Questo modello, definito come abbiamo detto da Edgar Codd nel suo celebre articolo "A Relational Model of Data for Large Shared Data Banks" pubblicato su Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387 è basato sul concetto algebrico di relazione e sulla teoria degli insiemi, che viene applicata agli insiemi di dati.
Supponiamo di avere N = 3 insiemi di dati, per esempio un insieme
di Cognomi (C), un insieme di Date di nascita (D), un insieme di numeri
di Telefono (T).
L'algebra definisce come prodotto cartesiano di questi insiemi CxDxT
l'insieme di tutte le possibili triple ottenute prendendo il primo dato
da C, il seconda da D e il terzo da T.
CxDxT = { (c,d,t) / c e C, d e D, t e T}
Naturalmente di questo insieme caotico di dati non ce ne faremmo
niente: noi abbiamo bisogno che ad ogni cognome venga associata la
giusta data di nascita e numero di telefono: in questo ci viene in
aiuto il concetto di relazione, che in algebra si definisce
come sottoinsieme del prodotto cartesiano:
R CxDxT
In pratica di tutte le possibili terne ottenute combinando a caso
cognomi, date e numeri di telefono, sceglieremo solo quelle in cui i
dati sono effettivamente in relazione tra loro.
In questo modo una relazione definita su questi insiemi
dominio, può essere interpretata come un archivio che
contiene una rubrica telefonica. (la data di nascita non è in questo
caso particolarmente utile ma si tratta solo di un esempio).
Gli elementi della relazione (in pratica i record del nostro
archivio) nell'esempio fatto sono terne di dati, ma possono avere un
numero qualunque di elementi e vengono chiamati t-ple (o tuple),
e la relazione stessa viene detta tabella.
Il numero di colonne della tabella è uguale al numero degli insiemi
dominio, e viene detto grado della relazione.
Il numero di righe della tabella viene invece detto cardinalità
della relazione.
Nel modello relazionale la relazione implementa quindi il concetto di entità del Data Base.
Nello stesso tempo, se vogliamo associare delle entità tra di loro,
possiamo sempre creare delle relazioni in cui compaiano i dati che ci
interessano insieme: per esempio i dati di un articolo e quello del suo
fornitore.
Per cui la relazione implementa anche il concetto di associazione
tra entità.
Una base di dati relazionale può quindi definirsi come un insieme di relazioni (o tabelle)
Le relazioni devono rispettare le seguenti regole:
Il concetto di chiave in quanto fattore di ordinamento e di ricerca
è estraneo alla teoria dei DB relazionali; anzi è detto esplicitamente
che l'ordine delle t-ple non è rilevante all'interno della tabella.
Dato che però nella pratica le tabelle vengono realizzate con la
tecnica degli archivi indicizzati, bisogna fare i conti con vari
concetti legati alle chiavi, che qui riassumiamo brevemente perchè
fanno più strettamente parte dela teoria degli indici.
Una chiave (o indice) è un dato composto da uno o più attributi della entità, che viene utilizzato per riordinare o per velocizzare l'accesso alle t-ple.
Per progettare un DB relazionale è necessario prima di tutto
definire le entità che lo compongono. A ciascuna di queste
entità corrisponde una relazione, cioè un archivio; nel linguaggio dei
DB relazionali di solito questa struttura viene chiamata tabella.
Successivamente si passerà ad esaminare quali associazioni (o
collegamenti) ci sono fra queste entità.
Ci sono solo tre possibili tipi di relazioni tra due entità
Lo schema concettuale di un Data Base si rappresenta graficamente tramite il diagramma Entità-relazione.
Una volta definito lo schema concettuale, nella stesura dello schema logico per realizzare le associazioni tra entità si usano le cosiddette chiavi esterne (foreign keys). Una chiave esterna è la chiave primaria di un'altra entità : dato che la chiave primaria identifica univocamente una singola istanza dell' entità, in questo modo si crea un collegamento ad un determinato record.
Per realizzare correttamente le associazioni bisogna seguire alcune semplici regole :
A volte si possono incontrare associazioni che coinvolgono una sola
entità (ricorsive o riflessive)
In questo caso si seguono comunque le regole di derivazione usando una
chiave esterna se il collegamento è 1-1 o 1-N, oppure creando una nuova
relazione se l'associazione è di tipo N-M.
Consideriamo le relazioni di parentela che possono verificarsi tra le persone registrate in una anagrafe
Per esempio possiamo prendere in considerazione il matrimonio,
che è una associazione 1-1.
Secondo le regole di derivazione, useremo una chiave esterna in
entrembe le entità per indicare il coniuge:
ANAGRAFICA(CodiceFiscale, Cognome, Nome, DataNascita,Indirizzo,
Citta, CodiceConiuge)
Oppure la relazione padre-figlio che è 1-N.
iun cui useremo una chieve esterna nelle entità dei figli per indicare
il padre:
ANAGRAFICA(CodiceFiscale, Cognome, Nome, DataNascita,Indirizzo,
Citta, CodicePadre)
Infine, se vogliamo prendere in considerazione i fratelli,
avremo una associazione N-N.
In questo caso, dobbiamo creare una seconda relazione:
ANAGRAFICA(CodiceFiscale, Cognome, Nome, DataNascita,Indirizzo,
Citta)
FRATELLI(Contatore, CodiceFiscale1, CodiceFiscale2)
Nella relazione FRATELLI vengono indicate tutte le coppie di
fratelli
Se l'associazione invece è multipla, cioè coinvolge 3 o più tabelle, si ricorre sempre ad una nuova relazione che contiene come chiavi esterne tutte le chiavi primarie della relazioni associate.
Consideriamo la relazione tra docenti, materie e classi
Derivazione:
DOCENTI(CodiceFiscale, Cognome, Nome, DataNascita,Indirizzo,
Citta)
MATERIE(Codice, Descrizione)
CLASSI(Numero, AnnoCorso, Indirizzo, Sezione, Sede, Piano, Aula)
ORGANICO(Contatore,Docente, Materia, Classe, Ore)
Il passaggio in prima forma normale è obbligatorio per
soddisfare la coerenza e la correttezza delle tabelle di un DB
relazionale
Dopo aver progettato lo schema concettuale e quello logico, bisogna
quindi accertarsi che tutti gli attributi delle varie entità siano in
forma semplice.
Se non lo sono, possono verificarsi due casi:
Il passaggio in seconda forma normale avviene solo se ci sono
tabelle con chiavi composte.
In questo caso bisogna eliminare le dipendenze parziali dalla chiave,
separando in due tabelle distinte gli attributi che dipendono solo da
una parte della chiave.
Nella nuova tabella viene riportata come chiave primaria la parte della
chiave interessata alla dipendenza
Es: RIGHE (Numero, CodArticolo, Descrizione,
Prezzo, Quantita)
RIGHE (Numero, CodArticolo,
Quantita)
ARTICOLI (CodArticolo,
Descrizione, Prezzo)
Con questo passaggio, simile al precedente , si eliminano le
dipendenze indirette dalla chiave primaria. E' in genere da questo
passaggio che scaturiscono le cosiddette tabelle di look-up,
che contengono i dati che dipendono indirettamente dalla chiave
primaria; il dato da cui dipendono viene usato come chiave primaria
nella nuova tabella.
Es: FATTURA (Numero, Data, CodCliente, Denominazione,
Indirizzo, Cap, Citta)
FATTURA (Numero, Data,
CodCliente)
CLIENTE (CodCliente,
Denominazione, Indirizzo, Cap, Citta)
Sono anche detti vincoli di colonna.
Si tratta di condizioni che vengono imposte a seconda del tipo di informazione: per esempio, se si tratta di una temperatura, si può imporre il vincolo che sia compresa tra -20 e +50, se il dato rappresenta l'età, di una persona, che sia inferiore a 110, se contiene un giorno della settimana che sia lunedì, o martedì, ecc...
Un tipico vincolo di dominio è costituito anche dalla clausola not null.
Detti anche vincoli di riga, sono condizioni che riguardano i dati di una stessa t-pla
Per esempio, se in una stessa riga abbiamo la data di nascita e la data di morte di una persona, la prima dovrà essere inferiore alla seconda-
Sono condizioni che riguardano l'intera tabella.
Tipicamente, la clausola unique, applicata a una chiave, che specifica che all'interno della tabella il valore della chiave non può comparire più di una volta.
N.B.: Anche la clausola primary key implica un vincolo di unicità
Sono detti anche vincoli interrelazionali e riguardano i collegamenti tra i dati di diverse tabelle.
Vengono usati per legare il valore di una colonna (chiave esterna) in una tabella, a quelli di una colonna
corrispondente in un'altra tabella, in modo che non sia possibile inserire valori inesistenti.
Tali vincoli vengono imposti con la clausola foreign key ...references
![]() |
![]() |
![]() |