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

[mando]

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
_______________________________________________
[hidden email]
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

[a.furieri]

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 :-D

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.

_______________________________________________
[hidden email]
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

[mando]

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?
_______________________________________________
[hidden email]
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

[a.furieri]

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.

_______________________________________________
[hidden email]
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

[Marco Li Volsi]

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
> _______________________________________________
> [hidden email]
> 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

_______________________________________________
[hidden email]
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

[mando]

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 <[hidden email]>:

> 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
>> _______________________________________________
>> [hidden email]
>> 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
>
>
> _______________________________________________
> [hidden email]
> 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

_______________________________________________
[hidden email]
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