Obiektowe bazy danych Micha Gryglicki Rys historyczny 1

Obiektowe bazy danych Michał Gryglicki

Rys historyczny (1) • wczesne 1980 -te – Orion Research Project w Microelectronics and Computer Technology Corporation (twórca Won Kim). Wyewoluował z tego Versant. • późne 1980 -te – Pierwsza fala produktów komercyjnych: - Graphael (później Matisse) oparty na języku Lisp - Gem. Stone w Servo-Logic (później Gem. Stone Systems) - O 2 w INRIA (Francja) (twórca Francois Bencilhon również z MCC) - Vbase w Ontologic (twórca Tom Atwood) wspiera własny język COP (C Object Processor). Później Ontologic zamieniło się w ONTOS, a COP został zastąpiony prze C++. - Object Design w Object Store (twórca Tom Atwood po odejściu z Ontologic)

Rys historyczny (2) • 1991 – ODMG zainicjowany przez Rick Cattell (Sun. Soft) razem z 5 największymi twórcami OODMBS. (w 1990 -tych pracuje z komitetem X 3 H 2 (ANSI Database Committee) nad ogólnym językiem zapytań, ale gdy nie przynosi to wyników ODMG skupia się na OQL (Object Query Language) • 1993 – standard ODMG 1. 0 • 1995 - OODBMS Manifesto definiuje OODBMS podając jego cechy w trzech grupach: Obowiązkowe (omówione dalej), Opcjonalne, Otwarte dla twórców (wybór) • 2001 – standard ODMG 3. 0 • 2004 - open source (db 4 o) ob 4 o implementuje Native Queries jako obiektowy dostęp do danych, w którym zapytania do bazy wyrażane są bezpośrednio w odpowiednim języku programowania (Java/C#)

Model relacyjny (MR) - podstawy • Baza danych składa się z prostokątnych tablic, każda o określonej liczbie kolumn i dowolnej liczbie wierszy. Takie tablice są określane jako relacje. Wiersz relacji jest nazywany krotką. • Relacje i ich kolumny posiadają nazwy. Nazwy kolumn są określane jako atrybuty. • Elementy krotek są atomowe (niepodzielne) i są bezpośrednio wartościami. Niedozwolone jest tworzenie wskaźników prowadzących do innych krotek. Niedozwolone jest, aby element krotki był zbiorem wartości (1 NF). • Każda relacja posiada wyróżniony atrybut lub grupę atrybutów określoną jako klucz. Wartość klucza w unikatowy sposób identyfikuje krotkę relacji. Jakakolwiek inna identyfikacja krotki (np. wewnętrzny identyfikator) jest niewidoczna dla użytkownika. • Manipulacja relacjami odbywa się w sposób makroskopowy przy pomocy operatorów algebry relacji lub innego tego rodzaju języka. Przetwarzanie “krotka po krotce” jest niedozwolone.

MR– niezgodność impedancji (1) • SQL – zapytania SELECT, język definicji danych, język manipulacji danymi SQL nie jest pełnym językiem programowania, więc wymaga: - zanurzenia zdań SQL w uniwersalny język programowania - zdań pośredniczących, które umożliwiają takie zanurzenie • Konsekwencją połączenia dwóch różnych języków jest niekorzystny efekt określany jako niezgodność impedancji, czyli niezgodność w zakresie: - Składni: programista musi w jednym tekście programu używać dwóch stylów językowych i przestrzegać reguł dwóch różnych gramatyk - Systemu typów: język zapytań operuje na typach zdefiniowanych w schemacie bazy danych, m. in. relacjach, natomiast język programowania posiada zwykle odmienny system typów, w którym nie występuje typ relacja. - Semantyki i paradygmatów języków: język zapytań bazuje na stylu deklaracyjnym (co wyszukać, a nie jak) podczas gdy języki programowania bazują na stylu imperatywnym (jak zrobić, a nie co).

MR– niezgodność impedancji (2) - Faz i mechanizmów wiązania: języki zapytań są oparte o późne wiązanie (są interpretowane) podczas gdy języki programowania zakładają wczesne wiązanie (podczas kompilacji i konsolidacji). Stwarza to problemy m. in. dla programów odpluskwiających. - Przestrzeni nazw i reguł zakresu: język zapytań i język programowania posiadają własne przestrzenie nazw, które mogą zawierać identyczne nazwy o różnych znaczeniach. Odwzorowania pomiędzy przestrzeniami nazw wymagają dodatkowych środków syntaktycznych i semantycznych. Przestrzeń nazw języka programowania jest zbudowana hierarchicznie i podlega regułom zakresu opartym o zasadę stosu. Te reguły są ignorowane przez język zapytań powodując wiele trudności. - Schematów iteracyjnych: w języku zapytań iteracje są wtopione w semantykę operatorów takich jak selekcja, projekcja i złączenie. W języku programowania iteracje muszą być organizowane explicite przy pomocy pętli for, while, repeat lub innych. Przetwarzanie wyników zapytań przy pomocy języka programowania wymaga specjalnych udogodnień takich jak kursory i iteratory.

MR– niezgodność modelu pojęciowego i relacyjnego (1) Mentalna percepcja świata rzeczywistego Model Pojęciowy (encja-związek) Schemat relacyjnej struktury danych Model encja-związek stara się odwzorować świat rzeczywisty, lecz nie może być bezpośrednio zaimplementowany, gdyż relacyjna baza danych na to nie pozwala. W rezultacie: - schemat struktury danych gubi znaczną część semantyki danych, - użytkownik musi explicite w zdaniach SQL odtwarzać semantykę, co zwiększa ich złożoność i powoduje wzrost czasów wykonania.

MR– niezgodność modelu pojęciowego i relacyjnego (2) Departament Nr. D Nazwa. D Lokacja * Zatrudnia Pracownik Pracuje_w Nr. Prac Zawód * Wypłaty * Szef Departament( Nr. D, Nazwa. D ) Lokacja( Nr. Lokacji, Nazwa. Lok, Nr. D ) Szef( Nr. D, Nr. Prac) Pracownik( Nr. Prac, Nr. Osoby) Prac. Dept( Nr. Prac, Nr. D) Zawód( Id. Zawodu, Nazwa. Zawodu, Nr. Prac ) Wypłata ( Id. Wypłaty, Wysokość, Nr. Prac ) Osoba( Nr. Osoby, Nazwisko, Rok. Urodz ) Adres( Nr. Adresu, Miejsce, Nr. Osoby ) Mama( Nr. Osoby, Nr. Osoby ) Tata( Nr. Osoby, Nr. Osoby ) Osoba Nazwisko Adres * Rok. Urodz Mama Dziecko Tata - Czytelna pojęciowa struktura zamieniła się na 11 schematów relacji - Pojawiły się nowe atrybuty klucze - Semantyka wyrażona poprzez liczności została częściowo zgubiona - Semantyka dziedziczenia została zgubiona

MR– wady • niezgodność impedancji. • niezgodność pomiędzy modelem pojęciowym i relacyjnym, która gubi część schematu i narzuca dodatkowy koszt na jego odzyskanie • (skomplikowane zapytania SQL) • brak złożonych obiektów (np. dane multimedialne); informacje o pojęciach wyróżnialnych i manipulowalnych w rzeczywistości są rozproszone w krotkach wielu tablic • tylko 2 z góry ustalone konstruktory: krotka i zbiór (relacja) służące do strukturyzacji informacji (brak agregacji, specjalizacji itp. ) • brak wyspecjalizowanych środków do realizacji powiązań pomiędzy danymi • brak środków do przechowywania danych proceduralnych. Wszelkie informacje wykraczające poza strukturę relacyjną (perspektywy, procedury bazy danych, BLOBy, aktywne reguły, . . . ) są implementowane ad hoc.

ODB - intuicja • Relacyjna baza danych kota: • Obiektowa baza danych kota:

ODB – co nam dały? • Zmniejszenie dystansu pomiędzy fazami analizy, projektowania i implementacji • Zwiększenie poziomu abstrakcji w myśleniu programistów i użytkowników (uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości a myśleniem o danych i procesach, które zachodzą na danych) • Uwzględnienie informacji proceduralnej (metody) • Stworzenie nowego potencjału dla ponownego użycia • Docelowa tendencja - ortogonalna trwałość: - Programista podczas programowania nie musi nic wiedzieć o bazie danych, operując na jej obiektach tak jak na obiektach/zmiennych programu. - Baza danych powinna być niewidoczna (przezroczysta)

ODBMS = DBMS + ? 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 Ä Powiązania pomiędzy obiektami Ä Hermetyzacja, interfejsy do obiektów Ä Typy i/lub klasy oraz hierarchia dziedziczenia Ä Przełanianie/przeciążanie/późne wiązanie Ä Kompletność obliczeniowa (pragmatyczna)

ODB – Manifest M. Atkinson, F. Bancilhon, D. De. Witt, K. Dittrich, D. Maier, S. Zdonik • Cechy obowiązkowe – złożone obiekty – tożsamość obiektów – enkapsulacja – dziedziczenie – typy lub klasy – rozszerzalność – zapytania ad hoc – kompletność obliczeniowa – trwałość – współbieżność i odtwarzanie • Cechy opcjonalne – – wielokrotne dziedziczenie kontrola typów rozproszenie zarządzanie wersjami • Cechy otwarte – – paradygmat programowania metody reprezentacji obiektów system typów jednolitość (zgodność)

ODB – model firmy (przykład) Firma: [ Oddział: [ Adres: [ Nazwa : String, Ulica : String, Centrala : Adres, Biuro : Adres, Miejscowość : String ] Oddziały: { Oddział }, Kierownik : Pracownik, Dyrektor: Pracownik ] Pracownicy : { Pracownik } ] Osoba: [ Pracownik is-a Osoba: [ Pojazd: [ Nazwisko : String, Kwalifikacje: { String } Model : String, Wiek : Integer, Wynagrodzenie : Integer Producent : Firma, Miejsce. Zam : Adres, Rodzina : { Osoba } ] Kolor : String ] Tabor : { Pojazd } ] […] typ krotkowy {…} typ zbiorowy

ODB – obiekty złożone (1) • konstruktory: krotka, zbiór, wielozbiór, lista, tabela, które można stosować do obiektów w dowolny sposób • operatory działające na całych obiektach jak i na ich części • składnikami obiektów złożonych mogą być inne obiekty lub odwołania (agregacja). Zaletą agregacji jest możliwość powtórnego użycia informacji przez współdzielenie obiektów • Przykład: nie musimy już modelować przynależności Pracowników do Oddzałów, przez wprowadzanie dodatkowej relacji Prac. Oddział. Wystarczy, że obiekt oddział posiada jako swoją składową zbiór powiązań z odpowiednimi pracownikami; • schemat obiektowej bazy danych, dość wiernie oddaje nam modelowaną rzeczywistość

ODB – obiekty złożone (2)

ODB – identyfikator obiektu • każdy obiekt posiada tożsamość, niezależnie od swoich rzeczywistych wartości • aby to zapewnić dla każdego obiektu system utrzymuje identyfikator obiektu niezmienny w całym cyklu życia obiektu • nie ma konieczności szukania klucza, ani wprowadzania żadnych dodatkowych sztucznych atrybutów • dodatkowo obsługa identyfikatorów umożliwia dzielenie obiektów (agregację), tzn. dwa różne obiekty, mogą mieć wspólne podobiekty jako składowe • zwalnia programistę z problemu definiowania kluczy głównych, kluczy obcych, wprowadzania sztucznych identyfikatorów do relacji

ODB – typy i klasy • pojęcia zapożyczone z języków programowani i odzwierciedlają różnicę między wartością a obiektem na poziomie abstrakcji • typ = niezmienny w czasie opis zbioru możliwie złożonych wartości; może być typem podstawowym (np. integer, real) lub strukturalnym; opisuje strukturalną część klasy • klasa = zamyka w sobie strukturę i specyficzne zachowanie; związane z czasem: może być do niej przypisany zbiór obiektów istniejących w danym momencie (instancji klasy) • w niektórych sytuacjach będziemy chcieli traktować nazwę klasy jako Klasa, a w innych jako nazwa Typu

ODB – dziedziczenie • związek specjalizacji definiujący klasy, które są powiązane z innymi klasami relacją „Is. A” • jeżeli jeden obiekt jest określony dokładniej niż drugi, to ma on zwykle własności, które odnoszą się do obiektu bardziej ogólnego np. obiekt pracownicy różni się od obiektu osoby tym, że posiada m. in. atrybut wynagrodzenie • dzięki temu mechanizmowi obiekty dziedziczą również zachowania

ODB – cechy języka (1) • enkapsulacja – służy tak jak w językach programowania wyższego poziomu, rozróżnieniu specyfikacji od implementacji operacji; utworzenie abstrakcji ukrywającej szczegóły dotyczące implementacji – każda klasa zawiera przypisany do niej zbiór zachowań, a świat zewnętrzny widzi tylko zbiór sygnatur, wskazujących nazwy komunikatów, które mogą być wysłane do klasy, wraz z typami argumentów i wyniku – uzyskujemy w ten sposób logiczną niezależność danych, ponieważ implementacja metody może być zmienna bez zmiany interfejsu

ODB – cechy języka (2) • przeciążanie, przesyłanie, późne wiązanie – ta sama metoda, ale z różną implementacją może być zdefiniowana kilka razy w hierarchii klas, więc nazwy metod mogą być przeciążone – aby była wywoływana metoda najdokładniejsza (przesłoniła pozostałe) musi być zrealizowane późne wiązanie implementacji do wywołań metody, czyli odsunięcie decyzji co ma być wykonane do czasu uruchomienia • zapytania ad hoc – chcemy mieć język, o możliwie wysokim poziomie abstrakcji (nawet przy ograniczonej możliwości obliczeniowej), przy pomocy którego będziemy mogli wykonywać zapytania do bazy danych (niekoniecznie z poziomu języka programowania)

ODB – cechy języka • kompletność obliczeniowa – konwencjonalne bazy danych, zwłaszcza z powodu efektywności, mają zwykle ograniczone możliwości obliczeniowe – w systemach obiektowych poprzez powiązanie metod z klasami można określić połączenie z językiem programowania (zwłaszcza jeśli do implementacji metody jest użyty taki język jak Smalltalk, C++, Java) • rozszerzalność – odb dostarczają zbiór wstępnie zdefiniowanych typów i konstruktorów, ale umożliwia wykorzystanie dowolnych napisanych później klas jako typów i konstruktorów kolejnych klas – rozszerzalność poziomu pojęciowego, ale również na poziomie wewnętrznym np. wprowadzenie nowej struktury pamięci do przechowywania danych multimedialnych

ODB – własności SZBD • trwałość • definiowanie trwałych klas (jawnie przez programistę) • trwałe tworzenie wystąpień obiektów (nie klas) • trwałość oparta na osiągalności trwałych obiektów (obiekt jest trwały, gdy jest przedmiotem odwołania trwałych obiektów) – ortogonalna, w tym sensie, że każdy obiekt, niezależnie od swojego typu, może stać się trwałym – możliwość rozróżnienia obiektów trwałych od ulotnych, dla programisty pełna przezroczystość – niezależna od nośnika, tzn. tak aby nie były potrzebne żadne jawne operacje odczytu/zapisu – możliwość zapewnienia trwałości obiektu tylko na z góry określony czas • kontrola wielu użytkowników – transakcje przetwarzane zgodnie z zasadą ACID (metody wywoływanie podczas transakcji mogą powodować powstawanie skomplikowanych zagnieżdżeń) • odtwarzanie – dzienniki itp.

Języki ODB – wymagania ogólne • uniwersalność – nie projektowany pod określony cel • opisowość – wysoki poziom abstrakcji (obsługa dostępu ukonkretnionego na zbiory) • optymalizowalność – reguły i strategie optymalizacyjne • zamkniętość – możliwość opisania każdego wyniku wyrażenia języka w ramach danego modelu danych lub obiektu (wykorzystanie wyników zapytania jako wejścia w następnym) • kompletność – każde pojęcie rozpatrywanego modelu danych musi mieć odpowiednik w języku • rozszerzalność – obsługa typów zdefiniowanych przez użytkownika jak i system

Języki ODB – przykład: model firmy Firma: [ Oddział: [ Adres: [ Nazwa : String, Ulica : String, Centrala : Adres, Biuro : Adres, Miejscowość : String ] Oddziały: { Oddział }, Kierownik : Pracownik, Dyrektor: Pracownik ] Pracownicy : { Pracownik } ] Osoba: [ Pracownik is-a Osoba: [ Pojazd: [ Nazwisko : String, Kwalifikacje: { String } Model : String, Wiek : Integer, Wynagrodzenie : Integer Producent : Firma, Miejsce. Zam : Adres, Rodzina : { Osoba } ] Kolor : String ] Tabor : { Pojazd } ] […] typ krotkowy {…} typ zbiorowy

Języki ODB • Podstawowy dostęp do obiektów – Identyfikatory pojazdów, dla których Model ma wartość Tipo select f from in Pojazd where Model = ‘Tipo’ – Wartości wszystkich atrybutów pojazdów: select * from Pojazd where Model = ‘Tipo’ • Dostęp do obiektów złożonych (np. utworzonych przez agregację) – Wynagrodzenie dyrektorów firm, których centrala mieści się w Rzymie select Dyrektor. Wynagrodzenie from Firma where Centrala. Miejscowość = ‘Rzym’ (wartość atrybutu Centrala jest identyfikatorem obiektu z klasy Adres; dostęp do jego atrybutów jest możliwy przy pomocy wyrażenia ścieżkowego – umożliwiają one nawigację po schemacie bd) (tak samo wyrażenie ścieżkowe może wystąpić w klauzuli select)

Języki ODB • Jawne złączenie (możliwość uzyskania złączeń nie zdefiniowanych w schemacie bd) – Osoby i pojazdy o nazwiskach identycznych z nazwiskiem dyrektora firmy, produkującej dany samochód select p, f from p in Osoba, f in Pojazd where p. Nazwisko = f. Producent. Dyrektor. Nazwisko (nazwisko zdefiniowane dla dyrektorów przez dziedziczenie) • Jednakowe traktowanie atrybutów i metod (zał, że istnieje logiczna metoda Zastępca z parametrem umożliwiającym sprawdzenie dla wszystkich kierowników, czy rozważany pracownik jest zastępcą) – Zastępcy kierowników select a 1, a 2 from a 1 in Pracownik, a 2 in Pracownik where a 1. Zastępca(a 2)

Języki ODB (zał, że istnieje metoda Wiek klasy Osoba) – Osoby w wieku powyżej 50 lat select * from Osoba where Wiek > 50 – Wiek osoby nazywającej się Peter Smith select Wiek from Osoba where Nazwisko = ‘Peter Smith’ • Dostęp do zbioru obiektów – Nadawanie nazw kolekcjom obiektów, np. Moja. Rodzina jako podzbiór obiektów Osoba – można go później stosować w dalszych zapytaniach) Moja. Rodzina : = select p from Osoba where Nazwisko = Moje. Nazwisko

Języki ODB – Producenci niebieskich pojazdów select Nazwa from (select Producent from Pojazd where Kolor = ‘niebieski’) – Liczba firm, w których wynagrodzenie dyrektorów przekracza 20000) select count(f) from f in Firma where Dyrektor in (select a from a in Pracownik where Wynagrodzenie > 20000) (atrybuty/metody w wyrażeniach ścieżkowych stają się problemem, gdy kilka takich atrybutów/metod pojawia się wy tym samym wyrażeniu) – Wynagrodzenie pracowników w oddziałach firmy select f. Oddziały. Pracownicy. Wynagrodzenie from f in Firma Rozwinięcie wyrażenia ścieżkowego: - Dla danej firmy f, wyznaczamy zbiór oddziałów - Aby uniknąć błędu typu, nie możemy zastosować atrybutu Pracownicy (definiowany tylko dla jednego Oddziału) do wyniku f. Oddziały (zbiór)

Języki ODB - Jeśli zastosujemy atrybut Pracownicy do każdego elementu zbioru f. Oddziały, to otrzymamy zbiór zbiorów f. Oddziały. Pracownicy - Znowu próba zastosowania atrybutu Wynagrodzenie do f. Oddziały. Pracownicy da błąd typu Rozwiązania tych problemów: 1. jawne usunięcie struktury zbioru tam, gdzie są spodziewane pojedyncze wartości, dlatego końcowy wynik poprzedniego zapytania, dla każdej firmy f da zbiór wynagrodzeń pracowników w tej firmie, a ponieważ wyrażenie ścieżkowe musi być zastosowane do każdej firmy, zagnieżdżone zbiory będą musiały być znowu usunięty i wynikiem ostatecznym będzie jeden zbiór wynagrodzeń pracowników ze wszystkich firm 2. Dodanie operatora spłaszczenia (flatten): flatten(select flatten(f. Oddziały). Pracownicy). Wynagrodzenie from f in firm)

Języki ODB • Wpływ hierarchii klas – Pracownicy i pozostałe Osoby w wieku ponad 50 lat select * from Osoba where Wiek > 50 – Osoby w wieku ponad 50 lat nie będące pracownikami select * from p in Osoba where Wiek > 50 and p not in Pracownik Pierwsze zapytanie daje zbiór heterogeniczny (zawiera obiekty różnych typów) Osób i Pracowników. W klasie Pracownik jest więcej atrybutów niż w klasie Osoba, więc wykorzystanie wyników tego zapytania w dalszym przetwarzaniu może prowadzić do błędów typu. Jednym z rozwiązań tego problemu jest stwierdzenie, że wszystkie obiekty w zbiorze wynikowym mają wszystkie atrybuty (o wartości null jeśli nie są zdefiniowane inaczej) -> problem wartości pustych! Innym, że obiekty zbioru heterogenicznego mogą być reprezentowane tylko przez swoje identyfikatory -> niezamierzony wynik zapytania (wymaga dalszego przetwarzania)

Języki ODB • Generowanie nowych klas – Przez odpowiednie konstrukcje językowe lub dynamicznie przy pomocy zapytań – Perspektywa, w której osoba, ich wartości dotyczące nazwiska oraz pojazdy wyprodukowane przez Forda są powiązane tak, że dla każdej krotki nazwisko osoby odpowiada nazwisku dyrektora firmy. create class K as select p, p. Nazwisko, f from p in Osoba, f in Pojazd where f. Producent. Nazwa = ‘Ford’ and p. Nazwisko = f. Producent. Dyrektor. Nazwisko – Wynik typu: { [ p: Osoba, Nazwisko: String, f: Pojazd ] } Należy rozróżnić sytuację, gdy wynik zapytania ma zawierać nowe obiekty lub nie.

Języki ODB – Zgodnie z perspektywami relacyjnymi jest uzasadnione niewprowadzanie identyfikatorów nowych obiektów przez perspektywy, gdyż stanowią one dane i obiekty pochodne – Dopuszczalne jest również zdefiniowanie perspektywy generującej obiekty w celu umożliwienia np. dziedziczenia na obiektach w perspektywie – Problem dynamicznego generowania obiektów: w jaki sposób nowa klasa ma być zintegrowana z istniejącą hierarchią klas? • Wyniki nie mają nadklasy • Jakieś zasady wstawiania w istniejącą hierarchii

Języki ODB • Bezpieczeństwo – Przykład pokazujący, że przedefiniowanie metod może być problematyczne – Interesuje nas metoda Zastępca odnosząca się do klasy Pracownik i Kierownik (Kierownik Is. A Pracownik) – Zatępca (Pracownik, Pracownik): Boolean a 1. Nominacja = a 2. Nominacja and not (a 1 == a 2) – Zastępca (Kierownik, Kierownik): Boolean m 1. Nominacja = m 2. Nominacja and m 1. Partia = m 2. Partia and not (m 1 == m 2) – Aby wskazać zastępców wszystkich pracowników select a 1, a 2 from a 1 in Pracownik, a 2 in Pracownik where a 1. Zastępca(a 2) Jednak to zapytanie jest bezpieczne! Jeśli a 1 odwołuje się do Pracownika, który jest Kierownikiem, to zostanie wywołana metoda klasy Kierownik, a jeśli dodatkowo a 2 odwołuje się do Pracownika, który nie jest Kierowikiem, to w metodzie Zastępca będzie odwołanie do niezdefiniowanego atrybutu a 2 Partia

Standardy • SQL 3 – krok w kierunku obiektowo-relacyjnych baz danych – typy wartościowe i typy obiektowe (konstruktory typu LIST, SET, MULTISET) – specjalizacja – hierarchia tabel jako forma specjalizacji relacji (podtabele) – funkcje SQL oraz funkcje zewnętrzne (wywołanie z wnętrza SELECT) • OMG (Object Management Group) – ORB (Object Request Broker), czyli pośrednik wymiany obiektów; interfejs między składnikami sprzętowymi i programowymi różnych producentów – CORBA (Common Object Request Broker Architecture) opisuje architekturę heterogenicznych i współdziałających systemów na poziomie interfejsu i obsługi

Standardy – Model obiektów: przeciwko jednemu modelowi obiektów, który musiałby być przyjęty przez wszystkich w celu zachowania zgodności z architekturą pośredników. Zamiast tego struktura dwuczęściowa: • model rdzeniowy – najmniejsza wspólna część, na którą mogliby się zgodzić członkowie konsorcjum; minimalne wymagania kwalifikujące model jako „technologia obiektowa”, czyli identyfikatory, typy, operacje, dziedziczenie, podtypy • składniki – rozszerzenia rdzenia, takie jak atrybuty, relacje, trwałość, zależności, transakcje, które w pewnych relacjach są potrzebne a w innych nie Kombinacja modelu rdzeniowego i kilku składników to profil, czyli model obiektów, który może być wykorzystywany w określonym obszarze zastosowań; Specyfikacje ODMG reprezentują specyficzny profil OMG

Standardy • ODMG-93 (Object Database Management Group) – ODMG = podgrupa OMG – Standard zawiera: • • model obiektów język definiowania obiektów (ODL) język zapytań (OQL) zorientowany na SQL, ale nie oparty na SQL powiązania do obiektowych języków programowania, m. in. C++, Smalltalk, Java – brak atrybutów o wartościach obiektowych, za to wprowadza atrybut związku, w celu wyrażenia odwołań między obiektami – OQL: • deklaratywny • optymalizowalny • niekompletny w sensie Turinga (nie jest uważany za pełny język programowania) • składnia podobna do SQL (select-from-where) • brak jawnych poleceń aktualizacji, są za to przewidziane odpowiednie metody aktualizacji • nie traktuje zbioru jako głównego środka zapytań, ale struktury krotkowe i listy

Algebry obiektowe • Operacje algebraiczne (możliwości): – zapytanie zawsze dostarczać zbiór wartości (wyjęte z obiektów) z pominięciem identyfikatora obiektu (duże ograniczenia; narusza kryterium domkniętości) – zapytanie dostarcza zbiór obiektów (wydaje się bardziej sensowne) • Operacje zachowujące obiekty – problem z umieszczeniem wyników zapytań w istniejącej hierarchii klas – selekcja – dostarcza podklasę danego argumentu o tym samym typie (trudności, gdy klasa ma już podklasy, ich porównanie z nową podklasą zależy od ich bieżącego stanu) Samochód Napęd Nadwozie #10 #20 Sedan #11 #21 Hatchback #12 #22 Sedan Napęd Nadwozie #10 #20 Sedan #12 #22 Sedan

Algebry obiektowe – projekcja – zbiór obiektów nie ulega zmianie, natomiast zmienia się typ wyniku, który jest podtypem typu argumentu Samochód Napęd Nadwozie #10 #20 Sedan #11 #21 Hatchback #12 #22 Sedan Napęd #10 #20 #11 #21 #12 #22 – różnica – np. Osoba – Pracownik, daje osoby nie będące Pracownikami; jest tworzona podklasa osób o tym samym typie co klasa Osoba – unia – Udziałowiec + Pracownik, daje heterogeniczny zbiór obiektów o typie, który jest podtypem zarówno Udziałowca jak i Pracownika • Przeciwdziałanie tym problemom – dopuszczenie istnienia kilku klas dla jednego typu (zgodne z językami programowani); zgodny z ODMG – zastosowanie operacji obiektotwórczych zamiast operacji zachowujących obiekty

Algebry obiektowe • Operacje obiektotwórcze – klasy wynikowe istnieją równolegle do wszystkich pozostałych klas w hierarchii, więc nie mogą dziedziczyć żadnej metody zdefiniowanej na klasach argumentów – przy tworzeniu klasy wynikowej wartości atrybutów są kopiowane, w szczególności są kopiowane odwołania do innych obiektów; np. przy projekcji instancji klasy Oddział kopiowane są odwołania do obiektów Adres; problemem jest stwierdzenie do jakiego stopnia jest to dopuszczalne – projekcja – klasa wynikowa zawiera nowe obiekty; jej typ jest nadtypem typu argumentu Samochód Napęd Nadwozie #110 #20 #10 #20 Sedan #111 #21 #11 #21 Hatchback #112 #22 #12 #22 Sedan

ODB vs RDB ZALETY ODB • ODB nie wymagają odtwarzania obiektów z tabel przy każdym do nich sięgnięciu • ODB wymagają mniej stronicowania, przez wrzucanie do pamięci tylko niezbędnych obiektów ODBMS Relational DBMS

ODB vs RDB • prostsza jest obsługa wersjonowania obiektów (przy zmianie jest tworzony nowy obiekt) • nawigacja po bazie danych jest prostsza i bardziej intuicyjna (poprzez wskaźniki między obiektami) • dziedziczenie zmniejsza nakład pracy na implementację • prostszy model danych bliższy rzeczywistemu światu • dobrze się sprawują w rozproszonych architekturach

ODB vs RDB • dobrze się sprawują w rozproszonych architekturach (obiekty mogą być dzielone pomiędzy procesy w rozproszonych środowiskach)

ODB vs RDB • dobre w aplikacjach, gdzie zależności między obiektami stanowią kluczową informację w bazie danych (np. powiązanie studentów z przedmiotami które studiują) • łatwa integracja z obiektowymi językami programowania (brak rozdźwięku między modelem aplikacji i bazy danych – jeden diagram UML)

ODB vs RDB WADY ODB • gorsze w aplikacjach, gdzie wartości obiektów stanowią kluczową informację w bazie danych • szybkość dostępu może być zmniejszona poprzez opóźnione wiązanie, które może powodować skomplikowane przeszukiwania po hierarchii klas • dużo gorsze standardy, z brakiem wspólnego OQL przyjętego przez wielu twórców ODB, takiego jak SQL dla RDB • brak jednolitej i spójnej formalnej semantyki obiektowej, takiej jak semantyka relacyjna • strata prostoty relacyjnych tabel • trudniejsze zmiany schematu bazy danych (być może wymagające aktualizacji wszystkich obiektów w bazie danych) • zapytania, które można wykonać ad-hoc są zależne od struktury bazy danych

Problem ODB • kiedy pojawiły się idea RDB programiści próbowali zbudować je tak, żeby działały dokładnie tak samo jak modele hierarchiczne, sieciowe, . . . Zmiana na bazy relacyjne przebiegła boleśnie i problematycznie, z wprowadzeniem nowych systemów, nowego języka SQL, oraz w ogóle nowego sposobu myślenia (wciąż rzutuje to na niechęć do zmiany na ODB) • dlatego powstały systemy obiektowo-relacyjne, ale w tych systemach obiekty są dodane jako dodatek, albo jako osłonka na bazę danych, zamiast integrować tę ideę z silnikiem bazy danych • Esther Dyson, "Using tables to store objects is like driving your car home and then disassembling it to put it in the garage. It can be assembled again in the morning, but one eventually asks whether this is the most efficient way to park a car. ” • obiektowo-relacyjne systemy są dobre do rozwiązania niektórych problemów baz danych, takich jak dane multimedialne

Problem ODB • ODBMS i RDBMS zostały stworzone do rozwiązywanie innych problemów „using a pure object database to store relational data is like keeping auto parts fully assembled into cars and disassembling the fleet when you need to count the screws you have in stock. ” • dlatego nie powinniśmy dopasowywać danych do bazy, ale system do danych, które chcemy przechowywać • Problemem ODB jest ich nazwa! Czyli nie object database, ale objectbase, ponieważ celem nie jest przechowywanie i manipulacja danymi przy pomocy obiektów, ale przechowywanie i manipulacja obiektami

Przykłady • O 2 firmy O 2 Technology – architektura klient-serwer • O 2 Engine (trzon), system niezależnej od języka bazy obiektów, która obsługuje model obiektów O 2 i administrację schematu • O 2 Look, graficzne narzędzie do tworzenia, prezentacji i edycji obiektów bazy danych • O 2 SQL, język zapytań podobny do SQL – nie tworzy nowych obiektów (wynikiem są wartości lub obiekty istniejące w bd) – nie przestrzega zasady enkapsulacji (umożliwia wolny dostęp do wnętrzna obiektu) • O 2 Tools, środowisko programowania z graficzną przeglądarką, edytorami, debugerem i dokumentacją schematu • O 2 C, język programowania bazy danych, reprezentujący nadzbiór C • interfejsy języka programowania umożliwiające dostęp do baz danych O 2 z innych języków jak C++ • Gem. Stone firmy Gem. Stone System Inc. – Łączy pojęcia języka obiektowego Smalltalk z funkcjonalnością systemu baz danych

Przykłady – obsługuje duże kolekcje nawet dużych obiektów (1 obiekt do 1 GB) – dynamiczne tworzenie i zmienianie metod – jednolity język definiowania i manipulowania danymi: Gem. Stone Smalltalk jest pochdnym języka Smalltalk-80 – przy pisaniu programów aplikacyjnych mogą być również wykorzystywane języki C, C++ – może być powiązany z bazami danych SQL za pomocą bram – Zapewnia wieloużytkownikowe środowisko z mechanizmami ochrony i autoryzacji, zarządzania indeksami i klastrami dla złożonych obiektów – architektura klient-serwer: • proces serwera Gem – wykonują metody i oszacowywują zapytania; zawiera pamięć podręczną obiektów; klienci łączą się z tymi procesami • proces nadzoru Stone – przydziela identyfikatory obiektów, koordynuje transakcje, obsługuje sytuacje błędne – przykład wyszukiwania: Pracownicy z działu badań | szukaj. Prac : = Prac select: [: p | p. Dział = ‘Badania’ ]. szukaj. Prac jako. Tabela.

Przykłady • Object. Store – rozszerzenie obiektowych języków programowania w celu objęcia funkcjonalności bazy danych (oparty na C++) – model danych jest w zasadzie modelem obiektów w C++ – architektura serwera stron (tzn. obiekty są na serwerze, ale wszystkie obliczenia, włącznie z pamięcią podręczną obiektów obsługuje aplikacja kliencka – rozszerza bibliotekę klas o klasę odpowiadającą kolekcjom z podklasami dla zbiorów, wielozbiorów, list, tabel; oraz relacje dwukierunkowe class pracownik { public: string Nazwisko; int Wynagrodzenie; Oddział * Prac. Oddział inverse_member Oddział : : Pracownicy; };

$Przykłady class Pracownik { public: string Nazwisko; int Wynagrodzenie; Oddział * Prac. Oddział inverse_member$

Przykłady class Pracownik { public: string Nazwisko; int Wynagrodzenie; Oddział * Prac. Oddział inverse_member Oddział : : Pracownicy; }; Prac. Oddział – atrybut typu referencyjnego klasy Oddział; - zdefiniowany jako atrybut zwrotny; - częścią dopełniającą jest wielowartościowy atrybut Pracownicy, reprezentujący relację między Oddziałem i Pracownikiem

Bibliografia • www. odbms. org • www. odmg. org • Georg Lause, Gottfied Vossen „Obiektowe bazy danych” • www. ipipan. waw. pl/~subieta/ • www. google. pl