Cos’è un DBMS

Un DBMS (Database Management System) è un software che permette di definire, creare, gestire, manipolare e interrogare basi di dati. Fornisce l’interfaccia tra le applicazioni e i dati fisici memorizzati su disco, garantendo integrità, concorrenza, sicurezza e persistenza delle informazioni. Evita duplicazioni, mantiene la coerenza e supporta più utenti con controllo delle transazioni.

Componenti principali

Un DBMS tipico include il motore di storage (organizzazione fisica su disco, buffer e caching), il gestore delle transazioni (ACID, controllo di concorrenza, rollback/commit), l’ottimizzatore di query (piani di esecuzione), il gestore degli indici (B-tree, hash, ecc.), meccanismi di accesso concorrente (lock, MVCC), sicurezza e autorizzazioni, logging e strumenti operativi (backup/restore, replica), e interfacce client (ODBC, JDBC, API).

Tipi e modelli di dati

I DBMS si dividono in più famiglie in base al modello dati e all’architettura. I RDBMS (relazionali) usano tabelle e SQL ed eccellono in transazionalità e integrità (PostgreSQL, MySQL, Oracle). I NoSQL comprendono key-value, document store, column-family e graph DB, orientati a scalabilità orizzontale e flessibilità schemaless (MongoDB, Cassandra, Neo4j). I NewSQL forniscono scalabilità distribuita con garanzie transazionali (Spanner, CockroachDB). Esistono anche time-series DB ottimizzati per dati temporali (InfluxDB, TimescaleDB).

Transazioni e proprietà ACID

Una transazione è un’unità atomica di lavoro. Le proprietà ACID sono: atomicità (tutto o niente), consistenza (lo stato passa da valido a valido), isolamento (transazioni concorrenti non producono effetti incoerenti) e durabilità (una volta effettuato il commit, i cambi persistono). Il DBMS realizza queste proprietà tramite logging (WAL), locking o MVCC e meccanismi di recovery.

CAP theorem e sistemi distribuiti

Nel contesto distribuito, il teorema CAP afferma che è impossibile garantire contemporaneamente Consistenza, Availability e Partition tolerance. In presenza di partizioni di rete si deve scegliere tra consistenza e disponibilità. Questa scelta guida l’architettura: sistemi fortemente consistenti (NewSQL, Spanner) o sistemi eventual-consistency (Cassandra, Dynamo-style) per alta disponibilità e throughput.

Progettazione: ER, normalizzazione e denormalizzazione

La progettazione parte dal modello concettuale (ER — entità, attributi, relazioni). Lo schema logico si costruisce normalizzando (1NF, 2NF, 3NF, BCNF) per rimuovere ridondanze e anomalie, ma si possono introdurre denormalizzazioni per motivi prestazionali: tabelle aggregate, materialized views, copie per letture rapide. Ogni scelta è un trade-off tra integrità e performance.

Indici, statistiche e ottimizzazione

Gli indici sono fondamentali per velocizzare le letture: B-tree, hash, bitmap, GiST, R-tree. L’ottimizzatore usa statistiche (cardinalità, distribuzione) per scegliere piani di esecuzione: join order, tipo di join, access method. Best practice: indici su colonne usate in WHERE, JOIN, ORDER BY; mantenere statistiche aggiornate; usare EXPLAIN ANALYZE per profilare le query.

Concorrenza: locking vs MVCC

Il controllo di concorrenza può essere basato su locking (pessimistico) o MVCC (multi-version) che consente snapshot isolation e riduce la contesa. Locking è semplice ma può causare deadlock; MVCC migliora le prestazioni in letture concorrenti, adottato da PostgreSQL, Oracle e InnoDB.

Storage engine e gestione fisica

I DB offrono storage engine diversi (MySQL: InnoDB, MyISAM; MongoDB: WiredTiger). Ogni engine ha caratteristiche su crash recovery, compressione e locking. Strategie di backup includono logical dump (pg_dump, mysqldump), snapshot a livello filesystem (LVM) e backup log-based (WAL) per point-in-time recovery (PITR).

Replica, HA e sharding

La replica copia i dati tra nodi (synchronous o asynchronous) per scalabilità in lettura e failover. L’alta disponibilità richiede orchestrazione del failover (Patroni, repmgr, Orchestrator). Lo sharding (partizionamento orizzontale) divide i dati su più nodi per scalare le scritture e la capacità di storage; la scelta della shard key è critica per bilanciare il carico.

Sicurezza e compliance

Misure essenziali: autenticazione forte, ruoli e permessi granulari, cifratura in-transit (TLS) e at-rest, auditing e logging, pseudonimizzazione dei dati sensibili e gestione delle chiavi. Verificare la conformità GDPR per dati personali e predisporre retention policy e procedure di incident response.

Monitoraggio e operazioni

Metriche importanti: latenza query, tps, cache hit ratio, lock waits, replication lag, spazio disco, I/O, CPU e memoria. Strumenti: Prometheus + Grafana, Percona Monitoring, pg_stat views, Datadog. Alerting e runbook per failover e recovery sono fondamentali.

Casi d’uso per tipologie di DB

RDBMS: ERP, sistemi bancari, applicazioni enterprise. Document store: CMS, e-commerce, cataloghi. Key-value: cache, session store (Redis). Column-family: telemetria e logging a grande scala (Cassandra). Graph DB: social network, recommendation, fraud detection. Time-series DB: metriche, IoT, finanza ad alta frequenza.

Trend e scenari

Aumentano DBaaS e managed services (RDS, Cloud SQL), Distributed SQL/NewSQL per transazioni globali, multi-model DB, serverless DB e integrazione OLTP/OLAP (HTAP). Streaming e change data capture (Debezium, Kafka Connect) collegano DB operativi a pipeline analitiche.

Esempi concreti

DB popolari: PostgreSQL (estendibile, PostGIS), MySQL/MariaDB (diffuso nel web), Oracle DB (enterprise), SQL Server (Microsoft), MongoDB (document), Cassandra (throughput), Redis (in-memory key-value), Neo4j (graph), CockroachDB/Spanner (distributed SQL).

Esempio pratico: schema minimo e query

-- Schema relazionale minimo (Postgres/MySQL)
CREATE TABLE clienti (
  cliente_id SERIAL PRIMARY KEY,
  nome VARCHAR(100) NOT NULL,
  email VARCHAR(200) UNIQUE,
  data_registrazione DATE DEFAULT CURRENT_DATE
);

CREATE TABLE ordini (
  ordine_id SERIAL PRIMARY KEY,
  cliente_id INTEGER NOT NULL REFERENCES clienti(cliente_id),
  totale NUMERIC(12,2) NOT NULL,
  data_ordine TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Inserimento
INSERT INTO clienti (nome, email) VALUES ('Mario Rossi', 'mario@example.com');

-- Query: totale speso per cliente
SELECT c.cliente_id, c.nome, SUM(o.totale) AS totale_speso
FROM clienti c
JOIN ordini o ON c.cliente_id = o.cliente_id
GROUP BY c.cliente_id, c.nome
ORDER BY totale_speso DESC;
            

Esempio transazione

BEGIN;
UPDATE conti SET saldo = saldo - 100 WHERE id = 1;
UPDATE conti SET saldo = saldo + 100 WHERE id = 2;
COMMIT;
-- ROLLBACK; se qualcosa fallisce
            

Strategie di backup e restore

Full backup, incremental backup e WAL/redo-based PITR. Tecniche: pg_basebackup + archiviazione WAL (Postgres), snapshot LVM + backup dei logs, logical dumps per migrazioni. Testare periodicamente il restore in ambienti separati.

Checklist per scegliere un DBMS

Errori comuni e best practices

Evita normalizzazione eccessiva senza considerare i costi JOIN, indici inutili che rallentano scritture, mancanza di piani di backup/restore, scarsa gestione degli accessi e scelte basate sulla moda. Best practice: progettare per il carico reale, monitorare, testare restore, proteggere i dati e scegliere shard key con attenzione.