pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 27
w
Ocena standardu CWM w kontekście standardu SQL
2003 i projektowania relacyjnych baz danych
w
1 Wstęp
da
.b
w
Streszczenie. W artykule dokonano przeglądu pakietu Relational standardu
CWM oraz odpowiednich, zgodnych semantycznie, elementów standardu
SQL. W oparciu o przeprowadzoną analizę zaproponowano także ograniczenia zdefiniowane w języku OCL, które nałożone na metamodel CWM, zapewnią zgodność semantyczną wybranych elementów, ze standardem SQL
2003.
pl
s.
Projektowanie baz danych jest procesem wieloetapowym i sprowadza się do tworzenia modeli na różnych poziomach abstrakcji. Transformacja modeli pomiędzy poszczególnymi
poziomami abstrakcji odbywa się w oparciu o zdefiniowany zbiór reguł transformacji [9].
Model konceptualny, będący reprezentacją wycinka rzeczywistości, może być wyspecyfikowany za pomocą języka UML [10] w postaci diagramu klas. Model logiczny uzyskuje
się z modelu konceptualnego bazy dany. W przypadku, gdy jest on modelem relacyjnym
(technologicznie zależnym), wówczas do jego specyfikacji można użyć dedykowanego
profilu UML lub standardu SQL. Model fizyczny, uzyskany w wyniku przekształcenia modelu logicznego, wyrażony jest za pomocą języka specyficznego dla wybranej platformy
implementacyjnej [8]. Standard CWM (Common Warehouse Metamodel) używa notacji
UML do reprezentowania pojęć standardu SQL. W związku z powyższym może on być
wykorzystany do tworzenia modeli poziomu logicznego. CWM zdefiniowany został
w oparciu o standard SQL w wersji 99 [4], natomiast aktualną wersją, jest wersja 2003.
Z uwagi na występujące różnice pomiędzy wspomnianymi wersjami standardu SQL dokonano w pracy oceny użyteczność standardu w procesie projektowania relacyjnych baz
danych. Przeprowadzono analizę rozbieżności i ocenę ich wpływu na użyteczność standardu CWM. Jednocześnie uzupełniono standard CWM o ograniczenia wyrażone w języku
OCL, które wykluczyły możliwość zdefiniowania modelu logicznego bazy danych niezgodnego ze standardem SQL.
W kolejnym podrozdziale omówiony został pakiet Relational, w celu lepszego zrozumienia
poruszanego tematu.
Ewa Śliwa, Lech Tuzinkiewicz: Politechnika Wrocławska,
Instytut Informatyki Stosowanej,
Wybrzeże Wyspiańskiego 27, 50-370 Wrocław, Polska
email: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
E. Śliwa, L. Tuzinkiewicz
2 Pakiet Relational standardu CWM
w
Standard CWM [1], zaproponowany przez Object Management Group (OMG), stanowi
rozszerzenie metamodelu OMG i służy do wymiany metadanych. CWM jest zbiorem pakietów, które zawierają tematycznie pogrupowane metaklasy. Pakiet Relational, którego
elementy wykorzystywane są do modelowania obiektowo-relacyjnego, bazuje na części
standardu SQL99, składa się z dwudziestu czterech klas. Klasy pakietu można pogrupować
zgodnie z ich przeznaczeniem na sześć grup. Pierwszą grupę stanowią klasy definiujące
hierarchię obiektów: Catalog oraz Schema. Druga grupa, to zbiór klas definiujących
podstawowe elementy składowe schematu bazy danych: Column, ColumnSet, ColumnValue, QueryColumnSet, Row, RowSet, NamedColumnSet, Table, View, SQLDataType,
SQLSimpleType, SQLDistinctType oraz SQLStructuredType. Do trzeciej grupy, definiującej indeksy należą: SQLIndex oraz SQLIndexColumn. Czwarta grupa to klasy definiujące
integralność danych: CheckConstraint, UniqueConstraint, PrimaryKey oraz ForeignKey.
Do ostatniej, piątej grupy, należą klasy, które definiują aspekty dynamiczne bazy danych:
Trigger, Procedure oraz SQLParameter. Relacja pomiędzy omówionymi klasami przedstawiona została na rysunku poniżej.
da
.b
w
w
pl
s.
Rys. 1. Relacje pomiędzy klasami pakietu Relational standardu CWM ([1] strona 199)
270
Ocena standardu CWM w kontekście standardu SQL 2003 i projektowania relacyjnych baz danych.
3 Ocena zgodności CWM ze standardem SQL2003
w
Biorąc pod uwagę fakt, że w standardzie SQL 2003 [3] dokonano szeregu zmian polegających na dodaniu nowych elementów oraz usunięciu tych, które uznano za nieistotne, wymagana jest analiza zgodności elementów standardu CWM reprezentujących pojęcia języka
SQL. W tabeli 1. przedstawiono wyniki analizy zgodności semantycznej wybranych, (podstawowych z punktu widzenia modelowania bazy danych na poziomie logicznym) elementów standardu CWM ze standardem SQL 2003. Zestawienie to dokonane zostało z zachowaniem wprowadzonego w poprzednim podrozdziale podziału na grupy.
Tabela 1. Zestawienie pogrupowanych elementów standardu CWM ze standardem SQL
w
Element CWM
Catalog
Schema
Element CWM
Table
da
.b
w
Pierwsza grupa
Ocena
Zgodność na poziomie definicji.
Różnice na poziomie agregowanych elementów (np. indeksy, dziedzina) oraz braku ograniczeń wymuszających przynależność schematu do
katalogu oraz składowych schematu do schematu. Nie zostało nałożone ograniczenie na unikalność nazw schematów w obrębie katalogu.
Druga grupa
Ocena
Koncepcja tabeli w obu standardach jest odmienna. Standard
SQL2003 definiuje tabelę jako kolekcję wierszy tego samego typu –
Row Type – posiadającą przynajmniej jedną kolumnę. Tabela metamodelu CWM [5] jest zmaterializowanym, nazwanym zbiorem kolumn (wyznaczonym przez strukturalny typ danych), posiadającym
ograniczenie unikalności oraz mogącym posiadać klucze obce. Standard CWM dopuszcza jednak istnienie tabeli, która nie posiada żadnej
kolumny. Różnica w koncepcji bytu, reprezentującego tabelę, dotyczy
także jego podziału na rodzaje. Standard SQL 2003 wyróżnia tabele
bazowe (trwałe oraz tymczasowe), chwilowe oraz pochodne.
W CWM tabelę bazową reprezentuje klasa Table, której atrybut
isTemporary decyduje o tym, czy jest ona tymczasowa czy trwała.
W przypadku tabeli tymczasowej, jej zakres wyznacza atrybut
temporaryScope (zgodnie ze standardem SQL). Kolejny atrybut klasy
Table – isSystem – decyduje o fakcie, czy dana tabela jest systemową
czy też nie (jest to pewna nadmiarowość w stosunku do standardu
SQL). CWM dopuszcza, aby systemowa tabela była jednocześnie
tymczasową – brak jest odpowiedniego ograniczenia. Nie definiuje
także SQL-owej tabeli chwilowej. Klasa QueryColumnSet, nie
odpowiada w pełni SQL-owej tabeli pochodnej, ponieważ nie
obejmuje swym zasięgiem widoków.
W CWM [6] perspektywa jest nazwanym zbiorem kolumn, natomiast
w SQL 2003 - nazwaną tabelą pochodną, która może opierać się
zarówno na tabeli bazowej jak i na innej tabeli pochodnej. Jest to
istotna różnica, bowiem standard SQL w przeciwieństwie do CWM,
dopuszcza tworzenie widoków w oparciu o inną perspektywę. Ma to
wpływ na postać definicji perspektywy modyfikowalnej. Uzasadnia to
istnienie w SQL-u klauzuli WITH CHECK OPTION.
pl
s.
View
271
w
Column
SQLDataType
Element CWM
CheckConstraint,
ForeignKey,
UniqueConstraint,
PrimaryKey
Nie ma odpowiednika w standardzie SQL.
pl
s.
Element CWM
SQLIndex
SQLIndexColumn
da
.b
w
w
W matamodelu CWM klasa Column posiada atrybut initialValue
(odziedziczony po klasie Attribute z pakietu Core), który może stanowić SQL – wą wartość domyślną. Atrybut ten, typu Expression, jest
zapisanym w postaci łańcucha znaków wyrażeniem, którego wykonanie nadaje początkową wartość kolumnie. Dla kolumny określa się typ
danych (związek klasy Column z klasą SQLDataType) oraz fakt czy
dopuszcza ona nieokreśloność – podobnie jak w przypadku standardu
SQL. Konieczność określenia atrybutu length dla kolumny typu znalowego, która oznacza w przypadku łańcucha zmiennej długości jego
maksymalną długość, natomiast w przypadku łańcucha stałej długości
jego długość, może doprowadzić do sprzeczności. Podobny atrybut
(characterMaximumLength) zostaje określony dla klasy SQLSimpleDataType, z którym może być związana klasa Column. Brakuje jednak odpowiedniego ograniczenia, które strzegłoby równości wartości
obu atrybutów. Dla kolumny według SQL 2003, w odróżnieniu od
CWM, należy zaznaczyć, czy jej nazwa jest zależna od implementacji
oraz w przypadku, gdy bazuje ona na dziedzinie, należy ją wskazać
(CWM nie definiuje w ogóle pojęcia dziedziny). Ponadto SQL 2003
wprowadza kolumny typu IDENTITY oraz kolumny generowane,
których definicja wymaga podania większej ilości informacji, niż
definicja zwykłej kolumny. Zagadnienie to jednak nie miało szansy
zaistnieć w metamodelu CWM.
Standard SQL 2003 definiuje trzy rodzaje typów danych: predefiniowany, konstruowany (tablica, wielozbiór, referencja lub wiersz) oraz
definiowany przez użytkownika. SQL-owemu typowi predefiniowanemu odpowiada w CWM SQLSimpleType oraz SQLDistinctType.
Trzeci SQLStructuredType jest najbliższy definicji SQL – owego typu
wierszowego. W standardzie CWM nie ma typu zdefiniowanego przez
użytkownika.
Trzecia grupa
Ocena
Czwarta grupa
Ocena
Koncepcja ograniczeń, dzięki którym baza danych zachowuje integralność, jest także odmienna w obu standardach. SQL definiuje trzy
rodzaje ograniczeń integralności: tabelowe, dziedziny oraz asercje.
Ograniczenia tabelowe podzielone zostały z kolei na: unikalności,
referencji oraz zwykłe ograniczenie poprawności. W CWM klasa
CheckConstraint (specjalizująca klasę Constraint z pakietu Core)
reprezentuje SQL – owe ograniczenie poprawności. Nie jest ono
jednak w pełni zgodne ze standardem SQL 2003. Pokrywa się forma
definicji, którą stanowi wyrażenie logiczne, oraz omówione cechy
związane z walidacją. Jednakże w SQL – u ograniczenie poprawności
może dotyczyć tylko jednej tabeli, natomiast w CWM – wielu tabel.
Wydaje się więc, iż w metamodelu CWM ograniczenie poprawności
stanowi połączenie jego SQL – owej wersji oraz asercji. Poza tym
klasa CheckConstraint pozostaje w związku z klasami Table oraz
272
w
w
Element CWM
Trigger,
Procedure,
SQLParameter
da
.b
w
Column. Nie zostało jednak nałożone ograniczenie, które strzegłoby,
aby kolumny, z którymi jest związana jest klasa CheckConstraint,
należały do klasy Table, także będącej z nią w związku. SQL – owe
ograniczenie unikalności oraz jego specjalizacja w postaci
ograniczenia klucza głównego reprezentowane są w CWM poprzez
klasy UniqueConstraint oraz PrimaryKey Z kolei ograniczenie
referencji w CWM zamodelowane jest w postaci klasy ForeignKey,
która wiąże kolumny z jednej tabeli z kolumnami z innej lub tej samej
tabeli. Cechy obu tych ograniczeni odpowiadają definicji standardu
SQL. W metamodelu CWM nie jest jednak przestrzegana zasada
unikalności nazw ograniczeń. W przypadku ograniczenia klucza
obcego, brak jest ograniczenia, które wskazywałby, iż kolumny danej
tabeli, które zostają związane z kolumnami unikalnymi innej (lub tej
samej) tabeli muszą być tego samego typu.
Piąta grupa
Ocena
W obu przypadkach aspekt dynamiczny wyrażony jest za pomocą procedur składowanych oraz wyzwalaczy. Różnice występują w części
składniowej. CWM dopuszcza by procedura składowana posiada parametr typu return (niedopuszczalne w SQL – u, parametr tego typu
może posiadać jedynie funkcja składowana).
Znaczenie wyzwalaczy w obu standardach jest jednakowe, a istniejące
różnice dotyczą zakresu i sposobu ich wykorzystania. W matamodelu
CWM możliwe jest stworzenie wyzwalacza dla tabeli tymczasowej
(niedopuszczalne w standardzie SQL). Z kolei, w SQL możliwe jest
ograniczenie listy kolumn tabeli związanych z wyzwalaczem oraz
określenie znacznika czasu utworzenia wyzwalacza, który jest istotny
w sytuacji istnienia wielu wyzwalaczy dotyczących tego samego
zdarzenia (brak w CWM).
pl
s.
Głównym skutkiem rozbieżności standardu CWM oraz SQL jest brak jednoznacznej interpretacji definiowanych pojęć, co z kolei może przełożyć się na niezgodności przy przenoszeniu modeli pomiędzy platformami. Dla niektórych z wyżej omówionych niezgodności
zaproponowano ograniczenia, zdefiniowane w języku OCL [2], które je eliminują.
4 Przykład wykorzystania standardu CWM w projektowaniu relacyjnej bazy danych
Przedstawione w poprzednim podrozdziale rozbieżności pomiędzy standardami CWM
i SQL mogą mieć negatywny wpływ na jakość modelu logicznego. Wybrane przypadki
rozbieżności zostaną zilustrowane na przykładzie modelu logicznego, którego podstawę
stanowi model konceptualny związany z organizacją konferencji naukowych (rys. 2). Dla
każdego z tych przykładów zaproponowane zostanie ograniczenie zdefiniowane w języku
OCL [7].
273
w
w
w
da
.b
Rys. 2. Model konceptualny wycinka rzeczywistości związanego z organizacją konferencji
naukowych
Na rys. 3. przedstawiono realizację asocjacji zgłoszenie (rys. 2) w standardzie CWM.
Relacja ta pokazana jest za pomocą pogrubionej linii ciągłej i jest przykładem
niepoprawnej referencji w standardzie SQL (niezgodność typów powiązanych kolumn).
Poprawny związek reprezentowany jest przerywaną linią.
pl
s.
Rys. 3. SQL-owy związek referencji zamodelowany w standardzie CWM
Definicja ograniczenia (w języku OCL w wersji 2.0), eliminująca możliwość wystąpienia
omówionej wyżej sytuacji.
context ForeignKey inv:
let (s1 : Sequence (SQLDataType) = self.feature.type)
and (s2 : Sequence (SQLDataType) = self.unique.feature.type)
in
(s1->size() = s2->size()) and (s1->forAll(i:Integer | self->at(i)
= s2->at(i)))
274
Na rys. 4. zamodelowana została klasa Artykuł (rys. 2) w standardzie CWM. Jest to
przykład prezentujący możliwość zdefiniowania typu łańcuchowego dla kolumny z niejednoznacznie określoną długością (wyróżnione obiekty definiują dwa różne rozmiary kolumny typu łańcuch znaków).
w
w
w
Rys. 4. Model tabeli w standardzie CWM
omówionej wyżej sytuacji.
da
.b
context Column inv:
not(self.length->oclIsInvalid())
implies (self.type->oclIsTypeOf(char) or
self.type->oclIsTypeOf(varchar)) and
(self.length = self.type.characterMaximumLength)
pl
s.
Na rys. 5. zamodelowane zostało ograniczenie związane z wycinkiem rzeczywistość, które
na rys. 1. oznaczone jest w postaci notki. W CWM rolę SQL-owej asercji spełnia klasa
CheckConstraint. Jest to przykład prezentujący możliwość zdefiniowania ograniczenia,
w którego ciele wykorzystywane będą kolumny tabel, z którymi dane ograniczenie nie jest
związane (sytuacja niedopuszczalna w SQL). Pogrubiona linia obrazuje błędny związek
pomiędzy instancją klasy CheckConstraint oraz instancją klasy Column, która nie należy do
tabel związanych z ograniczeniem.
omówionej wyżej sytuacji
context CheckConstraint inv:
let cc : Set(Column)=self.constrainedElement->
select(elem|elem->oclIsTypeOf(Column))
and
ct : Set(Column)=
(self.constrainedElement->select(elem|elem->oclIsTypeOf(Table)))
->select(self.feature)
in
ct->includesAll(cc)
275
w
da
.b
w
w
Rys. 5. SQL-owa asercji zamodelowana w standardzie CWM za pomocą klasy
CheckConstraint
context Table inv:
let s : Set(String) = self.trigger.name
and
b : Bag(String) = self.trigger.name
in
s->size() = b->size()
pl
s.
W metamodelu CWM brakuje ograniczenia związanego z zachowaniem unikalności nazw
jednego typu elementu w przestrzeni nazw (sytuacja niedopuszczalna w SQL). Na przykład
dopuszczalne jest, aby katalog zawierał schematy o tej samej nazwie lub, aby wyzwalacze
danej tabeli posiadały nieunikalne nazwy.
Metamodel CWM dopuszcza także możliwość zdefiniowania tymczasowej tabeli
systemowej (sytuacja niedopuszczalna w SQL) oraz wyzwalacza dla tabeli tymczasowej.
context Table inv:
self.isSystem implies self.isTemporary = False
oraz
context Table inv:
self.isTemporary implies self.trigger->isEmpty()
276
5 Wnioski
w
W projektowaniu baz danych istotną rolę odgrywają standardy dotyczące modelowania
i przetwarzania danych. Standardem, który może być wykorzystany do modelowania na
poziomie logicznym jest standard CWM, który został stworzony na podstawie standardu
języka SQL99 [4]. Z uwagi na to, iż alternatywnym rozwiązaniem specyfikacji modelu na
poziomie logicznym jest standard SQL 2003 dokonana została ocena zgodność pakietu
Relational standardu CWM w zakresie zgodności reprezentowanych pojęć względem
standardu SQL 2003. Przeprowadzona analiza wykazała, że:
− Różnice, na poziomie semantycznym, pomiędzy elementami standardów CWM oraz
SQL mogą mieć negatywny wpływ na jakość modelu logicznego wyspecyfikowanego za pomocą standardu CWM.
− Standard CWM wymaga uzupełnienia o ograniczenia, które zapewnią zgodność
semantyczną w zakresie reprezentowanych elementów standardu SQL.
− Standard CWM, pomimo rozbieżności w stosunku do aktualnej wersji standardu
SQL, może być praktycznie wykorzystywany.
Ponadto:
− Istnieją narzędzia oparte o standard CWM wspierające proces projektowania baz
danych
− Model logiczny utworzony w oparciu o standard CWM może być przenoszony
pomiędzy różnymi platformami.
Standard CWM powinien być utrzymywany oraz wciąż rozwijany.
1.
da
.b
w
w
Literatura
pl
s.
Common Warehouse Metamodel (CWM) Specification, March 2003, Version 1.1, Volume
1 formal /03-03-02. Wersja elektroniczna specyfikacji dostępna jest na stronie internetowej:
http://www.omg.org/technology/cwm/ .
2. OCL 2.0 Specification, Version 2.0. Wersja elektroniczna specyfikacji dostępna jest na stronie
internetowej: http://www.omg.org/docs/ptc/03-10-14.pdf .
3. Information technology – Database languages – SQL 2003 – Part 2 : Foundation.
4. Information technology – Database languages – SQL 99 – Part 2 : Foundation
5. Poole J., Chang D., Tolbert D., Mellor D.:Common Warehouse Metamodel Developer’s Guide,
Wiley Publishing, Inc., Indianapolis, Indiana.
6. Poole J., Chang D., Tolbert D., Mellor D.:Common Warehouse Metamodel John Wiley & Sons,
Inc., New York 2002.
7. Warmer J., Kleppe A.: OCL precyzyjne modelowanie w UML, WNT, Warszawa 2003
8. Teorey T., Lightstone S., Nadeau T.: Database Modeling & Design: Logical Design, Elsevier
Inc., 2006.
9. Muller R.: Bazy danych. Język UML w modelowaniu danych, Wydawnictwo Mikom 1999.
10. UML specification version 2.0. Wersja elektroniczna specyfikacji dostępna jest na stronie
internetowej: http://www.uml.org/
277
w
da
.b
w
w
pl
s.
278

pobierz plik referatu

Transkrypt

Podobne dokumenty

Konsulat Chicago

Zaproszenie na seminarium Beep on Part I

Rekrutacja studentów na praktyki zagraniczne

Plakat

Ankieta wolontariacka

tutaj - Centrum Wychowania Morskiego ZHP

Młodszy Analityk Danych (Junior Data Analyst)

NET Developer

Karta Pracy Wolontariusza