hurtownie

Hurtownie danych wyk. 2

dr inż. Paweł Sitek

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

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

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

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

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:

Tabele partycjonowane wykorzystują mniejsze pliki ( np. nie większe niż

2GB). Archiwizacja takich plików jest dużo łatwiejsza.

Jeżeli baza danych została podzielona na mniejsze części, awaria sprzętu

spowoduję utratę mniejszej liczby danych.

Przeprowadzanie czynności jaką jest analiza tabeli (statystyki) - zabiera

mniej czasu.

Poszczególne części tabeli mogą być poddawane czynnościom

konserwacyjnym

podczas

gdy

pozostałe

partycje

mogą

być

wykorzystywane przez użytkowników.

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

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:

Kolumna klucza partycjonowania musi być częścią predykatu zapytania

SQL, wybierającego dane z partycjonowanej tabeli.

Kolumna klucza musi zawierać wystarczającą liczbę różnych wartości,

aby możliwy był podział tabeli na odpowiednią liczbę partycji.

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

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

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

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).

rysunku

3przedstawiona

została

architektura

perspektywy

zmaterializowanej.

Do najznaczniejszych elementów perspektywy zmaterializowanej należy:

Stanowisko główne (ang. master site) – miejsce, w którym jest

przechowywana tabela źródłowa migawki.

Tabela źródłowa (ang. source table) – przechowuje dane źródłowe

migawki.

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.

Kolejka zadań Oracle9i (ang. Job process queue) – zadania te

propagują zawartość dziennika migawki do stanowiska zdalnego.

Stanowisko zdalne (ang. remote site) – transakcje na stanowisku

zdalnym są przetwarzane w miarę napływania do stanowiska i

powodują

wstawienie,

usunięcie

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

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ą :

zapytanie odwołuje się do pojedynczej tabeli,

w stosunku do kolumn tabeli źródłowej nie są wykonywane funkcje

agregujące, nie występuje grupowanie wierszy, przy czym:

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.

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

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

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

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

•

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

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.