Obiektowe języki zapytań 1..5 - Katedra Inżynierii Oprogramowania

Obiektowe języki zapytań
Wykładowca: Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
[email protected]
Wykłady 1..5
Instytut Podstaw Informatyki PAN,
Warszawa
[email protected]
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 1
kwiecień 2002
Plan wykładów 1..5
Cel tej serii wykładów - objaśnienie podejścia stosowego do
obiektowych języków zapytań






Generalne założenia podejścia stosowego
Wprowadzenie do języków zapytań
Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja
Podstawy semantyczne języków zapytań
Modele składu obiektów - M0, M1, M2 i M3
Stos środowisk i wiązanie nazw
Dalsze wykłady 6..10 z tej serii będą poświęcone językowi SBQL, oraz konstrukcjom
imperatywnym i perspektywom bazującym na SBQL.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 2
kwiecień 2002
Wykład 1
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 3
kwiecień 2002
Generalne założenia podejścia stosowego
stack-based approach, SBA
 Niniejszy wykład teorii i konstrukcji obiektowych języków zapytań
będzie opierał się na podejściu stosowym, SBA.
 Podejście stosowe zakłada, że języki zapytań są szczególnym
przypadkiem języków programowania.
 Stąd teorie języków programowania są bardziej adekwatne niż podejścia
takie jak algebra relacyjna, rachunek relacyjny lub logika matematyczna.
 W podejściu stosowym kluczową rolę odgrywa stos środowisk
(environment stack), który jest podstawowym mechanizmem praktycznie
wszystkich popularnych języków programowania.
 Jego rolą jest określenie zakresów nazw (scoping), wiązanie nazw
(binding) oraz wprowadzenie dyscypliny w zakresie alokowania
dynamicznych bytów programistycznych, w szczególności lokalnych
danych (obiektów) i parametrów procedur.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 4
kwiecień 2002
Zalety podejścia stosowego
 Oparcie semantyki języków zapytań na mechanizmie stosu środowisk
umożliwia precyzyjne wyjaśnienie ich semantyki.
 Inne podejścia do semantyki obiektowych języków zapytań są wadliwe:
• Podstawy teoretyczne (np. algebra relacji, algebry obiektowe) nie obejmują
wszystkich konstrukcji spotykanych w językach zapytań.
• Posiadają zasadnicze wady koncepcji, są semantycznie nieprecyzyjne.
• Nie dają bezpośredniej możliwości rozszerzeń: uwzględnienia pojęć
obiektowości (klasy, dziedziczenie, hermetyzacja), konstrukcji
imperatywnych (update, insert, delete), abstrakcji BD (perspektywy,
procedury BD, funkcje, trygery, komunikowanie parametrów).
 SBA pozwala na włączenie do konstruowanego języka wszystkich pojęć
obiektowości oraz dowolnych konstrukcji i abstrakcji imperatywnych.
 Podejście jest bezpośrednio implementowalne. Przedstawiony będzie
SBQL (Stack-Based Query Language) oparty na SBA i zrealizowany w
prototypowym systemie Loqis.
 Podejście jest optymalizowalne przy pomocy generalnych metod.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 5
kwiecień 2002
Wprowadzenie do języków zapytań
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 6
kwiecień 2002
Ogólna charakterystyka języków zapytań
query languages
 Języki zapytań (query languages) tworzą relatywnie nową dziedzinę
informatyki, która (jak dotąd) jest związana z tematyką baz danych.
 Językiem zapytań dla relacyjnych baz danych jest SQL.
 Wielu specjalistów uważa, że SQL jest źródłem komercyjnego sukcesu
całej technologii relacyjnych baz danych.
 Pozycja SQL jako czołowego języka dla relacyjnych baz danych została
wzmocniona przez standardy ANSI (American National Standard
Institute) oraz ISO (International Standard Organization): SQL-89 oraz
SQL-92. Obecnie trwają prace nad standardem SQL3 i nowszymi
wersjami SQL 1999, SQL 2000,....
 SQL stał się podstawą lub uzupełnieniem wielu produktów, np. języków
czwartej generacji (4GL), narzędzi RAD, języków programowania np.
Oracle PL/SQL oraz różnych API, w szczególności ODBC i JDBC.
 Najbardziej znanym obiektowym językiem zapytań jest ODMG OQL.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 7
kwiecień 2002
Czy przyszłością języków zapytań jest SQL/OQL?
 Obie propozycje są kontrowersyjne.
 SQL3 - SQL1999 - SQL2000 są krytykowane za eklektyzm, wszystkoizm
i przypadkowość decyzji w zakresie konstrukcji językowych, co owocuje
monstrualną specyfikacją (ponad 1000 stron, plus dodatki).
 Jest wątpliwe, aby ktokolwiek zaimplementował te języki w całości.
 OQL jest językiem znacznie mniejszym, ze specyfikacją mieszczącą się
na kilkudziesięciu stronach, ale pozwala wyłącznie na wyszukiwanie
danych. Brakuje perspektyw, zapamiętanych procedur, itd.
 Co za tym idzie, programowanie w OQL wymaga zanurzenia zapytań w
uniwersalny język programowania: C++, Smalltalk i Java.
 Zanurzenie języka zapytań w uniwersalny język programowania ma złą
sławę określaną jako „niezgodność impedancji”.
 Obie propozycje cechuje niespójność (i w gruncie rzeczy, brak istotnej
koncepcji) w zakresie semantyki.
 Co za tym idzie, optymalizacja zapytań stoi pod znakiem zapytania.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 8
kwiecień 2002
Czy warto zabiegać o precyzyjną semantykę?
 Brak precyzyjnej semantyki jest powszechny dla nowo powstających
języków programowania.
 W przypadku języków zapytań sytuacja jest odmienna w porównaniu do
klasycznych języków programowania.
 Języki zapytań są dramatycznie nieefektywne (praktycznie
nieakceptowalne) w przypadku braku automatycznej optymalizacji.
 Optymalizacja oznacza zamianę zapytania q1, którego czas wykonania jest
dramatycznie długi (np. tysiąc lat), na semantycznie równoważne
zapytanie q2 posiadające akceptowalny czas wykonania (np. 5 sekund).
 Powoduje to konieczność ustalenia, co to znaczy „semantycznie
równoważne zapytanie”. Jest to niemożliwe bez precyzyjnej formalizacji
zarówno danych, na których operują zapytania, jak i semantyki
operatorów występujących w zapytaniach.
 Uzyskanie pełnej jasności i precyzji opisu semantyki obiektowych
języków zapytań jest celem podejścia stosowego.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 9
kwiecień 2002
Co to są "języki zapytań"?
Istnieje na ten temat wiele poglądów, np.:
 Proste, przyjacielskie i naturalne interfejsy dla powszechnego
użytkownika do interakcyjnego formułowania zleceń wyszukiwania w
bazie danych lub jej aktualizacji przez mało doświadczonego
użytkownika. W tej roli znacznie lepsze od SQL są interfejsy graficzne
oparte o okienka, menu, formularze, tabele, przeglądanie, itp.
 Syntaktyczne warianty języków pewnych sławnych matematycznych
teorii, np. logiki. Ten punkt widzenia był lansowany przez teoretyków baz
danych. Obecne języki zapytań zaprzeczają tego rodzaju poglądom.
 Pod-języki bardzo wysokiego poziomu (API) zanurzane w typowe
języki programowania do wyszukiwania i aktualizacji bazy danych. W
tej roli najczęściej występuje SQL. Liczne wady tego podejścia.
 Wyrażenia programistyczne bardzo wysokiego poziomu zintegrowane
z językiem programowania. Tworzą kompletny interfejs do
programowania aplikacji. Przykładem jest PL/SQL systemu Oracle.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 10
kwiecień 2002
Języki zapytań jako wyrażenia programistyczne
 Ostatni punkt widzenia zakłada nowy rodzaj języka programowania, w
którym występują specyficzne wyrażenia (podobne do klasycznych
wyrażeń języka oprogramowania) zwane „zapytaniami”.
 Istotą tych nowych wyrażeń jest obsługa kolekcji.
 W tej roli języki zapytań są wyższym szczeblem abstrakcji nad
konstrukcjami organizującymi pętle (while, repeat, goto, for, loop, itp.),
iteratorami, kursorami i innymi tego rodzaju udogodnieniami.
 Zapytania koncepcyjnie „hermetyzują” pętle iteracyjne w języku
programowania przy pomocy operatorów takich jak selekcja (where),
projekcja, złączenie, unia, kwantyfikatory, grupowanie, sortowanie, itp.
 Słowo „koncepcyjnie” jest tu istotne, gdyż chodzi o taką hermetyzację,
która jest naturalna, zrozumiała i czytelna dla programisty; wspomagająca
procesy modelowania pojęciowego przy tworzeniu aplikacji.
 W tej koncepcji języki zapytań są tworami całkowicie ortogonalnymi w
stosunku do cechy trwałości danych (czyli bazy danych).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 11
kwiecień 2002
Znaczenie języków zapytań
 Obniżenie poziomu profesjonalizmu niezbędnego do programowania
aplikacji baz danych. W tradycyjnych językach programowania aplikacje
te wymagają profesjonalnych, wysoko opłacanych programistów.
 Podwyższenie wydajności programistów poprzez dostarczenie do ich
dyspozycji pojęciowych, makroskopowych operacji, pozwalających
zapisać złożone przetwarzanie w zwartej, czytelnej i zrozumiałej formie.
• Jedno zdanie w SQL może zastąpić kilka stron programu napisanego w
językach takich jak Cobol, C lub Pascal.
• Ma to skutki dla tempa tworzenia oprogramowania, jego kosztu,
pielęgnacyjności i modyfikowalności.
 Podwyższenie niezawodności produktów programistycznych poprzez
zwartość zapisu programu i konceptualizację myślenia programisty.
 Zwolnienie projektanta i programisty z myślenia o mniej istotnych
sprawach implementacyjnych, umożliwienie skupienia się na tym co ma
być zrobione, a nie jak; myślenie w kategoriach problemu i dziedziny
zastosowań, a nie w w kategoriach detali i sztuczek implementacyjnych.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 12
kwiecień 2002
Zastosowania języków zapytań (1)
 Narzędzie dla powszechnego użytkownika umożliwiające interakcyjne
zapytania i aktualizacje (tzw. ad hoc), z generacją odpowiedzi lub
raportów w pewnych z góry zadanych formatach.
 Konstrukcje języka programowania umożliwiające programowanie na
bardzo wysokim poziomie abstrakcji i konceptualizację programów.
 Definiowanie ograniczeń integralnościowych (integrity constraints),
inaczej więzów integralności, zapobiegających niedopuszczalnym
operacjom na bazie danych lub wykrywających błędy w danych.
 Definiowanie podschematów, ograniczeń dostępu i innych środków
autoryzacji lub bezpieczeństwa danych.
 Definiowanie wirtualnych perspektyw (views), zmaterializowanych
perspektyw (materialized views), danych pochodnych (derived), replikacji
danych, procedur zapamiętanych w bazie danych (stored procedures,
database procedures), i innych abstrakcji lub udogodnień w danych.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 13
kwiecień 2002
Zastosowania języków zapytań (2)
 Składowe konstrukcji językowych skryptów (scripts) w językach czwartej
generacji (4GL) i narzędziach do prototypowania (RAD).
 Definiowanie aktywnych reguł, dedukcyjnych reguł, aktywnych agentów i
innych „inteligentnych" elementów w bazie danych.
 Określanie danych do transmisji w rozproszonych bazach danych;
umożliwienie współpracy pomiędzy heterogenicznymi i/lub odległymi
bazami danych (np. interfejsy w stylu ODBC lub JDBC).
 Określanie danych do transmisji pomiędzy różnymi rodzajami pamięci,
np. pomiędzy pamięcią optyczną typu jukebox a pamięcią dyskową.
 Narzędzia do wyszukiwania informacji w danych pół-strukturalnych
(semi-structured), np. w plikach XML lub RDF; definiowanie perspektyw
nad danymi pół-strukturalnymi.
 Narzędzia do eksploracja danych (data mining), hurtowni danych i
analitycznego przetwarzania (OLAP).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 14
kwiecień 2002
Własności języków zapytań (1)
 Wysoki poziom konceptualizacji i abstrakcji; niezależność danych
(data independence) wyrażająca się w braku odwołań do elementów
fizycznej organizacji danych (takich jak np. indeksy). Użytkownik
formułuje zapytanie znając wyłącznie logiczny schemat bazy danych.
 Nieproceduralność lub deklaracyjność, wyrażająca się w zorientowaniu
języka na formułowanie bezpośrednio celu wyszukiwania, a nie środków
prowadzących do tego celu.
 Makroskopowość, czyli jednoczesne działanie (z punktu widzenia
użytkownika) na wielu elementach kolekcji o nieznanych rozmiarach.
 Naturalność, czyli wspomaganie naturalnych schematów myślenia
użytkownika, wspomaganie modelowania pojęciowego, łatwość uczenia
się i użycia.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 15
kwiecień 2002
Własności języków zapytań (2)
 Efektywność, czyli akceptowalne czasy wykonania zapytań. Oznacza to
konieczność stosowania automatycznych metod optymalizacyjnych.
• To zaś oznacza konieczność określenia jednorodnej koncepcji i zdefiniowania
precyzyjnej semantyki języka, bez pomijania jakichkolwiek detali.
• Dla złożonego problemu automatyczna optymalizacja zapytań jest bardziej
skuteczna od manualnego zakodowania tego samego zadania w języku
niskiego poziomu, np. w C.
 Uniwersalność, czyli zdolność języka zapytań do definiowania
dowolnych operacji wyszukiwania i kojarzenia danych.
• Ta własność jest słabą stroną SQL.
• Kryteria dla określenia stopnia uniwersalności języków zapytań są ułomne.
Tzw. „relacyjna kompletność” (relational completeness) jest przypadkowym,
nie umotywowanym punktem na skali uniwersalności. Tzw. "kompletność
Turinga" (Turing completeness) jest oparta na pseudo-argumentach.
• Uniwersalność jest kategorią pragmatyczną, a nie matematyczną.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 16
kwiecień 2002
Własności języków zapytań (3)
 Niezależność od dziedziny zastosowań, czyli brak przypisania do jednej
dziedziny aplikacyjnej, umożliwienie realizacji wszystkich potencjalnych
zastosowań danego systemu zarządzania bazą danych.
 Wykonywanie zapytań w trybie interpretacyjnym, późne (dynamiczne)
wiązanie, brak fazy kompilacji i konsolidacji zapytań z całością aplikacji.
Umożliwia to zapytania ad hoc, dynamiczne tworzenie i usuwanie
perspektyw, zapamiętywanie procedur i reguł w bazie danych,
dynamiczne tworzenie i usuwanie indeksów, itd.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 17
kwiecień 2002
Zasady języków zapytań (1)
Ostatnio, zasady wypracowane przez świat akademicki są kwestionowane
przez świat przemysłowy. Wynika to z faktu, że dla firm komercyjnych jest
bardzo niewygodne stwierdzenie, że jakaś cecha ich produktu jest
"niezgodna z zasadą". Kwestionuje się więc zasadę.
Zadaniem świata akademickiego jest obrona zasad.
Niżej są podane podstawowe zasady obowiązujące języki zapytań.
 Naturalność: zgodność z naturalnym myśleniem potencjalnych
użytkowników. Niekoniecznie oznacza ona wyrażanie zapytań w języku
naturalnym (ponieważ jest on zbyt mało precyzyjny).
 Prostota: klarowność konstrukcji syntaktycznych, oczywistość
semantyki, łatwość uczenia się i nauczania, łatwość dokumentowania,
implementacji, pielęgnowania i użycia.
 Ortogonalność: każda kombinacja cech języka, która ma sens, powinna
być dozwolona. Ortogonalność pozwala na zredukowanie do minimum
definicji języka oraz znaczne podwyższenie jego mocy.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 18
kwiecień 2002
Zasady języków zapytań (2)
 Kompozycyjność: unikanie dużych zlepków syntaktycznych i zależności
pomiędzy odległymi kontekstowo fragmentami wyrażeń języka.
 Relatywizm: identyczna składnia i semantyka wyrażeń języka
odnoszących się do dowolnego poziomu zagnieżdżenia struktur danych.
Np. zapytania odnoszące się do całej bazy danych i odnoszące się do
wnętrza pojedynczego obiektu (które może zawierać podobiekty) powinny
być konstruowane na tych samych zasadach.
 Minimalność (brzytwa Occama): unikanie cech redundantnych. Dotyczy
to zarówno redundantnej składni, jak i wprowadzania takich konstrukcji
językowych, które można łatwo zastąpić przez inne konstrukcje.
 Brak anomalii: unikanie specjalnych przypadków, cech wyjątkowych,
nieregularnego traktowania, itd. Wszystkie takie cechy stają się przyczyną
błędów oraz zwiększają objętość dokumentacji języka. Szczególnie
groźne są tzw. semantyczne rafy, które powodują błędny (nieoczekiwany)
wynik bez ostrzeżeń.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 19
kwiecień 2002
Zasady języków zapytań (3)
 Uniwersalność: język powinien w maksymalnym stopniu przykrywać
dziedzinę, do której został przeznaczony. Chodzi o uniwersalność
pragmatyczną, czyli spełnienie wszystkich aktualnych (i rozsądnych)
oczekiwań użytkowników na dzisiaj i na przewidywaną przyszłość.
 Modularność (hermetyzacja): umożliwienie użytkownikowi zamykania
fragmentów języka w nazwane, hermetyzowane bryły, którymi można
dalej posługiwać się tak jak atomami. Zmiana kontekstu użycia takich brył
nie powinna prowadzić do zmiany ich znaczenia.
 Bezpieczeństwo: wzbogacenie języka o specjalne środki (takie jak
deklarowanie typów, asercje, więzy integralności, transakcje)
przeciwdziałające niepoprawnemu użyciu konstrukcji języka,
prowadzących do naruszenia integralności bazy danych lub integralności
przetwarzania.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 20
kwiecień 2002
Zasady języków zapytań (4)
 Specjalna troska o przypadki skrajne: puste zbiory, puste stringi,
wartości zerowe, niezainicjowane zmienne, itd. są bardzo często nie objęte
definicją semantyki języka, co powoduje rezultaty nie oczekiwane przez
użytkowników.
 Koncepcyjna kontynuacja: mała zmiana celu, dla którego budowane jest
wyrażenie języka, nie powinno wywoływać dramatycznej zmiany w
myśleniu użytkownika i w formie tego wyrażenia.
 Jednorodne podejście do konstrukcji programistycznych bazujących
na języku zapytań (zdania imperatywne, perspektywy, procedury, metody,
parametry procedur i metod, itd.).
 Nie zaniedbywanie jakiegokolwiek problemu semantycznego.
• Każdy, nawet najmniejszy problem semantyczny jest dużym
problemem.
 Wysoki potencjał dla optymalizacji zapytań.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 21
kwiecień 2002
Optymalizacja zapytań
query optimization
 Opracowanie sprawnych metod optymalizacji jest fundamentalnym
problemem w konstrukcji języka zapytań. Naiwna ewaluacja zapytań
prowadzi do nieakceptowalnych czasów wykonania i konsumpcji pamięci.
• Np. proste zapytanie w SQL (podaj nazwiska dostawców dostarczających
części o nazwie ”zawór”):
select Dostawca.nazwisko from Dostawca, Produkt, DP
where Dostawca.NrDost = DP.NrDost and DP.NrProd = Produkt.NrProd
and Produkt.nazwa = ”zawór”
wymaga wykonania produktu kartezjańskiego relacji wymienionych w
klauzuli from. Przyjmując 10000 dostawców, 10000 produktów, 100000
krotek w relacji DP i średnio 100 bajtów w każdej krotce tych relacji, produkt
kartezjański miałby 1013 elementów i zajmowałby 930 000 GB.
• Jeżeli sprawdzenie warunku w klauzuli where dla pojedynczej krotki
trwałoby jedną tysięczną sekundy, to wyselekcjonowanie z produktu
kartezjańskiego właściwych krotek trwałoby 1010 sekund, czyli 317 lat.
• Dzięki metodom optymalizacyjnym obliczenie powyższego zapytania trwa
kilka sekund i nie wymaga zbyt dużo pamięci.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 22
kwiecień 2002
Metody optymalizacji zapytań (1)
 Metody oparte na przepisywaniu (rewriting). W metodach tych
dokonuje się semantycznie równoważnego przekształcenia zapytania (jego
drzewa syntaktycznego) na taką równoważną semantycznie postać, która
rokuje lepszy czas wykonania.
 Wprowadzenie specjalnych struktur danych lub specjalnej
organizacji danych. Do tej kategorii można zaliczyć indeksy, organizacje
plików oparta na kodowaniu mieszającym (hash coding), struktury danych
oparte na łańcuchach lub tablicach pointerów, specjalne organizacje tablic
w bazie danych umożliwiające bardzo szybkie złączenia, itd.
 Unikanie obliczania pewnych fragmentów zapytań. Chodzi tu o
unikanie obliczania „martwych” podzapytań, tj. takich fragmentów
zapytania, które nie mają wpływu na jego końcowy wynik. Tego rodzaju
sytuacje szczególnie często pojawiają się w przypadku automatycznej
generacji zapytań z innych interfejsów np. z wirtualnych perspektyw.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 23
kwiecień 2002
Metody optymalizacji zapytań (2)
 Zapamiętywanie wyników poprzednio obliczonych zapytań. Niektóre
szczególnie często spotykane zapytania są „materializowane”, dzięki
czemu nie jest potrzebna powtórna ich ewaluacja. Temat ten jest znany
jako „zmaterializowane perspektywy”.
 Jednoczesna optymalizacja wielu zapytań. W sytuacji, kiedy zapytania
ewaluuje jeden serwer obsługujący bardzo wiele jednoczesnych zleceń od
użytkowników możliwe jest wyodrębnienie wspólnych części tych
zapytań (np. pewnych złączeń) i następnie, jednorazowa ich ewaluacja.
 Wybór planu ewaluacji zapytania. Może być wiele semantycznie
równoważnych sposobów ewaluacji zapytania. Należy wybrać taki plan,
który zapewni jak najszybsze ograniczenie przestrzeni danych
uczestniczących w ewaluacji (np. plan na początku wykorzystuje indeks).
 Przy budowie optymalizatora zapytań zwykle wykorzystuje się szereg
wymienionych wyżej metod oraz ich wariantów i kombinacji.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 24
kwiecień 2002
Obiektowość a języki zapytań (1)
 Stosunek obiektowości do języków zapytań nadal nie jest do końca jasny.
Wynika to z dwóch przyczyn:
 1. Obiektowość jest ideologią informatyczną o luźno zarysowanych
założeniach, pojęciach i granicach.
• Natomiast języki zapytań są tworami formalnymi, których semantyka musi
być określona precyzyjnie, gdyż muszą być automatycznie optymalizowane.
• Luźne założenia i granice modeli obiektowych, ich ograniczenia (np. brak
kolekcji) powodują, że specyfikacje języków zapytań są intuicyjne.
 2. Poglądy i (fałszywe) stereotypy dotyczące języków zapytań,
wypracowane podczas rozwoju modelu relacyjnego.
• Np. twierdzenia, że jedynie model relacyjny wraz z jego podstawami
matematycznymi może być podstawą definicji języków zapytań.
• M. Stonebraker w często cytowanych publikacjach twierdzi, że obiektowe
bazy danych w ogóle nie mogą być wyposażone w języki zapytań.
• Podobne poglądy do pewnego czasu głosił J. Ullman.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 25
kwiecień 2002
Obiektowość a języki zapytań (2)
 Powstały próby i spekulacje dotyczące tego jak dopasować paradygmaty
relacyjnych języków zapytań do obiektowych struktur danych.
• Np. jak zmodyfikować algebrę relacji, jak przystosować SQL, itp.
• Konkluzje bywają zaskakujące.
 Przez pewien czas dominował pogląd, że idea języków zapytań jest
sprzeczna z koncepcją hermetyzacji (encapsulation).
• Zdaniem niektórych autorów, hermetyzacja polega na tym, że obiekt może
być przetwarzany wyłącznie przez metody zdefiniowane w jego klasie.
• Języki zapytań muszą mieć bezpośredni dostęp do atrybutów.
• Ergo: języki zapytań są sprzeczne z hermetyzacją.
• Jest to nonsens wynikający ze złego rozumienia pojęć obiektowości.
 Inną konsekwencją jest bezpośrednie uogólnianie metod formalnych
relacyjnych języków zapytań na obiektowe języki zapytań.
• Efektem jest mnogość tzw. obiektowych algebr, obiektowych rachunków, itd.
• Są to twory koncepcyjnie, matematycznie i pragmatycznie wadliwe.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 26
kwiecień 2002
Wykład 2
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 27
kwiecień 2002
Pojęcia obiektowości w bazach danych przypomnienie i dyskusja
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 28
kwiecień 2002
Obiekt
object
 Wielu autorów nie rozróżnia pojęcia obiektu jako pewnej abstrakcji
pojęciowej lub informacyjnej, konkretnego obiektu (materialnego)
istniejącego w świecie rzeczywistym, oraz struktury danych określanej
jako „obiekt” przechowywanej wewnątrz komputera.
 Dla języków zapytań tylko ostatni punkt widzenia jest relewantny.
 Obiektem będzie więc pewna struktura danych przechowywana w
przestrzeni pamięciowej komputera.
 Nie wymagamy, aby ta struktura danych miała swój odpowiednik wśród
obiektów świata rzeczywistego.
 Obiektem może być także dowolna abstrakcja programistyczna, np.
moduł, procedura, zmienna, stała środowiskowa, okienko wyświetlane na
ekranie, plik tekstowy, itd.
 Istotą obiektu jest to, że programista może nim manipulować tak jak
pojedynczą zwartą bryłą, np. wyszukiwać, kopiować, tworzyć, usuwać lub
przenosić.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 29
kwiecień 2002
Tożsamość obiektu, identyfikator obiektu
object identity
 W odróżnieniu od modelu relacyjnego obiektowość nie zakłada
konieczności określenia takiego atrybutu obiektu (lub kombinacji
atrybutów), który identyfikuje go w sposób unikalny, czyli tzw. „klucza
głównego” (primary key).
 Obiekt posiada swoją tożsamość (identity), tj. istnieje niezależnie od
innych obiektów i od swojego aktualnego stanu.
 W praktyce tożsamość oznacza ona, że obiekt posiada unikalny
wewnętrzny identyfikator (object identifier, OID), który odróżnia go od
innych obiektów.
 Taki identyfikator jest nadawany przez system automatycznie, niezależnie
od woli projektanta lub programisty.
 Wewnętrzny identyfikator jest nieczytelny, nie przenosi informacji
biznesowej.
 Wewnętrzny identyfikator umożliwia budowanie referencji do obiektu, w
szczególności tworzenie powiązań pointerowych.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 30
kwiecień 2002
Nazwa obiektu
 Każdy obiekt posiada nazwę, poprzez którą programista lub użytkownik
może identyfikować obiekt w tekście programu lub zapytania.
 Nazwa obiektu z reguły posiada nieformalne konotacje, np. nazwy takie
jak Student, Osoba, Faktura, Wykład przenoszą pewną informację o
znaczeniu odpowiedniej struktury danych w świecie rzeczywistym.
 Obiekt może posiadać więcej niż jedną nazwę. Z reguły różne nazwy
obiektu implikują różne spojrzenie na semantykę obiektów w świecie
rzeczywistym.
 W odróżnieniu od identyfikatora, nazwa obiektu nie musi być unikalna może być wiele obiektów posiadających tę samą nazwę. Np. można
utworzyć dowolnie dużo obiektów o nazwie Student.
 Obiekt może być identyfikowany przez nazwy inne niż jego własna
nazwa. Np. obiekt Student może być także identyfikowany przez nazwę
Osoba. Jest to konsekwencja zasady zamienialności (substitutability).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 31
kwiecień 2002
Stan obiektu, atrybuty obiektu
object state
 Obiekt posiada stan, określany jako kombinacja wartości wszystkich
składowych obiektu, przede wszystkim wartości wszystkich jego
atrybutów oraz powiązań z innymi obiektami.
 Stan obiektu może zmieniać się w czasie.
 Istnieje wiele rodzajów atrybutów obiektów i ich kombinacji:
• Atrybut prosty lub atomowy taki jak np. NAZWISKO dla obiektu
PRACOWNIK. Przechowuje dokładnie jedną wartość; np. ”Kowalski”.
• Atrybut złożony, taki jak np. ADRES. Przechowuje wiele wartości. Ma
strukturę hierarchiczną.
• Atrybut pointerowy: zawiera jako wartość identyfikator obiektu.
• Atrybut powtarzalny: przechowuje pewien zestaw wartości o nieokreślonej i
zmiennej w czasie liczbie elementów.
• Atrybut opcyjny, multimedialny, wyliczalny, domyślny, ...
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 32
kwiecień 2002
Przykład obiektu
Wypłać
Wpłać
Sprawdź
stan
KONTO
Numer 123-4321
Porównaj
podpis
Właściciel Jan Kowalski
Upoważniony Ewa Kowalska
Nalicz
procent
SaldoZł 34567
....
Upoważnij
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 33
Zlikwiduj
konto
Zmień
upoważnienie
 Czy oprócz
wymienionych metod
można będzie dostać się
do stanu obiektu
poprzez nazwy
atrybutów ?
 Tak. Kwestia zostanie
rozpatrzona dalej.
kwiecień 2002
Obiekt złożony
complex object
 Obiekt może być złożony, tj. składać się z pewnej liczby komponentów,
które także mogą być złożone.
 W zależności od języka lub systemu komponenty mogą być traktowane
jako obiekty lub mogą być uważane za kategorię różną od obiektów.
 Nie powinno istnieć ograniczenie rozmiaru obiektu, liczby komponentów
składających się na obiekt, rodzajów komponentów, lub liczby poziomów
hierarchii komponentów.
 Obiekt złożony reprezentujący byt świata rzeczywistego powinien
zawierać wszelkie informacje, które odnoszą się do tego bytu.
 Niezależnie od stopnia złożoności obiektu i jego wielkości projektant lub
programista może rozpatrywać go i wykonywać na nim operacje jak na
pojedynczym elemencie.
 Podane wyżej założenia stwarzają nową sytuację w stosunku do modelu
relacyjnego, gdzie informacje o obiekcie wyróżnialnym w rzeczywistości
modelowanej przez dane są rozproszone w krotkach wielu tabel.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 34
kwiecień 2002
Zasada relatywizmu obiektów
object relativism
 Zgodnie z zasadą relatywizmu obiektów, każdy obiekt złożony jest
zestawem podobiektów, które mogą być złożone lub atomowe.
Każdy podobiekt jest traktowany jako samodzielny obiekt.
Ogólne własności dotyczące obiektów i podobiektów są identyczne.
• Od tej zasady nie ma wyjątków, w szczególności atomowy atrybut obiektu
(np. atrybut ZAROBEK obiektu PRACOWNIK) jest obiektem.
• Powiązanie do innego obiektu jest też obiektem.
• Konsekwencją relatywizmu jest istnienie obiektów, które nie posiadają
atrybutów (czyli obiektów atomowych), jak również obiektów, dla których
nie jest istotne definiowanie klas, ponieważ są one obsługiwane wyłącznie
przez metody generyczne.
• Konsekwencją relatywizmu obiektów jest również fakt, że każdy podobiekt
(atrybut) musi posiadać swój unikalny identyfikator.
• Np. obiekt PRACOWNIK ma pewien zestaw przypisanych mu metod, ale jego
atrybut ZDJĘCIE jest innym obiektem posiadającym własne metody.
• Niektóre obiekty są obsługiwane wyłącznie przez wbudowane metody
generyczne, takie jak +, -, <, =. Dla nich nie jest istotne definiowanie klas.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 35
kwiecień 2002
Znaczenie relatywizmu obiektów
 Relatywizm obiektów znacznie upraszcza ich model formalny.
 Dzięki relatywizmowi środki dostarczane do dyspozycji programistów
mogą być zredukowane do minimum, gdyż nie zachodzi np. potrzeba
różnicowania środków dostępu do obiektów i do atrybutów.
 Relatywizm pozwala traktować moduły lub całe bazy danych jako
pojedyncze obiekty definiowane, dostępne i manipulowalne przy pomocy
standardowych środków.
 Minimalizacja ilości cech, które muszą być rozpatrywane przy
definiowaniu i manipulowaniu obiektami ma konsekwencje dla prostoty
całości interfejsu programistycznego, szybkości jego nauczania, rozmiaru
dokumentacji, rozmiaru i regularności języków, złożoności modeli
formalnych oraz łatwości i ogólności metod implementacyjnych.
 Jak dotąd, relatywizm obiektów nie jest popularny. Brak świadomości co
do znaczenia relatywizmu obiektów można uważać za przejaw
niedojrzałości wielu koncepcji w zakresie obiektowości.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 36
kwiecień 2002
Zasada wewnętrznej identyfikacji
internal identification
• Jest konsekwencją zasady relatywizmu obiektów.
 Zgodnie z zasadą wewnętrznej identyfikacji każdy byt programistyczny,
który może być niezależnie od innych wyszukiwany, wiązany,
aktualizowany, wstawiany, usuwany, indeksowany, zabezpieczany,
blokowany, itp. musi mieć unikalny wewnętrzny identyfikator.
• Tej zasadzie będą podlegać dowolne identyfikowalne byty zasobów
komputera lub danej aplikacji, m.in. procedury zgromadzone w bibliotekach,
klasy, metody, perspektywy, ograniczenia, wyzwalacze, moduły, itd.
• Nie jest istotne w jaki sposób identyfikator ma być konstruowany. Np. może
to być fizyczny adres, <OID+nazwa atrybutu>, <OID+offset>, itd.
• <OID+nazwa atrybutu> nie jest dobrą identyfikacją atrybutu, jeżeli jest on
wielowartościowy. Każda wartość takiego atrybutu musi mieć unikalną
identyfikację. <OID+offset> jest również niedobry, gdyż jest powiązany z
fizyczną reprezentacją i stałym formatem obiektu.
• Identyfikator bytu programistycznego nie może być związany ze stanem tego
bytu, o ile ten stan może ulegać zmianom. Czyli klucz główny (primary key),
znany z modelu relacyjnego, też nie zawsze jest dobrą identyfikacją.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 37
kwiecień 2002
Znaczenie zasady wewnętrznej identyfikacji
 Istnienie unikalnego wewnętrznego identyfikatora obiektu i jego
dowolnych podobiektów umożliwia budowanie jednoznacznych
referencji (references) do tego obiektu.
• Brak możliwości budowy referencji powoduje trudności z definicją semantyki
wielu funkcjonalności, takich jak np. operatora podstawienia, operatora
usuwania wartości atrybutu powtarzalnego, zapewnienie prywatności dostępu
do atrybutu, itd.
• Zasadzie wewnętrznej identyfikacji muszą także podlegać powiązania
pomiędzy obiektami. Powiązanie może podlegać aktualizacji, blokowaniu lub
ochronie, wobec czego konieczna jest jego jednoznaczna wewnętrzna
identyfikacja by umożliwić spójną implementację tych cech.
• Zasadzie wewnętrznej identyfikacji powinny podlegać również elementy
proceduralne, takie jak procedury, funkcje i metody.
• Zasada wewnętrznej identyfikacji jest ignorowana w modelu relacyjnym.
Wynikają stąd liczne anomalie i niejasna semantyka wielu cech systemów i
języków, np. semantyka klauzuli update w SQL.
• Podobnie z XML i systemami opartymi na XML.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 38
kwiecień 2002
Powiązania pomiędzy obiektami
pointer links, relationships
 Dzięki istnieniu unikalnych identyfikatorów obiektów w obiektowych
językach programowania i bazach danych możliwe jest tworzenie
bezpośrednich powiązań pointerowych między obiektami.
• Dość często każdy pointer ma "bliźniaka"; spójność par pointerów jest
wspomagana systemowo (ODMG).
PRACOWNIK
PRACOWNIK
PRACOWNIK
Nazwisko Nowak
Nazwisko Kowal
Nazwisko Babel
Zarobek 1500
Zarobek 2500
Zarobek 2000
PracujeW
PracujeW
PracujeW
Szef
NrFirmy 102030
Zatrudnia
Zatrudnia
Nazwa Syntex
Zatrudnia
FIRMA
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 39
kwiecień 2002
Znaczenie powiązań między obiektami
 Powiązania pointerowe były krytykowane przez propagatorów modelu
relacyjnego jako prowadzące do utraty niezależności danych.
 W modelu relacyjnym powiązania są realizowane poprzez umieszczanie
identycznych wartości w różnych miejscach relacyjnej struktury danych,
zwykle wartości klucza głównego i tzw. klucza obcego.
 Obiektowość wraca do powiązań pointerowych, odrzucając przy tym stare
kontr-argumenty jako demagogiczną, pseudo-techniczną retorykę.
• Zaletą powiązań pointerowych jest naturalne odwzorowanie semantycznych
związków między obiektami.
• Zaletą jest konceptualizacja programów, dzięki wyrażeniom ścieżkowym
(path expressions) skracającym kod i zwiększającym jego czytelność.
• Powiązania pointerowe umożliwiają zwiększenie szybkości działania, gdyż
nawigacja (przejście) wzdłuż pointera, np. od obiektu PRACOWNIK do
obiektu FIRMA, jest z reguły bardzo szybka.
• W systemach relacyjnych tego rodzaju przejście wymaga wykonania
kosztownej operacji złączenia (join); optymalizacja nie zawsze działa.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 40
kwiecień 2002
Przykład wykorzystania powiązań pointerowych
 Podaj nazwisko szefa Nowaka:
• SQL:
select s.Nazwisko
from PRACOWNIK p, FIRMA f, PRACOWNIK s
where p.NrFirmy = f.NrFirmy
and f.Szef = s.NrPracownika
and p.Nazwisko = "Nowak"
• SBQL: (PRACOWNIK where Nazwisko = "Nowak").
PracujeW.FIRMA.Szef.PRACOWNIK.Nazwisko
• Występujący w zapytaniu SQL warunek p.NrFirmy = f.NrFirmy jest
koncepcyjnie równoważny przejściu wzdłuż pointera PracujeW w modelu
obiektowym.
• W zapytaniu SBQL taki warunek się nie pojawia, gdyż jest on „wszyty” w
strukturę danych w postaci powiązania pointerowego.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 41
kwiecień 2002
Powiązania binarne i n-arne
 Model oparty na pointerach uwzględnia wyłącznie powiązania binarne.
 W modelu tym nie można również uwzględnić atrybutów powiązań i
ewentualnie metod przypisanych do powiązań.
 Istnieją kontrowersje co do tego, czy są to istotne ograniczenia
modelowania pojęciowego.
 Potrzeba wprowadzenia powiązań n-arnych i/lub z atrybutami pojawia się
w modelowaniu pojęciowym rzadziej i można je zastąpić powiązaniami
binarnymi bez atrybutów poprzez wprowadzenie nowej klasy obiektów.
 Model, w którym mogą istnieć powiązania n-arne (n  3) oraz posiadające
atrybuty powoduje znaczny rozrost środków programistycznych
niezbędnych dla jego obsługi (patrz CORBA Relationship Service).
 Jeżeli istnieją atrybuty powiązań, to mogą okazać się konieczne metody
dla obsługi tych atrybutów. W tej sytuacji powiązanie musiałoby być
związane z własną klasą, co implikuje, że powiązanie jest także obiektem.
Wracamy więc do punktu wyjścia.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 42
kwiecień 2002
Zamiana powiązań n-arnych na binarne
OSOBA
Bober
OSOBA
Kowalska
Sprzedający
Kupujący
OSOBA
Bober
OSOBA
Kowalska
Sprzedający
Kupujący
TRANSAKCJA
Plac
1995.08.16
40000
Transakcja
Plac
1995.08.16
40000
Pośrednik
Pośrednik
OSOBA
Nowak
OSOBA
Nowak
Pośrednik
Pośrednik
Transakcja
Samochód
1998.05.15
20000
Kupujący
TRANSAKCJA
Samochód
1998.05.15
20000
Sprzedający
OSOBA
Maciąg
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 43
Kupujący
OSOBA
Bielicka
OSOBA
Maciąg
Sprzedający
OSOBA
Bielicka
kwiecień 2002
Aktualizacja powiązań
 Języki proponowane przez różnych autorów dość często nie uwzględniają
faktu, że powiązania pomiędzy obiektami muszą być aktualizowane.
• Np. w języku OQL standardu ODMG nie można zbudować referencji do
powiązania, co powoduje, że aktualizacja powiązania poprzez wyrażenie
OQL staje się niestandardowa lub niemożliwa.
 Aktualizacja powiązania oznacza operację podstawienia, która wymaga
odzyskania (po lewej stronie podstawienia) referencji do powiązania, tj.
identyfikatora danej przechowującej pointer.
 Jeżeli pointer jest związany ze swoim bliźniaczym pointerem odwrotnym,
wówczas aktualizacja dowolnego z nich pociąga za sobą odpowiednią
aktualizację dwóch bliźniaczych pointerów (znajdujących się w starym i
nowym obiekcie, do których prowadził/prowadzi aktualizowany pointer).
• Takie rozwiązanie jest cechą standardu ODMG (wiązanie do C++).
• Usunięcie obiektu pociąga za sobą usunięcie powiązań tego obiektu z innymi
obiektami. „Bliźniacze” pary pointerów i ich synchroniczna aktualizacja
umożliwiają uniknięcie "zwisających pointerów ".
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 44
kwiecień 2002
Hermetyzacja i ukrywanie informacji encapsulation
information hiding
 Hermetyzacja jest grupowaniem elementów składowych w obrębie jednej
bryły i następnie, manipulowanie tą bryłą jako całością.
 Hermetyzację wiąże się z ukrywaniem części informacji dotyczącej
struktury i implementacji wnętrza tej bryły.
 Hermetyzacja jest generalną zasadą inżynierii oprogramowania
sformułowaną przez D. Parnasa w 1972 w związku z pojęciem modułu.
• Moduł, klasa, abstrakcyjny typ danych (ADT) - przykłady hermetyzacji.
 Programista ma tyle wiedzieć o tworze programistycznym (procedurze,
module, obiekcie, klasie), ile mu trzeba, aby go efektywnie używać.
• Wszystko, co może być przed programistą ukryte, powinno być ukryte.
• Jest to pożądane zarówno ze względu na potrzebę nie przeciążania modelu
pojęciowego programisty niepotrzebnymi elementami, jak i ze względu na
konieczność zredukowania potencjalnych błędów w oprogramowaniu.
• Specyfikacja jest oddzielona od implementacji. Możliwa jest zmiana
implementacji bez zmiany specyfikacji. Programistę interesuje wyłącznie
specyfikacja - nie ma potrzeby ani możliwości wglądu w implementację.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 45
kwiecień 2002
Różne spojrzenia na hermetyzację
 Hermetyzacja ortodoksyjna (znana z języka Smalltalk i ADT). Na
zewnątrz klasy lub obiektu widoczne są tylko niektóre metody (operacje);
natomiast pozostałe cechy obiektu (jego stan), w tym wszystkie jego
atrybuty, są ukryte.
 Hermetyzacja ortogonalna w stosunku do rodzaju własności klasy,
obiektu lub modułu (Modula-2, C++, Eiffel, Java). Dowolna własność
obiektu (atrybut, metoda, itp.) może być prywatna (ukryta) lub publiczna.
• Modula-2 i Eiffel wprowadzają pojęcie listy eksportowej, ustalającej cechy
„eksportowane” na zewnątrz do użytku publicznego.
• C++ wprowadza podobny środek w inny sposób, jak również dodatkowe
możliwości w postaci cech chronionych (protected) oraz klas
„przyjacielskich” (friend class).
• Java wprowadza pojęcie interfejsu grupującego cechy publiczne klasy;
koncepcyjnie odpowiada on pojęciu "listy eksportowej".
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 46
kwiecień 2002
Ortodoksyjna hermetyzacja jest sprzeczna
 Ortodoksyjna hermetyzacja należy do (bzdurnej) retoryki niektórych
zwolenników obiektowości. Jest ona wewnętrznie sprzeczna. Zakłada, że
deklaracja dowolnego publicznego atrybutu A oznacza dwie metody: getA
(podaj wartość A) i setA (ustaw wartość A). Patrz CORBA.
• Atrybuty mogą być opcyjne i/lub wielowartościowe (kolekcje), złożone,
multimedialne, itd. Dla nich dwie metody nie wystarczą.
• Np. jeżeli atrybut jest kolekcją, to musi istnieć metoda podstawiająca na
dowolną wartość z tej kolekcji. Taka metoda musi opierać się o iterator, czyli
mechanizm, który zwraca referencje do wartości atrybutów.
• Uniknięcie zwracania referencji do atrybutu jest motywem tej koncepcji, a tu
okazuje się, że tak czy inaczej musimy zwracać referencje. Sprzeczność!
• Taka hermetyzacja stwarza trudności z generycznością, np. zakomunikowaniu
atrybutu jako parametru call-by-reference do procedury lub metody.
• Stała się podstawą krytyki obiektowości jako takiej, gdyż uniemożliwia
zdefiniowanie języków zapytań (C.Date: Encapsulation is a red herring.).
• Ortodoksyjna hermetyzacja jest sprzeczna z zasadą relatywizmu obiektów (i
w konsekwencji, zasadą wewnętrznej identyfikacji).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 47
kwiecień 2002
Hermetyzacja ortogonalna
 Oznacza, ze dowolna cecha obiektu może być prywatna lub publiczna.
 Jeżeli atrybut jest publiczny, to oznacza, że istnieje generyczna metoda
(wspólna dla całego modelu), która zwraca referencję do tego atrybutu.
• Tą metodą jest (niejawna) operacja wiązania (binding), której argumentem
jest nazwa (m.in. atrybutu), zaś wynikiem jest referencja lub zbiór referencji.
Wewnętrzna struktura obiektu
PRACOWNIK
PRACOWNIK
NAZWISKO Nowak
ZAROBEK 2500
Zewnętrzna struktura obiektu
ROK_UR 1951
NAZWISKO Nowak
DZIAŁ Zabawki
ZarobekNetto() {...};
Podatek(){...};
DZIAŁ Zabawki
ZarobekNetto()
ZmieńZarobek(...) {...};
ZmieńZarobek(...)
Wiek() { return RokBież - ROK_UR };
Wiek()
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 48
kwiecień 2002
Komunikat
message
 Komunikat jest prawie dokładnie tym samym, co wołanie procedury.
• Różnice dotyczą wyłącznie składni, miejsca ulokowania procedury (metody
są wewnątrz klasy) oraz sposobu komunikowania parametrów do procedury:
• Wołanie procedury: Wypłać( KontoKowalskiego, 1000 );
• Komunikat:
KontoKowalskiego . Wypłać( 1000 );
 Różnica dotyczy także polimorfizmu, tj. mechanizmu dynamicznego
wyboru metody po wysłaniu komunikatu do obiektu.
• Polimorfizm wymaga dynamicznego wiązania. Bez dynamicznego wiązania
pojęcie komunikatu jest równoważne wołaniu procedury (z dokładnością do
składni). Polimorfizm jest ważną cechą, i dlatego warto odróżniać
komunikaty i wołania procedur.
 Języki zapytań mogą implikować inny kontekst i składnię komunikatów:
(PRACOWNIK where Wiek > 45) . Nazwisko
komunikat
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 49
kwiecień 2002
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ę.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 50
kwiecień 2002
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ń 1..5, Folia 51
kwiecień 2002
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ń 1..5, Folia 52
kwiecień 2002
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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 53
kwiecień 2002
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ń.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 54
kwiecień 2002
Przykład klas i dziedziczenia
OSOBA
Nazwisko
Imię
RokUrodz
Wiek()
STUDENT
NrIndeksu
RokStudiów
Wydział
WstawOcenę(...)
ZaliczSemestr()
obiekt
obiekt
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 55
obiekt
obiektobiektobiekt
PRACOWNIK
Zarobek
Firma
Zdjęcie
ZarobekNetto()
ZmieńZarobek(...)
obiekt
obiekt
obiekt
kwiecień 2002
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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 56
kwiecień 2002
Ekstensja klasy
extent
 Jest to nazwany zbiór obiektów aktualnie należących do danej klasy.
OSOBA
Nazwisko Kowalska
RokUr 1975
Ekstensja
klasy OSOBA
OSOBA
Nazwisko Nowak
RokUr 1951
OSOBA
Nazwisko Abacki
RokUr 1948
PRACOWNIK
Nazwisko Nowak
RokUr 1951
Zarobek 2000
Dział zabawki
PRACOWNIK
Nazwisko Abacki
RokUr 1948
Zarobek 2500
Dział zabawki
OSOBA
Nazwisko
RokUr
Wiek()
OSOBA
Nazwisko Babacki
RokUr 1940
PRACOWNIK
Nazwisko Babacki
RokUr 1940
Zarobek 3000
Dział sprzedaż
PRACOWNIK
Zarobek
Dział
ZarobekNetto()
ZmieńZarobek(...)
Ekstensja klasy PRACOWNIK
 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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 57
kwiecień 2002
Wielokrotne dziedziczenie
multiple inheritance
multi-inheritance
 Jest to dziedziczenie z kilku klas, z zsumowaniem dziedziczonych cech.
POJAZD
ciężar
.....
prędkość_eksploat()
POJAZD_LĄDOWY
ilość_kół
max_prędkość
.....
SAMOCHÓD
TRAKTOR
POJAZD_WODNY
wyporność
max_prędkość
.....
AMFIBIA
ŻAGLÓWKA
JACHT
 Problemem wielo-dziedziczenia jest konieczność rozstrzygnięcia
konfliktów nazw. Nie ma na to dobrego sposobu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 58
kwiecień 2002
Abstrakcyjne typ 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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 59
kwiecień 2002
Polimorfizm
polymorphism
• 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.
OSOBA
nazwisko
kategoria
....
....
STUDENT
....
dochody()
....
obiekt
PRACOWNIK
....
dochody()
....
obiekt
obiekt
obiekt
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 60
 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.
EMERYT
....
dochody()
....
obiekt
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.
kwiecień 2002
Wykład 3
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 61
kwiecień 2002
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: student JEST osobą . Jest to błąd pojęciowy.
raczej osoba STAJE SIĘ studentem, i to tylko na jakiś czas.
To
 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
STUDENT
PACJENT
dane historyczne
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 62
kwiecień 2002
Dynamiczne role i klasy
OSOBA
Nazwisko
RokUr
Wiek()
PRACOWNIK
Zarobek
Dział
ZarobekNetto()
ZmieńZarobek(..)
Klasy
OSOBA
Nazwisko Abacka
RokUr 1948
OSOBA
Nazwisko Kowalska
RokUr 1975
PRACOWNIK
Zarobek 2500
Dział Kredyty
Obiekty
STUDENT
Semestr
NrIndeksu
WpiszOcenę(...)
ObliczŚredniąOcen()
OSOBA
Nazwisko Nowak
RokUr 1951
PRACOWNIK
Zarobek 1500
Dział Obsługa
STUDENT
Semestr 7
NrIndeksu 223344
jest_klientem
pracuje_w
pracuje_w
FIRMA
Nazwa BankSA
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 63
OSOBA
Nazwisko Nowacki
RokUr 1940
studiuje_na
UCZELNIA
Nazwa PW
STUDENT
Semestr 4
NrIndeksu 556677
studiuje_na
UCZELNIA
Nazwa UW
kwiecień 2002
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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 64
kwiecień 2002
Przykład zagnieżdżonych kolekcji
nested collections
Pracownicy
Pracownik
Zatrudnienia
Nazwisko
Zatrudnienie
Dzieci
Dziecko Dziecko
Pracownik
..
.
Stanowisko
.....
Zatrudnienie
Dzieci
Dziecko Dziecko
Zatrudnienie
Zatrudnienia
Nazwisko
..
.
Stanowisko
.....
Zatrudnienie
.....
 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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 65
kwiecień 2002
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 problemy dla mocnej kontroli typów.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 66
kwiecień 2002
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{ 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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 67
kwiecień 2002
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.
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") )
 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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 68
kwiecień 2002
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.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 69
kwiecień 2002
Moduł
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ń.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 70
kwiecień 2002
Podstawy semantyczne języków zapytań
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 71
kwiecień 2002
Składnia, semantyka i pragmatyka języka
syntax, semantics, pragmatics
 Składnia: oznacza reguły tworzenia wyrażeń języka z elementarnych
symboli (alfabetu). Istotną cechą składni są reguły składniowe określające
sposób budowania wyrażeń (hierarchiczny podział wyrażeń na części).
 Semantyka: określa znaczenie wyrażeń języka, czyli stosunku napisów
tego języka do rzeczy, które te napisy wyrażają lub oznaczają.
• Definicja semantyki wymaga co najmniej zdefiniowania wspomnianych
„rzeczy”, czyli pewnej dziedziny znaczeń, pewnego uniwersum dyskusji o
znaczeniach. Definicja takiej dziedziny nie jest jednoznaczna i zależy od tego,
kto jest odbiorcą naszej definicji, jaki jest cel definicji, itd.
 Pragmatyka: wyznacza funkcję użytkową języka w interakcji
międzyludzkiej lub w interakcji pomiędzy człowiekiem i maszyną.
• Jak należy używać języka, w jakim celu, jak dopasować wyrażenia języka do
konkretnego problemu. Można znać składnię i semantykę, i być bezradnym
wobec problemu, jak przy pomocy tego języka zrobić użyteczny system
(przypadek wielu tzw. "teoretyków informatyki").
 Składnia i semantyka języka są służebnicami jego pragmatyki.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 72
kwiecień 2002
Składnia abstrakcyjna
abstract syntax
 Składnia wzbudza odruch lekceważenia u specjalistów, którzy ukuli
termin „lukier syntaktyczny” (syntactic sugar) na oznaczenie
semantycznie nieistotnych elementów zdań lub wyrażeń.
• w zdaniu: select Nazwisko from Osoba where Zawód = „analityk”
słowa
select, from i where są lukrem.
• Równie dobrze można byłoby je zapisać przy pomocy innego lukru, np.:
search Osoba with Zawód : „analityk” then retrieve Nazwisko
• Dyskusja odnośnie tego, który lukier jest lepszy, jest często niepoważna.
• Semantyka nie zależy od lukru syntaktycznego.
 Składnia pozbawiona lukru syntaktycznego jest składnią abstrakcyjną.
• Zapis: select A from B where C w składni abstrakcyjnej może mieć
postać nazwy operatora i jego argumentów, np. select(A; B; C) .
• Istotne jest to, aby do reguł składniowych przyporządkować reguły
semantyczne.
• To przyporządkowanie nazywa się semantyką kierowaną składnią.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 73
kwiecień 2002
Semantyka kierowana składnią
syntax-driven semantics
 Składnia abstrakcyjna powinna być zbudowana w taki sposób, aby
odzwierciedlać reguły semantyczne.
 Reguła semantyczna przyporządkowana do klauzuli składniowej
odzwierciedla znaczenie wyrażenia.
• Np. mamy składnię select A from (B where C) , której
przyporządkowujemy następującą regułę semantyczną:
• wyznacz zbiór B; z tego zbioru odrzuć elementy nie spełniające C; następnie
dokonaj projekcji wyniku na A.
• Jeżeli dokonalibyśmy rozbioru tego zdania w inny sposób, np.
(select A from B) where C , wówczas nie udałoby się zbudować
poprawnej semantyki.
 Semantyka kierowana składnią oznacza, że:
• język wyrażamy w postaci reguł składni abstrakcyjnej;
• do każdej reguły składni abstrakcyjnej przyporządkowujemy regułę
semantyczną, która bierze elementy składniowe jako argumenty.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 74
kwiecień 2002
Modularność lub kompozycyjność semantyki
modularity, compositionality
 Zasada modularności lub kompozycyjności mówi, że semantyka całości
wyrażenia jest funkcją semantyk wszystkich części tego wyrażenia.
Niech wyrażenie w ma w abstrakcyjne składni postać:
w = konstrukcja_składniowa(w1, w2, ..., wn )
• gdzie w1, w2, ..., wn są podwyrażeniami wyrażenia w.
 Oznaczmy przez |x| semantykę napisu x. Wówczas :
|w| = funkcja_zależna_od_konstrukcji_składniowej( |w1|, |w2|, ..., |wn| )
 Zasadę tę stosujemy rekurencyjnie, t.j. semantyki |w1|, |w2|, ..., |wn| są
wyznaczane analogicznie, aż do elementów alfabetu składni abstrakcyjnej.
• Elementom alfabetu przyporządkowujemy funkcje semantyczne w zależności
od ich kategorii leksykalnej (nazwy, stałe, operatory, itd.).
• Zasada ta obowiązuje formalne języki komputerowe. Dla niektórych z nich
(np. SQL) wyznaczenie funkcji semantycznych zależnych od konstrukcji
składniowych może być bardzo trudne ze względu na "syntaktyczne zlepki" i
odległe kontekstowo zależności.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 75
kwiecień 2002
Język modularny lub ortogonalny
 Język jest modularny lub ortogonalny, jeżeli:
• Jego wyrażenia w składni abstrakcyjnej zawierają mało podwyrażeń; najlepiej
jeżeli maksymalne n wynosi 2 lub 3;
• Składnia abstrakcyjna ma niewiele klauzul (nie więcej niż 50);
• Język zawiera niewielką liczbę kategorii leksykalnych (od 3-ch do 10-ciu).
• Funkcje semantyczne są proste i naturalne dla użytkowników;
• Nie występują wyjątki, dodatkowe ograniczenia syntaktyczne lub
semantyczne, nieregularne zależności.
 Język modularny/ortogonalny jest prosty w definicji, jest łatwy do uczenia
się, użycia, ma krótkie podręczniki.
 Język modularny/ortogonalny jest łatwy do bezpośredniej implementacji i
do optymalizacji.
• Obecna praktyka przemysłowa nie sprzyja tworzeniu języków modularnych/
ortogonalnych. Regułą są chaotyczne syntaktyczne zlepki, monstrualny
eklektyzm, niejasna semantyka, mnóstwo wyjątków i ograniczeń. Np. SQL3.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 76
kwiecień 2002
Semantyka języka zapytań z lotu ptaka
 Podstawą będzie założenie, że semantyka dowolnego zapytania jest
funkcją odwzorowującą zbiór wszystkich stanów (przede wszystkim bazy
danych, ale nie tylko) w element zbioru rezultatów zapytań.
• Niech Q będzie zbiorem napisów składających się na język zapytań
(wyznaczonych przez jego abstrakcyjną składnię),
• Stan - zbiór wszystkich możliwych stanów,
• Rezultat - zbiór wszystkich możliwych rezultatów zapytań.
 Dla dowolnego napisu q  Q semantyka jest pewną funkcją |q|
odwzorowującą stan w rezultat:
|q|: Stan  Rezultat
 Jeżeli zapytanie q ma efekty uboczne, np. wywołuje metodę, która
powoduje zmiany w bazie danych, wówczas semantyka takiego zapytania
wyraża się poprzez funkcję:
|q|: Stan  (Rezultat  Stan)
 Jeżeli q jest zleceniem aktualizacyjnym (np. klauzulą update języka SQL),
to:
|q|: Stan  Stan
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 77
kwiecień 2002
Własność domkniętości
closure property
 Własność ta mówi, że zarówno argumentami jak wynikiem dowolnego
zapytania muszą być elementy należące do tej samej dziedziny.
• Np. algebra relacji: argumentami zapytania są relacje, wynikiem jest relacja.
 Własność tę próbowano zastosować dla obiektowych języków zapytań.
Okazało się jednak że:
 Dla obiektowych języków zapytań własność domkniętości jest
nonsensem prowadzącym do licznych anomalii semantycznych.
• Jest ona również nonsensem dla SQL.
 Używając oznaczeń z poprzedniego slajdu, własność ta oznacza, że:
• Stan = Rezultat  Rezultat  Rezultat  Rezultat  Rezultat  Rezultat  ...
• Nic takiego nie będziemy zakładać. Jakkolwiek zbiory Stan i Rezultat
będziemy budować z tych samych cegiełek, zbiory te będą zasadniczo różne,
o różnej intencji, przeznaczeniu i roli semantycznej.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 78
kwiecień 2002
Co więc należy zdefiniować?
Dla potrzeb semantyki języka zapytań należy zdefiniować:
 Dziedzinę syntaktyczną zapytań, oznaczony wcześniej jako Q, w postaci
składni abstrakcyjnej.
 Zbiór wszystkich stanów, oznaczony wcześniej jako Stan.
 Zbiór wszystkich rezultatów zapytań, oznaczony wcześniej jako
Rezultat.
 Dla każdej klauzuli syntaktycznej z dziedziny Q, należy zdefiniować
odwzorowanie jej w znaczenie (semantykę) tej klauzuli.
• Najczęściej będzie to funkcja odwzorowująca Stan w Rezultat.
• Niekiedy będzie to funkcja odwzorowująca Stan w Rezultat i nowy Stan.
 Musimy zadbać o modularność, czyli taką definicję, która pozwoli na
budowanie semantyki dowolnie złożonych zapytań poprzez rekurencyjne
złożenie semantyk jego komponentów.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 79
kwiecień 2002
Co to jest "stan"?
state
 Zazwyczaj, pojęcie "stanu" jest utożsamiane ze "stanem bazy danych".
Jest to uproszczenie i ograniczenie. W naszym przypadku pojęcie stanu
będzie znacznie rozszerzone.
 Ze względu na ortogonalną trwałość interesować nas będzie nie tylko stan
bazy danych, ale także stan nietrwałych zmiennych/obiektów używanych
przez programy aplikacyjne, procedury, funkcje, metody, itd.
 Całość trwałych i nietrwałych zmiennych/obiektów będziemy nazywać
składem obiektów (krótko: składem).
• Cecha trwałości nie będzie nas w gruncie rzeczy interesować.
• Skład zawiera także pewne cechy globalnego środowiska, takie jak czas
bieżący, datę, login aktualnego użytkownika, itd.
 Interesować nas będzie także chwilowy stan przetwarzania, który jest
odwzorowany w postaci stosu środowisk (environment stack).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 80
kwiecień 2002
Modele składu obiektów
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 81
kwiecień 2002
Złożoność modeli obiektowych (1)
 Istniejące modele obiektowe są bardzo złożone.
 Model obiektowy standardu ODMG włącza dużą liczbę pojęć takich jak:
obiekty, literały, typy, podtypy, interfejsy, dziedziczenie, przesłanianie,
polimorfizm, kolekcje, struktury, związki, operacje, wyjątki i inne.
 Jeszcze bardziej złożony jest model SQL3, ponieważ do wymienionych
pojęć dokłada (co najmniej) relacje i abstrakcyjne typy danych (ADT).
 Zasadniczy udział w tej złożoności mają cechy drugorzędne i brak dążenia
do upraszczania i redukcji pojęć, eliminacji pojęć drugorzędnych i
zastępowanie bardziej specyficznych pojęć przez pojęcia bardziej ogólne.
 Konsekwencją złożoności modelu obiektowego jest złożoność języka
zapytań, w szczególności jego semantyki, ponieważ każda cecha modelu
obiektowego musi mieć swoje odbicie w składni, semantyce i w
pragmatyce języka bazującego na tym modelu.
• Precyzyjna semantyka języka oznacza konieczność zdefiniowania zbioru
wszystkich stanów (zbioru Stan). Złożoność modelu obiektowego powoduje
złożoność definicji tego zbioru i w konsekwencji złożoność definicji języka.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 82
kwiecień 2002
Złożoność modeli obiektowych (2)
 Złożoność oznacza zwiększenie trudności przy formalnej analizie
semantyki, czyli utrata kontroli nad uniwersalnością języka oraz znaczne
zmniejszenie potencjału dla optymalizacji zapytań.
 Obecny świat informatyki przemysłowo-komercyjnej przy konstrukcji
języków zapytań ignoruje lub lekceważy problem ich semantyki oraz
problem optymalizacji zapytań.
 Twierdzenia, że np. dla SQL3 lub OQL można łatwo zbudować modele
formalne, nie mają żadnego uzasadnienia. Wręcz odwrotnie, nie można.
 Z tego powodu konieczne staje się uproszczenie modeli obiektowych i/lub
taka abstrakcja nad tymi modelami, która byłaby formalnie prosta i
jednocześnie dostatecznie wiernie oddawałaby modele praktyczne.
• Modele obiektowe wprowadzają dużo pojęć, często różnie rozumianych.
Nie jest możliwe zbudowanie pojedynczego modelu formalnego.
 Będziemy opierali się o pewną rodzinę modeli, posiadającą tę samą bazę
pojęciową.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 83
kwiecień 2002
Modele składu obiektów
object store
 M0: obejmuje dowolnie powiązane hierarchiczne struktury danych; nie
obejmuje klas, dziedziczenia, interfejsu i hermetyzacji. Model M0
pozwala wyjaśnić semantykę relacyjnych języków zapytań (szczególnie
SQL), przykrywa koncepcję zagnieżdżonych relacji, struktury
implikowane przez XML i dane określane jako pół-strukturalne.
 M1: uzupełnia M0 o pojęcia klasy, dziedziczenia i wielodziedziczenia w
najczęściej spotykanym rozumieniu; nie obejmuje hermetyzacji i
interfejsu.
 M2: uzupełnia model M1 oraz nieco go modyfikuje wprowadzając
dziedziczenie pomiędzy obiektami oraz dynamiczne role. Można go
również uważać jako model odwzorowujący koncepcję wielu interfejsów
do obiektu.
 M3: uzupełnia model M1 lub M2 o pojęcie hermetyzacji - podział
własności klas i obiektów na publiczne i prywatne.
 Podana rodzina modeli nie zamyka tematu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 84
kwiecień 2002
Wykład 4
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 85
kwiecień 2002
Pojęcia wspólne dla modeli M0, M1, M2 i M3
 Wewnętrzny identyfikator obiektu. Jest nadawany automatycznie przez
system i nie posiada semantyki w świecie zewnętrznym. Jest nieczytelny.
Jest unikalny dla danego obiektu. Służy do identyfikacji obiektów w
pamięci komputera. Nie będziemy zajmować się budową identyfikatorów
ani ich specjalizowaniem w zależności od rodzaju obiektu lub pamięci.
 Zewnętrzna nazwa obiektu. W odróżnieniu od wewnętrznego
identyfikatora, zewnętrzna nazwa jest nadawana przez projektanta,
programistę lub administratora. Jest powiązana z modelem koncepcyjnym
lub biznesowym aplikacji działających na bazie danych. Posiada
(nieformalną) semantykę w świecie zewnętrznym. Np. taką nazwą może
być Klient lub Zarobek. W odróżnieniu od wewnętrznego identyfikatora,
zewnętrzna nazwa nie musi być i zwykle nie jest unikalna.
 Wartość atomowa. Wartość atomowa jest z naszego punktu widzenia
niepodzielna, nie posiada wyróżnialnych składowych. Wartość atomowa
może być liczbą, stringiem, blobem, ciałem metody, perspektywy,
procedury, reguły, itd.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 86
kwiecień 2002
Model M0 składu obiektów
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 87
kwiecień 2002
Model M0
• I - zbiór identyfikatorów (i, i1, i2, ... - oznaczenia identyfikatorów)
• N - zbiór nazw (n, n1, n2, ... - oznaczenia nazw)
• V - zbiór wartości atomowych (v, v1, v2, ... - oznaczenia wartości)
 Obiekt atomowy: trójka <i, n, v>.
 Obiekt pointerowy: trójka <i1, n, i2>. Obiekt jest identyfikowany przez i1,
natomiast i2 jest pointerem (referencją) do innego obiektu.
 Obiekt złożony: trójka <i, n, T>, gdzie T jest zbiorem dowolnych
obiektów. Powyższa reguła umożliwia rekurencyjne tworzenie obiektów o
nieograniczonej złożoności i o nieograniczonej liczbie poziomów
hierarchii.
 Skład obiektów jest zdefiniowany jako para <S, R>, gdzie S jest zbiorem
obiektów, zaś R jest zbiorem identyfikatorów "startowych”.
• Zbiór R wyznacza punkty wejściowe do składu obiektów, tj. obiekty
"korzeniowe" (root objects), które mogą być początkiem wyszukiwania w
zbiorze przechowywanych obiektów.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 88
kwiecień 2002
Ograniczenia w modelu M0
 Każdy obiekt, podobiekt, itd. w składzie posiada unikalny identyfikator.
 Jeżeli (na dowolnym poziomie hierarchii obiektów) wystąpi obiekt
pointerowy <i1,n,i2>, to powinien istnieć również obiekt posiadający
identyfikator i2. Warunek oznacza brak zwisających pointerów (lub tzw.
integralność referencyjną).
 Dowolny identyfikator ze zbioru R jest identyfikatorem pewnego obiektu
znajdującego się w składzie.
 Będziemy abstrahować od obiektów, które nie są osiągalne ze zbioru R,
bezpośrednio lub pośrednio. Obiekt bezpośrednio osiągalny posiada
identyfikator ze zbioru R. Obiekt jest osiągalny, jeżeli jest bezpośrednio
osiągalny lub jest podobiektem obiektu osiągalnego. Obiekt jest także
osiągalny, jeżeli posiada identyfikator i2 oraz jest osiągalny obiekt
pointerowy <i1, n, i2>. Obiekty nieosiągalne nie są w stanie wpłynąć na
wynik ewaluacji zapytań; są one tzw. nieużytkami (garbage) i mogą być
w dowolnym momencie skasowane.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 89
kwiecień 2002
Przykład składu w modelu M0
S - Obiekty:
< i1 , Prac , {< i2, Nazwisko, ”Nowak” >, < i3, Zar, 2500 >,
< i4, PracujeW, i17 > } >,
< i5 , Prac , {< i6, Nazwisko, ”Kowalski” >, < i7, Zar, 2000 >,
< i8, PracujeW, i22 > } >,
< i9 , Prac , {< i10, Nazwisko, ”Barski” >, < i11, Zar, 900 >,
< i12, Adres, {< i13, Miasto, ”Radom” >,
< i14, Ulica, ”Wolska” >,
< i15, NrDomu, 12 > } >,
< i16, PracujeW, i22 > } >,
< i17 ,Dział, {<i18, Nazwa, ”Produkcja” >,
< i19, Lokacja, ”Kielce” >, < i20, Lokacja, ”Kraków” >,
< i21, Zatrudnia, i1 > } >,
< i22 , Dział,{< i23, Nazwa, ”Sprzedaż” >,
< i24, Lokacja, ”Radom” >,
< i25, Zatrudnia, i5 >, < i26, Zatrudnia, i9 > } >
Diagram klas
Prac [0..*]
Nazwisko
Zar
Adres [0..1]
Miasto
Ulica
NrDomu
PracujeW
Zatrudnia[1..*]
Dział [0..*]
Nazwa
Lokacja[1..*]
R - Identyfikatory startowe:
i1 , i5 , i9 , i17 , i22
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 90
kwiecień 2002
Poglądowy obraz małej bazy danych
i1
Prac
i2 Nazwisko ”Nowak”
i3 Zar 2500
i4 PracujeW
i5
Prac
i9
i6 Nazwisko ”Kowalski”
Prac
i10 Nazwisko ”Barski”
i7 Zar 2000
i11 Zar 900
i12 Adres
i8 PracujeW
i13 Miasto ”Radom”
i14 Ulica ”Wolska”
i15 NrDomu 12
i16 PracujeW
i17
Dział
i22
Dział
i18 Nazwa ”Produkcja”
i23 Nazwa ”Sprzedaż”
i19 Lokacja ”Kielce”
i24 Lokacja ”Radom”
i20 Lokacja ”Kraków”
i25 Zatrudnia
i21 Zatrudnia
i26 Zatrudnia
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 91
kwiecień 2002
Relatywizm obiektów
object relativism
 Nie będziemy przywiązywać wagi do podziału obiektów na proste i
złożone, a także nie wprowadzamy specjalnej terminologii i pojęć dla
obiektów złożonych (takich jak „atrybut”, „struktura”, „krotka”, itd.).
Wszystkie te pojęcia dadzą się zamodelować przy pomocy opisanego
modelu składu.
 Tego rodzaju relatywizm obiektów ma zasadnicze znaczenie dla
uproszczenia definiowanych języków, znacznie upraszcza metamodel i
operacje na metamodelu, zwiększa uniwersalność języka i ma zasadnicze
znaczenia dla prostoty oraz klarowności semantyki i pragmatyki.
• W wielu koncepcjach obiektowości (np w standardach CORBA i ODMG)
relatywizm nie jest wyznawany. Np. w ODMG atrybut jest tzw. literałem,
który nie jest obiektem. Podobnie, większość koncepcji innych autorów
implicite zakłada, że obiekt musi być złożony, tj. musi posiadać strukturę
wewnętrzną w postaci atrybutów, pól, itp.
 W tej koncepcji zbędne również staje się pojęcie modułu. Moduł jest po
prostu obiektem składającym się z obiektów.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 92
kwiecień 2002
Modelowanie kolekcji i struktur
 W zdefiniowanym powyżej modelu M0 (jak i w następnych modelach) nie
zakładamy unikalności zewnętrznych nazw obiektów. Dotyczy to
dowolnego poziomu hierarchii obiektów.
• Przykładowo, na górnym poziomie hierarchii nazwy Prac i Dział nie są
unikalne, zaś wewnątrz obiektów Dział nie są unikalne nazwy Lokacja i
Zatrudnia.
• To założenie umożliwia modelowanie kolekcji bez wprowadzania w tym celu
specjalnych środków formalnych. Kolekcja nie występuje jako
identyfikowalny byt programistyczny - w odróżnieniu np. od ODMG.
• Podobne założenie odnośnie kolekcji przyjmuje XML.
 Abstrahujemy od wielu pojęć wprowadzanych w innych modelach, takich
jak krotki (tuples), struktury, warianty/unie, zapisy (records), zbiory (sets),
wielozbiory (bags), ekstensje (extents), itd.
• Pojęcia te dadzą się wyrazić w terminach podanego modelu poprzez pewne
ograniczenie lub wyspecjalizowanie.
• Z naszego punktu widzenia są to zestawy obiektów lub obiekty złożone.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 93
kwiecień 2002
Model relacyjny i model zagnieżdżonych relacji
 Model M0 włącza struktury danych zakładane przez model relacyjny jako
szczególny przypadek. Semantykę relacyjnego języka zapytań (w
szczególności SQL) można będzie zdefiniować jako szczególny
przypadek definiowanej przez nas semantyki.
• Nie będziemy nastawiać się na definiowanie semantyki SQL. SQL jest
językiem o licznych anomaliach, niekonsekwencjach i semantycznych rafach,
w związku z tym definiowanie jego precyzyjnej semantyki jest trudne i mało
sensowne. Przed taką definicją należałoby wcześniej uporządkować
koncepcję języka, a na to w przypadku SQL jest za późno.
 Model M0 przykrywa również model zagnieżdżonych relacji (NF2) jako
szczególny przypadek.
 Również struktury danych implikowane przez inne modele, określane
przez ich autorów jako funkcjonalne, obiektowe, logiczne, semantyczne,
itd. dadzą się sformalizować w terminach podanego prostego modelu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 94
kwiecień 2002
Relacja zapisana w modelu M0
Relacja: Prac
Schemat relacyjny:
Prac(
Nazwisko,
Zarobek,
PracujeW )
Nazwisko
Nowak
Kowalski
Barski
Zarobek
2500
2000
2000
PracujeW
Produkcja
Sprzedaż
Sprzedaż
Model składu obiektów:
Krotki relacji jako
obiekty złożone
S - Obiekty:
< i1 , Prac, { < i2, Nazwisko, ”Nowak” >,
< i3, Zarobek, 2500 >,
< i4, PracujeW, ”Produkcja” > } >,
< i5 , Prac, { < i6, Nazwisko, ”Kowalski” >,
< i7, Zarobek, 2000 >,
< i8, PracujeW, ”Sprzedaż” > } >,
< i9 , Prac, { < i10, Nazwisko, ”Barski” >,
< i11, Zarobek, 2000 >,
< i12, PracujeW, ”Sprzedaż” > } >
R - Identyfikatory startowe:
i1 , i5 , i 9
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 95
kwiecień 2002
Dokument XML zapisany w modelu M0
Plik XML
<pracownik>
<imie>Jan</imie>
<nazwisko>Kowalski</nazwisko>
<data_urodz>1973-12-1</data_urodz>
<pensja>2500</pensja>
</pracownik>
Model składu obiektów M0:
S - Obiekty:
< i1, pracownik, {
< i2, imie, ”Jan” >,
< i3, nazwisko, "Kowalski" >,
< i4, data_urodz, 1973-12-1>
< i5, pensja, 2500>
}>
R - Identyfikatory startowe:
i1
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 96
 Nie ma różnic koncepcyjnych.
 Potencjalne drobne problemy:
• Jak określić identyfikatory dla
obiektów XML?
• Jak traktować informacje
(tzw. atrybuty) wewnątrz
XML-owych tagów?
• Jak modelować powiązania
(obiekty pointerowe) w
XML?
kwiecień 2002
Sekwencje i tablice w modelu M0
 Istnieją ważne operatory, które potrzebują uwzględnienia porządku w
obiektach. Do nich należy np. operator order by języka SQL. Istotny jest
również operator wyboru n pierwszych (lub ostatnich) elementów z
pewnej kolekcji. Umożliwia on m.in. takie zapytania jak „Podaj 50-ciu
najlepiej zarabiających pracowników”.
 Czy potrzebne jest wzbogacenie naszego modelu o pojęcie "sekwencji"?
• Model M0 bezpośrednio nie uwzględnia sekwencji. Należy go rozszerzyć.
• Można też np. zastosować konwencję w której nazwy obiektów są liczbami
naturalnymi. Np. tablica ustalająca dzieci pracownika w porządku od
najstarszego do najmłodszego mogłaby mieć postać:
• <i1, Dzieci, { <i2, 1, ”Jacek”>, <i3, 2, ”Adam”>, <i4, 3, ”Anna”> }>
• Przy takim modelu dostęp do elementu tablicy następowałby poprzez indeks,
np. Dzieci.2 oznaczałoby wiązanie do identyfikatora i3 (wartości ”Adam”).
• Możliwe byłoby również użycie takich wyrażeń jak np. Dzieci.[x+1], które
przy wartości obiektu x równej 2 zwróci i4.
• Są inne metody realizacji pojęcia sekwencji w ramach modelu M0.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 97
kwiecień 2002
Model M1 składu obiektów
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 98
kwiecień 2002
Model M1 - klasy i dziedziczenie
 Model M1 wprowadza pojęcia klasy i dziedziczenia w wersji prototypów.
Klasa jest obiektem podobnym do wprowadzonych poprzednio obiektów.
 Obiekty będące klasami będą wyróżnione jako te, które przechowują
inwarianty innych obiektów. Ta rola klas będzie miała wpływ na
definiowaną przez nas semantykę języków zapytań.
 W M1 skład obiektów jest zdefiniowany jako <S, R, KK, OK>, gdzie:
• S jest zbiorem obiektów (rozszerzonym o klasy),
• R jest zbiorem identyfikatorów obiektów będących „wejściem” do nawigacji
w obiektowej strukturze danych,
• relacja KK  I  I wyznacza związek dziedziczenia pomiędzy klasami,
•
relacja OK  I  I wyznacza przynależność obiektów do klas.
 Dla każdej pary <i1, i2>  KK, i1 oznacza identyfikator klasy
dziedziczącej, zaś i2 oznacza identyfikator klasy z której się dziedziczy.
 Model M1 obejmuje wielokrotne dziedziczenie.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 99
kwiecień 2002
Przykład modelu M1
S - Obiekty i klasy:
< i1 , Osoba , { < i2, Nazwisko, ”Wilski” >, < i3, RokUr, 1950 > } >,
< i4 , Prac , { < i5, Nazwisko, ”Nowak” >, < i6, RokUr, 1944 >,
< i7, Zar, 2500 >, < i8, PracujeW, i127 > } >,
< i9 , Prac , { < i10, Nazwisko, ”Kowalski” >, < i11, RokUr, 1940 >,
< i12, Zar, 2000 >, < i13, PracujeW, i128 > } >,
< i40 , KlasaOsoba , {
< i41, Wiek, (..kod metody Wiek..) >,
inwariant: Nazwa obiektów = "Osoba",
..pozostałe inwarianty klasy KlasaOsoba ..}>,
< i50 , KlasaPrac , { < i51, ZmieńZar, (..kod metody ZmieńZar..) >,
< i52, ZarNetto, (...kod metody ZarNetto..) >,
inwariant: Nazwa obiektów = "Prac";
..pozostałe inwarianty klasy KlasaPrac .. }>,
R - Identyfikatory startowe:
i1 , i 4 , i 9
KK - Związki dziedziczenia między klasami:
< i50 , i40 >
OK - Związki dziedziczenia między obiektami i klasami:
< i1 , i40 >, < i4 , i50 >, < i9 , i50 >
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 100
kwiecień 2002
Graficzna reprezentacja przykładu modelu M1
Osoba
Nazwisko
RokUr
Wiek
i40 KlasaOsoba
i41 Wiek (...kod...)
................
i1 Osoba
i2 Nazwisko ”Wilski”
PracujeW
i3 RokUr 1950
Prac
Zar
ZmieńZar
ZarNetto
i50 KlasaPrac
i51 ZmieńZar (...kod...)
i52 ZarNetto (...kod...)
................
i4 Prac
i9 Prac
i5 Nazwisko ”Nowak”
i10 Nazwisko ”Kowalski”
i6 RokUr 1944
i11 RokUr 1940
i7 Zar 2500
i12 Zar 2000
i8 PracujeW
i13 PracujeW
i127
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 101
i128
kwiecień 2002
Inwariant klasy - nazwa jej obiektów
 Model M1 implikuje problemy z wiązaniem nazw.
 Zgodnie z zasadą zamienialności (substitutability, LSP), jeżeli w
wyrażeniu występuje nazwa Osoba, to związane muszą być nie tylko
obiekty Osoba, ale również obiekty Prac.
 M1 w sformułowaniu formalnym nie zawiera bezpośrednio informacji,
która to umożliwia, zatem musi być rozszerzony.
• W klasycznych modelach problem ten nie występuje, gdyż nazwa obiektów
nie jest inwariantem klasy, zaś zamienialność wynika z hierarchii klas lub
typów.
 To rozszerzenie można zrobić na kilka sposobów.
 Podany sposób zakłada, że klasy są wyposażona w dodatkowy inwariant nazwę obiektów danej klasy.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 102
kwiecień 2002
Model M2 składu obiektów
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 103
kwiecień 2002
Model M2 - dynamiczne role
 Model M2 jest uporządkowaną piątką <S, R, KK, OK, OO>, gdzie
wprowadziliśmy nową relację OO  I  I.
• Relacja OO pozwala obiektom dziedziczyć z innych obiektów, na takiej samej
zasadzie jak obiekty dziedziczą z klas. Obiekty dziedziczące z obiektu A
będziemy nazywać rolami obiektu A. Możliwe jest dziedziczenie z ról.
• Relacja OO ustala semantykę manipulacji obiektami z dynamicznymi rolami.
W szczególności, usunięcie obiektu będzie powodować usunięcie wszystkich
jego ról.
 Model M2 jest wolny od pewnych anomalii typologicznych i jest
formalnie bardziej „czysty” w stosunku do modelu M1. W szczególności,
nie ma wspomnianego problemu z wiązaniem nazw.
•
Jest paradoksem fakt, że model składu wprowadzający role, który jest
semantycznie czysty i prosty, jest uważany za zbyt skomplikowany.
• Wydaje się, że wynika to z pewnych obciążeń myślenia o obiektowości,
wynikających z tradycji istniejących języków programowania, takich jak C++
i Smalltalk.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 104
kwiecień 2002
Przykład modelu M2
S - Obiekty i klasy:
< i1 , Osoba , { < i2, Nazwisko, "Wilski" >, < i3, RokUr, 1950 > } >,
< i4 , Osoba , { < i5, Nazwisko, "Nowak" >, < i6, RokUr, 1944 >} >,
< i7 , Osoba , { < i8, Nazwisko, "Kowalski" >, < i9, RokUr, 1940 >} >,
< i13 , Prac , { < i14, Zar, 2500 >, < i15, PracujeW, i127 > } >,
< i16 , Prac , { < i17, Zar, 2000 >, < i18, PracujeW, i128 > } >,
< i19 , Student , { < i20, NrIndeksu, 76943 >, < i21, Wydział, "fizyka" >} >,
< i40 , KlasaOsoba , { < i41, Wiek, (...kod metody Wiek...) >,
...pozostałe inwarianty klasy KlasaOsoba ...}>,
< i50 , KlasaPracownik , { < i51, ZmieńZar, (...kod metody ZmieńZar...) >,
< i52, ZarNetto, (...kod metody ZarNetto...) >,
...pozostałe inwarianty klasy KlasaPrac ... }>,
< i60 , KlasaStudent , { < i61, ŚredniaOcen, (...kod metody ŚredniaOcen...) >,
...pozostałe inwarianty klasy KlasaStudent ... }>,
R - Identyfikatory startowe: i1 , i4 , i7 , i13 , i16 , i19
KK - Związki dziedziczenia między klasami: Zbiór pusty
OK - Związki dziedziczenia między obiektami i klasami:
< i1 , i40 >, < i4 , i40 >, < i7 , i40 >, < i13 , i50 >, < i16 , i50 >, < i19 , i60 >,
OO - Związki dziedziczenia między obiektami i obiektami:
< i13 , i4 >, < i16 , i7 >, < i19 , i7 >
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 105
kwiecień 2002
Graficzna reprezentacja przykładu modelu M2
i40 KlasaOsoba
i41 Wiek (...kod...)
.............
i1 Osoba
i60 KlasaStudent
i2 Nazwisko ”Wilski”
i61 ŚredniaOcen (...kod...)
i3 RokUr 1950
................
i50 KlasaPrac
i51 ZmieńZar (...kod...)
i52 ZarNetto (...kod...)
................
i4 Osoba
i5 Nazwisko ”Nowak”
i7 Osoba
i8 Nazwisko ”Kowalski”
i6 RokUr 1944
i9 RokUr 1940
i13 Prac
i16 Prac
i14 Zar 2500
i17 Zar 2000
i15 PracujeW
i19 Student
i20 NrIndeksu 76943
i21 Wydział ”fizyka”
i18 PracujeW
i127
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 106
i128
kwiecień 2002
Odmienność i zalety modelu z rolami (1)
 Wielokrotne dziedziczenie: Ponieważ role są hermetyzowane, nie może
wystąpić konflikt nazw nawet wtedy, gdy różne role (czyli specjalizacje
obiektu) posiadają własności o tych samych nazwach.
 Powtarzalne dziedziczenie: Jest normalne, że obiekt może mieć dwie
lub więcej ról o tej samej nazwie. Np. Kowalski może być dwa razy
studentem, w różnych szkołach. Ten przypadek nie jest objęty klasycznym
modelem dziedziczenia lub wielokrotnego dziedziczenia.
 Przechowywanie obiektów historycznych: Role idealnie nadają się do
przechowywania obiektów historycznych nie powodując przy tym
anomalii z unikalnością identyfikatorów obiektów. Np. można łatwo
zapisać fakt, że Kowalski był już kiedyś dwa razy studentem.
 Wielo-aspektowe dziedziczenie: Klasa może być specjalizowana wg
wielu aspektów, np. według stosunku do zatrudnienia lub stosunku do
wykształcenia. UML przykrywa tę cechę, ale jest ona nieobecna w
narzędziach obiektowych, co prowadzi m.in. do efektu "eksplozji klas".
Role automatycznie mają cechę wielo-aspektowego dziedziczenia.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 107
kwiecień 2002
Odmienność i zalety modelu z rolami (2)
 Warianty (unie): Cecha ta, wprowadzona m.in. w C++, CORBA i
ODMG, prowadzi do wielu semantycznych i implementacyjnych
problemów. Role przykrywają tę cechę, przez co staje się niepotrzebna.
 Migracja obiektów: Role mogą pojawiać się i znikać dynamicznie, co w
terminach klasycznych modeli obiektowych oznacza, że obiekt zmienia
klasę (czyli "migruje") bez zmiany tożsamości. Dla klasycznych modeli
jest to duży problem. W przypadku ról problem ten nie istnieje.
 Spójność referencyjna: W przypadku ról związki mogą prowadzić do ról,
a nie do całych obiektów. Np. jeżeli nawigujemy od obiektu Szkoła do
obiektu Kowalskiego poprzez jego rolę Student, wówczas niedostępny jest
atrybut Zar i metoda ZarNetto. Jest to znaczne uściślenie hermetyzacji.
 Dynamiczne dziedziczenie: KlasaPrac nie dziedziczy statycznie z
KlasaOsoba. Zamiast tego, rola Prac dziedziczy dynamicznie z roli
Osoba wszystkie cechy, włączając metody zawarte w klasie KlasaOsoba.
Stwarza to nową sytuację dla przesłaniania i polimorfizmu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 108
kwiecień 2002
Odmienność i zalety modelu z rolami (3)
 Heterogeniczne, przecinające się kolekcje. W klasycznych modelach,
np. w ODMG, jeżeli obiekt był elementem kolekcji, to nie mógł być
jednocześnie elementem innej kolekcji. Jest to ograniczenie modelowania
pojęciowego. Dynamiczne role posiadają naturalną zdolność modelowania
heterogenicznych, przecinających się kolekcji.
• Np. można utworzyć rolę Pacjent, i tą rolę objąć ludzi i zwierzęta, oraz inną
rolę ObiektyDzisiajAktualizowane obejmującą obiekty dowolnego typu.
Kolekcje Pacjent i
ObiektyDzisiajAktualizowane są heterogeniczne i
zachodzą na siebie.
 Programowanie aspektowe (Aspect-Oriented Programming, AOP) i
rozdzielenie aspektów. AOP zajmuje się rozdzieleniem przecinających
się aspektów (cross-cutting concerns) celem umieszczenie każdego
aspektu w odrębnym module programu (np. historię zmian, reguły
bezpieczeństwa, wizualizację, itd.). Dynamiczne role mają wiele
zbieżności z AOP lub mogą być wykorzystane jako techniczne
wspomaganie AOP.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 109
kwiecień 2002
Model M3 składu obiektów
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 110
kwiecień 2002
Model M3 - hermetyzacja i ukrywanie informacji
 Model M3 uwzględniający hermetyzację możemy zbudować zarówno na
gruncie modelu M1, jak i modelu M2, ponieważ cecha hermetyzacji jest
ortogonalna w stosunku do wprowadzonych wcześniej własności.
 Idea hermetyzacji polega na tym, aby w określonych sytuacjach zabronić
dostępu do pewnych własności obiektów, określanych jako „prywatne”.
• Chodzi o to, aby własności prywatne były dostępne z „wnętrza” obiektu, zaś
niedostępne z jego „zewnętrza”. Będzie to wymuszone poprzez stosową
semantykę języka zapytań.
 Model M3 uzupełnia model M1 lub M2 w taki sposób, że klasy są
wyposażona w dodatkowy inwariant - listę eksportową. Jest ona
zbiorem nazw własności tej klasy i jej obiektów (metod, atrybutów),
które będą widoczne z zewnątrz.
 Lista eksportowa będzie użyta w procesie ewaluacji zapytań jako
dodatkowy środek kontroli zakresu obowiązywania nazw.
• Podobny środek polega na wprowadzeniu pojęcia interfejsu do obiektów
danej klasy.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 111
kwiecień 2002
Przykład modelu M3
S - Obiekty i klasy:
< i1 , Osoba , { < i2, Nazwisko, ”Wilski” >, < i3, RokUr, 1950 > } >,
Osoba
+ Nazwisko
- RokUr
+ Wiek
Prac
- Zar
+PracujeW
+ ZmieńZar
+ ZarNetto
< i4 , Prac , { < i5, Nazwisko, ”Nowak” >, < i6, RokUr, 1944 >,
< i7, Zar, 2500 >, < i8, PracujeW, i127 > } >,
< i9 , Prac , { < i10, Nazwisko, ”Kowalski” >, < i11, RokUr, 1940 >,
< i12, Zar, 2000 >, < i13, PracujeW, i128 > } >,
< i40 , KlasaOsoba , { < i41, Wiek, (..kod metody Wiek..) >,
inwariant: Nazwa obiektów = "Osoba",
inwariant: Lista eksportowa = {"Nazwisko",
"Wiek"},
..pozostałe inwarianty klasy KlasaOsoba ..}>,
< i50 , KlasaPrac, { < i51, ZmieńZar, (..kod metody ZmieńZar..) >,
< i52, ZarNetto, (...kod metody ZarNetto..) >,
inwariant: Nazwa obiektów = "Prac";
inwariant: Lista eksportowa = {"PracujeW",
"ZmieńZar", "ZarNetto" },
..pozostałe inwarianty klasy KlasaPrac .. }>,
R - Identyfikatory startowe:
i1 , i4 , i 9
KK - Związki dziedziczenia między klasami:
< i50 , i40 >
OK - Związki dziedziczenia między obiektami i klasami:
< i1 , i40 >, < i4 , i50 >, < i9 , i50 >
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 112
kwiecień 2002
Schemat bazy danych dla modeli składu
 Język schematu bazy danych jest bardzo ważnym uzupełnieniem
dowolnego modelu składu.
 Język schematu stanowi inherentną część języka zapytań (jego
pragmatyki), gdyż na podstawie schematu programista wie, co baza
danych zawiera i jak jest zorganizowana.
 Schemat bazy danych jest również wykorzystywany przez SZBD dla
właściwej organizacji danych, reprezentacji danych, kontroli typów
danych oraz wymuszenia niektórych ograniczeń dotyczących danych.
 Przykładem takiego języka jest ODL wg standardu ODMG.
• Schematy są również wyrażane w postaci graficznej; np. w UML.
 Dla każdego wprowadzonego modelu składu konieczne jest opracowanie
języka umożliwiającego zapis schematu. Jest to duże zadanie.
• W tym wykładzie będziemy przyjmować (nie do końca słusznie), że schemat
jest ważny dla pragmatyki języka, ale jest mniej istotny dla jego semantyki.
• Z tego powodu dalej będziemy stosować notację ad hoc (wzorowaną na
UML) popartą objaśnieniami i przykładami.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 113
kwiecień 2002
Wykład 5
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 114
kwiecień 2002
Stos środowisk i wiązanie nazw
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 115
kwiecień 2002
Stos środowisk
environment stack
 Pojęcie stosu środowisk pojawiło się w informatyce w latach 60-tych.
 Od tego czasu stos ten jest elementem konstrukcji większości znanych
języków, włączając Pascal, C/C++, Smalltalk, Java, itd.
• Idea tego stosu jest znana wszystkim konstruktorom języków oraz większości
programistów programujących w w/w językach.
 Idea jest prosta i oczywista, ale nie jest często dostatecznie dobrze
objaśniona w podręcznikach.
• Specjaliści z zakresu baz danych rzadko rozumieją, po co jest ten stos i jakie
ma własności.
• Znane języki zapytań są oparte o koncepcje ograniczone i nieadekwatne, takie
jako algebra relacji, algebry obiektowe, itd.
 Przy konstrukcji semantyki języków zapytań musimy wrócić do stosu
środowisk.
• Chcemy prześledzić jego rolę jako mechanizmu języków programowania oraz
zmodyfikować jego budowę i funkcje go w taki sposób, aby odpowiadał on
potrzebom związanym z definicją semantyki języków zapytań.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 116
kwiecień 2002
Środowiska w językach programowania
 Pojęcie środowiska (environment) działania programu oznacza zestaw
wszystkich bytów programistycznych czasu wykonania (zmiennych,
stałych, obiektów, funkcji, procedur, typów, klas, itd.), które są dostępne
dla programisty w danym punkcie sterowania programu.
 Środowisko wykonania nie jest „płaską” strukturą oraz zmienia się w
trakcie działania programu.
 Wygodnym sposobem zarządzania zmianami środowiska jest przyjęcie
założenia, że środowisko jest podzielone na pod-środowiska, które
pojawiają się i znikają w miarę przesuwania się sterowania programu.
S1
S1 S2
S1 S2 S3
S1 S2
S1
sterowanie
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 117
kwiecień 2002
Zasady zarządzania środowiskami programu
 Zasady te mają wpływ na technikę i niezawodność programowania.
Są one następujące:
 Środowisko lokalne danego bytu programistycznego ma priorytet w
stosunku do środowiska bardziej globalnego. Np. programista
koncentrujący się nad napisaniem pewnej procedury powinien mieć
możliwość abstrahowania od wpływu globalnego środowiska na tę
procedurę.
 Zasada lokalnego kontekstu: programista piszący pewną procedurę nie
może uwzględnić w niej tych (nieznanych) elementów środowiska
wykonania, które pojawią się w momencie wywołania tej procedury.
 Zasada dowolnego zagnieżdżania wołań procedur: programista piszący
procedurę może bez ograniczeń koncepcyjnych wołać w niej inne
procedury. W szczególności, dopuszczalne są dowolne rekurencyjne
wołania, pośrednie lub bezpośrednie.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 118
kwiecień 2002
Realizacja zarządzania środowiskami
 Przyjęcie tych zasad prowadzi do pojęcia stosu środowisk (określanego
także jako stos wołań, call stack), czyli struktury danych odpowiedzialnej
za kontrolowania zmianami środowiska wykonania programów.
 W językach programowania cel, działanie i organizacja mechanizmu stosu
środowisk jest dobrze rozpoznane. Stos ten jest odpowiedzialny za:
• kontrolowanie zakresów nazw zmiennych i wiązanie tych nazw;
• przechowywanie wartości lokalnych zmiennych funkcji, procedur lub metod;
• przechowywanie wartości parametrów aktualnych funkcji i procedur;
• przechowywanie tzw: śladu powrotu, tj. adresu instrukcji, do której ma
przejść sterowanie po zakończeniu działania funkcji, procedury lub metody.
 Stos środowisk jest strukturą danych przechowywaną w pamięci
operacyjnej (lub wirtualnej). Jest on podzielony na części, które będziemy
określać jako sekcje, przy czym kolejność sekcji jest istotna.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 119
kwiecień 2002
Działanie stosu środowisk
 Stos jest zarządzany zgodnie z wołaniami procedur, funkcji, metod, itd.
oraz wejściem sterowania w tzw. bloki programu.
 Nowa sekcja (tzw. zapis aktywacji, activation record) pojawia się na
wierzchołku stosu w momencie wejścia sterowania programu w procedurę
(funkcję, metodę) oraz w momencie wejścia sterowania w blok.
 Sekcja ta zawiera wartości lokalnych zmiennych, wartości parametrów
oraz (dla procedur, funkcji i metod) ślad powrotu.
• Zatem nowa sekcja na stosie odpowiada każdemu wołaniu procedury, funkcji
lub metody, lub wejściu sterowania w nowy blok.
 Sekcja ta jest usuwana z wierzchołka stosu w momencie zakończenia
procedury (funkcji, metody) oraz w momencie wyjścia z bloku.
 Wszystkie lokalne zmienne zadeklarowane w aktualnie wykonywanej
procedurze (funkcji, metodzie) oraz jej parametry są przechowywane na
wierzchołku tego stosu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 120
kwiecień 2002
Ilustracja działania stosu środowisk
Procedura p1 wywołuje procedurę p2, która wywołuje procedurę p3
Wywołanie p3
Wywołanie p2
Sekcja
lokalnych
danych i
parametrów
procedury p3
Wyjście z p3
Wywołanie p1
Sekcja
lokalnych
danych i
parametrów
procedury p2
Sekcja
lokalnych
danych i
parametrów
procedury p2
Sekcja
lokalnych
danych i
parametrów
procedury p2
Wyjście z p2
Sekcja
lokalnych
danych i
parametrów
procedury p1
Sekcja
lokalnych
danych i
parametrów
procedury p1
Sekcja
lokalnych
danych i
parametrów
procedury p1
Sekcja
lokalnych
danych i
parametrów
procedury p1
Sekcja
lokalnych
danych i
parametrów
procedury p1
Wyjście z p1
...
...
...
...
...
...
...
Sekcja
danych
globalnych
Sekcja
danych
globalnych
Sekcja
danych
globalnych
Sekcja
danych
globalnych
Sekcja
danych
globalnych
Sekcja
danych
globalnych
Sekcja
danych
globalnych
czas
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 121
kwiecień 2002
Wiązanie (1)
binding
 Wiązanie jest to zastępowanie nazw występujących w tekście programu na
byty programistyczne czasu wykonania, np. na adresy RAM,
identyfikatory obiektów, adresy startowe procedur, itd.
• Przykładowo, wiązanie nazwy zmiennej x oznacza zastąpienie tej nazwy
przez adres RAM, gdzie przechowywana jest wartość zmiennej x.
 Wiązanie może być wczesne lub statyczne (early binding, static binding),
czyli odbywa się w czasie kompilacji, albo późne lub dynamiczne (late
binding, dynamic binding), czyli odbywa się w czasie wykonania.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 122
kwiecień 2002
Wiązanie (2)
 Wiązanie nazw na stosie środowiskowym odbywa się więc wg prostej
zasady:
• poszukuje się wartości opatrzonej tą nazwą w sekcji na wierzchołku stosu;
• jeżeli na wierzchołku takiej nazwy nie ma, poszukuje się takiej wartości w
sekcji poniżej;
• proces ten jest kontynuowany aż do znalezienia wartości opatrzonej tą nazwą,
ale z uwzględnieniem reguł zakresu (scoping rules), które nakazują omijanie
pewnych sekcji stosu;
• jeżeli nazwa nie jest odnaleziona na stosie, wówczas poszukiwana jest ona
wśród zmiennych globalnych (ew. tzw. zmiennych statycznych), bibliotek
funkcji i zmiennych/stałych środowiskowych. Można uważać, że tego rodzaju
globalne własności znajdują się na dole stosu środowisk.
 Abstrahujemy od wiązania statycznego, zakładając, że wszelkie wiązania
zachodzą podczas czasu wykonania.
• wiązanie statyczne traktujemy jako rodzaj optymalizacji.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 123
kwiecień 2002
Przykładowa sytuacja na stosie środowisk
Wykonywany jest blok l w procedurze p2 wywołanej z p1.
procedure p1( x, y ) {
deklaracje zmiennych a, b;
...
call p2( 55, 83 );
...
}
procedure p2( z, t ) {
deklaracje zmiennych c,d;
...
{ (* blok l *)
deklaracje zmiennych e, f;
Wierzchołek stosu
Zmienne e, f zadeklarowane
wewnątrz bloku l
Zmienne c, d i parametry
z(55), t(83) procedury p2
Zmienne a, b i parametry x, y
procedury p1
g := 75;
...
};
...
}
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 124
Kolejność
poszukiwania wiązania
dla zmiennej g
.........
Zmienne i inne byty globalne
Dół stosu
kwiecień 2002
Dlaczego przy wiązaniu omijamy niektóre sekcje?
 Reguła zakresu: z wnętrza procedury p2 (i bloku b) nie mogą być
widoczne zmienne i parametry procedury p1.
• Procedury p1 i p2 mogą być pisane przez różnych programistów, w różnym
czasie, zatrudnionych przez różne firmy.
• Programista piszący p2 nie ma pojęcia, jakie nazwy lokalnych zmiennych
będą użyte podczas pisania p1.
• Nie może mieć jakiejkolwiek możliwości odwołania się do zmiennych
procedury p1. Każde takie odwołanie wynikałoby z przypadkowej zgodności
nazw, np. wskutek błędu.
• Zatem najlepiej "na chwilę" ukryć środowisko wewnętrzne p1.
 Jest to zasada określana niekiedy jako statyczna lub leksykalna kontrola
zakresu (static scoping, lexical scoping).
 Zasada ta mówi, że programista nie może mieć możliwości odwołania się
do tych bytów programistycznych, które są dla niego niewidoczne lub
nieznane podczas pisania programu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 125
kwiecień 2002
Statyczna kontrola zakresu dla modułów
• p1 woła p2 . Procedura p1 znajduje się wewnątrz modułu m1, zaś procedura
p2 znajduje się wewnątrz modułu m2. Wykonywany jest blok b wewnątrz p2.
Wierzchołek stosu
Zmienne zadeklarowane wewnątrz bloku b
Kolejność
poszukiwania
zmiennej x
Zmienne i parametry procedury p2
Prywatne i publiczne własności modułu m2
Własności importowane przez moduł m2
Zmienne i parametry procedury p1
Prywatne i publiczne własności modułu m1
Własności importowane przez moduł m1
.........
Referencje do wszystkich modułów
Referencje do własności środowiska globalnego
Dół stosu
• Podobnie dla języków obiektowych (do tego tematu dojdziemy).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 126
kwiecień 2002
Po co jest mechanizm stosu środowiskowego? (1)
 Abstrakcja i hermetyzacja: wnętrze napisanej procedury (funkcji,
metody) zostaje ukryte przed programistami, którzy jej użyją. Procedura
jest widoczna wyłącznie poprzez jej interfejs (tzw. sygnaturę).
 Izolacja: programiści piszący różne procedury nie muszą o sobie wiedzieć
ani nie muszą między sobą uzgadniać nazw lokalnych zmiennych.
 Semantyczna niezależność i ponowne użycie: procedura może być
wywołana z wielu miejsc. Może być także używana w wielu aplikacjach.
 Wywoływanie procedur z innych procedur, włączając wołania
rekurencyjne. Dzięki temu, że sekcja stosu jest przypisana do wołania
procedury, nie zachodzi konflikt przy wywołaniach procedur z procedur;
w szczególności, procedura może bez ograniczeń wywołać samą siebie.
• Przy założeniu, że pamięć przeznaczona na stos jest nieograniczona, co nie
ma miejsca w typowych językach programowania.
• Niekiedy stos jest zorganizowany z użyciem pamięci wirtualnej, co
minimalizuje problem przepełnienia stosu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 127
kwiecień 2002
Po co jest mechanizm stosu środowiskowego? (2)
 Spójne zarządzanie nazwami użytymi w programie. Przestrzeń użytych
nazw jest ściśle kontrolowana, zaś nazwy są wiązane do bytów
programistycznych czasu wykonania według ścisłych reguł.
 Realizacja metod transmisji parametrów: wartości parametrów oraz
inne ich własności są odkładane w lokalnych sekcjach stosu, dzięki czemu
możliwy jest spójny dostęp i zarządzanie parametrami oraz realizacja
metod transmisji parametrów, takich jak wołanie przez wartość (call-byvalue) lub wołanie przez referencję (call-by-reference).
 Podane motywacje mają znaczenie dla języków zapytań, pozwalając
zrealizować takie ich założenia jak: możliwość dowolnego zagnieżdżania
zapytań, możliwość powoływania lokalnych nazw wewnątrz zapytań,
możliwość używania nazw z bazy danych łącznie z nazwami zmiennych
programistycznych, nazwami procedur, funkcji i metod.
• Nie uwzględnienie mechanizmu stosu środowiskowego w typowych
podejściach do języków zapytań, takich jak algebra relacji, rachunek
relacyjny, logika matematyczna, itd. z góry skazuje je na ograniczenia.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 128
kwiecień 2002
Stos statyczny i dynamiczny
static stack, dynamic stack
 W typowych językach nazwy występujące w programie są drugiej
kategorii programistycznej: nie są dostępne podczas wykonania programu.
 Dla takich języków stos środowiskowy musi istnieć w dwóch postaciach:
stos zarządzany podczas kompilacji (stos statyczny), oraz stos czasu
wykonania (stos dynamiczny).
 Wiązanie nazw odbywa się początkowo na stosie statycznym i ostatecznie
na dynamicznym.
• Podczas kompilacji stos statyczny symuluje działanie stosu dynamicznego jest podwyższany lub skracany w miarę postępu analizy syntaktycznej.
• Stos statyczny przechowuje nazwy bytów programistycznych, ich sygnatury,
oraz informacje o ich reprezentacji. Wiązanie nazw nie jest bezwzględne, lecz
relatywne, z dokładnością do odległości (mierzonej w bajtach) położenia
reprezentacji danej wartości od wierzchołka stosu dynamicznego.
• Dopiero podczas wykonania następuje ostateczne obliczenie adresu
ulokowania danego bytu programistycznego np. poprzez odjęcie adresu
relatywnego od aktualnego rozmiaru stosu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 129
kwiecień 2002
Stos środowisk w SBA (1)
 Stos środowisk dostosujemy do wymagań semantyki języków zapytań
oraz konstrukcji pochodnych, takich jak perspektywy, procedury bazy
danych, itd. Stos będzie spełniać następujące założenia:
• Będzie zgodny z modelami składu M0 - M3.
• Będzie w jednorodny sposób traktował dane indywidualne i kolekcje.
• Maksymalny rozmiar stosu nie będzie implementacyjnie ograniczony.
• Stos będzie składał się z sekcji, gdzie każda sekcja będzie przechowywać
informację o pewnym środowisku czasu wykonania, np. środowisku
wywołania pewnej funkcji, procedury lub metody, środowisku wnętrza
pewnego obiektu, środowisku wnętrza pewnej klasy, środowisku obiektów
bazy danych, itd. Rozmiar sekcji nie będzie ograniczony.
• Na dole stosu umieszczone będą sekcje globalne, do których należą globalne
zmienne aplikacji, baza danych, wspólne biblioteki procedur i funkcji, oraz
zmienne środowiskowe systemu komputerowego.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 130
kwiecień 2002
Stos środowisk w SBA (2)
• Stos będzie więc przechowywał pełną informację niezbędną do wiązania
dowolnej nazwy, która może wystąpić w zapytaniu, perspektywie,
procedurze, trygerze lub programie aplikacyjnym.
• Stos będzie w jednakowy sposób traktował zarówno dane trwałe (persistent)
przechowywane w bazie danych, dane chwilowe będące danymi lokalnymi
wywoływanych procedur, funkcji i metod, dane chwilowe będące danymi
globalnymi aplikacji, oraz aktualne parametry procedur lub metod.
• Stos będzie także miejscem przechowywania informacji o definicjach
wprowadzanych w zapytaniach lub w programach. M.in. będzie on
przechowywał informację o tzw. „synonimach” lub „zmiennych
korelacyjnych” (w SQL lub OQL), zmiennych związanych kwantyfikatorami,
zmiennych używanych w iteratorach „for each”, itd.
• W odróżnieniu od języków programowania, gdzie stos jest jednocześnie
składem wartości zmiennych, nasz stos jest strukturą różną od składu
obiektów. Powodem jest to, że w budowanej przez nas semantyce odwołania
do tego samego obiektu mogą pojawić się w różnych sekcjach stosu.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 131
kwiecień 2002
Binder
binder
 Elementarną strukturą przechowywaną na stosie środowisk jest binder.
 Binder jest parą <n, x>, gdzie n jest zewnętrzną nazwą (nazwą zmiennej,
stałej, obiektu, funkcji, perspektywy, procedury, metody, itd.), zaś x jest
bytem czasu wykonania (zwykle referencją do obiektu).
• Parę <n, x> będziemy zapisywać n( x ).
• Definicję tę uogólnimy.
 Koncepcja bindera jest bardzo prosta. Zadaniem bindera n(x) jest wiązanie
(binding), czyli zastąpienie nazwy n występującej w zapytaniu lub
programie na wartość x, będącą bytem czasu wykonania.
• Dla dowolnej nazwy występującej w programie musi być na stosie
odpowiedni binder, który zamieni tę nazwę na byt czasu wykonania.
• Nazwa, dla której odpowiadający jej binder nie istnieje, nie może być
związana, czyli jest błędna.
• Przy luźnych modelach składu, tzw. półstrukturalnych, (semistructured)
możemy uznać, że wiązanie takiej nazwy jest puste (jest pustym zbiorem).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 132
kwiecień 2002
Rola binderów
 Uogólnienie: Binder jest parą n(x), gdzie n może być dowolną zewnętrzną
nazwą definiowaną przez programistę, użytkownika, projektanta aplikacji,
projektanta bazy danych, itp., zaś x może być dowolnym rezultatem
zwracanym przez zapytanie.
 W podejściu stosowym do języków zapytań stos środowisk składa się z
sekcji odpowiadających poszczególnym środowiskom czasu wykonania.
 Sekcja stosu jest zbiorem binderów do bytów programistycznych
odpowiadającego jej środowiska.
 W budowanej przez nas semantyce bindery będą miały także inne
zastosowania, w szczególności, będą niekiedy zwracane jako rezultaty
zapytań.
 Stos środowiskowy będziemy oznaczać ENVS (ENVironment Stack).
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 133
kwiecień 2002
Przykładowy skład
Obiekty trwałe
Obiekty ulotne
i127 X
i128 Y
i1 Prac
i5 Prac
i9 Prac
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 134
i17 Dział
i22 Dział
kwiecień 2002
Przykładowy ENVS
Sekcja chwilowa przetwarzania
Prac(i1)
Sekcja chwilowa przetwarzania
- własności lokalne wywołanej
metody
X(i127) Y(i128) N(5) I("Maria")
Sekcja chwilowa przetwarzania
- własności wnętrza aktualnie
przetwarzanego obiektu Prac
Nazwisko(i10) Zarobek(i11) Adres(i12)
PracujeW(i16)
.........
.........
Bindery do obiektów/zmiennych nietrwałych
aktualnej sesji użytkownika
Prac(i1) Prac(i5) Prac(i9) Dział(i17) Dział(i22)
Sekcje danych globalnych
Sekcja bazy
danych
Bindery do globalnych funkcji
bibliotecznych
Bindery do zmiennych i funkcji środowiska
komputerowego
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 135
kwiecień 2002
Pojęcie stanu
 Pojedyncza referencja jest szczególnym przypadkiem rezultatu zapytania.
• W ten sposób, poprzez definicję składu obiektów i stosu ENVS uzyskaliśmy
precyzyjną definicje pojęcia stanu.
 W podejściu stosowym Stan jest definiowany jako stan składu
obiektów plus stan stosu środowisk.
• Brak pojęcia stanu jest bardzo poważną wadą wielu koncepcji i modeli
obiektowych, w szczególności standardów SQL3, SQL1999 i ODMG.
• Zgodnie z wcześniejszymi definicjami, semantyka zapytania jest funkcją
odwzorowującą stan, czyli skład obiektów oraz stan ENVS, w rezultat.
 Odwzorowaniem, które będzie podstawą dalszych definicji, jest
semantyka pojedynczej nazwy występującej w zapytaniu lub w programie.
 Czynność ewaluacji takiej nazwy nosi nazwę wiązania.
• Wiązanie odbywa się na ENVS zgodnie z regułą stosu, które nakazuje
przeszukiwanie stosu od jego wierzchołka w kierunku jego podstawy, z
pominięciem niektórych sekcji.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 136
kwiecień 2002
Reguły wiązania nazw
 Zasady przeszukiwania stosu i wyznaczania rezultatu wiązania są
następujące:
 Przeszukiwanie ENVS zaczyna się od jego wierzchołkowej sekcji, w dół,
aż do jego dolnej sekcji.
 Dla wiązanej nazwy n, ENVS jest przeszukiwany aż do znalezienia sekcji,
w której znajduje się binder oznaczony nazwą n. Po znalezieniu takiej
sekcji wyszukiwanie jest zakończone.
 Wszystkie bindery z tej sekcji oznaczone nazwą n tworzą rezultat
przeszukiwania.
 Rezultat wiązania uzyskuje się poprzez odrzucenie ze znalezionych
binderów nazwy n i pozostawienie wyłącznie wartości tych binderów.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 137
kwiecień 2002
Mechanizm przeszukiwania stosu - funkcja bind
start przeszukiwania
stosu
Prac(i1)
X(i127) Y(i128) N(5)
I("Anna")
 bind( nazwa ) - funkcja wiązania nazw:
.........
Nazwisko(i10)
Zarobek(i11) Adres(i12)
PracujeW(i16)
.........
Prac(i1) Prac(i5) Prac(i9)
Dział(i17) Dział(i22)
•
•
•
•
•
bind( Prac ) = i1
bind( Y ) = i128
bind( I ) = "Anna"
bind( Zarobek ) = i11
bind( Dział ) = { i17, i22 }
.........
Binder Prac(i1) znajduje się w dwóch sekcjach stosu, ale w tym
przypadku wiązanie nazwy Prac zwróci i1, a nie {i1, i5, i9 }.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 138
kwiecień 2002
Rezultaty zwracane przez zapytania
 Oprócz referencji i wartości atomowych zapytania mogą zwrócić bindery.
 Uogólnienie podanych założeń prowadzi do następującej rekurencyjnej
definicji dziedziny Rezultat:
• Atomowa wartość należąca do V (np. 3, "Kowalski", TRUE, itd.) należy do
dziedziny Rezultat.
• Referencja do obiektu (inaczej identyfikator obiektu) dowolnego typu
należąca do I należy do dziedziny Rezultat. W szczególności, do dziedziny
Rezultat należą referencje do metod, procedur, funkcji, perspektyw, itd.
• Jeżeli x  Rezultat, zaś n  N jest dowolną nazwą, wówczas para n(x) należy
do dziedziny Rezultat. Taki rezultat będziemy nazywać nazwaną wartością;
w innym kontekście został on już określony jako binder.
• Jeżeli x1, x2, x3, ...  Rezultat, wówczas struct{ x1, x2, x3, ...}  Rezultat.
struct jest konstruktorem struktury, czyli pewnym dodatkowym atrybutem
(flagą) rezultatu. Kolejność elementów w strukturze ma znaczenie.
• Jeżeli x1, x2, x3, ...  Rezultat, wówczas bag{ x1, x2, x3, ...}  Rezultat oraz
sequence{ x1, x2, x3, ...}  Rezultat.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 139
kwiecień 2002
Przykłady zbioru Rezultat
 Atomowe:
• 25, "Kowalski", i11, i18
 Złożone:
• struct{i1, i56}
• sequence{ i1, i6, i11}
• bag{ struct{i1, i56}, struct{i6, i72}, struct{i11, i72}}
• bag{struct{n("Kowalski"), Zarobek(2500), d(i56)}}
• bag{struct{ Dział(i56), Prac( bag{ struct{ n("Nowak"), s(i9 ) },
struct{ n("Stec" ), s(i14) }})}
 Przy pomocy podanych konstruktorów można tworzyć struktury
przypominające obiekty. Nie są one jednak obiektami, ponieważ nie
można im przypisać własnych identyfikatorów i nie można ich związać z
istniejącą lub nową klasą. Są one wartościami, jakkolwiek złożonymi.
• Używając terminologii ODMG, rezultaty zapytań są literalami. Takiej
terminologii nie będziemy stosować.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 140
kwiecień 2002
Rezultaty zapytań zapisane jako tablice
sequence{ i1, i6, i11}
bag{ struct{i1, i56},
struct{i6, i72},
struct{i11, i72}}
bag{ struct{ n("Nowak"), s(i9)},
struct{ n("Stec"), s(i14)},
struct{ n("Mikuła" ), s(i18)}}
n
i1
i6
i11
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 141
i1 i56
i6 i72
i11 i72
s
"Nowak" i9
"Stec"
i14
"Mikuła" i18
kwiecień 2002
Otwieranie nowego zakresu na stosie środowisk
• W klasycznych językach programowania otwieranie nowego zakresu na
wierzchołku ENVS następuje w momencie wywołania procedury (funkcji,
metody) lub w momencie wejścia sterowania w nowy blok. Skasowanie tej
sekcji następuje w momencie zakończenia działania procedury (funkcji,
metody) lub w momencie wyjścia sterowania z bloku.
 Do klasycznych sytuacji otwierania nowego zakresu na ENVS dołączymy
nową. Stanowi ona istotę podejścia stosowego do języków zapytań.
Pewne operatory występujące w zapytaniach (zwane nie-algebraicznymi)
działają na stosie podobnie do wywołań bloków programów.
• Np. w zapytaniu języka SBQL:
Prac where (Nazwisko = ”Kowalski” and Zarobek > 1000)
część (Nazwisko = ”Kowalski” and Zarobek > 1000) jest blokiem, który jest
ewaluowany w nowym środowisku określonym przez “wnętrze” obiektu Prac
aktualnie testowanego przez operator where.
• Na stos ENVS jest wkładana nowa sekcja zawierająca bindery do wszystkich
wewnętrznych własności (atrybutów, metod, itd.) tego obiektu Prac.
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 142
kwiecień 2002
Ilustracja otwierania nowego zakresu
Operator where iteruje po rezultacie zapytania PRAC .
W każdej iteracji wkłada (i po ewaluacji zdejmuje) sekcję stosu
zawierającą bindery do wnętrza kolejnego obiektu PRAC.
PRAC
wiązanie
where (Nazwisko = ”Kowalski” and Zarobek > 1000)
wiązanie
wiązanie
Nazwisko(i10) Zarobek(i11)
Adres(i12) PracujeW(i16)
PRAC (i1) PRAC (i5) PRAC(i9)
DZIAŁ (i17) DZIAŁ (i22)
Stos w momencie ewaluacji zapytania
PRAC . Ewaluacja (wiązanie) nazwy
PRAC zwraca {i1, i5, i9}
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 143
PRAC (i1) PRAC (i5) PRAC(i9)
DZIAŁ (i17) DZIAŁ (i22)
Stos w momencie ewaluacji pod-zapytania
(Nazwisko = ”Kowalski” and Zarobek > 1000)
dla trzeciego obiektu PRAC.
Ewaluacja (wiązanie) nazwy Nazwisko zwraca i10.
Ewaluacja (wiązanie) nazwy Zarobek zwraca i11.
kwiecień 2002
Co wkładamy na ENVST - funkcja nested
 Intencją jest zdefiniowanie funkcji, której argumentem jest referencja do
obiektu, zaś wynikiem jest wewnętrzne środowisko tego obiektu, które ma
być umieszczone na ENVS.
 Takie środowisko jest zbiorem binderów.
 Funkcję nazwaliśmy nested.
i9 Prac
i10 Nazwisko ”Barski”
i11 Zarobek 2000
i12 Adres
i13 Miasto ”Radom”
i14 Ulica ”Wolska”
i15 NrDomu 12
i16 PracujeW
nested(i9) = { Nazwisko (i10 ), Zarobek (i11 ), Adres (i12 ), PracujeW (i16 ) }
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 144
kwiecień 2002
Uogólnienie funkcji nested
 Dla dowolnej wartości atomowej v  V  nested( v ) =  (zbiór pusty).
 Dla identyfikatora i obiektu atomowego (nie posiadającego podobiektów)
 nested( i ) = .
 Dla obiektu złożonego <i, n, {<i1, n1, ...>, <i2, n2, ...>, ... , <ik, nk, ...> }>
 nested( i ) = { n1(i1), n2(i2), ... , nk(ik) }.
 Dla identyfikatora i obiektu pointerowego <i, n, i1> dla którego istnieje w
składzie obiekt < i1, n1, ...>  nested( i ) = { n1(i1) }.
 Dla dowolnego bindera n(x)  nested( n(x) ) = { n(x) }.
 Jeżeli argumentem funkcji nested jest struktura elementów, wówczas
wynik jest sumą teorio-mnogościową rezultatów funkcji nested dla
pojedynczych elementów tej struktury 
nested( struct{ x1, x2, x3, ...}) = nested( x1 )  nested( x2 )  nested( x3 )  ...
© K.Subieta. Obiektowe języki zapytań 1..5, Folia 145
kwiecień 2002