Obiektowe języki zapytań 1..5

Języki i środowiska programowania
systemów rozproszonych
Wykład 2
Wprowadzenie do
języków zapytań
Wykładowca: Tomasz Kowalski
Wykłady przygotowane na
podstawie materiałów
prof. Kazimierza Subiety
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 1
2011
Zasady języków zapytań (1)
 Ostatnio, zasady wypracowane przez świat akademicki są
kwestionowane przez świat przemysłowy. Wynika to z dwóch
przyczyn:
• dla firm komercyjnych jest bardzo niewygodne stwierdzenie, że jakaś
cecha ich produktu jest "niezgodna z zasadą". Kwestionuje się więc
zasadę.
• świat akademicki zbyt pochopnie wypracowuje „zasady”, które tak
naprawdę są często motywowane pewną koncepcją teoretyczną,
ideologią, formą lub steoretypem. Przykładem są „zasady” baz danych
wypracowane przez model relacyjny, które w całości można wyrzucić
do kosza, jeżeli przejdziemy na model obiektowy.
 Zadaniem świata akademickiego jest jednak wypracowanie i
obrona zasad.
 Dalej są podane podstawowe zasady obowiązujące w językach
zapytań (czasami nie tylko w językach zapytań).
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 2
2011
Zasady języków zapytań (2)
 Naturalność
 Prostota
 Ortogonalność
 Kompozycyjność
 Relatywizm
 Minimalność (brzytwa
Occama)
 Brak anomalii
 Uniwersalność
 Modularność (hermetyzacja)
 Bezpieczeństwo
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 3
 Specjalna troska o przypadki
skrajne
 Koncepcyjna kontynuacja
 Jednorodne podejście do
konstrukcji
programistycznych
 Nie zaniedbywanie
jakiegokolwiek problemu
semantycznego.
• Każdy, nawet najmniejszy
problem semantyczny jest
dużym problemem.
 Wysoki potencjał dla
optymalizacji zapytań.
2011
Obiektowość a języki zapytań
 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óle nie mogą być wyposażone w języki zapytań.
• Podobne poglądy do pewnego czasu głosił J. Ullman.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 4
2011
Niezgodność impedancji (1)
impedance mismatch
 Wykształcone w latach 70-tych koncepcje dotyczące języków
zapytań z definicji zakładały brak algorytmicznej uniwersalności.
 Ponieważ taka uniwersalność jest niezbędna do tworzenia aplikacji
opartych na bazie danych, przyjęto, że języki zapytań będą „podjęzykami” w środowisku wytwórczym oprogramowania
 Co za tym idzie, to środowisko powinno być oparte na popularnym
języku programowania. To oznacza konieczność połączenia języka
zapytań z językiem programowania, w taki sposób, aby:
• zapytania mogły być używane wewnątrz programów;
• zapytania mogły być parametryzowane (dynamicznie, w praktycznie
dowolny sposób) przez wartości zmiennych języka programowania;
• wyniki zapytań mogły być przetwarzane przez programy.
 Różnice w koncepcji języków spowodowały znaczne trudności techniczne
w realizacji tego rodzaju połączenia  niezgodność impedancji.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 5
2011
Niezgodność impedancji (2)
 Terminem tym określa się niekorzystne cechy formalnego połączeniu
języka zapytań (np. SQL) z językiem programowania takim jak np. C lub
Java. Objawia się niezgodnościami w zakresie:
•
•
•
•
•
•
•
•
•
Składni.
Systemu typów.
Semantyki i paradygmatów języków.
Poziomu abstrakcji.
Faz i mechanizmów wiązania.
Przestrzeni nazw i reguł zakresu.
Traktowania wartości zerowych.
Schematów iteracyjnych.
Traktowania cechy trwałości danych.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 6
2011
Schemat i organizacja danych
 Są to nieodłączne cechy języka zapytań.
 Użytkownik języka musi być w pełni świadomy celów formułowania
zapytania, związków zapytania zarówno z jego celem (biznesowym), jak i
strukturą danych.
 Musi być świadomy technicznych i biznesowych własności struktur
danych oraz technicznych i biznesowych własności zwracanego przez
zapytanie wyniku.
 Warunkiem koniecznym umożliwiającym formułowanie zapytań jest
informacja co zawiera baza danych i jak jest zorganizowana.
• Ta informacja musi mieć algorytmiczną precyzję.
• Determinizm programów komputerowych (w tym zapytań) oznacza, że
użytkownik lub programista posiada wiedzę o logicznej organizacji danych.
• Terminem „logiczna” określa się organizację danych wyrażoną w terminach
precyzyjnego „zewnętrznego” modelu danych, abstrahującą od fizycznej
reprezentacji danych.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 7
2011
Zależności pomiędzy pojęciami języka zapytań
Model składu
danych
Meta-model
znaczenie
danych
Dziedzina
przedmiotowa,
uniwersum rozważań
Schemat składu
(bazy) danych
wiedza o
strukturach
danych
potrzeba
Możliwy stan składu
danych
Możliwy stan składu
danych
Możliwy stan składu
danych
Możliwy stan składu
danych
Bieżący stan składu
danych
Zapytanie
interpretacja
wyniku
Wynik
zapytania
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 8
2011
Pojęcia języka zapytań (1)
 Model składu danych wyznacza reguły budowy oraz ograniczenia struktur
danych,
• pośrednio określa składnię i semantykę języka schematu danych oraz metamodelu ustalającego organizację danych.
 Schemat składu (lub bazy) danych powstaje w wyniku analizy dziedziny
przedmiotowej (biznesu), zakresu aplikacji, które mają go wspomagać
oraz projektu struktury (bazy) danych niezbędnej do działania tych
aplikacji.
 Skład lub baza danych zawiera konkretne dane zgodne z modelem
danych, kontrolowane przez meta-model i schemat składu danych.
• Bieżący stan składu danych zmienia się i zwykle jest nieznany dla
użytkownika w momencie pisania zapytania.
• Z tego względu zapytanie jest formułowane w odniesieniu do (zwykle
nieskończonego) zbioru możliwych stanów składu.
• Zbiór ten jest określony semantyką schematu.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 9
2011
Pojęcia języka zapytań (2)
 Zapytanie jest formułowane przez użytkownika na podstawie rozpoznanej
potrzeby w dziedzinie przedmiotowej oraz na podstawie wiedzy o
strukturach danych.
• Wiedza ta jest wyznaczona schematem oraz związkiem schematu z dziedzina
przedmiotową.
 Wynik zapytania powstaje jak skutek zapytania oraz bieżącego stanu
składu danych.
• Wynik jest interpretowany przez użytkownika w dziedzinie przedmiotowej,
• Może on go poprawnie przetwarzać przy pomocy innych własności systemu.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 10
2011
Schemat składu danych i przykładowy stan składu
Osoba [0..*]
nazw: string
wiek: integer
zarobek: integer [0..1]
pracuje w [0..1]
Schemat
zatrudnia [0..*]
Firma [0..*]
nazwa: string
lokacja: string [1..*]
i10 Osoba
Jeden z
możliwych
stanów
i20 Osoba
i30 Firma
i11 nazw ”Abacki”
i21 nazw ”Nowak”
i31 nazwa ”Asko”
i12 wiek 29
i22 wiek 33
i32 lokacja ”Radom”
i13 zarobek 1900
i33 lokacja „Piła”
i14 pracuje w
i34 zatrudnia
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 11
2011
Co użytkownik musi wiedzieć?
 Poprzedni slajd przedstawia przykład schematu danych, z którego
użytkownik:
•
•
•
•
•
widzi z jakimi obiektami biznesowymi ma do czynienia (Osoba i Firma),
rozumie ich znaczenie w dziedzinie biznesowej,
wie jakie mają atrybuty (wraz z typami),
wie jak są ze sobą powiązane (powiązania pracuje w/zatrudnia),
zna też liczności wszystkich elementów w dowolnym stanie składu, np. wie,
że obiektów Osoba może być od zera do dowolnej liczby, atrybut zarobek
może nie wystąpić, zaś firma może być zlokalizowana w jednym lub więcej
miejsc.
 Slajd przedstawia też przykładowy stan składu danych odpowiadający
temu schematowi.
• prawdziwego stanu użytkownik zwykle nie zna,
• na podstawie pewnych wyobrażeń odnośnie własności logicznych struktur
danych może poprawnie zbudować zapytanie.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 12
2011
Język schematu
 Użytkownik formułujący zapytanie powinien posiadać i rozumieć opis
danych zawartych w składzie (bazie) danych.
 Powinien to być schemat danych zapisany w odpowiednim precyzyjnym
języku.
 Wzorcem takiego języka może być IDL standardu CORBA, ODL
standardu ODMG, lub DTD (lub XML Schema) dla repozytoriów XML.
 Schemat danych jest opisem (nieskończonego) zbioru stanów składu
danych rozumianych na poziomie logicznym, z algorytmiczną precyzją.
 Brak precyzyjnego modelu składu danych uniemożliwia zdefiniowanie
semantyki języka zapytań.
• Przykładowo, diagram klas UML przypomina schemat składu (bazy) danych.
• Ten schemat nie definiuje jednak pojęcia stanu składu danych.
• Stąd precyzyjne zdefiniowanie języka zapytań dla UML jest niemożliwe.
 Podobnie do rozumienia stanów składu danych, użytkownik musi
rozumieć wynik zapytania, na poziomie logicznym, z algorytmiczna
precyzją.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 13
2011
Złożoność modelu danych a złożoność zapytań
 Im więcej informacji semantycznej znajduje się w strukturach
danych, tym mniej złożone i krótsze są zapytania.
• Jeżeli model danych nie daje możliwości zapisu pewnych informacji
semantycznych, wówczas schemat danych niezbędny do rozumienia
biznesowej roli danych jest prosty formalnie, ale złożony koncepcyjnie.
• Jest mniej czytelny dla programisty, co wydłuża czas formułowania zapytań.
• Programista formułujący zapytanie musi te zależności uwzględnić w
zapytaniu, przez co jest ono bardziej złożone.
 Zbyt prosty model danych powoduje dalsze straty:
• zwiększony rozmiar programów aplikacyjnych,
• zwiększony koszt ich tworzenia i pielęgnacji,
• zwiększony koszt/czas ewaluacji bardziej złożonych zapytań.
• Optymalizacji zapytań w relacyjnych SZBD zajmuje się częściowo reperowaniem
tego, co zostało zepsute poprzez zgubienie informacji semantycznej.
 Zbyt złożony model danych jest też niekorzystny – trudniej dopasować
sytuacje w dziedzinie biznesowej do decyzji w zakresie struktur danych.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 14
2011
Przykład: schemat podobnej relacyjnej bazy danych
Firma(NrF, Nazwa)
Zatrudnienie(NrF, NrP)
Pracownik(NrP, NrOs)
Lokal(NrF, Miejsce)
Oceny(NrOceny, Ocena, NrF, NrP)
Dochód(NrDochodu, Wypłata, NrF, NrP)
Osoba(NrOs, Nazwisko)
Wyszkolenie(Stan, NrP)
Imiona(NrOs, Imię)
Adresy(NrOs, Adres)
 Część informacji semantycznej została utracona, np. informacja o
licznościach atrybutów i związków.
 Programista spędzi kilkanaście minut nad zrozumieniem zależności.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 15
2011
Przykład: schemat prostej obiektowej bazy danych
Osoba[0..*]
Nazwisko
Imię[1..*]
Adres[1..*]
Firma[0..*]
FZ[0..*]
Nazwa
Miejsce[1..*]
Zatrudnienie[0..*]
ZF Wypłata[0..*]
Ocena[1..*]
ZP
Pracownik[0..*]
PZ[0..*] Stan[1..*]
 Programista po 2-3 minutach wyjaśnień jest w stanie zorientować się w
zawartości bazy danych.
 Zawiera ona cztery klasy obiektów, związki asocjacji z rolami, liczności
kolekcji obiektów, asocjacji i atrybutów oraz związek dziedziczenia.
• Ze schematu wynika np. że każdy pracownik jest osobą, ma jedno nazwisko,
lecz może mieć wiele imion i adresów, może pracować wielu firmach,
posiadać wiele wypłat i ocen w każdej z nich, itd.
• Po tych wyjaśnieniach bez trudu sformułuje zapytania np. w SBQL.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 16
2011
Straty na formułowaniu zapytań
 Oprócz zwiększenia złożoności schematu relacyjnego (wskutek fałszywego
dążenia do „prostoty” modelu danych) skutki ograniczonej informacji
semantycznej odbijają się na zapytaniach:
Podaj nazwiska i stanowiska pracowników pracujących w firmach zlokalizowanych w Radomiu:
 SBQL, model obiektowy (21 elementów leksykalnych):
(Firma where ”Radom” Miejsce).
FZ.Zatrudnienie.ZP.Pracownik.(Nazwisko, Stan)
 SQL, model relacyjny (78 elementów leksykalnych):
select s.Nazwisko, w.Stan
from Firma as f, Lokal as k, Zatrudnienie as z,
Pracownik as p, Wyszkolenie as w, Osoba as s
where k.Miejsce = “Radom” and k.NrF = f.NrF
and f.NrF = z.ZF and z.ZP = p.NrP and w.NrP = p.NrP
and p.NrOs = s.NrOs
 Zapytanie w SQL jest dłuższe od zapytania w SBQL głównie wskutek tego, że w
SQL konieczne są predykaty (np. k.NrF = f.NrF) kojarzące informację
semantyczną, która została zgubiona w relacyjnej strukturze danych.
Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 17
2011