Database Relazionali e SQL

Il modello relazionale

Il modello relazionale l'ha inventato Edgar F. Codd nel 1970, e organizza i dati in tabelle fatte di righe e colonne. Ogni tabella rappresenta una cosa del mondo (clienti, ordini, prodotti) e i collegamenti fra le tabelle si fanno con delle chiavi condivise. È un'idea di più di cinquant'anni fa che regge ancora tutto quello che usi ogni giorno, dalla banca al gestionale.

I motori più diffusi sono MySQL, PostgreSQL, Microsoft SQL Server, Oracle e SQLite. Ognuno aggiunge qualcosa di suo allo standard SQL, e le basi sono identiche: quello che impari su uno lo porti sugli altri.

"Un database relazionale ben progettato garantisce integrità dei dati, eliminazione delle ridondanze e facilità di interrogazione."

Tabelle, righe e colonne

Una tabella è una struttura a due dimensioni in cui:

• Ogni colonna (attributo) ha un nome univoco e un tipo di dato (INTEGER, VARCHAR, DATE, BOOLEAN, ecc.).
• Ogni riga (tupla) rappresenta un singolo record, ovvero un'istanza dell'entità.
• L'ordine delle righe non ha significato logico; l'ordine delle colonne è definito dallo schema ma non influisce sulle query.

CREATE TABLE studenti (
    id          INT PRIMARY KEY AUTO_INCREMENT,
    nome        VARCHAR(50) NOT NULL,
    cognome     VARCHAR(50) NOT NULL,
    email       VARCHAR(100) UNIQUE,
    data_nascita DATE,
    corso_id    INT
);

Chiavi primarie ed esterne

La chiave primaria (PRIMARY KEY) identifica univocamente ogni riga di una tabella. Può essere un singolo campo o una combinazione di più campi (chiave composta). Non ammette valori NULL né duplicati.

La chiave esterna (FOREIGN KEY) crea un collegamento tra due tabelle, garantendo l'integrità referenziale: il valore nella tabella figlia deve corrispondere a un valore esistente nella tabella padre.

CREATE TABLE corsi (
    id      INT PRIMARY KEY AUTO_INCREMENT,
    nome    VARCHAR(100) NOT NULL,
    crediti INT DEFAULT 6
);

ALTER TABLE studenti
ADD CONSTRAINT fk_corso
FOREIGN KEY (corso_id) REFERENCES corsi(id)
ON DELETE SET NULL
ON UPDATE CASCADE;

SQL di base

SQL (Structured Query Language) si divide in famiglie di comandi:

Le quattro operazioni con cui si fa il 90% del lavoro:

-- CREATE (inserimento)
INSERT INTO studenti (nome, cognome, email, corso_id)
VALUES ('Marco', 'Rossi', 'marco.rossi@uni.it', 1);

-- READ (lettura)
SELECT nome, cognome, email
FROM studenti
WHERE corso_id = 1
ORDER BY cognome ASC;

-- UPDATE (aggiornamento)
UPDATE studenti
SET email = 'nuovo@uni.it'
WHERE id = 1;

-- DELETE (cancellazione)
DELETE FROM studenti
WHERE id = 1;

Le JOIN

Le JOIN combinano righe di due o più tabelle basandosi su una condizione di correlazione. Sono il cuore del modello relazionale.

• INNER JOIN: restituisce solo le righe con corrispondenza in entrambe le tabelle.
• LEFT JOIN: restituisce tutte le righe della tabella sinistra, con NULL dove non c'è corrispondenza.
• RIGHT JOIN: simmetrico al LEFT JOIN.
• FULL OUTER JOIN: restituisce tutte le righe di entrambe le tabelle.
• CROSS JOIN: produce il prodotto cartesiano.

SELECT s.nome, s.cognome, c.nome AS corso
FROM studenti s
INNER JOIN corsi c ON s.corso_id = c.id
WHERE c.crediti >= 6
ORDER BY s.cognome;

Normalizzazione (1NF-3NF)

La normalizzazione è il processo di organizzazione delle tabelle per ridurre ridondanza e anomalie di inserimento, aggiornamento e cancellazione.

• Prima Forma Normale (1NF): ogni cella contiene un solo valore atomico; non ci sono gruppi ripetuti. Un campo "telefoni" con più numeri separati da virgola viola la 1NF.
• Seconda Forma Normale (2NF): soddisfa la 1NF e ogni attributo non-chiave dipende dall'intera chiave primaria (rilevante con chiavi composte).
• Terza Forma Normale (3NF): soddisfa la 2NF e nessun attributo non-chiave dipende transitivamente dalla chiave primaria. Se un campo "città" determina "regione", bisogna separare i dati in tabelle distinte.

"I dati devono dipendere dalla chiave, dalla chiave intera e da nient'altro che la chiave." (Regola mnemonica per la 3NF)

Indici

Un indice è una struttura dati (tipicamente un B-Tree o un hash) che accelera le operazioni di ricerca su una o più colonne, a fronte di un maggiore consumo di spazio e di un leggero rallentamento nelle operazioni di scrittura.

-- Indice su singola colonna
CREATE INDEX idx_email ON studenti(email);

-- Indice composto
CREATE INDEX idx_nome_cognome ON studenti(nome, cognome);

-- Indice univoco
CREATE UNIQUE INDEX idx_unique_email ON studenti(email);

Transazioni ACID

Le transazioni raggruppano più operazioni SQL in un'unità logica. Le proprietà ACID garantiscono la correttezza dei dati:

• Atomicità (Atomicity): la transazione viene eseguita completamente o per niente.
• Consistenza (Consistency): il database passa da uno stato valido a un altro stato valido.
• Isolamento (Isolation): le transazioni concorrenti non interferiscono tra loro.
• Durabilità (Durability): una volta confermata, la transazione sopravvive a guasti di sistema.

BEGIN TRANSACTION;

UPDATE conti SET saldo = saldo - 100 WHERE id = 1;
UPDATE conti SET saldo = saldo + 100 WHERE id = 2;

-- Se tutto ok:
COMMIT;

-- Se qualcosa va storto:
-- ROLLBACK;

Il classico esempio è il trasferimento bancario: se il prelievo va a buon fine ma l'accredito fallisce, il ROLLBACK annulla entrambe le operazioni, evitando incongruenze.

SQL vs NoSQL

I database relazionali eccellono quando i dati hanno una struttura ben definita e le relazioni tra entità sono importanti: gestionali, e-commerce, sistemi contabili e CRM trovano nel modello SQL la garanzia di integrità e coerenza che serve a operazioni sensibili. Tuttavia, per scenari con dati semi-strutturati o esigenze di scalabilità orizzontale estrema, i database NoSQL possono essere più appropriati.

Nel marketing e nell'analisi dati la scelta è pragmatica: un SQL ben normalizzato è perfetto per anagrafiche clienti, ordini e report con join complessi, mentre soluzioni NoSQL documentali brillano con cataloghi flessibili, log e dati provenienti da API esterne. Molti progetti reali adottano un approccio ibrido, usando ciascuna tecnologia dove rende di più.

Anche adesso che l'AI scrive le query, sapere SQL serve, e per un motivo pratico: la query te la genera in due secondi, e il compito di capire se il risultato è giusto resta tuo. Per collegare le tabelle giuste, riconoscere un JOIN che duplica le righe e vedere che un totale non torna serve sapere com'è fatto il database. Saper leggere uno schema e scrivere una SELECT con un JOIN è la differenza fra interrogare i dati dell'azienda da solo e chiedere a qualcun altro di farlo per te.

Da qui si va avanti con le API e i web service, che sono il modo in cui i dati escono dal database e arrivano in una pagina, e con i fondamenti di JavaScript per la parte che si vede.