Maria Chaon

SYSTEMY BAZ DANYCH

Wprowadzenie

Oficyna Wydawnicza Politechniki Wrocawskiej

Wrocaw 2001

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 zestrukturalizowane 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 powstaa jako rozszerzona wersja treci zaj prowadzonych dla studentw kierunku Informatyka. 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 podstawowych 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 metodologi projektowania baz danych.
2. W czci drugiej po krtkim wprowadzeniu przedstawiono wybrane metody reprezentacji 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 Wypoczynkowy 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 funkcji i danych baz posuy system Informix. W rozdziale tym nie mogo zabrakn
rwnie sposobu prezentacji danych w Internecie.

Satysfakcjonujce poczenie wiedzy teoretycznej z praktycznym jej wykorzystaniem 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 zajmujcych si teori i praktycznym tworzeniem baz danych w systemach informatycznych,
lecz take tych wszystkich informatykw, ktrzy w swojej pracy zawodowej zajmuj
si przetwarzaniem danych.

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

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 dosownie 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 jednoczenie 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 wasnoci statycznych i klasy wasnoci dynamicznych.
Wasnoci statyczne, zwane schematem bazy danych, s stae, niezmienne w czasie. Schemat odpowiada temu, co nazywamy zazwyczaj jzykiem definiowania danych (ang. Data Definition Language DDL). Jzyk ten definiuje dopuszczalne struktury 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 definiowania 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 Language 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 stwierdzenie faktw, ktre staj si prawdziwe lub przez zaprzeczenie faktw, ktre przestaj
by prawdziwe. Do tej klasy operacji nale rwnie takie operacje, ktre nie powoduj 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-

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 schematw 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 ktrej 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 faktami przechowywanymi w bazie a modelem rzeczywistym i kada zmiana wystpujca w modelu rzeczywistym musi by wprowadzona w bazie opisujcej ten model,
bezpieczestwo danych, czyli ograniczenie dostpu w celu zapewnienia integralnoci bazy. Problem bezpieczestwa jest bardzo wany i zostanie szczegowo omwiony 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 niewidoczna 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.

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. Pojawiy si wtedy pierwsze pakiety danych do uytku oglnego [18, 20].Tradycyjna baza
danych suya wycznie do przechowywania danych. Ich przetwarzanie wykonywane byo przez programy uytkowe wsppracujce z SZBD. Obsuga tych programw
bya tak skomplikowana, e wymagaa obecnoci programisty o duych kwalifikacjach. 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 danych. 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 bezporedniego 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 reprezentowania 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 integralnoci, zapyta i modyfikacji. Obecnie ich wad jest brak wydajnych implementacji 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 producentw 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]. Wida wic, e wielki wpyw na ksztat systemw baz danych ma: przetwarzanie wbu-

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 realizacji wielkiej liczby transakcji, wiele osb uznao lata dziewidziesite za er rozproszonych baz danych. Ostatnio mona rwnie zaobserwowa gwatowny wzrost prezentacji 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: <nazwa obiektu, cecha
obiektu, warto obiektu, czas>. Czas jest bardzo niewygodnym czynnikiem przy modelowaniu. 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, chocia 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 atrybutw, ktry w sposb jednoznaczny identyfikuje dan.
Klucz gwny klucz wybierany ze zbioru kluczy kandydujcych.
Jzyk Definiowania Danych (DDL) zbir regu wyraajcych wasnoci statyczne danych. DDL definiuje dopuszczalne struktury danych (obiekty i zalenoci midzy nimi), tworzc schemat bazy danych.
Przykad 3.1
Mamy dany schemat prostej sieciowej bazy [18] ZAOPATRZENIE przedstawionej na rys. 3.1.

11
DOSTAWCA
Dnr

Nazwa

CZ
Adres

D-D

Cznr

DOSTAWA

Data

Cena

CZ-D

Lcz
P-D

Nrproj

Adres

PROJEKT

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 czynienia 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
10
11
12
13
DOSTAWA:
Dnr
10
10
12
11

Adres

ETO
MTO
ZTO
WPP

WROCAW
WROCAW
WARSZAWA
KRAKW

Cznr
100
150
100
150

Nrproj
2000
2000
2001
2002

Data
15.09.2000
15.09.2000
20.01.2001
20.09.2001

3. Program:
a) R1 DOSTAWA (Cznr=100)
R1:
Dnr

Cznr

Nrproj

Data

Lcz

10
12

100
100

2000
2001

15.09.2000
20.01.2001

15
30

b) R2 R1 [Dnr]
R2:
Dnr
10
12

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

R3:
Dnr
10
12

Nazwa
ETO
ZTO

Adres
WROCAW
WARSZAWA

Lcz
15
20
30
10

14

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

Jzyk Zarzdzania Danymi (DCL) jest to zbir komend stworzonych do zapewnienia 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 uytkownikowi o nazwie EWA.
oglna posta komend:
GRANT {uprawnienia,./ALL}
ON {nazwa obiektu}
TO {nazwa uytkownika }

GRANT SELECT
ON ZAOPATRZENIE
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 realizowanymi transakcjami. Trwao wyniku transakcji polega na zapisywaniu w pamici
staej systemu wynikw, co chroni je przed awari procesu serwera. Z punktu widzenia aplikacji, transakcja to zbir kolejnych instrukcji nieproceduralnego jzyka manipulacji danymi o nazwie SQL (rozdz. 8). Zbir ten zakoczony jest instrukcj
COMMIT WORK (zatwierdzenie transakcji) lub ROLLBACK (anulowanie transakcji). W razie awarii systemu automatycznie realizowane jest anulowanie transakcji.
Baza danych zbir danych zorganizowanych w pewien logiczny i zestrukturalizowany sposb. Bieca struktura zaley od modelu danych przyjtego przy organizowaniu tych danych. Jej wielko zalena jest od liczby danych i od wzajemnych
powiza midzy nimi.
Sformatowana baza danych zbir danych w postaci skoczonego zbioru wzorcw (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 danych, umoliwienie rwnoczesnego dostpu wielu uytkownikom, wprowadzanie
mechanizmu bezpieczestwa i prywatnoci, odzyskiwanie danych i operowanie na
przechowywanych danych, wprowadzanie i adowanie danych, udostpnienie wydajnych 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 midzy rekordami, ktre na rwni z danymi s nonikami informacji (w przykadzie 3.1
powizanie okrelone jest sowem set). Systemy sieciowe s bardzo szybkie i efektywnie 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 pomidzy 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 sformuowa 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 konceptualny, model logiczny i model fizyczny (rys. 4.1).
wiat
rzeczywisty
Model konceptualny

Model logiczny

BAZA
DANYCH

Model fizyczny

Rys. 4.1. Modele bazy danych

Model konceptualny jest modelem wiata rzeczywistego. Najbardziej znanym modelem 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 przetwarzanych danych. W myl metody zaproponowanej przez Chena [3, 19] i szeroko stosowanej 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 rzeczywistym jaka powinna by odwzorowana w bazie danych, a wic zaprojektowanie schematu 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 wymagania [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 zasad posugiwania si danymi, np. modele klasyczne czy modele semantyczne danych.
Proces modelowania logicznego wie si z okreleniem zawartoci bazy danych niezalenie 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 oprogramowania.

4.2. Proces projektowania i jego skadowe

Proces projektowania obejmuje czynnoci i zdarzenia wystpujce midzy pojawieniem 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 zadania projektowego oraz od wielu rnych cech charakterystycznych dla projektowanych 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 formuowanie 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 dokumentu wedug standardw obowizujcych w danym systemie tworzy zaoenia projektowe. 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.

wiat
rzeczywisty

Schemat bazy
konceptualnej
Jzyk OS
Jzyk WI

Stan bazy
konceptualnej

Rys. 4.2. Tworzenie konceptualnej bazy danych

W etapie pierwszym naley zdefiniowa pewien wski podzbir jzyka naturalnego, sucy do opisu stanw wiata rzeczywistego (w skrcie Jzyk Opisu Stanw
OS) oraz jzyk sucy do formuowania wizw integralnoci (w skrcie Jzyk Wizw Integralnoci WI). Celem jest okrelenie, jakie w ogle obiekty wiata rzeczywistego, 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 rzeczywistym 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 odpowiadaj 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 pewnej niezmiennej waciwoci, jak ma rozpatrywany przez nas wycinek wiata rzeczywistego. Schemat jest stay, niezmienny, kada zmiana to zupenie nowa baza danych.
W etapie trzecim budowana jest pewna struktura matematyczna, czyli model abstrakcyjny 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 obejmowa 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. Model 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. Kady obiekt jest okrelony poprzez atrybuty majce pewne wartoci. Pomidzy obiektami istniej powizania. Obiekty, atrybuty, powizania i wartoci mona klasyfikowa
w zbiory. Podstaw tej klasyfikacji jest posiadanie przez nie pewnej wasnoci okrelonej dla kadego zbioru [19]. Obiekty reprezentowane s za pomoc wartoci atrybutw. Nazwa atrybutu jest na og jedn z jego wartoci. W celu jednoznacznej identyfikacji 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 wartoci. Nazywamy go kluczem gwnym. Wartoci, ktre klucz gwny przyporzdkowuje 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

nr ewidencyjny

imi i nazwisko

PACJENT

pe

adres
nr kart zdrowia

Rys. 4.3. Przedstawienie atrybutw zdefiniowanych na zbiorze encji PACJENT

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] skadajcego si z wierzchokw poczonych etykietowanymi krawdziami. Zarwno sposb okrelenia krawdzi midzy wierzchokami jak i przypisane etykiety przekazuj
istotn informacj o wasnociach semantycznych odwzorowywanego wiata rzeczywistego. 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 rysunku 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

posiada
posiada
oddziaw
oddziaw

personel
medyczny

ODDZIA

LEKARZ

ilo
ilo
personelu
personelu

PERSONEL

postawiona
diagnoza

zajto
oddziau

badania
laboratoryjne

LABORATORIUM

opieka
lekarska
przewidziane
badania

PACJENT

wykonane
badania

BADANIE

DIAGNOZA
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
podwadny

Zarzdza
personelem

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.

Lekarz
prowadzcy
LEKARZ

PACJENT

Lekarz
konsultujcy

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

LEKARZ

Zlecone
badania

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 zaokrglonych brzegach.
ODDZIA

Zajto
ka

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 prawdziwe lub faszywe. Inaczej mwic, s zachowane lub naruszone. Jeli wartoci danych 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 oglny 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 definiowa 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 dotyczy operacji. Naley tak definiowa operacje w bazie, aby w wyniku ich zastosowania nie naruszy integralnoci bazy. Jest i trzeci typ wizw, wizy niejawne. Mona
go wyprowadzi ze zdefiniowanych wizw wbudowanych i jawnych. W hierarchicznej bazie danych kady obiekt podrzdny ma najwyej jeden obiekt nadrzdny. Wynika 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 projektowaniem bazy danych powinny by przede wszystkim wystarczajco oglne i bogate semantycznie, ponadto powinny zawiera wszystkie podstawowe cechy systemw komercyjnych 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 dokumentacj 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 przeprowadzono 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 wicej tabel bez straty powiza zachodzcych midzy danymi (rozdz. 5).
W wyniku normalizacji w projektowanej bazie danych otrzymano nastpujce
tabele:

26

Tabele danych osobowych:

SPRZEDAWCA
ID_Sprzedawca
Nazwisko
Imi
Miasto
Kod
Ulica
Tel / Fax

DOSTAWCA
ID_Dostawca
Nazwisko
Imi
Miasto
Kod
Ulica
Tel / Fax

KLIENT
ID_Klient
Nazwisko
Imi
Miasto
Kod
Ulica
Tel / Fax

Tabele dotyczce towaru:

ELEMENT
ID_Producent
ID_Opis
ID_Dostawa
ID_Element
Warto
Cena
Sztuki

PODZESP
ID_Producent
ID_Opis
ID_Dostawa
ID_Podzesp
Nazwa
Cena
Gwarancja
Sztuki

PRODUCENT
ID_Producent
Nazwa_Firm
Miasto
Kod
Ulica
Tel / Fax

OPIS
ID_Opis
Opis

Tabele dotyczce transakcji:

DOSTAWA
ID_Dostawa
ID_Dostawca
Data_Dostawy

SPRZEDA
ID_Sprzeda
ID_Klient
ID_Sprzedawca
ID_Faktura
Data_Sprzeda
Cena_Sumaryczna

FAKTURA
ID_Faktura
ID_Sprzeda
Data_Wystawienia
Dane_Firm
Patno

Tabele powstae w celu wyeliminowania powiza zalenoci typu wiele do wielu

(n:m):
SPRZEDA
ELEMENTW
ID_Element
ID_Sprzeda
Sztuki

SPRZEDA
PODZESPOW
ID_Podzesp
ID_Sprzeda
Sztuki

czc poszczeglne tabele z uwzgldnieniem relacji midzy nimi otrzymano diagram 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 logicznego. Stanowi take punkt odniesienia w przypadku niejednoznacznoci, jakie
mog pojawi si przy interpretacji danych przez rnych uytkownikw. W wielomodelowych, lokalnych bazach danych schemat konceptualny stanowi integraln
cz bazy danych. Oprcz niego wspistniej w systemie schematy logiczne utworzone wedug rnych modeli danych. Wraz z rozwojem sieci komputerowych i zwizanych z nimi rozproszonych baz danych pojawia si zupenie nowe znaczenie schematu konceptualnego. Uytkownik korzystajc z bazy danych nie odczuwa, e baza ta
jest fragmentem systemu rozproszonego. Zawarto wszystkich baz danych tworzcych system rozproszony opisana jest w globalnym schemacie konceptualnym, z ktrego 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 aktualnie jest zwizany. Sposb przejcia z poziomu konceptualnego do logicznego zaley
przede wszystkim od typu bazy logicznej i metodologii jej projektowania. Ju na poziomie logicznym istniej rne metody projektowania schematw logicznych.
W podejciu sieciowym bierze si pod uwag nie tylko zwizki logiczne midzy danymi, ale take przewidywane sposoby i czsto odwoywania si do danych [1, 13].
Wpywa to dodatnio na efektywno systemu, ale jednoczenie zmniejsza niezaleno 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 jedynie zalenoci midzy atrybutami, ktre wyraaj pewne semantyczne wasnoci odwzorowywanego 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 Database 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. AddisonWesley 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 wykorzystywanym 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 konceptualny. Istnieje wiele rnorodnych modeli logicznych danych. Wrd modeli klasycznych na szczegln uwag zasuguje model relacyjny majcy jednolite podstawy teoretyczne. 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 pitego. Model relacyjny jest klasycznym przykadem sformatowanej bazy danych. Ostatnio wiele cech klasycznych modeli danych, a w szczeglnoci modelu relacyjnego
pojawio si pod nazw obiektowego modelu danych. Trudno jest jednoznacznie okreli, czy systemy obiektowych baz danych oferuj lepsze warunki do zarzdzania bazami 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 rzecz sensown uycie obiektowoci w standardowych aplikacjach komercyjnych baz
danych. Bazy obiektowe s tematem rozdziau szstego. Wraz z rozwojem takich waciwoci systemw baz danych, jak: rozproszenie, zarzdzanie obiektami o strukturze
hierarchicznej, przechowywanie tekstw, grafiki, obrazw, animacji, dwikw pojawi 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 przechowywanych 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. Charakterystyczn 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 reprezentowane przez dwuwymiarowe tablice,
nieproceduralne, deklaratywne jzyki manipulacji danymi jzyki nieproceduralne 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 pamitanych w relacjach informacji.
STUDENT

PRZEDMIOT

nr indeksu nazwisko data urodz.

nr przedmiotu nazwa

EGZAMIN
egzaminator

data

ocena

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 relacyjnym (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 wybranych 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 uporzdkowane). 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 kolumn 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 krotkach 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 wartociami s rwnie relacje tego samego typu co argumenty. Przytoczone operacje mnogociowe s zaweniem operacji dobrze znanych z teorii mnogoci, gdzie definiowane 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, Fizyka, 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
Nowak
Kowal
Owad
Jawor
Olski

Wydzia
Fizyka
Elektronika
Fizyka
Matematyka
Fizyka

T(X):
Nazwisko
Nowak
Kowal
Owad
Jawor
Olski

Rok_studiw
1
2
1
3
1

S(Y):
Wydzia
Fizyka
Elektronika
Matematyka

Rok_studiw
1
2
1
3
1

Rok_studiw
1
2
3

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

Imi
Ewa
Jan
Piotr
Adam

Wydzia
Fizyka
Fizyka
Elektronika
Elektronika

37
T(X):
Nazwisko
Nowak
Kowal

Wydzia
Fizyka
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 = {Wydzia, Rok_studiw}. Wykonujemy operacje czenia, w wyniku ktrej uzyskujemy
relacje R(U).
T(X):
Nazwisko
Nowak
Kowal
Owad
Jawor
Olski
S(Y):
Wydzia
Fizyka
Elektronika
Matematyka
R(U):
Nazwisko
Nowak
Kowal
Owad
Jawor
Olski

Rok_studiw
1
2
1
3
1

Rok_studiw
1
2
3

Wydzia
Fizyka
Elektronika
Fizyka
Matematyka
Fizyka

Rok_studiw
1
2
1
3
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
1020
2040
3000
4000

Miasto
Krakw
Wrocaw
Opole
Opole

B(Y):
Nr_dostawcy
1020
4000
1110
2040
2020

Nr_czci
100
107
201
207
100

Data_dostawy
1999
2000
1999
1998
1999

Z(U):
Nr_dostawcy
1020
2040
4000

Miasto
Krakw
Wrocaw
Opole

Nr_czci
100
207
107

Data_dostawy
1999
1998
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
a
a
c
b

B
x
y
x
x

C
1
4
3
2

D
3
2
3
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 relacji 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
Nowak
Kowal
Owad
Owad
Nowak
Nowak

Przedmiot
Fizyka
Matematyka
Fizyka
Obwody
Matematyka
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 powizania 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 reprezentowa 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 przykady powiza nosz nazw zalenoci funkcyjnych midzy okrelonymi zbiorami
atrybutw.
Schematem relacyjnym nazywamy par uporzdkowan R = (U, F) o zbiorze atrybutw 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 krotek 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 niepodanych waciwoci, czyli defektw. Defekty te mog by usuwane drog odpowiedniego 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, nazwisku 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
80001
80001
80003
80004
80003
80006
80006

N
Ajacki
Ajacki
Nowak
Kowal
Nowak
Celer
Celer

P
Fizyka
Matematyka
Fizyka
Fizyka
Matematyka
Fizyka
Matematyka

O
5
3
4
4
5
2
2

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

kilka sposobw.
Sposb 1 (tabele E1, E2)
E1:
I
80001
80003
80004
80006
E2:
I
80001
80001
80003
80004
80003
80006
80006

N
Ajacki
Nowak
Kowal
Celer

P
Fizyka
Matematyka
Fizyka
Fizyka
Matematyka
Fizyka
Matematyka

O
5
3
4
4
5
2
2

42

Sposb 2 (tabele E2, E3)

E2:
I
80001
80001
80003
80004
80003
80006
80006

P
Fizyka
Matematyka
Fizyka
Fizyka
Matematyka
Fizyka
Matematyka

E3:
I
80001
80001
80003
80004
80003
80006
80006

N
Ajacki
Ajacki
Nowak
Kowal
Nowak
Celer
Celer

O
5
3
4
4
5
2
2

P
Fizyka
Matematyka
Fizyka
Fizyka
Matematyka
Fizyka
Matematyka

Sposb 3 (tabele E1, E2, E4)

E1:
I
80001
80003
80004
80006

N
Ajacki
Nowak
Kowal
Celer

E2:
I
80001
80001
80003
80004
80003
80006
80006

P
Fizyka
Matematyka
Fizyka
Fizyka
Matematyka
Fizyka
Matematyka

E4:
I
80001
80001
80003
80004
80003
80006
80006

P
Fizyka
Matematyka
Fizyka
Fizyka
Matematyka
Fizyka
Matematyka

O
5
3
4
4
5
2
2

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 nadmiarow 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
Nowak
Kowal
Makow
Olcki

W
Elektronika
Chemia
Elektronika
Chemia

D
Biernatt
Wojtas
Biernatt
Wojtas

Moemy dokona rozkadu wg zalenoci:

1. S W(S D)
R1:
S
Nowak
Kowal
Makow
Olcki

W
Elektronika
Chemia
Elektronika
Chemia

R2:
S
Nowak
Kowal
Makow
Olcki

D
Biernatt
Wojtas
Biernatt
Wojtas

44

2. D W
R3:
W
Elektronika
Chemia
R4:
S
Nowak
Kowal
Makow
Olcki

D
Biernatt
Wojtas

D
Biernatt
Wojtas
Biernatt
Wojtas

3. W D
R5:
W
Elektronika
Chemia
R6:
S
Nowak
Kowal
Makow
Olcki

D
Biernatt
Wojtas

W
Elektronika
Chemia
Elektronika
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 zalenoci 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 nazwano 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) okrela, 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 przykadem.
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
77100
77100
77101
77102
77100

N
Kowal
Kowal
Nowak
Olcki
Kowal

A
Wrocaw
Wrocaw
Legnica
Wrocaw
Wrocaw

K
Elektronika
Elektronika
Chemia
Chemia
Elektronika

P
Matematyka
Fizyka
Matematyka
Matematyka
Ekonomia

O
3
4
3
3
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 tabeli 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
77100
77101
77102

N
Kowal
Nowak
Olcki

E2:
I
77100
77100
77101
77102
77100

P
Matematyka
Fizyka
Matematyka
Matematyka
Ekonomia

A
Wrocaw
Legnica
Wrocaw

K
Elektronika
Chemia
Chemia

O
3
4
3
3
5

E = E[I, N, A, K] | E [I, P, O] rozoono na dwie relacje:

E1 = ({I, N, A, K}, {I NAK})

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 jednoznacznym, 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
Budrem
Elpo
WRT
WSK

A
Krakw
Opole
Opole
d

P
P1000
P1000
P1001
P1002

D
99
99
98
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 projektu 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 kocem 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 tylko 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
Budrem
Elpo
WRT
WSK

A
Krakw
Opole
Opole
d

P
P1000
P1000
P1001
P1002

48
E2:
P
P1000
P1001
P1002

D
99
98
97

E = E[W, A, P] | E[P, D] rozoono na dwa schematy:

E1 = ({W, A, P}, {W AP})

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 jednoznacznym, 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 atrybutom niekluczowym.
W 3PN istniej jednak defekty zwizane z atrybutami kluczowymi. Atrybuty kluczowe mog by zalene funkcyjnie midzy sob, mog by zalene funkcyjnie od
atrybutw niekluczowych, jak rwnie od czci pewnego klucza, do ktrego nie nale. W 3PN moe wic istnie niepena i przechodnia zaleno atrybutw kluczowych. 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 podana. Dlatego problem ten musi by rozwizywany inaczej, na przykad przez zastosowanie algorytmw syntezy schematw relacyjnych [25].
Zaleno funkcyjna odzwierciedla pewne semantyczne zwizki wynikajce z odzwierciedlenia rzeczywistoci. Uoglnieniem zalenoci funkcyjnej jest zaleno
wielowartociowa [22, 23]. Tak jak zaleno funkcyjna X Y 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. Zaleno 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

(P,K,S,W)

(P,K,S,W)

SK

KW

(S,P,W)

(S,K)

(S,W)

(S,K)

4 sposb: K

(P,K,S,W)

(K,P)

SK

(S,P)

3 sposb: K
K

(K,P,S)

(K,W)

SW

(P,K,S,W)

(K,S,W)

(K,P)

(K,S,W)

KW

(K,S)

(S,P)

KW

(K,W)

(S,K)

(S,W)

50

Przy dekompozycji wg S K lub K W uzyskujemy nienaturalny schemat powizania 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 stwierdzi, 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 utworzenie 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 stosowania pewnej procedury w schemat SK = {Ri = (Ui, Fi), i = 1, 2, ... n} bdcy zbiorem 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 najgorszego. Algorytm dekompozycji i jego rozszerzenia pozwalaj co prawda uzyska
schemat bazy w 4PN, jednak nie zachowuj zalenoci funkcyjnych, co w wielu wypadkach 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 NiekludowejCalenki. Zachowuje zarwno dane jak i zalenoci oraz daje w wyniku
rozkadu minimaln liczb schematw R i . Niestety nie uwzgldnia zalenoci wielowartociowych. Metoda Rissanena daje rozkad zachowujcy dane i zalenoci, jednak liczba wynikowych schematw R i jest maksymalna.
Rozpatrywane algorytmy maj charakter czysto syntaktyczny, ograniczaj si do
analizy zalenoci funkcyjnych i wielowartociowych. Zakadaj, e zalenoci midzy atrybutami s jednoznaczne. Nie bior pod uwag analizy semantycznej, ktra jest
tak istotna w projektowaniu bazy. Mona je traktowa jako etap poredni przy tworzeniu 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 zestrukturalizowanie baz danych pozwala na szybki i atwy dostp do wszystkich potrzebnych informacji 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 spenianych 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 utworzenie 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 klucze 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 indeksowanie. 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 kolumn w tabeli powinna by okrelona przez natur elementw danych. Naley prbowa 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 zachowa rwnowag pomidzy liczb tabel a ich rozmiarami. Istotn spraw s powizania 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 elementw 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 powiza jeden do wielu jedn z kolumn tabeli rezerwuje si do przechowywania da-

52

nych stanowicych tzw. klucze podstawowe. Klucz podstawowy to minimalny podzbir 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 programowania SIMULA. Wprowadzono pojcie abstrakcyjnego typu danych jako zintegrowanego pakietu struktur danych i procedur. Nastpnie zaczto go uywa w odniesieniu 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 modelu 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 odwoywa si znowu do grupy wartoci.
Wikszo istniejcych systemw relacyjnych dostarcza uytkownikowi tylko
ograniczonej liczby typw danych (integer, date, real itp). S one na og wystarczajce do standardowych zastosowa [20, 31, 32]. Do aplikacji typu komputerowo wspomagane projektowanie (CAD), czy systemw informacji geograficznej te typy danych
nie s wystarczajco bogate. Rozszerzenie zakresu typu danych w zalenoci od zastosowa jest po prostu niepraktyczne. Lepszym rozwizaniem wydaje si danie uytkownikowi moliwoci nieograniczonego rozszerzania systemu baz danych o okrelone 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 programowania 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 metod
procedur, ktre moemy na nim wykona. Metody pozwalaj obiektowi na komunikacj z innymi obiektami i s uaktualniane przez komunikaty przekazywane midzy
obiektami. Metody i atrybuty s w obiekcie bezporednio powizane. W bazie obiektowej 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 proces umieszczania danych i procedur w jednym opakowaniu w ramach zdefiniowanego 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 procedury 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 definiuj schemat bazy danych. Obiektowy model danych dostarcza dwch mechanizmw,
ktre umoliwiaj projektantowi bazy konstruowanie struktur lub konstruowanie hierarchii klas obiektw. Te mechanizmy abstrakcji to: uoglnienie i agregacja. Uoglnienie 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 klasyfikuje obiekt lub odwrotnie, obiekt jest instancj klasy obiektw.

6.3. Atrybuty
Obiektowe bazy danych definiuj wiele rnych typw atrybutw. Mona je podzieli na takie, ktre odnosz si bezporednio do obiektu lub do caej klasy obiektw. 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 atrybutw 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 atrybutem wielowartociowym. Wystpuj rwnie atrybuty wyliczane. Warto takiego
atrybutu nie jest przechowywana w obiekcie, lecz jest wyliczana w momencie odwoywania si do niego. Atrybut taki jest po prostu wywoaniem okrelonej metody obliczajcej jego warto na podstawie stanu innych atrybutw.

6.4. Metody
Pena definicja metody danej klasy skada si z deklaracji i kodu. Deklaracja opisuje dziaanie metody, okrela dokadnie nazw metody, nazwy i rodzaj argumentw
i jeli metoda zwraca jaki wynik, to jego rodzaj, czyli klas. Sprawdzanie poprawnoci podawanych w metodzie argumentw odbywa si musi na poziomie kompilacji.
Kod metody to lista instrukcji w jzyku programowania (np. w jzyku C++) wykonujca operacje na podanych argumentach lub na argumentach klas. Nowy obiekt mona
tworzy albo przez wykonanie operacji new, albo stosowanie obiektw prototypowych. Jeeli mamy do czynienia ze rodowiskiem mao zmieniajcym si, to do tworzenia obiektw naley wykorzysta metod new. T sam metod new mona wywoywa 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 przypadku rodowiska szybko zmieniajcego si do tworzenia obiektw naley wykorzysta 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 dziedziczenie zachowania. Przy dziedziczeniu struktury mwimy, e podklasa dziedziczy
atrybuty swojej nadklasy. Przy zaoeniu, e na przykad klasa Pracownik ma atrybuty: 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 dziedziczeniu 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 dziedziczy 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 dostarczajcych 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 rnice 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 odrni go od pozostaych obiektw istniejcych w systemie. Ma to szczeglne znaczenie podczas operacji wyszukiwania i kasowania. Dokadna identyfikacja jest korzystna, 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 odpowiedni 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 funkcjonowanie 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 charakter oglny, natomiast struktura danych obiektu i operacje na nich wykonywane maj
charakter lokalny. Pojcie enkapsulacji wywodzce si z obiektowych jzykw programowania nawizuje do abstrakcyjnych typw danych. Mona wyrni osobno
miejsce deklaracji, gdzie umieszcza si wszystkie operacje jakie mog by wykonywane na danym obiekcie, od miejsca definicji, w ktrym zawarte s wszystkie definicje danych opisujcych stan obiektu oraz definicje metod opisujcych operacje na
danych. Uytkownik ma dostp tylko do czci deklaracyjnej. W przypadku baz danych problem troch si komplikuje. Powstaje niejasno, czy dane powinny znajdowa si w czci deklaracji, przez co bd widoczne i dostpne dla uytkownika, czy
te maj zosta ukryte w czci definicyjnej. W bazach obiektowych dane s umieszczone w obiekcie. Obiekt w czci definicji ma atrybuty i metody. Zarwno dane jak
i operacje na nich zawarte s w tej samej bazie danych. Enkapsulacja gwarantuje, e
uytkownik ma dostp do danych tylko za pomoc metod. Model enkapsulacji zapewnia niezaleno logiczn danych. Mona zmieni zestaw atrybutw opisujcych dany
obiekt oraz implementacje metod, nie zmieniajc programw odwoujcych si do
tych danych, a deklaracja w tym wypadku nie ulegnie zmianie. Zachowanie penej
niewidocznoci danych nie zawsze jest korzystne. Przy zapytaniach do bazy danych
wskazany byby bezporedni dostp do atrybutw obiektu. Systemy obiektowe oferuj
taki dostp poprzez zdefiniowanie operacji czytania i modyfikacji. Tego typu rozwizanie ma dwie zalety: operacje te s napisane w sposb efektywny, a uytkownik zostaje zwolniony z obowizku pisania wielu metod czytajcych i modyfikujcych
atrybuty.

58

6.7. Utrzymanie poprawnoci bazy

Zachowanie poprawnoci danych i zalenoci miedzy nimi jest wanym problemem w przypadku rozbudowanych baz danych. Mog si pojawia dwa rodzaje nieprawidowoci: brak zgodnoci wartoci atrybutw z narzuconymi wczeniej warunkami lub niepoprawne powizania midzy atrybutami i obiektami w bazie danych.
Naley wic dy do:
zachowania poprawnoci danych jednostkowych, czyli utrzymania poprawnoci
wartoci atrybutw w obiekcie. Przykadem jest wymaganie, aby warto atrybutu
bya niepusta,
zachowania waciwych relacji midzy atrybutami, na przykad ojciec nie moe
by modszy od syna,
zachowania spjnoci zwizkw pomidzy rnymi obiektami, na przykad zapewnienie, aby przy kasowaniu obiektw nie pozostay inne ze wskazaniami na skasowany obiekt.
Utrzymanie poprawnoci bazy realizuje si poprzez definiowanie wizw integralnoci, czyli okrelenie warunkw, jakie musz spenia wartoci atrybutw wszystkich obiektw nalecych do danej klasy. Po kadej modyfikacji atrybutw obiektu
wizy s testowane. Jeli dana operacja narusza wizy, generowany jest bd, a operacja zostaje anulowana. Rwnie korzysta si tu z procedur wywoywanych zdarzeniami zachodzcymi w bazie. Takim zdarzeniem moe by usunicie, modyfikacja lub
wstawienie danych. Procedury te, okrelane jako wyzwalacze, opisano w p. 8.6.

6.8. Mechanizmy ochrony dostpu do danych

W obiektowych bazach danych podstawow jednostk ochrony jest obiekt. Budujc model ochrony trzeba pamita, aby by on spjny z modelem danych, uwzgldnia takie waciwoci baz danych, jak dziedziczenie czy istnienie obiektw kompozytowych. Mocno rozbudowany system zabezpiecze moe mie znaczny wpyw na
efektywno pracy bazy. Mechanizm ochrony dostpu dla baz mona na przykad
podzieli na: zbir obiektw O, ktrym bd przyznawane rnego typu prawa dostpu, zbir podmiotw P, ktre bd day dostpu do obiektw oraz zbir dostpw D
czytanie, kasowanie, modyfikacja. Wwczas tryb dostpu mona zdefiniowa jako
funkcj:

F (p, o, d), gdzie o O, p P, d D a f: P O D (Prawda, Fasz),

ktra przyjmuje wartoci Prawda, gdy podmiot p moe uzyska dostp d do obiektu o,
a Fasz, gdy go nie ma. Na podstawie informacji o moliwoci dostpu do jakiego
obiektu mona okreli zasady i wyprowadzi reguy dostpu do obiektw, na przy-

59

kad: Kierownik ma dostp do wszystkich danych, do ktrych ma dostp jego Podwadny (dziedzina P) lub uytkownik, ktry moe modyfikowa dany obiekt, moe go
rwnie czyta (dziedzina D).

6.9. Uwagi kocowe

Obiektowe bazy danych s potnym narzdziem w rkach programistw. W odrnieniu od relacyjnego systemu [9, 11] dostarczaj penego wsparcia dla obiektowego modelu programowania uytego w jzykach podobnych do C++ i Java. Ten model
programowania jest intuicyjny, dobry do modelowania relacji i wygodny dla duych
projektw. Obiektowa baza danych czy ze sob semantyk obiektowego jzyka programowania z zarzdzaniem danymi i zapytaniami. Pozwala to na zarzdzanie du
liczb danych i modelowanie relacji pomidzy nimi. Obecnie obiektowe techniki s
widziane jako modna forma tworzenia oprogramowania. Naley jednak zda sobie
spraw z tego, e modelowanie obiektowe jest dobr metod do tworzenia bardzo
zoonych struktur systemw programistycznych. Te same struktury, ktre nam pozwalaj wyrazi semantyk relacji pomidzy obiektami mog by uyte do tworzenia
programu o postaci modularnej, ktry jest lepszy strukturalnie i atwiejszy do zrozumienia. Obiektowe programy pozwalaj programicie czy kod z danymi w jednej
strukturze zwanej obiektem. Definicja tego obiektu nazwana jest klas. Klasy
i obiekty dla maych programw s proste i przejrzyste, ale dopiero wykorzystanie ich
w duych i zoonych projektach pozwala nam waciwie doceni podejcie obiektowe. Rwnie zarzdzanie relacjami midzy komponentami w duych zoonych systemach stanowi powany problem. Obiekty bardzo dobrze nadaj si do naturalnego
modelowania relacji, co jest wanym powodem przy wykorzystaniu ich w duych
projektach. Sia i moc obiektowych baz danych ley w tym, e obiekty cile odwzorowuj istot rozwizywanego problemu. Logiczne powizania midzy obiektami
mog by jasno zobrazowane, jeli si uyje do tego celu dziedziczenia i polimorfizmu. Obiektowa baza danych zapewnia: dugookresowe zapamitywanie, du pojemno skadowania danych, zapytania bazujce na wartociach, wspdzielenie
obiektw midzy programami, niezalene od urzdzenia formaty, precyzyjn obsug
bdw w bazie. Ponadto obiektowa baza danych pozwala na rozwizywanie problemu referencji w programie, relacji jeden do wielu, zapyta bazowanych na wartociach wraz z sortowaniem wynikw, inteligentnego zarzdzania obiektami. Bazy
obiektowe s dobrze przystosowane do wielkiej liczby danych i szybkiej realizacji
zapyta opartych na wartociach. Przykad realizacji systemu opartego na modelu
obiektowym podano w rozdz. 9 czci III.

60

7. DEDUKCYJNE BAZY DANYCH

7.1. Uwagi oglne
W dedukcyjnych bazach danych do opisu danych uywa si jzyka logiki pierwszego rzdu, natomiast operowanie na danych sprowadza si do wartociowania formu logicznych [17, 39]. Jzyki logiki charakteryzuj si zrozumia semantyk, s
narzdziami umoliwiajcymi jednorodne opisywanie faktw i regu rzdzcych modelowan rzeczywistoci, wizw integralnoci oraz zapyta kierowanych do bazy.
Teoria jzykw logiki uatwia rozwizywanie wielu problemw zwizanych z efektywnym zarzdzaniem baz. Pojedyncze reguy logiczne ze wzgldu na wysoki stopie ekspresji mog zastpi cae zbiory jawnie definiowanych faktw, co z jednej
strony upraszcza proces modelowania encji, z drugiej zwiksza czytelno i uatwia
zrozumienie wybranego sposobu opisu rzeczywistoci [31, 39]. Pierwsze badania nad
zastosowaniem logiki do systemw baz danych prowadzone byy w latach 60. W tym
samym czasie pojawiy si prace Kuhnsa (1967), Levina i Marona (1967) oraz Greena
i Raphaela (1968). We wszystkich tych pracach pokazywano moliwoci zastosowania jzyka logiki do zadawania zapyta oraz wykorzystanie zasady rezolucji [4] do
wyszukiwania informacji. Systemy te mona okreli jako typu pytanie odpowied dziaajce na niewielkiej liczbie faktw. Pierwsze prace teoretyczne na temat
ogranicze jzyka logiki do formuowania zapyta prowadzone byy przez Di Paola
w 1969. Od tego czasu rozwijane s koncepcje programowania logicznego. Obecne
prace [2, 6, 7, 8, 10] nad udoskonaleniem tego typu systemw polegaj na integracji
regu z systemami zarzdzania bazami. Prowadzone s intensywne badania, na og
w ramach duych projektw badawczych, ktrych celem jest budowa efektywnych
systemw dedukcyjnych. Naleaoby tu jeszcze powiedzie, e bdem, pomimo wielu
podobiestw, jest utosamianie baz dedukcyjnych z systemami eksperckimi [12, 30,
41]. Systemy eksperckie mog odpowiada systemom reprezentacji wiedzy, podczas
gdy systemy zarzdzania bazami wiedzy stanowi odpowiednik baz dedukcyjnych.

7.2. Model dedukcyjnej bazy danych

U podstaw kadego systemu bazy danych ley model danych, ktry jest zbiorem
pewnych abstrakcyjnych poj umoliwiajcym opis fragmentu modelowanej rzeczywistoci.

61

Dedukcyjn baz danych w postaci oglnej mona zdefiniowa jako par:

:= (K, L)
gdzie: K to skoczony zbir klauzul, L to jzyk logiki pierwszego rzdu.
Klauzula bazy danych jest to formua logiczna nastpujcej postaci:

A1 A2 A3 ..... Am L1 L2 L3 ...... Ln
gdzie: m 1, n 0, Ai jest atomem, Lj jest literaem.
Cz klauzuli wystpujca po lewej stronie zwana jest gow klauzuli, natomiast
cz wystpujca po prawej stronie ciaem klauzuli.
W zwizku z tym nasuwa si okrelenie takich poj jak regua i fakt.
Regua to klauzula z niepustym ciaem,
fakt
to klauzula pozbawiona ciaa.
W dedukcyjnej bazie danych mona wyrni:
predykaty bazowe,
predykaty wirtualne: proste i zmaterializowane,
predykaty zewntrzne.
Predykaty bazowe okrelaj fakty. Maj one znacznie szerszy zestaw typw wartoci danych prostych dla atrybutw ni jest to przyjte w bazie relacyjnej. Relacyjna
baza danych [24] stanowi szczeglny przypadek bazy dedukcyjnej jako baza zawierajca same fakty. W bazie dedukcyjnej istnieje dodatkowo moliwo definiowania
atrybutw zagregowanych. Reguy bdce wystpieniami predykatw wirtualnych
umoliwiaj wywodzenie nowych faktw (predykatw wirtualnych prostych) na podstawie istniejcych w bazie predykatw bazowych i otrzymanych w wyniku wczeniejszego zastosowania regu innych predykatw wirtualnych. W szczeglnych sytuacjach predykaty wirtualne mog by materializowane, to znaczy, e wywiedzione
z nich fakty mog zosta w sposb jawny zapamitane w bazie danych tak jakby byy
wystpieniami odpowiedniego predykatu bazowego. Materializacja predykatw
zwiksza efektywno systemu. Na og materializuje si predykaty, do ktrych czsto odwouj si zapytania. Rwnie materializuje si te, ktre wyznaczaj liczne
zbiory wirtualnych faktw, aby wielokrotnie nie stosowa tych samych regu do
otrzymania tej samej informacji. Materializacja faktw wymaga jednak stosowania
dodatkowo pewnych dynamicznie uaktualnianych mechanizmw, dla zachowania
integralnoci bazy, cznie ze zmian predykatw bazowych. Reguy maj okrelony
tzw. jzyk reguowy zawierajcy skadni i mechanizm wnioskowania. Jzyk ten wywodzi si ze sztucznej inteligencji. W zalenoci od rodzaju bazy istnieje wiele rnicych si pod wzgldem semantyki i syntaktyki jzykw.
Trzecim typem predykatw s predykaty zewntrzne zdefiniowane poza systemem. Predykaty te maj za zadanie midzy innymi:
sprawdzenie, czy midzy argumentami zachodz okrelone zwizki, np. rwnoci wikszoci itp.,

62

realizacj operacji arytmetycznych na argumentach predykatw,

konwersj typw argumentw,
wymian informacji z operatorem.
Predykaty te nie mog odwoywa si do systemu bazy danych, ani odczytywa,
ani uaktualnia danych.

7.3. Jzyki dedukcyjnych baz danych

Jzyki dedukcyjnych baz danych skadaj si z dwch komponentw: deklaratywnego i proceduralnego. Komponent deklaratywny jest odpowiednikiem opracowanego
przez firm Codasyl [18] jzyka definiowania danych (ang. Data Definition Language). Umoliwia on definiowanie regu i ogranicze integralnociowych przechowywanych w bazie. Deklaratywno jzyka polega na tym, e uytkownik nie jest
wiadom sposobu wartociowania regu i ograniczania podczas wspbienego wykonywania transakcji, jak rwnie nie ma moliwoci wymuszania okrelonej procedury
ich wartociowania. Transakcja jest logiczn jednostk pracy, mogc si skada
z jednej bd kilku elementarnych akcji, takich jak wywoanie instrukcji typu [28]
INSERT, UPDATE czy DELETE mogcych zmieni stan bazy danych. Transakcja,
jak podano w rozdziale 3, ma nastpujce wasnoci:
atomowo oznaczajc, e jest jednostk niepodzieln, to znaczy, e wszystkie
jej akcje elementarne s jednoczenie potwierdzane albo odwoywane,
trwao gwarantujc, e w przypadku pomylnego zakoczenia transakcji
wszystkie wprowadzone przez ni zmiany do bazy nie zostan pniej utracone nawet
w razie awarii systemu,
izolacj gwarantujc wykonanie transakcji w sposb bezkolizyjny,
spjno odwzorowujc taki stan bazy, w ktrym spenione s wszystkie zdefiniowane w niej wizy integralnociowe w inny rwnie spjny stan. Odwoywanie
transakcji nie powoduje utraty spjnoci bazy danych.
Komponent proceduralny jest odpowiednikiem jzyka manipulowania danymi
(ang. Data Manipulation Language). Umoliwia przygotowanie aplikacji bazy oraz
predykatw zewntrznych.
W zalenoci od rodzaju bazy istnieje wiele jzykw reguowych. Ich korzenie
wywodz si ze sztucznej inteligencji. Tradycyjne systemy dziaaj na podstawie reguy dedukcyjnej zwanej regu odrywania, ktr zapisuje si nastpujco:

( ),

Regua ta oznacza, e jeeli z przesanki wynika przesanka oraz jest prawdziwe, to przyjmujemy, e fakt jest rwnie prawdziwy. Regu mona uzna za odpowiednik reguy wnioskowania zwanej w logice arystotelesowskiej jako modus ponen-

63

do ponens. Bardzo czsto przyjmuje si, e wystpienie faktu ju wiadczy o jego

prawdziwoci. Oglnie regua ma posta: wzorzec akcja. Regua jest uaktywniana
wtedy, gdy wzorzec (warunek, predykat) odpowiada danym znajdujcym si w pamici roboczej systemu, natomiast akcja dokonuje ich modyfikacji. Reguy w systemach baz danych przyjmuj nastpujca posta:
ON zdarzenie
IF warunek
THEN akcja.
Regua uaktywniana jest tylko wtedy, gdy wystpi okrelone zdarzenie. Warunek
reguy zdefiniowany w treci reguy jest sprawdzany na podstawie danych. Jeli warunek jest speniony, to podejmowana jest okrelona akcja. Ten sposb reprezentacji
znany jest jako reguy ECA (ang. Even Condition Action). Szczegy i stopie zoonoci specyfikacji zdarze, warunkw i akcji rni si w znacznym stopniu
w poszczeglnych systemach. Niektre systemy s wyposaone w mechanizmy porzdkowania regu, ktrych celem jest okrelenie jaka regua powinna by wykonana
w sytuacji, gdy wiele regu zostao uaktywnionych. Zwizki pomidzy poszczeglnymi elementami regu wystpujce w jzykach reguowych s bardzo zrnicowane.
W wikszoci systemw reguy s uaktywniane przez operacje wprowadzania, usuwania i aktualizacji danych (INSERT, DELETE i UPDATE) zawartych w okrelonej
relacji. Do kadej wprowadzanej, usuwanej lub aktualizowanej krotki moe nastpi
odwoanie w czci warunkowej i akcji reguy. Wikszo jzykw reguowych stwarza moliwo uaktywniania regu na podstawie operacji dostpu do danych. Innym
typem uaktywniajcym reguy s zdarzenia czasowe, ktre uaktywniaj reguy
w okrelonym czasie lub przedziale czasu. We wszystkich jzykach reguowych cz
warunkowa okrela warunek lub zapytanie dotyczce informacji przechowywanej
w bazie. Warunek moe by pominity w definicji reguy. W wielu jzykach reguowych warunki mog odnosi si do modyfikowanych danych lub stanu bazy przed
modyfikacj Akcja reguy okrela operacje jakie maj by wykonane, jeli cz warunkowa reguy jest speniona. Akcje mog by sekwencjami operacji wyszukiwania
i modyfikacji danych. Akcja moe odnosi si do danych, ktrych modyfikacja spowodowaa, e regua zostaa uaktywniona. Na przykad regua:
ON APPEND TO badanie
DO DELETE badanie
WHERE badanie.nazwa = nowa_nazwa
jest uaktywniana zawsze, gdy do tabeli zawierajcej rodzaj bada dopisywane s nowe
badania. Akcja tej reguy polega na usuniciu istniejcego badania, jeli nazwa nowego badania jest taka sama.
Jednym z istotnych problemw zarzdzania reguami jest kwestia wyboru reguy
w sytuacji, gdy w wyniku wystpienia okrelonego zdarzenia zostanie uaktywnionych
wiele regu. W tym przypadku istnieje wiele strategii postpowania. Do znanych nale strategie: wieoci, blokowania, specyficznoci i przypadkowoci. Strategia wie-

64

oci polega na okreleniu reguy, ktra najpniej zostaa doczona do regu. Zadaniem strategii blokowania jest eliminacja tych regu, ktre wczeniej w procesie wnioskowania byy wykorzystane. Strategia specyficznoci opiera swoje dziaanie na
uwzgldnieniu duej liczby rnych przesanek w reguach. S preferowane reguy
majce wiksz liczb przesanek, z ktrych jest wybierana przesanka o mniejszej
liczbie zmiennych. Wszystkie te strategie speniaj w programie funkcje pewnego
rodzaju filtrw, ktre maja ograniczy liczb regu tak, aby wybra jedn. Jeli w wyniku zastosowania wymienionych strategii istnieje cigle wicej ni jedna regua do
uaktywnienia, to stosuje si strategi przypadkowoci, ktra wybiera regu w sposb
przypadkowy.

7.4. Metody wnioskowania

Jeli chodzi o techniki wnioskowania, to wyrniamy wnioskowanie progresywne,
regresywne i mieszane. Osobn grup stanowi techniki wnioskowania wykorzystujce wiedz niepewn, wrd ktrych szczeglna rol odgrywa wnioskowanie rozmyte.
Idea wnioskowania progresywnego jest niezwykle prosta. Na podstawie dostpnych regu i faktw naley generowa nowe fakty tak dugo, a wrd wygenerowanych faktw znajdzie si postawiona hipoteza. Podstawow cech tego sposobu wnioskowania jest zwikszanie si bazy faktw, co czasami staje si zjawiskiem
niepodanym. Przyspiesza to co prawda proces sprawdzania postawionej hipotezy,
jednak zajmuje niepotrzebnie pami komputera.
Algorytm wnioskowania progresywnego.
BW: Wiedza pocztkowa/Fakty
REPEAT
1. Okrel zbir C regu w bazie wiedzy BW, dla ktrych s spenione przesanki.
2. Ze zbioru C wybierz regu R na podstawie strategii sterowania wnioskowaniem.
3. BW: = Wynik uaktywnienia reguy R dziaajcy na BW plus BW.
UNTIL Osignito cel lub nie mona zastosowa wicej regu.

Ilustracj opisanego algorytmu dla bazy wiedzy zawierajcej cztery reguy oraz trzy
fakty mona znale w pracy [35].
Wnioskowanie regresywne przebiega w odwrotn stron ni wnioskowanie progresywne. Oglnie polega ono na wykazaniu prawdziwoci hipotezy gwnej na podstawie prawdziwoci przesanek. Kiedy nie wiadomo, czy jaka przesanka jest prawdziwa, wtedy traktowana jest jako nowa hipoteza i naley j wykaza. Jeli w wyniku
takiego postpowania zostanie wreszcie znaleziona regua, ktrej wszystkie przesanki
s prawdziwe, to konkluzja tej reguy jest prawdziwa. Na podstawie tej konkluzji do-

65

wodzi si nastpn regu, ktrej przesanka nie bya poprzednio znana. Postawiona
hipoteza jest prawdziwa, jeli wszystkie postawione przesanki dadz si wykaza.
Algorytm wnioskowania regresywnego.
BW: Wiedza pocztkowa/Fakty
REPEAT
1. Okrel zbir C regu w bazie wiedzy BW, ktrych konkluzje daj si s zunifikowa.
2. Ze zbioru C wybierz regu R na podstawie strategii sterowania wnioskowaniem.
3. Jeli przesanka reguy R nie znajduje si w bazie wiedzy BW, dokonaj wnioskowania regresywnego dla przesanki reguy R (aby ja udowodni).
UNTIL Hipoteza zostanie wykazana lub nie mona zastosowa wicej regu.

Ilustracj opisanego algorytmu dla bazy wiedzy mona znale w pracy [35].
Zasadnicz cech, ktra odrnia wnioskowanie regresywne od progresywnego
jest mniejsza liczba generowanych nowych faktw oraz niemono rwnoczesnego
dowodzenia kilku hipotez. Oglnie w typowych zastosowaniach wnioskowanie regresywne jest efektywniejsze, bardziej rozpowszechnione oraz czas oczekiwania na osigniecie rozwizania postawionej hipotezy jest w wielu przypadkach duo krtszy ni
przy wnioskowaniu progresywnym.
Kompromis midzy wnioskowaniem progresywnym i regresywnym stanowi wnioskowanie mieszane, dziki czemu jest pozbawione niektrych wad opisywanych metod. Strategia tego wnioskowania opiera si na wykorzystaniu oglnych regu, zwanych metareguami, stanowicych metawiedz, na podstawie ktrej program
zarzdzajcy dokonuje odpowiedniego przeczania midzy poszczeglnymi rodzajami wnioskowania. W zalenoci od sytuacji system moe automatycznie dobra odpowiedni sposb wnioskowania. Przy przechodzeniu z jednego wnioskowania na drugie za hipotez gwn zawsze wybiera si t, ktr postawi uytkownik. Dziki temu
na kadym etapie wnioskowania istnieje moliwo udzielania odpowiedzi na postawion hipotez. We wnioskowaniu mieszanym system musi mie wprowadzony
oprcz bazy wiedzy rwnie zbir zawierajcy metareguy. W dziaaniu systemu
mona wyrni jakby dwie maszyny wnioskujce: progresywn i regresywn. Wiedza zapisana w metareguach moe preferowa jeden z rodzajw wnioskowania. Na
pocztek zakada si, e priorytet ma wnioskowanie regresywne. W zwizku z tym
stosuje si go tak dugo, dopki da si wykorzysta wszystkie reguy zwizane z wybranym wnioskowaniem. Po kadym cyklu wnioskowania s sprawdzane warunki
zapisane w metareguach. Jeli nie da si dalej stosowa wnioskowania regresywnego,
to system jest przeczany na wnioskowanie progresywne. Po wyprowadzeniu kolejnych faktw sprawdza si, czy system uzyska odpowied na postawion hipotez.

66

Jeli tak, to wynik stanowi rozwizanie. W przeciwnym razie proces jest kontynuowany a do osignicia celu lub gdy zostan wyczerpane wszystkie moliwoci jego
wykazania.
Niej podamy przykad wnioskowania mieszanego.
Przykad 7.1
Baza regu podzielona jest na dwie czci zawierajce 8 regu. Cz bazy regu
zwizana z wnioskowaniem regresywnym zawiera reguy:
R1 F and H K
R2 E and A K
R3 E and B H
Cz bazy zwizana z wnioskowaniem progresywnym zawiera reguy:
R4 A and G B
R5 B and D H
R6 G and D E
R7 A and B D
R8 A and C G
Zaoono, e naley wykaza hipotez K. Prawdziwe s fakty A i C, a priorytet ma
wnioskowanie regresywne. O wyborze reguy decyduje kolejno umieszczenia na
licie. Tak wic jako pierwsza zostanie uyta regua R1, ktrej cz warunkowa zawiera dwa nieznane fakty F i H. Naley wykaza prawdziwo tych faktw. Poniewa
w konkluzji reguy R3 znajduje si fakt H, wic w drugim kroku zostanie wybrana ta
wanie regua. Poniewa w czci warunkowej tej reguy znajduj si dwa nowe fakty
E oraz B, wic do wykazania mamy w sumie trzy fakty F, E, B. Dla rozwaanej bazy
wiedzy nie mona zastosowa wicej regu przy wnioskowaniu regresywnym, wobec
czego system zostaje przeczony na wnioskowanie progresywne. Wobec znanych
faktw A i C bd kolejno uaktywniane nastpujce reguy R8, R4, R7, R6, R5, przy
czym kolejno zostan wprowadzone nowe fakty G, B, D, E, H do bazy faktw. Poniewa zostay uaktywnione wszystkie fakty, w tej czci przechodzimy do wnioskowania regresywnego. Z faktw F, E, B, ktre poprzednio przy wnioskowaniu regresywnym naleao wykaza, tylko fakt F nie zosta wykazany. Oznacza to, e
postawionej hipotezy K nie da si wyprowadzi z regu R1 i R3. Wobec tego naley
rozway inne reguy, ktrych czci warunkowe nie byy jeszcze badane. Regu tak
jest regua R2. System sprawdza, czy fakty E oraz A znajduj si w bazie, jeli tak, to
regua R2 zostanie uaktywniona i fakt K zostaje uznany za prawdziwy, co koczy
proces wnioskowania.
Mona zauway, e proces wnioskowania przeprowadzony by w 10 krokach.
Gdyby zostaa przeprowadzona analiza wnioskowania mieszanego z priorytetem pro-

67

gresywnym, proces wnioskowania trwaby 7 krokw. Nie naley jednak wyciga

wniosku, e nadanie priorytetu wnioskowaniu progresywnemu przyspiesza uzyskanie
wynikw. Oglnie o tym, ktry sposb wnioskowania jest efektywniejszy wiadczy:
struktura bazy wiedzy, kolejno umieszczania regu w bazie oraz zastosowane strategie
sterowania wnioskowaniem tworzce metawiedz o rozwizaniu danego problemu.

7.5. Podstawowe funkcje systemu zarzdzania

dedukcyjn baza danych
Wszelkie operacje prowadzone na faktach i reguach zorganizowane s w postaci
zbiorw elementarnych jednostek zwanych transakcjami. Kada transakcja musi by
wykonana w caoci lub w caoci wycofana. W przypadku pomylnego wykonania
transakcji wszystkie wprowadzone przez ni zmiany do bazy musz by zachowane.
Transakcja nie ma prawa narusza spjnoci bazy, to znaczy, e po wykonaniu transakcji musz by zachowane wszystkie wczeniej zdefiniowane wizy integralnoci.
System zarzdzania baz dedukcyjn powinien charakteryzowa si wasnociami,
ktre zapewni bezpieczny i efektywny dostp do bazy wielu uytkownikom.
W zwizku z tym musi realizowa nastpujce funkcje:
ochrony spjnoci i trwaoci danych,
zarzdzania wspbienoci transakcji,
autoryzacji dostpu do danych,
fizycznego zarzdzania danymi,
weryfikacji wizw integralnoci,
optymalizacji wykonywania operacji, a w szczeglnoci procesu wnioskowania.
Cz z tych funkcji implementowana jest ju w bazach relacyjnych, inne, jak na
przykad weryfikacja czy optymalizacja, wymagaj nowych rozwiza w stosunku do
moliwoci oferowanych przez bazy relacyjne.

7.6. Realizacja zapyta i ich optymalizacja

Poniewa wikszo ludzkiej wiedzy nagromadzona jest w postaci tekstu, wic
tekst jest najwaniejszym komponentem technologii inteligentnych baz danych. Problem polega na powizaniu wiedzy tekstu podstawowego z reprezentacj wiedzy,
ktr mona wykorzysta do wnioskowania. Chodzi tu nie tylko o natychmiastowe
wyszukiwanie informacji, ale o stworzenie procesw przeksztacajcych tekst w reprezentacj wiedzy, ktra mogaby by zrozumiaa i wykorzystywana przez systemy
wnioskujce. To wszystko wie si nierozerwalnie z technikami reprezentacji, gromadzenia, zarzdzania i dostpu do wiedzy. Najbardziej popularnymi metodami reprezentacji wiedzy i jej strukturalizacji s: sieci semantyczne, tabele decyzyjne

68

i drzewa decyzyjne [35].W dedukcyjnych bazach informacje jakie uzyskuje uytkownik s wynikiem procesw wnioskujcych. Algorytmy wartociowania zapyta kierowanych do bazy powinny charakteryzowa si: poprawnoci, kompletnoci i skoczonoci uzyskanych odpowiedzi na zadane pytania. Istnieje wiele rodzajw tego
typu algorytmw, w zalenoci od na przykad kolejnoci stosowania regu podczas
procesu wnioskowania, czy liczby faktw, ktre s pobierane z predykatw bazowych
w jednym cyklu procesu wnioskowania. Kada z grup algorytmw wymaga stosowania dodatkowych mechanizmw optymalizacji przeprowadzanych wspbienie
z sam metod. Zaproponowane metody optymalizacji mona podzieli na: syntaktyczne i semantyczne. Metody syntaktyczne opieraj si na precyzyjnej analizie postaci zapytania oraz regu wnioskowania, ktrych naley uy w celu uzyskania odpowiedzi. Przykadowo, wynikiem tej analizy moe by zmiana kolejnoci wartociowania podzapyta lub zmiana kolejnoci uycia alternatywnych regu tego samego
predykatu. Metody semantyczne opieraj si na dodatkowej wiedzy, ktra zwykle nie
jest jawnie przechowywana w bazie. Warto tu wspomnie o wizach integralnoci,
ktre w stosunku do baz relacyjnych zostay znacznie rozszerzone. W bazach dedukcyjnych wizy s definiowane za pomoc regu logicznych. Transakcja modyfikujca
fakty lub reguy dedukcyjnej bazy moe zosta zatwierdzona wycznie wtedy, gdy
w wyniku swego dziaania nie naruszya zdefiniowanych w bazie wizw. Wizy
bardzo uatwiaj precyzyjne modelowanie rzeczywistoci, mog jednak przyczyni si
do istotnego zmniejszenia efektywnoci systemu. Wynika to z koniecznoci odczytu
i udowodnienia bardzo duej liczby faktw przed podjciem decyzji o zatwierdzeniu
lub odrzuceniu transakcji. Wizy mona podzieli na natychmiastowe i opnione.
Wizy natychmiastowe musz by spenione po wykonaniu kadej elementarnej operacji transakcji. Wizy opnione musz by spenione po zakoczeniu ostatniej elementarnej operacji skadajcej si na transakcj i mog by przejciowo naruszone
w trakcie realizacji transakcji. Mona te wyrni wizy statyczne i dynamiczne.
Wizy statyczne dotycz pojedynczego stanu modelowanej rzeczywistoci. Wizy
dynamiczne ograniczaj moliwe zmiany stanw. Zarwno wizy statyczne jak i dynamiczne mog by podzielone ze wzgldu na liczb faktw, ktre musz zosta
przeanalizowane w trakcie ich weryfikacji. Wyrniamy tutaj wizy zagregowane
i niezagregowane [2, 6].

7.7. Uwagi kocowe

Budowa systemw opartych na modelu dedukcyjnym nie jest prosta i wymaga cisego wspdziaania caej grupy osb: ekspertw, inynierw wiedzy, programistw.
Dodatkowym utrudnieniem jest fakt, e ta dziedzina nie posiada wasnej metodologii.
Obecnie stosowane techniki wydaj si dostpne do prostych zastosowa, natomiast
do bardziej skomplikowanych ich budowa i wdraanie staj si trudne praktycznie na

69

kadym etapie implementacji. Do najbardziej skomplikowanych problemw, z ktrymi boryka si metodologia tworzenia systemw w dedukcyjnych bazach nale:
problem adekwatnej reprezentacji wiedzy,
rozumowanie w przypadkach wiedzy niepewnej,
problemy z gromadzeniem wiedzy,
interfejs pomidzy systemem a uytkownikiem.
Za wskie gardo przy tworzeniu systemw dedukcyjnej bazy danych uwaa si
ekstrahowanie i gromadzenie wiedzy. Ekspertyza nie zawsze jest atwo dostpna.
Rni eksperci czsto diametralnie rni si midzy sob podejciem do tego samego
problemu. Pomimo pewnego postpu, w eksperymentach z automatyzacj procesu
ekstrahowania wiedzy bezporednie jej gromadzenie nadal nie jest praktycznie moliwe. Baza wiedzy budowana jest na podstawie wiedzy pozyskanej od ekspertw przez
inyniera wiedzy. Jeeli ta wiedza okae si niepena, niepewna, zrnicowana zalenie od punktu widzenia eksperta lub nieprawidowa, to te same bdy pojawi si
w bazie wiedzy systemu. Bdy semantyczne czsto s te wynikiem przekama
spowodowanych przez inyniera wiedzy na skutek nieporozumienia lub bdnej interpretacji informacji uzyskanej od specjalisty. Bdy semantyczne i syntaktyczne mog
powsta na skutek uycia niewaciwej formy regu wnioskowania lub wybrania niewaciwej formy interpretacji wiedzy. W obecnym stadium technologia systemw
inteligentnych nie potrafi sobie jeszcze efektywnie radzi z reprezentacj wiedzy rnego typu w ramach jednego systemu. Czstym rdem bdw jest te wadliwie
zaprojektowany modu interfejsu midzy uytkownikiem a systemem, ktry czsto
dostarcza uytkownikowi niekompletnych, niejasnych lub wrcz mylnych informacji.
Obecne systemy eksperckie nie s w stanie samodzielnie weryfikowa swojej poprawnoci ani ucila bazy wiedzy. Obie te czynnoci musz by inicjowane z zewntrz
i wykonywane przez inynierw wiedzy przy wsppracy z samymi ekspertami.
Przykad systemu opartego na modelu dedukcyjnym podano w rozdz. 10 czci III.

70

PODSUMOWANIE
Cz druga zawiera opis trzech reprezentatywnych modeli danych: relacyjnego,
obiektowego i dedukcyjnego. W latach osiemdziesitych zapowiadano [4], e systemy
majce za podstaw model obiektowy znacznie si rnicy od modelu relacyjnego,
przecign na pocztku lat dziewidziesitych systemy oparte na modelu relacyjnym
danych. Obecnie mamy rok 2001, a bazy relacyjne nadal s podstaw wikszoci systemw komercyjnych. Bazy relacyjne wymagaj, aby wszystkie dane byy przedstawiane jako serie dwuwymiarowych tabel. Systemy oparte na modelu relacyjnym byy
rzeczywicie wielkim wydarzeniem w latach osiemdziesitych, lecz programici bardzo szybko przekonali si, e ycie nie jest seri dwuwymiarowych tabel. Wzrost
zoonoci wspczesnych programw i wzrost uycia dynamicznych modeli danych
ukaza ograniczenia relacyjnych baz danych. Wielu producentw systemw relacyjnych zaczyna oferowa modele obiektowe [ORACLE 8] i twierdzi, e nowe wersje
jzyka SQL maj cechy obiektowoci. Rwnie bazy dedukcyjne maj poszerzony
zakres typw atrybutw w stosunku do baz relacyjnych. Dziki wyraeniu wizw
integralnoci za pomoc regu logiki pierwszego rzdu moliwe jest bardzo precyzyjne modelowanie powiza midzy encjami i ogranicze wystpujcych w modelowanej rzeczywistoci. Nie ma ogranicze w modyfikowaniu regu i wizw integralnoci. Bazy dedukcyjne maj nowe funkcje, na przykad funkcje warunkowe, uaktualniania hipotetycznego czy te rekurencyjne predykaty, ktre istotnie zwikszaj
zakres zastosowa.

71

BIBLIOGRAFIA
[1] Bancilhon F., Delobel C., Kanellakis P., Building an Object Oriented Database System: the story
of O2, Morgan Kaufmann 1992.
[2] Bayer P., Lefebvre A., Vieille L., Architecture and Design of the EKS Deductive Database System,
VLDB Journal on Prototypes of Deductive Database Systems 1993.
[3] Bernstein P.A., Synthesizing Third Normal Form Relations for Functional Dependencies, ACM
Transactions on Database Systems 1976, Vol. 1, No. 4 s. 277298.
[4] Beynon-Davies P., Systemy baz danych, WNT, Warszawa 1998.
[5] Beynon-Davies P., Information Systems Development; an introduction to information systems engineering, Macmillan Press 1993.
[6] Beynon-DaviesP., Expert Database Systems: a gentle introduction, Maidenhead, MacGraw-Hill
1991.
[7] Beynon-Davies P., Knowlege Engineering for Information Systems Development; an introduction
to information systems engineering, Maidenhead, MacGraw-Hill 1993.
[8] Beynon-Davies P., Tudhope D., Taylor C., Jones C.B., A Semantic Data-base Approach to Knowlege
Based Hypermedia Systems, Information and Software Technology, June 1994, 36(6), s. 323329.
[9] Blaha M.R., Premerlani W.J., Rumbaught I.E., Relational Database Design Using an ObjectOriented Methodology CACM, 31(4), s. 414427.
[10] Bratko I., Prolog Programming for Artificial Intelligence, 2nd Ed. Reading, Mass. Addison-Wesley
1990.
[11] Cattell R.G.G., The Object Database Standard ODMG-93 Reease 1.1, Morgan Kaufmann 1994.
[12] Chwiakowska E., Sztuczna inteligencja w systemach ekspertowych, Zakad Nauczania Informatyki
Micom, Warszawa 1991.
[13] Codd E.F., A Relational Model for Large Shared Data Banks Communications of ACM, June 1970,
Vol. 13, No. 6, s. 377387.
[14] Codd E.F., Further Normalization of the Date Base Relational Model, Englewood Cliffs: PrenticeHall 1972, s. 3364.
[15] Codd E.F., The Relational Model for Database Management: Version 2. Reading, Mass. AddisonWesley 1990.
[16] 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.
[17] Das S.K. Deductive Databases and Logic Programming, Adison-Wesley Publishing Company
1981.
[18] DBTG: Report of the CODASYL Database Task Group, ACM, April.
[19] Date C., Introduction to Datebase Systems 5th Ed, Addison-Wesley 1990.
[20] Delobel C., Lecluse C., Richard P., Database from relational to object-oriented systems International Thompson Publishing, 1995.
[21] Delobel C., Adiba M., Relacyjne bazy danych, WNT, Warszawa 1989.
[22] Fagin R., Multi-Valued Dependencies and a New Normal Form for Relational Database, ACM
Tran. of Database Systems 1977, 2(1).
[23] Fagin R., Normal Form and Relational Database Operarators ACM SIGMOD, Int. Symposium on
the Management of Data, 1979, s. 153160.

72
[24] Gardarin G., Valduriez P., Relational Databases and Knowledge Bases, Reading Mass. Addison-Wesley 1990.
[25] Kent W., A Simple Guide to Five Normal Forms in Relational Database Theory, CACM 1983,
26(2).
[26] MacVittie D.W., MacVittie L.A., Programowanie zorientowane obiektowo, Mikom, Warszawa
1996.
[27] Martin J., Organizacja baz danych, PWN, Warszawa 1983.
[28] Miller T., Powell D., Ksiga eksperta, Helion, Gliwice 1998.
[29] Myer B., Object Oriented Software Construction, New York, Prentice-Hall 1997.
[30] Mulawka J.J., Systemy ekspertowe, WNT, Warszawa 1996.
[31] Oszu M.T., Valduriez P., Principles of Distributed Database Systems, Englewood-Cliffs, New York,
Prentice Hall 1991.
[32] Oszu M.T., Valduriez P., Distributed Database Systems: where are we now? Database Programming
and Design, March 1992.
[33] Pankowski T., Podstawy baz danych, PWN, Warszawa 1992.
[34] Prabhu C.S.R., Semantic Database Systems: a Functional introduction, London, Sangam 1992.
[35] Prace: Kumierski W., Dedukcyjna baza danych modelujca laboratorium medyczne, dyplom pod
kierunkiem M. Chaon, ICT PWr.,Wrocaw 1997.
Felu T., Mrwczyski M., Obiektowo zorientowana baza danych wspomagajca zarzdzanie, dyplom pod kierunkiem M. Chaon, ICT, PWr., Wrocaw 1999.
[36] Rissanen J., Independent Components of Relations, ACM Transactions on Database Systems 1977,
Vol. 2, No. 4, s. 317325.
[37] Rissanen J., Theory of relations for Database a Tutorial Survey, Proc. MFCS. Lecture Notes
in Computer Science, BerlinHeidelberg 1978, Vol. 64, s. 537551.
[38] Tsichritzis D.C., Lochovsky F.H., Modele danych, WNT, Warszawa 1990.
[39] Tsur S., Naqvi S., A Logical Language for Data and Knowledge Bases, Computer Science Press,
New York 1989.
[40] Teorey T.J., Database Modelling and Design: the Fundamental Principles 2nd Ed. San Mateo, Calif.
Morgan Kaufmann 1994.
[41] Winston P.H., Artificial intelligence, Reading, Mass. Addison-Wesley 1984.

73

CZ III
Stosowanie modeli danych

Jako modelu danych jest wyznaczona jedynie jego uytecznoci

przy rozwaaniu, organizacji i uyciu danych. Tak jak w wikszoci
sytuacji konkretny problem wyznacza rodki potrzebne do jego rozwizania. Poniewa rne modele danych dostarczaj rnych narzdzi do ich
modelowania, wic uyteczno modeli zaley od problemw, do ktrych
s stosowane.
D. Tsichritzis, F. Lochovsky

74

WPROWADZENIE
Jednym z istotnych zagadnie przy wyborze modelu danych, a co za tym idzie
SZBD przez projektanta, a potem przez uytkownika jest jego zoono. Uwaa si,
e im mniej zoony jest model, czyli czym wiksz prostot si charakteryzuje, tym
atwiej uytkownikowi zrozumie go i poprawnie uywa. Argument prostoty jest
czsto podnoszony przez zwolennikw relacyjnych baz danych. Mona wyrni dwa
rodzaje zoonoci: zoono struktury i zoono wizw. W obu przypadkach relacyjne modele danych s mniej zoone ni obiektowe czy dedukcyjne. Jednake brak
zoonoci moe by wad wtedy, gdy brakuje mechanizmw wspomagajcych uytkownika w interpretacji danych. Innym zagadnieniem przy wyborze modelu danych
jest dopasowanie struktury danych do moliwoci ich modelowania. Jeeli dane s
w sposb naturalny hierarchiczne, to trudno jest przedstawi je w postaci tabeli dwuwymiarowej. Na wybr modelu danych do konkretnej aplikacji moe mie wpyw
rodzaj jzyka manipulacji danych. Dy si do stworzenia jednego uniwersalnego
jzyka, jak np. SQL, z moliwoci jego modyfikowania w zalenoci od potrzeb modelu. Ciekawym zagadnieniem jest wybr midzy jzykiem naturalnym a sztucznym.
Badania wykazay [4, 5, 19], e uytkownik korzystajcy z jzyka naturalnego czsto
formuuje nieracjonalne dania do bazy ze wzgldu na zbyt du swobod przy zadawaniu pyta. Jzyki sztuczne zazwyczaj narzucaj uytkownikowi sposb zadawania pyta.
Na podstawie omwionych kryteriw mona wybra odpowiednie modele danych
dla kadej modelowanej dziedziny. W rozdziaach smym, dziewitym i dziesitym
podano przykady konkretnych systemw zbudowanych na modelach relacyjnym,
obiektowym i dedukcyjnym.

75

8. NIEPROCEDURALNY JZYK
CZWARTEJ GENERACJI
8.1. Uwagi oglne
Jzyki suce do wyszukiwania danych dzielimy na: proceduralne i nieproceduralne. W jzykach proceduralnych uytkownik opisuje procedur wyszukiwania
i uzyskiwania danych na pewnym poziomie szczegowoci. Wyrniamy wyszukiwanie jednostkowe, ktrego przykadem moe by sieciowa baza danych, oraz wyszukiwanie grupowe, ktrego przykadem jest definicja cigu operacji algebry relacji.
W jzykach nieproceduralnych uytkownik podaje warunki, jakie powinien spenia
dany przez niego wynikowy zbir danych. Wyraenia nieproceduralne musz by
przetumaczone w systemie na cig wyrae jzyka proceduralnego. W podejciu
nieproceduralnym wykorzystuje si jeden z jzykw rachunku relacji: rachunek krotek
lub rachunek domen. Relacyjny rachunek na krotkach sta si podstaw jzyka SQL
[7], natomiast relacyjny rachunek na domenach podstaw interfejsw QBE (zapytanie
przez przykad). Pierwowzorem SQL by jzyk SEQUEL [5, 6, 15, 19, 21]. Definicja
skadni standardu jzyka relacyjnych baz danych SQL po raz pierwszy zostaa opublikowana w 1986 roku w oparciu o dwa dialekty SQL IBM i Oracle [8]. Jej ulepszona
wersja SQL1 powstaa rok pniej. W 1989 roku [9] opublikowano wersj SQL89
zawierajc gwnie popraw integralnoci bazy. Dopiero w 1992 wydano pen specyfikacj rozszerzonej wersji pod nazw SQL2 [10]. Ta rnorodno wersji sprawia,
e nie ma jednolitego standardu SQL, jest wiele dialektw tego jzyka. Ponadto stale
powstaj nowe wersje SQL.
Instrukcje jzyka SQL dzieli si z reguy na cztery grupy zwane rwnie jzykami.
S to:
instrukcje definiowania danych,
instrukcje manipulowania danymi,
zapytania,
instrukcje zarzdzania danymi.

8.2. Instrukcje definiowania danych

Instrukcje te su do tworzenia, modyfikowania i usuwania obiektw tworzcych
baz danych. Obiektami tymi s tabele, perspektywy, synonimy, indeksy, schematy,
katalogi. W skad jzyka wchodz midzy innymi takie instrukcje, jak: CREATE

76

obiekt powodujca utworzenie obiektu danego typu, ALTER obiekt wykorzystywana

do modyfikowania tablic, DROP obiekt suca do usuwania z bazy obiektu okrelonego typu. Ponadto rwnie integralno danych wczona jest do instrukcji definiowania danych. Ze wzgldu na du wag problemu oraz rodzaj komend, ktrych uywa si przy okrelaniu rnych typw integralnoci zagadnienie to zostanie omwione
w osobnym rozdziale.
Aby utworzy obiekt, na przykad tabel, uytkownik okrela nastpujce skadniki:
nazw tabeli,
nazw kadej kolumny w tabeli,
typ danych,
szeroko kadej kolumny,
opcjonalny parametr (NULL).
Typy danych okrelaj pewne waciwoci dotyczce dopuszczalnych wartoci danych w kolumnie. Kada warto w kolumnie musi by tego samego typu. Standard
SQL [10] (ISO 1992) definiuje okoo 15 typw danych podzielonych na grupy: typy
napisowe, typy liczbowe, typy daty i godziny, przedziay midzy datami itp. Jako
parametr opcjonalny stosuje si sowo kluczowe NOT NULL okrelajce, e podczas
wprowadzania nowego rekordu do tablicy warto pola odpowiadajcego kolumnie
zadeklarowanej jako NOT NULL musi by ustalona lub sowo NULL, gdy warto ta
moe by nieustalona. Jeeli parametr opcjonalny nie jest okrelony, to przyjmuje si,
e kolumna jest typu NULL. Kada kolumna moe by rwnie zdefiniowana jako
UNIQUE, czyli jednoznaczna. Klauzula ta zabrania wprowadzania do kolumn powtarzajcych si wartoci. Kombinacj NOT NULL i UNIQUE mona uy do
zdefiniowania cech klucza gwnego.
Przykad 8.1
Tworzymy tabel o nazwie Pracownicy, ktra ma cztery kolumny a kluczem
gwnym jest NrPrac.
CREATE TABLE Pracownicy;
(NrPrac Number (5);
NazwiskoPrac Varchar (15);
NazwaWydziau Varchar (20);
Pensja Decimal (7,2);
PRIMARY KEY (NrPrac))
Przykad 8.2
Dla tabeli z poprzedniego przykadu zdefiniowano cechy klucza gwnego.
CREATE TABLE Pracownicy;
(NrPrac Number (5) NOT NULL UNIQUE;
NazwiskoPrac Varchar (15);

77

NazwaWydziau Varchar (20);

Pensja Decimal (7,2);
PRIMARY KEY (NrPrac))
Do definicji kolumny moemy doda klauzul DEFAULT <warto> okrelajc
warto, ktr system automatycznie wpisuje do kolumny w przypadku jeli uytkownik wprowadzi niepen informacj.
Przykad 8.3
Do kolumny NrWydziau w tabeli dodajemy specyfikacj DEFAULT4, wskazujc, e domylnym numerem Wydziau jest 4.
CREATE TABLE Pracownicy;
(NrPrac Number (5) NOT NULL UNIQUE;
NazwiskoPrac Varchar (15);
NazwaWydziau Varchar (20);
NrWydziau Smallint DEFAULT 4;
Pensja Decimal (7,2);
PRIMARY KEY (NrPrac))
Uywajc komendy CREATE tworzymy rwnie perspektywy. Perspektywa jest logiczn struktur, umoliwiajc dostp do podzbioru kolumn i wierszy danej tabeli lub
grupy tabel. Tworzona jest ze wzgldw bezpieczestwa i dla wygody. Jej organizacja
jest taka sama jak tabeli, nie ma jednak wasnych danych, a wic nie zajmuje dodatkowej pamici. Pozwala na utajnianie pewnych danych zawartych w tabelach
i upraszcza w wielu przypadkach posta zapytania kierowanego do bazy.
Przykad 8.4
Tworzymy perspektyw Dochody z tabeli Pracownicy.
CREATE VIEW Dochody;
AS
SELECT NrPrac, NazwiskoPrac, Pensja;
FROM Pracownicy
Czasami z pewnych wzgldw nazwa tabeli czy perspektywy jest niewygodna w uyciu, np. zbyt duga, wtedy mona utworzy synonim, a nastpnie uy go zamiast nazwy tabeli czy perspektywy.
Przykad 8.5
Tworzenie synonimu PU dla tabeli Pracownicy Uczelni.

78

CREATE SYNONIM PU;

FOR Pracownicy Uczelni
Aby przyspieszy wykonywanie zapyta dotyczcych tabel zawierajcych setki rekordw, tworzymy na podzbiorze ich kolumn indeksy.
Przykad 8.6
Tworzymy zbir indeksowy WP.
CREATE INDEX Ind WP;
On Warunki Pracy
Jeeli grupa kolumn ma tworzy klucz gwny tabeli, to znaczy, e w tabeli moe by
dokadnie jeden rekord o tej samej kombinacji wartoci pl odpowiadajcych kolumnom klucza gwnego. Przy tworzeniu indeksu naley wykorzysta sowo kluczowe
UNIQUE np. CREATE UNIQUE INDEX.
Za pomoc instrukcji CREATE mog by tworzone schematy. Schemat jest nadrzdny w stosunku do tabel i perspektyw, ktre stanowi jego czci. Nazwa tabeli musi
by jednoznaczna w danym schemacie, ale ta sama nazwa moe wystpi w wielu
schematach. Aby nie byo konfliktw z nazwami, trzeba kwalifikowa nazw schematu lub jawnie poprzedza nazw tabeli nazw schematu.

Przykad 8.7
Tworzenie schematu Uczelnia.
CREATE SCHEMAT Uczelnia;
CREATE TABLE Pracownicy
Zmiana schematu moe odbywa si za pomoc instrukcji SET SCHEMAT. Pojciem szerszym od schematu jest katalog. Katalog jest nazwan grup schematw. Instrukcja tworzenia katalogu zalena jest od implementacji. Nazwy schematw w katalogu musz by jednoznaczne.
Kolejna instrukcja CREATE DOMAIN suy do definicji dziedziny, czyli zbioru poprawnych wartoci. Dziedzina jest okrelona w schemacie i jest identyfikowana przez
swoja nazw. Gwnym celem uycia dziedziny jest ograniczenie zbioru poprawnych
wartoci, ktre mog by przechowywane w kolumnie.
Przykad 8.8
Definicja dziedziny, ktra okrela typ danych i klauzul wartoci domylnej.

79

CREATE DOMAIN NrSprz;

AS INTEGER;
DEFAULT 9999;
CHECK (VALUE > 1000)
Niezalenie od jakiejkolwiek tabeli lub dziedziny mog by tworzone i nazwane wizy zwane asercjami.
Przykad 8.9
Tworzenie wizw.
CREATE ASSERTION NrPracCheck;
CHECK (NrPrac BETWEEN 100 AND 10999)
Sprawdzanie tych wizw odbywa si niezalenie od jakiejkolwiek tabeli i moe by
wykonywane z opnieniem (DEFERRABLE) lub natychmiast (NOT DEFERRABLE).
Pocztkowy sposb sprawdzania wizw moe by okrelany jako INITIALLY
DEFERRED lub INITIALLY IMMEDIATE. Za pomoc instrukcji SET CONSTRAINTS,
ktra okrela, czy dla listy nazwanych wizw naley wykona sprawdzanie opnione czy natychmiastowe, mona zmieni w czasie sesji tryb sprawdzania.
Obiekty utworzone za pomoc instrukcji CREATE mona usuwa z bazy, stosujc
instrukcj DROP o skadni DROP typ obiektu, nazwa obiektu, gdzie typem obiektu
jest odpowiednio tabela, perspektywa, synonim czy indeks.
Przykad 8.10
Usuwanie tabeli Pracownicy.
DROP TABLE Pracownicy
Istnieje rwnie moliwo modyfikacji struktury bazy danych, to znaczy zmiana
definicji kolumn istniejcych w bazie, dodanie lub usunicie kolumny w bazie poprzez
uycie polecenia ALTER.
Przykad 8.11
Dodanie kolumny w tabeli.
ALTER TABLE Pracownicy;
ADD COLUMN Nazwisko_profesora
Definicj kolumny zmienia si wprowadzajc do instrukcji ALTER TABLE zdanie
MODIFY.

80

Przykad 8.12
Jeli kolumna NrPrac ma peni funkcj klucza gwnego tabeli Pracownicy, to
wartoci pl odpowiadajce tej kolumnie musz by okrelone.
ALTER TABLE Pracownicy;
MODIFY (NrPrac NUMER (5) NOT NULL)

8.3. Instrukcje manipulowania danymi

Instrukcje jzyka manipulowania danymi su do wprowadzania nowych rekordw do tabel, do modyfikowania zawartoci jednego lub wikszej liczby wierszy tabeli oraz do ich usuwania z tabeli. Przez te polecenia reprezentowana jest dynamika
bazy. Najprostsz postaci instrukcji INSERT jest:
INSERT INTO nazwa tabeli;
VALUES (lista wartoci pl)
Instrukcja o takiej skadni suy do wprowadzania wartoci do wszystkich pl rekordu.
Oczywicie wartoci poszczeglnych pl musz by uszeregowane w takim porzdku,
jak zadeklarowane s pola przy tworzeniu tabeli.
Przykad 8.13
Jeli chcemy wpisa wartoci w jakim innym porzdku, to naley to zaznaczy:
INSERT INTO Pracownicy;
VALUES (167,Kowalski,Elektronika 2000)
lub
INSERT INTO Pracownicy;
VALUES (111,Ryt,Informatyka, 2100)
Specjalna wersja polecenia INSERT umoliwia dodanie wielu wierszy do tabeli.
Zwykle jest uywana, aby umieci wyniki jakiego zapytania w podanej tabeli.
Przykad 8.14
Jeli chcemy umieci tabel Pracownikw pracujcych na wydziale Elektroniki,
to robimy to uywajc instrukcji SELECT.
CREATE TABLE Pracownicy Elektroniki;
(NrPrac Number (5);
NazwiskoPrac Varchar (15);
Pensja Decimal (7,2));

81

INSERT INTO Pracownicy Elektroniki (NrPrac, NazwiskoPrac, Pensja);

SELECT NrPrac, NazwiskoPrac, Pensja;
FROM Pracownicy;
WHERE NazwaWydziau = Elektronika
Zmian wartoci pl jednego lub wielu wierszy tabeli mona zrealizowa uywajc
instrukcji UPDATE. Skadnia tej instrukcji jest nastpujca:
UPDATE
SET
WHERE

nazwa tabeli
zmiany do wykonania w klauzuli SET
warunek dla ktrego s zmiany

Przykad 8.15
Zmiana wartoci pola tabeli Pracownicy.
UPDATE Pracownicy;
SET Pensja = Pensja + 2000;
WHERE DataZatrudnienia < 01.01.1996
Wiersze z tabeli usuwa si za pomoc instrukcji DELETE o postaci:
DELETE FROM nazwa tabeli
WHERE wyraenie logiczne

Przykad 8.16
Usuwanie wierszy z tabeli.
DELETE FROM Pracownicy;
WHERE NazwaWydziau = Elektronika
Jeli nieokrelony jest warunek WHERE, to wszystkie rekordy z tabeli s usuwane.

8.4. Zapytania
Zapytania su do uzyskiwania informacji z tabel tworzcych baz. Wszystkie zapytania zaczynaj si sowem kluczowym SELECT. Sowo to stanowi poczenie operatorw projekcji, konkatenacji i selekcji. Do prostego wyszukiwania uywa si kombinacji
klauzul SELECT FROM WHERE. Kombinacja ta zwana jest blokiem kwalifikacyjnym.
SELECT
FROM
WHERE

atrybuty
nazwa tabeli
warunki

82

W celu zilustrowania zapyta wykorzystano konkretn baz danych, ktrej aplikacja

znajduje si w opisie systemu FoxPro [12].
Przykad 8.17
Dany jest diagram bazy danych pokazany na rys. 8.1 [12]. Baza skada si z szeciu zbiorw: Klient (Customer), Faktury (Invoices), Detal (Detail), Biura (Offices),
Sprzedawca (Salesman), Czci (Parts) okrelonych poprzez swoje atrybuty:
Customer = {cno, company, contact, address, city, state, zip, phone, ono, ytdpurch,
lat, long},
Invoices = {ino, cno, idate, itotal, salesman},
Detail = {ino, line, qty, pno, price, ltotal},
Offices = {ono, itdsales, zmin, zmax, address, city, state, zip, phone},
Salesman = {salesman, ono, name, ytdsales, address, city, state, zip, phone, notes},
Parts = {pno, descript, onhand, onorder, price, cost, ytdunits, ytdsales}.
Wylistuj nazwy wszystkich spek ze zbioru Klienci, ktre w swojej nazwie zawieraj
sowo Computer.
SELECT company;
FROM Customer;
WHERE company LIKE %Computer%
Operator LIKE ma zastosowanie w sytuacjach, gdy uytkownik chce wyznaczy te
rekordy, w ktrych warto okrelonego pola tekstowego spenia pewien wzr, na
przykad zaczyna si od okrelonej litery. Do definiowania wzorw wykorzystuje si
specjalnie przydzielony znak, na przykad %. To samo zadanie mona rozwiza na
dwa rne sposoby:
SELECT company;
FROM Customer;
WHERE Computer & company
albo
SELECT company;
FROM Customer;
WHERE AT (Computer, company) > 0
Operator BETWEEN i AND umoliwia wyznaczenie wszystkich wierszy w tabeli, dla
ktrych warto okrelonego pola naley do pewnego przedziau.

83

Klient (Customer)

Faktury (Invoices)

Sprzedawca (Salesman)

Detal (Detail)

Biura (Offices)
Czci (Parts)

Rys. 8.1. Diagram przykadowej bazy danych

Przykad 8.18
Ze zbioru Detale wybierz wszystkie detale, ktrych cena zawarta jest w okrelonym przedziale cenowym.
SELECT Ino, price;
FROM Detail;
WHERE price BETWEEN 3000 AND 4000
Za pomoc operatora IN wyznacza si wszystkie rekordy, dla ktrych warto pewnego pola naley do okrelonego zbioru.
Przykad 8.19
Ze zbioru Sprzedawca wybierz wszystkich sprzedawcw zamieszkaych we Wrocawiu lub Warszawie.
SELECT name, city;
FROM Salesman;
WHERE city IN (Wroclaw,Warszawa)
Poniewa relacja nie ma jawnego uporzdkowania wierszy, mona to zrobi stosujc
przetwarzanie relacji. Aby uzyska posortowan wyjciow list, do instrukcji
SELECT dodajemy klauzul ORDER BY z odpowiednim sowem kluczowym (porzdek malejcy lub rosncy). W celu podsumowania wartoci w tabeli uywamy
klauzuli GROUP BY. Klauzula GROUP BY moe mie swoj wasn klauzul ograniczajc HAVING.

84

Przykad 8.20
Wylistuj oddziay firmy oraz sumaryczn warto sprzeday kadego oddziau.
Uporzdkuj wydruk wedug wartoci sprzeday od najwikszego do najmniejszego.
SELECT Offices.city, SUM (Invoices.itotal);
FROM Offices, Invoices, Salesman;
WHERE Invoices.salesman = Salesman.salesman;
AND Salesman.ono = Offices.ono;
GRUP BY Offices.ono;
ORDER BY 2 DESCENDING
W przykadzie tym operacja SELECT dziaajca na trzech powizanych przez wsplne kolumny tabelach (zaznaczono to w warunku WHERE) pozwala wybra, podsumowa i uporzdkowa w porzdku malejcym informacje. Inny przykad pokazuje
dziaanie klauzuli ograniczajcej HAVING.
Przykad 8.21
Wybierz te czci, dla ktrych suma wartoci atrybutu qty jest wiksza od 50.
SELECT Detail.pno, Parts.descript, SUM(qty), SUM (qty*Detail.price);
FROM Detail, Parts;
WHERE Detail.pno = Parts.pno;
GROUP BY Detail.pno;
HAVING SUM (qty) > 50
W tym przykadzie czymy dwie tabele, w warunku podajemy nazwy kolumn, wedug ktrych nastpio poczenie oraz listujemy wartoci kolumn wybranych w instrukcji SELECT zgodnie z klauzul ograniczajc HAVING.
Przykad 8.22
Wylistuj stany pooone midzy 40 a 45 stopniem szerokoci geograficznej, w ktrych mieszkaj klienci danej firmy.
SELECT state;
FROM Customer;
GROUP BY state;
HAVING 40 <= min (lat) AND max (lat) <= 45
To samo zadanie mona wykona inaczej, korzystajc z moliwoci zagniedania
zapyta w instrukcjach SELECT.

85

SELECT DISTINCT state;

FROM Customer;
WHERE state NOT IN;
(SELECT state;
FROM Customer;
WHERE lat < 40 OR lat > 45)
Taki typ zapyta wprowadza redundancje informacji. SQL realizuje najpierw zapytanie umieszczone w nawiasach, tzw. podzapytanie. Uzyskany wynik jest porwnywany
z wynikiem zwracanym przez zewntrzne zapytanie. Podzapytanie jest instrukcj
SELECT zawart w zdaniu wchodzcym w skad innej instrukcji SELECT.
Przykad 8.23
Znajd klienta, ktry dokona najwikszego zakupu. Podaj nazw firmy, nazwisko
sprzedawcy oraz warto zakupu.
SELECT Salesman.name, Customer.company, Invoices.ino, Invoices.idate, Invoices.
itotal;
FROM Salesman, Invoices, Customer;
WHERE Salesman.salesman = Invoices.salesman;
AND Invoices.cno = Customer.cno;
AND Invoices.itotal = (SELECT MAX(itotal) FROM Invoices)
Inne przykady zawierajce zagniedon instrukcj SELECT:
Przykad 8.24
Wylistuj stany, w ktrych klienci nie dokonali adnych zakupw.
SELECT DISTINCT state FROM Customer;
WHERE state NOT IN;
(SELECT Customer.state;
FROM Customer, Invoices;
WHERE Invoices.cno = Customer.cno)
Przykad 8.25
Podaj osob, ktra wicej zarabia ni pracownik o nazwisku Jazz.
SELECT NrPrac, NazwiskoPrac;
FROM Pracownicy;
WHERE Pensja >;
(SELECT Pensja;

86

FROM Pracownicy;
WHERE NazwiskoPrac = Jazz)
Wykonanie podzapytania moe by powtarzane. Wtedy nazywa si ono podzapytaniem skorelowanym. W takim wypadku otrzymujemy cig wartoci do porwnywania
z wynikami najbardziej zewntrznego zapytania. Konieczne jest istnienie kopii waciwej tabeli.
Przykad 8.26
W przykadzie tym mamy wypisa nazwiska wszystkich pracownikw, ich pensje
i nazwy wydziaw dla tych pracownikw, ktrzy zarabiaj wicej ni wynosi rednia
pensja pracownika ich wydziau.
SELECT NazwiskoPrac, NazwaWydziau, Pensja;
FROM Pracownicy L;
WHERE Pensja >;
(SELECT AVG (Pensja);
FROM Pracownicy;
WHERE L NazwaWydziau = NazwaWydziau)
Tworzymy kopi tabeli Pracownicy o nazwie Pracownicy L. Jedna tabela suy do
policzenia redniej pensji (funkcja AVG), druga jest podstaw do porwnania wykonanego dla kadego pracownika. Moemy zatem nadawa nazw alternatywn, zwan
aliasem, kolumnie lub tabeli w ramach kontekstu zapytania. Podobne zadanie z zastosowaniem dwukrotnym tej samej tablicy Sprzedawca podano niej.
Przykad 8.27
Porwnaj rednie roczne zarobki Sprzedawcw.
SELECT a.salesman, a.name, a.ytdsales, AVG (b.ytdsales);
FROM Salesman a, Salesman b;
WHERE a.ytdsales < b.ytdsales;
GROUP BY a.salesman
Tworzenie kopii jest rwnoznaczne z czeniem tablicy samej ze sob. Trzeba to robi
bardzo ostronie przede wszystkim w przypadku czenia tablic o duej liczbie wierszy, jak rwnie wtedy, gdy w wyniku chcemy uzyska pewne kombinacje danych,
jak pokazano to w podanym dalej przykadzie.

87

Przykad 8.28
Ze zbioru Czci mamy wylistowa pary: numer czci i jej opis, ktre zafakturowano temu samemu klientowi. Poniewa nie istnieje w bazie bezporednie powizanie
pomidzy zbiorami Faktury i Czci, aby uzyska potrzebne informacje naley wzi
pod uwag zbir Detale, co zaznaczone jest powizaniem w warunku WHERE.
SELECT a1.pno, a1.descript, a2.pno, a2.descript;
FROM Parts.a1, Parts.a2, Invioces.b1, Invoices.b2, Detail.c1, Detail.c2;
WHERE b1.ino = c1.ino AND c1.pno = a1.pno;
AND b2.ino = c2.ino AND c2.pno = a2.pno;
AND b1.cno = b2.cno;
AND a1.pno < a2.pno
Warunek umieszczony w ostatniej linijce przykadu zabezpiecza przed uzyskaniem
kadej pary z tabeli gwnej i jej kopii dwukrotnie.
Istnieje moliwo poczenia wynikw dwch zgodnych zapyta poprzez uycie
operatora sumy UNION, ktry odpowiada operatorowi sumy algebry relacyjnej.
Przykad 8.29
Wybierz wszystkich klientw zamieszkaych we Wrocawiu i w Poznaniu.
SELECT Cno, Campany;
FROM Customer;
WHERE City=Wrocaw;
UNION;
SELECT Cno, Campany;
FROM Customer;
WHERE City=Pozna

8.5. Instrukcje zarzdzania danymi

Komendy jzyka zarzdzania danymi s wykorzystywane do zapewnienia kontroli
danych i funkcji SZBD. Kontrola ta jest czynnoci, ktra wie si z przyznawaniem
praw dostpu do danych i do narzdzi operowania danymi. Jedn z metod kontroli
danych jest okrelenie praw dostpu przy uyciu perspektywy. Tworzenie perspektywy, ktra jest tabel wirtualn, polega na wybraniu tylko niektrych informacji
z jednej lub wielu tabel.
Przykad 8.30
Tworzymy perspektyw S1 z tabeli Wykadowcy.

88

CREATE VIEW S1 AS;

SELECT NazwiskoStud, Pe, KodKursu;
FROM Wykadowcy
Jeli komenda SELECT ma posta SELECT*, to oznacza to, e z tabeli o nazwie
Wykadowcy wybieramy wszystkie kolumny.
Do przekazywania uprawnie dostpu suy instrukcja GRANT o postaci:
GRANT typ uprawnienia
ON nazwa tabeli, perspektywy
TO nazwa uytkownika
Typ uprawnienia dotyczy rodzaju operacji wykonywanych na danej tabeli. Na przykad uytkownik ma prawo wykonywa jedn z operacji: INSERT, UPDATE,
DELETE, SELECT lub wszystkie, wwczas tryb uprawnienia ALL.
Przekazane uprawnienia mona odwoa instrukcj REVOKE.
REVOKE typ uprawnienia
ON nazwa tabeli, perspektywy
TO nazwa uytkownika
Przykad 8.31
Chcemy da panu o nazwisku A. Nowak prawo ogldania i modyfikowania rekordw Pracownikw na wydziale Elektronika, jednoczenie nie dajc mu praw usuwania
czy wstawiania rekordw.
CREATE VIEW Nowak AS;
SELECT*;
FROM Pracownicy;
WHERE NazwaWydziau =;
(SELECT NazwaWydziau;
FROM Pracownicy;
WHERE NazwiskoPrac = Nowak A)
GRANT SELECT, UPDATE
ON Nowak
TO Anowak
Przykad 8.32
Aby sam nie mg zmienia swojej pensji, modyfikujemy perspektyw.
CREATE VIEW Nowak AS;
SELECT*;
FROM Pracownicy;

89

WHERE NazwaWydziau =;
(SELECT NazwaWydziau;
FROM Pracownicy;
WHERE NazwiskoPrac = Nowak A;
AND NazwiskoPrac <> Nowak A)
Jeeli uytkownikowi przekae si okrelone uprawnienia do danego obiektu, to
otrzymuje on dostp do tego obiektu jedynie w ramach tych uprawnie. Istniej rwnie klasy uytkownikw. Uytkownik nalecy do klasy CONNECT moe oglda
dane innych uytkownikw, moe wykonywa zadania operowania danymi i tworzy
perspektywy. Uprawnienia RESOURCE umoliwiaj uytkownikowi tworzenie indeksw i tabel baz danych oraz przyznawanie praw dostpu do tych tabel i indeksw
innym uytkownikom. Uprawnienia administratora bazy dostaj tylko niektrzy uytkownicy.
Przykad 8.33
Nowy uytkownik Nowak majcy haso hallo ma okrelone uprawnienia:
GRANT CONNECT, RESOURCE;
TO Nowak;
IDENTIFIED BY hallo
lub odwoane:
REVOKE CONNECT;
FROM Nowak

8.6. Integralno bazy danych

Gwn cech nowoczesnych systemw informacyjnych jest proces zapewnienia
integralnoci [3]. Integralno mwi nam o tym, czy zawarto bazy danych odzwierciedla opisywan rzeczywisto, a wic czy dany stan bazy jest dopuszczalny, czy nie.
Integralno jest zwizana z procesem zmian zachodzcych w bazie spowodowanych
zarwno przez zdarzenia zewntrzne jak i wewntrzne. Zdarzenia, ktre wywouj
zmian stanu s w terminologii baz danych nazwane transakcjami. Transakcja powoduje przejcie jednego stanu w drugi. Nowy stan jest wprowadzony przez stwierdzenie
faktw, ktre staj si prawdziwe lub zaprzeczenie tych, ktre przestaj by prawdziwe. Integralno jest realizowana przez tak zwane logiczne ograniczenia zwane wizami. Definicja wizw moe by wyraona w sposb statyczny, czyli sprawdza si,
czy wykonana transakcja nie zmienia stanu bazy w stan niepoprawny lub w sposb
dynamiczny, czyli mamy do czynienia z wizami przej. Wizy przej s ograniczeniami naoonymi na przejcia bazy z jednego stanu w drugi. Mona wyrni integralno: encji, referencyjn, dziedziny.

90

Integralno encji realizowana jest przez dodanie specyfikacji klucza gwnego. Jest to
regua, ktra mwi, e kada tabela musi mie klucz gwny i e kolumna lub kolumny
wybrane jako klucz gwny powinny by jednoznaczne i nie zawiera wartoci NULL.
Bezporedni konsekwencj tej reguy jest to, e nie mog powtarza si wiersze.
Przykad 8.34
Dodanie klucza gwnego do definicji tabeli.
CREATE TABLE Pracownicy;
(NrPrac Number (5), NOT NULL UNIQUE;
NazwiskoPrac Varchar(15);
Status Varchar (15);
NazwaWydziau Varchar (20);
Pensja Decimal (7,2);
PRIMARY KEY (NrPrac))
CREATE TABLE Jednostki;
(NazwaJednostki Char (15) NOT NULL UNIQUE;
Poziom Smallint;
KodKursu Char (3);
NrPrac Number (5);
PRIMARY KEY (NazwaJednostki))
Integralno referencyjn definiujemy przez specyfikacj klucza obcego. Regua ta
mwi, e kada warto klucza obcego moe znajdowa si w jednym z dwch stanw. Normalnie warto klucza obcego odwouje si do wartoci klucza gwnego
tabeli w bazie danych lub ma warto NULL (czyli adnych powiza). Utrzymanie
integralnoci referencyjnej nie ogranicza si do okrelania wartoci NULL. Obejmuje
rwnie okrelenie wizw propagacji. Wizy te okrelaj, co powinno si sta
z powizan tabel, gdy modyfikujemy wiersz lub wiersze w tabeli docelowej. Moemy wyrni podejcie ostrone, ufne i wywaone. W pierwszym przypadku,
ostronego usuwania, (RESTRICTED) zabraniamy usuwa wiersz z tabeli gwnej
(np. Pracownicy), dopki nie bd usunite wszystkie wiersze tabeli podrzdnej (np.
Jednostki). W przypadku drugim, ufnym, istnieje usuwanie kaskadowe (CASCADES),
czyli usuwanie wszystkich wierszy powizanych z gwnym (Pracownicy). W przypadku
trzecim, wywaonym (NULLIFILES), kiedy usuwamy wiersz gwny (Pracownicy), do
tablicy Jednostki wstawiamy NULL.
Przykad 8.35
Integralno referencyjna dla tabeli Jednostki:

91

CREATE TABLE Jednostki;

(NazwaJednostki Char (15);
Poziom Smallint;
KodKursu Char (3);
NrPrac Number (5);
PRIMARY KEY (NazwaJednostki);
FOREIGN KEY (NrPrac IDENTIFIES Pracownicy);
ON DELETE SET NULL;
ON UPDATE CASCADE)
Tabela Jednostki moe mie te tak posta:
CREATE TABLE Jednostki;
(NazwaJednostki Char (15);
Poziom Smallint;
KodKursu Char (3);
NrPrac Number (5);
PRIMARY KEY (NazwaJednostki);
FOREIGN KEY (NrPrac IDENTIFIES Pracownicy);
DELETE RESTRICTED;
ON UPDATE CASCADE)
CREATE TABLE Pracownicy;
(NrPrac Number (5);
NazwiskoPrac Varchar (15);
Status Varchar (15);
NazwaWydziau Varchar (20);
Pensja Decimal (7,2);
PRIMARY KEY (NrPrac))
NrPrac ma by ustawiony na NULL, jeeli powizany rekord Pracownicy jest usuwany. Jeli dokonamy jakiejkolwiek zmiany w NrPrac w rekordzie Pracownicy, to zmiana ta powinna zosta odzwierciedlona w powizanych rekordach Jednostki.
Specjalnym rodzajem procedur zapewniajcym integralno referencji przez
sprawdzenie relacji logicznych midzy tabelami s wyzwalacze. Gwn zalet wyzwalaczy jest moliwo ich automatycznego wywoywania. Wyzwalacze uruchamiane s niezalenie od tego, czy akcja zostaa wywoana przez aplikacj klienta, czy
modyfikacja danych zostaa wymuszona przez serwer bazy danych. Mona wyrni
trzy typy wyzwalaczy, kady skojarzony z typem modyfikacji danych:
update trigger akcja wyzwalacza uruchamiana jest przed lub po modyfikacji
pola tabeli,

92

insert trigger akcja wyzwalacza uruchamiana jest przed lub po wstawieniu

nowego wiersza do tabeli,
delete trigger akcja wyzwalacza uruchamiana jest przed lub po skasowaniu
wiersza w tabeli.
Specjalna skadnia wyzwalacza kontroluje jakie dziaanie uruchamia wyzwalacz
na wyznaczonej kolumnie. Ogln posta podano niej.
IF UPDATE nazwa kolumny
BEGIN
wyraenie w SQL
END
lub
IF UPDATE nazwa kolumny AND UPDATE nazwa kolumny
BEGIN
wyraenie w SQL
END
Wyzwalacz jest uruchamiany natychmiast po modyfikacji danych. Na og SQL
traktuje kade wywoanie wyzwalacza jako transakcj, ktra moe by cofnita, gdy
wystpi bd. Suy do tego np. komenda ROLLBACK TRIGGER, gdy chcemy cofn modyfikacje danych wykonan przez wyzwalacz. Wyzwalacze mog te zmienia
kaskadowo dane w poczonych tabelach.
Przykad 8.36
Mamy dwie tabele. Tabela o nazwie Klient skada si z kolumn: klient.nr, nazwa,
adres oraz tabela o nazwie Polisa zawiera kolumny polisa.nr, ubezpieczony.nr, sprzedawca.nr. W tabeli Klient kluczem gwnym jest klient.nr, a w tabeli Polisa kluczem
gwnym jest polisa.nr. Obydwie tabele powizane s ze sob przez kolumny klient.nr
= ubezpieczony.nr. Pole ubezpieczony.nr ma waciwo klucza obcego w tabeli Polisa. Wyzwalacz kasowania ustawiony na kolumnie klient.nr w tabeli Klient moe spowodowa akcj kasowania rekordw w tabeli Polisa.
ALTER TRIGGER DELETE Klient;
On Klient FOR DELETE;
AS
BEGIN
DELETE FROM Polisa;
WHERE Polisa.ubezpieczony.nr = Klient.klient.nr;
END

93

Wyzwalacze mog zastpowa warunki integralnoci. Nie dopuszczaj lub cofaj

zmiany, ktre naruszaj zasady integralnoci danych. Wyzwalacze mog by uruchamiane, kiedy uytkownik wprowadza do tabeli klucz obcy, ktry nie ma odpowiednika w kluczu gwnym innej tabeli. Wyzwalacze mog zapewnia zasady integralnoci
bardziej zoone ni zdefiniowane reguy integralnoci lub sprawdzanie wprowadzonych danych. Odmiennie od nich wyzwalacze mog odnosi si zarwno do kolumn
jak i obiektw bazy danych. Na og kady wyzwalacz jest uruchamiany tylko raz
w zapytaniu. Jeeli akcja wyzwalacza polega na modyfikacji wielu wierszy tabeli,
wyzwalacz moe zbada dane wielu wierszy i wykona stosown akcj. Modyfikacja
wielu wierszy jest zwykle wana w przypadku obliczania sum w kolumnach.
Przykad 8.37
Policzy przychd w kadym wierszu tabeli Ksiga Przychodu po wykonaniu
wstawienia wiersza.
ALTER TRIGGER policz_przychod;
ON Ksiga Przychodu FOR INSERT;
AS;
BEGIN;
UPDATE Ksiga Przychodu SET;
Przychd = skadka * Prowizja /100;
END
W opisanych przypadkach wyzwalacze rozpatryway wyraenia modyfikacji danych
jako cao. Jeeli jeden z wierszy nie jest akceptowany, to modyfikacja koczy si
niepowodzeniem i caa transakcja jest anulowana. Aby tego unikn, konstruuje si
wyzwalacze wraz z instrukcjami warunkowymi.
Przykad 8.38
Konstrukcja wyzwalacza z instrukcjami warunkowymi.
ALTER TRIGGER sprawdz_zarobki;
ON Pracownik FOR UPDATE;
AS
BEGIN
IF ((Wydzia_nr <> 12) and (Zarobek > 3000));
BEGIN;
UPDATE Pracownik SET;
Zarobek = 3000;
END;
END

94

Wyzwalacze mog zagnieda w sobie inne wyzwalacze. Kady wyzwalacz moe uruchamia inny. Liczba poziomw zagniedenia zaley od systemu. Typowym
zastosowaniem gniazda wyzwalaczy jest funkcja, ktra zapisuje kopie wierszy modyfikowanych przez inny wyzwalacz. Wyzwalacze mog wykonywa proste analizy
oraz porwnania przed i po wykonaniu modyfikacji danych oraz wykonywa akcje
zalene od wyniku porwnania.
W przypadku integralnoci dziedziny podajemy odpowiedni typ danych dla kolumny lub odpowiedni zakres danych.
Przykad 8.39
Uywamy klauzuli CHECK do wymuszenia poprawnej modyfikacji.
CREATE TABLE Jednostki;
(NazwaModuu Char (15);
Poziom Smallint;
KodKursu Char (3);
NrPrac Number (5);
PRIMARY KEY (NazwaJednostki);
FOREIGN KEY (NrPrac IDENTIFIES Pracownicy);
ON DELETE SET NULL;
ON UPDATE CASCADE;
CHECK (Poziom IN 1, 2, 3))
warto wstawiana do POZIOM bya
w okrelonym zbiorze
CREATE TABLE Pracownicy;
(NrPrac Number (5);
NazwiskoPrac Varchar (15);
Status Varchar (15);
NazwaWydziau Varchar (20);
Pensja Decimal (7,2);
PRIMARY KEY (NrPrac);
CHECK (NrPrac BETWEEN 100 AND 10999))

8.7. Uwagi kocowe

Wraz z rozwojem SZBD jzyk SQL z jzyka zapyta przeksztaci si w jzyk baz
danych. Prosta konstrukcja tego jzyka zawarta w tzw. bloku kwalifikacyjnym skadajcym si z instrukcji SELECT.FROM.WHERE w sposb niezwykle przejrzysty
umoliwia konstruowanie programw w SQL. Obecne prace nad tworzeniem standardu SQL skupiaj si na dwch zagadnieniach: wzbogaceniu konstrukcji rela-

95

cyjnych i wprowadzeniu obiektowoci. Jeeli chodzi o pierwsze zagadnienie, to wiele

relacyjnych SZBD realizuje ju aktywne reguy i procedury wyzwalania, czyli wyzwalacze (trigger). Element czasowy zawarty w procedurze CREATE TRIGGER
okrela moment aktywacji wyzwalacza. Wydaje si, e gwnym celem zmodyfikowanej wersji SQL bdzie wprowadzenie obiektowoci. Oczekuje si nowych typw
danych okrelanych przez uytkownika oraz uwzgldnienie takich cech, jak hermetyzacja, tosamo czy dziedziczenie.

96

9. SYSTEM OBIEKTOWO ZORIENTOWANY

9.1. Uwagi oglne
Projektowanie systemw wspomagajcych zarzdzanie przedsibiorstwem jest od
lat tematem rozwaa analitykw, projektantw i informatykw. Celem tego rozdziau
jest omwienie podejcia do projektowania systemw informatycznych, opartych na
modelu obiektowym, wspomagajcych zarzdzanie przedsibiorstwem na przykadzie
biura turystycznego, ktre prowadzi rnego rodzaju usugi [18]. W tym celu naleao
zapozna si ze specyfik pracy biura turystycznego, z potrzebami i oczekiwaniami
wzgldem przyszego systemu informatycznego, sposobami wiadczenia usug. Nastpnym krokiem jest stworzenie dokumentacji bdcej podstaw tworzenia pniejszych
struktur informatycznych. Schemat organizacyjny biura przedstawiono na rys. 9.1.
CENTRALA

ODDZIA

ODDZIA

dom noclegowy

stowka
dom noclegowy

ODDZIA

wypoyczalnia
sprztu

stowka

dom noclegowy

Rys. 9.1. Schemat organizacyjny biura turystycznego

Diagram kontekstowy organizacji, ktry ukazuje jak wymieniane s w biurze zadania i informacje przedstawiono na rys. 9.2.
Przykadowy proces zachodzcy w biurze pokazano na rys. 9.3.
Schemat ten pozwala si zorientowa, jakie operacje naley wykona, aby dany
proces zakoczy si jednym z moliwych zdarze. Kada operacja moe by albo
kolejnym procesem lub zestawem wywoa metod obiektw i operacji na ich atrybutach, albo dziaaniem czowieka. Procesy przedstawione na rysunku s czytelne dla
czowieka, jednak, aby mg posugiwa si nimi komputer musz zosta zapisane
w postaci pseudojzyka.

97

CENTRALA

koordynacja
i planowanie
wycieczek

ODDZIA
rezerwacja
i kontrola
wolnych miejsc

rezerwacja
i kontrola
wolnych miejsc

dom noclegowy

stowka

rezerwacja
miejsc na
imprezy

rezerwacja
sprztu

rezerwacja
posikw

rezerwacja
noclegw

wypoyczalnia
sprztu

KLIENT

Rys. 9.2. Diagram kontekstowy organizacji

98

szukanie wolnych

wstpny
plan trasy

zbyt duo wolnych

pokoi we wasnych
biurach

miejsc w domach noc.

nowa wycieczka

szukanie wolnych
pokoi w innych
biurach

rezerwacja posikw
Oszacowanie

wasne stowki

zainteresowania

opracowanie planu

klientw

wycieczki
rezerwacja posikw

klienci

w innych biurach

zainteresowani

zatwierdzenie

wyznaczenie oddziau

planu wycieczki

prowadzcego

przekazanie planw
do oddziau

odrzucenie projektu
wycieczki

Rys. 9.3. Przykadowy proces zachodzcy w biurze

9.2. Jzyk opisu procesw

Definicja procesu rozpoczyna si sowem kluczowym Process, po ktrym nastpuje nazwa procesu. Wykonanie procesu rozpoczyna si kiedy zajd zdarzenia umieszczone po sowie kluczowym Start on. Nazwy poszczeglnych zdarze s umieszczone w apostrofach ^ i oddzielone od siebie przecinkami. Kady proces skada si z
wielu wywoa podprocesw. Wywoanie podprocesu ma posta: sowo kluczowe
Run, po ktrym nastpuje nazwa procesu. Moliwe jest rwnie wywoanie kilku
procesw rwnolegle, z tym e rozpoczcie kolejnego procesu moe mie miejsce po
zakoczeniu wszystkich procesw rwnolegych. Takie wywoanie ma posta: sowo
kluczowe Run, po ktrym nastpuje nawias { }. W nawiasie naley umieci nazwy
poszczeglnych procesw rozdzielone przecinkami. Mona take wywoywa procesy

99

zwracajce warto. Takie wywoanie ma posta: sowo kluczowe Run test, po ktrym nastpuje nazwa procesu. Po tej komendzie powstaje seria polece postaci: sowo
kluczowe On, po ktrym nastpuje nazwa wartoci zwrconej przez poprzedni proces,
a nastpnie komenda, ktra ma by wykonana dla tej wartoci. Mona rwnie wprowadzi sowo kluczowe Else. Polecenia znajdujce si po tym sowie wykonywane s
dla wartoci, ktre nie zostay wczeniej wymienione po sowach kluczowych On.
Komend Run test koczy sowo kluczowe End test.
Kade polecenie mona zastpi sekwencj instrukcji za pomoc sw kluczowych
Begin... End, midzy ktrymi moe wystpi dowolna ilo komend. Aby w procesie
istniaa moliwo cofania si do wykonanych wczeniej polece, wprowadzono do
zaznaczenia jakiego miejsca w kodzie sowo kluczowe Label, po ktrym nastpuje
identyfikator zapisany duymi literami. Powrt do tego miejsca nastpuje po napotkaniu sowa kluczowego Back to z danym identyfikatorem. Sowo kluczowe Throw
suy do wywoywania zdarze. Wykonanie kodu procesu koczy si po napotkaniu
sowa kluczowego !End. Dopuszczalne jest uycie kilku instrukcji koczcych
w jednym procesie. Niej podano opis w postaci pseudojzyka przykadowych procesw.
Przykad 9.1
Opis w pseudojzyku procesu planowania wycieczki dla rysunku 9.3.
Process PLANOWANIE WYCIECZKI OBJAZDOWEJ
Start on ^Zbyt duo miejsc w budynkach^ or ^Wymylono now wycieczk^
Begin
Run ^Wstpne zaplanowanie trasy^
Run
{
^Szukanie wolnych pokoi we wasnych budynkach^
^Szukanie wolnych pokoi w innych biurach^
}
Run ^Opracowanie planu wycieczki^
Run
{
^Rezerwacja posikw we wasnych stowkach^
^Rezerwacja posikw w innych biurach^
}
Run test ^Oszacowanie zainteresowania klientw^
On ^Klienci zainteresowani^
Begin
Run ^Zatwierdzenie planu wycieczki^
Run ^Wyznaczenie Oddziau Prowadzcego^
Throw ^Przekazanie planu do oddziaw^
!End
EndOn
Else

100
Begin
Throw ^Odrzucenie planu wycieczki^
!End
End test
End
End

Przykad 9.2
Opis w pseudojzyku procesu realizacji wycieczki.
Process REALIZACJA WYCIECZKI OBJAZDOWEJ W ODDZIALE
Start on ^Wpyn projekt nowej wycieczki^
Begin
Run ^Wprowadzenie wycieczki do oferty^
Run ^Wyznaczenie odpowiedzialnego pracownika^
Label REALIZACJA
Run ^Rezerwacja rodkw transportu^
Run ^Wyznaczenie pilotw^
Run ^Opracowanie i realizacja strategii reklamowej^
Run test ^Oczekiwanie na zgoszenia klientw^
On ^Zbyt mao klientw^
Run test ^Analiza przyczyn braku zainteresowania^
On ^Przyczyna braku klientw moliwa do poprawienia^
Begin
Run ^Korekta oferty^
Back to REALIZACJA
End
On ^Przyczyna braku klientw niemoliwa do poprawienia^
Begin
Run ^Przedstawienie zgoszonym klientom innych propozycji^
Run ^Anulowanie wycieczki^
Throw ^Zgoszenie faktu anulowania wycieczki do centrali^
!End
End On
End On
On ^Wystarczajca ilo klientw^
Begin
Run test ^Sprawdzenie czy pozostay wolne miejsca^
On ^Tak^
Run ^Oferta last minute^
End On
Run ^Zatwierdzenie wyjazdu^
Throw ^Wyjazd wycieczki^
End test
!End
End On
End test
End On
End test
End
End

101

Przykad 9.3
Opis w pseudojzyku rezerwacji miejsc w domu noclegowym wasnym.
Process REZERWACJA MIEJSC DOM NOCLEGOWY WASNY
Start on ^Rezerwacja z oddziau^, ^Bezporednia rezerwacja^
Begin
Run Test ^Sprawdzenie czy s wolne miejsca^
On ^Znaleziono^
Begin
Label REALIZACJA
Run ^Rezerwacja miejsca^
Throw ^Informacja o dokonaniu rezerwacji^
!End
End On
On ^Brak^
Begin
Label ODMOWA
Run ^Odmowa rezerwacji^
Throw ^Informacja o braku miejsc^
!End
End On
On ^Znaleziono^
Run test ^Konsultacja z klientem aktualnej rezerwacji^
On ^Rezerwacja aktualna^
Back to ODMOWA
On ^Rezerwacja nieaktualna^
Begin
Run ^Anulowanie rezerwacji aktualnego klienta^
Back to REZERWACJA
End
End On
End On
End test
End On
End test
End
End

9.3. Schemat bazy danych

Posugujc si posiadanymi informacjami o przedsibiorstwie mona stworzy
schemat bazy danych. Na schemacie pokazanym na rys. 9.4, uwzgldniono wszystkie
obiekty wraz z nazwami ich atrybutw, powizaniami midzy obiektami, oraz
uwzgldniono dziedziczenie. Jako model dziedziczenia przyjto dziedziczenie wielobazowe, poniewa oferuje ono wiksz elastyczno przy tworzeniu obiektw. Relacje
dziedziczenia s zaznaczone na rysunku liniami zakoczonymi strzakami, gdzie grot
strzaki wskazuje obiekt rodzica w tym zwizku.

Rys. 9.4. Schemat bazy danych biura turystycznego uwzgldniajcy dziedziczenie

104

9.4. Jzyk opisu klas

Definicja klasy skada si z nazwy klasy, nazw klas, po ktrych ta klasa dziedziczy, oraz atrybutw i metod danej klasy. Nazwa klasy, pisana du liter poprzedzona
jest sowem kluczowym class. W nowej linii po sowie inherit znajduje si lista klas,
po ktrej definiowana klasa ma dziedziczy. Poszczeglne klasy musz by oddzielone przecinkami. Atrybuty klasy pojawiaj si po sowie kluczowym properties. Lista
atrybutw zakoczona jest sowem end. Kady z atrybutw powinien si znale
w nowej linii. Linia jest zbudowana z nazwy atrybutu, znaku : oraz typu atrybutu.
Mona uywa nastpujcych typw atrybutw: integer, real, string, date, time, datetime, inne klasy. Jeli atrybutem jest nazwa innej klasy, to wartoci tego atrybutu
moe by zarwno obiekt tej klasy, jak i dowolnej klasy dziedziczcej po tej klasie.
W opisie przyjto nastpujc konwencj: jeli po nazwie atrybutu pojawi si znak
(*), to oznacza to, e mamy do czynienia z list atrybutw danego typu. Wizy integralnoci podajemy po sowie constraints. Maj one posta warunkw jakie musz
spenia wybrane pola. Jeli warto warunku wynosi false, to warto atrybutu nie
moe zosta zaakceptowana. Lista procedur wywoanych zdarzeniami zachodzcymi
w bazie umieszczamy za sowem kluczowym triggers. Kady wiersz w opisie klasy
zakoczony jest znakiem ; .
Szablon definicji klasy ma nastpujca posta:
class NAZWA KLASY
inherit NAZWA KLASY BAZOWEJ
properties
nazwa atrybutu: typ atrybutu;
nazwa atrybutu (*): typ atrybutu;
constrains
nazwa atrybutu > 0;
nazwa atrybutu1 > nazwa atrybutu2;
triggers
if nazwa atrybutu not NULL then delete disabled;
end;

Jako przykadow definicj klasy podano klas bazow RODEK TRANSPORTU.

Poniewa klasa ta nie dziedziczy po innych klasach, wic po sowie kluczowym inherit
nie wystpuje nic. RODEK TRANSPORTU posiada atrybuty: wypoczynek wskazujcy na klas WYPOCZYNEK, ilo osb atrybut prosty typu integer, rezerwacja
wskazujcy na klas REZERWACJA, dodatki lista atrybutw prostych typu string
oraz cen za osob atrybut prosty typu real. Zdefiniowane wizy integralnoci sprawiaj, e atrybuty cena za osob i ilo osb musz mie warto wiksz od zera.
Zdefiniowana procedura typu trigger sprawia, e danego rodka transportu nie da si
usun, jeli odwouje si on do obiektu typu REZERWACJA lub WYPOCZYNEK.

105

Przykad 9.4
Opis klasy RODEK TRANSPORTU:
class RODEK TRANSPORTU
inherit
properties
wypoczynek: WYPOCZYNEK;
ilo osb: integer;
rezerwacja: REZERWACJA RODKA TRANSPORTU;
dodatki (*): string;
cena za osob: real;
constrains
cena za osob > 0;
ilo osb > 0;
triggers
if wypoczynek, rezerwacja not NULL then delete disabled;
methods
New();
Dispose();
OdczytAtrybutw(): (*)^;
ZapisAtrybutw (wypoczynek, ilo osb, rezerwacja, dodatki, cena za osob);
Ilo dni (wypoczynek): integer;
end;

Jako przykad klasy dziedziczcej po innej klasie przedstawiono klas

SAMOLOT. Klasa ta dziedziczy wszystkie atrybuty po klasie bazowej RODEK
TRANSPORTU, ponadto posiada wasne atrybuty charakteryzujce wycznie j:
rodzaj wynajcia, typ, klasa.
Przykad 9.5
Opis klasy SAMOLOT:
class SAMOLOT
inherit RODEK TRANSPORTU
properties
rodzaj wynajcia: string;
typ: string;
klasa: string;
methods
New();
Dispose();
OdczytAtrybutw() : (*)^;
ZapisAtrybutw (rodzaj wynajcia, typ, klasa);
end;

Przykad 9.6
Opis klasy PRACOWNIK:

106
class PRACOWNIK
inherit OSOBA
properties
data_ zatrudnienia: date;
stanowisko: string;
zarobki: real;
szef: PRACOWNIK;
odpowiedzialny (*): WYPOCZYNEK, BIURO, SAMOCHD;
data _urodzenia: date;
miejsce_ zatrudnienia: string;
constrains
miejsce_ zatrudnienia not NULL;
data_ zatrudnienia not NUL;
adres not NULL;
triggers
if odpowiedzialny not NULL then delete disabled;
methods
New();
Dispose();
OdczytAtrybutw(): (*)^;
ZapisAtrybutw (data_zatrudnienia, stanowisko, zarobki, szef, odpowiedzialny, data_urodzenia, miejsce_zatrudnienia);
Nazwisko_szefa: string;
Imi_szefa: string;
ZaCoOdpowiedzialny: string;
end;

Przykad 9.7
Opis klasy OSOBA:
class OSOBA
inherit
properties
nazwisko: string;
imi: string;
pe: boolean;
nr_dowodu: string
adres: string
telefon: string;
constrains
nazwisko not NULL;
methods
New();
Dispose();
OdczytAtrybutw(): (*)^;
ZapisAtrybutw (nazwisko, imi, pe, nr_dowodu, adres, telefon);
end;

W podobny sposb mona opisa wszystkie klasy wystpujce w systemie.

107

9.5. Jzyk opisu metod

Kada klasa zawiera metody operujce na wartociach atrybutw tej klasy. Wszystkie metody zawarte s w sowie kluczowym methods. Nazwa metody rozpoczyna si
od duej litery i charakteryzuje jej dziaanie. W kadej klasie zdefiniowano dwie podstawowe metody suce do odczytu i zapisu atrybutw danej klasy. Metoda OdczytAtrybutw(); wykorzystywana jest do pobierania wszystkich, lub tylko niektrych,
wartoci atrybutw obiektu. Brak parametrw przy wywoywaniu tej metody powoduje zwrot wartoci wszystkich atrybutw (take NULL) danego obiektu. W tym przypadku zwracany jest wskanik do listy wskanikw dla okrelonych wartoci atrybutw. Zapisywane jest to w nastpujcy sposb: OdczytAtrybutw (): (*)^; Jeeli
interesuj nas tylko okrelone atrybuty, to naley jako parametry poda ich nazwy,
a jako wynik dziaania metody otrzymamy wskanik do listy wskanikw zawierajcej tylko podane atrybuty (OdczytAtrybutw (zarobki, szef): (*)^ ;). Aby zapisa
wartoci atrybutw do obiektw, naley uy metody ZapisAtrybutw( );. W obiekcie
zapisywane s tylko te wartoci atrybutw, rozdzielone przecinkami, ktre zostay
podane w linii parametrw. Moliwe jest zatem nastpujce wywoanie metody zapisujcej atrybuty: ZapisAtrybutw (data_zatrudnienia, stanowisko, zarobki, , data_urodzenia);. Wartoci zwracane przez te reguy to na og wartoci proste typu:
integer, real, string, date, ale take wskaniki do list zawierajcych wartoci proste.
Zapisuje si to w nastpujcy sposb: ProgramWypoczynku: (*) string;. Rwnie
obiekt moe by wartoci zwracan przez metod ProgramWypoczynku: (wypoczynek): PROGRAM;.W kadej klasie zdefiniowane s dwie metody suce do tworzenia
i kasowania obiektw. Do tworzenia nowego obiektu wykorzystuje si metod New();,
natomiast do zwalniania zasobw zajtych przez dany obiekt metod Dispose();.

9.6. Jzyk opisu praw dostpu

Definicja praw dostpu danej klasy do pozostaych klas rozpoczyna si sowem
kluczowym rights, a koczy na sowie kluczowym end. Po sowie rights podawana
jest nazwa klasy, dla ktrej zdefiniowane zostay prawa dostpu, nastpnie wypisywane s wszystkie obiekty ze wszystkimi ich atrybutami, a obok podawane s prawa
dostpu. Przykadowo wybrano trzy prawa dostpu: R (read) klasa ma prawo tylko
do odczytu danego obiektu lub atrybutu, M (modify) klasa ma prawo modyfikacji
oraz odczytu danego obiektu lub atrybutu oraz D (delete) klasa ma prawo kasowania, modyfikacji i odczytu danego obiektu lub atrybutu. Przyjcie takiej kaskadowej
koncepcji praw uatwia w znaczny sposb definiowanie i zapis tego w systemie bazy
danych. Prawa dostpu podawane s po dwukropku w nawiasach, a wiersz definicji
zakoczony jest rednikiem. Jeli w nawiasie nie pojawi si adna litera, to dana klasa

108

nie ma adnych praw dostpu do obiektu lub atrybutu. Niej podano przykad okrelenia praw dostpu dla klasy: OBSUGA KLIENTA.
Przykad 9.8
Nadawanie praw dostpu:
rights

OBSUGA KLIENTA

KIEROWNIK: (R);
Telefon: (R);
Samochd: (R);
Podlegli pracownicy: (R);
PRACOWNIK BIUROWY: (R );
wyksztacenie: (R);
jzyki: (R);
specjalnoci: (R);
KLIENT: (D);
bierze udzia w: (M);
wpaci: (M);
zarezerwowa: (M);
OSOBA: (D);
nazwisko: (M);
imi: (M);
pe: (M);
nr dowodu: (M);
telefon: (M);
adres: (M);
PRACOWNIK

.
.
end

9.7. Zapytania w bazie

Podstawowym elementem kadego systemu baz jest proste i efektywne formuowanie zapyta. Jzyk zapyta powinien charakteryzowa si prostot zapisu zoonych operacji, by efektywny, to znaczy zapytania powinny by optymalizowane pod
wzgldem szybkoci wyszukiwania informacji, a ponadto powinien by niezaleny od
aplikacji. Spenienie tych wymaga w przypadku baz obiektowych jest z wielu powodw trudne. Dua zoono struktur danych, brak jednolitego modelu oraz sprzeczno z zasad enkapsulacji (wartoci danych nie powinny by bezporednio dostpne
dla uytkownika) to podstawowe przeszkody. W przypadku baz obiektowych mona
wyrni dwa podstawowe sposoby dostpu do obiektw. Pierwszy z nich to wykorzystanie jzyka zapyta podobnego w swej konstrukcji do jzyka relacyjnych baz
danych, np. SQL, drugi sposb bazuje na bezporednim dostpie do obiektw poprzez

109

ich identyfikatory. Wykorzystanie identyfikatorw pozwala na poruszanie si po bazie, a metody obiektw na uzyskanie dostpu do danych w obiekcie. Oba sposoby
mog by uywane zamiennie. Mona, przykadowo, wykorzystujc jzyk zapyta
otrzyma zbir wynikw speniajcych dane warunki, a nastpnie korzystajc z technik nawigacyjnych przeglda rezultat zapytania. Rezultatem zapytania moe by
obiekt lub zbir obiektw klasy, ktra musi by zdefiniowana w zapytaniu. Zabezpieczeniem w tym przypadku moe by zaoenie, e wszystkie otrzymane atrybuty musz pochodzi z kadego z wyszukanych obiektw, czyli e moe to by albo sam
obiekt, albo pojedynczy atrybut. Sposb ten gwarantuje, e wynikiem wyszukiwania
bdzie zbir obiektw nalecych do istniejcych ju klas. W zapytaniach do baz danych mona rwnie wykorzysta metody. Wykorzystanie metod moe w znaczcy
sposb wpyn na uatwienie wyszukiwania informacji w bazie. Rezultat metody
moe suy do sformuowania warunkw zapytania lub moe by zwykym atrybutem speniajcym okrelone warunki. Jako przykad zadajemy pytanie: Znajd wszystkich kierowcw autokaru, dla ktrych impreza (wypoczynek) bdzie trwaa trzy dni.
W tym przypadku wykorzystamy metod IloDni (impreza) obiektu KIEROWCA
AUTOKARU, ktra jako rezultat swojego dziaania zwraca warto rwn dugoci
trwania imprezy w dniach.
W dziedzinie prac badawczych nad jzykiem zapyta dla obiektowych baz kadzie
si duy nacisk na zgodno ze standardem jzyka SQL. Obiektowe jzyki wzorowane
na SQL dysponuj podstawowymi moliwociami tego jzyka takimi, jak: mechanizmy sortowania danych, operacje grupowania danych, funkcje arytmetyczne itp. Formuowanie zapytania w jzyku obiektowym np. OQL (ang. Object Query Language),
jest bardzo podobne do formuowanych w SQL. OQL jest oparty na rachunku dziedzin. Zapytanie jest wyraeniem, zwykle zoonym, o okrelonym typie. Jzyk udostpnia szereg operatorw o rnej liczbie argumentw, ktre mog by take wyraeniami. Konstrukcja SELECT-FROM-WHERE jest pewnym operatorem. Dlatego
OQL umoliwia zagniedanie nie tylko na poziomie frazy WHERE, ale rwnie
przy frazach SELECT i FROM. SELECT okrela zbir atrybutw, ktry ma by
rezultatem zapytania, FROM okrela zakres zapytania, a WHERE okrela warunki,
jakie musz spenia wyszukiwane obiekty. Atrybuty mog by definiowane w sposb
zagniedony. W tym wypadku konieczne jest definiowanie cieek dostpu.
Przykad 9.9
Znajd wszystkie wycieczki objazdowe, ktre trway cztery dni, ktrych pilot jest
specjalist od architektury i ktrych klienci s mczyznami.
SELECT x FROM x IN WYPOCZYNEK WHERE x.ilo_dni=4 AND x.pilot.specjalizacja = Architektura AND x.klient.pe = TRUE;
Przykad 9.10
Znajd wszystkich pracownikw oraz ich przeoonych. Przeoeni musz zarabia
mniej ni 1000 i musi by speniony dodatkowy warunek, e urodzili si po 1975 roku.

110

SELECT DISTINCT STRUCT (n:x.nazwisko, p: (SELECT y FROM y IN x.szef

WHERE y.zarobki < 1000) AND y.data_urodzenia > 1975-01-01) FROM x IN
PRACOWNIK;
Przykad 9.11
Znajd nazwiska i stanowiska tych pracownikw, ktrzy maj na imi Tomasz lub
Marcin oraz zostali zatrudnieni po 1 kwietnia 1999 roku.
SELECT STRUCT (n:x.nazwisko, s:x.stanowisko) FROM x IN (SELECT y FROM y
IN PRACOWNIK WHERE y.data_zatrudnienienia > 1999-04-01) WHERE
(x.imi=Tomasz OR x.imi=Marcin);
Przykad 9.12
Znajd wszystkich pracownikw biurowych, ktrzy s jednoczenie szefami.
SELECT PRACOWNIK_BIUROWY WHERE EACH szef = TRUE; lub
FOR ALL x IN PRACOWNIK BIUROWY: x.szef = TRUE;
Przykad 9.13
Znajd pracownikw biurowych, z ktrych co najmniej jeden jest szefem.
SELECT PRACOWNIK_BIUROWY WHERE EXSISTS szef = TRUE;
Jeli mamy do czynienia z atrybutami wielowartociowymi to w zapytaniu naley
uy konstruktora SET.
Przykad 9.14
Znajd pracownikw biurowych, ktrzy rozpoczynaj urlopy: 2.07.99, 1.02.00,
4.02.00.
SELECT PRACOWNIK_BIUROWY FROM x IN WYPOCZYNEK WHERE
data_rozpoczcia IN SET (1999-07-02, 2000-02-01, 2000-02-04)
Przy wyszukiwaniu danych naley wzi pod uwag, czy zapytanie dotyczy tylko
jednej wyspecjalizowanej klasy. Najprostszym sposobem jest wykonanie operacji
sumowania zbiorw.
Przykad 9.15
Znajd wszystkich pracownikw zarabiajcych wicej ni 1000.
(SELECT x FROM x IN PRACOWNIK WHERE zarobki > 1000);
UNION
(SELECT x FROM x IN KIEROWCA WHERE zarobki > 1000);
UNION
(SELECT x FROM x IN KIEROWCA_AUTOBUSU WHERE zarobki > 1000);
UNION
..
..
dla wszystkich obiektw dziedziczcych po obiekcie PRACOWNIK.

111

Znacznym uproszczeniem powyszego zapisu jest wstawienie obok nazwy klasy operatora *, ktry oznacza, e w zapytaniu bdzie uwzgldniona caa hierarchia tej klasy.
Przykad 9.16
Znajd wszystkich pracownikw zarabiajcych wicej ni 1000.
SELECT PRACOWNIK * WHERE zarobki > 1000;
Czstym przypadkiem w definicji klas jest fakt, e nowo utworzona klasa jest definiowana przez odwoanie si do siebie samej. W jzyku zapyta powinna powsta
moliwo zadawania pyta dotyczcych zalenoci cyklicznych. Rozwaymy atrybut
szef klasy PRACOWNIK. Dziedzin tego atrybutu jest ta sama klasa.
Przykad 9.17
Znajd wszystkich pracownikw, ktrzy s podwadnymi pracownika o nazwisku
Nowak.
SELECT x FROM x IN PRACOWNIK, y IN PRACOWNIK WHERE y = x.szef
AND EXISTS (SELECT y FROM y IN y.szef WHERE y.nazwisko = Nowak);
Inaczej ten przykad mona zapisa w prostszy sposb, uywajc klauzuli
RECURSES.
SELECT PRACOWNIK (RECURSES szef) WHERE nazwisko = Nowak
RESURSES szef oznacza, e jak tylko zostanie znaleziony obiekt klasy
PRACOWNIK z atrybutem nazwisko = Nowak, musi by rekursywnie zwrcona
warto atrybutu szef dla tego obiektu.
Zapytania z wielokrotnymi obiektami pozwalaj na rozstrzygnicie, czy przedmiotem
zapytania ma by caa hierarchia klas, czy tylko pojedyncza klasa oraz rozwizuj
problem porwnywania atrybutw wielowartociowych.
Przykad 9.18
Znajd wszystkich pracownikw biurowych, ktrzy maj to samo nazwisko co szef
pilotw.
SELECT x FROM x IN PRACOWNIK_BIUROWY, p IN PILOT WHERE x.nazwisko = p.szef. nazwisko
Obiektowy jzyk OQL jest zasadniczo jzykiem wyszukiwania danych, nie posiada
SQL-owych komend INSERT i UPDATE, cho umoliwia wykonywanie metod
obiektw, ktre mog wykonywa operacje na danych. W OQL brak jest wartoci
NULL, pojcia tablic oraz perspektyw. Jest jednak moliwo definiowania wizw
integralnoci, wyzwalaczy i nadawania przywilejw.

112

9.8. Uwagi kocowe

Trudnoci z jakimi spotykaj si pracownicy rnego typu przedsibiorstw czy
biur to zapanowanie nad ogromnym stosem dokumentw oraz konieczno trzymania
si cile wytyczonego schematu, ktry jest niefunkcjonalny, poniewa na przykad
rezygnacja jednego klienta w dowolnym momencie realizacji usugi sprawia ogromny
zamt w pozostaych rezerwacjach. Spraw niezmiernie wan jest rwnie scalenie
i ujednolicenie formatu dokumentw istniejcych w przedsibiorstwie. Zwykle uywa
si kilku niezalenie pracujcych programw. Jedne dotycz systemu rezerwacji, inne
usprawniaj ksigowo. Naley szuka wic rozwizania jednolitego, ktre synchronicznie wspomagaoby prac na wielu paszczyznach. Od takiego produktu oczekuje
si pogodzenia dziaalnoci przedsibiorstwa jako operatora wycieczek, czyli firmy
sprzedajcej swoj ofert rozbudowanego systemu rezerwacji i firmy dbajcej o wasne sprawne biuro obsugi klienta. Moliwoci wykorzystania komputerw zarwno
w sieciach lokalnych przedsibiorstwa, jak i dostp do oglnowiatowej sieci Internet
stworzyo wielkie moliwoci rozwoju tego typu firm.

113

10. SYSTEM DEDUKCYJNY

10.1. Uwagi oglne
W celu zilustrowania teorii dedukcyjnych baz danych przedstawiono system bazy
danych obsugujcy laboratorium medyczne [18]. Jak powszechnie wiadomo, medycyna jest dziedzin bardzo szybko rozwijajc si, a wiedza medyczna ma bardzo
niski stopie formalizacji. Wykorzystanie sformatowanego modelu danych takiego
jakim jest model relacyjny nie oddawaoby istoty problemu. Dlatego te model dedukcyjny wydaje si by odpowiedni do ilustracji laboratorium medycznego. Przykadowy model struktury bazy skada si z siedmiu moduw:
1. REJESTRU kartoteka pacjentw, rejestracja zlece, katalog bada;
2. PRACOWNI weryfikacja zlece, ksika zlece, wyniki i metody;
3. KONTROLI materiay kontrolne, prby kontrolne, dokumentacja;
4. MAGAZYNU kartoteka materiaowa, przychody, rozchody, zestawienia, rozliczenia;
5. ANALIZY wyznaczanie norm, weryfikacja hipotez, prezentacja;
6. ADMINISTRATORA konfiguracja, sterowanie, zabezpieczenia, kopie, uytkownicy;
7. ARCHIWUM archiwizacja, wyniki zbiorcze, zestawienia, rozliczenia;
Schemat blokowy przykadowej bazy danych przedstawia rys. 10.1.
REJESTR

PRACOWNIA

KONTROLA

ARCHIWUM

MAGAZYN

ANALIZA

ADMINISTRATOR

Rys. 10.1. Schemat przykadowej bazy danych Laboratorium

Wszystkie informacje przetwarzane w tych moduach s umieszczone w tabelach.

Jest wiele tabel, np. PACJENT (id.pacjenta, nazwisko, imi, data urodzenia, ....., kategoria pacjenta), ODDZIA (id.oddziau, kod, nazwa), BADANIA (id.badania, id.pa-

114

cjenta, id.oddziau, id.kategorii badania, ....., archiwum) WYNIKI (id,wyniku,

id.nazwy, id.grupy, wynik liczba, jednostki, ....., data wykonania badania) i inne, gdzie
PACJENT, WYNIKI, BADANIA to nazwy encji, a w nawiasach podano atrybuty opisujce dan encj. Pomidzy tabelami istniej powizania typu jeden do wielu, ktre na
rwni z wartociami atrybutw umieszczonymi w tabelach s nonikami informacji.

10.2. Pozyskiwanie wiedzy

Tworzenie i pozyskiwanie wiedzy jest najtrudniejszym elementem budowy systemw dedukcyjnych baz danych [1, 3, 18]. Wchodz tu w gr midzy innymi takie
czynniki, jak: trudnoci z usystematyzowaniem wiedzy, jej obszerno, moliwo
popenienia pomyek itp. W podanym przykadzie wiedz uzyskano drog konsultacji
z ludmi pracujcymi w laboratorium medycznym, ekspertami w tej dziedzinie. Analiza i proces wnioskujcy zostay przeprowadzone na podstawie bada tarczycy [14,
16, 17]. Do analizy potrzebne byy:
fakty bazowe zawierajce: informacje o pacjentach oraz zestaw bada, np:
wyniki i normy badania TSH,
wyniki i normy badania fT4,
wyniki i normy badania AMA,
wyniki i normy badania TRH,
pe pacjenta;
fakty wirtualne, ktre uzyskuje si w czasie trwania analizy i s odpowiedziami
na postawione przez system wnioskujcy pytania:
czy pacjent jest w trakcie brania konkretnych lekw, ktre maj wpyw na
wyniki poszczeglnych bada,
w przypadku gdy pacjent jest kobiet, system moe poprosi o informacj czy
pacjentka nie jest w ciy,
czy wyniki podanych wyej bada mieszcz si w normach, czy te przekraczaj doln lub grn granic.
Graf przedstawiony na rys. 10.2 pokazuje poszczeglne etapy wnioskowania. Wida na nim, e moliwe s do sformuowania cztery hipotezy, konkretne stany chorobowe tarczycy. W przypadku, gdy wynik badania TSH bdzie poniej dolnej granicy
normy, a wynik badania fT4 bdzie w normie, uytkownik bdzie proszony o udzielenie odpowiedzi na pytanie czy analizowany pacjent bierze jakie leki. Moliwe jest
zadawanie dwch rodzajw pyta:
pytanie sformuowane w taki sposb, e moliwa jest odpowied tak lub nie;
pytanie o wikszej liczbie odpowiedzi, w ktrym zbir moliwych odpowiedzi
musi zosta wczeniej okrelony. Przypadek drugi jest rwnie trudniejszy w analizie
dla programisty. Naley zatem tak formuowa pytanie, aby zbir odpowiedzi by
moliwie jak najmniejszy.

115

low

high
TSH

high
normal
fT4

nie

low

normal

tak

fT4
LEKI

AMA

nie

CIA

normal

high

normal
TRH
SUBKLINICZNA
NADCZYNNO
low

NADCZYNNO

EUTYREOZA

NIEDOCZYNNO

Rys. 10.2. Przykadowy graf do prowadzenia procesu wnioskujcego

HIPOTEZY

NADCZYNNO EUTYREOZA
TARCZYCY

SUBKLINICZNA
NIEDOCZYNNO
NIEDOCZYNNO TARCZYCY

FAKTY:

TSH-LOW
TSH-NORMAL
TSH-HIGH
fT4-LOW
fT4-NORMAL
fT4-HIGH
TRH-LOW
TRH-NORMAL
AMA-NORMAL
AMA-HIGH
Czy pacjent bierze leki?
Czy pacjentka
jest w ciy?

+ + +
+

+ + +

+
+
+
+
+
N
N

N N T
N T

Rys. 10.3. Przykad tabeli decyzyjnej

+
+

116

Ze wzgldu na prostot, czytelno oraz zrozumiao dla nieprofesjonalistw do

pozyskania i usystematyzowania wiedzy zostaa uyta tabela decyzyjna (rys. 10.3).
Znak + oznacza, e dany fakt jest prawdziwy.

START

We hipotez ze
szczytu stosu zada

tak

nie
Czy w bazie wiedzy na
licie faktw jest odpowied
na postawion hipotez?
Okrel reguy, ktrych
przesanki znajduj si
na licie faktw

nie
Czy istnieje regua ktr
mona uaktywni?

Wybierz regu stosujc

strategi wnioskowania
Sformuuj odpowied

Uaktywnij wybran regu

stop

tak

Dopisz nowe fakty do listy

faktw, zaznacz uycie
uaktywnionej reguy

Rys. 10.4. Algorytm maszyny wnioskujcej progresywnie

117

Kolumny tej tabeli zawieraj hipotezy, a wiersze fakty zwizane z wynikami konkretnych bada laboratoryjnych oraz pytania zadawane przez system podczas procesu
wnioskujcego. Daje to przejrzysty obraz danej dziedziny. W tabeli znak + odpowiada zachodzeniu konkretnych faktw. Na podstawie tej tabeli decyzyjnej zbudowana jest baza regu i przeprowadzone wnioskowanie progresywne (rys. 10.4). Wnioskowanie to polega na wybraniu jednej z moliwych hipotez, a nastpnie generowanie
za pomoc zdefiniowanych regu nowych faktw a do momentu, kiedy dana hipoteza
zostanie udowodniona, albo zbir regu zostanie wyczerpany.
Kolejne kroki algorytmu maszyny wnioskujcej progresywnie mona opisa w nastpujcy sposb. W procesie wnioskowania korzysta si z pewnego obszaru pamici
roboczej programu, gdzie przechowuje si wyniki tak zwanego stosu zada. Rozwizanie problemu zaczyna si od umieszczenia hipotezy na szczycie stosu zada
(w naszym przykadzie subkliniczna niedoczynno tarczycy), nastpnie system przeglda list faktw w bazie wiedzy i sprawdza, czy nie ma tam odpowiedzi na postawion hipotez.
Jeeli jest, to nastpuje sformuowanie odpowiedzi i zakoczenie procesu wnioskowania. Jeeli w bazie nie ma odpowiedzi na wybran hipotez, zostaje okrelony
zbir regu, ktrych przesanki znajduj si na licie faktw. Nastpnie, stosujc strategi sterowania wnioskowaniem, wybiera si odpowiednie reguy. Kolejnym krokiem
jest sprawdzanie, czy wybran regu mona uaktywni. Jeeli nie, to proces jest zatrzymany. Oznacza to, e na podstawie zgromadzonych regu i faktw nie mona
udowodni wybranej hipotezy. W przeciwnym razie, po uaktywnieniu reguy, konkluzja jej jest wprowadzana na list faktw oraz jest odnotowane, e wybrana regua zostaa uyta w biecym procesie wnioskujcym strategia blokowania. Po wprowadzeniu nowego faktu na list system sprawdza ponownie, czy na licie faktw
znajduje si wybrany cel czyli hipoteza. Proces jest powtarzany tak dugo, a zostanie
osignity cel lub zostan wyczerpane wszystkie moliwoci jego wykazania.

10.3. Baza wiedzy

Na baz wiedzy skada si baza faktw i baza regu. Gromadzenie faktw rozpoczyna
si podczas tworzenia caego systemu. Zbierane s szczegowe dane o pacjencie oraz
o badaniach, jakie s zalecane. W bazie faktw mog wystpowa trzy typy faktw:
fakty bazowe gromadzone podczas tworzenia systemu,
fakty wnioskowane wprowadzone jako konkluzje uaktualnionych regu,
fakty podane przez uytkownika w czasie procesu wnioskowania.
Rna jest ywotno tych trzech rodzajw faktw. O ile fakty bazowe utrzymuj
swoj ywotno w czasie caej sesji trwania wnioskowania, o tyle fakty podane przez
uytkownika s wane do koca cyklu wnioskowania, nastpnie mona je zmieni,
odpowiadajc inaczej na pytania zadawane przez maszyn wnioskujc. Oczywicie

118

tylko nowy zestaw przechodzi do nastpnego cyklu wnioskowania, a wszystkie inne

trac wano i zostaj usunite z bazy. Inaczej przedstawia si sprawa z baz regu.
W przedstawionym modelu regu moe by:
a) predykat rekurencyjny:
badanie (badanie, badanie czstkowe, wynik), gdzie badanie czstkowe (badanie,
wynik)predykat badanie opisuje badanie zawarte w bazie oraz czy badania zoone
z jego komponentami, ktre mog wystpowa samodzielnie i wielokrotnie.
b) predykat wirtualny:
wynik (norma, badanie)
prawidowa warto
AND wynik > od wartoci
AND wynik < od wartoci
Regua ta wyznacza badania, dla ktrych wynik badania jest poprawny. Ciao reguy
definiujcej wirtualny predykat wynik odwouje si wycznie do predykatu bazowego
prawidowa warto (dane te s okrelane poprzez normy konkretnego badania).
Oglnie w ciaach regu mona odwoywa si do wielu predykatw zarwno bazowych, jak i wirtualnych, stosujc dodatkowo kwantyfikatory oglne i (lub) szczegowe (w jzyku SQL some lub any i exists). Zbir regu w przykadzie zosta sformuowany na podstawie tabeli decyzyjnej. Reguy w takiej postaci w literaturze
anglojzycznej okrelane s jako production rules.
IF warunek_1
AND warunek_2
......
AND warunek_n
THEN konkluzja
Mechanizm wnioskowania dla tego typu regu prbuje ustali prawdziwo poszczeglnych warunkw danej reguy. Proces ustalania prawdziwoci warunkw powoduje
uruchamianie procedur rozpatrujcych inne reguy, ktrych konkluzjami s warunki
procedury pierwotnej. Pozytywne rozpatrzenie wszystkich warunkw powizanych
operacj koniunkcji pozwala na udowodnienie konkluzji. Zalet regu jest to, e odpowiadaj ludzkiej intuicji i w prosty sposb reprezentuj wiedz heurystyczn oraz
daj si atwo modyfikowa. Mona zmienia reguy, nie zwracajc uwagi na powizania tej reguy z innymi. Oczywicie nie mona pozwoli na cakowit dowolno
w strukturze bazy regu. Zaptlenia i reguy sprzeczne mog powodowa nieprzewidziane dziaanie systemu. Aby uatwi wprowadzanie regu, opracowano specjalny format regu z wykorzystaniem struktury plikw typu ini. Oglny format regu ma posta.
[RULE_1] nazwa reguy w bazie,
TAKE=FALSE parametr reguy okrelajcy, czy regua zostaa wykorzystana
w procesie wnioskowania; po uaktywnieniu jakiej reguy warto tego parametru

119

zmieniana jest z FALSE na TRUE. Po zakoczeniu procesu wnioskowania parametr

TAKE we wszystkich reguach ustawiana jest na warto pocztkow FALSE.
COUNT=n faktyczna liczba warunkw jakie musz zosta spenione, aby konkluzja
reguy zostaa wprowadzona do bazy faktw.
W1: WARUNEK_1
konkretne warunki
W2: WARUNEK_2
.
.
.
Wn: WARUNEK_n
K: KONKLUZJA
parametr okrela konkluzj reguy
Edycji regu mona dokonywa w dowolnym edytorze tekstowym. Wane jest, aby
format wprowadzanej reguy by dokadnie taki jak zostao to przewidziane.

10.4. Badanie poprawnoci bazy wiedzy

Jako bazy wiedzy w istotnym stopniu decyduje o waciwym dziaaniu systemu.
Poprawno bazy moemy bada zarwno w trakcie tworzenia regu, jak i w trakcie
dziaania systemu. Podstawowe problemy wystpujce w bazach wiedzy to:
nadmierna liczba warunkw,
sprzeczno regu,
zaptlenie si regu,
pochanianie regu,
wielokrotne odwoywanie si do jednego atrybutu,
spjno.
Z nadmiern liczb warunkw mamy do czynienia wwczas, gdy dwie reguy
maj niepotrzebne warunki i obie s pochaniane przez trzeci regu. Przykadem
mog by nastpujce reguy:
(AMA,N) AND (fT4,N) AND (TSH,H) EUTYREOZA
(AMA,L) AND (fT4,N) AND (TSH,H) EUTYREOZA
przy czym atrybut AMA moe przyjmowa wartoci N normal, L low. Obie te
reguy s pochaniane przez regu:
(fT4,N) AND (TSH,H) EUTYREOZA
Dwie reguy s sprzeczne wwczas, gdy ich czci warunkowe s spenione rwnoczenie lub nie s spenione we wszystkich moliwych sytuacjach i ich czci konkluzyjne s rne dla przynajmniej jednej sytuacji. Dwie reguy s sprzeczne:
(AMA,N) AND (fT4,N) AND (TSH,H) EUTYREOZA
(AMA,N) AND (fT4,N) AND (TSH,H) SUB.NIEDOCZYNNO

120

Zestaw regu tworzy ptl, jeeli uaktywnienie tych regu jest cykliczne. Aby wykry zaptlenie regu dla badanej bazy, buduje si specjaln tabel zwan tabel zalenoci. W tabeli takiej przedstawia si zalenoci istniejce midzy reguami oraz
midzy reguami a celem do wykazania.
Jedna regua jest pochaniana przez inn regu wwczas, gdy cz warunkowa
pierwszej reguy jest speniona, jest rwnie speniona cz warunkowa drugiej reguy i czci konkluzyjne obu regu s identyczne. Na przykad regua:
(AMA,N) AND (fT4,N) AND (TSH,N) EUTYREOZA
jest pochaniana przez regu
(TSH,N) EUTYREOZA
Pochaniajce reguy daj podobny efekt jak reguy z nadmiern liczb warunkw.
Wielokrotne odwoywanie si do jednego atrybutu zachodzi wwczas, gdy
w czci warunkowej wystpuje kilka czonw zawierajcych ten sam atrybut.
W przypadku gdy odwoania s identyczne, powtarzajce warunki s zbdne i wyduaj niepotrzebnie czas wnioskowania. Natomiast w przypadku gdy nie s identyczne,
regua nigdy nie zostanie uaktywniona, poniewa atrybut nie moe jednoczenie
przyjmowa kilku wartoci, np.:
(TSH,N) AND (TSH,H) EUTYREOZA
Wielokrotne odwoywanie si do jednego atrybutu w czci wynikowej jest bdem
logicznym, stwarzajcym domniemanie wystpienia bdnego powizania atrybutu
wynikowego z jego wartoci.
Testowanie spjnoci polega na wykrywaniu regu zbdnych, sprzecznych, pochaniajcych, regu z niepotrzebnymi warunkami oraz regu zaptlonych. Nadmiarowo bazy wiedzy wystpuje wwczas, gdy pojawi si reguy zbyteczne. Dwie reguy s nadmiarowe, jeli obie ich czci warunkowe s rwnoczenie spenione we
wszystkich moliwych sytuacjach oraz ich czci konkluzyjne s identyczne, np.:
(AMA,N) EUTYREOZA
(AMA,L) EUTYREOZA
gdzie N i L przyjmuj odpowiednie wartoci [3].
Mimo e redundancja powoduje nadmiarowo bazy wiedzy, proces wnioskowania odbywa si normalnie, chocia jest wymagane przeszukiwanie wikszej liczby
regu.

10.5. Uwagi kocowe

Przedstawiony przykad bazy dedukcyjnej jest czci wikszej caoci zaprojektowanej pod nazw Laboratorium medyczne [18]. Cay system podzielony jest na
dwie czci. Pierwsz z nich jest relacyjna baza danych. Jest to kompletny model laboratorium medycznego, opracowany na podstawie prowadzonej w laboratorium dokumentacji, dotyczcej sposobw rejestracji pacjentw i bada oraz wyznaczania wy-

121

nikw. Dla poprawienia warunkw pracy zostay stworzone mechanizmy wymuszania

na uytkowniku wprowadzania poprawnych formatw danych, wyczania pewnych
funkcji w zalenoci od wykonywanych operacji, rozbudowany system obsugi bdw. Dodatkowo funkcje przegldania i edycji konkretnych informacji zostay pomylane tak, aby ich wywoanie byo moliwe na kilka sposobw w zalenoci od potrzeb uytkownika. Cz druga to cz dedukcyjna, ktrej zadaniem jest analiza
zgromadzonych danych oraz wyciganie konkretnych hipotez dotyczcych stanu
zdrowia wybranego pacjenta. W czci tej znajduj si procedury i funkcje przetwarzajce baz wiedzy. Jest to baza dotyczca stanw chorobowych tarczycy.
Wymagania sprztowo-programowe podyktowane s platform systemu operacyjnego, pod ktr pisana jest baza. W przypadku duych baz wiedzy wanym czynnikiem warunkujcym sprawne dziaanie systemu jest stosunkowo szybki dysk twardy,
poniewa istnieje bardzo czsto potrzeba odczytu pliku z reguami w trakcie procesu
wnioskowania.

122

PODSUMOWANIE
W czci III pokazano moliwoci wykorzystania przedstawionych wczeniej modeli danych w konkretnych zastosowaniach. Ze wzgldu na niezwyk uniwersalno
i popularno modelu relacyjnego nie przedstawiono konkretnej implementacji tego
modelu [20], a jedynie umiejtno wykorzystywania jzyka zapyta SQL. Niestety,
model relacyjny, tak wygodny przy oprogramowywaniu rnego rodzaju sformatowanych baz danych (np. hurtownie, magazyny itp.), nie sprawdza si w przypadku niesformatowanych baz danych. Tutaj przydatne s dedukcyjne i obiektowe bazy danych
[2]. Bazy te, oprcz standardowych zakresw typw atrybutw, maj poszerzony zakres predykatw bazowych, konstruktory umoliwiajce agregacj atrybutw. Dziki
wyraaniu wizw integralnoci za pomoc regu logiki pierwszego rzdu (bazy dedukcyjne) moliwe jest bardzo precyzyjne modelowanie powiza midzy encjami
i ogranicze wystpujcych w modelowanej rzeczywistoci. Bazy te nie maj ogranicze w modyfikowaniu regu, wizw i integralnoci. Maj wiele nowych niezwykle
przydatnych funkcji, na przykad warunkowe uaktualniania, uaktualniania hipotetyczne, czy te rekurencyjne predykaty, ktre istotnie zwikszaj zakres zastosowa.

123

BIBLIOGRAFIA
[1] Angielski S., Jakubowski Z., Biochemia Kliniczna, Perseusz, Sopot 1996.
[2] Austin D., Poznaj Oracle 8, MIKOM, Warszawa 1999.
[3] Beynon-Davies P., Systemy baz danych, WNT, Warszawa 1998.
[4] Date C.J., Twelve Rules for a Distributed Database, Comp. World, June 8, 1987.
[5] Date C.J., Wprowadzenie do baz danych, WNT, Warszawa 1983.
[6] Delobel C., Adiba M., Relacyjne bazy danych, WNT, Warszawa 1989.
[7] Gruber M., SQL Helion, Gliwice 1996.
[8] International Standards Organisation Database Language SQL.ISO/IEC 9075, 1987.
[9] International Standards Organisation Database Language SQL with integrity Enhancment ISO/IEC
9075, 1989.
[10] ISO, Basic Reference Model of Open Distributed Processing, Part 1: Overview and Guide to Use.
ISO/IEC JTC1/SC212/WG7 CD 10746-1, International Standards Organization 1992.
[11] Lustig D., Jzyk SQL dla relacyjnej bazy danych Oracle, KSW Technimex, Wrocaw 1992.
[12] Microsoft Corporation, Introduction to Programming Microsoft FoxPro 1993 (SQL Quiz).
[13] Miller T., Powell D., SQL Ksiga eksperta, Helion, Gliwice 1998.
[14] Muraszkiewicz M., Rybiski H., Bazy Danych, Akademicka Oficyna Wydawnicza RM, Warszawa
1996.
[15] Pankowski T., Podstawy baz danych, PWN, Warszawa 1992.
[16] Pawelski S., Maj S., Normy i diagnostyka chorb wewntrznych, PZW, Warszawa 1993.
[17] Pawelski S., Maj S., Normy i interpretacja bada laboratoryjnych, PZW, Warszawa 1993.
[18] Prace: Kumierski W., Dedukcyjna Baza danych modelujca laboratorium medyczne, dyplom pod
kierunkiem M. Chaon, ICT PWr.,Wrocaw 1997.
Felu T., Mrwczyski M., Obiektowo zorientowana baza danych wspomagajca zarzdzanie,
dyplom pod kierunkiem M. Chaon, ICT PWr., Wrocaw 1999.
[19] Tsichritzis D.C., Lochovsky F.H., Modele danych, WNT, Warszawa 1990.
[20] Thurrott P., Brent G., Bogdarian R., Tendon S., Arkana Delphi, RM 1998.
[21] Ullman J.D., Systemy baz danych, WNT, Warszawa 1981.

125

CZ IV
Rozproszone bazy danych

Wiele osb uznao lata dziewidziesite za er rozproszonych baz danych. Rozproszone bazy danych s bardziej skomplikowane ni scentralizowane z powodu dodatkowego czynnika komunikacji sieciowej. Mimo
rozlicznych trudnoci zwizanych z rozproszeniem wiele organizacji rozpoczo konstrukcje systemw rozproszonych baz danych.
P. Beynon-Davies

126

WPROWADZENIE
Systemy rozproszone zdaj si wyznacza naturalny kierunek rozwoju wspczesnej informatyki. Mwic o systemach rozproszonych z reguy ma si na myli system
jako cao, z infrastruktur sprztow, sieciow, systemami operacyjnymi i oprogramowaniem uytkowym. Obecnie do dobrze znane s ju zagadnienia sieci komputerowych i rozproszonych systemw operacyjnych [18, 19]. Powstaje jednak potrzeba
badania systemw rozproszonych pod ktem zarzdzania danymi oraz aktualizacji
i synchronizacji wykonywanych na nich dziaa. Do najwaniejszych zalicza si tu
problemy synchronizacji, spjnoci i rekonstruowania danych, tolerowania uszkodze,
skalowania i przezroczysto tych systemw. Wiele osb rwnie nie wyobraa sobie
prowadzenia jakiejkolwiek dziaalnoci bez takich usug, jak: poczta elektroniczna,
transmisja danych, czy korzystanie ze skarbnicy danych www. Dlatego te te problemy s wyzwaniem dla wspczesnej nauki.

127

11. ARCHITEKTURA ROZPROSZONYCH

SYSTEMW BAZ DANYCH
11.1. Uwagi oglne
Coraz waniejsze miejsce w istniejcych systemach komputerowych zajmuj systemy rozproszone [3, 6, 20]. System rozproszony (ang. distributed system) jest zbiorem samodzielnych komputerw wraz z urzdzeniami peryferyjnymi, poczonych za
pomoc sieci, na ktrych zainstalowane jest rozproszone oprogramowanie systemowe.
Uytkownicy takiego systemu powinni go odbiera jako jedno zintegrowane rodowisko. Fakt rozproszenia powinien by tu niezauwaalny. Do zainteresowania si systemami rozproszonymi przyczyni si midzy innymi szybki rozwj sieci rozlegych,
asynchronicznych sieci ATM i upowszechnienie czy satelitarnych, co pozwolio na
budow systemw o niespotykanym dotychczas zasigu. Pojawiy si projekty tworzenia oglnokrajowych infostrad, czyli sieci o duej przepustowoci i zasigu, ktrych trzon stanowi rozproszone systemy danych. Rwnie cige denie do efektywnego wykorzystania systemw w przedsibiorstwach wymusio powstawanie
nowej klasy programw uytkowych wielkiej skali. S to tzw. systemy komputeryzacji przedsiwzi (ang. enterprise computing systems), w ktrych najwikszy nacisk
kadzie si na wysoki stopie integracji i niezawodnoci, czyli na zachowanie spjnoci
systemw niezalenie od miejsca i sposobu dostpu, oraz szybkie wykrywanie i usuwanie
pojawiajcych si w nich awarii. Systemy takie musz by dostpne dla uytkownikw
pracujcych na rnym sprzcie, ktrych mog dzieli znaczne odlegoci.
Potencjalna gama zastosowania systemw rozproszonych jest bardzo szeroka. Due koncerny posiadajce swoje oddziay w wielu krajach, giedy, banki, linie lotnicze
opieraj swoje dziaanie na posiadaniu rozproszonego systemu komputerowego. Badania nad systemami rozproszonymi prowadzone s od wielu lat midzy innymi
w Queen Mary and Westfield College, University of London, University of Berkeley,
Cambridge University, Newcastle University. Badania niezalene prowadzone s
przez wiele firm komputerowych, w tym Sun Microsystems, Xerox PARC, Informix,
ktre implementuj mechanizmy systemw rozproszonych w swoich produktach.
Pierwsze prace badawcze nad systemami rozproszonymi pojawiy si na pocztku lat
siedemdziesitych. Wwczas to zosta opracowany przez Xerox PARC projekt serwera plikw oraz opracowany przez Cambridge system oparty na puli procesorw.
Prawdopodobnie pierwszy komercyjny system rozproszony powsta w 1980 roku
w firmie Apollo Computers. W swej najwikszej konfiguracji czy on 1800 stacji

128

roboczych. Wspczesne systemy rozproszone [1, 10, 21], to znaczy systemy otwarte,
skalowane, tolerujce uszkodzenia, pojawiy si w poowie lat osiemdziesitych wraz
z systemami UNIX BSD 4.2+ opracowanym przez Sun Microsystem oraz Mach opracowanym w Carnegie-Mellon University, bdcymi jdrem systemu operacyjnego dla
systemw rozproszonych. Powstanie wydajnych systemw sieciowych oraz rozproszonych systemw operacyjnych dao moliwo budowania rozproszonych systemw
baz danych. Podstaw tych systemw stanowi specjalizowane serwery baz danych,
majce moliwo wymiany danych z innymi serwerami.

11.2. Podstawowe wasnoci

rozproszonego systemu baz danych
Rozproszony system baz danych to zbir lokalnych baz danych stanowicych cao w sensie jednego modelu danych i koordynacji wykonywanych transakcji.
W zalenoci od przedmiotu rozproszenia wyrniamy rozproszenie pod wzgldem
funkcji oraz danych [3, 10]. Mwic o rozproszeniu funkcji mamy na myli separacj
funkcjonaln midzy danymi i mechanizmami zarzdzania nimi, czyli serwerem
a aplikacjami uytkownikw, ktre pobieraj wymagane dane poprzez wysyanie do
serwera zapyta. Model obrazujcy separacj to znany model klientserwer. W przypadku rozproszenia danych mamy do czynienia z ich rozlokowaniem na rnych serwerach, czsto oddalonych od siebie. Na og jednak ma miejsce zarwno rozproszenie funkcji, jak i danych. O uytecznoci rozproszonych baz danych decyduj
nastpujce cechy: wspdzielenie zasobw, otwarto, wspbieno, skalowalno,
przezroczysto, tolerowanie uszkodze.
Wspdzielenie zasobw jest pojciem bardzo szerokim. Dotyczy zarwno zasobw sprztowych, jak i oprogramowania. W przypadku baz danych najbardziej istotna
jest moliwo wspdzielenia danych. Pozwala ona bowiem na wspdzielenie narzdzi pracy, takich jak programy komputerowe, i danych opracowanych przez poszczeglnych uytkownikw systemu. Umoliwia to tworzenie systemw wspomagania
pracy zespoowej CSCW (ang. Computer Supported Cooperative Working), gdzie
chyba najbardziej uwydatnia si wspzaleno uytkowania wsplnych danych
w rnych stacjach roboczych. Systemy CSCW znajduj zastosowanie w pracach grup
projektowych i systemach zdalnego nauczania. Aby z danego zasobu mogo korzysta
wielu uytkownikw, musi zosta zorganizowany odpowiedni sposb dostpu do niego. System rozproszony moemy zatem przedstawi jako zbir zarzdcw zasobw
i zbir korzystajcych z nich aplikacji. W oparciu o takie abstrakcyjne przedstawienie
systemu buduje si dwa modele. Pierwszy z nich to najbardziej obecnie znany i stosowany model klientserwer, drugi to model oparty na obiektach (nie myli
z obiektowymi bazami danych) [14]. Jest on uwaany za bardzo obiecujcy, lecz pozostaje wci w fazie eksperymentw.

129

Otwarto systemu okrela moliwo dokonania jego rozbudowy o nowe zbiory

danych dzielonych. Rozbudowa ta nie wymaga rekonfigurowania systemu czy przeprojektowania istniejcych ju zbiorw, ani modyfikacji aplikacji klientw. Dobrym
przykadem implementacji otwartoci systemu jest Informix Universal Server (IUS)
[2, 7, 12]. Ciekawym mechanizmem zawartym w tym produkcie jest moliwo
wprowadzania wasnych typw danych oraz definiowanie dla nich funkcji i operatorw. S to tak zwane moduy DataBlade, ktre s doczane do serwera na etapie jego
konfigurowania i staj si jego integraln czci [9]. S na tym samym poziomie co
typy wbudowane i mog by wykorzystywane we wszystkich umieszczonych na serwerze bazach danych [4].
Wspbieno w systemach rozproszonych pojawia si jako naturalna konsekwencja jednoczesnej pracy wielu uytkownikw. Rwnoczenie mamy tu do czynienia ze zjawiskiem rwnolegoci. Procesy uytkownikw dziaaj jednoczenie
w rnych systemach komputerowych. Najwikszy i najpowaniejszy problem dotyczy synchronizacji dostpu do danych wspdzielonych. Jest on zasadniczo rozwizywany za pomoc kolejkowania dostpw dzielonych, lecz mechanizm kolejkowania
nie rozwizuje problemu aktualnoci danych. Bardzo ciekawy sposb realizacji
wspbienoci w systemach zarzdzania bazami danych jest zawarty w architekturze
Informixa. Do realizacji obsugi zada pochodzcych od wielu klientw serwer tworzy
automatycznie tzw. wirtualne procesory [2].
Zdolno systemu do zmiany rozmiarw bez koniecznoci modyfikacji systemu
wyjciowego okrela si jako skalowalno systemu. Problemy zwizane ze skalowaniem pojawiaj si gwnie w oszacowaniu zakresu wielkoci przetwarzanych danych
i sposobie ich adresacji. Przeszacowanie prowadzi bowiem do marnowania pamici
oraz do zwikszenia nakadw systemowych do przetwarzania danych. Niedoszacowanie moe prowadzi do unieruchomienia caego systemu i potrzeby modyfikacji
wielu tabel. Problem skalowalnoci od lat jest tematem wielu bada. Prbuje si rnych rozwiza polegajcych na stosowaniu danych zwielokrotnionych, uyciu pamici notatnikowej (podrcznej), zwielokrotnienie serwerw przez ich replikacje itp.
Przezroczysto systemu to ukrywanie przed uytkownikami odrbnoci skadowych systemu i przedstawianie go jako integraln cao. Przezroczysto dostpu
oznacza, e dostp do danych, zarwno lokalnych, jak i odlegych, jest moliwy za
pomoc tych samych dziaa. Przezroczysto pooenia umoliwia dostp do danych
bez znajomoci ich faktycznej lokalizacji. Przezroczysto wspbienoci pozwala
wielu procesom na niezakcone operowanie na tych samych obiektach informacji.
Przezroczysto zwielokrotniania umoliwia uycie wielu kopii obiektw danych
w celu zwikszenia niezawodnoci i wydajnoci systemu bez wiedzy uytkownikw
o istniejcych obiektach i o tym, czy pracuj na oryginale, czy na kopii. Przezroczysto awarii ukrywa przed uytkownikami pojawiajce si uszkodzenia w systemie
i umoliwia programom uytkowym koczenie zada. Przezroczysto przemieszczania okrela zdolno przemieszczania obiektw informacji wewntrz systemu bez

130

wpywu na dziaanie uytkownikw. Przezroczysto wydajnoci pozwala na rekonfigurowanie systemu w celu poprawienia jego wydajnoci przez zmian rozoenia obcienia systemu. Przezroczysto skalowania pozwala na zmian skali systemu bez
zmiany jego struktury i algorytmw uytkowych.
Szczeglnie istotnym zagadnieniem rozproszonych systemw jest zapewnienie
spjnoci danych w przypadku wystpienia awarii systemu. Aby to uzyska, stosuje
si metod redundancji sprztowej. Uywa si nadmiarowych elementw systemu lub
odtwarzania programowego, czyli stosuje programy usuwajce skutki uszkodze.
Z punktu widzenia danych, redundancja sprztowa suy do utrzymywania dodatkowej kopii danych na rnych nonikach. Oprcz obsugi zwierciadlanej (ang. disc
mirroring) dyskw stosuje si replikacj danych. Wie si to jednak z uruchomieniem dodatkowego serwera baz danych.

11.3. Cele projektowe dla baz rozproszonych

W rozproszonych systemach baz danych strategiczne znaczenie ma spjno, niezawodno i bezpieczestwo. Bez zapewnienia dostatecznego ich poziomu, rozproszone bazy staj si praktycznie nieuyteczne. Jednym z najwaniejszych elementw
projektowych jest wprowadzenie do systemu baz danych jednolitego sposobu nazywania wspdzielonych zasobw. Chcc zyska dostp do zasobu naley poda jego
identyfikator. Zwykle dla wygody uytkownikw, aby uatwi dostp, wprowadza si
nazwy niosce jakie znaczenie (np. www.gazeta.com). Jednake programy odwoujce si bezporednio do zasobw (np. przegldarki stron www w Internecie) stosuj
inny, czsto numeryczny identyfikator. W przypadku Internetu podawany jest czteroczciowy adres komputera macierzystego (ang. host identifier), ktry przykadowo
moe mie posta 192.123.123.123 oraz numer portu (ang. port number), bdcy liczb cakowit okrelajc konkretny port komunikacyjny. Z powodu istnienia dwch
sposobw identyfikowania zasobw, innego dla uytkownika i innego dla aplikacji,
naley zapewni mechanizm tumaczenia nazwy. Najczciej stosuje si do tego bazy
danych, w ktrych przechowuje si nazwy wraz z odpowiadajcymi im adresami komunikacyjnymi. Czsto si zdarza, e tumaczenie odbywa si wielopoziomowo. Po
kadym kroku otrzymywany jest adres niszego rzdu. Taka sytuacja ma miejsce np.
w przypadku nazw hierarchicznych. Tumaczenie nazw trwa a do otrzymania nazw
elementarnych. Ustalenie zalenoci midzy nazw i zasobem, na ktry nazwa wskazuje, nazywa si wizaniem. Zwykle nazwy s wizane z atrybutami, bdcymi adresami nazywanych obiektw. Utrzymanie i zarzdzanie bazami danych wiza pomidzy nazwami i atrybutami zasobw okrela si jako usugi nazewnicze. W Internecie
usugi te realizowane s przy wykorzystaniu specjalizowanych serwerw DNS (ang.
Domain Name System) GNS (ang. Global Name System) oraz X500 (standard usug
katalogowych) zawierajcych bazy danych pozwalajce na tumaczenie nazw. Potrze-

131

ba kontekstowego tumaczenia nazw jest bardzo istotna. Odwoanie do konkretnej

tabeli w bazie danych ma sens tylko wtedy, gdy zostanie podana nazwa bazy, a czsto
take serwera. Inaczej mwic, ta sama nazwa w zalenoci od uytego kontekstu
moe okrela inny zasb wspdzielony. Usugi nazewnicze zarzdzaj bazami danych w kadym z kontekstw oraz staraj si zapewni jak najbardziej aktualny stan
nazw i ich odwzorowa na inn przestrze nazw. Utrzymanie spjnoci tych baz ma
zasadnicze znaczenie dla komunikacji w rozproszonym systemie. Projektowanie systemw komunikacji daje podstawy do tworzenia otwartych systemw rozproszonych.
Dwa podstawowe systemy komunikacji to klientserwer i rozsyanie grupowe. Komunikacja typu klientserwer jest ukierunkowana na dostarczanie usug. Zakada przesyanie dwch komunikatw: zamwienia i odpowiedzi. W przypadku rozsyania grupowego komunikat jest przesyany do okrelonej grupy procesw.
W rozproszonych systemach baz danych fundamentaln form oprogramowania
stanowi serwery baz danych. Od ich jakoci zaley potencjalna uyteczno budowanych baz danych. Idea serwera pozwala na tworzenie systemw otwartych, gdy do
posiadanej bazy danych mona dodawa nowe aplikacje bez koniecznoci modyfikowania istniejcych aplikacji. Dodatkowym wymogiem dla rozproszonych baz danych
jest potrzeba swobodnej wymiany danych pomidzy wieloma serwerami baz danych.
Serwery powinny by rwnie wyposaone w system replikacji danych, pozwalajcy
na prowadzenie lustrzanych serwerw baz danych.

11.4. Modele danych dzielonych i transakcji rozproszonych

11.4.1. Fragmentacja i replikacja danych
W rozproszonych systemach baz danych wystpuje rozoenie danych poprzez ich
fragmentacj lub replikacj do rnych konfiguracji sprztowych i programistycznych
umieszczonych w rnych wzach sieci, zwykle rnych geograficznie miejsc. Rozproszenie pozwala przede wszystkim na odwzorowanie struktur organizacji, dla ktrej
system zosta zaprojektowany, umoliwia wiksz kontrol nad danymi w miejscu ich
wprowadzania i uytkowania. Rozproszenie uzyskane przez replikacj zwiksza niezawodno systemu, pozwala zapewni cig prac w przypadku wystpienia awarii
jednego z serwerw, poprawia dostpno systemu i pozwala na odcienie czy
w przypadku znacznie oddalonych od siebie wzw sieci. Dobrze zaprojektowana
fragmentacja moe znacznie podnie wydajno systemu. Obok niewtpliwych zalet
rozproszone bazy maj cay szereg wad. Katalog systemowy takiej bazy musi zawiera dodatkowo informacje o rozmieszczeniu fragmentw bazy oraz o sposobie replikacji. Znacznie bardziej jest skomplikowane sterowanie wspbienoci aktualizacji
danych, testowanie systemu rozproszonego i odszukanie przyczyn ewentualnych nieprawidowoci. Ide fragmentacji ilustruje rys. 11.1. Ten sposb podziau danych po-

132

zwala na skrcenie czasu odpowiedzi poprzez moliwo wykonywania operacji wyszukiwania, aktualizacji i innych jako rwnolegych procesw, osobno dla kadego
fragmentu tabeli.

KLIENT

KLIENT

KLIENT

Tabela
z perspektywy
aplikacji

fragment x
fragment y
Tabela
z perspektywy
serwera

fragment z

fragment x

Dysk 1

fragment z

Dysk 2

fragment y

Fizyczne
rozmieszczenie
tabeli

Dysk 3

Rys. 11.1. Idea fragmentacji danych w IUS

W przypadku duych, czsto uywanych tabel mona zmniejszy wspzawodnictwo o dostp do danych rozmieszczajc je w kilku osobnych fragmentach usytuowanych na rnych nonikach danych. Gdy jeden z fragmentw staje si niedostpny, np.
na skutek awarii dysku, uytkownicy mog nadal swobodnie korzysta z danych zawartych w pozostaych, dostpnych fragmentach tabeli. Poprzez fragmentacj tabeli
mona wykona jej kopi zapasow oraz odzyskiwa z niej dane w sposb rwnolegy, skracajc w ten sposb czas realizacji operacji. Mona wyrni fragmentacj
poziom i pionow. Fragmentacja pozioma to podzbir zbioru wierszy tabeli wyselekcjonowanych wedug okrelonych wartoci klucza, odpowiadajca operacji SELECT.
Odtworzenie stanu pierwotnego, sprzed fragmentacji, wykonuje si korzystajc z operacji UNION. Fragmentacja pionowa stanowi podzbir zbioru kolumn tabeli, stanowicy okrelony zbir cech opisywanego obiektu bazy. Powstaje dziki operacji rzutowania PROJECT, a stan pierwotny uzyskuje si poprzez operacj zczania JOIN
kolumn w oparciu o wartoci klucza gwnego.

133

W oglnym ujciu replikacja danych to proces reprezentowania obiektw bazy

w wicej ni jednym miejscu. Moe zatem suy do tworzenia lokalnych kopii w celu
zwikszenia bezpieczestwa systemu lub opracowania raportw bez dostpu do
wszystkich danych zawartych w bazie. Replikacji moe zosta poddana jedynie cz
bazy danych. Schemat systemu z replikacj danych pokazano na rys. 11.2.
KLIENT

KLIENT

SERWER
nadrzdny

replikacja

SERWER
podrzdny

KLIENT

KLIENT

Klient z prawem do modyfikacji danych

Klient z prawem wycznie do odczytu

Rys. 11.2. Schemat systemu z replikacj danych

KLIENT

KLIENT

SERWER
nadrzdny

KLIENT

replikacja

SERWER
podrzdny

KLIENT

Klient z prawem do modyfikacji danych

Klient z prawem wycznie do odczytu

Rys. 11.3. Przeczanie klientw po awarii serwera nadrzdnego

Mechanizm replikacji danych zosta zaimplementowany w IUS gwnie w celu

zapewnienia mechanizmw przetwarzania tolerujcego uszkodzenia. Wymagane jest
tu zastosowanie serwera nadrzdnego i podrzdnego (ang. primary, secondary server).
Wszystkie operacje wykonywane na danych zgromadzonych w serwerze nadrzdnym
s replikowane i automatycznie odwieane na serwerze podrzdnym. Replikacja od-

134

bywa si tylko w jednym kierunku od serwera nadrzdnego do podrzdnego. Narzuca to pewien wymg, e klienci korzystajcy z serwera podrzdnego mog wykonywa operacje wycznie w trybie odczytu. W przypadku awarii serwera nadrzdnego
nastpuje przeczenie klientw do serwera podrzdnego (rys. 11.3) w sposb automatyczny lub rczny, zalenie od ustawienia pewnych parametrw w pliku konfiguracyjnym.
Korzyci wynikajc z zastosowania replikacji jest, obok zabezpieczenia przed
utrat danych, odcienie czy i serwera nadrzdnego od obsugi klientw z prawem
dostpu wycznie do odczytu. Odcienie czy jest szczeglnie widoczne wtedy, gdy
grupa klientw czy si do serwera z duej odlegoci. Tego typu sytuacje spotyka si
w Internecie. W celu uniknicia czstych, odlegych pocze stosuje si repliki popularnych serwerw (tzw. serwery lustrzane) zlokalizowane po stronie odlegych klientw.

11.4.2. Hurtownie danych

Tradycyjne systemy baz danych su do biecego rejestrowania stanu obiektw,
ich zmian oraz pozwalaj na szybkie dostarczanie informacji. S to tzw. operacyjne
bazy danych. Przykadem takiej bazy moe by rozproszony system baz danych sucy do rejestrowania wielu czynnikw pogodowych na danym obszarze, jak: cinienie
atmosferyczne, wielko opadw, temperatura powietrza, sia wiatru itp. W kadym
wle systemu zbierane s dane dotyczce wycznie pewnego obszaru. Dziki zastosowaniu rozproszonego sytemu moliwe jest odtworzenie stanu pogody na danym
terenie z dowolnego wza systemu.
Oprcz operacyjnych systemw coraz wiksze znaczenie zaczynaj mie analityczne systemy baz danych tworzone w postaci hurtowni danych. Celem ich jest okrelenie pewnych trendw i wzorcw zachowa okrelonych obiektw danych. W oparciu o te systemy budowane s systemy wspomagajce podejmowanie decyzji. Operuj
one na danych historycznych uzyskiwanych z operacyjnych baz danych, pozwalaj na
aproksymacj zachowa obiektw danych zawartych w bazie. Mona zaproponowa
budow systemu analitycznego do prognozowania zachowa czynnikw pogodowych,
opracowania modeli klimatu na obszarze dziaania systemu, czy szacowania stanu
rzeki na podstawie danych o stanie i zmianach pogody na okrelonym obszarze. Jak
wida z tego przykadu, do tworzenia hurtowni danych wyjtkowo uyteczne s systemy rozproszone. Gromadz one w sposb lokalny dane zgodnie z miejscem ich
uytkowania. Do prowadzenia natomiast globalnej analityki rejestrowanych procesw dane mog by pobierane ze wszystkich lokalnych wzw systemu. Aby hurtownia speniaa kryteria analitycznej bazy, powinna wykazywa nastpujce wasnoci:
integracj w sensie jednolitego sposobu kodowania informacji, stosowania jednolitych formatw pl, identyfikacji obiektw,

135

orientacj tematyczn informacje o obiektach jednego typu mog pochodzi

z rnych rde,
nieulotno dane raz wprowadzone do hurtowni nie ulegaj modyfikacji, s
tylko odczytywane,
orientacj czasow dane w hurtowni maj charakter historyczny i musi by im
nadany identyfikator czasowy.
Informacje do hurtowni pochodz z lokalnych serwerw i zwykle s poddawane
agregacji w celu wstpnego wyliczenia pewnych miar wykorzystywanych w pniejszych analizach. Skadowane w hurtowni informacje s zwykle poddane wczeniejszej
obrbce, np. przez wyliczenie rednich, i dopiero one zapisywane s do bazy analitycznej. To wstpne przetwarzanie danych pozwala przyspieszy czas wykonywania
analiz. Tworzenie analitycznych systemw baz danych jest czsto jednym z priorytetowych czynnikw uzasadniajcych budowanie rozproszonych systemw baz danych.

11.4.3. Transakcje
W celu zapewnienia spjnoci danych dzielonych i rozproszonych podczas operowania na nich naley stosowa operacje niepodzielne, czyli transakcje. Aby mogy
istnie operacje niepodzielne, serwer musi mie mechanizmy wzajemnego wykluczania. Zwykle s to zamki (ang. mutex) i blokady (ang. lock). Pojawia si zatem problem
synchronizacji i harmonogramowania zamwie klientw. Mog powsta takie sytuacje, w ktrych operacja zapocztkowana przez jednego klienta nie moe by zakoczona do czasu wykonania operacji przez innego klienta. Taka sytuacja niesie ze sob
niebezpieczestwo powstania zakleszcze (ang. deadlock). Mwic o operacjach niepodzielnych w kontekcie systemw baz danych mamy na myli sytuacje, w ktrych
skutek wykonania dowolnej operacji jest niezaleny od operacji wykonywanych
wspbienie. Transakcje mog posiada wasne zbiory transakcji, co pozwala na hierarchizacj wykonywanych operacji. Takie transakcje okrela si jako zagniedone.
Pozwalaj one na dodatkow wspbieno, gdy operacje na tym samym poziomie
zagniedenia mog by wykonywane jednoczenie. Wykonywanie operacji na danych wielodostpnych wymaga zagwarantowania waciwego sterowania wspbienoci. Dopuszcza si wspbienie wykonywane transakcje, pod warunkiem, e skutki ich wykonania bd takie same jak gdyby zostay wykonane po kolei. Takie
transakcje okrela si jako rwnowane szeregowo. Mechanizmy pozwalajce na
osignicie rwnowanoci szeregowej, to: blokowanie, optymistyczne sterowanie
wspbienoci, zastosowanie znacznikw czasu. W razie blokowania na kady
obiekt zostaje zaoona blokada przez pierwsz sigajc do niego transakcj. Dopki
blokada nie zostanie usunita, adna inna transakcja nie ma moliwoci modyfikowania zablokowanych danych. Mechanizm blokowania jest bardzo zoony [16].
Przy optymistycznym sterowaniu wspbienoci zakada si, e transakcje s
rozdzielone, to znaczy nie wystpuj adne konflikty pomidzy nimi. Takie zaoenie

136

jest czsto prawdziwe i znacznie przyspiesza cay proces realizacji zamwie aplikacji
klientw. Gdy jednak dochodzi do konfliktu pomidzy transakcjami, naley zaniecha
ich wykonywania i ponowi prb po pewnym czasie [16].
Mechanizm uycia znacznikw czasu polega na nadawaniu transakcjom etykiet
z niepowtarzalnymi znacznikami. Zawarto etykiet oznacza pozycj transakcji
w cigu czasowym, co pozwala na cakowite uporzdkowanie zamwie pochodzcych od transakcji w kolejnoci zgosze.
Transakcje realizowane na wielu serwerach bazy danych jednoczenie okrelane s
jako transakcje rozproszone. Do ich wykonania potrzebne s wielofazowe protokoy
zatwierdzajce. Jednym z podstawowych zada protokow zatwierdzajcych jest, by
w razie wystpienia bdw podczas realizacji transakcji rozproszonej zagwarantowa
spjno danych. Aby to byo moliwe, protok musi mie odpowiedni mechanizm
obsugi bdw.

11.5. Rekonstruowanie danych

W rozproszonych systemach baz danych szczeglnie du uwag naley zwrci
na poprawno wykonywanych operacji w celu zagwarantowania spjnoci danych.
Jest to zadanie bardzo trudne, poniewa w przypadku systemw rozproszonych zwielokrotnieniu ulegaj punkty potencjalnych miejsc awarii. Naley wic zapewni odpowiedni mechanizm gwarantujcy odtworzenie stanu obiektw danych w razie wystpienia awarii serwera. Najpowszechniejsz metod stosowan do rekonstruowania
przebiegu transakcji jest wykorzystanie pliku rejestru zwanego plikiem rekonstrukcji.
Jest to metoda dobra, ale moliwa do zastosowania jedynie w systemach, w ktrych
nie wymaga si natychmiastowej odpowiedzi, gdy metoda ta jest stosunkowo wolna.
W celu implementacji tworzony jest zarzdca rekonstrukcji, ktry powinien by odporny na uszkodzenia wasnego pliku rekonstrukcji. Odporno realizuje si przez
zwielokrotnienie pliku rekonstrukcji na wielu trwaych nonikach danych. Aby umoliwi przebieg rekonstrukcji, kady serwer baz danych musi rejestrowa histori
zmian modyfikowanych obiektw danych. W tym celu tworzy list zamiarw, dla
wszystkich aktualnie dziaajcych transakcji, na ktrych zawarte s nazwy i kolejne
wartoci obiektw danych modyfikowanych przez transakcje. Lista ta jest wykorzystana przez serwer po zakoczeniu transakcji w celu identyfikacji modyfikowanych
obiektw danych oraz usunicia tymczasowych wersji danych. W pliku rekonstrukcji
dodatkowo przechowywana jest informacja o stanie kadej transakcji oraz o skojarzeniu odpowiedniego obiektu danych z odpowiedni transakcj. Sposb operowania na
pliku jest rny w rnych serwerach baz danych. Kady obiekt danych ma jednoznaczny identyfikator, dziki czemu kolejne wersje obiektu danych w plikach rekonstrukcji s kojarzone z danymi w serwerze. Po wystpieniu awarii i wznowieniu prawidowego funkcjonowania, serwer wykrywa potrzeb uruchomienia mechanizmu

137

rekonstrukcji. W celu optymalizacji czasu procesu rekonstrukcji trzeba okresowo reorganizowa plik rejestru. Informacj potrzebn do odtworzenia stanu obiektw danych jest kopia wszystkich zatwierdzonych wersji obiektw danych. W praktyce tworzy si nowy plik rejestru, w ktrym umieszczone s kopie wszystkich zatwierdzonych
obiektw danych oraz informacje o stanach i listy zamiarw transakcji jeszcze nie
zakoczonych. Taka operacja pozwala na znaczne zmniejszenie zapotrzebowania na
pami i w istotny sposb wpywa na skrcenie czasu wykonywania rekonstrukcji
bazy danych.

11.6. Bezpieczestwo w rozproszonych systemach baz danych

Podczas konstruowania rozproszonych systemw baz danych napotyka si na
sprzeczno, gdy z jednej strony naley dy do najwikszej otwartoci tych systemw, z drugiej otwarto pociga za sob wiksze prawdopodobiestwo nielegalnego
dostpu do systemu. Wrd zagroe na jakie jest wystawiony system wystpuj:
przecieki uzyskanie poufnej informacji przez nieupowanionych do tego odbiorcw,
naduycia zmiana wartoci obiektw przez osoby lub aplikacje do tego nieupowanione,
kradzie zasobw uytkowanie zasobw bez uprawnie,
wandalizm zaburzenie prawidowego funkcjonowania systemu bez jakichkolwiek korzyci dla sprawcy.
Najtrudniejsze do wykrycia, a zarazem najgroniejsze dla systemu s przecieki
i naduycia. Wandalizm jest powszechnie spotykany w Internecie, gdzie czsto dochodzi do podmienienia stron www na inne. W systemach rozproszonych komputery
s poczone w sie i wyposaone w systemy operacyjne posiadajce standardowy
interfejs komunikacyjny. Pozwala to na utworzenie kanaw komunikacyjnych. Naruszenie bezpieczestwa polega na uzyskaniu dostpu do takiego kanau lub przejciu
go od osoby uprawnionej. W systemach rozproszonych jest to o tyle atwiejsze, e
w celu zapewnienia wikszej niezawodnoci niektre kanay komunikacyjne s zwielokrotnione. Wrd metod przejmowania kanaw komunikacyjnych wyrnia si:
podsuch odbieranie kopii komunikatw bez upowanienia,
kamufla podszywanie si pod innego uytkownika,
faszowanie komunikatw zmiana treci komunikatw,
powtarzanie starych komunikatw wysyanie komunikatw w pniejszym czasie.
Wikszo atakw na system rozproszony pochodzi od legalnych uytkownikw.
Ataki mog polega na prostym mechanizmie usiowania odgadywania hasa uytkownika a do bardziej wyrafinowanych form, jak wirusy komputerowe, robaki sieciowe, czy metoda konia trojaskiego. Wirusy komputerowe znane ze rodowiska
komputerw osobistych w systemach rozproszonych maj znacznie szersze pole dziaania i stanowi potencjalnie wiksze zagroenie. Przy pomocy komunikacji sieciowej

138

ulegaj samoreprodukcji i powielaniu na kolejne czci systemu rozproszonego. Robak ma moliwoci zdalnego uruchamiania procesw w systemie. Jest on zwykle jednym z narzdzi administratora systemu, ale wykorzystany w niewaciwy sposb
przez nielegalnego uytkownika stanowi doskonae narzdzie ataku. Metoda konia
trojaskiego polega na wprowadzeniu programu-puapki, ktry pozornie wykonuje
poyteczne czynnoci, lecz faktycznie suy nielegalnemu przechwytywaniu informacji.
Wrd mechanizmw obrony przed niepowoanym dostpem wyrnione zostay:
kryptografia, uwierzytelnienie i kontrola dostpu. Zastosowanie kryptografii w celu
szyfrowania danych pozwala na utajnienie poufnych informacji w fizycznych kanaach komunikacji lub przy skadowaniu w pamici trwaej, gdzie s naraone na podsuch czy faszowanie. Kryptografia pozwala rwnie na wspomaganie mechanizmu
uwierzytelnienia, gdy zaszyfrowana informacja wedug okrelonego klucza moe
zosta odszyfrowana tylko przez odbiorc znajcego odpowiedni klucz. Gdy odbiorca
otrzyma informacj, ktrej nie jest w stanie we waciwy sposb odczyta, zachodzi
podejrzenie, e nadawca nie by upowaniony do jej wysyania. Dziki kryptografii
wprowadzono cyfrowe podpisy, ktrymi oznacza si np. obiekty danych. Istnienie
podpisu cyfrowego pozwala okreli, na zasadzie zblionej do sumy kontrolnej, czy
do odbiorcy dociera oryginalna, czy te zmieniona posta informacji. Uwierzytelnienie jest natomiast podstaw metody identyfikacji serwerw i klientw. Kontrola dostpu oznacza udzielenie dostpu do wszelkich zasobw wycznie tym grupom uytkownikw, ktre maj przyznane prawa na okrelonym poziomie hierarchii.
Wikszo mechanizmw zabezpieczenia systemw rozproszonych musi by implementowana na poziomie sprztu lub systemu operacyjnego. Jednake sam serwer baz
danych musi rwnie zapewnia moliwo ograniczenia dostpu do zasobw.
W przypadku IUS na poziomie jzyka SQL mona nadawa i odbiera prawa dostpu
(instrukcje GRANT i REVOKE) do baz danych i pojedynczych tabel. W konfiguracji
serwera okrela si uytkownikw, ktrzy bd mieli dostp do baz danych na danym
serwerze. Dane s przechowywane przez serwer w specjalnie sformatowanym zabezpieczonym obszarze dysku (ang. sbspace), ktry nie jest standardowym systemem
plikw, co ogranicza moliwo niepowoanego odczytania tego obszaru. Dodatkowo
serwer zapewnia metody ledzenia wszystkich akcji uytkownikw, zapisujc kiedy
i przez kogo zostay podjte i na ktrym obiekcie danych. Innym ze sposobw zabezpieczenia jest oprogramowanie separujce system lub jego fragmenty rozgraniczajce
pewne zasoby systemowe jak i sprztowe. Stosuje si zapory ogniowe (ang. firewall)
i serwery poredniczce (ang. proxy server).
Aby skutecznie chroni dane i cay system, naley okreli polityk bezpieczestwa
oraz mechanizmy bezpieczestwa pozwalajce na implementacj przyjtej polityki.

139

11.7. Architektura IUS

Jako przykad narzdzia do realizacji rozproszonych systemw baz danych posuy
serwer IUS [2, 4, 9, 12, 13]. Architektura IUS jest okrelana jako obiektowo-relacyjna.
Jej podstaw stanowi dwie waciwoci: rozszerzalno i dynamiczna skalowalno.
Przez rozszerzalno rozumiana jest tu moliwo dodawania do serwera nowych
elementw, jak wasne typy danych, funkcje operujce na nich (w tym istnieje moliwo definiowania wasnych operatorw logicznych dla nowych typw danych) oraz
metod dostpu do danych. Rozszerzenia tego typu w postaci tzw. moduw DataBlade
s doczane do serwera. Charakterystycznym przykadem stosowania moduw
DataBlade jest wprowadzenie typu danych dwikowych, video i zdefiniowanie funkcji operujcych na nich. Dynamicznie skalowalna architektura (ang. Dynamic Scalable
Architecture DSA) oznacza zdolno do skalowania zasobw w zalenoci od zapotrzebowania zgaszanego przez aplikacje. Jest to moliwe szczeglnie przy wykorzystaniu symetrycznych wieloprocesorowych systemw komputerowych (ang. Symmetric
Multiprocessing Computer Systems SMPs). Moliwa jest wwczas rwnolega praca
wielu procesorw dla pojedynczego zadania klienta. Podstaw dynamicznie skalowanej architektury IUS stanowi procesory wirtualne (ang. virtual processor). Daj one
moliwo dzielenia przetwarzania oraz oszczdno pamici i zasobw systemu.
Jedn z podstawowych korzyci pyncych z wykorzystania procesorw wirtualnych
jest moliwo przetwarzania rwnolegego. W niektrych dziaaniach (rys. 11.4)
procesory wirtualne z klasy CPU (jednostki centralnej) pozwalaj na utworzenia wielu
indeksowanie
sortowanie
odzyskiwanie

KLIENT

PROCESORY WIRTUALNE

CPU1

CPU2

CPU3

CPU4

Rys. 11.4. Przetwarzanie rwnolege dla pojedynczego klienta

z wykorzystaniem procesorw wirtualnych

wtkw dziaajcych rwnolegle dla pojedynczego klienta. Jest to moliwe w operacji

indeksowania, sortowania, odzyskiwania, przeszukiwania, czenia, agregacji i gru-

140

powania. Zastosowania przetwarzania rwnolegego w tych operacjach powoduje

skrcenie czasu realizacji poszczeglnych zada, a co za tym idzie skrcenie czasu
odpowiedzi na pytania uytkownika. Dziki zastosowaniu procesorw wirtualnych
serwer potrafi obsugiwa w sposb rwnolegy operacje na tabelach poddanych
fragmentacji. Do operacji na kadym fragmencie mona utworzy osobny procesor
wirtualny.
Procesory wirtualne wykorzystuj pami dzielon przy operowaniu na danych
wsplnie wykorzystywanych oraz do szybkiej komunikacji midzy sob. Do harmonogramowania przetwarzania jednoczenie realizowanych wtkw IUS stosuje kolejki. Kontrola wspbienoci jest realizowana z wykorzystaniem zamkw i blokad. Do
zapewnienia spjnoci danych zapisywanych w pamici staej i dzielonej serwer stosuje znaczniki czasu. Oprcz nich wykorzystuje si rwnie mechanizm sekcji krytycznej oraz punktw kontrolnych.

11.8. Uwagi kocowe

Miar jakoci i przydatnoci projektowanych systemw rozproszonych baz danych
s ich podstawowe wasnoci: wspdzielenie zasobw, otwarto, wspbieno,
skalowalno, przezroczysto i tolerowanie uszkodze. Od doboru rozwiza technicznych zwizanych z projektowaniem rozproszonych systemw baz danych zaley
stopie osignicia podstawowych wasnoci tych systemw. Pojawiaj si tu dodatkowe aspekty funkcjonalnoci systemu, moliwoci jego rekonfigurowania, oraz jakoci usug rozumianych jako wydajno systemu, niezawodno, dostpno oraz bezpieczestwo. Moliwo zapewnienia tych aspektw, ktre s najbardziej dostrzegalne
przez uytkownika kocowego systemu, zaley w gwnej mierze od doboru odpowiednich rozwiza projektowych i zwykle decyduje o ocenie systemu. W systemach
rozproszonych wanym kryterium projektowym jest komunikacja w systemie. Jest ona
rodkiem pozwalajcym na poczenie poszczeglnych elementw systemu. Projektowanie schematw komunikacyjnych, jak klientserwer czy rozsyanie grupowe, daje
podstawy do tworzenia otwartych systemw rozproszonych. W tego typu systemach
istotna jest strukturalizacja oprogramowania, ktra uwidacznia si podczas projektowania serwerw baz danych. Serwery te musz pozwoli na atwe dodawanie nowych
zasobw danych wspdzielonych oraz dzielenie danych i utrzymywanie spjnoci.
Uytkownik musi mie cakowite zaufanie do prawdziwoci i aktualnoci otrzymywanych odpowiedzi. Jeszcze jedn zalet tworzenia rozproszonych baz danych jest opracowanie na podstawie danych zgromadzonych w rnych wzach sieci analitycznych
baz danych organizowanych w tzw. hurtownie danych.
Omawiajc rozproszone bazy danych wielokrotnie wspominano o dynamicznie
rozwijajcej si sieci Internet. Niezwyka popularno tego narzdzia sprawia, e
prezentacja danych w Internecie jest tematem nastpnego rozdziau.

142

12. PREZENTACJA DANYCH W INTERNECIE

12.1. Uwagi oglne
Ostatnio mona zaobserwowa gwatowny wzrost prezentacji rnego typu informacji, a to gwnie za spraw Internetu [11, 16, 17]. Moliwo prezentacji rnego
typu materiaw na graficznych stronach www przyczynia si wanie do tak byskawicznego wzrostu zainteresowania integracj baz danych z serwerami www. Ma to
podstawowe znaczenie przy budowie szerokiej gamy usug internetowych i intranetowych (sie informatyczna w przedsibiorstwach). Mona poda wiele praktycznych
przykadw zastosowania integracji baz danych z moliwociami www poczwszy od
najprostszych zasobw archiwalnych umoliwiajcych wyszukiwanie tekstowe, prezentacj tabel z danymi tekstowymi i liczbowymi poprzez systemy ogosze, systemy
ledzenia zamwie, a po elektroniczne multimedialne katalogi czy nawet sklepy
internetowe. Firmom rzucono wyzwanie, gdy korzyci jakie przynosi posiadanie
zintegrowanej bazy danych z serwerem www s niewtpliwe. Jednak osoby podejmujce decyzj, czy zastosowa nowoci programistyczne we wasnej firmie czeka jeszcze trudne zadanie znalezienia miejsca dla nowego oprogramowania w istniejcej
strukturze informatycznej. Integracja bazy danych z serwerami www obejmuje takie
zagadnienia, jak: szeroko rozumiana architektura systemu, wydajno, aspekty konfiguracji i administracji, atwo i intuicyjno wykorzystania oraz bezpieczestwo
danych i transmisji.
Internet ma najwikszy i praktycznie nieograniczony zasig. Uytkownik moe
w nim korzysta z wielu usug. Bardzo prnie rozwija si usuga, dajca moliwo
zaprezentowania swojej graficznej wizytwki na stronach www. Umoliwia ona
w atwy i przyjazny dla uytkownika sposb zaprezentowanie swoich danych, jak
rwnie korzystanie z zasobw udostpnianych na serwerach caego wiata. Ogromn
zalet jest niezaleno od stosowanej platformy sprztowej i systemowej.
www stwarza moliwo prezentacji swoich danych oraz odczytywania informacji
udostpnianych przez ogromn liczb jej uytkownikw. Aby przedstawi swoje dane, musimy stworzy wasny dokument i umieci go w serwerze www. Odczytywanie
odbywa si przy pomocy specjalnych programw nawigacyjnych zwanych przegldarkami. Ich zadaniem jest nawizanie komunikacji z serwerem i odpowiednia interpretacja znajdujcych si tam dokumentw. Producenci wzbogacaj przegldarki
o nowe moliwoci korzystania z innych usug internetowych: poczty elektronicznej,
protokow transmisji plikw, list dyskusyjnych.

143

Na potrzeby prezentacji dokumentw w sieci Internet powsta jzyk programowania HTML (ang. HyperText Markup Language). Dokument HTML jest zwykym plikiem tekstowym, w ktrym znajduj si polecenia HTML. Oznacza to, e w dokumencie jest opisywana struktura a nie wygld, ktry zaley od uywanego przez
klienta programu przetwarzajcego, tzw. przegldarki. Wynika z tego, e dokument
taki mona utworzy za pomoc najprostszego edytora tekstw, rcznie dodajc
znaczniki. Jednak na rynku pojawio si ju wiele specjalizowanych edytorw, ktre
wydatnie uatwiaj konstruowanie dokumentu, wspomagajc wprowadzenie polece.
Internet mia pocztkowo suy udostpnianiu wielu danych w formie cile sprecyzowanej przez standardy HTML. wiat jednak poszed gwatownie do przodu
i uytkownicy tej rozlegej sieci zaczli dodawa coraz to nowsze i bardziej pomysowe rozwizania. Kady waciciel wasnej witryny chce, aby prezentowany przez niego graficzny serwis by atrakcyjny i uyteczny. Gwatownie wzrasta te zapotrzebowanie na wiksz ilo informacji, publikowanych za porednictwem sieci Internet.
Kolejnym wielkim krokiem bya moliwo przedstawienia zawartoci baz danych
bezporednio na stronach www. Nastpia zmiana charakteru, od czysto statycznych
stron do dynamicznie aktualizowanych wiadomociami zawartymi w bazach danych.
Standard HTML nie uleg wielkim przeobraeniom. Modyfikowano go tylko w kierunku wykorzystania skryptw i apletw Javy, ktre wykorzystujc odpowiednie sterowniki do systemu zarzdzania baz danych potrafi wybrane informacje umieci na
witrynach www.

12.2. Serwery www

Jeeli chcemy udostpni innym uytkownikom jakie dane, niezalenie od tego
czy bd to dokumenty w formacie HTML, czy informacje zawarte w bazach danych,
inne pliki, teksty, obrazki czy animacje, moemy skorzysta z usugi serwera www.
Jest oprogramowanie, ktre sprawia, e osoba korzystajca z tej usugi moe skorzysta z udostpnionych zasobw, nie wnikajc w szczegy dotyczce ich lokalizacji
i metod dostpu do nich. Jedyn istotn kwesti jest uwzgldnienie ich w zasobach
przez administratora. Mona stwierdzi, e serwer www jest przezroczysty, to znaczy,
e bez wzgldu na to skd si czymy nie musimy dokadnie wiedzie gdzie znajduj
si dane. Uytkownik pragnc skorzysta z zasobw znajdujcych si na serwerze
generuje danie przesania danych. Serwer odbiera zgoszenie przegldarki, przesya
dany plik i koczy poczenie. Istotn zalet jest fakt, e pragnc skorzysta z jakiego dokumentu w formacie HTML osobno obsugiwane jest zgoszenie dotyczce
pliku tekstowego, a osobno poszczeglnych plikw z grafik, dla ktrych otwierane s
niezalene poczenia midzy przegldark i serwerem. Przed transmisj danych do
przegldarki zostaje wysany znacznik typu danych. Znacznik w jzyku HTML to
polecenie bdce specjalnym cigiem znakw objtym nawiasami ostrymi. Po identy-

144

fikacji przegldarka wie, jak wczyta interpreter typu danych. Jeeli chcemy wysa
do przegldarki dokument zawierajcy grafiki w formatach JPG i GIF (dwa podstawowe formaty bitowych plikw graficznych), to serwer wysya znaczniki, na podstawie ktrych przegldarka wczytuje i uruchamia odpowiednie interpretery formatu.
Aby wybra odpowiedni serwer www, naley zbada potrzeby i oczekiwania oraz
zapozna si z istniejc struktur informatyczn. Wane jest oszacowanie ruchu,
iloci odwoa, rozmiaru i zakresu orodka udostpniajcego witryny. Poza tym
o wyborze konkretnego rozwizania powinny decydowa osoby konfigurujce i modyfikujce zawarto www i osoby zarzdzajce sieci. Bardzo wan cech serwera
jest poczenie z bazami danych. Jeli ciga si dane z systemw zarzdzania baz
danych, to trzeba bra pod uwag typy pocze serwera www z zewntrzn baz danych. Najbardziej popularn metod jest protok ODBC (ang. Open Database Conectivity), jednak niektre firmy proponuj wasne rozwizania. Na przykad produkt
Web Side Professional zawiera narzdzie do projektowania aplikacji umoliwiajce
zakodowanie komend dostpu do danych na stronach HTML. Gdy taka strona zostanie
wywoana, serwer www wykonuje te komendy, ciga dane i wkleja je na stron.

12.3. Dane na stronach www

12.3.1. Wprowadzenie
Twrcy dzisiejszego oprogramowania przecigaj si w tworzeniu i dodawaniu
nowych narzdzi czy obiektw dla uatrakcyjnienia serwisu www. Ostatnio kluczow
spraw jest udostpnienie informacji bezporednio z bazy danych, jak rwnie moliwo ingerencji bezporednio w struktur bazy za pomoc jednej z popularnych przegldarek. Projektanci baz danych, serwerw www znaleli kilka sposobw na dynamiczne tworzenie serwisu prezentujcego interesujce bazy danych. Zasady
projektowania interfejsu do baz danych s proste. Najnowsze standardy jzyka HTML
umoliwiaj umieszczenie w dokumencie elementw aktywnych, dziki ktrym uytkownik za porednictwem przegldarki stron www moe oprcz przegldania wasnorcznie wprowadzi dane lub wykona zapytania do bazy danych. Informacj zwrotn
otrzymuje on dziki specjalnym mechanizmom. Podstawowy mechanizm wsppracy
midzy przegldark, serwerem www a serwerem bazy danych mona zawrze
w czterech krokach:
1. Poprzez przegldark generowane jest zapytanie klienta.
2. Serwer www przekazuje zapytanie do bazy danych.
3. Baza danych przetwarza zapytanie i udziela odpowiedzi.
4. Odpowied przetworzona zostaje na HTML i przekazana do przegldarki.
Taka specyfika wsppracy przegldarki i bazy danych nie jest korzystna dlatego,
e nie ma trwaego poczenia midzy przegldark a serwerem. Nie moemy w tym

145

wypadku mwi o bezporedniej transakcji wykonywanej na bazie danych. Teraz

informacje o stanie transakcji s przekazywane poprzez dynamicznie generowane
odnoniki (ang. links) lub te wykorzystuje si waciwoci dynamiczne tworzonych
formularzy. Dostpny jest rwnie specjalny mechanizm umoliwiajcy przekazywanie odpowiednich wartoci podczas komunikacji midzy przegldark a serwerem.
Metody statycznego udostpniania informacji tekstowej na internetowych witrynach www nale do najprostszych. Pocztkowo kreatorzy stron kopiowali zawarto
baz danych i umieszczali je na stronach jako zwyky tekst. Gdy po pewnym czasie
naleao dokona aktualizacji webmaster, opiekujcy si serwisem wymienia ca
stron na serwerze. Byo to zajcie bardzo czasochonne. Firmy wiadczce usug
prezentacji informacji ekonomicznych czasami kilkanacie razy dziennie zmieniay
zawarto swoich serwerw. Z pomoc przyszo rozwizanie dynamicznie aktualizowanych stron, na ktrych informacja odzwierciedla stan serwera podczonej bazy
danych. Jest ona na bieco modyfikowana, a wywietlane informacje oddaj stan
momentu dania usugi przez klienta.

12.3.2. Metody dynamicznego udostpniania danych w www

Uytkownicy zaczli stawia coraz wiksze wymagania dotyczce serwerw www.
Bardzo wan kwesti byo utrzymywanie aktualnoci danych. Tak wic zaczto tworzy specjalne dodatki do standardowego jzyka HTML, umoliwiajce wykonywanie
rnych polece systemowych, tworzenie interaktywnej grafiki, czy bezporedniego
odwoywania si do baz danych. Powstao wiele standardw i nowych technologii
wykorzystywania specjalnych funkcji, jak: przetwarzanie skryptw, wykorzystywanie
jzykw wysokiego poziomu itp. Pojawienie si nowych technologii postawio projektantw oprogramowania oraz projektantw serwisw internetowych i intranetowych przed problemem wyboru tej najwaciwszej. Przed zarzdcami systemw
stany problemy zapewnienia waciwego poziomu wydajnoci i ochrony zasobw
znajdujcych si w sieci.
API (ang. Application Programing Interface) to zestaw funkcji stworzonych dla
serwera www. Obecnie na rynku licz si dwie specyfikacje: dla serwerw Netscape
NSAPI oraz ISAPI dla oprogramowania Microsoft. Funkcje API peni przerne
zadania na serwerze i umoliwiaj obsug odwoa do jego zasobw, do zasobw baz
danych itp. Funkcje te tworzy si od podstaw, aby zapewni jak najwiksz wydajno. Tworzenie aplikacji w API wymaga specjalistycznych technik programistycznych, jak wielowtkowo, synchronizacja procesw, bezporednie programowanie
protokou i obsuga bdw. Wielu producentw dostarcza gotowe rozwizania
w postaci bibliotek *.dll. Metoda API zwana jest metod niskiego poziomu.
Do metod wysokiego poziomu naley metoda SSI (ang. Serwer Side Includes). Jest
to chyba najstarsza metoda dynamicznego udostpniania informacji z baz danych na
stronach www. Polega ona na zapisywaniu komend SSI bezporednio w dokumencie

146

HTML. Pliki z takimi komendami byy odpowiednio identyfikowane rozszerzeniem

*.ssi. Umoliwiao to serwerowi www wczeniejsze przetworzenie takiego dokumentu, a potem zrealizowanie usugi. Gdy serwer www nie posiada odpowiednich mechanizmw, dodatkowe komendy byy ignorowane, a dokument trafia do klienta w wersji nieprzetworzonej.
Microsoft od pocztku powstania mocno reklamowa swoje rozwizanie Active X
jako najlepsze narzdzie do projektowania aplikacji internetowych. Pocztek wszystkiemu da standard DDE (ang. Dynamic Data Exchange) zaprojektowany w celu udostpnienia aplikacjom moliwoci wymiany danych. Kolejnym krokiem byo OLE
(ang. Object Linking and Embedding), umoliwiajce traktowanie dokumentw utworzonych przez jedn aplikacj jako zasobnika dla obiektu utworzonego przez inn, np.
dokument Word moe zawiera tabel utworzon w Excel. Zagniedenie to moe
polega na wczeniu caego obiektu lub tylko jego cznika. Kiedy wzroso zainteresowanie Internetem i Intranetem, technologia OLE Documents przeksztacia si
w Active X Documents. Pierwotna koncepcja Active X usystematyzowaa si i zostaa
poszerzona o dodatkowe rozwizania:
szkielet serwera Active X (ang. Internet Serwer API) opisujcy, w jaki sposb
serwer www powinien komunikowa si z aplikacjami wspierajcymi, ktre miedzy
innymi pozwalaj filtrowa i modyfikowa dokumenty,
sterowniki internetowe Active X zapewniajce usugi przegldarek internetowych innych klientw oraz transfer plikw w formie moduw, co pozwala atwo wcza je do aplikacji,
Active Scripts sterowniki Active X wykorzystujce Java Script, Visual Basic
Script, C/C++ oraz inne jzyki opisowe,
Code Security Services zapewniajce integralno po stronie klienta w odniesieniu do obiektw Active X sprowadzanych ze rde nie majcych statusu bezpieczestwa.
Interfejs CGI (ang. Common Gateway Interface) kadorazowo podczas zgoszenia
uytkownika powoduje uruchomienie na serwerze odpowiedniego programu, ktry
poczy si z baz danych, przekae jej zapytanie, a wynik, ktry otrzyma przetworzy
na format HTML i odele do serwera. Zalet tego rozwizania jest jego prostota, niestety na jego niekorzy wiadcz saba integracja z serwerem i niska wydajno. Ta
ostatnia cecha wynika z koniecznoci uruchamiania odrbnego procesu dla kadego
zgoszenia przychodzcego z sieci. Fakt, i program CGI jest kadorazowo niezalenym wykonywalnym procesem sprawia, e informacja o aktualnym stanie serwera jest
dosy ograniczona. Nie zaleca si stosowania go w przypadku wykonywania skomplikowanych wieloetapowych transakcji. Powsta ju zreszt nowy standard Fast CGI.
Przy zastosowaniu Fast CGI serwer www uruchamiajcy na danie proces obsugi
danych z zewntrznego rda utrzymuje go w gotowoci do obsugi nastpnych zgosze, dziki czemu nie ma problemw z uruchamianymi kadorazowo nowymi procesami.

147

ASP (ang. Active Serwer Pages) jest to koncepcja budowania dynamicznych stron
www opracowana przez firm Microsoft. Pozwala ona w tekstowych plikach HTML
umieszcza wstawki kodu lub cae programy napisane w Visual Basic Script czy Java
Script. Bardzo uyteczna jest moliwo poszerzania tworzonych dokumentw
o obiekty baz danych i obiekty zapewniajce zapamitanie transakcji klienta. Przygotowana witryna www jest w rzeczywistoci wzorcem strony, w ktrym przed wysaniem do klienta zostan umieszczone odpowiednio sformatowane dane pochodzce
z systemu wsppracujcych baz danych. Rozwizania ASP umoliwiaj szybkie poczenie z baz, bardzo szybkie tworzenie profesjonalnych aplikacji www, zarwno
internetowych jaki intranetowych. Oprcz podstawowych operacji wykonywanych na
bazach, takich jak otwieranie i zamykanie pocze, wykonywanie zada SQL, dostpne s take bardziej zaawansowane mechanizmy. Naley do nich obsuga transakcji na kilku poczeniach z danym klientem lub korzystanie z procedur wbudowanych.
Bardzo duo ciekawych rozwiza przy czeniu aplikacji baz danych ze stronami
www daje moliwo zastosowania jzyka Java. Aplikacja Javy moe dziaa niezalenie od serwera. Nie korzysta ona z API serwera. Uytkownicy, wykorzystujc
przegldark przystosowan do interpretacji Javy lokalnie przetwarzaj aplety zawarte
w dokumentach HTML na serwerze. Aplety s plikami niewielkimi wic ich transfer
nie obcia sieci. Wykorzystujc aplety Javy do podpinania baz danych atwo jest
zauway du elastyczno tego jzyka. Na przykad podczas tworzenia formularza
jaki chcemy wypeni danymi, ktre nastpnie zapisz si do bazy danych na serwerze, wystarczy wykorzysta stworzony do tego celu aplet. Nie ma w tym wypadku
koniecznoci tworzenia dynamicznej strony HTML. Takie napisane przez nas aplety
mog dziaa zarwno po stronie klienta, czyli przegldarki, jak rwnie po stronie
serwera. Do komunikacji z baz danych stosuje si specjalny protok JDBC. W odrnieniu od produktw Microsoft daje on wiksz niezaleno od platformy sprztowej i systemowej. Biblioteka JDBC API jest to zbir klas, ktre umoliwiaj poczenia z bazami danych, wykonuj instrukcje SQL i przetwarzaj wyniki.
Jeszcze jedno rozwizanie to narzdzia wizualne. Jest to grupa gotowych programw, ktre umoliwiaj graficzne zaprojektowanie wygldu stron www, schematw
baz danych, formatw raportw czy formularzy, na podstawie ktrych jest generowany nastpnie odpowiedni kod aplikacji klienta czy serwera. Narzdzia wizualne s
bardzo praktyczne. Ich projektanci zadbali o to, aby kocowy uytkownik nie mia
problemw z rnymi formatami danych oraz z bardziej zoonymi schematami danych, jak na przykad zczenia tabel.

148

12.3.3. Metody dostpu do baz danych

Narzdzia do pocze na stronach www firma Microsoft oferuje uytkownikom
pracujcym na platformie Windows NT i korzystajcym z bazy danych SQL Serwer
i serwera www. Oprogramowanie to tworzy jedn cao SQL Internet Connector.
Zasadnicz czci tych aplikacji jest Web Assistant, narzdzie uatwiajce tworzenie
dynamicznych stron w HTML. Jest bardzo pomocne podczas pobierania specyficznych danych z serwera bazy danych i uywania ich do tworzenia strony w HTML.
Dane mona uzyska kilkoma sposobami. Moemy wybiera kolumny z poszczeglnych tabel, stosowa swobodna form wyrae SQL lub uywa zapamitane procedury dostpu do bazy danych. Uywanie takich kryteriw jak data, czas lub fakt modyfikacji danych, umoliwia okrelenie, kiedy naley uaktualnia strony www
informacjami z bazy danych. Zalet takiego rozwizania jest to, e uytkownicy nie
zatrudniaj bazy danych w czasie rzeczywistym, lecz uzyskuj dostp do statycznych
stron uaktualnianych dynamicznie co pewien czas. Niewtpliw wad jest brak moliwoci tworzenia dynamicznych stron ad hoc. W tym wypadku stosuje si techniki
wykorzystujce ASP i kontrolki Active X.
Inn bardzo popularn metod udostpniania baz danych na witrynach www jest
wykorzystanie produktu IDC (ang. Internet Database Connector).
pliki *.idc

SZBD

pliki *.htx

Internet Database
Connector IDC

komunikacja

Serwer www.

Internet Information
Server IIS
oprogramowanie serwera www

Komputer
z przegldark

Rys. 12.1. Sposb korzystania z IDC

Jest to rozszerzenie Internet Information Serwer wykorzystujce API tego serwera.

IDC jest czci, a konkretnie jedn z bibliotek *.dll (httpodbc.dll) adowanych do
serwera www. Wanie dlatego wszystkie funkcje zawarte w IDC mog korzysta
z zasobw serwera www. Aby uzyska moliwo komunikacji z baz danych, naley
zainstalowa odpowiedni sterownik ODBC. IDC wykorzystuje dwa rodzaje plikw:
*.idc zawieraj informacje o sposobie poczenia z baz, o instrukcjach SQL

149

i wszystkich informacjach niezbdnych do wykonania operacji na bazie oraz pliki

*.htx zawierajace informacje w jaki sposb formatowa dane uzyskane po wykonaniu plikw *.idc.
Firma Oracle oferuje oprogramowanie Web Request Broker bdce czci pakietu Web Server dostarczonego w Oracle 7 Serwer 7.3. Jej produkty obsuguj przetwarzanie transakcji on-line i pozwalaj na utrzymanie trwaej sesji miedzy przegldarkami, serwerami www i serwerami baz danych. Rozwizanie to pomija mechanizmy
CGI, co powoduje uzyskanie wikszej kontroli nad procesami generowanymi przez
aplikacj, obsug zarzdzania jednoczenie wieloma poczeniami do bazy, co z kolei
znacznie poprawia wydajno. Dla programistw dostarczany jest WRB API sucy
do projektowania pakietw aplikacyjnych. Dodatkowo firma opracowaa narzdzie
projektowe Developer 2000 i Designer 2000. Ich przeznaczeniem jest projektowanie
aplikacji internetowych dla zaawansowanych projektantw.
Produktem firmy Informix jest Live Wire Pro, ktry stanowi cz oferty Suite
Spot pakietu Online Workgroup Serwer. Produkty Informix udostpniaj w ramach
tych pakietw oprogramowanie firmy Netscape. Informix dostarcza kilku opcji pozwalajcych zamieszcza dane z baz na stronach www. Najprostszy Web Interface Kit
ustanawia proste poczenie www baza danych wykorzystujc skrypty CGI. Kolejnym produktem jest Web Connectivity Framework pozwalajcy orodkom www
utrzymywa informacje o stanie sesji w sposb analogiczny do aplikacji baz danych.
Bardzo interesujca jest propozycja Web Data Blade. Jest to rodowisko projektowania moduw i aplikacji baz danych oparte na www. Stosuje si tutaj technologi
obiektow w www. Scala ona wszystkie funkcje dostpu do danych i indeksacji.
Umoliwia to pamitanie takich zoonych typw danych jak video, gos, obrazy cznie z tekstem i innymi typami danych multimedialnych.
Firma IBM doczya moliwoci zarzdzania zoonymi typami danych do swojego produktu DB2. Dotychczas uywano NetDate, ktry umoliwia przeksztacanie
statycznych stron HTML na dynamiczne aplikacje za pomoc zestawu makr. Wykorzystano tu technik skryptw CGI. NetDate wsppracuje z baz DB2 w sposb bezporedni, a z bazami innych producentw za porednictwem sterownika ODBC.
W Sybase programy scalajce prac przegldarek, serwerw www i baz danych to
Web SQL i Object Connect. Pozwalaj one na wpisywanie instrukcji takich jak wyraenia SQL i skrypty Perl. Umoliwiaj rwnie generowanie stron majcych indywidualizowan zawarto opart na szablonach uytkownika i jego preferencjach.

12.4. Serwery handlu elektronicznego

Najbardziej dzi zaawansowanymi aplikacjami wykorzystujcymi opisywane serwery www, bazy danych, metody wsppracy midzy nimi i udostpnienie informacji
dynamicznie na stronach www s systemy handlu elektronicznego. Zasadnicz czci

150

jest w nich serwer handlowy. Opiera si on na serwerach www poszerzonych o skrypty

back end, obsugujce prezentacj katalogw towarw i procesy sprzeday. Oczywicie potrzebna jest odpowiednia baza danych SQL. Moe ona pracowa na serwerze
handlu, ale bardzo czsto umieszcza si j osobno, poprawiajc bezpieczestwo rozwizania. Wiele serwerw handlu elektronicznego obsuguje sprzeda anonimow i personalizowan. W pierwszym przypadku klient identyfikowany jest w momencie skadania
zamwienia, w drugim rejestruje si jednorazowo w bazie klientw, a potem identyfikuje
si go podczas wejcia na serwer. Istotn spraw jest elektroniczny koszyk sklepowy.
W istocie jest to rwnie baza danych pozycji wybranych przez klienta. Wane jest naleyte skonfigurowanie takiego koszyka, a zaley ono od wielu czynnikw. Proces patnoci
w handlu elektronicznym mona opisa w omiu krokach (rys. 12.2):
krok3

krok1

krok2

Serwer
sprzedawcy

klient

krok4

klient

INTERNET
krok7

klient

krok6

klient
Bank realizujcy
patnoci

Krok 5

Bank
zarzdzajcy
karta kredytow

Bank
sprzedawcy
prywatna sie bankowa

Rys. 12.2. Patnoci w handlu elektronicznym

Krok 1: nabywca odwiedzajc sklep on-line wybiera interesujce go propozycje.

Krok 2: serwer wysya do klienta formularz z opisami produktu, cen, form patnoci, numerem transakcji.
Krok 3: klient wybiera form zapaty. Specjalne oprogramowanie klienta uruchamia aplikacj patnicz. Dane zostaj zaszyfrowane i odesane na serwer.
Krok 4: zaszyfrowane dane klienta serwer odsya do specjalnego banku realizujcego patnoci.

151

Krok 5: serwer realizujcy patnoci wysya dane klienta do banku wskazanego

przez sprzedawc.
Krok 6: bank sprzedawcy potwierdza wano karty kredytowej (komunikacja
z instytucj zarzdzajc kartami) i informuje o tym fakcie bank realizujcy patnoci.
Krok 7: bank realizujcy patnoci przekazuje otrzymane dane do serwera sprzedawcy.
Krok 8: serwer sprzedawcy finalizuje transakcj i powiadamia nabywc.
Istotne s oczywicie sprawy ochrony. Jeeli serwer handlowy zamierza prowadzi
transakcje finansowe, to bardzo wan spraw jest utrzymanie poufnoci transakcji
(wykorzystanie protokow SSL lub Secure HTML). Oczywicie powinien on by
dodatkowo zabezpieczony. Na rynku dominuj trzy wiodce rozwizania: Net Commerce firmy IBM, Site Server firmy Microsoft oraz Domino Merchant Lotusa.
Polityka bezpieczestwa jest spraw, ktrej obecnie powica si coraz wicej
uwagi [15]. Firmy dbaj o tajno wasnej informacji. Problem ten jest o wiele szerszy
ni tylko obrona przed internetowymi hackerami. Z sonday wynika, e najwicej
szkody czyni niekompetentni i niezdyscyplinowani pracownicy. Pracownikw naley
wcza do odpowiednio zaprojektowanego systemu bezpieczestwa poprzez nadawanie im praw dostpu stosownie do zajmowanych pozycji. Wane jest, aby zaplanowa odpowiednio strategi bezpieczestwa. Plany te powinny uwzgldnia: propozycje fizycznego zabezpieczenia zasobw firmy, opis realizacji metod kontroli dostpu
do systemu i jego zasobw, opis metod monitorowania systemu, reakcji na wykrycie
zagroenia lub prby wamania, dokadn implementacj procedur naprawiajcych
szkody wywoane przez niepowoanych uytkownikw, czy wreszcie opis tworzenia
zabezpiecze i kopii zapasowych.

12.5. Uwagi kocowe

Moliwo wykorzystania bogatych zasobw wiedzy z najrnorodniejszych dziedzin znajdujcych si w sieci Internet [11] pozwala na stworzenie aplikacji prostych,
atwych w obsudze i funkcjonalnych. Aplikacje takie dysponuj nastpujcymi mechanizmami tak charakterystycznymi dla tego typu oprogramowania:
odpowiednim poczeniem z baz danych,
narzdziami dla analiz i raportw,
odpowiedni prezentacj danych (koszyk internetowy),
rejestracj uytkownikw,
prost rozszerzalnoci oferty.
Oczywicie profesjonalne oprogramowanie pozwala tworzy wasne serwery handlu elektronicznego dysponujce wieloma dodatkowymi narzdziami i usugami. Zapewniaj one oprcz charakterystycznych opcji zwizanych ze sprzeda usug czy
towarw take ochron pocze i aspekty bezpieczestwa przechowywanych danych.
Wane jest, aby zapewni w naleyty sposb ochron danych serwera.

152

PODSUMOWANIE
W czci IV poruszono dwie istotne sprawy dla dalszego rozwoju baz danych,
a mianowicie problematyk rozproszonych baz danych i moliwoci sieci Internet
w dziedzinie baz danych. Jeeli chodzi o projektowanie baz rozproszonych, to w pewnym stopniu moemy traktowa to jako pewien sposb projektowania bazy na poziomie fizycznym. Pierwszym etapem projektowania jest utworzenie modelu scentralizowanej bazy, a nastpnie podjcie decyzji, jak podzieli i zreplikowa utworzony
schemat logiczny. Problem polega na tym, aby umieci dane blisko miejsca gdzie s
uywane oraz zmniejszy ilo danych przesyanych w sieci. Fragmentacja i replikacja danych jest jednym z najwaniejszych zada strategii rozproszenia [20, 22].
Z rozproszonymi bazami danych cile zwizana jest moliwo wykorzystania sieci
Internet w dziedzinie baz danych. W obu przypadkach powinna istnie moliwo
korzystania z takich uytecznych cech, jak:
moliwo umieszczenia serwera aplikacji na dowolnym systemie w sieci,
moliwo automatycznego, rwnomiernego rozoenia obcienia midzy kilka
serwerw realizujcych usugi tego samego typu,
moliwo dziaania wieloaplikacyjnych serwerw na jednej lub wielu maszynach,
zatajenie prawdziwej lokalizacji serwera,
moliwo wykorzystania niejednorodnych, heterogenicznych baz danych,
prostota dodawania nowych i modyfikacji istniejcych czci systemu.
Architektura tego typu istnieje na rynku od lat. Jest ona realizowana w dwojaki
sposb. Pierwszy sposb to utrzymanie tendencji dotychczas panujcej reprezentowanej przez takie firmy jak Microsoft i Intel. Ich wizja sieci to niezalene stacje robocze
PC wyposaone w twarde dyski, na ktrych rezyduje system. Drugi sposb to koncepcja zastpienia komputerw PC komputerami sieciowymi. Nazywa si je odchudzonymi klientami. Urzdzenia te przechowuj wszystkie dane w swojej pamici RAM,
a podstawowymi wymaganiami jakie musz spenia to zawiera rodowisko wykonawcze Javy, obsugiwa aplikacje niezalene i rezydujce w sieci oraz wykazywa
si niezalenoci od rodzaju sieci. Do grupy tej nale Netscape, Oracle, Sun Microsystem.

153

ZAKOCZENIE
Dziedzina baz danych ulega staym rozszerzeniom w celu obsuenia coraz bardziej i bardziej zoonych obszarw zastosowa. W ten sposb systemy baz danych
zajy znaczce miejsce w konstrukcji systemw informacyjnych. Przykadem s takie
systemy informacyjne jak hipermedia [5] oraz geograficzne systemy informacyjne [8].
Tradycyjne systemy baz danych byy projektowane z myl o przechowywaniu duej
iloci strukturalnych danych. Struktura umoliwiaa specyfikacj formalnych zapyta
i wyszukiwanie informacji. W przypadku systemw hipermedialnych mamy do czynienia z przechowywaniem maych iloci rnych rodzajw mediw poczonych
sieci asocjacyjnych powiza. W zwizku z brakiem wewntrznej struktury ukadanie zapyta w tych systemach jest trudne do zrealizowania. Rwnie geograficzne
systemy informacyjne rni si od tradycyjnych baz danych. Mamy tu do czynienia
z modelowaniem i analiz danych przestrzennych. Do zarzdzania przestrzeni danych nadaje si zarwno opisany w czci II model obiektowy jak i dedukcyjny.
Oglnie uwaa si [1, 22], e nowe kierunki rozwoju baz danych, ktre prawdopodobnie odegraj istotn rol w przyszoci to:
rwnolego, czyli zastosowanie technologii komputerw rwnolegych do zarzdzania bazami danych; metoda ta, stosowana od lat, udowodnia swoj skuteczno
polepszajc wydajno,
inteligencja, czyli sztuczna inteligencja i jej implementacja w kontekcie baz danych; szczeglnie chodzi tu o bazy dedukcyjne,
zoono, czyli problem uycia baz danych w zoonych sytuacjach aplikacyjnych.

154

BIBLIOGRAFIA
[1] Beynon-Davies P., Systemy baz danych, WNT, Warszawa 1998.
[2] Berry B., Chase D., Delson B., Francis J., O Neill P., Sherwood J., Informix Universal Serwer.
Administrations Guide. Published by Informatix Press 1997.
[3] Coulouris G., Dillimore J., Kindberg T., Systemy rozproszone. Podstawy i projektowanie, WNT,
Warszawa 1998.
[4] Daniell B., Leland J., Maneval D., Informix Universal Server. DataBlade API. Programmers Manual. Published by Informix Press 1997.
[5] Darrel R.R., Tampa F.W.M., Hypertext and the Oxford English Dictionary, CACM, July, 1988,
31(7), s. 871879.
[6] Date C., Introduction to Datebase Systems 5th Ed. Addison-Wesley 1990.
[7] Garms J., Windows NT 4.0 Serwer. Kompendium Robomatic, Wrocaw 1997.
[8] Gatrell A.C., Concepts of Space and Geographical Data, 1999.
[9] Halilovic I., Gales Ch., DataBlade Module Development Overview, Published by Informix Press
1997.
[10] Hall C.L., Techniczne podstawy systemw klientserwer, WNT, Warszawa 1996.
[11] Informacje zawarte na witrynach www. 1999/2000.
[12] Kline M., Litzell Ch., Schackell J., Landshoff D., Bostrom K., Nowacki B., Howard D., Blade Manager. Published by Informix Press 1997.
[13] McCarthy D.R., Dayal U., The Architecture of an Active Data Base, Management Systems
Proc.SIGMOD 1989.
[14] Myer B., Object Oriented Software Construction, New York, Prentice-Hall 1997.
[15] Net World: Polityka bezpieczestwa i strategie jej realizacji 2/98,
Serwery handlu elektronicznego 2/98,
Narzdzia realizacji polityki bezpieczestwa 3/1998.
[16] Prace: Jankowski S., Obiektowo-zorientowany system zarzdzania prac przedsibiorstwa, dyplom
pod kierunkiem M. Chaon ICT PWr., Wrocaw 1998.
Bielecki K., Architektura rozproszonych systemw baz danych, dyplom pod kierunkiem M. Chaon
ICT PWr., Wrocaw 1999.
[17] Rose J., Marshall T., The Little Black Book: Mail Bonding with OSI Directory Services. Englewood
Cliffs, NJ, Prentice-Hall 1992.
[18] Rochkind M., Programowanie w systemie Unix dla zaawansowanych, WNT, Warszawa 1993.
[19] Stevens W., Programowanie zastosowa sieciowych w systemie Unix, WNT, Warszawa 1996.
[20] Teorey T.J., Database Modelling and Design: the Fundamental Principles. 2nd Ed. San Mateo, Calif.
Morgan Kaufmann 1994.
[21] The Advanced Network System Architecture (ANSA), Reference Manual, Castle Hill, Cambridge
England, Architecture Project Management, 1989.
[22] Ullman J.D., Widom J., Podstawowy wykad z systemw baz danych, WNT, 2000.

155

Spis rzeczy
Przedmowa ......................................................................................................................................

CZ I. Wprowadzenie do problematyki baz danych ...................................................................

1. Wstp ............................................................................................................................................
2. Krtka historia baz danych ..........................................................................................................
3. Pojcia podstawowe......................................................................................................................
4. Metodologia projektowania baz danych ......................................................................................
4.1.Wprowadzenie ........................................................................................................................
4.2. Proces projektowania i jego skadowe ...................................................................................
4.3. Opis modelu konceptualnego ................................................................................................
4.4. Przykad realizacji konkretnej bazy .......................................................................................
4.4.1. Sprecyzowanie wymaga dotyczcych projektowanej bazy danych ..........................
4.4.2. Model konceptualny bazy danych ...............................................................................
4.4.3. Normalizacja ...............................................................................................................
Podsumowanie .................................................................................................................................
Bibliografia ......................................................................................................................................

5
6
8
10
16
16
17
19
24
24
25
25
28
29

CZ II. Wybrane metody reprezentacji danych ..........................................................................

Wprowadzenie .................................................................................................................................
5. Model relacyjny jako przykad modelu klasycznego ...................................................................
5.1.Uwagi oglne .........................................................................................................................
5.2. Opis modelu ..........................................................................................................................
5.3. Operacje na relacjach ............................................................................................................
5.4. Schemat relacyjny .................................................................................................................
5.5. Rozkad schematu relacyjnego ..............................................................................................
5.6. Normalizacja .........................................................................................................................
5.7. Wskazwki praktyczne .........................................................................................................
6. Obiektowy model danych ............................................................................................................
6.1. Uwagi oglne ........................................................................................................................
6.2. Obiekty i klasy ......................................................................................................................
6.3. Atrybuty .................................................................................................................................
6.4. Metody ...................................................................................................................................
6.5. Dziedziczenie i tosamo obiektw......................................................................................
6.6. Enkapsulacja .........................................................................................................................
6.7. Utrzymanie poprawnoci bazy ...............................................................................................
6.8. Mechanizmy ochrony dostpu do danych ..............................................................................
6.9. Uwagi kocowe .....................................................................................................................
7. Dedukcyjne bazy danych .............................................................................................................
7.1. Uwagi oglne .........................................................................................................................
7.2. Model dedukcyjnej bazy danych ...........................................................................................
7.3. Jzyki dedukcyjnych baz danych ..........................................................................................
7.4. Metody wnioskowania ..........................................................................................................

31
32
33
33
34
35
39
40
45
51
53
53
54
54
55
55
57
58
58
59
60
60
60
62
64

156
7.5. Podstawowe funkcje systemu zarzdzania dedukcyjn baza danych ....................................
7.6. Realizacja zapyta i ich optymalizacja ..................................................................................
7.7. Uwagi kocowe .....................................................................................................................
Podsumowanie .................................................................................................................................
Bibliografia ......................................................................................................................................

67
67
68
70
71

CZ III. Stosowanie modeli danych ............................................................................................

Wprowadzenie ..................................................................................................................................
8. Nieproceduralny jzyk czwartej generacji ...................................................................................
8.1. Uwagi oglne .........................................................................................................................
8.2. Instrukcje definiowania danych .............................................................................................
8.3. Instrukcje manipulowania danymi ........................................................................................
8.4. Zapytania ...............................................................................................................................
8.5. Instrukcje zarzdzania danymi .............................................................................................
8.6. Integralno bazy danych ......................................................................................................
8.7. Uwagi kocowe......................................................................................................................
9. System obiektowo zorientowany .................................................................................................
9.1. Uwagi oglne .........................................................................................................................
9.2. Jzyk opisu procesw ............................................................................................................
9.3. Schemat bazy danych ............................................................................................................
9.4. Jzyk opisu klas .....................................................................................................................
9.5. Jzyk opisu metod .................................................................................................................
9.6. Jzyk opisu praw dostpu ......................................................................................................
9.7. Zapytania w bazie ..................................................................................................................
9.8. Uwagi kocowe .....................................................................................................................
10. System dedukcyjny .....................................................................................................................
10.1. Uwagi oglne .......................................................................................................................
10.2. Pozyskiwanie wiedzy ...........................................................................................................
10.3. Baza wiedzy. ........................................................................................................................
10.4. Badanie poprawnoci bazy wiedzy ......................................................................................
10.5. Uwagi kocowe ...................................................................................................................
Podsumowanie .................................................................................................................................
Bibliografia ......................................................................................................................................

73
74
75
75
75
80
81
87
89
94
96
96
98
101
104
107
107
108
112
113
113
114
117
119
120
122
123

CZ IV. Rozproszone bazy danych ............................................................................................

Wprowadzenie .................................................................................................................................
11. Architektura rozproszonych systemw baz danych ...................................................................
11.1. Uwagi oglne .......................................................................................................................
11.2. Podstawowe wasnoci rozproszonego systemu baz danych ..............................................
11.3. Cele projektowe dla baz rozproszonych ..............................................................................
11.4. Modele danych dzielonych i transakcji rozproszonych .......................................................
11.4.1. Fragmentacja i replikacja danych ...........................................................................
11.4.2. Hurtownie danych ..................................................................................................
11.4.3.Transakcje ...............................................................................................................
11.5. Rekonstruowanie danych ....................................................................................................
11.6. Bezpieczestwo w rozproszonych systemach baz danych ...................................................
11.7. Architektura IUS .................................................................................................................
11.8. Uwagi kocowe ...................................................................................................................

125
126
127
127
128
130
131
131
134
135
136
137
139
140

157
12. Prezentacja danych w Internecie.................................................................................................
12.1. Uwagi oglne .......................................................................................................................
12.2. Serwery www .......................................................................................................................
12.3. Dane na stronach www .........................................................................................................
12.3.1. Wprowadzenie.........................................................................................................
12.3.2. Metody dynamicznego udostpniania danych w www ............................................
12.3.3. Metody dostpu do baz danych ..............................................................................
12.4. Serwery handlu elektronicznego ..........................................................................................
12.5. Uwagi kocowe....................................................................................................................
Podsumowanie .................................................................................................................................
Zakoczenie .....................................................................................................................................
Bibliografia ......................................................................................................................................

141
141
142
143
143
144
147
148
150
151
152
153