Modelle der Datenbankarchitektur: Hierarchische, Netzwerk- und relationale Modelle

Einige der Boardmodelle der Datenbankarchitektur lauten wie folgt:

Das Definieren des konzeptionellen Designs von Datenelementen und ihrer Wechselbeziehungen wird als Datenmodellierung bezeichnet. Der traditionelle Anwendungsansatz für die Datenorganisation erstellte für jede Datendatei unterschiedliche Modelle.

Bildhöflichkeit: ysma.gr/static/images/6_4_DBinput.jpg

Aufgrund der vielfältigen Möglichkeiten, mit denen verschiedene Datenelemente verknüpft und in Datendateien gespeichert werden, sind diese Dateien nur für die Anwendungen geeignet, für die sie ursprünglich erstellt wurden. Tatsächlich müssen die Details bezüglich der genauen Platzierung verschiedener Datenelemente in einer Datei sehr sorgfältig dokumentiert werden.

Jede Änderung in der Reihenfolge, in der verschiedene Datenelemente platziert werden, führt zu Änderungen in den Anwendungsprogrammen, die die Datendatei verwenden. Der Datenbankansatz verwendet ein gemeinsames Datenmodell für die gesamte Datenbank, und das Benutzerprogramm ist nicht mit der Platzierung eines bestimmten Datenelements befasst. Das Datenbankverwaltungssystem (DBMS) fungiert als Schnittstelle zwischen der Datenbank und den Anwenderprogrammen.

Das DBMS holt die Daten aus der Datenbank und stellt sie dem Anwenderprogramm zur Verfügung. Diese Funktion bietet den Vorteil der Datenunabhängigkeit beim Datenbankansatz.

Konzeptionell gibt es drei Optionen für Datenbankmodelle. Diese sind:

ein. Hierarchisches Modell

b. Netzwerkmodell

c. Relationales Modell

(a) Hierarchisches Modell:

Dieses Modell stellt Benutzern Daten in einer Hierarchie von Datenelementen dar, die in einer Art umgekehrten Baum dargestellt werden können. In einem Kundenauftragsabwicklungssystem kann ein Kunde viele Rechnungen erhalten, und jede Rechnung kann unterschiedliche Datenelemente haben. Die Stammdatenebene ist also Kunde, die zweite Ebene ist Rechnung und die letzte Ebene sind Positionen wie Rechnungsnummer, Datum, Produkt, Menge usw.

Diese Struktur ist aus Sicht der Ereignisse recht natürlich. Die unteren Ebenen gehören jedoch Datenelementen höherer Ebene, und Elemente auf derselben Ebene haben überhaupt keine Verknüpfung. Daher ist es schwierig, die Abfrage, beispielsweise welche Produkte von welchem ​​Kunden im obigen Beispiel gekauft werden, in der hierarchischen Struktur auszuführen.

Die Frage, welcher Kunde welches Produkt gekauft hat, wäre praktisch. Wenn also viele-zu-viele-Beziehungen zwischen zwei Entitäten bestehen, wäre dieses Modell nicht geeignet. Abbildung 9.4 zeigt das hierarchische Datenmodell für eine Kundenauftragsverarbeitungsanwendung.

(b) Netzwerkmodell:

Im Netzwerkmodell der Datenbank gibt es keine Ebenen, und ein Datensatz kann eine beliebige Anzahl von Besitzern und auch mehrere Datensätze besitzen. Das oben angesprochene Problem in der Kundenauftragsabwicklung tritt daher nicht im Netzwerkmodell auf.

Da für das Abrufen von Daten kein definierter Pfad definiert ist, ist die Anzahl der Links sehr groß und daher sind Netzwerkdatenbanken komplex, langsam und schwer zu implementieren. In Anbetracht der Schwierigkeiten bei der Implementierung wird das Netzwerkmodell nur verwendet, wenn alle anderen Optionen geschlossen sind.

Ein typisches Beispiel für eine Netzwerkdatenbank kann der Mitarbeiter und die Abteilung sein, mit der er / sie gearbeitet hat oder in der Zukunft arbeiten kann. Abbildung 9.5 zeigt das Netzwerkmodell der Daten für ein Mitarbeiterinformationssystem.

(c) relationales Modell:

Das neueste und beliebteste Modell des Datenbankentwurfs ist das relationale Datenbankmodell. Dieses Modell wurde entwickelt, um die Probleme der Komplexität und Inflexibilität der beiden früheren Modelle beim Umgang mit Datenbanken mit vielen zu vielen Beziehungen zwischen Entitäten zu überwinden.

Diese Modelle sind nicht nur einfach, sondern auch leistungsstark. In der relationalen Datenbank wird jede Datei als eine flache Datei (eine zweidimensionale Tabelle) wahrgenommen, die aus vielen Zeilen (Datensätzen) besteht, wobei jeder Datensatz Schlüssel- und Nicht-Schlüsseldatenelemente aufweist. Die Schlüsselelemente sind die Datenelemente, die den Datensatz identifizieren. Abbildung 9.6 zeigt die Dateien und die Felder, die jeder Datensatz in einem Kundenabrechnungssystem haben soll.

In diesen Dateien sind die Schlüsseldatenelemente Kundennummer, Rechnungsnummer und Produktcode. Jede der Dateien kann separat verwendet werden, um Berichte zu erstellen. Daten können jedoch auch aus einer beliebigen Kombination von Dateien abgerufen werden, da alle diese Dateien mit Hilfe der oben angegebenen Schlüsseldatenelemente miteinander in Beziehung stehen.

Dies ist der grundlegende Vorteil des relationalen Datenbankmodells in Verbindung mit seiner Einfachheit und Robustheit.

Das relationale Modell stützt sich stark auf die Arbeit von EF Codd, der die Merkmale einer guten relationalen Datenbank wie folgt identifiziert:

a) Alle Informationen werden logisch als Tabellen dargestellt und der Zugriff auf Daten ist über die Namen von Feldern möglich. Daher ist die Reihenfolge, Position oder Dateiverbindung für die Benutzer nicht von Belang.

b) das Datenwörterbuch enthält Informationen bezüglich der Datenbankstruktur einschließlich des Datentyps; Größe usw., Definitionen, Beziehungen und Zugriffsberechtigungen. Die berechtigten Benutzer können sich mit der Datenbankumgebung vertraut machen und die Umgebung mithilfe der DDL (Data Description Language) ändern.

c) Benutzern, einschließlich Programmierern, steht eine Datenmanipulationssprache (DML) zur Verfügung, mit der ein beliebiger Teil der Datenbank erstellt, eingefügt, geändert, abgerufen, organisiert und gelöscht werden kann. Diese Manipulationen sind sowohl auf Datensatzebene als auch für die gesamte Datei möglich, sodass Sie die Zugriffsberechtigungen für verschiedene Benutzerkategorien flexibel festlegen können.

d) Änderungen in der Datenbankstruktur hinsichtlich der horizontalen oder vertikalen Aufteilung der Tabelle sollten keinen Einfluss auf die Logik des Programms haben, das die Datenbank verwendet. Diese Datenunabhängigkeit ist der Kernvorteil des relationalen Datenbankmodells.

e) Die verteilte Unabhängigkeit von Daten ist ein weiteres Merkmal einer guten relationalen Datenbank. Die Benutzerprogramme erfordern keine Änderung, wenn Daten zum ersten Mal verteilt oder neu verteilt werden. Der tatsächliche physische Ort der Daten ist für den Benutzer nicht von Bedeutung, solange dieses Feld im Datenwörterbuch als lokal angezeigt wird.

Wie aus Abb. 9.6 ersichtlich, ist keines der Felder in zwei Dateien mit Ausnahme des Schlüsselelements gleich. So kann die Datenredundanz in diesem Modell vermieden werden. Zu diesem Zweck wird während des Entwurfs der Struktur einer Datenbank ein Datennormalisierungsprozess durchgeführt.