1. uzdevuma nostādne - web vieweizmantojot case rīkus. praktiskais darbs nr. 1. mācību...

RĪGAS TEHNISKĀ UNIVERSITĀTE

Datorzinātnes un informācijas tehnoloģijas fakultāte

Informācijas tehnoloģijas institūts

Datu bāzes struktūras projektēšana neizmantojot CASE rīkus

Praktiskais darbs Nr. 1

mācību priekšmetā

Informācijas sistēmas un CASE rīki

I DMI0 – 1

Jūlija Avdejeva

St. apl. Nr. 051RDB083

Rīga-2009.g.

1. Uzdevuma nostādne

1. Jāizdomā noteikta problēmu vide;

2. Datu plūsmas diagrammas veidošana (Dati un funkcijas);

3. Konceptuāla datu modeļa izveidošana. EER diagramma;

3.1. Boisa-koda normalkoda pārbaude;

4. Transformāciju veikšana no EER DB. Loģiskais modelis (RDB, RODB);

5. DBVS - Access, Oracle, DB2 SQL create vaicājumu kodi;

6. Secinājumi.

1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki”

Saturs

1. Uzdevuma nostādne.......................................................................2

2. Priekšmetiskas vieds modeļa iegūšana (Datu Plūsmas Diagramma).......................................................................................5

3. Konceptuālais modelis (EER moduļa veidošana)...........................7

3.1. Unāra saite...............................................................................7

3.2. Bināra saite..............................................................................7

3.3. Ternāra saite............................................................................8

3.4. „Vāja” realitāte.........................................................................8

3.5. Dati saite..................................................................................9

3.6. Klasifikācija............................................................................10

3.7. Superrealitāte........................................................................10

3.8. Arc elements..........................................................................11

3.9. Mantošana..............................................................................12

4. Kopēja EER diagramma...............................................................13

5. Konceptuāla modeļa transformācija loģiskajā modelī..................14

5.1. Unāras saites transformācija.................................................14

5.2. Bināras saites transformācija.................................................14

5.3. Ternāras saites transformācija...............................................15

5.4. “Vājas” realitātes transformācija...........................................16

5.5. Datu transformācija...............................................................16

5.6. Klasifikācijas transformācija..................................................18

5.7. Superrealitātes transformācija..............................................18


5.8. Arc elementa transformācija..................................................19

5.9. Mantošanas transformācija....................................................19

6. Loģiskā modeļa kopēja shēma.....................................................21

7. Tabulu pārbaude..........................................................................22

7.1. Datu funkcionālas atkarības diagramma................................22

7.1.1. Pilna funkcionāla atkarība................................................22

7.1.2. Nepilna funkcionāla atkarība...........................................23

8. Boisa Koda normālformas pārbaude............................................25

9. Tabulu dublēšanas pārbaude.......................................................27

10. DBVS realizēšana.......................................................................28

10.1. Tabulu veidošana.................................................................28

10.2. Saišu starp tabulām veidošana.............................................31

11. Secinājumi..................................................................................35


2. Priekšmetiskas vieds modeļa iegūšana (Datu Plūsmas

Diagramma)

Lai varētu iegūt konceptuālu vai loģisko modeli datubāzei vispirms jādefinē Datu Plūsmas Diagrammu (DPD), lai saprastu, kas ir datubāzes būtība un par ko tā ir. Neskatoties uz to, ka Austrālijas datubāzu inženieri uzskata, ka jāsāk ar konceptuālo modeli (EER modelis), sāksim tieši ar DPD. Mūsu datubāzes priekšmets (biznesa process) ir preču pasūtīšana un nodošana pasūtītājam. Mans izveidotais variants ir sekojošais:


Att. 1 Datu plūsmas diagramma

Notāciju izmantotie simboli:

D1- Pasūtījuma dati;

D2 – Dati par pasūtītāju

D3 – Dati par uzņēmumu (pasūtītāju)

D4 – Dati par pasūtījuma statusu

F1-F11 – Funkcijas


V1 – V2 – Vaicājumi

A1 – Atbilde

K1 –Dokumenti

Kad datu plūsmas diagramma ir izveidota un ir definētas notācijas, var pāriet pie konceptuāla modeļa veidošanas soļa.


3. Konceptuālais modelis (EER moduļa veidošana)

Iepriekšējā sadaļā ir izveidota datu plūsmas diagramma iekšējam informācijas sistēmas procesam preču pasūtīšana un nodošana pasūtītājam. Tagad var sākt projektēt konceptuālu modeli, izmantojot EER diagrammu ar P.Čena notāciju (diagrammā) un kreisajā pusē Barkera notāciju vizuālais atspoguļojums. Konceptuālam modelim jāsatur: unāro saiti, bināro saiti, ternāra saiti, datu saiti, vāju realitāti, klasifikāciju, superrealitāti, arc elementu un mantošanu. Tālāk apskatīsim katru saiti atsevišķi, kur paradīšu kā vispārēji jāizskatās saitei un kā tā ir atspoguļota manā EER modelī.

3.1. Unāra saiteUnāra saite ir saite, kas savieno vienu realitāti pašu ar sevi. Manā gadījumā ir galvenā grāmatvede ir vienlaicīgi pieder arī pie

grāmatvedības darbiniekiem (R1). Ir vairāki grāmatvedības darbinieku (N), bet galvenā grāmatvede ir 1. Sk. Att. 2.

Att. 2 Unāra saite


3.2. Bināra saiteBināra saite ir divu dažādu realitāšu saite. Manā gadījumā ir vairāki (N) dokumenti (R2), kuri glabājās vienā (1) noliktavā

(R1). Tas ir viens no vairākiem bināras saitēm. Sk. Att. 3.

Att. 3 Bināra saite

3.3. Ternāra saiteTernāra saite savieno trīs realitātes, veidojot vienu veselu saiti. Visas trīs realitātes ir atkarīgas viena no otrās. Apskatīsim, kā es realizēju šo saiti

savā procesā. Sk. Att. 4. Tātad man ir trīs realitātes ,kas ir saistītas, veidojot ternāra saiti. Ir viens piegādātājs (R1), kuram ir vairāki pasūtītāji (klienti) (R2), savukārt piegādātājam ir vairāki līgumi (R3) ar katru no pasūtītājiem.


Att. 4 Ternāra saite

3.4. „Vāja” realitāteVāja realitāte ir tāda realitāte, kura bez realitātēm, kuras ir saistītas apkārt ar šo „vāju

realitāti” nevar pastāvēt vai dod bezjēdzīgus, tukšus datus. Tātad gan realitāte „Pozitīva atbilde”, gan realitāte „Negatīva atbilde” ir vājās realitātes, jo bez datiem saitēs un realitātēm „Pasūtītājs” un „Piegādātājs”, vājām realitātēm ir bezjēdzīgi, „tukši” dati. Vāja realitāte „Pozitīva atbilde” nozīme, ka prece, kuru pasūtīja pasūtītājs ir, un tā ir gatava nosūtīšanai, savukārt „Negatīva atbilde” var būt gadījumā ja preces nav vai pasūtītas preces daudzums ir mazāks nekā ir noliktavā. Manā diagrammā „vāja realitāte” ir atspoguļota sekojošā veidā (Sk. Attēls 5):


Att. 5 Vāja realitāte

3.5. Dati saiteKā ir redzams 6. Attēlā, datu saite ir tāda saite starp realitātēm, kurai pieder atribūti. Manā gadījumā šī saite pastāv situācijā kad pēc viena līguma var būt vairāki maksājumi, tas nozīmē, ka

pasūtītājs slēdz vienu līgumu ar piegādātāju, kurā sadarbības laikā var pievienot jaunus pasūtījumus ar jauniem atribūtiem (summa samaksai un apmaksas termiņš). Protams, ka vienam pasūtījumam ir atšķirīgi šī atribūti.

Att. 6 Dati saite

3.6. Klasifikācija


Klasifikācijas var būt pilna vai nepilna. Pēc būtības atšķirība starp pilno un nepilno klasifikāciju ir sekojoša:

Ja klasifikācija ir pilna, tad ir apskatītas un definētas visas realitātes lomas;

Pilna klasifikācija ir parādīta manā EER diagrammā (7.attēls), kad līgums var būt slēgts starp uzņēmumiem vai nu uz ilgtermiņu, tas nozīme ka pasūtītājs varēs saņemt pasūtījumus neslēdzot pēc katra pasūtījuma jaunu līgumu vai nu uz ierobežotu laiku, tas nozīme kā pasūtītājs tikai vienu reizi saņems pasūtījumu no piegādātāja. Klasificētas realitātes („Ilgtermiņa līgums” un „Uz ierobežotu laiku līgums”) nevar krustoties.

Ja klasifikācija ir nepilna, tad ir definētas dažas vai ne visas realitātes lomas.

Att. 7 Pilna klasifikācija


3.7. SuperrealitāteSuperrealitāte ir divu vai vairāku realitāšu apvienojums ar mērķi definēt vienu veselu realitāti. Sk. Att. 8. Manā EER diagrammā superrealitāte ir atspoguļota

sekojoša veidā:

Att. 8 Superrealitāte

Uz attēlā var redzēt, ka ir definēti vairāki dati par pasūtītāju (kontrahentu), kas ir vajadzīgi maksājuma veikšanai. Gadījumā ja maksājumā nav norādīts kaut viena no realitātēm: „Uzņēmuma reģistrācijas numurs”, „Uzņēmuma nosaukums” vai „Apmaksāta summa” maksājumu nevarēs piereģistrēt mūsu informācijas sistēmā. Tas nozīme, ka ir vajadzīgi visi trīs pasūtītāja dati.


3.8. Arc elementsArc elementa galvenā nozīme ir ka realitātes var pāriet tikai vienā no divām „stāvokļiem”. Apskatīsim manu piemēru no kopējas EER diagrammas. Apskatīsim 9. Attēls.

Kā pasūtītājs, ka arī kā piegādātājs var dod viens otram tikai vienu no atbildēm. Pieņemsim, ka pasūtītājs pasūtīja 2 preču vienības. Savukārt Piegādātājam ir tikai viena preces vienība. Piegādātājs raksta „Negatīvu atbildi” par nepietiekošu preces daudzumu. Savukārt Pasūtītājs var arī atbildēt Piegādātājam, ka viņš nopirks pieejamo 1 preces vienību, viņš raksta „Pozitīvu atbildi”. Tātad ir iespējams tikai viens no divām variantiem.

Att. 9 Arc elements

3.9. MantošanaMantošana ļauj realitātēm, kuri ir „bērni” citai vai citām realitātēm, mantot, pārņemt īpašības no realitātēm, kuri ir „vecāki”. Manā


diagrammā no realitātes „Uzņēmums”, kas ir „vecaks”, bērni „Pasūtītājs” un „Piegādātājs” manto četrus atribūtus: Nosaukums, PVN reģistrācijas numurs, Adrese un Bankas konts. Savukārt realitātei „Pasūtītājs”, izņemot tā saucamos pamat atribūtus vēl pievienojās vēl četri. Tāda paša situācija ir arī realitātei „Piegādātājs”. Sk. 10. Attēlu.

Att. 10 Mantošana

Tagad visas saites ir aprakstītas un parādītas uz fragmentiem, kuri ir „izgriezti” no kopējas EER diagrammas. Kopējo EER diagrammu var aplūkot nākamā sadaļā.

4. Kopēja EER diagramma


Att. 11 Kopēja EER diagramma


5. Konceptuāla modeļa transformācija loģiskajā modelī

Tagad, kad EER diagramma ir pilnīgi definēta, varu sākt tas pārveidošanu transformācijas loģiskajā modelī. Katru EER diagrammas daļu (saites) es apskatīšu atsevišķi.

5.1. Unāras saites transformācijaUnāras saites realitāti „Grāmatvedības darbinieki” es atspoguļoju kā skatu. Tā kā unāra saite savieno vienu realitāti ar viņu pašu, es izveidoju divus skatus: „Skats_GRDarbinieki” un „Skats_GRDarbinieki2”. Lai izveidot attiecību, es izveidoju vēl vienu tabulu starp skatiem, kas satur laukus-atslēgas, kuri norāda kurš no grāmatvedības darbiniekiem ir galvenais grāmatvedis. Sk. Att. 12.

Att. 12 Unāras saites transformācija

5.2. Bināras saites transformācijaApskatīšu iepriekšizveidotu bināru saiti starp „Noliktava” un „Dokuments” realitātēm. Uz 13.attēla var redzēt, ka bināra saitei ir vienkāršāka transformācija, nekā iepriekšējai unārai saitei, tāpēc realitātei „Noliktava” ir izveidots skats „Skats_Noliktava”, bet realitāte „Dokuments” ir transformēts „Tabula_Dokuments”.


Att. 13 Bināras saites transformācija

5.3. Ternāras saites transformācijaTernāras saites transformācija tiek realizēta gandrīz tāda paša veidā kā unāra saite. Atšķirībā no unāras saites transformācijas, Ternāras saites transformāciju jāizpilda ar dažām izmaiņām – jāveido trīs tabulas katrai realitātei. Pēc tam jāveido starptabulu, kas arī palīdzēs attēlot un savienot trīs galvenās tabulas. Uz 14. Attēla var redzēt ka ir savienoti trīs galvēnas tabulas: „Tabula_Pasutitajs”, „Tabula_Ligums” un „Tabula_Piegadatajs”. Katra no galvenās tabulas ir skats. Un ir izveidota starptabula „Tabula_tern_att”.


Att. 14 Ternāras saites transformācija

5.4. “Vājas” realitātes transformācijaVājo realitātes saiti attēloju, kā starptabulu divām eksistējošām tabulām. Tas nozīmē, ka starp skatiem „Skats_Pasutitajs” un „Skats_Piegadatajs” eksistē vēl divas tabulas „Tabula_Poz_atbilde” un „Tabula_Neg_atbilde”. Transformācija ir atspoguļota 15 attēlā.

Att. 15 Vājas realitātes transformācija


Tātad gan tabula „Pozitīva atbilde”, gan „Negatīva atbilde” ir starp tabulas, kas palīdz attēlot vājās realitātes.

5.5. Datu transformācijaTagad aplūkosim datu saiti. Tādu saiti var transformēt divos variantos. Apskatīsim katru variantu atsevišķi, kur katram variantam ir izveidotas atbilstošas transformācijas. Transformāciju aplūkosim starp „Skats_Ligums”, „Skats_Pasutitajs” un „Skats_Piegadatajs”. Tā bija iepriekš apskatīta ternāras saites transformācijas sadaļā. Šajā pašā piemērā apskatīsim arī datu transformāciju.

1. variants:

Pārveidot datu saiti par tabulu ar attiecīgiem laukiem, kas saturēs šos datus, ka arī atslēgas tabulu savienošanai. 16. attēlā var redzēt, ka dati „Summa_samaksai” un „Apmaksas_termins” ir pievienoti tabulai „Tabula_tern_att”. Ar zaļo krāsu ir iezīmēti pievienoti lauki.

Att. 16 Datu saites transformācija 1. variants


2. variants:

Cits variants ir pievienot šos datus tai tabulai, kurai tie ir vispiemērotākie. Manā gadījumā, sk. Att. 17, kur dati ir pievienoti tabulai „Skats_Ligums”. Apskatīsim piemēru, kas attiecās uz ternāras saites transformāciju. „Skats_Ligums” ir pievienoti sekojoši datu lauki: „Summa_samaksai” un „Apmaksas_termins”. Ar zaļo krāsu ir iezīmēti pievienoti lauki.

Att. 17 Datu transformācija 2.variants

5.6. Klasifikācijas transformācijaTātad, lai attēlotu „Līgums” realitātes klasifikāciju „Ilgtermiņā līgums” un „Uz ierobežotu laiku līgums” veidošu sekojošu transformāciju. Sk. 18. Att. Tā kā manā piemērā ir pilna klasifikācija, tas nozīmē, ka pamatā bus tabula, no kuras „klasificējas” divi skati. Uz attēla var redzēt, ka tabulas


„Tabula_Ligums” datu lauki pāriet klasificējamos skatos „Skats_IlgterminaL” un „Skats_UzIerobezotuL”.

Att. 18 Klasifikācijas transformācija

5.7. Superrealitātes transformācijaIr iespējami divi varianti kā var realizēt superrealitātes transformāciju: var izveidot vai nu skatu (kā izvēlējos es) un izveidot tabulu ar tiem pašiem datiem. Abi ši varianti ir apskatīti mācību materiālā.

Es izvēlējos realizācijas izveidot skatu, kurā būs apvienoti divu tabulas dati un citi dati. Tas var izskatīties sekojošā veidā (20. attēls ). „Skats_DatiParUznemumu” glabājas dati par uzņēmumu:


Att. 19 Superrealitātes transformācija

5.8. Arc elementa transformācija

ArcTā kā lekcijas laikā mēs apspriežam transformācijas arc elementam, kur vajadzēja izmantot trīs tabulas. Es nolēmu, ka visvienkāršākā variantā ir izveidot trigeri, kas aktivizēsies momentā kad vajadzēs izveidot vēl vienu ierakstu tabulā, kur vajadzēs ierakstīt vai nu pēc pasūtījuma ir „Pozitīva atbilde” vai nu „Negatīva atbilde”.

5.9. Mantošanas transformācijaManā piemēra runa iet par vienkāršu mantošanu. Realizāciju mēs apskatījām lekcijas laikā, un izveidojām vienu tabulu, kas ir savienoti ar diviem iepriekšizveidotiem skatiem: „Skats_Pasutitajs”


R1

R2 R3

un „Skats_Piegadatajs”, jo sākumā tiek mantotas realitātes „Uzņēmums” atribūti, tad atbilstoši realitātes „Pasūtītājs” vai „Piegādātājs” atribūti, var izveidot sekojošu struktūru. Sk. Att. 20. Gribu piezīmet, ka „Skats_Pasutitajs” lauks Pa_piegadesAdrese nav tas pats kā „Tabula_Uznemums” lauks Uzn_Adrese. Uzņēmuma adrese ir faktiskā vai jurisikā adrese kurā ir reģistrēts uzņēmums, bet lauks Pa_PiegadesAdrese ir lauks, kurā būs definēta pasūtījuma nosūtīšanas adrese. Bet visi pārējie lauki no „Tabula_Uznemums” ir mantoti skatiem.

Att. 20 Mantošanas transformācija


Kad visu saišu transformācijas ir izveidotas, varam apkopot visas aprakstītas transformācijas vienā loģiskā modelī. Modeli var apskatīt nākamā sadaļā „Loģiskā modeļa kopēja shēma”.


6. Loģiskā modeļa kopēja shēma

Skats_GrDarbinieki

D_IDD_VardsD_UzvardsD_PersKodsD_DarbaPieredzeD_IzglitibaD_MobilasD_Alga

<pi>

Skats_GrDarbinieki2

D_IDD_VardsD_UzvardsD_PersKodsD_DarbaPieredzeD_IzglitibaD_MobilasD_Alga

<pi>

Tabula_GGramatvedis

Darb_IDGG_ID

IntegerInteger

<M><M>

Skats_Noliktava

N_IDN_AdreseN_RajonsN_DarbSkaitsN_AtbildigaisN_Platiba

<pi>

Tabula_Dokuments

Dok_NumDok_DatumsDok_VeidsDok_StatussDok_PrioritateDok_Atbildigais

<pi>

Tabula_Līgums

L_IDL_DatumsL_TipsL_KontrahentsL_BeigDatums

<pi>

Skats_Pasutitajs

Pa_IDPa_LigumaNrPa_Lig_VeidsPa_PasDatumsPa_JurPersPa_Fiz_PersPa_PasSanDatumsPa_PiegadesAdrese...

<pi>Skats_Piegadatajs

Pi_IDPi_BankKontsPi_Atbi ldPersonaPi_GalvGramatvedePi_Piegad_datums

<pi>

Identifier_1... <pi>

Tabula_tern_att

Ligums_IDPasutitajs_IDPiegadatajs_IDSumma_samaksaiApmaksas_termins

Tabula_Poz_atbilde

PA_PaPA_PiPA_Sanems_datumsPA_Nosut_datums...

Tabula_Neg_atbilde

NA_PaNA_PiNA_Sanems_datumsNA_Nosut_datums...

Skats_IlgterminaL

L_IDL_DatumsL_TipsL_KontrahentsL_BeigDatumsIL_DatumsNoIL_AtlaideIL_Priori tateILAtbi ldigais

<pi>Skats_UzIerobezL

L_IDL_DatumsL_TipsL_KontrahentsL_BeigDatumsIL_DatumsNoIL_Pasuti jums

<pi>

Tabula_Uznemums

Uzn_IDUzn_FaxUzn_AdreseUzn_RegNumUzn_GadaApgrozijumsUzn_NosaukumsUzn_StavsUzn_DibinasanasGadsUzn_NodarbosanasNozareUzn_CilvekuSkaitsUzn_WebAdreseUzn_DirektorsUzn_Telefons

<Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined>

Tabula_Maksajums

M_IDM_KontsM_KontrahentsM_MerkisM_SummaM_DatumsUzn_RegistracijasNumursUzn_NosaukumsApmSumma

<pi>

Att. 21 Loģiskā modeļa kopēja shēma


7. Tabulu pārbaude

Iepriekšējā sadaļā ir pilnīgi aprakstītas gan kopēja EER diagramma, gan ir definēts loģiskais modelis, katrs ir apskatīts pa daļām. Tagad var turpināt ar tabulu kvalitātes pārbaudi, kas ietvers gan datu funkcionālu atkarības pārbaudi, gan Boisa Koda normālformas pārbaudi. Tagad apskatīsim katru pārbaudi atsevišķi.

7.1. Datu funkcionālas atkarības diagrammaFunkcionāla atkarība datiem ir sekojoši definēta – ja vienai x vērtībai eksistē tikai viena y vērtība, tad tā ir funkcionāla atkarība.1 Eksistē pilnā un nepilnā funkcionāla atkarība. Apskatīsim katru atkarību atsevišķi, ka arī atbilstošu piemēru katram.

7.1.1. Pilna funkcionāla atkarībaApskatīsim 22. Attēlu, kurā ir parādīta tabula no loģiskā modeļa, kurā ir sekojoši lauki – Uzn_Adrese (Uzņēmuma faktiskā vai juridiskā adrese), Uzn_Stavs (Uzņēmuma stāvs, kur atrodas ofiss), Uzn_Nosaukums (Uzņēmuma nosaukums). Pārējus tabulas laukus neapskatīsim.

Pieņemsim, ka pēc vienas adrese var atrasties vairāki ofisi un katrs ofiss aizņem vienu ēkas stāvu. Veidojot jaunu ierakstu laukam Uzņēmuma nosaukums būs jauna vērtība tad, kad gan lauks „Uzņēmuma adrese”, gan lauks „Stāvs” veidos unikālu vērtību. Tikai apvienot abas vērtības veidojas unikāla vērtība. Zinot uzņēmuma adresi un stāvu, kurā atrodas galvenais vai meitas ofiss var uzzināt uzņēma nosaukumu (un ne tikai šo vērtību), varu secināt, ka tāda atkarība ir pilna funkcionāla atkarība.1 Mācību materiāls, 2008.gads

Tabula_Uznemums

Uzn_IDUzn_FaxUzn_AdreseUzn_RegNumUzn_GadaApgrozijumsUzn_NosaukumsUzn_StavsUzn_DibinasanasGadsUzn_NodarbosanasNozareUzn_CilvekuSkaitsUzn_WebAdreseUzn_DirektorsUzn_Telefons

<Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined><Undefined>

Att. 22 Pilnas funkcionālas atkarības piemērs

7.1.2. Nepilna funkcionāla atkarībaApskatīsim nepilnas funkcionālas atkarības piemēru uz 23. attēla. Es paņemu tabulu no loģiskā modeļa. Tātād šī tabula satur sekojošus laukus – „Ligums_ID”, „Pasutitajs_ID”, „Piegadatajs_ID”, „Summa_samaksai” un „Apmaksas_termins”. Kad būs veidots jauns ieraksts, tad lauks „Ligums_ID”, ietekmēs lauka „Summa_samaksai” vērtību, bet lauks „Pasutitajs_ID”, neietekmēs vispār, jo pēc līguma numura var uzzināt visu pārējo informāciju.

Tabula_tern_att

Ligums_IDPasutitajs_IDPiegadatajs_IDSumma_samaksaiApmaksas_termins

Att. 23 Nepilnās funkcionālas atkarības piemērs

Tagad apskatīsim 24 un 25 attēlus, kurā ir attēlota datu funkcionālā atkarība. Atgādināšu, ka iepriekš ir definēts, ka jebkāds uzņēmums aizņem ēkā vienu veselu stāvu. Šos divus attēlus vajadzēja apvienot vienā, bet es tos izšķiroju, lai sīkāk apskatīt katru. Ir redzams, ka


primāra atslēga ir lauks „Uzn_ID” (Uzņēmuma identifikācijas numurs), kas ietekmē uz pārējiem lauku vērtībām. Veidojot jaunu ierakstu primārai atslēgai, veidojas jaunas vērtības pārējiem laukiem, attiecīgi veidojot kopīgu unikālu vērtību. Uz attēla ir redzams, ka zinot tikai uzņēmuma identifikācijas numuru, var uzzināt pavisam visus pārējus laukus (Adrese, Stāvs, Nosaukums, Reģistrācijas numurs un tt.).

Dibinasanas_gads

Nosaukums

Nodarbosanas_nozare

Reg.Num

FaxDirektors Web_adrese

Telefons

Cilveku_skaits

Uzn_ID

Adrese Stavs

Att. 24 Datu funkcionālas atkarības diagramma (sākums)

Lauki „Adrese” un „Stavs” veido kopīgu unikālu vērtību. Ja ir unikāla vērtība, tad pārējiem, laukiem arī jāveido unikālu kopīgu vērtību, kaut arī atsevišķi lauki var atkārtoties. Laukam „Reg_num” (Uzņēmuma reģistrācijas numurs) arī ir tas pats, kas tika apspriests iepriekš, jo reģistrācijas numurs var piederēt tikai vienam uzņēmumam, nevis visiem. Tabulas anomālijas un šajā tabulā nav, jo nav tāda lauka, kuru mainot, vai dzēšot vajadzētu obligātu darīt to pašu ar citu lauku. Šajai tabulai ir funkcionāla. Tālāk darbā apskatīsim Boisa Koda normālformas pārbaudi.


Dibinasanas_gads

Nosaukums

Nodarbosanas_nozare

Reg.Num

FaxDirektors Web_adrese

Telefons

Cilveku_skaits

Uzn_IDAdrese Stavs

Att. 25 Datu funkcionālas atkarības diagramma (turpinājums)

8. Boisa Koda normālformas pārbaude

Lai pārbaudītu Boisa koda normālformu sākumā jāpārbauda pirmo, otru un trešu normālformas. Ja visas normālformas atbilst man izveidotam modelim, tad var pārbaudīt Boisa Koda normālformu.

Pirmā normālforma

Apskatīsim pirmo normālformu (1NF). 1NF eksistē tikai tādā gadījumā, kad visi domēni satur nedalāmas vērtības. Izpētot visus laukus tabulās, var apgalvot, ka domēni lauku vērtībām ir nedalāmi. Mans izveidotais modelis atbilst 1NF.

Otrā normālforma


2NF eksistē gadījumā ja izveidotais modelis atbilst 1NF un katrs neprimāras atslēga lauks funkcionāli pilnīgi ir atkarīga no primāras atslēgas. Pārbaudot visas tabulas var konstatēt, ka jebkurš neprimāras atslēgas lauks funkcionāli pilnīgi atkarīgs no primāras atslēgas.

Trešā normālforma

3NF tad, ja ir 2NF un katrs ne primāras atslēgas lauks netransitīvi ir atkarīgs no primāras atslēgas (lai transitīvas saites neeksistētu). Transitivitāte eksistē, ja zinām ‘a’ un ‘b’, var uzzināt ‘c’. (Sk. attēlu) Apskatot modeli var konstatēt, ka eksistē transitīva saite starp tabulu „Tabula_Maksājums” un „Tabula_Līgums”. Šo situāciju var koriģēt, ievietojot vēl vienu tabulu (it ka starp tabulu) „Tabula_Maks_Lig”, kas būtu starpnieks minētām tabulām un saturēs datus par maksājumiem un līgumiem. Shematiski to var attēlot sekojoši ():


a

c

b

Tabula_Līgums

L_IDL_DatumsL_TipsL_KontrahentsL_BeigDatums

<pi>

Tabula_Maksajums

M_IDM_KontsM_KontrahentsM_MerkisM_SummaM_DatumsUzn_RegistracijasNumursUzn_NosaukumsApmSumma

<pi> Tabula_Maks_Lig

Mask_M_IDMaks_L_IDMaks_ID <pi>

Identifier_1... <pi>

Att. 26 Transtitīvītātes novēršana

Tātad, var secināt, ka transtitivitāte ir novērsta un tagad modelis pilnīgi atbilst 3NF.

BKNF ir gadījumā tikai tad, kad tabula T apmierina 3NF prasības un ja katrs determinants ir iespējamā primāra atslēga. Tad pieņemsim ir tabula „Tabula_Uzņēmums”, kurai ir sekojoši lauki „Uzn_ID”, „Uzn_RegNum”, „Uzn_Nosaukums”, „Uzn_Adrese”, „Uzn_Stavs”, „Uzn_DibinasanasGads”, „Uzn_CilvekuSkaits”, „Uzn_WebAdrese”, „Uzn_Direktors” un „Uzn_Telefons”, „Uzn_Fax” un „Uzn_GadaApgrozijums”.Iespējama primāra atslēga (Primary Key)

Determinants

Uzn_ID Uzn_ID

Uzn_RegNum Uzn_RegNum

Uzn_Adrese + Uzn_Stavs Uzn_Adrese + Uzn_Stavs

Uzn_Nosaukums Uzn_Nosaukums

- Uzn_DibinasanasGads

- Uzn_CilvekuSkaits

Uzn_WebAdrese Uzn_WebAdrese

- Uzn_Direktors

Uzn_Telefons Uzn_Telefons

Uzn_Fax Uzn_Fax

- Uzn_GadaApgrozijums


Tabula 1

Tabulā 1 ir sadalīta divās kolonnās, kur pirmā ir atspoguļoti iespējama primāra atslēga un otrā Determinānts. Pēc tabulas datiem ir redzams, ka ne visi dati var būt determinanti (Uzn_DibinasanasGads, Uzn_CilvekuSkaits, Uzn_Direktors un Uzn_GadaApgrozijums). Novērsim šo situāciju, normalizējot šo tabulu sekojoši:

Tabula_Uznemums

Uzn_IDUzn_AdreseUzn_RegNumUzn_NosaukumsUzn_StavsUzn_WebAdreseUzn_TelefonsUzn_Fax

Uzn_Informacija

IDUzn_DibinasanasGadsUzn_CilvekuSkaitsUzn_DirektorsUzn_GadaApgrozijums

Att. 27 Tabulas normalizācija

Apskatot parejas tabulas, varu konstatēt, ka pārējas tabulas atbilst BKNF, tad detalizēti tos neapskatīsim.

9. Tabulu dublēšanas pārbaude

Šī pārbaudes pamats ir atrast tabulas, kurās dublējas dati. Manā loģiska modeļa ir tikai divas tabulas „Tabula_Poz_atbilde” (kas atbilst reālitātei „Pozitīva atbilde”) un „Tabula_Neg_atbilde” (kas atbilst reālitātei „Negatīva atbilde”). To var novērst, izveidojot vienu tabulu , pievienojot tai lauku „Atbildes_statuss”, kurš noradis uz atbildes statusu.

Atbildes_statuss

A_IDA_PaA_PiA_Sanemsanas_datumsA_Nosutisanas_datumsA_Stauss


Tādejādi, pabeidzam visas pārbaudes un saksim veidot datubāzi, izmantojot Microsoft Access rīku.


10. DBVS realizēšana

Lai izveidot tabulas un saites starp tiem es izmantoju Microsoft Access 2007 rīku.

10.1. Tabulu veidošana1. tabula

Att. 28 Izveidota tabula "Pasutitajs"

CREATE TABLE Pasutitajs( Pa_ID NUMBER(12) NOT NULL, Pa_LigumaNr VARCHAR2(20) NOT NULL, Pa_LigVeids VARCHAR2(50) NOT NULL, Pa_PasDatums DATE, Pa_JurPers VARCHAR(3) NOT NULL, Pa_FizPers VARCHAR(3) NOT NULL, Pa_PasSanDatums DATE, Pa_PiegadesAdrese VARCHAR2(50) NOT NULL,


CONSTRAINT Pa_ID PRIMARY KEY (Pa_ID));

Izveidota tabulas SQL kods "Pasutitajs"

Pēc tāda paša principa ir izveidoti visas pārējas tabulas ar laukiem, kuri ir aprakstīti loģiskā modeļa sadaļā.

2. tabula

3 un 4. tabulas

un

5 un 6. tabulas


7. tabula

8. tabula

9. tabula


10. tabula

11. tabula

12. tabula

13. tabula


Tagad visas 13 tabulas ir izveidotas, varam ķerties pie saišu veidošanas starp tiem. Bet par to nākamā sadaļā.

10.2. Saišu starp tabulām veidošana1.

2.


3.

4.


5.

Visas saites nav atspoguļotas ar attēliem. Kopēju shēmu var aplūkot nākamā lappusē.


11. Secinājumi

Pirmā praktiskā darba mērķis ir izveidot informācijas sistēma, definēt to un izstrādāt konceptuālu modeli, datu plūsmas diagrammu, loģisko modeļi, kā arī parādīt kā tādu sistēmu var realizēt ar Oracle,SQL vai Access. Mana datubāzes priekšmets (biznesa process) ir preču pasūtīšana un nodošana pasūtītājam. Lai vieglāk saprast manu darbu, es pēc iespējas vairāk ievietoju attēlu, lai atspoguļot gan diagrammas, gan tabulas (kopā darbā ir 44 attēli). Manuprāt, pateicoties notācijām var viegli saprast izveidota modeļa jēgu. Ar datu plūsmas diagrammu izveidošanu nebija lielas grūtības. Pēc tam sāku veidot EER diagrammu, ar kuru sākumā, manuprāt, bija pavisam slikti. Bet pēc konsultēšanām ar kolēģiem un Jums, sāka veidoties atbilstošs uzdevumu nostādnei modelis. Varu atzīmēt, ka loti palīdzēja mācību materiāli un lekcija, kurā mēs aplūkojam uz studenta piemēra kā pareizi jāzīmē EER diagrammu (pēc Chena notācijas). Daudz nesaprašanu bija attiecīgi konceptuāla modeļa. Klasifikācija un mantošana sajaucās galvā, bet pēc Jūsu padomiem jautājums tika atrisināts. Kā arī grūtības sagādāja informācijas meklēšana par Arc elementa transformāciju: vai nu veidot vēl vienu tabulu, vai skatu. Kad visas transformācijas bija izveidotas, palika nesavienotas realitātes, un kas ar tiem darīt nebija ne jausmas. Gan konceptuālais, gan datu plūsmas diagrammas ir izveidotas, pateicoties PowerDesighner 15 programmatūrai. Protams, realizēt visas tabulas varēja arī ar SQL Developer rīku, bet nesanāca uzstādīt savā datorā Oracle. Bet tomēr darbā, realizācijas sadaļā ir parādīts SQL vaicājuma kods. Arī meklēju informāciju par


normālformām (lekcijas laikā Jūs piemīnējat, ka tos var būt līdz 7) un kas ir nedalāmas vērtības.

Kas attiecās uz darbu Access vidē, tabulā Dokuments Access’ā nevarēju pievienot (Relationship) tabulai Noliktava, tāpēc kā nebija atbilstoša lauka kam pievienot, tas nozīmē, ka tabulu pārbaudes laikā es šo kļūdu nepamanīju. Nācās pārtaisīt tabulas, ka arī no jauna pārbaudīt visas pārējas tabulas.

Darbs bija ne īpaši sarežģīts, bet laika ietilpīgs, domāju kā paveikt tādu darbu varētu ātrāk. Tagad visas kļūdas un sarežģījumi, kas rodas praktiska darba rakstīšanas laikā ir aprakstītas. Darbs ir izpildīts patstāvīgi. Paldies!


1. uzdevuma nostādne - web vieweizmantojot case rīkus. praktiskais darbs nr. 1. mācību...

Documents