Hurtownie danych wyk. 2
dr inż. Paweł Sitek
1
Hurtownie danych w systemie Oracle
Podczas instalacji należy wybierać następujące opcje (ważniejsze formatki instalatora)
:
.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
2
WYPEŁNIANIE HURTOWNI DANYMI
.
Jednym z warunków prawidłowego korzystania z hurtowni danych jest
problem zasilenia jej danymi. Powstaje wtedy problem umieszczenia danych w
hurtowni danych, który wynika z ich dużej liczby.
Korzystanie w tym przypadku z pomocy formatek stworzonych w np. Form
Builder, przeglądarki internetowej lub formatek oprogramowanych w Delphi
może dotyczyć niewielkiej liczby danych lub danych słownikowych.
Jednak ręczne wprowadzanie danych operacyjnych np. sprzedaży z całego
kraju nie jest by najlepszym pomysłem. E tym wypadku należy zastosować inne
metody pompowania danych do hurtowni takie jak:
•
wczytywanie za pomocą tabel zewnętrznych
•
wykorzystanie programu SQL*Loader.
•
można także korzystać z funkcji Import w Enterprise Manager
Console, ale w tym przypadku spowoduje to ograniczenie tylko do
danych pochodzących ze środowiska Oracle.
Jeżeli rozpatrywane są duże systemy, pompowanie danych staje się
problemem nietrywialnym. Chodzi o to, aby w trakcie kiedy obciążenie
hurtowni jest jak najmniejsze (np. od 24:00 do 6:00) wtłoczyć wszystkie dane.
Przy małych ilościach nie stanowi to problemu, jednak sytuacja się zmienia
kiedy przychodzi do wprowadzenia danych o rozmiarach liczonych w gigabajty.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
3
SQL*LOADER.
SQL*Loader jest dość poręcznym narzędziem, które pozwala integrować
dane z różnych źródeł. Wprowadzanie danych przy pomocy SQL*Loadera
zostanie zademonstrowane na przykładowej tabeli systemu Oracle o nazwie
BANK .
Dla potrzeb demonstracji zbudowano arkusz, który zawiera dane takie jak
id_banku , oraz jego nazwę. Następnie można wykorzystać możliwość arkusza
i zapisać dane w postaci pliku CSV, czyli kolejne dane będą oddzielone
ś
rednikami.
Tak spreparowany plik z danymi należy przegrać do katalogu w którym
znajduje się plik z SQL*Loader’em. Sam program można skopiować z katalogu
w którym został zainstalowany Oracle z podkatalogu bin.
Aby rozpocząć ładowanie danych należy stworzyć plik sterujący, który
będzie zawierał odpowiednie parametry poniżej przedstawiono listing tego
pliku. Ponadto plik musi być zapisany z rozszerzeniem *.ctl.
Po zapisaniu arkusza Excel do pliku CSV dane wyglądają następująco:
1 BRE
2 mBank
3 PKO SA
4 Fortis
5 BHP
6 PKO BP
7 BG
Ż
8 Milenium
9 Eurobank
10 Volkswagen
11 BGK
12 Agrobank
13 Bank Handlowy
14 Bank Staropolski
Listing wprowadzanego pliku ster.ctl
load data
infile banki.csv
into table BANK
replace
fields terminated by ';' określa rodzaj
separatora
( bk_id char,
nazwa char
)
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
4
Następnie poprzez wywołanie „sqlldr use/rpassw control=ster”
doprowadzamy do ładowania plików do tabeli. W wywołaniu podana została
nazwa użytkownika oraz hasło i nazwa pliku sterującego.
SQL*Leader może sczytywać dane niemal z każdego pliku, w którym
dane są zapisane w kolejności i oddzielone separatorem, który można określić
w pliku sterującym.
W wyniku procesu wprowadzania danych są generowane następujące
pliki: „ster.log; ster.bad (tylko w przypadku gdy jakieś rekordy, dane nie zostaną
wprowadzone do tabeli).
TABELE ZEWNĘTRZNE.
Tabele zewnętrzne stanowią cenny element podczas tworzenia hurtowni
danych. Umożliwiają one definiowanie tabel, które nie są tabelami tradycyjnymi
(czyli takimi, które są zarządzane przez serwer bazy danych). Tabele zewnętrzne
są przechowywane w zwykłych plikach systemu plików. Pozwala to na
zadeklarowanie pliku danych jako tabeli i następnie pobieranie z niego danych.
Aby stworzyć tabelę zewnętrzną należy w bazie danych utworzyć obiekt
katalogu (directory). Można tego dokonać za pomocą „SQL PLUS Worksheet”
wpisując następujące polecenie
SQL> create or replace directory t_zew as ‘d/dyplom/kat’
Natomiast usuwamy katalog poleceniem “drop directory t_zew”.
Kolejnym krokiem będzie zdefiniowanie tabeli zewnętrznej korzystamy z
następującego skryptu. (UWAGA!) Jednak przed stworzeniem tabeli
zewnętrznej należy w stworzonym katalogu (w poprzednim poleceniu) na dysku
umieścić następujące pliki „banki2.bad”, „banki2.dis”, „banki2.log”, oraz plik z
danymi w naszym przypadku „banki.csv”. Oczywiście nazwy plików są ściśle
związane ze skryptem tworzącym tabelę zewnętrzną. Dopiero po takim
przygotowaniu katalogu można „odpalić” skrypt tworzący tabelę zewnętrzną.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
5
CREATE TABLE banki2
( bk_id number(10), DEFINICJA
nazwa varchar2(20)
)
ORGANIZATION EXTERNAL
( TYPE oracle_loader
DEFAULT DIRECTORY tab_zew
ACCESS PARAMETERS
(
RECORDS DELIMITED BY newline
BADFILE 'banki2.bad'
DISCARDFILE 'banki2.dis'
LOGFILE 'BANKI2.LOG'
FIELDS TERMINATED BY ";"
(
bk_id char,
nazwa char
)
)
LOCATION ('banki.csv')
)
REJECT LIMIT UNLIMITED;
Możliwe jest także wprowadzanie danych poprzez stworzenie odpowiednich
procedur przy użyciu języka PL/SQL.
MECHANIZMY HURTOWNI DANYCH W ORACLE 9i.
Po utworzeniu hurtowni przykładowe dane np. mogą być wygenerowane
przy użyciu arkusza Excel i wprowadzone do hurtowni danych za pomocą
programu SQL*Loader. Część danych (szczególnie dane słownikowe) można
wprowadzić za pomocą formatek ekranowych wygenerowanych za pomocą
programu Form Builder lub innej aplikacji.
System Oracle udostępnia użytkownikowi cały zestaw metod, które są
niezwykle pomocne w analizie danych. Narzędzia w których wykorzystywane
są te metody przede wszystkim są skierowane do hurtowni danych.
Użytkownicy nie muszą ograniczać analiz do sumowania, zliczania czy
uśredniania danych. Możliwe są takie funkcje jak szeregowanie zbiorów,
INSTRUKCJE DOTYCZĄCE SPOSOBU WCZYTYWANIA PLIKU ORAZ NAZW
PLIKÓW, KTÓRE ZOSTANĄ WYKORZYSTANE DO REJESTROWANIA
KOMUNIKATÓW O EWENTUALNYCH PROBLEMACH ZWIĄZANYCH Z
TWORZENIEM TABELI
.
DEFINICJA TABELI JAKO TABELI ZEWNĘTRZNEJ (OKREŚLENIE JEJ RODZAJU)
.
TABELI. KOLUMNY POWINNY ODZWIERCIEDLAĆ STRUKTURĘ PÓL W
PLIKU DANYCH.
DEFINICJA STRUKTURY PLIKU DANYCH. JEST TO DEFINICJA IDENTYCZNA
JAK TA KTÓRA BYŁA TWORZONA W PRZYPADKU SQL LOADERA.
OKREŚLENIE NAZWY PLIKU Z DANYMI.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
6
tworzenie agregacji i przeprowadzanie jeszcze bardziej skomplikowanych
analiz.
TABELE PARTYCJONOWANE
.
Tabela partycjonowana nie należy do zestawu narzędzi, które pozwalają
analizować i przetwarzać dane. Tabele partycjonowane to rozwiązanie, które
pozwala na zwiększenie wydajności zapytań analizujących dane. Metoda ta
bardzo dobrze sprawdza się w przypadku hurtowni danych. Świadczą o tym
następujące fakty:
1.
Tabele partycjonowane wykorzystują mniejsze pliki ( np. nie większe niż
2GB). Archiwizacja takich plików jest dużo łatwiejsza.
2.
Jeżeli baza danych została podzielona na mniejsze części, awaria sprzętu
spowoduję utratę mniejszej liczby danych.
3.
Przeprowadzanie czynności jaką jest analiza tabeli (statystyki) - zabiera
mniej czasu.
4.
Poszczególne części tabeli mogą być poddawane czynnościom
konserwacyjnym
podczas
gdy
pozostałe
partycje
mogą
być
wykorzystywane przez użytkowników.
5.
Jednym z najważniejszych powodów partycjonowania jest wydajność.
Przypuśćmy, że tabela zawiera 60 milionów wierszy a tabela jest
podzielona na partycje po 10 milionów, to w momencie wykonania
zapytania system przeszukuje tylko 1/6-stą tabeli, a nie całą tabelę. Co
wprost proporcjonalnie przekłada się na szybkość wykonywania tego
zapytania.
Można wyróżnić następujące sposoby partycjonowania tabel :
•
Partycjonowanie zakresowe.
•
Partycjonowanie według listy.
•
Partycjonowanie haszowe.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
7
Najprostszą i najbardziej powszechną (oraz dostępną najwcześniej)
metodą partycjonowania jest partycjonowanie zakresowe. Dostępne jest od 1997
roku w bazach danych firmy Oracle od wersji 8.0.
Przed przystąpieniem do partycjonowania należy wybrać klucz
partycjonowania.
Wybór ten ma zasadniczy wpływ na realizację i efektywność
późniejszych zapytań.
Przy wyborze kolumny, która ma stać się kluczem do partycjonowania
należy uwzględnić następujące czynniki:
1.
Kolumna klucza partycjonowania musi być częścią predykatu zapytania
SQL, wybierającego dane z partycjonowanej tabeli.
2.
Kolumna klucza musi zawierać wystarczającą liczbę różnych wartości,
aby możliwy był podział tabeli na odpowiednią liczbę partycji.
3.
Po stwierdzeniu odpowiedniej liczby rozróżnialnych wartości kolumn
należy zadbać o równomierny rozkład wartości kolumny, ponieważ
wpływa on bezpośrednio na rozkład wierszy w partycjach.
Najlepiej przy wyborze kolumny partycjonowania uwzględnić jak często
nazwa tej kolumny pada podczas wykonywania zapytań SQL. Następnie należy
zadbać, o aby wartości według, których tabela partycjonowana pozwoliły na
równomierny rozkład danych. Należy tak dobrać wartości aby różnica liczby
wierszy zakwalifikowanych do poszczególnych partycji nie przekraczała więcej
niż 8,9%. Poniżej przedstawiony zostanie kod SQL tworzący tabelę
partycjonowaną zakresowo według kolumny data
.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
8
CREATE TABLE SPRZEDAZ
(SP_ID NUMBER NOT NULL
,SP_CENA NUMBER
,SP_SZT NUMBER(5)
,SP_DATA DATE
,SP_UWAGI VARCHAR2(50)
,SP_KLT_KLT_ID NUMBER NOT NULL
,SP_OKR_OKR_ID NUMBER NOT NULL
,SP_TEL_TEL_ID NUMBER NOT NULL
,MI_MI_ID NUMBER NOT NULL
,KD_KD_ID NUMBER NOT NULL
)
partition by range (sp_data)
(partition sp_ok1 values less than (to_date('2004-STY-20','yyyy-mon-dd'))
tablespace cw_sp1,
partition sp_ok2 values less than (to_date('2004-CZE-14','yyyy-mon-dd'))
tablespace cw_sp2,
partition sp_ok3 values less than (to_date('2004-SIE-27','yyyy-mon-dd'))
tablespace cw_sp3,
partition sp_ok4 values less than (to_date('2004-PAź-22','yyyy-mon-dd'))
tablespace cw_sp4,
partition sp_ok5 values less than (maxvalue)
tablespace cw_sp5
)
Listing kodu tworzącego tabelę partycjonowaną.
Aby było możliwe stworzenie samej tabeli partycjonowanej należy wcześniej
stworzyć odpowiednie przestrzenie tabel. Na listingu poniżej przedstawiono kod
dzięki któremu zostały stworzone przestrzenie tabel do których przypisano
poszczególne zakresy partycjonowanych danych.
create tablespace cw_sp1
datafile 'D:\dyplom\p_t_cw\cw_sp1.dbf' size 10M reuse
default storage (initial 10k
next 10k
minextens 1
maxextens 100
);
Listing kodu tworzącego przestrzeń tabel o nazwie cw_sp1 wykorzystaną przy tworzeniu partycji sp_ok1 w
tabeli sprzedaż.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
9
PERSPEKTYWY ZMATERIALIZOWANE.
Perspektywa stanowi środek wybiórczej prezentacji różnych danych
przechowywanych w tabelach hurtowni danych. Często jest używana jako
ś
rodek zabezpieczający dane, dzięki któremu danemu użytkownikowi można
udostępniać dane tylko przeznaczone dla niego. Sama perspektywa jest tylko
definicją dostępu do danych. Definicja ta jest realizowana w momencie
wywołania perspektywy – czyli faktycznie w tym momencie zostanie wykonane
zapytanie tworzące perspektywę. Sytuacja taka jest powodem obciążenia
serwera. Jeżeli perspektywa jest dość skomplikowana to przy pobieraniu dużej
liczby danych może być przyczyną zamrożenia systemu.
Tradycyjna perspektywa posiada małą wydajność z tego powodu
stworzony został mechanizm zwany perspektywą zmaterializowaną (ang.
snapshot).
Dzięki perspektywom zmaterializowanym można dokonywać w systemie
Oracle tzw. przepisywania zapytań (ang. query rewrite). Technika ta polega na
podejmowaniu przez system bazy danych decyzji o tym, czy zapytanie powinno
zostać zrealizowane na podstawie danych przechowywanych w tabelach bazy
danych, czy też wygenerować zbiór wynikowy na podstawie utworzonego
wcześniej zbiorczego podsumowania danych.
Funkcja ta działa w sposób transparentny (tzn. niezauważalny) dla
końcowego użytkownika. Przepisywanie zapytania zwiększa wydajność
systemu, czyli jest bardzo pożądane.
Perspektywy zmaterializowane są obiektami schematu bazy
danych, które można wykorzystać do generowania podsumowań, replikacji i
rozpraszania danych. Nadają się do zastosowania w szerokiej gamie systemów
przetwarzających dane, w tym w hurtowniach danych, systemach wspomagania
decyzji czy w przetwarzaniu rozproszonym lub wręcz w przypadku modeli
mobilnych.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
10
W świecie hurtowni danych perspektywy zmaterializowane są najczęściej
używane do przechowywania podsumowań i zbiorów wynikowych funkcji
zbiorczych. Takie zastosowanie perspektyw zmaterializowanych może znacząco
zwiększyć szybkość przetwarzania zapytań odwołujących się do hurtowni
danych. Czas niezbędny do przeliczenia zbiorów podsumowań jest skrócony o
czas niezbędny do wykonania samego podsumowania. W poprzednich wersjach
Oracle poprzedzających wersję Oracle 8i odpowiedniki perspektyw
materializowanych nazywano migawkami (ang. snapshot).
Na
rysunku
3przedstawiona
została
architektura
perspektywy
zmaterializowanej.
Do najznaczniejszych elementów perspektywy zmaterializowanej należy:
1.
Stanowisko główne (ang. master site) – miejsce, w którym jest
przechowywana tabela źródłowa migawki.
2.
Tabela źródłowa (ang. source table) – przechowuje dane źródłowe
migawki.
3.
Dziennik migawki tabeli źródłowej (ang. source table snapshot log)
– rejestr transakcji odwołujących się do tabel źródłowych,
przechowywany lokalnie, w pliku dziennika tychże tabel.
4.
Kolejka zadań Oracle9i (ang. Job process queue) – zadania te
propagują zawartość dziennika migawki do stanowiska zdalnego.
5.
Stanowisko zdalne (ang. remote site) – transakcje na stanowisku
zdalnym są przetwarzane w miarę napływania do stanowiska i
powodują
wstawienie,
usunięcie
i
modyfikację
wierszy
przechowywanych w migawce.
Przed przystąpieniem do tworzenia perspektyw zmaterializowanych
należy się upewnić czy użytkownik, który się będzie tym zajmował posiada
uprawnienia systemowe do tego rodzaju czynności.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
11
Stanowisko tabeli zdalnej
Migawka (perspektywa
zmaterializowana)
Stanowisko tabeli głównej.
Dziennik migawki tabeli
ź
ródłowej
Tabel
ź
ródłowa
Kolejka zada
ń
oracle 9i
Architektura perspektywy zmaterializowanej.
W systemie Oracle 9i można stworzyć dwa rodzaje migawek prostą i
złożoną. Jeżeli na jedne z poniższych pytań odpowiedź brzmi tak, to dana
migawka jest migawką prostą :
1.
zapytanie odwołuje się do pojedynczej tabeli,
2.
w stosunku do kolumn tabeli źródłowej nie są wykonywane funkcje
agregujące, nie występuje grupowanie wierszy, przy czym:
a.
agregacja to jeden z terminów z dziedziny operacji
podsumowujących. Agregacja polega często na zsumowaniu
wartości w kolumnie liczbowej w wierszach tabeli (tabel)
ź
ródłowej migawki.
b.
Grupowanie to scalanie wierszy o podobnej wartości w
wyznaczonej kolumnie. Realizowane jest za pośrednictwem
klauzuli group by zapytania SQL.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
12
Występuje jeszcze jedna zasadnicza różnica. Migawka prosta może
wykorzystywać tzw. dziennik migawki natomiast migawka złożona jest już
pozbawiona takiej możliwości.
Aby stworzyć migawkę prostą należy w pierwszej kolejności zbudować
dziennik dla tabeli na której będzie ta migawka założona. Dziennik jest
budowany w następujący sposób:
CREATE SNAPSHOT LOG ON SPRZEDAZ;
Dalsza
konfiguracja
polega
na
zmianie
wartości
parametru
JOB_QUEUE_PROCESSES. Najczęściej stosowane są tu wartości całkowite 2,
8 lub 16. parametr ten znajduje się w pliku INIT.ORA.
W przypadku bazy danych KOMTELE będzie to następująca ścieżka
dostępu: D:\oracle9i\ora92\admin\KTELE\pfile. Plik wystarczy poddać edycji
za pomocą zwykłego edytora tekstu. Jest to ostatni etap konfiguracji stanowiska
głównego.
Kolejnym etapem staje się konfiguracja stanowiska zdalnego. Aby
korzystać z migawki należy stworzyć łącze bazy. Naturalnie należy pamiętać, że
tworząc łącze należy posiadać uprawnienia
create materialized view
. Łącze bazy
danych jest niezbędne do korzystania z migawki.
Tworzy je się następująco:
CREATE DATABASE LINK DO_KTELE
CONNECT TO OPERATOR IDENTIFIED BY user/passw
USING ‘WISNIA’;
Tworząc łącze bazy danych w pierwszym wierszu określamy nazwę łącza,
która nie może być większa niż 30 znaków. Bardzo dobrym zwyczajem jest
nadawanie dla łącz danych nazw po których łatwo można by skojarzyć jaką rolę
pełni to łącze w systemie bazodanowym. Wiersz 2 zawiera informacje
uwierzytelniające wymagane do nawiązani połączenia.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
13
Przykładowo migawka prosta może być zrealizowana w sposób wzorowany na
poniższym listingu.
CREATE MATERIALIZED VIEW KLIENT_W
TABLESPACE KLT_W
1 REFRESH FAST
2 START WITH SYSDATE NEXT SYSDATE+1 AS
3 SELECT * FROM KLIENT
Wiersz 1 : zawiera definicję metody odświeżania migawki. Oznacza to, że
transakcje ingerujące w tabele bazową (klient- przechowywaną na stanowisku
głównym) będą okresowo umieszczane w dzienniku migawki i przekazywane
do stanowiska zdalnego. Czas odświeżania definiują klauzule w wierszu 2
analizowanego polecenia.
Wiersz 2 po pierwszym stworzeniu migawki jej dane będą aktualizowane
codziennie.
Wiersz 3 zadaniem migawki będzie realizowanie zapytania select * from
KLIENT (wybiera wszystkie wiersze z tabeli klient).
Migawka prosta stała się dobrym wprowadzeniem do tworzenia migawki
złożonej. Kolejny Listening przedstawia kod dzięki któremu została stworzona
migawka złożona dla hurtowni Ktele. Migawka ma za zadanie obliczać wartość
sprzedaży dziennej aparatów telefonicznych w firmie KOM-TELE. Przed
stworzeniem migawki została utworzona dla niej przestrzeń tabel sprz_w.
Kolejnym parametrem jest sposób odświeżania migawki dostępne są
następujące opcje:
•
Force (użyta przy konstruowaniu migawki sprzedaz_regoin1)-
opcja ta powoduje, że oprogramowanie system Oracle podejmuje
próbę odświeżania w trybie Fast. Jeżeli odświeżanie nie jest
możliwe zostanie wykonane odświeżanie w trybie complete.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
14
•
Fast – w trybie Fast są wychwytywane zmiany w tabeli (tabelach)
ź
ródłowej od momentu wykonania ostatniej operacji odświeżania,
poczym zmiany są wprowadzone do migawki.
•
Complete – w tym trybie polecenie modyfikujące tabelę źródłową
jest wykonywane również w stosunku do migawki.
Migawka złożona
CREATE MATERIALIZED VIEW sprzedaz_REGION1
TABLESPACE sprz_w
1 REFRESH FORCE
2 START WITH SYSDATE+10/1440 AS
3 SELECT TRUNC(SPRZEDAZ.SP_DATA) AS CZAS_TRANSAKCJI,
4 SUM ((SPRZEDAZ.SP_CENA)*(SPRZEDAZ.SP_SZT)) AS
WARTOSC_SPRZEDAZY_REGIONALNEJ
5 FROM SPRZEDAZ, REGION, MIASTO
6 WHERE ((SPRZEDAZ.MI_MI_ID = MIASTO.MI_ID)
7 AND (MIASTO.REG_REG_ID = REGION.REG_ID) AND
(REGION.REG_ID='1')) GROUP BY (SPRZEDAZ.SP_DATA);
Kod tworzący migawkę złożoną dla hurtowni danych Ktele.
Wynikiem zapytania select * sprzedaz_region1; jest wypisanie dziennych
obrotów w regionie 1 (polska północ) (wydruk poniżej)
CZAS_TRA
WRTOSC_SPRZEDAZY_REGIONALNEJ
--------
----------------------------
04/01/19 347730
04/06/12 316690
04/08/26 448920
04/10/21 283360
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
15
Dla migawki złożonej wiersz 1 tak jak w migawce prostej określa rodzaj
odświeżania migawki.
Wiersz 2 określa momenty, w których migawka będzie odświeżana. W
przypadku migawki złożonej z listingu wypełnianie danymi nastąpi zaraz po jej
utworzeniu, następnie ta operacja będzie powtarzana co 10 minut (doba liczy
1440 minut więc zapis 10/1440 będzie oznaczał odświeżanie co 10min).
Wiersze od 3-7 zawierają polecenie, które tworzy podsumowanie dla
migawki wybierając odpowiednie dane z tabel.
MIGAWKA CZY PERSPEKTYWA?
Wybór nie jest trudny jeżeli się weźmie pod uwagę problemy związane z
hurtownią danych. Wybór pada na migawkę.
Aby wykonać jedną perspektywę serwer bazy danych najczęściej musi
zrealizować z tego powodu konkretne zapytanie, oznacza to często pochłonięcie
dużych zasobów systemowych.
Jeżeli do tego w jednym czasie pojawi się ponad 15 żądań skorzystania z
jakiejkolwiek perspektywy jest duża szansa, że system stanie się niewydolny.
Migawka natomiast dysponuje swoją tabelą i danymi, jej odświeżanie polega
najczęściej na rozpoznaniu zmian jakie zaszły w tabeli źródłowej i uzupełnieniu
ich w migawce. Jest to operacja znacznie mniej „zasobo-żerna” niż wykonanie
zwykłej perspektywy.
W rozwiązaniach, kiedy bazy danych nie mogły korzystać z mechanizmu
migawek były tworzone specjalnie oddzielne tabele podsumowujące, dla
których programiści tworzyli skomplikowane procedury obsługujące proces ich
odświeżania. Można powiedzieć, że także był to rodzaj migawki, jednak dużo
bardziej kłopotliwy dla twórców. Obecnie w systemie Oracle 9i łatwo jest
tworzyć migawki, można to robić za pomocą kodu SQL, lub Enterprise Manager
Konsole.
Hurtownie danych wyk. 2
dr inż. Paweł Sitek
16