Unterschied relationale und objektrelationale Datenbank

[Volker72]

Hallo zusammen,
könnt ihr mir den Unterschied zwischen relationale und Objektrelationale Datenbanken aufzeigen anhand eines Beispieles ?

Wäre echt klasse.

[Andreas Kosch]

Hallo,

der Unterschied zwischen beiden Arten liegt darin, dass bei einer relationalen Datenbank (RDBMS) die Daten als "Schatz" im Mittelpunkt stehen (Objekte im Clientprogramm != Daten), während bei einer objektrelationalen Datenbank (OODBMS) die Vereinfachung für den Entwickler (Objekte im Programm = Objekte in der Datenbank) im Mittelpunkt steht. Die im OODBMS gespeicherten Daten sind daher im Vergleich zum RDBMS nur eingeschränkt auswertbar/kombinierbar. Aus diesem Grund sind die 1990 von Object Data Management Group (ODMG) standardisierten OODBMS auch grandios gescheitert und geistern nur noch als "Zombies" herum ;-)

[yetibrain]

Unterschied zwischen relationale und Objektrelationale Datenbanken

Hallo zusammen,
könnt ihr mir den Unterschied zwischen relationale und Objektrelationale Datenbanken aufzeigen anhand eines Beispieles ?

Wäre echt klasse.

Klar gerne!

Bei relationalen Datenbanken gibt es quasi nur 2-dimensionale Tabellen, ähnlich wie bei einer Excel-Tabelle. Die Spalten die man definieren und benennen kann ist die erste Dimension, die sogenannten Felder, zusammen gesehen ist das die Datensatz-Definition bzw. eine record-Definition. Die zweite Dimension sind eben die Datensätze/Records die man dann speichert.

Beispiel:

Vorname----Nachname-----Alter
Charly Braun 12
Simon Templar 34

Nachteile:

Jeder Datensatz hat die gleichen statischen Felder.

Ein Feld ist kein Array (es gibt RDBMS die es unterstützen, ist aber eingeschränkt und eher die Ausnahme) , man kann also z. B. für ein und dieselbe Person nicht mehrere Vornamen speichern.

Um letzteres z. B. zu realisieren muss man mit einem RDBMS eine zweite Tabelle definieren, welche die Vornamen enthält. Diese setzt man dann in eine Master-Detail Beziehung, auch als 1 zu n Beziehung bekannt. Dazu benötigt man nicht nur den Vornamen in der zweiten Tabelle sondern noch ein Feld, welches über konkrete Daten (hier z. B. Nachname) jeden Vornamen-Datensatz dem entsprechenden Nachnamen-Datensatz zuordnet. So findet man über einen Vornamen-Datensatz den entsprechenden Nachname-Datensatz um z. B. das Alter zu erfahren, der Nachname würde ja schon auch im Vornamen-Datensatz stehen (Hier kommen wir gleich zu einem weiteren Nachteil). Für einen Nachname-Datensatz kann man nun alle Vornamen über den Nachname-Schlüssel finden.

Redundanz. Über sogenannte Primär- und Sekundaärschlüssel definiert man die Relationen, das bedeutet aber dass ein und dieselben Daten meistens in den Schlüsselfeldern n-fach in den in Beziehung stehenden Tabellen vorkommen. Noch mehr Redundanz entsteht wenn man dann für diese Index-Felder Indexdateien anlegt um Abfragen zu beschleunigen.

Eingeschränkte Modellierungsmöglichkeiten von Datenstrukturen. Meistens können nur elementare Datentypen verwendet werden wie etwa Integer, Floats, Strings aber auch z. B. Datumstypen. Man kann zwar beliebige Octets in einem sogenannten BLOB speichern, aber Daten in diesen BLOBs nur durch verfügbare Metadaten, meist in Verbindung mit speziellen Funktionsaufrufen innerhalb eines SQL-Query abfragen.

Die Relationen von Tabellen in einem RDBMS sind meist separat gespeichert, sogenannte Constraints. Gehen diese Informationen verloren hat man schnell verwaiste Tabellen. Eine Tabelle kennt seine Beziehungen nicht. Es ist möglich vollkommen absurde Abfragen zu machen über Relationen von Tabellen (mit JOIN SQL-Anweisung) die nicht stimmen.

Bei Abfragen müssen die Relationen zwischen Tabellen bekannt sein und in jeder Abfrage angegeben werden (obwohl diese statisch sind und sich nicht ändern). Abfragen mit vielen JOINS werden schnell unübersichtlich und es können sich so Fehler einschleichen.

Wenn wie im o. g. Beispiel ein Vorname nicht bekannt ist und es keinen Datensatz hierfür gibt, fehlt bei einer Abfrage auch der Nachname-Datensatz. Man muss sogenannte OUTER-JOINS benutzen um diesen Effekt zu umgehen.

Paradigmenwechsel. Verwendet man in einer Sprache wie etwa C# SQL-Abfragen dann hat man eine Sprache innerhalb einer Sprache.

Vorteile

Einfach zu erlernen, da nur 2-dimensionale Tabellen.
SQL-Standard weit verbreitet.

---------------------
OODBMS folgt später.....

[yetibrain]

OODBMS versus RDBMS

Hallo zusammen,
könnt ihr mir den Unterschied zwischen relationale und Objektrelationale Datenbanken aufzeigen anhand eines Beispieles ?

Wäre echt klasse.

Klar gerne!


Bei einem OODBMS bist du beim Modellieren der Datenstruktur nicht auf 2-dimensionale Tabellen beschränkt sondern kannst Klassen definieren und/oder vorhandene Klassen benutzen. Nehmen wir als Beispiel folgende Klasse:

class Person
{

String Vorname;
String Nachname;
Integer Alter;

....Methoden()
}


Bei solch einer Klasse wird man natürlich auch noch Methoden definieren welche zum Beispiel eine Dialogbox aufrufen in die man Daten für eine neue Person eingeben kann. Oder eine Methode um die Daten wieder am Bildchirm anzuzeigen.

Wenn nun Daten in solch einem Objekt existieren und diese persistent gespeichert werden sollen, dann müssen bei einem OODBMS diese Daten nicht von A nach B kopiert werden wie z. B. bei Benutzung einer relationalen Datenbank, wo man ein SQL-INSERT statement zusammennageln müsste. Stattdessen kann sich das Objekt über einen simplen Methodenaufruf wie etwa object.Store() selbst speichern. Danach kannst du den Rechner abschalten, denn die Daten sind auf Scheibe und können wieder geholt und als Objekte erzeugt werden. Hierfür lädt das OODBMS die Objekte von Scheibe und creiert die Objekte wieder im Memory. Sämtliche referenzierte Objekte werden auch gespeichert, abhängig von der Einstellung der "Tiefe" bzw. vom Level.

Wenn man z. B. mehrere Vornamen speichern will so ist der Aufwand bei einem RDBMS enorm, da man wie ich bereits erläutert habe mit einer Tabelle nicht mehr auskommt. Da man bei einem OODBMS aber Klassen benutzen kann und im Grunde alle Containertypen wie etwa arrays, collections, hashes etc. ist man viel flexibler beim modellieren. Man ändert die Klasse einfach wie folgt:

class Person
{

StringArray Vorname;
String Nachname;
Integer Alter;

....Methoden()
}

Du verwendest statt einem String einfach ein StringArray für den Vornamen und das wars. Ob du nun keinen oder einen oder mehrere Vornamen zu einer Person hast, alles ist damit abgedeckt. Wenn so ein Objekt gespeichert wird dann werden auch automatisch alle Vornamen mitgespeichert. Natürlich kann man auch Objekte anderer Klassen als member einer Klasse verwenden. Volle Flexibilität.

Auch Vererbung von Klassen und das speichern solcher ist natürlich möglich. Vor allem wenn virtuelle Funktionen benutzt werden kannst du z. B. alle Objekte abgeleiteter Klassen über eine Abfrage in ein Collection-Objekt des Basisklassentyps laden und dann über eine Iteration eine bestimmte Methode aufrufen wobei jeweils die korrekte Methode des entsprechenden Objekts aufgerufen wird. OODBMS erlauben es z. B. alle Objekte einer bestimmten Klasse wieder von Scheibe zu laden und zu instanzieren, dabei musst du keinen einzigen "new" absetzen, das OODBMS erledigt das alles für dich, auch das verpointern referenzierter Objekte. Bei einem Query kann man natürlich auch Abfragekriterien definieren wie in dem genannten Beispiel z. B. das herholen aller Person eines bestimmten Alters.

Ein weiterer Vorteil ist dass du dieselbe Sprache bei einer Abfrage benutzen kannst, also das sogenannte native query. Man ist nicht gezwungen eine andere Sprache zur Abfrage zu benutzen wie etwa SQL. Du bleibst z. B. einfach bei deinem C#.

Auch brauchst du keine Fremdschlüssel wie bei einem RDBMS, referenzierte Objekte werden automatisch mit abgespeichert.

Wie das ganze im Detail funktioniert kann man etwa bei db4o nachlesen oder am Besten selbst ausprobieren.

So, das wars, ich hoffe es war verständlich und hilfreich.