Metamodele a bazy danych Wprowadzenie Rola metamodeli

Wprowadzenie
• Metamodel bazy danych występuje w każdym
SZBD.
• Konstrukcje metamodelu odzwierciedlają
konstrukcje języka definiowania danych (DDL)
i języka operowania danymi (DML); są
niezbędne do implementacji wewnętrznych
mechanizmów SZBD.
• Metamodel jest podstawą tworzenia
repozytorium schematu bazy danych.
Metamodele a bazy danych
MOF Specification
Version 1.4
April 2002
str. 1- 358.
Tadeusz Pankowski
Instytut Automatyki i Inżynierii Informatycznej
Politechnika Poznańska
T. Pankowski
Rola metamodeli
Przyszłość metamodeli
• Metamodel wyjaśnienia znaczenie konstrukcji i
związków między konstrukcjami.
• Model aplikacji tworzy metadane pamiętane w
schemacie.
• Metamodel jest modelem dla takiego modelu i
określa logiczną strukturę schematu.
• Metadane w ramach metamodelu mogą być
dynamicznie zmieniane przez aplikacje.
• Schemat jest dynamiczny, reguły zmian
określa metamodel.
T. Pankowski
2
3
• Metamodele współczesnych systemów informatycznych
są coraz bardziej złożone.
• Nowe, coraz bardziej zaawansowane wymagania
wynikają z:
• rozwoju internetu i technologii systemów rozproszonych,
• interoperacyjności i integracji systemów – potrzeba opisu
lokalnych zasobów i odwzorowań między nimi a schematem
globalnym.
• Czy podejście MDA jest w stanie sprostać tym
oczekiwaniom? Jeśli nie MDA to co? Wzorce projektowe
(design patterns)?
T. Pankowski
4
Metapoziom
Metapoziom (c.d.)
• Znaczenie pojęcia „meta” jest względne, zależy od tego,
co uważamy za „obiekty regularne”.
• Właściwości metapoziomu:
• ontologiczne – interpretacja obiektu (związana z jego
wyszukiwaniem, modyfikacją, integralnością), wymaga opisu
jego struktury i interfejsów; korzystamy z pojęć, których
wyjaśnienie wymaga kolejnego metapoziomu; mamy
potencjalnie nieskończoną hierarchię metapoziomów –
skończoność wymaga, aby najwyższy metapoziom był
zdefiniowany jest za pomocą języka z formalną semantykę;
• operacyjne – zakłada, że metaobiekt ma wiedzę o obiektach i
potrafi wykonywać na nich operacje – kontroluje zachowanie
się obiektów; metapoziom jest odwzorowany w konkretne
struktury implementacyjne.
T. Pankowski
5
Metapoziom w programowaniu
T. Pankowski
6
Metapoziom w programowaniu i b.d.
• Metapoziom w dziedzinie języków programowania
umożliwia realizację refleksji (reflective capabilities) jako
mechanizmu wspierającego tzw. separation of concerns
(oddzielenie problemów – proces podziału programu na jednostki realizujące
różne zadania), którą dzieli się na introspekcję i interwencję.
• Introspekcja (introspective capabilities) – sprawdzanie
struktury i funkcjonalności jednostek dostępnych w
czasie wykonania i wykorzystanie tej informacji do
dynamicznego formułowania poleceń.
• Interwencja (intercessory capabilities) – przechwytywanie
zachowań i przeplatanie oddzielnie zdefiniowanych
procedur co pozwala na ich zamianę; separacja
zachowań i zmiana implementacji.
T. Pankowski
• Metapoziom opisuje problemy właściwe wszystkim
systemom informatycznym.
• Jawność i dostępność metapoziomu może być różna.
• Dostępność metapoziomu determinuje zdolność aplikacji
do odkrywania i modyfikowania zarówno samych
struktur danych, jak i ich zachowania.
7
• Brak wsparcia dla refleksji w językach programowania
czy w systemach baz danych znacznie komplikuje
tworzenie oprogramowania wymagającego takiej
funkcjonalności. Wówczas jedyną metodą dostępu do
metapoziomu jest używanie preprocesorów, co znacznie
komplikuje proces tworzenia oprogramowania.
• Znaczenie refleksji w SZBD jest jeszcze większe niż w
językach programowania – pojęciom metapoziomu
nadaje się „obywatelstwo pierwszej kategorii” co
umożliwia dużą elastyczność czasu wykonania.
Zmniejsza to oczywiście efektywność przetwarzania.
T. Pankowski
8
Elastyczność i interoperacyjność
SZBD
Metamodel dla bazy danych
• Elastyczność wymaga:
• Obecnie najlepszy metamodel to UML.
• Rola metamodelu:
• wsparcia dla programowania z wykorzystaniem refleksji,
• możliwości rozszerzania struktury metadanych przez
użytkownika,
• możliwości interwencji w celu izolacji pewnych aspektów
zachowań i łatwej zmiany implementacji, w duchu AOP.
• opis pojęć języka modelowania,
• standaryzacja reguł poprawnej budowy i formatów wymiany
metadanych między różnymi narzędziami (środowiskami).
• Główne cechy SZBD przesądzające o potrzebie jawnie
dostępnego metamodelu:
• Interoperacyjność dotyczy integracji i kolaboracji
heterogenicznych baz danych.
• Metadane dostarczają nie tylko informacji o strukturze
danych, ale także o ich znaczeniu/interpretacji.
• Dwie powyższe role metadanych określane są jako:
• strukturalna rola metadanych
• semantyczna rola metadanych.
• elastyczność,
• interoperacyjność.
T. Pankowski
9
• Metamodel oprócz opisu używanego modelu
danych opisuje te wszystkie cechy bazy danych,
które są niezależne od jej stanu.
• Metamodel opisuje:
schemat bazy danych
fizyczną lokalizację i organizację plików,
informacje optymalizacyjne,
reguły dostępu,
reguły integralności (spójności).
T. Pankowski
10
MOF – Meta Object Facility
Znaczenie metamodelu w b.d.
•
•
•
•
•
T. Pankowski
11
• MOF jest specyfikacją OMG, która „definiuje
abstrakcyjny język i ogólne ramy (framework) do
specyfikowania i konstruowania metamodeli oraz
zarządzania nimi niezależnie od technologii”.
• MOF a UML – UML może być traktowany jako
instancja MOF (na poziomie metamodelu są pewne
różnice). MOF jest prostszy niż UML, jest bardziej
zorientowany na implementacje (np. asocjacje binarne
zamiast n-członowych).
T. Pankowski
12
MOF - cechy
Czteropoziomowa architektura MOF
• Rozszerzalność (extensibility) – dopuszcza dodawanie
nowych metadanych.
• W tym celu adoptuje 4-poziomową architekturę znaną
w społeczności zajmującej się standardami (ISO,
CDIF).
• Istotą jej jest istnienie poziomu meta-metamodelu,
który wiąże ze sobą metamodele i modele.
• Poziom informacji – składa się z danych, które chcemy
opisywać.
• Poziom modelu – składa się z metadanych opisujących
dane z poziomu informacji. Metadane są nieformalnie
agregowane jako modele.
• Poziom metamodelu – składa się z opisów (tj. metametadanych) definiujących strukturę i semantykę
metadanych. Metamodel jest „językiem abstrakcyjnym” do
opisu różnego rodzaju danych, tj językiem bez konkretnej
składni.
• Poziom meta-metamodelu – składa się opisu struktury i
semantyki meta-metadanych. Jest „językiem
abstrakcyjnym” do definiowania różnych rodzajów
metadanych.
T. Pankowski
13
Czteropoziomowa architektura MOF
T. Pankowski
Czteropoziomowa architektura MOF
Zestaw pojęć używanych na poziomie
metamodelu
T. Pankowski
15
14
M3 - poziom meta-metamodelu
MetaModel(‘RecordType’,
MetaClass(‘Record’, [MetaAttr (‘name’, String),
[MetaAttr (‘fields’, List<‘Field’>)])
MetaClass(‘Field’, [MetaAttr (‘name’, String),
[MetaAttr (‘type’, StdType)])
M2 - poziom metamodelu
Record(‘Student’, [Field (‘Nazwisko’, String),
[Field (‘Średnia’, Numeric)])
M1 - poziom modelu (metadanych)
Student(‘Nowak’, 4.51)
Student(‘Kubiak’, 3.73)
M0 - poziom danych
T. Pankowski
16
Czteropoziomowa architektura MOF
T. Pankowski
17
Konstrukcje metamodelowania w
MOF
T. Pankowski
18
Klasy
• „Abstrakcyjny język” MOF do definiowania
metamodeli. Jest to podzbiór UML core.
• W MOF przyjmuje się cztery podstawowe
pojęcia modelowania:
1. Klasy (classes) – modelują metaobiekty MOF.
2. Asocjacje (associations) – modelują binarne
związki między metaobiektami.
3. Typy danych (data types) – modelują inne
dane (np. typy proste, typy zewnętrzne, etc.).
4. Pakiety (packages) – modularyzują modele.
T. Pankowski
Czteropoziomowa architektura MOF
19
• Klasy opisują typy „instancji o pierwszej kategorii
obywatelstwa” (of first class instance) metaobiektów MOF.
• Klasy zdefiniowane na poziomie M2 (metamodelu) mają
instancje na poziomie M1. Instancje te mają tożsamość
obiektową, stan i zachowanie.
• Stan i zachowanie instancji z poziomu M1 są zdefiniowane
przez klasę poziomu M2.
• Instancje klas należą do ekstensji klasy (class extents).
• Klasy mają trzy rodzaje cech (features): atrybuty, operacje
i referencje.
• Klasy mogą także zawierać: wyjątki (exceptions), typy
danych, ograniczenia (constraints) i inne.
T. Pankowski
20
Atrybuty
Operacje
• Operacje są miejscem (hooks) dostępu do
zachowania związanego z klasą.
• Nie specyfikują zachowania (metody
implementującej to zachowanie), ale podają
nazwy i sygnatury, za pomocą których
zachowanie jest wywoływane.
• Atrybut definiuje nazwane miejsce pamiętania wartości
(notional value holder). Właściwości atrybutu:
T. Pankowski
21
Właściwości operacji
T. Pankowski
22
Zakresy atrybutów i operacji
• Atrybuty i operacje mogą być definiowane „na poziomie
klasyfikatora” lub „na poziomie instancji”.
• Atrybut poziomu instancji ma value holder dla każdej
instancji klasy, a atrybut poziomu klasyfikatora ma
value holder wspólny dla wszystkich instancji
należących do ekstensji klasy.
• Podobnie, operacja poziomu instancji może być
wywołana dla instancji klasy, a operacja poziomu
klasyfikatora może być wywołana niezależnie przez
każdą instancję i może być zastosowana do dowolnej
lub do wszystkich instancji z ekstensji klasy.
T. Pankowski
23
T. Pankowski
24
Krotność, liczność (Multiplicities)
atrybutów i parametrów
Generalizacja klas
• Atrybuty i parametry mogą być: z wartościami
opcjonalnymi, z wartościami pojedynczymi, z
wartościami wielokrotnymi.
• Specyfikacja krotności składa się z 3 części:
• ograniczenie dolne i górne: np. 0..1, 1, 1..*;
• flaga „is_ordered” mówi czy uporządkowanie
wartości ma semantyczne znaczenie;
• flaga „is_unique” określa czy dopuszczalne są
instancje z tymi samymi wartościami.
T. Pankowski
25
Klasy abstrakcyjne, klasy liście i
klasy korzenie
• klasa nie może generalizować samej siebie,
• klasa nie może generalizować podklasy zawierającej element
modelu o tej samej nazwie co element zawarty lub
oddziedziczony w nadklasie (nie dopuszcza się przysłaniania,
over-riding);
• przy wielokrotnym dziedziczeniu żaden element modelu w
nadklasach nie może mieć tej samej nazwy; wyjątkiem jest
„diamond rule” pozwalająca nadklasom dziedziczyć ze
wspólnej nadklasy.
T. Pankowski
26
Asocjacje
• Klasa abstrakcyjna jest wyłącznie używana do
dziedziczenia. Nie ma żadnych obiektów, których typem
jest klasa abstrakcyjna.
• Klasa może być zdefiniowana jako „leaf” lub „root” i
wówczas nie może mieć, odpowiednio, żadnej podklasy
lub nadklasy.
T. Pankowski
• MOF dopuszcza dziedziczenie z jednej lub z wielu klas.
Jak w UML mówi się, że superklasa generalizuje
podklasę.
• Ograniczenia zapewniające sensowność i
implementowalność:
27
• Asocjacje wyrażają związki w metamodelu.
• Na poziomie M1 i M2 definiują związki (linki)
między parami instancji klas.
• Asocjacje nie mają ani tożsamości, ani
atrybutów, ani operacji.
T. Pankowski
28
Końce asocjacji
Krotność końców asocjacji
• Każda asocjacja w MOF zawiera dokładnie dwa końce
asocjacji opisujące końce powiązania.
• Końce asocjacji definiują następujące właściwości:
• Krotność końca asocjacji odnosi się do liczności zbioru
elementów będącego projekcją elementów drugiego
końca asocjacji (patrz następny slajd).
• Ponieważ duplikowanie związków jest niedozwolone,
zatem dla każdej ascocjacji „is_uniqueu” jest TRUE.
• Flaga „is_ordered” określa, czy projekcje z drugiego
końca są uporządkowane. Model MOF pozwala na
używanie etykiety „order” tylko dla jednego końca
asocjacji.
T. Pankowski
29
Krotność końców asocjacji
T. Pankowski
30
Agregacje
• W metamodelu MOF klasy i typy danych mogą być
powiązane z innymi klasami za pomocą asocjacji lub
atrybutów. W obydwu tych przypadkach zachowanie
się tych powiązań można określić jako semantyka
agregacji.
• Wyróżniamy trzy rodzaje semantyki agregacji między
instancjami
Na rysunku podany jest zbiór związków dla asocjacji z końcami o nazwach „left” w
klasie A i „right” w klasie B. Instancjami A są a1, a2 i a3, a instancjami B są b1 i b2.
Mamy 5 związków (linków). Projekcją elementu a1 jest zbiór {b1}, a projekcją b1 jest
zbiór {a1, a2, a3}. Jeśli b3 jest instancją klasy B i nie występuje w żadnym związku, to
jego projekcja jest zbiorem pustym. „Dolne” i „górne” ograniczenie końca asocjacji
określa dopuszczalną liczbę elementów w projekcji. Jeśli w rozważanym przykładzie
koniec „left” ma ograniczenie „0..3”, to projekcja dla każdej instancji z ekstensji klasy
B musi zawierać od 0 do 3 instancji klasy A.
• semantyka non-aggregate, równorzędne;
• semantyka composite, tj. „całość-część” – usunięcie całości
powoduje usunięcie powiązanych z nią części;
• semantyka shared (w obecnej wersji MOF niedostępna).
T. Pankowski
32
Agregacje asocjacyjne
Semantyka „non-aggregate”
• Semantykę agregacyjną asocjacji specyfikujemy za
pomocą atrybutu „aggregation” końca asocjacji.
Atrybut „aggregation” końca zbiorowego (composite)
ma wówczas wartość True, a końca składowego
(component) ma wartość False.
• Krotność (multiplicity) końca zbiorowego musi być
[0..1] lub [1..1].
• Instancja składowa nie może być komponentem wielu
kompozycji.
• Semantyka „non-aggregate” oznacza luźne powiązanie
między instancjami o następujących właściwościach:
T. Pankowski
33
Semantyka „composite”
T. Pankowski
34
Agregacje atrybutowe
• Semantyka „composite” określa silniejsze powiązanie
między instancjami o następujących właściwościach:
• powiązanie jest asymetryczne, jeden koniec oznacza
„kompozycję” lub „całość”, a drugi oznacza „komponent” lub
„część”,
• instancja nie może być komponentem w więcej niż jednej
kompozycji w żadnym powiązaniu kompozycyjnym,
• instancja nie może być komponentem samej siebie,
• usunięcie instancji kompozycji powoduje kaskadowe
usunięcie wszystkich jej komponentów,
• instancja nie może być komponentem instancji z ekstensji
innego pakietu (Composition Closure Rule).
T. Pankowski
• nie ma specjalnych restrykacji na liczność związków,
• nie ma specjalnych ograniczeń na pochodzenie instancji w
związkach,
• związki nie wpływają na cykl życia powiązanych instancji – w
szczególności usunięcie instancji nie powoduje usunięcia
instancji z nią powiązanych.
35
• Semantyka agregacyjna atrybutu zależy od typu
atrybutu. Na przykład:
• atrybut, którego typ określony jest jako DataType ma
semantykę „non-aggregate”;
• atrybut, którego typ określono jako Class ma
semantykę „composite”.
• Możliwe jest użycie DataType do zakodowania
typu Class. Pozwala to definiować atrybuty,
których wartości są instancjami Class bez
ponoszenia konsekwencji semantyki „composite”.
T. Pankowski
36
Asocjacje a atrybuty
Model obliczeniowy dla asocjacji
• Model MOF posiada dwie konstrukcje dla modelowania
powiązań między klasami, asocjacje i atrybuty.
• Mimo, że asocjacje i atrybuty są podobne z punktu
widzenia modelowania informacji, to jednak różnią się
zasadniczo z punktu widzenia ich modelu
obliczeniowego i odpowiadających im interfejsów.
• Asocjacje oferują model obliczeniowy zorientowany na
zapytania, „query-oriented”. Użytkownik wykonuje
operacje na obiekcie, który enkapsuluje zbiór
związków (linków).
• Zaleta: asocjacje pozwalają wykonywać zapytania
„globalne” nad wszystkimi związkami, a nie tylko nad
tymi, które dotyczą danego obiektu.
• Wada: Operacje dotyczące dostępu i aktualizacji
związków mają tendencje do nadmiernej złożoności.
T. Pankowski
37
T. Pankowski
38
Model obliczeniowy dla atrybutów
Referencje
• Atrybuty oferują nawigacyjny „navigation-oriented”
model obliczeniowy. Użytkownik zwykle wykonuje
operacje „set” i „get” na atrybutach.
• Zalety: Styl interfejsu typu „set” i „get” jest prostszy i
bardziej naturalny dla typowych aplikacji
zorientowanych na metadane, które trawersują
(obchodzą) graf metadanych.
• Wady: Wykonywanie zapytań „globalnych” nad
związkami wyrażonymi za pomocą atrybutów jest
obliczeniowo intensywne (computationally intensive).
• Model MOF udostępnia dodatkowy rodzaj cech
klas zwanych referencjami, które dostarczają
alternatywny dla atrybutów sposób widzenia
asocjacji. Specyfikacja referencji podaje:
T. Pankowski
39
• nazwę referencji w jej klasie,
• „eksponowany” (exposed) koniec asocjacji, którego
typem jest ta klasa lub jej nadklasa;
• „referencyjny” (referenced) koniec asocjacji, który
jest drugim końcem tej samej asocjacji.
T. Pankowski
40
Referencje
Referencje
• Definicja referencji w klasie powoduje, że wynikowy
interfejs zawiera operacje o sygnaturach identycznych
z tymi, jakie miałby równoważny atrybut. Jednak
zamiast operacji na wartościach w slocie atrybutu
instancji klasy, operacje pobierają i aktualizują
asocjację, a dokładniej projekcję względem asocjacji.
• Ilustruje to przykład na następnym slajdzie (w notacji
UML-podobnej).
Na rysunku klasa My_Class_1 jest powiązana z klasą My_CLass_2 za pomocą
asocjacji My_Assoc. My_Class_1 ma atrybut attr typu Integer oraz referencję o
nazwie ref, która odwołuje się do końca end_2 asocjacji My_Assoc.
W ten sposób udostępniony jest API dla ref pozwalający użytkownikowi na dostęp i
aktualizację linków z instancji My_Class_1 do instancji My_Class_2 za pomocą
operacji set i get.
W konwencji UML, ref jest atrybutem pochodnym klasy My_Class_1 typu
My_Class_2.
T. Pankowski
41
T. Pankowski
42
Cel CWM
CWM
March 2003
Version 1.1, Volume 1
formal/03-03-02 (str. 1-576)
Tadeusz Pankowski
Instytut Automatyki i Inżynierii Informatycznej
Politechnika Poznańska
• Zasoby danych w organizacji podwajają się co pięć lat.
• Magazynowanie danych (data warehousing) dostarcza metodę
transformacji danych w użyteczną i wiarygodną informację służącą
wspieraniu procesów podejmowania decyzji biznesowych, a więc pozwala
osiągnąć inteligencję biznesową (business intelligence).
• Jedną z najbardziej istotnych składowych magazynowania danych są
metadane (metadata). Metadane są używane do tworzenia,
utrzymywania, zarządzania i użytkowania zasobami danych. Rozwój
różnych systemów wspierających te procesy doprowadził do
różnorodności reprezentacji i traktowania metadanych.
• CWM jest odpowiedzią na potrzebę ujednolicenia podejść do metadanych.
Dostarcza bazę (framework) dla reprezentowania metadanych o
• źródłach danych i docelowych miejscach danych,
• transformacjach i analizach,
• operacjach tworzenia i zarządzania zasobami danych.
T. Pankowski
44
CWM (Common Warehouse
Metamodel)
• Standard OMG wymiany metadanych (metadata
interchange) w dziedzinie magazynowania danych
(data warehousing) i inteligencji biznesowej (business
intelligence).
• Magazynowanie danych (omawiane w standardzie CWM)
obejmuje: relacyjne bazy danych, struktury rekordów,
bazy wielowymiarowe (MOLAP), analiza danych (OLAP),
XML, transformację, prezentację, ...
• CWM określa:
• język metamodelu (metamodel) do opisu
metadanych
• język oparty na XML do wymiany metadanych
• funkcje API dostępu do metadanych
T. Pankowski
45
Poziom ObjectModel
• Rozszerza architekturę metamodelowania
OMG o pojęcia związane z magazynowaniem
danych i inteligencją biznesową
• Wzbogaca MDA o specyfikację
oprogramowania i o integrację systemów
T. Pankowski
46
Pakiet metamodelu ObjectModel
• Pakiet metamodelu ObjectModel udostępnia podstawowe konstrukcje
dla tworzenia i opisu klas we wszystkich innych pakietach CWM.
ObjectModel jest podzbiorem UML zawierającym tylko te cechy, które
są konieczne.
Management
Analysis
Resource
Foundation
Object
Model
Warehouse
Process
Transformation OLAP
Object
Relational
Warehouse
Operation
Data Information
Business
Mining Visualization Nomenclature
Record
Multi
Dimensional
XML
Business Data
Keys Type
Software
Expressions
Information Types
Index Mapping Deployment
Core
Behavioral
Relationships
Metamodel CWM
Instance
T. Pankowski
48
Element
0..1
requiredTag
*
TaggedValue
*
tag : Name
value : String
/modelElement : ModelElement
/stereotype : Stereotype
*
Dependency
kind : String
/client : ModelElement
/supplier : ModelElement
Pakiet Core
*
ModelElement
name : Name
visibility : VisibilityKind
/ clientDependency : Dependency
/ constraint : Constraint
/ importer : Package
ownedElement
*
/ namespace : Namespace
{ordered} * / taggedValue : TaggedValue
client 1..*
1..*
supplier
*
*
0..1
Namespace
Feature
ownerScope :ScopeKind
/owner : Classifier
Constraint
body : BooleanExp
/constrElem : ModelElement
*
stereotypeConstraint
0..1
Stereotype
constrained
baseClass
: Name
Stereotype
0..1
Pakiet (metamodel) Core (c.d.)
importedElement
/extendedElem : ModelElement
/requiredTag : TaggedValue
/stereotypeConstr : Constraint
StructuralFeature
{ordered}*
owner
0..1
changeability : ChangeableKind
multiplicity : Multiplicity
ordering : OrderingKind
tagetScopy : ScopeKind
/type : Classifier
Attribute
/ownedElement : ModelElement
Class
importer
*
Classifier
Package
isAbstract : Boolean
feature : Feature
/importedEle :
ModelElement
DataType
Subsystem
Model
T. Pankowski
initialValue : Expr
Metamodel Relationship
Metamodel Behavioral
T. Pankowski
51
50
Metamodel Instance
Przykład modelu
Przykładowy model opisuje osoby i powiązania małżeńskie między nimi.
Powiązania małżeńskie są reprezentowane za pomocą asocjacji
Marriage. Asocjacja Marriage ma dwa końce o nazwach „person” i
„spouse”. Każda instancja asocjacji ma atrybut o pojedynczej wartosci
podający aktualny status powiązania. Wartościami atrybutu
MaritalStatus są “Married”, “Divorced” i “Widowed”. Osoby, które
nigdy nie były w związku małżeńskim nie mają żadnej wartości.
T. Pankowski
53
Pakiet Relational
T. Pankowski
54
Pakiet Relational (c.d.)
Pakiet Relational zależy od następujących pakietów:
• org.omg::CWM::ObjectModel::Behavioral, • org.omg::CWM::ObjectModel::Core
• org.omg::CWM::ObjectModel::Instance, • org.omg::CWM::Foundation::DataTypes
• org.omg::CWM::Foundation::KeysIndexes
Odwołuje się do pakietów ObjectModel i Foundation – dziedziczy od klas tych pakietów.
Definiuje kontenery: Catalog, Schema rozszerzające klasę Package pakietu metamodelu
ObjectModel. ColumnSet i SQLStructuredType rozszerzają Class. Kolumny zawarte w
ColumnSet są rozszerzeniami Attribute pakietu ObjectModel. Typy danych dla kolumn
(SQLDataType) dziedziczą od klasy Classifier pakietu ObjectModel.
Pakiet Relational obejmuje także pojęcia związane z indeksowaniem (IndexedFeature,
Index), kluczami głównymi (PrimaryKey) i obcymi (ForeignKey). W tym celu rozszerza
odpowiednie pojęcia z pakietu Foundation. Pojęcia związane z procedurami SQL rozszerzają
pakiet Behavioral.
T. Pankowski
56
Kontenery Catalog, Schema i ich obiekty
Tabele i trigery
SQLIndex
/ownedElement filterCondition : String
isNullable : Boolean
* autoUpdate : Boolean
Package
(f ro m Co re)
DataManager
(from SoftwareDeployment)
Superclass
of Table
0.. 1
/namespace
*
*
/dat aPackage
Catalog
defaultCharacterSetName : String
defaultCollationName : String
0..1
/ownedElement
*
/ namespace
/namespace
0..1
Schema
UML Class
with attributes
displayed
0.. 1
*
/ownedElement
Procedure
*
0..1
Trigger
type : ProcedureType
eventManipulation : EventManipulationType /ownedElement
actionCondition : BooleanExpression
*
actionStatement : ProcedureExpression
/ownedElement
actionOrientation : ActionOrientationType
NamedColumnSet
conditionTiming : ConditionTimingType
/ optionScopeColumn : Column
conditionReferenceNewTable : String
/ type : SQLStructuredType
conditionReferenceOldTable : String
/ usingTrigger : Trigger
/ table : Table
/ usedColumnSet : NamedColumnSet
Immediate
Attributes
Reference
Package name
(from Relational)
Inheritance
relationship
/namespace
/namespace
NamedColumnSet
Class
name
Association
name
Association
End name
Association
End name
UML Class with
attributes
suppressed
TableOwningTrigger
Table
table
isTemporary : Boolean
temporaryScope : String 1
/ trigger : Trigger
isSystem : Boolean
Attribute
name
trigger
{ordered}
UML Association
Multiplicity of
“table” end
Attribute
type
*
Trigger
(from Relational)
*
Multiplicity of
“trigger” end
Constraint on
“trigger” end
Composite
Association
indicates
ownership
0..1
/ownedElement
Slashes indicate reuse of
inherited association
/namespace
Schema
(from Relational)
UML Class with
no attributes
Catalog zawiera wszystkie tabele/widoki i podlega zarządzaniu. Katalog zawiera także
schematy, Schema, które także zawierają tabele/widoki. Tabele składają się z kolumn, które
mają przypisany typy danych. Kontener Schema zawiera ponadto klasy Procedure, Trigger i
SQLIndex.
T. Pankowski
Tabele, kolumny i typy danych (c.d.)
Tabele, kolumny i typy danych
/constrainedElement
{ordered}
*
/type
Column
1 SQLDataType
*
* /constraint
precision : Integer
/structuralFeature typeNumber : Integer
scale : Integer
/feature
isNullable : NullableType
ColumnSet 0..1
/owner
* length : Integer
{ordered} collationName : String
characterSetName : String
/ optionScopeColumnSet : NamedColumnSet
/ referencedTableType : SQLStructuredType
/constraint
CheckConstraint
*
deferrability : DeferrabilityType
• ColumnSet reprezentuje dowolną postać danych relacyjnych.
• NamedColumnSet jest logicznym widokiem (View) lub fizyczną
tabelą (Table).
• QueryColumnSet jest wynikiem zapytania SQL-owego.
• Kolumny klasy Column są związane z SQLDataType za pomocą
asocjacji prowadzącej ze StructuralFeature do Classifier
odziedziczonej z metamodelu Core pakietu ObjectModel.
• Jako SQL-owe typy danych (SQLDataType) wyróżnia się typ prosty
SQLSimpleType i typ odrępny SQLDistinctType. Typy proste
wynikają ze standardu SQL, a typy odrębne definiowane są z typów
prostych.
T. Pankowski
58
59
NamedColumnSet
/ optionScopeColumn : Column
/ type : SQLStructuredType
/ usingTrigger : Trigger
QueryColumnSet
query : QueryExpression
SQLDistinctType
length : Integer
precision : Integer
scale : Integer
/ sqlSimpleType : SQLSimpleType
sqlDistinctType
{ordered}
/constrainedElement
*
Table
isTemporary : Boolean
temporaryScope : String
/ trigger : Trigger
isSystem : Boolean
*
SQLSimpleType
characterMaximumLength : Integer
1 characterOctetLength : Integer
numericPrecision : Integer
sqlSimpleType numericPrecisionRadix : Integer
numericScale : Integer
dateTimePrecision : Integer
View
isReadOnly : Boolean
checkOption : Boolean
queryExpression : QueryExpression