70926 ullman021 (2)

ł Kf 2 MOOF.I/)WAMn BAZ DANYCH

Podstawowym celem języka ODL jest dostarczenie mechanizmów do takiego zapisu zorientowanych obiektowo projektów baz danych, który może być przetłumaczony bezpośrednio na deklaracje w zorientowanych obiektowo systemach zarządzania bazami danych (OODBMS). Głównymi językami w takich systemach si| albo C-H-, albo Srnalltalk. język ODL musi więc być tłumaczony na deklaracje jednego z nich. Ponieważ język ODL przy pomina oba (ale C++ bardziej), zatem tłumaczenie, zilustrowane na rys. 2.3, jest całkiem proste. Tłumaczenie / języka 01)1. lub diagramu związków cncji na deklarację dopasowaną do bardziej popularnych relacyjnych systemów zarządzania bazami danych jest w porównaniu z poprzednim dużo bardziej złożone.

Schematy i dane

Język ODL jest przeznaczony do specyfi kowani a schematu lub struktury bazy danych. Nie ma w nim ani mechanizmów służących do określania bieżącej zawartości bazy danych, ani do zapisywania zapytań lub innych operacji na danych. Jak już wspomnieliśmy w podrozdziale 1.1. języki opisu schematu, takie jak język ODL, określa się często mianem języków definiowania danych, podczas gdy języki, umożliwiające określanie bieżącej zawartości bazy danych lub zapisywanie zapytań i innych operacji no danych, są nazywane analogicznie językami operowania danymi. Nie będziemy omawiać na razie języków oporowania danymi, aż do miejsca w rozdziale 4. gdzie ujrzymy bazę danych / punktu widzenia jej użytkownika. Języki definiowania danych są natomiast kluczowe w poznawaniu baz danych z punktu widzenia ich projektanta.

2.1.1. Projektowanie zorientowane obiektowo

W myśl zasad projektowania zorientowanego obiektowo św iat jest złożony z obiektów, czyli pew nego rodzaju możliwych do zaobserwowania bytów. \a przykład można myśleć o ludziach jako o obiektach, a także o kontach bankowych, rejsach samolotów, wykładach w szkołach wyższych, o budynkach itd. Zakłada się, żc każdy obiekt ma unikalny identyfikator (objęci identyfily - OlD), który odróżnia go od innych obiektów, wspominaliśmy już o tym w p. 1.3.1.

Zazwyczaj ze względu na porządkowanie danych chcemy pogrupować obiekty o podobnych cechach w klasy. Pojęcia: „obiekt” i „klasa” oznaczają w bazach danych to samo co w językach zorientowanych obiektowo C++ i Srnalltalk (tutaj znowu powołamy się na treść p. 1.3.1). Kiedy jednak rozważani) zorientowane obiektowo projektowanie w języku ODL, „podobieństwo cech” obiektów' w- klasach powinniśmy rozważać na dwa sposoby:

• Pojęcia ze świata rzeczywistego, reprezentow ane przez obiekty jednej klasy, powinny być podobne. Na przykład ma sens pogrupowanie

wszystkich klientów banku w jedną klasę, a kont w inną. Natomiast nic ma sensu tworzenie jednej klasy do reprezentowania i kont i klientów, ponieważ nic mają one ze sobą nic, albo prawie nic, wspólnego, a poza tym odgrywają zupełnie inną rolę w bankowości.

• Obiekty danej klasy muszą mieć ten sam zestaw cech. Programując w językach zorientowanych obiektowo, często rozumiemy obiekty tak samo jak rekordy, co można wywnioskować z rys. 2.3. Obiekty mają pola lub gniazdka, w których umieszcza się wartości. Te wartości mogą być zwykłych typów, na przykład całkowitego, tekstowego lub macierzowego, albo mogą być odniesieniem (referencją) do innego obiektu. Mogą także być metodą, t/n. funkcją, która operuje na sa mym obiekcie. Ale w naszych rozważaniach dotyczących języka ODL nie będziemy wyróżniać tych metod, z których korzysta się podobnie jak w innych językach zorientowanych obiektowo. Powrócimy do tego tematu w podrozdziale 8.1.

do obiektu Klient

Konto

RYSUNEK 2.3

Obiekt reprezentujący konto

Istota identyfikatorów obiektu

Jak już wspomnieliśmy w p. 1.3.1. zorientowane obiektowo bazy danych są często tak wielkie, że liczba potrzebnych identyfikatorów OID znacznie przekracza zakres numerów w przestrzeni adresowej. Dlatego w zorientowanych obiektowo bazach danych zazwyczaj istnieje schemat budowania niepowtarzalnych napisów kojarzonych z poszczególnymi obiektami; często te napisy są długie, nawet do 16 bajtów. Na przy kład jako OID może wystąpić dokładny czas powołania obiektu do życia (mierzony w jednostkach na tyle małych, że na jednym komputerze nie mogą powstać dwa obiekty w jednym momencie) połączony /. nazwą komputera, na którym obiekt powstał (jeśli baza danych jest rozproszona na wielu maszynach).

Mimo że często projektowanie bywa łatwiejsze, gdy utożsamia się obiekt z rekordem, to jednak rozdział niniejszy jest poświęcony projektowaniu na poziomic abstrakcyjnym. Dlatego musimy przede wszystkim skupić się na bardziej abstrakcyjnym pojęciu klas i ich właściwości, bez wnikania w detale