Obiekt ID =5 Dziecko Obiekt ID =2 Pracownik Dzieci = 4, 3, 6 Obiekt

Obiektowy model danych.
Obiektowy model danych wynika bezpośrednio z paradygmatu obiektowego.
Obiekty encji uŜywane w programach obiektowych są analogiczne do encji bazy danych uŜywanych w
bazach czysto obiektowych, z jedną istotną róŜnicą: obiekty programu znikają po zakończeniu jego
działania, a obiekty bazy danych pozostają.
Koncepcja ta nosi nazwę trwałości (ang. persistence). Na koncepcji trwałych obiektów opiera się
większość dzisiejszych czysto obiektowych systemów zarządzania bazami danych, w których deklaracje
klas są bardzo podobne do tych, jakie spotyka się w obiektowych językach programowania.
Deklaracje klas muszą jednak nie tylko wskazywać, Ŝe obiekty utworzone na ich podstawie są trwałe, lecz
równieŜ w jakiś sposób pokazać zaleŜności między obiektami.
Obiektowo-relacyjne bazy danych określane są równieŜ jako bazy postrelacyjne bądź teŜ hybrydowe.
Obiektowe relacje między danymi.
Obiektowa baza danych musi umoŜliwiać reprezentowanie nie tylko tradycyjnych relacji bazy danych
(„jeden do wielu" i „wiele do wielu"), ale takŜe relację „jest" wynikającą z dziedziczenia.
Identyfikatory obiektów.
W relacyjnej bazie danych relacje między danymi reprezentowane są poprzez konieczność
dopasowania danych klucza podstawowego i obcego. W bazie takiej nie ma struktur danych tworzących
powiązania między tabelami. Relacje uŜywane są w miarę potrzeb poprzez łączenie tabel.
Natomiast w czysto obiektowej bazie danych relacje zakodowane są „na sztywno", przez
umieszczenie wewnątrz obiektu identyfikatorów innych, powiązanych z nim obiektów.
Identyfikator obiektu jest wewnętrznym identyfikatorem bazy danych przypisywany kaŜdemu
obiektowi.
UŜytkownicy,
umoŜliwiający
programiści,
wykonywanie
zapytań,
czy
nigdy
teŜ
nie
uŜytkownicy
widzą
ani
obsługujący
bezpośrednio
interaktywny
nie
program
manipulują
tymi
identyfikatorami.
Identyfikatory obiektów są przydzielane i uŜywane tylko przez DBMS.
Identyfikatory mogą mieć róŜne znaczenie w róŜnych systemach zarządzania bazami danych. Mogą to być
dowolnie ustalone wartości lub informacje potrzebne do zlokalizowania obiektu w pliku bazy.
Przykład 1.
Prostokąty oznaczają pracowników, a elipsy dzieci. Wszystkie obiekty mają unikatowe identyfikatory. Jak
widać, kaŜdy identyfikator obiektu jest inny.
Obiekt ID =2
Pracownik
Dzieci = 4, 3, 6
Obiekt ID =5
Dziecko
Obiekt ID =1
Pracownik
Dzieci = 5
Obiekt ID =6
Dziecko
Obiekt ID =3
Dziecko
Obiekt ID =4
Dziecko
Obiekty klasy Pracownik mają atrybuty o nazwie Dzieci, które zawierają atrybuty w postaci
identyfikatorów dzieci pracowników.
Wnioski :
-
identyfikator obiektu nie moŜe się zmienić, tylko wówczas mechanizm ten będzie działał.
-
przy przeszukiwaniu bazy danych ( zapytania ) mogą być wykorzystane tylko te relacje, które
zostały uprzednio zdefiniowane przez zapisanie ich w atrybutach identyfikatorów powiązanych
obiektów,
czyli obiektowa baza danych ma charakter nawigacyjny, podobnie jak wcześniejsze
hierarchiczne i sieciowe modele danych.
Pod tym względem obiektowy model danych jest krokiem wstecz, poniewaŜ ogranicza elastyczność
działań programisty lub uŜytkownika do tych predefiniowanych relacji.
Dlatego obiektowe bazy danych generalnie nie nadają się tak dobrze do zapytań ad hoc jak bazy
relacyjne. Z kolei wyszukiwanie danych zgodnie ze ścieŜkami zdefiniowanymi przez relacje między
danymi, daje większą wydajność niŜ w przypadku bazy relacyjnej, gdyŜ lokalizowanie obiektów za
pomocą identyfikatorów jest o wiele szybsze niŜ łączenie tabel.
Relacje typu „jeden do wielu”.
Aby przedstawić relację „jeden do wielu", po stronie „wielu" relacji definiuje się atrybut klasy, w
którym
będzie
przechowywany
identyfikator
obiektu
macierzystego
(rodzica).
Klasa
obiektów
macierzystych ma atrybut, w którym znajdą się identyfikatory powiązanych z nią obiektów. Gdy DBMS
zobaczy atrybut, którego typ danych będzie inną klasą, zorientuje się, Ŝe atrybut ten słuŜy do
przechowywania identyfikatorów obiektów, a nie samych danych.
Aby na przykład powiązać pracowników z ich dziećmi, klasa Dziecko moŜe mieć atrybut o typie danych
Pracownik. Klasa Pracownik będzie zawierała atrybut typu Dziecko zadeklarowany jako zbiór wartości.
NaleŜy pamiętać, Ŝe chociaŜ relacja jest zdefiniowana przez atrybuty w klasie, to w samej bazie danych
relacje istnieją między obiektami, podobnie jak relacje klucz podstawowy - klucz obcy zachodzą między
określonymi rekordami, a nie całymi tabelami.
Relacje typu „wiele do wielu”
W obiektowej bazie danych obiekty mogą mieć atrybuty wielowartościowe, pozwala to na
bezpośrednie przedstawienie relacji „wiele do wielu", bez konieczności tworzenia złoŜonych encji do
usuwania zaleŜności. W kaŜdej klasie uczestniczącej w relacji definiowany jest atrybut zawierający zbiór
wartości innej klasy, z jaką będzie powiązany.
MoŜliwość tworzenia bezpośredniej reprezentacji zaleŜności „wiele do wielu" wydaje się zaletą
obiektowej bazy danych. Występują tu jednak pewne niedogodności.
Po pierwsze, mając powiązane dane, jak na przykład cenę towaru róŜną w zaleŜności od dostawcy, u
jakiego towar został zamówiony, konieczne będzie utworzenie encji złoŜonej przechowującej te dane.
Relacja „wiele do wielu" zostanie wtedy zastąpiona przez dwie relacje „jeden do wielu", podobnie jak w
relacyjnej bazie danych.
Po drugie, w bazie danych zawierającej relacje „wiele do wielu" moŜe występować utratę informacji
lub teŜ niemoŜność dokładnego określenie zaleŜności.
Przykład :
Mamy trzy klasy: Sklep, Klient i Towar, kaŜdy z kształtów reprezentuje obiekty innej klasy.
Linie na wykresie między obiektami wskazują, które obiekty są powiązane ze sobą.
Baza przedstawia klientów, którzy zakupili towary w określonych sklepach oraz towarów zakupionych
w tych sklepach. Zachodzi tutaj relacja „wiele do wielu" między klientem a sklepem oraz relacja „wiele
do wielu" między klientem a towarem (jest równieŜ relacja „wiele do wielu" między towarem a
sklepem, lecz w tej bazie nie ma ona znaczenia, o ile nie będzie powiązana z klientem, który zakupił
towar).
Z diagramu moŜna ustalić, Ŝe klient nr l zakupił towary nr l i nr 2 w sklepie nr l (jeden klient dokonuje
zakupów wielu towarów w jednym sklepie). Podobnie widać, Ŝe klient nr 2 dokonał zakupów w
sklepach nr l i nr 2 oraz Ŝe obydwa zakupy dotyczyły jednego towaru (jeden klient dokonuje zakupu
jednego towaru w wielu sklepach). W przypadku klienta nr 3 obraz nie jest juŜ tak jasny.
Klient nr 3 kupował zarówno w sklepie nr 2, jak i nr 3. Jednocześnie klient nr 3 zakupił towar nr 2 i
towar nr 3 (jeden klient dokonuje zakupów wielu towarów w wielu sklepach). W którym sklepie
klient nr 3 kupił poszczególne towary ?
Poprzez stosowanie relacji „wiele do wielu", straciliśmy informację: sklep, w którym został kupiony
określony towar.
Sklep 1
Klient 1
Produkt 1
Sklep 2
Sklep 3
Klient 2
Klient 3
Produkt 2
Produkt 3
Rozwiązaniem jest usunięcie relacji „wiele do wielu" między klientami a towarami przez wstawienie
złoŜonej encji reprezentującej zakup towaru przez klienta w sklepie.
Nowa klasa Zakup wiąŜe jeden lub więcej towarów z określonym klientem i sklepem. Nie ma teraz
wątpliwości, Ŝe klient nr 3 kupił towar nr 2 w sklepie 2 oraz Ŝe towar nr 3 pochodził ze sklepu nr 3.
Teraz dopiero relacja „wiele do wielu” nie powoduje utrat informacji. Jej stosowanie w obiektowym
modelu danych naleŜy jak widać dokładnie zaplanować.
Klient 2
Sklep 1
Sklep 2
Sklep 3
Zakup 3
Zakup 2
Zakup 5
Klient 1
Zakup 1
Zakup 4
Produkt 3
Klient 3
Produkt 1
Produkt 2
Widać wyraźnie, Ŝe Klient 3 kupił Produkt 2 w Sklepie 2 oraz Ŝe Produkt 3 został zakupiony w Sklepie 3.
Relacja „Jest „
PoniewaŜ paradygmat obiektowy obsługuje dziedziczenie, w obiektowej bazie danych między
obiektami moŜe równieŜ istnieć relacja „jest" (ang. is a).
Deklarujemy klasę Pracownik z następującymi atrybutami: nazwisko, adres, numer ubezpieczenia,
data zatrudnienia i dział.
Problem pojawia się przy rejestrowaniu sposobu wynagradzania pracownika, poniewaŜ jedni są
płatni za godziny, inni otrzymują pensję miesięczną.
Klasa dla pracowników płatnych za godziny wymaga atrybutów zawierających stawkę godzinową,
płacę za pracę w nadgodzinach oraz miesięczną normę godzin. Klasa dla pracowników wynagradzanych
miesięcznie wymaga tylko atrybutu przechowującego wysokość rocznego zarobku.
Prawidłowy sposób rozwiązania tego problemu polega na utworzeniu dwóch podklas klasy Pracownik,
po jednej dla kaŜdego rodzaju pracownika.
Obecność tych klas powoduje, Ŝe projekt staje się on bardziej czytelny, a ponadto ułatwia pracę
programistów, którzy mogą napisać metody uŜywane przez obie podklasy tylko raz, dla klasy Pracownik.
Relacja „rozszerza".
Teoria obiektowych baz danych obsługuje dwa rodzaje dziedziczenia :
relację „jest"
oraz
relację „rozszerza" (ang. extends).
Relacja „jest", tworzy hierarchię dziedziczenia, w której podklasy są szczególnymi typami ich klasy
bazowej.
W przypadku relacji „rozszerza" zachodzi natomiast rozszerzenie definicji podklasy względem klasy
bazowej, a nie jej zawęŜenie do bardziej szczególnego typu.
Dla przykładu wcześniejszego z klasą Pracownik, oprócz klas opisujących pracowników odmiennie
wynagradzanych, potrzebna jest jeszcze informacja o kierownikach, którzy równieŜ są pracownikami.
Tworzymy więc się klasę Kierownik z dodatkowym atrybutem (wielowartościowym ), w którym będą
zapisani pracownicy podlegający danemu kierownikowi. Kierownik jest pracownikiem o dodatkowych
cechach.
Klasa Kierownik rozszerza zatem definicję kaŜdej z klas związanych ze sposobem wynagradzania,
zamiast ją uszczegóławiać.
Relacja „całość-część".
Koncepcje części całości jest trudniej zaprezentować w relacyjnej bazie danych.
Przykład :
Jest baza danych w fabryce, w której mają być rejestrowane części i podzespoły uŜywane do wytwarzania
określonych produktów.
W obiektowej bazie danych moŜna natomiast wykorzystać relację zwaną „całość-część" ( wiele do
wielu), w której obiekty danej klasy powiązane są z obiektami innych klas wchodzących w jej skład.
W przykładowej bazie za pomocą relacji „całość-część" będzie powiązana klasa Produkt z klasami Część i
Podzespół.
Produkt moŜe składać się z wielu części i podzespołów. Podobnie ta sama część lub podzespół moŜe
być uŜyty w wielu róŜnych produktach.
Relacja „całość-część" ma bardziej szczególne znaczenie niŜ zwykła relacja „wiele do wielu" i moŜna
ją umieścić w dokumentacji projektu bazy, by ułatwić zrozumienie projektu.
Relacja między produktami, częściami i podzespołami jest w rzeczywistości trochę bardziej
skomplikowana , poniewaŜ podzespoły składają się z części, a same równieŜ mogą wchodzić w skład
większych podzespołów.
Integralność relacji.
Funkcjonowanie relacji w czysto obiektowych bazach danych, jest zaleŜne od zachowania zgodności
identyfikatorów obiektów po obu stronach relacji.
Jeśli na przykład istnieje powiązanie między pracownikami a ich dziećmi, wówczas musi istnieć
mechanizm zapewniający, Ŝe jeśli identyfikator obiektu klasy Dziecko zostanie wstawiony do obiektu
klasy Pracownik, wtedy identyfikator tego samego obiektu Pracownik będzie wstawiony do obiektu
Dziecko.
Integralność relacji, przypomina integralność powiązań w relacyjnym modelu danych i realizowana
jest poprzez określenie relacji odwrotnych (ang. inverse relationship).
Za integralność powiązań w relacyjnej bazie danych odpowiedzialny jest projektant, podobnie jak za
określenie relacji odwrotnych w obiektowej bazie danych.