CodeGym /Corsi /SQL SELF /Modello relazionale dei dati

Modello relazionale dei dati

SQL SELF
Livello 1 , Lezione 1
Disponibile

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 _id qui vuol dire "identifier". Esempio: Numero Cliente diventa customer_id.
    • Per esempio, nella tabella customers: possono esserci customer_id, first_name, email e così via.
  • 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 email 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_id dalla tabella delle consegne) serve per le info sugli ordini, con chiave primaria order_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_date indica la data e ora di creazione del record di consegna.

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:

  1. Struttura semplice. Tabelle con colonne e righe sono chiare e facili da capire.
  2. Flessibilità nella gestione dei dati. Puoi aggiungere o modificare dati facilmente, senza rompere tutto.
  3. 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!
  4. 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.

Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION