Datenbankmodell - Database model

Ein Datenbankmodell ist ein Datenmodelltyp , der die logische Struktur einer Datenbank bestimmt . Sie bestimmt grundsätzlich, wie Daten gespeichert, organisiert und manipuliert werden können. Das bekannteste Beispiel für ein Datenbankmodell ist das relationale Modell , das ein tabellenbasiertes Format verwendet.

Typen

Gängige logische Datenmodelle für Datenbanken umfassen:

Hierarchisches Datenbankmodell

Es ist die älteste Form des Datenbankmodells. Es wurde von IBM für IMS (Information Management System) entwickelt. Es ist ein Satz organisierter Daten in Baumstruktur. DB-Record ist ein Baum, der aus vielen Gruppen besteht, die als Segmente bezeichnet werden. Es verwendet eine zu vielen Beziehungen. Auch der Datenzugriff ist vorhersehbar.

Eine objektrelationale Datenbank kombiniert die beiden verwandten Strukturen.

Physische Datenmodelle umfassen:

Andere Modelle sind:

Beziehungen und Funktionen

Ein gegebenes Datenbankverwaltungssystem kann ein oder mehrere Modelle bereitstellen. Die optimale Struktur hängt von der natürlichen Organisation der Daten der Anwendung und von den Anforderungen der Anwendung ab, die Transaktionsrate (Geschwindigkeit), Zuverlässigkeit, Wartbarkeit, Skalierbarkeit und Kosten umfassen. Die meisten Datenbankverwaltungssysteme basieren auf einem bestimmten Datenmodell, obwohl es möglich ist, dass Produkte mehr als ein Modell unterstützen.

Verschiedene physikalische Datenmodelle können jedes gegebene logische Modell implementieren. Die meiste Datenbanksoftware bietet dem Benutzer ein gewisses Maß an Kontrolle bei der Abstimmung der physischen Implementierung, da die getroffenen Entscheidungen einen erheblichen Einfluss auf die Leistung haben.

Ein Modell ist nicht nur eine Möglichkeit, Daten zu strukturieren, sondern definiert auch eine Reihe von Operationen, die mit den Daten durchgeführt werden können. Das relationale Modell definiert beispielsweise Operationen wie select ( project ) und Join . Obwohl diese Operationen in einer bestimmten Abfragesprache möglicherweise nicht explizit sind , bilden sie die Grundlage, auf der eine Abfragesprache aufbaut.

Flaches Modell

Flatfile-Modell

Das flache (oder Tabellen-) Modell besteht aus einem einzelnen, zweidimensionalen Array von Datenelementen , wobei angenommen wird, dass alle Elemente einer gegebenen Spalte ähnliche Werte haben und alle Elemente einer Zeile miteinander verwandt sind. Zum Beispiel Spalten für Name und Kennwort, die als Teil einer Systemsicherheitsdatenbank verwendet werden könnten. Jede Zeile hätte das spezifische Passwort, das einem einzelnen Benutzer zugeordnet ist. Tabellenspalten sind oft mit einem Typ verknüpft, der sie als Zeichendaten, Datums- oder Uhrzeitinformationen, Ganzzahlen oder Gleitkommazahlen definiert. Dieses Tabellenformat ist ein Vorläufer des relationalen Modells.

Frühe Datenmodelle

Diese Modelle waren in den 1960er, 1970er Jahren beliebt, finden sich aber heute vor allem in alten Legacy-Systemen wieder . Sie zeichnen sich in erster Linie dadurch aus, dass sie navigatorisch sind, starke Verbindungen zwischen ihren logischen und physischen Darstellungen aufweisen und Mängel in der Datenunabhängigkeit aufweisen .

Hierarchisches Modell

In einem hierarchischen Modell sind die Daten in einer baumartigen Struktur organisiert , was für jeden Datensatz ein einziges Elternteil impliziert. Ein Sortierfeld hält Geschwisterdatensätze in einer bestimmten Reihenfolge. Hierarchische Strukturen waren in den frühen Mainframe-Datenbankverwaltungssystemen, wie dem Information Management System (IMS) von IBM weit verbreitet und beschreiben heute die Struktur von XML- Dokumenten. Diese Struktur ermöglicht eine Eins-zu-Viele-Beziehung zwischen zwei Datentypen. Diese Struktur ist sehr effizient, um viele Beziehungen in der realen Welt zu beschreiben; Rezepte, Inhaltsverzeichnis, Reihenfolge der Absätze/Verse, alle verschachtelten und sortierten Informationen.

Diese Hierarchie wird als physische Reihenfolge der Datensätze im Speicher verwendet. Der Datensatzzugriff erfolgt durch Navigieren nach unten durch die Datenstruktur unter Verwendung von Zeigern in Kombination mit sequenziellem Zugriff. Aus diesem Grund ist die hierarchische Struktur für bestimmte Datenbankoperationen ineffizient, wenn nicht auch für jeden Datensatz ein vollständiger Pfad (im Gegensatz zu Aufwärtsverbindung und Sortierfeld) enthalten ist. Solche Einschränkungen wurden in späteren IMS-Versionen durch zusätzliche logische Hierarchien kompensiert, die der physischen Basishierarchie auferlegt wurden.

Netzwerkmodell

Das Netzwerkmodell erweitert die hierarchische Struktur und ermöglicht viele-zu-viele-Beziehungen in einer baumartigen Struktur, die mehrere Eltern zulässt. Es war am beliebtesten, bevor es durch das relationale Modell ersetzt wurde, und wird durch die CODASYL- Spezifikation definiert.

Das Netzwerkmodell organisiert Daten mithilfe von zwei grundlegenden Konzepten, die als Datensätze und Mengen bezeichnet werden . Datensätze enthalten Felder (die hierarchisch organisiert sein können, wie in der Programmiersprache COBOL ). Mengen (nicht zu verwechseln mit mathematischen Mengen) definieren Eins-zu-viele- Beziehungen zwischen Datensätzen: ein Eigentümer, viele Mitglieder. Ein Datensatz kann ein Besitzer in einer beliebigen Anzahl von Sätzen und ein Mitglied in einer beliebigen Anzahl von Sätzen sein.

Ein Set besteht aus zirkulären verknüpften Listen, wobei ein Datensatztyp, der Setbesitzer oder das übergeordnete Element, einmal in jedem Kreis vorkommt und ein zweiter Datensatztyp, der untergeordnete oder untergeordnete, in jedem Kreis mehrmals vorkommen kann. Auf diese Weise kann eine Hierarchie zwischen zwei beliebigen Datensatztypen erstellt werden, z. B. Typ A ist der Eigentümer von B. Gleichzeitig kann eine andere Menge definiert werden, in der B der Eigentümer von A ist. Somit umfassen alle Mengen einen allgemeinen gerichteten Graphen (Eigentum definiert eine Richtung) oder Netzwerkkonstrukt . Der Zugriff auf Datensätze erfolgt entweder sequentiell (normalerweise in jedem Datensatztyp) oder durch Navigation in den zirkulären verknüpften Listen.

Das Netzwerkmodell ist in der Lage, Redundanz in Daten effizienter darzustellen als im hierarchischen Modell, und es kann mehr als einen Pfad von einem Vorgängerknoten zu einem Nachkommen geben. Die Operationen des Netzwerkmodells sind im Stil der Navigation: Ein Programm behält eine aktuelle Position bei und navigiert von einem Datensatz zu einem anderen, indem es den Beziehungen folgt, an denen der Datensatz beteiligt ist. Datensätze können auch durch Angabe von Schlüsselwerten gefunden werden.

Obwohl dies kein wesentliches Merkmal des Modells ist, implementieren Netzwerkdatenbanken im Allgemeinen die Mengenbeziehungen mittels Zeigern , die direkt den Ort eines Datensatzes auf der Platte adressieren. Dies führt zu einer hervorragenden Abrufleistung auf Kosten von Vorgängen wie dem Laden und Reorganisieren von Datenbanken.

Beliebte DBMS - Produkte , die verwendet es waren Cincom Systems 'Total und Cullinet ' s IDMS . IDMS gewann einen beachtlichen Kundenstamm; in den 1980er Jahren wurden neben den ursprünglichen Tools und Sprachen auch das relationale Modell und SQL übernommen.

Die meisten Objektdatenbanken (erfunden in den 1990er Jahren) verwenden das Navigationskonzept, um eine schnelle Navigation über Netze von Objekten zu ermöglichen, wobei im Allgemeinen Objektkennungen als "intelligente" Zeiger auf verwandte Objekte verwendet werden. Objectivity/DB implementiert beispielsweise benannte Eins-zu-Eins-, Eins-zu-Viele-, Viele-zu-Eins- und Viele-zu-Viele-Beziehungen, die datenbankübergreifend sein können. Viele Objektdatenbanken unterstützen auch SQL , wodurch die Stärken beider Modelle kombiniert werden.

Invertiertes Dateimodell

In einer invertierten Datei oder einem invertierten Index werden die Inhalte der Daten als Schlüssel in einer Nachschlagetabelle verwendet, und die Werte in der Tabelle sind Zeiger auf die Position jeder Instanz eines bestimmten Inhaltselements. Dies ist auch die logische Struktur heutiger Datenbankindizes , die möglicherweise nur den Inhalt einer bestimmten Spalte in der Nachschlagetabelle verwenden. Das invertierte Dateidatenmodell kann Indizes in einem Satz von Dateien neben bestehenden flachen Datenbankdateien platzieren, um effizient direkt auf benötigte Datensätze in diesen Dateien zuzugreifen.

Bemerkenswert für die Verwendung dieses Datenmodells ist das 1970 eingeführte ADABAS DBMS der Software AG . ADABAS hat einen beachtlichen Kundenstamm gewonnen und existiert und wird bis heute unterstützt. In den 1980er Jahren hat es das relationale Modell und SQL zusätzlich zu seinen ursprünglichen Tools und Sprachen übernommen.

Die dokumentenorientierte Datenbank Clusterpoint verwendet das invertierte Indexierungsmodell, um eine schnelle Volltextsuche beispielsweise für XML- oder JSON -Datenobjekte zu ermöglichen.

Relationales Modell

Zwei Tabellen mit einer Beziehung

Das relationale Modell wurde 1970 von EF Codd eingeführt , um Datenbankverwaltungssysteme unabhängiger von bestimmten Anwendungen zu machen. Es ist ein mathematisches Modell, das in Bezug auf Prädikatenlogik und Mengentheorie definiert ist , und Implementierungen davon wurden von Mainframe-, Midrange- und Mikrocomputersystemen verwendet.

Die Produkte, die allgemein als relationale Datenbanken bezeichnet werden , implementieren tatsächlich ein Modell, das nur eine Annäherung an das von Codd definierte mathematische Modell ist. Drei Schlüsselbegriffe werden in relationalen Datenbankmodellen häufig verwendet: Beziehungen , Attribute und Domänen . Eine Relation ist eine Tabelle mit Spalten und Zeilen. Die benannten Spalten der Relation werden Attribute genannt, und die Domäne ist die Menge von Werten, die die Attribute annehmen dürfen.

Die grundlegende Datenstruktur des relationalen Modells ist die Tabelle, in der Informationen über eine bestimmte Entität (z. B. einen Mitarbeiter) in Zeilen (auch Tupel genannt ) und Spalten dargestellt werden. Somit bezieht sich die " Relation " in der "relationalen Datenbank" auf die verschiedenen Tabellen in der Datenbank; eine Relation ist eine Menge von Tupeln. Die Spalten zählen die verschiedenen Attribute der Entität auf (z. B. Name, Adresse oder Telefonnummer des Mitarbeiters), und eine Zeile ist eine tatsächliche Instanz der Entität (ein bestimmter Mitarbeiter), die durch die Relation repräsentiert wird. Als Ergebnis repräsentiert jedes Tupel der Mitarbeitertabelle verschiedene Attribute eines einzelnen Mitarbeiters.

Alle Relationen (und damit Tabellen) in einer relationalen Datenbank müssen einige Grundregeln einhalten, um als Relationen zu gelten. Erstens ist die Reihenfolge der Spalten in einer Tabelle unerheblich. Zweitens kann es in einer Tabelle keine identischen Tupel oder Zeilen geben. Und drittens enthält jedes Tupel einen einzelnen Wert für jedes seiner Attribute.

Eine relationale Datenbank enthält mehrere Tabellen, die jeweils denen im "flachen" Datenbankmodell ähnlich sind. Eine der Stärken des relationalen Modells besteht darin, dass im Prinzip jeder Wert, der in zwei verschiedenen Datensätzen auftritt (die zu derselben Tabelle oder zu verschiedenen Tabellen gehören), eine Beziehung zwischen diesen beiden Datensätzen impliziert. Um jedoch explizite Integritätsbedingungen zu erzwingen , können Beziehungen zwischen Datensätzen in Tabellen auch explizit definiert werden, indem Eltern-Kind-Beziehungen identifiziert oder nicht identifiziert werden, die durch die Zuweisung von Kardinalität gekennzeichnet sind (1:1, (0)1:M, M:M ). Tabellen können auch ein bestimmtes einzelnes Attribut oder einen Satz von Attributen aufweisen, die als "Schlüssel" fungieren können, der verwendet werden kann, um jedes Tupel in der Tabelle eindeutig zu identifizieren.

Ein Schlüssel, mit dem eine Zeile in einer Tabelle eindeutig identifiziert werden kann, wird als Primärschlüssel bezeichnet. Schlüssel werden häufig verwendet, um Daten aus zwei oder mehr Tabellen zu verknüpfen oder zu kombinieren. Beispielsweise kann eine Employee- Tabelle eine Spalte namens Location enthalten, die einen Wert enthält, der dem Schlüssel einer Location- Tabelle entspricht. Schlüssel sind auch bei der Erstellung von Indizes von entscheidender Bedeutung, die ein schnelles Abrufen von Daten aus großen Tabellen ermöglichen. Jede Spalte kann ein Schlüssel sein, oder mehrere Spalten können zu einem zusammengesetzten Schlüssel zusammengefasst werden. Es ist nicht erforderlich, alle Schlüssel im Voraus zu definieren; Eine Spalte kann als Schlüssel verwendet werden, auch wenn sie ursprünglich nicht als Schlüssel gedacht war.

Ein Schlüssel mit einer externen, realen Bedeutung (wie der Name einer Person, die ISBN eines Buches oder die Seriennummer eines Autos) wird manchmal als "natürlicher" Schlüssel bezeichnet. Wenn kein natürlicher Schlüssel geeignet ist (denken Sie an die vielen Personen namens Brown ), kann ein beliebiger oder Ersatzschlüssel zugewiesen werden (z. B. durch Angabe von Mitarbeiter-ID-Nummern). In der Praxis haben die meisten Datenbanken sowohl generierte als auch natürliche Schlüssel, da generierte Schlüssel intern verwendet werden können, um Verknüpfungen zwischen Zeilen zu erstellen, die nicht unterbrochen werden können, während natürliche Schlüssel weniger zuverlässig für Suchen und für die Integration mit anderen Datenbanken verwendet werden können. (Zum Beispiel könnten Datensätze in zwei unabhängig entwickelten Datenbanken nach der Sozialversicherungsnummer abgeglichen werden , es sei denn, die Sozialversicherungsnummern sind falsch, fehlen oder haben sich geändert.)

Die am häufigsten beim relationalen Modell verwendete Abfragesprache ist die Structured Query Language ( SQL ).

Maßmodell

Das dimensionale Modell ist eine spezielle Anpassung des relationalen Modells, das verwendet wird, um Daten in Data Warehouses so darzustellen, dass Daten mithilfe von Online-Analyseverarbeitung oder OLAP- Abfragen einfach zusammengefasst werden können . Im dimensionalen Modell besteht ein Datenbankschema aus einer einzigen großen Tabelle mit Fakten, die mithilfe von Dimensionen und Kennzahlen beschrieben werden. Eine Dimension stellt den Kontext eines Fakts bereit (z. B. wer teilgenommen hat, wann und wo er aufgetreten ist, und seinen Typ) und wird in Abfragen verwendet, um zusammengehörige Fakten zu gruppieren. Dimensionen sind in der Regel diskret und oft hierarchisch; Der Standort kann beispielsweise das Gebäude, das Bundesland und das Land umfassen. Eine Kennzahl ist eine Größe, die die Tatsache beschreibt, z. B. den Umsatz. Wichtig ist, dass Maßnahmen sinnvoll aggregiert werden können – zum Beispiel können die Umsätze verschiedener Standorte zusammengerechnet werden.

In einer OLAP-Abfrage werden Dimensionen ausgewählt und die Fakten werden gruppiert und aggregiert, um eine Zusammenfassung zu erstellen.

Das Dimensionsmodell wird häufig über dem relationalen Modell implementiert, indem ein Sternschema verwendet wird , das aus einer hochnormalisierten Tabelle mit den Fakten und umgebenden denormalisierten Tabellen mit jeder Dimension besteht. Eine alternative physische Implementierung, die als Schneeflockenschema bezeichnet wird , normalisiert mehrstufige Hierarchien innerhalb einer Dimension in mehrere Tabellen.

Ein Data Warehouse kann mehrere dimensionale Schemata enthalten, die Dimensionstabellen gemeinsam nutzen, sodass sie gemeinsam verwendet werden können. Die Erstellung eines Standardsatzes von Bemaßungen ist ein wichtiger Teil der Bemaßungsmodellierung .

Seine hohe Leistungsfähigkeit hat das Dimensionsmodell zur beliebtesten Datenbankstruktur für OLAP gemacht.

Postrelationale Datenbankmodelle

Produkte eine allgemeinere Datenmodell als das relationale Modell anbieten , sind manchmal klassifiziert als postrelationale . Alternative Begriffe sind "hybrid database", "Object-enhanced RDBMS" und andere. Das Datenmodell in solchen Produkten enthält Beziehungen , ist jedoch nicht durch das Informationsprinzip von EF Codd eingeschränkt , das dies erfordert

alle Informationen in der Datenbank müssen explizit als Werte in Relationen gecastet werden und auf keine andere Weise

—

Einige dieser Erweiterungen des relationalen Modells integrieren Konzepte aus Technologien, die vor dem relationalen Modell liegen. Sie ermöglichen beispielsweise die Darstellung eines gerichteten Graphen mit Bäumen auf den Knoten. Die deutsche Firma sones setzt dieses Konzept in ihrer GraphDB um .

Einige postrelationale Produkte erweitern relationale Systeme um nicht-relationale Funktionen. Andere kamen an die gleiche Stelle, indem sie prärelationalen Systemen relationale Funktionen hinzufügten. Paradoxerweise ermöglicht dies Produkten, die historisch prärelational sind, wie PICK und MUMPS , einen plausiblen Anspruch auf postrelational.

Das Resource Space Model (RSM) ist ein nicht-relationales Datenmodell basierend auf einer mehrdimensionalen Klassifikation.

Diagrammmodell

Graphdatenbanken erlauben eine noch allgemeinere Struktur als eine Netzwerkdatenbank; jeder Knoten kann mit jedem anderen Knoten verbunden sein.

Mehrwertmodell

Datenbanken mit mehreren Werten sind "klumpige" Daten, da sie genau wie relationale Datenbanken gespeichert werden können, aber auch eine Tiefe zulassen, die das relationale Modell nur mit Untertabellen annähern kann. Dies ist fast identisch mit der Art und Weise, wie XML Daten ausdrückt, bei der ein gegebenes Feld/Attribut mehrere richtige Antworten gleichzeitig haben kann. Multivalue kann man sich als komprimierte Form von XML vorstellen.

Ein Beispiel ist eine Rechnung, die entweder in mehrwertigen oder relationalen Daten als (A) Rechnungskopftabelle - ein Eintrag pro Rechnung und (B) Rechnungsdetailtabelle - ein Eintrag pro Position angesehen werden kann. Im Mehrwertmodell haben wir die Möglichkeit, die Daten wie in einer Tabelle zu speichern, mit einer eingebetteten Tabelle, um die Details darzustellen: (A) Rechnungstabelle - ein Eintrag pro Rechnung, keine weiteren Tabellen erforderlich.

Der Vorteil ist, dass die Atomarität der Rechnung (konzeptionell) und der Rechnung (Datendarstellung) eins zu eins ist. Dies führt auch zu weniger Lesevorgängen, weniger Problemen mit der referenziellen Integrität und einer drastischen Verringerung der Hardware, die zur Unterstützung eines bestimmten Transaktionsvolumens erforderlich ist.

Objektorientierte Datenbankmodelle

Objektorientiertes Modell

In den 1990er Jahren wurde das Paradigma der objektorientierten Programmierung auf die Datenbanktechnologie angewendet, wodurch ein neues Datenbankmodell namens Objektdatenbanken entstand . Dies zielt darauf ab, die objekt-relationale Impedanzfehlanpassung zu vermeiden – den Aufwand für die Konvertierung von Informationen zwischen ihrer Darstellung in der Datenbank (zum Beispiel als Zeilen in Tabellen) und ihrer Darstellung im Anwendungsprogramm (typischerweise als Objekte). Darüber hinaus kann das in einer bestimmten Anwendung verwendete Typsystem direkt in der Datenbank definiert werden, wodurch die Datenbank die gleichen Datenintegritätsinvarianten erzwingen kann. Objektdatenbanken führen auch die Schlüsselideen der Objektprogrammierung, wie Kapselung und Polymorphismus , in die Welt der Datenbanken ein.

Zum Speichern von Objekten in einer Datenbank wurden verschiedene dieser Wege ausprobiert. Einige Produkte haben das Problem von der Seite der Anwendungsprogrammierung angegangen, indem sie die vom Programm manipulierten Objekte persistent gemacht haben . Dies erfordert typischerweise das Hinzufügen einer Art von Abfragesprache, da herkömmliche Programmiersprachen nicht in der Lage sind, Objekte basierend auf ihrem Informationsinhalt zu finden. Andere haben das Problem von der Datenbankseite her angegriffen, indem sie ein objektorientiertes Datenmodell für die Datenbank definiert und eine Datenbankprogrammiersprache definiert haben, die volle Programmierfähigkeiten sowie traditionelle Abfragemöglichkeiten ermöglicht.

Objektdatenbanken litten unter mangelnder Standardisierung: Obwohl Standards von der ODMG definiert wurden , wurden sie nie gut genug implementiert, um die Interoperabilität zwischen den Produkten zu gewährleisten. Dennoch wurden Objektdatenbanken in vielen Anwendungen erfolgreich eingesetzt: in der Regel spezialisierte Anwendungen wie Ingenieurdatenbanken oder molekularbiologische Datenbanken anstelle der üblichen kommerziellen Datenverarbeitung. Die Ideen für Objektdatenbanken wurden jedoch von den relationalen Anbietern aufgegriffen und beeinflussten Erweiterungen dieser Produkte und sogar der SQL- Sprache.

Eine Alternative zum Übersetzen zwischen Objekten und relationalen Datenbanken ist die Verwendung einer Object-Relational-Mapping- Bibliothek (ORM).

Siehe auch

Datenbank Design

Verweise

Languages

In other projects