Projektowanie baz danych - diagramy związków encji

 

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.

 

Pośredni model projektowy - diagram związków encji:

  1. powinien w sposób jednoznaczny określać wymagania użytkowników umożliwiając im sprawdzenie czy analityk systemu dobrze zrozumiał ich intencje i specyfikę działania firmy; 
  2. jest istotnie prostszy od schematu bazy danych, ponieważ abstrahuje 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.

 

Encja (obiekt) coś co istnieje, co jest odróżnialne od innych, o czym informację trzeba znać lub przechowywać. Encje o tych samych własnościach tworzą typy (zbiory) encji. Reprezentacją graficzną encji jest ramka (prostokąt).

                          

 

Atrybut jest to właściwość encji danego typu, reprezentowana pewną wartością np. liczbą całkowitą, liczbą rzeczywistą, napisem.

 

Klucz (jednoznaczny identyfikator) jest to zbiór (być może jednoelementowy) atrybutów danej encji, których wartości jednoznacznie identyfikują każdą instancję tej encji.  Jeden klucz - główny, pozostałe alternatywne. Jedna encja może mieć wiele kluczy.

Atrybuty klucza głównego wyróżnia się etykietą PK i podkreśleniem.

 i

 

Więzy spójności dla encji określa się w zakładce Check.

 

 

Związek - uporządkowana lista encji, poszczególne encje mogą występować wielokrotnie. 

Z(E1 ,...,En) co oznacza: encje E1 ,...,En wchodzą w skład związku Z

Przykłady

 

Związek binarny - dwuargumentowy 

Uwaga: Połączenie encji związkiem sygnalizują czerwone kwadraciki w miejscu połączeń encji z linią związku!

Związek jednoznaczny

Gdy instancja związku binarnego jest dwuargumentową funkcją częściową związek jest jednoznaczny. 

Część związku odpowiadająca dziedzinie funkcji jest nazywana stroną wiele związku (lub encją podrzędną), a część odpowiadająca przeciwdziedzinie funkcji stroną jeden związku (lub encją nadrzędną) – i jest oznaczana strzałką. 

 

Implementacja związku jednoznacznego

Dwie encje połączone związkiem jednoznacznym są implementowane odpowiednio przez dwie tabele. W encji po stronie wiele jest dodany klucz obcy określający powiązanie z instancją encji po stronie jeden. 

 

Okienko właściwości związku  

 

Zakładka “Definition” definiuje związek jako powiązanie dwóch atrybutów: tworzonego automatycznie klucza obcego w encji po stronie "wiele" i klucza głównego w encji po stronie "jeden".

 

Zakładka "Name" określa sposób odczytywania zawartości związku oraz nazwę dla więzów klucza obcego: Departament_Osoba_FK1.

 

Zakładka “Miscelaneous” określa podstawowe własności związku:

  1. liczebność (Cardinality) – ile egzemplarzy encji po stronie wiele może być połączone z jednym egzemplarzem encji po stronie jeden; 
  2. typ związku (Relationship type) - czy identyfikujący – wartość klucza obcego wchodzi w skład klucza głównego encji po stronie wiele czy nieidentyfikujący - wartość klucza obcego nie wchodzi w skład klucza głównego encji po stronie wiele oraz 
  3. opcję Optional – czy wartość klucza obcego jest opcjonalna tzn. czy dopuszcza wartość NULL.

 

Zakładka “Ref. Integrity” określa akcje referencyjne podejmowane w przypadku naruszenia więzów spójności referencyjnej przez operacje usuwania i aktualizacji wierszy w tabeli nadrzędnej.

Oto opcje:

  1. Nic nie rób (No action, Restricted) - nie wykonuj zmiany naruszającej więzy  spójności referencyjnej. 
  2. Propaguj zmiany do encji podrzędnej (Cascade) - przy aktualizacji instancji encji nadrzędnej uaktualnij wartość klucza obcego w encji podrzędnej a przy usuwaniu razem z egzemplarzem encji  nadrzędnej usuń wszystkie powiązane przez wartość klucza obcego egzemplarze encji podrzędnej.
  3. Wstaw NULL (Set Null) - w przypadku aktualizacji lub usuwania instancji encji nadrzędnej za wartość klucza obcego w odpowiadających jej instancjach encji podrzędnej wstaw NULL. 
  4. Wyłącz więzy  spójności referencyjnej i wykonaj operację (Do not enforce). 

 

Transformacja związku niejednoznacznego

 

Wprowadzana encja reprezentująca związek nazywa się asocjacyjna

Przykład transformacji dla związku trójargumentowego

Pracownik w projekcie pełni rolę

Stosując przedstawioną metodę wprowadzamy nową encję asocjacyjną, której zadaniem jest opisać związek zachodzący między osobami, projektami i rolami. Jednoznaczny identyfikator nowej encji tworzą trzy wprowadzone związki tj. klucze obce do encji Osoba, Projekt i Rola.

 

Związek rekurencyjny

Zachodzi między tą samą encją, np. "Jedna osoba jest kierownikiem drugiej osoby".

Aby go zdefiniować w Visio tworzymy pętlę związku wokół encji Osoba, wprowadzamy do encji Osoba nowy atrybut o nazwie Kierownik i łączymy go z kluczem głównym Numer – w zakładce Definition.

 

Generowanie bazy danych

Po wybraniu docelowego systemu bazodanowego (w naszym przypadku MS Accessa) możemy wygenerować tabele w bazie danych:

  1. Tworzymy pustą bazę danych Accessa.
  2. Z menu Visio wybieramy opcję "Database -> Generate" wywołując kreator generacji.
  3. W pierwszym okienku dialogowym kreatora wybieramy opcję "Generate new database".

4a. Przy pierwszym użyciu:

4b. Przy kolejnym użyciu:

Po wygenerowaniu i otwarciu bazy danych Access mamy:

 Przykład

Zbudować model bazy danych z informacjami o piwoszach, barach i gatunkach piwa. Wymodelować związki:

  1. W barze podają gatunek piwa.

  2. Piwosz lubi gatunek piwa.

  3. Piwosz bywa w barze.

Rozwiązanie

 

Związki jedno-jednoznaczne, jeden-do-jeden

Gdy instancja związku jest różnowartościową funkcją częściową np. związek "Każdy student jest osobą" ("Osoba może być studentem, ale nie musi nim być").

 

Metody odwzorowania w tabele bazy danych

  1. (Stosowana przez MS Access) Używamy dwóch tabel: Student i Osoba. W tabeli Osoba zapisujemy atrybuty wspólne dla wszystkich osób. W tabeli Student zapisujemy klucz główny z tabeli Osoba (identyfikujący studenta jako osobę) oraz atrybuty charakterystyczne tylko dla studentów.

  2. Używamy tylko jednej tabeli, w której są przechowywane wszystkie możliwe atrybuty dotyczące osób. Jeśli osoba nie jest studentem, wartości atrybutów charakterystycznych tylko dla studentów pozostają NULL.

  3. W przypadku podziału encji Osoba na kilka podtypów, na przykład na encje Student i Pracownik, można użyć dwóch osobnych tabel Student i Pracownik. Gdy jest potrzebna informacja obejmująca zarówno studentów, jak i pracowników, trzeba zastosować sumowanie zawartości dwóch tabel.