Maria Chaon

SYSTEMY BAZ DANYCH

Wprowadzenie

Oficyna Wydawnicza Politechniki Wrocawskiej

Wrocaw 2001

3

PRZEDMOWA

Nie ulega wtpliwoci, e systemy baz danych zajmuj bardzo wane miejsce we wspczesnych metodach tworzenia systemw informacyjnych. Waciwie zapisane i przekazane informacje powikszaj wspln wiedz, dlatego spraw duej wagi jest sposb ich zapisywania. Jzyk naturalny, tak wygodny w przypadku swobodnego porozumiewania si ludzi, nie jest dostatecznie precyzyjnym narzdziem zapisu i przechowywania informacji w komputerze. Odpowiednio zebrane i zestrukturalizo-wane informacje tworz modele danych bdce podstaw tworzenia systemw baz danych. Wanie to nastawienie na praktyczn stron zagadnienia odrnia t ksik od innych, bardziej teoretycznych podrcznikw o tej tematyce. Publikacja ta powsta-a jako rozszerzona wersja treci zaj prowadzonych dla studentw kierunku Infor-matyka. Podstawowym celem autorki byo czenie wiedzy teoretycznej lecej u podstaw systemw baz danych z praktycznym wykorzystaniem opisywanych metod. W zwizku z tym ukad ksiki jest nastpujcy:

1. Cz I stanowi wprowadzenie do II, III i IV czci ksiki i zawiera opis pod-stawowych cech bazy, krtk histori baz danych oraz definicj podstawowych poj, ktrymi operuje si w kolejnych czciach podrcznika lub ktre stanowi istotn dla dalszych rozwaa informacj. W ostatnim rozdziale czci pierwszej opisano meto-dologi projektowania baz danych.

2. W czci drugiej po krtkim wprowadzeniu przedstawiono wybrane metody re-prezentacji danych, takie jak model relacyjny, model obiektowy oraz dedukcyjny. Cz ta zawiera opis przedstawianych modeli.

3. W czci trzeciej podano przykady implementacji wybranych systemw. Dla modelu relacyjnego wprowadzono nieproceduralny jzyk czwartej generacji SQL, ilustrujc jego wasnoci licznymi przykadami. Aplikacja o nazwie Orodek Wypo-czynkowy jest przykadem bazy obiektowej. Jako przykad bazy dedukcyjnej posuy opis Laboratorium Medycznego.

4. W czci czwartej szczeglny nacisk pooono na architektur rozproszonych baz danych. Jako przykad narzdzia do realizacji rozproszonych pod wzgldem funk-cji i danych baz posuy system Informix. W rozdziale tym nie mogo zabrakn rwnie sposobu prezentacji danych w Internecie.

4

Satysfakcjonujce poczenie wiedzy teoretycznej z praktycznym jej wykorzysta-niem jest zawsze niezwykle trudne. W tym wypadku mamy do czynienia z wieloma problemami dotyczcymi baz danych i z potrzeb wybrania tych, ktre w istotny i znaczcy sposb reprezentuj aktualn wiedz na temat baz, a take maj szans rozwoju i wykorzystania w przyszoci.

Zawarty w ksice materia zainteresuje nie tylko studentw informatyki zajmuj-cych si teori i praktycznym tworzeniem baz danych w systemach informatycznych, lecz take tych wszystkich informatykw, ktrzy w swojej pracy zawodowej zajmuj si przetwarzaniem danych.

5

CZ I

Wprowadzenie do problematyki baz danych

Projektowanie bazy danych powinno rozpoczyna si zawsze od analizy informacji, ktre maj znale si w bazie i powiza istniejcych midzy nimi. W wyniku wstpnej fazy prac powstaje schemat pojciowy, stanowi on model informatyczny rozwaanego systemu informacji.

C. Delobel, M. Adiba

6

1. WSTP

Rozpowszechnio si bdne przekonanie, e bazy danych i systemy zarzdzania bazami danych dotycz bahej dziedziny zapamitywania i uzyskiwania danych. By moe sprawi to angielski wyraz datum wywodzcy si z aciny i oznaczajcy dosow-nie fakt. Dane jednak nie zawsze odpowiadaj faktom. Czasami nie s sprecyzowane lub opisuj co, co si nigdy nie zdarzyo, np. ide. Okazuje si jednak, e problem nie tkwi w danych i sposobie ich zapisu, ale w ich interpretacji. Interpretacja danych moe by zawarta w samych danych lub w programach, ktre z nich korzystaj. Dopiero dane i ich interpretacja tworz peny obraz wycinka rzeczywistoci, ktr chcemy opisa za pomoc komputera. Jest oczywiste, e potrzebujemy na tyle abstrakcyjnej interpretacji, aby tolerowaa ona pewne zaburzenia wiata rzeczywistego, a jednocze-nie bya dostatecznie cisa, dajc pojcie o tym, jak dane s wzajemnie powizane. Konstrukcj pojciow zapewniajc tak interpretacj nazywamy modelem danych. Podstawowe wasnoci opisywanej rzeczywistoci nale do dwch klas: klasy wa-snoci statycznych i klasy wasnoci dynamicznych.

Wasnoci statyczne, zwane schematem bazy danych, s stae, niezmienne w cza-sie. Schemat odpowiada temu, co nazywamy zazwyczaj jzykiem definiowania da-nych (ang. Data Definition Language DDL). Jzyk ten definiuje dopuszczalne struk-tury danych w ramach danego modelu. To znaczy, e okrela wasnoci, ktre musz by prawdziwe dla wszystkich wystpie bazy danych okrelonego schematu. S dwa uzupeniajce si sposoby definiowania struktur danych:

1. Dozwolone obiekty i zwizki specyfikuje si za pomoc oglnych regu defi-niowania dla kategorii, do ktrej nale.

2. Niedozwolone obiekty i zwizki wyklucza si definiujc wizy, czyli nakadajc ograniczenia na kategori.

Wasnoci dynamiczne, zwane stanem bazy danych, s wyraone zbiorem operacji odpowiadajcych jzykowi manipulowania danymi (ang. Data Manipulation Lan- guage DML). W zbiorze tym zdefiniowane s dozwolone operacje, ktre mog by wykonywane na pewnym wystpieniu bazy danych D1, w celu otrzymania wystpienia D2. Przykadem tego typu operacji s np. operacje aktualizacji. Aktualizacja zmienia baz danych z jednego stanu w drugi. Nowy stan jest wprowadzany przez stwierdze-nie faktw, ktre staj si prawdziwe lub przez zaprzeczenie faktw, ktre przestaj by prawdziwe. Do tej klasy operacji nale rwnie takie operacje, ktre nie powo-duj zmiany w wystpieniu, a mimo to s dynamiczne, gdy powoduj zmian stanu bazy danych, np. zapytania. Zapytanie nie modyfikuje w aden sposb bazy danych, ale jest uywane gwnie do sprawdzania czy pewien fakt lub grupa faktw jest spe-

7

niona w danym stanie bazy danych. Funkcje zapyta mog by rwnie uywane do wyprowadzania danych z ustalonych faktw.

Model danych jest integraln czci Systemu Zarzdzania Baz Danych (SZBD), czyli takiego systemu, ktry dostarcza zarwno mechanizmw do definiowania sche-matw baz danych, jak i operacji, ktre mona stosowa do przeksztacenia jednej bazy w inn, oczywicie o tym samym schemacie. Dokadnie mwic, SZBD spenia trzy zasadnicze funkcje: zarzdza plikami, wyszukuje informacje oraz zarzdza ca baz danych, czyli stanowi jakby powok, ktra otacza baz danych i za pomoc kt-rej dokonuj si wszystkie operacje na danych. Sama baza danych jest magazynem danych z naoon na niego wewntrzn struktur.

Z baz te s powizane inne waciwoci. Nale do nich: wspdzielenie danych, czyli moliwo korzystania przez wielu uytkownikw

w tym samym czasie z tych samych danych, integracja danych, czyli utrzymywanie i administrowanie baz nie zawierajc

niepotrzebnie powtarzajcych si lub zbdnych danych, integralno danych, czyli baza danych musi dokadnie odzwierciedla obszar

analizy, ktrego ma by modelem, co oznacza, e istnieje odpowiednio midzy fak-tami przechowywanymi w bazie a modelem rzeczywistym i kada zmiana wystpuj-ca w modelu rzeczywistym musi by wprowadzona w bazie opisujcej ten model,

bezpieczestwo danych, czyli ograniczenie dostpu w celu zapewnienia integral-noci bazy. Problem bezpieczestwa jest bardzo wany i zostanie szczegowo om-wiony w dalszych rozdziaach.

abstrakcja danych, czyli moliwo przechowywania pewnych istotnych do okrelonych potrzeb waciwoci obiektw i zwizkw midzy nimi.

niezaleno danych, czyli oddzielenie danych od procesw, ktre uywaj tych danych. Celem jest osignicie sytuacji, w ktrej organizacja danych byaby niewi-doczna dla uytkownika i programw uytkowych korzystajcych z tych danych. Rwnie dy si do tego, aby adna zmiana programu aplikacyjnego nie miaa wpywu na struktur danych.

Podane waciwoci stanowi na og podane cechy idealnej bazy danych. W rzeczywistoci wikszo modeli baz danych nie spenia wszystkich tych cech.

8

2. KRTKA HISTORIA BAZ DANYCH

Pierwsze bazy danych powstay w latach szedziesitych, kiedy to due firmy komputerowe, takie jak General Electric Company, tworzyy konkretne SZBD. Poja-wiy si wtedy pierwsze pakiety danych do uytku oglnego [18, 20].Tradycyjna baza danych suya wycznie do przechowywania danych. Ich przetwarzanie wykonywa-ne byo przez programy uytkowe wsppracujce z SZBD. Obsuga tych programw bya tak skomplikowana, e wymagaa obecnoci programisty o duych kwalifika-cjach. W latach szedziesitych stworzono sieciowy system zarzdzania IDMS [13, 18] dziaajcy na duych komputerach IBM, ktry przez nastpne dwadziecia lat by potentatem wrd SZBD. System ten mia duy wpyw na stworzenie przez grup Codasyl [12] modelu bdcego standardem w dziedzinie sieciowych modeli baz da-nych. Jednak prawdziw rewolucj wywoa w roku 1970 naukowiec z firmy IBM dr E.F. Codd swoj prac A Relational Model for Large Shared Data Banks [6], ktra miaa decydujcy wpyw na rozwj architektury baz danych. Idea przedstawiona przez Codda staa si podstaw do stworzenia pierwszych relacyjnych baz danych. Swj szybki rozwj i olbrzymi popularno zawdziczaj bazy relacyjne przede wszystkim sposobowi zapisu danych za pomoc tabel zwanych relacjami oraz moliwoci bez-poredniego zaimplementowania tego typu SZBD na komputerach osobistych [7, 8, 13]. Dua popularno baz relacyjnych w wielu komercyjnych zastosowaniach nie wyklucza jednak faktu, e bazy te obecnie przestaj by narzdziem wystarczajcym do opisu wielu problemw. Model relacyjny oferuje bardzo elastyczny sposb repre-zentowania faktw i formuowania zapyta o te fakty, ale nie oferuje atwego sposobu reprezentowania wizw integralnoci i modyfikacji. Wizy te i funkcje modyfikacji s zazwyczaj implementowane w programach uytkowych dziaajcych na zewntrz bazy relacyjnej. Dy si do tego, aby baza danych nie stanowia jedynie miejsca przechowywania faktw i informacji, ale miaa wbudowan inteligencj. Tak wic zaczy powstawa dedukcyjne bazy danych [2, 3, 4, 10]. Dedukcyjne bazy danych oferuj notacj o duej ekspresji, suc do reprezentowania faktw, wizw inte-gralnoci, zapyta i modyfikacji. Obecnie ich wad jest brak wydajnych implementa-cji duych baz faktw. W ostatnich latach pojawio si zwikszone zapotrzebowanie na nowe typy systemw baz danych opartych na pojciu obiektowoci [4, 15, 17]. Nie tylko powstao wiele komercyjnych obiektowych SZBD, lecz rwnie wielu produ-centw relacyjnych systemw wyposaa swoje produkty w cechy charakterystyczne dla baz obiektowych. Pomys zastosowania rwnolegej architektury komputerw przy problemach zarzdzania bazami danych ma rwnie wieloletni histori [4]. Wi-da wic, e wielki wpyw na ksztat systemw baz danych ma: przetwarzanie wbu-

9

dowane w baz danych, obiektowo i rwnolego [4]. Istotne miejsce w systemach komputerowych zajmuj systemy rozproszone [9], a co za tym idzie pomimo tego, e jest jeszcze miejsce na scentralizowane, due bazy danych specjalizujce si w reali-zacji wielkiej liczby transakcji, wiele osb uznao lata dziewidziesite za er rozpro-szonych baz danych. Ostatnio mona rwnie zaobserwowa gwatowny wzrost pre-zentacji rnego typu informacji dziki dynamicznie rozwijajcej si sieci Internet.

10

3. POJCIA PODSTAWOWE

Wprowadzimy obecnie pewne pojcia, ktrymi bdziemy posugiwa si w dalszej czci podrcznika. Nale do nich:

Dana (nazwa, cecha, warto) podstawowy skadnik informacji, ktry na og stanowi zbir znakw bdcych literami, cyframi lub znakami interpunkcyjnymi.

Encja kady przedmiot, zjawisko, stan, pojcie, kady obiekt, ktry potrafimy odrni od innych obiektw. Encja moe by okrelona przez: . Czas jest bardzo niewygodnym czynnikiem przy mo-delowaniu. Czciej pomija si czas i wprowadza si uporzdkowanie zdarze wedug kolejnoci ich wystpowania.

Powizania midzy danymi jedno-jednoznaczne (11). Mamy dane dwa zbiory encji A i B. Kadej encji ze zbioru A odpowiada najwyej jedna encja ze zbioru B i na odwrt (nie wszystkie encje obu zbiorw musz by w zwizku).

Powizania midzy danymi wielo-jednoznaczne (n 1) Mamy dane dwa zbiory encji A i B. Kadej encji ze zbioru A odpowiada najwyej 1 encja ze zbioru B, cho-cia 1 encji ze zbioru B moe odpowiada wiele encji ze zbioru A (jedno- -wieloznaczne (1 m) symetrycznie do poprzedniego).

Powizania midzy danymi wielo-wieloznaczne (m n) s najbardziej zoonym sposobem czenia obiektw danych przy projektowaniu bazy. Kady element jednego obiektu jest zwizany z kilkoma elementami innego obiektu i na odwrt.

Klucz wyrniony atrybut lub minimalny zbir wyrnionych atrybutw. Klucz kandydujcy wyrniony atrybut lub minimalny zbir wyrnionych atry-

butw, ktry w sposb jednoznaczny identyfikuje dan. Klucz gwny klucz wybierany ze zbioru kluczy kandydujcych. Jzyk Definiowania Danych (DDL) zbir regu wyraajcych wasnoci statycz-

ne danych. DDL definiuje dopuszczalne struktury danych (obiekty i zalenoci mi-dzy nimi), tworzc schemat bazy danych.

Przykad 3.1 Mamy dany schemat prostej sieciowej bazy [18] ZAOPATRZENIE przedstawio-

nej na rys. 3.1.

11

P-D

D-D DOSTAWA CZ-D

Data Lcz

Dnr Nazwa Adres Cznr Cena

Nrproj Adres

PROJEKT

DOSTAWCA CZ

gdzie: D-D, CZ-D, P-D powizania jedno-wieloznaczne

Rys. 3.1. Diagram schematu ZAOPATRZENIE

Baza skada si z czterech rekordw: DOSTAWCA, CZ, DOSTAWA, PROJEKT opisanych za pomoc wyrnionych cech oraz trzech powiza (set D-D, set CZ-D i set P-D) pomidzy rekordami, ktre zawieraj informacje o tym, ktry z rekordw jest rekordem nadrzdnym (ang. owner), a ktry podrzdnym (ang. member). Jzyk DDL dla schematu ZAOPATRZENIE ma nastepujca posta: Data base ZAOPATRZENIE Record DOSTAWCA Dnr string 2,key; Nazwa string 20; Adres string 20; End DOSTAWCA. Record CZ Cznr string 2,key; Cena real; End CZ. Record PROJEKT Nrproj string 2,key; Adres string 20; End PROJEKT. Record DOSTAWA Data integer; Lcz integer;

12

End DOSTAWA. Set D-D owner DOSTAWCA; member DOSTAWA; End D-D. Set CZ-D owner CZ; member DOSTAWA; End CZ-D Set P-D owner PROJEKT; member DOSTAWA; End P-D. End ZAOPATRZENIE.

Jzyk Manipulowania Danymi (DML) zbir operacji okrelajcych dynamiczne

wasnoci bazy danych, czyli stan bazy danych. Przykad 3.2 Dla podanego wyej schematu bazy ZAOPATRZENIE mamy za zadanie poda

adresy realizacji tych projektw, dla ktrych dostarczono CZ o numerze 100 (Cznr = 100). Przykad realizacji zapytania w DML:

FIND FIRST CZ RECORD WHERE (CZ.Cznr=100) IF ( STAN=0) GO TO KONIEC CZ-D:=CZ NASTCz: FIND NEXT CZ-D SET IF ( STAN=0) GO TO KONIEC P-D:=CZ-D FIND OWNER P-D SET GET P-D.Adres GO TO NASTCz KONIEC: STOP

Podany przykad pokazuje uycie jzyka proceduralnego, w ktrym mamy do czy-

nienia z wyszukiwaniem jednostkowym. To samo zadanie rozwizane za pomoc wyszukiwania grupowego z wykorzystaniem jzyka RALAN (model bazy relacyjny) pokazuje przykad 3.3.

Przykad 3.3 Przykad realizacji zapytania w jzyku Ralan [18].

13

1. Okrelenie schematu bazy danych za pomoc nagwkw:

DOSTAWCA (Dnr, Nazwa, Adres) CZ (Cznr, Cena) PROJEKT (Nrproj, Adres) DOSTAWA (Dnr, Cznr, Nrproj, Data, Lcz)

2. Tabele relacji:

DOSTAWCA: Dnr Nazwa Adres 10 ETO WROCAW 11 MTO WROCAW 12 ZTO WARSZAWA 13 WPP KRAKW

DOSTAWA: Dnr Cznr Nrproj Data Lcz 10 100 2000 15.09.2000 15 10 150 2000 15.09.2000 20 12 100 2001 20.01.2001 30 11 150 2002 20.09.2001 10

3. Program:

a) R1 DOSTAWA (Cznr=100) R1: Dnr Cznr Nrproj Data Lcz 10 100 2000 15.09.2000 15 12 100 2001 20.01.2001 30

b) R2 R1 [Dnr]

R2: Dnr 10 12

c) R3 R2 | DOSTAWCA (gdzie | znak czenia relacji)

R3: Dnr Nazwa Adres 10 ETO WROCAW 12 ZTO WARSZAWA

14

d) LIST R3 [Adres] Wynik: Adres WROCAW WARSZAWA

Jzyk Zarzdzania Danymi (DCL) jest to zbir komend stworzonych do zapew-

nienia bezpieczestwa i spjnoci danych. Mona je podzieli na dwie grupy: potwierdzanie i odwoywanie transakcji blokowania dostpu do tablic, nadawanie i odwoywanie przywilejw dostpu do zasobw bazy danych. Przykad 3.4 Pokazano nadawanie przywilejw do zasobw bazy ZAOPATRZENIE uytkow-

nikowi o nazwie EWA.

oglna posta komend: GRANT {uprawnienia,./ALL} GRANT SELECT ON {nazwa obiektu} ON ZAOPATRZENIE TO {nazwa uytkownika } TO EWA

Transakcja jest to zdarzenie powodujce zmian stanu bazy danych. Nowy stan

jest wprowadzany przez stwierdzenie faktw, ktre staj si prawdziwe i (lub) przez zaprzeczenie faktw, ktre przestaj by prawdziwe. Kada transakcja powinna mie waciwoci: niepodzielnoci, spjnoci, izolacji i trwaoci (ang. atomic, consistency, isolation, durability, std okrelenie cech transakcji ACID). Niepodzielno transakcji jest rozumiana jako jednoznaczne jej zakoczenie: zatwierdzenie lub anulowanie. Spjno to przeprowadzenie systemu z jednego stanu spjnego do innego rwnie spjnego. Izolacja to wykonanie transakcji w sposb nie kolidujcy z innymi realizo-wanymi transakcjami. Trwao wyniku transakcji polega na zapisywaniu w pamici staej systemu wynikw, co chroni je przed awari procesu serwera. Z punktu widze-nia aplikacji, transakcja to zbir kolejnych instrukcji nieproceduralnego jzyka mani-pulacji danymi o nazwie SQL (rozdz. 8). Zbir ten zakoczony jest instrukcj COMMIT WORK (zatwierdzenie transakcji) lub ROLLBACK (anulowanie transak-cji). W razie awarii systemu automatycznie realizowane jest anulowanie transakcji.

Baza danych zbir danych zorganizowanych w pewien logiczny i zestrukturali-zowany sposb. Bieca struktura zaley od modelu danych przyjtego przy organi-zowaniu tych danych. Jej wielko zalena jest od liczby danych i od wzajemnych powiza midzy nimi.

Sformatowana baza danych zbir danych w postaci skoczonego zbioru wzor-cw (schematw, formatw) sucych do wyraenia pewnych informacji o stanie wiata rzeczywistego. Zakres odwzorowanej wiedzy nie powinien by szeroki.

15

Niesformatowana baza danych zbir faktw i regu tworzcych nowe fakty na podstawie istniejcych w postaci sieci semantycznych, wyspecjalizowanych jzykw opisu wiedzy. Zakres odwzorowania wiedzy moe by bardzo szeroki.

System Zarzdzania Baz Danych (SZBD) jest zorganizowanym zbiorem narzdzi umoliwiajcym dostp do baz danych i zarzdzanie nimi. Dziki SZBD dostpne s takie operacje, jak: przechowywanie danych, tworzenie i utrzymywanie struktur da-nych, umoliwienie rwnoczesnego dostpu wielu uytkownikom, wprowadzanie mechanizmu bezpieczestwa i prywatnoci, odzyskiwanie danych i operowanie na przechowywanych danych, wprowadzanie i adowanie danych, udostpnienie wydaj-nych mechanizmw indeksowania pozwalajcych na szybkie znalezienie wybranych danych, zapewnienie spjnoci rnych rekordw, ochrona przechowywanych danych przed utrat za pomoc kopii bezpieczestwa i procedur odtwarzania.

Aby speni te wymagania, stworzono rone typy SZBD [13, 18, 19, 20]. Oparto je na nastpujcych modelach:

hierarchicznym w modelu tym dane przechowywane s w postaci struktury drzewiastej (obecnie jest to system przestarzay);

sieciowym w modelu tym dane zapisane s w postaci rekordw i powiza mi-dzy rekordami, ktre na rwni z danymi s nonikami informacji (w przykadzie 3.1 powizanie okrelone jest sowem set). Systemy sieciowe s bardzo szybkie i efek-tywnie wykorzystuj pami masow. Pozwalaj na tworzenie zoonych struktur danych, s jednak bardzo mao elastyczne i wymagaj mudnego projektowania. Przykadem takiego systemu jest system rezerwacji biletw lotniczych;

relacyjnym w modelu tym dane maj prawdopodobnie najprostsz struktur jak moe mie baza, czyli tabel. S atwe w uyciu i bardzo popularne. Przykadem s systemy: ORACLE, INFORMIX, SYBASE;

obiektowym w modelu tym przechowywane i obsugiwane s obiekty takie, jak obrazki, zdjcia, filmy video. Przykadem moe by SZBD ORACLE 8. Baza ta w tabelach przechowuje obiekty.

16

4. METODOLOGIA PROJEKTOWANIA BAZ DANYCH

4.1. Wprowadzenie

Oglnie mona powiedzie, e w bazie danych zawarta jest wiedza odnoszca si do pewnego wydzielonego fragmentu wiata rzeczywistego. Ustalenie zwizkw po-midzy danymi w bazie i faktami w wiecie rzeczywistym, a wic ustalenie semantyki danych nie odbywa si bezporednio. Pomostem umoliwiajcym ustalenie tych zwizkw jest model konceptualny [19, 20] bazy danych. Aby dane mogy dostarcza informacji, ich organizacja powinna umoliwia efektywne przetwarzanie. Istniej rne sposoby organizowania danych: tablice, listy, formuy itp. Modelujc dane, staramy si organizowa je tak, aby wiernie odzwierciedlay sytuacj rzeczywist i jednoczenie, aby mona je byo zapisa w pamici komputera. Te dwa wymagania nierzadko s sprzeczne. Aby mc okreli najlepsz organizacj informacji w danym zastosowaniu, musimy pozna jej cechy charakterystyczne. Cechy te pozwol sformu-owa oglne stwierdzenie co do sposobu zorganizowania i przetwarzania danych. Niesprzeczny, formalny zbir takich stwierdze definiuje model danych.

Mona wyrni trzy zasadnicze etapy konstruowania modelu: model konceptual-ny, model logiczny i model fizyczny (rys. 4.1).

Model konceptualny

Model logiczny

Model fizyczny

wiatrzeczywisty

BAZADANYCH

Rys. 4.1. Modele bazy danych

Model konceptualny jest modelem wiata rzeczywistego. Najbardziej znanym mo-delem tego typu jest model danych zwizkw encji Chena [5]. Modelowanie koncep-

17

tualne jest etapem poprzedzonym analiz wymaga, czyli wie si z uzyskiwaniem od uytkownikw pocztkowego zbioru informacji i wymaga dotyczcych przetwa-rzanych danych. W myl metody zaproponowanej przez Chena [3, 19] i szeroko sto-sowanej w teorii i praktyce baz danych do podstawowych faktw rozpatrywanych w wiecie rzeczywistym, o ktrych wiedza jest reprezentowana w bazie zaliczamy: wystpowanie obiektw (ang. entity), istnienie pomidzy tymi obiektami wzajemnych powiza (ang. relationship) oraz posiadanie przez obiekty i powizania okrelonych wartoci (ang. value) atrybutw (ang. attribute). Rodzaj wiedzy o wiecie rzeczywi-stym jaka powinna by odwzorowana w bazie danych, a wic zaprojektowanie sche-matu bazy jest jednym z najtrudniejszych i najwaniejszych zada przy projektowaniu bazy. Od poprawnie zaprojektowanego schematu zaley waciwe dziaanie caego systemu wykorzystujcego baz. Poprawny, to znaczy speniajcy nastpujce wyma-gania [11, 19, 20]:

cisy zwizek z faktami wiata rzeczywistego, tzn. atwy sposb ich tworzenia i rozumienia,

kompletno informacji, podatno na zmiany, a wic ewolucyjno schematu, stabilno, czyli projektowany schemat powinien uwzgldnia przewidywalne

zmiany, moliwo tworzenia rnych obrazw danych, czyli rnych logicznych modeli

baz danych. Model logiczny jest to, z punktu widzenia architektury danych, zbir oglnych za-

sad posugiwania si danymi, np. modele klasyczne czy modele semantyczne danych. Proces modelowania logicznego wie si z okreleniem zawartoci bazy danych nie-zalenie od wymogw konkretnej implementacji fizycznej. Model fizyczny to sposb reprezentacji danych w pamici komputera wyraony za pomoc plikw, rekordw, struktur dostpu itp. odpowiednich dla okrelonej konfiguracji sprztu i oprogramo-wania.

4.2. Proces projektowania i jego skadowe

Proces projektowania obejmuje czynnoci i zdarzenia wystpujce midzy poja-wieniem si problemu a powstaniem dokumentacji opisujcej rozwizanie problemu zadawalajce z punktu widzenia funkcjonalnego, ekonomicznego i innych wymaga. Ta definicja procesu projektowania podana zostaa przez Kricka [14] w roku 1971 i jest na tyle oglna, e mona j zastosowa w wikszoci przypadkw. Oczywicie projektowanie rzadko przebiega wedug identycznych sieci dziaa skadowych. Ich posta zaley przede wszystkim od klasy projektowanych obiektw, od specyfiki za-dania projektowego oraz od wielu rnych cech charakterystycznych dla projektowa-nych obiektw czy systemw. Inaczej postpujemy na etapie projektowania modelu

18

konceptualnego, logicznego czy te fizycznego. Mona jednak dopatrzy si pewnych wsplnych cech, to znaczy sekwencji dziaa podstawowych, do ktrych nale for-muowanie problemu, generacja rozwiza, ocena rozwiza itp. Oczywicie punktem wyjciowym do sformuowania problemu jest analiza potrzeb i wymaga. W wyniku oglnej i szczegowej analizy problemu uzyskujemy pewien zbir danych. Zbir ten po uporzdkowaniu stanowi zadanie projektowe, ktre zapisane w formie dokumen-tu wedug standardw obowizujcych w danym systemie tworzy zaoenia projekto-we. Uporzdkowanie jest to proces przejcia od faktw w wiecie rzeczywistym do danych w bazie danych. Etapy przejcia od wiata rzeczywistego do konceptualnej bazy danych przedstawiono na rysunku 4.2.

wiatrzeczywisty

Schemat bazykonceptualnej

Stan bazykonceptualnej

Jzyk OS

Jzyk WI

Rys. 4.2. Tworzenie konceptualnej bazy danych

W etapie pierwszym naley zdefiniowa pewien wski podzbir jzyka naturalne-go, sucy do opisu stanw wiata rzeczywistego (w skrcie Jzyk Opisu Stanw OS) oraz jzyk sucy do formuowania wizw integralnoci (w skrcie Jzyk Wi-zw Integralnoci WI). Celem jest okrelenie, jakie w ogle obiekty wiata rzeczy-wistego, jakie powizania midzy tymi obiektami i jakie atrybuty (cechy) obiektw s interesujce w danej klasie zastosowa. Przy tak sformuowanym problemie z gry okrela si konieczno wykorzystania takich operacji, jak selekcja, klasyfikacja i nazywanie obiektw. Rwnoczenie zwizane z tym jest okrelenie pewnego zbioru warunkw zwanych wizami integralnoci, ktrych spenienie jest konieczne, aby o danej strukturze mona byo powiedzie, e jest ona niesprzeczna ze swoim opisem. Wizy integralnoci s to wyraenia, ktre stwierdzaj zachodzenie w wiecie rze-czywistym pewnych staych niezmiennych zalenoci. Ich rdem jest znajomo waciwoci semantycznych wiata rzeczywistego. Wizy integralnoci s warunkami koniecznymi, ale nie dostatecznymi poprawnoci bazy danych. Moliwa jest w bazie taka sytuacja, e pomimo spenienia wszystkich wizw dane w bazie nie odpowiada-j adnemu poprawnemu stanowi wiata rzeczywistego. W czasie projektowania bazy danych, przy zastosowaniu konkretnego modelu danych i zwizanej z nim metody

19

szereg wizw integralnoci zostaje ujtych w samej strukturze bazy danych. W wielu przypadkach jednak wizy musz by formuowane w specjalnym jzyku.

Etap drugi to tworzenie schematu bazy danych. Schemat stanowi zbir zda jzyka opisu stanw prawdziwych wzgldem rozpatrywanego stanu wiata rzeczywistego (np. w pewnym przedziale czasu, w ktrym nie zaszy adne interesujce nas zmiany) oraz zbir zda jzyka wizw integralnoci. W kadym z wizw ma swoje odbicie jakie ograniczenie semantyczne, odzwierciedlajce nasze intuicyjne rozumienie pew-nej niezmiennej waciwoci, jak ma rozpatrywany przez nas wycinek wiata rzeczy-wistego. Schemat jest stay, niezmienny, kada zmiana to zupenie nowa baza danych.

W etapie trzecim budowana jest pewna struktura matematyczna, czyli model abs-trakcyjny stanu wiata rzeczywistego. Model ten na og mona przedstawi jako struktur zoon, w skad ktrej wchodz zbiory: obiektw, powiza, wartoci, oraz atrybuty i wizy integralnoci. Manipulowanie w bazie konceptualnej moe obejmo-wa operacje wyszukiwania, modyfikowania, doczania i usuwania. Niektre z nich, jak np. wyszukiwanie, nie zmieniaj stanu bazy i po ich wykonaniu nie wystpuje konieczno sprawdzania wizw integralnoci. W przypadku pozostaych moe si to okaza konieczne.

4.3. Opis modelu konceptualnego

Jako przykad modelu konceptualnego posuy model zwiazkw encji Chena. Mo-del ten powsta w wyniku praktycznych dowiadcze przy projektowaniu bazy danych za pomoc dostpnych na rynku SZBD. Zgodnie z propozycj Chena [5] podstawowe fakty rozpatrywane w wiecie rzeczywistym s opisywane za pomoc obiektw. Ka-dy obiekt jest okrelony poprzez atrybuty majce pewne wartoci. Pomidzy obiekta-mi istniej powizania. Obiekty, atrybuty, powizania i wartoci mona klasyfikowa w zbiory. Podstaw tej klasyfikacji jest posiadanie przez nie pewnej wasnoci okre-lonej dla kadego zbioru [19]. Obiekty reprezentowane s za pomoc wartoci atry-butw. Nazwa atrybutu jest na og jedn z jego wartoci. W celu jednoznacznej iden-tyfikacji obiektu w zbiorze obiektw okrelamy klucz kadego obiektu. Jest to atrybut lub zbir atrybutw okrelony na tym zbiorze, ktry rnym obiektom w tym zbiorze przyporzdkowuje rne wartoci. Oznacza to, e wskazanie wartoci klucza obiektu jednoznacznie wyznacza obiekt w zbiorze obiektw. Jeden zbir obiektw moe mie kilka kluczy. Jeeli jest kilka kluczy, to wybieramy z nich ten, ktry jest najbardziej sensowny semantycznie i dla ktrego mona przewidzie dopuszczalny zakres warto-ci. Nazywamy go kluczem gwnym. Wartoci, ktre klucz gwny przyporzdkowu-je obiektom traktujemy jako reprezentacje tych obiektw. Kady obiekt w modelu Chena nosi nazw encji. Encje tego samego typu tworz zbiory encji. Na rysunku 4.3 podano przykad przedstawienia encji PACJENT.

20

Rys. 4.3. Przedstawienie atrybutw zdefiniowanych na zbiorze encji PACJENT

PACJENT

nr ewidencyjny

pe

nr kart zdrowia

adres

imi i nazwisko

Atrybuty mog by jedno- lub wielowartociowe (rys. 4.4).

LABORATORIUM

nr telefonu

Rys. 4.4. Atrybut dla encji Laboratorium

Encje zawieraj niewiele informacji. Midzy zbiorami encji zachodz pewne zwizki. Wyrniamy zwizki typu 1:1, 1:n (m:1) i n:m. Zwizki na rwni z encjami s rdem informacji. Struktur bazy danych zorganizowan zgodnie z modelem zwizkw encji mona przedstawi za pomoc diagramu zwizkw encji [19] skada-jcego si z wierzchokw poczonych etykietowanymi krawdziami. Zarwno spo-sb okrelenia krawdzi midzy wierzchokami jak i przypisane etykiety przekazuj istotn informacj o wasnociach semantycznych odwzorowywanego wiata rzeczy-wistego. Wyrniamy nastpujce rodzaje wierzchokw: prostokty etykietowane nazwami encji oraz romby etykietowane nazwami zbiorw powiza. Wystpowanie konkretnego wierzchoka z przypisan mu etykiet przekazuje informacje, e dany zbir encji, powiza lub wartoci wystpuje w opisie wiata rzeczywistego. Na ry-sunku 4.5 [19] pokazano diagram dla medycznej bazy danych. Zbir takich encji, jak: SZPITAL, ODDZIA, LEKARZ, PERSONEL, LABORATORIUM, PACJENT, BADANIE, DIAGNOZA, reprezentuje na rysunku prostokt z etykiet. Zbiory encji odpowiadaj rnym, oglnym klasyfikacjom encji. Przynaleno do zbioru okrela predykat, to znaczy cechy konkretnego wcielenia pewnej encji mog by testowane w celu ustalenia, czy encja ta naley, czy nie do zbioru encji. Zbiory encji nie musz

21

SZPITAL

posiadaoddziaw

personelmedyczny

badanialaboratoryjne

ODDZIA LEKARZ LABORATORIUM

ilopersonelu

zajtooddziau

opiekalekarska

PERSONELPACJENT

przewidzianebadania

BADANIEwykonanebadania

DIAGNOZA

postawionadiagnoza

posiada oddziaw

ilo personelu

Rys. 4.5. Diagram zwizkw encji

by rozczne. Konkretna encja moe nalee do wicej ni jednego zbioru, np. lekarz moe take by pacjentem. Zbiory powiza s reprezentowane przez romb z etykiet. Zbiory encji nalece do zbioru zwizkw s wskazywane przez krawdzie czce je z opisanym typem zwizku.

Ta sama encja moe peni w tym samym zwizku rne role. Mwimy wtedy o zwizku rekurencyjnym. Ilustruje to rysunek 4.6.

22

zwierzchnik

PERSONEL Zarzdzapersonelempodwadny

Rys. 4.6. Zbir zwizku rekurencyjnego

Moe istnie wicej ni jeden zbir zwizku midzy tymi samymi dwoma zbiorami encji. Przykad podano na rysunku 4.7.

Lekarzprowadzcy

Lekarzkonsultujcy

LEKARZ PACJENT

Rys. 4.7. Dwa zbiory zwizku midzy tymi samymi zbiorami encji

LEKARZZleconebadania BADANIE

PACJENT

Rys. 4.8. Zbir zwizku trzyargumentowego

Zbir zwizku moe by zbiorem zwizku n-argumentowego (rys. 4.8), to znaczy moe dotyczy n zbiorw encji. Diagram przedstawia zwizek midzy encjami LEKARZ, PACJENT, BADANIE. Semantyka zbioru wieloargumentowego moe by czasem do trudna do zrozumienia. Na rysunku 4.8 mamy nastpujce zwizki:

23

LEKARZ moe zaleci wykonanie rnych BADA kilku PACJENTOM, jedno BADANIE moe by zalecane przez kilku LEKARZY rnym PACJENTOM oraz jeden PACJENT moe mie do wykonania kilka BADA zleconych przez rnych LEKARZY.

W modelu zwizkw encji zbir wartoci nazywa si dziedzin. Zbir wartoci moe by zwizany nie tylko ze zbiorem encji, ale rwnie ze zbiorem zwizku (rys. 4.9). Zbiory wartoci przedstawiono na rysunku w postaci prostoktw o zaokrglo-nych brzegach.

ODDZIA

Zajtoka nr ka

PACJENT

Rys. 4.9. Atrybut zbioru zwizku

Zbiory zwizku take maj klucze zwane kluczami zwizku. Klucz zwizku skada si z kluczy encji tych zbiorw encji, ktre s zawarte w danym zbiorze zwizku. Oprcz zwizkw wystpujcych w modelu encji istniej tzw. logiczne ograniczenia zwane wizami. Wizy to pewne wasnoci, ktre dla danego zbioru encji s praw-dziwe lub faszywe. Inaczej mwic, s zachowane lub naruszone. Jeli wartoci da-nych s zgodne z istniejc wiedz o obiekcie, to oczekuje si, e te wizy zostan zachowane. W modelu danych wizy s szczeglnie przydatne wtedy, gdy maj ogl-ny charakter, to znaczy gdy mog by definiowane i stosowane w zbiorach obiektw, a nie s ustalone dla konkretnego obiektu. W modelu danych wizy s konieczne ze wzgldu na semantyk i integralno. Semantyka odzwierciedla dokadnie sytuacj wiata rzeczywistego, a integralno umoliwia SZBD ograniczenie moliwych w danym schemacie stanw bazy do takich, ktre zachowuj wizy. Rozrniamy dwa podstawowe typy wizw: wizy wbudowane [19] oraz wizy jawne. Wizy wbudowane stanowi bardzo ograniczony mechanizm definiowania wizw, na og okrelaj pewne wymagania co do struktury (np. zwizki w modelu hierarchicznym mog mie tylko struktur drzewa). Czasami zachowanie tych wizw moe sprawi, e struktura bazy nie odpowiada wiernemu opisowi wiata rzeczywistego. Aby usun wady wynike z definiowania wizw wbudowanych, wprowadzono wizy jawne.

24

Wizy te zapewniaj elastyczny mechanizm umoliwiajcy rozbudow struktury bazy. Rozgraniczenie midzy wizami wbudowanymi i jawnymi jest na og pynne i zaley w duej mierze od struktur modelu danych. Im wicej ogranicze nakadaj struktury modelu danych, tym wicej zawiera on wizw wbudowanych i tym mniej trzeba de-finiowa wizw jawnych. Definicja wizw jawnych moe by wyraona w sposb statyczny lub dynamiczny. Specyfikacja statyczna wyraa reguy mwice o tym, ktre ze stanw bazy s poprawne, czyli ktre mog wystpi. Poprawno rozumiana jest w sensie zachowania integralnoci bazy (rozdz. 8). Specyfikacja dynamiczna do-tyczy operacji. Naley tak definiowa operacje w bazie, aby w wyniku ich zastosowa-nia nie naruszy integralnoci bazy. Jest i trzeci typ wizw, wizy niejawne. Mona go wyprowadzi ze zdefiniowanych wizw wbudowanych i jawnych. W hierarchicz-nej bazie danych kady obiekt podrzdny ma najwyej jeden obiekt nadrzdny. Wyni-ka z tego, e kady obiekt ma tylko jeden obiekt poprzedzajcy dowolnego typu. Pierwsze zdanie mwi o wizach wbudowanych, drugie o niejawnych.

Modele zwizkw encji powstae w procesie praktycznych bada nad projektowa-niem bazy danych powinny by przede wszystkim wystarczajco oglne i bogate se-mantycznie, ponadto powinny zawiera wszystkie podstawowe cechy systemw ko-mercyjnych tak, aby mogy by atwo implementowane.

4.4. Przykad realizacji konkretnej bazy

4.4.1. Sprecyzowanie wymaga dotyczcych projektowanej bazy danych

Przykadowa baza danych wykonana zostaa w ramach projektu studenckiego (T. Idasiak, T. Kasper). Przeznaczona jest dla sklepu ze sprztem elektronicznym, ma by pomoc w zarzdzaniu transakcjami (sprzeda, dostawa towaru) poprzez doku-mentacj kolejnych zakupw i dostaw. Zawiera pen informacj dotyczc:

towaru, stanu magazynu, danych klientw i dostawcw, wystawianych faktur, dokonanych zakupw, zrealizowanych dostaw. Baza realizuje nastpujce funkcje: zapisywanie danych do bazy, dopisywanie danych do bazy, modyfikowanie danych znajdujcych si w bazie, usuwanie danych z bazy, wyszukiwanie danych zgodnie z zapotrzebowaniem.

25

Projektujc niniejsz baz wzito pod uwag moliwo wyszukiwania danych zgodnie z nastpujcymi zapytaniami:

wylistuj wszystkich dostawcw, klientw lub sprzedawcw, wylistuj elementy lub podzespoy o okrelonych atrybutach, podaj parametry opisujce dany element (podzesp), wylistuj elementy (podzespoy) dostarczone/zakupione przez dostawc/klienta

(np. w okrelonym dniu, o okrelonej cenie), wylistuj sprzedae dokonane przez danego klienta, na ktre nie zostaa jeszcze

wystawiona faktura, wylistuj sprzedae (klientw) dokonane po danym dniu powyej danej ceny, wylistuj dostawy zrealizowane przez dostawc, wylistuj dane sprzedawcy, ktry wystawi dan faktur, itd.

4.4.2. Model konceptualny bazy danych

Projektowana baza danych zawiera nastpujce encje: DOSTAWCY Identyfikator, Nazwisko, Imi, Adres (Miasto, Kod, Ulica,

Tel/Fax); SPRZEDAWCY Okrelone przez takie same pola jak DOSTAWCA; KLIENTA Okrelone przez takie same pola jak DOSTAWCA; ELEMENTU Identyfikator, Warto, Cena, Ilo_Szt, Producent, Opis; PODZESPOU Identyfikator, Nazwa, Cena, Gwarancja, Ilo_Szt, Producent,

Opis; FAKTURY Identyfikator, Dane_Firmy, Data_Wystawienia, Patno; SPRZEDAY Nr Sprzeday, Cena_Sumaryczna, Data_Sprzeday, Ilo_Sztuk; DOSTAWY Nr Dostawy, Data_Dostawy, informacje o dostawcy.

4.4.3. Normalizacja

W celu wyznaczenia pojedynczych tabel i powiza pomidzy nimi przeprowa-dzono normalizacj (rozdz. 5, p. 5.6), ktr zrealizowano w nastpujcych krokach:

zebranie zbioru danych, przeksztacenie nieznormalizowanego zbioru danych w tabele, wykorzystanie jednego z algorytmw normalizacji. Przy kadym kolejnym przeksztaceniu podzielono struktur danych na coraz wi-

cej tabel bez straty powiza zachodzcych midzy danymi (rozdz. 5). W wyniku normalizacji w projektowanej bazie danych otrzymano nastpujce

tabele:

26

Tabele danych osobowych:

Ulica

Imi

DOSTAWCAID_DostawcaNazwisko

MiastoKodUlicaTel / Fax

SPRZEDAWCAID_SprzedawcaNazwiskoImiMiastoKod

Tel / Fax

KLIENTID_KlientNazwiskoImiMiastoKodUlicaTel / Fax

Tabele dotyczce towaru:

ELEMENTID_ProducentID_OpisID_DostawaID_ElementWartoCenaSztuki

PODZESPID_ProducentID_OpisID_DostawaID_PodzespNazwaCenaGwarancjaSztuki

PRODUCENTID_ProducentNazwa_FirmMiastoKodUlicaTel / Fax

OPIS

OpisID_Opis

Tabele dotyczce transakcji:

DOSTAWAID_DostawaID_DostawcaData_Dostawy

SPRZEDA

ID_KlientID_SprzedawcaID_FakturaData_SprzedaCena_Sumaryczna

FAKTURA

ID_SprzedaData_WystawieniaDane_FirmPatno

ID_FakturaID_Sprzeda

Tabele powstae w celu wyeliminowania powiza zalenoci typu wiele do wielu (n:m):

SPRZEDAPODZESPOWID_PodzespID_SprzedaSztuki

SPRZEDAELEMENTW

Sztuki

ID_ElementID_Sprzeda

czc poszczeglne tabele z uwzgldnieniem relacji midzy nimi otrzymano dia-gram encji, w ktrym zachodzce relacje opisane s w nastpujcy sposb:

28

PODSUMOWANIE

Baza konceptualna jest podstaw do tworzenia struktur logicznej bazy danych. Miejsce i rola schematu konceptualnego zaley od sposobu organizacji systemu bazy danych. W przypadku gdy mamy do czynienia z lokalnymi lub rozproszonymi bazami danych, opartymi na jednym modelu, schemat konceptualny ma najczciej znaczenie pomocnicze i wykorzystywany jest, czsto nieformalnie, do tworzenia schematu lo-gicznego. Stanowi take punkt odniesienia w przypadku niejednoznacznoci, jakie mog pojawi si przy interpretacji danych przez rnych uytkownikw. W wielo-modelowych, lokalnych bazach danych schemat konceptualny stanowi integraln cz bazy danych. Oprcz niego wspistniej w systemie schematy logiczne utwo-rzone wedug rnych modeli danych. Wraz z rozwojem sieci komputerowych i zwi-zanych z nimi rozproszonych baz danych pojawia si zupenie nowe znaczenie sche-matu konceptualnego. Uytkownik korzystajc z bazy danych nie odczuwa, e baza ta jest fragmentem systemu rozproszonego. Zawarto wszystkich baz danych tworz-cych system rozproszony opisana jest w globalnym schemacie konceptualnym, z kt-rego moe by wyprodukowanych wiele lokalnych schematw logicznych. Jeeli teraz uytkownik korzysta z caej rozproszonej bazy, to operuje na poziomie globalnym. SZBD dokonuje koniecznych przeksztace zarwno na poziomie globalnym, jak i na poziomach lokalnych tak, e uytkownik nawet nie wie, z ktr z lokalnych baz aktu-alnie jest zwizany. Sposb przejcia z poziomu konceptualnego do logicznego zaley przede wszystkim od typu bazy logicznej i metodologii jej projektowania. Ju na po-ziomie logicznym istniej rne metody projektowania schematw logicznych. W podejciu sieciowym bierze si pod uwag nie tylko zwizki logiczne midzy da-nymi, ale take przewidywane sposoby i czsto odwoywania si do danych [1, 13]. Wpywa to dodatnio na efektywno systemu, ale jednoczenie zmniejsza niezale-no danych. W podejciu relacyjnym bierze si pod uwag pewne zalenoci midzy atrybutami [1, 7, 8] i na tej podstawie tworzy si pewien zbir danych o podanych wasnociach. W podejciu tym nie bierze si pod uwag wydajnoci systemu, a jedy-nie zalenoci midzy atrybutami, ktre wyraaj pewne semantyczne wasnoci od-wzorowywanego wiata rzeczywistego.

29

BIBLIOGRAFIA

[1] Banachowski L., Bazy Danych tworzenie aplikacji, WNT, Warszawa 1997. [2] Beynon-Davies P., Expert Database Systems: a gentle introduction Maidenhead, MacGraw-Hill

1991. [3] Beynon-Davies P., Knowlege Engineering for Information Systems Development; an introduction to

information systems engineering, Maidenhead MacGraw-Hill 1993. [4] Beynon-Davies P., Systemy baz danych, WNT, Warszawa 1998. [5] Chen P.P.S., The Entity Relationship Model: towards and unified view of data. ACM Tran. of Data-

base Systems 1976, 1(1), s.936 [6] Codd E.F., A Relational Model for Large Shared Data Banks Communications of ACM, June 1970,

Vol. 13, No. 6, s. 377387. [7] Codd E.F., Extending the relational Database Model to Capture More Meaning. ACM Transactions

on Database Systems, Dec. 1979, Vol. 4, No. 4, s. 397434. [8] Codd E.F., The Relational Model for Database Management: Version 2. Reading, Mass. Addison-

Wesley 1990. [9] Coulouris G., Dillimore J., Kindberg T., Systemy rozproszone. Podstawy i projektowanie, WNT,

Warszawa 1998. [10] Das S.K. Deductive Databases and Logic Programming, Adison-Wesley Publishing Company 1981. [11] Date C.J., Wprowadzenie do baz danych, WNT, Warszawa 1983. [12] DBTG: Report of the CODASYL Database Task Group. ACM, April 1971. [13] Delobel C., Adiba M., Relacyjne bazy danych, WNT, Warszawa 1989. [14] Krick E.V., Wprowadzenie do techniki projektowania technicznego, WNT, Warszawa 1975. [15] MacVittie D.W., MacVittie L.A., Programowanie zorientowane obiektowo, Mikom, Warszawa

1996. [16] Martin J., Organizacja baz danych, PWN, Warszawa 1983. [17] Myer B., Object Oriented Software Construction, New York, Prentice-Hall 1997. [18] Pankowski T., Podstawy baz danych, PWN, Warszawa 1992. [19] Tsichritzis D.C., Lochovsky F.H., Modele danych, WNT, Warszawa 1990. [20] Ullman J.D., Systemy baz danych, WNT, Warszawa 1981.

31

CZ II

Wybrane metody reprezentacji danych

prezentowanie uytkownikowi bazy danych w jej obrazie konceptualnym jest niewygodne. Dlatego proponowane s modele danych, ktrych celem jest dostarczenie rodkw umoliwiajcych prezentowanie uytkownikowi takiego obrazu bazy danych, ktry byby dla niego moliwie naturalny i atwo zrozumiay... Model danych jest pewnym narzdziem wykorzysty-wanym do zrozumienia organizacji danych w logicznej bazie danych. Nie opisuje danych w tej bazie, a jedynie wskazuje sposb w jaki dane mog by organizowane oraz sposb w jaki mona organizowa do nich dostp.

T. Pankowski

32

WPROWADZENIE

Punktem wyjcia do tworzenia logicznego modelu danych jest model konceptual-ny. Istnieje wiele rnorodnych modeli logicznych danych. Wrd modeli klasycz-nych na szczegln uwag zasuguje model relacyjny majcy jednolite podstawy teo-retyczne. Jego prekursorzy model sieciowy i hierarchiczny s ju praktycznie nieuywane. Model relacyjny ze wzgldu na solidne podstawy matematyczne jak i du popularno przy budowie komercyjnych SZBD jest tematem rozdziau pite-go. Model relacyjny jest klasycznym przykadem sformatowanej bazy danych. Ostat-nio wiele cech klasycznych modeli danych, a w szczeglnoci modelu relacyjnego pojawio si pod nazw obiektowego modelu danych. Trudno jest jednoznacznie okre-li, czy systemy obiektowych baz danych oferuj lepsze warunki do zarzdzania ba-zami ni modele klasyczne. Bez wtpienia podejcie obiektowe nadaje si do pewnych niestandardowych aplikacji, jak systemy informacji geograficznej lub projektowanie wspomagane komputerowo. Pozostaje jednak spraw nierozstrzygnit, czy jest rze-cz sensown uycie obiektowoci w standardowych aplikacjach komercyjnych baz danych. Bazy obiektowe s tematem rozdziau szstego. Wraz z rozwojem takich wa-ciwoci systemw baz danych, jak: rozproszenie, zarzdzanie obiektami o strukturze hierarchicznej, przechowywanie tekstw, grafiki, obrazw, animacji, dwikw poja-wi si pomys wykorzystania logiki formalnej w tych systemach. Przy pomocy logiki istnieje moliwo wyraenia w sposb jednolity takich operacji, jak: definiowanie danych, operowanie danymi i zapewnienie integralnoci danych. Logika umoliwia rwnie poszerzenie konwencjonalnej bazy danych o narzdzia dedukcyjne. W bazach dedukcyjnych oprcz faktw przechowuje si rwnie reguy. Liczba przechowywa-nych faktw jest duo wiksza od liczby regu. Jzyk baz dedukcyjnych opiera si na schemacie zdefiniowanym w fazie konceptualnej. Szczeglny nacisk pooony jest na efektywno systemu. Problem efektywnoci sprowadza si gwnie do efektywnego przeszukiwania bazy i tworzenia dziki reguom nowych faktw w bazie. Charaktery-styczn cech baz dedukcyjnych jest to, e w wyniku kierowanych do bazy zapyta istnieje moliwo przegldania wszystkich rozwiza i analizowanie ich. Dedukcyjne bazy danych s tematem rozdziau sidmego.

33

5. MODEL RELACYJNY JAKO PRZYKAD MODELU KLASYCZNEGO

5.1. Uwagi oglne

Na rynku komercyjnym dominuj relacyjne bazy danych oparte na modelu Codda [13, 14, 15, 16]. S one podstaw wikszoci takich systemw, jak: Clipper, dBase, Foxpro, Delphi oraz duych SZBD takich, jak Oracle, Ingress, Progress, Informix.

Podstawowe zalety relacyjnych baz danych to [4, 21, 38]: prostota struktur danych zredukowanych do relacji nie wprowadza si adnych

poj poziomu fizycznego. Zbiory encji i powizania midzy encjami zawsze s re-prezentowane przez dwuwymiarowe tablice,

nieproceduralne, deklaratywne jzyki manipulacji danymi jzyki nieprocedu-ralne okrelaj, ktre informacje maj by wyszukiwane, a nie w jaki sposb,

niezaleno fizyczna i logiczna danych definicja struktur fizycznych i cieek jest niezalena od modelu danych,

optymalizacja dostpu do bazy danych automatyczne generowanie strategii dostpu, oparcie modelu na szczeglnie precyzyjnym fundamencie teoretycznym teoria

zbiorw. Dziki tym zaletom bazy relacyjne znalazy zastosowanie w typowych aplikacjach:

bankowych, magazynowych, ewidencji personalnej itp. Trzy podstawowe cechy s charakterystyczne dla modelu relacyjnego: struktura danych ( jest tylko jedna struktura danych w bazie), dostpno operatorw algebry relacji, wizy integralnoci w sposb jawny lub niejawny zapewniajce zgodno pa-

mitanych w relacjach informacji.

nr indeksu nazwisko data urodz. nr przedmiotu nazwa

egzaminator data ocena

STUDENT PRZEDMIOT

EGZAMIN

Rys. 5.1. Zapis w modelu sieciowym

34

Jeeli chodzi o ekspresyjno modelu, czyli zdolno do ujmowania informacji o wiecie rzeczywistym, to zapisy zarwno w modelu sieciowym (rys. 5.1) jak i rela-cyjnym (rys. 5.2) s jednakowo czytelne.

STUDENT (nr indeksu, nazwisko, data urodz.) PRZEDMIOT (nr przedmiotu, nazwa) EGZAMIN (nr indeksu, nr przedmiotu, egzaminator, data, ocena)

Rys. 5.2. Zapis w modelu relacyjnym

5.2. Opis modelu

Struktury danych modelu relacyjnego opieraj si na pojciach: dziedziny zbioru dopuszczalnych wartoci danych, relacji tabela dwuwymiarowa bdca podzbiorem iloczynu kartezjaskiego wy-

branych dziedzin, krotki wiersza tabeli dwuwymiarowej, atrybutu nazwy kolumny tabeli dwuwymiarowej, klucza atrybutu identyfikujcego wiersz tabeli. Kada encja w modelu relacyjnym jest zapisana w postaci KROTKI, czyli wiersza

tabeli. Zbir wierszy, czyli zbir KROTEK opisanych tymi samymi atrybutami tworzy relacj. Relacja, jedyna struktura danych w modelu, jest tabel, dla ktrej speniony jest nastpujcy zbir zasad:

1. Kada relacja w bazie ma jednoznaczn nazw. 2. Kada kolumna w relacji (jako zbir) ma jednoznaczn nazw (atrybut). 3. Wszystkie wartoci w kolumnie musz by tego samego typu (dziedzina). 4. Porzdek kolumn w relacji nie jest istotny (elementy zbioru nie s uporzdko-

wane). Wane jest to, aby kolumny nie powtarzay si w tabeli. 5. Liczba kolumn w relacji to stopie relacji. 6. Kady wiersz w relacji (KROTKA) musi by rny. 7. Porzdek wierszy nie jest istotny. 8. Kade pole lece na przeciciu wiersza i kolumny powinno by atomowe.

Oznacza to, e warto atrybutu w danej kolumnie powinna by dan elementarn [18]. Tabela zawierajca tylko dane elementarne znajduje si w pierwszej postaci normalnej (1PN). Algorytm tworzenia 1PN opisano w [33].

9. Kada relacja musi mie klucz gwny. Klucz gwny to jedna lub wicej ko-lumn tabeli, w ktrych wartoci atrybutw jednoznacznie identyfikuj wiersz tabeli.

10. W kadej relacji moe istnie wiele kluczy kandydujcych i kluczy obcych. Kluczem obcym w danej tabeli nazywamy klucz gwny innej tabeli z ni powizanej.

35

5.3. Operacje na relacjach

Definicje podstawowych poj relacyjnego modelu danych podano w [33] rozdz. 16, p.16.1. Korzystajc z tych poj, operacje na relacjach mona podzieli na dwie grupy: operacje mnogociowe, ktre wynikaj z faktu, e relacja jest zbiorem oraz operacje relacyjne, ktre oparte s na rozumieniu relacji jako zbioru krotek. Relacje mnogociowe na zbiorach to: suma, rnica, przekrj, dopenienie. Operacje na krot-kach to: projekcja, czenie, selekcja i dzielenie.

Operacje mnogociowe mona zdefiniowa zgodnie z [33] w nastpujcy sposb:

SUMA Relacja T(U) jest sum relacji R(U) i S(U), co oznaczamy T = R S wtedy i tylko wtedy, gdy T = {t KROTKA(U) : t R t S}

RNICA Relacja T(U) jest rnic relacji R(U) i S(U), co oznaczamy T = R S wtedy i tylko wtedy, gdy T = {t KROTKA(U) : t R t S}

PRZEKRJ Relacja T jest przekrojem relacji R(U) i S(U), co oznaczamy T = R S wtedy i tylko wtedy, gdy T = {t KROTKA(U) : t R t S}

DOPENIENIE Relacja T(U) jest dopenieniem relacji R(U), co oznaczamy T = R wtedy i tylko wtedy, gdy

T = KROTKA(U) R = {t KROTKA(U) : t R}

Dopenienie relacji R(U) okrelone jest tylko wtedy, gdy zbir KROTKA(U) jest skoczony.

Operacje mnogociowe s okrelone na relacjach jednakowego typu i ich warto-ciami s rwnie relacje tego samego typu co argumenty. Przytoczone operacje mno-gociowe s zaweniem operacji dobrze znanych z teorii mnogoci, gdzie definiowa-ne s one w odniesieniu do dowolnych zbiorw.

Operacje relacyjne definiujemy zgodnie z [33] nastpujco:

PROJEKCJA

Dana jest relacja R(U) oraz zbir X U. Relacj T(X) nazywamy projekcj relacji R(U) na zbir X, co oznaczamy T = R[X] wtedy i tylko wtedy, gdy:

T = {t KROTKA(X) : (r R) t = r[X]} Przykad 5.1 Dana jest relacja R(U) stopnia trzeciego zawierajca informacj o studentach.

U jest zbiorem atrybutw U = {Nazwisko, Wydzia, Rok_studiw}.

36

Kady z atrybutw okrelony jest przez zbir wartoci: Nazwisko = {Nowak, Kowal, Owad, Jawor, Olski}, Wydzia = {Elektronika, Fi-

zyka, Matematyka}, Rok_studiw = {1, 2, 3}. Wykonujemy operacje projekcji relacji R na relacje T(X), gdzie X jest zbiorem

atrybutw X = {Nazwisko, Rok_studiw} i na relacje S(Y), gdzie Y = {Wydzia, Rok_studiw}

R(U): Nazwisko Wydzia Rok_studiw Nowak Fizyka 1 Kowal Elektronika 2 Owad Fizyka 1 Jawor Matematyka 3 Olski Fizyka 1

T(X): Nazwisko Rok_studiw Nowak 1 Kowal 2 Owad 1 Jawor 3 Olski 1

S(Y): Wydzia Rok_studiw Fizyka 1 Elektronika 2 Matematyka 3

W wyniku operacji projekcji uzyskujemy relacje T(X) i S(Y) stopnia drugiego. Czasa-mi w wyniku projekcji nastpuje utrata informacji. Sytuacj tak ilustruje przy- kad 5.2. Przykad 5.2 Projekcja relacji R(U) na T(X), gdzie: U = {Nazwisko, Imi, Wydzia}, X = {Nazwisko, Wydzia}

R(U): Nazwisko Imi Wydzia Nowak Ewa Fizyka Nowak Jan Fizyka Kowal Piotr Elektronika Kowal Adam Elektronika

37

T(X): Nazwisko Wydzia Nowak Fizyka Kowal Elektronika

CZENIE

Dane s relacje R(X) i S(Y) oraz Z = X Y. Relacje T(Z) nazywamy czeniem tej relacji wtedy i tylko wtedy, gdy:

T = {t KROTKA(Z) : t[X] R t[Y] S}

czenie T = R | S, inaczej zwane konkatenacj tych krotek, ktre maj jednakowe wartoci w zbiorze atrybutw X i Y. Przykad 5.3 Dane s dwie relacje: T(X) i S(Y), gdzie X = {Nazwisko, Rok_studiw} i Y = {Wy-

dzia, Rok_studiw}. Wykonujemy operacje czenia, w wyniku ktrej uzyskujemy relacje R(U).

T(X): Nazwisko Rok_studiw Nowak 1 Kowal 2 Owad 1 Jawor 3 Olski 1

S(Y): Wydzia Rok_studiw Fizyka 1 Elektronika 2 Matematyka 3

R(U): Nazwisko Wydzia Rok_studiw Nowak Fizyka 1 Kowal Elektronika 2 Owad Fizyka 1 Jawor Matematyka 3 Olski Fizyka 1

Przykad 5.4 Dane s dwie relacje A(X) stopnia drugiego i B(Y) stopnia trzeciego, gdzie: X =

{Nr dostawcy, Miasto}, a Y = {Nr dostawcy, Nr czci, data dostawy}. W wyniku operacji czenia dostajemy relacj Z(U) stopnia wyszego ni relacje A(X) i B(Y).

38

A(X): Nr_dostawcy Miasto 1020 Krakw 2040 Wrocaw 3000 Opole 4000 Opole

B(Y): Nr_dostawcy Nr_czci Data_dostawy 1020 100 1999 4000 107 2000 1110 201 1999 2040 207 1998 2020 100 1999

Z(U): Nr_dostawcy Miasto Nr_czci Data_dostawy 1020 Krakw 100 1999 2040 Wrocaw 207 1998 4000 Opole 107 2000

SELEKCJA

Relacje T(U) nazywamy selekcj relacji R(U) wzgldem warunku selekcji E.

T(U) = {t KROTKA(U) : E(t) = true} Przykad 5.5 Dana jest relacja R(U) gdzie U = {A, B, C, D}:

R(U): A B C D a x 1 3 a y 4 2 c x 3 3 b x 2 1

Przy warunku selekcji E(t) = C D (A = a A = b) w wyniku uzyskamy relacje

S(U):

S(U): A B C D a y 4 2 b x 2 1

39

DZIELENIE

Dana jest relacja R(U) zbir X U. Relacje T(U X) nazywamy podzieleniem re-lacji R przez zbir X wtedy i tylko wtedy, gdy

T = {t KROTKA(U X) : (s KROTKA(X) ) t | s R}

Przykad 5.6 Dana jest relacja R(U), gdzie U = {Nazwisko, Przedmiot}. Zbir wartoci, czyli

domena (DOM), dla atrybutu Nazwisko to DOM(Nazwisko) = {Nowak, Kowal, Owad}, a domena, czyli zbir wartoci dla atrybutu Przedmiot to DOM(Przedmiot) = {Fizyka, Matematyka, Obwody}.

R(U): Nazwisko Przedmiot Nowak Fizyka Kowal Matematyka Owad Fizyka Owad Obwody Nowak Matematyka Nowak Obwody

Wynikiem podzielenia relacji R(Nazwisko, Przedmiot) przez zbir {Przedmiot} jest relacja:

T(U X): Nazwisko Nowak

Jeli (s, p) R(S, P) oznacza, e student s zda egzamin z przedmiotu p, to zbir R/{s} jest zbiorem tych studentw, ktrzy zdali egzaminy ze wszystkich przedmiotw.

Operacje mnogociowe i relacyjne tworz zbir operacji algebry relacji. Algebra ta jest podstaw do tworzenia jzyka manipulacji danych w relacyjnej bazie danych. Operacje relacyjne, przede wszystkim projekcja i czenie, su do badania zalenoci midzy danymi oraz do projektowania schematu logicznego bazy relacyjnej. Aby wprowadzi pojcie schematu relacyjnego, naley wyjani znaczenie zalenoci funkcyjnej.

5.4. Schemat relacyjny

We wstpie do czci pierwszej okrelono pojcie schematu bazy danych. Schemat jest stay, niezmienny dla danej bazy. Zmiana schematu to stworzenie zupenie nowej bazy. Schemat bazy relacyjny zwany dalej schematem relacyjnym opisuje wasnoci

40

statyczne bazy relacyjnej. Schemat relacyjny to zbir encji, pomidzy ktrymi s po-wizania bdce na rwni z encjami nonikami informacji. Aby wyjani pojcie schematu relacyjnego, podano nastpujcy przykad:

Przykad 5.7 Dana jest relacja: R(U) = E(I, N, P, O), gdzie: I numer indeksu, N nazwisko

studenta, P przedmiot egzaminu, O ocena egzaminu. Aby relacja moga reprezen-towa pewn informacj, musi mie cechy, ktre si nie zmieniaj w czasie. Te cechy to: numer indeksu i E(I) majcy jednoznacznie przyporzdkowane nazwisko n E(N). Kady numer to jedno nazwisko, lecz niekoniecznie odwrotnie. Kadej parze (i, p) E(I, P) przyporzdkowano jednoznacznie ocen o E(O). Podane przy-kady powiza nosz nazw zalenoci funkcyjnych midzy okrelonymi zbiorami atrybutw.

Schematem relacyjnym nazywamy par uporzdkowan R = (U, F) o zbiorze atry-butw U i zbiorze zalenoci funkcyjnych F opisanych nad U.

Przykad 5.8 Jeeli zbir atrybutw U = {I, N, P, O} i zbir zalenoci funkcyjnych okrelimy

jako F = {I N, IP O}, to schemat relacyjny E: E = ({I, N, P, O}, {I N, IP O})

W schemacie moemy okreli klucz gwny, czyli atrybut lub minimalny podzbir zbioru atrybutw, ktre maj cech jednoznacznego, unikalnego identyfikowania kro-tek w kadej relacji.

Przykad 5.9 Dla schematu relacyjnego E:

E = ({I, N, P, O}, {I N, IP O}) Cech jednoznacznej identyfikacji maj IP, INP, INPO. Najmniejszym z nich jest IP. W dalszej czci atrybuty bdce kluczami bd podkrelane. Pozostae bdziemy nazywa atrybutami niekluczowymi.

5.5. Rozkad schematu relacyjnego

Analiza zalenoci funkcyjnych midzy kluczami a pozostaymi atrybutami w schemacie relacyjnym pozwala orzeka o posiadaniu przez schemat pewnych nie-podanych waciwoci, czyli defektw. Defekty te mog by usuwane drog odpo-wiedniego procesu rozkadania tych schematw na schematy elementarne. Proces ten nazywa si normalizacj. Rozkad schematw na elementarne moe odbywa si:

41

bez straty danych, bez straty zalenoci funkcyjnych, bez straty danych i zalenoci rwnoczenie na skadowe niezalene. Schemat relacji R(U, F) jest rozkadalny bez straty danych na dwa schematy R[X]

i R[Y], gdy X Y =U i dla kadej relacji R = R[X] | R[Y] (twierdzenie i dowd w [33]).

Przykad 5.10 Relacja E (I, N, P, O) mwi nam o tym, e student o numerze indeksu i I, nazwi-

sku n N zda egzamin z przedmiotu p P, na ocen o O. Czyli schemat relacyjny ma posta E = ({I, N, P, O}, {I P, IP O})

E: I N P O 80001 Ajacki Fizyka 5 80001 Ajacki Matematyka 3 80003 Nowak Fizyka 4 80004 Kowal Fizyka 4 80003 Nowak Matematyka 5 80006 Celer Fizyka 2 80006 Celer Matematyka 2

Relacje E mona rozoy na schematy elementarne (wykona operacje projekcji) na kilka sposobw.

Sposb 1 (tabele E1, E2)

E1: I N 80001 Ajacki 80003 Nowak 80004 Kowal 80006 Celer

E2: I P O 80001 Fizyka 5 80001 Matematyka 3 80003 Fizyka 4 80004 Fizyka 4 80003 Matematyka 5 80006 Fizyka 2 80006 Matematyka 2

42

Sposb 2 (tabele E2, E3)

E2: I P O 80001 Fizyka 5 80001 Matematyka 3 80003 Fizyka 4 80004 Fizyka 4 80003 Matematyka 5 80006 Fizyka 2 80006 Matematyka 2

E3: I N P 80001 Ajacki Fizyka 80001 Ajacki Matematyka 80003 Nowak Fizyka 80004 Kowal Fizyka 80003 Nowak Matematyka 80006 Celer Fizyka 80006 Celer Matematyka

Sposb 3 (tabele E1, E2, E4)

E1: I N 80001 Ajacki 80003 Nowak 80004 Kowal 80006 Celer

E2: I P O 80001 Fizyka 5 80001 Matematyka 3 80003 Fizyka 4 80004 Fizyka 4 80003 Matematyka 5 80006 Fizyka 2 80006 Matematyka 2

E4: I P 80001 Fizyka 80001 Matematyka 80003 Fizyka 80004 Fizyka 80003 Matematyka 80006 Fizyka 80006 Matematyka

43

Dla wszystkich przypadkw mamy:

E1 | E2 = E2 | E3 = E1 | E2 | E4

A wic wszystkie s poprawne, jednak sposb 1 jest bardziej naturalny i lepiej oddaje semantyk odwzorowania rzeczywistoci. Mona zauway, e rozkady 1 i 3 daj dwie identyczne tabelki, a dodatkowo przy 3 rozkadzie mamy jeszcze jedn nadmia-row tabel. Jeeli interesuje nas informacja o uczszczaniu na wykady, to bardziej przydatny jest rozkad sposobem 3.

Rozkad schematu bez straty zalenoci funkcyjnych ilustruje przykad 5.11:

Przykad 5.11 Mamy dany schemat relacyjny R:

R = (U, F) = ({S, W, D}, {S W, S D, D W, W D}) gdzie:

S nazwisko studenta, D nazwisko dziekana, W wydzia Relacja R ma nastpujce wartoci:

R: S W D Nowak Elektronika Biernatt Kowal Chemia Wojtas Makow Elektronika Biernatt Olcki Chemia Wojtas

Moemy dokona rozkadu wg zalenoci: 1. S W(S D)

R1: S W Nowak Elektronika Kowal Chemia Makow Elektronika Olcki Chemia

R2: S D Nowak Biernatt Kowal Wojtas Makow Biernatt Olcki Wojtas

44

2. D W

R3: W D Elektronika Biernatt Chemia Wojtas

R4: S D Nowak Biernatt Kowal Wojtas Makow Biernatt Olcki Wojtas

3. W D

R5: W D Elektronika Biernatt Chemia Wojtas

R6: S W Nowak Elektronika Kowal Chemia Makow Elektronika Olcki Chemia

Mona atwo stwierdzi, e dla wszystkich rozkadw relacje speniaj warunek

R = R1 | R2 = R3 | R4 = R5 | R6 Dla schematw mona rwnie okreli takie same zalenoci funkcyjne. R1 = R6 = ({S, W}), {S W}) R2 = R4 = ({S, D}), {S D}) R3 = R5 = ({W, D}), {W D, D W}) W wyniku czenia schematw mamy: R1 | R2 = ({S, W, D}), {S W, S D}) R3 | R4 = ({S, W, D}), {S D, W D, D W}) R5 | R6 = ({S, W, D}), {S W, W D, D W}) Czyli R = R3 | R4 = R5 | R6 R1 | R2 W podanym przykadzie rozkady byy bez straty danych, ale nie wszystkie byy

bez straty zalenoci. W rozkadzie R1 | R2 gubimy zalenoci W D, D W. Przy

45

czeniu schematw R3 | R4 zaleno S W mona wyprowadzi z pozostaych, tak jak S D ze schematw R5 | R6. Okazuje si rwnie, e rozkady bez straty zale-noci nie zawsze s rozkadami bez straty danych [33]. Rozkady, ktre zachowuj rwnoczenie dane i zalenoci zwane s rozkadami na skadowe niezalene. Bada je Rissanen [36, 37]. Proces rozkadu schematu relacyjnego na zbir schematw nazwa-no procesem dekompozycji lub normalizacji.

5.6. Normalizacja

Termin normalizacja pochodzi od pojcia postaci normalnej [13, 14, 15, 16], ktre wprowadzi twrca modelu relacyjnego Codd. Pierwsza posta normalna (1PN) okre-la, e relacja jest tabel, w ktrej na przeciciu kadej kolumny i kadego wiersza warto atrybutu jest wartoci atomow, tzn. nie zbiorem, cigiem tylko wartoci pojedyncz. Przykadami 1PN s tabele rozpatrywane w rozkadach bez straty danych i bez straty zalenoci funkcyjnych. Tabele te maj pewne anomalia. Aby wyjani z jakimi anomaliami mamy do czynienia i jak ich naley unika, posuymy si przy-kadem.

Przykad 5.12 Dany jest schemat relacyjny

E = ({I, N, A, K, P, O}, {I NAK, IP O}) gdzie:

I numer indeksu, N nazwisko, A adres studenta, K kierunek studiw, P przedmiot, O ocena, IP klucz danego schematu.

E: I N A K P O 77100 Kowal Wrocaw Elektronika Matematyka 3 77100 Kowal Wrocaw Elektronika Fizyka 4 77101 Nowak Legnica Chemia Matematyka 3 77102 Olcki Wrocaw Chemia Matematyka 3 77100 Kowal Wrocaw Elektronika Ekonomia 5

Okazuje si, e jeli zbudujemy schemat relacyjny z tabel okrelon przez zbir

atrybutw (w tym przypadku U = {I, N, A, K, P, O}), to informacja zawarta w tej tabe-li nie zawsze bdzie prawdziwa. Nieprawidowoci wystpujce w tym schemacie to anomalia:

doczania w relacji reprezentowane s tylko nazwiska tych studentw, ktrzy zdali egzamin z danego przedmiotu, inaczej klucz IP nie byby peny,

46

aktualizacji zmiana adresu pociga za sob konieczno przegldania duej, czsto zmiennej liczby krotek; moe to doprowadzi przed kocem aktualizacji do sprzecznej informacji w bazie,

usuwania student 77102 zda egzamin tylko z jednego przedmiotu, jeli go uniewanimy, trzeba usun ca informacj o studencie.

Nieprawidowoci wynikaj z tego, e nie wszystkie atrybuty zalene s od caego klucza, niektre zalene s tylko od jego czci, czyli istnieje tzw. niepena zaleno funkcyjna od klucza. Likwidacja tej zalenoci jest moliwa dziki okreleniu drugiej postaci normalnej (2PN), czyli dziki rozkadowi schematu za pomoc operacji projekcji.

Tabele relacji s nastpujce:

E1: I N A K 77100 Kowal Wrocaw Elektronika 77101 Nowak Legnica Chemia 77102 Olcki Wrocaw Chemia

E2: I P O 77100 Matematyka 3 77100 Fizyka 4 77101 Matematyka 3 77102 Matematyka 3 77100 Ekonomia 5

E = E[I, N, A, K] | E [I, P, O] rozoono na dwie relacje: E1 = ({I, N, A, K}, {I NAK}) i E2 = ({I, P, O}, {IP O}) Przeprowadzajc schemat relacyjny do 2PN trzeba bra pod uwag nastpujce

fakty: schemat jest ju w 2PN, jeli kady jego klucz jest jednoelementowy, przeprowadzanie schematu relacyjnego do 2PN nie jest procesem jednoznacz-

nym, tzn. dla jednego schematu moe istnie wiele rwnowanych informacyjnie ukadw projekcji tego schematu w 2PN,

spord zbioru ukadu rwnowanych schematw relacyjnych wybieramy to rozwizanie, ktre zawiera najmniej elementw. Nazywamy go ukadem minimalnym. Ukad ten jest o tyle optymalny, o ile prawd jest, e wraz ze wzrostem liczby relacji wzrasta zoono ukadu.

Schemat bdcy w 2PN moe rwnie posiada nieprawidowoci.

47

Przykad 5.13 Dany jest schemat relacyjny:

E = ({W, A, P, D}, {W APD, P D})

gdzie: W wykonawca stanowi klucz relacji, A adres, P projekt, D data ukoczenia

projektu.

E: W A P D Budrem Krakw P1000 99 Elpo Opole P1000 99 WRT Opole P1001 98 WSK d P1002 97

W schemacie okrelone s pewne funkcje: kady wykonawca W ma jednoznacznie okrelony adres A, dla kadego wykonawcy W jest jednoznacznie okrelona data D ukoczenia pro-

jektu P, termin ukoczenia projektu P jest taki sam dla wszystkich jego wykonawcw W. Pomimo e schemat jest w 2PN, posiada nastpujce nieprawidowoci: doczania nie ma informacji o projekcie P i dacie D jego zakoczenia, jeli nie

jest okrelony cho jeden jego wykonawca W, aktualizacji zmiana daty D ukoczenia projektu P pociga za sob konieczno

przegldania duej, czsto zmiennej liczby krotek (moe to doprowadzi przed ko-cem aktualizacji do sprzecznej informacji w bazie),

usuwania zaniechanie wykonywania projektu P powoduje czasami wykrelenie caej informacji o projekcie.

Wymienione anomalia wynikaj z tego, e niektre atrybuty (A i P) s zalene tyl-ko od klucza W, natomiast D od atrybutu nie bdcego kluczem. Czyli istnieje tzw. zaleno przechodnia.

W wyniku procesu normalizacji schematu relacyjnego E uzyskamy nastpujce schematy elementarne E1 i E2:

E1: W A P Budrem Krakw P1000 Elpo Opole P1000 WRT Opole P1001 WSK d P1002

48

E2: P D P1000 99 P1001 98 P1002 97

E = E[W, A, P] | E[P, D] rozoono na dwa schematy: E1 = ({W, A, P}, {W AP}) i E2 = ({P, D}, {P D}) Przeprowadzajc schemat relacyjny do trzeciej postaci normalnej (3PN) trzeba

bra pod uwag nastpujce fakty: przeprowadzanie schematu relacyjnego do 3PN nie jest procesem jednoznacz-

nym, tzn. dla jednego schematu moe istnie wiele rwnowanych informacyjnie ukadw projekcji tego schematu w 3PN,

spord zbioru ukadu rwnowanych schematw relacyjnych wybieramy to rozwizanie, ktre zawiera najmniej elementw. Nazywamy go ukadem minimalnym. Ukad ten jest o tyle optymalny, o ile prawd jest, e wraz ze wzrostem liczby relacji wzrasta zoono ukadu.

kady schemat w 3PN ma t waciwo, e midzy atrybutami niekluczowymi nie ma zalenoci funkcyjnej. Czyli w relacjach wraz ze zmian wartoci atrybutu niekluczowego nie jest zwizana anomalia. Waciwo ta przysuguje jedynie atrybu-tom niekluczowym.

W 3PN istniej jednak defekty zwizane z atrybutami kluczowymi. Atrybuty klu-czowe mog by zalene funkcyjnie midzy sob, mog by zalene funkcyjnie od atrybutw niekluczowych, jak rwnie od czci pewnego klucza, do ktrego nie na-le. W 3PN moe wic istnie niepena i przechodnia zaleno atrybutw kluczo-wych. Prowadzi to do powstawania anomalii omawianych poprzednio. Anomalia te wynikaj z tego e schemat relacyjny E nie jest w postaci normalnej BoyceaCodda [15, 33]. Z licznych dowiadcze wynika jednak, e ta posta nie zawsze jest poda-na. Dlatego problem ten musi by rozwizywany inaczej, na przykad przez zastoso-wanie algorytmw syntezy schematw relacyjnych [25].

Zaleno funkcyjna odzwierciedla pewne semantyczne zwizki wynikajce z od-zwierciedlenia rzeczywistoci. Uoglnieniem zalenoci funkcyjnej jest zaleno wielowartociowa [22, 23]. Tak jak zaleno funkcyjna XY mwi nam, e kada krotka typu X wyznacza jednoznacznie krotk typu Y, to zaleno wielowartociowa X Y oznacza, e krotka typu X wyznacza jednoznacznie zbir krotek typu Y. Zale-no wielowartociowa nie ma wasnoci odwrotnej projekcji. Jak istotn rzecz jest uwzgldnienie zalenoci wielowartociowych przy normalizacji pokazuje przykad analizowany w [33].

49

Przykad 5.14 Mamy schemat relacyjny S = (U, F M), gdzie: U = {P, K, S, W} P podrcznik, K kurs, S suchacz kursu, W wykadowca, F = {S K, K W, S W}, co oznacza, e:

jeden suchacz S uczestniczy w jednym kursie K, kady kurs K ma jednego wykadowc W, kady suchacz S ma jednego wykadowc W oraz

M = {K P}, co oznacza, e kady kurs ma zalecany zbir podrcznikw. Graficznie mona to przedstawi w postaci drzew binarnych:

1 sposb: S K 2 sposb: K W

(S,K)(S,P,W)

S W (K,W)(K,P,S)

S K

(S,W) (S,P) (S,K) (S,P)

(P,K,S,W)S K

(P,K,S,W)K W

3 sposb: K P 4 sposb: K P

(K,P) (K,S,W)K W

(K,P) (K,S,W)K W

(K,S) (K,W) (S,K) (S,W)

(P,K,S,W)K P

(P,K,S,W)K P

50

Przy dekompozycji wg SK lub KW uzyskujemy nienaturalny schemat po-wizania suchacza S z podrcznikiem P, bez okrelenia kursu K na jaki uczszcza suchacz. Bardziej naturalne jest poczenie wg K P kursu K i suchacza S (trzeci sposb) ni wykadowcy W i suchacza S (czwarty sposb). Oglnie mona stwier-dzi, e najpierw dekomponuje si schemat wedug powiza wielowartociowych, a nastpnie dopiero pozostae. Zaleno wielowartociowa czasami okrelana jest jako czwarta posta normalna (4PN).

Jedn z najwaniejszych czynnoci przy projektowaniu bazy danych jest utworze-nie schematu. Schemat przesdza o walorach uytkowych bazy, uatwia zrozumienie dziaania i manipulowania danymi w bazie oraz zmniejsza moliwo popenienia bdw. Czasami rwnie ma wpyw na efektywno pracy komputera.

Zadanie tworzenia schematu mona sformuowa nastpujco: Okrelamy jeden uniwersalny schemat bazy SU = {R = (U, F)}, czyli traktujemy

baz jako jedn wielk relacj, gdzie: U zbir wszystkich atrybutw wystpujcych w bazie, F zbir wszystkich powiza funkcyjnych i przeksztacamy w wyniku sto-sowania pewnej procedury w schemat SK = {Ri = (Ui, Fi), i = 1, 2, ... n} bdcy zbio-rem schematw relacyjnych przy zaoonych kryteriach. Jako kryteria przyjmuje si zwykle: stopie normalizacji schematw relacyjnych oraz liczb tych schematw. W literaturze [15, 21, 36, 38] spotykamy wiele algorytmw projektowania schematu bazy danych. Najistotniejsze wrd nich to:

algorytm dekompozycji [14] i jego rozszerzenia [22], algorytm Bernsteina [3], algorytm NiekludowejCalenki [33], algorytm Rissanena [36, 37]. aden z tych algorytmw nie moe by okrelany mianem najlepszego czy najgor-

szego. Algorytm dekompozycji i jego rozszerzenia pozwalaj co prawda uzyska schemat bazy w 4PN, jednak nie zachowuj zalenoci funkcyjnych, co w wielu wy-padkach stanowi istotn wad. W innych przypadkach niestosowanie tego algorytmu, ktry jako jedyny uwzgldnia zalenoci wielowartociowe, rwnie moe prowadzi do niewaciwych rozwiza. W algorytmie Bernsteina nie s zachowane dane, co powanie ogranicza jego uyteczno. Wydaje si, e najlepszym jest algorytm Nie-kludowejCalenki. Zachowuje zarwno dane jak i zalenoci oraz daje w wyniku rozkadu minimaln liczb schematw Ri . Niestety nie uwzgldnia zalenoci wielo-wartociowych. Metoda Rissanena daje rozkad zachowujcy dane i zalenoci, jed-nak liczba wynikowych schematw Ri jest maksymalna.

Rozpatrywane algorytmy maj charakter czysto syntaktyczny, ograniczaj si do analizy zalenoci funkcyjnych i wielowartociowych. Zakadaj, e zalenoci mi-dzy atrybutami s jednoznaczne. Nie bior pod uwag analizy semantycznej, ktra jest tak istotna w projektowaniu bazy. Mona je traktowa jako etap poredni przy two-rzeniu bazy na podstawie innych modeli ujmujcych problemy strukturalizacji i klasyfikacji obiektw.

51

5.7. Wskazwki praktyczne

Uyteczno bazy danych w duej mierze zaley od sposobu zdefiniowania tablic danych opisujcych obiekty oraz ich wzajemne relacje. Poprawne zestrukturalizowa-nie baz danych pozwala na szybki i atwy dostp do wszystkich potrzebnych informa-cji poprzez odtwarzanie powizanych elementw z bazy. Projektowanie bazy naley rozpocz od okrelenia przeznaczenia bazy i funkcji jakie ma spenia, a co za tym idzie od okrelenia jakiego rodzaju elementy danych potrzebne s do opisu obiektw oraz przewidzie moliwo rozszerzenia bazy w miar zwikszania funkcji spenia-nych przez t baz. A wic naley tworzy elastyczne struktury danych. Kolejnym krokiem jest ich logiczne zorganizowanie, czyli pogrupowanie elementw zwizanych z poszczeglnymi obiektami i umieszczenie ich w pojedynczych tabelach oraz utwo-rzenie tabel relacji opisujcych powizania pomidzy elementami danych z rnych tabel. W dobrze zaprojektowanej bazie aden element danych nie wystpuje wicej ni jeden raz. Wyjtkiem od tej reguy s elementy danych wykorzystywane jako klu-cze powiza. Aby powiza ze sob dwie tabele danych, wiersze musz mie takie same numery identyfikacyjne; tego typu powtarzanie si danych jest zatem konieczne. Operacj suc do uporzdkowania danych wedug zaoonej kolejnoci jest indek-sowanie. Przyspiesza ona wyszukiwanie danych. Rwnie rozmiar tabeli, a przede wszystkim liczba kolumn, ma wpyw na szybko uzyskiwania informacji, atwiej bowiem jest przetwarza dane w mniejszych tabelach ni w wikszych. Liczba ko-lumn w tabeli powinna by okrelona przez natur elementw danych. Naley prbo-wa grupowa pokrewne kolumny zwizane z tymi samymi obiektami danych w tych samych tabelach danych. W niektrych przypadkach, gdy do opisu obiektu potrzebna jest dua liczba kolumn mona je umieci w rnych tabelach. Wane jest, aby za-chowa rwnowag pomidzy liczb tabel a ich rozmiarami. Istotn spraw s powi-zania pomidzy elementami danych, a co za tym idzie powizania pomidzy tabelami. Wyjtek stanowi relacje typu jeden do jednego midzy obiektami, kiedy to obiekty te mona umieci w jednej tabeli. W kadym innym przypadku powtarzanie si elemen-tw powoduje marnotrawstwo pamici oraz zagroenie dla precyzji informacji w bazie. Typowe bazy danych pozwalaj spojrze na powizania midzy danymi na jeden z trzech sposobw: jako na wspomniane relacje typu 1:1 (jedno-jednoznaczne), 1:m lub n:1 (jedno-wieloznaczne lub wielo-jednoznaczne) oraz n:m. (wielo- -wieloznaczne). Spord tych trzech rodzajw relacji, relacje 1:1 stanowi najprostsze powizanie pomidzy obiektami danych. Ten typ relacji wie jeden obiekt z innym pojedynczym obiektem. Jeeli do przedstawienia obiektw w pamici komputera uywamy tabel, to obiekty te mona umieci we wsplnej tabeli. W praktyce relacje typu 1:1 midzy obiektami s rzadkoci i zapisywanie ich w jednej tabeli prowadzi do wielokrotnego powtarzania pl, a nawet caych wierszy tabeli. W przypadku po-wiza jeden do wielu jedn z kolumn tabeli rezerwuje si do przechowywania da-

52

nych stanowicych tzw. klucze podstawowe. Klucz podstawowy to minimalny pod-zbir zbioru atrybutw jednoznacznie identyfikujcy dane w tabeli. Do czenia z inn tabel danych przy opisywaniu relacji jeden do wielu niezbdna jest take kolumna lub kolumny stanowice klucze obce, tzn. odnoszce si do powizanych tabel. Jeli relacje midzy obiektami s wiele-wielu, to trzeba zdefiniowa i utworzy jedn lub wiele tabel relacji, aby te relacje obsuy. Tabele relacji wygldaj dokadnie tak samo jak zwyczajne tabele. W rzeczywistoci s to tabele danych. Jako takie skadaj si z pewnej liczby wierszy i kolumn. Istotn rnic midzy dwoma rodzajami tabel jest to, e w tabeli relacji przechowywane s elementy danych okrelajce powizania midzy dwoma obiektami danych. Kady wiersz takiej tabeli wie podstawowy klucz jednej tabeli z podstawowym kluczem innej. Tabela relacji moe nie mie kolumny wasnego klucza.

53

6. OBIEKTOWY MODEL DANYCH

6.1. Uwagi oglne

We wspczesnej informatyce obiektowo ma wiele rnych znacze [4, 11, 26]. Termin ten po raz pierwszy zosta zastosowany w odniesieniu do grupy jzykw pro-gramowania SIMULA. Wprowadzono pojcie abstrakcyjnego typu danych jako zinte-growanego pakietu struktur danych i procedur. Nastpnie zaczto go uywa w odnie-sieniu do baz danych. Gwna rnica midzy obiektowymi jzykami programowania a bazami danych jest taka, e obiektowe bazy danych wymagaj istnienia trwaych obiektw. W obiektowych jzykach programowania obiekty istniej tylko przez krtki czas podczas wykonywania programu. Prbowano rnych sposobw podejcia do problematyki baz danych [19, 27, 34, 40]. Poczwszy od wykorzystania moliwoci modelu relacyjnego i poszerzenie go o cechy obiektowe do zamiany relacyjnego mo-delu danych na bogatszy semantycznie model danych zawierajcy odpowiednio do potrzeb cechy obiektowoci. Przykadem tego jest stworzenie modelu nazwanego NF2 zawierajcego zagniedone relacje, czyli relacje nie w pierwszej postaci normalnej (1PN). Zostay one zaproponowane jako sposb operowania zoonymi obiektami. Obiekt zoony to obiekt o strukturze hierarchicznej, ktrego atrybuty mog mie wartoci zarwno elementarne, jak i zoone. Podobnie jak relacje proste, rwnie relacje zagniedone mog by definiowane przez podanie listy nazw kolumn. Nazwa kolumny w relacji zagniedonej moe odwoywa si do grupy wartoci atrybutw, a nie tylko do wartoci elementarnej atrybutu, przy czym kada z nich moe odwoy-wa si znowu do grupy wartoci.

Wikszo istniejcych systemw relacyjnych dostarcza uytkownikowi tylko ograniczonej liczby typw danych (integer, date, real itp). S one na og wystarczaj-ce do standardowych zastosowa [20, 31, 32]. Do aplikacji typu komputerowo wspo-magane projektowanie (CAD), czy systemw informacji geograficznej te typy danych nie s wystarczajco bogate. Rozszerzenie zakresu typu danych w zalenoci od zasto-sowa jest po prostu niepraktyczne. Lepszym rozwizaniem wydaje si danie uyt-kownikowi moliwoci nieograniczonego rozszerzania systemu baz danych o okrelo-ne przez niego i zaimplementowane tak zwane abstrakcyjne typy danych, w skrcie ADT (ang. Abstract Data Types). ADT jest to typ obiektu, ktry okrela dziedzin wartoci i zbir operacji zaprojektowanych do dziaania na tych wartociach [1, 9].

54

6.2. Obiekty i klasy

Obiektowa baza danych [29] skada si z obiektw i klas obiektw powizanych pewn liczb mechanizmw abstrakcji. Obiekt jest przeniesieniem do jzyka progra-mowania struktur faktycznie istniejcych w rzeczywistym wiecie. Obiekt okrelony jest przez swj stan lub zachowanie. W jzyku programowania stanem obiektu jest opisujcy go zestaw atrybutw, natomiast jego zachowanie definiuje zestaw metodprocedur, ktre moemy na nim wykona. Metody pozwalaj obiektowi na komunika-cj z innymi obiektami i s uaktualniane przez komunikaty przekazywane midzy obiektami. Metody i atrybuty s w obiekcie bezporednio powizane. W bazie obiek-towej dwa identyczne rekordy mog si odwoywa do dwch rnych obiektw dziki wprowadzeniu jednoznacznego identyfikatora generowanego przez system. Istnieje moliwo rozrniania dwch obiektw o takich samych cechach. Jest to niemoliwe w modelach relacyjnych, gdzie dwie identyczne krotki zawsze wskazuj ten sam obiekt. Wszystkie obiekty musz mie waciwo hermetyzacji. Jest to pro-ces umieszczania danych i procedur w jednym opakowaniu w ramach zde- finiowanego interfejsu i udostpnienie go z zewntrz w sposb kontrolowany przez interfejs. Hermetyzacja okrelona jest niejawnie w definicji obiektu, poniewa wszystkie operacje na obiektach musz by wykonywane przez zdefiniowane proce-dury doczone do obiektw. Uoglnieniem pojcia obiektu jest pojcie klasy. Klasa obiektw jest zgrupowaniem podobnych obiektw. Uywamy jej do okrelania wsplnych dla grupy obiektw atrybutw, metod i zwizkw. Klasy obiektw definiu-j schemat bazy danych. Obiektowy model danych dostarcza dwch mechanizmw, ktre umoliwiaj projektantowi bazy konstruowanie struktur lub konstruowanie hie-rarchii klas obiektw. Te mechanizmy abstrakcji to: uoglnienie i agregacja. Uogl-nienie umoliwia deklarowanie pewnych klas obiektw jako podklas innych klas obiektw, np. klasy Kierownik, Sekretarka, Technik mog by zadeklarowane jako podklasy klasy Pracownik. Agregacja jest procesem, dziki ktremu obiekt wyszego poziomu jest uywany do grupowania pewnej liczby obiektw niszego poziomu. Na przykad encj Samochd mona zbudowa ze zbioru czci k, podwozia, silnika itp. Obiektowy model danych musi rwnie dostarcza sposobw na powizanie obiektw z klasami obiektw. W tym wypadku mwimy, e klasa obiektw klasyfiku-je obiekt lub odwrotnie, obiekt jest instancj klasy obiektw.

6.3. Atrybuty

Obiektowe bazy danych definiuj wiele rnych typw atrybutw. Mona je po-dzieli na takie, ktre odnosz si bezporednio do obiektu lub do caej klasy obiek-tw. Atrybuty obiektu opisuj stan konkretnego obiektu. Wyrniamy atrybuty proste, jednowartociowe oraz atrybuty zoone, wielowartociowe. Dziedzin atrybutw

55

prostych s typy danych znane ze strukturalnych jzykw programowania, np. integer, real, string i jako takie nie odbiegaj od atrybutw relacyjnych baz danych. Do atrybu-tw prostych zaliczamy rwnie atrybuty referencyjne, to znaczy takie, ktre definiuj powizania midzy obiektami. Wartoci takiego atrybutu jest identyfikator obiektu, ktrego dotyczy referencja. Atrybuty referencyjne odpowiadaj kluczom obcym w bazie relacyjnej. Atrybuty wielowartociowe skadaj si z wielu atrybutw prostych tworzcych takie struktury, jak: lista, kolekcja, tabela. Tego typu atrybuty zwikszaj elastyczno budowania zoonych struktur danych. Rwnie definicja obiektu, ktry wystpuje w definicji innego obiektu i tworzy obiekt kompozytowy moe by atrybu-tem wielowartociowym. Wystpuj rwnie atrybuty wyliczane. Warto takiego atrybutu nie jest przechowywana w obiekcie, lecz jest wyliczana w momencie odwo-ywania si do niego. Atrybut taki jest po prostu wywoaniem okrelonej metody obli-czajcej jego warto na podstawie stanu innych atrybutw.

6.4. Metody

Pena definicja metody danej klasy skada si z deklaracji i kodu. Deklaracja opi-suje dziaanie metody, okrela dokadnie nazw metody, nazwy i rodzaj argumentw i jeli metoda zwraca jaki wynik, to jego rodzaj, czyli klas. Sprawdzanie poprawno-ci podawanych w metodzie argumentw odbywa si musi na poziomie kompilacji. Kod metody to lista instrukcji w jzyku programowania (np. w jzyku C++) wykonu-jca operacje na podanych argumentach lub na argumentach klas. Nowy obiekt mona tworzy albo przez wykonanie operacji new, albo stosowanie obiektw prototypo-wych. Jeeli mamy do czynienia ze rodowiskiem mao zmieniajcym si, to do two-rzenia obiektw naley wykorzysta metod new. T sam metod new mona wywo-ywa w celu utworzenia wielu obiektw tej samej klasy. Metoda new jest metod danej klasy, nie bdzie ona natomiast metod obiektu. W nowo utworzonym obiekcie nie bd ju przechowywane informacje zawarte w definicji klasy, to jest wartoci atrybutw wsplnych dla wszystkich obiektw, czy implementacje metod. W przy-padku rodowiska szybko zmieniajcego si do tworzenia obiektw naley wykorzy-sta obiekty prototypowe. Nowy obiekt powstaje z ju istniejcego obiektu poprzez modyfikacj jego argumentw i metod. Aby zdefiniowa tre metody, trzeba uy standardowego jzyka programowania. Komunikaty musz zawiera nazw metody, identyfikator obiektu i odpowiednie parametry metody.

6.5. Dziedziczenie i tosamo obiektw

Podstawow cech programowania obiektowego i obiektowych baz danych jest mechanizm dziedziczenia. Pozwala on na tworzenie nowych klas zwanych podklasami z klas ju istniejcych. Proces dziedziczenia jest zwizany z pojciem hierarchii

56

uoglnienia. Istniej dwa gwne typy dziedziczenia: dziedziczenie struktury i dzie-dziczenie zachowania. Przy dziedziczeniu struktury mwimy, e podklasa dziedziczy atrybuty swojej nadklasy. Przy zaoeniu, e na przykad klasa Pracownik ma atrybu-ty: nazwisko, imi, adres, pensja wwczas podklasy: Kierownik, Sekretarka, Technik maj takie same atrybuty. Czyli struktura danych w podklasie jest przejmowana z klas zwanych nadklasami. Doczane s take wasne struktury podklasy. Przy dziedzicze-niu zachowania podklasa dziedziczy metody swojej nadklasy. Gdy klasa Pracownik ma okrelon metod OBLICZAJ PAC, to podklasa Kierownik te ma okrelon t metod. Jeeli obiektowa baza realizuje dziedziczenie pojedyncze, to klasa moe by podklas tylko jednej nadklasy. Jeli jedna klasa ma wiele podklas, mwimy wtedy o dziedziczeniu wielokrotnym. Przy dziedziczeniu wielokrotnym klasa moe dziedzi-czy atrybuty i metody od wicej ni jednej nadklasy. Jedn z zalet dziedziczenia jest to, e kod metod jest wykorzystywany przez wiele obiektw czsto nalecych do rnych klas. Najczciej uywane metody mog by zdefiniowane dla nadklasy, a w razie potrzeby redefiniowane w poszczeglnych podklasach. Dziedziczenie upraszcza w znaczny sposb tworzenie nowych klas. Dziedziczone struktury danych i metody mog by przenoszone w sposb bezporedni lub modyfikowane podczas przenoszenia z nadklasy do podklasy (np. zmiana nazwy atrybutu). W metodach do-starczajcych mechanizmu dziedziczenia wielokrotnego zachodz rne konflikty zwizane z dziedziczeniem atrybutw i metod. Przykadem moe tu by przypadek, gdy w nadklasach danej klasy s atrybuty czy metody o takiej samej nazwie, a rni-ce si semantyk czy wartociami. Powane problemy z dziedziczeniem wystpuj w przypadku zapyta do bazy. W jzyku zapyta mog by uywane rwnie metody. Jeeli w podklasie jaka metoda zostaa redefiniowana, to przy oglnym odwoaniu do tej metody wynik moe by bdny. Aby tego unikn, naley zachowa zgodno z atrybutami i metodami zdefiniowanymi w nadklasie. Mechanizm istnienia rnych funkcji pod t sama nazw nazywa si polimorfizmem. Przy wykonywaniu operacji na bazie wygodne jest uycie tej samej nazwy metody dla rnych rodzajw dziaa. Odbywa si to poprzez redefiniowanie metody zdefiniowanej na wyszym poziomie w hierarchii dziedziczenia. Metoda, pod ktrej nazw kryje si wiele implementacji nosi nazw metody przecionej. Tosamo obiektu jest to cecha, ktra pozwala od-rni go od pozostaych obiektw istniejcych w systemie. Ma to szczeglne znacze-nie podczas operacji wyszukiwania i kasowania. Dokadna identyfikacja jest korzyst-na, jeli si zaoy, e wartociami atrybutw obiektu mog by rwnie obiekty. Problem identyfikacji w systemach obiektowych dotyczy zarwno obiektw, jak i klas obiektw. Identyfikacj klas mona zapewni narzucajc unikalno nazwy. Obiekt ma unikalny identyfikator, ktry suy zarwno do identyfikacji obiektu jak i do wprowadzania powiza midzy obiektami, jeli wartoci atrybutu obiektu pewnej klasy jest inny obiekt. Identyfikator jest odpowiednikiem klucza w bazie relacyjnej. Zaletami stosowania identyfikatora obiektu w stosunku do klucza jest to, e klucz jest unikalny zwykle w obrbie relacji, natomiast identyfikator w caej bazie. Identyfikato-

57

ry s implementowane przez system, wic programista nie musi si obawia o odpo-wiedni ich dobr. Pojcie identyfikatora wprowadza pojcie rwnoci i identycznoci obiektw. Dwa obiekty s identyczne, gdy maj ten sam identyfikator. Dwa obiekty s rwne, jeli wartoci wszystkich atrybutw s rekursywnie rwne. Prawdziwe jest twierdzenie, e dwa obiekty identyczne s rwne, natomiast odwrotne jest faszywe.

6.6. Enkapsulacja

Enkapsulacja jest to rozdzielenie deklaracji i implementacji metod, dziki czemu uzyskuje si ochron danych przed niepowoanymi uytkownikami oraz zapewnia si prywatno zawartoci metod. Enkapsulacja umoliwia strukturalizacj programu poprzez jego podzia na niezalene moduy. Pena enkapsulacja zapewnia, e funkcjo-nowanie i wewntrzna budowa obiektu nie s widoczne dla pozostaych obiektw. Dostp do tego obiektu odbywa si poprzez metody tego obiektu wykonujce pewne operacje na danych zawartych w tym obiekcie. Wywoanie metod obiektu ma charak-ter oglny, natomiast struktura danych obiektu i operacje na nich wykonywane maj charakter lokalny. Pojcie enkapsulacji wywodzce si z obiektowych jzykw pro-gramowania nawizuje do abstrakcyjnych typw danych. Mona wyrni osobno miejsce deklaracji, gdzie umieszcza si wszystkie operacje jakie mog by wykony-wane na danym obiekcie, od miejsca definicji, w ktrym zawarte s wszystkie defini-cje danych opisujcych stan