Best practice per la riprogettazione di un database

Sono a conoscenza di alcune best practice generali durante la progettazione di un database per un'applicazione, ma per quanto riguarda la riprogettazione?

Faccio parte di un team incaricato di riprogettare un'applicazione aziendale interna, sebbene nonostante io dica "interno", purtroppo sono molte, molte persone lontane dal contatto con gli utenti reali del sistema.

Il programma attuale è in Oracle Forms, distribuito su un gruppo di tabelle non normalizzate, a volte con più tabelle quasi duplicate che contengono lievi varianti sui dati degli altri. I vincoli si presentano spesso sotto forma di procedure memorizzate scarsamente applicate. Anche i tipi non sembrano essere memorizzati correttamente. Ho riscontrato tutti i tipi di dati errati che Oracle sembra ignorare ma che si sono adattati (e giustamente) all'importazione / esportazione guidata di SQL Server. (Ad esempio, numeri interi a due cifre non costituiscono un datetime completo!)

Il programma originale risale probabilmente a vent'anni fa e tutti gli sviluppatori originali si sono ritirati così tanto tempo fa che anche le persone anziane qui non hanno idea di chi fossero. Di conseguenza, non ci sono davvero requisiti puliti da soddisfare: dobbiamo solo duplicare la funzionalità dell'applicazione esistente e conservare i suoi dati esistenti.

Il risultato finale della riscrittura sarà una versione basata sul Web in esecuzione su ASP.NET con MS SQL Server per il back-end.

I miei altri due compagni di squadra sono molto, molto più vecchi di me, entrambi con background di business / MIS mentre il mio è CS. L'esperienza del membro senior è stata quasi esclusivamente di moduli Oracle e l'altro membro ha svolto principalmente il lavoro di applicazioni aziendali in Visual Basic. Sebbene il mio background di database sia stato limitato alla progettazione di nuovi database per progetti in MySQL o SQLite, principalmente per le mie lezioni universitarie, mi sembra di essere l'unico con esperienza nella progettazione di database.

Ho già scritto un piccolo programma in C # che legge tutti i dati esistenti in un formato neutro, pronto per essere rilanciato e inserito in un nuovo database. Ho intenzione di scrivere il codice di caricamento dopo aver progettato il database di destinazione, in modo che i dati possano essere suddivisi correttamente tra le nuove tabelle normalizzate, aggiunti nell'ordine corretto per seguire i nuovi vincoli, ecc. Lo stesso programma potrebbe quindi essere eseguito nuovamente in un secondo momento per copiare i dati di produzione nella riprogettazione ultimata appena implementata. Questo lascia la riprogettazione effettiva del database come la cosa principale da capire.

Quindi il cuore della mia domanda: quali sono alcune best practice per eseguire una riprogettazione dal livello del database a livello di un'applicazione esistente?

Penso che tu sappia già come normalizzare un database.

Ciò di cui hai bisogno sono le strategie per ridurre al minimo il rischio quando si sposta tutto il software nel nuovo database.

Quello che sto suggerendo è più lavoro come un compromesso per meno rischi.

Normalizza il database e crea un processo per popolare il database normalizzato con i dati del database originale. Il database originale sarà il database per inserimenti, aggiornamenti ed eliminazioni. Il database normalizzato sarà il database delle query solo durante la conversione.

Il processo di compilazione dovrà essere eseguito tutte le volte che è necessario disporre di dati di query. Se i dati del giorno precedente sono accettabili, è possibile eseguire un processo di popolamento notturno. Se hai bisogno di più dati attuali, devi eseguire un processo di popolamento continuo.

Crea la porzione di query del tuo nuovo sistema ASP.NET, indicando il nuovo database normalizzato.

I risultati della query dal nuovo sistema devono essere confrontati con i risultati della query dal sistema originale.

Potresti fermarti a questo punto. Questa è una decisione commerciale, non una decisione tecnica.

A tuo piacimento, crei nuove funzionalità di inserimento / aggiornamento / eliminazione nel tuo nuovo sistema ASP.NET. Quando si crea la nuova funzionalità, si disattivano le parti del sistema originale corrispondenti. Ad un certo punto, nulla del sistema originale rimane.

I vantaggi della conversione in questo modo sono la riduzione del rischio creando innanzitutto la porzione di query. Generalmente le funzioni di query sono semplici rispetto alla logica aziendale incorporata nella funzionalità di inserimento / aggiornamento / eliminazione.

Converti la funzionalità di inserimento / aggiornamento / eliminazione un processo alla volta. Se si verifica un problema di incomprensione della logica aziendale, può essere risolto mentre gli utenti utilizzano il sistema originale.

Va da sé che il processo di popolamento dovrebbe essere assolutamente coerente.

Cerca di convincerli a contrarre lo sviluppo del nuovo sistema a una società esterna, ci sono molte buone società di sviluppo che hanno le risorse per sviluppare correttamente le applicazioni più velocemente e meglio del tuo team limitato. Una buona società di sviluppo sarà anche in grado di forzare i tuoi superiori a fare cose che potrebbero non fare se tu lo richiedessi, il PM dell'azienda che viene pagato un sacco di soldi per sviluppare un'app ha molto più interesse per coinvolgere l'utente rispetto al responsabile IT molti livelli al di sotto dell'autorità di gestione per organizzare tali cose.

Costa un sacco di soldi in anticipo, ma pagherà alla grande per avere le risorse adeguate per lo sviluppo e l'implementazione. Se riesci a ottenere una RFP, scommetterei che le offerte che ricevi indicano che ciò che stai cercando di fare è molto più complicato di quanto i tuoi manager realizzino.

Progettare il database normalizzato necessario con i tipi di dati necessari. Quindi la parte più difficile è la migrazione dei dati. Per prima cosa devi avere un piano su come mappare dal vecchio al nuovo e cosa farai con i dati che non soddisfano la nuova struttura. Ad esempio, potresti avere dei dati che ora non sono identificabili se non disponi di vincoli di integrità adeguati. Potresti semplicemente non spostare tali dati o potrebbe essere necessario spostarli ma collegarli a un nuovo record principale chiamato "Sconosciuto". Se una data non è davvero una data reale, puoi inserire un valore nullo nel campo durante la migrazione? Avrai bisogno di risposte a questo tipo di domande. Suggerirei che alcuni degli sviluppatori lavorino sul cambio della GUI per utilizzare la nuova struttura del database e altri che lavorino rigorosamente sulla migrazione. La migrazione è un compito enorme, ci vorrà molta abilità e un sacco di tempo. Non lasciarlo come ripensamento.

Poiché si utilizza SQL Server, è possibile eseguire la migrazione effettiva tramite SSIS.

Crea un buon insieme solido di casi di test in modo da poter confrontare che i risultati con il vecchio sistema sono gli stessi con il nuovo sistema.

Poiché hai tanti anni di dati, potresti voler migrare in due parti. Prima migra la maggior parte dei dati e poi quando è il momento di andare in diretta, migra solo i dati modificati. Ovviamente dovresti mettere in atto dei controlli sul database per poter trovare i dati modificati che potresti non avere ancora. È inoltre possibile prendere in considerazione in questo momento se si desidera archiviare alcuni dati.

Sono confrontato con la riprogettazione dello schema del database quasi ogni giorno a causa del supporto e dell'ulteriore sviluppo di diverse applicazioni legacy che sono nate come file MS Access (.mdb) e poi cresciute in grandi database con diverse centinaia di tabelle ora situate su MS SQL Server ma con ancora "decessi infantili" del progetto originale. Ecco alcune pratiche che ho trovato utili per me:

Prova a ridurre al minimo la superficie disponibile pubblicamente dello schema del database.

Ciò significa che dovresti provare a progettare alcune API pubbliche che rendi disponibili per applicazioni esterne. Di solito cerco di implementare i dati statici come viste (anche se sono solo basati su una singola tabella) e dati dinamici come viste parametrizzate o come procedure memorizzate. Per query di dati in cui è sufficiente un solo valore, è possibile utilizzare anche funzioni scalari.

Solo questi (viste, stored procedure e funzioni scalari) sono visibili ad applicazioni esterne (tramite ORM o direttamente) e utilizzati per tutte le operazioni CRUD. Questo schema viene quindi congelato completamente, mentre internamente potresti modificare le tabelle sottostanti, migliorare le tue procedure ecc. - Ciò non comprometterà la compatibilità con la tua applicazione.

Cerca di ottimizzare i criteri del mondo reale, non quelli dei libri.

La normalizzazione è un argomento importante in ogni libro sulla progettazione di database. Ma nella vita reale ci sono casi in cui la normalizzazione non ti porterà molto o addirittura rallenterà il tuo database, ad esempio se hai alcuni dati che si ripetono, ma la percentuale di ripetizioni è molto bassa, ecc. Non sono contrario alla normalizzazione, quello che sto cercando di dire qui è che devi affrontarlo con un po 'di scetticismo e prudenza.

Registra la sessione di profilazione e analizzali.

La riprogettazione del database basata esclusivamente sullo schema del database non è completa. Guarda il tuo database nella sua dinamica, prova a trovare i colli di bottiglia durante i test di carico e risolvi questi problemi. Nel caso di MS SQL Server esiste un sintonizzatore speciale che può generare alcuni consigli sulla traccia dell'attività registrata.

Ecco la mia risposta:

1. Prima di tutto, capisci quanto è possibile l'attuale sistema di database. Devi conoscere tutti gli usi di questi sistemi e gli utenti. È necessario conoscere tutte le fonti del sistema e i sistemi che potrebbero fungere da sistema di origine.

2. È necessario identificare tutti i diversi usi del sistema, sia esso operativo o di reporting o entrambi. Identificare le applicazioni e il sistema a monte che potrebbero utilizzare il database. In questo modo, conoscerai gli elementi del database corrente che sono obsoleti e non più necessari.

3. Analizzare e comprendere anche l'attuale processo ETL che carica i dati nel database ed estrae i dati dal database.

4. Comprendere tutti gli elementi di dati del database e se è possibile creare una matrice di box che può aiutare a identificare elementi duplicati.

5. Dopo aver ottenuto tutte le informazioni, è possibile accedere alla riprogettazione come se si stesse progettando il database per la prima volta con le informazioni raccolte durante la raccolta dei requisiti.

6. In bocca al lupo!