Base di dati (parte 2)

Un modello di dati fornisce i concetti e le regole attraverso i quali è possibile

rappresentare un dominio. Uno schema utilizza tali concetti per rappresentare gli

aspetti di uno specifico dominio ritenuti rilevanti. Gli stessi dati possono essere

rappresentati con due modelli diversi, ogni rappresentazione rende espliciti alcuni

concetti, relazioni e vincoli, lasciandone altri impliciti o omettendoli. Tali scelte

determinano quali aspetti del dominio risulti naturale esprimere, mettere in relazione e

interrogare.

Quando si progetta una base di dati non si decide subito il tipo di modello che si vuole

utilizzare si vuole parlare dei dati prescindendo il modello logico e utilizzando il



modello concettuale dei dati (posso specificare le esigenze di memorizzazione a

prescindere dal livello logico).

Il contenuto di un dominio ha un livello più astratto di quello logico, e viene quindi

redatto con un modello concettuale.

Mentre gli schemi definiscono la "struttura del database" a diversi livelli, l'istanza del

database si riferisce al suo contenuto effettivo in un dato momento.

La progettazione di un database richiede di passare da un dominio di interesse a una

rappresentazione che possa essere implementata su un computer e interrogata.

Si articola in 3 fasi:

- Progettazione concettuale

- Progettazione livello logico

- Progettazione livello fisico

Spostandosi di livello ci si accorge che gli schemi sono sempre meno espressivi,

sempre più vincolati a ciò che permette di fare la base di dati scelta (perdono

dell’intuitività). In

ogni fase, si sacrifica l'espressività a favore della formalità: la rappresentazione

diventa più

precisa e meno ambigua, ma alcuni aspetti semantici del dominio, esplicitamente colti

a

livello concettuale, potrebbero non essere più rappresentati direttamente.

Nella fase di progettazione concettuale, lo schema definito è altamente espressivo:

cattura la ricchezza del dominio reale in modo intuitivo e vicino alla comprensione

umana. Tuttavia, trattandosi di una rappresentazione relativamente informale e

astratta, non è ancora pronto per l'implementazione diretta (come nella progettazione

di una casa a livello base, l’architetto indica che sensazione devono trasmettere le

stanze).

A livello logico, lo schema diventa più formale e strutturato: si attiene alle regole di

uno specifico modello di dati (come il modello relazionale), riducendo in parte la

flessibilità semantica e la ricchezza del modello concettuale, ma rendendolo più

preciso e privo di ambiguità (come un architetto quando definisce le posizioni esatte e

le misure della casa).

A livello fisico, lo schema è di natura prettamente tecnica e specifica per

l'implementazione (includendo, ad esempio, codice SQL): descrive nel dettaglio le

strutture di memorizzazione, l'organizzazione dei file, ecc. In questa fase, gran parte

della semantica del dominio non è più direttamente visibile, risultando in larga misura

implicita nella progettazione (come quando vengono definiti lo spessore dei tubi

dell’impianto idraulico o di quello elettrico).

L'obiettivo della progettazione di un database è identificare e descrivere gli aspetti

rilevanti del dominio di interesse, insieme ai relativi requisiti. La progettazione

concettuale viene solitamente svolta interage