obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 04, Folia 1 marzec 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 04 Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja (2)


Klasa

• Zła definicja: klasa jest to zbiór obiektów (jest to raczej ekstensja klasy).

• Dobra definicja:

Klasa jest miejscem przechowywania tych informacji dotyczących obiektów, które są dla nich niezmienne, wspólne lub dotyczą całej ich populacji. Takie informacje są nazywane inwariantami obiektów.

Inwarianty dotyczące jednego obiektu mogą być przechowywane w wielu klasach, tworzących hierarchię lub inną strukturę dziedziczenia.

Poprzez przypisanie obiektów do klas unika się przechowywania inwariantów wewnątrz każdego obiektu.

Klasa stanowi więc coś w rodzaju „czynnika wyciągniętego przed nawias” dla pewnej populacji obiektów.

Takie „wyciągnięcie przed nawias” ma ogromne znaczenie dla modelowania pojęciowego, pozwalając operować zestawem inwariantów jak abstrakcją zastępującą zarówno poszczególne egzemplarze obiektów, jak i pewną ich populację.

class


Inwarianty przechowywane w ramach klas (1)

Typ, czyli struktura obiektu. Zwykle typ określa zestaw atrybutów obiektu (ich nazwy oraz typ wartości, które mogą one przybierać).

Metody, lub inaczej operacje, które można wykonać na obiekcie.

Nazwa, czyli językowy identyfikator obiektu używany w tekstach programu lub w zapytaniach. Nazwa obiektu może być inwariantem, ale nie musi. W obiektowych językach programowania zwykle nie jest.

Specyfikacje powiązań (links, relationships) obiektów danej klasy z obiektami innej lub tej samej klasy.

Interfejs, lista eksportowa lub inny środek określający, które atrybuty czy metody są dostępne z zewnątrz klasy lub obiektu, a które są prywatne.

Wartości wspólne dla wszystkich elementów klasy, np. pewne stałe lub wspólne atrybuty.

Informacja o dopuszczalności wartości zerowych (null values);


Inwarianty przechowywane w ramach klas (2)

Wartości domyślne (default values) używane przez system w momencie tworzenia nowego obiektu lub podstawiane w sytuacji kiedy dany atrybut dla pewnego obiektu przyjmuje wartość zerową.

Zdarzenia lub wyjątki, które mogą mieć miejsce podczas wykonywania operacji na obiekcie.

Obsługa zdarzeń lub wyjątków: czynności, które mają być wykonane po wystąpieniu zdarzenia lub wyjątku; w bazach danych noszą one nazwę aktywnych reguł (active rules).

Lista importowa lub inny środek ustalający cechy obiektów innych klas, które są "zaimportowane" do wnętrza obiektów danej klasy.

Ograniczenia, więzy integralności (integrity constraints).

Reguły bezpieczeństwa i prywatności.

Informacje katalogowe, pomoce.


Interfejs

Interfejs zawiera komplet informacji o tych własnościach klasy, które są niezbędne do poprawnego manipulowania obiektami tej klasy.

Interfejs posiada znaczenie pojęciowe dla użytkownika lub programisty i pozwala na wystarczająco dokładne przedstawienie tego, co obiekt zawiera w swoim wnętrzu (tj. interfejs określa odpowiedni fragment schematu obiektowego) i jak nim manipulować.

Praktycznym kryterium rozróżnienia pomiędzy klasą i interfejsem jest fakt, że klasa może być przedmiotem obrotu handlowego, podczas gdy interfejs takiemu obrotowi nie podlega.

Interfejs jest pojęciem różnym od pojęcia typu. • Typ jest specyfikacją klasy ograniczająca kontekst, w którym obiekty tej

klasy mogą być użyte w wyrażeniach, zapytaniach lub programach. Jednocześnie typ określa często reprezentację wartości.

• Często interfejsu nie odróżnia się od typu, lub typ jest składnikiem interfejsu.

interface


Hierarchia klas i dziedziczenie

Klasę można budować wyłącznie na zasadzie formalistycznego „wyciągnięciem przed nawias” pewnego zestawu inwariantów.

Częściej jednak klasa posiada niezależne znaczenie dla modelowania pojęciowego jako ogólna abstrakcja budowana przez projektanta lub programistę w celu odwzorowania niezmiennych własności obiektów.

Dziedziczenie oznacza, że dla przetwarzania obiektu programista może wykorzystywać dowolne inwarianty z klasy, której dany obiekt jest członkiem, lub z dowolnych nadklas tej klasy.

Ważnym aspektem tworzenia hierarchii klas jest unikanie redundancji, zarówno redundancji kodu jak i redundancji koncepcyjnej.

Innym ważnym aspektem jest zwiększenie potencjału ponownego użycia: raz zdefiniowana klasa może być wielokrotnie użyta dla stworzenia jej specjalizacji.

Zasada "otwarta-zamknięta" (open-close principle): klasa jest zamknięta dla modyfikacji, ale otwarta dla rozszerzeń.

class hierarchy, inheritance


Przykład klas i dziedziczenia

PRACOWNIKZarobekFirma

ZdjęcieZarobekNetto()

ZmieńZarobek(...)

STUDENTNrIndeksu

RokStudiówWydział

WstawOcenę(...)ZaliczSemestr()

OSOBANazwisko

ImięRokUrodz

Wiek()

obiekt obiekt obiekt obiekt obiekt obiekt

obiektobiektobiekt


Obywatelstwo klasy

W językach programowania obywatelem pierwszej kategorii nazywa się taki byt programistyczny, którym można manipulować w czasie wykonania.

Obywatelem drugiej kategorii nazywa się ten byt, który istnieje tylko w tekście źródłowym programu - nie istnieje lub jest niedostępny podczas wykonania.

Klasa może być obywatelem pierwszej (Smalltalk) lub drugiej kategorii (C++).

W zależności od kategorii obywatelstwa są możliwe lub niemożliwe niektóre operacje na klasie, takie jak:• Wysłanie komunikatu do klasy (jako obiektu);• Zmiana nazwy obiektu;• Dynamiczna zmiana zestawu lub typu atrybutów obiektów ;• Dynamiczna zmiana zestawu metod znajdujących się wewnątrz klasy.

Jeżeli klasy są obywatelami pierwszej kategorii, to mogą one być traktowane na takich samych zasadach jak normalne obiekty programistyczne lub obiekty bazy danych.


Ekstensja klasy Jest to nazwany zbiór obiektów aktualnie należących do danej klasy.

Różne ekstensje mogą mieć wspólne części, co może być powodem trudności semantycznych. Stąd pojęcie ekstensji jest kontrowersyjne. Jest ona uważana za wątpliwe "dziedzictwo" modelu relacyjnego.

OSOBANazwisko Babacki

RokUr 1940

OSOBANazwisko Abacki

RokUr 1948

OSOBANazwisko Nowak

RokUr 1951

OSOBA Nazwisko

RokUrWiek()

PRACOWNIKZarobek

DziałZarobekNetto()

ZmieńZarobek(...)

OSOBANazwisko Kowalska

RokUr 1975Ekstensja

klasy OSOBA

PRACOWNIKNazwisko Nowak

RokUr 1951Zarobek 2000Dział zabawki

PRACOWNIKNazwisko Abacki

RokUr 1948Zarobek 2500Dział zabawki

PRACOWNIKNazwisko Babacki

RokUr 1940Zarobek 3000Dział sprzedaż

Ekstensja klasy PRACOWNIK

extent


Zmienne i inne cechy klasy jako całości

Oprócz inwariantów obiektów klasa może przechowywać pewne cechy właściwe dla klasy jako takiej lub cechy całej kolekcji obiektów będących członkami klasy:• Metoda zarobek_netto może potrzebować lokalnej funkcji oblicz_podatek. Ta

funkcja nie jest dziedziczona przez wystąpienia tej klasy.

• Mogą się okazać potrzebne wewnątrz klasy pewne lokalne struktury danych, np. zmienne lub obiekty oraz ich typy.

• Pewna grupa metod i obiektów może odnosić się do zbioru wszystkich aktualnych wystąpień klasy, np. liczba wystąpień tej klasy (wyliczana),

Takie metody, zmienne i obiekty mogą być prywatne lub publiczne. Alternatywą jest przyjęcie założenia, że klasa może zawierać wyłącznie

inwarianty dziedziczone przez obiekty oraz dane lokalne, niewidoczne na zewnątrz. • Cechy wspólne dla klasy A rozpatrywanej jako całość nie powinny być

cechami klasy A, lecz klasy zdefiniowanej dla kolekcji elementów (określanej jako power_set_of(A).


Zasada zamienialności

• Oznaczana też LSP (Liskov's Substitutability Principle) Zasada zamienialności głosi, że w każdym miejscu programu, gdzie

może być użyty pewien obiekt klasy K, może być także użyty obiekt, którego klasą jest podklasa klasy K. • Przykładowo, wszędzie tam, gdzie można użyć liczby całkowitej, można

także użyć liczby naturalnej; wszędzie tam, gdzie można użyć obiektu Osoba można także użyć obiektu Pracownik.

• Ponieważ obiekt podklasy klasy K zawiera więcej atrybutów niż obiekt klasy K, zasada ta oznacza ignorowanie wszystkich tych atrybutów, które „wystają” poza typ oczekiwany w danym miejscu programu.

• Zasada ta obejmuje również metody zawarte w klasach.• Ma bardziej ogólne sformułowania (dla typów obiektów).• Prowadzi niestety do pewnych anomalii: np. anomalii podstawienia, anomalii

wielodziedziczenia, dylematu "wariancja czy kontr-wariancja", i innych. Zasada zamienialności staje się kontrowersyjna jeżeli przyjmiemy, że

inwariantem obiektów jest ich nazwa. W szczególności, przestaje obowiązywać dla modelu z dynamicznymi rolami obiektów.

substitutability


Wielokrotne dziedziczenie

Jest to dziedziczenie z kilku klas, z zsumowaniem dziedziczonych cech.

Problemem wielo-dziedziczenia jest konieczność rozstrzygnięcia konfliktów nazw.

POJAZDciężar

.....prędkość_eksploat()

POJAZD_LĄDOWYilość_kół

max_prędkość.....

POJAZD_WODNYwyporność

max_prędkość.....

AMFIBIASAMOCHÓD JACHTTRAKTOR ŻAGLÓWKA

multiple inheritancemulti-inheritance


Konflikty przy wielodziedziczeniu

Jeżeli przy wielokrotnym dziedziczeniu występuje konflikt nazw, to musi nastąpić złamanie albo zasady zamienialności, albo zasady otwarta-zamknięta.• Jeżeli dla amfibii weźmiemy atrybut max_prędkość z pojazdu lądowego, to

nie może ona być użyta jako pojazd wodny (złamanie zasady LSP). Istnieje kilka metod rozstrzygania tego rodzaju konfliktów, np.:

• traktowanie konfliktu jak błędu (Eiffel), • ustalenie priorytetu ścieżek dziedziczenia, • lokalna zmiana dziedziczonej nazwy inwariantu (O2),• kwalifikowanie konfliktowych własności przez nazwę klasy (C++).

Metody te powodują jednak dalsze anomalie. Nie ma sposobu uzyskania pełnej spójności przy wielokrotnym

dziedziczeniu. • Przyczyna tego jest prosta: wielokrotne dziedziczenie oznacza zmieszanie w

środowisku jednej klasy inwariantów z dwóch lub więcej środowisk, które mogą być niekompatybilne.

• To musi powodować dalsze patologie.


Abstrakcyjne typy danych, ADT

ADT jest oparty na założeniu, że typ struktury danych jest skojarzony z operacjami działającymi na elementach tego typu.

Nie istnieje potrzeba i możliwość używania operacji nie należących do oferowanego zestawu; operacje są kompletne i wyłączne (hermetyzacja).

Bezpośredni dostęp do składowych takiej struktury danych nie jest możliwy, dzięki czemu jej szczegóły implementacyjne (np. zestaw i reprezentacja atrybutów) są niewidoczne. • Np. stos, wraz z operatorami push (połóż element na wierzchołku stosu), pop

(zdejmij element z wierzchołka stosu), top (odczytaj element znajdujący się na wierzchołku stosu) i empty (sprawdź, czy stos jest pusty).

• Po zadeklarowaniu lub utworzeniu zmiennej X jako stosu, wszelkie operacje na tej zmiennej odbywają się poprzez powyższe cztery operatory.

ADT jest w istocie innym spojrzeniem na pojęcia klasy i interfejsu. W związku z tym dalej zrezygnujemy z używania terminu ADT.

abstract data type


Polimorfizm

• Polimorfizm w teorii typów: umożliwienie programom lub procedurom działania jednocześnie na wielu typach. Tym nie będziemy się zajmować.

Polimorfizm w obiektowości: dynamiczny wybór metody, po otrzymaniu komunikatu skierowanego do obiektu.

polymorphism

obiekt obiektobiekt obiekt

STUDENT....

dochody()....

PRACOWNIK....

dochody()....

EMERYT....

dochody()....

obiektobiekt

OSOBAnazwiskokategoria

....

....

Metody dochody są różne dla każdej klasy. Po otrzymaniu komunikatu dochody wybierana jest metoda właściwa dla klasy, do której należy dany obiekt.

Polimorfizm wymaga dynamicznego wiązania.

Przesłanianie jest jedną z jego form.

Polimorfizm stwarza znaczny potencjał dla ponownego użycia i modyfikowalności oprogramowania.


Zaleta polimorfizmu

W językach bez polimorfizmu:

W językach z polimorfizmem można zdefiniować niezależnie tyle procedur dochody, ile jest różnych klas obiektów.

Programiści tych metod nie muszą o sobie wiedzieć. Wzrasta przez to ponowne użycie i modyfikowalność oprogramowania.

TypWyniku TypWyniku dochodydochody( TypOsoby ( TypOsoby OsobaOsoba ) { ) {ifif Osoba.kategoriaOsoba.kategoria = ” = ”pracownikpracownik” ” thenthen

...... // obliczenie dochodów dla pracownika */...... // obliczenie dochodów dla pracownika */elseelse ifif Osoba.kategoriaOsoba.kategoria = ” = ”studentstudent” ” thenthen

...... // obliczenie dochodów dla studenta */...... // obliczenie dochodów dla studenta */elseelse ifif Osoba.kategoriaOsoba.kategoria = ” = ”emerytemeryt” ” thenthen

...... // obliczenie dochodów dla emeryta */...... // obliczenie dochodów dla emeryta */elseelse ...... ......

}; };


Przesłanianie

Przesłanianie dotyczy sytuacji, kiedy różne metody o tej samej nazwie m znajdują się w klasach powiązanych dziedziczeniem (nad-klasie i jej pod-klasie lub pod-klasach).

Po wysłaniu do obiektu będącego członkiem tych klas komunikatu m(...) wybierana jest metoda m znajdująca się najniżej w hierarchii tych klas. • Mówi się wtedy, że metoda ta przesłania

metodę dziedziczoną z nad-klasy.

PRACOWNIKnazwisko...zwolnij()...

Cz³onek Rady Zak³adowej

zwolnij()

PRACOWNIKnazwisko...zwolnij()...

Cz³onek Rady Zak³adowej

zwolnij()

overridingoverriding


Przeciążanie

Przeciążanie oznacza, że jakiś symbol (np. operatora, funkcji) ma znaczenie zależne od kontekstu jego użycia, np. od składni, ilości lub typu argumentów.

Powszechne jest przeciążanie operatora równości =, który służy do porównania liczb całkowitych, liczb rzeczywistych, stringów, identyfikatorów, struktur, itd. Podobnie, operator + może oznaczać dodawanie lub konkatenację.

Przeciążanie jest w gruncie rzeczy własnością z poziomu składni języka: jest ono odmianą homonimii, którą można rozstrzygnąć na podstawie kontekstu występowania homonimicznego elementu. • Znaczenie takiego „przeciążonego” symbolu można rozpoznać podczas

statycznej analizy tekstu programu.

• Przeciążanie może stać się środkiem wspomagającym wielokrotne użycie.

W nielicznych językach, np. w C++, przeciążanie jest udostępnione jako środek znajdujący się w rękach programisty.

overloadingoverloading


Dynamiczne role obiektów

Stanowią odpowiedź na problemy wielokrotnego dziedziczenia oraz innych anomalii (powtarzalnego dziedziczenia, wieloaspektowego dziedziczenia, obiektów historycznych, ekspolozji liczby klas, itd.).• Normalne dziedziczenie: student JEST osobą . Jest to błąd pojęciowy.

To raczej osoba STAJE SIĘ studentem, i to tylko na jakiś czas.

Każdy obiekt może nabywać i tracić wiele ról lub specjalizacji, nie zmieniając swojej tożsamości. Role zmieniają się dynamicznie.

PACJENT

CZŁONEK KLUBUPRACOWNIK

STUDENT PODATNIK

dane historyczne

OSOBA

STUDENTSTUDENT

dynamic roles


Dynamiczne role i klasy

OSOBANazwisko Abacka

RokUr 1948

OSOBA Nazwisko

RokUrWiek()

PRACOWNIKZarobek

DziałZarobekNetto()

ZmieńZarobek(..)

OSOBANazwisko Kowalska

RokUr 1975

STUDENTSemestr

NrIndeksuWpiszOcenę(...)

ObliczŚredniąOcen()

OSOBANazwisko Nowak

RokUr 1951

Klasy

OSOBANazwisko Nowacki

RokUr 1940

Obiekty

FIRMANazwa BankSA

pracuje_w pracuje_w

UCZELNIANazwa PW

studiuje_na

UCZELNIANazwa UW

studiuje_najest_klientem

PRACOWNIKZarobek 2500Dział Kredyty

PRACOWNIKZarobek 1500Dział Obsługa

STUDENTSemestr 7

NrIndeksu 223344

STUDENTSemestr 4

NrIndeksu 556677


Kolekcje

Kolekcje są zestawami danych o podobnej strukturze. Rozmiaru kolekcji nie można przewidzieć ani ograniczyć. Do kolekcji zaliczane są zbiory, relacje, wielozbiory, sekwencje, listy, drzewa, itp.

• Popularne języki programowania nie wprowadzają pojęcia kolekcji lub silnie je ograniczają (np. Java - sekwencja referencji).

• Brak kolekcji w językach programowania jest powodem niezgodności impedancji pomiędzy językiem programowania i językiem zapytań.

• Brak kolekcji jest powodem konieczności używania sterty (heap), co np. prowadzi do wyciekania pamięci.

Kolekcje mogą być zagnieżdżone (co jest najczęściej ignorowane przez teorie dotyczące obiektowych baz danych, np. obiektowe algebry).

• Relacje z modelu relacyjnego są przypadkiem kolekcji. Brak możliwości zagnieżdżania relacji jest utrudnieniem dla modelowania pojęciowego, ale zdaniem adwokatów modelu relacyjnego, upraszcza struktury danych i daje możliwość zastosowania matematyki. Są to poglądy kontrowersyjne.

collections


Przykład zagnieżdżonych kolekcji

XML stwarza nowy stosunek do kolekcji: kolekcje nie są nazywane, lecz są modelowane przez identyczne nazwy obiektów. Na podobnej zasadzie jak w XML, dynamiczne role pozwalają na tworzenie heterogenicznych, wzajemnie przecinających się

kolekcji - bez wprowadzania pojęcia kolekcji explicite.

Pracownicy

.....

PracownikZatrudnienia

.....

Zatrudnienie

Zatrudnienie

Stanowisko

Nazwisko

Dzieci...

Dziecko Dziecko

PracownikZatrudnienia

.....

Zatrudnienie

Zatrudnienie

Stanowisko

Nazwisko

Dzieci...

Dziecko Dziecko

nested collections


Operatory i konstrukcje do przetwarzania kolekcji

Operatory lub konstrukcje można pogrupować w dwie kategorie:• Operatory makroskopowe, których argumentem i wynikiem są kolekcje;• Operatory iteracyjne - kolejne przetwarzanie elementów kolekcji.

Przykładowe operatory nie iteracyjne mogą być następujące: Dla bagów:

• suma bagów, przecięcie bagów, różnica bagów, usunięcie duplikatów z bagów, rozmiar bagu, dostawienie elementu do bagu, itd.

Dla sekwencji (podobnie dla tablic):• konkatenacja sekwencji, i-ty element, rozmiar, zawieranie się, usunięcie i-

tego elementu, sortowanie sekwencji. Niektóre operatory wymagają zdefiniowania dodatkowego operatora,

który ustali co to znaczy, że dwa elementy kolekcji są identyczne. Wyróżnia się dwa przypadki:• Porównanie płytkie: obiekty są identyczne jeżeli ich identyfikatory są

identyczne• Porównanie głębokie: obiekty są identyczne, jeżeli reprezentują identyczne

drzewa etykietowanych wartości.


Wartości zerowe

Zwykle są oznaczane jako NULL lub NIL. Istnieje wiele przyczyn powstawania wartości zerowych, np.:

• Atrybut nie ma zastosowania dla danego przypadku, np. NazwiskoPanieńskie;

• Informacja jest nieznana, np. miejsce, gdzie został pochowany Mozart;

• Informacja o przyszłości, np. wynik przyszłego meczu piłkarskiego;

• Informacja jeszcze nie zapełniona.

Większość przyczyn powstawania wartości zerowych można określić jako skutek nieregularnych w danych, które nie chcą się zmieścić w formacie.

Wartości zerowe okazały się trudne dla interfejsów programistycznych, rodząc dużą liczbę anomalii, które są nie do usunięcia. • Liczne patologie w SQL.

XML postępuje z wartościami zerowymi bardzo prosto: daną z wartością zerową po prostu się pomija, razem z tagami.• Ten sposób można uważać za najlepszy i podnieść do rangi zasady. Implikuje

on pewne (raczej drobne) problemy dla mocnej kontroli typów.

null values


Warianty (unie)

Warianty (unie) są nieregularnościami w strukturach danych. Służą do odwzorowania takich sytuacji, kiedy wystąpienia danej określonego typu mogą się różnić zestawem lub typem atrybutów.

Pracownik:( Nazwisko:”Nowak”, Rodzaj:”etatowy”, Zarobek:3000 )

Pracownik:( Nazwisko:”Wrona”, Rodzaj:”uczeń”, Status:3, Stypendium:700 )• Ta sytuacja jest modelowana jako „zapis z wariantami” (w rodzinie języków

linii Pascala) lub unia (w rodzinie C i C++); np. (w składni C):

struct{ string Nazwisko; string Rodzaj;

union{ int Zarobek;

struct{ int Status; int Stypendium;} str;} un; } Pracownik;

• Warianty mogą posiadać wyróżniony atrybut, tzw. dyskryminator, który służy do rozróżnienia podczas wykonania, z którym przypadkiem mamy do czynienia.

Wariant jest pojęciem podobnym do wartości zerowej ale nieco różnym. Np. jeżeli pewien zapis ma 10 atrybutów, które mogą przyjmować wartości zerowe, wówczas liczba wariantów wynosi 210 = 1024.

variants, unions


Dane pół-strukturalne Dane pół-strukturalne są nieregularne, nie mają stałego formatu. Mogą nie podlegać mocnej kontroli typu. Mogą nie posiadać schematu, lub ich schemat jest luźny. Są nowym podejściem do wartości zerowych i wariantów.

Dane pół-strukturalne są typowe dla zastosowań Webowych.• Przykładem danych półstrukturalnych są pliki XML.

Dane pół-strukturalne implikują nowe problemy dla języków zapytań.• Wymagają nowych podejść i/lub nowych operatorów.

• Implikują nowe problemy co do opisu ontologii biznesowej.

semistructured data

Osoba( Pseudonim( "Masa") Kwalifikacja( "kryminalista") Przestępstwo( "rozbój") Przestępstwo( "włamanie"))

Osoba( Nazwisko( "Nowak") Imię( "Jan") Imię( "Antoni") Zawód("piekarz") )

Osoba( Nazwisko( "Kruk") Stopień("kapral") Jednostka("artyleria") )


Trwałość

Byt programistyczny jest trwały, jeżeli żyje dłużej niż trwa czas działania programu, który go używa • Wszystko, co zawierają bazy danych, jest trwałe.

Trwałą zmienną jest zmienna programistyczna, która ma wszystkie własności normalnej zmiennej, ale której wartość przy nowym uruchomieniu programu jest taka sama, jak przy zakończeniu poprzedniego uruchomienia programu.

Popularne języki programowania (C, C++, Smalltalk, Pascal, Java,...) nie mają trwałych zmiennych / trwałych obiektów.

Istnieją prototypowe języki/systemy z trwałością (DBPL, Napier88, PS-Algol, Galileo, Fibonacci, Loqis,... )

Trwałość jest także dobudowywana do języka Java (Pjama) lub jest cechą technologii, np. EJB, ADO.

Trwałość wymaga niezależnego od danej aplikacji repozytorium (bazy danych).

persistence


Rodzaje trwałości

Trwałość poprzez osiągalność: Obiekt trwały nie może mieć nietrwałych pod-obiektów lub atrybutów, ani też nie może zawierać pointera prowadzącego do obiektu nietrwałego. • Wszystkie obiekty trwałe i ich atrybuty są osiągalne z jednego „trwałego

korzenia”.

Trwałość poprzez dziedziczenie: specjalne klasy z cechą trwałości, wszystkie klasy potomne są klasami z trwałością.• Konieczne są duplikaty klas/typów dla tych samych trwałych i nietrwałych

obiektow

Trwałość poprzez utworzenie: podczas tworzenia programista ustala, czy tworzony obiekt ma być trwały.

Ortogonalna trwałość.


Ortogonalna trwałość

Tradycyjnie, bazy danych przechowywały wyłącznie typy trwałe i masowe (zbiory, relacje, etc.).

Podobnie, klasyczne języki programowania zajmowały się wyłącznie typami indywidualnymi i nietrwałymi (zmienne, struktury, zapisy, etc.).

Taki podział nie ma uzasadnienia. Niekiedy niezbędne jest zapamiętanie w bazie danych pojedynczych wartości; np. adresu firmy, w której jest zainstalowany system. Brak typów masowych w językach programowania ma liczne wady.

Zasada ortogonalnej trwałości oznacza nowy typ języka programowania, w którym cecha trwałości jest ortogonalna w stosunku do konstruktorów struktur danych.

Oznacza to m.in., że języki zapytań w równym stopniu dotyczą:

• trwałych i nietrwałych danych: są ortogonalne w stosunku do trwałości,

• kolekcji i indywidualnych danych: są ortogonalne w stosunku do masowości.

orthogonal persistence


Moduły

W modularnych językach programowania, takich jak Modula-2, moduł oznacza fragment programu stanowiący jednostkę przechowywania, kompilacji i konsolidacji (linking) programów.

Moduł podlega regułom hermetyzacji oddzielającym specyfikację modułu od jego implementacji.

Specyfikacja modułu zawiera tzw. listy eksportowe i importowe. • Lista eksportowa jest odpowiednikiem pojęcia interfejsu znanego ze

standardu CORBA, standardu ODMG i języka Java.

• Lista importowa określa obiekty innych modułów, które można użyć w danym module - skuteczny środek kontroli efektów ubocznych modułu.

Z punktu widzenia koncepcji obiektowości, moduł jest obiektem, który wewnątrz może zawierać obiekty oraz inne własności, takie jak typy lub klasy.

Moduły nie wprowadzają w zasadzie nowej jakości dla obiektowych języków zapytań.

module

obiektowe języki zapytań

Documents