Modele danych.

Stworzono wiele modeli danych pozwalających na zarządzanie bazami danych, w których występują takie typy relacji. Trzy najczęściej używane modele to: hierarchiczny, sieciowy i relacyjny model danych.

Hierarchiczny model danych.

Hierarchiczny model danych przedstawia relacje pomiędzy elementami danych w postaci struktury drzewiastej o wielu gałęziach. Jeśli miałbyś użyć hierarchicznego modelu danych do przedstawienia relacji pomiędzy trzema obiektami danych z naszego przykładu (biura, sprzedawcy, regiony), to wyglądałoby to tak, jak na rysunku 4

Jak widać na rysunku, model ma trzy poziomy, jeden poziom główny i dwa poziomy niższego rzędu. Pierwszy poziom opisuje Biuro Sprzedaży, a każda z jego gałęzi reprezentuje element obiektu danych i prowadzi do różnej liczby poddrzew. Z kolei, każde z tych poddrzew reprezentuje kolejny obiekt danych-Sprzedawcę. W miarę rozbudowy modelu, każdy z pracowników zatrudnionych przy sprzedaży otrzymuje własne poddrzewo kolejnego poziomu- w tym przypadku trzeciego\ odpowiadające obiektowi danych Region Sprzedaży.

Rys. 4 Hierarchiczny model danych.

Kiedy patrzy się na model hierarchiczny na rysunku 4. to widać, że wszystkie elementy danych są zorganizowane w bardzo logiczny sposób; to znaczy każda wartość obiektu danych jest logicznie powiązaną z jedną lub kilkoma wartościami innego obiektu danych. Można określić wartość dla każdego z obiektów danych oraz wszystkie relacje pomiędzy nimi. Jeśli jednak przestudiowalibyśmy ten model nieco dokładniej, to można zauważyć, że model hierarchiczny pozwala zobrazować jedynie relacje jedno-jedno i jedno-wiele lub wiele-jedno. W celu uwzględnienia relacji wiele-wiele trzeba je zrestrukturyzować do postaci powtarzających się relacji jedno-wiele.

Relacje wiele-wiele zachodzą pomiędzy obiektami danych odpowiadającymi pracownikom sprzedaży i regionom sprzedaży. Oznacza to że sprzedawca może mieć więcej niż jeden region sprzedaży, a region sprzedaży może być przypisany więcej niż jednemu sprzedawcy. Na przykład sprzedawcy Frankowskiemu przypisano dwa regiony sprzedaży R4 i R6, a każdy z tych regionów przypisano więcej niż jednemu sprzedawcy. Region R4 przypisany dwóm sprzedawcom: Frankowskiemu i Jankowskiemu, itd.

Wróćmy do modelu hierarchicznego z rysunku 4. Zauważmy że relacje typu wiele-wielu musza zostać zestrukuralizowane do powtarzających się relacji jedno-wiele. Zwróć uwagę, że w przypadku struktur drzewiastych, jedna gałąź może prowadzić do wielu podgałęzi, lecz wszystkie podgałęzie prowadzą zawsze do tylko jednej gałęzi wyższego poziomu. Aby dostosować się do tego typu struktury, konieczne jest powtarzanie pewnych obiektów w wielu podgłęziach w celu opisania relacji wiele-wiele poprzez kilka relacji jedno-wiele.

Na rysunku 4. widać także, że niektóre obiekty poziomu Region występują wielokrotnie jako podgałęzie, aby można było opisać ich relacje w stosunku do obiektów Sprzedawca tak, jak - na przykład - region R4 pojawiający się dwukrotnie w podgałęziach. W każdym z wystąpień pozostaje on w relacji do obiektów Sprzedawca-raz w stosunku do Frankowskiego, drugi raz w stosunku do Jankowskiego W celu uniknięcia tego typu powtórzeń opracowano inny model danych. Model ten nazywa się modelem sieciowym.

Sieciowy model danych.

Na sieciowy model danych można spojrzeć jak na zmodyfikowaną wersję modelu hierarchicznego. Elementy danych są w nim zorganizowane w strukturę drzewiasta podobnie jak w przypadku modelu hierarchicznego. Jednak, inaczej niż w modelu hierarchicznym, model sieciowy pozwala na definiowanie relacji wiele-wiele w postaci struktury drzewiastej bez powtarzania poszczególnych wartości w ramach obiektu danych. Na rysunku 5 przedstawiono relacje pomiędzy tymi samymi obiektami danych w postaci modelu sieciowego.

Zwróć uwagę, że model ten wygląda bardzo podobnie do przedstawionego rysunku 4 oba te modele wykorzystują struktury drzewiaste do przedstawienia relacji pomiędzy obiektami danych. Ponieważ relacja pomędzy biurami sprzedaży a pracownikami sprzedaży jest typu jedno-wiele, modele hierarchiczny i sieciowy opisują ją w taki sam sposób.

Rysunek 5

Lecz sposób, w jaki model sieciowy opisuje relacje wiele-wiele pomiędzy pracownikami sprzedaży a regionami sprzedaży, jest nieco inny niż w przypadku modelu hierarchicznego.

Istotną różnicą jest to, że w modelu sieciowym każdy element obiektu danych Region zawsze występuje jako tylko jedna podgałąź. Ponadto, podgałęzie obiektu danych Region mogą być połączone z więcej niż jedną gałęzią wyższego poziomu. Na przykład, gałąź opisująca Frankowskiego prowadzi do dwóch podgałęzi odnoszących się do regionów R4 i R6. Podgałąź opisująca region R4 wychodzi od dwóch gałęzi odpowiadających Frankowskiemu i Jankowskiemu Gałąź opisująca Jankowskiego odnosi się do regionów R4,R5 i R6, jako że reprezentuje trzy poddrzewa w tym modelu.

W obu tych modelach elementy danych są zorganizowane w sposób logiczny, co pozwala na powiązanie wszystkich elementów danych poprzez zdefiniowanie koniecznych połączeń. W przypadku wyszukiwania pojedynczej informacji w bazie danych, można przejść wzdłuż odpowiednich połączeń w celu odnalezienia poszukiwanej informacji. Aby było to możliwe, system musi jednak dysponować wbudowanym, dość szczegółowym opisem połączeniem w postaci wskaźników określających powiązania pomiędzy obiektami. Dodatkowo, ze względu na przyśpieszenie wyszukiwania, często konieczne jest ułożenie elementów danych w określonym porządku. Te działania porządkujące realizowane są przez takie operacje jak sortowanie czy indeksowanie.

Relacyjny model danych

Relacyjny model danych jest najpopularniejszym z modeli używanych do organizowania i zarządzania elementami danych. Większość oprogramowania mikrokomputerowego przeznaczonego do zarządzania bazami danych jest zaprojektowana zgodnie z tym modelem. FoxPro 2.0, FoxBase, Paradox, Rbase, oraz rodzina oprogramowania dBASE wykorzystują relacyjny model danych do strukturalizacji elementów danych. Jednym z powodów popularności tego modelu jest to że, jest on łatwy do zrozumienia i prosty do zastosowania. Może on być stosowany do strukturalizacji relacji typu jedno-jedno, jedno-wiele oraz wiele-wiele. Mając poprawnie określoną strukturę bazy danych, można z łatwością operować elementami danych. Odnajdywanie pożądanych informacji staje się bardzo szybkie, jeśli wszystkie powiązania i relacje pomiędzy obiektami danych zostały uwzględnione.

W relacyjnym modelu danych wszystkie elementy danych oraz relacje pomiędzy obiektami danych są zorganizowane w tablice danych. Tablice danych wykorzystuje się do przechowywania elementów danych związanych z konkretnymi obiektami danych. Podobnie, wszystkie relacje pomiędzy obiektami są także zapisane jako elementy danych w tablicach danych. W efekcie, baza danych według modelu relacyjnego składa się ze zbioru tablic danych.

Aby dać lepsze pojęcie o tym jak organizować elementy danych według relacyjnego modelu danych i przechowywać je w tablicach danych, kontynuujmy rozważania na przykładzie obiektów danych użytych przy omawianiu dwóch poprzednich modeli- Sprzedawców, Biur Sprzedaży i Regionów Sprzedaży. Każdy z nich ma pewną liczbę obiektów, które z kolei mają pewne zestawy własności. Elementy danych są wykorzystywane do opisu tych własności.

Jeśli przyjrzeć się obiektowi danych Sprzedawcy, to widać, że zawiera on pewną liczbę obiektów, z których każdy reprezentuje sprzedawcę: Adamskiego, Bednarskiego, Czajkowskiego, i tak dalej. Każdy element obiektu danych Sprzedawcy posiada pewien zbiór własności obejmujący numer identyfikacyjny sprzedawcy, nazwisko, imię, wynagrodzenie oraz datę zatrudnienia. Elementy danych wykorzystywane do opisu własności są zbiorami znaków w postaci liter alfabetu, cyfr i symboli. Na przykład, element danych opisujących imię Bednarskiego zawiera ciąg znaków czytany jako "Bartek". Zbiór cyfr i symboli-"10/12/88"-określa element danych będący datą jego zatrudnienia. Wszystkie elementy danych obiektu danych Sprzedawcy mogą zostaę zorganizowane w tablicę wyglądającą tak jak to pokazano na rysunku 6

Na rysunku 6 wszystkie elementy danych opisujące własności obiektu danych Sprzedawcy zebrano w tablicy. Można przypisać tablicy nazwę - w tym przypadku Sprzedawcy - dla potrzeb identyfikacyjnych oraz w celu łatwego odwoływania się doń Sama tablica podzielona jest na pewną liczbę kolumn i wierszy; każda z kolumn może być także nazwana i wykorzystywana do przechowywania elementów danych opisujących poszczególną własność obiektu danych - w tym wypadku z konkretnym sprzedawcą. Wiersze są identyfikowane poprzez kolejne numery nadawane im w miarę dodawania wierszy do tablicy; nie ma potrzeby przypisywania nazw poszczególnym wierszom w tablicy.

W tablicy Sprzedawcy, na przykład, przechowywane są wszystkie elementy danych opisujące wszystkie nazwiska pracowników zatrudnionych przy sprzedaży w kolumnie o nazwie "Nazwisko". Wynagrodzenia miesięczne przechowywane są w kolumnie "Wynagrodzenia". Każdy wiersz w tablicy danych Sprzedawcy zawiera elementy danych opisujące wszystkie własności (numer identyfikacyjny, nazwisko, imię, data zatrudnienia, wynagrodzenie) danego sprzedawcy.

Tabela: Sprzedawcy
Id sprzedawcy	Nazwisko	ImiÄ™	Data zatrudnienia	Wynagrodzenie
S0	Adamski	Paweł	07/01/86	2,800
S1	Bednarski	Bartek	10/12/86	2,400
S2	Czajkowski	Jacek	05/14/87	2,550
S3	Dziedzic	Edward	06/04/90	1,500
S4	Frankowski	Henryk	03/08/88	2,000
S5	Ford	Ida	11/22/87	2,600
S6	Nowak	Franek	04/15/87	2,300
S7	Jankowska	Katarzyna	12/01/89	2,450
S8	Idzikowski	Albert	10/25/88	2,200
S9	Kowalska	Beata	09/26/89	2,500

Rys. 6 Tablica danych w modelu relacyjnym.

Wykorzystując podobną strukturę, można zorganizować wszystkie elementy danych związane z biurami sprzedaży i regionami sprzedaży w dwie oddzielne tablice danych o nazwach Biura i Regiony, jak to pokazano na rysunku 7

Widać na tym rysunku, że tablice Biura i Regiony mają taki sam układ jak tablica Sprzedawcy. Obie są podzielone na wiersze i kolumny, gdzie każdy wiersz zawiera elementy danych odpowiadające określonemu obiektowi danych, a każda kolumna zawiera elementy danych związane z określoną własnością tego obiektu.

Tabela: Biuro
Id Biura	Adres	Miasto	Województwo	Kod	Telefon #
B1	100	Warszawa	warszawskie	10016	800-123-5555
B2	200	Poznań	poznańskie	60607	800-234-5555
B3	500	Kraków	krakowskie	94005	800-456-5555
Tabela: Regiony
Id Regionu	Region	Kierownik
R1	PÅ‚n-wsch	Alicja Kowalska
R2	PÅ‚d-wsch	Bogdan Wilk
R3	Północ	Jacek Lis
R4	Południe	Katarzyna Nowacka
R5	PÅ‚n-zach	Krzysztof Pac
R6	PÅ‚d-zach	Helena Koniecpolska

Rys. 7 Tablice Biura i Regiony.

W tablicy Biura elementy danych opisujące własności biur - numer identyfikacyjny, adres, numer telefonu - są przechowywane w kolumnach. Każdy wiersz tablicy zawiera elementy danych związane z konkretnym biurem. Podobnie, w tablicy Regiony, własności regionów są przechowywane w kolumnach. Na przykład, kolumna o nazwie Kierownik zawiera elementy danych określające nazwiska kierowników regionów.

W relacyjnym modelu danych baza danych zawiera na ogół więcej niż jedną tablicę danych i trzeba wiedzieć, że takie tablice danych są często w terminologii oprogramowania relacyjnych baz danych takiego jak FoxPro 2.0 nazywane plikami bazy danych. Każdy wiersz w tablicy nazywany jest rekordem danych i zawiera pewną liczbę pól danych, z którego każde odpowiada kolumnie w tablicy danych. Zatem, elementy danych w relacyjnej bazie danych są zorganizowane w pliki bazy danych (tablice danych). Każdy plik bazy danych zawiera pewną liczbę rekordów (wierszy tablicy), a każdy rekord - pewną liczbę pól (kolumn tablicy).

Wykorzystując tę terminologię relacyjnych baz danych, można opisać bazę danych składającą się ze Sprzedawców, Biur i Regionów w następujący sposób:

Nazwa tablicy:	Sprzedawcy
Liczba rekordów:	10
Pola danych:	Identyfikator sprzedawcy
	Nazwisko
	ImiÄ™
	Data zatrudnienia
	Wynagrodzenie
Nazwa tablicy:	Biura
Liczba rekordów:	3
Pola danych:	Numer identyfikacyjny
	Adres
	Miasto
	Województwo
	Kod pocztowy
	Numer telefoniczny
Nazwa tablicy:	Regiony
Liczba rekordów:	6
Pola danych:	Numer identyfikacyjny
	Region
	Kierownik

Jak podano wcześniej w tym rozdziale, relacyjny model danych nie tylko zbiera wszystkie elementy danych opisujące obiekty danych w tablice danych; tablice danych są także wykorzystywane do przechowywania elementów danych opisujących relacje pomiędzy tymi obiektami. Chociaż wkrótce nauczysz się jeszcze więcej o tym, w jaki sposób tworzyć wykorzystywać tablice danych tego typu, to już teraz na rysunku 8 pokazano przykład takiej tablicy relacyjnej nazwanej Przypisanie.

Jeśli porównasz strukturę tablicy Przypisanie z tablicami Sprzedawcy, Biura czy Regiony, to bez trudu odnajdziesz podobieństwa. Wszystkie one są zorganizowane w wiersze i kolumny. Lecz pomiędzy tablicami Sprzedawcy a Przypisanie jest znacząca różnica. Przypomnijmy, że wiersz w tablicy Sprzedawcy opisywał własności określonego sprzedawcy. Inaczej niż w tablicy Sprzedawcy, wiersz w tablicy Przypisanie określa powiązanie pomiędzy regionem sprzedaży a sprzedawcą. Na przykład, pierwszy wiersz w tej tablicy zawiera dwa elementy danych R1 i S1, przechowywane w kolumnach o nazwach Numer Regionu i Numer Sprzedawcy. Elementy danych w pierwszym wierszu opisują powiązanie regionu sprzedaży R1 ze sprzedawcą S1.

Takie relacyjne bazy danych mają znaczący wpływ na sprawność pracy i użyteczność relacyjnej bazy danych. Gdy są one poprawnie ze strukturalizowane, możliwe jest posługiwanie się dowolnymi relacjami zachodzącymi pomiędzy obiektami danych. O relacyjnych tablicach danych dowiesz się więcej w dalszej części tego rozdziału.

Tabela: Przypisanie
Id regionu	Id sprzedawcy
R1	S0
R1	S3
R1	S6
R1	S9
R2	S2
R2	S5
R3	S2
R3	S8
R4	S4
R4	S7
R5	S1
R5	S7
R6	S4
R6	S7

Rys. 8 Tablica relacyjna.