INFO
Sylabus
Standard ODMG, część 3
1. Plan wykładu
2. ODL: Object Definition Language
3. Założenia przyjęte przy projektowaniu ODL
4. ODL - językowo-niezależny
5. ODL: BNF dla interfejsu
6. Atrybuty
7. Związki
8. Operacje
9. Przykład w ODL
10. Schemat w ODL -reprezentacja graficzna
11. ODL- inny przykład
12. ODL: składnia górnego poziomu
13. Model ODMG i ODL - zalety i wady
14. ODMG ODL - wady koncepcyjne i semantyczne
Skorowidz
Wyście:
Wyklad IX. Wprowadzenie do standardu ODMG, część 3:
ODL (KURS SSR)
I II III IV V VI VII VIII IX X XI XII XIII XIV
« poprzedni punkt   następny punkt »

14. ODMG ODL - wady koncepcyjne i sematyczne

(1kB) 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

(1kB) 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.

(1kB) 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.)

(1kB) 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.)

(1kB) 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 .

(1kB) 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.)

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

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

(1kB) 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.

(1kB) 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...

(1kB) Brak definicji perspektywy, podstawowej abstrakcji w bazach danych, bez której trudno sobie wyobrazić wiele aplikacji, szczególnie rozproszonych.

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

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

(1kB) 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.

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

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

(1kB) 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.

(1kB) 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).

(1kB) 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.

(1kB) 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.


« poprzedni punkt   następny punkt »