Bazy danych i inżynieria oprogramowania

Download Report

Transcript Bazy danych i inżynieria oprogramowania

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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 1
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 2
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ć:
Określający co, a nie jak
Deklaracyjny
Makroskopowy
Przetwarzający quasi-równolegle wiele
danych w tym samym czasie
Niezależny od organizacji danych,
abstrakcyjny
Niezależny od reprezentacji danych,
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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 3
OQL -wstępne informacje (1)
OQL bazuje na modelu obiektowym ODMG
Object Query Language
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.)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 4
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).
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 5
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)
Bazuje na SQL?
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.
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 6
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
Pracownicy.nazwisko
Kowalski.żona.adres.ulica
(niestety, niekonsekwentna)
Wyrażenia ścieżkowe
(niestety, niekonsekwentne)
select max(select d.wiek from p.dzieci as d)
from Pracownicy as p where p.nazwisko = “Nowak“
Ortogonalność
select x.nazwisko, x.zarobek_netto()
from Pracownicy as p where p.nazwisko = “Walesa”
Wołanie metod
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 7
(niestety, niekonsekwentna)
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
Osoba
nazwisko
rok_ur
płeć
wiek
Ekstensje
Osoby
kieruje
Pracownik
zarobek
gr_zawodowa
Pracownicy
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 8
select distinct x.wiek from Osoby as x
where x.nazwisko = “Nowak”
select distinct struct(a: x.wiek, b: x.płeć)
from Pracownicy as x
where x.nazwisko = “Nowak”
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”
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 9
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” )
list( 1, 2, 2, 3, 1 )
set( 1, 2, 5 )
bag(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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 10
Co zwraca zapytanie?
Nie jest jasne, czy taka
kolekcja musi mieć
select x from Osoby as x where x.nazwisko = “Nowak” własną tożsamość, czy też
tożsamość ma mieć każdy
zwraca kolekcję obiektów Osoba posiadających nazwisko Nowak. zwracany obiekt, KS.
Kolekcję obiektów posiadających tożsamość, np.
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”
Literal, np.
Szef.zarobek
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 11
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.
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
obiekt
x. mąż_lub_żona.adres.miasto.nazwa
x -> mąż_lub_żona -> adres -> miasto -> nazwa
Osoba
dzieci
....
atrybut
pod-atrybut
pod-pod-atrybut
adres
....
miasto
....
Niestety, jeżeli związek nie jest 1:1, to tego
rodzaju nawigacja jest niedozwolona; należy
użyć standardowego select ... from...:
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...
x.dzieci.imię
nazwa
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 12
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 13
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.
Podaj osoby, w których
adresie brakuje miasta:
select nkmpl from Osoba as nkmpl
where is_undefined( nkmpl.adres.miasto )
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 14
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;
Podaj wiek najstarszego dziecka Kolskiego:
select max( select d.wiek from os.dzieci as d ) from Osoby as os
where os.nazwisko = “Kolski”
wiek jest metodą
zdefiniowaną dla
obiektów Osoba.
Jeżeli metoda zwróci obiekt (referencję?), to od takiego obiektu można
dalej nawigować:
najstarsze_dziecko
Podaj ulice na których mieszkają najstarsze dzieci
jest metodą zdefiniowaną dla
osób z Burakowa:
obiektów Osoba i zwracającą
obiekt Osoba;
select os.najstarsze_dziecko.adres.ulica from Osoby as os
where os.mieszka_w( “Buraków” )
mieszka-w jest metodą z
jednym parametrem
zwracającą True lub False.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 15
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
Pracownik
...
co_robi
select os.co_robi
from Osoby as os
Student
...
co_robi
W takich sytuacja czesto trzeba
wskazać klasę (zastosować casting):
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 10, Folia 16
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.
select ((Student)os).rok_studiów
from Osoby as os
where “studiuje” in os.co_robi