Bazy danych i inżynieria oprogramowania

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łaTechnik Komputerowych, Warszawa

Wykład 8:

Wprowadzenie do standardu ODMG, część 2: Model obiektowy


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)


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ć.


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.

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.

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.

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.


ObiektyAspekty obiektu: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”.


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<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.

collections

Kolekcja są wyposażone w zestaw operacji: 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); ... }


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{ Set union_with( in Set other ); Set intersection_with(in Set other ); Set difference_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.


LiteraleInaczej wartości.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<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.


attribute struct Adres{string NazwaAkademika, string NrPokoju} AdresStudenta;

interface Struct{ unsigned long size(); void set_element( in any field, in any value ); any get_element( in any field ); void clear_element(in any field); Struct copy(); void delete();};

struct Wyksztalcenie{ string NazwaSzkoły; string RodzajWykształcenia; unsigned short RokUkończenia;};

Użycie deklaracji struktur


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;};

Identyfikator obiektuZbió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.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.


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<Wykład> 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)

Liczność związku jest ustalona poprzez słowa kluczowe określające rodzaj kolekcji (set,bag,sequence)


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:Inny sposób deklarowania związku - poprzez referencje lub wskaźniki:

interface Student { ... attribute set<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ń.


Operacje

Operacje są inną charakterystyką typu, której zadaniem jest odwzorowanie zachowania się obiektów. Operacje określa się poprzez podanie ich sygnatur.

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).

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.


WyjątkiOperacje 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 ) .

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: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.


MetadaneODMG 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 RepositoryODL 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łyOperacjeWyjątkiWłasności (atrybuty i związki)Typy (interfejsy, kolekcje, typy konstruowane).....

Charakterystyki meta-bazyCharakterystyki meta-bazy Są to najczęściej klasy powiązane związkami asocjacyjnymi


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 { 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();}

Połączenie z aktualnie wykonywanym wątkiem

Transakcjetransactions

Wprowadzenie modyfikacji do bazy danych bez zwalniania zamków

Bazy danych i inżynieria oprogramowania

Documents

Transcript of Bazy danych i inżynieria oprogramowania