Come progettare molti-a-molti rapporti in un oggetto di database?

Question

Ho pensato che era il momento di guardare OO database e ha deciso di utilizzare db4o per il mio piccolo progetto, una piccola biblioteca.

Considerare i seguenti oggetti:Libro Di Categoria.

Un Libro può essere 0-n categorie e una Categoria può essere applicato a 0-m Libri.

Il mio primo pensiero è quello di avere un entrare in oggetto come BookCatecory ma dopo un po ' di Googling vedo che questo non è appropriato per 'Reale OO'.

Un altro approccio (consigliato da molti) è quello di avere una lista sia oggetti:Libro.categorie e di Categoria.libri.Un lato gestisce la relazione:Libro.addCategory aggiunge Categoria a Libro.categorie e Libro di Categoria.libri.Come gestire il commit e rollback quando 2 oggetti sono stati alterati all'interno di un metodo di chiamata?

Quali sono i tuoi pensieri?Il secondo approccio ha evidenti vantaggi, ma, almeno per me, il primo 'si sente' a destra (meglio normed).

Answer 1

Se si utilizza database ad oggetti che non è necessario per la cura come le relazioni sono memorizzati nel database. È possibile definire le classi e le relazioni tra di loro. Si prega di leggere il riferimento guidata al database. Esempi di rapporti:

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

Ci sono solo due modi che posso pensare di risolvere questo problema, entrambi i quali è già detto.Personalmente, vorrei andare con il primo approccio (la creazione di un oggetto di mapping come OO entità).Questo impedisce di mantenere le informazioni ridondanti di tutto e di dover sincronizzare;significa anche che se l'associazione si finisce per avere campi di sua proprietà (la data in cui il libro è stato assegnato alla categoria, diciamo), che può essere incorporato facilmente.Possiamo utilizzare questo approccio per una varietà di associazioni nel nostro sistema.

Le OO entità simile:

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

Qui è necessario mantenere il rapporto oggetto e le due collezioni in sincronia;tuttavia, le collezioni sono opzionali in questo caso.In genere si potrebbe ottenere la stessa informazione con un ORM query, qualcosa di simile a:selezionare b.libro da BookCategory b, dove b.categoria = MyCategory

L'alternativa è avere una configurazione come:

Book {
 Collection<Category> categories
}

Category {
 Collection<Books> books
}

Se il tuo ORM/DB strumento mantiene automaticamente le associazioni, questo è bene;in caso contrario, si è bloccato l'aggiornamento di entrambe le collezioni.(In modalità di Ibernazione, da un lato avrà la proprietà:inverso=true sulla mappatura;questo lato non è aggiornato, quindi a rigor di termini, non ha bisogno di essere mantenuto.Questa mi sembra una pessima abitudine, però.)

Se in genere l'accesso solo il rapporto in un modo (per esempio, di prendere tutti i libri in una categoria), si potrebbe eliminare la raccolta dell'altro lato;quindi penso che si dovrebbe aggirare il ORM e utilizzare un nativo di query per l'accesso al rapporto da un'altra direzione.

Utilizziamo Hibernate (basato su java Object Relational Mapping tool) sul nostro progetto;la Sospensione docs sono un buon riferimento per OO/relazionale problemi di progettazione, se si può avere a spendere un po ' di tempo di apprendimento di Sospensione per fare qualcosa di utile:http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues

HTH!

Answer 3

Credo che tu sia solo un po 'appeso sulla via db relazionale di pensare. Le liste in ogni oggetto è il diritto OO cosa da fare. Commit e rollback non sono un problema, si verificano in una transazione che impegna tutto o rotola indietro tutto.

Answer 4

In un database puro OO come GemStone gli oggetti stessi hanno collezioni di riferimenti ad altri oggetti. Quando l'oggetto viene fatto riferimento dall'applicazione del OODBMS genera un proxy che avvolge l'oggetto. Lo schema di questo è solo l'oggetto persistente e la sua collezione di riferimenti agli oggetti cui si riferisce. L'OODBMS non ha necessariamente bisogno di un soggetto di collegamento.

Con un livello di mappatura O / R (ammesso che sia abbastanza intelligente da fare M: rapporti M) M: rapporto M si manifesta come un insieme di riferimenti controllate sull'oggetto stesso, che il mapping O / R risolve al link entità dietro le quinte. Non tutti / mapper R O fare questo, quindi si può avere un oggetto di collegamento separato.

Answer 5

Hai qualche motivo particolare si voleva utilizzare un ODBMS? Per le strutture di dati semplici (come categorizzare libri) in genere non troverete alcun vantaggio in ODBMS su RDBMS, e infatti avrà un tempo più facile lavorare nel mondo tanto più standardizzato di RDBMS. ODBMS ha vantaggi molto concreti quando si lavora con i tipi di dati complessi o letterale persistenza / stoccaggio di oggetti dinamici. ODBMS è anche citato come essendo molto più veloce e più scalabile di RDBMS, anche se posso offrire visione poco in questo io stesso. Qui ci sono un paio di pagine che discutono RDBMS contro ODBMS, però:

Whatever Happened to Object-Oriented Database

Object-Oriented Database vs Object-Rleational Database (SO)

Answer 6

Vorrei evitare la duplicazione dei dati, perché poi si esegue in tutti i tipi di problemi con la fusione delle differenze.

Il trucco per questo è riferimenti.

il risultato è che avrei ciascun oggetto contiene un insieme di riferimenti altro tipo di oggetto, oltre ad avere una collezione indipendente dagli altri oggetti.

La tabella di corrispondenza è un concetto relazionale, a meno che una classe di collegamento intermediario può avere proprietà che non sono attribuibili a uno degli oggetti. E 'lì in quanto consente di eseguire query da scrivere in un modo potente in quanto riduce il rapporto con 2 uno a molti rapporti e riduce notevolmente la duplicazione dei dati. Se avete fatto queste cose in un database relazione senza la tabella di corrispondenza e poi le cose sarebbero male molto rapidamente - come sarebbe un aggiornamento operare? Personalmente trovo l'attrazione di banche dati oo essere allontanandosi da questo

il modo in cui vorrei collegare tutti gli oggetti insieme è attraverso eventi nel codice per un qualche tipo di gestore delle transazioni per consentire la memorizzazione nella cache di oggetti stati. Quindi, piuttosto che oggetti manipolare ogni altri proprietà chiedono un cambiamento attraverso il conduttore e attendono il risultato in una richiamata.