Bazy danych i inżynieria oprogramowania

1. Bazy danych i inżynieria oprogramowania Wykład 7: Wprowadzenie do standardu ODMG, część 1: Motywacje, Model obiektowy Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. Plan wykładu (część 1) Co to jest ODMG? Krytyczne cechy obiektowych baz danych; kryteria wyboru Cele i uwarunkowania standardu Zawartość standardu ODMG 2.0; ramowa architektura Model obiektowy ODMG • Typy i klasy; interfejsy i implementacje • Podtypy i dziedziczenie

3. Co to jest ODMG? Object Database Management Group Jest to konsorcjum powstałe w wyniku porozumienia kilkunastu firm oferujacych swoje produkty określane jako “obiektowe systemy zarządzania bazami danych”: Objectivity, ObjectDesign, Ontos, O2, Poet, Servio, Versant,, ... Pomysł, forma działania, początkowy impuls oraz obiektowy model danych pochodzi od konsorcjum OMG, która opracowała i rozwija standard CORBA. ODMG nie ma związku z oficjalnymi instytucjami normalizacyjnymi takimi jak ANSI lub ISO. Zdaniem twórców ODMG, instytucje te działają wolno, nieefektywnie i są obciążone własnymi preferencjami. Standard ODMG budzi kontrowersje, zaś jego ogólny poziom techniczny jest przedmiotem krytyki. Wady są systematycznie usuwane w kolejnych wersjach standardu, ale nadal jest ich sporo (bedą omówione). • ODMG-93 wersja 1.1 (grudzień 1993) • ODMG-93 wersja 1.2 (styczeń 1996) • ODMG wersja 2.0 (sierpień 1997) Wersje: (Morgan Kaufman Publishers)

4. Kluczowi zawodnicy obiektowych BD Źródło: Barry & Associates, Inc., styczeń 1997, http://www.odbmsfacts.com System ODB-II (Jasmine) GemStone Odapter (Java/Depot) ITASCA (Orion) Illustra/Informix MATISSE O2 ObjectStore Objectivity/DB Omniscience ONTOS DB Persistence IDB Object Database POET UniSQL OSMOS ODBMS VERSANT Wersja 2.0 5.0 B.05.xx 2.3.5 3.0 3.0 5.0 4.0.2 4.1 3.0 3.2 3.210 2.5 4.0 3.5 R10.0 3.1 4.2 Firma Fujitsu Software Corporation + Computer Associates Gemstone Systems, Inc. Hewlett-Packard Company IBEX Corporation S.A. Illustra Information Technologies, Inc. MATISSE Software, Inc. O2 Technology Object Design, Inc. Objectivity, Inc Omniscience Object Technology, Inc. ONTOS, Inc. Persistence Software, Inc. Persistent Data Systems, Inc. POET Software, Inc. UniSQL, Inc. Unisys Corporation VC Software, Inc. Versant Object Technology

5. Krytyczne cechy obiektowych baz danych: (1) • Jasny, naturalny, uniwersalny, powszechnie akceptowany model danych i • odpowiadający temu modelowi język opisu danych (język schematu) • Języki zapytań: zapytania interakcyjne ad hoc, zagnieżdżanie zapytań (embedding) • Programowanie poprzez języki zapytań; bezszwowa integracja języka zapytań z • językiem programowani; perspektywy, zapamiętane procedury, reguły • Optymalizacja zapytań (query optimization) • Obiektowe programowanie wizyjne (visual programming) • Interfejsy (wiązania) do programowania aplikacji (API) dla • popularnych języków programowania • Wygodne środowisko do tworzenia i uruchamiania aplikacji • Dynamiczna autoryzacja dostępu

6. Krytyczne cechy obiektowych baz danych (2) • Sprawne zarządzanie pamięcią zewnętrzną, indeksowanie, buforowanie, odśmiecanie • Konsekwentna organizacja i dostęp do meta-informacji (katalogów, pomocy) • Rozszerzalność, skalowalność, dynamiczna ewolucja schematu • Wspomaganie dla więzów integralności (integrity constraints) • i aktywnych reguł (active rules) • Dobrze udokumentowane, uniwersalne, elastyczne i minimalne biblioteki klas • oraz inne środki ponownego użycia • Wspomaganie dla materializowanych i niematerializowanych obiektowych • perspektyw (object views), aktualizacja perspektyw (view updating) • Bezszwowa integracja multimediów (tekst, grafika, wideo, audio)

7. Krytyczne cechy obiektowych baz danych (3) • Zintegrowanie systemu z bogatym zestawem narzędzi i udogodnień (data mining, CASE, • data warehouses, pakiety statytystyczne, ...) • Zarządzanie transakcjami (własności ACID, długie transakcje) • Składowanie (backup), odwracanie (rollback) i odtwarzanie (recovery) • Wersjonowanie, własności temporalne, obiekty archiwalne • Integracja z serwisami Internetu (przystosowanie do dostępu poprzez Web) • Współdziałanie systemów heterogenicznych, przystosowanie do współpracy z • z oprogramowaniem komponentowym (CORBA, OpenDoc, JavaBeans, ActiveX) • Architektura klient-serwer • Zarządzanie rozproszonymi obiektami, rozproszone przetwarzanie, • optymalizacja zapytań w systemach rozproszonych • Zarządzanie metodami dostępu, parametryczne dostrajanie

8. Kryteria oceny (obiektowych) SZBD Wydajność (performance) - jak szybki jest produkt? Skalowalność (scalability) - jak produkt będzie działał gdy wzrośnie liczba użytkowników i objętość danych? Funkcjonalność (functionality) - jakie możliwości i cechy produkt oferuje? Zgodność ze standardami - czy produkt uzależnia od jednego dostawcy? Łatwość użycia (usability) - ile wysiłku kosztuje nauczenie się produktu i jak łatwo będzie się go używać? Niezawodność (reliability) - jak często produkt zawodzi? Wspomaganie (support) - czy dostawca produktu zapewnia pomoc i jest odpowiedzialny? Środowisko (environment) - na jakim sprzęcie/systemie operacyjnym pracuje produkt? Żywotność (viability) - czy można oczekiwać, że dostawca będzie podtrzymywał produkt w przyszłości? Cena (price) - ile kosztuje produkt, w krótkim czasie i w oczekiwanym horyzoncie czasowym?

9. Po co standard? Przenaszalność (portability): Aplikacja może działać na różnych obiektowych SZBD. Współdziałanie (interoperability): Aplikacja może działać jednocześnie z wieloma obiektowymi SZBD Wartość dodana, synergia: Wytwórcy oprogramowania mogą skupić się na wartościach dodanych, nie na podstawowych interfejsach Narzędzia i biblioteki wspólne dla wielu systemów (nowy rynek) Uwolnienie użytkowników od niebezpieczeństwa zależności od jednego dostawcy Szybszy wzrost przemysłu, poprzez wzrost konkurencji w zakresie wartości dodanych Komunikacja pomiędzy użytkownikami i projektantami Ujednolicone uczenie W tej chwili jest dość trudno ocenić, czy standard spełni te oczekiwania. Jak uczy doświadczenie standardów SQL i C++, prawdopodobnie nie spełni. Jest to jednak nieodzowny początek drogi.

10. Co podlega standardyzacji? Interfejsy Ale nie wnętrze OSZBD lub jego architekturę Kandydaci do standardyzacji: + + +/- +/- - + - - - - - - • Model obiektowy (pojęcia, ograniczenia, terminologia) • Język definicji obiektów • Format wymiany informacji (przekazywania obiektów) • Obiektowy język zapytań • Abstrakcje wspomagające język zapytań (perspektywy, • zapamiętane procedury, aktywne reguły,...) • Wiązania do języków programowania: C++, Smalltalk, Java,... • Zintegrowany język programowania aplikacji oparty o • język zapytań (do pisania metod) • Pomosty (gateways) do innych systemów (np. relacyjnych) • Administrację systemem, katalogi BD, dostęp do katalogów • Prawa dostępu, bezpieczeństwo • Narzędzia i usługi (klasy systemowe, biblioteki klas) • Protokóły wymiany informacji w sieci (np. IIOP) Jest jeszcze wiele do zrobienia...

11. ODMG 2.0: zawartość • Ramowa architektura OSZBD • Model obiektowy • Języki specyfikacji obiektów • - Język definicji obiektówODL (nadzbiór OMG IDL) • - Format wymiany obiektów • Obiektowy język zapytań OQL (składnia wzorowana na SQL) • Wiązanie do C++ • Wiązanie do Smalltalk’a • Wiązanie do Java • Dodatki • - Porównanie z modelem obiektowym OMG • - Obiektowe bazy danych w środowisku OMG CORBA “Standard leży na przecięciu trzech istniejących dziedzin technologicznych: baz danych (SQL), technologii obiektowych (OMG) oraz obiektowych języków programowania (C++, Smalltalk, Java).”

12. ODMG 2.0: podejście umiarkowanie rewolucyjne Podejście ewolucyjne: Rozbudowa relacyjnych SZBD (DB2, Oracle, Sybase, Informix, Ingres) o nowe własności, w tym obiektowe np. BLOBy, abstrakcyjne typy danych, zapamiętane procedury. Niweczą standard SQL-92 poprzez niekompatybilne rozszerzenia Podejście eklektyczne, odmiana podejścia ewolucyjnego: Budowa systemów obiektowo-relacyjnych, umożliwiających przechowywanie tradycyjnych tablic i obiektów. Brak kompatybilności, koncepcyjna redundancja, przypadkowość, niesystematyczność rozwiązań. SQL3 jest tu nadzieją, ale dość iluzoryczną. Podejście “wolna amerykanka”: Spontaniczna rozbudowa “od dołu do góry” niektórych narzędzi wspomagających “małą informatykę”: arkuszy kalkulacyjnych, systemów przetwarzania dokumentów (LotusNotes, MS Repository). Standardyzacja - wątpliwa. Podejście umiarkowanie rewolucyjne: Jednorodny model obiektowy, ale z licznymi odniesieniami do istniejących technologii. Takie właśnie podejście reprezentuje ODMG 2.0. Podejście rewolucyjne: Jednorodny model obiektowy, jednorodna architektura i język programowania baz danych, język zapytań zintegrowany z językiem programowania. Całkowite odrzucenie półśrodków takich jak C++, Java, SQL. Mocny polimorficzny system kontroli typów, ortogonalna trwałość, ortogonalność języków zapytań i trwałości.

13. ODMG 2.0: Ramowa architektura Baza danych Deklaracje w ODL lub jęz.progr./ODL Źródłowe aplikacje w rozszerzonym jęz.progr. Preprocesor deklaracji Kompilator jęz. progr. OSZBD, procedury czasu wykonania (runtime) Aplikacje w kodzie do konsolidacji metadane Konsolidator (linker) Dostęp do danych Działający program

14. Model obiektowy ODMG Ustala konstrukcje, które muszą być wspomagane przez OSZBD Podstawowymi prymitywami modelu są obiekty i literale. Każdy obiekt posiada unikalny identyfikator. Literal nie posiada identyfikatora, jest to stała. Obiekty i literale są charakteryzowane poprzez typy. Każdy element danego typu posiada wspólną dziedzinę stanów (ten sam zestaw własności) oraz wspólne zachowanie (ten sam zestaw operacji). Obiekt jest niekiedy określany jako wystąpienie typu. Stan obiektu jest zdefiniowany jako wartości przechowywane dla własności. Własnościami mogą być atrybuty obiektu oraz związki obiektu z innymi obiektami. Zwykle własności obiektu mogą zmieniać się w czasie. Zachowaniesię obiektu jest zdefiniowane poprzez zbiór operacji, które mogą być wykonane na obiekcie lub przez obiekt. Operacje mogą mieć parametry wejściowe i wyjściowe, każdy z wyspecyfikowanym typem. Operacja może zwrócić rezultat określonego typu. Baza danych przechowuje obiekty, umożliwiając jednoczesny dostęp do nich przez wielu użytkowników. Opiera się na schemacie zdefiniowanym w ODL i zawiera wystąpienia typów zdefiniowane w jej schemacie.

15. Typy i klasy; interfejsy i implementacje Typ posiada dwa aspekty: - specyfikację interfejsu (jedną) - jedną lub więcej specyfikacji implementacji Interfejs (interface): zewnętrzna charakterystyka obiektów danego typu widoczna dla użytkowników obiektu. Interfejs włącza operacje, które można wykonać na obiekcie oraz zmienne stanu (atrybuty), których wartości są dostępne z zewnątrz. Implementacja: określa wewnętrzne aspekty obiektu danego typu. Składa się z reprezentacji oraz zbioru metod. Metody są ciałami procedur. Dla każdej operacji zdefiniowanej w interfejsie istnieje odpowiednia metoda, która ustala czynności niezbędne dla wykonania tej operacji. Implementacja może zawieraćstruktury danych i metody wewnętrzne, niewidoczne dla użytkowników obiektu i nie wyspecyfikowane w interfejsie. Typ może mieć wiele implementacji, np. jedną w C++, inną w Smalltalk’u; tylko jedna z nich występuje w danej aplikacji. Oddzielenie interfejsu (specyfikacji klasy) od implementacji jest bardzo istotne i określa sposób, w jaki ODMG podchodzi do problemu hermetyzacji (encapsulation). Interfejs = typ Implementacja = klasa Mniej formalnie:

16. Podtypy i dziedziczenie subtypes, inheritance Związek typ-podtyp (typ-nadtyp), określany także jako związek is-a. interface Pracownik{...}; interface Profesor : Pracownik{...}; interface ProfesorNadzw : Profesor{...}; Obiekt typu Profesor posiada cały interfejs Pracownik plus swój własny. Obiekt typu ProfesorNadzw posiada cały interfejs Profesor plus swój własny (czyli cały interfejs Pracownik, plus to, co dodał Profesor, plus własny). Dowolne wystąpienie podtypu jest jednocześnie wystąpieniem nadtypu, np. obiekt typu ProfesorNadzw jest jednocześnie obiektem typu Pracownik. Relacje “być podtypem”, “być nadtypem” są przechodnie. Stąd wynika, że wszędzie tam, gdzie może być użyty obiekt o danym typie T, może być także użyty obiekt typu T1, gdzie T1 jest podtypem T. Np. Wszędzie tam gdzie mozę być użyty obiekt Pracownik może być także użyty obiekt Profesor lub typu ProfesorNadzw. Jest to zasada zamienialności (substitutability).