Le entità di un database
Le entità sono gli oggetti principali del database. Un’entità rappresenta un gruppo omogeneo d’informazioni.
Supponiamo di voler progettare un database per una biblioteca, possiamo individuare come entità il libro, che è l’oggetto preponderante.
Ma la biblioteca non è solo un magazzino di libri, nel modello dobbiamo inserire il concetto di biblioteca come “servizio” ed aggiungere l’entità “utente”.
Tornando al libro, riflettiamo sul fatto che il libro è scritto da uno o più autori, è pubblicato da una casa editrice e appartiene ad un genere; quindi sono nate altre entità autore, casa editrice e genere.
Frequentando una biblioteca o chiacchierando con qualcuno che ci lavora sicuramente ci accorgiamo che di entità ce ne sono molte di più, ma per acquisire familiarità con le basi di dati, possiamo accontentarci di un modello di biblioteca in miniatura.
Vediamo ora in cosa consiste un’entità; partendo dall’esempio del libro: per descrivere un libro abbiamo bisogno di un titolo, di un autore, di un genere, di una casa editrice, di una data di pubblicazione, etc. Tutte queste informazioni che costituiscono l’entità libro, si chiamano attributi.
Le relazioni
Le entità non sono oggetti a se stanti ma sono in relazione tra loro. in un database ad esempio i libri sono legati ai generi; ogni libro appartiene ad un genere ed esistono molti liberi diversi dello stesso genere. Un libro è scritto da uno o più autori ed ogni autore può scrivere più libri. Figura 1. Modello entità/relazione
I libri sono presi in prestito dagli utenti; un utente può prendere in prestito uno o più libri e un libro può essere preso in prestito solo da un utente per volta.
Modellare un database può non essere semplice, bisogna scegliere bene quali elementi sono entità, quali attributi e quali relazioni.
Dopo aver introdotto il concetto di entità, scendiamo nel dettaglio della realizzazione. Per rappresentare un’entità con Access utilizziamo una tabella. Ogni colonna corrisponde ad un attributo dell’entità, (detto anche campo) e ogni riga della tabella (detta anche record) rappresenta un’istanza dell’entità (un caso particolare)
Volendo rappresentare ad esempio l’entità persona, possiamo impostare
una tabella che abbia come colonne gli attributi di una persona (nome, cognome, data di nascita, indirizzo). Ogni riga (o record) corrisponde ad una persona particolare.
Figura 1. Tabella “persona”
Gli attributi (o campi) rappresentano tipi diversi di informazione, ad esempio possiamo avere campi numerici o campi di testo, oppure campi per le date. In gergo informatico questa natura diversa dell’informazione si indica con la parola “tipo”. Anche Access lavora con i tipi: il nome dell’autore è di tipo testo (o stringa: sequenza di caratteri alfanumerici), la data è di tipo “data”, l’anno di pubblicazione può essere un tipo “numerico intero” e così via.
I tipi dei campi della tabella “persona”
È importante che i dati siano coerenti con i tipi corrispondenti, ad esempio, se nel campo data di nascita dell’autore inseriamo un numero come 01121980, commettiamo un errore di coerenza.
Lo schema della figura è quello che visualizziamo quando chiediamo di visualizzare la struttura della tabella.
Nella visualizzazione della struttura possiamo impostare, visualizzare e
modificare il tipo degli attributi; ad esempio nel campo nome inseriremo solamente delle stringhe di caratteri pertanto il tipo idoneo è il tipo testo; all’attributo data abbiamo assegnato il tipo data. Approfondiremo i tipi più avanti nella guida.
Se consideriamo un lungo elenco di persone, come l’elenco del
telefono ad esempio, risulta plausibile trovare omonimie tra le persone,
questo significa che alla coppia di informazioni nome, cognome corrisponde più di un record.
Risulta indispensabile allora realizzare un meccanismo che ci permetta di idenitificare in modo univoco i record, anche se hanno tutti i campi uguali tra loro.
La “chiave primaria” di un database
La soluzione è quella di inserire nella tabella un nuovo campo che funzioni da chiave primaria; è il più importante tra tutti gli attributi e garantisce l’individuazione di un determinato record all’interno di una tabella.
Tipicamente si tratta di un numero intero che viene incrementato automaticamente da Access ogni volta che aggiungiamo un record.
Non è sempre indispensabile creare un campo a parte; a volte esiste già un campo che è univoco per natura (ad esempio il codice fiscale) oppure si riescono a raggruppare un gruppo di più campi che presi tutti assieme costituiscono un elemento univoco. Ma è molto più frequente, specie nelle piccole applicazioni, che la chiave primaria sia un campo numerico, spesso indicato come campo ID (identificatore).
Tabella con chiave primaria
L’unicità di questo campo viene inoltre garantita dal fatto che, quando cancelliamo un record, il suo ID non è più riutilizzato. Ad esempio, se cancelliamo l’autore con identificativo 23, quella chiave viene persa per sempre.
La “chiave esterna”
Riportiamo il concetto di chiave primaria nel contesto della biblioteca: possiamo immaginare che ogni libro nella tabella dei libri sia riconoscibile univocamente dagli altri grazie al suo “ID”. Sarà molto comodo poter indicare solo questo numeretto per raggiungere sicuramente un certo testo.
Abbiamo anche detto che le tabelle possono essere messe in relazione tra loro. Prendiamo ad esempio la relazione tra libro e autore:
Libro -> scritto da -> Autore
Supponiamo che un libro sia scritto da un autore e che un autore
abbia scritto diversi libri. Secondo il discorse della chiave primaria
la tabella Autore avrà un codice ID che identifica
univocamente ogni autore. Quindi, per associare un libro ad un autore
possiamo prevedere un campo, nella tabella Libro che contenga il codice dell’autore. Questo campo viene detto chiave esterna.
Possiamo pensare di effettuare lo stesso ragionamento anche per la relazione edito da con la casa editrice: il campo casa editrice nella tabella Libro è una chiave esterna e corrisponde ad un campo ID (chiave primaria) della tabella case editrici.
Tabella con chiavi esterne
Vantaggi pratici
Discorsi concettuali a parte il lavoro con le relazioni semplifica anche alcuni aspetti più pratici. Ad esempio possiamo essere certi che se inseriamo 100 libri della stessa casa editrice, scrivendo il nome 100 volte commetteremo qualche errore e comunque potremmo non scriverlo in modo identico e coerente ogni volta.
Se invece selezioniamo lo stesso nome da un elenco possiamo sbagliare editore me non avere lo stesso nome scritto male o in modo diverso. Questo garantisce miglior coerenza e semplicità di reperimento delle informazioni. Se, ad esempio cercassimo l’editore “Mondadori” il sistema non capirebbe che “Mondadori”, “mondadori”, “MONDADORI” e “Mondadorri” sono la stessa cosa.
Prendiamo anche ad esempio la modifica di un dato come l’indirizzo dell’editore. Ci convinciamo facilmente che è molto più semplice modificarlo una volta sola (mantenendo inalterato l’ID) che riscriverlo su centinaia di record dei libri.
