Logisches Datenbankdesign: Hierarchische und Netzwerkmodelle

Logisches Datenbankdesign (Logico)

Das logische Design (Logico) zielt darauf ab, die Entwürfe, die den Anforderungen entsprechen, in eine logische Konstruktion zu übersetzen, die von einem Datenbankmanagementsystem (DBMS) umgesetzt werden kann.

Überblick über Logische Modelle

Es gibt verschiedene Darstellungen für das logische Modell einer Datenbank (BD), darunter:

• Hierarchisches Modell
• Netzwerkmodell (Gitter)
• Relationales Modell
• Objektorientiertes Modell

Das Hierarchische Datenbankmodell

Die Entwicklung hierarchischer Modelle und des Konzepts der Datenbanken fand hauptsächlich in den 1960er und 1970er Jahren statt. Ein bekanntes Beispiel für eine hierarchische Datenbank ist IBM IMS, das in den späten 60er Jahren entwickelt wurde.

Wichtige Entwicklungen in dieser Zeit:

• Definition von Sprachen für Unabhängigkeit, Sicherheit usw.
• 1975: Gründung und Arbeit des Ausschusses SPARC/BD (ANSI), der die 3-Stufen-Architektur des DBMS definierte.
• Bis 1980: Entwicklung hierarchischer Systeme und fortgeschrittener Netzwerksysteme.

Merkmale des Hierarchischen Modells

Im hierarchischen Modell haben die Elemente eine Eltern-Kind-Beziehung. Dieses Modell stellt Assoziationen zwischen Entitäten vom Typ 1:1 und 1:M dar, was einer Hierarchie von Einheiten (oder einem Baum) entspricht.

In einer Hierarchie kann ein Elternteil (Eigentümer-Record) viele Kinder (untergeordnete Records) haben, aber ein Kind kann nur ein Elternteil haben.

Der Baum kann mehrere Ebenen bilden, das heißt, ein Kind einer bestimmten Ebene kann wiederum ein Elternteil mit anderen Kindern der unteren Ebene sein. Auf allen Ebenen muss jedoch gelten: Während jeder Elternteil mehrere Kinder haben kann, kann jedes Kind nur ein Elternteil haben.

Datenorganisation und Einschränkungen

Alle Beziehungen werden durch Hierarchien dargestellt. Dateien sind durch physische Zeiger (die die physische Adresse des Datensatzes auf der CD angeben) oder durch hinzugefügte Felder in einzelnen Datensätzen verbunden.

• Es ist schwierig, Beziehungen auszudrücken, in denen ein Kind mit vielen Eltern verbunden ist.
• Das Ändern und Pflegen der Datenbank lässt sich leicht realisieren und aufrechterhalten.

Eine wesentliche Einschränkung dieses Modells ist die Existenz eines alleinigen Elternteils für jede Entität. Aufgrund dieser Beschränkungen können nicht alle Beziehungen in einer hierarchischen Struktur dargestellt werden. Dies führte zu Versuchen, vernetzte Datenbanksysteme zu entwickeln.

Das Netzwerk-Datenbankmodell

Dieses Modell stellt die Daten als eine Menge (Set) von Satzarten und Assoziationen zwischen diesen dar. Es verwendet eine Graph-Datenstruktur, sodass ein Record-Typ viele Assoziationen mit anderen Record-Typen der Art 1:1, 1:M und M:N eingehen kann.

Vorteile und Nachteile

Das Netzwerkmodell ist flexibler als das hierarchische Modell, da es eine Erweiterung darstellt, in der ein Kind mehr als ein Elternteil haben kann. Dieses Modell ist weniger restriktiv als das hierarchische und nutzt ebenfalls physische Hinweise (Pointer) im BD-System.

Der Nachteil ist, dass diese Art von Datenmodellstruktur schnell das Aussehen eines „Spinnennetzes“ annehmen kann, da Zeiger in alle Richtungen verlaufen.

Entwicklung und Standardisierung

Das Netzwerkmodell wurde in den frühen 70er Jahren entwickelt und vermarktet. Es ist bekannt als das CODASYL-Datenmodell (Committee on Data Systems Languages). Normalisierte Beispiele für vernetzte DBMS sind ADABAS, TOTAL und IMAGE.

Umgang mit M:N-Beziehungen

Die Darstellung von M:N-Beziehungen erfordert deren Transformation in zwei Assoziationen, die durch eine sogenannte Kreuzungssatzart (genannt NUB) verbunden sind. Dadurch werden Redundanzprobleme, die im hierarchischen Modell generiert wurden, gelöst.

Das Einfügen, Löschen und Ändern der Datenbank, das im hierarchischen Modell Probleme aufwarf, wird erheblich vereinfacht. Es ist jedoch Vorsicht geboten beim Löschen von Datensätzen, die in M:N-Assoziationen involviert sind, da Inkonsistenzen entstehen können, wenn die in NUB einbezogenen Datensätze nicht ebenfalls gelöscht werden.