Das re­la­tio­na­le Da­ten­bank­mo­dell

Be­kann­ter­ma­ßen gehören Da­ten­ban­ken zu den Kern­kom­po­nen­ten eines jeden Com­pu­ter­sys­tems. Denn jedes Com­pu­ter­pro­gramm greift in seiner Laufzeit auf Daten zurück oder generiert selbst In­for­ma­tio­nen, die zu­ver­läs­sig, wi­der­spruchs­frei und dauerhaft ge­spei­chert werden müssen. Dies erfolgt in struk­tu­rier­ten Da­ten­ban­ken (DB), die von so­ge­nann­ten Datenbank-Ma­nage­ment­sys­te­men (DBMS) verwaltet werden. Bei Datenbank-Ma­nage­ment­sys­te­men handelt es sich um Software-An­wen­dun­gen, die mit End-Anwendern oder anderen Pro­gram­men in­ter­agie­ren und diesen eine Teilmenge der in der Datenbank ge­spei­cher­ten Da­ten­ba­sis zur Verfügung stellen.

Bis heute wird die elek­tro­ni­sche Da­ten­ver­wal­tung vom re­la­tio­na­len Da­ten­bank­mo­dell dominiert. Zu den meist­ge­nutz­ten re­la­tio­na­len Datenbank-Ma­nage­ment­sys­te­men (RDBMS) zählen in al­pha­be­ti­scher Rei­hen­fol­ge:

• Db2: Mit Db2 steht Anwendern ein pro­prie­tä­res re­la­tio­na­les Datenbank-Ma­nage­ment­sys­tem aus dem Hause IBM unter kom­mer­zi­el­ler Lizenz zur Verfügung.
   
• Microsoft SQL Server: Das re­la­tio­na­le Datenbank-Ma­nage­ment­sys­tem von Microsoft ist unter einer kos­ten­pflich­ti­gen Microsoft-End­an­wen­der­li­zenz verfügbar.
   
• MySQL: Bei MySQL handelt es sich um das meist­ge­nutz­te quell­of­fe­ne RDBMS der Welt. Seit der Übernahme durch Oracle wird MySQL unter einem dualen Li­zenz­sys­tem ver­mark­tet. Die ur­sprüng­li­che Ent­wick­ler­ge­mein­de führt das Projekt unter dem Namen MariaDB weiter.
   
• Post­greS­QL: Mit Post­greS­QL können Anwender auf ein freies, ob­jekt­re­la­tio­na­les Datenbank-Ma­nage­ment­sys­tem (ORDBMS) zu­rück­grei­fen. Die Wei­ter­ent­wick­lung erfolgt durch eine Open-Source-Community.
   
• Oracle Database: Das re­la­tio­na­le Datenbank-Ma­nage­ment­sys­tem des gleich­na­mi­gen Un­ter­neh­mens Oracle wird als pro­prie­tä­re Software kos­ten­pflich­tig ver­mark­tet.
   
• SQLite: Bei SQLite handelt es sich um eine ge­mein­freie Pro­gramm­bi­blio­thek, die ein re­la­tio­na­les Datenbank-Ma­nage­ment­sys­tem enthält.

Alle genannten Systeme basieren auf einer ta­bel­la­ri­schen Or­ga­ni­sa­ti­on von In­for­ma­tio­nen. Doch was hat es damit auf sich? Wir führen Sie in die Grund­prin­zi­pi­en des re­la­tio­na­len Datenbank-Designs ein, stellen Ihnen re­la­tio­na­le Da­ten­ban­ken anhand von Bei­spie­len vor und grenzen den Da­ten­bank­typ von anderen Modellen ab.

Ein zentraler Begriff des re­la­tio­na­len Da­ten­bank­mo­dells ist die Relation. Dieser geht auf den bri­ti­schen Ma­the­ma­ti­ker und Da­ten­bank­theo­re­ti­ker Edgar F. Codd zurück. Nach Codd stellt eine Relation eine Menge von Entitäten mit gleichen Ei­gen­schaf­ten dar. Jede Relation besteht aus einer Reihe von Da­ten­sät­zen (so­ge­nann­ten Tupel), deren Werte be­stimm­ten At­tri­bu­ten zu­ge­ord­net sind.

Welche Attribute eine Relation umfasst und welchem Datentyp die den At­tri­bu­ten zu­ge­ord­ne­ten Werte ent­spre­chen, wird mithilfe eines Re­la­tio­nen­sche­mas nach folgender Syntax definiert:

R = (A₁ : Typ₁, A₂ : Typ₂ , … , A_n : Typ_n)

Das Re­la­tio­nen­sche­ma (R) umfasst die Attribute A₁ bis A_n. Jedem Attribut ist ein Datentyp (Typ_1, Typ₂ etc.) zu­ge­ord­net. Ver­deut­li­chen lässt sich dies an einem konkreten Beispiel.

Folgendes Schema definiert die Attribute der Relation „mit­ar­bei­ter“:

Das Bei­spiel­sche­ma umfasst die Attribute Mit­ar­bei­ter-ID (m_id), Nachname, Vorname, So­zi­al­ver­si­che­rungs­num­mer (svn), Straße (str), Post­leit­zahl (plz) und Ort und könnte bei­spiels­wei­se der un­ter­neh­mens­in­ter­nen Ver­wal­tung von Per­so­nal­da­ten dienen. Jedem Attribut wird ein Datentyp (bei­spiels­wei­se string oder integer) zu­ge­ord­net. Es gibt somit in dieser Relation Attribute, die Zei­chen­ket­ten als Werte erwarten, und solche, die aus­schließ­lich ganz­zah­li­ge Zah­len­wer­te ak­zep­tie­ren.

Eine Relation mit dem soeben de­fi­nier­ten Schema könnte nun folgendes Tupel enthalten:

Die Bei­spiel­ta­bel­le dient der Spei­che­rung von Per­so­nal­da­ten und besteht aus vier Da­ten­sät­zen. Jeder Datensatz be­inhal­tet In­for­ma­tio­nen zu genau einem Mit­ar­bei­ter.

Die Datenbank eines re­la­tio­na­len Da­ten­bank­sys­tems bildet die ta­bel­la­risch struk­tu­rier­te Da­ten­ba­sis. Definiert wird deren Da­ten­struk­tur vom Datenbank-Ma­nage­ment­sys­tem, das zudem für die Ver­wal­tung der Schreib- und Le­se­zu­grif­fe ver­ant­wort­lich ist. Anwender in­ter­agie­ren mit dem Datenbank-Ma­nage­ment­sys­tem mithilfe einer Da­ten­bank­spra­che. Jedes re­la­tio­na­le Datenbank-Ma­nage­ment­sys­tem un­ter­stützt min­des­tens eine formale Sprache, mit der sich folgende Datenbank-Ope­ra­tio­nen vornehmen lassen:

• Da­ten­struk­tur de­fi­nie­ren: Im Rahmen der Da­ten­de­fi­ni­ti­on wird eine Be­schrei­bung der Da­ten­struk­tur über Meta-Daten im Data-Dic­tion­a­ry des Da­ten­bank­sys­tems abgelegt. Erstellt ein Anwender bei­spiels­wei­se eine neue Tabelle, wird ein ent­spre­chen­des Re­la­tio­nen­sche­ma im Data-Dic­tion­a­ry ge­spei­chert. Das Vokabular einer Da­ten­bank­spra­che, das der Da­ten­de­fi­ni­ti­on dient, wird Data De­fi­ni­ti­on Language (DDL) genannt.
  
  
• Be­rech­ti­gun­gen de­fi­nie­ren: Jede Da­ten­bank­spra­che stellt eine Syntax zur Verfügung, die es er­mög­licht, Be­rech­ti­gun­gen zu vergeben oder diese zu entziehen. Man spricht in diesem Zu­sam­men­hang von der Data Control Language (DCL) – einem Teil­vo­ka­bu­lar der Da­ten­bank­spra­che.
  
  
• In­te­gri­täts­be­din­gun­gen de­fi­nie­ren: Unter In­te­gri­täts­be­din­gun­gen versteht man An­for­de­run­gen an den Zustand einer Datenbank. Werden Be­din­gun­gen für die In­te­gri­tät definiert, stellt die Datenbank sicher, dass diese zu jedem Zeitpunkt erfüllt sind. Man spricht von einem kon­sis­ten­ten Zustand. Eine grund­le­gen­de In­te­gri­täts­be­din­gung in re­la­tio­na­len Da­ten­bank­sys­te­men ist bei­spiels­wei­se, dass sich jeder Datensatz (Tupel) eindeutig iden­ti­fi­zie­ren lässt.
  
  
• Trans­ak­tio­nen de­fi­nie­ren: Wird eine Datenbank von einem kon­sis­ten­ten Zustand in einen anderen überführt, spricht man von einer Trans­ak­ti­on. Trans­ak­tio­nen be­inhal­ten eine Reihe von An­wei­sun­gen und müssen stets voll­stän­dig durch­ge­führt werden. Kommt es zum Abbruch einer Trans­ak­ti­on, wird die Datenbank in den Aus­gangs­zu­stand zu­rück­ge­setzt (Rollback). Jede Trans­ak­ti­on beginnt mit der Anweisung, eine Ver­bin­dung zur Datenbank her­zu­stel­len. Dieser folgen Befehle, die die ei­gent­li­che Da­ten­ope­ra­ti­on einleiten, sowie ein Prüf­schritt (Commit), der die In­te­gri­tät der Datenbank si­cher­stellt. In­te­gri­täts­ge­fähr­den­de Ope­ra­tio­nen werden nicht committet (permanent in die Datenbank ge­schrie­ben). Ab­schlie­ßend wird die Ver­bin­dung zur Datenbank ge­schlos­sen. Das der Da­ten­ma­ni­pu­la­ti­on zu­grun­de­lie­gen­de Vokabular der Da­ten­bank­spra­che nennt man Data Ma­ni­pu­la­ti­on Language (DML).
  
  
• Views de­fi­nie­ren: Bei einem View handelt es sich um eine virtuelle Ansicht aus­ge­wähl­ter Daten. Das Datenbank-Ma­nage­ment­sys­tem erstellt im Fall eines Views eine virtuelle Tabelle (logische Relation) auf Basis phy­si­scher Tabellen. Auf diese Views können Nutzer dieselben Datenbank-Ope­ra­tio­nen anwenden wie auf physische Tabellen. Man un­ter­schei­det je nach Funktion der Da­ten­an­sicht ver­schie­de­ne Arten von Views. Gängig sind Views, die bestimmte Zeilen (Se­lek­ti­ons­sicht) oder Spalten (Pro­jek­ti­ons­sicht) aus einer aus­ge­wähl­ten Tabelle her­aus­fil­tern, sowie Views, die ver­schie­de­ne Tabellen mit­ein­an­der ver­knüp­fen (Ver­bund­sicht).

Als Standard-Schnitt­stel­le für die oben auf­ge­führ­ten Datenbank-Ope­ra­tio­nen nutzt man im re­la­tio­na­len Da­ten­bank­mo­dell die auf der re­la­tio­na­len Algebra ba­sie­ren­de Da­ten­bank­spra­che SQL (Struc­tu­red Query Language).

Datenbank-Ope­ra­tio­nen wie das Abfragen, Erstellen, Ak­tua­li­sie­ren oder Löschen von Daten erfolgen mithilfe so­ge­nann­ter SQL-State­ments – eine Kom­bi­na­ti­on aus­ge­wähl­ter SQL-Befehle. Diese sind se­man­tisch an die englische Sprache angelehnt und somit weit­ge­hend selbst erklärend. Folgende Tabelle enthält zentrale Begriffe des re­la­tio­na­len Da­ten­mo­dells und deren Ent­spre­chung in der SQL-Ter­mi­no­lo­gie.

Eine einfache Abfrage aus­ge­wähl­ter Daten ließe sich mit SQL bei­spiels­wei­se nach folgendem Schema umsetzen:

Wir nutzen zunächst den Befehl SELECT, um das RDBMS an­zu­wei­sen, Daten ab­zu­fra­gen. An­schlie­ßend de­fi­nie­ren wir, welche Daten wir abfragen möchten, indem wir die Tabelle sowie die ge­wünsch­te Spalte angeben. Darüber hinaus in­te­grie­ren wir mit WHERE eine Bedingung in das SQL-Statement. Wir möchten nicht sämtliche in der Spalte ge­spei­cher­ten At­tri­but­wer­te abrufen, sondern lediglich den Wert eines be­stimm­ten Da­ten­sat­zes.

Bezogen auf unsere Bei­spiel­ta­bel­le „mit­ar­bei­ter“ könnte ein solches SQL-Statement fol­gen­der­ma­ßen aussehen:

Das SQL-Statement weist das RDBMS an, aus der Tabelle „mit­ar­bei­ter“ einen Wert aus der Spalte svn abzurufen. Als Bedingung haben wir definiert, dass der Wert aus dem Datensatz entnommen werden soll, bei dem der At­tri­but­wert der Spalte m_id dem Wert 3 ent­spricht.

Als Ergebnis liefert uns die Datenbank 25 091225 M 463 – die So­zi­al­ver­si­che­rungs­num­mer von Günther Meyer, dem Mit­ar­bei­ter mit der ID 3.

Ein solcher Schlüssel mit den Werten

wäre somit geeignet, den Datensatz zum An­ge­stell­ten Günther Meyer wi­der­spruchs­frei zu iden­ti­fi­zie­ren. Man spricht bei Schlüs­seln dieser Art von Su­per­schlüs­seln. Su­per­schlüs­sel haben in der Praxis jedoch nur eine geringe Bedeutung. Ein Grund dafür ist, dass Su­per­schlüs­sel oft mehr Attribute be­inhal­ten, als für die Iden­ti­fi­ka­ti­on notwendig wären. Mit anderen Worten: Su­per­schlüs­sel sind nicht minimal.

In re­la­tio­na­len Da­ten­ban­ken arbeitet man daher mit kleinst­mög­li­chen Teil­men­gen eines denkbaren Su­per­schlüs­sels – so­ge­nann­te Schlüs­sel­kan­di­da­ten. Eine Tabelle kann dabei durchaus mehrere Schlüs­sel­kan­di­da­ten aufweisen, mit denen sich Da­ten­sät­ze eindeutig iden­ti­fi­zie­ren lassen.

Bereits das Ab­fra­ge­bei­spiel im vor­her­ge­hen­den Abschnitt hat gezeigt, dass die Da­ten­sät­ze der Tabelle „mit­ar­bei­ter“ allein durch die Mit­ar­bei­ter-ID wi­der­spruchs­frei zu iden­ti­fi­zie­ren sind. Ein weiterer Schlüs­sel­kan­di­dat der Bei­spiel­ta­bel­le ist die So­zi­al­ver­si­che­rungs­num­mer. Ein Schlüssel {nachname, vorname} wäre hingegen kein ge­eig­ne­ter Schlüs­sel­kan­di­dat, da diese Kom­bi­na­ti­on von At­tri­bu­ten nicht eindeutig einem Mit­ar­bei­ter zu­ge­schrie­ben werden kann. Denn in einem Un­ter­neh­men können durchaus mehrere An­ge­stell­te mit dem Namen Günther Meyer be­schäf­tigt sein. Die Iden­ti­fi­ka­ti­on über einen solchen Schlüssel wäre also nicht eindeutig. Dass sich zwei An­ge­stell­te dieselbe Mit­ar­bei­ter-ID oder So­zi­al­ver­si­che­rungs­num­mer teilen, ist hingegen aus­ge­schlos­sen.

Für die oben dar­ge­stell­te Bei­spiel­ta­bel­le lassen sich somit folgende Schlüs­sel­kan­di­da­ten bestimmen:

Re­la­tio­na­le Da­ten­bank­ta­bel­len werden in der Regel so struk­tu­riert, dass einer der möglichen Schlüs­sel­kan­di­da­ten die Rei­hen­fol­ge der Da­ten­sät­ze vorgibt. Dieser Schlüs­sel­kan­di­dat wird Pri­mär­schlüs­sel (Primary Key) genannt. In der Praxis handelt es sich bei Pri­mär­schlüs­seln meist um fort­lau­fen­de IDs. Mit der m_id weist auch unsere Bei­spiel­ta­bel­le eine solche ID auf.

Da Schlüssel Da­ten­sät­ze in re­la­tio­na­len Da­ten­bank­ta­bel­len eindeutig iden­ti­fi­zie­ren, eigenen sich diese her­vor­ra­gend, um ver­schie­de­ne Tabellen einer Datenbank mit­ein­an­der in Beziehung zu setzen. Dazu nimmt man den Pri­mär­schlüs­sel der einen Tabelle als Fremd­schlüs­sel (Foreign Key) in die andere Tabelle auf.

Folgende Tabelle umfasst Daten, die ein Un­ter­neh­men zum fir­men­ei­ge­nen Fuhrpark erfasst haben könnte. Pri­marschlüs­sel der Tabelle „kfz“ ist eine fort­lau­fen­de kfz_id.

Um ab­zu­bil­den, welche Mit­ar­bei­ter welchen Fir­men­wa­gen benutzen, muss man die Tabelle „kfz“ mit der Tabelle „mit­ar­bei­ter“ ver­knüp­fen – bei­spiels­wei­se, indem der Pri­mär­schlüs­sel der Kfz-Tabelle (die kfz_id) als Fremd­schlüs­sel in die Mit­ar­bei­ter-Tabelle in­te­griert wird.

Der Mit­ar­bei­ter-Tabelle ist nun zu entnehmen, dass An­ge­stell­ter Schmidt einen Fir­men­wa­gen mit der kfz_id 3 benutzt. An­ge­stell­ter Krause fährt ein Fahrzeug mit der kfz_id 2. Müller und Meyer hingegen teilen sich den Wagen mit der kfz_id 1.

Soll nun ermittelt werden, welcher Mit­ar­bei­ter seinen Fir­men­wa­gen wann das nächste Mal warten lassen muss, müsste man dazu sowohl die Tabelle „mit­ar­bei­ter“ als auch die Tabelle „kfz“ abfragen. Da beide Tabellen über Fremd­schlüs­sel mit­ein­an­der in Beziehung stehen, lässt sich dies mit nur einer Abfrage be­werk­stel­li­gen. Datenbank-Ope­ra­tio­nen, die sich über mehrere Tabellen erstecken, werden im re­la­tio­na­len Da­ten­bank­mo­dell mithilfe eines JOINs rea­li­siert.

Bei einem JOIN (auf Deutsch: Verbund) handelt es sich eine Datenbank-Operation, die es er­mög­licht, mehrere Da­ten­bank­ta­bel­len gleich­zei­tig ab­zu­fra­gen. Dabei werden die Daten aus­ge­wähl­ter Tabellen zu einer Er­geb­nis­men­ge zu­sam­men­ge­fasst und nach be­nut­zer­de­fi­nier­ten Be­din­gun­gen gefiltert aus­ge­ge­ben.

Ma­the­ma­ti­sche Grundlage des SQL JOINs sind zwei Ope­ra­tio­nen der re­la­tio­na­len Algebra: das kar­te­si­sche Produkt und die Selektion. Welche Daten der ab­ge­frag­ten Tabellen in die Er­geb­nis­men­ge auf­ge­nom­men werden, bestimmen Anwender durch die Wahl des JOIN-Typs sowie mithilfe einer Se­lek­ti­ons­be­din­gung.

Zu den wich­tigs­ten JOIN-Typen zählen:

• INNER JOIN
• OUTER JOIN
• SELF JOIN

Un­ab­hän­gig davon sind EQUI JOINs und NON EQUI JOINs zu un­ter­schei­den.

Wie SQL JOINs über re­la­tio­na­le Da­ten­bank­ta­bel­len funk­tio­nie­ren und was bei der Wahl des JOIN-Typs zu beachten ist, ist Thema des wei­ter­füh­ren­den Artikels zum SQL JOIN.

Ab­zu­gren­zen sind re­la­tio­na­le Da­ten­ban­ken auf SQL-Basis von solchen Konzepten, die mit der starren Ta­bel­len­struk­tur brechen und al­ter­na­ti­ve Ansätze zur Da­ten­struk­tu­rie­rung verfolgen. Zu den pro­mi­nen­tes­ten Konzepten dieser Art zählen Ob­jekt­da­ten­ban­ken und do­ku­men­ten­ba­sier­te Systeme.

Ende der 1980er-Jahre trat mit Ob­jekt­da­ten­ban­ken ein bis dahin neues Da­ten­bank­mo­dell auf den Plan, das Konzepte der ob­jekt­ori­en­tier­ten Pro­gram­mie­rung aufgriff und eine Da­ten­spei­che­rung in Form von Objekten er­mög­lich­te. Durch­set­zen konnte sich dieser Ansatz bis heute jedoch kaum. Statt­des­sen sind Konzepte der Ob­jekt­ori­en­tie­rung in die Ent­wick­lung re­la­tio­na­ler Da­ten­bank­sys­te­me mit­ein­ge­flos­sen. Das Ergebnis sind Produkte mit ob­jekt­re­la­tio­na­len Er­wei­te­run­gen, die eine Spei­che­rung abs­trak­ter Da­ten­ty­pen im re­la­tio­na­len Da­ten­bank­mo­dell er­mög­li­chen.

Mit der ver­än­der­ten Nutzung des Internets im Rahmen des Web 2.0 geriet das re­la­tio­na­le Da­ten­bank­mo­dell zur Jahr­tau­send­wen­de erneut unter Beschuss. Im Rahmen der NoSQL-Bewegung (kurz für Not Only SQL) wurden Al­ter­na­tiv­mo­del­le wie do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken ent­wi­ckelt. Ziel dieser Bewegung war es, leis­tungs­star­ke Da­ten­bank­kon­zep­te für da­ten­in­ten­si­ve An­wen­dun­gen zu ent­wi­ckeln.

Vom re­la­tio­na­len Da­ten­bank­mo­dell un­ter­schei­den sich Ob­jekt­da­ten­ban­ken und do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken vor allem darin, wie der Da­ten­be­stand ge­spei­chert wird und wie auf ge­spei­cher­te Daten zu­ge­grif­fen werden kann.

Das ob­jekt­ori­en­tier­te Da­ten­bank­mo­dell sieht die Spei­che­rung von Daten als Objekte vor. Die Mo­du­la­ti­on von Objekten erfolgt dabei analog zur ob­jekt­ori­en­tier­ten Pro­gram­mie­rung. Ein Objekt definiert eine Entität und enthält:

• die zur Be­schrei­bung der Entität be­nö­tig­ten Ei­gen­schaf­ten (Attribute),
• Verweise (Be­zie­hun­gen) zu anderen Objekten sowie
• Funk­tio­nen, die den Zugriff auf die ge­spei­cher­ten Daten er­mög­li­chen (Methoden).

Ein Objekt ist somit ein Verbund von Daten, in dem zudem die Schnitt­stel­le definiert ist, über die man auf diese Daten zugreift. Objekte zählt man zu den abs­trak­ten Da­ten­ty­pen.

Jedem Objekt wird vom ob­jekt­ori­en­tier­ten Datenbank-Ma­nage­ment­sys­tem (ODBMS) au­to­ma­tisch eine ID zu­ge­wie­sen. Die er­mög­licht es, das Objekt eindeutig zu iden­ti­fi­zie­ren und mit Methoden an­zu­spre­chen. Diese Objekt-ID ist zu­stands­un­ab­hän­gig, d.h. von den Ob­jekt­wer­ten ent­kop­pelt. Es ist somit möglich, zwei Objekten mit denselben Daten (d.h. mit demselben Zustand) zwei un­ter­schied­li­che IDs zu geben. Damit grenzt sich das ob­jekt­ori­en­tier­te Da­ten­bank­mo­dell deutlich vom re­la­tio­na­len Modell ab, bei dem jeder Tupel anhand seiner Daten iden­ti­fi­ziert werden kann (z. B. durch einen Pri­mär­schlüs­sel).

Ein weiteres Merkmal des ob­jekt­ori­en­tier­ten Da­ten­bank­mo­dells ist die Da­ten­kap­se­lung. Auf ge­spei­cher­te Daten kann man aus­schließ­lich über die zuvor de­fi­nier­ten Methoden zugreifen. Die im Objekt ge­kap­sel­ten Daten sind somit vor Än­de­run­gen über nicht de­fi­nier­te Schnitt­stel­len geschützt.

Da­ten­bank­struk­tu­ren werden im ob­jekt­ori­en­tier­ten Da­ten­bank­mo­dell über ein hier­ar­chi­sches Klas­sen­sys­tem definiert. Unter einer Klasse versteht man in der ob­jekt­ori­en­tier­ten Pro­gram­mie­rung eine Menge von Objekten, die dieselben Merkmale besitzen. Jeder Ob­jekt­klas­se liegt eine Klas­sen­de­fi­ni­ti­on zugrunde. Dieses Schema gibt die Attribute und Methoden aller Objekte der Klasse vor und bestimmt somit, wie diese erzeugt und geändert werden.

Anwender in­ter­agie­ren mit dem ODBMS mit einer an SQL an­ge­lehn­ten Ab­fra­ge­spra­che für Ob­jekt­da­ten­ban­ken: der Object Query Language (OQL). Das Ergebnis einer OQL-Abfrage ist nicht wie bei SQL eine Er­geb­nis­men­ge, sondern eine Liste jener Objekte, die den Be­din­gun­gen des OQL-State­ments ent­spre­chen.

Bekannte Im­ple­men­tie­run­gen des ob­jekt­ori­en­tier­ten Da­ten­bank­mo­dells sind Realm, ZODB und Perst.

Ent­wi­ckelt wurden ob­jekt­ori­en­tier­te Da­ten­ban­ken als Lösung auf ein Problem in der An­wen­dungs­ent­wick­lung, das als Object-re­la­tio­nal impedence mismatch (ob­jekt­re­la­tio­na­le Un­ver­träg­lich­keit) be­zeich­net wird.

Sollen Objekte aus einer ob­jekt­ori­en­tier­ten Pro­gram­mier­spra­che (z.B. C#, C++ oder Java) in einer re­la­tio­na­len Datenbank ge­spei­chert werden, kommt es un­wei­ger­lich zu In­kom­pa­ti­bi­li­tä­ten, die durch grund­le­gen­de Un­ter­schie­de beider Pro­gram­mier­pa­ra­dig­men begründet sind.

• Re­la­tio­na­le Da­ten­ban­ken un­ter­stüt­zen keine ob­jekt­ori­en­tier­ten Konzepte wie Klassen und Vererbung.
• Die zu­stands­un­ab­hän­gi­ge Ob­jekt­iden­ti­fi­ka­ti­on lässt sich im re­la­tio­na­len Da­ten­bank­mo­dell nicht rea­li­sie­ren.
• Der Schutz­me­cha­nis­mus der Da­ten­kap­se­lung steht im re­la­tio­na­len Da­ten­bank­mo­dell nicht zur Verfügung.

Ein Ansatz, die genannten In­kom­pa­ti­bi­li­täts­pro­ble­me zu vermeiden, besteht darin, auf re­la­tio­na­le Da­ten­ban­ken zu ver­zich­ten und im Rahmen der ob­jekt­ori­en­tier­ten An­wen­dungs­pro­gram­mie­rung statt­des­sen auf eine Ob­jekt­da­ten­bank zu setzen. Dies geht jedoch zwangs­läu­fig mit dem Nachteil einher, dass in Objekten ge­kap­sel­te Daten nicht un­ab­hän­gig von der da­zu­ge­hö­ri­gen Anwendung zur Verfügung stehen. Hinzu kommt die geringe Ver­brei­tung von Ob­jekt­da­ten­ban­ken. Die meisten Tools und Schnitt­stel­len zur Analyse von Da­ten­be­stän­den sind nach wie vor auf re­la­tio­na­le Da­ten­ban­ken ausgelegt und un­ter­stüt­zen das ob­jekt­ori­en­tier­te Da­ten­mo­dell nicht.

An­wen­dungs­ent­wick­ler, die auf die Vorteile einer re­la­tio­na­len Da­ten­hal­tung nicht ver­zich­ten möchten, haben al­ler­dings die Mög­lich­keit, In­kom­pa­ti­bi­li­tä­ten mithilfe ob­jekt­re­la­tio­na­ler Mapper (O/R-Mapper) zu kom­pen­sie­ren. Funk­tio­na­li­tä­ten zur ob­jekt­re­la­tio­na­len Abbildung (object-re­la­tio­nal mapping, ORM) werden über Bi­blio­the­ken im­ple­men­tiert. Diese erzeugen eine Abs­trak­ti­ons­schicht zwischen der ob­jekt­ori­en­tier­ten Anwendung und den in Tabellen ge­spei­cher­ten Daten.

Auch zahl­rei­che Her­stel­ler re­la­tio­na­ler Da­ten­bank­sys­te­me statten ihre Produkte mit Funk­tio­nen aus, die In­kom­pa­ti­bi­li­tä­ten zur ob­jekt­ori­en­tier­ten Pro­gram­mie­rung kom­pen­sie­ren. Da­ten­bank­sys­te­me dieser Art werden „ob­jekt­re­la­tio­nal“ genannt.

Ob­jekt­ori­en­tier­te Da­ten­ban­ken über­tra­gen Grund­prin­zi­pi­en der Ob­jekt­ori­en­tie­rung auf Da­ten­bank­tech­no­lo­gien und bieten sich daher vor allem im Rahmen der ob­jekt­ori­en­tier­ten An­wen­dungs­pro­gram­mie­rung an. Ent­spre­chen­de Da­ten­bank­sys­te­me sind jedoch rar und zum Teil noch nicht marktreif.

Bei einem ob­jekt­re­la­tio­na­len Da­ten­bank­sys­tem handelt es sich um ein re­la­tio­na­les Da­ten­bank­sys­tem, das man um Konzepte der Ob­jekt­ori­en­tie­rung erweitert hat. Die bewährten Prin­zi­pi­en des re­la­tio­na­len Da­ten­bank­mo­dells sollen dadurch auf abstrakte Da­ten­ty­pen wie Objekte aus­ge­wei­tet werden.

Um eine Ver­wal­tung abs­trak­ter Da­ten­ty­pen zu er­mög­li­chen, erweitern ob­jekt­re­la­tio­na­le Da­ten­ban­ken das re­la­tio­na­le Da­ten­bank­mo­dell um

• komplexe, be­nut­zer­de­fi­nier­te Da­ten­ty­pen,
• Typ­kon­struk­to­ren sowie
• Funk­tio­nen und Methoden.

Während re­la­tio­na­le Da­ten­ban­ken im We­sent­li­chen auf al­pha­nu­me­ri­sche Da­ten­ty­pen be­schränkt sind, lassen sich mit be­nut­zer­de­fi­nier­ten Da­ten­ty­pen auch komplex struk­tu­rier­te Mul­ti­me­dia-Dateien verwalten. Typ­kon­struk­to­ren er­mög­li­chen es, neue Da­ten­ty­pen aus vor­han­de­nen Ba­sis­ty­pen ab­zu­lei­ten. Da die Da­ten­bank­spra­che SQL keine Mög­lich­keit bietet, Funk­tio­nen zu erzeugen, müssen ob­jekt­re­la­tio­na­le Da­ten­bank­sys­te­me Er­wei­te­run­gen be­reit­stel­len, mit denen sich Zugriffs- und Ver­ar­bei­tungs­funk­tio­nen für komplexe Da­ten­ty­pen de­fi­nie­ren lassen.

Ab der Jahr­tau­send­wen­de wurden ob­jekt­re­la­tio­na­le Er­wei­te­run­gen wie struk­tu­rier­te Typen in neuere Versionen des SQL-Standards auf­ge­nom­men. Diese werden jedoch nicht von allen DBMS un­ter­stützt. Bekannte Da­ten­bank­sys­te­me, die ent­spre­chen­de Er­wei­te­run­gen zur Verfügung stellen, sind IBM Db2, Oracle Database und Microsoft SQL Server.

Während die Da­ten­spei­che­rung bei re­la­tio­na­len Da­ten­ban­ken in Da­ten­bank­ta­bel­len erfolgt, liegt dem do­ku­men­ten­ori­en­tier­ten Da­ten­bank­mo­dell eine he­te­ro­ge­ne Da­ten­ba­sis aus Ein­zel­do­ku­men­ten zugrunde. Dabei kann es sich sowohl um struk­tu­rier­te Dokumente wie JSON-, YAML- oder XML-Dateien handeln als auch um un­struk­tu­rier­te Dateien wie Binary Large Objects (BLOBs) – bei­spiels­wei­se Bild-, Video- oder Au­dio­da­tei­en. Liegen struk­tu­rier­te Dokumente vor, erfolgt die Spei­che­rung von Daten in Form von Schlüssel/Wert-Paaren. Jedem Schlüssel wird ein konkreter Wert zu­ge­ord­net. In diesem Zu­sam­men­hang wird der Schlüs­sel­be­griff synonym zum Begriff Attribut verwendet und hat nichts mit den Schlüs­seln im re­la­tio­na­len Da­ten­bank­sys­tem zu tun. Bei Werten kann es sich um beliebige In­for­ma­tio­nen handelt. Auch Listen und Arrays mit ge­schach­tel­ten Daten sind mögliche Werte. Ein Dokument im JSON-Format (Ja­va­Script Object Notation), das der Spei­che­rung von Mit­ar­bei­ter­da­ten dient, könnte bei­spiels­wei­se fol­gen­der­ma­ßen aussehen:

Mehrere Dokumente lassen sich zu Do­ku­men­ten­samm­lun­gen (so­ge­nann­ten Coll­ec­tions) zu­sam­men­fas­sen. Das dar­ge­stell­te Mit­ar­bei­ter­do­ku­ment könnte bei­spiels­wei­se zusammen mit anderen Teil der Coll­ec­tion „Mit­ar­bei­ter“ sein.

Abfragen werden mithilfe von Funk­tio­nen rea­li­siert – bei­spiels­wei­se via Ja­va­Script. Auch Datenbank-Ma­nage­ment­sys­te­me, die do­ku­men­ten­ori­en­tiert arbeiten, vergeben an jedes Dokument eine ein­deu­ti­ge ID. Anders als im re­la­tio­na­len Da­ten­bank­mo­dell existiert jedoch kein die ganze Datenbank um­fas­sen­des Da­ten­bank­sche­ma. Dokumente einer do­ku­men­ten­ba­sier­ten Datenbank müssen weder einer Nor­mal­form gerecht werden noch gibt es vor­ge­ge­be­ne Struk­tur­merk­ma­le, die auf alle Dokumente zutreffen müssen. Prin­zi­pi­ell kann also jedes Dokument anders aufgebaut sein. Im Rahmen der An­wen­dungs­ent­wick­lung empfiehlt es sich jedoch, Dokumente in einem der Anwendung ent­spre­chen­den Schema anzulegen, um die Vor­aus­set­zung für gezielte Abfragen zu schaffen.

Be­zie­hun­gen wie die Ver­knüp­fung von Da­ten­bank­ta­bel­len im re­la­tio­na­len Da­ten­bank­mo­dell lassen sich mit do­ku­men­ten­ori­en­tier­ten Da­ten­ban­ken nicht umsetzen. Es ist zwar möglich, die ID eines Dokuments als Referenz manuell in ein anderes Dokument ein­zu­tra­gen, do­ku­men­ten­ori­en­tier­te Datenbank-Ma­nage­ment­sys­te­me bieten jedoch keine JOINs. Ent­spre­chen­de Ab­fra­ge­mög­lich­kei­ten müssten Sie somit selbst pro­gram­mie­ren.

Do­ku­men­ten­ori­en­tier­te Da­ten­bank­sys­te­me bieten sich vor allem dann an, wenn große Da­ten­men­gen mit he­te­ro­ge­ner Struktur und geringer Ver­net­zung ver­ar­bei­tet werden sollen. Damit ist dieses Modell der Da­ten­hal­tung vor allem für Big-Data-Szenarien sinnvoll.

Re­la­tio­na­le Da­ten­bank­sys­te­me stellen zu jeden Zeitpunkt sicher, dass die in den Ta­bel­len­de­fi­ni­tio­nen angegeben Be­din­gun­gen erfüllt sind. Das führt bei der Be­ar­bei­tung großer Da­ten­men­gen zu ver­gleichs­wei­se langsamen Schreib­ge­schwin­dig­kei­ten. NoSQL-Da­ten­bank­sys­te­me haben keine so strengen An­for­de­run­gen an die Da­ten­kon­sis­tenz und eigenen sich daher für große Ar­chi­tek­tu­ren, bei denen viele Da­ten­bank­in­stan­zen parallel betrieben werden.

Auch Web-An­wen­dun­gen greifen immer häufiger auf do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken zurück. Ist jedoch eine starke Ver­net­zung er­for­der­lich, ist die do­ku­men­ten­ba­sier­te Da­ten­spei­che­rung mit größerem Aufwand verbunden. Anwender sollten in diesem Fall besser re­la­tio­na­le Da­ten­bank­sys­te­me nutzen.

Beispiele für do­ku­men­ten­ori­en­tier­te Da­ten­ban­ken sind BaseX, CouchDB, eXist, MongoDB und RavenDB.

Re­la­tio­na­le Da­ten­ban­ken haben sich nicht ohne Grund als De-Facto-Standard in der elek­tro­ni­schen Da­ten­ver­ar­bei­tung durch­ge­setzt. Folgende Punkte sprechen für das re­la­tio­na­le Da­ten­bank­mo­dell.

• Einfaches Da­ten­mo­dell: Re­la­tio­na­len Da­ten­ban­ken liegt ein Da­ten­mo­dell zugrunde, das sich ver­gleichs­wei­se einfach im­ple­men­tie­ren und verwalten lässt. Zahl­rei­che In­for­ma­tio­nen – wie Kun­den­da­ten, Be­stell­lis­ten oder Kon­to­be­we­gun­gen –, die Un­ter­neh­men lang­zei­tig speichern wollen, lassen sich mit der dem re­la­tio­na­len Da­ten­bank­mo­dell zu­grun­de­lie­gen­den Ta­bel­len­struk­tur ideal abbilden.
  
  
• Geringe Da­ten­red­un­danz: Das re­la­tio­na­le Da­ten­bank­mo­dell gibt mit den ver­schie­de­nen Nor­mal­for­men genau de­fi­nier­te Re­ge­lun­gen zur Red­un­danz­ver­mei­dung vor. Werden die Vorgaben zur Nor­ma­li­sie­rung kon­se­quent umgesetzt, er­mög­li­chen re­la­tio­na­le Da­ten­bank­sys­te­me eine nahezu red­un­danz­freie Da­ten­hal­tung. Dies er­leich­tert vor allem die Pflege und Wartung von Da­ten­be­stän­den, da Än­de­run­gen lediglich an einer Stelle vor­ge­nom­men werden müssen.
  
  
• Hohe Da­ten­kon­sis­tenz: Nor­ma­li­sier­te re­la­tio­na­le Da­ten­ban­ken er­mög­li­chen eine wi­der­spruchs­freie Da­ten­hal­tung und tragen somit zur Da­ten­kon­sis­tenz bei. Re­la­tio­na­le Da­ten­bank­sys­te­me bieten zudem Funk­tio­nen, mit denen sich In­te­gri­täts­be­din­gun­gen de­fi­nie­ren und au­to­ma­tisch über­prü­fen lassen. Trans­ak­tio­nen, die die Da­ten­kon­sis­tenz gefährden, sind aus­ge­schlos­sen.
  
  
• Men­gen­ori­en­tier­te Da­ten­ver­ar­bei­tung: Das re­la­tio­na­le Da­ten­bank­sys­tem beruht auf einer men­gen­ori­en­tier­ten Da­ten­ver­ar­bei­tung, bei der jede Entität in atomare Werte zerlegt wird. Dies er­mög­licht eine Ver­knüp­fung ver­schie­de­ner Entitäten über den Inhalt sowie komplexe Da­ten­bank­ab­fra­gen wie JOINs.
  
  
• Ein­heit­li­che Ab­fra­ge­spra­che: Für Abfragen re­la­tio­na­ler Da­ten­ban­ken hat sich die durch ein Gremium von ISO und IEC stan­dar­di­sier­te Da­ten­bank­spra­che SQL etabliert. Zweck dieser Stan­dar­di­sie­rung ist, dass sich An­wen­dun­gen weit­ge­hend un­ab­hän­gig vom dar­un­ter­lie­gen­den Datenbank-Ma­nage­ment­sys­tem ent­wi­ckeln und ausführen lassen. Nach wie vor fällt der Support von SQL je nach DBMS jedoch sehr un­ter­schied­lich aus.

Je nachdem, in welchem Szenario re­la­tio­na­le Da­ten­bank­sys­te­me zum Einsatz kommen, lassen sich Vorteile wie das einfache auf Tabellen ba­sie­ren­de Da­ten­mo­dell sowie die Auf­tei­lung von Daten auf mehrere mit­ein­an­der ver­knüpf­te Tabellen auch als Nachteil in­ter­pre­tie­ren. Zudem sind zentrale Merkmale des re­la­tio­na­len Da­ten­mo­dells mit modernen An­for­de­run­gen an die An­wen­dungs­pro­gram­mie­rung (wie Ob­jekt­ori­en­tie­rung, Mul­ti­me­dia und Big-Data) nur schwer vereinbar.

• Ta­bel­la­ri­sche Abbildung von Daten: Nicht alle Da­ten­ty­pen lassen sich in ein starres Schema mit­ein­an­der ver­knüpf­ter zwei­di­men­sio­na­ler Tabellen pressen (Impedance Mismatch). Abstrakte Da­ten­ty­pen und un­struk­tu­rier­te Daten, die im Zu­sam­men­hang mit Mul­ti­me­dia-An­wen­dun­gen und Big-Data-Lösungen auftreten, lassen sich im re­la­tio­na­len Da­ten­bank­mo­dell nicht abbilden.
   
• Kein hier­ar­chi­sches Da­ten­bank­sche­ma: Re­la­tio­na­le Da­ten­ban­ken bieten – anders als Ob­jekt­da­ten­ban­ken – keine Mög­lich­keit, Da­ten­bank­sche­ma­ta mit hier­ar­chisch struk­tu­rier­ten Klassen zu rea­li­sie­ren. Konzepte wie un­ter­ge­ord­ne­te Entitäten, die Ei­gen­schaf­ten von über­ge­ord­ne­ten Entitäten erben, lassen sich mit ihnen nicht umsetzen. So kann man mit ihnen bei­spiels­wei­se keine Sub-Tupel anlegen. Alle Tupel einer re­la­tio­na­len Datenbank befindet sich auf derselben Hier­ar­chie-Ebene.
   
• Seg­men­tie­rung von Daten: Das Grund­prin­zip re­la­tio­na­ler Da­ten­bank­sys­te­me, In­for­ma­tio­nen auf separate Tabellen auf­zu­tei­len (Nor­ma­li­sie­rung), führt un­wei­ger­lich zu einer Seg­men­tie­rung der Daten. Zu­sam­men­ge­hö­ri­ges wird nicht zwangs­läu­fig auch zusammen ge­spei­chert. Dieses Da­ten­bank­de­sign führt auf der An­wen­dungs­ebe­ne zu komplexen Abfragen über mehrere Tabellen. Die daraus re­sul­tie­ren­de höhere Anzahl ab­ge­frag­ter Segmente wirkt sich meist auch negativ auf die Per­for­mance aus.
   
• Schlech­te­re Per­for­mance in Vergleich zu NoSQL-Da­ten­ban­ken: Das re­la­tio­na­le Da­ten­bank­mo­dell stellt hohe An­for­de­run­gen an die Da­ten­kon­sis­tenz, die bei Trans­ak­tio­nen zulasten der Schreib­ge­schwin­dig­keit gehen. Hier können bei­spiels­wei­se Graph­da­ten­ban­ken punkten.

Das re­la­tio­na­le Da­ten­bank­mo­dell ist über­sicht­lich, ma­the­ma­tisch fundiert und hat sich seit mehr als 40 Jahren im Pra­xis­ein­satz bewährt. Und dennoch ist die Da­ten­hal­tung in struk­tu­rier­ten Tabellen nicht allen An­for­de­run­gen der modernen In­for­ma­ti­ons­tech­no­lo­gie gewachsen.

Vor allem die Ver­wal­tun­gen großer Da­ten­men­gen im Rahmen von Big-Data-Analysen und die Spei­che­rung abs­trak­ter Da­ten­ty­pen bringen klas­si­sche re­la­tio­na­le Systeme an ihre Grenzen. Hier punkten spe­zia­li­sier­te Systeme wie Ob­jekt­da­ten­ban­ken oder Konzepte, die im Rahmen der NoSQL-Bewegung ent­wi­ckelt wurden. Gänzlich ab­schrei­ben kann man das re­la­tio­na­le Da­ten­bank­mo­dell jedoch nicht. Gerade in Un­ter­neh­mens­be­rei­chen, in denen die Ver­ar­bei­tung von Trans­ak­ti­ons­da­ten im Vor­der­grund steht, bringen re­la­tio­na­le Da­ten­ban­ken zahl­rei­che Vorteile.

Daten zu Kun­den­ak­tio­nen oder Mar­ke­ting­maß­nah­men lassen sich in ta­bel­la­ri­schen Systemen ideal abbilden. Zudem pro­fi­tie­ren Anwender von einer Syntax, die trotz ihrer Ein­fach­heit komplexe Abfragen er­mög­licht.