Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

1 L.Banachowski Projektowanie relacyjnych baz danych – postacie normalne Wyk ł ad 2.

Podobne prezentacje


Prezentacja na temat: "1 L.Banachowski Projektowanie relacyjnych baz danych – postacie normalne Wyk ł ad 2."— Zapis prezentacji:

1 1 L.Banachowski Projektowanie relacyjnych baz danych – postacie normalne Wyk ł ad 2

2 2 L.Banachowski Projektowanie schematu bazy danych Celem procesu projektowania schematu bazy danych jest: 1.wyspecyfikowanie wymagań użytkowników przyszłej bazy danych, dokonanie analizy tych wymagań; 2.utworzenie schematu bazy danych spełniającego wymagania użytkowników i jednocześnie gwarantującego poprawne funkcjonowanie bazy danych w ramach całego systemu informacyjnego, zaprojektowanie schematu bazy danych.

3 3 L.Banachowski Pośredni model - diagram związków encji ERD Ten pośredni model powinien w sposób jednoznaczny określać wymagania użytkowników - umożliwiając im sprawdzenie czy analityk systemu rzeczywiście dobrze zrozumiał ich intencje i specyfikę działania firmy. Ten pośredni model powinien być istotnie prostszy od schematu bazy danych, abstrahując od szczegółów implementacyjnych, które muszą być później opracowane przez projektanta bazy danych aby baza danych mogła powstać i spełniać postawione przed nią zadania.

4 4 L.Banachowski Przykłady związków trzy- argumentowych “student chodzi na ćwiczenia prowadzone przez asystenta” “pracownik pracuje w projekcie w roli” “towar jest sprowadzany od dostawcy do użycia w projekcie”

5 5 L.Banachowski Notacja Chena - MS Visio

6 6 L.Banachowski Reprezentowanie związku nie-jednoznacznego 1.Związek >2 argumentowy. 2.Związek binarny wieloznaczny. Metoda: Do reprezentowania takiego związku Z(E1,E2,…,En) używamy dodatkowej encji nazywanej asocjacyjną, którą łączymy związkami jednoznacznymi (encja asocjacyjna po stronie wiele tych związków) z encjami E1, E2,….,En.

7 7 L.Banachowski Reprezentacja związku 3- argumentowego między studentami, przedmiotami i asystentami (Notacja IDEF1X w MS Visio)

8 8 L.Banachowski Normalizacja bazy danych 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. W modelu firmy lotniczej (przykład rozważany w następnym punkcie) Pasa ż erowie i Personel to dwie odrębne encje. Jeśli jedna osoba będzie 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.

9 9 L.Banachowski Pożądane cechy modelu danych poprawność modelu; istotność każdego elementu modelu dla funkcjonowania firmy (organizacji); pełność modelu – to znaczy, gwarancja, że żaden element modelu danych - istotny dla funkcjonowania firmy (organizacji), nie został pominięty. Użytkownicy muszą: rozumieć tworzony model danych i po dokładnym przeanalizowaniu wszystkich szczegółów, biorąc za to odpowiedzialność, zaakceptować go. Projektant bazy danych dla tego modelu buduje bazę danych i aplikację bazy danych.

10 10 L.Banachowski Model relacyjnych baz danych W modelu relacyjnym przyjmuje się, że w tabeli w bazie danych kolejność wierszy i kolejność kolumn są nieistotne. Dwa wiersze zawierające te same wartości są uznawane za identyczne. 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 możliwych wiele różnych reprezentacji za pomocą tabel.

11 11 L.Banachowski Przykład relacji - Loty 83 Warszawa Moskwa 11:30 13:43 84 Moskwa Warszawa 15:00 17: Warszawa Nowy Jork 09:50 16: Warszawa Frankfurt 11:43 12: Frankfurt Warszawa 14:20 15: Nowy Jork Warszawa 18:12 07: Nowy Jork Frankfurt 22:00 09: Frankfurt Nowy Jork 13:20 19: Warszawa Tokio 18:00 09:10 Numer Sk ą d Dok ą d Odlot Przylot

12 12 L.Banachowski Schemat relacji R = {A 1, A 2,..., A n } gdzie A 1, A 2,...,A n są atrybutami (nazwami kolumn). Na przykład, Loty = {Numer, Sk ą d, Dok ą d, Odlot, Przylot}

13 13 L.Banachowski Dziedzina atrybutu Każdemu atrybutowi A przyporządkowana jest dziedzina Dom(A) czyli 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) = C HAR (5)

14 14 L.Banachowski Dziedzina relacji Dziedziną relacji o schemacie R = {A 1, A 2,..., A n } nazywamy sumę dziedzin wszystkich atrybutów relacji Dom(R) = Dom(A1)  Dom(A2) ...  Dom(An)

15 15 L.Banachowski Definicja relacji Relacja o schemacie R = {A 1, A 2,..., A n } jest to skończony zbiór r = {t 1, t 2,...,t m } odwzorowań t i : R  Dom(R) takich, że dla każdego j, 1 <= j <= n, t i (A j )  Dom(A j ) Każde takie odwzorowanie nazywa się krotką (lub wierszem).

16 16 L.Banachowski Krotka odpowiada wierszowi (rekordowi) w tabeli, 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 Przykład krotki (elementu relacji) 83 Warszawa Moskwa 11:30 13:43

17 17 L.Banachowski Operacja ograniczenia krotki Ograniczeniem krotki t relacji r o schemacie R do zbioru atrybutów X  R nazywamy odwzorowanie będące ograniczeniem krotki t do zbioru atrybutów X t |X : X  Dom(X) Na przykład, gdy X = { Sk ą d, Dok ą d }, t z poprzedniego przykładu to t |X (Sk ą d)='Warszawa', t |X (Dok ą d) = 'Moskwa'

18 18 L.Banachowski Zależność funkcyjna Relacja r o schemacie R = {A 1, A 2,..., A n } spełnia zależność funkcyjną X  Y (X, Y  R) jeśli dla każdych dwóch krotek t, u  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. Numer  {Sk ą d, Dok ą d, Odlot, Przylot}

19 19 L.Banachowski 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). Np. Numer  {Sk ą d, Dok ą d, Odlot, Przylot} {Sk ą d, Dok ą d, Odlot}  {Numer, Przylot} {Sk ą d, Dok ą d, Przylot}  {Numer, Odlot} alternatywna konwencja zapisu: Numer  Sk ą d Dok ą d Odlot Przylot Sk ą d Dok ą d Odlot  Numer Przylot

20 20 L.Banachowski Nadklucz relacji Nadklucz relacji r o schemacie R = {A 1, A 2,..., A n } - dowolny zbiór atrybutów X  R taki, że zachodzi zależność funkcyjna X  R tzn. wartość każdego atrybutu jest jednoznacznie zdeterminowana przez wartości atrybutów zbioru X. Jednym z nadkluczy jest zawsze zbiór wszystkich atrybutów R.

21 21 L.Banachowski Klucz relacji Klucz relacji r o schemacie R = {A 1, A 2,..., A n } - każdy minimalny nadklucz (nie zawierający żadnego 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 klucz, a może być ich więcej jak to pokazuje przykład relacji Loty.

22 22 L.Banachowski Klucze i klucz główny Zależności funkcyjne podane poprzednio określają trzy klucze: {Numer} {Sk ą d, Dok ą d, Odlot} {Sk ą d, Dok ą d, Przylot} Wyróżniony klucz nazywa się kluczem głównym. Wchodzące w jego skład atrybuty są podkreślane. Dla relacji Loty wybieramy jako klucz główny klucz Numer : Loty = {Numer, Sk ą d, Dok ą d, Odlot, Przylot}

23 23 L.Banachowski Dlaczego schemat jest zły? Nazwa_dostawcyAdres_dostawcyNazwa_towaruCena KowalskiAleja Postępu 102Modem1000 KowalskiAleja Postępu 102Wtyczka5 JaworskiUnii Europejskiej 34Kabel10 JaworskiUnii Europejskiej 34Telewizor1500 KowalskiAleja Postępu 102Komplet gier200 Marciniak…..……. Redundancja Anomalie przy modyfikacji Anomalie przy wstawianiu Anomalie przy usuwaniu

24 24 L.Banachowski Przyczyna trudności Mamy do czynienia ze złączeniem dwóch różnych rodzajów obiektów (encji), które byłoby lepiej określić jako osobne relacje: Dostawcy = {Nazwa_dostawcy, Adres_dostawcy} Towary = {Nazwa_dostawcy, Nazwa_towaru, Cena}

25 25 L.Banachowski Dlaczego schemat jest zły? Id_pracownikaNazwiskoNazwa_instytucjiAdres_instytucji 101KowalskiPJWSTKKoszykowa KalinowskiPJWSTKKoszykowa JaworskiUWBanacha 2 103MakowskiUWBanacha 2 105RudziakPJWSTKKoszykowa …..……. Redundancja Anomalie przy modyfikacji Anomalie przy wstawianiu Anomalie przy usuwaniu

26 26 L.Banachowski Przyczyna trudności Mamy do czynienia ze złączeniem dwóch różnych rodzajów obiektów (encji), które byłoby lepiej określić jako osobne relacje: Pracownicy={Id_prac,Nazwisko, Nazwa_instytucji} Instytucje={Nazwa_instytucji, Adres_instytucji } Przyczynę trudności można też wyjaśnić za pomocą pojęcia zależności funkcyjnej.

27 27 L.Banachowski Zależności od części klucza Dostawcy ={Nazwa_dostawcy,Adres_dostawcy,Nazwa_towaru,Cena} zależności funkcyjne: Nazwa_dostawcy  Adres_dostawcy Nazwa_dostawcy, Nazwa_towaru  Cena Kluczem jest para atrybutów: Nazwa_dostawcy, Nazwa_towaru. Pierwsza zależność jest zależnością od części klucza - tego typu zależności są przyczyną redundancji i anomalii!

28 28 L.Banachowski Zależności przechodnie od klucza Pracownicy={Id_prac,Nazwisko,Nazwa_instytucji, Adres_instytucji} zależności funkcyjne: Id_prac  Nazwisko, Nazwa_instytucji Nazwa_instytucji  Adres_instytucji Kluczem jest atrybut Id_prac. Druga zależność jest zależnością przechodnią od klucza - tego typu zależności są też przyczyną redundancji i anomalii!

29 29 L.Banachowski "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. Są dwa typy zależności nie od klucza: 1. zależności od części klucza, 2. zależności przechodni e od klucza.

30 30 L.Banachowski "Złe" zależności funkcyjne - zależności nie od klucza Zależność nie od klucza wprowadza wewnętrzną zależność między atrybutami relacji, możliwość przewidywania wartości jednych atrybutów przez inne, co oznacza redundancję i anomalie. Jedyną “zdrową” zależnością funkcyjną jest zależność od klucza. XY x x y ? ….. X  Y

31 31 L.Banachowski Metoda eliminacji zależności nie od klucza Metoda eliminacji zależności nie od klucza polega na wprowadzeniu dla niej osobnej relacji i usunięcie atrybutu stojącego po prawej stronie zależności nie od klucza z oryginalnego schematu relacji. Dla schematu dostawców: dodajemy schemat relacji {Nazwa_dostawcy, Adres_dostawcy} i usuwamy z oryginalnego schematu atrybut Adres_dostawcy otrzymując schemat {Nazwa_dostawcy, Nazwa_towaru, Cena}. Dla schematu pracowników: dodajemy schemat relacji {Nazwa_instytucji, Adres_instytucji} i usuwamy z oryginalnego schematu atrybut Adres_instytucji otrzymując schemat {Id_prac, Nazwisko, Nazwa_instytucji}.

32 32 L.Banachowski Postać normalna Boyce'a-Codda Dla każdej zależności w schemacie relacji X  A (X  R, A  R) zachodzi albo 1. A  X (zależność trywialna), albo 2. X jest nadkluczem. Jeśli schemat relacji znajduje się w postaci Boyce'a-Codda, nie ma redundancji - nie można przewidzieć jednych wartości w oparciu o inne.

33 33 L.Banachowski Przykłady 1.F = Id_prac  { Nazwisko,Funkcja,Stanowisko } - BC 2.F = Numer  {Sk ą d, Dok ą d, Odlot, Przylot} {Sk ą d, Dok ą d, Odlot}  {Numer, Przylot} {Sk ą d,Dok ą d,Przylot}  {Numer,Odlot} - BC 3.R = {M, U, K} (Miasto, Ulica, Kod) F = MU  K; K  M - nie BC Są dwa klucze MU i KU. Ze względu na zależność K  M schemat nie jest w postaci normalnej Boyce'a-Codda i nie da się go rozłożyć z zachowaniem zależności funkcyjnych.

34 34 L.Banachowski Trzecia postać normalna A jest atrybutem głównym (kluczowym) jeśli istnieje klucz K taki, że A  K; w przeciwnym przypadku A jest atrybutem niegłównym (niekluczowym). Trzecia postać normalna Dla każdej zależności w schemacie relacji X  A (X  R, A  R) zachodzi albo 1. A  X (zależność trywialna), albo 2. X jest nadkluczem, albo 3. A jest atrybutem głównym.

35 35 L.Banachowski Przykłady 1. R = {M,U,K}, ( Miasto, Ulica, Kod ) F = MU  K; K  M Dwa klucze MU i KU Schemat R jest w trzeciej postaci normalnej (gdyż M jest atrybutem głównym). 2. R = {A,B,C,D},F = AB  C; B  D; BC  A Kluczami są AB i BC. D jest atrybutem niegłównym. Schemat R nie jest w trzeciej postaci normalnej.

36 36 L.Banachowski Zależności wielowartościowe (czwarta postać normalna) Student (Nr_stud, Przedmiot, Sport) 100 Bazy danych Tenis 100 Bazy danych Pływanie 100 Assemblery Tenis 100 Assemblery Pływanie 200 Bazy danych Boks Schemat jest w postaci normalnej Boyce’a-Codda (jedynym kluczem są wszystkie trzy atrybuty) a w tabeli jest redundancja i możliwe są anomalie!

37 37 L.Banachowski Zależności wielowartościowe W relacji R = {Nr_stud, Przedmiot, Sport} mamy do czynienia z zależnościami wielowartościowymi: F = {Nr_stud  Kurs; Nr_stud  Sport} Aby je wyeliminować rozkładamy R na dwie relacje: {Nr_stud, Przedmiot} i {Nr_stud, Sport}.

38 38 L.Banachowski 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, częściami i projektami.

39 39 L.Banachowski Nazwa_dostNazwa_częściNazwa_projektu KowalskiŚrubkaWenus KowalskiNakrętkaMars KowalskiŚrubkaMars JankowskiŚrubkaMars JankowskiGwóźdźWenus JankowskiŚrubkaWenus MisiakNakrętkaNeptun

40 40 L.Banachowski Zasady biznesowe Załóżmy, ze zasady działania firmy określają, że jeśli (1) dostawca X dostarcza część Y, (2) dostawca X pracuje dla projektu Z, (3) projekt Z używa części Y to (4) dostawca X dostarcza część Y dla projektu Z.

41 41 L.Banachowski Przy tych zasadach zapis informacji w tabeli jest redundantny bo skoro (1) Kowalski jest dostawcą śrubek (dostarcza dla projektu Wenus), (2) Kowalski pracuje dla projektu Mars (dostarcza nakrętki), (3) projekt Mars używa śrubek (od dostawcy Jankowskiego) to redundantna jest już informacja, że: (4) Kowalski dostarcza śrubek dla projektu Mars.

42 42 L.Banachowski Rozwiązanie problemu Rozwiązaniem problemu jest podział relacji na trzy relacje: (1) Dostawcy-części, (2) Dostawcy-projekty, (3) Projekty-części. Podział na tylko dwie nie jest wystarczający! W relacjach (1)-(3) nie ma już redundancji, a ich złączenie daje wyjściową relację.

43 43 L.Banachowski Przy małej zmianie Sytuacja uległaby zmianie gdybyśmy chcieli przechowywać informację o ilości zamówionych części w danym projekcie u konkretnego dostawcy. Wówczas rozbicie na trzy relacje już nie byłoby możliwe.

44 44 L.Banachowski 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 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).


Pobierz ppt "1 L.Banachowski Projektowanie relacyjnych baz danych – postacie normalne Wyk ł ad 2."

Podobne prezentacje


Reklamy Google