Rozdział 4
Obiektowe projektowanie relacyjnych baz danych
(Marek Miłosz)
Od chwili ogłoszenia przez dr. Edgara Codda [7] postulatów budowy relacyjnych baz danych
przemysł informatyczny rozwinął cały szereg systemów zarządzania tymi bazami oraz
metodyk ich projektowania. Idea uproszczonego przedstawienia struktur danych w postaci
jednorodnych tabel i paru prostych mechanizmów łączenia ich w system zaowocowała
wzrostem wydajności programistów, którzy nie musieli wnikać w wewnętrzne mechanizmy
przechowywania danych, i standaryzacją języka dostępu do danych SQL (ang. Structured
Query Language). Idea wielowarstwowej architektury bazy danych, różnych poziomów
abstrakcji przedstawienia tego samego problemu przeniknęła do procesu projektowania
i wprowadziła podział projektu (i w konsekwencji technik jego przedstawienia) na projekt
konceptualny przedstawiany w pojęciach użytkownika systemu i implementacyjny
w konkretnym systemie bazy danych. Przejście pomiędzy obydwoma poziomami
projektowania, czyli tzw. mapowanie modeli, powinno być jednoznaczne.
Parę lat po wynalezieniu relacyjnego modelu baz danych powstała podstawowa metodyka
ich projektowania konceptualnego diagramy związków encji, wymyślone przez Petera Chena
[6]. Od tamtych czasów w informatyce nastąpił zwrot ku obiektowości. Zwrot ten dotyczy
bardzo silnie języków programowania oraz, w ostatnich latach, metodyk projektowania.
Relacyjne bazy danych także ustawicznie migrują w stronę obiektowych, rozszerzając raczej
model relacyjny nizli od niego odchodząc. Większość rozszerzeń modelu relacyjnego wynika
z uwarunkowań ułatwienia dostępu do danych, zwiększenia efektywności przetwarzań czy też
bezpieczeństwa danych. Relacyjne bazy danych spełniają bowiem większość typowych
wymagań aplikacji dla firm i organizacji. Inne typy, takie jak obiektowo-relacyjne, obiektowe,
hierarchiczne czy hipertekstowe, znajdują obecnie zastosowanie w niszowych obszarach
przetwarzania danych.
Obiektowo-relacyjny model danych
Relacyjny model danych od samego początku swojego powstania przypisywał bazie danych
właściwości proceduralne. Do nich bowiem można zaliczyć wszystkie bez wyjątku warunki
integralności, które mają być kontrolowane przez system bazy danych. Poprawność
wprowadzanych wartości, unikalność wiersza w tabeli (krotki w relacji) czy też integralność
związku pomiędzy tabelami (integralność referencyjna) jest zapewniana proceduralnie
40 Współczesne technologie informatyczne
w przypadku występowania odpowiednich zdarzeń w bazie danych. Procedury te realizują
ściśle zdefiniowane sposoby zachowania się serwera bazy danych (np. odmowa, komunikat,
nadawanie wartości domyślnej czy też kasowanie kaskadowe). Podobnie wymaganie
możliwości tworzenia perspektyw jest w istocie rzeczy wymaganiem proceduralnym
w stosunku do bazy danych.
Istotne ograniczenia modelu relacyjnego zostały wprowadzone doń od samego początku
przynajmniej w teorii. Są to proste typy danych, brak możliwości ich rozszerzania, brak
środków do przechowywania danych proceduralnych, brak implementacji skomplikowanych
i dynamicznych reguł poprawności, wymóg normalizacji bazy danych, wymóg dostępu
poprzez identyfikatory, pełne oderwanie struktur danych od programów. Wszystkie te
elementy w poszczególnych implementacjach systemów zarządzania relacyjnymi bazami
danych (SZRBD) były sukcesywnie modyfikowane. Modyfikacje te z jednej strony
udostępniały coraz to więcej możliwości, uelastyczniły przechowywanie i zarządzanie danymi,
z drugiej skutecznie ograniczały możliwości standaryzacji. W konsekwencji, każdy SZRBD
oprócz standardowego języka SQL oferuje swoje własne, zwykle proceduralne jego
rozszerzenie.
Proste, sztywne struktury danych nie nadają się do przechowywania danych słabo lub
całkowicie niezestrukturyzowanych, o różnej zawartości, nieznanych lub nowych typów.
SZRBD wprowadzały zatem takie typy jak BLOB (ang. Binary Large Object), podtypy,
wektorowe wartości pól (pola wielowartościowe) czy też typy danych definiowane przez
projektanta [41]. Coraz częściej typy te noszą charakter typów obiektowych, a więc
umożliwiające projektantowi zdefiniowanie własnych typów oraz przypisanie im zachowania
metod.
Wymaganie normalizacji struktury relacyjnej bazy danych, zalecane jako walka
z redundancją [44], doprowadza do znacznego wzrostu złożoności struktur. Informacja
dotycząca danego obiektu rzeczywistego jest rozproszona bowiem pomiędzy wiele tabel,
powiązanych ze sobą relacjami. Takie rozproszenie ma dwa negatywne skutki. Z jednej strony
powoduje wzrost problemów na etapie projektowania i pielęgnacji bazy danych złożoność
utrudnia bowiem projektantom, programistom i administratorom zrozumienie semantyki
modelu danych. Z drugiej strony zmniejsza się efektywność przetwarzania danych, i to
pomimo opracowania całego szeregu metod optymalizacji złączeń, indeksowania, B-drzew itp.
Ten ostatni problem relacyjnych baz danych uwidocznił się silnie (oraz przyczynił do
powstania różnych teoretycznych i praktycznych metod denormalizacji) w procesie tworzenia
hurtowni danych.
Życie wniosło do relacyjnych baz danych takie nierelacyjne elementy jak sekwencje,
etykiety, teksty komunikatów i helpów. Zmiany te w zasadzie są zgodne z postulatem
centralizacji funkcji zarządzania i kontroli danych przez SZRBD, ale niezgodne z relacyjnym
modelem danych.
Jeszcze większą rewolucję w relacyjnych bazach danych wprowadziły możliwości
proceduralne, definiowane przez projektanta programistę. Są to procedury wbudowane w bazę
danych i wykonywane przez serwer na zlecenie aplikacji oraz definiowane procedury
wyzwalaczy czy też aktywnych reguł, reagujących na zdarzenia w bazie danych. Większość
współczesnych SZRBD posiada te mechanizmy implementacji zachowań po stronie serwera.
W dziedzinie baz danych widoczne jest zatem podejście ewolucyjne: od relacyjnych,
poprzez obiektowo relacyjne aż do, być może, obiektowych baz danych. Podejście to
umożliwia płynną modyfikację modelu, a więc zmniejsza koszty i skalę problemów, ale też
powoduje spory bałagan implementacyjny. SZRBD od poszczególnych dostawców różnią się
od siebie w istotny sposób. Relacyjny model danych jest tylko szczególnym przypadkiem
Obiektowe projektowanie relacyjnych baz danych 41
modelu obiektowego. Wielkość nakładów finansowych i uzyskane do tej pory wyniki
w postaci relacyjno-obiektowych baz danych rokują tej technologii długie życie.
Obiekty w obiektowo-relacyjnej bazie danych mogą być składowane jako obiekty
krotkowe (wierszowe) lub atrybutowe (kolumnowe). Tylko obiekty wierszowe mają swoją
tożsamość identyfikowaną przez automatycznie generowany OID (ang. Object Identifier). Dla
obiektów w bazie danych wykorzystywany jest cały arsenał metodologiczny obiektowości.
W większości komercyjnych baz danych możliwość składowania obiektów w relacyjnej bazie
danych jest realizowana przez specjalną programową warstwę tłumaczącą model obiektowy na
relacyjny i odwrotnie. Pozwala to wykorzystać istniejące motory przetwarzań, ale zniża
wydajność bazy danych.
Projektowanie relacyjnych baz danych
Podstawową techniką projektowania relacyjnych struktur danych na poziomie koncepcyjnym
są diagramy związków encji (ang. ERD Entity Relationship Diagram) rys. 4.1. Technika ta
zakłada wydzielenie encji, jako obiektów informacyjnych niosących dane potrzebne z punktu
widzenia realizacji funkcji projektowanego systemu. Obiekty te mogą być rzeczywiste (osoby,
jednostki organizacyjne, rzeczy, dokumenty itp.) lub wyobrażone (zdarzenia, abstrakcje itp.).
Klienci
PESEL
Nazwisko klienta
Imie klienta
Rower Wypozyczenie Data urodzenia
Numer roweru Numer wypozyczenia Nr dowodu tozsamosci
Typ roweru
jest ma
ma
Kolor Data wypozyczenia Rodzaj dowodu tozsamosci
Kod typu
Rok produkcji Data planowana zwrotu Kod pocztowy
Nazwa typu roweru
Status roweru Data zwrotu Miasto
Status Ulica
Numer domu/mieszkania
Telefon staly
jest zwiazany
Telefon komorkowy
Cennik
Pozycja cennika
Cena za godz.
Cena stala
Rysunek 4.1. Diagram ERD jako projekt koncepcyjny bazy danych
Encja jest definicją (z punktu widzenia zawartości informacyjnej) zbioru obiektów
a więc klasą w rozumieniu technik obiektowych. Encje podobnie jak obiekty posiadają
atrybuty. Encje mają (podobnie jak klasy) swoje rozróżnialne instancje wystąpienia. Innym
elementem techniki ERD są powiązania pomiędzy encjami związki, relacje. Relacje te to
sposób odwzorowania istotnych (z punktu widzenia projektowanego systemu) powiązań
pomiędzy obiektami instancjami encji. Powiązania charakteryzują się całym szeregiem
parametrów (rys. 4.1):
" nazwa specyfikuje charakter relacji;
" liczność (krotność, moc, częstość wystąpień) wskazuje ile instancji jednej encji
wstępuje w związek z obiektami drugiej encji;
42 Współczesne technologie informatyczne
" inne charakterystyki związku, takie jak obowiązkowość lub opcjonalność, wzajemne
wykluczanie się przy związkach wielokrotnych (np. ternarnych w notacjach Chena
lub SSADM), generalizacja (w notacji IDEF1X) lub też relacje silne i słabe
(identyfikujące, słownikowe) [24].
Wszystkie techniki modelowania struktur relacyjnych przewidują przejście od modelu
konceptualnego do implementacyjnego (a więc układu tabel powiązanych związkami klucz
główny klucz obcy) rys. 4.2. Takie mapowanie modeli wykonuje się zwykle automatycznie.
Problemy wynikające w trakcie tego procesu, takie jak zmiana nazw na identyfikatory,
mapowanie typów analitycznych na implementacyjne, zamiana związków na klucze obce
i referencje są dość łatwe do rozwiązania. Inne problemy (np. definiowanie dodatkowych
indeksów kluczy) wynikają z projektu funkcjonalności systemu informatycznego, a więc
struktury zapytań do bazy danych, i wymagają dogłębnej znajomości SZRBD.
Wypoz
Nr-wyp Integer
Rowery
PESEL
Character (11) Check
Typy
nr_row Character (4)
jest
nr_row Character (4)
ma
kod_typu Character (1) Check
kod_typu Character (1) Check
d_wyp DateTime
P-cen Character (2)
Kolor Character (12)
d_zw_pl DateTime
nazwa_typ Character (15) Not Null
r_prod Date
d_zw DateTime
St_r Character (1) Not Null
Status Character (1)
jest zwiazany
ma
Ceny
P-cen Character (2)
cena_h Decimal (6.2)
cena_const Decimal (6.2)
Klienci
PESEL Character (11) Check
Name Character (20) Not Null
Imie Character (12) Not Null
d_ur Date Not Null
nr-dow Character (8)
R_DT Character (1) Not Null
Kod_p Character (5) Not Null
Miasto Character (12)
Ulica Character (15)
nr_m Character (6)
tel_d Character (15)
tel_m Character (15)
Rysunek 4.2. Implementacyjny model relacyjnej bazy danych z rys. 4.1
(FKn klucze obce, AKn klucze-indeksy alternatywne)
Diagramy związków encji są w pewnym sensie techniką obiektową, gdyż wykorzystują
takie pojęcia obiektowości jak: klasa, obiekt, atrybut, hermetyzacja.
Model ERD nie przewiduje natomiast przypisywania encjom elementów proceduralnych
innych niż kontrola poprawności danych i związków pomiędzy nimi. Cecha ta powoduje, że
diagramy ERD są coraz mniej przydatne do projektowania współczesnych obiektowo-
relacyjnych baz danych.
Istotnym problemem w projektowaniu systemów informatycznych, wykorzystujących
relacyjne bazy danych, jest wielowarstwowość współczesnych aplikacji (rys. 4.3).
Wykorzystują one w warstwie prezentacyjnej technikę obiektową (programowanie interfejsu
Obiektowe projektowanie relacyjnych baz danych 43
GUI) a na najniższym poziomie relacyjne (lub obiektowo-relacyjne) bazy danych. Warstwa
pośrednia (aplikacyjna rys. 4.3) może mieć charakter obiektowy lub strukturalny.
Użytkownik
<>
Interfejs -
GUI
OBIEKTOWY
<>
Aplikacja
<>
Baza danych -
SZRBD
RELACYJNA
Rysunek 4.3. Wielowarstwowa architektura aplikacji
W większości zastosowań baz danych model relacyjny, rozszerzony o elementy
obiektowości, jest modelem sprawdzonym i wystarczającym.
Obiektowe projektowanie systemów informatycznych
Rozwój technik obiektowych w projektowaniu systemów informatycznych zachodził
wielotorowo i bardzo burzliwie. Wszystkie znaczące ośrodki i poszczególni guru inżynierii
oprogramowania opracowywały własne metodyki. Do najważniejszych należały: OMT,
OOA/OOD, OOSA, metodyka Boocha i natacja Objectory Jacobsona OOSE. W chwili
obecnej, dzięki połączeniu sił wielu instytucji i osób skrystalizował się ogólnie uznany
standard: zunifikowany język graficznego modelowania systemów UML (ang. Unified
Modeling Language) [24].
Jednym z podstawowych elementów UMLa jest diagram klas [6, 7], który odwzorowuje
elementy systemu informatycznego (klasy) oraz ich powiązania (rys. 4.4). Diagram klas jest
wykorzystywany na wszystkich poziomach modelowania systemu: od poziomu biznesowego
poprzez interfejs, aż do poziomu technicznego [22].
Diagram klas jest pojęciowo bardzo bliski diagramowi ERD. Podstawowymi elementami
diagramu klas są bowiem:
" klasy (uogólnienie, abstrakcja pojęcia obiektu), które łączą w sobie atrybuty i metody;
44 Współczesne technologie informatyczne
" związki pomiędzy klasami, które mogą być różnych typów: generalizacja, zależność
i powiązanie (asocjacja).
Osoba
Firma
zatrudnia Pracownik
nazwisko
nazwa
zawód[*] imię[1..*]
Lokal[1..*]
1..*
1..*
*
* Adres[1..*]
Zatrudnienie
dataZatrudnienia
wypłata [*]
ocena[*]
zajmowaneStanowisko : Stanowisko
Stanowisko
nazwaStanowiska
wymagania
Rysunek 4.4. Diagram klas (opracowanie własne na podstawie [41])
Diagram klas w istotny sposób wzbogaca diagram ERD. Klasy jako bezpośrednie
odpowiedniki encji są semantycznie znacznie bogatsze od nich nie mają ograniczenia typów
atrybutów tylko do typów prostych oraz umożliwiają definiowanie procedur metod. Poza tym
klasyczną cechą każdego elementu klasy jest jego dostępność: publiczna, chroniona, prywatna
i ew. implementacyjna. Pojęcie to jest nieznane w relacyjnym modelu danych, w którym nie
występują elementy hermetyzacji, a dane są zawsze dostępne bezpośrednio. Diagramy klas
oferują możliwość odwzorowania nie tylko powiązań (asocjacji) jak to miało miejsce na
diagramach ERD, ale również związków typu generalizacja oraz zależności, czyli związku
użycia. Już nawet pojęcie powiązania w diagramie klas jest bogatsze niż na ERD: wyróżnia się
bowiem dwa specyficzne typy asocjacji agregacje i kompozycje. Pojęcia te nawiązują do
więzów integralności referencyjnej, znanych z relacyjnych baz danych.
Przekształcenie modelu obiektowego w model relacyjny
Mapowanie modelu obiektowego w postaci diagramu klas w model relacyjny w zasadzie
odbywa się na poziomie danych, poprzez przekształcenie obiektów w tabele, a ich atrybutów
w kolumny tabel. Przy czym takie oczywiste przekształcenie dopuszczalne jest dla prostych
typów danych (z pewnym rozszerzeniem klasycznych typów o wartość null, która jest istotna
z punktu widzenia relacyjnych struktur) i wymaga bardzo często dodania dodatkowych
atrybutów-kolumn identyfikujących wartościowo w sposób jednoznaczny wiesze z danymi
czyli kluczy głównych. Klucze główne w wielu przypadkach są elementami sztucznymi, nie
występującymi w rzeczywistości i są narzutem nakładanym na dane przez relacyjny model.
Obiektowe projektowanie relacyjnych baz danych 45
Dla atrybutów wielowartościowych, jak również dla zdefiniowanych związków użycia,
przejście do modelu relacyjnego wywołuje konieczność wprowadzenia dodatkowych tabel
(rys. 4.5 i 4.6) powiązanych relacjami z tabelą podstawową.
Student Jezyk
Student
Nr_albumu Nr_albumu
Nazwisko : String (25)
Nazwisko Jezyk
Imię : String (15)
Imię
JęzykObcy[0..*] : Język
Rysunek 4.5. Mapowanie atrybutu wielowartościowego o wartościach unikalnych na tabelę
Student Wplata
Student Wplata
Student
Nr_albumu Nr_albumu
Nr_albumu Nr_albumu
Nazwisko : String (25)
Nazwisko Nr_wplaty
Nazwisko Nr_wplaty
Imię : String (15)
Imię Kwota_wplaty
Imię Kwota_wplaty
WpłataCzesnego[0..*] : Currency
Rysunek 4.6. Mapowanie atrybutu wielowartościowego o wartościach powtarzających się
Odrębnym problemem jest mapowanie związków. Jest to zadanie stosunkowo proste dla
asocjacji. Są one bowiem semantycznie identyczne z relacjami, znanymi z diagramów ERD.
Przy liczności asocjacji 1:1 dwa obiekty zostają mapowane na pojedynczą tabelę (rys. 4.7).
W tym przypadku występuje zwykle problem wyboru klucza głównego tabeli. Zwykle
tworzony jest klucz sztuczny. Przy asocjacjach 1:n tworzone są dwie tabele powiązane parą
klucz główny klucz obcy (rys. 4.8). Asocjacje n:m mapowane są na trzy tabele (rys. 4.9), przy
czym tabela środkowa jest tabelą łączącą wprowadzaną do relacyjnego modelu danych
z powodu wymagań ograniczenia redundancji.
Klient DowódTożsamości
PESEL +dotyczy numer
+posiada
nazwisko rodzaj .
1 1
imię 1 1
Klient
Id_klienta
PESEL
Nazwisko
Imię
Numer dowodu tozsamosci
Rodzaj dowodu tozsamosci
Rysunek 4.7. Mapowanie asocjacji 1:1 na pojedynczą tabelę
46 Współczesne technologie informatyczne
Pracownik
PracujeW Firma
nazwisko
nazwa
imię
1..n 1
1..n 1
Pracownik
Id pracownika
Firma
Nazwisko
Id firmy
Imie
ma
Nazwa
Id firmy
Rysunek 4.8. Mapowanie asocjacji 1:n na dwie tabele
Pracownik
PracujeW Firma
nazwisko
nazwa
imię
1..n n
1..n n
Pracownik Prac_Firma
Firma
Id pracownika Id pracownika
Id firmy
Nazwisko Id firmy
Nazwa
Imie
Rysunek 4.9. Mapowanie asocjacji n:m na dwie tabele
Model obiektowy (podobnie zresztą jak niektóre metodyki strukturalne) dopuszcza, by
asocjacja była obiektem, tj. posiadała swoje atrybuty i metody. Przykładem takim jest asocjacja
zatrudnia z rys. 4.4. Podczas mapowania asocjacja taka staje się tabelą.
Specyficzne typy asocjacji: agregacje i kompozycje są uwzględniane jako więzy
integralności referencyjnej (obowiązkowość lub nie- związku, modyfikowanie lub kasowanie
kaskadowe) rys. 4.10.
Obiektowe projektowanie relacyjnych baz danych 47
Wydzial
Uczelnia
Id_wydzialu
Id_uczelni
Nazwa_wydzialu
sklada sie
Nazwa_uczelni
Id_uczelni
ma
Uczelnia Wydział
pracuje
1..*
1..*
1
1
0..1
0..1
pracuje na
Wykladowca
Id_wykladowcy
Nazwisko
1..*
1..*
Imie
Wykładowca Id_wydzialu
Rysunek 4.10. Mapowanie kompozycji i agregacji
Istotnym problemem mapowania modelu obiektowego na relacyjny jest brak mechanizmów
w modelu relacyjnym do odwzorowania operacji dziedziczenia, a więc związków typu
generalizacja. Związki te mogą być mapowane w różny sposób na: pojedynczą tabelę,
rozdzielne tabele oraz na tabele powiązane ze sobą relacjami.
Klasy związane relacją dziedziczenia mogą być mapowane na pojedynczą tabelę
(rys. 4.11). Będzie ona zawierać wszystkie atrybuty wchodzące w skład powiązanych klas oraz
jeden dodatkowy, który umożliwi rozróżnienie wariantu dyskryminator (na rys. 4.11 jest nim
kolumna TYP_PLATNOSCI). Zaletą takiego mapowania jest niewątpliwa prostota i szybki
dostęp do danych, wadą nadmiarowość struktury. Znaczna część pól w wierszach tabeli
Platnosc z rys. 4.11 nie będzie bowiem wypełniona.
Płatność
Platnosc
kwota
Id_platnosci
data
Kwota
Sprzedawc a
waluta Data_platnosci
Sprzedawca
Waluta
TYP_PLATNOSCI
KwotaWe
Reszta
Numer_karty
KartaKredytowa
Gotówka Przelew
Data_waznosci
numerKarty
kwotaWe dataRealizacji
Kod_autoryzacji
dataWażności
reszta KontoPłatnika
Napiwek
Właściciel
Wlasciciel
kodAutoryzacji
Data_realizacji
napiwek
Konto_platnika
Rysunek 4.11. Powiązania typu generalizacja i mapowanie go na pojedynczą tabelę
48 Współczesne technologie informatyczne
Inne rozwiązanie problemu dziedziczenia to mapowanie go na rozdzielne tabele, z których
każda odpowiada klasie liściu w drzewie dziedziczenia i zawiera pełen zestaw
odziedziczonych atrybutów rys. 4.12. W tym rozwiązaniu nie występują nadmiarowe
kolumny oraz nie ma potrzeby stosowania dyskryminatora. Istotnym problemem może w tej
strukturze okazać się zapewnienie unikalności Id_platnosci w trzech tabelach równocześnie
(jeśli jest wymagana) i organizacja zapytań do układu tabel. Zapytania te w niektórych
przypadkach będą dość proste, a w innych bardzo skomplikowane (np. odszukaj płatność
o konkretnym Id_platnosci.
PlatnoscKarta
PlatnoscGotowkowa
Id_platnosci
PlatnoscPrzelew
Id_platnosci
Kwota
Id_platnosci
Data_platnosci Kwota
Kwota
Sprzedawca
Data_platnosci
Data_platnosci
Waluta
Sprzedawca
Sprzedawca
Numer_karty
Waluta
Waluta
Data_waznosci
KwotaWe
Data_realizacji
Kod_autoryzacji
Reszta
Konto_platnika
Napiwek
Wlasciciel
Rysunek. 4.12. Układ trzech tabel odpowiadający modelowi z rys. 4.11
Kolejnym rozwiązaniem problemu dziedziczenia jest układ wielu tabel powiązanych ze sobą
relacjami (rys. 4.13). Układ ten w zasadzie powtarza układ klas z diagramu (rys. 4.11)
z dodanym mechanizmem powiązania tabel kluczami obcymi. Układ ten nie ma nadmiarowych
kolumn, ale może stwarzać istotne problemy wydajnościowe przy realizacji zapytań. Innym
problemem, rozwiązywanym tylko proceduralnie, jest tutaj zapewnienie wykluczania się form
płatności.
PlatnoscNaglowek
Id_platnosci
Kwota
Data_platnosci
Sprzedawca
Waluta
Karta
Id_platnosci
Gotowka Przelew
Numer_karty
Id_platnosci Id_platnosci
Data_waznosci
KwotaWe Data_realizacji
Kod_autoryzacji
Reszta Konto_platnika
Napiwek
Wlasciciel
Rysunek 4.13. Układ czterech powiązanych tabel odpowiadający modelowi z rys. 4.11
Obiektowe projektowanie relacyjnych baz danych 49
Model relacyjny bazy danych nie przewiduje powiązania danych z metodami ich
przetwarzania. Powiązanie to powinno owocować trwałym przechowywaniem procedur
i funkcji razem z danymi, a więc w bazie danych. Część proceduralna przetwarzania danych
została wprowadzona do modelu relacyjnego jako postulaty unikalności klucza głównego,
integralności na różnych poziomach (pola, tabeli, referencji). Pozostałe możliwości
proceduralne były wprowadzane ad hoc przez dostawców SZRBD naruszając model relacyjny
z jednej strony, a standard SQL z drugiej.
Najbliższe idei metod związanych z danymi są w relacyjnych bazach danych wyzwalacze,
zwane niekiedy aktywnymi regułami. Są to definiowalne w języku programowania (zwykle
proceduralnym rozszerzeniu SQLa lub 4GL) procedury, które są wykonywane przez serwer
bazy danych w wyniku reakcji na predefiniowane zdarzenia zachodzące na danych. Zdarzenia
takie dotyczą zwykle jednej z czterech operacji z danymi: wprowadzenie, modyfikacja,
wyszukanie lub usunięcie danych i mogą być przypisane do kolumny, tabeli i związku
pomiędzy, a nawet np. do procesu replikacji danych. Wyzwalacze mogą być z powodzeniem
użyte do realizacji kontroli zakresu dostępności do atrybutów kolum w tabelach.
Innym elementem wiązania metod z danymi są procedury składowane w bazie danych
i wykonywane przez serwer. Procedury te mogą, ale nie musza być związane z tabelami.
Definiują one wspólną dla wielu aplikacji funkcjonalność bazy danych.
Przykład mapowania modeli
W trakcie mapowania modelu obiektowego na relacyjny następuje spłaszczenie i uproszczenie
struktur danych. Prowadzi to wzrostu złożoności modelu (rys. 4.14) oraz wzrostu liczby
różnych dodatkowych elementów danych (kluczy głównych i obcych), wprowadzanych do
modelu w sposób sztuczny po to tylko by spełnić wymagania modelu relacyjnego rys. 4.15.
Jeden obiekt mapowany jest bowiem na cały szereg powiązanych ze sobą tabel.
Zawód
jest
Imie
wystepuje
Prac_zawód
Imiona_Pracownika
posiada
ma
Firma Zatrudnienie Pracownik
zatrudnia jest
dotyczy
jest
ma
zajmuje Adres
Lokal Ocena Wyplata Stanowisko
Rysunek 4.14 Diagram ERD odpowiadający modelowi obiektowemu z rys. 4.4
50 Współczesne technologie informatyczne
Rysunek 4.15. Struktura relacyjnej bazy danych odpowiadająca modelowi z rys. 4.14
(pokazano tylko kluczowe atrybuty)
Obiektowe projektowanie relacyjnych baz danych 51
Podsumowanie
Po uwzględnieniu ograniczeń relacyjnego modelu bazy danych możliwe jest wykorzystanie
metodyk obiektowego projektowania systemów informatycznych, a w szczególności języka
UML, do projektowania struktur SZRBD. Przekształcenie statycznej (a więc związanej ze
strukturą danych) części diagramu klas jest stosunkowo proste, natomiast część dynamiczna
(metody obiektów) jest realizowana poprzez proceduralne rozszerzenia relacyjnych baz
danych.
Wyszukiwarka
Podobne podstrony:
2009 02 Relacyjna baza danych HSQLDB [Bazy Danych]
Relacyjna baza danych Access 2007
2004 11 Porównanie serwerów relacyjnych baz danych Open Source [Bazy Danych]
01 Projektowanie relacyjnej bazy danych Czym jest relacyj
BAZA DANYCH GEOLOGICZNYCH
BAZA DANYCH GMINNEJ EWIDENCJI ZABYTKÓW
Zestaw 1 Wprowadzenie do relacyjnych baz danych
Dokumenty XML w relacyjnych bazach danych czyli wojna światów I
Baza danych w programie Access
więcej podobnych podstron