Duomenų bazės (DB). Reliacinės DB

1. Duomenų bazės (DB). Reliacinės DB • Duomenų bazės samprata; • Duomenų bazių modeliai; • Reliacinės duomenų bazės ir jų savybės; • Duomenų normalizavimas ir normalinės formos.

2. Duomenų bazės samprata Duomenų bazė - tai kartu saugomų ir susijusių duomenų, skirtų apdoroti kompiuteriu, visuma. Duomenys atitinka realaus pasaulio tam tikros - skirtos automatizuoti - dalies (taikymo srities) modelį. Duomenų pavyzdžiai: bibliotekos kartoteka, telefonų abonentų knyga, pirkėjų užsakymų registracijos žurnalas ir kt. Duomenys saugomi ir apdorojami ne bet kaip, o laikantis tam tikrų susitarimų, taisyklių. Kitaip tariant, duomenys tam tikru būdu sutvarkyti (priešingu atveju nebūtų DB). Reiktų skirti vadinamąjį fizinį ir loginį duomenų organizavimą. Pirmasis nurodo duomenų fizinio išdėstymo būdus kompiuterio atmintyje, o antrasis - duomenų struktūros vaizdavimą - modelį, reikalingą vartotojams.

3. Duomenų bazės samprata (2) Platesne prasme duomenų bazė tapatinama su duomenimis ir programų rinkiniu, atliekančiu tų programų apdorojimo operacijas. Toks rinkinys vadinamas duomenų bazių valdymo sistema (DBVS). Plačiausia prasme duomenų bazė – tai informacinių, programinių, matematinių, kalbinių, organizacinių ir techninių priemonių, įvertinant saugomus duomenis ir taip pat technologiniame procese užimtą personalą, sistema, skirta centralizuotam duomenų kaupimui, siekiant gauti tuo metu reikalingą informaciją.

4. Duomenų bazės samprata (3) • Duomenims, saugomiems duomenų bazėje, būdingos šios savybės: • integruotumas; • nepertekliškumas; • nepriklausomumas. • Duomenų integruotumas reiškia, kad visi duomenys kaupiami ir saugomi kartu nustačius jų tarpusavio ryšius. Taip saugomus duomenis dažniausiai naudoja ne vienas, o keli vartotojai. • Antroji savybė nusako tai, jog duomenys saugomi vengiant jų dubliavimo. Kai yra pertekliškumas, t.y. kelios duomenų kopijos, joms veltui eikvojama atmintis, o modifikuojant duomenis tenka kelis kartus naudoti tas pačias atnaujinimo operacijas. Be to, kai duomenų kopijos atitinka skirtingas atnaujinimo stadijas, tai gali iššaukti prieštaringos informacijos pateikimą. • Duomenų nepriklausomumas reiškia, kad duomenų apdorojimo taikomosios programos nesikeičia modifikuojant duomenis.

5. Duomenų bazių modeliai • Pagal tai, kokiu būdu duomenys jungiami į visumą, išskiriami šie duomenų organizavimo modeliai (DB tipai): • tinklinis modelis; • hierarchinis modelis; • reliacinismodelis; • objektinis modelis; • Pastaruoju metu bene populiariausios duomenų bazės, kuriose duomenys organizuojami pagal reliacinį modelį, - tai reliacinės duomenų bazės.

6. Dženi SesilijaBergren ūgis 170, briunetė 1972.05.29 Melin Bergren ūgis 168, blondinė 1970.10.31 Džonas PeterBergren ūgis 190, šatenas 1967.03.21 Ulf Ekberg ūgis 188, blondinas 1970.12.06 Vokalas Solo gitara YAMAHA Bos gitara KORD Mušamieji CASIO Tinklinis modelis Tinklinę duomenų struktūrą galima pateikti, pavyzdžiui, tokia schema: Tinklinis modelis dažniau taikomas geografinėse informacinėse sistemose

7. Hierarchinis modelis Hierarchiniam duomenų modeliui yra būdingas žemesnio lygmens objektų pavaldumas aukštesniojo lygmens objektams. Aukštesnio ir žemesnio lygmens objektus sieja ryšys “vienas su daugeliu”. Be įprastinių operatorių, tokiose DB naudojami ir perėjimo iš vieno hierarchijos lygio į kitą operatoriai. Pavyzdžiui, muzikinių grupių hierarchinės DB modelis galėtų būti toks:

8. Reliacinis duomenų modelis Reliacinį duomenų modelį 1969 metais pasiūlė firmos IBM darbuotojas E.F.Kodas (E.F.Codd). Reliacinė duomenų bazė – tai tokia duomenų visuma kurioje informacija saugoma dvimatėse lentelėse. Kiekviena lentelė susideda iš eilučių (dar vadinamų įrašais arba kortežais (record)) ir stulpelių (dar vadinamų laukais arba atributais (field)). Naudosime įvairias šių terminų poras. Eilutėse yra duomenys apie pateiktus lentelėje faktus (dokumentus, žmones, vienu žodžiu, – vieno tipo objektus). Stulpelių ir eilučių susikirtimuose yra konkrečios saugomų lentelėje duomenų reikšmės (laukų reikšmės).

9. Dvimatė lentelė Pažymėtina, kad lauko sąvoka atitinka DE sąvoką anksčiau nagrinėtuose duomenų vaizdavimuose. Į lentelės įrašus įtraukiamos duomenų porcijos, kurias sudaro DE reikšmės, dar vadinamos laukų reikšmėmis (pvz., «A2599», «98 01 26» ir pan.). Bet kurios eilutės ir bet kurio stulpelio susikirtime turi būti tik viena DE reikšmė, o ne tų reikšmių rinkinys. 5.1 pav.

10. Reliacinės duomenų bazės savybės • Reliacinėse DB kiekviena lentelė pasižymi tokiomis savybėmis: • Visi įrašai yra vienodai organizuoti, turi tą pačią struktūrą. Visuose įrašuose yra tiek pat laukų, o laukai yra vienarūšiai, t.y. atskiro lauko reikšmės yra vieno tipo. Tačiau skirtinguose laukuose gali būti skirtingų tipų duomenys; • Lentelėje negali būti tuščių įrašų, taip pat identiškų įrašų, t.y. įrašų su pasikartojančiais duomenimis, nors atskiri duomenų elementai gali būti tušti arba pasikartojantys; • Įrašų ir laukų išdėstymo tvarka lentelėje nėra svarbi. Atliekant duomenų apdorojimo operacijas lentelės eilutės ir stulpeliai gali būti peržiūrimi bei tvarkomi bet kuria tvarka, nepriklausomai nuo jų informacinio turinio. • Kiekvienai lentelei suteikiamas vardas. Lentelės vardas turėtų atspindėti atitinkamo realaus informacinio objekto pavadinimą, o laukų vardai – to objekto atributų pavadinimus.

11. Lentelių raktai Nors skaitoma, kad eilutės lentelėje nėra išrūšiuotos, bet kuri DBVS turi rūšiavimo pagal eilutes ir stulpelius įrankius. Kadangi stulpelių išdėstymo tvarka taip pat nesvarbi, kreipimasis į juos vykdomas pagal jo vardą, kurie duotoje lentelėje turi būti unikalūs, bet neprivalo būti tokie visoje duomenų bazėje. Lentelėms nustatomi raktai, t. y. laukai ar laukų grupės, kurių įgyjamos reikšmės yra nepasikartojančios, taigi šios reikšmės vienareikšmiškai identifikuoja tų lentelių įrašus. Lentelės gali turėti po kelis raktus, iš kurių konkrečiu momentu faktiškai naudojamas tik vienas - pirminis raktas(primary key). Jei pirminį raktą sudaro keli laukai, jis vadinamas sudėtiniu pirminiu raktu (composite primary key).

12. Užsakymai UŽSAKYMO NUMERIS PIRKĖJO KODAS PREKĖS KODAS UŽSAKYMO DATA UŽSAKYTAS KIEKIS CUSTOMERS CustomerID CompanyName City Country …. Lentelių pateikimo formos Labai dažnai naudojama sutrumpinta lentelių pateikimo forma, kai iš pradžių užrašomas lentelės vardas, o po to tarp skliaustelių išvardijami lentelės laukų vardai. Laukų, įeinančių į pirminio rakto sudėtį, vardai pabraukiami. Toks užrašas vadinamas lentelės schema. 5.1 pav. pateiktos lentelės schema atrodo taip: UŽSAKYMAI (UŽSAKYMO NUMERIS, PIRKĖJO KODAS, PREKĖS KODAS, UŽSAKYMO DATA, UŽSAKYTAS KIEKIS). Didesniam vaizdumui gauti nustatant ryšius tarp lentelių taip pat dažnai naudojama stačiakampė lentelės schema:

13. Ryšiai tarp lentelių Į reliacinių DB sudėtį įeinančios lentelės tarpusavyje susiejamos. Ryšį tarp atskirų lentelių nustato bendri, sutampantys tų lentelių laukai, kurie dar vadinami siejančiais laukais. Taip susietų lentelių visuma ir apibrėžia reliacinį modelį. Kitaip negu rodykliniuose duomenų modeliuose, kur ryšiams iliustruoti naudojamos rodyklės, reliaciniame modelyje nėra atskirų elementų vaizduoti ryšiams - jie atspindimi pačiomis lentelėmis (siejančiais laukais). Galima pastebėti reliacinio modelio tam tikro laipsnio pertekliškumą. Pertekliniai laukai įvedami dažniausiai dėl dviejų priežasčių: a) daliai lentelių reikalingi laukai, skirti suformuoti pirminius raktus, t.y. vienareikšmius lentelių įrašų identifikatorius; b) kai kurioms lentelėms reikalingi laukai, kurie nėra pirminiai raktai (ar jų dalis), bet naudojami nustatyti ryšiams.

14. Išvykimo punktas Reiso Nr. Atvykimo punktas Lėktuvo tipas Reiso Nr. + Data Laisvos vietos Reliacinis DB modelis Ankstesnėje temoje suformuotą rodyklinį bilietų rezervavimo DB modelį: pervesime į reliacinį DB modelį: REISAS(REISO_NR., IŠVYKIMO PUNKTAS, ATVYKIMO PUNKTAS, LĖKTUVO TIPAS); LAISVOS VIETOS(REISO_NR., DATA, LAISVOS VIETOS). Arba:

15. REISAS REISO_NR. IŠVYKIMO PUNKTAS ATVYKIMO PUNKTAS LĖKTUVO TIPAS LAISVOS VIETOS REISO_NR. DATA LAISVOS VIETOS OrderID (PK) CustomerID (FK) OrderDate Freight Ship Address …. CustomerID (PK) CompanyName City Country …. Reliacinis DB modelis (2) PK – Primary Key (pirminis raktas) FK – Foreign Key (išorinis raktas)

16. Reliacinis DB modelis (3) Pirmoje schemoje sąryšį (relationchip) tarp lentelių sukuria raktinis atributas „Reiso Nr.”. Čia lentelė „REISAS” vadinama pagrindine (master) lentele lentelės „LAISVOS VIETOS” atžvilgiu, o lentelė „LAISVOS VIETOS” - antrine (detail) lentele lentelės „REISAS” atžvilgiu. Antroje schemoje raktiniai atributai CustomerID išskirti į pirminį (PK) ir išorinį (FK) raktus. Pirminio rakto prasmę jau aptarėme anksčiau. Laukas, nurodantis įrašą kitoje lentelėje, kuris susijęs su duotu įrašu, vadinamas išoriniu raktu (foreign key). Mūsų atveju lentelės Orders išorinis raktas yra laukas CustomerID. Kitaip tariant, išorinis raktas – tai laukas ar jų rinkinys, kurio reikšmės sutampa su kitos lentelės pirminio rakto reikšmėmis. Ryšys tarp lentelių nustatomas (sudaromas) priskiriant vienos lentelės išorinio rakto reikšmes kitos lentelės pirminio rakto reikšmėms.

17. Įstaigos darbinės veiklos informacinis modelis 5.2 pav.

18. Įstaigos darbinės veiklos reliacinės DB modelis (2) SKYRIUS (SKYRIAUS_NR, PAVADINIMAS, VADOVAS, BIUDŽETAS); DARBAS (DARBO_NR, SKYRIAUS_NR, DARBO_APRAŠYMAS); DARBUOTOJAI (DARBUOTOJO_NR, DARBO_NR, PAVARDĖ, SKYRIAUS_NR, ALGA); DARBINĖ_VEIKLA (PASKYRIMO_DATA, DARBUOTOJO_NR, PAREIGOS); ALGOS_KEITIMAI (KEITIMO_DATA, DARBUOTOJO_NR, ALGA). Čia atsižvelgiama į tai, jog požymis „DARBO_NR” nėra visuotinai priimtas identifikatorius įstaigoje, o kiekviename skyriuje yra savi darbų numeriai. Todėl pilnai darbų identifikacijai į lentelės „DARBAS” schemą įvedamas papildomas laukas „SKYRIAUS_NR”, kuris kartu su lauku „DARBO_NR” sudaro pirminį raktą. Laukas „DARBUOTOJO_NR” įvedamas į lentelių „DARBINĖ_VEIKLA” ir „ALGOS_KEITIMAI” schemas taip pat kaip pirminio rakto dalis. Į lentelę „DARBUOTOJAI” įvestas papildomas laukas („DARBO_NR”), neįeinantis į pirminio rakto sudėtį, bet naudojamas ryšiui užtikrinti.

19. Reliacinė DB lentelių schema DARBUOTOJAI DARBUOTOJO_NR DARBO_NR PAVARDĖ SKYRIAUS_NR ALGA ALGOS_KEITIMAI KEITIMO_DATA DARBUOTOJO_NR ALGA DARBAS DARBO_NR SKYRIAUS_NR DARBO_APRAŠYMAS DARBINĖ_VEIKLA PASKYRIMO_DATA DARBUOTOJO_NR PAREIGOS SKYRIUS SKYRIAUS_NR. PAVADINIMAS VADOVAS BIUDŽETAS

20. Lentelių sąryšio schema (Relationship), sudaryta su DBVS MS Access

21. Duomenų normalizavimas ir normalinės formos Bet kurią DB galėtų sudaryti tik viena lentelė. Tačiau jei būtų daug lentelės laukų ir gausu duomenų, atsirastų žymus duomenų pertekliškumas, dubliavimas, o apdorojant duomenis reikėtų sugaišti nemažai papildomo laiko. Norint to išvengti, reikia didelę, sudėtingos struktūros lentelę suskaidyti (dekomponuoti) į mažesnes, paprastesnės struktūros lenteles. Šis procesas vadinamas normalizavimu. Jo metu sprendžiamos tokios problemos: • kaip sugrupuoti duomenų elementus, t. y. kokius laukus surinkti į vieną lentelę; • kaip parinkti raktus; • kaip tarp lentelių nustatyti ryšius.

22. Lentelės laukų funkcinės priklausomybės Normalizuojama keliais žingsniais (etapais), kurių metu lentelės įgyja atitinkamas pateikimo formas, vadinamas normalinėmis formomis (NF). Taigi, normalizuojamos lentelės pervedamos iš vienos NF į kitą. Pirmiausia apibrėšime terminą „funkcinė priklausomybė”. Sakoma, kad lentelės laukas B funkcionaliai priklauso nuo tos pačios lentelės lauko A, jei bet kuriuo momentu kiekvieną A reikšmę atitinka ne daugiau kaip viena B reikšmė. Kitaip tariant, A lauko reikšmės identifikuoja B lauko reikšmes. Trumpai tai užrašoma naudojant rodyklę: A  B. Jei keli laukai priklauso nuo vieno lauko A, pateikiamas jų sąrašas, pvz., A B, C, D. Pvz.: lentelėje DARBUOTOJAI (DARBUOTOJO_NR, DARBO_NR, PAVARDĖ, SKYRIAUS_NR, ALGA); DARBUOTOJO_NRPAVARDĖ

23. Laukų funkcinės priklausomybės Jei neraktinis laukas funkcionaliai priklauso nuo sudėtinio rakto atskiros dalies, tai suprantama kaip šio lauko dalinė funkcinė priklausomybė nuo rakto. Jei neraktinis laukas priklauso tik nuo viso sudėtinio rakto, o ne nuo atskirų dalių, tai sakoma, kad yra pilna funkcinė šio lauko priklausomybė nuo rakto. Jei A, B ir C laukams egzistuoja priklausomybės A  B bei B C, bet atvirkštinių priklausomybių nėra, tai sakoma, kad C tranzityviai priklauso nuo A. Pažymėtina, kad funkcinės priklausomybės atspindi duomenų vidinius, prasminius ryšius, tuo tarpu laukai - duomenų struktūrą.

24. Normalinės formos (NF) Yra trys pagrindinės NF. Reikia užtikrinti, kad visi laukai būtų atomariniai, t.y. mažiausios įmanomos komponentės. Kitaip sakant, kiekvienos lentelės lauke yra galima tik viena reikšmė, o ne jų rinkinys. Lentelė yra pirmosios normalinės formos (1NF), jeigu kiekvienas neraktinis laukas yra pilnoje arba dalinėje funkcinėje priklausomybėje nuo bet kokio galimo tos lentelės rakto. Lentelė yra antrosios normalinės formos (2NF), jeigu ji yra 1NF ir kiekvienas jos neraktinis laukas yra pilnoje funkcinėje priklausomybėje nuo bet kokio galimo tos lentelės rakto. Lentelė yra trečiosios normalinės formos (3NF), jeigu ji yra 2NF ir kiekvienas jos neraktinis laukas yra tiesioginėje pilnoje, bet ne tranzityvioje priklausomybėje nuo bet kokio galimo tos lentelės rakto. T.y. reikia užtikrinti, kad visi neraktiniai laukai būtų vienas nuo kito nepriklausomi. Jei taip nėra, reikia sukurti naują lentelę (sąryšį), kuri neturėtų neraktinių lakų tarpusavio priklausomybės.

25. 1 NF Kaip 1NF lentelės pavyzdį galima pateikti lentelę, turinčią informaciją apie gaminių tiekimą. Lentelės schema yra tokia: TIEKIMAS(TIEKĖJO_NR(TN),GAMINIO_NR(GN), TIEKĖJO_PAVARDĖ(TP), DUOMENYS_APIE_TIEKĖJĄ(TD), TIEKIMO_KAINA(TK)). Funkcinės priklausomybės tarp šios lentelės laukų: TN+GN  TP, TD, TK TN  TP, TD . Čia pirmoje eilutėje parodytos pilnos funkcinės priklausomybės nuo pirminio rakto, o antroje - dalinės funkcinės priklausomybės nuo sudėtinio rakto dalies TN. Kaip matome, laukai TP ir TD, būdami neraktiniais laukais, funkcionaliai priklauso nuo vienintelio galimo rakto TN+GN dalies TN. Taigi ši lentelė nėra 2NF, tai reiškia, kad ji yra 1NF.

26. 1 NF anomalijos • Pirmos NF lentelių apdorojimui būdinga nemaža keblumų, vadinamų anomalijomis: • Įvedimo anomalija. Negalima įvesti tam tikrų duomenų tol, kol neįvesta pilna rakto reikšmė (pvz., pateiktoje lentelėje TIEKIMAS negalima įvesti jokių duomenų apie tiekėją iki to laiko, kol jis nepristatęs kokio nors gaminio). • Atnaujinimo (keitimo) anomalija. Reikia didelių papildomų laiko, atminties resursų, atnaujinant lentelėje dažnai pasikartojančias reikšmes bei įterpiant lentelėje naujus laukus (pvz., norint įvesti papildomus duomenis apie tiekėją, reikia papildomų resursų, jei tiekėjo pristatomų gaminiųįvairovė didelė). • Šalinimo anomalija. Šalinant tam tikrus duomenis, gali būti prarasta naudinga informacija, netiesiogiai susijusi su šalinamais duomenimis (pvz., šalinant konkretų tiekėją, atsiranda pavojus prarasti informaciją apie gaminius, jei juos tiekė tik šis tiekėjas).

27. 1 NF anomalijų šalinimas Tokio tipo anomalijas galima panaikinti išskaidžius lentelę, t. y. išskyrus į atskiras lenteles sudėtinio rakto dalis ir nuo jų priklausančius laukus. Pavyzdžiui, lentelė TIEKIMAS (TIEKĖJO_NR(TN),GAMINIO_NR(GN), TIEKĖJO_PAVARDĖ(TP), DUOMENYS_APIE_TIEKĖJĄ(TD), TIEKIMO_KAINA(TK)). gali būti išskaidyta į tokias dvi lenteles: TIEKĖJAS(TIEKĖJO_NR, TIEKĖJO_PAVARDĖ, DUOMENYS_APIE_TIEKĖJĄ); TIEKIMAS(TIEKĖJO_NR, GAMINIO_NR, TIEKIMO_KAINA). kurios jau atitiks 2NF, o gal ir 3NF.

28. 2 NF Tegul lentelėje yra informacija apie projektavimo įstaigos darbuotojus, o lentelės schema atrodo taip: DARBUOTOJAI(DARBUOTOJO_NR(DN), DARBUOTOJO_ASM_KOD(DAK), ALGA(AL), PROJEKTO_NR(PN), BAIGIMO_DATA(BD)). Funkcinės priklausomybės tarp šios lentelės laukų: DN DAK, AL, PN DAK  DN, AL, PN PN  BD Lentelė DARBUOTOJAI, būdama 1NF, yra ir 2NF, nes jos abu galimi raktai (DN ir DAK) turi tik po vieną lauką. Tačiau ši lentelė nėra 3NF, nes jos neraktinis laukas BD tranzityviai priklauso nuo galimų raktų (tai aišku iš priklausomybių: DN  PN arba DAK    PN, PN    BD).

29. 3 NF 2NF lentelėms irgi būdingos įvedimo, atnaujinimo ir šalinimo anomalijos. Pavyzdžiui, negalima įvesti projekto baigimo datos tol, kol nepaskirti šio projekto vykdytojai (įvedimo anomalija). Projekto datos keitimas reikalauja visų turinčių šią datąįrašų - o jų gali būti labai daug - paieškos ir modifikavimo (atnaujinimo anomalija). Atleidus iš darbo visus kurio nors projekto vykdytojus, t.y. pašalinus šiuos darbuotojus atitinkančius įrašus, bus prarasta ir to projekto baigimo data (šalinimo anomalija). Šios anomalijos išnyksta, panaikinus lentelėje esančią tranzityvią funkcinę priklausomybę. Tai galima padaryti išskaidžius lentelęį atitinkamas atskiras lenteles. Pavyzdžiui, lentelę DARBUOTOJAI galima išskaidyti į tokias lenteles: DARBUOTOJAI(DARBUOTOJO_NR, PROJEKTO_NR, DARBUOTOJO_ASM_KOD, ALGA); PROJEKTAI(PROJEKTO_NR, BAIGIMO_DATA). Gautos lentelės DARBUOTOJAI ir PROJEKTAI yra trečiosios normalinės formos.

30. Išvada: • Normalizuojant DB, kitaip tariant, pervedant DB lenteles iš vienos normalinės formos į kitą, siekiama tokių esminių tikslų: • išvengti nepageidaujamų funkcinių priklausomybių tarp lentelių laukų; • kuo labiau sumažinti duomenų pertekliškumą; • supaprastinti duomenų apdorojimą.

31. Tipinis duomenų normalizavimo pavyzdys Tarkime, kad reikia sukurti DB, kurioje turi būti saugoma informacija apie studentų mokymosi rezultatus. Į DB pradinės lentelės sudėtį įtraukiami šie laukai: DISCIPLINOS_KODAS(DK), DISCIPLINOS_PAVADINIMAS(DP), KREDITŲ_SKAIČIUS(KS), EGZAMINO_ĮVERTINIMAS(EĮ), EGZAMINO_DATA(ED), EGZAMINATORIAUS_PAVARDĖ(EP) STUDENTO_BILIETO_NR(SB), STUDENTO_PAVARDĖ(SP), AKADEMINĖ_GRUPĖ(AG), FAKULTETAS(FA), GIMIMO_METAI(GM), GYVENAMOS_VIETOS_ADRESAS(GA), Šioje didelėje lentelėje norint surasti kurio nors studento laikyto egzamino įvertinimą,datą ir egzaminatoriaus pavardę, reiktų parinkti pirminį raktą, sudarytą iš dviejų laukų (SB+DK)

32. Tipinis duomenų normalizavimo pavyzdys (2) Pradinė DB lentelė aprašoma štai tokia schema: STUDIJOS(SB, SP, AG, FA, GM, GA, DK, DP, KS, EĮ, ED, EP). Funkcinės priklausomybės, egzistuojančios tarp lentelės (duomenų bazės) STUDIJOS laukų: SB+DK    EĮ, ED, EP SB    SP, AG, FA, GM, GA DK   DP, KS AG    FA Tai reiškia, kad turime 1NF lentelę.

33. Normalizavimas iki 2NF Lentelėje STUDIJOS yra laukų, iš dalies priklausančių nuo sudėtinio rakto SB+DK. SB+DK    EĮ, ED, EP Čia ED ir EP priklauso tik nuo DK Normalizavę, t. y. išskaidę iš dalies priklausančius laukus į atskiras lenteles, gausime šias lenteles: STUDENTAI(SB, SP, AG, FA, GM, GA); STUDIJOS(SB, DK, EĮ, ED, EP); DISCIPLINOS(DK, DP, KS). Dabar jau turime 2NF lenteles.

34. Normalizavimas iki 3NF Lentelėje STUDENTAI egzistuoja lauko FA tranzityvi priklausomybė nuo rakto SB. Jos galima išvengti sudarius dar vieną lentelę GRUPĖS(AG, FA) ir pašalinus lauką FA lentelėje STUDENTAI. Po šių pakeitimų turime 3NF lenteles: GRUPĖS(AG, FA); STUDENTAI(SB, SP, AG, GM, GA); STUDIJOS(SB, DK, EĮ, ED, EP); DISCIPLINOS(DK, DP, KS).

35. Dar vienas normalizavimo pavyzdys [3] a) KURSŲ_INFORMACIJA (pradinė nenormalizuota lentelė)

36. 1NF b) KURSŲ_INFORMACIJA (pirma normalinė forma)

37. KURSAI_MODULIAI Žingsnis link 2NF Ankstesnėje 1NF lentelėje pirminį raktą sudaro atributai ‘kursas’ ir ‘moduliai’. Atributai ‘m_pavadinimas’, ‘statusas’ ir ‘kreditai’ priklauso tik nuo rakto dalies ‘moduliai’, taigi, turime dalinę priklausomybę, kurios 2NF neturi būti. Tam skaidome lentelę į dvi. Bet lentelė KURSAI_MODULIAI dar nėra 2NF, nes ‘k_pavadinims’ ir ‘lygis’ priklauso nuo rakto dalies ‘kursas’. Taigi, šią lentelę reikia dar skaldyti. b) MODULIAI

38. c) MODULIAI 2 NF a) KURSAI_MODULIAI b) KURSAI

39. 3 NF c) MODULIAI a) KURSAI_MODULIAI b) KURSAI d) STATUSAS

40. Parengta pagal: • Parengta pagal R.Kuto paskaitų konspektus • J.Adomaitis ir kt. Informatika I dalis Vadovėlis, L-kla “Technolgija”, Kaunas, 1999, p.p. 161 – 173. • http://distance.ktu.lt/kursai/informatika1/8/ • A.Saulis, O.Vasilecas INFORMACINIŲ SISTEMŲ PAGRINDAI, mokomoji knyga, Technika, Vilnius, 1998, 82 – 98 p.p. Dar apie tai rasite: • R.Baronas. Duomenų bazių sistemos (Metodinė priemonė). Vilnius: TEV, 2002, 126 p. • ИНФОРМАТИКА базовый курс. Учебник для ВУЗОВ / СПб., Питер, 2001, c.c. 328-355. • Введение в системы баз данных. Дж. Д. Ульман, Дж. Уидом, М., “Лори”, 2000, 374 с. • http://www.citforum.ru/database/dbguide/index.shtml • http://www.citforum.ru/database/dblearn/index.shtml