In vista dell'avvio di un nuovo ciclo del corso abbiamo preparato un breve materiale originale con importanti consigli sulla progettazione di database. Speriamo che questo materiale possa esserti utile.
I database sono ovunque: dai semplici blog e directory ai solidi sistemi informativi e grandi reti sociali. Non è tanto importante se il database è semplice o complesso, quanto è fondamentale progettare correttamente. Quando un database è progettato senza riflessione e senza una chiara comprensione degli obiettivi, non solo non è efficace, ma il lavoro successivo con il database diventa un vero tormento, una selva inestricabile per gli utenti. Ecco alcuni consigli sulla progettazione di database che possono aiutarti a creare un prodotto utile e semplice da usare.
1. Definisci a cosa serve la tabella e qual è la sua struttura
Oggi, metodi di sviluppo come Scrum o RAD (sviluppo rapido delle applicazioni) aiutano i team IT a sviluppare rapidamente database. Tuttavia, nella corsa contro il tempo, è molto allettante tuffarsi subito nella costruzione del database, con una vaga idea di qual è l'obiettivo, quali dovrebbero essere i risultati finali.
È come se il team fosse orientato a un lavoro efficace e veloce, ma questo è un miraggio. Più ci si addentra nel progetto, più tempo sarà necessario per identificare e correggere gli errori nel progetto del database.
Pertanto, la prima cosa da decidere è definire l'obiettivo per il tuo database. Per quale tipo di applicazione viene sviluppato il database? L'utente si limiterà a lavorare con i record e sarà necessario prestare attenzione alle transazioni o è più interessato all'analisi dei dati? Dove deve essere distribuito il database? Sarà utilizzato per monitorare il comportamento dei clienti o semplicemente per gestire le relazioni tra di loro?
Prima risponde il team di progettazione a queste domande, più agevolmente e serenamente si svolgerà il processo di progettazione del database.
2. Quali dati scegliere per la memorizzazione?
Pianificate in anticipo. Pensate a cosa farà il sito o il sistema in futuro, per il quale si sta progettando il database. È importante andare oltre i semplici requisiti del capitolato tecnico. Solo, per favore, non iniziate a riflettere subito su tutti i possibili tipi di dati che l'utente potrebbe mai memorizzare. Meglio pensare se gli utenti potranno scrivere post, caricare documenti o fotografie o scambiarsi messaggi. Se è così, nel database è necessario riservare spazio per questi.
Lavorate con un team, un dipartimento o un'organizzazione per i quali il database progettato sarà sostenuto in futuro. Comunicate con persone di diversi livelli, dagli specialisti nella gestione dei clienti ai capi dei reparti. Così, grazie al feedback, avrete un'idea chiara dei requisiti dell'azienda.
I bisogni degli utenti, anche all'interno di un solo dipartimento, saranno inevitabilmente in conflitto. Se vi trovate di fronte a ciò, non esitate a fare riferimento alla vostra esperienza e trovare un compromesso che soddisfi tutte le parti e contribuisca all'obiettivo finale del database. Siate certi: in futuro riceverete +100500 in karma e una montagna di biscotti.
3. Modellate i dati con cautela
Ci sono alcuni aspetti chiave a cui prestare attenzione nella modellazione dei dati. Come già detto in precedenza, il design del database determina quali metodi utilizzare nella modellazione. Se stiamo progettando un database per l'elaborazione operativa delle registrazioni (OLTP), in altre parole per la loro creazione, modifica e cancellazione, utilizziamo la modellazione delle transazioni. Se invece il database deve essere relazionale, è meglio applicare la modellazione multidimensionale.
Durante la modellazione vengono costruiti modelli concettuali (CDM), fisici (PDM) e logici (LDM) dei dati.
I modelli concettuali descrivono le entità e i tipi di dati che includono, nonché le relazioni tra di essi. Suddividete i vostri dati in pezzi logici: sarà molto più facile.
L'importante è la misura, non esagerate.
Se un'entità è molto difficile da classificare con una sola parola o frase, è tempo di utilizzare i sottotipi (entità figlie).
Se un'entità conduce una vita propria, possiede attributi che descrivono il suo comportamento e il suo aspetto, oltre a relazioni con altri oggetti, si può tranquillamente utilizzare non solo il sottotipo ma anche il supertipo (entità genitore).
Se si ignora questa regola, altri sviluppatori si confonderanno nel vostro modello e non comprenderanno appieno i dati e le regole su come raccoglierli.
Le modelli concettuali vengono realizzati tramite modelli logici. Questi modelli fungono da mappa stradale per la progettazione della base dati fisica. Nel modello logico vengono evidenziate le entità dei dati aziendali, vengono definiti i tipi di dati, lo stato della chiave e le regole che regolano le relazioni tra i dati.
Successivamente, il modello logico dei dati viene confrontato con la piattaforma di DBMS (sistema di gestione di database) selezionata in precedenza e si ottiene il modello fisico. Esso descrive il modo di memorizzazione fisica dei dati. gestione delle basi di dati4. Utilizzare tipi di dati appropriati
Applicare un tipo di dato errato può portare a dati meno precisi, difficoltà nella fusione delle tabelle, sincronizzazione degli attributi e all'ingrossamento delle dimensioni dei file.
Per garantire l'integrità dell'informazione, un attributo deve contenere solo i tipi di dati accettabili per esso. Se si inserisce l'età nel database, assicurarsi che nella colonna siano memorizzati numeri interi fino a un massimo di 3 cifre.
Creare il minor numero possibile di colonne vuote con valore NULL. Se si creano tutte le colonne come NULL, si tratta di un errore grave. Se invece si necessita di una colonna vuota per eseguire una specifica funzione aziendale, quando i dati non sono noti o non hanno ancora senso, allora si può procedere. Infatti, non possiamo riempire in anticipo le colonne "Data di morte" o "Data di licenziamento", non siamo certo indovini che possono puntare il dito nel buio :-).
La maggior parte dei software di modellazione (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) permette di creare prototipi di aree di dati. In questo modo si garantisce non solo il corretto tipo di dato, la logica dell'applicazione e buone prestazioni, ma anche l'obbligo di impostare un valore.
5. Preferire la naturalezza.com) consente di creare prototipi di aree dati. In questo modo è garantito non solo il tipo di dati corretto, la logica dell’applicazione e le buone prestazioni, ma anche la necessaria assegnazione del valore.
5. Preferire l'approccio naturale
Quando decidi quale colonna della tabella scegliere come chiave, fai sempre attenzione a quali campi può modificare l'utente. Non scegliere mai questi come chiave: è una cattiva idea. Può succedere di tutto, e devi garantire l'unicità.
È meglio usare una chiave naturale o di business (natural key). Ha un significato semantico, così eviterai la duplicazione nel database.
A meno che la chiave di business non sia unica (nome, cognome, posizione) e venga ripetuta in diverse righe della tabella o debba essere modificata, è consigliabile nominare come chiave primaria una chiave artificiale generata (artificial key).
6. Normalizza con moderazione
Per organizzare efficacemente i dati nel database, è necessario seguire una serie di raccomandazioni e normalizzare il database. Ci sono cinque forme normali da seguire.
Con la normalizzazione eviterai la ridondanza e garantirai l'integrità dei dati utilizzati nell'applicazione o sul sito.
Come sempre, tutto deve essere fatto con moderazione, inclusa la normalizzazione. Se ci sono troppe tabelle nel database con chiavi uniche identiche, ti sei lasciato prendere la mano e hai eccessivamente normalizzato il database. Un'eccessiva normalizzazione influisce negativamente sulle prestazioni del database.
7. Testa presto, testa spesso
Il piano di test e una corretta fase di test dovrebbero essere parte della progettazione del database.
È meglio testare il database attraverso il Continuous Integration (integrazione continua). Modella lo scenario “Un giorno nella vita del database” e verifica se tutti i casi limite vengono gestiti, quali interazioni degli utenti sono probabili. Prima trovi i bug, più tempo e denaro risparmi.
Questi sono solo sette consigli che puoi seguire per progettare un ottimo database per prestazioni ed efficienza. Se li seguirai, eviterai la maggior parte dei mal di testa in futuro. Questi consigli sono solo la punta dell'iceberg nella modellazione del database. Ci sono una grande quantità di trucchi utili. Quali usi tu?
Fonte: habr.com
