Ho raccolto per voi del materiale per affrontare la progettazione dei database, inserendo

anche degli esercizi svolti e infine un documento per conoscere la terminologia inglese
Progettazione di database
La progettazione dei database | Corsi PHP | PHPnews.it
phpnews.it
Corso Progettazione Data Base ITA 1 - presentazione del corso e strumenti
youtube.com
Nozioni fondamentali sulla progettazione di database - Access
support.office.com
Progettazione-1 - Prof.ssa Rosalba Giugno - progettazione-1.pdf
dmi.unict.it
Progettare un database per MySQL, trucchi e scorciatoie
html.it
Esercizi progettazione1 - Esercizi progettazione.pdf
home.deib.polimi.it
Esercizi progettazione2 EserciziEA - EserciziEA.pdf
di.unito.it
Database design basics - Access
support.office.com

La progettazione dei database | Corsi PHP | PHPnews.it

13 Lezioni | di Andrea Aulicino
Introduzione al concetto di database Relazionale
Introduzione ai database relazionali
I DBMS
DBMS: DataBase Management System
La progettazione di una base di dati
La progettazione di una base di dati (database).
Il mini-mondo

Analisi del mini-mondo della base di dati (database)

Progettazione concettuale: il Modello ER
Il modello ER entit relazione, la progettazione concettuale di una base di dati
(database)
Esempi di diagrammi ER
Diagrammi ER Entit Relazione
Il dominio di un attributo
Il dominio di un attributo di una entit del modello ER Entit Relazione
La chiave primaria
La chiave primaria
Progettazione logica: il Modello Relazionale
Il modello relazionale di una base di dati (database). La progettazione logica.
Conversione del Modello ER in Modello Relazionale
Conversione del Modello ER Entit Relazione in Modello Relazionale
Chiave primaria surrogata
La chiave primaria surrogata
Normalizzazione e denormalizzazione del database
Normalizzazione e denormalizzazione di una base di dati (database)
Dal Modello Relazionale al DDL dell'RDBMS
Dal Modello Relazionale al DDL dell'RDBMS

SE INVECE VI PIACE SEGUIRE DEI TUTORIAL SU YOUTUBE VI CONSIGLIO

Corso Progettazione Data Base ITA 1 - presentazione del corso e

strumenti: video su youtube
VEDI LA PRESENTAZIONE DEL CORSO
PER APPROFONDIMENTI
DAL SITO DI MICROSOFT

Nozioni fondamentali sulla progettazione di database - Access

Un database progettato correttamente consente l'accesso a informazioni
aggiornate e accurate. Poich una progettazione corretta essenziale per raggiungere gli
obiettivi per cui si utilizza un database, pu essere utile investire il tempo necessario per
apprendere i principi di una buona progettazione. In definitiva, sar molto pi probabile
ottenere un database che soddisfi esigenze specifiche e che supporti facilmente le
modifiche.
In questo articolo vengono descritte le linee guida per la pianificazione di un
database desktop. Verr inoltre illustrato come identificare le informazioni necessarie e
come suddividerle in tabelle e colonne appropriate, nonch come si imposta una
correlazione fra tali tali. Prima di procedere alla creazione del primo database desktop,
consigliabile leggere il presente articolo.
Importante : In Microsoft Access 2010 possibile utilizzare modalit di
progettazione innovative che consentono di creare applicazioni di database per il Web.
Quando si progetta per il Web necessario prendere in considerazione diversi aspetti. In
questo articolo non viene descritta la progettazione di applicazioni di database Web.
Terminologia di database che utile conoscere
In Access 2010 le informazioni vengono organizzate in tabelle, ovvero elenchi di
righe e colonne paragonabili a un registro contabile o a un foglio di calcolo. In un
semplice database pu essere presente una sola tabella, ma per la maggior parte dei
database ne sono necessarie pi d'una. In una tabella possibile, ad esempio, archiviare
informazioni sui prodotti, in un'altra tabella le informazioni sugli ordini e in un'altra
ancora le informazioni sui clienti.

Ogni riga viene pi correttamente definita record e ogni colonna detta campo.
Un record costituisce un modo significativo e coerente di combinare informazioni su
vari elementi. Un campo un singolo elemento di informazioni, ovvero un tipo di
elemento che viene visualizzato in ogni record. Nella tabella Prodotti, ad esempio, ogni
riga o record conterr informazioni su un prodotto, mentre in ogni colonna o campo sar
incluso un qualche tipo di informazioni su tale prodotto, ad esempio il nome o il prezzo.
Descrizione di una progettazione di database corretta
Il processo di progettazione di un database si basa su determinati principi, il primo
dei quali che la presenza di informazioni duplicate, dette anche dati ridondanti,
costituisce un aspetto negativo, in quanto si spreca spazio e si aumenta la probabilit di
introdurre errori e incoerenze. Il secondo principio che la correttezza e la completezza
delle informazioni sono elementi importanti. Se il database contiene informazioni non
corrette, anche tutti i report che recuperano informazioni da tale database conterranno
informazioni non corrette. Di conseguenza, qualsiasi decisione assunta in base a tali
report sar fondata su informazioni errate.
Una progettazione di database corretta consentir pertanto di:
o Divider le informazioni in tabelle basate su un argomento per ridurre i dati
ridondanti.
o Immettere in Access le informazioni necessarie per unire in join le
informazioni nelle tabelle secondo le esigenze.
o Supportare e assicurare l'accuratezza e l'integrit delle informazioni.
o Soddisfare le esigenze di elaborazione dei dati e di creazione di report.

Processo di progettazione
Il processo di progettazione costituito dai passaggi seguenti:
Determinare lo scopo del database utile per prepararsi ai passaggi rimanenti.
Individuare e organizzare le informazioni necessarie Raccogliere tutti i tipi di
informazioni che potrebbe essere necessario registrare nel database, ad esempio nome
del prodotto e numero d'ordine.
Dividere le informazioni in tabelle Dividere gli elementi di informazioni in
entit o argomenti principali, ad esempio Prodotti o Ordini. Ogni argomento diventa
quindi una tabella.
Trasformare elementi di informazioni in colonne Stabilire quali informazioni
si desidera archiviare in ogni tabella. Ogni elemento diventa un campo e viene
visualizzato sotto forma di colonna nella tabella. Una tabella Dipendenti potrebbe, ad
esempio, includere campi quali Cognome e Data di assunzione.
Specificare le chiavi primarie Scegliere la chiave primaria di ogni tabella. La
chiave primaria una colonna utilizzata per identificare in modo univoco ogni riga, ad
esempio ID prodotto o ID ordine.
Impostare le relazioni tra tabelle Esaminare ogni tabella e decidere in che
modo i dati presenti in una tabella sono correlati ai dati in altre tabelle. Aggiungere
campi alle tabelle o creare nuove tabelle per chiarire le relazioni, se necessario.
Ottimizzare la progettazione Analizzare la progettazione per verificare se sono
presenti errori. Creare le tabelle e aggiungere alcuni record di dati di esempio.
Controllare se possibile ottenere i risultati desiderati da tali tabelle. Apportare
modifiche alla progettazione, se necessario.
Applicare le regole di normalizzazione Applicare le regole di normalizzazione
dei dati per verificare se le tabelle sono strutturate correttamente. Apportare modifiche
alle tabelle, se necessario.
Identificazione dello scopo del database
consigliabile annotare su carta lo scopo del database, ovvero qual lo scopo,
come si prevede di utilizzarlo e chi lo utilizzer. Per un piccolo database per un'attivit
di piccole dimensioni, ad esempio, possibile scrivere qualcosa di molto semplice come
"Il database dei clienti contiene un elenco di informazioni sui clienti allo scopo di
produrre lettere e report". Se il database pi complesso o viene utilizzato da molte
persone, come accade stesso in una configurazione aziendale, lo scopo pu facilmente
richiedere uno o pi paragrafi e dovrebbe includere l'indicazione su quando o come ogni
persona utilizzer il database. L'idea di avere un'esposizione degli obiettivi ben
sviluppata a cui sia possibile fare riferimento durante tutto il processo di progettazione.
La disponibilit di tale esposizione consente di concentrarsi sugli obiettivi quando si
assumono decisioni.

Individuazione e organizzazione delle informazioni necessarie

Per individuare e organizzare le informazioni necessarie, iniziare da quelle
esistenti. possibile, ad esempio, che gli ordini di acquisto vengano registrati in un libro
mastro o che le informazioni relative ai clienti siano annotate su moduli cartacei
conservati in uno schedario. Raccogliere tali documenti ed elencare ogni tipo di
informazioni rilevate, ad esempio tutte le caselle che vengono compilate in un modulo.
Se non sono disponibili moduli esistenti, si supponga invece di dover progettare un
modulo per la registrazione delle informazioni relative ai clienti, cercando di
immaginare quali informazioni verrebbero inserite nel modulo, quali caselle compilabili
sarebbe opportuno creare, identificando ognuno di questi elementi e creandone un
elenco. Si supponga inoltre, ad esempio, che attualmente per l'elenco dei clienti vengano
utilizzate schede. L'esame di tali schede potrebbe rivelare che su ogni scheda sono
indicati il nome del cliente, l'indirizzo, la citt, lo stato il codice postale e il numero di
telefono. Ognuno di questi elementi rappresenta una potenziale colonna di una tabella.
Non necessario che questo elenco risulti perfetto durante la preparazione
iniziale. invece consigliabile includere nell'elenco tutti gli elementi possibili e
chiedere suggerimenti a eventuali altre persone che utilizzeranno il database. L'elenco
potr essere ottimizzato in un momento successivo.
quindi opportuno considerare i tipi di report o lettere che si desidera generare
dal database. Ad esempio, potrebbe essere utile creare un report sulle vendite di prodotti
in cui sono visualizzate le vendite per zona oppure un report di inventario riepilogativo
con i livelli di scorte dei prodotti. Potrebbe inoltre essere utile generare lettere tipo da
inviare ai clienti per annunciare una vendita speciale o per offrire un bonus. Progettare il
report mentalmente, immaginando quale aspetto avr. Stabilire quali informazioni si
desidera inserire nel report e aggiungerle all'elenco. Procedere allo stesso modo per la
lettera tipo e per qualsiasi altro report che si prevede di creare.

Pensare ai report e alle lettere che potrebbe essere utile creare consente di

identificare pi facilmente gli elementi richiesti nel database. Si supponga, ad esempio,

di voler offrire ai clienti l'opportunit di accettare o rifiutare esplicitamente
aggiornamenti periodici tramite posta elettronica e di voler stampare un elenco dei
clienti che hanno accettato. Per registrare tali informazioni, aggiungere una colonna
Invio messaggio di posta elettronica alla tabella dei clienti e impostare il campo su S
o No per ogni cliente.
Il requisito di inviare messaggi di posta elettronica ai clienti suggerisce un altro
elemento da registrare. Dopo avere ricevuto la conferma che un cliente desidera ricevere
messaggi di posta elettronica, si dovr conoscere l'indirizzo di posta elettronica a cui
inviarli. quindi necessario registrare un indirizzo di posta elettronica per ogni cliente.
consigliabile creare un prototipo di ogni report o elenco di output e considerare
quali elementi saranno necessari per generare il report. Ad esempio, esaminando una
lettera tipo si potrebbe pensare ad alcuni particolari. Se si desidera includere una vera e
propria formula di apertura, ad esempio una stringa "Sig.", "Sig.ra" o "Sig.na" iniziale, si
dovr creare un elemento per la formula di apertura. inoltre possibile che si desideri
iniziare solitamente una lettera con la formula Egr. Sig. Macagno, anzich Egr. Sig.
Maurizio Macagno. Ci suggerisce che in genere consigliabile archiviare il cognome
separatamente dal nome.
Un punto chiave da ricordare la necessit di suddividere ogni informazione nelle
relative parti utili pi piccole. Nel caso di un nome, per render immediatamente
disponibile il cognome, opportuno dividere il nome in due parti, Nome e Cognome.
Per ordinare un report in case al cognome, ad esempio, utile archiviare separatamente
il cognome del cliente. in genere consigliabile inserire in un campo separato le
informazioni in base alle quali si desidera applicare criteri di ordinamento, ricerca e
calcolo oppure creare un report.
Pensare alle domande alle quali il database dovrebbe rispondere. Ad esempio, la
quantit di vendite chiuse per il prodotto in primo piano durante il mese precedente,
dove risiedono i clienti migliori, chi il fornitore del prodotto pi venduto. La capacit
di prevedere queste domande consente di focalizzare l'attenzione su ulteriori elementi da
registrare.
Dopo avere raccolto queste informazioni, possibile procedere al passaggio
successivo.
Suddivisione delle informazioni in tabelle
Per dividere le informazioni in tabelle, scegliere le entit o gli argomenti
principali. Dopo avere individuato e organizzato le informazioni, ad esempio, per un
database relativo alle vendite di prodotti, l'elenco preliminare potrebbe avere l'aspetto
seguente:

Le principali entit qui illustrate sono i prodotti, i fornitori, i clienti e gli ordini.
quindi consigliabile iniziare con queste quattro tabelle: una per le informazioni sui
prodotti, una per le informazioni sui fornitori, una per le informazioni sui clienti e una
per le informazioni sugli ordini. Anche se l'elenco non completo, un buon punto di
partenza. possibile continuare a ottimizzare questo elenco finch non si ottiene una
progettazione appropriata.
Quando inizialmente si esamina l'elenco di elementi preliminare, si potrebbe
essere tentati di inserirli tutti in un'unica tabella, anzich le quattro illustrate nella figura
precedente. Di seguito viene spiegato perch non opportuno procedere in questo modo.
Si consideri per un momento la tabella illustrata di seguito:

In questo caso ogni riga contiene informazioni sia sul prodotto che sul relativo
fornitore. Poich possibile che vengano acquistati molti prodotti dallo stesso fornitore,
il nome del fornitore e le informazioni sull'indirizzo devono essere ripetute molte volte,
con uno spreco di spazio su disco. La registrazione delle informazioni sul fornitore una
sola volta in una tabella Fornitori distinta, una soluzione decisamente migliore.
Un secondo problema con questa progettazione si presenta quando necessario
modificare le informazioni sul fornitore. Si supponga ad esempio di dover modificare
l'indirizzo del fornitore. Poich viene visualizzato in diverse posizioni, possibile che
l'indirizzo venga modificato in una posizione che che si dimentichi accidentalmente di
modificarlo in un'altra. Registrando l'indirizzo del fornitore in una sola posizione si
risolve invece il problema.
Quando si progetta un database, sempre opportuno cercare di registrare ogni
dato una sola volta. Se si rileva che la stessa informazione viene ripetuta in pi

posizioni, ad esempio l'indirizzo di un particolare fornitore, inserire tale informazione in

una tabella distinta.
Si supponga infine che Coho Winery fornisca un solo prodotto e che si desideri
eliminare tale prodotto mantenendo il nome del fornitore e le informazioni sull'indirizzo.
Non possibile eliminare il record del prodotto senza perdere le informazioni sul
fornitore. Poich infatti ogni record contiene dati su un prodotto, nonch dati relativi a
un fornitore, non possibile eliminarne uno senza eliminare l'altro. Per mantenere
separati questi dati, necessario dividere una tabella in due: una per le informazioni sul
prodotto e un'altra per le informazioni sul fornitore. In questo modo l'eliminazione di un
record relativo al prodotto canceller solo i dati relativi a tale prodotto, non quelli
relativi al fornitore.
Dopo avere scelto l'argomento rappresentato da una tabella, nelle relative colonne
dovranno essere archiviati solo dati su tale argomento. Nella tabella dei prodotti, ad
esempio, devono essere archiviati solo dati sui prodotti. Poich l'indirizzo del fornitore
un dato relativo al fornitore e non al prodotto, appartiene alla tabella dei fornitori.
Trasformazione di elementi di informazioni in colonne
Per determinare le colonne di una tabella, opportuno stabilire quali sono le
informazioni relative all'argomento registrato nella tabella di cui necessario tenere
traccia. Per la tabella Clienti, ad esempio, Nome, Indirizzo, Citt-Stato-CAP, Invio
messaggio di posta elettronica, Formula di apertura e Posta elettronica sono un buon
elenco di colonne da cui iniziare. Ogni record nella tabella contiene lo stesso set di
colonne, quindi possibile archiviare informazioni relative a Nome, Indirizzo, CittStato-CAP, Invio messaggio di posta elettronica, Formula di apertura e Posta elettronica
per ogni record. La colonna Indirizzo, ad esempio, contiene l'indirizzo per quel cliente.
Dopo avere determinato il set iniziale di colonne per ogni tabella, possibile
definire le colonne con ancora maggiore precisione. consigliabile, ad esempio,
archiviare il nome del cliente in due colonne distinte, nome e cognome, in modo da
poter eseguire operazioni di ordinamento, ricerca e indicizzazione solo su tali colonne.
In modo analogo, l'indirizzo in effetti composto da cinque componenti distinti, ovvero
indirizzo, citt, provincia, CAP e paese, e anche in questo caso consigliabile archiviarli
in colonne distinte. Se si desidera eseguire un'operazione di ricerca o di ordinamento
oppure applicare un filtro in base, ad esempio, alla provincia, necessario archiviare le
informazioni corrispondenti in una colonna distinta.
opportuno considerare inoltre se il database conterr informazioni solo di
origine nazionale o anche internazionale. Se si prevede, ad esempio, di archiviare
indirizzi internazionali, preferibile creare una colonna Paese anzich provincia, in
modo da potervi inserire sia la provincie nazionali sia le aree di altri paese. Una colonna
CAP sar invece appropriata anche per archiviare indirizzi internazionali.
Nell'elenco seguente sono ripostati alcuni suggerimenti utili per determinare quali

colonne creare.
Non includere dati calcolati Nella maggior parte dei casi, consigliabile non
archiviare risultati di calcoli nelle tabelle. Al contrario, possibile fare in modo che i
calcoli vengano eseguiti da Access quando si desidera visualizzare il risultato. Si
supponga, ad esempio, di avere un report Prodotti ordinati in cui viene visualizzato il
subtotale delle unit ordinate per ogni categoria di prodotto nel database.Non tuttavia
presente una colonna di subtotale Unit ordinate in alcuna tabella. La tabella Prodotti
include invece una colonna Unit ordinate in cui sono archiviate le unit ordinate per
ogni prodotto. Utilizzando questi dati, Access in grado di calcolare il subtotale ogni
volta che si stampa il report. consigliabile non archiviare il subtotale stesso in una
tabella.
Archiviare le informazioni nelle relative parti logiche pi piccole Si potrebbe
essere tentati di creare un singolo campo per nomi e cognomi o per nomi di prodotti e
relative descrizioni. Se si combina pi di un tipo di informazioni in un campo, sar
difficile recuperare i dati in seguito. Cercare di scomporre le informazioni in parti
logiche. Ad esempio, creare campi distinti per nome e per cognome o per nome di
prodotto, categoria e descrizione.

Dopo avere ottimizzato le colonne dati in ogni tabella, possibile scegliere la

relativa chiave primaria.
Specifica di chiavi primarie
consigliabile includere in ogni tabella una colonna o un set di colonne che
identifichi in modo univoco ogni riga archiviata nella tabella. Si tratta spesso di un
numero di identificazione univoco, ad esempio il numero ID di un dipendente o un

numero di serie. Nella terminologia di database queste informazioni sono definite chiave
primaria della tabella. In Access i campi chiame primaria vengono utilizzati per
associare rapidamente dati da pi tabelle e riunire automaticamente i dati.
Se si dispone gi di un identificatore univoco per una tabella, ad esempio un
numero di prodotto che identifica in modo univoco ogni prodotto nel catalogo,
possibile utilizzarlo come chiave primaria della tabella, ma solo se i valori in questa
colonna saranno sempre diversi per ogni record. Non possibile utilizzare valori
duplicati in una chiave primaria. Non utilizzare, ad esempio, nomi di persone come
chiave primaria, poich i nomi non sono univoci. molto facile che due persone
abbiano lo stesso nome nella stessa tabella.
Una chiave primaria deve avere sempre un valore. Se il valore di una colonna pu
diventare a un certo punto non assegnato o sconosciuto (valore mancante), non pu
essere utilizzato come componente di una chiave primaria.
consigliabile scegliere sempre una chiave primaria il cui valore non venga
modificato. In un database che utilizza pi di una tavella, possibile utilizzare la chiave
primaria di una tabella come riferimento in altre tabelle. Se la chiave primaria viene
modificata, tale modifica dovr essere applicata anche a qualsiasi altro elemento in cui
viene fatto riferimento a tale chiave. L'utilizzo di una chiave primaria non soggetta a
modifiche riduce la possibilit che non sia pi sincronizzata con altre tabelle che vi
fanno riferimento.
Spesso come chiave primaria viene utilizzato un numero univoco arbitrario.
possibile, ad esempio, assegnare a ogni ordine un numero d'ordine univoco. Poich il
solo scopo di un numero d'ordine quello di identificare un ordine, dopo essere stato
assegnato non viene mai modificato.
Se non si dispone di una colonna o di un set di colonne adatte a costituire la
chiave primaria, possibile utilizzare una colonna con tipo di dati Numerazione
automatica. Quando si utilizza questo tipo di dati, viene assegnato automaticamente un
valore. Tale identificatore non rappresenta un dato effettivo, ovvero non contiene alcuna
informazione effettiva che descriva la riga a cui associato. L'utilizzo di questo tipo di
identificatori come chiave primaria ideale in quanto non vengono modificati. Una
chiave primaria che contiene dati relativi a una riga, ad esempio un numero di telefono o
il nome di un cliente, pi facilmente soggetta a modifiche, poich i dati stessi che
contiene potrebbero variare nel tempo.

1. Una colonna impostata sul tipo di dati Numerazione automatica rappresenta

spesso una chiave primaria appropriata poich garantisce l'univocit di tutti gli ID
prodotto.

In alcuni casi possibile utilizzare due o pi campi che insieme costituiscono la

chiave primaria di una tabella. In una tabella Dettagli sugli ordini in cui sono
memorizzate le voci d'ordine potrebbero, ad esempio, essere utilizzate come chiave
primaria due colonne, ovvero ID ordine e ID prodotto. Le chiavi primarie costituite da
pi colonne vengono inoltre definite chiavi composte.
Per il database relativo alle vendite di prodotti possibile creare una colonna
Numerazione automatica per ognuna delle tabelle utilizzate come chiave primaria:
IDProdotto per la tabella Prodotti, IDOrdine per la tabella Ordini, IDCliente per la
tabella Clienti e IDFornitore per la tabella Fornitori.

Creazione di relazioni tra tabelle

Dopo avere suddiviso le informazioni in tabelle, necessario riunire di nuovo tali
informazioni nei modi appropriati. Nella maschera seguente, ad esempio, sono incluse
informazioni recuperate da diverse tabelle.

1. Le informazioni nella maschera provengono dalla tabella Clienti...

2. ...dalla tabella Dipendenti...
3. ...dalla tabella Ordini...
4. ...dalla tabella Prodotti...
5. ...e dalla tabella Dettagli sugli ordini.
Access un sistema di gestione di database relazionali. In un database relazionale
le informazioni vengono suddivise in tabelle distinte in base all'argomento. Le relazioni
tra tabelle vengono quindi utilizzate per riunire le informazioni secondo le esigenze.
Creazione di una relazione uno-a-molti
Si consideri l'esempio seguente, in cui il database relativo ai prodotti ordinati
include le tabelle Fornitori e Prodotti. Un fornitore pu fornire una quantit qualsiasi di
prodotti. Di conseguenza, per qualsiasi fornitore rappresentato nella tabella Fornitori
possono essere rappresentati molti prodotti nella tabella Prodotti. Tra la tabella Fornitori
e la tabella Prodotti esiste pertanto una relazione uno-a-molti.

Per rappresentare una relazione uno-a-molti nella progettazione del database,

aggiungere la chiave primaria del lato "uno" della relazione come colonna o colonne
aggiuntive alla tabella sul lato "molti" della relazione. In questo caso, ad esempio, si
aggiunge la colonna ID fornitore dalla tabella fornitori alla tabella Prodotti. Il numero di
ID fornitore potr quindi essere utilizzato da Access nella tabella Prodotti per
individuare il fornitore corretto per ogni prodotto.
La colonna ID fornitore nella tabella Prodotti detta chiave esterna. Una chiave
esterna un'ulteriore chiave primarie della tabella. La colonna ID fornitore nella tabella
Prodotti una chiave esterna, in quanto anche la chiave primaria della tabella
Fornitori.

Per creare le basi per unire in join tabelle correlate, necessario definire coppie di
chiavi primarie e chiavi esterne. Se non si certi delle tabelle che dovrebbero
condividere una colonna comune, identificare una relazione uno-a-molti per assicurare
che le due tabelle interessate richiedano in effetti una colonna condivisa.
Creazione di una relazione molti-a-molti
Si consideri la relazione tra una tabella Prodotti e una tabella Ordini.
Un singolo ordine pu includere pi prodotti, mentre un singolo prodotto pu
essere incluso in molti ordini. A ogni record della tabella Ordini possono pertanto
corrispondere molti record della tabella Prodotti e a ogni record della tabella Prodotti
possono corrispondere molti record della tabella Ordini. Questo un tipo di relazione
molti-a-molti, poich a qualsiasi prodotto possono corrispondere molti ordini e a
qualsiasi ordine possono corrispondere molti prodotti. Per rilevare le relazioni molti-amolti tra le tabelle, importante considerare entrambi i lati della relazione.
Gli argomenti delle due tabelle, Ordini e Prodotti, sono collegati da una relazione
molti-a-molti e ci rappresenta un problema. Per comprendere il problema, si immagini
cosa accadrebbe se si tentasse di creare la relazione tra le due tabelle aggiungendo il
campo ID prodotto alla tabella Ordini. Per inserire pi prodotti per ogni ordine, nella
tabella Ordini deve essere presente pi di un record per ordine. Si dovrebbero ripetere le
informazioni relative agli ordini per ogni riga correlata a un singolo ordine, ottenendo
una progettazione inefficiente che potrebbe generare dati non corretti. Lo stesso
problema si verifica se si inserisce il campo ID ordine nella tabella Prodotti, poich nella
tabella Prodotti sarebbe presente pi di un record per ogni prodotto. Di seguito viene
descritto come risolvere il problema.
Creare una terza tabella, in genere denominata tabella di collegamento, che
consente di suddividere la relazione molti-a-molti in due relazioni uno-a-molti. Nella
terza tabella viene inserita la chiave primaria di ognuna delle due tabelle, registrando
cos ogni occorrenza o istanza della relazione.

Ogni record nella tabella Dettagli sugli ordini rappresenta una voce in un ordine.
La chiave primaria della tabella Dettagli sugli ordini costituita da due campi, le chiavi
esterne delle tabelle Ordini e Prodotti. Non possibile utilizzare il campo ID ordine da
solo come chiave primaria per questa tabella, poich a un ordine possono corrispondere
pi voci. L'ID ordine viene ripetuto per ogni voce di un ordine, di conseguenza il campo
non contiene valori univoci. Non possibile utilizzare nemmeno il campo ID prodotto
da solo, in quanto un prodotto pi essere presente in molti ordini diversi. Utilizzati
insieme, tuttavia, i due campi generano sempre un valore univoco per ogni record.
Nel database relativo alle vendite di prodotti la tabella Ordini e la tabella Prodotti
non sono correlate direttamente, ma lo sono indirettamente tramite la tabella Dettagli
sugli ordini. La relazione molti-a-molti tra ordini e prodotti rappresentata nel database
utilizzando due relazioni uno-a-molti:
Tra la tabella Ordini e la tabella Dettagli sugli ordini presente una relazione
uno-a-molti. A ogni ordine pu corrispondere pi di una voce, ma ognuna collegata a
un solo ordine.
Tra la tabella Prodotti e la tabella Dettagli sugli ordini presente una relazione
uno-a-molti. A ogni prodotto possono essere associate molte voci, ma ogni voce si
riferisce a un solo prodotto.
Dalla tabella Dettagli sugli ordini possibile determinare tutti i prodotti inclusi in
un ordine particolare e determinare inoltre tutti gli ordini per un particolare prodotto.
Dopo avere incorporato la tabella Dettagli sugli ordini, l'elenco delle tabelle e dei
campi potrebbe avere un aspetto analogo al seguente:

Creazione di una relazione uno-a-uno

Un altro tipo di relazione disponibile la relazione uno-a-uno. Si supponga, ad
esempio, di avere l'esigenza di registrare speciali informazioni supplementari sui
prodotti, che saranno utilizzate raramente o applicabili solo a pochi prodotti. Poich tali
informazioni sono raramente necessarie e poich la loro archiviazione nella tabella
Prodotti comporterebbe la presenta di spazio vuoto per ogni prodotto a cui tali
informazioni non sono applicabili, si utilizzer una tabella distinta. In modo analogo alla
tabella Prodotti, verr utilizzato IDProdotto come chiave primaria. La relazione tra
questa tabella supplementare e la tabella Prodotto costituisce una relazione uno-a-uno.
Per ogni record nella tabella Prodotto presente un unico record corrispondente nella
tabella supplementare. Quando si identifica tale relazione, entrambe le tabelle devono
condividere un campo comune.
Quando si rileva l'esigenza di impostare una relazione uno-a-uno nel database,
verificare che sia possibile inserire le informazioni dalle due tabelle in una sola. Se non
si desidera effettuare questa operazione per qualsiasi motivo, ad esempio perch
rimarrebbe parecchio spazio vuoto, nell'elenco seguente illustrato come verrebbe
rappresentata la relazione nella progettazione:
Se le due tabelle condividono lo stesso argomento, probabilmente possibile
impostare la relazione utilizzando la stessa chiave primaria in entrambe le tabelle.

Se le due tabelle includono argomenti diversi con chiavi primarie diverse,

scegliere una delle due tabelle (una qualsiasi) e inserire la relativa chiave primaria
nell'altra tabella come chiave esterna.
La capacit di determinare le relazioni tra tabelle assicura che vengano utilizzata
le tabelle e le colonne corrette. Quando presente una relazione uno-a-uno o uno-amolti, le tabelle interessate devono condividere una colonna o pi colonne comuni.
Quando presente una relazione molti-a-molti, per rappresentare la relazione
necessaria una terza tabella.
Ottimizzazione della progettazione
Dopo avere definito le tabelle, i campi e le relazioni necessari, consigliabile
creare e popolare le tabelle con dati di esempio e provare a utilizzare tali informazioni,
creando query, aggiungendo nuovi record e cos via. In questo modo possibile
evidenziare i potenziali problemi, ad esempio, potrebbe essere necessario aggiungere
una colonna che si dimenticato di inserire durante la fase di progettazione oppure
dividere una tabella per rimuovere la duplicazione.
Verificare se possibile utilizzare il database per ottenere le risposte desiderate.
Creare bozze di maschere e report e verificare se vengono visualizzati i dati previsti.
Cercare le eventuali inutili duplicazioni dei dati e, se vengono trovate, modificare la
progettazione per eliminarle.
Mentre si prova a utilizzare il database iniziale, si scopriranno con tutta
probabilit aree soggette a miglioramento. Di seguito sono elencati alcuni aspetti da
verificare:
Verificare se sono state dimenticate colonne. In tal caso controllare se le
informazioni sono presenti nelle tabelle esistenti. Se si tratta di informazioni relative ad
altri argomenti, potrebbe essere necessario creare un'altra tabella. Creare una colonna
per ogni elemento di informazioni di cui necessario tenere traccia. Se non possibile
calcolare le informazioni da altre colonne, probabile che sia necessario creare una
nuova colonna a tale scopo.
Stabilire se sono presenti colonne non necessarie, poich possono essere calcolate
da campi esistenti. Se un elemento di informazioni pu essere calcolato da altre colonne
esistenti, ad esempio un prezzo scontato calcolato dal prezzo al dettaglio, in genere
preferibile procedere in tal modo, evitando di creare nuove colonne.
Verificare se vengono immesse ripetutamente informazioni duplicate in una delle
tabelle. In tal caso probabilmente necessario dividere la tabella in due tabelle con una
relazione uno-a-molti.
Verificare se nelle tabelle sono presenti molti campi, un numero limitato di record
e molti campi vuoti nei singoli record. In tal caso, considerare la possibilit di
riprogettare la tabella in modo che contenga meno campi e record.
Verificare se ogni elemento di informazioni stato suddiviso in parti utili pi

piccole. Se necessario creare report oppure applicare criteri di ordinamento o eseguire

ricerche o calcoli su un elemento di informazioni, inserire tale elemento in una colonna
corrispondente.
Verificare se ogni colonna contiene dati relativi all'argomento della tabella. Se
una colonna non contiene informazioni sull'argomento di una tabella, appartiene a una
tabella diversa.
Verificare che tutte le relazioni tra tabelle siano rappresentate da campi comuni o
da una terza tabella. Le relazioni uno-a-uno e uno-a-molti- richiedono colonne comuni.
Le relazioni molti a molti richiedono una terza tabella.
Ottimizzazione della tabella Prodotti
Si supponga che ogni prodotto nel database relativo alle vendite di prodotti rientri
in una categoria generale, ad esempio Bevande, Condimenti o Pesce. Nella tabella
Prodotti possibile inserire un campo che visualizzi la categoria per ogni prodotto.
Si supponga che dopo avere esaminato e ottimizzato la progettazione del database
si decida si archiviare una descrizione della categoria insieme al relativo nome. Se si
aggiunge un campo Descrizione categoria alla tabella Prodotti, sar necessario ripetere
ogni descrizione di categoria per ogni prodotto che rientra in tale categoria, una
soluzione non certo ottimale.
Una soluzione migliore consiste nell'impostare Categorie come nuovo argomento
di cui tenere traccia nel database, con una tabella e una chiave primaria personalizzate.
Sar quindi possibile aggiungere la chiave primaria dalla tabella Categorie alla tabella
Prodotti come chiave esterna.
Le tabelle Categorie e Prodotti sono collegate mediante una relazione uno-a-molti,
infatti una categoria pu includere pi prodotti, ma un prodotto pu appartenere a una
sola categoria.
Quando si esaminano le strutture delle tabelle, prestare attenzione agli eventuali
gruppi ripetuti. Si consideri ad esempio una tabella contenente le colonne seguenti:
o ID prodotto
o Nome
o ID Prodotto1
o Nome1
o ID prodotto2
o Nome2
o ID prodotto3
o Nome3
Ogni prodotto un gruppo ripetuto di colonne che differiscono dalle altre solo
aggiungendo un numero alla fine del nome della colonna. Se si osservano colonne con
questa numerazione, consigliabile rivedere la progettazione.
Tale progettazione presenta diversi difetti. Innanzitutto, impone la definizione di

un limite massimo al numero di prodotti e, quando si supera tale limite, diventa

necessario aggiungere un nuovo gruppo di colonne alla struttura della tabella e ci
implica un'attivit amministrativa importante.
Un altro problema dovuto al fatto che per i fornitori con un una quantit di
prodotti inferiore al numero massimo viene sprecato spazio, in quanto le colonne
aggiuntive saranno vuote. Il difetto pi grave di tale progettazione che rende difficile
l'esecuzione di molte attivit, ad esempio l'ordinamento o l'indicizzazione della tabella
per ID prodotto o per nome.
Ogni volta che si rilevano gruppi ripetuti, consigliabile rivedere attentamente la
progettazione considerando la possibilit di dividere la tabella in due. Nell'esempio
precedente preferibile utilizzare due tabelle, una per i fornitori e una per i prodotti,
collegate mediante l'ID fornitore.
Applicazione delle regole di normalizzazione
Come passaggio successivo del processo di progettazione, possibile applicare
regole di normalizzazione dei dati, dette a volte semplicemente regole di
normalizzazione, che consentono di verificare se le tabelle sono strutturate
correttamente. Il processo di applicazione delle regole alla progettazione del database
detto normalizzazione del database o solo normalizzazione.
La normalizzazione risulta utile soprattutto dopo che sono stati rappresentati tutti
gli elementi di informazioni e avere creato la progettazione preliminare. Consente di
verificare che gli elementi di informazioni siano stati suddivisi nelle tabelle appropriate,
ma non pu invece assicurare che siano stati inseriti tutti gli elementi di dati corretti con
cui iniziare.
Applicare le regole in successione, verificando a ogni passaggio che la
progettazione raggiunga una di quelle che vengono definite "forme normali". In genere
vengono ampiamente accettate cinque forme normali, dalla prima alla quinta. In questo
articolo vengono considerate solo le prime tre, in quanto rappresentano i requisiti
necessari per la maggior parte delle progettazioni di database.
Prima forma normale
La prima forma normale specifica che a ogni intersezione di riga e colonna nella
tabelle presente un singolo valore e mai un elenco di valori. Ad esempio non
possibile avere un campo denominato Prezzo con cui siano presenti pi prezzi. Se si
considera ogni intersezione di riga e colonna come una cella, ogni cella pu contenere
un solo valore.
Seconda forma normale

La seconda forma normale richiede che ogni colonna non chiave sia
completamente dipendente dall'intera chiave primaria e non solo da una parte di tale
chiave. Questa regola viene applicata quando si dispone di una chiave primaria
composta da pi di una colonna. Si supponga ad esempio di avere una tabella contenente
le colonne seguenti, dove ID ordine o ID prodotto costituisce la chiave primaria:
o ID ordine (chiave primaria)
o ID prodotto (chiave primaria)
o Nome prodotto
Questa progettazione viola la seconda forma normale, in quanto Nome prodotto
dipendente da ID prodotto ma non da ID ordine, quindi non dipendente dall'intera
chiave primaria. necessario rimuovere Nome prodotto dalla tabella, in quanto
appartiene a un'altra tabella (Prodotti).
Terza forma normale
La terza forma normale richiede non solo che ogni colonna non chiave sia
dipendente dall'intera chiave primaria, ma che le colonne non chiave siano indipendenti
le une dalle altre.
In altre parole, ogni colonna non chiave deve essere dipendente dalla chiave
primaria ed esclusivamente dalla chiave primaria. Si supponga ad esempio di avere una
tabella che contiene le colonne seguenti:
o IDProdotto (chiave primaria)
o Nome
o PDC
o Sconto
Si supponga che la colonna Sconto dipenda dal prezzo al dettaglio consigliato
(PDC). Questa tabella viola la terza forma normale poich una colonna non chiave,
Sconto, dipende da un'altra colonna non chiave, PDC. Indipendenza delle colonne
significa che deve essere possibile modificare qualsiasi colonna non chiave senza
influire su qualsiasi altra colonna. Se si modifica un valore nel campo PDC, il valore di
Sconto verrebbe modificato di conseguenza, violando in tal modo la regola. In questo
caso necessario spostare la colonna Sconto in un'altra tabella la cui chiave primaria
basata sulla colonna PDC.
PER SCARICARE UNA PRESENTAZIONE POWERPOINT DELLA PROF.SSA
ROSALBA GIUGNO

PRESENTAZIONE POWERPOINT DELLA PROF.SSA ROSALBA

GIUGNO: PROGETTAZIONE DI UNA BASE DI DATI.PDF
LA PROGETTAZIONE DI UNA BASE DI DATI

ALCUNI CONSIGLI DAL SITO HTML.IT

Progettare un database per MySQL, trucchi e scorciatoie - DAL SITO

html.it BY CLAUDIO GARAU
Non esistono soluzioni valide universalmente per la progettazione di un database,
lorganizzazione di una banca dati infatti una procedura dipendente dal tipo di
applicazione che si desidera realizzare. Vi sono delle semplici regole che possibile
seguire al fine di strutturare basi di dati che consentano di archiviare e manipolare dati in
modo semplice ed efficiente.
Nella progettazione di un database fondamentale tenere presente alcune
caratteristiche basilari:
o il numero delle tabelle che verranno coinvolte dalle interrogazioni lanciate
tramite le applicazioni;
o il numero e il tipo di campi che verranno da creare allinterno delle tabelle;
o le relazioni interne ed esterne tra i campi.
Le relazioni sono il punto saliente della fase di progettazione, maggiore sar il
numero di relazioni che si sar in grado di stabilire, pi efficiente sar la struttura del
database, pi breve sar il codice da digitare per le applicazioni e inferiore sar
lesigenza di generare nuovi campi o di memorizzare pi volte gli stesso dati.
La logica della progettazione
Progettare un database, in particolare nel caso dei database relazioni come
quelli gestiti da un DBMS MySQL, significa definirne la struttura, le caratteristiche e i
contenuti gestiti cercando di prevedere quelle che saranno le esigenze dellapplicazione
che avr accesso ai dati; gi da questa prima affermazione possibile introdurre una
regola di valore generale: buona norma progettare il database prima dellapplicazione e
non il contrario, la motivazione di questa affermazione semplice: lapplicazione andr
a gestire i dati contenuti nella base di dati, quindi, migliore sar la struttura della banca
dati pi efficiente sar lapplicazione.
In pratica, progettare un database consiste nella costruzione di un modello di

realt, una base di dati non altro che un archivio a cui possibile inviare, attraverso un
DBMS, delle interrogazioni sotto forma di query; le query non sono altro che delle
domande, un database dotato di una struttura lineare sar in grado di rispondere in
modo semplice a domande semplici, a livello tecnico la possibilit di inviare semplici
domande ottenendo il massimo risultato significa creare applicazioni dotate di codici
meno complessi.
La fase di progettazione di un database non pu naturalmente prescindere dal tipo
di applicazione che si desidera realizzare, le applicazioni vengono scritte per degli scopi
(ad esempio: un database manager che gestisca i post di un sito Web), quindi anche i
database a cui esse si interfacciano dovranno perseguire gli stessi scopi (conservare i
dati relativi alle news); gli scopi per cui si progetta un database possono essere suddivisi
in due categorie:
1. scopi correlati ad esigenze operative: archiviare, mantenere e amministrare
informazioni su entit animate (individui accomunati da specifiche
caratteristiche), inanimate (oggetti, come dei prodotti) o astratte (ad
esempio i prezzi dei prodotti);
2. scopi correlati ad esigenze decisionali: le decisioni possono essere prese
esclusivamente sulla base delle informazioni disponibili, migliore sar la
struttura del database pi immediato sar laccesso alle informazioni.
La progettazione di una base di dati necessita generalmente di pi fasi la cui
finalit quella di generare un modello (o astrazione) in grado di fornire la
rappresentazione delle informazioni gestite e delle relazioni esistenti tra di esse.
Le fasi della progettazione
La progettazione di un database relazione si basa su un modello chiamato E\R
(Entit\Relazione), dove con il termine di entit si identificano delle persone, degli
oggetti (anche astratti) o eventi dotati di determinati attributi; gli attributi hanno il
compito di definire quelle che sono le propriet delle entit mentre le relazioni non sono
altro che le correlazioni esistenti tra le entit. In un modello di rappresentazione della
realt sotto forma di database, le entit saranno indicate da tabelle e gli attributi da
campi, i record (cio le informazioni gestite) consentiranno di stabilire le relazioni
esistenti sulla base di valori.
Con la prima fase della progettazione di un database secondo il modello E\R, si ha
la cosiddetta analisi dei requisiti, i requisiti possono essere distinti in quattro
categorie:
1. analisi delle caratteristiche dei dati;
2. analisi delle operazioni da effettuare sui dati;
3. analisi degli eventi che possono influenzare i dati;
4. analisi dei vincoli dintegrit, cio delle propriet relative a informazioni ed

eventi.
Alla fase descritta deve seguire quella pi attinente al modello E\R che consiste
nellelaborazione di una struttura che sia in grado di fornire una rappresentazione della
realt di cui il database sar modello; le informazioni relative ai dati, alle entit, ai loro
attributi e agli eventi che le coinvolgono saranno gi state raccolte nella fase precedente,
la seconda fase impone di porre in relazione quanto analizzato.
A questo punto sar possibile passare alla fase in cui sar cio necessario definire
quali tabelle dovranno essere create, quali relazioni dovranno sussistere tra di esse e
internamente ad esse e a quali vincoli saranno sottoposte le relazioni.
Fatto questo, si passer alla fase della realizzazione del database attraverso il
DBMS, i comandi inviati durante questa fase dipenderanno fondamentalmente dalle
decisioni prese durante le fasi precedenti.
Lunico modo possibile per mettere in relazione delle entit differenti quello
di stabilire la presenza in essi di specifici elementi, si ha cos un riferimento a quelle che
sono le regole di integrit che sanciscono lobbligo di prevedere elementi comuni in
entit distinte; si pensi per esempio al Campionato di Calcio di Seria A, tutti i giocatori
che vi partecipano sono calciatori di prima divisione, per possibile suddividerli in
gruppi sulla base di una relazione dovuta alla squadra di appartenenza.
Inoltre, sempre secondo le regole di integrit, deve essere possibile laccesso ai
dati senza ambiguit, quindi ogni singolo valore deve essere indirizzabile specificando
il nome della relativa tabella, della colonna e della chiave primaria del record
corrispondente; una chiave primaria non altro che lattributo di unentit, in grado di
identificare in modo univoco un elemento appartenete allentit stessa. La targa
attribuita ad un veicolo dalla motorizzazione civile per esempio un identificativo
univoco grazie al quale distinguere unauto dal resto del parco macchine nazionale.
Esempio pratico di progettazione basata sul modello relazione
Fondamentalmente il modello E\R prevede tre tipi di relazioni:
1. uno ad uno: ad esempio il codice fiscale che identifica univocamente un
cittadino rispetto allAgenzia delle Entrate;
2. uno a molti: una stessa azienda emette pi fatture per diversi clienti;
3. molti a molti: il calendario di un campionato di Calcio prevede che tutte le
squadre giochino tra di loro.
Un possibile esempio di relazioni tra entit quello della costruzione di un
database per gestire i prestiti in una biblioteca, lanalisi dei requisiti far emergere
lesigenza di creare un sistema che permetta la gestione di entit (libri, iscritti e prestiti)
sulla base di eventi; il riferimento al modello E\R consentir di stabilire una struttura in
cui per i diversi libri posseduti sia definibile una relazione interna (tutti i libri in prestito
sono in relazione cos come lo sono quelli ancora disponibili) ed esterna (quella tra i
libri e gli iscritti che li hanno presi in prestito o restituiti).

La prima tabella da creare sar quindi quella relativa ai libri posseduti:

id_libro

Titolo

autore

stato

1
2

Lamore del bandito Massimo Carlotto

Il lupo e il filosofo
Mark Rowlands

Buono
Ottimo

Lidentificativo univoco quindi quello relativo al valore del campo id_libro che non
potr essere ripetuto, ma allinterno della tabella esistono anche altre relazioni: sar
possibile ricercare i libri relativi ad un determinato autore cos come tutti quelli che sono
conservati nello stesso stato.
Si passi ora alla tabella degli iscritti:
id_iscritto
1

nome
Giuseppe

cognome
Garibaldi

indirizzo
Via Teano

Linus

Torvalds

Via Kernel

email
g.garibaldi@imill
e.it
tor@valds.it

Anche in questo caso i record relativi agli iscritti potranno essere distinti in modo
univoco grazie al relativo identificativo, in questo modo sar possibile evitare ambiguit
dovute ad eventuali omonimie.
Si passi ora alla tabella relativa ai prestiti e alle restituzioni:
id_prestito Id_libro
1
2

2
1

id_iscritto data_prestit
o
2
2009-09-08
1
2009-09-05

data_restituzion
e
2009-09-28
2009-09-25

reso
0
1

Essa permette di mettere in relazione i diversi libri con gli iscritti che li hanno presi in
prestito, consente quindi di stabilire una relazione tra i record presenti nella tabella dei
libri con quelli della tabella degli iscritti; inoltre essa consente di stabilire delle relazioni
interne, sar infatti possibile selezionare e contare:
o tutti i libri prestati ad un determinato iscritto;
o tutti gli iscritti che hanno preso in prestito un determinato libro o soltanto
quelli che lo hanno restituito o solo quelli che non lo hanno ancora
riportato;
o tutti i libri prestati o restituiti in una determinata data;
o tutti i libri in prestito cos come quelli disponibili.

Quelli proposti sono soltanto alcuni esempi di relazioni concepibili nella

progettazione di un database, la struttura di una banca dati pu naturalmente essere
implementata o semplificata sulla base dellapplicazione che si desidera realizzare.
Conclusioni
La progettazione di un database non di per s una procedura particolarmente
complessa, ma pu variare molto a seconda dei progetti del programmatore e delle
esigenze del software che si dovr interfacciare al DBMS per la manipolazione dei dati;
in questa breve trattazione sono state esposte alcune regole di base per realizzare una
banca dati con attenzione a quelle che sono le indicazioni del modello relazionale.
QUI TROVATE DEGLI ESERCIZI SVOLTI DA SCARICARE

Esercizi progettazione 1 - Esercizi progettazione.pdf

ESERCIZI DAL SITO HOME.DEIB.POLIMI.IT

Esercizi progettazione 2 - EserciziEA.pdf

ESERCIZI DAL SITO DI.UNITO.IT

PER APPROFONDIRE IN INGLESE DAL SITO MICROSOFT

Database design basics - Access

A properly designed database provides you with access to up-to-date, accurate
information. Because a correct design is essential to achieving your goals in working
with a database, investing the time required to learn the principles of good design makes
sense. In the end, you are much more likely to end up with a database that meets your
needs and can easily accommodate change.
This article provides guidelines for planning a database. You will learn how to
decide what information you need, how to divide that information into the appropriate

tables and columns, and how those tables relate to each other. You should read this
article before you create your first database.
Some database terms to know
Microsoft Office Access 2007 organizes your information into tables: lists of
rows and columns reminiscent of an accountants pad or a Microsoft Office Excel 2007
worksheet. In a simple database, you might have only one table. For most databases you
will need more than one. For example, you might have a table that stores information
about products, another table that stores information about orders, and another table with
information about customers.

Each row is also called a record, and each column, is also called a field. A record
is a meaningful and consistent way to combine information about something. A field is a
single item of information an item type that appears in every record. In the Products
table, for instance, each row or record would hold information about one product. Each
column or field holds some type of information about that product, such as its name or
price.
What is good database design?
Certain principles guide the database design process. The first principle is that
duplicate information (also called redundant data) is bad, because it wastes space and
increases the likelihood of errors and inconsistencies. The second principle is that the
correctness and completeness of information is important. If your database contains
incorrect information, any reports that pull information from the database will also

contain incorrect information. As a result, any decisions you make that are based on
those reports will then be misinformed.
A good database design is, therefore, one that:
Divides your information into subject-based tables to reduce redundant data.
Provides Access with the information it requires to join the information in the
tables together as needed.
Helps support and ensure the accuracy and integrity of your information.
Accommodates your data processing and reporting needs.
The design process
The design process consists of the following steps:
Determine the purpose of your database This helps prepare you for the
remaining steps.
Find and organize the information required Gather all of the types of
information you might want to record in the database, such as product name and order
number.
Divide the information into tables Divide your information items into major
entities or subjects, such as Products or Orders. Each subject then becomes a table.
Turn information items into columns Decide what information you want to
store in each table. Each item becomes a field, and is displayed as a column in the table.
For example, an Employees table might include fields such as Last Name and Hire Date.
Specify primary keys Choose each tables primary key. The primary key is a
column that is used to uniquely identify each row. An example might be Product ID or
Order ID.
Set up the table relationships Look at each table and decide how the data in one
table is related to the data in other tables. Add fields to tables or create new tables to
clarify the relationships, as necessary.
Refine your design Analyze your design for errors. Create the tables and add a
few records of sample data. See if you can get the results you want from your tables.
Make adjustments to the design, as needed.
Apply the normalization rules Apply the data normalization rules to see if your
tables are structured correctly. Make adjustments to the tables, as needed.
Determining the purpose of your database
It is a good idea to write down the purpose of the database on paper its
purpose, how you expect to use it, and who will use it. For a small database for a home
based business, for example, you might write something simple like "The customer
database keeps a list of customer information for the purpose of producing mailings and
reports." If the database is more complex or is used by many people, as often occurs in a

corporate setting, the purpose could easily be a paragraph or more and should include
when and how each person will use the database. The idea is to have a well developed
mission statement that can be referred to throughout the design process. Having such a
statement helps you focus on your goals when you make decisions.
Finding and organizing the required information
To find and organize the information required, start with your existing
information. For example, you might record purchase orders in a ledger or keep
customer information on paper forms in a file cabinet. Gather those documents and list
each type of information shown (for example, each box that you fill in on a form). If you
don't have any existing forms, imagine instead that you have to design a form to record
the customer information. What information would you put on the form? What fill-in
boxes would you create? Identify and list each of these items. For example, suppose you
currently keep the customer list on index cards. Examining these cards might show that
each card holds a customers name, address, city, state, postal code and telephone
number. Each of these items represents a potential column in a table.
As you prepare this list, dont worry about getting it perfect at first. Instead, list
each item that comes to mind. If someone else will be using the database, ask for their
ideas, too. You can fine-tune the list later.
Next, consider the types of reports or mailings you might want to produce from
the database. For instance, you might want a product sales report to show sales by
region, or an inventory summary report that shows product inventory levels. You might
also want to generate form letters to send to customers that announces a sale event or
offers a premium. Design the report in your mind, and imagine what it would look like.
What information would you place on the report? List each item. Do the same for the
form letter and for any other report you anticipate creating.

Giving thought to the reports and mailings you might want to create helps you
identify items you will need in your database. For example, suppose you give customers

the opportunity to opt in to (or out of) periodic e-mail updates, and you want to print a
listing of those who have opted in. To record that information, you add a Send e-mail
column to the customer table. For each customer, you can set the field to Yes or No.
The requirement to send e-mail messages to customers suggests another item to
record. Once you know that a customer wants to receive e-mail messages, you will also
need to know the e-mail address to which to send them. Therefore you need to record an
e-mail address for each customer.
It makes good sense to construct a prototype of each report or output listing and
consider what items you will need to produce the report. For instance, when you
examine a form letter, a few things might come to mind. If you want to include a proper
salutation for example, the "Mr.", "Mrs." or "Ms." string that starts a greeting, you
will have to create a salutation item. Also, you might typically start a letter with Dear
Mr. Smith, rather than Dear. Mr. Sylvester Smith. This suggests you would typically
want to store the last name separate from the first name.
A key point to remember is that you should break each piece of information into
its smallest useful parts. In the case of a name, to make the last name readily available,
you will break the name into two parts First Name and Last Name. To sort a report by
last name, for example, it helps to have the customer's last name stored separately. In
general, if you want to sort, search, calculate, or report based on an item of information,
you should put that item in its own field.
Think about the questions you might want the database to answer. For instance,
how many sales of your featured product did you close last month? Where do your best
customers live? Who is the supplier for your best-selling product? Anticipating these
questions helps you zero in on additional items to record.
After gathering this information, you are ready for the next step.
Dividing the information into tables
To divide the information into tables, choose the major entities, or subjects. For
example, after finding and organizing information for a product sales database, the
preliminary list might look like this:

The major entities shown here are the products, the suppliers, the customers, and
the orders. Therefore, it makes sense to start out with these four tables: one for facts
about products, one for facts about suppliers, one for facts about customers, and one for
facts about orders. Although this doesnt complete the list, it is a good starting point.
You can continue to refine this list until you have a design that works well.
When you first review the preliminary list of items, you might be tempted to place
them all in a single table, instead of the four shown in the preceding illustration. You
will learn here why that is a bad idea. Consider for a moment, the table shown here:

In this case, each row contains information about both the product and its supplier.
Because you can have many products from the same supplier, the supplier name and
address information has to be repeated many times. This wastes disk space. Recording
the supplier information only once in a separate Suppliers table, and then linking that
table to the Products table, is a much better solution.
A second problem with this design comes about when you need to modify
information about the supplier. For example, suppose you need to change a supplier's
address. Because it appears in many places, you might accidentally change the address
in one place but forget to change it in the others. Recording the suppliers address in
only one place solves the problem.
When you design your database, always try to record each fact just once. If you
find yourself repeating the same information in more than one place, such as the address
for a particular supplier, place that information in a separate table.
Finally, suppose there is only one product supplied by Coho Winery, and you want
to delete the product, but retain the supplier name and address information. How would

you delete the product record without also losing the supplier information? You can't.
Because each record contains facts about a product, as well as facts about a supplier, you
cannot delete one without deleting the other. To keep these facts separate, you must split
the one table into two: one table for product information, and another table for supplier
information. Deleting a product record should delete only the facts about the product,
not the facts about the supplier.
Once you have chosen the subject that is represented by a table, columns in that
table should store facts only about the subject. For instance, the product table should
store facts only about products. Because the supplier address is a fact about the supplier,
and not a fact about the product, it belongs in the supplier table.
Turning information items into columns
To determine the columns in a table, decide what information you need to track
about the subject recorded in the table. For example, for the Customers table, Name,
Address, City-State-Zip, Send e-mail, Salutation and E-mail address comprise a good
starting list of columns. Each record in the table contains the same set of columns, so
you can store Name, Address, City-State-Zip, Send e-mail, Salutation and E-mail
address information for each record. For example, the address column contains
customers addresses. Each record contains data about one customer, and the address
field contains the address for that customer.
Once you have determined the initial set of columns for each table, you can
further refine the columns. For example, it makes sense to store the customer name as
two separate columns: first name and last name, so that you can sort, search, and index
on just those columns. Similarly, the address actually consists of five separate
components, address, city, state, postal code, and country/region, and it also makes sense
to store them in separate columns. If you want to perform a search, filter or sort
operation by state, for example, you need the state information stored in a separate
column.
You should also consider whether the database will hold information that is of
domestic origin only, or international, as well. For instance, if you plan to store
international addresses, it is better to have a Region column instead of State, because
such a column can accommodate both domestic states and the regions of other
countries/regions. Similarly, Postal Code makes more sense than Zip Code if you are
going to store international addresses.
The following list shows a few tips for determining your columns.
Dont include calculated data In most cases, you should not store the result of
calculations in tables. Instead, you can have Access perform the calculations when you
want to see the result. For example, suppose there is a Products On Order report that
displays the subtotal of units on order for each category of product in the database.
However, there is no Units On Order subtotal column in any table. Instead, the Products

table includes a Units On Order column that stores the units on order for each product.
Using that data, Access calculates the subtotal each time you print the report. The
subtotal itself should not be stored in a table.
Store information in its smallest logical parts You may be tempted to have a
single field for full names, or for product names along with product descriptions. If you
combine more than one kind of information in a field, it is difficult to retrieve individual
facts later. Try to break down information into logical parts; for example, create separate
fields for first and last name, or for product name, category, and description.

Once you have refined the data columns in each table, you are ready to choose
each table's primary key.
Specifying primary keys
Each table should include a column or set of columns that uniquely identifies each
row stored in the table. This is often a unique identification number, such as an
employee ID number or a serial number. In database terminology, this information is
called the primary key of the table. Access uses primary key fields to quickly associate
data from multiple tables and bring the data together for you.
If you already have a unique identifier for a table, such as a product number that
uniquely identifies each product in your catalog, you can use that identifier as the tables
primary key but only if the values in this column will always be different for each
record. You cannot have duplicate values in a primary key. For example, dont use
peoples names as a primary key, because names are not unique. You could easily have
two people with the same name in the same table.
A primary key must always have a value. If a column's value can become
unassigned or unknown (a missing value) at some point, it can't be used as a component

in a primary key.
You should always choose a primary key whose value will not change. In a
database that uses more than one table, a tables primary key can be used as a reference
in other tables. If the primary key changes, the change must also be applied everywhere
the key is referenced. Using a primary key that will not change reduces the chance that
the primary key might become out of sync with other tables that reference it.
Often, an arbitrary unique number is used as the primary key. For example, you
might assign each order a unique order number. The order number's only purpose is to
identify an order. Once assigned, it never changes.
If you dont have in mind a column or set of columns that might make a good
primary key, consider using a column that has the AutoNumber data type. When you use
the AutoNumber data type, Access automatically assigns a value for you. Such an
identifier is factless; it contains no factual information describing the row that it
represents. Factless identifiers are ideal for use as a primary key because they do not
change. A primary key that contains facts about a row a telephone number or a
customer name, for example is more likely to change, because the factual information
itself might change.

1. A column set to the AutoNumber data type often makes a good primary key. No
two product IDs are the same.
In some cases, you may want to use two or more fields that, together, provide the
primary key of a table. For example, an Order Details table that stores line items for
orders would use two columns in its primary key: Order ID and Product ID. When a
primary key employs more than one column, it is also called a composite key.
For the product sales database, you can create an AutoNumber column for each of
the tables to serve as primary key: ProductID for the Products table, OrderID for the
Orders table, CustomerID for the Customers table, and SupplierID for the Suppliers
table.

Creating the table relationships

Now that you have divided your information into tables, you need a way to bring
the information together again in meaningful ways. For example, the following form
includes information from several tables.

1. Information in this form comes from the Customers table...

2. ...the Employees table...

3. ...the Orders table...

4. ...the Products table...
5. ...and the Order Details table.
Access is a relational database management system. In a relational database, you
divide your information into separate, subject-based tables. You then use table
relationships to bring the information together as needed.
Creating a one-to-many relationship
Consider this example: the Suppliers and Products tables in the product orders
database. A supplier can supply any number of products. It follows that for any supplier
represented in the Suppliers table, there can be many products represented in the
Products table. The relationship between the Suppliers table and the Products table is,
therefore, a one-to-many relationship.

To represent a one-to-many relationship in your database design, take the primary

key on the "one" side of the relationship and add it as an additional column or columns
to the table on the "many" side of the relationship. In this case, for example, you add the
Supplier ID column from the Suppliers table to the Products table. Access can then use
the supplier ID number in the Products table to locate the correct supplier for each
product.
The Supplier ID column in the Products table is called a foreign key. A foreign
key is another tables primary key. The Supplier ID column in the Products table is a
foreign key because it is also the primary key in the Suppliers table.

You provide the basis for joining related tables by establishing pairings of primary
keys and foreign keys. If you are not sure which tables should share a common column,
identifying a one-to-many relationship ensures that the two tables involved will, indeed,
require a shared column.
Creating a many-to-many relationship
Consider the relationship between the Products table and Orders table.
A single order can include more than one product. On the other hand, a single
product can appear on many orders. Therefore, for each record in the Orders table, there
can be many records in the Products table. And for each record in the Products table,
there can be many records in the Orders table. This type of relationship is called a manyto-many relationship because for any product, there can be many orders; and for any
order, there can be many products. Note that to detect many-to-many relationships
between your tables, it is important that you consider both sides of the relationship.
The subjects of the two tables orders and products have a many-to-many
relationship. This presents a problem. To understand the problem, imagine what would
happen if you tried to create the relationship between the two tables by adding the
Product ID field to the Orders table. To have more than one product per order, you need
more than one record in the Orders table per order. You would be repeating order
information for each row that relates to a single order resulting in an inefficient
design that could lead to inaccurate data. You run into the same problem if you put the
Order ID field in the Products table you would have more than one record in the
Products table for each product. How do you solve this problem?
The answer is to create a third table, often called a junction table, that breaks
down the many-to-many relationship into two one-to-many relationships. You insert the

primary key from each of the two tables into the third table. As a result, the third table
records each occurrence or instance of the relationship.

Each record in the Order Details table represents one line item on an order. The
Order Details tables primary key consists of two fields the foreign keys from the
Orders and the Products tables. Using the Order ID field alone doesnt work as the
primary key for this table, because one order can have many line items. The Order ID is
repeated for each line item on an order, so the field doesnt contain unique values. Using
the Product ID field alone doesnt work either, because one product can appear on many
different orders. But together, the two fields always produce a unique value for each
record.
In the product sales database, the Orders table and the Products table are not
related to each other directly. Instead, they are related indirectly through the Order
Details table. The many-to-many relationship between orders and products is
represented in the database by using two one-to-many relationships:
The Orders table and Order Details table have a one-to-many relationship. Each
order can have more than one line item, but each line item is connected to only one
order.
The Products table and Order Details table have a one-to-many relationship. Each
product can have many line items associated with it, but each line item refers to only one
product.
From the Order Details table, you can determine all of the products on a particular
order. You can also determine all of the orders for a particular product.
After incorporating the Order Details table, the list of tables and fields might look
something like this:

Creating a one-to-one relationship

Another type of relationship is the one-to-one relationship. For instance, suppose
you need to record some special supplementary product information that you will need
rarely or that only applies to a few products. Because you don't need the information
often, and because storing the information in the Products table would result in empty
space for every product to which it doesnt apply, you place it in a separate table. Like
the Products table, you use the ProductID as the primary key. The relationship between
this supplemental table and the Product table is a one-to-one relationship. For each
record in the Product table, there exists a single matching record in the supplemental
table. When you do identify such a relationship, both tables must share a common field.
When you detect the need for a one-to-one relationship in your database, consider
whether you can put the information from the two tables together in one table. If you
dont want to do that for some reason, perhaps because it would result in a lot of empty
space, the following list shows how you would represent the relationship in your design:
If the two tables have the same subject, you can probably set up the relationship
by using the same primary key in both tables.
If the two tables have different subjects with different primary keys, choose one
of the tables (either one) and insert its primary key in the other table as a foreign key.
Determining the relationships between tables helps you ensure that you have the

right tables and columns. When a one-to-one or one-to-many relationship exists, the
tables involved need to share a common column or columns. When a many-to-many
relationship exists, a third table is needed to represent the relationship.
Refining the design
Once you have the tables, fields, and relationships you need, you should create
and populate your tables with sample data and try working with the information:
creating queries, adding new records, and so on. Doing this helps highlight potential
problems for example, you might need to add a column that you forgot to insert
during your design phase, or you may have a table that you should split into two tables
to remove duplication.
See if you can use the database to get the answers you want. Create rough drafts
of your forms and reports and see if they show the data you expect. Look for
unnecessary duplication of data and, when you find any, alter your design to eliminate it.
As you try out your initial database, you will probably discover room for
improvement. Here are a few things to check for:
Did you forget any columns? If so, does the information belong in the existing
tables? If it is information about something else, you may need to create another table.
Create a column for every information item you need to track. If the information cant
be calculated from other columns, it is likely that you will need a new column for it.
Are any columns unnecessary because they can be calculated from existing
fields? If an information item can be calculated from other existing columns a
discounted price calculated from the retail price, for example it is usually better to do
just that, and avoid creating new column.
Are you repeatedly entering duplicate information in one of your tables? If so,
you probably need to divide the table into two tables that have a one-to-many
relationship.
Do you have tables with many fields, a limited number of records, and many
empty fields in individual records? If so, think about redesigning the table so it has
fewer fields and more records.
Has each information item been broken into its smallest useful parts? If you need
to report, sort, search, or calculate on an item of information, put that item in its own
column.
Does each column contain a fact about the table's subject? If a column does not
contain information about the table's subject, it belongs in a different table.
Are all relationships between tables represented, either by common fields or by a
third table? One-to-one and one-to- many relationships require common columns.
Many-to-many relationships require a third table.
Refining the Products table

Suppose that each product in the product sales database falls under a general
category, such as beverages, condiments, or seafood. The Products table could include a
field that shows the category of each product.
Suppose that after examining and refining the design of the database, you decide
to store a description of the category along with its name. If you add a Category
Description field to the Products table, you have to repeat each category description for
each product that falls under the category this is not a good solution.
A better solution is to make Categories a new subject for the database to track,
with its own table and its own primary key. You can then add the primary key from the
Categories table to the Products table as a foreign key.
The Categories and Products tables have a one-to-many relationship: a category
can include more than one product, but a product can belong to only one category.
When you review your table structures, be on the lookout for repeating groups.
For example, consider a table containing the following columns:
o Product ID
o Name
o Product ID1
o Name1
o Product ID2
o Name2
o Product ID3
o Name3
Here, each product is a repeating group of columns that differs from the others
only by adding a number to the end of the column name. When you see columns
numbered this way, you should revisit your design.
Such a design has several flaws. For starters, it forces you to place an upper limit
on the number of products. As soon as you exceed that limit, you must add a new group
of columns to the table structure, which is a major administrative task.
Another problem is that those suppliers that have fewer than the maximum
number of products will waste some space, since the additional columns will be blank.
The most serious flaw with such a design is that it makes many tasks difficult to
perform, such as sorting or indexing the table by product ID or name.
Whenever you see repeating groups review the design closely with an eye on
splitting the table in two. In the above example it is better to use two tables, one for
suppliers and one for products, linked by supplier ID.
Applying the normalization rules
You can apply the data normalization rules (sometimes just called normalization
rules) as the next step in your design. You use these rules to see if your tables are

structured correctly. The process of applying the rules to your database design is called
normalizing the database, or just normalization.
Normalization is most useful after you have represented all of the information
items and have arrived at a preliminary design. The idea is to help you ensure that you
have divided your information items into the appropriate tables. What normalization
cannot do is ensure that you have all the correct data items to begin with.
You apply the rules in succession, at each step ensuring that your design arrives at
one of what is known as the "normal forms." Five normal forms are widely accepted
the first normal form through the fifth normal form. This article expands on the first
three, because they are all that is required for the majority of database designs.
First normal form
First normal form states that at every row and column intersection in the table
there, exists a single value, and never a list of values. For example, you cannot have a
field named Price in which you place more than one Price. If you think of each
intersection of rows and columns as a cell, each cell can hold only one value.
Second normal form
Second normal form requires that each non-key column be fully dependent on the
entire primary key, not on just part of the key. This rule applies when you have a primary
key that consists of more than one column. For example, suppose you have a table
containing the following columns, where Order ID and Product ID form the primary
key:
o Order ID (primary key)
o Product ID (primary key)
o Product Name
This design violates second normal form, because Product Name is dependent on
Product ID, but not on Order ID, so it is not dependent on the entire primary key. You
must remove Product Name from the table. It belongs in a different table (Products).
Third normal form
Third normal form requires that not only every non-key column be dependent on
the entire primary key, but that non-key columns be independent of each other.
Another way of saying this is that each non-key column must be dependent on the
primary key and nothing but the primary key. For example, suppose you have a table
containing the following columns:
o ProductID (primary key)
o Name
o SRP
o Discount

Assume that Discount depends on the suggested retail price (SRP). This table
violates third normal form because a non-key column, Discount, depends on another
non-key column, SRP. Column independence means that you should be able to change
any non-key column without affecting any other column. If you change a value in the
SRP field, the Discount would change accordingly, thus violating that rule. In this case
Discount should be moved to another table that is keyed on SRP.