Obiektowe języki zapytań

1. Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 04 Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja (2)

2. Klasa class • 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ę.

3. 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);

4. 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 (integrityconstraints). • Reguły bezpieczeństwa i prywatności. • Informacje katalogowe, pomoce.

5. Interfejs interface • 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.

6. Hierarchia klas i dziedziczenie class hierarchy, inheritance • 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ń.

7. Przykład klas i dziedziczenia obiekt obiekt obiekt obiekt obiekt obiekt obiekt obiekt obiekt OSOBA Nazwisko Imię RokUrodz Wiek() STUDENT NrIndeksu RokStudiów Wydział WstawOcenę(...) ZaliczSemestr() PRACOWNIK Zarobek Firma Zdjęcie ZarobekNetto() ZmieńZarobek(...)

8. 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.

9. Ekstensja klasy OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) extent • 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. OSOBA Nazwisko Kowalska RokUr 1975 Ekstensja klasy OSOBA OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko Abacki RokUr 1948 OSOBA Nazwisko Babacki RokUr 1940 PRACOWNIK Nazwisko Nowak RokUr 1951 Zarobek 2000 Dział zabawki PRACOWNIK Nazwisko Babacki RokUr 1940 Zarobek 3000 Dział sprzedaż PRACOWNIK Nazwisko Abacki RokUr 1948 Zarobek 2500 Dział zabawki Ekstensja klasy PRACOWNIK

10. 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).

11. Zasada zamienialności substitutability • 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.

12. Wielokrotne dziedziczenie POJAZD ciężar ..... prędkość_eksploat() POJAZD_WODNY wyporność max_prędkość ..... POJAZD_LĄDOWY ilość_kół max_prędkość ..... AMFIBIA ŻAGLÓWKA JACHT SAMOCHÓD TRAKTOR multiple inheritance multi-inheritance • Jest to dziedziczenie z kilku klas, z zsumowaniem dziedziczonych cech. • Problemem wielo-dziedziczenia jest konieczność rozstrzygnięcia konfliktów nazw.

13. 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.

14. Abstrakcyjne typy danych, ADT abstract data type • 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.

15. 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. 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. STUDENT .... dochody() .... PRACOWNIK .... dochody() .... EMERYT .... dochody() .... polymorphism OSOBA nazwisko kategoria .... .... obiekt obiekt obiekt obiekt obiekt obiekt

16. 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 dochody( TypOsoby Osoba ) { ifOsoba.kategoria = ”pracownik” then ...... // obliczenie dochodów dla pracownika */ elseifOsoba.kategoria = ”student” then ...... // obliczenie dochodów dla studenta */ elseifOsoba.kategoria = ”emeryt” then ...... // obliczenie dochodów dla emeryta */ else ...... };

17. Przesłanianie overriding • 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.

18. Przeciążanie overloading • 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.

19. Dynamiczne role obiektów dynamic roles • Stanowią odpowiedź na problemy wielokrotnego dziedziczenia oraz innych anomalii (powtarzalnego dziedziczenia, wieloaspektowego dziedziczenia, obiektów historycznych, ekspolozji liczby klas, itd.). • Normalne dziedziczenie: studentJESTosobą . 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. OSOBA PRACOWNIK CZŁONEK KLUBU PODATNIK STUDENT STUDENT PACJENT STUDENT dane historyczne

20. Dynamiczne role i klasy OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(..) STUDENT Semestr NrIndeksu WpiszOcenę(...) ObliczŚredniąOcen() Klasy OSOBA NazwiskoAbacka RokUr1948 OSOBA NazwiskoKowalska RokUr1975 OSOBA NazwiskoNowak RokUr1951 OSOBA NazwiskoNowacki RokUr1940 PRACOWNIK Zarobek2500 DziałKredyty PRACOWNIK Zarobek1500 DziałObsługa Obiekty STUDENT Semestr7 NrIndeksu223344 STUDENT Semestr4 NrIndeksu556677 jest_klientem pracuje_w pracuje_w studiuje_na studiuje_na FIRMA NazwaBankSA UCZELNIA NazwaPW UCZELNIA NazwaUW

21. Kolekcje collections • 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.

22. Przykład zagnieżdżonych kolekcji nested collections • 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 Pracownik Pracownik Zatrudnienia Zatrudnienia Nazwisko Nazwisko Zatrudnienie Zatrudnienie ..... Dzieci Dzieci ... ... Dziecko Dziecko Dziecko Dziecko Zatrudnienie Zatrudnienie Stanowisko Stanowisko ..... .....

23. 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.

24. Wartości zerowe null values • 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.

25. Warianty (unie) variants, unions • 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{ stringNazwisko; stringRodzaj; union{ intZarobek; struct{ intStatus; intStypendium;} 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.

26. Dane pół-strukturalne semistructured data • 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. 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") )

27. Trwałość persistence • 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).

28. 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ść.

29. Ortogonalna trwałość orthogonal persistence • 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.

30. Moduły module • 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ń.