Obiektowe języki zapytań

1. Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykłady 1..5

2. Plan wykładów 1..5 Cel tej serii wykładów - objaśnienie podejścia stosowego do obiektowych języków zapytań • Generalne założenia podejścia stosowego • Wprowadzenie do języków zapytań • Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja • Podstawy semantyczne języków zapytań • Modele składu obiektów - M0, M1, M2 i M3 • Stos środowisk i wiązanie nazw Dalsze wykłady 6..10 z tej serii będą poświęcone językowi SBQL, oraz konstrukcjom imperatywnym i perspektywom bazującym na SBQL.

3. Wykład 1

4. Generalne założenia podejścia stosowego stack-based approach, SBA • Niniejszy wykład teorii i konstrukcji obiektowych języków zapytań będzie opierał się na podejściu stosowym, SBA. • Podejście stosowe zakłada, że języki zapytań są szczególnym przypadkiem języków programowania. • Stąd teorie języków programowania są bardziej adekwatne niż podejścia takie jak algebra relacyjna, rachunek relacyjny lub logika matematyczna. • W podejściu stosowym kluczową rolę odgrywa stos środowisk (environment stack), który jest podstawowym mechanizmem praktycznie wszystkich popularnych języków programowania. • Jego rolą jest określenie zakresów nazw (scoping), wiązanie nazw (binding) oraz wprowadzenie dyscypliny w zakresie alokowania dynamicznych bytów programistycznych, w szczególności lokalnych danych (obiektów) i parametrów procedur.

5. 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. Wprowadzenie do języków zapytań

7. Ogólna charakterystyka języków zapytań query languages • Języki zapytań (query languages) tworzą relatywnie nową dziedzinę informatyki, która (jak dotąd) jest związana z tematyką baz danych. • Językiem zapytań dla relacyjnych baz danych jest SQL. • Wielu specjalistów uważa, że SQL jest źródłem komercyjnego sukcesu całej technologii relacyjnych baz danych. • Pozycja SQL jako czołowego języka dla relacyjnych baz danych została wzmocniona przez standardy ANSI (American National Standard Institute) oraz ISO (International Standard Organization): SQL-89 oraz SQL-92. Obecnie trwają prace nad standardem SQL3 i nowszymi wersjami SQL 1999, SQL 2000,.... • SQL stał się podstawą lub uzupełnieniem wielu produktów, np. języków czwartej generacji (4GL), narzędzi RAD, języków programowania np. Oracle PL/SQL oraz różnych API, w szczególności ODBC i JDBC. • Najbardziej znanym obiektowym językiem zapytań jest ODMG OQL.

8. Czy przyszłością języków zapytań jest SQL/OQL? • Obie propozycje są kontrowersyjne. • SQL3 - SQL1999 - SQL2000 są krytykowane za eklektyzm, wszystkoizm i przypadkowość decyzji w zakresie konstrukcji językowych, co owocuje monstrualną specyfikacją (ponad 1000 stron, plus dodatki). • Jest wątpliwe, aby ktokolwiek zaimplementował te języki w całości. • OQL jest językiem znacznie mniejszym, ze specyfikacją mieszczącą się na kilkudziesięciu stronach, ale pozwala wyłącznie na wyszukiwanie danych. Brakuje perspektyw, zapamiętanych procedur, itd. • Co za tym idzie, programowanie w OQL wymaga zanurzenia zapytań w uniwersalny język programowania: C++, Smalltalk i Java. • Zanurzenie języka zapytań w uniwersalny język programowania ma złą sławę określaną jako „niezgodność impedancji”. • Obie propozycje cechuje niespójność (i w gruncie rzeczy, brak istotnej koncepcji) w zakresie semantyki. • Co za tym idzie, optymalizacja zapytań stoi pod znakiem zapytania.

9. Czy warto zabiegać o precyzyjną semantykę? • Brak precyzyjnej semantyki jest powszechny dla nowo powstających języków programowania. • W przypadku języków zapytań sytuacja jest odmienna w porównaniu do klasycznych języków programowania. • Języki zapytań są dramatycznie nieefektywne (praktycznie nieakceptowalne) w przypadku braku automatycznej optymalizacji. • Optymalizacja oznacza zamianę zapytania q1, którego czas wykonania jest dramatycznie długi (np. tysiąc lat), na semantycznie równoważne zapytanie q2 posiadające akceptowalny czas wykonania (np. 5 sekund). • Powoduje to konieczność ustalenia, co to znaczy „semantycznie równoważne zapytanie”. Jest to niemożliwe bez precyzyjnej formalizacji zarówno danych, na których operują zapytania, jak i semantyki operatorów występujących w zapytaniach. • Uzyskanie pełnej jasności i precyzji opisu semantyki obiektowych języków zapytań jest celem podejścia stosowego.

10. Co to są "języki zapytań"? Istnieje na ten temat wiele poglądów, np.: • Proste, przyjacielskie i naturalne interfejsy dla powszechnego użytkownika do interakcyjnego formułowania zleceń wyszukiwania w bazie danych lub jej aktualizacji przez mało doświadczonego użytkownika. W tej roli znacznie lepsze od SQL są interfejsy graficzne oparte o okienka, menu, formularze, tabele, przeglądanie, itp. • Syntaktyczne warianty języków pewnych sławnych matematycznych teorii, np. logiki. Ten punkt widzenia był lansowany przez teoretyków baz danych. Obecne języki zapytań zaprzeczają tego rodzaju poglądom. • Pod-języki bardzo wysokiego poziomu (API) zanurzane w typowe języki programowania do wyszukiwania i aktualizacji bazy danych. W tej roli najczęściej występuje SQL. Liczne wady tego podejścia. • Wyrażenia programistyczne bardzo wysokiego poziomu zintegrowane z językiem programowania. Tworzą kompletny interfejs do programowania aplikacji. Przykładem jest PL/SQL systemu Oracle.

11. 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. 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. 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. 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. 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. 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. 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. Zasady języków zapytań (1) Ostatnio, zasady wypracowane przez świat akademicki są kwestionowane przez świat przemysłowy. Wynika to z faktu, że dla firm komercyjnych jest bardzo niewygodne stwierdzenie, że jakaś cecha ich produktu jest "niezgodna z zasadą". Kwestionuje się więc zasadę. Zadaniem świata akademickiego jest obrona zasad. Niżej są podane podstawowe zasady obowiązujące języki zapytań. • Naturalność: zgodność z naturalnym myśleniem potencjalnych użytkowników. Niekoniecznie oznacza ona wyrażanie zapytań w języku naturalnym (ponieważ jest on zbyt mało precyzyjny). • Prostota: klarowność konstrukcji syntaktycznych, oczywistość semantyki, łatwość uczenia się i nauczania, łatwość dokumentowania, implementacji, pielęgnowania i użycia. • Ortogonalność: każda kombinacja cech języka, która ma sens, powinna być dozwolona. Ortogonalność pozwala na zredukowanie do minimum definicji języka oraz znaczne podwyższenie jego mocy.

19. 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. 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. 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. Optymalizacja zapytań query optimization • Opracowanie sprawnych metod optymalizacji jest fundamentalnym problemem w konstrukcji języka zapytań. Naiwna ewaluacja zapytań prowadzi do nieakceptowalnych czasów wykonania i konsumpcji pamięci. • Np. proste zapytanie w SQL (podaj nazwiska dostawców dostarczających części o nazwie ”zawór”): wymaga wykonania produktu kartezjańskiego relacji wymienionych w klauzuli from. Przyjmując 10000 dostawców, 10000 produktów, 100000 krotek w relacji DP i średnio 100 bajtów w każdej krotce tych relacji, produkt kartezjański miałby 1013 elementów i zajmowałby 930 000 GB. • Jeżeli sprawdzenie warunku w klauzuli where dla pojedynczej krotki trwałoby jedną tysięczną sekundy, to wyselekcjonowanie z produktu kartezjańskiego właściwych krotek trwałoby 1010 sekund, czyli 317 lat. • Dzięki metodom optymalizacyjnym obliczenie powyższego zapytania trwa kilka sekund i nie wymaga zbyt dużo pamięci. selectDostawca.nazwiskofromDostawca, Produkt, DP whereDostawca.NrDost = DP.NrDostandDP.NrProd = Produkt.NrProd andProdukt.nazwa = ”zawór”

23. 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. 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. 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ólenie mogą być wyposażone w języki zapytań. • Podobne poglądy do pewnego czasu głosił J. Ullman.

26. 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. Wykład 2

28. Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja

29. Obiekt object • Wielu autorów nie rozróżnia pojęcia obiektu jako pewnej abstrakcji pojęciowej lub informacyjnej, konkretnego obiektu (materialnego) istniejącego w świecie rzeczywistym, oraz struktury danych określanej jako „obiekt” przechowywanej wewnątrz komputera. • Dla języków zapytań tylko ostatni punkt widzenia jest relewantny. • Obiektem będzie więc pewna struktura danych przechowywana w przestrzeni pamięciowej komputera. • Nie wymagamy, aby ta struktura danych miała swój odpowiednik wśród obiektów świata rzeczywistego. • Obiektem może być także dowolna abstrakcja programistyczna, np. moduł, procedura, zmienna, stała środowiskowa, okienko wyświetlane na ekranie, plik tekstowy, itd. • Istotą obiektu jest to, że programista może nim manipulować tak jak pojedynczą zwartą bryłą, np. wyszukiwać, kopiować, tworzyć, usuwać lub przenosić.

30. Tożsamość obiektu, identyfikator obiektu object identity • W odróżnieniu od modelu relacyjnego obiektowość nie zakłada konieczności określenia takiego atrybutu obiektu (lub kombinacji atrybutów), który identyfikuje go w sposób unikalny, czyli tzw. „klucza głównego” (primary key). • Obiekt posiada swoją tożsamość (identity), tj. istnieje niezależnie od innych obiektów i od swojego aktualnego stanu. • W praktyce tożsamość oznacza ona, że obiekt posiada unikalny wewnętrzny identyfikator (object identifier, OID), który odróżnia go od innych obiektów. • Taki identyfikator jest nadawany przez system automatycznie, niezależnie od woli projektanta lub programisty. • Wewnętrzny identyfikator jest nieczytelny, nie przenosi informacji biznesowej. • Wewnętrzny identyfikator umożliwia budowanie referencji do obiektu, w szczególności tworzenie powiązań pointerowych.

31. 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. Stan obiektu, atrybuty obiektu object state • Obiekt posiada stan, określany jako kombinacja wartości wszystkich składowych obiektu, przede wszystkim wartości wszystkich jego atrybutów oraz powiązań z innymi obiektami. • Stan obiektu może zmieniać się w czasie. • Istnieje wiele rodzajów atrybutów obiektów i ich kombinacji: • Atrybut prosty lub atomowy taki jak np. NAZWISKO dla obiektu PRACOWNIK. Przechowuje dokładnie jedną wartość; np. ”Kowalski”. • Atrybut złożony, taki jak np. ADRES. Przechowuje wiele wartości. Ma strukturę hierarchiczną. • Atrybut pointerowy: zawiera jako wartość identyfikator obiektu. • Atrybut powtarzalny: przechowuje pewien zestaw wartości o nieokreślonej i zmiennej w czasie liczbie elementów. • Atrybut opcyjny, multimedialny, wyliczalny, domyślny, ...

33. Przykład obiektu Porównaj Sprawdź podpis stan Nalicz Zlikwiduj procent konto Zmień upoważnienie • Czy oprócz wymienionych metod można będzie dostać się do stanu obiektu poprzez nazwy atrybutów ? • Tak. Kwestia zostanie rozpatrzona dalej. Wypłać Wpłać KONTO Numer123-4321 WłaścicielJan Kowalski UpoważnionyEwa Kowalska SaldoZł34567 .... Upoważnij

34. Obiekt złożony complex object • Obiekt może być złożony, tj. składać się z pewnej liczby komponentów, które także mogą być złożone. • W zależności od języka lub systemu komponenty mogą być traktowane jako obiekty lub mogą być uważane za kategorię różną od obiektów. • Nie powinno istnieć ograniczenie rozmiaru obiektu, liczby komponentów składających się na obiekt, rodzajów komponentów, lub liczby poziomów hierarchii komponentów. • Obiekt złożony reprezentujący byt świata rzeczywistego powinien zawierać wszelkie informacje, które odnoszą się do tego bytu. • Niezależnie od stopnia złożoności obiektu i jego wielkości projektant lub programista może rozpatrywać go i wykonywać na nim operacje jak na pojedynczym elemencie. • Podane wyżej założenia stwarzają nową sytuację w stosunku do modelu relacyjnego, gdzie informacje o obiekcie wyróżnialnym w rzeczywistości modelowanej przez dane są rozproszone w krotkach wielu tabel.

35. Zasada relatywizmu obiektów object relativism • Zgodnie z zasadą relatywizmu obiektów, każdy obiekt złożony jest zestawem podobiektów, które mogą być złożone lub atomowe. Każdy podobiekt jest traktowany jako samodzielny obiekt. Ogólne własności dotyczące obiektów i podobiektów są identyczne. • Od tej zasady nie ma wyjątków, w szczególności atomowy atrybut obiektu (np. atrybut ZAROBEK obiektu PRACOWNIK) jest obiektem. • Powiązanie do innego obiektu jest też obiektem. • Konsekwencją relatywizmu jest istnienie obiektów, które nie posiadają atrybutów (czyli obiektów atomowych), jak również obiektów, dla których nie jest istotne definiowanie klas, ponieważ są one obsługiwane wyłącznie przez metody generyczne. • Konsekwencją relatywizmu obiektów jest również fakt, że każdy podobiekt (atrybut) musi posiadać swój unikalny identyfikator. • Np. obiekt PRACOWNIK ma pewien zestaw przypisanych mu metod, ale jego atrybut ZDJĘCIE jest innym obiektem posiadającym własne metody. • Niektóre obiekty są obsługiwane wyłącznie przez wbudowane metody generyczne, takie jak +, -, <, =. Dla nich nie jest istotne definiowanie klas.

36. 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. Zasada wewnętrznej identyfikacji internal identification • Jest konsekwencją zasady relatywizmu obiektów. • Zgodnie z zasadą wewnętrznej identyfikacji każdy byt programistyczny, który może być niezależnie od innych wyszukiwany, wiązany, aktualizowany, wstawiany, usuwany, indeksowany, zabezpieczany, blokowany, itp. musi mieć unikalny wewnętrzny identyfikator. • Tej zasadzie będą podlegać dowolne identyfikowalne byty zasobów komputera lub danej aplikacji, m.in. procedury zgromadzone w bibliotekach, klasy, metody, perspektywy, ograniczenia, wyzwalacze, moduły, itd. • Nie jest istotne w jaki sposób identyfikator ma być konstruowany. Np. może to być fizyczny adres, <OID+nazwa atrybutu>, <OID+offset>, itd. • <OID+nazwa atrybutu> nie jest dobrą identyfikacją atrybutu, jeżeli jest on wielowartościowy. Każda wartość takiego atrybutu musi mieć unikalną identyfikację. <OID+offset> jest również niedobry, gdyż jest powiązany z fizyczną reprezentacją i stałym formatem obiektu. • Identyfikator bytu programistycznego nie może być związany ze stanem tego bytu, o ile ten stan może ulegać zmianom. Czyli klucz główny (primary key), znany z modelu relacyjnego, też nie zawsze jest dobrą identyfikacją.

38. 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. Powiązania pomiędzy obiektami PRACOWNIK PRACOWNIK PRACOWNIK Nazwisko Kowal Nazwisko Nowak Nazwisko Babel Zarobek 1500 Zarobek 2500 Zarobek 2000 PracujeW PracujeW PracujeW Zatrudnia Zatrudnia Zatrudnia Nazwa Syntex Szef NrFirmy 102030 FIRMA pointer links, relationships • Dzięki istnieniu unikalnych identyfikatorów obiektów w obiektowych językach programowania i bazach danych możliwe jest tworzenie bezpośrednich powiązań pointerowych między obiektami. • Dość często każdy pointer ma "bliźniaka"; spójność par pointerów jest wspomagana systemowo (ODMG).

40. 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 (pathexpressions) 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. Przykład wykorzystania powiązań pointerowych • Podaj nazwisko szefa Nowaka: • SQL: • SBQL: • Występujący w zapytaniu SQL warunek p.NrFirmy = f.NrFirmyjest 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. 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. 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. Zamiana powiązań n-arnych na binarne OSOBA Bober OSOBA Kowalska OSOBA Bober OSOBA Kowalska Sprzedający Sprzedający Kupujący Kupujący TRANSAKCJA Plac 1995.08.16 40000 Transakcja Plac 1995.08.16 40000 Pośrednik Pośrednik OSOBA Nowak OSOBA Nowak Pośrednik Pośrednik Transakcja Samochód 1998.05.15 20000 TRANSAKCJA Samochód 1998.05.15 20000 Sprzedający Sprzedający Kupujący Kupujący OSOBA Maciąg OSOBA Bielicka OSOBA Maciąg OSOBA Bielicka

44. 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. Hermetyzacja i ukrywanie informacji encapsulation information hiding • Hermetyzacja jest grupowaniem elementów składowych w obrębie jednej bryły i następnie, manipulowanie tą bryłą jako całością. • Hermetyzację wiąże się z ukrywaniem części informacji dotyczącej struktury i implementacji wnętrza tej bryły. • Hermetyzacja jest generalną zasadą inżynierii oprogramowania sformułowaną przez D. Parnasa w 1972 w związku z pojęciem modułu. • Moduł, klasa, abstrakcyjny typ danych (ADT) - przykłady hermetyzacji. • Programista ma tyle wiedzieć o tworze programistycznym (procedurze, module, obiekcie, klasie), ile mu trzeba, aby go efektywnie używać. • Wszystko, co może być przed programistą ukryte, powinno być ukryte. • Jest to pożądane zarówno ze względu na potrzebę nie przeciążania modelu pojęciowego programisty niepotrzebnymi elementami, jak i ze względu na konieczność zredukowania potencjalnych błędów w oprogramowaniu. • Specyfikacja jest oddzielona od implementacji. Możliwa jest zmiana implementacji bez zmiany specyfikacji. Programistę interesuje wyłącznie specyfikacja - nie ma potrzeby ani możliwości wglądu w implementację.

46. 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. 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. Hermetyzacja ortogonalna • Oznacza, ze dowolna cecha obiektu może być prywatna lub publiczna. • Jeżeli atrybut jest publiczny, to oznacza, że istnieje generyczna metoda (wspólna dla całego modelu), która zwraca referencję do tego atrybutu. • Tą metodą jest (niejawna) operacja wiązania (binding), której argumentem jest nazwa (m.in. atrybutu), zaś wynikiem jest referencja lub zbiór referencji. Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu PRACOWNIK PRACOWNIK NAZWISKO Nowak ROK_UR 1951 NAZWISKO Nowak ZAROBEK 2500 DZIAŁ Zabawki DZIAŁ Zabawki ZarobekNetto() {...}; Podatek(){...}; ZarobekNetto() ZmieńZarobek(...) {...}; ZmieńZarobek(...) Wiek(){ return RokBież - ROK_UR }; Wiek()

49. Komunikat message • Komunikat jest prawie dokładnie tym samym, co wołanie procedury. • Różnice dotyczą wyłącznie składni, miejsca ulokowania procedury (metody są wewnątrz klasy) oraz sposobu komunikowania parametrów do procedury: • Wołanie procedury: • 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

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