K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 1 Bazy danych i inżynieria oprogramowania Kazimierz Subieta Instytut Podstaw Informatyki.

Prezentacja na temat: "K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 1 Bazy danych i inżynieria oprogramowania Kazimierz Subieta Instytut Podstaw Informatyki."— Zapis prezentacji:

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

2 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 2 Model obiektowy ODMG Typy abstrakcyjne, typy konkretne, polimorfizm, wielo-dziedziczenie Ekstensje, klucze Obiekty, literale Kolekcje Związki Operacje Wyjątki Metadane Transakcje Plan wykładu (część 2)

3 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 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ę E A Typ B posiada ekstensję E B B jest podtypem A Zbiór E A zawiera zbiór E B (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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 5 Obiekty ost 25.11.03 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 6 Kolekcje (1) Kolekcje: zestawy elementów tego samego typu. Elementami mogą być obiekty, literale oraz kolekcje. Kolekcje: zestawy elementów tego samego typu. Elementami mogą być obiekty, literale oraz kolekcje. Set Zbiór elementów typu t; powtórzenia elementów są niedopuszczalne. Bag Wielo-zbiór elementów typu t; powtórzenia są dopuszczalne. List Sekwencja elementów typu t (dowolnie rozszerzalna lub skracalna) Array Tablica elementów typu t, dostęp poprzez indeks (będący l. całkowitą) Dictionary Zbiór par, gdzie klucz jest unikalny. collections Kolekcja są wyposażone w zestaw operacji: interface Collection: Object{ exceptionInvalidCollectionType{}; unsigned longcardinality(); booleanis_empty(); voidinsert_element( in any element); booleancontains_element( in any element); Iteratorcreate_iterator(in boolean stability);...}

7 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 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++. 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++. Operatory do przetwarzania kolekcji, np. Operatory do przetwarzania kolekcji, np. interface Set : Collection{ Setunion_with( in Set other ); Setintersection_with(in Set other ); Setdifference_with( in Set other ); boolean is_subset_of( in Set other ); boolean is_proper_subset_of( in Set other ); boolean is_superset_of( in Set other ); boolean is_proper_superset_of( in Set other ); }; 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 8 Literale Inaczej wartości. 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. literals long, short, unsigned long (ulong), unsigned short (ushort), float, double, boolean, octet, char (character), string, enum (enumeration) Typy atomowe literali (IDL): Np.: attribute enum Płeć{mężczyzna, kobieta} Kolekcje literali: set, bag, list, array, dictionary 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.

9 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 9 attribute struct Adres{string NazwaAkademika, string NrPokoju} AdresStudenta; interface Struct{ unsigned longsize(); void set_element( in any field, in any value ); anyget_element( in any field ); voidclear_element(in any field); Structcopy(); voiddelete(); }; struct Wyksztalcenie{ stringNazwaSzkoły; stringRodzajWykształcenia; unsigned shortRokUkończenia; }; Użycie deklaracji struktur

10 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 10 Deklaracje atrybutów interface Osoba{ attribute short Wiek; attribute string Nazwisko; attribute enum Płeć{mężczyzna, kobieta}; attribute Adres AdresDomowy; attribute set Telefony; attribute Departament Dept; }; Identyfikator obiektu Zbiór numerów telefonów 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 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 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. 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 {... relationship set prowadzi inverse Wykład:: jest_prowadzony_przez;... } interface Wykład {... relationship Profesor jest_prowadzony_przez; inverse Profesor::prowadzi;... } Profesor Wykład prowadzi jest_prowadzony_przez Liczność związku jest ustalona poprzez słowa kluczowe określające rodzaj kolekcji (set,bag,sequence)

12 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 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 {... attribute set 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 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). void ZmieńWykładowcę( in Profesor NowyWykładowca ) raises ( NieJestSpecjalistą ) Np. operacja dla typu Wykład: Dowolna operacja może mieć dowolne efekty uboczne. Semantyka operacji nie jest specyfikowana przez ODMG. Dowolna operacja może mieć dowolne efekty uboczne. Semantyka operacji nie jest specyfikowana przez ODMG.

14 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 14 Wyjątki ost 2.12.03 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 ). exceptions 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 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 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)..... Charakterystyki meta-bazy Są to najczęściej klasy powiązane związkami asocjacyjnymi

16 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 8, Folia 16 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). Model rozproszonych transakcji jest taki sam jak model standardu OMG oraz ISO XA. Model transakcji w ODMG obejmuje także wątki (threads) Transakcja jest obiektem o następującym interfejsie: interface Transaction { exceptionTransactionInProgress{}; exceptionTransactionNotInProgress{}; void begin() raises (TransactionInProgress); void commit() raises (TransactionNotInProgress); void abort() raises (TransactionNotInProgress); void checkpoint() raises (TransactionNotInProgress); voidjoin(); void leave(); boolean IsOpen(); } Połączenie z aktualnie wykonywanym wątkiem Transakcje transactions Wprowadzenie modyfikacji do bazy danych bez zwalniania zamków