Modeller av databasarkitektur: hierarkiska, nätverk och relationella modeller

Några av modellerna för databasarkitekturen är följande:

Processen att definiera den konceptuella utformningen av dataelement och deras interrelationer kallas datormodellering. Den traditionella tillämpningens tillvägagångssätt för dataanalys byggde olika modeller för varje datafil.

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

En sådan mångfald av sätt som olika dataelement kopplas till och lagras i datafiler gör att dessa filer endast är lämpliga för de program som de ursprungligen skapades för. Faktum är att detaljerna om exakt placering av olika dataelement i en fil måste dokumenteras mycket noggrant.

Eventuell förändring i den ordning som olika dataelement placeras i resulterar i ändringar i applikationsprogrammen med datafilen. Databasmetoden använder en gemensam datamodell för hela databasen och användarprogrammet berör inte placeringen av ett visst dataelement. Databashanteringssystemet (DBMS) fungerar som ett gränssnitt mellan databasen och användarprogrammen.

DBMS hämtar data från databasen och gör den tillgänglig för användarprogrammet. Den här funktionen ger fördelen av dataoberoende i databasmetoden.

Konceptuellt finns det tre breda alternativ med avseende på databasmodeller. Dessa är:

en. Hierarkisk modell

b. Nätverksmodell

c. Relationsmodell

(a) Hierarkisk modell:

Denna modell presenterar data för användare i en hierarki av dataelement som kan representeras i ett slags inverterat träd. I ett försäljningsorderbehandlingssystem kan en kund ha flera fakturor upptagna till honom och varje faktura kan ha olika dataelement. Således är rotenivån av data kund, den andra nivån är faktura och den sista nivån är rader som fakturanummer, datum, produkt, kvantitet etc.

Denna struktur är ganska naturlig när man ser från händelsepunktet. De lägre nivåerna ägs emellertid av högre dataelement, och element på samma nivå har ingen koppling alls. Som ett resultat kommer frågan, såsom vilka produkter som köps av vilken kund, i ovanstående exempel, att vara svår att utföra i den hierarkiska strukturen.

Frågan om vilken kund köpte vilken produkt som skulle vara bekvämt. Därför, där det finns många till många relationer mellan två enheter, skulle denna modell inte vara lämplig. Figur 9.4 visar den hierarkiska datamodellen för en säljordningsbehandlingsapplikation.

b) Nätverksmodell:

I databasens nätverksmodell finns inga nivåer och en post kan ha ett antal ägare och kan också ha äganderätt till flera poster. Således kommer problemet som uppkommer ovan i orderorderbehandlingen inte att uppstå i nätverksmodellen.

Eftersom det inte finns någon bestämd sökväg definierad för hämtning av data är antalet länkar mycket stora och således är nätverksdatabaser komplexa, långsamma och svåra att implementera. Med tanke på svårigheten i genomförandet används nätverksmodellen endast när alla andra alternativ är stängda.

Det typiska exemplet på en nätverksdatabas kan vara den anställde och den avdelning han / hon har arbetat med eller kan arbeta med i framtiden. Figur 9.5 visar nätverksmodellen för data för ett anställdsinformationssystem.

(c) Relationsmodell:

Den senaste och populära modellen för databasdesign är relationsdatabasmodellen. Denna modell har utvecklats för att övervinna problemen med komplexitet och flexibilitet hos de tidigare två modellerna för hantering av databaser med många till många relationer mellan enheter.

Dessa modeller är inte bara enkla men också kraftfulla. I relationsdatabasen uppfattas varje fil som en platt fil (ett tvådimensionellt bord) som består av många rader (poster), där varje post har viktiga och icke-viktiga dataobjekt. Nyckelelementen är det eller de dataelement som identifierar posten. Figur 9.6 visar filerna och de fält som varje post ska ha i ett kundfaktureringssystem.

I dessa filer är de viktigaste dataposterna kund-id, fakturanummer och produktkod. Var och en av filerna kan användas separat för att generera rapporter. Däremot kan data också hämtas från vilken kombination av filer som alla dessa filer är relaterade till varandra med hjälp av nyckeldata som anges ovan.

Detta är den grundläggande fördelen med databasens relationella modell tillsammans med dess enkelhet och robusthet.

Relationsmodellen drar mycket på EF Codds arbete som identifierar funktioner i en bra relationell databas som följer:

a) All information är logiskt representerad som tabeller och tillgången till data är möjlig med namnen på fält. Således är beställningen, positionen eller filkopplingen inte ett problem för användarna.

b) Datalogiken har information om databasstrukturen inklusive datatypen; storlek, etc., definitioner, relationer och tillträdesbehörigheter. De auktoriserade användarna kan lära sig om databasmiljön och ändra miljön med hjälp av data beskrivningsspråket (DDL).

c) Ett data manipulationsspråket (DML) är tillgängligt för användare inklusive programmerare för skapande, infogning, modifiering, hämtning, organisering och radering av någon del av databasen. Dessa manipuleringar är möjliga både på rekordnivå och för hela filen, vilket ger flexibiliteten när det gäller att definiera åtkomstbehörigheter för olika kategorier av användare.

d) Eventuell ändring av databasens struktur i form av splittring av tabellen horisontellt eller vertikalt bör inte ha någon inverkan på programmets logik med hjälp av databasen. Detta data oberoende är kärnan fördel med databasens relationella modell.

e) Det distribuerade oberoende av data är ett annat inslag i en bra relationell databas. Användarprogrammen kräver ingen förändring när data först distribueras eller omfördelas. Den faktiska fysiska platsen för data spelar ingen roll för användaren så länge som fältet visas i datalogiken som lokal.

Som det kan noteras från figur 9.6 är inget av fälten vanligt i någon av de två filerna utom nyckelelementet. Så, data redundansen kan undvikas i denna modell. För detta ändamål genomförs en process för datalormalisering under utformningen av en databasstruktur.