In vista dell'avvio di un nuovo ciclo del corso abbiamo preparato un breve materiale originale con importanti consigli sulla progettazione delle basi di dati. Ci auguriamo che questo materiale possa esserti utile.
Le basi di dati sono ovunque: dai semplici blog e directory ai sistemi informativi affidabili e ai grandi social network. Non è tanto importante se la base è semplice o complessa, quanto è fondamentale progettarla correttamente. Quando una base è progettata senza riflessione e senza una chiara comprensione degli obiettivi, non è solo inefficace, ma il lavoro successivo con essa diventa una vera e propria sofferenza, una foresta impenetrabile per gli utenti. Ecco alcuni consigli sulla progettazione delle basi di dati che possono aiutarti a creare un prodotto utile e facile da utilizzare.
1. Definisci lo scopo della tabella e la sua struttura
Oggi, metodi di sviluppo come Scrum o RAD (sviluppo rapido di applicazioni) aiutano i team IT a sviluppare rapidamente le basi di dati. Tuttavia, nella corsa contro il tempo, c'è grande tentazione di tuffarsi direttamente nella costruzione della base, vagamente consapevoli di qual è l'obiettivo finale e quali devono essere i risultati.
Sembra che il team punti a un lavoro efficiente e veloce, ma è solo un miraggio. Più ci si immerge nel progetto, più tempo sarà necessario per identificare e correggere gli errori nella base di dati.
Pertanto, la prima cosa da risolvere è definire l'obiettivo per il tuo database. Per quale tipo di applicazione viene sviluppato il database? L'utente si occuperà solo delle registrazioni e sarà necessario prestare attenzione alle transazioni, o è più interessato all'analisi dei dati? Dove deve essere distribuito il database? Dovrà monitorare il comportamento dei clienti o semplicemente gestire le relazioni tra di loro?
Prima risponde il team di progettazione a queste domande, più fluido e semplice sarà il processo di progettazione del database.
2. Quali dati scegliere per la memorizzazione?
Pianifica in anticipo. Rifletti su cosa dovrà fare in futuro il sito o il sistema per cui viene progettato il database. È importante andare oltre i semplici requisiti del documento tecnico. Tuttavia, per favore, non iniziare a pensare a tutti i possibili tipi di dati che un utente potrebbe mai memorizzare. È meglio considerare se gli utenti possano scrivere post, caricare documenti o foto, o inviare messaggi. Se è così, il database deve riservare spazio per queste funzionalità.
Collabora con il team, il dipartimento o l'organizzazione che supporterà il database in futuro. Comunica con persone di diversi livelli, dagli addetti al servizio clienti ai responsabili dei dipartimenti. In questo modo, grazie al feedback, avrai una chiara comprensione dei requisiti dell'azienda.
È inevitabile che le esigenze degli utenti, anche all'interno di un singolo dipartimento, siano in conflitto. Se ti trovi ad affrontare questa situazione, non temere di fare riferimento alla tua esperienza e trovare un compromesso che soddisfi tutte le parti coinvolte e raggiunga l'obiettivo finale del database. Stai certo: in futuro ti arriveranno +100500 punti in karma e una montagna di biscotti.
3. Modella i dati con cautela
Ci sono alcuni aspetti chiave a cui prestare attenzione quando si modellano i dati. Come abbiamo già detto, dipende dallo scopo del database quali metodi utilizzare durante la modellazione. Se stiamo progettando un database per l'elaborazione operativa delle registrazioni (OLTP), in altre parole per creare, modificare o eliminare informazioni, utilizziamo la modellazione delle transazioni. Se invece il database deve essere relazionale, è meglio adottare una modellazione multidimensionale.
Durante la modellazione si costruiscono modelli di dati concettuali (CDM), fisici (PDM) e logici (LDM).
I modelli concettuali descrivono le entità e i tipi di dati che includono, nonché le relazioni tra di essi. Suddividi i tuoi dati in parti logiche: sarà molto più semplice gestirli.
L'importante è avere misura, senza esagerare.
Se un'entità è difficile da classificare con una sola parola o frase, è tempo di utilizzare sottotipi (entità figlie).
Se un'entità vive di vita propria, ha attributi che descrivono il suo comportamento e il suo aspetto, oltre a relazioni con altri oggetti, puoi tranquillamente utilizzare non solo il sottotipo, ma anche il supertipo (entità genitore).
Se si ignora questa regola, altri sviluppatori si confonderanno nel tuo modello e non comprenderanno appieno i dati e le regole su come raccoglierli.
I modelli concettuali vengono implementati attraverso modelli logici. Questi modelli fungono da mappa per la progettazione del database fisico. Nel modello logico si evidenziano le entità dei dati aziendali, si definiscono i tipi di dati e le regole delle chiavi che regolano le relazioni tra i dati.
Successivamente, il modello logico dei dati viene mappato sulla piattaforma DBMS (sistema di gestione database) scelta in anticipo. gestione delle basi di dati) e si ottiene il modello fisico. Descrive il modo in cui i dati vengono memorizzati fisicamente.
4. Usa i tipi di dati appropriati
L'uso di tipi di dati errati può portare a dati meno precisi, difficoltà nell'unire tabelle, nella sincronizzazione degli attributi e ad un aumento delle dimensioni dei file.
Per garantire l'integrità delle informazioni, un attributo deve contenere solo i tipi di dati accettabili. Se si inserisce l'età nel database, assicurarsi che nella colonna vengano memorizzati numeri interi con un massimo di 3 cifre.
Crea il minor numero possibile di colonne vuote con valore NULL. Se crei tutte le colonne come NULL, è un errore grave. Se hai bisogno di una colonna vuota per svolgere una specifica funzione aziendale, quando i dati sono sconosciuti o non hanno ancora significato, allora creala senza esitazione. Non possiamo riempire in anticipo le colonne 'Data di morte' o 'Data di licenziamento', non siamo dei previsori che puntano il dito nel vuoto :-).
La maggior parte dei software di modellazione (ER/Studio, MySQL Workbench, SQL DBM, gliffy.I dati delle colonne consentono di creare prototipi delle aree dati. Ciò garantisce non solo il corretto tipo di dati, la logica dell'applicazione e buone prestazioni, ma anche l'assegnazione obbligatoria del valore.
5. Preferisci la chiave naturale
Quando decidi quale colonna nella tabella utilizzare come chiave, presta sempre attenzione a quali campi possono essere modificati dall'utente. Non sceglierli mai come chiave: è una cattiva idea. Può succedere di tutto e tu devi garantire l'unicità.
È meglio utilizzare una chiave naturale, o commerciale (natural key). Ha un significato, quindi eviterai duplicati nel database.
A meno che la chiave commerciale non sia unica (nome, cognome, posizione) e si ripeta su diverse righe della tabella o debba essere modificata, è consigliabile impostare come chiave primaria una chiave artificiale, generata e surrogata (artificial key).
6. Normalizza con moderazione
Per organizzare efficacemente i dati nel database, è necessario seguire un insieme di raccomandazioni e normalizzare il database. Ci sono cinque forme normali che devono essere seguite.
Con la normalizzazione, eviterai ridondanze e garantirai l'integrità dei dati utilizzati nell'applicazione o nel sito web.
Come sempre, tutto deve essere fatto con moderazione, anche la normalizzazione. Se nel database ci sono troppe tabelle con chiavi uniche identiche, significa che hai esagerato eccessivamente nella normalizzazione del database. Un'eccessiva normalizzazione influisce negativamente sulle prestazioni del database.
7. Testa presto, testa spesso
Il piano di test e un adeguato testing devono essere parte della progettazione del database.
È meglio testare il database tramite Continuous Integration. Modella uno scenario ‘Un giorno nella vita del database’ e verifica se tutti i casi limite sono gestiti, quali interazioni degli utenti sono probabili. Prima trovi i bug, più tempo e denaro risparmi.
Ecco sette semplici consigli su come progettare un'ottima base di dati in termini di prestazioni ed efficienza. Seguendoli, eviterai la maggior parte dei mal di testa in futuro. Questi consigli sono solo la punta dell'iceberg nella modellazione dei dati. Ci sono un’enorme quantità di suggerimenti. Quali utilizzi tu?
Fonte: habr.com
