Projektowanie baz danych

Transkrypt

1 Krzysztof Dembczyński Instytut Informatyki Zakład Inteligentnych Systemów Wspomagania Decyzji Politechnika Poznańska Technologie Wytwarzania Oprogramowania Semestr zimowy 2005/06

2 Plan wykładu Ewolucja systemów baz danych Relacyjne systemy baz danych i język SQL i ochrona danych Optymalizacja i struktury danych Systemy OLAP I Systemy OLAP II Modelowanie wielowymiarowe Proces ekstrakcji, transformacji i ładowania danych (Proces ETL)

3 Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

4 Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

5 Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

6 Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

7 Zależności funkcyjne Zależności funkcyjne sa ważnym pojęciem pozwalajacym na lepsze projetkowanie baz danych. Projektowanie bazy danych: Zamodelowanie procesów biznesowych przedsiębiorstwa Rozpoznanie danych Model przedsiębiorstwa Zdefiniowanie informacji potrzebnej użytkownikom końcowym Specyfikacja wymagań Opis potrzeb użytkowników Model abstrakcyjny systemu bazy danych Projekt koncepcyjny Modele danych Przeniesienie modelu abstrakcyjnego do SZBD Projekt logiczny Modele logiczne (obiektowe, relacyjne, itp.) Zdefiniowanie stuktur przechowywania danych i metod dostępu Projekt fizyczny Postać fizyczna systemu bazy danych

8 Zależności funkcyjne Definicja dla konkretnej chwili czasu Niech R będzie relacja, X i Y zaś dowolnymi podzbiorami zbioru atrybutów R. Mówimy, że Y jest funkcyjnie zależny od X: X Y (czytaj X funkcyjnie określa Y ) wtedy i tylko wtedy, gdy każda wartość X z R jest stowarzyszona z dokładnie jedna wartościa Y z relacji R Innymi słowy, ilekroć dwie krotki z R maja taka sama wartość X, maja również sama wartość Y.

9 Zależności funkcyjne Przykład relacji SCP S# CITY P# QTY S1 London P1 100 S1 London P2 100 S2 Paris P1 200 S2 Paris P2 200 S3 Paris P2 300 S4 London P2 400 S4 London P4 400 S4 London P5 400

10 Zależności funkcyjne Dla powyższej tablicy mamy następujace zależności funkcyjne: (S#) (CITY) (S#, P#) (QTY) (S#, P#) (CITY) (S#, P#) (CITY, QTY) (S#, P#) (S#) (S#, P#) (S#, P#, CITY, QTY) (S#) (QTY) (QTY) (S#) Niektóre z tych zależności zachodza przez cały czas

11 Zależność funkcyjna, która zachodzi przez cały czas jest warunkiem integralności relacji R, bowiem nakłada ograniczenia na wartości jakie w R moga wystapić. Definicja dla wszystkich możliwych wartości relacji Niech R będzie zmienna relacja, X i Y zaś dowolnymi podzbiorami zbioru atrybutów R. Mówimy, że Y jest funkcyjnie zależny od X: X Y (czytaj X funkcyjnie określa Y ) wtedy i tylko wtedy, gdy dla każdej dopuszczalnej wartości R każda wartość X z R jest stowarzyszona z dokładnie jedna wartościa Y. Innymi słowy, dla każdej dopuszczalnej wartości R ilekroć dwie krotki z R maja taka sama wartość X, maja również sama wartość Y.

12 Zależności funkcyjne Dla powyższej tablicy mamy następujace zależności funkcyjne występujace przez cały czas : (S#) (CITY) (S#, P#) (QTY) (S#, P#) (CITY) (S#, P#) (CITY, QTY) (S#, P#) (S#) (S#, P#) (S#, P#, CITY, QTY) Poniższe takie nie sa: (S#) (QTY) (QTY) (S#)

13 Klucz kandydujacy a zależność funkcyjna Definicja Jeżeli X jest kluczem kandydujacym relacji R to wszystkie atrybuty Y relacji R musza koniecznie zależeć funkcyjnie od X.

14 Zależności trywialne i nietrywialne Zależność jest trywialna wtedy i tylko wtedy, gdy prawa strona jest podzbiorem lewej strony, np: (S#, P#) (S#) Każda relacja musi spełniać zależność trywialna. Jak łatwo się domyśleć nietrywialne zależności, to wszystkie pozostałe. Lewostronnie nieredukowalne zależności, to takie dla których nie można odjać żadnego atrybutu występujacego po lewej strony, bez straty opisu zależności występujacych w relacji W teorii wyznacza się zbiory zależności, ich domknięcia, oraz tzw. nieredukowalne zbiory zelażności.

15 Reguły Amstronga Reguły wnioskowania Amstronga Niech A, B i C będa dowolnymi podzbiorami zbioru atrybutów danej relacji R i niech zapis AB oznacza sumę A i B. Wówczas zachodza zwiazki: Zwrotność Jeżeli B A, to A B, Dołaczanie Jeżeli A B, to AC BC, Przechodność Jeżeli A B i B C, to A C.

16 Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

17 Normalizacja Przykład rozszerzonej relacji SCP S# CITY P# QTY S1 London P1 300 S1 London P2 200 S1 London P3 400 S1 London P4 200 S1 London P5 100 S1 London P6 100 S2 Paris P1 300 S2 Paris P2 400 S3 Paris P2 200 S4 London P2 200 S4 London P4 300 S4 London P5 400

18 Postacie normale Pierwsza postać normalna (1NF) Druga postać normalna (2NF) Trzecia postać normalna (3NF) Postać normalna Boyce a-codd a (BCNF) Czwarta postać normalna (4NF) Piata postać normalna (5NF)

19 Normalizacja Projektant powinien dażyć do stworzenia projektu zawierajacego relacje w 3NF (lub lepiej BNCF) Procedura normalizacji pozwala na przeprowadzenie operacji przejście z jednej postaci do drugiej (przy czym ta druga jest ta bardziej oczekiwana) Procedura ta jest odwracalna.

20 Rozkład bezstratny(odwracalny) S S# STATUS CITY S3 30 Paris S5 30 Athens (a) SST S# STATUS S3 30 S5 30 SC S# CITY S3 Paris S5 Athens (b) SST S# STATUS S3 30 S5 30 STC STATUS CITY 30 Paris 30 Athens

21 Rozkład bezstratny(odwracalny) W przypadku (a) nie ma utraty informacji; po połaczeniu relacji SST i SC z powtorem otrzymay relację S w przypadku (b) informacja jest tracona, uzyskujemy wszystkie krotki wyjściowej relacji wraz z pewnymi zbędnymi krotkami Zauważmy, że w relacji S sa spełnione zależności funkcyjne z S# STATUS nieredukowalnego zbioru: S# CITY

22 Rozkład bezstratny(odwracalny) Twierdzenia Heatha Niech R{A, B, C} będzie relacja, zaś A, B i C zbiorami atrybutów. Jeżeli R spełnia zależność funkcyjna A B, wówczas relacja R jest równa złaczeniu swoich rzutów na {A, B} i {A, C}.

23 Pierwsza postać normalna Definicja Relacja występuje w pierwszej postaci normalnej 1NF wtedy i tylko wtedy, gdy wszystkie wyjściowe dziedziny zawieraja wyłacznie wartości skalarne.

24 Przykład rozszerzonej relacji ESCP S# STATUS CITY P# QTY S1 20 London P1 300 S1 20 London P2 200 S1 20 London P3 400 S1 20 London P4 200 S1 20 London P5 100 S1 20 London P6 100 S2 10 Paris P1 300 S2 10 Paris P2 400 S3 10 Paris P2 200 S4 20 London P2 200 S4 20 London P4 300 S4 20 London P5 400 Występujace zależności: (S#, P#) QTY S# CITY S# STATUS CITY STATUS

25 Normalizacja Występowanie nadmiarowych zależności prowadzi do wielu anomalii aktualizacji (czyli operacji INSERT, DELETE i UPDATE). Warto więc postarać zastapić relację ESCP dwoma innymi stosujac rozkład bezstratny.

26 (a) ESCT2 S# STATUS CITY S1 20 London S2 10 Paris S3 10 Paris S4 20 London S5 30 Athens (b) SP S# P# QTY S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200 S4 P2 200 S4 P4 300 S4 P5 400

27 Normalizacja Występujace zależności: S# CITY S# STATUS CITY STATUS (S#, P#) QTY

28 Druga postać normalna Definicja Relacja występuje w drugiej postaci normalnej 2NF wtedy i tylko wtedy, gdy juz jest w 1NF oraz każdy niekluczony atrybut jest nieredukowalnie zależny od klucza głównego. Relacja ESCP nie jest w 2NF. W drugiej postaci sa relacje ESCP2 oraz SP. Niestety cały czas nie jest to całkowicie poprawny projekt (relacja ESCP2)

29 (a) SC S# CITY S1 London S2 Paris S3 Paris S4 London S5 Athens Występujace zależności: (b) CS CITY STATUS Athens 30 London 20 Paris 10 Roma 50 S# CITY CITY STATUS W końcu poprawny projekt!!!

30 Trzecia postać normalna Definicja uproszczona Relacja jest w trzeciej postaci normalnej 3NF wtedy i tylko wtedy, gdy juz jest w 2NF oraz każdy niekluczony atrybut jest w sposób nieprzechodni zależny od klucza głównego.

31 Postać normalna Boyce a-codd a Definicja Relacja znajduje sie w BCNF wtedy i tylko wtedy, gdy jedynymi elementami determinujacymi (występujacymy po lewej stronie zależności) sa klucze kandydujace. Redukcja do postaci BCNF jest zawsze możliwa czyli dowolna relację można zastapić równoważnym zbiorem relacjiw BCNF. Celem takiej redukcji jest unikanie redundancji (nadmiarowości), co wiaże się z anomaliami aktualizacji.

32 Formalna definicja 3NF i BCNF Definicja Niech R będzie relacja, X dowolnym zbiorem atrybutów R, a A dowolnym jednym atrybutem z relacji R. Wówczas R jest w 3NF wtedy i tylko wtedy, gdy dla każdej zależności funkcyjnej X A z R jest spełniony przynajmniej jeden z warunków: X zawiera A (zależność jest trywialna), X zawiera klucz kandydujacy z R (czyli X jest kluczem nadrzędnym), A zawiera się w kluczu kandydujacym. Definicję BCNF otrzymujemy z powyższej definicji przez usunięcie ostatniego warunku.

33 Plan wykładu 1 Zależności funkcyjne 2 Normalizacja 3 Model zwiazków encji

34 Podstawowe definicje modelu zwiazków encji Encja rozróznialny obiekt (np. dostawca, część, dostawa, pracownik), Własność informacja opisujaca encję (np. numer dostawcy, nazwa części, wielkość dostawy, wzrost pracownika), Zwiazek Encja służaca do połaczenia dwóch lub więcej encji (np. dostawa: dostawca-części, zatrudnienie: pracownik-dział), Podtyp Encja typy Y jest podtypem encji typu X wtedy i tylko wtedy, gdy każdy Y jest też X (np. pracownik jest podtypem osoby).

35 Modelowanie Podstawowe kroki: Określenie zbioru pojęć: encji, zwiazków, typów, itd., Zdefiniowanie obiektów formalnych do reprezentacji powyższych pojęć, Określenie reguł integralności.

36 Encje Encje, czyli coś co można jednoznacznie zidentyfikować. Rozróżniamy encje regularne oraz słabe. Encja słaba to taka encja, której istnienie zależy od innej encji w tym sensie, że nie może ona istnieć, jeżeli ta inna encja też nie istnieje (np. krewni i pracownik).

37 Własności Encje posiadaja własności (czasami nazywane polami lub atrybutami). Własności moga być: proste i złożone, kluczowe, jedno- lub wielowartościowe, podstawowe lub pochodne.

38 Zwiazki Zwiazek to połaczenie między encjami, np. połaczenie między działem a pracownikiem. Zwiazek ten może zostać nazwany: zatrudnia, zatrudnienie, itd.. Zwiazki moga być: obowiazkowe oraz opcjonalne, jeden do jeden, jeden do wielu lub wiele do wiele, zwiazki moga być unarne, binarne, terarne itd..

39 Podtypy Każda encja ma przynajmniej jeden typ encji, jednak encja może należeć do kilku typów jednocześnie. Np. programista, może być też pracownikiem. Powstaje hierarchia typów.

40 Diagram zwiazków encji

41 Diagram zwiazków encji

42 Model zwiazków encji i projektowanie baz danych Encje regularne odwzorowywane sa na relacje podstawowe, czasem zapisuje się to następujaco: Pracownik(id_prac, imię, nazwisko,..., oddział). Zwiazki wiele do jeden sa reprezentowane przez klucze obce, tak jak powyżej, Zwiazki wiele do wiele zastępowane sa relacja: Dostawa(..., id_prac, id_cześć), Słabe encje sa zwiazane z silna encja zwiazkiem jeden do wiele, należy odpowiednio dobrać reguły klucza obcego: DELETE CASCADES, UPDATE CASCADES, Własności sa zamieniane na atrybuty o określonych atrybutach. Wyjatek stanowia własności złożone, Podtypy i nadtypy, np. Pracownik i Programista: Programista(id_prac,..., język programowania,... ).

43 Przykład Mały zakład produkcyjny Pracownicy sa zatrudnieni w różnych działach, przy czym jeden pracownik jest zatrudniony w jednym dziale. W bazie danych przechowujemy również informacje o najbliższych krewnych pracownika. Pracownicy uczestnicza w projektach, każdy projekt ma jednego szefa. Projekty wykorzystuja części dostarczane przez dostawców. Część może składać się z innych części.

44 Ogólna zasada projektowania Wykorzystaj podejście zwiazków encji badź inna metodykę z góry na dół do utworzenia poczatkowego projektu, Wykorzystaj zasady normalizacji do polepszanie otrzymanego projektu.

45 Plan wykładu Ewolucja systemów baz danych Relacyjne systemy baz danych i język SQL i ochrona danych Optymalizacja i struktury danych Systemy OLAP I Systemy OLAP II Modelowanie wielowymiarowe Proces ekstrakcji, transformacji i ładowania danych (Proces ETL)