1

Dziedzina systemv~ baz danych

Czytelnicy niniejszej ksiki dowiedz si, w jaki sposb mona skutecznie korzysta z systemw
zarzdzania bazami danych, a zwaszcza jak projektowa bazy danych oraz progamowa operacje na danych.
Biecy rozdzial posuy do wprowadzenia wanych poj dotyczcych baz danych. Po krtkim rysie historycznym sprecyzujemy, czym w istocie rni si systemy baz danych od innych rodzajw oprogamowania.
Opiszemy rwnie podstawowe elementy implementowania systemw zarzdzania bazami danych, potrzebne
przy ich stosowaniu. Zrozumienie owych zakulisowych" zagadnie staje si wane wwczas, gdy trzeba
stwierdzi, dlaczego baza danych zostaa zaprojektowana tak, a nie inaczej, albo dlaczego sposoby
wykonywania operacji na danych podlegaj ograniczeniom. W kocu dokonamy przegldu pewnych kierunkw
w tej dziedzinie, takich na przyklad jak progumowanie obiektowe, ktre by moe s ju znane czytelnikom, ale
s niezbdne do zrozumienia treci nastpnych rozdzialw.

1.1. Ewolucj a systemw baz danych

Czym jest baza danych? Baza danych nie jest w istocie rzeczy niczym wicej ni zbiorem danych
istniejcym przez dugi czas, czsto przez wiele lat. W potocznym rozumieniu termin baza danych odnosi si do
zbioru danych zorganizowanego przez system zarzc~dzania baza danych, ktry nazywa si rwnie skrtowo
systemem DBMS (database management system) lub po prostu systemem baz danych. Oto, czego oczekuje si
od systemu DBMS:
1. Umoliwienia uytkownikowi utworzenia nowej bazy danych i okrelenia jej schematu (logicznej struktury
danych) za pomoc specjalizowanego jzyka definiowania danych (data-definition language).
2. Udostpnienia uytkownikowi moliwoci tworzenia zapyta (query) o dane (czasem okrelane po polsku
rwnie mianem kwerend) oraz
ZO 1. DZIEDZINA SYSTEMW BAZ DANYCH

aktualizowania danych, za pomoc odpowiedniego jzyka nazywanego jzykiem zapyta (query language)
lub jzykiem operowania danymi (data - manipulation language).
3. Zapewnienia moliwoci przechowywania ogromnej iloci danych, mierzonej w gigabajtach lub nawet
wikszych jednostkach, przez dugi czas, chronic je przed przypadkowym, lub niepowolanym dostpem, a
take umoliwiajc efektywny dostp do danych z poziomu jzyka zapyta i operacji na danych.
4. Sterowania jednoczesnym dostpem do danych przez wielu uytkownikw, z zapewnieniem bezkolizyjnoci
oraz ochrony danych przed przypadkowym uszkodzeniem.

1.1.1. Pierwsze systemy zarzdzania bazami danych

Pierwsze profesjonalne systemy zarzdzania bazami danych pojawiy si na rynku pod koniec lat
szedziesitych. Pocztkowo sprowadzay si one do zwykych systemw plikw. Systemy plikw maj
niektre z wlaciwoci wymienionych powyej (punkt 3): umoliwiaj na przykkad przechowywanie danych
przez dlugi czas i zapewniaj przestrze do magazynowania duej iloci danych. Jednak w zasadzie systemy
plikw nie gwarantuj, e dane nie zostan utracone, jeli nie zostanie utworzona ich kopia zapasowa, ani nie
gwarantuj szybkiego dostpu do tych danych, ktrych lokalizacja nie jest dokadnie znana.
Systemy plikw ponadto nie stwarzaj moliwoci opisanych w punkcie 2, gdy nie s wyposaone w
jzyk zapyta. Ich przydatno do sprostania zaleceniom z punktu 1 - opis schematu bazy danych - sprowadza
si do udostpnienia mechanizmu struktury katalogowej. Systemy plikw nie speniaj rwnie wymaga z
punktu 4, poniewa kilku uytkownikw lub kilka procesw moe mie jednoczenie dostp do tego samego
pliku. Z kolei system plikw w zasadzie nie dostarcza mechanizmw, ktre pozwalaj unika sytuacji takich, e
dwch uytkownikw jednoczenie modyfikuje ten sam plik, ale zmiany wprowadzane przez jednego z nich nie
zostan w pliku zapisane.
Pierwsze powane implementacje DBMS daway moliwo rozoenia zbioru danych na niewielkie
elementy, co z kolei gwarantowao atwo tworzenia zapyta i modyfikacji. Poniej przedstawiamy opisy kilku
zastosowa takich systemw DBMS.
Systemy rezerwacji miejsc lotniczych
W tym przypadku zbir danych skada si z nastpujcych elementw:
1. Rezerwacja na okrelone rejs dokonana przez konkretnego klienta, obejmujca a~umer fotela i upodobania
dotyczce posikw.
l.l. EWOLUCJA SYSTEMW BAZ DANYCH

21

2. Informacje dotyczce rejsu: miejsce odlotu, port przeznaczenia, czas odlotu i czas przylotu oraz na przykad
typ samolotu.
3. Dane o dostpnoci biletw i wariantach cen.
Typowe zapytania dotycz rejsw midzy okrelonymi portami w okrelonym terminie, dostpnoci i
cenach odpowiednich miejsc. Rutynowe aktualizacje obejmuj rezerwacj rejsu dla klienta, przydzia miejsca i
okrelenie upodoba kulinarnych. Systemy musz zapewnia jednoczesny dostp do danych w dowolnej chwili
dla wielu agencji. Nie mog rwnie dopuci do tego, by na przykad dwie agencje przydzieliy to samo
miejsce w tym samym rejsie, ani do utraty informacji w przypadku usterek systemu komputerowego.
Systemy bankowe
Wrd elementw danych wyrnia si: nazwiska i adresy klientw, konta, kredyty i bilans na koncie oraz
powizanie klienta z jego kontem i kredytem, tzn. autoryzowanie podpisem danego konta. Wrd operacji
dominuj zapytania o bilans na koncie i, jeszcze czstsze od nich, aktualizacje dotycz ce wpyww i wypat z
kont.
Podobnie jak w przypadku systemw rezerwacji lotniczych, tak i tutaj naley oczekiwa, e wielu
klientw i urzdnikw bdzie jednoczenie korzysta z danych i aktualizowa je (poprzez bankomaty). Tego
typu transakcje nie mog by pod adnym pozorem utracone, tutaj bdw si nie toleruje. Na przykad, w
chwili gdy bankomat dokona wypaty, system musi ten fakt zanotowa, nawet jeli w tym momencie nastpi
awaria zasilania. Tak samo jest niedopuszczalne, eby zaksigowa wypat, a nie wypaci pienidzy, bo akurat
zasilanie zostao przerwane. Poprawna obsuga podobnych operacji nie jest atwa ani oczywista i naley jej
implementacj uzna za jedno z najbardziej znaczcych osigni architektury systemu DBMS.
Dokumentowanie dziaania przedsibiorstw
Wiele wczesnych wdroe dotyczy dokumentowania dziaalnoci przedsibiorstw, zapisu kadej
sprzeday, wpat i wypat z kont czy te ewidencji pracownikw: ich nazwisk, adresw, pac, jak rwnie
nagrd, podatkw itp. Zapytania dotycz raportowania wysokoci wpyww do kasy czy te wypat
pracowniczych. Kada sprzeda, zakup, rachunek, patno, zwolnienie lub zatrudnienie wyraaj si przez
aktualizacj danych.
Pierwsze systemy DBMS, powstae z systemw plikw, wymagay od uytkownika tworzenia obrazw
danych zgodnych z ich struktur w bazie. W tych systemach uywano kilku rnych modeli danych do opisu
struktury danych w bazie, prym wiody tutaj modele hierarchiczny, inaczej drzewiasty, oraz sieciowy, nazywany
take grafowym. Ten drugi mia nawet standard utworzony pod koniec lat szedziesitych w raporcie komitetu
CODASYL
ZZ 1. DZIEDZINA SYSTEMW BAZ DANYCH

(Komitet ds. systemw i jzykw danych (Committee on Data System and languages)~. W podrozdziale 2.7
Czytelnicy bd mieli sposobno pozna oba te modele: hierarchiczny i sieciowy, mimo e obecnie maj one
ju tylko historyczne znaczenie.
Kopot z uywaniem pierwszych modeli i systemw polega na tym, e nie daway one moliwoci
korzystania z jzykw zapyta wysokiego poziomu. Na przykad jzyk opracowany przez CODASYL
dostarcza instrukcje poruszania si pomidzy elementami danych w postaci grafa wskanikw do nich. Trzeba
byo nie lada wysiku, aby napisa w tym jzyku program, obsugujcy nawet bardzo proste zapytania.

1.1.2. Relacyjne systemy baz danych

Systemy baz danych zmieniy si znacznie od ukazania si w roku 1970 synnego artykuu Teda Codda"*.
Propozycja Codda polegaa na umoliwieniu prezentowania uytkownikowi danych w postaci tabel,
nazywanych relacjami. Wewntrz systemu natomiast moga powstawa zloona struktura danych, ktra
gwarantowala uzyskiwanie blyskawicznych wynikw dla rnorodnych zapyta. Ale w przeciwiestwie do
wczesnych baz danych uytkownik relacyjnych baz danych nic nie musia wiedzie o tej wewntrznej
strukturze. Zapytania mona byo wyraa w jzyku bardzo wysokiego poziomu, co w znaczny sposb
podnioso wydajno pracy programistw baz danych. Model relacyjny systemw baz danych dominuje w
naszym podrczniku, poczynajc od rozdzialu 3, gdzie pojawia si opis podstawowych poj. Od rozdzialu 5
rozpocznie si nauka jzyka SQL (structured query language jzyk zapyta strukturalnych), najwaniejszego
jzyka zapyta dla modeli relacyjnych. Krtkie wprowadzenie do relacji pozwoli Czytelnikowi uchwyci
prostot tego modelu, a przedstawiony poniej przykad w SQL obrazuje to, e model relacyjny umoliwia
naturalny zapis zapytania bez szczeglowej nawigacji" w bazie danych.
PRZYKAD 1.1
Relacje s przedstawione w postaci tabel. W nagwkach kolumn znajduj si atrybuty, ktre opisuj zawarto
kolumn. Oto przykad relacji nazwanej Konta, sucej do ksigowania kont bankowych, ich bilansu i typu.
Nr konta Bilans Typ 12345 1000,00 oszczdnociowy 67890 2846,92
rozliczeniowy

" CODASYL Data Base Task Group Apil 1971 Report, ACM, New York.
"` Codd E.F.: A relational model for (arge shared data banks. Comna. ACH, 13 : 6, s. 377
387.
1.1. EWOLUCJA SYSTEMW BAZ DANYCH 23

W nagwkach kolumn wystpuj trzy atrybuty: nr konta, bilans oraz typ. Pod nazwami atrybutw znajduj si
wiersze nazywane knotkami. Zostay wypisane dwie knotki, wielokropki umieszczone pod nimi sugeruj, e jest
o wiele wicej knotek, po jednej dla kadego konta w banku. Pierwsza knotka informuje o tym, e na koncie o
numerze 12345 zgromadzono tysic dolarw i e jest to rachunek oszczdnociowy. Dane z drugiej knotki
dotycz konta rozliczeniowego o numerze 67890 z bilansem w wysokoci 2846,92$.
Zamy, e chcemy z bazy danych otrzyma informacj o biecym bilansie konta nr 67890. Zapytanie w
SQL wyglda nastpujco:
SELECT bilans EROM Konta WHERE nr konta = 67890;
W nastpnym przykadzie pokaemy, w jaki sposb zapyta o konta
oszczdnociowe z bilansem ujemnym:
SELECT nr konta EROM Konta
WHERE typ = `oszczdnociowe' AND bilans < 0;
Nie oczekujemy oczywicie, e podanie dwch przykadw wystarczy, aby Czytelnicy stali si ekspertami
w zakresie programowania w SQL. Powinno to jednak umoliwi zrozumienie istoty zapisu instrukcji selectfromwhere tego jzyka. W zasadzie w przykadach tych zleca si systemowi baz danych przeprowadzenie
nastpujcych operacji:
1. Sprawdzenie wszystkich knotek relacji Konta, wymienionej w klauzuli EROM.
2. Wyszukanie wszystkich tych knotek, ktre speniaj warunek opisany w klauzuli WHERE.
3. Sformuowanie odpowiedzi zawierajcej wybrane knotki z uwzgldnieniem atrybutw wskazanych w
klauzuli sELECT.
W praktyce system musi zapewni optymalizacj" zapytania i znale wydajny sposb znalezienia odpowiedzi,
nawet jeli relacje, ktrych dotyczy zapytanie, s bardzo obszerne.
0
Najwczeniej na rynku pojawiy si relacyjne i przedrelacyjne" systemy DBMS, produkowane w firmie
IBM. Poza tym, aby tworzy i sprzedawa relacyjne systemy DBMS, specjalnie powstaway nowe firmy.
Niektre z nich znajduj si obecnie wrd najwikszych producentw oprogramowania na wiecie.
24 I DZIEDZINA SYSTEMW BAZ DANYCH

1.1.3. Coraz mniejsze systemy

Pocztkowo systemy zarzdzania bazami danych wymagay ogromnych komputerw, a same byy bardzo
obszerne i bardzo kosztowne. Wymagania co do wielkoci wynikay std, e tylko wielki system komputerowy
mg pomieci gigabajty danych. Obecnie gigabajt mieci si na jednym dysku i uruchomienie systemu DBMS
na komputerze osobistym stao si zupenie realne. Dlatego te relacyjne systemy baz danych pojawiaj si na
bardzo maych maszynach i zaczynaj by tak samo popularnym narzdziem w zastosowaniach technik
komputerowych, jak arkusze kalkulacyjne i edytory tekstu.

1.1.4. Coraz wiksze systemy

Patrzc na to z innej strony, gigabajt nie jest to duo danych. Bazy danych w przedsibiorstwach zajmuj
czsto setki gigabajtw. Z czasem, gdy noniki pamici staj si coraz tasze, ludzie wynajduj coraz to nowe
powody do przechowywania coraz wikszej iloci danych. Na przykad w sieciach handlu detalicznego czsto
przechowuje si terabajty (1000 gigabajtw, co oznacza 1012 bajtw) lub wiksze iloci danych,
dokumentujcych w dugim okresie kad sprzeda (do celw planowania inwestycji; wicej na ten temat
bdziemy mieli do powiedzenia w czci 1.3.4). Bazy danych nie s ju przeznaczone do prze chowywania
wycznie prostych typw danych, takich jak cakowite lub znakowe. Obecnie mona zapamitywa obrazy,
dwik, filmy i wiele innych typw danych, ktre zajmuj wzgldnie duo pamici. Na przykad film video
wywietlany przez godzin zajmuje okoo jednego gigabajta pamici. Oczekuje si, e do roku 2000 pojawi si
bazy danych ze zdjciami satelitarnymi zajmujce petabajty (1000 terabajtw rwne 1015 bajtw) pamici.
Obsuga tak wielkich baz danych wymaga zaawansowanych technik. Na przykad redniej wielkoci bazy
danych przechowuje si obecnie na dyskach, zorganizowanych w tak zwane macierze dyskowe i okrelanych
jako pamici drugiego poziomu (w odrnieniu od pamici operacyjnej, ktra nazywa si pamicic~ pierwszego
poziomu). Mona nawet pokusi si o stwierdzenie, e tym co najbardziej rni systemy baz danych od innych
rodzajw oprogramowania jest fakt, e z zaoenia dane z bazy danych s zbyt obszerne, by zmieci si w
pamici operacyjnej i musz by przez prawie cay czas przechowywane na dysku. Istniej dwa trendy, ktre
stwarzaj perspektyw uzyskiwania szybkiego dostpu do duych zasobw danych.
Pami trzeciego poziomu

Najwiksze wspczesne bazy danych potrzebuj czego wicej ni dyski. Urzdzenia trzeciego poziomu, z
ktrych kade moe przechowa terabajt danych, wymagaj duszego czasu dostpu do wybranego elementu,
ni ma
1.2. ARCHITEKTURA SYSTEMU DBMS 2S

to miejsce w przypadku dysku. Dostp do danych zapisanych na dysku zajmuje od 10 do 20 milisekund,

natomiast dostp do danych zapisanych w pamiciach trzeciego poziomu moe trwa kilka sekund. Technika
korzystania z urzdze trzeciego poziomu obejmuje midzy innymi transport nonika z zapamitanymi danymi
do urzdzenia czytajcego. Komunikacj tego typu zapewnia zastosowanie pewnego rodzaju robotw
transportowych.
Na przykad pami trzeciego poziomu moe by zorganizowana z wykorzystaniem kompaktw (CD) jako
nonikw. W takim przypadku ruchome rami wybiera wkaciwy dysk, podnosi go, przemieszcza do czytnika, a
potem umieszcza w napdzie.
Obliczenia rwnolege
Zdolno przechowania bardzo duych woluminw danych jest wana, lecz jej znaczenie byoby znikome,
gdyby nie mona byto uzyska szybkiego dostpu do danych. Dlatego te wielkie bazy danych wymagaj
rwnie postpu w zakresie szybkoci przetwarzania. Powane przyspieszenie uzyskuje si dziki zastosowaniu
struktur indeksowych, ktre omawiamy w p. 1.2.1 oraz 5.7.7. Innym sposobem przetworzenia wikszej liczby
danych w okrelonym czasie jest skorzystanie z rwnolegloci. Rwnolego moe si przejawia na kilka
sposobw.
Na przykad tempo czytania danych z dysku jest wzgldnie niskie, kilka megabajtw na sekund, lecz
proces ten mona przyspieszy, stosujc kilka dyskw i czytajc z nich jednoczenie (nawet jeli dane na
pocztku znajduj si w pamici trzeciego poziomu, to s one skladowane na dysku, zanim bd osigalne dla
systemu DBMS). Takie dyski mog stanowi cz maszyny rwnolegej lub mog by skladnikiem systemu
rozproszonego, w ktrym wiele maszyn, kada odpowiedzialna za pewien fragment bazy danych, komunikuje
si ze sob poprzez szybk sie.
Oczywicie ani zdolno do szybkiego przesyania danych, ani zdolno przechowywania wielkiej liczby
danych, nie gwarantuj szybkiego generowania wynikw dla zapyta. Naley nadal korzysta z algorytmw
dekomponujcych zapytania w taki sposb, aby zasoby komputerw rwnoleglych lub sieci komputerowych
mogly by efektywnie uyte. Std te zarzdzanie rwnolegloci i przetwarzaniem rozproszonym w duych
bazach danych stanowi obszar intensywnych badan.

1.2. Architektura systemu DBMS

W tej czci przedstawimy zarys struktury typowego systemu zarzdzania bazami danych. Przyjrzymy si
rwnie sposobom przetwarzania zapyta i innych operacji na bazach danych. W kocu rozwaymy problemy
wynika
2C) 1. DZIEDZINA SYSTEMW BAZ DANYCH

jce przy projektowaniu DBMS, przeznaczonych do obsugi wielkich zasobw danych i szybkiego
przetwarzania zapyta. Jednak technologia implementowania DBMS nie jest tematem wiodcym w naszej
ksice, dlatego te skoncentrujemy uwag na tym, w jaki sposb projektowa bazy danych i korzysta z nich w
efektywny sposb.

1.2.1. Przegld skadowych systemu DBMS

Na rysunku 1.1 przedstawiono najbardziej istotne fragmenty DBMS. Na samym dole widzimy element
reprezentujcy miejsce skadowania danych. Zauwamy, e ten element suy nie tylko do zapisu danych, ale
take metadanych, ktre opisuj struktur danych. Na przykad, jeli rozwaany DBMS jest relacyjny, to
metadane obejmuj nazwy relacji, nazwy atrybutw relacji i typy poszczeglnych atrybutw (np. cakowity lub
znakowy o dugoci nie wikszej ni 20).
Modyfikacje Za tania Aktualizacje schematu py
Procesor zapyta
Modu zarzadzania transakcjami
Modu zarzdzania pamicia
Dane Metadane
RYSUNEK 1.1
Gwne elementy systemu DBMS
Czsto system DBMS obsuguje indeksy danych. Indeks jest tak struktur danych, ktra pomaga w szybkim
odnajdywaniu waciwych danych, a posuguje si przy tym ich wartociami; najbardziej popularny przykad
indeksu
1.2. ARCHITEKTURA SYSTEMU DBMS 2%

umoliwia odnalezienie waciwej krotki relacji, majcej zadane wartoci pewnych atrybutw. Na przykad
relacja obejmujca numery kont i bilans moe mie indeks zaoony na numerach kont, wwczas odnalezienie
bilansu konta o podanym numerze odbywa si byskawicznie. Indeksy s przechowywane razem z danymi, a
informacja o tym, ktry atrybut ma zaoone indeksy, naley do metadanych.
Jak s zaimplementowane indeksy
Z wykadu dotyczcego struktur danych Czytelnicy zapewne dowiedzieli si, e bardzo skutecznym sposobem
tworzenia indeksu s tablice haszowania. Byy one szeroko stosowane we wczesnych systemach DBMS.
Obecnie najbardziej rozpowszechnion struktur danych s B-drzewa, gdzie B" oznacza balanced zrwnowaony". B-drzewo stanowi uoglnienie zrwnowaonego binarnego drzewa przeszukiwa. Rnica
polega na tym, e kady wierzchoek drzewa binarnego ma co najwyej dwch potomkw, a wierzchoki Bdrzewa mog mie ich wicej. Z zaoenia B-drzewo jest zapisywane na dysku, zamiast w pamici operacyjnej,
i jest tak projektowane, aby jeden wierzchoek zajmowa cay jeden blok na dysku. Poniewa w typowym
systemie bloki dyskowe zajmuj okoo 2I2 bajtw (4096 bajtw), wic daje to sposobno zapisania setek
wskanikw do potomkw w jednym bloku B-drzewa. Std te przeszukiwanie B-drzewa rzadko kiedy wymaga
wicej ni trzech dostpw do dysku.
Rzeczywisty koszt przeszukiwania dysku w zasadzie jest proporcjonalny do liczby dostpw do dysku.
Std te przeszukiwania B-drzewa, ktre zwykle polegaj na sprawdzeniu trzech blokw na dysku, s znacznie
bardziej wydajne ni przeszukiwania drzew binarnych, ktre wymagaj zazwyczaj odszukania wierzchokw
znajdujcych si w wielu ronych blokach na dysku. Rnica midzy B-drzewami a drzewami binarnymi jest
jednym z wielu przykadw tego, e struktury danych bardzo odpowiednie dla danych przechowywanych na
dysku s zupenie inne ni struktury danych uywane w algorytmach operujcych wycznie na danych,
znajdujcych si w pamici operacyjnej.
Na rysunku 1.1 mona take dostrzec modu zarzc~dzania pami4cict, ktry ma za zadanie wybiera
waciwe dane z pamici i w razie potrzeby dostosowa je do wymaga moduw z wyszych poziomw
systemu. Wida tam take skadow, ktr nazwalimy moduem przetwarzania zapyta, mimo e taka nazwa
moe wprowadza w bd, bowiem obsuguje on nie tylko zapytania, ale rwnie aktualizacje danych oraz
metadanych. Jego zadanie polega na znalezieniu najlepszego sposobu wykonania zadanych operacji i na
wydaniu polece do moduu zarzdzania pamici, ktry je wykona.
Modus zarzcidzania transakcjami odpowiada za spjno systemu. Musi on gwarantowa, e kilka
jednoczenie przetwarzanych zapyta nie bdzie
28
1. DZIEDZINA SYSTEMW BAZ DANYCH

sobie wzajemnie przeszkadza oraz e adne dane nie zostan utracone, nawet jeli nastpi awaria systemu.
Wspdziaa on z moduem obsugi zapyta, poniewa musi mie dostp do szczegw dotyczcych tych
danych, na ktrych przetwarza si biece zapytania (w celu uniknicia konfliktw). Moe si zdarzy, e cz
przetwarzania bdzie musiaa zosta opniona, aby nie powsta konflikt.
U gry rysunku 1.1 mona zobaczy trzy rodzaje wej do systemu DBMS: 1. Zapytania. S to pytania o dane.
Mog one by sformuowane dwojako:
a) Poprzez interfejs zapyta bezporednich. Na przykad relacyjny DBMS umoliwia wprowadzenie zapyta
w SQL, ktre s nastpnie przekazywane do moduu przetwarzania zapyta, ktry z kolei tworzy
odpowied.
b) Poprzez interfejsy programw uytkowych. Typowy DBMS umoliwia programicie utworzenie programu
uytkowego, ktry poprzez wywoania procedur DBMS tworzy zapytania do bazy danych. Na przykad
agent posugujcy si systemem rezerwacji lotniczych uruchamia program uytkowy, ktry tworzy
zapytanie do bazy danych dotyczce dostpnoci rejsw. Zapytania mog by formuowane dziki
specjalizowanemu interfejsowi, ktry na og skada si z formularzy z pustymi polami, przeznaczonymi
do wypenienia konkretnymi danymi, np. nazw miasta, terminem itp. Nie mona w ten sposb zada
zupenie dowolnego pytania, ale jest znacznie atwiej sformuowa typowe zapytanie poprzez taki interfejs, ni formuowa zapytanie bezporednio w jzyku SQL.
2. Aktualizacje. S to operacje zmiany danych. Tak jak w przypadku zapyta mona je wprowadza do systemu
poprzez interfejsy zapyta bezporednich lub poprzez interfejsy programw uytkowych.
3. Modyfikacje schematu. Polecenia tego rodzaju wydaje specjalnie uprawniona osoba nazywana
administratorem bazy danych, ktrej wolno zmienia schemat bazy danych i tworzy nowe bazy danych. Na
przykad, jeli agencje rzdowe wezw banki do udokumentowania wypaty odsetek zgodnie z numerami
ubezpieczenia spoecznego klientw, to bank moe zada dodania do relacji opisujcej klientw nowego
atrybutu o nazwie nrUbezpieczenia.

1.2.2. Modus zarzdzania pamici

W prostych systemach baz danych modu zarzdzania pamici moe by tym samym co system plikw
podstawowego systemu operacyjnego. Jednak na og, przynajmniej w pewnych okolicznociach, DBMS
bezporednio zarzdza przestrzeni na dysku, co jest podyktowane wzgldami
1.2. ARCHITEKTURA SYSTEMU DBMS 29

efektywnoci. Modu zarzdzania pamici skada si z dwch czci: moduu zarzdzania buforami oraz
moduu zarzdzania plikami.
1. Modul zarzdzania plikami przechowuje dane o miejscu zapisania plikw na dysku i na polecenie moduu
zarzdzania buforami przesya zawarto bloku lub blokw, gdzie jest zapamitany dany plik. Prosz sobie
przypomnie, e dyski zazwyczaj s zorganizowane w postaci blokw dyskowych, czyli spjnych obszarw o
stosunkowo duej pojemnoci 2'2 lub 2'4 bajtw (od 4000 do 16000 bajtw).
2. Modu zarzdzania buforami obsuguje pami operacyjn. Modu zarzdzania plikami przekazuje bloki
danych z dysku, a modu zarzdzania buforami wybiera w pamici operacyjnej strony, ktre zostan
przydzielone dla wybranych blokw. Blok z dysku moe by przez chwil przechowany w pamici
operacyjnej, ale musi zosta przesany z powrotem na dysk, gdy tylko pojawi si potrzeba zapisania w to
miejsce pamici operacyjnej innego bloku. Powrt bloku na dysk moe nastpi rwnie w wyniku dania
moduu obsugi transakcji (zob. p. 1.2.4).

1.2.3. Module zarzdzania zapytaniami

Zadaniem moduu zarzdzania zapytaniami jest przeksztacenie zapytania lub operacji na bazie danych,
wyraanych zazwyczaj w jzyku bardzo wysokiego poziomu (np. jako zapytanie SQL), w cig polece
dajcych dostarczenia okrelonych danych, takich jak konkretne krotki zadanej relacji lub fragmenty indeksu
relacji. Czsto najtrudniejsz operacj przetwarzania zapyta jest optymalizacja zapytania, tzn. wybr dobrego
planu pytania lub cigu polece do systemu zarzdzania pamici, ktrego wykonanie wygeneruje waciw
odpowied w moliwie najkrtszym czasie.
PRZYKAD 1.2
Zamy, e bank opracowa baz danych z dwiema relacjami:
1. Klienci: jest to tabela, ktra zawiera nazwiska klientw banku, ich numer polisy ubezpieczenia spoecznego
oraz adres.
2. Konta: jest to tabela zawierajca dane o kontach, obejmujce numer konta, bilans oraz numer polisy
ubezpieczenia spoecznego waciciela konta. Warto zauway, e kade konto ma gwnego waciciela,
ktrego numer polisy suy celom podatkowym; mog istnie jeszcze inni waciciele konta, ale na
podstawie tych dwch relacji uie mona o nich uzyska informacji.
Zamy rwnie, e zostao utworzone zapytanie znale bilanse tych wszystkich kont, ktrych gwnym
wacicielem jest Anna Nowak". Modu
3O 1. DZIEDZINA SYSTEMW BAZ DANYCH

zarzdzania zapytaniami musi okreli dla tego zapytania plan, ktrego wykonanie doprowadzi do utworzenia
poprawnej odpowiedzi. Im mniej jest krokw w trakcie tworzenia odpowiedzi, tym plan jest lepszy. W zasadzie
kosztowne s te operacje, ktre prowadz do kopiowania blokw dysku do pamici lub kopiowania stron
pamici operacyjnej na dysk, angaujce modu zarzdzania pamici. Z tego powodu warto przy okrelaniu
kosztu planu zapytania bra pod uwag tylko operacje przesyania danych midzy pamiciami operacyjn a
pomocnicz.
Utworzenie odpowiedzi wymaga przeszukania relacji Klienci w celu odnalezienia numeru polisy nalecej
do Anny Nowak (zakadamy, e w bazie wystpuje tylko jedna klientka o takim nazwisku, jednak w praktyce
moe ich by wicej). Potem trzeba przeszuka relacj Konta i odnale wszystkie konta o waciwym numerze
polisy, a nastpnie wydrukowa bilanse z tych kont.
Prosty, ale kosztowny plan polega na przejrzeniu wszystkich krotek (wierszy) relacji Klienci, a do
odnalezienia tej, zawierajcej nazwisko Anna Nowak. redni koszt takiej operacji wymaga przejrzenia poowy
krotek zanim napotkamy waciw. Poniewa bank ma wielu klientw, wic tabela Klienci zajmuje duo
blokw dysku i koszt bdzie wysoki. A odnalezienie numeru polisy Anny Nowak nie koczy zadania. Teraz
trzeba przeglda krotki relacji Konta i wybra te wszystkie, w ktrych wystpuje znaleziony uprzednio numer
polisy. W typowym banku jest wiele kont, a zatem relacja Konta rwnie musi zajmowa wiele blokw dysku.
Sprawdzenie ich wszystkich musi te by kosztowne.
Jeeli jednak zosta zaoony indeks dla relacji Klienci na atrybucie nazwiska, to istnieje lepszy plan.
Zamiast przeszukiwa ca relacj Klienci skorzystamy z indeksu, ktry wskae blok, zawierajcy krotk
waciw dla Anny Nowak. Jak ju wspomniano w p. 1.2.1, odnalezienie waciwego bloku za pomoc

typowego indeksu, zbudowanego jako B-drzewo, wymaga przejrzenia trzech blokw indeksu. Jeszcze jeden
dostp do dysku pozwala otrzyma krotk odpowiadajc Annie Nowak.
Oczywicie nadal pozostaje do zrobienia drugi krok: znalezienie kont z odpowiednim numerem polisy w
relacji Konta. Zazwyczaj wymaga to wielokrotnego dostpu do dysku. Jeli jednak dla relacji Konta zaoono
indeks na atrybucie numer polisy, to moemy wedug tego indeksu przeszukiwa tylko te bloki, w ktrych
wystpuj poszukiwane krotki, zawierajce odnaleziony uprzednio numer polisy. Trzeba wwczas wykona 2
lub 3 operacje dyskowe, przegldajc indeks, podobnie jak w przypadku indeksowanego dostpu do relacji
Klienci. Jeli wszystkie potrzebne krotki sw rnych blokach dysku, to trzeba dosta si do kadego z tych
blokw. Ale prawdopodobnie jedna oso
" W rzeczywistoci poniewa kade przeszukania B-drzewa wymaga przjrzenia korzeuia, wic ten blok
przewanie jest na stalce w pamici operacyjnej, zajmujc jedn stron pamici. Std te tak naprawd
skorzystanie z tego rodzaju indeksu wymaga zazwyczaj tylko dwch operacji dostpu do dysku.
1.2. ARCHITEKTURA SYSTEMU DBMS 3 1

ba nie ma zbyt wielu kont, wic cae dziaanie sprowadzi si pewnie do niewielu operacji dyskowych. Jeli
zostay zaoone oba indeksy, to mona utworzy odpowied na zapytanie, angaujc w to od 6 do 10 operacji
dostpu. Jeli ktry z nich, albo aden, nie istnieje i musimy korzysta z gorszych planw zapyta, to operacj i
dostpu do dysku moe by potrzebnych setki, a nawet tysice, poniewa trzeba sprawdza wwczas ca,
obszern relacj.
0
Na podstawie przykadu 1.2 mona odnie wraenie, e optymalizacja zapyta polega wycznie na
korzystaniu z indeksw, o ile takie istniej. Jednak w rzeczywistoci takie procedury s duo bardziej zoone.
Skomplikowane zapytanie umoliwia na przykad zmian kolejnoci wykonywania operacji, co z kolei stwarza
moliwo utworzenia wielu planw wykonania takiego zapytania, ich liczba moe rosn w stosunku do
wielkoci zapytania nawet wykadniczo. Czsto mamy do wyboru dwa indeksy i trzeba wybra ktry z nich.
Rozwizania na temat implementacji tego wanego elementu DBMS s jednak ju poza zakresem naszej ksiki

1.2.4. Modu zarzdzania transakcjami

Jak ju wspomnielimy w podrozdziale 1.l, DBMS musi wykonanie niektrych operacji na bazie danych
obj specjalnymi gwarancjami. Stwierdzilimy wwczas, e wynik pewnych operacji nie moe zagin, nawet
w przypadku awarii systemu. Typowy DBMS stwarza uytkownikowi sposobno czenia jednego lub wicej
zapyta, bd modyfikacji, w transakcj, ktra stanowi nieformaln grup operacji przeznaczonych do
wykonania razem w jednym cigu, jako dua operacja jednostkowa.
Czsto system baz danych umoliwia jednoczesne przetwarzanie transakcji, na przykad co si moe
dzia jednoczenie na wielu bankomatach. Poprawno i kompletno przeprowadzenia wszystkich transakcji
gwarantuje w systemie DBMS modul zarzddzania transakcjami. Poprawno" przeprowadzenia transakcji
bardziej szczegowo opisuj ponisze waciwoci, inicjay ich angielskich nazw tworz sowo ACID. A oto te
waciwoci:
Niepodzielno (atomicity). damy, aby albo caa transakcja zostaa przeprowadzona, albo wcale - aden z jej
elementw nie zostanie uwzgldniony. Na przykad podjcie pienidzy z bankomatu i powizany z tym zapis
wypaty na koncie klienta musz stanowi jedn niepodzieln transakcj. Nie mona zaakceptowa wypaty
pienidzy i niezapisania tego faktu na koncie klienta, nie mona rwnie zgodzi si na to, by zapisa wypat, a
nie wypaci pienidzy.
Spjno (consistency). Baza danych musi stwarza warunki spjnoci, dane musz zaspakaja nasze
oczekiwania. Na przykad jeden
32 1. DZIEDZINA SYSTEMOW BAZ DANYCH

z warunkw spjnoci dla bazy danych linii lotniczych okrela, e jedno miejsce w konkretnym rejsie nie
zostanie przydzielone dwm rnym klientom. Taki warunek moe zosta naruszony tylko na krciutk chwil
podczas przetwarzania transakcji, gdy przydziela si miejsca dla pasaerw, ale modu zarzdzania transakcjami
musi zagwarantowa, e po zakoczeniu przetwarzania transakcji baza danych spenia wszystkie warunki
niesprzecznoci.
Izolacja (isolation). Gdy dwie transakcje s przetwarzane jednoczenie, ich dziaania nie mog na siebie
wzajemnie wpywa. To oznacza, e w wyniku jednoczesnego dziaania dwch transakcji nie moe zdarzy si
nic, co nie stao by si, gdyby dziaay jedna po drugiej, sekwencyjnie. Na przykad, jeli dwie agencje lotnicze
sprzedaj bilety na ten sam rejs, a zostao tylko jedno miejsce, to tylko jedno danie powinno zosta obsuone,
a drugie nie. Jednoczesno przeprowadzania transakcji nie moe spowodowa sprzeday tego samego biletu
dwm rnym osobom.
Trwalo (durability). Jeli transakcja si zakoczy, to jej wynik nie moe zosta utracony z powodu awarii
systemu, nawet jeli awaria nastpuje natychmiast po zakoczeniu transakcji.

Sposb implementowania transakcji, ktry zapewnia zachowanie waciwoci ACID, moe by tematem
zupenie oddzielnej ksiki i nie zamierzamy nawet prbowa pomieci tutaj stosownych treci. W czci 7.2
opisujemy natomiast w jaki sposb, w jzyku SQL, okreli transakcje i waciwe dla nich operacje oraz jakie
gwarancje uzyskuje programista, ktry korzysta z moliwoci grupowania operacji w transakcje. Poza tym
bardzo skrtowo przedstawimy tam popularne rozwizania techniczce zapewniajce transakcjom waciwoci
ACID.
Granulacja blokad
Systemy DBMS rni si rozmiarami elementw danych, ktre s poddawane blokowaniu. Na przykad mona
zastosowa blokad na poziomie pojedynczych krotek, poszczeglnych blokw dysku lub nawet na poziomie
caych relacji. Im wiksze s elementy, ktre blokujemy, tym bardziej jest prawdopodobne, e jedna transakcja
bdzie musiaa czeka na inn, nawet jeli nie potrzebuj dostpu do tych samych danych. Jednake, im
mniejsze s blokowane elementy, tym wikszy i bardziej skomplikowany musi by mechanizm obsugi blokad.
Blokady
Najczstsz przyczyn nierozcznoci transakcji jest konieczno czytania lub zapisu tych samych danych
w bazie danych. Na przykad, jeli dwie
1.2. ARCHITEKTURA SYSTEMU DBMS 3 3

transakcje prbuj jednoczenie zapisa nowe wartoci bilansu na tym samym koncie, to jedna z transakcji
zniszczy zapis wykonany przez drug z nich. Dlatego w wikszoci DBMS modul zarzdzania transakcjami
potrafi zablokowa element, ktrego dotyczy wykonywana wanie transakcja. Po zaloeniu blokady dane s
niedostpne dla innych transakcji. Mechanizm blokad w naszym przykadzie poskutkuje w ten sposb, e
transakcja, dla ktrej zostanie zablokowana krotka z bilansem konta 12345, bdzie moga odczytywa wartoci
tej krotki i zmienia je, zanim druga transakcja uzyska dostp do tej krotki. Druga transakcja uzyska zatem
dostp do nowych wartoci bilansu, co oznacza, e transakcje nie przeszkadzaj sobie.
Logi
Modul zarzdzania transakcjami dokumentuje wszystkie operacje, tzn. rozpoczcie kadej transakcji,
zmiany w bazie danych dokonane przez transakcje oraz zakoczenie transakcji. Zapis taki nazywa si logiem.
Log jest przechowywany w pamici stalej, tzn. na noniku danych takim jak dysk, ktry zapewni przetrwanie
danych w przypadku awarii zasilania. Zasadnicze przetwarzanie transakcji odbywa si w ulotnej pamici
operacyjnej, ale dane o przebiegu jej wykonania s natychmiast zapisywane na dysku. Log wszystkich operacji
jest wanym czynnikiem zapewniajcym systemowi trwao.
Zatwierdzanie transakcji
Z powodu koniecznoci zagwarantowania transakcjom niepodzielnoci i trwaloci s one najpierw
wstpnie przetwarzane, co oznacza, e aktualizacje s wyliczane, ale nie s zapisywane w bazie danych. W
chwili gdy transakcja koczy dziaanie, jest gotowa do zatwierdzenia, zmiany s kopiowane do logu. Log jest
pierwszym zapisem dokonanym na dysku przez transakcj. Dopiero potem nastpujaktualizacje danych.
Nawet jeli awaria systemu nastpi w trakcie przetwarzania operacji, to po przywrceniu funkcjonowania
mona przeczyta logi i stwierdzi, ktre zmiany trzeba jeszcze wprowadzi do bazy danych. Jeli awaria
systemu nastpi przed zapamitaniem logu, trzeba powtrzy ca transakcj, co zagwarantuje, e na przykad
nie przydzielono dwukrotnie tego samego miejsca w samolocie lub nie obciono dwukrotnie konta t sam
wypat.

1.2.5. Architektura klient-serwer

W wielu wspczesnych systemach informatycznych stosuje si architektur klient-serwer, gdzie polecenie
jednego procesu (klienta) jest przesylane do innego procesu (serwera) i tam obslugiwane. Systemy baz danych
nie stanowi wyjtku i czsto wprowadza si podzial skadowych z rys. 1.1 na proces serwem i jeden lub kilka
procesw klienckich.
34 1. DZIEDZINA SYSTEMW BAZ DANYCH

W najprostszych systemach typu klient/serwer cay DBMS stanowi serwer, a tylko interfejs zapyta
wspdziaa z uytkownikiem przy definiowaniu zapytania i przesya je jako klient do obsugi serwerowi. Na
przykad relacyjne systemy baz danych zlecenia klienta do serwera przedstawiaj w formie programw w
jzyku SQL. Serwer bazy danych przesya nastpnie odpowied w postaci tabeli lub formularza do klienta.
Zwizek midzy klientem a serwerem moe si bardziej komplikowa, szczeglnie jeli odpowiedzi s
ekstremalnie wielkie. Wicej na ten temat bdzie mona dowiedzie si po przeczytaniu p. 1.3.3. Od kiedy
dostp do serwera, z powodu wielu jednoczenie dziaajcych uytkownikw baz danych, stal si wskim
gardem, zarysowaa si tendencja rozbudowy zada klienckich.

1.3. Przysz~o systemw baz danych

Obecnie w dziedzinie baz danych obserwuje si wiele nowych prdw, ktre powoduj zmiany kierunkw jej
rozwoju. Niektre z nich s zwizane z nowymi technologiami, takimi jak na przykad programowanie
zorientowane obiektowo, wizy i wyzwalacze lub dane multimedialne, albo ze zjawiskami, ktre cakiem
zmieniaj natur DBMS, jak stao si za przyczyn wiatowej sieci WWW. Inne prdy, takie jak hurtownie
danych lub integracja danych, s zwizane z nowymi aplikacjami. W biecej czci przedstawimy gwne
trendy rozwoju przyszych systemw baz danych.

1.3.1. Typy, klasy i obiekty

Programowanie zorientowane obiektowo jest oceniane w szerokich krgach jako narzdzie, ktre pozwala
lepiej organizowa program i implementowa zdecydowanie bardziej niezawodne oprogramowanie.
Spopularyzowa je jzyk Smalltalk, ale naprawd rozgos nada mu rozwj jzyka C++ i migracja wikszoci
oprogramowania tworzonego uprzednio w jzyku C do postaci zapisanej w C++. Teraz uwag przykuwa inny
jzyk zorientowany obiektowo, sucy do uruchamiania programw poprzez sie WWW - jzyk Java. wiat
baz danych wykazuje rwnie zainteresowanie podejciem obiektowym i kilka firm sprzedaje systemy DBMS
opatrzone napisem zorientowane obiektowo". Nastpny fragment rozdziau powicimy przegl dowi tego, co
kryje si pod pojciem obiektowoci.
System typw
,fzyki programowania zorientowane obiektowo oferuj uytkownikowi bogaty zestaw typw. Zaczynajc
od typw podstawowych, obejmujcych
1.3. PRZYSZO SYSTEMW BAZ DANYCH 3 S

zazwyczaj liczby cakowite i rzeczywiste, wartoci logiczne i znaki, mona tworzy nowe typy pochodne,
korzystajc w tym celu z konstruktorw typw. Zazwyczaj konstruktory umoliwiajtworzenie:
1. Rekordw (record structures). Zalmy, e dane s typy Tl, T2, ..., T, a odpowiadajce im pola (nazywane w
Smalltalku zmiennymi indywidualnymi) maj nazwy f~, fZ, ..., fn. Mona wwczas utworzy nowy typ przez
struktur rekordu zloonego z n skadowych. I-ta skladowa jest typu T;, a mona si do niej odwola przez
nazw f. W jzykach C i C++ rekordy s deklarowane sowem struct".
2. Kolekcji (collection types). Z danego typu T mona tworzy typy pochodne, stosujc w tym celu operator
kolekcji. W rnych jzykach operatory kolekcji rni si, ale cz z nich, na przykad tablice, li sty i
zbiory, jest charakterystyczna dla wielu jzykw. Oznacza to, e gdy typ cakowity jest okrelony jako
bazowy, to mona tworzy na przykad nastpujce kolekcje: tablica typu calkowitego", lista typu
calkowitego" lub zbir typu calkowitego".
3. Referencje (references types). Referencja (odniesienie) do typu T jest typem, ktrego wartoci s odpowiednie
do przechowywania wartoci typu T. W jzykach C i C++ referencja jest wskanikiem" do wartoci, to
znaczy jest to miejsce, w ktrym przechowywany jest adres wirtualny wskazywanej wartoci. Model
wskanikw zazwyczaj wystarcza do zrozumienia referencji. Jednak w systemach baz danych, tam gdzie da ne przechowuje si na wielu dyskach i czsto bywaj one rozproszone pomidzy wiele komputerw, pojcie
referencji jest bardziej zoone ni wskanika. Obejmuje ono wwczas rwnie systemow nazw
komputera, numer dysku, numer bloku, a w kocu pozycj w bloku, gdzie jest przechowywana wskazywana
warto.
Oczywicie operatory kolekcji i rekordw mona wielokrotnie na siebie nakada i tworzy w ten sposb
coraz bardziej zoone typy. Na przykad mona zdefiniowa rekord, ktrego pierwsza skadowa, o nazwie
klient, jest typu znakowego, druga natomiast jest zbiorem elementw typu cakowitego (czyli typem
pochodnym) i nazywa si konta. Taki typ jest bardzo odpowiedni przy wizaniu informacji o klientach i
numerach ich kont bankowych.
Klasy i obiekty
Klasa stanowi polczenie typu oraz jednej lub kilku funkcji albo procedur, (nazywanych
metodami), ktre mona wykonywa na obiektach danej klasy. Obiekty klasy s albo wartociami
danego typu (tzw. obiekty niemutowalne), albo zmiennymi o wartociach danego typu (tzw. obiekty
mutowalne). Na przykad, jeli zdefiniujemy klas C, ktrej typem jest zbir wartoci cakowitych, to f
2, S, 7) bdzie niemutowalnym obiektem klasy C, podczas gdy
3 C) 1. DZIEDZINA SYSTEMW BAZ DANYCH

zmienna s moe otrzyma typ C, a tylko jej chwilowa warto bdzie rwna konkretnemu zbiorowi {2, 5, 7}.
Identyfikator obiektu
Zakada si, e obiektom przysluguje identyfikator (object identity OID). adne dwa obiekty nie mog
mie tego samego identyfikatora, ani aden obiekt nie moe mie wicej ni jednego identyfikatora.
Identyfikatorem jest warto, ktr przyjmuje odniesienie do obiektu. Mona czsto utosamia identyfikator
obiektu ze wskanikiem do obiektu w pamici wirtualnej, ale, jak ju wspomniano przy okazji omawiania typu
odniesienie, identyfkator moe w przypadku bazy danych by czym znacznie bardziej zoonym: cigiem

bitw pozwalajcym na dokadne umiejscowienie obiektu w pamici drugiego lub trzeciego poziomu na jednym
z wielu rnych komputerw. A poza tym, poniewa dane maj charakter trway, wic identyfikator musi mie
waciw warto przez cay czas ich istnienia.
Metody
Z klasami s zazwyczaj powizane pewne funkcje, czsto nazywane metodami. Metoda klasy C ma co
najmniej jeden argument, jest nim obiekt klasy C. Jeli na przyklad zdefiniujemy klas, ktrej typem jest zbir
liczb calkowitych", to mona mie metod sluc do wyliczenia zbioru potgowego danego zbioru, sumy
dwch zbiorw lub tak, ktra zwraca warto logiczn suc do sprawdzenia, czy zbir nie jest pusty.
Abstrakcyjne typy danych
W wielu przypadkach klasy s take abstrakcyjnymi typami danych, co znaczy, e ograniczaj dostp do
obiektu tylko dla metod, ktre s specjalnie dla tych klas zdefiniowane, a z kolei tylko te metody umoliwiaj
aktualizowanie obiektw danej klasy. Taka waciwo nazywa si hermetyzacja. Jej przestrzeganie gwarantuje,
e obiekty danej klasy nie bd zaktualizowane w sposb, ktrego nie zaplanowal implementator. Ocenia si, e
jest to obecnie podstawowy mechanizm tworzenia niezawodnego oprogramowania.
Hierarchie klas
Mona zadeklarowa klas C jako podklas innej klasy D. W takim przypadku klasa C dziedziczy wszystkie
cechy klasy D, to znaczy jej typ i wszystkie funkcje. Jednak klasa C moe mie take dodatkowe elementy.
Mona na przykad definiowa nowe metody dla obiektw klasy C i mog to by zupeknie nowe, dodatkowe
metody albo takie, ktre zastpi metody klasy D. Istniej nawet pewne sposoby rozszerzenia typu klasy D.
Gwny z nich dotyczy rekordw
13. PRZYSZO SYSTEMW BAZ DANYCH 3

i polega na tym, e jeli podstawowym typem klasy D jest rekord, to mona doczy nowe pola, ktre bd
wystpowa tylko w obiektach typu C.
PRZYKAD 1.3
Rozwamy klas obiektw kont bankowych. Nieformalnie moemy opisa typ tej klasy w nastpujcy sposb:
CLASS Konto = {Nrkonta: integer;
bilans: real; waciciel: REF Klient;
Typem klasy Konta jest rekord z trzema polami: calkowitym numerem konta, bilansem typu rzeczywistego oraz
wacicielem, ktry wskazuje na obiekt klasy Klient (innej klasy potrzebnej do obiektowego projektu bazy kont
bankowych, ale ktrej typu nie bdziemy definiowa).
Dlaczego obiekty?
Programowanie zorientowane obiektowo oferuje szereg moliwoci o szczeglnym znaczeniu dla baz danych.
Dziki rozbudowanemu systemowi typw moemy mie do czynienia z formatem danych bardziej naturalnym
ni relacje lub wczeniejsze modele danych. Naley zauway, e model relacyjny ma do ograniczony system
typw. Relacje s zbiorami rekordw, a rekordy s zoone z pl (nazywanych w relacyjnym modelu atry butami), ktrych typ musi nalee do jednego z typw podstawowych.
Dziki klasom i ich hierarchiom mona wielokrotnie korzysta z gotowych fragmentw oprogramowania
znacznie czciej ni wystpuje to w przypadku konwencjonalnych systemw.
Dziki abstrakcyjnym typom danych mona chroni dane przed niewlaciwym uyciem poprzez ograniczenie
dostpu do nich, ktry staje si moliwy tylko za porednictwem pewnych specjalnie w tym celu
zaprojektowanych funkcji.
Mona by zdefiniowa take jakie metody dla tej klasy. Niech to bdzie na przykad metoda
wpata( a: Konto, m: real)
ktra powoduje dodanie do wartoci bilansu obiektu a typu Konto wartoci m.
13. PRZYSZO SYSTEMW BAZ DANYCH 3%

i polega na tym, e jeli podstawowym typem klasy D jest rekord, to mona doczy nowe pola, ktre bd
wystpowa tylko w obiektach typu C.
PRZYKAD 1.3
Rozwamy klas obiektw kont bankowych. Nieformalnie moemy opisa typ tej klasy w nastpujcy sposb:
CLASS Konto = {Nrkonta: integer; bilans: real; waciciel: REF Klient;
Typem klasy Konta jest rekord z trzema polami: cakowitym numerem konta, bilansem typu rzeczywistego oraz
wacicielem, ktry wskazuje na obiekt klasy Klient (innej klasy potrzebnej do obiektowego projektu bazy kont
bankowych, ale ktrej typu nie bdziemy definiowa).
Dlaczego obiekty?
Programowanie zorientowane obiektowo oferuje szereg moliwoci o szczeglnym znaczeniu dla baz danych.
Dziki rozbudowanemu systemowi typw moemy mie do czynienia z formatem danych bardziej naturalnym
ni relacje lub wczeniejsze modele danych. Naley zauway, e model relacyjny ma do ograniczony system

typw. Relacje s zbiorami rekordw, a rekordy s zoone z pl (nazywanych w relacyjnym modelu atry butami), ktrych typ musi nalee do jednego z typw podstawowych.
Dziki klasom i ich hierarchiom mona wielokrotnie korzysta z gotowych fragmentw oprogramowania
znacznie czciej ni wystpuje to w przypadku konwencjonalnych systemw.
Dziki abstrakcyjnym typom danych mona chroni dane przed niewaciwym uyciem poprzez ograniczenie
dostpu do nich, ktry staje si moliwy tylko za porednictwem pewnych specjalnie w tym celu
zaprojektowanych funkcji.
Mona by zdefiniowa take jakie metody dla tej klasy. Niech to bdzie na przykad metoda
wpata( a: Konto, m: real)
ktra powoduje dodanie do wartoci bilansu obiektu a typu Konto wartoci m.
3 g 1. DZIEDZINA SYSTEMW BAZ, DANYCH

W kocu zayczymy sobie kilku podklas klasy Konta. Na przykad konto depozytw terminowych moe
mie dodatkowe pole termin, w ktrym zapisze si dat, po upywie ktrej waciciel bdzie mg dokonywa
wypat. Dla tej podklasy, nazwanej na przykad DepozytTerminowy, mona zdefiniowa metod:
kara (a: DepozytTerminowy)
ktra dla konta a wylicza obcienie karne wynike z tytuu zbyt wczesnej wypaty, a ktre jest moliwe do
wyliczenia na podstawie daty biecej oraz wartoci pola termin obiektu a. Dat biecotrzymuje si z systemu
operacyjnego komputera.
0
Zorientowane obiektowo aspekty baz danych bdziemy omawia bardzo obszernie w niniejszej ksice. W
podrozdziale 2.1 wprowadzimy zorientowany obiektowo jzyk projektowania baz danych ODL (object-oriented
database-design language). Z kolei rozdzia 8 powicilimy zorientowanym obiektowo jzykom zapyta,
zarwno jzykowi OQL, ktry staje si standardem dla baz danych zorientowanych obiektowo, jak i
obiektowym waciwociom jzyka SQL - standardu zapyta w relacyjnych bazach danych.

1.3.2. Wizy i wyzwalacze

Obecnie w bazach danych daje si zaobserwowa szerokie zastosowanie elementw aktywnych w systemach
komercyjnych. Przez aktywno" elementu rozumiemy, e dana skadowa bazy danych jest cay czas dostpna
i jest gotowa do wykonania zawsze wtedy, kiedy staje si to waciwe. W bazach danych mona wyrni dwa
rodzaje elementw aktywnych:
1. Wizy (constraints). S to funkcje logiczne, ktre zawsze powinny mie warto prawda. W bankowej bazie
danych moglibymy na przykad umieci wymaganie, okrelajce, e warto bilansu na koncie nie moe
by mniejsza ni 0. Wwczas aktualizacja polegajca na wypacie z konta kwoty wikszej ni warto
zapisana w bilansie zostaaby zabroniona przez DBMS, jako naruszajca wymaganie okrelone przez wizy.
2. Wyzwalacze (triggers). Wyzwalacz stanowi kawaek kodu, ktry czeka na zajcie zdarzenia; zdarzenia
mogpolega na wprowadzeniu lub usuniciu pewnego rodzaju danych. Po zajciu zdarzenia zostaje wykonany, lub inaczej mwic wyzwolony, cig akcji. Na przykad w systemie rezerwacji lotw moe wystpi
regua, wyzwalajca pewne akcje wwczas, gdy zostaje odwoany jaki rejs. Cz wyko
1.3. PRZYSZO SYSTEMW BAZ DANYCH

39
nywalna reguy moe polega na przetworzeniu zapytania o numery telefoniczne pasaerw odwoywanego
rejsu po to, by mona ich byo powiadomi. Bardziej skomplikowane przetwarzanie moe polega na
automatycznej rezerwacji w poczeniach alternatywnych.
Elementy aktywne nie s nowym pomysem. Wystpoway ju w jzyku PL/I pod nazw ON-conditions".
Pojawiay si rwnie przez wiele lat w systemach sztucznej inteligencji, a take maj wiele wsplnego z
demonami" wystpujcymi w systemach operacyjnych. Jednak efektywna implementacja elementw
aktywnych staje si powanym problemem technicznym w przypadkach, gdy trzeba operowa na duych
zbiorach danych lub gdy samych elementw aktywnych zaczyna by duo. Z tego powodu elementy aktywne
nie pojawiy si w systemie DBMS a do pocztku lat dziewidziesitych. Omwimy je w rozdziale 6.

1.3.3. Dane multimedialne

Inny wany trend w dziedzinie systemw baz danych dotyczy danych multimedialnych. Sowem
multimedia" okrelamy dane reprezentujce pewne sygnay. Zazwyczaj dane multimedialne obejmuj film,
dwik, sygnay radarowe, obrazy satelitarne oraz rozmaicie kodowane obrazy i dokumenty. Wspln cech
tych wszystkich form jest ich rozmiar, nie tylko znacznie wikszy ni danych tradycyjnych - typu cakowitego,
napisw znakowych 0 okrelonej dugoci itp., ale take bardzo rozmaity.
Dua objto danych multimedialnych wymusia rozwj systemw DBMS w kilku rnych kierunkach.
Na przykad zupenie inne operacje przetwarza si na danych multimedialnych ni na danych tradycyjnych.
Zatem operacja wyszukania kont bankowych z ujemnym bilansem polega na porwnywaniu wartoci bilansu z

liczb rzeczywist 0,0. Nie jest natomiast wykonalne przeszukanie bazy danych zawierajcej zdjcia w celu
wyszukania twarzy, ktra wyglda jak" pewien okrelony obraz. Dlatego w systemie DBMS musia powsta
mechanizm umoliwiajcy uytkownikom doczanie wasnych funkcji, ktre mog operowa na danych
multimedialnych. Do takich rozszerze czsto stosuje si podejcie zorientowane obiektowo, nawet w
systemach relacyjnych.
Rozmiary obiektw multimedialnych, konieczno zorganizowania pamici dla obiektw i krotek
zajmujcych gigabajty pamici, lub nawet wiksze jej obszary, wymuszaj rwnie zmiany w moduach
zarzdzania pamici. Jednym z wielu kkopotliwych zada jest utworzenie odpowiedzi na zapytanie. W
zwykkych relacyjnych systemach odpowied jest zbiorem krotek. Klient otrzymuje tak odpowied w caoci
od serwera.
Wyobramy sobie jednak, e odpowied jest wideoklipem o objtoci gigabajta. Serwer nie jest
w stanie przekaza takich danych klientowi w caoci.
4O 1. DZIEDZINA SYSTEMW BAZ DANYCH

Trwaoby to zbyt dugo i uniemoliwio serwerowi obsug innych zada. Poza tym klient moe potrzebowa
tylko fragmentu filmu, ale nie moe dokadnie okreli czego chce, zanim nie zobaczy pocztku. Trzeci powd
koniecznoci nowego podejcia do obsugi zada w przypadku danych multimedialnych wynika std, e nawet
jeli klient potrzebuje caego wideoklipu po to na przykad, by odtworzy go na ekranie, wystarczy dostarcza
go w kawakach o ustalonej dugoci rytmicznie w cigu okoo godziny (tyle mniej wicej czasu trwa
wywietlenie filmu skompresowanego w jednym gigabajcie). Dlatego system zarzdzania pamici w
przypadku multimedialnych baz danych musi by przygotowany do przesyania odpowiedzi w trybie interakcyjnym, przesyania waciwych fragmentw odpowiedzi na dania klienta albo w ustalonych odstpach czasu.

1.3.4. Integracja danych

Z czasem, gdy informacja staje si coraz waniejsza w pracy i zabawie, odkrywamy coraz nowe sposoby
korzystania z istniejcych rde danych. Rozwamy na przykad firm, ktra chce wprowadzi katalog,
dostpny przez WWW, po to, by klienci mogli bezporednio przeglda produkty i wysya zamwienia. Wielka
firma ma wiele oddziaw. Kady oddzia moe mie wasn baz danych, zupenie niezalenie od innych
oddziaw. Oddziay mog korzysta z rnych systemw DBMS, rnych struktur danych, a nawet rnych
nazw okrelajcych te same rzeczy albo tych samych terminw do okrelenia rnych rzeczy.
PRZYKAD 1.4
Rozwamy firm z wieloma oddziaami, produkujc dyski do komputerw. Katalog jednego z oddziaw takiej
firmy moe opisywa szybko dostpu liczb obrotw na sekund, a inny liczb obrotw na minut. Jeszcze
inny oddzia mg w ogle zaniedba podania tej wielkoci. Oddzia produkcji dyskietek moe posugiwa si w
odniesieniu do swoich produktw terminem dysk i oddzia produkujcy dyski twarde te okrela swoje towary
mianem dyskw. Liczba cieek na dysku twardym moe. zosta opatrzona sowem cieki" w jednym
oddziale, a sowem cylindry" w innym.
0
Centralna koordynacja nie zawsze skutkuje. Oddziay mogy zainwestowa duo pienidzy w swoje bazy
danych znacznie wczeniej, ni w ogle dostrzeono problem integracji danych midzy oddziaami. Poza tym
jaki oddzia, ktry mg wanie ostatnio zosta wczony do firmy, dotychczas wystpowa jako samodzielne
przedsibiorstwo. Z tych i wielu innych powodw tzw. spadkowych baz danych nie mona w atwy sposb
zastpi. Dlatego firma musi, ponad spadkowymi bazami danych, tworzy nowe struktury,
1.4. UKAD KSIKI 4I

umoliwiajce jednolity sposb przedstawienia klientom tych wszystkich danych, ktre dotycz ogu
dostarczanych towarw i usug.
Jeden z rozpowszechnionych sposobw polega na tworzeniu hurtowni danych, baz centralnych, do ktrych
kopiuje si, po uprzednim przetumaczeniu, dane z baz spadkowych". Hurtownie danych s aktualizowane
zgodnie ze zmianami, wprowadzanymi do baz spadkowych, ale nie dzieje si to natychmiast. Najczciej
hurtownie rekonstruuje si w nocy, gdy bazy spadkowe s mniej obcione przetwarzaniem.
Dziki takiemu rozwizaniu spadkowe bazy danych mog nadal dziaa zgodnie ze swoim
przeznaczeniem. Natomiast nowe funkcje, takie jak na przykad utrzymywanie katalogw w sieci, spenia
hurtownia danych. Czsto obserwujemy rwnie korzystanie z hurtowni danych do analiz i planowania. Na
przykad analitycy przedsibiorstwa mog tworzy zapytania do hurtowni danych, ktrych wyniki uatwi
okrelenie trendu sprzeday, a to z kolei umoliwi stworzenie lepszego planu produkcji i inwestycji. Hurtownie
danych su take przy wybieraniu danych (data mining), poszukiwaniu pord danych ciekawych i
niezwykych wzorcw i syszy si stwierdzenia, e zastosowanie odkrytych w ten sposb wzorcw dao efekt w
postaci zwikszenia sprzeday.

1.4. Ukad ksiki

Zakres zagadnie zwizanych z bazami danych mona podzieli na trzy obszerne grupy:
1. Projektowanie baz danych. Jak zbudowa uyteczn baz danych? Jakie rodzaje danych umieszcza si w
bazach danych? Jaka jest struktura danych? Jakie zaoenia naley przyjmowa o typach i wartociach
poszczeglnych elementw w bazie danych? W jaki sposb te elementy s ze sob powizane?
2. Programowanie baz danych. W jaki sposb wyrazi zapytania i inne operacje na bazie danych? W jaki
sposb skorzysta z innych waciwoci baz danych, na przykad z wyzwalaczy lub transakcji?
3. Implementacja baz danych. Jak zbudowa DBMS, uwzgldniajc takie zagadnienia jak przetwarzanie
zapyta, przetwarzanie transakcji oraz efektywny system zarzdzania pamici?
Implementacje baz danych stanowi gwny segment rynku oprogramowania, dlatego liczba osb
zatrudnionych przy projektowaniu i korzystaniu z baz danych znacznie przewysza liczb tych, ktrzy buduj
systemy baz danych. Niniejsza ksika jest pomylana jako podrcznik do pierwszego wykadu z baz danych,
wic waciwym wydaje si skupienie uwagi na
42 I. DZIEDZINA SYSTEMW BAZ DANYCH

pierwszych dwch grupach zagadnie: projektowaniu i programowaniu. W tym rozdziale prbowalimy

przelotnie spojrze na trzeci grup - implementacj - ale ju nie powrcimy do tych zagadnie. W pozostaych
rozdziaach pogrupowalimy tematy dotyczce projektowania i programowania.

1.4.1. Proj ektowanie

Rozdziay 2 i 3 dotycz projektowania. Rozdzia 2 zaczynamy od przedstawienia formalizmu wysokiego
poziomu, przeznaczonego do opisu projektw baz danych. Pierwszy z nich, ODL (jzyk definiowania
obiektw), jest zorientowanym obiektowo jzykiem, przeznaczonym do definiowania klas. Drugi z nich,
nazywany modelem E/R lub zwizkw encji, jest notacj graficzn suc do obrazowania organizacji bazy
danych.
Ani jzyk ODL, mimo e jest bardzo zbliony do jzyka definicji danych obiektowych DBMS, ani model
E/R nie mog suy bezporednio do definiowania struktury bazy danych. Zaklada si raczej, e projekt
opisany w ktrej z tych notacji zostanie przetumaczony na jzyk definicji danych konkretnego systemu
DBMS. Poniewa wikszo systemw baz danych operuje modelem relacyjnym, wic skoncentrujemy si na
przeksztacaniu zapisw w ODL i E/R wanie do postaci relacyjnej.
Procesowi translacji i modelowi relacyjnemu powicamy rozdzial 3. Dalej, w podrozdziale 5.7 pokaemy,
jak w sposb formalny opisywa relacyjne schematy baz danych w jzyku SQL.
W rozdziale 3 wprowadzimy Czytelnikw rwnie w tajniki opisu zwizkw, ktre du do formalnego
zapisu zaloe dotyczcych zwizkw midzy krotkami relacji. Zwizki umoliwiaj oplacaln dekompozycj
relacji, ktr przeprowadza si w procesie nazywanym normalizacj" relacji. Zwizki i normalizacja
wyczerpuj tre zawart w podrozdziale 3.5 i nastpnych; zagadnienia te stanowi wany element
projektowania baz danych. Opisywane tematy s wane zarwno dla tych, ktrzy bezporednio bd
projektowa relacyjne bazy danych, jak i dla tych, ktrzy bd musieli przeksztaci projekt zapisany w ODL
lub E/R do postaci relacyjnej i bd mieli problemy z projektem.

1.4.2. Programowanie
Rozdziay od 4 do 8 obejmuj zagadnienia zwizane z programowaniem baz danych. Zaczniemy w
rozdziale 4 od abstrakcyjnego potraktowania zapyta w modelu relacyjnym, polegajcego na wprowadzeniu
okrelonej na relacjach rodziny operatorw, ktra tworzy algebr relacji". Omwimy take tzw. Datalog" alternatywny sposb opisywania zapyta, w ktrym stosuje si wyraenia logiczne.
1.5. PODSUMOWANIE 43

Rozdziaky od 5 do 7 s dedykowane programowaniu w jzyku SQL. Jak ju wspominalimy, SQL jest

obecnie dominujcym jzykiem zapyta. W rozdziale 5 omwimy podstawy dotyczce zapyta w SQL oraz
opisu schematu baz danych w tym jzyku. Prawie wszdzie w tych rozdziaach, oraz w nastpnych dwch,
posugujemy si standardem SQL, nazywanym SQL2. Jednak niektre elementy charakterystyczne dla
programowania w SQL znajduj si w komercyjnych wersjach tego narzdzia, ale nie ma ich w standardzie. W
takich przypadkach korzystamy z pniejszego standardu, jeszcze nie cakiem formalnego, nazywanego SQL3.
Rozdzia 6 obejmuje zagadnienia zwizane z wyzwalaczami i wizami danych w jzyku SQL. Poniewa
moliwoci SQL2 w tym zakresie s do ograniczone, wic powicamy troch czasu rozwizaniom
proponowanym zarwno w SQL3, jak i w SQL2.
Rozdzia 7 zawiera opis pewnych zaawansowanych aspektw programowania w jzyku SQL. Po pierwsze,
podczas gdy najprostszy sposb programowania w SQL polega na korzystaniu z niezalenego interfejsu
generujcego zapytania, w praktyce wikszo kodu SQL jest osadzona w wikszych programach, zapisanych w
jzykach konwencjonalnych, takich jak na przykad C. W rozdziale 7 nauczymy si, w jaki sposb docza kod
zapisany w SQL do programu zewntrznego oraz jak przekazywa dane midzy baz danych a zmiennymi

programu. Take w tym rozdziale znajdziemy sposoby opisywania w SQL transakcji, czenia klienta z
serwerem i autoryzowania dostpu do baz danych dla osb spoza grona wacicieli.
W rozdziale 8 zwrcimy uwag na powstajce wanie zorientowane obiektowo standardy programowania
baz danych. Wyrnimy tutaj dwa kierunki. Pierwszy z nich, OQL (object query language) mona traktowa
jako prb dopasowania jzyka C++ do wymaga wysoko poziomowego programowania baz danych. W
drugim, ktry sprowadza si do obiektowych elementw SQL3, mona dopatrzy si prby przeksztacenia
SQL i baz relacyjnych do postaci kompatybilnej z programowaniem zorientowanym obiektowo. Do pewnego
stopnia oba te podejcia s podobne. Jednak jest wiele aspektw, ktre rni je zasadniczo.

1.5. Podsumowanie
Systemy zarzc~dzania bazami danych: (DBMS - database management systems): su projektantom do
strukturalizacji danych, uytkownikom do wyszukiwania i aktualizowania danych, a take uatwiaj
organizowanie wielkich iloci danych oraz wielu jednoczesnych operacji na nich.
Jzyki baz danych (database languages): S to bd jzyki, bd ich skadowe, przeznaczone do definiowania
struktur danych (jzyki definiowania danych - data-definition languages) i do wyszukiwania
44
1. DZIEDZINA SYSTEMW BAZ DANYCH

i aktualizowania danych (jzyki operowania danymi - data-manipulation languages).

Relacyjne systemy baz danych (relational database systems): Obecnie wikszo systemw baz
danych realizuje model relacyjny, w ktrym podstawow struktur danych jest tabela. W tych
systemach najczciej korzysta si z jzyka SQL.
Zorientowane obiektowo systemy baz danych (object-oriented database systems): W niektrych
wsplczesnych systemach baz danych mona zaobserwowa elementy zorientowanych obiektowo modeli
danych, takie jak na przykad klasy, obszerne systemy typw, identyfikatory obiektw oraz dziedziczenie
wlasnoci w podklasach. Prawdopodobnie w przyszoci wikszo systemw baz danych, nawet tych
relacyjnych, bdzie uwzgldnia te wszystkie koncepcje.
Pami drugiego i trzeciego poziomu (secondary and te~tiary storage): Wielkie bazy danych przechowuje si
zazwyczaj na urzdzeniach pamitajcych drugiego poziomu, przewanie na dyskach. Najwiksze bazy
danych potrzebuj zastosowania urzdze trzeciego poziomu, o pojemnoci o kilka rzdw wikszej ni
dyski, ale take o kilka rzdw wolniejszych.
Skadowe systemu DBMS (components of a DBM,f): Wrd gwnych skadowych systemu zarzdzania
bazami danych naley wymieni: modu obsugi zapyta, modu zarzdzania transakcjami oraz modu
zarzdzania pamici.
Modu zarzctdzania pamici (storage manager): Modu zarzdzania pamici obsuguje zarwno pliki
danych w pamici drugiego poziomu, jak i bufory w pamici operacyjnej, w ktrych umieszcza si
fragmenty plikw. System zarzdzania baz danych utrzymuje indeksy, tzn. struktury danych zapewniajce
efektywny dostp do danych.
Modu obsugi zapyta (query manager): Wane zadanie moduu obsugi zapyta polega na
optymalizowaniu" zapyta, to znaczy znalezieniu waciwego algorytmu generujcego odpowied na
konkretne zapytanie.
Modu zarzctdzania transakcjami (transaction manager): transakcja stanowi podstawow jednostk
przetwarzania w bazach danych. Modul zarzdzania transakcjami umoliwia jednoczesne przetwarzanie
wielu transakcji, zapewniajc take zachowanie waciwoci ACID: niepodzielnoci, spjnoci, izolacji i
trwaloci.
Systemy klient-serwer (client-server systems): Systemy zarzdzania bazami danych zazwyczaj dzialaj w
architekturze klient-serwer, gkwna cze bazy danych jest przetwarzana jako serwer, a po stronie klienta
dziaa interfejs uytkownika.
Aktywne elementy baz danych (active database elements): wsplczesne systemy baz danych zapewniaj
dostp do pewnych postaci elementw aktywnych, zazwyczaj wyzwalaczy lub wizw integralnoci.
1.6. LITERATURA DO ROZDZIAU 1

45

1 Przyszo systemw: Glwne trendy systemw baz danych obejmuj takie zjawiska jak bardzo due obiekty multimedialne", na
przykkad wideo lub obrazy oraz integrowanie danych z wielu oddzielnych rde w jednbaz danych.

1.6. Literatura do rozdziaw 1

Istnieje wiele ksiek powiconych wanym aspektom implementacji systemw baz danych. W pozycjach [3] i [5] opisano
implementacj zarzdzania transakcjami. Take tam, a rwnie i w pozycji [7] przedstawiono opis implementacji rozproszonych baz
danych. Natomiast implementacj systemu plikw omwiono w [11].

Pozycje [2], [4] oraz [6] dotycz zorientowanych obiektowo systemw baz danych. Teori baz danych przedstawiono w [1], [9] oraz
[10]. W [8] mona znale wiele opracowa naukowych, ktre miay wpyw na ksztatowanie si dziedziny baz danych.
1. Abiteboul S., Hull R., Vianu V.: Foundations of Databases. Addison-Wesley, Reading MA. 1995.
2. Bancilhon F., Delobel C., Kanellakis P.: Building an Object-Oriented Database System. Morgan-Kaufman, San Francisco, 1992.
3. Bernstein P.A., Hadzilacos V., Goodman N.: Concurrency Control and Recovery in Database Systen2s. Addison-Wesley, Reading, MA,
1987.
4. Cattell R.G.G.: Object Data Management. Addison-Wesley, Reading, MA, 1994.
5. Gray J.N., Reuter A.: Transaction Processing: Concepts and Technigues. Morgan-Kaufman, San Francisco, 1993.
6. Kim W. (ed.): Modern Database Systems: The Object Model, Interoperability and Beyond. ACM Press, New York, 1994.
7. Oszu M. T., Valduriez P.: Principles of Distributed Database Systems. Prentice Hall, Englewood Cliffs, NJ, 1991.
8. Stonebraker M. (ed.): Readings in Database Systems. Morgan-Kaufman, San Francisco, 1994.
9. Ullman J.D.: Principles in Database and Knowledge-Base Systems, t. I. Computer science Press, New York, 1988.
10. Ullman J.D.: Principles in Database and Knowledge-Base Systems, t. II. Computer science Press, New York, 1989.
11. Wiederhold G.: Database Design. McGraw-Hill, New York, 1983.