Argomenti:
- Il Modello Entità Relazioni
- Il modello Relazionale e le regole di Cood
- Caso di studio
Modello Entità Relazioni
Uno dei modelli concettuali più importanti nella realizzazione delle basi di dati è il modello Entità Relazioni. Esso si basa sull’associazione fra grandezze informative. Un’entità è un contenuto informativo su un oggetto o un soggetto. Attraverso un’entità è possibile fornire un’informazione completa sulla grandezza informativa che si sta gestendo. Fra entità differenti si possono instaurare anche legami associativi. Ad esempio cliente possiede conto corrente che può eseguire movimenti. In questo esempio vi è un’associazione fra il cliente di una banca e il suo conto corrente. E’ un’associazione obbligatoria poiché ogni conto corrente deve avere un intestatario. Nella seconda parte invece l’associazione è opzionale infatti i conti correnti possono eseguire movimenti ma non è obbligatorio. Il modello E-R non fa altro che definire le associazioni fra le entità per gestire al meglio la base di dati. Ogni entità è caratterizzata dal possedere attributi. Gli attributi sono le caratteristiche delle informazioni che si stanno gestendo. Un attributo è detto semplice se il dominio è semplice (ovvero l’insieme di appartenenza del dato è semplice intero, reale, stringa,ecc), composto se l’attributo è una struttura dati omogenea, complessa se è costituita da sottoattributi. Ogni associazione possiede una cardinalità o grado di molteplicità.
Esistono associazioni uno a uno, uno a molti, e molti a molti. Nel primo caso ad ogni elemento del primo insieme corrisponde un elemento del secondo e viceversa. Nella relazione 1 a M ad ogni elemento del primo insieme corrispondono più elementi del secondo insieme, ma non il contrario. Per finire nella relazione M a N ad ogni elemento del primo insieme corrispondono più elementi del secondo insieme e viceversa.
Esempi di relazioni uno a uno Marito – Moglie, Conto Corrente – Saldo. Esempi di associazioni uno a molti Conto Corrente – Movimenti. Associazioni Molti a molti possono essere fra cugini di una famiglia, fra alunni e docenti. Per poter gestire le associazioni si devono introdurre il concetto di chiave primaria come l’insieme di uno o più attributi che identificano in modo univoco dei valori nell’entità (istanza).
Si definisce chiave esterna uno o più attributi che nell’entità di partenza sono chiave primaria mentre in quella di arrivo identificano una n-pla di istanze. Nella associazione molti a molti si semplifica creando un’entità di passaggio che permetta di decomporre l’associazione in due 1-M.
Vediamo come esempio la gestione dei conti di una banca. L’entità come sopra citato sono tre Cliente, Conto, Movimenti. Esprimendo il modello concettuale E-R si ha:
Tale modello E-R presenta una relazione M a N fra Cliente e Conti, e una relazione 1 a N fra Conto e Movimento, questo perchè un conto corrente può essere cointestato e un cliente può possedere più conti correnti nella stessa banca. La relazione M a N può essere semplificata con relazione che contiene attributi.
Il modello E-R risultante potrebbe essere questo riportato sotto:
E’ stata introdotta l’entità intestazione, che semplifica la relazione M a N in una 1 a N e una 1 a 1, in quanto più persone possono essere presenti in un’intestazione di conto corrente, e un conto corrente è legato ad una singola intestazione. .
Modello Relazionale
Una volta definito il modello Entità – Relazioni occorre definire il modello Relazionale. La caratteristica principale del modello relazionale è quella di essere un modello logico per rappresentare le Entità e le Associazioni che legano le stesse mediante una rappresentazione tabellare. Per realizzare il modello Relazionale, occorre tener presenti alcune semplici regole di derivazione come per altro illustrato nelle 12 Regole di Cood.
Le regole di Cood danno un’idea precisa del metodo per derivare in modo corretto il modello logico.
- Regola 0: il sistema deve potersi definire come relazionale, base di dati e sistema di gestione.
Affinché un sistema possa definirsi sistema relazionale per la gestione di basi di dati (RDBMS), tale sistema deve usare le proprie funzionalità relazionali (e solo quelle) per gestire la base di dati.
- Regola 1: l’informazione deve essere rappresentata sotto forma di tabelle.
Le informazioni nel database devono essere rappresentate in maniera univoca, e precisamente attraverso valori in colonne che costituiscano, nel loro insieme, righe di tabelle.
- Regola 2: La regola dell’accesso garantito o delle chiavi primarie.
Tutti i dati devono essere accessibili senza ambiguità. Ogni singolo valore scalare nel database dev’essere logicamente indirizzabile specificando il nome della tabella che lo contiene, il nome della colonna in cui si trova e il valore della chiave primaria della riga in cui si trova.
- Regola 3: trattamento sistematico del valore NULL.
Il DBMS deve consentire all’utente di lasciare un campo vuoto, o con valore NULL. In particolare, deve gestire la rappresentazione di informazioni mancanti e quello di informazioni inadatte in maniera predeterminata, distinta da ogni valore consentito (per esempio, “diverso da zero o qualunque altro numero” per valori numerici), e indipendente dal tipo di dato. Queste rappresentazioni devono inoltre essere gestite dal DBMS sempre nello stesso modo.
- Regola 4: dizionario del modello relazionale.
La descrizione della struttura del database e degli oggetti che lo compongono deve avvenire ad un livello logico, tramite un dizionario di metadati, e questo dizionario deve essere accessibile agli utenti del Database con le stesse modalità e lo stesso linguaggio di interrogazione utilizzato per accedere ai dati.
- Regola 5: accessibilità dei dati.
Tutti i contenuti del database devono essere accessibili attraverso almeno un linguaggio relazionale (come ad esempio l’SQL) che abbia le seguenti caratteristiche:
- abbia una sintassi lineare (ovvero le cui istruzioni possono essere semanticamente interpretate con una semplice lettura da sinistra verso destra)
- possa essere utilizzato sia in forma interattiva che dall’interno di applicazioni
- supporti operazioni di definizione e di manipolazione dei dati, le regole di sicurezza e i vincoli di integrità del database.
- Regola 6: aggiornamento delle viste di dati.
In un database relazionale si possono creare viste che forniscono l’accesso a specifici subset di informazioni. Laddove il contenuto in termini di dati di queste viste è concettualmente modificabile, lo deve anche essere nella pratica.
- Regola 7: manipolazione dei dati ad alto livello.
Da un database possiamo reperire informazioni multiple costituite da set di dati provenienti da più righe e/o più tabelle. Gli stessi set di dati, piuttosto che le singole informazioni, devono anche poter essere inseriti, aggiornati e cancellati.
- Regola 8: indipendenza dalla rappresentazione fisica.
La struttura logica di un database deve essere indipendente dalle strutture di memorizzazione fisica: modifiche al piano fisico (come i dati vengono memorizzati, su quali unità, con quale organizzazione, ecc.) non devono richiedere un cambiamento alle modalità di accesso al database.
- Regola 9: indipendenza dalla rappresentazione logica.
Le modifiche al livello logico (tabelle, colonne, righe, chiavi primarie, …) non devono richiedere cambiamenti non giustificati alle applicazioni che utilizzano il database.
- Regola 10: i vincoli logici sui dati devono essere memorizzati nel Database.
I vincoli di integrità propri delle entità e delle relazioni, le regole di sicurezza e le restrizioni di accesso devono essere definiti nel dizionario del database e sono quindi separati dalle applicazioni che lo utilizzano. Deve quindi essere possibile modificare tali vincoli senza inutilmente interessare le applicazioni esistenti.
- Regola 11: indipendenza di localizzazione.
La distribuzione di porzioni del database su una o più allocazione fisiche o geografiche deve essere invisibile agli utenti del sistema. Le applicazioni esistenti devono continuare ad operare con successo quando i dati esistenti vengono ridistribuiti in modo diverso.
- Regola 12: regola di non sovversione:
Gli strumenti di accesso ai dati non devono poter annullare le restrizioni del database, per esempio aggirando i vincoli di integrità, le relazioni o le regole di sicurezza.
Queste regole sono state fissate nell’articolo di E. F. Codd, “Is Your DBMS Really Relational ?”, pubblicato sul magazine Computerworld nel 1985 (la prima parte il 14 ottobre e la seconda il 21 ottobre).
Dalle regole enunciate è possibile estrapolare un procedimento per creazione di un modello relazionale che possono essere sintetizzate in un procedimento semplice e univoche.
Prima di esporre in modo sintetico del regole di derivazione partendo dal modello E-R di esempio descriviamo le “Relazioni” ovvero le Tabelle. Prestare attenzione alla terminologia. Nel modello E-R parliamo di Entità e di Relazioni o Associazioni. Nel modello relazionale le tabelle sono nominate come “Relazioni”..
Definire le Relazioni nel modello logico è molto semplice e segue una nomenclatura standard. Ogni entità ha un nome e la relazione avrà lo stesso nome.
Ogni attributo dell’Entità è un elemento della relazione (colonna della relativa tabella); la colonna o le colonne che avranno il ruolo di chaive primaria sono sottolineate, Le chiavi esterne sono inserire nella Relazione di destinazione come ulteriore campo e per convenzione hanno una doppia sottolineatura o in modo semplice le indichiamo di colore rosso.
Quindi in sintesi da ogni Entità deve derivare una tabella, ad ogni attributo corrisponde una colonna, Le Entità che hanno una relazione possiedono nella Relazione che gioca il ruolo N la chiave esterna come come colonna aggiuntiva.
In sostanza in riferimento all’esempio:
Cliente ( nome, cognome, data_nascita, codice_fiscale)
Intestazione (codice_fiscale,codice_conto)
Una volta scritte le relazioni la fase successiva è la definizione della struttura logica delle tabelle associate alla relazioni create.
La fase successiva è la creazione e il dimensionamento delle tabelle corrispondenti alle entità, La progettazione del modello logico consiste nella definizione delle strutture dati idonee al problema posto mettendo in evidenza legami fra le entità. Se adoperiamo l’esempio esposto avremo tre tabelle così composte e definite:
| Nome Attributo | Tipo | Note |
| Data di Nascita | Data | |
| Codice Fiscale | 16 caratteri | Chiave Primaria |
| Cognome | 20 caratteri | |
| Nome | 20 caratteri |
per la tabella Intestazione si ha:
| Nome Attributo | Tipo | Note |
| Codice Fiscale | 16 Caratteri | Chiave Esterna |
| Codice Conto | 10 Caratteri | Chiave Primaria |
questo per la tabella clienti. Analogamente per l’entità conti e movimenti si hanno le seguenti tabelle:
| Nome | Tipo | Note |
| Codice Conto | 10 caratteri | Chiave Primaria e Chiave Esterna |
| Saldo | Reale | 2 cifre decimali e 15 intere |
| In_rosso | Logico | Vale Si se saldo negativo |
mentre per l’entità Movimenti si ottiene:
| Nome | Tipo | Note |
| Codice_Movimento | Intero auto incrementato | Chiave Primaria |
| Codice Conto | 10 caratteri | Chiave Esterna |
| Data_Movimento | Data in gg/mm/aaaa | |
| Importo | Reale | 2 cifre decimali e 15 intere |
| Tipo_Movimento | 20 caratteri |
Alle tabelle create è possibile aggiungere una colonna con le descrizioni dettagliate.