Progettazione dati

Livelli di progettazione

Quando si parla di modelli dati, si fa spesso riferimento a termini quali “concettuale”, “logico” e “fisico”. E spesso ci si confonde, in quanto questi termini significano cose diverse per persone diverse, o in strumenti diversio:

  • Il livello “concettuale” rappresenta, in modo non necessariamente dettagliato, concetti e relazioni tra concetti. Un modello concettuale dettagliato definisce attributi, identificatori e vincoli di integrità, ma è indipendente dalla tecnologia DBMS (Data Base Management System) che gestirà le strutture dati.
  • Il livello “logico” produce un modello dettagliato, ancora guidato essenzialmente dalle relazioni di significato tra i dati. È il livello di definizione delle tabelle in un DBMS relazionale, con indicazione di colonne e data type, chiavi primarie ed alternative, regole di integrità. Tutto ciò di cui chi accede alle tabelle deve essere consapevole. A differenza del modello concettuale, può essere un modello ottimizzato. Può, ad esempio, comprendere ridondanze introdotte per migliorare le tempistiche di accesso in consultazione.
  • Il livello “fisico” è quello in cui si definiscono caratteristiche utili per l’ottimizzazione delle prestazioni e della memoria (es. indici, percentuali di spazio disponibile per inserimento di nuove righe) o per la gestione del DBMS (es. organizzazione in data base e table space).

Per la progettazione del livello fisico è essenziale una competenza specialistica, tipica di un progettista DB. Per la definizione dei modelli concettuale e logico iniziale, invece, è sufficiente la conoscenza di tecniche di modellazione basilari, che si basano sull’analisi del significato dei dati (Entity-Relationship, normalizzazione).

La tabella seguente sintetizza le differenze tra i livelli:

Livello Concettuale Logico Fisico
Conoscenza primaria necessaria Significato dei dati Significato dei dati Caratteristiche DBMS
Ruolo del modello nei progetti Preliminare Intermedio Prodotto finale
Ottimizzazioni (per performance, contenimento spazio ecc.) Nessuna Il modello
logico iniziale è pienamente normalizzato, cioè privo
di ridondanze. Può essere successivamente ottimizzato sulla
base delle esigenze funzionali.
Quelle opportune per le esigenze funzionali
Legame con tecnologia DBMS Nessuno Medio Elevato
Tecniche di progettazione primarie Entity-Relationship Entity-Relationship, normalizzazione Ad hoc, mirate all’ottimizzazione degli accessi e degli spazi

Precisione del modello dati logico

Il modello logico è l’input per la progettazione fisica dei Data Base, ed è opportuno che raggiunga il massimo livello di precisione possibile. Un modello logico preciso comprende:

  • per ogni entità, l’elenco completo degli attributi
  • per ogni entità, l’indicazione esplicita della chiave primaria e di eventuali chiavi alternative
  • per ogni attributo, l’indicazione esplicita di opzionalità o obbligatorietà
  • per ogni attributo, l’indicazione esplicita del data type, che ne specifichi il formato e la lunghezza
  • per ogni data type per cui sia possibile farlo (pochi valori stabili, oppure range), l’esplicitazione dei valori ammessi
  • per ogni relationship, l’indicazione della molteplicità minima e massima in entrambe le direzioni
  • per ogni relationship, l’indicazione delle regole di integrità referenziale applicabili

Il modello logico deve, cioè, contenere tutte le informazioni necessarie che non sono legate ad aspetti tecnici, ma alla conoscenza dell’ambito applicativo, e quindi del significato dei dati.


Creazione del modello dati concettuale

Il modello dati può essere costruito in modo “top-down” o “bottom up”. Il risultato può essere identico, ma le modalità per arrivarci sono diverse.

Un modello è costruito in modo “top-down” se nasce in modo unitario, prescindendo da analisi preventive di porzioni del sistema (“subject area”).

È invece costruito in modo “bottom up” se il modello finale è il frutto dell’aggregazione di più modelli settoriali.

Ad esempio, in un progetto che utilizza i casi d’uso per la specifica dei requisiti, il modello dei dati può essere costruito in due modi alternativi:

  1. Prima di avere definito in dettaglio i casi d’uso, in modo unitario, viene creata una versione iniziale del modello. Successivamente, man mano che i singoli casi d’uso vengono dettagliati, il modello unitario viene arricchito e completato con nuovi attributi ed associazioni.
  2. Per ogni caso d’uso già dettagliato, viene definito un modello dei dati parziale, o “vista locale”. Il modello unitario verrà derivato passo passo, attraverso l’integrazione progressiva delle viste locali create per ogni caso d’uso.

Tutorial introduttivi


Bibliografia sulla progettazione dati


Moduli di formazione in aula

Corso: Progettazione di basi dati


Moduli di formazione a distanza

Moduli formativi (di base, ma impegnativi) disponibili sul sito www.adcorsi.com:

  • Modello Entity-Relationship
  • Normalizzazione dei dati

Notizie più recenti

Tutte le notizie