Relacyjne Bazy Danych wykad V 1 opr Lech
Relacyjne Bazy Danych wykład V 1 opr. Lech Banachowski, Jan Wierzbicki
Jakość schematu bazy danych Pożądane cechy modelu danych Następujące cechy modelu danych trzeba zapewnić na samym początku procesu projektowania, pozostając w ścisłym kontakcie z użytkownikami: • poprawność modelu - to co jest w modelu jest zgodne z rzeczywistością; • istotność każdego elementu modelu dla funkcjonowania firmy (organizacji); • pełność modelu - gwarancja, że żaden element modelu danych - istotny dla funkcjonowania firmy (organizacji), nie został pominięty. 2 opr. Lech Banachowski, Jan Wierzbicki
Po skonstruowaniu modelu danych: • użytkownicy powinni rozumieć utworzony model danych i po dokładnym przeanalizowaniu wszystkich szczegółów, biorąc za to odpowiedzialność, zatwierdzić go; • projektant bazy danych traktuje uzgodniony z użytkownikami model danych jako wierne odzwierciedlenie rzeczywistości i dla tego modelu buduje bazę danych i aplikację bazy danych. 3 opr. Lech Banachowski, Jan Wierzbicki
Normalizacja Postulat normalizacji daje się wyrazić w następujący sposób: Każdy fakt przechowywany w bazie danych powinien być wyrażalny w niej tylko na jeden sposób. • Informacja o przedmiocie powinna być zapisana tylko w jednym miejscu, a nie przy każdym studencie, który uczęszcza na zajęcia z tego przedmiotu. • Jeśli w bazie danych zapisujemy informację o rodzicach każdej osoby, nie ma już potrzeby zapisywać informacji o dziadkach, gdyż ta informacja daje się wyprowadzić z informacji o rodzicach. 4 opr. Lech Banachowski, Jan Wierzbicki
• Jeśli w modelu firmy lotniczej Pasażer i Pracownik to dwie odrębne encje, to jedna osoba może figurować w bazie danych - raz jako pasażer, a raz jako pracownik firmy lotniczej. Wówczas dane dotyczące takiej osoby (np. adres zamieszkania) będą zapisane w dwóch różnych miejscach. 5 opr. Lech Banachowski, Jan Wierzbicki
Dlaczego niektóre schematy tabel są złe? Problem złych schematów tabel zaprezentujemy na dwóch przykładach. Klucz główny tabel będzie zaznaczany pogrubioną czcionką. Przykład 1 Dostawcy = {Nazwa_dostawcy, Adres, Nazwa_towaru, Cena} 6 opr. Lech Banachowski, Jan Wierzbicki
Nazwa_dostawcy Adres Nazwa_towaru Cena Kowalski Wiolinowa 7 Telewizor 1500 Kowalski Wiolinowa 7 Radio 500 Jaworski Mozarta 5 Telewizor 1800 Jaworski Mozarta 5 Komputer 5000 Kowalski Wiolinowa 7 Warszawska 140 Baterie 5 Magnetowid 1000 Marciniak 7 opr. Lech Banachowski, Jan Wierzbicki
Oto zestaw wad łatwych do zidentyfikowania w przedstawiony schemacie. 1. Redundancja: adres dostawcy powtarza się dla każdego dostarczanego towaru. 2. Anomalie przy modyfikacji: uaktualniony adres w jednym wierszu pozostaje niezmieniony w innych. 3. Anomalie przy wstawianiu: trudno wstawić dostawcę bez towarów; towar wchodzi w skład klucza - nie może być NULL. 4. Anomalie przy usuwaniu: usuwając informacje o wszystkich towarach dostarczanych przez dostawcę (który może zmienić profil produkcji) usuwamy informację o samym dostawcy 8 opr. Lech Banachowski, Jan Wierzbicki
Przyczyna: złączenie w jednej encji dwóch różnych rodzajów obiektów (encji): • Dostawcy = {Nazwa_dostawcy, Adres} • Towary = {Nazwa_dostawcy, Nazwa_towaru, Cena} Poprawienie schematu polega na rozbiciu początkowego schematu na dwie tabele każda reprezentująca osobny typ obiektów czyli odpowiednio dostawców i towary. 9 opr. Lech Banachowski, Jan Wierzbicki
Przykład 2 Pracownicy = {Id_prac, Nazwisko, Nazwa_uczelni, Adres} Id_prac Nazwisko Nazwa_uczelni 101 PJWSTK Kowalski 123 Kalinowski WSI 109 Jaworski WSI 102 Makowski PJWSTK Rudziak 105 WSI 10 Adres Koszykowa 86 Zamiany 15 opr. Lech Banachowski, Jan Wierzbicki
Znowu możemy zaobserwować podobne wady jak poprzednio mimo, że tym razem klucz główny jest jednoelementowy. 1. Redundancja: adres uczelni powtarza się dla każdego zatrudnionego w niej pracownika. 2. Anomalie przy modyfikacji: uaktualniony adres uczelni w jednym wierszu pozostaje niezmieniony w innych. 3. Anomalie przy wstawianiu: trudno wstawić uczelnię bez pracownika; Id_prac stanowi klucz i nie może być NULL. 4. Anomalie przy usuwaniu: usuwając wszystkich pracowników usuwamy uczelnię. 11 opr. Lech Banachowski, Jan Wierzbicki
Przyczyna: złączenie w jednej encji dwóch różnych rodzajów obiektów (encji): • Pracownicy = {Id_prac, Nazwisko, Nazwa_uczelni} • Uczelnie = {Nazwa_uczelni, Adres} Poprawienie schematu polega na rozbiciu początkowego schematu na dwie tabele każda reprezentująca osobny typ obiektów czyli odpowiednio pracowników i uczelnie. 12 opr. Lech Banachowski, Jan Wierzbicki
Dany jest schemat Przychodnia = {Pacjent, Choroba, Lekarz, Karta, Wpis, Adres}. Zachodzą następujące reguły: 1. Każdy pacjent ma kartę. 2. Na każdej karcie jest zapisany adres. 3. Na karcie znajdują się wpisy. 4. Wpis na karcie dotyczy choroby. 5. Wpis na karcie jest dokonywany przez lekarza. 13 opr. Lech Banachowski, Jan Wierzbicki
Wyjaśnienie złych schematów za pomocą pojęć zależności częściowych i przechodnich między atrybutami tabeli (1) Dla schematu tabeli Dostawcy = {Nazwa_dostawcy, Adres, Nazwa_towaru, Cena} • kluczem jest para atrybutów: Nazwa_dostawcy i Nazwa_towaru, • Adres zależy od części klucza mianowicie od atrybutu Nazwa_dostawcy. 14 opr. Lech Banachowski, Jan Wierzbicki
Mówimy, że wartość atrybutu Adres zależy częściowo od klucza: Nazwa_dostawcy -> Adres a samą zależność nazywamy zależnością częściową. Po przeniesieniu atrybutów: Nazwa_dostawcy i Adres do osobnej encji, atrybut Nazwa_dostawcy staje się kluczem a zależność częściowa "Nazwa_dostawcy -> Adres" staje się zależnością od całego klucza. 15 opr. Lech Banachowski, Jan Wierzbicki
(2) Dla schematu tabeli: Pracownicy = {Id_prac, Nazwisko, Nazwa_uczelni, Adres} • kluczem jest atrybut Id_prac, • Adres zależy od innego atrybutu Nazwa_uczelni, który nie jest kluczem. Mówimy w takim przypadku, że wartość atrybutu Adres zależy przechodnio od klucza: Nazwa_uczelni -> Adres a samą zależność nazywamy zależnością przechodnią. Po przeniesieniu atrybutów: Nazwa_uczelni i Adres do osobnej encji, atrybut Nazwa_uczelni staje się kluczem a zależność częściowa "Nazwa_uczelni-> Adres" staje się zależnością od całego klucza. 16 opr. Lech Banachowski, Jan Wierzbicki
Reasumując, istnienie zależności częściowych i przechodnich wskazuje, że schemat tabel ma niepoprawne właściwości. Poprawne są tylko zależności funkcyjne od całego klucza. 17 opr. Lech Banachowski, Jan Wierzbicki
Formalny model relacyjnych baz danych • Relacja jest abstrakcyjnym, matematycznym pojęciem zawierającym w sobie istotę modelu relacyjnego. Relacyjna baza danych to zbiór relacji. • Tabela jest konkretną reprezentacją relacji – jedna relacja ma wiele różnych reprezentacji za pomocą tabel. • W relacji kolejność wierszy i kolejność kolumn są nieistotne. • Dwa wiersze w tabeli zawierające te same wartości są uznawane za identyczne to znaczy za ten sam element relacji. 18 opr. Lech Banachowski, Jan Wierzbicki
Przykład relacji - Loty Numer Skąd Dokąd 83 Warszawa Moskwa 19 Warszawa Nowy Jork Frankfurt Warszawa Odlot Przylot 11: 30 13: 43 84 109 213 214 Moskwa Warszawa Frankfurt 15: 00 09: 50 11: 43 14: 20 17: 55 16: 52 12: 45 15: 29 115 515 Nowy Jork Warszawa 18: 12 07: 10 Nowy Jork Frankfurt 22: 00 09: 15 516 711 Frankfurt Nowy Jork 13: 20 19: 15 Warszawa Tokio 18: 00 09: 10 opr. Lech Banachowski, Jan Wierzbicki
Moglibyśmy zmienić kolejność wierszy w tabeli. Moglibyśmy zmienić kolejność kolumn w tej tabeli. I nie miałoby to znaczenia dla relacji będącej zawartością obu tabel. Będzie to ciągle ta sama relacja. Schematem relacji nazywamy listę R = {A 1, A 2, . . , An} gdzie A 1, A 2, . . , An są atrybutami (nazwami kolumn). Na przykład, Loty = {Numer, Skąd, Dokąd, Odlot, Przylot} Pracownik = {Idprac, Imie, Nazwisko, Iddept, Zarobki, Stanowisko} Departament = {Iddept, Nazwa, Miejsce} 20 opr. Lech Banachowski, Jan Wierzbicki
Dziedzina atrybutu Każdemu atrybutowi A przyporządkowana jest dziedzina oznaczana przez Dom(A) - zbiór dopuszczalnych wartości. Np. Dom(Numer) = NUMBER(3) Dom(Skąd) = CHAR(15) Dom(Dokąd) = CHAR(15) Dom(Odlot) = CHAR(5) Dom(Przylot) = CHAR(5) 21 opr. Lech Banachowski, Jan Wierzbicki
Dziedzina relacji Dziedziną relacji o schemacie R = {A 1, A 2, . . . , An} nazywamy sumę dziedzin wszystkich atrybutów relacji Dom(R) = Dom(A 1) + Dom(A 2) +. . + Dom(An) gdzie + oznacza tutaj operację sumowania zbiorów. Definicja relacji Relacją o schemacie R = {A 1, A 2, . . . , An} nazywamy skończony zbiór r = {t 1, t 2, . . . , tm} odwzorowań ti: R -> Dom(R) takich, że dla każdego j, 1 <= j <= n, ti(Aj) należy do dziedziny Dom(Aj) Każde takie odwzorowanie t nazywa się krotką (lub wierszem). 22 opr. Lech Banachowski, Jan Wierzbicki
Przykład krotki (elementu relacji) Krotka odpowiada wierszowi (rekordowi) w tabeli. Można ją formalnie określić przez podanie wartości dla poszczególnych atrybutów np. t(Numer) = 83, t(Skąd) = "Warszawa", t(Dokąd) = "Moskwa", t(Odlot) = "11: 30", t(Przylot) = "13: 43" Graficznie: Numer Skąd Dokąd Odlot Przylot 83 Warszawa Moskwa 11: 30 13: 43 23 opr. Lech Banachowski, Jan Wierzbicki
Operacja ograniczenia krotki Ograniczeniem krotki t relacji r o schemacie R do zbioru atrybutów X z R nazywamy odwzorowanie będące ograniczeniem t do zbioru atrybutów X t|X: X -> Dom(R) to znaczy t|X(x)=t(x) dla x w X a dla x w R-X wartość t|X(x) jest nieokreślona. Na przykład, gdy X = {Skąd, Dokąd}, to dla krotki t z poprzedniego przykładu t|X (Skąd)="Warszawa", t|X (Dokąd) = "Moskwa" Graficznie: Skąd Dokąd Warszawa Moskwa 24 opr. Lech Banachowski, Jan Wierzbicki
Zależność funkcyjna Relacja r o schemacie R = {A 1, A 2, . . . , An} spełnia zależność funkcyjną X -> Y (X, Y - podzbiory R) jeśli dla każdych dwóch krotek t, u relacji r zachodzi warunek: jeśli t|X = u|X to t|Y = u|Y tzn. w ramach krotek relacji r wartości atrybutów zbioru X determinują jednoznacznie wartości atrybutów zbioru Y. W przykładowej relacji Loty, wartości atrybutu Numer jednoznacznie identyfikują cały lot a więc w szczególności jednoznacznie identyfikują wartości wszystkich atrybutów tej relacji: Numer -> {Skąd, Dokąd, Odlot, Przylot} 25 opr. Lech Banachowski, Jan Wierzbicki
Przykład relacji z zależnościami funkcyjnymi między jej atrybutami mianowicie relację Znaki Zodiaku o schemacie {Id, Imię, Nazwisko, Dzien. Urodzenia, Znak. Zodiaku} 26 Id Imię Nazwisko Dzien. Urodzenia Znak. Zodiaku 1 Agnieszka Kowalska 23. 01 Wodnik 2 Mariusz Malewicz 1. 04 Baran 3 Krzysztof Zalewski 23. 04 Byk 4 5 6 7 Ilona Marek Roman Sylwia Zawadzka Walicki Gerlich Frymus 13. 04 31. 07 5. 09 13. 04 Baran Lew Panna Baran opr. Lech Banachowski, Jan Wierzbicki
Mamy do czynienia z zależnością funkcyjną DzieńUrodzenia -> Znak. Zodiaku to znaczy, temu samemu dniu urodzenia odpowiada zawsze ten sam znak zodiaku. W rzeczywistości mamy tutaj do czynienia z czymś więcej, mianowicie ze znaną funkcją f: DzieńUrodzenia -> Znak. Zodiaku przyporządkowującą dniu urodzenia znak zodiaku. Jednak ta funkcja nie daje się wyrazić za pomocą funkcyjnej zależności w sensie podanej powyżej definicji. 27 opr. Lech Banachowski, Jan Wierzbicki
Identyfikacja zależności funkcyjnych W procesie projektowania dla każdego schematu relacji identyfikujemy zbiór spełniających ją zależności funkcyjnych (zależny od konkretnego zastosowania). Na przykład dla relacji Loty identyfikujemy następujący zbiór zależności funkcyjnych między jej atrybutami: Numer -> {Skąd, Dokąd, Odlot, Przylot} {Skąd, Dokąd, Odlot} -> {Numer, Przylot} {Skąd, Dokąd, Przylot} -> {Numer, Odlot} Uwaga: często jest stosowana skrócona forma zapisu polegająca na opuszczaniu przecinków i nawiasów klamrowych: Numer -> Skąd Dokąd Odlot Przylot Skąd Dokąd Odlot -> Numer Przylot 28 opr. Lech Banachowski, Jan Wierzbicki
Nadklucz relacji Nadkluczem relacji r o schemacie R = {A 1, A 2, . . . , An} nazywamy dowolny zbiór atrybutów X z R taki, że zachodzi zależność funkcyjna X -> R - inaczej mówiąc, wartość każdego atrybutu ma być jednoznacznie zdeterminowana przez wartości atrybutów zbioru X. Jednym z nadkluczy jest zawsze zbiór wszystkich atrybutów R. 29 opr. Lech Banachowski, Jan Wierzbicki
Klucz relacji Kluczem relacji r o schemacie R = {A 1, A 2, . . . , An} nazywamy każdy minimalny nadklucz (nie zawierający w sobie żadnego innego nadklucza), tzn. zbiór atrybutów X jest kluczem jeśli wartość każdego atrybutu w R jest jednoznacznie zdeterminowana przez wartości atrybutów zbioru X i żaden podzbiór zbioru X nie ma już tej własności. Zawsze istnieje co najmniej jeden nadklucz - całe R, stąd wynika, że istnieje co najmniej jeden minimalny nadlucz czyli klucz a może być kluczy więcej jak to pokazuje przykład relacji Loty. Zależności funkcyjne schematu Loty określają trzy klucze: {Numer} {Skąd, Dokąd, Odlot} {Skąd, Dokąd, Przylot} 30 opr. Lech Banachowski, Jan Wierzbicki
Klucze i klucz główny Wyróżniony klucz nazywa się kluczem głównym. Wchodzące w jego skład atrybuty są podkreślane lub pogrubiane. Dla relacji Loty wybieramy jako klucz główny klucz Numer: Loty = {Numer, Skąd, Dokąd, Odlot, Przylot} Dany jest schemat Przychodnia = {Pacjent, Choroba, Lekarz, Karta, Wpis, Adres}. Zachodzą następujące reguły: 1. Każdy pacjent ma kartę. 2. Na każdej karcie jest zapisany adres. 3. Na karcie znajdują się wpisy. 4. Wpis na karcie dotyczy choroby. 5. Wpis na karcie jest dokonywany przez lekarza. 31 opr. Lech Banachowski, Jan Wierzbicki
Dla schematu identyfikujemy następujące zależności funkcyjne: 1. Pacjent -> Karta 2. Karta -> Adres 3. Wpis -> Karta 4. Wpis -> Choroba 5. Wpis -> Lekarz Jedynym kluczem jest para atrybutów: Pacjent i Wpis. 32 opr. Lech Banachowski, Jan Wierzbicki
Znaczenie zależności funkcyjnych Zależność od czegokolwiek innego niż klucz wprowadza wewnętrzną zależność między atrybutami tabeli. Powoduje możliwość determinowania wartości jednych atrybutów przez inne (redundancję). Pokazuje to tabelka dla zależności X-> Y: 33 X. . . Y. . . x . . . y . . . x . . . ? . . . Jeśli X nie jest nadkluczem, to przedstawiona w tabelce sytuacja oznacza redundancję. Wartość w polu oznaczonym przez "? " jest już jednoznacznie zdeterminowana – musi to być y. Natomiast gdy X jest nadkluczem, to przedstawiona sytuacja jest niemożliwa. Nie mogą być dwa różne wiersze z tą samą wartością klucza. opr. Lech Banachowski, Jan Wierzbicki
"Złe" zależności funkcyjne - zależności nie od klucza Zależność funkcyjna X -> Y jest zależnością od klucza jeśli zbiór atrybutów X jest nadkluczem. Zależność funkcyjna X -> Y jest zależnością nie od klucza jeśli 1. jest nietrywialna tzn. zbiór Y nie jest podzbiorem X, 2. nie jest zależnością od klucza. 34 opr. Lech Banachowski, Jan Wierzbicki
Są dwa typy zależności nie od klucza: 1. częściowe - od części klucza, 2. przechodnie - od czegokolwiek nieporównywalnego z kluczem. W schematach Dostawcy i Pracownicy występują zależności nie od klucza, odpowiednio: • Nazwa_dostawcy -> Adres_dostawcy (zależność częściowa) • Uczelnia -> Adres (zależność przechodnia) 35 opr. Lech Banachowski, Jan Wierzbicki
Dany jest schemat Przychodnia = {Pacjent, Choroba, Lekarz, Karta, Wpis, Adres}. Dla tego schematu zidentyfikowaliśmy następujące zależności funkcyjne: 1. Pacjent -> Karta 2. Karta -> Adres 3. Wpis -> Karta 4. Wpis -> Choroba 5. Wpis -> Lekarz 6. Jedynym kluczem jest para atrybutów: Pacjent i Wpis. 36 opr. Lech Banachowski, Jan Wierzbicki
Zależności funkcyjne: 1. Pacjent -> Karta 2. Wpis -> Karta 3. Wpis -> Choroba 4. Wpis -> Lekarz są zależnościami częściowymi (zależnościami od części klucza). Natomiast zależność Karta -> Adres jest zależnością przechodnią (od klucza). 37 opr. Lech Banachowski, Jan Wierzbicki
Metoda eliminowania „złych” zależności polega na wprowadzeniu dla zależności (częściowej lub przechodniej) osobnej tabeli i usunięciu atrybutu stojącego po prawej stronie tej zależności z oryginalnego schematu. (1) Dla schematu dostawców dodajemy schemat tabeli {Nazwa_dostawcy, Adres} i usuwamy z oryginalnego schematu atrybut Adres: {Nazwa_dostawcy, Nazwa_towaru, Cena}. 38 opr. Lech Banachowski, Jan Wierzbicki
2) Dla schematu pracowników dodajemy schemat tabeli {Nazwa_uczelni, Adres} i usuwamy z oryginalnego schematu atrybut Adres: {Id_prac, Nazwisko, Nazwa_uczelni}. 39 opr. Lech Banachowski, Jan Wierzbicki
Najlepiej, aby każda zależność funkcyjna określała pojedyńczy schemat tabeli. {Pacjent, Karta} {Karta, Adres} {Wpis, Karta, Choroba, Lekarz} 40 opr. Lech Banachowski, Jan Wierzbicki
Postać normalna Boyce’a-Codda Relacja o schemacie R znajduje się w postaci normalnej Boyce'a. Codda jeśli nie zawiera zależności nie od klucza tj. dla każdej zależności X -> A w schemacie relacji R (gdzie X podzbiór R, A atrybut w R) zachodzi albo 1. A należy do X (zależność trywialna), albo 2. X jest nadkluczem. Jeśli schemat relacji znajduje się w postaci normalnej Boyce'a. Codda, nie można w tabeli przewidzieć jednych wartości w oparciu o inne, chociaż jak to będzie pokazane dalej nie mamy gwarancji, że nie będzie innego rodzaju redundancji niż zależność funkcyjna. 41 opr. Lech Banachowski, Jan Wierzbicki
Przykłady schematów w postaci normalnej Boyce'a-Codda: (1) R = {Id_prac, Nazwisko, Funkcja, Stanowisko}, F: Id_prac -> Nazwisko Funkcja Stanowisko (2) R = {Numer, Skąd, Dokąd, Odlot, Przylot} F: Numer -> Skąd Dokąd Odlot Przylot Skąd Dokąd Odlot -> Numer Przylot Skąd Dokąd Przylot -> Numer Odlot 42 opr. Lech Banachowski, Jan Wierzbicki
Schemat nie dający się sprowadzić do postaci normalnej Boyce’a. Codda Nie każdy schemat tabeli da się sprowadzić do zbioru schematów tabel w postaci normalnej Boyce’a-Codda - bez utraty zawartych w tabelach informacji i z zachowaniem zależności funcyjnych. Na przykład schematem takim jest MUK = {Miasto, Ulica, Kod} z zależnościami: {Miasto, Ulica} -> Kod Kod -> Miasto Są dwa klucze: • {Miasto, Ulica} • {Kod, Ulica} 43 opr. Lech Banachowski, Jan Wierzbicki
Ze względu na zależność Kod -> Miasto schemat MUK nie jest w postaci normalnej Boyce'a-Codda. Tego schematu nie daje się rozłożyć z zachowaniem zależności funkcyjnych (bo jedna z zależności funkcyjnych obejmuje wszystkie atrybuty). Atrybut kluczowy jest to atrybut wchodzący w skład jednego z kluczy tabeli. 44 opr. Lech Banachowski, Jan Wierzbicki
Trzecia postać normalna Relacja o schemacie R znajduje się w trzeciej postaci normalnej jeśli wszystkie zależności nie od klucza są między atrybutami kluczowymi, tj. dla każdej zależności X -> A w schemacie relacji R (gdzie X podzbiór R, A atrybut w R) zachodzi albo 1. A należy do X (zależność trywialna), albo 2. X jest nadkluczem, albo 3. A jest atrybutem kluczowym. 45 opr. Lech Banachowski, Jan Wierzbicki
46 W trzeciej postaci normalnej wykluczony jest więc przypadek zależności: X -> A gdzie A jest atrybutem nie-kluczowym, X nie jest nadkluczem, X nie zawiera A. Takich więc zależności należy poszukiwać w celu przekształcenia schematu relacji według "złej" zależności na dwie relacje. Na przykład zależność funkcyjna "Kod -> Miasto" w schemacie MUK wskazuje, że schemat MUK nie jest w postaci normalnej Boyce’a-Codda ale jest w trzeciej postaci normalnej bo atrybut Miasto jest atrybutem kluczowym – należy do jednego z kluczy {Miasto, Ulica}. Natomiast następujący schemat R, nie jest w trzeciej postaci normalnej. R = {A, B, C, D}, F = AB -> C; B -> D; BC -> A Kluczami są AB i BC. Istnieje zależność B -> D a D nie opr. Lech Banachowski, Jan Wierzbicki jest atrybutem kluczowym.
Zależności wielowartościowe (czwarta postać normalna) Nr_stud 100 100 200 47 Przedmiot Sport Bazy danych Systemy informacyjne Bazy danych Tenis Biegi Boks opr. Lech Banachowski, Jan Wierzbicki
Schemat relacji jest w postaci normalnej Boyce’a-Codda bo jedynym kluczem są wszystkie trzy atrybuty) a w tabeli jest redundancja i możliwe są anomalie! W relacji R = {Nr_stud, Przedmiot, Sport} mamy do czynienia z tak zwanymi zależnościami wielowartościowymi: Nr_stud ->> Przedmiot; Nr_stud ->> Sport Schemat relacji jest w czwartej postaci normalnej jeśli nie ma w nim zależności wielowartościowych. Powyższy schemat R nie jest więc w czwartej postaci normalnej. Aby wyeliminować zależności wielowartościowe rozkładamy R na dwie relacje o schematach: {Nr_stud, Przedmiot} i {Nr_stud, Sport}. 48 opr. Lech Banachowski, Jan Wierzbicki
Zależności złączeniowe (piąta postać normalna) Zależność złączeniowa jest uogólnieniem zależności wielowartościowej w tym sensie, że jej eliminacja polega na rozbiciu relacji na więcej niż dwie relacje. Rozważmy relację między dostawcami, produktami i projektami. 49 Nazwa_dostawcy Nazwa_produktu Nazwa_projektu Kowalski Jankowski Misiak Stal Srebro Stal Papier Stal Srebro Wenus Mars Wenus Neptun opr. Lech Banachowski, Jan Wierzbicki
zasadę biznesową: jeśli (1) dostawca X dostarcza produkt Y, (2) dostawca X pracuje dla projektu Z, (3) projekt Z używa produktu Y to (4) dostawca X dostarcza produkt Y dla projektu Z. Przy tych zasadach zapis informacji w tabeli jest redundantny bo skoro (1) Kowalski jest dostawcą stali (dostarcza dla projektu Wenus), (2) Kowalski pracuje dla projektu Mars (dostarcza srebro), (3) projekt Mars używa stali (od dostawcy Jankowskiego) to redundantna jest już informacja, że: (4) Kowalski dostarcza stali dla projektu Mars (pokolorowany wiersz w tabelce). 50 opr. Lech Banachowski, Jan Wierzbicki
Rozwiązanie problemu eliminacji zależności złączeniowych Rozwiązaniem problemu jest podział relacji na trzy relacje: (1) Dostawcy-produkty, (2) Dostawcy-projekty, (3) Projekty-produkty. Podział na tylko dwie relacje jest niewystarczający! W relacjach (1)-(3) nie ma już redundancji, a ich złączenie daje wyjściową relację. Sytuacja uległaby zmianie gdybyśmy chcieli przechowywać informację o ilości zamówionych produktów w danym projekcie u konkretnego dostawcy. Wówczas rozbicie na trzy relacje nie byłoby możliwe. 51 opr. Lech Banachowski, Jan Wierzbicki
Granice normalizacji Normalizacji nie doprowadza się czasem do końca, np: (1) gdy stosuje się replikacje danych; (2) gdy funkcje na danych preferują nieznormalizowane schematy relacji np. gdy przy każdym wypisywaniu informacji o towarze załączamy także adres dostawcy. Jeśli tak postępujemy, to musimy się liczyć ze wszystkimi konsekwencjami pozostawienia nieznormalizowanej tabeli i dlatego wszystkie zależności nie od klucza muszą być sprawdzane przy każdej modyfikacji bazy danych i wszystkie pozostające anomalie muszą mieć przygotowane specjalne traktowanie (np. przy użyciu dodatkowych tabel do obsługi anomalii wstawiania i usuwania) 52 opr. Lech Banachowski, Jan Wierzbicki
W trakcie pracy nad modelem danych i schematem bazy danych projektant musi zwracać uwagę na wiele aspektów takich jak poprawność, istotność, pełność modelu danych, jak również na to aby schemat bazy danych nie prowadził do redundancji danych oraz anomalii przy wstawianiu, usuwaniu i aktualizacji danych. Są przypadki, kiedy dopuszcza się pewien stopień redundancji – ale jest to wówczas decyzja świadoma, której towarzyszą zabezpieczenia przed wystąpieniem anomalii przy wykonywaniu operacji na danych 53 opr. Lech Banachowski, Jan Wierzbicki
poprawność modelu danych - to co jest w modelu jest zgodne z rzeczywistością. istotność modelu danych - każdy element modelu jest istotny. pełność modelu danych - żaden element modelu danych - istotny dla funkcjonowania firmy (organizacji), nie został pominięty. normalizacja - każdy fakt przechowywany w bazie danych jest wyrażalny w niej tylko na jeden sposób. anomalie - tracenie informacji, podatność na brak spójności lub nie możliwość wykonania operacji na danych spowodowane złym schematem bazy danych. schemat relacji - lista atrybutów relacji. relacja - matematyczny obiekt (zbiór krotek) będący abstrakcją tabeli w relacyjnej bazie danych. krotka - matematyczny obiekt (odwzorowanie) będący abstrakcją wiersza w relacyjnej bazie danych. 54 opr. Lech Banachowski, Jan Wierzbicki
zależność funkcyjna - zależność wartości jednych atrybutów od innych. Oznaczenie X -> Y co czytamy X determinuje Y. nadklucz - zbiór atrybutów, których wartości jednoznacznie determinują wartości pozostałych atrybutów relacji. klucz - minimalny zbiór atrybutów, których wartości jednoznacznie determinują wartości pozostałych atrybutów relacji. zależność częściowa - zależność wartości atrybutu od części klucza. zależność przechodnia - zależność wartości atrybutu od czegokolwiek nieporównywalnego z kluczem. postać normalna Boyce’a-Codda - jedyną nietrywialną zależnością każdego atrybutu jest zależność od nadklucza. Inaczej mówiąc, oznacza brak zależności nie od klucza. postać normalna - trzecia - dopuszczona jest zależność atrybutu od części klucza o ile atrybut jest atrybutem kluczowym (należącym do jednego z kluczy relacji). 55 opr. Lech Banachowski, Jan Wierzbicki
Koniec wykładu V 56 opr. Lech Banachowski, Jan Wierzbicki
- Slides: 56