Dopo aver letto e risposto al post (Evoluzione del Database e Deployment - http://tech.groups.yahoo.com/group/ugialtnet/message/513) mi sono riletto in questi giorni il libro di Ambler (Database Refactorings) che mi ero già letto qualche tempo fa per rinfrescarmi un pò la memoria e per cercare di fare un pò di chiarezza sulla situazione, visto che il tema sembra essere tornato caldo.
Partiamo da un punto fermo: anche il Database deve essere aperto ai cambiamenti e, come tale, deve poter essere sottoposto a refactoring.
Detto ciò - se qualcuno di voi ha letto Database Refactorings, l'unico testo in merito esistente al momento - avrà sicuramente notato una cosa: praticamente tutti i refactoring strutturali e sicuramente TUTTI gli "smells" indicati a pag.24 sono semplicemente correzioni dovute ad una mancanza di normalizzazione del database e che mirano proprio a normalizzare il database stesso!
Ma questo significa una cosa: quando abbiamo disegnato il database non abbiamo normalizzato nulla, ed ora ci troviamo con un database sbagliato. Non sto dicendo che il modello di dati che il database rappresenta è sbagliato, sto dicendo che il modello del database è fatto male e non rappresenta edelmente il modello dati a supporto delle regole di business!
Il refactoring è qualcosa che ci dovrebbe aiutare a fare emergere il design corretto che nella programmazione OO non è facile (anzi, direi impossibile) ottenere subito, anche facendo una pesante analisi upfront.
Con il DB questo però non è vero in quanto anche partendo da poche informazioni è cmq possibile, applicando in modo iterativo la normalizzazione, fino ad arrivare alla 5a forma normale (e poi si puo denormalizzare se le performance lo richiedono) far emegere subito un modello di database corretto, senza dover aspettare di scoprire l'errore quando questo "puzza".
Ovviamente con la normalizzazione NON è (sempre) possibile venire a conoscenza di logiche di business non documente dal cliente o dall'analisi (pur minima) fatta prima di iniziare il progetto, ed è in questo preciso momento che entra in gioco il refactoring del database.
Ad esempio mi trovo a dover gestire un'entità in più, che non avevo mai previsto prima. Ma questo non è una modifica architetturale INTERNA (che è quello a cui in gran parte si rivolge il refactoring) ma ESTERNA, ossia devo memorizzare informazioni AGGIUNTIVE rispetto alla situazione precedente.
Sono quindi giunto alla conclusione che il refactoring applicato ai database ha senso solamente se si parte da un database normalizzato correttaemnte, altrimenti non lo possiamo chiamare refactoring, ma CORREZIONE DEGLI ERRORI, che è una cosa ben diversa IMHO.
A chi mi chiede quindi come approciare in modo evolutivo al design del database direi:
1) Progettiamo il DB bene (e quindi normalizzando) in modo che il modello del databse sia adatto a rappresentare il modello dati che le regole di business di cui siamo a conoscenza nel momento del disegno dello stesso sia tutte correttamente implementate (quindi no alle colonne il cui significato dipende da un'altra colonna o valori "smart" o parlanti)
2) prima o poi le regole di business iniziali cambieranno. QUI interviene il refactoring del DB (ed oggi come oggi ci sono pochi strumenti a supporto, in particolare per quanto riguarda il Change Management). Tutto il refactoring fatto per sopperire mancanze introdotte nel punto 1 non è refactoring ma una "patch" agli errori commessi.
Come vedete questo approcio è diverso dal refactoring usato per la programmazione OO ma è invitabile IMHO, in quanto nell'approcio OOD non ci sono "regole" come la normalizzazione (che ci permette di sapere a priori cosa fare per evitare di andare incontro a problemi ben noti e documentati) ma tutto viene basato sulla proprio esperienza e sugli "smells" del codice o sui Design Pattern, che cmq non sono regole in senso stretto.
Credo che la differenza tra DB (modello ER) e OOD/P sia quindi questa: in OOD/P il refactoring è necessario anche per correggere degli "errori" (li chiamo cosi, ma errori non sono, sto infatti pensando ai "code smells") dovuti al fatto che non esistono regole che ci possano aiutare ad evitarli, mentre invece nel mondo del DB questo regole ci sono e quindi possiamo usarle per evitare errori "di base", utilizzando il refactoring a supporto solamente dei cambiamenti introdotti dall'esterno (modifica o aggiornamento delle regoled i business).
Quindi un approcio ai database sempre evolutivo, ma con basi più "solide" (il che, a pensarci bene, è naturale, in quanto il modello ER ha le sue basi nella matematica e nella logica).
La discussione è aperta (e la potete seguire qui: http://tech.groups.yahoo.com/group/ugialtnet/message/590)