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ų ppož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 dduomenimis. 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ė |

|  5515                     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 nnusakoma 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

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ų aatributų 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ę, jjog 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 rreikš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. PPadalijimas – 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.