Obiektowe języki zapytań
-
Upload
jin-booker -
Category
Documents
-
view
22 -
download
0
description
Transcript of 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)
© K.Subieta. Obiektowe języki zapytań 04, Folia 2 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 3 marzec 2004
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);
© K.Subieta. Obiektowe języki zapytań 04, Folia 4 marzec 2004
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.
© K.Subieta. Obiektowe języki zapytań 04, Folia 5 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 6 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 7 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 8 marzec 2004
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.
© K.Subieta. Obiektowe języki zapytań 04, Folia 9 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 10 marzec 2004
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).
© K.Subieta. Obiektowe języki zapytań 04, Folia 11 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 12 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 13 marzec 2004
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.
© K.Subieta. Obiektowe języki zapytań 04, Folia 14 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 15 marzec 2004
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.
© K.Subieta. Obiektowe języki zapytań 04, Folia 16 marzec 2004
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 ...... ......
}; };
© K.Subieta. Obiektowe języki zapytań 04, Folia 17 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 18 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 19 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 20 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 21 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 22 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 23 marzec 2004
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.
© K.Subieta. Obiektowe języki zapytań 04, Folia 24 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 25 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 26 marzec 2004
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") )
© K.Subieta. Obiektowe języki zapytań 04, Folia 27 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 28 marzec 2004
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ść.
© K.Subieta. Obiektowe języki zapytań 04, Folia 29 marzec 2004
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
© K.Subieta. Obiektowe języki zapytań 04, Folia 30 marzec 2004
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