W wykładzie jest rozważany problem jakości tworzonego schematu bazy danych i powiązany z nim
temat postaci normalnych relacji. Prezentacja materiału o postaciach normalnych
(w drugiej części tego wykładu) jest oparta na matematycznym modelu relacji i zależności
funkcyjnych - wymaga rozumienia pojęć matematyki dyskretnej takich jak zbiór,
odwzorowanie i relacja.
Następujące cechy modelu danych trzeba zapewnić na samym początku procesu projektowania, pozostając w ścisłym kontakcie z użytkownikami:
Po skonstruowaniu modelu danych:
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.
Przedstawienie normalizacji wymaga zastosowania formalnego, matematycznego
modelu relacji (w wersji uproszczonej zaprezentowanego w drugiej części tego
wykładu). Zasady normalizacji wprowadzimy najpierw przez przykłady
odwołując się do intuicji czytelnika.
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}
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 | Baterie | 5 |
Marciniak | Warszawska 140 | Magnetowid | 1000 |
Oto zestaw wad łatwych do zidentyfikowania w tym schemacie.
Redundancja: adres dostawcy powtarza się dla każdego dostarczanego towaru.
Anomalie przy modyfikacji: uaktualniony adres w jednym wierszu pozostaje niezmieniony w innych.
Anomalie przy wstawianiu: trudno wstawić dostawcę bez towarów; towar wchodzi w skład klucza - nie może być NULL.
Anomalie przy usuwaniu: usuwając
informacje o wszystkich towarach dostarczanych przez dostawcę (który może
zmienić profil produkcji) usuwamy informację o samym dostawcy.
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.
Przykład 2
Pracownicy = {Id_prac, Nazwisko, Nazwa_uczelni, Adres}
Id_prac |
Nazwisko | Nazwa_uczelni | Adres |
101 | Kowalski | PJWSTK | Koszykowa 86 |
123 | Kalinowski | WSI | Zamiany 15 |
109 | Jaworski | WSI | Zamiany 15 |
102 | Makowski | PJWSTK | Koszykowa 86 |
105 | Rudziak | WSI | Zamiany 15 |
Znowu możemy zaobserwować podobne wady jak poprzednio mimo, że tym razem klucz główny jest jednoelementowy.
Redundancja: adres uczelni powtarza się dla każdego zatrudnionego w niej pracownika.
Anomalie przy modyfikacji: uaktualniony adres uczelni w jednym wierszu pozostaje niezmieniony w innych.
Anomalie przy wstawianiu: trudno wstawić uczelnię bez pracownika; Id_prac stanowi klucz i nie może być NULL.
Anomalie przy usuwaniu: usuwając
wszystkich pracowników usuwamy uczelnię.
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.
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. Wskaż redundancje i anomalie wynikające z przyjęcia tego schematu. |
(1) Dla schematu tabeli
Dostawcy = {Nazwa_dostawcy, Adres, Nazwa_towaru, Cena}
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.
(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.
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.
Przykład relacji - Loty
Numer | Skąd | Dokąd | Odlot | Przylot |
83 | Warszawa | Moskwa | 11:30 | 13:43 |
84 | Moskwa | Warszawa | 15:00 | 17:55 |
109 | Warszawa | Nowy Jork | 09:50 | 16:52 |
213 | Warszawa | Frankfurt | 11:43 | 12:45 |
214 | Frankfurt | Warszawa | 14:20 | 15:29 |
115 | Nowy Jork | Warszawa | 18:12 | 07:10 |
515 | Nowy Jork | Frankfurt | 22:00 | 09:15 |
516 | Frankfurt | Nowy Jork | 13:20 | 19:15 |
711 | Warszawa | Tokio | 18:00 | 09:10 |
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 = {A1, A2, ...., An}gdzie A1, A2, ...., 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}
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)
Dziedzina relacji
Dziedziną relacji o schemacie R = {A1, A2,..., An} nazywamy sumę dziedzin wszystkich atrybutów relacji
Dom(R) = Dom(A1) + Dom(A2) + .. +
Dom(An)
gdzie + oznacza tutaj operację sumowania zbiorów.
Relacją o schemacie R = {A1, A2,..., An} nazywamy skończony zbiór
r = {t1, t2,...,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).
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",Graficznie:
t(Odlot) = "11:30", t(Przylot) = "13:43"
Numer | Skąd | Dokąd | Odlot | Przylot |
83 | Warszawa | Moskwa | 11:30 | 13:43 |
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 |
Relacja r o schemacie R = {A1, A2,..., 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}
Prześledźmy jeszcze jeden przykład relacji z zależnościami funkcyjnymi między jej atrybutami mianowicie relację Znaki Zodiaku o schemacie {Id, Imię, Nazwisko, DzienUrodzenia, ZnakZodiaku}.
Id |
Imię | Nazwisko | DzienUrodzenia | ZnakZodiaku |
1 | Agnieszka | Kowalska | 23.01 | Wodnik |
2 | Mariusz | Malewicz | 1.04 | Baran |
3 | Krzysztof | Zalewski | 23.04 | Byk |
4 | Ilona | Zawadzka | 13.04 | Baran |
5 | Marek | Walicki | 31.07 | Lew |
6 | Roman | Gerlich | 5.09 | Panna |
7 | Sylwia | Frymus | 13.04 | Baran |
Mamy do czynienia z zależnością funkcyjną
DzieńUrodzenia ->
ZnakZodiaku
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 -> ZnakZodiaku
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.
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
Nadkluczem relacji r o schemacie R = {A1, A2,...,
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.
Klucz relacji
Kluczem relacji r o schemacie R = {A1, A2,...,
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}
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}
Zachęcamy teraz czytelnika do kontynuowania pracy nad schematem Przychodnia.
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. Jakie zależności funkcyjne występują w rozważanym schemacie? Co jest kluczem w tym schemacie? Czy jest więcej niż jeden klucz? |
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:
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.
"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
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)
Dany jest schemat Przychodnia = {Pacjent, Choroba, Lekarz, Karta, Wpis, Adres}.
Dla tego schematu zidentyfikowaliśmy następujące zależności funkcyjne:
Jedynym kluczem jest para atrybutów: Pacjent i Wpis. Jakiego rodzaju są zidentyfikowane zależności funkcyjne? |
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}.
(2) Dla schematu pracowników dodajemy schemat tabeli {Nazwa_uczelni, Adres} i usuwamy z oryginalnego schematu atrybut Adres: {Id_prac, Nazwisko, Nazwa_uczelni}.
W ten sposób zależności funkcyjne dyktują, jakie powinny być tabele w schemacie bazy danych. Najlepiej, aby każda zależność funkcyjna określała pojedynczy schemat tabeli.
Używając metody eliminacji przekształć schemat Przychodnia na poprawne schematy relacji. |
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.
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
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}
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.
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.
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. |
Brak "złych" zależności funkcyjnych nie gwarantuje jeszcze braku
redundancji i anomalii. Zilustrujemy jeszcze dwa rodzaje zależności:
wielowartościowe i złączeniowe, których istnienie implikuje redundancje i
anomalie. Pominiemy dokładne definicje ograniczając się do
przykładów.
Zależności wielowartościowe (czwarta postać normalna)
Nr_stud |
Przedmiot | Sport |
100 | Bazy danych | Tenis |
100 | Bazy danych | Biegi |
100 | Systemy informacyjne | Tenis |
100 | Systemy informacyjne | Biegi |
200 | Bazy danych | Boks |
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}.
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.
Nazwa_dostawcy |
Nazwa_produktu | Nazwa_projektu |
Kowalski | Stal | Wenus |
Kowalski | Srebro | Mars |
Kowalski | Stal | Mars |
Jankowski | Stal | Mars |
Jankowski | Papier | Wenus |
Jankowski | Stal | Wenus |
Misiak | Srebro | Neptun |
Przyjmijmy następującą 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).
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.
Normalizacji nie doprowadza się czasem do końca, 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).
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.
Został zaprezentowany (w wersji skróconej) materiał teoretyczny wyjaśniający
podstawy normalizacji oparte na pojęciu zależności
funkcyjnej między atrybutami relacji. Zostały zdefiniowane:
trzecia postać normalna, postać normalna Boyce’a-Codda oraz zasygnalizowane:
czwarta postać
normalna, piąta postać normalna – gwarantujące, że opracowywany schemat
bazy danych jest wolny od redundancji i anomalii związanych z zależnościami
funkcyjnymi, wielowartościowymi i złączeniowymi.
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.
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).
1. Dany jest schemat relacji
R = {Makler, Biuro, Akcjonariusz, Kapitał, Akcje, Dywidenda
}
ze zbiorem zależności funkcyjnych: Kapitał -> Dywidenda;
Akcjonariusz -> Makler;
Akcjonariusz Kapitał -> Akcje;
Makler -> Biuro
· Wyjaśnij redundancje i anomalie występujące w powyższym schemacie.
· Czy zachodzi zależność funkcyjna:
Akcjonariusz Dywidenda -> Biuro?
· Znajdź wszystkie klucze.
· Sprowadź schemat do trzeciej postaci normalnej (z zachowaniem zależności funkcyjnych i informacji).
· Czy otrzymane schematy relacji są wszystkie w postaci normalnej Boyce'a-Codda? Czy pozostały jakieś redundancje i anomalie?
2. W poradniku hodowcy strusi zaproponowano bazę danych, która składa się z jednej tabeli o następującym schemacie:
R ={Nr_strusiarni, Liczba_strusi, Imię_strusia, Płeć_strusia, Wiek_strusia, Opiekun_strusiarni,
Nazwisko_opiekuna, Imię_opiekuna
}
Zachodzą następujące zależności funkcyjne:Nr_strusiarni -> Liczba_strusi
Nr_strusiarni -> Opiekun_strusiarni
Imię_strusia Nr_strusiarni -> Płeć_strusia
Imię_strusia Nr_strusiarni -> Wiek_strusia
Opiekun_strusiarni -> Nazwisko_opiekuna Imię_opiekuna
Wytłumacz zaprzyjaźnionemu hodowcy strusi, dlaczego baza ta jest nienajlepsza i wskaż schemat poprawnej bazy danych, w której można przechowywać te same informacje.
Strona przygotowana przez Lecha Banachowskiego - 12/13/03 .