¿Cómo diseñar relaciones de muchos a muchos en una base de datos de objetos?

Question

Pensé que ya era hora de echar un vistazo a las bases de datos OO y decidí usar db4o para mi próximo pequeño proyecto: una pequeña biblioteca.

Considere los siguientes objetos:Libro, Categoría.

Un Libro puede estar en categorías 0-n y una Categoría se puede aplicar a Libros 0-m.

Lo primero que pensé es tener un objeto de unión como BookCatecory, pero después de buscar un poco en Google veo que no es apropiado para 'Real OO'.

Entonces, otro enfoque (recomendado por muchos) es tener una lista en ambos objetos:Libro.categorías y Categoría.libros.Un lado maneja la relación:Book.addCategory agrega categoría a Book.categories y libro a Category.books.¿Cómo manejar confirmaciones y reversiones cuando se modifican 2 objetos dentro de una llamada a un método?

¿Cuáles son tus pensamientos?El segundo enfoque tiene ventajas obvias pero, al menos para mí, el primero "parece" correcto (mejor normado).

Answer 1

Si utiliza la base de datos de objetos que no es necesario preocuparse de cómo se almacenan las relaciones en la base de datos. Se definen las clases y las relaciones entre ellos. Por favor, lea la referencia guiada a su base de datos. Ejemplos de relaciones:

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

En realidad, solo se me ocurren dos formas de resolver este problema, las cuales usted mencionó.Personalmente, optaría por el primer enfoque (crear un objeto de mapeo como una entidad OO).Esto evita que usted mantenga información redundante y tenga que sincronizarla;también significa que si la asociación termina teniendo campos propios (la fecha en que el libro fue asignado a esa categoría, digamos), se pueden incorporar fácilmente.Utilizamos este enfoque para una variedad de asociaciones en nuestro sistema.

Las entidades OO se verían así:

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

Aquí tienes que mantener sincronizados el objeto de relación y las dos colecciones;sin embargo, las colecciones son opcionales en este caso.Normalmente podrías obtener la misma información con una consulta ORM, algo como:seleccione b.book de BookCategory b donde b.category = MyCategory

La alternativa es tener una configuración como:

Book {
 Collection<Category> categories
}

Category {
 Collection<Books> books
}

Si su herramienta ORM/DB mantiene automáticamente las asociaciones, está bien;de lo contrario, no podrá actualizar ambas colecciones.(En Hibernate, un lado tendrá la propiedad:inverso=verdadero en el mapeo;este lado no está actualizado, por lo que estrictamente hablando no es necesario mantenerlo.Sin embargo, esto me parece una mala práctica).

Si normalmente sólo accede a la relación de una manera (por ejemplo, obteniendo todos los libros de una categoría), puede eliminar la colección del otro lado;entonces creo que tendrías que solucionar la herramienta ORM y utilizar una consulta nativa para acceder a la relación desde la otra dirección.

Usamos Hibernate (una herramienta de mapeo relacional de objetos basada en Java) en nuestro proyecto;Los documentos de Hibernate son una buena referencia para problemas de diseño relacional/OO, aunque es posible que tengas que dedicar un poco de tiempo a aprender Hibernate para que sean útiles:http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues

¡HH!

Answer 3

Creo que eres un poco atascado en el camino db relacional de pensamiento. Listas en cada objeto es lo que hay que hacer OO. Confirmaciones y reversiones no son un problema, que se produzcan en una transacción que compromete todo o deshace todo.

Answer 4

En una base de datos OO pura como la piedra preciosa de los propios objetos tienen colecciones de referencias a otros objetos. Cuando se hace referencia el objeto de la aplicación del OODBMS genera un proxy que envuelve el objeto. El esquema para esto es sólo el objeto persistió y su colección de referencias a los objetos que se refiere. El SGBDOO no necesita necesariamente una entidad de enlace.

Con una capa de mapeo O / R (asumiendo que es lo suficientemente inteligente como para hacer M: relaciones M) el M: relación M se manifiesta como una colección de referencias subsidiarios sobre el objeto mismo que el asignador de O / R tiene el enlace entidad detrás de las escenas. No todos los creadores de mapas O / R ello, por lo que pueden tener un objeto enlace separado.

Answer 5

¿Tiene alguna razón en particular que quería utilizar un ODBMS? Para estructuras de datos simples (como la clasificación de los libros) por lo general no encontrará ninguna ventaja en ODBMS sobre RDBMS, y de hecho tendrá un tiempo más fácil trabajar en el mundo mucho-más-estandarizada de RDBMS. ODBMS tiene ventajas muy tangibles cuando se trabaja con tipos de datos complejos o literal persistencia / almacenamiento de objetos dinámicos. ODBMS también se cita como siendo mucho más rápido y más escalable que RDBMS, aunque puedo ofrecer poca información sobre esto mismo. Aquí hay un par de páginas que tratan sobre RDBMS vs ODBMS, sin embargo:

Qué fue de bases de datos orientada a objetos

Base de datos vs. Object-Rleational de base de datos (SO) Object-Oriented

Answer 6

Yo evitaría la duplicación de datos, ya continuación, se encuentra con todo tipo de problemas con la fusión de las diferencias.

El truco para esto es referencias.

el resultado es que tendría cada objeto contiene una colección de referencias al otro tipo de objeto, así como tener una colección independiente de los otros objetos.

La mesa de juego es un concepto relacional, a menos que esa clase de conexión intermediario puede tener propiedades que no son atribuibles a cualquiera de los objetos. Es allí, ya que permite realizar consultas a ser escritos de una manera poderosa, ya que reduce la relación de 2 a uno muchas relaciones y reduce en gran medida la duplicación de datos. Si hizo esto en una base de datos sin relación con la mesa de juego, entonces las cosas se pondrían mal muy rápidamente - cómo funcionaría una actualización? Personalmente, creemos que la atracción de las bases de datos oo estar alejándose de este

la forma en que iba a unir todos los objetos juntos es a través de eventos en código a algún tipo de manejador de transacciones para permitir el almacenamiento en caché de objetos estados. así que en lugar de la manipulación de objetos cada otros propiedades que solicitar un cambio a través de la guía y esperan el resultado en una devolución de llamada.