Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych subieta@pjwstk.pl

1. Podejście stosowe do obiektowych języków programowania baz danych Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych subieta@pjwstk.edu.pl http://www.ipipan.waw.pl/~subieta http://www.sbql.pl Wykład 01 Wprowadzenie do SBA i SBQL

2. 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

3. 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

4. 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.

5. 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

6. 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

7. 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.

8. 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.

9. Podstawy podejścia stosowego (SBA) • Dla potrzeb formalnej semantyki języka zapytań i programów należy zdefiniować: • Dziedzinę syntaktyczną zapytań i programów Qw postaci składni abstrakcyjnej • Zbiór wszystkich stanówStan (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.

10. 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

11. 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

12. 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

13. Architektura przetwarzania zapytań i programów Abstrakcyjne drzewo składniowe (AST) zapytanie/ program Parser 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 Dynamiczny stos środowisk ENVS Dynamiczny stos rezultatów QRES

14. 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), Pracownikwherenazwisko = ”Kowalski” • Operatory algebraiczne i niealgebraiczne • Wszystkie operatory są unarne lub binarne, • Brak dużych syntaktycznych zlepków a la SQL: select…from…where…groupby…having…order by… • Procedury, funkcje, metody, perspektywy

15. 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: qasn - przypisuje nazwę n do wszystkich elementów zwróconych przez zapytanie q • Operator group as: qgroup asn – przypisuje nazwę n do rezultatu zwróconego przez q • Zapytania mogą być parametrami procedur i metod • Zapytania określają wynik procedur i metod funkcyjnych

16. Prosty schemat BD a la UML Dział[0..*] nazwa: string lokacja[1..*]:string Osoba[0..*] imię: string nazwisko: string wiek: integer nazwImię(): string Prac[0..*] pensja: real zajęcie:string zatrudnia[0..*] szef pracujeW kieruje[0..1] Student [0..*] rok: integer oceny[0..*]: integer średniaOcen(): real Kurs[0..*] nazwaK: string trwa: integer prowadzi[1..*] uczestniczy[1..*] maUczestnika[1..20] prowadzonyPrzez

17. Przykłady zapytań w SBQL • Podaj imię i nazwisko szefa Nowaka: (Prac wherenazwisko = “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ł asd).(d, avg(d. zatrudnia. Prac. prowadzi. Kurs.maUczestnika.Student.średniaOcen))

18. 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) asajoin(Prac wherezajęcie = ”nauczyciel” andwiek > 45 andpensja < a) do pensja := a * 1.1; • Przenieś Nowaka do działu kierowanego przez Walaska i zmień mu stanowisko na inżynier: for Pracwherenazwisko = ”Nowak” do { pracujeW := (Działwhere (szef. Prac. nazwisko) = ”Walasek”); zajęcie := ”inżynier”; }

19. Procedury w SBQL • ProcedurePrzenieśma dwa parametry: (1) bag stringówreprezentujących stanowiskai (2)referencję dodziału. Proceduraprzenosi wszystkich pracowników mających stanowisko wymienione w parametrze 1 do działu wyspecyfikowanego w parametrze 2. procedurePrzenieś(z: string[0..*]; nowyD: refTypDział) { for each (Prac wherezajęcie inz) dopracujeW:= 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”);

20. 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.

21. Co mogą perspektywy w SBQL? • Perspektywa PracSzef dla wszystkich pracowników zwraca nazwisko pracownika (NazwPrac) i nazwisko szefa (NazwSzefa) jako stringi. Podstawienie na NazwSzefapowoduje przeniesienie pracownika do odpowiedniego działu: • Przenieś Nowaka do działu Walaska: (PracSzefwhereNazwPrac=”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”: forDziałŚrPenswhereNazwa = „Lalki” doŚrPens += 200;

22. 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 viewMoiPracDef { virtual MoiPrac: PracType[0..*]; seed: record{s:ServerType, p: PracType} { return((Kaliszas s)join(s.Pracas p)) union (((Lublin as s)join (s.Pracas p))union (((Kielceas s)join (s.Pracas p)) } on_retrieve{ connect (s); returnp.(nazwisko, imię, adres, zawód, PZ); }; on_delete do { connect (s); remoteDelete (p) }; //Dalsze części definicji perspektywy … } Integracja źródeł danych

23. Architektura integracji heterogenicznych i rozproszonych danych Aplikacje Aplikacja 1 Aplikacja 2 Aplikacje 3 Warstwa komunikacyjna Zapytania do wirtualnych danych i rezultaty zapytań Architektura wirtualnego repozytorium w systemie ODRA Procesor języka dostępu do wirtualnych danych Zintegrowane wirtualne dane Zintegrowane wirtualne dane Integrator źródeł danych Warstwa komunikacyjna Zunifikowany schemat wirtualnych danych Osłona 1 Osłona 2 Osłona 3 …per Istniejące zasoby danych Źródło danych 1 • Źródło danych 2 • Źródło danych 3 …. application

24. 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,…

25. Metody optymalizacyjne w SBQL • Metody oparte na przepisywaniu zapytań: • Wyciąganie niezależnych podzapytań przed operator pętli : Pracwherepensja > ((Pracwherenazwisko= ”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 (querymodification) • Metody bazujące na zastosowaniu indeksów • Metody bazujące na zapamiętywaniu wyników zapytań • … • Optymalizacje zapytań do rozproszonych BD

26. System ODRA • ObjectDatabase for RapidApplication 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).

27. Ś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 • ...

28. 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

29. 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

30. Dziękuję za uwagę! Pytania? Komentarze?