Podejście stosowe do obiektowych języków programowania baz danych

Prezentacja na temat: "Podejście stosowe do obiektowych języków programowania baz danych"— Zapis prezentacji:

1 Podejście stosowe do obiektowych języków programowania baz danych
Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych 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 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, 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 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.

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? Stos ten jest odpowiedzialny za:
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), 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

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

16 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..*] szef pracujeW kieruje[0..1] Student [0..*] rok: integer oceny[0..*]: integer średniaOcen(): real Prac[0..*] pensja: real zajęcie: string prowadzi[1..*] uczestniczy[1..*] Kurs[0..*] nazwaK: string trwa: integer maUczestnika[1..20] prowadzonyPrzez

17 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))

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) 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”; }

19 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”);

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

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

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

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

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?