Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

© K.Subieta. Podejście stosowe 03, Folia 1 Podejście stosowe do obiektowych języków programowania baz danych Wykład 03 Pojęcia obiektowości w bazach danych.

Podobne prezentacje


Prezentacja na temat: "© K.Subieta. Podejście stosowe 03, Folia 1 Podejście stosowe do obiektowych języków programowania baz danych Wykład 03 Pojęcia obiektowości w bazach danych."— Zapis prezentacji:

1 © K.Subieta. Podejście stosowe 03, Folia 1 Podejście stosowe do obiektowych języków programowania baz danych Wykład 03 Pojęcia obiektowości w bazach danych (2) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2 © K.Subieta. Podejście stosowe 03, Folia 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

3 © K.Subieta. Podejście stosowe 03, Folia 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 © K.Subieta. Podejście stosowe 03, Folia 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 (integrity constraints). Reguły bezpieczeństwa i prywatności. Informacje katalogowe, pomoce.

5 © K.Subieta. Podejście stosowe 03, Folia 5 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

6 © K.Subieta. Podejście stosowe 03, Folia 6 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

7 © K.Subieta. Podejście stosowe 03, Folia 7 Przykład klas i dziedziczenia PRACOWNIK Zarobek Firma Zdjęcie ZarobekNetto() ZmieńZarobek(...) STUDENT NrIndeksu RokStudiów Wydział WstawOcenę(...) ZaliczSemestr() OSOBA Nazwisko Imię RokUrodz Wiek() obiekt

8 © K.Subieta. Podejście stosowe 03, Folia 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 © K.Subieta. Podejście stosowe 03, Folia 9 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. OSOBA Nazwisko Babacki RokUr 1940 OSOBA Nazwisko Abacki RokUr 1948 OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) OSOBA Nazwisko Kowalska RokUr 1975 Ekstensja klasy OSOBA PRACOWNIK Nazwisko Nowak RokUr 1951 Zarobek 2000 Dział zabawki PRACOWNIK Nazwisko Abacki RokUr 1948 Zarobek 2500 Dział zabawki PRACOWNIK Nazwisko Babacki RokUr 1940 Zarobek 3000 Dział sprzedaż Ekstensja klasy PRACOWNIK extent

10 © K.Subieta. Podejście stosowe 03, Folia 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 © K.Subieta. Podejście stosowe 03, Folia 11 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

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

13 © K.Subieta. Podejście stosowe 03, Folia 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ć patologie.

14 © K.Subieta. Podejście stosowe 03, Folia 14 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

15 © K.Subieta. Podejście stosowe 03, Folia 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. polymorphism obiekt STUDENT.... dochody().... PRACOWNIK.... dochody().... EMERYT.... dochody().... obiekt OSOBA nazwisko kategoria.... dochody() 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.

16 © K.Subieta. Podejście stosowe 03, Folia 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 ) { if Osoba.kategoria = pracownik then // obliczenie dochodów dla pracownika */ else if Osoba.kategoria = student then // obliczenie dochodów dla studenta */ else if Osoba.kategoria = emeryt then // obliczenie dochodów dla emeryta */ else };

17 © K.Subieta. Podejście stosowe 03, Folia 17 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. overriding

18 © K.Subieta. Podejście stosowe 03, Folia 18 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. overloading

19 © K.Subieta. Podejście stosowe 03, Folia 19 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 KLUBU PRACOWNIK STUDENT PODATNIK dane historyczne OSOBA STUDENT dynamic roles

20 © K.Subieta. Podejście stosowe 03, Folia 20 Dynamiczne role i klasy OSOBA Nazwisko Abacka RokUr 1948 OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(..) OSOBA Nazwisko Kowalska RokUr 1975 STUDENT Semestr NrIndeksu WpiszOcenę(...) ObliczŚredniąOcen() OSOBA Nazwisko Nowak RokUr 1951 Klasy OSOBA Nazwisko Nowacki RokUr 1940 Obiekty FIRMA Nazwa BankSA pracuje_w UCZELNIA Nazwa PW studiuje_na UCZELNIA Nazwa UW studiuje_najest_klientem PRACOWNIK Zarobek 2500 Dział Kredyty PRACOWNIK Zarobek 1500 Dział Obsługa STUDENT Semestr 7 NrIndeksu STUDENT Semestr 4 NrIndeksu

21 © K.Subieta. Podejście stosowe 03, Folia 21 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

22 © K.Subieta. Podejście stosowe 03, Folia 22 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..... Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko nested collections

23 © K.Subieta. Podejście stosowe 03, Folia 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 © K.Subieta. Podejście stosowe 03, Folia 24 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

25 © K.Subieta. Podejście stosowe 03, Folia 25 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 2 10 = variants, unions

26 © K.Subieta. Podejście stosowe 03, Folia 26 Dane pół-strukturalne Dane pół-strukturalne są nieregularne, nie mają stałego formatu. Mogą nie podlegać mocnej kontroli typów. 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") )

27 © K.Subieta. Podejście stosowe 03, Folia 27 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, ODRA,... ) 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

28 © K.Subieta. Podejście stosowe 03, Folia 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 © K.Subieta. Podejście stosowe 03, Folia 29 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

30 © K.Subieta. Podejście stosowe 03, Folia 30 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


Pobierz ppt "© K.Subieta. Podejście stosowe 03, Folia 1 Podejście stosowe do obiektowych języków programowania baz danych Wykład 03 Pojęcia obiektowości w bazach danych."

Podobne prezentacje


Reklamy Google