Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

© K.Subieta. Obiektowe języki zapytań 1..5, Folia 1 kwiecień 2002 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła.

Podobne prezentacje


Prezentacja na temat: "© K.Subieta. Obiektowe języki zapytań 1..5, Folia 1 kwiecień 2002 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła."— Zapis prezentacji:

1 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 1 kwiecień 2002 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa Wykłady 1..5

2 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 2 kwiecień 2002 Plan wykładów 1..5 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 z tej serii będą poświęcone językowi SBQL, oraz konstrukcjom imperatywnym i perspektywom bazującym na SBQL. Cel tej serii wykładów - objaśnienie podejścia stosowego do obiektowych języków zapytań

3 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 3 kwiecień 2002 Wykład 1

4 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 4 kwiecień 2002 Generalne założenia podejścia stosowego 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. stack-based approach, SBA

5 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 5 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.

6 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 6 kwiecień 2002 Wprowadzenie do języków zapytań

7 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 7 kwiecień 2002 Ogólna charakterystyka języków zapytań 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. query languages

8 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 8 kwiecień 2002 Czy przyszłością języków zapytań jest SQL/OQL? Obie propozycje są kontrowersyjne. SQL3 - SQL 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.

9 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 9 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 q 1, którego czas wykonania jest dramatycznie długi (np. tysiąc lat), na semantycznie równoważne zapytanie q 2 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.

10 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 10 kwiecień 2002 Co to są "języki zapytań"? 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. Istnieje na ten temat wiele poglądów, np.:

11 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 11 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).

12 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 12 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.

13 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 13 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.

14 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 14 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).

15 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 15 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.

16 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 16 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ą.

17 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 17 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.

18 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 18 kwiecień 2002 Zasady języków zapytań (1) 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. 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ń.

19 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 19 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ń.

20 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 20 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.

21 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 21 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ń.

22 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 22 kwiecień 2002 Optymalizacja zapytań 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): wymaga wykonania produktu kartezjańskiego relacji wymienionych w klauzuli from. Przyjmując dostawców, produktów, krotek w relacji DP i średnio 100 bajtów w każdej krotce tych relacji, produkt kartezjański miałby elementów i zajmowałby 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 sekund, czyli 317 lat. Dzięki metodom optymalizacyjnym obliczenie powyższego zapytania trwa kilka sekund i nie wymaga zbyt dużo pamięci. select Dostawca.nazwisko from Dostawca, Produkt, DP where Dostawca.NrDost = DP.NrDost and DP.NrProd = Produkt.NrProd and Produkt.nazwa = zawór query optimization

23 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 23 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.

24 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 24 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.

25 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 25 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.

26 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 26 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.

27 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 27 kwiecień 2002 Wykład 2

28 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 28 kwiecień 2002 Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja

29 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 29 kwiecień 2002 Obiekt 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ć. object

30 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 30 kwiecień 2002 Tożsamość obiektu, identyfikator obiektu 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. object identity

31 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 31 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).

32 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 32 kwiecień 2002 Stan obiektu, atrybuty obiektu 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,... object state

33 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 33 kwiecień 2002 Przykład obiektu Czy oprócz wymienionych metod można będzie dostać się do stanu obiektu poprzez nazwy atrybutów ? Tak. Kwestia zostanie rozpatrzona dalej. Wypłać Wpłać Sprawdź stan Upoważnij Zmień upoważnienie Porównaj podpis Zlikwiduj konto Nalicz procent KONTO Numer SaldoZł Właściciel Jan Kowalski Upoważniony Ewa Kowalska....

34 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 34 kwiecień 2002 Obiekt złożony 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. complex object

35 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 35 kwiecień 2002 Zasada relatywizmu obiektów 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. object relativism

36 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 36 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.

37 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 37 kwiecień 2002 Zasada wewnętrznej identyfikacji 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,,, itd. nie jest dobrą identyfikacją atrybutu, jeżeli jest on wielowartościowy. Każda wartość takiego atrybutu musi mieć unikalną identyfikację. 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ą. internal identification

38 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 38 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.

39 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 39 kwiecień 2002 Powiązania pomiędzy obiektami 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 Nazwisko Kowal Zarobek 2500 PracujeW PRACOWNIK Nazwisko Babel Zarobek 2000 PracujeW PRACOWNIK Nazwisko Nowak Zarobek 1500 PracujeW FIRMA Szef NrFirmy Nazwa Syntex Zatrudnia pointer links, relationships

40 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 40 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.

41 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 41 kwiecień 2002 Podaj nazwisko szefa Nowaka: SQL: SBQL: 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. Przykład wykorzystania powiązań pointerowych select s.Nazwisko from PRACOWNIK p, FIRMA f, PRACOWNIK s where p.NrFirmy = f.NrFirmy and f.Szef = s.NrPracownika and p.Nazwisko = "Nowak" (PRACOWNIK where Nazwisko = "Nowak"). PracujeW.FIRMA.Szef.PRACOWNIK.Nazwisko

42 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 42 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.

43 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 43 kwiecień 2002 Zamiana powiązań n-arnych na binarne OSOBA Nowak Pośrednik Transakcja Samochód OSOBA Bielicka OSOBA Maciąg Kupujący Sprzedający Pośrednik Transakcja Plac OSOBA Kowalska OSOBA Bober Kupujący Sprzedający OSOBA Nowak Pośrednik OSOBA Bielicka OSOBA Maciąg Kupujący Sprzedający Pośrednik OSOBA Kowalska OSOBA Bober Kupujący Sprzedający TRANSAKCJA Plac TRANSAKCJA Samochód

44 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 44 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 ".

45 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 45 kwiecień 2002 Hermetyzacja i ukrywanie informacji 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ę. encapsulation information hiding

46 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 46 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".

47 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 47 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).

48 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 48 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. PRACOWNIK NAZWISKO NowakROK_UR 1951 ZAROBEK 2500 ZmieńZarobek(...) {...}; Podatek(){...}; ZarobekNetto() {...}; Wiek() { return RokBież - ROK_UR }; DZIAŁ Zabawki Wewnętrzna struktura obiektuZewnętrzna struktura obiektu PRACOWNIK NAZWISKO Nowak ZmieńZarobek(...) ZarobekNetto() Wiek() DZIAŁ Zabawki

49 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 49 kwiecień 2002 Komunikat 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: Komunikat: 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: Wypłać( KontoKowalskiego, 1000 ); KontoKowalskiego. Wypłać( 1000 ); (PRACOWNIK where Wiek > 45). Nazwisko komunikat message

50 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 50 kwiecień 2002 Klasa Zła definicja: klasa jest to zbiór obiektów (jest to raczej ekstensja klasy). Dobra definicja: Klasa jest miejscem przechowywania tych informacji dotyczących obiektów, które są dla nich niezmienne, wspólne lub dotyczą całej ich populacji. Takie informacje są nazywane inwariantami obiektów. Inwarianty dotyczące jednego obiektu mogą być przechowywane w wielu klasach, tworzących hierarchię lub inną strukturę dziedziczenia. Poprzez przypisanie obiektów do klas unika się przechowywania inwariantów wewnątrz każdego obiektu. Klasa stanowi więc coś w rodzaju czynnika wyciągniętego przed nawias dla pewnej populacji obiektów. Takie wyciągnięcie przed nawias ma ogromne znaczenie dla modelowania pojęciowego, pozwalając operować zestawem inwariantów jak abstrakcją zastępującą zarówno poszczególne egzemplarze obiektów, jak i pewną ich populację. class

51 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 51 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);

52 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 52 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.

53 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 53 kwiecień 2002 Interfejs Interfejs zawiera komplet informacji o tych własnościach klasy, które są niezbędne do poprawnego manipulowania obiektami tej klasy. Interfejs posiada znaczenie pojęciowe dla użytkownika lub programisty i pozwala na wystarczająco dokładne przedstawienie tego, co obiekt zawiera w swoim wnętrzu (tj. interfejs określa odpowiedni fragment schematu obiektowego) i jak nim manipulować. Praktycznym kryterium rozróżnienia pomiędzy klasą i interfejsem jest fakt, że klasa może być przedmiotem obrotu handlowego, podczas gdy interfejs takiemu obrotowi nie podlega. Interfejs jest pojęciem różnym od pojęcia typu. Typ jest specyfikacją klasy ograniczająca kontekst, w którym obiekty tej klasy mogą być użyte w wyrażeniach, zapytaniach lub programach. Jednocześnie typ określa często reprezentację wartości. Często interfejsu nie odróżnia się od typu, lub typ jest składnikiem interfejsu. interface

54 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 54 kwiecień 2002 Hierarchia klas i dziedziczenie Klasę można budować wyłącznie na zasadzie formalistycznego wyciągnięciem przed nawias pewnego zestawu inwariantów. Częściej jednak klasa posiada niezależne znaczenie dla modelowania pojęciowego jako ogólna abstrakcja budowana przez projektanta lub programistę w celu odwzorowania niezmiennych własności obiektów. Dziedziczenie oznacza, że dla przetwarzania obiektu programista może wykorzystywać dowolne inwarianty z klasy, której dany obiekt jest członkiem, lub z dowolnych nadklas tej klasy. Ważnym aspektem tworzenia hierarchii klas jest unikanie redundancji, zarówno redundancji kodu jak i redundancji koncepcyjnej. Innym ważnym aspektem jest zwiększenie potencjału ponownego użycia: raz zdefiniowana klasa może być wielokrotnie użyta dla stworzenia jej specjalizacji. Zasada "otwarta-zamknięta" (open-close principle): klasa jest zamknięta dla modyfikacji, ale otwarta dla rozszerzeń. class hierarchy, inheritance

55 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 55 kwiecień 2002 Przykład klas i dziedziczenia PRACOWNIK Zarobek Firma Zdjęcie ZarobekNetto() ZmieńZarobek(...) STUDENT NrIndeksu RokStudiów Wydział WstawOcenę(...) ZaliczSemestr() OSOBA Nazwisko Imię RokUrodz Wiek() obiekt

56 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 56 kwiecień 2002 Zasada zamienialności Oznaczana też LSP (Liskov's Substitutability Principle) Zasada zamienialności głosi, że w każdym miejscu programu, gdzie może być użyty pewien obiekt klasy K, może być także użyty obiekt, którego klasą jest podklasa klasy K. Przykładowo, wszędzie tam, gdzie można użyć liczby całkowitej, można także użyć liczby naturalnej; wszędzie tam, gdzie można użyć obiektu Osoba można także użyć obiektu Pracownik. Ponieważ obiekt podklasy klasy K zawiera więcej atrybutów niż obiekt klasy K, zasada ta oznacza ignorowanie wszystkich tych atrybutów, które wystają poza typ oczekiwany w danym miejscu programu. Zasada ta obejmuje również metody zawarte w klasach. Ma bardziej ogólne sformułowania (dla typów obiektów). Prowadzi niestety do pewnych anomalii: np. anomalii podstawienia, anomalii wielodziedziczenia, dylematu "wariancja czy kontr-wariancja", i innych. Zasada zamienialności staje się kontrowersyjna jeżeli przyjmiemy, że inwariantem obiektów jest ich nazwa. W szczególności, przestaje obowiązywać dla modelu z dynamicznymi rolami obiektów. substitutability

57 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 57 kwiecień 2002 Ekstensja klasy Jest to nazwany zbiór obiektów aktualnie należących do danej klasy. Różne ekstensje mogą mieć wspólne części, co może być powodem trudności semantycznych. Stąd pojęcie ekstensji jest kontrowersyjne. Jest ona uważana za wątpliwe "dziedzictwo" modelu relacyjnego. OSOBA Nazwisko Babacki RokUr 1940 OSOBA Nazwisko Abacki RokUr 1948 OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) OSOBA Nazwisko Kowalska RokUr 1975 Ekstensja klasy OSOBA PRACOWNIK Nazwisko Nowak RokUr 1951 Zarobek 2000 Dział zabawki PRACOWNIK Nazwisko Abacki RokUr 1948 Zarobek 2500 Dział zabawki PRACOWNIK Nazwisko Babacki RokUr 1940 Zarobek 3000 Dział sprzedaż Ekstensja klasy PRACOWNIK extent

58 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 58 kwiecień 2002 Wielokrotne dziedziczenie Jest to dziedziczenie z kilku klas, z zsumowaniem dziedziczonych cech. Problemem wielo-dziedziczenia jest konieczność rozstrzygnięcia konfliktów nazw. Nie ma na to dobrego sposobu. POJAZD ciężar..... prędkość_eksploat() POJAZD_LĄDOWY ilość_kół max_prędkość..... POJAZD_WODNY wyporność max_prędkość..... AMFIBIA SAMOCHÓD JACHT TRAKTOR ŻAGLÓWKA multiple inheritance multi-inheritance

59 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 59 kwiecień 2002 Abstrakcyjne typ danych, ADT ADT jest oparty na założeniu, że typ struktury danych jest skojarzony z operacjami działającymi na elementach tego typu. Nie istnieje potrzeba i możliwość używania operacji nie należących do oferowanego zestawu; operacje są kompletne i wyłączne (hermetyzacja). Bezpośredni dostęp do składowych takiej struktury danych nie jest możliwy, dzięki czemu jej szczegóły implementacyjne (np. zestaw i reprezentacja atrybutów) są niewidoczne. Np. stos, wraz z operatorami push (połóż element na wierzchołku stosu), pop (zdejmij element z wierzchołka stosu), top (odczytaj element znajdujący się na wierzchołku stosu) i empty (sprawdź, czy stos jest pusty). Po zadeklarowaniu lub utworzeniu zmiennej X jako stosu, wszelkie operacje na tej zmiennej odbywają się poprzez powyższe cztery operatory. ADT jest w istocie innym spojrzeniem na pojęcia klasy i interfejsu. W związku z tym dalej zrezygnujemy z używania terminu ADT. abstract data type

60 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 60 kwiecień 2002 Polimorfizm Polimorfizm w teorii typów: umożliwienie programom lub procedurom działania jednocześnie na wielu typach. Tym nie będziemy się zajmować. Polimorfizm w obiektowości: dynamiczny wybór metody, po otrzymaniu komunikatu skierowanego do obiektu. polymorphism obiekt STUDENT.... dochody().... PRACOWNIK.... dochody().... EMERYT.... dochody().... obiekt OSOBA nazwisko kategoria.... Metody dochody są różne dla każdej klasy. Po otrzymaniu komunikatu dochody wybierana jest metoda właściwa dla klasy, do której należy dany obiekt. Polimorfizm wymaga dynamicznego wiązania. Przesłanianie jest jedną z jego form. Polimorfizm stwarza znaczny potencjał dla ponownego użycia i modyfikowalności oprogramowania.

61 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 61 kwiecień 2002 Wykład 3

62 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 62 kwiecień 2002 Dynamiczne role obiektów Stanowią odpowiedź na problemy wielokrotnego dziedziczenia oraz innych anomalii (powtarzalnego dziedziczenia, wieloaspektowego dziedziczenia, obiektów historycznych, ekspolozji liczby klas, itd.). Normalne dziedziczenie: student JEST osobą. Jest to błąd pojęciowy. To raczej osoba STAJE SIĘ studentem, i to tylko na jakiś czas. Każdy obiekt może nabywać i tracić wiele ról lub specjalizacji, nie zmieniając swojej tożsamości. Role zmieniają się dynamicznie. PACJENT CZŁONEK KLUBU PRACOWNIK STUDENT PODATNIK dane historyczne OSOBA STUDENT dynamic roles

63 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 63 kwiecień 2002 Dynamiczne role i klasy OSOBA Nazwisko Abacka RokUr 1948 OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(..) OSOBA Nazwisko Kowalska RokUr 1975 STUDENT Semestr NrIndeksu WpiszOcenę(...) ObliczŚredniąOcen() OSOBA Nazwisko Nowak RokUr 1951 Klasy OSOBA Nazwisko Nowacki RokUr 1940 Obiekty FIRMA Nazwa BankSA pracuje_w UCZELNIA Nazwa PW studiuje_na UCZELNIA Nazwa UW studiuje_najest_klientem PRACOWNIK Zarobek 2500 Dział Kredyty PRACOWNIK Zarobek 1500 Dział Obsługa STUDENT Semestr 7 NrIndeksu STUDENT Semestr 4 NrIndeksu

64 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 64 kwiecień 2002 Kolekcje Kolekcje są zestawami danych o podobnej strukturze. Rozmiaru kolekcji nie można przewidzieć ani ograniczyć. Do kolekcji zaliczane są zbiory, relacje, wielozbiory, sekwencje, listy, drzewa, itp. Popularne języki programowania nie wprowadzają pojęcia kolekcji lub silnie je ograniczają (np. Java - sekwencja referencji). Brak kolekcji w językach programowania jest powodem niezgodności impedancji pomiędzy językiem programowania i językiem zapytań. Brak kolekcji jest powodem konieczności używania sterty (heap), co np. prowadzi do wyciekania pamięci. Kolekcje mogą być zagnieżdżone (co jest najczęściej ignorowane przez teorie dotyczące obiektowych baz danych, np. obiektowe algebry). Relacje z modelu relacyjnego są przypadkiem kolekcji. Brak możliwości zagnieżdżania relacji jest utrudnieniem dla modelowania pojęciowego, ale zdaniem adwokatów modelu relacyjnego, upraszcza struktury danych i daje możliwość zastosowania matematyki. Są to poglądy kontrowersyjne. collections

65 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 65 kwiecień 2002 Przykład zagnieżdżonych kolekcji XML stwarza nowy stosunek do kolekcji: kolekcje nie są nazywane, lecz są modelowane przez identyczne nazwy obiektów. Na podobnej zasadzie jak w XML, dynamiczne role pozwalają na tworzenie heterogenicznych, wzajemnie przecinających się kolekcji - bez wprowadzania pojęcia kolekcji explicite. Pracownicy..... Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko nested collections

66 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 66 kwiecień 2002 Wartości zerowe Zwykle są oznaczane jako NULL lub NIL. Istnieje wiele przyczyn powstawania wartości zerowych, np.: Atrybut nie ma zastosowania dla danego przypadku, np. NazwiskoPanieńskie; Informacja jest nieznana, np. miejsce, gdzie został pochowany Mozart; Informacja o przyszłości, np. wynik przyszłego meczu piłkarskiego; Informacja jeszcze nie zapełniona. Większość przyczyn powstawania wartości zerowych można określić jako skutek nieregularnych w danych, które nie chcą się zmieścić w formacie. Wartości zerowe okazały się trudne dla interfejsów programistycznych, rodząc dużą liczbę anomalii, które są nie do usunięcia. Liczne patologie w SQL. XML postępuje z wartościami zerowymi bardzo prosto: daną z wartością zerową po prostu się pomija, razem z tagami. Ten sposób można uważać za najlepszy i podnieść do rangi zasady. Implikuje on pewne problemy dla mocnej kontroli typów. null values

67 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 67 kwiecień 2002 Warianty (unie) Warianty (unie) są nieregularnościami w strukturach danych. Służą do odwzorowania takich sytuacji, kiedy wystąpienia danej określonego typu mogą się różnić zestawem lub typem atrybutów. Pracownik:( Nazwisko:Nowak, Rodzaj:etatowy, Zarobek:3000 ) Pracownik:( Nazwisko:Wrona, Rodzaj:uczeń, Status:3, Stypendium:700 ) Ta sytuacja jest modelowana jako zapis z wariantami (w rodzinie języków linii Pascala) lub unia (w rodzinie C i C++); np. (w składni C): struct{ string Nazwisko; string Rodzaj; union{ int Zarobek; struct{ int Status; int Stypendium;} str;} un; } Pracownik; Warianty mogą posiadać wyróżniony atrybut, tzw. dyskryminator, który służy do rozróżnienia podczas wykonania, z którym przypadkiem mamy do czynienia. Wariant jest pojęciem podobnym do wartości zerowej ale nieco różnym. Np. jeżeli pewien zapis ma 10 atrybutów, które mogą przyjmować wartości zerowe, wówczas liczba wariantów wynosi 2 10 = variants, unions

68 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 68 kwiecień 2002 Dane pół-strukturalne Dane pół-strukturalne są nieregularne, nie mają stałego formatu. Mogą nie podlegać mocnej kontroli typu. Mogą nie posiadać schematu, lub ich schemat jest luźny. Są nowym podejściem do wartości zerowych i wariantów. Dane pół-strukturalne są typowe dla zastosowań Webowych. Przykładem danych półstrukturalnych są pliki XML. Dane pół-strukturalne implikują nowe problemy dla języków zapytań. Wymagają nowych podejść i/lub nowych operatorów. Implikują nowe problemy co do opisu ontologii biznesowej. semistructured data Osoba( Pseudonim( "Masa") Kwalifikacja( "kryminalista") Przestępstwo( "rozbój") Przestępstwo( "włamanie")) Osoba( Nazwisko( "Nowak") Imię( "Jan") Imię( "Antoni") Zawód("piekarz") ) Osoba( Nazwisko( "Kruk") Stopień("kapral") Jednostka("artyleria") )

69 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 69 kwiecień 2002 Ortogonalna trwałość Tradycyjnie, bazy danych przechowywały wyłącznie typy trwałe i masowe (zbiory, relacje, etc.). Podobnie, klasyczne języki programowania zajmowały się wyłącznie typami indywidualnymi i nietrwałymi (zmienne, struktury, zapisy, etc.). Taki podział nie ma uzasadnienia. Niekiedy niezbędne jest zapamiętanie w bazie danych pojedynczych wartości; np. adresu firmy, w której jest zainstalowany system. Brak typów masowych w językach programowania ma liczne wady. Zasada ortogonalnej trwałości oznacza nowy typ języka programowania, w którym cecha trwałości jest ortogonalna w stosunku do konstruktorów struktur danych. Oznacza to m.in., że języki zapytań w równym stopniu dotyczą: trwałych i nietrwałych danych: są ortogonalne w stosunku do trwałości, kolekcji i indywidualnych danych: są ortogonalne w stosunku do masowości. orthogonal persistence

70 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 70 kwiecień 2002 Moduł W modularnych językach programowania, takich jak Modula-2, moduł oznacza fragment programu stanowiący jednostkę przechowywania, kompilacji i konsolidacji (linking) programów. Moduł podlega regułom hermetyzacji oddzielającym specyfikację modułu od jego implementacji. Specyfikacja modułu zawiera tzw. listy eksportowe i importowe. Lista eksportowa jest odpowiednikiem pojęcia interfejsu znanego ze standardu CORBA, standardu ODMG i języka Java. Lista importowa określa obiekty innych modułów, które można użyć w danym module - skuteczny środek kontroli efektów ubocznych modułu. Z punktu widzenia koncepcji obiektowości, moduł jest obiektem, który wewnątrz może zawierać obiekty oraz inne własności, takie jak typy lub klasy. Moduły nie wprowadzają w zasadzie nowej jakości dla obiektowych języków zapytań. module

71 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 71 kwiecień 2002 Podstawy semantyczne języków zapytań

72 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 72 kwiecień 2002 Składnia, semantyka i pragmatyka języka 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. syntax, semantics, pragmatics

73 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 73 kwiecień 2002 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ą. Składnia abstrakcyjna abstract syntax

74 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 74 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.

75 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 75 kwiecień 2002 Modularność lub kompozycyjność semantyki 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ć: gdzie w 1, w 2,..., w n są podwyrażeniami wyrażenia w. Oznaczmy przez |x| semantykę napisu x. Wówczas : Zasadę tę stosujemy rekurencyjnie, t.j. semantyki |w 1 |, |w 2 |,..., |w n | 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. w = konstrukcja_składniowa(w 1, w 2,..., w n ) |w| = funkcja_zależna_od_konstrukcji_składniowej( |w 1 |, |w 2 |,..., |w n | ) modularity, compositionality

76 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 76 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.

77 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 77 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: 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ę: Jeżeli q jest zleceniem aktualizacyjnym (np. klauzulą update języka SQL), to: |q|: Stan Rezultat |q|: Stan (Rezultat Stan) |q|: Stan Stan

78 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 78 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.

79 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 79 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.

80 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 80 kwiecień 2002 Co to jest "stan"? 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). state

81 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 81 kwiecień 2002 Modele składu obiektów

82 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 82 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.

83 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 83 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ą.

84 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 84 kwiecień 2002 Modele składu obiektów 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. object store

85 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 85 kwiecień 2002 Wykład 4

86 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 86 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.

87 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 87 kwiecień 2002 Model M0 składu obiektów

88 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 88 kwiecień 2002 Model M0 I - zbiór identyfikatorów (i, i 1, i 2,... - oznaczenia identyfikatorów) N - zbiór nazw (n, n 1, n 2,... - oznaczenia nazw) V - zbiór wartości atomowych (v, v 1, v 2,... - oznaczenia wartości) Obiekt atomowy: trójka. Obiekt pointerowy: trójka. Obiekt jest identyfikowany przez i 1, natomiast i 2 jest pointerem (referencją) do innego obiektu. Obiekt złożony: trójka, 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, 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.

89 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 89 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, to powinien istnieć również obiekt posiadający identyfikator i 2. 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 i 2 oraz jest osiągalny obiekt pointerowy. 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.

90 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 90 kwiecień 2002 Przykład składu w modelu M0 Dział [0..*] Nazwa Lokacja[1..*] Diagram klas PracujeW Zatrudnia [1..*] Prac [0..*] Nazwisko Zar Adres [0..1] Miasto Ulica NrDomu S - Obiekty:,, } >,,, } >,,,, } >,,,, } >,,, } > R - Identyfikatory startowe: i 1, i 5, i 9, i 17, i 22

91 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 91 kwiecień 2002 Poglądowy obraz małej bazy danych i 1 Prac i 2 Nazwisko Nowak i 3 Zar 2500 i 4 PracujeW i 5 Prac i 6 Nazwisko Kowalski i 7 Zar 2000 i 8 PracujeW i 9 Prac i 10 Nazwisko Barski i 11 Zar 900 i 16 PracujeW i 13 Miasto Radom i 14 Ulica Wolska i 15 NrDomu 12 i 12 Adres i 17 Dział i 18 Nazwa Produkcja i 19 Lokacja Kielce i 21 Zatrudnia i 20 Lokacja Kraków i 22 Dział i 23 Nazwa Sprzedaż i 24 Lokacja Radom i 25 Zatrudnia i 26 Zatrudnia

92 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 92 kwiecień 2002 Relatywizm obiektów 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. object relativism

93 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 93 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.

94 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 94 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 (NF 2 ) 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.

95 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 95 kwiecień 2002 Relacja zapisana w modelu M0 Schemat relacyjny: Prac( Nazwisko, Zarobek, PracujeW ) Nazwisko Nowak Kowalski Barski Zarobek PracujeW Produkcja Sprzedaż Relacja: Prac S - Obiekty:, } >,, } >,, } > R - Identyfikatory startowe: i 1, i 5, i 9 Model składu obiektów: Krotki relacji jako obiekty złożone

96 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 96 kwiecień 2002 Jan Kowalski S - Obiekty: < i 1, pracownik, {, } > R - Identyfikatory startowe: i 1 Model składu obiektów M0: Plik XML Dokument XML zapisany w modelu M0 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?

97 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 97 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ć:,, }> Przy takim modelu dostęp do elementu tablicy następowałby poprzez indeks, np. Dzieci.2 oznaczałoby wiązanie do identyfikatora i 3 (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 i 4. Są inne metody realizacji pojęcia sekwencji w ramach modelu M0.

98 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 98 kwiecień 2002 Model M1 składu obiektów

99 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 99 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, 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 KK, i 1 oznacza identyfikator klasy dziedziczącej, zaś i 2 oznacza identyfikator klasy z której się dziedziczy. Model M1 obejmuje wielokrotne dziedziczenie.

100 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 100 kwiecień 2002 Przykład modelu M1 S - Obiekty i klasy:, } >,,,, } >,,,, } >,, inwariant: Nazwa obiektów = "Osoba",..pozostałe inwarianty klasy KlasaOsoba..}>,, inwariant: Nazwa obiektów = "Prac";..pozostałe inwarianty klasy KlasaPrac.. }>, R - Identyfikatory startowe: i 1, i 4, i 9 KK - Związki dziedziczenia między klasami: OK - Związki dziedziczenia między obiektami i klasami:,,

101 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 101 kwiecień 2002 Graficzna reprezentacja przykładu modelu M1 i 40 KlasaOsoba i 41 Wiek (...kod...) i 50 KlasaPrac i 51 ZmieńZar (...kod...) i 52 ZarNetto (...kod...) i 4 Prac i 5 Nazwisko Nowak i 7 Zar 2500 i 8 PracujeW i 6 RokUr 1944 i 127 i 1 Osoba i 2 Nazwisko Wilski i 3 RokUr 1950 i 128 i 9 Prac i 10 Nazwisko Kowalski i 12 Zar 2000 i 13 PracujeW i 11 RokUr 1940 Osoba Nazwisko RokUr Wiek Prac Zar ZmieńZar ZarNetto PracujeW

102 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 102 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.

103 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 103 kwiecień 2002 Model M2 składu obiektów

104 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 104 kwiecień 2002 Model M2 - dynamiczne role Model M2 jest uporządkowaną piątką, 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.

105 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 105 kwiecień 2002 Przykład modelu M2 S - Obiekty i klasy:, } >,,...pozostałe inwarianty klasy KlasaOsoba...}>,,...pozostałe inwarianty klasy KlasaPrac... }>,,...pozostałe inwarianty klasy KlasaStudent... }>, R - Identyfikatory startowe: i 1, i 4, i 7, i 13, i 16, i 19 KK - Związki dziedziczenia między klasami: Zbiór pusty OK - Związki dziedziczenia między obiektami i klasami:,,,,,, OO - Związki dziedziczenia między obiektami i obiektami:,,

106 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 106 kwiecień 2002 Graficzna reprezentacja przykładu modelu M2 i 1 Osoba i 2 Nazwisko Wilski i 3 RokUr 1950 i 40 KlasaOsoba i 41 Wiek (...kod...) i 50 KlasaPrac i 51 ZmieńZar (...kod...) i 52 ZarNetto (...kod...) i 60 KlasaStudent i 61 ŚredniaOcen (...kod...) i 13 Prac i 14 Zar 2500 i 15 PracujeW i 127 i 4 Osoba i 5 Nazwisko Nowak i 6 RokUr 1944 i 7 Osoba i 8 Nazwisko Kowalski i 9 RokUr 1940 i 128 i 16 Prac i 17 Zar 2000 i 18 PracujeW i 19 Student i 20 NrIndeksu i 21 Wydział fizyka

107 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 107 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.

108 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 108 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.

109 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 109 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.

110 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 110 kwiecień 2002 Model M3 składu obiektów

111 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 111 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.

112 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 112 kwiecień 2002 Przykład modelu M3 S - Obiekty i klasy:, } >,,,, } >,,,, } >,, inwariant: Nazwa obiektów = "Osoba", inwariant: Lista eksportowa = {"Nazwisko", "Wiek"},..pozostałe inwarianty klasy KlasaOsoba..}>,, inwariant: Nazwa obiektów = "Prac"; inwariant: Lista eksportowa = {"PracujeW", "ZmieńZar", "ZarNetto" },..pozostałe inwarianty klasy KlasaPrac.. }>, R - Identyfikatory startowe: i 1, i 4, i 9 KK - Związki dziedziczenia między klasami: OK - Związki dziedziczenia między obiektami i klasami:,, +PracujeW Osoba + Nazwisko - RokUr + Wiek Prac - Zar + ZmieńZar + ZarNetto

113 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 113 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.

114 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 114 kwiecień 2002 Wykład 5

115 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 115 kwiecień 2002 Stos środowisk i wiązanie nazw

116 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 116 kwiecień 2002 Stos środowisk 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ń. environment stack

117 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 117 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 S2 S3 sterowanie

118 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 118 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.

119 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 119 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.

120 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 120 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.

121 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 121 kwiecień 2002 Ilustracja działania stosu środowisk Procedura p1 wywołuje procedurę p2, która wywołuje procedurę p3 czas... Sekcja danych globalnych Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wywołanie p1 Sekcja lokalnych danych i parametrów procedury p2 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wywołanie p2 Sekcja lokalnych danych i parametrów procedury p3 Sekcja lokalnych danych i parametrów procedury p2 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wywołanie p3 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wyjście z p2 Wyjście z p1... Sekcja danych globalnych Sekcja lokalnych danych i parametrów procedury p2 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wyjście z p3

122 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 122 kwiecień 2002 Wiązanie (1) 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. binding

123 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 123 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.

124 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 124 kwiecień 2002 Przykładowa sytuacja na stosie środowisk 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 p Zmienne i inne byty globalne Wierzchołek stosu Dół stosu Kolejność poszukiwania wiązania dla zmiennej g 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; g := 75;... };... } Wykonywany jest blok l w procedurze p2 wywołanej z p1.

125 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 125 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.

126 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 126 kwiecień 2002 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. Podobnie dla języków obiektowych (do tego tematu dojdziemy). Zmienne zadeklarowane wewnątrz bloku b 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ł m Referencje do wszystkich modułów Referencje do własności środowiska globalnego Wierzchołek stosu Dół stosu Kolejność poszukiwania zmiennej x Statyczna kontrola zakresu dla modułów

127 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 127 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.

128 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 128 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-by- value) 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.

129 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 129 kwiecień 2002 Stos statyczny i dynamiczny 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. static stack, dynamic stack

130 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 130 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.

131 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 131 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.

132 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 132 kwiecień 2002 Binder Elementarną strukturą przechowywaną na stosie środowisk jest binder. Binder jest parą, 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ę 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). binder

133 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 133 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).

134 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 134 kwiecień 2002 Przykładowy skład i 1 Prac i 5 Prac i 9 Prac i 17 Dział i 22 Dział Obiekty trwałe i 127 Xi 128 Y Obiekty ulotne

135 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 135 kwiecień 2002 Przykładowy ENVS Sekcja chwilowa przetwarzania Sekcja chwilowa przetwarzania - własności lokalne wywołanej metody Sekcja chwilowa przetwarzania - własności wnętrza aktualnie przetwarzanego obiektu Prac Sekcje danych globalnych Prac(i 1 ) X(i 127 ) Y(i 128 ) N(5) I("Maria") Nazwisko(i 10 ) Zarobek(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Bindery do obiektów/zmiennych nietrwałych aktualnej sesji użytkownika Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Bindery do globalnych funkcji bibliotecznych Bindery do zmiennych i funkcji środowiska komputerowego Sekcja bazy danych

136 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 136 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.

137 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 137 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.

138 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 138 kwiecień 2002 Prac(i 1 ) X(i 127 ) Y(i 128 ) N(5) I("Anna") Nazwisko(i 10 ) Zarobek(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) start przeszukiwania stosu Mechanizm przeszukiwania stosu - funkcja bind bind( nazwa ) - funkcja wiązania nazw: bind( Prac ) = i 1 bind( Y ) = i 128 bind( I ) = "Anna" bind( Zarobek ) = i 11 bind( Dział ) = { i 17, i 22 } Binder Prac(i 1 ) znajduje się w dwóch sekcjach stosu, ale w tym przypadku wiązanie nazwy Prac zwróci i 1, a nie {i 1, i 5, i 9 }.

139 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 139 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 x 1, x 2, x 3,... Rezultat, wówczas struct{ x 1, x 2, x 3,...} Rezultat. struct jest konstruktorem struktury, czyli pewnym dodatkowym atrybutem (flagą) rezultatu. Kolejność elementów w strukturze ma znaczenie. Jeżeli x 1, x 2, x 3,... Rezultat, wówczas bag{ x 1, x 2, x 3,...} Rezultat oraz sequence{ x 1, x 2, x 3,...} Rezultat.

140 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 140 kwiecień 2002 Przykłady zbioru Rezultat Atomowe: 25, "Kowalski", i 11, i 18 Złożone: struct{i 1, i 56 } sequence{ i 1, i 6, i 11 } bag{ struct{i 1, i 56 }, struct{i 6, i 72 }, struct{i 11, i 72 }} bag{struct{n("Kowalski"), Zarobek(2500), d(i 56 )}} bag{struct{ Dział(i 56 ), Prac( bag{ struct{ n("Nowak"), s(i 9 ) }, struct{ n("Stec" ), s(i 14 ) }})} 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ć.

141 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 141 kwiecień 2002 Rezultaty zapytań zapisane jako tablice sequence{ i 1, i 6, i 11 } i 1 i 6 i 11 bag{ struct{i 1, i 56 }, struct{i 6, i 72 }, struct{i 11, i 72 }} i 1 i 6 i 11 i 56 i 72 bag{ struct{ n("Nowak"), s(i 9 )}, struct{ n("Stec"), s(i 14 )}, struct{ n("Mikuła" ), s(i 18 )}} n "Nowak" "Stec" "Mikuła" s i 9 i 14 i 18

142 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 142 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.

143 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 143 kwiecień 2002 Ilustracja otwierania nowego zakresu PRAC (i 1 ) PRAC (i 5 ) PRAC(i 9 ) DZIAŁ (i 17 ) DZIAŁ (i 22 ) Stos w momencie ewaluacji zapytania PRAC. Ewaluacja (wiązanie) nazwy PRAC zwraca {i 1, i 5, i 9 } PRAC where (Nazwisko = Kowalski and Zarobek > 1000) Stos w momencie ewaluacji pod-zapytania (Nazwisko = Kowalski and Zarobek > 1000) dla trzeciego obiektu PRAC. Ewaluacja (wiązanie) nazwy Nazwisko zwraca i 10. Ewaluacja (wiązanie) nazwy Zarobek zwraca i 11. 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. wiązanie Nazwisko(i 10 ) Zarobek(i 11 ) Adres(i 12 ) PracujeW(i 16 ) PRAC (i 1 ) PRAC (i 5 ) PRAC(i 9 ) DZIAŁ (i 17 ) DZIAŁ (i 22 )

144 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 144 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. nested(i 9 ) = { Nazwisko (i 10 ), Zarobek (i 11 ), Adres (i 12 ), PracujeW (i 16 ) } i 9 Prac i 10 Nazwisko Barski i 11 Zarobek 2000 i 16 PracujeW i 13 Miasto Radom i 14 Ulica Wolska i 15 NrDomu 12 i 12 Adres

145 © K.Subieta. Obiektowe języki zapytań 1..5, Folia 145 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,,..., }> nested( i ) = { n 1 (i 1 ), n 2 (i 2 ),..., n k (i k ) }. Dla identyfikatora i obiektu pointerowego dla którego istnieje w składzie obiekt nested( i ) = { n 1 (i 1 ) }. 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{ x 1, x 2, x 3,...}) = nested( x 1 ) nested( x 2 ) nested( x 3 )...


Pobierz ppt "© K.Subieta. Obiektowe języki zapytań 1..5, Folia 1 kwiecień 2002 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła."

Podobne prezentacje


Reklamy Google