Rubrica di paese

di il
8 risposte

Rubrica di paese


Voglio creare un database Rubrica. Per molto tempo lo avevo ritenuto inutile in quanto la Rubrica di Outlook Express mi sembrava efficente. Facebook è troppo caotico. Da quando ho lasciato la città per trasferirmi in paese ho scoperto che se non conosci tutti e i fatti di tutti sei un outsider. Tra me e mia moglie incrociamo ogni giorno diverse persone e ci risulta sempre più difficile ricordare Tizio o Caio solo dal nome, volto o appunto trascritto velocemente su un foglio volante. Spesso raccontare la storia che vi è dietro torna molto più efficace e sociale. La Rubrica che vorrei realizzare deve contenere public relations con tanto di datazione evento per evento che sviluppa questa o quella conoscenza di persone. Perciò diventa importantissimo conoscere Famiglie, Gruppi, Associazioni, Enti, Parrocchie...
Lo schema delle Relazioni del link segnalato rappresenta ciò che ho realizzato finora. Ho più volte aumentato o accorpato tabelle a destra e a manca, ora sono fermo a questa struttura che provo a spiegare nei punti più critici.
1) È importante avere una tabella Gruppi (che significa tanto Ente, quanto Azienda, Famiglia, Associazione...), qualcosa che giustifichi il fatto che in data X molte Persone si sono ritrovate in un Gruppo per un certo motivo (Descrizione). Siccome anche una Persona può appartenere a molti Gruppi e, per di più, neanche in maniera stabile, ecco che torna utile associare IDGruppo-IDPersona con una Data e avere uno storico delle vicende sociali.
2) La struttura fra le tabelle Gruppi, Persone e Partecipazioni mi sembra corretta. Il fatto di avere quelle due tabelle periferiche ContattiGruppi e ContattiPersone mi inquieta un po', ma non riesco a risolvere altrimenti.
ContattiGruppi esiste perchè in una famiglia (gruppo in genere), ai molti componenti del nucleo tornano in comune Indirizzo, Città, Telefono (fisso)(campo Tipo). Mentre e-mail o cellulare risultano contatti strettamente personali (ContattiPersone).
3) Sia chiaro che chi è single e ha residenza da solo e non appartiene a nessun Gruppo, si sottintende appartenere al Gruppo "Sè stesso" oppure convenzionalmente Nessuno che li accomunerebbe tutti.
4) Il campo Persone.DataNascita messo lì serve soltanto per discriminare eventuali omonimi sui campi Nome e Cognome.
5) Di tutto questo discorso, opportune query dovranno poi dare molte risposte in base a vari filtri ecc...

Vorrei sapere se:
A) Questa struttura è coerente comunque oppure no.
B) Se occorrono fare altre analisi.

8 Risposte

  • Re: Rubrica di paese

    Mi sono preso un pò di tempo per capire... il progetto è, come hai compreso, da strutturare in modo serio fin da subito...!

    Le relazioni che io proverei a definire sono di questo tipo:

    TblAnagrafiche(quì ci puoi inserire le persone fisiche con i dati anagrafici stile Rubrica, recapiti ecc).
    TblGruppi(ogni IdAnagrafica può far parte di più gruppi questa Tabella avrà i dettagli specifici del GRUPPO, quindi Referente, Scopo del gruppo ecc...)
    Ne consegue che già quì serve una relazione MOLTI-MOLTI quindi una tblDettaglio(Anagrafica-Gruppi).
    Ogni Gruppo può avere PIU' incontri... quindi servirà una TblIncontri lato Molti.
    Ora se tuttavia devi registrare ad ogni incontro chi ha partecipato e non ti basta definire il GRUPPO... purtroppo servirà una nuova Tabella che per Ogni INCONTRO preveda(i partecipanti).
    Non confondere in questo caso GRUPPI---INCONTRI---PARTECIPANTI. sono relazioni indipendenti che si devono solo trascinare le PK e FK al fine di semplificarti le Queries.

    Suggerisco di usare il C.F. per distinghuere in modo specifico le persone... non inventarti cose meno sicure...!

    Vedi se ho inteso correttamente... poi nel caso si proseguiamo con i dettagli.
  • Re: Rubrica di paese

    Grazie per la risposta e il tentativo di interpretare al meglio il mio obiettivo. Confesso di non avere proprio le idee chiarissime e il fatto di concentrarmi su certi aspetti mi fa perdere di vista altri (non meno importanti).
    Nel frattempo ho elaborato un altro scenario tabelle.

    ANAGRAFICA
    IDPersona
    Nome
    Cognome
    DataNascita

    CONTATTI
    IDContatto
    Data
    IDPersona
    IDGruppo
    Ruolo(della IDPersona nel Gruppo)
    TipoContatto (Residenza 1, Residenza 2, Cellulare 1, Cellulare 2, e-mail 1, e-mail 2...)
    Indirizzo (Via, Piazza...)
    IDCittà (vorrei sfruttare il tuo database dei comuni, mi sa che mi torna molto utile)
    Coordinate GPS
    Interno (nel caso di Residenza o luogo di lavoro, l'Interno)
    Telefono
    Valore (si intende esattamente 33876622 (cellulare), o (e-mail)...qui ho le idee confuse. Pensi che il campo Telefono sia strettamente legato a CoordinateGPS=Città/Indirizzo/Interno oppure un numero di telefono può stare tranquillamente in questo campo?)
    Attivo (campo sì/no se si considera che, con il passare del tempo, alcuni contatti non serviranno più, può essere utile tenerne sempre traccia ai fini storici, ma deselezionato, favorirebbe un più facile filtro/query dei contatti attivi di Tizio)
    Note

    GRUPPO
    IDGruppo
    NomeGruppo
    Categoria

    Nel tentare di simulare un input, io stesso faccio confusione con il significato campi IDGruppo e TipoContatto.
    Lo stesso dicasi per il campo Categoria (Amici, Lavoro, Parenti...) che ho preso spunto da altri database. Potrebbero esistere tanto CategorieGruppi quanto CategoriePersone...ma, come un cane che si morde la coda, penso che Gruppo (reale (con tanto di luogo fisico) o virtuale (amici del forum xxx) che sia, automaticamente potrebbe includere/significare Categoria...???
    Mi crea caos mentale il fatto che IDCittà insieme a quei campi che servirebbero a identificare univocamente un luogo fisico si possa normalizzare con un semplice IDLuogo. Però aggiungere altri campi alla tabella Comuni non avrebbe senso. Intanto è pur vero che in certi casi, non sempre puoi sapere proprio la città e magari ti accontenti anche della sola Regione o Provincia (ho incontrato una bella ragazza Veneta in treno e ho con me soltanto cellulare e e-mail). Mia intenzione è quella di modificare la tabella Comuni, aggiungendo record e lasciando tranquillamente vuoti i campi Città, CAP, Provincia...quindi nel caso specifico IDLuogo (o IDCittà)di residenza della ragazza sarebbe semplicemente Regione: Veneto.
    Da questo scenario però ho perso il filo del discorso sugli Incontri.
    Una delle cose che più mi premeva segnalare nella Rubrica, era quella di contabilizzare soltanto eventuali cambiamenti di connotati-contatti delle persone che IO incontro ogni volta. Diciamo pure che, se un Incontro non produce nuovi contatti (o cambiamenti di contatti), non mi serve poi tanto tenerne traccia, altrimenti sarei costretto a scrivere qualsiasi cosa mi succede nell'arco della giornata minuto dopo minuto (sai che stress!). Pertanto questo farebbe saltare via tutto il discorso delle public relations. Aiuto!

    @Alex ha scritto:


    TblGruppi(ogni IdAnagrafica può far parte di più gruppi questa Tabella avrà i dettagli specifici del GRUPPO, quindi Referente, Scopo del gruppo ecc...)
    Ne consegue che già quì serve una relazione MOLTI-MOLTI quindi una tblDettaglio(Anagrafica-Gruppi).
    Ogni Gruppo può avere PIU' incontri... quindi servirà una TblIncontri lato Molti.
    Ora se tuttavia devi registrare ad ogni incontro chi ha partecipato e non ti basta definire il GRUPPO... purtroppo servirà una nuova Tabella che per Ogni INCONTRO preveda(i partecipanti).
    Non confondere in questo caso GRUPPI---INCONTRI---PARTECIPANTI.
    ma allora tu mi stai dicendo che da Anagrafica.IDPersona partirebbero almeno 3 linee di congiunzione verso Gruppi.IDReferente, Anagrafica-Gruppi.IDPersona, DettaglioIncontro.IDPersona? Ma si può fare normal-strutturalmente parlando?
  • Re: Rubrica di paese

    Facciamo un passo per volta... ho capito che potrebbe servire analizzare meglio le esigenze.

    Ti dico la mia, con tutti i difetti del non essere addentro al probelma.

    Per come hai proposto tu le cose ci sono alcuni dettagli che meritano riflessione.

    Nella Tabella CONTATTI identifichi una serie di Campi che mi pare non siano realmente
    da inserire in questa Tabella
    
    Ruolo(della IDPersona nel Gruppo)
    Il Ruolo è un campo che a mio avviso sia da mettere nella Tabella GRUPPI, al fine di identificare li il ruolo dei partecipanti al Gruppo.
    Andrà da se che se il REFERENTE è il CONTATTO la tabella contatti NON SERVE, se invece il contatto del Gruppo possono essere MOLTI la cosa cambia...

    Per quanto riguarda i dati specifici dei CONTATTI... quelli che riporto a titolo di esempio sotto... non capisco perchè non siano tipici dell'anagrafica...???
    Io tutti questi dati li metto nella tabella Anagrafiche, in questo modo se domani il REFERENTE cambia, ti porti dietri in AUTOMATICO i suoi dati specifici... che invece nel tuo caso dovresti MODIFICARE...!!!!
    
    TipoContatto (Residenza 1, Residenza 2, Cellulare 1, Cellulare 2, e-mail 1, e-mail 2...)
    Indirizzo (Via, Piazza...)
    IDCittà (vorrei sfruttare il tuo database dei comuni, mi sa che mi torna molto utile)
    Coordinate GPS
    Interno (nel caso di Residenza o luogo di lavoro, l'Interno)
    Telefono
    Poi c'è lo stato di [ATTIVO] che fatico ad individuare, ma, a pari del campo RUOLO, credo possa essere SPECIFICO dello stato della persona all'interno del Gruppo...!

    Stando così le cose la Tabella CONTATTI potrebbe non esistere se REFERENTE=CONTATTO, nel caso in cui ogni gruppo può avere più referenti allora la tabella CONTATTI sarebbe costituita da 3 campi...
    
    TblContatti
    IdContatto(PK Counter)
    IdGruppo (FK da TblGruppi)
    IdPersona (Fk da TblAnagrafiche ma da Inserire con Combo da TblGruppi in modo da selezionare solo gli appartenenti)
    Ovviamente avrai una TblRuoli legata alla TblGruppi nel campo RUOLO.

    A questo manca lo SCOPO del GRUPPO... che fa questo gruppo...

    Una cosa che mi sono dimenticato di chiederti... un GRUPPO può essere parte di un'altro GRUPPO...?

    Se la risposta è SI... ti si complica molto la VISIONE, in quanto serve rivedere la relazione tblAnagrafica con la tblGruppi che così come è strutturata prevede solo un rapporto di PARENTELA dato da 1-M, quindi 1 persona può far parte di Molti Gruppi... ma il gruppo non può far parte di un gruppo...!
    L'approccio di questo tipo prevede una struttura ad Albero RICORSIVA a Livelli INFINITI, molto complessa da CAPIRE strutturalmente ma gestibile SOLO VIA VBA.
    In sostanza la puoi vedere come la gestione delle ricette di cucina... ogni componente può essere parte di altri componenti(Finiti o Semilavorati).
    Un componente finito può essere una TORTA
    Un semilavorato la crema(usabile nella Torta o in altre ricette)...

    Stessa filosofia per Gruppi che possono comporre Gruppi...

    L'esempio che ho fatto, non è a caso...
  • Re: Rubrica di paese

    Mentre scrivevi tu, nel frattempo ho elaborato un altro scenario.
    Come vedi questo?

    ANAGRAFICA
    IDPersona
    Nome
    Cognome
    DataNascita

    CITTA'
    IDCittà
    Continente
    Nazione
    Regione
    Provincia
    Città
    CAP

    LUOGHI
    IDLuogo
    NomeLuogo
    CoordinateGPS
    IDCittà
    Indirizzo

    EVENTI
    IDEvento
    Data
    Descrizione
    IDLuogo

    CONTATTI
    IDContatto
    IDEvento
    IDPersona

    DETTAGLIO_CONTATTI
    IDDC
    Tipo
    IDLuogo
    Interno
    Valore
    IDContatto

    Relazioni:
    Città.IDCittà uno-a-molti con Luoghi.IDCittà
    Luoghi.IDLuogo uno-a-molti con Eventi.IDLuogo
    Eventi.IDEvento uno-a-molti con Contatti.IDEvento
    Anagrafica.IDPersona uno-a-molti con Contatti.IDPersona
    Contatti.IDContatto uno-a-molti con DettaglioContatti.IDContatto
    Luoghi.IDLuogo uno-a-molti con DettaglioContatti.IDLuogo

    Mi sono dato una ragione del fatto che un conto è parlare di Luogo di incontro-conoscenza (Evento), un altro di Luogo in quanto Residenza o Luogo di lavoro (DettaglioContatto).
    In DettaglioContatti scriverei in Tipo: Residenza, Telefono, Cellulare, e-mail...se si tratta di Residenza o Luogo di lavoro (luogo fisico), il campo IDLuogo avrà un senso, ma nel caso di Cellulare o e-mail, lascerò IDLuogo con un valore "0" fittizio di default.
    Città e Luoghi ho preferito dividerli in quanto Luoghi ha tutta l'aria di un "DettaglioCittà" e poi Città può sempre tornarmi utile per un eventuale campo LuogoNascitaAnagrafica (che di solito si indica solo con la Città).

    @Alex ha scritto:


    Nella Tabella CONTATTI identifichi una serie di Campi che mi pare non siano realmente
    da inserire in questa Tabella

    Codice: Seleziona tutto
    Ruolo(della IDPersona nel Gruppo
    Sì, in verità non so neanche io che significato dargli a quel campo e posto lì aveva molte ambiguità.

    @Alex ha scritto:


    Poi c'è lo stato di [ATTIVO] che fatico ad individuare, ma, a pari del campo RUOLO, credo possa essere SPECIFICO dello stato della persona all'interno del Gruppo...!
    "Attivo" non è riferito a una persona (spero non ci stiamo fraintendendo). Semplicemente Tizio aveva ieri come e-mail, oggi non la usa più e ha . Io anzichè modificare il dato esistente, preferisco aggiungere una nuova e-mail con nuova data (mantenendo lo storico). Poi alla vecchia e-mail avrei posto Attivo:No, alla nuova Attivo:Sì. Tu mi chiederai: a cosa ti serve? Per l'esempio e-mail magari non è tanto calzante, ma pensa ai cambi di residenza o luoghi di lavoro (hanno maggiore rilevanza sociale).

    @Alex ha scritto:


    A questo manca lo SCOPO del GRUPPO... che fa questo gruppo...
    La parola Gruppo temo sia ambigua. Tu l'hai intesa in senso stretto, io spesso più vicina al concetto di Categoria (se prendi ad esempio altri database Rubrica in giro)(Amici, Parenti, Colleghi...)...come vedi ho dato un senso molto vago: Scusa!

    @Alex ha scritto:


    Una cosa che mi sono dimenticato di chiederti... un GRUPPO può essere parte di un'altro GRUPPO...?
    Dal discorso ho lasciato facilmente intendere questo rischio. Proprio perchè temevo anche questo, preferirei renderlo un concetto il più semplificato possibile. Ho capito il discorso della torta: non voglio cadere in quella trappola. Quindi non Gruppi di Gruppi.

    Cercherò di analizzare con calma tutte le altre osservazioni.
    Ogni tanto ci divergiamo, ma non temere di dire concetti fuori luogo. Il tuo ragionare metodico è sempre molto affascinante.
    Confesso che il post era nato un po' per gioco, ma la discussione sta diventando davvero intrigante.
  • Re: Rubrica di paese

    La tabella CITTA mi sembra una tabella di EXCEL... ma li devi vedere tu effettivamente se ha un senso gestire una RELAZIONE o se conviene così...

    Per i dati anagrafici, io resto della mia idea... anche se sono dati Ufficio/Casa o altro sono anagrafici e non li vorrei disperdere, come ti ho fatto notare, così come lo hai impostato, se cambi PERSONA devi inserire dati ANAGRAFICI in 2 posti in 2 momenti...
    Pur avendo una sua LOGICA, che non condivido ma rimane pur sempre una logica, dal punto di vista OPERATIVO chi sviluppa deve vedere sempre l'azione di chi inserisce i dati...

    Nel tuo caso questi aspetti sono di difficle comprensione in quanto tu sei Sviluppatore ed UTENTE... e non noterai mai le difficoltà e la strana logica di inserimento in quanto tu stesso lo hai fatto...!

    Se il tuo programma lo usasse un mero INSERITORE, una segretaria per capirci..., forse ti potrebbe insultare

    Scherzi a parte, non addentrandomi nello specifico, mi fermo a considerazioni personali per come vedrei la gestione, chiaramente mi può sfuggire il disegno completo.
  • Re: Rubrica di paese

    @Alex ha scritto:


    Per i dati anagrafici, io resto della mia idea... anche se sono dati Ufficio/Casa o altro sono anagrafici e non li vorrei disperdere, come ti ho fatto notare, così come lo hai impostato, se cambi PERSONA devi inserire dati ANAGRAFICI in 2 posti in 2 momenti...
    Domande:
    1) Ma allora tu che campi metteresti in una normale/tipica tabella Anagrafica?
    oppure
    2) Come gestiresti una Persona che ha 3 residenze, 4 Luoghi di lavoro, 3 Telefoni fissi, 2 cellulari, 4 e-mail, 1 profilo Skype e 6 siti www?
  • Re: Rubrica di paese

    Con una tabella 1-Molti....?

    Non vedere la Tabella 1-M come un Vincolo... se ogni Anagrafica può avere Molti dettagli mi pare normale 1-M...!
    Il Campo Dettaglio diventerebbe il Nome della Proprietà da salvare...!

    Per farti capire:
    
    [b]TblAnagrafica[/b]
    IdAnagrafica(PK)
    Nome
    Cognome
    Residenza
    
    [b]TblDettagli[/b]
    IdDettaglio(Pk)
    IdAnagrafica(Fk)
    Dettaglio
    ValoreDettaglio
    Passo successivo è rendere selezionabile il TipoDettaglio in modo che siano rintracciabili o Filtrabili...
    
    [b]TblAnagrafica[/b]
    IdAnagrafica(PK)
    Nome
    Cognome
    Residenza
    
    [b]TblDettagli[/b]
    IdDettaglio(Pk)
    IdAnagrafica(Fk)
    IdTipoDettaglio(FK)
    PrioritàDettaglio
    ValoreDettaglio
    
    [b]TblTipoDettaglio[/b]
    IdTipoDettaglio(PK)
    TipoDettaglio
    
    Nella Tabella TipoDettaglio avrai:
    
    1 - Numero di Telefono
    2 - EMail
    3 - Sito Web
    A questo punto nella Tabella [TblDettagli] puoi avere 150 Numeri di Telefono, ed assegnare al gruppo Numeri di Telefono(IdTipoDettaglio=1) una priorità...
    e così per tutti i vari gruppi...

    Ovviamente ho banalizzato e semplificato molto, ma la strada è questa...
  • Re: Rubrica di paese

    Vorrei rivoluzionare il discorso prendendolo da altri punti di vista.
    Partirei dal fatto che, quando si conosce una persona, si acquisicono n informazioni, alcune dichiarate esplicitamente (Impiegato, Idraulico, Coniugato con, Telefono, e-mail...), altre elaborate dal proprio cervello ricevente (Alto, Bruno, Capelli lunghi, Progressista/Conservatore, Religioso...). Indipendentemente da questa pre-classificazione, mi preme sottolineare semplicemente che ognuna di queste parole può essere considerata "parola chiave" (o "Etichetta" per usare un termine più socialmente condiviso) per inquadrare una Persona. Tale parola chiave sarà indicata nel campo Indicazione.
    Osservare le seguenti 3 strutture che, sostanzialmente, dovrebbero raccontare gli stessi dati, ma impostati diversamente.
    Si noti come, a seconda della diversa interpretazione struttura, cambia il nome della tabella "fulcro", cioè
    DettagliPersone = Indicazioni = Incontri
    Consiglio di tralasciare l'attenzione dalle tabelle Città, Luoghi e TipiContatto e focalizzarla sulle restanti tabelle.


    RUBRICA SEMPLICE

    Ogni Indicazione viene scritta in base a qualsiasi notizia si acqusisce.
    I campi TipoContatto, PrioritàContatto, IDLuogoContatto, AttivoContatto verranno compilati soltanto se il valore nel campo Indicazione corrisponde alla parola chiave "Contatto", altrimenti restano vuoti.
    Pregi: semplice concettualmente, facile da compilare e gestire con future query.
    Difetti: non normalizzata, con troppi Data-IDLuogoIncontro ripetuti


    RUBRICA NORMALIZZATA

    Pregi: corretta strutturalmente
    Difetti: seccante dover compilare Eventi a monte per poi doverlo sempre richiamare in Indicazioni.IDEvento


    RUBRICA COMPROMESSO

    Ogni record conterrà Indicazione con parola chiave. Solo nel caso in cui la parole chiave fosse "Contatti" si giustifica l'utilizzo della tabella Contatti.

    Mi ritrovo ad essere indeciso su quale scegliere perchè ho considerato che per ogni Persona prevedo una media di 3-5 parole-chiave non Contatto e circa 2-3 Contatti.
    Per esempio incontro una Persona in data 10/10/2012 e colgo i seguenti particolari:
    Idraulico
    Musicista
    Cattolico
    Pacifista
    Contatto / 0804959436
    Contatto / 3393604225
    Contatto /

    In data 22/11/2012 conosco altri particolari:
    Coniugato con Paola
    Impiegato
    Contatto / Casa / IDLuogo digitato a monte nella relativa tabella / 08066666666
    Contatto /

    Tutti quei valori sono le parole chiave da inserire nel campo Indicazione. Se la parola chiave Indicazione si chiama "Contatto", allora occorre compilare tutti gli altri campi relativi al Contatto vero e proprio.

    @Alex ha scritto:


    La tabella CITTA mi sembra una tabella di EXCEL... ma li devi vedere tu effettivamente se ha un senso gestire una RELAZIONE o se conviene così...

    Per i dati anagrafici, io resto della mia idea... anche se sono dati Ufficio/Casa o altro sono anagrafici e non li vorrei disperdere, come ti ho fatto notare, così come lo hai impostato, se cambi PERSONA devi inserire dati ANAGRAFICI in 2 posti in 2 momenti...
    Pur avendo una sua LOGICA, che non condivido ma rimane pur sempre una logica, dal punto di vista OPERATIVO chi sviluppa deve vedere sempre l'azione di chi inserisce i dati...

    Nel tuo caso questi aspetti sono di difficle comprensione in quanto tu sei Sviluppatore ed UTENTE... e non noterai mai le difficoltà e la strana logica di inserimento in quanto tu stesso lo hai fatto...!

    Se il tuo programma lo usasse un mero INSERITORE, una segretaria per capirci..., forse ti potrebbe insultare

    Scherzi a parte, non addentrandomi nello specifico, mi fermo a considerazioni personali per come vedrei la gestione, chiaramente mi può sfuggire il disegno completo.
    Questa tua osservazione mi fa molto riflettere. Ma ritengo importante suddividere per Data ogni volta che si acquisiscono nuove Indicazioni siano esse parole-chiave fini a sè stesse o strettamente di Contatto.

    Non escludo la possibilità di creare una casella combinata sul campo Indicazione, visto che un valore come "Musicista" o "Impiegato" potrebbe ripetersi spesso.

    Premetto che non conosco tutte le regole di normalizzazione, i manuali e siti teorici al riguardo li trovo incomprensibili. Mi lascio semplicemente trasportare dall'istinto, esigenza del momento, esperienza di esempi passati.
    Quale struttura mi conviene scegliere?
Devi accedere o registrarti per scrivere nel forum
8 risposte