Nel corso degli anni, lavorando come modellatore di dati e architetto di database, ho notato che ci sono un paio di regole che dovrebbero essere seguite durante la modellazione e lo sviluppo dei dati. Qui descrivo alcuni suggerimenti nella speranza che possano aiutarti. Ho elencato i suggerimenti nell'ordine in cui si verificano durante il ciclo di vita del progetto anziché elencarli per importanza o per quanto sono comuni.
1. Pianifica in anticipo
Non riuscire a pianificare significa fallire.
Alan Lakein
Un problema che ho riscontrato è quando la modellazione dei dati si verifica contemporaneamente allo sviluppo del software. È come costruire le fondamenta prima di completare i progetti. In passato, la pianificazione sembrava un passaggio ovvio prima di iniziare lo sviluppo. I team di sviluppo non creerebbero database senza pianificazione, proprio come gli architetti non costruirebbero edifici senza progetti.
Nello sviluppo di applicazioni, è fondamentale comprendere la natura dei dati.
La pianificazione viene spesso ignorata in modo che gli sviluppatori possano semplicemente "iniziare a programmare". Il progetto inizia e quando emergono problemi, non c'è allentamento nel programma per affrontarli. Gli sviluppatori prendono scorciatoie con l'intento di risolverli in un secondo momento, ma ciò accade raramente, se non mai.
Un'attenta pianificazione è come assicurarsi di ottenere un database adeguato che non venga violato insieme. Se non spendi tempo e fatica in anticipo nell'affrontare i dati richiesti dai processi, li pagherai in seguito con un database che deve essere rielaborato, sostituito o demolito.
Anche se la pianificazione non viene sempre eseguita, molti modellatori di dati seguono comunque queste linee guida. Questo non vuol dire che possiamo prevedere in anticipo ogni esigenza di progettazione, ma la maggior parte dei modellatori ritiene che valga la pena di comprendere i dati e il loro utilizzo. Non vorresti un design per l'elaborazione delle transazioni quando la necessità è la creazione di report analitici.
I tempi sono cambiati; Le metodologie agili sono più diffuse, quindi i team di database devono ripensare il loro approccio alla modellazione dei dati. In Agile, viene utilizzato il modello di dominio dai casi d'uso al posto dei diagrammi di relazioni tra entità. Tuttavia, la necessità di pianificazione non è diminuita. Abbiamo bisogno di capire i dati e cosa dovrebbero fare. In generale, i primi Sprint devono concentrarsi sul design dei dati.
Quindi non è Agile il problema per i modellatori di database, ma piuttosto individui che non capiscono la natura dei dati. Alcuni vedono lo sviluppo di database come lo sviluppo di applicazioni. La modellazione del database e lo sviluppo del software sono diversi e richiedono un'attenzione adeguata.
Il database è il cuore della maggior parte delle applicazioni software. È necessario dedicare del tempo ad analizzare i requisiti e in che modo il modello di dati li soddisferà. Ciò diminuisce la possibilità che lo sviluppo perda rotta e direzione.
Gli sviluppatori devono comprendere l'importanza dei dati e il loro contributo al processo di sviluppo. Viviamo nell'era dell'informazione. Le applicazioni visualizzano e manipolano i dati. Sono le informazioni contenute nei dati che danno significato all'applicazione.
Non è possibile prevedere ogni esigenza né ogni problema, ma è importante prepararsi ai problemi con un'attenta pianificazione.
2. Documenta il tuo modello
Quando si crea un modello di dati, tutto sembra ovvio. Dai un nome agli oggetti in modo che il loro scopo sia evidente e tutti ne capiranno il significato solo leggendo il nome. Questo può essere vero, ma non è così ovvio come potresti pensare. Quando scegli i nomi per le tabelle e le colonne, chiarisci quale sarà l'utilizzo di ciascun oggetto. Nel tempo, il significato degli oggetti non sarà chiaro senza documentazione.
L'uso di una convenzione di denominazione è un passo verso una documentazione efficace. Quando dovrai apportare modifiche in futuro, apprezzerai tutta la documentazione esistente. Un documento breve e semplice che descrive le decisioni che hai preso e descrive il design aiuterà a spiegare la scelta del design in quel momento.
Vuoi una documentazione sufficiente in modo che il database possa essere gestito da un nuovo amministratore e che possano capirne il significato senza dover tornare da te per spiegazioni. Se il modello di dati e l'ambiente non sono documentati, è difficile mantenerlo o modificarlo al variare dei requisiti.
In una certa misura, la documentazione ha poco a che fare con la modellazione dei dati. La documentazione serve a comunicare il design e renderlo comprensibile in futuro.
La documentazione è spesso un ripensamento. Quando i programmi sono brevi, la documentazione viene ignorata. Eppure, questo è un debito tecnico con un costo elevato. Tagliare gli angoli durante il ciclo di sviluppo farà maturare costi in futuro per le modifiche al database, l'identificazione dei problemi, il monitoraggio dei bug e per la comprensione del modello di dati e della natura dei dati.
Ad esempio, i modelli di dati hanno spesso un campo "ID" come chiave primaria per una tabella o una parte del nome di una chiave. Potrebbe essere una chiave primaria come TransactionID sulla Transaction tavolo. Se alcune tabelle usano "Numero" come parte del nome di una chiave, è bene documentarne il motivo. Forse ReferenceNumber viene utilizzato come nome della chiave primaria sul messaggio perché è così che viene chiamato il riferimento nell'area aziendale. Ad esempio, nei servizi finanziari, i messaggi finanziari in genere includono un numero di riferimento.
Documentare la definizione di tabelle, colonne e relazioni in modo che i programmatori possano accedere alle informazioni. La documentazione deve descrivere le aspettative della struttura del database.
Nello strumento Vertabelo, posso includere immediatamente commenti su qualsiasi elemento:tabelle, colonne, riferimenti, chiavi alternative, il che significa che la documentazione viene archiviata immediatamente con il mio modello piuttosto che in qualche documento aggiuntivo da mantenere separatamente.
Una documentazione scarsa o assente è spesso dovuta a un pensiero miope, ma non ignorarne l'importanza. Questo è ancora un problema da affrontare.
3. Segui le convenzioni
Le convenzioni di denominazione potrebbero non sembrare importanti durante la progettazione. In realtà, i nomi forniscono le informazioni per comprendere un modello. Sono un'introduzione e dovrebbero essere logici.
La denominazione incoerente non serve a nulla. Frustra solo gli sviluppatori che devono accedere ai dati, gli amministratori del database e i modellatori che devono apportare modifiche in futuro.
Quando "ID" viene utilizzato per alcune chiavi artificiali ma alcune tabelle utilizzano una convenzione di denominazione diversa (come Numero), sviluppatori, analisti e DBA potrebbero perdere tempo per comprendere le eccezioni. Anche le convenzioni di denominazione deboli portano a errori di sviluppo perché la denominazione non è coerente.
Di pari passo con la documentazione, l'utilizzo di una convenzione di denominazione consente a qualcuno di comprendere il modello in futuro. Non passare in modo casuale dall'utilizzo di "ID" (come CustomerID ) e "Numero" (AccountNumber ) come chiavi per le tabelle. Fare eccezioni alle convenzioni solo quando sono giustificate. Documenta qual è l'eccezione e perché la convenzione non è rispettata.
Lo stesso vale per nomi criptici come "XRT1":sono le tabelle di riferimento estese? La tua ipotesi è buona quanto la mia. Spero che il designer sapesse perché ha scelto un nome così criptico, ma dubito che la prossima persona che accederà al database possa indovinarne il motivo.
Le convenzioni di denominazione sono una questione di scelta personale. Assicurati che le decisioni siano coerenti e documentate.
Se sono riuscito a convincerti ad applicare la convenzione di denominazione nella progettazione del tuo database, sentiti libero di leggere il mio prossimo articolo interamente dedicato a questo argomento.
4. Pensa attentamente alle chiavi
Le chiavi spesso generano controversie:chiavi primarie, chiavi esterne e chiavi artificiali. Le tabelle necessitano di una chiave primaria che identifichi ogni riga. L'arte è decidere quali colonne dovrebbero far parte della chiave primaria e quali valori includere.
Per una corretta normalizzazione, ogni tabella necessita di una chiave identificativa. L'unicità deve essere garantita. Tuttavia, le chiavi naturali e le chiavi primarie non devono essere necessariamente le stesse. In effetti, potrebbero non esserlo, purché la tabella abbia una chiave naturale.
Alcuni modellatori di dati preferiscono una chiave artificiale per l'unicità. Tuttavia, alcuni modellatori preferiscono una chiave naturale per garantire l'integrità dei dati.
Quindi, dovremmo usare una chiave naturale come chiave primaria? Una sfida sorge se la chiave naturale deve essere cambiata. Se la chiave naturale è composta da molte colonne, potrebbe essere necessario apportare modifiche in molti punti. Un'altra sfida consiste nell'usare una chiave artificiale come unica chiave per una tabella.
Ad esempio, potresti avere una tabella che memorizza informazioni sui prodotti. La tabella può essere definita con una chiave artificiale come una sequenza, un codice per il nome alfabetico breve del prodotto e la definizione del prodotto. Se l'unicità è garantita solo dalla chiave artificiale, potrebbero esserci due righe con lo stesso codice prodotto. Sono lo stesso prodotto inserito due volte? Forse una chiave con il codice prodotto è più appropriata.
5. Usa i controlli di integrità con attenzione
Per garantire l'integrità dei dati, abbiamo bisogno di chiavi esterne e vincoli. Fai attenzione a non abusare o sottoutilizzare questi controlli di integrità.
Le tabelle di dominio sono efficaci per rafforzare l'integrità. Le tabelle di dominio funzionano bene quando ci sono molti valori da confrontare o quando i valori da controllare cambiano frequentemente.
Un problema può essere che gli sviluppatori decidono che l'applicazione verificherà l'integrità. Il problema qui è che molte applicazioni potrebbero accedere a un database centrale. Inoltre, in genere vuoi proteggere i dati dove si trovano:nel database.
Se i valori possibili sono limitati o compresi in un intervallo, potrebbe essere preferibile un vincolo di controllo. Diciamo che i messaggi sono definiti come in entrata o in uscita, nel qual caso non è necessaria una chiave esterna. Ma, per qualcosa come le valute valide, sebbene queste possano sembrare statiche, in realtà cambiano di volta in volta. I paesi aderiscono a un'unione monetaria e le valute cambiano.
Le applicazioni dovrebbero anche eseguire controlli di integrità, ma non fare affidamento solo sull'applicazione per il controllo di integrità. La definizione di regole di integrità sul database garantisce che tali regole non vengano mai violate. In questo modo, i dati soddisfano in ogni momento le regole di integrità definite.
6. Non dimenticare gli indici nel tuo design
Alcuni progetti di indicizzazione sono utili durante la modellazione del database, anche se gli indici possono cambiare durante la distribuzione e l'utilizzo effettivi. Certo, è possibile avere troppi indici, così come è possibile averne troppo pochi.
L'indicizzazione è un processo continuo. Durante la progettazione, inizi il processo sul tuo modello. Il lavoro di progettazione riguarda le chiavi primarie e i vincoli.
Gli indici sono importanti quando si considerano le query sui dati. Durante la modellazione, dovresti considerare come verranno interrogati i dati. Fare attenzione a non indicizzare eccessivamente. L'indicizzazione ruota attorno all'ottimizzazione delle query.
7. Evita le tabelle di ricerca comuni
Ho visto spesso una tabella di ricerca comune per le coppie di attributi. Si ritiene che la definizione di una singola tabella di dominio generica semplifichi la progettazione. Questo stile di tabella di dominio crea una definizione astratta per contenere il testo. L'ho sentito chiamare tabella "Valori consentiti" o "Valori validi", ma il termine tabella "MUCK" è stato coniato per questo anti-modello nel 2006:Code-Key massicciamente unificata.
Le tabelle MUCK contengono dati non correlati.
Ad esempio, potresti avere una tabella che definisce il dominio, la voce e una descrizione. Ripensando all'esempio di messaggio sopra, due voci potrebbero essere:
| Dominio | Entrata | Descrizione |
|---|---|---|
| 1 | Io | Messaggio in arrivo ricevuto dalla banca |
| 1 | O | Messaggio in uscita inviato dalla banca |
Ora aggiungi le voci per un altro dominio:
| Dominio | Entrata | Descrizione |
|---|---|---|
| 2 | COPERTINA | Pagamento di copertura |
| 2 | SERIAL | Pagamento seriale |
| 2 | SSI | Istruzioni di regolamento standard |
Questo è solo un pasticcio. Cosa significa la tabella?
Solo per divertimento, ho modellato un semplice esempio di una tabella MUCK (o OTLT, "One True Lookup Table" se sei un fan di Tolkien) e ho incluso alcuni commenti. Tieni presente che questo è un anti-pattern e ti sconsiglio di utilizzarlo nel tuo modello di dati.
Con le tabelle MUCK non è possibile definire vincoli. I MUCK possono diventare molte righe senza alcun significato. Quando devi interrogare un'altra tabella per capire il significato di un campo, questo non è l'ideale.
Queste tabelle "va bene qualsiasi cosa" rendono i controlli di integrità complessi o addirittura impossibili. Uno dei motivi per cui queste tabelle possono essere create è perché diverse tabelle all'interno del database hanno una definizione simile. Quindi i controlli dell'integrità dei dati diventano impossibili. Inoltre, le loro dimensioni possono diventare piuttosto grandi.
La normalizzazione dovrebbe allontanarsi dalle tabelle MUCK. Una singola tabella dovrebbe rappresentare un singolo dominio; piuttosto che una singola tabella (MUCK) che rappresenta tutti i domini. Senza le tabelle MUCK, possiamo mettere in atto vincoli di chiave esterna.
Utilizzare tabelle separate per gli oggetti di dominio anziché stipare in un'unica tabella. Ciò consente tipi di colonna, vincoli e relazioni appropriati. Una tabella "Valori consentiti" è solo un pasticcio e non ha posto in un modello di dati.
8. Definire una strategia di archiviazione
Troppo spesso ho visto database creati senza una strategia adeguata di conservazione e archiviazione dei dati. Per quanto tempo i dati saranno mantenuti online disponibili nelle tabelle di database attive? La maggior parte dei sistemi sono costruiti per mantenere i dati nel database "per sempre". Per la maggior parte dei sistemi, questa non è una strategia ragionevole di conservazione dei dati a lungo termine. Ad un certo punto, i dati attivi dovrebbero essere archiviati.
Un approccio che sostengo è quello di includere la conservazione dei dati come parte delle considerazioni sulla progettazione. Avrai tabelle attive e storiche in modo che gli inserimenti di nuove righe nelle tabelle attive rimangano veloci, mentre le ricerche sui dati storici possano essere ottimizzate?
Ciò evita di dover riprogettare l'archiviazione nel database in base al progetto originale.
9. Testare in anticipo, testare spesso
Per parafrasare Al Capone (o John Van Buren, figlio dell'8° presidente degli Stati Uniti), “provate presto, provate spesso”. In questo modo segui il percorso dell'Integrazione Continua. I test in una fase di sviluppo iniziale consentono di risparmiare tempo e denaro.
I test sono sempre una sfida nel piano di sviluppo. Spesso c'è una fase di test al termine di un Agile Sprint e un test di sistema al termine dello sviluppo. Il test è generalmente la prima cosa da spremere quando il tempo si riduce.
Nel testare il database, l'obiettivo dovrebbe essere quello di simulare un ambiente di produzione:"Un giorno nella vita del database". Quali volumi ci si può aspettare? Quali interazioni dell'utente sono probabili? I casi limite vengono gestiti?
Quindi il piano di test e il test adeguato devono essere parte integrante della modellazione dei dati e dello sviluppo del database.
Conclusione
Questi sono i problemi principali che ho riscontrato durante il lavoro con i modellatori di dati e la revisione dei modelli di dati. Prestando attenzione a questi suggerimenti, il tuo database sarà progettato meglio e più robusto. Tuttavia, il ritorno di alcuni di questi investimenti non è sempre evidente o visibile. Pianifica, documenta, utilizza standard, crea chiavi, assicurati l'integrità, esegui indicizzazione, evita MUCK, sviluppa strategie e TEST!
Nessuna di queste attività richiederà un'enorme quantità di tempo, ma avrà un enorme impatto sulla qualità del tuo modello di dati.
Quali sono le tue opinioni su questi suggerimenti?
