Transcript DB_proj_DB5_slaidi

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
J. Eiduks. Datu bāzes projektēšana
Datu bāzes projektēšana
Asoc. profesors, Dr.sc.ing.
Jānis Eiduks
Rīgas Tehniskā universitāte
Datorzinātnes un informācijas tehnoloģijas fakultāte
Lietišķo datorsistēmu institūts
Sistēmu teorijas un projektēšanas katedra
“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
2
J. Eiduks. Datu bāzes projektēšana
Priekš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
“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
3
J. Eiduks. Datu bāzes projektēšana
Priekšmeta mērķi un uzdevumi
“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
4
J. Eiduks. Datu bāzes projektēšana
Pamatlitetratūra
“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
5
J. Eiduks. Datu bāzes projektēšana
Papildliteratūra
“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
6
J. Eiduks. Datu bāzes projektēšana
Atslēgas vārdi
“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
7
J. Eiduks. Datu bāzes projektēšana
Pamattēmas
“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
8
J. Eiduks. Datu bāzes projektēšana
Datu bāzes projektēšana
CASE rīks
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.
DBVS
10. Datu sākotnējās ielādes projekta izstrāde un realizēšana.
“Data stage” tipa rīks
“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
9
J. Eiduks. Datu bāzes projektēšana
Informācijas sistēmas un datu bāzes
sistēmas
Informācijas sistēmas (IS)
Datu bāzes sistēmas
Izpildvaras vai administratora IS
Stratēģiskais līmenis
Vecāko vadītāju līmenis
Lēmumu pieņemšanas atbalsta IS
Stratēģiskais līmenis
Vidējo vadītāju līmenis
Vadības IS
Vadības un pārvaldes līmenis
Darbu vadītāju līmenis
Biroja darbības automatizācijas IS
Vadības un pārvaldes līmenis
Kancelejas darbības līmenis
Transakciju apstrādes IS
Darbību izpildes līmenis
Darbinieki
Universālās 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..
“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
10
J. Eiduks. Datu bāzes projektēšana
Datu bāzes trīs līmeņu projektēšanas shēma
Informācijas sistēmas pasūtītājs
Datu bāzes projektētājs
Datu bāzes konceptuālais
modelis
Datu bāzes projektētājs
Datu bāzes sistēmas administrators
Datu bāzes loģiskais modelis
Datu bāzes sistēmas administrators
Sistēmas administrators
Datu bāzes fiziskais modelis
“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
11
J. Eiduks. Datu bāzes projektēšana
Datu bāzes sistēmas projektēšanas metodes
1. Datubāzes sistēmas projektēšana balstoties uz ieejas un izejas datiem.
Ieejas dati
Sistēma
Izejas dati
Sākuma dati
2. Diagrammu tehnoloģijas (CASE tehnoloģija) izmantošana.
ER
diagrammas
UML
diagrammas
3. Diagrammu tehnoloģijas un jēdzienu pakārtotības modeļu
izmantošana.
ER
diagrammas
UML
diagrammas
+
Semantiskais
tīkls, freimi
“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
12
J. Eiduks. Datu bāzes projektēšana
Datu 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)
b)
c)
d)
ārējā realitāte;
funkcija, kas pārvērš ieejas datus izejas datos;
datu krātuve, kurā tiek glabāti dati un no kuras tiek izgūti dati;
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 krātuve
Datu plūsma P1
“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
13
J. Eiduks. Datu bāzes projektēšana
Datu plūsmas diagrammu hierarhija
Avots
D1
D11
Konteksta līmeņa diagramma
Sistēma
D6
Izlietne
Izlietn
e
Sākuma līmeņa diagramma
Avots
D1
D1
1
F1
D2
K1
0
F3
D31 D7
D1
F5
D3
D9
F6
D8
D4
D6
F4
F2
D5
“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
14
J. Eiduks. Datu bāzes projektēšana
Datu plūsmas diagrammu hierarhija
(turpinājums)
Otrā līmeņa diagramma
F3.2
D15
D3
D18
F3.3
K3
F3.1
D31
D16
D181
D17
Sākuma līmeņa diagramma
Avots
D1
D11
F1
D2
K1
F5
Izlietne
D3
F3
D4
D9
F6
D8
D6
F4
D31 D7
D10
D4
F2
D5
“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
15
J. Eiduks. Datu bāzes projektēšana
Viesnīcas informācijas sistēma
Numuru
apzīmējumi,
tipi un stāvi,
papildīpašības,
Vēlmju
D1 Vaicājuma V1
D1
D1
statuss un
Viesa
V1
Viesis
datu ievade
datumi, viesu
vēlmju
noformēša A1
identifikatori
saņemšana D1
na
A1
Vēlmju dati
Atbildes
aktīvajam viesim A1
Viesu personas
noformēšana
D2
D3
A2, D3
dati un
un nodošana
Viesa personas
D3
identifikatori
viesim
datu ievade VID
(VID)
D3 VID
Viesa atbildes
Rezervēšanas
un personas
VID, A2, D2
A2
raksta
datu
izveidošana un
saņemšana
ierakstīšana
“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
16
J. Eiduks. Datu bāzes projektēšana
Datu 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.
“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
17
J. Eiduks. Datu bāzes projektēšana
ER (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)
b)
c)
realitātes tipi (entity type);
atribūti;
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)
b)
patstāvīgos realitātes tipos (parent, owner, dominant);
pakārtotos realitātes tipos (child, dependent, subordinate).
1. realitātes tips
(entity type)
1.realitātes tipa 3.
eksemplārs
1.realitātes tipa 3.
eksemplārs
1.realitātes tipa 3.
eksemplārs
“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
18
J. Eiduks. Datu bāzes projektēšana
Realitātes atribūti un atslēgas
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Realitātei ir īpašības. Šīs īpašības raksturo atribūti.
Atribūta domēns ir atribūta potenciālo vērtību kopa.
Vienkāršs atribūts sastāv no vienas neatkarīgas komponentes.
Salikts atribūts sastāv no vairākām neatkarīgām komponentēm.
Vienvērtīgs atribūts ir atribūts, kas vienai realitātei satur vienu vērtību.
Daudzvērtīgs atribūts vienai realitātei var saturēt vairākas vērtības.
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).
Potenciālā atslēga viennozīmīgi definē realitātes tipa eksemplārus.
Primārā atslēga ir potenciālā atslēga, kura izvēlēta par realitātes tipa galveno atslēgu.
Alternatīvā atslēga ir potenciālā atslēga, kas nav primārā atslēga.
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
“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
19
J. Eiduks. Datu bāzes projektēšana
Realitāš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).
1. realitāte
2.
Sait
e
2. realitāte
Var runāt arī par realitāšu eksemplāru savstarpējām saitēm
(relationship instance, relationship occurrence)
Atribūti
1. realitātes
eksemplārs
Saites
eksemplārs
2. realitātes
eksemplārs
Atribūti
“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
20
J. Eiduks. Datu bāzes projektēšana
Realitāšu saišu veidi
1.
2.
3.
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.
Realitāšu tipu skaitu, kurus ietver saite, sauc par saites pakāpi.
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ē.
Unārā saite
1. realitāte
1. realitāte
Ternārā saite
2. realitāte
3. realitāte
“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
21
J. Eiduks. Datu bāzes projektēšana
Saišu atribūti
1.
2.
Atribūti var būt arī saitēm. Tātad katram saites
eksemplāram var būt savas atribūtu vērtības.
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. realitāte
2. realitāte
Saite
1. tribūts
2.
atribūts
“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
22
J. Eiduks. Datu bāzes projektēšana
Saiš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)
b)
c)
viens ar vienu (1 : 1);
viens ar daudziem (1 : N);
daudzi ar daudziem ( N : M).
1. realitāte
1
N
Saite
2. realitāte
1. realitātes
eksemplārs
2. realitātes
eksemplārs
1. realitātes
eksemplārs
2. realitātes
eksemplārs
1. realitātes
eksemplārs
2. realitātes
eksemplārs
2. realitātes
eksemplārs
“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
23
J. Eiduks. Datu bāzes projektēšana
Realitātes piedalīšanās pakāpe saitē 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. realitāte
Neobligātā piedalīšanās saitē
(1, N)
Saite
2. realitāte
Obligātā piedalīšanās saitē
“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
24
J. Eiduks. Datu bāzes projektēšana
Pā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. realitāte
1
1
Saite_1_2
Saite_1_3
N
N
2. realitāte
?
3. realitāte
Pārrāvuma slazds
3. realitāte
N
1
Saite_1_3
1
Saite_3_2
N
1. realitāte
2. realitāte
“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
25
J. Eiduks. Datu bāzes projektēšana
Identificē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).
Identifikators
Realitāte
Students
Saite
Realitāte Atzīme
Vājā saite
Vājā realitāte
“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
26
J. Eiduks. Datu bāzes projektēšana
Realitāšu atkarību veidi
1. 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:
Darbinieks
a) pilnas kategorijas hierarhijas;
Numurs
Uzvārds
Vārds
Alga
Amats
Vīrietis
1.atribūts
2.atribūts
Sieviete
3.atribūts
4.atribūts
b) nepilnas kategorijas hierarhijas.
Darbinieks
Numurs
Uzvārds
Vārds
Alga
Amats
Analītiķis
1.atribūts
2.atribūts
Projektētājs
3.atribūts
4.atribūts
“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
27
J. Eiduks. Datu bāzes projektēšana
EER (Enhanced ER) datu konceptuā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).
Superrealitāte Ģimene
Superrealitāte Dzinējs
Realitāte Sieva
Realitāte
Dzinēja 1. bloks
Realitāte Vīrs
Realitāšu apvienojums vienā veselā
Realitāte
Dzinēja 2. bloks
Superklases realitāti papildina
apakšklases realitāte
“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
28
J. Eiduks. Datu bāzes projektēšana
EER (Enhanced ER) datu konceptuālais modelis
(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.
Superrealitāte Kravas
automašina
Superrealitāte Kravas automašina
Realitāte
Dzinējs
Kopēja pakārtotā realitāte
“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
29
J. Eiduks. Datu bāzes projektēšana
ER 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
“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
30
J. Eiduks. Datu bāzes projektēšana
Pā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
2) likums
3) likums
4) likums
5) likums
6) likums
1. realitāte
1. realitāte
1
1
1. realitāte
1
1. realitāte
1
1. realitāte
1
1. realitāte
N
1
1
1
N
N
M
2. realitāte
2. realitāte
2. realitāte
2. realitāte
2. realitāte
2. realitāte
= Viena datu tabula
= Divas datu tabulas
= Trīs datu tabulas
= Divas datu tabulas
= Trīs datu tabulas
= Trīs datu tabulas
“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
31
J. Eiduks. Datu bāzes projektēšana
Datu 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)
X
1
2
3
Y
2
3
4
Y = f (X) = 1 + X
X - arguments;
Y - funkcija
b)
c)
Firmas
Tālruņa
nosaukums numurs
Uzvārds
Vārds
ABC
A un B
Spars
Koks
Celms
Koks
Sakne
Liene
Zane
Varis
Juris
Firmas
nosaukums
Determinants
7222222
7222223
7222224
Tālruņa
numurs
Uzvārds
Vārds
Tālruņa
numurs
7444444
7444445
7444446
7444447
Tālruņa
numurs
Determinants
“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
32
J. Eiduks. Datu bāzes projektēšana
Datu funkcionālā atkarība (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)
Viesa
numurs
Pakalpojuma
numurs
Pakalpojuma
maksa
Viesa
numurs
Uzvārds
Viesnīcas numura
numurs
6. Datu funkcionālās atkarības. a) - funkcionāli pilna atkarība, b) - ne funkcionāli
pilna atkarība.
“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
33
J. Eiduks. Datu bāzes projektēšana
Tabulas lauku funkcionālās atkarī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
“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
34
J. Eiduks. Datu bāzes projektēšana
Daudzkriterialitāte tabulas 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)
Q2(X)
QN(X)
opt
X
opt
X
opt
X
X 1*
X- datu bāzes struktūra
X 2*
X**
XN*
Q1(X)
Optimums pēc pirmā kritērija
Pareto kopa (X**)
X1
Optimums pēc otrā kritērija
X2
X 1 > X2
Q 2(X)
“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
35
J. Eiduks. Datu bāzes projektēšana
Normālformu kritēriji
1. 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.
Piegādes
daudzums
Primārā atslēga
Piegādātāja
numurs
Piegādātāja statuss
Pilsēta
Piegādes
numurs
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.
Piegādātāja
numurs
Piegādātāja
statuss
Piegādātāja
numurs
Pilsēta
Piegādes
numurs
Piegādes
daudzums
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
Pilsēta
Pilsēta
(primārā
atslēga)
Piegādātāja
statuss
“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
36
J. Eiduks. Datu bāzes projektēšana
Boisa-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 Algas
Numurs
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
“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
37
J. Eiduks. Datu bāzes projektēšana
Funkcionālo atkarību pārveidojumu noteikumi
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
Y
X
,tad
2. noteikums (papildinājums).
Ja
un
X
X
U
Y
X
U
Y
U
Y
U
Z
U
un
3.noteikums (tranzitivitāte).
X
Y
Ja
un
Y
Z
4. noteikums (izplešanās).
Y
Ja X
5. noteikums (izplešanās turpinājums).
Ja X
Y
6. noteikums (pseidotranzitivitāte).
Ja
un Y,W
X
Y
Z
X
Y
,tad
X,U,
Z
Y,U,
Z
,tad
X
Z
,tad
X,U,
Z
X,U,
Z
Y
, tad
,tad
X,W
Y,U,
Z
Z
“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
38
J. Eiduks. Datu bāzes projektēšana
Funkcionālo attiecību 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
K
C
D
a)
Pārveidojumu piemērs
A
B
K
C
D
b)
Pārveidojumu piemērs
A
B
K
C
D
c)
“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
39
J. Eiduks. Datu bāzes projektēšana
Ceturtā normālforma un datu
daudzvērtību atkarības
Mācību kurss
Sistēmas analīze
Projektēšana
Pasniedzējs
Koks
Zars
Koks
Mācību kurss
Sistēmas analīze
Sistēmas analīze
Projektēšana
Pasniedzējs
Zars
Koks
Koks
Mācību grāmata
Analīze 1
Analīze 2
Projektēšana 1
Projektēšana 2
Projektēšana 3
Tabulas Mācības_1 projekcijas
Tabula Mācības
Daudzvērtību atkarības:
Mācību kurss Pasniedzējs
Mācību kurss
 Mācību grāmata
Mācību kurss
Sistēmas analīze
Sistēmas analīze
Projektēšana
Projektēšana
Projektēšana
Mācību grāmata
Analīze 1
Analīze 2
Projektēšana 1
Projektēšana 2
Projektēšana 3
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.
“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
40
J. Eiduks. Datu bāzes projektēšana
Piektā normālforma
Daž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).
Piegādātājs
Pieg_1
Pieg_1
Pieg_2
Pieg_1
Detaļa
Det_1
Det_2
Det_1
Det_1
Projekts
Proj_2
Proj_1
Proj_1
Proj_1
Piegādātājs
Pieg_1
Pieg_1
Pieg_2
Detaļa
Det_1
Det_2
Det_1
Detaļa
Det_1
Det_2
Det_1
Tabula Piegādātājs_detaļa_projekts
Projekcijas
Projekts Projekts Piegādātājs
Proj_2
Proj_2
Pieg_1
Proj_1
Proj_1
Pieg_1
Proj_1
Proj_1
Pieg_2
Savienojums no divām pirmajām projekcijām
Piegādātājs
Pieg_1
Pieg_1
Pieg_2
Pieg_2
Pieg_1
Detaļa
Det_1
Det_2
Det_1
Det_1
Det_1
Projekts
Proj_2
Proj_1
Proj_1
Proj_2
Proj_1
Lieks raksts
“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
41
J. Eiduks. Datu bāzes projektēšana
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)
“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
42
J. Eiduks. Datu bāzes projektēšana
Relāciju-objektu datu bāzes sistē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)
b)
c)
binārie lielie objekti – BLOB (BYNARY LARGE OBJECT);
simbolu lielie objekti - CLOB ( CHARACTER LARGE OBJECT);
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.
“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
43
J. Eiduks. Datu bāzes projektēšana
RODBS trūkumi
1.
2.
3.
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.
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.
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ā.
“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
44
J. Eiduks. Datu bāzes projektēšana
UML (The Unified Modeling Language)
modelēšanas valoda
1.
2.
3.
4.
5.
UML ir vizuāla modelēšanas valoda, kas paredzēta
informācijas sistēmu funkcionalitātes un datu struktūru
modelēšanai.
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.
UML ļauj modelēt gan informācijas sistēmas statisko
struktūru, gan sistēmas uzvedības dinamiku.
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.
UML ir diskrēta modelēšanas valoda. Tā nav paredzēta
analogu, nepārtrauktu sistēmu projektēšanai.
“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
45
J. Eiduks. Datu bāzes projektēšana
UML valodas diagrammas
Struktūras modelēšanas
diagrammas
Dinamikas modelēšanas
diagrammas
Klases
diagrammas
Stāvokļu
diagrammas
Izmantojuma
diagrammas
Darbību
diagrammas
Komponentu
diagrammas
Secību jeb virkņu
diagrammas
Izvērsuma
diagrammas
Kooperācijas
diagrammas
“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
46
J. Eiduks. Datu bāzes projektēšana
UML diagrammas elementi
Elements
Funkcija
Aktieris
Sistēmas lietotājs
Klase
Modelējamās sistēmas koncepcija
Klase
noteiktā
stāvoklī
Klasifikatora
loma
Komponents
Klase, kas var atrasties tikai vienā
stāvoklī
Datu tips
Primitīvo vērtību grupas deskriptors
Interfeiss
Nosaukta
operāciju kopa,
kas
raksturo noteiktu uzvedību
Skaitļošanas (aprēķinu) mezgls
Mezgls
Klasifikators, kas noteiktā veidā tiek
izmantots kooperācijā
Sistēmas daļa
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
Notācija
Nosaukums
Nosaukums [S]
Role: Nosaukums
Character, Date, …
Int_nosaukums
“signāls”
“Apakšsistēma”
Sistēmas uzvedības specifikācija
“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
47
J. Eiduks. Datu bāzes projektēšana
UML klašu diagramma
Klase -
Lietotājs
uzvārds: string
telefons: string
Atribūti
Pievienot(uzvārds,telefons)
Metodes
Asociācija
1 īpašnieks
Lomu nosaukumi
* īpašums
Klase -
Lietojums
nosaukums: string
datums: date
Reģistrēt(nosaukums,datums)
“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
48
J. Eiduks. Datu bāzes projektēšana
RODBVS datu tipi
1.
2.
3.
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.
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.).
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.
“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
49
J. Eiduks. Datu bāzes projektēšana
UML datu tipu pārveidošana par RODBS
datu struktūrām
1.
2.
3.
4.
5.
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.
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.
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”.
UML diagrammas datu struktūras ar „DataType” klasifikatoriem pārveido primitīvos
RODBS datu tipos.
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.
“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
50
J. Eiduks. Datu bāzes projektēšana
UML asociācijas
1. UML statiskas struktūras asociācijas:
1) ģeneralizācija jeb mantošana;
Class3
Class1
Class2
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
1
*
-End1
-End2
Class6
Kopēja agragācija
(shared agragation):
Kompozīcija
(Composition):
1
*
-End1
-End2
Class7 pieder Class6
Class7 nepieder Class6
Class7
Class7
“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
51
J. Eiduks. Datu bāzes projektēšana
UML asociāciju pārveidošana RODBS datu
struktū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.
“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
52
J. Eiduks. Datu bāzes projektēšana
Objekta atribūti un to izmantošana
1.
2.
3.
4.
5.
Objekta atribūts ir objekta tipa atribūts, kurš glabā strukturētu objektu nevis iebūvēto
datu tipu.
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.
Objektiem vienmēr ir ārēja, unikāla identitāte.
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.
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
Galvenais objekts ar
objekta atribūtu
Identifikācijas numurs
1
-Identificējas ar
1
-Identificē
Identifikācijas
dokuments
Atribūtā ieliktais
objekts
“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
53
J. Eiduks. Datu bāzes projektēšana
Objekta atsauce
1.
2.
3.
4.
Atsauce ir loģisks radītājs uz objektu, kurš glabājas RODBS tabulā.
Atsauce ir realizēta, kā objekta identifikators (OID). RODBVS ģenerē OID katram strukturēta tipa
objektam.
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.
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.
Persona
Adreses tipa objekti
atsaucas uz objektiem
Persona
*
0..1
0..1
*
Adrese
5.
6.
Persona
Var arī otrādi: Persona
objekti atsaucas uz
Adreses tipa objektiem
Adrese
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. 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.
“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
54
J. Eiduks. Datu bāzes projektēšana
Kolekciju izmantošana
1.
2.
3.
4.
5.
6.
7.
Kolekcija ir atribūts, kurš satur vairākas viena tipa vērtības (masīvs, kopa vai tabula).
SQL3 standarts paredz tikai vienu kolekcijas tipu  masīvu ARRAY.
DBVS Oracle realizē masīvu VARYING ARRAY un ieliktās tabulas.
Informix piedāvā kolekcijas – sarakstus: SET,MULTISET un LIST. Kolekcijas mērķis ir apvienot objektu
kopu vienā kolonnā.
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.
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);
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.
“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
55
J. Eiduks. Datu bāzes projektēšana
Objektu metožu realizēšana
1.
2.
3.
4.
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.
Oracle RODBS realizē metožu pievienošanu objektu tipam.
SQL3 standarts ievieš virkni standartoperāciju ar objektu
atribūtiem (get un set metodes), konstruktorus un tipu
pārveidošanas funkcijas.
Ir vērts transformēt tikai tās metodes, kuras pilda servera
operācijas.
“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
56
J. Eiduks. Datu bāzes projektēšana
Transformācijas shēma
RO 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.
“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
57
J. Eiduks. Datu bāzes projektēšana
Transformācijas shēma (1. turpinājums)
5. Objektu tipam ir jāpievieno atribūtus:
a)
b)
c)
d)
e)
UML atribūts UML klasē pārtop par atribūtu objektu tipā;
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.
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;
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;
ja ir nepieciešams, jāpievieno CHECK ierobežojumus.
6. Tur kur ir nepieciešams jārealizē mantošanu starp klasēm:
a)
b)
c)
d)
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).
Ja klase satur atribūtus ar marķieri {oid}, jāpievieno šos atribūtus kopējam tabulas PRIMARU
KEY nosacījumam.
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.
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.
“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
58
J. Eiduks. Datu bāzes projektēšana
Transformācijas shēma (2. turpinājums)
7.
8.
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.
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)
b)
2.
jāpievieno atribūts, kas veidos ārējo atslēgu;
jāpievieno atsauci uz objektu ar kardinalitāti 1.
transformējot kompozīcijas arī jāizšķiras starp dieviem variantiem:
a)
b)
jāizveido primāro atslēgu galvenā objekta tabulai un ārējo atslēgu iekļauta objekta tabulai (FOREIGN KEY ar
CASCADE nosacījumu);
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.
9.
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.
Jātransformē klašu metodes, iegūstot vai nu objektu tipu metodes vai iebūvētas procedūras (atkarībā
no RODBS).
“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
59
J. Eiduks. Datu bāzes projektēšana
Informācijas sistēmas izstrādes grupa
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.
“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
60
J. Eiduks. Datu bāzes projektēšana
Datu bāzes datu glabāšanas struktūras un
lietojumu saistība
1.
2.
3.
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.
Lietojumu veidošanai kā pamatdiagrammu izmanto funkciju hierarhiju diagrammu.
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.
“Augsta līmeņa”
Funkcijas apzīmējums
Funkcijas semantikas
īss izskaidrojums
Funkcijas apzīmējums
Funkcijas semantikas
īss izskaidrojums
Funkcijas apzīmējums
Funkcijas semantikas
īss izskaidrojums
Funkcijas apzīmējums
Funkcijas semantikas
īss izskaidrojums
Funkcijas apzīmējums
Funkcijas semantikas
īss izskaidrojums
Funkcijas apzīmējums
Funkcijas semantikas
īss izskaidrojums
Funkcijas apzīmējums
funkcijas
Funkcijas semantikas
īss izskaidrojums
Atomāras
funkcijas
“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
61
J. Eiduks. Datu bāzes projektēšana
Funkciju īpašības
1.
2.
3.
4.
5.
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.
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ī.
Atomārās funkcijas netiek tālāk dalītas pakārtotās funkcijās.
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ā.
Funkcija var tikt izpildīta realizējoties kādam notikumam. Tādu funkciju sauc
par funkciju ar trigera inicializāciju (Triggered function).
“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
62
J. Eiduks. Datu bāzes projektēšana
Funkciju īpašības (turpinājums)
4.
5.
6.
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).
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.
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.
“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
63
J. Eiduks. Datu bāzes projektēšana
Formas veida definēšana
1.
2.
3.
Formas struktūru nosaka tabulu, atribūtu un saišu lietojums.
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).
Var izdalīt vairākus tipiskos tabulu izmantojumus formā.
a) Galvenā – pakārtotā tabulas
Galvenā
tabula
Bāzes
tabula
b) Pakārtoto tabulu ķēde
Pārskata
tabula
Pārskata
tabula
Pakārtotā
tabula
c) Galvenā – pakārtotā tabulas ar pārskata tabulu
Galvenā
tabula
Pārskata
tabula
Pakārtotā
tabula
Pārskata
tabula
Galvenā
tabula
d) Tabulu matrica
Galvenā
tabula
Pakārtotā tabula
“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
64
J. Eiduks. Datu bāzes projektēšana
Formas struktūras saistība ar
izmantojamām tabulām
Bāzes
tabulas
1.tabula
Lauks_1
Lauks_2
...
Saite un
atsauces
atslēga
2.tabula
Lauks_21
Lauks_22
...
3.tabula
Lauks_31
Lauks_32
...
4.tabula
Lauks_41
Lauks_42
...
Jauna
lapa,
jauns
logs
Jauna
lapa
5.tabula
Lauks_51
Lauks_52
...
Pārskata
tabulas
Jauna
“Popup”
tipa izvēlne
“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
65
J. Eiduks. Datu bāzes projektēšana
Lietojumu noskaņošana - SQL vaicājumu
noskaņošana
1.
2.
3.
Projektējot informācijas sistēmu sākotnēji izstrādātājs veido SQL
vaicājumus, nodrošinot tikai loģisko korektumu.
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.
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
glabāšana
Datu
izgūšana
1. lietojums
(SQL vaicājumi)
2. lietojums
(SQL vaicājumi)
Datu bāzes sistēma
“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
66
J. Eiduks. Datu bāzes projektēšana
SQL vaicājumu noskaņošanas shēma
Statistikas savākšana
SQL
vaicājums
Vaicājumu
projektētājs
Vaicājumu
analizētājs
Optimizators:
1) resursu analīzes optimizators
(cost-based optimizer);
2) likumu izmantošanas
optimizators (rule-based
optimizer).
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
Izpildes
plāna
apraksta
iegūšana
“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
67
J. Eiduks. Datu bāzes projektēšana
SQL vaicājumu noskaņošanas darbības
1.
2.
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)
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;
“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
68
J. Eiduks. Datu bāzes projektēšana
Relāciju algebras darbības
1. Apvienošana R = R1 U R2
2. Starpìba R = R1 - R2
R1
a b v
d e a
i k l
R1
a b v
d e a
i k l
3. Dekarta reizinājums R = R1 x R2
4. Projekcija R = proj i1, i2(R1)
5. Selekcija (ierobežošana) R = selF(R1)
a
d
i
a
d
i
g
i
R2
d e
k l
R
a b v
d e a
i k l
g d e
R2
R
g
i
d e
k l
b
e
k
b
e
k
v
a
l
v
a
l
a
d
i
b
e
k
a b v
d e a
g
g
g
i
i
i
d
d
d
k
k
k
e
e
e
l
l
l
R = proj 1, 2 (R1)
R = sel (R1)
I 1 = a vai I2 = k
a
i
b
k
v
l
“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
69
J. Eiduks. Datu bāzes projektēšana
Relāciju algebras darbības (turpinājums)
6. Pārklāšanās R = R1 ∩ R2
7. Dalīšana R = R1 del R2
i
o
c
i
i
R1
o
p
k
o
k
l
R2
c
c
p
p
8. Savienošana R = R1 sav R2
R1
B=D
A B
a
b
a
i
d e
a
a
k
k
c
p
C
c
p
z
D
a
e
9. Dabiskā savienošana R = R1 dab.sav. R2 R1
A B
C
k m
t
a
k
R
i
R2
E
i
k
o
R
A
d
R2
B
m
A
k
B
e
C
z
D
e
E
k
R
B C
m t
“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
70
J. Eiduks. Datu bāzes projektēšana
Vaicājumu analīze
1. Datu pieeju karte (logical access map).
N 2.realitāte N
1.realitāte 1
Read (5)
Write (5)
1 3.realitāte
Read (5), Write (5), Delete (5)
2. Transakciju - atribūtu režģis (transaction - attribute grid).
Realitāte
Atribūts
1.trans.
1.realitāte
2.realitāte
3.realitāte
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
Transakcijas
2.trans. 3.trans.
4.trans.
R(3)
R(3)
W(3)
R(10)
R(10)
R(10)
W(3)
U(10)
U(10)
D(3),W(3)
“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
71
J. Eiduks. Datu bāzes projektēšana
SQL vaicājuma izpildes etapi
SQL - vaicājums
Vaicājuma
sintaksiskā analīze
Vaicājuma
optimizācija
Vaicājuma loģiskā
plāna izvēle
Vaicājuma fiziskā
plāna izvēle
Vaicājuma izteiksmju
koks
Vaicājuma loģiskā plāna
koks
Vaicājuma fiziskā plāna
koks
Plāna izpilde
“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
72
J. Eiduks. Datu bāzes projektēšana
Datu 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
“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
73
J. Eiduks. Datu bāzes projektēšana
SQL vaicājuma izpildes plāna iegūšana
un analīze
1.
2.
3.
SQL vaicājums ir veidots divām tabulām un tiek lietoti operands CUBE un
funkcija GROUPING.
Ar EXPLAIN PLAN komandu iegūstam izpildes plānu, kas tiek ierakstīts
speciālā tabulā (Plan_table) DB.
Ar SELECT vaicājumu no Plan_table izvadām izpildes plānu.
“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
74
J. Eiduks. Datu bāzes projektēšana
SQL vaicājuma izpildes plāna iegūšana
un analīze (turpinājums)
4.
Izpildes plāna darbību izpildes secība ir sekojoša:
a)
b)
c)
d)
e)
f)
g)
h)
(7) INDEX (UNIQUE SCAN) OF ‘P_K_UZSK_NUM’ – darbība atgriež rakstu rowid
darbībai (6);
(6) TABLE ACCESS (BY INDEX ROWID) OF ‘PIETEIKUMS’ – darbība atgriež
atbilstošos rakstus no tabulas Pieteikums darbībai (4);
(5) TABLE ACCESS (FULL) OF ‘IZMAKSAS' – tā atgriež visus rakstus no tabulas
Izmaksas darbībai (4);
(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);
(3) SORT (GROUP BY) – darbība kārto rindas grupās, jo vaicājumā ir izmantoti
GROUPING parametri. Rakstus nodod darbībai (2);
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);
(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);
(0) SELECT STATEMENT – visi saņemtie raksti no apvienotajām tabulām tiek
izvadīti.
75
“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
Datu noliktavas sistēmas izstrādes
galvenie 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.
Rīks datu
modeļa
veidošanai
Operatīvo
Operatīvo
datu
daturelāciju
relāciju
datu
datubāze
bāze
Rīks datu
nodošanai
Datu
attīrīšana,
apkopošana,
agregēšana
Rīks datu
modeļa
veidošanai
Datu
Datu
noliktavas
noliktavas
relāciju datu
datu
relāciju
bāze
bāze
Rīks datu
modeļa
veidošanai
Datu
Datu
noliktava
nolikava
(MOLAP)
(MOLAP)
Rīks
lietojumu
veidošanai
Datu
izgūšana un
analīze
Metadatu
repozitārijs
“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
76
J. Eiduks. Datu bāzes projektēšana
Dimensiju modelēšana
1.
2.
3.
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.
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.
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_1
Lauks_1 Primārā atslēga
Lauks_2
Lauks_3
Faktu tabula_A
Lauks_1 Atsauces atslēga
Lauks_2 Atsauces atslēga
Lauks_3
Dimensiju tabula_2
Lauks_1 Primārā atslēga
Lauks_2
Lauks_3
“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
77
J. Eiduks. Datu bāzes projektēšana
Dimensiju 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.
“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
78
J. Eiduks. Datu bāzes projektēšana
Dimensiju modeļa priekšrocības
1.
2.
3.
Dimensiju modelis ir labi izprotams un no tā vienkārši var iegūt
nepieciešamos datus.
Visas dimensijas ir loģiski ekvivalentas. Līdz ar to vaicājumi ir simetriski,
vienveidīgi.
Dimensiju modelis ir viegli paplašināms, pievienojot :
a)
b)
c)
d)
4.
Ir speciālas pieejas īpašu situāciju modelēšanā:
a)
b)
c)
d)
5.
jaunus faktus;
jaunas dimensijas;
jaunus dimensiju atribūtus;
jaunu apakšdimensiju ieviešana.
lēnu izmaiņu dimensiju modelēšana;
heterogēnu biznesa objektu izvērtēšana (vienlaicīgi jāievēro aršķirīgas biznesa
lietas);
pay-in advance databases ;
event-handling databases (darbība faktu deficītā).
Agregātu lietošanas iespējas (būtiskas vaicājuma izpildes ātrdarbības
palielināšanas iespējas).
“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
79
J. Eiduks. Datu bāzes projektēšana
Dimensiju modelēšanas pamatjēdzieni
1.
2.
3.
4.
Dimensiju modelī svarīgi ir atšķirt faktus un atribūtus.
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).
Atribūts parasti ir teksta formā un norāda reālu lietu īpašību.
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.
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
Vaicājuma rezultāta tabula
2.atribūts 6.atribūts 2.fakts
3.fakts
2.dimensija
primārā atslēga
4.atribūts
5.atribūts
6.atribūts
Aprēķinu rezultāts
“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
80
J. Eiduks. Datu bāzes projektēšana
Dimensiju modelēšanas pamatjēdzieni
(turpinājums)
1.
2.
3.
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.
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.
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.
Dimensiju
tabula
Dimensiju
tabula
Faktu
tabula
Dimensiju
tabula
Dimensiju
tabula
“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
81
J. Eiduks. Datu bāzes projektēšana
Dimensija 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
Faktu
tabula
Dimensijas tabula
(vēlams vienlaicīgi apskatīt
vairākas vērtības)
b) risinājums
Dimensiju
tabula
Dimensiju vērtību
grupas tabula
Faktu
tabula
Saite grupai
“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
82
J. Eiduks. Datu bāzes projektēšana
Situācija (slazds) daudzi – viens - daudzi
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.
Faktu tabula
“Preces”
Kardinalitāte A
1. vaicājums
Dimensijas
tabula
Faktu tabula
“Rēķini”
Kardinalitāte B
2. vaicājums
“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
83
J. Eiduks. Datu bāzes projektēšana
Dimensiju lomas (roles)
1.
2.
Dimensiju tabulai var būt vairāki sasaistes veidi ar faktu tabulu. Tā
var realizēt vairākas lomas.
Lai norādītu saites jālieto skati, citādi saites tiks uztvertas kā
kompleksa saite.
Dimensijas tabula Datums”
1. pirkšanas_datums
2. maksāšanas_datums
3. saņemšanas_datums
Faktu tabula
Dimensijas tabulas Skats_1
Dimensijas tabulas Skats_2
Datu izgūšanas noteikumu
norāde
“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
84
J. Eiduks. Datu bāzes projektēšana
Datu hierarhijas lietošanas problēmas
1.
2.
3.
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.
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.
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ārskate
Dimensijas
tabula
Navigācijas
tilta tabula
Faktu tabula
“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
85
J. Eiduks. Datu bāzes projektēšana
Dimensiju īpašību ievērošana
Izmaiņu fiksēšana lielā dimensijā
Dimensijas
tabula
Faktu tabula
(papildinājums)
Faktu tabula
Audita dimensijas veidošana
Faktu tabula
Audita
dimensijas
tabula
Faktu tabula
Vērtību diapazona iekļaušana pārskatos
Vecums
61 – 70
71 – 80
81 - 90
Pensionāru skaits
200 000
150 000
30 000
Diapazona vērtību tabula
1. diapazona_grupa
2. diapazona_nosaukums
3. apakšējā_vērtība
4. augšējā_vērtība
>=
<
Izmaksu summa
8 000 000
6 000 000
150 000
Faktu
tabula
“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
86
J. Eiduks. Datu bāzes projektēšana
Dimensiju izvēršana
Veicot 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.
Pirkumi
Pārdevēji
Pārdevējfirma
Preces_identifikators
Pircēja_identifikators
Pārdevēja_identifikators
Gads
Mēnesis
Daudzums
Cena
Atlaide
Pārdevēja_identifikators
Uzvārds_Vārds
Pārdevējfirmas_identifikators
Telefons_1
Atlaižu_sistēma
Pārdevējfirmas_identifikators
Firmas_nosaukums
Pilsēta
Valsts
Telefons_2
1. vaicājums
2. vaicājums
“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
87
J. Eiduks. Datu bāzes projektēšana
Sekcionēšana
1.
2.
3.
4.
5.
Sekcionēšana nozīmē datu apakškopas formēšanu.
Lieto horizontālo sekcionēša (rindu kopa) un vertikālo sekcionēšanu (kolonu kopa).
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.
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.
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).
Horizontāla sekcija
Vertikāla
sekcija
“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
88
J. Eiduks. Datu bāzes projektēšana
Agregēšanas noteikumi
1.
2.
3.
4.
5.
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.
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.
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.
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.
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.
“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
89
J. Eiduks. Datu bāzes projektēšana
Faktu tabulu apvienošana
1.
2.
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.
Tad tiek izmantots skatu mehānisms. Faktu tabulām tiek
veidoti dažādi skati un tie tiek lietoti vaicājumos.
L1
L2
L3
L4
L5
Faktu tabulas
L6
L7
L8
L1
L2
L6
L7
L8
Faktu tabulu skats (view)
“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
90
J. Eiduks. Datu bāzes projektēšana
Datu noliktavas izstrādē ietvertās
personas un to pamatuzdevumi
1.
2.
3.
4.
5.
6.
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.
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.
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.
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.
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.
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 – 7080% 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).
“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
91
J. Eiduks. Datu bāzes projektēšana
Datu noliktavas izstrādē ietvertās personas
un to pamatuzdevumi (turpinājums)
7.
8.
9.
10.
11.
12.
13.
14.
15.
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.
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.
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).
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.
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.
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.
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.
Web adminstrators (web adminstrator). Ir atbildīgs par web-lietojumiem un web servera drošības organizāciju.
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.
“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
92
J. Eiduks. Datu bāzes projektēšana
DB projektēšanas rīks Oracle Designer
1.
2.
3.
Kompānijas Oracle CASE
tehnoloģija bāzējas uz
strukturētu pieeju
informācijas sistēmas
izstrādei.
Viss process tiek sadalīts
galīga skaita etapos, kuri
saistīti savā starpā.
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.
“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
93
J. Eiduks. Datu bāzes projektēšana
CASE rīka Oracle Designer galvenais
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;
“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
94
J. Eiduks. Datu bāzes projektēšana
ER diagrammas veidošanas redaktora logs
ER diagrammu veidošanas redaktora logā:
1.
2.
tiek izveidotas realitātes;
tiek norādītas saites.
Realitāšu atribūtu un to domēnu definēšana notiek citos logos.
“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
95
J. Eiduks. Datu bāzes projektēšana
ER diagrammu attēlojumu pārveidojumi
CASE rīki veic diagrammas elementu izvietošanas
pārveidojumus, lai diagramma būtu uzskatāmāka.
“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
96
J. Eiduks. Datu bāzes projektēš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.
“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
97
J. Eiduks. Datu bāzes projektēšana
Realitātes atribūtu definēšana
1.
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.
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.
3.
“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
98
J. Eiduks. Datu bāzes projektēšana
Saiš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.
“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
99
J. Eiduks. Datu bāzes projektēšana
Atribūtu un saišu īpašības
1.
2.
3.
4.
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).
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).
Realitātei var būt arī “ vai “ tipa saites (arc).
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.
“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
100
J. Eiduks. Datu bāzes projektēšana
ER Diagrammas attēlojuma elementi
3+4. realitāte
1.realitāte
5.realitāte
3.realitāte
Vai (Arc)
Saite 12
Saite 21
2.realitāte
4.realitāte
6.realitāte
7.realitāte
Super-realitāte
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)
“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
101
J. Eiduks. Datu bāzes projektēšana
Superrealitātes transformācijas varianti
ER diagramma (Realitētes A,B,C)
A
Datu bāzes projektēšanas palīga
pārveidojuma varianti
a) (Super-type) b) (Explicit Sub-type) c) (Implicit Sub-type) d)
B
A
A
A
A
A
B
B
C
B
C
C
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
C
Super-realitāte
* Obligātais lauks_1
A
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
“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
102
J. Eiduks. Datu bāzes projektēšana
ER diagrammas transformēšana 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.
2.
3.
4.
5.
6.
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);
tabulu lauku definēšana (Column Mapping);
primāro atslēgu (Primary Keys)un unikālu lauku (Unique Keys)
definēšana;
atsauksmes atslēgu (Foregn Keys) definēšana;
pieļaujamo vērtību (Allowable values) un ierobežojumu
definēšana;
indeksu definēšana (Indexes).
“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
103
J. Eiduks. Datu bāzes projektēšana
ER diagramma – pamats tabulu un
tabulu 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.
“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
104
J. Eiduks. Datu bāzes projektēšana
Datu bāzes struktūras iegūšana ar
Database design transformer rīku
1.
Datu bāzes struktūru veidošana ar Database Design Transformer
rīku.
2.
Servera modeļa veidošana ar rīku Design Editor.
“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
105
J. Eiduks. Datu bāzes projektēšana
Iegūtais servera modelis (tabulas, lauki,
atslēgas) un saites
“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
106
J. Eiduks. Datu bāzes projektēšana
Projektēšanas sistēmas repozitā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.
“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
107
J. Eiduks. Datu bāzes projektēšana
Servera modeļā rediģēšanas palīgs
1.
2.
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.
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
“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
108
J. Eiduks. Datu bāzes projektēšana
Projektēšanas rezultātu izvērtējums
1.
Neobligātā 1:M saite ER
diagrammā
R8
Uzvednes
R3
Mācību kursu posmi
Atsaucas uz
POSMI
2.
Neobligātā 1:M saite datu bāzes
projektējumā bez CASE rīka.
PK
P_ID
FK1
P_MAACIIBU_KURSA_ID
P_NUMURS
P_APRAKSTS
P_PUBLICEESANAS_DATUMS
P_VEIDS
P_IZPILDES_LAIKS
P_NOD_DATUMS
P_VEIDA_ID
POSMU_UZVEDNES
UZVEDNES
PK
U_ID
PK,FK1
PK,FK2
POSMA_ID
UZVEDNES_ID
FK2
U_TEKSTS
3.
Neobligātā 1:M saite DB
projektējumā ar Datadase
Design Transformer .
“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
109
J. Eiduks. Datu bāzes projektēšana
Projektēšanas rezultātu 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.
R8
Uzvednes
Tā,
uz kuru atsaucas
Tā,
kura atsaucas
Atsaucas uz
2.
Neobligātā 1:M saite
Designer projektējumā
UZVEDNES
PK
U_ID
UZVEDNU_ATSAUCES
PK,FK1
PK,FK2
GALV_UZV_ID
PAKAART_UZV_ID
U_TEKSTS
“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
110