Bazy danych i inżynieria oprogramowania

1. Bazy danych i inżynieria oprogramowania Wykład 14: Wprowadzenie do standardu ODMG, część 8: Metamodel i repozytorium metadanych Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. Co to jest i po co jest metamodel? Metamodel jest to odwzorowanie zależności pomiędzy pojęciami wprowadzanymi w danym modelu. Np. metamodel ustala zależność pomiędzy pojęciem "interfejs" a pojęciem "atrybut" (tj. atrybut jest składową interfejsu). Dlaczego tworzy się metamodel? Lepsze zrozumienie modelu danych. Metamodel pozwala na ustalenie zależności pomiędzy pojęciami wprowadzanymi w ramach modelu, dzięki czemu projektanci/programiści mogą lepiej rozumieć, jak należy używać tych pojęć. Wewnętrzne operacje i administrowanie baza danych. Metamodel musi być wewnętrznie zaimplementowany wewnątrz SZBD, gdyż z informacji zawartych w metamodelu korzystają operacje zrealizowane w ramach tego SZBD. Implementacja metamodelu nosi nazwę "katalogu bazy danych", "słownika", itd. Programowanie generyczne: zaimplementowany metamodel posiadający odpowiednie funkcje dostępu umożliwia pisanie programów generycznych (np. programowanie w dynamicznym SQL, dynamiczne wywołania metod w CORBA, itp.)

3. Przykład opisu metamodelu Interfejs Metaobiekt Nazwa jest dziedziczony dziedziczy * * jest połączony przez Własność Typ określa określa wynik łączy * * * * ma należy_ do Związek Liczność Odwrotny Atrybut Operacja * * Argument * ma ma określa

4. Co przedstawia metamodel? Zależności pomiędzy wprowadzanymi pojęciami; Abstrakcyjną składnię odpowiednich wyrażeń języka opisu danych (ODL); Strukturę organizacji katalogów danego systemu zarządzania bazą danych. Metamodel nie wystarcza do pełnego opisu danych Metamodel nie reprezentuje: Formalnej semantyki wyrażeń opisu danych (dopuszczalnych stanów BD); Znaczenia danych w dziedzinie biznesu (semantyki danych); Pragmatyki użycia danych, reguł przetwarzania danych, ograniczeń, ergonomii, czynników efektywnościowych i wydajnościowych, itd. Opis powyższych własności nosi nazwę ontologii. Jest to opis wszystkiego tego, co projektant/programista powinien wiedzieć o danych, środowisku komputerowym i dziedzinie biznesowej, aby budować efektywne aplikacje.

5. Przykład metamodelu ODL: Metamodel (fragment): (Atrybut) Nazwa: "Nazwisko" Osoba Nazwisko (Interfejs) Nazwa: "Osoba" (Atrybut) Nazwa: "NrIndeksu" (Interfejs) Nazwa: "Student" Student NrIndeksu Stypendium Wykładowca Stanowisko Zarobek (Atrybut) Nazwa: "Stypendium" (Atrybut) Nazwa: "Zarobek" * uczęszcza_na prowadzi (Interfejs) Nazwa: "Wykładowca" * Wykład Nazwa * (Atrybut) Nazwa: "Stanowisko" obowiązuje prow_przez (Interfejs) Nazwa: "Wykład" (Atrybut) Nazwa: "Nazwa" (Związek) Nazwa: "obowiązuje" Liczność: "0..*" Odwrotny: "uczęszcza_na" (Związek) Nazwa: "prow_przez" Liczność: "1..1" Odwrotny:"prowadzi" (Związek) Nazwa: "prowadzi" Liczność: "0..*" Odwrotny:" prow_przez"

6. Wymagania w stosunku do metamodelu Odwzorowanie wszystkich pojęć modelu obiektowego oraz ODL. Muszą one być dostępne explicite dla systemu, gdyż inaczej nie będą uwzględnione. Prostota: posługiwanie się metamodelem przez programistów systemowych (tworzących SZBD) oraz programistów aplikacyjnych (korzystających z SZBD) musi być proste celem uniknięcia błędów, nadmiernej pracochłonności oraz nadmiernych kosztów pielęgnacji oprogramowania. Uniwersalność: metamodel powinien umożliwiać realizację dowolnych wyobrażalnych operacji, np. wprowadzenie nowej klasy, usunięcie klasy, wprowadzenie nowego związku, zmiana typu atrybutu, itd. Efektywność komputerowa: odwołania do metamodelu (systemowe lub aplikacyjne) mogą być częste, musi on być więc zorganizowany w taki sposób, aby dostęp do metamodelu nie obciążał zasadniczo czasów wykonania. Rolą repozytorium przechowującego metamodel jest również trzymanie informacji o strukturze fizycznej (np. liczności zbiorów, obecności indeksów) oraz informacji niezbędnych dla optymalizacji (np. statystyk dostępu, wag w modelu kosztów, itp.)

7. Co to jest "generyczność"? Jest to określenie charakteru oprogramowania lub charakteru narzędzia programistycznego umożliwiającego pracę z bardzo szeroką klasą struktur danych. Np. przeglądarka umożliwiająca oglądanie zawartości dowolnej relacyjnej bazy danych jest oprogramowaniem generycznym. Bardzo często aplikacje wymagają oprogramowania generycznego. Generyczność oprogramowania oznacza możliwość łatwego przystosowania go do nowych potrzeb, nowego klienta, nowych struktur danych, itd. Oprogramowanie działające na bazach danych Internetu, np. działające na plikach XML, z reguły musi być generyczne. Programowanie aplikacji lub narzędzi generycznych jest często konieczne, ale jest też bardziej uciążliwe dla programistów. ODMG nie definiuje środków programowania generycznego. Jednakże opis metamodelu pojawia się jako pierwszy krok w tym kierunku.

8. Metody programowania generycznego Najbardziej popularną metodą jest obniżenie poziomu abstrakcji programowania. Np. programując w C/C++ można pointery do struktur zamienić (przekastować) na pointery do bajtów, i następnie przetwarzać struktury bajt-po-bajcie. Inną metodą są wszelkie struktury parametryzowane, np. szablony (templates) w C++. Tę zasadę na wyższym poziomie abstrakcji wykorzystują także języki z polimorfizmem typów, np. ML lub Haskel. Inną metoda jest stosowana w relacyjnych SZBD (dynamiczny SQL), CORBA (wołania dynamiczne) i innych interfejsach. Metoda ta jest określana jako "refleksja". Metoda ta pojawia się w bardzo różnych wariantach. Chodzi w niej o to, że programista wewnątrz aplikacji generuje program, który w tej samej aplikacji jest wykonywany. Wariantem refleksji jest sprowadzenie danych i metadanych na ten sam poziom przetwarzania; następnie, udostępnienia mechanizmów umożliwiających wykorzystanie metadanych dla przetwarzania danych (patrz np. XML). Java jest krytykowana za słabe możliwości programowania generycznego.

9. Kroki refleksji W językach z wczesnym wiązaniem (C, C++, Java) refleksja jest w zasadzie niemożliwa, gdyż wymagałaby skonsolidowania wygenerowanego programu z działającym programem, a takie mechanizmy nie istnieją. Z tego powodu refleksja polega na generowaniu pewnych struktur danych (symulujacych program), które następnie podlegają interpretacji wewnątrz tego samego programu. Kroki refleksji są więc następujące: Odszukanie właściwej meta-informacji w katalogu; Wykorzystanie tej meta-informacji do dynamicznego skonstruowania zlecenia, np. w postaci stringu reprezentującego zdanie SQL; Wykonanie tego zlecenia poprzez specjalny mechanizm wbudowany w dany język, który skonstruowane zlecenie bierze jako parametr. Rezultat zlecenia jest zapamiętany w specjalnie przygotowanej strukturze danych; Utylizacja rezultatu zlecenia w programie. Często wymaga ona odzyskania informacji o typie tego rezultatu oraz dodatkowych mechanizmów. Istnienie metamodelu jest więc warunkiem koniecznym dla zrealizowania mechanizmu refleksji. Nie zawsze jednak to wystarcza (patrz punkty 3 i 4). 1 2 3 4

10. Metamodel rezultatów zapytań Jeżeli zapytanie może być tworzone dynamicznie, wówczas może ono zwrócić wartość takiego typu, który nie jest znany programiście podczas pisania programu. Przetwarzanie wyniku zapytania o nieznanym typie jest niemożliwe. Czyli wraz z wynikiem zapytania programista musi mieć możliwość odzyskania jego typu. Taki typ może być strukturą o dowolnym stopniu skomplikowania. Zapytanie może zwrócić taki typ, którego nie ma w schemacie bazy danych. Jeżeli rezultat zapytania byłby fizycznie rozdzielony ze strukturą przechowującą jego typ, wówczas przetwarzanie mogłoby być utrudnione z powodu niemożliwości dopasowania fragmentu wyniku do odpowiadającego mu fragmentu typu. Stąd rezultat zapytania powinien być "spleciony" z definicją jego typu. Zasady, w jaki sposób rezultat zapytania będzie "spleciony" z informacją o typie tego rezultatu tworzą metamodel rezultatów zapytań. ODMG nie definiuje metamodelu rezultatów zapytań, co powoduje, że wiele lub większość zadań programowania generycznego poprzez refleksję będzie nierealizowalna. SQL, zarówno w wariancie SQL-89 jak i SQL-92, definiuje tego rodzaju metamodel.

11. Metadane w ODMG 3.0 metadata Metadanymi nazywa się dane opisowe definiujące schemat obiektowej bazy danych. Są one używane dla zdefiniowania struktury składu trwałych obiektów. Metadane są przechowywane w Repozytorium Schematu ODL (ODL Schema Repository). Jest ono używane przez różne narzędzia i aplikacje. Repozytorium Schematu ODL jest odpowiednikiem Repozytorium Interfejsów IDL wg CORBA. Strukturę Repozytorium Schematu ODL określa zestaw interfejsów w ODL, który jest ze sobą połączony poprzez związki ustalające graf powiązań pomiędzy metaobiektami. Wszystkie te interfejsy sa zgromadzone wewnątrz modułu: module ODLMetaObjects{ // definicja interfejsów };

12. Zakresy scopes Zakresy definiują hierarchię nazw dla metaobiektów w repozytorium. Dodanie metaobiektu - bind Ustalenie metaobiektu na podstawie jego nazwy - resolve Usunięcie metaobiektu - unbind Metaobiekty podporządkowane - children bind resolve unbind children interfaceScope{ exceptionDuplicateName{}; exceptionNameNotFound{ stringreason; }; voidbind( instringname, in MetaObject value ) raises( DuplicateName ); MetaObject resolve( in stringname ) raises( NameNotFound ); voidunbind( in string name) raises( NameNotFound ); list<RepositoryObject> children(); }; Metaobiekt nadrzędny metaobiekty podrzędne

13. Metaobiekty RepositoryObject meta_kind accept_visitor parent MetaObject name comment absolute_name Scope bind resolve unbind children metaobjects ODMG proponuje mechanizm dostępu do repozytorium, polegający na użyciu metod callback. W tym celu definiuje interfejsy RepositoryObjectVisitor oraz RepositoryObject, których mają ze sobą współpracować przy wołaniach callback. Ten fragment standardu jest opisany bardzo niejasno i nie poparty przykładem, co praktycznie uniemożliwia zrozumienie, o co w tym wszystkim chodzi. • Wszystkie obiekty repozytorium są podklasami trzech głównych interfejsów: • MetaObject • Specifier • Operand definedIn * defines DefiningScope

14. Interfejs DefiningScope Jest to interfejs umożliwiający operacje na takich metaobiektach, które składają się z nieokreślonej liczby pewnych elementow. Przykładowe typy takich metaobiektów: Collection, Dictionary, Union, Enumeration, Structure. Dla odpowiednich rodzajów metaobiektów są zdefiniowane operacje create_..., add_... oraz remove_... . Razem interfejs zawiera 18 tego typu operacji. interfaceDefiningScope: Scope{ ... Collection create_collection( in CollectionKind collection_kind, in Operand max_size, in Type sub_type ); ... }; Niestety, autorzy "standardu" ograniczają się do podania tego interfejsu nie dając nawet najdrobniejszego komentarza odnośnie ich semantyki, pragmatyki ich użycia, lub najdrobniejszego chociaż przykładu ilustrującego ich intencje.

15. Moduły RepositoryObject meta_kind accept_visitor parent DefiningScope Scope bind resolve unbind children Module add_module add_interface add_class remove_module remove_interface remove_class modules MetaObject name comment absolute_name * definedIn defines Interfejs Module posiada operacje do tworzenia i usuwania modułów, interfejsów i klas. Dziedziczy z interfejsów MetaObject oraz DefiningScope. Całość repozytorium jest również modułem.

16. Operacje, wyjątki, stałe RepositoryObject meta_kind accept_visitor parent Constant value Scope bind resolve unbind children MetaObject name comment absolute_name Operation Exception * * operations result signature result type enumeration exceptions the_Value referenced_by * * Parameter Type Structure Operand ConstOperand Enumeration

17. Własności RepositoryObject meta_kind accept_visitor parent Attribute is_read_only properties MetaObject name comment absolute_name properties type Property Type * Relationship get_cardinality traversal traversal Każdy związek jest skojarzony z bliźniaczym.

18. Interfejsy MetaObject name comment absolute_name RepositoryObject meta_kind accept_visitor parent Relationship get_cardinality Attribute is_read_only Scope bind resolve unbind children Interfejsy dziedziczą i są dziedziczone. Są połączone z atrybutami i związkami poprzez Type. Zapomniano o wyjątkach. DefiningScope type Property Type * inherits * Interface add_atribute add_relationship add_operation remove_atribute remove _relationship remove _operation derives *

19. Klasy i kolekcje Collection collection_kind is_ordered bound Class extents keys classes, collections Zdaniem ODMG, klasa jest specjalizacją interfejsu zawierającą abstrakcyjny stan obiektów zapamiętanych w OSZBD. Dziedziczenie klas nie może być wielokrotne; zostało także inaczej nazwane ("extender/extensions"). Kolekcje są agregatami dowolnej liczby elementów pojedynczego podtypu. ..... Type Interface subtype * * Operand max_size extender * * Dictionary key_type extensions

20. Typy konstruowane constructed types ..... Scope Type ScopedType switch_type * Enumeration Structure Union elements fields exception_result cases * * * Constant Member Exception UnionCase

21. Specyfikatory i operandy Specifier name Parameter parameter_mode Expression operator Literal literal_value specifiers, operands Specyfikator jest używany do przypisania nazwy do typu w pewnych kontekstach. Collection RepositoryObject size_of type Type Operand value * case_in UnionCase * * value_of case_labels Constant Member UnionCase * * structure_type union_type * operation references the_operands ConstOperand Structure Union Operation

22. Podsumowanie i ocena specyfikacji Interfejsów: 31; Związków: 44 (2 x 22); Związków dziedziczenia: 29; Metod: 64 Struktura ta jest sama w sobie dużą bazą danych. Zrozumienie tej struktury oraz manipulacja tą strukturą będzie problemem dla programistów. Pielęgnacja tej struktury (reakcja na zmiany w specyfikacji standardu) stanie się koszmarem. Np. kiedyś pojawią się perspektywy, tryggery, procedury BD, metody BD. Co z nimi? Struktura ta bardzo utrudnia wydobywanie niektórych informacji. Przykładowo, mamy nazwę "klient"; jak ustalić, czy jest to nazwa interfejsu, klasy, atrybutu,...? Scenariusz postępowania przy refleksji może być następujący: mamy pewną daną, ustalić jej metadane. Struktura metadanych musi być więc powiązana z zapamiętanymi danymi. Standard tego nie precyzuje. Struktura musi być powiązana z informacją o fizycznej organizacji danych oraz informacją służącą do optymalizacji. Standard tego nie precyzuje. Struktura nie zajmuje się metamodelem rezultatów zwracanych przez zapytania. Generalna konkluzja: koncepcja niekompletna i technicznie wadliwa.

23. Jak poprawić koncepcję metamodelu? Uprościć model obiektowy, poprzez zredukowanie liczby pojęć, usunięcie pojęć redundantnych lub mało użytecznych (np, zbiorów - wystarczą wielozbiory) i zastosowanie zasady relatywizmu (np. każdy obiekt składa się z podobiektów, nie ma atrybutów). Uporządkować stosunek pomiędzy pojęciami interfejsu, typu i klasy. Zdefiniować standardowy, generyczny zestaw operacji do manipulacji i wyszukiwania. Powinien on dawać możliwość definiowania metod, ale nie powinien zmuszać wyłącznie do używania wąsko specjalizowanych, predefiniowanych metod. Powinien opierać się na języku zapytań a la OQL "Spłaszczyć" strukturę repozytorium metaobiektów tak, aby wszelkie związki pomiędzy elementami repozytorium były wyrażane w terminach wartości np. stringowych. Przykładowo, zamiast interfejsu Parameter zdefiniować obiekt Metaobject zawierający string "Parameter". Powyższe spłaszczenie ma kapitalne znaczenie dla pielęgnacyjności repozytorium, prostoty wyszukiwania, oraz dostawiania dowolnych pojęć typu informacja o organizacji fizycznej czy informacji optymalizacyjnej.

24. Spłaszczenie meta-modelu (1) MetaObject name: string kind: string Interface name: string Polega na tym, że część meta-meta-danych jest przesuwana na poziom meta-danych. Np. Interface jest meta-meta-daną, która jest zastąpiona przez string "Interface". Interfejsy Obiekty Wersja proponowana w standardzie ODMG (Interface) name: "Student" (MetaObject) name: "Student" kind: "interface" Wersja "spłaszczona"

25. Spłaszczenie meta-modelu (2) MetaObject name: string kind: string MetaValue value: string MetaAttribute name: string Każdy MetaObject jest opisany przez meta-atrybuty, których nazwy i zawartość mogą być dowolnie ustalane. Mogą być ustalane dynamicznie, ad-hoc. Meta-atrybuty są powiązane z meta-wartościami charakteryzującymi meta-obiekty. has describes * is_value_of is_described_by * Cokolwiek, co mogłoby charakteryzować metaobiekty, może być zapisane jako jedna lub więcej wartości pewnych ustalonych atrybutów. Powyższy rysunek przedstawia zasadę, którą można dowolnie rozwinąć - na meta-związki pomiędzy metaobiektami, na meta-atrybuty złożone, na meta-atrybuty przypisane do meta-związków, itd.

26. Spłaszczony metamodel - przykład (1) (MetaObject) name: "Student" kind: "interface" (MetaAttribute) name: "nbr of elements" (MetaObject) name: "IndexNbr" kind: "attribute" (MetaAttribute) name: "collection kind" (MetaObject) name: "Faculty" kind: "interface" (MetaAttribute) name: "null_is_allowed" (MetaObject) name: "Name" kind: "attribute" (MetaValue) value: 1531 (MetaValue) value: "sequence" (MetaValue) value: "yes" (MetaValue) value: 7648 (MetaValue) value: "set" (MetaValue) value: "no"

27. Rozwinięcie spłaszczonego metamodelu MetaObject name: string kind: string MetaValue value: string MetaRelationship name: string MetaAttribute name: string Zapisu związków pomiędzy meta-obiektami można rozwiązać na kilka sposobów, np.: has describes * is_value_of is_described_by * * is_connected_by * connects to_ancestor to_child Obiekty MetaRelationship przechowują rodzaj powiązania na zasadzie podobnej do przedstawionej poprzednio. Na następnym slajdzie związki są pokolorowane jw. odpowiednio na czarno i czerwono

28. Spłaszczony metamodel - przykład (2) (MetaObject) name: "Student" kind: "interface" (MetaRelationship) name: "inherits from" (MetaRelationship) name: "is super interface of" (MetaObject) name: "Person" kind: "interface" (MetaRelationship) name: "to attribute" (MetaObject) name: "IndexNbr" kind: "attribute" (MetaRelationship) name: "to attribute" (MetaObject) name: "Name" kind: "attribute" (MetaRelationship) name: "is attribute of" (MetaRelationship) name: "is attribute of" (MetaObject) name: "Faculty" kind: "interface" (MetaRelationship) name: "relationship from" (MetaObject) name: "studies on" kind: "relationship" (MetaRelationship) name: "relationship to"

29. Podsumowanie Istnienie metamodelu i repozytorium metadanych jest nieodzowne dla wspomagania wewnętrznych operacji SZBD. Takie repozytorium, oprócz informacji o schemacie BD, może być miejscem przechowywania informacji o strukturze fizycznej oraz informacji używanych do optymalizacji. Repozytorium powinno również wspomagać programowanie generyczne poprzez refleksję. To zastosowanie rodzi nowe wymagania, np. określenie metamodelu wyników zapytań. ODMG podjęła temat budowy metamodelu i repozytorium metadanych, jednakże proponowane rozwiązanie jest niekompletne i wadliwe. Konieczne jest opracowanie generycznych mechanizmów dostępu do takiego repozytorium, a nie poleganie na predefiniowanych metodach. Spłaszczenie struktury pojęciowej repozytorium metadanych wydaje się warunkiem koniecznym dla uniknięcie koszmaru dostępu i zarządzania metadanymi, umożliwienie elastycznej zmiany struktury pojęć opisywanych w repozytorium, oraz umożliwienie sprawnej pielęgnacji repozytorium.