Analisi di un database
Pagina 1 di 3
Introduzione
In fase di progettazione di un software che si interfacci con un database, sia esso ad interfaccia Web o Desktop, sia esso dedito ad un particolare utilizzo piuttosto che ad un altro, è sempre necessario effettuare un'accurata analisi onde evitare di dover fare i conti con problematiche quali integrità referenziale, ridondanza dei dati, ecc.
Lo scopo di questo fondamentale lavoro di analisi è uno: raggiungere la migliore ottimizzazione dei dati e delle risorse anche in previsione di future modifiche od implementazioni alla banca dati.
Lo scopo di questo articolo è mettere il lettore in condizioni di affrontare in futuro i propri progetti partendo col piede giusto in fase di organizzazione delle informazioni da dover gestire, ovvero in condizione di realizzare, attorno ad un database ben strutturato, un software più snello e performante.
Chi è il cliente?
E' una domanda stupida o troppo ampia? Forse, ma si può iniziare a dare due marco-risposte:
- il cliente da soddisfare sono io;
- il cliente da soddisfare... è un cliente.
Se non ti sei posto queste domande... ponitele!
Mi sono appena rivolto al lettore in tono molto diretto, evitando giri di parole, giri che non posso e non voglio evitare adesso, rispondendo al secondo caso.
Caso 2. Il cliente da soddisfare non è lo sviluppatore, ma qualcuno che di informatica può avere un minimo di conoscenza o meno. Se ha delle conoscenze può semplificarci la vita perchè "parla la nostra stessa lingua", oppure è un saccente che la vita tende a complicarla al prossimo. Oppure è una persona che di informatica non capisce nulla ma sa cosa vuole (raro) o è in grado di farcelo capire. Oppure non sa nemmeno cosa vuole o non è in grado di dare le informazioni necessarie.
Prendere questa affermazione come una legge: non dare mai nulla per scontato, chiunque si abbia di fronte! E' meglio essere petulanti, considerare e riconsiderare tutto, onde evitare di arrivare a delle conclusioni che, per colpa proprio o di chi tentiamo di soddisfare sono errate per un motivo o per un altro.
Chiudo questa doverosa parentesi atta a far comprendere al lettore che, la cosa più importante, è avere le idee chiare, avere un calderone di informazioni non ancora organizzate, allo scopo di organizzarle al meglio, come vedremo di seguito.
Fare una buona analisi di un database
Come detto nella Guida SQL di questo sito, il linguaggio SQL piuttosto che i vari gestori di database (MS Access, MySQL, e cosi via) non sono difficili da utilizzare. Certo, ci sono prodotti più o meno complessi o intuitivi, ma non è questo il punto.
Il punto sta nel sapere cosa fare!
Do dunque per scontato che il lettore abbiamo un minimo di cognizione in termini di gestione di un database relazionale, conosca il linguaggio SQL e sappia usare un qualsiasi DBMS, essendo ininfluente la scelta del prodotto ai fini della comprensione di questo articolo.
Il da farsi può essere sintetizzato in sei punti:
- raccogliere le informazioni da gestire;
- dividerle in gruppi logici;
- pensare bene alla suddivisione in tabelle ed ai tipi di dato da utilizzare;
- pensare che "percentuale" di ridondanza si desidera far risultare;
- ipotizzare una struttura differente;
- spegnere il computer, fissare il soffitto, ripensare alla struttura
Esempio pratico: struttura del database di una directory di aziende
Va molto di moda sul Web negli ultimi anni il concetto di directory, sia essa una directory per l'indicizzazione, sia essa una directory per la ricerca di prodotti, servizi, aziende e cosi via.
Non potendo esaurire in questo contesto tutto lo scibile relativo alle banche dati da dover gestire (andando le casistiche oltre l'infinito) proviamo a creare una struttura di dati per gestire questo tipo di servizio.
Cosa deve fare questo servizio?
- raccogliere utenti;
- gestire locazioni geografiche;
- gestire categorie e sottocategorie;
- gestire i dettagli, associandoli a quanto nei punti 1, 2 e 3;
- prevedere opzioni quali sottoscrizioni a pagamento e cosi via.
Relativamente alla lunghezza dei campi, lascio alla discrezione del lettore il compito di stabilirla. In alcuni casi le lunghezze dei campi sono obbligate (ad esempio il codice fiscale ha 16 caratteri, il CAP ne ha 5 e cosi via), mentre per altre cose come un nome, una URL, posso consigliare da 50 a 150 caratteri.
Fate vobis!
