Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd Języki i środowiska programowania systemów rozproszonych Wykładowca: Tomasz Kowalski Wykłady przygotowane na podstawie materiałów prof. Kazimierza Subiety Wykład 2 Wprowadzenie do języków zapytań

Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 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 Zasady języków zapytań (2) Naturalność Prostota Ortogonalność Kompozycyjność Relatywizm Minimalność (brzytwa Occama) Brak anomalii Uniwersalność Modularność (hermetyzacja) Bezpieczeństwo 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ń.

Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 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 Niezgodność impedancji (1) 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ą pod- ję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. impedance mismatch

Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 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 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 Zależności pomiędzy pojęciami języka zapytań Dziedzina przedmiotowa, uniwersum rozważań Model składu danych Meta-model Schemat składu (bazy) danych Bieżący stan składu danych Zapytanie wiedza o strukturach danych Wynik zapytania znaczenie danych potrzeba interpretacja wyniku Możliwy stan składu danych

Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 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 meta- modelu 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 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 Osoba [0..*] nazw: string wiek: integer zarobek: integer [0..1] Firma [0..*] nazwa: string lokacja: string [1..*] pracuje w [0..1] zatrudnia [0..*] i 10 Osoba i 11 nazw Abacki i 12 wiek 29 i 13 zarobek 1900 i 14 pracuje w i 20 Osoba i 21 nazw Nowak i 22 wiek 33 i 30 Firma i 31 nazwa Asko i 32 lokacja Radom i 33 lokacja Piła i 34 zatrudnia Schemat składu danych i przykładowy stan składu Schemat Jeden z możliwych stanów

Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 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 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 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 Przykład: schemat podobnej relacyjnej bazy danych 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. Firma(NrF, Nazwa) Lokal(NrF, Miejsce) Zatrudnienie(NrF, NrP) Pracownik(NrP, NrOs) Oceny(NrOceny, Ocena, NrF, NrP) Dochód ( NrDochodu, Wypłata, NrF, NrP) Osoba (NrOs, Nazwisko) Wyszkolenie (Stan, NrP) Imiona (NrOs, Imię) Adresy (NrOs, Adres )

Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd Przykład: schemat prostej obiektowej bazy danych 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. FZ[0..*] Osoba[0..*] Nazwisko Imię[1..*] Adres[1..*] ZFZFPZ[0..*]ZPZP Firma[0..*] Nazwa Miejsce[1..*] Zatrudnienie[0..*] Wypłata[0..*] Ocena[1..*] Pracownik[0..*] Stan[1..*]

Języki i środowiska programowania systemów rozproszonych, Wykład 02, Slajd 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.