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

1. Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa Nowy projekt w PJWSTK i IPI PAN: System zarządzania obiektową bazą danych

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

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

4. 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 bazo-danowych funkcji. Skrzynia ładunkowa Jelcza, silnika malucha. Brak koncepcji języka zapytań. • "Pospolite ruszenie": SODA i temu podobne zrywy tzw. "praktyków".

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

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

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

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

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

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

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

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

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

14. Architektura systemu - dolne warstwy CRUD - Create, Retrieve, Update, Delete Interfejsy wyższego poziomu Fizyczny skład nietrwałych obiektów Interfejs CRUD dostępu do interpretowanych trwałych i 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

15. Utylizacja spadkowych baz danych Interfejsy wyższego poziomu Fizyczny skład nietrwałych obiektów Interfejs CRUD dostępu do interpretowanych trwałych i nietrwałych obiektów Osłona (wrapper) specjalizowana dla danej spadkowej bazy 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. Interfejs programistyczny (API) spadkowej bazy danych (np. JDBC) Spadkowa baza danych

16. Architektura systemu - górne warstwy Interfejs będzie zajmował się tworzeniem i zamykaniem sesji, transakcjami globalnymi, rejestracją użytkowników, ochroną danych i usług. Zarządzanie sesjami użytkowników, transakcje globalne Środowisko udogodnień (administracja, zapytania i modyfikacje ad hoc, ...) Wszystkie programy będą przechowywane w bazie danych (niekoniecznie tej samej, na której operują) Środowisko tworzenia i modyfikacji zapytań/programów Interfejs będzie zajmował się integracją rozproszonych zasobów danych i usług. Integrator i broker odległych baz danych Interfejs będzie zajmował się kompilacją i wykonaniem zapytań/programów Interpreter i optymalizator zapytań/programów Interfejsy CRUD niższego poziomu

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

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

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

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

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

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

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

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

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

26. Model klasowy bez dynamicznych ról i1Osoba i2 Nazwisko”Wilski” i3 RokUr 1950 i4Prac i9Prac i5 Nazwisko ”Nowak” i10 Nazwisko ”Kowalski” i6 RokUr 1944 i11 RokUr1940 i7 Zar2500 i12 Zar 2000 i8 PracujeW i13 PracujeW i127 i128 i40KlasaOsoba i41 Wiek (...kod...) ................ Klasyczny, stosowany w większości systemów i50KlasaPrac i51 ZmieńZar (...kod...) i52 ZarNetto (...kod...) ................ Skomplikowane reguły wiązania nazw. Brak "czystości" referencyjnej.

27. Model z dynamicznymi rolami Proste wiązanie nazw. Czystość referencyjna. Brak anomalii wielo-dziedziczenia. i40KlasaOsoba i41 Wiek (...kod...) ............. i1OSOBA i60KlasaStudent i2 Nazwisko”Wilski” i61 ŚredniaOcen (...kod...) i3 RokUr 1950 ................ i50KlasaPrac i51 ZmieńZar (...kod...) i52 ZarNetto (...kod...) ................ i4OSOBA i7OSOBA i5 Nazwisko ”Nowak” i8 Nazwisko ”Kowalski” i6 RokUr 1944 i9 RokUr1940 i19STUDENT i16PRAC i13PRAC i20 NrIndeksu76943 i17 Zar 2000 i14 Zar2500 i21 Wydział ”fizyka” i18 PracujeW i15 PracujeW i128 i127

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

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

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