Ocena metod wersjowania baz i hurtowni danych

OCENA METOD WERSJOWANIA BAZ I HURTOWNI DANYCH
BOENA MIAŁKOWSKA
Zachodniopomorski Uniwersytet Technologiczny
TOMASZ DUDEK
Akademia Morska w Szczecinie
Streszczenie
Aby bazy i hurtownie danych mogły spełni swoj rol w zintegrowanych komputerowych systemach wspomagania zarzdzanie musz uwzgldnia zmienne w
czasie potrzeby uytkowników (decydentów, analityków). Ten zmienny charakter potrzeb mona osign poprzez tworzenie wielowersyjnych baz i hurtowni danych. W
literaturze i praktyce stosowane s róne metody wersjowania danych. Od uytej w
systemie bazy lub hurtowni danych metody wersjowania zaley jako i uyteczno
danych oferowanych uytkownikom tych systemów. W artykule zaprezentowano wyniki oceny wybranych metod wersjowania baz i hurtowni danych. Ocen t zrealizowano za pomoc metody AHP (ang. Analytical Hierarchy Process [6]).
Słowa kluczowe: wielowersyjne bazy i hurtownie danych, zarzdzanie wersjami danych, metoda
AHP, metoda wersjowania bitemporalnego baz i hurtowni danych
1. Wprowadzenie
Bazy i hurtownie danych przechowuj dane odwzorowujce stany wyodrbnionej czci wiata rzeczywistego (tzw. miniwiat), do której si odnosz. Z czasem zmiany w wiecie rzeczywistym
mog wpływa na konieczno modyfikacji struktury (schematu) bazy lub hurtowni danych szczególnie wówczas, gdy na etapie ich projektowania nie przewidziano tej zmiennoci. Niewtpliwy
wpływ na zmian struktur kolekcji danych maj równie:
− Nowe potrzeby uytkowników, pojawiajce si na etapie eksploatacji baz (hurtowni) danych,
− Zmiany w rodowisku biznesowym, zwizanym z kolekcj danych przechowywanych w
bazie (hurtowni) danych, Np. zmiany przepisów prawnych, metod zarzdzania i organizacji pracy, metod wspomagania decyzji, etc.,
− Rozwój infrastruktury systemów baz danych oraz technologii, technik, rodków i metod
przetwarzania danych.
Zmiany w schemacie bazy danych mona osign poprzez modyfikacj schematu (ang.
schema modification) lub poprzez tzw. wersjowanie (ang. schema versioning).
Modyfikacja schematu bazy danych moe by realizowana na poziomie fizycznym lub logicznym. Zmiana schematu fizycznego zwykle przeprowadzana jest przez administratora bazy danych
ze wzgldów eksploatacyjnych (przepełnienie pamici, optymalne wykorzystanie zasobów, optymalizacja rozmieszczenia zasobów, etc). Zmiana schematu na poziomie logicznym polega na dodaniu lub usuniciu wyrónionego elementu (obiektu) bazy danych, Np., tabeli, kolumny, widoku,
168
Boena miałkowska, Tomasz Dudek
Ocena metod wersjowania baz i hurtowni danych
indeksu, atrybutu, relacji, typu, etc. W relacyjnych bazach danych modyfikacja schematu logicznego jest stosowana w ograniczonym do moliwoci jzyka SQL zakresie, midzy innymi dziki takim komendom tego jzyka jak ALTER TABLE z opcj ADD COLUMN lub DROP COLUMN
czy te DROP TABLE.
Wersjowanie schematu bazy czy hurtowni danych polega na utrzymywaniu wielu wersji tej
samej kolekcji danych. Systemy baz lub hurtowni danych, w których nie jest moliwe utrzymywanie wielu wersji danych nazywa si jednowersyjnymi bazami lub hurtowniami danych.
Wersje przechowywane w wielowersyjnej bazie lub hurtowni danych mog by tworzone,
przechowywane i udostpniane z rónych wzgldów. Takimi wzgldami mog by Np. potrzeba
utrzymywania historycznych zmian w bazie danych, konieczno przeprowadzenia bada wyprzedzajcych histori (symulacja przyszłych stanów), potrzeba opracowania przyszłych scenariuszy
biznesowych, planowanie, badanie i porównanie alternatywnych rozwiza, etc. Zazwyczaj wersje
w wielowersyjnych bazach i hurtowniach danych dzieli si na wersje historyczne i wariantowe (alternatywne) [4][7][8]. Wersje wariantowe s interpretowane jako odpowiedniki modelowanych
obiektów, które róni si od obiektów tego samego typu struktur i zachowaniem modelowanej
rzeczywistoci. Wersje historyczne wynikaj z liniowego upływu czasu. Jednake moliwe jest
równie utrzymywanie wersji historycznych kolekcji danych z gałziowym modelem upływu czasu
na zasadzie podobnej jak w odniesieniu do temporalnych baz danych.
Wielowersyjne bazy lub hurtownie danych pozwalaj zachowywa (zapamita) stany i zachowanie obiektów bazodanowych w ujciu historycznym lub alternatywnym, przy jednoczesnym
zachowaniu powiza z tym samym modelowanym obiektem rzeczywistoci.
2. Rodzaje metod wersjowania baz i hurtowni danych.
W literaturze [1][5] wyrónia si w bazach i hurtowniach danych wersjowanie czciowe (ang.
partial schema versioning) lub pełne (ang. full schema versioning). Czciowe wersjowanie schematu ma miejsce wówczas, gdy system bazy lub hurtowni danych umoliwia pobranie wszystkich
danych (danych historycznych, wariantowych i aktualnych – zwykle jest to ostatnia wersja historyczna kolekcji danych), ale aktualizacja danych musi si odbywa tylko na danych aktualnych. O
pełnym wersjowaniu schematu bazy lub hurtowni danych mówi si wówczas, gdy system umoliwia odczyt i aktualizacj wszystkich danych (historycznych, alternatywnych i aktualnych) przechowywanych w systemie.
W wielowersyjnych bazach danych uytkownik moe mie dostp do danych pochodzcych z
tej samej lub innej wersji danych, przy jednoczesnym zachowaniu spójnoci kolekcji danych. Gdy
w bazie danych obiekt bazy (hurtowni danych) jest złoony z wielu innych obiektów (Np., tabela z
wielu atrybutów, baza danych z wielu tabel, obiekt złoony w obiektowej bazie danych) a kady z
nich moe wystpowa w wielu wersjach, to w systemie musz istnie mechanizmy jednoznacznej
identyfikacji, utrzymania i operowania na wielu reprezentacjach tych samych obiektów rzeczywistych, zwanych „wersjami” obiektów. W wielowersyjnych bazach danych moliwe jest utrzymywanie kolejnych wersji obiektów lub całej bazy danych. Mamy wówczas do czynienia z kolekcj
danych z wersjami obiektów lub z wersjami baz danych. W wielowersyjnej bazie (hurtowni) danych z wersjami obiektów wystpuj obiekty wersjowane i niewersjowane. Obiekty podlegajce
wersjowaniu mog by wersjami przejciowymi obiektu (ang. transient), roboczymi (ang. working)
lub ostatecznymi (ang. released). Tym typom obiektów wersjowanych odpowiada etap procesu
projektowania obiektu wielowersyjnego ostatecznego. Wersje przejciowe obiektów mog by
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 18, 2009
169
wersjami niekompletnymi, niepoprawnymi i s dostpne wyłcznie dla jej twórców. W momencie
osignicia stanu stabilnego (Np., po wstpnym przetestowaniu), wersje przejciowe mog sta si
wersjami roboczymi. Zmiana typu wersji obiektu jest moliwa dziki operacji promocji (ang. promotion). Wersje robocze obiektów mog by współdzielone przez wyróniony krg uytkowników
(projektanci grupy) i nie mog by modyfikowane. Stanowi one podstaw tworzenia innych wersji
przejciowych tego samego obiektu. Wersja robocza moe by promowana do wersji ostatecznej i
udostpniana szerszej rzeszy uytkowników bazy lub hurtowni danych. Z kadym obiektem wielowersyjnym w bazie lub hurtowni danych zwizany jest tzw. obiekt generyczny (ang. generic object). Celem tego obiektu jest reprezentacja tosamoci modelowanej rzeczywistoci. Zwykle atrybutami obiektu generycznego s:
− Liczba utworzonych wersji obiektu,
− Numer kolejnej wersji obiektu, jeli w przyszłoci taka wersja zostanie utworzona),
− Numer wersji domylnej, aktualnie obowizujcej,
− Drzewo wywodu wersji.
Za literatur [1][3], w zarzdzaniu danymi wielowersyjnych baz danych czsto stosuje si metody oparte na zasadzie utrzymywania pojedynczej puli danych (ang. Single-Pool Solution) lub
wielu pul danych (ang. Multi-Pool Solution). W rozwizaniu z pojedyncz pul danych, dane
wszystkich wersji s zarzdzane wspólnie, za w przypadku modelu z wieloma pulami danych,
dane rónych wersji schematu s zarzdzane przez oddzieln pul danych.
Dodatkowo w zarzdzaniu danymi w wielowersyjnych bazach danych stosuje si metody synchroniczne (ang. synchronous management) i asynchroniczne (ang. asynchronous management)[1][2]. W zarzdzaniu synchronicznym dane s przechowywane, wyszukiwane i aktualizowane za pomoc odpowiadajcych im wersji schematu za asynchroniczne zarzdzanie polega na tym,
e dane wielowersyjnej bazy danych mog by zapamitywane, wyszukiwane i aktualizowane za
pomoc dowolnej wersji schematu danych. Czciej w wielowersyjnych bazach danych uywa si
metod opartych na zarzdzaniu asynchronicznym, cho istniej równie implementacje oparte na
zmodyfikowanym zarzdzaniu asynchronicznym. Zwykle te modyfikacje metody zarzdzania
asynchronicznego dotycz wybranych metod obsługi danych (Np., zarzdzanie asynchroniczne
uywa si jedynie do aktualizacji wielowersyjnej bazy danych a wyszukiwanie realizuje si zwykle
na jednym schemacie wielowersyjnej bazy danych).
W zarzdzaniu danymi wielowersyjnych baz i hurtowni danych wykorzystuje si równie podejcie oparte na przypisywaniu do wersji schematu danych tzw. czasu transakcyjnego (ang. Transaction Time Schema Versioning). Tu zmiana schematu wielowersyjnej bazy danych dotyczy zawsze aktualnej w danej chwili wersji schematu (ostateczna wersja schematu). Wówczas adna instrukcja w jzyku SQL w postaci SET SCHEMA nie moe by uyta przed zmian schematu do
wybranej wersji schematu, która bdzie modyfikowana. Wersjowanie schematu danych z wykorzystaniem czasu transakcji wymaga najprostszego zarzdzania wewntrznymi danymi w odpowiedzi
na zmian schematu. Zmiana schematu moe wpłyn jedynie na biec wersj schematu. Gdy
zastosowane s mechanizmy z pojedyncz pul danych, to stara wersja danych podlega archiwizacji a nowa wersja wymaga zastosowania zmian w bazie danych, zgodnie ze zmian schematu. Czsto w tym przypadku naley wykorzysta tzw. tymczasowe funkcje konwersji [2]. Jeli w zarzdzaniu wielowersyjn baz danych zastosowano mechanizm wielu pul (pakietów) danych (ang.
Multi-Pool Solution), to tworzenie nowej wersji schematu wymusza utworzenia nowej puli danych.
W zarzdzaniu wielowersyjnym bazami i hurtowniami danych wykorzystuje si równie
170
Boena miałkowska, Tomasz Dudek
Ocena metod wersjowania baz i hurtowni danych
znaczniki wanoci wersji (ang. Valid-Time Schema Versioning) [1]. Realizuje si to czsto za
pomoc specjalnej klauzuli VALID bdcej warunkiem czasu wanoci wersji schematu danych.
Takiej klauzuli moe uy uprawniony do zmiany wersji schematu bazy danych uytkownik. W
tym przypadku poprzez klauzul SET SCHEMA mona dokona wyboru tej wersji schematu, na
którym bdzie realizowana modyfikacja. Nowej wersji schematu przypisywany jest znacznik czasu
wanoci schematu. Poprzednie wersje schematu logicznego, całkowicie zakryte (ang. overlapped)
przez zmian znacznika czasu wanoci, s usuwane. Znacznik czasu wanoci zostaje zredukowany dla poprzedniej wersji schematu logicznego, gdy znacznik ten jest tylko czciowo zakryty
(ang. partially overlapped) przez znacznik czasu wanoci nowej wersji schematu logicznego. W
wersjowaniu baz danych z wykorzystaniem znacznika wanoci schematu mog by przeprowadzane zarówno wsteczne (ang. retroactive) jak i przyszłe (ang. proactive) zmiany schematu danych.
W tym przypadku stosuje si specjaln klauzul jzyka SQL w formie VALID PERIOD, która
okrela wano czasow nowo utworzonej wersji schematu danych. Po wykonaniu zmian w schemacie zostanie utworzona nowa wersja, a pewne dane w wersjach starych mog zosta usunite lub
moe im zosta ograniczony zakres znacznika czasu wanoci. Zadaniem tej ostatniej czynnoci
jest uniknicie nakładania si znaczników wanoci poprzednich wersji schematu ze znacznikiem
czasowym wanoci nowej wersji danych. Metoda ze znacznikami wanoci wersji schematu moe
by równie realizowana z zastosowaniem pojedynczej lub wielu pul danych, na zasadach asynchronicznych i synchronicznych.
W wersjowaniu wykorzystujcym znaczniki czasu transakcji, logiczne usunicie danych nie
wie si z fizycznym usuwaniem danych, za w przypadku zarzdzania wielowersyjn baz lub
hurtowni danych z wykorzystaniem znaczników wanoci wersji, operacja logicznego usuwania
danych z kolejnej wersji schematu danych moe prowadzi do fizycznego usunicia danych.
W przypadku zastosowania znaczników wanoci wersji danych oraz wielu pul danych po
zmianie schematu (wersji) bazy danych inicjowana jest nowa pula danych, przy czym jest ona wypełniona danymi pochodzcymi z pul danych, które odpowiadaj zmodyfikowanej wersji schematu
logicznego, po dokonaniu stosownych zmian. Pule danych powizane z całkowicie przysłonitymi
(lub usunitymi) wersjami schematu take s usuwane. Pule danych powizane z tylko czciowo
zasłonitymi wersjami schematu s pozostawione bez zmiany w przypadku asynchronicznego zarzdzania danymi. W przypadku synchronicznego zarzdzania ich znaczniki wanoci zostaj
ograniczone.
Metod na retro- i pro- aktywne przechowywanie zmian wersji schematu wielowersyjnej bazy
lub hurtowni danych jest tzw. bitemporalne wersjowanie schematu logicznego kolekcji danych.
Metoda ta polega na zapamitywaniu dla kadej wersji danych zarówno znacznika czasowego
transakcji jak równie znacznika czasu wanoci wersji.
Z przeprowadzonej pokrótce charakterystyki metod wersjowania kolekcji danych wynika, e
wybór metody wersjowania ma istotny wpływ na zakres dostpu do danych oraz wydajno systemu. Aby okreli, która z metod wersjowania najlepiej nadawałaby si do implementacji w okrelonych warunkach naley przeprowadzi ocen tych metod.
Utworzenie rodowiska badawczego do przeprowadzenia eksperymentu opartego na pomiarze
nie jest moliwe dlatego, e nie jest moliwe zaimplementowanie wszystkich metod wersjowania w
jednym eksperymentalnym systemie przy jednoczesnym zachowaniu niezalenoci metod wersjowania od siebie i koniecznoci przeprowadzenia eksperymentu dla rónych zastosowa wielowersyjnych baz danych. Dodatkowo naley zauway, e takie parametry eksploatacyjne jak wydaj-
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 18, 2009
171
no, trudno implementacji, ryzyko utraty danych nie daj si wyrazi wielkociami mierzalnymi
a inne Np. czas implementacji, silnie zale od zastosowania i oprogramowania systemu baz danych.
3. Ocena metod wersjowania danych.
Do oceny metod wersjowania schematu logicznego baz lub hurtowni danych wykorzystano metod wielokryterialn AHP (ang. Analytical Hierarchy Process). Metoda ta wydaje si najbardziej
uyteczn ze wzgldu na złoono analizy wielokryterialnej, choby ze wzgldu na istnienie nieporównywalnych i wzajemnie zalenych kryteriów oceny metod wersjowania.
W ocenie rozwaono nastpujce kryteria porównawcze:
− Wag metody dla eksploatacji wielowersyjnej kolekcji danych,
− Efekty etapu wdraania metody,
− Bezpieczestwo metody,
− Elastyczno,
− Koszty zwizane z utrzymaniem i eksploatacj metody.
Dla wyrónionych kryteriów, zostały ocenione przez eksperta wagi wanoci par tych kryteriów. S one zgodne w opinii ekspertów z tabel 1.
Tabela 1. Macierz głównych kryteriów w metodzie AHP
K1
Eksploatacja
1
0,2
1
2
1
5,2
Kryterium
K1-Eksploatacja
K2-Wdraanie
K3-Bezpieczestwo
K4-Elastyczno
K5-Koszty
Suma
K2
Wdraanie
5
1
1
5
1
13
K3
Bezpieczestwo
1
1
1
5
1
9
K4
Elastyczno
0,5
0,2
0,2
1
0,2
2,1
K5
Koszty
1
1
1
5
1
9
ródło: opracowanie własne na podstawie[6]
W oparciu o Tabel 1 opracowano nastpnie Tabel 2, w której wyliczono wagi i rangi kryteriów bdcych podstaw oceny metod wersjowania schematu danych metod AHP.
Tabela 2. Macierz wag (priorytetów) i ranking głównych kryteriów w ocenie metod wersjowania baz
i hurtowni danych zgodnie z oznaczeniami z Tabeli 2
K1
K1
K2
K3
K4
K5
0,1923
0,0385
0,1923
0,3846
0,1923
K2
0,3846
0,0769
0,0769
0,3846
0,0769
K3
0,1111
0,1111
0,1111
0,5556
0,1111
K4
0,2381
0,0952
0,0952
0,4762
0,0952
K5
0,1111
0,1111
0,1111
0,5556
0,1111
Waga
0,2074
0,0866
0,1173
0,4713
0,1173
Ranking
2
4
3
1
3
ródło: opracowanie własne na podstawie [6]
Dla kadego kryterium oceny wyróniono nastpnie podkryteria. S one zgodne zgodnie z Tabel 3.
172
Boena miałkowska, Tomasz Dudek
Ocena metod wersjowania baz i hurtowni danych
Tabela 3. Podział kryteriów na podkryteria oceny metod wersjowania
K1
Eksploatacja
K2
Wdraanie
K3
Bezpieczestwo
K4
Elastyczno
K5
Koszty
S1-wydajno
S2-wymagane zasoby
S3-czasochłonno
S4-trudno implementacji
S5-łatwo odzyskania danych
S6-Ryzyko utraty danych historycznych
S7-przenaszalno
S8-moliwo wprowadzania zmian
S9-obszar zastosowa
S10-moliwo odwołania si do wersji historycznej
S11-moliwo tworzenia wersji przyszłych
S12-koszt wdraania
S13-koszt utrzymania
S14-koszt przenoszenia
S15-koszt odzysku danych po awarii
ródło: opracowanie własne
Na podobnych zasadach jak dla kryteriów (patrz Tabela 1 i 2) opracowano tabel lokalnych i globalnych wag dla rozwaanych podkryteriów. Wyznaczone wagi s zgodne z tabel 4.
Tabela 4. Macierz wag i ranking podkryteriów
Kryterium
K1
Eksploatacja
K2
Wdraanie
K3
Bezpieczestwo
K4
Elastyczno
K5
Koszty
Podkryterium
S1-wydajno
S2-wymagane zasoby
S3-czasochłonno
S4-trudno implementacji
S5-łatwo odzyskania danych
S6-Ryzyko utraty danych
historycznych
S7-przenaszalno
S8-moliwo wprowadzenia zmian
S9-obszar zastosowa
S10-moliwo odwołania si do
wersji historycznej
S11-moliwo tworzenia
wersji przyszłych
S12-koszt wdraania
S13-koszt utrzymania
S14-koszt przenoszenia
S15-koszt odzysku danych
ródło opracowanie własne na podstawie[6]
Lokalne
wagi Si
0,6667
0,3333
0,7501
0,2499
0,1667
0,8333
0,0324
0,0761
0,0918
0,3998
Globalne wagi
Ki
0,2074
0,0866
0,1173
0,4713
0,3998
0,2000
0,6609
0,0696
0,0696
0,1173
Globalne
wagi Si
Rangi Si
0,1383
0,0691
0,0650
0,0075
0,0196
3
6
7
14
11
0,0978
4
0,0153
0,0359
0,0433
12
9
8
0,1884
1
0,1884
2
0,0226
0,0747
0,0079
0,0079
10
5
13
13
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 18, 2009
173
Tabela 5. Lokalne wagi przypisane metodom wersjowania schematu logicznego
baz i hurtowni danych
Kryterium
Wagi
podkryteriów
0,138
3
0,069
1
0,065
0
0,007
5
M1
M2
M3
M4
M5
0,058
8
0,112
5
0,134
8
0,206
5
0,058
8
0,088
6
0,056
7
0,000
6
0,294
1
0,230
8
0,325
9
0,002
9
0,294
1
0,284
1
0,325
9
0,001
9
0,294
1
0,284
1
0,156
8
0,000
6
0,019
6
0,097
8
0,015
3
0,035
9
0,043
3
0,166
0
0,148
1
0,166
7
0,200
0
0,058
8
0,096
4
0,148
1
0,166
7
0,200
0
0,058
8
0,135
2
0,066
2
0,333
3
0,200
0
0,294
1
0,135
2
0,071
9
0,166
7
0,200
0
0,294
1
0,467
2
0,565
7
0,166
7
0,200
0
0,294
1
S10-moliwo odwołania
si do wersji
historycznej
0,188
4
0,083
1
0,392
1
0,058
8
0,073
8
0,392
1
S11-moliwo
tworzenia
wersji przyszłych
0,188
4
0,083
1
0,392
1
0,058
8
0,073
8
0,392
1
0,022
6
0,074
7
0,007
9
0,007
9
0,170
8
0,226
6
0,250
0
0,157
9
0,088
6
0,051
1
0,125
0
0,088
9
0,476
2
0,393
7
0,250
0
0,297
6
0,170
8
0,277
5
0,250
0
0,297
6
0,093
5
0,051
1
0,125
0
0,157
9
Podkryterium
S1-wydajno
K1
eksploatacja
S2-wymagane zasoby
S3-czasochłonno
K2
wdraanie
K3
bezpieczestwo
K4
elastyczno
S4-trudno
implementacji
S5-łatwo odzyskania
danych
S6-Ryzyko utraty danych
historycznych
S7-przenaszalno
S8-moliwo
wprowadzania zmian
S9-obszar zastosowa
S12-koszt wdraania
K5
koszty
S13-koszt utrzymania
S14-koszt przenoszenia
S15-koszt odzysku
danych po awarii
Lokalne wagi metod wersjowania
symbolami Mi dla i=1,2,..,5 oznaczono nazwy metod wersjowania
(M1- metoda wersjowania obiektów, M2 - wersjowanie całej bazy danych, M3 - wersjowanie z
uyciem znaczników czasu transakcji, M4 - wersjowanie z uyciem znaczników czasu wanoci
wersji a M5 – wersjowanie bitemporalne)
ródło: opracowanie własne
174
Boena miałkowska, Tomasz Dudek
Ocena metod wersjowania baz i hurtowni danych
Ostateczn ocen globaln metod wersjowania zgodnie z algorytmem metody AHP zaprezentowano w Tabeli 6.
Tabela 6. Globalne wagi i ranking metod wersjowania schematu logicznego baz i hurtowni danych
Kryterium
M1
M2
M3
M4
M5
0,008
1
0,007
8
0,008
8
0,001
5
0,003
3
0,014
5
0,002
6
0,007
2
0,002
5
0,008
1
0,006
1
0,003
7
0,000
6
0,001
9
0,014
5
0,002
6
0,007
2
0,002
5
0,040
7
0,015
9
0,021
2
0,002
9
0,002
7
0,006
5
0,005
1
0,007
2
0,012
7
0,040
7
0,019
6
0,021
2
0,001
9
0,002
7
0,007
0
0,002
6
0,007
2
0,012
7
0,040
7
0,019
6
0,010
2
0,000
6
0,009
2
0,055
3
0,002
6
0,007
2
0,012
7
0,188
4
0,015
7
0,073
9
0,011
1
0,013
9
0,073
9
0,188
4
0,015
7
0,073
9
0,011
1
0,013
9
0,073
9
0,022
6
0,074
7
0,007
9
0,007
9
0,003
9
0,016
9
0,002
0
0,001
2
0,002
0
0,003
8
0,001
0
0,000
7
0,010
8
0,029
4
0,002
0
0,002
4
0,003
9
0,020
7
0,002
0
0,002
4
0,002
1
0,003
8
0,001
0
0,001
2
Wagi
0,111
7
0,202
5
0,181
7
0,172
4
0,314
Rangi
5
2
3
4
1
Podkryterium
S1-wydajno
K1
eksploatacja
S2-wymagane zasoby
S3-czasochłonno
K2
wdraanie
K3
bezpieczestwo
K4
elastyczno
S4-trudno
Implementacji
S5-łatwo odzyskania
Danych
S6-Ryzyko utraty danych
Historycznych
S7-przenaszalno
S8-moliwo
wprowadzania zmian
S9-obszar zastosowa
S10-moliwo odwołania
si do wersji
Historycznej
S11-moliwo
tworzenia wersji
Przyszłych
S12-koszt wdraania
K5
koszty
Globalne wagi metod wersjowania
Wagi
podkryteriów
0,138
3
0,069
1
0,065
0
0,007
5
0,019
6
0,097
8
0,015
3
0,035
9
0,043
3
S13-koszt utrzymania
S14-koszt przenoszenia
S15-koszt odzysku
danych po awarii
symbolami Mi dla i=1,2,..,5 oznaczono nazwy metod wersjowania (M1- metoda wersjowania
obiektów, M2 - wersjowanie całej kolekcji danych, M3 - wersjowanie z uyciem znaczników czasu
POLSKIE STOWARZYSZENIE ZARZDZANIA WIEDZ
Seria: Studia i Materiały, nr 18, 2009
175
transakcji, M4 - wersjowanie z uyciem znaczników czasu wanoci wersji a M5 - bitemporalne
wersjowanie)
ródło: opracowanie własne
Z przeprowadzonej analizy wynika, e najlepsz wzgldem zaprezentowanych kryteriów
i podkryteriów oceny metod wersjowania jest metoda bitemporalnego wersjowania. Umoliwia ona
tworzenie wersji stanów przyszłych modelowanej rzeczywistoci.
4. Podsumowanie
Utrzymywanie w bazach lub hurtowniach danych wielu wersji schematu danych wynika z koniecznoci uwzgldnienia ewolucyjnego charakteru struktur danych i systemów oprogramowania.
Istnieje wiele rónych metod wersjowania baz danych, które charakteryzuj si rónorodn wydajnoci i uytecznoci eksploatacyjn. Wybór jednej z nich nie jest prosty zwłaszcza, e uytkownicy tych systemów maj róne preferencje i potrzeby. W artykule zaprezentowano metod oceny
metod wersjowania baz i hurtowni danych dla szerokiej gamy wielu kryteriów. Rozpatrzono tu
metod wersjowania obiektów i całych baz (kolekcji) danych, metod zarzdzania wersjami
w oparciu o znaczniki czasowe transakcji i wanoci wersji oraz metod bitemoraln. Posłuono
si takimi kryteriami jak wydajno, wymagane zasoby, elastyczno metody na zmiany, czasochłonno i trudno implementacji, łatwo odzysku danych (Np., podczas awarii systemu), ryzyko utraty danych historycznych, przenaszalno, obszar zastosowa, moliwo pracy z wersjami
historycznymi i wersjami przyszłymi (alternatywnymi), koszty wdraania, przenoszenia, utrzymania i odzysku danych. Ocena oparta na tych wielu kryteriach metod wersjowania z uyciem metody
AHP wykazała, e najlepsz metod wersjowania jest wersjowanie bitemporalne. Metod t mona
zastosowa z powodzeniem do baz relacyjnych, które stanowi główny obszar zastosowa baz danych. Dodatkowo, metoda wersjowania bitemporalnego umoliwia nie tylko tworzenie wersji historycznych w bazie danych, ale równie sprzyja trzymaniu wersji alternatywnych, odwzorowujcych przyszłe stany modelowanej rzeczywistoci.
Ogólnie wielowersyjno w bazach danych zwiksza obszar stosowalnoci i ywotnoci baz
danych i pozwala uwzgldni naturaln ewolucj rzeczywistoci a wybór najlepszej z nich jest
istotnym problemem. Zaprezentowana metoda AHP w ocenie metod wersjowania oparta została
o wiedz eksperta ze wzgldu na kategoryczny charakter kryteriów i podkryteriów oceny. Istotnym
praktycznie zagadnieniem byłoby przeprowadzenie takiej oceny przez wielu ekspertów i zastosowanie oceny ekspertyzy w oparciu o pomiar odległoci pogldów ekspertów. Bdzie to etapem
dalszych prac nad zaprezentowanym problemem.
Bibliografia
1.
2.
3.
Castro C.D., Grandi F.: On schema versioning In temporal database. Workshop In
Computing, Springer-Verlag, Berlin, 1995.
Castro C.D., Grandi F., Scalas M.,R.: Schema versioning for multi-temporal relational
databases. Information Systems, Vol. 22, 1997.
Deucet A., Garncarski S., Jomier G., Monties S.: Integrity Constraints In Multiversion
Databases. Springer-Verlag, Berlin, 1997.
176
Boena miałkowska, Tomasz Dudek
Ocena metod wersjowania baz i hurtowni danych
4.
5.
6.
7.
8.
Morzy T., Wrembel R.: Managing and Querying Versions of Multi-version Data
Warehouse. In Proceeding of International Conference on Extending Database
Technology, EDBT, 2006
Roddick J.F.: A Survey of Schema Versioning In Temporal Database Systems.
Information and Software Technology, 1995.
Saaty T.,L.: The Analytical Hierarchy Process. RWS Publications, Pittsburg, 1990
Wrembel R.: Management of schema and data evaluation in multiversion data warehouse.
Wydawnictwo Politechniki Poznaskiej, Seria: Rozprawy, nr 411, Pozna, 2007.
miałkowska B.: Metoda projektowania hurtowni danych dla potrzeb adaptacyjnego
wspomagania zarzdzania strategi firmy. Wydawnictwo Katedry Informatyki w
Zarzdzaniu, Akademii Rolniczo-Technicznej, Bydgoszcz,2003.
VALUATION OF DATA SCHEMA VERSIONING METHODS FOR DATABASE AND
WAREHOUSE SYSTEMS
Summary
The paper describes methods of schema versioning (transaction-time and validtime versioning for single-pool and multi-pool solution, synchronous and asynchronous data management, method with versions of database objects, method with versions of databases and bitemporal versioning). To goal of this paper is to analyze
methods of database’s (warehouse’s) logical schema versioning and to choose the
best method to fulfills specified set of criteria (usage, implementation, safety, flexibility and costs). The paper includes comparative analysis of schema versioning
methods with the used Analytical Hierarchy Process and overall conclusions.
Keywords: multi-version database and warehouse, database’s logical schema versioning, AHP
method, bitemporal versioning
Boena miałkowska
Zachodniopomorski Uniwersytet Technologiczny
[email protected]
http://www.kisi.wi.zut.edu.pl
Tomasz Dudek
Akademia Morska
[email protected]