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

2 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 3 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.)

4 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 5 ODL - językowo-niezależny Lingua franca dla integracji systemów (STEP/Express, SQL3, CAD Framework Initiative,...) Lingua franca dla integracji systemów (STEP/Express, SQL3, CAD Framework Initiative,...) STEP/ExpressSQL3Inne Językowo-niezależny ODL C++ SQL3 Smalltalk Java Inne

6 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 6 ODL: BNF dla interfejsu ::= [: ]{[ ]}; ::= persistent | transient ::= interface [ ] określa obecność ekstensji i kluczy, np. interface Profesor : Osoba (extent profesorowie keys id_wydziału, nr_pesel): persistent {... atrybuty...... związki...... operacje... };

7 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 7 ODL: Atrybuty ::= [readonly] attribute [ ] ::= | 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 stopnie;... związki...... operacje... }; Kontrowersyjna składnia... Brak relatywizmu obiektów....

8 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 8 ODL: Związki relationships ::= relationship inverse [{order_by }] 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 stopnie; relationship set opiekuje_się inverse Student::opiekun; relationship set 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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...) Zgodne ze specyfikacją OMG IDL. Definiowana jest wyłącznie specyfikacja operacji (sygnatura), ODMG nie zajmuje się (w zasadzie) jakimikolwiek środkami programowania operacji. (Szkoda...) ::=[oneway] ([ ]) [ ] [ ] ::= | void ::= |, ::= ::=in | out | inout ::= raises ( ) ::= context ( ) 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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; attribute set stopnie; relationship set opiekuje_się inverse Student::opiekun; relationship set zatrudnia inverse Asystent::pracuje_dla; relationship Wydział pracuje_na inverse Wydział::zatrudnia; short Promuje( in string kogo ) raises (Nie_spełnia_warunków); };

11 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 11 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 Kurs Student_asystentProfesor Wykład 1..* 0..* 1..* 0..* 0..1

12 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 12 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 dzieci inverse Osoba::rodzice; relationship list 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 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 mieszkańcy; };

13 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 13 ODL: składnia górnego poziomu ::= | ::= | | | | ::=module { } ::= | ::= [: ]{[ ]}; ::= persistent | transient ::= interface [ ] [ ] ::=interface..... ::= | ::= | | | | |..... ::=typedef | | |.....

14 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 14 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).

15 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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. 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.

16 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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. 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).

17 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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. 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.

18 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 9, Folia 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.