1. Uzdevuma nostādne - Web vieweizmantojot CASE rīkus. Praktiskais darbs Nr. 1. mācību...
Transcript of 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” Page 2
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 3
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 4
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:
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 5
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 6
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.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 7
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 8
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.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 9
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):
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 10
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 11
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 12
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.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 13
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ā
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 14
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 15
Att. 11 Kopēja EER diagramma
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 16
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”.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 17
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”.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 18
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 19
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 20
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 21
„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:
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 22
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”
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 23
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 24
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”.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 25
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 27
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 29
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.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 30
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 31
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 ():
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 32
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 33
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 34
Tādejādi, pabeidzam visas pārbaudes un saksim veidot datubāzi, izmantojot Microsoft Access rīku.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 35
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,
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 36
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 37
7. tabula
8. tabula
9. tabula
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 38
10. tabula
11. tabula
12. tabula
13. tabula
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 39
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.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 40
3.
4.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 41
5.
Visas saites nav atspoguļotas ar attēliem. Kopēju shēmu var aplūkot nākamā lappusē.
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 42
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 43
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
1. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 44
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. praktiskais darbs mācību priekšmetā “Informācijas sistēmas un CASE rīki” Page 45