Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych [email protected]

K.Subieta: Podejście stosowe 1/30

Kazimierz SubietaPolsko-Japońska Wyższa Szkoła

Technik Komputerowych

[email protected]

http://www.ipipan.waw.pl/~subieta

Podejście stosowe do obiektowych języków programowania baz danychhttp://www.sbql.pl

Wykład 01 Wprowadzenie do SBA i SBQL


Plan wykładu

• Geneza i motywacje języka SBQL• Podejście stosowe do obiektowych języków zapytań• Architektura przetwarzania zapytań i programów• Zapytania i programy w SBQL• Wirtualne aktualizowalne perspektywy• Optymalizacje w SBQL• System ODRA i jego środowisko• Obecny stan rozwoju języka SBQL• Podsumowanie


Geneza i motywacje języka SBQL

• W połowie lat 1980-tych zwrócono uwagę na braki teorii i technologii baz danych (BD)– Mit „solidnych matematycznych podstaw” relacyjnych BD

• algebra relacji < 10% funkcjonalności języka SQL

– „Niezgodność impedancji 1”: negatywny efekt połączenia języka zapytań z uniwersalnym językiem programowania

– „Niezgodność impedancji 2”: obiektowe projektowanie i programowanie sprzeczne z relacyjnymi BD

• Lata 1990-te: obiektowość w modelowaniu, projektowaniu, programowaniu i opr. pośredniczącym

• Popularność obiektowych języków programowania• Liczne pomysły i realizacje obiektowych BD


Motywacja: obiektowość

• Obiektowość jest ideologią informatyczną o luźno zarysowanych założeniach, pojęciach i granicach. – Różnice pomiędzy różnymi koncepcjami obiektowości są

fundamentalne, np. różnice pomiędzy modelem obiektowym notacji UML i modelem obiektowym języka SQL-99.

• Centralny motyw: dopasowanie modeli komputerowych do własności ludzkich zmysłów i mózgu oraz mechanizmów percepcji i rozumienia świata.

• Świat jest postrzegany przez ludzi jako mnogość obiektów, powiązań pomiędzy obiektami oraz zachowania się obiektów.

• Klasyfikacja obiektów na podstawie ich niezmienników.


Motywacja: brak niezgodności impedancji

• Niezgodność impedancji 1: w językach programowania zapytania są stringami– Różnice: składnia, semantyka, typy, fazy wiązania, …

• Lek → język programowania baz danych zintegrowany z językiem zapytań

• Niezgodność impedancji 2: obiektowy wynik analizy i projektowania zniekształcony poprzez odwzorowanie do schematu relacyjnego.– Odwzorowanie odwrotne często niemożliwe i bezsensowne

• Lek → obiektowy schemat bazy danych– Najlepiej zgodny z językiem analizy i modelowania, np.UML


Geneza SBA i SBQL

• Habilitacja z podejścia stosowego (SBA) do zapytań 1988• Implementacje Netul i Loqis 1989-1991– Potem długo nic.

• Powrót do koncepcji: rok 2000– Wykłady i seminaria z podejścia stosowego na PJWSTK– Projekt ODRA: 2003 – do dzisiaj; pełna implementacja SBQL

• Projekty europejskie (6 PR)– eGov Bus – rozwinięcie języka SBQL jako uniwersalnego

obiektowego języka programowania baz danych, 2006 – 2008– VIDE – inne rozwinięcie SBQL, 2006-2008

• 2 habilitacje, 14 obronionych doktoratów, ~ 50 prac mgr


Główne cechy SBQL

• Obiektowy, zintegrowany język zapytań i programowania.– Formalna semantyka– Unifikacja wyrażeń języka programowania z zapytaniami.– Bazuje na SBA i modelu obiektowym UML.– Mocna kontrola typologiczna.– Prototyp kompilatora zrealizowany w systemie ODRA.– Wyposażony w wiele nowoczesnych udogodnień (klasy, metody,

tranzytywne domknięcia, aktualizowalne perspektywy, itd.)– Interfejsy z popularnych języków programowania (Java, C#, …).– Interfejsy do XML, relacyjnych baz danych, Web Services, …– Wirtualne obiektowe perspektywy jako podstawa integracji

heterogenicznych i rozproszonych baz danych.


Czy formalna semantyka jest potrzebna?

• Większość języków zapytań (SQL, OQL, HQL, Xquery, LINQ,…) nie dba o formalną semantykę. Ale…

• Jeżeli nie ma formalnej semantyki, to nigdy nie będzie właściwego standardu języka.– Każda implementacja będzie inna, patrz np. SQL

• Formalna semantyka umożliwia wnioskowanie o języku– Np. o redundancji pewnych konstrukcji lub braku pełnej

funkcjonalności

• Formalna semantyka jest warunkiem opracowania uniwersalnych metod optymalizacji zapytań– Bez optymalizacji język zapytań jest nieakceptowalny dla

bardzo dużych baz danych.


Podstawy podejścia stosowego (SBA)

• Dla potrzeb formalnej semantyki języka zapytań i programów należy zdefiniować:– Dziedzinę syntaktyczną zapytań i programów Q w postaci

składni abstrakcyjnej– Zbiór wszystkich stanów Stan (bazy danych, ale nie tylko)– Zbiór wszystkich rezultatów zapytań Rezultat

• Dla każdego elementu q z dziedziny Q, należy zdefiniować odwzorowanie go w znaczenie (semantykę)

• Dla zapytań będzie to funkcja |q|: Stan → Rezultat.– Musimy zadbać o modularność, czyli taką definicję, która

pozwoli na budowanie semantyki dowolnie złożonych zapytań poprzez rekurencyjne złożenie semantyk jego komponentów.


SBA: co to jest „stan”?

• Zazwyczaj, pojęcie "stanu" jest utożsamiane ze "stanem bazy danych". Jest to uproszczenie i ograniczenie.– Interesować nas będzie także stan nietrwałych

zmiennych/obiektów używanych przez programy aplikacyjne, procedury, funkcje, metody, itd.

– Całość trwałych i nietrwałych zmiennych/obiektów będziemy nazywać składem obiektów

– Skład zawiera także pewne cechy globalnego środowiska, takie jak czas bieżący, datę, login aktualnego użytkownika, itd.

– Interesować nas będzie także chwilowy stan przetwarzania, który jest odwzorowany w postaci stosu środowisk (ENVS)

• Stan = Stan składu obiektów + Stan stosu środowisk


Po co stos środowisk?

– Jest to jedno z najważniejszych pojęć wszystkich współczesnych języków programowania

• Stos ten jest odpowiedzialny za:– Kontrolowanie zakresów nazw i wiązanie tych nazw;– Przechowywanie wartości lokalnych zmiennych procedur;– Przechowywanie parametrów aktualnych funkcji i procedur;– Przechowywanie śladu powrotu, czyli adresu do którego ma

wrócić sterowania po zakończeniu działania procedury.

• W SBA stos ten ma jeszcze jedną funkcję: umożliwia pełne sformalizowanie tzw. operatorów niealgebraicznych– W SBA operatory selekcji, projekcji/nawigacji, złączenia,

kwantyfikatory, itd. są operatorami niealgebraicznymi– Niemożliwa poprawna formalizacja w ramach dowolnej algebry


Dalsze cechy SBA

• Stos rezultatów zapytań QRES• Formalna semantyka wyrażona w postaci abstrakcyjnej

implementacji (semantyki operacyjnej)– Abstrakcyjna maszyna zdefiniowana w sposób zrozumiały dla

potencjalnego programisty kompilatora

• Dla każdej konstrukcji składniowej maszyna przyporządkowuje akcje na trzech strukturach danych:– Skład obiektów– Stos środowisk – Stos rezultatów

• Ta konstrukcja semantyki wymaga od czytelnika więcej niż algebra relacji. Ale też oferuje pełną uniwersalność.

} Stan


Architektura przetwarzania zapytań i programów

Optymalizator zapytań

Parserzapytanie/program

Abstrakcyjne drzewo składniowe

(AST)Zoptymalizowane

AST

Kompilator dokodu bajtowego

Kod bajtowy

Ewaluator zapytań/programów (maszyna wirtualna)

Kontrola typów

AST po kontroli typów

Skład obiektów

Dynamiczny stos środowisk

ENVS

Dynamiczny stos rezultatów

QRES

metabaza Statyczny stosśrodowiskS_ENVS

Statyczny stosrezultatówS_QRES


Składnia SBQL

• Pełna ortogonalność: wszystko można kombinować ze wszystkim, jeżeli tylko ma to sens i jest zgodne z typami

• Unifikuje wyrażenia języka programow. oraz zapytania– Jak dotąd, unikalna własności wśród wszystkich języków

zapytań zintegrowanych z językami programowania. – 2+2, x*y, sin(x), Pracownik where nazwisko = ”Kowalski”

• Operatory algebraiczne i niealgebraiczne– Wszystkie operatory są unarne lub binarne, – Brak dużych syntaktycznych zlepków a la SQL: select…

from…where…group by…having…order by…

• Procedury, funkcje, metody, perspektywy


Semantyka SBQL

• Zasada kompozycyjności: semantyka konstrukcji złożonej jest funkcją semantyk jej komponentów

• Operatory algebraiczne: nie używają ENVS• Operatory niealgebraiczne: używają ENVS• Semantyka operatorów definicji pomocniczych nazw– Nieobecna w innych formalizacjach – Operator as: q as n - przypisuje nazwę n do wszystkich

elementów zwróconych przez zapytanie q– Operator group as: q group as n – przypisuje nazwę n do

rezultatu zwróconego przez q

• Zapytania mogą być parametrami procedur i metod• Zapytania określają wynik procedur i metod funkcyjnych


Prosty schemat BD a la UML

Student [0..*]rok: integeroceny[0..*]: integerśredniaOcen(): real

Dział [0..*]nazwa: stringlokacja[1..*]: string

Prac[0..*]pensja: realzajęcie: string

zatrudnia[0..*]

pracujeW kieruje[0..1]

szef

uczestniczy[1..*]

maUczestnika[1..20]

prowadzi[1..*]

prowadzonyPrzez

Osoba[0..*]imię: stringnazwisko: stringwiek: integernazwImię(): string

Kurs[0..*]nazwaK: stringtrwa: integer


Przykłady zapytań w SBQL

• Podaj imię i nazwisko szefa Nowaka:(Prac where nazwisko = “Nowak”). pracujeW. Dział. Szef. Prac.

(imię, nazwisko)

• Dla każdego działu podaj średnią średnich ocen studentów kursów prowadzony przez pracowników danego działu:(Dział as d). (d, avg(d. zatrudnia. Prac. prowadzi. Kurs.

maUczestnika. Student. średniaOcen))


Instrukcje imperatywne w SBQL

• Dla każdego nauczyciela starszego niż 45 lat i zarabiającego mniej niż średnia daj podwyżkę do wysokości 10% wyższej niż średnia:for each avg(Prac.pensja) as a join (Prac where zajęcie =

”nauczyciel” and wiek > 45 and pensja < a) do

pensja := a * 1.1;

• Przenieś Nowaka do działu kierowanego przez Walaska i zmień mu stanowisko na inżynier:for Prac where nazwisko = ”Nowak” do {

pracujeW := (Dział where (szef. Prac. nazwisko) = ”Walasek”);

zajęcie := ”inżynier”;

}


Procedury w SBQL

• Procedure Przenieś ma dwa parametry: (1) bag stringów reprezentujących stanowiska i (2) referencję do działu. Procedura przenosi wszystkich pracowników mających stanowisko wymienione w parametrze 1 do działu wyspecyfikowanego w parametrze 2. procedure Przenieś(z: string[0..*]; nowyD: ref TypDział) {

for each (Prac where zajęcie in z) do pracujeW := nowyD; }

Podstawienie na dwukierunkowy pointer pracujeW/zatrudnia.

• Przenieś wszystkich analityków i maklerów do Walaska:Przenieś( bag(“analityk”, “makler”);

Dział where (szef.Prac.nazwisko) = “Walasek”);


Wirtualne aktualizowalne perspektywy

• Są odpowiednikiem perspektyw (views) w SQL, ale:– Bazują na modelu obiektowym, a nie relacyjnym.– Język definiowania perspektyw posiada pełną moc algorytmiczną i

pragmatyczną (której SQL nie posiada).– Mechanizm aktualizacji wirtualnych obiektów jest znacznie

bardziej uniwersalny niż to ma miejsce w SQL.• Daje to podstawę implementacji dowolnych osłon lokalnych źródeł danych,

w tym osłon z możliwością aktualizacji.

– Język definiowania perspektyw może odwoływać się do funkcji protokołu komunikacyjnego.• Perspektywy mogą być użyte do budowy integratora źródeł danych.

– Perspektywy SBQL mają znacznie większy potencjał optymalizacyjny w stosunku do perspektyw SQL.


Co mogą perspektywy w SBQL?

– Perspektywa PracSzef dla wszystkich pracowników zwraca nazwisko pracownika (NazwPrac) i nazwisko szefa (NazwSzefa) jako stringi. Podstawienie na NazwSzefa powoduje przeniesienie pracownika do odpowiedniego działu:

– Przenieś Nowaka do działu Walaska:

(PracSzef where NazwPrac=”Nowak”).NazwSzefa := ”Walasek”;

– Perspektywa DziałŚrPens zwraca nazwę działu (Nazwa) i średnią pensję (ŚrPens) w tym dziale. Podstawienie na średnią pensję powoduje podwyżkę zarobków w tym dziale proporcjonalną do aktualnych zarobków pracowników i do ich oceny.

– Podnieś o 200 średnią pensję w dziale „Lalki”:

for DziałŚrPens where Nazwa = „Lalki” do ŚrPens += 200;


Perspektywa integrująca rozproszone źródła danych

• Używa funkcji protokołu komunikacyjnego.– Załóżmy, ze mamy 3 serwery o adresach Kalisz, Lublin i Kielce

view MoiPracDef { virtual MoiPrac: PracType [0..*]; seed: record{s:ServerType, p: PracType} { return ((Kalisz as s) join (s.Prac as p)) union (((Lublin as s) join (s.Prac as p)) union (((Kielce as s) join (s.Prac as p)) } on_retrieve{ connect (s); return p.(nazwisko, imię, adres, zawód, PZ); }; on_delete do { connect (s); remoteDelete (p) };

//Dalsze części definicji perspektywy …}

Integracja źródeł danych


Architektura integracji heterogenicznych i rozproszonych danych

Istniejące zasoby danych

Osłona 1

Źródło danych 1

Osłona 2

Źródło danych 2

Osłona 3

Źródło danych 3

…per

….applicatio

n

Aplikacja 1 Aplikacja 2 Aplikacje 3

Zunifikowany schemat wirtualnych danych

Zintegrowane wirtualne dane

Zapytania do wirtualnych danych i rezultaty zapytań

Zintegrowane wirtualne dane

Aplikacje

Warstwa komunikacyjna

Warstwa komunikacyjna

Integrator źródeł danych

Procesor języka dostępu do wirtualnych danych

Architektura wirtualnego repozytorium w systemie ODRA


Optymalizacja zapytań

• Wysoki poziom abstrakcji zapytań powoduje, że czas odpowiedzi bez optymalizacji jest nieakceptowalny.– Dla bardzo dużych baz danych nawet proste zapytania mogą

wymagać godzin lub dni na najszybszych komputerach.– Optymalizacja musi skrócić czas odpowiedzi tysiące razy.

• Na szczęście, języki zapytań i ich środowiska zawierają ogromną liczbę możliwości optymalizacyjnych.– Wiele z nich wykorzystuje SQL

• Dzięki formalnej semantyce podejście stosowe doskonale nadaje się do rozwoju metod optymalizacji zapytań.– Jak pokazały testy, znacznie lepiej niż SQL – Brak optymalizacji w OQL, OCL, HQL, LINQ, XQuery,…


Metody optymalizacyjne w SBQL

• Metody oparte na przepisywaniu zapytań:– Wyciąganie niezależnych podzapytań przed operator pętli :

Prac where pensja > ((Prac where nazwisko= ”Nowak”).pensja)– Wyciąganie słabo zależnych podzapytań przed operator pętli– Wyciąganie selekcji przed konstruktor struktur (join)– Usuwanie martwych podzapytań (nie wpływających na wynik)– Usuwanie niepotrzebnych pomocniczych nazw – Traktowanie funkcji jako makrosów (query modification)

• Metody bazujące na zastosowaniu indeksów• Metody bazujące na zapamiętywaniu wyników zapytań• …• Optymalizacje zapytań do rozproszonych BD


System ODRA

• Object Database for Rapid Application development• Główny motyw: nowy paradygmat rozwoju aplikacji

biznesowych opartych na bazie danych– Częściowo motywowany chęcią uporządkowania setek

chaotycznych języków i narzędzi dookoła języka Java i innych– Język SBQL – pełna integracja języka programowania z

językiem zapytań, wysoki poziom abstrakcji programów– Radykalne skrócenie kodu i czasu programowania (~10 razy)

• Jest próbą utworzenia pojedynczego, uniwersalnego, zintegrowanego, spójnego i minimalnego środowiska tworzenia zastosowań biznesowych.

• Ma jeszcze status prototypu (wersja alfa).


Środowisko systemu ODRA

• ODRA składa się z trzech zintegrowanych komponentów:– System zarządzania obiektową bazą danych– Kompilator języka SBQL i wirtualna maszyna SBQL– Interfejsy z/do zewnętrznych technologii

• Instalacja ODRA może pracować jako klient i jako serwer– Możliwe jest tworzenie rozproszonych baz danych

• Zewnętrzne technologie: – Dostęp do relacyjnych baz danych (18 typów RDBMS)– Importer/eksporter plików XML oraz RDF– Dostęp do Web Services, możliwość tworzenia Web Services– Interfejs do programów w Java, interfejs z Java do SBQL– ...


Obecny stan rozwoju SBQL

• ODRA – ciągle rozwijana• SBQL jest hasłem w ogromnej (4 tomy) i prestiżowej

encyklopedii baz danych Springera– Jedyne hasło w tej encyklopedii pochodzące z Polski

• SBQL został zaproponowany jako podstawa rozwoju standardu OMG obiektowych baz danych

• SBQL4J – zintegrowanie języka SBQL z językiem Java– Inspirowane przez C#/LINQ

• SBQL4Workflow – rozwinięcie w kierunku workflow• Loxim – system tworzony na Uniwersytecie Warszawskim • Obecny rozwój: projekt strategiczny SYNAT


Podsumowanie

• SBQL jest pierwszym w historii językiem, który integruje zapytania i programy oraz unifikuje zapytania i wyrażenia.– Całkowity brak niezgodności impedancji– Podobne propozycje: PL/SQL, Transact SQL, C#/LINQ, SQL

1999, SQL2008, … są nią w jakimś stopniu obciążone

• Unikalne cechy SBQL: – Model obiektowy i schemat bliskie UML– Wirtualne aktualizowalne obiektowe perspektywy– Zaawansowane metody optymalizacyjne– Duża kolekcja interfejsów z/do zewnętrznych technologii

• Prowadzone są nadal prace na rozwojem SBQL


Dziękuję za uwagę!

Pytania?

Komentarze?

Documents

Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych [email protected]