Como projetar relacionamentos muitos para muitos em um banco de dados de objetos?

Question

Eu pensei que estava na hora de dar uma olhada nos bancos de dados OO e decidi usar o DB4O para o meu próximo pequeno projeto - uma pequena biblioteca.

Considere os seguintes objetos: livro, categoria.

Um livro pode estar nas categorias 0-N e uma categoria pode ser aplicada a livros de 0 m.

Meu primeiro pensamento é ter um objeto de junção, como o BookCatecory, mas depois de um pouco de pesquisas no Google, vejo que isso não é apropriado para 'OO real'.

Portanto, outra abordagem (recomendada por muitos) é ter uma lista em ambos os objetos: book.categories e category.books. Um lado lida com o relacionamento: book.addcategory adiciona categoria à book.categories e livro a category.books. Como lidar com compromissos e reversões quando 2 objetos são alterados em uma chamada de método?

Quais são seus pensamentos? A segunda abordagem tem vantagens óbvias, mas, pelo menos para mim, o primeiro 'parece certo' (melhor normalmente).

Answer 1

Se você usa o banco de dados de objetos, não precisa se importar com a forma como as relações são armazenadas no banco de dados. Você define classes e relacionamentos entre elas. Leia a referência guiada ao seu banco de dados. Exemplos de relacionamentos:

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

Na verdade, existem apenas duas maneiras de pensar para resolver esse problema, as quais você mencionou. Pessoalmente, eu iria com a primeira abordagem (criando um objeto de mapeamento como uma entidade OO). Isso impede que você mantenha informações redundantes e tendo que sincronizar; Isso também significa que, se a associação acabar tendo campos próprios (a data em que o livro foi atribuído a essa categoria, digamos), eles podem ser incorporados facilmente. Usamos essa abordagem para uma variedade de associações em nosso sistema.

As entidades OO seriam:

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

Aqui você deve manter o objeto de relação e as duas coleções em sincronia; No entanto, as coleções são opcionais neste caso. Normalmente, você pode obter as mesmas informações com uma consulta ORM, algo como: Selecione B.Book FRO

A alternativa é ter uma configuração como:

Book {
 Collection<Category> categories
}

Category {
 Collection<Books> books
}

Se a sua ferramenta ORM/DB mantiver automaticamente as associações, tudo bem; Caso contrário, você está atualizando as duas coleções. (Em Hibernate, um lado terá a propriedade: Inverse = true no mapeamento; este lado não é atualizado; portanto, estritamente falando, não precisa ser mantido. Isso me parece uma prática ruim.)

Se você normalmente acessa apenas a relação de uma maneira (por exemplo, obtendo todos os livros em uma categoria), poderá eliminar a coleção do outro lado; Então eu acho que você teria que contornar a ferramenta ORM e usar uma consulta nativa para acessar o relacionamento da outra direção.

Usamos o Hibernate (uma ferramenta de mapeamento relacional de objetos baseada em Java) em nosso projeto; Os documentos de hibernato são uma boa referência para problemas de design OO/relacional, embora você possa ter que gastar um pouco de tempo aprendendo hibernados para torná -los úteis:http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-fvalues

HTH!

Answer 3

Eu acho que você está apenas um pouco pendurado na maneira relacional de banco de dados. As listas em cada objeto são a coisa certa a fazer. Comprometes e reverso não são problemas, eles acontecem em uma transação que comete tudo ou revira tudo.

Answer 4

Em um banco de dados OO puro, como pedra preciosa, os próprios objetos têm coleções de referências a outros objetos. Quando o objeto é referenciado a partir do aplicativo, o OODBMS gera um proxy que envolve o objeto. O esquema para isso é apenas o objeto persistido e sua coleção de referências aos objetos a que se refere. O OODBMS não precisa necessariamente de uma entidade de link.

Com uma camada de mapeamento de O/R (supondo que seja inteligente o suficiente para fazer relacionamentos M: M), o relacionamento M: M se manifesta como uma coleção de referências subsidiárias no próprio objeto que o mapeador O/R resolve para a entidade Link por trás do cenas. Nem todos os mapeadores O/R fazem isso, para que você possa ter um objeto de link separado.

Answer 5

Você tem algum motivo específico que deseja usar um ODBMS? Para estruturas de dados simples (como categorizar livros), você geralmente não encontra vantagem nos ODBMs sobre o RDBMS e, de fato, terá mais facilidade em trabalhar no mundo muito mais padronizado de RDBMs. O ODBMS tem vantagens muito tangíveis quando você está trabalhando com tipos de dados complexos ou persistência/armazenamento literal de objetos dinâmicos. O ODBMS também é citado como sendo muito mais rápido e mais escalável que o RDBMS, embora eu possa oferecer pouca visão disso. Aqui estão algumas páginas que discutem RDBMS vs. ODBMS, no entanto:

O que quer que tenha acontecido com bancos de dados orientados a objetos

Banco de dados orientado a objetos vs. Banco de dados de objetos-rleationais (SO)

Answer 6

Eu evitaria a duplicação de dados porque você encontra todos os tipos de problemas com a fusão das diferenças.

O truque para isso são referências.

O resultado é que eu teria cada objeto que contém uma coleção de referências ao outro tipo de objeto, além de ter uma coleção independente de outros objetos.

A tabela correspondente é um conceito relacional, a menos que a classe de conexão intermediária possa ter propriedades que não sejam atribuíveis a nenhum dos objetos. Ele está lá, pois permite que as consultas sejam escritas de maneira poderosa, pois reduz a relação com 2 a muitas relações e reduz bastante a duplicação de dados. Se você fizesse isso em um banco de dados de relação sem a tabela correspondente, as coisas ficariam mal rapidamente - como uma atualização funcionaria? Pessoalmente, acho que a atração dos bancos de dados OO para se afastar disso

A maneira como eu uniria todos os objetos é através de eventos em código para algum tipo de manipulador de transações para permitir o cache dos estados de objetos. Portanto, em vez de os objetos manipularem as propriedades, eles solicitam uma alteração através do manipulador e aguardam o resultado em um retorno de chamada.