Beitragsseiten

 

3.4 Datenbankmanagementsysteme

Im Datenbankbereich haben sich unterschiedliche logische Datenmodelle herausgebildet, die sich darin unterscheiden, welche Elemente dem Anwender zur Verfügung stehen und wie diese miteinander verknüpft werden können (KEMPER/EICKLER 1996, S. 23):

  • Netzwerkmodell

  • Hierarchisches Datenmodell

  • Relationales Datenmodell

  • Objektorientiertes Datenmodell

  • Deduktives Datenmodell

Während das Netzwerk- und das hierarchische Datenmodell heute fast nur noch von historischer Bedeutung sind und lediglich in Altinstallationen anzutreffen sind, besitzen relationale Datenbanksysteme eine marktbeherrschende Position. Das deduktive Modell stellt eine Erweiterung des Relationalen Modells um eine Regel- bzw. Deduktionskomponente dar, befindet sich aber noch im Forschungsstadium (ABDELMOTY/ WILLIAMS/ PATON 1992, S. 443). Das objektorientierte Datenmodell soll im Verlauf der Arbeit als Alternative im GIS-Bereich vorgestellt werden. Da Geographische Informationssystem heute in der Regel auf relationalen Datenbank­managementsystemen (RDBMS) aufbauen, soll dieser Typ im Folgenden näher betrachtet werden.

Strukturteil

In relationalen Datenbankmanagementsystemen werden Daten und die Beziehungen zwischen diesen Daten in einfachen, zweidimensionalen Matrizen verwaltet. Formal be­trachtet sind diese Matrizen als Relationen definiert, die jeweils eine Menge gleichartiger Tupel zusammenfassen. In einer präzisen Definition wird zwischen dem Relationen­schema als der strukturellen Beschreibung einerseits, und der Relation als eine Instanz dieses Schemas in einer Datenbank andererseits unterschieden. Das Datenbankschema ist dann eine Menge von Relationenschemen, und eine Menge Relationen bilden eine Daten­bank. Jede Relation ist in ihrer Struktur durch ihre Attribute festgelegt und jedem Attribut ist ein Wertebereich (Domäne) zugeordnet, der die gültigen Werte für dieses Attribut um­faßt (WORBOYS 1999, S. 375). Da die Relation als eine mathematisch definierte Menge aufgefaßt wird, muß jedes Tupel innerhalb einer Relation, d.h. jedes Element der Menge, eindeutig identifizierbar sein. Dazu wird für jede Relation ein Attribut bzw. eine Kombination mehrerer Attribute als Primärschlüssel definiert, der die geforderte Eigen­schaft erfüllt. Durch diesen identifizierenden Charakter des Primärschlüssels kann er als Verweis auf einen bestimmten Datensatz benutzt werden (HEALY 1991, S. 257f.). Über­tragen auf ein RDBMS werden die Daten in einfachen Tabellen gespeichert. Jede Zeile einer Tabelle bildet einen zusammenhängenden Datensatz und jede Spalte entspricht einem Attribut mit den jeweiligen Werten für jedes Tupel (WORBOYS 1999, S. 375).

Operationenteil

In der von CODD 1970 definierten Relationenalgebra sind folgende Operationen festge­legt (HEUER 1992, S.63f.):

  • Selektion: Die Selektion wählt durch die Angabe von Selektionsbedingungen Tupel aus einer Relation aus.

  • Projektion: Über die Projektion kann die Sicht auf bestimmte Attribute einer Relation beschränkt werden.

  • Join: Über gemeinsame Attribute können zwei Relationen miteinander verknüpft werden. Es werden jeweils Tupel mit gemeinsamen Attributwerten zu einem neuen Tupel verknüpft.

  • Mengenoperationen: Die üblichen Mengenoperationen Vereinigung, Differenz und Durchschnitt können nur auf Relationen angewendet werden, die über dieselbe Struktur verfügen.

Die Relationenalgebra ist abgeschlossen, d.h. jede der definierten Operationen hat wiederum eine Relation zu Ergebnis (KEMPER/EICKLER 1996, S. 64). Diese Algebra ist in Form der Structured Query Language (SQL) realisiert, mit der sowohl Abfragen formuliert werden können, als auch die Erstellung eines Datenbankschemas und die Manipulation der Daten möglich ist (WORBOYS 1999, S. 376)

Integritätsregeln

Beim Entwurf der Relationen sind die sog. Normalformen einzuhalten. Die zwei wesent­lichsten Bedingungen, die durch diese Regeln erfüllt werden sollen, sind folgende:

  • Atomisierung der Attributwerte: jede Relation enthält nur noch einfache Attribute, die nicht mehr weiter unterteilt werden können (z.B. einzelne Zahlen oder Zeichen­ketten). Strukturierte Datentypen wie z.B. zusammengesetzte Typen oder Listen sind nicht erlaubt.

  • Funktionale Abhängigkeit: Jedes Nicht-Schlüsselattribut ist voll funktional abhängig von seinem Primärschlüssel.

Idealtypisch repräsentiert in einer voll normalisierten Datenbank jedes Attribut einen Fakt seines Primärschlüssels (HEALY 1991, S. 259). In der Praxis werden Datenbanken aus Performanzgründen wieder denormalisiert, da sonst aufwendige Verknüpfungen durchge­führt werden müssen. Dennoch sind die Normalformen ein wichtiges Instrument während der Designphase eines Informationssystems, da hiermit Redundanzen und Abhängigkeiten im Datenmodell entdeckt und durch einen entsprechende Implementierung konsistenz­erhaltend behandelt werden können.