Wykład 3

Projektowanie baz danych - diagramy związków encji

 

Streszczenie

W wykładzie 3 jest przedstawiona podstawowa metoda tworzenia schematu relacyjnej bazy danych. Jest ona dwustopniowa. W pierwszej fazie projektujemy model danych dla rozważanej dziedziny zastosowań nazywany diagramem związków encji. W drugiej fazie przekształcamy otrzymany model danych w schemat bazy danych.

Specjalne oprogramowanie (nazywane narzędziami CASE - Computer Aided System Engineering)  dostarcza narzędzi graficznych do projektowania i rysowania diagramów na ekranie komputera. Co więcej dostarcza narzędzi do automatycznego generowania schematu bazy danych w konkretnym systemie baz danych takim jak na przykład Microsoft Access. W tym wykładzie ilustrujemy wprowadzane pojęcia za pomocą zdjęć ekranów pochodzących z programu Microsoft Visio (wersja 2000), który służy do rysowania różnego rodzaju diagramów, w tym diagramów związków encji.

Proponujemy czytelnikowi aby na bieżąco wykonywał ćwiczenia odnośnie konstrukcji prezentowanych na wykładzie a na koniec zrealizował zadanie o piwoszach. Do realizacji zadań jest potrzebny albo sam program Microsoft Visio (wersja 2000) albo inny program umożliwiający rysowanie diagramów, na przykład Microsoft Word.
 


Diagram 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.

Na ogół, zanim utworzy się bazę danych, dokonuje się analizy wymagań informacyjnych i przedstawia się je w postaci modelu danych nazywanego diagramem związków encji. W diagramie tym abstrahujemy od szczegółów technicznych związanych z implementacją danych w konkretnym systemie baz 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. ma być istotnie prostszy od schematu bazy danych, ponieważ ma abstrahować od szczegółów implementacyjnych, które muszą być później opracowywane przez projektanta bazy danych aby baza danych mogła powstać i spełniać postawione przed nią zadania.

Omówimy kolejno składniki: encje (ang. entity), atrybuty (ang. attribute) i związki (ang. relationship), z których jest budowany diagram związków encji.
 

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. Jedna encja może mieć wiele kluczy. Jeden klucz jest  główny, pozostałe alternatywne.

Atrybuty klucza głównego wyróżnia się etykietą PK i podkreśleniem. Klucze aternatywne określa się za pomocą indeksów jednoznacznych, o których będzie mowa za chwilę.

 W MS Visio atrybuty encji określa się w zakładce "Columns".

 i na przykładzie typów danych MS Access:

("Req'd" to skrót od "Required" – "Wymagany", "PK" to skrót od "Primary Key" – "Klucz główny". Wybierając typ danych możemy z listy rozwijanej wybrać opcję <new data type> i wtedy wyświetli się więcej dostępnych typów danych.)

Jak zobaczymy, niektóre encje wymagają powiązania z innymi encjami w celu jednoznacznego ich zidentyfikowania – encje takie nazywają się słabe, zależne; pozostałe niezależne. Analizę zaczynamy zawsze od zidentyfikowania encji niezależnych.
 

Więzy spójności dla encji określa się w zakładce Check. Oto przykład definicji wymagania, że zarobki pracownika muszą być większe niż 1000.

 

Indeksy

Wśród atrybutów encji wyróżniamy atrybuty bądź grupy atrybutów względem wartości których są wyszukiwane egzemplarze encji. Dla takich atrybutów specyfikujemy indeksy. Przy czym indeks na kluczu głównym jest zakładany automatycznie i nie trzeba dodatkowo go specyfikować.

Odróżniamy dwa rodzaje indeksów: indeksy jednoznaczne oparte na kolumnach, które tworzą klucz jednoznaczny oraz indeksy zwykłe oparte na kolumnach, które nie koniecznie tworzą klucz jednoznaczny.

Na diagramie atrybuty posiadające indeksy jednoznaczne są etykietowane literą U z kolejnym numerem np. U1, U2, a indeksy  zwykłe są etykietowane literą I z kolejnym numerem np. I1, I2.

W MS Visio indeksy specyfikuje się w zakładce "Indexes". Oto przykład specyfikacji zwykłego indeksu do wyszukiwania osób według ich nazwisk.

 


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

Na przykład:
  • Pracownik pracuje w dziale
  • Pracownik w projekcie pełni rolę
  • Kraj eksportuje towar

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 funkcją częściową, związek nazywa się jednoznaczny.

  • Instancja związku jednoznacznego między encjami Osoba i Departament jest funkcją ze zbioru osób w zbiór departamentów.

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ą. 

  • Departament jest encją po stronie jeden (nadrzędną) a Osoba encją po stronie wiele (podrzędną).

Czas na proste zadanie.

Powiąż w pary odpowiadające sobie terminy: kolumna, encja, tabela, atrybut, klucz, związek jednoznaczny, wiersz, jednoznaczny identyfikator, klucz obcy, egzemplarz encji.

 

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.

  • W naszym przykładzie do encji Osoba jest dodany klucz obcy Id etykietowany przez FK1 określający powiązanie z instancją encji Departament - przez wartość klucza  głównego Id.

 Czas na proste zadanie.

Powiąż wierszami odpowiadające sobie terminy: dziedzina funkcji, strona jeden, encja nadrzędna, przeciwdziedzina funkcji, strona wiele, encja podrzędna.

 

Okienko właściwości związku ("Database properties")

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

W przykładzie, Osoba jest encją po stronie "wiele", a Departament jest encją 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. Może to być konkretna liczba np. 2 albo określenie typu "zero lub więcej", "jeden lub więcej", "zero lub jeden".
  2. typ związku (Relationship type) - 
  3. opcję Optional – czy wartość klucza obcego jest opcjonalna tzn. czy dopuszcza wartość NULL. Związek jest opcjonalny gdy wartość klucza obcego dopuszcza wartość NULL. Związek jest wymagany gdy wartość klucza obcego musi być określona tzn. nie może być NULL (inaczej mówiąc, dla każdego egzemplarza encji po stronie wiele istnieje odpowiadający mu egzemplarz encji po stronie jeden).

Związek między osobami i departamentami ma liczebność "zero lub więcej", jest nieidentyfikujący i opcjonalny.

Inny przykład:
 

Jako przykład związku, który ma liczebność "jeden lub więcej", jest identyfikujący i wymagany (nie opcjonalny), rozważmy związek między zamówieniami i pozycjami w zamówieniu. Każde zamówienie składa się z jednej lub więcej pozycji zamawianych towarów. Zamówienie identyfikuje każdą swoją pozycję (bez zamówienia nie można mówić o pozycji zamówienia). Każda pozycja zamówienia ma określone dokładnie jedno zamówienie, którego jest pozycją. Encja Pozycja zamówienia to encja słaba (zależna). Spróbuj zaprojektować diagram obejmujący klientów, zamówienia, pozycje zamówień i towary. Oto możliwe rozwiązanie. Czy możesz podać jeszcze inny przykład związku identyfikującego?

Teraz pytanie:
 

Czy możesz podać przykład związku opcjonalnego, który jest identyfikujący?

 

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 gdy narusza ona 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. Ta akcja jest w szczególności naturalna dla wszystkich związków identyfikujących.
  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).

Niektóre systemy dopuszczają jeszcze jedną opcję:
 
5.  Wstaw wartość domyślną (Set Default) - w przypadku aktualizacji lub usuwania instancji encji nadrzędnej za wartość klucza obcego w odpowiadających jej instancjach encji podrzędnej wstaw wartość domyślną.

 


Przejście do drugiej części wykładu