Comprendere un database

Prima della struttura: perché una base diventa necessaria

Immagina un catalogo il cui stock è 8 nel file del negozio e 11 nel negozio online. Un ordine fa riferimento a un cliente assente, mentre due report sulle vendite danno come risultato totali diversi.

Nessuno di questi problemi viene risolto imparando prima la parola chiave SQL. Hai bisogno di una fonte condivisa in cui le informazioni abbiano un luogo noto, dove le relazioni siano verificabili e dove le regole impediscano stati impossibili.

Un foglio di calcolo rimane molto utile per un'analisi una tantum o un piccolo set di dati. Un database diventa rilevante quando più processi devono leggere e modificare dati collegati con le stesse regole.

• Informazioni duplicate: due versioni potrebbero differire.
• Stock incoerente: la decisione dipende dal file aperto.
• Ordine senza cliente: il rapporto commerciale si interrompe.
• Rapporto non riproducibile: il calcolo o la fonte non sono condivisi.

Una tabella organizza lo stesso tipo di oggetto

Un database relazionale memorizza le informazioni in tabelle. Una tabella clients contiene i clienti; una tabella commandes contiene gli ordini.

Ogni tabella ha una struttura definita. Ciò impedisce che una data, un importo o un identificatore vengano interpretati in modo diverso a seconda di chi apre il file.

• Una linea rappresenta un record.
• Una colonna rappresenta una proprietà.
• Un tipo specifica i valori autorizzati: testo, numero, data o booleano.

La chiave primaria identifica una riga

Due client possono avere lo stesso nome. Una chiave primaria come id_client fornisce a ciascuna riga un identificatore univoco e stabile.

Un comando può quindi memorizzare id_client come chiave esterna. Questo riferimento collega le due tabelle senza copiare tutte le informazioni sul cliente.

clients
- id_client  INTEGER  PRIMARY KEY
- nom        VARCHAR
- ville      VARCHAR

commandes
- id_commande    INTEGER  PRIMARY KEY
- id_client      INTEGER  REFERENCES clients(id_client)
- montant        DECIMAL

Database relazionale o foglio Excel?

Un foglio di calcolo è eccellente per esplorare rapidamente un piccolo set di dati. Un database relazionale è progettato per mantenere regole, connettere diversi insiemi e servire a diversi usi senza moltiplicare le copie.

SQL permette poi di porre una domanda specifica a questo database: quali clienti vivono a Tunisi, quali ordini superano i 100 TND o quale prodotto realizza il maggior numero di vendite?

• Excel favorisce la manipolazione visiva di un foglio.
• Una fondazione enfatizza la coerenza e le relazioni.
• SQL descrive il risultato desiderato senza modificare i dati predefiniti.

Leggi una base come un professionista

Prima di scrivere una query, un analista cerca di capire cosa rappresenta una riga, quali colonne sono richieste e come sono correlate le tabelle. Questa lettura del modello evita di produrre un risultato tecnicamente valido ma falso a livello aziendale.

Chiedi sempre chi crea i dati, quando e secondo quali regole. Una data di ordine non ha lo stesso significato di una data di pagamento; un importo escluse le tasse non deve essere confrontato direttamente con un importo comprensivo di tutte le tasse.

In un progetto reale, scrivi le definizioni importanti in un dizionario di dati. Poche righe di documentazione condivisa riducono le ambiguità e rendono riproducibili le analisi.

• Formulare cosa rappresenta una linea.
• Individuare le chiavi e le colonne facoltative.
• Convalida unità, date e stati prima del calcolo.

Verifica ciò che hai capito

In una tabella produits, quale colonna sarebbe la migliore chiave primaria: produit, prix o id_produit?