Streszczenie
Artykuł porusza kwestie modelowania wybranych zagadnie dotyczcych da-nych hierarchiczda-nych, uwzgldnienia zjawisk zmieniajcych si wraz z upływem cza-su, a istotnych z punktu widzenia funkcjonalnoci projektowanego systemu oraz uwzgldnienia podziału kategorii encji. Treci zawarte w artykule zaprezentowano w zwartej postaci, stanowi tym samym gotowe rozwizania wybranych problemów, z jakimi spotka moe si osoba zajmujca si modelowaniem danych.
Słowa kluczowe: modelowanie danych, modelowanie czasu, modelowanie danych hierarchicznych
1. Wprowadzenie
Artykuł zaznajamia czytelnika z moliwo ciami modelowania rónego rodzaju funkcjonalno- ci wymaganych od projektowanego systemu przy wykorzystaniu relacyjnego modelu danych. Prezentowane s rónego rodzaju zwizki i konstrukcje modeli danych, z którymi, na co dzie ma do czynienia osoba zajmujca si modelowaniem danych oraz projektowaniem baz danych. Poru-szana jest w nim zarówno kwestia stopnia zwizków, typu asocjacji, typu zwizku czy te jego istnienia. Zaprezentowano równie bardzo istotne zagadnienia, z którymi mierzy si modelarz danych, jak cho by uwzgldnienie zmienno ci w czasie zarówno atrybutów encji, jak i samych zwizków; odwzorowanie hierarchicznej struktury organizacji przy wykorzystaniu zwizków rekurencyjnych i sieciowych, czy te modelowanie hierarchii encji logicznych ze wskazaniem sposobów ich realizacji w modelu fizycznym, jednocze nie podkre lajc wady i zalety poszcze-gólnych rozwiza. Wybrane przykłady oprócz prezentacji modeli logicznych zilustrowane zosta-ły modelami fizycznymi implementowanymi w wybranych rodowiskach SZBD oraz fragmentami kodu SQL.
2. Związki
Zwizki w diagramach ERD pozwalaj definiowa istniejce powizania pomidzy encjami, bdcymi odzwierciedleniem rzeczywistych obiektów istniejcych w realnym wiecie dla mode-lowanego systemu. Kady zwizek okre li mona za pomoc pewnych cech takich jak: stopie zwizku, typ asocjacji, typ zwizku oraz jego istnienie [7,8,15,16].
Stopie zwizku okre la liczb biorcych w nim udział encji. Wyróni mona nastpujce rodzaje zwizków: unarny (łczcy encje sam ze sob), binarny (łczcy dwie encje), tenarny (łczcy trzy encje), n-arny (łczcy n-encji). Zwizki o stopniu wikszym o dwóch okre lane s mianem zwizków złoonych.
43
Typ asocjacji zwany take kardynalno ci zwizku okre la liczb wystpie jednej encji po-wizanych z okre lon liczb wystpie drugiej encji. Wyróni mona nastpujce typy zwiz-ków: 1:1 (jeden do jednego), 1:n (jeden do wielu) oraz n:m (wiele do wielu).
Typ zwizku okre la jego identyfikujcy lub nieidentyfikujcy charakter. Zwizek jest identy-fikujcy, gdy do identyfikacji egzemplarza encji podrzdnej niezbdny jest egzemplarz encji nad-rzdnej. Innymi słowy klucz obcy encji zalenej wchodzi w skład jej klucza głównego. Zwizek jest nieidentyfikujcy, gdy do identyfikacji egzemplarza encji podrzdnej nie jest potrzebny eg-zemplarz encji nadrzdnej. Tym samym w przeciwiestwie do zwizku identyfikujcego klucz obcy nie wchodzi w skład klucza głównego encji podrzdnej.
Istnienie zwizku okre la, czy dany zwizek jest opcjonalny, czy obowizkowy. Innymi słowy okre la, czy atrybut klucza obcego moe przyjmowa warto NULL, czy te musi dla niego ist-nie odpowiadajcy mu egzemplarz w encji nadrzdnej. Istnienie zwizku nazywane bywa take klas przynaleno ci zwizku.
2.1. Związek unarny
Zwizek unarny jest zwizkiem jednoargumentowym łczcym encje sam ze sob [7,8,15,16]. Nazywany take bywa zwizkiem rekurencyjnym. Jest to zwizek, w którym ten sam zbiór encji wystpuje wicej ni jeden raz w rónych rolach. Kady element podrzdny moe posiada tylko jeden element nadrzdny.
Rysunek 1. Zwizek unarny
ródło: opracowanie własne na podstawie [7]. 2.2. Związek binarny
Zwizek binarny jest zwizkiem dwuargumentowym łczcym ze sob dwie encje [3,7,8,15,16]. Jest to najcz ciej wystpujcy zwizek. Poniszy rysunek jest ilustracj zwizku binarnego, modelujcego fragment rzeczywisto ci, w której województwa zamieszkiwane s przez studentów.
Rysunek 2. Zwizek binarny
ródło: opracowanie własne na podstawie [7].
Studies & Proceedings of Polish Association for Knowledge Management Nr 62, 2012
2.3. Związek tenarny
Zwizek tenarny, zwany take zwizkiem potrójnym jest zwizkiem trójargumentowym ł-czcym ze sob trzy encje [7,8,15,16]. Rysunek 3 ilustruje zwizek tenarny modelujcy fragment wiata rzeczywistego, gdzie wykładowcy z okre lonych przedmiotów wpisuj konkretne oceny do konkretnych kart egzaminacyjnych.
Rysunek 3. Zwizek tenarny
ródło: opracowanie własne na podstawie [7]. 2.4. Związek n-arny
Zwizki n-arne to zwizki o stopniu wikszym ni trzy [7,8,15,16]. Jako przykład podano zwizek poczwórny o stopniu równym cztery. Zwizek przedstawiony na rysunku 4 jest rozsze-rzeniem zwizku tenarnego z podrozdziału 2.3. Przedstawia on zaleno bdc odzwierciedle-niem wiata rzeczywistego, w której ten sam wykładowca ma moliwo wpisania oceny z tego samego przedmiotu do karty egzaminacyjnej zarówno z wykładu, jak i z laboratorium.
Rysunek 4. Zwizek poczwórny
ródło: opracowanie własne na podstawie [7]. 2.5. Charakterystyka typów asocjacji
W kolejnych trzech podrozdziałach zaprezentowane pokrótce zostały podstawowe typy aso-cjacji w ród, których wyróni mona zwizki typu: 1:1, 1:n, m:n, oraz zwizek przechodni. 2.5.1. Związek typu 1:1
Zwizek typu 1:1 kademu egzemplarzowi jednej encji przyporzdkowuje, co najwyej jeden egzemplarz drugiej encji [4,7,8,9,10,13,14]. Ze wzgldu na fakt, i ten typ asocjacji narusza reguły normalizacji jest on niezmiernie rzadko implementowany w relacyjnych bazach danych. Imple-mentacja tego typu asocjacji uzasadniona jest tylko w kilku przypadkach spo ród, których
wyró-45
ni mona separacj danych poufnych od pozostałych danych dotyczcych tego samego klienta; czy przypadek, gdy liczba atrybutów encji logicznej przekracza dozwolon liczb pól tabeli fi-zycznej dla konkretnego rodowiska SZBD, wówczas jedna encja logiczna rozdzielana jest na kilka tabel fizycznych, powizanych ze sob za pomoc klucza głównego.
2.5.2. Związek typu 1:n
Zwizek typu 1:n jest to najcz ciej spotykany i wykorzystywany typ asocjacji. Jednemu eg-zemplarzowi encji nadrzdnej odpowiada zero, jeden lub wiele egzemplarzy encji podrzdnej. Natomiast jednemu egzemplarzowi encji podrzdnej odpowiada zero lub co najwyej jeden eg-zemplarz encji nadrzdnej. Ten typ asocjacji okre lany bywa równie mianem zwizku rodzic-dziecko lub zwizku ogół-szczegół. W modelu fizycznym implementowany jest poprzez umiesz-czenie kopii klucza głównego tabeli nadrzdnej w tabeli podrzdnej, w postaci klucza obcego. W przypadku identyfikacyjnego charakteru zwizku klucz obcy włczany jest w skład klucza głównego tabeli podrzdnej [1,2,3,4,7,8,9,10,13,14,15,16].
2.5.3. Związek typu n:m
Typ asocjacji n:m jest nieco rzadziej wykorzystywany w porównaniu do omówionego w po-przednim podpunkcie. Jednemu egzemplarzowi pierwszej encji logicznej odpowiada zero, jeden lub wiele egzemplarzy drugiej encji logicznej biorcej udział w tym zwizku. Działa to dokładanie tak samo w drug stron. O ile niektóre z narzdzi CASE do modelowania danych pozwalaj na przedstawienie zwizku n:m za pomoc dwóch encji logicznych, o tyle implementacja fizyczna tego rodzaju zwizku dla relacyjnego modelu danych wymaga wprowadzenia dodatkowej tabeli fizycznej tzw. tabeli asocjacyjnej. Innymi słowy zwizek n:m rozkładany jest na dwa zwizki 1:n, a w tabeli asocjacyjnej umieszcza si klucze obce (bdce kopiami kluczy głównych tabel bior-cych udział w zwizku wieloznacznym)-stanowice zarazem jej złoony klucz główny [1,2,4,7,8,9,10,13,14,15,16].
2.5.4. Związek przechodni
Ze wzgldu na fakt, i nie istnieje bezpo redni zwizek pomidzy dwoma encjami biorcymi w nim udział, zwizek ten nazywany jest zwizkiem przechodnim bd te zwizkiem dziadek-wnuk [9]. Egzemplarze encji logicznej dziadek powizane s z egzemplarzami encji logicznej wnuk za po rednictwem dodatkowej encji logicznej. Zwizki biorce udział w zwizku przechod-nim posiadaj typ asocjacji 1:n. Jako ilustracj tego rodzaju zwizku mona przytoczy przykład przedstawiony na rysunku 5 (uproszczony ze wzgldu na czytelno modelu). Student posiada wiele rónych wpisów otrzymywanych po kadym semestrze nauki do karty egzaminacyjnej. Jednake nie istnieje bezpo redni zwizek pomidzy encj Studenci a encj WpisyDoKarty, której zadaniem jest przechowywanie wszystkich informacji przechowywanych w danej Karcie, wydanej konkretnej osobie. Aby zweryfikowa , jakie oceny osignł dany student w okre lonym semestrze z wybranych przedmiotów naley skorzysta z encji po redniej Karta.
Studies & Proceedings of Polish Association for Knowledge Management Nr 62, 2012
KARTA IdKarty IdStudenta (FK) Semestr DataZlozenia STUDENCI IdStudenta Imie Nazwisko WpisyDoKarty IdPrzedmiotu IdFormyZaliczenia IdWykladowcy IdKarty (FK) IdOceny DataWpisu Rysunek 5. Model „Dziadek-Wnuk”
ródło: opracowanie własne. 3. Modelowanie hierarchii
Bardzo czsto spotykanym problem, przed którym staje modelarz danych, jest zamodelowanie hierarchii [1,2,7,10,11,13,14]. Mona tutaj przytoczy wiele przykładów. Jednym z nich bardzo czsto implementowanym moe by podział administracyjny Polski, czy chociaby struktura or-ganizacyjna danego przedsibiorstwa. W najprostszym klasycznym ujciu struktur tak mona przedstawi w postaci prezentowanej na rysunku 6.
WOJEWODZTWA IdWojewodztwa Wojewodztwo GMINY IdGm iny IdPowiatu (FK) Gmina MIEJSCOWOSCI IdMIejscowosci IdGm iny (FK) Miejscowosc POWIATY IdPowiatu IdWojewodztwa (FK) Powiat
Rysunek 6. Hierarchiczny model podziału administracyjnego Polski
ródło: opracowanie własne. 3.1. Związek rekurencyjny
Jako alternatyw dla stworzenia modelowania danych hierarchicznych mona wykorzysta zaprezentowany w podpunkcie 2.1 zwizek rekurencyjny. Podej cie takie znacznie uprasza sam model danych, w stosunku do rozwizania klasycznego. Ponadto jest on znacznie bardziej uniwer-salny w odniesieniu do poprzedniego rozwizania [1,2,3,4,7,8,13,14,15,16].
W podej ciu tym wszystkie jednostki administracyjne, czy te organizacyjne przedstawione s za pomoc jednej encji. Samo powizanie z encj nadrzdn w tym przypadku zostało zorganizo-wane za pomoc ptli wokół jednej encji. Naley pamita , i zwizek rekurencyjny w przypadku modelowania danych hierarchicznych musi by opcjonalny, ze wzgldu na fakt, i jednostka nad-rzdna (nadrzdny egzemplarz encji, zwany take korzeniem hierarchii) nie posiada swojej
wła-47
snej jednostki nadrzdnej. Na rysunku 7 zaprezentowano alternatywne podej cie dla przedstawie-nia modelu hierarchii danych.
TYPY_JEDNOSTEK IdTypu NazwaTypu JEDNOSTKA_ADMINISTRACYJNA IdJednostkiAdm JednostkaNadrzedna (FK) IdTypu (FK) NazwaJednos tki
Rysunek 7. Hierarchiczny model podziału administracyjnego Polski przy wykorzystaniu samozłczenia
ródło: opracowanie własne.
Rysunek 8 przedstawia fizyczn implementacj hierarchicznego modelu danych odwzorowu-jcego podział administracyjny Polski, przy wykorzystaniu zwizku rekurencyjnego w rodowisku MS Access i MS SQL Server.
a)
b)
Rysunek 8. Hierarchiczny model podziału administracyjnego Polski przy wykorzystaniu samo-złczenia implementowany w: a) rodowisku Access, b) rodowisku MS SQL Server
ródło: opracowanie własne.
Poniej przedstawiono kod implementujcy zwizek rekurencyjny przedstawiony na powy-szym rysunku.
CREATE TABLE tbl_Kategoria (
IdKategorii int PRIMARY KEY NOT NULL, Kategoria varchar(30) NOT NULL,
KategoriaNadrzedna int NULL,
CONSTRAINT FK FOREIGN KEY(KategoriaNadrzedna) REFERENCES tbl_Kategoria(IdKategorii)
)
Studies & Proceedings of Polish Association for Knowledge Management Nr 62, 2012
3.2. Związek sieciowy
Zwizek sieciowy pozwala na połczenie ze sob dwóch lub wikszej liczby encji. Jednake w przeciwiestwie do zwizku rekurencyjnego oferuje du wiksz elastyczno [1,7]. Pozwala na modelowanie zaleno ci, w której egzemplarz encji podrzdnej moe posiada wiele egzempla-rzy encji nadrzdnej. Uywany bywa do modelowania m.in. schematów organizacyjnych. Tym samym pozwala na osignicie nieskoczonej głboko ci i szeroko ci sieci. Niemniej jednak w tym przypadku naley mie na uwadze pewne zagroenia, jakie si wi z implementacj zwizku sieciowego na poziomie modelu fizycznego. Mianowicie naley dopilnowa , aby aden rekord nie był jednocze nie swoim elementem podrzdnym i nadrzdnym. Sytuacja taka skutko-wałaby utworzeniem nieskoczonej ptli, w której zapytanie pobierajce dane nie mogłoby zako-czy swojego działania. Jako przykład uycia zwizku sieciowego mona poda przypadek, gdzie dany pracownik moe pełni funkcje kierownicze w jednym projekcie, bdc take podwładnym w innym projekcie. Na rysunku 9 zaprezentowano przykład zwizku sieciowego, który pozwala pracownikom kierowa wieloma projektami oraz jednocze nie przynalee do wielu zespołów projektowych. SkladZespoluProjektowego IdPracownika ImiePracownika NazwiskoPracownika Rola_w_Zespole TelefonPracownika StrukturaZespoluProjektowego NazwaProjektu IdKierownikaProjektu (FK) IdPodwladnego (FK) DataPrzydzieleniaDoZepolu DataZakonczeniaPracy Rysunek 9. Przykład zwizku sieciowego
ródło: opracowanie własne.
Poniej przedstawiono kod SQL implementujcy zwizek sieciowy przedstawiony na powy-szym rysunku.
CREATE TABLE tbl_SkladZespoluProjektowego( IdPracownika int NOT NULL, ImiePracownika varchar(15) NOT NULL, NazwiskoPracownika varchar(30) NOT NULL, Rola_w_Zespole varchar(25) NOT NULL, TelefonPracownika char(9) NULL, PRIMARY KEY CLUSTERED (IdPracownika) )
go
CREATE TABLE tbl_StrukturaZespoluProjektowego( NazwaProjektu varchar(30) NOT NULL,
49
IdKierownikaProjektu int NOT NULL, IdPodwladnego int NOT NULL, DataPrzydzieleniaDoZespolu datetime NOT NULL, DataZakonczeniaPracy datetime NULL,
PRIMARY KEY CLUSTERED (NazwaProjektu, IdKierownikaProjektu, IdPodwladnego) CONSTRAINT FK_SklZesProj_Podwladny FOREIGN KEY (IdPodwladnego)
REFERENCES tbl_SkladZespoluProjektowego(IdPracownika)
CONSTRAINT FK_SklZesProj_Kierownik FOREIGN KEY (IdKierownikaProjektu) REFERENCES tbl_SkladZespoluProjektowego(IdPracownika)
) go
4. Modelowanie czasu
Kolejnym bardzo czsto spotykanym zagadnieniem z jakim musi si zmierzy osoba modelu-jca dane, jest uchwycenie w modelu danych zjawiska zmian w czasie. Zmiany w czasie dotyczy mog zarówno samych atrybutów encji, jak równie zwizków zachodzcych pomidzy poszcze-gólnymi encjami, a w szczególnych przypadkach równie całych encji wraz ze wszystkimi ich atrybutami oraz zwizkami [12]. Jednym z przykładów zastosowania modelu temporalnego jest przechowywanie informacji na temat historii zatrudnienia danego pracownika w danej jednostce oraz jego awansu w poszczególnych latach (z uwzgldnieniem zmiany stanowisk i stopni nauko-wych). Innym przykładem moe by zmiana miejsca zatrudnienia pracownika, a wic przechowy-wania informacji na temat historii rónych miejsc zatrudnienia pracownika, w rónych jednost-kach. Problem ten moe by rozwizany poprzez wprowadzenie dodatkowych encji temporalnych, których zadaniem bdzie przechowywanie danych historycznych. Innym rozwizaniem tego za-gadnienia jest utworzenie specjalnych tabel archiwalnych, w których umieszczane bd rekordy usuwane z bazy danych (lub zastpowane now aktualn warto ci). Zazwyczaj tabele archiwalne wyposaone s w znacznik czasu zdefiniowany w postaci dodatkowego atrybutu. Z uwagi na wy-dajno wyszukiwania informacji, w przypadku bardzo rozbudowanych zbiorów encji rozwizanie z tabel archiwaln bdzie bardziej efektywne.
4.1. Zmiana atrybutów encji w czasie
W celu zilustrowania zmian w czasie warto ci atrybutów dla poszczególnych encji wprowa-dza si do modelu danych odpowiedni ilo encji temporalnych skojarzonych z wybran encj [2,5,12]. Liczba wprowadzonych encji temporalnych jest równa liczbie parametrów, które bd zmienia si w czasie, (stanowic odpowiednik kluczowych zmian z punktu widzenia funkcjonal-no ci projektowanego systemu). Zwizek istniejcy pomidzy encj pierwotn oraz nowo utwo-rzon encj temporaln jest zwizkiem identyfikujcym. W skład klucza głównego encji tempo-ralnej oprócz klucza obcego encji pierwotnej włcza si atrybuty typu Data przechowujce infor-macje na temat od kiedy dana zmiana została wprowadzona (w razie potrzeby mona wprowadzi dodatkowy niekluczowy atrybut do kiedy wprowadzona zmiana obowizywała-warto tego atry-butu powinna by opcjonalna). Na rysunku 10 zaprezentowano model temporalny przechowujcy histori awansu pracowników naukowych z wyszczególnieniem posiadanych stopni naukowych, jak równie piastowanych przez nich stanowisk. Ze wzgldu na fakt, i zdobycie kolejnego stopnia
Studies & Proceedings of Polish Association for Knowledge Management Nr 62, 2012
naukowego nie jest jednoznaczne z automatyczn, jednoczesn zmian stanowiska pracy – zmiany te zostały odwzorowane za pomoc dwóch encji temporalnych.
HISTORIA_STOPNI DataUzyskania IdWykladowcy (FK) IdStopnia (FK) STANOWISKA IdStanowiska Stanowis ko WYKLADOWCY IdWykladowcy Im ie Nazwisko STOPNIE_NAUKOWE IdStopnia Stopien HISTORIA_STANOWISK DataUzyskania IdWykladowcy (FK) IdStanowiska (FK)
Rysunek 10. Zmiana atrybutów encji w czasie
ródło: opracowanie własne. 4.2. Zmiana związku w czasie
W celu zilustrowania zmian zwizku w czasie, do modelu danych podobnie, jak w poprzed-nim przypadku wprowadza si dodatkow encj temporaln, bdc odpowiednikiem encji asocja-cyjnej [2,5,12]. Klucz główny takiej encji temporalnej stanowi klucze obce pochodzce z encji nadrzdnych oraz atrybut bdcy znacznikiem czasu, kiedy takowa zmiana wystpiła (w razie konieczno ci mona wprowadzi dodatkowy atrybut niekluczowy, dopuszczajcy warto ci NULL, przechowujcy dat do kiedy dany pracownik był, w danej jednostce zatrudniony). Na rysunku 11 zaprezentowano model temporalny przechowujcy histori zatrudnienia pracownika w rónych jednostkach. P RODZAJE_JEDNOSTEK IdRodzaju NazwaRodzajuJednostki WYKLADOWCY IdWykladowcy Imie Nazwisko HISTORIA_ZATRUDNIENIA DataZatrudnienia IdWykladowcy (FK) IdJednostki (FK) JEDNOSTKA_UCZELNIANA IdJednostki JednostkaNadrzedna (FK) IdRodzaju (FK) NazwaJednostki
Rysunek 11. Zmiana zwizku w czasie
ródło: opracowanie własne. 5. Związek kategorii encji
Kategoria encji pozwala na zamodelowanie hierarchii encji, gdzie jedna encja pełni rol encji nadrzdnej a pozostałe encje kategorii stanowi podencje w postaci encji podrzdnych [1,2,3,4,6,7,8,10,13,14,15,16]. Zwizek kategorii encji okre lany równie bywa hierarchi encji lub hierarchi uogólnie. Pozwala on na podział encji na podzbiory, przy czym kady podzbiór
51
stanowi cz cało ci. Cechy wspólne dla wszystkich podencji przechowywane s w encji nad-rzdnej, natomiast cechy charakterystyczne dla poszczególnych kategorii encji przechowywane s w odpowiednich podencjach. Zwizek kategorii encji posiada take wyrónik kategorii, którego zadaniem jest klasyfikacja egzemplarza encji nadrzdnej (nadtypu) do jednej z podencji (podtypu). W kontek cie tego stwierdzenia mona wyróni kategori pełn, gdzie kady egzemplarz naden-cji trafia do jednej z podennaden-cji, jak równie kategori niepełn. Kategoria pełna uwzgldnia wszyst-kie typy w przeciwiestwie do kategorii niepełnej. Kategoria niepełna nie zwiera wszystkich pod-typów z rónych wzgldów m.in. gdy nie s znane wszystkie kategorie, kategorie mog zmienia si z biegiem czasu, bd te z okre lonych przyczyn nie uwzgldniono wszystkich kategorii. Wszystkie encje współuytkuj klucz główny encji nadrzdnej. Jako przykład zwizku kategorii przytoczy mona encje nadtypu Płatno oraz encje podtypu Gotówka, Przelew bankowy, Karta
kredytowa.
Kategorie zupełne i niezupełne obrazowane s za pomoc rónych symboli graficznych cha-rakterystycznych dla wybranych notacji modelowania. Na rysunkach 12 i 13 uyto notacji IDEF1X, która w postaci graficznej wyrónia kategorie pełne i niepełne oraz notacji IE na rysun-kach 15 i 16 w celu wizualnego zrónicowania kategorii zawierajcej i wykluczajcej.
StatusOsoby STUDENCI IdOsoby (FK) NrIndeksu KierunekStudiow DataRozpoczecia DataZakonczenia OSOBY IdOsoby Im ie Nazwisko DataUrodzenia StatusOsoby WYKLADOWCY IdOsoby (FK) DataZatrudnienia NazwaJednostki Stanowisko
Rysunek 12. Kategoria pełna
ródło: opracowanie własne.
STUDENCI IdOsoby (FK) NrIndeksu KierunekStudiow DataRozpoczecia DataZakonczenia OSOBY IdOsoby Im ie Nazwisko DataUrodzenia StatusOsoby WYKLADOWCY IdOsoby (FK) DataZatrudnienia NazwaJednostki Stanowisko StatusOsoby
Rysunek 13. Kategoria niepełna
ródło: opracowanie własne.
STUDENCI IdOs oby (FK) NrIndeks u KierunekStudiow DataRozpoczecia DataZakonczenia WYKLADOWCY IdOsoby (FK) DataZatrudnienia NazwaJednos tki Stanowisko StatusOsoby OSOBY IdOsoby Imie Nazwisko DataUrodzenia Status Osoby
Rysunek 14. Kategoria zawierajca
ródło: opracowanie własne.
STUDENCI IdOs oby (FK) NrIndeks u KierunekStudiow DataRozpoczecia DataZakonczenia WYKLADOWCY IdOsoby (FK) DataZatrudnienia NazwaJednos tki Stanowisko OSOBY IdOsoby Imie Nazwisko DataUrodzenia Status Osoby StatusOsoby
Rysunek 15. Kategoria wykluczajca
ródło: opracowanie własne.
Studies & Proceedings of Polish Association for Knowledge Management Nr 62, 2012
Kategorie mona podzieli dodatkowo na zawierajce i wykluczajce. Kategorie zawierajce pozwalaj na przynaleno dowolnego elementu nadtypu do dowolnego elementu podtypu (wielu a nawet wszystkich elementów podtypu). Kategoria wykluczajca zezwala na przynaleno do-wolnego elementu nadtypu tylko do jednego z podtypów. Jako przykład kategorii zawierajcej i wykluczajcej rozway mona encj nadtypu Osoby oraz encje podtypu Student i Pracownik. W przypadku kategorii zawierajcej dana osoba moe by jednocze nie studentem studiów dokto-ranckich oraz pracownikiem Uczelni zatrudnionym na stanowisku asystenta. W przypadku katego-rii wykluczajcej dana osoba moe by albo studentem albo wykładowc.
W modelu fizycznym zwizek kategorii encji mona zaimplementowa na kilka sposobów, spo ród których kady z nich posiada swoje wady i zalety:
a) Osobna tabela dla nadencji i podencji-nadencja przechowuje wszystkie wspólne atrybuty.
Podencje przechowuj atrybuty charakterystyczne dla danej kategorii encji. Pewn wad ta-kiego rozwizania jest konieczno uywania złcze. Rozwizanie takie nazywane bywa równiekategori rozszerzaln. Jest to zarazem domy lne rozwizanie dostpne w wikszo- ci narzdzi CASE do modelowania danych podczas przekształcania modelu logicznego na model fizyczny. Rozwizanie to powoduje utworzenie najwikszej liczby tabel fizycznych, jednocze nie pozwala uywa jednego ródła migracji kluczy obcych nadtypu kategorii. Wybór tego rozwizania daje projektantowi najwiksz elastyczno w tworzeniu struktury i jej rozbudowy. Jest to jednak najbardziej skomplikowana posta w implementacji, ze wzgldu na konieczno przechowywania zasad integralno ci na poziomie bazy danych. Rozwizanie to uywane jest najcz ciej w odniesieniu do bardzo skomplikowanych katego-rii, które wymagaj zarzdzania du liczb kategorii o niepowtarzalnych atrybutach i zwiz-kach.
b) Osobne tabele dla podencji-podencje oprócz zbioru atrybutów charakterystycznych dla
da-nych podencji zawieraj, równie zbiór atrybutów wspólda-nych (umieszczoda-nych w kadej po-dencji). Rozwizanie to sprawdza si znakomicie, gdy podział na kategorie jest rozłczny (np., gdy pracownik nie moe by studentem, ani student pracownikiem). Wada takiego roz-wizania wyranie jest widoczna w przypadku podziału nierozłcznego. Wówczas ta sama informacja bdzie przechowywana wielokrotnie. Rozwizanie takie nazywane bywa równie
rozwijaniem kategorii ze wzgldu na fakt, i wszystkie atrybuty nadtypu umieszczane s
w kadym z podtypów kategorii. Zalet takiego rozwizania jest eliminacja kodu obsługuj-cego poszczególne typy kategorii, gdy kada kategoria jest odrbnym obiektem. Naley uwzgldni wiele ródeł migracji kluczy obcych z kategorii nadrzdnej. Podczas tworzenia zapyta podsumowujcych, stanowicych ródło danych dla raportów kocowych, istnieje konieczno uycia złcze, co w zaleno ci od specyfiki warunków wykorzystania projek-towanego systemu (obcienia, ilo ci i czsto ci zapyta, liczby uytkowników, przepusto-wo ci łcza internetowego) moe mie istotny wpływ na wydajno systemu. Ponadto encje podtypów powinny by zaprojektowane w taki sposób, aby uniemoliwiały przechowywanie warto ci NULL. Dodatkowo, je li zaistniałaby konieczno ujednolicenia połczonych zbio-rów kluczy głównych dla wszystkich podtypów, bdzie ona wymagała dodatkowego opro-gramowania funkcjonalno ci generowania niepowtarzalnych rekordów wzgldem rekordów pozostałych podtypów kategorii. Ten sposób implementacji obiektów fizycznych stosowany jest równie w przypadku, gdy kady podtyp kategorii musi by obsługiwany przez odrbne procesy zwizane m.in. z kwestiami bezpieczestwa, własno ci obiektów czy tworzeniem
53
zaawansowanych, złoonych interfejsów uytkownika.
c) Jedna wspólna tabela – wszystkie atrybuty przechowywane s w obrbie jednej tabeli
fi-zycznej. Wad takiego rozwizania szczególnie widoczn w przypadku kategorii rozłcznej jest dua ilo warto ci NULL dla okre lonych atrybutów tabeli (okre lajcych dan katego-ri). Rozwizanie takie nazywane bywa równie scalaniem kategorii. Reguły biznesowe i zwizki oparte na podtypie wymagaj zakodowania na sztywno wielu zasad zapobiegaj-cych tworzeniu niepoprawnych danych. Wybór tego rozwizania zmniejsza ilo tabel im-plementowanych w modelu fizycznym oraz powstaje jedno ródło migracji kluczy obcych kategorii nadrzdnej.
Przykład implementacji fizycznej hierarchii encji dla wymienionych powyej rozwiza za-prezentowano na rysunku 16. a) b) c) Z Z tbl_OSOBY IdOsoby (PK) Imie Nazwisko DataUrodzenia StatusOsoby tbl_STUDENCI IdOsoby (PK)(FK) NrIndeksu KierunekStudiow DataRozpoczecia DataZakonczenia tbl_WYKLADOWCY IdOsoby (PK)(FK) DataZatrudnienia NazwaJednostki tbl_STUDENCI IdStudenta (PK) Imie Nazwisko DataUrodzenia NrIndeksu KierunekStudiow DataRozpoczecia DataZakonczenia tbl_WYKLADOWCY IdWykladowcy (PK) Imie Nazwisko DataUrodzenia DataZatrudnienia NazwaJednostki tbl_OSOBY IdOs oby (PK) Imie Nazwisko DataUrodzenia NrIndeks u KierunekStudiow DataRozpoczecia DataZakonczenia DataZatrudnienia NazwaJednostki
Rysunek 16. Implementacja fizyczna hierarchii encji w postaci: a) kategorii rozszerzalnej, b) rozwinicia kategorii, c) scalenia kategorii
ródło: opracowanie własne. 6. Podsumowanie
W artykule zaprezentowano przegld rónego rodzaju zwizków, za pomoc, których moli-we jest tworzenie rónorodnych modeli danych reprezentujcych przeróne rodowiska pracy. Za pomoc wybranych zwizków moliwe jest odwzorowywanie zaleno ci zachodzcych w wiecie rzeczywistym, takich jak zagadnienia zwizane z odwzorowaniem hierarchii istniejcej w danym przedsibiorstwie, czy te innej organizacji, instytucji, czy jednostce administracyjnej. W zaleno- ci od wzajemnych relacji istniejcych pomidzy poszczególnymi obiektami wchodzcymi w skład struktury hierarchicznej moe by ona modelowana w sposób klasyczny przy uyciu okre- lonej liczby zwizków typu 1:n (o jeden mniejszej w stosunku do liczby wystpujcych encji), za pomoc zwizku rekurencyjnego lub te zwizku sieciowego.
W przypadku, gdy specyfika modelu wymaga uwzgldnienia w nim zmian zachodzcych w czasie, (chociaby przechowywania zmian cen wybranych produktów, historii awansu danego pracownika z jednoczesn rejestracj zarówno zmiany samych stanowisk, jak i miejsca zatrudnie-nia) wówczas modelarz danych ma kilka moliwo ci do wyboru. Jedn z nich jest wprowadzenie dodatkowych tzw. encji temporalnych, których zadaniem bdzie przechowywanie okre lonych danych historycznych, bd te zaimplementowanie w modelu fizycznym odpowiedniej ilo ci dodatkowych tabel archiwalnych (stanowicych odpowiednik archiwum danych – magazynu na
Studies & Proceedings of Polish Association for Knowledge Management Nr 62, 2012
dane usuwane wg ustalonego algorytmu z tabel roboczych), które najcz ciej nie s projektowane w modelu logicznym.
Oczywi cie róne problemy mog by rozwizywane przez projektantów w róny sposób, co wynika nie tylko ze specyfiki danego zagadnienia, ale take z samego do wiadczenia i wiedzy osób zajmujcych si modelowaniem danych, jak równie dodatkowych załoe i warunków ograniczajcych powizanych z modelowanym zagadnieniem. Z pozoru podobne lub wrcz iden-tyczne zagadnienie moe by zupełnie odmiennie zrealizowane przez róne osoby, a nawet t sam osob, gdy uwzgldnione zostan specyficzne wymagania zdefiniowane przez klienta, jak równie uwzgldniona zostanie specyfika pracy zaimplementowanego systemu w konkretnym otoczeniu ( rodowisku produkcyjnym). Nie bez znaczenia bdzie znajomo wybranych SZBD oraz moliwo ci, jakie one oferuj. Dobrym przykładem ilustrujcym rozwizanie tego problemu jest modelowanie hierarchii encji opisanej w rozdziale 5, gdzie odwzorowanie modelu logicznego, w model fizyczny moe mie identyczn bd te z goła odmienn posta . Natomiast wybór spo-sobu fizycznej realizacji tej konstrukcji, spoczywajcy na projektancie uzaleniony jest od specy-fiki danego problemu i powinien by poprzedzony dogłbn analiz zysków i strat optujcych za wybraniem konkretnego rozwizania.
Nie istnieje jedno jedynie zawsze słuszne rozwizanie, które moe by stosowane do zamode-lowania kadego przypadku. Kady przypadek wymaga indywidualnego, elementarnego potrak-towania przez projektanta. W zwarty sposób zaprezentowano zagadnienia zwizane z modelowa-niem wybranych struktur danych, w postaci gotowych rozwiza, z którymi zaznajomiona powin-na by kada osoba zawodowo zajmujca si modelowaniem danych, czy te projektowaniem i tworzeniem baz danych za pomoc relacyjnego modelu danych.
Bibliografia
[1] Allen S., Modelowanie danych, Helion, Gliwice 2005.
[2] Banachowski L. i in., Relacyjne bazy danych. Wykłady i wiczenia, Wydawnictwo PJWSTK, Warszawa 2009.
[3] Banachowski L., Stencel K., Systemy zarzdzania bazami danych, Wydawnictwo PJWSTK, Warszawa 2007.
[4] Barker R., Case Method. Modelowanie zwizków encji, WNT 2005.
[5] Ben-Gan I., i in., Microsoft SQL Server 2008 od rodka: Programowanie w jzyku
T-SQL, APN Promise, Warszawa 2009.
[6] Ben-Gan I., i in., Microsoft SQL Server 2008 od rodka: Zapytania w jzyku T-SQL, APN Promise, Warszawa 2009.
[7] Connolly T., Begg C., Systemy baz danych. Praktyczne metody projektowania,
implementacji i zarzdzania-Tom I, RM, Warszawa 2004.
[8] Gracia-Molina H., Ullman D., Widom J., Systemy baz danych. Kompletny podrcznik, Helion, Gliwice 2011.
[9] Groh M. i in., Access 2007. Biblia, Helion, Gliwice 2008.
[10] Johnson E., Jones J., Modelowanie danych w SQL Server 2005 i 2008, Helion, Gliwice 2009.
[11] Karwin B., Antywzorce jzyka SQL. Jak unikn pułapek podczas programowania baz
55
[12] Matysiak M., (15.06.2012), Modelowanie wersji danych, [On line]. Dostpne: http://www.ploug.org.pl/plougtki.php?action=read&p=4&a=3.
[13] Muller R. J., Bazy danych – jzyk UML w modelowaniu danych, MIKOM Warszawa 2000. [14] Roszkowski J., Analiza i projektowanie strukturalne, Helion, Gliwice 2004.
[15] Teorey T. Database modeling and design: The fundamental principles, Morgan Kaufmann, San Mateo 1994.
[16] Teorey T., i in., Database modeling and design: Logical design, Morgan Kaufmann, San Francisco 2006.
CREATION OF RELATIONAL DATA MODELS Summary
The article discusses issues relating to selected aspects of modeling of hierar-chical data, take into account the effects of changing over time, relevant to the func-tionality of the designed system and take into account distribution of the category en-tities. The contents of the article presents in compact form thus providing complete solutions to selected problems which can meet the person responsible for data mod-eling.
Keywords: data modeling, modeling of time, modeling of hierarchical data
Sebastian Łacheciski
Katedra Informatyki Ekonomicznej Wydział Ekonomiczno-Socjologiczny Uniwersytet Łódzki
ul. Rewolucji 1905 r. nr 37, 90-214 Łód e-mail: slachecinski@uni.lodz.pl
Studies & Proceedings of Polish Association for Knowledge Management Nr 62, 2012
