Duomenų bazės projektavimas, vadinamas . Kam reikalinga duomenų bazės ? Tikriausiai argumentas, jog normalizuota duomenų bazė užima mažiau vietos ir veikia žymiai greičiau jūsų neįtikins. Kam tai rūpi, turint tokius galingus kompiuterius, kaip dabar? Pagrindinis tikslas - duomenų dubliavimo sumažinimas ir anomalijų pašalinimas. Atlikus duomenų bazės normalizaciją, žymiai lengviau atnaujinti duomenis esančius lentelėse, mažai tikėtina, jog prisivels klaidų, dėl to kad vieną kartą buvo įvestas žodis „labas“, o kita kartą netyčia „kabas“.

Mano tikslas - kiek galima paprasčiau paaiškinti taisykles ir patį principą. Jeigu jums pasirodys, kad mano pateikta informacija perdaug paviršutiniška, tai pasirinkite „duomenų bazių kursą“ bet kuriame universitete arba pasiieškokite kokybiškesnės informacijos internete.

Pirmiausiai pradėsiu nuo apibrėžimų:
Duomenų bazė – organizuotas duomenų saugojimo būdas. Duomenų bazės būna sudarytos iš lentelių.
Lentelės sudarytos iš laukų, kuriuose saugoma informacija.
Pirminis raktas – laukas, kuris konkrečioje lentelėje saugo unikalų identifikatorių, pagal kurį galima paimti vieną konkretų įrašą iš lentelės.
Duomenų santykiai tarp skirtingų lentelių apibrėžiami ryšiais. Gali būti trijų tipų ryšiai:

  • Vienas su vienu (1:1) – kai vienas lentelės įrašas atitinka tiktai vieną kitos lentelės įrašą.
  • Vienas su daug (1:M) – kai vienas įrašas pirmoje lentelėje gali turėti daug atitikimų antroje.
  • Daug su daug (M:N) – kai daug įrašų iš vienos lentelės, turi daug atitikimų kitoje.

Realiai nėra prasmės egzistuoti ryšiui 1:1, jeigu toks ryšys egzistuoja, tai kodėl nesujungus tų dviejų lentelių į vieną? Taip pat nerekomenduojama kurti ryšių M:N. Yra sistemų, kurios palaiko tokius ryšius, tačiau dažniausiai jie yra pakeičiami į M:1 ir 1:N, įterpiant papildomą lentelę.

Antrinis raktas – jeigu tarkime, kad tarp lentelių yra ryšys 1:M, tai pirmoji lentelė turės pirminį raktą, o lentelė M antrinį. Raktų pagalba apibrėžiami ryšiai tarp lentelių.

Pirmoji normalinė forma

  • Jokių dubliuotų laukų, kiekvienas įrašas turi vienodą laukų skaičių, tik vienetinės reikšmės.
  • Visi laukai yra nepriklausomi nuo kitų.
  • Kiekviena eilutė turėtų turėti pirminį raktą.

Antroji normalinė forma

  • Visi duomenys turi atitikti pirmos reikalavimus.
  • Pašalinti duomenų dubliavimus stulpeliuose.
  • Sukurti ryšius tarp lentelių.

Trečioji normalinė forma

  • Visi duomenys turi atitikti antros reikalavimus.
  • Visi lentelės laukai turi tiesiogiai priklausyti nuo pirminio rakto.

Yra ir daugiau normalinių formų, bet apie jas nekalbėsiu, nes jos labiau teorinės ir diskutuojamos tik tarp mokslininkų, o praktikoje nelabai taikomos.
Suprantu, kad sausa teorija nėra labai aiški, todėl dabar pabandysiu pateikti vieną pavyzdį.
Taigi, tarkim turime parduotuvėje apsipirkusių žmonių prekių statistiką. Ją sudaro tokie laukai: parduotuvė, parduotuvės adresas, pirkėjas, prekė, kaina, suma. Tam sukursime lentelę su pavyzdiniais duomenimis:

npdb1.jpg

Savaime suprantama, kad šita lentelė tikrai nėra NF1, nes Preke ir Kaina minėta du kartus, to būti neturėtų, todėl pertvarkome.

npdb2.jpg

Tačiau ir po pertvarkymo tai dar nėra NF1 laukas Suma yra laukų Kaina suma, tokie dalykai neturi būti saugomi duomenų bazėje nes: 1) Jeigu reikia galutiniame rezultate išvesti sumą, tai ją apskaičiuoti visai nesunku; 2) Jeigu pasikeis vienos iš prekių kaina, reikės sukurti sudėtingą mechanizmą, kuris atnaujintų visas sumas, kad jos būtų teisingos, o tai jau bereikalingas resursų švaistymas. Taigi, pirmiausiai panaikinsime lauką Suma, o po to dar pridėsime lauką Id.

npdb3.jpg

Dabar pabandysime sukurti NF2. Kaip matote problema ta, kad parduotuvė „Rytas“ ir jos adresas pakartoti du kartus, tai, be abejo, bereikalingas informacijos dubliavimas ir jeigu atidžiau pažvelgtumėte į lentelę, tai įsivėlė gramatinė klaida, vienu atveju tas pats parduotuvės pavadinimas su trumpąją ‘i’ kitu su ilgąją. Analogiškai ir su prekėmis.
Taigi suskaldome į tris lenteles.

npdb4.jpg

Be to, kad perskyrėm į tris lenteles dar įdėjom ir du ryšius 1:M
Dabar pereikime prie NF3. Nelogiškumas ankstesnėje, schemoje, tai kad pirkėjas pririštas prie parduotuvės, pagal tokią schemą, viena parduotuvė gali turėti tik vieną pirkėją, o tai akivaizdi nesąmonė. Siekdami tai pataisyti pirkėją iškelsim į kitą lentelę

npdb5.jpg

Sveikinu, dabar jūsų duomenų bazė atitinka NF3, tikiuosi pavyzdys paaiškino padėtį.

P.S. Gal kas nors galite pasiūlyti geresnį būdą atvaizduoti duomenų bazės ryšiams, laukams ir turinui?

Panašūs straipsniai


“Duomenų bazių normalinės formos” komentarų: 11

  1. dado1945
  2. enc

    yra atitinkamas softas lentelių schemoms braižyti, bet nė vienas jų nėra labai geras (bent jau neatitiko mano reikalavimų)

  3. Kazkas

    microsoft office visio ;)

  4. Slave

    Šiaip Visio, bet man labiau prie širdies poprieriaus lapas ir tušinukas ;) Retkarčiais prisiminti teoriją yra gerai. Dėkui už postą NePo. :-)

  5. Sergej Kurakin

    Lentele po pirmo pertvarimo (npdb2.jpg) vadinama universaliaja lentele.

    O dabar griškime į realų pasaulį. Po tavo optimizacijos (npdb5.jpg), jai prekems pakeis kainas, mes negalesime žinoti, kiek kainavo pirkejui preke per priesh tai buvusios pirkimus - tokiam pavizdžiui tai dydžiulis minusas.

    Dar vienas dalykas, kurio aš nepagaunų iš pavizdžių - aš nepagaunų kur yra pirktų prekių kiekis? Dar priesh optimizacija (universalioje lenteleje) kieki buvo įmanoma paskaičioti padalinus suma ish kainos (keistas alus pas jus, 7/5 = 1.4 - jis pirko pilstoma alu, ar dauzita buteli), o jau normalinei formoi 3 mes prarandame prekiu kieki, benet į sąrišiu lentele ikišime kiekviena pirkinį taskirai.

  6. bss

    antrinis raktas? manau jis vadinasi isorinis. Lenteliu normalizavimo formu yra 4 + Boiso-Kodo NF. univere moke kad 4nf yra privaloma visoms db

  7. NeARAZ

    (kažką bandau sakyt su savo visai surūdijusiom duombazių žiniom…)

    Kiek atsimenu univerą, tai iš ten suprast kas yra normalizacija, buvo tikrai sunku. Spėju, daugeliu atvejų net neįmanoma. Man visada atrodė taip: jei žmogus su sveiku protu atsisėda ir pradeda projektuot duombazę, tai jam 3 normalinė forma ir gaunasi natūraliai. O univere ten kažkaip atvirkščiai reikėjo: pirma prisiverst sugalvot “kuo gaidiškesnę duombazę”, o tada visokių suktų taisyklių pagalba datempt ją iki 3NF. Argi kas nors taip daro? :)

    Beje, man regis pati straipsnio pradžia kiek klaidinanti: kad išlošt greičio (vietos ir šiaip aiškumo sąskaita), duombazės kartais daromos būtent ne-normalizuotos, t.y. su duplikuotais duomenimis ir t.t.

  8. Tautvydas Levinskas

    Pritariu kolegai. DB projektavimo realybė labai skiriasi nuo DB normalinių formų teorijos. Universitetai būtų dar išmintingesni, jei prie teorijos dėstytų laboratoriniuose ne teorijos pritaikymą, o realius praktinius uždavinius (bet tam, žinoma, laiko nėra - to išmoko darbas). Pamenu, kai aš, ką tik iškeptas IS specialistas, ėmiausi įmonėje tvarkyti DB - senieji programuotojai buvo pakraupę, tačiau jie buvo teisūs - praktikoje reikia vadovautis ne taisyklėmis, o sveiku protu, patirtimi, įvertinti DBVS, OS, duomenų kiekius, užklausų variantus, geležies galimybes. Tai svarbu, kadangi normalinės formos ne tam, kad jas teoriškai projektuotume, o tam, kad jomis remiantis, įgyvendintume praktinius uždavinius.

  9. Arunas

    Teisybė, Tautvydai!!! Ir ji slypi kažkur anapus.

  10. ...

    shlamshtas visa tai - vietoj to, kad sedetumet ir skaitytumet sausa teorija, projektuokit duomenu bazes. ir kaip sake neAraz - joks sveiko proto programuotojas nepradeda nuo kvailos duombazes ir jos nenormalizuoja. beje, pavyzdziu kaip normalines formos dirba leciau nei nenormalizuota duombaze irgi apstu - kiekvienas atvejis individualus, kas tinka petrui, netinka jonui.

  11. desper4do

    Kaip tik kemsu sitas pievas sau i galva, nes duombaziu koliokvumas laukia. Kaip teisingai sake neARAZ, tikrai sunku suprasti kas tai yra skaitant ktu’no teorinius isvedziojimus.. Bet gal cia kaltas neveikiantis kairysis mano smegenu pusrutulis ;)

Rašyti komentarą

Jūs privalote prisijungti jeigu norite rašyti komentarą.