NOZIONI PER LA PROGETTAZIONE DI UN DATABASE, ED ESEMPI.

Per Iniziare

Un database progettato correttamente consente di accedere a informazioni aggiornate e accurate. Le informazioni vengono organizzate da Microsoft Office Access 2007 in tabelle, ovvero elenchi di righe e colonne simili a un blocco per la contabilità o un foglio di lavoro di Microsoft Office Excel 2007. Un database semplice può includere una sola tabella. Nella maggior parte dei database sono necessarie più tabelle.
Si può ad esempio disporre di una tabella contenente informazioni sui Studenti, un'altra tabella contenente informazioni sull’ Università e un'altra tabella con informazioni sulle iscrizioni.
Ogni riga viene denominata record e ogni colonna viene denominata campo. Un record costituisce un modo significativo e coerente per combinare le informazioni su un determinato argomento. Un campo rappresenta un singolo elemento di informazioni, ovvero un tipo di elemento incluso in ogni record.
Nella tabella Studentii, ad esempio, ogni riga o record conterrà informazioni su un determinato Studente, mentre ogni colonna o campo includerà un tipo di informazioni sullo Studente, ad esempio il nome o la matricola ecc..

Progettazione appropriata

Il processo di progettazione di database è basato su determinati principi. Il primo è costituito dal fatto che la presenza di informazioni duplicate, denominate anche dati ridondanti, è negativa poiché causa uno spreco di spazio e aumenta le probabilità di errori e incoerenze. Il secondo principio è rappresentato dall'importanza della correttezza e della completezza delle informazioni. Se il database contiene informazioni non corrette, qualsiasi report che estrae informazioni dal database conterrà a propria volta informazioni non corrette. Di conseguenza, qualsiasi decisione a partire da tali report sarà basata su informazioni errate.
Una progettazione di database appropriata presenta pertanto le caratteristiche seguenti:

• Suddivide le informazioni in tabelle per argomento in modo da ridurre i dati ridondanti.
• Offre ad Access le informazioni necessarie per unire le informazioni delle tabelle in base alle esigenze.
• Supporta e garantisce l'accuratezza e l'integrità delle informazioni.
• Soddisfa le esigenze di elaborazione dei dati e creazione di report.
  

Processo di progettazione

Il processo di progettazione è costituito dai passaggi seguenti:

• Identificare lo scopo del database.
• Individuare e organizzare le informazioni necessarie. Raccogliere tutti i tipi di informazioni che si desidera registrare nel database, ad esempio il nome dello studente la matricola ecc..
• Suddividere le informazioni in tabelle. Suddividere gli elementi di informazioni in argomenti o entità principali, ad esempio Studenti, Università. A ogni argomento verrà quindi assegnata una tabella.
• Trasformare gli elementi di informazioni in colonne. Determinare le informazioni che si desidera memorizzare in ogni tabella. A ogni elemento viene assegnato un campo, visualizzato come una colonna della tabella. Una tabella Stundeti può ad esempio includere campi come Cognome e Data immatricolazione.
• Specificare chiavi primarie. Scegliere la chiave primaria di ogni tabella. La chiave primaria è la colonna utilizzata per identificare in modo univoco ogni riga, ad esempio Matricola studente o ID Università.
• Impostare le relazioni tra le tabelle. Esaminare ogni tabella e determinare la relazione tra i dati di una tabella e i dati di altre tabelle. Aggiungere campi alle tabelle o creare nuove tabelle per chiarire le relazioni, in base alle esigenze.
• Perfezionare la progettazione. Analizzare la progettazione per individuare eventuali errori. Creare le tabelle e aggiungere alcuni record di dati di esempio. Verificare se è possibile ottenere i risultati desiderati dalle tabelle. Apportare modifiche alla progettazione in base alle esigenze.
• Applicare le regole di normalizzazione. Applicare le regole di normalizzazione dei dati per verificare la corretta strutturazione delle tabelle. Apportare modifiche alle tabelle in base alle esigenze.

Perfezionamento della struttura

Quando si dispone delle tabelle, delle relazioni e dei campi necessari, è consigliabile creare e popolare le tabelle con dati di esempio e provare a utilizzare le informazioni creando query, aggiungendo nuovi record e così via. È così possibile evidenziare potenziali problemi. Può ad esempio essere necessario aggiungere una colonna che non è stata inserita durante la fase di progettazione oppure suddividere una tabella in due per rimuovere dati duplicati.
Controllare se è possibile utilizzare il database per ottenere le risposte desiderate. Creare bozze delle maschere e dei report e verificare se contengono i dati previsti. Cercare eventuali dati duplicati non necessari e, se presenti, modificare la progettazione in modo da eliminarli.
Quando si eseguono prove con il database iniziale, sarà possibile individuare margini di miglioramento. Di seguito sono elencati alcuni aspetti da verificare:

• Sono state omesse eventuali colonne? In caso affermativo, le informazioni appartengono alle tabelle esistenti? Se le informazioni riguardano un altro argomento, può essere necessario creare un'altra tabella. Creare una colonna per ogni informazione di cui si deve tenere traccia. Se le informazioni non possono essere calcolate da altre colonne, è probabilmente necessario aggiungere una nuova colonna.
• Sono presenti colonne non necessarie poiché calcolabili dai campi esistenti? Se un'informazione può essere calcolata da altre colonne esistenti, come nel caso di un prezzo scontato calcolato dal prezzo di listino, è in genere preferibile evitare di creare una nuova colonna.
• Si immettono ripetutamente informazioni duplicate in una delle tabelle? In questo caso, è probabilmente necessario suddividere la tabella in due tabelle con una relazione uno-a-molti.
• Sono presenti tabelle con molti campi, un numero limitato di record e numerosi campi vuoti nei singoli record? In questo caso, può essere opportuno riprogettare la tabella in modo da ridurre il numero di campi e aumentare il numero di record.
  
• Ogni informazione è stata suddivisa nelle sue unità significative più piccole? Se è necessario eseguire l'ordinamento, la ricerca, il calcolo o la creazione di report in base a un'informazione, inserire tale informazione in un'apposita colonna.
• Ogni colonna contiene un dato relativo all'argomento della tabella? Una colonna che non contiene informazioni sull'argomento della tabella appartiene a una tabella diversa.
  
• Sono rappresentate tutte le relazioni tra le tabelle, mediante campi comuni o una terza tabella? Le relazioni uno-a-uno e uno-a-molti necessitano di colonne comuni, mentre per le relazioni molti-a-molti è necessaria una terza tabella.

Applicazione delle regole di normalizzazione

Queste regole consentono di verificare la corretta strutturazione delle tabelle. Il processo di applicazione delle regole alla progettazione del database viene denominato normalizzazione del database o semplicemente normalizzazione.
La normalizzazione, maggiormente utile dopo che sono stati rappresentati tutti gli elementi di informazioni ed è stata definita una progettazione preliminare, è finalizzata a garantire che gli elementi di informazioni siano stati suddivisi nelle tabelle appropriate. La normalizzazione non può tuttavia garantire che si disponga di tutti gli elementi di dati corretti come punto di partenza.
Le regole vengono applicate in successione, verificando in ogni passaggio che la struttura raggiunga la cosiddetta "forma normale". Sono in genere accettate cinque forme normali, dalla prima forma normale fino alla quinta forma normale. Le prime tre, però sono considerate sufficienti per la maggior parte delle strutture di database.

1. Prima forma normale
Prevede che in corrispondenza di ogni intersezione di riga e colonna nella tabella sia presente un singolo valore e mai un elenco di valori. Non è ad esempio possibile disporre di un campo denominato Prezzo in cui vengono inseriti più prezzi. Considerando ogni intersezione di righe e colonne come una cella, ogni cella può contenere un solo valore.

2. Seconda forma normale
Richiede che ogni colonna non chiave dipenda completamente dall'intera chiave primaria, non soltanto da una parte della chiave. Questa regola è applicabile in caso di chiave primaria costituita da più colonne. Si supponga ad esempio di disporre di una tabella contenente le colonne seguenti, con ID ordine e ID prodotto come chiave primaria:
· ID ordine (chiave primaria)
· ID prodotto (chiave primaria)
· Nome prodotto
Questa progettazione viola la seconda forma normale, poiché Nome prodotto dipende da ID prodotto, ma non da ID ordine. Non dipende pertanto dall'intera chiave primaria. È necessario rimuovere Nome prodotto dalla tabella, poiché appartiene a una diversa tabella (Prodotti).

3. Terza forma normale
Richiede non solo che ogni colonna non chiave dipenda dall'intera chiave primaria, ma anche che le colonne non chiave siano reciprocamente indipendenti.
In altri termini, ogni colonna non chiave deve dipendere dalla chiave primaria ed esclusivamente da tale chiave. Si supponga ad esempio di disporre di una tabella contenente le colonne seguenti:
· ID prodotto (chiave primaria)
· Nome
· Prezzo consigliato
· Sconto
Se lo sconto dipende dal prezzo di listino consigliato, questa tabella viola la terza forma normale poiché la colonna non chiave Sconto dipende da un'altra colonna non chiave, Prezzo consigliato. L'indipendenza delle colonne garantisce la possibilità di modificare qualsiasi colonna non chiave senza influire su altre colonne. Se si modifica un valore nel campo Prezzo consigliato, lo sconto dovrà essere modificato di conseguenza violando così tale regola. In questo caso, lo sconto deve essere spostato in un'altra tabella con chiave basata sul prezzo di listino consigliato.

Analogie tra i concetti base di statistica e quelli informatici

Spreadsheet e DBMS

Spreadsheet in inglese significa foglio di calcolo, altrimenti detto foglio elettronico Il principio su cui si basa è semplice: fornire una tabella, detta anche foglio di lavoro, formata da celle in cui si possono inserire dati, numeri o formule. I fogli di calcolo automatizzati offrono un gran numero di funzionalità per il calcolo e la creazione di grafici per la visualizzazione e la modifica di dati tabulari. Possono inoltre essere utilizzati efficacemente per memorizzare elenchi di informazioni, attualmente il foglio di calcolo maggiormente utilizzato è Microsoft Excel.
Man mano che i requisiti degli elenchi crescono in complessità, può diventare difficile gestire i dati in un foglio di calcolo. Un'applicazione di database relazionale è più adatta alla creazione e all'utilizzo di elenchi complessi, si parla in questi casi di DBMS (database management system) è un sistema software progettato per consentire la creazione e manipolazione efficiente di collezioni di dati strutturati. I DBMS svolgono un ruolo fondamentale in numerose applicazioni informatiche, dalla contabilità, alla gestione delle risorse umane e alla finanza fino a contesti tecnici come la gestione di rete o la telefonia. Molto conosciuto Microsoft Access o anche Oracle. La progettazione del database (database design) è il processo decisionale su come organizzare i dati in possesso in tipi di record e su come ciascun tipo di record si relaziona con gli altri.
Analogie e differenze
Database e fogli di calcolo hanno molte analogie se prendiamo ad esempio le due più conosciute applicazioni, Excel e Access riscontriamo che entrambe consentono infatti di eseguire potenti query per ordinare e filtrare i dati, eseguire calcoli, utilizzare maschere per aggiungere, modificare, eliminare e consultare i dati con facilità, utilizzare visualizzazioni tabella pivot e grafico pivot per gestire i dati in modo interattivo, generare rapporti sui dati e visualizzarli in più formati, e ancora, importare dati da database esterni creare pagine web, infine entrambe le applicazioni organizzano i dati in colonne, dette anche campi, non ostate tutte queste somiglianze bisogna comunque tenere a mente che Excel rimane un foglio di calcolo mentre in un database i dati vengono memorizzati in tabelle molto simili ai fogli di lavoro, ma progettate per l'esecuzione di query complesse in relazione ai dati memorizzati in altre tabelle e posizioni, nonché in campi di altre tabelle.

Esempio di schema Entità/relazioni per la memorizzazione dei dati sulle immatricolazioni