Conversione tra i Modelli part.2

La Chiave primaria

Quando si crea un database Relazionale, come Microsoft Access, e si definiscono delle tabelle collegate, la scelta di una chiave primaria per una relazione è molto importante. Poiché il Modello Relazionale viene implementato direttamente all’interno del database, bisogna tenere presente che gli RDBMS indicizzano le chiavi primarie in modo da velocizzare notevolmente la ricerca di una specifica riga all’interno delle tabelle.

Esistono quindi dei casi in cui è opportuno inserire delle chiavi primarie "surrogate", realizzate cioè con campi che non contengono un particolare attributo della tupla (ad esempio nome e cognome per una tabella "studenti"), ma che vengono creati ad-hoc per far fronte a due comuni scenari:

· la difficoltà di avere n campi che garantiscano l’univocità della chiave

· la complessità di gestione per la macchina di chiavi complesse.

Ad esempio se riprendiamo l’esempio del Film immaginiamo che esistano due attori diversi, ma con lo stesso nome e cognome. Se usassimo la coppia nome e cognome come chiave primaria potremmo inserire nella nostra base di dati uno solo di essi. Poiche pero gli omonimi esistono, nella realtà spesso si utilizza il codice fiscale (è già una chiave surrogata!).

Supponiamo di avere una chiave formata da parecchi campi e ci sono altre tabelle che sono collegate alla tabella in questione attraverso chiavi esterne, ovviamente con lo stesso numero di campi. Ma cosi facendo le prestazioni del sistema possono subire un degrado.

Allora è sufficiente inserire un nuovo campo, costituito da un numero intero crescente e chiamato ID ovvero "identificativo", che diventa la chiave primaria della tabella. Gli elementi della tabella verranno identificati quindi da un semplice numero intero.

In questo modo la chiave primaria sarà costituita da un unico campo, contenente un numero facile da gestire per la macchina. Inoltre non ci saranno rischi di chiavi duplicate poiché basta incrementare tale numero ad ogni inserimento di una nuova riga nella tabella.

Normalizzazione del database

Quando ci si appresta a trasformare il Modello E-A nel Modello Relazionale anche se si presta particolare attenzione, possono sorgere dei problemi. Esistono a riguardo dei sistemi di verifica che, applicati sul Modello Relazionale, stabiliscono il grado di normalizzazione della stessa, ovvero il grado di immunità alle ridondanze ed alle inconsistenze dei dati.

Il processo di normalizzazione serve a verificare la struttura della base di dati ed eventualmente indica le relazioni contenenti attributi a ben vedere indipendenti. Questo processo si effettua attraverso la suddivisione dei dati tra Tabelle tra loro collegate. Dal discorso sinora fatto sembra quindi che la qualità di una base di dati aumenti all’aumentare della suddivisione dei dati in relazioni. La questione in realtà è più complessa poiché più si suddividono i dati in relazioni e più è oneroso il compito di ricostruire le informazioni originarie e quindi si può presentare una riduzione della velocità nel reperimento dei dati.

Si parla di denormalizzazione, l’operazione che porta ad accorpare attributi appartenenti a relazioni diverse in un’unica relazione.

Nasce quindi la necessità di equilibrare la normalizzazione dei database ad un livello soddisfacente sia per la gestione dei dati che per la velocità di reperimento degli stessi.

Se hai delle domande o precisazioni che vuoi approfondire mandami una mail all’indirizzo info@creaprogrammando.com

A presto

Paolo Bellesia

P.s. Se ancora non lo hai fatto e vuoi scaricare il primo Special Report gratuito "Crea il tuo programma" iscriviti nel box a fianco potrai cosi cominciare a progettare in modo semplice e divertente i tutti i tuoi programmi. Inoltre riceverai le indicazioni di tutti gli articoli che periodicamente inseriamo nel Blog.

Conversione tra i modelli

Abbiamo visto nei precedenti articoli due tipi di modelli: il modello Entità-Associazione ed il modello Relazionale. Vediamo le regole di base per trasformare il nostro progetto dal modello E-A a quello Relazionale:

1. Per ciascuna entità del modello E-A, creiamo una tabella i cui campi sono gli attributi dell’entità stessa.

2. Nel caso ci sia un Attributo Multivalore per una entità , come il caso delle lingue per un film, bisogna creare una nuova tabella che identifica l’attributo Multivalore e una relazione che collega l’entità con la nuova tabella. La chiave esterna inserita nell’entità sarà la chiave primaria dell’attributo.

3. Per ogni Entità debole, che collega l’entità primaria, bisogna creare una relazione che li collega. La chiave esterna sarà uguale alla chiave primaria dell’entità principale.

4. Le relazioni tra due Entità aventi cardinalità 1:1 verranno convertite creando due tabelle distinte, collegate da una relazione. Le chiavi di collegamento potranno essere indifferentemente tra le due chiavi primarie. Conviene comunque analizzare la situazione migliore, nei vari casi.

Ad esempio nel caso di figura, conviene avere come chiave primaria quella relativa alla tabella dell’Auto Aziendale, collegata alla chiave esterna della tabella Dipendente

5. Anche nel caso di due entità aventi cardinalità 1:N è necessario creare due tabelle distinte, collegate tra loro da una relazione. Le chiavi di collegamento saranno come chiave primaria quella sul lato 1 mentre la chiave esterna quella sul lato N

6. Ogni associazione di tipo M:N bisogna sostituirla con due associazioni M:1 e 1:N, introducendo una nuova relazione e tabella. Anche i collegamenti tra le chiavi riprenderanno le indicazioni viste nel punto 5. Questa nuova Tabella potrà avere degli attributi.

Naturalmente questi elementi di teoria saranno chiariti quando cominceremo a sviluppare concretamente un progetto.

Se hai delle domande o precisazioni che vuoi approfondire mandami una mail all’indirizzo info@creaprogrammando.com

A presto

Paolo Bellesia

P.s. Se ancora non lo hai fatto e vuoi scaricare il primo Special Report gratuito "Crea il tuo programma" iscriviti nel box a fianco potrai cosi cominciare a progettare in modo semplice e divertente i tutti i tuoi programmi. Inoltre riceverai le indicazioni di tutti gli articoli che periodicamente inseriamo nel Blog.

Il Modello Relazionale

Continuiamo anche in questo articolo la progettazione di un Database Access, partendo dalle basi, cioè dal trasformare una idea in un modello effettivamente realizzabile come Database.

Abbiamo visto che Access è un Database Relazionale, quindi il passaggio che vedremo oggi riguarda proprio la creazione di un Modello Relazionale per il nostro progetto, in modo da organizzare la nostra Base dati nel migliore dei modi.

Il Modello Relazionale rappresenta la struttura del database attraverso la creazione di tabelle collegate tra loro dalle relazioni:

- Le tabelle sono costituite da diversi campi (colonne), che definiscono gli attributi della tabella, e da un insiemi di righe (tuple) che definiscono l’insieme di valori (Record) per quell’elemento
- Le relazioni sono i collegamenti tra due o più tabelle che ne identificano i legami tra le righe

Uno o più campi di una relazione formano la chiave primaria (Primary Key) della tabella, come per le entità del Modello ER. Abbiamo visto che la chiave primaria ha la proprietà di identificare univocamente un record in una tabella, come ad esempio il Codice fiscale per un individuo, questo ci permette di collegare un record di un’altra tabella in modo inequivocabile. In questa seconda tabella possono esserci particolari campi, che prendono il nome di chiavi esterne (Foreign Key), il cui compito è quello di realizzare legami logici tra le relazioni.
Il collegamento tra una chiave esterna e la chiave primaria di due tabelle, realizza l’associazione tra le due tabelle, in modo che la chiave esterna contiene dei dati che si riferiscono alla chiave primaria, creando così un legame logico tra le tuple delle due tabelle.

Per capire meglio vediamo un esempio grafico, consideriamo il caso si voglia costruire un indirizzario di contatti, e quindi memorizzare l’indirizzo delle aziende contattate. Ogni indirizzo è definito dai seguenti campi: Via, Numero, Città, Cap, Prov.

All’interno di questo insieme di informazioni, inserendo gli indirizzi delle aziende, esistono dei campi che vengono ripetuti frequentemente, come CAP Città e Prov, i quali poi sono anche collegati fra loro. Quindi è lecito pensare di non scriverli per ogni azienda che deve essere inserita, ma creare una tabella a parte in cui inserirli una sola volta, per poi collegare questa alla tabella delle aziende, attraverso una RELAZIONE.

Le Tabelle vengono rappresentate tramite rettangoli divisi in celle, ogni cella rappresenta un campo della relazione. Il collegamento tra le due tabelle è una relazione e collega la chiave primaria (PK) della tabella Localita, con la chiave esterna (FK) nella tabella Azienda. Entrambe le chiavi hanno lo stesso nome IDLoc, non perché è obbligatorio, ma per facilitarne la comprensione.


Per comprendere ancora meglio l’efficacia della metodologia, sviluppiamo l’esempio con dei dati effettivi. Cominciamo analizzando una tabella dove non si è creata nessun modello relazionale:

Come si può vedere si aper la Maserati spa che per la Panini spa vi sono ripetuti i 3 campi relativi alla località. Sviluppando la relazione vista sopra avremo:


In questo modo dopo aver inserito la Localita nella sua tabella, sarà necessario soltanto inserire la chiave primaria PK della tabella Localita, nel campo IDLoc (Chiave esterna ) della tabella Azienda, per avere il riferimento giusto dell’indirizzo, con un risparmio notevole sia in termini di spazio di occupazione del DB sia di tempo impiegato

Il Modello Relazionale spesso va accompagnato, oltre che dalla sua rappresentazione grafica, anche da una descrizione dei suoi dati. Tale descrizione testuale che ha il compito di indicare i domini di tutti gli attributi di ogni tabella con i relativi domini di appartenenza, individuare le chiavi primarie e le chiavi esterne e a volte riporta anche le descrizioni delle relazioni.

Per oggi abbiamo finito. Nella prossimo articolo continueremo a parlare del modello relazionale.

Se hai delle domande o precisazioni che vuoi approfondire mandami una mail all’indirizzo info@creaprogrammando.com

A presto
Paolo Bellesia

P.s. Se ancora non lo hai fatto e vuoi scaricare il primo Special Report gratuito "Crea il tuo programma" iscriviti nel box a fianco potrai cosi cominciare a progettare in modo semplice e divertente i tutti i tuoi programmi. Inoltre riceverai le indicazioni di tutti gli articoli che periodicamente inseriamo nel Blog.

Dominio e chiave primaria nel modello ER

In questo articolo continueremo ad approfondire le proprietà del modello ER , andando ad approfondire il dominio di un attributo e la definizione della chiave primaria.

Il dominio di un attributo

Abbiamo visto nel precedente articolo cosa sono le entità e le associazioni e come collegarle fra loro. Ognuna di queste possono avere degli attributi, ai quali si può assegnare un insieme di valori.

Il dominio di un attributo non è altro che il tipo di dati assegnato, ad esempio:

• Stringhe di caratteri
• Valori numerici
• Valori temporali (date, ore, ...)
• Valori booleani (vero o falso)
• Enumerazioni (si definisce una lista di valori validi)
• …

Nel nostro esempio, per l’entità Persona avremo:

attributo	Tipo dati
Nome	stringa
Cognome	stringa
Data nascita	Data/ora
Biografia	Memo

In tal modo un volta assegnati i titpi di dati ad un attributo, esso potrà assumere soltanto quel tipo di dati oppure Null, cioè valore nullo.

Nel caso un attributo abbia valore multiplo, questi valori devono avere lo stesso tipo di dati. Nel nostro esempio l’attributo Lingue dell’entità film avrà il valore multiplo (o meglio 3 valori): "italiano", "inglese" e "spagnolo", tutte di tipo stringa.

La chiave primaria

Nel grafico 1 del precedente articolo, vi è anche un altro elemento importantissimo per la gestione dei Database relazionali: La chiave primaria.

Questo attributo, indicati con la sottolineatura (nome per l’entità film e la coppia nome cognome per l’entità persona), permette di identificare univocamente ogni istanza dell’entità, cioè precisamente una persona o un film. Una condizione necessaria è che di una entità deve esserci una istanza unica, e la chiave primaria la distingue dalle altre.

Quindi non saranno ammessi film con lo stesso nome oppure, se pensiamo all’entità persona, non saranno ammesse persone che hanno contemporaneamente lo stesso nome e cognome.

NOTA: Come si vede questo aspetto limita il nostro database, e quindi consiglio di non utilizzare questo tipo di campi per definire la chiave primaria, ma di crearne una ad-hoc, per ogni entità.

Ritorneremo sul concetto di chiave primaria, quando passeremo alla traduzione dei diagrammi ER in modelli relazionali, e vedremo che la scelta della chiave primaria spesso sarà dettata da considerazioni più contingenti e tecniche. Per ora basta sapere che la chiave primaria è l’insieme minimo di attributi che permettono di individuare univocamente ogni istanza dell’entità cui appartengono. Proprio per l’individuazione univoca non sono ammesse istanze di una stessa entità che abbiano i valori della chiave primaria duplicati ed inoltre nel dominio di valori della chiave non può esserci il NULL.

Per oggi abbiamo finito. Nella prossimo articolo parleremo del modello relazionale.

Se hai delle domande o precisazioni che vuoi approfondire mandami una mail all’indirizzo info@creaprogrammando.com

A presto

Paolo Bellesia

P.s. Se ancora non lo hai fatto e vuoi scaricare il primo Special Report gratuito "Crea il tuo programma" iscriviti nel box a fianco potrai cosi cominciare a progettare in modo semplice e divertente i tutti i tuoi programmi. Inoltre riceverai le indicazioni di tutti gli articoli che periodicamente inseriamo nel Blog.

il Modello Entità-Associazione (Entity-Relationship)

Proseguiamo la creazione della nostra idea in un progetto software vero e proprio, andando ad analizzare il punto 2 dei 4 passi fondamentali per la progettazione di un database.

In questo secondo passo spiegherò Il Modello Entità-Associazione (dall’inglese Entity-Relationship, da cui la sigla ER), il quale permette di trasformare la nostra idea in un diagramma di flusso, base per la realizzazione del nostro.

Questo modello ci permetterà di evidenziare quali sono le entità necessarie del DB (Database) e quali sono le associazioni fra di esse.

Ma cosa sono le entità e cosa sono le associazioni?

- Una entità è un "qualcosa" (concreta o astratta) indipendente dalle altre.
- Gli attributi sono le sue proprietà.

Per meglio dire un’entità è la descrizione di un insieme di oggetti che condividono gli stessi attributi.

Nel precedente articolo abbiamo cominciato un esempio che vorrei utilizzare anche nel proseguo di questo mini corso iniziale. L’esempio è relativo ad un negozio di vendita e noleggio DVD e CD.

Consideriamo un film ed una persona, queste sono entrambe due entità, le quali saranno legate nel caso in cui la persona ha fatto parte del cast del film, in un qualunque suo possibile impiego.

Gli attributi per il film possono essere: nome, data di realizzazione, genere, trama e le lingue in cui è stato tradotto il film.

Mentre quelli della persona sono: il nome, il cognome, data di nascita e biografia.

Le associazioni tra le varie entità sono i legami che uniscono le entità. Si noti che anche le associazioni possono avere attributi.

Tra le due entità film e persona vi è un’associazione che descrive il fatto che una persona ha partecipato alla realizzazione di un film. Il ruolo avuto nella realizzazione del film, sia esso quello di regista, protagonista, attore secondario o altro, è un attributo dell’associazione.

Nel diagramma ER le entità vengono indicate con dei rettangoli mentre le associazioni con dei rombi collegati alle entità interessate dall’associazione. Gli attributi invece vengono indicati all’interno di ellissi collegate all’entità o all’associazione cui appartengono.

L’associazione tra le due entità la chiamiamo ad esempio “cast”, e indica che una persona ha partecipato alla realizzazione di uno o più film ovvero che un film è stato realizzato da una o più persone. Il diagramma ER corrispondente è:

La M e quella N vicino all’entità film e all’entità persona indica qual è la sua cardinalità, cioè quante volte può esserci nell’associazione. Nel nostro esempio lo si fa facendosi due semplici domande:

- una persona a quanti film può partecipare? La risposta è M (ovvero più di uno);
- un film quante persone può annoverare nel suo cast? La risposta è N (ovvero più di una).

Anche nel caso in cui una persona svolga più ruoli all’interno del cast del film, si useranno più associazioni “cast”. Ad esempio se una persona è sia regista che attore, verrà inserito una sola volta tra le persone, ma ci saranno due associazioni cast: una col ruolo di attore e una col ruolo di regista.

Oltre alla cardinalità M:N, le associazioni possono avere cardinalità 1:N o 1:1. Vediamo alcuni semplici esempi.

Ogni film può essere N volte oggetto di una proiezione in sala, mentre ogni proiezione ha come oggetto (di norma) un solo film.

Ogni studente ha una sola carriera universitaria e ogni carriera appartiene ad un solo studente.

Altro elemento che possiamo notare nel diagramma è che l’attributo lingue di film è cerchiato due volte. Questo sta ad indicare che è multivalore, cioè al suo interno vi sono memorizzati più valori (le lingue in cui è stato tradotto il film possono essere più di una).

Un altro tipo di attributo, non mostrato nell’esempio, è l’attributo composto, eccone un esempio:

L’indirizzo è un attributo composto perché costituito da ulteriori attributi semplici: via, numero, città, provincia e cap.

Nella prossimo articolo vedremo approfondiremo ulteriormente il modello ER, sempre proseguendo nell’esempio. Se hai delle domande o precisazioni che vuoi approfondire mandami una mail all’indirizzo info@creaprogrammando.com

A presto

Paolo Bellesia

P.s. Se ancora non lo hai fatto e vuoi scaricare il primo Special Report gratuito "Crea il tuo programma" iscriviti nel box a fianco potrai cosi cominciare a progettare in modo semplice e divertente i tutti i tuoi programmi. Inoltre riceverai le indicazioni di tutti gli articoli che periodicamente inseriamo nel Blog.