Progettazione di basi di dati

Voce principale: Base di dati.

Questa voce o sezione sull'argomento informatica è ritenuta da controllare.

Motivo: Questa definizione della progettazione di basi di dati confonde il concetto di relazione con quello di associazione fra relazioni, ci sono molti refusi e non consente la comprensione del concetto di progettazione di database né delle modalità con cui tale processo si esplica. Deve essere riscritta completamente!

---

Partecipa alla discussione e/o correggi la voce. Segui i suggerimenti del progetto di riferimento.

Questa pagina sull'argomento informatica sembra trattare argomenti unificabili alle pagine Schema di database, Progettazione logica e Modello concettuale (informatica), che potrebbero confluire qui.

---

Puoi contribuire unendo i contenuti in una pagina unica. Commenta la procedura di unione usando questa pagina di discussione. Segui i suggerimenti del progetto di riferimento.

In informatica la progettazione di basi di dati è il processo di formulazione di un modello dettagliato del database. Questo modello contiene tutte le scelte progettuali a livello logico e fisico e i parametri fisici di memorizzazione necessari per la generazione del data definition language (DDL), che può essere usato per l'implementazione del database. Un modello dei dati completamente specificato contiene i dettagli specifici per ogni singola entità.

Il termine progettazione di basi di dati può essere usato per descrivere diverse parti della progettazione in un generico database management system (DBMS). Principalmente, e più correttamente, può essere pensato come la progettazione logica della struttura dati di base usata per memorizzare i dati. Nel modello relazionale queste strutture sono le tabelle e le viste. In una base di dati ad oggetti le entità e le relazioni sono mappate direttamente alle classi di oggetti e ai nomi delle relazioni. Tuttavia, il termine database potrebbe anche essere utilizzato per applicare il generico processo di progettazione, non solo le singole strutture dati di base, ma anche le schermate e interrogazioni usate come parte di una generica applicazione per database presente all'interno del DBMS.^[1]

Lo sviluppo del database generalmente consiste in un numero di passi effettuati dal progettista del database. Solitamente, esso deve:

• Definire i dati da memorizzare nel database
• Definire le relazioni tra i diversi elementi presenti tra i dati
• Sovrapporre una struttura logica sopra i dati sulla base delle relazioni precedentemente definite.^[2]

All'interno del modello relazionale l'ultimo passo di sopra può generalmente essere spezzato in due parti ulteriori, quella di definire il raggruppamento delle informazioni all'interno del sistema, generalmente definendo quali sono gli oggetti base su cui le informazioni sono memorizzate, e poi definire le relazioni tra questi gruppi di informazioni, o oggetti. Questo step non è necessario con un base di dati ad oggetti.^[1]

Nella maggioranza dei casi, chi progetta il database è una persona che possiede competenze in tale campo, piuttosto che competenze nel dominio applicativo dei dati da memorizzare. Ad esempio financial information, biological information ecc. Pertanto, i dati da memorizzare devono essere definiti in cooperazione con un esperto di dominio, che è consapevole di quali dati devono essere memorizzati nel nuovo sistema.

Questo processo è uno di quelli comunemente considerati parte dell'analisi dei requisiti, e richiede che il progettista abbia le competenze necessarie per sfruttare al meglio le conoscenze di dominio applicativo. Questo avviene perché spesso chi progetta il database non riesce esprimere con chiarezza quali sono i requisiti del sistema siccome non è abituato a pensare in termini dei dati che devono essere memorizzati. Tali dati possono essere rilevati tramite un'apposita specifica dei requisiti.^[3]

Una volta che il progettista è consapevole di quali dati memorizzare all'interno della base di dati, deve definire come i dati dipendono dagli altri. A volte quando i dati vengono cambiati possono essere modificati altri dati non visibili. Per esempio, in una lista di nomi e indirizzi (in realtà al posto del nome è necessario usare un attributo univoco come ad esempio il codice fiscale), assumendo una situazione dove più persone possono avere lo stesso indirizzo ma una persona non può avere più di un indirizzo. Quindi dato un nome, l'indirizzo è univocamente definito; tuttavia l'inverso non vale, dato un indirizzo non possiamo univocamente definire un nome perché più persone possono risiedere allo stesso indirizzo. Poiché l'attributo indirizzo è definito univocamente dall'attributo nome, abbiamo la dipendenza dall'attributo indirizzo dall'attributo nome. (NOTA: Il modello relazionale è chiamato così perché è basato sulla struttura matematica conosciuta come relazione).

Lo stesso argomento in dettaglio: Schema di database e Tablespace.

Una volta che le entità e le relazioni tra le diverse entità sono state definite, è possibile organizzare i dati in una struttura logica la quale può essere mappata negli oggetti memorizzati e supportati dal DBMS. Nel caso di un database relazionale gli oggetti memorizzati sono tabelle che immagazzinano i dati in righe e colonne. In un database ad oggetti, invece, gli oggetti memorizzati corrispondono direttamente agli oggetti usati dalla programmazione orientata agli oggetti per scrivere le applicazioni che vogliono gestire e accedere ai dati. Le relazioni possono essere definite come attributi delle classi ad oggetti coinvolte o come metodi che operano su tali classi.

Il modo in cui questa mappatura è generalmente fatta è tale che ogni insieme di dati correlati che dipende da un singolo oggetto, se reale o astratto, è collocato in una tabella. Le relazioni tra questi oggetti dipendenti è allora memorizzato come collegamento tra i vari oggetti.

Ogni tabella può rappresentare un'implementazione di un oggetto logico o una relazione di accoppiamento di una o più istanze di uno o più oggetti logici. Le relazioni tra le tabelle possono allora essere memorizzate come collegamenti tra le tabelle figlie e padre. Dato che le complesse relazioni logiche sono a loro volta delle tabelle, avranno probabilmente collegamenti a più di una tabella padre.

Lo stesso argomento in dettaglio: Modello E-R.

La progettazione di basi di dati include anche i diagrammi del Modello E-R. Un tale diagramma aiuta nella progettazione in modo efficiente.

Gli attributi in un diagramma ER sono di solito modellati come un ovale specificandone il nome, e collegati all'entità o relazione che contiene l'attributo.

1. Definire l'obiettivo del database - Questo aiuta a prepararsi per i passi successivi.
2. Trovare e organizzare le informazioni necessarie - Raccogliere tutti questi tipi di informazioni da registrare nel database, ad esempio il nome di un prodotto o il numero d'ordine.
3. Dividere le informazioni nelle tabelle - Dividere gli elementi informativi in entità principali oppure oggetti, ad esempio Prodotti o Ordini. Ogni oggetto allora diventa una tabella.
4. Trasformare gli elementi informativi nelle colonne della tabella - Decidere quale informazione è necessaria per essere memorizzata in ogni tabella. Per esempio, una tabella 'Impiegati' potrebbe includere campi come Cognome e Data di Assunzione.
5. Specificare le chiavi primarie - Scegliere la chiave primaria di ogni tabella. La chiave primaria è una colonna, o un loro insieme, che viene usata per identificare univocamente ogni riga. Un esempio potrebbe essere il codice prodotto o il codice dell'ordine.
6. Impostare le relazioni tra le tabelle - Guardare ogni tabella e decidere come i dati in essa sono correlati ai dati di un'altra tabella. Aggiungere campi alle tabelle o crearne di nuove per chiarire le relazioni, se ritenuto opportuno.
7. Affinare la progettazione - Analizzare la progettazione per eventuali errori. Creare le tabelle e aggiungerci un paio di record come esempio campione. Controllare se i risultati vengono dalle tabelle come previsto. Effettuare adattamenti alla progettazione, se necessario.
8. Applicare le regole di normalizzazione - Applicare tali regole ai dati per vedere se le tabelle sono strutturate il modo corretto. Effettuare adattamenti alle tabelle, se necessario.

Lo stesso argomento in dettaglio: Normalizzazione (informatica).

Nel progettazione di un database relazionale, la normalizzazione è un via sistematica di garantire che la struttura di un database sia adatta per scopi generici di interrogazione e sia libera da certe caratteristiche indesiderate — le anomalie da inserimento, aggiornamento, e cancellazione che potrebbero condurre alla perdita dell'Integrità dei dati.

Una regola standard della progettazione prevede che il progettista dovrebbe creare un progetto di base di dati pienamente normalizzato; in maniera selettiva la denormalizzazione può essere successivamente eseguita, ma solo per ragioni di performance. Tuttavia, molte discipline di modellazione, ad esempio il dimensional modeling usato nella progettazione di data warehouse, raccomanda esplicitamente di progettare in maniera non normalizzata, cioè progettazioni che in larga parte non sono conformi al 3NF. La Normalizzazione consiste in forme normali che sono 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF e 5NF.

Lo stesso argomento in dettaglio: Modello concettuale (informatica).

Il raffinamento dello schema di un database specifica che i dati vengano normalizzati per ridurne l'insufficienza e i conflitti.

Lo stesso argomento in dettaglio: Schema Fisico del Database.

Il design fisico di un database precisa la configurazione fisica di un database sui supporti di memorizzazione. Questo include dettagliate specifiche dei data element, tipo di dato, indicizzazione e altri parametri risiedenti nel data dictionary del DMBS. È la progettazione dettagliata di un sistema che include moduli e le specifiche hardware e software del sistema.

• Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, Riccardo Torlone, "Basi di dati 4/ed", 2014, ISBN 978-88-386-6587-5.
• (EN) Narain Gehani, The Database Book: Principles & Practice using MySQL, 1ª ed., Silicon Press, 2006, ISBN 0-929306-35-X.
• S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press, 2007. ISBN 0-12-369389-6
• M. Hernandez, "Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design", 3rd Edition, Addison-Wesley Professional, 2013. ISBN 0-321-88449-3

• Normalizzazione (informatica)
• Database relazionale
• Modello relazionale
• POOD (Principle of orthogonal design)
• The Third Manifesto
• Mappa concettuale
• Modellazione dei dati
• Modello E-R
• Entity-attribute-value model
• Object-relationship modeling
• Object Role Modeling
• Rappresentazione della conoscenza
• Logical data model
• Mappa mentale
• Physical data model
• Web semantico
• Three schema approach

• Database Design and Modeling Fundamentals
• Database design basics
• Database Normalization Basics Archiviato il 5 febbraio 2007 in Internet Archive. by Mike Chapple (About.com)
• Database Normalization Intro, Part 2
• An Introduction to Database Normalization, su dev.mysql.com. URL consultato il 25 febbraio 2012 (archiviato dall'url originale il 6 giugno 2011).
• Normalization, su utexas.edu. URL consultato il 25 febbraio 2012 (archiviato dall'url originale il 6 gennaio 2010).
• Efficient Database Design^{[collegamento interrotto]}
• Relational database design tutorial