030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

Transkrypt

1 030 PROJEKTOWANIE BAZ DANYCH Prof. dr hab. Marek Wisła

2 Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty, związki Więzy integralności

3 Zagrożenia - Anomalie Anomalia dołączania (wstawiania) nie można dołączyć krotki, nie znamy wszystkich danych, które krotka musi zawierać. Anomalia aktualizacji (modyfikacji) te same dane muszą być zmieniane w wielu miejscach. Anomalia usuwania usunięcie krotki powoduje niepożądane usunięcie innych, istotnych danych.

4 Normalizacja relacji Normalizacja to jeden z etapów projektowania relacyjnej bazy danych. Celem normalizacji jest usunięcie redundancji (powtarzania się tych samych danych, nadmiaru danych) i wyeliminowanie anomalii.

5 Pierwsza postać normalna 1NF Relacja jest w pierwszej postaci normalnej (1NF), jeżeli wartości atrybutów są atomowe (niepodzielne).

6 Funkcyjna zależność atrybutów Zbiór atrybutów Y jest funkcyjnie zależny od zbioru atrybutów X, co zapisujemy X Y, wtedy i tylko wtedy, gdy dla dwóch dowolnych krotek r, s takich, że r[x] = s[x], zachodzi zawsze r Y = s[y]. Przykład: Atrybut Y=Płaca jest funkcyjnie zależny od X=Stanowisko.

7 Funkcyjna zależność od klucza Każdy atrybut jest funkcyjnie zależny od klucza relacji, który jest unikalny. Rzeczywiście, jeśli K jest kluczem relacji, to dla każdych krotek r, s równość r K = s[k] implikuje, że r = s, a stąd r[a] = s[a] dla każdego atrybutu A.

8 Pełna funkcyjna zależność Zbiór atrybutów Y jest w pełni funkcyjnie zależny od zbioru atrybutów X, jeżeli X Y i nie istnieje podzbiór Z X taki, że Z Y..

9 Druga postać normalna 2NF Relacja jest w drugiej postaci normalnej (2NF), jeżeli każdy jej atrybut wtórny (tzn. nie należący do klucza relacji) jest w pełni funkcyjnie zależny od klucza głównego tej relacji. W szczególności klucz główny relacji w 2NF jest optymalny (nie można zmniejszyć liczby jego atrybutów). Każda relacja, która ma klucz główny jednoelementowy, jest zawsze w 2NF.

10 Przechodnia funkcyjna zależność Zbiór atrybutów Y jest przechodnio funkcyjnie zależny od zbioru atrybutów X, jeżeli X Y i istnieje zbiór atrybutów Z, nie będący podzbiorem żadnego klucza relacji taki, że zachodzi X Z i Z Y.

11 Przykład przechodniej funkcyjnej zależności ID pracownika Stanowisko Płaca

12 Trzecia postać normalna 3NF Relacja jest w trzeciej postaci normalnej (3NF), jeżeli jest w drugiej postaci normalnej i żaden atrybut wtórny nie jest przechodnio funkcyjnie zależny od klucza głównego tej relacji.

13 Projektowanie bazy danych Projektowanie relacyjnej bazy danych ma na celu: określenie, jakie tabele, a w nich jakie wiersze i kolumny będą występowały w bazie danych oraz jakie będą powiązania pomiędzy tabelami; określenie, jakie operacje będą wykonywane na danych i jakie będą skutki tych operacji tak, aby zachować integralność danych;

14 Projektowanie baz danych

15 Model ER (Entity-Relationship) Model ER opisuje dziedzinę przedmiotową za pomocą pojęć: encja (entity) (jednostka, obiekt) - reprezentuje byt (a w zasadzie typ takiego bytu ) ze świata rzeczywistego (obiekty materialne i niematerialne, zdarzenia i fakty); atrybut (attribute) określa szczegółowe właściwości (cechy) encji; związek (relationship) - reprezentuje powiązania między encjami.

16 Notacja Chena Do nieformalnego przedstawienia projektu bazy danych możemy wykorzystać model ER zaproponowany przez Petera P. Chena w 1976 r.

17 Inne notacje

18 Model ER Projekt ma postać graficzną zwaną diagramem związków encji lub ERD (Entity Relationship Diagram). Atrybuty tworzące klucz główny encji wyróżnia się przez podkreślenie. Istnieje procedura (pół)automatycznej transformacji diagramu ER do konkretnej implementacji, np. do relacyjnej bazy danych.

19 Przykład ERD

20 Przykład diagramu ERD

21 Przykład diagramu ERD

22 Związki Związek obrazuje powiązania między dwoma encjami (związek binarny) lub większą liczbą encji (związki wieloczłonowe). Związek może posiadać atrybuty. związki mogą być rekurencyjne (cykliczne).

23 Związki Opisując związek należy określić: role uczestniczących w nim encji charakter uczestnictwa encji: obowiązkowy (obligatoryjny), opcjonalny liczebność, tj. wartość mówiącą, ilu reprezentantów danej encji może jednocześnie uczestniczyć w związku: zero lub (opcjonalny) dokładnie jeden 1(obligatoryjny) zero lub wiele 0..N, 0.. (opcjonalny) jeden lub wiele N, 1..N, 1.. (obligatoryjny) liczebność określamy dla każdej encji uczestniczącej w związku

24 Związki jedno-jednoznaczne 1-1 Ten typ związku występuje rzadko i nie jest pożądany Pary encji pozostające w takim związku należy połączyć w jedną encję dodając atrybuty jednej z nich do drugiej.

25 Związki jednoznaczne 1-N lub N-1 Najczęściej spotykany i pożądany typ związku. Związek jest reprezentowany za pomocą klucza głównego encji po stronie jeden, umieszczanego jako atrybut encji po stronie wiele. Tak utworzony atrybut encji po stronie wiele tworzący referencję, nosi nazwę klucza obcego (foreign key) Jeżeli związek posiada atrybuty, to dołączamy je do encji po stronie wiele.

26 Związki rekurencyjne (cykliczne) Związek ma miejsce dla różnych obiektów tej samej encji Związek jest reprezentowany za pomocą klucza głównego encji po stronie jeden, umieszczanego jako dodatkowy atrybut tej samej encji po stronie wiele. Przykład: tabela Pracownicy (ID_Prac,, Szef)

27 Związki wieloznaczne N-N Związek wieloznaczny nie jest pożądany - może być łatwo usunięty przez utworzenie nowej encji i zastąpienie związku wieloznacznego dwoma związkami jednoznacznymi Nowo utworzona encja działa jako łącznik dla związku wieloznacznego i znajduje się po stronie wiele dla obu nowych związków Para atrybutów tworzących referencje do encji po stronach jeden tworzy klucz główny nowo utworzonej encji, a każdy z tych atrybutów osobno jest jednocześnie kluczem obcym w tej encji Jeżeli związek posiadał atrybuty, to dołączamy je do nowo utworzonej encji.

28 Związki wieloznaczne N-N Przykład

29 Związki wieloczłonowe (n-arne) Przykład:

30 Przekształcenie w związki 1-N Egzaminy (IdEgz, Przedmiot, IdWykł, NrIndeksu, Data, Ocena) IdEgz jest kluczem własnym w tabeli Egzaminy Przedmiot, IdWykł, NrIndeksu są kluczami obcymi w tabeli Egzaminy

31 Encje słabe Encją słabą nazywamy encję, dla której istnienie jej obiektów jest uzależnione od istnienia obiektów innej encji. Np. istnienie obiektu encji Dziecko w bazie danych o pracownikach ma sens, gdy istnieje obiekt encji Pracownik, będący rodzicem dziecka. Encje słabe nie mają własnego atrybutu kluczowego. Ich obiekty są identyfikowane za pomocą kombinacji wartości wyróżnionego atrybutu (tzw. klucza częściowego) i wartości klucza encji właściciela, np. (IdPrac, Imię).

32 Specjalizacja - generalizacja Specjalizacja: definiowanie zbioru encji podklas na podstawie encji nadklasy. Generalizacja: definiowanie ogólnej encji nadklasy na podstawie istniejącego zbioru encji, które automatycznie stają się encjami podklas. Specjalizacja może być rozłączna lub nakładająca się. Specjalizacja może być pełna lub częściowa.

33 Specjalizacja Samochody (NrRej, Marka, Model, Typ) Osobowe (NrRej, LiczMiejsc) Ciężarowe (NrRej, Ładown) Generalizacja Samochody (NrRej, Marka, Model, Typ, LiczMiejsc, Ładown)

34 Więzy integralności Więzy integralności to wymagania, które winny być spełnione przez określony podzbiór danych z bazy. Określają one warunki spójności powiązań, np.: unikalność klucza encji (klucz nie może zawierać wartości NULL), zawężenie dziedziny atrybutu do wartości dopuszczalnych (np. NOT NULL) zależności między wartościami atrybutów (w danym wierszu), odpowiedni format wartości atrybutu (np. nr telefonu, kod, ISBN) zależności pomiędzy wartościami danego atrybutu, a wartościami tego atrybutu w innych wierszach ograniczenie zbioru wartości, które może przyjmować pewien atrybut encji E1 do wartości określonego atrybutu encji E2 (np. klucz obcy encji E1 może przyjmować wartości tylko z dziedziny klucza głównego encji E2)

35 Więzy integralności Więzy mogą być statyczne (zawsze zachodzą) lub dynamiczne (związane z przejściem bazy z jednego stanu w drugi). Przykłady konieczności zastosowania dynamicznych więzów integralności: Dodanie lub zmiana wierszy w tabeli powiązanej, jeśli nie istnieje odpowiedni wiersz w tabeli podstawowej. Zmiana wierszy w tabeli podstawowej, która powoduje powstanie osieroconych wierszy w tabeli powiązanej. Usuwanie wiersza z tabeli podstawowej, gdy istnieją do niego odwołania w tabeli powiązanej.

36 Jak utworzyć ERD? 1. Ustalić encje i określić ich nazwy (rzeczowniki). 2. Dla każdej encji ustalić jej atrybuty i dziedziny tych atrybutów (przymiotniki, cechy). 3. Dla każdej encji określić, jakie atrybuty pełnią funkcję klucza głównego. 4. Ustalić związki, jakie zachodzą między encjami, określić ich liczebność (czasowniki). 5. Wyeliminować jako niepożądane związki jednojednoznaczne (1-1) i związki wieloznaczne (N-N). 6. Uzupełnić encje o klucze obce pozwalające zrealizować w praktyce związki jednoznaczne. 7. Określić więzy integralności nałożone na dane w bazie danych.