Tanto tempo fa, quando i dinosauri erano giganti... cioè, nel 1970, un tizio di nome Edgar Codd ha deciso che il caos nei dati aveva superato il livello di "disordine creativo" e ormai sembrava un buco nero che inghiottiva tempo e risorse. Edgar ci ha pensato su un bel po' e ha inventato un modo per mettere ordine, gettando le basi di un mondo dove i dati sono sistemati in tabelle ordinate, come libri su uno scaffale in una biblioteca perfetta. Righe, colonne, ordine — e niente più "vabbè, si capisce lo stesso" o "così va bene".
Il modello relazionale si basa sulla rappresentazione dei dati tramite tabelle, dove ogni tabella è fatta di righe e colonne. È tutto abbastanza intuitivo: le righe sono i record, le colonne sono le proprietà o attributi del record. Questo approccio rende più semplice lavorare e manipolare i dati.
Immagina di fare un ordine su un e-commerce. Perché quell’ordine venga gestito e consegnato, il sistema deve considerare un sacco di dettagli: chi sei (cliente), quale servizio di consegna hai scelto, dove spedire e come tracciare lo stato del pacco.
Se tutte queste informazioni fossero in un’unica tabella gigante, sarebbe il caos: dati duplicati, difficile aggiornarli e ancora più difficile trovare velocemente quello che serve. L’approccio relazionale aiuta a mettere ordine, dividendo le informazioni tra tabelle che possono scambiarsi dati.
In questo schema vedi un esempio di organizzazione dei dati per il processo di tracking delle consegne:
- Clienti - qui si conserva l’informazione su ogni cliente – con un Numero Cliente unico.
- Servizi di consegna - questa tabella contiene la lista dei servizi che possono effettuare la consegna, ognuno con il suo Numero Servizio unico.
- Consegna ordine - questa è la tabella centrale, che collega tutto. Ogni riga qui è una consegna specifica. Contiene il suo Numero Consegna, e fa riferimento al cliente, al servizio di consegna, può riferirsi a un ordine specifico, alla data e allo stato attuale.
Le frecce mostrano come i record della tabella Consegna ordine sono collegati ai record nelle tabelle Clienti e Servizi di consegna.
Esempio ipotetico della tabella Consegna ordine:
| Numero Consegna | Numero Cliente | Numero Servizio | Numero Ordine | Data creazione | Stato consegna |
|---|---|---|---|---|---|
| 121 | 101 | 1 | 1569 | 2025-03-23 | Consegnato |
| 122 | 234 | 3 | 1570 | 2025-03-24 | Consegnato |
| 123 | 1011 | 2 | 1571 | 2025-03-25 | Attivo |
| 124 | 1011 | 2 | 1572 | 2025-03-25 | In attesa |
Vantaggi di questo approccio:
- L’informazione su clienti o servizi di consegna viene salvata una sola volta, così evitiamo ripetizioni in ogni record di consegna.
- I collegamenti tramite numeri unici (detti anche chiavi) garantiscono che non ci siano, per esempio, consegne senza un cliente esistente o tramite un servizio che non esiste.
- È facile combinare dati da tabelle diverse per ottenere report complessi o selezioni specifiche.
- Le modifiche ai dati si fanno in un solo posto e sono subito disponibili per tutte le operazioni collegate (tipo il telefono del servizio di consegna).
Struttura di un database relazionale
Il cuore di un database relazionale sono le tabelle. Ogni tabella ha:
- Nome (Table Name) per poterla identificare — per esempio, customers.
- Set di colonne (Columns/Attributes), che definiscono le proprietà dell’oggetto.
- Quando nominiamo le colonne che servono come numeri unici (chiavi primarie), spesso usiamo il pattern
nome_id. Il suffisso_idqui vuol dire "identifier". Esempio:Numero Clientediventacustomer_id. - Per esempio, nella tabella customers: possono esserci
customer_id,first_name,emaile così via.
- Quando nominiamo le colonne che servono come numeri unici (chiavi primarie), spesso usiamo il pattern
- Dati nelle righe (Rows/Records) - una riga nella tabella customers: conterrà tutte le info su un cliente specifico (101, Alex Song ecc.).
Vediamo un esempio di tabella — customers:
| customer_id | full_name | phone_number | delivery_address | registration_date | |
|---|---|---|---|---|---|
| 101 | Alex Song | alex.song@example.com | 555-0101 | 123 Main St, Anytown | 2023-01-15 |
| 234 | Maria Garcia | maria.g@example.org | 555-0102 | 456 Oak Ave, Otherville | 2022-11-30 |
| 1011 | David Lee | david.lee@example.net | 555-0103 | 789 Pine Ln, Sometown | 2023-03-01 |
Chiavi delle tabelle
Per identificare in modo unico ogni riga in una tabella, si usa la chiave primaria (Primary Key, PK). È una colonna (o più colonne) i cui valori sono unici per ogni riga e non possono essere vuoti. Pensala come il numero unico di ogni record, tipo customer_id nella nostra tabella customers: identifica senza dubbi ogni cliente.
La chiave primaria è come il passaporto, anzi, il suo numero: unico per ogni oggetto. E aiuta a evitare problemi con record omonimi.
Per collegare le tabelle si usa la chiave esterna (Foreign Key, FK). È una colonna in una tabella che fa riferimento alla chiave primaria di un’altra tabella. Le chiavi esterne sono i "ponti" tra le tabelle. Spesso il nome della colonna della chiave esterna coincide con quello della chiave primaria a cui si riferisce. Per esempio, nella tabella deliveries la colonna customer_id sarà una chiave esterna che contiene valori dalla colonna customer_id della tabella customers, così colleghiamo la consegna al cliente.
Questo è lo schema che già conosciamo, ma ora è più realistico.
- La tabella customers contiene info sui clienti; la sua chiave primaria è
customer_id. - La tabella delivery_services conserva i dati sui servizi di consegna; la sua chiave primaria è
service_id. - La tabella orders (mostrata per completezza, visto che c’è il riferimento
order_iddalla tabella delle consegne) serve per le info sugli ordini, con chiave primariaorder_id. - La tabella deliveries è centrale per il tracking delle consegne. Ha:
- La sua chiave primaria:
delivery_id. - Tre chiavi esterne per collegare:
customer_id(FK): collega la consegna a un cliente specifico dalla tabella customers.service_id(FK): collega la consegna al servizio scelto dalla tabella delivery_services.order_id(FK): collega la consegna all’ordine corrispondente dalla tabella orders.
- Il campo
created_dateindica la data e ora di creazione del record di consegna.
- La sua chiave primaria:
Questo uso di chiavi primarie ed esterne garantisce integrità dei dati. Il sistema non ti farà creare un record di consegna se il customer_id o order_id non esistono nelle rispettive tabelle e ti permette di recuperare in modo flessibile le info collegate.
Vantaggi del modello relazionale
Il modello relazionale ha un sacco di vantaggi che lo rendono il top rispetto ad altri approcci:
- Struttura semplice. Tabelle con colonne e righe sono chiare e facili da capire.
- Flessibilità nella gestione dei dati. Puoi aggiungere o modificare dati facilmente, senza rompere tutto.
- Supporto per query complesse. Con SQL puoi tirare fuori dati da tante tabelle, combinarli, filtrarli e fare praticamente tutto quello che ti serve. Tipo trovare tutti gli studenti iscritti a un certo corso — facilissimo!
- Integrità dei dati tramite chiavi. Usare chiavi primarie ed esterne garantisce che i dati nel database siano coerenti. Non puoi, per esempio, aggiungere un record di uno studente a un corso se quel corso non esiste.
Il modello relazionale dei dati è la base dei database moderni. È semplice, potente e perfetto per conservare dati strutturati. Come diceva Edgar Codd: "Metti ordine o muori!" (ok, l’ha detta in modo diverso, ma il senso è quello...). Nella prossima lezione vediamo come il modello relazionale si differenzia dagli altri tipi di database (tipo NoSQL) e dove conviene usare uno o l’altro.
GO TO FULL VERSION