1 / 15

Obiektowe bazy danych, aktualizowalne perspektywy i technologie gridowe

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. Dlaczego obiektowe bazy danych?. Modelowanie pojęciowe:

thanos
Download Presentation

Obiektowe bazy danych, aktualizowalne perspektywy i technologie gridowe

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related