Wie gestaltete ich viele zu viele Beziehungen in einer Objektdatenbank?

Question

Ich dachte, es wäre an der Zeit, sich OO -Datenbanken anzusehen, und beschloss, DB4O für mein nächstes kleines Projekt zu verwenden - eine kleine Bibliothek.

Betrachten Sie die folgenden Objekte: Buch, Kategorie.

Ein Buch kann in 0-N-Kategorien sein und eine Kategorie kann auf 0-m-Bücher angewendet werden.

Mein erster Gedanke ist, ein Beitrittsobjekt wie BookCateCory zu haben, aber nach ein wenig googeln sehe ich, dass dies nicht für "echte OO" geeignet ist.

Ein weiterer Ansatz (von vielen empfohlen) besteht also darin, eine Liste in beiden Objekten zu haben: book.categories und category.books. Eine Seite behandelt die Beziehung: book Wie kann ich mit Commits und Rollbacks umgehen, wenn 2 Objekte innerhalb eines Methodenaufrufs geändert werden?

Was sind deine Gedanken? Der zweite Ansatz hat offensichtliche Vorteile, aber zumindest für mich fühlt sich der erste "richtig" (besser normiert).

Answer 1

Wenn Sie die Objektdatenbank verwenden, müssen Sie sich nicht darum kümmern, wie die Beziehungen in der Datenbank gespeichert werden. Sie definieren Klassen und Beziehungen zwischen ihnen. Bitte lesen Sie die in Ihre Datenbank geführte Referenz. Beispiele für Beziehungen:

n:n attribute, referencing from the parent
------------------------------------------------------------------
class Person{
List addresses;
}

class Address{
}


n:n attribute, referencing from the child
------------------------------------------------------------------
class Person{
}

class Address{
List persons
}

n:n attribute, bidirectional references
------------------------------------------------------------------
class Person{
List addresses;
}

class Address{
List persons
}

Answer 2

Es gibt wirklich nur zwei Möglichkeiten, wie ich denken kann, um dieses Problem zu lösen, die beide erwähnt haben. Persönlich würde ich mit dem ersten Ansatz (Erstellen eines Mapping -Objekts als OO -Entität) gehen. Dies hindert Sie daran, redundante Informationen in der Nähe zu halten und synchronisieren zu müssen. Dies bedeutet auch, dass die Vereinigung, wenn die Vereinigung eigene Felder haben (das Datum, an dem das Buch dieser Kategorie zugewiesen wurde, sagen wir, sie können leicht aufgenommen werden. Wir verwenden diesen Ansatz für eine Vielzahl von Assoziationen in unserem System.

Die OO -Entitäten würden aussehen wie:

BookCategory {
 Book book
 Category category
}
Book {
 Collection <BookCategory> categories
}
Category {
 Collection <BookCategory> categories
}

Hier müssen Sie das Beziehungsobjekt und die beiden Sammlungen synchronisieren; Die Sammlungen sind in diesem Fall jedoch optional. Normalerweise können Sie dieselben Informationen mit einer ORM -Abfrage erhalten, so etwas wie: Wählen Sie B.Book aus der Buchkategorie B, wo b.category = mycategory

Die Alternative besteht darin, ein Setup zu haben wie:

Book {
 Collection<Category> categories
}

Category {
 Collection<Books> books
}

Wenn Ihr ORM/DB -Tool die Assoziationen automatisch verwaltet, ist dies in Ordnung. Andernfalls stecken Sie fest und aktualisieren beide Sammlungen. (In Hibernate hat eine Seite die Eigenschaft: Inverse = True on the Mapping; diese Seite ist nicht aktualisiert, so dass sie mir streng genommen nicht aufrechterhalten werden muss. Dies scheint mir jedoch eine schlechte Praxis zu sein.)

Wenn Sie normalerweise nur auf die Beziehung zugreifen (z. B. alle Bücher in einer Kategorie einbeziehen), können Sie die Sammlung auf der anderen Seite beseitigen. Dann denke ich, dass Sie im ORM -Tool umgehen und eine native Abfrage verwenden müssten, um auf die Beziehung aus der anderen Richtung zuzugreifen.

Wir verwenden Hibernate (ein Java-basierter Objekt-Relational-Mapping-Tool) für unser Projekt. Die Hibernate -Dokumente sind eine gute Referenz für OO/Relational Design -Probleme, obwohl Sie möglicherweise ein wenig Zeit damit verbringen müssen, Winterschlaf zu lernen, um sie nützlich zu machen:http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues

HTH!

Answer 3

Ich denke, du bist nur ein wenig auf der relationalen DB -Denkweise aufgehängt. Listen in jedem Objekt sind die richtige OO -Sache. Commits und Rollbacks sind kein Problem, sie passieren in einer Transaktion, die alles begeht oder alles zurückrollt.

Answer 4

In einer reinen OO -Datenbank wie Gemstone haben die Objekte selbst Sammlungen von Verweise auf andere Objekte. Wenn das Objekt aus der Anwendung verwiesen wird, erzeugt OODBMS einen Proxy, der das Objekt umhüllt. Das Schema dafür ist nur das anhaltende Objekt und seine Sammlung von Verweisen auf die Objekte, auf die es sich bezieht. Das OODBMS benötigt nicht unbedingt eine Link -Entität.

Mit einer O/R -Mapping -Schicht (vorausgesetzt, sie ist klug genug, um M: M -Beziehungen zu machen) ist die M: M -Beziehung als Sammlung von Nebenreferenzen auf dem Objekt selbst manifest Szenen. Nicht alle O/R -Mapper tun dies, daher haben Sie möglicherweise ein separates Linkobjekt.

Answer 5

Haben Sie einen bestimmten Grund, warum Sie ein ODBMS verwenden wollten? Für einfache Datenstrukturen (z. B. Kategorisierungsbücher) finden Sie im Allgemeinen keinen Vorteil in ODBMs gegenüber RDBMs und es wird sich tatsächlich leichter in der vielmorexponierten Welt der RDBMs arbeiten. ODBMS hat sehr greifbare Vorteile, wenn Sie mit komplexen Datentypen oder buchstäblicher Persistenz/Speicherung dynamischer Objekte arbeiten. ODBMS wird auch als viel schneller und skalierbarer als RDBMs bezeichnet, obwohl ich selbst wenig Einblick in dies geben kann. Hier sind jedoch ein paar Seiten, auf denen RDBMS gegenüber ODBMS besprochen wird:

Was auch immer mit objektorientierten Datenbanken passiert ist

Objektorientierte Datenbank vs. Object-Rleational-Datenbank (SO)

Answer 6

Ich würde Datenverdoppelung vermeiden, weil Sie dann auf alle möglichen Probleme beim Zusammenführen der Unterschiede stoßen.

Der Trick dafür sind Referenzen.

Das Ergebnis ist, dass jedes Objekt eine Sammlung von Verweise auf den anderen Objekttyp sowie eine unabhängige Sammlung der anderen Objekte enthält.

Die Übereinstimmungstabelle ist ein relationales Konzept, es sei denn, diese Zwischenverbindungsklasse kann Eigenschaften haben, die auf keiner der Objekte zurückzuführen sind. Es ist da, da es dazu ermöglicht wird, auf eine leistungsstarke Weise zu schreiben, da es die Beziehung zu 2 eins zu vielen Beziehungen reduziert und die Datenverdoppelung erheblich verringert. Wenn Sie dies in einer Beziehungsdatenbank ohne die passende Tabelle tun würden, würde die Dinge sehr schnell das Böse werden - wie würde ein Update funktionieren? Persönlich finde ich die Anziehungskraft von OO -Datenbanken davon ab

Die Art und Weise, wie ich alle Objekte zusammenbinden würde, ist über Ereignisse im Code an eine Art Transaktionshandler, um das Zwischenspeichern von Objektstaaten zu ermöglichen. Anstatt sich gegenseitig die Eigenschaften zu manipulieren, fordern sie eine Änderung durch den Handler an und warten auf das Ergebnis eines Rückrufs.