Fatta la prima parte – studio – adesso si passa alla definizione del database.
Prima domanda: che dati servono? Si crea quindi una lista di tutti i dati che dobbiamo registrare, per i vari oggetti-tabelle.
Perciò, se per esempio ho un’anagrafica contatti:

  • contatti
    1. nome
    2. cognome
    3. indirizzo
    4. fax
    5. telefono
    6. ecc.

Un punto importante da osservare è la granularità dei dati, cioè se devo scrivere – ad esempio – nome e cognome in due campi separati o in uno unico, o se l’indirizzo è compreso di CAP e città e provincia oppure tutto in campi separati.
Questo dipende da quale utilizzo può avere il database. Se devo inviare una mass-mail separando per CAP, oppure inviare delle lettere con scritto “Caro -utente-“, dovrò sicuramente suddividere i campi. In linea di massima, è sempre più sicuro suddividere i campi.

Durante l’elencazione dei campi, risulterà che alcuni hanno una possibilità limitata di scelta: ad esempio, alcuni dipendenti di un’azienda faranno parte dell’ufficio acquisti, altri dell’ufficio vendite e così via. In questo caso è più comodo estrarre il campo e creargli una sua tabella dedicata: ci sarà quindi la tabella “Reparto”, mentre nella tabella “Dipendenti” sarà presente solo un campo collegato.

Un altro punto da valutare è il riutilizzo dei dati: se il contatto diventerà in futuro un cliente, è preferibile riutilizzare i dati già inseriti. Quindi, invece di creare una tabella Contatti e una tabella Clienti, è possibile creare una tabella Partner con i soli dati comuni e delle tabelle collegate con i dati specifici (un contatto non avrà il codice fiscale, mentre un cliente sì), come proposto dal secondo dei testi indicati nel post precedente.
In alternativa, un semplice campo che permette di scegliere: “cliente”, “contatto”, “fornitore”, ecc., se riteniamo accettabile di mettere tutti i campi che servono nella stessa tabella.