I DATABASE DBMS

UN DATABASE E’ UN MODELLO (SU Un Data Base Management System è una raccolta di strumenti
che permettono di strutturare, manipolare e gestire i dati di un
COMPUTER) DELLA REALTA’. database che deve possedere almeno le seguenti caratteristiche:
Gli archivi costituiscono una memoria di lavoro indispensabile per
gestire quantità ingenti di informazioni, per ordinare gli elementi utili,
Strumenti per la definizione dei dati
metterli in collegamento e selezionare i dati che devono essere Strumenti per l’immissione e la modifica dei dati
utilizzati nelle varie circostanze. Strumenti per l’interrogazione l’estrazione dei dati
La creazione di software specifici per la gestione di banche dati,
Strumenti per la generazione di report
chiamati DBMS (Data Base Management System), ha permesso di
Strumenti di programmazione
unificare in un unico programma applicativo le funzionalità di
Strumenti di amministrazione
archiviazione e gestione dei dati.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi

MODELLI DI DATABASE MODELLO RELAZIONALE

Esistono vari modelli organizzativi di database, ossia basi Il nome RELAZIONALE deriva dalle
teoriche a cui si conformano i progettisti dei DBMS.
Il modello gerarchico. Trattazione omessa.
TABELLE, che sono il modo, facile ed
Il modello reticolare. Trattazione omessa.
intuitivo, scelto per rappresentare gli
“insiemi”, le “collezioni” di dati.
Proprio la teoria degli insiemi, dove il termine
Il modello RELAZIONALE è quello che
“relazione” è sinonimo di “tabella” sta alla
trattiamo in questo corso
base di questo modello.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi
 MODELLO RELAZIONALE MODELLO RELAZIONALE
Origini del modello relazionale Progettazione (disegno o design)
Il modello relazionale è stato proposto dal matematico Edgar Codd, un ricercatore dell’IBM, alla fine
degli anni 60. La vera forza del modello relazionale è che (almeno finora) esso è l’unico modello di un database relazionale.
definito per mezzo di rigorosi principi matematici astratti. La grande innovazione di Edgar Codd, infatti, La teoria relazionale di Codd ha il grande pregio della
era l'aver intuito che il modello organizzativo dei dati poteva essere basata sulla teoria matematica
degli insiemi e che si potevano avere risultati rigorosamente prevedibili tramite le normali operazioni formalizzazione, e quindi rigorosità, matematica. Però metterla in
insiemistiche applicate ai dati di un database. pratica nella sua interezza si è dimostrato in concreto impossibile.
In altri termini, il modello relazionale può essere dedotto a partire da principi primi o assiomi
matematici. Ecco quindi che nel 1976 è stata elaborata da Peter Pin-Shan
Chen una diversa proposta, che sarà quella da noi adottata:
Il modello Entità – Relazioni (E/R)
“The Entity – Relationsip Model – Toward A Unified View Of
Data” (Marzo 1976).

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi

E/R – ENTITA' E/R – ENTITA'

Entità … Questa caratteristica fa sì che l’intera metodologia posta
Il primo passo della metodologia E/R consiste dall’E/R risulti scarsamente scientifica e che quindi nonostante
nell’individuare le Entità, cioè quelle cose o quegli oggetti l’insieme dei passi da seguire per pervenire allo schema E/R sia
del mondo reale (ricordiamo la definizione iniziale di molto ben definito, l’effetto finale è che non esiste uno schema
database!) dei quali abbiamo necessità di conoscere delle E/R “giusto”, nel senso che l’analisi di persone diverse potrebbe
informazioni. portare allo sviluppo di schemi differenti, in quanto già i punti di
partenza potrebbero essere diversi (potrebbero essere cioè
Questo, all’interno dell’E/R è il punto più critico in quanto il diverse le entità individuate in questa prima fase).
concetto di entità risulta scarsamente formalizzato. Si tratta di un Esempi di entità : le Persone, i Prodotti, le Ditte, i Clienti, i Soci
concetto non definito in termini rigorosamente matematici, bensì del club, ecc.(si usa scrivere con la maiuscola)
fortemente intuitivo....
Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi
 E/R – ATTRIBUTI E/R – RELAZIONI
Attributo Relazioni (legami)
Il secondo passo della metodologia E/R consiste Il terzo passo della metodologia E/R consiste nell'identificare
nell'identificare e descrivere l’insieme delle caratteristiche e descrivere i legami, i collegamenti, le correlazioni fra le
degli elementi, ossia degli oggetti, appartenenti a ciascuna entità, che per uniformità con la terminologia di Access/Base
entità. Tali caratteristiche si dicono attributi. chiameremo RELAZIONI.
Esempi : nome-cognome-data di nascita delle Persone; codice- Esempi : fra le Ditte e i Prodotti ci potrebbe essere il legame (la
costo-descrizione dei Prodotti; ecc. relazione) “quale ditta produce un certo prodotto”, oppure fra
Clienti e Fatture “a quale cliente è stata emessa una fattura”, ecc.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi

E/R – RELAZIONI
Un esempio di legami uno a molti è quello che intercorre tra un
cliente e un ordine che ha fatto (es. il sig Pinco e il suo ordine di
bibite). Infatti un ordine fa capo ad un unico cliente, ma quel
cliente può fare molti ordini.
Invece il legame tra potrebbe intercorrere fra due ipotetiche
entità, le Persone e i Telefoni, sarebbe un legame molti a molti
in quanto una persona può avere più telefoni e ad uno stesso
telefono, possono corrispondere più persone.
Un tipico legame uno a uno è quello tra una persona e una carta
di identità: una persona può avere una carta di identità, una carta
di identità deve appartenere ad una sola persona.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi
 E/R – RELAZIONI
Nell'esempio “un Cliente fa MOLTI Ordini, mentre un Ordine
proviene da UN SOLO Cliente” abbiamo detto che c'è una
relazione 1 a M.
Però ATTENZIONE ! Nel giudicare il tipo delle relazioni si deve
pensare alla POSSIBILITA' che l'evento reale accada. Per es un
Cliente PUO' fare Ordini, non è detto che tutti i clienti li facciano.
Cioè la condizione è sufficiente, ma non necessaria. In compenso
un Ordine NON PUO' appartenere a più Clienti, quindi NON c'è
un legame 1 a M fra Ordine e Cliente.
Altro esempio : 1 Ordine (contiene) M prodotti, ma anche 1
Prodotto (sta in) M Ordini. Si tratta di un legame Molti a Molti.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi

CHIAVE PRIMARIA CHIAVE PRIMARIA

PRIMARY KEY (PK) PRIMARY KEY (PK)
Gli oggetti appartenenti ad una entità devono essere Talvolta l'attributo opportuno non esiste: in tal caso si sceglie una
identificabili in maniera univoca, in modo ciascuno di loro combinazione di attributi (p.es. nome+cognome+data di nascita),
risulti separato e identificabile da tutti gli altri della stessa oppure si “inventa” un nuovo attributo atto allo scopo (p.es. un
entità. P.es. nell'entità Persone ogni persona si deve distinguere numero di matricola o un semplice contatore progressivo).
dalle altre. A tale scopo è necessario individuare all’interno di
ciascuna entità un attributo tale per cui ogni oggetto ha un valore Per quanto sia possibile creare entità prive di PK (p.es. Tabelle di
diverso da tutti gli altri (p.es. il codice fiscale delle persone). Tale decodifica), si sconsiglia vivamente di farlo (e noi non lo faremo
attributo viene chiamato MAI), ma specialmente, come vedremo,
CHIAVE PRIMARIA la PRESENZA di PK è l'elemento INDISPENSABILE,
all'atto pratico, per definire le RELAZIONI fra entità.
(o Primary Key, abbreviato PK)
Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi
 REALIZZAZIONE DI UN REALIZZAZIONE DELLE
DATABASE IN UN DBMS RELAZIONI NEI DBMS
Le relazioni 1 → M sono molto frequenti nei database, e vengono
Come si poteva intuire già dalle slides introduttive, le ENTITA' definite in Access/Base mediante un metodo grafico, però
vengono realizzate, all'atto pratico nei DBMS, tramite delle abbisognano di una operazione preliminare a livello di
TABELLE, in cui gli ATTRIBUTI sono le COLONNE (in perfetta progettazione.
analogia con i fogli di calcolo), mentre le RIGHE sono gli oggetti Per realizzare una 1 → M si deve aggiungere
appartenenti all'entità.
alla tabella lato Molti un NUOVO CAMPO,
In terminologia database : (cioè colonna) corrispondente alla PK del
Le colonne sono chiamate CAMPI lato Uno, che viene chiamato
Le righe sono chiamate RECORD
Uno o più campi costituiscono la PK CHIAVE ESTERNA (Foreign Key o FK).
P.es.il Codice (fiscale) del cliente va aggiunto – come nuovo
campo - alla tabella Ordini
Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi

REALIZZAZIONE DELLE REALIZZAZIONE DELLE

RELAZIONI NEI DBMS RELAZIONI NEI DBMS
Le relazioni M ←→ M non sono hanno una rappresentazione
Non è necessario che il campo FK abbia lo stesso nome del diretta nel DBMS: anche qui è necessaria una soluzione
campo PK, la corrispondenza NON avviene in base al nome. preliminare a livello di progettazione.
Consiglio, anzi, di usare per la FK un nome che richiami la tabella Bisogna individuare una terza tabella, da inserire in mezzo alle
della PK (specie quando il nome della PK è generico, tipo due, la quale avrà una relazione 1 → M con ciascuna delle due
“Codice”). Quindi ATTENZIONE al significato delle chiavi e non al tabelle di partenza....(segue)
loro nome. Come detto, in Base/Access la realizzazione pratica
delle relazioni si fa con un metodo grafico che prescinde dai nomi
dati ai campi.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi
 RELAZIONI M - M
Per realizzare una M←→M si deve
AGGIUNGERE UNA NUOVA tabella (“di
intersezione”) contenente, come FK, le 2 PK
delle tabelle di partenza. Tabella che si
troverà dal lato Molti di 2 relazioni 1 → M .
La PK della tabella di intersezione sarà
costituita dalla combinazione delle 2 FK.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi

RELAZIONI M - M RELAZIONI 1 - 1
Non è obbligatorio inserire nella tabella di intersezione altri campi Le relazioni 1 - 1 non sono altro che relazioni 1 – M in cui il lato M
oltre alle due FK, però facendolo si chiarisce meglio la natura viene limitato a 1.
della relazione M-M, e in numerosi casi è NECESSARIO inserire P.es. si potrebbe imporre la regola che ogni Cliente può fare al
in questa tabella campi che altrimenti non troverebbero massimo UN Ordine. Quindi il caso del legame 1-1 si risolve
collocazione nelle altre 2 tabelle. Si capirà meglio quando come quello 1 – M, ma è possibile scegliere da quale parte
vedremo gli esempi pratici. mettere la FK.
Si obietta spesso che in realtà le relazioni 1 – 1 non dovrebbero
esistere, in quanto si potrebbe inserire tutti gli attributi (delle 2
tabelle) in un'unica tabella. I motivi che giustificano la loro
esistenza stanno nella situazione REALE che il database deve
rappresentare.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi
 I DATABASE

Fine della parte teorica.

Passeremo ora a delle realizzazioni pratiche

utilizzando il software Base della suite
LibreOffice oppure MS Access.

Università degli studi di Trieste Informatica A.A. 2016/17 Docente: Ing. Daniele Bassi