Reliacinės duomenų bazės

Vilniaus Gedimino technikos universitetas

Verslo vadybos fakultetas

Referatas:

“Reliacinės duomenų bazės”

TURINYS

TURINYS 2

RELIACINIS DUOMENŲ MODELIS IR SISTEMŲ EVOLIUCIJA 3

RELIACINIS DUOMENŲ BAZĖS MODELIS: PAGRINDINĖS SĄVOKOS 3

Reliacinės lentelės 3

lentelė 1 4

lentelė 2 4

lentelė 3 4

lentelė 4 5

Tuščios reikšmės 5

Raktai 6

Išoriniai raktai 6

Apribojančios sąlygos, palaikančios vientisumą 7

Duomenų pertekliškumas 8

Pertekliškumo problema reliacinėse duomenų bazėse 8

Pertekliškumo problema tradicinėje failinėje sistemoje 11

paveikslėlis 1 11

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 rrodykles
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 buuvo 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 va

artotojui 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 t

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.

Leave a Comment