Curs Modul 3 - DW - Capitole 8-9 PDF

Baze de Date Depozit
Baze de Date Depozit 39
Cuprins
8. Vizualizri materializate ............................................................................. 41

Avantajele utilizrii vizualizrilor materializate ........................................... 41
Restricii pentru cererile care definesc o vizualizare materializat ............... 41
Numele........................................................................................................... 41
Caracteristici de stocare ................................................................................. 41
Metode de populare cu date........................................................................... 42
Momentul actualizrii .................................................................................... 42
Modaliti de actualizare ............................................................................... 42
Rescrierea cererilor ........................................................................................ 43
Clauza ORDER BY ........................................................................................ 43
Logurile (jurnalul) vizualizrilor materializate ............................................. 43
Comanda CREATE MATERIALIZED VIEW................................................. 44
Modificarea vizualizrilor materializate ....................................................... 47
Suprimarea vizualizrilor materializate......................................................... 48
Exemple de intervale la care se realizeaz actualizarea ................................ 48
Informaii despre vizualizrile materializate ................................................. 48
9. Rescrierea cererilor ...................................................................................... 49

9.1. Concepte generale ..................................................................................... 49
9.2. Activarea rescrierii cererilor..................................................................... 52
Parametrul QUERY_REWRITE_INTEGRITY ............................................... 52
Parametrul OPTIMIZER_MODE .................................................................. 53
Hint-uri pentru rescrierea cererilor ................................................................ 54
Privilegii pentru a putea activa rescrierea cererilor ....................................... 54
9.3. Metode de rescriere a cererilor ................................................................. 54
9.3.1. Metode de rescriere prin comparare la nivel de text SQL ..................... 54
Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.
9.3.2. Metode generale pentru rescrierea cererilor .......................................... 56

Metodele generale de rescriere a cererilor ce pot fi utilizate ........................ 56
Dimensiuni i constrngeri necesare pentru rescrierea cererilor................... 56
Constrngeri definite pe vizualizri .............................................................. 57
Potrivirea expresiei ........................................................................................ 58
Formatul datei calendaristice ......................................................................... 59
Compatibilitatea seleciei .............................................................................. 60
Compatibilitatea join-ului .............................................................................. 65
Join-uri comune ............................................................................................. 65
Cereri delta join ............................................................................................. 67
Vizualizri materializate delta join ............................................................... 67
Suficiena datelor ........................................................................................... 68
Compararea gruprilor................................................................................... 70
Compararea agregatelor................................................................................. 71

8. Vizualizri materializate
O vizualizare materializat, cunoscut n versiunile anterioare sub numele

de snapshot, este un obiect al schemei ce stocheaz rezultatele unei cereri i care
este folosit pentru a rezuma, calcula, replica i distribui date.
Din mai multe puncte de vedere vizualizarea materializat se comport
asemenea unui index:
scopul vizualizrii materializate este de a mri performana la execuie
a cererilor;
existena unei vizualizri materializate este transparent aplicaiilor
SQL, astfel c administratorul poate crea sau terge vizualizri
materializate fr s afecteze aplicaiilor SQL;
o vizualizare materializat necesit spaiu de stocare;
coninutul vizualizrilor materializate trebuie s fie actualizat atunci
cnd tabele de baz sunt modificate.
Avantajele utilizrii vizualizrilor materializate

Elimin costurile mari de calcul al operaiilor de join sau al agregatelor
pentru multe clase importante de cereri.
Pot fi utilizate pentru a replica date.
Permit rescrierea cererilor.
Restricii pentru cererile care definesc o vizualizare materializat

Nu pot conine expresiile ROWNUM, SYSDATE.
Nu pot referi obiecte de tip RAW, LONG RAW sau REF.
Nu pot conine operatori pe mulimi (UNION, MINUS etc).
Numele
Dac vizualizarea materializat este bazat pe un tabel declarat prebuilt,
atunci numele acesteia trebuie s fie acelai cu numele tabelului.
Caracteristici de stocare
Dac vizualizarea nu este creat pe baza unui tabel prebuilt, atunci aceasta
va necesita spaiu de stocare n baza de date. Dac nu se cunoate ct spaiu de
stocare necesit vizualizarea, atunci se poate utiliza procedura ESTIMATE_SIZE
din pachetul DBMS_OLAP, care permite estimarea spaiului de stocare necesar.

Metode de populare cu date

Metoda Descriere
BUILD Se creeaz vizualizarea i se populeaz imediat
IMMEDIATE cu date.
BUILD Se creeaz vizualizarea dar fr s conin date.
DEFERRED Popularea ulterioar cu date se poate realiza
utiliznd procedura REFRESH din pachetul
DBMS_MVIEW.
Momentul actualizrii
Mod Descriere
ON Indic declanarea unei operaii de reactualizare ori de
COMMIT cte ori sistemul permanentizeaz o tranzacie care
opereaz asupra unui tabel de baz al vizualizrii
materializate. Aceasta ar putea determina creterea
timpului de execuie a operaiei COMMIT, ntruct
reactualizarea va face parte din acest proces.
ON Este implicit i indic efectuarea reactualizrii
DEMAND vizualizrii materializate la cererea utilizatorului, prin
intermediul procedurilor specifice din pachetul
DBMS_MVIEW (REFRESH, REFRESH_ALL_
MVIEWS, REFRESH_DEPENDENT).
Modaliti de actualizare
Opiuni Descriere
COMPLETE Implic reactualizarea complet, care se realizeaz prin
reexecutarea complet a cererii din definiia vizualizrii
materializate.
FAST Indic metoda de reactualizare incremental, care se
efectueaz corespunztor modificrilor survenite n
tabelele de baz. Modificrile sunt stocate ntr-un fiier
log (jurnal) asociat tabelului de baz.
FORCE Determin reactualizarea de tip FAST, dac este posibil,
n caz contrar actualizarea de tip COMPLETE.
NEVER Indic faptul c vizualizarea nu va fi reactualizat.
Procedura DBMS_MVIEW.EXPLAIN_MVIEW indic dac o vizualizare

materializat poate fi actualizat de tip FAST sau nu.
Rescrierea cererilor
nainte de a defini o vizualizare se pot afla, utiliznd procedura
DBMS_MVIEW.EXPLAIN_MVIEW, ce tipuri de rescriere a cererilor va permite
aceasta. Dup ce vizualizarea a fost creat se poate afla, cu ajutorul procedurii
DBMS_MVIEW.EXPLAIN_REWRITE, de ce aceasta va rescrie o cerere sau nu.
O vizualizare materializat poate fi utilizat pentru rescrierea cererilor
dac n definiia sa este specificat clauza ENABLE QUERY REWRITE.
Clauza ORDER BY
Clauza ORDER BY a comenzii SELECT care definete vizualizarea este
utilizat doar la momentul crerii acesteia. Nu va fi utilizat n timpul operaiilor
de actualizare a vizualizrii. Pentru a mbunti performana cererilor care se
execut la vizualizri cu multe date, se recomand stocarea liniilor n
vizualizare, n ordinea dat de clauza ORDER BY. Aceast clauz nu este
considerat parte din definiia vizualizrii.
Logurile (jurnalul) vizualizrilor materializate
Pentru a putea realiza actualizri de tip FAST sunt necesare fiiere de tip log
definite pentru tabele de baz. Acestea se creeaz prin comanda:
CREATE MATERIALIZED VIEW LOG ON nume_tabel

[ WITH { OBJECT ID
| PRIMARY KEY
| ROWID
| SEQUENCE
| (coloan [,coloan ]...)
}
[, { OBJECT ID
| PRIMARY KEY
| ROWID
| SEQUENCE
| (coloan [,coloan ]...)
}
]...
{ INCLUDING | EXCLUDING } NEW VALUES
] ;
Clauza WITH este utilizat pentru a indica dac n fiierul log se

nregistreaz valorile pentru cheia primar, rowid-ul, id-ul obiectului sau o
combinaie a acestor identificatori atunci cnd o nregistrare din tabelul de baz
este modificat. De asemenea, se poate utiliza clauza SEQUENCE pentru a
aduga valorile unei secvene n fiierul log, cu scopul de a menine informaii
despre ordonarea nregistrrilor.

n fiierul log se pot nregistra valori ale coloanelor care nu sunt chei
primare: coloane utilizate n filtre sau coloane de join.
Clauza NEW VALUES determin dac sunt salvate n fiierele log att
valorile vechi, ct i valorile noi ale operaiilor UPDATE.
n plus de rowid-uri, pentru vizualizrile materializate care conin
agregate, trebuie incluse i clauzele INCLUDING NEW VALUES i
SEQUENCE. Se recomand utilizarea opiunii SEQUENCE cu excepia
cazurilor n care exist sigurana c niciodat nu se vor folosi combinaii de
operaii LMD pe mai multe tabele.
Jurnalul este:
necesar pentru a realiza mai rapid operaiile de refresh;
creat implicit cu opiunea WITH PRIMARY KEY, dac este omis una
dintre clauzele PRIMARY KEY, ROWID, OBJECT ID;
localizat n aceeai schem ca i tabelul de baz;
populat cu ajutorul unui declanator creat asupra tabelului de baz;
creat asupra tabelului de baz (pentru un tabel se poate defini un singur
jurnal);
denumit implicit de sistem: MLOG$_nume_tabel.
Exemple
a. Implicit, fiierul log menine valorile cheii primare.
CREATE MATERIALIZED VIEW LOG ON produse;
b. Fiierul log menine valorile cheii primare i rowid-urile nregistrrilor.

CREATE MATERIALIZED VIEW LOG ON produse
WITH PRIMARY KEY, ROWID;
c. Fiierul log-ul determin actualizarea de tip fast a vizualizrilor materializate

care conin agregate. Se aleg ca i coloane de filtrare colonele utilizate n cererea
care definete vizualizarea materializat.
CREATE MATERIALIZED VIEW LOG ON vanzari
WITH ROWID,SEQUENCE
(cantitate, pret_unitar,produs_id)
INCLUDING NEW VALUES;
Comanda CREATE MATERIALIZED VIEW

O vizualizare materializat se creeaz prin intermediul comenzii CREATE
MATERIALIZED VIEW, care are urmtoarea form sintactic:
CREATE MATERIALIZED VIEW [schema.]nume_viz_mat
[OF [schema.]tip_obiect] [ (constr_ref_domeniu) ]
[ORGANIZATION INDEX clauza_tabel_org_index]
[{proprieti_vm | ON PREBUILT TABLE

[{WITH | WITHOUT} REDUCED PRECISION]}]
[{USING INDEX
[{clauza_atribute_fizice | TABLESPACE nume_sp_tab}
[{clauza_atribute_fizice | TABLESPACE
nume_sp_tab}]]
| USING NO INDEX}]
[refresh_vm]
[FOR UPDATE]
[{DISABLE | ENABLE} QUERY REWRITE] AS subcerere;
Clauza OF permite crearea unei vizualizri materializate obiect.
Sintaxa clauzei constr_ref_domeniu este urmtoarea:
SCOPE FOR ( {ref_coloana | ref_atribut} )
IS [schema.]nume_tabel_scope
[, SCOPE FOR ( {ref_coloana | ref_atribut} )
IS [schema.]nume_tabel_scope]
Clauza poate fi utilizat pentru restricionarea domeniului referinelor la
tabelul nume_tabel_scope. Valorile dintr-o coloan de tip REF vor adresa
obiecte din tabelul identificat prin nume_tabel_scope. n acest tabel sunt stocate
instane de obiecte care au acelai tip ca i coloana REF.
Opiunea ON PREBUILT TABLE permite considerarea unui tabel existent
ca fiind o vizualizare materializat predefinit. Tabelul trebuie s aib acelai
nume i s se afle n aceeai schem ca vizualizarea materializat rezultat. La
tergerea acestei vizualizri, tabelul revine la statutul su iniial. Pentru o
vizualizare materializat de acest tip, alias-urile de coloan din clauza subcerere
trebuie s corespund, ca numr i tip de date, coloanelor din tabel.
Clauza WITH REDUCED PRECISION permite ca precizia coloanelor
tabelului sau vizualizrii materializate s nu coincid cu precizia coloanelor
returnate de subcerere. Pentru a impune respectarea ntocmai a preciziei, sintaxa
dispune de opiunea WITHOUT REDUCED PRECISION, care este implicit.
Atributele fizice au o semantic asemntoare celei descrise de
clauza_proprieti_fizice din cadrul comenzii CREATE TABLE. Spre deosebire
de tabele, pentru o vizualizare materializat nu poate fi specificat opiunea
ORGANIZATION EXTERNAL.
Clauza TABLESPACE specific spaiul tabel n care urmeaz s fie creat
vizualizarea materializat. n absena acesteia, vizualizarea va fi creat n spaiul
tabel implicit al schemei care o conine.
Clauza USING INDEX permite stabilirea de valori ale parametrilor
INITRANS, MAXTRANS i STORAGE ai indexului implicit care este utilizat de
sistemul Oracle pentru a ntreine datele vizualizrii materializate. Dac este
omis clauza, sistemul va utiliza indexul implicit pentru ameliorarea vitezei de
reactualizare incremental a vizualizrii materializate. n aceast clauz nu poate
aprea parametrul PCTFREE. Pentru a suprima crearea indexului implicit, se

poate utiliza opiunea USING NO INDEX. Un index alternativ poate fi creat
explicit prin comanda CREATE INDEX.
Clauza proprieti_vm este util pentru descrierea vizualizrilor
materializate care nu se bazeaz pe un tabel existent (nu sunt construite cu
opiunea ON PREBUILT TABLE). Dintre proprietile care pot fi specificate n
aceast clauz, se menioneaz: clauza_partiionare_tabel, CACHE sau
NOCACHE, clauza_paralelism. Acestea sunt similare celor tratate n cadrul
comenzii CREATE TABLE. Pe lng acestea, poate fi menionat opiunea
BUILD IMMEDIATE | DEFERRED care determin introducerea de linii n
vizualizarea materializat imediat, respectiv la prima operaie de reactualizare
(refresh). n acest ultim caz, pn la prima operaie de reactualizare, vizualizarea
nu va putea fi utilizat n rescrierea cererilor. Opiunea IMMEDIATE este
implicit.
Prin refresh_vm se specific metodele, modurile i momentele la care
sistemul va reactualiza vizualizarea materializat. Sintaxa clauzei este
urmtoarea:
{ REFRESH
[ {FAST | COMPLETE | FORCE} ]
[ON {DEMAND | COMMIT} ]
[START WITH data] [NEXT data]
[WITH {PRIMARY KEY | ROWID} ]
| USING
{DEFAULT [ {MASTER | LOCAL} ] ROLLBACK SEGMENT
| [{MASTER | LOCAL} ]
ROLLBACK SEGMENT nume_segm_anulare }}
| NEVER REFRESH}
Clauza WITH PRIMARY KEY este implicit i permite ca tabelele de baz
s fie reorganizate fr a afecta eligibilitatea vizualizrii materializate pentru
reactualizarea de tip FAST. Tabelul de baz trebuie s conin o constrngere
PRIMARY KEY. Opiunea nu poate fi specificat pentru vizualizri materializate
obiect.
Opiunea WITH ROWID asigur compatibilitatea cu tabelele de baz din
versiunile precedente lui Oracle8.
Clauza USING ROLLBACK SEGMENT specific segmentul de anulare
distant care urmeaz s fie utilizat pentru reactualizarea vizualizrii
materializate. Cuvntul cheie DEFAULT determin ca sistemul s aleag acest
segment n mod automat. Opiunile MASTER i LOCAL specific segmentul de
anulare distant care urmeaz s fie utilizat pe site-ul distant pentru vizualizarea
materializat individual, respectiv pentru grupul local de reactualizare care
conine vizualizarea materializat. Opiunea LOCAL este implicit.
Clauza FOR UPDATE permite actualizarea unei vizualizri materializate.

Opiunea AS specific cererea care definete vizualizarea materializat.

Vizualizrile materializate nu pot conine coloane de tip LONG. Dac n clauza
FROM a cererii din definiia vizualizrii materializate se face referin la o alt
vizualizare materializat, atunci aceasta va trebui reactualizat ntotdeauna
naintea celei create n instruciunea curent.
Modificarea vizualizrilor materializate

Comanda ALTER MATERIALIZED VIEW permite intervenia asupra unei
vizualizri materializate, ntr-unul din urmtoarele sensuri:
modificarea caracteristicilor de stocare;
modificarea metodei, modului sau timpului de reactualizare (refresh);
modificarea structurii, astfel nct s devin un alt tip de vizualizare
materializat;
activarea sau dezactivarea funciei de rescriere a cererilor.
O sintax simplificat a acestei comenzi este urmtoarea:
ALTER MATERIALIZED VIEW nume_viz_materializat
[ {REBUILD | alter_vm_refresh} ]
[ { {ENABLE | DISABLE} QUERY REWRITE
| COMPILE | CONSIDER FRESH} ];
Clauza REBUILD permite regenerarea operaiilor de reactualizare atunci
cnd se modific un tip care este referit n vizualizarea materializat.
Specificarea acestei opiuni interzice utilizarea altor clauze n aceeai
instruciune ALTER MATERIALIZED VIEW.
Clauza alter_vm_refresh permite modificarea metodei, modului sau
perioada de timp la care se va realiza actualizarea. n cazul modificrii
coninutului tabelelor de baz ale vizualizrii materializate, datele din
vizualizare trebuie reactualizate astfel nct s reflecte datele existente. Sintaxa
clauzei este asemntoare clauzei refresh_vm, prezentat n cadrul instruciunii
CREATE MATERIALIZED VIEW. Spre deosebire de aceasta, clauza nu prevede
opiunea NEVER REFRESH.
Clauza QUERY REWRITE, prin opiunile ENABLE i DISABLE,
determin ca vizualizarea materializat s fie, sau nu, eligibil pentru rescrierea
cererilor.
Clauza COMPILE permite revalidarea explicit a vizualizrii
materializate. Dac un obiect de care depinde vizualizarea materializat este
suprimat sau modificat, vizualizarea rmne accesibil, dar nu este eligibil
pentru rescrierea cererilor. Clauza este util pentru revalidarea explicit a
vizualizrii materializate, astfel nct aceasta s devin eligibil n operaia de
rescriere a cererilor.
Opiunea CONSIDER FRESH indic sistemului s considere vizualizarea
materializat ca fiind reactualizat i deci eligibil pentru rescrierea cererilor.

Suprimarea vizualizrilor materializate

Pentru tergerea unei vizualizri materializate existente n baza de date se
utilizeaz instruciunea:
DROP MATERIALIZED VIEW nume_viz_materializat;
La tergerea unui tabel de baz, sistemul nu va suprima vizualizrile
materializate bazate pe acesta. Atunci cnd se ncearc reactualizarea unei astfel
de vizualizri materializate, va fi generat o eroare.
Exemple de intervale la care se realizeaz actualizarea

SYSDATE +1 operaia de refresh se realizeaz la o zi de la ultimul
refresh;
NEXT_DAY(TRUNC(SYSDATE),MONDAY)+15/24 operaia de refresh
se realizeaz n zilele de Luni la ora 3:00 PM;
ADD_MONTHS(SYSDATE,3) operaia de refresh se realizeaz la fiecare
3 luni;
SYSDATE +1/24 operaia de refresh se realizeaz din or n or.
Informaii despre vizualizrile materializate

USER_MVIEWS
USER_MVIEW_LOGS
USER_REFRESH

9. Rescrierea cererilor
Optimizorul recunoate n mod automat atunci cnd o vizualizare

materializat poate i ar trebui utilizat pentru a satisface cerina utilizatorului.
Optimizorul rescrie cererea pentru a putea utiliza vizualizarea materializat.
Cererile se execut direct pe vizualizarea materializat n loc de tabelele de baz.
n general, rescrierea cererilor folosind vizualizri materializate n locul
tabelelor de baz mbuntete timpul de rspuns.
n clauza SELECT din definiia vizualizrii materializate nu se pot
specifica tabele distante dac se dorete meninerea avantajelor rescrierii cererii.
n concluzie, rescrierea cererilor permite comenzilor SQL care sunt
exprimate pe tabele sau vizualizri s fie transformate n comenzi SQL care s
acceseze una sau mai multe vizualizri materializate ce au fost definite asupra
tabelelor de baz. Transformarea este transparent utilizatorilor finali i
aplicaiilor (nefiind nevoie de nici o intervenie a acestora). Deoarece rescrierea
cererilor este transparent, vizualizrile materializate pot fi adugate sau terse
la fel ca n cazul indecilor, fr invalidarea comenzilor SQL care le utilizau.
9.1. Concepte generale
nainte ca cererea s fie rescris trebuie realizate cteva verificri pentru a

determina dac aceasta poate fi utilizat n operaia de rescriere. Dac cererea nu
trece validrile, atunci aceasta se va executa asupra tabelelor de baz.
Optimizorul Oracle folosete dou metode pentru a determina dac o
cerere poate fi rescris.
Prima metod const n compararea comenzii SQL candidat pentru
rescriere cu comanda SQL care apare n definiia vizualizrii
materializate.
Dac aceast metod eueaz, atunci optimizorul folosete o metod
general, n care compar join-urile, seleciile, coloanele de date,
gruprile de coloane i funciile agregat ale cererii cu cele ale vizualizrii.
Rescrierea cererilor opereaz pe:
cereri SELECT;
subcereri care apar n comanda CREATE TABLE ... AS SELECT;
subcereri care sunt conectate prin operatorii UNION, UNION ALL,
INTERSECT sau MINUS;
subcereri care apar n comenzile LMD (INSERT, DELETE, UPDATE).
Rescrierea sau nu a cererilor este influenat de anumii factori:

activarea sau dezactivarea opiunii de rescriere a cererilor;
- prin comenzile CREATE sau ALTER pentru anumite vizualizri
materializate;
- prin setarea parametrului QUERY_REWRITE_ENABLED;
- prin folosirea hint-urilor REWRITE sau NOREWRITE n comenzile
SQL;
nivelurile de integritate ale rescrierii;
constrngeri i dimensiuni.
Sistemul furnizeaz procedura DBMS_MVIEW.EXPLAIN_REWRITE care
informeaz dac rescrierea unei cereri este posibil i ce vizualizare
materializat va fi utilizat.
Atunci cnd se utilizeaz rescrierea cererii, trebuie create vizualizri
materializate care s satisfac un numr mare de cereri. De exemplu, dac se
identific 20 de cereri care se aplic asupra tabelelor de fapte sau de dimensiuni,
atunci se pot crea 5-6 vizualizri materializate care s satisfac aceste cereri.
Definiia unei vizualizri materializate poate include oricte funcii agregat i
oricte join-uri. Sistemul Oracle ofer o serie de proceduri consultative, prin
pachetul DBMS_OLAP, pentru designul i evaluarea vizualizrilor materializate
destinate rescrierii cererilor. Aceste funcionaliti sunt cunoscute sub denumirea
de Summary Advisor sau Advisor (sunt disponibile i n Oracle Enterprise
Manager). Dac vizualizarea materializat va fi utilizat pentru rescrierea
cererilor, atunci aceasta trebuie stocat n aceeai baz de date ca i tabelele de
fapte sau/i de dimensiuni pe care se bazeaz aceasta. O vizualizare
materializat poate fi partiionat i se pot defini vizualizri materializate pe
tabele partiionate.
Exemple de vizualizri materializate utilizate la rescrierea cererilor

Presupunem c sunt definite urmtoarele vizualizri materializate.
a) Vizualizrile materializate care conin join-uri i agregate.
CREATE MATERIALIZED VIEW vm1_sum_domeniu_luna
ENABLE QUERY REWRITE
AS
SELECT p.categorie_4 AS domeniu, t.luna AS luna,
SUM(cantitate * pret_unitar_vanzare) AS valoare
FROM vanzari v, dim_produse p, dim_timp t
WHERE t.id_timp = v.timp_id
AND v.produs_id = p.id_produs
GROUP BY categorie_4, luna;
CREATE MATERIALIZED VIEW vm2_sum_prod_luna_client

AS
SELECT p.denumire AS produs, t.luna AS luna,

v.client_id AS client,
GROUP BY p.denumire, t.luna, v.client_id;
CREATE MATERIALIZED VIEW vm3_sum_domeniu_luna_oras

AS
r.oras AS oras,
SUM(cantitate * pret_unitar_vanzare) AS valoare,
COUNT(cantitate * pret_unitar_vanzare) AS numar
FROM vanzari v, dim_produse p,
dim_timp t, dim_regiuni r
AND v.produd_id = p.id_produs
AND v.regiune_id = r.id_regiune
GROUP BY p.categorie_4, t.luna, r.oras;
b) Vizualizrile materializate care conin doar join-uri.
CREATE MATERIALIZED VIEW vm4_produs_trimestru

AS
SELECT denumire, trimestru,
cantitate * pret_unitar_vanzare valoare
FROM vanzari v, dim_produse p, dim_timp t,
AND v.produd_id = p.id_produs;
CREATE MATERIALIZED VIEW vm5_produs_trimestru_outer

AS
SELECT denumire, trimestru,
cantitate * pret_unitar_vanzare valoare
FROM vanzari v, dim_produse p, dim_timp t,
AND p.id_produs = v.produs_id (+);
Pentru a permite optimizorului s determine dac poate utiliza rescrierea

cererilor trebuie colectate statistici. Aceasta se poate realiza pentru fiecare obiect
sau pentru toate obiectele noi create care nu au statistici.
Exemplu:
Statistici pentru un obiect (de exemplu, pentru vizualizarea materializat
vm_produs_trimestru):
EXECUTE DBMS_STATS.GATHER_TABLE_STATS
('USER_DW','VM_PRODUS_TRIMESTRU',
estimate_percent=>20,block_sample=>TRUE,
cascade=>TRUE);
Pentru toate obiectele noi create, la nivel de schem:
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS
('USER_DW', options => 'GATHER EMPTY',
estimate_percent=>20, block_sample=>TRUE,
cascade=>TRUE);
9.2. Activarea rescrierii cererilor
Pentru activarea rescrierii cererilor trebuie urmai anumii pai:

1. vizualizrile materializate ce vor fi folosite la rescriere trebuie s fie
definite cu opiunea ENABLE QUERY REWRITE;
2. parametrul de iniializare QUERY_REWRITE_ENABLED trebuie s fie
setat la valoarea TRUE;
3. parametrul de iniializare OPTIMIZER_MODE trebuie s aib una dintre
valorile ALL_ROWS, FIRST_ROWS sau CHOOSE.
4. parametrul de iniializare OPTIMIZER_FEATURES_ENABLE trebuie s
nu fie setat (s nu i se dea nici o valoare); dac totui parametrul are setat
o valoare, atunci aceasta trebuie s fie cel puin 8.1.6.
5. utilizatorul s dein privilegiul sistem QUERY REWRITE sau GLOBAL
QUERY REWRITE;
6. cererea s nu utilizeze hint-ul NOREWRITE;
7. depinde de nivelul de integritate al cererii care este dat de parametrul
QUERY_REWRITE_INTEGRITY.
Parametrul QUERY_REWRITE_INTEGRITY
Acest parametru determin gradul de integritate pentru care sistemul
Oracle aplic rescrierea cererilor. Implicit acesta are valoarea ENFORCED.
QUERY_REWRITE_INTEGRITY = {stale_tolerated | trusted

| enforced}
Valoarea parametrului poate fi setat la nivel de sesiune sau sistem
(ALTER SESSION, ALTER SYSTEM).
Valoarea ENFORCED presupune c sistemul Oracle aplic i garanteaz
consistena i integritatea. Optimizorul va folosi doar vizualizrile
materializate care conin date actualizate (fresh) i va folosi doar acele
relaii care sunt bazate pe constrngeri active i valide de cheie primar,
unicitate, cheie extern.

Valoarea TRUSTED presupune c sistemul Oracle permite rescrierea

cererilor care utilizeaz relaii ce au fost declarate, dar care nu au fost
aplicate. Optimizorul are ncrederea c datele vizualizrilor materializate
sunt actualizate i c relaiile declarate n dimensiuni i constrngerile de
tip RELY sunt corecte. n acest mod, optimizorul va folosi vizualizri
materializate prebuilt sau vizualizri materializate bazate pe alte
vizualizri. De asemenea, va folosi att relaiile validate ct i pe cele
nevalidate. n acest mod, optimizorul are ncredere n constrngerile de
cheie primar, unicitate i relaiile specificate prin dimensiuni, declarate
fr clauza ENABLED VALIDATED.
Valoarea STALE_TOLERATED presupune c sistemul Oracle permite
rescrierea folosind relaii nevalidate. Optimizorul folosete att
vizualizrile materializate care sunt valide, dar care conin date
neactualizate (stale), ct i vizualizrile cu date actualizate (fresh). Acest
mod ofer capacitatea maxim de rescriere a cererilor, dar determin
riscul generrii de rezultate incorecte.
Dac nivelul de integritate al rescrierii este cel mai sigur ENFORCED
atunci optimizorul va aplica constrngerile de cheie primar i pe cele
refereniale pentru a asigura c rezultatele cererii sunt aceleai cu rezultatele
obinute n cazul n care cererea ar accesa direct tabelele de baz.
Dac nivelul de integritate al rescrierii este altul dect ENFORCED,
atunci apar cteva situaii n care rezultatul obinut prin rescriere poate fi diferit
de cel obinut dac s-ar utiliza tabelele de baz.
1. O vizualizare materializat poate s nu fie sincronizat cu datele tabelelor
de baz. Aceasta se poate ntmpla atunci cnd procedura de actualizare a
vizualizrii este n ateptare dup o ncrcare masiv cu date sau dup
operaiile LMD asupra unuia sau mai multor tabele de baz ale vizualizrii
respective. Aceeai situaie este ntlnit dac vizualizarea este actualizat
la anumite intervale de timp.
2. Relaiile implementate prin dimensiuni ale obiectelor pot fi invalide. De
exemplu, valorile unui anumit nivel ierarhic nu au exact un printe.
3. Valorile stocate n tabelul prebuilt care determin vizualizarea
materializat pot fi incorecte.
4. Operaiile asupra partiiilor (DROP i MOVE PARTITION) tabelelor de
baz pot afecta rezultatele vizualizrii materializate.
Parametrul OPTIMIZER_MODE
Acest parametru stabilete modul implicit pentru alegerea unei abordri de
optimizare. Valoarea implicit a parametrului este choose.
OPTIMIZER_MODE =
{first_rows_[1 | 10 | 100 | 1000]
| first_rows | all_rows | choose | rule}

Hint-uri pentru rescrierea cererilor

Hint-ul NOREWRITE ntr-o cerere previne ca optimizorul s rescrie
cererea.
Exemplu:
SELECT /*+ NOREWRITE */
p.categorie_4 AS domeniu, t.luna AS luna,
Hint-ul REWRITE fr nici un argument foreaz optimizorul s
foloseasc o vizualizare materializat pentru a rescrie cererea, fr a ine cont de
costuri.
Hint-ul REWRITE(mv1,mv2,...) selecteaz cele mai potrivite vizualizri
materializate pentru a rescrie cererea.
Exemplu:
SELECT /*+ REWRITE(vm1_sum_domeniu_luna) */
p.categorie_4 AS domeniu, t.luna AS luna,
Dac cererea const din mai multe blocuri SELECT, atunci se pot
specifica hint-uri pentru fiecare bloc SELECT.
Privilegii pentru a putea activa rescrierea cererilor
Privilegiul sistem QUERY REWRITE permite utilizarea pentru rescrierea
cererilor a vizualizrilor materializate din schema proprie care refer tabele din
acea schem.
Privilegiul sistem GLOBAL QUERY REWRITE permite utilizarea
vizualizrilor materializate pentru rescrierea cererilor, chiar dac aceasta refer
tabele din alte scheme.
9.3. Metode de rescriere a cererilor
9.3.1. Metode de rescriere prin comparare la nivel de text SQL

Optimizorul poate folosi dou astfel de metode:
comparare complet;
comparare parial.
Dac este utilizat metoda de comparare complet, atunci este comparat

textul ntreg al comenzii cu definiia vizualizrii materializate (ntreaga expresie
SELECT), ignorndu-se spaiile.
Exemplu:
r.oras AS oras,
SUM(cantitate * pret_unitar_vanzare) AS valoare,
COUNT(cantitate* pret_unitar_vanzare) AS numar
Aceast cerere se potrivete complet cu definiia vizualizrii materializate

vm3_sum_domeniu_luna_oras i va fi rescris astfel:
SELECT domeniu, luna, oras, valoare, numar

FROM vm3_sum_domeniu_luna_oras;
Dac operaia de comparare complet se ncheie cu o euare, atunci

optimizorul ncearc compararea parial. n acesta metod, se compar textul
care apare n clauzele FROM.
Exemplu:
r.oras AS oras,
AVG(cantitate * pret_unitar_vanzare) AS medie
Cererea de mai sus este rescris astfel:
SELECT domeniu, luna, oras, valoare/numar AS medie

FROM vm3_sum_domeniu_luna_oras;
Dac nici compararea parial nu se ncheie cu succes, atunci optimizorul

va ncerca alte metode de rescriere.
De remarcat este faptul c optimizorul realizeaz o comparare case-
sensitive (de exemplu, un cuvnt cheie precum FROM trebuie scris la fel n
cerere ct i n definiia vizualizrii).

9.3.2. Metode generale pentru rescrierea cererilor
Pentru a determina dac o cerere poate fi rescris, sistemul Oracle

realizeaz mai multe tipuri de verificri:
compatibilitatea seleciei;
compatibilitatea join-ului;
suficiena datelor;
compatibilitatea gruprilor;
compatibilitatea agregrilor.
Metodele generale de rescriere a cererilor ce pot fi utilizate

Metode de verificare VM doar VM cu join-uri VM cu agregate
a rescrierii cu join-uri i agregte pe un singur tabel
Compatibilitatea
X X X
seleciei
Compatibilitatea
X X -
join-ului
Suficiena datelor X X X
Compatibilitatea
- X X
gruprilor
Compatibilitatea
- X X
agregrilor
Dimensiuni i constrngeri necesare pentru rescrierea cererilor
Metode de verificare Constrngeri de cheie

Dimensiuni
a rescrierii primar, cheie extern i Not Null
Compatibilitatea
nu sunt necesare nu sunt necesare
seleciei
Compatibilitatea
nu sunt necesare necesare
join-ului
Suficiena datelor necesare necesare
Compatibilitatea
necesare necesare
gruprilor
Compatibilitatea
nu sunt necesare nu sunt necesare
agregrilor

Constrngeri definite pe vizualizri

Constrngerile definite pe vizualizri trebuie create cu opiunea DISABLE
NOVALIDATE. Pentru a permite rescrierea cererilor complexe, starea unei
constrngeri definit pe o vizualizare poate fi RELY sau NORELY. De exemplu,
o constrngere pe o vizualizare care este n starea RELY permite rescrierea
cererii atunci cnd nivelul de integritate al cererii este TRUSTED.
Stare Constrngere /
RELY NORELY
Mod integritate rescriere
ENFORCED Nu Nu
TRUSTED Da Nu
STALE_TOLERATED Da Nu
Pentru a demonstra capacitatea de rescriere a cererilor pe vizualizri,

trebuie extins schema cu urmtoarea vizualizare:
CREATE VIEW v_timp AS

SELECT id_timp,
TO_NUMBER(TO_CHAR(id_timp,'ddd'))AS zi_in_an
FROM dim_timp;
Acum se poate stabili o relaie referenial n modul RELY, ntre

vizualizare i tabelul de fapte. Rescrierea va merge pentru acest exemplu n
modul TRUSTED.
ALTER VIEW v_timp

ADD CONSTRAINT pk_v_timp PRIMARY KEY (id_timp)
DISABLE NOVALIDATE;
ALTER VIEW timp_view
MODIFY CONSTRAINT timp_view_pk RELY;
ALTER TABLE vanzari
ADD CONSTRAINT timp_view_fk FOREIGN key (id_timp)
REFERENCES timp_view(timp_id)
DISABLE NOVALIDATE);
ALTER TABLE vanzari
MODIFY CONSTRAINT timp_view_fk RELY;
CREATE MATERIALIZED VIEW vanzari_pcat_cal_zi_mv

AS
SELECT p_categorie, zi_in_an,
SUM(svaloare_sold) as sum_valoare_sold
FROM timp_view, vanzari, produse

WHERE id_timp = timp_id AND prod_id = id_prod

GROUP BY p_categorie, zi_in_an;
Urmtoarea cerere, care nu utilizeaz tabelul produse, va fi rescris fr

relaia referenial, deoarece join-ul suprimat dintre tabelul de fapte vanzari i
tabelul dimensiune produse nu este necesar.
SELECT zi_in_an,
SUM(valoare_sold) AS sum_valoare_sold
FROM timp_view, vanzari
WHERE timp_id = id_timp
GROUP BY zi_n_an;
Totui, dac vizualizarea materializat vanzari_pcat_cal_zi_mv a fost

definit numai asupra vizualizrii timp_view, atunci nu se poate rescrie
urmtoarea cerere:
SELECT p_categorie,
FROM vanzari, produse
WHERE prod_id = id_prod
GROUP BY p_categorie;
Potrivirea expresiei
O expresie ce apare n cerere poate fi nlocuit cu o coloan simpl din
vizualizarea materializat, care reprezint acea expresie precalculat. Dac
cererea poate fi rescris cu expresia precalculat, atunci cererea se va executa
mai rapid.
Exemplu:
Se consider vizualizarea materializat vm2_sum_prod_luna_client i
urmtoarea cerere SQL:
SELECT p.denumire, t.luna, v.client_id,

SUM(cantitate* pret_unitar_vanzare)
GROUP BY p.denumire, t.luna, v.client_id;
Cererea va fi rescris astfel:

SELECT produs, luna, client, valoare
FROM vm2_sum_prod_luna_client;

Formatul datei calendaristice

Reprezint o form specific a metodei de rescriere prin potrivirea
expresiei. n acest tip de rescriere data calendaristic din cerere este inclus ntr-
o dat calendaristic echivalent, avnd gradul de granularitate mai mare. Data
care o cuprinde reprezint o granul mai mare ca de exemplu luni, trimestre sau
ani.
Potrivirea expresiei se realizeaz prin folosirea formelor canonice pentru
datele calendaristice.
Tipul DATE este un tip de date care reprezint uniti ordonate de timp ca
secunde, zile, luni i incorporeaz o ierarhie precum secund minut or
zi lun trimestru an. De exemplu, data 01-01-2010 poate fi inclus n
anul 2010 sau n primul trimestru al anului 2010, adic 2010-1 sau n prima lun
a anului 2010, adic 2010-01.
Deoarece valorile datelor calendaristice sunt ordonate, un predicat
specificat pe o coloan de tip DATE poate fi inclus ntr-un nivel mai mare de
granularitate. De exemplu, predicatul date_col BETWEEN '01-01-2010' AND
'01-07-2010' poate fi inclus n granula lun sau granula trimestru, folosind
funcia TO_CHAR.
Exemplu:
Se consider urmtoarea vizualizare materializat:
CREATE MATERIALIZED VIEW vm_categorii_lunare
AS
SELECT categorie_5 AS categorie,
TO_CHAR(timp_id,'YYYY-MM') AS luna,
SUM(cantitate* pret_unitar_vanzare) AS valoare
FROM vanzari v, dim_produse p
WHERE v.produs_id = p.id_produs
GROUP BY categorie_5, TO_CHAR(timp_id,'YYYY-MM');
Se consider cererea care listeaz valoarea vnzrilor pe categorii de
produse pentru anul 2007.
SELECT categorie_5 AS categorie,
SUM(cantitate* pret_unitar_vanzare)
FROM vanzari v, dim_produse p
WHERE v.produs_id = p.id_produs
AND TO_CHAR(v.timp_id, 'YYYY-MM') BETWEEN '2007-01'
AND '2007-12'
GROUP BY p_categorie;
SELECT categorie, valoare
FROM vm_vanzari_lunare
WHERE luna BETWEEN '2007-01' AND '2007-12';

Compatibilitatea seleciei
Sistemul Oracle permite rescrierea cererilor astfel nct s foloseasc
vizualizri materializate n care clauza HAVING sau WHERE conine o selecie
a unei submulimi de date dintr-un tabel.
Compatibilitatea seleciei poate fi:
simpl selecii de genul <expresie> operator_relational <constanta>;
complex selecii de genul <expresie> operator_relational <expresie>;
de tip range selecii de genul <expresie> BETWEEN <const1> AND
<const2>;
de tip in list selecii de genul lista_coloane IN lista_valori; de remarcat
este faptul c seleciile de forma coloana1='v1' OR coloana1='v2' OR
coloana1='v3' OR .... sunt tot de tipul list;
de tip IS [NOT] NULL;
de tip [NOT] LIKE.
Atunci cnd se compar selecia din cerere cu cea din vizualizarea

materializat se verific dac partea stng a celor dou selecii coincide. Dac
se folosete un interval de valori, atunci se compar partea dreapt, ca n
exemplul urmtor.
Exemplul 1:
n cerere:
WHERE prod_id = 102
n vizualizare:
WHERE prod_id BETWEEN 0 AND 200
Exemplul 2:
n cerere:
WHERE prod_id > 10 AND prod_id < 50
n vizualizare:
WHERE prod_id BETWEEN 0 AND 200
Exemplul 3:
n cerere:
WHERE vanzari.valoare_sold * .07 BETWEEN
1 AND 100
n vizualizare:
WHERE vanzari.valoare_sold *. 07 BETWEEN
0 AND 200
Exemplul 4:

n cerere:
WHERE cost.unit_pret * 0.95 >
cost_unit_cost * 1.25
n vizualizare:
WHERE cost.unit_pret * 0.95 >
cost_unit_cost * 1.25
Exemplul 5:
Seleciile din cerere nu sunt constrnse de nici o selecie din vizualizare,
dar valorile din dreapta trebuie coninute de vizualizare. Cererea urmtoare va fi
rescris.
n cerere:
WHERE p_nume = 'pantaloni'
AND p_categorie = 'barbati'
n vizualizare:
WHERE p_categorie = 'barbati'
Exemplul 6:
Vizualizarea este mai restrictiv dect cererea. Cererea urmtoare nu va fi
rescris.
n cerere:
WHERE p_categorie = 'barbati'
n vizualizare:
WHERE p_nume = 'pantaloni'
AND p_categorie = 'barbati'
Exemplul 7:
n cerere:
WHERE prod_id, client_id IN
((1022, 1000), (1033, 2000))
n vizualizare:
WHERE prod_id IN (1022,1033)
AND client_id IN (1000, 2000)
Exemplul 8:
n cerere:
WHERE prod_id = 1022
n vizualizare:
WHERE (prod_id, client_id) IN
(1022, 1000), (1022, 2000))

Exemplul 9:
Rescrierea eueaz.
n cerere:
WHERE prod_id = 1022
n vizualizare:
WHERE (prod_id, client_id, c_oras)
IN ((1022, 1000, 'Bucuresti'),
(1022, 2000, 'Iasi'))
Compatibilitatea seleciilor se poate realiza i pentru selecii complexe de

genul
(selecie AND selecie AND ...) OR (selecie AND selecie AND ...)
Fiecare grup de selecii relaionate prin operatorul AND este n disjuncie

cu un alt grup. De fapt se obine o disjuncie de conjuncii.
Exemplul 10:
Cererea va fi rescris:
n cerere:
WHERE populatie_oras > 15000
AND populatie_oras < 25000
AND judet= 'Vrancea'
n vizualizare:
WHERE (populatie_oras < 5000
AND judet = 'Bucuresti')
OR (populatie_oras BETWEEN 10000 AND
50000
AND judet = ' Vrancea ')
Exemplul 11:
CREATE MATERIALIZED VIEW cal_luna_vanzari_id_mv
BUILD IMMEDIATE
REFRESH FORCE
AS
SELECT calendar_luna_desc,
SUM(valoare_sold) AS suma
FROM vanzari,timp
WHERE timp_id = id_timp AND id_client = 10
GROUP BY calendar_luna_desc;

Cererea urmtoare poate fi rescris deoarece ntoarce date despre clientul

10.
SELECT calendar_luna_desc,
FROM vanzari,timp
WHERE timp_id = id_timp AND id_client = 10
GROUP BY calendar_luna_desc;
SELECT calendar_luna_desc, suma

FROM cal_luna_vanzari_id_mv;
Exemplul 12:
CREATE MATERIALIZED VIEW produs_vanzari_mv
BUILD IMMEDIATE
REFRESH FORCE
AS
SELECT p_nume,
FROM produse, vanzari
GROUP BY p_nume
HAVING SUM(valoare_sold) BETWEEN 5000 AND
50000;
Se d urmtoarea cerere:
SELECT p_nume, SUM(valoare_sold) AS suma

FROM produse, vanzari
GROUP BY p_nume
HAVING SUM(valoare_sold) BETWEEN 10000 AND 20000;
SELECT p_nume, suma

FROM produs_vanzari_mv
WHERE suma > 10000 AND suma < 20000;
Exemplul 13:
CREATE MATERIALIZED VIEW

vanzari_valentines_day_99_mv
BUILD IMMEDIATE
REFRESH FORCE
AS
SELECT prod_id, id_client, valoare_sold
FROM vanzari,timp
AND timp_id=TO_DATE('14-FEB-1999','DD-MON-
YYYY');
SELECT prod_id, id_client, valoare_sold

FROM vanzari,timp
AND timp_id=TO_DATE('14-FEB-1999', 'DD-MON-
YYYY');
SELECT * FROM vanzari_valentines_day_99_mv;
Exemplul 14:
CREATE MATERIALIZED VIEW promo_vanzari_mv
BUILD IMMEDIATE
REFRESH FORCE
AS
SELECT promo_nume,
FROM promotii, vanzari
WHERE promo_id = id_promo
AND promo_nume IN
('cupon', 'premium', 'fluturas')
GROUP BY promo_name;
SELECT promo_nume, SUM(valoare_sold)

AND promo_nume IN ('cupon', 'premium')
SELECT *
FROM promo_vanzari_mv
WHERE promo_nume IN ('coupon', 'premium');
Cererea urmtoare va i ea rescris ca mai jos:
SELECT promo_nume, SUM(valoare_sold)

AND promo_nume = 'cupon'
HAVING SUM(valoare_sold) > 1000;
SELECT *
FROM promo_vanzari_mv
WHERE promo_nume = 'cupon'
AND sum_valoare_sold > 1000;
Compatibilitatea join-ului
Join-urile din cerere sunt comparate cu join-urile din definiia vizualizrii
materializate. n general, aceast comparare poate fi clasificat n trei categorii:
1. join-uri comune, care apar att n cerere ct i n vizualizare;
2. join-uri delta, care apar n cerere, dar nu i n vizualizare (cereri delta
join);
3. join-uri delta, care apar n vizualizare, dar nu i n cerere (vizualizri
delta join).
Join-uri comune
Exemplul 1:
SELECT p_nume, zi_sf_saptamana, SUM(valoare_sold)
FROM vanzari, produse, timp
WHERE timp_id=id-timp AND prod_id = id_prod
AND zi_sf_saptamana BETWEEN
TO_DATE('01-AUG-1999', 'DD-MON-YYYY')
AND TO_DATE('10-AUG-1999', 'DD-MON-YYYY')
GROUP BY p_nume, zi_sf_saptamana;
Join-urile comune ntre aceast cerere i vizualizarea materializat

join_vanzari_timp_produs_mv sunt timp_id=id_timp i prod_id = id_prod.
Join-urile se potrivesc i cererea poate fi rescris astfel:
SELECT p_nume, zi_sf_saptamana, SUM(valoare_sold)

FROM join_vanzari_timp_produs_mv
WHERE zi_sf_saptamana BETWEEN
TO_DATE('01-AUG-1999','DD-MON-YYYY')
AND TO_DATE('10-AUG-1999','DD-MON-YYYY')
De asemenea, cererea poate fi procesat i utiliznd vizualizarea

join_vanzari_timp_produs_oj_mv unde join-urile din cerere pot fi obinute din
outerjoin-urile din vizualizare:
SELECT p_nume, zi_sf_sapatamana, SUM(valoare_sold)

FROM join_vanzari_timp_produs_oj_mv
TO_DATE('01-AUG-1999','DD-MON-YYYY')
AND TO_DATE('10-AUG-1999','DD-MON-YYYY')
AND prod_id IS NOT NULL
Exemplul 2:
SELECT DISTINCT p_nume
FROM produse p
WHERE EXISTS
(SELECT *
FROM vanzari s
WHERE p.prod_id=s.id_prod
AND s.valoare_sold > 1000);
Aceast cerere poate fi interpretat i astfel:
SELECT DISTINCT p_nume

FROM produse p
WHERE p.prod_id IN (SELECT s.id_prod
FROM vanzari s
WHERE s.valoare_sold > 1000);
Aceast cerere conine un semijoin ntre tabelul produse i tabelul

vanzari:
s.id_prod = p.prod_id.
Cererea poate fi rescris astfel:
SELECT p_nume
FROM (SELECT DISTINCT p_nume

WHERE valoare_sold > 1000);
Dac vizualizarea materializat join_vanzari_timp_produs_mv este

partiionat dup timp_id, atunci aceast cerere va fi mai eficient dect cererea
original, deoarece join-ul original dintre tabelul vanzari i tabelul produse
poate fi evitat.
SELECT p_nume
FROM (SELECT DISTINCT p_nume
WHERE valoare_sold > 1000
AND prod_id IS NOT NULL);
Cereri delta join
Exemplul 3:
SELECT p_nume, zi_sf_saptamana, c_oras,
SUM(valoare_sold)
FROM vanzari,clienti,timp,produse
WHERE timp_id=id_timp
AND prod_id=id_prod
AND client_id = id_client
GROUP BY p_nume, zi_sf_saptamana, c_oras;
Folosind vizualizarea join_vanzari_timp_produs_mv join-urile comune

sunt timp_id=id_timp i prod_id=id_prod. Join-ul delta este client_id =
id_client.
SELECT mv.p_nume, mv.zi_sf_saptamana, c.c_oras,

SUM(mv.valoare_sold)
FROM join_vanzari_timp_produs_mv mv, clienti c
WHERE mv.id_client = c.client_id
GROUP BY mv.p_nume, mv.zi_sf_saptamana, c.c_oras;
Vizualizri materializate delta join

Pentru ca o cerere s poat fi rescris printr-o vizualizare materializat
care conine join-uri suplimentare, acele join-uri nu trebuie s determine
pierderea de nregistrri (nregistrri care nu ndeplinesc condiia de join).
Pentru aceasta coloanele care intr n join trebuie s aib declarate
constrngerile FOREIGN KEY, PRIMARY KEY i NOT NULL.
Exemplul 4:
SELECT zi_sf_saptamana, SUM(valoare_sold)
FROM vanzari,timp
WHERE timp_id =id_timp

AND zi_sf_saptamana BETWEEN
GROUP BY zi_sf_saptamana;
Vizualizarea join_vanzari_timp_produs_mv are un join adiional

prod_id=id_prod ntre tabelul vanzari i tabelul produse. Cererea poate fi
rescris dac s.id_prod este cheie extern i p.prod_id este not null.

Cererea poate fi rescris i utiliznd vizualizarea materializat

join_vanzari_timp_produs_oj_mv. Aceast vizualizare conine un outerjoin ntre
tabelul vanzari i tabelul produse (s.id_prod=p.prod_id(+)). Dac p.prod_id
este cheie primar, atunci cererea poate fi rescris astfel:

Suficiena datelor
n cazul acestei verificri, optimizorul determin dac toate coloanele de
date necesare cererii pot fi obinute din vizualizarea materializat. Pentru aceasta
se utilizeaz echivalena coloanelor.
De exemplu, dac avem un inner join ntre tabelele A i B cu predicatul de
join A.X = B.X, atunci datele din coloana A.X vor fi egale cu datele din coloana
B.X n rezultatul join-ului. Aceast proprietate a datelor este utilizat pentru a
verifica potrivirea coloanei A.X din cerere cu coloana B.X din vizualizare.
Exemplul 1:
SELECT p_nume, timp.timp_id, zi_sf_saptamana,
SUM(valoare_sold)
WHERE timp_id=id_timp AND prod_id = id_prod
GROUP BY p_nume, timp_id, zi_sf_saptamana;
Aceast cerere poate fi rescris folosind vizualizarea materializat

join_vanzari_timp_produs_mv, dei n vizualizare nu apare coloana
timp.timp_id. Deoarece timp.timp_id=vanzari.id_timp optimizorul va rescrie

cererea.
SELECT p_nume, id_timp, zi_sf_saptamana,

SUM(valoare_sold)
GROUP BY p_nume, id_timp, zi_sf_saptamana;
Dac o anumit coloan nu se poate obine direct din vizualizare, atunci

optimizorul ncerca s determine dac poate obine coloana pe baza
dependentelor funcionale (valorile unei coloane determin valorile altei
coloane). De exemplu, codul unui produs determin funcional numele
produsului.
Exemplul 2:
SELECT p_categorie, zi_sf_saptamana,
SUM(valoare_sold)
AND p_categorie='barbati'
GROUP BY p_categorie, zi_sf_saptamana;
Vizualizarea materializat sum_vanzari_pcat_sapt_mv conine p.prod_id,

dar nu i p.p_categorie. Totui se poate realiza un join ntre vizualizare i tabelul
produse pentru a obine categoria produsului, deoarece coloana prod_id
determin n mod funcional coloana p_categorie. Cererea va fi rescris astfel:
SELECT p_categorie, mv.zi_sf_saptamana,

SUM(mv.sum_valoare_sold)
FROM sum_vanzari_prod_sapt_mv mv, produse p
WHERE mv.prod_id=p.prod_id
AND p.prod_category='barbati'
GROUP BY p_categorie, mv.zi_sf_saptamana;
Dependenele funcionale se pot declara n dou moduri:

utilizarea constrngerii de cheie primar;
utilizarea clauzei DETERMINES a unei dimensiuni.
Clauza DETERMINES din definiia unei dimensiuni poate fi uneori
singura modalitate de a determina dependena funcional atunci cnd coloana
care determin alt coloan nu poate fi cheie primar. De exemplu, tabelul
produse este un tabel dimensiune denormalizat care are coloanele prod_id,
p_nume, p_subcategorie i p_categorie. Atributul p_subcategorie determin
funcional p_subcat_desc, iar p_categorie determin funcional p_categ_desc.
Att p_subcateg ct i p_categ nu pot fi chei primare n acest tabel.

Exemplul 3:
CREATE DIMENSION produse_dim
LEVEL produs IS (produse.prod_id)
LEVEL subcategorie IS (produse.p_subcategorie)
LEVEL categorie IS (produse.p_categorie)
HIERARCHY prod_rollup (
produs CHILD OF
subcategorie CHILD OF
categorie)
ATTRIBUTE produs DETERMINES produse.prod_nume
ATTRIBUTE produs DETERMINES produse.prod_desc
ATTRIBUTE subcategorie
DETERMINES produse.p_subcateg_desc
ATTRIBUTE categorie
DETERMINES produse.p_categ_desc;
Se d cererea urmtoare:
SELECT p_subcateg_desc, zi_sf_saptamana,

SUM(valoare)
AND p_subcateg_desc LIKE '%barbati'
GROUP BY p_subcateg_desc, zi_sf_saptamana;
Aceast cerere va fi rescris astfel:
SELECT iv.p_subcateg_desc, mv.zi_sf_saptamana,

FROM sum_vanzari_pcat_sapt_mv mv,
(SELECT DISTINCT p_subcategorie,
p_subcateg_desc
FROM produse) iv
WHERE mv.p_subcategorie=iv.p_subcategorie
AND iv.p_subcateg_desc LIKE '%barbati'
GROUP BY iv.p_subcateg_desc, mv.zi_sf_saptamana;
Compararea gruprilor
Aceast verificare este necesar dac att cererea ct i vizualizarea conin
clauza GROUP BY. Iniial optimizorul determin dac gruparea datelor cerute
de cerere este identic cu cea folosit n vizualizare. De exemplu, o cerere
folosete o grupare dup p_subcategorie i o vizualizare materializat stocheaz
datele grupate dup p_subcateg i p_subcateg_desc. Gruparea este aceeai n
ambele cazuri determinnd gruparea dup atributul p_subcategorie care
determin funcional atributul p_subcateg_desc.
Vizualizarea sum_vanzari_pcat_sapt_mv grupeaz datele dup zi_sf_sapt
i p_subcategorie. Urmatoarea cerere grupeaz datele dup p_subcategorie.

Exemplul 1:
SELECT p_subcategorie,
SUM(valoare_sold) AS sum_valoare
WHERE prod_id=id_prod
GROUP BY p.p_subcategorie;
De aceea, optimizorul va rescrie cererea astfel:
SELECT p_subcategorie, SUM(sum_valoare_sold)

FROM sum_vanzari_pcat_saptamana_mv
GROUP BY p_subcategorie;
Exemplul 2:
SELECT p_categorie, zi_sf_saptamana,
SUM(valoare_sold) AS sum_valoare
FROM vanzari,produse,timp
WHERE timp_id=id_timp AND prod_id=id_prod
GROUP BY p_categorie,zi_sf_saptamana;
Deoarece p_subcategorie determin funcional p_categorie, vizualizarea

sum_vanzari_pcat_ saptamana_mv poate fi folosit pentru rescriere.
SELECT pv.p_subcategorie, mv.zi_sf_saptamana,

FROM sum_vanzari_pcat_saptamana_mv mv,
(SELECT DISTINCT p_subcategorie,
p_categorie
FROM produse) pv
WHERE mv.p_subcategorie=mv.p_subcategorie
GROUP BY pv.p_subcategorie, mv.zi_sf_saptamana;
Compararea agregatelor
Aceast verificare este necesar doar dac att cererea, ct i vizualizarea
conin agregate. De exemplu, dac cererea returneaz AVG(X), iar vizualizarea
conine SUM(X) i COUNT(X), atunci cererea poate fi rescris cu
SUM(X)/COUNT(X).
Dac verificarea compatibilitii gruprilor determin c vizualizarea
stocheaz agregate de tip rollup, atunci se ncerc determinarea fiecrui agregat
cerut de cerere prin utilizarea agregatelor de nivele inferioare ale vizualizrii
materializate. De exemplu, SUM(vanzari) la nivel de jude se poate obine prin
nsumarea valorilor SUM(vanzari) la nivel de ora care au aceeai valoare pentru
jude.

Exemplu:
SELECT p_subcategorie, AVG(valoare) AS avg_vanzari

GROUP BY p_subcategorie;
Optimizorul va rescrie cererea astfel:
SELECT mv.p_subcategorie,
SUM(mv.sum_valoare_sold)/SUM(mv.count_valoare_sold)
AS avg_vanzari
FROM sum_vanzari_pcat_luna_oras_mv mv
GROUP BY mv.p_subcategorie;
Argumentul unei funcii agregat precum SUM poate fi o expresie

aritmetic precum A+B. Optimizorul verific dac agregatul SUM(A+B) care
apare n cerere se potrivete cu un agregat de tipul SUM(A+B) sau SUM(B+A)
n vizualizare.
Pentru a realiza verificrile, sistemul Oracle convertete expresiile
argument din funcia agregat n aceeai form canonic. De exemplu, A*(B-C),
A*B-C*A, (B-C)*A i -A*C+A*B pot fi convertite toate n aceeai form
canonic.

Curs Modul 3 - DW - Capitole 8-9 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curs Modul 3 - DW - Capitole 8-9 PDF

Titlu original:

Încărcat de

Drepturi de autor:

Formate disponibile

Baze de Date Depozit

Baze de Date Depozit 39

8. Vizualizri materializate ............................................................................. 41

9. Rescrierea cererilor ...................................................................................... 49

9.3.2. Metode generale pentru rescrierea cererilor .......................................... 56

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

O vizualizare materializat, cunoscut n versiunile anterioare sub numele

Avantajele utilizrii vizualizrilor materializate

Restricii pentru cererile care definesc o vizualizare materializat

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

Metode de populare cu date

Procedura DBMS_MVIEW.EXPLAIN_MVIEW indic dac o vizualizare

CREATE MATERIALIZED VIEW LOG ON nume_tabel

Clauza WITH este utilizat pentru a indica dac n fiierul log se

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

b. Fiierul log menine valorile cheii primare i rowid-urile nregistrrilor.

c. Fiierul log-ul determin actualizarea de tip fast a vizualizrilor materializate

Comanda CREATE MATERIALIZED VIEW

[{proprieti_vm | ON PREBUILT TABLE

aprea parametrul PCTFREE. Pentru a suprima crearea indexului implicit, se

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

Opiunea AS specific cererea care definete vizualizarea materializat.

Modificarea vizualizrilor materializate

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

Suprimarea vizualizrilor materializate

Exemple de intervale la care se realizeaz actualizarea

Informaii despre vizualizrile materializate

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

Optimizorul recunoate n mod automat atunci cnd o vizualizare

9.1. Concepte generale

nainte ca cererea s fie rescris trebuie realizate cteva verificri pentru a

Rescrierea sau nu a cererilor este influenat de anumii factori:

Exemple de vizualizri materializate utilizate la rescrierea cererilor

CREATE MATERIALIZED VIEW vm2_sum_prod_luna_client

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

CREATE MATERIALIZED VIEW vm3_sum_domeniu_luna_oras

b) Vizualizrile materializate care conin doar join-uri.

CREATE MATERIALIZED VIEW vm4_produs_trimestru

CREATE MATERIALIZED VIEW vm5_produs_trimestru_outer

Pentru a permite optimizorului s determine dac poate utiliza rescrierea

9.2. Activarea rescrierii cererilor

Pentru activarea rescrierii cererilor trebuie urmai anumii pai:

QUERY_REWRITE_INTEGRITY = {stale_tolerated | trusted

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

Valoarea TRUSTED presupune c sistemul Oracle permite rescrierea

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

Hint-uri pentru rescrierea cererilor

9.3. Metode de rescriere a cererilor

9.3.1. Metode de rescriere prin comparare la nivel de text SQL

Dac este utilizat metoda de comparare complet, atunci este comparat

Aceast cerere se potrivete complet cu definiia vizualizrii materializate

SELECT domeniu, luna, oras, valoare, numar

Dac operaia de comparare complet se ncheie cu o euare, atunci

Cererea de mai sus este rescris astfel:

SELECT domeniu, luna, oras, valoare/numar AS medie

Dac nici compararea parial nu se ncheie cu succes, atunci optimizorul

Copyright 2007-2015 Lect. Dr. Gabriela Mihai. Toate drepturile rezervate.

9.3.2. Metode generale pentru rescrierea cererilor

Pentru a determina dac o cerere poate fi rescris, sistemul Oracle

Metodele generale de rescriere a cererilor ce pot fi utilizate

Dimensiuni i constrngeri necesare pentru rescrierea cererilor

Metode de verificare Constrngeri de cheie