Transcript
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
