Come specializzazioni ORM non disgiunte

Question

Come specializzazioni ORM non disgiunte

#1 da (3 voti)
#2 da (1 voti)

2

Considera questo esempio altamente semplificato di dati relazionali (ogni tabella può essere coinvolta in relazioni uno-a-molti e molti-a-molti non mostrate qui):

people
+-------+------+--------+
| name  | born | gender |
+-------+------+--------+
| Alice | 1980 |      F |
| Bob   | 1975 |      M |
| Carl  | 1994 |      M |
| Dot   | 1942 |      F |
+-------+------+--------+

workers                         students
+-------+---------+-------+     +-------+-------------+-------+
| name  | company | since |     | name  | institution | since |
+-------+---------+-------+     +-------+-------------+-------+
| Alice | Soylent |  2003 |     | Alice | Western     |  2001 |
| Bob   | HAL     |  1999 |     | Carl  | Eastern     |  2012 |
+-------+---------+-------+     +-------+-------------+-------+

Alcune persone sono lavoratori (Bob), alcuni sono studenti (Carl), altri no (Dot).
Alcuni sono entrambi (Alice).

Mappare a OOP, sarebbe semplice avere tre classi, come:

class Worker extends Person

class Student extends Person

Ma va bene fintanto che la specializzazione è disgiunto : oggetto alice non può essere istanza di Worker e Student al stesso tempo . Se ottieni un elenco di oggetti Person , non puoi trasmettere lo stesso elemento a entrambe le sottoclassi.

Innanzitutto, esiste un nome specifico per questo caso di mancata corrispondenza dell'impedenza (probabilmente comune)?

Successivamente, supponi di non poter modificare lo schema . Potrei avere il mio modo di risolvere il problema con OOP, ma sono principalmente interessato al tuo. Esiste una sorta di linea guida per le migliori pratiche ?
Questo esempio ha solo due relazioni ISA, ma la mia impressione è, più sotto-entità non-disgiunte , più OOP diventa scomodo.

object-oriented inheritance orm

posta matpop 14.11.2014 - 16:51

fonte

2 risposte

Leggi altre domande sui tag object-oriented inheritance orm

Controlli web di terze parti e accoppiamento stretto Come è stato utilizzato per la prima volta l'orologio di sistema nei primi computer?

score 3 · Answer 1

Un modo per farlo sarebbe quello di modellarlo nell'applicazione usando la composizione:

//maps to the table PEOPLE
class Person
{
   String name;
   Date birthdate;
   GenderEnum gender;

   Worker workerAttributes;
   Student studentAttributes;
}

//maps to the table WORKERS
class Worker
{
   String name;
   String company;
   Date since;
}

//maps to the table STUDENTS
class Student
{
   String name;
   String institution;
   Date since;
}

Ogni oggetto Person contiene un oggetto contenente informazioni Worker e informazioni Studente. Quando compili questi oggetti, dovresti assicurarti di aver aderito alla Persona corretta.

score 1 · Answer 2

Non so come sia modellato nella tua applicazione, ma nel mondo reale le persone non possono solo essere sia studenti che lavoratori, possono lavorare contemporaneamente a diverse aziende. Ora guardando più da vicino i tavoli mostra che assomigliano a N: N join tabelle, vero?

Quindi quello che vorrei fare è rinominare Studente in iscrizione e Lavoratore in contratto. La persona ora ha due relazioni N: N, una con Istituzione e una con la Compagnia. In termini di OOP:

class Person {
    Collection<Enrollment> enrollments;
    Collection<Contract> employmentContracts;
}