slajd 1© J.Rumiński Jacek Rumiński  Bazy danych Kontakt: Katedra Inżynierii Biomedycznej, pk. 106, tel.: , fax: ,

slajd 2© J.Rumiński Projektowanie relacyjnych baz danych -Specyfikacja – język naturalny, -Diagramy związków encji (ERD – Entity-Relationship Diagrams), -Diagramy relacyjne (odwzorowanie ERD-DR), -Diagramy relacyjne a SQL.

slajd 3© J.Rumiński (na podstawie James Larson, Carol Larson, EVALUATION OF FOUR LANGUAGES FOR SPECIFYING CONCEPTUAL DATABASE DESIGNS, Data Management Handbook, CRC Press, 1999). Grupa encji Atrybut

slajd 4© J.Rumiński ERD - Peter Chen w 1976 roku, inna notacja IDEF1X standaryzowana przez wojsko. Encja – byt, konkretny i jednostkowy egzemplarz, to co istnieje (np. Kowalski). Atrybut – cecha charakterystyczna encji (np. kolor oczu). Atrybut reprezentowany jest na diagramach ZE poprzez owal. Grupa/zbiór encji – zgrupowane encje o tej samej charakterystyce-atrybutach (np. studenci). Zbiór encji reprezentowany jest na diagramach ZE przez prostokąt. Klucz – zbiór atrybutów, których wartości zapewniają unikalność encji – ograniczenie wartości atrybutów (key constraint). Klucz reprezentowany jest na diagramach ZE poprzez podkreślenie nazwy atrybutu/atrybutów. Zbiór związków – związki pomiędzy encjami, jeden-do-wielu; wiele-do-jednego; wiele- do-wielu.

slajd 5© J.Rumiński

slajd 6© J.Rumiński Związki – związek jeden do wielu i wiele do jednego

slajd 7© J.Rumiński

slajd 8© J.Rumiński Związki –wiele do wielu

slajd 9© J.Rumiński Hierarchia

slajd 10© J.Rumiński Reguły składni diagramów ZE. Często weryfikowane przez narzędzia wspomagające projektowanie baz danych. 1. Każdy atrybut jest powiązany z dokładnie jednym zbiorem encji lub zbiorem związków. (Nie mogą istnieć odseparowane atrybuty, lub powiązane z wieloma zbiorami encji lub relacji). 2. Każdy zbiór związków jest powiązany z co najmniej dwoma zbiorami encji. 3. Każdy zbiór encji jest pośrednio powiązany z każdym zbiorm encji diagramu. (Jeżeli diagram można podzielić na dwa rozłączne to modelują one dwa schematy a nie jeden schemat bazy danych.)

slajd 11© J.Rumiński Reguły znaczeniowe (semantyczne) diagramów ZE. Konieczna znajomość specyfikacji bazy danych i jej przeznaczenia. 1.Każdy atrybut powinien mieć unikalną nazwę. (Nazwa powinna jednoznacznie wskazywać atrybut. Jeżeli dwa zbiory encji mają atrybuty o tej samej nazwie to należy je przekształcić dodając przedrostek w nazwie, np. nazwy zbioru encji).

slajd 12© J.Rumiński 2. Każdy zbiór encji powinien mieć unikalną nazwę. (Zbiór encji jest odwzorowywany w kolekcję danych np. tabele, których nazwy muszą być unikalne).

slajd 13© J.Rumiński 2. Każdy zbiór encji powinien mieć unikalną nazwę. (Zbiór encji jest odwzorowywany w kolekcję danych np. tabele, których nazwy muszą być unikalne).

slajd 14© J.Rumiński 3. Każdy zbiór związków łączący parę tych samych zbiorów encji powinien mieć unikalną nazwę.

slajd 15© J.Rumiński 4. Żaden atrybut nie może mieć wielu wartości. (Model relacyjny wyklucza wiele wartości jednego atrybutu).

slajd 16© J.Rumiński Pierwsza postać normalna (1NF – First Normal Form): Każdy atrybut tabeli jest niepodzielny (atomowy). Przecięcie krotki i atrybutu zawiera pojedynczą wartość. W tabeli nie mogą znajdować się zatem powtarzające grupy. Przykład złamania reguły: imię i nazwisko jako jedna wartość atrybutu.

slajd 17© J.Rumiński 5. Żaden zbiór encji czy związków nie może posiadać powtarzających się grup. (Problem wielokrotnych zbiorów atrybutów – np. wiele adresów jednego studenta).

slajd 18© J.Rumiński 6. Atrybuty klucza zbioru encji funkcyjnie określają wszystkie wartości atrybutów powiązanych z danym zbiorem encji. ( Atrybut Y relacji R jest funkcyjne zależny od atrybutu X, jeżeli zawsze każdej wartości x atrybutu X odpowiada nie więcej niż jedna wartość y atrybutu Y. Jeżeli Y zależy funkcyjnie od X to X wyznacza Y)

slajd 19© J.Rumiński Zbiór atrybutów Y jest w pełni zależny funkcyjnie od zbioru atrybutów X relacji R, jeżeli X->Y i nie istnieje podzbiór X’ zawarty w X, taki że X’ ->Y. Zbiór atrybutów Y jest w częściowo zależny funkcyjnie od zbioru atrybutów X relacji R, jeżeli X->Y i istnieje podzbiór X’ zawarty w X, taki że X’ ->Y. Druga postać normalna: Relacja R jest w drugiej postaci normalnej (2NF) jeżeli żaden atrybut wtórny tej relacji nie jest częściowo funkcyjnie zależny od żadnego z kluczy relacji R. Inaczej – w krotce (wierszu) nie może być atrybutów (danych) zależnych od fragmentu klucza głównego (np. gdy jest zdefiniowany z więcej niż jednego atrybutu).

slajd 20© J.Rumiński Trzecia postać normalna: Relacja R o danym schemacie jest w trzeciej postaci normalnej (3NF), jeżeli jest w drugiej postaci normalnej i żaden atrybut wtórny tej relacji nie jest przechodnio zależny od klucza głównego tej relacji. Inaczej – atrybuty nie wchodzące w skład klucza głównego zależą jedynie od klucza głównego. Zbiór atrybutów Y jest przechodnio funkcyjnie zależny od zbioru atrybutów X w schemacie relacji R, jeżeli X  Y i istnieje zbiór atrybutów Z, nie będący podzbiorem żadnego klucza schematu relacji R, taki że zachodzi X  Z i Z->Y. →  Y.

slajd 21© J.Rumiński Reguły pragmatyczne (upraszczające model). 1. Usuwać nadmiarowe zbiory związków.

slajd 22© J.Rumiński 2. Rozdziel zbiór encji jeśli jego atrybuty są wykorzystywane w różnych kontekstach (np. optymalizacja czasowa).

slajd 23© J.Rumiński 3. Zamień każdy zbiór związków wiele-do-wielu na dwa jeden-do- wielu i dodatkowy zbiór encji. (Dopasowanie do modelu relacyjnego).

slajd 24© J.Rumiński Dodatkowe wskazówki projektowe. Reguły biznesowe: reguły określające ważne wartości (domenę) atrybutów (liczebność, przynależność, zależności funkcyjne). Opisuj stosowane kody (np. 1 mężczyzna, 2 kobieta) Opisuj elementy danych – jakie wartości atrybutu są dopuszczalne, do kiedy ważne, w jakich jednostkach, itp.

slajd 25© J.Rumiński Odwzorowanie diagramu ZE na model relacyjny Klucze kandydujące, Klucze główne, Tabele, Klucze obce, Typy danych Relacje

slajd 26© J.Rumiński Klucze Każdy podzbiór SK (superkey, superklucz) atrybutów relacji R, taki że dla każdych dwóch krotek k relacji R: k1(SK)<>k2(SK) jest nazywany superkluczem (nadkluczem) relacji R. Kluczem K schematu relacji R nazywamy taki klucz, że nie istnieje żaden inny klucz K’ zawarty w K. Jeżeli relacja R zawiera więcej niż jeden klucz, wówczas nazywane są one kluczami kandydującymi (candidate key). W procesie odwzorowania modelu koncepcyjnego na model relacyjny ustalamy klucze kandydujące, oraz wybieramy z nich klucz główny. Jeżeli żaden z kluczy kandydujących nie spełnia naszych oczekiwań (ze względu na efektywność działania – liczby zamiast łańcuchów znaków) można utworzyć nowy atrybut, spełniający wymagania klucza głównego. Klucz powinien być ograniczony co najmniej zapewnieniem iż jego wartość będzie: NIE PUSTA (NOT NULL) i UNIKALNA (UNIQUE).

slajd 27© J.Rumiński Zbiory encji -> Relacje (tabele) Kolejnym krokiem odwzorowania jest utworzenie relacji/tabel na podstawie zbiorów encji. Spełniwszy wymagania co do diagramów ZE (np. wymagania normalizacji) pozostaje głównie określenie dozwolonych nazw atrybutów oraz określenie typów danych ich zakresu (dziedziny). Klucze obce Następny krok to określenie kluczy obcych (relacji). Konieczna jest weryfikacja czy wybrane środowisko RDBMS obsługuje klucze obce, jakie warunki i ograniczenia, itp. Na tej podstawie można dopiero przygotować odwzorowanie związków modelu ZE na relacje modelu relacyjnego.

slajd 28© J.Rumiński Przykład – normal_forms.html