Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 06, Folia 1 kwiecień 2004

Obiektowe języki zapytań

Wykładowca: Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, [email protected]

Instytut Podstaw Informatyki PAN, [email protected]

Wykład 06: Modele składu obiektów


Złożoność modeli obiektowych (1)

Istniejące modele obiektowe są bardzo złożone. Model obiektowy standardu ODMG włącza dużą liczbę pojęć takich jak:

obiekty, literały, typy, podtypy, interfejsy, dziedziczenie, przesłanianie, polimorfizm, kolekcje, struktury, związki, operacje, wyjątki i inne.

Jeszcze bardziej złożony jest model SQL-99, ponieważ do wymienionych pojęć dokłada (co najmniej) relacje i abstrakcyjne typy danych (ADT).

Zasadniczy udział w tej złożoności mają cechy drugorzędne i brak dążenia do upraszczania i redukcji pojęć, eliminacji pojęć drugorzędnych i zastępowanie bardziej specyficznych pojęć przez pojęcia bardziej ogólne.

Konsekwencją złożoności modelu obiektowego jest złożoność języka zapytań, w szczególności jego semantyki, ponieważ każda cecha modelu obiektowego musi mieć swoje odbicie w składni, semantyce i w pragmatyce języka bazującego na tym modelu. • Precyzyjna semantyka języka oznacza konieczność zdefiniowania zbioru

wszystkich stanów (zbioru Stan). Złożoność modelu obiektowego powoduje złożoność definicji tego zbioru i w konsekwencji złożoność definicji języka.


Złożoność modeli obiektowych (2)

Złożoność oznacza zwiększenie trudności przy formalnej analizie semantyki, czyli utrata kontroli nad uniwersalnością języka oraz znaczne zmniejszenie potencjału dla optymalizacji zapytań.

Obecny świat informatyki przemysłowo-komercyjnej nie docenia problemu semantyki języków zapytań oraz optymalizacji zapytań.

Dla SQL-99 lub OQL nie można zbudować modeli formalnych z powodu zasadniczych wad ich specyfikacji i licznych niespójności.

Brak modelu formalnego uniemożliwia wnioskowanie o semantycznie równoważnych przekształceniach optymalizacyjnych.

Z tego powodu konieczne staje się uproszczenie modeli obiektowych i/lub taka abstrakcja nad tymi modelami, która byłaby formalnie prosta i jednocześnie dostatecznie wiernie oddawałaby modele praktyczne. • Modele obiektowe wprowadzają dużo pojęć, często różnie rozumianych.

Nie jest możliwe zbudowanie pojedynczego modelu formalnego.

Będziemy opierali się o pewną rodzinę modeli, z tą samą bazą pojęciową.


Modele składu obiektów

M0: obejmuje dowolnie powiązane hierarchiczne struktury danych; nie obejmuje klas, dziedziczenia, interfejsu i hermetyzacji. Model M0 pozwala wyjaśnić semantykę relacyjnych języków zapytań (szczególnie SQL), przykrywa koncepcję zagnieżdżonych relacji, struktury implikowane przez XML i dane określane jako pół-strukturalne.

M1: uzupełnia M0 o pojęcia klasy, dziedziczenia i wielodziedziczenia w najczęściej spotykanym rozumieniu; nie obejmuje hermetyzacji i interfejsu.

M2: uzupełnia model M1 oraz nieco go modyfikuje wprowadzając dziedziczenie pomiędzy obiektami oraz dynamiczne role. Można go również uważać jako model odwzorowujący koncepcję wielu interfejsów do obiektu.

M3: uzupełnia model M1 lub M2 o pojęcie hermetyzacji - podział własności klas i obiektów na publiczne i prywatne.

Podana rodzina modeli nie zamyka tematu.

object store


Pojęcia wspólne dla modeli M0, M1, M2 i M3

Wewnętrzny identyfikator obiektu. Jest nadawany automatycznie przez system i nie posiada semantyki w świecie zewnętrznym. Jest nieczytelny. Jest unikalny dla danego obiektu. Służy do identyfikacji obiektów w pamięci komputera. Nie będziemy zajmować się budową identyfikatorów ani ich specjalizowaniem w zależności od rodzaju obiektu lub pamięci.

Zewnętrzna nazwa obiektu. W odróżnieniu od wewnętrznego identyfikatora, zewnętrzna nazwa jest nadawana przez projektanta, programistę lub administratora. Jest powiązana z modelem koncepcyjnym lub biznesowym aplikacji działających na bazie danych. Posiada (nieformalną) semantykę w świecie zewnętrznym. Np. taką nazwą może być Klient lub Zarobek. W odróżnieniu od wewnętrznego identyfikatora, zewnętrzna nazwa nie musi być i zwykle nie jest unikalna.

Wartość atomowa. Wartość atomowa jest z naszego punktu widzenia niepodzielna, nie posiada wyróżnialnych składowych. Wartość atomowa może być liczbą, stringiem, blobem, ciałem metody, perspektywy, procedury, reguły, itd.


Model M0

• I - zbiór identyfikatorów (i, i1, i2, ... - oznaczenia identyfikatorów)

• N - zbiór nazw (n, n1, n2, ... - oznaczenia nazw)

• V - zbiór wartości atomowych (v, v1, v2, ... - oznaczenia wartości)

Obiekt atomowy: trójka <i, n, v>.

Obiekt pointerowy: trójka <i1, n, i2>. Obiekt jest identyfikowany przez i1, natomiast i2 jest pointerem (referencją) do innego obiektu.

Obiekt złożony: trójka <i, n, T>, gdzie T jest zbiorem dowolnych obiektów. Powyższa reguła umożliwia rekurencyjne tworzenie obiektów o nieograniczonej złożoności i o nieograniczonej liczbie poziomów hierarchii.

Skład obiektów jest zdefiniowany jako para <S, R>, gdzie S jest zbiorem obiektów, zaś R jest zbiorem identyfikatorów "startowych”.

• Zbiór R wyznacza punkty wejściowe do składu obiektów, tj. obiekty "korzeniowe" (root objects), które mogą być początkiem wyszukiwania w zbiorze przechowywanych obiektów.


Ograniczenia w modelu M0

Każdy obiekt, podobiekt, itd. w składzie posiada unikalny identyfikator.

Jeżeli (na dowolnym poziomie hierarchii obiektów) wystąpi obiekt pointerowy <i1,n,i2>, to powinien istnieć również obiekt posiadający identyfikator i2. Warunek oznacza brak zwisających pointerów (lub tzw. integralność referencyjną).

Dowolny identyfikator ze zbioru R jest identyfikatorem pewnego obiektu znajdującego się w składzie.

Będziemy abstrahować od obiektów, które nie są osiągalne ze zbioru R, bezpośrednio lub pośrednio. Obiekt bezpośrednio osiągalny posiada identyfikator ze zbioru R. Obiekt jest osiągalny, jeżeli jest bezpośrednio osiągalny lub jest podobiektem obiektu osiągalnego. Obiekt jest także osiągalny, jeżeli posiada identyfikator i2 oraz jest osiągalny obiekt pointerowy <i1, n, i2>. Obiekty nieosiągalne nie są w stanie wpłynąć na wynik ewaluacji zapytań; są one tzw. nieużytkami (garbage) i mogą być w dowolnym momencie skasowane.


Przykład składu w modelu M0

Dział [0..*]NazwaLokacja[1..*]

Diagram klas

PracujeW

Zatrudnia[1..*]

Prac [0..*]NazwiskoZar

Adres [0..1]MiastoUlicaNrDomu

S - Obiekty:

< i1 , Prac , {< i2, Nazwisko, ”Nowak” >, < i3, Zar, 2500 >, < i4, PracujeW, i17 > } >,

< i5 , Prac , {< i6, Nazwisko, ”Kowalski” >, < i7, Zar, 2000 >, < i8, PracujeW, i22 > } >,

< i9 , Prac , {< i10, Nazwisko, ”Barski” >, < i11, Zar, 900 >, < i12, Adres, {< i13, Miasto, ”Radom” >,

< i14, Ulica, ”Wolska” >, < i15, NrDomu, 12 > } >,

< i16, PracujeW, i22 > } >,

< i17 ,Dział, {<i18, Nazwa, ”Produkcja” >, < i19, Lokacja, ”Kielce” >, < i20, Lokacja, ”Kraków” >, < i21, Zatrudnia, i1 > } >,

< i22 , Dział,{< i23, Nazwa, ”Sprzedaż” >, < i24, Lokacja, ”Radom” >, < i25, Zatrudnia, i5 >, < i26, Zatrudnia, i9 > } >

R - Identyfikatory startowe:i1 , i5 , i9 , i17 , i22


Poglądowy obraz małej bazy danych

i1 Prac

i2 Nazwisko ”Nowak”

i3 Zar 2500

i4 PracujeW

i5 Prac

i6 Nazwisko ”Kowalski”

i7 Zar 2000

i8 PracujeW

i9 Prac

i10 Nazwisko ”Barski”

i11 Zar 900

i16 PracujeW

i13 Miasto ”Radom”

i14 Ulica ”Wolska”

i15 NrDomu 12

i12 Adres

i17 Dział

i18 Nazwa ”Produkcja”

i19 Lokacja ”Kielce”

i21 Zatrudnia

i20 Lokacja ”Kraków”

i22 Dział

i23 Nazwa ”Sprzedaż”

i24 Lokacja ”Radom”

i25 Zatrudnia

i26 Zatrudnia


Modelowanie „zmiennych” języka programowania

Nie będziemy robić rozróżnienia pomiędzy pojęciem języków programowania określanym jako „zmienna” oraz wprowadzonymi przez nas obiektami. • Np. zmienna x z języka programowania posiadająca aktualną wartość 5

będzie w naszych modelach składu reprezentowana jako trójka <i, x, 5>, gdzie i jest pewnym identyfikatorem wewnętrznym tej zmiennej, np. jej adresem w pamięci operacyjnej.

Nie będziemy również rozróżniać pojęcia zmiennej i pojęcia obiektu na zasadzie: obiekt posiada swoją klasę, zaś zmienna nie posiada klasy. • Wszystkie obiekty posiadają klasę, ale dla niektórych obiektów są one puste

(nie zawierają żadnych inwariantów), wobec czego są pomijane.

• Model M0 nie ma klas, ale wprowadza obiekty (inaczej „zmienne”).

Nie zajmujemy się również cechą trwałości obiektów, tj. czy obiekty są przechowywane na dysku czy też w pamięci operacyjnej. • Cecha trwałości nie ma znaczenia dla definiowania semantyki języka

zapytań.


Relatywizm obiektów

Nie będziemy przywiązywać wagi do podziału obiektów na proste i złożone, a także nie wprowadzamy specjalnej terminologii i pojęć dla obiektów złożonych.

Tego rodzaju relatywizm obiektów ma zasadnicze znaczenie dla uproszczenia definiowanych języków, znacznie upraszcza metamodel i operacje na metamodelu, zwiększa uniwersalność języka i ma zasadnicze znaczenia dla prostoty oraz klarowności semantyki i pragmatyki. • W wielu koncepcjach obiektowości (np w standardach CORBA i ODMG)

relatywizm nie jest wyznawany. Np. w ODMG atrybut jest tzw. literałem, który nie jest obiektem. Podobnie, większość koncepcji innych autorów implicite zakłada, że obiekt musi być złożony, tj. musi posiadać strukturę wewnętrzną w postaci atrybutów, pól, itp.

W tej koncepcji zbędne również staje się pojęcie modułu. Moduł jest po prostu obiektem składającym się z obiektów.

object relativism


Modelowanie kolekcji i struktur

W zdefiniowanym powyżej modelu M0 (jak i w następnych modelach) nie zakładamy unikalności zewnętrznych nazw obiektów. Dotyczy to dowolnego poziomu hierarchii obiektów. • Przykładowo, na górnym poziomie hierarchii nazwy Prac i Dział nie są

unikalne, zaś wewnątrz obiektów Dział nie są unikalne nazwy Lokacja i Zatrudnia.

• To założenie umożliwia modelowanie kolekcji bez wprowadzania w tym celu specjalnych środków formalnych. Kolekcja nie występuje jako identyfikowalny byt programistyczny - w odróżnieniu np. od ODMG.

• Podobne założenie odnośnie kolekcji przyjmuje XML.

Abstrahujemy od wielu pojęć wprowadzanych w innych modelach, takich jak krotki (tuples), struktury, warianty/unie, zapisy (records), zbiory (sets), wielozbiory (bags), ekstensje (extents), itd. • Pojęcia te dadzą się wyrazić w terminach podanego modelu poprzez pewne

ograniczenie lub wyspecjalizowanie.

• Z naszego punktu widzenia są to zestawy obiektów lub obiekty złożone.


W naszych modelach składu kolekcja nie występuje jako pojedynczy, identyfikowalny byt programistyczny. • Nie można utworzyć pojedynczej referencji prowadzącej do kolekcji.

• Można zbudować zbiór referencji do elementów danej kolekcji, w szczególności, do wszystkich elementów danej kolekcji.

Można oczywiście utworzyć obiekt, który w środku będzie miał tak samo nazwane podobiekty, i wtedy można zbudować referencję do takiego obiektu.

Taki zabieg oczywiście nic nie wnosi do koncepcji, nadal jesteśmy w modelu M0.

Model M0 zajmuje się wyłącznie kolekcjami zwanymi bagi (bags). Inne kolekcje, takie jak sekwencje, wymagają nowego modelu.

Kolekcje

OsobaOsobaOsobaOsoba OsobaOsoba OsobaOsoba OsobaOsoba

OsobyOsoby


Modelowanie powiązań pomiędzy obiektami

Obiekty pointerowe umieszczone wewnątrz obiektów są w stanie odwzorować powiązania pomiędzy obiektami. • Np. każdy obiekt pointerowy PracujeW prowadzi do odpowiedniego obiektu

Dział, zaś każdy obiekt pointerowy Zatrudnia prowadzi do obiektu Prac.

Podobnie jak w modelu ODMG nie będziemy interesowali się powiązaniami o arności wyższej niż 2 oraz powiązaniami posiadającymi własne atrybuty.

Takie opcje zwiększają złożoność programistycznego interfejsu. • W szczególności, trudności są związane z aktualizacją takich powiązań, np.

przełączeniu jednej gałęzi danego powiązania do innego obiektu.

• Powiązania posiadające własne atrybuty prowadzą do niejasności koncepcyjnej. Konieczne byłoby tworzenie nowego rodzaju klasy, która opisywałaby atrybuty powiązań.

• Konieczne byłyby podwójne definicje klas: dla obiektów i dla powiązań.

Nie wydaje się również potrzebne dekorowanie powiązania klasą (jak w UML)


Wartości zerowe, warianty, dane półstrukturalne

M0 umożliwia formalizację wartości zerowych i wariantów (unii). Np. atrybut (złożony) Adres występuje tylko dla jednego obiektu Prac. • Model niczym nie zobowiązuje nas do tego, aby obiekty posiadające te same

nazwy posiadały pod-obiekty o tych samych nazwach.

• Model nie wprowadza (jak dotąd) ograniczeń typologicznych, co daje pełną swobodę w zakresie budowy poszczególnych obiektów.

• Będziemy uważać, że ewentualny dyskryminator wariantu jest takim samym pod-obiektem jak pozostałe.

M0 przykrywa nieregularności w danych, określane ostatnio jako dane pół-strukturalne (semistructured). • Oznacza to, że budowana przez nas semantyka będzie adekwatna do budowy

języków zapytań i języków programowania obsługujących takie struktury.

• W szczególności, semantyka będzie nadawała się do struktur rozważanych w technologiach opartych na XML.

• Nie będziemy jednak dążyć do dopasowania lukru syntaktycznego języka zapytań do lukru syntaktycznego XML.


Model relacyjny i model zagnieżdżonych relacji

Model M0 włącza struktury danych zakładane przez model relacyjny jako szczególny przypadek. Semantykę relacyjnego języka zapytań (w szczególności SQL) można będzie zdefiniować jako szczególny przypadek definiowanej przez nas semantyki. • Nie będziemy nastawiać się na definiowanie semantyki SQL. SQL jest

językiem o licznych anomaliach, niekonsekwencjach i semantycznych rafach, w związku z tym definiowanie jego precyzyjnej semantyki jest trudne i mało sensowne. Przed taką definicją należałoby wcześniej uporządkować koncepcję języka, a na to w przypadku SQL jest za późno.

Model M0 przykrywa również model zagnieżdżonych relacji (NF2) jako szczególny przypadek.

Również struktury danych implikowane przez inne modele, określane przez ich autorów jako funkcjonalne, obiektowe, logiczne, semantyczne, itd. dadzą się sformalizować w terminach podanego prostego modelu.


Relacja zapisana w modelu M0

Schemat relacyjny: Prac( Nazwisko, Zarobek, PracujeW )

NazwiskoNowakKowalskiBarski

Zarobek250020002000

PracujeWProdukcjaSprzedażSprzedaż

Model relacyjny - Relacja Prac

S - Obiekty:< i1 , Prac, { < i2, Nazwisko, ”Nowak” >,

< i3, Zarobek, 2500 >, < i4, PracujeW, ”Produkcja” > } >,

< i5 , Prac, { < i6, Nazwisko, ”Kowalski” >, < i7, Zarobek, 2000 >, < i8, PracujeW, ”Sprzedaż” > } >,

< i9 , Prac, { < i10, Nazwisko, ”Barski” >, < i11, Zarobek, 2000 >, < i12, PracujeW, ”Sprzedaż” > } >

R - Identyfikatory startowe:i1 , i5 , i9

Model składu obiektów M0:

Krotki relacji jako obiekty złożone


<pracownik><imie>Jan</imie><nazwisko>Kowalski</nazwisko><data_urodz>1973-12-1</data_urodz><pensja>2500</pensja>

</pracownik>

S - Obiekty:< i1, pracownik, {

< i2, imie, ”Jan” >, < i3, nazwisko, "Kowalski" >,< i4, data_urodz, 1973-12-1>< i5, pensja, 2500>

} >R - Identyfikatory startowe:i1

Model składu obiektów M0:

Plik XML

Dokument XML zapisany w modelu M0

Nie ma różnic koncepcyjnych. Potencjalne drobne problemy:

• Jak określić identyfikatory dla obiektów XML?

• Jak traktować informacje (tzw. atrybuty) wewnątrz XML-owych tagów?

• Jak modelować powiązania (obiekty pointerowe) w XML?


Sekwencje i tablice w modelu M0

Istnieją ważne operatory, które potrzebują uwzględnienia porządku w obiektach. Do nich należy np. operator order by języka SQL. Istotny jest również operator wyboru n pierwszych (lub ostatnich) elementów z pewnej kolekcji. Umożliwia on m.in. takie zapytania jak „Podaj 50-ciu najlepiej zarabiających pracowników”.

Czy potrzebne jest wzbogacenie naszego modelu o pojęcie "sekwencji"?• Model M0 bezpośrednio nie uwzględnia sekwencji. Należy go rozszerzyć.

• Można też np. zastosować konwencję w której nazwy obiektów są liczbami naturalnymi. Np. tablica ustalająca dzieci pracownika w porządku od najstarszego do najmłodszego mogłaby mieć postać:

• <i1, Dzieci, { <i2, 1, ”Jacek”>, <i3, 2, ”Adam”>, <i4, 3, ”Anna”> }>

• Przy takim modelu dostęp do elementu tablicy następowałby poprzez indeks, np. Dzieci.2 oznaczałoby wiązanie do identyfikatora i3 (wartości ”Adam”).

• Możliwe byłoby również użycie takich wyrażeń jak np. Dzieci.[x+1], które przy wartości obiektu x równej 2 zwróci i4.

• Są inne metody realizacji pojęcia sekwencji w ramach modelu M0.


Model M1 - klasy i dziedziczenie

Model M1 wprowadza pojęcia klasy i dziedziczenia w wersji prototypów. Klasa jest obiektem podobnym do wprowadzonych poprzednio obiektów.

Obiekty będące klasami będą wyróżnione jako te, które przechowują inwarianty innych obiektów. Ta rola klas będzie miała wpływ na definiowaną przez nas semantykę języków zapytań.

W M1 skład obiektów jest zdefiniowany jako <S, R, KK, OK>, gdzie:

• S jest zbiorem obiektów (rozszerzonym o klasy),

• R jest zbiorem identyfikatorów obiektów będących „wejściem” do nawigacji w obiektowej strukturze danych,

• relacja KK I I wyznacza związek dziedziczenia pomiędzy klasami,

• relacja OK I I wyznacza przynależność obiektów do klas.

Dla każdej pary <i1, i2> KK, i1 oznacza identyfikator klasy dziedziczącej, zaś i2 oznacza identyfikator klasy z której się dziedziczy.

Model M1 obejmuje wielokrotne dziedziczenie.


Przykład modelu M1

S - Obiekty i klasy:< i1 , Osoba , { < i2, Nazwisko, ”Wilski” >, < i3, RokUr, 1950 > } >,

< i4 , Prac , { < i5, Nazwisko, ”Nowak” >, < i6, RokUr, 1944 >, < i7, Zar, 2500 >, < i8, PracujeW, i127 > } >,

< i9 , Prac , { < i10, Nazwisko, ”Kowalski” >, < i11, RokUr, 1940 >, < i12, Zar, 2000 >, < i13, PracujeW, i128 > } >,

< i40 , KlasaOsoba , { < i41, Wiek, (..kod metody Wiek..) >,inwariant: Nazwa obiektów = "Osoba",..pozostałe inwarianty klasy KlasaOsoba ..}>,

< i50 , KlasaPrac , { < i51, ZmieńZar, (..kod metody ZmieńZar..) >,< i52, ZarNetto, (...kod metody ZarNetto..) >,inwariant: Nazwa obiektów = "Prac";..pozostałe inwarianty klasy KlasaPrac .. }>,


KK - Związki dziedziczenia między klasami:< i50 , i40 > OK - Związki dziedziczenia między obiektami i klasami:< i1 , i40 >, < i4 , i50 >, < i9 , i50 >


Graficzna reprezentacja przykładu modelu M1

i40 KlasaOsoba

i41 Wiek (...kod...)

................

i50 KlasaPrac

i51 ZmieńZar (...kod...)

................

i52 ZarNetto (...kod...)

i4 Prac


i7 Zar 2500

i8 PracujeW

i6 RokUr 1944

i127

i1 Osoba

i2 Nazwisko ”Wilski”

i3 RokUr 1950

i128

i9 Prac


i12 Zar 2000

i13 PracujeW

i11 RokUr 1940

OsobaNazwiskoRokUrWiek

PracZarZmieńZarZarNetto

PracujeW


Inwariant klasy - nazwa jej obiektów

Model M1 implikuje problemy z wiązaniem nazw. Zgodnie z zasadą zamienialności (substitutability, LSP), jeżeli w

wyrażeniu występuje nazwa Osoba, to związane muszą być nie tylko obiekty Osoba, ale również obiekty Prac.

M1 w sformułowaniu formalnym nie zawiera bezpośrednio informacji, która to umożliwia, zatem musi być rozszerzony. • W klasycznych modelach problem ten nie występuje, gdyż nazwa obiektów

nie jest inwariantem klasy, zaś zamienialność wynika z hierarchii klas lub typów.

To rozszerzenie można zrobić na kilka sposobów. Podany sposób zakłada, że klasy są wyposażona w dodatkowy inwariant -

nazwę obiektów danej klasy.


Model M2 - dynamiczne role

Model M2 jest uporządkowaną piątką <S, R, KK, OK, OO>, gdzie wprowadziliśmy nową relację OO I I.• Relacja OO pozwala obiektom dziedziczyć z innych obiektów, na takiej

samej zasadzie jak obiekty dziedziczą z klas. Obiekty dziedziczące z obiektu A będziemy nazywać rolami obiektu A. Możliwe jest dziedziczenie z ról.

• Relacja OO ustala semantykę manipulacji obiektami z dynamicznymi rolami. W szczególności, usunięcie obiektu będzie powodować usunięcie wszystkich jego ról.

Model M2 jest wolny od pewnych anomalii typologicznych i jest formalnie bardziej „czysty” w stosunku do modelu M1. W szczególności, nie ma wspomnianego problemu z wiązaniem nazw.• Jest paradoksem fakt, że model składu wprowadzający role, który jest

semantycznie czysty i prosty, jest uważany za zbyt skomplikowany.

• Wydaje się, że wynika to z pewnych obciążeń myślenia o obiektowości, wynikających z tradycji istniejących języków programowania, takich jak C++ i Smalltalk.


Przykład modelu M2

S - Obiekty i klasy:

< i1 , Osoba , { < i2, Nazwisko, "Wilski" >, < i3, RokUr, 1950 > } >,< i4 , Osoba , { < i5, Nazwisko, "Nowak" >, < i6, RokUr, 1944 >} >,< i7 , Osoba , { < i8, Nazwisko, "Kowalski" >, < i9, RokUr, 1940 >} >,< i13 , Prac , { < i14, Zar, 2500 >, < i15, PracujeW, i127 > } >,< i16 , Prac , { < i17, Zar, 2000 >, < i18, PracujeW, i128 > } >,< i19 , Student , { < i20, NrIndeksu, 76943 >, < i21, Wydział, "fizyka" >} >,

< i40 , KlasaOsoba , { < i41, Wiek, (...kod metody Wiek...) >, ...pozostałe inwarianty klasy KlasaOsoba ...}>,

< i50 , KlasaPracownik , { < i51, ZmieńZar, (...kod metody ZmieńZar...) >, < i52, ZarNetto, (...kod metody ZarNetto...) >,

...pozostałe inwarianty klasy KlasaPrac ... }>,

< i60 , KlasaStudent , { < i61, ŚredniaOcen, (...kod metody ŚredniaOcen...) >, ...pozostałe inwarianty klasy KlasaStudent ... }>,

R - Identyfikatory startowe: i1 , i4 , i7 , i13 , i16 , i19

KK - Związki dziedziczenia między klasami: Zbiór pusty

OK - Związki dziedziczenia między obiektami i klasami: < i1 , i40 >, < i4 , i40 >, < i7 , i40 >, < i13 , i50 >, < i16 , i50 >, < i19 , i60 >,

OO - Związki dziedziczenia między obiektami i obiektami: < i13 , i4 >, < i16 , i7 >, < i19 , i7 >


Graficzna reprezentacja przykładu modelu M2

i1 Osoba

i2 Nazwisko ”Wilski”

i3 RokUr 1950

i40 KlasaOsoba

i41 Wiek (...kod...)

.............

i50 KlasaPrac

i51 ZmieńZar (...kod...)

................

i52 ZarNetto (...kod...)

i60 KlasaStudent

i61 ŚredniaOcen (...kod...)

................

i13 Prac

i14 Zar 2500

i15 PracujeW

i127

i4 Osoba


i6 RokUr 1944

i7 Osoba


i9 RokUr 1940

i128

i16 Prac

i17 Zar 2000

i18 PracujeW

i19 Student

i20 NrIndeksu 76943

i21 Wydział ”fizyka”


Odmienność i zalety modelu z rolami (1)

Wielokrotne dziedziczenie: Ponieważ role są hermetyzowane, nie może wystąpić konflikt nazw nawet wtedy, gdy różne role (czyli specjalizacje obiektu) posiadają własności o tych samych nazwach.

Powtarzalne dziedziczenie: Jest normalne, że obiekt może mieć dwie lub więcej ról o tej samej nazwie. Np. Kowalski może być dwa razy studentem, w różnych szkołach. Ten przypadek nie jest objęty klasycznym modelem dziedziczenia lub wielokrotnego dziedziczenia.

Przechowywanie obiektów historycznych: Role idealnie nadają się do przechowywania obiektów historycznych nie powodując przy tym anomalii z unikalnością identyfikatorów obiektów. Np. można łatwo zapisać fakt, że Kowalski był już kiedyś dwa razy studentem.

Wielo-aspektowe dziedziczenie: Klasa może być specjalizowana wg wielu aspektów, np. według stosunku do zatrudnienia lub stosunku do wykształcenia. UML przykrywa tę cechę, ale jest ona nieobecna w narzędziach obiektowych, co prowadzi m.in. do efektu "eksplozji klas". Role automatycznie mają cechę wielo-aspektowego dziedziczenia.



Warianty (unie): Cecha ta, wprowadzona m.in. w C++, CORBA i ODMG, prowadzi do wielu semantycznych i implementacyjnych problemów. Role przykrywają tę cechę, przez co staje się niepotrzebna.

Migracja obiektów: Role mogą pojawiać się i znikać dynamicznie, co w terminach klasycznych modeli obiektowych oznacza, że obiekt zmienia klasę (czyli "migruje") bez zmiany tożsamości. Dla klasycznych modeli jest to duży problem. W przypadku ról problem ten nie istnieje.

Spójność referencyjna: W przypadku ról związki mogą prowadzić do ról, a nie do całych obiektów. Np. jeżeli nawigujemy od obiektu Szkoła do obiektu Kowalskiego poprzez jego rolę Student, wówczas niedostępny jest atrybut Zar i metoda ZarNetto. Jest to znaczne uściślenie hermetyzacji.

Dynamiczne dziedziczenie: KlasaPrac nie dziedziczy statycznie z KlasaOsoba. Zamiast tego, rola Prac dziedziczy dynamicznie z roli Osoba wszystkie cechy, włączając metody zawarte w klasie KlasaOsoba. Stwarza to nową sytuację dla przesłaniania i polimorfizmu.



Heterogeniczne, przecinające się kolekcje. W klasycznych modelach, np. w ODMG, jeżeli obiekt był elementem kolekcji, to nie mógł być jednocześnie elementem innej kolekcji. Jest to ograniczenie modelowania pojęciowego. Dynamiczne role posiadają naturalną zdolność modelowania heterogenicznych, przecinających się kolekcji.

• Np. można utworzyć rolę Pacjent, i tą rolę objąć ludzi i zwierzęta, oraz inną rolę ObiektyDzisiajAktualizowane obejmującą obiekty dowolnego typu. Kolekcje Pacjent i ObiektyDzisiajAktualizowane są heterogeniczne i zachodzą na siebie.

Programowanie aspektowe (Aspect-Oriented Programming, AOP) i rozdzielenie aspektów. AOP zajmuje się rozdzieleniem przecinających się aspektów (cross-cutting concerns) celem umieszczenie każdego aspektu w odrębnym module programu (np. historię zmian, reguły bezpieczeństwa, wizualizację, itd.). Dynamiczne role mają wiele zbieżności z AOP lub mogą być wykorzystane jako techniczne wspomaganie AOP.


Model M3 - hermetyzacja i ukrywanie informacji

Model M3 uwzględniający hermetyzację możemy zbudować zarówno na gruncie modelu M1, jak i modelu M2, ponieważ cecha hermetyzacji jest ortogonalna w stosunku do wprowadzonych wcześniej własności.

Idea hermetyzacji polega na tym, aby w określonych sytuacjach zabronić dostępu do pewnych własności obiektów, określanych jako „prywatne”. • Chodzi o to, aby własności prywatne były dostępne z „wnętrza” obiektu, zaś

niedostępne z jego „zewnętrza”. Będzie to wymuszone poprzez stosową semantykę języka zapytań.

Model M3 uzupełnia model M1 lub M2 w taki sposób, że klasy są wyposażona w dodatkowy inwariant - listę eksportową. Jest ona zbiorem nazw własności tej klasy i jej obiektów (metod, atrybutów), które będą widoczne z zewnątrz.

Lista eksportowa będzie użyta w procesie ewaluacji zapytań jako dodatkowy środek kontroli zakresu obowiązywania nazw.• Podobny środek polega na wprowadzeniu pojęcia interfejsu do obiektów

danej klasy.


Przykład modelu M3

S - Obiekty i klasy:< i1 , Osoba , { < i2, Nazwisko, ”Wilski” >, < i3, RokUr, 1950 > } >,

< i4 , Prac , { < i5, Nazwisko, ”Nowak” >, < i6, RokUr, 1944 >, < i7, Zar, 2500 >, < i8, PracujeW, i127 > } >,

< i9 , Prac , { < i10, Nazwisko, ”Kowalski” >, < i11, RokUr, 1940 >, < i12, Zar, 2000 >, < i13, PracujeW, i128 > } >,

< i40 , KlasaOsoba , { < i41, Wiek, (..kod metody Wiek..) >,inwariant: Nazwa obiektów = "Osoba",inwariant: Lista eksportowa = {"Nazwisko",

"Wiek"},..pozostałe inwarianty klasy KlasaOsoba ..}>,

< i50 , KlasaPrac, { < i51, ZmieńZar, (..kod metody ZmieńZar..) >,< i52, ZarNetto, (...kod metody ZarNetto..) >,inwariant: Nazwa obiektów = "Prac";inwariant: Lista eksportowa = {"PracujeW",

"ZmieńZar", "ZarNetto" },..pozostałe inwarianty klasy KlasaPrac .. }>,


KK - Związki dziedziczenia między klasami:< i50 , i40 > OK - Związki dziedziczenia między obiektami i klasami:< i1 , i40 >, < i4 , i50 >, < i9 , i50 >

+PracujeW

Osoba+ Nazwisko- RokUr+ Wiek

Prac- Zar+ ZmieńZar+ ZarNetto


Schemat bazy danych dla modeli składu

Język schematu bazy danych jest bardzo ważnym uzupełnieniem dowolnego modelu składu.

Język schematu stanowi inherentną część języka zapytań (jego pragmatyki), gdyż na podstawie schematu programista wie, co baza danych zawiera i jak jest zorganizowana.

Schemat bazy danych jest również wykorzystywany przez SZBD dla właściwej organizacji danych, reprezentacji danych, kontroli typów danych oraz wymuszenia niektórych ograniczeń dotyczących danych.

Przykładem takiego języka jest ODL wg standardu ODMG. • Schematy są również wyrażane w postaci graficznej; np. w UML.

Dla każdego wprowadzonego modelu składu konieczne jest opracowanie języka umożliwiającego zapis schematu. Jest to duże zadanie. • W tym wykładzie będziemy przyjmować (nie do końca słusznie), że schemat

jest ważny dla pragmatyki języka, ale jest mniej istotny dla jego semantyki.

• Z tego powodu dalej będziemy stosować notację ad hoc (wzorowaną na UML) popartą objaśnieniami i przykładami.

Documents

Obiektowe języki zapytań