Bazy danych i inżynieria oprogramowania

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

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

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

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

5. 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 Java SQL3 Smalltalk C++ Inne

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

7. 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; attributeset<string> stopnie; ... związki ... ... operacje ... }; Kontrowersyjna składnia... Brak relatywizmu obiektów....

8. ODL: Związki relationships <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; attributeset<string> stopnie; relationshipset<Student> opiekuje_się inverse Student::opiekun; relationshipset<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...?

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

10. 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; attributeset<string> stopnie; relationshipset<Student> opiekuje_się inverse Student::opiekun; relationshipset<Asystent> zatrudnia inverse Asystent::pracuje_dla; relationship Wydział pracuje_na inverse Wydział::zatrudnia; short Promuje( instring kogo ) raises (Nie_spełnia_warunków); };

11. Schemat w ODL -reprezentacja graficzna W notacji UML: Osoba zapisany_na Student Pracownik poprzedza 1..* 0..* Kurs Student_asystent Profesor 0..* zawiera prowadzi 0..1 asystuje_w następuje_po prowadzony_dla jest_składową 1..* 1..* ma_asystenta Wykład 0..* prowadzony_przez

12. ODL- inny przykład interface Osoba ( extent osoby) { attributestring nazwisko_imię; attribute Date data_ur; attributestruct Adres{unsignedshort nr, string ulica, string miasto} adres; relationship Osoba mąż_lub_żona inverse Osoba:: mąż_lub_żona; relationshipset<Osoba> dzieci inverse Osoba::rodzice; relationshiplist<Osoba> rodzice inverse Osoba::dzieci order_by data_ur; void urodzenie(instring nazwisko_imię_ur); boolean ślub(instring nazw_imię_narzecz) raises (nie_ma_takiej_osoby); unsignedshort daj_przodków (outset<Osoba> przodkowie) raises (nie_ma_takiej_osoby); void zmiana_adresu(instring nowy_adres); }; interface Miasto ( extent miasta key kod_miasta) { attributeunsignedshort kod_miasta; attributestring nazwa; attributeset<Osoba> mieszkańcy; };

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

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

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

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

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

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