Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

K.Subieta. Założenia projektu SZOBD, Folia 1 czerwiec 2001

Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Instytut Podstaw Informatyki PAN, Warszawa

Nowy projekt w PJWSTK i IPI PAN:System zarządzania obiektową bazą danych


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


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.



• 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 bazo-danowych funkcji. Skrzynia ładunkowa Jelcza, silnika malucha. Brak koncepcji języka zapytań.

• "Pospolite ruszenie": SODA i temu podobne zrywy tzw. "praktyków".



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



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


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.


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.


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


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 bazo-danowych (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ą.



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



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



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


Interfejsy wyższego poziomu

Architektura systemu - dolne warstwy

Fizyczny skład trwałych obiektó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.

Interfejs CRUD dostępu do interpretowanych trwałych obiektów

Interfejs będzie specjalizowany dla poszczególnych kategorii trwałych bytó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 i nietrwałych obiektów

Fizyczny skład nietrwałych obiektów

CRUD - Create, Retrieve, Update, Delete


Utylizacja spadkowych baz danych

Interfejsy wyższego poziomu

Interfejs programistyczny (API) spadkowej bazy danych (np. JDBC)

Osłona (wrapper) specjalizowana dla danej spadkowej bazy danych

Interfejs CRUD dostępu do interpretowanych trwałych i nietrwałych obiektów

Fizyczny skład nietrwałych obiektów

Spadkowa baza danych

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.


Architektura systemu - górne warstwy

Interfejsy CRUD niższego poziomu

Integrator i broker odległych baz danych

Interpreter i optymalizator zapytań/programów

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.

Interfejs będzie zajmował się integracją rozproszonych zasobów danych i usług.

Interfejs będzie zajmował się kompilacją i wykonaniem zapytań/programów

Środowisko tworzenia i modyfikacji zapytań/programów

Środowisko udogodnień (administracja, zapytania i

modyfikacje ad hoc, ...)

Wszystkie programy będą przechowywane w bazie danych (niekoniecznie tej samej, na której operują)


Integracja zasobów rozproszonych

Filozofia podobna do założeń standardu CORBA:

Integrator i broker

odległych baz danych

Miejsce 1

Integrator i broker


Miejsce 2

Integrator i broker


Miejsce 3

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.


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


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.


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.


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.


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.


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.


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


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


Model klasowy bez dynamicznych ról

i40 KlasaOsoba

i41 Wiek (...kod...)

................

i50 KlasaPrac

i51 ZmieńZar (...kod...)

................

i52 ZarNetto (...kod...)

i4 Prac

i5 Nazwisko ”Nowak”

i7 Zar 2500

i8 PracujeW

i6 RokUr 1944

i127

i1 Osoba

i2 Nazwisko ”Wilski”

i3 RokUr 1950

i128

i9 Prac

i10 Nazwisko ”Kowalski”

i12 Zar 2000

i13 PracujeW

i11 RokUr 1940

Skomplikowane reguły wiązania nazw.Brak "czystości" referencyjnej.

Klasyczny, stosowanyw większości systemów


Model z dynamicznymi rolami

i1 OSOBA

i2 Nazwisko ”Wilski”

i3 RokUr 1950

i40 KlasaOsoba

i41 Wiek (...kod...)

.............

i50 KlasaPrac

i51 ZmieńZar (...kod...)

................

i52 ZarNetto (...kod...)

i13 PRAC

i14 Zar 2500

i15 PracujeW

i127

i4 OSOBA

i5 Nazwisko ”Nowak”

i6 RokUr 1944

i60 KlasaStudent

i61 ŚredniaOcen (...kod...)

................

i7 OSOBA

i8 Nazwisko ”Kowalski”

i9 RokUr 1940

i128

i16 PRAC

i17 Zar 2000

i18 PracujeW

i19 STUDENT

i20 NrIndeksu 76943

i21 Wydział ”fizyka”

Proste wiązanie nazw.Czystość referencyjna.Brak anomalii wielo-dziedziczenia.


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.


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


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?

Documents

Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa