Objektorientiert versus relational – Datenbanktheorie für Nicht-Informatiker
Während meiner Arbeit im Bereich des Dokumentenmanagement wurde ich oftmals mit denBegriffen der relationalen und objektorientierten Speicherung von Daten in Datenbakenkonfrontiert. Schnell lernte ich, welcher Hersteller, welches Modell anwendet und dassallgemein das relationale Modell weiter verbreitet ist, obwohl das objektorientierteModell für Dokumentenmanagement vorteilhafter wäre. Dann fragte mich mal ein Kunde, wasdenn eigentlich der Unterschied sei – und so genau konnte ich ihm das leider auch nichterklären. Unzufrieden mit mir selbst habe ich mich also hingesetzt, Bücher gewälzt, imInternet recherchiert und Entwickler und Datenbankspezialisten ausgefragt.
Kennen Sie den Unterschied? Falls nicht, möchte ich die folgenden Zeilen nutzen, um ihnen einen kleinenEinblick in die Welt der Datenbankmodellierung zu geben.
Was sind Datenbanken?
Datenbanken speichern Informationen innerhalb einer einheitlichen Systematik. Siespeichern diese Daten beispielsweise auf der Festplatte, sodass die Daten auf gleicheWeise dauerhaft wieder aufgerufen werden können.
Wie diese Daten gesucht und gefunden werden können und wie Rechte hinsichtlich derInformationen verwaltet werden, entscheidet ein übergeordnetes Datenbankmanagementsystem.Im Bereich des Dokumentenmanagement gibt es zwei populäre Arten der Datenbankmodellierung.Zum einen die relationale und zum anderen die objektorientierte Speicherung von Daten. Wasbedeuten diese Begriffe nun eigentlich?
Relationale Datenbanken
Im relationalen Modell werden Daten innerhalb zweidimensionaler Tabellen mit einer festenAnzahl Spalten und einer beliebigen Anzahl Zeilen gespeichert. Die Spalten stehen dabeijeweils für eine Ausprägung, die Zeilen für einen Datensatz.
Um beispielsweise zu speichern, dass der Kunde Herr Erwin Müller in der Gartenstraße inBerlin wohnt, würden 5 Spalten und eine Zeile benötigt. Die Zeile entspricht demDatensatz, also in diesem Falle unserem Kunden Herrn Müller. Die Spalten entsprechenAnrede, Vornamen, Namen, Straße und Ort.
Anrede | Vorname | Name | Straße | Ort
Herr | Erwin | Müller | Gartenstraße | Berlin
Nun schließt Herr Müller einen Vertrag über eine Haftpflichtpolice ab. Zu diesem Datensatzgibt es dann zwei Tabellen.
Eine Tabelle verwaltet sämtlich Dokumententypen. Die andere Tabelle stellt den Vertrag vonHerrn Müller dar. Die Tabellen referenzieren aufeinander, sodass dasDatenbankmanagementsystem weiß, dass die Dokumentenypnr. 4 auf den Dokumententyp Vertraghinweist.
Damit das Datenbankmanagementsystem sieht, dass der Vertrag zu Herrn Müller gehört,bekommt Herr Müller von Anfang an eine Kundenummer, welche auch in der Tabelle desVertrages auftaucht und beide Tabellen verbindet.
Im Laufe der Zeit schließt Herr Müller viele Verträge ab und jeder bekommt eine eigeneTabelle, welche über die Kundennummer auf Herrn Müller verweist. Wenn man dann nach denVerträgen von Herrn Müller sucht, durchsucht das Datenbankmanagementsystem alle Tabellender Datenbank nach der Ausprägung Herr Müller. Es findet die Kundennr. 123 als Referenz.Außerdem sucht es nach dem Dokumententyp Vertrag und findet die Dokumententypnr. 4 alsReferenz. Dann sucht es nach allen Tabellen, in denen diese beiden Ausprägungen vorkommen.Sie können sich vorstellen, dass das noch viel komplizierter werden kann, je speziellerdie Suche ist.
Jetzt nehmen wir einmal an, Herr Erwin Müller heiratet Elke Fröhlich aus derKornblumenstraße. Herr Müller ist ein fortschrittlicher Mensch und seinen Nachnamen konnteer eh noch nie so richtig leiden. Daher nimmt er den Namen seiner Frau an und zieht zuihr. Selbstverständlich meldet er dies seiner Versicherung. In der Datenbank wird dann dieerste Tabelle dementsprechend geändert.
Kundennummer | Anrede | Vorname | Name | Straße | Ort
123 | Herr| Erwin |Fröhlich |Kornblumenstraße |Berlin
Damit ändert sich aber in der Datenbank der gesamte Zusammenhang seiner Verträge. LautDatenbank hat nun Herr Erwin Fröhlich sämtliche Verträge abgeschlossen und es ist auf denersten Blick nicht zu erkennen, dass Herr Fröhlich damals noch Müller hieß. Wenn jetzt einälterer Kollege sich an Herrn Müller erinnert und nach ihm in der Datenbank sucht, wird erMühe haben, ihn zu finden.
Soviel zu Systematik und ersten Problemen bei relationalen Datenbanken.
Objektorientierte Datenbanken
In einer objektorientierten Datenbank wird jeder Datensatz als ein Ganzes gespeichert.Herr Müller wird im ersten Schritt gespeichert als
Kundennr. 123
Herr Erwin Müller
Gartenstraße
Berlin
Der Unterschied zur relationalen Datenbank wird erst bei Abschluss der Versicherungspolicedeutlich. Diese wird ebenfalls als ein Objekt gespeichert als
Dokumententyp Vertrag
Dokumtententypnr. 4
Versicherungspolice
Kundennr. 123
Herr Erwin Müller
Gartenstraße
Berlin
Herr Müller schließt im Laufe der Zeit viele Verträge ab und jeder wird als eigenständigesObjekt gespeichert. Wenn man dann nach den Verträgen von Herrn Müller sucht, durchsuchtdas Datenbankmanagementsystem alle Objekte der Datenbank nach solchen, welche dieAusprägungen "Vertrag" und "Herr Müller" beinhalten. Es ist also möglich, direkt denSuchbegriffen zu folgen, ohne Referenzierung auf vielfältige andere Tabellen. Diessteigert die Leistungsfähigkeit der Suche innerhalb der Datenbank.
Gleichzeitig werden viele Informationen jedoch doppelt gespeichert – man spricht hier vonredundanter Datenhaltung. Dies ist auch der Grund, weswegen objektorientierte Datenbankenlange Zeit wenig beachtet wurden – frühere Speichermedien wären bereits nach kurzer Zeitvöllig überlastet gewesen. Heutzutage stellen Datenmengen in diesem Bereich seltenst eineHerausforderung dar.
Jetzt heiratet Herr Erwin Müller, Elke Fröhlich aus der Kornblumenstraße. Herr Müllernimmt den Namen seiner Frau an und zieht zu ihr. Selbstverständlich meldet er dies seinerVersicherung. In der Datenbank wird ein Verweis von Herrn Erwin Müller auf Herrn ErwinFröhlich hinterlegt.
Die Datensätze werden hierdurch nicht geändert, ebenso wenig der Zusammenhang, in welchemsie gespeichert wurden. Wenn jetzt ein älterer Kollege sich an Herrn Müller erinnert undnach ihm in der Datenbank sucht, wird er ihn wie eh und je finden.
Fazit
Natürlich ist dies ein sehr vereinfachtes Beispiel. Aber es stellt zwei große Unterschiedebeider Arten der Datenbankmodellierung dar:
Zum einen ist die Suche in relationalen Datenbanken deutlich verstrickter als inobjektorientierten Systemen. Ergebnis sind längere Suchzeiten. Meiner Meinung nach folgenhieraus auch weniger Möglichkeiten der Suche. In jedem Falle sind die verschiedenstenSuchmöglichkeiten innerhalb einer objektorientierten Struktur deutlich einfacher zugestalten.
Zum anderen garantiert die objektorientierte Datenbank Unveränderlichkeit. Vor allem imDokumentenmanagement ist dies ein nicht zu vernachlässigender Faktor. Selbstverständlichwerden die Dokumente selbst auch in der relationalen Datenbank nicht verändert – nur derZusammenhang, in welchem sie gespeichert sind. Doch reicht dies oftmals aus, umverwirrende Suchergebnisse zu liefern.
Es gibt noch viele andere Unterschiede zwischen beiden Datenbanken. So gehen heute fastsämtliche Programmiersprachen (Delphi, C++, Perl, Java) objektorientiert vor. Daher wirdvor allem Software meist mit objektorientierten Programmiersprachen entwickelt. Dieseobjektorientierten Objekte in relationalen Datenbanken zu speichern oder sie damit zuverbinden ist selbstredend deutlich aufwendiger, als wenn beide Systeme einer Modellierungfolgen.
Der relationale Ansatz ist für die Datenhaltung einfacher, stringenter Informationen mitwenigen Querverweisen zwischen den Datensätzen die beste Lösung. Doch gerade dieumfangreichen Verknüpfungen zwischen Dokumenten, Personen, Unternehmen, etc. inDokumentenmanagementsystemen sind innerhalb einer objektorientierten Datenbank deutlichbesser abzubilden. So kann man in objektorientierten Datenbanken besser Strukturenabbilden (Unternehmen/Bereich/Abteilung) und die Datenbanken sind generellleistungsfähiger.
Dennoch beherrschen relationale Datenbanken den Markt im Dokumentenmanagement und es stehtin den Sternen, ob sich dies jemals ändern wird. Aber in jedem Fall kennen wir jetzt denUnterschied zwischen beiden Modellierungen ein wenig besser…
© 2012 FEiG & PARTNER