Wykład 4

Modelowanie danych

 

Streszczenie

Wykład 4 składa się z czterech części. W pierwszej są przedstawione dwie kolejne konwencje notacyjne dla diagramów związków encji. Ilustruje to fakt, że w praktyce są używane rozmaite notacje i nie ma jednego, jedynie słusznego standardu. 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.

W trzeciej części jest przedstawione obiektowo-relacyjne rozszerzenie modelu danych: w MS Visio oraz notacyjny język ODL (Object Definition Language).

W czwartej części jest przedstawiony tzw. semistrukturalny model danych w tym reprezentacja danych w języku XML.

Przykłady diagramów, tak jak na poprzednim wykładzie, są tworzone przy pomocy programu Microsoft Visio.
 


Notacja modelowania danych IDEF1X

Za chwilę zaprezentujemy kolejne dwie 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 narzędzie CASE, które stosuje zespół projektowy.

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


Konwencje notacyjne

Notacja IDEF1X jest stosowana w Erwinie - narzędziu CASE używanym dawniej w PJWSTK. Erwin modeluje też związki wieloznaczne:

 
Jedna osoba może pracować w wielu projektach. W jednym projekcie może pracować wiele osób.

 

Notacja modelowania danych Chena

Jest to notacja zaproponowana przez 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.

Konwencje notacyjne:

W MS Visio: "File -> New -> Database -> Chen ERD" (do tej pory "File -> New -> Database -> Database Model Diagram")

 
Każda osoba może brać udział w różnych projektach w różnych rolach.

Czas na ćwiczenie z modelowania danych.

 
Podaj model w notacji Chena dla danych dotyczących zwierząt w ZOO, ich opiekunów i pokarmów. Model powinien obejmować związek: zwierzę zjada posiłek przygotowany przez opiekuna.

A teraz zadanie "badawcze" dla osób, które dysponują programem MS Visio.
Sprawdź jakie jeszcze konwencje notacyjne diagramów związków encji realizuje MS Visio. Może inna konwencja jest bardziej odpowiednia dla Ciebie?

 

Rozszerzenia zasadniczego modelu w MS Visio

 

Modelowanie perspektyw (view)

Perspektywa jest widokiem na dane w bazie danych dostosowanym do punktu widzenia i potrzeb końcowego użytkownika bazy danych. Pierwszy przykład pokazuje perspektywę złożoną z nazwiska osoby (atrybut encji Osoba) i jej miejsca pracy (atrybut encji Departament). Przy definiowaniu perspektywy trzeba podać warunek złączenia encji wchodzących w skład definicji perspektywy.

 

Drugi przykład pokazuje perspektywę ZamTowary określającą zamówione przez klienta towary. Obejmuje ona dwa atrybuty: Nazwisko klienta – atrybut Nazwisko z encji Klient oraz Nazwa towaru – atrybut Nazwa z encji Towar. Zauważmy, że encje Klient i Towar, 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ć sekwencję warunków złączeń zaczynając od encji Klient, przechodząc przez encje Zamowienie i Pozycja i dochodząc na koniec do encji Towar. Przykład ten pokazuje, że w definicji perspektywy może występować więcej encji niż tylko te z których pochodzą atrybuty perspektywy.

Przy generowaniu do MS Access perspektywy przechodzą na kwerendy wybierające.

 

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 Projektant, Analityk i Sekretarka podencjami.

 
Osoba może być projektantem, analitykiem lub sekretarką. Cechy wspólne osób grupuje się w encji Osoba; cechy charakterystyczne dla odpowiedniej grupy osób w jednej z podencji Projektant, Analityk lub Sekretarka.

Atrybut Stanowisko, nazywany wyróżnikiem kategorii, decyduje o zaliczeniu osoby do jednej z podencji. Na diagramie kategoria została określona jako pełna (complete) tzn. każda osoba trafia do jednej z trzech podencji.

Oto pełny zestaw narzędzi opcji "Entity Relationship" w MS Visio do tworzenia elementów diagramu związków encji:

Związek kategorii można zastąpić zbiorem związków jedno-jednoznacznych między nadencją i podencjami. Na wykładzie 3 omówiliśmy trzy sposoby reprezentowania związków jednojednoznacznych w bazie danych, które mogą być zastosowane do reprezentowania hierarchii:

  1. osobne tabele dla nadencji i podencji,
  2. osobne tabele dla podencji,
  3. jedna wspólna tabela.

Przy generowaniu do bazy danych MS Access jest realizowana metoda 1 tzn. tworzone są osobne tabele dla nadencji i każdej podencji.

Jako ćwiczenie zbuduj hierachię znanych Ci rodzajów obiektów latających. Jakie właściwości są dla nich wspólne, jakimi się różnią?

 


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