Sistemi di Gestione Dati

Sistemi di Gestione Dati

Corso Laurea Odontoiatria &

Corso Laurea Ostetricia aa 2015/2016

Università di Perugia

Cos’è un database

 Un database è fondamentalmente una collezione di registrazioni (record) che concernono qualche sorta di azione od oggetto.

 Più formalmente, un database è qualsiasi collezione di “fatti” organizzati in modo sistematico.

 Es. Le schede del catalogo di una biblioteca. Ogni

scheda, fisica o virtuale, contiene fatti (autore, titolo, ISBN, etc.) che sono organizzati (alfabeticamente per titolo o autore, numericamente per ISBN) al fine di rendere la loro ricerca più semplice rispetto ad una scansione di tutti i libri della biblioteca.

Tipi di Sistemi di Gestione di Base di Dati (DBMS)



Esistono diversi tipi di database:

 Database gerarchici

 Database a rete

 Database relazionali

 Database a oggetti



Access, MySQL, SQL Server etc. sono database relazionali

Es. Scheda e

Rappresentazione

Tabellare

Terminologia



Un certo numero di termini descrivono le parti di un database. Sono termini standard,

indipendenti dal particolare software con cui è implementato il database.



Campo - è l’unità strutturale di base del

database. È il contenitore per un dato o per ogni sua parte logica.

Ad esempio, un indirizzo di posta potrebbe essere il campo ma, in un diverso contesto, potrebbero essere campi separati la via, il numero civico, la città, lo stato ed il codice postale.

Terminologia



Record o n-upla - è un insieme di campi che descrivono un’unità più grande. È detto anche riga. I campi in un record forniscono una

descrizione completa di ogni elemento in una collezione. Un record è un’istanza unica di dati che riguardano un oggetto o un evento.



Tabella o Relazione - è il nome formale dato ad un gruppo di record che contengono gli

elementi di una collezione. Di norma una tabella rappresenta un oggetto distinto (es.

tabella libri in una biblioteca) o un evento (es.

tabella degli ordini per un prodotto).

Schemi Relazionali

 Uno Schema Relazionale è costituito da un insieme di schemi di relazione (o relazioni) R_i : {T_i}, i=1, 2,…, k e da un insieme di vincoli di integrità relativi a tali schemi.

 Una n-upla t=(A₁:= v₁, A₂:= v₂,…, A_n:= v_n) di tipo (A₁ :T₁ , A₂ :T₂ , …, A_n :T_n) è un insieme di coppie (A_i , v_i) con v_i di tipo T_i.

 Una Relazione R di tipo {(A₁ :T₁ , A₂ :T₂ , …, A_n :T_n)}

è un insieme finito di n-uple di tipo (A₁ :T₁ , A₂ :T₂ , …, A_n :T_n).

 La cardinalità di una relazione è il numero di n-uple

Esempio di relazione

 E’ una relazione di tipo {(Nome : char , Matricola : int ,Indirizzo : char ,

Telefono :int )} e ciascuna riga è una n-

upla della relazione.

Terminologia

 Chiave - è un identificatore univoco per ogni riga (record) in una tabella di dati.

 Anche se un record singolo rappresenta una porzione separata dei dati, alcuni di questi records possono

apparire identici.

 La chiave rappresenta un modo non ambiguo per

identificare record distinti e serve come puntatore ad un particolare record della tabella.

 Es.: ogni cittadino italiano è univocamente identificato dal codice fiscale.

 In molti casi, le chiavi per le tabelle dei dati sono costruite semplicemente aggiungendo un campo al record con funzione di chiave.

Terminologia

Esempio di schema relazionale

{ Studenti : { (Nome: char , Matricola: int(6) ,Indirizzo : char, Telefono :int(6)) }

Esami : { (Corso: char , Matricola: int(6) ,Voto: {18,19,

…,30} }

Corsi : { (Corso:char, Professore:char) } }

 Che si abbrevia (se non interessa riportare il tipo degli attributi) in:

 Studenti( Nome, Matricola, Indirizzo, Telefono);

Esami( Corso, Matricola,Voto);

Corsi( Corso, Professore);

Dominio di un attributo



dom(Ai) e’ l’insieme dei possibili valori dell’attributo A_i



ad esempio nella tabella

Studenti(Corso,Matricola,Voto) , dom(Voto) = {18,19,…,30}

Vincoli di integrità

 I vincoli di integrità servono a migliorare la qualità delle informazioni contenute nella base di dati

 Un vincolo è un predicato che deve essere soddisfatto da ogni n-upla nella base di

dati

 Un’istanza valida di uno schema di

relazione è una relazione dello schema che

soddisfa tutti i vincoli di integrità.

Esempio di vincoli d ’integrità

 Il voto deve essere compreso tra 18 e 30

 La lode può apparire solo se voto=30

 Ogni studente deve avere un numero di matricola

 Il numero di matricola di uno studente deve essere univoco

 Esami dati devono fare riferimento solo a

corsi offerti

Vincoli d’integrità



I tre tipi più importanti specificano:

 Quali attributi non possono assumere il valore NULL

 Quali attributi sono chiave

 Quali attributi sono chiavi esterne

Mancanza di informazione

 Il modello relazionale impone una struttura rigida ai dati, in quanto:

 L’informazione viene rappresentata per mezzo di n-uple

 Le n-uple hanno uno schema ben definito

 Come rappresentare quindi, ad esempio, il fatto che di uno studente non si conosce il numero di cellulare?

 Usanza comune:

 Usare valori non utilizzati (es. 0 per eta’ studente)

 Problemi:

 Possono non esserci valori inutilizzati

 Il valore inutilizzato puo’ diventare utile

 In alcuni casi bisogna ricordarsi di distinguere i valori reali dei

“riempiposto”, esempio: media dell’eta’ degli studenti (se

rappresentiamo il fatto di non conoscere l’eta’ dello studente con 0)

Valori nulli (NULL)

 Il modello relazionale include il “NULL value” come tecnica per modellare la mancanza di informazione

 NULL non fa parte del dominio dell’attributo

 Quando si da ad un attributo la possibilità di avere valore null, si ammette che quell’attributo in qualche n-upla può rimanere non specificato e/o venire assegnato in un secondo momento

 Il valore NULL per un certo attributo può indicare:

 Il valore non c’è;

 Il valore c’è ma non lo si conosce al momento;

 Non si sa se il valore c’è;

 I Sistemi di Gestione di Dati non modellano il perché manca il dato, si limitano a denotarne la sua mancanza

Esempio di valori nulli

Il Telefono di Ugo Bianchi può non esserci,

esserci ma non conosciuto, in attesa di essere installato

Chiavi

 Superchiave X di uno schema di

relazione è un insieme di attributi dello schema tale che in ogni istanza dello schema se due n-uple coincidono su X allora sono uguali.

 Chiave è una superchiave minimale rispetto alla relazione .

 Chiave Primaria è una delle chiavi scelta

per un dato schema.

Esempi di chiavi

 {Nome,Matricola} è una superchiave ma non è una chiave, infatti

 {Matricola} è una chiave e si sceglie anche come primaria per accedere ai vari record

 {Indirizzo} non è superchiave

Chiavi esterne



Un insieme di attributi {A1, A2 , …, An} di uno schema di relazione R è una chiave esterna

che riferisce una chiave primaria {B₁, B₂ , …, B_n} di un altro schema S se in ogni istanza valida

della base di dati, per ogni n-upla r dell’istanza di R esiste una n-upla s (riferita da r) dell’istanza di S tale che r.Ai = s.Bi.

Esempio chiave esterna

 Una chiave esterna associa a certe n-uple della relazione r (quelle aventi la stessa chiave esterna) una ben

determinata n-upla della relazione s a cui si riferisce determinata dai valori della chiave primaria(cioè della chiave esterna)

 Così {Matricola} per Esami è chiave esterna che si riferisce a Studenti

Esami

Studenti

Tipi di database



Esistono diversi modi in cui i database sono implementati. Si possono individuare tre

categorie di base:

 database flat-file

 database relazionali

 database orientati agli oggetti

Flat file

 È il tipo più elementare di organizzazione dei dati in un database. La caratteristica base di un flat-file è che tutti i dati sono memorizzati insieme in una singola tabella. La maggior parte dei database cartacei appartengono a questa categoria.

 Caratterizzati da semplicità di progetto e

implementabili in modo diretto. Un semplice file di testo con dati organizzati può rappresentare un flat- file.

 È il tipo di organizzazione meno efficiente e più

problematica. Il maggior svantaggio è dovuto al fatto che parte dei dati inseriti possono essere ridondanti o inconsistenti.

Flat-file: database di ordini

Database Flat-file



Il database dell’esempio precedente ha un evidente problema di progetto: ogni record è relativo all’ordine di un solo prodotto per un dato cliente.



Se un cliente ordina prodotti diversi, si avranno tanti records per il cliente quanti sono gli ordini (come mostrato per il cliente con CustID=1567)

 questo porta alla duplicazione dei dati relativi al cliente (Name, Shipping Address) in ognuno di questi record.

Database Flat-file



In maniera alternativa, il problema potrebbe essere risolto aggiungendo alla tabella un altro insieme di campi (colonne della tabella)

ItemCode, Price e Quantity, numerandoli in sequenza (così da distinguere i campi per il primo prodotto da quelli del secondo e dei successivi).

Database Relazionali

 Sono stati sviluppati con l’obiettivo di prevenire una non necessaria duplicazione dei dati nel

database.

 Il problema, nell’esempio del database di ordini, nasce dal fatto che nella tabella sono

rappresentate due entità logicamente distinte:

 il cliente e i dati ad esso relativi;

 l’insieme di prodotti che sono stati ordinati.

 In un database relazionale ogni entità

logicamente distinta dalle altre è rappresentata in una differente tabella del database.

Database Relazionali:

tabella di ordini



Due tabelle:

 tabella ordini, con i dati relativi al cliente;

 tabella prodotti, con i dati relativi ai prodotti di ogni singolo ordine.

Tabella di ordini

Database Relazionali

 La chiave OrderID nella tabella degli ordini descrive univocamente ciascun ordine di un cliente.

 Ogni prodotto ordinato è individualmente e univocamente memorizzato in una tabella separata dei prodotti.

 Il cliente può, nello stesso ordine, richiedere quanti prodotti desidera senza limitazioni a priori sul

numero massimo, né spreco di memoria.

 Tra le tabelle è stabilita una relazione tramite le rispettive chiavi.

Database Relazionali



Ogni tabella ha la propria chiave primaria per identificare i suoi elementi.



Notare che la chiave OrderID della tabella degli ordini è inserita nella tabella dei prodotti per

ogni prodotto che è stato ordinato da un cliente.



Ogni prodotto che è stato ordinato può essere legato al cliente appropriato cercando tutti i records della tabella prodotti che hanno un particolare valore nel campo OrderID.

Relazione Uno-a-Molti

 Nella tabella dei prodotti OrderID non è un valore univoco.

 La relazione tra la tabella degli ordini e quella dei prodotti è detta relazione uno-a-molti in quanto un record nella tabella degli ordini è legato ad un

numero variabile di records nella tabella dei prodotti.

 OrderID serve come chiave esterna nella tabella dei prodotti, in quanto il valore della chiave viene da una diversa tabella (dove i valori sono univoci).

Database ordini



Nota: per evitare la duplicazione degli indirizzi di un cliente tra più ordini successivi sarebbe

conveniente creare una ulteriore tabella dei

clienti, con solo i dati relativi al cliente, e legarla con una relazione uno-a-molti, stabilita

attraverso il CustID, con la tabella degli ordini.

 In questo modo ogni cliente può effettuare più ordini ed ogni ordine può comprendere più

prodotti.

Tabella Ordini

Tipi di relazioni



Oltre alla relazione uno-a-molti esistono altri due modi possibili per relazionare due tabelle del

database:

 relazione uno-ad-uno;

 relazione uno-a-molti (già descritta in precedenza)

 relazione molti-a-molti.

Relazioni uno-a-uno



In una relazione uno-a-uno ogni record in una

tabella è collegato ad uno ed uno solo dei record in un’altra tabella.



Nella maggior parte dei casi, questo tipo di relazione è stabilita tra una tabella che

rappresenta un insieme di dati relativi ad un sottoinsieme delle entità in una tabella

“principale”, e la tabella principale stessa.

Relazioni uno-a-uno

Relazioni uno-a-uno

 La tabella degli impiegati ha un record per ogni impiegato dell’azienda ed usa EmployeeID come chiave primaria per identificarli in modo univoco.

 Supponiamo che l’azienda preveda due tipi di impiegati:

 salariati;

 _{a ore.}

 La tabella impiegati contiene solo i dati di base relativi ad entrambe le categorie: nome,

cognome, indirizzo e numero telefonico.

Relazioni uno-a-uno



Dato che per le due categorie di impiegati devono essere mantenuti dati diversi, questi sono inclusi in due tabelle ausiliarie:

 la tabella degli impiegati a ore. Mantiene solo i dati aggiuntivi che li riguardano, come il costo orario e le ore lavorate;

 la tabella degli impiegati salariati. La tabella mantiene solo i dati specifici per questa categoria, come il salario complessivo e l’informazione sanitaria.



Per entrambe le tabelle ausiliarie la chiave primaria è rappresentata da EmployeeID.

Relazioni uno-a-uno

 Ogni impiegato può apparire una sola volta nella tabella impiegati, ed un record nella tabella degli impiegati a ore rappresenta un solo impiegato.

Lo stesso vale per la tabella degli impiegati salariati.

 L’uso della relazione uno-a-uno tra la tabella

principale e ciascuna delle due tabelle ausiliarie ha permesso di separare i dati che riguardano solo

sottoinsiemi di records nella tabella principale. In questo modo non è stato necessario inserire campi aggiuntivi nella tabella principale con conseguente risparmio di memoria.

Database Relazionali:

Relazioni molti-a-molti



La caratteristica distintiva di una relazione molti- a-molti tra due tabelle è che una terza tabella è necessaria per rappresentare la relazione.



La tabella che descrive la relazione

semplicemente mantiene la chiave primaria da una tabella, con la chiave primaria dei record ad essa collegati nella seconda tabella, insieme con ogni altra informazione che contraddistingue la relazione.

Relazioni molti-a-molti



La relazione molti-a-molti permette di

rappresentare relazioni in casi in cui più record in una tabella sono in relazione con più record in un’altra tabella.



Un esempio classico è quello di un database di corsi e studenti. Ogni corso è seguito da più

studenti, ma ogni studente segue molti corsi.

Perciò è necessaria una relazione molti-a-molti tra la tabella dei corsi e quella degli studenti.



Un altro esempio è quello della relazione tra impiegati e progetti.

Relazioni molti-a-molti

Relazioni molti-a-molti

 Database di progetti che tiene tracia degli impiegati che lavorano su ciascun progetto.

 Ogni impiegato dell’azienda lavora a molti progetti, ed ogni progetto ha molti impiegati dedicati al suo svolgimento.

 Sono individuate due tabelle per rappresentare le due entità distinte:

 tabella impiegati;

 tabella progetti.

 È necessaria un’ulteriore tabella per rappresentare la relazione molti-a-molti tra impiegati e progetti.

Relazioni molti-a-molti



La tabella di relazione tra impiegati e progetti è costruita usando le chiavi primarie delle tabelle impiegati e progetti.



Sia i valori della chiave per la tabella degli

impiegati (EmployeeID), sia quelli della chiave per la tabella dei progetti (ProjectID), possono essere ripetuti più volte nella tabella della

relazione.

Esempio Microsoft Access

Esempio Microsoft Access

Esempio Microsoft Access

SQL: un linguaggio di interrogazione



Structured Query Language (SQL) è un

linguaggio di interrogazione per database progettato per

 _leggere,

 modificare

 gestire dati memorizzati in un sistema basato sul modello relazionale

 creare e modificare schemi di database

 creare e gestire strumenti di controllo ed accesso ai dati.

Evoluzione del linguaggio

• Le origini di SQL si trovano in un documento del 1970 realizzato da Edgar Codd, “A Relational Model of Data of Large Shared Data

Banks”.

• La prima versione fu sviluppata da IBM all'inizio degli anni settanta.

Chiamata originariamente SEQUEL era progettata per manipolare dati memorizzati nel database relazionale ideato e brevettato da IBM.

• Primo standard SQL-86 pubblicato da ANSI e ratificato da ISO nel 1987

o (ANSI e ISO sono due organismi internazionali che si occupano della standardizzazione delle tecnologie).

• SQL-92 (SQL 2) è lo standard a cui fanno riferimento la maggior parte dei DBMS.

• L’evoluzione del linguaggio ha portato a due ulteriori versioni:

SQL:1999 (oggetti) e SQL:2003 (xml).

Utilizzo di SQL

 Interattivo

 L’utente utilizza un software, in genere fornito con il DBMS, in cui introdurre comandi SQL che vengono inviati al DBMS.

 All’interno di applicazioni software

 L’interazione con il database è scritta in SQL mentre il resto dell’applicazione software in un comune

linguaggio di programmazione.

 I comandi SQL possono essere poi collegati nel programma in due modalità differenti:

 “ospitati” nel codice del software e inviati al DBMS all’occorrenza.

 memorizzati all’interno del DBMS e quindi richiamati dal programma.

SELECT



Per estrarre informazioni dalla base di dati si utilizza l’istruzione SELECT.



La sintassi completa dell’istruzione SELECT è

complessa perché l’istruzione implementa varie funzionalità.

SELECT (proiezione)

SELECT [DISTINCT]

<Campo1> [AS “Alias1”],

<Campo2> [AS “Alias2”], …

<CampoN> [AS “AliasN”]

FROM <Tabella1>, <Tabella2>, … <TabellaN>

DISTINCT - Questa opzione permette di ottenere solo tuple differenti tra loro.

<Campo> - Elenco dei campi da estrarre.

<Tabella> - Tabella in cui sono contenuti i campi da estrarre.

“Alias” - Etichetta da assegnare al campo nella selezione (facoltativa).

*: Sostituendo * ai nomi dei campi implica la selezione di tutti i campi della tabella specificata.

Esempi

• Selezione di un’intera tabella SELECT *

FROM Genere

• Selezione di alcuni campi di una tabella (proiezione) SELECT fi_titolo, fi_regia

FROM Film

• Selezione (senza duplicazione) SELECT DISTINCT fi_titolo

FROM Film

SELECT (restrizione)

Per estrarre informazioni dal DB, limitate da una condizione:

SELECT [DISTINCT]

<Campo1>, <Campo2>, … <CampoN>

FROM <Tabella>

[WHERE <Condizione>]

<Condizione> - Indica la condizione che devono soddisfare le tuple estratte.

All’interno di questa espressione è possibile specificare:

nomi dei campi della tabella;

operatori di confronto, come =, <>, >, >=, <=, <;

operatori logici come NOT, AND, OR;

la parola chiave IS NULL o IS NOT NULL.

Esempi

• Selezione delle righe che soddisfano una condizione (restrizione)

SELECT * FROM Film

WHERE fi_durata>100

• Selezione con condizione composta SELECT *

FROM Film

WHERE fi_durata>100 AND fi_titolo IS NOT NULL

SELECT (join)

• Per concatenare due tabelle in base ad un campo comune (JOIN) può essere utilizzata l’istruzione SELECT-WHERE, con una particolare condizione:

SELECT [DISTINCT]

<Campo1>, <Campo2>, … <CampoN>

FROM <Tabella1>, <Tabella2>, … <TabellaN>

WHERE <Tabella1>.<Campo1> = <Tabella2>.<Campo2>

Esempi

•

Primo formato SELECT *

FROM Film, Genere

WHERE Film.fi_genere = Genere.ge_codice

Esempio di Base di Dati



ATTORI (CodAttore, Nome, AnnoNascita, Nazionalità);



RECITA (CodAttore, CodFilm)



FILM (CodFilm, Titolo, AnnoProduzione, Nazionalità, Regista, Genere)



PROIEZIONI (CodProiezione, CodFilm, CodSala, Incasso, DataProiezione)



SALE (CodSala, Posti, Nome, Città)

Esempi di QUERY



1. Il numero di sale di Torino con più di 60 posti SELECT count(*)

FROM SALE AS s

WHERE s.Città = "Torino" and s.Posti > 60



2. Il numero totale di posti nelle sale di Torino SELECT sum(s.Posti)

FROM SALE AS s

WHERE s.Città = "Torino"

Esempi di QUERY

 3. Per ogni città, il numero di sale con più di 60 posti

 SELECT s.Città, count(*) FROM SALE AS s WHERE s.Posti > 60

GROUP BY s.Città

 4. Per ogni regista, l’incasso totale di tutte le proiezioni dei suoi film

 SELECT f.Regista, sum(p.Incasso) AS IncassoTotale FROM FILM AS f, PROIEZIONI AS p

WHERE f.CodFilm = p.CodFilm GROUP BY f.Regista

Anche in Microsoft Access