Bazy danych i inżynieria oprogramowania

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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 1
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 2
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).
Wersje:
• ODMG-93 wersja 1.1 (grudzień 1993)
• ODMG-93 wersja 1.2 (styczeń 1996)
• ODMG wersja 2.0 (sierpień 1997)
(Morgan Kaufman Publishers)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 3
Kluczowi zawodnicy obiektowych BD
Źródło: Barry & Associates, Inc., styczeń 1997, http://www.odbmsfacts.com
System
Wersja Firma
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
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 4
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
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 5
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)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 6
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 7
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?
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 8
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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 9
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...
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 10
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).”
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 11
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 obiektoworelacyjnych, 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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 12
ODMG 2.0: Ramowa architektura
Źródłowe aplikacje
w rozszerzonym jęz.progr.
Deklaracje w ODL
lub jęz.progr./ODL
Preprocesor deklaracji
Kompilator jęz. progr.
metadane
OSZBD,
procedury czasu
wykonania (runtime)
Aplikacje w kodzie
do konsolidacji
Konsolidator (linker)
Dostęp do danych
Baza danych
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 13
Działający program
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.
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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 14
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).
Mniej formalnie:
Interfejs
= typ
Implementacja = klasa
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 15
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).
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 7, Folia 16