Duomenų bazės architektūros modeliai: hierarchiniai, tinklų ir reliaciniai modeliai

Kai kurie duomenų bazės architektūros modeliai yra tokie:

Duomenų elementų koncepcinio projektavimo ir jų tarpusavio ryšių apibrėžimo procesas vadinamas duomenų modeliavimu. Tradiciniai duomenų tvarkymo būdai kiekvienam duomenų rinkiniui sukūrė skirtingus modelius.

Image Courtesy: ysma.gr/static/images/6_4_DBinput.jpg

Tokie įvairūs būdai, kuriais skirtingi duomenų elementai yra susieti ir saugomi duomenų rinkmenose, leidžia, kad šie failai būtų tinkami tik toms programoms, kurios buvo sukurtos. Iš tiesų, informacija apie tikslią įvairių duomenų elementų išdėstymą rinkmenoje turi būti dokumentuojama labai atsargiai.

Bet kokie skirtingų duomenų elementų išdėstymo tvarkos pakeitimai lemia programų programų pakeitimus naudojant duomenų failą. Duomenų bazės metodas naudoja bendrą duomenų bazę visai duomenų bazei, o vartotojo programa nėra susijusi su konkretaus duomenų elemento išdėstymu. Duomenų bazių valdymo sistema (DBVS) veikia kaip duomenų bazės ir naudotojų programų sąsaja.

DBVS atsiunčia duomenis iš duomenų bazės ir leidžia ją naudoti vartotojo programai. Ši funkcija suteikia duomenų nepriklausomumo privalumą duomenų bazės požiūriu.

Konceptualiai yra duomenų bazių modelių variantai trys. Sitie yra:

a. Hierarchinis modelis

b. Tinklo modelis

c. Reliacinis modelis

a) Hierarchinis modelis:

Šis modelis vartotojams pateikia duomenis duomenų elementų hierarchijoje, kuri gali būti atstovaujama tam tikru invertuotu medžiu. Pardavimo užsakymų apdorojimo sistemoje klientui gali būti pateiktos daug sąskaitų faktūrų ir kiekvienoje sąskaitoje-faktūroje gali būti įvairių duomenų elementų. Taigi duomenų šaknis yra klientas, antrasis lygis - sąskaita, o paskutinis - eilutės elementai, pvz., Sąskaitos faktūros numeris, data, produktas, kiekis ir kt.

Ši struktūra yra gana natūrali, kai žiūrima iš įvykių. Tačiau žemesni lygiai priklauso aukštesnio lygio duomenų elementams, o to paties lygio elementai apskritai neturi ryšio. Dėl šios priežasties užklausa, pavyzdžiui, kokie produktai yra perkami, kai klientas, pirmiau pateiktame pavyzdyje, yra sunku atlikti hierarchinėje struktūroje.

Klausimas, koks klientas įsigijo, kuris produktas būtų patogus. Taigi, kai yra daug-daug ryšių tarp dviejų subjektų, šis modelis nebūtų tinkamas. 9.4 pav. Pavaizduotas pardavimo užsakymų apdorojimo programos duomenų hierarchinis modelis.

b) Tinklo modelis:

Duomenų bazės tinkle nėra lygių, o įrašai gali turėti bet kokį savininkų skaičių, taip pat gali turėti keletą įrašų. Taigi problema, iškilusi pardavimų užsakymų apdorojimo srityje, nebus sukurta tinklo modelyje.

Kadangi nėra jokio aiškaus duomenų, reikalingų duomenų paieškai, nuorodų skaičius yra labai didelis, todėl tinklo duomenų bazės yra sudėtingos, lėtos ir sunkiai įgyvendinamos. Atsižvelgiant į sunkumus įgyvendinant, tinklo modelis naudojamas tik tada, kai visos kitos galimybės yra uždarytos.

Tipiškas tinklo duomenų bazės pavyzdys gali būti darbuotojas ir departamentas, kurį jis dirbo arba gali dirbti ateityje. 9.5 pav. Parodyta darbuotojų informacinės sistemos duomenų tinklo modelis.

c) Reliacinis modelis:

Naujausias ir populiariausias duomenų bazių kūrimo modelis yra reliacinės duomenų bazės modelis. Šis modelis buvo sukurtas siekiant įveikti ankstesnių dviejų modelių sudėtingumo ir nelankstumo problemas, tvarkant duomenų bazes su daugeliu daugelio ryšių tarp subjektų.

Šie modeliai yra ne tik paprasti, bet ir galingi. Reliacinėje duomenų bazėje kiekvienas failas suvokiamas kaip plokščias failas (dviejų matmenų lentelė), susidedantis iš daugelio eilučių (įrašų), kiekvienas įrašas turi raktinį ir ne raktinį duomenų elementą (-us). Pagrindinis elementas (-ai) yra duomenų elementas (-ai), kuris (-ie) identifikuoja įrašą. 9.6 pav. Pavaizduoti failai ir laukai, kuriuos kiekvienas įrašas turi turėti klientų sąskaitų faktūrų išrašymo sistemoje.

Šiuose failuose pagrindiniai duomenų elementai yra kliento ID, sąskaitos faktūros Nr. Ir produkto kodas. Kiekvienas failas gali būti naudojamas atskirai ataskaitoms generuoti. Tačiau duomenys taip pat gali būti gauti iš bet kokio failų derinio, nes visi šie failai yra tarpusavyje susiję su pirmiau nurodytais pagrindiniais duomenų elementais.

Tai yra pagrindinis duomenų bazės reliacinio modelio pranašumas ir paprastumas bei patikimumas.

Reliacinis modelis labai remiasi EF Codd darbu, kuris nustato geros reliacinės duomenų bazės savybes:

a) Visa informacija logiškai pateikiama kaip lentelės, o duomenų prieiga yra įmanoma pagal laukų pavadinimus. Taigi, užsakymas, pozicija ar failų susiejimas nekelia abejonių vartotojams.

b) Duomenų žodynas turi informaciją apie duomenų bazės struktūrą, įskaitant duomenų tipą; dydžiai ir tt, apibrėžtys, ryšiai ir prieigos leidimai. Įgalioti naudotojai gali sužinoti apie duomenų bazės aplinką ir keisti aplinką naudodami duomenų aprašymo kalbą (DDL).

c) Duomenų manipuliavimo kalba (DML) yra prieinama vartotojams, įskaitant programuotojus, norintiems kurti, įterpti, keisti, gauti, tvarkyti ir ištrinti bet kurią duomenų bazės dalį. Šios manipuliacijos yra įmanoma ir rekordiniu lygmeniu, ir visam failui, suteikiant lankstumo apibrėžiant prieigos teises įvairioms vartotojų kategorijoms.

d) Bet kokie duomenų bazės struktūros pakeitimai, susiję su lentelės padalijimu horizontaliai arba vertikaliai, neturėtų turėti įtakos programos logikai naudojant duomenų bazę. Šis duomenų nepriklausomumas yra pagrindinis duomenų bazės reliacinio modelio pranašumas.

e) Duomenų pasiskirstymas yra dar vienas geros reliacinės duomenų bazės bruožas. Vartotojų programoms nereikia keisti, kai duomenys pirmą kartą platinami ar platinami. Tikroji fizinė duomenų vieta vartotojui nesvarbu, kol šis laukas bus rodomas duomenų žodynuose kaip vietinis.

Kaip matyti iš 9.6 pav., Nė vienas iš laukų nėra įprastas dviejose rinkmenose, išskyrus raktų elementą. Taigi šiame modelyje galima išvengti duomenų atleidimo. Šiuo tikslu kuriant duomenų bazės struktūrą atliekamas duomenų normalizavimo procesas.