Da­ten­ban­ken: Wozu man sie braucht und welche Arten es gibt

Eine Datenbank sammelt Daten und verknüpft diese zu einer logischen Einheit. Die einzelnen Daten werden mit Me­ta­be­schrei­bun­gen und In­for­ma­tio­nen versehen, die zu ihrer Ver­ar­bei­tung notwendig sind. Da­ten­ban­ken sind äußerst praktisch, um Da­ten­be­stän­de zu verwalten und die Abfrage von be­stimm­ten In­for­ma­tio­nen zu er­leich­tern. Außerdem lassen sich in vielen Da­ten­ban­ken Rechte festlegen, die bestimmen, welche Personen oder Programme auf welche Daten zugreifen dürfen. Dabei geht es auch darum, die Inhalte be­darfs­ge­recht und über­sicht­lich dar­zu­stel­len.

Da­ten­bank­sys­te­me un­ter­schei­den sich kon­zep­tio­nell von­ein­an­der und haben dem­entspre­chend in­di­vi­du­el­le Stärken und Schwächen. Allen liegt aber eine Un­ter­tei­lung in die Datenbank und das Datenbank-Ma­nage­ment-System zugrunde. Die „Datenbank“ be­zeich­net dabei die komplette Menge der zu ordnenden Daten (auch als „Da­ten­ba­sis“ be­zeich­net). Das Datenbank-Ma­nage­ment-System ist für die Ver­wal­tung ver­ant­wort­lich und bestimmt somit Struktur, Ordnung, Zu­griffs­rech­te, Ab­hän­gig­kei­ten usw. Dafür verwendet es häufig eine eigens de­fi­nier­te Da­ten­bank­spra­che und ein ge­eig­ne­tes Da­ten­bank­mo­dell, das die Ar­chi­tek­tur des Da­ten­bank­sys­tems vorgibt.

Viele solcher Systeme lassen sich nur von be­stimm­ten oder sogar genau fest­ge­leg­ten Da­ten­bank­an­wen­dun­gen lesen. Spä­tes­tens hier kommt es häufig zu Ver­wechs­lun­gen der Be­griff­lich­kei­ten, wenn ein be­stimm­tes Da­ten­bank­pro­gramm schlicht als „Datenbank“ be­zeich­net wird. Der Begriff wird zudem häufig verwendet, wenn einfache Samm­lun­gen von Dateien gemeint sind. Im tech­ni­schen Sinn jedoch ist z. B. ein Ordner auf dem Computer, der viele Dateien enthält, noch keine Datenbank.

Um die elek­tro­ni­sche Da­ten­ver­ar­bei­tung struk­tu­rell effizient zu gestalten, hat man bereits in den 1960er Jahren das Konzept der elek­tro­ni­schen Datenbank als separate Software-Schicht zwischen dem Be­triebs­sys­tem und dem An­wen­dungs­pro­gramm er­ar­bei­tet. Es war das Ergebnis prak­ti­scher Er­fah­run­gen: Das manuelle Arbeiten mit einzelnen Dateien sowie das Be­auf­sich­ti­gen und Erteilen von Zu­griffs­rech­ten erwiesen sich schlicht als zu un­hand­lich, als dass die elek­tro­ni­sche Da­ten­ver­ar­bei­tung eine wirkliche Er­leich­te­rung bedeutet hätte. Die Idee des elek­tro­ni­schen Da­ten­bank­sys­tems war eine der wich­tigs­ten In­no­va­tio­nen bei der Ent­wick­lung des Computers.

Zunächst wurden netz­werk­ar­ti­ge und hier­ar­chi­sche Da­ten­bank­mo­del­le er­ar­bei­tet. Diese erwiesen sich aber bald als zu simpel und technisch limitiert. Einen we­sent­li­chen Durch­bruch schaffte die Firma IBM in den 1970er Jahren mit der Ent­wick­lung des weitaus leis­tungs­fä­hi­ge­ren re­la­tio­na­len Da­ten­bank­mo­dells, das sich daraufhin in der Ar­beits­welt rasch ver­brei­te­te. Die er­folg­reichs­ten Produkte dieser Zeit waren die Da­ten­bank­spra­che SQL von Oracle und die Nach­fol­ge­pro­duk­te von IBM, SQL/DS und DB2.

Bis in die 2000er Jahre hinein be­herrsch­ten namhafte Her­stel­ler den Markt für Datenbank-Software, bis einige Open-Source-Projekte für frischen Wind sorgten. Zu den po­pu­lärs­ten frei zu­gäng­li­chen Systemen zählen MySQL und Post­greS­QL. Der seit 2001 ein­set­zen­de Trend hin zu NoSQL-Systemen brach die Tradition von re­la­tio­na­len Da­ten­bank­sys­te­men der Her­stel­ler weiter auf.

Heute sind Da­ten­bank­sys­te­me aus vielen An­wen­dungs­be­rei­chen nicht mehr weg­zu­den­ken. Jegliche Un­ter­neh­mens­soft­ware fußt auf mächtigen und leis­tungs­fä­hi­gen Da­ten­ban­ken, die für die Sys­tem­ad­mi­nis­tra­to­ren um­fang­rei­che Optionen und Tools be­reit­hal­ten. Daneben ist das Thema Da­ten­si­cher­heit bei Da­ten­bank­sys­te­men immer wichtiger geworden. Schließ­lich werden in elek­tro­ni­schen Da­ten­ban­ken Pass­wör­ter, per­sön­li­che In­for­ma­tio­nen und sogar elek­tro­ni­sche Währungen ge­spei­chert und ver­schlüs­selt.

Das moderne Fi­nanz­sys­tem z. B. kann man sich als ein Netzwerk von Da­ten­ban­ken vor­stel­len. Die meisten Geld­sum­men exis­tie­ren als elek­tro­ni­sche In­for­ma­ti­ons­ein­hei­ten – der Schutz dieser In­for­ma­tio­nen mithilfe von sicheren Da­ten­ban­ken ist eine we­sent­li­che Aufgabe der Fi­nanz­in­sti­tu­tio­nen. Nicht zuletzt damit sind elek­tro­ni­sche Da­ten­ban­ken für die moderne Zi­vi­li­sa­ti­on enorm wichtig.

Ein weit ver­brei­te­ter Begriff zur Be­schrei­bung von Funk­tio­nen und An­for­de­run­gen an Trans­ak­tio­nen eines Datenbank-Ma­nage­ment-Systems ist ACID (dt. AKID), ein Akronym für atomicity, con­sis­ten­cy, isolation und du­ra­bi­li­ty (dt. Ato­ma­ri­tät/Ab­ge­schlos­sen­heit, Kon­sis­tenz, Isolation und Dau­er­haf­tig­keit). Die Teil­be­grif­fe von ACID decken wiederum die wich­tigs­ten An­for­de­run­gen an ein DBMS ab:

• Ato­ma­ri­tät bzw. Ab­ge­schlos­sen­heit be­zeich­net die „Alles oder nichts“-Ei­gen­schaft von DBMS, dass nur gültige Abfragen in der richtigen Rei­hen­fol­ge erfolgen und so die gesamte Trans­ak­ti­on korrekt vollzogen wird.
• Kon­sis­tenz setzt voraus, dass er­folg­rei­che Trans­ak­tio­nen eine stabile Datenbank hin­ter­las­sen, was eine ständige Über­prü­fung aller Trans­ak­tio­nen erfordert.
• Als Isolation wird die An­for­de­rung be­zeich­net, dass sich Trans­ak­tio­nen nicht ge­gen­sei­tig „im Weg stehen“, was meist durch bestimmte Sperr­funk­tio­nen gesichert wird.
• Dau­er­haf­tig­keit bedeutet, dass sämtliche Daten im DBMS dauerhaft ge­spei­chert werden, auch nach Abschluss einer er­folg­rei­chen Trans­ak­ti­on. Das gilt auch oder besonders bei Sys­tem­feh­lern bzw. Ausfällen des DBMS. Es­sen­zi­ell für die Dau­er­haf­tig­keit sind etwa Trans­ak­ti­ons­logs, die sämtliche Vorgänge im DBMS mit­pro­to­kol­lie­ren.

Im Folgenden finden Sie eine weitere Un­ter­tei­lung der Funk­tio­nen und An­for­de­run­gen eines Datenbank-Ma­nage­ment-Systems über das ACID-Modell hinaus.

Die Un­ter­schei­dung zwischen den gängigen Da­ten­bank­mo­del­len ist nicht zuletzt Ergebnis der tech­ni­schen Wei­ter­ent­wick­lung elek­tro­ni­scher Da­ten­über­tra­gung. Dabei ging es vor allem um Effizienz und Nut­zer­freund­lich­keit, aber auch um das Wett­rüs­ten der namhaften Her­stel­ler.

Das älteste Da­ten­bank­mo­dell ist das hier­ar­chi­sche. Mitt­ler­wei­le wurde es wei­test­ge­hend von der re­la­tio­na­len Datenbank und anderen Modellen abgelöst. Al­ler­dings kommt das hier­ar­chi­sche Modell in jüngerer Zeit wieder häufiger zum Einsatz: XML nutzt das simple System zur Da­ten­spei­che­rung. Hier und da benutzen Ver­si­che­run­gen und Banken noch hier­ar­chi­sche Da­ten­ban­ken, vor allem bei älteren Da­ten­bank­an­wen­dun­gen. Das wohl be­kann­tes­te hier­ar­chi­sche Da­ten­bank­sys­tem ist IMS/DB von IBM.

In hier­ar­chi­schen Da­ten­ban­ken gibt es ganz ein­deu­ti­ge Ab­hän­gig­kei­ten. So hat jeder Datensatz genau einen Vorgänger (Parent-Child Re­la­ti­onships, PCR) außer der Root (Wurzel) der Datenbank. Das führt zu der oben ab­ge­bil­de­ten Baum­struk­tur. Zwar kann jedes „Kind“ nur einen „El­tern­teil“ haben, dafür kann jedes „El­tern­teil“ aber beliebig viele „Kinder“ haben. Wegen der streng hier­ar­chi­schen Ordnung können Ebenen, die nicht direkt be­nach­bart sind, nicht mit­ein­an­der in­ter­agie­ren. Auch kann eine Ver­bin­dung zwischen zwei ver­schie­de­nen Bäumen nicht ohne weiteres her­ge­stellt werden. Hier­ar­chi­sche Da­ten­bank­struk­tu­ren sind daher extrem un­fle­xi­bel, wenn auch sehr über­sicht­lich.

Da­ten­sät­ze, die „Kinder“ haben, werden als „Records“ be­zeich­net. Da­ten­sät­ze ohne „Kinder“ werden auch „Blätter“ genannt, weil sie meist die Dokumente in einer hier­ar­chi­schen Datenbank be­inhal­ten. Records dienen meist zur Ordnung der Blätter. Jede Abfrage auf einer hier­ar­chi­schen Datenbank greift somit auf ein Blatt zu, das von der Root aus über die Records erreicht wird.

Etwa zeit­gleich zum re­la­tio­na­len Da­ten­bank­mo­dell wurde das Netzwerk-Da­ten­bank­mo­dell kon­zi­piert, auch wenn es sich lang­fris­tig von der Kon­kur­renz aus­ste­chen ließ. Anders als beim hier­ar­chi­schen Modell haben Da­ten­sät­ze (Records) hier keine strikten Parent-Child-Be­zie­hun­gen. Jeder Datensatz kann so mehrere Vorgänger haben, was zu einer netz­ähn­li­chen Struktur führt. Ebenso gibt es keinen ein­deu­ti­gen Zu­griffs­weg auf einen Datensatz.

Der Datensatz in der Mitte des Schau­bilds kann theo­re­tisch von fünf anderen Sätzen erreicht werden. Gleich­zei­tig er­mög­licht der Zugriff auf den mittleren Datensatz den Weg zu fünf weiteren Da­ten­sät­zen. Im Netzwerk-Da­ten­bank­mo­dell können auch Ab­hän­gig­kei­ten fest­ge­legt werden: Der oberste Datensatz hat keine un­mit­tel­ba­re Ver­knüp­fung zu dem ganz rechts, muss also den Weg über den mittleren gehen (dieser kann dann den Zugriff erlauben oder ablehnen). Dafür kann er den Datensatz oben links direkt erreichen. Im Netz­werk­mo­dell können Da­ten­sät­ze fließend eingebaut und entfernt werden, ohne we­sent­lich in die Ge­samt­struk­tur ein­zu­grei­fen.    

Heute kommt das netz­werk­ar­ti­ge Da­ten­bank­mo­dell haupt­säch­lich auf Groß­rech­nern zum Einsatz. In anderen Bereichen vertraut man entweder weiterhin dem hier­ar­chi­schen Modell (gilt besonders für Kunden von IBM) oder hat den Wechsel zum fle­xi­ble­ren und einfacher zu be­die­nen­den re­la­tio­na­len Modell vollzogen. Bekannte Netzwerk-Da­ten­bank­mo­del­le sind neben dem UDS von Siemens das DMS von Sperry Univac. Beide Firmen ent­wi­ckel­ten im Lauf der Jahre auch in­ter­es­san­te Misch­for­men zwischen Netz­werk­mo­dell und re­la­tio­na­lem Modell, ohne einen wirk­li­chen Durch­bruch zu schaffen. Er­geb­nis­se dieses Versuchs lassen sich aber noch heute in Siemens SQL nach­voll­zie­hen. Als moderne Wei­ter­ent­wick­lung des Netz­werk­mo­dells gilt die Graph­da­ten­bank, die vor allem in ihrer Struktur an ein Netzwerk erinnert.

Ob­jekt­da­ten­ban­ken wurden erst Ende der 1980er Jahre kon­zi­piert und finden bis heute eher wenige An­wen­dungs­be­rei­che. Die teilweise als Open Source er­hält­li­chen ob­jekt­ori­en­tier­ten Da­ten­ban­ken kommen am häu­figs­ten auf Java- und .NET-Platt­for­men zum Einsatz. Die be­kann­tes­te Ob­jekt­da­ten­bank ist db4o, die vor allem mit einer geringen Spei­cher­grö­ße punktet. Ob­jekt­da­ten­ban­ken arbeiten meist mit der Ab­fra­ge­spra­che OQL, die SQL sehr ähnlich ist.

Im ob­jekt­ori­en­tier­ten Da­ten­bank­mo­dell werden Daten zusammen mit ihren Funk­tio­nen bzw. Methoden in einem Objekt ge­spei­chert. Objekte be­zeich­nen üb­li­cher­wei­se Ge­gen­stän­de oder Begriffe mit zu­ge­hö­ri­gen At­tri­bu­ten, die das jeweilige Objekt näher be­schrei­ben. Der Zugriff auf diese Objekte wird im Ob­jekt­da­ten­bank-Ma­nage­ment-System mithilfe der „Methoden“ definiert, die zusammen mit den Daten im Objekt abgelegt werden.

Objekte können dabei komplex sein und etwa aus beliebig vielen Da­ten­ty­pen bestehen. Außerdem sind Objekte innerhalb des Da­ten­bank­sys­tems ein­zig­ar­tig und werden mit der ein­deu­ti­gen Iden­ti­fi­ka­ti­ons­num­mer (Object-ID, OID) ge­kenn­zeich­net. Wie im Schaubild zu sehen, werden einzelne Objekte zu Ob­jekt­klas­sen zu­sam­men­ge­fasst, womit sich eine Klas­sen­hier­ar­chie ergibt. Obwohl eine Ähn­lich­keit zum hier­ar­chi­schen Da­ten­bank­mo­dell zu bestehen scheint, ist hier der ob­jekt­ori­en­tier­te Ansatz maßgebend und es exis­tie­ren keine festen Parent-Child-Be­zie­hun­gen. Trotzdem kann durch die Ob­jekt­klas­se die Methode für den Zugriff vor­ge­ge­ben werden.

Vorteile bieten Ob­jekt­da­ten­ban­ken bei komplexen Problemen mit ent­spre­chen­den Ob­jekt­tie­fen. Die Ob­jekt­da­ten­bank arbeitet größ­ten­teils selbst­stän­dig ohne großen Eingriff in die Nor­ma­li­sie­rung und ID-Re­fe­ren­zie­rung und erlaubt somit ein relativ simples und rei­bungs­lo­ses Ein­spei­sen von neuen, komplexen Objekten. Einfache Abfragen sind aber z. B. in einem re­la­tio­na­len Da­ten­bank­sys­tem deutlich schneller. Die eher geringe Po­pu­la­ri­tät ob­jekt­ori­en­tier­ter Da­ten­bank­sys­te­me führt auch zu un­zu­rei­chen­der Kom­pa­ti­bi­li­tät mit vielen gängigen Da­ten­bank­an­wen­dun­gen.

Dokumente bilden in diesem Modell die Grund­ein­heit für die Spei­che­rung von Daten. Sie struk­tu­rie­ren Daten und sollten nicht mit Do­ku­men­ten, wie man sie z. B. von Text­be­ar­bei­tungs­pro­gram­men kennt, ver­wech­selt werden. Die Daten werden in so­ge­nann­ten Key/Value-Paaren ge­spei­chert und bestehen somit aus einem „Schlüssel“ und einem „Wert“. Da die Struktur und die Anzahl dieser Paare nicht fest­ge­schrie­ben sind, können einzelne Dokumente innerhalb einer do­ku­men­ten­ori­en­tier­ten Datenbank höchst un­ter­schied­lich aussehen. Jedes Dokument ist dabei eine in sich ge­schlos­se­ne Einheit. Re­la­tio­nen zwischen Do­ku­men­ten sind nicht ohne weiteres möglich, in diesem Modell aber auch nicht notwendig.

Im re­la­tio­na­len Modell (im Schaubild mit den Tabellen dar­ge­stellt) werden ver­schie­de­ne Re­la­tio­nen mit­ein­an­der verknüpft, um einen ge­mein­sa­men Datensatz aus­zu­le­sen. Im Do­ku­men­ten­mo­dell genügt ein einziges Dokument, um sämtliche In­for­ma­tio­nen zu speichern. Dabei ist das Schema frei wählbar: Das do­ku­men­ten­ori­en­tier­te Da­ten­bank­mo­dell ist kon­zep­tio­nell sche­ma­frei, solange die ver­wen­de­te Da­ten­bank­spra­che gleich bleibt.

Elementar für Do­ku­men­ten­da­ten­ban­ken ist die Idee, dass zu­sam­men­hän­gen­de Daten stets gemeinsam an einem Ort (im Dokument) ge­spei­chert werden. Während re­la­tio­na­le Da­ten­ban­ken zu­sam­men­hän­gen­de In­for­ma­tio­nen meist über die Ver­knüp­fung mehrerer Tabellen dar­stel­len und ausgeben, ist die gezielte Abfrage eines Dokuments im do­ku­men­ten­ba­sier­ten Modell aus­rei­chend. Dadurch wird die Anzahl der nötigen Vorgänge in der Datenbank ver­rin­gert.

Vor allem für Web-Ap­pli­ka­tio­nen sind do­ku­men­ten­ba­sier­te Da­ten­bank­sys­te­me in­ter­es­sant, weil hiermit komplette HTML-Formulare ein­ge­speist werden können. Besonders im Zuge der Ent­wick­lung des Web 2.0 wurden Do­ku­men­ten­da­ten­ban­ken immer beliebter. Al­ler­dings gibt es zwischen den un­ter­schied­li­chen do­ku­men­ten­ori­en­tier­ten Da­ten­bank­sys­te­men er­heb­li­che Un­ter­schie­de von der Syntax bis hin zur internen Struktur. Daher ist grund­sätz­lich nicht jede Do­ku­men­ten­da­ten­bank für jeden An­wen­dungs­be­reich geeignet. Gerade wegen dieser un­ter­schied­li­chen Ite­ra­tio­nen gibt es heute einige namhafte do­ku­men­ten­ori­en­tier­te Da­ten­bank­sys­te­me: Lotus Notes, Amazon SimpleDB, MongoDB, CouchDB, Riak, ThruDB, OrientDB u. v. m.