Gli errori fatali nella progettazione del modello dati

La progettazione del modello dati è uno di quegli aspetti dei progetti IT che viene sistematicamente sottovalutato. Molti lo considerano un passaggio tecnico di routine, qualcosa che si può improvvisare durante una riunione. In realtà, rappresenta le fondamenta su cui poggia l’intera applicazione. Un modello dati mal progettato può compromettere irrimediabilmente un progetto.

Con preoccupante frequenza, tutti si improvvisano architetti di database. La convinzione diffusa è che “basta mettere qualche colonna nel database”. Come se progettare una base dati fosse equivalente a mettere qualche mattone per costruire il Colosseo.

L’ambiguità letale dei nomi

Uno degli errori più comuni riguarda l’ambiguità nei nomi dei campi. Qualcuno propone: “Ci serve un campo Codice”. Codice di cosa? Del prodotto? Del cliente? Della transazione?

Senza contesto, un nome generico è inutile. Il campo “Data” è un altro classico: data di cosa? Di nascita? Di scadenza? Di ultima modifica?

L’ambiguità crea confusione per gli sviluppatori, genera errori nell’implementazione e rende la manutenzione un incubo. La soluzione richiede disciplina: nomi descrittivi che includano il contesto. Codice_Prodotto, Data_Nascita, Data_Scadenza_Contratto.

La proliferazione dei dati duplicati

Un altro errore classico è la moltiplicazione di campi che rappresentano lo stesso tipo di informazione. Email_utente, email_contatto, email_preferita, email_emergenza. Invece di modellare correttamente una relazione uno-a-molti, si creano decine di campi ridondanti.

Questa approccio genera problemi immediati. Quale email si usa per quale scopo? Cosa succede quando servono più di tre indirizzi? Si aggiunge email_emergenza_2?

La duplicazione viola un principio fondamentale: la normalizzazione. Ogni fatto dovrebbe essere memorizzato una sola volta.

I vincoli di coerenza ignorati

I vincoli di coerenza sono spesso sacrificati per la fretta. Esempio classico: salvare l’età invece della data di nascita. Sembra più semplice, ma il sistema pensa che tutti abbiano la stessa età per sempre.

La data di nascita è un fatto immutabile. L’età è un valore derivato che cambia. Salvare valori derivati invece di fatti base crea debito tecnico. Ogni volta che si salva un dato derivato, si crea un punto potenziale di incoerenza.

L’incapacità di prevedere l’evoluzione

Molti modelli vengono progettati per il caso più semplice, senza considerare evoluzioni prevedibili. “Un cliente ha un solo indirizzo” funziona finché non serve spedire in luoghi diversi.

Il campo tipo_cliente con solo privato/azienda va in crisi quando arriva un’associazione no-profit o un ente pubblico. Progettare significa anticipare. Certi scenari sono sufficientemente probabili da meritare considerazione. Un modello rigido diventa rapidamente obsoleto e richiede costose migrazioni.

Gli errori sui tipi di dato

La scelta dei tipi di dato appropriati è fondamentale ma spesso trascurata. Salvare numeri di telefono come interi elimina gli zeri iniziali. In Italia molti numeri fissi iniziano con 0, un tipo intero li renderebbe inutilizzabili.

Le date salvate come stringhe perdono confronti temporali significativi e ordinamenti corretti. I codici salvati come numeri creano problemi con gli zeri iniziali. Ogni tipo di dato esiste per uno scopo specifico. Usare il tipo sbagliato è tecnicamente scorretto e crea problemi pratici.

La sicurezza come ripensamento

La sicurezza viene spesso considerata un aspetto da affrontare “dopo”. Password salvate in chiaro perché “chi le guarda?”, dati sensibili non crittografati perché “è interno”, informazioni accessibili a chiunque perché “implementeremo i permessi dopo”.

Salvare password in chiaro è negligenza professionale. La crittografia dei dati sensibili, l’hashing delle password, la gestione corretta dei permessi non sono optional. Sono requisiti che devono essere integrati nella progettazione iniziale.

La complessità multidimensionale

Progettare un modello dati è come giocare a scacchi multidimensionali. Bisogna pensare a come stanno le cose ora e a come potrebbero essere in futuro, con volumi maggiori, con requisiti diversi.

Serve bilanciare normalizzazione e performance. La teoria insegna a normalizzare per eliminare ridondanze. La pratica richiede denormalizzazioni strategiche per ottimizzare le query frequenti. Serve prevedere gli indici necessari. Un database senza indici appropriati è inutilizzabile, ma troppi indici rallentano le scritture.

L’importanza della documentazione

Un aspetto trascurato è la documentazione del modello dati. Non basta creare tabelle e campi. Serve documentare le decisioni di progettazione, i vincoli impliciti, le assunzioni fatte.

Quando tra anni qualcuno dovrà modificare il database, avrà bisogno di capire la logica dietro le scelte. Senza documentazione, ogni modifica diventa rischiosa. Si rischia di violare vincoli impliciti, di rompere assunzioni nascoste.

Le conseguenze di lungo termine

Gli errori nella progettazione del modello dati hanno conseguenze che si manifestano nel lungo periodo. Inizialmente tutto sembra funzionare. I problemi emergono quando il sistema cresce, quando i requisiti evolvono.

A quel punto correggere diventa estremamente costoso. Le migrazioni di database in produzione sono operazioni delicate. Prevenire è infinitamente più economico che correggere. Ma questo richiede riconoscere che la progettazione del database non si può improvvisare.

Verso una progettazione consapevole

La progettazione del modello dati richiede competenze specifiche, esperienza, disciplina. Richiede conoscenza dei principi di normalizzazione, comprensione dei trade-off, capacità di anticipare evoluzioni.

Richiede anche umiltà: riconoscere quando non si hanno le competenze e coinvolgere esperti. Un architetto di database competente può evitare errori che costerebbero ordini di grandezza in più del suo compenso.

E mentre qualcuno discute ancora se uno stato debba essere booleano o stringa con “Sì/No/Forse”, da qualche parte un database piange silenziosamente, sognando progettazione seria, vincoli ben definiti e tipi di dato corretti.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT