Bazy danych i inżynieria oprogramowania

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

2. Plan wykładu (część 2) Model obiektowy ODMG • Typy abstrakcyjne, typy konkretne, polimorfizm, wielo-dziedziczenie • Ekstensje, klucze • Obiekty, literale • Kolekcje • Związki • Operacje • Wyjątki • Metadane • Transakcje

3. Typy abstrakcyjne, typy konkretne, polimorfizm, wielo-dziedziczenie Typ abstrakcyjny (abstract type): Typ definiujący własności (atrybuty, operacje) dziedziczone przez jej podklasy, ale nie posiadający bezpośrednich wystąpień obiektów. Typ abstrakcyjny może oczywiście posiadać wystąpienia pośrednie. Typ konkretny (concrete type): może posiadać bezpośrednie wystąpienia obiektów. ODMG nie robi różnicy w specyfikacji typu abstrakcyjnego i konkretnego. Polimorfizm, przesłanianie (polymorphism, overriding): możliwość specjalizacji zachowania w ramach podtypów. Np. implementacja operacji ZarobekNetto może być różna dla obiektów Pracownik i dla obiektów Profesor (50% zwolnienia od podatku za pracę o charakterze twórczym). Wybór konkretnej metody następuje w momencie zainicjowania operacji na obiekcie, co wymaga późnego wiązania. Wielo-dziedziczenie: możliwość dziedziczenia z więcej niż jednego interfejsu interface PracującyStudent: Pracownik, Student {...} Aktualnie ODMG nie precyzuje środków rozstrzygania konfliktów nazw operacji dziedziczonych z różnych nadklas, oraz nie specyfikuje, co w takiej sytuacji robić.

4. Ekstensje, klucze extents, keys Ekstensja typu jest zestawem aktualnie istniejących obiektów danego typu. ODMG używa tego terminu dla oznaczenia specjalnej struktury danych skojarzonej z danym typem, która przechowuje wszystkich wystąpienia tego typu. Typ A posiada ekstensję EA Typ B posiada ekstensję EB B jest podtypem A Zbiór EA zawiera zbiór EB (jest to niestety pewne uproszczenie) W modelu relacyjnym każda deklaracja typu jest obowiązkowo kojarzona z jego ekstensją (deklaracja relacji jest kojarzona z samą relacją). Ta własność jest często krytykowana. W ODMG projektant bazy danych może zadecydować, czy deklarowany typ ma być skojarzony z ekstensją, czy też nie. Klucz: atrybut lub zestaw atrybutów, których wartości identyfikują obiekt w sposób unikalny. ODMG nie zakłada konieczności deklarowania kluczy. Zadeklarowanie unikalnego klucza wymaga wcześniejszego zadeklarowania ekstensji.

5. Obiekty Aspekty obiektu: Identyfikator, który jest używany przez OSZBD w celu odróżnienia obiektu od innych obiektów oraz w celu odszukania obiektu. Indentyfikatory są wewnętrzne (nieczytelne; różnica z kluczami pierwotnymi w modelu relacyjnym) i unikalne w ramach jednego składu obiektów (storage domain). Literale nie mają identyfikatorów; np. liczba 3.14 lub ciąg znaków “ala ma kota”. Obiekty mające identyfikatory są zmienialne (mutable); literale są niezmienialne (immutable). Nazwa, przeznaczona dla wygodnej identyfikacji obiektu przez programistów lub użytkowników. Nazwa obiektu ma “zewnętrzną” semantykę dla użytkownika. Obiekt może mieć wiele nazw (ale zwykle ma jedną). Zakresem unikalności nazw jest cała baza danych. Możliwe jest tworzenie hierarchicznych przestrzeni nazw oraz przestrzeni obejmujących wiele baz danych. Tworzenie, odnoszące się do sposobu w jaki obiekty są tworzone przez programistę. Obiekty są tworzone przez operację new, umieszczoną w interfejsie ObjectFactory. Czas życia, określający rodzaj i sposób zarządzania pamięcią użytą do przechowania obiektu. Rozróżnia się obiekty ulotne (transient) oraz trwałe (persistent). Ten sam typ może określać ulotne i trwałe obiekty. Struktura, ustalająca czy obiekt jest “atomowy” czy też złożony z innych obiektów. Obiekty złożone z innych obiektów są określane jako “kolekcje”.

6. Kolekcje (1) collections Kolekcje: zestawy elementów tego samego typu. Elementami mogą być obiekty, literale oraz kolekcje. Set<t> Zbiór elementów typu t; powtórzenia elementów są niedopuszczalne. Bag<t> Wielo-zbiór elementów typu t; powtórzenia są dopuszczalne. List<t> Sekwencja elementów typu t (dowolnie rozszerzalna lub skracalna) Array<t> Tablica elementów typu t, dostęp poprzez indeks (będący l. całkowitą) Dictionary<t,v> Zbiór par <klucz,wartość>, gdzie klucz jest unikalny. Kolekcja są wyposażone w zestaw operacji: interface Collection: Object{ exception InvalidCollectionType{}; unsigned long cardinality(); boolean is_empty(); void insert_element( in any element); void insert_element( in any element); boolean contains_element( in any element); Iterator create_iterator( in boolean stability); ... }

7. Kolekcje (2) Iterator: mechanizm sekwencyjnego obiegu elementów kolekcji. Stabilność iteratora: usunięcie lub dodanie elementu do kolekcji w trakcie obiegu nie zakłóca spójności przetwarzania. Iteratory “niestabilne” - silny wpływ filozofii C++. interface Set : Collection{ Set union_with( in Setother ); Set intersection_with(in Setother ); Set difference_with( in Setother ); boolean is_subset_of( in Setother ); boolean is_proper_subset_of( in Setother ); boolean is_superset_of( in Setother ); boolean is_proper_superset_of( in Setother ); }; Operatory do przetwarzania kolekcji, np. Kolekcje takie jak Bag,List, etc. mają szereg dodatkowych operatorów, np. sumę wielozbiorów, konkatenację, itd. Pojęcie kolekcji w ODMG budzi wiele wątpliwości; jest to własność zdefiniowana dość słabo, z wieloma semantycznymi niedomówieniami i niekonsekwencjami.

8. Literale literals Inaczej wartości. long, short, unsigned long (ulong), unsigned short (ushort), float, double, boolean, octet, char (character), string, enum (enumeration) Typy atomowe literali (IDL): Np.: attributeenum Płeć{mężczyzna, kobieta} Kolekcje literali: set<t>, bag<t>, list<t>, array<t>, dictionary<t,v> Strukturalne literale : Date, Interval, Time, Timestamp (różne konwencje wartości odnoszących się do czasu) Struktury definiowane przez użytkownika: struct - generator struktur (składnia C/C++) Struktury mogą być dowolnie kombinowane, np. struktury zbiorów, zbiory struktur, tablica struktur, itd. Pojęcie “literala” plącze różne byty: element leksykalny programu oznaczający stałą, niezmienialny obiekt (stała w programie), wartość atrybutu obiektu oraz wartość zwracaną przez wyrażenie lub funkcję. Utożsamienie tych bytów prowadzi do nieporozumień i niespójności semantycznych.

9. Użycie deklaracji struktur attribute struct Adres{string NazwaAkademika, string NrPokoju}AdresStudenta; interface Struct{ unsignedlong size(); void set_element( inany field, inany value ); any get_element( inany field ); void clear_element(inany field); Struct copy(); void delete(); }; struct Wyksztalcenie{ string NazwaSzkoły; string RodzajWykształcenia; unsignedshort RokUkończenia; };

10. Deklaracje atrybutów interface Osoba{ attribute short Wiek; attribute string Nazwisko; attribute enum Płeć{mężczyzna, kobieta}; attribute Adres AdresDomowy; attribute set<NrTelefonu> Telefony; attribute Departament Dept; }; Zbiór numerów telefonów Identyfikator obiektu Atrybut nie zawsze oznacza deklarację struktury danych. Niekiedy atrybut może być zaimplementowany jako metoda, np. atrybut Wiek zaimplementowany jako metoda obliczająca wiek z wartości DataUrodzenia. Atrybut nie jest obiektem i dlatego nie może mieć identyfikatora obiektu. Ostatnia własność jest kontrowersyjna: wiele atrybutów, np. multimedialne lub tzw. nieprzejrzyste (opaque) musi być obsługiwane przez własne metody, a wobec tego musi należeć do własnej klasy, czyli być obiektami. Innym powodem jest zasada relatywizmu obiektów, znacznie upraszczająca semantykę wszystkich funkcjonalności zdefiniowanych dla obiektów.

11. Związki(1) relationships • Związki mają bardzo podobny charakter jak w modelu encja-związek. • Są definiowane pomiędzy dwoma typami. • Podtrzymywane są wyłącznie związki binarne. • Liczność związku może być 1:1, 1:n, m:n. • Związek wyznacza ścieżkę przejścia (traversal path) w obie strony. interface Profesor { ... relationshipset<Wykład> prowadzi inverse Wykład:: jest_prowadzony_przez; ... } Profesor jest_prowadzony_przez prowadzi interface Wykład { ... relationship Profesor jest_prowadzony_przez; inverse Profesor::prowadzi; ... } Wykład Liczność związku jest ustalona poprzez słowa kluczowe określające rodzaj kolekcji (set,bag,sequence)

12. Związki(2) Zadeklarowanie związku oznacza, że system musi automatycznie podtrzymywać integralność odwołań (referential integrity). Jeżeli np. usunięty będzie obiekt Wykład, wówczas automatycznie są usuwane wszystkie ścieżki przejścia “prowadzi” prowadzące od obiektu Profesor do usuniętego obiektu. Związek jest więc czymś więcej niż wskaźnikiem lub zbiorem wskaźników. Inny sposób deklarowania związku - poprzez referencje lub wskaźniki: interface Student { ... attributeset<Wykład> zaliczone_wykłady; ... } W tym przypadku deklarowane jest także powiązanie “zaliczone_wykłady” (o liczności m:n) prowadzące od obiektów Student do obiektów Wykład; jednakże system jest zwolniony z obowiązku automatycznego podtrzymywania integralności odwołań. Wprowadzenie związków oraz wskaźników jako dwóch odrębnych bytów o podobnym przeznaczeniu i charakterze, lecz dość różnej semantyce jest bardzo kontrowersyjne, gdyż niepotrzebnie komplikuje model i prowadzi do nieporozumień.

13. Operacje Operacje są inną charakterystyką typu, której zadaniem jest odwzorowanie zachowania się obiektów. Operacje określa się poprzez podanie ich sygnatur. Sygnatura zawiera: • nazwę operacji • nazwy i typy jej argumentów • typ zwracanej wartości (może być void, co oznacza brak zwracanej wartości) • nazwy wyjątków (sygnałów błędów), które mogą być przez nią powodowane Nazwa operacji musi być unikalna w ramach typu, ale może być przeciążona (overloaded). W takim przypadku wybiera się operację z klasy najbardziej wyspecjalizowanej. Zakłada się dynamiczne wiązanie operacji (polimorfizm). Dowolna operacja może mieć dowolne efekty uboczne. Semantyka operacji nie jest specyfikowana przez ODMG. Np. operacja dla typu Wykład: void ZmieńWykładowcę( in Profesor NowyWykładowca ) raises ( NieJestSpecjalistą )

14. Wyjątki exceptions Operacje mogą powodować wyjątki, które mogą być dodatkowo wyposażone w informację o warunkach powstania wyjątku. Wyjątki są obiektami i posiadają swój interfejs (typu Exception lub pewnego podtypu typu Exception ) . Zasady sterowania wyjątkami: Programista deklaruje obsługę wyjątku (exception handler) dotyczącą wyjątku typu t wewnątrz pewnego zakresu s Operacja wewnątrz zakresu sn (zawartego w s) może podnieść (raise) wyjątek typu t. Ten sam skutek ma podniesienie wyjątku typu t1, gdzie t1 jest podtypem t. Wyjątek jest “przechwytywany” przez odpowiadającą mu obsługę wyjątku znajdującą się w najbardziej lokalnym zakresie. Stos środowisk (call stack) jest w takiej sytuacji zwijany aż do poziomu na którym znajduje się ta obsługa. Zwinięcie oznacza usunięcie wszystkich obiektów znajdujących się w zwijanych sekcjach stosu i zerwanie wszystkich transakcji zainicjowanych w zwijanych zakresach. Sterowanie jest przekazywane do w/w obsługi wyjątku t. Wewnątrz tej obsługi wyjątek może być “skonsumowany” (tj. usunięty ze środowiska) lub przekazany dalej, do bardziej szerokiego zakresu.

15. Metadane ODMG precyzuje model przechowywania i przeszukiwania metadanych, tj. schematu bazy danych i informacji o wszystkich typach i ich powiązaniach. Jest to bardzo ważne, gdyż dostęp do metadanych jest nieodzowny dla większości aplikacji, zaś różnice w dostępie do metadanych są podstawową przyczyną braku przenaszalności aplikacji (patrz SQL-92). ODL Schema Repository Obiektowa meta-baza danych Charakterystyki meta-bazy Są to najczęściej klasy powiązane związkami asocjacyjnymi Hierarchia nazw dla meta-obiektów (opis obiektu może być identyfikowany przez inną nazwę niż nazwa obiektu lub interfejsu) Meta-obiekty (opisy wszystkich obiektów znajdujących się w repozytorium) Moduły Operacje Wyjątki Własności (atrybuty i związki) Typy (interfejsy, kolekcje, typy konstruowane) .....

16. Transakcje transactions Programy używające trwałych obiektów są organizowane w transakcje posiadające własności ACID (atomicity, consistency, isolation, durability) i spełniające własność szeregowalności (serializability). Transakcje nie zajmują sie obiektami ulotnymi. Model transakcji jest tradycyjny, pesymistyczny (oparty na zamkach, locks). Transakcja jest obiektem o następującym interfejsie: interface Transaction { exception TransactionInProgress{}; exception TransactionNotInProgress{}; void begin() raises (TransactionInProgress); void commit() raises (TransactionNotInProgress); void abort() raises (TransactionNotInProgress); void checkpoint() raises (TransactionNotInProgress); void join(); void leave(); boolean IsOpen(); } Wprowadzenie modyfikacji do bazy danych bez zwalniania zamków Połączenie z aktualnie wykonywanym wątkiem Model rozproszonych transakcji jest taki sam jak model standardu OMG oraz ISO XA. Model transakcji w ODMG obejmuje także wątki (threads)