Bazy danych i inżynieria oprogramowania

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 1

Bazy danych i inżynieria oprogramowania

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 7:

Wprowadzenie do standardu ODMG, część 1: Motywacje, Model obiektowy


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

Plan wykładu (część 1)


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

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)

Co to jest ODMG?


System

ODB-II (Jasmine)GemStoneOdapter (Java/Depot)ITASCA (Orion)Illustra/InformixMATISSEO2ObjectStoreObjectivity/DBOmniscienceONTOS DBPersistenceIDB Object DatabasePOETUniSQLOSMOSODBMSVERSANT

Wersja

2.05.0B.05.xx2.3.53.03.05.04.0.24.13.03.23.2102.54.03.5R10.03.14.2

Firma

Fujitsu Software Corporation + Computer AssociatesGemstone Systems, Inc.Hewlett-Packard CompanyIBEX Corporation S.A.Illustra Information Technologies, Inc.MATISSE Software, Inc.O2 TechnologyObject Design, Inc.Objectivity, IncOmniscience Object Technology, Inc.ONTOS, Inc.Persistence Software, Inc.Persistent Data Systems, Inc.POET Software, Inc.UniSQL, Inc.Unisys CorporationVC Software, Inc.Versant Object Technology

Źródło: Barry & Associates, Inc., styczeń 1997, http://www.odbmsfacts.com

Kluczowi zawodnicy obiektowych BD


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


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)


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


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?


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

dostawcySzybszy wzrost przemysłu, poprzez wzrost konkurencji

w zakresie wartości dodanychKomunikacja pomiędzy użytkownikami i projektantamiUjednolicone 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.


Co podlega standardyzacji?

InterfejsyInterfejsy Ale nie wnętrze OSZBD lub jego architekturę

Kandydaci do standardyzacji: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...


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


ODMG 2.0: podejście umiarkowanie rewolucyjne

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.

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.


ODMG 2.0: Ramowa architektura

Deklaracje w ODLlub jęz.progr./ODL

Deklaracje w ODLlub jęz.progr./ODL

Źródłowe aplikacjew rozszerzonym jęz.progr.

Źródłowe aplikacjew rozszerzonym jęz.progr.

Kompilator jęz. progr.

Konsolidator (linker)

Baza danych

OSZBD,procedury czasu

wykonania (runtime)

Aplikacje w kodziedo konsolidacji

Działający program

Preprocesor deklaracji

Dostęp do danych

metadane


Model obiektowy ODMGUstala konstrukcje, które muszą być wspomagane przez OSZBDUstala 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.

Zachowanie się 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.


Typy i klasy; interfejsy i implementacjeTyp 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).

Oddzielenie interfejsu (specyfikacji klasy) od implementacji jest bardzo istotne i określa sposób, w jaki ODMG podchodzi do problemu hermetyzacji (encapsulation).

Interfejs = typImplementacja = klasa

Mniej formalnie:


Podtypy i dziedziczenie

Związek typ-podtyp (typ-nadtyp), określany także jako związek is-a.Związek typ-podtyp (typ-nadtyp), określany także jako związek is-a.

interface Pracownik{...};interface Profesor : Pracownik{...};interface ProfesorNadzw : Profesor{...};

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.

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

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

subtypes, inheritance

Documents

Bazy danych i inżynieria oprogramowania