Modeller av databasarkitektur: hierarkiske, nettverk og relasjonsmodeller

Noen av brettmodellene til databasearkitekturen er som følger:

Prosessen med å definere begrepsdesign av dataelementer og deres interrelasjoner kalles datamodellering. Den tradisjonelle applikasjonsmetoden til dataorganisasjon bygde forskjellige modeller for hver datafil.

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

Et slikt mangfold av måter som ulike dataelementer er koblet til og lagret i datafiler, gjør disse filene bare egnet for programmene de ble opprettet for. Faktisk må detaljene om nøyaktig plassering av forskjellige dataelementer i en fil dokumenteres svært nøye.

Enhver endring i rekkefølgen der ulike dataelementer er plassert, resulterer i endringer i applikasjonsprogrammene ved bruk av datafilen. Databasemetoden bruker en felles datamodell for hele databasen, og brukerprogrammet er ikke opptatt av plassering av et bestemt dataelement. Databasebehandlingssystemet (DBMS) fungerer som et grensesnitt mellom databasen og brukerprogrammene.

DBMS henter dataene fra databasen og gjør den tilgjengelig for brukerprogrammet. Denne funksjonen gir fordelen av data uavhengighet i databasen tilnærming.

Konseptuelt er det tre brede muligheter med hensyn til databasemodeller. Disse er:

en. Hierarkisk modell

b. Nettverksmodell

c. Relasjonsmodell

(a) Hierarkisk modell:

Denne modellen presenterer data til brukere i et hierarki av dataelementer som kan representeres i en slags invertert tre. I et salgsordrebehandlingssystem kan en kunde ha mange fakturaer hevet til ham, og hver faktura kan ha forskjellige dataelementer. Dermed er rotenivået av data kunde, det andre nivået er faktura og det siste nivået er linjeposter som fakturanummer, dato, produkt, mengde etc.

Denne strukturen er ganske naturlig når man ser det fra hendelsespunktet. De lavere nivåene eies imidlertid av høyere dataelementer, og elementer på samme nivå har ingen sammenheng i det hele tatt. Som et resultat vil spørringen som hvilke produkter som er kjøpt av hvilken kunde, i eksempelet ovenfor, være vanskelig å utføre i den hierarkiske strukturen.

Spørringen om hvilken kunde kjøpt hvilket produkt som ville være praktisk. Således, hvor det er mange til mange relasjoner mellom to enheter, ville denne modellen ikke være hensiktsmessig. Figur 9.4 viser den hierarkiske datamodellen for en salgsordrebehandlingsapplikasjon.

(b) Nettverksmodell:

I nettverksmodellen av databasen er det ingen nivåer og en plate kan ha et antall eiere og kan også ha eierskap til flere poster. Dermed oppstår ikke problemet som oppstår ovenfor i salgsordrebehandlingen i nettverksmodellen.

Siden det ikke er definert en bestemt vei for datainnhenting, er antall koblinger svært store og dermed nettverksdatabaser er komplekse, sakte og vanskelige å implementere. I lys av vanskeligheten ved implementering, er nettverksmodellen bare brukt når alle andre alternativer er stengt.

Det typiske eksempelet på en nettverksdatabase kan være den ansatte og avdelingen han / hun har jobbet eller kan jobbe med i fremtiden. Figur 9.5 viser nettverksmodellen for data for et informasjonssystem for medarbeiderne.

(c) Relasjonsmodell:

Den nyeste og populære modellen for databasedesign er relasjonsdatabasemodellen. Denne modellen ble utviklet for å overvinne problemene med kompleksitet og ufleksibilitet av de to tidligere modellene i håndtering av databaser med mange til mange relasjoner mellom enheter.

Disse modellene er ikke bare enkle, men også kraftige. I relasjonsdatabasen blir hver fil oppfattet som en flat fil (et todimensjonalt tabell) bestående av mange linjer (poster), hver plate har nøkkel og ikke-nøkkel dataelement (er). Nøkkelelementet (e) er dataelementet (e) som identifiserer posten. Figur 9.6 viser filene og feltene som hver post skal ha i et kundefaktureringssystem.

I disse filene er nøkkeldataelementene kunde-ID, faktura nr og produktkode. Hver av filene kan brukes separat for å generere rapporter. Data kan imidlertid også hentes fra hvilken som helst kombinasjon av filer, da alle disse filene er relatert til hverandre ved hjelp av nøkkeldataelementer angitt ovenfor.

Dette er den grunnleggende fordelen av relasjonsmodellen til databasen sammen med dens enkelhet og robusthet.

Relasjonsmodellen trekker sterkt på arbeidet med EF Codd som identifiserer egenskaper av en god relasjonsdatabase som følger:

a) All informasjon er logisk representert som tabeller, og tilgangen til data er mulig med navnene på feltene. Dermed er ordren, posisjonen eller filkoblingen ikke et problem for brukerne.

b) Dataarkjektet har informasjon om databasestrukturen, inkludert datatypen; størrelse, etc., definisjoner, relasjoner og tilgangstillatelser. De autoriserte brukerne kan lære om databasemiljøet og endre miljøet ved hjelp av databeskrivelsesspråket (DDL).

c) DML (Data Manipulation Language) er tilgjengelig for brukere, inkludert programmerere for opprettelse, innføring, modifisering, gjenfinning, organisering og sletting av enhver del av databasen. Disse manipulasjonene er mulige både på rekordnivå og for hele filen, og gir fleksibilitet i å definere tilgangstillatelser for ulike kategorier av brukere.

d) Enhver endring i databasens struktur med hensyn til å splitte bordet horisontalt eller vertikalt, bør ikke ha noen innvirkning på logikken i programmet ved hjelp av databasen. Denne data uavhengigheten er kjernen fordel av relasjonsmodellen av databasen.

e) Den distribuerte uavhengigheten av data er et annet trekk ved en god relasjonsdatabase. Brukerprogrammene krever ingen endring når data distribueres eller distribueres først. Den faktiske fysiske plasseringen av data spiller ingen rolle for brukeren så lenge dette feltet vises i dataloggen som lokal.

Som det kan bemerkes fra figur 9.6, er ingen av feltene felles i noen to filer unntatt nøkkelelementet. Så, data redundansen kan unngås i denne modellen. Til dette formål gjennomføres en prosess med datalormalisering under utformingen av en databasestruktur.