Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Bazy danych 3. Zale ż no ś ci funkcyjne Postaci normalne P. F. Góra semestr letni 2006/07.

Podobne prezentacje


Prezentacja na temat: "Bazy danych 3. Zale ż no ś ci funkcyjne Postaci normalne P. F. Góra semestr letni 2006/07."— Zapis prezentacji:

1 Bazy danych 3. Zale ż no ś ci funkcyjne Postaci normalne P. F. Góra semestr letni 2006/07

2 Bazy danych - wykład 32 W bardzo sformalizowanych wyk ł adach baz danych jest to jedno z najwa ż niejszych zagadnie ń. W wyk ł adach (kursach) pisania kodu w SQL jest to zagadnienie ca ł kowicie pomijane. Proste (kilkutabelowe) bazy mo ż na z powodzeniem projektowa ć (i optymalizowa ć ) bez znajomo ś ci tego tematu. Z ł o ż onych baz bez tego zaprojektowa ć si ę praktycznie nie da.

3 Bazy danych - wykład 33 Definicja zale ż no ś ci funkcyjnej Je ś li dwie krotki pewnej tabeli (relacji) s ą zgodne w atrybutach A 1, A 2, …A n, to musz ą by ć zgodne w pewnym innym atrybucie B. Zapisujemy to A 1, A 2, …A n B

4 Bazy danych - wykład 34 A B

5 Bazy danych - wykład 35 PESEL Nazwisko

6 Bazy danych - wykład 36 Zale ż no ś ci funkcyjne s ą matematycznym modelem wi ę zów jednoznaczno ś ci w modelu relacyjnym baz danych. Zale ż no ś ci funkcyjne nale żą do schematu bazy. Nie mo ż na o nich wnioskowa ć jedynie na podstawie instancji (faktycznych wyst ą pie ń ) tabel. Je ż eli zachodzi A 1, A 2,…,A n B 1,…, A 1, A 2,…, A n B m p iszemy w skrócie A 1, A 2,…, A n B 1,…, B m

7 Bazy danych - wykład 37 Przyk ł ad W u ż ywanym w podr ę czniku przyk ł adzie tabeli Filmy wyst ę puj ą nast ę puj ą ce zale ż no ś ci funkcyjne: tytuł rok długość tytuł rok TypFilmu tytuł rok NazwaStudia Jednak na przyk ł ad zdanie tytuł rok NazwiskoGwiazdy jest fa ł szywe: w jedym filmie, identyfikowanym przez zbiór atrybutów {tytu ł, rok}, mo ż e wyst ę powa ć wiele gwiazd.

8 Bazy danych - wykład 38 Regu ł y dotycz ą ce zale ż no ś ci funkcyjnych Przyk ł ad: Za ł ó ż my, ż e w pewnej tabeli z atrybutami A, B, C zachodz ą zale ż no ś ci funkcyjne A B, B C. Wnioskujemy s ą d, i ż zachodz tak ż e A C. Dowód: Niech dwie krotki zgodne dla A maj ą posta ć (a,b 1,c 1 ), (a,b 2,c 2 ). Poniewa ż zachodzi A B, krotki zgodne dla A musz ą by ć te ż zgodne dla B, a zatem b 1 = b 2. Krotki maj ą wi ę c posta ć (a,b,c 1 ), (a,b,c 2 ). Poniewa ż zachodzi B C, musi by ć spe ł nione c 1 = c 2, co ko ń czy dowód. Jest to przyk ł ad regu ł y przechodnio ś ci.

9 Bazy danych - wykład 39 Zale ż no ś ci trywialne Zale ż no ść nazywam trywialn ą, je ś li atrybut B jest równy któremu ś atrybutowi A. Je ś li przyjmiemy skrótowy zapis zale ż no ś ci z wielocz ł onow ą praw ą stron ą, zale ż no ść jest –Trywialna, je ś li zbiór z ł o ż ony z atrybutów B jest podzbiorem zbioru z ł o ż onego z atrybutów A –Nietrywialna, je ś li co najmniej jeden B nie jest A –Ca ł kowicie nietrywialna, je ś li ż adnen B nie jest A.

10 Bazy danych - wykład 310 Regu ł y wnioskowania (aksjomaty Armstronga) 1.Zwrotno ść : Je ż eli {B 1,B 2,…,B m } {A 1,A 2,…A n }, to A 1 A 2 …A n B 1 B 2 …B m 2.Rozszerzenie: Je ż eli A 1 A 2 …A n B 1 B 2 …B m, to A 1 A 2 …A n C 1 C 2 …C k B 1 B 2 …B m C 1 C 2 …C k dla dowolnych C 1 C 2 …C k. 3.Przechodnio ść : Je ż eli A 1 A 2 …A n B 1 B 2 …B m oraz B 1 B 2 …B m C 1 C 2 …C k, to A 1 A 2 …A n C 1 C 2 …C k. Zale ż no ś ci trywialne

11 Bazy danych - wykład 311 Domkni ę cia Niech {A 1, A 2, …A n } b ę dzie pewnym zbiorem atrybutów, S niech b ę dzie zbiorem zale ż no ś ci funkcyjnych. Domkni ę ciem zbioru {A 1, A 2, …A n } nad S nazywamy taki zbiór atrybutów B, ż e je ś li jego elementy spe ł niaj ą wszystkie zale ż no ś ci funkcyjne z S, to spe ł niaj ą tak ż e zale ż no ść A 1 A 2 …A n B, a zatem zale ż no ść A 1 A 2 …A n B wynika z S. Domkni ę cie oznaczam cl {A 1, A 2, …A n }.

12 Bazy danych - wykład 312 Mówi ą c niezbyt ś ci ś le, domkni ę cie to zbiór wszystkich atrybutów determinowanych, w sensie zale ż no ś ci funkcyjnych, przez atrybuty zbioru wyj ś ciowego. Ściśle było na poprzednim ekranie

13 Bazy danych - wykład 313 Algorytm obliczania domkni ę cia 1.Na pocz ą tku X oznacza zbiór {A 1,A 2,…,A n }. 2.Znajdujemy wszystkie zale ż no ś ci funkcyjne postaci B 1 B 2 …B m C, gdzie B i nale żą do X, a C nie nale ż y. Do łą czamy C do X. 3.Powtarzamy krok 2 tak d ł ugo, jak długo do X nie mo ż na do łą czy ć ż adnego nowego atrybutu. Poniewa ż X mo ż e si ę tylko rozszerza ć, za ś zbiór atrybutów jest sko ń czony, po sko ń czonej ilo ś ci kroków nast ą pi moment, w którym do X nie da si ę niczego do łą czy ć. 4.X=cl {A 1,A 2,…,A n }.

14 Bazy danych - wykład 314 Przykład (najprostszy) Dane mamy atrybuty A, B, C, D i zbiór zależności funkcyjnych (zbiór S) następującej postaci: B C, AB D. Ile wynosi cl({B}) nad podanym zbiorem zależności funkcyjnych? Na początku X ={B}. Na podstawie zależności B C, do zbioru X dołączam atrybut C. X={B,C}. W podanym zbiorze zależności funkcyjnych nie ma żadnej innej zależności, której poprzednik obejmowałby elementy zbioru X, a więc nie ma sposobu, aby do X coś jeszcze dołączyć. Ostatecznie cl({B})={B,C}.

15 Bazy danych - wykład 315 Caveat emptor! Powy ż ej przedstawiony algorytm jest poprawny i intuicyjnie prosty, ale nie jest efektywny – mo ż e by ć algorytmem kwadratowym (w czasie) w najgorszym przypadku. Znacznie rozs ą dniej jest tak uporz ą dkowa ć zale ż no ś ci funkcyjne, aby ka ż da by ł a u ż ywana (odpalana) dok ł adnie w tym momencie, w którym wszystkie atrybuty jej lewej strony znajd ą si ę w kandydacie X. Dla du ż ych baz (i tabel) domkni ęć nie oblicza si ę r ę cznie, ale komputerowo!

16 Bazy danych - wykład 316 Przyk ł ad: Rozwa ż my zbiór atrybutów {A, B, C, D, E, F}. Za ł ó ż my, ż e w tym zbiorze zachodz ą zale ż no ś ci AB C, BC AD,D E, CF B. Obliczmy cl{A,B}. X={A,B}. Wszystkie atrybuty zale ż no ś ci AB C s ą w X, wi ę c do X do łą czamy C. X={A,B,C}. Lewa strona zale ż no ś ci BC AD jest w X, A jest ju ż w X, wi ę c do X do łą czamy D. X={A,B,C,D}. Na mocy zale ż no ś ci D E, do łą czamy do X atrybut E. X={A,B,C,D,E}. Zle ż no ś ci CF B nie mo ż emy zastosowa ć, poniewa ż F X i nie ma jak F do X do ł o ż y ć. Ostatecznie cl{A,B} = {A,B,C,D,E}.

17 Bazy danych - wykład 317 Bazy relacji Ka ż dy zbiór zale ż no ś ci funkcyjnych pewnego zbioru atrybutów, z którego mo ż na wyprowadzi ć wszystkie inne zale ż no ś ci funkcyjne zachodz ą ce pomi ę dzy elementami tego zbioru, nazywam baz ą relacji. Je ś li ż aden podzbiór bazy nie jest baz ą (nie umo ż liwia wyprowadzenia wszystkich relacji), baz ę t ę nazywam baz ą minimaln ą. Przyk ł ad: Mam atrybuty A,B,C i zale ż no ś ci A B, A C, B A, B C, C A, C B. Mo ż na teraz wyprowadzi ć zale ż no ś ci nietrywialne AB C, AC B, BC A (oraz zale ż no ś ci trywialne). Baz ą minimaln ą jest zbiór {A B, B A, B C, C B} Inn ą baz ą minimaln ą jest {A B, B C, C A}

18 Bazy danych - wykład 318 Po co jemy t ę ż ab ę ?!

19 Bazy danych - wykład 319 Klucze relacji (tabeli) Mówimy, ż e zbiór atrybutów {A 1,A 2,…,A n } tworzy klucz tabeli, je ś li 1.Wszystkie pozosta ł e atrybuty s ą funkcyjnie zale ż ne od tych atrybutów, a zatem dwie ró ż ne krotki nie mog ą by ć zgodne dla atrybutów A 1,A 2,…,A n. 2.Nie istnieje taki podzbiów w ł a ś ciwy zbioru {A 1,A 2,…,A n }, od którego pozosta ł e atrybuty s ą zale ż ne funkcyjnie.

20 Bazy danych - wykład 320 Nadzbiór klucza nazywa si ę nadkluczem. Terminologia alternatywna: Nadklucz nazywa si ę kluczem. To, co na poprzednim ekranie by ł o nazwane kluczem, nazywa si ę kluczem minimalnym.

21 Bazy danych - wykład 321 Zauwa ż my, ż e zbiór cl{A 1,A 2,…,A n } zawiera wszystkie atrybuty pewnej tabeli R wtedy i tylko wtedy, gdy elementy A 1,A 2,…,A n s ą nadkluczem R. Stwierdzenie, czy zbiór {A 1,A 2,…,A n } stanowi klucz tabeli (klucz minimalny w terminologii alternatywnej), polega na 1.Sprawdzeniu, czy wszystkie atrybuty R nale żą do cl {A 1,A 2,…,A n }. 2.Sprawdzenie, czy domkni ę cie zbioru powsta ł ego przez usuni ę cie cho ć by jednego elementu A i nie zawiera wszystkich atrybutów R.

22 Bazy danych - wykład 322 Ż aba s ł u ż y zatem jako formalne narz ę dzie do identyfikowania kluczy. Identyfikacja kluczy jest elementem niezb ę dnym przy normalizacji bazy danych. Bez formalnego zastosowania mechanizmu relacji funkcyjnych i domkni ęć, normalizacja du ż ych baz jest praktycznie niemo ż liwa.

23 Bazy danych - wykład 323 Cel normalizacji baz danych – unikanie anomalii Rodzaje anomalii 1.Redundancja 2.Anomalie modyfikacji 3.Anomalie usuwania Te same dane niepotrzebnie powtarzaj ą si ę w kilku krotkach Warto ść tej samej danej zostanie zmodyfikowana w jednej krotce, w innej za ś nie. Która warto ść jest wówczas poprawna? Utrata cz ęś ci danych, gdy dla pewnego atrybutu zacznie obowi ą zywa ć warto ść pusta (null) Odwrotno ść : anomalie do łą czania

24 Bazy danych - wykład 324 Pierwsza postać normalna: Tabele zawieraj ą wy łą cznie dane atomowe. Ka ż da tabela ma klucz. Zakaz duplikowania wierszy. Tabela jest zbiorem wierszy.

25 Bazy danych - wykład 325 Problem: Jednemu numerowi zamówienia odpowiada zbiór identyfikatorów cz ęś ci

26 Bazy danych - wykład 326 Tabela w 1PN podzielone niektóre wiersze.

27 Bazy danych - wykład 327 Nie jest w 1PN Jest w 1PN podzielone niektóre kolumny

28 Bazy danych - wykład 328 Druga postać normalna: Tabela jest w 1PN. Ka ż dy atrybut niekluczowy zale ż y funkcyjnie od pe ł nego klucza. Od pe ł nego klucza, a nie tylko od podzbioru w ł a ś ciwego klucza. Ka ż da tabela, której wszystkie klucze s ą jednokolumnowe, jest w 2PN. Kontynuujemy konsumpcj ę p ł azów

29 Bazy danych - wykład 329 Nie jest w 2PN: nazwa dostawcy adres, id dostawcy; nazwa cz ęś ci id cz ęś ci Anomalie: 1.Redundancja: adres Seagate w czterech (sic!) krotkach. 2.Anomalia modyfikacji: Je ś li Seagate zmieni siedzib ę, czy na pewno poprawimy to we wszystkich miejscach? 3.Anomalia usuwania: Je ś li usuniemy zamówienie nr 002, stracimy informacj ę o siedzibie Toshiby. 4.Anomalia do łą czania: Nie da si ę do łą czy ć nowej firmy, dopóki nie z ł o ż ymy w niej zamówienia.

30 Bazy danych - wykład 330 Sprowadzenie do 2PN: podzia ł tabeli

31 Bazy danych - wykład 331 Trzecia postać normalna: Tabela jest w 2PN. Je ś li A 1 A 2 …A n B, to albo {A 1,A 2,…,A n } jest nadkluczem, albo B jest elementem pewnego klucza. Dotyczy tylko zale ż no ś ci nietrywialnych!

32 Bazy danych - wykład 332 Trzecia posta ć normalna jest postaci ą najcz ęś ciej wyst ę puj ą c ą w praktyce. Istniej ą specjalne algorytmy i specjalne narz ę dzia CASE do przeprojektowywania bazy do 3PN. W specjalistycznych zastosowaniach (np. hurtownie danych) niekiedy korzystnie jest pozostawi ć baz ę w 2PN lub nawet 1PN.

33 Bazy danych - wykład 333 Cz ę sto mówi si ę, ż e 3PN wyklucza zale ż no ś ci przechodnie (typu A B, B C, zatem A C). Je ś li jednak C jest elementem klucza (by ć mo ż e obejmuj ą cego jakie ś atrybuty A), to dalej jest 3PN. Przyk ł ad: Tabela z trzema atrybutami i zale ż no ś ciami kino miasto tytuł miasto kino Kluczem jest { tytuł, miasto }. Innym kluczem jest { kino, tytuł }. Tabela jest w 3PN: chocia ż samo kino nie jest nadkluczem, miasto jest elementem klucza. Zwanego kluczem kandyduj ą cym. Bo ka ż de kino jest w jakim ś mie ś cie. Bo dystrybutor ogranicza rozpowszechnianie do jednego kina w danym mie ś cie.

34 Bazy danych - wykład 334 Procedura post ę powania: 1.Dany jest zbiór atrybutów, które chcemy reprezentowa ć, i zbiór zale ż no ś ci funkcyjnych pomi ę dzy atrybutami. 2.Znajdujemy baz ę minimaln ą (bazy minimalne) zbioru zale ż no ś ci funkcyjnych. Eliminujemy symetryczne zale ż no ś ci funkcyjne. 3.Dla (pewnej) bazy minimalnej sumujemy zale ż no ś ci funkcyjne o takich samych lewych stronach i dla ka ż dej wysumowanej zale ż no ś ci tworzymy tabel ę z odpowiedni ą lew ą stron ą zale ż no ś ci jako kluczem.

35 Bazy danych - wykład 335 Procedura szukania bazy minimalnej: 1.Ka ż dy atrybut musi wyst ę powa ć z lewej lub z prawej strony jednej zale ż no ś ci funkcyjnej w zbiorze. 2.Je ś li jaka ś zale ż no ść funkcyjna jest w łą czona do zbioru, nie wszystkie zale ż no ś ci funkcyjne potrzebne do jej wyprowadzenia mog ą wyst ę powa ć w tym zbiorze. 3.Je ś li jaka ś zale ż no ść funkcyjna zostaje wy łą czona ze zbioru, zale ż no ś ci funkcyjne potrzebne do jej wyprowadzenia musz ą zosta ć do ń do łą czone.

36 Bazy danych - wykład 336 Je ś li mamy wiele atrybutów i wiele zale ż no ś ci, normalizacji r ę cznie przeprowadzi ć si ę nie da. Powy ż sza procedura jest dostosowana do projektowania od zera. Je ś li mamy wst ę pny projekt w postaci diagramu E/R, projektowanie jest znacznie prostsze.

37 Bazy danych - wykład 337 Przyk ł ad Firma transportowa posiada baz ę danych, w której zachodz ą nast ę puj ą ce zale ż no ś ci funkcyjne: NrRejestracyjny Data Kierowca NrRejestracyjny Data Odbiorca Odbiorca Odległość Kierowca Stawka Odległość Stawka Koszt Odbiorca Kierowca Koszt NrRejestracyjny Data Koszt

38 Bazy danych - wykład 338 Tabele: (NrRejestracyjny, Data, Kierowca, Odbiorca) (Kierowca, Stawka) (Odbiorca, Odległość) (Odległość, Stawka, Koszt)

39 Bazy danych - wykład 339 Postać normalna Boycea-Coda (BCNF, PNBC) Tabela jest w BCNF wtedy i tylko wtedy, gdy dla ka ż dej zale ż no ś ci nietrywialnej A 1 A 2 …A n B, zbiór {A 1,A 2,…,A n } jest nadkluczem

40 Bazy danych - wykład 340 U ż ywa si ę tak ż e wy ż szych postaci normalnych (czwartej, pi ą tej i szóstej), ale nie b ę d ą one omawiane na tym wyk ł adzie. Wy ż sze postaci normalne s ą potrzebne, ale do bardzo wielu zastosowa ń praktycznych postaci trzecia i BCNF wystarczaj ą. Niekiedy wygodniej jest u ż ywa ć ni ż szych postaci normalnych, drugiej i pierwszej.

41 Bazy danych - wykład 341 Bezstratne złączenia Normalizacja ma na celu unikanie redundancji i innych anomalii. Trzeba jednak by ć ostro ż nym: Powstaj ą ce tabele musz ą zapewnia ć bezstratno ść z łą cze ń – tak, aby informacja nie zosta ł a utracona.

42 Bazy danych - wykład 342 Dekompozycj ę tabeli R na tabele R 1, R 2, …, R n nazywamy dekompozycj ą bezstratnego z łą czenia (ze wzgl ę du na pewien zbiór relacji funkcyjnych), je ś li naturalne z łą czenie R 1, R 2, …, R n jest równe tabeli R. Formalną definicję złączenia poznamy później

43 Bazy danych - wykład 343 Dekompozycja tabeli R na dwie tabele R 1, R 2 jest dekompozycj ą bezstratnego z łą czenia, je ś li spe ł niony jest jeden z dwu warunków: (R 1 R 2 ) (R 1 -R 2 ) lub (R 1 R 2 ) (R 2 -R 1 ) Innymi s ł owy, wspólna cz ęść atrybutów R 1, R 2 musi zawiera ć klucz kandyduj ą cy R 1 lub R 2

44 Bazy danych - wykład 344 Przykład negatywny Dana jest tabela Zapisy(NrStudenta,NrKursu,DataZapisu,Sala,Prowadzący) Przyk ł adowa instancja mo ż e wygl ą da ć tak: NrStudentaNrKursuDataZapisuSalaProwadzący K A1Góra K A1Oramus K A1Góra K C1Oramus K C2Bogacz

45 Bazy danych - wykład 345 Rozbijamy tabel ę Zapisy na dwie tabele: Z1(NrStudenta,NrKursu,DataZapisu) Z2(DataZapisu,Sala,Prowadzący) NrStudentaNrKursuDataZapisu K K K K K DataZapisuSalaProwadzący A1Góra A1Oramus A1Góra C1Oramus C2Bogacz To jest do ść kiepski podzia ł : DataZapisu nie jest kluczem kandyduj ą cym Instancje tych tabel wygl ą daj ą tak:

46 Bazy danych - wykład 346 Chcemy si ę dowiedzie ć jakich studentów naucza Góra. W tym celu robimy z łą czenie Z1 Z2 Wspóln ą kolumn ą obu tabel jest DataZapisu Dostajemy NrStudentaNrKursuDataZapisuSalaProwadzący K A1Góra K A1Góra K C1Góra etc Zaznaczone krotki s ą fa ł szywe – nie wyst ę puj ą w pierwotnej tabeli. Zaproponowana dekompozycja spowodowa ł a, ż e po wykonaniu z łą czenia tracimy informacj ę o tym, kto kogo naucza.

47 Bazy danych - wykład 347 Uwaga! Przeprowadzając normalizację, staramy się zachować trzy warunki: 1.BCNF 2.Zachowanie zależności funkcyjnych 3.Bezstratne złączenia Czy zawsze da się to zrobić?

48 Bazy danych - wykład 348 Rozwa ż my tabel ę T(A, B, C) z nast ę puj ą cymi relacjami funkcyjnymi: C A AB C Tabela ta nie jest w postaci BCNF, gdy ż C nie jest nadkluczem. Na przyk ł ad: A – nazwa banku B – nazwisko klienta C – nazwisko bankiera

49 Bazy danych - wykład 349 Próbujemy nast ę puj ą cej dekompozycji: T 1 (A,C) T 2 (B,C) Ta dekompozycja nie zachowuje relacji AB C i nie jest dekompozycj ą bezstratnego z łą czenia W naszym przyk ł adzie by ł oby to T 1 (NazwaBanku,NazwiskoBankiera) T 2 (NazwiskoKlienta,NazwiskoBankiera)

50 Bazy danych - wykład 350 Jak wida ć, nie zawsze udaje si ę przeprowadzi ć normalizacj ę do postaci BCNF tak, aby zachowa ć komplet relacji funkcyjnych i aby dekompozycja pozwala ł a na bezstratne z łą czenia. W takiej sytuacji rezygnujemy z postaci BCNF, zadowalaj ą c si ę jak ąś ni ż sz ą postaci ą normaln ą i dopuszczaj ą c pewne anomalie. Zachowanie kompletu zale ż no ś ci funkcyjnych oraz bezstratno ść z łą cze ń musz ą mie ć priorytet!


Pobierz ppt "Bazy danych 3. Zale ż no ś ci funkcyjne Postaci normalne P. F. Góra semestr letni 2006/07."

Podobne prezentacje


Reklamy Google