La strutturazione dei database (1/3): La chiave primaria
Iniziamo oggi una serie di articoli sulla strutturazione dei database. In anni di militanza nei vari forum di supporto, mi sono reso conto che ci sono molti utenti perfettamente in grado di manipolare i database, con query anche molto complesse, ma quando chiedono aiuto per qualche ragione e si va a vedere la struttura delle tabelle del database, capita di trovarsi di fronte a delle realizzazioni confuse e che non tengono conto di alcune semplici e basilari norme.
Questo articolo è dunque destinato a chi si è addentrato da poco nel mondo dei database e vuole partire con il piade giusto, come pure a chi ha già una certa esperienza e desidera migliorare la qualità dei propri prodotti.
I principi che vedremo sono fondamentali per realizzare dei database efficienti, mantenibili ed aderenti agli standard della programmazione. Gli argomenti che tratteremo sono i seguenti:
- La chiave primaria
- La prima, la seconda e la terza forma normale
- Il concetto di relazionalità e l’applicazione della normalizzazione
Assimilati questi concetti, ti risulterà più facile creare delle strutture di database in modo corretto.
Iniziamo dunque con il primo argomento di fondamentale importanza in quanto ruota quasi tutto intorno a quello.
Cos’è la chiave primaria?
In una tabella la chiave primaria è quel dato che ci permette di identificare univocamente una riga (quindi un insieme di dati) e per convenzione prende solitamente il nome id.
Una tabella contenente ad esempio degli indirizzi, può avere più righe nelle quali il nome è “Maurizio” ed il cognome è “Tarchini”. Infatti possono esserci diverse persone che si chiamano “Maurizio Tarchini”. La chiave primaria ci permette di distinguere ogni singolo record indipendentemente dalle ambiguità che possono facilmente crearsi (come persone con lo stesso nome e lo stesso cognome).
Come vedi in questa tabella i campi nome, cognome e città non sono univoci. Il nome Maurizio compare due volte come pure la città Catania. Dobbiamo quindi creare un dato che sia certamente unico, quindi una chiave primaria.
La presenza in una tabella di una chiave primaria correttamente impostata è una precondizione indispensabile all’applicazione della relazionalità (concetto che approfondiremo in un altro articolo).
Se tutto questo viene a mancare diventa alto il rischio che si produca il fenomeno dell’inconsistenza, che in poche parole significa la non affidabilità dei dati (vedremo perchè e in che modo).
Come impostare la chiave primaria?
Normalmente la chiave primaria è impostata in fase di creazione della tabella.
Il caso più classico è impostare il campo come numero intero, annunciarlo come chiave primaria ed attribuirgli la proprietà auto_increment.
`id` INT( 6 ) UNSIGNED NOT NULL AUTO_INCREMENT , PRIMARY KEY ( `id` )
In questo modo lasciamo al database il compito di gestire le chiavi primarie. Questa è una modalità molto sicura.
Il database attribuirà automaticamente un numero univoco ad ogni record. Anche qualora cancellassimo una righa, la chiave primaria di questa riga non sarà più utilizzata successivamente.
Ma questa strada, a volte, può rivelarsi un errore.
Serve un solo dato univoco
Capita di essere tanto abituati ad impostare una chiave primaria da non rendersi conto che a volte esiste già senza doverla creare. Quello che segue è un errore molto comune.
Una regola fondamentale dei database (verrà fuori altre volte) è che non dobbiamo avere dati ridondanti. In questo caso abbiamo però un dato ridondante.
Infatti non ha senso creare il campo id come dato univoco. Il codice assicurato è già, per sua stessa natura, un dato univoco.
Possiamo quindi utilizzare questo dato come chiave primaria. In questo caso non dovremo però ovviamente definire la proprietà auto_increment; il dato sarà inserito così com’é, a noi basta la certezza che sia un dato univoco. Possiamo dunque fare a meno della colonna id.
Similmente potremo utilizzare il numero di matricola come chiave primaria nell’elenco degli studenti di un’università oppure il numero di partita IVA per un elenco di aziende.
Il dato univoco può essere una combinazione di dati?
Se vogliamo proprio dirla tutta, non necessariamente la chiave primaria dovrà essere un unico dato. Qualora la combinazione di due o più dati possono identificare univocamente una riga, possiamo utilizzare quella che viene definita una chiave primaria composta.
Prendiamo ad esempio una tabella che mostri la provincia, il numero di targa ed il proprietario dell’automobile.
La combinazione tra provincia e numero da luogo ad un dato univoco e quindi alla possibile chiave primaria per questa tabella.
Conclusione
In questo articolo abbiamo iniziato ad esplorare le tecniche grazie alle quali è possibile realizzare dei database efficienti e mantenibili. Abbiamo dunque analizzato brevemente cosa sia una chiave primaria. Quanto questo dato sia fondamentale lo vedremo nei prossimi articoli. La chiave primaria è infatti la base per realizzare la normalizzazione (che vedremo nel prossimo articolo) e la normalizzazione è la base per implementare una robusta relazionalità tra le tabelle (argomento dell’ultimo articolo di questa serie).
Ringrazio capobecchino per aver segnalato un errore imporatante in questo articolo ed avermi dato modo così di correggerlo
L'autore
Articoli correlati
Potresti essere interessato anche ai seguenti articoli:
37 commenti
Trackback e pingback
-
Tweets that mention La strutturazione dei database (1/3): La chiave primaria | Your Inspiration Web -- Topsy.com
[...] This post was mentioned on Twitter by mtx_maurizio, Antonino Scarfì. Antonino Scarfì said: RT @YIW La strutturazione dei database… -
Mysql e database: la struttura e la chiave primaria | Italian webdesign
[...] questo articolo, Yourinspirationweb ci spiega cos’è la chiave primaria. Giusto un po’ di teoria per [...] -
La strutturazione dei database: la normalizzazione | Your Inspiration Web
[...] Nell’articolo precedente abbiamo trattato l’importante concetto della chiave primaria. Oggi vedremo quali sono nella teoria i principali accorgimenti (che…
tutto preciso tranne per l’esempio del CAP che non per forza può essere univoco, infatti 2 o più città possono averlo uguale e quindi non può essere considerato una chiave univoca.
per il resto complimenti spiegazioni chiara e semplice :)
Se i comuni appartengono ad un unica nazione (che era quello che volevo dire), il CAP è un dato univoco
ehm! non credo, in Italia ad esempio ci sono comuni che hanno lo stesso CAP
Cosaaa? Dici sul serio?
ad esempio come puoi veder qui in campania http://www.nonsolocap.it/campania/37-cap-provincia-di-caserta/
Caspita, ma è vero. Ma che senso ha?
Dovrò correggere: Il CAP è un dato univoco tranne che in italia
Beh, comunque è il concetto ad essere importante. Grazie per la segnalazione, vedrò come correggere
ovvio che il concetto è interessante, ti basta levare quell’esempio o integrarlo con un altro dato che potrebbe essere univoco ;)
Il Codice Fiscale può essere un dato univoco :)
Questo perché in Italia le “zone postali” non corrispondono ai comuni, infatti i comuni di grosse dimensione hanno molti CAP (poi se non metti quello preciso la posta arriva comunque)
Maurizio un veloce esempio sono Frattaminore e Crispano, entrambe provincia di Napoli, città differenti e quasi distanti, ma stesso CAP ;)
Grazie Franceso. Sì, in effetti dopo la segnalazione ho constatato questo fatto. Non pensavo fosse così… :-)
Ma vieniiiiiiiiiiii. Adesso pure i tutorial sui DB <3
Spettacolo come sempre (merito del basilico????????? :D )
Grazie tante a te e a tutta YIW per gli splendidi tutorial che sfornate :)
Se fosse merito del basilico, leggeresti solo articoli “rinsecchiti” e morenti… :-)
Bene Maurizio, è sempre buono creare un database robuto e non ridondante in modo da no appensatire il server e far vedere il sito velocemente.
Grazie Luca
Bell’articolo! Ci voleva un pochino di precisazioni riguardo queste tematiche. I neofiti potrebbe essere confusi dal passo in cui il cap è dichiarato chiave primaria. Il cap non è un dato univoco, in quanto più persone possono avere lo stesso cap, proprio come nell’esempio sopra riportato a quelle righe.
Certo, io mi riferivo ad una tabella così come è esposta, contenente unicamente i comuni ed il CAP (e naturalmente, come ho detto prima, con comuni della stessa nazione)
Caro Mau, anche se ormai ti trovi in territorio teutonico devi e dovrai sempre fare i conti con i paradossi italiani :)
maurì, basta cambiare la tabella dell’esempio e utilizzare una tabella con partita iva e aziende per spiegare il concetto.
Ho modificato l’esempio. Chiedo scusa ma ero assolutamente convinto che il CAP fosse un dato univoco. :-)
In ogni caso che conta è il principio
Ciao Maurizio complimenti per l’articolo, siete davvero una grande risorsa, yiw for president! :)
In effetti stavamo pensando di candidarci per le prossime elezioni: Your Inspiration Party :-)
Io avrei il ministero dell’agricoltura e del promuovimento del basilico.
Ok ragazzi, comunque facciamo che questa storia del CAP non diventi come il basilico…
Grazie mille. Ormai YIW sta diventando una fonte a 360°, e questa iniziativa sulla spiegazione dei database arriva al momento giusto: proprio stamattina ho confermato a me stesso che li avrei cominciati a studiare.
Volevo solo chiederti: posso cominciare la mia preparazione dai tuoi articoli oppure ci sarebbe prima qualche livello più basso da conoscere?
Questa serie di articoli é piuttosto teorica. Non mostrerò nessuna query per intenderci.
Puoi certamente seguirli, in questo modo (come ho detto all’inizio) potrai partire con il piede giusto.
Ottimo. Come sempre d’altronde. ;-)
Grazie Giovanni
e’ stato traumatico scoprire che il CAP non è un dato univoco…città con lo stesso CAP??????O.o….cmq…interessantissimo l’articolo..complimenti Maurizio!!!!:)
Grazie Silvia.
Non so perchè tutti continuate a parlare di questo CAP che nemmeno è menzionato nell’articolo :-)
Beh, almeno è servito a qualcosa. Mi sembra che siano più le persone che non lo sapevano che quelle che lo sapevano.
quindi non sono pazzo…dove l’ha visto il cap capobecchino?
…nelle prime tre lettere del suo nickname =)
scherzi a parte… maurizio erroneamente aveva fatto un esempio di dato univoco utilizzando il CAP (codice avviamento postale) che – dopo la corretta e tempestiva segnalazione di capobecchino – ha provveduto a correggere =)
ma dai … l’ho sognato :P :P :P
Su questa frase non sono d’accordo:
“Il database attribuirà automaticamente un numero univoco ad ogni record. Anche qualora cancellassimo una righa, la chiave primaria di questa riga non sarà più utilizzata successivamente.
Ma questa strada, a volte, può rivelarsi un errore”.
Inserire una sequence (o contatore) è la strada più sicura e non si rivela mai un errore. Al contrario inserendo il codice come chiave è un errore (non teorico). Esempio se devo cambiare un codice (e la cosa succede più spesso di quanto si pensi) cosa faccio cambio tutte le relazioni?