Bazy danych i inżynieria oprogramowania

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, 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 9:Wprowadzenie do standardu ODMG, część 3: ODL


Plan wykładu (część 3)

ODL - Object Definition Language

Założenia przyjęte przy projektowaniu ODL

ODL: BNF dla interfejsu

ODL: Atrybuty

ODL: Związki

ODL: Operacje

Przykłady w ODL

ODL: składnia górnego poziomu

Model ODMG i ODL - zalety i wady


ODL: Object Definition Language

Inaczej, język definiowania schematu obiektowej bazy danych.

Ustala na poziomie “logicznym” z jakich obiektów składa się baza danych, jak one są pogrupowane w klasy i jak są powiązane związkami asocjacyjnymi.

ODL jest wzorowany na języku IDL (Interface Definition Language) wg standardu CORBA.

Język definicji obiektów.

ODMG nie przewiduje standardowego języka manipulacji danymi opartego o ODL, prawdopodobnie z powodu świadomości trudności wylansowania nowego języka programowania. (Jest to chyba błąd.)


Założenia przyjęte przy projektowaniu ODL

• ODL powinien uwzględniać wszystkie konstrukcje modelu danych

• ODL nie jest pełnym językiem programowania lecz językiem specyfikacji sygnatur interefejsów

• ODL powinien być neutralny w stosunku do języków programowania (C++, Smalltalk, Java, ... )

• ODL powinien być kompatybilny z IDL wg OMG (kontrowersyjny styl C++)

• ODL powienien być rozszerzalny, nie tylko na przyszłościowe funkcjonalności, lecz także dla celów fizycznych optymalizacji (nie do końca jest jasne co ODMG przez to rozumie)

• ODL powinien być językiem użytecznym, posiadającym wartość dla rozwoju aplikacji oraz powinien być podtrzymywany przez wytwórców OSZBD w relatywnie krótkim czasie.


ODL - językowo-niezależny“Lingua franca” dla integracji systemów (STEP/Express, SQL3, CAD Framework Initiative,...)

STEP/Express SQL3 Inne

Językowo-niezależny ODL

C++ SQL3 Smalltalk Java Inne


ODL: BNF dla interfejsu

<dekl_interfejsu> ::= <nagłówek_interfejsu>[:<deklaracja_trwałości>]{[<ciało_interfejsu>]};

<deklaracja_trwałości> ::= persistent | transient

<nagłówek_interfejsu> ::= interface <identyfikator> [<specyfikacja_dziedziczenia>] [<lista_własności_typów>]

< lista_własności_typów > określa obecność ekstensji i kluczy, np.

interface Profesor : Osoba(extent profesorowie keys id_wydziału, nr_pesel): persistent

{... atrybuty...... związki ...... operacje ...

};


ODL: Atrybuty

<deklaracja atrybutu> ::= [readonly] attribute <typ_dziedziny> <nazwa_atrybutu> [<rozmiar_tablicy>]

<typ_dziedziny> ::= <spec_prostego_typu> | <typ_strukturalny> | <typ_przeliczeniowy>


{attribute char id_wydziału[6];attribute long nr_pesel;attribute Adres adres;attribute set<string> stopnie;... związki ...... operacje ...

};

Kontrowersyjna składnia...Brak relatywizmuobiektów....


ODL: Związki relationships<deklaracja_związku> ::= relationship <cel_ścieżki> <identyfikator>

inverse<ścieżka_odwrotna> [{order_by <lista_atrybutów>}]


{attribute char id_wydziału[6];attribute long nr_pesel;attribute Adres adres;attribute set<string> stopnie;relationship set<Student> opiekuje_się inverse Student::opiekun;relationship set<Asystent> zatrudnia inverse Asystent::pracuje_dla;relationship Wydział pracuje_na inverse Wydział::zatrudnia;... operacje ...

};

Brak związków ternarnych i o większej liczbie argumentów.Brak możliwości przypisania atrybutów do związków.(Różnica z Relationship Service OMG CORBA.) Może i dobrze...?


ODL: OperacjeZgodne ze specyfikacją OMG IDL.Definiowana jest wyłącznie specyfikacja operacji (sygnatura), ODMG nie zajmuje się (w zasadzie) jakimikolwiek środkami programowania operacji. (Szkoda...)

<dekl_operacji> ::= [oneway] <specyf_typu_op> <identyfikator>([<lista_parametrów>]) [<deklar_wyjątków>][<deklar_kontekstu>]

<specyf_typu_op> ::= <specyfikacja_typu_prostego> | void <lista_parametrów> ::= <dklr_parametru>|<lista_parametrów> , <dklr_parametru><dklr_parametru> ::= <atryb_parametru> <spec_typu_prostego> <deklarator><atryb_parametru> ::= in | out | inout<deklar_wyjątków> ::= raises (<lista_nazw>)<deklar_kontekstu> ::= context (<lista_stringów>)

Brak pełnej ortogonalności, np. parametrem operacji nie może być struktura i operacje nie mogą zwrócić struktury. (Ale - ciekawostka - parametrem operacji mogą być kolekcje, ale tylko wartości prostych, nie struktur. Być może jest to po prostu błąd w specyfikacji składni.)


Przykład w ODLinterface Profesor : Osoba

(extent profesorowie keys id_wydziału, nr_pesel): persistent

{attribute char id_wydziału[6];attribute long nr_pesel;attribute Adres adres;attribute set<string> stopnie;relationship set<Student> opiekuje_się inverse Student::opiekun;relationship set<Asystent> zatrudnia inverse Asystent::pracuje_dla;relationship Wydział pracuje_na inverse Wydział::zatrudnia;short Promuje( in string kogo ) raises (Nie_spełnia_warunków);

};


Schemat w ODL -reprezentacja graficzna

W notacji UML:

poprzedza

następuje_po

zawiera

jest_składowąma_asystenta

asystuje_w

zapisany_na

prowadzony_dla

prowadzony_przez

prowadzi

PracownikStudent

Osoba

KursStudent_asystent Profesor

Wykład

1..*

0..*

1..* 1..*

0..*

0..*

0..1


ODL- inny przykładinterface Osoba( extent osoby){

attribute string nazwisko_imię;attribute Date data_ur; attribute struct Adres{unsigned short nr, string ulica, string miasto} adres;relationship Osoba mąż_lub_żona inverse Osoba:: mąż_lub_żona;relationship set<Osoba> dzieci inverse Osoba::rodzice;relationship list<Osoba> rodzice inverse Osoba::dzieci order_by data_ur;void urodzenie(in string nazwisko_imię_ur);boolean ślub(in string nazw_imię_narzecz) raises (nie_ma_takiej_osoby);unsigned short daj_przodków (out set<Osoba> przodkowie)

raises (nie_ma_takiej_osoby);void zmiana_adresu(in string nowy_adres);

};

interface Miasto( extent miasta

key kod_miasta){

attribute unsigned short kod_miasta;attribute string nazwa;attribute set<Osoba> mieszkańcy;

};


ODL: składnia górnego poziomu<specyfikacja> ::= <definicja> | <definicja> <specyfikacja><definicja> ::= <dekl_typu> | <dekl_stałej> | <dekl_wyjątku>

| <interfejs> | <moduł><moduł> ::= module <identyfikator> {<specyfikacja>}<interfejs> ::= <dekl_interfejsu> | <dekl_forward><dekl_interfejsu> ::= <nagłówek_interfejsu>

[: <deklaracja_trwałości>]{[<ciało_interfejsu>]};<deklaracja_trwałości> ::= persistent | transient<nagłówek_interfejsu> ::= interface <identyfikator> [<specyfikacja_dziedzicz>]

[<lista_własności_typów>]<dekl_forward> ::= interface <identyfikator> ..... .....<ciało_interfejsu> ::= <eksport> | <eksport> <ciało_interfejsu><eksport> ::= <dekl_typu> | <dekl_stałej> | <dekl_wyjątku>

| <dekl_atrybutu> | <dekl_związku> | <dekl_operacji>..... .....<dekl_typu> ::= typedef <type_declarator> |

<typ_struct> | <typ_union> | <typ_enum>..... .....


Model ODMG i ODL - zalety i wady

ODMG 2.0 cechuje dość niski poziom ogólnego uzasadnienia, racjonalności przyjmowanych decyzji, co powoduje u wielu ludzi wrażenie ich przypadkowości i chaotyczności.

Efekt ten jest wzmacniany przez liczne błędy w przykładach, błędy, niekonsekwencje lub niedoróbki specyfikacji gramatyki, wady koncepcji i semantyki.

Standard ODMG stanowi krok do przodu, ponieważ: + konkretyzuje założenia obiektowego modelu danych, + konkretyzuje struktury danych,+ konkretyzuje interfejsy specyfikacji i manipulacji danymi,+ stawia na ortogonalność (dowolne zagnieżdzanie) struktur danych,+ specyfikuje związki pomiędzy danymi, + specyfikuje hierarchię dziedziczenia, operacje oraz wyjątki (niestety, nie do końca konsekwentnie),+ stawia na mocną kontrolę typów (niestety, również niekonsekwentnie).


ODMG ODL - wady koncepcyjne i sematyczne (1)Pojęcie literala oraz podział na obiekty i literale są bardzo podejrzane i powodują wrażenie, że osoby z kręgów ODMG niewiele wiedzą o sematyce języków programowania. Semantyka jest intuicyjna i bardzo nieprecyzyjna.

Brak referencji do obiektu (identyfikatora obiektu) jako specjalnego bytu służacego do konstrukcji niektórych dziedzin semantycznych (np. rezultatów zapytań) jest błędem, który uniemożliwia zbudowanie poprawnej semantyki odpowiednich interfejsów.Zasada przechowywania: każda przechowywana dana (obiekt, atrybut, podatrybut, powiązanie, wyjątek, ... ) musi posiadać unikalny identyfikator lub lokację. Brak tej możliwości powoduje trudności z definicją semantyki wielu konstrukcji (podstawienie, usuwanie, wołanie przez referencję, itd.)

Dla wielu zastosowań konieczne jest oddzielenie kontrolnej funkcji pojęcia typu (dynamiczna kontrola typów, statyczna kontrola programów) od funkcji tego pojęcia w zakresie modelowania pojęciowego (specyfikacja interfejsu). Typ obiektu może być różny w zależności, czy rozpatrujemy jego “wnętrze” czy “zewnętrze”. (Zdublowanie form gramatycznych typu dla obiektów i literali.)

ODMG wiele mówi o typach obiektów lub literali, natomiast nie wprowadza żadnego modelu określającego w sposób precyzyjny lub formalny czym jest obiekt lub literal. Typy gubią wiele informacji semantycznej, określanie typów pewnych bytów bez określania samych bytów ma fatalne skutki dla precyzji specyfikacji semantyki.


ODMG ODL - wady koncepcyjne i sematyczne (2)Brak ortogonalności i pełnego relatywizmu obiektów (obiekt powinien składać się z podobiektów i z niczego innego) powoduje całkowicie niepotrzebny rozrost funkcji języka i problemy semantyczne.

Brak dynamicznych ról obiektów; brak możliwości zbudowania wielu interfejsów do tego samego obiektu.

Ortogonalna trwałość: identyczne traktowanie trwałych i ulotnych danych, zarówno w zakresie definicji jak i w zakresie manipulacji. Możliwość budowy trwałych obiektów posiadających nietrwałe atrybuty lub nietrwałe związki.

Wartości zerowe i unie powinny być traktowane konsekwentnie w modelu, w języku ODL oraz w językach manipulacji danymi. ODMG wspomina o wartościach zerowych w modelu, ale nie ma ich w specyfikacji składni; natomiast w przypadku unii postępuje odwrotnie...

Dla wielu zastosowań konieczne jest oddzielenie identyfikatora obiektu od lokacji obiektu - w przeciwnym przypadku następuje zbitka semantyczna nie do rozstrzygnięcia (obiekty archiwalne, wersje obiektów, replikacje obiektów, itd.)

Brak jasnego odddzielenia metod działąjących na kolekcjach/ekstensjach od metod działającyh na indywidualnych obiektach (np. metoda new).


ODMG ODL - wady koncepcyjne i sematyczne (3)Brak definicji perspektywy, podstawowej abstrakcji w bazach danych, bez której trudno sobie wyobrazić wiele aplikacji, szczególnie rozproszonych.

Brak definicji ograniczenia i/lub aktywnej reguły, innej podstawowej abstrakcji w bazach danych, bez której trudno sobie wyobrazić wiele aplikacji.

Naiwne potraktowanie kwestii przetwarzania wyjątków; możliwość zadeklarowania wyjątku, ale brak możliwości zadeklarowania obsługi tego wyjątku. Brak możliwości powrotu do stanu, który spowodował wyjątek po jego obsłudze.

Naiwny stosunek do uporządkowania, nie uwzględniający wielu systemów porządkowania, m.in. związanych z językami innymi niż angielski.

Naiwny stosunek do pojęcia zbioru i wielozbioru, nie uwzględniający faktu, że identyczność elementów może byc bardzo różnie zdefiniowana.

Brak precyzyjnego schematu meta-danych oraz metod dostępu do metadanych (mimo istnienia wzoru w postaci Interface Repository OMG CORBA.


ODMG ODL - wady koncepcyjne i sematyczne (4)Brak zdefiniowanych operatorów ogólnych (generic), takich jak podstawienie, które muszą być obecne w każdym języku programowania. Brak zdefiniowanych funkcji ogólnych (bibliotecznych), które muszą być zrealizowane w kazdym interfejsie kompatybilnym z ODMG.

Brak możliwości określenia efektów ubocznych operatorów; brak możliwości zadeklarowania operatorów nie posiadających efektów ubocznych (istotne dla kontroli poprawności programów).

Brak możliwości zadeklarowania operatora (funkcji, procedury) działającej na więcej niż jednym obiekcie lub nie działającej na żadnym obiekcie (tj. działającej na dowolnych obiektach poprzez efekty uboczne). Brak generaliów, szablonów, typów parametrycznych.Brak możliwości zadeklarowania metod odnoszących się wyłącznie do wartości (lub obiektów po zastosowaniu operacji dereferencji); inaczej abstrakcyjnych typów danych.

Z powodu tych oraz innych wad wiele osób ma nieżyczliwy stosunek do standardu ODMG. Są opracowania mające w tytule lub w temacie “obiektowe bazy danych”, gdzie nie występuje akronim ODMG, co sugeruje, że ich autorzy uważają tę propozycję za niepoważną. Z drugiej strony, wymienione wady ODMG można uważać za choroby dziecięce (4-ro latka). Niemniej: “Bill is everywhere!” Zasadniczą kwestią jest to, co ODMG powie Microsoft, IBM, etc. Jak dotąd, nie widać tu większego zainteresowania.

Bazy danych i inżynieria oprogramowania

Documents

Transcript of Bazy danych i inżynieria oprogramowania