Rozdział monografii: `Bazy Danych: Rozwój metod i technologii

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 10
w
Zarządzanie wersjami warstwy ORM
sterowane atrybutami
w
da
.b
w
Streszczenie. Warstwa ORM (Object Relational Mapping), dość powszechnie spotykana we współczesnych systemach informacyjnych, jest zależna od
wielu czynników, które ulegają zmianom, m.in. od zmiennej struktury danych relacyjnych, typu i wersji DBMS, czy typu i wersji samego narzędzia
użytego do zbudowania ORM. Czynniki te ewoluują w sposób w dużej mierze niezależny, ale zmiany każdego z nich mogą wymuszać modyfikowanie
warstwy ORM. W pracy przedstawiono propozycję zastosowania wersjowania sterowanego atrybutami, w którym uwzględnia się niezależność wielu
czynników wpływających na ewolucję systemu, biorąc pod uwagę także
pewne ograniczenia owej niezależności. Opis wersji, skonstruowany z atrybutów, służy następnie do sterowania generacją wersji ORM na podstawie repozytorium zbudowanego z użyciem języka XVCL – opartego na idei programowania generatywnego języka opisu wariantów oprogramowania.
1 Wprowadzenie
pl
s.
Współczesne systemy informacyjne często programowane są w obiektowych językach programowania (np. Java, C++, C#, Delphi), tymczasem dane z reguły składowane są w relacyjnych bazach danych. Jedną w często stosowanych metod połączenia tych dwóch „światów” jest użycie warstwy tzw. odwzorowania obiektowo-relacyjnego – ORM (ObjectRelational Mapping). Do tworzenia takiej warstwy służą specjalne, dość popularne narzędzia (np. Hibernate czy TopLink), a jej istnienie przewidziane jest w wiodących architekturach systemów informacyjnych (np. JPA w JEE).
Warstwa ORM stanowi interfejs między różnymi częściami systemu i musi być nich dostosowana; zmiany funkcjonalne i technologiczne, zarówno po stronie bazy danych jak
i aplikacji, wpływać mogą na ORM. Zmienność warstwy ORM zależy zatem od wielu niezależnych czynników.
Praca opisana tutaj ma pokazać przydatność modelu wersjowania sterowanego atrybutami [2], w połączeniu z technikami programowania generatywnego i językiem XVCL [5],
do zarządzania zmiennością warstwy ORM. Zarządzanie wersjami powinno, zgodnie z [9],
umożliwiać tworzenie pierwszej i kolejnych wersji, identyfikację, wybór i ekstrakcję werAndrzej Grudzień, Tomasz Traczyk
Politechnika Warszawska, Instytut Automatyki i Informatyki Stosowanej, ul. Nowowiejska 15/19, 00665 Warszawa, Polska
email: [email protected], [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
A. Grudzień, T. Traczyk
w
sji. W tej pracy skupiono się na sposobie zapisu wersji oraz wyborze właściwej wersji i jej
ekstrakcji.
Praca ta jest częścią większego zamierzenia [10]: zbadania możliwości użycia programowania generatywnego i języka XVCL jako środka do zarządzania zmianami całości projektów – wszystkich ich części i warstw, poczynając od modeli konceptualnych, a na dokumentacji gotowego systemu kończąc – w systemach informacyjnych mających wiele równoczesnych wariantów i zbudowanych z użyciem współczesnych technologii wykorzystujących bazy danych oraz nowoczesne środowiska budowania aplikacji.
1.2 Podstawowe założenia
1.3 Podobne prace
da
.b
w
w
System informacyjny, którego częścią jest ORM, podlega ciągłej zmienności, wymuszanej
zmianami wymagań funkcjonalnych i pozafunkcjonalnych, pojawianiem się nowych wersji
oprogramowania itp. Zmienność nie polega jednak tylko na ukazywaniu się kolejnych wydań; istnieć mogą także równoległe warianty, np. związane z wykorzystaniem różnych systemów zarządzania bazami danych czy narzędzi ORM, a także przeznaczeniem dla różnych
klientów, których wymagania mogą się nieznacznie różnić.
Założono, że cały opis systemu, w tym warstwy ORM, będzie zawarty w XML-owym
repozytorium [10], w którym wersje artefaktów będą opisane za pomocą języka XVCL
[14]. Struktury danych, kod aplikacji, modele analityczne oraz dokumentacja systemu są
traktowane jako równorzędne artefakty, których zmienność powinna być zarządzana w ten
sam sposób. Zastosowany sposób zapisu oraz zarządzania wersjami muszą być więc dość
ogólne, a nie wyspecjalizowane pod kątem specyficznej części projektu czy rodzaju kodu.
Założono także, że struktura repozytorium musi być na tyle klarowna, by było możliwe
zarządzanie nim bez użycia specjalnych narzędzi („ręczne”) oraz by na podstawie przeglądu plików repozytorium można było łatwo odczytać, jak przebiegała ewolucja systemu.
pl
s.
Koncepcję zastosowania modelu wersjowania opartego na atrybutach do zarządzania komponentami będącymi podstawą systemów biznesowych można znaleźć w [2], [3]. Prace te
przestawiają ogólne podejście, w którym komponenty są opisywane poprzez zbiory interfejsów dostarczanych i wymaganych. Model wersjowania użyty w tej pracy został wybrany
jako baza dla prezentowanego w tym opracowaniu.
Jeszcze szerszy przykład zastosowania modelu wersjowania opartego na atrybutach
można znaleźć w języku PCL (Proteus Configuration Language) [11]. Tam jest on składową metody opisu elementów systemu, rozpoczynając na elementach sprzętowych, a na dokumentacji kończąc. Samo wykorzystanie modelu opartego na atrybutach jest nieco prostsze, gdyż dopuszczalne wartości atrybutów są definiowane jako zbiory a nie taksonomie.
Niniejsza praca różni się od wymienionych w dwóch istotnych kwestiach. Po pierwsze,
zajmuje się zagadnieniem o znacznie mniejszym zakresie, co pozwala na wprowadzenie
ograniczeń w modelu wersjowania, zmniejszając jego złożoność. Po drugie i ważniejsze,
przytoczone prace zajmują się ewolucją obiektów jako kompletnych artefaktów, natomiast
proponowane tu podejście, dzięki wykorzystaniu techniki generatywnej, pozwala odnotowywać zmiany składowych i cech obiektów, zapisanych w nieredundantny sposób.
128
Sterowane atrybutami zarządzanie wersjami warstwy ORM
2 Wersjowanie sterowane atrybutami
w
Wersjowanie sterowane atrybutami [2], jest spotykane dość często. Przykład jego zastosowania znajdziemy chociażby w narzędziu CVS [1], gdzie stosowane jest – w postaci znaczników (tags) – do zarządzania konfiguracjami obiektów. W tym modelu wersjowania każda
wersja obiektów jest opisana za pomocą zbioru par (atrybut, wartość). Atrybuty mogą reprezentować cechę wersji obiektu (np. język narodowy) lub relację z innym obiektem należącym do systemu lub zewnętrznym (np. system operacyjny).
W ramach tego modelu można wyróżnić dwa podejścia. Pierwsze z nich, stosujące atrybuty o charakterze opisowym (np. opis zmiany czy nazwisko wprowadzającego ją), nie wymaga szczególnego komentarza. Przykład wykorzystania można znaleźć w [7]. Drugie podejście, stosujące atrybuty taksonomiczne, stanowi postawę opisanego tu rozwiązania.
Atrybuty taksonomiczne posiadają taksonomie określające dopuszczalne wartości oraz
opisujące relacje między nimi. Istnieją różne sposoby wyrażenia taksonomii (np. kostka,
drzewo, czy proponowany w [2] zbiór częściowo uporządkowany).
Oprócz taksonomii podstawowej, która obejmuje wszystkie dopuszczalne wartości jednego atrybutu, atrybuty mogą posiadać taksonomie pomocnicze, które nie zawierają
wszystkich wartości atrybutu, ale mogą obejmować wartości innych atrybutów. Umożliwia
to zapis wiedzy o dodatkowych relacjach, a także narzucenie ograniczeń.
Na rys. 1 przedstawiono przykład dwóch atrybutów taksonomicznych, które mogą być
użyte do opisu obiektów warstwy ORM. Ich zbiory wartości dopuszczalnych są wyznaczone poprzez taksonomie główne (1 i 2), zaś taksonomia pomocnicza (3) modeluje ograniczenie „jeżeli wariant jest przeznaczony dla klienta akceptującego tylko Oracle, to może mieć
tylko cechy przewidziane dla narzędzi dobrze współpracujących z Oracle”.
da
.b
w
w
pl
s.
Rys. 1. Przykładowe atrybuty i taksonomie
2.1 Wybór modelu wersjowania do zarządzania ewolucją ORM
Szukając właściwego modelu wersjowania dla problemu ORM, oprócz modelu opartego na
atrybutach rozważano zarówno tradycyjne modele sekwencyjny i równoległy, jak i modele
zaawansowane, takie jak model zorientowany na zmiany [8], czy model oparty na środowisku zmian [12].
129
w
Model sekwencyjny staje się niepraktyczny już w przypadku, gdy konieczne jest jednoczesne utrzymywanie wersji już dostarczonej klientowi oraz rozwijanie kolejnego wydania.
Także w przypadku, gdy produkt jest dostarczany w więcej niż jednym wariancie równocześnie, ten model zawodzi.
Model równoległy, popularny w powszechnie przyjętych rozwiązaniach (CVS, Subversion), także nie jest wystarczający. Ze względu na działanie warstwy ORM na styku dwóch
elementów systemu: schematu zrealizowanego w relacyjnej bazie danych i obiektowego
programu, w zarządzaniu ewolucją trzeba uwzględnić wiele czynników, podczas gdy model
równoległy umożliwia modelowanie tylko jednej relacji (zwykle „pochodzi od”). Dobrym
przykładem jest tu chociażby przypadek, gdy system jest utrzymywany jednocześnie dla
różnych systemów zarządzania bazami danych i dwóch klientów o nieco odmiennych wymaganiach co do struktur danych. W modelu równoległym należałoby utworzyć oddzielną
równoległą ścieżkę dla każdej z 4 kombinacji oraz wybrać arbitralnie jedną z nich jako
„pień”. Ewentualna zmiana, np. związana z wykorzystaniem możliwości nowej wersji jednej z baz, musi być wprowadzona w dwóch miejscach. Gdy uwzględnimy dodatkowe czynniki, takie jak różne narzędzia ORM, problem staje się dotkliwy. Co gorsza, dla niektórych
zmian może okazać się niemożliwe ustalenie po fakcie, który z czynników spowodował
powstanie nowej wersji.
W modelu opartym na atrybutach każdy czynnik może być modelowany osobno jako
atrybut lub kombinacja kilku atrybutów. Jednocześnie opis pojedynczej wersji czy wariantu
w postaci zbioru par atrybut-wartość jest zrozumiały i wygodny dla użytkownika. Model
bazujący na atrybutach umożliwia także wygodne wyszukiwanie wersji właściwej w danej
sytuacji przez odpowiednie wykorzystanie taksonomii przypisanych atrybutom, z jednoczesnym zachowaniem zdefiniowanych ograniczeń.
Bardziej zaawansowane modele cechują się większą złożonością i trudnością opanowania, co jest sprzeczne z jednym z podstawowych założeń przedsięwzięcia, to jest by istniała
możliwość zrozumienia wszystkich zapisów w repozytorium i – w razie potrzeby – wprowadzania modyfikacji bez użycia specjalnych narzędzi.
Główne przyczyny wyboru modelu opartego na atrybutach to zatem: łatwość modelowania różnych czynników mogących wymuszać zmiany systemu, duża ilość informacji semantycznej, możliwa do zapisania w wartościach atrybutów, rozwinięte możliwości wyszukania właściwej wersji oraz możliwy do opanowania poziom komplikacji.
da
.b
w
w
pl
s.
2.2 Dostosowanie modelu wersjowania do zarządzania wersjami ORM
Dla określenia powiązań między wartościami atrybutu wybrano zbiory częściowo uporządkowane, co wynikło z obserwacji, że w przypadku ORM niektóre atrybuty będą odpowiadać wersjowaniu równoległemu użytych produktów, na przykład narzędzia ORM. Prostszy
model drzewa nie zapewnia odwzorowania dla częstej operacji łączenia (merge), którą
można znaleźć na przykład w przypadku gdy wydawana jest nowa wersja narzędzia ORM
zawierająca cechy dwóch poprzednich wersji, a użytkownik posiada już wcześniej opracowane warianty współpracujące z owymi wersjami.
Podstawę opisywanego sposobu zarządzania wersjami stanowią atrybuty taksonomiczne.
Każdy z nich posiada jedną taksonomię główną, oraz może posiadać pewną liczbę taksonomii pomocniczych, przy czym taksonomie pomocnicze stanowią tylko ograniczenia, to jest
nie biorą udziału w wyszukiwaniu wersji, a jedynie ograniczają zbiór wynikowy. Taksonomia pomocnicza może zawierać wartości wielu różnych atrybutów, przez co można wyrażać zależności między nimi, np. relację współpracy wariantu jednego obiektu z określonym
130
w
zbiorem wariantów innego. Decyzja o ograniczeniu roli taksonomii pomocniczych tylko do
definiowania ograniczeń jest podyktowana chęcią utrzymania względnej prostoty modelu
i zapewnienia łatwego do interpretacji sposobu definiowania ograniczeń.
Użycie atrybutów o charakterze opisowym jest także dopuszczalne, przy czym w wyszukiwaniu wersji może występować albo odwołanie do konkretnej wartości, albo deklaracja,
że dany atrybut nie jest istotny. Nie jest dopuszczalne umieszczanie odwołań do wartości
takich atrybutów w taksonomiach pomocniczych atrybutów taksonomicznych. Założenie to
ma na celu utrzymanie wyłącznie opisowego charakteru tej grupy atrybutów.
Atrybuty podzielono na trzy kategorie: systemowe, wbudowane oraz użytkownika. Atrybuty systemowe i wbudowane muszą być użyte dla każdego projektu. Różnica polega na
sposobie ustalania wartości tych atrybutów. Dla atrybutów wbudowanych decyzję o wartościach i powiązaniach między nimi podejmuje użytkownik, natomiast dla systemowych
istnieją określone ścisłe reguły, zarówno dla wartości, jak i powiązań między nimi. Atrybuty użytkownika mogą są tworzone osobno dla poszczególnych projektów i użytkownik nie
jest ograniczony w ich tworzeniu.
Proponowane atrybuty systemowe to:
− czas dodania – atrybut taksonomiczny, w którym wartościami są stemple czasowe
utworzenia wersji/wariantu obiektu, a taksonomia ma postać szeregowej listy uporządkowanej według rosnącej wartości;
− identyfikator wprowadzającego zmianę – atrybut którego wartościami są identyfikatory użytkowników systemu, a taksonomia grupuje je według ról;
− typ i wersja DBMS.
da
.b
w
w
3 Realizacja zarządzania wersjami ORM
pl
s.
Warto zauważyć, że dwa pierwsze atrybuty systemowe nie mają ścisłego związku
z problematyką ORM, a raczej stanowią odpowiednik rozwiązań typowo spotykanych
w narzędziach do zarządzania wersjami. Kolejny służy natomiast do integracji z częścią repozytorium opisującą schemat bazy danych1. Atrybutem wbudowanym jest typ i wersja narzędzia ORM. Przykłady atrybutów użytkownika to zaś np. docelowe środowisko wdrożenia wariantu/wersji.
Podział na kategorie ma znaczenie przy ustalaniu taksonomii pomocniczych dla atrybutów. Po pierwsze tworzenie tych taksonomii przez użytkownika jest dozwolone tylko dla
atrybutów wbudowanych i użytkownika. Po drugie, dla zachowania prostej struktury zależności, zabronione jest korzystanie z wartości atrybutów użytkownika w taksonomiach pomocniczych atrybutów wbudowanych. Jako że atrybuty systemowe mają swoje odrębne reguły, nie ma potrzeby podawania dla nich dodatkowych ograniczeń.
Aby zrealizować zarządzanie ewolucją ORM, oprócz modelu wersjowania określić trzeba
także sposób zapisu informacji o odwzorowaniu między strukturami relacyjnymi a obiektowymi, mechanizm wyszukiwania wersji oraz sposób tworzenia artefaktów dla narzędzia
ORM. Implementację przedstawionego pomysłu oparto na języku XVCL, wspieranym
przez pomocnicze zastosowanie języka XQuery.
1
Wersję schematu bazy danych określają zarówno atrybuty systemowe (np. typ i wersja DBMS),
jak i użytkownika (związane np. z wersją wymagań, użytkownikiem itp.).
131
w
XVCL [14] to język i metodologia programowania generatywnego [5]. Podstawowym
elementem tego języka są tzw. x-ramki zapisane w XML. Na x-ramkach wykonuje się operację adaptacji, która powoduje wygenerowanie wynikowego dokumentu, np. programu. Xramki tworzą hierarchię, w której ramki wyższego poziomu wywołują (adaptują) ramki niższego poziomu, sterując adaptacją m.in. za pomocą przekazywanych zmiennych. Ramka
specyfikacyjna jest to ramka najwyższego poziomu, od której rozpoczyna się przetwarzanie. Stosowany w ramkach znacznik <select> umożliwia wybór fragmentów ramki przeznaczonych do przetwarzania na podstawie wartości zmiennej określonej przez atrybut
option. Przetwarzane są wszystkie elementy <option>, których atrybut value ma wartość
równą wartości podanej zmiennej. Deklaracja zmiennej, z jednoczesnym nadaniem wartości, wykonywana jest przy użyciu znacznika <set>. Zmienna jest widoczna w ramce, w której została zadeklarowana, oraz w ramkach przez nią adaptowanych.
XQuery [13] jest deklaratywnym językiem zapytań, przeznaczonym do operowania na
dokumentach XML. W projekcie język ten jest wykorzystywany do nawigacji po taksonomiach i stworzenia x-ramki specyfikacyjnej na podstawie konfiguracji. Użycie XVCL do
tego celu jest znacząco utrudnione, gdyż XVCL jest skonstruowany z myślą o generacji
nowych obiektów, a nie o przeglądaniu i modyfikowaniu istniejących, w szczególności
brak w nim możliwości łatwego przetwarzania grafów.
w
w
da
.b
3.1 Zapis wersji encji i związków
Podlegającymi wersjowaniu obiektami opisującymi strukturę danych są encje, odpowiadających klasom w odwzorowaniu, oraz związki. Każdy z obiektów jest zapisany w odrębnej
x-ramce. Szkielet każdej x-ramki opisu stanowią znaczniki <select>, jak poniżej:
pl
s.
<select option="selectingVariable">
<option value="?@Operating-system=OS;DB-type=Oracle?">
<set var="?@objectId?:Present" value="true"/>

</option>
<option value="?@Operating-system=WinXP;DB-type=Postgres?">
<set var="?@objectId?:Present" value="false"/>

</option>

</select>
Wartość zmiennej selectingVariable w trakcie interpretacji jest zawsze ustawiana na
true. Dla zmiennych sterujących, występujących w atrybutach value elementów <option>,
jest określony schemat tworzenia nazw, które stanowią serializację zbioru par atrybut-wartość opisujących wersje i warianty: każda wartość poprzedzana jest nazwą jej atrybutu
i znakiem równości, wartości poszczególnych atrybutów są oddzielone średnikami, a kolejność występowania jest alfabetyczna. Wartości tych zmiennych są definiowane w ramce
specyfikacyjnej. W zależności od tego, czy zostanie im nadana wartość true, czy inna, po
przetworzeniu tej klauzuli zmienne opisujące obiekt będą miały wartość taką jak w pierwszym lub w drugim elemencie <option> (gdy więcej niż jedna z ze zmiennych sterujących
będzie miała wartość true, wartości zmiennych będą wyznaczone przez ostatni „pasujący”
element <option>). Nie prowadzi to do komplikacji jeśli przestrzega się zasady, według
której przy dodawaniu nowej wersji odpowiadający jej element <option> dopisuje się po
już istniejących oraz stosuje się zasady modyfikacji taksonomii opisane dalej.
Opis encji składa się z jednego elementu <select>, opisującego cechy encji jako całości,
takie jak nazwa czy główna tabela odpowiadająca jej w bazie, oraz po jednym elemencie
132
w
<select> na każdy atrybut (odpowiadający kolumnie tabeli relacyjnej). Jeżeli kolumna
w tabeli relacyjnej jest kluczem obcym, to nie jest reprezentowana w obiekcie encji, gdyż
jej istnienie wynika z opisu związku.
Opis związku składa się zawsze z trzech elementów <select>. Pierwszy, tak jak w przypadku encji, zawiera ogólne cechy (nazwa, typ), a dwa pozostałe – wskazanie encji stanowiących końce związku oraz dodatkowe cechy, takie jak nawigowalność.
Cechy obiektów i ich składowych zostały wybrane w taki sposób, by zapewnić kompatybilność z Java Persistence API, jako najnowszym standardem w dziedzinie ORM dla języka Java.
w
3.2 Zapis konfiguracji
da
.b
w
Konfiguracja systemu zapisywana jest jako x-ramka, w której użytkownik musi zdefiniować następujące trzy elementy: zbiór par atrybut-wartość wybierający wersje obiektów
z repozytorium, nazwę generatora (opisanego dalej) oraz nazwę zbioru strojącego [4], zawierającego techniczne parametry ORM.
Dwa ostanie elementy są związane z zastosowaniem metodyki generatywnej i nie mają
znaczenia z punktu widzenia problemu wersjowania, natomiast według wymienionego jako
pierwszy zbioru wartości atrybutów wyznaczane są zmienne sterujące. Istotne jest założenie, że niezależnie od rozbudowy taksonomii atrybutów, raz określona konfiguracja musi
zawsze powodować wygenerowanie tych samych artefaktów.
Wspomniany wyżej generator [4] jest to zbiór x-ramek opisujących meta-ORM, tj. zawierających definicje generycznych metakomponentów, które zostają dopasowane do konkretnej sytuacji w procesie adaptacji x-ramek, sterowanym przez konfigurację. Generator
ten jest używany przetworzenia zbioru zmiennych, powstającego w rezultacie opisanej wyżej interpretacji ramek obiektów, na finalny kod warstwy ORM.
3.3 Zapis taksonomii
Taksonomie atrybutów zapisywane są w plikach XML o strukturze przedstawionej poniżej:
pl
s.
<taxonomies>

<taxonomy for-attribute="nazwa_atrybutu" name="nazwa_taksonomii">
<element name="wartosc_atrybutu">
<belongs-to distance="0" name="wartosc_atrybutu"/>
<belongs-to distance="1" name="inna_wartosc_atrybutu"/>
</element>

</taxonomy>

<taxonomy name="nazwa_taksonomii">
<element name="wartosc_atrybutu" for-attribute="nazwa_atrybutu">
<belongs-to distance="0" name="wartosc_atrybutu"
for-attribute="nazwa_atrybutu"/>
<belongs-to distance="1" name="inna_wartosc_atrybutu"
for-attribute="inna_nazwa_atrybutu"/>
</element>

</taxonomy>
</taxonomies>
Jak widać, dla każdej wartości atrybutu podawane są wszystkie wartości będące dla niej
przodkiem w grafie taksonomii.
133
Konstrukcja tego zapisu ma przede wszystkim na celu wygodne i efektywne przetwarzanie z pomocą XQuery, stąd między innymi wymienianie wszystkich przodków elementu,
upraszczające znacząco proces wyznaczania wartości zmiennych sterujących.
Nowe wartości atrybutu do taksonomii można dodawać tylko jako liście grafu. Gdyby
dopuścić możliwość wstawiania nowych wartości pomiędzy istniejące, to byłaby możliwa
sytuacja, w której to samo wyszukiwanie wersji, wykonane przed i po modyfikacji taksonomii dałoby różne wyniki.
w
3.4 Wyznaczanie elementów konfiguracji
da
.b
w
w
W celu wyszukania należących do konfiguracji wersji elementów wykonuje się zapytanie,
podające uporządkowany zbiór par atrybut-wartość. Odpowiedni skrypt w języku XQuery
wyznacza wartości zmiennych sterujących występujących w x-ramkach, zgodnie z następującymi regułami.
1) Tworzony jest zbiór wszystkich nazw zmiennych sterujących występujących w ramkach repozytorium.
2) Każda z tych nazw jest rozbijana na uporządkowany zbiór par atrybut-wartość.
3) Dla każdego zbioru sprawdzane jest, czy spełnia on warunki zapytania, tj.
a) dla każdego atrybutu opisowego zachodzi równość wartości lub w zapytaniu dla
danego atrybutu użyto wartości uniwersalnej;
b) wartości atrybutów taksonomicznych są równe tym z zapytania lub też są ich
przodkami (nie jest to równoważne wcześniejszej wersji, ale daje bardziej racjonalne wyniki w przypadku, gdy wersja dziedziczy cechy po wersjach mających
wspólnego przodka).
4) Dla każdego zbioru, który przeszedł poprzednie kroki, sprawdzane jest dla każdego
atrybutu taksonomicznego, czy jego wartość występuje w jednej z taksonomii pomocniczych. Jeżeli tak, to dla każdego z każdego z pozostałych atrybutów taksonomicznych sprawdzane jest czy jego wartość jest w relacji wyznaczonej przez taksonomię pomocniczą. Jeżeli dla dowolnego atrybutu wynik będzie negatywny, to
sprawdzany zbiór wartości atrybutów jest odrzucany, czyli odpowiadająca mu
zmienna sterująca będzie miała wartość false.
3.5 Dalsze przetwarzanie
pl
s.
Rezultat jest formowany w x-ramkę specyfikacyjną, która przyjmuje postać szeregu elementów set, nadających wyznaczone wartości zmiennym sterującym, oraz pojedynczego
elementu powodującego adaptację ramki zbiorczej repozytorium (zawierającej odwołania
do pozostałych ramek).
Rezultatem opisanej powyżej procedury jest stworzenie reprezentacji obiektów warstwy
ORM w przestrzeni zmiennych XVCL. Aby utworzyć artefakty dla konkretnego narzędzia,
należy zaadaptować ramkę główną odpowiedniego generatora (patrz wyżej). Dla potrzeb
przeglądu wersji i wariantów zawartych w repozytorium, a spełniających warunki zapytania, dostarczony może być specjalny generator, tworzący raport o wybranych obiektach.
134
3.6 Pozostałe funkcje zarządzania wersjami
w
Utworzenie pierwszej wersji systemu jest wspomagane przez narzędzie oparte na XQuery,
tworzące ramki obiektów na podstawie schematu bazy danych zapisanego we wspomnianym wcześniej, specjalizowanym dialekcie.
Identyfikacja kolejnych wersji i równoległych wariantów bazuje na zmiennych sterujących – każda unikalna wartość wyznacza jedną wersję lub wariant. Klasyfikacja na wersje
i warianty jest możliwa na podstawie atrybutów – przykładowo zmienne różniące się jedynie wartością atrybutu czasu wstawienia wyznaczają kolejne wersje, a np. różniące się wartością atrybutu „środowisko wdrożenia” stanowią równoległe warianty.
Tworzenie wersji warstwy ORM polega na ustaleniu wartości atrybutów, jakie mają opisywać nową wersję, a następnie ręcznym wprowadzenie do zmiennych modelu zgrupowanych w podelementach <option> różnic opisanych przez wartość zmiennej sterującej, wyznaczoną przez nowe wartości atrybutów.
Wybór wersji przechowywanych obiektów możliwy jest tylko w ramach ekstrakcji konfiguracji, którą to procedurę opisano wcześniej. Nie przewiduje się operacji na pojedynczych obiektach, ponieważ obiekty warstwy ORM przedstawiają wartość tylko jako całość,
a próby „ręcznego” składania warstwy z arbitralnie wybranych wersji doprowadzą do problemów ze wzajemną zgodnością elementów oraz zgodnością ze schematem bazy danych.
da
.b
w
w
4 Podsumowanie
pl
s.
Podstawową korzyścią, jaka ma być osiągnięta poprzez zastosowanie proponowanego rozwiązania, jest możliwość śledzenia zmian obiektów i ich składowych nie jako zmian
w tekstowym zapisie pewnego artefaktu, ale jako zmian konkretnych, nazwanych cech, których przyczyny są łatwo odczytywane z wartości atrybutów użytych do opisu. Dodatkową
zaletą, która musi zaistnieć by było możliwe powyższe, jest opisywanie obiektów odwzorowania w klarowny i ustrukturalizowany sposób. Pozytywną cechą, otrzymywaną niejako
przy okazji realizacji powyższych celów, jest redukcja rozmiaru zarządzanego kodu, w sytuacji gdy system utrzymywany jest w wielu wariantach.
Prace nad zarządzaniem wersjami ORM są dość zaawansowane, ale oczywiście nie
wszystkie problemy rozwiązano. Dalsze prace powinny obejmować m.in.:
− rozwinięcie modelu opisu odwzorowań, tak by można w nim wyrazić wszystkie użyteczne koncepcje ORM (pola wyliczane, funkcje składowane), nie zaś tylko encje
z atrybutami i związki między encjami;
− sposób prezentowania użytkownikowi opisu wersji spełniających podane kryteria,
przed przekazaniem ich do generatora;
− możliwości kilkustopniowej eksploracji repozytorium (poziom obiektów – poziom
wersji/wariantów obiektu równolegle z definicjami składników obiektu – poziom
cech składników);
− lepszą integrację wersjowania ORM z zarządzaniem wersjami schematu bazy danych
(por. [6]).
Opracowana metoda zarządzania wersjami wydaje się dawać duże możliwości, w szczególności pozwala definiować i generować zarówno kolejne wydania jak i równoległe warianty
ORM. Analiza zawartości repozytorium pozwala w każdej chwili prześledzić ewolucję projektu, możliwe jest też zawsze wygenerowanie każdej wersji.
135
w
Sugerowany sposób zapisu jest klarowny, choć trochę przytłaczający (ilościowo) przy
dłuższej historii zmian; stąd potrzeba prac nad łatwiejszą eksploracją repozytorium.
Możliwości modelu wersjowania opartego na atrybutach są bardzo duże. W zastosowaniu do warstwy ORM można pozwolić sobie na wprowadzanie – dla uproszczenia – dość
silnych ograniczeń funkcji taksonomii pomocniczych, a model pozostaje użyteczny i dostatecznie „pojemny”.
Pokazane tu rozwiązanie jest samo w sobie ciekawe, ale działając w separacji byłoby
mało użyteczne. Właściwy poziom użyteczności osiągnięty może być dopiero we współpracy z kompatybilnymi rozwiązaniami do zarządzania ewolucją schematu bazy danych
i obiektów warstwy wyższej (biznesowej).
w
Literatura
1.
3.
4.
6.
7.
8.
9.
10.
12.
13.
14.
pl
s.
11.
da
.b
5.
w
2.
CVS – concurrent versions system v1.11.21.
http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs.html
Gergic J.: Towards a versioning model for component-based software assembly. In Proceedings:
ICSM 2003, Amsterdam, The Netherlands, 22-26 September 2003.
Gergic J.: A Versioning Model for SOFA/DCUP Architecture. Praca magisterska, 1999.
Grudzień A., Traczyk T., Jarzabek S.: Application of Generative Programming to Evolution of
Object-Relational Mapping Layer. Proceedings of the 2nd AIS SISGSAND Symposium on Systems Analysis And Design, ss. 64-71. Gdańsk, czerwiec 2007.
Jarzabek S., Basset P., Zhang H. and Zhang W.: XVCL: XML-based Variant Configuration
Language. Proc. Int. Conf. on Software Engineering, ICSE’03, pp. 810-811, Portland, May 2003.
Kowalski J., Traczyk T.: Zastosowanie języka XVCL do zarządzania ewolucją schematu relacyjnej bazy danych. Bazy danych. Nowe technologie, t. 1, ss. 35-44. WKiŁ, Warszawa 2007.
Morzy T., Eder J., Koncilia C.: The COMET metamodel for temporal data warehouses. In 14th
Int. Conf. on Advanced Information Systems Engineering (CAISE’02), Toronto, Canada, 2002.
Munch B. P.: Versioning in a Software Engineering Database - the Change Oriented Way. PhD
thesis, The Norwegian Institute of Technology, 1995.
Tichy W.F.: RCS – A System for Version Control. Software – Practice & Experience 17, 7, July
1985, pp. 637-654.
Traczyk T.: Zarządzanie ewolucją systemu informacyjnego za pomocą programowania generatywnego i języka XVCL. TPD 2005 I Krajowa Konferencja Naukowa Technologie Przetwarzania Danych, ss. 378-389. Poznań, wrzesień 2007.
Tryggeseth E., Conradi R., Gulla B.: Software Configuration Management in PROTEUS Proceedings of the 4th International Workshop on Software Configuration Management, 1993.
Wilkes W. Klahold P. Schlageter G.: A general model for version management in databases. In:
Wesley W. Chu, Georges Gardarin, Setsuo Ohsuga,and Yahiko Kambayashi, editors, VLDB’86
Twelfth International Conference on Very Large Data Bases, August 25-28, 1986, Kyoto, Japan,
Proceedings, pages 319–327. Morgan Kaufmann, 1986.
W3C XML Query (XQuery). http://www.w3.org/XML/Query/
XVCL Web Site. http://xvcl.comp.nus.edu.sg/
136

Rozdział monografii: `Bazy Danych: Rozwój metod i technologii

Transkrypt

Podobne dokumenty

U c tI\vAL A N r 208,toryD004

Zadanie 1. Na komfort cieplny i ryzyko odmrożenia wpływa zarówno

Dariusz Grzesista

Bazy danych - ćwiczenia 5

KTO JEST KIM W URZĘDZIE MIEJSKIM W GŁUSZYCY Pokój Osoba

WEKA - wstęp, ARFF, filtry.

£wI, Przedmiotowy, Aneks 2, Samoloty, lotnictwo