Datubāzes normālformas vai kā projektēt pareizi(papildināts)

Kaspars — Sat, 18 Oct 2008 10:10:34 +0000

Kam tas vispar ir vajadzīgs?

Izveidojot datubāzi, kura atbilstu vismaz pirmajām trijām normālformā, mēs atrisinām problēmas, kuras ir saistītas ar informācijas dublēšanos, kā arī ar iespējamām loģiskām un strukturālām uzbūves problēmām, kuras mēdz dēvēt arī par datubāžu anomālijām.

Mīnus normalizācijai ir tāds, ka, tas prasa tabulu sadalīšanu vairākās citās tabulās. Tādēļ, lai pēc tam izgūtu datus no tās ir vajadzīgi vairāku tabulu apvienojumi ar vaicājumiem, kas var samazināt jautājumu izpildes ātrumu.

Anomālijas( problēmas) datubāzēs var būt šādas:

atjauninājuma anomālija
ievietošanas anomālija
dzēšanas anomālija

Atjauninājuma anomālijas piemērs:

Piemēram ir tabula, ar Lietotaja ID, Adresi un Auto. Gadījumā ja lietotājam ir divas vai vairāk automašīnas rodas problēmas:

Lietotaja ID	Adrese	Auto
1	Rīga, Brīvības 5	Audi
2	Rīga, Brīvības 55	BMW
2	Rīga, Brīvības 55	Audi
3	Dobele, kautkas	VW

veicot labošanu lietotāja adresē ir jāatjauno uzreiz divi ieraksti
ja labošanas rezultātā notiek kļūme un nomainās adrese tikai vienā ierakstā un otrā paliks vecā informācija, nebūs iespējams patteikt, kura adrese īsti ir: pirmajā vai otrajā rindiņā

Iespējamais kļūdainās tabulas izskats:

Lietotaja ID	Adrese	Auto
1	Rīga, Brīvības 5	Audi
2	Rīga, Brīvības 55	BMW
2	Rīga, Brīvības 40	Audi
3	Dobele, kautkas	VW

Ievietošanas anomālija:

Tā rodas gadījumos, kad kādu informāciju nevar vispār ievietot,

piemēram, tabula, kura satur datus par reģistrētiem auto(pieņemot, ka katram auto ir jābūt valsts nr. – visi lauki ir obligāti):

ID	Marka	Sasijas num	Valsts nummurzīme
1	Audi	12345	LV-1111
2	BMW	23456	LV-1112
3	VW	34567	LV-1113

Ievietošanas anomālija rodas, tad, kad ir jāievieto dati par vēl neriģestrētu auto, jo tam vēl nav piešķirts valsts nummurs, piemēram, pievienot:

ID	Marka	Sasijas num
4	VW	45678

Tādēļ šādā struktūrā, šādu irakstu ievietot nevar.

Dzēšanas anomālija:

Šāda veida nomālija rodas gadījumā, kad viena fakta dzēšanas rezultātā tiek pazaudēta informācija pa visma par citu faktu, piemēram, ja tiek dzēsta valsts numurzīme LV-1111no datubāzes(iepriekšējais piemērs)(delete from table where vn=lv-1111), tad automātiskie tik dzēsta informācija arī par reģistrēto pašu auto, kas nedrīkstētu notikt.

Normālformas :

1 NF

Tabula atbilst pirmajai normālformai tad un tikai tad, kad visi tās kolonas(domēni) satur atomāras(nedalāmas vērtības)

Ja vērtību var sadalī vairākās daļās un tai nezūd jēga tad vērtība ir neatomāra.

Bieži jebkura vērtība var būt gan atomāra, gan neatomāra, pimēram skaitlis: 1234 ir:

atomāra vērtība, ja ar to sparot pin kodu
neatomāra vērtība, ja ar to saprot atsevišķu skaitļu rindu no 1 līdz 4

Skaitļu rinda var būt gan 12 un 34, kā arī samainīta vietām 43 un 21, un skaitļu jēga no tā nemainīsies. Tur pretīm jā samainīs pinkoda skaitļus vietām jēga skaitļiem vairs nav.

Neatomāras bieži pielietojamas vērtības piemērs ir adrese, kuru glabā vienā laukā, piem,

Pilsēta, Iela, Māja

2NF:

tabulai jāatbilst 1 NF

Tabula atbilst otrajai normālformai, ja katrs neprimārais atslēgas lauks ir atkarīgs no visas primārās atslēgas. (Nevis no primārās atslēgas kādas daļās).

Otrajai normālformai nozīme ir tikai realitātēs, kurās ir sarežģīta primārā atslēga(piem, sastāv no diviem laukiem), ja tabulai ir viena konkrēta primārā atslēga, tad tāda tabula jau autmātiski atbilst 2. normālformai, vai vienkāršiem vārdiem- tabulā nedrīkstētu būt divi atribūti, kas varētu būt kā primārie lauki.

*EmployeeID	LastName	FirstName	*ProjectNumber	ProjectTitle
EN1-26	O’Brien	Sean	30-452-T3	STAR manual
EN1-26	O’Brien	Sean	30-457-T3	ISO procedures
EN1-26	O’Brien	Sean	31-124-T3	Employee handbook
EN1-33	Guya	Amy	30-452-T3	STAR manual
EN1-33	Guya	Amy	30-482-TC	Web Site
EN1-33	Guya	Amy	31-241-TC	New catalog

Lai atrisinātu šo problēmu ir jārīkojas sekojoši:

Identificēt atribūtus, kuri ir atkarīgi tikai no primārās atslēgas daļas
Izveidot jaunu realitāti
Ievietot identificētos atribūtus jaunajā realitātē
Izveidot sasaisti starp veco un jauno realitāti

Šinī gadījumā, pirmārā atslēga varētu būt EmployeelID un ProjectNumber, tādēļ tie ir jāsadala:

EMPLOYEES

*EmployeeID	Last Name	First Name
EN1-26	O’Brien	Sean
EN1-33	Guya	Amy
EN1-35	Baranco	Steven
EN1-36	Roslyn	Elizabeth

EMPLOYEES_PROJECTS

*EmployeeID	*ProjectNum
EN1-26	30-452-T3
EN1-26	30-457-T3
EN1-26	31-124-T3
EN1-33	30-328-TC
EN1-33	30-452-T3

PROJECTS

*ProjectNum	ProjectTitle
30-452-T3	STAR manual
30-457-T3	ISO procedures
30-482-TC	Web site
31-124-T3	Employee handbook
31-238-TC	STAR prototype

3NF

Tabula apmierina trešo normālformu, ja tā apmierina otro NF un katrs ne primārais atslēgas lauks ir ne tranzistīvi atkarīgs no primārās atslēgas.

No matemātikas viedokļa nedrīkstētu sanākt, ka x->x un z->x, jo sanāk ka z->y, jo z->x->y.

(Nedrīkst būt situācija, kad ir saikne(attiecības) starp diviem vai vairākiem neprimāriem laukiem)

Piemēram:

id	Vārds	Kabinets	Telefons
1	Kaspars	101	02
2	Jānis	102	03
3	Kaspars	102	03

Šinī situācijā, pieņem, ka:

viens telefona nummurs(nav primārā atslēga) var būt pieslēgts vienā kabinetā(nav primārā atslēga)
un viens cilvēks var atrasties vairākos kabinetos

Rezultātā sanāk, ka telefons ir atkarīgs ne tikai no primārās atslēgas, bet arī no kabineta, kas nav primārā atslēga

Lai atrisinātu šādas problēmas ir jārīkojas šādi:

Jāpārnes savā starpā saistītos noprimāros atribūtus uz jaunu realitāti(tabulu) saglabājot saikni viņu starpā
Izmantot lauku, kurš noteica atkarību kā primāro lauku
Izveidot sasaisti starp veco un jauno realitāti

Tādēļ, lai apmierinātu 3 NF vajadzētu sadaīt šādi

Vārds	Kabinets
Kaspars	101
Jānis	102
Kaspars	102

Kabinets	Telefons
101	02
102	03

Šinī tabulā kabineta nummurs, jau var būt par primāro atslēgu

Kā darbināt linux aplikācijas Windows vidē-andLinux

IT sviestapika » normālforma

Datubāzes normālformas vai kā projektēt pareizi(papildināts)