Datu bāzes projektēšana (DSP410)

Lekciju materiāls sagatavots projekta“RTU studiju programmas “Datorsistēmas” pilnveidošana absolventu profesionālās konkurētspējas paaugstināšanai “ ietvaros

©RTU, 2007

Datu bāzes projektēšana Datu bāzes projektēšana (DSP410)(DSP410)

2“RTU studiju programmas “Datorsistēmas” pilnveidošana absolventu profesionālās konkurētspējas paaugstināšanai “2006/0238/VPD1/ESF/PIAA/06/APK/3.2.3.2/0015/0007

J. Eiduks. Datu bāzes projektēšana

Asoc. profesors, Dr.sc.ing. Jānis Eiduks

Rīgas Tehniskā universitāteDatorzinātnes un informācijas tehnoloģijas fakultāteLietišķo datorsistēmu institūtsSistēmu teorijas un projektēšanas katedra

Datu bāzes projektēšanaDatu bāzes projektēšana



Priekšmeta pamatdatiPriekšmeta pamatdati

• Priekšmeta pieteicējs: Jānis Eiduks• Apjoms: 4 KP• Kontroles veids: Eksāmens• Studiju līmenis: Maģistra profesionālās

studijas• Semestris: 3



Priekšmeta mērķi un uzdevumiPriekšmeta mērķi un uzdevumi



PamatlitetratūraPamatlitetratūra



PapildliteratūraPapildliteratūra



Atslēgas vārdiAtslēgas vārdi



PamattēmasPamattēmas



Datu bāzes projektēšanaDatu bāzes projektēšana

1. Priekšmetiskās vides analīze.2. Datu konceptuālā modeļa izvēle (ER diagrammas, UML

diagrammas un t.t.).3. Datu konceptūālā modeļa izstrāde.4. Datu bāzes sistēmas tipa izvēle (relāciju, relāciju-objektu,

objektu).5. Datu konceptuālā modeļa transformēšana datu bāzes loģiskajā

modelī.6. Datu bāzes loģiskā modeļa pilnveidošana.7. Konkrētas datu bāzes vadības sistēmas izvēle (Oracle, MS SQL

Server, Sybase, Informix un t.t.).8. Datu bāzes fiziskā modeļa izstrāde un tā realizēšana.9. SQL vaicājumu noskaņošana.10.Datu sākotnējās ielādes projekta izstrāde un realizēšana.

CASE rīks

DBVS

“Data stage” tipa rīks



Informācijas sistēmas un datu bāzes Informācijas sistēmas un datu bāzes sistēmassistēmas

Universālās datu bāzes sistēmas

Informācijas sistēmas (IS)

Izpildvaras vai administratora IS Stratēģiskais līmenisVecāko vadītāju līmenis

Lēmumu pieņemšanas atbalsta IS Stratēģiskais līmenisVidējo vadītāju līmenis

Vadības IS Vadības un pārvaldes līmenisDarbu vadītāju līmenis

Biroja darbības automatizācijas IS Vadības un pārvaldes līmenisKancelejas darbības līmenis Transakciju apstrādes IS Darbību izpildes līmenisDarbinieki

Datu bāzes sistēmas

Relāciju datu bāzes sistēmas

Relāciju-objektu datu bāzes sistēmas

Objektu datu bāzes sistēmas

Universālo datu bāzes sistēmu paplašinājumi:

- temporālais papl.;- telpiskais papl.;- daudzdimensiju papl..

?



Datu bāzes trīs līmeņu projektēšanas Datu bāzes trīs līmeņu projektēšanas shēmashēma

Informācijas sistēmas pasūtītājsDatu bāzes projektētājs Datu bāzes projektētājsDatu bāzes sistēmas administrators Datu bāzes sistēmas administratorsSistēmas administrators

Datu bāzes konceptuālais modelis

Datu bāzes loģiskais modelis

Datu bāzes fiziskais modelis



Datu bāzes sistēmas projektēšanas Datu bāzes sistēmas projektēšanas metodesmetodes

1. Datubāzes sistēmas projektēšana balstoties uz ieejas un izejas datiem.

Ieejas dati Izejas dati

Sākuma dati

2. Diagrammu tehnoloģijas (CASE tehnoloģija) izmantošana.

3. Diagrammu tehnoloģijas un jēdzienu pakārtotības modeļu izmantošana.

Sistēma

ER diagrammas

UML diagrammas

ER diagrammas

UML diagrammas

Semantiskais tīkls, freimi

+



Datu plūsmas diagrammaDatu plūsmas diagramma

1.Datu plūsmas diagramma ir priekšmetiskās vides modelis. Tā modelē projektējamās sistēmas funkcionalitāti. Tiek izdalītas atsevišķas funkcijas, noskaidrota to savstarpējās saistība un noteikti funkciju ieejas un izejas dati. Funkcijas raksturo datu pārveidojumus.

2. Datu plūsmas diagrammā tiek norādītas arī datu krātuves (īslaicīgas vai ilglaicīgas).

3. Datu plūsmas diagramma sniedz pilnīgu pārskatu par projektējamās sistēmas funkcionalitāti un datiem.

4. Datu plūsmas diagrammā tiek izmantoti sekojoši elementi:a) ārējā realitāte;b) funkcija, kas pārvērš ieejas datus izejas datos;c) datu krātuve, kurā tiek glabāti dati un no kuras tiek izgūti dati;d) datu plūsma. Tā veidojas starp funkcijām, starp funkciju un datu krātuvi, starp ārējo

realitāti un funkciju.

Ārējā realitāte Funkcija

Datu plūsma P1

Datu krātuveDatu krātuve



Datu plūsmas diagrammu Datu plūsmas diagrammu hierarhijahierarhija

Konteksta līmeņa diagramma

Sākuma līmeņa diagramma

Izlietne

Sistēma

Avots

D6

D1D11

Avots F1 K1K1 F3

F5 F6 F2

F4

D1 D2 D3 D4

D5

D6

D7

D8D9

D10

D11

D31

Izlietne



Datu plūsmas diagrammu Datu plūsmas diagrammu hierarhija (turpinājums)hierarhija (turpinājums)

Otrā līmeņa diagramma

Sākuma līmeņa diagramma

F3.3K3K3F3.1

F3.2

D3

D4

D15

D16

D17

D18

D31

D181

Avots F1 K1K1 F3

F5 F6 F2

F4

D1 D2 D3 D4

D5

D6

D7

D8D9

D10

D11

D31

Izlietne



Viesnīcas informācijas sistēmaViesnīcas informācijas sistēma D1 D1 D1 V1 A1 D1 A1 A1 A2, D3 D3 D2 D3 VID D3 VID A2 VID, A2, D2

Numuru apzīmējumi, tipi un stāvi,

papildīpašības, statuss un

datumi, viesu identifikatori

Viesa atbildes un personas

datu saņemšana

Viesis Viesa vēlmju

saņemšana

Vēlmju datu ievade

Vaicājuma V1

noformēšana

Atbildes noformēšana un nodošana

viesim Viesa personas

datu ievade

Rezervēšanas raksta

izveidošana un ierakstīšana

Viesu personas dati un

identifikatori (VID)

Vēlmju dati aktīvajam viesim



Datu struktūras modeļiDatu struktūras modeļi

Tiek izmantoti dažādi datu struktūras modeļi:1. realitāšu – saišu diagramma (Entity

Relationship Diagram – ERD);2. atslēgu datu modelis (Key Based Model –

KBM) – realitātes un to primārās atslēgas;3. pilnais atribūtu modelis (Fully Attributed

Model –FAM) – realitātes, atribūti, saites.4. UML diagrammas.



ER (Entity-Relationship) modelisER (Entity-Relationship) modelis

1. ER (Entity-Relationship) modelis ir datu konceptuālais modelis ko 1976. gadā izstrādāja P. Čens (Chen), lai atvieglotu datu bāzes projektēšanu.

2. ER diagrammas pamatelementi ir:a) realitātes tipi (entity type);

b) atribūti;

c) saites tipi.

3. Realitātes tips ir priekšmetiskās vides noteikta objektu, subjektu vai procesu klase.4. Realitāte ir realitātes tipa eksemplārs (entity instance, entity occurance). Tipam

parasti ir daudz eksemplāru.5. Realitātes tipus var sadalīt:

a) patstāvīgos realitātes tipos (parent, owner, dominant);

b) pakārtotos realitātes tipos (child, dependent, subordinate).

1.realitātes tipa 3. eksemplārs

1. realitātes tips (entity

type)





Realitātes atribūti un atslēgasRealitātes atribūti un atslēgas

1. Realitātei ir īpašības. Šīs īpašības raksturo atribūti.2. Atribūta domēns ir atribūta potenciālo vērtību kopa.3. Vienkāršs atribūts sastāv no vienas neatkarīgas komponentes.4. Salikts atribūts sastāv no vairākām neatkarīgām komponentēm.5. Vienvērtīgs atribūts ir atribūts, kas vienai realitātei satur vienu vērtību.6. Daudzvērtīgs atribūts vienai realitātei var saturēt vairākas vērtības.7. Atvasināta atribūta vērtība tiek iegūta no cita vai citu atribūtu vērtībām (ne

tikai dotās realitātes atribūtiem).8. Potenciālā atslēga viennozīmīgi definē realitātes tipa eksemplārus.9. Primārā atslēga ir potenciālā atslēga, kura izvēlēta par realitātes tipa

galveno atslēgu.10. Alternatīvā atslēga ir potenciālā atslēga, kas nav primārā atslēga.11. Salikta atslēga ir potenciāla atslēga, kura sastāv no vairākiem atribūtiem.

1. realitāte

1. atribūts

2. atribūts

3. atribūts



Realitāšu saitesRealitāšu saites

1. Realitāšu tipu savstarpējās saites, ir izpratnes asociācijas starp dažādiem realitāšu tipiem (var būt saites arī vienam tipam, pašam ar sevi).

2. Var runāt arī par realitāšu eksemplāru savstarpējām saitēm (relationship instance, relationship occurrence) 1. realitātes Saites 2. realitātes

Atribūti eksemplārs eksemplārs eksemplārs Atribūti

1. realitāte 2. realitāteSaite



Realitāšu saišu veidiRealitāšu saišu veidi

1. Saite var būt realitātes tipam pašam ar sevi (unārā saite jeb rekursīva saite) , starp divām realitātē (binārā saite), starp trijām (ternārā saite) realitātēm u.t.t.

2. Realitāšu tipu skaitu, kurus ietver saite, sauc par saites pakāpi.3. Ja starp realitātēm ir vairākas saites, tad realitātēm var tikt

norādīti lomu nosaukumi, kādu lomu realitāte spēlē katrā saitē.

1. realitāte

Unārā saite

1. realitāte 2. realitāte

3. realitāte

Ternārā saite



Saišu atribūtiSaišu atribūti

1. Atribūti var būt arī saitēm. Tātad katram saites eksemplāram var būt savas atribūtu vērtības.

2. Jaunākās ER diagrammas notācijās atribūti saitēm nevar būt. Tas būtiski vājina ER diagrammas izteiksmību.


1. tribūts

2. atribūts



Saišu kardinalitāteSaišu kardinalitāte

1. Saišu kardinalitāte norāda ar cik citas realitātes eksemplāriem var būt sasaistīts realitātes eksemplārs.

2. Tipiskās saites ir:a) viens ar vienu (1 : 1);b) viens ar daudziem (1 : N);c) daudzi ar daudziem ( N : M).

1 N1. realitāte 2. realitāteSaite

1. realitātes eksemplārs









Realitātes piedalīšanās pakāpe Realitātes piedalīšanās pakāpe saitē ar citu realitātisaitē ar citu realitāti

1. Ir divas piedalīšanās pakāpes: pilnā (total) un daļējā (partial).2. Realitātei ir pilnā piedalīšanās pakāpe saitē, ja viņas

eksemplāra eksistencei ir obligāti nepieciešama citas realitātes eksemplāra eksistence.

3. Realitātei ir daļējā piedalīšanās pakāpe saitē, ja viņas eksemplāra eksistencei nav obligāti nepiečiešama citas realitātes eksemplāra eksistēnce.

4. Pilno piedalīšanās pakāpi saitē bieži vien sauc par obligāto piedalīšanos (mandatory).

5. Nepilno piedalīšanās pakāpi saitē sauc arī par neobligāto piedalīšanos (optional).

(0, 1) (1, N)

Neobligātā piedalīšanās saitē Obligātā piedalīšanās saitē




Pārrāvuma slazds ER diagrammāsPārrāvuma slazds ER diagrammās

Pārravuma slazds var veidoties ER diagrammās, ja starp realitāšu tipiem eksistē saistība, bet tieši ar saiti realitāšu eksemplāri nav saistīti.

1 1 N N

? Pārrāvuma slazds N 1 1 N

1. realitāte

2. realitāte

Saite_1_2 Saite_1_3

3. realitāte

3. realitāte

1. realitāte

Saite_1_3 Saite_3_2

2. realitāte



Identificējošās saitesIdentificējošās saites

1. Tiek lietotas neatkarīgas realitātes un arī atkarīgas jeb vājās realitātes.

2. Identificējošā saite realizējas starp neatkarīgo (“vēcāku” tipa) realitāti un atkarīgo (“bērna” tipa) realitāti.

3. Atkarīgās jeb vājās realitātes tiek attēlotas kā dubulttaisnstūris.

4. Norādot identificējošu saiti, neatkarīgās realitātes primārās atslēgas atribūti tiks iekļauti arī vājās realitātes primārajā atslēgā. Notiks it kā atribūtu migrācija. Vājajā realitātē iekļautie atribūti kļūs par ārējām atslēgām (foreign key –FK).

Vājā saite Vājā realitāte

Realitāte Students

Realitāte Atzīme

Saite

Identifikators



Realitāšu atkarību veidiRealitāšu atkarību veidi1. Ir vairāki atkarīgo realitāšu tipi:

a) neatkarīgo realitāti raksturojošā jeb īpašību pakārtotā realitāte. Tā ir saistīta tikai ar vienu galveno realitāti, glabājot datu par tās eksemplāru īpašībām.b) asociatīvā pakārtotā realitāte, kura ir saistīta ar vairākām neatkarīgām realitātēm. Tā raksturo šo neatkarīgo realitāšu saistību.c) saistošā pakārtotā realitāte, kura norāda neatkarīgo realitāšu saiti daudzi ar daudziem gadījumā. Realitātei nav savu atribūtu, tikai neatkarīgo primārās atslēgas.d) kategorijas pakārtotā realitāte. Tā ir “bērna” tipa realitāte realitāšu hierarhijā.

2. Realitāšu hierarhijas var būt:a) pilnas kategorijas hierarhijas;

b) nepilnas kategorijas hierarhijas.

Darbinieks

NumursUzvārdsVārdsAlgaAmats

Vīrietis

1.atribūts2.atribūts

Sieviete


Darbinieks

NumursUzvārdsVārdsAlgaAmats

Analītiķis


Projektētājs3.atribūts4.atribūts



EER (Enhanced ER) datu EER (Enhanced ER) datu konceptuālais modeliskonceptuālais modelis

1. ER modeliim ir daudz ierobežojumu. Lai varētu pilnvērtīgāk veidot datu bāzes datu konceptuālo modeli tika izveidots ER modeļa paplašinājums – Paplašinātais ER modelis (EER).

2. ER modelis tika paplašināts ar superklases un apakšklases jēdzieniem. 3. Superklases realitāte ir patstāvīga realitāte, kas ietver sevī apakšklases realitātes.4. Apaksklases realitātes ir patstāvīgas realitātes, kuras superklasē veido vienotu loģisko

apvienojumu.5. Superklases un apakšklases realitāšu attiecības var modelēt arī atribūtu mantošanu

(specialization, generalization).

Realitāšu apvienojums vienā veselā Superklases realitāti papildina

apakšklases realitāte

Superrealitāte Ģimene

Realitāte Sieva

Realitāte Vīrs

Superrealitāte Dzinējs

Realitāte Dzinēja 1.

bloks

Realitāte Dzinēja 2.

bloks



EER (Enhanced ER) datu konceptuālais modelis EER (Enhanced ER) datu konceptuālais modelis (turpinājums)(turpinājums)

6. Viena apakšklase var būt saistīta ar divām superklasēm. Apakšklasi šajā gadījumā sauc par kategoriju (category). Apskatīto realitāšu konstrukciju sauc par kategorizēšanu.

Kopēja pakārtotā realitāte

Superrealitāte Kravas automašina

Superrealitāte Kravas automašina

Realitāte Dzinējs



ER modeļa elementu pārveidojumiER modeļa elementu pārveidojumi

Parēja no ER diagrammas uz tabulu sākotnējo struktūru notiek, ievērojot pārveidojumu vai transformāciju likumus:

1) ER modeļa realitāte pārvēršas par tabulu;2) ER modeļa realitātes atribūts pārvēršas par tabulas lauku;3) ER modeļa realitāšu saite var pārvērsties par attiecīgo tabulu

saiti, bet ja saitei ir atribūti, tad izveidotie arī jauna tabula.

Realitāte Tabula

Atribūts Lauks



Pārveidojumu likumiPārveidojumu likumi

No ER diagrammas tiek iegūtas datu tabulu sākotnējie varianti. Šo pārveidojumu veikšanai tiek izmantoti speciāli transformēšanas likumi:

1) likums 1 1

= Viena datu tabula

2) likums 1 1

= Divas datu tabulas

3) likums 1 1

= Trīs datu tabulas

4) likums 1 N

= Divas datu tabulas

5) likums 1 N


6) likums N M



1. realitāte

2. realitāte







Datu funkcionālā atkarībaDatu funkcionālā atkarība

1. Funkcionālo atkarību starp mainīgiem lielumiem var definēt gan analītisku izteiksmju veidā, gan tabulu veidā.

2. Funkcionālo atkarību var konstatēt ne tikai starp skaitļiem. Funkcionāla atkarība var eksistēt starp jebkuras formas datiem: skaitļiem, datumiem, tekstveida datiem un t.t.

a) b) c)

Y = f (X) = 1 + X X - arguments; Y - funkcija Determinants Determinants

Firmas nosaukums

Tālruņa numurs

ABC 7222222 A un B 7222223 Spars 7222224

X Y 1 2 2 3 3 4

Uzvārds Vārds Tālruņa numurs

Koks Liene 7444444 Celms Zane 7444445 Koks Varis 7444446 Sakne Juris 7444447

Firmas nosaukums

Tālruņa numurs Uzvārds

Vārds

Tālruņa numurs



Datu funkcionālā atkarība Datu funkcionālā atkarība (turpinājums)(turpinājums)

3. Lielums Y ir funkcionāli atkarīgs no lieluma X, tad un tikai tad, ja katra lieluma X vērtība ir saistīta tikai ar vienu Y vērtību.

4. Lielums Y ir funkcionāli pilni atkarīgs no lieluma X, ja tas ir funkcionāli atkarīgs no X, bet nav funkcionāli atkarīgs no tā (X) daļas. Šajā gadījumā lielums X sastāv no vairākiem pakārtotiem lielumiem.

5. Determinants ir tabulas lauks X vai lauku kopa { X } no kura (-as) lauks Y ir funkcionāli pilni atkarīgs.

a) b)

6. Datu funkcionālās atkarības. a) - funkcionāli pilna atkarība, b) - ne funkcionāli pilna atkarība.

Viesa numurs

Pakalpojuma numurs

Pakalpojuma maksa

Viesa numurs

Uzvārds

Viesnīcas numura numurs



Tabulas lauku funkcionālās Tabulas lauku funkcionālās atkarības diagrammaatkarības diagramma

Katrai tabulai var uzzīmēt funkcionālo atkarību shēmu, kurā parādīti tabulas lauki (ailes) un to savstarpējās atkarības.

Viesa numurs

Uzvārds

Vārds Adrese Tālruņa numurs



Daudzkriterialitāte tabulas Daudzkriterialitāte tabulas kvalitātes noteikšanākvalitātes noteikšanā

Tabulas kvalitātes noteikšanai tiek izmantoti dažādi kritēriji. Tie raksturo tabulu no tās satura viedokļa (vai tabulā ir dati par vienu vai vairākiem informācijas objektiem), no izpildāmo darbību vienkāršības un iespēju viedokļa (vai ir iespējams vienmēr ierakstīt jaunu informāciju, vai viegli veikt datu modifikāciju u.t.t.), no vaicājumu realizēšanas ātrdarbības viedokļa (vai vaicājumu izpildes laiki ir pieļaujami). Veidojas daudzkriteriālās optimizācijas uzdevums:

Q1(X) opt X1* X- datu bāzes struktūra X Q2(X) opt X2* X** X QN(X) opt XN* X Q1(X) Optimums pēc pirmā kritērija Pareto kopa (X**) X1 Optimums pēc otrā kritērija X2 X1 > X2 Q2(X)



Normālformu kritērijiNormālformu kritēriji1. Tabula T apmierina pirmās normālformas prasības, tad un tikai tad, ja visi domēni satur tikai

atomāras (nedalāmas) vērtības.

Primārā atslēga

2. Tabula T apmierina otrās normālformas prasības, ja tā apmierina pirmās normālformas prasības un katrs ne primārās atslēgas lauks funkcionāli pilni ir atkarīgs no primārās atslēgas.

Primārā atslēga

3. Tabula T apmierina trešās normālformas prasības, ja tā apmierina otrās normālformas prasības un katrs ne primārās atslēgas lauks netranzitīvi ir atkarīgs no primārās atslēgas.

Piegādātāja numurs

Piegādes numurs

Piegādes daudzums

Pilsēta

Piegādātāja statuss


Piegādātāja statuss

Pilsēta


Piegādes numurs

Piegādes daudzums


Pilsēta(primārā atslēga)

Pilsēta Piegādātāja statuss



Boisa-Kodda normālformaBoisa-Kodda normālforma

Tabula T apmierina trešās normālformas prasības, ja katrs determinants ir iespējamā primārā atslēga. šo definējumu ieveda Boiss un Kodds, tāpēc to sauc par Boisa - Kodda normālformu.

Tabula AlgasNumurs Uzvārds Vārds Alga

NUM UZV VAR ALGA

1 Koks Zane 150.00

2 Celms Juris 160.00

3 Zars Inese 140.00

3.normālformas pārbaude

Iespējamās atslēgas

Determinanti

NUM NUM

UZV + VAR UZV + VAR



Funkcionālo atkarību pārveidojumu Funkcionālo atkarību pārveidojumu noteikuminoteikumi

Katrai tabulai starp datu ailēm (laukiem) eksistē noteiktas funkcionālas atkarības. No vienām funkcionālām atkarībām var iegūt (izsecināt) citas. Lai to realizētu izmanto funkcionālo attiecību pārveidošanas likumi vai noteikumi.Ja un ,tad 2. noteikums (papildinājums). Ja un ,tad 3.noteikums (tranzitivitāte). Ja un ,tad 4. noteikums (izplešanās). Ja ,tad 5. noteikums (izplešanās turpinājums). Ja , tad 6. noteikums (pseidotranzitivitāte). Ja un ,tad

X

Y

U

U

Y X X Y

X U

Y U

Z U

X Y X,U,Z

Y,U,Z

X Y Y Z X Z

X Y X,U,Z

Y

X Y Y,W Z X,W Z

X Y X,U,

Z Y,U,

Z



Funkcionālo attiecību Funkcionālo attiecību pārveidojumu likumi (turpinājums)pārveidojumu likumi (turpinājums)

7. noteikums (apvienojums)Ja X Y , tad X Y, Z X Z

8. noteikums (dekompozīcija)Ja X Y , Z , tad X Y X Z

Pārveidojumu piemērs

A B D

K C a)


A B D

K C b)


A B D

K C c)



Ceturtā normālforma un datu Ceturtā normālforma un datu daudzvērtību atkarībasdaudzvērtību atkarības

Tabula Mācības Daudzvērtību atkarības: Mācību kurss Pasniedzējs Mācību kurss Mācību grāmata

Tabulas Mācības_1 projekcijas

Mācību kurss Pasniedzējs Mācību grāmata Sistēmas analīze Koks Analīze 1 Zars Analīze 2 Projektēšana Koks Projektēšana 1 Projektēšana 2 Projektēšana 3

Mācību kurss Mācību grāmata Sistēmas analīze Analīze 1 Sistēmas analīze Analīze 2 Projektēšana Projektēšana 1 Projektēšana Projektēšana 2 Projektēšana Projektēšana 3

Mācību kurss Pasniedzējs Sistēmas analīze Zars Sistēmas analīze Koks Projektēšana Koks

1. Attieksmei (tabulai) R ir atribūti (lauki) A, B, C. Atribūts (lauks) B ir daudzvērtīgi atkarīgs no atribūta A, ja B vērtību kopa, kura atbilst atribūtu (lauku) A un C vērtību kopām, ir atkarīga tikai no A, bet ne no C.

2. Tabula apmierina 4.normālformas prasības, ja tā apmierina Boisa-Kodda normālformas prasības un visas daudzvērtību saites ir funkcionālas saites no iespējamās primāras atslēgas.



Piektā normālformaPiektā normālformaDažos gadījumos nevar veikt tabulu sadalīšanu (dekompozīciju) 2 daļās, bet gan 3 vai vairākās

daļās (n-dekompozīciju attieksme).

Tabula Piegādātājs_detaļa_projekts Projekcijas

Savienojums no divām pirmajām projekcijām

Piegādātājs Detaļa Projekts Pieg_1 Det_1 Proj_2 Pieg_1 Det_2 Proj_1 Pieg_2 Det_1 Proj_1 Pieg_1 Det_1 Proj_1

Piegādātājs Detaļa Pieg_1 Det_1 Pieg_1 Det_2 Pieg_2 Det_1

Detaļa Projekts Det_1 Proj_2 Det_2 Proj_1 Det_1 Proj_1

Projekts Piegādātājs Proj_2 Pieg_1 Proj_1 Pieg_1 Proj_1 Pieg_2

Piegādātājs Detaļa Projekts Pieg_1 Det_1 Proj_2 Pieg_1 Det_2 Proj_1 Pieg_2 Det_1 Proj_1 Pieg_2 Det_1 Proj_2 Pieg_1 Det_1 Proj_1

Lieks raksts



Piektā normālforma (turpinājums)Piektā normālforma (turpinājums)

Tabula apmierina 5. normālformas (projekciju apvienošanas) prasības tikai tad, kad katra apvienošanas projekcija satur tabulas iespējamo primāro atslēgu.

Tabulas R sadalīšana vairākās projekcijās

R(Pieg_num, Pieg_nos, Statuss, Pils)

R1(Pieg_num, Pieg_nos, Statuss) R2(Pieg_num, Pils)

R(Pieg_num, Pieg_nos, Statuss, Pils)

R1(Pieg_num, Pieg_nos) R2(Pieg_num, Statuss) R3(Pieg_nos, Pils)



Relāciju-objektu datu bāzes Relāciju-objektu datu bāzes sistēmassistēmas

1. Relāciju-objektu datu bāzes vadības sistēmas (RODBS) papildina relāciju datu bāzes iespējas un ļauj izmantot objektus.

2. Lielo (sarežģīto) objektu datu tipu atbalsts:a) binārie lielie objekti – BLOB (BYNARY LARGE OBJECT);b) simbolu lielie objekti - CLOB ( CHARACTER LARGE OBJECT);c) nacionālo simbolu lielie objekti - NCLOB (NATIONAL CHARACTER LARGE OBJECT).

3. Paplašināto datu tipu (Extended Data Type, EDB) atbalsts:RODBS produkti paplašina savas tipizēšanas sistēmas, ieviešot lietotāju-definēta tipa (User Defined Type, EDF), abstraktu datu tipa (Abstract Data Type, ADP) un objektu tipa atbalstu.

4. Kolekciju datu tipu (ieliktas tabulas, masīvi) atbalsts:Daudzas RODBS atceļ pirmās normālformas ierobežojumus, atļaujot izmantot ieliktas tabulas un masīvus, kā atsevišķas kolonas vērtību.

5. Objektu identifikatora jēdziena ieviešana:Daudzas RODBS ievieš objektu identitātes (OID) jēdzienu. OID ļauj unikāli identificēt noteikta tipa objektu, kā arī savienot tabulas, kuras glabā šos objektus, izmantojot atsauces uz OID vērtībām.



RODBS trūkumiRODBS trūkumi

1. RODBS ievieš jauninājumus tipizēšanas sistēmā, līdz ar to prasa ieviest izmaiņas arī SQL valodā. Taču eksistējošais SQL standarts (respektīvi, tehnoloģiskās iespējas) neatļauj to izdarīt vienkārši. Katrs izstrādātājs ievieš savu, atšķirīgu no citiem risinājumu. Līdz ar to pagaidām nav vienošanās starp RODBS izstrādātiem par vairākiem būtiskiem jautājumiem.

2. RODBS produkti ievieš daudz jaunu, nestandartizētu pieeju darbam ar RO datu bāzēm. Daudzie no jauninājumiem neatbilst topošam SQL3 standartam. Līdz ar to tiek ievērojami apgrūtināta līdzekļu izvēle RODBS realizācijai.

3. Funkcionālo iespēju daudzveidība padara grūtu vienotas pieejas izvēli, kas ļautu transformēt konceptuālo UML diagrammu datus ORDBS shēmā.



UML (The Unified Modeling UML (The Unified Modeling Language) modelēšanas valodaLanguage) modelēšanas valoda

1. UML ir vizuāla modelēšanas valoda, kas paredzēta informācijas sistēmu funkcionalitātes un datu struktūru modelēšanai.

2. UML modeļi palīdz labāk, vienkāršāk, uzskatamāk uztvert un analizēt projektējamās sistēmas uzbūvi un darbību.

3. UML ļauj modelēt gan informācijas sistēmas statisko struktūru, gan sistēmas uzvedības dinamiku.

4. UML nav programmēšanas valoda. Programmas kodu var iegūt no UML diagrammām lietojot speciālas programmu paketes. No programmas koda var iegūt UML diagrammu.

5. UML ir diskrēta modelēšanas valoda. Tā nav paredzēta analogu, nepārtrauktu sistēmu projektēšanai.



UML valodas diagrammasUML valodas diagrammas

Struktūras modelēšanas diagrammas

Dinamikas modelēšanas diagrammas

Klases diagrammas

Izmantojuma diagrammas

Komponentu diagrammas

Izvērsuma diagrammas

Stāvokļu diagrammas

Darbību diagrammas

Secību jeb virkņu diagrammas

Kooperācijas diagrammas



UML diagrammas elementiUML diagrammas elementi

Elements Funkcija Notācija Aktieris Sistēmas lietotājs

Klase Modelējamās sistēmas koncepcija

Klase noteiktā stāvoklī

Klase, kas var atrasties tikai vienā stāvoklī

Klasifikatora loma

Klasifikators, kas noteiktā veidā tiek izmantots kooperācijā

Komponents Sistēmas daļa

Datu tips Primitīvo vērtību grupas deskriptors Character, Date, …

Interfeiss Nosaukta operāciju kopa, kas raksturo noteiktu uzvedību

Int_nosaukums

Mezgls Skaitļošanas (aprēķinu) mezgls

Signāls Asinhronie paziņojumi starp objektiem

Apakšsistēma Sistēmas bloks, kuram ir sava individualitāte interpretācijā un realizācijā

Lietojuma variants

Sistēmas uzvedības specifikācija

Nosaukums

Nosaukums [S]

Role: Nosaukums

“signāls”

“Apakšsistēma”



UML klašu diagrammaUML klašu diagramma

Atribūti

Metodes

Asociācija 1 īpašnieks Lomu nosaukumi

* īpašums

Klase - Lietotājs uzvārds: string telefons: string Pievienot(uzvārds,telefons)

Klase - Lietojums nosaukums: string datums: date Reģistrēt(nosaukums,datums)



RODBVS datu tipiRODBVS datu tipi1. Galvenā RODBS priekšrocība ir spēja strādāt (respektīvi, glabāt, reprezentēt un apstrādāt)

ar viss dažādākiem datu veidiem. Izstrādātajām ir nepieciešams pareizi izlemt, kuru no iespējamām datu struktūrām izvēlēties, konkrētas problēmas risināšanai.

2. RDBS sistēmās izstrādātāji operē ar iebūvētiem datu tipiem, kuri tiek asociēti ar atsevišķiem tabulas laukiem (piemēram, NUMERIC, FLOAT, VARCHAR, TIMESTAMP unc.).

3. RODBS situācija ir citāda. Piemēram, SQL3 standarts definē šādus jaunus datu tipus:a) lietotāja definēts tips (User Defined Type, UDT) – tips, kurš tiek definēts ar CREATE

TYPE izteiksmi. Tipu ir iespējams izmantot atsaucēs, mantošanās attiecībās, atgriežot vērtību no lietotāja funkcijas, tipu pārveidošanas izteiksmēs un galvenais, definējot tabulas. Izšķir atsevišķu un strukturētus lietotāju tipus. Atsevišķs tips (Distinct UDT) atsaucas uz iepriekšdefinētu, iebūvētu datu tipu, turpretī strukturēts lietotāja (Structured UDT)tips ir datu struktūra, kas apvieno vairākus datu atribūtus.

b) rindas tips (Row type) – tips, kurš reprezentē datu rindas struktūru;c) atsauces tips (Reference Type) – atsauce uz lietotāja definēto tipu, tiek izmantota

atsaucoties uz datu struktūru no tabulas lauka;d) datu kolekcijas tips – daudzvērtību tips, piemēram, masīvs – vienveidīga, sakārtota

datu kopa;e) CLOB – liels datu masīvs simbolu datu glabāšanai;f) NCLOB – CLOB, kurš glabā vairāku baitu simbolus, kurus definē vienā no SQL3 simbolu

tabulām;g) BLOB – liels datu masīvs bināro datu glabāšanai;h) SQL3 iekļauj objektu orientētas funkcijas, kas ļauj realizēt datu aizsardzību

(inkapsulāciju) un mantošanu.



UML datu tipu pārveidošana par UML datu tipu pārveidošana par RODBS datu struktūrāmRODBS datu struktūrām

1. RODBS objekta jēdziens ir atdalīts no tabulas jēdziena. RODBS nemēģina pārdefinēt tabulu ar objektu tipa palīdzību. Termins objektu tips ir Oracle produktu lietotāju definēta tipa nosaukums. Vēl viens, taču vairāk teorētisks, sinonīms terminam objektu tips ir abstrakts datu tips (ADT). Nav nekādas vajadzības piešķirt dotajiem terminiem atšķirīgo teorētisko nozīmi, jo faktiski iet runa par vienu un to pašu būtību, kurai tiek piešķirti dažādo izstrādātāju izdomāti nosaukumi.

2. Datu tips definē datu semantiku, operācijas, kuras ir iespējams veikt ar dotā tipa datiem, kā arī nosāka, kādas vērtības var pieņemt dota tipa mainīgie. Objektu tipiem semantiku uzdot lietotājs.

3. UML valoda definē vienkāršus datu tipus , datu tipus, kuru mainīgiem nav identitātes, bet tikai vērtība. Vienkāršie datu tipi iekļauj primitīvus iebūvētus datu tipus (tādus, kā integer vai string), struktūras un sarakstus. Līdz ar to UML vienkārša datu tipa klasifikatoram „DataType” ir trīs apakštipi: „Primitive”, „Structure” un „Enumeration”.

4. UML diagrammas datu struktūras ar „DataType” klasifikatoriem pārveido primitīvos RODBS datu tipos.

5. Klašu un interfeisu UML klasifikatori „Class” un „Interface” atbilst RODBS strukturētiem objektu tipiem. Relāciju datubāzēs klases tiek pārveidotas tabulās, bet interfeisi glabājamās procedūrās. RODBS klases un interfeisi var tikt pārveidoti gan relāciju tabulās, gan strukturētos objektu tipos, kurus definē ar CREATE TYPE palīdzību.



UML asociācijasUML asociācijas1. UML statiskas struktūras asociācijas: 1) ģeneralizācija jeb mantošana;

Class1 Class2

Class3

2) semantiskā asociācija:

a) daudzie pret daudziem asociācija; Class4 Class5

* * b) viens pret daudziem asociācija;

Class4 Class5

1..1 * c) agregācija Class6

Class7

-End11-End2*

Class6

Class7

-End11-End2*

Kopēja agragācija (shared agragation): Class7 nepieder Class6

Kompozīcija (Composition): Class7 pieder Class6



UML asociāciju pārveidošana RODBS datu UML asociāciju pārveidošana RODBS datu struktūrāsstruktūrās

Veidot UML asociācijas RODBS ir grūti, tāpēc, ka ir pārāk daudz iespēju, kā tās realizēt:

1. ar ārējo atslēgu palīdzību, veidojot parastas saites 1:1 un 1:M starp relāciju tabulām;

2. izmantojot objektu atsauces un objektu atribūtus.

3. izmantojot objektu kolekcijas.



Objekta atribūti un to izmantošanaObjekta atribūti un to izmantošana

1. Objekta atribūts ir objekta tipa atribūts, kurš glabā strukturētu objektu nevis iebūvēto datu tipu.

2. Relāciju tabulas glabā savās kolonnas tikai primitīvas vērtības. Vērtībām nav atsevišķas identitātes ārpus dotas tabulas rindas robežām.

3. Objektiem vienmēr ir ārēja, unikāla identitāte. 4. RODBS tabula (objektu tabula) sastāv no objektiem, kur katrai tabulas rindai

atbilst unikālais objekts, kurš savukārt var iekļaut arī citus unikālus objektus. 5. Faktiski objektu atribūti veido UML kompozīcijas asociāciju, ar kardinalitāti

1..1 vai 1..0 tajā klases pusē, kura atspoguļo ielikto (jeb pakļauto) objektu.

Persona

Identifikācijasdokuments

-Identificējas ar1

-Identificē1

Galvenais objekts ar objekta atribūtu

Identifikācijas numurs

Atribūtā ieliktais objekts



Objekta atsauceObjekta atsauce1. Atsauce ir loģisks radītājs uz objektu, kurš glabājas RODBS tabulā. 2. Atsauce ir realizēta, kā objekta identifikators (OID). RODBVS ģenerē OID katram

strukturēta tipa objektam. 3. Ar OID palīdzību var atsaukties uz objektu, ieliekot OID vērtību tabulas kolonnā. Ar

atsauces palīdzību ir iespējams izgūt nepieciešamo objektu SQL vaicājumā, neizmantojot tabulu savienošanu ar ārējo atslēgu palīdzību.

4. Ar OID palīdzību ir iespējams realizēt vienkāršas asociācijas starp objektiem, un šīs asociācijas vairs nav ierobežotas ar stingriem kompozīcijas nosacījumiem. OID ļauj vienkārši realizēt viens pret daudziem semantisko asociatīvu attiecību.

5. Taču ir jāņem vēra šādu nosacījumu: ORDBVS neiekļauj mehānismus atsauces pareizības pārbaudei, līdz ar to izstrādātājam ir jārēķinās ar papildus izdevumiem aizsardzības mehānisma realizēšanai.

6. 6. Pie tam ar OID palīdzību var realizēt tikai vienā pusē virzītas semantiskās asociācijas, jo objektam, uz kuru atsaucas, nav nekādas informācijas par šo asociāciju.

Persona

Adrese

*0..1

Adreses tipa objekti atsaucas uz objektiem Persona

Var arī otrādi: Persona objekti atsaucas uz Adreses tipa objektiem



Kolekciju izmantošanaKolekciju izmantošana1. Kolekcija ir atribūts, kurš satur vairākas viena tipa vērtības (masīvs, kopa vai tabula). 2. SQL3 standarts paredz tikai vienu kolekcijas tipu masīvu ARRAY. 3. DBVS Oracle realizē masīvu VARYING ARRAY un ieliktās tabulas. 4. Informix piedāvā kolekcijas – sarakstus: SET,MULTISET un LIST. Kolekcijas mērķis ir

apvienot objektu kopu vienā kolonnā. 5. Ar kolekcijas palīdzību ir iespējams realizēt viens pret daudziem vai daudzi pret daudziem

semantiskās asociācijas, viens pret daudziem kopējas agregācijas vai kompozīcijas.6. Apskatīsim asociāciju starp klasēm Persona un Identifikācijas_dokuments. Katrai personai

ir virkne identifikācijas dokumentu. Šī ir kompozīcijas asociācija, līdz ar to informāciju par identifikācijas dokumentiem ir jāglabā, kā personas objekta sastāvdaļu. Realizēsim šo asociācijas ar VARYING ARRAY palīdzību. Ierobežosim identifikācijas dokumentu skaitu ar 20 gabaliem, jo masīvam ir jābūt ar iepriekšdefinētu garumu. Līdz ar to mēs izveidojam 1 pret 20 kompozīciju starp klasēm Persona un Identifikācijas_dokuments.

CREATE TYPE Identifikācijas_dokuments_tips

AS VARYING ARRAY (20) OF IDENT_MASIVS;

CREATE TYPE Persona_t AS OBJECT (

Personas_ID NUMBER,

. . . ,

ID Identifikācijas_dokuments_tips);

7. Kolekciju no atsaucēm ir ieteicams izmantot tikai tad, kad ir nepieciešams realizēt vienā pusē virzīto asociāciju un tikai optimizācijas nolūkos, jo minēta shēma ar atsaucēm neļauj automātiski (ar RODBS līdzekļiem) uzturēt datubāzes integritāti.



Objektu metožu realizēšanaObjektu metožu realizēšana

1. Relāciju datu bāzēs UML objektu metodes tiek transformētas glabājamās procedūrās un trigeros. RODBS tikai nedaudz maina šo shēmu, ieviešot dažus jaunus veidus, kā pievienot uzvedību objektiem.

2. Oracle RODBS realizē metožu pievienošanu objektu tipam.

3. SQL3 standarts ievieš virkni standartoperāciju ar objektu atribūtiem (get un set metodes), konstruktorus un tipu pārveidošanas funkcijas.

4. Ir vērts transformēt tikai tās metodes, kuras pilda servera operācijas.



Transformācijas shēmaTransformācijas shēmaRO shēmas izveidošanas process ietver divus pamat soļus: 1. ir jāizveido objektu tipi un tabulas visām UML klasēm;2. ir jāizveido papildtabulas, lai realizētu saites „daudzi ar daudziem” un trīspusējās

asociācijas.

Veicot transformāciju jārealizē sekojošas darbības:1. Jāidentificē klases, kuras var realizēt ar izmantojamās RODBS paplašinājumiem. Ja ir

specifiskas informācijas sistēmas, kurām jādarbojas ar sarežģītiem objektiem (piemērām, attēlu apstrādes sistēma vai ģeogrāfiskā informācijas sistēma), jāizvēlas attiecīgas RODBS.

2. Uzsākot transformācijas UML klases jāpārveido objektu tipos. Parasti katram objektu tipam atbilst objektu tabula, kas glabā objektu rindas. Ir iespējams, ka vienam objektam atbilst vairākas objektu tabulas.

3. Veidojot objektu tabulu ir jāpieņem arī lēmums par to, kā tabulas objekti tiks identificēti: ar OID palīdzību, vai izmantojot tabulas primāro atslēgu. OID objektam tiek veidots vienmēr. Primāra atslēga papildus ļauj saistīt tabulas un specificēt saišu integritātes nosacījumus (CACADE DELETE nosacījums un tml.). Primāras atslēgas izveidošanai ir jāpievieno objektam papildus atribūtu un pēc tam objektu tabulas atbilstošai kolonnai ir jāpievieno PRIMARY KEY nosacījumu.

4. Jāpārveido visus pārējus UML datu tipus. Par objektu tipu UML tips kļūst tikai, ja šim tipam ir atribūti, citādi tips pārtop par kādu no iebūvētiem primitīviem datu tipiem. Šajā posmā izstrādātajam ir jābūt uz rokām transformācijas tabulai, kura definētu, kā pārveidot UML primitīvus datu tipus ROBS iebūvētos tipos.



Transformācijas shēma (1. Transformācijas shēma (1. turpinājums)turpinājums)

5. Objektu tipam ir jāpievieno atribūtus:a) UML atribūts UML klasē pārtop par atribūtu objektu tipā;b) UML atribūta tips kļūst vai nu par atribūta objektu tipu vai iebūvēto primitīvo tipu,

atbilstoši iepriekšminētiem noteikumiem.c) ja UML atribūtam ir piekārtots marķieris {nullable}, tad, definējot objektu tabulu,

atbilstošajam atribūtam (kolonnai) ir jāpiekārto NULL ierobežojumu, citādi jāpiekārto NOT NULL ierobežojumu;

d) ja UML atribūts ir inicializēts, definējot objektu tabulu, atbilstošam atribūtam (kolonnai) ir jāpiekārto vērtību pēc noklusēšanas, izmantojot DEFAULT izteiksmi;

e) ja ir nepieciešams, jāpievieno CHECK ierobežojumus.

6. Tur kur ir nepieciešams jārealizē mantošanu starp klasēm:a) UML klasēm, kurām nav ģeneralizācijas (saknes vai neatkarīgā klase), ir jāizveido primāro

atslēgu (jāpievieno jauno atribūtu un jānorada atbilstošai tabulas kolonnai PRIMARY KEY nosacījumu).

b) Ja klase satur atribūtus ar marķieri {oid}, jāpievieno šos atribūtus kopējam tabulas PRIMARU KEY nosacījumam.

c) Ja dotajai klasei ir apakšklase, tad atbilstošajam objektu tipam ir jādefinē papildus atribūtu, kurš palīdzēs atšķirt konkrētu klasi. Objektu tabulas kolonnai (kolonnām, ja tiks veidotas vairākas tabulas), kas atbilst izveidotajam atribūtam ir jāpievieno CHECK nosacījumu ar dotas klases apakšklašu nosaukumu kopu.

d) apakšklasē jāpievieno katra priekšteča primāro atslēgu PRIMARY KEY un FOREIGN KEY nosacījumu kopām. Protams, ja dotā RODBS atbalsta mantošanu, var izmantot DBVS piedāvāto sintaksi mantošanas realizācijai.



Transformācijas shēma (2. Transformācijas shēma (2. turpinājums)turpinājums)

7. Ja UML klasē ir marķeris {alternate oid = <atribūta numurs>}, kas specificē alternatīvus identifikatorus dotajai klasei, tad objektu tabulas atbilstošajai kolonnai ir jāpievieno UNIQUE ierobežojumu.

8. Turpinājumā, kad ir definēti visi objektu tipi un objektu tabulas ar nepieciešamajiem ierobežojumiem un primārām atslēgām, ir jāveic asociāciju transformēšanu:

1. transformējot bināras „viens pret daudziem” asociācijas, klasei ar kardinalitāti „daudzi” ir:

a) jāpievieno atribūts, kas veidos ārējo atslēgu; b) jāpievieno atsauci uz objektu ar kardinalitāti 1.

2. transformējot kompozīcijas arī jāizšķiras starp dieviem variantiem: a) jāizveido primāro atslēgu galvenā objekta tabulai un ārējo atslēgu iekļauta objekta tabulai (FOREIGN

KEY ar CASCADE nosacījumu); b) jāizmanto objektu tipu, lai glabāt iekļautus objektus, vai nu izmantojot objektu atribūtu, vai nu

izmantojot kolekcijas (iekļautas tabulas, masīvi).

3. transformējot pārējas agregācijas, ir jāizveido primārā atslēga galvenajā objektā un ārējo atslēgu iekļautos objektos. Šajā gadījumā nav jādefinē stingrus (CASCADE) sasaistes nosacījumus. Var izmantot arī atsauces uz objektiem un kolekcijas no atsaucēm, taču šīs variants prasa papildus aizsardzības mehānismu realizāciju.

4. „daudzi pret daudziem” un trīspusējo asociāciju realizācijai nav iespējams izmantot RO shēmas līdzekļus (objektu atribūtus, kolekcijas). Šo asociāciju transformācijai ir jāizveido atsevišķas tabulas, kas satur visu saistītu klašu primāras atslēgas. Protams, var izveidot arī objektu tipu kas satur saistīto tabulu primāras atslēgas un nepieciešamus asociācijas atribūtus, un pēc tam objektu tipam veidot objektu tabulu.

9. Jātransformē klašu metodes, iegūstot vai nu objektu tipu metodes vai iebūvētas procedūras (atkarībā no RODBS).



Informācijas sistēmas izstrādes Informācijas sistēmas izstrādes grupagrupa

Analītiķis – biznesa procesu pētītājs un sistematizētājs. Veido biznesa modeļus.Lietotājs (Business User) – jaunās informācijas sistēmas potenciālais lietotājs.Datu bāzes administrators – datu bāzes realizētājs un uzturētājs.CASE rīka repozitārija administrators. Projekta datu bāzes administrators.Lietotāja grafiskā interfeisa (GUI) administrators. Informācijas sistēmas grafiskā

interfeisa standartu definētājs.Izstrādātāji:

a) projektētājs;b) programmētājs.

Testētājs.Informācijas sistēmas izstrādes vadītājs (Information System manager) - kopējā

vadība.Projekta vadītājs (Project Manager) – personāla vadība un finanses.Tehniskais projekta vadītājs (Technical Project Manager):

a) nosaka projekta standartus;b) kontrolē standartu ievērošanu;c) specifisko uzdevumu izstrāde.



Datu bāzes datu glabāšanas struktūras un Datu bāzes datu glabāšanas struktūras un lietojumu saistība lietojumu saistība

1. Izmantojot CASE tehnoloģiju, datu bāzes datu glabāšanas struktūra būtiski ietekmē lietojumu veidošanu, jo nosakot kādus datus lietojums izmantos, automātiski tiek veidota lietojuma uzbūve.

2. Lietojumu veidošanai kā pamatdiagrammu izmanto funkciju hierarhiju diagrammu.

3. Funkciju hierarhijas redaktors (Function Hierarchy Diagrammer) ļauj dokumentēt galvenās darbības (biznesa funkcijas), ko informācijas sistēmā (IS) veic lietotāji. Sarežģītākas biznesa funkcijas tiek paskaidrotas norādot kādas vienkāršākas funkcijas tajā ietilpst.Funkcijas apzīmējums

Funkcijas semantikas īss izskaidrojums

Funkcijas apzīmējumsFunkcijas semantikas īss izskaidrojums






“Augsta līmeņa” funkcijas

Atomāras funkcijas



Funkciju īpašībasFunkciju īpašības

1. Funkcijas var klasificēt sekojošā veidā:a) “augsta līmeņa” (high level) funkcijas, kurām ir pakārtotās

funkcijas;b) elementārās funkcijas, izpildās vai nu visa vai izpilde tiek anulēta.

2. Elementāras funkcijas var būt atomāras vai ar pakārtojumu (galvenās un pakārtoto funkciju kopums). Parasti tās realizē vienā programmu modulī.

3. Atomārās funkcijas netiek tālāk dalītas pakārtotās funkcijās.4. Funkcijām tiek norādīts:

a) lietojuma biežums (Frequency);b) atbildes režīms (Response): tūlītējs (Immediate), paketes režīms

(Overnight);c) ja funkciju norāda kā kopēju (Common), tā var tikt iekļauta

vairākās vietās funkciju hierarhijas kokā.5. Funkcija var tikt izpildīta realizējoties kādam notikumam. Tādu

funkciju sauc par funkciju ar trigera inicializāciju (Triggered function).



Funkciju īpašības (turpinājums)Funkciju īpašības (turpinājums)4. Funkcijas izmanto realitātes (Entity Usage). Tās var tikt:

a) radītas (Create);b) meklētas (Retrieve);c) modificētas (Update);d) dzēstas (Delete);e) arhivētas (Archive).

5. Funkcijas protams izmanto realitāšu atribūtus (Attribute Usage). Tiem var tikt realizētas:a) vērtību ierakstīšana, ievietošana (Insert);b) vērtību meklēšana (Retrieve);c) vērtību modificēšana (Update);d) vērtības “nulle” piešķiršana (Nullify);e) vērtību arhivēšana (Archive);f) citas darbības.

6. Pēc noklusēšanas funkcijas realizē dažāda tipa programmu moduļi: a) ekrāna (Screen) modulis. Modulis prasa tūlītēju (Immediate) atbildi un izmanto vismaz

vienu realitāti.b) pārskata (Report) modulis. Modulis pieļauj paketes režīmu (Overnight) un realitātes

tiek izmantotas tikai meklēšanas (Retrieve) režīmā.c) papildpakalpojumu (Utility) modulis. Modulis pieļauj paketes režīmu (Overnight) un

dažādas darbības ar realitātēm.d) rokas vadības (Manual) modulis. Nav realitāšu lietojuma.



Formas veida definēšanaFormas veida definēšana

1. Formas struktūru nosaka tabulu, atribūtu un saišu lietojums. 2. Ar bāzes tabulas datiem var tikt veiktas visas iespējamās darbības,

ar pakārtotās tabulas – tikai lasīšana (vērtības izvade).3. Var izdalīt vairākus tipiskos tabulu izmantojumus formā.

a) Galvenā – pakārtotā tabulas b) Pakārtoto tabulu ķēde

c) Galvenā – pakārtotā tabulas ar pārskata tabulu d) Tabulu matrica

Galvenā

tabula

Pakārtotā tabula

Bāzes tabula

Pārskata

tabula

Pārskata

tabula

Galvenā tabula

Pakārtotā tabula

Pārskata tabula

Pārskata tabula

Galvenā tabula

Galvenā tabula

Pakārtotā tabula



Formas struktūras saistība ar Formas struktūras saistība ar izmantojamām tabulāmizmantojamām tabulām

1.tabula Lauks_1 Lauks_2 . . .





Bāzes tabulas

Pārskata tabulas

Jauna lapa, jauns logs

Jauna lapa

Jauna “Popup”

tipa izvēlne

Saite un atsauces atslēga



Lietojumu noskaņošana - SQL Lietojumu noskaņošana - SQL vaicājumu noskaņošanavaicājumu noskaņošana

1. Projektējot informācijas sistēmu sākotnēji izstrādātājs veido SQL vaicājumus, nodrošinot tikai loģisko korektumu.

2. Vienu un to pašu SQL vaicājumu var pierakstīt daudzos dažādos veidos. SQL vaicājumu optimizators cenšas nodrošināt optimālu vaicājuma izpildes plānu, lai vaicājums izpildītos pēc iespējas ātrāk. Optimālā plāna izstrāde tomēr ir atkarīga no sākotnējā SQL vaicājuma pieraksta. Ne visos gadījumos optimizators ir spējīgs atrast labāko risinājumu.

3. Lai veiktu kvalitatīvu SQL vaicājumu izpildes noskaņošanu jāsadarbojas speciālistam ar SQL vaicājumu plānu optimizēšanas programmām.

Datu bāzes sistēma

Datu glabāšana

Datu izgūšana

1. lietojums(SQL

vaicājumi)

2. lietojums(SQL

vaicājumi)



SQL vaicājumu noskaņošanas SQL vaicājumu noskaņošanas shēma shēma

Optimizators: 1) resursu analīzes optimizators (cost-based optimizer); 2) likumu izmantošanas optimizators (rule-based optimizer).

Vaicājumu projektētājs

Vaicājumu analizētājs

SQL vaicājums

SQL vaicājumu speciālista norādes, mājieni (hints)

Optimizatora intelekts un zināšanas par datu izgūšanas metodēm (data access methods)

SQL vaicājuma izpildes plāns

Statistikas savākšana

Izpildes plāna apraksta iegūšana



SQL vaicājumu noskaņošanas SQL vaicājumu noskaņošanas darbības darbības

1. SQL optimizatora darbības režīma (optimizācijas mērķa) izvēle.ALTER SESSION SET OPTOMIZER_GOAL = CHOOSE (1.režīms)

RULE (2.režīms)

FIRST_ROWS (1.režīms)

ALL_ROWS (1.režīms)

2. Ja nepieciešams, statistikas iegūšana priekš optimizatora. ANALYZE TABLE Tab_nosauk COMPUTE STATISTICS;

ANALYZE TABLE Tab_nosauk ESTIMATE STATISTICS SAMPLE 10 PERCENT;

ANALYZE TABLE Tab_nosauk ESTIMATE STATISTICS SAMPLE 2000 ROWS;

3. Tabulas izveidošana DB, kurā ieraksta SQL vaicājumu izpildes plānus. Lai to izdarītu, parasti, serverī jāpalaiž speciāla programma. Piemēram DBVS Oracle:

$ORACLE_HOME\RDBMS8\ADMIN\utxplain.sql PLAN_TABLE

4. SQL vaicājuma izpildes plāna ierakstīšana speciālajā tabulā.EXPLAIN PLAN SET STATEMENT_ID = ‘Plans_1’ FOR SELECT …

5. Izpildes plāna izvade no speciālās tabulas. Tas tiek veikts ar komandas SELECT palīdzību.SELECT OPERATION, OPTIONS, OBJECT_NAME, ID, PARENT_ID FROM PLAN_TABLE WHERE STATEMENT_ID = ‘Anal_1’ ORDER BY ID;



Relāciju algebras darbībasRelāciju algebras darbības 1. Apvienošana R = R1 U R2 R1 R2 R 2. Starpìba R = R1 - R2 R1 R2 R 3. Dekarta reizinājums R = R1 x R2

4. Projekcija R = proj i1, i2(R1) R = proj 1, 2 (R1) 5. Selekcija (ierobežošana) R = selF(R1) R = sel (R1) I1 = a vai I2 = k

a b v d e a i k l

g d e i k l

a b v d e a i k l g d e

a b v d e a

a b v d e a i k l

g d e i k l

a b v g d e d e a g d e i k l g d e a b v i k l d e a i k l i k l i k l

a b d e i k

a b v i k l



Relāciju algebras darbības Relāciju algebras darbības (turpinājums)(turpinājums)

6. Pārklāšanās R = R1 ∩ R2 7. Dalīšana R = R1 del R2 R1 R2 R 8. Savienošana R = R1 sav R2 R1 R2 R B=D 9. Dabiskā savienošana R = R1 dab.sav. R2 R1 R2 R

i k l

i o c a o p c a c k p k i o p k

c a p k

i o

A B C a b c a i p d e z

D E a i e k

A B C D E d e z e k

A B k m

C B t m

A B C k m t



Vaicājumu analīzeVaicājumu analīze1. Datu pieeju karte (logical access map). 1 N N 1 Read (5) Write (5) Read (5), Write (5), Delete (5) 2. Transakciju - atribūtu režģis (transaction - attribute grid).

Realitāte Atribūts Transakcijas 1.trans. 2.trans. 3.trans. 4.trans. 1.realitāte A1 A2 R(3) A3 A4 R(3) 2.realitāte A5 R(10) A6 W(3) R(10) A7 R(10) A8 W(3) 3.realitāte A9 U(10) A10 U(10) A11 D(3),W(3) A12

1.realitāte 2.realitāte 3.realitāte



SQL vaicājuma izpildes etapiSQL vaicājuma izpildes etapi

Plāna izpilde

Vaicājuma optimizācija

SQL - vaicājums

Vaicājuma sintaksiskā analīze

Vaicājuma loģiskā plāna izvēle

Vaicājuma fiziskā plāna izvēle

Vaicājuma izteiksmju koks

Vaicājuma fiziskā plāna koks

Vaicājuma loģiskā plāna koks



Datu izgūšanas metožu rangiDatu izgūšanas metožu rangi

Datu izgūšanā tiek lietotas dažādas metodes. Vienas ir ātrdarbīgākas, citas lēnākas. Jā izvēlēts likumu izmantošanas optimizātora režīms, izgūšanas metodēm ir piekārtoti rangi, kurus optimizators ņem vērā.

Rangs Pieejas metode

1 Rindu identifikatora ROWID izmantošana

2 Klastera savienojuma izmantošana vienai rindai

3 Heš klastera atslēga unikālai vai primārai atslēgai

4 Unikālas vai primārās atslēgas izmantošana

5 Klastera savienojuma izmantošana daudzām rindām

6 Heš klastera atslēgas izmantošana

7 Indeksētās klastera atslēgas izmantošana

8 Jauktā jeb saliktā indeksa izmantošana

9 Indeksa vienai kolonai izmantošana

10 Atlase indeksētās kolonnās ierobežotā diapazonā

11 Atlase indeksētās kolonnās neierobežotā diapazonā

12 Savienojuma lietojot šķirošanu izmantošana

13 Max un Min operāciju izpilde indeksētām kolonnām

14 Order by operācijas izpilde indeksētām kolonnām

15 Pilnā tabulas pārskate



SQL vaicājuma izpildes plāna SQL vaicājuma izpildes plāna iegūšana un analīzeiegūšana un analīze

1. SQL vaicājums ir veidots divām tabulām un tiek lietoti operands CUBE un funkcija GROUPING.

2. Ar EXPLAIN PLAN komandu iegūstam izpildes plānu, kas tiek ierakstīts speciālā tabulā (Plan_table) DB.

3. Ar SELECT vaicājumu no Plan_table izvadām izpildes plānu.



SQL vaicājuma izpildes plāna SQL vaicājuma izpildes plāna iegūšana un analīze (turpinājums)iegūšana un analīze (turpinājums)4. Izpildes plāna darbību izpildes secība ir sekojoša:

a) (7) INDEX (UNIQUE SCAN) OF ‘P_K_UZSK_NUM’ – darbība atgriež rakstu rowid darbībai (6);

b) (6) TABLE ACCESS (BY INDEX ROWID) OF ‘PIETEIKUMS’ – darbība atgriež atbilstošos rakstus no tabulas Pieteikums darbībai (4);

c) (5) TABLE ACCESS (FULL) OF ‘IZMAKSAS' – tā atgriež visus rakstus no tabulas Izmaksas darbībai (4);

d) (4) NESTED LOOPS – šajā darbībā tiek savienoti raksti, kas iegūti no darbības (5) un darbības (6), un tālāk tiek nodoti darbībai (3);

e) (3) SORT (GROUP BY) – darbība kārto rindas grupās, jo vaicājumā ir izmantoti GROUPING parametri. Rakstus nodod darbībai (2);

f) GENERATE (CUBE) – katrā grupā tiek veidoti jauni raksti, kas satur visas iespējamās abu iepriekš ar GROUPING grupēto lauku (Klients un Izm_veids) varianti. Izveidotie raksti tiek pievienoti pārējiem rakstiem. Darbība savu rezultātu nodod darbībai (1);

g) (1) SORT (GROUP BY) – darbība kārto rindas grupās, jo vaicājumā ir izmantots GROUP BY parametrs pie CUBE un iegūst kopējās vērtības iespējamajām grupām. Rakstus nodod darbībai (0);

h) (0) SELECT STATEMENT – visi saņemtie raksti no apvienotajām tabulām tiek izvadīti.



Datu noliktavas sistēmas izstrādes Datu noliktavas sistēmas izstrādes galvenie uzdevumigalvenie uzdevumi

Veidojot datu noliktavu:1. jāizveido operatīvās datu bāzes datu loģiskais modelis (mantoto sistēmu analīze);2. jāizprojektē datu noliktavas relāciju datu bāzes struktūra (zvaigznes un sniegpārsliņu

shēmu veidošana);3. datu noliktavas daudzdimensiju datu bāzes struktūras projektēšana – dimensiju

modelēšana;4. datu izgūšanas un analīzes lietojumu izstrāde.Šo uzdevumu kvalitatīva realizēšana bez attiecīgu dator-palīgrīku (programmu) izmantošanas nav

iespējama. Tāpēc jāveido attiecīgas grupas, kuras apgūst nepieciešamo rīku teorētisko bāzi un to lietošanu.

Operatīvo datu

relāciju datu bāze

Datu attīrīšana, apkopošan

a, agregēšan

a

Datu noliktavas


Datu nolikava (MOLAP)

Datu izgūšana

un analīze

Metadatu repozitārijs

Rīks datu modeļa

veidošanai

Rīks datu nodošanai

Rīks datu modeļa

veidošanai

Rīks datu modeļa

veidošanai

Rīks lietojumu

veidošanai

Operatīvo datu


Datu noliktavas


Datu noliktava (MOLAP)



Dimensiju modelēšanaDimensiju modelēšana1. Dimensiju modelēšana (dimensional modeling) ir metode, kas tiek lietota projektējot datu

noliktavas datu struktūras. Datu noliktavas datu struktūru modelēšanai var izmantot ER. Diemžēl to efektivitāte šajā jomā ir neapmierinoša.

2. ER diagrammām ir sekojoši trūkumi:a) datu noliktavu lietotājiem ir grūti tajās orientēties un atcerēties (ļoti daudz realitāšu

un saišu);b) ER modeļu lietošana, nesaskan ar datu noliktavu darbības mērķiem (vēlama labi

saprotama struktūra, kurā viegli realizēt vajadzīgos vaicājumus).c) ER diagrammas nemodelē biznesu, bet mikro saites starp datiem. Tās nelieto biznesa

likumus, bet datu likumus. 3. Dimensiju modelēšana ir loģikas projektēšanas tehnika, kas mēģina prezentēt datus

intuitīvi labi izprotamā veidā un nodrošina ātru piekļušanu vajadzīgajiem datiem. Tiek izmantotas faktu un dimensiju tabulas.

Dimensiju tabula_1Lauks_1 Primārā atslēgaLauks_2Lauks_3

Dimensiju tabula_2Lauks_1 Primārā atslēgaLauks_2Lauks_3

Faktu tabula_ALauks_1 Atsauces atslēgaLauks_2 Atsauces atslēgaLauks_3



Dimensiju modeļu veidošanaDimensiju modeļu veidošana

Veidojot dimensiju modeļus:1. viena ER diagramma tiek sadalīta daudzās faktu tabulu

diagrammās. Tas atvieglina uztveri, jo vienlaicīgi nav jāaplūko daudz datu.

2. ER diagrammas saites daudzi ar daudziem tiek iekļautas faktu tabulās.

3. dimensiju tabulas tiek veidotas kā plakanas tabulas un ja nepieciešams tās tiek iekļautas vairākās zvaigznes shēmās. Veidojas saites starp dimensiju modeļiem.

4. tipisks datu noliktavu kopējais dimensiju modelis sastāv parasti no 10 – 25 savienotiem zvaigžņu modeļiem. Katrai faktu tabulai ir no 5 – 15 dimensijām.

5. lietošanas sākumā faktu tabulas tiek izmantotas atsevišķi, vēlāk tiek izmantotas arī kopējās dimensiju tabulas lai realizēt sasaisti.



Dimensiju modeļa priekšrocībasDimensiju modeļa priekšrocības

1. Dimensiju modelis ir labi izprotams un no tā vienkārši var iegūt nepieciešamos datus.

2. Visas dimensijas ir loģiski ekvivalentas. Līdz ar to vaicājumi ir simetriski, vienveidīgi.

3. Dimensiju modelis ir viegli paplašināms, pievienojot :a) jaunus faktus;b) jaunas dimensijas;c) jaunus dimensiju atribūtus;d) jaunu apakšdimensiju ieviešana.

4. Ir speciālas pieejas īpašu situāciju modelēšanā:a) lēnu izmaiņu dimensiju modelēšana;b) heterogēnu biznesa objektu izvērtēšana (vienlaicīgi jāievēro aršķirīgas

biznesa lietas);c) pay-in advance databases ;d) event-handling databases (darbība faktu deficītā).

5. Agregātu lietošanas iespējas (būtiskas vaicājuma izpildes ātrdarbības palielināšanas iespējas).



Dimensiju modelēšanas Dimensiju modelēšanas pamatjēdzienipamatjēdzieni

1. Dimensiju modelī svarīgi ir atšķirt faktus un atribūtus. 2. Fakts ir kaut kādi dati, kas iepriekš nav zināmi. Tie parasti ir skaitļu formā

(reāli skaitļi), bet var būt arī teksta veidā (retāk). 3. Atribūts parasti ir teksta formā un norāda reālu lietu īpašību. 4. Tekstuālie atribūti, kas raksturo lietas tiek organizēti dimensijās. Dimensijas

atribūti ir cieši saistīti viens ar otru. Dimensiju vērtībām kombinējoties kopā, rodas norāde uz faktiem. Ja dimensijas ir samērā vāji korelētas, tad fakta iespējamo vērtību skaits ir neliels. Ja korelācijas pakāpe ir augsta, fakta vērtību skaits var būt ļoti liels.

– Atribūtiem dimensiju modelī ir izšķiroša loma. Tie veido lietojuma vaicājuma noteikumu sistēmu (ierobežojumus) un iegūta pārskata rindu virsrakstus.

Vaicājuma rezultāta tabula 2.atribūts 6.atribūts 2.fakts 3.fakts Aprēķinu rezultāts

1.dimensija primārā atslēga 1.atribūts 2.atribūts 3.atribūts

Faktu tabula ārējā atslēga saitei ar 1.dimensiju ārējā atslēga saitei ar 2.dimensiju 1.fakts 2.fakts 3.fakts

2.dimensija primārā atslēga 4.atribūts 5.atribūts 6.atribūts



Dimensiju modelēšanas Dimensiju modelēšanas pamatjēdzieni (turpinājums)pamatjēdzieni (turpinājums)

1. Dimensiju tabulā atribūti parasti veido vairākas hierarhiju sistēmas. Piemēra, produkta dimensijā – tirgu hierarhija, finansu hierarhija, detaļu un mezglu hierarhija. Labi projektētā datu noliktavā pieprasot vienādu skaitu rakstu dažādās hierarhijas pakāpēs, izpildes laiki nedrīkst būtiski atšķirties.

2. Strādājot ar dimensiju tabulām jānodrošina labas to atribūtu vērtību pārskates (browsing) iespējas. Lietotājam bieži ir vēlams noskaidrot kādas un cik ir unikālas atribūtu vērtības un kā tās ir saistītas ar citu atribūtu vērtībām. Tā kā katrs lietotājs datus analizē izejot no savām prasībām lietderīgi izmantot ierobežojumu definēšanas un piekārtošanas katram lietotājam mehānismu. Lietotājs definē savus ierobežojumus, tie fiksējas un nākošā sessijā atkal tiek ievēroti.

3. Dažreiz “zvaigznes shēma” tiek paplašināta uz “sniegpārsliņas shēmu” izslēdzot no sākotnējās dimensiju tabulas zemas kardinalitātes atribūtus un izveidojot pakārtotas dimensijas tabulu. Visumā tas nav vēlams, jo sarežģī vaicājumu veidošanu, ierobežojumu ievērošanu un datu meklēšanas laiks ļoti būtiski pieaug. Atmiņa nedaudz tiek ekonomēta. Tomēr dažos gadījumos sniegpārsliņas veidošana tiek pieļauta.

Faktu tabula

Dimensiju tabula

Dimensiju tabula

Dimensiju tabula

Dimensiju tabula



Dimensija daudzi ar daudziemDimensija daudzi ar daudziem

1. Lietotāju var interesēt nevis viena dimensijas vērtība, bet vienlaicīgi vairākas. Vēlams veidot datu apkopojumu par tām.

2. Lai realizētu šādus vāicājumus lietderīgi papildināt datu noliktavas struktūru ar tilta (bridge) tabulu.

a) nevēlama situācija

b) risinājums

Saite grupai

Faktu tabula

Dimensijas tabula (vēlams vienlaicīgi apskatīt vairākas vērtības)

Dimensiju tabula

Dimensiju vērtību grupas

tabula

Faktu tabula



Situācija (slazds) daudzi – viens - Situācija (slazds) daudzi – viens - daudzidaudzi

Dimensiju tabula bieži ir saistīta ar vairākām faktu tabulām, pie tam saitēm ir dažāda kardinalitāte. Šādos gadījumos nevar veidot vienotu vaicājumu, jo rezultāts būs nekorekts (SQL šādu variantu “neizprot”). Jāveido 2 vai vairāki vaicājumi un to rezultāti jāapvieno.

Kardinalitāte A Kardinalitāte B

1. vaicājums 2. vaicājums

Faktu tabula “Preces”

Faktu tabula “Rēķini”Dimensijas

tabula



Dimensiju lomas (roles)Dimensiju lomas (roles)

1. Dimensiju tabulai var būt vairāki sasaistes veidi ar faktu tabulu. Tā var realizēt vairākas lomas.

2. Lai norādītu saites jālieto skati, citādi saites tiks uztvertas kā kompleksa saite.

Datu izgūšanas noteikumunorāde

Dimensijas tabula Datums”

1. pirkšanas_datums2. maksāšanas_datums3. saņemšanas_datums

Faktu tabula

Dimensijas tabulas Skats_1

Dimensijas tabulas Skats_2



Datu hierarhijas lietošanas Datu hierarhijas lietošanas problēmasproblēmas

1. Datu noliktavas vaicājumi strādā ar datu agregātiem. Tos veido dažādas sarežģītības pakāpes datu hierarhijas. Datu glabāšanas struktūras nav hierarhiski organizētas, tāpēc ir aktuāls jautājums kā šos hierarhiskos datus izgūt.

2. Pēdējos gados daudzās datu bāzes vadības sistēmās SQL valoda pieļauj hierarhiskus vaicājumus. Tas ļoti atvieglina vaicājumu veidošanu.

3. Lai paātrinātu un vienkāršotu hierarhisku vaicājumu veidošanu, datu noliktavās izmanto papildus navigācijas tabulas. Tās ļauj efektīvi realizēt hierarhiju pārskati gan uz leju, gan uz augšu.

Hierarhijas pārskateDimensijas tabula

Navigācijas tilta tabula

Faktu tabula



Dimensiju īpašību ievērošanaDimensiju īpašību ievērošana

Izmaiņu fiksēšana lielā dimensijā

Audita dimensijas veidošana

Vērtību diapazona iekļaušana pārskatos

Vecums Pensionāru skaits Izmaksu summa 61 – 70 200 000 8 000 000 71 – 80 150 000 6 000 000 81 - 90 30 000 150 000 >= <

Dimensijas tabula

Faktu tabula Faktu tabula (papildinājums)

Faktu tabula Faktu tabula Audita dimensijas

tabula

Diapazona vērtību tabula 1. diapazona_grupa 2. diapazona_nosaukums 3. apakšējā_vērtība 4. augšējā_vērtība

Faktu tabula



Dimensiju izvēršanaDimensiju izvēršanaVeicot datu meklēšanu faktu tabulā tiek izmantoti gan dimensiju identifikatori, gan nosaukumi,

gan citi dimensiju atribūti. Lai to varētu realizēt tiek izmantota viena no trijām iespējām:1. dimensiju tabulā tiek iekļauti vajadzīgie atribūti;2. no atribūtiem tiek veidotas jaunas dimensijas;3. tiek veikta dimensiju izvēršana (vienai dimensiju tabulai tiek veidota pakārtotā (-ās)

dimensiju tabulas.Trešajā variantā tiek realizēta dimensiju tabulas normalizācija (vienā tabulā glabāt informāciju

par viena tipa objektiem, subjektiem vai procesiem). Tas samazina nepieciešamās atmiņas apjomu, bet palielina meklēšanas laiku. Dimensiju izvēršanas lietošana ir vispusīgi jāizvērtē. Kopējā tendence ir - ar to neaizrauties.

1. vaicājums 2. vaicājums

Pirkumi

Preces_identifikatorsPircēja_identifikatorsPārdevēja_identifikatorsGadsMēnesisDaudzumsCenaAtlaide

Pirkumi

Preces_identifikatorsPircēja_identifikatorsPārdevēja_identifikatorsGadsMēnesisDaudzumsCenaAtlaide

Pārdevēji

Pārdevēja_identifikatorsUzvārds_VārdsPārdevējfirmas_identifikatorsTelefons_1Atlaižu_sistēma

Pārdevējfirma

Pārdevējfirmas_identifikatorsFirmas_nosaukumsPilsētaValstsTelefons_2



SekcionēšanaSekcionēšana

1. Sekcionēšana nozīmē datu apakškopas formēšanu. 2. Lieto horizontālo sekcionēša (rindu kopa) un vertikālo sekcionēšanu

(kolonu kopa). 3. Vairums faktu tabulu datu noliktavā strauji palielina savu apjomu. Tas ir

saistīts ar intensīvām izmaiņām operatīvajās datu bāzēs. Lielie faktu tabulu apjomi apgrūtina to administrēšanu un vadību.

4. Ielādējot tajā jaunu datu kopu, faktu tabula uz laiku var būt nepieejama lietotājiem. Ir apgrūtināta arī veco nevajadzīgo datu atdalīšana un nodzēšana.

5. Lai novērstu minētās problēmas, tiek realizēta tabulu sekcionēšana – sadalīšana vairākās sīkākās tabulās. Bieži vien tiek lietota horizontālā sekcionēšana, par pamatfaktoru izvēloties laiku (vienā tabulā viens gads, otrā – nākošais u.t.t).

Vertikāla sekcija

Horizontāla sekcija



Agregēšanas noteikumiAgregēšanas noteikumi1. Datu noliktavās tiek glabāti divu veidu dati:

a) atomārie dati, kuri tiek iegūti no operatīvās darbības DB (OLTP datu bāzes);b) datu agregāti, kurus iegūst veicot datu apvienošanu un vispārināšanu.

2. Svarīgi ir pareizi noteikt:a) kad - kādos gadījumos veikt agregēšanu;b) ko – kādus datus ir nepieciešams agregēt un kādus nē;c) kā – kā veikt datu agregēšanu, kādos līmeņos.

3. Lai noteiktu ko agregēt, parasti tiek izmantotas atskaites un noskaidrota kāda datu statistiska apstrāde bieži tiek veikta. Diemžēl šī informācija nevar sniegt pilnīgu ieskatu potenciālajos vaicājumos kas tiks veidoti izmantojot datu noliktavu.

4. Pieredze parāda ka jāvadās no vairākiem kritērijiem izvēloties veidojamos datu agregātus:a) tā kā tiek lietoti dažādu hierarhijas līmeņu agregāti, tad jāizvēlas tā līmeņa agregāti,

kuru vērtību noteikšana ir visdarbietilpīgākā;b) jācenšas veidot laika gaitā nemainīgus vai maz-mainīgus agregātus;c) jācenšas veidot tādus agregātus, kuru vērtības laika gaitā nav jāaprēķina no jauna, bet

var tikt koriģētas ievērojot tikai izmaiņas;d) ja tiek izmantotas agregātu kombinācijas, tad datu noliktavā jāglabā atsevišķās

sastāvdaļas nevis beigu rezultāts.5. Agrēgātu glabāšanu var realizēt:

a) faktu tabulā kopā ar neagregētiem datiem;b) faktu tabulā atsevišķi no neagregētiem datiem;c) katrai datu agregātu grupai tiek izmantota atsevišķa tabula.



Faktu tabulu apvienošanaFaktu tabulu apvienošana

1. Faktu tabulas ne vienmēr tiek aplūkotas atsevišķi. Bieži nepieciešami savstarpēji saistīti dati no vairākām faktu tabulām.

2. Tad tiek izmantots skatu mehānisms. Faktu tabulām tiek veidoti dažādi skati un tie tiek lietoti vaicājumos.

Faktu tabulas Faktu tabulu skats (view)

L1 L2 L3 L4

L5 L6 L7 L8

L1 L2 L6 L7 L8



Datu noliktavas izstrādē ietvertās Datu noliktavas izstrādē ietvertās personas un to pamatuzdevumipersonas un to pamatuzdevumi

1. Vadītājs – sponsors (executive sponsor). Persona, kurai nepieciešama datu noliktava. Parasti pasūtītāja organizācijas vadītājs. Viņš nodrošina budžetu un vispārēju atbalstu tam.

2. Lietotāju pārstāvis un lietotāji (user liaison and user). Lietotāju pārstāvji parasti nāk no biznesa vides. Viņiem ir ļoti ciešs kontakts ar lietotājiem, saprot to valodu un ir pilnīga lietotāju uzticība. Dažās organizācijās šādu pārstāvju nav (tad atbilstošās funkcijas realizē paši lietotāji). Lietotāju pārstāvji palīdz definēt datu prasības, formātus un drošību.

3. Biznesa analītiķis (business analyst). Viņš parasti ir informācijas tehnoloģiju pārstāvis, kurš labi pārzina biznesa vidi. Viņš tiekas ar lietotājiem un cenšas izprast viņu darbības mērķus un jēgu. Biznesa analītiķis piedāvā jaunas, racionālākas darbības modeļus.

4. Lietotāju palīgs (user support). Viņš ir pirmā palīdzība, kad lietotājam ir problēmas. Viņam labi jāparzina datu bāzes struktūra, izmantotie rīki lai sniegtu skaidrus paskaidrojumus, kā lietotājam dotajā situācijā rīkoties. Lietotāju palīgs labi pārzin biežāk uzdotos jautājumus un radušās problēmas. Viņš palīdz lietotājam izveidot jaunus “ad hoc”tipa vaicājumus un pārskatus un optimizē lietotāju jaunradi.

5. Datu adminstrators (data adminstrator). Datu adminstrators veic biznesa datu modelēšanu saskaņā ar biznesa likumiem. Tiek noteiktas datu saites. Datu adminstrators piedalās arī datu izgūšanas procesā no mantotajiem datu avotiem un sadarbojas ar datu bāzes adminstratoru, lai tas varētu kvalitatīvi veikt datu noliktavas fizisko projektēšanu.

6. Lietojumu projektētājs (application developer). Ir divas lietojumu projektētāju grupas:a) IS aizmugures saimniecības (back-end) programmu projektētāji (datu transformācijas, ielāde,

pārbaudes – 70-80% resursu);b) IS priekšplāna saimniecības (front-end) programmu projektētāji (vaicājumu veidošana, pārskatu

veidošana, OLAP tehnoloģijas lietojumu veidošana).



Datu noliktavas izstrādē ietvertās Datu noliktavas izstrādē ietvertās personas un to pamatuzdevumi personas un to pamatuzdevumi

(turpinājums)(turpinājums)7. Drošības inženieris un audita veicējs (security officer and auditor). Datu noliktavā dažāda līmeņa datu

agregācijai var būt dažāda slepenība. Līdz ar to jādomā ne tikai par atomāro datu izmantošanas tiesībām, bet arī agregātu slepenības pakāpi.

8. Datu bāzes adminstrators (database adminstrator). Viņš ir atbildīgs par datu noliktavas fiziskajiem aspektiem. Tas ietver fizisko projektēšanu, ražību, kopēšanu un atjaunošanu.

9. Sistēmas adminstrators (system adminstrator, technical services). Viņš ir atbildīgs par datu noliktavas tehniskās arhitektūras izveidošanu (tehniskais nodrošinājums, tīkls, operētājsistēma, datu bāzes vadības sistēma).

10. Datu noliktavas arhitekts (data warehouse architect). Izstrādā datu noliktavas arhitektūru (OLAP rīki un kā tie savā starpā saistīti). Tiek risinātas arī datu vitrīnu veidošanas rīku problēmas.

11. Datu noliktavas projekta vadītājs (data warehouse project manager). Viņam ir visaptveroša atbildība par datu noliktavas veiksmīgu realizēšana. Viņš definē, plāno, veido sarakstus un kontrolē projekta izpildi. Viņš veido grupu un risina jautājumus par grupas locekļu saderības nodrošināšanu.

12. Datu kvalitātes analītiķis (data quality analyst). Atrod un risina problēmas, kas saistītas ar datu kvalitātes nodrošināšanu. Viņš ir šo problēmu apskates iniciators. Risinājumi var nākt no citiem grupas locekļiem.

13. Datu izguves rīku adminstrators (query tool adminstrator). Pārzin datu izguves rīkus, to iespējas un ir kontaktā ar rīku izstrādātājiem (attiecīgām firmām). Konsultē lietojumu izstrādātājus un meklē problēmu atbildes saistoties ar piegādes firmām.

14. Web adminstrators (web adminstrator). Ir atbildīgs par web-lietojumiem un web servera drošības organizāciju.

15. Konsultanti un kontrahents (līgumslēdzēja puse) (consultants and contractors). Konsultē pasūtītāja organizāciju informācijas tehnoloģiju jomā. Ja organizācijā nepieciešams darbinieks ar noteiktām iemaņām un zināšanām (uz noteiktu laiku), kādu pasūtītāja organizācijā nav, tiek slēgts kontrakts ar firmu, kurai ir šādi darbinieki.



DB projektēšanas rīks Oracle DB projektēšanas rīks Oracle DesignerDesigner

1. Kompānijas Oracle CASE tehnoloģija bāzējas uz strukturētu pieeju informācijas sistēmas izstrādei.

2. Viss process tiek sadalīts galīga skaita etapos, kuri saistīti savā starpā.

3. Metodoloģijas pamats ir vienota datu bāze (repozitārijs), kurā glabājas visas projekta specifikācijas un ar kuras palīdzību tiek nodrošināta izstrādātāju, kuri strādā lietojumprogrammu izveidošanā, darbību saskaņotība.



CASE rīka Oracle Designer CASE rīka Oracle Designer galvenais izvēles logsgalvenais izvēles logs

Oracle Designer ir sistēmas modelēšanas rīks, kurš nodrošina sekojošas iespējas:

1. Detalizēti aprakstīt kā informācija tiek lietota biznesa procesos, izmantojot Dataflow Diagrammer.

2. Definēt kādu informāciju sistēma pārvaldīs un veidos, izmantojot Entity Relationship Diagrammer;

3. Database Design Transformer, kas izmantojot modeļos norādīto informāciju, to pārveido par datu bāzes modeli;



ER diagrammas veidošanas redaktora ER diagrammas veidošanas redaktora logslogs

ER diagrammu veidošanas redaktora logā:1. tiek izveidotas realitātes;2. tiek norādītas saites.

Realitāšu atribūtu un to domēnu definēšana notiek citos logos.



ER diagrammu attēlojumu ER diagrammu attēlojumu pārveidojumipārveidojumi

CASE rīki veic diagrammas elementu izvietošanas pārveidojumus, lai diagramma būtu uzskatāmāka.



Domēna izveidošana Domēna izveidošana

Lai uzsāktu diagrammas veidošanu, no sākuma ieteicams izveidot domēnus. Lai izveidotu domēnus, izsauc izvēlnes komandu Edit->Domains. Domēnu lietošana atvieglo atribūtu izmantošanu.

Sadaļā ‘Definition’ norāda domēna pamatdatus (nosaukumu, formātu, maksimālo garumu, datu tipu, maksimālo kolonas garumu un komentārus). Nākamajā sadaļā ‘Detail’ norāda papildus datus par attiecīgo domēnu (piemēram, noklusēto vērtību, atribūtu un kolonas datus). Sadaļā ‘Values’ var norādīt visas iespējamās vērtības, kuras var pieņemt mainīgais no šī domēna.



Realitātes atribūtu definēšanaRealitātes atribūtu definēšana1. Realitātes definēšanas logā ir 7 sadaļas (ieliktņi), kuros var norādīt

realitātes atribūtus un to īpašības.

2. Šo logu var izmantot lai ievestu jaunus atribūtus, izdzēstu nevajadzīgos, vai izmainītu jau eksistējošusatribūtus.

3. Atribūtu detalizācijas un vērtību logos varam ievadīt, kādas būs iespējamās atribūtu vērtības. Atribūtus var definēt arī ar izveidoto domēna palīdzību.



Saišu izveidošanaSaišu izveidošana

Realitātes ir savienotas ar dažāda tipa saitēm Definējot saiti:

1. tiek norādīti tās nosaukumi;2. tiek norādīti tās tips un īpašības.



Atribūtu un saišu īpašībasAtribūtu un saišu īpašības1. Realitāšu atribūtu īpašību norādīšanai izmanto sekojošus simbolus:

# - primārais unikālais identifikators (unique identifier) realitātei;* - obligātais (mandatory) atribūts (realitātes eksemplāram vienmēr jābūt šai atribūta

vērtībai); - neobligātais (optional) atribūts (realitātes eksemplāram var arī nebūt šī atribūta vērtība).

2. Diagrammā tiek izmantotas arī super-realitātes (super-type entities). Tās satur vairākas citas realitātes -pakārtotās realitātes (sub-type entities).

3. Realitātei var būt arī “ vai “ tipa saites (arc). 4. Realitātes ir loģiski saistītas. Izmanto sekojošus saišu (relationship) tipus: saite viens pret vienu ( 1 : 1 ) , abpusēji obligāta; saite viens pret vienu ( 1 : 1 ) , abpusēji neobligāta; saite viens pret vienu ( 1 : 1 ) , obligāta tikai vienai būtībai; saite viens pret daudziem ( 1 : M ) , abpusēji obligāta; saite viens pret daudziem ( 1 : M ) , abpusēji neobligāta; saite viens pret daudziem ( 1 : M ) , obligātajam vienam atbilst neobligāti daudzi; saite viens pret daudziem ( 1 : M ) , obligātajiem daudziem atbilst neobligātais viens; saite daudzi pret daudziem ( 1 : M ) , abpusēji obligāta; saite daudzi pret daudziem ( 1 : M ) , abpusēji neobligāta; saite daudzi pret daudziem ( 1 : M ) , obligāta tikai vienai realitātei.



ER Diagrammas attēlojuma ER Diagrammas attēlojuma elementielementi

3+4. realitāte Vai (Arc) Saite 12 Saite 21 Super-realitāte Realitāte

1.realitāte

2.realitāte

3.realitāte

5.realitāte

4.realitāte 6.realitāte 7.realitāte

Realitātes nosaukums # PRIM_IDENT (primārā identifikatora apzīmējums) * ATRIB_1 (obligāta atribūta apzīmējums) * ATRIB_2 (obligāta atribūta apzīmējums) ATRIB_3 (neobligāta atribūta apzīmējums) ATRIB_4 (neobligāta atribūta apzīmējums)



Superrealitātes transformācijas Superrealitātes transformācijas variantivarianti

ER diagramma (Realitētes A,B,C) Datu bāzes projektēšanas palīga pārveidojuma varianti a) (Super-type) b) (Explicit Sub-type) c) (Implicit Sub-type) d)

Super-realitāte * Obligātais lauks_1 1. pakārtotā realitāte # Identifikators_1 * Obligātais lauks_2 * Obligātais lauks_3 Neobligātais lauks_1 2. pakārtotā realitāte # Identifikators_2 * Obligātais lauks_4 * Obligātais lauks_5 Neobligātais lauks_2

A

B

C

A

B

A

C

A

B

A

C

A A

B

C

1.tabula * Obligātais lauks_1 # Identifikators_1 * Obligātais lauks_2 * Obligātais lauks_3

Neobligātais lauks_1

2.tabula * Obligātais lauks_1 # Identifikators_2 * Obligātais lauks_4 * Obligātais lauks_5

Neobligātais lauks_2

A B C



ER diagrammas transformēšana ER diagrammas transformēšana datu bāzes loģiskajā modelīdatu bāzes loģiskajā modelī

ER diagrammas tiek pārveidotas datu bāzes sākotnējā loģiskajā modelī. To veic datu bāzes projektēšanas palīgs (Database Design Transformer). Tas izpilda sekojošus uzdevumus:

1. tabulu definēšana (Table Mapping) no realitātēm, saskaņā ar ievadītām norādēm un projrktēšanas likumiem realizē realitāšu transformēšanu tabulās (atrisina arī saites daudzi ar daudziem problēmu);

2. tabulu lauku definēšana (Column Mapping);3. primāro atslēgu (Primary Keys)un unikālu lauku (Unique

Keys) definēšana;4. atsauksmes atslēgu (Foregn Keys) definēšana;5. pieļaujamo vērtību (Allowable values) un ierobežojumu

definēšana;6. indeksu definēšana (Indexes).



ER diagramma – pamats tabulu un ER diagramma – pamats tabulu un tabulu saišu izveidošanaitabulu saišu izveidošanai

Iegūtā ER diagramma tiek izmantota lai no tās ģenerētu datu bāzes sākotnējo struktūru. To automātiski veic speciāla programma Database transformer.



Datu bāzes struktūras iegūšana ar Datu bāzes struktūras iegūšana ar Database design transformer rīkuDatabase design transformer rīku1. Datu bāzes struktūru veidošana ar Database Design

Transformer rīku.

2. Servera modeļa veidošana ar rīku Design Editor.



Iegūtais servera modelis (tabulas, Iegūtais servera modelis (tabulas, lauki, atslēgas) un saiteslauki, atslēgas) un saites



Projektēšanas sistēmas Projektēšanas sistēmas repozitārija navigatorsrepozitārija navigators

Lai pārliecinātos par to, ka servera modeļa ģenerēšana bija veiksmīga un tika iegūtas attiecīgās relāciju tabulas no ER diagrammas, var izmantot repozitorija objektu navigatoru.



Servera modeļā rediģēšanas palīgsServera modeļā rediģēšanas palīgs

1. Pēc servera (jeb datu bāzes) modeļa veidošanas procesa pabeigšanas tiek palaists Oracle Design Editor rīks, kas ir domāts datu bāzes struktūras rediģēšanai.

2. Tomēr ērtāk ir strādāt ar servera modeļa rediģēšanas palīgu. Palīgs pārskatāma veidā atspoguļo datu bāzes struktūru, piedāvājot savdabīgu modeļa iespējamo struktūru un elementu karti



Projektēšanas rezultātu Projektēšanas rezultātu izvērtējumsizvērtējums

1. Neobligātā 1:M saite ER diagrammā

2. Neobligātā 1:M saite datu bāzes projektējumā bez CASE rīka.

3. Neobligātā 1:M saite DB projektējumā ar Datadase Design Transformer .

R3Mācību kursu posmi

R8Uzvednes

Atsaucas uz

POSMI

PK P_ID

FK1 P_MAACIIBU_KURSA_ID P_NUMURS P_APRAKSTS P_PUBLICEESANAS_DATUMS P_VEIDS P_IZPILDES_LAIKS P_NOD_DATUMSFK2 P_VEIDA_ID

POSMU_UZVEDNES

PK,FK1 POSMA_IDPK,FK2 UZVEDNES_ID

UZVEDNES

PK U_ID

U_TEKSTS



Projektēšanas rezultātu Projektēšanas rezultātu izvērtējums (turpinājums)izvērtējums (turpinājums)

Neobligāta 1:M realitātes sasaiste pašai ar sevi.

1. Neobligātā 1:M saite projektējumā bez CASE rīka.

2. Neobligātā 1:M saite Designer projektējumā

R8Uzvednes

Atsaucas uz

Tā, uz kuru atsaucas

Tā,kura atsaucas

Documents

Datu bāzes projektēšana (DSP410)