Vilniaus universitetas Komunikacijos fakultetas Informacijos ir komunikacijos katedra
Andrius Jurgelevičius, Verslo informacijos vadybos programos studentas
DUOMENŲ BAZIŲ KŪRIMO TECHNOLOGIJA KURSINIS DARBAS
Vadovas doc. dr. P. Abarius
Vilnius, 2004 TURINYS
Įvadas 3 Duomenų bazės samprata 5 1. 1. Duomenų bazės sąvoka, pagrindinės funkcijos 5 1. 2. Duomenų bazių valdymo sistemos, jų funkcijos 6 2. Duomenų bazės projektavimas 8 2. 1. Duomenų bazės modelių tipai 8 2. 2. SQL kalba 9 2. 3. Reliacinis duomenų bazės modelis 11 2. 4. Reliacinė algebra 16 2. 5. Reliaciniai skaičiavimai 18 2. 6. Duomenų bazės normalizavimas, norminės formos 20 2. 7. Konceptualinis duomenų bazės modeliavimas 23 2. 8. Trijų lygių duomenų bazės architektūros projektavimas 25 3. Duomenų bazės kūrimas 29 3. 1. Duomenų bazės kūrimo žingsniai 29Išvados 32Bibliografinių nuorodų sąrašas 33
ĮVADAS
Teorija apie duomenų bazių struktūrą, jos valdymo sistemą, duomenų bazių praktinį pritaikymą įvairiausiose veiklos sferose yra ganėtinai jauna žinių sritis – ji gyvuoja šiek tiek daugiau nei 30 metų, tačiau po pirmųjų eksperementalių duomenų bazių atsiradimo 1950-aisiais metais industrinis pasaulis suprato jų svarbą. Mokslo sritis apie duomenų bazes pradėjo sparčiai vystytis. Šiandien be duomenų bazių sunku įsivaizduoti šiuolaikinį informacijos technologijų pasaulį. Jos naudojamos komercijos, valdžios, karinėse ir daugelyje kitų veiklos sferų, nuo aukščiausių valdžios instancijų iki didmeninės ir mažmeninės prekybos parduotuvių. Informacinės sistemos, naudojančios duomenų bazes, leido atsikratyti tokių problemų, kaip duomenų perteklius, silpna jų kontrolė, problematiškas priėjimas prie saugomos informacijos. Centralizuotose duomenų bazėse lengva realizuoti duomenų pakeitimus, sukurti ryšius tarp atskirų duomenų elementų. Duomenų bazių naudojimas organizacijai suteikė am tikrų privalumų:Visi duomenys surinkti vienoje integruotoje saugykloje, į kurią gali patogiai kreiptis įvairūs vartotojai;Išvengiama daugkartinio tų pačių duomenų įvedimo ir dubliavimo įvairiose programose;Didesnis saugumo laipsnis;Mažesnis perteklinių duomenų kiekis. Mano darbo tikslas – nustatyti duomenų bazių kūrimo technologijų ypatumus. Darbe bus išanalizuoti svarbiausi duomenų planavimo, projektavimo klausimai, duomenų bazių modeliavimo principai, duomenų bazių įdiegimo problematika. Taip pat dėmesys bus skirtas ir problemoms ir nesėkmėms, atsirandančioms kuriant ir naudojant duomenų bazes, o taip pat ir patarimai kaip efektyviausiai pašalinti kilusius keblumus. Duomenų bazės – tai nauja informacinių technologijų atšaka, sukurta einamiesiems duomenų saugojimo ir naudojimo uždaviniams spręsti. Kuriant vieningą duomenų bazę atsižvelgiama į organizacijos funkcinių sričių įvairovę, ji užtikrina vidinių ir išorinių ryšių palaikymą tarp įvairių funkcinės veiklos sričių. Šiuolaikinės organizacijos susiduria su žiauria konkurencija ne tik tarp savo šalies įmonių, bet ir tarptautiniu mastu. Todėl bet kurios organizacijoje naudojamos informacinės sistemos svarbiausias tikslas turėtų būti duomenų pavertimas informacija ir žiniomis, nes tik informacija ir žinios suteikia organizacijai konkurencinį pranašumą. Informacija ir žinios – tai organizacijos kompetencijos pagrindas, tai tie ištekliai, kurios organizacija naudoja gamindama aukštos kokybės prekes bei paslaugas ir kurių negali, arba beveik negali dubliuoti jokia kita konkurentinė organizacija. Kaupti duomenis ir iš jų gauti informaciją bei žinias stengiasi kiekviena organizacija. Būtent duomenų bazės leidžia sukaupti milžiniškus duomenų kiekius ir garantuoja lengvą priėjimą prie jų. Kaip sukurti duomenų bazę, kurią būtų galima sėkmingai įdiegti skirtingos paskirties organizacijose, kokios duomenų bazių projektavimo pasirinkimo galimybės, kaip pasirinkti tinkamus projektavimo etapus, šios ir kitos problemos, reikalaujančios gilesnio nagrinėjimo, bus analizuojamos mano darbe.
1. DUOMENŲ BAZĖS SAMPRATA
1. 1. Duomenų bazės sąvoka, pagrindinės funkcijos
Duomenų baze galima vadinti kartu saugomų ir tarpusavyje susijusių duomenų visumą, kuriems apdoroti pasitelkiamos programos. Duomenų bazė – tai duomenų hierarchijos aukščiausias lygmuo. Tai specialių būdu organizuotas integruotų duomenų visuos saugojimas, kuris vartotojui užtikrina patogią sąveiką ir greitą bei lengvą prieigą prie sukauptų duomenų. Kitaip tariant, duomenų bazė – tai ne kas kita, kaip dideli kompiuterio atminties įrenginiuose saugomi logiškai tarpusavyje susietų duomenų masyvų rinkiniai, iš kurių lengvai ir greitai iškviečiami bei pateikiami norimu pavidalu valdomi duomenys, panaudojant programinę įrangą. Kai kalbama apie visumą duomenų bazę sudarančių ir kartu veikiančių elementų, ji suvokiama kaip automatizuota sistema, kurią sudaro duomenys, programinė ir techninė įranga, papildomos priemonės, tokios, kaip kalbos priemonės, programavimo, duomenų aprašymo, užklausų priemonės, metodinės priemonės, pavyzdžiui, rekomendacijos ir instrukcijos apie duomenų bazės sukūrimą ir funkcionavimą, taipogi ir kiti personalo atstovai, kurių pagrindinė užduotis – duomenų bazės darbo kontrolė, ir visa užtikrina duomenų kaupimą, saugojimą, atnaujinimą, paiešką bei pateikimą vartotojui. Duomenų bazė – tai dinaminis objektas, kur saugomų duomenų reikšmės yra keičiamos, norint atspindėti realią tam tikros dalykinės srities padėtį. Duomenų bazė gali būti išdėstyta viename kompiuteryje, taip vadinama, vietinė duomenų bazė, arba paskirstyta keliuose, sujungtuose į tinklą kompiuteriuose – paskirstyta duomenų bazė. Vietinės duomenų bazės efektyviau išnaudojamos, kai dirba vienas ar keli vartotojai, kai jų veiksmus galima suderinti. Paskirstytų duomenų bazių paskirtis – pateikti lankstesnes, daugelio nutolusių ir išsimėčiusių geografiškai vartotojų aptarnavimo formas, kai dirbama su dideliais duomenų kiekiais. Paskirstytos duomenų bazės sistemos suteikia daugiau galimybių valdant sudėtingus objektus ar procesus, susidedančius iš daugelio grandžių, pavyzdžiui, organizacija, jungiančią tam tikrą filialų skaičių. Viena iš paskirstytų duomenų bazių valdymo priemonių – tai duomenų tiražavimas. Tai procesas, kurio metu pradinės duomenų bazės objektų pakeitimai perkeliami į pačią duomenų bazę, ar jos dalis, esančias skirtinguose paskirstytos sistemos mazguose. Paskirstytų sistemų darbo organizavimas numato vartotojo prieigos prie duomenų apribojimus, nes tokiose sistemose iškyla daugiau pavojų duomenų saugumui.
1. 2. Duomenų bazių valdymo sistemos, jų funkcijos
Kai duomenys saugomi kompiuterio atmintyje, veiksmus su jais galima atlikti tik naudojantis programine įranga. Programinė įranga, skirta darbui su duomenų baze ir pati duomenų bazė vadinama duomenų bazės sistema. Kai kalbama apie kompiuterines sistemas, duomenų bazės sistema suvokiama kaip sistema, kurią sudaro jos vartotojai, asmenys tiesiogiai naudojantys duomenų bazės teikiamomis paslaugomis, bei taikomosios programos, kurios atlieka operacijas su duomenų baze. Pagrindinė duomenų bazės programinės įrangos paskirtis – suteikti vartotojui galimybę naudotis duomenų baze, nesigilinant į technines detales, taip pat traktuoti duomenų bazę kaip aukštesnio lygio objektą nei įrašų failas [9, p. 7]. Tokia programinė įranga vadinama duomenų bazių valdymo sistema. Duomenų bazės valdymo sistema yra tarsi sąsaja tarp vartotojo ir duomenų bazės. Duomenų bazės valdymo sistema turi užtikrinti tikslų duomenų bazės veikimą, pašalinant atsiradusias kliūtis. Būna atvejų, kai duomenų bazėje atsiranda kelios duomenų kopijos, tai atsitinka nes kartais, norint panaudoti tuos pačius duomenis skirtingiems tikslams, prireikia juos dubliuoti. Šiuo atveju, toms kopijoms veltui eikvojama atmintis, prireikus modifikuoti duomenis, tenka kelis kartus naudoti tas pačias atnaujinimo proceso stadijas, o tai gali sukelti prieštaringos informacijos pateikimą. Todėl duomenų bazės valdymo sistema turi pasistengti atsikratyti atsiradusio duomenų dubliavimo, deja, dažniausiai visiškai užtikrinti duomenų nepertekliškumo tiesiog neįmanoma, šiuo atveju, duomenų perteklius yra minimizuojamas. Kita duomenų bazės valdymo sistemos užduotis – užtikrinti veiksmingą duomenų bazės naudojimą. Duomenų baze naudojasi didelis vartotojų skaičius, ne paslaptis, kad atvėrus duomenų failą redagavimui, operacinė sistema neleidžia kitiems vartotojams ne tik į jį rašyti, bet ir skaityti iš jo tol, kol rašymo operacija bus baigta ir failas bus uždarytas. Taigi, duomenų bazės valdymo sistemoje taikomas duomenų izoliavimo metodas – kai vienas duomenų bazės vartotojas keičia bet kurį joje saugomą įrašą, kiti vartotojai tuo pat metu gali peržvelgti ar keisti kitus įrašus.
Duomenų bazė galės vadintis vientisa tik tuo atveju, jei ji atitiks tam tikras duomenų saugojimo sąlygas ir sugebės išlaikyti tas sąlygas atliekant įvairius pakeitimo veiksmus su duomenimis. Tik taip centralizuotai saugomi duomenys atitinka realaus pasaulio tam tikros – skirtos automatizuoti – dalies taikymo srities modelį [13, p. 3]. Duomenų vientisumas – duomenų tikslumo ir neprieštaravimo vienų kitiems problema. Duomenų bazės valdymo sistemos užduotis – garantuoti duomenų bazės integralumą atliekant pakeitimus joje. Tam, kad užtikrinti duomenų vientisumą, dažniausiai yra naudojama slaptažodžių sistema bei duomenų dalijimas į atskiras dalis. Be to į duomenų žodynus įrašomos duomenų reikšmių sudėtis ir ribos. Duomenų bazės valdymo sistema privalo tikrinti, kad pakeitus duomenis duomenų bazėje nebūtų pažeistos nustatytos sąlygos, taip pat turi uždrausti ir įspėti vartotoją apie nesankcionuotą duomenų pakeitimą, kurį atlikus, nebus vykdoma kuri nors sąlyga. Kaip bebūtų, bet duomenų reikšmių sudėties apribojimas ir privalomi reikalavimai šiems duomenims yra silpnoji šiuolaikinių duomenų bazių valdymo sistemos dalis. Mes galime sugalvoti daug daugiau apribojimų negu juos gali realizuoti duomenų bazės valdymo sistemos. Todėl atsiranda būtinybė rašyti programas, kurios tikrintų, ar atitinka įvedami duomenys nustatytiems apribojimams. Rūpintis tokių programų rašymu turi būti pavesta duomenų bazės administratoriui. Ne mažiau svarbi duomenų bazės valdymo sistemos funkcija – duomenų nepriklausomumo užtikrinimas. Kitaip tariant, duomenų bazės valdymo sistema turi pasirūpinti tuo, kad taikomosios duomenų apdorojimo programos nesikeistų modifikuojant duomenų saugojimo i organizavimo būdą. Svarbu tai, kad įmanomas kiek fizinis, tiek ir loginis duomenų organizavimas. Šiuo atveju, fizinis duomenų organizavimas nurodo skirtingus duomenų fizinio išdėstymo būdus kompiuterio atmintyje, o loginis – duomenų struktūros vaizdavimą, reikalingą vartotojams. Organizacijos turimų duomenų sujungimo į vieningą, visiems prieinamą sistemą idėja turi tiek savo pranašumų, tiek trūkumų. Akivaizdus bendras duomenų bazės naudojimo privalumas rizikingas neteisingu duomenų bazės panaudojimu bei duomenų pakeitimu ar sugadinimu iš neatsakingų ir neturinčių įgaliojimų naudotis duomenų baze vartotojų pusės. Duomenų bazės administratorius ruošia duomenų bazės valdymo sistemos kontrolės priemones ir procedūras, kurios galės užkirsti galimybes neteisingai naudotis duomenimis, o be to, leis apibrėžti kiekvienam vartotojui ar jų grupei teises į duomenų vartojimą. Duomenų bazės valdymo sistema kontroliuoja priėjimo lygį bei fiksuoja duomenų panaudojimo arba papildymo statistiką. Duomenų bazės administratorius atsako už slaptažodžių bei nustatyto priėjimo lygio suteikimą. Tokiu būdu duomenų bazės administratorius sumažina galimybes ir riziką, kad viena vartotojų grupė gali sunaikinti kitos vartotojų grupės duomenis. Duomenų bazės valdymo sistema turi atlikti ir daug kitų svarbių funkcijų, tarp kurių gali išskirti tokias, kaip duomenų bazės struktūros aprašymas ir įdiegimas, duomenų bazės pildymas duomenimis ir redagavimas, navigacija duomenų bazėje, taikomųjų vartotojų programų ir ataskaitų kūrimas ir dar daugelį kitų, daugiau ar mažiau reikšmingų funkcijų.2. DUOMENŲ BAZĖS PROJEKTAVIMAS
2. 1. Duomenų bazių modelių tipai
Kaip vieną iš svarbiausių duomenų bazės valdymo sistemos funkcijų galima paminėti jos kaip savotiškos sąsajos tarp vartotojo ir duomenų bazės vaidmens atlikimas. Duomenų bazės valdymo sistema suteikia galimybę vartotojui kreiptis į duomenų bazę loginėmis sąvokomis, o ne fizinių veiksnių, tokių, kaip operacinė sistema ar bet kokia kita aparatūra, pagalba. Tų loginių sąvokų rinkinys sudaro duomenų bazės modelį. Duomenų modelis – tai ne kas kita kaip būdas struktūrizuoti duomenis. Svarbiausia loginio duomenų modelio paskirtis – sisteminti įvairiausių rūšių duomenis ir išryškinti jų savybes pagal tam tikrus požymius – dažniausiai pagal turinį, struktūrą, apimtį, ryšius ir dinamiką, be to, dėmesys turi būti skiriamas ir į tai, kad būtų tenkinami įvairių kategorijų vartotojų informaciniai poreikiai. Loginis duomenų modelis kuriamas etapais, kol galiusiai pasirenkamas optimalus variantas, žinoma, atsižvelgiant ir į ribojančius veiksnius. Loginio duomenų modelio kūrimo proceso metu, pirmiausia išaiškinami tam tikros dalykinės srities objektai, procesai, kurie gali būti reikalingi duomenų bazės vartotojui. Pavyzdžiui, tokiais objektais gali būti investoriai, indėlininkai, tiekėjai, pirkėjai, prekės ir pan. Šiuo atveju, kiekvienam objektui atrenkamas jį apibūdinančių savybių, tokių kaip rekvizitas, atributas ar laukas, rinkinys, pavyzdžiui, indėlininkui – pavardė, vardas, asmens kodas, adresas, indėlio tipas, indėlio suma ir kt. Svarstant, kokie duomenys turėtų sudaryti duomenų bazę, reikia atsižvelgti ne tik į dalykinę sritį, aptarnaujamų problemų ratą, bet ir į darbo su tam tikrais duomenimis intensyvumą, duomenų dinamiką, koregavimo dažnumą, duomenų tarpusavio ryšius bei sąveiką su kitais veiksniais. Praktiškai ne visi vartotojai gali būti suinteresuoti visu duomenų modeliu, o tik tam tikra jo dalimi. Kuriant loginį duomenų modelį, pasirenkamas vienas iš trijų modeliavimo būdų: hierarchinis, tinklinis arba reliacinis. Hierarchinio modelio struktūra yra medžio tipo, ji išreiškia vertikalius hierarchijos ryšius, t. y. žemesnieji lygiai pavaldūs aukščiau esantiems. Tinklinis modelis sudėtingesnis ir skiriasi nuo hierarchinio tuo, kad turi ir horizontalius ryšius, kurie gali būti ir nevienareikšmiai. Duomenys čia pateikiami orientuotais grafais. Reliacinės ir tinklinės duomenų sistemos yra ikireliacinių sistemų pavyzdys. Nors iki šiol tinklinės ir reliacinės sistemos veiksmingai naudojamos specifiniams uždaviniams spręsti, juos baigia išstumti reliacinės sistemos.
2. 2. SQL kalba
Sąsajai tarp vartotojo ir duomenų bazės sudaryti vartojama tam tikra formalioji kalba skirta užklausoms pateikti. Vienas pagrindinių užklausų kalbos dialektų, naudojamas daugelyje duomenų bazių, yra SQL. SQL – tai instrumentas, skirtas duomenų, esančių kompiuterinėje duomenų bazėje nuskaitymui ir apdorojimui. Kitaip tariant, SQL (Structured Query Language) – tai struktūrizuota užklausų kalba. SQL kalba buvo sukurta 1970 – ųjų metų pabaigoje IBM korporacijos tyrimų centre. SQL darbo schema pavaizduota 1 pav.
1 pav. SQL užklausų kalbos panaudojimas dirbant su duomenų baze [4].
SQL darbo esmė yra ta, kad vartotojas šios užklausų kalbos pagalba kreipiasi į duomenų bazės valdymo sistemą, kuri apdoroja užklausą, randa reikalingus duomenis ir galiausiai pateikia juos vartotojui. Kitaip ši procedūra vadinama duomenų bazės užklausa, iš čia ir kilęs ir pavadinimas – struktūrizuota užklausų kalba. Tačiau dabar SQL panaudojama ne tik užklausų sudarymui, taip pat ji naudojama visų funkcinių galimybių, kurias vartotojui suteikia duomenų bazės valdymo sistema, realizavimui, o būtent:Duomenų organizavimas, jo esmė yra ta, kad SQL suteikia vartotojui galimybę keisti duomenų pateikimo struktūrą ir nustatyti santykius tarp duomenų bazės elementų.Duomenų nuskaitymas. SQL suteikia vartotojui galimybę gauti duomenis esančius DB ir jais naudotis.Duomenų apdorojimas. SQL pagalba galima keisti duomenų bazės turinį, t.y. įvesti naujus duomenis, trinti nebereikalingus, atnaujinti senus.Priėjimo prie duomenų valdymas. SQL pagalba galima apsaugoti duomenis nuo nesankcionuoto vartojimo, apriboti vienų ar kitų vartotojų galimybes dirbant su duomenų baze.
Kolektyvinis darbas su duomenų baze. SQL suteikia galimybę keliems vartotojams vienu metu naudotis ta pačia duomenų baze netrukdant vienas kitam.Duomenų bazės apsauga. SQL padeda užtikrinti duomenų bazės vientisumą apsaugodama ją nuo sugriovimo dėl įvairių nesuderintų pakeitimų duomenų bazėje. Iš esmės SQL kalba vartojama reliacinėms operacijoms aprašyti. Šioje kalboje išskiriamos trys sakinių grupės: duomenų apibrėžimo sakiniai, kitaip dar vadinami duomenų apibrėžimo kalba DDL; duomenų apdorojimo sakiniai DML ir duomenų valdymo sakiniai DCL, taigi SQL = DDL+DML+DCL [9, p. 10]. Kaip bebūtu, reiktu pažymėti, kad SQL yra nepilnavertė kalba kaip pavyzdžiui COBOL, FORTRAN ar C++. Visų pirma, SQL neturi operatoriaus IF sąlygos patikrinimui; GOTO – perėjimų ir nuorodų organizavimui; DO arba FOR – ciklų sudarymui. SQL yra taip vadinama duomenų bazės pokalbe, kuri turi apie 30 operatorių skirtų valdyti duomenų bazę. SQL operatoriai įsiterpia į bazinę kalbą ir suteikia vartotojams galimybę naudotis duomenų baze. Nežiūrint į ne visai tikslų apibrėžimą, šiuo metu SQL yra vienintelė standartinė kalba skirta dirbti su reliacinėmis duomenų bazėmis. Pačios SQL negalima pavadinti nei duomenų bazės valdymo sistema, nei atskiru programiniu produktu. SQL yra neatsiejama duomenų bazės valdymo sistemos dalis, tai tarsi instrumentas, kurio pagalba realizuojamas vartotojo ryšys su duomenų bazės valdymo sistema. Vienų žodžių, pagrindiniai SQL apibrėžimai būtų šie – SQL tai:Interaktyvi užklausų kalba;Duomenų bazių programavimo kalba;Duomenų bazių administravimo kalba;Priedų klientas/serveris sudarymo kalba;Paskirstytų duomenų bazių kalba;Duomenų bazių šliuzas. Tokiu būdu, SQL tapo galingu instrumentu manipuliuojant reliacinėse duomenų bazėse esančia informaciją. Be to, SQL gali būti apibūdinta kaip lengvai suprantama ir universali programinė duomenų valdymo priemonė. SQL kalba turi daugybe privalumų, tarp jų galima išskirti tai, kad SQL nepriklauso nuo konkrečių duomenų bazės valdymo sistemų, ji yra standartizuota, gali būti perkelta iš vienų kompiuterinių sistemų į kitas, turi aukšto lygio struktūrą, suteikia galimybę dinamiškai keisti ir plėsti duomenų bazės struktūrą tuo pat metu naudojantis jos turiniu ir pan. Kaip jau buvo pažymėta anksčiau, SQL naudojama apie 30 operatorių. Kiekvienas jų “prašo” duomenų bazės valdymo sistemą atlikti tam tikrą užduotį, pavyzdžiui, sukurti lentelę, nuskaityti duomenis, įvesti į ją papildomų duomenų ir pan. Visi SQL operatoriai turi vienodą struktūrą. Kiekvienas SQL operatorius prasideda veiksmažodžiu, t.y. pagrindiniu žodžiu, kuris nusako atliekamą veiksmą (INSERT, DELETE, CREATE ir COMMIT). Po to eina vienas ar keli sakiniai, kurie nusako duomenis su kuriais dirba operatorius arba patikslina operatoriaus atliekamą veiksmą. Kiekvienas sakinys prasideda pagrindiniu žodžiu, pavyzdžiui, WHERE, FROM, INTO ir HAVING. Vieni sakiniai operatoriuje yra būtini, kiti – ne. Pabrėžtina, kad konkreti sakinio struktūra ir turinys gali keistis. Iš pagrindinių SQL operatorių galima išskirti šiuos: SELECT – nuskaito duomenis iš DB [4].SELECT [ALL | DISTINCT] {Atrenkamų objektų sąrašas | * } INTO Bazinių – kintamųjų – sąrašas FROM Nuorodų – į – lenteles – sąrašas [WHERE Paieškos – sąlyga] INSERT – įterpia duomenis į DB [4].
INSERT INTO lentelės pavadinimas [stulpelių – sąrašas] VALUES {(įterpiamų – elementų – sąrašas) | užklausos specifikacija} DELETE – trina duomenis iš DB [4].
DELETE FROM lentelė WHERE Paieškos – sąlyga UPDATE – atnaujina pasenusius DB duomenis [4].
UPDATE Lentelė SET Išraiškų – nuorodų – sąrašas WHERE Paieškos sąlyga Tarp kitų galima išskirti duomenų tvarkymo, priėjimo prie duomenų valdymo, transakcijų valdymo ir programinio SQL operatorius.
2. 3. Reliacinis duomenų bazės modelis
Reliacinį, kitaip dar vadinamą sąryšinį, modelį 1970 metais pasiūlė E. F. Kodas (Codd). Visi iki to momento egzistavę priėjimai prie įrašų sujungimo iš skirtingų failų naudojo fizines rodykles arba adresus diske. Pavyzdžiui, tarkime, 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 gi įrodė teoriškai ir praktiškai, kad toks duomenų bazės tipas žymiai apriboja vartotojų galimybes manipuliuoti duomenimis. Be to, tokios duomenų bazės labai jautriai reaguoja į pakeitimus fizinėje aplinkoje. Kai į kompiuterinę sistemą buvo įdiegiamas naujas diskasukis arba buvo keičiami duomenų saugojimo adresai, papildomai buvo reikalinga pakeisti tam tikrus failus. Jeigu prie įrašo formato faile buvo prijungiami nauji laukai, tai buvo neišvengiamas visų failų įrašų fizinių adresų keitimas. Šiuo atveju, programuotojų ir vartotojų galimybės buvo smarkiai apribotos susiduriant su fizinėmis problemomis ir nebuvo galima atlikti tam tikras operacijas su duomenimis taip, kaip tai būtų leidusi loginė struktūra. Būtent reliacinis duomenų bazės modelis, paremtas duomenų loginiu ryšiu, sugebėjo įveikti šias problemas. Tai leido vartotojui visiškai nesirūpinti duomenų fizine struktūra. Reliacinio modelio ašį sudaro lentelė. Matematikoje lentelę atitinka santykis. Santykis, šiuo atveju, išreiškiamas lentele, kurioje duomenys pateikiami dvimačiu masyvu, sudarytu iš horizontalių eilučių ir vertikalių stulpelių. Toliau reliacinis modelis bus nagrinėjamas remiantis pateikta supaprastinta reliacine duomenų baze „Statybinės firmos darbininkai“: Darbininkai
Darb. Nr. Pavardė Specialybė Vad. Nr. 0258 Markus Tinkuotojas 0123 0359 Šnepkus Stalius 0521 0270 Čėrkus Dažytojas 0889 0691 Lesnickas Suvirintojas 1254 0562 Vėlavičius Santechnikas 5670 0458 Andrijauskas Mūrininkas 3679
Paskyrimas
Darb. Nr. Pastato Nr. Darbo pr. Dienų sk. 0258 35 08. 30 14 0359 125 10. 25 5 0270 125 08. 00 7 0691 113 10. 30 5 0562 14 9. 25 20 0458 41 12. 00 14 0270 14 10. 00 14 0691 187 11. 30 10
Pastatas
Pastato Nr. Tipas Adresas 35 Parduotuvė Pilies 4 125 Gyvenamasis Vydūno 7 187 Gyvenamasis Žirmūnų 36 113 Ofisas Gedimino 10 14 Kotedžas Fabijoniškių 1A 41 Sandėlys Upės 12C
Specialybė
Tipas Užm. Per sav. Val. per sav. Tinkuotojas 125 Lt 35 Stalius 220 Lt 25 Dažytojas 100 Lt 22 Suvirintojas 200 Lt 20 Santechnikas 150 Lt 26 Mūrininkas 210 Lt 40
Šioje duomenų bazėje kiekvienas reliacijos stulpelis vadinamas reliacijos atributu. Atitinkamai, stulpelio pavadinimas atlieka atributo vardo funkciją. Toliau bus naudojami terminai atributas ir atributo vardas vietoj terminų stulpelis ir stulpelio pavadinimas. Mūsų pavyzdyje lentelės „Darbininkai“ atributų vardai yra šie: {Darb. Nr}, {Pavardė}, {Specialybė}, {Vad. Nr.}. Reikia pabrėžti, kad reliacijos atributų skaičius kitaip vadinamas reliacijos laipsniu. Taigi, lentelės „Darbininkai“ reliacijos laipsnis bus lygus keturiems. Kadangi duomenų bazės vartotojas nekreipia dėmesio į atributų eilės tvarką reliacijoje, tai ši tvarka laikoma neesminė. Iš to seka, kad bet kokia reliacijos atributų pora negali turėti vienodų vardų. Reliacijos eilutės vadinamos kortežais. Pabrėžiama, kad nėra nustatytos kortežų išdėstymo tvarkos, todėl jokie du kortežai negali turėti vienodų reikšmių rinkinių. Rinkinys visų galimų reikšmių, kurios gali būti priskirtos atributams, vadinamas atributo sritimi. Dvi atributų sritys gali sutapti tik tuo atveju, jeigu jos turi tas pačias reikšmes. Pavyzdžiui, atributai Pavardė ir Specialybė iš lentelės „Darbininkai“ 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 {Vad. Nr.} ir {Darb. Nr.} turi tą pačią sritį, į kurią įeina numeriai, kurie atlieka darbuotojų identifikacijos vaidmenį.
Visų leistinų atributo reikšmių aibė reliacijoje vadinama domenu. Tuščioji reikšmė (žymima NULL) priskiriama atributui eilėje, kai ano reikšmė nežinoma arba neturi prasmės. Tarkime, kad kažkokiu konkrečiu atveju atributas yra nepanaudojamas. Pavyzdžiui, kai kurie darbininkai iš lentelės „Darbininkai“ neturi vadovų. Tokiu atveju, atributo {Vad. Nr.} reikšmė jiems neegzistuoja. Be to, kai mes įvedinėjame duomenis į reliacijos eilutę, mes galime ir nežinoti vienos ar net kelių tos eilutės atributų reikšmių. Abiem atvejais mes nieko neįvedinėjam ir eilutė į duomenų bazę įvedama su tuščiomis tų atributų reikšmėmis. Tuščia reikšmė – tai ne tarpas ir ne nulis, šiuo atveju atributas nepanaudojamas, arba reikšmė paprasčiausiai šiuo metu nežinoma, ir gali būti įvesta vėliau. Lentelės „Darbininkai“ eilutėje patalpinta visa reikalinga informacija apie konkretų darbininką. Mes teigsime, kad kiekvienas tarnautojas pateiktas viena ir tik viena lentelės „Darbininkai“ eilute. Tokiu atveju, jeigu kuris nors atributas vienareikšmiškai apibrėžia kiekvieną darbuotoją, mes galime teigti, kad tas pats atributas vienareikšmiškai nusako ir lentelės „Darbininkai“ eilutę. Atkreipdami dėmesį į tai, teigsime, kad atributas {Darb. Nr.} vienareikšmiškai nusako įmonės darbuotoją. Iš to seka teiginys, jog atributo reikšmė vienareikšmiškai nusako lentelės „Darbininkai“ kortežą, o tai reiškia, kad atributas {Darb. Nr.} yra lentelės „Darbininkai“ raktas. Atributų rinkinys, vienareikšmiškai apibrėžiantis bet kurią lentelės kortežą, vadinamas viršrakčiu arba superraktu. Viršraktis tampa lentelės raktu, jeigu jis praranda savo universalumą, pašalinus iš jo bent vieną atributą. Reliacijos raktas – tai minimalus atributų rinkinys, tai minimalus superraktas. Minimalumas suprantamas taip, kad nė vienas raktinių atributų aibės poaibis vienareikšmiškai neapibrėžia reliacijos kortežų. Pavyzdžiui, lentelėje „Darbininkai“ atributų rinkinio {Darb. Nr., Pavardė} reikšmės vienareikšmiškai nusako kiekvieną reliacijos kortežą – tai tos lentelės viršraktis. Tačiau šis atributų rinkinys nėra minimalus, taigi, jis nėra ir raktas. Šitame pavyzdyje atskirai paimtas atributas {Darb. Nr.}yra raktas, kadangi kiekvienas reliacinės lentelės kortežas vienareikšmiškai apibrėžiamas atributo {Darb. Nr.} reikšme. Reliacinėje lentelėje „Paskyrimas“ raktas susideda iš atributų {Darb. Nr.} ir {Pastato Nr.} poros. Atskirai nė vienas iš šių atributų vienareikšmiškai nenusako kiekvienos eilutės, tačiau kartu šie atributai duoda vienareikšmišką nusakymą, kurio ir reikalaujama iš rakto. Raktas vadinamas sudėtiniu raktu jeigu jį sudaro du ar daugiau atributų. Kiekvienoje 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 „Darbininkai“ raktu. Tokiu atveju mes teigsime, kad pavardės niekada nesikartoja. Jeigu pavardės galės kartotis, tai atributas {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. Anksčiau pateiktame reliacinės duomenų bazės pavyzdyje skirtingose lentelėse kartais naudojami tie patys atributų vardai, pavyzdžiui, atributas {Pastato Nr.} lentelėse „Pastatas“ ir „Paskyrimas“. Šiam atributui suteikiama išorinio rakto sąvoką. Vienos lentelės atributų rinkinys, kuris tampa raktas kitoje lentelėje, vadinamas išoriniu raktu. Taigi, šiuo atveju, atributas {Pastato Nr.}, kuris atlieka rakto vaidmenį lentelėje „Pastatas“, tuo pat metu yra ir lentelės „Paskyrimas“ išorinis raktas. Išoriniai raktai sudaro svarbius ryšius tarp lentelių. Jų dėka, vienos lentelės duomenis surišami 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, lentelės „Darbininkai“ atributai {Darb. Nr.} ir {Vad. Nr.} turi skirtingus vardus, nors juos abu sudaro reikšmės iš srities, kurioje yra darbuotojus identifikuojantys numeriai. Taigi, {Vad. Nr.} tai ne kas kita kaip reliacinės lentelės „Darbininkai“ išorinis raktas, kuris nurodo į savo pačios lentelės raktą. Kiekvienam darbuotojui atributas {Vad. Nr.} priskiria atitinkantį vadovą, kuris taip pat yra darbuotojas. Tokiu būdu, atributas {Vad. Nr.} turi turėti reikšmę, kuri yra kažkokio kito lentelės „Darbininkai“ kortežo rakto reikšmė . Taigi ,{Vad. Nr.} yra rekursinio išorinio rakto , t.y. išorinio rakto, nurodančio į savo paties reliacinę lentelę pavyzdys. Kuriant reliacinę duomenų bazę turi būti laikomasi apribojančių sąlygų, kurios palaiko duomenų vientisumą. Šios apribojančios sąlygos suteikia teisingoms duomenų reikšmėms duomenų bazėje nustatymui loginį pagrindą, taip pat perspėja apie klaidas, pasitaikančias modifikuojant ir apdorojant duomenis. Tokios galimybės labai vertingos, kadangi pagrindinis duomenų bazės tikslas – suteikti vartotojui tikslią informaciją. Kodo suformuotame reliaciniame modulyje yra keletas apribojančių sąlygų, naudojamų duomenų bazėje sukauptų duomenų tikrinimui. Svarbiausios iš jų:Kategorijų vientisumas;Nuorodų vientisumas;Funkcinės priklausomybės. Reliacinės lentelės eilutės yra konkrečių realaus pasaulio objektų atitikmenys duomenų bazėje [8, p. 7]. Pavyzdžiui, lentelės „Darbininkai“ 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 apibrėžia kiekvieną kortežą, tuo pačiu, ir kiekvieną kategorijos elementą. Tokiu būdu, jeigu vartotojai nori manipuliuoti konkrečios eilutės duomenimis, jie turi žinoti tos eilutės rakto reikšmę. Todėl svarbu, kad elementas nebūtų įrašomas į duomenų bazę iki to momento, kol nebus pilnai nustatytos jo raktinių atributų reikšmės. Taigi, raktas ar rakto dalis negali turėti tuščios (NULL) reikšmės – tai ir yra kategorijų vientisumo taisyklė. Nuorodų gi vientisumas gali būti paaiškintas taip: norint sujungti vienos lentelės eilutes su eilutėmis iš kitos lentelės, naudojami išoriniai raktai. Pavyzdžiui, atributas {Specialybė} naudojamas lentelėje „Darbininkai“ tam, kad pateiktų vartotojui kiekvieno darbuotojo specialybę, jog būtų galima apskaičiuoti savaitės užmokesčio įmonėje dydį. Todėl reikia pabrėžti, kad kiekvienos eilutės atributo {Specialybė} reikšmės būtų lygios tam tikroms raktinio atributo {Tipas} reikšmėms lentelėje „Specialybė“. 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ės gi priklausomybės sąvoka naudojama normalizacijos procese. Ji suteikia reliaciniai schemai papildomų apribojimų. Jos pagrindinė idėja – vieno atributo reikšmė korteže vienareikšmiškai nusako kito atributo reikšmę eilutėje. Pavyzdžiui {Darb. Nr.} vienareikšmiškai nusako darbininko pavardę. Šiuo atveju, funkcinė priklausomybė užrašoma taip:{ Darb. Nr.} –> Pavardė. Pažymėjimas ,,–> “ reiškia ,,funkcionaliai nusako “.2. 4. Reliacinė algebra
Kodas įvedė dvi manipuliavimo duomenimis reliacinėje sistemoje kalbas, kurios pasiūlė daug efektyvesnes priemones priėjimui prie duomenų ir jų apdorojimui. Tos kalbos – tai reliacinė algebra ir reliaciniai skaičiavimai. Būtent šios kalbos ir buvo tas pagrindas, kuris sukėlė reliacinę revoliuciją duomenų bazėse. Kodd’as parodė, kad reliacinė algebra ir reliaciniai skaičiavimai logiškai ekvivalentus. Vienu žodžiu, bet kokią užklausą, kurią galima suformuluoti loginių skaičiavimų pagalba, taip pat galima suformuluoti naudojantis reliacine algebra ir atvirkščiai. Pirmiausia, panagrinėsime reliacinę algebra, ji gali būti apibūdinta kaip reliacinių lentelių apdorojimo procedūrinė kalba, kalba, kuri parodo visus uždavinio sprendimo kelius. Reliacinės algebros operacijos manipuliuoja reliacinėmis lentelėmis, kitaip tariant operacijos panaudoja vieną ar dvi turimas lenteles naujos lentelės sukūrimui. Gauta nauja lentelė gali būti panaudota naujose operacijose. Taip galima eksperimentuoti daliniais sprendimais kol galiausiai nebus pasiekta norimo rezultato. Reliacinę algebrą sudaro devyni elementai:Apjungimas;Susikirtimas;Skirtumas;Sandauga;Išrinkimas;Projekcijų sudarymas;Susijungimas;Dalinimas;Priskyrimas. Lengva pastebėti, kad pirmos keturios operacijos paimtos iš matematinės aibių teorijos ir praktiškai sutampa su aibių teorijos operacijomis, kitos gi operacijos, neskaitant devintos, skirtos tik reliacinio modelio duomenims apdoroti. Galiausiai, devinta operacija standartinė programavimo kalbos operacija, suteikianti dydžiui vardą. Toliau panagrinėsim atskiros operacijos funkciją. Apjungimo operacija (žymima È )leidžia kombinuoti duomenis iš dviejų lentelių, kitaip tariant, tai reliacinės algebros operacija, kuri apjungia dvi apjungimui suderintas reliacines lenteles, sudarydama teorinį aibių apjungimą. Reiktų pabrėžti, kad yra specialus reikalavimas skirtas apjungimo operacijai, kuris atskiria ją nuo paprasto aibių apjungimo matematikoje. Matematikoje galima apjungti bet kurias dvi aibes. Bet reliacinėje algebroje, prieš taikant apjungimo operaciją dviem reliacinėm lentelėm, reikia įsitikinti, kad jos turi tiksliai tuos pačius atributus. Tai reiškia, kad apjungti galima tik apjungimui suderintas lenteles – t. y. dvi ar daugiau reliacines lenteles, turinčias jų kiekio ir jų srities atžvilgiu ekvivalenčius stulpelius. Susikirtimo operacija sukuria dviejų apjungimui suderintų reliacinių lentelių susikirtimą. teorine aibių prasme(žymima ≤ ; C:=A≤B). Susikirtimo operacija leidžia mums identifikuoti eilutes, jungiančias abi lenteles, atlikę ją gausim naują lentelę į kurią įeis eilutės priklausančios abiem lentelėm. Skirtumo operacija sukuria dviejų apjungimui suderintų reliacinių lentelių teorinį aibių skirtumą. (žymima ,,-“). Skirtumo operacija leidžia mums identifikuoti tas eilutes, kurios yra vienoje lentelėje, bet kurių nėra kitoje. Sandaugos operacija atlieka dviejų reliacinių lentelių Dekarto sandaugą.(žymima ,,*“). Sandaugos operacija yra labai reikšminga kaip reliacinės algebros lentelių sujungimo operacijos sudedamoji, kuri (sujungimo operacija) yra viena svarbiausių reliacinėje algebroje. Taigi sandauga atliekama:1. Sujungus atributus abiejų lentelių. 2. Prijungus prie kiekvienos A lentelės eilutės kiekvieną B lentelės eilutę. Išrinkimo operacija – tai reliacinės algebros operacija atrenkanti iš lentelės eilutes pagal pateikta sąlygą. Išrinkimas naudojamas formavimui naujos reliacinės lentelės, į kurią įeina tik tos eilutės, kurios tenkina pateiktą sąlygą.(žymima: SELECT (lentelės pavadinimas: sąlyga)). Kaip sąlygą galim naudoti šias operacijas: = , <, >, <=, >=; taip pat ir logines operacijas: and, or, not. Projekcijų sudarymas – tai reliacinės algebros operacija, sudaranti naują lentelę atmetant stulpelius iš esamos lentelės. Projekcija – tai reliacinė lentelė, gauta projekcijos sudarymo rezultate. Jei išrinkimo operaciją galim įsivaizduoti kaip išbraukimą, atmetimą nereikalingų eilučių, tai projekcijų sudarymo operaciją kaip atmetimą nereikalingų stulpelių. Skirtingai nuo kitų RA-ros operacijų, ši operacija nereikalauja jokio specialaus simbolio ar raktinio žodžio. Tam, kad sudaryti projekciją tereikia nurodyti lentelės pavadinimą, o po jo laužtiniuose skliaustuose išvardinti stulpelius, kuriuos norėtume palikti [6]. Sujungimo operacija naudojama siekiant surišti duomenis tarp lentelių vienu iš kelių sujungimo būdų, kurie yra vykdomi keliais etapais. Dalinimas tai reliacinės algebros operacija, kuri sudaro naują lentelę, išrenkant eilutes vieno lentelės, atitinkančias kiekvienai eilutei kitos lentelės. Galiausiai, paskutinė, priskyrimo operacija atlieka vardo suteikimo lentelei funkcija (žymima „=“).
2. 5. Reliaciniai skaičiavimai
Reliaciniai skaičiavimai gali būti paaiškinami kaip neprocedūrinė kalba, skirta užklausų sudarymui reliacinėse duomenų bazėse. Reliacinių skaičiavimų pavadinimas atsiranda iš predikatų skaičiavimų loginėje matematikoje. Reliaciniuose skaičiavimuose naudojamos bulio operacijos (ir, arba, ne), egzistavimo ir apibendrinantys kvantorai, atitinkamai reiškiantys tai, kad tam tikro tipo elementas egzistuoja arba sąlyga teisinga kiekvienam tam tikro tipo elementui [7]. Norint suprasti reliacinių skaičiavimų esmę reikia panagrinėti užklausos pavyzdį. Sudarykime užklausą: kas iš informacijos vadybininkų dirba Vilniuje? Reliaciniuose skaičiavimuose ši užklausa realizuojama sekančiai:{ r.VADYB_PAVARDĖ : r IN VADYBININKAS and r.OFISAS = „Vilnius“ }. Čia pateiktas sprendimas iliustruoja beveik visus elementus reliacinių skaičiavimų elementus. Panagrinėsime realizavimo struktūrą. Pirmoji dalis iki dvitaškio yra tikslinis sąrašas, likusi gi dalis yra apibendrinta išraiška. Išskirstysime sprendimą dalimis ir paaiškinsime: 1. Figūriniai skliausteliai ( {} ), kuriuose pateikta išraiška, reiškia, kad užklausos rezultatas bus kažkokia aibė. O kas būtent įeina į tą aibę, vaizduoja išraiška skliausteliuose. 2. r – tai kintamasis, kuris aprašo kiekvieną eilutę. Lentelė, iš kurios imamas r, vaizduojama išraiška „r IN VADYBININKAS“, kuri reiškia lentelės VADYBININKAS r eilutę. 3. r.VADYB_PAVARDĖ – atributo VADYB_PAVARDĖ reikšmė eilutėje r. 4. Dvitaškio ( : ) paskirtis – atskirti tikslinį sąrašą ir sąlygas. Tikslinis sąrašas šiuo atveju yra r.VADYB_PAVARDĖ, o apsprendžianti išraiška r IN VADYBININKAS ir r.OFISAS = „Vilnius“. Dvitaškį galima suprasti kaip “toks, kad”. 5. r.OFISAS = „Vilnius“ reiškia, kad atributo OFISAS reikšmė eilutėje r lygi „Vilnius“. Reliaciniuose skaičiavimuose didelę svarbą turi tikslinis sąrašas ir apsprendžiančios išraiškos. Tikslinis sąrašas nusako atributus sprendimo lentelėje, o apsprendžiančios išraiškos – tai sąlygos, apribojančios elementų patekimo pavidalą, kitaip tariant, atrenka elementus iš duomenų bazės į sprendimo lentelę.Kiekvienos užklausos sprendimas yra reliacinė lentelė, kuri yra užduodama tiksliniu sąrašu ir tam tikra sąlyga. Tikslinis sąrašas sąlygoja sprendimų lentelės atributus. Ankščiau pateiktame pavyzdyje tiksliniu sąrašu buvo r.VADYB_PAVARDĖ kas reiškia, kad sprendimų lentelė turi tik vieną atributą, t.y. informacijos vadybininko pavardę. Reikšmės, įeinančios į sprendimų lentelę, paimtos iš tų eilučių, kurios tenkina sąlygą. Pateiktame pavyzdyje vadybininko pavardė buvo paimta iš eilutės r ir įrašyta į sprendimo lentelę, jei eilutė r tenkina sąlygą r IN VADYBININKAS AND r.OFISAS = „Vilnius“. Sistema peržiūri visas lentelės VADYBININKAS eilutes. Pirmai eilutei laikinai priskiriamas vardas r ir tikrinama ar sąlyga tenkinama. Šiuo atveju, kadangi r.OFISAS = „Vilnius“, sąlyga tenkinama, todėl r.VADYB_PAVARDĖ (Ivanauskas) įrašoma į sprendimų lentelę. Vėliau sistema pereina į kitą eilutę, jai priskiria vardą r ir vėl tikrina sąlygą. Kai sąlyga yra netenkinama, išraiška neteisinga, todėl tos eilutės „atstovas“ neįrašomas į sprendimų lentelę. Procesas kartojamas kiekvienai lentelės VADYBININKAS eilutei, kol galiausiai proceso rezultatai pateikiami lentelės pavidalu. Daugumai užklausų tikslinis sąrašas susidės iš vieno atributo. Vis dėlto, tikslinis sąrašas gali susidaryti ir iš kelių atributų, tereikia išvardinti visus atributus, atskiriant juos kableliais: {r.VADYBININKO_ID, r.VADYB_PAVARDĖ, r.MENEDŽERIO_ID, r.OFISAS :r IN VADYBININKAS AND r.OFISAS = “Vilnius” } ir pan.
Pateiktų paaiškinimai leidžia suprasti, kaip išrinkimo operacijos ir reliacinės algebros projektavimas palaikomi reliaciniuose skaičiavimuose. Apjungimo, susikirtimo, skirtumo ir sandaugos operacijas taip pat galima pateikti reliacinių skaičiavimų konstrukcijomis. Kadangi skaičiavimuose nenaudojamos algebros žingsninės procedūros, tai priskyrimo operacija nereikalinga. Tokiu būdu, liko dvi Reliacinės algebros operacijos – tai sujungimo ir dalinimo operacijos. Šioms operacijoms atlikti būtina pasitelkti kvantorais. Šiuo atveju egzistavimo kvantoras bus reikalingas sujungimo operacijai atlikti, o apibendrinantis kvantoras – dalinimui . Taigi, pradėsim nuo egzistavimo kvantoro. Pagal savo apibūdinimą, kvantoras reiškia kokį nors kažkokio dalyko kiekį. Egzistavimo gi kvantoras – tai reliacinių skaičiavimų išraiška, kuri reiškia bent vienos eilutės, tenkinančios duotą sąlygą, egzistavimą. Reliaciniuose skaičiavimuose egzistavimo kvantoras naudojamas užduoti sąlygą, kad apibrėžto tipo eilutė lentelėje egzistuoja. Vienu žodžių, panagrinėsime egzistavimo kvantoro funkcijas, atsižvelgiant į konkretų atvejį. Taigi, sudarykime užklausa: išvardinti vardus vartotojų, pasinaudojusių paslauga 0618? Kaip ir anksčiau nagrinėtose operacijose, šio uždavinio sprendinys bus lentelė, kurioje bus kai kurių vartotojų vardai. Šią lentelę, sudarys vienas stulpelis, nes tikslinis sąrašas r.VART_VARDAS sudarytas iš vieno atributo, kur r – tai eilutė iš lentelės VARTOTOJAS. Taigi, mes sudarėme tikslinį sąrašą, tačiau dar neatkreipėm dėmesio į apsprendžiančią išraišką? Kad vartotojas pakliūtų į sprendimų lentelę, jis turi atitikti duotą sąlygą, t.y. vartotojas naudojosi paslauga 0618. Kitaip tariant, jei kliento ID sutinkamas tam tikroje lentelės PASLAUGOS eilutėje su PASLAUGOS_ID = 0618, tai tas klientas bus įtrauktas į spendimų lentelę. Tokiu būdu, gauname sąlyga: lentelėje PASLAUGOS egzistuoja bent viena eilutė, turinti vartotojo ID ir PASL_ID =0618. Taigi galiausiai reliaciniuose skaičiavimuose gaunama sąlyga: ( s.VARTOTOJO_ID = r.VARTOTOJO_ID and s.PASLAUGOS_ID = 0618 ). Tokia išraiška skaitoma: „lentelėje PASLAUGOS egzistuoja eilutė s tokia, kad „s.VARTOTOJO_ID = r.VARTOTOJO_ID ir s.PASLAUGOS_ID =0618“. Pabrėžtina, kad ta išraiška apibrėžia eilutę r. Jei išraiška teisinga, t.y. eilutei r egzistuoja tokia eilutė s, tai r.VART_VARDAS įterpiamas į sprendimo lentelę, ir atvirkščiai, jei išraiška klaidinga, t.y. tokia eilutė s neegzistuoja – tai r.VART_VARDAS neįrašomas į sprendimo lentelę. Galutinis sprendimas reliaciniuose skaičiavimuose atrodys taip: (r.VARTOTOJO_VARDAS : IN VARTOTOJAS and exists s IN PARDAVIMAS s.VARTOTOJO_ID = r.VARTOTOJO_ID and s.PASLAUGOS_ID = 0618). Apibendrinantis gi kvantoras reiškia, kad kažkokia sąlyga taikytina kiekvienai tam tikro tipo eilutei. Jis yra reliacinės algebros dalinimo operacijos atitikmuo. Taigi sudarykime užklausą: kuris pardavėjas pardavė kiekvieną automobilį? Ši užklausa yra sudėtingesnė, nes reikalauja dviejų sujungimų, čia atsižvelgiama ir į klientus pirkusius automobilį pas atitinkamą pardavėją. Sprendimas atrodys sekančiai: ( r.KLIENT_VARDAS : r IN KLIENTAS and there exists p IN AUTOMOBILIAI exists s IN PARDAVIMAS); ( r.PARDAV_ID = s. PARDAV_ID and s. AUTOMOBILIO_ID = p. AUTOMOBILIO_ID ). Sprendinio rezultatas bus lentelė, į kurią bus įrašytas pardavėjo vardas. Pardavėjo vardas iš eilutės r lentelės PARADAVIMAS įrašomas į sprendimo lentelę, jeigu sąlyga teisinga eilutei r. Kiekvienai lentelės AUTOMOBILIS eilutei p turi egzistuoti eilutė s lentelėje PARDAVIMAS, tenkinanti sąlygą. Kiekvienoje iš eilučių lentelėje PARDAVIMAS, PARDAVĖJO_ID priklauso kažkokiam pardavėjui ir kiekviena pardavimo eilučių atitinka vieną iš keturių galimų prekių. Taigi, tas pardavėjas ir bus pardavęs kiekvieną prekę.2. 6. Duomenų bazės normalizavimas, norminės formos
Duomenų bazės normalizaciją galima apibūdinti kaip įvairių taisyklių taikymą, siekiant supaprastinti sąryšius. Ji padeda suvesti reliacines lenteles iki standartinio pavidalo, taip pat padeda išvengti problemų, kurios atsiranda dėl neteisingo duomenų bazės projektavimo, o būtent duomenų perteklių, duomenų vientisumo užtikrinimas, duomenų atnaujinimo, pašalinimo ir įvedimo anomalijas. Norint suprasti kylančias duomenų bazės kūrimo procese problemas reikia išnagrinėti konkretų pavyzdį. Tegul turime atvejį, kai reliacinis duomenų bazės modelis buvo sukurtas ne koncepcinio modelio pagalba, o informacijos, tiesiogiai gautos iš potencialių vartotojų, pagrindu. Reliacinė lentelė „Priskirtas darbuotojas“ atrodys taip: „Priskirtas darbuotojas“
ID-Darbuotojo Pavardė Specialybė ID-Vadovo ID-Pastato Data Alga 1010 A.Ivanauskas Suvirintojas 512 14 04. 15 650 1010 A.Ivanauskas Suvirintojas 236 25 03. 17 650 1581 M. Žukauskas Dažytojas 512 14 05. 25 600 1581 M. Žukauskas Dažytojas 457 58 06. 21 600 1581 M. Žukauskas Dažytojas 218 69 07. 11 600 1581 M. Žukauskas Dažytojas 123 12 03. 14 600 1471 J. Sakalauskas Santechnikas 218 69 04. 21 700
Akivaizdu, kad reliacinė lentelė suprojektuota nesėkmingai. Keturiuose kortežuose, atitinkančiuose darbuotojui kurio numeris 1581, kartojasi ta pati pavardė, bei specialybė. Šiuo atveju, duomenų perteklius atsirado dėl to, kad vienas darbininkas paskirtas darbui keliuose pastatuose. Duomenų perteklius sunaudoja laisvą vietą, ir gali sukelti ir duomenų vientisumo pažeidimus. Pavyzdžiui, Žukausko specialybė būtų įvesta neteisingai ir ištaisyta tik pirmame korteže, tada tarp kortežų, turinčių informaciją apie Žukauską atsirastų neatitikimas – atnaujinimo anomalija. Sekanti problema, su kuria įmanoma susidurti tai pašalinimo anomaliją. Pavyzdžiui, pastate, kuriame dirba Ivanauskas pasibaigė darbai ir iš lentelės norima pašalinti visas eilutes turinčias informaciją apie užbaigtą pastatą, bet tada informacija apie Ivanausko ID, pavardę ir specialybę bus prarasta. Jeigu norime įvesti naują darbuotoją (pvz. Aleksandravičių, kuriam dar nespėjome paskirti pastatą, ir tuščios reikšmės neliestinos, tai informaciją apie Aleksandravičių įvesti negalėsim, tai sukels įvedimo anomaliją. Norint išvengti anomalijų ir užtikrinti duomenų vientisumą, lentelė „Priskirtas darbuotojas“ turi būti išskaidyta. Šiam tikslui naudojamos norminės formos. Normine forma vadinamos sąlygos, kurias turi tenkinti duomenų bazės reliacinė schema, kad duomenų bazė išvengtų tam tikrų nepageidaujamų savybių. Lentelė yra pirmos norminės formos, jei visų jos atributų reikšmės yra atomai. Atomu laikoma reikšmė, kuri nėra nei aibė, nei sąrašas [9, p 37]. Pirmiausia panagrinėsim pirmąją norminę formą, norint aiškiau suprasti jos esme panagrinėkime lentelę, kuri neatitinka pirmąją norminę formą, tegul tai būna lentelė „Darbuotojas“. Pagal Kodd‘o reliacinės lentelės apibrėžimą, reliacinė lentelė turi tenkinti pirmąją norminę formą. „Darbuotojas“
ID-Darbuotojo Pavardė Specialybė ID-Vadovo ID-Pastato 1010 A.Ivanauskas Suvirintojas 512 14, 126, 24 1581 M. Žukauskas Dažytojas 514 14, 450, 158
ID-Pastato reikšmės nėra atominės, t.y. vienam kortežui ID-Pastato gali turėti kelias reikšmes. Pagal Kodd‘o apibrėžimą lentelė „Darbuotojas“ nėra reliacinė lentelė. Bet lentelė „Priskirtas darbuotojas“ tenkina pirmąją norminę formą, nes mums ID-Pastato reikšmė gali būti laisvai išrinkta nuorodos į atributo ID-Pastato vardą pagalba. Antra ir trečia norminės formos yra apribotos funkcinėmis priklausomybėmis, t. y. kai vieno atributo reikšmė korteže vienareikšmiškai apibrėžia kito atributo reikšmę. ir liečia sąryšius tarp raktinių ir neraktinių atributų [5]. Antra norminę formą apibrėžia, kad kiekvienas neraktinis atributas yra funkcionaliai priklausomas nuo visu raktinių atributų, kitaip tariant, nuo pilno rakto, vienu žodžiu, jis negali būti priklausomas tik nuo vieno iš raktinių atributų. Lentelė „Priskirtas darbuotojas“ turi sudėtinį raktą {ID-Darbuotojo, ID- Pastato}. Atributo {Pavardė} reikšmę vienareikšmiškai apibrėžia atributas {ID-Darbuotojo}, taigi ir funkcionaliai priklauso nuo rakto dalies, o tai sąlygoja antros norminės formos netenkinimą, todėl yra tikimybė, kad gali atsirasti anksčiau minėtos duomenų bazės kūrimo procese atsirandančios problemos. Tam, kad lentelę tenkintų antrąją norminę formą, būtina išskaidyti ją į dvi lenteles. Svarbu paminėti išskaidymo etapus: Pirmiausia reikia sukurti naują lentelę, kurios atributai yra pradinės lentelės atributai, netenkinantys funkcinės priklausomybės sąlygos, tada funkcinės priklausomybės determinantas tampa naujos lentelės raktu. Sekantis žingsnis – Atributo, esančio dešinėje funkcinės priklausomybės pusėje, išbraukimas iš pradinės lentelės. Šie du žingsniai kartojami jeigu yra daugiau funkcinių priklausomybių, kurios pažeidžia antrą norminę formą. Ir galiausiai, jeigu vienas determinantas įeina į kelias funkcines priklausomybes, tai visi nuo jo funkcionaliai priklausantys atributai talpinami kaip neraktiniai atributai į lentelę, kurios raktu bus determinantas.
Trečios norminės formos, kitaip dar Bois‘o – Kodd‘o norminės formos esmė – kiekvienas determinantas yra raktas. Paimkim lentelę „Darbuotojas“, čia funkcinės priklausomybės atrodys taip: ID-Darbuotojo ® Pavardė ID-Darbuotojo ® Specialybė ID-Darbuotojo ® ID-Menedžerio ID-Darbuotojo ® Alga Tačiau reikia paminėti funkcinę priklausomybę Specialybė ® Alga, kuri netenkina trečiąją norminę formą, nes Specialybė yra determinantas, bet nėra raktas. Kad išvengti panašių problemų kaip ir antroje norminėje formoje vėl išskaidysim lentelę, atliekant tokius pat išskaidymo žingsnius kaip ir suvedimo iki antros norminės formos atveju. Gausime sekančią lentelę „Priskirtas“, kur {ID-Darbuotojo, ID-Pastato, Data}, čia išorinis raktas: ID-Darbuotojo kreipiasi į lentelę Darbuotojas Čia lentelė A {ID-Darbuotojo, Pavardė, Specialybė, ID-Menedžerio} Išorinis raktas: Specialybė kreipiasi į lentelę B Čia lentelė B {Specialybė, Alga} Šios lentelės tenkina trečiąją norminę formą. Pagal apibrėžimą, jeigu lentelė tenkina trečiąją norminę formą, tai ji tenkina antrąją norminę formą bei pirmąją norminę formą. (Atvirkščias teiginys negalioja). Todėl, tam kad suvesti lentelę iki antros norminės formos ir trečios norminės formos užtenka pasinaudoti trečios norminės formos kriterijumi. Pateikta trečios norminės formos versija vadinama Bois‘o – Kodd‘o normaline forma. Yra ir kitas trečios norminės formos kriterijus, bet jis logiškai yra silpnesni. Šis kriterijus teigia, kad lentelė tenkina trečiąją norminę formą, jeigu ji neturi tranzityvinių priklausomybių, kai neraktinis atributas funkcionaliai priklauso nuo vieno ar daugiau neraktinių atributų [5]. Ketvirtos norminės formos esmė – kai lentelė tenkina trečią norminę formą ir neturi daugiareikšmių priklausomybių, tai galima pasiekti jeigu kiekvieną daugiareikšmį atributą kartu su raktu, nuo kurio jis priklauso, patalpinti į atskirą lentelę. Yra dar ir penktoji norma, ji buvo sukurta tam, kad išvengti bendrų priklausomybių. Bendros priklausomybės turi teorinę prasmę ir abejotiną praktinę vertę. Todėl penkta norminė forma iš tikrųjų neturi praktinio panaudojimo, todėl ir neturi didelės reikšmės duomenų bazės kūrimo procese.2. 7. Konceptualus duomenų bazės modeliavimas
Duomenų bazės projektavimo procesas neapsieina be modeliavimo sferos. Duomenų bazės loginė schema – tai visos informacinės sistemos pagrindas. Taigi, projektuojant duomenų bazes reikia tiksliai aprašyti dalykinę sritį. Formalizuotas dalykinės srities aprašas, kuris suprantamas visiems asmenims, tiesiogiai susijusiems su duomenų bazės projektavimo procesu, vadinamas konceptualinių, kitaip dar semantiniu, modeliu. Du pagrindiniai duomenų modelių kūrimo tikslai: padėti suprasti duomenų prasmę; padėti komunikaciją apie informacijos reikalavimus.Duomenų modelis palengvina duomenų prasmės suvokimą. Todėl duomenys modeliuojami, siekiant užtikrinti, kad suvokiama:kiekvieno vartotojo duomenų perspektyva;duomenų natūralioji prigimtis, nepriklausoma nuo jų fizinių reprezentacijos priemonių;duomenų naudojimas konkrečiuose veiksmuose.Konceptualinio projektavimo etapą sudaro konceptualinės duomenų bazės schema. Specifikacijos kuriamos tame lygyje, kuris reikalauja perėjimo prie realizacijos. Šiame etape sukuriami smulkūs vartotojiškų duomenų pateikimo modeliai, fiksuojantys visus elementus bendrųjų duomenų, kurie bus duomenų bazėje. Vienas populiariausių konceptualinių modelių yra 1976 m. P. Čeno pasiūlytas esybių ryšių modelis. Jis gali būti suvokiamas kaip fiziškai egzistuojančių ar lengvai suvokiamų ir skiriamų modeliuojamo pasaulio bendrųjų vaizdų, būtent koncertų ar sąvokų, rinkinių ryšiai. E-R modelis sudaro pagrindą esybių ryšių diagramoms, kurios atitinka konceptualią duomenų bazę , kaip ji yra įsivaizduojama vartotojo. Pagrindiniai esybių ryšių diagramos komponentai yra esybės, ryšiai ir atributai. Esybės – tai gerai skiriami fiziškai ar mintyse egzistuojantys modeliuojamo pasaulio konceptai. Panašios esybės sudaro esybių aibę kurį dažniausiai vadinama tiesiog esybe. Esybės žymimos stačiakampiais, viduje užrašant esybės vardą. Vienu žodžiu, esybė esybių ryšių modelyje atitinka reliacinės aplinkos lentelę, o ne eilutę. Atributai charakterizuoja esybes, arba ryšius. Jie vaizduojami ovalais, kurių viduje rašomas atributo vardas. Ovalai sujungiami su atitinkama esybe. Atributai turi domenus. Domeną sudaro visos galimos atributo reikšmės. Atributai būna: raktiniai, jie vienareikšmiškai atitinka esybės objektą; vienareikšmiai ir daugiareikšmiai; taip pat gali būti skirstomi i paprastus ir sudėtinius. Sudėtiniai atributai – atributai, kurie gali būti toliau skaidomi, gaunant papildomus atributus. Svarbu pažymėti, kad reliaciniame modelyje negali būti sudėtinių atributų. Ryšiai – tai dvinariai junginiai, nusakantys esybių tarpusavio santykį arba sąveiką. Kiekvienas ryšys pavadinamas taip, kad vardas atspindėtų ryšio esmę. Ryšiai žymimi rombais, kuri viduje rašomas ryšio vardas. Rombas jungiamas su esybėmis, tarp kuri ir yra aprašomas ryšys. Ryšio laipsnis parodo ryšyje dalyvaujančių esybių skaičių. Skirstomi unariniai ternariniai ir binariniai ryšiai. Unariniai ryšiai, arba vieno nario ryšiai – tai ryšiai vienos esybės viduje, tokie ryšiai dar vadinami rekursyviais. Binarinis ryšys atsiranda tada, kai jungiamos dvi esybės. Šis ryšys pasitaiko dažniausiai. Ternarinis ryšys jungia tris esybes. Ryšiai tarp keturi ir daugiau esybių yra itin reti. Ryšį R tarp esybių E1, E2, …, En galima suprasti kaip sąryšį matematine prasme. Tuomet ryšys R yra esybių E1, E2, …, En Dekarto sandaugų poaibis. n – ryšio laipsnis: R E1 * E2 * … * EnElementas (e1, e2, …, en) _ R vadinamas ryšio egzemplioriumi kur ei Eikiekvienam 1 ≤i ≤n.Galima apibrėžti ir rolės sąvoką . Panagrinėjus ryšį Būtini Kursai matosi, kad reikiatiksliau nurodyti, k kuri esybės ryšyje reiškia:Būtini Kursai Kursas * KursasKad charakterizuoti egzempliorių (k , k2) Būtini Kursai, reikalingos rolės: (Prieš:k1 , Po to:k2) Būtini Kursai. Iš čia visiškai aišku, kad kursas k yra būtina sąlyga kursui k2 []. Tarp pagrindinių ryšių rūšių galima išskirti šiuos: i vienas-su-vienu (1:1), vienas-su-daug (1:N) ir daug-su-daug (N:M). Iki šiol buvo laikoma, kad esybės egzistuoja nepriklausomai viena nuo kitos (autonomiškai) ir tarp to paties tipo esybių yra vienareikšmiškai nusakomos raktinių atributų kombinacija. Realiame pasaulyje yra dar ir silpnųjų esybių, kurioms tai negalioja. Silpnoji esybė pasižymi savybėmis:Egzistavimas priklauso nuo kitos (pagrindinės, aukštesnės) esybėsPati esybė vienareikšmiškai identifikuojama tik prie rakto prijungus kitos (pagrindinės) esybės raktą.Silpnosios esybės žymimos dvigubu stačiakampiu. Ryšys su pagrindine esybe taip pat žymimas dvigubu rombu, rombą ir silpnąją esybę jungia dviguba linija. Ryšio tarp silpnosios esybės ir pagrindinės esybės jungiamumas dažniausiai būna 1:N, kartais 1:1. N:M jungiamumo būti negali [9, p. 51]. Generalizavimo ir specializavimo fazės metu išskiriamos bendros panašių esybių savybės, o būtent, atributai ir ryšiai, kuriuose dalyvauja esybės ir priskiriamos atskirai esybei – virštipiui. Galima būtų išskirti du generalizavimo/specializavimo atvejus:Disjunktyvus (nepersidengiantis) specializavimas būna tada, kai potipio aibės yra
poromis skirtingos;Pilnas specializavimas, būna tada, kai virštipio esybių aibė neturi tiesioginio egzemplioriaus , t.y. susideda tik iš potipio egzemplioriaus.Panašios esybės, iš kuri buvo išskirtos bendros savybės, vadinamos virštipio potipiais Tos savybės, kurios nėra bendros visiems potipiams, lieka prie to potipio, kuriam iš pradžių ir priklausė. Galimas ir atvirkščias procesas: jei konkrečiame esybių tipe išsiskiria esybių poaibiai, kuri viduje esybės pasižymi tomis pačiomis savybėmis, tačiau poaibiai vienas nuo kito skiriasi, tai specializavimo metu pradinė esybė išskaidoma i bendrąją dalį ir specializacijas. Esminė virštipio ir potipio sąryšio savybė – paveldimumas. Jis reiškiasi tuo, kad potipis paveldi visas savo virštipio charakteristikas, būtent atributus ir sąryšius. Taigi konkrečios potipio esybės tuo pačiu yra ir virštipio esybės. Paveldimumas – tai specialus ryšio tipas (“is – a” ryšys) [9, p. 51].2. 8. Trijų lygių duomenų bazės architektūros projektavimas
Per pastaruosius dešimtmečius failų apdorojimo metodika žymiai pasikeitė. Vienas svarbiausių pasiekimų buvo reliacinių duomenų bazių sukūrimas. Daugmaž reliacinės revoliucijos idėja yra paremta loginės struktūros atskyrimu, duomenų, pateiktų vartotojui suprantamu pavidalu, manipuliavimo būdų ir jų fizinio realizavimo. Kaip ir daugelis kitų revoliucinių idėjų, ši idėja iš pradžių iššaukė daug diskusijų, tačiau galutinai supratus jos svarba, pagaliau ji yra visur priimta. Šių lygių atskyrimas yra bet kurios ANSI/SRARC (Amerikos standartizavimo institutai) modelį atitinkančios duomenų bazės struktūros esmė. Skirtumas tarp duomenų bazės fizinio ir loginio lygių buvo oficialiai pripažintas tik 1978 metais. Tuomet ANSI/SRARC komitetas pasiūlė apibendrintą duomenų bazių sistemų struktūrą, kuri buvo pavadinta trejų lygių duomenų bazės architektūra. Jos esmė – tai trys abstrakcijos lygiai, kuriuose galima nagrinėti duomenų bazę: koncepcinis, išorinis ir vidinis. Taigi, svarbu atkreipti dėmesį į šiuos lygius duomenų bazės projektavimo kontekste, todėl reikia išnagrinėti, kaip apibrėžiamos vartotojų dalykinės sritys, o būtent išorinis lygis, jų integravimo procesą į vieningą koncepcinę duomenų bazės schemą ir šios schemos realizavimo ypatumus šiuolaikinėse komercinėse duomenų bazių valdymo sistemose. Pabrėžtina, kad šios sistemos yra pusiaukelėje tarp grynai fizinio ir grynai loginio lygių. Taip pat nepaliksime be nagrinėjimo ir vidinio, kitaip tariant, fizinio duomenų bazės lygio. Pirmiausia, reikia atkreipti dėmesį į pagrindinius duomenų bazės projektavimo žingsnius, jie pavaizduoti 2 pav.
2 pav. Pagrindiniai duomenų bazės projektavimo žingsniai.
Reiktu atkreipti dėmesį, kad pirmieji du projektavimo žingsniai, o būtent informacijos rinkimas apie dalykinę sritį ir analizė ir informacijos rinkimas apie probleminę sritį ir analizė, atliekami išoriniame lygyje. Išoriniame lygyje prasideda duomenų bazės planavimas. Jis inicijuojamas aukščiausio lygio vadovybe. Vadovai paskirsto plano parengimo dalyvius, kurie, pagal vadovybės nuosprendį, gauna visas reikalingas sėkmingam plano realizavimui lėšas. Duomenų bazės planavimas pirmiausiai aprėpia informacijos rinkimą apie dalykinę sritį ir analizę, kurią galima apibūdinti kaip žinių, duomenų, nuomonių ir požiūrių apie dalykinės srities struktūrą, joje vykstančius įvykius ir procesus, tų procesų vykdymo tikslus bei būdus ir tuos procesus vykdančių asmenų išsilavinimą, klasifikaciją bei tradicijas rinkimas. Pagrindinis dalykinės srities analizės tikslas – suvokti tą sritį ir sukaupti žinias, reikalingas duomenų bazėms sukurti, o ne parengti vienus ar kirus dokumentus. Dokumentai yra tik pagalbinė priemonė. Sukurti duomenų bazės be analizės neįmanoma. Be to informacijos rinkimo sėkmę lemia šie veiksniai: užsakovo kompetencija ir turima kompiuterizacijos patirtis;užsakovo kompetencija ir turima kompiuterizacijos patirtis;analitikų profesinė patirtis ir jų turimos dalykinės srities žinios;analizėje dalyvaujančių asmenų geba diskutuoti, suvokti kitų asmenų požiūrius ir juos aprobuoti;geras analizės planas ir jo aprūpinimas resursais. Analizės metu surinkti faktai ir nuomonės retai kada būna tarpusavyje suderinti. Kartais tuo pačiu klausimu skirtingų asmenų nuomonės gali būti prieštaringi. Todėl yra integruojami visi skirtingi ir prieštaringi požiūriai ir gaunami objektyvūs vertinimai. Visa surinkta informacija apie dalykinę sritį suklasifikuojama, apibendrinama. Tokiu būdu yra išsprendžiami konfliktai ir randamas kompromisas tarp prieštaringų nuomonių, požiūrių bei vertinimų [8]. Sekantis duomenų bazės planavimo žingsnis – tai informacijos rinkimas apie probleminę sritį ir analizė. Šį žingsnį galima apibūdinti kaip informacijos rinkimą apie sprendžiamos organizacijos problemų visumą. Priklausomai nuo organizacijos problemų yra parenkama tam tikra dalykinė sritis, jos objektai. Įveikus šį etapą, artėjama prie koncepcinio duomenų bazės projektavimo lygio. Kaip savarankiška duomenų bazių projektavimo stadija, koncepcinis projektavimas pradėtas skirti tik pastaraisiais metais, tai struktūrinis duomenų bazės lygis, kuriame aprašoma loginė duomenų bazės schema. Atliekant duomenų bazės koncepcinį projektavimą, svarbiausias žingsnis – tai projektuojamosios duomenų bazės koncepcinės schemos sudarymas. Šiame etape išskiriama dar viena grupė neatskiriamų nuo duomenų bazės elementų – tai duomenų bazės administracija. Kadangi duomenų bazė – tai labai vertingas korporatyvinis resursas, ji reikalauja duomenų kontrolės ir apsaugos. Tai ir yra pagrindinis duomenų bazės administracijos uždavinys. Ji koordinuoja koncepcinio projektavimo eigą, apmokina vartotojus, realizuoja duomenų apsaugą ir palaiko jų vientisumą bei prieinamą sistemos veikimą. Dalykinės srities koncepcinis modelis gali būti apibūdintas kaip sąveika sekančių elementų: klasių hierarchijos; ryšių; esybių ryšių ir gyvavimo ciklų; kritinių ryšių; veiklos diagramos; scenarijų; procesų bei srautų. Koncepcinio modelio paskirtis – įsivaizduoti realaus pasaulio problemą objektais, kurie abstraguojami iš dalykinės srities. Pagrindiniai koncepcinio modelio elementai yra objektai ir ryšiai tarp jų. Paprastai koncepciniame modelyje objektai yra aprašomi daiktavardžiais, o ryšiai tarp jų – veiksmažodžiais. Objektai ir ryšiai gana efektyviai padeda aprašyti mus dominančias problemas []. Loginis projektavimas yra jau po duomenų bazės modelio nustatymo, jis taikomas išrinktam modeliui ir yra priklausomas nuo programinės i rangos. Loginis projektavimas tai ne kas kita kaip scheminio projekto pervedimas i vidinį modelį . I loginį reliacinės duomenų bazės modelį eina lentelių , indeksų , virtuali lentelių , tranzakcijų projektavimas. Loginio projektavimo etape yra nustatomos duomenų bazės vartotojų teisės naudotis ja. Šiame etape iškyla daug klausimų: kas galės naudotis lentelėmis ir kokiems vartotojams kokios jų dalys bus prieinamos? Atsakymas i tokius klausymus ir padeda išsiaiškinti atitinkamų priėjimo prie duomenų teisų apibrėžimo. Trumpai tariant, loginis projektavimas perveda nuo programinės įrangos nepriklausomo scheminio modelio i priklausomą modelį , nustatant atitinkamų sričių apibrėžimus, fizinius reikalavimus, kurie leis sistemai funkcionuoti su pasirinktąja kompiuterine aplinka. Paskutinis duomenų bazės projektavimo etapas – fizinis, arba vidinis etapas. Šis etapas – tai struktūrinis duomenų bazės lygis, kuriame atliekama fizinė duomenų bazės realizacija, atliekamas fizinis duomenų bazės projektavimas. Duomenų bazės administracija nagrinėja, kaip duomenų bazės valdymo sistema apdoroja kreipinius į duomenis, išsiaiškina efektyviausius kreipimosi metodus, nusprendžia kokius metodus taikyti, norint saugiai įvesti, ištrinti ar atnaujinti duomenis.
Šių trijų lygių realizacija reikalauja iš duomenų bazės “mokėjimą pertvarkyti” iš vieno lygio į kitą. Tam, kad pateikti duomenis koncepciniame ar išoriniame lygiuose sistema turi mokėti pertvarkyti fizinius adresus ir nuorodas į atitinkamus loginius vardus ir ryšius. Toks pertvarkymas gali vykti ir priešinga kryptimi [8]. Nors atliekant tokius pertvarkymus atsiranda žymių sisteminių trukdymų, iš to gaunama ir nauda, nes šie lygiai yra nepriklausomi vienas nuo kito, o tai yra labai svarbu.3. DUOMENŲ BAZĖS KŪRIMAS
3. 1. Duomenų bazės kūrimo žingsniai
Panagrinėję daugelį duomenų bazės projektavimo ypatybių, galiausiai priėjome prie paskutinio duomenų bazės kūrimo ciklo etapo – galutinio duomenų bazės sudarymo. Tačiau, iš pradžių reiktų atkreipti dėmesį į konceptualinių duomenų bazių valdymo schemų kūrimą, duomenų apibrėžimą, jungiamų į duomenų bazę ir programų, atnaujinančių ir apdorojančių duomenų kūrimą. Ši procedūra vadinama gyvybiniu duomenų bazių ciklu . Gyvybinis duomenų bazių ciklas gali būti suprastas, kaip projektavimo, realizacijos ir duomenų bazės palaikymo procesas. Reiktų pabrėžti, kad gyvybinis duomenų bazių ciklas aprašo sistemų gyvavimo ciklą, čia išskiriami sekantys žingsniai: nagrinėjimas, reikalavimų apibrėžimas, sistemos projektavimas, programavimas ir derinimas, įdiegimas ir paleidimas ir taip pat sistemos darbo įvertinimas ir jos palaikymas. Iškyla klausimas, kaip duomenų bazių kūrimo procesas įsijungia į šį scenarijų. Tam, kad padidinti savo darbo efektyvumą, projektuotojai turi atidžiai peržiūrėti prielaidas, esančias tradiciniame sistemų gyvavimo cikle, kurio metodai paremti funkcionaliai orientuotu priėjimu. Tai reiškia, kad sistema peržiūrima iš tų funkcijų pusės, kurias ši vykdo, o ne iš duomenų pusės, kuriais ji operuoja. Tokiu būdu, struktūrinė analizė pabrėžia sekamų duomenų judėjimo reikšmes, duomenų pasikeitimo atsekimas, virtimu pasėkoje, jų tikslinimas keliuose lygiuose. Tas taip pat liečia ir struktūrinį projektavimą, kuris žiūri į sistemą, kaip į vientisą funkciją, palaipsniui sudalytų į smulkesnes įvairaus lygio funkcijas [1]. Skiriant daug dėmesio funkcijoms šie metodai mažiau atsižvelgia į duomenis, todėl sistema duoda trumpalaikę naudą, aukodama ilgalaikius vartotojų poreikius, kas yra visiškai nepriimtina. Šie trūkumai iššaukia sunkias funkcionaliai orientuotų sistemų problemas, todėl, kad jų kūrimas reikalautų daug kartų jas koreguoti ir perdarinėti, kad įgyvendinti visas norimas funkcijas. Požiūris orientuotas į duomenis, atvirkščiai, pagrindinį dėmesį skiria duomenų, reikalingų įvykdyti tam tikroms funkcijoms, analizei. Čia reiktų pažymėti du privalumus:Duomenų elementai yra žymiai stabilesnė sistemos dalis, negu vykdomos jos funkcijos. Tai surišta su tuo, kad duotą elementų rinkinį galima kombinuoti daugybe būdų, duodant atsakymus į daugelį klausimų. Jeigu mes kiekvieną klausimą analizuosime kaip sistemos vykdomą funkciją, tai lengva parodyti, kad galimų funkcijų kiekis bus žymiai didesnis negu duomenų laukelių skaičius [1]. Teisingos duomenų struktūros schemos duomenų bazės sukūrimas reikalauja smulkios vienetų klasės ir ryšių tarp jų sukūrimo. Po to kai duomenų bazės loginė schema peržiūrėta, galima sukurti bent kiek funkcinių sistemų, naudojančių tą schemą. Be tokios schemos duomenų bazė gali būti naudinga tik vienai konkrečiai funkcijai. Tokiu būdu, funkcionaliai orientuotas priėjimas naudingas tik kuriant laikinas sistemas ir turi žymiai mažesnę vertę, ilgalaikiu aspektu [1]. Metodo orientuoto į duomenis naudojimo metu duomenys tampa daugelio funkcionalių sistemų kūrimo pagrindu. Duomenų bazės plano atlikėjas gali nuspręsti, kad organizacijai reikia kelių duomenų bazių vietoj vienos, viską apimančios. Daugelis kompanijų priėjo prie tokių išvadų, kadangi jų vykdomos operacijos yra įvairiapusės. Uždavinys – sukurti naują duomenų bazę, atitinkančią visus reikalavimus, būtų per daug brangus ir, galimas daiktas, ji neatliktų visų reikalavimų. Jiems geriausias sprendimas buvo keleto gerai apibrėžtų tam tikrose srityse duomenų bazių sukūrimas. Žinoma, informacijos mainai tarp šių duomenų bazių pasidaro sudėtingesni, tačiau kompanijos linkusios rinktis pastarąjį variantą. Strateginis duomenų bazių planas siūlo kiekį ir išvaizdą, kurią reikia organizacijai sudaryti tokį, kaip nupiešta plano schemoje. Po to, kai planas yra galutinai įvertinamas, toliau gali būti sprendžiami projektavimo planai ir konkrečių duomenų bazių realizacija, būtent čia pasitarnauja duomenų bazių gyvavimo ciklas. Išankstinis planavimas – tai svarbus kintamasis strateginio plano kūrimo procese. Kada prasideda realizacijos projekto kūrimas, bendras informacinis modelis sukurtas duomenų bazės planavimo procese peržiūrimas ir jei reikia, tai tobulinamas. Planavimo procese kaupiama informaciją, atsakanti į šiuos klausimus:1. Kiek naudojama taikomųjų programų ir kokias funkcijas jos vykdo. 2. Kokie failai surišti su kiekviena iš šių taikomųjų programų. 3. Kokios naujos programos ir failai atsiranda kūrimo procese. Sekantis žingsnis – tai įgyvendinamumo patikrinimas, kuris apibrėžia technologinį, operacinį ir ekonominį duomenų bazės plano įgyvendinamumą. Čia svarbu paminėti ataskaitų paruošimą šiais klausimais: 1. Technologinis įgyvendinamumas. Ar yra technologija, reikalinga DB realizuoti? 2. Operacinis įgyvendinamumas. Ar kompanijoje yra personalas, resursai ir ekspertai, reikalingi sėkmingam DB plano įgyvendinimui? 3. Ekonominis naudingumas. Ar galima nustatyti naudą? Ar atsipirks suplanuota sistema? Toliau žengiame prie reikalavimų nustatymo, į šį etapą įeina duomenų bazės tikslų pasirinkimas, informacinių reikalavimų nustatymas atskiriems padaliniams. Galiausiai, atlikus konceptualinį projektavimą, apie kurį jau buvo kalbama anksčiau, priėjome prie paskutinės duomenų bazės kūrimo stadijos – realizacijos. Realizaciją galima apibūdinti kaip žingsnius, kuriuos reikia įgyvendinti, kad paversti konceptualų modelį į funkcionuojančią duomenų bazę. Duomenų bazės realizacijos procese išsirenkamos duomenų bazių valdymo sistemos. Vėliau smulkus konceptualinis modelis verčiamas į duomenų bazės realizacijos projektą. Kuriami duomenų žodynai, duomenų bazė užpildoma duomenimis. Kuriamos taikomosios programos, apmokomi vartotojai. Galiausiai duomenų bazė vertinama ir tobulinama. Įvertinimas susideda iš vartotojų apklausos, kad išsiaiškinti, kokie informaciniai poreikiai liko neįvertinti. Jei reikia, yra įnešami pakeitimai. Sukuriamas sistemos palaikymas pakeitimais, koregavimais ir papildymais, naujų duomenų elementų pridėjimas, atsižvelgiant į verslo plėtimąsi [1].
IŠVADOS
Šiuolaikiniame pasaulyje organizacijos susiduria su žiauria konkurencija, todėl bet kurios organizacijoje naudojamos informacinės sistemos svarbiausias tikslas turėtų būti duomenų pavertimas informacija ir žiniomis, nes tik informacija ir žinios suteikia organizacijai konkurencinį pranašumą. Kaupti duomenis ir iš jų gauti informaciją bei žinias stengiasi kiekviena organizacija. Būtent duomenų bazės suteikia galimybe sukaupti milžiniškus duomenų kiekius prie kurių garantuojamas lengvas priėjimas. Atsakant į iškeltus tikslus darbe buvo išanalizuoti sekantys dalykai:Apibrėžta duomenų bazių ir jų valdymo sistemų funkcionavimo esmė;Aptarta duomenų bazės SQL užklausų kalbos ypatumai;Išnagrinėti duomenų bazės struktūros modeliai;Apibrėžtas esminiai duomenų bazės projektavimo etapai; Nustatyti duomenų bazės kūrimo ciklo žingsniai. Kai kurios temos buvo išanalizuotos, pateikiant konkrečius pavyzdžius. Duomenų bazės – tai vienas svarbiausių informacijos srauto apdorojimo, saugojimo ir pateikimo elementas, be kurio tiesiog neįmanoma įsivaizduoti šiuolaikinį informacijos technologijų pasaulį., šis darbas – tai dar vienas bandymas susistemintai paaiškinti duomenų bazių kūrimo technologijų ypatumus.
BIBLIOGRAFINIŲ NUORODŲ SĄRAŠAS
1. ANDRIULIENĖ, B. Duomenų bazių kūrimo ciklas. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .2. ANDRIULIENĖ, B. Koncepcinis (Esybių ryšių) duomenų modelis. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .3. ANDRIULIENĖ, B. Reliacinis duomenų modelis. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .4. ANDRIULIENĖ, B. SQL užklausų kalba. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .5. ANDRIULIENĖ, B. Normalizacija. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .6. ANDRIULIENĖ, B. DB valdymas. Reliacinė algebra. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .7. ANDRIULIENĖ, B. DB valdymas. Reliaciniai skaič8. iavimai. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .9. ANDRIULIENĖ, B. Trijų lygių DB architektūros projektavimas. Iš Duomenų bazių kursas [interaktyvus]. Klaipėda: Klaipėdos universitetas, informatikos katedra, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .10. BARONAS, Romas. Duomenų bazių sistemos. Vilnius: TEV, 2002. 126 p. ISBN 9955-491-24-8.11. JUOZAPAVIČ12. IUS, A. Duomenų bazių projektavimas [interaktyvus]. Vilnius: Vilniaus universitetas, matematikos ir informatikos fakultetas, [žiūrėta 2004 m. Kovo 4 d.]. Prieiga per internetą: .13. КАТАРЫГИН, Серьгей А. Базы данных : простейшие средства обработки информации, электронные таблицы, системы управления базами данных. Москва: ABF, 1995. 2 t.14. ROB, Peter. Database Systems. Design, Implementation andManagement. California, Belmont: Wadsworth Publishing Company, 1993.15. SEKLIUCKIS, Vitolis. Duomenų bazės. Kaunas: Naujasis lankas, 2001. 94 p. ISBN 9955-03-058-5.16. SEKLIUCKIS, Vitolis. Informacijos sistemos ir duomenų bazės. Kaunas: Technologija, 2003. 338 p. ISBN 9955-09-486-9.