klasy

BAZY DANYCH
model obiektowy
Opracował:
dr inż. Piotr Suchomski
Wprowadzenie
Relacyjny model danych jest zbyt płaski i
prosty do reprezentacji danych o bardziej
skomplikowanej i nieregularnej strukturze (p.
dane multimedialne).
 W teorii baz danych istnieją inne modele, za
pomocą których można lepiej odwzorować
rzeczywiste obiekty danych.
 Głównym, alternatywnym do relacyjnego
modelu danych jest model obiektowy.

Obiektowy model danych

Obiektowa koncepcja baz danych bazuje na
rozszerzonej koncepcji obiektowych języków
programowania takich jak C++ czy Java o
mechanizmy zapewniające trwałość danych.
 W czasie wykładu zostanie przedstawiony
„czysty” model obiektowy ODL – Object
Definition Language, zdefiniowany przez
organizację ODMG – Object Data Managment
Group)
Cechy obiektowości
Rozbudowany system typów,
 Pojęcie klasy, które są typami związanymi z
ekstensją lub zbiorem obiektów należących do
danej klasy. Klasa oprócz atrybutów, które mogą
być typami atomowymi lub złożonymi, może
zawierać metody, które są procedurami
stosowanymi do obiektów danej klasy.
 Tożsamość obiektu (jednoznaczny
identyfikator) niezależna od jego wartości.
 Dziedziczenie, które pozwala tworzyć
hierarchiczną organizację klas, w której klasy
niższe dziedziczą właściwości klasy wyższej.

System typów
Można korzystać z typów atomowych (liczby
całkowite, rzeczywiste, łańcuchy znaków, typy
logiczne itp.)
 Korzystając z tzw. konstruktorów typów można
tworzyć nowe typy:

System typów
Typ struktury służy do tworzenia typu rekordu.
Analogicznie jak „struktury” w języku C i C++
składają się z określonej liczby pół, a każde
pole jest określonego typu.
 Typ kolekcji – gdy jest dany jakiś typ T to za
pomocą różnych operatorów kolekcji można
utworzyć np. tablice, listy, zbiory (np. lista liczb
całkowitych, zbiór liczb naturalnych, tablica
rekordów itp.)
 Typ referencji – Referencją do typu T jest typ,
którego wartości jednoznacznie wskazują na
wartości typu T (wskaźniki).

Identyfikacja obiektu
W modelu obiektowym zakłada się, że każdy
obiekt posiada dokładnie jeden, niepowtarzalny
identyfikator (OID – object identity).
 W modelu obiektowym mogą istnieć dwa
obiekty o takich samych wartościach ale
różnych identfikatorach.

Metody i hermetyzacja
Klasa może, ale nie musi, posiadać
funkcje/metody pozwalające przetwarzać dane
obiektów danej klasy.
 Dzięki metodom możliwa jest realizacja
hermetyzacji (encapsulate). Ograniczony jest
dostęp bezpośredni do danych obiektów.
Wszystkie operacje na danych wykonywane są
wyłącznie za pomoca metod. Takie rozwiązanie
pozwala zabezpieczyć obiekty danych przed
modyfikacjami jakich nie przewidział projektan
bazy. Hermetyzacja jest jedną z podstaw
tworzenia niezawodnego oprogramowania.

Hierarchia klas - dziedziczenie
Pewna klasa C może być podklasą klasy D.
 Podklasa C dziedziczy wszystkie własności
oraz metody klasy D włącznie z jej typem.
 W klasie C mogą być zdefiniowane dodatkowe
własności oraz metody lub metody klasy C
mogą zastępować metody klasy D.

Jezyk ODL
Język ODL jest standardowym językiem do
specyfikowania struktury bazy danych w
terminologii obiektowej.
 Stanowi on rozszerzenie języka IDL (Interface
Description Language), który jest składnikiem
standardu CORBA (Common Object Request
Broker Architecture) – znany standard
obiektowego przetwarzania rozproszonego.

Projekt klas w ODL

W skład projektu klas w języku ODL wchodzą 3
składniki:
– Atrybuty – wartości związane z obiektami danej klasy,
– Związki – opisują powiązanie danego obiektu z
obiektami innych klas,
– Metody – funkcje, które pozwalają przetwarzać dane
obiektów danej klasy.

Atrybuty, związki i metody tworzą własności
klasy.
Atrybuty

W modelu obiektowym atrybuty nie muszą być
typu atomowego.
Class Film{
attribute string tytul;
attribute integer rok_prod;
attribute integer czas_trwania;
attribute enum dźwięk{mono, stereo, DD, SDDS}
standardDzwieku;
};
Class Aktor{
attribute string nazwisko;
attribute Struct Adr{miasto, ulica, nr_domu}
adres;
};
Typy w języku ODL
Typy atomowe – typy całkowite,
zmiennoprzecinkowe, łańcuchy znaków,
logiczne, wyliczeniowe.
 Nazwy klas,
 Typy strukturalne powstają z typów bazowych za
pomocą tzw. konstruktorów typów (tzw. typy
kolekcji):

– Zbiór – Jeżeli T jest nazwą jakiegoś typu, to Set<T>
oznacza typ, którego wartość są dowolnymi
skończonymi zbiorami elementów typu T. W zbiorze
każdy element występuje tylko raz.
Typy w języku ODL
– Wielozbiór - Jeżeli T jest nazwą jakiegoś typu, to
Bag<T> oznacza typ, którego wartości są dowolnymi
skończonymi zbiorami z powtórzeniami. W
wielozbiorze element może występować wielokrotnie.
– Lista - Jeżeli T jest nazwą jakiegoś typu, to L1st<T>
oznacza typ, którego wartości są dowolnymi
skończonymi listami zero lub więcej elementów typu
T. Szczególny przypadek stanowi typ strlng, który jest
skrótowym zapisem typu List<char>. W liście ważny
jest porządek elementów np. {3,5,3} i {3,3,5} to takie
same wielozbiory, ale różne listy.
– Tablica - Jeśli T jest nazwą typu oraz i jest nazwą
typu integer, to Array<T, i> oznacza typ, którego
elementami są tablice i elementów typu T.
Typy w języku ODL
– Słownik - jeśli T i S są typami, to Dictionary<T,S>
oznacza typ, którego wartościami są skończone
zbiory par. Każda para składa się z wartości klucza
typu T oraz wartości zakresu typu S. W słowniku nie
mogą wystąpić dwie pary z taką samą wartością
klucza. Z założenia metoda implementacji słownika
jest efektywna w sensie wyszukiwania wartości z
zakresu typu S na podstawie określonej wartości t
klucza typu T.
– Struktura – (analogicznie jak w języku C i C++)
posiada pola, które mogą być również złożonego
typu.
Związki

Związki pozwalają określić powiązania z innymi
obiektami tej klasy lub innej klasy.
Class Film{
attribute string tytul;
attribute integer rok_prod;
attribute integer czas_trwania;
attribute enum dźwięk{mono, stereo, DD, SDDS}
standardDzwieku;
relationship Set<Aktor> aktorzy;
};

W każdym obiekcie typu Film istnieje zbiór
referencji do obiektów klasy Aktor.
Związki odwrotne
Bardzo często istnieje potrzeba wyrażenia tego,
że istnieje związek odwrotny do
zadeklarowanego związku (np. w danym filmie
występują różni aktorzy, ale każdy aktor może
występować w różnych filmach).
 Jeżeli związek R w klasie C wiąże obiekt x
klasy C ze zbiorem jednego lub więcej obiektów
y1, y2, … ,yn klasy D, to związek odwrotny do R
wiąże z każdym z obiektów yi obiekt x.

Związki odwrotne
Class Film{
attribute string tytul;
attribute integer rok_prod;
attribute integer czas_trwania;
attribute enum dźwięk{mono, stereo, DD, SDDS}
standardDzwieku;
relationship Set<Aktor> obsada
inverse Aktor::zagrałW;
};
Class Aktor{
attribute string nazwisko;
attribute Struct Adr{miasto, ulica, nr_domu}
adres;
relationship Set<Film> zagrałW
inverse Film::obsada;
Krotność związków





Analogicznie jak w przypadku związków E/R
para związków odwrotnych może być wiele do
wiele, wiele do jeden, jeden do wiele i jeden do
jeden.
m:n między klasami C i D typem związku w
klasie C jest Set<D>, a w klasie D typem
związku jest Set<C>;
n:1 z klasy C do D typem związku w C jest D, a
w klasie D typem związku jest Set<C>;
1:n (odwrotnie niż w punkcie poprzednim);
1:1 typem związku w C jest D, a w D jest C.
Związki wieloargumentowe
ODL wspiera tylko związki binarne.
 Związki wieloargumentowe należy zamienić na
wiele związków binarnych.

Metody





Metody stanowią fragment kodu wykonywalnego
na obiektach danej klasy.
W ODL można zadeklarować nazwy metod
związanych z daną klasą oraz typy wejść/wyjść
(sygnatury).
Kod funkcji nie jest elementem języka ODL. Kod
metody zapisywany jest w języku podstawowym.
Deklaracja metod występuje w deklaracji klasy
razem z atrybutami i związkami.
Tak jak w językach programowania metoda jest
związana z daną klasą i działa na obiektach tej
klasy
Metody - syntaktyka

Syntaktyka deklaracji jest zbliżona do języka C.
Dodatkowo rozszerzona została o dwa
elementy:
– Parametry metod określane są dyrektywami in, out
oraz inout. Wartości parametrów out i inout mogą być
zmieniane i dlatego są przekazywane przez
referencję, natomiast parametr in jest niezmienny i
jest przekazywany przez wartość. Ponadto (tak jak w
C) metoda może zwrócić wartość.
– W metodzie mogą pojawiać się tzw. wyjątki –
odpowiedzi na zdarzenia nietypowe, nie mieszczące
się w standardowym mechanizmie komunikacji przez
zwracane parametry. W ODL wyjątki oznaczane są
słowem kluczowym raises.
Metody
class Film{
attribute string tytul;
…
relationship Set<Aktor> obsada
inverse Aktor::zagrałW;
…
float DługośćWGodzinach() reises(brakDługości)
void PokażObsadę(out Set<string>);
void DorobekGwiazdy(in Aktor, out Set<Film>)
raises (brakTakiegoAktora)
}
Dziedziczenie - podklasy

W standardzie ODL dziedziczenie oznaczane
jest słowem kluczowym extends.
Class Animowany extends Film{
attribute enum AnimTyp{2D, 3D, poklatkowa}
typAnimacji;
relationship Set<Aktor> dubbing
inverse Aktor::udzieliłGłosu;
}

Każdy obiekt klasy Animowany posiada własności
klasy Film oraz dodatkowo własne właściwości
(atrybut i związek).
Dziedziczenie wielokrotne
Mimo, że w rzeczywistości mogą istnieć obiekty,
które posiadają cechy kilku klas, nie można w
technice obiektowej tworzyć obiektów, które
przynależą do kilku klas.
 Należy zdefiniować inną klasę, która będzie
dziedziczyć po kilku klasach.

Class KomediaAnimowana extends Komedia: Anmimowany;

W przypadku dziedziczenia mnogiego istnieje
potencjalny konflikt nazw własności, które w
różnych klasach nadrzędnych mogą nazywać
się tak samo. Potrzebny jest mechanizm, który
wskaże o jaką własność klasy bazowej chodzi.
Dziedziczenie mnogie - konflikty
Można unikać (bądź nieudostępnić)
mechanizmu dziedziczenia po wielu klasach.
 Opracowanie mechanizmu, który pozwoli
wskazać, z której klasy bazowej własność o
podanej nazwie ma być dziedziczona.
 Można tą własność w nowej klasie przejąć pod
inną, unikatową nazwą.

Ekstensje
Należy odróżnić definicję klasy od jej obiektów.
Sytuacja analogiczna do odróżnienia schematu
relacji od jej instancji.
 W standardzie ODL rozróżnienie to jest jawne –
klasie i obiektom nadaje się różne nazwy.
Nazwa klasy określa schemat klasy, a ekstensja
identyfikuje zbiór obiektów danej klasy.

Class Film (extent Filmy){
attribute string tytul;
…
};
Deklaracja kluczy w ODL

W technice obiektowej jednoznaczna
identyfikacja obiektu odbywa się na podstawie
jego identyfikatora, dlatego definiowanie kluczy
w tym modelu jest opcjonalne (niedopuszczalne
w modelu E/R i relacyjnym).
 Można zadeklarować jeden bądź kilka kluczy
używając słowa kluczowego key bądź keys.
Class Student
(extent Studenci keys (nazwisko, data_ur),
nr_indeksu){
…
};
Przejście do modelu relacyjnego
ODL może być stosowany do stworzenia
pierwotnego projektu bazy danych, który przed
implementacją jest przekształcany do postaci
relacyjnej.
 Konwersja ta przypomina pod wieloma względami
przejście od modelu E/R do schematu
relacyjnego. Mimo, że w modelu obiektowym
łatwiej i dokładniej można zamodelować
rzeczywistość to przekształcenie do modelu
relacyjnego – łatwiejszego w implementacji,
obarczone jest kilkoma problemami, które na
etapie tego przejścia trzeba rozwiązać.

Typowe problemy przekształcenia

W modelu relacyjnym wymagane jest
bezwzględnie określenie kluczy, które w modelu
obiektowym są opcjonalne. Często istnieje
konieczność definiowania dodatkowych
atrybutów, które mogą tworzyć klucze.
 W modelu relacyjnym atrybuty muszą być
atomowe. Przekształcenie atrybutów typu
kolekcji do postaci atomowej wymaga wielu
sztuczek, które wymagają późniejszej
normalizacji.
 Istnieje poważna trudność konwersji metod do
postaci relacyjnej
Przekształcenia atrybutów
Przekształcenie atrybutów atomowych jest
zagadnieniem trywialnym.
 W przypadku struktury przekształca się jej pola
do postaci atrybutów relacji.

Class Student (extent Studenci){
attribute string nazwisko;
attribute Struct Adr{string miasto, string ulica,
integer nr_domu}adres;
}
Studenci(nazwisko, miasto, ulica, nr_domu)
Przekształcenia atrybutów


Najwięcej trudności sprawia przekształcenie
atrybutów typu kolekcji (zbiór, wielozbiór, lista,
tablica itp.). Każdy typ posiada specyficzny
sposób konwersji.
Jedna z metod reprezentowania zbioru wartości
atrybutu A polega na utworzeniu dla każdej
wartości odpowiadającej jej krotki. Taka krotka
zawiera wówczas stosowne wartości wszystkich
pozostałych atrybutów klasy. Niestety taka technika
zastępowania obiektów atrybutami o wartościach
zbiorowych przez kolekcje krotek, po jednej dla
każdej kombinacji wartości tych atrybutów może
prowadzić do postaci nieznormalizowanych.
Przekształcanie atrybutów
Class Aktor(extent Aktorzy){
attribute string nazwisko;
attribute Set<Struct Adr{string miasto, string
ulica}> adres;
};
nazwisko
miasto
ulica
Carrie Fischer
Hollywood
123 Mapie St .
Carrie Fischer
Malibu
5 Locust Ln.
Mark Hamill
Brentwood
456 Oak Rd.
Harrison Ford
Beverly Hills
789 Palm Dr.
Przekształcenie wielozbiorów

W przypadku wielozbiorów metoda
przekształcenia dla zbiorów komplikuje się,
ponieważ w bazie krotki nie mogą się
powtarzać. Rozwiązaniem tego problemu jest
wprowadzenie dodatkowego atrybutu np.
licznika, który będzie przechowywał informację o
ilości identycznych krotek.
Model obiektowo-relacyjny

Model obiektowy nie znalazł szerszego
wykorzystania w praktycznej implementacji
systemów baz danych. Nie nastąpił rozwój
obiektowych systemów baz danych kosztem
relacyjnych baz danych. Jednak od lat 90
obserwuje się tendencję wykorzystywania
niektórych zalet podejścia obiektowego w
relacyjnych systemach baz danych. To
spowodowało wyodrębnienie się grupy
obiektowo-relacyjncyh baz danych.
Rozszerzenie modelu relacyjnego
Atrybuty nie muszą być atomowe. Dużą uwagę
skupia się na zbiorach struktur, które same w
sobie tworzą relację. Składową krotki może być
cała relacja.
 Wykorzystanie metod. Można zdefiniować i
stosować specjalne operacje dla typów
zdefiniowanych przez użytkownika.
 Identyfikatory krotek. Krotki odgrywają rolę
obiektów. Zazwyczaj identyfikator krotki jest
ukryty, ale w specyficznych sytuacjach może
być widoczny.
 Referencje - wskaźniki do krotek.

Od ODL do modelu obiektoworelacyjnego

Znacznie prostsza jest konwersja z modelu
obiektowego do obiektowo-relacyjnego niż do
modelu relacyjnego ze względu na
wprowadzone rozszerzenia (nieatomowe
atrybuty, metody, referencje itp.).
 Reprezentacja związków w modelu obiektoworelacyjnym jest taka sama jak w modelu
relacyjnym.
 Problem tłumaczenia modelu z metodami do
czystego modelu relacyjnego w przypadku
modelu obiektowo-relacyjnego praktycznie nie