Bazy danych 1. Wykład 6 Metodologia projektowania baz danych. (projektowanie logiczne - Normalizacja)

Transkrypt

1 Bazy danych 1 Wykład 6 Metodologia projektowania baz danych (projektowanie logiczne - Normalizacja)

2 Projektowanie logiczne przegląd krok po kroku 1. Usuń własności niekompatybilne z modelem relacyjnym 2. Wyznacz relacje dla logicznego modelu danych 3. Wykonaj normalizację relacji 4. Sprawdź, czy relacje umoŝliwiają realizacje transakcji. 5. Wyznacz więzy integralności. 6. Omów logiczny model danych z uŝytkownikiem.

3 Projektowanie logiczne (krok 2 - przypomnienie) 2. Wyznacz relacje dla logicznego modelu danych Relacje będziemy opisywać za pomocą języka definiowania bazy danych DDL (DataBase Definition Language) Definicja (uproszczona) relacji w DDL zawiera: nazwę relacji (w liczbie mnogiej), ujętą w nawiasy listę prostych atrybutów relacji, klucz główny, wszystkie klucze alternatywne i obce, nazwę relacji zawierającą wskazany klucz obcy jako klucz główny listę atrybutów pochodnych wraz z wyraŝeniami definiującymi sposób wyliczenia ich wartości.

4 Projektowanie logiczne (krok 2 - przypomnienie) 1. Dla kaŝdej encji tworzymy schemat relacji (reprezentacją relacji jest tabela). Najczęściej nazwa relacji jest taka sama jak nazwa encji, tylko w liczbie mnogiej ze względu na to, ze relacja zawiera wiele wystąpień obiektu. 2. Atrybuty encji stają się atrybutami w schemacie relacji. Atrybuty odpowiadające kluczom głównym stają się kluczami głównymi relacji. Atrybuty opcjonalne stają się kolumnami o dopuszczalnych wartościach NULL, atrybuty obligatoryjne stają się kolumnami NOT NULL. 3. Sposób tworzenia kluczy obcych zaleŝy od liczności (krotności) oraz uczestnictwa encji w związku.

5 Projektowanie logiczne (krok 2 - przypomnienie) 1. W przypadku związków jeden do jeden najczęściej tworzymy jedną relację zawierająca atrybuty obu encji 2. W przypadku związków jeden do wiele najczęściej do schematu do schematu po stronie wiele wstawiamy jako dodatkowy atrybut klucz główny z relacji po stronie jeden. 3. W przypadku związków wiele do wiele związek ten reprezentujemy dodatkową relacją, który zawiera dwa klucze obce związek reprezentujemy dodatkową relacją, który zawiera dwa klucze obce klucze główne z relacji po obu stronach związku (oraz atrybuty związku).

6 Normalizacja (krok 3) Aby uniknąć w bazie redundancji (powtórzeń) i związanych z nią anomalii róŝnego typu, przeprowadza się normalizacje relacji wchodzących w skład bazy. 6

7 ZaleŜność funkcyjna Niech R będzie schematem relacji i X,Y R Definicja Zbiór Y jest w zaleŝności funkcyjnej względem zbioru X (X Y) wtw, gdy dla kaŝdej relacji o schemacie R wartości atrybutów ze zbioru X jednoznacznie wyznaczają wartości atrybutów ze zbioru Y. 7

8 ZaleŜność funkcyjna - przykład Niech schemat relacji R określa rozkład zajęć w szkole. Ma on następujące atrybuty: N (nauczyciel),g (godzina),s (sala),k (klasa),p (przedmiot). KaŜda z krotek relacji r oznacza, Ŝe: Nauczyciel N wykładający przedmiot P prowadzi zajęcia o godzinie G w sali S z klasą K Dla tego schematu określamy następujące zaleŝności funkcyjne: dany nauczyciel o danej godzinie prowadzi zajęcia tylko z jedną klasą - NG K o danej godzinie w danej sali znajduje się tylko jeden nauczyciel - GS N 8

9 ZaleŜność funkcyjna Sformułowanie zaleŝności funkcyjnych oznacza ustalenie pewnych związków między atrybutami odzwierciedlających związki między odpowiednimi obiektami w świecie rzeczywistym. Wybór zaleŝności funkcyjnych nie pozostaje bez wpływu na organizację danych. Np.. ustalenie zaleŝności N P oznacza, Ŝe Ŝaden nauczyciel nie będzie mógł wykładać kilku przedmiotów. 9

10 Klucz relacji Definicja Zbiór atrybutów X tworzy klucz, gdy: wszystkie pozostałe atrybuty są funkcyjnie zaleŝne od atrybutów X; jest to minimalny taki zbiór, tzn. nie istnieje podzbiór właściwy zbioru X wyznaczający funkcyjnie pozostałe atrybuty relacji. 10

11 Klucz relacji Niech F będzie zbiorem zaleŝności funkcyjnych dla schematu relacji R. Definicja ZaleŜność funkcyjna X Y wynika logicznie ze zbioru zaleŝności F (F = X Y), jeśli kaŝda relacja o schemacie R spełniająca wszystkie zaleŝności funkcyjne z F spełnia równieŝ zaleŝność X Y. 11

12 Domknięcie zbioru zaleŝności Definicja Domknięciem F + zbioru F zaleŝności funkcyjnych dla schematu relacji R nazywamy zbiór wszystkich zaleŝności funkcyjnych wynikających logicznie ze zbioru F. 12

13 ZaleŜności trywialne Definicja ZaleŜność funkcyjna X Y jest trywialna, gdy Y X, nietrywialna, gdy Y X i Y X, 13

14 Rozkład schematu relacji ZaleŜność od klucza jest jedyną zdrową zaleŝnością funkcyjną i najlepiej by było, Ŝeby kaŝda relacja reprezentowała tylko jedną taką zaleŝność funkcyjną. ZaleŜność nie od klucza wprowadza wewnętrzną zaleŝność między atrybutami, moŝliwość przewidywania wartości jednych atrybutów przez inne, co oznacza redundancję. Usunięcie z relacji anomalii i redundancji odbywa się poprzez podział (rozkład) relacji na kilka nowych. 14

15 Rozkład schematu relacji Definicja Rozkładem schematu relacji R nazywamy rodzinę {R i } i {1,...,k} podzbiorów R taką, Ŝe R=R 1... R k. Krotki relacji o schemacie R i otrzymujemy poprzez rzutowanie relacji o schemacie R na zbiór atrybutów R i : r i = Π Ri (r) Rozkład schematu nie moŝe być byle jaki, powinien on być poprawny, tzn. zachowywać informację i zaleŝności funkcyjne wyjściowego schematu.

16 Rozkład odwracalny (bezstratny) Definicja Rozkład R=Q S jest odwracalny względem F wtw gdy kaŝda relacja o schemacie R i spełniająca zaleŝności z F jest złączeniem naturalnym swoich rzutów na Q i S 16

17 Rozkład zachowujący zaleŝności funkcyjne Definicja Rozkład R=Q S zachowuje zbiór zaleŝności F, jeśli wszystkie zaleŝności naleŝące do F wynikają logicznie z sumy wszystkich zaleŝności naleŝących do rzutów zbioru F na Q i S. 17

18 Postacie normalne Pojęcie postaci normalnej wprowadził Codd. Zaproponował on trzy postacie normalne: pierwszą (1NF), drugą (2NF) i trzecią (3NF). Kolejnymi postaciami normalnymi są postać normalna Boyce a-codda (BCNF), czwarta postać normalne (4NF) i złączeniowa postać normalna (5NF). Najczęściej najbardziej poŝądaną jest postać normalna Boyce a-codda. 18

19 Postać Boyce a-codda Definicja Schemat relacji jest w BCNF wtw, gdy dla kaŝdej zaleŝności X A F + zachodzi jeden z przypadków: A X (czyli jest to zaleŝność trywialna) X jest nadkluczem Jeśli schemat jest w BCNF, nie ma redundancji, tzn. nie moŝna przewidzieć jednych wartości w oparciu o inne. 19

20 Postać Boyce a-codda Przykład. Niech R = {M (miasto), U (ulica), K (kod)} i F = {MU K, K M}. Schemat nie jest w BCNF, gdyŝ są dwa klucze: {M, U} i {K, U} i nie są spełnione warunki definicji dla zaleŝności K M (K nie jest nadkluczem). Twierdzenie KaŜdy schemat albo jest w BCNF albo daje się rozłoŝyć na sumę schematów relacji w BCNF z zachowaniem informacji (ale niekoniecznie z zachowaniem zaleŝności). 20

21 Trzecia postać normalna Definicja Schemat relacji jest w 3NF wtw, gdy dla kaŝdej zaleŝności X A F + zachodzi jeden z przypadków: A X (zaleŝność trywialna), X jest nadkluczem, A jest atrybutem kluczowym (naleŝy do co najmniej jednego klucza). 21

22 Trzecia postać normalna Uwaga: Schemat relacji w BCNF jest w 3NF, ale nie odwrotnie Przykład. Niech R = {M (miasto), U (ulica), K (kod)} i F = {MU K, K M}. Są dwa klucze: {M,U} i {K,U}. Schemat jest w 3NF ({M, U} jest nadkluczem a M jest atrybutem kluczowym). Twierdzenie KaŜdy schemat relacji daje się rozłoŝyć na sumę schematów relacji w 3NF z zachowaniem informacji i zaleŝności funkcyjnych. 22

23 Druga postać normalna Definicja ZaleŜność funkcyjna X A jest zaleŝnością częściową, gdy X jest właściwym podzbiorem pewnego klucza. Definicja ZaleŜność funkcyjna X A jest zaleŝnością przechodnią, gdy X nie jest właściwym podzbiorem Ŝadnego klucza. Definicja Schemat relacji jest w 2NF wtw, gdy nie zawiera zaleŝności częściowych. 23

24 Druga postać normalna Przykład. Schemat relacji w BCNF i 3NF jest w 2NF. Przykład. Niech R={A, B, C, D} i F={AB C, AC D}. Jedynym kluczem jest {A, B}. Schemat nie jest w 3NF (D nie jest atrybutem kluczowym). W schemacie nie ma zaleŝności częściowych. Schemat jest w 2NF. W schemacie istnieje zaleŝność przechodnia: AC D. Przykład. Niech R={A, B, C, D} i F={AB C, B D, BC A}. Jedynymi kluczami są {A, B} i {B, C}. D jest atrybutem niekluczowym i {B} jest podzbiorem właściwym klucza, więc zaleŝność B D jest zaleŝnością częściową. Schemat nie jest w 2NF. Twierdzenie Schemat relacji jest w 3NF wtw, gdy jest w 2NF i nie zawiera zaleŝności przechodnich. 24

25 Pierwsza postać normalna Definicja Schemat relacji jest w 1NF wtw, gdy jego atrybuty przyjmują wartości atomowe (wartości atrybutów nie są zbiorami). 25

26 Postacie normalne - przykład Hodowca zaproponował następujący schemat bazy danych: Hodowle (Nr_strusiarni, Liczba_strusi, Imię_strusia, Płeć_strusia, Wiek_strusia,Opiekun_strusiarni, Nazwisko_opiekuna, Imię_opiekuna) 1. Nr_strusiarni Liczba_strusi 2. Nr_strusiarni Opiekun_strusiarni 3. Imię_strusia, Nr_strusiarni Płeć_Strusia 4. Imię_strusia, Nr_strusiarni Wiek_Strusia 5. Opiekun_strusiarni Nazwisko_opiekuna, Imię_opiekuna

27 Normalizacja (krok 3) Projekt logiczny (po wykonaniu normalizacji) nie musi być projektem ostatecznym. Jeśli wymagają tego kryteria dotyczące wydajności, projekt fizyczny moŝe się róŝnić od logicznego jedną z moŝliwości jest denormalizacja niektórych relacji. Normalizacja słuŝy udoskonaleniu modelu danych tak, aby spełniał szereg warunków pozwalających uniknąć duplikowania danych, dzięki normalizacji model lepiej odwzorowuje informacje modelowanego przedsiębiorstwa, staje się spójny, zapewnia minimum redundancji i maksimum stabilności.

28 Realizacja transakcji (krok 4) Sprawdź, czy relacje umoŝliwiają realizacje transakcji Celem tego kroku jest sprawdzenie, czy logiczny model danych umoŝliwia wykonanie transakcji opisanych w specyfikacji wymagań uŝytkownika. W kroku tym próbujemy wykonać manualnie poszczególne operacje zawarte w transakcjach, korzystając z relacji, powiązań między kluczami głównymi i obcymi relacji.

29 Więzy integralności (krok 5) Wyznacz więzy integralności Więzy integralności to dodatkowe warunki, których spełnienie zapobiega niespójności bazy danych. Na tym etapie koncentrujemy się na wysokopoziomowym opisie specyfikującym, jakie więzy integralności powinny być spełnione, niezaleŝnie od tego, w jaki sposób zapewniona będzie ich realizacja. Po ustaleniu więzów integralności logiczny model danych moŝna uznać za kompletna reprezentacje rzeczywistości.

30 Więzy integralności RozwaŜamy pięć typów więzów integralności: wymagana obecność danych niektóre atrybuty nie powinny zawierać wartości pustych; więzy tego typu powinny być ustalone na etapie dokumentowania informacji o atrybutach w słowniku danych. więzy dziedzin atrybutów z kaŝdym atrybutem związana jest dziedzina, czyli zbiór dopuszczalnych wartości; wiązy tego typu naleŝy ustalić wraz z wyborem dziedzin atrybutów. integralność encji klucz główny encji nie moŝe przyjmować wartości pustych; ograniczenie to naleŝy uwzględnić przy wyborze klucza głównego dla danego zbioru encji.

31 Więzy integralności więzy ogólne są nazywane regułami biznesowymi (lub zasadami działania); reguły te wynikają z zasad obowiązujących w opisywanym przez nie fragmencie świata rzeczywistego, np. Promotor moŝe prowadzić 10 prac dyplomowych studentów integralność referencyjna klucz obcy wiąŝe krotkę relacji podrzędnej z krotką relacji nadrzędnej o pasującej wartości klucza kandydującego; integralność referencyjna oznacza, Ŝe jeśli wartość klucza obcego jest określona, to wartość ta musi odpowiadać istniejącej krotce w relacji nadrzędnej.

32 Więzy integralności Integralność referencyjna Przykład: Personel Nr_Pracownika <pk> Zarządza Nieruchomość Nr_Nieruchomosci Nr_Pracownika <pk> <fk> Atrybut Nr_Pracownika w relacji Nieruchomość wiąŝe nieruchomość do wynajęcia z krotką w relacji Personel zawierającą dane pracownika zarządzającego daną nieruchomością. Jeśli wartość Nr_Pracownika (w relacji Nieruchomość) jest określona, to powinna ona zawierać poprawny numer pracownika, występujący jako wartość Nr_Pracownika w relacji Personel.

33 Więzy integralności Integralność referencyjna Pierwszym problemem jest kwestia, czy dozwolone są wartości puste klucza obcego. W przypadku opcjonalnego uczestnictwa relacji podrzędnej wartości puste są dozwolone, np. dopuszczamy moŝliwość przechowywania informacji o nieruchomości do wynajęcia bez podania pracownika zarządzającego tą nieruchomością W przypadku obowiązkowego uczestnictwa relacji podrzędnej wartości puste nie są dozwolone, np. nie dopuszczamy moŝliwości przechowywania informacji o nieruchomości do wynajęcia bez podania pracownika zarządzającego tą nieruchomością

34 Więzy integralności Integralność referencyjna Kolejnym problemem jest sposób zapewnienia integralności referencyjnej. Operacje na bazie danych mogą naruszyć więzy referencyjne. Przypadek 1. Wstawienie krotki do relacji podrzędnej dla zachowania integralności referencyjnej konieczne jest sprawdzenie, czy klucz obcy w relacji podrzędnej ma wartość pusta lub jest równy wartości występującej w jednej z krotek relacji nadrzędnej Przypadek 2. Usunięcie krotki z relacji podrzędnej nie narusza integralności referencyjnej Przypadek 3. Modyfikacja klucza obcego krotki w relacji podrzędnej sytuacja podobna do przypadku 1

35 Więzy integralności Integralność referencyjna Przypadek 4. Wstawienie krotki do relacji nadrzędnej nie narusza integralności referencyjnej Przypadek 5. Usunięcie krotki z relacji nadrzędnej moŝe naruszyć integralność referencyjną w przypadku, gdy w relacji podrzędnej występuje krotka wskazującą na usuniętą krotkę nadrzędną (patrz dalej) Przypadek 6. Modyfikacja klucza głównego krotki nadrzędnej - moŝe naruszyć integralność referencyjną w przypadku, gdy w relacji podrzędnej występuje krotka wskazującą na wartość klucza głównego sprzed modyfikacji (patrz dalej)

36 Więzy integralności Integralność referencyjna W przypadku 5 i 6 moŝna wybrać kilka moŝliwości: NO ACTION lub RESTRICT - uniemoŝliwia usunięcie (modyfikację) krotki z relacji nadrzędnej jeśli występują jakiekolwiek krotki od niej zaleŝne. CASCADE usunięcie (modyfikacja) krotki nadrzędnej pociąga za sobą usunięcie (modyfikację) wszystkich związanych z nią krotek podrzędnych; jeśli krotka podrzędna pełni rolę nadrzędną w innym związku, analogiczna operacja usuwania (modyfikacji) powinna być wykonana dla krotek podrzędnych tego związku. SET NULL usunięcie krotki nadrzędnej pociąga za soną automatyczne nadanie wartości pustych odpowiednim kluczom obcym wszystkich krotek SET DEFAULT usunięcie krotki nadrzędnej pociąga za soną automatyczne nadanie wartości domyślnych odpowiednim kluczom obcym wszystkich krotek podrzędnych.

37 Nieruchomość( nieruchomośćnr NumerNieruchomości NOT NULL ulica Ulica NOT NULL miasto Miasto NOT NULL typ TypNieruchomości NOT NULL DEFAULT F pokoje NieruchomośćPokoje NOT NULL DEFAULT 4 czynsz NieruchomośćCzynsz NOT NULL DEFAULT 600 właścicielnr NumerWłaściciela NOT NULL pracowniknr NumerPracownika NOT NULL biuronr NumerBiura NOT NULL kaucja NieruchomośćCzynsz NOT NULL PRIMARY KEY (nieruchomośćnr) ALTERNATE KEY (ulica, miasto) FOREIGN KEY (pracowniknr) REFERENCES Personel(pracownikNr) ON UPDATE CASCADE ON DELETE SET NULL FOREIGN KEY (właścicielnr) REFERENCES WłaścicielPrywatny(właścicielNr) and WłaścicielInstytucjonalny(właścicielNr) ON UPDATE CASCADE ON DELETE NO ACTION DERIVED kaucja (czynsz*0,1)

38 Dziękuj kuję za uwagę!!!