Software Dev Notes: Basi di Dati: Il modello concettuale

Content:

Database
DBMS
MODELLI DEI DATI
PROGETTAZIONE DI UNA BASE DI DATI
PROGETTAZIONE CONCETTUALE

Il Modello E-R

Le entità

Gli Attributi

Le Associazioni

Vincoli di Integrita'

Esempio di progettazione concettuale: la gestione dei prestiti dei libri di una bilioteca

Esempio di progettazione concettuale: la concessionaria di automobili

1 DATABASE

Cosa e' un sistema informativo?

Durante qualunque attivita' e' necessario avere a disposizione una quantita' di informazioni, per cui le organizzazioni si dotano di un sistema informativo per gestire le informazioni.

Dati e Informazioni

dati = rappresentazione grezza
informazione = significato ottenuto interpretando i dati

Le informazioni vengono codificate e scambiate.
I dati sono la rappresentazione codificata delle informazioni. Opportunamente interpretati, i dati permettono di ottenere informazioni.

Cosa sono le basi di dati?

Le basi di dati sono una collezione di dati, raccolti allo scopo di rappresentare le informazioni usate in un sistema informativo. In altre parole, un database e' una base di dati è una collezione organizzata di dati correlati che descrivono una specifica realta' di interesse.

Esempi:

quando facciamo una operazione allo sportello dell'ufficio postale, l'operatore in inserisce dei dati dal terminale che sono registrati in un database, il database dei versamenti.
quando andiamo in banca e facciamo delle operazioni, l'operatore inserisce dei dati, parte una transazione e i dati immessi popolano un database.
voi vi sieti iscritti a questo corso, i vostri dati sono stati registrati in un database.
tutti i dati che descrivono una realta' costituiscono un database.

2 DBMS

Il Database Management System DBMS e' il software che gestisce il database, che mi permette di inserire dati, modificare dati e fare delle operazioni sui dati. Quindi ha senso realizzare un database se io ho uno strumento che lo gestisce.

Esempi di DBMS a pagamento sono: Oracle e Microsoft SQL Server. Esempi di DBMS open source sono: MySQL e PostgreSQL. Microsoft Access e' un DBMS per database di piccole dimensioni e per uso personale.

Le caratteristiche che un DBMS deve avere sono:

indipendenza logica dei dati
indipendenza fisica dei dati
multiutenza
sicurezza
gestione delle transazioni
linguaggio per la gestione dei dati

Indipendenza logica dei dati significa che l'organizzazione logica dei dati può evolvere senza richiedere modifiche ai programmi applicativi, purché l'interfaccia esterna rimanga invariata (ad esempio tramite viste). Indipendenza fisica significa che se cambio l'organizzazione fisica dei file sul supporto di memorizzazione l'applicazione continua a funzionare. Per realizzare una applicazione web oriented c’è bisogno di un database che sia multiutente, cioe' che permetti l'accesso concorrente ai dati.

Un database deve essere progettato in modo tale da ridurre le ridondanze, cioe' i dati ripetuti. Ad esempio, se scriviamo in un foglio excel una serie di informazioni come nome e cognome dello studente e il corso che frequenta, ho delle informazioni ripetute; infatti se Mario Rossi frequenta tre corsi, nome e cognome di Mario Rossi sono ripetuti tre volte nel foglio excel. Se si introducono le ridondanze e' piu' facile che si avranno delle incongruenze nel database. Infatti, se si modifica il cognome, si deve modificarlo in tutte e tre le righe, altrimenti ci sono delle anomalie: il contenuto della base di dati non e' piu' coerente.

Sicurezza significa che il database deve offirire all'amministratore strumenti per il backup e restore dei dati, l'amministratore effettua delle copie settimanali o mensili del database. La sicurezza include anche: utenti, password, privilegi, ruoli, autorizzazioni, cifratura, auditing.

La transazione e' una insieme di operazioni viste come una singola procedura. Ad esempio, quando si va allo sportello ATM della banca per fare un prelievo, il DBMS effettua una transazione sul database dei movimenti dei conti correnti che consiste nel sottrarre al saldo la cifra prelevata, la transazione parte quando si clicca sul bottone ESEGUI e termina quando viene eseguito il COMMIT. Se c’è un malfunzionamento, la transazione deve essere annullata. Una transazione deve rispettare le proprietà ACID.

Durante gli anni 70-80, quando i DBMS erano in fase di sviluppo, i linguaggi per la gestione dei dati erano diversificati. E tuttora nella letteratura si tende a diversificare i linguaggi di gestione dei dati in diversi sottolinguaggi. SQL comprende istruzioni appartenenti ai linguaggi DDL, DML, DCL e TCL.
Il linguaggio SQL contiene i comandi per creazione di tabelle (Data Definition Language), comandi per l'inserimento e modifica di dati in tabella (Data Manipulation Language), comandi per il controllo dell'accesso dei dati (Data Control Language) usati dagli amministratori dei database, comandi per il controllo delle transazioni (Transaction Control Language).

3 MODELLI DEI DATI

Un modello di dati è un insieme di concetti e regole utilizzati per descrivere e organizzare i dati di interesse. Ogni modello mette a disposizione costrutti propri per rappresentare una determinata realtà.

Nella progettazione di una base di dati si distinguono principalmente due categorie di modelli:

modelli concettuali
modelli logici

Modelli concettuali

I modelli concettuali vengono utilizzati nella fase iniziale della progettazione di una base di dati per descrivere la realtà di interesse in modo indipendente dal DBMS che verrà utilizzato.

Lo scopo del modello concettuale è rappresentare gli oggetti del mondo reale e le relazioni tra essi, senza preoccuparsi di come i dati saranno memorizzati.

Il modello concettuale più diffuso è il modello Entità-Associazione tradotto dall'inglese Entity-Relationship (E-R). Un altro modello è UML Class Diagram.

Modelli logici

Terminata la progettazione concettuale, il modello viene tradotto secondo uno specifico modello logico (ad esempio il modello relazionale), indipendentemente dal particolare DBMS.

I modelli logici sono quelli effettivamente implementati nei sistemi di gestione delle basi di dati.

I principali modelli logici sono:

il modello relazionale;
il modello gerarchico;
il modello reticolare;
il modello a oggetti.

Il modello relazionale rappresenta i dati mediante il concetto matematico di relazione. Nei DBMS una relazione viene normalmente rappresentata come una tabella: ogni riga rappresenta una tupla (o record) e ogni colonna rappresenta un attributo. L'ordine delle righe e delle colonne non ha significato. (Nota: la tabella non è la relazione, ma la sua rappresentazione pratica nei DBMS).

Ad esempio, i dati relativi ai corsi universitari possono essere organizzati mediante la relazione CORSI.

Schemi e istanze

Nelle basi di dati esiste una parte costante e una parte variabile nel tempo. Lo schema del database rappresenta una descrizione dei dati e non varia nel tempo. L'istanza o stato rappresenta i valori assunti dai dati e puo' variare nel tempo

Nell'esempio precedente, la relazione CORSI viene rappresentata con una tabella di tre colonne. Lo schema della relazione CORSI e' il nome della relazione seguito dai nomi dei suoi attributi:

  CORSI(NOME,CFU,ANNO)

L'istanza della relazione CORSI e' rappresentata dal contenuto delle righe della tabella.

Lo schema logico del database rappresenta la descrizione dell'intera base di dati attraverso il modello logico adottato per rappresentare i dati su database. Lo schema logico non contiene i dati, ma soltanto la struttura.

4 PROGETTAZIONE DI UNA BASE DI DATI

Come nella programmazione si fa l'analisi, il design e l'implementazione, lo stesso processo si ha anche nella progettazione dei database. Nella progettazione dei database si parte da una specifica realta' di interesse che il committente vuol fare informatizzare da parte di una societa' di sviluppo software.

Le software-house si specializzano in campo di interesse e creano database per uno speficico campo applicativo. La Buffetti crea gestionali che sono pacchetti software integrati (che contengono un proprio database): Buffetti gestione magazzino, Buffetti gestione contabilita', ecc. Ci sono software house specializzate nella creazione di database cartografici che contengono mappe, foto e informazioni collegate a punti su delle mappe geografiche: per esempio, se faccio click su una cartina mi appaiono le informazioni su un negozio.

La progettazione di un database si articola in tre fasi: progettazione concettuale, progettazione logica e progettazione fisica:

Nella progettazione concettuale si analizza la realtà di interesse e la si descrive mediante un modello concettuale dei dati, indipendentemente dal DBMS che verrà utilizzato. Il risultato di questa fase è lo schema concettuale, generalmente rappresentato mediante un diagramma Entity-Relationship (E-R).
Nella progettazione logica lo schema concettuale viene tradotto in uno schema logico, utilizzando uno specifico modello logico dei dati, ad esempio il modello relazionale.
Nella progettazione fisica lo schema logico viene trasformato nello schema fisico del database, definendo l'organizzazione dei dati sul sistema di memorizzazione e gli aspetti implementativi, come i tipi di dato, gli indici e le modalità di accesso ai dati.

Negli anni Settanta, Peter Chen introdusse il modello Entity-Relationship (E-R), che divenne il principale modello concettuale per la progettazione delle basi di dati. Nello stesso periodo, il matematico Edgar F. Codd sviluppò il modello relazionale, sul quale si basano i moderni database relazionali.

5 PROGETTAZIONE CONCETTUALE

La progettazione concettuale consiste nel creare un modello astratto su carta che rappresenta/schematizza una specifica realta' di interesse. Nel fare cio' si usa un processo di astrazione.

Esistono tre tipi di astrazione:

astrazione per classificazione
astrazione per aggregazione
astrazione per generalizzazione

Ad esempio, se si vuole fare un programma per la gestione di una biblioteca, un oggetto da modellizzare e' il libro. Quindi, classificare l'oggetto libro, significa attribuire all'oggetto tutte le sue caratteristiche (codice ISBN, titolo, autore, casa editrice). Se voglio fare un programma per la gestione di un negozio di ricambi auto, l'oggetto principe e' l'automobile, per cui se voglio classficare l'auto si conferiscono all'oggetto auto le proprieta' che le contraddistinguono (numero telaio, marca, modello, cilindrata, anno di immatricolazione).

5.1 Il Modello Entità-Associazione

Il modello Entità-Associazione, Entity-Relationship (E-R) e' il modello concettuale dei dati piu' utilizzato nell’ambito della progettazione di una base di dati. Il modello E-R viene utilizzato per costruire degli schemi che descrivono la struttura dei dati.

Il modello E-R offre i seguenti costrutti per descrivere la realta' di interesse:

entità = rappresenta classi di oggetti, nello schema viene rappresentato graficamente con un rettangolo
esempio: l'automobile per un database di un negozio di ricambi auto
attributo = caratteristica che descrive l'entità; nel diagramma adottato in queste dispense gli attributi sono rappresentati mediante linee collegate all'entità.
esempio: il numero di telaio dell'auto
associazione = legame logico tra due o piu' entità
esempio: l'associazione tra le due entità auto e proprietario dell'auto
vincolo = condizione per la coerenza del database espressa per un campo di un database
esempio: il campo anno di produzione per l'entità automobile usata non puo' essere antecedente ad una certa data

5.2 Le entità

Le entità rappresentano classi di oggetti che hanno proprietà/attributi comuni. Un'occorrenza di un'entità è un oggetto o istanza della classe che l'entità rappresenta. Una entità viene rappresentata graficamente con un rettangolo, gli attributi sono rappresentati graficamente come delle linee che escono dall'entità.

Ad esempio, (8829827924, Informatica Generale, Piero Gallo e Fabio Salerno) e' un esempio di occorrenza dell'entità Libro; (5^, A, informatica) e' un esempio di occorrenza dell'entità Classe di Studenti.

5.3 Gli Attributi

Gli attributi possono essere semplici o atomici, composti, multipli. Un attributo semplice non e' ulteriormente scomponibile (es: codice ISBN).

L'attributo indirizzo dell'entità persona e' un esempio di attributo composto. L'attributo indirizzo che e' composto da via, numero, CAP e città. A livello concettuale non ci si interessa di renderlo semplice. Poi, a livello di progettazione logica si spezza l'attributo composto in tanti attributi semplici.

Gli attributi possono essere multipli. Ad esempio l'autore di un libro puo' essere uno solo o puo' essere piu' di una persona. In questo caso l'attributo autore ha due valori. Nella traduzione verso il modello relazionale, gli attributi multipli si portano fuori dall'entità e si crea una una nuova relazione, collegata con l'entità di origine: nel caso dell'entità libro si crea la relazione autori. Gli attributi multipli vanno estrapolati altrimenti ho un problema per la ricerca. Ad esempio, consideriamo il libro "informatica generale" scritto da Piero Gallo e Fabio Salerno; se voglio cercare nel database tutti i libri di Piero Gallo, sarebbe scomodo andare a fare una ricerca per parte di campo.

Domanda: cosa succede se una persona possiede due indirizzi email?
Risposta: se il numero di indirizzi email non è rigidamente limitato, è preferibile modellare una relazione 1:N tra le entità Persona ed Email. Questa è la soluzione più corretta dal punto di vista della progettazione relazionale. Nei piccoli software gestionali, tuttavia, si adotta talvolta una soluzione più semplice: gli indirizzi email vengono mantenuti come attributi dell'entità Persona. Ad esempio, la tabella AnagraficaPersona può contenere campi come telefono, fax, cellulare ed email. Se è necessario memorizzare più indirizzi, si possono aggiungere campi come email1, email2, e così via. In questo caso non viene introdotta una nuova entità, poiché gli indirizzi email sono considerati attributi e non è previsto eseguire ricerche o altre operazioni specifiche su di essi.
Questa soluzione è semplice da implementare perché non richiede la creazione di una nuova entità e di una relazione tra tabelle. Tuttavia è poco flessibile, poiché il numero massimo di indirizzi email deve essere stabilito in fase di progettazione. Se in futuro fosse necessario memorizzare un numero maggiore di indirizzi oppure associare ulteriori informazioni a ciascuna email, come il tipo (personale, lavoro o PEC), l'indicazione dell'indirizzo principale, la data di verifica, la data di creazione o lo stato (attivo/non attivo), sarebbe necessario modificare la struttura del database. Utilizzando invece una relazione 1:N tra Persona ed Email, il numero di indirizzi memorizzabili è virtualmente illimitato e il modello risulta più facilmente estendibile.

Gli attributi possono essere obbligatori o opzionali. Un attributo e' obbligatorio quando e' necessario valorizzarlo e ogni istanza di quella entità deve avere un valore per quell'attributo, si dice un campo obbligatorio. Un attributo e' opzionale quando nell'istanza puo' essere valorizzato o non valorizzato. Il fatto che non e' valorizzato si traduce nel database nel fatto che il campo e' NULL. NULL vuol dire informazione mancante. Ad esempio, quando ci si inscrive in sito web si riempie un form html che ha dei campi obbligatori e dei campi opzionali; spesso si riempiono solo i campi obbligatori e si clicca sul bottone invio del form. Questo si traduce nel fatto che nel database viene riempita una riga relativa alla mia iscrizione con i campi obbligatori valorizzati e i campi opzionali NULL.

5.3.1 Attributo Chiave

Ogni entità deve avere un attributo speciale detto attributo chiave. Nella teoria dei database, l'attributo chiave e' per definizione uno o piu' attributi che identificano in maniera univoca una istanza dalle altre.

Nella teoria dei database, esistono:

chiavi composte
chiavi candidate
chiavi naturali
chiavi artificiali (surrogate)

Ad esempio per la entita' Prenotazione, la chiave naturale è: (numeroVolo, data, posto).

Una chiave composta
è una chiave formata da due o più attributi che, considerati insieme, identificano univocamente un'istanza dell'entità. Nessuno degli attributi, preso singolarmente, è sufficiente a garantire l'unicità.

Esempio

Consideriamo l'entità Iscrizione:

Matricola	CodiceCorso	DataIscrizione
12345	INF101	10/09/2025
12345	MAT201	12/09/2025

La coppia (Matricola, CodiceCorso) identifica univocamente ogni iscrizione, mentre i singoli attributi no.

Una chiave candidata
è un insieme minimo di uno o più attributi che identifica univocamente ogni istanza di un'entità. Si dice "candidata" perché può essere scelta come chiave primaria. Una stessa entità può avere più chiavi candidate.

Ad esempio, per l'entità Persona potrebbero essere entrambe valide sia il Codice Fiscale che il Numero della Carta d'Identità. Entrambe identificano univocamente una persona. Se scegliamo il Codice Fiscale come chiave primaria, la Carta d'Identità diventa una chiave alternativa (alternate key).

Una chiave naturale
è una chiave costituita da uno o più attributi che appartengono già alla realtà rappresentata e hanno un significato nel dominio applicativo. Non viene introdotta appositamente per il database.

Ad esempio, Codice fiscale, ISBN di un libro, Targa di un'automobile, Partita IVA, sono tutti identificatori che esistono indipendentemente dal database.

Una chiave artificiale
(o chiave surrogata, surrogate key) è un identificatore creato esclusivamente per identificare univocamente le istanze di un'entità. Non possiede alcun significato nel dominio applicativo.

Esempio

ID	Nome	Cognome
1	Mario	Rossi
2	Luca	Bianchi

L'attributo ID non descrive la persona: serve solo come identificatore.

NOTA: Questi concetti non si escludono a vicenda. Per esempio: 1) una chiave naturale può essere anche una chiave candidata; 2) una chiave candidata può essere composta; 3) una chiave composta può essere naturale.

Ad esempio, nell'entità Prenotazione Volo, la coppia (NumeroVolo, Data), potrebbe essere contemporaneamente:

una chiave composta (perché formata da due attributi);
una chiave candidata (perché identifica univocamente una prenotazione, se nessun'altra combinazione minima lo fa);
una chiave naturale (perché entrambi gli attributi appartengono naturalmente al dominio applicativo e non sono stati introdotti artificialmente). Questa distinzione aiuta a capire che i termini descrivono proprietà diverse della stessa chiave.

Tuttavia, e' una scelta progettuale molto diffusa (non una regola) non prendere una lista di campi per creare un attributo chiave, ma prenderne uno solo. Ad esempio l'entità libro ha una serie di istanze, "Informatica Generale" e' una istanza dell'entità libro e l'attributo chiave dell'entità libro e' il codice ISBN.

Esempi di chiave sono: la matricola per l'entità dipendente, la matricola per l'entità studente, il codice fiscale per la persona fisica, la partita IVA per l'azienda.

Tutti gli oggetti hanno naturalmente un attributo chiave, e se non lo ha se ne introduce uno in modo artificiale. Il codice fiscale e' una chiave naturale derivata, perche' viene calcolata da altri attributi, ma identifica la persona senza essere stata introdotta solo per il database. Per l'entità articolo del negozio si inventa il codice dell'articolo. Il codice non e' un attributo che descrive l'articolo, ma e' stato introdotto in maniera artificiale, ma necessaria, per creare l'attributo chiave. Infine, se non ne troviamo uno, si usa un ID, ad esempio il circolo sportivo individua il socio con il numero tessera, che e' un numero progressivo.

Nel diagramma ER le chiavi sono sottolineate.

5.4 Le Associazioni

Le entità sono legate tra di loro. Ad esempio nel database del PRA l'entità persona e' collegata all'entità auto tramite l'associazione POSSIEDE, nel DB del ministero delle finanze l'entità versamento e' collegata al contribuente tramite l'associazione PAGA.

Nel diagramma E-R le associazioni sono schematizzate utilizzando il rombo, al cui interno si scrive il nome dell'associazione.

Esempi di associazioni

Un'occorrenza di una associazione e' una n-pla costituita da occorrenze di entità, un'occorrenza per ogni entità che partecipa all'associazione. Ad esempio (Mario Rossi; fiat punto 1.2 EL) puo' essere un'occorrenza della associazione possiede del database del Pubblico Registro Automobilistico.

Le associazioni hanno un grado dato dal numero delle entità che partecipano all’associazione. Le associazioni di grado 1 sono dette auto associazioni o associazioni ricorsive. Le associazioni di grado 2 sono dette binarie. Le associazioni di grado 3 sono dette ternarie.

Nella pratica, negli schemi E-R, si cerca, quando possibile, di modellare le associazioni mediante relazioni binarie, poiché risultano più semplici da comprendere e da tradurre nel modello relazionale. Quando il significato dell'associazione lo consente, una relazione ternaria può essere scomposta in due relazioni binarie. Tuttavia, esistono associazioni ternarie che rappresentano un'informazione non scomponibile senza perdere significato. Un esempio classico è l'associazione Fornitura, che collega contemporaneamente un fornitore, un prodotto e un reparto. In questo caso l'informazione è rappresentata dalla combinazione dei tre elementi: scomponendo l'associazione in due relazioni binarie si perde il significato originario. Ad esempio: la ditta Samsung Italia fornisce stampanti al reparto Amministrazione. Questa è un'unica informazione. Se la scomponi in due relazioni binarie: Samsung Italia → fornisce → Stampanti e Reparto Amministrazione → utilizza → Stampanti non puoi più stabilire quale fornitore rifornisce quale reparto per quel determinato prodotto.

Anche le associazioni possono avere attributi propri: le due entità studente e corso hanno i loro attributi, l'associazione ESAME ha data e voto.

Una auto associazione lega una entità a se stessa. Partita e' un esempio di auto associazione.

L'associazione fornitura e' un esempio di associazione ternaria.

Per esempio, un insieme di occorrenze dell'associazione Fornitura stabilisce che:

Nota: di solito nel diagramma ER per le entità si usano i nomi al singolare, mentre nello modello relazionale per le tabelle si usano i nomi al plurale, ma nessuno ci vieta di cambiare la convenzione.

Nota: nella pratica moderna molti progettisti preferiscono introdurre una chiave artificiale (ID) invece di utilizzare una chiave primaria composta, perché semplifica la gestione delle relazioni. Tuttavia le chiavi primarie composte sono perfettamente corrette e vengono ancora utilizzate quando rappresentano naturalmente il dominio del problema.

5.4.1 Entità deboli ed entità forti

Un'entità debole è un'entità che non può essere identificata univocamente senza fare riferimento a un'altra entità, detta entità forte. Infatti, un'entità debole può avere un proprio identificatore parziale. L'identificazione completa deriva dalla combinazione: (chiave dell'entità forte, identificatore parziale)

Cliente e Conto sono entità forti. Movimento è un’entità debole, perche' ha senso solo in relazione all’entità Conto.
Nella progettazione moderna si preferisce spesso introdurre una chiave artificiale (ID) per semplificare la rappresentazione dell'entità nel modello relazionale.

5.4.2 Cardinalità delle associazioni

La cardinalita' di una associazione viene specificata per ogni entità che partecipa ad una associazione. La cardinalità specifica il numero minimo e massimo di occorrenze dell'associazione alle quali può partecipare un'istanza dell'entità.

Per esempio, se in una relazione Insegnamento specifichiamo per l'entità Docente una cardinalita' minima pari ad uno ed una cardinalita' massima pari a tre, vogliamo indicare che un docente puo' partecipare ad un minimo di una occorrenza e ad un massimo di tre occorrenze della relazione Insegnamento. In altre parole, un docente deve insegnare almeno una materia ma non piu' di tre.
Se per l'entità Materia specifichiamo una cardinalita' minima pari a zero e una cardinalita' massima pari a 5 imponiamo che, in una scuola, una certa materia puo' partecipare o a nessuna occorrenza o la massimo a 5 occorrenze della relazione Insegnamento. Quindi un certa materia puo' non essere insegnata da nessun docente oppure puo' essere insegnata da un numero di docenti inferiore o uguale a 5. In uno schema E-R, la cardinalita' minima e massima delle partecipazioni di entità a relazioni si specificano tra parentesi, come nella figura sotto.

In linea di principio, e' possibile assegnare un qualunque intero maggiore o uguale a zero alla cardinalita' di una associazione con l'unico vincolo che la cardinalita minima deve essere minore o uguale alla cardinalita massima. Nella maggior parte dei casi, e' sufficiente utilizzare solo tre valori: zero, uno e il simbolo N, che indica un intero maggiore di uno. In particolare:

CARDINALITA MINIMA = 0|1
nel primo caso si dice che la partecipazione dell'entità relativa e' opzionale, nel secondo caso si dice che la partecipazione e' obbligatoria.
CARDINALITA MASSIMA = 1|N
nel primo caso la partecipazione della seconda entità puo' essere vista come una funzione che associa ad una occorrenza dell'entità una sola occorrenza (o nessuna) dell'altra entità; nel secondo c'e' invece una associazione con un numero arbitrario di occorrenze dell'altra entità.

Nella figura sotto, sono riportati diversi casi di cardinalita per associazioni.

5.4.3 Classificazione delle associazione binarie

Osservando le cardinalita massime, e' possibile classifcare le associazioni binarie in base al tipo di corrispondenza che viene stabilita tra le occorrenze delle entità coinvolte:

Uno ad uno (1:1)

Le associazioni che hanno cardinalita massima pari ad uno per entrambe le entità coinvolte, definiscono una corrispondenza uno ad uno tra le occorrenze di tali entità e vengono quindi denominate relazioni uno ad uno. Le associazioni uno ad uno sono rare, esempi di associazioni di tipo 1:1 sono Preside:Scuola, Persona:Passaporto, Veicolo:Libretto, Dipendente:Armadietto, Utente:Profilo.

Uno a molti (1:N)

Le relazioni aventi una entità con cardinalita massima pari ad uno e l'altra con cardinalita massima pari ad N sono denominate relazioni uno a molti. Ad esempio, le cardinalita della associazione Persona:Auto ci dice che una persona puo' non possedere un'auto e ne puo' possedere anche piu' di una. Un'auto puo' essere intestata al massimo a una sola persona.
L'associazione Calciatore:Squalifica e' una associazione opzionale 1:N, l'associazione Squalifica:Calciatore e' una associazione obbligatoria N:1. Durante il campionato un calciatore puo' essere soggetto a una o piu' squalifiche. Se esiste una squalifica deve necessariamente esistere qualche calciatore a cui l'ho data, altrimenti si avrebbe una anomalia su database.

Molti a molti (M:N)

Le relazioni aventi cardinalita massima pari ad N per entrambe le entità coinvolte, come la relazione PRENOTA, vengono denominate relazioni molti a molti. Ad esempio, l'associazione PersonaFisica:Immobile: una persona puo' possedere piu' immobili e un immobile puo' essere posseduto da piu' persone, come marito e moglie hanno una comproprieta del 50% oppure tre fratelli sono comproprietari al 33% di un immobile.

Per le cardinalita minime va detto che e' raro avere una caso di partecipazione obbligatoria per tutte le entità coinvolte, perche quando si aggiunge una nuova occorrenza di una entità, spesso non sono note (o non esistono) le corrispondenti occorrenze delle entità ad essa collegate. Per esempio, nell'associazione VENDITA che lega le entità ordine e fattura, quando si riceve un nuovo ordine, non esiste ancora una fattura ad esso relativa, per cui non e' possibile costruire una occorrenza della associazione VENDITA che contiene il nuovo ordine.

Per quanto riguarda le relazione n-arie, vedi ad esempio l'associazione FORNITURA, le entità conivolte partecipano quasi sempre con cardinalita massima pari ad N.

5.4.4 Generalizzazione e specializzazione

Ci sono casi in cui una entità e' un caso particolare di un'altra entità. Ad esempio nel caso della gestione dei tributi, si hanno tre tipi di tributi locali: ICI per la casa, TARSU per la nettezza urbana, TOSAP per i commercianti. Si puo' modellizzare una entità Imposta e poi specializzare in una serie di tributi. Si parla di associazione per generalizzazione e si modellizza il concetto creando una gerarchia ISA (is a = e' un): cioe' ICI e' una imposta, TARSU e' una imposta, ecc.

Nel modello concettuale si modellizzano delle entità che sono dei sottoinsiemi di una entità piu' generale.

Ad esempio, una entità Lavoratore puo' essere una generalizzazione di entità figlie come Lavoratore Dipendente, Lavoratore Autonomo, Professionista, ecc. Ogni entità figlia e' specializzata.

5.5 Vincoli di Integrita'

Un vincolo e' una regola che deve essere rispettata per il buon funzionamento del database: in particolare il vincolo e' una regola che previene incongruenze sulla base di dati. Un base di dati integra non presenta anomalie.

Dal punto di vista formale, i vincoli possono essere classificati in quattro tipi:

vincoli di dominio
vincoli di chiave
vincoli di integrità referenziale
vincoli definiti dall'utente

5.5.1. Vincoli di dominio (Domain Constraints)

Un vincolo di dominio stabilisce quali valori può assumere un attributo. In altre parole, definisce l'insieme dei valori ammessi.

Esempi: Età: 0 <= eta <= 120; prezzo: prezzo > 0; sesso: 'M'|'F'; voto: 18...30; CAP: deve essere formato da 5 cifre

5.5.2. Vincoli di chiave (Key Constraints)

Un vincolo di chiave impone che gli attributi scelti come chiave identifichino univocamente ogni occorrenza dell'entità. In pratica: nessun duplicato e nessun valore NULL (per la chiave primaria).

Esempio: STUDENTE(Matricola, Nome), non possono esistere due studenti con la stessa matricola.

5.5.3. Vincoli di integrità referenziale (Referential Integrity)

Un vincolo di integrità referenziale impone che ogni valore di una chiave esterna (foreign key) corrisponda a un valore esistente della chiave primaria della tabella a cui fa riferimento. In questo modo il DBMS impedisce la presenza di riferimenti a record inesistenti.

Esempio: Consideriamo la associazione Cliente:Ordine di tipo 1:N. L'associazione Cliente:Ordine e' una associazione opzionale 1:N, l'associazione Ordine:Cliente e' una associazione obbligatoria N:1.

 -------------                     -------------
|             |                   |             |
|   CLIENTE   |                   |    ORDINE   |
|             |                   |             |
 -------------                     ------------- 
 \            \                    \            \
 CodCliente    Nome               NumOrdine     Data

La cardinalita' e' CLIENTE (0,N) e ORDINE (1,1).

Quando traduciamo lo schema E-R otteniamo due tabelle.

CLIENTI

CodCliente	Nome
10	Mario Rossi
20	Luca Bianchi

ORDINI

NumOrdine	Data	CodCliente
100	10/1/2025	10
101	11/1/2025	10
102	12/1/2025	20

Osserva l'ultima colonnaCodCliente. Questa colonna è una chiave esterna (foreign key). Una colonna con una foreign key contiene un valore che punta alla chiave primaria di un'altra tabella. In questo esempio: ORDINI.CodCliente punta a CLIENTI.CodCliente

Che cos'è il vincolo di integrità referenziale? Il DBMS impone questa regola: Ogni valore della foreign key deve esistere nella tabella a cui fa riferimento. Per esempio, se proviamo ad inserire

NumOrdine	CodCliente
103	999

Il DBMS controlla se esiste un cliente con codice 999. Siccome, non esiste, allora rifiuta l'inserimento. Perché avremmo un ordine che appartiene ad un cliente inesistente.

Nota: non esiste un collegamento diretto tra un'associazione obbligatoria nel modello E-R e un vincolo di integrità referenziale nel modello relazionale. Sono due concetti distinti che appartengono a livelli diversi della progettazione. L'associazione obbligatoria è un concetto del modello concettuale (E-R) e indica che ogni occorrenza di un'entità deve necessariamente partecipare all'associazione. Il vincolo di integrità referenziale è un concetto del modello relazionale e garantisce che ogni chiave esterna (foreign key) faccia riferimento a una chiave primaria esistente. Nella traduzione dal modello E-R al modello relazionale, un'associazione viene normalmente realizzata introducendo una foreign key, sulla quale il DBMS applica il vincolo di integrità referenziale. Se la partecipazione dell'entità è obbligatoria, oltre al vincolo di integrità referenziale è necessario imporre anche che la foreign key non possa assumere il valore NULL. Pertanto, l'integrità referenziale e l'obbligatorietà della partecipazione sono due vincoli distinti: il primo garantisce la validità del riferimento tra tabelle, il secondo impone che tale riferimento sia sempre presente.

5.5.4. Vincoli definiti dall'utente (Business Rules)

Questa categoria comprende tutte le regole che dipendono dal problema da risolvere. Non derivano dalla teoria relazionale. Sono regole che decide il progettista. Esempi: età < 40, un utente può prendere al massimo 4 libri, dataFine >= dataInizio, sconto <= 30%, un professore può insegnare al massimo tre corsi. Sono tutte regole del dominio applicativo.

5.6 Esempio di progettazione concettuale: la gestione dei prestiti dei libri di una bilioteca

I lettori hanno una tessera su cui e' scritto un numero progressivo, il nome, il cognome, l'indirizzo, e il numero di telefono. I libri hanno un codice ISBN, un titolo, una lista di autori e possono esistere in piu' copie. I lettori effettuano richieste di prestito per le copie dei libri che sono catalogati nella biblioteca. A seguito di una richiesta, viene prima consultato l'archivio delle copie disponibili, cioe' non in prestito. Se la copia e' disponibile, si procede alla ricerca della copia nello scaffale, poi la copia viene classificata come in prestito e consegnata al lettore. Terminata la consultazione, la copia viene inserita in biblioteca e nuovamente classificato come disponibile. Per un prestito si tiene nota di ora e data di acquisizione e di riconsegna.

Il diagramma ER contiene tre entità: Utente, Copia e Libro: Utente ha come attributo chiave il numero della tessera della biblioteca. Libro ha come attributo chiave l'ISBN. Copia non ha un attributo chiave naturale, per cui introduciamo un numero progressivo. L'associazione Utente:Copia di tipo M:N e si chiama PrendeInPrestito. PrendeInPrestito ha attributi propri: data prestito e data consegna. L'associazione PrendeInPrestito e' opzionale in entrambi i versi, perche' l'utente puo' prendere in prestito nessun libro e ci possono essere dei libri che non sono mai consultati. L'attributo data prestito e' obbligatorio, l'attributo data consegna e' opzionale. Quando l'utente prende in prestito un libro il campo data consegna e' NULL e sara' valorizzato quando lo consegna. Quindi per vedere i prestiti attualmente aperti per un utente, io faccio una ricercare per utente e vedo quanti valori NULL ha in prestito.

Allo schema si possono aggiungere dei vincoli definiti dall'utente.

data consegna >= data prestito.
un utente non puo' prendere in prestito piu' di quattro libri

il tempo massimo di prestito sia di 30 giorni. In pseudocodice si scrive:

IF dataConsegna == NULL
    IF (dataAttuale - dataPrestito) > 30
    THEN Sollecito Utente

Operazioni sul sistema biblioteca

inserimento tesserato
inserimento libro
inserimento copia libro
ricerca di un libro tramite titolo e autore
controllo della disponibilita' di una copia di un libro
ricerca della collocazione delle copie di un libro
registrazione di un prestito e di una restituzione
ricerca di tutte le copie prestate

Errori su database e chiavi primarie

Anche Il Ministero delle Finanze fa dei controlli sul proprio database: se il contribuente non ha presentato il 730, c’è un campo con valore NULL e il Ministero invia una cartella. Se avviene un errore sul codice fiscale, il ministero manda la cartella lo stesso. Infatti, un operatore che riempie una base di dati commette statisticamente un errore ineliminabile del 2 per mille. Se vi arriva una cartella ICI e' possibile che un operatore abbia sbagliato il codice_comune o il codice_fiscale, ad esempio ha inserito una F invece di una P. Alcuni incongruenze si possono risolvere corregendo i vincoli di integrita' tra le entità, in modo che se un contribuente paga le tasse da 10 anni sul database devono risultare tutti e 10 i versamenti.

5.7 Esempio di Progettazione Concettuale: la concessionaria di automobili multimarca

Il sistema per la concessionaria di automobili gestisce vendite di auto nuovo ed usato. Per l'usato si ha una gestione delle riparazioni, per il nuovo si ha una gestione degli optional venduti. Si suppone che l'utente possa acquistare piu' automobili. Si hanno i seguenti vincoli sulle auto usate: 1) non devono esistere riparazioni con spese inferiori ai 1000 eur, 2) non si devono vendere auto immatricolate prima del 2008, 3) non si possono vendere auto che abbiano percorso piu' di 100.000 Km.

Gli attributi dell'entità cliente sono i soliti: nome, cognome, indirizzo, tel., con attributo chiave il codice fiscale.
L'associazione Acquista, di tipo uno a molti, tra le entita' Cliente ed Automobile, contiene gli attributi data acquisto e sconto.
Sia l'automobile nuova che l'auto usata viene descritta dagli attributi: N.telaio, marca, modello, prezzo e anni di garanzia (di solito 1 anno per l'usato e 2 anni per il nuovo), per cui questi attributi li generalizzo e li porto sull'entità padre. Un'auto usata ha degli attributi in piu' rispetto a quella nuova, che sono km percorsi ed anno di immatricolazione; le auto nuove sono immatricolate dal concessionario al momento della vendita.
L'associazione opzionale Usato:Riparazione di tipo M:N, con codice, tipo (ad es. frizione, freni), descrizione (cosa ho fatto alla macchina) e il costo. In questo modo potro' fare delle ricerche su database del tipo: quante auto ho venduto che hanno richiesto una riparazione ai freni.
L'associazione opzionale Nuovo:Optional di tipo M:N, con codice, descrizione (ad es. cerchi in lega) e prezzo. L'auto nuova puo' avere 0...N optional, un optional puo' avere 1...N auto.
Se io voglio sapere le auto vendute che motorizzazione hanno, ad es. la cilindrata, se e' diesel o benzina, allora devo introdurre una nuova entità che chiamo motorizzazione. L'associazione Auto:Motorizzazione e' di tipo 1:N. Poiche' il prezzo dell'auto dipende dalla motorizzazione, sposto l'attributo prezzo dall'entità Automobile a quella Motorizzazione.
Il prezzo finale dell'auto e' dato da: P = (prezzo dell'auto) + (prezzo optional) + (costo riparazione) - (sconto).
In questo modello la parte della vendita non prende in considerazione la fatturazione, ovviamente questa e' una semplificazione della realta' di un concessionario auto.

Software Dev Notes

Friday, July 6, 2018

Basi di Dati: Il modello concettuale