2. Diagramma Entità Relazione

Come anticipato, in questo articolo entriamo in maniera approfondita nella questione relativa allo schema entità relazione (ER) sul quale si baserà l'implementazione del nostro database in cui si memorizzeranno i dati. La creazione dello strato di persistenza in un'applicazione è un processo delicato, in quanto su di esso si baserà anche il codice per il recupero delle informazioni dalla base di dati e la rappresentazione del dato all'interno della memoria. Avere una corretta rappresentazione del dato sin dall'inizio, anche se si evolverà con il tempo, facilita le operazioni di implementazione della controparte all'interno del gestionale. Analizziamo lo schema che ho creato.

Figura 1: Schema ER

L'entità principale da cui è partita la fase di analisi è l'entità socio composta dai seguenti campi:

• tessera, rappresentato come intero all'interno del database e allo stesso tempo è la primary key della tabella, in quanto con questo valore si identifica univocamente il socio;
• data_iscrizione, di tipo date all'interno del database, nel formato "yyyy-mm-dd", indica la data in cui il socio ha presentato la sua domanda;
• data_approvazione, anch'esso di tipo date nel formato "yyyy-mm-dd", indica la data di approvazione da parte dell'assemblea associativa della richiesta di iscrizione del socio;
• cognome, di tipo varchar, rappresentante il cognome del socio;
• nome, di tipo varchar, rappresentante il nome del socio;
• nascita, di tipo date nel formato "yyyy-mm-dd", rappresentante la data di nascita del socio;
• luogo_nascita, di tipo varchar, rappresentante il luogo di nascita del socio;
• indirizzo, campo strutturato per memorizzare l'indirizzo di residenza del socio. I campi che lo costituiscono sono la città,il cap e la via;
• ruolo, di tipo int, questo campo rappresenta una foreign key che collega la tabella soci alla tabella ruoli attraverso la relazione stato;
• data_annullamento, di tipo date nel formato "yyyy-mm-dd", indicante la data a partire dalla quale l'iscrizione del socio non è più attiva;
• note, di tipo varchar, contenente alcune note che il direttivo può inserire in riferimento al socio;
• cellulare, di tipo varchar, rappresentante il numero di cellulare del socio per eventuali contatti;
• consenso, di tipo varchar per rappresentare il consenso al trattamento dei dati personali;
• minorenne, di tipo varchar, indicante se il socio ha raggiunto la maggiore età.

Alcune considerazioni personali sulla scelta implementativa di questa entità e sulle prossime. Ho scelto di utilizzare il tipo varchar per la maggior parte dei campi in quanto non verranno fatti molte trasformazioni su questi dati, eccetto per qualche operazione di inserimento e aggiornamento. Ho lasciato il tipo int per tutti quei campi che rappresentano un codice identificativo come primary key di quella entità/relazione oppure rappresentano una foreign key, indicante un collegamento con entità o relazioni esterne. Inoltre prima di schematizzare questa entià ho raccolto alcune business logic che hanno influenzato la sua realizzazione. I dati dei soci erano racchiusi in un folgio excel, quindi ho mantenuto la stessa tipologia di valori memorizzata, però consultandomi con gli altri membri, abbiamo deciso di aggiungere le colonne per il consenso e per indicare se un socio è minorenne, per facilitare la sua visualizzazione nel caso in cui si organizzano attività nelle quali è necessario sapere se un socio ha prestato o meno il consenso per l'utilizzo dei dati oppure se il socio e maggiorenne.

Passiamo a documentare l'entità ruolo e la relazione stato. La prima memorizza tutti i vari tipi di ruoli presenti all'interno dell'associazione, mentre la relazione rappresenta un collegamento tra l'entità socio e l'entità ruolo. Iniziamo dall'entità ruolo:

• id_ruolo: identificativo del ruolo, è rappresentato come un intero;
• titolo: nome del ruolo, memorizzato come un varchar;
• compito: campo descrittivo di tipo varchar, contenente tutte le informazioni relative al ruolo, inclusi i suoi compiti che deve svolgere all'interno dell'associazione.

Mentre la relazione stato presenta solo tre campi:

• id_stato: id della relazione, di tipo int e primary key
• id_socio: id del socio, di tipo int e collegato all'entità socio in quanto foreign key
• id_ruolo: id del ruolo, di tipo int e colelgato all'entità ruolo in quanto foreign key

Business Logic: i ruoli all'interno dell'associazione sono descritti nello statuto. Attualmente sono: socio, volontario, presidente, vicepresidente e due cariche vuote. Gli ultimi 4 tipi di ruoli fanno parte del direttivo dell'associazione. Non è stata rappresentata questa relazione in quanto è possibile ottenerla attraverso delle query all'interno del database. In questo caso tra l'entità socio e l'entità ruolo è stata inserita una relazione molti a molti in quanto un socio può ricoprire più ruoli e un ruolo può essere ricoperto da più soci. Questo ragionamento non fa riferimento solo alle cariche del direttivo, in quanto per poterci accedere devono essere implicitamente dei soci, ma anche perchè il presidente e il vicepresidente possono incaricare altri soci di ruoli, la cui necessità nasce solo in determinati momenti e non è possibile prevederla in anticipo.

Descriviamo ora la sezione eventi, con i relativi costi e ricavi, e come questa si relazione con l'entità soci. Iniziamo descrivendo l'entità evento, la quale rappresenta la seconda parte più importante dell'associazione. L'entità è molto semplice, ma la logica di business che orchestra questa sezione è molto articolata, e se non gestita correttamente potrebbe portare a complicazioni a livello implementativo. L'entità evento quindi possiede solo tre attributi:

• id_evento: primary key di tipo int, rappresentate il codice univoco dell'evento
• nome: nome dell'evento o del format di eventi che l'associazione organizza, viene rappresentato come varchar
• descrizione: descrizione dell'evento, memorizzato come varchar

Ho voluto escludere da questa entità il campo data, in quanto ho ritenuto più opportuno memorizzarlo nell'entità evento_creato, che racchiuderà tutti gli eventi creati. E' stata impostata una relazione molti a molti, in quanto in un giorno possono essere effettuati più eventi e un evento può svolgersi in più giorni. Ero combattuto se convertire l'entità evento_creato in una relazione, ma non vi erano altre entità coinvolte. Mentre non avevo dubbi per la relazione partecipazione, che collega l'entità socio con l'entità evento_creato, in quanto vi era una relazione molti a molti: un socio poteva partecipare alla creazione di più eventi e a un evento possono partecipare più eventi. Esplicitiamo i campi di questa relazione:

• id_partecipazione: primary key che identifica la partecipazione, è memorizzata come int;
• id_creato: foreign key, memorizzata come int e che si riferisce all'evento creato o che si sta creando;
• id_socio: foreign key memorizzata come int e che si riferisce al socio che ha partecipato alla creazione dell'evento;
• gruppo: campo di tipo varchar che rappresenta il gruppo di appartenenza del socio durante l'organizzazione dell'evento.

Per questa relazione, l'unica logica di business che mi ha spinto ad aggiungere il campo gruppo come attributo e non come entità, è stata dettata dal fatto dell'assenza di gruppi di lavoro definiti. Ciò non toglie che in un aggiornamento futuro, l'attributo gruppo venga trasformato in un'entità.

Vorrei concludere questo articolo analizzando le entità costo_evento e entità_evento, rimandando le altre al prossimo articolo. Introduciamo la logica di business alla base di queste due entità. Anche se l'associazione ONstage è un'associazione no profit, deve tenere traccia delle spese e dei costi relativi agli eventi e alla gestione generale dell'associazione, questo è il motivo principale della presenza di queste entità che hanno una natura di tipo "economico". I campi relativi all'entità costo_eventi:

• id_costo: primary key di tipo int che identifica univocamente la transazione del costo;
• id_evento_creato:foreign key di tipo inti che identifica l'evento a cui fa riferimento il costo;
• data: data riferita al momento in cui il costo è stato sostenuto, è memorizzata come tipo date nel formato "yyyy-mm-dd"
• descrizione: descrizione del costo, memorizzato come varchar
• costo: valorizzato come tipo float all'interno del database e rappresentante l'effettivo costo sostenuto
• id_fattura: foreign key relativa alla relativa fattura del costo, è memorizzato come int;
• id_scontrino: foreign key relativa al relativo scontrino, è memorizzato come int.

Gli attributi id_fattura e id_scontrino possono essere anche valorizzati con 'Null', in quanto la valorizzazione di uno esclude la valorizzazione dell'altro. Seguendo questa logica, analizziamo anche l'entità entrate_evento, formata dai seguenti attributi:

• id_entrata: primary key di tipo int che identifica univocamente la transazione dell'entrata;
• id_evento_creato:foreign key di tipo inti che identifica l'evento a cui fa riferimento l'entrata;
• data: data riferita al momento in cui l'entrata è stata riscossa, è memorizzata come tipo date nel formato "yyyy-mm-dd"
• descrizione: descrizione dell'entrata, memorizzato come varchar
• entrata: valorizzato come tipo float all'interno del database e rappresentante l'effettiva entrata riscossa
• id_fattura: foreign key relativa alla relativa fattura emessa, è memorizzato come int;
• id_scontrino: foreign key relativa al relativo scontrino emesso, è memorizzato come int.

Per non annoiarvi, la descrizione delle altre entità e relazioni che sono rimaste verrà effettuata nel prossimo articolo. Rimanete aggiornati per i futuri progressi e le future novità.