- Turinys
- Reliacinis duomenų modelis ir sistemų evoliucija
- Reliacinis duomenų bazės modelis: pagrindinės sąvokos
- Reliacinės lentelės
- Lentelė 1
- Lentelė 2
- Lentelė 3
- Lentelė 4
- Tuščios reikšmės
- Raktai
- Išoriniai raktai
- Apribojančios sąlygos, palaikančios vientisumą
- Duomenų pertekliškumas
- Pertekliškumo problema reliacinėse duomenų bazėse
- Pertekliškumo problema tradicinėje failinėje sistemoje
- Paveikslėlis 1
Vilniaus Gedimino technikos universitetas
Verslo vadybos fakultetas
Referatas:
“Reliacinės duomenų bazės”
Reliacinis duomenų modelis ir sistemų evoliucija
Įvadas
Žmonių požiūris į duomenų bazes pamažu pradėjo keistis po 1970 m. E.F. Kodo
(Codd) publikacijos apie reliacinį modelį. Visi tuo momentu egzistavę priėjimai prie įrašų sujungimo iš skirtingų failų naudojo fizines rodykles arba adresus diske. Pavyzdžiui, tarkim, kad vienoje iš tų senų sistemų mums prireikė sujungti įrašą A su įrašu B. Tam mums reikės prie įrašo A
prijungti laukelį, kuriame bus patalpintas įrašo adresas diske. Tas pridėtinis laukelis, arba fizinė rodyklė, visada rodys iš įrašo A į įrašą
B. Kodas pademonstravo, kad tokios duomenų bazės apriboja mūsų galimybes manipuliuoti duomenimis. Be to, jos labai jautrios pakeitimams fizinėje aplinkoje. Kai į kompiuterinę sistemą buvo įdiegiamas naujas diskasukis arba keitėsi duomenų saugojimo adresai, buvo reikalingi ir papildomi failų pakeitimai. Jei prie įrašo formato faile buvo prijungiami nauji laukai, tai fiziniai adresai visų failų įrašų keitėsi. Tokiu būdu programuotojų ir vartotojų galimybės buvo labai apribotos dėl fizinių problemų ir nebuvo galima manipuliuoti duomenimis taip, kaip tai būtų leidusi loginė struktūra.
Reliacinis modelis, paremtas loginiu duomenų ryšiu, įveikė šias problemas.
Tai leido vartotojui visiškai nesirūpinti fizine duomenų struktūra.Be to,
Kodas įvedė dvi manipuliavimo duomenimis kalbas, kurios pasiūlė daug efektyvesnes priemones priėjimui prie duomenų ir jų apdorojimui. Tos kalbos
– tai reliacinė algebra ir reliaciniai skaičiavimai.
Reliacinis duomenų bazės modelis: pagrindinės sąvokos
Reliacinės lentelės
Reliacinis duomenų modelis apdoroja ir pateikia duomenis lentelių (arba reliacijų) pavidale.
Reliacija – tai terminas, atėjęs iš matematikos ir reiškiantis dvimatę lentelę, susidedančią iš duomenų eilučių ir stulpelių.
Žemiau yra pateiktas pavyzdys reliacinės duomenų bazės “lentelė 1”, kuria remdamasi aš apibūdinsiu pagrindines reliacinės duomenų bazės sąvokas.
Lentelė 1
|Darb-Nr |Pavardė |Specialybė|Vodovo-Nr |
|1235 |AAA |Elektrikas|1311 |
|1412 |BBB |Tinkuotoja|1520 |
| | |s | |
|2920 |CCC |Pakrovėjas| |
|2920 |DDD |Stalius | |
|1520 |EEE |Tinkuotoja| |
| | |s | |
|1311 |FFF |Elektrikas| |
|3001 |GGG |Stalius |3231 |
Lentelė 2
|Darb-Nr |Pastato-Nr|Darbo_Pradž|Dienų_skaičiu|
| | |ia |s |
|1235 |312 |10.10 |5 |
|1412 |312 |01.10 |10 |
|1235 |515 |17.10 |22 |
|1412 |460 |08.12 |18 |
|1412 |435 |15.10 |15 |
|1412 |515 |05.11 |8 |
|1311 |435 |08.10 |12 |
Lentelė 3
|Pastato-Nr Pastato_adresas |
|Tipas |
| 312 Klevų 10 |
| Ofisas |
| 435 Beržų 4 |
| Parduotuvė |
| 515 Liepų 3 |
| Gyvenamasis namas |
| 210 Eglių 2 |
| Ofisas |
| 111 Pušų 5 |
| Ofisas |
| 460 Gilių 8 |
| Sandėlys |
Lentelė 4
|Specialybės_tipas Premijiniai Val_per_savaitę |
|Tinkuotojas 30 Lt 35 |
|Elektrikas 35 Lt 37 |
|Pakrovėjas 50 Lt 40 |
|Stalius 45 Lt 35 |
Kiekvienas reliacijos stulpelis – tai reliacijos atributas. Stulpelio pavadinimas – atributo vardas. Toliau naudosime terminus atributas ir atributo vardas vietoj terminų stulpelis ir stulpelio pavadinimas.Mūsų pavyzdyje lentelės 1 atributų vardai: Darb-Nr, Pavardė, Specialybė, Vadovo-
Nr.
Reliacijos atributų skaičius vadinamas reliacijos laipsniu. Taigi, reliacijos laipsnis lentelės Darbuotojas lygus keturiems. Kadangi vartotojui nesvarbi atributų eilės tvarka reliacijoje, tai ta tvarka laikoma neesminė. Iš to seka, kad jokie du reliacijos atributai negali turėti vienodų vardų.
Reliacijos eilutės vadinamos kortežais. Laikoma, kad nėra nustatytos eilučių (kortežų) išdėstymo tvarkos, todėl jokie du kortežai negali turėti vienodų reikšmių rinkinių.
Rinkinys visų galimų reikšmių, kurias gali turėti atributai, vadinamas atributo sritimi. Dvi atributų sritys sutampa tik tuo atveju, jeigu jos turi tas pačias reikšmes. Pavyzdžiui, atributai Pavardė ir Specialybė iš lentelės 1 turi skirtingas atributų sritis, nors kiekvieno jų reikšmės yra simbolių eilutės. Du atributai su ta pačia sritimi nebūtinai turi turėti vienodus vardus. Pavyzdžiui, atributai Vadovo-Nr ir Darb-Nr turi tą pačią sritį, kurią sudaro numeriai, identifikuojantys darbuotojus.
Tuščios reikšmės
Tarkime, kad kažkokiu konkrečiu atveju atributas nepanaudojamas.
Pavyzdžiui, kai kurie darbininkai iš reliacinės lentelės 1 neturi vadovų.
Tokiu atveju, atributo Vadovo-Nr reikšmė jiems neegzistuoja. Be to, kai mes įvedinėjame duomenis į reliacinės lentelės eilutę, mes galime ir nežinoti vienos ar kelių tos eilutės atributų reikšmių. Abiem atvejais mes nieko neįvedinėjam ir eilutė į duomenų bazę įsirašo su tuščiomis tų atributų reikšmėmis. Tuščia reikšmė – tai ne tarpas ir ne nulis, ji paprasčiausiai nežinoma (ar atributas nepanaudojamas) ir gali būti įvesta vėliau.
Raktai
Lentelės 1 eilutėje patalpinta visa informacija apie konkretų tarnautoją.
Mes teigsime, kad kiekvienas tarnautojas pateiktas viena ir tik viena lentelės 1 eilute. Tokiu atveju, jei kuris nors atributas vienareikšmiškai nusako darbuotoją, mes galime teigti, kad tas pats atributas vienareikšmiškai nusako ir lentelės 1 eilutes. Teigsime, kad atributas Darb-
Nr vienareikšmiškai nusako kompanijos tarnautoją. Tada atributo reikšmė vienareikšmiškai nusako lentelės 1 eilutę, ir mes sakome, kad Darb-Nr yra lentelės 1 raktas.
Rinkinys atributų, vienareikšmiškai nusakantis kiekvieną reliacinės lentelės kortežą, vadinamas superraktu. Reliacijos raktas – tai minimalus atributų rinkinys; tai minimalus superraktas. Minimalumas suprantamas taip, kad nė vienas raktinių atributų aibės poaibis nenusako vienareikšmiškai reliacinės lentelės kortežų.
Pavyzdžiui, lentelėje 1 atributų rinkinio {Darb-Nr, Pavardė} reikšmės vienareikšmiškai nusako kiekvieną reliacijos kortežą – tai tos lentelės superraktas. Tačiau šis atributų rinkinys nėra minimalus, taigi, jis nėra ir raktas. Šitame pavyzdyje atskiras paimtas atributas Darb-Nr yra raktas, kadangi kiekviena lentelės eilutė vienareikšmiškai nusakoma atributo Darb-
Nr reikšme.
Abiejose iš duotų reliacinių lentelių gali būti daugiau nei vienas atributų rinkinys, kurį galime laikyti raktu.Šie atributų rinkiniai vadinami potencialiais raktais. Pavyzdžiui, Atributas Pavardė gali būti potencialiu lentelės 1 raktu. Tokiu atveju mes laikysime, kad pavardės niekada nesikartoja. Jeigu pavardės gali kartotis, tai Pavardė nėra potencialus raktas. Kai vienas iš potencialių raktų yra išrenkamas reliacijos raktu, jį galime pavadinti pirminiu raktu. Paprastai pirminiu raktu išrenkamas potencialus raktas, kuriuo lengviausia naudotis įvedinėjant duomenis.
Išoriniai raktai
Išorinis raktas – tai atributų rinkinys vienoje lentelėje, kuris yra raktas kitoje lentelėje. Taigi, atributas Pastato-Nr yra lentelės 2 išorinis raktas ir raktas lentelėje Pastatas. Išoriniai raktai sudaro svarbius ryšius tarp lentelių. Jie naudojami tam, kad surišti duomenis vienos lentelės su kitos lentelės duomenimis.
Išorinio rakto atributai nebūtinai turi turėti tuos pačius vardus kaip ir rakto atributai, kuriuos jie atitinka. Pavyzdžiui, Darb-Nr ir Vadovo-Nr lentelės Darbuotojas turi skirtingus vardus, nors abu juos sudaro reikšmės iš srities, kurioje yra darbuotojus identifikuojantys numeriai. Tokiu būdu,
Vadovo-Nr yra reliacinės lentelės 1 išorinis raktas, nurodantis į savo pačios lentelės raktą. Kiekvienam darbuotojui atributas Vadovo-Nr priskiria vadovą, kuris taip pat yra darbuotojas. Tokiu būdu, atributas Vadovo-Nr turi turėti reikšmę, kuri yra reikšmė rakto kažkokio kito kortežo iš lentelės 1. Vadovo-Nr yra pavyzdys rekursinio išorinio rakto, t.y. išorinio rakto, nurodančio į savo paties reliacinę lentelę.
Sąrašas, kuriame nurodomi reliacinių lentelių pavadinimai ir išvardinti jų atributai (raktai pabraukti) bei nurodyti išoriniai raktai, vadinamas reliacine duomenų bazės schema.
Pvz.: 1 (Darb-Nr, Pavardė, Specialybė, Vadovo-Nr)
Išoriniai raktai : Specialybė nurodo į lentelę Specialybė;
Vadovo-Nr. nurodo į lentelę Darbuotojas.
Apribojančios sąlygos, palaikančios vientisumą
Apribojanti sąlyga- tai taisyklė, nustatanti galimas reikšmes duomenų bazėje.
Apribojančios sąlygos suteikia loginį pagrindą teisingoms duomenų reikšmėms duomenų bazėje nustatymui, perspėja apie klaidas, pasitaikančias atnaujinant ir apdorojant duomenis. Tokios galimybės labai vertingos, kadangi pagrindinis duomenų bazės tikslas- teikti tikslią informaciją.
Reliaciniame Kodo modulyje yra keletas apribojančių sąlygų, naudojamų duomenų tikrinimui duomenų bazėje. Svarbiausios iš jų:
[pic] kategorijų vientisumas, [pic] nuorodų vientisumas, [pic] funkcinė priklausomybė
Kategorijų vientisumas. Reliacinės lentelės eilutės duomenų bazėje pateikia realaus pasaulio objektus (arba kategorijas). Pavyzdžiui, lentelės 1 eilutė pateikia konkretų tarnautoją, lentelės Pastatas eilutė pateikia konkretų pastatą, o lentelės Paskyrimas eilutė pateikia konkretų darbuotojo paskyrimą į konkretų pastatą. Reliacinės lentelės raktas vienareikšmiškai nustato kiekvieną eilutę, taigi, ir kiekvieną kategorijos elementą. Tokiu būdu, jeigu vartotojai nori manipuliuoti duomenimis iš konkrečios eilutės, jie turi žinoti tos eilutės rakto reikšmę. Todėl svarbu, kad elementas nebūtų įrašomas į duomenų bazę tol, kol nebus pilnutinai nustatytos jo raktinių atributų reikšmės.Taigi, raktas ar rakto dalis negali turėti tuščios reikšmės – tai ir yra kategorijų vientisumo taisyklė.
Nuorodų vientisumas. Norint sujungti vienos lentelės eilutes su eilutėmis iš kitos lentelės, naudojami išoriniai raktai. Pavyzdžiui, atributas
Specialybė naudojamas lentelėje 1 tam, kad praneštų mums kiekvieno darbuotojo specialybę, jog būtų galima apskaičiuoti premijinių dydį. Todėl labai svarbu, kad kiekvienos eilutės atributo Specialybė reikšmės būtų lygios tam tikroms raktinio atributo Specialybės-tipas reikšmėms lentelėje
4. Priešingu atveju, išorinis raktas Specialybė į nieką nenurodys. Iš čia ir seka nuorodų vientisumo taisyklė – kiekviena netuščia išorinio rakto reikšmė turi bųti lygi vienai iš raktinių reikšmių kitoje lentelėje.
Funkcinė priklausomybė. Funkcinės priklausomybės sąvoka naudojama normalizacijos procese. Ji suteikia reliaciniai schemai papildomų apribojimų. Pagrindinė jos idėja- vieno atributo reikšmė korteže vienareikšmiškai nusako kito atributo reikšmę korteže. Pavyzdžiui Darb-Nr vienareikšmiškai nusako pavardę.
Funkcinė priklausomybė užrašoma: Darb-Nr –> Pavardė.
Pažymėjimas ,,–> “ reiškia ,,funkcionaliai nusako “.
Formalesnės funkcinės priklausomybės apibrėžimas: jei A ir B lentelėje R, tai užrašas A –> B reiškia, kad jei du lentelės R kotežai turi vienodas atributo A reikšmes, tai jie turi turėti vienodas ir atributo B reikšmes.
Atributas, kuris ,,funkcionaliai nusako “ kito atributo reikšmė, vadinamas determinantu (tai atributai esantys kairėje funkcionalinės priklausomybės užrašo dalyle ir apsprendžiantys atributus, esančius to užrašo dešinėje pusėje) lentelės raktas- visuomet determinantas, nes jo reikšmė vienareikšmiškai nusako kiekvieno lentelės atributo reikšmę.
Duomenų pertekliškumas
Pertekliškumo problema reliacinėse duomenų bazėse
Duomenų pertekliškumas – duomenų pasikartojimas duomenų bazėje.
Panagrinėsime lentelę 5. Tarkim, jog ji buvo sudaryta ne iš koncepcinio modelio, bet buvo sukurta tiesiogiai iš turimos informacijos, gautos iš potencialių duomenų bazių vartotojų. Pažiūrėsime, kokios problemos gali iškilti dėl nerūpestingo duomenų bazės projektavimo ir kaip išvengti panašių problemų, naudojant standartinius principus, kurie vadinami normalizacija (reliacinės lentelės suvedimas į standartinę formą).
lentelė 5
|WORKER | | | | |
|WORKER-|NAME |SKILL-T|SUPV-I|BLDG-I|
|ID | |YPE |D |D |
|1235 |M. |Elektri|1311 |312 |
| |Faradėj|kas | | |
| |us | | | |
|1235 |M. |Elektri|1311 |515 |
| |Faradėj|kas | | |
| |us | | | |
|1412 |K. Nemo|Mūrinin| |312 |
| | |kas | | |
|1412 |K. Nemo|Mūrinin| |460 |
| | |kas | | |
|1412 |K. Nemo|Mūrinin| |435 |
| | |kas | | |
|1412 |K. Nemo|Mūrinin| |515 |
| | |kas | | |
|1311 |K. |Elektri| |435 |
| |Kolumbo|kas | | |
Truputi paanalizavus šią reliacinę lentelę aiškiai matosi, jog ji suprojektuota truputi nevykusiai. Pavyzdžiui keturiuose kortežuose, atstovaujančiuose darbininką 1412, kartojasi vienas ir tas pats vardas ir informacija apie specialybės tipą. Tai duomenų pertekliškumo problema (duomenų prieštaravimas duomenų bazėje) arba tiesiog duomenų pasikartojimas. Ši problema kompiuterio atmintyje sukelia papildomos vietos praradimus; ji gali sukelti duomenų vientisumo pažeidimus (prieštaravimas)
duomenų bazėje.
Problema kyla dėl to, kad vienas ir tas pats darbininkas gali dirbti daugiau nei viename pastate. Tarkim, jog K.Nemo specializacija buvo nurodyta neteisingai, o pataisymas buvo įvestas tik pirmajame korteže. Tada tarp kortežų, talpinančių informaciją apie K.Nemo iškyla prieštaravimas, kurį sukelia atnaujinimo anomalija (duomenų prieštaravimas iškilęs dėl duomenų pertekliškumo ir dalinio atnaujinimo).
Dabar tarkim, jog K.Nemo buvo tris mėnesius susirgęs ir visi pastatai į kuriuos jis buvo paskirtas, jau baigti. Jeigu priimamas sprendimas iš lentelės ištrinti visas eilutes turinčias duomenis apie baigtus pastatus, tai informacija apie identifikatorių K.Nemo, jo vardą ir specialybę bus prarasta. Tai vadinama pašalinimo anomalija (duomenų praradimas atsiradęs dėl kitų duomenų pašalinimo). Priešingas atvejis: mes galėjome pasamdyti naują darbininką pavarde Špandolfas, kurio dar nespėjome paskirti į kokį nors pastatą. Jei tuščios reikšmės yra draudžiamos, tai į duomenų bazę negalėsime įvesti jokios informacijos. Tai vadinama įvedimo anomalija (draudimas įvesti į lentelę duomenis dėl kitų duomenų nebuvimo).
Atnaujinimo anomalijos, pašalinimo ir įvedimo, savaime aišku yra nepageidaujamos. Kaip išvengti arba bent jau iki minimumo sumažinti panašias problemas? Intuityvus sprendimas būtų lentelę 5 suskaidyti į dvi lenteles 5 bei 6:
lentelė 6
|WORKER | | | |
|WORKER-ID|NAME |SKILL-TYP|SUPV-ID |
| | |E | |
|1235 |M.Faradėj|Elektrika|1311 |
| |us |s | |
|1412 |K.Nemo |Mūrininka| |
| | |s | |
|1311 |K.Kolumba|Elektrika| |
| |s |s | |
lentelė 7
|ASSIGNMENT | | | |
|WORKER-ID |BLDG-I|START-DATE |NUMBER-OF-D|
| |D | |AYS |
|1235 |312 |00 01 03 |20 |
|1235 |515 |99 11 16 |18 |
|1412 |312 |99 08 15 |35 |
|1412 |460 |99 07 20 |15 |
|1412 |435 |99 04 13 |14 |
|1412 |515 |99 03 08 |23 |
|1311 |435 |00 01 13 |7 |
Esant tokioms lentelėms anomalijos nekyla. Formalesnis metodas, vadinamas padalijimu, juo pasiekiamas toks pat rezultatas. Padalijimas – tai lentelės padalijimo į kelias lenteles, procesas, kurio tikslas išvengti anomalijų ir išlaikyti duomenų vientisumą. Tam, kad tai atlikti naudojamos normalinės formos arba lentelių struktūrizavimo taisyklės.
Pertekliškumo problema tradicinėje failinėje sistemoje
Pagrindinis sunkumas yra tame, kad dauguma programų naudoja savo nuosavus duomenų failus. Tokiu būdu kai kurie duomenų vienetai pasikartoja skirtingose moduliuose. Pavyzdžiui, viena ir ta pati banko kliento pavardė sutinkama failuose turinčiuose informaciją apie einamąsias sąskaitas, taupomąsias sąskaitas ir paskolas:
[pic]
Paveikslėlis 1
Nors tai vienas ir tas pats kliento vardas, atitinkami laukai skirtinguose failuose gali skirtingai vadintis. Taip laukas CNAME einamųjų sąskaitų faile pavirsta į SNAME taupomųjų sąskaitų faile ir į INAME paskolų faile.
Taip pat vienas ir tas pats laukas skirtinguose failuose gali turėti skirtingą ilgį. Pavyzdžiui, laukas CNAME gali turėti iki 20 simbolių, o laukas NAME ir INAME leidžia maksimalų 15 simbolių ilgį. Toks duomenų pertekliškumas sukelia papildomas problemas palaikant ir saugant duomenis.
Duomenų pertekliškumas taip pat sukelia prieštaravimo tarp skirtingų duomenų versijų grėsmę.
Tarkim, jog klientas Kerol T.Džons pakeitė pavardę į Kerol T.Smit ir po to paėmė iš banko paskolą. Paskolų faile senoji pavardė bus pakeista į naują, o likusiuose failuose informacija liks neatnaujinta. Praėjus tam tikram laiko tarpui, panašūs nesutapimai gali smarkiai sumažinti duomenų bazėje saugomos informacijos kokybę. Toks duomenų nesuderinamumas gali atsispindėti ataskaitų tikslume. Tarkim, jog norime sudaryti ataskaitą, kurioje turi būti išvardinti visi klientai, turintys einamąsias arba taupomąsias sąskaitas ir paėmę iš banko paskolas. Kerol T.Smit bus praleista šitoje ataskaitoje, kadangi paskolų faile yra įrašyta jos naujoji pavardė, o einamųjų bei taupomųjų sąskaitų failuose liko senoji.
Informacinės sistemos, naudojančios duomenų bazes, leidžia išvengti panašių duomenų pertekliškumo problemų. Jose visi moduliai naudoja vieną ir tą patį duomenų rinkinį. Tokia informacija, kaip pavyzdžiui kliento vardas arba adresas į duomenų bazę įrašomi tik vieną kartą. Tokiu būdu galime keisti kliento adresą arba vardą tik vieną kartą ir žinoti, jog visi moduliai naudos suderintus duomenis.