Bazy danych i inżynieria oprogramowania Wykład 10: Wprowadzenie do standardu ODMG, część 4: OQL Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Plan wykładu (część 4) Wstępne informacje o OQL Wynik zapytań w OQL Tworzenie obiektów Wyrażenia ścieżkowe Predykaty, złączenia Wartości zerowe Wołanie metod

Co to jest język zapytań? Nie jest to kompletny język programowania, lecz język umożliwiający w dokonywanie w sprawny sposób podstawowych operacji na bazie danych, głównie wyszukiwawczych. Język zapytań musi być: Deklaracyjny Określający co, a nie jak Makroskopowy Przetwarzający quasi-równolegle wiele danych w tym samym czasie Niezależny od organizacji danych, Niezależny od reprezentacji danych, abstrakcyjny indeksów, tablic wskaźników, organizacji plików, itd. Naturalny dla użytkownika Wspomagający naturalne schematy myślenia, łatwy do nauczenia i używania Automatycznie optymalizowalny Umożliwiający zastosowanie metod radykalnej poprawy czasu wykonania Interpretowany Umożliwiający zapytania ad hoc, dynamiczne tworzenie perspektyw i zapamiętanych procedur, itp.

OQL -wstępne informacje (1) Object Query Language OQL bazuje na modelu obiektowym ODMG OQL jest obiektowym językiem zapytań w stylu SQL (ale zbieżność jest powierzchowna, KS.). Rozbieżności dotyczą pojęć obiektowych, takich jak złożone obiekty, tożsamość obiektów, wyrażenia ścieżkowe, polimorfizm, wołanie operacji, późne wiązanie OQL przewiduje konstrukcje wysokiego poziomu do przetwarzania zbiorów obiektów, ale nie jest ograniczony do przetwarzania zbiorów (może również przetwarzać struktury, listy, tablice, itp. z taka samą efektywnością) OQL zapewnia swobodne ortogonalne kombinowanie operatorów, o ile tylko nie narusza to mocnej kontroli typów. Wynika to z faktu, że rezultat zapytania ma typ należący do systemu typów ODMG i w związku z tym może stanowić argument większego zapytania. (Faktycznie, OQL jest w tym względzie lepszy od SQL, ale daleki od ideału, KS.) OQL nie jest kompletny obliczeniowo (tj. są zapytania, których nie można w nim zadać, nie posiada operacji aktualizacyjnych, nie posiada abstrakcji programistycznych i konstrukcji sterujących, KS.)

OQL -wstępne informacje (2) Zapytania OQL mogą być używane wewnątrz języków programowania, dla których ODMG zdefiniował wiązania. OQL może także wołać operacje zdefiniowane w tych językach programowania. OQL nie przewiduje explicite operacji aktualizacyjnych, ale może wywoływać operacje zapisane w innych językach, które są dla tego celu zdefiniowane. Jest to motywowane “obiektowością”, która zdaniem ODMG zakłada, że wszystko co dzieje się na obiektach ma być wykonywane za pomocą “metod” (jest tu pewne nieporozumienie: nie można uniknąć niektórych operacji generycznych; KS) OQL zapewnia deklaracyjny (nieproceduralny) dostęp do obiektów. Stąd wynika, że zapytania OQL mogą być łatwo optymalizowane, co wynika z istoty deklaracyjności (jest to pobożne życzenie, KS.) Formalna semantyka OQL może być łatwo zdefiniowana. (Jest to nieprawda, formalna semantyka OQL jest poważnym problemem badawczym; na szczęście nie jest to problem praktyczny; KS).

Krótka charakterystyka OQL Cele: Interakcyjne zapytania (są wątpliwości, jest to język zbyt skomplikowany dla tego celu, KS) Programowanie poprzez zanurzenie w C++, Smalltalk, Java,... (luźne zintegrowanie, loose coupling) Jest to mimikra mająca chyba na celu wytrącenie broni z ręki ideologom broniącym “intergalaktycznego” znaczenia SQL. Konsekwencją są bardzo kontrowersyjne decyzje syntaktyczne (za dużo lukru, zbyt duże syntaktyczne zlepki), KS. Bazuje na SQL? Semantyka prawie całkowicie odchodzi od SQL: Złożone obiekty Tożsamość obiektów Mocna kontrola typów Klasy (dziedziczenie, przesłanianie) Metody (pisane w jęz. programowania) Hermetyzacja (ograniczona) Nawigacje, wyrażenia ścieżkowe (path expressions) Złączenia (joins) w wariancie nawigacyjnym (dependent joins) Asocjacyjne powiązania

OQL - kilka przykładów select x from Profesorowie as x where x.zarobek > 5000 Dziedziczenie select s.nazwisko, w.nazwa_wykładu from Studenci as s, s.jest_zapisany_na as w Zależne złączenie Rezygnacja z lukru SQL (niestety, niekonsekwentna) Pracownicy.nazwisko Wyrażenia ścieżkowe (niestety, niekonsekwentne) Kowalski.żona.adres.ulica select max(select d.wiek from p.dzieci as d) from Pracownicy as p where p.nazwisko = “Nowak“ Ortogonalność (niestety, niekonsekwentna) select x.nazwisko, x.zarobek_netto() from Pracownicy as p where p.nazwisko = “Walesa” Wołanie metod

Wejście i wynik zapytań w OQL Jako samodzielny język, OQL umożliwia formułowanie zapytań skierowanych do obiektów bazując na ich nazwach, które są punktami wejściowymi w bazie danych. Nazwa może dotyczyć dowolnego rodzaju obiektów: atomowych, struktur, kolekcji, literali (?, KS) Jako język zanurzony, OQL formułowanie zapytań skierowanych do obiektów j.w., które są podtrzymywane przez dany język programowania. Zapytanie w OQL jest traktowane jako funkcja, której wynikiem jest obiekt o typie określonym przez zapytanie. Klasy Ekstensje Osoba nazwisko rok_ur płeć wiek Osoby select distinct x.wiek from Osoby as x where x.nazwisko = “Nowak” kieruje select distinct struct(a: x.wiek, b: x.płeć) from Pracownicy as x where x.nazwisko = “Nowak” Pracownicy Pracownik zarobek gr_zawodowa

Przykłady w OQL Operator select wewnątrz select: Dla każdego pracownika, podaj nazwisko oraz zbiór kierowanych przez niego pracowników, którzy zarabiają ponad 10000: select distinct struct( nazwisko: x.nazwisko, elita: (select y from x.kieruje as y where y.zarobek > 10000)) from Pracownicy as x Rezultat jest typu: set <struct( nazwisko: string, elita: bag<Pracownik>)> Operator select wewnątrz from: Dla pracowników o nazwisku Nowak z 10-tej grupy zawodowej, podaj wiek i płeć: select struct( w: x.wiek, p: x.płeć ) from (select y from Pracownicy as y where y.gr_zawodowa = “10”) as x where x.nazwisko = “Nowak”

Tworzenie obiektów Tworzenie obiektu Osoba Osoba( nazwisko: “Nowak”, data_ur: “2/28/56”, płeć: “M” ) Taka konstrukcja jest odróżniana od konstrukcji zwracającej literał (obiekt bez tożsamości, czyli wartość): struct( a: 10, b: “Adam” ) set( 1, 2, 5 ) bag(1, 2, 2, 3, 1 ) list( 1, 2, 2, 3, 1 ) array( 1, 2, 2, 3, 1 ) Tworzenie obiektów w ramach języka zapytań jest nie do przyjęcia. Normalnie, język zapytań jest językiem pasywnym, nie zmieniającym stanu; dopiero zanurzenie zapytań w konstrukcje imperatywne pozwala zmienić stan. Jest to semantyczna niekonsekwencja, która rodzi poważne problemy: (1) jeżeli nie ma ekstensji, w jakim środowisku (module?) tworzone są nowe obiekty? (2) Co zwraca takie zapytanie i czy może być kombinowane z innymi zapytaniami? (3) Dlaczego jest tworzenie, a nie ma usuwania, wstawiania, i podstawiania? ODMG naraża się tu na zarzut niekompetencji w zakresie konstrukcji języków programowania.

Co zwraca zapytanie? Kolekcję obiektów posiadających tożsamość, np. Nie jest jasne, czy taka kolekcja musi mieć własną tożsamość, czy też tożsamość ma mieć każdy zwracany obiekt, KS. Kolekcję obiektów posiadających tożsamość, np. select x from Osoby as x where x.nazwisko = “Nowak” zwraca kolekcję obiektów Osoba posiadających nazwisko Nowak. Obiekt z tożsamością, np. element( select x from Osoby as x where x.PESEL =“44071900010”) zwraca obiekt Osoba posiadających nr PESEL 44071900010. Kolekcję literali, np. select x.NrPaszportu from Osoby as x where x.gr_zawodowa = “10” Pomysł, że zapytanie zwraca obiekty, a nie referencje do obiektów, jest chory. Określenie dziedzin semantycznych dla zapytań jest mało precyzyjne i mało kompetentne. Literal, np. Szef.zarobek

Wyrażenia ścieżkowe Startując od obiektu, można nawigować w głąb jego struktury, lub wzdłuż prostych związków: Niech x będzie zmienną, an którą podstawia się obiekt Osoba: Osoba as x Nazwa miasta, w którym żyje małżonek(-ka) osoby x: mąż_lub_żona x. mąż_lub_żona.adres.miasto.nazwa obiekt Osoba x -> mąż_lub_żona -> adres -> miasto -> nazwa dzieci .... adres atrybut Niestety, jeżeli związek nie jest 1:1, to tego rodzaju nawigacja jest niedozwolona; należy użyć standardowego select ... from...: .... miasto pod-atrybut select y.imię from x.dzieci as y x.dzieci.imię .... nazwa pod-pod-atrybut Uzasadnienie dla tego ograniczenia pozwala sądzić, że niektórzy ludzie z ODMG nie kojarzą, gdzie jest składnia, a gdzie semantyka...

Predykaty, złączenia predicates, joins Podaj adresy dzieci osób żyjących na ulicy Blacharskiej, mających co najmniej dwoje dzieci. Interesują nas tylko dzieci żyjące w innym mieście niż rodzice. select c.adres from Osoby as x, x.dzieci as d where x.adres.ulica = “Blacharska” and count(x.dzieci) >= 2 and d.adres.miasto != x.adres.miasto Rozbudowany predykat Mamy dwie kolekcje, Osoby i Kwiaty. Podaj osoby, których nazwiska są nazwami kwiatów: Złączenie a la SQL select p from Osoby as p, Kwiaty as k where p.nazwisko = k.nazwa

Wartości zerowe null values Rezultat dostępu do własności/obiektu posiadającego wartość nil jest UNDEFINED. Reguły przetwarzania UNDEFINED: Operator . lub -> działający na UNDEFINED zwraca UNDEFINED Porównanie UNDEFINED z czymkolwiek zwraca FALSE Dwie funkcje: is_undefined(UNDEFINED) = TRUE is_defined(UNDEFINED) = FALSE Dowolna inna operacja na UNDEFINED powoduje błąd wykonania. KS: Naiwne podejście do poważnego problemu wartości zerowych. ODMG modyfikuje tu nieco paranoiczne rozwiązania przyjęte w SQL (patrz artykuły Ch. Date), ale jest to leczenie bólu zęba przy pomocy herbatki ziołowej. Podaj osoby, w których adresie brakuje miasta: select nkmpl from Osoba as nkmpl where is_undefined( nkmpl.adres.miasto )

Wołanie metod Nie ma istotnej różnicy w użyciu nazwy atrybutu i nazwy metody; Podaj wiek najstarszego dziecka Kolskiego: wiek jest metodą zdefiniowaną dla obiektów Osoba. select max( select d.wiek from os.dzieci as d ) from Osoby as os where os.nazwisko = “Kolski” Jeżeli metoda zwróci obiekt (referencję?), to od takiego obiektu można dalej nawigować: najstarsze_dziecko jest metodą zdefiniowaną dla obiektów Osoba i zwracającą obiekt Osoba; mieszka-w jest metodą z jednym parametrem zwracającą True lub False. Podaj ulice na których mieszkają najstarsze dzieci osób z Burakowa: select os.najstarsze_dziecko.adres.ulica from Osoby as os where os.mieszka_w( “Buraków” )

Polimorfizm, późne wiązanie, wskazanie klasy polymorphism, late binding, class indicator Przy wołaniu metod, brana jest pod uwagę metoda, która jest najbliżej obiektu będacego adresatem komunikatu. Decyzję, którą metodę należy wybrać podejmuje się podczas czasu wykonania. Osoba ... co_robi select os.co_robi from Osoby as os W zależności od tego, czy konkretna Osoba jest po prostu osobą, czy też pracownikiem, czy też studentem, wybierana jest dynamicznie inna metoda co_robi. Pracownik ... co_robi Student select ((Student)os).rok_studiów from Osoby as os where “studiuje” in os.co_robi W takich sytuacja czesto trzeba wskazać klasę (zastosować casting):