Bazy danych w systemach obiektowych

Prezentacja na temat: "Bazy danych w systemach obiektowych"— Zapis prezentacji:

1 Bazy danych w systemach obiektowych

2 Problemy zarządzania danymi
Zarządzanie danymi sprowadza się do realizacji szeregu funkcji typowych dla przetwarzania danych, w dużej mierze niezależnych od środowiska implementacyjnego i przyjętej metodyki projektowania. Do najważniejszych należą: - trwałe i niezawodne przechowywanie dużych ilości informacji; - zapewnienie efektywnego dostępu do tych informacji na żądanie, według zadanych kryteriów wyszukiwania; - zapewnienie możliwości modyfikowania przechowywania informacji; - zagwarantowanie logicznej spójności (integralności) informacji, polegające na niedopuszczaniu do realizacji takich operacji, które naruszają definicje danych lub definicje wzajemnych powiązań logicznych pomiędzy poszczególnymi fragmentami danych; ochrona danych, rozumiana jako zagwarantowanie tego, że na określonych danych będą wykonywane jedynie dopuszczalne operacje i to przez określonych z góry użytkowników (którymi mogą być programy aplikacyjne, ich poszczególne składniki lub użytkownicy przy terminalach). W konkretnym przypadku nie wszystkie z tych funkcji są jednakowo ważne.

3 Bazy danych w projekcie systemu
Konieczność uwzględnienia bazy danych w projekcie (i później w implementacji) systemu może wynikać z kilku przyczyn takich jak: - niektóre obiekty składające się na system muszą mieć cechę trwałości, czyli powinny istnieć nie tylko w trakcie wykonywania programu, ale także po jego zakończeniu. Jest istotne w takich sytuacjach, w których program uruchamiany jest wielokrotnie i korzysta z wyników poprzedniego uruchomienia lub gdy wyniki jednego programu wykorzystywane są przez inne programy. - program może operować na dużych ilościach danych, niekoniecznie o charakterze trwałym. W modelu obiektowym dane takie są zazwyczaj gromadzone w pojemnikach danych w postaci obiektów, które przechowują i udostępniają te dane. Dla dużych składnic danych znaczenia nabiera problem efektywnych metod organizowania danych w struktury w pamięci zewnętrznej i dostępu do takich struktur według uniwersalnych kryteriów. Realizacja takich metod (zwykle bardzo skomplikowanych) sposobami konwencjonalnymi jest trudna i w praktyce nieopłacalna. Jednym z głównych zadań systemów baz danych jest zapewnienie takich metod. - jako narzędzie implementacyjne może zostać wybrane oprogramowanie do rozwoju aplikacji, wchodzące w skład pakietu konkretnego systemu DBMS. Oprogramowanie takie zawiera pewien język programowania, który wymusza na programiście stosowanie określonych konstrukcji bazodanowych w programie aplikacyjnym. Rzutuje to na projekt systemu, gdyż wówczas szereg decyzji projektowych wynika bezpośrednio z zastosowanego języka. Jeśli jako narzędzie implementacyjne zostanie wybrany język ogólnego przeznaczenia, projektant i programista zachowują większy wpływ na środki zastosowane w implementacji programu, jednak kosztem konieczności stosowania wywołań interfejsu programowania aplikacji oferowanego przez wykorzystywany system baz danych.

4 Systemy obiektowych baz danych - cechy
Najważniejszą cechą (poza jawnym uwzględnieniem obiektowego modelu danych) jest jednolity język programowania, w którym obiekty trwałe i obiekty programowe (nietrwałe) traktowane są identycznie. W takich językach nie ma potrzeby dokonywania jawnego dostępu do bazy danych (np. przez zanurzenie w programie zapytań formułowanych w specjalnie do tego przeznaczonym języku dostępu do danych, innym niż język programowania aplikacji); system zarządzania automatycznie zrealizuje taki dostęp, jeśli tylko w programie nastąpi odwołanie do obiektu przechowywanego w bazie danych. Cecha ta jest tak istotna, iż czasami systemy obiektowych baz danych nazywa się „językami programowania obiektowych baz danych”, a także „prawdziwymi systemami obiektowymi”. Te prawdziwe systemy zarządzania obiektowymi bazami danych (Object-Oriented Database Management System – OODBMS) zaczęły powstawać w drugiej połowie lat 80. Najważniejsze z nich to: Orion, Itasca, GemStone, ObjectStore, Ontos, O2, Jasmine, Versant, Objectivity/DB, Statice, GBase. Obiektowe bazy danych łączą w sobie obiektowy model danych z własnościami charakterystycznymi dla tradycyjnych („klasycznych”) baz danych. Podstawową jednostką manipulowania danymi w obiektowych bazach danych jest obiekt, rozumiany jako kompletna, hermetyczna i jednoznacznie identyfikowana struktura, obejmująca zarówno dane (atrybuty), jak i zachowanie (metody).

5 Charakterystyczne cechy
Charakterystyczne cechy obiektowego modelu danych, odróżniające go od modelu relacyjnego, a uwzględniane w obiektowych bazach danych, to: - tożsamość obiektu (w modelu relacyjnym encje identyfikowalne są jednoznacznym kluczem będącym pojedynczym atrybutem lub złożeniem kilku atrybutów; w modelu obiektowym obiekty mają tożsamość niezależną od ich wartości), - hermetyzacja (zamknięcie danych i operujących na nich procedur we wnętrzu obiektu, niedostępnym z zewnątrz; w modelu relacyjnym dane i procedury są rozdzielone i ogólnie dostępne), - agregacja (możliwość zagnieżdżania obiektów o dowolnej strukturze w innych obiektach; w klasycznym modelu relacyjnym atrybuty są nierozkładalne i nie mają wewnętrznej struktury), - dziedziczenie (zdolność przejmowania właściwości, takich jak atrybuty i zachowanie, od klas zdefiniowanych na wyższym poziomie abstrakcji; w modelu relacyjnym nieobecne), - rozszerzalność (swoboda definiowania nowych typów danych, stosownie do potrzeb aplikacji; w modelu relacyjnym zestaw typów danych jest zdefiniowany z góry i nie można go modyfikować), - wersjowanie (możliwość utrzymywania wielu wersji tego samego obiektu; jest to uogólnienie mechanizmów historycznych, czyli zależnych od czasu, baz danych).

6 Tradycyjne funkcje zarządzania bazami danych (OODBMS)
Trwałość obiektów i zarządzanie pamięcią zewnętrzną, Interakcyjne języki zapytań (zapytań typy ad hoc), Przetwarzanie transakcyjne, Realizacja współbieżnego dostępu do danych, Kontrola ograniczeń integralnościowych, Odtwarzanie po awariach, Ochrona danych i autoryzacja operacji, Narzędzia wspomagające tworzenie aplikacji.

7 Nowe funkcje obiektowych baz danych
Obsługa transakcji długotrwałych i zagnieżdżonych, Zupełność obliczeniowa języka manipulowania danymi, w praktyce oznaczająca możliwość dokonywania takich obliczeń, jak w proceduralnych językach programowania (co jest znacznym rozszerzeniem w stosunku do standardowego dla baz relacyjnych języka SQL), Zarządzanie wersjami obiektów i schematów baz danych, Zarządzanie wielkimi obiektami o dowolnej strukturze, takimi jak obiekty multimedialne, Szeroki zakres modyfikacji schematu bazy danych.

8 Przykład Prosta baza danych ma za zadanie przechowywanie informacji o powiązaniach rodzinnych. Dla każdego ojca interesuje nas: jego identyfikator PESEL, imię i nazwisko oraz zbiór jego dzieci. Dla każdego dziecka chcemy przechowywać imię i datę urodzenia. Definicja schematu takiej bazy danych podana zostanie w trzech wersjach: wersji obiektowej (język OQL systemu O2), w klasycznej wersji relacyjnej (standardowy język SQL) oraz w rozszerzonej wersji relacyjnej (rozszerzona wersja języka SQL).

9 Przykład – model obiektowy
class Ojciec type tuple (pesel: string, imię: string, nazwisko: string, dzieci: set(Dziecko)) method podaj_opis_dzieci: set(string) end class Dziecko type tuple (imię: string, data_ur: Date) method wyświetl end;

10 Komentarz Schemat obiektowej bazy danych zawiera definicje dwóch klas: Ojciec i Dziecko. Każdy obiekt klasy Ojciec ma wymagane atrybuty pesel, imię i nazwisko oraz atrybut dzieci, którego wartością jest zbiór identyfikatorów obiektów będących dziećmi danego ojca. Dla dziecka przechowujemy jedynie atrybuty podające jego imię i datę urodzenia. Atrybut dzieci klasy Ojciec w naturalny i logiczny sposób realizuje wiązanie pomiędzy ojcem a jego wszystkimi dziećmi. Wiązanie to ma charakter jednokierunkowy: przejście od ojca do zbioru jego dzieci jest bezpośrednie – wystarczy odczytać wartość atrybutu dzieci. Znalezienie odpowiedniego obiektu klasy Ojciec dla danego obiektu klasy Dziecko nie jest już tak proste: wymaga przeglądania wartości atrybutu dzieci wszystkich obiektów klasy Ojciec w celu odnalezienia poszukiwanego identyfikatora obiektu klasy Dziecko. Jeśli w konkretnej aplikacji zachodzi częsta potrzeba wykonywania takiej operacji, a liczba obiektów klasy Ojciec jest duża, sensowne może okazać się dodanie do definicji klasy Dziecko dodatkowego atrybutu, który implementuje wiązanie pomiędzy dzieckiem a jego ojcem w kierunku od dziecka do ojca. W ten sposób, za pomocą dwóch atrybutów w dwóch powiązanych ze sobą logicznie klasach zrealizowane zostanie wiązanie dwukierunkowe.

11 Komentarz - cd Zmieniona definicja klasy Dziecko, z dodanym atrybutem realizującym takie dwukierunkowe wiązanie jest następująca: class Dziecko type tuple (imię: string, data_ur: Date ojciec: Ojciec) method wyświetl end; Uwaga: W definicjach klas Ojciec i Dziecko, oprócz atrybutów zawierają również nagłówki dwóch metod (bezparametrowych), umożliwiające uzyskanie i wyświetlenie wybranych informacji o obiektach tych klas. Takie połączenie wartości i operacji w jednym elemencie aplikacji (w tym wypadku – w klasie), charakterystyczne dla obiektowego modelu danych, jest bardzo naturalne i zarazem wygodne dla użytkownika (klienta) klasy.

12 Przykład – model relacyjny
CREATE TABELE Ojcowie (pesel CHAR(11), imię CHAR(16), nazwisko CHAR(24); CREATE TABELE Dzieci imię CHAR(8), data_ur DATE, pes_ojca CHAR(11));

13 Komentarz – model relacyjny
Schemat relacyjnej bazy danych zawiera definicje dwóch relacji: Ojcowie i Dzieci. Relacja Ojcowie ma jedynie atrybuty pesel, imię i nazwisko. Atrybut pesel jest kluczem głównym tej relacji, gdyż jednoznacznie identyfikuje ojca (pojedynczą krotkę relacji). W relacji Dzieci, z uwagi na trudności w rozróżnianiu krotek wyłącznie na podstawie atrybutów oznaczających imię i datę urodzenia, również wprowadzono atrybut pesel, który w sposób jednoznaczny identyfikuje dziecko (krotkę relacji) i jest kluczem głównym tej relacji. Można założyć, że dopóki dziecku nie nadano urzędowo numeru PESEL, system automatycznie przypisze mu pewien jednoznaczny numer z zarezerwowanej do tego celu puli numerów (taka praktyka „numerowania” krotek relacji jest bardzo pożyteczna w przypadku, gdy trudno określić klucz główny lub gdy klucz główny składa się z wielu atrybutów). Związek między ojcami a dziećmi jest reprezentowany w relacji Dzieci dodatkowym atrybutem pes_ojca. Atrybut ten pełni rolę klucza obcego, co oznacza, że wartości tego atrybutu muszą być równe wartościom klucza głównego innej relacji (w tym wypadku relacji Ojcowie). Wiązanie między dzieckiem a jego ojcem ma w tym schemacie charakter jednokierunkowy, przy czym jego kierunek nie może zostać w prosty sposób zmieniony (tak jak to miało miejsce w obiektowej wersji schematu tej bazy danych). Istotnie, wymóg zachowania pierwszej postaci normalnej nie pozwala na dodanie do schematu relacji Ojcowie atrybutu wielowartościowego reprezentującego zbiór dzieci danego ojca (w tym wypadku byłby to zbiór wartości klucza głównego relacji Dzieci). Dodanie wielu atrybutów prostych, po jednym na każde dziecko, jest również niemożliwe, gdyż liczba atrybutów w każdej krotce relacji musi być z góry ustalona i jednakowa.

14 Komentarz – model relacyjny
Z uwagi na jednokierunkowy charakter wiązania dziecko-ojciec, jedynie operacja znalezienia ojca dla danego dziecka może być realizowana bezpośrednio: wystarczy w tym celu odczytać wartość atrybutu pes_ojca dla danej krotki relacji Dzieci. Symetryczna do niej operacja znalezienia zbioru dzieci dla konkretnego ojca (czyli dla danej krotki relacji Ojcowie) wymaga przejrzenia wszystkich krotek relacji Dzieci w poszukiwaniu tych wartości atrybutu pes_ojca, które są równe wartości klucza głównego danej krotki relacji Ojcowie. Jeśli taka operacja wykonywana jest często, a relacja Dzieci zawiera dużą liczbę krotek, może okazać się konieczne zastosowanie pomocniczych struktur zwanych indeksami, które pozwalają na efektywną implementcję poszukiwania w danej relacji krotek o zadanej wartości wybranego atrybutu. Standard języka SQL obejmuje instrukcje pozwalające projektantom baz danych tworzyć indeksy, stosownie do potrzeb danej aplikacji. W omawianym przykładzie, taki indeks posłużyłby do realizacji (wielowartościowego) odwzorowania każdej z wartości klucza głównego relacji Ojcowie w zbiór odpowiadających jej wartości klucza głównego relacji Dzieci. Indeks taki posłużyłby do implementacji drugiego kierunku związku pomiędzy ojcami a dziećmi.

15 Komentarz – model relacyjny
Standard języka SQL nie daje środków wspomagających zachowanie podstawowych własności kluczy głównych i kluczy obcych. Od wartości klucza głównego relacji wymaga się, by były jednoznaczne i niepuste. Od wartości klucza obcego w konkretnej krotce wymaga się, by była albo pusta albo równa wartości klucza głównego w pewnej krotce relacji z nią powiązanej. Aby wspomóc użytkownika w zachowaniu tego typu ograniczeń integralnościowych, producenci wprowadzają różne rozszerzenia do części języka SQL zwanej językiem definiowania danych (Data Definition Language). Poniżej zamieszczono poprzedni schemat relacyjnej bazy danych z uwzględnieniem możliwości, jakie daje język SQL z rozszerzeniami wprowadzonymi przez firmę Informix. Atrybuty pełniące rolę kluczy głównych opatrzono frazą PRIMARY KEY. Atrybut pełniący rolę klucza obcego opatrzono frazą REFERENCES –daje to możliwość kontroli powiązań pomiędzy krotkami obu relacji. CREATE TABELE Ojcowie (pesel CHAR(11) PRIMARY KEY, imię CHAR(16), nazwisko CHAR(24); CREATE TABELE Dzieci imię CHAR(8), data_ur DATE, pes_ojca CHAR(11) REFERENCES);

16 Komentarz – model relacyjny
W schematach relacji Ojcowie i Dzieci nie ma możliwości zawarcia definicji operacji, które mogą być wykonywane na poszczególnych krotkach. Schemat relacyjnej bazy danych zawiera jedynie opis danych, bez opisu zachowania się (funkcji) elementów przechowywanych w bazie. Jednak współczesne systemy RDBMS dopuszczają możliwość przechowywania w bazie danych nie tylko danych statystycznych, ale także procedur (stored procedure), choć wiązanie ich z danymi musi być nadal realizowane jawnie przez program aplikacyjny.

17 Komentarz – rozszerzony model relacyjny
TYPE Dziecko = ROW (imię CHAR(16), data_ur DATE); CREATE TABELE Ojcowie (pesel CHAR(11), imię CHAR(16), nazwisko CHAR(24), dzieci SET(Dziecko));

18 Komentarz – rozszerzony model relacyjny
Schemat relacyjnej bazy danych ograniczono tu do jednej relacji Ojcowie, przy czym w porównaniu z odpowiadającą jej relacją z klasycznego modelu relacyjnego dodany został atrybut wielowartościowy dzieci, reprezentujący zbiór dzieci danego ojca. Zastosowano tu charakterystyczną dla rozszerzonych systemów relacyjnych możliwość zagnieżdżania jednych krotek w innych (a więc odejścia od pierwszej postaci normalnej). W tym celu zdefiniowano typ wierszowy Dziecko, definiujący strukturę krotek zawierających dane dotyczące dzieci. Odpowiednie krotki z tymi danymi, będące konkretnymi wystąpieniami typu Dziecko, zagnieżdżane są w stosownej krotce relacji Ojcowie. Rozwiązanie to jest podobne do rozwiązania zastosowanego w modelu obiektowym; jednak występują tu pewne zasadnicze różnice. W modelu obiektowym zdefiniowano oddzielną klasę Dziecko, co powoduje, że obiekty tej klasy mają swoją tożsamość (atrybut dzieci klasy Ojciec zawiera zbiór identyfikatorów obiektów będących dziećmi danego ojca, a nie zbiór wartości tych obiektów). Natomiast w rozszerzonym modelu relacyjnym atrybut dzieci relacji Ojcowie zawiera zbiór wartości atrybutów opisujących dzieci danego ojca. Związek między dziećmi a ojcami został tu zrealizowany w postaci jawnego zagnieżdżenia wartości jednej encji w innej encji, przy czym encja zagnieżdżona utraciła przy tym swoją tożsamość (nie ma swojego klucza głównego, a więc nie może być odróżniona od innych). Rozwiązanie to można zmodyfikować na kilka sposobów. Jedną z możliwości jest dodanie do definicji typu Dziecko atrybutu kluczowego pesel (analogicznie do modelu relacyjnego, bez zmiany schematu relacji Ojcowie. Wówczas pozostaje implementacja związku przez zagnieżdżenie, jednak encja zagnieżdżona nie traci swojej tożsamości (rozumianej jako możliwość odróżnienia jej od innej encji tego samego typu). Drugą możliwością jest zdefiniowanie oddzielnej relacji Dzieci, zawierającej dane opisujące dzieci, podobnie jak to uczyniono w modelu relacyjnym. Taki schemat przejmuje z modelu obiektowego możliwość stosowania atrybutów wielowartościowych (co np. umożliwia naturalną implementację związków dwukierunkowych bez względu na krotność), a z modelu relacyjnego realizację związków pomiędzy relacjami za pomocą kluczy obcych.

19 Komentarz – rozszerzony model relacyjny
CREATE TABELE Ojcowie (pesel CHAR(11), imię CHAR(16), nazwisko CHAR(24), dzieci SET(CHAR(11)); CREATE TABELE Dzieci imię CHAR(8), data_ur DATE, pes_ojca CHAR(11)); W rozszerzonych systemach relacyjnych wprowadza się pewne możliwości bezpośredniego wiązania danych z operacjami.

20 Decyzje projektowe Problemy jakie występują, gdy model klas projektowanego systemu chce się przełożyć na projekt bazy danych dotyczą zwykle decyzji projektowych lub czysto implementacyjnych. Podjąć je należy w momencie przekładania modelu na projekt, ukierunkowany na określone środowisko implementacyjne. Charakter tych decyzji zależy w dużej mierze od modelu danych przyjętego w systemie baz danych w którym projektowana baza danych będzie implementowana (decyzje odnośnie sposobu implementacji związków między obiektami czy kwestie zagnieżdżania danych).

21 Implementacja związków
Zależności pomiędzy klasami (zw. też związkami), występujące w modelu klas, nie mają z góry określonej kierunkowości (z punktu widzenia logiki modelu są dwukierunkowe). W projekcie bazy danych trzeba zdecydować się na ustalenie kierunku związku, a ściślej – na sprecyzowanie kierunku połączenia (zw. wiązaniem), istniejącego pomiędzy dwoma obiektami powiązanych ze sobą klas. Z uwagi na możliwość definiowania w strukturze obiektu atrybutów wielowartościowych, dowolny związek binarny można implementować w postaci związku jednokierunkowego (w dowolnym kierunku) albo w postaci związku dwukierunkowego. Niezależnie od krotności związku nie musimy do jego implementacji używać żadnych oddzielnych struktur – wystarczy dodanie odpowiedniego atrybutu do definicji klas. Tak uczyniono w schemacie obiektowym (atrybut dzieci klasy Ojciec i atrybut ojciec zmodyfikowanej klasy Dziecko) oraz w rozszerzonym schemacie relacyjnym w jego drugiej wersji (atrybut dzieci relacji Ojcowie i atrybut pes_ojca relacji Dzieci). Implementacja związku w postaci dwukierunkowej nakłada dodatkowe ograniczenia integralnościowe związane z aktualizacją wiązań. Ograniczenia te polegają na tym, że: - aktualizacja atrybutu reprezentującego wiązanie w jednym obiekcie musi pociągać za sobą aktualizację odpowiedniego atrybutu w obiekcie z nim powiązanym, aktualizacja obu atrybutów musi być wykonana w ramach jednej transakcji (musi być operacją atomową). Uwaga: jeśli którykolwiek z powyższych warunków nie będzie zachowany, wiązanie utraci charakter dwukierunkowości.

22 Implementacja związków - cd
W modelu obiektowej bazy danych może być również uzasadnione reprezentowanie związku przez specjalnie w tym celu wprowadzoną klasę. Metodę tę należy stosować wówczas, gdy stopień związku jest wyższy niż dwa (tzn. liczba związanych ze sobą klas jest większa niż dwa), a także wtedy, gdy z semantyki modelu wynika, że ze związkiem skojarzone są konkretne atrybuty, które nie są atrybutami klas pozostających w tym związku. Występuje tu pełna zgodność z metodą postępowania stosowaną podczas analizy obiektowej (związki posiadające własne atrybuty stają się klasami).

23 Przykład Mamy klasę Mężczyzna i Kobieta, powiązane ze sobą związkiem Małżeństwo. Pomiędzy dwoma obiektami z tych klas wiązanie istnieje wtedy, gdy dwie osoby reprezentowane przez te obiekty pozostają ze sobą w związku małżeńskim. Najlogiczniejszym miejscem dla atrybutu oznaczającego datę zawarcie związku małżeńskiego jest opis samego związku. Z każdym związkiem wiążemy wówczas jedną wartość (datę). W momencie tworzenia wiązania (czyli w chwili zawarcia związku małżeńskiego) tworzymy nowy obiekt reprezentujący to wiązanie i nadajemy wartość jego atrybutom (dacie). W zależności od tego, czy decydujemy się na wiązanie jedno- czy dwukierunkowe, dodatkowo może zajść potrzeba zapisania w odpowiednich obiektach klasy Mężczyzna i klasy Kobieta wskazań na nowo utworzony obiekt klasy Małżeństwo. Gdybyśmy atrybut oznaczający datę umieścili w obu powiązanych ze sobą klasach, pojawiłyby się problemy wielu kopii tej samej informacji oraz typowe problemy integralnościowe przy aktualizacjach. Umieszczenie tego atrybutu w tylko jednej z tych klas powodowałoby niejednakowe traktowanie tych klas, a tym samym zachwianie logicznej spójności modelu.

24 Przykład – fragment schematu
Poniżej przedstawiono fragment schematu obiektowej bazy danych, w którym związek Małżeństwo zaimplementowano jako klasę. W schemacie tym zastosowano wiązania jednokierunkowe pomiędzy obiektami klasy Małżeństwo a odpowiadającymi im obiektami klasy Mężczyzna i klasy Kobieta. Uwaga: Dla prostoty pominięto szereg atrybutów i metod, które mogłyby być istotne w danej bazie danych, a także możliwość zastosowania uogólnienia, które mogłoby tu polegać na wydzieleniu wspólnych atrybutów klas Mężczyzna i Kobieta (np. nazwisko i imię, adres) do wspólnej nadklasy. class Mężczyzna type tuple (nazwisko: string, imię: string, …) end; class Kobieta class Małżeństwo type tuple (data: Date, mąż: Mężczyzna, żona: Kobieta)

25 Osadzanie obiektów Osadzanie obiektów w innych obiektach może być uzasadnione ze względu na efektywność. Dostęp do wartości obiektu osadzonego z poziomu obiektu złożonego jest bezpośredni – polega jedynie na odczytaniu wartości atrybutu (lub atrybutów). W wypadku przechowywania obiektów w bazach danych należy się spodziewać, że wartości atrybutów jednego obiektu położone są fizycznie blisko siebie, prawdopodobnie na jednej stronie dyskowej lub – jeśli obiekt ma duży rozmiar – na niewielu sąsiadujących ze sobą stronach. W związku z tym wartości te pobierane są do pamięci operacyjnej bardzo efektywnie, zwykle w ramach jednej transmisji dyskowej. Jeśli związany obiekt nie jest osadzony, a jedynie zagniżdżony (tzn. w obiekcie złożonym istnieje jawne odwołanie do obiektu składowego, poprzez jego identyfikator), wówczas dostęp do obiektu składowego wymaga z reguły przynajmniej jeszcze jednego, dodatkowego dostępu do dysku. W projekcie schematu obiektowej bazy danych możliwy jest również proces odwrotny do osadzania, polegający na wydzieleniu pewnej części wartości obiektu i potraktowaniu jej jako samodzielnego, „pełnoprawnego” obiektu. Może to być celowe, gdy zdarza się, że liczne obiekty tej samej klasy mają tę samą wartość pewnych atrybutów.

26 Przykład – fragment bazy o osobach
Baza danych zawiera m.in. Informacje adresowe. Definicja klasy Osoba w takiej bazie może wyglądać następująco: class Osoba type tuple (nazwisko: string, imię: string, adr_miasto: string, adr_kod: string, adr_ulica: string, adr_nr_ul: integer) end;

27 Komentarz Jeśli szereg osób mieszka pod tym samym adresem, wartości wszystkich atrybutów o nazwach rozpoczynających się od adr_ będą się powtarzać. Rozszerzymy schemat naszej bazy danych o klasę Adres, której wystąpieniami są adresy, pod którymi mogą mieszkać osoby oraz zmodyfikujemy odpowiednio definicję klasy Osoba. W efekcie uzyskamy następujący schemat: class Osoba type tuple (nazwisko: string, imię: string, adres: Adres) end; class Adres type tuple (miasto: string, kod: string, ulica: string, nr_ul: integer)

28 Obiekty z osadzonymi identycznymi adresami – graf kompozycji
nazwisko imię adres Nowak Jan Kłos Jerzy miasto kod ulica nr_ul Olsztyn 10-900 Wąska 12 nr_ul Różnice w zawartościach obu baz zobrazowano w grafach kompozycji dwóch obiektów O1 i O2 klasy Osoba, o identyfikatorach odpowiednio O1 i O2 mieszkających pod tym samym adresem. Na rysunku przedstawiono wariant w którym adres jest wartością.

29 Obiekty z osadzonymi identycznymi adresami – graf kompozycji
Obiekty z identycznym adresem, reprezentowanym jako obiekt id1 id2 nazwisko imię adres imię adres nazwisko Nowak Jan id3 Jerzy Kłos miasto kod ulica nr_ul Olsztyn 10-900 Wąska 12 Zaprezentowane tu wydzielenie części wartości obiektu jako oddzielnego obiektu w praktyce może mieć głębsze znaczenie niż tylko ukierunkowane implementacyjnie zmniejszenie zajętości pamięci. Jeśli wydzielona struktura jest złożona, może okazać się pożyteczne przypisanie do niej stosownych metod, np. służących do jej prezentacji lub zmiany wartości. Takie postępowanie sprzyja polepszeniu modularności i elastyczności systemu i jest zgodne z duchem obiektowości

30 Trwałość obiektów Jednym z najważniejszych wymogów stawianych bazom danych jest cecha trwałości (persistence), polegająca na tym, że dane utworzone przez program mogą istnieć dłużej niż okres aktywności tego programu. To jak długo mogą istnieć dane, zależy wyłącznie od ich właściciela (zazwyczaj jest nim użytkownik, który je utworzył). Podejście obiektowe w zastosowaniu do baz danych wpływa w istotny sposób na interpretację cechy trwałości elementów aplikacji, w tym wypadku – trwałości obiektów. Jednym z istotnych postulatów obiektowego modelu danych jest jednorodność, przejawiająca się w różnych aspektach, także w aspekcie jednakowego traktowania obiektów trwałych (przechowywanych w bazie danych) i obiektów nietrwałych (programowych). Takie jednakowe traktowanie przejawia się w tym, że operacje wykonywane na obiektach nie zależą od cech trwałości obiektów. Jest to dodatkowy i bardzo pożyteczny w praktyce aspekt niezależności programu od danych (data independence).

31 Trwałość obiektów - wymagania
Istotne wymagania odnośnie cechy trwałości obiektów to: - ortogonalność – trwałość obiektu nie zależy od klasy, do której należy dany obiekt; innymi słowy, każdy obiekt, niezależnie od jego klasy, może być uczyniony obiektem trwałym lub obiektem nietrwałym; - przezroczystość – obiekty trwałe i obiekty nietrwałe mogą być traktowane w programie w ten sam sposób; innymi słowy, z punktu widzenia programu aplikacyjnego, nie ma różnicy w dostępie do danych rezydujących w pamięci operacyjnej i do danych przechowywanych w pamięci dyskowej. Wszystkie „prawdziwe” systemy obiektowe spełniają postulat przezroczystości (transparency). Spełnienie postulatu ortogonalności zależy natomiast od konkretnego systemu.

32 Przykład Schemat osobowej bazy danych rozszerzono o definicję klasy kontenerowej o nazwie ZbiórOsób. W tym schemacie zdefiniowano również obiekt nazwany TenZbiórOsób, będący wystąpieniem klasy ZbiórOsób. Ponieważ obiekt TenZbiórOsób po utworzeniu go w klasie ZbiórOsób i przypisaniu mu nazwy staje się obiektem trwałym, każdy obiekt klasy Osoba umieszczony w zbiorze będącym atrybutem zbiór obiektu TenZbiórOsób staje się też obiektem trwałym. Również każdy obiekt klasy Adres, do którego odwołuje się dowolny obiekt trwały klasy Osoba, jest obiektem trwałym. Pozostałe obiekty klas Osoba i Adres są nietrwałe. class ZbiórOsób type tuple (zbiór: set(Osoba), licznik: integer, method dodaj_osobę (osoba: Osoba), … end; class Osoba type tuple (nazwisko: string, imię: string, adres: Adres) class Adres type tuple (miasto: string, kod: string, ulica: string, nr_ul: integer) Name TenZbiórOsób: ZbiórOsób;

33 Baza danych - Armatorzy
System komputerowy (Armatorzy) ma zarządzać danymi o firmach eksploatujących statki. Każda firma może mieć kilka siedzib (filii), przy czym siedziby jednej z nich są uporządkowane według pewnego kryterium ważności (nie jest one dla nas ważne). Każda siedziba ma swoją nazwę. W jednej siedzibie może mieścić się wiele firm. Dla każdej firmy chcemy znać: nazwę, rok założenia, liczbę zatrudnionych, a także wiedzieć, gdzie ma swoje siedziby i jakie statki eksploatuje. Każdy statek eksploatowany przez firmę ma nazwę i wyporność. Wśród statków wyróżniamy promy i żaglowce. Każdy prom, oprócz atrybutów właściwych dla każdego statku, ma określoną trasę kursowania. Dla każdego żaglowca, oprócz atrybutów właściwych dla każdego statku, interesuje nas dodatkowo powierzchnia żagli i typ żaglowca. Każdy statek eksploatowany jest przez jednego armatora (firmę). Każdy został zwodowany w określonej stoczni. Dla każdej stoczni interesuje nas: lokalizacja, określona przez miasto i państwo, pewien parametr ekonomiczny (średni zysk ze sprzedaży jednego statku, w procentach) oraz to jakie statki (spośród tych, które są eksploatowane przez firmy) w niej zwodowano.

34 Diagram klas dla systemu Armatorzy
Na diagramie zaznaczono jedynie te atrybuty, które zostały jawnie wymienione w sformułowaniu problemu. W trakcie głębszej analizy pojawiłaby się konieczność zawarcia w modelu innych atrybutów, a także operacji, które dla uproszczenia zostały pominięte.

35 Schemat obiektowej bazy danych Armatorzy
Na schemat każdej obiektowej bazy danych składają się dwie hierarchie: hierarchia dziedziczenia, reprezentująca związek nadklasa- podklasa oraz hierarchia kompozycji, reprezentująca związek atrybut-dziedzina. W ogólności hierarchię dziedziczenia w obiektowej bazie danych można przedstawić w postaci skierowanego grafu acyklicznego, natomiast hierarchię kompozycji w postaci dowolnego grafu skierowanego. Węzłami w obu hierarchiach są te same klasy. Na diagramie strzałki ciągłe oznaczają związek nadklasa-podklasa (są więc krawędziami w hierarchii dziedziczenia), natomiast strzałki przerywane oznaczają związek atrybutu-dziedzina (są krawędziami w hierarchii kompozycji). Znak * obok nazwy atrybutu oznacza, że jest to atrybut wielowartościowy, czyli taki, którego wartością jest zbiór (jak atrybut statki klasy Firma) lub lista (jak atrybut siedziby klasy Firma).

36 Przykład - Armatorzy Niżej zapisano ten schemat w języku definiowania schematów systemu O2. zgodnie z konwencją przyjęto w tym języku, dziedziny atrybutów pisane małą literą są dziedzinami prymitywnymi (czyli takimi, których elementy są wartościami atomowymi), natomiast dziedziny pisaną dużą literą oznaczają klasy (elementami tych dziedzin są identyfikatory obiektów odpowiednich klas). Klasy Prom i Żaglowiec mają również atrybuty producent i wyporność, choć nie występują one jawnie w opisach tych klas. Atrybuty te są dziedziczone przez te klasy z klasy Statek, co zapewnia fraza inherit występująca w definicjach klas Prom i Żaglowiec. Aby zapewnić trwałość obiektów z bazy Armatorzy, do schematu tej bazy dodano nazwę ZbiórFirm, która będzie pełniła rolę korzenia trwałości i w trakcie tworzenia bazy danych zostanie przypisana do pustego zbioru obiektów klasa Firma.

37 Przykład - Armatorzy class Firma type tuple (nazwa: string,
rok_założenia: integer, statki: set(Statek), zatrudnia: integer, siedziby: list(string)) end; class Statek producent: Stocznia, wyporność: integer) class Stocznia type tuple (miasto: string, państwo: string, zysk_jednostkowy: integer) class Prom inherit Statek type tuple (trasa: string) class Żaglowiec inherit Statek type tuple (powierzchnia_żagli: integer, typ: string) name ZbiórFirm: set(Firma);