Obiektowe bazy danych, aktualizowalne perspektywy i technologie gridowe

1. Obiektowe bazy danych, aktualizowalne perspektywy i technologie gridowe Prelegent: Kazimierz Subieta Zespół Baz Danych i Systemów Rozproszonych IPI PAN Katedra Systemów Informacyjnych PJWSTK

2. Dlaczego obiektowe bazy danych? • Modelowanie pojęciowe: • Sprzyjanie naturalnym ludzkim własnościom w zakresie percepcji i rozumienia świata. • Zmniejszenie dystansu pomiędzy modelem koncepcyjnym (biznesowym) przedsięwzięcia informatycznego a modelem implementacyjnym. • Zasada abstrakcji (enkapsulacji): • umożliwienie projektowania i zarządzania bryłami koncepcyjnymi (obiektami) bez potrzeby wnikania w ich wewnętrzną strukturę • Zasada dekompozycji • umożliwienie zdekomponowania złożonego problemu na pod-problemy • Zasada ponownego użycia (otwarte-zamknięte): • umożliwienie tworzenie brył koncepcyjnych (klas) zamkniętych dla modyfikacji, ale otwartych dla rozszerzeń.

3. Cechy obiektowych baz danych • Złożone obiekty: mogą być dowolnie duże. • Kolekcje: obiekty o podobnych własnościach. • Powiązania. związki asocjacyjne między obiektami. • Hermetyzacja. Rozróżnienie pomiędzy interfejsem do obiektu a implementacją obiektu; ukrywanie implementacji. • Klasy. Cechy niezmienne dla zbiorów obiektów. • Metody. Procedury wykonywane w środowisku wnętrza obiektu. • Hierarchia klas i dziedziczenie: klasy szczegółowe dziedziczą niezmienniki swoich nad-klas. • Polimorfizm. Wywołana operacja zależy od rodzaju obiektu. • Trwałość. Obiekty żyją dowolnie długo.

4. Obiektowe języki zapytań • Język zapytań – interfejs dostępu i wyszukiwania w bazie danych. • Wysoki poziom abstrakcji i konceptalizacji • SQL – najbardziej popularny język zapytań do relacyjnych baz danych, uważany za główne źródło ich sukcesu • Liczne próby przeniesienia tego sukcesu na grunt obiektowych i XML-owych baz danych • dziesiątki pomysłów - ograniczonych i/lub niespójnych • Podejście stosowe (Stack-Based Approach) –podejście najbardziej konsekwentne i uniwersalne • Praca habilitacyjna (K.Subieta, 1984-89) • Bazujące na wszechstronnych praktycznych doświadczeniach • Udoskonalone i rozszerzone (w ciągu 20 lat) pod względem koncepcyjnym i dydaktycznym

5. Podejście stosowe do języków zapytań • Alternatywa dla relacyjnych algebr, relacyjnych rachunków, specjalnych logik i innych pomysłów. • Założenie: języki zapytań są rodzajem języków programowania. • Uogólniony stos środowiskowy jako podstawa definicji operatorów języków zapytań. • Precyzyjna semantyka podana w formie abstrakcyjnej implementacji (semantyka operacyjna). • Duży potencjał dla optymalizacji zapytań. • Daje możliwość definiowania języków zapytań dla dowolnego modelu składu: relacyjnego, obiektowo-relacyjnego, obiektowego, XML-owego, itd. • Rozszerzenia w kierunku konstrukcji imperatywnych, procedur, funkcji, metod, perspektyw, mocnej kontroli typów.

6. Język zapytań SBQL (Stack-Based Query Language) • Pełna modularność i ortogonalność • Formalna implementowalna semantyka • Abstrakcyjna składnia • posmak algebry, logiki, rachunku, itp. • Rozszerzenia w kierunku języków programowania. • Szereg implementacji: • Netul, Loqis, XML DOM, ICONS, YAOD, Objectivity/DB, BPQL, ODRA (nad rozwojem pracuje obecnie ok. 20 osób), • SBA i SBQL nauczane w PJWSTK (2 semestry, 60h wykładów + 60h laboratoriów) • Ukończona książka (ok. 530 stron)

7. Przykład zapytania Osoba[0..*] Nazwisko Imię[1..*] Adres[1..*] Firma[0..*] Nazwa Miejsce[1..*] Zatrudnienie[0..*] Wypłata[0..*] Ocena[1..*] FZ[0..*] ZF ZP PZ[0..*] Pracownik[0..*] Stan[1..*] Podaj nazwiska i stanowiska pracowników pracujących w firmach zlokalizowanych w Radomiu: SBQL, model obiektowy: • (Firmawhere ”Radom”Miejsce). FZ.Zatrudnienie.ZP.Pracownik. • (Nazwisko, Stan) SQL, po odwzorowaniu powyższego schematu na model relacyjny • selects.Nazwisko, w.Stan • fromFirmaasf, Lokalask, Zatrudnienieasz, • Pracownikasp, Wyszkolenie as w, Osobaas s • wherek.Miejsce = “Radom” andk.NrF = f.NrF • andf.NrF = z.ZFandz.ZP = p.NrPandw.NrP = p.NrP • andp.NrOs = s.NrOs

8. Perspektywy (views) • Określają dane wirtualne („istniejące” w wyobraźni programisty). • Są definiowane poprzez język zapytań i używane w zapytaniach. • Umożliwiają przystosowanie schematu bazy danych do wymagań użytkownika. • Ograniczają dostęp do danych. • Liczne zastosowania praktyczne dla wielu celów. • Problemy związane z perspektywami: • Uniwersalność: język perspektyw powinien dawać możliwość dowolnego odwzorowania zapamiętanych danych w dane wirtualne. • Przezroczystość dla wyszukiwania i aktualizacji. Z punktu widzenia użytkownika lub programisty nie występują jakiekolwiek różnice w operowaniu na zapamiętanych i wirtualnych danych. • Problem aktualizacji danych wirtualnych jest znany od 1974 roku, ale do czasu SBQL nie doczekał się uniwersalnego rozwiązania. • Optymalizacja: efektywna realizacja zapytań odwołujących się do perspektyw.

9. Problem aktualizowalnych perspektyw • Perspektywa jest odwzorowaniem zapamiętanych danych na zasadzie „wiele do jednego”. • Stąd odwzorowanie aktualizacji danych wirtualnych na aktualizacje danych rzeczywistych zwykle nie jest jednoznaczne. • Np. jeżeli perspektywa zwraca średni zarobek pracowników, to zwiększenie średniego zarobku o 100 zł może być odwzorowane na aktualizację zapamiętanych danych na nieskończenie wiele sposobów. • Cały wysiłek teoretyków (setki prac) skupił się na ustalaniu ograniczeń, przy których perspektywę można aktualizować jednoznacznie, bez anomalii i efektów ubocznych. • Ten wysiłek jest przykładem skierowania badań na boczny, scholastyczny tor omijający rzeczywisty problem. Przez to otrzymane wyniki okazały się dla praktyki bezużuteczne.

10. Rewolucyjny pomysł • Pomysł aktualizowalnych procedur polega na uzupełnieniu definicji perspektywy poprzez informacje o intencji użytkownika. • Podobnie jest w instead of trigger views systemów Oracle i SQL Server. • Pierwsza część definicji odwzorowuje zapamiętane obiekty w obiekty wirtualne (podobnie jak w SQL). Ma postać procedury funkcyjnej zwracającej byty zwane „ziarnami”. • Druga część re-definiuje generyczne operacje aktualizacyjne działające na obiektach wirtualnych. • Są to cztery procedury mające ziarno jako parametr: • on_deleteusuwa obiekt wirtualny, • on_retrieve zwraca wartość obiektu wirtualnego, • on_insertwkłada dany obiekt do wnętrza obiektu wirtualnego • on_updatemodyfikuje obiekt wirtualny zgodnie z parametrem aktualizacji. • W ten sposób osoba definiująca perspektywę może przejąć kontrolę nad dowolną operacją wykonywaną na wirtualnym obiekcie, realizując w ten sposób w pełni zasadę przezroczystości perspektyw. • Wszystkie tzw. „kryteria aktualizowalności perspektyw” wyrzucamy do śmieci.

11. Przykład aktualizowalnej perspektywy create viewPracSzefDef { virtual objectsPracSzef { returnPracasp }; on_delete do { deletep }; create viewNazwPracDef { virtual objectsNazwPrac{ returnp.Nazwiskoasn }; on_retrieve do { returnn } } create viewNazwSzefaDef { virtual objectsNazwSzefa{ returnp.PracujeW.Dział.Szef.Prac.Nazwisko ass }; on_retrieve do{ returns }; on_update( NowySzef ) do { p.PracujeW := refDziałwhere (Szef.Prac.Nazwisko)= NowySzef }}} • Baza danych zawiera obiekty Prac i Dział połączone związkami PracujeW/Zatrudnia oraz Kieruje/Szef. • Obiekty wirtualne PracSzef zawierają tylko nazwisko pracownika i nazwisko szefa. • Aktualizacja nazwiska szefa ma oznaczać nie zmianę jego nazwiska, lecz przeniesienie pracownika do działu, którego szefem jest pracownik z tym nazwiskiem. Przenieś Nowaka do działu kierowanego przez Bryla: (PracSzefwhereNazwPrac = ”Nowak”).NazwSzefa := ”Bryl”

12. Grid computing • Grid computing jest nową wersją starego marzenia o masowej równoległości przetwarzania. • Grid ma zsumować zasoby wielu (tysięcy) komputerów w jeden ogromny wirtualny komputer • Nowy termin wzbudza nowe nadzieje i nowe środki przeznaczone na realizację starego marzenia. • Wiele obecnych technologii jest mniej lub bardziej udaną realizacją tego marzenia. • CORBA, RMI, Web Services (OGSA), J2EE, .NET, ... • Sieci P2P • Federacyjne bazy danych (Oracle 10G) • Technologie agentowe (???) • ... • Nowa kultura informacyjna, w której usługa jest na pierwszym planie, zaś usługodawca na drugim (jeżeli w ogóle).

13. Cztery najważniejsze problemy gridów • Przezroczystość (transparency): traktowanie rozproszonych zasobów i usług tak, jak gdyby były one wewnątrz przestrzeni adresowej jednego komputera. • przezroczystość ma wiele form: lokacji, implementacji, replikacji, fragmentacji, współbieżności, transakcji, awarii, indeksowania, ... • Bezpieczeństwo: przeciwdziałanie losowym awariom oraz możliwościom ataku z zewnętrz. • Interoperacyjność (interoperability): umożliwienie współpracy heterogenicznych platform, aplikacji, logik biznesowych i organizacji danych. • Efektywność: uzyskanie czasów przetwarzania akceptowalnych dla szerokiego kręgu użytkowników rozproszonych aplikacji.

14. Globalny klient 1 Globalny klient 2 Globalny klient 3 Perspektywy kontrybucyjne Perspektywy kontrybucyjne Schemat kontrybucyjny Schemat kontrybucyjny Od aktualizowalnych perspektyw do gridu ... Schematglobalny Globalny wirtualny serwer obiektów i usług Perspektywy globalne Projektant gridu Protokół komunikacyjny Schemat integracyjny Lokalny serwer A obiektów i usług Lokalny serwer B obiektów i usług ... Lokalna baza danych Lokalna baza danych

15. Podsumowanie • W tej chwili następuje konsolidacja dużej grupy badawczej wokół dobrze zdefiniowanych celów naukowych i praktycznych. • Kluczem do przebicia się na większym forum światowym jest realizacja własnego systemu o unikalnych własnościach (not „yet another”). • Mamy pomysł na taki system. Pierwsze rezultaty są osiągnięte (obiektowa baza danych, język SBQL), dalsze będą przedmiotem prac w bieżącym i przyszłym roku. • Bardzo istotne jest zabieganie o finanse. Bez nich prace implementacyjne nie nabiorą rozmachu. Szanse na granty może zwiększyć pokazanie praktycznej skuteczności. • Naszymi głównymi atutami podczas przebijania się na forum światowym są: podejście stosowe do obiektowych języków zapytań, aktualizowalne perspektywy i technologie gridowe.