Bazy danych i inżynieria oprogramowania

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 1

Bazy danych i inżynieria oprogramowania

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 10:

Wprowadzenie do standardu ODMG, część 4: OQL


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

Bazuje na SQL?Jest to mimikra mająca chyba na celu wytrącenie broni z rękiideologom broniącym “intergalaktycznego” znaczenia SQL.Konsekwencją są bardzo kontrowersyjne decyzje syntaktyczne (za dużo lukru, zbyt duże syntaktyczne zlepki), KS.

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

• 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)

Cele:


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

Pracownicy.nazwiskoRezygnacja z lukru SQL (niestety, niekonsekwentna)

Kowalski.żona.adres.ulicaWyrażenia ścieżkowe(niestety, niekonsekwentne)

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 OQLJako 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.

Pracownikzarobek

gr_zawodowa

Klasy Ekstensje

Osoby

Pracownicy

select distinct x.wiek from Osoby as xwhere x.nazwisko = “Nowak”

Osobanazwisko

rok_urpłećwiek

select distinct struct(a: x.wiek, b: x.płeć) from Pracownicy as xwhere x.nazwisko = “Nowak”

kieruje


Przykłady w OQL

select distinct struct( nazwisko: x.nazwisko, elita: (select y from x.kieruje as y where y.zarobek > 10000))

from Pracownicy as x

Dla każdego pracownika, podaj nazwisko oraz zbiór kierowanych przez niego pracowników, którzy zarabiają ponad 10000:

Rezultat jest typu: set <struct( nazwisko: string, elita: bag<Pracownik>)>

select struct( w: x.wiek, p: x.płeć )from (select y from Pracownicy as y where y.gr_zawodowa = “10”) as xwhere x.nazwisko = “Nowak”

Operator select wewnątrz select:

Operator select wewnątrz from:

Dla pracowników o nazwisku Nowak z 10-tej grupy zawodowej, podaj wiek i płeć:


Tworzenie obiektów

Osoba( nazwisko: “Nowak”, data_ur: “2/28/56”, płeć: “M” )

Tworzenie obiektu Osoba

Taka konstrukcja jest odróżniana od konstrukcji zwracającej literał (obiekt bez tożsamości, czyli wartość):

struct( a: 10, b: “Adam” )

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.

set( 1, 2, 5 )

list( 1, 2, 2, 3, 1 )

bag(1, 2, 2, 3, 1 )

array( 1, 2, 2, 3, 1 )


Co zwraca zapytanie?

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.

Nie jest jasne, czy taka kolekcja musi mieć własną tożsamość, czy też tożsamość ma mieć każdy zwracany obiekt, KS.

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.

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.

Kolekcję literali, np.

select x.NrPaszportu from Osoby as x where x.gr_zawodowa = “10”

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:

Osoba as x

x. mąż_lub_żona.adres.miasto.nazwa

Nazwa miasta, w którym żyje małżonek(-ka) osoby x:

Niech x będzie zmienną, an którą podstawia się obiekt Osoba:

Osoba

mąż_lub_żona

adres....

miasto

nazwa

....

....

obiekt

atrybut

pod-atrybut

pod-pod-atrybut

x -> mąż_lub_żona -> adres -> miasto -> nazwa

Niestety, jeżeli związek nie jest 1:1, to tego rodzaju nawigacja jest niedozwolona; należy użyć standardowego select ... from...:

dzieci

x.dzieci.imięselect y.imięfrom x.dzieci as y

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

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 dwhere x.adres.ulica = “Blacharska” and

count(x.dzieci) >= 2 andd.adres.miasto != x.adres.miasto

predicates, joins

select p from Osoby as p, Kwiaty as kwhere p.nazwisko = k.nazwa

Rozbudowany predykat

Złączenie a la SQL

Mamy dwie kolekcje, Osoby i Kwiaty. Podaj osoby, których nazwiska są nazwami kwiatów:


Wartości zerowenull values

Rezultat dostępu do własności/obiektu posiadającego wartość nil jest UNDEFINED.

Operator . lub -> działający na UNDEFINED zwraca UNDEFINED

Porównanie UNDEFINED z czymkolwiek zwraca FALSE

Dwie funkcje: is_undefined(UNDEFINED) = TRUEis_defined(UNDEFINED) = FALSE

Dowolna inna operacja na UNDEFINED powoduje błąd wykonania.

Reguły przetwarzania UNDEFINED:

select nkmpl from Osoba as nkmplwhere is_undefined( nkmpl.adres.miasto )

Podaj osoby, w których adresie brakuje miasta:

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.


Wołanie metod

Nie ma istotnej różnicy w użyciu nazwy atrybutu i nazwy metody;

select max( select d.wiek from os.dzieci as d ) from Osoby as oswhere os.nazwisko = “Kolski”

Podaj wiek najstarszego dziecka Kolskiego:

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.

Jeżeli metoda zwróci obiekt (referencję?), to od takiego obiektu można dalej nawigować:

select os.najstarsze_dziecko.adres.ulica from Osoby as oswhere os.mieszka_w( “Buraków” )

Podaj ulice na których mieszkają najstarsze dzieci osób z Burakowa:

wiek jest metodą zdefiniowaną dla obiektów Osoba.


Polimorfizm, późne wiązanie, wskazanie klasy ost 16.12.03polymorphism, 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

Pracownik...

co_robi

Student...

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.

W takich sytuacja czesto trzeba wskazać klasę (zastosować casting):

select ((Student)os).rok_studiów from Osoby as oswhere “studiuje” in os.co_robi

Bazy danych i inżynieria oprogramowania

Documents

Transcript of Bazy danych i inżynieria oprogramowania