bazy danych i inżynieria oprogramowania

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 14, Folia 1

Bazy danych i inżynieria oprogramowania

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 14:

Wprowadzenie do standardu ODMG, część 8: Metamodel i repozytorium metadanych


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


Przykład opisu metamodelu

MetaobiektNazwa

Typ

Argument

Własność

ZwiązekLicznośćOdwrotny

Atrybut

*

maOperacja należy_ do*

*

*

ma

określałączy wynik

określa

*

jest połączony przez*

*

*

jest dziedziczonydziedziczy

ma

*

określa

Interfejs


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.


Przykład metamodelu

uczęszcza_na prowadzi

OsobaNazwisko

WykładowcaStanowiskoZarobek

StudentNrIndeksuStypendium

WykładNazwaobowiązuje

*

prow_przez

*

*

ODL: Metamodel (fragment):

(Interfejs)Nazwa: "Osoba"

(Interfejs)Nazwa: "Student"

(Interfejs)Nazwa: "Wykład"

(Interfejs)Nazwa: "Wykładowca"

(Atrybut)Nazwa: "Nazwisko"

(Atrybut)Nazwa: "NrIndeksu"

(Atrybut)Nazwa: "Stypendium"

(Atrybut)Nazwa: "Nazwa"

(Atrybut)Nazwa: "Stanowisko"

(Atrybut)Nazwa: "Zarobek"

(Związek)Nazwa: "prowadzi"

Liczność: "0..*"Odwrotny:" prow_przez"

(Związek)Nazwa: "prow_przez"

Liczność: "1..1"Odwrotny:"prowadzi"

(Związek)Nazwa: "obowiązuje"

Liczność: "0..*"Odwrotny: "uczęszcza_na"


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


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.


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.


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


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.


Metadane w ODMG 3.0metadata

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

};


Zakresyscopes

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

interface Scope{ exception DuplicateName{}; exception NameNotFound{ string reason; }; void bind( in string name,

in MetaObject value )raises( DuplicateName );

MetaObject resolve( in string name ) raises( NameNotFound );

void unbind( in string name) raises( NameNotFound );

list<RepositoryObject> children();};

bindresolveunbindchildren

Metaobiektnadrzędny

metaobiekty podrzędne


Metaobiektymetaobjects

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.

definedIn

RepositoryObjectmeta_kindaccept_visitorparent

MetaObjectnamecommentabsolute_name

DefiningScope

defines

Wszystkie obiekty repozytorium są podklasami trzech głównych interfejsów:• MetaObject• Specifier• Operand

*

Scope



Interfejs DefiningScope

interface DefiningScope: Scope{...Collection create_collection( in CollectionKind collection_kind,

in Operand max_size, in Type sub_type );

...};

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.

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.


Moduły

definedIn



defines

*

Scope


DefiningScope

Module

add_moduleadd_interfaceadd_classremove_moduleremove_interfaceremove_class

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.

modules


Operacje, wyjątki, stałe



Scope


Operation Exception Constantvalue

Parameter Type

*result

*

signatureexceptions

Structure Operand

result* operations

ConstOperand Enumeration

enumerationthe_Valuetype

referenced_by

*


Własnościproperties



Property Type*type properties

Attributeis_read_only

Relationship

get_cardinality

traversal

traversal

Każdy związek jest skojarzony z bliźniaczym.


Interfejsy

Interface

add_atributeadd_relationshipadd_operationremove_atributeremove _relationshipremove _operation

inherits

*

*

derives

Type

Scope


DefiningScope



Property*type

Attributeis_read_only

Relationship

get_cardinality

Interfejsy dziedziczą i są dziedziczone.Są połączone z atrybutami i związkami poprzez Type.Zapomniano o wyjątkach.


Klasy i kolekcje

Interface

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

.....

Classextentskeys

extender

extensions

*

classes, collections

Collectioncollection_kindis_orderedbound

Dictionary*key_type

Operand

subtype*

*max_size


Typy konstruowaneconstructed types

Type

.....

Scope

ScopedType

Enumeration Structure Union

Constant*

elements

Member Exception UnionCase**

cases

*switch_type

fields exception_result


Specyfikatory i operandyspecifiers, operands

RepositoryObject

Specyfikator jest używany do przypisania nazwy do typu w pewnych kontekstach.

Type

structure_type*

Specifiername

Member UnionCase Parameterparameter_mode

*type

operation

*

Operand

value

union_type*

Structure Union Operation

case_labels

*

Expressionoperator

*

the_operands

Literalliteral_value

ConstOperand

Constant

Collection

UnionCase

references

value_of

size_of

case_in


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.


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.


Spłaszczenie meta-modelu (1)

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

(MetaObject)name: "Student"kind: "interface"

MetaObjectname: stringkind: string

(Interface)name: "Student"

Interfacename: string

Wersja proponowanaw standardzie ODMG

Wersja "spłaszczona"

Interfejsy Obiekty


Spłaszczenie meta-modelu (2)

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.

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.

MetaAttributename: string

*

MetaValuevalue: string

MetaObjectname: stringkind: string is_described_by

describes has*is_value_of


Spłaszczony metamodel - przykład (1)

(MetaAttribute)name: "nbr of elements"

(MetaAttribute)name: "collection kind"

(MetaAttribute)name: "null_is_allowed"

(MetaObject)name: "Student"kind: "interface"

(MetaObject)name: "Faculty"kind: "interface"

(MetaObject)name: "IndexNbr"kind: "attribute"

(MetaObject)name: "Name"

kind: "attribute"

(MetaValue)value: 1531

(MetaValue)value: 7648

(MetaValue)value: "yes"

(MetaValue)value: "sequence"

(MetaValue)value: "set"

(MetaValue)value: "no"


Rozwinięcie spłaszczonego metamodelu

Zapisu związków pomiędzy meta-obiektami można rozwiązać na kilka sposobów, np.:

MetaRelationshipname: string

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

MetaAttributename: string

*

MetaValuevalue: string

MetaObjectname: stringkind: string is_described_by

describes has*is_value_of

*

is_connected_by

connects

to_child

*

to_ancestor


Spłaszczony metamodel - przykład (2)(MetaObject)

name: "Student"kind: "interface"

(MetaObject)name: "Faculty"kind: "interface"

(MetaObject)name: "IndexNbr"kind: "attribute"

(MetaObject)name: "Name"

kind: "attribute"

(MetaObject)name: "Person"kind: "interface"

(MetaObject)name: "studies on"kind: "relationship"

(MetaRelationship)name: "is attribute of"

(MetaRelationship)name: "to attribute"

(MetaRelationship)name: "is attribute of"

(MetaRelationship)name: "to attribute"

(MetaRelationship)name: "inherits from"

(MetaRelationship)name: "is super interface of"

(MetaRelationship)name: "relationship from"

(MetaRelationship)name: "relationship to"


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.

bazy danych i inżynieria oprogramowania

Documents