Arnis Kiršners

Pasūtījumu veikšanas datu konceptuālais modelis

Rīga, 2009.

SatursUzdevuma nostādne..............................................................................................3

Ievads....................................................................................................................4

1. Izveidot noteiktu problēmas vidi.................................................................5

2. Datu plūsmas diagrammas izveidošana izveidotajai problēmas videi.........7

3. Konceptuālā datu modeļa izveidošana.........................................................9

4. Boisa koda normālformu pārbaude, nepieciešamības gadījumā veikt

dekompozīciju...........................................................................................16

5. Transformāciju veikšana no EER uz datubāzes loģisko modeli................19

5.1. Unārās saites transformācija...............................................................19

5.2. Binārās saites transformācija..............................................................19

5.2.1. Saites 1:1 transformācijas realizācija.............................................19

5.2.2. Saites 1:N transformācijas realizācija............................................20

5.2.3. Saite N:M (daudzi pret daudziem) realizācija................................20

5.3. Ternārās saites transformācija............................................................21

5.4. Klasifikācijas transformācija..............................................................21

5.5. Superrealitātes transformācija............................................................22

5.6. Vājas saites un mantošanas transformācija........................................22

5.7. ARC jeb XOR transformācija............................................................23

6. DBVS un SQL kods...................................................................................25

7. Secinājumi.................................................................................................30

Izmantotās literatūras saraksts............................................................................31

Uzdevuma nostādne

Izveidot noteiktu problēmas vidi;

Datu plūsmas diagrammas izveidošana izveidotajai problēmas videi;

Konceptuālā datu modeļa izveidošana;

Boisa koda normālformu pārbaude, nepieciešamības gadījumā veikt dekompozīciju;

Transformāciju veikšana no EER uz datubāzes loģisko modeli;

DBVS un SQL kods;

Secinājumi.

3

Ievads

Lai atvieglotu sistēmu analītiķa darbu, informācijas sistēmu (IS) izstrādē var izmantot

dažādus sistēmu analīzes rīkus. Tie ir t.s. CASE (Computer Aided Software Engeneering)

rīki. Sistēmu analīzes rīki ir datoru komplekss, kas ir paredzēts vienā, vairākas vai visos

sistēmas dzīves cikla posmos izmantojamās informācijas atspoguļošanai. CASE rīkus atkarībā

no to pielietojuma var iedalīt kategorijās:

informācijas glabātuves jeb krātuves (repository);

apgrieztās inženierijas rīki.

Informācijas glabātuves ir tādi CASE rīki, kas izveido sava veida enciklopēdiju, sauktu

par CASE repository, kurā tiek glabātas sistēmas diagrammas, datu vārdnīcas, ekrāna un

pārskatu modeļi, procesa loģikas blokshēmas un cita informācija, kas tiek izmantota veidojot

analīzes beigu pārskatu.

Apgrieztās inženierijas rīki ir tādi CASE rīki, kas pamatojoties uz pieejamo

programmatūras kodu, to analizē un izveido tā grafisku modeli, kurā tiek attēlota

programmatūras struktūra, moduļi, to hierarhija un datu vārdnīcas.

Modernie CASE rīki aptver plašu informācijas sistēmu projektēšanas daudzveidīgo

tehnoloģiju apgabalu: no vienkāršiem analīzes un dokumentācijas līdzekļiem līdz pilnīgi

automatizētiem līdzekļiem, kuri nosedz visu programmatūras nodrošinājuma dzīves ciklu.

Informācijas sistēmas izstrādes darbietilpīgākie etapi ir analīze un projektēšana, kuru

laikā CASE rīki nodrošina pieņemamo tehnisko risinājumu kvalitāti un projekta

dokumentācijas sagatavošanu. Liela nozīme ir informācijas vizuālajai demonstrēšanai. Tas

jāsaprot kā struktūras vai cita veida diagrammu veidošanu reālā laika mērogā, daudzveidīgas

krāsu paletes izmantošanu, sintakses noteikumu pārbaudi. Modelēšanas grafiskie līdzekļi ļauj

izstrādātājiem uzskatāmā veidā izpētīt esošo informācijas sistēmu, pārveidot to atbilstoši

uzstādītajiem mērķiem un pastāvošajiem ierobežojumiem.

CASE rīkos tiek iekļauti gan nosacīti lētas sistēmas personālajiem datoriem ar visai

ierobežotām iespējām, gan neviendabīgas skaitļošanas platformas un operāciju vides.

Piemēram, pašreizējais programmēšanas līdzekļu tirgus ietver ap 300 dažādu CASE rīku.

4

1. Izveidot

noteiktu problēmas vidi

Par pamatu dotā darba izveidei, izvēlēsimies problēmas vidi, kas raksturos klienta un

pārdevēja attiecības. Problēmas vide sastāvēs no ārējās pasaules, kuru reprezentēs klients un

vadības informācijas sistēmas, kuru reprezentēs pasākumu komplekss, kas norisinās sistēmas

iekšienē. Izveidotā vadības informācijas sistēma raksturos biznesa procesu, kas ir

izveidojamās datubāzes priekšmets. Biznesa procesa pamatā, ko risinās informācijas vadības

sistēma būs preču pasūtījuma veikšana, kuru pavadīs attiecīgie biznesa procesi, raugoties no

datubāzes izveides viedokļa.

Izveidojamai informācijas vadības sistēmai, aplūkosim trīs biznesa procesus, kuri varētu

būt sekojoši:

pasūtījuma veikšana;

pasūtījuma noformēšana;

pasūtījuma apstiprināšana.

Pasūtījuma veikšana sastāv no pieprasījuma, ko veic klients, nosūtot pieprasījumu

informācijas sistēmai. Tā savukārt fiksē un saglabā datu krātuvē doto pieprasījumu, izveido

un realizē vaicājumu, pārbauda klientu un pasūtījumu, saņem vaicājuma rezultātu, noformē un

nosūta klientam atbildi.

Savukārt pasūtījuma noformēšana sastāv no klienta pasūtījuma noformēšanas, nosūtot

pieprasījumu informācijas sistēmai. Tā savukārt reģistrē un saglabā datu krātuvē doto

pasūtījumu, izveido un realizē vaicājumu, pārbauda klientu un pasūtījumu, saņem vaicājuma

rezultātu, noformē un nosūta klientam atbildi, kā arī reģistrē pasūtījuma statusu datu krātuvē.

Visbeidzot, pasūtījuma apstiprināšanu tiek realizēta, klientam nosūtot, vadības

informācijas sistēmai apstiprinājumu par pasūtījuma veikšanu, dotais apstiprinājums tiek

fiksēts un tā statuss tiek saglabāts datu krātuvē, kā arī izveidots un realizēts vaicājums, tad

pārbauda klientu un pasūtījumu, saņem vaicājuma rezultātu, noformē un nosūta klientam

atbildi, kā arī tiek noformēts pasūtījums un tā statuss par kuru tiek nodota informācijas

uzņēmuma darbiniekam, kas fiksē doto pasūtījumu.

Izveidojamo informācijas vadības sistēmu, varētu raksturot kā trīs vadības ciklus, kurā

norisinās dažādas datu plūsmas, kuras ir parādītas . attēlā. Sākotnēji, 1. cikla ietvaros, klients

izdara pieprasījumu informācijas sistēmai, par viņam interesējošo preci un daudzumu.

Sistēma apstrādā pieprasījumu un nosūta klientam informāciju ar viņam interesējošo

informāciju. Tālāk, 2. cikla ietvaros, klients rediģē un nosūta pasūtījumu informācijas

5

sistēmai, informācijas sistēma apstrādā doto pieprasījumu, nosūtot pasūtījumu klientam

apstiprināšanai. Sistēma reģistrē pasūtījuma statusu «Iesniegts» datu krātuvē, kā arī nosūta

doto pasūtījumu un pasūtījuma statusu «Iesniegts» uzņēmuma darbiniekam, kas atbildēs un

kontrolēs dotā pasūtījuma tālāku virzību informācijas sistēmā, līdz dotais uzdevums būs

pilnībā izpildīts. Pēdējā 3. cikla ietvaros, klients nosūta informācijas sistēmai pasūtījuma

apstiprinājumu, informācijas sistēma reģistrē datu krātuvē doto pasūtījumu, nomainot tā

statusu uz «Apstiprināts», par ko tiek nosūtīta informācijas attiecīgajam uzņēmuma

darbiniekam, kas uzrauga doto pasūtījumu.

1. att. Problēmas vides ārējās vides un vadības informācijas sistēmas mijiedarbība

Pirmo ciklu aktivizē klients (nospiežot taustiņu), tādā veidā nosūtot informācijas

sistēmai pieprasījumu, no kuras saņem atbildi un klientam nosūtītā dokumenta statuss ir

«Iesniegts». Otrajā ciklā, klients koriģē pasūtījumu, ja tas ir nepieciešams un nosūta to atpakaļ

(nospiežot taustiņu) informācijas sistēmai, informācijas sistēma dokumentu nosūta

darbiniekam, kas būs atbildīgs par dotā pasūtījuma nodrošināšanu un piešķir dokumentam

statusu «Apstiprināts». Trešajā ciklā informācijas sistēma sagatavoto dokumentu nosūta

klientam to apstiprināt, klients apstiprina doto dokumentu (nospiežot taustiņu) un informācijas

sistēma dokumentam piešķir statusu «Izpildīts». Aprakstītie cikli attēlo informācijas sistēmas

biznesa procesu norisi, pielietojot datubāzu struktūras to realizācijā.

6

2. Datu

plūsmas diagrammas izveidošana izveidotajai problēmas videi

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ā saistība

un noteikti funkciju ieejas un izejas dati. Funkcijas raksturo datu pārveidojumus.

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

Datu plūsmas diagramma sniedz pilnīgu pārskatu par projektējamās sistēmas

funkcionalitāti un datiem. Funkcionalitāte raksturo biznesa procesu norisi.

Datu plūsmas diagrammā tiek izmantoti sekojoši elementi:

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

Lai varētu izprast vadības informācijas sistēmā notiekošos biznesa procesus ir jāizveido

datu plūsmas diagramma, lai varētu grafiski izprast procesa būtību un modelī notiekošo datu

plūsmu, izveidoto datu plūsmu diagrammu skatīt . attēlā. Par apzīmējumiem, kas izmantoti

plūsmas diagrammā:

D1 – D4 – raksturo datu plūsmu informācijas sistēmā un starp mijiedarbības

vidēm;

F1 – F17 – raksturo funkcijas, ko izpilda informācijas sistēma;

V1 – V2 – raksturo vaicājumus, kurus izpilda informācijas sistēma;

DK1 – DK4 – datu krātuves, kurās tiek veikta informācijas uzglabāšanas par

datu kustību attiecīgajos procesos ;

A1, A3 – atbildes noformēšana informācijas sistēmas iekšienē;

A2, A4 – atbildes noformēšana lietotājiem ārējā vidē.

Datu plūsmas apraksts.

D1: preces tips; kods; skaits; pasūtītāja dati un kontakti;

V1: D1, atlikuma dati, statusa dati, pasūtījuma datums;

A1: D1, atlikuma dati, statusa dati, pasūtījuma datums, dokumenta statuss;

A2: pasūtījums (D1, atlikuma dati, statusa dati, pasūtījuma datums), dokumenta statuss;

D2: pasūtījums (preces tips un skaits)

D3: pasūtījums (preces tips un skaits), pasūtījuma datums;

7

V2: pasūtījums (preces tips un skaits), pasūtījuma datums;

A3: pasūtījums (preces tips un skaits), pasūtījuma datums; pasūtījuma statuss;

A4: pasūtījums (preces tips un skaits), pasūtījuma datums; pasūtījuma statuss; klienta dati;

D4: pasūtījums (preces tips un skaits).

2. att. Datu plūsmas diagramma definētajai problēmas videi

8

3. Koncept

uālā datu modeļa izveidošana

Ņemot par pamatu datu plūsmas diagrammu, kas apraksta sekojošus biznesa procesus:

pasūtījuma veikšana; pasūtījuma noformēšana un pasūtījuma apstiprināšana, var uzsākt

konceptuālā modeļa izstrādi, pamatojoties un P. Čena notāciju. Jaunizveidojamam modelim ir

jāsatur sekojoši elementi:

unārā saite (piemēram: daudziem darbiniekiem ir viens priekšnieks), skatīt 3. attēlu;

3. att. Unārā saite

binārā saite, skatīt 4. attēlu;

4. att. Binārā saite

ternārā saite, skatīt 5. attēlu;

5. att. Ternārā saite

klasifikācija, skatīt 6. attēlu;

6.att. Klasifikācija

9

vāja realitāte (piemēram: R1 – mācību priekšmets; R2 - atzīme; R3 - students);

7. att. Vāja realitāte

mantošana, skatīt 8. attēlu;

8. att. Mantošana

superrealitāte, , skatīt 9. attēlu ;

9. att. Superrealitāte

izslēdzošais OR (XOR) , skatīt 10. attēlu.

10

10. att. Izslēdzošais OR

11

11. att. EER diagramma

12

Kopējā EER diagrammas shēma ir parādīta 11. attēlā. Ar dažādu krāsu taisnstūriem ir

iezīmēti darbā izveidotie saišu tipu. Dotā diagramma realizē iepriekšējā nodaļā aprakstītos

biznesa procesus. EER diagramma attēlo datu plūsmu informācijas sistēmā. Ar dažādu saišu

palīdzību tiek realizēta mijiedarbība starp dažādām datu struktūrām informācijas sistēmā.

Turpinājumā tiks padziļināti aplūkots, katrs no saišu tipiem. Unārā saite, kas parādīta .

attēlā, raksturo realitāti «DARBINIEKS», kur viens no darbiniekiem ir priekšnieks,

12. att. Unārās saites realizācija

visiem darbiniekiem dotajā realitātē. Saiti raksturo attiecība 1:N (viens priekšnieks vairākiem

darbiniekiem).

Bināro saiti raksturo attiecības starp divām neatkarīgām realitātēm «PASŪTĪJUMS»

un «KLIENTS», skatīt . attēlu. Saites starp realitātēm var pastāvēt ar attiecībām 1:1, 1:N vai

N:1. No dotās saites izriet, ka vienam pasūtījuma var būt viens pasūtītājs – klients.

13. att. Binārās saites realizācija

13

Ternārā saite tiek realizēta starp trim realitātēm, skatīt . attēlu. Dotajā darbā ternārā saite

ir realizēta starp realizācijām «DARBINIEKS», «ARODS» un «ALGA», pielietojot attiecības

starp 1:1. Realitātes savā starpā sadarbojas ar saišu tabulu. Ternārā saite nosaka, ka

14. att. Ternārās saites realizācija

realitātei «DARBINIEKS» ir sasaiste ar realitātēm «ARODS» un «APJOMS». Šī sadarbība

nosaka, ka darbiniekam ar vārdu uzvārdu un personas kodu un noteiktu vadītāju ir alga ar

noteiktu apjomu un amats, kuru darbinieks pilda no noteikta līdz noteiktam datumam.

Klasifikāciju raksturo realitātes «KLIENTS» sadalījums, kur realitātes atribūtu

vērtības sadalās realitātēs vai lomās «JURIDISKA PERSONA» UN «FIZISKA PERSONA»,

klasifikācijas realizāciju, skatīt . attēlu. Izšķir divus klasifikācijas veidus pilno un nepilno

klasifikāciju. Doto gadījumu varētu raksturot, kā pilno klasifikāciju. Nepilnā klasifikācija

būtu, ja realitāte students tiktu sadalīta neklātienes un dienas nodaļas students, bet nebūtu

vakara nodaļas studenta.

15. att. Klasifikācijas realizācijas

14

Superrealitāte raksturo divu vai vairāku realitāšu apvienojumu, no kurām tiek veidota

viena vesela realitāte, skatīt . attēlu. Šajā piemērā superrealitāte «DARBINIEKA

DOKUMENTI» apvieno realitātes «PASES DATI» un «NODOKĻU GRĀMATIŅAS DATI»

ar saviem atribūtiem, nodrošinot realitātei «DARBINIEKI» darbinieka dokumentu kopumu,

kas nepieciešams darbiniekam pildot savus pienākumus. Superrealitātes realizāciju fiziskajā

modelī ir iespējams realizēt skata veidā, apvienojot realitātes «PASES DATI» un

16. att. Superrealitātes realizācija

«NODOKĻU GRĀMATIŅAS DATI», kas paātrina datu apmaiņu vaicājumos un sistēmas

drošību, jo kā zināms, tad caur skatu nav iespējams veikt iejaukšanos tabulu struktūrā.

Savukārt ARC elements EER diagrammā nosaka izvēli, kas notiek izvēloties vienu un

tikai vienu realitāti tālāka procesa realizācijai, skatīt . attēlu. ARC elementu no loģiskās

programmēšanas saprotam ar operatoru «IF», bet no Būla algebras ar XOR – izpildās tikai

17. ARC saites realizācija

15

viens no visiem. Šajā piemērā dokumentam tiek piešķirts viens noteikts statuss, ko nodrošina

ARC funkcija. Dokumentam var piešķirt realitātes ar sekojošiem statusiem: «IESNIEGTS»,

«APSTIPRINĀTS» un «IZPILDĪTS».

Pēdējā no shēmām, skatīt . attēlu, apskatīsim vājās realitātes realizāciju un mantošanu.

Vājā realitāte ir realizēta starp realitātēm «PRODUKTS», «ATLIKUMS» un «PRECE». Vājā

realitāte ir «PRECE», kas blokshēmā ir attēlota ar dubulttaisnstūri. No realizācijas viedokļa

raugoties, vājai realitātei nav primārās atslēgas, savukārt to saišu realitātēm tādas eksistē.

Mantošana ir realizēta līdzīgā veidā, kad no realitātes «PRODUKTS» atribūtiem, realitātē

«PRECE» tiek izmantots jeb mantots atribūts «Tips», bet no realitātes «ATLIKUMS», tiek

mantots jeb izmantots atribūts «Atlikums», šādi izveidojot realitāti «PRECE», kur pievienojot

vēl atribūtus: skaits, artikuls un cena, izveidojot pilnīgu realitāti «PRECE», kuru var

pilnvērtīgi pielietot izveidojamajā informācijas sistēmā.

18. att. Vājas saites un mantošanas realizācija

16

4. Boisa

koda normālformu pārbaude, nepieciešamības gadījumā veikt

dekompozīciju

Kad EER diagramma ir izveidota ar iekļautajām visām nepieciešamajām datu

struktūrām, kas tika definētas uzdevumu nostādnē un datu loģiskais modelis ir pilnībā

nodefinēts, var uzsākt Boisa koda normālformas pārbaudi.

Boisa koda normālformu pārbaudi iedala sekojoši:

pirmā normālforma (1NF);

otrā normālforma (2NF);

trešā normālforma (3NF);

Boisa koda normālforma (BKNF).

Boisa koda 1NF raksturo domēnu atribūtu vērtību nedalāmība. Veidojot jaunas tabulas ir

jāaplūko visu izveidojamo tabulu domēnu atribūtu vērtības, lai tās būtu nedalāmas. Boisa

koda 2NF ir tad, ja eksistējot 1NF katrs neprimārās atslēgas lauks ir pilnīgi funkcionāli

atkarīgs no primārās atslēgas. Savukārt Boisa koda 3NF ir, ja pastāv 2NF un katrs neprimārās

atslēgas lauks ir netransitīvi atkarīgs no primārās atslēgas un visbeidzot, ja izpildās 3NF un

katrs determinants ir iespējamā primārā atslēga, tad izpildās BKNF.

Lai labāk izprastu, kā jāpielieto Boisa koda normālformas, EER diagrammu vēlam

pārveidot par loģisko shēmu, skatīt . attēlu.

19. att. Loģiskā shēma

17

Loģiskā shēma ir starp posms, transformācijas izveidei starp EER un datubāzes

loģisko modeli. Kā redzams no . attēla, tad realitātes un to atribūti ir transformēti nosacītos

blokos, kuru apvienojumu raksturo realitātes nosaukums, bet blokus realitātē – atribūtu

nosaukumi. Pasvītrotie atribūtu nosaukumi norāda uz attiecīgās realitātes primāro atslēgu. Ar

bultām ir norādīta realitāšu sasaiste savā starpā un datu pieprasījuma virziens realitātē, kas

vēlāk transformācijas rezultātā tiks realizēts datubāzes loģiskajā modelī, norādot saites starp

tabulām.

Katra no pārveidotajām realitātēm ar to atribūtu nosaukumiem ir jāanalizē atsevišķi

viena no otras. Aplūkojot . attēlu, redzams, ka abas realitātes atbilst Boisa koda normālformai

un atribūts «Atlikums» realitātē «PRECE» ir jau atdalīts atsevišķa realitātē «ATLIKUMS»,

tāpēc dotās realitātes atbilst Boisa koda NF prasībām.

20. att. Realitāte «PRECE» un «ATLIKUMS»

Realitāte «PASUTIJUMS» atbilst Boisa koda NF prasībām, jo atribūti «Klients»,

«Past_Nr», «Darbinieks» un «Status» ir izdalītas atsevišķās realitātēs, skatīt . attēlu.

21. att. Realitāte «PASUTIJUMS»

22. att. Realitāte «KLIENTI»

18

Arī realitāte «KLIENTS» ar klasifikācijas palīdzību tiek sadalīta realitātē «Fiziska persona»

un «Juridiska persona», tādā veidā nodrošinot Boisa koda NF izpildi, skatīt . attēlu. Līdzīga

situācija ir izveidojusies arī realitātē «DARBINIEKS», kura tiek sadalīta realitātēs

«APJOMS», «AMATS» un realitāte «DARBINIEKA DATI», kura realizētas ar skatu

palīdzību, skatīt . attēlu.

23. att. Realitātes «DABINIEKS, «APJOMS» un «AMATS»

Kā pēdējo no visām realitātēm aplūkosim realitāti «PRODUKTS», kas sastāv no

atribūtu laukiem «Tips», «Zīmols», «Krāsa» un «Izmērs», skatīt . attēlu. Tā kā vienam kodam

var eksistēt vairākas krāsas un dažādi izmēri, tad Boisa koda NF pārbaude nonāk pretrunā un

ir jāveic realitātes dekompozīcija, lai izvairītos no neatbilstības. Pārveidotās realitātes, kas

atbilst BKNF var aplūkot . attēlā.

24. att. Realitāte «PRODUKTS»

25. att. Realitāte «PRODUKTS» pēc Boisa koda NF pielietošanas

19

5. Transfor

māciju veikšana no EER uz datubāzes loģisko modeli

Kad ir izveidota EER diagramma un pārbaudīta izveidojamo tabulu atbilstība Boisa

koda normālformām, turpinājumā var veidot datu loģisko modeli. Izklāsta turpinājumā

apskatīsim detalizēti, uzdevumā definēto saišu transformāciju.

5.1. Unārās saites transformācija

Dotā saite realizē nosacījumu, ka noteiktai darbinieku grupai, realitātei darbinieks ir

viens priekšnieks, kas realizēts unārās saites veidā. Transformācijas rezultātā tiks iegūta

tabula «DARBINIEKI», kuras transformāciju struktūra parādīta . attēlā. Dotās saites

attēlošanai tiks izmantota ER diagramma, jo loģiskais modelis izvēlētajā programmā neattēlo

unārās saites sasaisti.

20

21

5.2. Binārās

saites transformācija

Binārā saite ir visplašāk pielietojamai saišu tips datubāzu struktūrās. Ar dotajām saitēm

tiek realizētas sasaistes starp tabulām, pielietojot saišu tipus 1:1(viens pret vienu), 1:N(viens

pret daudziem) un N:M(daudzi pret daudziem). Saite N:M gadījumā tabulu sasaistei lieto

starptabulas primāro atslēgu sasaistei.

5.2.1. Saites 1:1 transformācijas

realizācija

Dotajā

saitē ir realizēta

attiecība 1:1, starp realitātēm klients un pasūtījums, jo vienam pasūtījumam var būt viens

klients un pretēji. Transformācijas rezultātā tiek iegūtas tabulas «PASUTITAJI» un

«KLIENTI», kas savstarpēji realizē doto saiti, skatīt . attēlu.

5.2.2. Saites 1:N transformācijas

realizācija

Saite tiek realizēta starp realitātēm produkts un prece, kas norāda, ka vienā precē ietilpst

vairāki produkti, kas transformācijas rezultātā tiek pārvērstas par tabulām «PRODUKTI» un

«PRECES». Saites realizācija tiek veikta tabulā «PRODUKTI» atribūtam «Kods» piešķirot

26. att. Unārās saites transformācija

27. att. Binārās saites 1:1 transformācija

22

primāro atslēgu, bet tabulā «PRECES», atribūtam «Produkts», norādot sekundāro atslēgu un

atsauci uz tabulas «Produkti» primāro atslēgu, realizāciju skatīt . attēlā.

23

5.2.3. Saite N:M (daudzi pret daudziem)

realizācija

Dotās saites realizācija ir veikta starp realitātēm prece un pasūtījums, kas norāda, ka

vienā pasūtījumā var eksistēt dažāda prece un otrādi – daudzos pasūtījumos dažāda prece.

Transformācijas rezultātā tiek iegūtas tabulas «PRECES» un «PASUTIJUMI», lai realizētu

saiti N:M ir nepieciešamība veidot starp tabulu ar nosaukumu «SASTAV», kurā tiek

realizētas savstarpējās saites starp tabulām. Tabulā «SASTAV» ir abu sasaistošo tabulu

primārās atsauces, bet tabulās «PRECES» un «PASUTIJUMI» sekundārās atslēgas ar norādi

uz tabulas «SASTAV» primārajām atslēgā, realizāciju skatīt . attēlā.

29. att. Binārās saites N:M realizācija

5.3. Ternārās saites transformācija

Ternārā saite ir realizēta starp trim realitātēm darbinieks, alga un arods savstarpēji

sasaistot tās ar saitēm 1:1. Transformācijas rezultātā tiek iegūtas tabulas «DARBINIEKI»,

«ALGAS» un «ARODI», sasaisti starp tabulām, kas ir ternārā saite, nodrošina starptabula

«PASTAV», kurā atrodas savienoto tabulu sekundārās atslēgas, ar atsauci uz savienotajām

tabulām, kurās glabājas primārās atslēgas, realizāciju skatīt . attēlā.

28. att. Binārās saites 1:N realizācija

24

5.4. Klasifikācijas transformācija

Klasifikācija ir realizēta realitātē klients apvienojot realitātes juridiska persona un

fiziska persona, transformācijas rezultātā tika iegūta tabulas «KLIENTI», «J_PERSONAS»

un «F_PERSONAS». Klasifikācija ir tabulas «KLIENTI» sadalīšana daļās, kur viena daļa

glabājas tabulā », «J_PERSONAS» , bet otra - «F_PERSONAS». Klasifikācijas saites

realizāciju, skatīt . attēlā.

31. att. Klasifikācijas transformācija

30. att. Ternārās saites transformācijas realizācija

25

5.5. Superrealitātes transformācija

Superrealitāte ir realitāšu pases dati un nodokļu grāmatiņas dati apvienojums vienā

realitātē darbinieka dokumenti. Transformācijas rezultātā tiek izveidotas tabulas «P_DATI»

un «N_DATI», savukārt superrealitāte tiek izveidota pielietojot skatu «DAR_DOK», kurā ir

apvienota informācija no abām izveidotajām tabulām. Superrealitātes realizāciju, skatīt .

attēlā.

Diemžēl izvēlētā programma neattēlo sakarības starp tabulām un to skatu apvienojumiem.

5.6. Vājas saites un mantošanas transformācija

Dotās saites realizācija ir veikta starp realitātēm produkts, atlikums un prece.

Transformācijas rezultātā iegūstam tabulas «PRODUKTI», «ATLIKUMI» un «PRECES».

Vājā saite norāda uz to, ka tabulā «PRECES» nav primārās atslēgas. Šī tabula ar pārējām tiek

sasaistīta ar sekundārajām atslēgām un saiti uz citu tabulu primārajām atslēgām. Tāpat starp

šīm tabulām arī ir realizēta mantošana, jo tabula «PRECES» manto no tabulas «PRODUKTI»

atribūtu «Tips» un no tabulas «ATLIKUMI» atribūtu «Atlikums». Vājās saites un mantošanas

transformācijas rezultātus, skatīt . attēlā.

32. att. Superrealitātes transformācija

26

5.7. ARC jeb XOR transformācija

ARC saite realizē realitātei statuss vērtības piešķiršanu, pie tam tikai vienu no trim.

Transformācijas rezultātā tiek iegūtas tabulas «PASUTIJUMI», kura laukam statuss, tiek

piesaistīta tabula «STATUSS» ar kuras palīdzību notiek, vienas no izvēlētās, vērtības

piesaiste. Transformācijas realizāciju, skatīt . attēlā.

33. att. Vājās saites un mantošanas transformācija

34. att. ARC transformācijas realizācija

27

Kopējo loģisko modeli ar visiem transformāciju veidiem un informācijas sistēmā

iekļautajām realitātēm, skatīt . attēlā. Diemžēl pielietojamā lietojumprogramma nenodrošina

divu tabulu attēlojumu skatā, tāpēc dotās transformācijas nav loģiskajā modelī.

28

35. att. Realitāšu transformācija loģiskajā modelī

29

6. DBVS un

SQL kods

Dotajā nodaļā tiks apskatīts transformāciju rezultātā iegūto datu ievade DBVS, veidojot

informācijas sistēmu un tajā nodrošinot biznesa procesu izpildi un datu plūsmu. Sākumā tiek

veidotas tās tabulas, kuras hierarhijā atrodas pašā apakšējā līmenī. Izveidotas tiek tabulas

«KRASAS» un «IZMERI» iekļaujot tajās primārās atslēgas, bet tabulā «PRODUKTI»

norādot sekundārās atsauces uz šīm tabulām. Līdzīgi veidojam tabulas «ATLIKUMI» un

«PRECES»; «ARODI», «AMATI» un «DARBINIEKI», bet tabulā «DARBINIEKI», bez

visām jau iepriekšminētajām darbībām ir jānorāda atsauce pašai uz sevi, tas nozīmē, ka tabulā

«DARBINIEKI» ir vadītājs jeb priekšnieks, kurs vada attiecīgo darbinieku grupu. Savukārt

tabulā «PASTAV», kas ir saites tabula un realizē ternāro saiti, tiek norādītas atsauces uz

sasaistītajām tabulām un šo tabulu primāro atslēgu unikalitāte. Turpinājumā ir parādītas

tabulu izveides principi, lietojot SQL kodu un DBVS. Realizācija tika veikta Toad 8.5 vidē,

par DBVS izmantojot Oracle 10g.

Tabulas «KRASAS» izveide:CREATE TABLE KRASAS(KRASA NVARCHAR2(15) PRIMARY KEY,KR_NR NUMBER(2))

Tabulas «IZMERI» izveide:CREATE TABLE IZMERI(IZMERS NVARCHAR2(5), GARUMS NVARCHAR2(5),CONSTRAINT IZ_PK PRIMARY KEY (IZMERS, GARUMS))

Tabulas «PRODUKTI» izveide:CREATE TABLE PRODUKTI(KODS NUMBER PRIMARY KEY,TIPS NVARCHAR2(10),ZIMOLS NVARCHAR2(15),KRASA NVARCHAR2(15),IZMERS NVARCHAR2(5),GARUMS NVARCHAR2(5),CONSTRAINT IZ_FK FOREIGN KEY(IZMERS,GARUMS) REFERENCES IZMERI(IZMERS,GARUMS) ON DELETE CASCADE,CONSTRAINT KR_FK FOREIGN KEY(KRASA) REFERENCES KRASAS(KRASA)ON DELETE CASCADE)

Tabulas «PRECES» izveide:CREATE TABLE PRECES(PAS_NR NUMBER,PRODUKTS NUMBER,ATLIKUMS NUMBER,SKAITS NUMBER(6),CENA NUMBER(8,2),

30

FOREIGN KEY(PAS_NR,PRODUKTS) REFERENCES SASTAV(PAS_NR,PRODUKTS) ON DELETE CASCADE,FOREIGN KEY(ATLIKUMS) REFERENCES ATLIKUMI(ATLIKUMS) ON DELETE CASCADE,FOREIGN KEY(PRODUKTS) REFERENCES PRODUKTI(KODS)ON DELETE CASCADE)

Tabulas «ATLIKUMI» izveide:CREATE TABLE ATLIKUMI(ATLIKUMS NUMBER PRIMARY KEY,ATLAIDE NUMBER(3))

Saites tabulas «SASTAV» izveide:CREATE TABLE SASTAV(PAS_NR NUMBER,PRODUKTS NUMBER,PRIMARY KEY(PAS_NR, PRODUKTS))

Tabulas «ARODI» izveide:CREATE TABLE ARODI(ATMATS VARCHAR2(15) PRIMARY KEY,DAT_NO DATE,DAT_LIDZ DATE)

Tabulas «AMATI» izveide:CREATE TABLE ALGAS(APJOMS NUMBER(6,2) PRIMARY KEY)

Tabulas «DARBINIEKI» izveide:CREATE TABLE DARBINIEKI(PER_KODS NVARCHAR2(12) PRIMARY KEY,VARDS NVARCHAR2(12),UZVARDS NVARCHAR2(15),PRIEK NVARCHAR2(12)NOT NULL,D_DATI NVARCHAR2(100),FOREIGN KEY (PRIEK) REFERENCES DARBINIEKI) – unārās saites realizācija

Saites tabulas «PASTAV» izveide:CREATE TABLE PASTAV(PER_KODS NVARCHAR2(12),AMATS VARCHAR2(12),APJOMS NUMBER(6,2),PRIMARY KEY (PER_KODS, AMATS),FOREIGN KEY (PER_KODS) REFERENCES DARBINIEKI ON DELETE CASCADE,FOREIGN KEY (AMATS) REFERENCES ARODI ON DELETE CASCADE,FOREIGN KEY (APJOMS) REFERENCES ALGAS ON DELETE CASCADE,UNIQUE (PER_KODS, APJOMS),UNIQUE (AMATS, APJOMS));

Tabulas «PASUTIJUMI» izveide:CREATE TABLE PASUTIJUMI(KLIENTS INTEGER,PAS_NR NUMBER,PRODUKTS NUMBER,SUMMA NUMBER(8,2),DATUMS DATE,DARB NVARCHAR2(12),STATUSS NVARCHAR2(12),FOREIGN KEY (PAS_NR,PRODUKTS) REFERENCES SASTAV(PAS_NR,PRODUKTS) ON DELETE CASCADE,FOREIGN KEY (KLIENTS) REFERENCES KLIENTI (KLIENTS) ON DELETE CASCADE,FOREIGN KEY (DARB) REFERENCES DARBINIEKI (PER_KODS) ON DELETE CASCADE,FOREIGN KEY (STATUSS) REFERENCES STATUSS(STATUSS) ON DELETE CASCADE)

31

32

Tabulas «KLIENTI» izveide:CREATE TABLE KLIENTI(KLIENTS INTEGER PRIMARY KEY,NOSAUKUMS NVARCHAR2(30),ADRESE NVARCHAR2(50),REG_NR NVARCHAR2(15),VARDS NVARCHAR2(15),UZVARDS NVARCHAR2(20),PER_KODS NVARCHAR2(12),CONSTRAINT J1_PER FOREIGN KEY (NOSAUKUMS, ADRESE, REG_NR) REFERENCES J_PERSONAS (NOSAUKUMS, ADRESE, REG_NR) ON DELETE CASCADE,CONSTRAINT F1_PER FOREIGN KEY (VARDS, UZVARDS, PER_KODS) REFERENCES F_PERSONAS (VARDS, UZVARDS,PER_KODS) ON DELETE CASCADE)

Tabulas «F_PERSONAS» izveide:CREATE TABLE F_PERSONAS(VARDS NVARCHAR2(15),UZVARDS NVARCHAR2(20),PER_KODS NVARCHAR2(12),CONSTRAINT F_PER PRIMARY KEY (VARDS, UZVARDS, PER_KODS))

Tabulas «J_PERSONAS» izveide:CREATE TABLE J_PERSONAS(NOSAUKUMS NVARCHAR2(30),ADRESE NVARCHAR2(50),REG_NR NVARCHAR2(15),CONSTRAINT J_PER PRIMARY KEY (NOSAUKUMS, ADRESE, REG_NR))

Tabulas «STATUSS» izveide

CREATE TABLE STATUSS(STATUSS NVARCHAR2(12) PRIMARY KEY)

Tabulas «P_DATI» izveide

CREATE TABLE P_DATI(P_ID NUMBER PRIMARY KEY,NUMURS NVARCHAR2(9),PILSONIBA NVARCHAR2(20),DERIGA DATE)

Tabulas «N_DATI» izveide

CREATE TABLE N_DATI(N_ID NUMBER PRIMARY KEY,NUMURS NVARCHAR2(9),RAJONS NVARCHAR2(50),TER_KODS NVARCHAR2(9))

Skata «DAR_DOK» izveide

CREATE VIEW DAR_DOK ASSELECT A.NUMURS, A.PILSONIBA, A.DERIGA, B.RAJONS, B.TER_KODSFROM P_DATI A, N_DATI BWHERE A.P_ID=B.N_ID

33

Tabulā «KLIENTI» ir realizēta klasifikācija, tas nozīmē, ka klienti tiek sadalīti divās

grupās: fiziskās un juridiskās personas. Tādā veidā tabulas «KLIENTI» dati tiek saklasificēti

attiecīgajās klasifikācijas grupās ar tabulu nosaukumiem «J_PERSONAS» un

«F_PERSONAS». Tabulā «STATUSS» ir izveidotas trīs vērtības, kas norāda uz dokumenta

izpildes statusu. Tabulas «N_DATI» un «P_DATI» ir realitāšu nodokļu grāmatiņas dati un

pases dati pārveidojums fiziskajās tabulās. Dotās tabulas dati tiek apvienoti ar skata

«DAR_DOK» palīdzību, kas rezultātā attēlo darbinieka dokumentus.

Starp tabulām « PASUTIJUMI» un «PRECES» ir realizēta saite dauzi pret daudziem

(N:M), tas nozīmē ka eksistē dažādi pasūtījumi ar dažādu precu klāstu tajos. Tāpēc sasaiste

starp dotajām tabulām tiek realizēta ar starp tabulas «SASTAV» palīdzību, kurā saišu veidā

norāda sasaistes laukus (atribūtus).

Tabulu izveidē tika plaši izmantota konstrukcija ON DELETE CASCADE vai ON UPDATE

CASCADE, kas nozīmē ierakstu automātisku dzēšanu vai atjaunošanos sasaistītajās tabulās.

Realitāšu transformācijā tika izmantotas sapārotas primārās atslēgas, definējot tās, tika

pielietota dažāda definēšanas tehnika. Izmantots arī tika ierobežošanas lauka definējumi.

Savukārt tabulā «PASUTIJUMI» ir apkopota visa informācija par pasūtījumu un no šīs

tabulas var nokļūt uz jebkuru citu tabulu dotajā informācijas sistēmā. Kopējā informācijas ER

diagramma ir parādīta . attēlā.

Fiziskajā datu modelī nav realizācijas saites starp tabulu «DARBINIKI» atribūtu

«D_Dati» un skatu «DAR_DOK», jo nav iespējams skatu piesaistīt atribūtu laukam

izmantojot kādu no sasaistes veidiem, tāpēc izveidoto pastāvošo realitāšu savienojumu, reālos

dzīves apstākļos būtu nepieciešams aizstāt ar citu saišu tipu.

34

36. att. ER diagramma jeb fiziskais datu modelis

35

7. Secināju

mi

Šajā darbā autors realizēja informācijas sistēmu, kurā norisinās biznesa procesi, kas

mijiedarbojas ar ārējo vidi. Informācijas sistēmā notiek datu apmaiņa starp dažādām datu

bāzes struktūrām, kuras ir realizētas dotajā darba izklāstā. Atšķirībā no iepriekšējo DBVS

kursiem, kur izveidojamie darbi bija kaut kā konteksts, tad dotā darba autors centās realizēt

reālu sistēmu, kura ir ļoti pietuvināta reāliem apstākļiem.

Tā kā katram datubāzu sistēmu projektētājam ir savs redzējums, tad arī darba autors

pieturējās pie saviem uzskatiem, un projektējot doto sistēmu sāka ar citu pieeju dotajai

problēmai, nevis pa punktiem, kas definēti uzdevuma nostādnē. Citiem vārdiem sakot, sistēma

tika sākta projektēta no vidus, reāli iztēlojoties sistēmas fizisko uzbūvi. Kā arī pielietojot

pieredzes zināšanas, veidojot realitātes neiekļaujot tajās pārāk daudz atribūtu. Rezultātus šādai

pieejai ilgi nebija jāgaida, jo kad tika analizētas Boisa koda normālformas, izrādījās, ka

izveidotajā sistēmā pastāv tikai viena realitāte, kas neatbilst Boisa koda normālformu

prasībām. Ko pārveidot par vairākām realitātēm, pielietojot dekompozīciju, lielas problēmas

nesagādāja. Runājot par Boisa koda normālformu pārbaudi, darba autors nu nekādi nevarēja

iztikt bez loģiskās shēmas, kas parādīta izklāsta 4 nodaļā, jo izveidojot to un iezīmējot

primārās atslēgas, un saites starp realitātēm, ļoti uzskatāmi ir redzamas jaunizveidojamo

(dekompozīcijas rezultātā) tabulu struktūras, tādā veidā arī vizuāli var redzēt nepieciešamību

pēc realitāšu dekompozīcijas.

Tā kā darbā bija jārealizē noteiktas saišu grupas, tad nācās piestrādāt, lai prasības varētu

realizēt dzīvē. Ja, protams, nebūtu ierobežojumi, kas saistīti ar noteiktu saišu pielietošanu,

darbu varētu paveikt ātrāk, sarežģītākas saišu kombinācijas aizstājot ar vienkāršākām, jeb

izveidojot nedaudz savādākas realitāšu struktūras, kas realizē vienus un tos pašus uzdevumus.

Runājot par saišu tipiem jāatgriežas pie ARC saites definējuma, jo šī darba ietvaros

realizētā ARC saite īsti neatbilst lekcijās piedāvātajām struktūrām, kā arī realizēt šo saiti ar

virknes palietošanu dotajā problēmas sfērā ir neefektīvi. Virknes ģenerē arvien jaunus

primārās atslēgas, kas dotajā realizācijā pilnīgi nav nepieciešams, jo pastāv trīs un tikai trīs

vērtības, no kurām lietotājam ir jāizvēlas viena. Tāpēc darba autors, uzskata, ka lietderīgāk

būtu izmantot trigerus, vismaz dotā darba ietvaros, jo ar tiem varētu efektīvi norealizēt doto

problēmu. Tā kā darba ietvaros netika prasītas tāda tipa realizācijas, tad darba autors trigeru

uzbūves principus sīkāk neapskatīja ARC problēmas risināšanai.

36

Kā jau tika minēts darba izklāstā tad vienīgā saite, kas netika realizēta, lai dotā

informācijas sistēma pilnvērtīgi strādātu ir skata, kas apraksta darbinieka dokumentu kopumu,

saites savienojums ar tabulu «Darbinieki», jo dotajai tabulai nav iespējams piesaistīt skatu,

kuram nav primārās atslēgas.

Lai varētu izprojektēt datubāzi, sākotnēji ir jābūt datu plūsmas diagrammai un EER

diagrammai ar realitāšu attiecībām. Jo tikai viss dotais kopums nodrošinās pilnvērtīgu

datubāzes satura definēšanu. Beigās izveidotajam gala produktam ir jāatbilst saturiski

izvirzītajai problēmas vides informācijas struktūrai, datubāzes satura vienkāršībai, lai to spētu

interpretēt citi projektā iesaistītie izstrādātāji, precīzi definētām saitēm starp datiem un

jāizslēdz datu dublēšanos.

37

Izmantotās literatūras saraksts

1. Prof. Jānis Eiduks «Lekciju konspekti» - 2009

2. J. Perry, G.Post «Introduction to Oracle 10g» - 2006, Pearson Prentice Hall, 698 p.

3. Scoot Urman, Ron Hardman, Michael McLaughlin «Oracle Database 10g PL/SQL

Programming» - 2004, Oracle press, 792 p.

4. Narayan S. Umanath, Richard W. Scamell «Data modeling and database design» -

2007, Thomson course tehnology, 698 p.

5. Teorey T., Lightstone S., Nadeau T. Database modeling and design – 2006, Morgan

Kaufmann Publisher, 275 p.

38