1 messaggio dal 17 agosto 2009
ho una tabella che cotiene dei dati relativi a persone

TABLE persona
IDpersona
cognome
nome
...

vorrei gestire le relazioni anagrafiche tra persone (fratello, padre, madre, ecc...). qual'è secondo voi il milgior modo?

avrei pensato ad una tabella del tipo

TABLE relazione
IDpersona1
IDpersona2
tiporelazione

però ho il dubbio che possa crearmi problemi di "circolarità" nelle ricerche (per esempio quando sono presenti 3 fratelli) e di non "bidirezionalità" di certe relazioni (se si parla di fratelli nessun problema, in quanto è un rapporto paritario, ma per esempio il rapporto padre-figlio a implicazioni diverse: un figlio può avere un solo padre e inoltre se voglio sapere chi "è il padre di", l'ordine in cui registro gli identificativi "persona" nella tabella "relazione" ha importanza)

quindi vi chiedo: qual'è il miglior modo per gestire queste cose? cosa dicono a riguardo i testi sull'argomento SQL?
Modificato da pucci il 13 marzo 2010 10.12 -
salve pucci,
la domanda e' molto interessante, ed e' un paio di giorni che cerco di ragionarci un po' sopra in quanto non avevo mai affrontato il problema.. e mi spaventa :)
mi spaventa perche' non credo tu stia parlando di un grafo aciclico normale, o anche con multipaternita' di subnodo (2 sono solitamente i genitori di una "persona", quindi 2 nodi superiori portano ad uno o piu' nodi inferiori [nel caso semplice che il padre sia sempre lo stesso]), ma che in definitiva non si parli sempre di foreste ma anche di isole di nodi completamente interconnessi..
mi spiego, se e' sempre conosciuta "la madre" (o il padre), il problema sarebbe semplicemente l'esplosione di un grafo aciclico "normale", (non so come si riuscira' a visualizzare questa rappresentazione grafica)
*
/ \
* *
come si vede e' semplice, e lo sarebbe anche nel caso di entrambi i genitori conosciuti, in quanto, almeno nei legami parentali di primo livello c'e' sempre una connessione diretta.. in questo semplice caso di unico nodo padre, anche i nested sets di Joe Celko sarebbero una ottima soluzione, anche se personalmente preferisco non utilizzare questa impostazione per gli eventuali alti costi di aggiornamento, ma nel caso proprio in esame si suppone che grandi variazioni parentali non debbano succedere, se non per l'eventuale aggiunta di fratelli, ma sui figli abbiamo poche probabilita' che l'insieme resti statico, quindi tenderei ad escluderlo.. tanto piu' che, solitamente, i genitori sono 2.. e qui puo' venirci incontro una soluzione basata sui matherialized paths, tecnicamente anche relativamente efficiente per le eventuali ricerche..
non esistono "problematiche" di referenziamento dei parenti di secondo livello, i fratelli, in quanto esiste un vincolo comune con almeno uno dei 2 genitori.. sui fratellastri gia' cominciano alcune problematiche tendenzialmente risolvibili in OR nelle eventuali operazioni di esplosione di join (ma questo e' un aspetto tennico).. quindi
  
  *  *  
  |\/|  
 // \|  
*    * 

[si lo so, si capisce poco :) ]
ma il mio pensiero va invece allo scenario di "assenza" di parenti di primo livello diretti (i genitori non sono "conosciuti"), e quindi invece di un grafo troviamo un'isola che deve risultare completamente interpolata..
 
3 fratelli =  
  *  
 / \  
* - *  
4 fratelli=  
   *  
  /|\  
 * + *  
  \|/  
   *  

questo in un semplice caso di parentela di secondo livello dove i genitori siano sconosciuti alla nostra tabella
qui la gestione diventa complicata, in quanto per ogni fratello gestito si rende necessaria la connessione con tutti i fratelli esistenti..
la dimenticanza/omissione di una relazione crea un errore logico (ed anche implementativo) imbarazzante, e purtroppo non c'e' vincolo semantico che possa aiutare nella definizione aprioristica dell'entita'... tutto deve essere demandato al codice attuativo di inserimento, che deve recuperare almeno uno dei fratelli per poter poi ciclare su tutti i risultanti al fine di popolare completamente l'interrelazione..
la ciclicita' da te prefigurata solo mi fa pensare a questa problematica di isole di dati, in quanto in un grafo aciclico anche multiorigine, per conoscere i nodi fratelli basta interrogare uno dei nodi genitori per riportare tutti i nodi subordinati di primo livello..
diverso invece il caso, appunto delle isole.. dove deve essere percorsa l'intera struttura esplosa di interrelazione..
ma e' la semantica che ci deve essere dietro che piu' mi spaventa, in quanto non vedo, in questo caso, una semplice soluzione implementativa..
infatti mi viene da pensare che, almeno solitamente, non ci si possa aspettare un albero genealogico corretto e completo prima di registrare il nuovo "cliente"... potremo successivamente venire a conoscenza che clienteA e clienteB siano fratelli, ma non necessariamente saremo sempre a conoscenza delle loro origini..
se invece queste mie preoccupazioni sono fugate all'origine, se cioe' non possono esistere isole ma sempre trattiamo di foreste (quindi di alberi bi-originanti) allora un'implementazione come grafo aciclico penso possa essere indicata..
la gestione degli affini, pero', ripropone lo scenario di isole.. a meno che mia "cognata" venga legata a mia "moglie" tramite i loro parenti di primo livello (i relativi genitori)..
  
  *  *            *  *  
  |\/|            |\/|  
 // \|           // \|  
*    *          *    *  
     moglie -  io  
cognata             mio fratello  


e questo fermandosi al secondo livello di parentela (io-padre/madre-fratello)..
anche se un grafo aciclico puo' ovviamente essere esploso su tantissimi livelli..

non sono ancora riuscito a trovare niente in rete che affronti l'argomento, ma se e quando lo trovero', mi riprometto di ritornare su questo thread..
spiacente, queste sono solo mie elucubrazioni, niente di veramente importante che tu non abbia gia' realizzato :)
saluti
Modificato da Andrea Montanari il 17 marzo 2010 00.19 - sto provando a verificare se si riesce a migliorare la visulizzazione dei grafi e delle isole
Modificato da Andrea Montanari il 17 marzo 2010 00.20 - a quanto pare, senza successo :(

Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz - http://italy.mvps.org
http://www.hotelsole.com - http://www.hotelsolericcione.de

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.
In primo piano

I più letti di oggi

Media
In evidenza
MISC