240 likes | 344 Views
Obiektowość w bazach danych - koncepcje, nadzieje i fakty. III Konferencja Użytkowników I Developerów ORACLE. Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa. Plan prezentacji. Geneza i motywacje obiektowości
E N D
Obiektowość w bazach danych - koncepcje, nadzieje i fakty III Konferencja Użytkowników I Developerów ORACLE Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa
Plan prezentacji Geneza i motywacje obiektowości Podstawowe założenia obiektowości Niektóre pojęcia obiektowści: obiekty, komunikaty, klasy Co to jest obiektowy SZBD? Standard ODMG 2.0 Komercyjne obiektowe SZBD Systemy obiektowo-relacyjne Obiektowość kontra model relacyjny Podsumowanie
Obiektowość jako ideologia Obiektowość jest nową ideologią która wynika z zaobserwowanych wad istniejącego świata i podaje receptę jak te wady usunąć. Wady: Złożoność: przekleństwo ciążące na większości projektów i produktów informatyki. Kryzys softwerowy: oprogramowanie i jego utrzymanie kosztuje zbyt dużo i jest zawodne współdziałanie pomiędzy produktami oprogramownia jest problemem Niedopasowanie metodyk analizy i projektowania systemów informacyjnych do bazy realizacyjnej systemów (języków programowania, systemów zarządzania bazami danych) Głównym problemem systemów stał się człowiek (analityk, projektant, programista). Technologie komputerowe powinny być bardziej zorientowane na ludzi, nie na maszyny Co robić? Podwyższyć poziom abstrakcji w projektowaniu i programowaniu. Dopasować wszystkie fazy projektu do uwarunkowań technicznych i ludzkich.
Symptomy kryzysu oprogramowania Sprzeczność pomiędzy ogromną odpowiedzialnościa spoczywajaca na systemach komputerowych, a ich zawodnoscią wynikającą z niedoskonałości oprogramowania i technik jego tworzenia. USA: Utrzymanie 10 mld. linii istniejących programów kosztuje 70 mld. $ rocznie. (IEEE Software Development, Aug 94, p.65) Długi cykl tworzenia oprogramowania, niska wydajność projektantów i programistów Wysokie prowdopodobieństwo niepowodzenia projektu Problem zmiany wymagań i systemów spadkowych
Filozoficzna misja obiektowości Uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości a myśleniem o danych i procesach które zachodzą na danych. Schemat struktury danych Model pojęciowy Mentalna percepcja świata rzeczywistego W modelu relacyjnym model pojęciowy stara się odwzorować świat rzeczywisty, lecz jest ograniczony dostępną bazą implementacyjną. W rezultacie, schemat struktury danych gubi semantykę danych. Model obiektowy podtrzymuje te zgodności, przybliżając semantykę danych do świata rzeczywistego.
Oczekiwania dotyczące obiektowości Większa wydajność tworzenia oprogramowania, krótszy cykl tworzenia oprogramowania, mniejsze koszty tworzenia i utrzymywania oprogramowania. Mechanizmy abstrakcji dostarczone projektantowi, pozwalające budować coraz większe jednostki oprogramowania i operować tymi jednostkami bez wnikania w ich wewnętrzną struktur; oddzielenie specyfikacji od implementacji. Mechanizmy kompozycji i dekompozycji: - zamykanie detali projektu lub oprogramowania w coraz większe jednostki - dekomponowanie złożonych struktur na ich fragmenty i rozpatrywanie tych fragmentów niezależnie od siebie i niezależnie od całości Ponowne użycie (reuse) wcześniej wytworzonych komponentów oprogramowania. Może ono dotyczyć wszystkich elementów projektu i oprogramowania. Podstawowe mechanizmy: tworzenie klas wyspecjalizowanych, tworzenie agregatów. Jakość, niezawodność, testowalność, rozszerzalność, łatwa pielęgnacja oprogramowania, szybkie prototypowanie, współdziałanie, przenaszalność Efekty:
Wyzwania technologiczne • Wydajność wytwarzania oprogramowania • Ponowne użycie składników projektów i • oprogramowania • Hermetyzacja składowych oprogramowania • Automatyzacja wytwarzania oprogramowania • Skalowalność oprogramowania (możliwość rozbudowy) • Rynek komponentów oprogramowania
Czynniki wydajności produkcji oprogramowania Wydajność = krótki cykl tworzenia • Programowanie wizyjne sterowane zdarzeniami • Wysoki poziom abstrakcji w programowaniu • Środowisko obiektowe • Środki uniwersalne (generic) wysokiego poziomu • Współdziałanie systemów informatycznych (standardy) • Składniki oprogramowania ponownego użycia • Oprogramowanie komponentowe
Podstawowe założenia obiektowości Złożone obiekty - Oprogramowanie powinno składać się z małych, zrozumiałych modułów, zawierających struktury danych i dozwolone na nich operacje, czyli obiektów. Powiązania - Obiekty mogą być powiązane związkami asocjacyjnymi. Hermetyzacja - Jasne rozróżnienie pomiędzy interfejsem do obiektu opisującym co obiekt zawiera i co robi, a implementacją definiującą jak on jest zbudowany i jak on to robi. Typy i klasy - Zgrupowanie obiektów o tych samych charakterystykach i traktowanie ich jako bytów tej samej klasy; sprawdzanie typologicznej poprawności użycia obiektów. Dziedziczenie - Wielokrotne użycie tego, co wcześniej zostało zrobione: definiowanie typów, które mają wszystkie wcześniej zdefiniowane cechy plus niektóre nowe cechy. Komunikaty - Obiekt wykonuje jedną z jego funkcji po wysłaniu do niego odpowiedniego komunikatu, który nie zależy od tego jak obiekt jest zaimplementowany. Polimorfizm - Wybór nazwy dla operacji jest określony wyłącznie jej zewnętrznym, pojęciowym znaczeniem. Obiekt sam decyduje, którą operację wybrać, jeżeli w skierowanym do niego komunikacie została użyta ta nazwa.
Obiekty (1) Obiektem jest rzecz lub pojęcie obserwowane w świecie rzeczywistym którego dotyczy SI. Obiekt jest odróżnialny od innych obiektów, ma dobrze określone granice i nazwę. Obiektem może być także pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu,...), którym można operować jako zwartą bryłą (wyszukiwać, wiązać, kopiować, blokować, usuwać, indeksować, ...). Obiekt posiada swoją tożsamość, która wyróżnia go spośród innych obiektów. Tożsamość obiektu jest niezależna od wartości jakichkolwiek jego atrybutów i od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera. (praktycznie: tożsamość = trwały wewnętrzny identyfikator obiektu) Obiekt posiada stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu).
Obiekty (2) Obiekt może być złożony, tj. może składać się z mniejszych obiektów. Obiekt złożony zawiera w sobie wszelkie informacje, które składają się na jego stan Obiekt może być powiązany z innymi obiektami związkami asocjacyjnymi. Obiekt ma przypisane zachowanie, tj. zestaw operacji które wolno do niego stosować (implementacja operacji jest zwana metodą). Obiekt ma przypisany typ, tj. wyrażenie językowe, które ogranicza dopuszczalną budowę obiektu oraz ustala operacje, które wolno wykonać na obiekcie.
Przykład obiektu Wypłać Wpłać Porównaj podpis Sprawdź stan Numer: 123-4321 Stan konta: 34567 PLN Właściciel: Jan Kowalski Upoważniony:..... .... Nalicz procent Zlikwiduj konto Obiekt KONTO definiujący konto bankowe Zmień upoważnienie Upoważnij
Wypłać Wpłać Porównaj podpis Sprawdź stan Numer: 123-4321 Stan konta: 34567 PLN Właściciel: Jan Kowalski Upoważniony: .... Nalicz procent Zlikwiduj konto Zmień upoważnienie Upoważnij Komunikaty Wypłać 1000 PLN OK, wypłaciłem Graj Cccco proszę...?
Klasa class Dwa rozumienia, które nie zawsze są ze sobą zgodne: 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach. Własności te (zestaw atrybutów, metody) są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze obiektów Osoba. 2. Klasa jest miejscem przechowywania cech grupy obiektów, które są niezmienne (inwariantów). Klasa nie jest zbiorem obiektów i niekoniecznie jest definicją zbioru obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus niektóre własne. Najważniejsze inwarianty to: Nazwa, czyli językowy identyfikator obiektu Typ, czyli statyczna budowa obiektu (atrybuty) Metody, czyli operacje, które można wykonać na obiekcie
Obiektowy SZBD jest to SZBD Klasyczne funkcje SZBD: • Zarządzanie pamięcią zewnętrzną • Zarządzanie schematem • Sterowanie współbieżnością • Zarządzanie transakcjami • Odtwarzalność • Przetwarzanie zapytań • Kontrola dostępu Do tych funkcji dołożone są: • Złożone obiekty • Typy definiowane przez użytkownika • Tożsamość obiektów • Hermetyzacja • Typy i/lub klasy oraz ich hierarchia • Przesłanianie/przeciązanie/późne wiązanie • Kompletność obliczeniowa (pragmatyczna)
ODMG 2.0: standard obiektowych baz danych 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.
Co może podlegać standardyzacji? Interfejsy Ale nie wnętrze OSZBD lub jego architektura 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).”
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
Systemy obiektowo-relacyjne Podejście hybrydowe: zachowanie sprawdzonych technologii relacyjnych i wprowadzanie na ich wierzchołku innych własności, w tym obiektowych: Informix Universal Server, DB2 Universal Database, Oracle8, ….. Atrakcyjne cechy umożliwiające efektywną produkcję aplikacji: multimedia (duże obiekty BLOB, CLOB i pliki binarne), dane przestrzenne (spatial), abstrakcyjne typy danych (ADT), metody definiowane przez użytkownika, kolekcje (zbiory, wielozbiory,...), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Systemy te zachowują jednocześnie wiele sprawdzonych technologii: architektura klient/serwer, mechanizmy buforowania i indeksowania, przetwarzanie transakcji, optymalizacja zapytań. Systemy obiektowo-relacyjne są tworzone z myślą o szybkim i pewnym zysku. Mają licznych zwolenników z powodu pozycji systemów relacyjnych na rynku i odwołania się do ich wiernej klienteli.
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?
Przeszkody dla obiektowości Zastany świat interfejsów programistycznych (C, COBOL, Fortran, SQL, ...) Mity i fałszywe steoretypy: • Relacyjna baza danych zapewnia prostotę struktur danych • Bezpośrednie powiązania (wskaźniki) w bazie danych są niekorzystne • Tylko relacyjna baza danych zapewnia możliwość definiowania języków zapytań • Tylko relacyjna baza danych zapewnia sprawne przetwarzanie transakcji • Relacyjne bazy danych mają solidne podstawy matematyczne • Relacyjne bazy danych mają bardzo dobrą wydajność, nieosiągalną dla innych. “Spuścizna”: ogromne inwestycje w hierarchiczne, sieciowe i relacyjne bazy danych Własna słabość: słabo wyartykułowane zasady, formalizmy, języki, standardy; kompromisy w zakresie celów.
Obiektowość kontra model relacyjny? Model relacyjny przegrał walkę z obiektowością w strefie ideologicznej. Powstało szereg systemów relacyjnych, dojrzałych technicznie i użytecznych, ale posiadających zasadnicze odstępstwa od założeń modelu relacyjnego. Mocne podstawy matematyczne modelu relacyjnego są mitem. Teorie matematyczne są całkowicie nieadekwatne do praktyki. Twórcy systemów relacyjnych wzmacniają ich interfejsy o pojęcia obiektowe, oraz umożliwiają obiektowe perspektywy relacyjnych struktur danych (np. interfejsy oparte o OMG CORBA). Powstają ideologie i systemy hybrydowe, ktore łączą koncepcje relacyjne z obiektowymi. Jakkolwiek mogą one być bardzo użyteczne, są one nieregularne, trudne do standardyzacji i uzależniające klienta od jednego dostawcy.
Podsumowanie Obiektowość jest nową ideologią, która zmienia myślenie realizatorów SI z “zorientowanego na maszynę” na “zorientowane na człowieka”. Obiektowość jest konsekwencją kryzysu oprogramowania: kosztów związanych z oprogramowaniem, jego zawodnością, i trudną do opanowania złożonością. Obiektowość przenika wszelkie fazy projektowania, oraz narzędzia i interfejsy. Obiektowość dopracowała się własnej kolekcji pojęć i narzędzi. Obiektowość jest na początku swojej drogi i musi walczyć z konserwą i spuścizną poprzednich ideologii.