analisi-disegno.com

Livelli modellazione dati - concettuale, logico, fisico

I livelli

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 diversi. Puntualizziamo:

Il livello "concettuale" rappresenta, in modo non necessariamente dettagliato, concetti e relazioni tra concetti. È completamente indipendente dalla tecnologia DBMS (Data Base Management System) che gestirà le strutture dati.
Il livello "logico" produce un modello dettagliato, 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. (Naturalmente, il massimo livello di precisione possibile viene raggiunto progressivamente, nell'ambito di un progetto.) 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 a competenze di natura tecnica, ma che derivano invece dalla conoscenza approfondita 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:

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.
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.

analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.