Zalozenia projektu SZOBD - Instytut Podstaw Informatyki PAN

Nowy projekt w PJWSTK i IPI PAN:
System zarządzania obiektową bazą danych
Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
Instytut Podstaw Informatyki PAN,
Warszawa
K.Subieta. Założenia projektu SZOBD, Folia 1
czerwiec 2001
Motywacje
• Stworzenie poligonu badawczego, podstawy publikacji
naukowych dla uczestników projektu
• Samo-kształcenie i nauczanie: zrozumienie zasad
projektowania i konstrukcji SZOBD
• Prace doktorskie i prace magisterskie
• Podjęcie wyzwania technologicznego, pokazanie światu
potencjalnego kierunku rozwoju SZOBD
• Cele komercyjne (mniej ważne): w dalszym etapie
zastosowania komercyjne stworzonego prototypu
K.Subieta. Założenia projektu SZOBD, Folia 2
czerwiec 2001
Stan obecny w zakresie SZOBD (1)
• Systemy tzw. "czysto-obiektowe": rozczarowują niskim
poziomem interfejsów do tworzenia aplikacji, nie są
wyposażane w atrakcyjne cechy takie jak języki zapytań,
perspektywy, zapamiętane procedury i metody, itd.
Pseudo-standard ODMG rozczarowuje niespójnościami i
wadami koncepcji; prawdopodobnie jest już martwy.
• Systemy tzw. "obiektowo-relacyjne": rozczarowują
molochowatością i eklektyzmem - zmieszaniem różnych
mało kompatybilnych paradygmatów. Pseudo-standard
ANSI SQL3: nieprawdopodobne monstrum, zmarł pod
własnym ciężarem.
K.Subieta. Założenia projektu SZOBD, Folia 3
czerwiec 2001
Stan obecny w zakresie SZOBD (2)
• Standard SQL 1999 (SQL 2000) - kontynuacja standardu
SQL3, ma wszelkie szanse podzielić jego los.
• XML, czyli jak W3C próbuje zbudować dziedzinę baz
danych od nowa opierając się na banalnej koncepcji
składniowej. Frustrujące podejście "bottom-up".
• PJama i inne poronione koncepcje dodania cechy
trwałości do języka Java.
• JDO, czyli jak przystosować język Java do bazodanowych funkcji. Skrzynia ładunkowa Jelcza, silnika
malucha. Brak koncepcji języka zapytań.
• "Pospolite ruszenie": SODA i temu podobne zrywy tzw.
"praktyków".
K.Subieta. Założenia projektu SZOBD, Folia 4
czerwiec 2001
Stan obecny w zakresie SZOBD (3)
• Świat baz danych zrobił się eklektyczny i dekadencki:
brak jednorodnych, spójnych i uniwersalnych koncepcji,
próby dopasowania systemów do wielu popularnych
technologii, języków, koncepcji i buzzword-ów.
Owocuje to monstrualnością rozwiązań.
• Obiektowość w bazach danych zbyt małą wagę
przywiązuje do języków zapytań, źródła sukcesu
relacyjnych baz danych.
• Technologie XML w zakresie baz danych są naiwne.
• Java jako paradygmat budowy baz danych jest "drugą
pomyłką ludzkości" (pierwszą był C++, B. Meyer).
K.Subieta. Założenia projektu SZOBD, Folia 5
czerwiec 2001
Stan obecny w zakresie SZOBD (4)
• Frustrująca cechą obecnych podejść do obiektowych baz
danych jest przyjmowanie założenia, że aplikacje
działające na takich bazach danych muszą być
programowane w obecnie popularnych obiektowych
językach programowania, takich jak C++, Java i
(rzadziej) Smalltalk.
• Ponieważ te języki są silnie przywiązane do własnych
struktur fizycznych, to natychmiast rodzi zarzut, że
obiektowe bazy danych są krokiem w tył w stosunku do
relacyjnych, ponieważ nie spełniają wymogu
konceptualizacji danych i zmuszają do programowania
na niskim poziomie, znacznie niższym niż poziom SQL.
K.Subieta. Założenia projektu SZOBD, Folia 6
czerwiec 2001
Stan teorii w zakresie SZOBD
• Kontynuacja i rozszerzanie paradygmatów modelu
relacyjnego, takich jak algebra relacji i rachunek
relacyjny.
• Ułomność koncepcji, ograniczenia funkcjonalności,
poważne wady formalne tworów określanych jako
"obiektowe algebry".
• Nowe koncepcje takie jak komprehensje i rachunek
monoidów - w istocie są to koncepcje składniowe, bez
istotnej semantyki.
• Obecnie jedyną sensowną i uniwersalną koncepcją
teoretyczną jest podejście stosowe (SBA). Jedynym
sposobem propagacji tej koncepcji jest budowa systemu.
K.Subieta. Założenia projektu SZOBD, Folia 7
czerwiec 2001
Nasze aktywa
• SBA jest zaproponowane przeze mnie i rozwijane w
zespołach, którymi kierowałem lub kieruję. Biorąc pod
uwagę teoretyczne buble produkowane przez inne
zespoły badawcze, SBA tworzy szansę, której nie
powinniśmy zmarnować.
• SBA ma zaszłości implementacyjne w postaci prototypu
Loqis. Wiele rozwiązań tego systemu można przenieść i
uogólnić w nowym systemie.
• Praca doktorska Jacka Płodzienia posuwa do przodu
ważny aspekt tego podejścia - optymalizację zapytań.
• Dalsze prace doktorskie i magisterskie jako motywacja.
K.Subieta. Założenia projektu SZOBD, Folia 8
czerwiec 2001
Nasze pasywa
• Pieniądze: nie należy się spodziewać, szczególnie w
pierwszym okresie rozwoju projektu. To zmniejsza
motywacje potencjalnych uczestników projektu. W
dalszym etapie można się starać o granty KBN lub UE.
• Programowanie: słabo rozpoznane środowiska
implementacyjne, brak większych doświadczeń w
zakresie programowania. Ale właśnie z tego powodu ten
projekt ma sens.
• Kadry: najtrudniejszy będzie etap początkowy, w
którym należy zbudować fundamenty systemu, gdyż tej
pracy nie da się zrównoleglić.
K.Subieta. Założenia projektu SZOBD, Folia 9
czerwiec 2001
Podstawowe założenia projektu (1)
• Odrzucenie wszelkich pozostałości modelu relacyjnego.
• Zerwanie z eklektyzmem i wszystkoizmem, zbudowanie
uniwersalnego SZOBD na bazie jednorodnej koncepcji i
jednorodnego języka zapytań/programowania
obejmujących wszystkie aspekty i moduły SZOBD.
• Tylko jeden język (SBQL++) będący jednocześnie
językiem zapytań, wyrażeń, konstrukcji imperatywnych,
oraz wszelkich abstrakcji programistycznych i bazodanowych (procedury, metody, perspektywy, itd.).
Zapytania/programy w tym języku będą kompilowane
do kodu pośredniego, następnie interpretowane przez
własną maszynę wirtualną.
K.Subieta. Założenia projektu SZOBD, Folia 10
czerwiec 2001
Podstawowe założenia projektu (2)
• Zachowanie wszystkich ideałów obiektowości, takich
jak: ortogonalna trwałość, wysoki poziom abstrakcji
danych i dostępu do danych, dowolnie złożone obiekty,
relatywizm obiektów, pełna wewnętrzna identyfikacja
obiektów.
• Jednorodne traktowanie danych indywidualnych i
masowych, pełna ortogonalność konstruktorów danych.
• Zachowanie wszystkich pojęć obiektowości takich jak:
klasy i dziedziczenie, metody (pamiętane po stronie bazy
danych), hermetyzacja, polimorfizm, związki
asocjacyjne, interfejsy.
K.Subieta. Założenia projektu SZOBD, Folia 11
czerwiec 2001
Podstawowe założenia projektu (3)
• Optymalizacja zapytań na bazie reguł przepisywania,
indeksów, analizy modeli kosztu, itd.
• Zachowanie wszystkich niezbędnych cech systemów baz
danych, takich jak: transakcje, wielodostęp, ochrona
dostępu, buforowanie, rozproszenie zasobów.
• Interfejs nasłuchowy na bazie protokołów internetowych
(TCP/IP, HTTP, IIOP) umożliwiający przezroczystą
integrację zasobów rozproszonych.
• Umożliwienie podłączenia spadkowych aplikacji
poprzez broker działający na poziomie podobnym do
poziomu ORB-ów CORBA, ale (w odróżnieniu) z
zachowanie wszelkich cech bazo-danowych.
K.Subieta. Założenia projektu SZOBD, Folia 12
czerwiec 2001
Podstawowe założenia projektu (4)
• Wydajność systemu oraz konsumpcja zasobów pamięci
nie będą priorytetami przy konstrukcji systemu. Liczyć
się będzie zredukowanie dystansu pomiędzy modelem
pojęciowym a modelem implementacyjnym.
• Staranne zaprojektowanie metamodelu i katalogów
systemu, umożliwiające m.in. optymalizacje i
generyczność aplikacji poprzez refleksję.
• Statyczna i dynamiczna kontrola typologiczna
poprawności programów i danych, na tyle elastyczna, aby
nie zmniejszać uniwersalności systemu. Nie mam na
myśli polimorficznych systemów typów a la ML.
K.Subieta. Założenia projektu SZOBD, Folia 13
czerwiec 2001
Architektura systemu - dolne warstwy
CRUD - Create, Retrieve, Update, Delete
Interfejsy wyższego poziomu
Interfejs CRUD dostępu do interpretowanych
trwałych i nietrwałych obiektów
Fizyczny skład
nietrwałych obiektów
Interfejs CRUD transakcyjnego dostępu do
interpretowanych trwałych obiektów
Interfejs będzie zajmował się sesjami,
lokalnymi transakcjami i ochroną danych
Interfejs CRUD dostępu do interpretowanych
trwałych obiektów
Interfejs będzie specjalizowany dla
poszczególnych kategorii trwałych bytów
Interfejs CRUD dostępu do nie-interpretowanych
trwałych obiektów (BLOB-ów)
Dowolny trwały byt programistyczny
czasu wykonania (obiekt, klasa,
procedura, sesja, dziennik, transakcja,
perspektywa, indeks, pozycja katalogu,
okno, itd.) będzie zapamiętany i dostępny
w identyczny sposób.
Fizyczny skład trwałych obiektów
K.Subieta. Założenia projektu SZOBD, Folia 14
czerwiec 2001
Utylizacja spadkowych baz danych
Interfejsy wyższego poziomu
Interfejs CRUD dostępu do interpretowanych
trwałych i nietrwałych obiektów
Osłona (wrapper) specjalizowana dla danej
spadkowej bazy danych
Interfejs programistyczny (API) spadkowej bazy
danych (np. JDBC)
Spadkowa baza danych
K.Subieta. Założenia projektu SZOBD, Folia 15
Fizyczny skład
nietrwałych obiektów
Istotne jest przyjęcie założenia, że
spadkowe bazy danych będą
dostępne na poziomie interfejsu
CRUD, a nie np. SQL. Może to
mieć konsekwencje dla wydajności,
ale uwalnia od konieczności
translacji języka wysokiego
poziomu np. SBQL na SQL.
czerwiec 2001
Architektura systemu - górne warstwy
Zarządzanie sesjami użytkowników,
transakcje globalne
Interfejs będzie zajmował się
tworzeniem i zamykaniem sesji,
transakcjami globalnymi, rejestracją
użytkowników, ochroną danych i usług.
Środowisko udogodnień
(administracja, zapytania i
modyfikacje ad hoc, ...)
Środowisko tworzenia i
modyfikacji zapytań/programów
Integrator i broker odległych baz danych
Interpreter i optymalizator
zapytań/programów
Wszystkie programy będą przechowywane
w bazie danych (niekoniecznie tej samej, na
której operują)
Interfejs będzie zajmował się
integracją rozproszonych zasobów
danych i usług.
Interfejs będzie zajmował się kompilacją
i wykonaniem zapytań/programów
Interfejsy CRUD niższego poziomu
K.Subieta. Założenia projektu SZOBD, Folia 16
czerwiec 2001
Integracja zasobów rozproszonych
Filozofia podobna do założeń standardu CORBA:
Miejsce 1
Miejsce 2
Miejsce 3
Integrator i
broker
odległych baz
danych
Integrator i
broker
odległych baz
danych
Integrator i
broker
odległych baz
danych
Architektura może być określona jako multi-klient/multi-serwer.
Koncepcja nie dzieli aplikacji/miejsc na klientów i serwery.
Różnica z CORBA będzie polegać na tym, że zintegrowane zasoby
będą przetwarzane we własnym języku zapytań/programowania.
K.Subieta. Założenia projektu SZOBD, Folia 17
czerwiec 2001
Programowanie aplikacji w Java, C++,...?
• Nie ma takiego założenia. To jest właśnie przyczyna
molochowatości systemów, a koncepcyjna prostota może
być naszym jedynym atutem.
• Na pewnym etapie można zrobić interfejs pozwalający z
naszego języka wołać kod napisany w innych językach.
Nigdy odwrotnie.
• Loqis ma udogodnienie pozwalające na wywołanie
procedury napisanej w innym języku, przechowywanej w
dynamicznej bibliotece (.dll). Udogodnienie przechwytuje parametry
ze stosu Loqisa, uruchamia procedurę i wkłada jej wynik na stos Loqisa.
• Procedura nie ma dostępu do bazy danych, musi on być
zorganizowany w języku wywołującym procedurę.
K.Subieta. Założenia projektu SZOBD, Folia 18
czerwiec 2001
Integracja z Web
• Problem nie wygląda na skomplikowany.
• Programy odwzorowujące a la XSL(T), pozwalające
odwzorować XML na obiekty bazy danych oraz
wyprodukować z bazy danych XML lub HTML, będzie
można zaprogramować w języku zapytań/programowania.
• Potrzebny będzie dość prosty interfejs skryptowy (API)
pozwalający na wywołanie tych programów.
• Tworzenie dynamicznych stron Web będzie polegało na
napisaniu tych programów odwzorowujących oraz
wywołaniu ich przy pomocy skryptów zanurzonych w
HTML, Java, Perlu, PHP lub innym tego rodzaju języku.
K.Subieta. Założenia projektu SZOBD, Folia 19
czerwiec 2001
Technologie Implementacyjne
• Przyjmujemy, że wszystko będzie napisane od nowa w
wybranym języku (przypuszczalnie Java). Nie
zakładamy budowy tego systemu na wierzchołku innego
systemu, np. na relacyjnej lub obiektowej bazie danych.
• NT raczej niż Linux. Na pewno nie Unix.
• Problemem są warstwy dolnego poziomu i buforowanie.
Można byłoby rozejrzeć się za jakąś dobrą stertą (heap)
z GC, do przechowywania "gumowych" blobów.
• Interfejsy graficzne: można wykorzystać standardowy
interfejs Windows, interfejs "przeglądarkowy" (np. IE),
Visual Basic, lub inny pakiet ze standardowymi
widżetami.
K.Subieta. Założenia projektu SZOBD, Folia 20
czerwiec 2001
Model obiektowy (1)
• Dowolnie złożone obiekty, dynamicznie rozszerzalne,
brak stałego formatu obiektów. Moduły, sesje,
transakcje, procedury, funkcje,... są także obiektami.
• Pełny relatywizm obiektów: każdy podobiekt (atrybut)
jest też obiektem.
• Totalna wewnętrzna identyfikacja: każdy obiekt lub
podobiekt ma (nieczytelny) wewnętrzny identyfikator,
który może być trwały.
• Związki referencyjne pomiędzy obiektami; integralność
referencyjna podtrzymywana systemowo.
• Związki referencyjne i metody są także obiektami i
posiadają wewnętrzne identyfikatory.
K.Subieta. Założenia projektu SZOBD, Folia 21
czerwiec 2001
Model obiektowy (2)
• Obiekty mają unikalne "zewnętrzne" nazwy pierwszej
kategorii programistycznej.
• Ortogonalna trwałość: obiekty trwałe i nietrwałe są
przetwarzane przy pomocy dokładnie tych samych
środków. Cecha trwałości jest tylko "flagą" zawieszoną
na obiekcie. Żadnych "persistence capable classes"!
• Kolekcje: obiekty posiadające podobiekty. Będą
rozróżniane: "wielozbiory", "sekwencje" i "opcje"
(modelowanie wartości NULL). Brak pojęcia ekstensji.
• Metody, trygery, ograniczenia, będą mogły być
własnościami obiektów, tak samo jak atrybuty i związki
referencyjne. Trwałe wątki - koncepcja do rozważenia.
K.Subieta. Założenia projektu SZOBD, Folia 22
czerwiec 2001
Model obiektowy (3)
• Klasy: pierwszej kategorii, przechowują inwarianty
obiektów, w tym metody, atrybuty, typy, ograniczenia.
Przechowywane w bazie danych.
• Hierarchia dziedziczenia, wielokrotne dziedziczenie.
• Dynamiczne role - alternatywa dla wielokrotnych
interfejsów i zasady zamienialności (LSP).
• Polimorfizm metod, przesłanianie.
• Kontrola typologiczna - bardzo ostrożna i sterowana,
możliwości typów polimorficznych, ale bez
ortodoksyjnych ograniczeń. Typy (poza wyjątkami) będą
traktowane wyłącznie jako dodatkowe ograniczenie
budowy obiektu oraz sposobu ich użycia.
K.Subieta. Założenia projektu SZOBD, Folia 23
czerwiec 2001
Model obiektowy (4)
• Typy atomowe: int, real, string, boolean, ....
• Metody - pisane wyłącznie w dedykowanym języku
zapytań programowania.
• Brak metod i atrybutów "klasowych". Jeżeli pojawi się
taka konieczność, to należy wstawić metody bezpośrednio
do kolekcji lub utworzyć nową klasę dla kolekcji.
• Wynik zwracany przez zapytania: kombinacja wartości,
nazw i referencji do obiektów.
• Procedury bazy danych, perspektywy (aktualizowalne),
trygery (pojęcie "zdarzenia", rejestracja i obsługa zdarzeń).
K.Subieta. Założenia projektu SZOBD, Folia 24
czerwiec 2001
Model obiektowy (5)
• Hermetyzacja "ortogonalna" - dowolna cecha obiektu
lub klasy może być "publiczna" lub "prywatna".
• Listy eksportowe czyli interfejsy.
• Listy importowe (pasywnych i aktywnych efektów
ubocznych).
• Katalogi: standardowa budowa i dostęp poprzez język
zapytań; umożliwienie programowania z refleksją.
• Abstrakcyjne typy danych: synonim klasy.
• Zdarzenia - specjalne "fruwajace" obiekty środowiska
programistycznego i bazy danych, wyłapywane przez
"zjadaczy zdarzeń".
K.Subieta. Założenia projektu SZOBD, Folia 25
czerwiec 2001
Model klasowy bez dynamicznych ról
i40 KlasaOsoba
i41 Wiek (...kod...)
................
i1 Osoba
Klasyczny, stosowany
w większości systemów
i2 Nazwisko ”Wilski”
i3 RokUr 1950
i50 KlasaPrac
i51 ZmieńZar (...kod...)
i52 ZarNetto (...kod...)
................
i4 Prac
i9 Prac
i5 Nazwisko ”Nowak”
i10 Nazwisko ”Kowalski”
i6 RokUr 1944
i11 RokUr 1940
i7 Zar 2500
i12 Zar 2000
i8 PracujeW
i13 PracujeW
i127
K.Subieta. Założenia projektu SZOBD, Folia 26
Skomplikowane reguły
wiązania nazw.
Brak "czystości" referencyjnej.
i128
czerwiec 2001
Model z dynamicznymi rolami
i40 KlasaOsoba
i41 Wiek (...kod...)
Proste wiązanie nazw.
Czystość referencyjna.
Brak anomalii wielo-dziedziczenia.
.............
i1 OSOBA
i60 KlasaStudent
i2 Nazwisko ”Wilski”
i61 ŚredniaOcen (...kod...)
i3 RokUr 1950
................
i50 KlasaPrac
i51 ZmieńZar (...kod...)
i52 ZarNetto (...kod...)
................
i4 OSOBA
i7 OSOBA
i5 Nazwisko ”Nowak”
i8 Nazwisko ”Kowalski”
i6 RokUr 1944
i9 RokUr 1940
i13 PRAC
i16 PRAC
i14 Zar 2500
i17 Zar 2000
i19 STUDENT
i20 NrIndeksu 76943
i21 Wydział ”fizyka”
i18 PracujeW
i15 PracujeW
i127
K.Subieta. Założenia projektu SZOBD, Folia 27
i128
czerwiec 2001
Język zapytań/programowania
• SBQL - Stack Based Query Language
• Semantyka oparta na koncepcji stosu środowiskowego
• Operatory niealgebraiczne: where, . , zależne złączenie,
kwantyfikatory, uporządkowanie, tranzytywne
domknięcia.
• Operatory algebraiczne: +, -, *, /, =, <, union, .....
• Klasy, dziedziczenie, hermetyzacja, polimorfizm.
• Konstrukcje imperatywne bazujące na zapytaniach.
• Perspektywy, procedury, metody (pełna rekurencja),
trygery, parametry w postaci zapytań, wynik jako
zapytanie, macro-call-by-value, macro-call-by-reference.
K.Subieta. Założenia projektu SZOBD, Folia 28
czerwiec 2001
Rezultaty zwracane przez zapytania
Atomowe:
25
"Kowalski"
i11
true
Złożone:
struct{i1, i56} bag{i1, i56} sequence{i1, i56}
option{i1}
option{}
bag{ struct{i1, i56}, struct{i6, i72}, struct{i11, i72}}
bag{struct{n("Kowalski"), Zarobek(2500), d(i56)}}
bag{struct{ Dział(i56),
Prac( bag{ struct{ n("Nowak"), s(i9 ) },
struct{ n("Stec" ), s(i14) }})}
K.Subieta. Założenia projektu SZOBD, Folia 29
czerwiec 2001
Podsumowanie
• Nie jest pewne, czy obecny czas i sytuacja w Polsce
sprzyja, ale jedyną szansą na zaistnienie zespołu
naukowego na szerszym forum jest zbudowanie nowego
systemu o ciekawych, niespotykanych własnościach.
Tworzenie 51-szego systemu obiektowego o znanych
własnościach ma mały sens i jest nieinteresujące.
• System taki można zbudować na bazie SBA.
• Atutem takiego systemu może być maksymalna
koncepcyjna jednorodność i uniwersalność. Przepowiadam
rychły zmierzch "epoki eklektycznej", symptomami tej
przepowiedni są trupy SQL3 i ODMG.
• Czy wystarczy nam wytrwałości?
K.Subieta. Założenia projektu SZOBD, Folia 30
czerwiec 2001