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
K.Subieta. Założenia projektu SZOBD, Folia 2 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 3 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 4 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 bazo-danowych 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 5 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 6 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 7 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 8 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 9 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 10 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 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ą.
K.Subieta. Założenia projektu SZOBD, Folia 11 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 12 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 13 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 14 czerwiec 2001
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
K.Subieta. Założenia projektu SZOBD, Folia 15 czerwiec 2001
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.
K.Subieta. Założenia projektu SZOBD, Folia 16 czerwiec 2001
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ą)
K.Subieta. Założenia projektu SZOBD, Folia 17 czerwiec 2001
Integracja zasobów rozproszonych
Filozofia podobna do założeń standardu CORBA:
Integrator i broker
odległych baz danych
Miejsce 1
Integrator i broker
odległych baz danych
Miejsce 2
Integrator i broker
odległych baz danych
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.
K.Subieta. Założenia projektu SZOBD, Folia 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 czerwiec 2001
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
K.Subieta. Założenia projektu SZOBD, Folia 27 czerwiec 2001
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.
K.Subieta. Założenia projektu SZOBD, Folia 28 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 29 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 30 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?