#27
CZĘŚĆ I
Projektowanie relacyjnej bazy danych

#29
1. Czym jest relacyjna baza danych?

Ryba pływa trzy razy - w wodzie, w maśle i w winie - Przysłowie polskie

Typy baz danych

Użytkowane dziś bazy danych można podzielić, ze względu na sposób zarządzania nimi, na dwa rodzaje: operacyjne bazy danych i analityczne bazy danych.
Bazy operacyjne znajdują zastosowanie w codziennym funkcjonowaniu różnorodnych organizacji, instytucji i firm. Są wykorzystywane tam, gdzie zachodzi potrzeba gromadzenia, przechowywania i modyfikowania danych. Ten typ bazy przechowuje dane dynamiczne, czyli takie, które ulegają ciągłym zmianom i odzwierciedlają aktualny stan jakiegoś obiektu. Przykładami baz operacyjnych są bazy inwentaryzacyjne, bazy obsługi zamówień, bazy informacji o pacjentach czy bazy prenumeratorów czasopism.
Analityczne bazy danych są wykorzystywane do przechowywania danych historycznych i informacji związanych z pewnymi wydarzeniami. Kiedy dana firma lub organizacja chce przeanalizować tendencje rynkowe, uzyskać dostęp do długoterminowych danych statystycznych lub poczynić prognozy na przyszłość, sięga do analitycznej bazy danych. Dane w bazie analitycznej są statyczne, co oznacza, że bardzo rzadko (jeśli w ogóle) ulegają zmianom i zawsze odzwierciedlają stan obiektów z pewnego ustalonego momentu (nie stan obecny). Przykłady analitycznych baz danych to bazy testów chemicznych, próbek geologicznych czy danych pomiarowych.

Wczesne modele baz danych

Zanim pojawił się relacyjny model logiczny, do przechowywania i modyfikowania danych wykorzystywano dwa wcześniejsze modele: model hierarchiczny i model sieciowy.
#30
================================
Uwaga: Pomimo iż szczegółowy opis tych dwóch modeli wykracza poza zakres materiału tej książki, chciałbym pokrótce omówić każdy z nich. W moim omówieniu zawarłem informacje o zakładanej przez dany model strukturze danych i metodach dostępu do nich, sposobie reprezentowania relacji między tabelami oraz o wadach i zaletach tego modelu.
=================================
Hierarchiczny model logiczny

W hierarchicznym modelu bazy danych (czasem określanego skrótem HMBD) dane mają strukturę, którą można najprościej opisać jako odwrócone drzewo. Jedna z tabel pełni rolę "korzenia" drzewa, a pozostałe mają postać "gałęzi" biorących swój początek w korzeniu. Rysunek 1.1 ukazuje diagram struktury HMBD.

[pośrednicy]-->[muzycy]-->[terminarz]
druga -->od [pośrednicy]-->[klienci]-->[umowy]
druga -->od [klienci]-->[rozliczenia]
Rysunek 1.1. Diagram modelu hierarchicznego

Baza danych pośredników. W przykładzie z rysunku 1.1 każdy pośrednik pracuje dla kilku muzyków i ma pewną liczbę klientów, którzy zamawiają u niego obsługę muzyczną różnych imprez. Klient zawiera umowę z danym muzykiem przez pośrednika i u tego właśnie pośrednika uiszcza należność za usługę.
Relacje w HMBD są reprezentowane w kategoriach ojciec/syn. Oznacza to że tabela-ojciec może być powiązana z wieloma tabelami-synami, lecz pojedynczy syn może mieć tylko jednego ojca. Tabele te mogą być powiązane jawnie, przez wskaźniki, lub przez fizyczną organizację rekordów wewnątrz tabel. Aby uzyskać dostęp do danych w modelu hierarchicznym, użytkownik zaczyna od korzenia i przedziera się przez całe drzewo danych, aż do interesującego go miejsca. Oznacza to jednak, że użytkownik musi dobrze znać strukturę bazy danych.
Jedną z zalet tego rodzaju bazy jest to, że potrzebne dane można szybko przywołać, ponieważ poszczególne tabele są ze sobą bezpośrednio powiązane. Inną zaletą
#31
jest to, że mają one automatycznie wbudowaną integralność odwołań. Oznacza to, że rekord w tabeli-synu musi być powiązany z istniejącym rekordem w tabeli-ojcu. Jeśli jeden z rekordów w tabeli-ojcu zostanie skasowany, wówczas skasowaniu ulegną również wszystkie powiązane z nim rekordy w tabelach-synach.
Jeżeli jednak musimy zapisać w tabeli-synu rekord, który nie byłby powiązany z żadnym z rekordów w tabeli-ojcu, wówczas powstaje problem. W przykładzie z rysunku 1.1 nie możemy dopisać do tabeli muzyków nowej osoby, dopóki nie przypiszemy jej pośrednika w tabeli pośredników. Często jednak występuje sytuacja, w której muzyk zapisuje się do agencji pośredniczącej zanim zostanie mu przydzielony konkretny pośrednik. Taki scenariusz jest trudny do spełnienia w modelu HMBD. Można jednak nagiąć zasady, nie łamiąc ich jednak, jeśli wpiszemy do tabeli pośredników "sztuczne" dane. Takie rozwiązanie nie jest jednak optymalne.
Nadmiarowe dane stanowią kolejny problem modelu HMBD, ponieważ model ten jest niezdolny do obsługi złożonych relacji. W przykładzie z rysunku 1.1 między klientami i muzykami istnieje relacja wiele-do-wielu: jeden muzyk gra dla wielu klientów, a jeden klient może zatrudniać wielu muzyków. Ponieważ taki rodzaj relacji nie może zostać bezpośrednio wpisany w model HMBD, zachodzi konieczność wprowadzenia nadmiarowych danych do tabel terminarzy i umów. Tabela terminarzy będzie zawierać dane o klientach (takich np. jak: imię, nazwisko, adres oraz numer telefonu), informujące o miejscu występu danego muzyka, lecz dane te pojawiają się również (a może przede wszystkim) w tabeli klientów. Ponadto tabela terminarzy będzie zawierać dane o muzykach (na przykład: imię, nazwisko, telefon i gatunek muzyki), mówiące nam, którzy muzycy grają dla danego klienta. Te same dane znajdują się (poniekąd słusznie) w tabeli muzyków. Ta nadmiarowość tworzy możliwość sytuacji, w których pewne dane zostają wprowadzone w sposób niekonsekwentny, co z kolei zaburza integralność bazy. Problem można obejść przez utworzenie osobnej hierarchicznej bazy danych dla muzyków i drugiej - dla pośredników. Nowa baza muzyków będzie składać się jedynie z tabeli muzyków, natomiast baza pośredników będzie zawierać tabele pośredników, klientów, rozliczeń i umów. Tabela terminarzy nie jest już potrzebna, ponieważ można zdefiniować logiczną relację ojciec-syn między tabelą umów w bazie pośredników oraz tabelą muzyków w bazie muzyków. Po wprowadzeniu takiej relacji z bazy będzie można wyczytać informacje takie jak: lista muzyków, z którymi zawarł umowy dany klient, czy terminarz występów danego muzyka.
Metoda ta spełnia swoje zadanie, jeśli ją zastosujemy. Twórca bazy danych musi jednak być pewien konieczności uwzględnienia takiej relacji. W tym wypadku była ona dość oczywista, lecz wiele relacji jest znacznie bardziej skomplikowanych i potrzeba ich wprowadzenia może zostać zauważona dopiero w bardzo późnych stadiach procesu projektowania lub też - o zgrozo - po oddaniu bazy do użytku.
#32
Baza danych muzyków - [Muzycy]--->logiczna relacja ojciec-syn--->do [umowy] z B.d.p.

Baza danych pośredników - [Pośrednicy]--->[klienci]--->(dwie strzałki- pierwsza do)--->[umowy]
--->(druga do)--->[rozliczenia]

Rysunek 1.2. Wykorzystanie dwóch hierarchicznych baz danych do rozwiązania problemu relacji wiele-do-wielu

Hierarchiczny model bazy danych był z powodzeniem stosowany w systemach zapisu taśmowego, wykorzystywanych w komputerach typu mainframe do późnych lat siedemdziesiątych, i zdobył dużą popularność w firmach polegających na tych systemach. A jednak, pomimo tego, iż HMBD zapewniał szybki, bezpośredni dostęp do danych i znajdował zastosowanie w rozwiązywaniu wielu problemów, powoli narastała potrzeba wprowadzenia nowego modelu, który nie wymagałby wprowadzania takiej ilości nadmiarowych danych i złożonych relacji.

Sieciowy model logiczny

Sieciowy model bazy danych (odtąd będziemy go nazywać SMBD) został stworzony głównie w celu rozwiązania problemów związanych z modelem hierarchicznym. Tak jak w HMBD, strukturę SMBD można sobie wyobrazić jako odwrócone drzewo. Różnica polega jednak na tym, że w przypadku SMBD kilka drzew może dzielić ze sobą gałęzie, a każde drzewo stanowi część ogólnej struktury bazy danych. Na rysunku 1.3 widać diagram modelu sieciowego.
Baza danych pośredników. W przykładzie z rysunku 1.3 każdy pośrednik pracuje dla kilku muzyków i ma pewną liczbę klientów, którzy zamawiają u niego obsługę muzyczną różnych imprez i uiszczają opłaty. Każdy muzyk może zawrzeć wiele oddzielnych umów i specjalizować się w wielu różnych gatunkach muzyki.
#33
Baza danych pośredników
(między strzałkami-opis z książki; w nawiasach- opis mój)
[pośrednicy]-->reprezentuje--->[klienci]-->uiszcza-->[rozliczenia]
---> druga strzałka od --->[klienci] do-->zawiera--> [umowy]
druga -->od [pośrednicy]do-->kieruje-->[muzycy]-->wypełnia-->[umowy](wspólna część)
druga -->od [muzycy]do-->gra-->[style muzyczne]

Rysunek 1.3. Diagram modelu sieciowego

Relacje w SMBD są definiowane przez kolekcje (ang. set structures). Kolekcja jest niejawną konstrukcją łączącą dwie tabele przez przypisanie jednej z nich roli właściciela, a drugiej - roli członka. (Stanowiło to znaczny postęp w porównaniu z relacjami ojciec--syn). Kolekcje umożliwiają wprowadzanie relacji jeden-do-wielu, co oznacza, że w obrębie danej struktury każdy rekord z tabeli-właściciela może być powiązany z dowolną ilością rekordów tabeli-członka, lecz pojedynczemu rekordowi w tabeli-członku może odpowiadać tylko jeden rekord w tabeli-właścicielu. Ponadto każdy rekord w tabeli-członku musi być powiązany z istniejącym rekordem w tabeli-właścicielu. Przykładowo, każdy klient musi mieć przyporządkowanego pośrednika, choć mogą istnieć pośrednicy nie obsługujący żadnych klientów. Rysunek l .4 przedstawia typową strukturę kolekcji.
Między każdymi dwoma tabelami można zdefiniować dowolną liczbę powiązań (kolekcji), a każda tabela może uczestniczyć w wielu różnych kolekcjach. Przykładowo, na rysunku 1.3 tabela klientów jest powiązana z tabelą opłat przez kolekcję uiszcza oraz z tabelą umów przez kolekcję zawiera. Tabela umów, oprócz tabeli klientów, jest powiązana również z tabelą muzyków przez kolekcję wypełnia.

1 [pośrednicy] ---- tabela-wtaściciel
{strzałka w dół; obok niej napis:reprezentuje) --- kolekcja
M [klienci] --- tabela-członek

Rysunek 1.4. Typowa struktura kolekcji

W SMBD dostęp do odpowiednich danych można uzyskać, poruszając się po kolekcjach. W przeciwieństwie do modelu hierarchicznego, gdzie poszukiwanie danych należało zacząć od podstaw, w SMBD użytkownik może rozpocząć od dowolnej tabeli, a następnie poruszać się w górę lub w dół po tabelach z nią powiązanych. Rozważmy
#34
przykład z rysunku 1.3 i załóżmy, że użytkownik chce znaleźć pośrednika, który zawarł pewną określoną umowę. Zaczniemy od interesującego nas rekordu w tabeli umów, następnie, korzystając z kolekcji zawiera, sprawdzimy, który klient jest "właścicielem" tego rekordu, i na koniec przejdziemy do tabeli pośredników przez kolekcje reprezentuje. Z tak zorganizowanej bazy danych można wyczytać bardzo wiele informacji, pod warunkiem że użytkownik umie prawidłowo poruszać się po kolekcjach.
Zaletą modelu SMBD jest szybkość, z jaką można odczytywać z niego dane. Ponadto użytkownik ma możliwość tworzenia znacznie bardziej złożonych zapytań niż miało to miejsce w modelu hierarchicznym. Za wadę można uznać jednak to, że, podobnie jak w HMBD, użytkownik musi mieć dobre wyobrażenie o strukturze używanej bazy danych. W przykładzie z rysunku 1.3 na użytkownika spada ciężar pamiętania, przez które kolekcje należy przejść, aby dowiedzieć się, czy - przykładowo - należność za daną umowę została już uiszczona. Kolejną wadą jest niemożność zmiany struktury bazy danych bez ponownego tworzenia obsługujących ją programów. Jak już wiemy, relacje w SMBD są zdefiniowane za pomocą kolekcji. Danej kolekcji nie można zmienić bez modyfikowania aplikacji bazodanowej, ponieważ aplikacja ta polega na kolekcjach do wyszukiwania odpowiednich danych. Jeśli któraś kolekcja ulegnie zmianie, wszystkie odwołania do tej kolekcji zawarte w aplikacji obsługującej bazę danych muszą również zostać zmienione.
Pomimo iż sieciowy model logiczny był zdecydowanym krokiem naprzód w porównaniu z modelem hierarchicznym, kilku ludzi w środowisku bazodanowym nadal uważało, że musi istnieć lepszy sposób na przechowywanie i obsługę dużych ilości danych. W miarę jak rozwijał się przemysł informatyczny, użytkownicy chcieli uzyskiwać odpowiedzi na coraz bardziej złożone zapytania. To z kolei kładło coraz większy ciężar na istniejące struktury baz danych. I tak dochodzimy do modelu relacyjnego.

Relacyjny model logiczny: krótka historia

Pod koniec lat sześćdziesiątych dr E. F. Codd, badacz zatrudniony przez firmę IBM, pracował nad nowymi sposobami obsługi dużych ilości informacji. Zrażony do istniejących modeli baz danych zauważył, że zastosowanie struktur i procesów matematycznych w zarządzaniu danymi mogłoby rozwiązać wiele problemów trapiących ówczesne modele, jak nadmiarowość danych, ich słaba integralność czy nadmierna zależność od fizycznej implementacji. Ponieważ Codd był z wykształcenia matematykiem, wybór tej ścieżki stał się dlań oczywisty.
W lipcu 1970 r. Codd opublikował dzieło swojego życia, zatytułowane: Relacyjny model logiczny dla dużych banków danych. W książce tej po raz pierwszy zaprezentował założenia relacyjnego modelu baz danych (odtąd będziemy go nazywać RMBD), oparłszy go na dwóch gałęziach matematyki - teorii mnogości i rachunku predykatów pierwszego rzędu. Popularnym błędem jest twierdzenie, że nazwa RMBD
#35
wywodzi się z faktu istnienia "relacji" między tabelami w bazie danych. W rzeczywistości RMBD zawdzięcza swoją nazwę pojęciu relacji w teorii mnogości.
W RMBD dane przechowuje się w domenach, czyli tabelach. Każda tabela składa się z krotek, czyli rekordów, oraz atrybutów, czyli pól. (W dalszej części książki ograniczymy się do pojęć "tabela", "rekord" i "pole"). Fizyczna kolejność pól i rekordów w tabeli jest całkowicie bez znaczenia. Każdy rekord jest wyróżniany przez jedno pole zawierające unikatową wartość. Te dwie cechy RMBD umożliwiają egzystencję danych niezależnie od sposobu, w jaki przechowuje je komputer. Innymi słowy, użytkownik nie musi znać fizycznego położenia rekordu, który chce odczytać. To odróżnia RMBD od modelu hierarchicznego i sieciowego, gdzie bardzo duży nacisk kładziono na struktury, których rozmieszczenie użytkownik musiał opanować, by móc odczytać interesujące go dane. Rysunek 1.5 przedstawia diagram modelu RMBD.
Baza danych pośredników. W przykładzie z rysunku 1.5 każdy pośrednik pracuje dla kilku muzyków i ma pewną liczbę klientów. Ponadto klienci i muzycy są ze sobą powiązani przez tabelę umów, ponieważ klient może zatrudnić dowolną liczbę muzyków, a każdy muzyk może grać dla wielu różnych klientów. Oprócz tego każdy muzyk reprezentuje jeden lub więcej gatunków muzyki, co odzwierciedla tabela "Gatunki/muzycy".

Baza danych pośredników

[pośrednicy]--->[klienci]-->[rozliczenia]
druga -->od[pośrednicy]do-->[muzycy]-->[rozliczenia](wspólna część)
druga -->od [muzycy]do--->[gatunki/muzycy]<---(z drugiej strony dochodzi od osobnego bloku)<---[gatunki muzyczne]

Rysunek 1.5. Diagram relacyjnego modelu logicznego

Relacje w RMBD można podzielić na trzy grupy: jeden-do-jednego, jeden-do--wielu oraz wiele-do-wielu. (Typami relacji szczegółowo zajmiemy się w rozdziale 10). Każde dwie tabele, między którymi istnieje relacja, są ze sobą jawnie powiązane, ponieważ dzielone przez nie pola zawierają odpowiadające sobie wartości. Przykładowo, na rysunku 1.6 tabela "Pośrednicy" i tabela "Klienci" są powiązane przez pole "ID pośrednika". Każdemu klientowi odpowiada jeden z pośredników, którego identyfikator znajduje się w tym właśnie polu. Podobnie tabela "Muzycy" jest powiązana
#36
z tabelą "Umowy" przez pole "ID muzyka". Dany rekord w tabeli "Umowy" można połączyć z rekordem w tabeli "Muzycy", analizując zawartość pola "ID muzyka".
Jeżeli użytkownik wie, jakie relacje występują miedzy poszczególnymi tabelami w bazie danych, może czerpać zeń informacje na niemal nieograniczoną ilość sposobów, kojarząc ze sobą dane z bezpośrednio lub pośrednio powiązanych tabel. Przyjrzyjmy się jeszcze raz przykładowi z rysunku 1.5. Pomimo iż tabela klientów jest tylko pośrednio powiązana z tabelą gatunków muzycznych (właściwie to bardzo pośrednio), użytkownik jest w stanie sporządzić listę upodobań muzycznych danego klienta. Jest to łatwe, ponieważ tabela gatunków muzycznych jest bezpośrednio powiązana z tabelą "Gatunki/ muzycy", z którą powiązana jest również tabela muzyków. Ci z kolei mają bezpośrednią łączność z tabelą umów, a ta jest w relacji z tabelą klientów.
W RMBD dostęp do danych uzyskuje się, podając nazwę interesującego nas pola oraz tabel(i), do których ono należy. Jednym ze sposobów jest wykorzystanie języka SQL (ang. Structured Query Language). SQL jest standardowym językiem używanym do wprowadzania, modyfikowania oraz odczytywania informacji z bazy danych. Przykładowo, zapytanie o spis wszystkich klientów z miasta El Paso, zapisane w języku SQL, wyglądałoby tak jak na rysunku 1.7.
Proste zapytanie SQL składa się z trzech podstawowych składników: wyrażenia SELECT ... FROM, klauzuli WHERE oraz klauzuli ORDER BY. Nazwy pól, jakie zapytanie to ma zwracać, są wypisane po słowie kluczowym SELECT, a tabele, do których pola te należą - po słowie FROM. Następnie do jednego lub większej liczby pól możemy zastosować kryteria wyboru wypisane w klauzuli WHERE, a wyniki posortować według zawartości dowolnego pola (lub pól), wykorzystując klauzulę ORDER BY.
Większość popularnych pakietów oprogramowania baz danych udostępnia graficzne narzędzia do konstrukcji zapytań, więc dokładna znajomość SQL nie jest zbyt ważna. Opanowanie podstaw tego języka pomoże Ci jednak zrozumieć, co dzieje się za kulisami wykorzystywanych przez Ciebie graficznych kreatorów zapytań.
Większość pakietów oprogramowania, przeznaczonych do konstrukcji relacyjnych baz danych, posiada wbudowany interpreter SQL, czy to bezpośrednio, czy też "wewnątrz" samego programu, gdzie jest on wykorzystywany przy generowaniu ostatecznej postaci zapytania z danych dostarczonych przez użytkownika. Przykładowo, R:BASE firmy Microrim daje użytkownikowi możliwość bezpośredniego wpisywania zapytań SQL w linii poleceń, podczas gdy program Microsoft Access umożliwia budowanie zapytań przy użyciu graficznego edytora generującego odpowiednie wyrażenie, które z kolei zostaje użyte do odczytania danych z bazy. W momencie zapisania zapytania na dysku, Access zapisuje również wyrażenie SQL.
====================================
Uwaga: Pomimo iż szczegółowe omówienie języka SQL wykracza poza zakres tej książki, powinieneś zdawać sobie sprawę z faktu, iż język ten jest bezpośrednio związany z relacyjnym modelem bazy danych.
==================================
#37
Pośrednicy

D pośrednika; Imię pośrednika; Nazw. pośrednika; Data zatrudnienia; Telefon domowy pośrednika 100; Mike; Hernandez; 05/16/95; 553-3992
101; Greg; Piercy; 10/15/95; 790-3992
102; Katherine; Ehrlich; 03/01/96; 551-4993

Klienci

ID klienta; ID pośrednika; Imię klienta; Nazwisko klienta; Telefon domowy klienta
9001; 100; Stewart; Jameson; 553-3992
9002; 101; Shannon; McLain; 790-3992
9003; 102; Estela; Pundt; 551-4993
(strzałka od kolumny D pośrednika; do ID pośrednika;)
Muzycy

ID muzyka; ID pośrednika; Imię pośrednika; Nazwisko pośrednika
3000; 100; John; Slade
3001; 101; Mark; Jones
3002; 102; Teresa; Weiss

Umowy

ID klienta; ID pośrednika; Data usługi; Czas rozpoczęcia; Czas zakończenia
9003; 3001; 04/01/98; 13:00; 15:30
9009; 3000; 04/13/98; 21:00; 1:30;
9001; 3002; 05/02/98; 15:00; 18:00;
(strzałka od ID muzyka;z Muzycy do ID pośrednika; z Umowy)

Rysunek 1.6. Przykłady powiązanych tabel w RMBD

SELECT Nazwisko klienta, Imię klienta, Telefon klienta
FROM Klienci
WHERE Miasto = "El Paso"
ORDER BY Nazwisko klienta, Imię klienta

Rysunek 1.7. Przykładowe zapytanie SQL
#38
Relacyjny model logiczny posiada wiele zalet. Oto niektóre z nich:
� Wielopoziomowa integralność danych. Integralność na poziomie pól zapewnia dokładność wprowadzanych danych, integralność na poziomie tabel uniemożliwia powtarzanie się tego samego rekordu i pozostawianie nie wypełnionych pól wchodzących w skład klucza podstawowego, integralność na poziomie relacji gwarantuje ich odpowiednie zdefiniowanie, a reguły integralności kontrolują poprawność danych z punktu widzenia tematu bazy. (W miarę opisywania procesu projektowania będziemy po kolei wyjaśniać różne aspekty integralności danych).
� Logiczna i fizyczna niezależność od aplikacji bazodanowych. Zarówno zmiany wprowadzane przez użytkownika do projektu logicznego, jak i modyfikacje sposobów fizycznej implementacji bazy przez producentów oprogramowania mają znikomy wpływ na działanie aplikacji obsługującej tę bazę.
� Zagwarantowana dokładność i poprawność danych. Dane są poprawne i dokładne dzięki wprowadzeniu wielopoziomowej integralności.
� Łatwy dostęp do danych. Dane można w prosty sposób odczytywać z pojedynczej tabeli lub z całej grupy powiązanych tabel.
Te i szereg innych zalet czynią RMBD szczególnie użytecznym w świecie biznesu i we wszystkich sytuacjach wymagających gromadzenia i przechowywania danych. Obecnie cieszy się on zdecydowanie największą popularnością wśród wszystkich modeli baz danych.

Jeszcze do niedawna za główną wadę RMBD uważany był fakt, że oparte na nim aplikacje działały bardzo powoli. Nie była to jednak wina samego modelu, lecz technologii wykorzystywanej w czasach, kiedy model ten powstał. Dostępna wówczas moc obliczeniowa, pamięć operacyjna i pamięć masowa nie wystarczały do pełnego zaspokojenia potrzeb producentów oprogramowania obsługującego RMBD. Dlatego też wczesne relacyjne bazy danych nie były tak zaawansowane i elastyczne, jak oczekiwano, aczkolwiek kryły nie wykorzystany potencjał. Wraz z początkiem lat dziewięćdziesiątych postępy w mikroelektronice i w inżynierii oprogramowania zepchnęły problem mocy obliczeniowej na dalszy plan i umożliwiły producentom oprogramowania pełną implementację RMBD.
W miarę zapoznawania się z opisanym w niniejszej książce procesem projektowania dowiesz się więcej o relacyjnym modelu logicznym - poznasz na przykład: struktury tabel, sposoby zapewnienia integralności danych oraz metody definiowania relacji.

Systemy zarządzania relacyjnymi bazami danych

System zarządzania relacyjną bazą danych, w skrócie SZRBD, jest programem wykorzystywanym do tworzenia i modyfikowania relacyjnych baz danych. Służy również do generowania aplikacji, z której będzie korzystał użytkownik gotowej bazy.
#39
Oczywiście jakość danego SZRBD zależy od stopnia, w jakim implementuje on relacyjny model logiczny. Nawet "prawdziwe" SZRBD niekiedy diametralnie odbiegają od siebie w tej kwestii, a pełnej implementacji RMBD nadal nie udało się nikomu osiągnąć. Mimo to obecne SZRBD są potężniejsze i wszechstronniejsze niż kiedykolwiek.
Systemy zarządzania relacyjnymi bazami danych były wytwarzane przez sporą liczbę producentów oprogramowania od wczesnych lat siedemdziesiątych. Programy te działają na różnych platformach sprzętowych i pod różnymi systemami operacyjnymi. Istnieją implementacje SZRBD na praktycznie dowolny komputer.
Przez pewien czas po stworzeniu modelu relacyjnego SZRBD były pisane tylko na komputery mainframe. (Czy istnieje jakikolwiek rodzaj oprogramowania, który nie zaczai swojego istnienia od systemów mainframe!) Dwoma takimi programami, napisanymi we wczesnych latach siedemdziesiątych, były System R, opracowany przez IBM w laboratorium badawczym w San Jose, oraz INGRES (Interaktywny System Obsługi Grafiki; ang. Interactive Graphics Retrieval System), powstały na Uniwersytecie Kalifornijskim w Berkeley. Oba te systemy przysłużyły się znacząco do upowszechnienia modelu relacyjnego.
W miarę jak zalety RMBD stawały się coraz wyraźniejsze, wiele organizacji zaczęło powoli przechodzić z modeli hierarchicznych i sieciowych na model relacyjny, stwarzając tym samym popyt na lepsze i większe programy SZRBD. Lata osiemdziesiąte były okresem burzliwego rozwoju komercyjnych systemów zarządzania dla komputerów mainframe, jak np. Oracle korporacji Oracle, czy DB2 IBM-u.
We wczesnych latach osiemdziesiątych do powszechnego użytku zaczęły wchodzić komputery osobiste, a razem z nimi, przeznaczone dla nich, SZRBD. Niektóre z wcześniejszych programów, jak dBase firmy Ashton-Tate czy FoxPro z Fox Software, były jedynie prostymi systemami zarządzania danymi, zapisanymi w plikach. Historia prawdziwych SZRBD dla komputerów PC rozpoczęła się wraz z wejściem na rynek programów R:BASE firmy Microrim oraz Paradox firmy Ansa Software. Każdy z tych produktów przyczynił się do udostępnienia użytkownikom komputerów domowych możliwości uprzednio zarezerwowanych dla systemów mainframe.
W miarę jak coraz więcej użytkowników wchodziło w kontakt z bazami danych, pod koniec lat osiemdziesiątych i na początku dziewięćdziesiątych potrzeba szerszego udostępniania danych gromadzonych w owych bazach stała się pilna. Pomysł centralnie ulokowanej bazy dostępnej dla dowolnej liczby użytkowników wydawał się bardzo kuszący. Poza zwiększeniem szybkości systemu, przechowywanie danych w jednym miejscu znacznie ułatwiłoby ich obsługę i ochronę. Producenci oprogramowania baz danych odpowiedzieli na to zapotrzebowanie, opracowując systemy SZRBD typu klient-serwer.
W tym typie SZRBD dane znajdują się w centralnym komputerze, nazywanym serwerem bazy danych, a użytkownicy uzyskują do nich dostęp, wykorzystując aplikacje zainstalowane w ich własnych komputerach PC, nazywanych klientami bazy danych. Serwer "troszczy się" zarówno o integralność danych, jak i o ich bezpieczeństwo, urno-
#40
żliwiając stworzenie wielu różnych aplikacji-klientów, których zastosowanie nie wyklucza się nawzajem i nie zagraża danym przechowywanym na serwerze. Zarówno sama baza danych, jak i obsługujące ją aplikacje są nadzorowane przez oprogramowanie SZRBD typu klient-serwer.
Bazy danych typu klient-serwer są obecnie szeroko wykorzystywane przy obsłudze dużych ilości danych współdzielonych przez wielu użytkowników. Najnowsze systemy zarządzania takimi bazami to miedzy innymi: Microsoft SQL Server firmy Microsoft, Oracle 7 Cooperative Seryer korporacji Oracle czy Sybase System 11 SQL Server firmy Sybase.
Systemy zarządzania relacyjnymi bazami danych mają za sobą długą historie, a rola odgrywana przez nie w obsłudze danych zarówno w dużych, jak i małych organizacjach jest trudna do przecenienia. Należy oczekiwać, że w nieodległej przyszłości wpływ tych programów na nasze życie ulegnie dalszemu zwiększeniu na skutek integracji ich możliwości z architekturą sieci Internet.

Podsumowanie

We wstępie do tego rozdziału zdefiniowaliśmy dwie podstawowe kategorie baz danych: operacyjne bazy danych i analityczne bazy danych.
Następnie omówiliśmy pokrótce model hierarchiczny oraz model sieciowy. Powiedzieliśmy parę słów na temat struktur danych, relacji i sposobów dostępu wykorzystywanych w obu tych modelach; powiedzieliśmy również o ich głównych wadach. Modele te były często wykorzystywane we wczesnym okresie rozwoju baz danych i doprowadziły w końcu do stworzenia oraz spopularyzowania modelu relacyjnego.
Po tym wstępie skoncentrowaliśmy się na relacyjnym modelu logicznym, na jego historii oraz głównych wyróżnikach. Zauważyliśmy, że jest on oparty na dwóch gałęziach matematyki i że owe matematyczne podstawy nadają modelowi relacyjnemu jego wyjątkowe cechy. Później przeszliśmy do omówienia struktur danych i relacji w RMBD oraz opisaliśmy funkcję pełnioną przez język SQL. Od tej pory powinieneś pamiętać, że SQL jest standardowym językiem wykorzystywanym w relacyjnych bazach danych. Dział zakończyliśmy opisem wad i zalet modelu relacyjnego.
Na koniec zapoznałeś się z podstawowymi informacjami dotyczącymi systemów zarządzania relacyjnymi bazami danych (SZRBD). Przedstawiliśmy krótką historię tych systemów, zaczynając od wielkich komputerów mainframe z lat siedemdziesiątych, przez pecetowe aplikacje lat osiemdziesiątych, aż do wykorzystywanych obecnie pakietów klient-serwer. Powinieneś więc zdawać już sobie sprawę z okoliczności, które doprowadziły do stworzenia zaawansowanych systemów dnia dzisiejszego.