J. AleksejevaSociālo pabalstu piešķiršanas datu konceptuālais modelis

Rīga 2005.

SATURS

1. Problēmas vides datu plūsmu diagrammas (DPD) modelis 3.

2. Datu modeļa diagrammas veidošana 8.2.1. Būtisko datu iegūšana 8.2.2. Datu subjektīva grupēšana 9.2.3. Realitāšu saišu diagrammas iegūšana 10.

3. Tabulu sākotnējās strukstūras iegūšana 12.

4. Tabulu normalizēšana. Boisa-Kodda normālforma. 17.

5. Gala pārbaude 30.

SECINĀJUMI 34.

2

Datu krātuve

Processieejas dati izejas dati

1. Problēmas vides datu plūsmu diagrammas (DPD) modelis

Problēmas vide ir - sociālo pabalstu piešķiršana. Sociālo pabalstu birojs nodarbojas ar valsts programmā paredzēto pabalstu piešķiršanu likuma kārtībā cilvēkiem ar noteiktu sociālo statusu (piem., maznodrošinātais). Bez visa tā dienests sniedz interesentu konsultēšanu visos pabalstu piešķiršanas jautājumos. Sociālo pabalstu dienesta speciālisti veic arī dzīvesvietu apsekošanu, pēc kuras tehniskā stāvokļa novērtēšanas tiek pieņemts komisijas lēmums par pabalstu piešķiršanu.

Sociālo pabalstu biroja kompetencē ietilpst sekojošas darbības:a) pabalstu potenciālo saņēmēju datu reģistrētā uzskaite;b) klientu dzīvesvietu apsekošana, ko veic instruktori, un apsekošanas rezultātu uzskaite;c) iesniegumu un tiem atbilstoša rakstura izziņu arhīvs (pēc sociāla darbinieka

pieprasījuma katrā atsevišķā situācijā);d) izejot no apsekošanas rezultātiem un personas iesniegtajiem dokumentiem, pieņemto

lēmumu leģitimitātes kontrole (uz pastāvošo likumu bāzes);e) piešķirto pabalstu (materiāla palīdzība vai servisa darbi) saraksti;f) finansiālās palīdzības piešķiršanas gadījumā noteiktas naudas summas no atvēlētā

budžeta tiek izmaksātas prasītājam tieši uz rokas, pakalpojumu sniegšanas gadījumā – tiek pieaicinātas juridiskās personas, kas šāda veida palīdzību apmaksā;

g) sniegto pakalpojumu maksājumu uzdevumu uzskaite (izejot no iepriekšējā punkta).

Lai izveidotu DPD (datu plūsmu diagrammu), modeli konstruē kā datu plūsmu, kur procesu kontrole un mehānismi nodrošina ieejas datu jeb sākotnējās informācijas pārveidošanu izejas datos – apstrādes rezultātos. Pats process vai funkcija ir datu plūsmas posms informācijas apstrādē. DPD tiek izpildīta Visio2000 vidē (sk. 1.1.att.), izmantojot sekojošus attēlojumus:

Aktivitāšu attēlošana:

Ārējās vides realitāte (aktieris), kas ietekmē informācijas sistēmas darbību un kalpo kā datu avots šajā sistēmā.

Datu krātuve – datu izvietošana.

Datu plūsma starp dažādiem sistēmas objektiem: starp procesiem, datu krātuvēm un ārējām realitātēm.

Process – ieejas informāciju pārvērš izejas informācijā. Procesa apzīmējumā iekļauts procesa numurs (Fn), procesa nosaukums, ieejas datu saraksts, izejas datu saraksts.

Ār.

3

4

5

DPD parāda ar kāda tipa datiem operē Sociālo pabalstu dienesta sistēma, no kādiem ārējiem datu avotiem šī informācija tiek iegūta, kādos procesos datu plūsma sadalās un kur sistēmā glabājas apstrādātie dati. Sistēmas ieejas dati ir personu informācijas pieprasījumi un klientu pabalstu pieprasījumi, uz kuru pamata sociālie darbinieki: dzīvesvietu apsekotāji – inspektori un biroja darbinieki, lemj par pabalsta saņemšanas tiesībām. Izejas informācija ir pabalstu dati un sociālo darbinieku atbildes uz informācijas pieprasījumiem.

Sociālo pabalstu biroja sistēma satur 3 ārējas realitātes:1). Persona – jebkurš cilvēks, kas griežas pēc informatīvas vai materiālas palīdzības;2). Sociālais darbinieks – Sociālo pabalstu dienestā nodarbinātais attiecīgas jomas speciālists;3). Juridiska persona – sociālo palīdzību sniedzoša organizācija, kas Sociālo pabalstu dienestam

piestāda apmaksas rēķinu par sniegto pakalpojumu izmaksām.

Sociālo pabalstu dienesta sistēma satur 12 datu noliktavas, kas ir apzīmētas DKn, kur DK atšifrējas kā datu krātuve un n – glabātuves kārtas numurs:

DK1. Personas dati – datu krātuve satur datus par visām personām, kas griezušās Sociālo pabalstu birojā pēc palīdzības, proti, informācijas vai materiālas palīdzības.

DK2. Dzīvesvietas dati – personas pieraksta vietas dati.DK3. Informācijas pieprasījumi – personu fiksētie jautājumi, kas prasa speciālistu konsultācijas

par visdažādākajām pabalstu piešķiršanas jomas tēmām.DK4. Atbildes - biroja darbinieku fiksētās atbildes uz personu informācijas pieprasījumiem.DK5. Izziņas – dažādu iestāžu izsniegtie oficiālie dokumenti, kas pierāda personas pabalsta

piešķiršanas nepieciešamības faktu.DK6. Pabalstu iesniegumi – Sociāla pabalstu biroja klientu pamatotie lūgumi saņemt palīdzību.DK7. Apsekošanas dati – dienesta apsekošanas ekspertu, inspektoru, slēdziens par personas

dzīvesvietas tehnisko stāvokli pēc tās apskates.DK8. Lēmumi par pabalstu piešķiršanu – sociāla centra komisijas spriedums par personas

pabalsta iesnieguma apmierināšanu uz likumu, apsekošanas rezultātu un iesniegto izziņu pamata.

DK9. Pabalsti – pieņemtā lēmuma rezultāts (rīkojums) par palīdzības sniegšanu naudas formā, izmaksājot pabalstam atvēlēto naudas summu prasītājam tieši uz rokām, vai pakalpojuma formā, sniedzot klientam apmaksāta servisa palīdzību

DK10. Maksājuma uzdevumi – biroja darbinieku sagatavotie apmaksai juridisko personu rēķini par pakalpojumu veikšanu pabalsta ieguvējiem.

DK11. Rēķina dati – juridiskās personas piestādītais rēķins Sociālajam dienestam par pakalpojumu realizēšanu.

DK12. Juridiskas personas dati –pakalpojuma tipa pabalstu sniedzoša organizācija, uzņēmums.

6

Sistēmā ir 14 datu plūsmas, 10 vaicājumi un atbildes uz tiem, izdalīti 59 procesi. Apzīmējot vaicājumus, es izmantoju attiecīgas plūsmas kārtas numuru, nevis paša vaicājuma kārtas numuru, lai būtu vienkāršāk noteikt, kurai datu plūsmai pieder šis vaicājums, kā arī papildplūsmas (kas papildina pirmatnējās plūsmas informāciju) apzīmējumam izmantoju “ ‘ “ simbolu. Tātad sistēmā eksistē sekojošas datu plūsmas:

D1 - privātas personas, kas griežas Sociālo pabalstu birojā, pamatdati;V1 - vaicājums, vai attiecīga persona nav iepriekš reģistrējusies Sociālo pabalstu informācijas

sistēmā, jo tādā gadījumā visu datu sniegšana nav nepieciešama sakarā ar to, ka persona jau ir biroja klients, kura dati jau tiek glabāti datu krātuvē;

A1 - atbilde uz personas iepriekšējas reģistrācijas vaicājuma pārbaudi;D2 - personas dzīvesvietas dati;V2 - pārbaude, vai šie dati jau nav reģistrēti personai;A2 - pārbaudes rezultāts;D3 - klienta informācijas pieprasījums par pabalstu piešķiršanas tēmu;V3 - informācijas pieprasījuma vaicājums, atgriež biroja darbinieka atbildi uz to;A3 - biroja darbinieka konsultatīva un rakstiska atbilde uz klienta informācijas pieprasījumu;D4 - nepieciešamo izziņu uzrādīšana (pēc sociāla darbinieka uzteikuma);D5 - pabalsta iesnieguma dati;V5 - visu nepieciešamo pabalsta iesniegumam izziņu pārbaude – jā kaut kāda izziņa, kas

apliecina personas tiesības saņemt pabalstu, trūkst, tad klients par to tiek brīdināts;A5 - vajadzīgo izziņu nodošanas pārbaudes rezultāti;V6 - dzīvesvietas apsekošanas slēguma atbilstības pārbaude pabalsta prasības dokumentā

personas sniegtajai informācijai;A6 - iesniegto un apsekošanas datu atbilstības pārbaudes rezultāti;D7 - dzīvesvietas apsekošanas procesa dati;V7 - pārbaude, vai ir nepieciešams veikt apsekošanu;A7 - rezultāta saņemšana, kas tiks nodota apsekošanu veicošajam darbiniekam - inspektoram;D7’- apsekošanas rezultāta apkopošana izziņas veidā;V8 - pārbaude uz visu nepieciešamo izziņu savākšanu lēmuma pieņemšanas procedūrai;A8 - pārbaude un personas informēšana, ja kāds dokuments trūkst;D8 - lēmuma pieņemšanas procedūras sākums;D9 - pabalsta dati;V9 - pabalsta piešķiršanas rīkojuma pārbaude - vai bija pieņemts attiecīgais lēmums;A9 - atbilde par lēmuma eksistēšanu;D10 - maksājuma uzdevuma sagatavotie dati;V10 - maksājuma uzdevumam atbilstoša rēķina eksistences pārbaude – vai tāds rēķins sastādīts;A10 - pārbaudes rezultāti;D10’- maksājuma uzdevuma dati attiecīgajam rēķinam;D11 – rēķina dati;D12 – juridiskās personas dati, kas piedalās pabalsta piešķiršanas organizēšanā.

7

Datu plūsma sastāv no vairākiem datiem, kurā izdalīsim tikai būtiskos datus, kuru detalizētāks skaidrojums dots 2.2. nodaļā “Būtisko datu izdalīšana”. Pagaidām sniegsim tikai datu plūsmu vienības (sk. 1.1. tab.).

1.1. tabulaDatu plūsmu elementi

D1 d1, d2, d3, d4, d5, d6 V1 d1, d2, d3 A1 d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11

D2 d12, d13, d14 V2 d12, d13 A2 d12, d13, d14D3 d15, d16, d17, d18 V3 d15, d18 A3 d19, d20, d21D4 d22, d23, d24, d25D5 d26, d27, d28 V5

V6

d26, d28, d22

d26, d28, d29

A5

A6

d26, d27, d28, d22, d23, d24, d25d26, d27, d28, d29, d30, d31, d32, d33

D7 d29, d30, d31, d32, d33 V7 d29, d12, d13 A7 d29, d30, d31, d32, d33, d39, d40

D7’ d12, d13, d14, d22, d23, d24, d25, d29, d30, d31, d32, d33D8 d43, d44, d45, d46, d47 V8 d43, d22 A8 d22, d23, d24, d25, d43,

d44, d45, d46, d47D9 d48, d49, d50 V9 d48, d49, d43, d47 A9 d48, d49, d50, d51, d52,

d53, d54, d55, D10 d59, d60, d61, d62 V10 d59, d60 A10 d59, d60, d61, d62, d56,

d57, d58D10’ d59, d60, d61, d62, d56, d57, d58D11 d60, d61, d62, d56, d57, d58, d52, d53D12 d56, d57, d58

8

2. Datu modeļa diagrammas iegūšana

2.1. Būtisko datu izdalīšana

Paskaidrosim būtiskos datus, kas tika izmantoti tabulā 2.1.1. , iepriekšējā nodaļā.

2.1.1. tabulaBūtiskie dati

d1- personas identifikators;d2- personas kods;d3- pases numurs;d4- personas vārds;d5- personas uzvārds;d6- dzimums;d7- ienākumi;d8- mobilais telefons;d9- sociālais statuss;d10-veselības stāvoklis;d11-ģimenes stāvoklis;d12-dzīvesvietas identifikators;d13-adrese;d14-mājas telefons;d15-info pieprasījuma identifikators;d16-pieprasījuma datums;d17-pieprasījuma veids;d18-pieprasījuma saturs;d19-atbildes identifikators;d20-atbildes datums;d21-atbildes saturs;d22-izziņas identifikators;d23-izdošanas datums;d24-izdevējs;d25-izziņas saturs;d26-iesnieguma ident.;d27-tapšanas datums;d28-iesnieguma saturs;

d29-apsekošanas identifikators;d30-apsekošanas datums;d31-apsekotājs;d32-stāvoklis;d33-slēdziens;d34-sociāla darbinieka identifikators;d35-soc.darbn. personas kods;d36-soc.darbn. vārds/uzvārds;d37-izglītība;d38-kategorija;d39-inspektora identifikators;d40-inspektora rangs;d41-biroja darbinieka ident.;d42-biroja darbinieka amats;d43-lēmuma numurs;d44-sēdes komisija;d45-lēmuma pieņemšanas datums;d46-likumi;d47-lēmuma saturs;d48-pabalsta numurs;d49-pabalsta kategorija;d50-pabalsta mērķis;d51-piešķiršanas datums;d52-pakalpojuma identifikators;d53-pakalpojuma veids;d54-finansu palīdzības identifikators;d55-finansiālas palīdzības summa;d56-juridiskas personas reģistrācijas num.;d57-juridiskas personas nosaukums;d58-konta numurs;d59-maksājuma uzdevuma numurs;d60-maksājuma datums;d61-maksājuma mērķis;d62-maksājuma summa.

9

2.2. Datu subjektīva grupēšana

Subjektīvi veicot būtisko datu (sk. 2.1.1. tab.) grupēšanu, tiek izdalītas sekojošas realitātes, kurām šie dati pieder. Jāmin, ka par realitātēm kļuva galvenokārt visas DPD datu krātuves un ārējas realitātes, taču daudzi procesi ietekmēja lomu izdalīšanu dažām realitātēm un nosaukumu maiņu, ērtības labā izlaižot vārdu “dati” realitātēm, jo tāpat skaidrs, ka katra no tām glabā datus.

Ir notikušas sekojošas pārmaiņas: “Personas” realitātei atsevišķi tiek izdalīta vājā realitāte “Klients”, kas apzīmē visas sistēmā

reģistrētas personas, kas griežas ne tikai pēc informācijas, bet gan pēc pabalsta; realitāte “Dzīvesvieta” arī kļūst par vājo realitātei “Persona”; realitāte “Apsekošana” ir atkarīga un identificējas no realitātes “Dzīvesvieta” – tātad arī ir

vāja realitāte; ārējai realitātei “Sociālais darbinieks” parādās nepilnais lomu dalījums: “Inspektors” un

“Biroja darbinieks”; datu krātuve “Lēmumi par pabalstu piešķiršanu” kļūst vienkārši par “Lēmumi”; realitātei “Pabalsts” parādās pilnais lomu dalījums “Pakalpojumos” un “Finansiālā palīdzībā”; krātuves “Maksājuma uzdevumi” un “Rēķina dati” tiek integrētas uz realitāti “Maksājums”.

Tabulā Nr. 2.2.1. tiek apkopota informācija par modelī izmantotajām realitātēm, to atribūtiem un to skaidrojumu.

2.2.1. tabulaSubjektīvas grupēšanas veikšana

Nr. Realitātes nosaukums AtribūtiR1 Persona Personas ID, Personas kods, Pases numurs, Vārds,

Uzvārds, DzimumsR2 Dzīvesvieta Dzīvesvietas ID, Adrese, TelefonsR3 Klients Ienākumi, Mobilais telefons, Sociālais statuss,

Veselības stāvoklis, Ģimenes stāvoklisR4 Apsekošana Apsekošanas ID, Apsekošanas datums, Apsekotājs,

Stāvoklis, SlēdziensR5 Sociālais darbinieks SocDarbn ID, Personas kods, Vārds, Uzvārds, Izglītība,

KategorijaL1 Inspektors Inspektora ID, RangsL2 Biroja darbinieks Biroja darbn ID, AmatsR6 Iesniegums Iesnieguma ID, Tapšanas datums, SatursR7 Izziņa Izziņas ID, Izdošanas datums, Izdevējs, SatursR8 Informācijas pieprasījums Pieprasījuma ID, Datums, Veids, SatursR9 Atbilde Atbildes ID, Datums, SatursR10 Lēmums Lēmuma numurs, Komisija, Datums, Likumi, SatursR11 Pabalsts Pabalsta numurs, Kategorija, MērķisL3 Pakalpojums Pakalpojuma ID, Pakalpojuma veidsL4 Finansiāla palīdzība FinPalidz ID, SummaR12 Maksājums MaksUzd numurs, Datums, Mērķis, SummaR13 Juridiska persona Reģistrācijas numurs, Nosaukums, Konta numurs

10

2.3. Realitāšu saišu diagrammas iegūšana

Izpildot būtisko datu izdalīšanu un to grupēšanu, no datu plūsmas diagrammas (DPD) var iegūt datu modeļa (ERD) diagrammu. Tā ir attēlota 2.3.1. shēmā.

Realitāšu un to atribūtu izcelsme detalizēti aprakstīta iepriekšējās nodaļās, sīkāka informācija par ER diagrammu ir sniegta iepriekšējā darbā, palika apskatīt realitāšu sasaistes ERD diagrammas notācijā, kas dots 2.3.1. tabulā.

2.3.1. tabulaRealitāšu sasaiste

Saistītās realitātes Kardinalitāte NozīmeR1 R3 1:1 Klienta dati ir daļa no personas datiem, kas pie tam identificējas no

personas ID. Bez personas datiem, nevar eksistēt arī klienta dati – tie ir atkarīgi (vājā saite). Klients ir tā pati persona, kas iesniegusi lūgumu par pabalsta piešķiršanu, tāpēc saite viens pret vienu.

R1 R2 N:1 Dzīvesvietas dati ir daļa no personas datiem – vājā saite. Vairākas personai var būt pierakstītas vienā un tajā pašā dzīvesvietā.

R2 R4 1:N Viena dzīvesvieta var tikt apsekota vairākas reizes, pie tam apsekošanas dati paši par sevi eksistēt nevar, tie identificējas no dzīvesvietas datiem, tātad, ir atkarīgi.

L1 R4 1:N Viens inspektors var veikt vairākas apsekošanas.R1 R8 1:N Viena persona var iesniegt vairākus informācijas pieprasījumus.R3 R8 1:N Viens klients var iesniegt vairākus informācijas pieprasījumus.R3 R6 1:N Viens klients var noformēt vairākus iesniegumus.R3 R7 1:N Klients var atnest vairākas izziņas pēc biroja darbinieka lūguma.R6 R7 1:N Lai iegūtu pabalstu, uz vienu iesniegumu var tikt pieprasītas

vairākas dažāda rakstura izziņas.R6 R6 1:N Rekursīvā saite – viena un tā paša tipa iesniegums var tikt regulāri

iesniegts, lai saņemtu vienu un to pašu pabalstu, piem., ikmēneša pabalsts dzīvokļa īres samaksai denacionalizētajā mājā.

R5 R3 N:M Viens sociālais darbinieks var strādāt ar vairākiem klientiem, kā arī viens un tas pats klients var tikt apkalpots ar vairākiem darbiniekiem.

L2 R6 1:N Viens biroja darbinieks saņem vairākus iesniegumus.L2 R7 1:N Viens biroja darbinieks pieprasa/saņem vairākas izziņas.L2 R8 1:N Viens biroja darbinieks saņem vairākus informācijas pieprasījumus.R8 R9 1:1 Atbilde attiecas uz informācijas pieprasījumu, kas to pieprasa.R1 R9 1:N Viena persona var saņemt vairākas atbildes.L2 R9 1:N Biroja darbinieks var sniegt vairākas atbildes.R5 R10 N:M Viens sociālais darbinieks var pieņemt vairākus lēmumus, kā arī

viens lēmums var tikt pieņemts no komisijas puses – vairākiem sociāliem darbiniekiem, kuru starpā var būt gan biroja darbinieki, gan inspektori, gan citi speciālisti.

R10 R11 1:1 Lēmums piešķirt pabalstu – viens komisijas lēmums norīko tikai viena pabalsta piešķiršanu.

R10 R12 1:1 No šī paša lēmuma izriet maksājums, ja tika piešķirts servisa sniegšanas pabalsts.

R13 R12 1:1 Šo maksājumu saņem juridiska persona.R13 L3 1:N Juridiska persona sniedz vairākus pakalpojumus.R3 L3 1:N Viens klients var saņemt dažādus pakalpojumus.R3 L4 1:N Viens klients var saņemt dažādas naudas summas kā finansiālus

pabalstus.

11

DzīvesvietaDzīvesvietas IDAdreseTelefons

KlientsPersonas IDIenākumiMobilais telefonsSociālais statussVeselības stāvoklisĢimenes stāvoklis

3.1. att.-Tabula

3. Tabulu sākotnējās struktūras iegūšana

No iepriekš projektētas ER diagrammas, izmantojot dažādus pārveidošanas likumus, ir iespējams iegūt datu bāzes tabulu sākotnējo struktūru. Realizējot pāreju no datu modeļa uz tabulu struktūru, pieturēsimies pie šādiem vispārīgiem likumiem:

1. Katra ERD realitāte kļūst par DB struktūras tabulu. Arī realitāšu lomu dalījumi kļūst par atsevišķām tabulām, izņemot gadījumus, kad projektētājs nevēlas atsevišķās tabulās izdalīt kādas realitātes lomas un apvieno tās galvenajā tabulā.

2. Realitātes atribūti kļūst par tabulas laukiem, kur atslēgas atribūts ir primārās atslēgas lauks. 3. Vājām realitātēm primārais identifikators var būt pārņemts no galvenajām realitātēm, ja to

dati identificējas pēc šī atribūta.4. Saite starp divām realitātēm pieprasa primārās atslēgas lauka (Primary Key) un saites lauka

(Foreign Key) eksistēšanas nepieciešamību.4.1. saites kardinalitāte 1:1, 1:N un N:1 pieprasa tikai primārās atslēgas un saites lauka

eksistēšanu tabulās;4.2. saites kardinalitāte N:M realizējama ar starptabulas palīdzību;4.3. katrā realitātē parādās tik saites lauki, ar cik cita veida realitātēm tā ir nedominanti

saistīta – pakārtota;4.4. unārā saite realizējama, pievienojot tabulai primārās atslēgas lauka kopiju ar citu

nosaukumu;5. Citi subjektīvi likumi.

Orientējoties uz šiem likumiem, 2.3.1. attēlā doto ER diagrammu un 2.3.1. tabulā sniegto saišu aprakstu, veidosim tabulu struktūras:

Saite starp realitātēm R1 un R3, “Persona” un “Klients”, nosaka to, ka klienta dati tiek identificēti pēc personas datiem. Tas nozīmē, ka tabulā “Klients” (sk. 3.1. att.) lauku sastāvā bez visiem realitātes “Klients” atribūtiem ietilps arī lauks “Personas ID”, pēc kura būs iespējams noteikt, uz kuru personu attiecas klienta dati. Realitātei R3 savs identifikators nav, jo tā pati no sevis neidentificējas. Būtībā “Personas ID” abās tabulās “Persona” un “Klients” sakritīs, jo klients ir reģistrēta persona: persona – jebkurš cilvēks, kas uzņemts Sociālo pabalstu dienesta Informācijas sistēmas uzskaitē, bet klients – persona, kas šajā sistēmā jau figurē kā infomācijas vai pabalsta prasītājs vai saņēmējs.

3.2. att. - Tabula “Dzīvesvieta” Realitātes R2 – “Dzīvesvieta” dati arī ir atkarīgi no realitātes R1 – “Persona” datiem kā 1:N, taču no dzīvesvietas jābūt identificējamiem arī tās apsekošanas datiem, tāpēc ieviesīsim primārās atslēgas lauku - “Dzīvesvietas ID” (sk. 3.2. att.).

IesniegumsIesnieguma IDBiroja darbn IDIesnieguma ID2 Personas IDTapšanas datumsSaturs

AtbildeAtbildes IDBiroja darbn IDPersonas IDDatumsSaturs

Informācijas pieprasījumsPieprasījuma IDAtbildes IDBiroja darbn IDPersonas IDDatumsVeidsSaturs

PersonaPersonas IDDzīvesvietas IDPersonas kodsPases numursVārdsUzvārdsDzimums

ApsekošanaApsekošanas IDDzīvesvietas ID Inspektora ID Apsekošanas datumsApsekotājsStāvoklisSlēdziens

Realitātes R4 – “Apsekošana” dati ir atkarīgi no realitātes R2 – “Dzīvesvieta” datiem un tie ir identificējami pēc “Dzīvesvietas ID”. Abas realitātes R4 un R2 ir vājas. Apsekošanu veic inspektors, tāpēc ir vajadzīgs lauks “Inspektora ID”, kas nodrošina realitāšu R4 un L1 - Inspektors saiti N:1.

3.3. att. - Tabula “Apsekošana”

3.4.att. - Tabula “Persona” Atgriezīsimies pie galvenās realitātes, no kuras vājas realitātes ir atkarīgas – R1 “Persona” (sk. 3.4. att.). Tabulai ir vajadzīgs primārās atslēgas lauks, par kuru pēc 2. likuma pielietošanas, kļūst realitātes primārais identifikators “Personas ID”. N:1 saiti ar tabulu “Dzīvesvieta” nodrošina saites lauka “Dzīvesvietas ID” ieviešana.

Persona un klients (- persona, kas jau ir reģistrēta sistēmā) ir saistīti ar realitāti R8 – “Informācijas pieprasījums”. Sakarā ar to, ka “Klients” ir realitātes “Persona” vājā realitāte un abām saitēm R1 un R8, R3 un R8 kardinalitāte ir 1:N, tabulā būs lauks “Personas ID”. Bez tā realitātei R8 eksistē vēl 1:1 saite ar L2 – “Biroja darbinieks”, jo informācijas pieprasījumu apstrādā biroja darbinieks un sniedz personai atbildi (R9) uz to – R8 un R9 kā 1:1 saite. Tas nozīmē, ka parādīsies vēl 2 lauki: “Biroja darbn ID” un “Atbildes ID”.

3.5. att. - “Informācijas pieprasījums”

3.6. att. - Tabula “Atbilde” No iepriekšēja piemēra, ir adekvātas realitātes R9 – “Atbilde” saites: L2 - “Biroja darbinieks” un R9 ar kardinalitāti 1:N, no kurienes

iegūstam lauku – “Biroja darbn ID”;

R1 un R9 kā 1:N saite – no kurienes lauks “Personas ID”.Sanāk, ka biroja darbinieka identifikators parādās abās realitātēs: R8 un R9, kas ir tāpēc, ka informācijas pieprasījumu var saņemt viens darbinieks, bet atbildēt uz to cits.

Realitāte R6 - “Iesniegums” ir saistīta ar “Klienta” realitāti, tāpēc tabulā “Iesniegums” papildus iekļauts lauks “Personas ID”. Biroja darbinieks (L2) saņem šos iesniegumus (L2 un R6 kā 1:N – rezultātā tiek iekļauts lauks “Biroja darbn ID”) un fiksē sistēmā, kur katrs nākamais iesniegums var tikt veidots uz iepriekšējā dokumenta bāzes , tātad veidojas rekursīvā saite – “Iesnieguma ID2”.

3.7. att. - Tabula “Iesniegums”

14

Saite: soc. Darbinieks – LēmumsSocDarbn IDLēmuma numurs

LēmumsLēmuma numursKomisijaDatumsLikumiSaturs

Sociālais darbinieksSocDarbn IDPersonas kodsVārdsUzvārdsIzglītībaKategorija

IzziņaIzziņas IDBiroja darbn IDIesnieguma IDPersonas IDIzdošanas datumsIzdevējsSaturs

Atgriežamies atkal pie realitātes R3 – “Klients”, tāpēc ka klientam katrs iesniegums ir jāpamato ar attiecīgām izziņām, tātad tabulā “Izziņa” būs saites lauks ar realitāti - “Personas ID”. Izziņas, tāpat kā iesniegumus, saņem biroja darbinieki (saite L2 – “Biroja darbinieks” un R7 – “Izziņa”, 1:N) – tā iegūstam saites lauku “Biroja darbn ID”. To, ka izziņas (R7) attiecas uz konkrēto iesniegumu (R6), nodrošina saites lauks – “Iesnieguma ID”.

3.8.att. - Tabula “Izziņa”

Klientu konsultē sociālais darbinieks – kā daudzi pret daudziem strādā saite starp realitātēm “Sociālais darbinieks” (R5) un “Klients” (R3). Likums Nr. 4.4. pieprasa starptabulas izmantošanu, kuru nosauksim par “Saite: soc. Darbinieks – Klients”, kurā būs tikai 2 lauki: “Personas ID” un “SocDarbn ID”. Savukārt tabulai “Sociālais darbinieks” definēsim 2 lomu tabulas: “Inspektors” (L1) un “Biroja darbinieks (L2), abās tabulās ievietojot saites lauku “SocDarbn ID” - galvenās tabulas primārās atslēgas lauks.

3.9.att. – Starptabula starp “Klients” un “Sociālais darbinieks”

3.10. att. – “Sociālais darbinieks”

3.11.att. - Lomas tabula “Biroja darbinieks”

3.12.att.-Lomas tabula “Inspektors”

3.13.att. - Tabula “Lēmums”

3.14. att. – Starptabula starp “Sociālais darbinieks” un “Lēmums”

Tālak sociālais darbinieks pieņem lēmumus par pabalsta piešķiršanu - kā daudzi pret daudziem strādā saite starp realitātēm “Sociālais darbinieks” (R5) un “Lēmums” (R10). Saiti N:M divām tabulām atkal nodrošina starptabula ”Saite: soc. Darbinieks – Lēmums”, kurā ievietosim 2 saites laukus: “Lēmuma numurs” un “SocDarbn ID”.

Pēc lēmuma pieņemšanas tiek piešķirti pabalsti. Realitātei R11 – “Pabalsts” ir pilnais lomu dalījums “Pakalpojumos” un “Finansiālā palīdzībā” un 1:1 saite ar realitāti “Lēmums”. Saiti nodrošināsim, ievietojot tabulā “Pabalsts” saites lauku “Lēmuma numurs”, bet saites īpašību “Datums” ierakstīsim kā lauku, jo pabalsta pieņemšanas datums attiecas uz tabulu “Pabalsts” (sk._3.15. att.).

Saite: soc. Darbinieks – KlientsSocDarbn IDPersonas ID

Biroja darbinieksBiroja darbn IDSocDarbn ID Rangs

InspektorsInspektora ID SocDarbn IDAmats

15

Lomu tabulās ievietosim vecāka tabulas identifikatoru “Pabalsta numurs”, kā arī “Personas ID” saites lauku ar tabulu “Klients”, jo tieši klients ir tas, kurš beigās saņem palīdzību – vai nu pakalpojumu, vai naudu. Sakarā ar to, ka pakalpojumu realizēšanu piedāvā juridiskas personas, tabulā “Pakalpojums” ir nepieciešams ievietot norādi uz servisa sniedzēju, ko var atpazīt pēc uzņēmuma reģistrācijas numura - “Reģistrācijas numurs” (sk. 3.16. att.).

3.15. att. – Tabula “Pabalsts” 3.16.att. – Lomas tabula “Pakalpojums” 3.17. att. – Lomas tabula “Finansiāla palīdzība”

3.18. att. – Tabula “Maksājums No pieņemtā lēmuma jeb rīkojuma par pabalsta piešķiršanu izriet maksājums- kā 1:1 strādā saite starp realitātēm “Lēmums” (R10) un “Maksājums” (R12). Tas neattiecas uz materiālo pabalstu naudas formā, ko Sociālo pabalstu birojs izmaksā no atvēlēta budžeta. Maksājumu saņem juridiska persona. Rezultātā tabulā “Maksājums” būs 2 saites lauki: “Lēmuma numurs” ar tabulu “Lēmums” un “Reģistrācijas numurs” ar “Juridiskas personas” tabulu.

Tabulas “Juridiska persona” struktūra ir redzama attēlā Nr. 3.19. Juridiska persona jeb organizācija saņem maksājumus.

3.19. att. – Tabula “Juridiska persona”

Izveidojot tabulu sākotnējās struktūras, analīze ir jāturpina un šajā stadijā var veikt datu fiziskā modeļa uzmetumu – t.i. iegūt tabulu diagrammu (sk. 3.20. att.), no kuras mums būs vieglāk turpināt Sociālo pabalstu biroja sistēmas datu bāzes projektēšanu. Tam tiks izmantots tabulu normalizācijas Boisa-Kodda piegājiens un datu funkcionālas atkarības diagrammu attēlošana visām tabulām, kas uzrādīs anomālijas.

PabalstsPabalsta numursLēmuma numursDatumsKategorijaMērķis

PakalpojumsPakalpojuma IDPabalsta numursPersonas IDReģistrācijas numursPakalpojuma veids

Finansiāla palīdzībaFinPalidz IDPabalsta numursPersonas IDSumma

MaksājumsMaksUzd numursLēmuma numursReģistrācijas numursDatumsMērķisSumma

Juridiska personaReģistrācijas numursNosaukumsKonta numurs

16

3.20. att. – Tabulu sākotnējās struktūras diagramma

17

4. Tabulu normalizēšana. Boisa-Kodda normālforma

Pēc sākotnējo tabulu izveides no datu loģiskā modeļa ir iespējams veikt tālāko analīzi un pārbaudīt, kādas statiskās saites pastāv struktūras datu vienību starpā. To pārskatāmi uzrāda datu funkcionālas atkarības diagrammas.

Analizējot tabulu struktūras, īpaši ja tās aizpildītas ar datiem, var atrast ievades (INSERT), labošanas (UPDATE) un dzēšanas (DELETE) anomālijas – t.i. tabulas stuktūru loģikas problēmas. Tā piemēram, var redzēt, ka tabulai “Izziņa” ir ievades anomālija: ja ir jauni dati par izziņas izdevēju, ko nepieciešams ievietot, tad izrādās, ka to nav iespējams izdarīt, kamēr uzskaitē neienāk jauna izziņa. Šī tabula uzrāda arī labošanas anomāliju tāpēc, ka, ja būtu jālabo kāda konkrēta izziņas izdevēja iniciāļi, kas tabulas ierakstos atkārtojas – iznāktu mainīt tikai viena raksta vērtību, lai gan jālabo visiem. Dzēšanas anomālija izpaužas šādi: vēlamies dzēst kādu izziņu, bet zaudējam informāciju par izziņas izdevēju.

Līdzīgas problēmas var noteikt arī daudzām citām tabulām, tāpēc anomāliju novēršanas nolūkā ir nepieciešams veikt tabulu normalizāciju. Normalizēšanas būtība ir datu struktūru projektēšana tādā veidā, lai izvairītos no datu dublēšanās un nepieļaut nesaistītas struktūras. Normalizēšanas rezultātā notiek lauku pārvietošana uz atbilstošām tabulām. Pastāv 5 normālformas, kuru prasības jāievēro tabulās. Plaši tiek izmantotas pirmās trīs normālformas: 1NF – nedalāma atomāra vienība; 2NF – primārās atslēgas lauka būtība; 3NF – neprimārās atslēgas lauku netranzitīva atkarība no primārās atslēgas. 4NF atklāj daudzvērtību atkarības un 5.N.F – projekciju apvienošanas prasības. Mūsu uzdevuma prasība ir Boisa-Kodda normālformas izmantošana (BCNF).

Boisa-Kodda normālforma: Attieksme R atbilst BCNF, ja katrs determinants ir arī iespējamais primārās atslēgas kandidāts. Tiks veikta visu sistēmas tabulu pārbaude. Ja tabula neatbilst BCNF, tad tiks realizēta dekompozīcija un atkārtoti veikta pārbaude pēc dotās normālformas visām sadalījuma rezultātā radītām struktūrām.

Tabula “PERSONA”Tabula atbilst BCNF. Katrs determinants var būt arī primārā atslēga un sakarā ar to, ka atslēgai ir jānodrošina unikalitāte, veidojam grupu: “Personas kods”, “Vārds” un “Uzvārds”, jo gan personu kodi (kas ir reālās sistēmas anomālija), gan arī vārdu un uzvārdu kombinācijas mēdz atkārtoties. Jāpievērš uzmanība laukam “Dzimums”. Lai gan ir iespēja izdalīt atsevišķu tabulu, kas saturēs tikai 2 laukus: “Dzimuma ID” un “Dzimums” un būs saistīta ar esošo tabulu “Persona”, taču datu bāzes projektētāja lēmums ir atstāt lauku, formāli piemērojot viņam standarta pieraksta veidu bez saīsinājumiem, kā parādīts piemērā.

Tabula “Persona”Personas ID Dzīvesvietas ID Personas kods Pases numurs Vārds Uzvārds Dzimums111 100 211082-21211 LE12542542 Ģirts Kalniņš Vīrietis112 200 101241-10584 LE95554442 Ģirts Kalniņš Vīrietis113 300 101241-10584 LE32542165 Iveta Krēsliņa Sieviete

18

BCNF pārbaudeIespējamā primārā atslēga Determinants

Personas ID Personas IDPases numurs Pases numurs

Personas kods+Vārds+Uzvārds Personas kods+Vārds+Uzvārds

4.1. att. – Datu funkcionālās atkarības diagramma tabulai “Persona”

Tabula “KLIENTS”Tabula neatbilst BCNF. Taču pirms tabulas pārbaudes uz BCNF, lauki “Sociālais statuss”,

“Veselības stāvoklis” un “Ģimenes stāvoklis” ir jāpaskaidro, t.i. jāsadala sīkākās atomārās vienības, proti, sanāk pielietot 1NF. Sadalīsim tos, kā tas ir parādīts tabulā.

Tabula “Klients”Personas ID Ienākumi Mobilais

telefonsSociālais statuss Veselības stāvoklis Ģimenes stāvoklis

Soc

iāla

sta

tusa

ID

Soc

.st.

nosa

ukum

s

Pie

šķirš

anas

pa

mat

ojum

sV

esel

ības

stā

vokļ

a ID

Ves

elīb

as d

iagn

oze

Inva

liditā

te

Vai

atro

das

past

āvīg

ajā

ārst

u uz

skai

tēĀ

rstn

. ies

tāžu

ap

mek

lēju

ms

gadā

Ģim

enes

stā

vokļ

a ID

Ģim

enes

stā

vokl

is

Apg

ādāj

amo

skai

ts111 90 6558545 1 ... ... 1 ... ... ... ... 1 ... ...112 100 6021230 1 ... ... 2 ... ... ... ... 1 ... ...113 70 2 ... ... 3 ... ... ... ... 1 ... ...

4.2. att. – Datu funkcionālās atkarības diagramma tabulai “Klients”

Iespējamā primārā atslēga DeterminantsPersonas ID Personas ID

- Sociāla statusa ID- Veselības stāvokļa ID- Ģimenes stāvokļa ID

Normalizācijas rezultāts:

19

Tabulai “Klients” primārā atslēga var būt tikai viena – “Personas ID”. Pēc datu atkarības funkcionālās diagrammas var secināt, ka tabula jāsadala pēc katra no determinantiem: “Sociāla statusa ID”, “Veselības stāvokļa ID”, “Ģimenes stāvokļa ID”, tabulā “Klients” atstājot tikai saites laukus ar šīm tabulām, rezultātā iegūstam jaunu tabulas “Klients” struktūru:

Tabula “Klients”Personas ID Ienākumi Mobilais telefons Sociāla statusa ID Veselības stāvokļa ID Ģimenes stāvokļa ID111 90 6558545 1 1 1112 100 6021230 1 2 1113 70 2 3 1

Tālāk konstruējam datu funkcionālas atkarības diagrammu un varam veikt atkārtotu BCNF pārbaudi (sk .4.3. att.).

4.3. att. – Datu funkcionālās atkarības diagramma tabulai “Klients” pēc dekompozīcijas

Iespējamā primārā atslēga DeterminantsPersonas ID Personas ID

Var redzēt, ka tagad vienīgais primārās atslēgas lauks ir “Personas ID”. Veiksim pārbaudi arī jaunizveidotajām tabulām “Sociālais statuss” (sk .4.4. att.), “Veselības stāvoklis” (sk .4.5. att.) un “Ģimenes stāvoklis” (sk .4.6. att.), kuru struktūras laukus var redzēt tabulā “Klients”.

Tabula “SOCIĀLAIS STATUSS”

4.4. att. – DFAD jaunai tabulai “Sociālais statuss”

Iespējamā primārā atslēga DeterminantsSociāla statusa ID Sociāla statusa ID

Tabula “VESELĪBAS STĀVOKLIS”

4.5. att. – DFAD jaunai tabulai “Veselības stāvoklis”

Tabula “ĢIMENES STĀVOKLIS”

4.6. att. – DFAD jaunai tabulai “Ģimenes stāvoklis”Tabula “DZĪVESVIETA”

Iespējamā primārā atslēga Determinants

Veselības stāvokļa ID

Veselības stāvokļaID

Iespējamā primārā atslēga Determinants

Ģimenes stāvokļa ID

Ģimenes stāvokļaID

20

Tabula atbilst BCNF. Lauks “Adrese” jāsadala iespējamās atomārās vienībās (1NF): “Pilsēta”, “Iela”, “Pasta indekss”, “Mājas numurs”, “Dzīvokļa numurs”. Vienīgais primārās atslēgas lauks var būt “Dzīvesvietas ID”.

Tabula “Dzīvesvieta”Dzīvesvietas ID Pilsēta Iela Pasta indekss Mājas numurs Dzīvokļa numurs Telefons100 Rīga Jersikas LV-1006 45 124a 7844854200 Rīga Krāsotāju LV-1010 28 4 7555445300 Jelgava Kr. Barona LV-542 34 7 87516

4.7. att. – Datu funkcionālās atkarības diagramma tabulai “Dzīvesvieta”

Iespējamā primārā atslēga DeterminantsDzīvesvietas ID Dzīvesvietas ID

Tabula “APSEKOŠANA”Tabula neatbilst BCNF. Determinants “Inspektora ID” nevarētu būt iespējamā primārā atslēga

tabulā “Apsekošana”. Lauks “Apsekotājs” ir jādzēš no tabulas, jo apsekošanu veic inspektors, uz kura datiem norāda saites lauks “Inspektora ID”, t.i. informācija tiek dublēta ar tabulu “Inspektors”.

4.8. att. – Datu funkcionālās atkarības diagramma tabulai “Apsekošana”

Iespējamā primārā atslēga DeterminantsApsekošanas ID Apsekošanas ID

- Inspektora ID

Normalizācijas rezultāts: Iegūstam jaunu tabulas stuktūru, kurai atkal veicam pārbaudi.

Tabula “Apsekošana”Apsekošanas ID Dzīvesvietas ID Inspektora ID Apsekošanas datums Stāvoklis Slēdziens1 100 1 10.02.04. Avārijas Apkure nedarbojās. 2 200 1 15.06.03. Remonta Vajadzīgs remonts.3 300 2 21.08.01 Avārijas Jāmaina izolācija.

21

4.9. att. – Datu funkcionālās atkarības diagramma tabulai “Apsekošana” pēc normalizācijas

Iespējamā primārā atslēga DeterminantsApsekošanas ID Apsekošanas ID

Tabula “INFORMĀCIJAS PIEPRASĪJUMS”Tabula neatbilst BCNF. Par primāro lauku tabulā var kalpot tikai pieprasījuma identifikators

(“Pieprasījuma ID”). Informācijas “Veids” nevar būt primārā atslēga, tas nozīmē, ka pēc šī determinanta tabula “Informācijas pieprasījums” ir jāsadala.

Apskatoties tabulas datus, var ieraudzīt INSERT, UPDATE un DELETE anomāliju laukam “Veids” - jo, ievadīt jaunu informācijas nodošanas veidu var tikai ar jauna pieprasījuma ienākšanu, labot datus var tikai vienam ierakstam, un, dzēšot kādu no veidiem, tiek zaudēti dati par pieprasījumu, uz kuru šis veids ir attiecināms.

Analizējot tos pašus ievades datus, var pamanīt, ka lauks “Veids” sastāv no dažādas nozīmes vērtībām: informācijas pieprasījuma veida (elektronisks, telefonisks, rakstisks, mutisks) un atgriezenisko datu pieprasījuma ātruma (steidzami, nav steidzami). Tas norāda uz 1NF neizpildīšanos. Abi faktori viennozīmīgi ietekmē atbildes formēšanas veidu. Tātad, ir vajadzīga atsevišķa tabula informācijas veidam, ar kuru būs saistītas tabulas “Informācijas pieprasījums” un “Atbilde”.

Tabula “Informācijas pieprasījums”Pieprasījuma ID Atbildes ID Biroja darbn ID Personas ID Datums Veids Saturs1 1 1 111 18.04.05. Elektronisks …2 2 2 112 17.04.05. Mutisks …3 3 3 113 10.04.05. Steidzams …

4.10. att. – Datu funkcionālās atkarības diagramma tabulai “Informācijas pieprasījums”

Iespējamā primārā atslēga DeterminantsPieprasījuma ID Pieprasījuma ID

- Veids

Normalizācijas rezultāts: Izdalīsim atsevišķu tabulu “Informācijas veids” ar sekojošiem laukiem: “Nodošanas veids”,

“Steidzamība”. Tabulā “Informācijas pieprasījums” lauka “Veids” vietā ievietosim ārējās atslēgas lauku ar jaunu tabulu – “Informācijas veida ID”. Veidojas sekojoša tabula:

Tabula “Informācijas pieprasījums” pēc normalizācijas

22

Pieprasījuma ID Atbildes ID Biroja darbn ID Personas ID Datums Informācijas veida ID Saturs1 1 1 111 18.04.05. 1 …2 2 2 112 17.04.05. 1 …3 3 3 113 10.04.05. 2 …

4.11. att. – DFDA tabulai “Informācijas pieprasījums” pēc normalizācijas

Var redzēt, ka tagad vienīgais primārās atslēgas lauks ir “Pieprasījuma ID”. Veiksim pārbaudi arī jaunizveidotajai tabulai “Informācijas veids” (sk .4.12. att.).

Tabula “INFORMĀCIJAS VEIDS”

4.12. att. – DFAD jaunai tabulai “Informācijas veids”

Iespējamā primārā atslēga DeterminantsInformācijas veida ID Informācijas veida ID

Tabula “ATBILDE”Tabula atbilst BCNF. Determinants “Atbildes ID” ir arī vienīgā iespējamā primārā astlēga.

Saistībā ar jauna jēdziena “Informācijas veids” parādīšanos, tabulai “Atbilde” jāpievieno uz to atsauce.

Tabula “Atbilde”Atbildes ID Biroja darbn ID Personas ID Informācijas veida ID Datums Saturs1 1 111 1 19.04.05. …2 2 112 1 25.04.05. …3 3 113 2 10.04.05. …

4.13. att. – Datu funkcionālās atkarības diagramma tabulai “Atbilde”

Tabula “IESNIEGUMS”Tabula atbilst BCNF. Unārās saites nodrošināšanai izmantota primārā atslēga “Iesnieguma

ID” un norāde uz šo pašu atslēgu “Iesnieguma ID2” - parādās iespēja veidot iesniegumu arhīvu, paplašinot nākamā iesnieguma saturu uz iepriekšējā bāzes. Abi determinanti var pildīt primārās atslēgas funkcijas.

Tabula “Iesniegums”

23

Iesnieguma ID Biroja darbn ID Iesnieguma ID2 Personas ID Tapšanas datums Saturs1 1 111 02.02.05. …2 2 1 111 10.03.05. …3 3 2 111 23.04.05. …

4.14. att. – Datu funkcionālās atkarības diagramma tabulai “Iesniegums”

Iespējamā primārā atslēga DeterminantsIesnieguma ID Iesnieguma IDIesnieguma ID2 Iesnieguma ID2

Tabula “IZZIŅA”Tabula neatbilst BCNF. Pirms Boisa-Kodda normālformas izmantošanas, visi lauki jāuzdod

kā nedalāmas atomāras vienības (1NF). Tā lauks “Izdevējs” satur vismaz 3 būtiskas vērtības, kas ir parādītas tabulā.

Tabula “Izziņa”Izziņas ID Biroja darbn IDIesnieguma ID Personas ID Izdošanas datums Izdevējs Saturs

Izdevēja ID

Izdevēja nosaukums

Izdevēja telefons

1 1 1 111 12.12.04. 1 ABC 7777777 ...2 2 2 112 20.03.05. 2 AAA 7888599 ...3 3 3 113 03.05.05. 3 CSDD 7548421 ...

Datu funkcionālās atkarības diagrammā aizvietosim šo lauku ar 3 tā sastāvdaļām, un pēc BCNF būs redzams, pēc kura determinanta jāsadala tabula, ja vienīgā iespējamā primārā atslēga ir lauks “Izziņas ID” (sk. 4.15. att.). Dekompozīcja jāveic pēc lauka “Izdevēja ID”.

4.15. att. – Datu funkcionālās atkarības diagramma tabulai “Izziņa”

Iespējamā primārā atslēga DeterminantsIzziņas ID Izziņas ID

- Izdevēja ID

Normalizācijas rezultāts:

24

Izdalīsim atsevišķu tabulu “Izziņu izdevējs”ar 3 laukiem: “Izdevēja ID”, “Izdevēja nosaukums” un “Izdevēja telefons”, tabulā “Izziņa” atstājot uz to saites lauku. Atsevišķi veiksim jaunizveidotās tabulas pārbaudi.

4.16. att. – Datu funkcionālās atkarības diagramma tabulai “Izziņa” pēc dekompozīcijas

Tabula “IZZIŅU IZDEVĒJS”

4.17. att. – DFAD jaunai tabulai “Izziņu izdevējs”

Iespējamā primārā atslēga DeterminantsIzdevēja ID Izdevēja ID

Tabulas “INSPEKTORS” un “BIROJA DARBINIEKS”Apskata kopā, jo abas ir nepilna lomu dalījuma tabulas.Abas tabulas neatbilst BCNF. Determinants “Amata ID” nevar kļūt par iespējamo primāro

atslēgu, jo tabulai “Inspektors” ir divi tādi iespējamās primārās atslēgas lauki: “Inspektora ID” un “SocDarbn ID”, bet tabulai “Biroja darbinieks” – “Biroja darbn ID” un “SocDarbn ID”. Veiksim dekompozīciju pēc šī determinanta.

Lauks “Amats” nav galīga atomāra vienība, lai varētu veikt pilnvērtīgu analīzi. Lauka “Amats” hierarhija ir redzama tabulas “Inspektors” struktūrā, un tā skar tādu jēdzienu kā rangs. Amati un rangi mijiedarbojas ar saiti viens pret daudziem – vienam amatam vairāki rangi. Te atklājas arī projektēšanas laikā pieļautā loģiskā kļūda (!), jo tabulā “Inspektors” (sk. 4.18. att.) tiek izmantots “Amats”, bet tabulā “Biroja darbinieks” (sk. 4.19. att.) – “Rangs”, lai gan abos gadījumos jāizmanto “Amats”, jo rangs ir jebkura amata apakšvienība.

Tabula “Inspektors”

Inspektora ID SocDarbn IDAmats

Amata ID Amata nosaukumsRangs

Ranga ID Ranga nosaukums

4.18. att. – DFAD tabulai “Inspektors”

Iespējamā primārā atslēga DeterminantsInspektora ID Inspektora IDSocDarbn ID SocDarbn ID

- Amata ID

25

4.19. att. – DFAD tabulai “Biroja darbinieks”

Normalizācijas rezultāts: Izdalīsim atsevišķas tabulas “Amats” un “Rangs”, kuru pārbaude pēc BCNF tiks realizēta

zemāk. Tabulā “Amats” ir 2 lauki: “Amata ID” un “Amata nosaukums”, bet tabulā “Rangs” 3 lauki: “Ranga ID”, “Ranga nosaukums” un “Amata ID”. Tabulām “Inspektors” un “Biroja darbinieks” realizēsim sadali pēc lauka “Amata ID”, atstājot to kā saites lauku. Atsevišķi veiksim jaunizveidoto tabulu pārbaudi pēc BCNF.

4.20. att. – DFAD tabulai “Inspektors” pēc dekompozīcijas

Iespējamā primārā atslēga DeterminantsInspektora ID Inspektora IDSocDarbn ID SocDarbn ID

4.21. att. – DFAD tabulai “Biroja darbinieks” pēc dekompozīcijas

Iespējamā primārā atslēga DeterminantsBiroja darbn ID Biroja darbn ID

SocDarbn ID SocDarbn ID

Tabula “AMATS”

4.22. att. – DFAD jaunai tabulai “Amats”

Iespējamā primārā atslēga DeterminantsAmata ID Amata ID

Tabula “RANGS”

4.23. att. – DFAD jaunai tabulai “Rangs”

Iespējamā primārā atslēga DeterminantsRanga ID Ranga ID

Iespējamā primārā atslēga DeterminantsBiroja darbn ID Biroja darbn ID

SocDarbn ID SocDarbn ID- Amata ID

26

Tabula “SOCIĀLAIS DARBINIEKS”Pirms BCNF pārbaudes ir nepieciešams veikt divas svarīgas operācijas:

ņemot vērā to, ka iepriekš apskatītās tabulas “Inspektors” un “Biroja darbinieks” ir “Sociāla darbinieka” lomu tabulas, bet lomas ir ieņemamie amati, tad lauks “Amata ID” no abiem apakšlīmeņiem: “Inspektora” un “Biroja darbinieka” tabulām, tiek pārvietots uz augstāko līmeni, tabulā “Sociālais darbinieks”.

lauks “Izglītība” jāsadala atomārajās vienībās: “Izglītības ID”, “Izglītība” (domāts, nosaukums), “Izglītības līmenis”.

Rezultātā tabula izskatās sekojoši:

Tabula “Sociālais darbinieks”SocDarbn ID Personas kods Vārds Uzvārds Amata ID Izglītība Kategorija

Izglītības ID Izglītība Izglītības līmenis

4.24. att. – Datu funkcionālās atkarības diagramma tabulai “Sociālais darbinieks” sākumā

Iespējamā primārā atslēga DeterminantsSocDarbn ID SocDarbn ID

Personas kods+Vārds+Uzvārds Personas kods+Vārds+Uzvārds- Amata ID- Izglītības ID

Tabula neatbilst BCNF. Tabulā ir viens primārās atslēgas lauks “SocDarbn ID” un alternatīvā primārās atslēgas kombinācija: “Personas kods”+”Vārds”+”Uzvārds”. Sakarā ar to, ka nedz “Amata ID”, nedz “Izglītības ID” nevar kalpot par iespējamo primāro atslēgu, tabulā “Sociālais darbinieks” pēc šiem determinantiem ir nepieciešams veikt dekompozīciju.

Normalizācijas rezultāts: Izdalīsim atsevišķu tabulu “Izglītība” (atsevišķi neapskatīsim, jo struktūru var redzēt

4.24.att., atstājot tabulā “Sociālais darbinieks” saites lauku. Dzēsīsim lauku “Kategorija”, jo veidojas datu dublēšanās ar tabulu “Amati” – “Amata ID” arī nosaka darbinieka kategoriju.

27

4.25. att. – Datu funkcionālās atkarības diagramma tabulai “Sociālais darbinieks” beigāsIespējamā primārā atslēga Determinants

SocDarbn ID SocDarbn IDPersonas kods+Vārds+Uzvārds Personas kods+Vārds+Uzvārds

Tabula “LĒMUMS”Tabula neatbilst BCNF. Determinants “Likumi” (precīzāk te būtu jāmin “Likuma numurs”)

nevar kļūt par iespējamo primāro atslēgu, jo tabulai “Lēmums” ir iespējams viens primārās atslēgas lauks - “Lēmuma numurs”. Veiksim dekompozīciju pēc šī determinanta.

Tabula “Lēmums”Lēmuma numurs Komisija Datums Likumi Saturs

Šajā gadījumā mēs rīkojamies nedaudz savādāk nekā iepriekšējos gadījumos un nesadalam lauku “Likumi” atomārajās vienībās jau pašā sākumā. Tas šoreiz nav tik svarīgi, jo tabulā “Lēmums” pēc dekompozīcijas nepaliks neviena ar likumu saistīta vienība, piemēram, saites lauks kā tas bija parasti. Tas ir izskaidrojams ar to, ka visos iepriekšējos gadījumos bija jānodrošina saite 1:N, bet šoreiz starp tabulām “Likums” un “Lēmums” jānodrošina N:M saite. Tas notiks ar starptabulas “Saite: Lēmums – Likums” palīdzību.

4.26. att. – Datu funkcionālās atkarības diagramma tabulai “Lēmums” pirms dekompozīcijas

Iespējamā primārā atslēga DeterminantsLēmuma numurs Lēmuma numurs

- Likumi

Normalizācijas rezultāts: Izveidosim atsevišķu tabulu “Likums”, kuras struktūra ir attēlota zemāk, un no tabulas

“Lēmums” dzēsīsim ārā lauku “Likumi”. Tāpat, datu dublēšanas novēršanai, izsvītrosim lauku “Komisija”, jo ar pelēko krāsu ir attēlota ar starptabulas pieslēgšanas iespēja tabulai “Sociālais darbinieks”, no kuras var iegūt visu to darbinieku sarakstu, kas ir piedalījušies lēmuma pieņemšanā – proti, lēmuma pieņemšanas komisiju.

Tabula “Likums”Likumi

28

Likuma numurs Formulējums Pieņemšanas datumsRezultātā iegūsim tabulas “Lēmums” jaunu datu funkcionālo atkarības diagrammu (sk.4.27.att.).

4.27. att. – DFAD tabulai “Lēmums” pēc dekompozīcijas

Iespējamā primārā atslēga DeterminantsLēmuma numurs Lēmuma numurs

Tabula “PABALSTS”Tabula atbilst BCNF. Determinants “Pabalsta numurs” ir arī vienīgā iespējamā primārā

atslēga. Pārbaudot tabulu uz datu dublēšanos, jāizdzēš lauks “Kategorija”, jo norādi par to, vai pabalsts ir pakalpojums vai finansiāla palīdzība, var izgūt no lomu tabulām “Pakalpojums” vai “Finansiāla palīdzība” pēc laukiem “Pakalpojuma ID” un “FinPalidz ID”.

Te jāpievērš uzmanība, ka primārās atslēgas lauka nosaukumā vairs nav “ID” inicāļu (tas ir novērojams arī tabulām “Lēmums”, “Likums”, “Maksājums”, “Juridiska persona”), bet ir parādījies vārds “numurs”. Tas ir izskaidrojams ar to, ka Sociālo pabalstu sistēmas iekšējas lietošanas primārās atslēgas ir “ID”, bet valsts noteiktie standarti ir “numurs” – piemēram, katram likumam ir savs numurs. Principiālas atšķirības to starpā nav, tā ir tikai formalitāte.

Tabula “Pabalsts”Pabalsta numurs Lēmuma numurs Datums Kategorija Mērķis

4.28. att. – DFAD tabulai “Pabalsts” pēc pārbaudes uz datu dublēšanos

Iespējamā primārā atslēga DeterminantsPabalsta numurs Pabalsta numurs

Tabula “PAKALPOJUMS”Tabula neatbilst BCNF. Pirms pārbaudes veicot “Pakalpojuma veida” sadalījumu atomārās

vienībās, iegūstam zemāk ilustrēto struktūru. Vienīgais iespējamais primārās atslēgas lauks ir “Pakalpojuma ID”, pēc determinanta “Pakalpojuma veida ID”, kas nevar būt atlernatīvā primārā atslēga, veiksim tabulas “Pakalpojums” dekompozīciju.

Tabula “Pakalpojums”Pakalpojuma

IDPabalsta numurs

Personas ID

Reģistrācijas numurs

Pakalpojuma veidsPakalpojuma veida ID Pakalpojuma nosaukums

29

4.29. att. – Datu funkcionālās atkarības diagramma tabulai “Pakalpojums” pirms dekompozīcijas

Iespējamā primārā atslēga DeterminantsPakalpojuma ID Pakalpojuma ID

- Pakalpojuma veida ID

Normalizācijas rezultāts: Definēsim jaunu tabulu “Pakalpojuma veids” no 2 laukiem “Pakalpojuma nosaukums” un

“Pakalpojuma veida ID”, kas atdala jauno tabulu no tabulas “Pakalpojums”.

4.30. att. – DFAD tabulai “Pakalpojums” pēc dekompozīcijas un jaunai tabulai “Pakalpojuma veids”

Tabula “FINANSIĀLA PALĪDZĪBA”Tabula atbilst BCNF. Tabula “Finansiāla palīdzība” ir vēl viens pabalstu veids. Vienīgā

iespējamā primārā atslēga ir “FinPalidz ID”.

Tabula “Finansiāla palīdzība”FinPalidz ID Pabalsta numurs Personas ID Summa

4.31. att. – DFAD tabulai “Finansiāla palīdzība”

Tabula “MAKSĀJUMS”Tabula atbilst BCNF. “MaksUzd numurs” ir iespējamā primārā atslēga.

Tabula “Finansiāla palīdzība”MaksUzd numurs Lēmuma numurs Reģistrācijas numurs Datums Mērķis Summa

4.32. att. – DFAD tabulai “Maksājums”

30

Tabula “JURIDISKA PERSONA”Tabula atbilst BCNF. “Reģistrācijas numurs” tiek izmantots kā atslēgas lauks, jo tas ir

unikāls kods, kas tiek piereģistrēts valsts uzņēmumu reģistrā. Iespējamā primārā atslēga ir arī lauku grupa: “Nosaukums” + “Konta numurs”.

Tabula “Finansiāla palīdzība”MaksUzd numurs Lēmuma numurs Reģistrācijas numurs Datums Mērķis Summa

4.33.att. – DFAD tabulai “Juridiska persona”

Iespējamā primārā atslēga Determinants

Reģistrācijas numurs Reģistrācijas numursNosaukums + Konta

numursNosaukums + Konta

numurs

31

5. Gala pārbaude

Pēc visu tabulu pārbaudes no esošām 19 tabulām dekompozīcijas rezultātā tika iegūtas vēl 11 tabulas. Veicot Boisa-Kodda normalizēšanu, anomāliju tabulas tika pārbaudītas atkārtoti. Sakarā ar to, ka tabulu skaits ir visai liels, fizisko pārbaudi es veikšu pēc iepriekšējas nodaļas datiem (faktiski tas jau ir izdarīts iepriekšējā nodaļā), bet nepieciešamās izmaiņas analizēšu jau šajā nodaļā. Beigās, lai varētu vēl dziļāk un detalizētāk apskatīt Sociālo pabalstu biroja sistēmu fiziskā modeļa izpratnē, veidošu tabulu diagrammu, kas būs 3.20. attēlā redzamās shēmas jauna versija pēc normalizēšanas procedūras.

1). Apskatot divas tabulas “Persona” un “Klients” ar saiti 1:1, var redzēt, ka dati dublējas, jo lauks “Personas ID” abās tabulās satur vienādas vērtības. Tāpēc es apvienošu šīs abas tabulas tabulā “Persona” un veikšu šīs tabulas pārbaudi pēc BCNF. Jauna tabula “Persona” BCNF atbilst.

5.1. att. – Datu funkcionālās atkarības diagramma tabulai “Persona”

Iespējamā primārā atslēga DeterminantsPersonas ID Personas ID

Pases numurs Pases numursPersonas kods+Vārds+Uzvārds Personas kods+Vārds+Uzvārds

2). Vēlreiz uzmanīgi izejot cauri tabulas “Iesniegums” datiem, atradu datu dublēšanos starp unārās saites laukiem “Iesnieguma ID” un “Iesnieguma ID2”, dotajā situācijā neveidojās hierarhiskā iesniegumu informācijas uzkrāšana, bet gan datu dublēšana. Tas nozīmē, ka ir jāatstāj tikai “Iesnieguma ID” lauks. Jauna tabula atbilst BCNF.

5.2. att. – Datu funkcionālās atkarības diagramma tabulai “Iesniegums”

3). Sarežģīta situācija ir sanākusi ar tabulu “Sociālais darbinieks” un tā lomu tabulām “Inspektors” un “Biroja darbinieks”. Sakarā ar to, ka lauku “Amata ID” pārvietojām no lomu tabulām galvenās tabulas ķermenī, faktiski lomu dalījumu sociālajam darbiniekam nosaka tieši šis lauks, jo darbinieka loma šajā gadījumā ir viņa ieņemamais amats. Katrā tabulā palikušie lauki “Inspektors”: “Inspektora ID” un “SocDarbn ID”, un “Biroja darbinieks”: “Biroja darbn ID” un “SocDarbn ID”, dublē galvenās tabulas “Sociālais darbinieks” “SocDarbn ID” un “Amata ID” laukus. Pie tam, abas tabulas nodrošina nepilno lomu dalījumu (tā bija definēts ERD), kas nozīmē, ka katra jaunas lomas realizēšana paredz jaunas tabulas veidošanu, kas nav lietderīgi.

32

Rezultātā, abas lomu tabulas tiek iznīcinātas, bet informācija par to, kurš darbinieks ir veicis kādu operāciju var uzzināt no viņa identifikatora un ieņemamā amata vērtībām. Visās saistītās tabulās “Biroja darbn ID” un “Inspektora ID” tiks nomainīti ar “SocDarbn ID”. Rezultāta tabula atbilst BCNF.

5.3. att. – Datu funkcionālās atkarības diagramma tabulai “Sociālais darbinieks”

Iespējamā primārā atslēga DeterminantsSocDarbn ID SocDarbn ID

Personas kods+Vārds+Uzvārds Personas kods+Vārds+Uzvārds

4). Nākamais datu bāzes sistēmas veseluma un vienota stila jautājums. Tabulai “Juridiska persona” pievienošu iekšējās lietošanas identifikatoru “JurPersonas ID”, kas tiks izmantots ārējām atslēgām, jo lauks “Reģistrācijas numurs” neizsaka šī lauka misiju. Visus pārējus determinantus atstāšu kā iespējamās atslēgas laukus. Rezultāta tabula atbilst BCNF.

5.4. att. – Datu funkcionālās atkarības diagramma tabulai “Juridiska persona”

Iespējamā primārā atslēga DeterminantsJurPersonas ID JurPersonas ID

Reģistrācijas numurs Reģistrācijas numursNosaukums + Konta numurs Nosaukums + Konta numurs

Rezultātā visas izmaiņas attēlosim tabulu diagrammā, vēlreiz pārbaudot modeli (sk. 5.5. att).

33

5.5. att. – Tabulu struktūras diagramma pēc BCNF pārbaudēm un normēšanas5.6.

34