Objektorientiert versus relational – Datenbanktheorie für Nicht-Informatiker

DruckversionAls E-Mail versendenZum Magazin-Forum

Während meiner Arbeit im Bereich des Dokumentenmanagement wurde ich oftmals mit den Begriffen der relationalen und objektorientierten Speicherung von Daten in Datenbaken konfrontiert. Schnell lernte ich, welcher Hersteller, welches Modell anwendet und dass allgemein das relationale Modell weiter verbreitet ist, obwohl das objektorientierte Modell für Dokumentenmanagement vorteilhafter wäre. Dann fragte mich mal ein Kunde, was denn eigentlich der Unterschied sei – und so genau konnte ich ihm das leider auch nicht erklären. Unzufrieden mit mir selbst habe ich mich also hingesetzt, Bücher gewälzt, im Internet recherchiert und Entwickler und Datenbankspezialisten ausgefragt.

Kennen Sie den Unterschied? Falls nicht, möchte ich die folgenden Zeilen nutzen, um ihnen einen kleinen Einblick in die Welt der Datenbankmodellierung zu geben.


Was sind Datenbanken?

Datenbanken speichern Informationen innerhalb einer einheitlichen Systematik. Sie speichern diese Daten beispielsweise auf der Festplatte, sodass die Daten auf gleiche Weise dauerhaft wieder aufgerufen werden können.

Wie diese Daten gesucht und gefunden werden können und wie Rechte hinsichtlich der Informationen 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. Was bedeuten diese Begriffe nun eigentlich?


Relationale Datenbanken

Im relationalen Modell werden Daten innerhalb zweidimensionaler Tabellen mit einer festen Anzahl Spalten und einer beliebigen Anzahl Zeilen gespeichert. Die Spalten stehen dabei jeweils 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 in Berlin wohnt, würden 5 Spalten und eine Zeile benötigt. Die Zeile entspricht dem Datensatz, also in diesem Falle unserem Kunden Herrn Müller. Die Spalten entsprechen Anrede, 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 Datensatz gibt es dann zwei Tabellen.





Eine Tabelle verwaltet sämtlich Dokumententypen. Die andere Tabelle stellt den Vertrag von Herrn Müller dar. Die Tabellen referenzieren aufeinander, sodass das Datenbankmanagementsystem weiß, dass die Dokumentenypnr. 4 auf den Dokumententyp Vertrag hinweist.

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 des Vertrages auftaucht und beide Tabellen verbindet.





Im Laufe der Zeit schließt Herr Müller viele Verträge ab und jeder bekommt eine eigene Tabelle, welche über die Kundennummer auf Herrn Müller verweist. Wenn man dann nach den Verträgen von Herrn Müller sucht, durchsucht das Datenbankmanagementsystem alle Tabellen der 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 als Referenz. 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 spezieller die Suche ist.

Jetzt nehmen wir einmal an, Herr Erwin Müller heiratet Elke Fröhlich aus der Kornblumenstraße. Herr Müller ist ein fortschrittlicher Mensch und seinen Nachnamen konnte er eh noch nie so richtig leiden. Daher nimmt er den Namen seiner Frau an und zieht zu ihr. Selbstverständlich meldet er dies seiner Versicherung. In der Datenbank wird dann die erste 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. Laut Datenbank hat nun Herr Erwin Fröhlich sämtliche Verträge abgeschlossen und es ist auf den ersten 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 er Mü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 Versicherungspolice deutlich. 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ändiges Objekt gespeichert. Wenn man dann nach den Verträgen von Herrn Müller sucht, durchsucht das Datenbankmanagementsystem alle Objekte der Datenbank nach solchen, welche die Ausprägungen "Vertrag" und "Herr Müller" beinhalten. Es ist also möglich, direkt den Suchbegriffen zu folgen, ohne Referenzierung auf vielfältige andere Tabellen. Dies steigert die Leistungsfähigkeit der Suche innerhalb der Datenbank.

Gleichzeitig werden viele Informationen jedoch doppelt gespeichert – man spricht hier von redundanter Datenhaltung. Dies ist auch der Grund, weswegen objektorientierte Datenbanken lange Zeit wenig beachtet wurden – frühere Speichermedien wären bereits nach kurzer Zeit völlig überlastet gewesen. Heutzutage stellen Datenmengen in diesem Bereich seltenst eine Herausforderung dar.

Jetzt heiratet Herr Erwin Müller, Elke Fröhlich aus der Kornblumenstraße. Herr Müller nimmt den Namen seiner Frau an und zieht zu ihr. Selbstverständlich meldet er dies seiner Versicherung. In der Datenbank wird ein Verweis von Herrn Erwin Müller auf Herrn Erwin Fröhlich hinterlegt.

Die Datensätze werden hierdurch nicht geändert, ebenso wenig der Zusammenhang, in welchem sie gespeichert wurden. Wenn jetzt ein älterer Kollege sich an Herrn Müller erinnert und nach 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 Unterschiede beider Arten der Datenbankmodellierung dar:

Zum einen ist die Suche in relationalen Datenbanken deutlich verstrickter als in objektorientierten Systemen. Ergebnis sind längere Suchzeiten. Meiner Meinung nach folgen hieraus auch weniger Möglichkeiten der Suche. In jedem Falle sind die verschiedensten Suchmöglichkeiten innerhalb einer objektorientierten Struktur deutlich einfacher zu gestalten.

Zum anderen garantiert die objektorientierte Datenbank Unveränderlichkeit. Vor allem im Dokumentenmanagement ist dies ein nicht zu vernachlässigender Faktor. Selbstverständlich werden die Dokumente selbst auch in der relationalen Datenbank nicht verändert – nur der Zusammenhang, in welchem sie gespeichert sind. Doch reicht dies oftmals aus, um verwirrende Suchergebnisse zu liefern.

Es gibt noch viele andere Unterschiede zwischen beiden Datenbanken. So gehen heute fast sämtliche Programmiersprachen (Delphi, C++, Perl, Java) objektorientiert vor. Daher wird vor allem Software meist mit objektorientierten Programmiersprachen entwickelt. Diese objektorientierten Objekte in relationalen Datenbanken zu speichern oder sie damit zu verbinden ist selbstredend deutlich aufwendiger, als wenn beide Systeme einer Modellierung folgen.

Der relationale Ansatz ist für die Datenhaltung einfacher, stringenter Informationen mit wenigen Querverweisen zwischen den Datensätzen die beste Lösung. Doch gerade die umfangreichen Verknüpfungen zwischen Dokumenten, Personen, Unternehmen, etc. in Dokumentenmanagementsystemen sind innerhalb einer objektorientierten Datenbank deutlich besser abzubilden. So kann man in objektorientierten Datenbanken besser Strukturen abbilden (Unternehmen/Bereich/Abteilung) und die Datenbanken sind generell leistungsfähiger.

Dennoch beherrschen relationale Datenbanken den Markt im Dokumentenmanagement und es steht in den Sternen, ob sich dies jemals ändern wird. Aber in jedem Fall kennen wir jetzt den Unterschied zwischen beiden Modellierungen ein wenig besser…

02/2007, Pia Heine



Pia Heine arbeitet nach beratenden Tätigkeiten innerhalb des Produkt- und Kundenmanagement als Leiterin Marketing bei der Drivve GmbH & Co.KG, einem Hersteller von Software der Bereiche Customer Relationship Management, Dokumenten- und Workflowmanagement.


Kommentare zu diesem Beitrag 


Objektorientiert versus relational – Dat...  
Fachartikel 22.02.07
Re: Objektorientiert versus relational...  
Ulrich Fuchs 02.05.07
Re: Objektorientiert versus relation...  
Michael Friedrich 23.03.09
Re: Objektorientiert versus relati...  
L Supreme 11.05.09
Re: Objektorientiert versus rela...  
S. Lange 14.08.09
Re: Objektorientiert versus relati...  
M. Peter 13.11.09

Schreiben Sie einen Kommentar zu diesem Beitrag

Newsletter abonnieren

Verpassen Sie nichts und bleiben Sie informiert mit unserem Newsletter.
Ihre E-Mail Adresse:  
RSS-Feed: Alle News aktuellUnsere News auf Ihrer Website

Weitere Beiträge zu diesem Thema

Die DMS-Area auf der CeBIT 2007 zeigt den Weg zu mehr Effizienz im Büro
Auf der CeBIT 2007 zeigen Anbieter in der DMS-Area in der Halle 1, wie Unternehmen dokumentenbasierte Prozesse maßgeblich verbessern und gleichzeitig gesetzliche Bestimmungen einhalten...
Records Management – Anforderungen und Lösungen für die Aktenführung
Der Begriff Records Management kann mit "Aktenführung" übersetzt werden. Man versteht darunter die systematische Aufzeichnung von Geschäftsvorgängen und -Ergebnissen...
Aus der Praxis: Elektronische Rechnungseingangsbearbeitung leicht gemacht
Der Schritt zur vollständig digitalen Verarbeitung der Forderungen ist vergleichsweise einfach zu realisieren. Das Pharma-Unternehmen Schering hat in nur wenigen Wochen gemeinsam mit der Deutschen Post eine Lösung umgesetzt...
Storage-Strategien und Technologien zum Schutz von Unternehmensdaten
Business Continuity, Sicherheit und Verfügbarkeit von Daten spielen bei Unternehmen jeder Größenordnung eine zentrale Rolle...
E-Mail-System der Zukunft
Systemintegrator Document Dialog hat eine bundesweite Studie in Auftrag gegeben, die die "E-Mail-Systeme der Zukunft" näher beleuchtet. Erfragt wurden die Meinungen von rund 100 Fach- und Führungskräften...

Beiträge aus anderen Themenbereichen

Die große Nummer – IP-Adressen und Datenschutz
Ob Vorratsdatenspeicherung oder Auskunftsansprüche von Rechteinhabern – IP-Adressen sind zentraler Gegenstand von Ängsten und Begehren. Ob sie personenbezogene Daten sind, ist umstritten...
Game Server – Der Trend von Morgen
Game Server sind gewöhnliche Bestandteile von Spielen, welche Multiplayer Optionen anbieten und stellen heutzutage eine Standardfunktion dar. Doch Online Multiplayer sorgen leider nicht nur für Spass...
Systemvorstellung: aitsu Content Management System
aitsu ist ein Framework, das auf dem Web Content Management System Contenido aufsetzt. Contenido-Funktionen bleiben erhalten und werden durch weitere Framework-Funktionen ergänzt...

Sponsored Links

Erotische Fotografie
Das Content Management PortalDas Dokumenten Management PortalDas IT-Security PortalDas Customer Relationship Management PortalDas E-Commerce PortalDas Enterprise Resource Planning PortalPortal für VoIP und mobile KommunikationDas Magazin für IT im KrankenhausDas Verzeichnis für IT-Profis
homeimpressumerklärung zum datenschutz - privacy policykontaktwerbung

Schnellsuche