[Gfoss] Come impostare in un db una relazione 1:n tra più tabelle padre e una tabella figlio?

Salve a tutti,
domandona e mi rivolgo in particolare a Furieri e Sucameli.

Vorrei dare al mio DB postgres / spatialite una veste un po' più
pulita. Per ora le relazioni 1:N le ho gestite beceramente via python
con del mio codice.
Ora vorrei uno schema serio da passare ad sqlalchemy. Ma quello che
per ora non capisco è:

Se ho 2 tabella padre che devono linkarsi a una tabella figlio in
relazione 1:n è corretto quanto segue (in pseudo linguaggio)?

tab 1
field 1 (id primary key)
field 2 opt

....

tab 2
field 1 (id primary key)
field 2 opt

....

tab 3
field 1 (id)
field 2 opt
id di tab 1 (foreign key tab1.field 1)
id di tab 2 (foreign key tab2.field 1)
....

In sostanza nella tabella 3 figlio che viene usata sia da tab 1 che da
tab 2, è giusto aggiungere 1 campo di foreign key per ogni tabella chi
gli fa da padre?

Spero sia chiaro....ma non ci spero molto...

Attendo mooolte domande...

Ciao

Luca

On Wed, 26 Sep 2012 14:35:47 +0200, Luca Mandolesi wrote:

Se ho 2 tabella padre che devono linkarsi a una tabella figlio in
relazione 1:n è corretto quanto segue (in pseudo linguaggio)?

tab 1
field 1 (id primary key)
field 2 opt

....

tab 2
field 1 (id primary key)
field 2 opt

....

tab 3
field 1 (id)
field 2 opt
id di tab 1 (foreign key tab1.field 1)
id di tab 2 (foreign key tab2.field 1)
....

In sostanza nella tabella 3 figlio che viene usata sia da tab 1 che da
tab 2, è giusto aggiungere 1 campo di foreign key per ogni tabella chi
gli fa da padre?

Spero sia chiaro....ma non ci spero molto...

Luca, sei stato chiarissimo :smiley:

ed hai azzeccato il modo giusto di usare le relazione Primary/Foreign

giusto per fissare meglio le idee in modo piu' fornale, prendi il caso
della gerarchia Comune/Provincia/Regione; ovviamente un comune appartiena
sia ad una Provincia che ad una Regione
(lo potresti anche rappresentare a cascata, ma rimaniano sul "doppio padre"
per seguire il tuo esempio da vicino).

CREATE TABLE reg (
   id_reg INTEGER NOT NULL PRIMARY KEY,
   nome_reg TEXT NOT NULL);

CREATE TABLE prov (
   id_prov INTEGER NOT NULL PRIMARY KEY,
   nome_prov TEXT NOT NULL);

CREATE TABLE com (
   id_com INTEGER NOT NULL PRIMARY KEY,
   id_reg INTEGER NOT NULL,
   id_prov INTEHER NOT NULL,
   nome_com TEXT NOT NULL,
   CONSTRAINT fk_com_reg FOREIGN KEY (id_reg)
     REFERENCES reg (id_reg),
   CONSTRAINT fk_com_prov FOREIGN KEY (id_prov)
     REFERENCES prov (id_prov));

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

Uh..ottimo esempio che però mi fa notare una lacuna nel mio modello,
ovvero...io vorrei usare una tabella per rappresentare degli attributi
complessi di una entità, che però appartengono ad entità
diverse...esempio banalissimo: le misurazioni

struttura
  id_struttura (primary key)
  sigla struttura
  ....

reperto
   id_reperto (primary key)
   sigla_reperto
   ....

misurazioni
   id_misurazioni
   tipo_misura
   unita_misura
   valore
   id_struttura (foreign key struttura.id_struttura)
   id_reperto (foreign key reperto.id_reperto)

Nel caso del comune, lui avrà sempre una provincia e una regione
collegati...ma nel mio caso le misurazioni riceveranno i dati o da uno
o dall'altro...questo non potrebbe creare confusione avendo un campo
vuoto non per carenza di info ma perchè sto schedando a partire da una
entità differente?

On Wed, 26 Sep 2012 15:13:00 +0200, Luca Mandolesi wrote:

Uh..ottimo esempio che però mi fa notare una lacuna nel mio modello,
ovvero...io vorrei usare una tabella per rappresentare degli attributi
complessi di una entità, che però appartengono ad entità
diverse...esempio banalissimo: le misurazioni

Nel caso del comune, lui avrà sempre una provincia e una regione
collegati...ma nel mio caso le misurazioni riceveranno i dati o da uno
o dall'altro...questo non potrebbe creare confusione avendo un campo
vuoto non per carenza di info ma perchè sto schedando a partire da una
entità differente?

scusa Luca,

se hai due situazioni cosi' nettamente differenziate perche' non definisci
due tavole separate ?
una "misure_struttura", l'altra "misure_reperti"; se ti serve (ammesso che
ti serva) le attacchi assieme tramite una UNION, tanto hanno entrambe sempre
il solito layout

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

La soluzione "pulita" a livello database è esattamente questa.
Salutos.

Il 26/09/2012 14:35, Luca Mandolesi ha scritto:

Salve a tutti,
domandona e mi rivolgo in particolare a Furieri e Sucameli.

Vorrei dare al mio DB postgres / spatialite una veste un po' più
pulita. Per ora le relazioni 1:N le ho gestite beceramente via python
con del mio codice.
Ora vorrei uno schema serio da passare ad sqlalchemy. Ma quello che
per ora non capisco è:

Se ho 2 tabella padre che devono linkarsi a una tabella figlio in
relazione 1:n è corretto quanto segue (in pseudo linguaggio)?

tab 1
  field 1 (id primary key)
  field 2 opt

  ....

tab 2
  field 1 (id primary key)
  field 2 opt

  ....

tab 3
  field 1 (id)
  field 2 opt
  id di tab 1 (foreign key tab1.field 1)
  id di tab 2 (foreign key tab2.field 1)
  ....

In sostanza nella tabella 3 figlio che viene usata sia da tab 1 che da
tab 2, è giusto aggiungere 1 campo di foreign key per ogni tabella chi
gli fa da padre?

Spero sia chiaro....ma non ci spero molto...

Attendo mooolte domande...

Ciao

Luca
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

Il mio modo (errrato) di ragionare deriva dall'uso di failmaker, dove
avevo almeno 50 entità diverse e tutte usavano i campi delle
misurazioni...quindi al posto di avere 50 tabelle misurazioni, in
failmaker bastava legare ad un id generico della misurazione le
singole entità e in caso di modifica nel modo di misurare, le
modifiche di 1 tabella andavano a vantaggio di tutte le 50 entità.
Ovviamente in failmaker avevo 50 relazioni...quindi deve essere un
processo che lavora di dietro e non mi fa vedere 50 tabelle
personalizzate...ma me le fa sembrare delle semplici relazioni...

2012/9/26 Marco Li Volsi <marco.livolsi@gmail.com>:

La soluzione "pulita" a livello database è esattamente questa.
Salutos.

Il 26/09/2012 14:35, Luca Mandolesi ha scritto:

Salve a tutti,
domandona e mi rivolgo in particolare a Furieri e Sucameli.

Vorrei dare al mio DB postgres / spatialite una veste un po' più
pulita. Per ora le relazioni 1:N le ho gestite beceramente via python
con del mio codice.
Ora vorrei uno schema serio da passare ad sqlalchemy. Ma quello che
per ora non capisco è:

Se ho 2 tabella padre che devono linkarsi a una tabella figlio in
relazione 1:n è corretto quanto segue (in pseudo linguaggio)?

tab 1
  field 1 (id primary key)
  field 2 opt

  ....

tab 2
  field 1 (id primary key)
  field 2 opt

  ....

tab 3
  field 1 (id)
  field 2 opt
  id di tab 1 (foreign key tab1.field 1)
  id di tab 2 (foreign key tab2.field 1)
  ....

In sostanza nella tabella 3 figlio che viene usata sia da tab 1 che da
tab 2, è giusto aggiungere 1 campo di foreign key per ogni tabella chi
gli fa da padre?

Spero sia chiaro....ma non ci spero molto...

Attendo mooolte domande...

Ciao

Luca
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012