Transcript Bazy danych i inżynieria oprogramowania

Bazy danych i inżynieria oprogramowania
Wykład 9:
Wprowadzenie do
standardu ODMG, część 3:
ODL
Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 1
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 2
ODL: Object Definition Language
Język definicji obiektów.
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.
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.)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 3
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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 4
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 5
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 ...
};
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 6
ODL: Atrybuty
<deklaracja atrybutu>
::= [readonly] attribute
<typ_dziedziny> <nazwa_atrybutu> [<rozmiar_tablicy>]
<typ_dziedziny>
::= <spec_prostego_typu>
| <typ_strukturalny>
| <typ_przeliczeniowy>
interface 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;
... związki ...
... operacje ...
};
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 7
Kontrowersyjna
składnia...
Brak relatywizmu
obiektów....
ODL: Związki
<deklaracja_związku> ::= relationship <cel_ścieżki> <identyfikator>
inverse<ścieżka_odwrotna>
[{order_by <lista_atrybutów>}]
interface 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;
... 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...?
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 8
relationships
ODL: Operacje
Zgodne 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.)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 9
Przykład w ODL
interface 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);
};
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 10
Schemat w ODL -reprezentacja graficzna
W notacji UML:
Osoba
zapisany_na
poprzedza
1..*
Student
Pracownik
0..*
Kurs
0..*
Student_asystent
zawiera
następuje_po
asystuje_w
jest_składową 1..*
0..1
Profesor
prowadzi
prowadzony_dla
1..*
Wykład
ma_asystenta
0..*
prowadzony_przez
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 11
ODL- inny przykład
interface 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;
};
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 12
ODL: składnia górnego poziomu
<specyfikacja>
<definicja>
::=
::=
<moduł>
<interfejs>
<dekl_interfejsu>
::=
::=
::=
<deklaracja_trwałości> ::=
<nagłówek_interfejsu> ::=
<dekl_forward>
.....
<ciało_interfejsu>
<eksport>
.....
<dekl_typu>
.....
::=
::=
::=
::=
<definicja> | <definicja> <specyfikacja>
<dekl_typu> | <dekl_stałej> | <dekl_wyjątku>
| <interfejs> | <moduł>
module <identyfikator> {<specyfikacja>}
<dekl_interfejsu> | <dekl_forward>
<nagłówek_interfejsu>
[: <deklaracja_trwałości>]{[<ciało_interfejsu>]};
persistent | transient
interface <identyfikator> [<specyfikacja_dziedzicz>]
[<lista_własności_typów>]
interface <identyfikator>
.....
<eksport> | <eksport> <ciało_interfejsu>
<dekl_typu> | <dekl_stałej> | <dekl_wyjątku>
| <dekl_atrybutu> | <dekl_związku> | <dekl_operacji>
.....
typedef <type_declarator> |
<typ_struct> | <typ_union> | <typ_enum>
.....
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 13
Model ODMG i ODL - zalety i wady
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 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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 14
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.
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.
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.)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 15
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.
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).
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...
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 16
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.
Brak precyzyjnego schematu meta-danych oraz metod dostępu do metadanych (mimo
istnienia wzoru w postaci Interface Repository OMG CORBA.
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
porządkowania, m.in. związanych z językami innymi niż angielski.
wielu
systemów
Naiwny stosunek do pojęcia zbioru i wielozbioru, nie uwzględniający faktu, że
identyczność elementów może byc bardzo różnie zdefiniowana.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 17
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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 18