Naujos duomenų bazės kūrimas. Naujos bazės pagrindinės sąvokos.

Vilniaus teisės ir verslo kolegija

Ekonomikos katedra

Naujos duomenų bazės kūrimas. Naujos bazės pagrindinės sąvokos.

Atliko:

RV 4/1

Tikrino: dėstytojas

2004, Vilnius

Turinys:

Įžanga 3

1. Duomenų organizavimo principai, duomenų vaizdavimas 4

2. Reliacinės duomenų bazės, jų savybės 6

3. Duomenų normalizavimas ir normalinės formos 8

4. Duomenų bazių valdymo sistemos, jų funkcijos ir sudėtis 10

5. Duomenų bazės kūrimas ir redagavimas 13

6. Žinių bazių sistemų kūrimas 14

7. Navigacijos duomenų bazėje priemonės 14

8. Duomenų bazės rikiavimas ir indeksiniai failai 14

9. Paieškos priemonės 15

10. Ataskaitų kūrimas 17

11. Taikomųjų programų kūrimas, užklausų kalba SQL 18

12. Ryšys su kitomis programomis 19

13. Duomenų bazių taikymas 20

14. Populierių duomenų bazių valdymo sistemų palyginimas 21

15. Access 2002 apžvalga 22

16. Pavyzdys 32

Literatūra 34

Įžanga:

Šiame skyriuje supažindinama su pagrindinėmis duomenų bazių (DB) sąvokomis, jų kūrimo iir panaudojimo principais. Daugiausia dėmesio skiriama reliaciniam duomenų tvarkymo būdui. Glaustai aprašomas duomenų normalizavimas, tai iliustruojama tipiniu pavyzdžiu.

Skyriuje pateikiama žinių apie duomenų bazių valdymo sistemas (DBVS), jų paskirtį, svarbiausias funkcijas bei sudedamąsias dalis. Apžvelgiamos įvairios DB vartotojams teikiamos galimybės, instrumentai, taikomųjų programų kūrimas, užklausų kalba SQL ir kt.

Skyriaus pabaigoje apibūdinama tipinė DB taikymo situacija, taip pat kai kurių DBVS lyginamosios charakteristikos.

Duomenų bazės samprata

Terminas „duomenų bazė” atsirado XX amžiaus 6-ojo dešimtmečio pabaigoje, tačiau ir šiuo metu vis dar įvairiai aapibrėžiamas. Yra kelios DB sampratos. Pagrindinės yra dvi.

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

Duomenims, saugomiems DB, būdingos šios savybės:

q integruotumas;

q nepertekliškumas;

q nepriklausomumas.

Duomenų integruotumas reiškia, kad visi duomenys kaupiami ir saugomi kartu nustačius jų tarpusavio ryšius. Taip saugomus duomenis dažniausiai naudoja ne vienas, o keli vartotojai.

Antroji savybė nusako tai, jog duomenys saugomi vengiant jų dubliavimo. Kai yra pertekliškumas, t.y. kelios duomenų kopijos, joms veltui eikvojama atmintis, o modifikuojant duomenis tenka kelis kartus naudoti tas pačias atnaujinimo operacijas. Be to, kai dduomenų kopijos atitinka skirtingas atnaujinimo stadijas, tai gali iššaukti prieštaringos informacijos pateikimą.

Duomenų nepriklausomumas reiškia, kad duomenų apdorojimo taikomosios programos nesikeičia modifikuojant duomenis.

Antroji DB samprata yra platesnė, ji apima ne tik tvarkingai saugomus duomenis, bet ir programinę įrangą, skirtą duomenų bazėms kurti ir įvairiais būdais apdoroti.

Duomenų organizavimo principai, duomenų vaizdavimas

Prieš pradėdami nagrinėti duomenų organizavimą, apibrėšime duomenų elemento (DE) sąvoką. DE vadinsime minimalią prasmingą duomenų dalį. Kaip minėta, DB duomenys saugomi ne bet kaip, o kaip susietų tarpusavyje DE visuma, t. yy. joje turi būti nustatyti ryšiai tarp įvairių DE. Toks duomenų sruktūros pateikimo būdas dažnai vadinamas duomenų modeliu. Jį patogu grafiškai vaizduoti ovalinėmis diagramomis. Tokiose diagramose DE vaizduojami ovalais, kurių viduje užrašomas DE vardas, o ryšiai vaizduojami linijomis (žr. 1 pav.).

1 pav. Duomenų vaizdavimas ovaline diagrama

1 pav. diagramoje yra du DE , o kiekvienas DE gali turėti daug reikšmių. Pvz., DE „Studentas” gali turėti reikšmes: «JONAITIS J», «PETRAITIS P» ir kt., DE „Stipendija” – 0, 200 ir kt.

Yra du pagrindiniai ryšių tarp DE tipai. Pirmasis – tai vadinamasis ryšys „vienas su vienu”, arba paprastas ryys. Sakoma, jog tarp DE „A” ir „B” egzistuoja paprastas ryšys, jeigu bet kuriuo momentu kiekvieną „A” reikšmę atitinka tik viena „B” reikšmė. Toks ryšys vaizduojamas paprasta rodykle (žr. 2 pav.). Šiuo atveju sakoma, kad „A” identifikuoja „B”.

2 pav. Ryšio „vienas su vienu” pavyzdys

Antras tipas – tai vadinamasis ryšys „vienas su daugeliu” arba sudėtingas ryšys. Tarp DE „A” ir „B” egzistuoja sudėtingas ryšys, jeigu bet kuriuo momentu vieną „A” reikšmę atitinka kelios „B” reikšmės. Toks ryšys vaizduojamas dviguba rodykle (žr. 3 pav.).

3 pav. Ryšio „vienas su daugeliu” pavyzdys

Tarp bet kurių dviejų DE dažnai egzistuoja abipusis ryšys. Pavyzdžiui, jei DE yra „Vyras” ir „Moteris”, tai tarpusavio ryys ttarp jų gali atspindėti santuokos formą (žr. 4 pav.).

4 pav. Galimi ryšių tarp DE „Vyras” ir „Moteris” variantai

Pirmuoju (a) atveju 4 pav. vaizduojama tradicinė krikščioniška santuokos forma, antruoju (b) atveju – daugpatystė, trečiuoju (c) – daugvyrystė, ketvirtuoju (d) – grupinė santuoka.

Kitame pavyzdyje pateikiama ovalinė diagrama su gausesniais DE ir ryšiais tarp jų (žr. 5 pav.).

5 pav. Duomenys apie skyriaus tarnautojus ir jų ryšiai

Šioje diagramoje vaizduojami ne visi galimi ryšiai tarp DE. Čia, pavyzdžiui, nematyti sudėtingo ryšio „Alga” – „Tarnautojas” (o be tokio ryšio nebūtų galima atsakyti štai į tokį vartotojo klausimą „Kokie tarnautojai gauna algą, didesnę negu 1000 litų?”).

Jeigu yra N skirtingų DE, tai tarp jų galimi N* (N-1) ryšiai. Todėl didelėse DB, kuriose būna šimtai ar tūkstančiai DE, ryšių skaičius be galo išaugtų (pvz., jei N=1000, tai ryšių skaičius siektų milijoną). Norint sumažinti ryšių skaičių, DE jungiami į grupes. Tokios DE grupės vadinamos įrašais. Įrašų struktūrą taip pat galima pavaizduoti ovalinėmis diagramomis (žr. 6 pav.). Konkretaus įrašo struktūros pavyzdys pateiktas 7 pav.

6 pav. Bendras įrašo ovalinės diagramos pavidalas

7 pav. Įrašo vaizdavimo ovaline diagrama pavyzdys

Įraše yra bent vienas DE (ar jų rinkinys), kurio visos reikšmės yra nepasikartojančios, t. y. jo reikšmės vienareikšmiškai identifikuoja kitas įrašo reikšmes. Toks DE (ar jų rrinkinys) vadinamas raktu. Kiti (neraktiniai) DE vadinami atributais (žr. 6 pav.). Jei raktas susideda iš kelių DE, jis vadinamas sudėtiniu. Sudėtinis raktas apdorojant duomenis traktuojamas kaip vienas DE ir diagramoje vaizduojamas vienu ovalu. 8a pav. parodytas sudėtinis raktas „Programuotojas”+„Programos Nr.”.

8 pav. Sudėtinių ir galimų raktų pavyzdys

Įrašas gali turėti kelis raktus, vadinamus galimais raktais. 8 pav. diagramoje yra du galimi raktai – „Programuotojas”+„Programos Nr.” ir „Programuotojas”+„Programos pavadinimas”. Vienas iš galimų raktų yra pirminis raktas (faktiškai naudojamas DE identifikacijai), o kiti – alternatyvieji raktai (raktai-kandidatai).

Pirminiam raktui DE reikia parinkti taip, kad iš anksto būtų žinomas jų įgyjamų reikšmių diapazonas, o DE jame būtų kuo mažiau. Labai pabrėžtina rakto savybė yra jo pertekliškumo nebuvimas: iš rakto, kurį sudaro keli DE, negalima išmesti jokio DE (to rakto nesuardant). Įrašo rakto svarba didelė – juo galime atskirti DE vieną nuo kito, pagal jį nustatoma įrašo vieta atmintyje.

Panašiai kaip DE, į grupes sujungiami ir įrašai. Įrašų su tarpusavio ryšiais visuma sudaro DB. Jos sudarymo metu labai svarbu tai, kaip sugrupuojami DE, t. y. kokie DE surenkami į vieną įrašą, kokie parenkami raktai ir kaip tarp įrašų nustatomi ryšiai.

Ryšiai tarp skirtingų įrašų vaizduojami rodyklėmis tarp tų

įrašų raktų – taip gaunamas DB rodyklinis modelis, kitaip tariant, DB struktūros diagrama. DB, rezervuojančios lėktuvų bilietus, diagramos pavyzdys parodytas 9 pav.

9 pav. DB struktūros ovalinės diagramos pavyzdys

Kompaktiškesnis įrašo ir DB struktūros vaizdavimo būdas yra stačiakampė diagrama. Tokioje diagramoje DE vaizduojami stačiakampiais, o įrašai – stačiakampių blokais. Raktiniai DE pabraukiami. 10 pav. pateikiama stačiakampė diagrama, gauta iš 9 pav. parodytos ovalinės diagramos.

10 pav. DB struktūros stačiakampės diagramos pavyzdys

Reliacinės duomenų bazės, jų savybės

Pagal tai, kokiu būdu duomenys jungiami į visumą, iišskiriami šie duomenų organizavimo (sutvarkymo) modeliai: reliacinis, hierarchinis, tinklinis. Pastaruoju metu bene populiariausios DB, kuriose duomenys organizuojami pagal reliacinį modelį, – tai reliacinės DB. Reliacinė DB yra tokia duomenų visuma, kurioje informacija (duomenys) saugoma vadinamosiose dvimatėse lentelėse. (Toliau dvimatės lentelės vadinamos tiesiog lentelėmis.) Lentelės pavyzdys parodytas 1 pav.

1 pav. Lentelės pavyzdys (užsakymų registracijos žurnalas)

Lentelę sudaro eilutės ir stulpeliai, taigi lentelės forma yra įprasta ir suprantama vartotojui. Lentelės eilutės vadinamos įrašais, o stulpeliai – laukais (žr. 1 pav.). Laukams duodami vardai ((pvz. „UŽSAKYMO NUMERIS”, „PIRKĖJO KODAS” ir pan.). Pažymėtina, kad lauko sąvoka atitinka DE sąvoką anksčiau nagrinėtuose duomenų vaizdavimuose. Į lentelės įrašus įtraukiamos duomenų porcijos, kurias sudaro DE reikšmės, dar vadinamos laukų reikšmėmis (pvz., «A2599», «98 01 26» ir pan.). Bet kkurios eilutės ir bet kurio stulpelio susikirtime turi būti tik viena DE reikšmė, o ne tų reikšmių rinkinys.

Reliacinėse DB kiekviena lentelė pasižymi tokiomis savybėmis:

q Visi įrašai yra vienodai organizuoti, turi tą pačią struktūrą. Visuose įrašuose yra tiek pat laukų, o laukai yra vienarūšiai, t. y. kiekvieno lauko reikšmės yra vieno tipo. Tačiau skirtinguose laukuose gali būti įvairių tipų duomenys;

q Lentelėje negali būti tuščių įrašų, taip pat identiškų įrašų, t. y. įrašų su pilnai pasikartojančiais duomenimis, nors atskiri duomenų elementai gali būti tušti arba pasikartojantys;

q Įrašų ir laukų išdėstymo tvarka lentelėje nėra svarbi. Atliekant duomenų apdorojimo operacijas lentelės eilutės ir stulpeliai gali būti peržiūrimi bei tvarkomi bet kuria tvarka, nepriklausomai nuo jų informacinio turinio.

Kiekvienai lentelei suteikiamas vardas, kuriuo ji saugoma kompiuterio išorinėje atmintyje (diske) kkaip atskiras objektas. Lentelės vardas turėtų atspindėti atitinkamo realaus informacinio objekto pavadinimą, o laukų vardai – to objekto atributų pavadinimus. Pavyzdžiui, 1 pav. parodytai lentelei galėtų būti suteiktas vardas „UŽSAKYMAI” (laukų vardai pavaizduoti paveikslėlyje).

Lentelėms nustatomi raktai, t. y. laukai ar laukų grupės, kurių įgyjamos reikšmės yra nepasikartojančios, taigi šios reikšmės vienareikšmiškai identifikuoja tų lentelių įrašus. Lentelės gali turėti po kelis raktus, iš kurių konkrečiu momentu faktiškai naudojamas tik vienas – pirminis raktas.

Labai dažnai naudojama sutrumpinta lentelių pateikimo forma, kai iš ppradžių užrašomas lentelės vardas, o po to tarp skliaustelių išvardijami lentelės laukų vardai. Laukų, įeinančių į pirminio rakto sudėtį, vardai pabraukiami. Toks užrašas vadinamas lentelės schema. 1 pav. pateiktos lentelės schema atrodo taip:

UŽSAKYMAI (UŽSAKYMO NUMERIS, PIRKĖJO KODAS, PREKĖS KODAS, UŽSAKYMO DATA, UŽSAKYTAS KIEKIS).

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

Bet kurią duomenų struktūrą galima vaizduoti tiek rodykline, tiek lentelių forma. Toliau panagrinėsime kelis pavyzdžius, kuriuose parodysime duomenų modelio, pavaizduoto stačiakampėmis diagramomis, pervedimą į reliacinį modelį.

Anksčiau pateikta DB, skirta lėktuvų bilietų rezervavimui, pervedama į reliacinę DB, susidedančią iš dviejų lentelių:

REISAS (REISO_NR., IŠVYKIMO PUNKTAS, ATVYKIMO PUNKTAS, LĖKTUVO TIPAS);

LAISVOS VIETOS (REISO_NR., DATA, LAISVOS VIETOS).

Šiuo atveju nėra perteklinių laukų ((DE), nes rodykliniame modelyje ryšį tarp atskirų įrašų tipų nurodo bendras atributas „Reiso Nr.”. Pateiktose schemose lentelė „REISAS” vadinama pagrindine lentele lentelės „LAISVOS VIETOS” atžvilgiu, o lentelė „LAISVOS VIETOS” – antrine lentele lentelės „REISAS” atžvilgiu. Pažymėtina, kad į reliacinę DB įeinančių lentelių schemų užrašymo tvarka gali būti bet kokia.

Panagrinėsime DB, aprašančią kurios nors įstaigos skyrių darbinę veiklą (žr. 2 pav.).Čia kiekvienas darbas atliekamas viename skyriuje.

2 pav. DB, aprašančios darbinę įstaigos veiklą, rodyklinis vaizdavimas

Pervedę šios DB rodyklinę formą į reliacinę, gauname tokias lentelių schemas:

SKYRIUS (SKYRIAUS_NR, PAVADINIMAS, VADOVAS, BIUDŽETAS);

DARBAS (DARBO_NR, SKYRIAUS_NR, DARBO_APRAŠYMAS);

DARBUOTOJAI (DARBUOTOJO_NR, DARBO_NR, PAVARDĖ, SKYRIAUS_NR, ALGA);

DARBINĖ_VEIKLA (PASKYRIMO_DATA, DARBUOTOJO_NR, PAREIGOS);

ALGOS_KEITIMAI (KEITIMO_DATA, DARBUOTOJO_NR, ALGA).

Čia atsižvelgiama į tai, jog požymis „DARBO_NR” nėra visuotinai priimtas identifikatorius įstaigoje, o kiekviename skyriuje yra savi darbų numeriai. Todėl pilnai darbų identifikacijai į lentelės „DARBAS” schemą įvedamas papildomas laukas „SKYRIAUS_NR”, kuris kartu su lauku „DARBO_NR” sudaro pirminį raktą. Laukas „DARBUOTOJO_NR” įvedamas į lentelių „DARBINĖ_VEIKLA” ir „ALGOS_KEITIMAI” schemas taip pat kaip pirminio rakto dalis. Į lentelę „DARBUOTOJAI” įvestas papildomas laukas („DARBO_NR”), neįeinantis į pirminio rakto sudėtį, bet naudojamas ryšiui užtikrinti. Šis laukas pabrauktas punktyrine linija.

Kai DB sudaro daug lentelių, svarbu, kad būtų patenkinama vadinamoji duomenų pilnumo sąlyga – bet kurią antrinės lentelės siejančio lauko reikšmę turi atitikti tokia pati reikšmė iiš pagrindinės lentelės lauko. Pvz., bet kuris lentelėje „DARBUOTOJAI” pasitaikęs skyriaus numeris turi būti aprašytas lentelėje „SKYRIUS”.

Duomenų normalizavimas ir normalinės formos

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

Normalizuojama keliais žingsniais (etapais), kurių metu lentelės įgyja atitinkamas pateikimo formas, vadinamas normalinėmis formomis (NF). Taigi normalizuojamos lentelės pervedamos iš vienos NF į kitą. Pirmiausia apibrėšime terminą „funkcinė priklausomybė”.

Sakoma, kad lentelės laukas B funkcionaliai priklauso nuo tos pačios lentelės lauko A, jei bet kuriuo momentu kiekvieną A reikšmę atitinka ne daugiau kaip viena B reikšmė. Kitaip tariant, A lauko reikšmės identifikuoja B lauko reikšmes. Trumpai tai užrašoma naudojant rodyklę: A -> B. Jei keli laukai priklauso nuo vieno lauko A, pateikiamas jų sąrašas, pvz., A -> B, C, D.

Pažymėtina, kad funkcinės priklausomybės atspindi duomenų vidinius, prasminius ryšius, tuo tarpu laukai

– duomenų struktūrą.

Jei neraktinis laukas funkcionaliai priklauso nuo sudėtinio rakto atskiros dalies, tai suprantama kaip šio lauko dalinė funkcinė priklausomybė nuo rakto. Jei neraktinis laukas priklauso tik nuo viso sudėtinio rakto, o ne nuo atskirų dalių, tai sakoma, kad yra pilna funkcinė šio lauko priklausomybė nuo rakto. Jei A, B ir C laukams egzistuoja priklausomybės A -> B bei B -> C, bet atvirkštinių priklausomybių nėra, tai sakoma, kad C tranzityviai priklauso nuo A.

Dabar apibūdinsime tris pagrindines NF. Lentelė yyra pirmosios normalinės formos (1NF), jeigu kiekvienas neraktinis laukas yra pilnoje arba dalinėje funkcinėje priklausomybėje nuo bet kokio galimo tos lentelės rakto.

Lentelė yra antrosios normalinės formos (2NF), jeigu kiekvienas jos neraktinis laukas yra pilnoje funkcinėje priklausomybėje nuo bet kokio galimo tos lentelės rakto.

Lentelė yra trečiosios normalinės formos (3NF), jeigu kiekvienas jos neraktinis laukas yra tiesioginėje pilnoje, bet ne tranzityvioje priklausomybėje nuo bet kokio galimo tos lentelės rakto.

Kaip 1NF lentelės pavyzdį galima pateikti lentelę, turinčią informaciją apie gaminių tiekimą. Lentelės schema yyra tokia:

TIEKIMAS (TIEKĖJO_NR (TN), GAMINIO_NR (GN), TIEKĖJO_PAVARDĖ (TP), DUOMENYS_APIE_TIEKĖJĄ (TD), TIEKIMO_KAINA (TK)).

Funkcinės priklausomybės tarp šios lentelės laukų:

TN+GN -> TP, TD, TK

TN -> TP, TD .]

Čia pirmoje eilutėje parodytos pilnos funkcinės priklausomybės nuo pirminio rakto, o antroje – dalinės funkcinės ppriklausomybės nuo sudėtinio rakto dalies TN.

Kaip matome, laukai TP ir TD, būdami neraktiniais laukais, funkcionaliai priklauso nuo vienintelio galimo rakto TN+GN dalies TN. Taigi ši lentelė nėra 2NF, tai reiškia, kad ji yra 1NF.

1NF lentelių apdorojimui būdinga nemaža keblumų, vadinamų anomalijomis:

Įvedimo anomalija. Negalima įvesti tam tikrų duomenų tol, kol neįvesta pilna rakto reikšmė (pvz., pateiktoje lentelėje TIEKIMAS negalima įvesti jokių duomenų apie tiekėją iki to laiko, kol jis nepristatęs kokio nors gaminio).

Atnaujinimo (keitimo) anomalija. Reikia didelių papildomų laiko, atminties resursų, atnaujinant lentelėje dažnai pasikartojančias reikšmes bei įterpiant lentelėje naujus laukus (pvz., norint įvesti papildomus duomenis apie tiekėją, reikia papildomų resursų, jei tiekėjo pristatomų gaminių įvairovė didelė).

Šalinimo anomalija. Šalinant tam tikrus duomenis, gali būti prarasta naudinga informacija, netiesiogiai susijusi su šalinamais dduomenimis (pvz., šalinant konkretų tiekėją, atsiranda pavojus prarasti informaciją apie gaminius, jei juos tiekė tik šis tiekėjas).

Tokio tipo anomalijas galima panaikinti išskaidžius lentelę, t. y. išskyrus į atskiras lenteles sudėtinio rakto dalis ir nuo jų priklausančius laukus. Pavyzdžiui, lentelė TIEKIMAS gali būti išskaidyta į tokias dvi lenteles:

TIEKĖJAS(TIEKĖJO_NR, TIEKĖJO_PAVARDĖ, DUOMENYS_APIE_TIEKĖJĄ);

TIEKIMAS(TIEKĖJO_NR, GAMINIO_NR, TIEKIMO_KAINA).

Panagrinėsime dar vieną – šiuo atveju 2NF lentelės – pavyzdį. Lentelėje yra informacija apie projektavimo įstaigos darbuotojus, o lentelės schema atrodo taip:

DARBUOTOJAI (DARBUOTOJO_NR (DN), DARBUOTOJO_ASM_KOD (DAK), ALGA (AL), PROJEKTO_NR (PN), BBAIGIMO_DATA (BD)).

Funkcinės priklausomybės tarp šios lentelės laukų:

DN -> DAK, AL, PN

DAK -> DN, AL, PN

PN -> BD

Lentelė DARBUOTOJAI, būdama 1NF, yra ir 2NF, nes jos abu galimi raktai (DN ir DAK) turi tik po vieną lauką. Tačiau ši lentelė nėra 3NF, nes jos neraktinis laukas BD tranzityviai priklauso nuo galimų raktų (tai aišku iš priklausomybių: DN -> PN arba DAK -> PN, PN -> BD).

2NF lentelėms irgi būdingos minėtos įvedimo, atnaujinimo ir šalinimo anomalijos. Pavyzdžiui, negalima įvesti projekto baigimo datos tol, kol nepaskirti šio projekto vykdytojai (įvedimo anomalija). Projekto datos keitimas reikalauja visų turinčių šią datą įrašų – o jų gali būti labai daug – paieškos ir modifikavimo (atnaujinimo anomalija). Atleidus iš darbo visus kurio nors projekto vykdytojus, t. y. pašalinus šiuos darbuotojus atitinkančius įrašus, bus prarasta ir to projekto baigimo data (šalinimo anomalija).

Šios anomalijos išnyksta, panaikinus lentelėje esančią tranzityvią funkcinę priklausomybę. Tai galima padaryti išskaidžius lentelę į atitinkamas atskiras lenteles. Pavyzdžiui, lentelę DARBUOTOJAI galima išskaidyti į tokias lenteles:

DARBUOTOJAI (DARBUOTOJO_NR, PROJEKTO_NR, DARBUOTOJO_ASM_KOD, ALGA);

PROJEKTAI (PROJEKTO_NR, BAIGIMO_DATA).

Gautos lentelės DARBUOTOJAI ir PROJEKTAI yra trečiosios normalinės formos. Pažymėtina, kad lentelės DARBUOTOJAI laukas PROJEKTO_NR nėra joks raktas, jis naudojamas tik lentelėms susieti.

Galima padaryti išvadą, kad normalizuojant DB, kitaip tariant, pervedant DB lenteles iš vienos nnormalinės formos į kitą, siekiama tokių esminių tikslų: išvengti nepageidaujamų funkcinių priklausomybių tarp lentelių laukų, kuo labiau sumažinti duomenų pertekliškumą, supaprastinti duomenų apdorojimą.

Tipinis duomenų normalizavimo pavyzdys

Toliau nagrinėjamas tipinis pavyzdys, padedantis geriau suvokti duomenų normalizavimo proceso ypatumus.

Tarkime, kad reikia sukurti DB, kurioje turi būti saugoma informacija apie studentų mokymosi rezultatus. Į DB pradinės lentelės sudėtį įtraukiami šie laukai:

STUDENTO_BILIETO_NR (SB),

STUDENTO_PAVARDĖ (SP),

AKADEMINĖ_GRUPĖ (AG),

FAKULTETAS (FA),

GIMIMO_METAI (GM),

GYVENAMOS_VIETOS_ADRESAS (GA),

DISCIPLINOS_KODAS (DK),

DISCIPLINOS_PAVADINIMAS (DP),

KREDITŲ_SKAIČIUS (KS),

EGZAMINO_ĮVERTINIMAS (EĮ),

EGZAMINO_DATA (ED),

EGZAMINATORIAUS_PAVARDĖ (EP).

Šioje didelėje lentelėje norint surasti kurio nors studento laikyto egzamino įvertinimą, datą ir egzaminatoriaus pavardę, reiktų parinkti pirminį raktą, sudarytą iš dviejų laukų (SB+DK)

Pradinė DB lentelė aprašoma štai tokia schema:

STUDIJOS (SB, SP, AG, FA, GM, GA, DK, DP, KS, EĮ, ED, EP).

Funkcinės priklausomybės, egzistuojančios tarp lentelės (duomenų bazės) STUDIJOS laukų:

SB+DK -> EĮ, ED, EP

SB -> SP, AG, FA, GM, GA

DK -> DP, KS

AG -> FA

Lentelėje STUDIJOS yra laukų, iš dalies priklausančių nuo sudėtinio rakto SB+DK. Normalizavę, t. y. išskaidę iš dalies priklausančius laukus į atskiras lenteles, gausime šias lenteles:

STUDENTAI (SB, SP, AG, FA, GM, GA);

STUDIJOS (SB, DK, EĮ, ED, EP);

DISCIPLINOS (DK, DP, KS).

Lentelėje STUDENTAI egzistuoja lauko FA tranzityvi priklausomybė nuo rakto SB. Jos galima išvengti sudarius dar vieną lentelę GRUPĖS (AG, FA) ir pašalinus lauką FA lentelėje STUDENTAI. Po šių pakeitimų turime 33NF lenteles:

GRUPĖS (AG, FA);

STUDENTAI (SB, SP, AG, GM, GA);

STUDIJOS (SB, DK, EĮ, ED, EP);

DISCIPLINOS (DK, DP, KS).

Duomenų bazių valdymo sistemos, jų funkcijos ir sudėtis

Duomenų bazės valdymo sistema (DBVS) vadinama programinė įranga, skirta DB kurti, jas saugoti ir įvairiais būdais apdoroti. Svarbiausios DBVS funkcijos yra šios:

q DB struktūros projektavimas;

q DB pildymas, kaupimas, redagavimas;

q navigacija DB;

q duomenų peržiūra, paieška, rikiavimas ir kitas tvarkymas;

q taikomųjų vartotojo programų kūrimas;

q ataskaitų kūrimas.

Bet kurią DBVS sudaro priemonės DB stuktūrai projektuoti, duomenims įvesti, papildyti ir modifikuoti. Šiuolaikinė DBVS suteikia jos vartotojui lanksčias galimybes lengvai surasti ir atrinkti reikalingus duomenis pagal vieną ar kelis kriterijus, tuos duomenis rikiuoti, grupuoti, vaizduoti juos pageidaujama forma. Tam tikrais laiko tarpais reikia sukauptą informaciją apibendrinti, atlikti analizę, vykdyti matematinius, statistinius skaičiavimus ir kurti įvairių formatų ataskaitas. Vartotojai, esant reikalui, rašo bei derina savas taikomąsias programas, naudodamiesi tam skirtomis DBVS priemonėmis. DBVS turi atlikti ir daug kitų svarbių funkcijų: duomenų apsaugą, jų korektiškumo, neprieštaringumo ir išsamumo kontrolę, DB kopijų išsaugojimą ir kt.

Daugelį šiuolaikinių DBVS sudaro tokios dalys:

q duomenų tvarkymo dialoginė aplinka;

q duomenų aprašymo ir manipuliavimo jais kalba;

q programų generatoriai.

Dialoginė aplinka yra viena svarbiausių šiuolaikinių DBVS dalių. Ji skirta interaktyviam darbui su DBVS atliekant veiksmus su visa DB ar atskirais įrašais. Šiuolaikinės dialoginės aplinkos

suteikia vartotojui galimybę pasirinkti jam priimtiniausią darbo su DB stilių. Yra du pagrindiniai darbo su DB būdai:

q grafinių, vizualiai orientuotų instrumentų panaudojimas;

q specialių instrukcijų rašymas.

Grafiniai instrumentai pagal savo veikimo principą skirstomi į dizainerius, meistrus (žynius-suflerius) ir meniu sistemas. Dizaineriai suteikia galimybę vartotojui pačiam laisvai pasirinkti, ką daryti ir kaip daryti. Meistrai ir meniu sistemos leidžia tik išsirinkti, ką daryti, t. y. pateikiamas galimų veiksmų sąrašas (meniu), o vartotojui telieka patvirtinti savo pasirinkimą iš daugelio siūlomų veiksmų sekų ar maršrutų. Be mminėtų instrumentų dažnai naudojami konstruktoriai, padedantys rašyti sudėtingas išraiškas, formules ir pan.

Kita svarbi DBVS dalis yra duomenų aprašymo ir manipuliavimo jais kalba. Ji skirta kurti taikomąsias programas, t. y. tokias programas, kurias vartotojas ar jų grupė naudoja konkretiems, specifiniams uždaviniams spręsti. Į tokios kalbos sudėtį įeina duomenų aprašymo ir manipuliavimo jais instrukcijos (komandos). Aprašant duomenis nurodoma DB lentelių struktūra, raktiniai laukai, ryšiai tarp atskirų lentelių. Manipuliavimo duomenimis instrukcijos – tai daugybė įvairios paskirties komandų, skirtų tiesiogiai apdoroti duomenų elementus (laukų rreikšmes), lentelių įrašus, lenteles ar visą DB.

Iš daugybės manipuliavimo duomenimis instrukcijų į savarankišką grupę išskiriamos vadinamosios užklausos. Jos aprašomos ir vykdomos atitinkama kalba. Viena plačiausiai naudojamų užklausų kalbų yra SQL (Structured Query Language – struktūrizuota užklausų kalba). Tai gana paprasta kkalba su aiškiomis standartizuotomis instrukcijomis. Ši kalba įtraukta į daugumą DBVS. Plačiau SQL nagrinėjama tolesniuose skyriuose.

Modernios DBVS turi programų generatorius. Tai specialūs instrumentai, skirti automatizuoti programų rašymą, kartu palengvinti vartotojų, ypač programuotojų, darbą kuriant taikomąsias programas. Generatoriai įgalina žymiai sumažinti darbo sąnaudas, kai reikia programuoti daug laiko jų rašymui reikalaujančias ir dažnai pasikartojančias operacijas, pvz., ekrano apiforminimo, veiksmų (meniu) juostų, ataskaitų sudarymo ir kt. operacijas.

Darbo aplinka ir tipinis darbo scenarijus

DBVS, skirtų personaliniams kompiuteriams, dialoginės aplinkos standartiniai komponentai yra šie: ekranas, langas, piktogramos, pelės žymeklis. Ekrane matomi visi kiti komponentai. Lange yra: viena ar daugiau veiksmų juostų, darbinė sritis, mygtukai. Veiksmų juostose dedami arba veiksmų grupių pavadinimai, arba piktogramos.

1 pav. Darbo aplinkos pavyzdys

Reikalingos operacijos išsirenkamos žymekliu nurodant atitinkamą pavadinimą ar piktogramą. TTipinis darbo aplinkos vaizdas parodytas 1 pav. Minėti darbo aplinkos komponentai būdingi ne tik DBVS, bet ir daugeliui kitų taikomųjų sistemų. Įvairiose sistemose gali skirtis šių komponentų pateikimo stilius, veiksmų su jais forma.

2 pav. Tipinis darbo su duomenų baze scenarijus

Vartotojui dirbant DBVS aplinkoje, darbo scenarijus priklauso nuo sistemos ypatumų ir vartotojo ketinimų. Vis dėlto galima išskirti būdingus darbo su DB etapus, sudarančius tipinį darbo scenarijų. Svarbiausios tipinio scenarijaus dalys pavaizduotos 2 pav.

Iš pradžių projektuojama DB struktūra (šablonas). Po to bazė ggali būti užpildoma vartotojo duomenimis. Jeigu DB struktūra buvo sukurta anksčiau, tada prieš užpildant DB ją reikia atidaryti (padaryti prieinamą vartotojui). Prireikus DB galima redaguoti (taisyti). Darbo pabaigoje DB uždaroma ir tampa neprieinama tol, kol vėl iš naujo atidaroma.

Duomenų bazės kūrimas ir redagavimas

Pagrindiniai darbo su DB etapai yra šie:

q DB struktūros projektavimas;

q DB užpildymas;

q DB redagavimas.

Naujos DB kūrimas prasideda nuo bazės struktūros, t.y. bazės lentelių struktūros projektavimo. Formuojant atskiros lentelės struktūrą, nurodomi:

q lentelės laukų vardai;

q laukų reikšmių tipai;

q laukų pločiai.

Papildomai gali būti nurodyti ir kiti dalykai, pvz., nutylėtos laukų reikšmės, t. y. reikšmės, kuriomis laukas užpildomas automatiškai. Suformavus visų lentelių struktūrą, nustatomi raktiniai ir siejantys lentelių laukai, nustatomi ryšių, reikalingų lentelėms susieti į vientisą DB, tipai.

Baigus kurti DB struktūrą, bazė užpildoma konkrečiais vartotojo duomenimis. Vėliau DB tenka redaguoti (įterpti naujus įrašus, pasenusius duomenų elementus pakeisti naujais ir t. t.). DBVS leidžia redaguoti ir DB struktūrą, ir jos turinį, t. y. duomenų elementus. Redaguojant DB struktūrą, daugiausia tenka:

q pakeisti lauko tipą, plotį;

q įterpti papildomą lauką;

q pašalinti nebereikalingą lauką.

Čia pažymėtina, jog geriau iš karto detaliai apgalvoti ir suprojektuoti efektyvią DB struktūrą, kad vėliau netektų jos keisti. Žymiai dažniau reikia redaguoti DB turinį, o ne bazės struktūrą. Svarbiausios DB turinio redagavimo operacijos yra ššios:

q naujo įrašo įterpimas;

q atskiro lauko ar viso įrašo užpildymas konkrečiais duomenimis (reikšmėmis);

q įrašo laukų reikšmių modifikavimas;

q įrašo pašalinimas.

Šiomis operacijomis nesunku sukonstruoti kitas, sudėtingesnes operacijas. Pavyzdžiui, galima automatiškai pakeisti atskiro lauko reikšmes visoje lentelėje, išvalyti lauką ar net visą lentelę.

DB turiniui redaguoti labai plačiai naudojamos vadinamosios formos. Galimos formos pavyzdys parodytas 1 pav.

1 pav. Formos pavyzdys

Forma – tai tam tikras langas, skirtas vaizduoti ir redaguoti laukų reikšmes iš vienos ar kelių DB lentelių. Langas atitinkamai apipavidalinamas, laukų reikšmės jame išdėstomos laisva tvarka ir vaizduojamos vartotojui patogiu formatu. Forma – tai lyg savotiška prizmė, pro kurią žvelgiame į DB įrašus. Formoje turi būti ir duomenų vaizdavimo valdymo įrankiai, dar kitaip vadinami navigacijos įrankiais. Įrankiai pateikiami kaip tam tikri mygtukai su atitinkamais nurodymais, pvz., „pereiti prie tolesnio įrašo“, „redaguoti įrašą“ ir pan. Formos naudojamos ne tik DB redagavimui, bet ir užpildymui, peržiūrai.

Žinių bazių sistemų kūrimas

Daugeliui atrodo, jog žinių inžinerija tai sunkus informacijos apdorojimo darbas. Toks požiūris atsirado dėl įprastos (bendros) programinės įrangos neišbaigtumo, ji tiesiogiai sąlygoja žiniomis pagrįstų sistemų kūrimą. Tačiau panašumų tarp programinės įrangos ir žiniomis pagrįstų sistemų yra daugiau nei skirtumų. Taigi šio skyriaus tikslas apibrėžti ir išanalizuoti jų skirtumus ir panašumus.

Bendros programinės įrangos kūrimas. įprastos programinės įrangos kūrimas ttradiciškai apibrėžiamas krioklio modeliu. šį modelį sudaro šeši etapai (8.1 pav.):

Užduoties analizavimas. šiame etape užduotis (problema) analizuojama ar ji galėtų būti išsprendžiama skaičiavimo metodais. Norint įsitikinti ar ši programinės įrangos sistema pasiteisina, nustatomos sistemos išlaidos ir nauda.

Pav. 8.1 „Krioklio“ modelis programinės įrangos vystymui

Reikalavimų specifikacija. Ji paremta analize, gauta praeitame etape. Specifikacija yra apibendrintas dokumentas, apibrėžiantis sistemos rezultatus, kuriuos tikisi matyti vartotojai, t.y. skaičiavimo aplinką ir kitas priemones, įtakojančias galutinės sistemos vaizdą, o tuo pačiu ir sprendinio gavimo sėkmę.

Projektavimas. Tai pagrindinis etapas šiame cikle. Gerai suprojektuotą sistemą lengva realizuoti, testuoti, tikrinti ir palaikyti. Projektas pilnai atspindi specifikacijos reikalavimus, apima vartotojo interfeiso, kodo struktūras, taip pat visų sistemos dalių kompoziciją, kurios atitinkamai sukomponuotos tarpusavy sąlygoja teisingą ir pageidautiną sistemos veikimą.

Realizacija. Apima kodo rašymą ir derinimą kiekvienam moduliui, kurie vėliau apjungiami į vieningą sistemą. Gero projekto derinimas yra minimalus.

Testavimas. Užtikrina vystomos programinės įrangos atitikimą specifikacijai ir teisingą užduoties išsprendimą. Testavimas atliekamas arba dirbtinoje, arba realioje aplinkoje.

Palaikymas. šiam etapui būdingas sistemos modifikavimas po jos sukūrimo: ištaisomos klaidos, neaptiktos realizavimo ar testavimo etapuose; tobulinama programinės įrangos kokybė. Tai brangiausias etapas, reikalaujantis 30 – 80% visų pastangų, idėtų kuriant sistemą.

Krioklio modelio privalumu laikoma jo aiški,

žingsniais paremta, nuo sąvokos iki realizacijos, vystymo metodologija. Tačiau jo trūkumas yra cikliška (besikartojantis procesas) struktūra, turinti du nepageidautinus bruožus:

Nėra galimybės leisti klientui ar projektuotojui „pajausti“ kokia bus reali galutinė sistema, kadangi visa sistema yra baigiama prieš skaičiavimą ar vartotojo tikrinimą. Taigi koregavimas galimas tik realizacijos etapo gale.

Kadangi visa sistema yra sudaryta iš tarpusavyje susietų modulių, ji turi būti užbaigta ir patvirtinta prieš atiduodant ją klientui. Laiko tarpas tarp projektavimo ir sistemos realizacijos dėl to užsitęsia.

Kitas ppopuliarus bendros programinės įrangos vystymo modelis yra Boehm’o spiralinis modelis [Boehm, 1988]. šis modelis apima geriausius krioklio modelio bruožus, prototipo idėją ir rizikos analizės sąvoką (pav. 8.2). Modelis interpretuoja sistemos vystymą kaip tam tikros žingsnių sekos ciklišką kartojimą. šie žingsniai atliekami kiekviename vystymo proceso lygyje nuo pradinės operacijų dokumentacijos iki programos rašymo. Kiekvienas spindulys spiraliniame modelyje atspindi susikaupusias išlaidas, atitinkančias žingsnių kiekį kiekviename cikle, kurį kaip tik nurodo spindulio kampas su ašimi. Ciklą sudaro:

Identifikavimas. Nustatomi ciklo tikslai, galimos alternatyvos jjiems pasiekti ir kokios pasekmės būtų, panaudojus šias alternatyvas.

įvertinimas. Tiriami tikslai ir pasekmės, gautos panaudojus atitinkamas alternatyvas. Tai padeda aptikti ir panaikinti neaiškumus, o taip pat atskleisti slypinčią riziką.

Formulavimas. Vysto strategiją, kuri padėtų numatyti neaiškumus ir riziką, susijusius ssu administravimo klausimais, pastabomis, dirbtinų sąlygų ir/arba prototipų kūrimu.

Galutinis įvertinimas. Skaičiuojama kokia galima likusi rizika. įvertinama ar tinkamai pasirinkta vystymo strategija, ar reikia ją keisti.

Dauguma didelių programinės įrangos sistemų turėtų būti vystomos būtent pagal šį modelį, kuriame nuoseklus procesas atspindi programinės įrangos vystymo būvį, o rizikos analizavimas, identifikavimas, išskaičiavimas įgalina ją sumažinti kiekviename vystymo etape. Tačiau iš tikrųjų ir čia neapsieinama be nepageidautinų momentų:

Būtina įsitikinti, jog evoliucinis procesas yra valdomas.

Modelis per daug siejamas su rizikos įvertinimu. Jei negalima įvertinti rizikos ankstesniuose etapuose, tai pats sistemos kūrimas gali būti „užspaustas“ lygiai taip kaip dirbant pagal krioklio modelį.

Žinių bazių sistemų kūrimo skirtumai. Žinių bazių sistemos, kaip ir kita programinė įranga, turi tikslą sukurti kompiuterizuotą (skaičiavimo) sistemą specializuotiems uuždaviniams spręsti. Nors žinių bazių sistemos remiasi daugiau euristinėmis taisyklėmis nei algoritminėmis, jų kūrimas yra panašus į bendros programinės įrangos vystymą.

Pav. 8.3 Paradigmų pokytis

Tačiau tarp žinių bazių ir programinės įrangos inžinerijų yra keletas žymių skirtumų. Jeigu programinės įrangos inžinerija remiasi gerai žinomais ir griežtai apibrėžtais algoritmais, tai žinių inžinerija manipuliuoja plačiomis, nevienareikšmėmis, ne griežtai apibrėžtomis euristinėmis žiniomis, padiktuotomis toje srityje dirbančių ekspertų. Siekiant efektyvumo aiškėja, jog šios žinios turi būti kažkaip transformuojamos į matematinį (kompiuterinį) jų atvaizdavimą. Toks duomenų pperkėlimas vadinamas Žinių kaupimu.

Kitas žymus skirtumas susijęs su žinių prigimtimi ir kiekybe. Algoritmiškai uždavinys, įvertinantis žinių prigimtį ir kiekybę, išsprendžiamas pakankamai gerai, tačiau kitaip yra su žinių bazių sistemomis. Žinių prigimtį ir jų apimtį, reikalingus uždavinių sprendimui, vienareikšmiškai negali nusakyti net patys ekspertai. Kuriant žinių bazių sistemą dėl to atsiranda sunkumų, susijusių su sistemos kūrimo darbo imlumo numatymu. Tačiau svarbiau yra tai, kad jau ankstyvuose projektavimo etapuose gali iškilti sunkumų. Pastaroji situacija gali iššaukti taip vadinamą paradigmų pokytį (pav. 8.3).

Paradigmų (modelių) pokytis gali pasireikšti vystymo procese, kai žinių vaizdavimo struktūra, priemonės ir/ar kitos sistemos projektavimo detalės yra nepakankamai išvystytos. Tai gali būti rimta kliūtis, kai šis paradigmų pokytis pasireiškia progresyvaus vystymo etape. Tuomet žinių inžinierius turi nuspręsti ar tęsti vystymą su nepakankama infrastruktūra, kuri vėliau gali sukelti atitinkamus sunkumus, ar pradėti vystymą iš naujo su tikėtinai teisinga žinių struktūra ir/arba kitomis detalėmis. Bet kuris pasirinkimas gali prailginti projektavimo procesą ir pareikalauti daugiau projektuotojų pastangų.

Kad būtų įveiktos šios kliūtys ir žinios įgautų norimą prasmę (griežtą, aiškią), žinių bazių sistemų projektuotojai naudoja greitą prototipų sudarymą ir progresyvų kūrimą.

Greitam prototipų sudarymui naudojamas LISP’o ir PROLOG’o programavimo kalbos ir/arba kitų paketų priemonės, kurios leidžia greitai sukurti veikiantį įsivaizduojamos galutinės sistemos pprototipą. Tai garantuoja jau ankstyvame vystymo etape numatyti vartotojo poreikius, žinių diapozoną ir sprendimų, padarytų projektavimo etape, pateisinimą. Taigi, jei iškiltų paradigmų pokyčio grėsmė, tai ji mažiausiai priklausytų nuo ankstesnių vystymo etapų.

Pav. 8.4 žinių bazių sistemų kūrimas

Sudarant prototipus, analizavimo ir specifikacijos etapai turi būti atliekami tik įvertinus visą sistemą, tačiau projektavimas ir realizavimas įgyvendinami greičiau ir grubiau, nesigilinant į kai kurias detales. Todėl nepageidaujamu atveju grįžtama prie nagrinėjamo prototipo, o geriausiu atveju, jis šiek tiek pakoreguojamas, arba tenka jį (prototipą) keisti nauju, gilinantis į nenumatytus atvejus ar detales.

Tuo būdu, žinių bazių sistemų prasmingumas ir kokybė gali būti padidinami ir pagerinami, pasinaudojant vidinių prototipų sudarymais. Vidiniai prototipai gali būti kombinuojami, modifikuojami, keičiami, daug kartų, kol bus pasiektas norimas programos veikimo vaizdas. Toks procesas vadinamas progresyviu sistemos vystymu.

Progresyvus vystymas koncentruojasi ties dvejomis sąvokomis: dalinimas-ir-įgyvendinimas, kur žinios yra padalinamos, ir atskirtos jų dalys vystomos atskirai; ir nuoseklus kūrimas, kur dalinimas ir įgyvendinimas yra taikomas nuosekliai, įtraukiant įvairias sistemos dalis, kurios ir sudaro akcentuojamą problemą. Taip, imant, pridedant ir vystant atskiras, nepriklausomas dalis (t.y. modulius), galima žinių bazių sistemą padaryti dalinai funkcionalią ir netgi pateikti vartojimui, kai ji nėra užbaigta; tuo tarpu bendrosios programos, dėl jų procedūrinės prigimties, bendruoju atveju turi bbūti visiškai užbaigtos prieš pateikiant sistemą naudojimui.

Paveikslėlis (pav. 8.4) vaizduoja žinių bazių sistemos progresyvų vystymą. Kaip matoma žinių bazių vystymo procesas padalintas į dvi kategorijas, į kurias vienodai įeina projektavimo, realizavimo ir testavimo etapai. Deklaratyvi žinių, kuriomis manipuliuoja sistema, prigimtis leidžia palyginamai lengvą įvairių sistemos vystymo proceso kategorijų integraciją į galutinį rezultuojantį paketą.

Žinių bazių sistemų kūrimo etapai. Žinių bazių sistemų tobulinimas (kūrimas) priklauso nuo to, kokia bus pasirinkta vystymo strategija, t.y. koks modelis konkrečiai bus naudojamas pasiekti norimą tikslą. Vienas iš tokių modelių žinių bazių sistemoms kurti pavaizduotas pav. 8.4:

Užduoties analizavimas. Analizuojama užduotis (problema) ir nustatomi resursai (pvz., grupės nariai) ir probleminė sritis , kurioje bus taikytinas žinių bazės sistemos sprendinys. Sistemos pasiteisinimo atveju numatomos jos išlaidos ir nauda. Tai savo ruožtu reikalauja arba paklausos analizavimo, jei produktas skirtas specializuotai rinkai, arba detalaus tyrimo reaguojant į užsakovo (vartotojo) užklausas sistemos efektyvumo kainos nustatymui.

Reikalavimų specifikacija. Formalizuoti ir užrašyti kas buvo nagrinėjama ir studijuojama analizavimo etape. Kaip jau buvo minėta, specifikacija yra apibendrintas dokumentas, kuris apibrėžia sistemos rezultatus, kuriuos tikisi matyti vartotojai, t.y. skaičiavimo aplinką ir kitas priemones ir bruožus, įtakojančius galutinės sistemos sėkmę. Dėl euristinės žinių bazių prigimties, tokios sistemos daugiau išnaudoja reikalavimų specifikacijas, nei

tradiciniai programinės įrangos projektai; todėl šis etapas sudaro vieną pagrindinių dalių žinių bazių sistemos kūrime.

Preliminarus projektavimas. šis etapas remiasi aukštesniam lygyje priimtais sprendimais, būtinais pradėti vidinių prototipų sudarymą. čia galutinai įvardijami ekspertai ir numatomas žinių kaupimas, kurio pasekoje nustatomos žinių vaizdavimo paradigmos (modeliai) ir kitos prototipų sudarymui reikalingos priemonės.

Vidinių prototipų sudarymas ir įvertinimas. Tai esminis ir pagrindinis etapas, kadangi visi preliminarūs projektavimo darbai bus arba pasiteisinę, arba žinios, surinktos iš ekspertų, pasirodys nepakankamai apibrėžtos ar patikimos. Vidinis prototipas tturi atspindėti ir įgauti panašų į pilnos sistemos pavidalą, t.y. jis turi apimti pakankamai gerai išvystytą vartotojo interfeisą ir gruboką, iki tam tikros ribos, žinių poaibį, kad potencialus vartotojas galėtų nuspręsti apie žinių bazės kokybę. Jei yra padaryta klaidų preliminaraus projektavimo etape, tai čia jos surandamos ir ištaisomos.

Galutinis projektavimas. Apima konkrečių resursų ir priemonių, reikalingų vystomai sistemai, parinkimą. Žinių bazių sistemos skiriasi nuo bendrosios programinės įrangos dar ir tuo, kad šis etapas įtraukia ir žinių vaizdavimo pasirinkimą. Struktūrinių diagramų pplėtojimas nepriklauso nuo deklaratyvinės žinių bazių sistemų prigimties. Vis dėlto, keletas aukšto lygio nagrinėjamos sistemos architektūros apibrėžimų turi būti padaryta. Pavyzdžiui, jei tai būtų automobilinė diagnozavimo sistema, ji galėtų apimti tokius žinių modulius kaip kuro sistema, uždegimo sistema, aušinimo sistema, eelektrinė sistema, kt., ir kiekvienas iš šių modulių (subsistemų) būtų specifikuojamas atitinkamais atributais (duomenimis – įvedimo žiniomis) ir gautomis išvadomis.

Realizavimas. Tai daugiausiai laiko užimantis žinių bazių sistemų vystymo etapas, netgi ir tuomet, kai yra geras projektas. Realizavimas apima žinių užrašymo formalia kalba procesą visoms posistemėms.

Patvirtinimas ir patikrinimas (P&P) arba testavimas. Kadangi analizavimo objektas yra tas pats tiek bendroje programinėje įrangoje, tiek žinių bazių sistemų vystyme, jų tyrimo strategija testavimo atžvilgiu yra ta pati. Tik realizacijos etapo detalėse, pastebimas žymus skirtumas tarp šių dviejų (žBS ir BPįS) sistemų.

Projekto koregavimas. Kadangi darbų pradžioje numatyti visas smulkmenas ir problemas susijusias su vystoma sistema yra praktiškai neįmanoma, todėl darbų eigoje, kaip jau buvo minėta, dažnai tenka koreguoti einamąjį planą. Projekto korekcija vvyksta tol, kol gaunamas norimas sistemos pavidalas.

Palaikymas. šis etapas jau aptartas kai buvo kalbama apie bendrosios programinės įrangos sistemos vystymą (jis mažai kuo skiriasi nuo minėtojo).

Navigacijos duomenų bazėje priemonės

Dirbant su DB, vartotojui tenka nuolat „judėti“ DB, t. y. pereiti nuo vieno DB įrašo (lauko) prie kito. DBVS yra specialios navigacijos priemonės, užtikrinančios kuo didesnį to „judėjimo“ efekyvumą. Be navigacijos priemonių būtų neįmanomas joks DB tvarkymas. Prieš atliekant kurį nors veiksmą su DB įrašu, būtina lokalizuoti tą įrašą, kitaip ttariant, pereiti prie jo ir jį,“suaktyvinti“. Bet koks betarpiškas veiksmas įmanomas tik su aktyvaus įrašo duomenų elementais (žr. 1 pav.). Galima įsivaizduoti, kad aktyvus yra tas įrašas, į kurį konkrečiu momentu nukreipta tariamoji rodyklė (įrašų rodyklė).

1 pav. Aktyvaus lentelės įrašo pavyzdys

Navigacija bazėje atliekama pagal atitinkamus nurodymus. Nurodymai gali būti pateikti grafiniais, vizualiai orientuotais instrumentais arba parašytomis specialiomis instrukcijomis. Dirbant interaktyviai (pvz., koreguojant DB), paprastai pasirenkamas pirmas būdas. Vykdant navigaciją DB dažniausiai sutinkami tokie nurodymai:

q Pereiti prie nurodyto įrašo;

q Pereiti pirmyn, praleidžiant nurodytą įrašų kiekį;

q Grįžti atgal, praleidžiant nurodytą įrašų kiekį;

q Grįžti prie pirmojo įrašo;

q Pereiti prie paskutiniojo įrašo.

„Judėjimas“ DB gali būti absoliutinis ir santykinis. Pirmuoju atveju „judama“ nekreipiant jokio dėmesio į aktyviojo įrašo padėtį. Reikalingas įrašas surandamas pagal jo nurodytą numerį (pažymėtina, kad įrašai numeruojami pagal jų užpildymo, t. y. įvedimo, tvarką). Antruoju atveju atsižvelgiama į aktyviojo įrašo padėtį, „judama” būtent to įrašo padėties atžvilgiu, tarytum šio įrašo padėtis būtų atskaitos taškas. Šiuo atveju turi būti nurodomas ne tikslus įrašo numeris, o perėjimo į reikiamą įrašą žingsnio ilgis (atstumas). Reikia nurodyti ir kuria kryptimi eiti.

Navigacija DB atliekama labai efektyviai, kai naudojamas indeksinis failas. Šiuo atveju reikiamas įrašas išrenkamas pagal nurodytą reikšmę, esančią viename iš įrašo laukų. Tas laukas turi būti indeksuotas (turi būti sukurta atitinkama iindeksų seka).

Navigaciją DB patogu atlikti, pasitelkus į pagalbą formas.

Duomenų bazės rikiavimas ir indeksiniai failai

Labai dažnai DB įrašus reikia tam tikru būdu sutvarkyti, pvz., išdėstyti įrašus kurio nors lauko reikšmių didėjimo tvarka. Toks išdėstymas vadinamas rikiavimu (rūšiavimu). DB įrašus rikiuoti galima be jokių papildomų failų, panaudojant tik DB lentelių failus. Tačiau šiuo atveju turi būti sukuriama nauja DB kopija. O tai paprastai yra neefektyvu – sunaudojama daug atminties ir sugaištama nemažai laiko.

Žymiai efektyvesnis rikiavimas, sukuriant papildomus specialius failus, vadinamus indeksiniais failais. Toks rikiavimas dar vadinamas rikiavimu pagal indeksuotą lauką. Indeksuotas laukas yra tas DB laukas, pagal kurio reikšmes (duomenų elementus) rikiuojami bazės įrašai ir kuriam sudaroma įrašų indeksų seka. Jeigu DB turi bent vieną indeksuotą lauką, tai sakoma, kad ji yra indeksuota.

Indeksų seka – tai nuorodų į DB įrašus, surikiuotus pagal kurio nors lauko reikšmes, rinkinys, kuris įtraukiamas į indeksinį failą. Įrašai gali būti rikiuojami tų reikšmių didėjimo arba mažėjimo (abėcėlės ar atvirkščia) tvarka. Rikiuoti galima ir pagal reikšmės dalį (pvz., pagal pavardės pirmąją raidę) ar išraiškos rezultatą. Įrašus rikiuoti galima taip pat pagal kelių laukų reikšmes, t. y. pagal tų laukų išraiškos rezultatą.

Vienai DB, netgi atskirai lentelei, galime sudaryti daug indeksų sekų ir visas jas saugoti indeksiniame faile. Kiekviena indeksų sseka turi pavadinimą. Jis gali sutapti su lauko vardu. Jeigu indeksų faile yra daugiau negu viena indeksų seka, tai DB rikiuojama pagal aktyvią tuo momentu seką. Tuo pačiu metu gali būti aktyvi ne daugiau kaip viena indeksų seka (atskiru atveju visos sekos gali būti neaktyvios, tuomet DB nerikiuojama).

Naudojant indeksinį failą, į DB įrašus kreipiamąsi ne tiesiogiai, bet per indeksus, saugomus aktyvioje indeksinio failo indeksų sekoje. Indeksinio failo naudojimas 8.2 skyriaus 1 pav. pateiktai lentelei iliustruojamas 1 pav. Čia lentelės įrašai rikiuojami lauko „PIRKĖJO KODAS” reikšmių didėjimo tvarka (kai kodai vienodi, atsižvelgiama į jų įvedimo tvarką).

Rikiuojant pagal indeksuotą lauką, nereikia atlikinėti daug laiko reikalaujančių DB įrašų kopijavimo, perstatymo operacijų. Pakanka pertvarkyti tik indeksų seką. Indeksų seka sudaroma vieną kartą, o pertvarkoma tik tada, kai koks nors įrašas įterpiamas, modifikuojamas arba pašalinamas.

Svarbiausias indeksinio failo naudojimo privalumas tas, kad užtikrinama labai efektyvi duomenų paieška, atranka ir atskiroje lentelėje, ir visoje DB.

1 pav. Indeksinio failo naudojimas

Paieškos priemonės

Paieška yra manipuliavimo duomenimis operacija ar operacijų seka, kurios paskirtis – surasti konkrečius duomenis iš vienos ar kelių DB lentelių. Paieška yra viena svarbiausių manipuliavimo duomenimis operacijų. Daugelio kitų operacijų (įrašų modifikavimo, įterpimo, pašalinimo) neįmanoma atlikti be šios operacijos. Vartotojui labai aktualu atlikti paiešką greitai, patogiai,

lanksčiai. Paieškos greitis, galima sakyti, nulemia viso darbo su DB efektyvumą. Paiešką DB galima organizuoti: a) naudojantis grafiniais, vizualiai orientuotais instrumentais, b) rašant instrukcijas specialia kalba.

Šiuolaikinės DBVS turi labai tobulas grafines paieškos priemones. Kaip jau minėta, joms priskiriami specialūs grafiniai dizaineriai, meistrai ir meniu sistemos. Šiomis priemonėmis vartotojas gali surasti, atrinkti bet kokius jam reikalingus duomenis iš vienos ar kelių lentelių, taip pat vaizduoti juos norimu formatu. Vartotojui nereikia rašyti sudėtingų komandų, sistema pati „sufleruoja” galimus pasirinkimo variantus, tereikia tik iiš jų išsirinkti tinkamą.

Antrasis būdas daugiausia naudojamas sudarant taikomąsias programas. Paieškos instrukcijos rašomos konkrečia manipuliavimo duomenimis kalba arba specialia užklausų kalba, iš kurių, kaip minėta, populiariausia yra SQL.

Atsižvelgiant į paieškos vykdymo principą, skiriama paieška pagal įrašą ir paieška pagal indeksą. Pirmuoju atveju tikrinami pačios DB bazės įrašai. Jie nagrinėjami pradedant pirmuoju, nuosekliai, t. y. ta tvarka, pagal kurią jie buvo išdėstyti užpildant DB. Antruoju atveju nagrinėjami ne patys įrašai, o nuorodos į tuos įrašus – įrašų indeksai, kurie įtraukiami į iindeksinį failą. Pavyzdžiui, lokalizuojant pirmąjį surikiuotos lentelės įrašą, pakanka kreiptis į pradinį indeksą indeksiniame faile (žr. 1 pav.). Antruoju atveju paieška atliekama žymiai greičiau nei pirmuoju, ypač tada, kai pasitelkiami specialūs pagreitintos paieškos algoritmai, pvz., dvejetainio dalijimo algoritmas.

Galimos įvairios paieškos fformos. Tai – atskirų įrašų (laukų) paieška, įrašų grupių atranka, atranka su rikiavimu ir pan. Nurodymai konkrečių duomenų paieškai paprastai išreiškiami tam tikrais klausimais – užklausomis. Vienas lanksčiausių užklausos pavidalų yra vadinamoji užklausa pagal pavyzdį.

Užklausa pagal pavyzdį – tai apibrėžto formato klausimas su vienu ar keliais ieškomų duomenų elementų pavyzdžiais, pagal kuriuos atrenkami įrašai. Klausimas užrašomas kaip loginė išraiška (sąlyga). Sakysim, 8.2 skyriuje 1 pav. pateiktai lentelei galėtų būti suformuota tokia užklausos išraiška:

PIRKĖJO KODAS=«3-87022» («3-87022» šioje užklausoje yra duomenų elemento pavyzdys).

Užklausos rezultatus matome 1 pav.

1 pav. Užklausos rezultatų pavyzdys

Paieškos (užklausos) rezultatai gali būti įvairiai pateikiami. Juos galima išvesti į ekraną (laikinąjį peržiūros langą), naują sukuriamą lentelę, ataskaitą. Paieškos rezultatus galima išvesti ir į vadinamąją virtualiąją lentelę.

Virtualioji lentelė skiriasi nuo įprastos DDB lentelės tuo, kad ji nėra fiziškai, realiai saugoma išorinėje atmintyje. Tai laikinai pagrindinėje atmintyje saugoma lentelė. Virtualioji lentelė yra išvestinė lentelė, t. y. generuojama iš vienos ar kelių realių, fizinių lentelių laukų kaip atsakymas į pateiktą užklausą. Virtualios lentelės laukų reikšmės gaunamos tiesiog perkeliant jas iš vienos ar kelių fizinių lentelių, tačiau atliekant įvairias operacijas su fizinių lentelių laukų reikšmėmis galima gauti ir išvestines reikšmes. Laukai, sudaryti iš tokių išvestinių reikšmių, vadinami skaičiuojamais (apskaičiuojamais) laukais.

Atskirai reikėtų paminėti vadinamąsias kryžmines uužklausas. Paprasčiausiu atveju sudarant kryžminę užklausą operuojama su viena lentele – užklausos išeities lentele. Iš pradžių pasirenkamas bazinis laukas, t. y. laukas, kuris bus lauku ir užklausos rezultatų lentelėje. Antrame žingsnyje nurodomas išeities lentelės laukas, pagal kurio reikšmes generuojami rezultatų lentelės skaičiuojami laukai. Trečiame žingsnyje apibrėžiama rezultatų lentelės laukų reikšmių apskaičiavimo taisyklė. Pabrėžtina, kad formuoti kryžmines užklausas tikslinga tik tokioms lentelėms, kuriose yra laukai su ribota diskrečių reikšmių aibe.

Filtrai

Dažnai tenka operuoti ne su visa DB, o tik su jos dalimi. Tokiais atvejais naudojami filtrai. Filtras leidžia dalį įrašų „paslėpti”. Tokių įrašų negalima peržiūrėti, atlikti su jais kitų operacijų. Operacijos atliekamos su aktyviais įrašais, t. y. su įrašais, kurie nėra „paslėpti”. Atrinkti atskirus įrašus įmanoma ir naudojant duomenų manipuliavimo kalbos instrukcijas. Tačiau instrukcija yra susieta su DB apdorojančia programa, bet ne su pačia DB. Filtras gi yra susietas su DB, galima sakyti, yra savotiška DB savybė. Filtras veikia kiekvieną kartą, kai tik kreipiamasi apdoroti DB. Tai nepriklauso nuo apdorojimo būdo, t. y. nuo to, ar DB apdorojama interaktyviu būdu, ar programiškai.

Filtras aprašomas, naudojant loginę išraišką (sąlygą). DB įrašai, kuriems ta sąlyga tenkinama, „praeina pro filtrą” ir dalyvauja apdorojime, likusieji įrašai tampa „nematomais”. Konkretaus filtro pavyzdys galėtų būti filtras UŽSAKYTAS KIEKIS<=15.

2 pav. FFiltro veikimo pavyzdys

Šiuolaikinėse DBVS yra ir kitos, dar lankstesnės priemonės – tai kontroleriai, trigeriai, saugomosios procedūros. Kontroleris yra tokia lentelės savybė, kuri leidžia automatiškai atlikti iš anksto nurodytus veiksmus įvedant ar taisant atskirus duomenų elementus. Trigeris įgalina įjungti atitinkamas veiksmų sekas įvedant, modifikuojant ar pašalinant atskirus DB įrašus. Saugomoje kartu su DB procedūroje talpinamas instrukcijų rinkinys (programos fragmentas), kuris gali būti iškviestas iš kontrolerio, trigerio ar vartotojo programos.

Ataskaitų kūrimas

Ataskaita yra tam tikro formato dokumentas, kuriame atvaizduotas visos DB ar jos atskirų dalių turinys. Pagrindinė ataskaitos paskirtis – pateikti duomenis (rezultatus) patogioje vartotojui formoje, t.y. taip, kad juos būtų galima lengvai analizuoti, apibendrinti ir padaryti teisingas išvadas. DBVS įgalina gana paprastai sukurti ataskaitą. Į ataskaitą įmanoma įtraukti duomenis iš kelių tarpusavyje susietų lentelių, taip pat ir iš virtualiųjų lentelių. Duomenis leidžiama įvairiai rūšiuoti, grupuoti, atlikti su jais įvairius skaičiavimus. Paruošta ataskaita gali būti peržiūrima kompiuterio ekrane, išsaugoma išorinėje atmintyje kaip atskiras failas, spausdinama popieriuje, po to įvairiais būdais dauginama. Ataskaitą galima sukurti dviem būdais:

q Naudojantis standartinėmis formomis;

q Pačiam vartotojui pasirenkant ataskaitos formą.

Pirmasis būdas gerokai apriboja vartotojo pasirinkimą, kadangi ataskaita kuriama pagal sistemos siūlomą formatą. Žymiai daugiau galimybių atsiranda formuojant ataskaitą antruoju būdu. Čia vartotojas gali laisvai pasirinkti jam priimtiniausią ataskaitos formatą. Be to, įį pagalbą ateina tam tikslui skirti specialūs instrumentai – ataskaitų dizaineriai. Modernios DBVS taip pat leidžia duomenis pateikti įvairiausių formatų diagramų pavidalu.

Kiekviena ataskaita turi tam tikrą struktūrą, į kurią privalu atsižvelgti. Ataskaitoje išskiriamos tokios trys zonos: antraštės zona, pagrindinė zona, pabaigos zona. Antraštės zonoje rašoma informacija, kuri turi būti viso dokumento pradžioje. Jei dokumentą sudaro keli puslapiai, tai nurodoma ir informacija, kuri turi būti kiekvieno puslapio pradžioje. Pagrindinė zona apima eilutes, kurios dažniausiai vaizduoja vieną duomenų bazės įrašą. Ataskaitos pabaigos zona analogiška antraštės zonai, tik jos turinys vaizduojamas dokumento (ar puslapio) pabaigoje. Ataskaitos pavyzdys pateiktas 1 pav.

1 pav. Ataskaitos pavyzdys

Taikomųjų programų kūrimas, užklausų kalba SQL

DBVS skirtos tenkinti įvairius vartotojų poreikius. Konkretiems poreikiams įgyvendinti dažnai nepakanka dialoginių-interaktyvių priemonių. Sprendžiant iškilusius specifinius uždavinius, tenka kurti taikomąsias vartotojo programas. Šios programos kuriamos, naudojant duomenų aprašymo ir manipuliavimo jais kalbą, kitaip vadinamą programavimo kalba. Į įvairių DBVS sudėtį įeinančios programavimo kalbos skiriasi savo struktūra, sintakse ir galimybėmis. Programavimo kalbas priimta klasifikuoti į žemo ir aukšto lygio kalbas. Šiuo metu DBVS naudojamos aukšto lygio programavimo kalbos, kurios savo ruožtu skirstomos į vadinamąsias trečiosios ir ketvirtosios kartos kalbas. Pastarosiose nedetalizuojama, kaip būtent duomenys turi būti gaunami ir apdorojami (tai būdinga 3-osios kartos kalboms).

Čia svarbu, kad vartotojas galėtų sau patogia forma nurodyti, kokie duomenys jam reikalingi. Atskirai paminėtinos užklausų kalbos, skirtos aprašyti tik manipuliavimo duomenimis operacijas (be jokių kitų papildomų galimybių). Viena tokių kalbų, kaip minėjome, yra SQL.

Ketvirtosios kartos programavimo kalbos suteikia vartotojui galimybę kurti taikomąsias programas, kuriose galima:

q aprašyti DB struktūrą;

q sudaryti specialias formas, skirtas duomenų įvedimui, peržiūrai, modifikavimui;

q kurti įvairių lygių meniu sistemas;

q įvairiai manipuliuoti duomenimis;

q atlikti matematinius-statistinius skaičiavimus;

q generuoti reikiamo formato ataskaitas;

q apdoroti užklausas, pateikiamas SQL kalba;

q panaudoti objektiškai orientuoto programavimo ((OOP) technologijas.

Ketvirtosios kartos programavimo kalbos pavyzdžiu galima nurodyti Foxpro programavimo kalbą. Ši kalba leidžia vartotojui-programuotojui ne tik manipuliuoti DB, bet ir sukurti patogią bendravimo sąsają naudojant langus, specialias formas bei meniu sistemą. Foxpro kalba taip pat leidžia organizuoti ciklinius (pasikartojančius) ir išsišakojančius skaičiavimus, pasitelkus atitinkamas kalbos konstrukcijas. Dažnai reikalingiems veiksmams ir tų veiksmų sekoms atlikti vartojami kreipiniai į vadinamąsias standartines funkcijas. Yra labai daug įvairiausios paskirties funkcijų – tai matematinės funkcijos, simbolių ir tekstų apdorojimo funkcijos, datos funkcijos ir tt. t. Leidžiama sudaryti ir vadinamąsias vartotojo funkcijas. Naudodamasis atitinkamomis konstrukcijomis, programuotojas gali išskaidyti savo programą į atskirus modulius (procedūras).

Toliau trumpai apžvelgsime standartinę užklausų kalbą SQL. SQL kalboje numatytos šios pagrindinės manipuliavimo duomenimis instrukcijos (komandos): DB kūrimas, paieška DB, duomenų mmodifikavimas, įrašo įterpimas į DB, įrašo pašalinimas.

Nauja DB lentelė sukuriama naudojant „CREATE” instrukciją. Šios instrukcijos supaprastintas formatas yra toks:

CREATE TABLE duomenų_bazės_lentelės_vardas (lauko_vardas_1 tipas [ (plotis [, tikslumas ]) ] [, lauko_vardas_2 . ] );

čia: CREATE – instrukcijos pavadinimas,

TABLE – bazinis žodis, nurodantis, jog kuriama nauja lentelė (konkretus lentelės vardas rašomas po šio žodžio).

Instrukcijoje nurodoma, kokie būtent laukai sudarys kuriamą lentelę. Kiekvieną lauką apibūdina to lauko tipas, lauko plotis ir, jeigu reikia, tikslumas (skaitmenų kiekis po kablelio). Lauko charakteristikos rašomos lenktiniuose skliausteliuose. Simboliai „[” ir „]” nurodo, kad tarp jų esanti instrukcijos dalis nėra būtina, jos galima nerašyti. Instrukcijos pavyzdys:

q CREATE TABLE a (u_numeris N(3), p_kodas C(7), pr_kodas C(5), data D);

q pagal ją bus sukurta nauja, tuščia A lentelė, kurią sudarys 4 laukai: sskaitmeninis laukas U_NUMERIS (lauko plotis – ne daugiau kaip 3 skaitmenys), simbolių laukas P_KODAS (lauko plotis – ne daugiau kaip 7 simboliai), simbolių laukas PR_KODAS (lauko plotis – 5 simboliai), datos tipo laukas DATA.

SQL kalboje duomenų paieškos ir atrankos instrukcijos supaprastintas formatas yra toks:

SELECT laukų vardų sąrašas | *

FROM duomenų_bazės_lentelės_vardas

[WHERE paieškos sąlyga];

čia: SELECT – instrukcijos pavadinimas,

FROM – bazinis žodis, po kurio nurodoma, kurioje lentelėje daryti paiešką,

WHERE – bazinis žodis, apibrėžiantis paieškos sąlygą, t. y. kriterijų, kurį turi tenkinti ieškomi dduomenys.

Simbolis „|” reiškia, kad instrukcijoje galima nurodyti tik vieną iš alternatyvų, t . y. arba laukų vardų sąrašą, arba simbolį „* ”. „* ” nurodo, jog reikia pateikti visų duotos lentelės laukų reikšmes. Taigi parašius instrukciją „SELECT”, iš lentelės bus atrinktos nurodytų laukų reikšmės, kurios tenkina pateiktą paieškos sąlygą. Instrukcijos pavyzdys:

SELECT * FROM b WHERE p_kodas=„1-12693”;

pagal ją „B” lentelėje bus surastas pirkėjas, kurio kodas „1-12693”.

DB lentelės laukų reikšmės modifikuojamos naudojant „UPDATE” instrukciją. Instrukcijos formatas:

UPDATE duomenų_bazės_lentelės_vardas

SET lauko_vardas_1=išraiška_1 [, lauko_vardas_2=išraiška_2 . ]

[WHERE paieškos sąlyga];

čia: UPDATE – instrukcijos pavadinimas,

SET – bazinis žodis, po kurio nurodoma, kokių laukų reikšmės ir kaip keičiamos (galima pakeisti konstanta ar išraiškos rezultatu).

Jeigu nurodytas bazinis žodis „WHERE” su paieškos sąlyga, tai keitimas atliekamas tik tuose įrašuose, kurie tenkina duotąją sąlygą. Priešingu atveju keičiamos visų įrašų laukų reikšmės. Pavyzdys:

UPDATE c SET kaina=kaina* 4.00;.

Naujas įrašas įterpiamas į DB lentelę, naudojant „INSERT” instrukciją. Jos formatas toks:

INSERT INTO duomenų_bazės_lentelės_vardas [(laukų vardų sąrašas)]

VALUES (laukų reikšmių sąrašas);

čia: INSERT – instrukcijos pavadinimas,

INTO – bazinis žodis, po kurio nurodoma, kurioje lentelėje įterpti naują įrašą,

VALUES – bazinis žodis, po kurio surašomos laukų reikšmės, išdėstytos reikiama tvarka.

Naujasis įrašas įterpiamas lentelės pabaigoje (po paskutiniojo lentelės įrašo). Instrukcijos pavyzdys:

INSERT INTO a (u_numeris, p_kodas, pr_kodas, data)

VALUES (6, „3-12908”, „A7340”, {98 01 30});.

Įrašo aar jų grupės pašalinimo iš lentelės instrukcija užrašoma taip:

DELETE FROM duomenų_bazės_lentelės_vardas

[WHERE paieškos sąlyga];

čia: DELETE – instrukcijos pavadinimas,

FROM – bazinis žodis, nurodantis, kurioje lentelėje pašalinti įrašą(us)

WHERE – bazinis žodis, apibrėžiantis sąlygą, kurią turi tenkinti pašalinami įrašai.

Ryšys su kitomis programomis

DBVS neizoliuotos nei viena nuo kitos, nei nuo kitų taikomųjų programų. Yra įvairių priemonių, leidžiančių atskiroms DBVS bendrauti tarpusavyje bei palaikyti ryšį su kitomis programomis, sistemomis. Pagrindiniai ryšio tarp DBVS ir kitų taikomųjų programų mechanizmai yra šie:

q dinaminis apsikeitimas duomenimis;

q objektų susiejimas ir įdiegimas.

Dinaminis duomenų apsikeitimas (angliškai DDE – Dynamic Data Exchange) įgalina perduoti duomenis iš vienos programos į kitą. Programa, kuri inicijuoja ryšį ir kreipiasi į kitą programą, vadinama klientu, o programa, kuri atsako klientui ir jį aptarnauja, vadinama serveriu. DBVS gali atlikti ir kliento, ir serverio vaidmenį. Atlikdama kliento vaidmenį, DBVS gali kreiptis į kitą programą, pasiųsti vienus duomenis į tą programą bei gauti iš jos kitus duomenis. Pavyzdžiui, DBVS gali kreiptis į skaičiuoklę ir gauti duomenis, saugomus elektroninėje lentelėje, arba kreiptis į teksto procesorių ir gauti duomenis, saugomus tekstiniame dokumente. Kita vertus, DBVS gali perduoti duomenis į elektroninę lentelę arba į dokumentą. Atlikdama serverio vaidmenį, DBVS suteikia galimybę kitoms programoms kreiptis į DB, jos lenteles ar atskirus duomenų elementus. Šiuo aatveju kita programa gali duomenis siųsti sau arba juos pakeisti. Kad klientas ir serveris galėtų apsikeisti duomenimis, jie abu turi būti aktyvūs, t. y. atitinkamos programos paleistos vykdyti.

Susiejimo ir įdiegimo mechanizmas (angliškai OLE – Object Linking and Embedding) leidžia DB lentelėse saugoti įvairiausius objektus – tekstus, grafinius vaizdus, video-vaizdus ir pan. Tokie objektai saugomi atitinkamo tipo laukuose. Objektas gali būti sukurtas ne DBVS, o kurios nors kitos taikomosios programos – serverio. Galimi du variantai: a) DB saugoma tik nuoroda į objektą, sukurtą programos-serverio, b) DB talpinamas pats objektas. Procesas, kurio metu į DB įtraukiama nuoroda į objektą, vadinamas susiejimu, o procesas, kurio metu į DB įtraukiamas pats objektas, vadinamas objekto įdiegimu. Įterpiant į DB susiejamą/įdiegiamą objektą ar jį koreguojant, automatiškai iškviečiama ta programa (serveris), kurios pagalba šis objektas buvo sukurtas. Taigi DB galima saugoti įvairialypius duomenis, paruoštus skirtingomis taikomosiomis programomis, pvz., teksto procesoriais, grafiniais redaktoriais ir kt.

Paminėtinas dar vienas DBVS dažnai naudojamas mechanizmas – duomenų eksportas-importas. Šiuo mechanizmu viena DBVS gali paruošti duomenis kitai DBVS arba priimti duomenis iš kitos DBVS.

Duomenų bazių taikymas

DB labai plačiai taikomos įvairiausiose srityse. Beveik neįmanoma surasti srities, kur paprastos ar sudėtingesnės DB būtų nenaudojamos, o tuo labiau nereikalingos. Ypač sunku įsivaizduoti šiuolaikinės firmos darbą be

DB panaudojimo. Reikia išskirti atskiras organizacijas, įstaigas, kurioms DB itin reikalingos. Tai:

q bankai;

q bibliotekos;

q prekybinės firmos;

q darbo biržos;

q muitinės ir kt.

Minėtose, taip pat kitose didelėse firmose, organizacijose yra tokios praktinės veiklos sritys, kuriose išsiversti be DB tiesiog negalima. Pagrindinės tokios veiklos sritys yra šios:

q gamybos valdymas ir planavimas;

q prekyba;

q buhalterija;

q materialinių vertybių apskaita;

q personalo apskaita ir kt.

1 pav. Firmos veiklos schema

Panagrinėkime, pavyzdžiui, DB naudojimą kurios nors firmos veikloje, susijusioje su prekyba. Tarkime, kad firma parduoda tam tikro asortimento prekes pagal uužsakymus. Tokioje firmoje yra skyrius, kurio specialistai sudaro siūlomų parduoti prekių katalogą. Katalogas išplatinamas potencialiems pirkėjams. Su klientais, nusprendusiais įsigyti prekę, bendrauja užsakymų tarnyba. Firmos vidaus tarnyba koordinuoja atskirų vykdytojų darbą. Supaprastinta firmos veiklos schema pateikta 1 pav.

Pardavimo procesas vyksta pagal tokią schemą. Pirkėjas iš firmos siūlomų prekių katalogo užsisako norimą prekę. Firmos atstovas (pardavėjas) išrašo pirkėjui sąskaitą ir tuo pat metu išsiunčia užsakymą nurodytos prekės tiekėjui (gamintojui), su kuriuo firma yra sudariusi atitinkamą sutartį. Pirkėjui apmokėjus sąskaitą, firma įsipareigoja pper nustatytą terminą pristatyti prekę klientui. Pardavimo procese dalyvauja šie informaciniai objektai: klientai, prekės, pardavėjai, užsakymai, sąskaitos. Kiekvieną iš šių informacinių objektų apibūdina atitinkami atributai:

q klientai – KLIENTO_KODAS (KK), KLIENTO_VARDAS (KV), KLIENTO_PAVARDĖ (KP), ADRESAS (AD), TELEFONAS (TE);

q prekės – PREKĖS_KODAS (PR), PAVADINIMAS ((PV), GAMINTOJAS (GA), PAGAMINIMO_DATA (PD), KAINA (KA);

q pardavėjai – PARDAVĖJO_KODAS (PK), VARDAS (VA), PAVARDĖ (PA);

q užsakymai – UŽSAKYMO_NUMERIS (UN), KLIENTO_KODAS, PREKĖS_KODAS, PARDAVĖJO_KODAS, UŽSAKYMO_DATA (UD), UŽSAKYTAS_KIEKIS (UK);

q sąskaitos – SĄSKAITOS_NUMERIS (SN), KLIENTO_KODAS, PREKĖS_KODAS, DATA (DA), SUMA (SU);

čia: DA – sąskaitos apmokėjimo data, SU – mokėjimų už konkrečias prekes suma.

2 pav. Duomenų bazės struktūros diagrama firmos prekybinei veiklai

Ryšiai tarp atskirų informacinių objektų turi būti įvesti atsižvelgiant į šias sąlygas: a) vienas klientas gali užsisakyti daug prekių; b) vienas pardavėjas gali apiforminti daug užsakymų; c) to paties pavadinimo prekė gali būti užsakyta kelių klientų. Turint galvoje minėtas aplinkybes, sudaroma DB struktūros stačiakampė diagrama (žr. 2 pav.).

Pervedus šią stačiakampę diagramą į reliacinį modelį, gaunama firmos pardavimų DB, kurią sudaro tokios lentelės:

KLIENTAI(KK, KV, KP, AD, TE);

PREKĖS(PR, PV, GA, PPD, KA);

PARDAVĖJAI(PK, VA, PA);

UŽSAKYMAI(UN, KK, PR, PK, UD, UK);

SĄSKAITOS(SN, KK, PR, DA, SU).

Normalizavimo metu lentelė UŽSAKYMAI išskaidoma į lenteles UŽSAKYMAI ir UŽSAKYTI_KIEKIAI:

UŽSAKYMAI(UN, KK, PK, UD);

UŽSAKYTI_KIEKIAI(UN, PR, UK).

Lentelė SĄSKAITOS išskaidoma į lenteles SĄSKAITOS ir SĄSKAITŲ_APMOKĖJIMAS:

SĄSKAITOS(SN, KK, DA);

SĄSKAITŲ_APMOKĖJIMAS(SN, PR, SU).

Populiarių duomenų bazių valdymo sistemų palyginimas

Yra daugybė DBVS. Jas kuria įvairios firmos, kurios šias sistemas platina tarp vartotojų kaip atskirus, savarankiškus programinės įrangos vienetus. Tokie vienetai vadinami paketais. DB valdymo paketai skiriasi vieni nuo kitų kokybinėmis ir kiekybinėmis (techninėmis) charakteristikomis. Kokybinės DBVS charakteristikos &– tai apimtis (sudėtingumo laipsnis), taikymo sritis, funkcionavimo bazė, darbo patogumas. Kiekybinės charakteristikos – tai, pvz., leistina apdorojamos DB apimtis, DB lentelių skaičius, lentelės apimtis ir pan. Vienas iš pagrindinių sistemų klasifikavimo kriterijų yra sistemų apimtis. Pagal savo apimtį DBVS galima suskirstyti į dideles (labai sudėtingas) sistemas, vidutines (mažiau sudėtingas) sistemas ir mažas sistemas. Didelės DBVS yra šios: Oracle, Sybase, Informix, DB2, SQL Server, IMS, Ingres. Vidutinių sistemų yra daugiau. Pagrindinės yra šios: Foxpro, Access, Paradox, Clipper, Clarion, dBase ir kt. Dar daugiau yra mažų DBVS – jų šiuo metu suskaičiuojama daugiau kaip 50.

Didelės apimties, kompleksinės DBVS paprastai reikalingos stambioms organizacijoms, kompanijoms, bankams. Vidutinės sistemos tinka smulkesnėse įmonėse, įstaigose, firmose. Jos gali būti naudojamos ir atskiruose stambių organizacijų padaliniuose, filialuose. Beje, Lietuvoje populiariausia DBVS yra Foxpro (1998 m. žiniomis).

Daugumos šiuolaikinių DBVS funkcionavimo bazė yra personaliniai kompiuteriai. Visos didelės sistemos, be to, dar gali funkcionuoti ir minikompiuteriuose bei super-kompiuteriuose. Paprastai visi DB valdymo paketai yra orientuojami į darbą Windows tipo operacinėse sistemose, būtent, Windows NT, Windows 95 ir pan. Dideli paketai gali veikti ir operacinėse sistemose, skirtose superkompiuteriams, pvz., Unix, VAX VMS, OS/2.

Kalbant apie darbo patogumą pažymėtina, jog vienose sistemose siekiama suteikti kuo lankstesnes, vaizdesnes grafinės sąsajos galimybes, o kitose sistemose ppagrindinis dėmesys skiriamas tam, kad būtų kuo daugiau manipuliavimo duomenimis priemonių. Pirmosios sistemos daugiau orientuojamos į vadinamuosius galutinius vartotojus (ne į programuotojus). Antrosios sistemos orientuojamos į kvalifikuotus vartotojus (programuotojus).

1 lentelė. Duomenų bazių valdymo sistemų kiekybinės charakteristikos

DBVS Lentelių kiekis Lentelės dydis Lentelės plotis Laukų kiekis Lauko plotis

Oracle — — priklauso nuolaukų pločių 254 2 GB

Sybase 2·109 priklauso nuoOA dydžio priklauso nuoOA dydžio 250 1962 baitai

Informix 477·106 64 TB 32767 baitai 2767 32767 baitai

DB2 priklauso nuo OA dydžio 64 GB priklauso nuoOA dydžio 255 4005 baitai

SQL Server 2·109 2 TB 2048 baitai 250 255 baitai

FoxPro — 2 GB 65500 baitų 255 254 baitai

Access — 1 GB — 255 255 baitai

Pagrindinės kiekybinės DBVS charakteristikos yra šios:

q maksimalus leistinas lentelių kiekis DB;

q maksimalus lentelės dydis;

q maksimalus įrašų kiekis lentelėje;

q maksimalus simbolių kiekis įraše (lentelės plotis);

q maksimalus laukų kiekis lentelėje;

q maksimalus lauko plotis;

q maksimalus lauko vardo ilgis ir kt.

Kai kurių DBVS konkrečios kiekybinės charakteristikos parodytos 1 lentelėje (čia pateikiami 1996-97 m. duomenys). Lentelėje panaudoti pažymėjimai: OA – operatyvioji atmintis, GB – gigabaitas, TB – terabaitas.

Access 2002 apžvalga

Ir patyrusiems duomenų bazių vartotojams, ir naujokams 2002 Microsoft Access versija leidžia kurti galingas, lengvai susiejamas duomenų bazes, kurios lengvai integruojamos į internetą ir įmonės duomenų struktūrą. Stebėti pardavimo įrašus, inventoriaus dinamiką – kokie bebūtų Jūsų poreikiai, Access 2002 padės Jums dirbti efektyviau.

Access 2002 padeda nepaprastai lengvai sukurti galingas duomenų bazių priemones ir pasiekti bei analizuoti svarbią informaciją.

Paprastai atliekama sudėtingiausia duomenų analizė Keiskite duomenų analizavimo būdą. Lengva kurti ir ppublikuoti interaktyvias skaičiuokles bei naudoti Microsoft PivotTable® ir Microsoft PivotChart® suvestinių rodinius svarbiai informacijai dinamiškai pateikti skirtingais būdais, ir visa tai galima atlikti neišeinant iš programos Access.

Lengvas darbų pataisymas ir atkūrimas Dabar galite anuliuoti ir perdaryti daug veiksmų, kad galėtumėte produktyviai kurti formas, ataskaitas, duomenų prieigos puslapius, makrokomandas bei modulius.

Formų ir ataskaitų įtraukimas į tinklapius Naudodamiesi jau žinomais įrankiais leiskite savo duomenis bendrai naudoti Voratinklyje. Įrašykite formas ar ataskaitas kaip Duomenų prieigos puslapį, kuriame vartotojas su savo naršykle galėtų peržiūrėti ir redaguoti aktyvius duomenis.

Vertingi Voratinklio įrankiai Jei norite atsisiųsti šablonų, įrankių, patarimų ir naujinimų, padedančių dirbti greičiau, aplankykite Office Tools svetainę Voratinklyje.

Pasinaudokite naujais galingais publikavimo įrankiais, kurie leidžia eksportuoti duomenis ir formatavimą į tinklapį, naudojant interneto standartus, pvz., praplečiamąją dokumentų aprašų kalbą XML.

Sąveika su savo duomenimis dirbant Internete Susikurkite galingus duomenų prieigos puslapius ir galėsite lengvai atidaryti, peržiūrėti ir naujinti aktyvius duomenis Interneto naršyklėje, kur bebūtumėte – įstaigoje ar kelyje.

Tinklapių kūrimo pagreitinimas Galinga ir paprasta duomenų prieigos puslapių kūrimo programa Data Access Page Designer leidžia dar lengviau tinklapyje publikuoti interaktyvias formas bei ataskaitas. Pasinaudokite patobulinimų privalumais, pvz., sudėtinio pažymėjimo, kartotinio anuliavimo (Multiple Undo) bei perdarymo (Redo) pasirinktimis ir patobulintu valdiklių dydžių

keitimu.

XML privalumai publikuojant ataskaitas Dabar galite greitai publikuoti Access ataskaitas tinklapyje, naudodami interneto standartus atitinkančias XML ir XSL kalbas, leidžiančias vartotojams peržiūrėti ataskaitas Voratinklio naršyklėje, palaikančioje HTML 4.0.

Access 2002 teikia programų kūrėjams įrankius, reikalingus galingoms ir sudėtingoms Microsoft SQL Server™ duomenų bazių priemonėms kurti naudojantis gerai žinoma Access sąsaja. Dirbdami savo priemonėmis programų kūrėjai dabar gali naudoti XML duomenis, pasinaudodami naujomis XML kalbos palaikymo galimybėmis programoje Access.

Vientisa SQL Server duomenų integracija Nauji įrankiai padidina galimybę pasiekti informaciją iš bendrojo lygio ggalinių duomenų bazių, pvz., iš SQL Server serverio. Access duomenų bazių projektai leidžia kurti patikimas kliento/serverio programas, naudojantis jau žinoma Access sąsaja.

Lengvas SQL Server objektų valdymas Kurkite savo priemonėms skirtus SQL Server objektus, naudodami grafinę užklausų kūrimo programą Query Designer ir įsimintųjų procedūrų kūrimo programą Stored Procedure Designer. Kad galėtumėte tai padaryti, jums nebūtina būti SQL Server žinovu.

Didžiulės XML kalbos galimybės Pasinaudojant vos keliomis paprastomis komandomis XML duomenis lengva importuoti į Access (Jet) arba SQL Server duomenų bazę. Publikuoti dduomenis XML kalba taip pat paprasta: eksportuokite lentelę, ataskaitą arba užklausą ir įtraukite pateikimui skirtą susijusį XSL failą.

Pavyzdys

Užduotis: Sudarykite užrašų knygelę savo draugų, į kurią įeitų: Vardas, Pavardė, Gimimo data, Telefono Nr., Elektroninio pašto adresas.

Atlikimo eiga:

1. Pasileisti Microsoft Accsess programą:

Start // Programs / Microsoft Access.

(Jei automatiškai atsidarys koks pasikalbėjimo langelis jį uždarykite )

2. Susikuriam nauja failą:

File/New;

Pasirenkame Detabase

3. Failui priskiriame vardą:

Eilute File name: įrašome vardą Adresai.mdb

4. Sukuriame lentelę:

Su pele pasirinkti Table; Create table in Designe view

Su pele pasirinkti Designe view

(nenaudoti lietuviškų rašmenų)

5. Sukuriame lentelės viršutinės eilutės pavadinimus:

Eil_Nr Vardas Panarde Gimimo diena Tel_Nr e-mail

Stulpelyje Field Name rašome Eil_Nr ir klaviatūroje

Su pele paspaudžiam šalia žymeklio atsiradusią rodykle ir pasirenkame AutoNumber

Stulpelyje Field Name rašome Vardas ir klaviatūroje

Stulpelyje Field Name rašome Pavarde ir klaviatūroje

Stulpelyje Field Name rašome Gim_data ir klaviatūroje

Eilutėje Field Size įrašole 30; su pele grįžtame į stulpelį Field Name

Stulpelyje Field Name rašome Tel_Nr ir klaviatūroje

Eilutėje Field Size įrašole 30; su pele grįžtame į stulpelį Field Name

Stulpelyje Field Name rašome e-mail ir klaviatūroje <

6. Pasirenkame pagrindinį laukelį:

Su pele (и) pažymime eilute Eil_Nr ir iš menių pasirenkame:

Edit/Primary Key

7. Užsaugome lentelę:

File/Save.

Rašome Duomenys

8. Suvesime duomenis:

Eil_Nr Vardas Panarde Gimimo diena Tel_Nr e-mail

1 Vita Čiapkaitė 1980-05-06 523186

2 Rūta Sliesoraitytė 1994-01-26 212865

3 Evelina Dapkutė 1980-05-17 ernelinda@takas.lt

4 Aurelijus Gudžius 1974-05-06 506845 nera@xxx.lt

5 Tomas Arkalas 1969-08-31 erka@betkas.man

Klaviatūra Vita Čiapkaitė 1980-05-06 Rūta .

9. Užsaugome lentelę:

File/Save

10. Pertvarkome duomenis abėcėlės tvarka:

Su pele (к) pažymite tą stulpelį, pagal kurį pertvarkysite duomenis. Iš menių pasirenkame:

Records/Sort/Ascending (nuo A iki Z).

11. Lentelę galima atspausdinti:

File/Print

12. Uždarome Microsoft Access programą:

File/Exit.

Literatūra:

1. R.Achajan, A.Gorev, S.Makasharipov. Efektivnaja rabota s CUBD. Sank-Peterburg, Piter, 1997.

2. A.Balčytienė ir kt. Informatikos įvadas. Vilnius, Apyaušris, 1996.

3. C.J.Date, Ch.J.Date. An introduction to database systems. Addison-Wesley, 1994.

4. Dž.Martin. Organizacija baz danich v vichislitelnich ssistemach. Moskva, Mir, 1980.

5. Gonzalez A.J., Dankel D.D. The Engineering of knowledge-based systems. Theory and practice. Prentice-Hall, 1993.