Database

10/06/16 Ing. Ronchi Sergio 1
Relational DB
I database relazionali sono stati concepiti nel 1969 e sono diventati quelli largamente più
utilizzati fino ad oggi. Il padre del modello relazionale è stato il Dottor Edgar F. Codd, un
matematico che lavorava come ricercatore in IBM negli anni ’60.
Il Dot. Codd presentò formalmente il modello in un lavoro intitolato "A Relational Model of
Data for Large Shared Databanks" pubblicato nel giugno del 1970.
Un database relazionale memorizza i dati in relazioni, che l’utente percepisce come tabelle.
Ogni relazione è composta da tuples (o records) e attributi (o campi). Ogni record è identificato
da un campo univoco.
Una relazione tra due tabelle si ottiene implicitamente attraverso una corrispondenza logica dei
valori contenuti.
Il modello relazionale classifica le relazioni in tre categorie di base uno-a-uno, uno-a-molti,
molti-a-molti.

Esempio
In questo esempio abbiamo due tabelle Agents e Clients con diversi campi. Ogni record di una
tabella è identificato da un campo identificativo (Agent ID) e (Client ID). Le due tabelle sono
in relazione attraverso Agent ID: nella tabelle Clients il campo Agent ID identifica l’agente
che segue quel cliente.
Si tratta chiaramente di una relione uno a molti in quanto evidentemente un agente potrà
seguire molti clienti, non è invece possibile il viceversa nello schema indicato.

Vantaggi dei DB relazionali
L’uso appropriato del modello relazionale comporta grossi vantaggi:
• Integrità dei dati: a livello di campo, di tabella e di relazione
• Indipendenza del modello logico dei dati da quello fisico. Questo comporta che il disegno
logoco dei dati non deve essere rifatto cambiando il software di gestione dei dati.
• Consistenza e congruenza dei dati.
• Facile lettura dei dati grazie al linguaggio di interrogazione SQL.

RDBMS
(relational DB management system)
E’ il software che si usa per creare, gestire, modificare i db relazionali. Alcuni RDBMS
contengono anche stumenti per creare i front-end con gli utenti.
Negli anni ’70 esistevano solo RDBMS su mainframe, già negli anni ’80 vedevano la luce
i sistemi DB2 (di IBM) e Oracle e i primi RDBMS per PC come FoxPro, Paradox, Access.
Questi ultimi non sono altro che software che permettono una gestione avanzata di un file
contenente dati.
Negli anni ’90 venne incrementato e semplificato il sistema di sicurezza dei maggiori
RDBMS e si sviluppò il concetto dei DB server con i relativi client, questo per permettere
una consultazione remota.
Alcuni dei DB server utilizzati oggi sono:
Oracle
MS SQL Server
MySQL
PostgreSQL

Prima forma normale (1NF)
Richiede che i dati nelle tabelle siano bi-dimensionali, che non ci siano gruppi ripetuti
nelle righe (campi non atomici). Un esempio che non rispetta la prima forma normale è il
seguente:
Employee(ID,name, address, {dependent name})
dove {dependent name} è un attributo che potrebbe essere ripetuto inutilmente.
1,Smith, 123 4th St., {John, Freeman, Lance, Ramirez}
2,Jones, 4 Moose Lane., {Sartis, Franklin, Ribon}
3,Adams, 88 Tiger Circle., {McGregor, Lancom, Martins}
Il campo non atomico non è facilmente indicizzabile e dimensionabile. Inoltre è difficile
effettuare ricerche mirate all’interno di tali campi.

Normalizzazione 1NF
Employee
Emp_ID name address
00001 Smith 123 4th St
00002 Jones 4 Moose Lane
00003 Adams 12 Roger Square
00004 John 31 Ricon Avenue
00005 Freeman 12 Pingon Hil
00006 Lance 32 Mary Rose Lane
00007 Ramirez 21 Stinger Square
00008 Sartis 1 Abby Road
……..
Dependent
Dep_ID Emp_ID
00004 00001
00005 00001
00006 00001
00007 00001
00008 00002
…….. ………
Nella tabella ‘Dependent’ la primary key è
formata dall’accoppiata dei due campi.
Singolarmente Dep_Id e Emp_id sono
foreign key e puntano alla tabella Employee

Normalizzazione 1NF con autoreferenza
Employee
Emp_ID name address Boss_Id
00004 John 31 Ricon Avenue 00001
00005 Freeman 12 Pingon Hil 00001
00006 Lance 32 Mary Rose
Lane
00001
00007 Ramirez 21 Stinger Square 00001
00008 Sartis 1 Abby Road 00002
La colonna Boss_Id è una Foreign_key che
punta all’Emp_Id, ma si tratta di un caso
particolare in cui il collegamento avviene
con la tabella stessa

Seconda forma normale (2NF)
Richiede che i dati di una riga dipendano dalla chiave primaria nel suo complesso, non sono da una
parte della stessa (Questo implica avere una PK fromata da più di un campo) . Esempio
Employee (name, job, salary, address)
Se la PK è la combinazione di name e job, questa definisce il salario, ma l’indirizzo dipende solo dal
nome e non dal lavoro.
Name Job Salary Address
Smith Welder 14.75 123 4th St
Smith Programmer 24.50 123 4th St
Smith Waiter 7.50 123 4th St
Jones Programmer 26.50 4 Moose Lane
Jones Bricklayer 34.50 4 Moose Lane
Adams Analyst 28.50 88 Tiger Circle
Come si può vedere l’indirizzo è ripetuto in modo ridondante. Questo porta a una anomalia di
inserimento: ad esempio se si vuole inserire una persona e a questa persona non è ancora stato
assegnato un lavoro, non è possibile farlo perché un campo chiave non può contenere un valore null.
Un’anomalia di aggiornamento: se Smith cambiasse l’indirizzo, si dovrebbero cambiare 3 righe per
completare l’aggiornamento.

Normalizzazione 2NF
Employees
Emp_ID name address
……..
Jobs
Job_ID Description
A Welder
B Programmer
C Bricklayer
D Analyst
E Waiter
Salaries
Emp_ID Job_ID Salary
00001 A 14,75
00001 B 24,50
00001 E 7,50
00002 B 26,50
00002 C 34,50
00003 D 28,50
Nella Tabella Salaries la primary key è
formata dalla coppia Emp_ID, Job_ID.
Songolarmente Emp_ID è una FK che punta
alla tabella Employess e Job_ID è una FK
che punta alla tabella Jobs

Terza forma normale (3NF)
Richede che i dati dipendano solo dalla chiave primaria. Un classico esempio errato è:
Employee (name, address, project#, project-location)
Si ipotizzi che project-location significhi il luogo da cui il progetto viene controllato e
dipenda dal codice del progetto project#:
Name Address Project# Project-location
Smith 123 4th St 101 Memphis
Smith 123 4th St 102 Redmond
Jones 4 Moose Lane 101 Memphis
Si noti la ridondanza che porta alle stesse anomalie viste prima. In particolare si ha una
anomalaia di cancellazione in più in quanto eliminando la seconda riga si elimina Smith,
ma si elimina anche l’informnazione che il progetto 102 è controllato da Redmond.

Normalizzazione 3NF
Employees
Emp_ID name address
……..
Projects
Project_ID Location
101 Memphis
102 Redmond
Nella Tabella Emp_Projects la primary key è
formata dalla coppia Project_ID, Emp_ID.
Songolarmente Emp_ID è una FK che punta
alla tabella Employess e Project_ID è una FK
che punta alla tabella Projects
Emp_Projects
Project_ID Emp_ID
101 00001
102 00001
101 00002

Termini legati ai dati
Dati: sono valori statici memorizzati nel database.
Informazione: Sono le informazione che gli utenti recuperano dal database, sono
certamente legate ai dati, ma non sono solo dati, possono anche subire
elaborazioni.
Null: rappresenta una campo vuoto, senza valore, non è ne zero ne una stringa
vuota. Si deve porre attenzione al fatto che un valore nullo non può essere
calcolato quindi qualsiasi formula contenente null dà come risultato null.

Termini legati alla struttura
 Tables
E’ la struttura base di un database. E’ formata da un insieme di record (righe)
ognuno caratterizzato da attributi (Colonne). Una tabella può rappresentare un
oggetto concreto o concettuale, ma può anche rappresentare un evento ad
esempio gli esami sostenuti da uno studente. Vengono dette data-table quelle
contenenti i dati che possono essere manipolate molto di frequente dall’utente.
Sono invece validation-table quelle che contengono dati variati di rado e
vengono usate per garantire l’integrità dei dati nell’inserimento o modifica delle
data-table (province, regioni, modalità pagamento)
 Field (attribute)
E’ la struttura atomica di un DB e contiene un dato. I dati nei database sono
tipizzati (numeri, stringhe, date,…).
 Record (tuple)
E’ un’istanza univoca di un oggetto di una tabella. Tale oggetto comprende tutta
la collezione di campi sia valorizzati sia nulli. Il record è identificato da uno o più
campi univoci per la tabella.

Termini legati alla struttura View
E’ una tabella virtuale ottenuta generalmente tramite una query dai campi di
una o più tabelle. In questo caso i dati sono quelli delle tabelle reali, mentre
della vista viene memorizzata solo la struttura. Gli utenti vedono i dati come
strutturati nella vista, senza avere accesso diretto alle tabelle reali.
 Keys
Sono campi di una tabella che giocano un ruolo speciale. In particolare:
 Primary key: è un valore che identifica un record (può essere composto da più
campi), inoltre garantisce l’integrità dei dati e permette di creare relazioni con le altre
tabelle.
 Foreign key:
entra in gioco nelle relazioni
 Indexes
Sono strutture fisiche atte a
migliorare le prestazioni del RDBMS
nella ricerca dei dati

Termini legati alle relazioni
 Relationship
Si ha una relazione quando due tabelle sono in qualche modo collegate. Il collegamento
avviene attraverso PK e FK oppure attraverso una terza tabella detta linking table.
 One – to – one
Un record della prima tabella è legato a un record nella seconda e viceversa.
Si tratta di un caso particolare in cui PK e FK coincidono. Questo tipo di relazione non ha
una grandissima utilità, viene usata per semplificare la struttura delle tabelle

 One – to - many
Un singolo record della prima tabella è legato a molti record nella seconda
tabella, ma un record della seconda tabella è legato a un solo record nella
prima. Questo tipo di relazione è molto comune e permette di risolvere quasi
tutti i problemi di normalizzazione.

 many – to - many
Un singolo record della prima tabella è legato a molti record nella seconda
tabella, e un record della seconda tabella è legato a molti record nella prima.
Per realizzare questo tipo di relazione è necessaria una terza tabella, che
all’occorrenza può avere attributi, ma che è caratterizzata dall’avere come
chiave primaria la composizione di du FK che solo la copia delle PK delle due
tabelle coinvolte nella relazione.

Partecipazione alle relazioni
La partecipazione a una relazione può essere obbligatoria o opzionale.
In questo caso fosse obbligatoria per
inserire un Entertainers dovrei avere
per forza definito prima l’Agent.
Nel caso fosse opzionale potrei
anche evitare di avere inserito prima
l’Agent
Si dice altresì grado di partecipazione il numero minimo e massimo di occorrenze
che la relazione dovrà avere.

Termini legati all’Integrità
L’integrità è tutto ciò che concerne la validità, la consistenza e l’accuratezza dei
dati. Ne segue che in fase di disegno si deve porre molta attenzione all’integrità
dei dati.
 Table level integrity (entity integrity)
Assicura l’assenza di duplicati grazie all’univocità della PK, inoltre tutti i
componenti delle PK devono essere non nulli.
 Field level integrity (domain integrity)
Assicura che i dati nei campi abbiano un valore valido e accurato in base alla
tipologia di dati definito.
 Relationship level integrity (referential integrity)
Assicura la sincronizzazione tra le tabelle legate da relazioni, a seconda delle
scelte fatte in fase di disegno.
 Business Rule integrity: i dati, le relazioni devono rispettare di solito alcune regole
specifiche che dipendono dal contesto e che impongono vincoli aggiuntivi.

Analisi e Disegno di un Database
La fase di analisi è disegno di un database è un processo complesso che richiede
una certa esperienza e abilità. Si ricordi che un errore o una mancanza in fase di
analisi e disegno si ripercuote pesantemente sui tempi e sui costi successivi,
infatti la correzione successiva di questi errori comporta dover ripercorrere passi
già svolti e riscrivere o adattare porzioni di codice. In genere possiamo individuare
delle ben precise fasi che a grandi linee coincidono con le normali fasi di analisi e
sviluppo di qualsiasi prodotto.
 Analisi dei requisiti: Intervista con gli utenti
 Stesura delle specifiche tecniche (elenco dei campi, telle tabelle): questa fase è
spesso completata dopo un feedback con l’utente.
 Disegno del database, delle relazioni, dei vincoli, delle regole di business
 Implementazione fisica del database
 Installazione e test
 Manutenzione

Formalismi
Le varie fasi dello sviluppo permettono di
produrre dei semilavorati che possono essere
molto utili alle fasi successive. In particolare
per i tecnici che avranno il compito di scrivere
materialmente il codice. Ad esempio è
possibile avere delle schede, come quella
indicata a fianco, per descrivere i campi di
una tabella.
Inoltre esistono alcuni ‘linguaggi’ di tipo
prevalentemente grafico, e alcuni tool
software, che consentono di modellizzare in
modo adeguato i database.
Primo tra tutti sono i diagrammi entità-
relazione che vedremo in seguito.

ERD Entity Relation Diagram
E’ uno strumento grafico per facilitare da definizione del modello di un DB.
Entity: “Qualcosa” nel mondo reale che deve essere rappresentata in un database.
In realtà un entità può essere concreata (uno studente, un palazzo), ma anche
concettuale (un ruolo). Il nome di un entità deve rappresentare una classificazione,
non una particolare istanza (un record). Ogni entità possiede attributi.
Attributes: sono le caratteristiche di un entità. Ad esempio Automobile può avere
come attributi colore, targa, marca, modello, colindrata,…..
Esistono anche modi alternativi di
rappresentazione, ad esempio riportando
gli attributi all’interno del rettangolo
dell’entità.
La primary key viene normalmente
indicata tramite una sottolineatura.

Relazione 1:1
Nella relazione 1:1 la tabella legata può
essere spesso indicata come Subset
table contiene cioè dei dati che
appartengono solo ad alcuni Impiegati,
mentre altri tali dati non hanno neppure
senso.
EmpID
EmpFirstName
Home Phone
…..
Employees Compensation
EmpID
Hourly Rate

Relazione 1:N
…..
Customers
…..
Customers Rentals

Relazione N:N
…..
Students
…..
Classes

Relazione N:N
Nella relazione n:n come sappiamo esiste una linking-table che permette di realizzare la relazione
stessa. In alcuni casi tale tabella potrebbe anche avere campi aggiuntivi che caratterizzano la
relazione. In tal caso è indispensabile evidenziare la linking table nel diagramma.

Relazioni N-arie
In alcuni casi le linking table possono avere una chiave formata non da 2 ma da n
FK. Si pensi al seguente esempio disegnato con un diagramma ER di tipo
tradizionale:
Buy
CustID SupID StateID ProdID price
101 0001 A AXS001 102,34
102 0001 A AZ0001 234,01

Esempio
In questo esempio è evidenziata
un’autorelazione 1:N nella tabella
Employees e viene mostrata anche la
tabella di relazione tra Ordini e Prodotti
Analizziamo in questo esempio le partecipazioni alle relazione e i vincoli di integrità delle stesse.

Deletion Rule
La cancellazione dei record nelle tabelle relazionate è sempre critica. Ci sono le seguenti
modalità di cancellazione dei record relazionati:
 Deny (D): non permette la cancellazione di un record in una tabella ‘padre’: si dovrà
prevedere la possibilità di rendere il record non attivo.
 Restrict (R): la cancellazione è possibile solo se nella tabella figlia non ci sono record
legati.
 Cascade(C): elimina a cascata i record della tabella padre e della tabella figlia.
 Nullify (N): elimina il record padre e pone a ‘null’ tutte le FK che erano legate.
 Set Default(S): elimina il record padre e pone a un valore di default tutte le FK che erano
legate.
Per decidere cosa fare porsi la seguente domanda:
Quando un record nella tabella padre viene cancellato, cosa dovrebbe accadere ai record
correlati nella tabella figlia?
La risposta dipende sempre dal contesto è cioè una business rule. Porremo comunque la
lettera corrispondente vicino alla relazione.

Partecipazione alle relazioni
• Mandatory (obbligatoria). Deve esserci almeno un record nella tabella per poter inserire record
nella tabella relazionata.
•Optional (opzionale). Non è necessario avere record nella tabella per inserirne nella tabella
relazionata.
• La tabella Employees ha una partecipazione obbligatoria: ci deve essere almeno un impiegato per
assegnarlo a un dato cliente.
• La tabella Customers ha una partecipazione opzionale nel senso che è possibile inserire un
impiegato anche se non ci sono clienti.
In pratica questo si traduce dicendo che la relazione è di tipo:
0:N vista da Employees (la business rule impone 0:15)
1:1 vista da Customers

Business Rules
Le business rules sono un insieme di regole che dipendono dall’applicazione
specifica. Questo comporta la scrittura di vincoli (Constraint) sui campi: ad esempio
alcuni campi possono contenere solo una certa combinazione di caratteri, oppure il
loro valore deve essere contenuto in un intervallo o in un insieme.
In particolare quando si hanno campi che possono assumere solo valori ben
determinati si ricorre alle Validation Tables:

Relazioni
Le entità possono essere relazionate ad altre tramite alcuni attributi in comune.
Relation: E’ un associazione tra entità, possono essere espresse sintatticamente
con un verbo di una frase in cui soggetto e oggetto sono delle entità.

Cardinalità

Esempio N:N
Codice Titolo
00001 Programmare in java
00002 Linux Read Hat
00003 Basi di Dati
IDAutore Cognome e Nome
000AB Smith John
000CD Pinco Pallino
000SZ Rossi Paolo
Libro Autore Pagine
00001 000AB 100
00001 000CD 200
00002 000CD 140
Nella tabella di relazione la
chiave primaria è costituita
da entrambe le chiavi
esterne.

Esempio

Database

More Related Content

Similar to Database

More from Sergio Ronchi

Database