Podei*cie stosowe

Podejście stosowe do obiektowych języków
programowania baz danych
http://www.sbql.pl
Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych
[email protected]
http://www.ipipan.waw.pl/~subieta
K.Subieta: Podejście stosowe
Wykład 01
Wprowadzenie do
SBA i SBQL
1/30
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
K.Subieta: Podejście stosowe
2/30
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
K.Subieta: Podejście stosowe
3/30
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.
K.Subieta: Podejście stosowe
4/30
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
K.Subieta: Podejście stosowe
5/30
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
K.Subieta: Podejście stosowe
6/30
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.
K.Subieta: Podejście stosowe
7/30
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.
K.Subieta: Podejście stosowe
8/30
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.
K.Subieta: Podejście stosowe
9/30
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
K.Subieta: Podejście stosowe
10/30
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
K.Subieta: Podejście stosowe
11/30
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
}Stan
• Ta konstrukcja semantyki wymaga od czytelnika więcej
niż algebra relacji. Ale też oferuje pełną uniwersalność.
K.Subieta: Podejście stosowe
12/30
Architektura przetwarzania zapytań i
programów
zapytanie/
program
Parser
Abstrakcyjne
drzewo składniowe
(AST)
AST po
kontroli typów
Zoptymalizowane
AST
Kontrola
typów
Optymalizator
zapytań
Kompilator do
kodu bajtowego
metabaza
Statyczny stos
środowisk
S_ENVS
Statyczny stos
rezultatów
S_QRES
Kod bajtowy
Ewaluator zapytań/programów (maszyna wirtualna)
Skład
obiektów
K.Subieta: Podejście stosowe
Dynamiczny
stos środowisk
ENVS
Dynamiczny
stos rezultatów
QRES
13/30
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
K.Subieta: Podejście stosowe
14/30
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
K.Subieta: Podejście stosowe
15/30
Prosty schemat BD a la UML
Osoba[0..*]
imię: string
nazwisko: string
wiek: integer
nazwImię(): string
Dział [0..*]
nazwa: string
lokacja[1..*]: string
zatrudnia[0..*]
pracujeW
Student [0..*]
rok: integer
oceny[0..*]: integer
średniaOcen(): real
szef
kieruje[0..1]
Prac[0..*]
pensja: real
zajęcie: string
prowadzi[1..*]
uczestniczy[1..*]
Kurs[0..*]
nazwaK: string
maUczestnika[1..20] trwa: integer
prowadzonyPrzez
K.Subieta: Podejście stosowe
16/30
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))
K.Subieta: Podejście stosowe
17/30
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”;
}
K.Subieta: Podejście stosowe
18/30
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”);
K.Subieta: Podejście stosowe
19/30
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.
K.Subieta: Podejście stosowe
20/30
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;
K.Subieta: Podejście stosowe
21/30
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
Integracja źródeł danych
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
…
}
K.Subieta: Podejście stosowe
22/30
Architektura integracji heterogenicznych
i rozproszonych danych
Aplikacje
Aplikacja 1
Aplikacja 2
Aplikacje 3
Warstwa komunikacyjna
Zapytania do
wirtualnych danych i
rezultaty zapytań
Procesor języka dostępu do
wirtualnych danych
Architektura
wirtualnego
repozytorium
w systemie
ODRA
Zintegrowane wirtualne
dane
Integrator źródeł danych
Warstwa komunikacyjna
Zunifikowany schemat
wirtualnych danych
Istniejące
zasoby
danych
K.Subieta: Podejście stosowe
Osłona 1
Osłona 2
Źródło
danych 1
Źródło
danych 2
Osłona 3
Źródło
danych 3
…per
….
applicatio
n
23/30
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,…
K.Subieta: Podejście stosowe
24/30
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
K.Subieta: Podejście stosowe
25/30
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).
K.Subieta: Podejście stosowe
26/30
Ś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
...
K.Subieta: Podejście stosowe
27/30
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
K.Subieta: Podejście stosowe
28/30
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
K.Subieta: Podejście stosowe
29/30
Dziękuję za uwagę!
Pytania?
Komentarze?
K.Subieta: Podejście stosowe
30/30