Obiektowość w modelu relacyjnym

ji nadrzędnych i encji potomnych według ogólnych zasad dziedziczenia dla podej-ścia obiektowego. Zgodnie z tymi zasadami encja nadrzędna zawiera atrybuty wspól-ne, encje potomne natomiast zawierają atrybuty charakterystyczne dla nich, dziedzicząc atrybuty wspólne. Program DataArchitect umożliwia wprowadzanie nad-klasy encji i podklas do diagramu ER za pomocą narzędzia dziedziczenia z palety narzędzi, a także przeprowadzenie szczegółowej definicji dziedziczenia w standardo-wy dla pakietu sposób, czyli poprzez okna dialogowe.

Ponieważ w środowisku, którego dotyczył przykład 7.1 nie zachodzi

iniowania dziedziczenia, mechanizmy te zostaną zobrazowane prostym i wyłącznie ilustracyjnym przykładem dotyczącym innego obszaru modelowania, z hipotetycznie przyjętymi założeniami. Nie będzie to cały model, lecz wycinek związany z zagadnie-niem dziedziczenia i jego transformacją na model relacyjny.

Obszar modelowania dotyczy środowiska uczelnianego, analizowanego pod kątem systemu płac. Pierwszym spostrzeżeniem jest podział pracowników na dwie ogólne kategorie: pracownicy dydaktyczni i niedydaktyczni (w rzeczywistości podział jest bardziej skomplikowany, ten podział przyjęto jedynie przykładowo). Obie kategorie pracowników można opisać wspólnymi atrybutami, takimi jak: identyfikator pracow-nika, nazwisko, imię, data urodzenia, miejsce zamieszkania, jednostka organizacyjna, stanowisko. Każda z kategorii charakteryzuje się dodatkowo swoimi własnymi atrybu-tami, na przykład: typ umowy o pracę dla pracowników dydaktycznych może być mianowaniem bądź umową o pracę, każdy z pracowników dydaktycznych ma okre-ślone pensum godzinowe, w odniesieniu do każdego pracownika odnotowywana jest liczba zrealizowanych godzin dydaktycznych. Podobnie dla pracowników niedydak-tycznych atrybutem jest przysługująca premia, odnotowywane są liczby nadgodzin przepracowanych w dni robocze i w dni wolne.

Z punktu widzenia analityka i projektanta sytuacja taka umożliwia wyodrębnienie nadklasy encji: PRACOWNIK oraz dwóch podklas encji: PRACOWNIK DYDAK-TYCZNY i PRACOWNIK NIEDYDAKDYDAK-TYCZNY.

Konstruowanie diagramu E-R przebiega według znanej procedury:

• Umieszczenie w polu projektu encji oraz ich zdefiniowanie (nazwy, atrybuty, dziedziny).

• Zaznaczenie za pomocą narzędzia dziedziczenia z palety narzędzi związku po-między encją rodzicem (PRACOWNIK) najpierw z jedną encją potomną, a następnie z drugą. Diagram E-R wygląda następująco:

PRACOWNIK Id_pracownika Nazwisko Imie Data_ur Miejsce_ur Miejsce_zamieszkania Jednostka_org Stanowisko DYDAKTYK Typ_umowy pensum godziny_wyk NIEDYDAKTYK Premia Nadgodz_rob Nadgodz_wol

• Kolejnym krokiem jest zdefiniowanie właściwości dziedziczenia poprzez wywo-łanie okna dialogowego dla obiektu dziedziczenia (rys. 7.25). Należy przypomnieć, że program DataArchitect traktuje dziedziczenie umieszczone w modelu CDM jako obiekt (podobnie jak związek, encja, czy perspektywa), którego nazwa i definicja

mu-szą zostać zapisane w słowniku programu. Okno dialogowe w przypadku definiowa-nia dziedziczedefiniowa-nia oprócz standardowych definicji zawiera opcje umożliwiające wybór parametrów transformacji modelu CDM na model PDM.

Tryb dziedziczenia Sposób implementacji w modelu PDM Atrybut identyfikujący encje potomne

Rys. 7.25. Okno dialogowe definiujące dziedziczenie

Należy zwrócić uwagę na wybór trybu dziedziczenia – na rys. 7.25 zaznaczono tryb Mutually exclusive, co oznacza dziedziczenie wykluczające: nie można być jed-nocześnie pracownikiem dydaktycznym i niedydaktycznym. W modelu CDM dziedzi-czenie wykluczające zostanie automatycznie oznaczone przez pojawienie się znaku × wewnątrz symbolu dziedziczenia.

Kolejne deklaracje dotyczą sposobu transformacji modelu CDM na model PDM, tzn. czy w modelu relacyjnym ma być generowana jedna tabela zawierająca kolumny z encji rodzica i encji potomnych, czy generowane mają być tabele odpowiadające wszystkim encjom, czy też tylko tabele odpowiadające encjom potomnym.

W pierwszym przypadku (tylko jedna tabela) zostanie uaktywniona dolna część okna, w celu zdefiniowania atrybutu identyfikującego (rozróżniającego) encje potom-ne. W uaktywnione pola należy wpisać nazwę atrybutu oraz jego dziedzinę. W odnie-sieniu do omawianego przykładu właściwą dziedziną jest typ Boolean, ponieważ istnieją tylko dwie możliwości: pracownik jest pracownikiem dydaktycznym lub nie. Okno dialogowe dla takiego przypadku oraz – będący konsekwencją wybranych opcji – model PDM ilustruje rys. 7.26.

Uwaga: Planując realizację dziedziczenia w modelu relacyjnym w jednej tabeli

wymagane, lecz opcjonalne. Jako wymagane mogą być definiowane jedynie atrybuty encji rodzica. Wiąże się to z późniejszymi zapisami do bazy danych – kolumny tabel odpowiadające atrybutom wymaganym będą określone jako not null.

W praktyce taki sposób implementacji dziedziczenia stosuje się w przypadkach, gdy encje potomne mają małą liczbę atrybutów własnych, aby nie doprowadzić do sytuacji nierównomiernych zapisów do tabeli, z wieloma miejscami pustymi.

Ustawienia okna dialogowego dla trybu generowania jednej tabeli w modelu PDM

Model PDM – implementacja dziedziczenia w jednej tabeli

Rys. 7.26. Okno dialogowe definiujące dziedziczenie i opcje generowania jednej tabeli w modelu PDM

W przypadku drugim (generowane wszystkie tabele) należy podjąć decyzję, czy w tabelach odpowiadających encjom potomnym mają się znaleźć wszystkie dziedzi-czone atrybuty, czy jedynie klucze obce, poprzez które realizowane będzie powiązanie pomiędzy tabelą nadrzędną a tabelami podrzędnymi. Wybór opcji z dziedziczeniem wszystkich atrybutów prowadzi nieuchronnie do ogromnej redundancji danych – te same wartości będą przechowywane w kilku tabelach; z praktycznego punktu widze-nia trudno znaleźć uzasadnienie dla takiej opcji. Ustawiewidze-nia okna dialogowego oraz model PDM dla przypadku generowania trzech tabel powiązanych poprzez klucze ilustruje rys. 7.27. W przypadku generowania wszystkich tabel przy wprowadzaniu danych zachodzi konieczność uwzględnienia (podobnie jak w przypadku związków wykluczających) dodatkowych warunków spójności. Często wykorzystywanym mecha-nizmem jest perspektywa, zarówno dla odczytu, jak i wprowadzania danych.

Mniejsze wątpliwości budzi wariant generowania tabel odpowiadających encjom potomnym z dołączeniem kolumn dziedziczonych po encji rodzicu do każdej z tabel.

Tryb ten jest często stosowany w praktyce ze względu na późniejszy sposób pracy programów użytkowych z bazą danych – programy pracują na tabelach odnoszących się do żądanych podtypów.

Model PDM - tabele powiązane poprzez klucze

ID_PRACOWNIKA = ID_PRACOWNIKA

ID_PRACOWNIKA = ID_PRACOWNIKA

PRACOWNIK ID_PRACOWNIKA char(10) NAZWISKO long varchar IMIE long varchar

DATA_UR date

MIEJSCE_UR long varchar MIEJSCE_ZAMIESZKANIA long varchar JEDNOSTKA_ORG char(5) STANOWISKO long varchar

DYDAKTYK ID_PRACOWNIKA char(10) TYP_UMOWY long varchar PENSUM integer GODZINY_WYK time NIEDYDAKTYK ID_PRACOWNIKA char(10) PREMIA numeric(5,2) NADGODZ_ROB time NADGODZ_WOL time

Ustawienia dla trybu generowania osobnych tabel w modelu PDM

Model PDM –tabele powiązane poprzez klucz

Rys. 7.27. Okno dialogowe z opcją generowania wszystkich tabel w modelu PDM

Wszystkie przedstawione opcje implementowania dziedziczenia mają zarówno wady, jak i zalety, których nie można oszacować bezwzględnie, czyli bez pominięcia kontekstu (celu, jakiemu ma służyć projektowana baza danych, funkcji, jakie będą realizowane przez aplikacje użytkowe w odniesieniu do bazy danych, rodzaju pamię-tanych danych itp.). Projektant może podjąć decyzję, która z opcji jest najwłaściwsza, opierając się na wynikach analizy całego systemu i mając na uwadze, że baza danych jest jedną z jego składowych, fundamentalną, ale nie samoistną.