Modeller af databasearkitektur: hierarkiske, netværk og relationelle modeller

Nogle af boardmodellerne i databasearkitekturen er som følger:

Processen med at definere det konceptuelle design af dataelementer og deres indbyrdes relationer kaldes datamodellering. Den traditionelle applikations tilgang til data organisation bygget forskellige modeller for hver datafil.

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

En sådan mangfoldighed af måder, hvorpå forskellige dataelementer er forbundet og lagret i datafiler gør disse filer kun egnede til de applikationer, de oprindeligt blev oprettet til. Faktisk skal detaljerne vedrørende den nøjagtige placering af forskellige dataelementer i en fil dokumenteres meget nøje.

Enhver ændring i rækkefølgen, hvor forskellige dataelementer er placeret, resulterer i ændringer i applikationsprogrammerne ved hjælp af datafilen. Databaseprocessen anvender en fælles datamodel for hele databasen, og brugerprogrammet er ikke berørt af placeringen af ​​et bestemt dataelement. Databasebehandlingssystemet (DBMS) fungerer som en grænseflade mellem databasen og brugerprogrammerne.

DBMS henter dataene fra databasen og gør det tilgængeligt for brugerprogrammet. Denne funktion giver fordelen af ​​data uafhængighed i databasen tilgang.

Konceptuelt er der tre brede muligheder med hensyn til databasemodeller. Disse er:

en. Hierarkisk model

b. Netværksmodel

c. Relationsmodel

(a) Hierarkisk model:

Denne model præsenterer data til brugere i et hierarki af dataelementer, der kan repræsenteres i en slags inverteret træ. I et salgsordrebehandlingssystem kan en kunde have mange fakturaer opdraget til ham, og hver faktura kan have forskellige dataelementer. Således er rodeniveauet af data kunde, andet niveau er faktura, og det sidste niveau er linjeposter som faktura nummer, dato, produkt, mængde osv.

Denne struktur er helt naturlig, set fra arrangementet synspunkt. De lavere niveauer ejes dog af højere dataelementer, og elementer på samme niveau har slet ingen forbindelse. Som følge heraf vil spørgsmålet, som f.eks. Hvilke produkter, der købes af hvilken kunde, i ovenstående eksempel være vanskeligt at udføre i den hierarkiske struktur.

Spørgsmål til hvilken kunde købt hvilket produkt der ville være bekvemt. Således, hvor der er mange til mange forhold mellem to enheder, ville denne model ikke være passende. Figur 9.4 viser den hierarkiske datamodel for en salgsordrebehandlingsapplikation.

(b) Netværksmodel:

I databasenes netværksmodel er der ingen niveauer, og en post kan have et antal ejere og kan også have ejerskab af flere poster. Således opstår problemet ikke ovenfor i salgsordrebehandlingen i netværksmodellen.

Da der ikke er nogen bestemt vej defineret til hentning af data, er antallet af links meget stort, og dermed er netværksdatabaser komplekse, langsomme og vanskelige at implementere. I betragtning af vanskeligheden ved implementering anvendes netværksmodellen kun, når alle andre muligheder lukkes.

Det typiske eksempel på en netværksdatabase kan være medarbejderen og den afdeling han / hun har arbejdet med eller kan arbejde sammen med i fremtiden. Figur 9.5 viser netværksmodellen af ​​data til et medarbejderinformationssystem.

(c) Forholdsmodel:

Den nyeste og populære model af database design er den relationelle database model. Denne model blev udviklet til at overvinde problemerne med kompleksitet og ufleksibilitet hos de to tidligere modeller i håndtering af databaser med mange til mange relationer mellem enheder.

Disse modeller er ikke kun enkle men også kraftfulde. I relationsdatabasen opfattes hver fil som en flad fil (et todimensionelt bord) bestående af mange linjer (optegnelser), hvor hver post har nøgle og ikke-nøgle dataelement (er). Nøgleelementet (e) er det dataelement (er), der identificerer posten. Figur 9.6 viser filerne og de felter, som hver post skal have i et kundfaktureringssystem.

I disse filer er de vigtigste dataelementer kunde-id, faktura nr og produktkode. Hver af filerne kan bruges separat for at generere rapporter. Data kan imidlertid også hentes fra en hvilken som helst kombination af filer, da alle disse filer er relateret til hinanden ved hjælp af de vigtigste dataelementer, der er angivet ovenfor.

Dette er den grundlæggende fordel ved databasens relationelle model sammen med dens enkelhed og robustheden.

Relationsmodellen trækker meget på EF Codds arbejde, der identificerer funktioner i en god relationsdatabase som følger:

a) Alle oplysninger er logisk repræsenteret som tabeller, og adgangen til data er mulig ved navnene på felter. Således er ordre-, position- eller filforbindelse ikke et problem for brugerne.

b) Dataordbogen har oplysninger om databasestrukturen, herunder datatypen; størrelse osv., definitioner, relationer og adgangstilladelser. De autoriserede brugere kan lære om databasemiljøet og ændre miljøet ved hjælp af databeskrivelsessproget (DDL).

c) Et data manipulationssprog (DML) er tilgængeligt for brugere, herunder programmører til oprettelse, indsættelse, ændring, hentning, organisering og sletning af enhver del af databasen. Disse manipulationer er mulige både på rekordniveau og for hele filen, hvilket giver fleksibilitet i at definere adgangstilladelser til forskellige kategorier af brugere.

d) Enhver ændring i databasens struktur med hensyn til opdeling af tabellen vandret eller lodret burde ikke have nogen indflydelse på programmets logik ved hjælp af databasen. Denne data uafhængighed er den centrale fordel ved databasen relational model.

e) Den distribuerede uafhængighed af data er et andet træk ved en god relationel database. Brugerprogrammerne kræver ikke nogen ændring, når dataene først distribueres eller omfordeles. Den faktiske fysiske placering af data betyder ikke noget for brugeren, så længe dette felt vises i dataloggen som lokal.

Som det kan bemærkes fra figur 9.6 er ingen af ​​felterne almindelige i nogen to filer undtagen nøgleelementet. Så, data redundans kan undgås i denne model. Til dette formål gennemføres en proces med datalormalisering under udformningen af ​​en databasestruktur.