TOMASZ DUDEK
Akademia Morska w Szczecinie
Streszczenie
Aby bazy i hurtownie danych mogły spełni swoj rol w zintegrowanych kom-puterowych systemach wspomagania zarzdzanie musz uwzgldnia zmienne w czasie potrzeby uytkowników (decydentów, analityków). Ten zmienny charakter po-trzeb 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 wy-niki oceny wybranych metod wersjowania baz i hurtowni danych. Ocen t zrealizo-wano 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 wia-ta 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 szcze-gó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) da-nych,
− Zmiany w rodowisku biznesowym, zwizanym z kolekcj danych przechowywanych w bazie (hurtowni) danych, Np. zmiany przepisów prawnych, metod zarzdzania i organiza-cji 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 logicz-nym. Zmiana schematu fizycznego zwykle przeprowadzana jest przez administratora bazy danych ze wzgldów eksploatacyjnych (przepełnienie pamici, optymalne wykorzystanie zasobów, opty-malizacja rozmieszczenia zasobów, etc). Zmiana schematu na poziomie logicznym polega na do-daniu lub usuniciu wyrónionego elementu (obiektu) bazy danych, Np., tabeli, kolumny, widoku,
indeksu, atrybutu, relacji, typu, etc. W relacyjnych bazach danych modyfikacja schematu logiczne-go jest stosowana w ograniczonym do moliwoci jzyka SQL zakresie, midzy innymi dziki ta-kim 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 utrzymywa-nie 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 wyprze-dzajcych 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 (al-ternatywne) [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 za-chowanie 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 sche-matu ma miejsce wówczas, gdy system bazy lub hurtowni danych umoliwia pobranie wszystkich danych (danych historycznych, wariantowych i aktualnych – zwykle jest to ostatnia wersja histo-ryczna 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 umoli-wia odczyt i aktualizacj wszystkich danych (historycznych, alternatywnych i aktualnych) prze-chowywanych 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 rzeczywi-stych, zwanych „wersjami” obiektów. W wielowersyjnych bazach danych moliwe jest utrzymy-wanie 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) da-nych 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
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. pro-motion). 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 wie-lowersyjnym w bazie lub hurtowni danych zwizany jest tzw. obiekt generyczny (ang. generic ob-ject). Celem tego obiektu jest reprezentacja tosamoci modelowanej rzeczywistoci. Zwykle atry-butami 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 me-tody 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 syn-chroniczne (ang. synchronous management) i asynsyn-chroniczne (ang. asynchronous manage-ment)[1][2]. W zarzdzaniu synchronicznym dane s przechowywane, wyszukiwane i aktualizowa-ne za pomoc odpowiadajcych im wersji schematu za asynchroniczaktualizowa-ne 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 po-dejcie oparte na przypisywaniu do wersji schematu danych tzw. czasu transakcyjnego (ang. Tran-saction Time Schema Versioning). Tu zmiana schematu wielowersyjnej bazy danych dotyczy zaw-sze aktualnej w danej chwili wersji schematu (ostateczna wersja schematu). Wówczas adna in-strukcja 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 wykorzy-staniem 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 archiwiza-cji a nowa wersja wymaga zastosowania zmian w bazie danych, zgodnie ze zmian schematu. Cz-sto w tym przypadku naley wykorzysta tzw. tymczasowe funkcje konwersji [2]. Jeli w zarz-dzaniu 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
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 zredukowa-ny 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 przeprowa-dzane 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 sche-macie 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 asyn-chronicznych i synasyn-chronicznych.
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 wy-peł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 za-rzdzania danymi. W przypadku synchronicznego zaza-rzdzania 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 syste-mu. Aby okreli , która z metod wersjowania najlepiej nadawałaby si do implementacji w okre-lonych 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 wersjo-wania od siebie i koniecznoci przeprowadzenia eksperymentu dla rónych zastosowa wielower-syjnych baz danych. Dodatkowo naley zauway , e takie parametry eksploatacyjne jak
wydaj-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 da-nych.
3. Ocena metod wersjowania danych.
Do oceny metod wersjowania schematu logicznego baz lub hurtowni danych wykorzystano me-tod wielokryterialn AHP (ang. Analytical Hierarchy Process). Metoda ta wydaje si najbardziej uyteczn ze wzgldu na złoono analizy wielokryterialnej, cho by ze wzgldu na istnienie nie-poró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 kryte-riów. S one zgodne w opinii ekspertów z tabel 1.
Tabela 1. Macierz głównych kryteriów w metodzie AHP
Kryterium K1 Eksploatacja K2 Wdraanie K3 Bezpieczestwo K4 Elastyczno K5 Koszty K1-Eksploatacja 1 5 1 0,5 1 K2-Wdraanie 0,2 1 1 0,2 1 K3-Bezpieczestwo 1 1 1 0,2 1 K4-Elastyczno 2 5 5 1 5 K5-Koszty 1 1 1 0,2 1 Suma 5,2 13 9 2,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 kryte-rió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 K2 K3 K4 K5 Waga Ranking K1 0,1923 0,3846 0,1111 0,2381 0,1111 0,2074 2 K2 0,0385 0,0769 0,1111 0,0952 0,1111 0,0866 4 K3 0,1923 0,0769 0,1111 0,0952 0,1111 0,1173 3 K4 0,3846 0,3846 0,5556 0,4762 0,5556 0,4713 1 K5 0,1923 0,0769 0,1111 0,0952 0,1111 0,1173 3 ródło: opracowanie własne na podstawie [6]
Dla kadego kryterium oceny wyróniono nastpnie podkryteria. S one zgodne zgodnie z Ta-bel 3.
Tabela 3. Podział kryteriów na podkryteria oceny metod wersjowania S1-wydajno
K1
Eksploatacja S2-wymagane zasoby S3-czasochłonno K2
Wdraanie S4-trudno implementacji S5-łatwo odzyskania danych K3
Bezpieczestwo S6-Ryzyko utraty danych historycznych S7-przenaszalno
S8-moliwo wprowadzania zmian S9-obszar zastosowa
S10-moliwo odwołania si do wersji historycznej K4
Elastyczno
S11-moliwo tworzenia wersji przyszłych S12-koszt wdraania
S13-koszt utrzymania S14-koszt przenoszenia K5
Koszty
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 lokal-nych i globallokal-nych wag dla rozwaalokal-nych podkryteriów. Wyznaczone wagi s zgodne z tabel 4.
Tabela 4. Macierz wag i ranking podkryteriów Kryterium Podkryterium Lokalne
wagi Si Global-ne wagi Ki Globalne wagi Si Rangi Si S1-wydajno 0,6667 0,1383 3 K1
Eksploatacja S2-wymagane zasoby 0,3333 0,2074 0,0691 6
S3-czasochłonno 0,7501 0,0650 7
K2
Wdraanie S4-trudno implementacji 0,2499 0,0866 0,0075 14 S5-łatwo odzyskania danych 0,1667 0,0196 11 K3
Bezpiecze-stwo
S6-Ryzyko utraty danych historycznych
0,8333 0,1173
0,0978 4
S7-przenaszalno 0,0324 0,0153 12
S8-moliwo wprowadzenia zmian 0,0761 0,0359 9
S9-obszar zastosowa 0,0918 0,0433 8
S10-moliwo odwołania si do wersji historycznej 0,3998 0,1884 1 K4 Elastyczno S11-moliwo tworzenia wersji przyszłych 0,3998 0,4713 0,1884 2 S12-koszt wdraania 0,2000 0,0226 10 S13-koszt utrzymania 0,6609 0,0747 5 S14-koszt przenoszenia 0,0696 0,0079 13 K5 Koszty
S15-koszt odzysku danych 0,0696
0,1173
0,0079 13 ródło opracowanie własne na podstawie[6]
Tabela 5. Lokalne wagi przypisane metodom wersjowania schematu logicznego baz i hurtowni danych
Lokalne wagi metod wersjowania Kryterium Podkryterium Wagi pod- kryte-riów M1 M2 M3 M4 M5 S1-wydajno 0,138 3 0,058 8 0,058 8 0,294 1 0,294 1 0,294 1 K1 eksploata-cja S2-wymagane zasoby 0,069 1 0,112 5 0,088 6 0,230 8 0,284 1 0,284 1 S3-czasochłonno 0,065 0 0,134 8 0,056 7 0,325 9 0,325 9 0,156 8 K2 wdraanie S4-trudno implementacji 0,007 5 0,206 5 0,000 6 0,002 9 0,001 9 0,000 6 S5-łatwo odzyskania danych 0,019 6 0,166 0 0,096 4 0,135 2 0,135 2 0,467 2 K3 bezpiecze-stwo
S6-Ryzyko utraty danych historycznych 0,097 8 0,148 1 0,148 1 0,066 2 0,071 9 0,565 7 S7-przenaszalno 0,015 3 0,166 7 0,166 7 0,333 3 0,166 7 0,166 7 S8-moliwo wprowadzania zmian 0,035 9 0,200 0 0,200 0 0,200 0 0,200 0 0,200 0 S9-obszar zastosowa 0,043 3 0,058 8 0,058 8 0,294 1 0,294 1 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 K4 elastyczno S11-moliwo tworzenia wersji przyszłych 0,188 4 0,083 1 0,392 1 0,058 8 0,073 8 0,392 1 S12-koszt wdraania 0,022 6 0,170 8 0,088 6 0,476 2 0,170 8 0,093 5 S13-koszt utrzymania 0,074 7 0,226 6 0,051 1 0,393 7 0,277 5 0,051 1 S14-koszt przenoszenia 0,007 9 0,250 0 0,125 0 0,250 0 0,250 0 0,125 0 K5 koszty S15-koszt odzysku danych po awarii 0,007 9 0,157 9 0,088 9 0,297 6 0,297 6 0,157 9 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)
Ostateczn ocen globaln metod wersjowania zgodnie z algorytmem metody AHP zaprezen-towano w Tabeli 6.
Tabela 6. Globalne wagi i ranking metod wersjowania schematu logicznego baz i hurtowni danych Globalne wagi metod wersjowania
Kryterium Podkryterium Wagi pod- kryte-riów M1 M2 M3 M4 M5 S1-wydajno 0,138 3 0,008 1 0,008 1 0,040 7 0,040 7 0,040 7 K1
eksploatacja S2-wymagane zasoby 0,069 1 0,007 8 0,006 1 0,015 9 0,019 6 0,019 6 S3-czasochłonno 0,065 0 0,008 8 0,003 7 0,021 2 0,021 2 0,010 2 K2 wdraanie S4-trudno Implementacji 0,007 5 0,001 5 0,000 6 0,002 9 0,001 9 0,000 6 S5-łatwo odzyskania Danych 0,019 6 0,003 3 0,001 9 0,002 7 0,002 7 0,009 2 K3
bezpieczestwo S6-Ryzyko utraty danych Historycznych 0,097 8 0,014 5 0,014 5 0,006 5 0,007 0 0,055 3 S7-przenaszalno 0,015 3 0,002 6 0,002 6 0,005 1 0,002 6 0,002 6 S8-moliwo wprowadzania zmian 0,035 9 0,007 2 0,007 2 0,007 2 0,007 2 0,007 2 S9-obszar zastosowa 0,043 3 0,002 5 0,002 5 0,012 7 0,012 7 0,012 7 S10-moliwo odwołania si do wersji Historycznej 0,188 4 0,015 7 0,073 9 0,011 1 0,013 9 0,073 9 K4 elastyczno S11-moliwo tworzenia wersji Przyszłych 0,188 4 0,015 7 0,073 9 0,011 1 0,013 9 0,073 9 S12-koszt wdraania 0,022 6 0,003 9 0,002 0 0,010 8 0,003 9 0,002 1 S13-koszt utrzymania 0,074 7 0,016 9 0,003 8 0,029 4 0,020 7 0,003 8 S14-koszt przenoszenia 0,007 9 0,002 0 0,001 0 0,002 0 0,002 0 0,001 0 K5 koszty S15-koszt odzysku danych po awarii 0,007 9 0,001 2 0,000 7 0,002 4 0,002 4 0,001 2 Wagi 0,111 7 0,202 5 0,181 7 0,172 4 0,314 Rangi 5 2 3 4 1
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
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 ko-niecznoci uwzgldnienia ewolucyjnego charakteru struktur danych i systemów oprogramowania. Istnieje wiele rónych metod wersjowania baz danych, które charakteryzuj si rónorodn wydaj-noci i uyteczwydaj-noci eksploatacyjn. Wybór jednej z nich nie jest prosty zwłaszcza, e uytkow-nicy 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, czaso-chłonno i trudno implementacji, łatwo odzysku danych (Np., podczas awarii systemu), ryzy-ko utraty danych historycznych, przenaszalno , obszar zastosowa, moliwo pracy z wersjami historycznymi i wersjami przyszłymi (alternatywnymi), koszty wdraania, przenoszenia, utrzyma-nia i odzysku danych. Ocena oparta na tych wielu kryteriach metod wersjowautrzyma-nia 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 da-nych. Dodatkowo, metoda wersjowania bitemporalnego umoliwia nie tylko tworzenie wersji hi-storycznych w bazie danych, ale równie sprzyja trzymaniu wersji alternatywnych, odwzorowuj-cych 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 zastoso-wanie oceny ekspertyzy w oparciu o pomiar odległoci pogldów ekspertów. Bdzie to etapem dalszych prac nad zaprezentowanym problemem.
Bibliografia
1. Castro C.D., Grandi F.: On schema versioning In temporal database. Workshop In Computing, Springer-Verlag, Berlin, 1995.
2. Castro C.D., Grandi F., Scalas M.,R.: Schema versioning for multi-temporal relational databases. Information Systems, Vol. 22, 1997.
3. Deucet A., Garncarski S., Jomier G., Monties S.: Integrity Constraints In Multiversion Databases. Springer-Verlag, Berlin, 1997.
4. Morzy T., Wrembel R.: Managing and Querying Versions of Multi-version Data Warehouse. In Proceeding of International Conference on Extending Database Technology, EDBT, 2006
5. Roddick J.F.: A Survey of Schema Versioning In Temporal Database Systems. Information and Software Technology, 1995.
6. Saaty T.,L.: The Analytical Hierarchy Process. RWS Publications, Pittsburg, 1990 7. Wrembel R.: Management of schema and data evaluation in multiversion data warehouse.
Wydawnictwo Politechniki Poznaskiej, Seria: Rozprawy, nr 411, Pozna, 2007.
8. 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 valid-time versioning for single-pool and multi-pool solution, synchronous and asynchro-nous data management, method with versions of database objects, method with ver-sions 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, flexi-bility 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 bsmialkowska@wi.ps.pl
http://www.kisi.wi.zut.edu.pl Tomasz Dudek
Akademia Morska tdudek@wi.ps.pl
