163
Bazy danych Andrzej Bobyk http://www.alfabeta.lublin.pl/BD/

Bazy danych · Baza danych. Związki ... • Integracja danych – przechowywanie jednego logicznego elementu danych tylko w jednym miejscu • Integralność danych

Embed Size (px)

Citation preview

Bazy danychAndrzej Bobyk

http://www.alfabeta.lublin.pl/BD/

Literatura• P. Beynon-Davies: Systemy baz danych. WNT,

Warszawa 2003• C. J. Date: Wprowadzenie do systemów baz

danych. WNT, Warszawa 2000• J. D. Ullman, J. Widom: Podstawowy wykład

z systemów baz danych. WNT, Warszawa 2000• T. M. Connolly, C. E. Begg: Systemy baz danych.

Praktyczne metody projektowania, implementacji i zarządzania. RM, Warszawa 2004

Literatura (c.d.)• C. J. Date, H. Darwen: SQL. Omówienie standardu

języka. WNT, Warszawa 2000• J. S. Bowman, S. L. Emerson, M. Darnowsky:

Podręcznik języka SQL. WNT, Warszawa 2001• H. Ladanyi: SQL. Księga eksperta. Helion, Gliwice

2000• A. Jakubowski: Podstawy SQL. Ćwiczenia

praktyczne. Helion, Gliwice 2001• R. Wrembel, J. Jezierski, M. Zakrzewicz: System

zarządzania bazą danych Oracle 7 i Oracle 8.Nakom, Poznań 1999

Czym są bazy danych (BD)?

• Magazyn danych z nałożoną na niego pewną strukturą

• Model pewnego aspektu rzeczywistości organizacji (tzw. obszaru analizy – OA)

• Zbiór powiązanych ze sobą danych, którego zadaniem jest reprezentowanie OA (część ekstensjonalna)

• Definicje struktur danych służących do organizowania i przechowywania danych (część intensjonalna – schemat BD)

Piramida wiedzy

Kontekst bazy danych

Użytkownicy Źródło danychBaza danych

Związki z rzeczywistością

Historia zarządzania danymi• 4000 p.n.e – 1900 n.e - ręczne

zarządzanie zapisami– pierwszy znany zapis obejmujqcy

majątek królewski i podatki w Sumatrze• 1900 – 1955 - zarządzanie zapisami

na kartach perforowanych– Maszyna Holleritha (bazująca na

wynalazku Jacquarda z 1801 roku)

Historia zarządzania danymi• 1955 – 1970 - programowane

zarządzanie zapisami– 1950 rok wynalezienie taśmy

magnetycznej (na jednej mieściły się dane z ok. 10 000 kart perforowanych)

– praca wsadowa na plikach i rekordach (nie daje możliwości wychwycenia błędów aż do zakończenia wsadu)

Historia zarządzania danymi• 1965 – 1970 - sieciowe zarządzanie

danymi on-line– praca on-line, przetwarzanie bieżących

transakcji– pliki indeksowane– zastosowanie bębnów i dysków

magnetycznych– trzypoziomowa architektura bazy

danych

Historia zarządzania danymi• 1980 – 1995 - relacyjne zarządzanie

danymi– 1970 - model Codd’a– powszechne SZBD na komputery PC– najczęściej stosowany model– architektura klient-serwer

• 1995 - Obiektowe bazy danych– dane aktywne– oparte o mechanizmy dziedziczenia– często przechowują dane różnych typów

np.: głos, obraz, dane GIS itp.

Rozwój systemu informacyjnego• Informatyzacja zwyczajowo odbywała się po

kawałku (każdy dział oddzielnie)• Informatyzacja „po kawałku” najczęściej prowadzi

do powstania wielu oddzielnych systemów z własnymi plikami, danymi i programami

Rozwój systemu informacyjnego• Izolowane systemy nie reprezentują sposobu,

w jaki działa organizacja.• Wymiana danych między systemami odbywa się

poza nimi.• Informacje wygenerowane przez kilka systemów są

dla personelu mniej wartościowe, gdyż nie dają pełnego obrazu działalności organizacji.

• Dane mogą być powielane w wielu plikach używanych przez różne systemy.

• W nowoczesnych systemach informatycznych dane są zintegrowane - dzięki czemu mogą być

wykorzystywane na wiele sposobów

Zalety komputerowych BD

• Szybkość wyszukiwania informacji• Oszczędność miejsca• Integralność danych• Dostęp dla wielu użytkowników• Wygodne interfejsy• Zabezpieczenia dostępu

Przykłady BD• Książki telefoniczne• Systemy rezerwacji miejsc• Katalogi biblioteczne• Systemy finansowo-księgowe• Systemy wspomagające zarządzanie• Witryny WWW

Część ekstensjonalna BD• Encje (klasy) – rzeczy istotne dla OA

– każda encja musi być jednoznacznie identyfikowalna (nazwa w liczbie pojedynczej)

– każda instancja (wystąpienie) encji musi być wyraźnie odróżnialna od wszystkich innych instancji encji tego samego typu (identyfikator, klucz główny)

• BD jest zbiorem faktów (asercji) pozytywnych na temat OA – fakty negatywne nie są reprezentowane

• BD znajduje się w pewnym stanie (zawiera zbiór faktów, które są prawdziwe w danej

chwili)• Dane w bazie są traktowane jako trwałe

Integralność BD• BD ma właściwość integralności, jeżeli jest

dokładnym odbiciem swojego OA• Jeżeli BD jest używana do celów

referencyjnych, to integralność nie jest istotna

• Integralność sprawia, że BD zmienia się w przestrzeni, określonej przez zbiór stanów poprawnych

Więzy integralności• Określają, w jaki sposób baza ma

pozostać dokładnym odbiciem swojego OA

• Więzy statyczne – określają, które stany bazy są poprawne

• Więzy przejść – reguły, które wiążą ze sobą stany BD

Część intensjonalna BD• Encje mają atrybuty (właściwości)• Między encjami zachodzą pewne zależności, które mogą być opisywane przez diagramy związków encji(ERD)

• Tworzenie schematu BD to projektowanie BD

Rodzaje atrybutów• wymagane vs. opcjonalne

– np. sygnatura („1234/AB”) vs. data_wypożyczenia (null)

• proste vs. złożone– np. nazwisko („Kowalski”) vs. adres

(„Dworcowa 11 m. 7, 75-201 Koszalin”) → ulica („Dworcowa”), nr_domu („11”), nr_lokalu („7”), kod_pocztowy („75-201”), miasto („ Koszalin”)

• jedno- vs. wielowartościowe– nazwisko („Kowalski”) vs. nr_telefonu („941234567”,

„501987654”, „666333111”)

• podstawowe vs. pochodne– data_urodzenia („07.07.1997”) vs. wiek („15”)

→ wiek = data_bieżąca – data_urodzenia

Diagram związków encji (ERD)• Diagram prezentujący dane i związki

logiczne pomiędzy nimi • Na diagramie występują:

– encje o określonych właściwościach (atrybutach)

– związki między nimi (odniesienia)• Notacje:

– „kurza łapka”– UML– … i szereg innych

Związki encji• Stopień związku:

– unarne (rekurencyjne)– binarne (najczęściej spotykane)– tercjarne, ternarne, n-arne

• Więzy strukturalne (krotności)– liczność

• jeden-do-jednego (1:1)• jeden-do-wielu (1:N, 1:*)• wiele-do-wielu (N:M, *:*)

– uczestnictwo• obowiązkowe• opcjonalne

Diagram związków encji (ERD)

Diagram związków encji

Rozszerzony model związków encji (EER)

• Specjalizacja/generalizacja– hierarchia encji– związki nadklasa-podklasa– dziedziczenie atrybutów

• Agregacja i kompozycja

Funkcje BD• Funkcje aktualizujące – dokonują

zmian na danych• Funkcje zapytań – wydobywają dane

z bazy– proste– złożone

Cykl życia bazy

danych

Konceptualne projektowanie bazy danych

Planowanie bazy danych

Definicja systemu

Gromadzenie i analiza wymagań

Projektowanie bazy danych

Selekcja SZBD Projektowanie aplikacji

Logiczne projektowaniebazy danych

Fizyczne projektowanie bazy danych

Tworzenie prototypów Implementacja

Konwersjai przenoszenie danych

Testowanie

Bieżąca konserwacja

Administracja danymi i bazą danych• Administracja danymi – oznacza zarządzanie

zasobami danych, w tym planowanie bazy danych, tworzenie i utrzymywanie standardów, założeń i procedur oraz konceptualne i logiczne projektowanie bazy danych.

• Administracja bazą danych – oznacza zarządzanie fizyczną realizacją aplikacji, w tym fizyczne projektowanie i implementację bazy danych, definiowanie zasad bezpieczeństwa i więzów integralności, monitorowanie wydajności bazy danych oraz przeprowadzanie jej reorganizacji w razie potrzeby.

Zadania administratora danych• Wybór odpowiednich narzędzi systemowych.• Wspieranie rozwoju technologii informacyjnych

w przedsiębiorstwie i związanych z nimi strategii.• Przeprowadzanie badań realizowalności oraz planowanie

rozwoju bazy danych.• Tworzenie modelu danych przedsiębiorstwa.• Określanie wymagań instytucji odnośnie do danych.• Ustalanie standardów gromadzenia danych i ich formatów.• Szacowanie objętości danych i perspektyw wzrostu.• Wyznaczanie sposobów i częstości użycia danych.• Wyznaczanie wymagań względem metod dostępu do danych

oraz określanie zabezpieczeń, realizujących prawne i firmowe wymagania tego typu.

• Realizacja konceptualnego i logicznego projektu bazy danych.

Zadania administratora danych• Łączność z administratorami bazy danych

i wykonawcami aplikacji, służąca zapewnieniu wypełniania przez aplikacje wszystkich ustalonych wymagań.

• Szkolenie użytkowników w zakresie standardów danych i odpowiedzialności prawnej.

• Bieżące śledzenie technologii informacyjnych i postępu w przedsiębiorstwie.

• Zapewnienie kompletności dokumentacji, włączając w to model przedsiębiorstwa, standardy, założenia, proce-dury, użycie słownika danych i nadzór nad użytkownikami.

• Zarządzanie słownikiem danych.• Łączność z użytkownikami służąca określaniu nowych

wymagań i rozwiązywaniu problemów dotyczących dostępu do danych i wydajności.

• Tworzenie założeń dotyczących bezpieczeństwa.

Zadania administratora bazy danych• Ocena i wybór SZBD.• Realizacja fizycznego projektu bazy danych.• Implementacja fizycznego projektu bazy danych

w docelowym SZBD.• Definiowanie zasad bezpieczeństwa i więzów

integralności.• Łączność z wykonawcami aplikacji bazy danych.• Tworzenie strategii testowania.• Szkolenie użytkowników.• Końcowy odbiór zaimplementowanych aplikacji bazy

danych.• Monitorowanie wydajności systemu

i dostrajanie systemu w razie potrzeby.

Zadania administratora bazy danych• Regularne wykonywanie kopii zapasowych.• Zapewnienie dostępności mechanizmów i procedur

odzyskiwania danych.• Zapewnienie kompletności dokumentacji, w tym

materiałów wytworzonych własnymi siłami.• Bieżące śledzenie rozwoju sprzętu i oprogramowania

oraz ich cen.• Instalacja koniecznych aktualizacji.

Własności BD• Współdzielenie danych

– używanie bazy przez więcej niż jednego użytkownika, być może w tym samym czasie

• Integracja danych– przechowywanie jednego logicznego

elementu danych tylko w jednym miejscu• Integralność danych

– baza danych ma dokładnie odzwierciedlać obszar analizy, którego jest modelem

Własności BD• Bezpieczeństwo danych

– określenie zbioru użytkowników i ich uprawnień, ograniczenie dostępu do bazy

• Abstrakcja danych– przechowywanie w bazie tylko istotnych

szczegółów, dotyczących OA• Niezależność danych

– oddzielenie danych od procesów, które używają tych danych – organizacja danych ma być niewidoczna dla użytkowników

System zarządzania BD (SZBD)

• Zbiór programów, umożliwiających tworzenie i eksploatację BD

• Zarządza transakcjami (interakcjaz użytkownikami)

• Zarządza dostępem do danych (wprowadzanie, usuwanie i modyfikacja)

• System bazy danych = BD + SZBD

Moduł zarządzania transakcjami

Moduł zarządzania dostępem do danych

S

Z

B

D

użytkownik

schemat BD

dane

System BD

transakcja

System baz danych (SBD)• System Baz Danych to skomputeryzowany

system przechowywania i przetwarzania danych. Składa się z następujących elementów:– modelu danych– oprogramowania

• System Zarządzania Bazą Danych• inne oprogramowanie

– baz danych

System baz danych (SBD)• Często do sytemu baz danych zalicza się

również:– sprzęt

• pamięci masowe• urządzenia systemowe

– użytkowników• programiści aplikacji - tworzą programy

umożliwiające innym użytkownikom dostęp do bazy danych

• użytkownicy końcowi - obsługujący bazę danych -wprowadzający dane, generujący raporty itp.

• administratorzy BD - odpowiadają za tworzenie i konserwację rzeczywistej bazy danych oraz jej bezpieczeństwo

Funkcje SZBD• Zarządzanie plikami

– dodawanie nowych plików do BD– usuwanie plików z BD– modyfikowanie struktury istniejących plików– wstawianie nowych danych do istniejących

plików– aktualizowanie danych w istniejących plikach– usuwanie danych z istniejących plików

Funkcje SZBD (c.d.)• Wyszukiwanie informacji

– wydobywanie danych z istniejących plików do stosowania przez użytkowników

– wydobywanie danych do stosowania przez programy użytkowe

• Zarządzanie BD– tworzenie i monitorowanie użytkowników BD– ograniczanie dostępu do plików w BD– monitorowanie działania BD

Architektura SZBD– W 1975 (ANSI-SPARC) zaproponował

trzypoziomową architekturę SZBD:• poziom zewnętrzny (użytkownika) - opisuje jak

użytkownicy widzą dane,• poziom koncepcyjny (pojęciowy) - opisuje widok

wszystkich danych w bazie. Poziom ten opisuje logiczny widok baz danych, bez szczegółów dotyczących realizacji,

• poziom wewnętrzny (fizyczny) - opisuje sposób przechowywania danych oraz metody dostępu do nich.

– Pomiędzy warstwami istnieją dwa poziomy odwzorowania przekładające się na dwa poziomy niezależności danych:

• logiczna niezależność danych - oznacza niewrażliwość schematów zewnętrznych na zmiany w schemacie koncepcyjnym,

• fizyczna niezależność danych - oznacza niewrażliwość schematu koncepcyjnego na zmiany w schemacie fizycznym.

Architektura SZBD (c.d.)

Architektura SZBD (c.d.)

Transakcja• Jednostka interakcji użytkownika z BD• Składa się z ciągu akcji (pojedynczych

operacji)• Przeprowadza BD z jednego stanu w drugi• Może zostać zatwierdzona (commit) lub

wycofana (rollback)

Cechy transakcji (ACID)• Niepodzielność (Atomicity)• Spójność (Consistency)• Izolacja (Isolation)• Trwałość (Durability)

Transakcja jest funkcją aktualizującą

Architektoniczne modele danych

• Zbiór ogólnych zasad posługiwania się danymi:1. definicja danych (określa strukturę danych)2. operowanie danymi3. integralność danych (określa, które stany bazy

są poprawne)

• Każda baza danych i każdy SZBD muszą się stosować do zasad pewnego

modelu danych

Architektoniczne modele danych (c.d.)

• Proste modele danych (plik – rekord – pole)• Klasyczne modele danych

– model hierarchiczny– model sieciowy– model relacyjny

• Semantyczne modele danych– model obiektowy

Generacje baz danych• systemy plików (takie jak: ISAM i VSAM),• hierarchiczne baz danych (ISM, System

2000),• sieciowe bazy danych CODASYL (m.in.

IDS, IDMS),• relacyjne bazy danych,• obiektowe bazy danych,• postrelacyjne (obiektowo-relacyjne) bazy

danych.

Chronologia powstawania modeli danych

Cechy modeli klasycznych• struktura bazy danych opiera się na

rekordach różnych typów o stałym formacie

• każdy rekord definiowany jest poprzez stałą liczbę atrybutów

• każdy atrybut jest zazwyczaj określonego rozmiaru co ułatwia implementację

• nie zawierają mechanizmów bezpośredniej reprezentacji kodu w bazie danych

Cechy modeli klasycznych• z modelami związane są języki

zapytań umożliwiające realizację zapytań oraz modyfikację danych

• opis danych na poziomie konceptualnym oraz na poziomie wyglądu

• całościowa specyfikacja konceptualnej struktury bazy danych

• opis implementacji bazy danych na wysokim poziomie

Hierarchiczne bazy danych• W hierarchicznym modelu danych

(HMBD) dane maja strukturę, którą można najprościej opisać jako odwrócone drzewo.

• Jedna z tabel pełni rolę „korzenia” drzewa, a pozostałe mają postać „gałęzi” biorących swój początek w korzeniu.

Hierarchiczne bazy danych• Związki w HMBD są reprezentowane

w kategoriach ojciec/syn (nadrzędny/podrzędny). Oznacza to że tabela-ojciec może być powiązana z wieloma tabelami/synami, lecz pojedynczy syn może mieć tylko jednego ojca. Tabele te mogą być powiązane jawnie, przez wskaźniki, lub przez fizyczną organizację

rekordów wewnątrz tabel.

Hierarchiczne bazy danych• Aby uzyskać dostęp do danych

w modelu hierarchicznym, użytkownik zaczyna przeszukiwanie od korzenia i przedziera się przez całe drzewo danych, aż do interesującego go miejsca. Oznacza to jednak, że użytkownik musi dobrze znać strukturę bazy danych.

Model hierarchiczny

Książki

Podręczniki

Historyczne Obyczajowe

Beletrystyka

Informatyka Fizyka

Bazy danych ArkuszeEdytory Optyka Magnetyzm

P. Beynon-Davies: Systemy baz danych

Przykład 1: System plików UNIX/Linux/DOS/Windows

Przykład 2: Rejestr systemu Windows

Przykład 3: Usługi katalogowe(NDS/eDirectory, LDAP/ActiveDirectory)

Model sieciowy

ModernizmGotyk

Architektura Malarstwo Rzeźba

Renesans Barok

AngliaPolska Francja Włochy

Leonardo da Vinci: Mona Lisa

Model relacyjny• Twórca: E.F. Codd (od 1968 do dziś)• Cele:

– zdyscyplinowany sposób posługiwania się danymi (narzędzia matematyczne teorii zbiorów)

– podniesienie poziomu niezależności między programami a danymi

– wzrost wydajności tworzenia oprogramowania• Jedna struktura danych: relacja

(tabela relacyjna)• Operacje na relacjach tworzą tzw.

algebrę relacyjną• Nieproceduralny język zapytań

Wady klasycznych baz danych i SZBD

• model danych (szczególnie relacyjny) jest zbyt prosty do zamodelowania złożonych, zagnieżdżonych encji,

• systemy baz danych oferują tylko kilka prostych typów danych (integer, character), nie obsługują ogólnych typów danych występujących

w językach programowania,• &

Wady klasycznych baz danych i SZBD

• model danych nie zawiera często używanych pojęć semantycznych (np.: generalizacja, agregacja), a co za tym idzie SZBD nie oferuje mechanizmów do reprezentacji takich związków i zarządzania nimi (programiści muszą sami zaimplementować takie mechanizmy w aplikacjach),

Wady klasycznych baz danych i SZBD

• zbyt wolne działanie systemów baz danych z programami użytkowymi wymagającymi szybkich i skomplikowanych obliczeń (szczególnie symulacyjnych),

• różnice między językami baz danych (SQL, DL/1, CODASYL DML), a językami programowania (COBOL, FORTRAN, PL/1,

C++, Java) zarówno pod względemwykorzystywanego modelu danych, jak i struktur danych,

Wady klasycznych baz danych i SZBD

• systemy baz danych nie dostarczają narzędzi do reprezentowania i zarządzania temporalnymi aspektami baz danych (m.in.: pojęciem czasu, wersjami obiektów i schematu).

Model obiektowy• Jest przykładem semantycznego

modelu danych• Semantyka (znaczenie) informacji

zawarte w samej bazie danych• Naturalne powiązanie danych

i sposobów operowania na nich (enkapsulacja)

• Najczęściej realizowany jako dodatkowa opcja w modelu relacyjnym

• Ułatwione odwzorowanie danych do obiektowych języków programowania

(np. Java)

Relacyjna i obiektowa struktura aplikacji

Zalety obiektowych baz danych

• reprezentacja złożonych obiektów• typy danych definiowane przez

użytkownika• tożsamość obiektów (identyfikator),

trwałość• hermetyzacja, hierarchia, dziedziczenie• rozszerzalność• zgodność we wszystkich fazach życia

bazy i danych

Zalety obiektowych baz danych

• metody i funkcje przechowywane wraz z danymi

• nowe możliwości (wersjonowanie, rejestracja zmian, powiadamianie ...)

• możliwość nowych zastosowań mniejszym kosztem (bazy multimedialne, przestrzenne, bazy aktywne...)

• porównywalna wydajność (i wciążrośnie)

Wady obiektowych baz danych

• brak optymalizacji zapytań (rozumianej jak w poprzednich modelach)

• niedopracowane mechanizmy zarządzania dużą bazą obiektów, sterowania wersjami,...

• mała liczba ekspertów od technik obiektowych

• nie wiadomo z jakimi kosztami wiąże się migracja dużych systemów

• brak dopracowanych standardów

Model relacyjny – zasady• Jedna struktura danych – relacja (tabela

relacyjna)• Relacja jest skończonym zbiorem krotek

(wierszy tabeli) o różnych wartościach i takiej samej strukturze (schemacie)

• schemat relacji – lista nazw kolumn (atrybutów relacji)

• plik – encja – relacja - tabela• rekord – instancja - krotka – wiersz tabeli• atrybut - kolumna – zbiór wartości danego

atrybutu• wartość atrybutu - pole rekordu – pole

tabeli (na przecięciu wiersza i kolumny)

Przykład relacjiPrzedmioty

Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456

Cechy relacji1. Każda relacja w bazie ma jednoznaczną

nazwę2. Każda kolumna w relacji ma

jednoznaczną nazwę w ramach relacji3. Wszystkie wartości w kolumnie są tego

samego typu4. Porządek kolumn w relacji nie jest

istotny5. Każdy wiersz w relacji musi być różny6. Porządek wierszy nie jest istotny7. Każde pole zawiera wartość atomową

(niepodzielną)

Dziedzina• Zbiór wartości, z którego pochodzą

elementy, pojawiające się w kolumnach tabeli

• Wartość null oznacza niepełną lub nieznaną informację

• Trzeba stosować logikę trójwartościową

Klucze główne• Kolumna (lub zbiór kolumn), której

wartości jednoznacznie identyfikują każdy wiersz tabeli

• Klucz główny wybierany jest spośród kluczy kandydujących

• Integralność encji: każda tabela musi mieć klucz główny; kolumna (lub kolumny) wybrane jako klucz główny powinny być jednoznaczne i nie zawierać wartości null

Klucze kandydujące/główne

WykładowcyNrPrac Nazwisko Status234 P. Beynon-Davies AS345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE

Klucze kandydujące/głównePrzedmioty

Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456

Klucze kandydujące/głównePrzedmioty

Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456Informatyka 1 MAT null

Klucze obce• Kolumna (lub zbiór kolumn) tabeli,

która czerpie swoje wartości z tej samej dziedziny, co klucz główny tabeli z nią powiązanej

• Integralność referencyjna: każda wartość klucza obcego może bądź odwoływać się do wartości klucza głównego tabeli powiązanej, bądź przyjmować wartość null

Klucze obce

Wykładowcy

NrPrac Nazwisko Status

234 P. Beynon-Davies AS

345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE

Przedmioty

Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234

Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345

Prawo administracyjne 2 ADM 456Informatyka 1 MAT null

Utrzymywanie integralności referencyjnej

1. Usuwanie ograniczone (podejście ostrożne)

2. Usuwanie kaskadowe (podejście ufne)

3. Wstawianie null (podejście wyważone)

Integralność dodatkowa• Aspekt integralności, którego nie

można wyrazić za pomocą reguł integralności wewnętrznej (semantyka)

• Ciąg definicji więzów, najczęściej wyrażany za pomocą reguł algebry relacyjnej, wyrażeń SQL itp.

Algebra relacyjna• selekcja (ograniczenie)• projekcja (rzut)• złączenia• iloczyn kartezjański• suma• przecięcie• różnica• iloraz

SelekcjaPrzedmioty

Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456

SelekcjaσSemestr=1 Przedmioty

Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234

ProjekcjaPrzedmioty

Nazwa Semestr KodKierunku NrPracSystemy baz danych 1 INF 234Podstawy programowania 1 INF 234Informatyka 3 ADM 345Projektowanie sieci komputerowych 3 INF 345Prawo administracyjne 2 ADM 456

ProjekcjaπNazwa,Semestr Przedmioty

Nazwa SemestrSystemy baz danych 1Podstawy programowania 1Informatyka 3Projektowanie sieci komputerowych 3Prawo administracyjne 2

Złączenia• równozłączenie• złączenie naturalne• złączenia zewnętrzne

– lewostronne– prawostronne– obustronne

RównozłączenieRównozłączenie relacji Przedmioty i Wykładowcy

Przedmioty EQUIJOIN Wykładowcy

Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych

1 INF 234 234 P. Beynon-Davies

AS

Podstawy programowania

1 INF 234 234 P. Beynon-Davies

AS

Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych

3 INF 345 345 C.J. Date AD

Prawo administracyjne

2 ADM 456 456 J. Ullmann PR

Złączenie naturalneZłączenie naturalne relacji Przedmioty i Wykładowcy

Przedmioty JOIN Wykładowcy

Nazwa Semestr KodKierunku NrPrac Nazwisko StatusSystemy baz danych

1 INF 234 P. Beynon-Davies

AS

Podstawy programowania

1 INF 234 P. Beynon-Davies

AS

Informatyka 3 ADM 345 C.J. Date ADProjektowanie sieci komputerowych

3 INF 345 C.J. Date AD

Prawo administracyjne

2 ADM 456 J. Ullmann PR

Złączenia zewnętrzneLewostronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy

Przedmioty LEFT OUTER JOIN Wykładowcy

Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych

1 INF 234 234 P. Beynon-Davies

AS

Podstawy programowania

1 INF 234 234 P. Beynon-Davies

AS

Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych

3 INF 345 345 C.J. Date AD

Prawo administracyjne

2 ADM 456 456 J. Ullmann PR

Informatyka 1 MAT null null null null

Złączenia zewnętrznePrawostronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy

Przedmioty RIGHT OUTER JOIN Wykładowcy

Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych

1 INF 234 234 P. Beynon-Davies

AS

Podstawy programowania

1 INF 234 234 P. Beynon-Davies

AS

Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych

3 INF 345 345 C.J. Date AD

Prawo administracyjne

2 ADM 456 456 J. Ullmann PR

null null null null 666 B. Devil PE

Złączenia zewnętrzneObustronne złączenie zewnętrzne relacji Przedmioty i Wykładowcy

Przedmioty FULL OUTER JOIN Wykładowcy

Nazwa Semestr KodKierunku NrPrac NrPrac Nazwisko StatusSystemy baz danych

1 INF 234 234 P. Beynon-Davies

AS

Podstawy programowania

1 INF 234 234 P. Beynon-Davies

AS

Informatyka 3 ADM 345 345 C.J. Date ADProjektowanie sieci komputerowych

3 INF 345 345 C.J. Date AD

Prawo administracyjne

2 ADM 456 456 J. Ullmann PR

Informatyka 1 MAT null null null nullnull null null null 666 B. Devil PE

Operatory teoriomnogościowe

• Suma, przecięcie, różnica• Operują na relacjach o zgodnych

schematach, tj. zawierających te same zbiory atrybutów, określonych na tych samych dziedzinach

• Traktują relacje jako zbiory krotek

Suma, przecięcie, różnicaWykładowcy

NrPrac Nazwisko Status

234 P. Beynon-Davies AS

345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE

Administratorzy

NrPrac Nazwisko Status

234 P. Beynon-Davies AS

345 C.J. Date AD777 A. Angel PR1001 S. Jones UR1023 R. Evans SU

Suma, przecięcie, różnicaWykładowcy UNION Administratorzy

NrPrac Nazwisko Status

234 P. Beynon-Davies AS

345 C.J. Date AD456 J. Ullmann PR666 B. Devil PE777 A. Angel PR1001 S. Jones UR1023 R. Evans SU

Wykładowcy INTERSECT Administratorzy

NrPrac Nazwisko Status

234 P. Beynon-Davies AS

345 C.J. Date AD

Suma, przecięcie, różnicaWykładowcy EXCEPT Administratorzy

NrPrac Nazwisko Status

456 J. Ullmann PR

666 B. Devil PE

Administratorzy EXCEPT Wykładowcy

NrPrac Nazwisko Status

777 A. Angel PR

1001 S. Jones UR1023 R. Evans SU

Modelowanie związków encjiModel związków encji (ER – Entity-Relationship Model) – jeden z przykładów modelu do komunikowania się z użytkownikami.

Modelowanie związków encji reprezentuje podejście zstępujące do projektowania bazy danych. Rozpoczyna się mianowicie od wyodrębnienia istotnych danych, nazywanych encjami, i tych związków pomiędzy nimi, które powinny być reprezentowane w modelu. Następnie dodaje się do modelu coraz więcej szczegółów, takich jak informacje, które chcemy przechowywać o encjach i o związkach, nazywane atrybutami, oraz więzy(warunki) odnoszące się do encji, związków i atrybutów.

Zbiór encji – to grupa obiektów o tych samych właściwościach, które w ramach przedsiębiorstwa zostały uznane za niezależne byty.

Wystąpienie encji – to unikalny i rozpoznawalnyobiekt ze zbioru encji.

Graficzna reprezentacja zbiorów encji

Każdy zbiór encji jest reprezentowany za pomocą prostokąta oznaczonego nazwą encji, która jest zazwyczaj rzeczownikiem w liczbie pojedynczej.

Personel WłaścicielPrywatny

Nazwa encji

Związki encjiZwiązek – to zbiór znaczących powiązań pomiędzy zbiorami encji.

Wystąpienie związku – to unikalne i identyfikowalne powiązanie zachodzące pomiędzy pojedynczymi wystąpieniami encji z uczestniczących w związku zbiorów encji.

Encja Biuro(biuroNr)

Encja Personel(pracownikNr)

B003

B007

r1

r2

r3

SG37

SG14

SA9

Związek Ma

Sieć semantyczna:Używając modelu związków encji:

Nazwa związku

“Biuro ma personel”

Biuro PersonelMa

Stopień związku (liczba uczestniczących w nim zbiorów encji)

“Właściciel prywatny posiada nieruchomość do wynajęcia”

WłaścicielPrywatny NieruchomośćPPosiada

BiuroPersonel Rejestruje

Klient

“Personel rejestrujeklienta w biurze”

InstytucjafinansowaKupujący Uzgadnia

Oferta

Prawnik

“Prawnik w imieniu kupującegowspieranego przez instytucjęfinansową uzgadnia ofertę”

Związek binarny:

Związek potrójny:

Związek poczwórny:

Związki rekurencyjne(związki, w których ten sam zbór encji występuje więcej niż jeden raz w różnych rolach)

Zarządza

MaPersonel Biuro

“Dyrektor zarządza biurem oddziału”

Nazwa roli

Biuro oddziałuDyrektor

“Biuro oddziału ma pracownika”

Nazwa roli

Biuro oddziałuPracownik

Nazwa roli

Nazwa roli“Personel (kierownik) kierujepersonelem (kierowanymi)”

Kieruje

Personel

Kierownik

Kierowany

Zbiór encji Personeluczestniczy podwójnie w związku Kieruje.Związkom mogą być przypisane nazwy ról, które są istotne przy związkach rekurencyjnych, aby wskazać funkcje wypełniane w nich przez uczestników.

Nazwy ról nie są na ogół wymagane, jeśli funkcje, jakie pełnią w związku uczestniczące w nim encje, są jednoznaczne.

Przykład encji powiązanych ze sobą poprzez dwa różne związki:

Atrybut (cecha encji lub związku)

Klucz główny

Atrybutwielowartościowy

Zarządza

Ma

Personel

pracownikNr (PK)imięNazwiskostanowiskopensja/liczba personelu

Biuro

biuroNr (PK)adres

ulicamiastokodPocztowy

telNr

Obszar doumieszczania

atrybutów Atrybutpochodny

Atrybut złożony

Atrybutjednowartościowy

• proste – zawierające tylko jedną składową, która może istnieć niezależnie;• złożone – zbudowane z wielu składowych, z których każda może istnieć

niezależnie;• jednowartościowy – atrybut, który ma tylko jedną wartość;• wielowartościowy – atrybut, który może zawierać wiele wartości dla

pojedynczego wystąpienia encji.• pochodny – atrybut reprezentujący wartość, która jest wyliczana z

podobnego atrybutu lub ze zbioru atrybutów, niekoniecznie pochodzących z tego samego zbioru.

[1..3][1..*]

PK – primary keyPPK – partial primary keyAK – alternate key

Atrybuty związków

Graficzna reprezentacja związku Ogłasza:

Silne i słabe zbiory encji:

Nieruchomość

NieruchomośćNr

Gazeta

NazwaGazety

dataOgłoszeniakoszt

Ogłasza

“Gazeta ogłasza nieruchomość do wynajęcia”

Silna encja Słaba encja

Klient

klientNr (PK)imięNazwisko

imięnazwisko

telNr

Preferencje

typPreferencjimaksCzynsz

Określa

Silny zbiór encji – to zbiór encji, którego istnienie nie jest zależne od innych zbiorów encji, natomiast istnienie słabego zbioru encji zależy od innych zbiorów encji.

Więzy strukturalneWięzy, które mogą być nałożone na zbiory encji biorące udział w związku powinny odzwierciedlać ograniczenia występujące w związkach, które można zaobserwować w „rzeczywistości”. Głównym typem więzów nakładanych na związki jest krotność – liczba lub zakres możliwych wystąpień encji z jednego zbioru, które mogą być w danym związku z pojedynczym wystąpieniem innej powiązanej encji. Krotność ogranicza sposób powiązania encji, reprezentuje założenia określone przez użytkownika lub przedsiębiorstwo.

Najbardziej powszechnymi związkami są związki binarne, które można podzielić na:

• wzajemnie jednoznaczne (1:1);• typu „jeden do wielu” (1:*);• typu „wiele do wielu”.Np.:• osoba z personelu zarządza biurem (1:1);• osoba z personelu nadzoruje nieruchomości do wynajęcia (1:*);• gazety ogłaszają nieruchomości do wynajęcia (*:*).

Związki wzajemnie jednoznaczne

Sieć semantyczna przedstawia-jąca dwa wystąpienia związku Personel Zarządza Biuro:

Krotność

“Każde biuro jest zarządzaneprzez jedną osobę z personelu”

“Osoba z personelu zarządzazero lub jednym biurem”

Zarządza Biuro

biuroNr

Personel

pracownikNr 1..1 0..1

Wyznaczenie krotności związku wymaga na ogół wykorzystania próbek danych i dokładnego zbadania powiązań pomiędzy danymi występującymi w tym związku.

Zbiór encji Biuro(biuroNr)

Zbiór encji Personel(pracownikNr)

B003

B005

r1

r2

SG5

SG37

SL21

Związek Zarządza

Związek typu „jeden do wielu”

Sieć semantyczna przedstawiająca trzywystąpienia związku Personel NadzorujeNieruchomość:

“Każda nieruchomość dowynajęcia jest nadzorowana przez

pracownika”zero lub jednego

“Każdy pracownik nadzorujenieruchomości

do wynajęcia”zero lub więcej

Nadzoruje Nieruchomość

nieruchomośćNr

Personel

pracownikNr 0..1 0..*

Zbiór encji Nieruchomość(nieruchomośćNr)

Zbiór encji Personel(pracownikNr)

PG21

PG36

PA14PG4

r1

r3

r2

SG5

SG37

SA9

Związek Nadzoruje

Związek typu „wiele do wielu”

Encja Nieruchomość(nieruchomośćNr)

Encja Gazeta(nazwaGazety)

PG21

PG36

PA14

PG4

r1

r3r4

r2Głos

Gazeta

Poranny

Związek Ogłasza

“Każda nieruchomość dowynajęcia jest ogłaszanaw zero lub więcej gazet”

“Każda gazeta ogłaszanieruchomości

do wynajęcia”jedną lub więcej

Ogłasza Nieruchomość

nieruchomośćNr

Gazeta

nazwaGazety 0..* 1..*

Sieć semantyczna przedstawiająca czterywystąpienia związku Gazeta OgłaszaNieruchomość:

Więzy liczności i uczestnictwaLiczność – opisuje maksymalną liczbę możliwych wystąpień związku dla encji uczestniczącej w tym związku.

Uczestnictwo – określa, czy w pewnym związku biorą udział wszystkie, czy tylko niektóre wystąpienia encji.

“Nie każdy pracownik zarządzabiurem” (uczestnictwo

opcjonalne dla personelu)

“Wszystkie biura są zarządzane” (uczestnictwo

obowiązkowe dla biur)

“Jedno biuro jest zarządzaneprzez jednego pracownika”

“Jeden pracownik zarządza jednym biurem”

Zarządza Biuro

biuroNr

Personel

pracownikNr 1..1 0..1

Liczność

Uczestnictwo

Problemy występujące w modelach ER

Pułapka wachlarzowa – występuje w sytuacji, gdy model przedstawia związek pomiędzy pewnymi zbiorami encji, ale wynikające z tego ścieżki pomiędzy wystąpieniami encji nie są jednoznaczne.

ProwadziMa OddziałPersonel Biuro1..* 1..1 1..1 1..*

Prowadzi MaOddział PersonelBiuro1..1 1..* 1..1 1..*

Zmiana strukturymodelu

Pułapka szczelinowa – występuje, gdy model sugeruje istnienie związku pomiędzy zbiorami encji, ale nie istnieją ścieżki łączące pewne wystąpienia tych encji.

NadzorujeMa NieruchomośćPersonelBiuro1..1 1..* 0..1 0..*

NadzorujeMa NieruchomośćPersonelBiuro1..1 1..* 0..1 0..*

Dodanie związku Oferuje

Oferuje1..1 1..*

Rozszerzone modelowanie związków encji

Specjalizacja – to proces maksymalizacji różnic pomiędzy elementami encji, realizowany poprzez identyfikację wyróżniających ich charakterystyk.

Generalizacja – to proces minimalizacji różnic pomiędzy encjami, realizowany poprzez wyznaczanie ich wspólnych charakterystyk.

Agregacja – reprezentuje związki typu „jest częścią” lub „ma” pomiędzy zbiorami encji, w których jeden uczestnik związku jest „całością”, a drugi „częścią.

Kompozycja – to specjalna forma agregacji przedstawiająca powiązanie pomiędzy encjami, w którym występuje silny związek „posiadania” części przez całość oraz zgodność okresów ich istnienia.

110

Transformacja ERD do modelu relacyjnego

• Transformacja encji i ich atrybutów na relacje i ich atrybuty

• Transformacja związków pomiędzy encjami na związki pomiędzy relacjami

• Transformacja hierarchii encji(w modelu rozszerzonym) na …

Przypomnienie pojęć• Schemat bazy danych

– zbiór schematów relacji• Relacja (tabela)

– dwu-wymiarowa tablica– kolumny → atrybuty– wiersze → krotki, rekordy

• każda krotka reprezentuje wystąpienie encji

Przypomnienie pojęć• Klucz główny (podstawowy)

– atrybut lub zbiór atrybutów - wybrany spośród kluczy potencjalnych

• Klucz obcy– atrybut lub zbiór atrybutów wskazujący

na klucz główny innej relacji• atrybut lub zbiór atrybutów w relacji B,

będący jednocześnie kluczem głównymw relacji A

– należy zaznaczyć, że klucz obcy może odnosić się do klucza głównego tej samej relacji, w której został on zdefiniowany

Reguły transformacji encji• Encja → relacja• Atrybut encji → atrybut relacji• Typ danych atrybutu encji → typ

danych atrybutu relacji• Identyfikator encji → klucz główny

relacji• Obowiązkowość atrybutów encji →

ograniczenie NOT NULL• Opcjonalność atrybutów encji →

ograniczenie NULL• Pozostałe ograniczenia

integralnościowe atrybutów encji → ograniczenia integralnościowe atrybutów relacji

• Atrybuty wielowartościowe– odrębna krotka w tabeli, dla każdej

wartości atrybutu (ale mogą się pojawić anomalie i problemy z normalizacją)

– odrębna tabela na wartości tego atrybutu (i powiązane z nimi) plus powiązanie z tabelą zasadniczą

• Atrybuty złożone– podział na atrybuty proste → dodatkowe

kolumny w tabeli

Reguły transformacji encji

Reguły transformacji związków

• Związek binarny 1:1 → klucz obcy we wskazanej tabeli

• Związek unarny 1:1, 1:M → klucz obcy w tej samej tabeli

• Związek binarny 1:M → klucz obcy w tabeli po stronie „wiele”

• Związek unarny/binarny M:N, związki stopnia > 2 (tercjarne, ternarne)→ tabela

Związek binarny 1:1 (1)

Prezentator
Notatki do prezentacji
Związek binarny 1:1 jednostronnie obowiązkowy transformuje się do klucza obcego w tabeli po stronie związku obowiązkowego. Ograniczenie integralnościowe jest definiowane dla atrybutu klucza obcego. Klucz ten nie może przyjmować wartości pustych. W przykładzie ze slajdu, z encji Pracownik powstaje tabela Pracownicy, a z encji Samochód - tabela Samochody. Związek pomiędzy tymi dwoma encjami jest transformowany do klucza obcego IdPracownika w tabeli Samochody. Klucz ten wskazuje na klucz podstawowy w tabeli Pracownicy, czyli IdPracownika. Wartość atrybutu klucza obcego musi być zawsze określona ponieważ związek jest obowiązkowy od strony encji Samochód.

Związek binarny 1:1 (2)

Prezentator
Notatki do prezentacji
Związek binarny 1:1 obustronnie opcjonalny transformuje się do klucza obcego w tabeli o mniejszym rozmiarze. Ograniczenie integralnościowe jest definiowane dla atrybutu klucza obcego. Atrybut ten może przyjmować wartości puste, ponieważ związek jest opcjonalny. W przykładzie ze slajdu, z encji Pracownik powstaje tabela Pracownicy, a z encji Komputer - tabela Komputery. Związek jest transformowany do klucza obcego IdPracownika w tabeli Komputery. Klucz ten wskazuje na klucz podstawowy w tabeli Pracownicy, czyli IdPracownika. Klucz obcy może przyjmować wartości puste.

Związek binarny 1:1 (3)

Prezentator
Notatki do prezentacji
Możliwe przypadki transformacji związku 1:1 obustronnie opcjonalnego przedstawia slajd. Przypadek 1 jest stosowany niezwykle rzadko. Polega on na umieszczeniu kluczy obcych w obu tabelach wynikowych. Przypadek 2 został omówiony na poprzednim slajdzie. Przypadek trzeci polega na umieszczeniu klucza obcego w tabeli Pracownicy.

Związek 1:M (1)• Klucz obcy dodawany do relacji po stronie

"wiele"• Ograniczenia referencyjne definiowane dla

klucza obcego• Obowiązkowość związku po stronie „wiele” →

ograniczenie NOT NULL definiowane na kluczu obcym

• Opcjonalność związku po stronie „wiele” →ograniczenie NULL definiowane na kluczu obcym relacji

• • Opcjonalność lub obowiązkowość związku po stronie „jeden” nie jest odwzorowywana w modelu relacyjnym

Związek 1:M (2)

Prezentator
Notatki do prezentacji
Przykład ze slajdu ilustruje sposób transformacji binarnego związku 1:M jednostronnie obowiązkowego. Z encji Pracownik powstaje tabela Pracownicy, a z encji Dział – tabela Działy. Klucz obcy jest dodawany do tabeli Pracownicy (strona "wiele") i wskazuje on na klucz podstawowy tabeli Działy, czyli IdDziału. Należy zwrócić uwagę, że klucz obcy IdDziału posiada ograniczenie NOT NULL ponieważ związek jest obowiązkowy od strony "wiele".

Związek M:N (1)• Reprezentowany poprzez dodatkową

relację• Nazwa relacji jest złączeniem nazw

relacji powstałych z encji• Relacja zawiera klucze obce wskazujące

na klucze główne relacji powstałych z powiązanych encji

• Ograniczenia referencyjne definiowanedla kluczy obcych

• • Klucze obce tworzą klucz główny relacji

Prezentator
Notatki do prezentacji
Reguły transformacji związku M:N są identyczne zarówno dla związków jednostronnie obowiązkowych, jak i obustronnie opcjonalnych.

Związek M:N (2)

Prezentator
Notatki do prezentacji
Poniższy przykład ilustruje sposób transformacji binarnego związku M:N jednostronnie obowiązkowego. Z encji Pracownik powstaje tabela Pracownicy, a z encji Projekt - tabela Projekty. Ze związku powstaje tabela pośrednia o nazwie Pracownicy_Projekty. Zawiera ona dwa klucze obce. Jeden wskazuje na klucz podstawowy tabeli Pracownicy, czyli IdPracownika, a drugi - na klucz podstawowy tabeli Projekty, czyli NrProjektu. Oba klucze obce stanowią klucz podstawowy tabeli Pracownicy_Projekty. Oznacza to, że ich wartości nigdy nie mogą być puste.

• Związek M:N przenosimy jako nową relację• Tworzymy klucze obce na podstawie kluczy

głównych dwóch pozostałych relacji• Na atrybuty jednego i drugiego klucza

obcego nakładamy dwa ograniczenia referencyjne

• Wszystkie atrybuty relacji tworzą klucz główny

Transformacja związków M:N

PRACOWNIK# id_pracownika* imię* nazwisko

pracuje nadjest realizowany

przez

A co w przypadku gdybyśmy chcieli przechowywać

informację o liczbie godzin tygodniowo przepracowanych

przez pracownika nad określonym projektem ?

PROJEKT# nazwa_proj* data_rozpocz o data_zakoncz

Transformacja związków M:N

PRACOWNIK# id_pracownika* imię* nazwisko

pracuje nadjest realizowany

przez

Jest to przypadek atrybutu charakteryzującego

związek !

PROJEKT# nazwa_proj* data_rozpocz o data_zakoncz

Transformacja związków M:N

PRACOWNIK# id_pracownika* imię* nazwisko

pracuje nadjest realizowany

przez

PROJEKTY (Nazwa_projektuData_rozpocz Data_zakoncz

PRIMARY KEY NOT NULL NULL )

PRACOWNICY (Id_pracownikaImięNazwisko

PRIMARY KEY NOT NULL NOT NULL )

UDZIAŁY_W_PROJEKTACH (Id_pracownika REFERENCES Pracownicy(id_pracownika),Nazwa_projektu REFERENCESProjekty(Nazwa_projektu),Godziny NULLPRIMARY KEY (Id_pracownika, Nazwa_projektu) )

Atrybut związku

PROJEKT# nazwa_proj* data_rozpocz o data_zakoncz

Transformacja związków M:N

Przykład 1• OA: W pewnej szkole organizowane są

konkursy przedmiotowe dla uczniów, którzy za udział w nich otrzymują nagrody. Każdy konkurs ma swojego opiekuna spośród nauczycieli, datę, kwotę przeznaczoną na nagrody itp. Uczniowie uczęszczają do klas o różnym profilu, z których każda ma swojego wychowawcę.

• Zadanie: Przedstawić opisany powyżej OA w postaci diagramu związków encji

i przekształcić go w schemat relacji.

Przykład 2• OA: Pewna uczelnia prowadzi projekty

finansowane ze źródeł zewnętrznych. Każdy projekt jest kierowany przez swojego kierownika i ma m.in. określony budżet, w projekcie biorą ponadto udział pracownicy różnych działów uczelni (każdy dział ma m.in. także osobę zarządzającą i swój budżet), którzy oprócz regularnej pensji otrzymują dodatkowe wynagrodzenie z tytułu udziału w projekcie. – Zadanie: Analogiczne, jak poprzednio.

Związek unarny (1)

Prezentator
Notatki do prezentacji
Związek unarny 1:1 lub 1:M obustronnie opcjonalny transformuje się do klucza obcego w tej samej tabeli. W pierwszym przykładzie ze slajdu, z encji Pracownik powstaje tabela Pracownicy. Zawiera ona klucz obcy IdKierownika wskazujący na IdPracownika w tej samej tabeli. Należy zwrócić uwagę, że wartość klucza obcego może być pusta ponieważ związek jest opcjonalny od strony "wiele". W drugim przykładzie, w tabeli Osoby powstaje klucz obcy IdWspółmałżonka wskazujący na IdOsoby w tej samej tabeli. Ponieważ związek jest opcjonalny, więc klucz obcy może przyjmować wartości puste.

Związek unarny (2)

Prezentator
Notatki do prezentacji
Związek unarny M:N obustronnie opcjonalny jest transformowany do tabeli pośredniej. W przykładzie ze slajdu, z encji Lek powstaje tabela Leki, a związek jest transformowany do tabeli o nazwie Zastępniki. Tabela ta posiada dwa klucze obce (atrybut IdLeku1 i IdLeku2), oba wskazują na klucz podstawowy tabeli Leki, czyli na atrybut IdLeku. Oba klucze obce wchodzą w skład klucza podstawowego tabeli Zastępniki.

Związki tercjarne

Prezentator
Notatki do prezentacji
Związek tercjarny transformuje się w sposób identyczny jak związek 1:M. W przykładzie ze slajdu, z encji Mandat powstaje tabela Mandaty. Zawiera ona 3 klucze obce: IdKierowcy, NrSłużbowy, NrWykroczenia wskazujące odpwiednio na: IdKierowcy w tabeli Kierowcy, NrSłużbowy w tabeli Policjanci, NrWykroczenia w tabeli Wykroczenia. Te trzy klucze obce wchodzą w skład klucza podstawowego tabeli Mandaty, ponieważ transformowana encja Mandat była słaba.

Hierarchia encji• Schemat 1: jedna wspólna tabela• Schemat 2: dla każdej pod-encji tworzona

jest tabela, zawierająca atrybuty wspólne i specyficzne

• Schemat 3:– dla atrybutów wspólnych tworzona jest tabela

wspólna– dla każdej pod-encji tworzona jest osobna

tabela z kluczem i atrybutami specyficznymi– tabela wspólna i tabele powstałe z pod-encji,

powiązane ograniczeniami referencyjnymi

Prezentator
Notatki do prezentacji
Hierarchię encji do modelu relacyjnego można przetransformować na 3 sposoby. Sposób (schemat) 1 polega na utworzeniu jednej tabeli ze wszystkimi atrybutami i kluczami obcymi, tj. wspólnymi i specyficznymi dla podencji. Sposób (schemat) 2 polega na utworzeniu osobnej tabeli dla każdej podencji. Każda z tabel zawiera atrybuty wspólne i specyficzne dla określonej encji. Sposób (schemat) 3 polega na utworzeniu osobnej tabeli na atrybuty wspólne i osobnej tabeli dla każdej podencji. Tabele powstałe z podencji zawierają klucz podstawowy i atrybuty specyficzne. Tabela wspólna i tabele powstałe z podencji są połączone ograniczeniami referencyjnymi.

Transformacja hierarchii encji(schemat 1 – do jednej relacji)

Prezentator
Notatki do prezentacji
Przykład ze slajdu ilustruje sposób transformacji hierarchii encji według schematu 1. Powstała tabela Klienci zawiera wszystkie atrybuty wspólne i wszystkie atrybuty specyficzne dla wszystkich podencji. Atrybuty specyficzne w tabeli mogą przyjmować wartości puste zawsze, niezależnie od ich definicji w pod-encjach. Wynika to z faktu, że rekord w tabeli klienci opisuje albo klienta fizycznego albo prawnego. Jeśli rekord opisuje klienta fizycznego, to atrybuty klienta prawnego pozostają puste i odwrotnie. Dodatkowo, w tabeli Klienci jest tworzony atrybut z wartością obowiązkową (KL_TYPE), którego wartościami mogą być albo 'F' albo 'P'. Wartość tego atrybutu określa czy rekord opisuje klienta fizycznego ('F'), czy prawnego ('P'). Atrybut ten jest przydatny przy wyszukiwaniu klientów określonego typu.

Zasady transformacji:Tworzymy relację zawierającą

atrybuty wspólne, atrybuty specyficzne wszystkich specjalizacji i atrybut określający typ specjalizacji.

Wszystkim atrybutom specyficznym poszczególnych specjalizacji nadajemy własność NULL.

PRACOWNIK# id_prac

atrybuty_wspólne PRACOWNIK KRAJOWYatr_specyf_kraj

PRACOWNIKZAGRANICZNYatr_specyf_zagr

PRACOWNICY (Id_pracownika PRIMARY KEYatrybuty wspólne atr_specyf_kraj atr_specyf_zagr typ_prac

NULL NULLNOT NULL)

Transformacja hierarchii encji(schemat 1 – do jednej relacji)

Transformacja hierarchii encji(schemat 2 – do dwóch relacji)

Prezentator
Notatki do prezentacji
Przykład ze slajdu ilustruje sposób transformacji hierarchii encji według schematu 2. Z encji OS_FIZYCZNA powstaje tabela OS_FIZYCZNE. Zawiera ona wszystkie atrybuty wspólne encji Klient i wszystkie atrybuty specyficzne encji OS_FIZYCZNA. Opcjonalność/obowiązkowość wartości atrybutów encji przenosi się bezpośrednio na opcjonalność/obowiązkowość atrybutów tabeli OS_FIZYCZNE. W podobny sposób jest transformowana encja OS_PRAWNA.

Zasady transformacji:Dla każdej specjalizacji

tworzymy relację zawierającą atrybuty wspólne, atrybuty specyficzne danej specjalizacji i klucz podstawowy dziedziczony z generalizacji.

PRACOWNIK# id_prac atrybuty_wspólne PRACOWNIK

KRAJOWYatr_specyf_kraj

PRACOWNIK ZAGRANICZNYatr_specyf_zagr

PRACOWNICY_KRAJ (Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_kraj )PRACOWNICY_ZAGR (Id_pracownika PRIMARY KEY atrybuty wspólne atr_specyf_zagr )

Transformacja hierarchii encji(schemat 2 – do dwóch relacji)

Transformacja hierarchii encji(schemat 3 – do trzech relacji)

Prezentator
Notatki do prezentacji
Przykład ze slajdu ilustruje sposób transformacji hierarchii encji według schematu 3. Z encji OS_FIZYCZNA powstaje tabela OS_FIZYCZNE, która zawiera wszystkie atrybuty specyficzne ze swojej encji i atrybut OFI_ID, który jest kluczem podstawowym tabeli OS_FIZYCZNE. Z encji OS_PRAWNA powstaje tabela OS_PRAWNE, która zawiera wszystkie atrybuty specyficzne ze swojej encji i atrybut OPR_ID, który jest kluczem podstawowym tabeli OS_PRAWNE. Z atrybutów wspólnych encji Klient powstaje tabela KLIENCI. Dodatkowo, tabela ta posiada dwa klucze obce OFI_OFI_ID i OPR_OPR_ID, z wartościami opcjonalnymi. Pierwszy z nich wskazuje na klucz podstawowy tabeli OS_FIZYCZNE, a drugi – na klucz podstawowy tabeli OS_PRAWNE. Dla danego rekordu w tabeli KLIENCI, tylko jeden klucz obcy może przyjąć wartość, ponieważ rekord w tabeli KLIENCI opisuje albo osobę prawną albo fizyczną.

Zasady transformacji:Tworzymy jedną relację

zawierająca atrybuty wspólne i atrybut określający typ specjalizacji

Dla każdej specjalizacji tworzymy relację zawierającą jej atrybuty specyficzne i klucz podstawowy dziedziczony z generalizacji.

PRACOWNICY (Id_pracownika PRIMARY KEY atrybuty_wspólne,typ_prac NOT NULL )

PRACOWNIK# id_prac atrybuty_wspólne PRACOWNIK

KRAJOWYatr_specyf_kraj

PRACOWNIK ZAGRANICZNYatr_specyf_zagr

PRACOWNICY_KRAJ (Id_pracownika PRIMARY KEY atr_specyf_kraj )PRACOWNICY_ZAGR (Id_pracownika PRIMARY KEY atr_specyf_zagr )

Transformacja hierarchii encji(schemat 3 – do trzech relacji)

Transformacja związków wyłącznych - schemat 1

Prezentator
Notatki do prezentacji
Transformacja związków wyłącznych jest podobna do transformacji związku 1:M. Z tą tylko różnicą, że klucze obce mogą przyjmować wartości puste. Jako przykład rozważmy encję Rachunek bankowy powiązaną związkami wyłącznymi z encją Osoba fizyczna i Osoba prawna. Z encji Rachunek bankowy powstaje tabela Rachunki_Bankowe, która posiada dwa klucze obce, jeden wskazuje na klucz podstawowy tabeli Osoby_Fizyczne, a drugi - na klucz podstawowy tabeli Osoby_Prawne. Oba klucze obce mogą przyjmować wartości puste, pomimo, że związki z których powstały są obowiązkowe od strony "wiele". Dzieje się tak dla tego, że dany rekord rachunku bankowego jest albo związany z osobą fizyczną albo z osobą prawną, więc tylko jeden klucz obcy przyjmie wartość.

Transformacja związków wyłącznych - schemat 2

Prezentator
Notatki do prezentacji
Alternatywny sposób transformacji związków wyłącznych przedstawiono na slajdzie. Różni się on od poprzedniego tym, że w tabeli Rachunki_Bankowe jest atrybut Właściciel, który może przyjąć wartość klucza podstawowego rekordu albo z tabeli Osoby_Ficzyzne albo z tabeli Osoby_Prawne; dla atrybutu tego zdefiniowanie ograniczenia referencyjnego jest niemożliwe. Ponadto, w tabeli Rachunki_Bankowe jest atrybut RodzajWłaściciela, który może przyjąć jedną z dwóch wartości 'F' lub 'P'. Służy on do określania rodzaju osoby, na którą wskazuje wartość atrybutu Właściciel. Oba atrybuty nie mogą przyjmować wartości pustych.

Normalizacja schematu relacji• Głównym celem projektowania bazy

przeznaczonej dla systemu relacyj-nego jest właściwa reprezentacja danych, związków i więzów

• W identyfikowaniu właściwych relacji pomaga technika nazywana normalizacją, która jest techniką wstępującą („z dołu do góry”) projektowania bazy danych

Normalizacja schematu relacji• Normalizacja – to technika służąca do

wyznaczania zbioru relacji o pożądanych własnościach na podstawie analizy istniejącego zbioru danych

• Metoda stosowana głównie w organiza-cjach, które przed wprowadzeniem bazy danych gromadziły dane w innej formie –np. w arkuszach kalkulacyjnych lub w formie papierowej

Normalizacja schematu relacji• 1972 – po raz pierwszy przedstawiony

proces normalizacji przez E.F.Codda; wówczas zaproponował trzy postacie normalne: 1NF, 2NF, 3NF (normal form).

• 1974 – R.Boyce i E.F.Codd wprowadzili silniejszą definicję trzeciej postaci normalnej (BCNF)

• Powyższe postacie normalne są oparte na zależnościach funkcyjnych pomiędzy atrybutami

Normalizacja schematu relacji• Wprowadzone kilka lat później

wyższe postacie normalne, wychodzące poza BCNF, czwarta i piąta postać normalna (Fagin 1977, 1979) dotyczą sytuacji występujących bardzo rzadko

• Powyższe postacie normalne są oparte na niefunkcyjnych zależnościach wielowartościowych

pomiędzy atrybutami

Nadmiarowość danych i anomalie aktualizacji

• Główne zadanie w projektowaniu relacyjnej bazy danych to pogrupowanie atrybutów w relacje w sposób, który minimalizuje nadmiarowość danych – efektem jest zmniejszenie wymagań pamięciowych dla plików implementujących bazowe

relacje oraz usunięcie anomalii aktualizacji

Anomalie wynikające z nadmiarowości

• anomalie wstawiania (dopisanie rekordu może powodować niespójność/ dezaktualizację innego pola)

• anomalie usuwania (usunięcie wiersza powoduje usunięcie większej ilości informacji, niż zamierzaliśmy)

• anomalie modyfikacji (zmiana jednego rekordu powoduje konieczność

zmiany zapisów w innych rekordach)

Prezentator
Notatki do prezentacji
Relacje zawierające nadmiarowe dane mogą być przyczyną anomalii aktualizacji, które dzielą się na:

Dekompozycja• Poprzez dekompozycję relacji pozby-

wamy się problemu anomalii aktualizacji• Dekompozycja ma dwie ważne własności:

– bezstratnego złączenia – zapewniająca, że każdy stan oryginalnej relacji może być odtworzony z odpowiednich stanów mniejszych relacji

– zachowania zależności – gwarantująca, że więzy na oryginalnej relacji mogą być

utrzymane przez proste wymuszenie pewnych więzów na każdej z mniejszych relacji

Etapy normalizacji

1. Zebranie danych2. Przekształcenie do pierwszej postaci

normalnej (1NF)3. Przekształcenie do drugiej postaci

normalnej (2NF)4. Przekształcenie do trzeciej postaci

normalnej (3NF)

Etapy normalizacji• Po znormalizowaniu do 3NF relacje

najczęściej są już pozbawione anomalii, jeżeli nie to należy je:4. Przekształcić do postaci normalnej Boyce’a-

Codd’a (BCNF)5. Przekształcić do czwartej postaci normalnej

(4NF)6. Przekształcić do piątej postaci normalnej

(5NF)• Proces normalizacji jest włożony, tzn.

każda wyższa postać normalna jest podzbiorem postaci niższej

Nieznormalizowany zbiór danych

Przedmiot Id pracownika

Nazwisko pracownika

Id studenta Student Ocena Typ oceny

TOiS 23 Bos 123 Botas 4 W

4,5 Ć

143 Moton 3,5 Ć

134 Koton 4,5 W

5 Ć

UA 23 Bos 321 Ficek 4 W

4,5 Ć

Angielski 34 Kusek 231 Bocek 5 Ć

Zależność funkcyjna• Dwa elementy danych A i B są w zależności

funkcyjnej lub relacji zależnej, jeśli ta sama wartość elementu danych B pojawia się zawsze z tą samą wartością elementu danych A. W takim przypadku mówimy, że atrybut A określa (wyznacza) funkcyjnie atrybut B:

A → B• Wszystkie atrybuty w tabeli są funkcyjnie zależne

od klucza głównego tej tabeli• Wszystkie dane osobowe są zależne funkcyjnie od

numeru PESEL osoby

Pierwsza postać normalna• Relacja jest w pierwszej postaci normalnej

wtedy i tylko wtedy, gdy każdy atrybut niekluczowy jest funkcyjnie zależny od klucza głównego (co jest równoważne stwierdzeniu, że w polach relacji mamy wartości atomowe, niepodzielne, a nie listy/zbiory wartości)

• W pierwszym etapie normalizacji próbujemy znaleźć w relacji klucz główny – od którego wszystkie atrybuty niekluczowe byłyby funkcyjnie zależne. Jeśli nie można znaleźć klucza głównego,

to relację należy podzielić na mniejsze

Znormalizowany zbiór danych (1NF)

Przedmiot Id pracownika

Nazwisko pracownika

Id studenta

Student Ocena Typ oceny

TOiS 23 Bos 123 Botas 4 W

TOiS 23 Bos 123 Botas 4,5 Ć

TOiS 23 Bos 143 Moton 3,5 Ć

TOiS 23 Bos 134 Koton 4,5 W

TOiS 23 Bos 134 Koton 5 Ć

UA 23 Bos 321 Ficek 4 W

UA 23 Bos 321 Ficek 4,5 Ć

Angielski 34 Kusek 231 Bocek 5 Ć

Druga postać normalna• Relacja jest w drugiej postaci normalnej wtedy

i tylko wtedy, gdy jest w pierwszej postaci normalnej i każdy atrybut niekluczowy jest w pełni funkcyjnie zależny od klucza głównego (tzn. od całości klucza, a nie tylko jego części)

• W tabeli Oceny atrybut Student zależy funkcyjne tylko od atrybutu Id studenta, czyli od części klucza głównego, a nie od całego klucza, podobnie jak Id pracownika i Nazwisko pracownika, które zależą tylko od atrybutu Przedmiot

• Atrybut Ocena zależy funkcyjnie od całego klucza głównego

Przejście do 2NF(z zachowaniem bezstratnego złączenia)

Przedmiot Id studenta

Typ oceny

Student Ocena

TOiS 123 W Botas 4

TOiS 123 Ć Botas 4,5

TOiS 143 Ć Moton 3,5

TOiS 134 W Koton 4,5

TOiS 134 Ć Koton 5

UA 321 W Ficek 4

UA 321 Ć Ficek 4,5

Angielski 231 Ć Bocek 5

Oceny

Przedmiot Id pracownika

Nazwisko pracownika

TOiS 23 Bos

UA 23 Bos

Angielski 34 Kusek

Przedmioty1

*

Tabele w 2NF

Przedmiot Id studenta

Typ oceny

Ocena

TOiS 123 W 4

TOiS 123 Ć 4,5

TOiS 143 Ć 3,5

TOiS 134 W 4,5

TOiS 134 Ć 5

UA 321 W 4

UA 321 Ć 4,5

Angielski 231 Ć 5

Oceny

Id studenta

Student

123 Botas

143 Moton

134 Koton

321 Ficek

231 Bocek

StudenciPrzedmiot Id

pracownikaNazwisko pracownika

TOiS 23 Bos

UA 23 Bos

Angielski 34 Kusek

Przedmioty1 * 1*

Trzecia postać normalna• Relacja jest w trzeciej postaci normalnej wtedy i

tylko wtedy, gdy jest w drugiej postaci normalnej i każdy niekluczowy atrybut jest bezpośrednio funkcyjnie zależny (a nie pośrednio zależny) od klucza głównego (inaczej mówiąc, brak jest zależności funkcyjnych atrybutów niekluczowych od innych atrybutów niekluczowych)

• W tabeli Przedmioty atrybut Nazwisko pracownikajest zdeterminowany przez atrybut Id pracownika, a zatem atrybut Nazwisko pracownika jest

przechodnio zależny od klucza głównego –atrybutu Przedmiot

Przejście do 3NF(z zachowaniem bezstratnego złączenia)

Id pracownika Nazwisko pracownika

23 Bos

34 Kusek

Pracownicy

Przedmiot Id pracownika

Nazwisko pracownika

TOiS 23 Bos

UA 23 Bos

Angielski 34 Kusek

Przedmioty

Przedmiot Id pracownika

TOiS 23

UA 23

Angielski 34

Przedmioty 1*

Tabele w 3NF

Przedmiot Id studenta

Typ oceny

Ocena

TOiS 123 W 4

TOiS 123 Ć 4,5

TOiS 143 Ć 3,5

TOiS 134 W 4,5

TOiS 134 Ć 5

UA 321 W 4

UA 321 Ć 4,4

Angielski 231 Ć 5

OcenyId studenta

Student

123 Botas

143 Moton

134 Koton

321 Ficek

231 Bocek

StudenciPrzedmiot Id

pracownika

TOiS 23

UA 23

Angielski 34

Przedmioty1* 1*

Id pracownika

Nazwisko pracownika

23 Bos

34 Kusek

Pracownicy1

*

Schemat bazy danych po normalizacji

Pracownicy

Id pracownika

Nazwisko pracownika

Oceny

Przedmiot

Id studenta

Typ oceny

ocena

Studenci

Id studenta

Student

Przedmioty

Przedmiot

Id pracownika

1

*1

*

1*

Podsumowanie• Postać nieznormalizowana (0NF – zero- th normal

form) – to tabela nie zawierająca ani jednej powtarzającej się grupy

• Pierwsza postać normalna (1NF – first normal form) – to relacja, w której każde przecięcie wiersza i kolumny zawiera tylko jedną wartość

• Druga postać normalna (2NF) – oznacza relację w pierwszej postaci normalnej, w której każdy atrybut spoza klucza głównego jest od niego w pełni funkcyjnie zależny

• Trzecia postać normalna (3NF) – oznacza relację w pierwszej i w drugiej postaci normalnej, w której

żaden atrybut spoza klucza głównego nie jest od niego przechodnio zależny

162

Przysięga normalizacji

• Bez powtórzeń (0NF)• Pola zależą od klucza (1NF)• Od całego klucza (2NF)• I niczego innego, tylko klucza (3NF)• Tak mi dopomóż Codd