© K.Subieta. Obiektowe języki zapytań 12, Folia 1 maj 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik.

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

1 © K.Subieta. Obiektowe języki zapytań 12, Folia 1 maj 2004 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ład 12: Przetwarzanie struktur nieregularnych

2 © K.Subieta. Obiektowe języki zapytań 12, Folia 2 maj 2004 Dane nieregularne (pół-strukturalne) Problem danych nieregularnych, zwanych również pół-strukturalnymi (semistructured) jest nowym sformułowaniem problemu wartości zerowych w bazach danych (NULL values). Problem obrósł ogromną literaturą (ponad 500 pozycji) i w swoim czasie był ulubionym tematem licznych prac naukowych w kontekście tzw. niekompletnej informacji. Powstały liczne prace dotyczące specjalnych algebr z wartościami zerowymi, specjalnych rachunków, trój-wartościowych i cztero- wartościowych logik, odpytywania dysjunktywnej informacji i zbiorów możliwych światów, i wiele innych. Skrajnie mizerne rezultaty przy ogromnym nacisku badawczym. Świat informatyki komercyjno-przemysłowej nie uznał więc tych rozwiązań za dostatecznie istotne; Nie pojawiły się nawet próby implementacji czegokolwiek z tej góry poronionych pomysłów.

3 © K.Subieta. Obiektowe języki zapytań 12, Folia 3 maj 2004 Wartości zerowe w SQL Problem wartości zerowych znalazł swoje odbicie praktyczne w SQL. Sposób wprowadzenia wartości zerowych do SQL ignoruje zasadę korespondencji i wprowadza niespójności i rafy semantyczne. W SQL wartość zerowa nie ma żadnej zewnętrznej semantyki, np. do reprezentowania niekompletnej informacji. Jest to wyłącznie trik techniczny mający na celu dostarczenie projektantom i programistom możliwości uwzględnienia nieregularności w danych. Projektant lub programista może go stosować do dowolnie wybranych celów, i on jest też jedynym autorytetem który wie, jaka jest zewnętrzna (biznesowa) semantyka wprowadzonych poprzez ten trik wartości zerowych.

4 © K.Subieta. Obiektowe języki zapytań 12, Folia 4 maj 2004 Warianty lub unie W językach programowania istnieje inny fenomen dotyczący nieregularnych danych, zwany rekordem z wariantami w rodzinie języków Pascala, i unią w rodzinie języków C. Wariant oznacza typ, którego instancje mogą różnić się zestawem atrybutów. Warianty i wartości zerowe są pojęciami dość podobnymi. Jeżeli w obiektach R typu T z atrybutami A,B,C,... atrybut A może mieć wartość zerową, to można to zapisać (w pseudokodzie) jako typ z wariantami: T = wybierz wariant R(A, B, C,... } lub R( B, C,...) Drugi wariant typu T pomija atrybut A. Pojęcia wartości zerowej i wariantu nie są równoważne. Jeżeli obiekty R mogłyby mieć np. 10 atrybutów mogących przyjąć wartości zerowe, wówczas konieczne byłyby 2 10 = 1024 warianty. Warianty mogą posiadać dyskryminator (Pascal) - wyróżniony atrybut, wartość którego pozwala automatycznie rozróżnić, z którym wariantem mamy w danej chwili do czynienia. Dyskryminator daje możliwość dynamicznej kontroli typu.

5 © K.Subieta. Obiektowe języki zapytań 12, Folia 5 maj 2004 XML i dane pół-strukturalne Ostatnio stosunek do nieregularności w danych nieco się zmienił ze względu na standard XML, który nieregularność formatu przyjął jako zasadę. Stare prace dotyczące wartości zerowych są niestety w tym kontekście również bezwartościowe. Powstało wiele nowych prac, w których nie mówi się już o wartościach zerowych, wariantach, lub niekompletnej informacji, lecz o przetwarzaniu danych pół-strukturalnych, co przybliża to podejście do klasycznych wariantów, ale ustawia je w nowym kontekście. Stare problemy jednak pozostały i nie są widoczne nowe rewolucyjne metody, które mogłyby zmienić jakość rozwiązań. Można więc wątpić, czy ten nowy kierunek zaowocuje tym razem rezultatami dostatecznie istotnymi dla powszechnych praktycznych wdrożeń. Najbardziej prawdopodobne jest to, że świat informatyki komercyjnej, nie oglądając się na świat informatyki akademickiej, dopracuje się własnych rozwiązań na podstawie mniej lub bardziej przemyślanych (lub przypadkowych) decyzji.

6 © K.Subieta. Obiektowe języki zapytań 12, Folia 6 maj 2004 Niezgodność zakresu Jest to niezgodność pomiędzy funkcjonalnością koncepcji, teorii, języka lub modelu dotyczącą tego problemu, z funkcjonalnością programistyczną, która musi obowiązywać wartości zerowe lub dane pół- strukturalne. W typowych przypadkach pierwszy zakres obejmuje pewną algebrę lub pewien uproszony język zapytań. Ale dowolny system nie może ograniczać funkcjonalności wyłącznie do przechowywania i prostego odpytywania danych. Zakres nieregularności w danych obejmuje wszystkie cechy środowiska programistycznego, z którym będzie miał do czynienia programista aplikacyjny. Nieregularności w danych muszą być uwzględnione przez kompletne środowisko do programowania aplikacji, włączając operacje aktualizacyjne, zdania imperatywne, procedury, funkcje, klasy, typy, metody, itd. Obowiązuje przy tym zasada korespondencji, która żąda spójności wprowadzanych opcji z dotychczas wprowadzonymi opcjami. Rozwiązania dla danych półstrukturalnych i dla XML orientują się wyłącznie na pierwszy z wymienionych zakresów.

7 © K.Subieta. Obiektowe języki zapytań 12, Folia 7 maj 2004 Metoda ukrytego bajtu Klasycznym rozwiązaniem zastosowanym w zanurzonym SQL jest metoda ukrytego bajtu (hiddden byte). W tabelach relacyjnych oraz w SQL wartość zerowa jest widoczna explicite i obsługiwana przez odpowiednie konstrukcje SQL. Inaczej jest, gdy tabela zwrócona przez SQL jest przetwarzana przez język programowania, np. C. W tym przypadku każda kolumna tabeli, w której może pojawić się wartość zerowa, jest implementowana jako dwie kolumny. Pierwsza z nich przechowuje normalną wartość danego atrybutu lub wartość przypadkową (nieistotną) jeżeli we tym miejscu ma być NULL. Druga kolumna przechowuje flagę posiadającą dwa stany: nie jestem NULL lub jestem NULL. Na podstawie tej flagi programista może zbadać, czy w pierwszej wymienionej kolumnie jest wartość mająca znaczenie. Ten sposób jest dalej rozszerzany na całe środowisko programistyczne. Dzięki temu stało się możliwe przetwarzanie wartości zerowych w klasycznym języku programowania z mocna statyczną kontrolą typów.

8 © K.Subieta. Obiektowe języki zapytań 12, Folia 8 maj 2004 Co zamiast ukrytego bajtu? Metoda ukrytego bajtu nie nadaje się bezpośrednio do zastosowania dla danych pół-strukturalnych: Wprowadzane tam nieregularności w danych są znacznie większe niż to miało miejsce w przypadku relacyjnych tabel z wartościami zerowymi. Zakładając, że zbudujemy język zapytań do wyszukiwania w danych półstrukturalnych, przetwarzanie wyników zapytań przez środowisko programistyczne może być zrealizowane na jeden z trzech sposobów: 1.Zmiany w systemie typów danego uniwersalnego języka programowania. 2.Spłaszczenie hierarchicznej struktury zwracanej przez zapytanie. 3.Zbudowanie nowego kompletnego środowiska programistycznego przystosowanego do przetwarzania danych półstrukturalnych. Interesować nas będzie tylko ostatnia z tych możliwości.

9 © K.Subieta. Obiektowe języki zapytań 12, Folia 9 maj 2004 Trzy sposoby przetwarzania nieregularności 1.System typów danego uniwersalnego języka programowania (np. Java) przystosujemy w taki sposób, aby każdy wynik zapytania mógł być potraktowany jako poprawna wartość pewnego znanego w danym momencie typu. Sposób ten jest mało realny ze względu na znaczne trudności koncepcyjne i implementacyjne dla programisty aplikacyjnego. 2.Spłaszczenie hierarchicznej struktury zwracanej przez zapytanie. Przykładem takiego spłaszczenia jest potraktowanie całości wyniku wyszukiwania (łącznie z nazwami danych) jako ciągu bajtów a la XML. Podobnym sposobem jest reprezentacja danych półstrukturalnych w dwóch lub więcej tabelach relacyjnych, gdzie wszystkie nazwy danych są trzymane jako stringi obok wartości, oraz istnieje specjalna tabela reprezentująca hierarchię danych.. 3.Zbudowanie nowego kompletnego środowiska programistycznego przystosowanego do przetwarzania danych półstrukturalnych. Konieczność opracowania własnego języka programowania – trudne dla zastosowań komercyjnych, ale całkowicie możliwe w ramach prototypu lub własnego projektu.

10 © K.Subieta. Obiektowe języki zapytań 12, Folia 10 maj 2004 Przykład – spłaszczenie struktury XML Jan Adam Kowalski 1973-12-1 Warszawa Sienna 67 2500 NrCzęści NazwaCzęści 1 pracownik 2 imie 3 imie 4 nazwisko 5 data_urodz 6 adres 7 miejscowosc 8 ulica 9 nr domu 10 pensja Części pliku XML NrCzęści Wartość 2 Jan 3 Adam 4 Kowalski 5 1973-12-1 7 Warszawa 8 Sienna 9 67 10 2500 Wartości Nadczęść Podczęść 1 2 1 3 1 4 1 5 1 6 1 10 6 7 6 8 6 9 Hierarchia

11 © K.Subieta. Obiektowe języki zapytań 12, Folia 11 maj 2004 Nieregularne dane w modelach składu M0-M3 Wprowadzone przez nas modele składu M0-M3 z definicji są przygotowane do przechowywania dowolnych struktur nieregularnych. Podobnie jak w XML, nie wprowadzamy także wartości zerowych, uważając że jeżeli wartość pewnego (pod-) obiektu jest nieznana lub nierelewantna, to taki (pod-) obiekt może być w całości pominięty w danym składzie obiektów. Jak dotąd nie wiążemy modeli składu z jakimkolwiek systemem typów. Mechanizmy wiązania na stosie środowiskowym nie zależą od tego, czy dane mają regularny format, czy są nieregularne. W istocie jednak, ta swoboda jest pozorna i wynika wyłącznie z faktu, że przy konstrukcji semantyki języka zapytań pominęliśmy schemat danych, i to zarówno od strony znaczenia danych w dziedzinie przedmiotowej (dziedzinie biznesu) oraz od strony rozumienia wszelkich aspektów logicznej organizacji i reprezentacji danych. Dobrym wzorcem w tym zakresie jest DTD oraz XMLSchema należące do technologii XML. W systemie Loqis zrealizowaliśmy nieco inny model oparty o gramatyki bezkontekstowe i wyrażenia regularne.

12 © K.Subieta. Obiektowe języki zapytań 12, Folia 12 maj 2004 Konstrukcje w jęz. zapytań dla danych nieregularnych Jeżeli dana o nazwie n jest nieobecna w pewnym obiekcie z identyfikatorem i, wówczas nested(i) nie będzie zawierać bindera o nazwie n. Jeżeli mamy zapytanie o postaci q 1 θ q 2 (n) gdzie q 1 zwraca identyfikator i, θ jest operatorem nie-algebraicznym, q 2 (n), jest zapytaniem zawierającym nazwę n (nie objętą innym operatorem nie-algebraicznym), to w tej sytuacji odpowiedniego bindera nie ma na stosie, wobec czego nazwa n nie może być związana. W tej sytuacji należy przyjąć, że wiązanie nazwy n zwróci pusty zbiór. Powstaje pytanie, co z takim pustym zbiorem programista może zrobić.

13 © K.Subieta. Obiektowe języki zapytań 12, Folia 13 maj 2004 Przykład z pustym zbiorem Rozważmy przykład: Prac where Zar > 1000 przy czym atrybut Zar może nie wystąpić w niektórych obiektach Prac. W tej sytuacji można przyjąć, że jeżeli Zar nie wystąpi, to predykat Zar > 1000 przyjmuje wartość fałsz. Alternatywnie można przyjąć, że jest to sytuacja błędna powodująca podniesienie wyjątku. Pierwsze założenie prowadzi do licznych niespójności (identycznych z tymi, które były przyczyną krytyki wartości zerowych), zatem je bezwzględnie odrzucamy. Pozostaje tylko druga interpretacja, czyli przyjęcie, że zapytanie to jest błędne.

14 © K.Subieta. Obiektowe języki zapytań 12, Folia 14 maj 2004 Jak powinien postąpić programista? Jeżeli programista oczekuje, że atrybut Zar może nie istnieć, to powinien tę sytuację przewidzieć w swoim zapytaniu. Np. przyjmując, że count działa również na indywidualnych elementach zwracając dla nich 1, może formułować to zapytanie w sposób następujący: (Prac where count(Zar) = 1 ) where Zar > 1000 (Prac where exists(Zar) ) where Zar > 1000 Najpierw sprawdza, czy Zar istnieje, następnie upewniwszy się, że istnieje, używa po where odpowiedniego predykatu. Zwrócimy uwagę, że w tej sytuacji nie byłoby poprawne pozornie identyczne zapytanie: Prac where exists(Zar) and Zar > 1000 gdyż wymagałoby to specjalnego trybu ewaluacji operatora and (drugi człon nie podlegałby ewaluacji jeżeli pierwszy człon zwróciłby false). W językach zapytań taka interpretacja mogłaby prowadzić do błędów ze względu na optymalizację zapytań, która w wyniku metod przepisywania może przestawić kolejność predykatów.

15 © K.Subieta. Obiektowe języki zapytań 12, Folia 15 maj 2004 Sposób z kwantyfikatorem Analogicznie, przyjmując, że kwantyfikatory działające na indywidualnym elemencie traktują go jako zbiór jedno-elementowy, można to samo zapytanie sformułować z pomocą kwantyfikatora: Prac where Zar as z (z > 1000) Zapytanie zwraca referencje do obiektów pracowników, którzy mają zarobek i przekracza on 1000. Prac where Zar as z (z > 1000) Zapytanie, oprócz w/w referencji, zwraca także referencje do tych obiektów Prac, w których atrybut Zar jest nieobecny (kwantyfikator ogólny działający na pustym zbiorze zawsze zwraca prawda). Jak widać, dane nieregularne w SBQL nie wymagają wprowadzania wartości zerowych ani też nowych konstrukcji gramatycznych. Istotne w naszej metodzie jest również to, że nieobecna dana (czyli odpowiednik wartości zerowej) może być dowolnie złożona, np. Adres. Taka sytuacja jest niewyrażalna w modelu i systemach relacyjnych. Są one w stanie wyrazić sytuację, że każdy atrybut w ramach danej Adres ma wartość zerową, ale semantycznie nie jest to równoważne sytuacji, w której cała dana Adres ma wartość zerową.

16 © K.Subieta. Obiektowe języki zapytań 12, Folia 16 maj 2004 Nieobecne dane i funkcje agregowane Przyjęta przez nas interpretacja nieobecnych danych jest także spójna z funkcjami agregowanymi. Rozpatrzmy podany przez Ch.Date przykład z SQL, w którym jeżeli relacja R(A, B) posiada atrybuty A i B z wartościami zerowymi, to w generalnym przypadku zapytania: select sum(A+B) from R select sum(A)+sum(B) from R mogą zwrócić różny wynik. W SBQL problem ten nie występuje, ponieważ syntaktyczny odpowiednik pierwszego zapytania SQL, mający postać sum(R.(A+B)), jest błędny. Poprawny semantyczny odpowiednik pierwszego zapytania ma w SBQL postać: sum(R.(A as a, B as b).(a+b)) Jeżeli pewien obiekt R nie zawiera atrybutu A lub nie zawiera atrybutu B, to pod-zapytanie (A as a, B as b) zwróci pusty wynik, wobec czego do liczenia a+b nie dojdzie Odpowiednik drugiego zapytania ma postać: sum(R.A) + sum( R.B )

17 © K.Subieta. Obiektowe języki zapytań 12, Folia 17 maj 2004 Możliwości zewnętrznych złączeń Zewnętrzne złączenie (outer join) w systemach relacyjnych ma na celu zachowanie w złączeniu całej informacji ze złączanych tabel. Niech złączenie dotyczy relacji R1 i R2, według kolumny A w relacji R1 i kolumny B w relacji R2. Jeżeli krotka r relacji R1 ma wartość v w kolumnie A, ale v nie występuje w kolumnie B, wówczas w normalnym złączeniu krotka r jest pomijana w wyniku. W zewnętrznym złączeniu lewostronnym r jest w takiej sytuacji uzupełniane o wartości NULL we wszystkich kolumnach z relacji R2. Takie złączenie nie traci informacji z R1, ale może stracić informację z R2, Zewnętrzne złączenie prawostronne dopisuje wartości NULL w kolumnach pochodzących z R1 (nie traci informacji z R2). Obustronne zewnętrzne złączenie nie traci informacji z obydwu złączanych tabel (dopisuje NULL wszędzie tam, gdzie nie ma odpowiedniej wartości). Zewnętrzne złączenie da się wyrazić przez inne operatory SQL. Dla niektórych zadań wyszukiwawczych jest jednak bardzo wygodne, ze względu właśnie na to, że nie traci informacji, przez co umożliwia np. sporządzanie kompletnych raportów pochodzących z dwóch lub więcej tabel.

18 © K.Subieta. Obiektowe języki zapytań 12, Folia 18 maj 2004 Ilustracja zewnętrznego złączenia NrOs Nazwisko 2 Kowal 3 Kula 4 Manicki 5 Lato 8 Walak R1 Prac Zadanie 1 analiza 3 druk 4 edycja 6 pomiar 8 test R2 Zewnętrzne złączenie obustronne wg NrOs i Prac NrOs Nazwisko Prac Zadanie 1 NULL 1 analiza 2 Kowal 2 NULL 3 Kula 3 druk 4 Manicki 4 edycja 5 Lato 5 NULL 6 NULL 6 pomiar 8 Walak 8 test Normalne złączenie wg NrOs i Prac NrOs Nazwisko Prac Zadanie 3 Kula 3 druk 4 Manicki 4 edycja 8 Walak 8 test

19 © K.Subieta. Obiektowe języki zapytań 12, Folia 19 maj 2004 Jak zrobić zewnętrzne złączenie w SBQL? W sytuacji nieregularnych danych w definiowanym przez nas języku powinna być funkcjonalność pragmatycznie równoważna zewnętrznemu złączeniu. Istotne jest dla nas takie podejście, w którym zachowujemy cel pragmatyczny, a nie konkretny sposób znany z SQL. Tym celem pragmatycznym jest uniknięcie straty informacji w sytuacjach równoważnych do złączeń w relacyjnych bazach danych. Taką funkcjonalność może dostarczyć specjalny konstruktor struktury. Przy rozumieniu operatora struct jako uogólnionego iloczynu kartezjańskiego, jeżeli jakiekolwiek zapytanie będące jego argumentem zwróci pusty bag, wówczas wynik całości też jest pusty. Aby uzyskać interpretację równoważną pragmatycznie zewnętrznemu złączeniu musimy zmienić nieco ten operator na struct incomplete. Jeżeli jakieś zapytanie q i będące argumentem operatora struct incomplete zwróci pusty bag, wówczas takie zapytanie jest ignorowane. To oznacza, że zwracane struktury są w takim przypadku krótsze. Nieregularne struktury są trudniejsze dla mocnej kontroli typu, ale są bardziej elastyczne. Dla niektórych zastosowań (XML), mogą być nieuniknione.

20 © K.Subieta. Obiektowe języki zapytań 12, Folia 20 maj 2004 Zastosowanie struct incomplete Przykładowo, przyjmijmy że obiekty Prac mogą posiadać atrybuty Nazwisko, Zar i Stan, z których Zar i Stan są opcyjne (mogą nie wystąpić). Rozważmy zapytanie: Dla każdego pracownika zwróć nazwisko jako string, referencję do atrybutu Zar oraz referencję do atrybutu Stan: Prac. struct incomplete( deref (Nazwisko), Zar, Stan) Zapytanie może zwrócić bag struktur o długości 1, 2 lub 3, w zależności od obecności bądź nieobecności atrybutów Zar i Stan. Przykładowo (i atr oznacza referencję do atrybutu atr), może zwrócić strukturę: bag{ struct{ Kowalski, i Zar1, i Stan1 }, struct{ Pawlak, i Zar2 }, struct{ Nowak}, struct{ Bilski, i Stan4 }, struct{ Wolski, i Zar5 } } Analogiczne zapytanie: Prac. (deref (Nazwisko), Zar, Stan) zwróciłoby tylko bag{ struct{ Kowalski, i Zar1, i Stan1 } }

21 © K.Subieta. Obiektowe języki zapytań 12, Folia 21 maj 2004 Wartości zastępcze W sytuacji, gdy zależy nam na dobrze sformatowanych strukturach, np. dla celów raportowania lub przetwarzania wyniku zapytania przez język programowania z mocną kontrolą typu, możemy zastosować metodę wartości zastępczych. Wartość zastępcza powinna być wybrana w taki sposób, aby zastąpić ewentualny brak wartości. Jeżeli pewnej danej nie ma, to zamiast niej programista generuje w zapytaniu wybraną wartość zastępczą, której typ jest zgodny z oczekiwanym typem nieobecnej danej. W tym celu może posłużyć się dowolnymi już wprowadzonymi opcjami SBQL, np. funkcjami count, exists, kwantyfikatorami i innymi.

22 © K.Subieta. Obiektowe języki zapytań 12, Folia 22 maj 2004 Przykład z wartością zastępczą Np. wynik podanego wyżej przykładu można byłoby w ten sposób uczynić regularnym poprzez napisanie nieco dłuższego zapytania: Prac.( deref(Nazwisko) as n, (if exists(Zar) then Zar else 0 ) as z, (if exists(Zajęcie) then Zajęcie else brak zajęcia) as s)) W tym przypadku podany wcześniej wynik uzyska regularną postać, nadającą się do wydrukowania w postaci tablicowego raportu: bag{ struct{ n(Kowalski), z(i Zarobek1 ),s(i Zajęcie1 ) }, struct{ n( Pawlak), z(i Zarobek2 ),s(brak zajęcia) }, struct{ n( Nowak), z( 0 ),s(brak zajęcia) }, struct{ n( Bilski), z( 0 ),s(i Zajęcie4 ) }, struct{ n( Wolski), z(i Zarobek5 ),s(brak zajęcia) } } Przy pomocy podanych konstrukcji programista może osiągnąć nie tylko wszystkie efekty, które były osiągalne poprzez zewnętrze złączenie, ale także może opanować kwestię nieregularności w danych we wszystkich innych sytuacjach.

23 © K.Subieta. Obiektowe języki zapytań 12, Folia 23 maj 2004 Problem z fałszywym wiązaniem Jeżeli język zapytań nie ma kontroli typów, nieobecne obiekty w połączeniu z pełną ortogonalnością języka (nieograniczoną możliwością zagnieżdżania zapytań) prowadzą do błędu semantycznego powstającego w wyniku fałszywego wiązania. Rozpatrzmy zapytanie: Podaj pracowników zarabiających tyle samo co Nowak: Prac where Nazwisko Nowak and Zar = ((Prac where Nazwisko = Nowak).Zar Interesuje nas wiązanie drugiej występującej w tym zapytaniu nazwy Zar, w sytuacji, gdy obiekt Nowaka nie posiada takiego atrybutu. Wiązanie powinno zwrócić pusty zbiór, co spowoduje błąd wykonania. Następny slajd pokazuje sytuację na stosie środowiskowym podczas wiązania tej nazwy, jeżeli pierwszy operator where działa na obiekcie Kowalskiego, w którym atrybut Zar występuje.

24 © K.Subieta. Obiektowe języki zapytań 12, Folia 24 maj 2004 Sytuacja na stosie ENVS podczas wiązania Zar Jak widać, wbrew naszym założeniom druga nazwa Zar zostanie związana, ale do zarobku Kowalskiego, a nie Nowaka. W efekcie, zapytanie nie wykaże błędu wykonania i zwróci referencje do wszystkich obiektów pracowników posiadających atrybut Zar. Wynik ten jest oczywiście błędny. Nazwisko( i Nazw1 ),... Nazwisko( i Nazw2 ), Zar( i Zar1 ),... Sekcje bazowe Kierunek przeszukiwania stosu Sekcja obiektu Nowaka (brak Zar) Sekcja obiektu Kowalskiego

25 © K.Subieta. Obiektowe języki zapytań 12, Folia 25 maj 2004 Jak uniknąć fałszywego wiązania (1)? Przyczyną jest to, że w zapytaniu i w całym mechanizmie stosu nie ma informacji o tym, do którego bindera Zar ma być wiązana występująca w zapytaniu druga nazwa Zar. Uniknięcie tego błędu zmusza do jednego z następujących rozwiązań: 1.Zabronienie zagnieżdżania zapytań - sprzeczne z koncepcją. 2.Ustalenie bardziej rygorystycznej reguły wiązania, np. po operatorze kropki wiązanie następuje wyłącznie na wierzchołku stosu. Część zapytań stanie się niewyrażalna. Podobny błąd wystąpi zresztą dla innego operatora niealgebraicznego. 3.Zmuszanie programistów do świadomego formułowania tego zapytania tak, aby ten błąd nie mógł wystąpić. Np. inne (poprawne w każdym przypadku) sformułowanie tego zapytania jest następujące: (Prac where Nazwisko = Nowak).(Zar as x). (Prac where Nazw Nowak and Zar as y (x = y)) Powyższe założenie jest nieakceptowalne ze względów ergonomicznych, gdyż zmusza programistów do zbyt drobiazgowej analizy formalnej semantyki każdego zapytania.

26 © K.Subieta. Obiektowe języki zapytań 12, Folia 26 maj 2004 Jak uniknąć fałszywego wiązania (2)? 4.Określenie typów dla wszystkich obiektów i następnie, połączenie mechanizmu wiązania z przechowywaną informacją o typie. Dzięki temu można będzie wnioskować, że wprawdzie w danym obiekcie Zar nie występuje, ale w typie tego obiektu jest to opcyjne, zatem będziemy jednak wiązać Zar w tym obiekcie, co oczywiście da poprawny wynik w postaci pustego zbioru. 5.Skorzystanie z rozwiązania opartego na wartościach domyślnych przechowywanych w ramach klas (patrz dalej). Tylko dwa ostatnie rozwiązania są akceptowalne. Radykalnym rozwiązaniem jest zastosowanie typów obiektów. Np. można zmodyfikować funkcję nested w taki sposób, aby dla danej referencji i sprawdzała dodatkowo typ obiektu i. Jeżeli ten typ przewidywałby opcyjną daną o nazwie n, której w danym obiekcie nie ma, funkcja zwracała dodatkowo binder n( ). W ten sposób nieobecny pod-obiekt o nazwie n byłby reprezentowany na stosie środowiskowym przez binder n( ).

27 © K.Subieta. Obiektowe języki zapytań 12, Folia 27 maj 2004 Wartości domyślne (default values) Wartości domyślne (default values) zostały zaproponowane przez Ch.Date jak alternatywa dla wartości zerowych, w założeniu miały one być wpisywane fizycznie do relacyjnych tabel. Jest to dobre rozwiązanie w większości przypadków, ale ma także wady. Mogą być typy, dla których nie znajdziemy żadnej dobrej wartości zastępującej wartość zerową. Np. jeżeli jedna liczba reprezentowałaby bilans naszych rocznych dochodów i wydatków (ujemne liczby dla reprezentacji ujemnego bilansu), wówczas żadna z wartości nie mogłaby reprezentować faktu, że stan bilansu jest nieznany. Ponadto pojawia się problem np. z funkcjami agregowanymi, które wartości domyślne potraktują jak normalne wartości dając (przy braku dostatecznej uwagi ze strony programisty) błędny wynik. Wartości domyślne mogą mieć inne zastosowania, np. mogą stanowić początkowe wartości przy tworzeniu obiektów lub mogą być typowymi wartościami, które tylko w wyjątkowych przypadkach będą zmieniane.

28 © K.Subieta. Obiektowe języki zapytań 12, Folia 28 maj 2004 Wartości domyślne w SBQL (1) Modele składu obiektów M1-M3 pozwalają na inne potraktowanie wartości domyślnych, mianowicie przechowywanie ich jako inwariantów obiektów w ramach klas. Jeżeli dla każdego atrybutu o nazwie n danego obiektu klasa zawierałaby pod- obiekt z tą samą nazwą, to reguły zarządzania stosem spowodują, że jeżeli atrybut o nazwie n nie wystąpi w przetwarzanym obiekcie, to n zostanie związane do pod-obiektu z nazwą n występującego w jego klasie. Wartością takiego pod-obiektu mógłby być zbiór pusty, co rozwiązuje problem z fałszywym wiązaniem poruszony w poprzedniej sekcji. Nazwisko( i 1 ), RokUr(i 2 ) NrP( i 3 ), Stan(i 4 ) Stan(i 5 ) Zar( ) ZmieńZar(i 55 ) ZarNetto(i 56 ) RokUr(1900) Wiek(i 65 )... Sekcje bazowe Kierunek przeszukiwania stosu Sekcja przetwarzanego obiektu Sekcja klasy Prac Sekcja klasy Osoba Wartości domyślne

29 © K.Subieta. Obiektowe języki zapytań 12, Folia 29 maj 2004 Wartości domyślne w SBQL (2) Pokazaliśmy sytuacje na stosie w momencie wiązania nazw Zar i RokUr w zapytaniu: (Prac where Nazwisko = Nowak).(Zar, RokUr) Przyjęliśmy, że atrybuty Zar i RokUr są opcyjne, wobec czego: Klasa Prac zawiera wartość domyślną w postaci Zar( ), zaś klasa Osoba zawiera wartość domyślną w postaci RokUr(1900). Na samej górze znajdują się bindery do wnętrza przetwarzanego obiektu Nowaka, wśród których nie ma bindera dla Zar. Odpowiedni binder jest w sekcji klasy Prac. Wiązanie Zar zwróci zatem pusty zbiór. Przy wiązaniu RokUr odpowiedni binder jest na czubku stosu, wobec czego binder z nazwą RokUr w sekcji klasy Osoba nie będzie użyty; Stanowi on tylko zabezpieczenie przed sytuacją, gdy dla pewnego obiektu atrybut RokUr nie występuje. Wartości domyślne wstawione w ten sposób jako inwarianty do odpowiednich klas maję podwójną rolę: podstawienia odpowiedniej wartości w przypadku nieobecności pewnego podobiektu, zapobieganie fałszywemu wiązaniu.

30 © K.Subieta. Obiektowe języki zapytań 12, Folia 30 maj 2004 Niuanse semantyczne Można zauważyć, że binder taki jak Zar( ) pojawił się na stosie nieco wbrew objaśnianym dotąd regułom. Mianowicie, wewnątrz klasy Prac powinien być przechowywany obiekt o postaci i zgodnie z dotychczas określoną definicją funkcji nested, na stosie powinien pojawić się binder i zar raczej niż Zar( ). Binder Zar(i zar ) nie spełniałby jednak wymaganej przez tę własność roli. Obiekty przechowujące wartości domyślne w klasach powinny być dekorowane specjalną flagą, umożliwiającą wymaganą zmianę funkcji nested. Ta zmiana oznaczałaby jednak, że takich obiektów nie można byłoby aktualizować poprzez język zapytań. Wartości domyślne, jak wszystkie wartości, muszą jednak podlegać działaniom administracyjnym, np. usuwaniu lub zmianie. Zatem system, oprócz wspomnianej flagi musiałby rozróżniać intencje i/lub uprawnienia użytkowników: np. intencja administracyjna oznaczałaby normalne działanie funkcji nested, zaś intencja aplikacyjna oznaczałaby nieco zmienione działanie funkcji nested, w którym funkcja ta dokonuje automatycznie dereferencji.

31 © K.Subieta. Obiektowe języki zapytań 12, Folia 31 maj 2004 Aktualizacja wartości domyślnych Kolejne niuanse semantyczne dotyczą operacji aktualizacyjnych: podstawienia, usuwania i wstawiania. Jak poprzednio, aby umożliwić takie operacje na wartościach domyślnych, potrzebne będzie rozróżnienie intencji na administracyjną i aplikacyjną. Przy intencji administracyjnej działania te dotyczyłyby samych wartości domyślnych i działałyby na ich referencjach i wartościach. Przy intencji aplikacyjnej aktualizacje wartości domyślnych miałyby inną semantykę. Np. podstawienie na RokUr wartości 1951 w sytuacji, gdy dany obiekt nie posiada takiego atrybutu oznaczałoby wstawienie do obiektu nowego atrybutu, z nowym identyfikatorem. Podobnie z innymi operacjami. Objaśniona przez nas metoda jest przystosowana do wartości domyślnych, które są obiektami złożonymi. Jest również przystosowana do wartości domyślnych w postaci rezultatów wywoływanych funkcji.

32 © K.Subieta. Obiektowe języki zapytań 12, Folia 32 maj 2004 Wartości domyślne w modelu M3 M3 dzieli własności klas i obiektów na publiczne i prywatne. Własności prywatne danej klasy i obiektów tej klasy mogą być używane wyłącznie przez ciała metod zdefiniowanych w tejże klasie. Przy wywołaniu metody m wierzchołek ENVS powinien mieć następujące sekcje: Najwyżej: lokalną sekcję metody m, czyli jej zapis aktywacyjny; Poniżej: własności prywatne klasy, do której metoda m należy; Poniżej: własności prywatne i publiczne aktualnie przetwarzanego obiektu; Poniżej: własności publiczne klasy, do której należy metoda m i przetwarzany obiekt; Poniżej: własności publiczne nadklas, w odpowiedniej kolejności;... dalej jak zwykle; To gwarantuje, że wewnątrz ciała metody wartości domyślne nie przesłonią rzeczywistych wartości wpisanych explicite do obiektu.