Nauris JeškevičsStudenta reģistrācijas kopmītnē datu konceptuālais modelis

Rīga 2009.

Saturs

UZDEVUMA NOSTĀDNE............................................................................................................................................. 3

PROBLĒMVIDES APSKATS UN DATU PLŪSMAS DIAGRAMMAS IZVEIDOŠANA..............................................................4

DATUBĀZES KONCEPTUĀLĀ MODEĻA IZVEIDOŠANA...................................................................................................7

ER DIAGRAMMA..................................................................................................................................................................7Realitāšu saišu veidi....................................................................................................................................................8Saišu kardinalitāte......................................................................................................................................................9Realitātes piedalīšanās pakāpe saitē ar citu realitāti..................................................................................................9Vājā realitāte............................................................................................................................................................10Arc elements.............................................................................................................................................................10

ENHANCED-ER DIAGRAMMA................................................................................................................................................11Superklases un apakšklases ierobežojumi.................................................................................................................12Apakšklašu atdalīšana..............................................................................................................................................13Agregācija un kompozīcija........................................................................................................................................14Klasifikācija...............................................................................................................................................................15Kategorija.................................................................................................................................................................15

IZVEIDOTAIS DATUBĀZES KONCEPTUĀLAIS MODELIS (EER DIAGRAMMA)........................................................................................16

DB KONCEPTUĀLĀ MODEĻA TRANSFORMĀCIJA UZ DB LOĢISKO-FIZISKO MODELI.....................................................18

BINĀRĀS SAITES 1:N TRANSFORMĀCIJA..................................................................................................................................18BINĀRĀS SAITES N:N TRANSFORMĀCIJA..................................................................................................................................18VĀJĀS REALITĀTES TRANSFORMĀCIJA......................................................................................................................................19SPECIALIZĀCIJAS UN VISPĀRINĀŠANAS TRANSFORMĀCIJA............................................................................................................19TERNĀRĀS SAITES TRANSFORMĀCIJA......................................................................................................................................21UNĀRĀS SAITES TRANSFORMĀCIJA.........................................................................................................................................22KLASIFIKĀCIJAS TRANSFORMĀCIJA..........................................................................................................................................23AGREGĀCIJAS UN KOMPOZĪCIJAS TRANSFORMĒŠANA.................................................................................................................23ARC ELEMENTA TRANSFORMĀCIJA.........................................................................................................................................24KOPĒJAIS REALIZĒTAIS DATUBĀZES LOĢISKAIS-FIZISKAIS MODELIS..................................................................................................24

DATUBĀZES NORMALIZĀCIJA................................................................................................................................... 26

DATU FUNKCIONĀLĀ ATKARĪBA.............................................................................................................................................27NORMĀLFORMAS...............................................................................................................................................................27

DB normalizācija ar Boisa-Kodda normālformu........................................................................................................29

ORACLE DBVS SQL DEFINĒJUMI................................................................................................................................ 31

SQL DEFINĒJUMU RAKSTĪŠANA.............................................................................................................................................32

SECINĀJUMI............................................................................................................................................................. 38

IZMANTOTĀ LITERATŪRA......................................................................................................................................... 40

2

Uzdevuma nostādnePraktiskā darba izpildes gaitā, tiks realizēti šādi uzdevumi:

1) Jāizdomā noteikta problēmvide;2) Datu plūsmas diagrammas izveidošana (dati+funkcijas);3) Konceptuālā datu modeļa izveidošana (EER);4) Transformācijas veikšana EER->DB loģiskais modelis (RDB);5) DB normalizācija ar Boisa-Kodda normālformu;6) DBVS->SQL definējumi.

3

Problēmvides apskats un datu plūsmas diagrammas izveidošanaKā problēmvidi esmu izvēlējies kopmītnes, kurā tiks aplūkots biznesa process – studenta

uzņemšana kopmītnēs. Biznesa procesa automatizāciju nodrošina kopmītnes IS. Tagad īsumā par biznesa procesa norisi.

Kopmītnes IS glabājas kopmītnes iemītnieku reģistrs – visi tie studenti, kuri dzīvo ārpus augstskolas pilsētas un studiju programmas pietiekšanās laikā ir izvēlējušies apmesties kopmītnēs. Lai students varētu apmesties kopmītnēs, viņam septembra 1. nedēļas laikā jānoslēdz īres līgums, ņemot līdzi personas apliecinošu dokumentu (pase), dzīves vietas deklarācijas kopiju un daudz, daudz naudiņas. Kad students kopmītnēs iesniedz iepriekš minētos dokumentus, kopmītnes IS pārbauda vai students atrodas kopmītnes iemītnieku reģistrā. Ja atrodas, tad piedāvā visas brīvās istabiņas. Tālāk students IS nodod savu izvēlēto istabiņu, kura noformē un izsniedz studentam līgumu un kopmītnes iemītnieku reģistrā piešķir līguma noslēgšanas iezīmi. Kad students beidzot ir noslēdzis līgumu, atliek vēl veikt maksājumu par 1. mēnesi. Students nodod kasierim naudiņu un tālāk IS pārbauda, vai tiešām students ir noslēdzis līgumu. Ja ir, tad IS veic maksājuma apstiprināšanu, noformē un izdod studentam maksājuma čeku, kā arī kopmītnes iemītnieku reģistrā uzrādās veiktā maksājuma iezīme.

Bāzējoties uz izvēlēto problēmvidi, tiks veidota datu plūsmas diagramma, no kuras, savukār, vēlāk tiks projektēts datubāzes konceptuālais modelis. Datu plūsmas diagramma ir problēmvides (piemēram, kopmītnes) modelis, kura modelē projektējamās sistēmas (piemēram, kopmītnes IS) funkcionalitāti. Projektējamā sistēmā 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.

Datu plūsmas diagrammā tiek izmantoti šādi elementi:1) ārējā realitāte (piemēram, students, kasieris, nauda, utt);2) funkcija, kas pārvērš ieejas datus izejas datos (piemēram, studenta informācijas saņemšana);3) datu krātuve, kurā tiek glabāti dati un no kuras tiek izgūti dati (piemēram, kopmītnes iemītnieku reģistrs);4) datu plūsma (piemēram, vaicājuma datu plūšana līdz kopmītnes iemītnieku reģistram). Tā veidojas starp funkcijām, starp funkciju un datu krātuvi, starp ārējo realitāti un funkciju.

Attēlā ir parādīts datu plūsmas diagrammas elementu vizuālais attēlojums, kuri tiks izmantoti manā datu plūsmas diagrammā.

1.att. Datu plūsmas diagrammas elementi

Attēlā 2 ir parādīta projektējamās sistēmas (kopmītnes IS) datu plūsmas diagramma.

4

.att. Kopmītnes IS datu plūsmas diagramma

Lai labāk izprastu doto DPD, paskaidrošu, ko apzīmē lietotie simboli datu plūsmas elementos:D1 - dati:

d1a – personas apliecinošā dokumenta dati (vārds, uzvārds, personas kods, dzimums);d1b – dzīves vietas deklarācijas kopijas dati (valsts pilsēta).

Q1 – vaicājums no D1;A1 – vaicājuma Q1 atbilde:

a1a – studenta kopmītnes statusa noskaidrošana;a1b – brīvās kopmītnes istabiņas.

A2 – atbilde:a2a – potenciālā kopmītnes iemītnieka izvēlētā istabiņa.

D2 – dati:d2a – iesniegtie studenta dati.

L1 – dati:l1a – iesniegtie studenta dati (vārds, uzvārds, personas kods);l1b – istabiņa (numurs, platība, vietu skaits);l1c – līguma dati (līguma kods, līguma numurs).

D3 – dati:d3a – studenta personas dati (vārds, uzvārds);d3b – studenta istabiņas numurs.

N1 –dati:n1a – naudiņas daudzums.

Q2 – vaicājums no D3;A3 – atbilde:

5

a3a - studenta kopmītnes statusa noskaidrošana;a3b – naudiņas summa.

M1 – dati:m1a – studenta dati (vārds, uzvārds, personas kods);m1b- naudiņas summa.

Datu plūsmas diagramma projektējamai sistēmai ir realizēta. Nākamais solis ir datubāzes konceptuālā modeļa izveidošana.

6

Datubāzes konceptuālā modeļa izveidošanaBāzējoties uz datu plūsmas diagrammu, kura parāda procesu „studenta uzņemšana

kopmītnēs”, projektēšu datubāzes konceptuālo modeli, izmantojot P. Čena notācijas ER diagrammu un tās paplašinājumu (Enhanced ER jeb EER). Konceptuālais datubāzes modelis parāda kā biznesa pasaule redz informāciju. Tas apraksta datubāzu saturu un struktūru. Modelis parasti iekļauj nozīmīgākos realitāšu tipus, kam ir biznesa jēga kopā ar citiem realitāšu tipiem.

Tālāk nedaudz aprakstīšu par ER diagrammu un tās paplašinājumu.

ER diagrammaER (Entity Relationship – Realitāšu saistība) diagramma reprezentē datubāzes konceptuālo

modeli, ko 1976. gadā izstrādāja P. Čens, lai atvieglotu datubāzes projektēšanu. ER diagrammas pamatelementi ir:

a) realitātes tips;b) atribūts;c) saite.

Realitāte tips – Priekšmetiskās vides noteikta objektu, subjektu vai procesu klase.Realitāte – realitātes tipa eksemplārs. Tipam parasti ir daudz eksemplāru.

Pastāv arī vājais realitātes tips, bet par to nedaudz vēlāk.Saite – Divu vai vairāku realitāšu tipu savstarpējā sasaiste.Atribūts – Realitātes tipa būtiska pazīme, īpašība vai sastāvdaļa. Atribūts var attiekties arī uz saiti.

Identificējošs atribūts viennozīmīgi definē realitātes tipa eksemplārus.Vienkāršs atribūts sastāv no vienas neatkarīgas komponentes.Daudzvērtīgs atribūts vienai realitātei var saturēt vairākas vērtības.Salikts atribūts sastāv no vairākām neatkarīgām komponentēm.Atvasināta atribūta vērtība tiek iegūta no cita vai citu atribūtu vērtībām (ne tikai dotās realitātes atribūtiem).

Tabulā 1 ir parādīti ER diagrammas pamatelementu attēlojumi pēc P. Čena notācijas.

7

1. tabula

ER diagrammas pamatelementu attēlojums pēc P. Čena notācijasER diagrammas pamatelements Pamatelementa attēlojums ER

diagrammāRealitātes tips

Vājais realitātes tips

Saite

AtribūtsIdentificējošs

Vienkāršs

Daudzvērtīgs

Salikts

Atvasināts

Realitāšu saišu veidiER diagrammā starp realitāšu tipiem pastāv 3 veida saites: unārā, binārā un ternārā.

Unārā saiteUnārā saite saista realitāti pati ar sevi (skatīt attēlu ).

3.att. Unārā saite

Kā klasisku piemēru unārai saitei var minēt kopmītnes apkopēju (darbinieku) pakļautību. Piemēram, kopmītnes apkopējai Anniņai ir pakļautas 4 apkopējas.Binārā saite

Binārā saite saista divas dažādas realitātes (skatīt attēlu ).

4.att. Binārā saite

Binārās saites piemērs: Vienam kopmītnes īres līgumam var būt vairāki maksājumi.

8

Ternārā saiteTernārā saite saista trīs dažādas realitātes, veidojot vienu veselu saiti (skatīt attēlu 5).

5. att. Ternārā saite

Piemēram, pastāv 3 realitātes: administrācija, montieris un projekts. Visas šīs realitātes ir savā starpā saistītas, jo administrācijai ir pakļauti noteikti montieri noteiktā projektā; projekta tapšanā iesaistās montieri un administrācija; montieris ir pakļauts administrācijai un strādā pie noteikta projekta.

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

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

Attēlā ir parādīti saišu kardinalitātes apzīmējumi.

6.att. Saišu kardinalitātes

Pakomentēšu nedaudz attēlā 6 redzamās saišu kardinalitātes. Kardinalitāte 1:1 parāda to, ka 1 studentam var būt tikai 1 uzņemšanas dokumentu kopa un 1 uzņemšanas dokumentu kopa var būt piesaistīta tikai 1 studentam. Kardinalitāte 1:N parāda to, ka 1 īres līgumam tiek veikti vairāki maksājumi, bet 1 maksājums ir piesaistīts tikai 1 līgumam. Kardinalitāte N:N parāda to, ka 1 darbinieks var veikt vairākums pienākumus un 1 pienākumu var izpildīt vairāki darbinieki.

Realitātes piedalīšanās pakāpe saitē ar citu realitātiIr divas piedalīšanās pakāpes: pilnā un daļējā. Realitātei ir pilnā piedalīšanās pakāpe saitē, ja

viņas eksemplāra eksistencei ir obligāti nepieciešama citas realitātes eksemplāra eksistence. Realitātei ir daļējā piedalīšanās pakāpe saitē, ja viņas eksemplāra eksistencei nav obligāti nepieciešama citas realitātes eksemplāra eksistence. Pilno piedalīšanās pakāpi saitē bieži vien sauc par obligāto piedalīšanos. Nepilno piedalīšanās pakāpi saitē sauc arī par neobligāto piedalīšanos. Daļējo piedalīšanās pakāpi parāda ar aplīti. Attēlā ir parādītas tās pašas saites, kuras bija redzamas attēlā , bet tikai papildus ar piedalīšanos pakāpi.

9

7. att. Piedalīšanās pakāpes

Pakomentēšu nedaudz attēlā redzamās piedalīšanās pakāpes. Pirmajā piemērā students var pastāvēt bez uzņemšanas dokumentu kopas, savukārt uzņemšanas dokumentu kopa nevar eksistēt, ja nav students. Otrajā piemērā īres līgums var pastāvēt bez maksājumiem, bet maksājums nevar tikt izdarīts, ja nav līgums. Trešajā piemērā darbinieks nevar eksistēt kopmītnēs, ja viņam nav neviens pienākums, savukārt pienākums var pastāvēt bez darbinieka.

Vājā realitāteVājā realitāte ir realitāte, kurai neeksistē identificējošais atribūts un kura nevar būt unikāli

identificēta tikai ar tās atribūtiem. Tai ir jāsatur ārējā atslēga kopā ar tās atribūtiem, lai tiktu izveidota primārā atslēga. Vājā realitāte pati par sevi satur bezjēdzīgus datus, bet tiklīdz tā tiek sasaistīta ar citu realitāti, tā kopā veidojas dati ar jēgu. Vājā realitāte ER diagrammā tiek attēlota kā dubulttaisnstūris, savukārt saite ar vājo realitāti tiek attēlota ar dubultrombu. Vājās realitātes attēlojums ir parādīts attēlā .

8.att. Vājā realitāte

Vājās realitātes piemērs: Kopmītnes sūdzību grāmatiņa, kurā ir uzskaitītas kopmītnēs notiekušās sūdzības starp studentu un darbinieku, sūdzību ierosinātājs un divas ārējās atslēgas – atsauce uz studentu un atsauce uz darbinieku. Bez ārējām atslēgām būtu bezjēdzīgi un neunikāli dati.

Arc elementsArc elements apzīmē izvēles elementu. Arc elements dod iespēju izvēlēties kādu no diviem

vai vairākiem variantiem, no kuriem tikai viens būs patiess. Arc elementa attēlojums ir parādīts attēlā .

9.att. Arc eleemnts

Piemēram, kopmītnes liftu var salauzt vai nu students (realitāte R2) vai darbinieks (realitāte R3), bet ne abi reizē. Tas nozīmē, ka lifta salaušanas žurnālā (realitāte R1) parādīsies tikai viens konkrēts vaininieks: students vai darbinieks.

10

Enhanced-ER diagrammaER modelim ir daudz ierobežojumu. Lai varētu pilnvērtīgāk veidot datu bāzes datu

konceptuālo modeli tika izveidots ER modeļa paplašinājums – paplašinātais ER modelis (Enhanced ER jeb EER). ER modelis tika paplašināts ar superklases un apakšklases jēdzieniem. Superklase ir vispārējs realitātes tips, kam ir saite ar vienu vai vairākām apakšklasēm. Apakšklase ir superklases apakšgrupa; manto superklases atribūtus un satur savus unikālus atribūtus; kā arī var piedalīties saitēs ar citiem realitātes tipiem. Attēlā ir parādītā superklases un apakšklases notācija.

10.att. Superklases un apakšklases notācija

Tālāk uzskaitīšu noteikumus, kad izmantot superklases un apakšklases notāciju. Šo notāciju var izmantot, ja viens vai abi no šiem noteikumiem izpildās:

1.Ja realitātes tipā ir tādi atribūti, kas der tikai dažām instancēm, bet ne visām;2.Ja vienīgi apakšklases instances piedalās saitē ar kādu realitātes tipu.

Attēlā ir parādīts superklases un apakšklases piemērs.

11.att. Superklases un apakšklases piemērs

11

Attēlā redzamajā piemērā ir redzama superklases „Darbinieks” un tā apakšklases „Montieris” un „Apkopēja”. Apakšklases balstās uz amata kategoriju un ir savi unikāli atribūti kādi nav citiem superklases „Darbinieks” amatiem (1.noteikums). Kā arī studenta kopmītnes labošanas pieprasījumus ir iespējams pieprasīt tikai montieriem (2.noteikums).

Divi procesi, kas nodrošina superklases un apakšklase notāciju, ir specializācija (Specialization) un vispārināšana (Generalization). Specializācija ir process, kas definē vienu vai vairākas apakšklases no superklases, bāzējoties uz atšķirīgiem atribūtiem vai saitēm; „augšā-lejā” (top-down) pieeja. Vispārināšana ir process, kad no specializētām apakšklasēm tiek veidota superklase, bāzējoties uz visu superklašu kopīgajiem atribūtiem; „lejā-augšā” (bottom-up) pieeja.

Superklases un apakšklases ierobežojumiPastāv divu veida ierobežojumi: pilnība (Completeness) un sadalīšana (Disjointness).

Pilnība apskata jautājumu, vai superklases instancei obligāti ir jāatrodas vismaz vienā no apakšklasēm.Sadalīšana apskata jautājumu, vai superklases instance vienlaicīgi var atrasties divās vai vairākās apakšklasēs.

Pilnības ierobežojumsPastāv divi pilnības ierobežojuma likumi: pilnais specializācijas likums (dubultlīnijas notācija)

un daļējais specializācijas likums (vienas līnijas notācija). Pilnais specializācijas likums nosaka to, ka katrai superklases instancei obligāti ir jāpieder kādai no apakšklasēm. No superklases līdz sadalošajam aplim tiek izmantota dubultlīnija. Likuma piemērs apskatāms attēlā . Daļējais specializācijas likums nosaka to, ka superklases instance var nepiederēt nevienai no apakšklasēm. No superklases līdz sadalošajam aplim tiek izmantota viena līnija. Likuma piemērs apskatāms attēlā .

12.att. Pilnais specializācijas likums

Attēlā redzamais pilnā specializācijas likuma piemērs parāda to, studentam obligāti jāpieder kādai no apakšklasēm, jo ir uzskaitītas pilnīgi visas iespējamās apakšklases (dzimumi).

13.att. Daļējais specializācijas likums

12

Attēlā redzamais daļējā specializācijas likuma piemērs parāda to, darbiniekam nav obligāti jāpieder kādai no apakšklasēm, jo nav uzskaitītas pilnīgi visas iespējamās apakšklases (amati).

Sadalīšanas ierobežojumsPastāv divi sadalīšanas ierobežojuma likumi: sadalāmais likums (burta „d” notācija) un

pārklāšanās likums (burta „o” notācija).Sadalāmais likums nosaka to, ka superklases instance var vienlaicīgi piederēt tikai vienai no apakšklasēm. Likuma piemērs parādīts attēlā .Pārklāšanās likums nosaka to, ka superklases instance var vienlaicīgi piederēt divām vai vairākām apakšklasēm. Likuma piemērs parādīts attēlā .

14.att. Sadalāmais likums

Attēlā redzamais sadalāmā likuma piemērs parāda to, ka students vienlaicīgi var piederēt tikai vienam dzimumam.

15.att. Pārklāšanās likums

Attēlā redzamais pārklāšanās likuma piemērs parāda to, ka studentam var būt gan bakalaura grāds, gan maģistra.

Apakšklašu atdalīšanaApakšklašu atdalīšanu veic superklases atribūts, kura vērtības nosaka mērķa apakšklases.

Var atdalīt sadalāmajās apakšklasēs un pārklājamās apakšklasēs. Sadalāmajās apakšklasēs superklase atdala ar vienkāršo atribūtu, kuram pastāv viena vērtība (skatīt piemēru attēlā ). Pārklājamās apakšklasēs superklase atdala ar daudzvērtīgo atribūtu, kuram pastāv vairākas vērtības (skatīt piemēru attēlā 16).

13

16.att. Sadalāmās apakšklases

Attēlā 16 redzamais piemērs parāda to, ka ir iegūtas sadalāmās apakšklases ar superklases atribūta „Dzimums” palīdzību, kas sastāv no vienas vērtības: „V” vai „S”.

17.att. Pārklājamās apakšklases

Attēlā 17 redzamais piemērs parāda to, ka ir iegūtas pārklājamās apakšklases ar superklases atribūta „Grāds” palīdzību, kas var sastāvēt no vairākām vērtībām vienlaicīgi: „Bakalaurs”, „Maģistrs un „Doktors”.

Agregācija un kompozīcijaDivi papildus procesi, kas nodrošina superklases un apakšklase notāciju, ir agregācija un

kompozīcija, tikai šie procesi krasi atšķiras no procesiem specializācija un vispārināšana. Šie procesi ir plašāk pazīstami UML modelēšanās valodā. Agregācijā un kompozīcijā nepastāv mantošanas koncepts (superklasei un apakšklasēm ir savi unikāli atribūti), kā arī nepastāv iepriekš minētie ierobežojumi, kas attiecas uz specializāciju un vispārināšanu. Agregācijā un kompozīcijā kā superklase kalpo vesels un kā apakšklase daļa.

Agregācija ir "vesels-daļa" vai "daļa-no" attiecība, kurā apakšklases, kas ir superklases daļas, ir asociēti ar superklasi, kas ir šo daļu konteiners. Agregācijai apakšklašu apvienošanai arī tiek izmanos aplītis, bet tajā atrodas simbols „A”. Kā piemēru varētu minēt kopmītnes istabiņu, kurā ir, piemēram, šādas daļas: mēbeles un elektroniskās preces. Attēlā šis piemērs ir parādīts vizuālā veidā (agregācijas notācija).

18.att. Agregācijas piemērs

14

Agregācijā nepastāv saites integritātes. Galvenā agregācijas funkcija ir nodrošināt abstrakciju. Kompozīcija ir agregācijas gadījums: sastāvdaļas atrodas vesela iekšā un ja veselais ir

iznīcināts, daļas arī vairs nevar eksistēt. Piemēram, pastāv vesels kopmītne un daļa jumts. Ja tiek iznīcināta kopmītne, tad automātiski arī iznīcinās tās jumts. Attēlā šis piemērs ir parādīts vizuālā veidā.

19.att. Kompozīcijas piemērs

KlasifikācijaVēl pēdējais process, kas nodrošina superklases un apakšklase notāciju, ir klasifikācija. Uzreiz

jāpiezīmē, ka nevienā apskatītajā literatūras avotā par EER neko neatradu par tādu konceptu kā klasifikācija. Un arī pats neredzu jēgu, lai to atsevišķi izdalītu, jo uzskatu, ka šis koncepts pieder pie tās pašas specializācijas. Bet tā kā lekcijās tāds koncepts tika apskatīts, tad to arī atsevišķi apskatīju. Klasifikācija ir superklases iedalīšana apakšklasēs pēc kāda kritērija atribūta. Klasifikācija var būt pilna vai nepilna. Klasifikācija ir pilna, ja ir definētas visas superklases apakšklases (dubultlīnijas notācija), savukārt klasifikācija ir nepilna, ja ir definētas dažas vai ne visas superklases apakšklases (vienas līnijas notācija). Apakšklasēm nav savi unikāli atribūti. Kā piemēru var minēt superklasi „students”, kurš tiek sadalīts apakšklasēs „vīrietis” un „sieviete” pēc superklases atribūta „dzimums” (skatīt piemēru attēlā ).

20.att. Klasifikācijas piemērs

KategorijaKategorijas gadījumā apakšklase reprezentē superklašu instanču kolekciju, kas tiek dēvēta par

savienības tipu (union type) jeb kategoriju. Attēlā ir parādīta kategorijas notācija.

15

21.att. Kategorijas notācija

Kā redzams attēlā , tad kategorijas notācijas apzīmēšanai aplītī tiek izmantots „U” simbols. Kategorijas instancei obligāti ir jāatrodas vismaz vienā no superklasēm. Kategorija manto tikai vienas superklases atribūtus.

Arī kategorijā pastāv pilnības ierobežojums. Pastāv divi pilnības ierobežojuma likumi: pilnais specializācijas likums (dubultlīnijas notācija) un daļējais specializācijas likums (vienas līnijas notācija).

Izveidotais datubāzes konceptuālais modelis (EER diagramma) Esmu izveidojis kopmītnes datubāzes konceptuālo modeli ar EER diagrammas palīdzību, par ko plaši iepriekš aprakstīju šīs nodaļas ietvaros. Kopmītnes datubāzes konceptuālais modelis ir apskatāms attēlā 22.

.att. Kopmītnes datubāzes konceptuālais modelis

16

Lai labāk izprastu manis uzkonstruēto kopmītnes datubāzes konceptuālo modeli, apskaidrošu kādus konceptus esmu iekļāvis no ER diagrammas daļas (skatīt tabulu 2) un kādus no paplašinātās ER (EER) diagrammas daļas (skatīt tabulu 3). Visiem realitāšu tipiem ir izvēlēti konkrēti atribūti, tajā skaitā arī identificējošie, kā arī saitēm „veic” un „vada” ir pa atribūtam, ko visu var labi apskatīt attēlā 22.

Tabula 2

Pielietotie koncepti no ER diagrammas daļasSaite Saites veids Sasaistītie realitāšu tipi Saišu kardinalitāte Realitāšu tips ar daļēju

piedalīšanos pakāpi saitēkrāj Binārā Līgums-Maksājums 1:N Maksājumspiesaist. Binārā Itabiņa-Līgums 1:N Līgumsslēdz Binārā Students-Līgums 1:N Līgumsapstipr. Binārā Administrācija-Līgums 1:N Līgumslauž (1) Binārā Students-Liftu

salaušanas žurnāls (vājā)1:N Liftu salaušanas žurnāls

(vājā)lauž (2) Binārā Darbinieks-Liftu

salaušanas žurnāls (vājā)1:N Liftu salaušanas žurnāls

(vājā)saka (1) Binārā Students-Strīdu

grāmatiņa (vājā)1:N Strīdu grāmatiņa (vājā)

saka (2) Binārā Darbinieks-Strīdu grāmatiņa (vājā)

1:N Strīdu grāmatiņa (vājā)

veic Binārā Darbinieks-Pienākums N:N Darbiniekskomandē Unārā Apkopēja 1:N Apkopēja (padotā)vada Ternārā Administrācija-

Montieris-Projekts1:N:N -

Jāpiezīmē, ka saites „lauž (1)” un „lauž (2)” piedalās „Arc” elementa veidošanā.

Tabula 3

Pielietotie koncepti no paplašinātās ER diagrammas daļasProcess Superklase Apakšklase Pilnības ierobežojums Sadalīšanas

ierobežojumsSpecializācija Darbinieks Apkopēja, Montieris,

AdministrācijaDaļējais (d) Sadalāmais

Agregācija Istabiņa Mēbele, Elektroniskā prece

- -

Klasifikācija Students Vīrietis, Sieviete - -

Tālāk izveidotais datubāzes konceptuālais modelis tiks transformēts uz datubāzes loģisko modeli.

17

DB konceptuālā modeļa transformācija uz DB loģisko-fizisko modeliBāzējoties uz datubāzes konceptuālo modeli, iegūšu datubāzes loģisko-fizisko modeli. Tas ir,

tiks veikta manuāla transformācija no datubāzes konceptuālā modeļa uz datubāzes loģisko-fizisko modeli. Es izdomāju loģisko modeli un fizisko modeli uztvert kā vienu modeli, jo vizuāli modeļi ir ļoti līdzīgi, atšķirības, principā, slēpjas tikai to aprakstā. Loģiskajā modelī parādās šādas lietas: nepieciešamības gadījumā papildus realitāšu tipi, atribūti un saites, parādās primārās un arējās atslēgas, atrisināts saites N:N attēlojums, tiek veikta normalizācija. Fiziskajā modelī parādās šādas lietas: Realitāšu tipi pārtop par tabulām, to atribūti pārtop par kolonnām, ārējā atslēga kalpo kā tabulu sasaistes elements, deklaratīvie un saišu ierobežojumi. Fiziskais modelis ir paredzēts kādai konkrētai DBVS. Manā gadījumā būs Oracle DBVS. Primārā atslēga ir tabulas unikālais identifikators, savukārt ārējā atslēga ir identifikators, kas atļauj atkarīgai tabulai atsaukties uz tās vecāka tabulu. Tabulu sasaiste tiek parādīta ar vektoru, kur vektora gala punkts tiek norādīts vecāka tabulā. Loģiskajā-fiziskajā modelī neparādās saišu kardinalitāte N:N, tā tiek realizēta ar starptabulas palīdzību par ko vēlāk pastāstīšu transformācijas veikšanā. Tāpat loģiskajā-fiziskajā modelī var parādīties arī skati, kas ir saglabāts vaicājums, pieejams kā virtuāla tabula, kura reprezentē vaicājuma rezultātu.

Sākšu tad pamazām transformēt manis izveidoto EER diagrammu par datubāzes loģisko-fizisko modeli.

Binārās saites 1:N transformācijaBinārās saites 1:N transformācijas rezultātā tiek iegūtas 2 tabulas. Abām tabulām parādās

primārās atslēgas. Tabula, kura atrodas saites „N” pusē iegūst ārējo atslēgu, jo atsaucas uz vecāka tabulu. Attēlā ir parādīts transformācijas rezultāta piemērs par maksājumu un līgumu sasaisti.

23.att. Binārās saites 1:N transformācija

Binārās saites N:N transformācijaBinārās saites N:N transformācijas rezultātā tiek iegūtas 2 tabulas un 1 starptabula, kura

pārņem nosaukumu no saites. Starptabulā glabājas ārējās atslēgas no abām tabulām, kas piedalās saitē N:N, kā arī šīs arējās atslēgas kopā veido primāro atslēgu, lai izvairītos no dublikātiem un tukšām vērtībām. Ja saitei ir norādīts atribūts, tad tas arī parādās starptabulā, bet neietilpst primārās atslēgas veidošanā. Tabulas sasaiste ar starptabulu ir ar saišu kardinalitāti 1:N. Abām

18

saites N:N tabulām parādās primārā atslēga. Attēlā ir parādīts transformācijas rezultāta piemērs par darbinieku un pienākumu sasaisti (ar saites atribūtu).

24.att. Binārās saites N:N ar atribūtu transformācija

Vājās realitātes transformācijaVājās realitātes transformācijas rezultātā tiek iegūta tabula, kura iegūst ārējās atslēgas no

tām tabulām, ar kurām tā ir saistīta. Šīs ārējās atslēgas kopā ar pārējām tabulas kolonnām veido primāro atslēgu. Attēlā ir parādīts vājās realitātes transformācijas rezultāts.

25.att. Vājās realitātes transformācija

Specializācijas un vispārināšanas transformācijaSpecializācijas un vispārināšanas gadījumu ir iespējams transformēt vairākos variantos.

Apskatīšu katru no tiem. Pirmais variants ir tāds, ka gan superklase, gan apakšklases tiek transformētas par tabulām.

Šajā gadījumā superklases tabula satur tikai tās kolonnas, kas ir kopīgas visām apakšklasēm, savukārt apakšklasēm ir savas unikālas kolonnas. Apakšklases tabulas iegūst ārējo atslēgu no superklases tabulas, kura automātiski arī ir primārā atslēga. Attēlā ir parādīts pirmais specializācijas un vispārināšanas transformācijas rezultāta piemērs.

19

26.att. Specializācijas un vispārināšanas transformācija 1

Apskatot doto piemēru, rodas jautājums, kā, piemēram, kontrolēt to, lai apakšklasē „Montieris” atrastos tikai atsauces uz montiera amatu, nevis uz kādu citu amatu. Iespējamais variants ir pašā datubāzē nodrošināt arējās atslēgas kolonnu ar „ComboBox” elementu, kas ļautu izvēlēties tikai atsauces, kuras piemīt, piemēram, tikai montiera amatam.

Otrais variants ir tāds, ka superklase ir tabula, bet apakšklases ir skati. Superklases tabula sastāv no savām unikālajām kolonnām, kā arī no unikālajām apakšklases kolonnām. Tātad no visām iespējamām. Tas nozīmē, piemēram, ka konkrēta amata darbiniekiem dažās kolonnās vērtību nebūs, jo nav paredzēta kāda no kolonnām. Skati reprezentē apakšklasei raksturīgo vaicājumu. Piemēram, apakšklases „Montieri” gadījumā skats satur datus tikai par montieriem, kā arī skatā glabājas montierim raksturīgās unikālās kolonnas. Attēlā ir parādīts otrais specializācijas transformācijas rezultāta piemērs.

20

27.att. Specializācijas un vispārināšanas transformācija 2

Jāpiemin, ka dotajā piemērā transformācijas rezultātā nav attēlotas saites. Tas tāpēc, ka superklases tabula netiek saistīta ar apakšklases skatiem; tas būtu bezjēdzīgi. Visiem apakšklases skatiem ir paredzētas saites ar citām tabulām, tikai tās prasa vēl neapskatītas transformācijas, par kurām pastāstīšu nedaudz vēlāk. Skatiem pašā datubāzē varētu būt problēma ar saites integritāti (referential integrity), jo, principā, tabulas nenodrošina ārējo atslēgu uz skata identificējošo kolonnu. Vēl jāpiebilst, ka skatu realizācija īsti neatbilst apakšklases definīcijai, jo skats nemanto visas kolonnas no superklases tabulas, kā arī tam nav savas unikālas kolonnas. Bet toties skats it kā var piedalīties saitē.

Ternārās saites transformācijaTernārās saites transformācijas rezultātā tiek iegūtas 3 tabulas ar primārām atslēgām un 1

starptabula ar arējām atslēgām, ko tā ieguvusi no šīm 3 tabulām, kā arī starptabula vēl papildus var saturēt saites atribūtu. Svarīgi ir novērtēt, kuras starptabulas ārējās atslēgas automātiski kalpo arī kā primārās atslēgas. Visas ārējās atslēgas visos ternārās saites gadījumos noteikti nevar kalpot kā primārā atslēga, jo tad pastāv iespēja, ka dublēties var kāds pāris. Tāpēc ir jāizvērtē rūpīgi ternārās saites kardinalitāte. Manā gadījumā ternārās saites kardinalitāte ir 1:N:N. Attēlā ir parādīts ternārās saites 1:N:N transformācijas rezultāts.

21

28.att. Ternārās saites 1:N:N transformācija

Dotajā piemērā ir redzams, ka ternārās saites realizācijā ir iesaistītas 2 darbinieku apakšklases un projekts. Starptabulā par primāro atslēgu kļūst ārējā atslēga uz montieri un projektu, jo šīs tabulas atrodas ternārās saites „N” pusē. Ja saišu kardinalitāte būtu N:N:N, tad visās ārējās atslēgas kļūtu par primāro atslēgu. Ja saišu kardinalitāte būtu 1:1:1, tad viens pāris būtu primārā atslēga, bet atlikušie 2 pāri kļūtu par unikālajām atslēgām. Šajā gadījumā būtu pirms transformācijas jānorāda, kurš no pāriem kalpotu kā primārā atslēga. Saišu kardinalitāte 1:1:N vienam 1:N pārim būtu jābūt primārai atslēgai, otram 1:N pārim būtu jākalpo par unikālo atslēgu. Jāpiezīmē, ka ternārajā saitē daļēja piedalīšanās pakāpe neeksistē, jo katram realitāšu tipam saitē obligāti ir jābūt saistītam ar pārējiem diviem realitāšu tipiem.

Unārās saites transformācijaUnārās saites transformācijas rezultātā tiek iegūta 1 tabula vai arī 1 tabula kopā ar 1

starptabulu. Tas ir atkarībā no saites kardinalitātes. Manā gadījumā tiek izmantota saišu kardinalitāte 1:N, kas prasa tikai 1 tabulu. Transformācijas rezultātā tiek iegūta 1 tabula ar primāro atslēgu un vēl papildus ārējo atslēgu, kas tiek iegūta no tās pašas tabulas. Attēlā ir parādīts unārās saites 1:N transformācijas rezultāts.

29.att. Unārās saites 1:N transformācija

22

Klasifikācijas transformācijaGribētu atgādināt, ka nevienā apskatītajā literatūras avotā par EER neko neatradu par tādu

konceptu kā klasifikācija. Un arī pats neredzu jēgu, lai to atsevišķi izdalītu, jo uzskatu, ka šis koncepts pieder pie tās pašas specializācijas. Šo konceptu es ievietoju savā konceptuālajā modelī, bet bez īpašas nozīmes, jo apakšklases nepiedalās nevienā saitē. Klasifikācijas transformācijas rezultātā superklase kļūst par tabulu ar primāro atslēgu, bet apakšklases par skatiem. Attēlā ir parādīts klasifikācijas transformācijas rezultāta piemērs.

30.att. Klasifikācijas transformācija

Agregācijas un kompozīcijas transformēšanaEER diagrammā agregācijas un kompozīcijas process nav tik plaši pazīstams kā tas ir UML

modelēšanā. Agregācijā nepastāv saites integritātes. Galvenā agregācijas funkcija ir nodrošināt abstrakciju. Agregācijas transformācijas rezultātā tiek iegūtas 3 tabulas, kuras savstarpēji nav sasaistītas. Kompozīcija ir agregācijas gadījums: sastāvdaļas atrodas veselā iekšā un ja veselais ir iznīcināts, daļas arī vairs nevar eksistēt. Pēc šī apgalvojuma var spriest, ka kompozīcijas gadījumā saitēm starp tabulām ir jāapstāv. Transformācijas rezultāts varētu būt šāds: 1 superklases tabula un 2 apakšklases tabulas, kur superklases tabula ir sasaistīta ar apakšklases tabulām saitē 1:1. Un vēl papildus 1 skats, kas parāda kompozīciju starp kopmītni un jumtu. Savā datubāzes konceptuālajā modelī neesmu iekļāvis kompozīciju, taču piedāvāju šādu piemēru: kā vesels kalpo „Kopmītne”, bet kā daļa „Jumts”. Ja kopmītne tiek iznīcināta, tad automātiski iznīcinās ar jumts. Attēlā 31 ir parādīts kompozīcijas transformācijas rezultāts.

31.att. Kompozīcijas transformācija

23

Arc elementa transformācijaArc elementa transformācijas rezultātā tiek iegūta tabula, kurai viena ārējā atslēga atsaucās

uz divām vai vairākām tabulām. Visām tabulām ar ko ir saistīta šī Arc rezultāta tabula, primārās atslēgas vērtības nedrīkst pārklāties savā starpā, jo pretējā gadījumā izpildīsies vairākas saites vienlaicīgi, tādējādi nerealizējot izslēdzošo OR (XOR). Lai izvairītos no šāda veida problēmas, datubāzē ir jāglabājas virknei, kas ģenerēs visām Arc iesaistītajām tabulām primārās atslēgas vērtības. Attēlā ir parādīts Arc elementa transformācijas rezultāts.

32.att. Arc elementa transformācija

Kopējais realizētais datubāzes loģiskais-fiziskais modelisEsmu pārtransformējis EER diagrammu par datubāzes loģisko-fizisko modeli, kas pilnībā ir

aplūkojams attēlā 32.

24

.att. Kopmītnes datubāzes loģiskais modelis

Kā redzams attēlā 32, tad specializācijas procesa attēlošanai esmu izvēlējies pirmo transformācijas variantu – superklase un apakšklases ir tabulas. Bet tik pat labi varēju attēlot arī otro variantu – superklase ir tabula, bet apakšklases ir skati.

Nākamais solis tā kā būtu loģiskā-fiziskā modeļa pārveidošana par Oracle DBVS SQL definējumiem. Bet pirms tam tiks veikta topošās datubāzes normalizācija.

25

Datubāzes normalizācijaDatubāzes normalizācija ir sistemātisks ceļš, kas nodrošina to, lai datubāzes struktūra būtu

piemērota universālai vaicājumu veikšanai, atbrīvoties no „Insert”, „Update” un „Delete” modificēšanas anomālijām, kuras var novest pie datu integritātes zaudēšanas, kā arī atbrīvoties no datu dublēšanās. Lai labāk izprastu modificēšanas anomālijas, paskaidrošu tās ar tabulu palīdzību (skatīt attēlu ).

lig_kods lig_nr nosl_dat ist_id ist_nr123 AS345AU 04.09.2008 1 604B124 BD567AU 05.09.2007 2 503C125 TW560AI 05.09.2007 3 502A126 DF456AI 05.09.2007 1 604B127 VB334LK 06.09.2007 4 501B

lig_kods lig_nr nosl_dat ist_id123 AS345AU 04.09.2008 1124 BD567AU 05.09.2007 2125 TW560AI 05.09.2007 3126 DF456AI 05.09.2007 1127 VB334LK 06.09.2007 4

ist_id ist_nr1 604B2 503C3 502A4 501B

Līgumi_Istabiņas tabula

Līgumi tabula

Istabiņas tabula

34.att. Modificēšanas anomāliju piemēru tabulas

Datu redundances problēmas, kas rodas nenormalizētā datubāzes tabulā, ir uzskatāmas par modificēšanas anomālijām. Modificēšanas anomālijas iedalās 3 klasēs: „Insert” anomālija, „Update” anomālija un „Delete” anomālija. Tagad paskaidrošu katru anomālijas klasi ar attēlā redzamo tabulu palīdzību. „Insert” anomālija

Lai ievadītu informāciju par līgumu tabulā „Līgumi_Istabiņas”, kas paredzēta, piemēram, istabiņai „1”, ir jāievada korekta informācija par istabiņu „1”, lai istabiņas informācija sakristu ar pārējiem tabulas ierakstu datiem par istabiņu „1”. Tas ir ķepīgs un nekorekts paņēmiens. Lai ievadītu informāciju tabulā „Līgumi_Istabiņas” par istabiņu uz kuru nav noslēgts līgums, tad ir jāatstāj tukši visi dati par līgumu, bet tas nav iespējams, jo kolonna „lig_kods” ir primārā atslēga.

„Delete” anomālijaIzdzēšot kādu ierakstu no tabulas „Līgumi_Istabiņas”, tiek dzēsta informācija ne tikai par

līgumu, bet arī par istabiņu. Un līdz ar to datubāzē informācija par kādu istabiņu vairāk neeksistē.

„Update” anomālijaMainot informāciju ierakstā par kādu istabiņu tabulā „Līgumi_Istabiņas”, ir jānodrošina, lai

pārējos ierakstos arī būtu tādi paši dati par šo istabiņu. Tas ir ķepīgs un nekorekts paņēmiens.

Lai izvairītos no šīm anomālijām, tabula „Līgumi_Istabiņas” ir nepieciešams sadalīt divās tabulās „Līgumi” un „Istabiņas”, tas ir, sadalīt noteiktās informācijas klasēs (dekompozīcija). Izpildot

26

šādu variantu tabulā „Līgumi” glabājas informācija par līgumiem un atsauces uz tabulu „Istabiņas”, kurā glabājas informāciju par katru istabiņu.

Normalizācijas pamatprincips ir datu funkcionālā atkarība. Tagad nedaudz par to pastāstīšu.

Datu funkcionālā atkarībaDatu funkcionālā atkarība apraksta saites starp tabulas laukiem (kolonnām). Piemēram, ja

„A” un „B” ir tabulas lauki, tad „B” ir funkcionāli atkarīgs no „A”, ja katra „A” vērtība ir asociēta tikai ar vienu „B” vērtību. Datu funkcionālās atkarība ilustratīvi ir parādīta attēla .

35.att. Datu funkcionālās atkarības piemērs

Lauks vai lauku grupa, kas atrodas kreisajā pusē datu funkcionālās atkarības piemērā (attēls ), tiek saukts par determinantu. Determinanta piemērs: Tabulas „Līgumi_Istabiņas” (attēls 34) lauks „lig_kods” funkcionāli nosaka lauku „lig_nr”

Datu funkcionālās atkarība var tikt iedalīta 3 klasēs: „Pilna funkcionālā atkarība”, „Daļēja funkcionālā atkarība” un „Transitīva funkcionālā atkarība”. Pilna funkcionālā atkarība

Norāda to, ja „A” un „B” ir tabulas lauki, ka „B” ir pilnīgi funkcionāli atkarīgs no „A”, ja „B” ir funkcionāli atkarīgs no „A”, bet nav atkarīgs no jebkādas piemītošas „A” apakškopas. Piemērs no tabulas „Līgumi_Istabiņas” (attēls 34): „lig-id””ist_id”.

Daļēja funkcionālā atkarībaNorāda to, ja „A” un „B” ir tabulas lauki, ka „B” ir daļēji funkcionāli atkarīgs no „A”, ja ir kāds

lauks, kas var tikt likvidēts no „A”, un tik un tā saglabājas funkcionālā atkarība. Piemērs no tabulas „Līgumi_Istabiņas” (attēls 34): „lig_id”, „lig_num””ist_id”.

Transitīva funkcionālā atkarība„A”, „B” un „C” ir tabulas lauki. Ja „A” ir funkcionāli atkarīgs no „B” un „B” ir funkcionāli

atkarīgs no „C” , tad „C” ir transitīvi atkarīgs no „A” ar „B” lauku. Piemērs no tabulas „Līgumi_Istabiņas” (attēls 34): Pieņemsim, ka ir šādas funkcionālās atkarības – „lig_kods””lig_num”, „nosl_dat”, „ist_id”, „ist_nr”; „ist_id””ist_nr”. Tātad, lauks „lig_kods” funkcionāli nosaka „ist_nr” ar „ist_id” lauku.

Pastāv pāris likumi datubāzes normalizācijai. Katrs likums tiek dēvēts par „normālformu”. Tagad nedaudz par tām.

NormālformasSākotnēji pastāvēja 3 normālformas datubāzes normalizācijai: Pirmā normālforma (1NF),

Otrā normālforma (2NF) un trešā normālforma (3NF). Vēlāk R. Boiss un E. F. Kodds ieviesa spēcīgāku trešās normālformas definējumu, kas tika nosaukts par Boisa-Kodda normālformu (BCNF). Izņemot pirmo normālformu, visas pārējās ir bāzētas uz datu funkcionālo atkarību. Pastāv arī vēl tālākas normālformas aiz Boisa-Kodda normālformu, kā ceturtā normālforma (4NF) un piektā normālforma (5NF). Kaut gan šīs normālformas tiek pielietotas situācijās, kuras pastāv ļoti reti.

27

Pirmā normālforma (1NF)Lai tabula apmierinātu pirmās normālformas prasības, tai ir jāsatur tikai atomāras vērības.

Atomāras nozīmē nedalāmas, katra kolona satur mazāko iespējamo vērtības kopumu, kas sīkāk nav sadalāms. Piemēram, adresi pareizi būtu jāglabā sadalītā veidā (lauki – rajons, pilsēta, iela, u.c.), nevis visu vienā teksts laukā.

Otrā normālforma (2NF)Tabula ir otrajā normālformā, ja tā ir pirmajā normālformā un nav nevienas daļējās

funkcionālās atkarības. Katrs tabulas ne atslēgas lauks ir pilni funkcionāli atkarīgs no primārās atslēgas lauka. Vienkārši sakot, katrs ne atslēgas lauks ir norāde uz kādu primāro atslēgu.

Trešā normālforma (3NF)Tabula ir trešajā normālformā, ja tā apmierina otrās normālformas prasības un katrs ne

atslēgas lauks netransitīvi ir atkarīgs no primārās atslēgas lauka. Vienkārši sakot, visi ne atslēgas lauki ir savstarpēji neatkarīgi (tabula nesatur laukus, kas ir iegūstami no pārējo lauku kombinācijām un matemātiskām operācijām). Kā piemēru varētu minēt summas lauku, kas ir atkarīgs no citiem laukiem. Šādu lauku nedrīkst attēlot tabulā.

Boisa-Kodda normālforma (BCNF)Tabula apmierina trešās normālformas prasības, ja katrs determinants ir iespējamā primārā

atslēga.

Ceturtā normālforma (4NF)Tabula apmierina ceturtās normālformas prasības, ja tā apmierina Boisa-Kodda

normālformas prasības un visas daudzvērtīgās saites ir funkcionālas saites no iespējamās primāras atslēgas.

Piektā normālforma (5NF)Tabula apmierina piektās normālformas (projekciju apvienošanas) prasības tikai tad, kad

katra apvienošanas projekcija satur tabulas iespējamo primāro atslēgu.

Attēlā ir parādīts normālformu pakārtotības koks.

28

36.att. Normālformu pakārtotības koks

Izveidoto loģisko-fizisko modeli pārbaudīšu, pielietojot Boisa-Kodda normālformu.

DB normalizācija ar Boisa-Kodda normālformuLai pārbaudītu vai tabulas apmierina Boisa-Kodda normālformas prasības, ir automātiski

jāpārbauda vai izpildās pirmās 3 normālformas. Sākotnēji parādīšu piemēru tabulai, kurai izpildās Boisa-Kodda normālforma. Kā piemēra tabulu izvēlos „Līgumi” (skatīt attēlu).

37.att. Tabula "Līgumi"

Tabula „Līgumi” apmierina pirmo normālformu, jo satur kolonnas tikai ar atomārām vērtībām. Tā apmierina otro normālformu, jo katrs ne atslēgas lauks ir pilni funkcionāli atkarīgs no primārās atslēgas lauka: „lig_kods””lig_num”, „nosl_dat”. Tabula arī apmierina trešo normālformu, jo visi ne atslēgas lauki ir savstarpēji neatkarīgi. Lai noskaidrotu, vai tabula apmierina Boisa-Kodda normālformu ir jāpārbauda vai visi determinanti ir iespējamās primārās atslēgas. Pārbaude ir apskatāma tabulā 4.

Tabula 4

Boisa-Kodda normālformas pārbaude tabulai „Līgumi”Iespējamā primārā atslēga Determinants

l_kods l_kodslig_nr lig_nr

29

Kā redzams tabulā 4, tad katrs determinants ir iespējama primārā atslēga. Šim piemēram var uzzīmēt funkcionālās atkarības diagrammu (skatīt attēlu ).

38.att. Funkcionālās atkarības diagramma

Tālāk parādīšu tabulas piemēru, kas neapmierina Boisa-Kodda normālformu. Papētot manu izstrādāto loģisko-fizisko modeli nespēju atrast nevienu tabulu, kas neapmierinātu Boisa-Kodda normālformu, tāpēc nāksies izdomāt piemēru. Kā piemēru varu piedāvāt to pašu piemēru, kas redzams attēlā 34 (skatīt attēlu ).

lig_kods lig_nr nosl_dat ist_id ist_nr123 AS345AU 04.09.2008 1 604B124 BD567AU 05.09.2007 2 503C125 TW560AI 05.09.2007 3 502A126 DF456AI 05.09.2007 1 604B127 VB334LK 06.09.2007 4 501B

lig_kods lig_nr nosl_dat ist_id123 AS345AU 04.09.2008 1124 BD567AU 05.09.2007 2125 TW560AI 05.09.2007 3126 DF456AI 05.09.2007 1127 VB334LK 06.09.2007 4

ist_id ist_nr1 604B2 503C3 502A4 501B

Līgumi_Istabiņas tabula

Līgumi tabula

Istabiņas tabula

39.att. Boisa-Kodda normālformas pārbaude

Tiks pārbaudīta tabula ar nosaukumu „Līgumi_Istabiņas”. Tā apmierina pirmo normālformu, jo satur kolonnas tikai ar atomārām vērtībām. Tā apmierina otro normālformu, jo katrs ne atslēgas lauks ir pilni funkcionāli atkarīgs no primārās atslēgas lauka. Tabula neapmierina trešo normālformu, jo „lig_kods” funkcionāli nosaka „ist_nr” ar „ist_id” lauku. Lai tabula apmierinātu trešo normālformu, istabiņas dati ir atsevišķi jānodala jaunā tabulā (dekompozīcijas veikšana). Dekompozīcijas rezultāts ir parādīts attēlā 39, kur tabula „Līgumi_Istabiņas” ir sadalīta divās tabulās „Līgumi” un „Istabiņas”. Dekompozīcijas rezultātā abas tabulas apmierina gan trešo normālformu, gan Boisa-Kodda normālformu.

Pēc normalizācijas veikšanas seko beidzamā daļa - loģiskā-fiziskā modeļa pārveidošana par Oracle DBVS SQL definējumiem.

30

Oracle DBVS SQL definējumiBāzējoties uz izstrādāto loģisko-fizisko modeli tiks izveidoti SQL definējumi, ar kuru palīdzību

var izstrādāt datubāzi Oracle vidē. Loģiskajā-fiziskajā modelī vizuāli neparādās datubāzes integritātes ierobežojumi, tie parādās modeļa aprakstā. Integritātes ierobežojumi ierobežo lauku vērtības datubāzē. Oracle vidē pastāv 6 tipu integritātes ierobežojumi, kurus esmu uzskaitījis tabulā 5.

Tabula 5

Oracle vides integritātes ierobežojumiIntegritātes ierobežojums Apraksts

NOT NULL Nepieļauj tabulas laukam saturēt tukšas vērtībasUNIQUE Kontrolē to, lai tabulas lauka vai lauku kombinācijas vērtības būtu unikālas.

Taču pieļauj vērtībām būt tukšām. PRIMARY KEY Ir ierobežojumu NOT NULL un UNIQUE kombinācija. Ierobežojums var tikt

pielietots laukam vai lauku kombinācijai un tikai vienu reizi.FOREIGN KEY Divu tabulu saites ierobežojums. Ierobežojums identificē lauku vai lauku

kombināciju vienā tabulā („bērna”), kas atsaucas uz lauku vai lauku kombināciju citā tabulā („vecāka”). FOREIGN KEY lauks vai lauku kombinācija parasti atsaucas uz PRIMARY KEY lauku vai lauku kombināciju

CHECK Kontrolē lauka vērtības pēc noteikta kritērijaREF Ļauj aprakstīt saiti starp REF lauku un objektu uz kā tas atsaucas

Pirmie pieci integritātes ierobežojumi attiecas uz relāciju datubāzi, savukārt sestais attiecas uz relāciju-objektu datubāzi. SQL definējumi attieksies tikai uz relāciju datubāzi, tāpēc tiks izmantoti tikai pirmie pieci integritātes ierobežojumi. Tagad nedaudz detalizētāki par divu tabulu saites ierobežojumu FOREIGN KEY. Ierobežojuma sintakse ir šāda:CONSTRAINT fk_kolonna FOREIGN KEY (kolonna1, kolonna2, ... kolonna_n) REFERENCES vecāka_tabula (kolonna1, kolonna2, ... kolonna_n) ON DELETE dzēšanas_nosacījums Pastāv šādi dzēšanas nosacījumi:ON DELETE CASCADE – izdzēšot ierakstu no „vecāka” tabulas, tad „bērna” tabulas atsauces ieraksti arī izdzēsies. ON DELETE SET NULL – izdzēšot ierakstu no „vecāka” tabulas, tad „bērna” tabulas atsauces ieraksti saturēs tukšu vērtību FOREIGN KEY kolonnā.

Jāpiemin, ka loģiskajā-fiziskajā modelī arī netika parādīti lauku datu tipi, bet tie noteikti atspoguļosies SQL definējumos.

31

SQL definējumu rakstīšanaSākšu ar specializācijas pirmo gadījumu, kurā ir iesaistītas 4 tabulas „Darbinieki”,

„Administracija”, „Montieri” un „Apkopejas”, kura atsevišķi satur vēl unāro saiti (skatīt attēlu ).

40.att. Specializācija gadījums 1 un unārā saite

SQL definējumi:CREATE TABLE darbinieki(d_kods NUMBER, var VARCHAR2(40), uzv VARCHAR2(40), tel VARCHAR2(8), amats VARCHAR2(50));

ALTER TABLE darbiniekiADD(CONSTRAINT pk_darbinieki PRIMARY KEY (d_kods),CONSTRAINT check_tel CHECK(LENGTH(tel)=8));

CREATE TABLE administracija(d_kods1 NUMBER);

ALTER TABLE administracijaADD (CONSTRAINT fk_administracija FOREIGN KEY (d_kods1)REFERENCES darbinieki(d_kods)ON DELETE CASCADE,CONSTRAINT pk_administracija PRIMARY KEY (d_kods1));

CREATE TABLE montieri(d_kods2 NUMBER, kvalif VARCHAR2(50));

ALTER TABLE montieriADD (CONSTRAINT fk_montieri FOREIGN KEY (d_kods2)REFERENCES darbinieki(d_kods)ON DELETE CASCADE,CONSTRAINT pk_montieri PRIMARY KEY (d_kods2));

CREATE TABLE apkopejas(d_kods3 NUMBER, d_kods3p NUMBER, korp VARCHAR2(2), iesauka VARCHAR2(40));

ALTER TABLE apkopejasADD (CONSTRAINT fk_apkopejas FOREIGN KEY (d_kods3)REFERENCES darbinieki(d_kods)ON DELETE CASCADE,CONSTRAINT pk_apkopejas PRIMARY KEY (d_kods3),CONSTRAINT fk_komande FOREIGN KEY(d_kods3p)REFERENCES apkopejas(d_kods3)ON DELETE CASCADE);

ALTER TABLE apkopejasMODIFY d_kods3p NOT NULL;

Tagad parādīšu specializācijas otro gadījumu, kurā iesaistīta 1 tabula „Darbinieki” un 3 skati „administracija_view”, „”montieri_view”, „apkopejas_view” (skatīt attēlu ).

32

41.att. Specializācijas gadījums 2

SQL definējumi:create or replace view administracija_view (d_kods, var, uzv, tel, CONSTRAINT pk_dkods1 PRIMARY KEY (d_kods) RELY DISABLE NOVALIDATE) asselect d_kods, var, uzv, telfrom darbiniekiwhere lower(amats)='administracija';

create or replace view montieri_view (d_kods, var, uzv, tel, CONSTRAINT pk_dkods2 PRIMARY KEY (d_kods) RELY DISABLE NOVALIDATE) asselect d_kods, var, uzv, telfrom darbiniekiwhere lower(amats)='montieris';

create or replace view apkopejas_view (d_kods, var, uzv, tel, CONSTRAINT pk_dkods3 PRIMARY KEY (d_kods) RELY DISABLE NOVALIDATE) asselect d_kods, var, uzv, telfrom darbiniekiwhere lower(amats)='apkopeja';

Tālāk parādīšu ternārās saites 1:N:N realizāciju, kurā iesaistās jau 2 izveidotās tabulas „Administracija” un „Montieri”, starptabula „vada” un tabula „Projekti” (skatīt attēlu ).

42.att. Ternārā saite 1:N:N ar tabulām

SQL definējumi:CREATE TABLE projekti(pr_id NUMBER, pr_nos VARCHAR2(50), sak_dat DATE, beig_dat DATE);

ALTER TABLE projektiADD CONSTRAINT pk_projekti PRIMARY KEY (pr_id);

CREATE TABLE vada(d_kods2 NUMBER, pr_id NUMBER, d_kods1 NUMBER, uzd VARCHAR2(40));

ALTER TABLE vadaADD(CONSTRAINT fk_vada2 FOREIGN KEY(d_kods2)REFERENCES montieri(d_kods2)ON DELETE CASCADE,

33

CONSTRAINT fk_vada3 FOREIGN KEY(pr_id)REFERENCES projekti(pr_id)ON DELETE CASCADE,CONSTRAINT fk_vada1 FOREIGN KEY(d_kods1)REFERENCES administracija(d_kods1)ON DELETE CASCADE,CONSTRAINT pk_vada PRIMARY KEY(d_kods2,pr_id));

Tālāk parādīšu to pašu ternārās saites realizāciju, tikai šoreiz iesaistās jau 2 izveidotie skati „administracija_view” un „montieri_view”, starptabula „vada” un tabula „Projekti”. Tikai uzreiz jāpiemin, ka tabula nevar atsaukties uz skata identificējošo kolonnu. Nepastāv saites ierobežojums. Skatīt piemēru attēlā .

43.att. Ternārā saite 1:N:N ar skatiem

SQL definējumi:ALTER TABLE vadaADD(CONSTRAINT fk_vada2 FOREIGN KEY(d_kods2)REFERENCES montieri_view(d_kods1)ON DELETE CASCADE,CONSTRAINT fk_vada3 FOREIGN KEY(pr_id)REFERENCES projekti(pr_id)ON DELETE CASCADE,CONSTRAINT fk_vada1 FOREIGN KEY(d_kods1)REFERENCES administracija_view(d_kods)ON DELETE CASCADE,CONSTRAINT pk_vada PRIMARY KEY(d_kods2,pr_id));

Tālāk parādīšu binārās saites N:N SQL definējumu, kurā iesaistās jau izveidotā tabula „Darbinieki”, starptabula „veic” un tabula „Pienakumi” (skatīt attēlu ).

44.att. Binārā saite N:N

34

Nenostrādās

SQL definējumi:CREATE TABLE pienakumi(pien_id NUMBER, nos VARCHAR2(50), gr_pak NUMBER);

ALTER TABLE pienakumiADD(CONSTRAINT pk_pienakumi PRIMARY KEY (pien_id),CONSTRAINT check_gr_pak CHECK(gr_pak BETWEEN 1 AND 10));

CREATE TABLE veic(d_kods NUMBER, pien_id NUMBER, maksa_h NUMBER(6,2));

ALTER TABLE veicADD(CONSTRAINT fk_veic1 FOREIGN KEY(d_kods)REFERENCES darbinieki(d_kods)ON DELETE CASCADE,CONSTRAINT fk_veic2 FOREIGN KEY(pien_id)REFERENCES pienakumi(pien_id)ON DELETE CASCADE,CONSTRAINT pk_veic PRIMARY KEY(d_kods,pien_id));

Tālāk sekos vājās realitātes SQL definējums, kurā iesaistās jau izveidotā tabula „Darbinieki”, tabula „Stridu_gramatina” un tabula „Studenti” (skatīt attēlu ).

45.att. Vājā realitāte

SQL definējumi:CREATE TABLE studenti(p_kods NUMBER, var VARCHAR2(40), uzv VARCHAR2(40), tel VARCHAR2(8), dzim VARCHAR2(10));

ALTER TABLE studentiADD(CONSTRAINT pk_studenti PRIMARY KEY (p_kods),CONSTRAINT check_tel2 CHECK(LENGTH(tel)=8),CONSTRAINT check_dzim CHECK(dzim IN('V','S')));

create table stridu_gramatina(p_kods number, d_kods number, strids varchar2(256), kas varchar2(10), str_dat date);

ALTER TABLE stridu_gramatinaADD(CONSTRAINT fk_saka1 FOREIGN KEY(p_kods)REFERENCES studenti(p_kods)ON DELETE CASCADE,CONSTRAINT fk_saka2 FOREIGN KEY(d_kods)REFERENCES darbinieki(d_kods)ON DELETE CASCADE,CONSTRAINT pk_stridu_gramatina PRIMARY KEY(p_kods,d_kods,strids,kas,str_dat),CONSTRAINT check_kas check(kas in('S','D')));

Nākamais būs Arc elementa SQL definējums, kurā iesaistās jau izveidotās tabulas „Darbinieki” un „Studenti”, kā arī tabula „Liftu_salausanas_zurnals” (skatīt attēlu ).

35

46.att. Arc elements

SQL definējumi:CREATE TABLE liftu_salausaunas_zurnals(kluda VARCHAR2(256), sal_dat DATE, s_d NUMBER);

ALTER TABLE liftu_salausaunas_zurnalsADD(CONSTRAINT fk_lauz1 FOREIGN KEY(s_d)REFERENCES studenti(p_kods)ON DELETE CASCADE,CONSTRAINT fk_lauz2 FOREIGN KEY(s_d)REFERENCES darbinieki(d_kods)ON DELETE CASCADE,CONSTRAINT pk_liftu_salausaunas_zurnals PRIMARY KEY(kluda, sal_dat, s_d));

CREATE SEQUENCE arc1 START WITH 1000 INCREMENT BY 1 NOCACHE NOCYCLE;

Viena virkne tiek pielietota tabulām „Studenti” un „Darbinieki”, lai būtu iespējams realizēt Arc elementu.

Tālāk tiks parādīts klasifikācijas SQL definējums, kurā iesaistās jau izveidotā tabula „Studenti” un divi skati „Virietis”, „Sieviete” (skatīt attēlu ).

47.att. Klasifikācija

SQL definējumi:create or replace view virietis_view (p_kods, var, uzv, tel) asselect p_kods, var, uzv, telfrom studentiwhere lower(dzim)='V';

create or replace view sieviete_view (p_kods, var, uzv, tel) asselect p_kods, var, uzv, telfrom studentiwhere lower(dzim)='S';

Kā pēdējais SQL definējums tiks parādītas 2 binārās saites 1:N, kurās iesaistās tabulas „Istabinas”, „Ligumi” un „Maksajumi” (skatīt attēlu ).

36

48.att. 2 binārās saites 1:N

SQL definējumi:create table istabinas(ist_id number, ist_nr varchar2(4), viet_sk number, plat number (2,2));

ALTER TABLE istabinasADD(CONSTRAINT pk_istabinas PRIMARY KEY (ist_id),CONSTRAINT check_ist_nr CHECK(LENGTH(ist_nr)=4),CONSTRAINT check_viet_sk CHECK(viet_sk between 1 and 4));

create table ligumi(l_kods number, lig_nr varchar2(8), nosl_dat date, d_kods1 number, p_kods number, ist_id number);

ALTER TABLE ligumiADD(CONSTRAINT fk_piesaist FOREIGN KEY(ist_id)REFERENCES istabinas(ist_id)ON DELETE CASCADE,CONSTRAINT fk_sledz FOREIGN KEY(p_kods)REFERENCES studenti(p_kods)ON DELETE CASCADE,CONSTRAINT fk_apstipr FOREIGN KEY(d_kods1)REFERENCES administracija(d_kods1)ON DELETE CASCADE,CONSTRAINT pk_ligumi PRIMARY KEY(l_kods));

ALTER TABLE ligumiMODIFY (d_kods1 NOT NULL,p_kods NOT NULL, ist_id NOT NULL);

create table maksajumi(maks_id number, maks_nr varchar2(10), cena number(3,2), maks_dat date, l_kods number);

ALTER TABLE maksajumiADD(CONSTRAINT fk_kraj FOREIGN KEY(l_kods)REFERENCES ligumi(l_kods)ON DELETE CASCADE,CONSTRAINT pk_maksajumi PRIMARY KEY(maks_id));

ALTER TABLE maksajumiMODIFY l_kods NOT NULL;

37

SecinājumiTātad, ir izstrādāts pirmais praktiskais darbs, kurā bija jāprojektē datubāze struktūras,

neizmantojot CASE rīkus. Kā problēmvidi izvēlējos kopmītni, kurai izstrādāju datu plūsmas diagrammu (DPD); datubāzes konceptuālo modeli, izmantojot P. Čena notāciju; datubāzes konceptuālā modeļa transformāciju uz datubāzes loģisko-fizisko modeli un SQL definējumus, paredzētus Oracle DBVS.

Par datu plūsmas diagrammu iepriekš neko nebiju dzirdējis, un tas man ir kas jauns. Diagramma ir problēmvides modelis, kura modelē projektējamās sistēmas funkcionalitāti. Datu plūsmas diagramma tika realizēta kopmītnes biznesa procesam – studenta uzņemšana kopmītnēs. Sākotnēji bija grūti izprast, cik tad diagrammai ir jābūt cieši saistītai ar projektējamo datubāzi. Domāju, ka diagrammas datu krātuves elementam noteikti ir jāatspoguļo kāda datubāzes tabula vai skats, bet sapratu, ka tas tā nav. Datu plūsmas diagramma vienkārši modelē tik cik projektējamās sistēma funkcionalitāti un dod tikai vispārīgu priekšstatu par to kādai būtu jābūt datubāzes kopējai struktūrai.

Izstrādājis datu plūsmas diagrammu, ķēros klāt pie datubāzes konceptuālā modeļa veidošanas. Konceptuālā modeļa realizācijai tika pielietota ER diagramma pēc P. Čena notācijas, kā arī tās paplašinātais variants EER (Enhanced ER). Ar paplašināto ER diagrammu vēl nebija nācies saskarties, tāpēc bija ļoti interesanti par to uzzināt lekcijās un vairākos literatūras avotos. Jāatzīst, ka lekcijā apskatītā informācija un literatūras avotos apskatītā informācija kaut kā atšķiras. Diezgan pamatīgi izskatīju dažādas literatūras un man ir izveidojies labs priekšstats par paplašināto ER. Lekcijā tika izcelti atsevišķi koncepti „superrealitāte”, „mantošana” un „klasifikācija”, kurus būtu jāattēlo atsevišķi EER diagrammā. Bet spriežot pēc apskatītajām literatūrām, šie visi koncepti veido vienu veselumu – superklases un apakšklases notācija. Superklase ir vispārējs realitātes tips, kam ir saite ar vienu vai vairākām apakšklasēm. Apakšklase ir superklases apakšgrupa; manto superklases atribūtus un satur savus unikālus atribūtus; kā arī var piedalīties saitēs ar citiem realitātes tipiem. Saucamā „superrealitāte” ir superklases elements; mantošanas pastāv jebkurā gadījumā starp superklasi un apakšklasēm un tā nav jāizdala atsevišķi; „klasifikācija” ir superklases un apakšklases pilnības ierobežojums, kas arī nebūtu atsevišķi jāizdala. Pilnības ierobežojums iedalās šādi: pilnais specializācijas likums un daļējais specializācijas likums. Katrā gadījumā esmu detalizēti aprakstījis par paplašināto ER, balstoties uz vairākiem literatūra avotiem, un esmu daudz ko jaunu uzzinājis, kas netika iegūts lekcijās.

Kad pabeidzu projektēt EER diagrammu, manuāli transformēju to par loģisko-fizisko modeli. Es izdomāju loģisko modeli un fizisko modeli uztvert kā vienu modeli, jo vizuāli modeļi ir ļoti līdzīgi, atšķirības, principā, slēpjas tikai to aprakstā. Atsevišķi modeļus ir vērts izdalīt, ja tie tiek veidoti, izmantojot CASE rīkus, bet šajā praktiskajā darbā tas nebija paredzēts. Lekcijā tika ļoti izcelti skati kā transformācijas rezultāts, bet pirms transformācijas veikšanas jau sapratu, ka skati īsti neiederēsies. Protams, skati ir laba lieta, bet skati īsti neder kā transformācijas rezultāts, jo tie nenodrošina saites integritātes ierobežojumu (referential integrity). Tas ir, tabulas un skati nevar atsaukties uz skatiem. Taču skati var atsaukties uz tabulām, bet tāda vajadzība man nebija nepieciešama. Skatus toties var transformēt kā atsevišķas struktūras, kuras nepiedalās saitē. Izdomāt manuālo transformācijas rezultātu man palīdzēja bakalaura 2. kursā apskatītā programmatūra Sybase PowerDesigner. Taču jāpiezīmē, ka programmatūras bieži vien transformē nepieņemami, un tāpēc šajā darbā tiek veikta manuāla transformācija, lai iegūtu pieņemamāku rezultātu.

Ieguvis loģisko-fizisko modeli, ķēros klāt pie topošās datubāzes normalizācijas. Normalizācija ir ļoti svarīgs process, jo tā nodrošina to, lai datubāzes struktūra būtu piemērota universālai

38

vaicājumu veikšanai, atbrīvoties no „Insert”, „Update” un „Delete” modificēšanas anomālijām, kā arī datu dublēšanos. Bija jānodrošina tas, lai topošā datubāze apmierinātu Boisa-Kodda normālformu (trešās normālformas papildinājums). Kā jau man raksturīgi, domāju daudz uz ko uz priekšu un tāpēc mana izprojektētā datubāze jau sākotnēji apmierināja Boisa-Kodda normālformu un nebija vajadzība veikt dekompozīciju, taču apskatīju speciāli piemēru, kuram būtu jāveic normalizācija. Sapratu to, ka normalizēšanu nevar veikt mašīna, to var tikai individuāli pats datubāzu projektētājs.

Praktiskā darba noslēgumā loģisko-fizisko datubāzes modeli attēloju ar SQL definējumiem, kuri paredzēti Oracle videi. Ar SQL definējumu palīdzību ir iespēja izveidot lietojamu datubāzi. SQL definējumos bija iespēja parādīt datubāzes integritātes ierobežojumus, kurus vizuāli nevar redzēt loģiskajā-fiziskajā modelī. Integritātes ierobežojumi ierobežo lauku vērtības datubāzē, kas, protams, ir ļoti svarīgi.

39

Izmantotā literatūra1. Morgan Kaufmann, Database Modeling & Design (Fourth Edition);2. http://www.computing.surrey.ac.uk/personal/st/A.Browne/CS263/Lecture4Notes.ppt ;3. http://www.cse.ohio-state.edu/~gurari/course/cse670/cse670Ch16.xht ;4. http://www.eecis.udel.edu/~caulfij/cis437/hoffer6ed/the-info-engr-E-R-model2.pdf ;5. http://www.clt.astate.edu/rsegall/Holly_9-11_2403/4-ins.ppt ;6. http://ils.unc.edu/courses/2005_spring/inls156_002/notes/Lecture4.ppt .

40