Wykład III Modelowanie danych Relacyjne Bazy Danych Wykład III Modelowanie danych

Streszczenie wykładu III Wykład III składa się z trzech części. W pierwszej są przedstawione dwie kolejne konwencje notacyjne dla diagramów związków encji. Jako uzupełnienie jest pokazana notacja dla modelowania perspektyw i hierarchii encji. W drugiej części są rozważone dwa problemy często występujące w zastosowaniach: modelowanie hierarchii danych oraz modelowanie zmienności danych w czasie.

Konwencje notacyjne dla diagramów związków encji Część I Konwencje notacyjne dla diagramów związków encji

Alternatywne notacje modelowania danych Za chwilę zostaną przedstawione dwie kolejne konwencje notacyjne dla diagramów związków encji. Ilustruje to fakt, że w praktyce modelowania danych są używane rozmaite notacje i nie ma jednego, jedynie słusznego standardu. Wszystkie one obejmują te same pojęcia: encja – atrybut - związek. Wybór notacji jest naprawdę drugorzędny i jest często determinowany przez rodzaj narzędzia CASE, którego używa zespół projektowy.

Notacja modelowania danych IDEF1X Najpierw przedstawimy notację modelowania IDEF1X. Jest ona dostępna w MS Visio: "Database -> Options ->Document -> Zakładka General -> Symbol set = IDEF1X" (zamiast domyślnego "Relational")

Notacja modelowania danych IDEF1X Konwencje notacyjne IDEF1X: Związek identyfikujący – linia ciągła Związek nieidentyfikujący – linia przerywana Strona wiele związku – czarne kółko Związek opcjonalny – romb przy encji po stronie jeden Indeks - IE Prostokąt z zaokrąglonymi narożami - encja zależna (słaba)

Notacja IDEF1X - notacja ErWin’a Notacja IDEF1X jest stosowana w Erwinie - narzędziu CASE używanym dawniej w PJWSTK. Erwin modeluje też związki wieloznaczne: Jeden student uczęszcza na zajęcia z wielu przedmiotów. Na zajęcia z jednego przedmiotu uczęszcza wielu studentów. Należy pamiętać, że przedstawiony powyżej schemat, to tylko model związku, a nie rozwiązanie problemu, które, niezależnie od notacji, sprowadza się do rozłożenia związku niejednoznacznego na sumę związków jednoznacznych.

Notacja modelowania danych Chena Druga z prezentowanych notacji to notacja zaproponowana przez Petera Chena w 1976, jako pierwsza dla diagramów związków encji. Jest ona bardziej uniwersalna od poprzednich, bo umożliwia reprezentację związków wieloargumentowych i wieloznacznych.

Notacja modelowania danych Chena Konwencje notacyjne notacji Chena: Encja – prostokąt, Atrybut – koło, Związek – romb Powyższy diagram modeluje zależności: Dla każdej grupy studenckiej prowadzone są zajęcia z różnych przedmiotów przez różnych wykładowców.

Notacja modelowania danych Chena W MS Visio o tworzeniu modelu w notacji Chena decydujemy już na etapie otwierania nowego pliku: "File -> New -> Database -> Chen ERD” Dla notacji „Relational” i „IDEF1X: "File -> New -> Database -> Database Model Diagram").

Notacja modelowania danych Chena Należy zwrócić uwagę na fakt, że tylko w notacji Chena przewidziany jest oddzielny symbol reprezentujący związek w taki sposób, który pozwala modelować istniejące niejednoznaczne zależności pomiędzy encjami, gdy liczba encji przekracza 2, bez konieczności wprowadzania do modelu encji asocjacyjnych.

Rozszerzenia zasadniczego modelu w MS Visio - modelowanie perspektyw Perspektywa (view) jest widokiem na dane w bazie danych dostosowanym do punktu widzenia i potrzeb końcowego użytkownika bazy danych. Przy generowaniu do MS Access perspektywy przechodzą na kwerendy wybierające.

Rozszerzenia zasadniczego modelu w MS Visio - modelowanie perspektyw Pierwszy przykład pokazuje perspektywę złożoną z nazwiska studenta (atrybut encji Student) i numeru jego grupy studenckiej (atrybut encji Grupa). Przy definiowaniu perspektywy trzeba podać warunek złączenia encji wchodzących w skład definicji perspektywy. W pokazanym przykładzie jest to równość wartości atrybutów Nr_grupy po obu stronach związku, czyli w obu encjach wchodzących w skład perspektywy.

Rozszerzenia zasadniczego modelu w MS Visio - modelowanie perspektyw Drugi przykład pokazuje perspektywę Ucza_Studentow, łączącą wykładowców oraz tych studentów, z którymi wykładowcy prowadzą zajęcia. Posiada ona dwa atrybuty: Wykladowca (Nazwisko i Imię wykładowcy) z encji Wykładowca, oraz Student (Nazwisko i Imię studenta) z encji Student.

Rozszerzenia zasadniczego modelu w MS Visio - modelowanie perspektyw Zauważmy, że encje Wykladowca i Student, z których pochodzą atrybuty perspektywy, nie są bezpośrednio połączone związkiem. Przy definiowaniu warunków złączeń encji (w zakładce „Join Criteria”) trzeba podać całą sekwencję warunków złączeń, zaczynając od encji Wykladowca, przejść przez encje Zajecia i Grupa, dochodząc na koniec do encji Student. Przykład ten pokazuje, że w definicji perspektywy może występować więcej encji niż tylko te, z których pochodzą atrybuty perspektywy.

Część II Modelowanie hierarchii danych oraz modelowanie zmienności danych w czasie

Hierarchia encji, związek kategorii Pozostał nam do omówienia jeszcze jeden, często występujący związek między wieloma encjami. Mianowicie, przypadek gdy jedna encja jest wyróżniona jako nadrzędna (nadencja); pozostałe jako jej podencje (encje podrzędne). Związek tego rodzaju nazywa się związkiem kategorii lub hierarchią encji. Umożliwia on reprezentowanie dziedziczenia właściwości od encji ogólnej – nadencji, do encji szczegółowych - podencji. W przykładzie encja Osoba jest nadencją, a encje Student, Wykładowca i Administracja podencjami. Osoba może być studentem, pracownikiem dydaktycznym (wykładowcą) lub pracownikiem administracji szkolnej. Cechy wspólne osób grupuje się w encji Osoba; cechy charakterystyczne dla odpowiedniej grupy osób w jednej z podencji. Należy zwrócić uwagę na fakt, że w tym ujęciu Osoba może być jednocześnie studentem i/lub wykładowcą i/lub pracownikiem administracji, a przyjęte rozwiązanie pozwala na zapisanie bez powtórzeń wszystkich jej atrybutów. Niedogodnością tego rozwiązania jest konieczność korzystania ze złączeń encji przy wydobywaniu informacji dotyczących osób, wraz z danymi wynikającymi z ich przynależności do poszczególnych podkategorii

Hierarchia encji, związek kategorii - przykład Wśród atrybutów nadencji mógłby pojawić się atrybut, nazywany wyróżnikiem kategorii, decydujący o zaliczeniu osoby do jednej z podencji. W naszym przykładzie taki atrybut nie występuje. Na diagramie kategoria została określona jako pełna (complete) tzn. każda osoba trafia do jednej z trzech podencji.

Hierarchia encji – narzędzia tworzenia prezentacji Od symbolu kategorii do podencji Symbol kategorii Od nadencji do symbolu kategorii Dla tworzenia modelu diagramu związków encji z użyciem rozdzielenia kategorii i podkategorii MS Visio przewiduje specjalne narzedzia: Ikona „Category” stanowiąca obiekt pośredni pomiędzy nadencją a podencjami Ikona „Parent to category” – łącznik pomiędzy nadencją a ikoną „Category” Ikona „Category to child” – łącznik pomiędzy ikoną „Category” a podencjami

Hierarchia encji – implementacja w MS Access Związek kategorii można zastąpić zbiorem związków jedno - jednoznacznych między nadencją i podencjami. Na wykładzie II omówiliśmy trzy sposoby reprezentowania związków jedno - jednoznacznych w bazie danych, które mogą być zastosowane do reprezentowania hierarchii: Osobne tabele dla nadencji i podencji z rozdzieleniem atrybutów, osobne tabele dla podencji zawierające komplet atrybutów, jedna wspólna tabela zawierająca komplet atrybutów

Hierarchia encji – implementacja w MS Access Przy generowaniu do bazy danych MS Access realizowana jest metoda 1 tzn. tworzone są osobne tabele dla nadencji i każdej podencji, co widać na powyższym przykładzie.

Modelowanie hierarchicznej struktury danych Jednym z powtarzających się wzorców modelowania danych są ich hierarchie. Rozważmy na przykład hierarchiczną strukturę organizacyjną firmy. Model powyższy, aczkolwiek formalnie poprawny, ma dwie istotne wady: Jest bardzo rozbudowany; dla struktur bardziej skomplikowanych, o większej ilości „pięter” (np. dokumentacja techniczna, struktury podległości w wojsku) wymusza tworzenie dużej liczby encji (tabel). Jest całkowicie pozbawiony elastyczności; jakakolwiek zmiana struktury firmy, wymusza zmianę koncepcji(!) opisującej ją bazy danych.

Modelowanie hierarchicznej struktury danych Alternatywną reprezentację stanowi model, w którym wszystkie jednostki organizacyjne są modelowane za pomocą jednej encji. Powiązanie do encji nadrzędnej realizowane jest przez pętlę wokół encji jednostki organizacyjnej (związek rekurencyjny). Model ten jest krótszy i bardziej elastyczny np. w sytuacji zmiany struktury organizacyjnej firmy. Zwróćmy uwagę, że związek rekurencyjny dla hierarchii musi być opcjonalny, aby móc zakończyć przechodzenie hierarchii na najwyższej jednostce organizacyjnej nazywanej korzeniem hierarchii.

Modelowanie hierarchicznej struktury danych W encji jednostki organizacyjnej występuje atrybut Typ, którego wartością jest typ jednostki organizacyjnej np. „Oddział", „Zaklad” etc. Zbiór takich wartości jest mało-liczny i rzadko ulega modyfikacji. Aby ułatwić kontrolę poprawności wprowadzanych przez użytkownika wartości tego atrybutu, wprowadza się osobną encję, nazywaną encją słownikową. Na poniższym diagramie jest to encja Typ.

Modelowanie zjawisk zmiennych w czasie Problemem, przed którym często staje projektant schematu bazy danych jest uwzględnienie w modelu danych zmian wartości atrybutów w czasie. Interesuje nas nie tylko, ile wykładowca zarabia obecnie, jakie zajmuje stanowisko, w której aktualnie pracuje katedrze, ale również ile zarabiał w zeszłym roku, jak przebiegała jego kariera, w jakich katedrach pracował od początku zatrudnienia.

Modelowanie zjawisk zmiennych w czasie Stosowana metoda jest podobna jak przy wprowadzaniu encji asocjacyjnych – dodajemy encję "temporalną", której zadaniem jest reprezentowanie zmian w czasie – dotyczących albo wartości atrybutów, albo związków z inną encją. Zależność (związek) pomiędzy wykładowcą a jego zarobkami i stanowiskami jest zależnością jeden – do – wiele.

Modelowanie zjawisk zmiennych w czasie Najpierw rozwiążemy problem wprowadzenia historii zmian w wartościach atrybutów, tzn. problem uwzględnienia historii zarobków (atrybut Zarobki) i piastowanych stanowisk (atrybut Stanowisko). W tym celu wprowadzimy nowe encje zależne: „Zarobki_historia” – do reprezentowania zmian zarobków, oraz"Stanowiska_historia" – do reprezentowania zmian w piastowanych stanowiskach. Wprowadzimy także do obu nowych encji atrybut „Data_od" reprezentujący czas, w którym zaszło odpowiednie zdarzenie (rozpoczął się nowy stan). Atrybut ten umieszczamy w kluczu głównym.

Modelowanie zjawisk zmiennych w czasie Teraz rozwiążemy problem wprowadzenia historii przypisania pracowników do katedr w uczelni (związek między encjami Wykładowca i Katedra). W tym celu wprowadzimy nową encję zależną „Zatrudnienie_historia" której rolą jest reprezentowanie zmian przypisań wykładowcy do katedry. Wprowadzimy także do nowej encji atrybut „Data_od" reprezentujący czas, w którym zaszło przypisanie katedry. Atrybut ten umieszczamy w kluczu głównym. Zależność (związek) pomiędzy wykładowcami a ich zatrudnieniem jest zależnością wiele – do – wiele.

Modelowanie zjawisk zmiennych w czasie Opisaliśmy w ten sposób zmiany w czasie wartości atrybutów i związków. Zachodzi pytanie, czy jest sens mówić o zmienności instancji encji? Zmiany wartości atrybutów w istniejących instancjach encji moglibyśmy reprezentować tak jak poprzednio, z wyjątkiem być może zmian wartości klucza głównego (oznaczających zmianę "tożsamości" instancji encji). Taką zmianę moglibyśmy interpretować jako zastąpienie jednej instancji przez inną (usunięcie i wstawienie) – być może z przeniesieniem wartości pewnych atrybutów.

Modelowanie zjawisk zmiennych w czasie W szczególnym przypadku może tu chodzić tylko o usunięcie instancji encji – ale z pozostawieniem jej w historii instancji encji. Faktycznie w bazie danych pracowników (wykładowców) pozostawia się zwykle o nich informacje, mimo że przestają być pracownikami. Oto możliwe rozwiązanie tego problemu, polegające na wprowadzeniu atrybutu "Status", którego wartość powinna pozwolić rozstrzygnąć, czy dana osoba jest aktualnie pracownikiem firmy.

Modelowanie zjawisk zmiennych w czasie Inne rozwiązanie problemu mogłoby polegać na przeniesieniu informacji o usuwanych obiektach do osobnych encji stanowiących pewnego rodzaju historyczne archiwum bazy danych. Szczególnie przy dużych rozmiarach zbiorów instancji encji takie rozwiązanie jest wskazane, ze względu na efektywność operacji wyszukiwania w bazie danych.

Do zobaczenia na wykładzie IV Koniec wykładu III Do zobaczenia na wykładzie IV