Portale Basi di Dati
Formazione Digitale · Guida completa · Database

Basi di Dati
Dal dato al modello

Dato vs informazione, DBMS, progettazione concettuale e logica, diagrammi E-R, cardinalità e chiavi esterne. Tutto il necessario per capire come funziona davvero un database.

🎓 AFM · RIM 🗃️ Database 📐 Modello E-R ⏱ ~40 min
1
Dato vs Informazione
Due concetti spesso confusi, con una differenza fondamentale

Nel mondo aziendale, e in particolare negli indirizzi AFM e RIM, si sente spesso parlare di dati e informazioni come se fossero la stessa cosa. Non lo sono — e capire la differenza è il punto di partenza di qualunque ragionamento sui database.

ConcettoDefinizioneEsempio
Dato Una descrizione elementare, un valore grezzo privo di contesto. Rossi  ·  01/01/2025  ·  120.50
Informazione L'incremento di conoscenza che si ottiene interpretando e contestualizzando i dati. "Il cliente Rossi ha effettuato un ordine di 120,50 € il 01/01/2025"

L'insieme di valori {Rossi, 01/01/2025, 120.50} è una raccolta di dati grezzi: di per sé non ci dice nulla. Diventa informazione significativa solo quando gli associamo uno schema che ne definisce il significato, ad esempio {Cognome Cliente, Data Ordine, Importo Fattura}.

💡
È la chiave di interpretazione — lo schema — che trasforma dati grezzi in informazione utilizzabile. Senza schema, i dati sono rumore.
2
Schema e Istanza
La struttura e i valori: lo stampo e i biscotti

Ogni base di dati separa nettamente due livelli: la struttura (come sono organizzati i dati) e i valori concreti (i dati effettivi in un dato momento). Questa distinzione si chiama schema vs istanza.

SCHEMA (struttura) Cognome Data Ordine Importo — nomi delle colonne — — tipi di dato — — vincoli — produce ISTANZA (valori reali) Cognome Data Ordine Importo Rossi 01/01/2025 120,50 Bianchi 15/03/2025 340,00 Ferrari 02/04/2025 78,90
Lo schema definisce la struttura (nomi colonne, tipi, vincoli). L'istanza è l'insieme dei valori concreti in un dato momento.

Un'analogia efficace: lo schema è lo stampo per biscotti — definisce la forma. L'istanza sono i biscotti reali — i valori concreti che quella forma produce in un determinato momento. Lo schema cambia raramente; l'istanza cambia continuamente.

🍪
Lo schema può rimanere invariato per anni mentre l'istanza cambia ogni giorno. Modificare lo schema — aggiungere una colonna, rinominarne una — richiede attenzione: tutte le istanze esistenti devono restare coerenti.
3
Perché Excel non basta
I limiti della gestione tradizionale con file e fogli di calcolo

Prima dei database, le aziende gestivano le informazioni con archivi cartacei, documenti Word o fogli di calcolo come Excel. Questi strumenti funzionano bene per dati semplici e quantità limitate — ma al crescere della complessità emergono problemi seri.

🔁
Ridondanza
La stessa informazione (es. l'indirizzo di un cliente) è duplicata in più file. Ogni copia va aggiornata manualmente: errori garantiti.
⚠️
Inconsistenza
L'indirizzo aggiornato in contabilità ma non in magazzino genera due versioni diverse. I dati diventano inaffidabili per le decisioni aziendali.
🔒
Nessun controllo accessi
Chiunque abbia il file può leggere o modificare tutto. Non è possibile stabilire chi può vedere solo i propri dati.
🚫
No accesso simultaneo
Due persone non possono modificare lo stesso file contemporaneamente senza rischio di sovrascrittura o corruzione dei dati.
📉
Scalabilità zero
Un foglio Excel con 100.000 righe diventa lento e instabile. Non è pensato per grandi volumi di dati in accesso continuo.
🔍
Ricerche complesse
Incrociare dati da più fogli richiede formule CERCA.VERT complesse e fragili. Un database gestisce questo in modo nativo con le query.
📦
Caso reale: un'azienda aggiorna l'indirizzo di un cliente nel foglio della contabilità ma dimentica quello del magazzino. Risultato: la spedizione parte all'indirizzo sbagliato. Costo reale, causato da dati inconsistenti.
4
Cos'è una Base di Dati
Non un archivio, ma un modello di realtà
📚
Definizione: Una base di dati (o database) è una raccolta di dati logicamente correlati, utilizzata per modellare una realtà di interesse. I dati sono memorizzati su supporto di massa e progettati per essere fruiti in modo ottimizzato da applicazioni e utenti diversi.

Un database non è un semplice elenco. È un modello organizzato di una realtà: che si tratti di un'azienda, di un magazzino, di un sistema bancario o di un orario ferroviario, il database ne rappresenta gli elementi rilevanti e le relazioni tra loro in modo strutturato e coerente.

Le sei proprietà fondamentali

Consistenza
I dati sono significativi e logicamente coerenti con gli scopi per cui sono stati raccolti.
🛡️
Integrità
Le operazioni degli utenti non possono danneggiare o rendere incoerenti i dati esistenti.
🔐
Sicurezza
I dati sono protetti da accessi non autorizzati e da eventi accidentali come guasti hardware.
👥
Condivisibilità
Più utenti e applicazioni accedono agli stessi dati in modo controllato e simultaneo, senza interferenze.
💾
Persistenza
I dati sopravvivono ai programmi che li usano: rimangono salvati finché non vengono esplicitamente rimossi.
📈
Scalabilità
Il sistema gestisce quantità crescenti di dati senza degradazione delle prestazioni.
5
Il DBMS
Il software che dà vita al database
🧠
Definizione: Un DBMS (Data Base Management System) è un insieme di strumenti software che, sulla base delle specifiche dell'utente, gestisce dati strutturati che sono tanti, importanti, condivisi, sia interrogati che aggiornati.

Un database da solo è una raccolta passiva di dati. Il DBMS è il software intermediario tra gli utenti (o le applicazioni) e il database fisico: lo gestisce, lo protegge e lo rende interrogabile. Senza DBMS, un database sarebbe solo un insieme di file difficili da coordinare.

Cosa fa il DBMS

  • Gestione completa della base di dati a tutti i livelli.
  • Persistenza e consistenza dei dati nel tempo.
  • Sicurezza e privacy: chi può accedere a cosa e con quali permessi.
  • Controllo dell'integrità: le operazioni rispettano sempre i vincoli definiti.
  • Gestione delle transazioni: sequenze di operazioni eseguite completamente o per nulla, garantendo le proprietà ACID (vedi sotto).
  • Interrogazione (query): estrazione mirata di dati tramite un linguaggio specifico (SQL).

Le proprietà ACID

Una transazione è un insieme di operazioni che devono essere trattate come un'unica unità indivisibile — o vanno tutte a buon fine, o nessuna viene applicata. Il DBMS garantisce che ogni transazione rispetti quattro proprietà fondamentali, dette ACID.

ProprietàSignificatoEsempio concreto
A — Atomicità La transazione è indivisibile: o tutte le operazioni vengono eseguite, o nessuna. Un bonifico scala 500 € dal conto A e li accredita sul conto B. Se l'accredito fallisce, anche il prelievo viene annullato. Il denaro non sparisce nel nulla.
C — Coerenza La transazione porta il database da uno stato valido a un altro stato valido, rispettando tutti i vincoli definiti. Un ordine non può essere registrato con un codice cliente inesistente. Il DBMS blocca l'operazione prima che violi l'integrità referenziale.
I — Isolamento Le transazioni concorrenti non si interferiscono: ciascuna vede i dati come se fosse l'unica in esecuzione. Due cassieri che vendono contemporaneamente l'ultimo articolo in magazzino non possono entrambi "prenotarlo": uno dei due riceverà un errore di disponibilità.
D — Durabilità Una volta confermata (commit), la transazione è permanente anche in caso di guasto hardware o interruzione di corrente. Se il sistema si spegne dopo la conferma di una fattura, al riavvio la fattura è ancora lì. I dati non vengono persi.
🔍
Il potere delle query: un'azienda può chiedere al proprio DBMS "Quali clienti residenti in Lombardia hanno speso più di 500 € nell'ultimo trimestre?" e ottenere la risposta in millisecondi. È questa capacità di estrazione mirata che trasforma i dati grezzi in conoscenza di business per il decision making.

DBMS più diffusi

DBMSTipoUtilizzo tipico
MySQL / MariaDBRelazionale · Open sourceWeb, applicazioni PHP, PMI
PostgreSQLRelazionale · Open sourceApplicazioni enterprise, analisi dati
Microsoft SQL ServerRelazionale · ProprietarioAmbienti Windows, ERP aziendali
Oracle DatabaseRelazionale · ProprietarioGrandi aziende, banche, telco
LibreOffice BaseRelazionale · DesktopUso didattico, piccoli database locali
SQLiteRelazionale · EmbeddedApp mobile, browser, dispositivi IoT
6
Le tre fasi di progettazione
Dal problema reale al file sul disco: un percorso in tre passi

Creare un database non è un'attività improvvisata. Si segue un processo ingegneristico strutturato in tre fasi successive, che procedono dal livello più astratto a quello più concreto. L'output di ogni fase è l'input della successiva.

1. Concettuale Analisi dei requisiti Modello astratto Indipendente dal DBMS Output: Diagramma E-R 2. Logica Traduzione E-R → Tabelle Chiavi primarie ed esterne Modello relazionale Output: Schema logico 3. Fisica Implementazione su disco Strutture di accesso (indici) Ottimizzazione prestazioni Output: File fisici DB ← Parte dall'analisi del problema reale Arriva all'implementazione →
Le tre fasi procedono dal più astratto al più concreto. L'output di ogni fase diventa l'input della successiva.

Top-Down o Bottom-Up?

In fase di analisi concettuale esistono due approcci metodologici:

ApproccioCome funzionaQuando usarlo
Top-Down Si parte dalla visione generale del sistema, poi si scende progressivamente nel dettaglio delle singole componenti. Sistemi nuovi con requisiti chiari fin dall'inizio.
Bottom-Up Si progettano prima le parti individuali nel dettaglio, poi le si collegano per formare il sistema completo. Sistemi complessi dove le parti sono già note e si vuole integrare componenti esistenti.
ℹ️
In questo corso ci concentreremo sulla progettazione concettuale (modello E-R) e sulla progettazione logica (schema relazionale). La fase fisica è demandata al DBMS e alle sue impostazioni avanzate.
Schema che mostra il flusso dai requisiti aziendali al modello concettuale E-R e poi al modello logico con tabelle
Il modello concettuale risponde al COSA (quali entità e relazioni), il modello logico risponde al COME (quali tabelle, chiavi e colonne). I requisiti reali — fatture, ordini, archivi — sono il punto di partenza.
7
Entità, Istanze e Attributi
I mattoni fondamentali del modello E-R

Il modello Entità-Relazione (E-R) è lo strumento grafico usato nella progettazione concettuale per rappresentare la realtà di interesse in modo chiaro e indipendente dalla tecnologia. Si basa su tre concetti fondamentali.

ConcettoDefinizioneEsempio pratico
Entità Un "tipo" di oggetto o concetto del mondo reale che deve essere rappresentato nel database. L'entità Studente rappresenta il concetto generale di studente nel sistema.
Istanza di Entità Un singolo elemento specifico appartenente a un'entità, con i suoi valori concreti. "Mario Rossi, matricola 12345" è un'istanza di Studente. Viene anche chiamata record.
Attributo Una proprietà o caratteristica che descrive un'entità. Ogni istanza ha un valore per ogni attributo. Gli attributi di Studente: nome, cognome, matricola, indirizzo, classe.

Chiave Candidata e Chiave Primaria

🔑
Una Chiave Candidata è un insieme minimo di attributi che identifica univocamente ogni istanza di entità. Proprietà: unicità (nessuna istanza ha gli stessi valori per la chiave) e minimalità (nessun attributo può essere rimosso senza perdere l'unicità).

La Chiave Primaria (PK) è la chiave candidata scelta dal progettista come identificatore principale. Ogni entità ha una sola chiave primaria.

Tipi di chiave primaria

Tipologia
Semplice
Costituita da un singolo attributo.
Esempio: CodiceFiscale per una persona.
Tipologia
Composta (o Multipla)
Costituita da due o più attributi.
Esempio: CodiceCorso + AnnoAccademico per un'iscrizione.
Criterio di scelta
Naturale
Attributo che esiste già nei dati e garantisce unicità.
Esempio: CodiceFiscale, NumeroMatricola.
Criterio di scelta
Artificiale (Surrogate Key)
Attributo aggiunto ad hoc, spesso un intero auto-incrementante.
Esempio: ID_Studente generato dal sistema.
💡
Le chiavi artificiali sono spesso preferite per motivi di performance e semplicità: un numero intero è più veloce da confrontare di una stringa come il codice fiscale, e non cambia mai nel tempo. La chiave naturale invece può cambiare (es. una persona cambia cognome).
Confronto tra chiave primaria semplice (un pallino pieno) e chiave primaria composta (più pallini pieni collegati)
Nel diagramma E-R: un solo pallino pieno = chiave primaria semplice (es. Matricola). Più pallini pieni collegati = chiave primaria composta (es. Nome + Cognome + DataNascita).
8
Simbologia E-R e Cardinalità
Come si disegna un diagramma E-R e come si leggono le cardinalità

Il diagramma E-R usa simboli grafici standardizzati per rappresentare i vari elementi. Conoscerli è indispensabile per leggere e costruire un modello concettuale.

Simbologia standard del diagramma E-R STUDENTE Entità (rettangolo) Oggetto o concetto del mondo reale. Diventa una tabella nel database. SOSTIENE Rombo = Relazione tra entità. Può avere propri attributi di associazione. cognome Attributo semplice (ellisse vuota) Singolo dato che descrive un'entità. Si collega all'entità con una linea. matricola Chiave Primaria semplice Pallino pieno sul collegamento + nome sottolineato nell'ellisse. attr1 attr2 ENTITÀ Chiave Primaria composta Più pallini pieni: più attributi formano insieme la chiave univoca.
Rettangolo = Entità · Ellisse vuota = Attributo · Pallino pieno + sottolineatura = Chiave Primaria · Rombo = Relazione
Diagramma E-R completo: Autore scrive Libro, Libro pubblicato da CasaEditrice
Esempio completo: AUTORE scrive LIBRO (N:M), LIBRO pubblicato da CASAEDITRICE (1:N). Pallino pieno = chiave primaria. Pallino vuoto = attributo semplice.

Le cardinalità: leggere le molteplicità

La cardinalità specifica quante istanze di un'entità possono essere associate a un'istanza dell'altra entità nella relazione. Si esprime come coppia (min, max) e si scrive vicino all'entità a cui si riferisce, sul lato della linea che la connette al rombo.

📌
Come leggere le cardinalità nel diagramma: la coppia (min, max) si scrive vicino all'entità a cui si riferisce, non vicino al rombo. Descrive con quante istanze di quella entità partecipa alla relazione. Leggi sempre in entrambe le direzioni: da sinistra a destra e da destra a sinistra.
PERSONA (1,1) min 1 · max 1 POSSIEDE (0,N) min 0 · max N AUTOMOBILE Ogni automobile è posseduta da esattamente 1 persona · Ogni persona possiede da 0 a N automobili
Cardinalità dell'associazione POSSIEDE: lato AUTOMOBILE (1,1) — ogni auto appartiene a una sola persona; lato PERSONA (0,N) — una persona può possedere zero o più auto.
Esempio di attributi di relazione: DataInizio e DataFine sul rombo POSSESSO tra Persona e Automobile
Attributi di associazione: DataInizio e DataFine appartengono al rombo POSSESSO, non a PERSONA né ad AUTOMOBILE — perché descrivono il fatto del possesso, non le entità singole.

I tre tipi di relazione

TipoDescrizioneCardinalitàEsempio
Uno a Uno (1:1) Ogni istanza di A è associata a al massimo una di B, e viceversa. (1,1) — (1,1) Persona ↔ Passaporto
Uno a Molti (1:N) Un'istanza di A può essere associata a molte di B, ma ogni B è associata a una sola A. (1,1) — (0,N) Dipartimento ↔ Dipendenti
Molti a Molti (N:M) Un'istanza di A può essere associata a molte di B e viceversa. (0,N) — (0,N) Studenti ↔ Corsi
📌
La cardinalità dell'associazione è indicata direttamente sul rombo ed è data dai due valori massimi delle molteplicità. Se i valori massimi sono 1 e N, la cardinalità dell'associazione è 1:N. Questo valore è fondamentale per la traduzione al modello logico.
9
Entità forti, deboli e ridondanze
Dipendenze tra entità e dati calcolabili da eliminare

Entità forti e deboli

Non tutte le entità sono indipendenti. Un'entità è forte se può essere identificata autonomamente. È debole se dipende da un'altra entità per avere significato.

ENTITÀ FORTE ENTITÀ DEBOLE ALUNNO Esiste indipendentemente richiede VOTO Dipende da ALUNNO ✔ LIBRI SCOLASTICI (forte) Esistono e hanno senso anche senza prestiti. ✖ PRESTITI (debole) Un prestito non esiste senza un libro e uno studente. ✔ STUDENTI (forte) Esistono anche senza voti associati. ✖ VOTI (debole) Un voto senza uno studente non ha senso.
Le entità deboli sono spesso rappresentate con un doppio rettangolo nel diagramma E-R formale.

Informazioni ridondanti

Nella progettazione del modello E-R è fondamentale identificare gli attributi ridondanti: dati calcolabili o derivabili da altri elementi già presenti nel modello. Inserirli sarebbe un errore di progettazione.

🚫
Esempio 1 — Media esami: se il modello contiene un'entità ESAME con attributo VOTO, e STUDENTE è collegato a ESAME tramite la relazione SOSTIENE, allora l'attributo Media_Esami nello STUDENTE è ridondante: si calcola con una query sulla tabella ESAME. Va eliminato.
Diagramma E-R che mostra MEDIA_ESAMI come attributo ridondante di STUDENTE, barrato con una croce
MEDIA_ESAMI è barrata perché calcolabile: tramite la relazione SOSTIENE si accede ai VOTI in ESAME. Inserirla nel modello sarebbe ridondanza — e ogni modifica ai voti richiederebbe di aggiornare anche la media.
🚫
Esempio 2 — Numero di abitanti: se il modello ha un'entità COMUNE collegata a PERSONA, l'attributo Numero_Abitanti nel COMUNE è ridondante: si ottiene contando le istanze di PERSONA associate a quel comune. Va eliminato.
Regola pratica: chiediti sempre "questo dato è misurato o è calcolabile da dati già presenti?". Se è calcolabile, non va nel modello — va in una query.
10
Dal modello concettuale al logico
Le regole di traduzione da E-R a schema relazionale

Una volta completato il diagramma E-R, si procede con la traduzione al modello logico: uno schema che definisce le tabelle, le colonne, le chiavi primarie e le chiavi esterne, indipendentemente dallo specifico DBMS che verrà usato.

Come si scrive lo schema logico

Ogni tabella si rappresenta con il nome (al plurale) seguito dall'elenco degli attributi tra parentesi tonde, separati da virgole. La chiave primaria è sottolineata; la chiave esterna è preceduta da un asterisco.

-- Esempio: entità PERSONA tradotta in tabella
PERSONE(CodiceFiscale, Nome, Cognome, DataNascita, Indirizzo)

-- Entità AUTOMOBILE con chiave esterna (FK) verso PERSONE
AUTOMOBILI(Targa, Marca, Modello, Anno, *CodiceFiscale_Proprietario)

-- Tabella associativa per relazione N:M Studenti↔Corsi
ISCRIZIONI(*CodiceStudente, *CodiceCorso, DataIscrizione, Voto)
Schema logico scritto a mano con sintassi NOME(PK, attr, *FK) e relativa tabella con dati reali
La sintassi dello schema logico: NOME(PK sottolineata, attributi, *FK con asterisco). La freccia curva indica il riferimento tra chiave esterna e chiave primaria. Sotto: l'istanza concreta della tabella AUTO con i valori reali.

Le sette regole di traduzione

  1. 1
    Ogni entità diventa una tabella. Il nome dell'entità si usa al plurale.
  2. 2
    Gli attributi dell'entità diventano le colonne della tabella, ereditandone caratteristiche e vincoli.
  3. 3
    La chiave primaria dell'entità diventa la chiave della tabella (sottolineata nello schema logico).
  4. 4
    Relazione 1:N: nel lato N si aggiunge una colonna con la chiave primaria del lato 1. Questa è la chiave esterna (FK), indicata con asterisco.
  5. 5
    Relazione 1:1: si sceglie su quale delle due tabelle inserire la chiave esterna (solitamente nel lato con partecipazione facoltativa).
  6. 6
    Relazione N:M: si crea una terza tabella associativa che contiene le chiavi primarie di entrambe le tabelle. Può avere attributi propri (es. la data di iscrizione).
  7. 7
    Gli attributi di associazione (attributi del rombo) diventano colonne della tabella associativa o della tabella che riceve la FK.
Traduzione N:M → Tabella Associativa STUDENTI (0,N) FREQUENTA (0,N) CORSI traduzione STUDENTI CodStud (PK) Nome, Cognome... ISCRIZIONI (tabella associativa) *CodStud (FK → STUDENTI) *CodCorso (FK → CORSI) DataIscrizione, Voto CORSI CodCorso (PK) Titolo, CFU...
Una relazione N:M genera sempre una terza tabella associativa con le chiavi esterne di entrambe le entità. Le FK possono formare insieme la chiave primaria composta della tabella associativa.
🎯
Riepilogo delle regole chiave: 1:N → FK sul lato N · 1:1 → FK sul lato con partecipazione facoltativa · N:M → tabella associativa con due FK. Questi tre casi coprono la quasi totalità delle relazioni che incontrerete in un progetto reale.
🔗
Prossimi passi: una volta acquisito il modello logico, si passa alla fase fisica — la creazione reale delle tabelle in un DBMS come LibreOffice Base o MySQL — e all'interrogazione dei dati tramite SQL e le sue query. Consulta la Guida alle Query con LibreOffice Base per approfondire.