Tutorial sulla struttura e la progettazione di database

Un database ben strutturato:

• Fa risparmiare spazio su disco eliminando dati ridondanti.
• Mantiene l'accuratezza e l'integrità dei dati.
• Fornisce l'accesso ai dati in modo utile.

Per progettare un database efficiente e utile è necessario seguire il processo corretto, compresi questi passaggi:

1. Analisi dei requisiti o identificazione dello scopo del database
2. Organizzazione dei dati in tabelle
3. Determinazione delle chiavi primarie e analisi delle relazioni
4. Normalizzazione per standardizzare le tabelle

Diamo un'occhiata più da vicino ad ogni passaggio. È opportuno ricordare che questa guida tratta il modello di database relazionale di Edgar Codd espresso in SQL (piuttosto che i modelli di dati gerarchici, di rete o di oggetti). Per saperne di più sui modelli di database, leggi la nostra guida qui.

La comprensione dello scopo del database caratterizzerà le tue scelte durante il processo di progettazione. Assicurati di considerare il database da ogni prospettiva. Ad esempio, se stai realizzando un database per una biblioteca pubblica, vorrai valutare il modo in cui sia gli avventori che i bibliotecari potrebbero aver bisogno di accedere ai dati.

Ecco alcuni modi per raccogliere informazioni prima di creare il database:

• Consulta le persone che lo useranno
• Analizza moduli aziendali, come fatture, schede attività e sondaggi
• Esamina tutti i sistemi di dati esistenti (inclusi file fisici e digitali)

Inizia raccogliendo tutti i dati esistenti che verranno inclusi nel database. Quindi elenca i tipi di dati che desideri archiviare e le entità, o le persone, le cose, i luoghi e gli eventi che tali dati descrivono, in questo modo:

Clienti

• Nome
• Indirizzo
• Città, paese, CAP
• Indirizzo e-mail

Prodotti

• Nome
• Prezzo
• Quantità disponibile
• Quantità su ordinazione

Ordini

• ID ordine
• Rappresentante commerciale
• Data
• Prodotto/i
• Quantità
• Prezzo
• Totale

Queste informazioni diventeranno successivamente parte del dizionario di dati, che delinea le tabelle e i campi all'interno del database. Assicurati di suddividere le informazioni in elementi utili più piccoli possibile. Ad esempio, considera la possibilità di separare l'indirizzo dal paese, in modo da poter successivamente filtrare le persone in base al loro paese di residenza. Inoltre, evita di posizionare lo stesso punto dati in più di una tabella, in quanto aggiungerebbe una complessità non necessaria.

Una volta che sai quali tipi di dati includerà il database, da dove provengono e come verranno utilizzati, puoi iniziare a pianificare il database effettivo.

Il prossimo passaggio consiste nel creare una rappresentazione visiva del tuo database. Per fare ciò, devi capire esattamente come sono strutturati i database relazionali.

All'interno di un database, i dati correlati sono raggruppati in tabelle, ognuna delle quali è composta da righe (dette anche tuple) e colonne, come un foglio di calcolo.

Per convertire i tuoi elenchi di dati in tabelle, inizia creando una tabella per ogni tipo di entità, come prodotti, vendite, clienti e ordini. Ecco un esempio:

Ogni riga di una tabella è chiamata record. I record includono dati su qualcosa o qualcuno, come un particolare cliente. Al contrario, le colonne (note anche come campi o attributi) contengono un singolo tipo di informazioni che appaiono in ogni record, come gli indirizzi di tutti i clienti elencati nella tabella.

Nome	Cognome	Età	CAP
Roger	Williams	43	34760
Jerrica	Jorgensen	32	97453
Samantha	Hopkins	56	64829

Per mantenere coerenti i dati da un record al successivo, assegna il tipo di dati appropriato a ciascuna colonna. I tipi di dati comuni includono:

• CHAR - testo di una lunghezza specifica
• VARCHAR - testo di lunghezze variabili
• TEXT - grandi quantità di testo
• INT - numero intero positivo o negativo
• FLOAT, DOUBLE - può anche memorizzare numeri in virgola mobile
• BLOB - dati binari

Alcuni sistemi di gestione del database offrono anche il tipo di dati Autonumber, che genera automaticamente un numero univoco in ogni riga.

Ai fini della creazione di una panoramica visiva del database, nota come diagramma entità-relazione, non verranno incluse le tabelle effettive. Invece, ogni tabella diventerà una casella nel diagramma. Il titolo di ogni casella dovrebbe indicare ciò che descrivono i dati in quella tabella, mentre gli attributi vengono elencati di seguito, in questo modo:

Infine, dovresti decidere quale attributo o attributi serviranno come chiave primaria per ogni tabella, se presente. Una chiave primaria (PK) è un identificatore unico per una data entità, il che significa che si potrebbe scegliere un cliente esatto anche se si conosce solo quel valore.

Gli attributi scelti come chiavi primarie devono essere univoci, immutabili e sempre presenti (mai NULL o vuoti). Per questo motivo, i numeri degli ordini e i nomi utente sono tasti primari efficaci, mentre i numeri di telefono o gli indirizzi non lo sono. Puoi inoltre utilizzare più campi insieme come chiave primaria (questa è nota come chiave composita).

Quando arriva il momento di creare il database effettivo, inserirai sia la struttura dei dati logici che la struttura dei dati fisici nel linguaggio di definizione dei dati supportato dal tuo sistema di gestione del database. A quel punto, dovresti anche stimare la dimensione del database, per avere la certezza di poter ottenere il livello delle prestazioni e lo spazio di archiviazione che richiederà.

Ora che le tabelle del database sono state convertite in tabelle, puoi iniziare ad analizzare le relazioni tra di esse. La cardinalità si riferisce alla quantità di elementi che interagiscono tra due tabelle correlate. L'identificazione della cardinalità consente di dividere i dati in tabelle in modo più efficiente.

Ogni entità può potenzialmente avere una relazione con l'altra, ma tali relazioni sono in genere di tre tipi:

Relazioni uno a uno

Quando esiste solo un'istanza di Entità A per ogni istanza di Entità B, si dice che abbiano una relazione uno a uno (spesso scritta 1:1). Puoi indicare questo tipo di relazione in un modello ER con una linea con un trattino su ciascuna estremità:

A meno che tu non abbia una buona ragione per non farlo, una relazione 1:1 di solito indica che sarebbe meglio combinare i dati delle due tabelle in una singola tabella.

Tuttavia, potresti voler creare tabelle con una relazione 1:1 in un particolare insieme di circostanze. Se disponi di un campo con dati opzionali, come "descrizione", che è vuoto per molti dei record, è possibile spostare tutte le descrizioni nella loro propria tabella, eliminando lo spazio vuoto e migliorando le prestazioni del database.

Per garantire che i dati coincidano in modo corretto, dovresti poi aggiungere almeno una colonna identica in ogni tabella, molto probabilmente la chiave primaria.

Relazioni uno a molti

Queste relazioni si verificano quando un record contenuto in una tabella è associato a più voci presenti in un'altra. Ad esempio, un singolo cliente potrebbe aver effettuato molti ordini o un utente potrebbe aver preso in prestito dalla biblioteca più libri contemporaneamente. Le relazioni uno a molti (1:M) sono indicate con ciò che viene chiamato "notazione a zampa di gallina", come in questo esempio:

Per implementare una relazione 1:M mentre configuri un database, è sufficiente aggiungere la chiave primaria dal lato "uno" della relazione come attributo nell'altra tabella. Quando una chiave primaria viene elencata in un'altra tabella in questo modo, viene chiamata chiave esterna. La tabella sul lato "1" della relazione è considerata una tabella padre rispetto alla tabella figlio sull'altro lato.

Relazioni molti a molti

Quando più entità di una tabella possono essere associate a più entità in un'altra tabella, si dice che hanno una relazione molti a molti (M:N). Questo può accadere nel caso di studenti e classi, poiché uno studente può seguire molti corsi e una classe può avere molti studenti.

In un modello ER, queste relazioni sono rappresentate con queste linee:

Sfortunatamente, non è possibile implementare direttamente questo tipo di relazione in un database. È invece necessario dividerla in due relazioni uno a molti.

Per fare ciò, crea una nuova entità tra quelle due tabelle. Se esiste una relazione M:N tra vendite e prodotti, è possibile chiamare quella nuova entità "prodotti_venduti", poiché mostrerebbe il contenuto di ogni vendita. Sia le tabelle delle vendite che quelle dei prodotti avrebbero una relazione 1:M con prodotti_venduti. Questo tipo di entità intermedia viene chiamata tabella dei collegamenti, entità associativa o tabella di giunzione in vari modelli.

Ogni record nella tabella dei collegamenti corrisponderebbe a due delle entità nelle tabelle vicine (può includere anche informazioni supplementari). Ad esempio, una tabella di collegamenti tra studenti e lezioni potrebbe essere fatta così:

Obbligatorio o no?

Un altro modo per analizzare le relazioni è considerare quale aspetto della relazione deve essere presente perché possa esserci anche l'altra. L'aspetto non obbligatorio può essere contrassegnato da un cerchio sulla linea in cui si trova un trattino. Ad esempio, un paese deve esistere per avere un rappresentante nelle Nazioni Unite, ma non è vero il contrario:

Due entità possono essere reciprocamente dipendenti (una non potrebbe esistere senza l'altra).

Relazioni ricorsive

A volte una tabella punta a se stessa. Ad esempio, una tabella di dipendenti potrebbe avere un attributo "manager" che fa riferimento a un'altra persona nella stessa tabella. Questa si chiama relazione ricorsiva.

Relazioni ridondanti

Una relazione ridondante è una relazione espressa più di una volta. In genere, è possibile rimuovere una delle relazioni senza perdere informazioni importanti. Ad esempio, se un'entità "studenti" ha una relazione diretta con un'altra chiamata "insegnanti", ma ha anche una relazione con gli insegnanti in modo indiretto attraverso "lezioni", potresti voler rimuovere la relazione tra "studenti" e "insegnanti". È meglio eliminare quella relazione, perché l'unico modo in cui gli studenti sono assegnati agli insegnanti è attraverso le lezioni.

Non appena avrai un progetto preliminare del tuo database, potrai applicare le regole di normalizzazione per assicurarti che le tabelle siano strutturate correttamente. Pensa a queste regole come agli standard del settore.

Ciò premesso, non tutti i database sono adatti ad essere normalizzati. In generale, i database di elaborazione delle transazioni online (in breve OLTP, dall'inglese online transaction processing), in cui gli utenti si occupano di creare, leggere, aggiornare ed eliminare i record, dovrebbero essere normalizzati.

I database di elaborazione analitica online (OLAP), che favoriscono l'analisi e il reporting, potrebbero andare meglio con un certo grado di denormalizzazione, poiché la loro caratteristica prevalente è la velocità di calcolo. Questi includono applicazioni di supporto alle decisioni, in cui i dati devono essere analizzati rapidamente ma non modificati.

Ogni forma, o livello di normalizzazione, include le regole associate alle forme inferiori.

Prima forma normale

La prima forma normale (abbreviata come 1NF) specifica che ogni cella nella tabella può avere un solo valore, mai un elenco di valori, quindi una tabella come questa non è conforme:

ID prodotto	Colore	Prezzo
1	marrone, giallo	$15
2	rosso, verde	$13
3	blu, arancione	$11

Potresti essere tentato di aggirare questo problema suddividendo i dati in colonne aggiuntive, ma questo è anche contro le regole: una tabella con gruppi di attributi ripetuti o strettamente correlati non soddisfa la prima forma normale. La tabella seguente, ad esempio, non è conforme:

Invece, dividi i dati in più tabelle o record fino a quando ogni cella contiene un solo valore e non ci sono colonne extra. A questo punto, si dice che i dati sono atomici, o suddivisi per la dimensione utile più piccola. Per la tabella sopra, è possibile creare una tabella aggiuntiva denominata "Dettagli di vendita", che abbini prodotti specifici alle vendite. "Vendite" avrebbe quindi una relazione 1:M con "Dettagli vendite".

Seconda forma normale

La seconda forma normale (2NF) impone che ciascuno degli attributi sia completamente dipendente dall'intera chiave primaria. Ciò significa che ogni attributo deve dipendere direttamente dalla chiave primaria, anziché indirettamente tramite qualche altro attributo.

Ad esempio, si dice che un attributo "età", che dipende da "data di nascita", che a sua volta dipende da "ID studente", abbia una dipendenza funzionale parziale, e una tabella contenente questi attributi non riuscirebbe a soddisfare la seconda forma normale.

Inoltre, una tabella con una chiave primaria composta da più campi viola la seconda forma normale, se uno degli altri campi, oppure più campi, non dipendono da ogni parte della chiave.

Pertanto, una tabella con questi campi non soddisferebbe la seconda forma normale, poiché l'attributo "nome prodotto" dipende dall'ID prodotto ma non dal numero dell'ordine:

• Numero ordine (chiave primaria)

• ID prodotto (chiave primaria)

• Nome prodotto

 Terza forma normale

La terza forma normale (3NF) aggiunge a queste regole il requisito che ogni colonna non chiave sia indipendente da ogni altra colonna. Se la modifica di un valore in una colonna non chiave provoca la modifica di un altro valore, quella tabella non soddisfa la terza forma normale.

Ciò impedisce di archiviare tutti i dati derivati nella tabella, come la colonna "tasse", indicata di seguito, che dipende direttamente dal prezzo totale dell'ordine:

Ordine	Prezzo	Tasse
14325	$40.99	$2.05
14326	$13.73	$.69
14327	$24.15	$1.21

Sono state proposte ulteriori forme di normalizzazione, tra cui la forma normale di Boyce-Codd, le forme normali dalla quarta alla sesta e la forma normale chiave di dominio, ma le prime tre sono le più comuni.

Mentre queste forme spiegano le migliori pratiche da seguire in generale, il grado di normalizzazione dipende dal contesto del database.

Alcuni utenti potrebbero voler accedere a più dimensioni di un singolo tipo di dati, in particolare nei database OLAP. Ad esempio, potrebbero voler conoscere le vendite in base al cliente, allo stato e al mese. In questa situazione, la soluzione migliore è creare una tabella dei fatti centrale a cui possano fare riferimento altre tabelle di clienti, stato e mese, in questo modo:

Devi inoltre configurare il tuo database per convalidare i dati in base alle regole appropriate. Molti sistemi di gestione dei database, come Microsoft Access, applicano automaticamente alcune di queste regole.

La regola di integrità dell'entità stabilisce che la chiave primaria non può mai essere NULL. Se la chiave è composta da più colonne, nessuna di esse può essere NULL. Altrimenti, potrebbe non riuscire a identificare in modo univoco il record.

La regola di integrità referenziale richiede che ogni chiave esterna elencata in una tabella sia abbinata a una chiave primaria nella tabella a cui fa riferimento. Se la chiave primaria viene modificata o eliminata, tali modifiche dovranno essere implementate ovunque si faccia riferimento a tale chiave in tutto il database.

Le regole di integrità della logica aziendale assicurano che i dati rientrino in determinati parametri logici. Ad esempio, l'orario di un appuntamento dovrebbe rientrare nel normale orario di lavoro.

Un indice è essenzialmente un insieme ordinato di una o più colonne, con i valori in ordine crescente o decrescente. L'aggiunta di un indice consente agli utenti di trovare i record più rapidamente. Invece di riordinare per ogni query, il sistema può accedere ai record nell'ordine specificato dall'indice.

Sebbene l'indicizzazione acceleri il recupero dei dati, può rallentare l'inserimento, l'aggiornamento e l'eliminazione, poiché l'indice deve essere ricostruito ogni volta che viene modificato un record.

Una vista è semplicemente una query salvata sui dati. Le viste possono unire in modo utile i dati di più tabelle oppure mostrare parte di una tabella.

Una volta che hai completato il layout di base, è possibile perfezionare il database con le proprietà estese, come testo didattico, maschere di input e regole di formattazione che si applicano a uno schema, una vista o una colonna specifici. Il vantaggio è che, dato che queste regole sono archiviate nel database stesso, la presentazione dei dati sarà coerente tra i vari programmi che accedono ai dati.

L'Unified Modeling Language (UML) è un'altra modalità visiva di esprimere sistemi complessi creati mediante un linguaggio orientato agli oggetti. Molti dei concetti menzionati in questa guida sono noti nell'UML con nomi diversi. Ad esempio, nell'UML un'entità è conosciuta come una classe.

Oggi l'UML non è usato frequentemente come una volta. Attualmente viene spesso utilizzato a livello accademico e nelle comunicazioni tra i progettisti di software e i loro clienti.

Molte delle scelte di progettazione che farai dipenderanno dal sistema di gestione del database che utilizzi. Alcuni dei sistemi più comuni includono:

• Oracle DB

• MySQL

• Microsoft SQL Server

• PostgreSQL

• IBM DB2

Quando viene offerta la scelta, seleziona un sistema di gestione del database appropriato in base a costi, sistemi operativi, funzionalità e altro.