Programma 5° anno (appunti del professore)

prof. S. Masetta
P
Prrooggrraam
mm
maa S
Sccooaallaassttiiccoo
55°° aannnnoo IInnffoom
maattiiccaa
Agg. 14/11/2009
www.sezioneb.com
SOMMARIO
1
1.1
GESTIONE DELLE INFORMAZIONI ______________________________________ 2
Introduzione ____________________________________________________________________________ 2
1.2
Analisi e progetto dei sistemi informativi. Archivi. _____________________________________________ 2
1.2.1
Progettazione concettuale (con il modello ER) _______________________________________________ 2
1.2.2
Progettazione Logica (con il modello relazionale) ____________________________________________ 4
1.2.2.1 Dallo schema concettuale al logico ______________________________________________________ 5
1.2.2.2 Vincoli di integrità __________________________________________________________________ 5
1.2.2.3 Vantaggi del modello relazionale rispetto a quello a puntatori ________________________________ 6
1.2.2.4 Algebra Relazionale _________________________________________________________________ 6
1.2.2.5 Forme Normali _____________________________________________________________________ 7
1.2.2.5.1 Definizione delle dipendenze funzionali ______________________________________________ 8
1.2.2.5.2 Prima Forma Normale ____________________________________________________________ 9
1.2.2.5.3 Seconda Forma Normale __________________________________________________________ 9
1.2.2.5.4 Terza Forma Normale ___________________________________________________________ 10
1.2.2.5.5 linee guida sulla normalizzazione __________________________________________________ 12
1.2.2.5.6 Boyce Codd Normal Form ________________________________________________________ 12
1.2.2.5.7 Quarta Forma Normale __________________________________________________________ 13
1.2.3
Progettazione Fisica __________________________________________________________________ 13
1.2.3.1 Organizzazione ____________________________________________________________________ 13
1.3
Gestione degli archivi con linguaggi di programmazione. ______________________________________
1.3.1
Basi di dati: struttura, progetto, linguaggi per la realizzazione e per l'interrogazione. ________________
1.3.1.1 Tipi SQL ANSI ____________________________________________________________________
1.3.1.2 DML (Data Manipulation Language) __________________________________________________
1.3.1.2.1 Istruzione SELECT _____________________________________________________________
1.3.1.2.2 Istruzione INSERT _____________________________________________________________
1.3.1.2.3 Istruzione DELETE _____________________________________________________________
1.3.1.2.4 Istruzione UPDATE _____________________________________________________________
1.3.1.3 DDL (Data Definition Language) _____________________________________________________
1.3.1.3.1 Istruzione CREATE SCHEMA ____________________________________________________
1.3.1.3.2 Istruzione CREATE TABLE _____________________________________________________
1.3.1.3.3 Istruzione ALTER TABLE _______________________________________________________
1.3.1.3.4 Istruzione DROP TABLE ________________________________________________________
1.3.1.3.5 Istruzione CREATE VIEW _______________________________________________________
1.3.1.3.6 Istruzione DROP VIEW __________________________________________________________
1.3.1.4 DCL (Data Controll Language) _______________________________________________________
1.3.1.4.1 Istruzione GRANT ALL _________________________________________________________
1.3.1.4.2 Istruzione REVOKE_____________________________________________________________
1.3.1.4.3 Istruzione NOT EXIST __________________________________________________________
1.3.1.5 Operatori di aggregazione ____________________________________________________________
2
2.1
13
13
13
14
14
14
15
15
15
15
16
17
17
17
17
17
17
17
17
18
VARIE _____________________________________________________________ 18
Bibbliografia ___________________________________________________________________________ 18
pag 1
1
1.1
GESTIONE DELLE INFORMAZIONI
Introduzione
(a) Def: Database:
E’ un insieme di informazioni permanenti che sono organizzati secondo una struttura definita da un
modello che rappresenta la situazione reale che si vuole automatizzare (magazzino, fatturazione, ...)
(b) Indicare i requisiti che un database deve soddisfare
 ridondanza minima dei dati
 dati accessibili in maniera sicura
 concorrenza tra più utenti
 sicurezza a fronte di guasti
 eventualmente recupero di stati consistenti
 ottimizzazione delle prestazioni
 deve fare in modo che un utente si concentri sui dati e non sul modo in cui essi sono
rappresentati nel sistema (vedasi [russo 12-13])
 gestire le transazioni
 definizione di un DDL (linguaggio di definizione dati) , di un DML (linguaggio di
manipolazione dati), e di un DCL (linguaggio di controllo dati, per esempio per impostare
le autorizzazioni)
(c) differenza tra archivio fatto con i file e quello fatto invece con il db (uno contiene solo dati mentre il
secondo associa della semantica)
NOTA: Gli appunti per le basi di dati si dividono tra quelli [db1] e quelli di [russo].
1.2
Analisi e progetto dei sistemi informativi. Archivi.
Fare capire come lo scopo della progettazione dei database sia quello di schematizzare in un modello
concettuale , poi in uno logico e infine in uno fisico, una realtà (es: un magazzino)
NOTA: Lo schema logico dei dati dipende strettamente dal tipo di DBMS utilizzato, ed è quindi in base al tipo
di modello logico che facciamo la distinzione tra DBMS gerarchici, ad oggetti, relazionali, ...
NOTA: Su [russo 6-9] ci sono delle riflessioni di introduzione sui database.
1.2.1 Progettazione concettuale (con il modello ER)
La progettazione di una base di dati è solo un passo nel ciclo di vita di un sistema informativo:
Studio di
fattibilità
Raccolta
requisiti
Progettazione
Implementazione
Test
Funzionamento
pag 2
NOTA: Il livello concettuale esiste perché si separa nettamente cosa si vuole rappresentare dal come fare
per farlo ([russo11]).
L'obiettivo della progettazione concettuale e quella di dare una rappresentazione formale (schema
concettuale) di una realtà di interesse (informale) in maniera indipendente dal DBMS.
I modelli usati per la rappresentazione concettuale sono detti modelli semantici (alcuni di questi sono
reticolari, gerarchici, entità-relazione oppure ad oggetti). Noi tratteremo quello ER (si veda [russo 14 --- 20].
Quello che si definisce nel modello ER sono:

Concetto di Entità
E’ qualcosa che esiste ed è distinguibile (ES: una persona, un ufficio, ...)

Concetto di Set di Entità
Un gruppo di entità simili (ES: tutte le persone che abbiano o meno i capelli neri, ...)
Tenere presente che nel modello ER l’entità coinciderà con il record mentre il set di entità con la
tabella.

Concetto di Attributi
Definiscono le proprietà che sono caratteristiche delle entità (ES: tutte le persone con i capelli
neri, rossi, ...). Permettono di definire meglio la realtà

Concetto di Chiave
E’ un attributo particolare sul quale sono definiti dei vincoli che ne determinano le caratteristiche
(non nulla, una per entità, no duplicati, ...)

Concetto di ERD
Lo schema ER ha anche un rappresentazione grafica la quale permette di avere una visione
globale e immediata dello schema concettuale, Questa spesso viene detta ER Diagramm (ERD)
e per convenzione si usano:
-
dei rettangoli per il set di entità.
delle ellissi per gli attributi
una linea senza frecce tra set di entità per indicare una relazione N:M
una linea con la freccia pe rindicare una relazione 1:N (con la freccia che punta al set in
cui corrisponde 1 entità)

Concetto di Relazione
Sono dipendenze o associazioni di interesse informativo tra dati. Si classificano in base al
numero di entità che si associano (relazione 1:1, 1:n, n:n)

Concetto di Attributi di una Relazione ([russo 17])
Il modello ER prevede che anche le relazioni abbiano degli attributi che ne specificano le
caratteristiche. Graficamente vengono rappresentati tramite una ellisse.
Nome
attrib.
E1
R1
E2
Tenere presente le seguenti definizioni:
pag 3





SCHEMA di Tabella
dichiarazioni
vincoli
SCHEMA database
una superchiave
= <dichiarazioni><vincoli>
= {campo1,tipo1} .... {campo n,tipo n}
= o globali o locali
= <schema tabella 1> ...... <schema tabella n>
= un insieme di attributi che contiene la chiave
NOTA: Un esempio di schema concettuale si trova in [russo 18] dove sono descritti i vari set di entità, e in
[russo 20] dove con l’ERD si da una descrizione grafica delle relazioni e dello schema nella sua
completezza.
Il vantaggio di avere uno schema di questo tipo serve per:




avere una idea immediata di quello che costruiamo in maniera indipendente da come lo faremo
posso facilmente individuare le aree che conterranno informazioni sensibili. eventualmente visto
che poi gli accessi vengono definiti al livello di tabella , predispongo affichè i dati riservati si
trovino su set di ientità a parte collegati tramite relazioni
definire al meglio come i dati devono essere strutturati e come devono essere presentati. Infatti
se ho la necessità di utilizzare spesso dei dati che si trovano in set di entità differenti allora si
crea una relazione.
sarebbe difficile fare dei miglioramenti o analisi senza una schema ERD. Per esempio vedi lo
schema dell’OASI.
1.2.2 Progettazione Logica (con il modello relazionale)
Il principale scopo della progettazione logica è quello di tradurre lo schema concettuale in un modello logico
dei dati ottenendo lo schema logico del database [russo 23].
A differenza dello schema concettuale questo dipende dal DBMS [russo 13]. Inoltre è compito della
progettazione logica quello di definire le viste tramite DDL. Infine deve essere anche previsto un DML per
manipolare i dati.
E’ importante quindi definire:




modalità di accesso ai dati
DDL
DML
Viste
NOTA: Al livello logico tabella e relazione sono la stessa cosa.
NOTA: Al livello logico si defiiscono due metodologie per l’accesso ai dati :


l’Algebra Relazionale
Calcolo Relazionale
Sono entrambe equivalenti, ma noi tratteremo l’algebra in quanto da questa deriva la definizione del
linguaggio SQL ormai diventato standard di definizione e manipolazione di Database.
L'unico concetto fondamentale è la RELAZIONE (da non confonderla nel senso dell’ ER. Infatti qui la
relazione si intende nel senso insiemistico, cioè come un sottoinsieme di tuple del prodotto cartesiano di
tabelle).
In particolare vedremo:
pag 4


definizione di algebra (definita più avanti)
concetto di relazione al livello logico
una relazione algebrica lega degli elementi. Possiamo per semplicita raggrupparli in record (o tuple)
e avere così le tabelle

definizione di prodotto cartesiano [russo 29]
L'insieme degli attributi costituisce lo schema della relazione [russo 30]
NOTA: le entità del modello ER diventano tabelle nello schema logico. In [russo 31] ci sono le definizioni di
relazione 1:1, 1:N, N:M.
Inoltre si può utilizzare un esempio che si trova in [russo 34] molto pratico per fare capire. E' fondamentale
vedere [russo 35] dove si vede come tradurre una relazione del tipo N:N in uno schema Logico (mediante al
creazione di una tabella intermedia)
1.2.2.1
Dallo schema concettuale al logico
I passi per passare da uno schema concettuale a uno logico sono:
1) per ciascun set di entità creare una tabella nello schema logico
2) per ciascuna tabella si definisce la chiave primaria
3) per le relazioni 1:N vengono definite le chiavi esterne (nella tabella che vale per “N” mettiamo il
campo chiave primaria della tabella che vale per “1”). In questo modo siamo in grado di
collegare gli elementi della prima con i tanti della seconda
4) vengono definite le tabelle di supporto per le relazioni N:M. Nelle tabelle di supporto mettiamo le
chiavi primarie delle tabelle coinvolte. Possiamo aggiungere a queste tabelle anche campi di
supporto (vedi esempio [russo 35] parte in fondo)
1.2.2.2
Vincoli di integrità
Non sempre si verifica che le tuple di un sistema creato corrispondano perfettamente alla realtà. Per fare in
modo che questa simiglianza aumenti si inseriscono dei vincoli di integrità, che non sono altro che delle
regole che le tuple devono rispettare al fine di essere ritenute valide.
Si dividono in


intrarelazionali
Sono quelli di chiave. Ogni tabella (detta anche relazione) deve avere una chiave che non abbia
valore NULL.
interrelazionali.
Sono quelli di integrità referenziale. Se c'è una ralazione tra tabelle allora bisogna che i campi
chiave siano ripetuti nei valori dell'altra tabella altrimenti è impossibile mantenere la
relazione.(Chiave esterna). ES: [russo 39]
NOTA: I vincoli di integrità si riferiscono alla correttezza dei valori che si trovano nelle tuple [russo 51].
pag 5
1.2.2.3
Vantaggi del modello relazionale rispetto a quello a puntatori
Vedi eventualmente[russo 40-41].



non abbiamo l’onere di gestire dati che non fanno parte del database come ad esempio i
puntatori.
se vogliamo fare migrare un DB essendo il sistema basato sui valori e non sui puntatori non c’è
da fare nessun lavoro aggiuntivo.
si rappresenta solo quello che è rilevante per rappresentare la realtà e non dati aggiuntivi di
supporto (appunto i puntatori)
NOTA: E' importante rilevare che per sviluppare degli schemi logici si usano spesso degli strumenti CASE
[russo 61] che permettono di generare tabelle, chiavi, indici, viste , ecc.
Però per avere dei sistemi più efficienti è necessario poter fare anche un processo finale di
denormalizzazione, cioè di ammettere della ridondanza in cambio di maggior performance.
1.2.2.4 Algebra Relazionale
E' un formalismo per accedere ai dati. Si applica al livello di Schema logico in quanto qui abbiamo a che fare
con sottoinsiemi dei prodotti cartesiani delle relazioni. Questa costituisce la base dell'SQL .
Si basa tutta su degli operatori di base sui quali è possibile costruirne altri. Questi sono [russo 42]:

proiezione
X Y

Z
X Y
selezione (determina la SELECT)
X Y
Z
X
Y
Z

prodotto
Date due tabelle il prodotti si ottiene concatenando le righe della prima con tutte le righe
della seconda (prodotto cartesiano)

ridenominazione
Consente la ridenominazine dei nome dei campi di una tabella

unione
Date due tabelle con gli stessi attributi restituisce una tabella che contiene tutte le riche
delle due tabelle
A
B
C
a
d
b
a
c
f
c
b
d
D E
b g
d a
F
a
f
a
d
b
a
c
f
c
b
d
b
d
g
a
a
f
pag 6

differenza
Anche qui le tabelle devono avere la stessa struttura. Il risultato è che si hanno tutte le
righe della prima tabella escluse quelle della seconda.
A
B
C
a
d
b
a
c
f
c
b
d
D E
b g
d
a
F
a
a
c
b
b
c
d
f
NOTA: vedi esempi [russo 43]
Tra quelli derivati da questi invece vediamo:

Intersezione
R  S = R – (R –S)

Natural Join
Viene costruito facendo:
1) il prodotto cartesiano delle due tabelle R e S
2) sul risultato viene applicata la selezione delle righe in cui gli attributi
sono uguali
3) vengono ridenominati gli attributi che hanno lo stesso nome in modo
che compaiono una sola volta

Join (nel caso di operatore = diventa Equijoin)
date due tabelle R e S che hanno un dominio in comune e una condizione nella forma
ATT1 op ATT2
... dove ATT1 e ATT2 sono degli attributi delle tabelle e op un operatore di confronto.
Allora la join restituisce una tabella ottenuta come:
1) prodotto cartesiano delle due tabelle
2) sulla risultante si effettua la selezione delle righe in cui gli attributi
soddisfano la condizione di cui sopra
3) vengono ridenominati gli attributi che hanno lo stesso nome in modo
che compaiono una sola volta

1.2.2.5
SemiJoin
Non è altro che il Join ma proiettando solo gli attributi di una tabella
Forme Normali
Una volta impostato uno schema logico può succedere che lo schema presenti delle anomalie [da1 pg 59].
Esempio:
pag 7




Ridondanza:
In una tabella in cui vendiamo dei prodotti  il nome del produttore viene
ripetuto per ogni prodotto insieme a tutte le informazioni che lo riguardano
Inserimento:
Non possiamo inserire dati di un fornitore se questo non vende almeno un
prodotto. oppure avremmo dei campi NULL.
Aggiornamento: Se abbiamo valori ripetuti a fronte di aggiornamenti dobbiamo sostenere un
carico computazionale per aggiornare il tutto (più il pericolo di perdere qualche aggiornamento)
Cancellazione:
Se cancelliamo i prodotti di un fornitore perdiamo tutti i dati sullo stesso
Per evitarle bisogna applicare delle fasi di normalizzazione effettuabile tramite dei procedimenti di tipo
algebrico [russo 46] basati sulla scomposizione e sui concetti di dipendenza.
La prima cosa da fare è introdurre delle dipendenze funzionali che descrivono i legami tra gli attributi di una
relazione (vi è per esempio una dipendenza funzionale quando riesco a ricavare tutti i campi di una tupla
partendo dalla chiave !!! Quindi la chiave determina funzionalmente una relazione). Quidi le ddipendenze
funzioneli sono dei legami basati sui valori che si trovano nelle tabelle. E’ però impensabile che si
determinino tali legami dalla analisi di tutti i valori che si trovano nelle tabelle stesse, per cui alla fine dei
conti le dipendenze si ricavano da analisi logiche fatte sul significato dei campi stessi.
NOTA: Le dipendenze funzionali sono di per se ridondanti (ovvio !) ma sono allo stesso tempo la causa della
ridondanza e la soluzione perchè è sempre tramite esse che troviamo delle soluzioni.
E’ importante sapere il significato dei seguenti termini:

definizione di scomposizione [russo 49].
NOTA: La scomposizione è importante in quanto scomponendo riesco a risolvere dei problemi.
Se ho uno schema R allora parlo di scomposizione in tanti sottoschemi R1, ... ,Rn per cui il
prodotto cartesiano di questi mi da di nuovo R (non importa che siano disgiunti)

scomposizione senza perdita.
Non possiamo perdere informazione per cui deve essere possibile facendo il natural join delle
relazioni ottenute, ricostruire la tabella di partenza.

def. Di scomposizione che conserva le dipendenze [russo 51].
E' tale se l'unione di tutte le dipendenze nello schema scomposto implica logicamente tutte
quelle iniziali.
Un esempio di scomposizione fatta male è quella di [russo 50] in cui facendo una scopmosizione basandosi
su attributi che non sono chiave alla fine facendo l’equi-join si creano delle tuple spurie (cioè che in realtà
non esistono).
NOTA: In maniera sbrigativa si potrebbe dire che una relazione si scompone senza perdita se gli attributi
comuni alle due tabelle risultanti sono chiave almeno per una delle due tabelle.
1.2.2.5.1
Definizione delle dipendenze funzionali
NOTA: Con un esempio si trovano [da1 pg 59].
Praticamente basta tener presente che per evitare i problemi delle anomalie è necessario definire dei vincoli
particolari detti dipendenze funzionali.
DEF: Le dipendenze funzionali sono una classe di vincoli particolari tra i valori assunti dagli attributi.
pag 8
Adottando la BCNF si evita di avere una tabella in cui si trovano assieme delle informazioni su corsi, docenti
e recapiti dei docenti (come c’è nell’esempio di [da1 pg 58])
Vedere gli assiomi di Armstrong [da1 pg 60] sulle dipendenze funzionali e tenere presente che questi vincoli
non sono descrittivi, ma sono soggetti ad algebra e hanno delle proprietà che consentono di dedurre altre
dipendenze funzionali.
Le dipendenze funzionali possono esprimere semantica così come l’ER.
Quelle di Armstrong sono:
-
Riflessività
se Y X (Y insieme di attributi contenuto in X) allora X-> Y cioè da Y X si deduce che X-> Y
[db1 60]
-
Espansione
-
Transitività vedi [db1 60]
ES: se CORSO -> DOCENTE e da DOCENTE -> UFFICIO allora CORSO -> UFFICIO
vedi [db1 60]
Da queste si possono ricavare altre dipendenze funzionali in base a delle deduzioni basate sulle proprietà
delle stesse dipendenze funzionali. Queste sono (vedi [db1 60]) UNIONE, DECOMPOSIZIONE,
PSEUDOTRANSITIVITA’, PRODOTTO (se non tornano utili sono da saltare)
-
Concetto di deduzione [da1 pg 61)
concetto di chiusura di F (praticamente è l’insieme delle dipendenze funzionali che si possono
dedurre a partire da un insieme F di dipendenze) [da1 pg 62]
1.2.2.5.2 Prima Forma Normale
Semplice: in una relazione non ci possono essere dei campi che sono dei vettori (vedi es [russo 53] ). Se
infatti prendiamo l’esempio della tabella :
Padre
nome_padre
a
b
Figli
c d
e
non è in I NF essendoci una struttura vettoriale al campo figli. Questa deve essere scomposta nella maniera
di cui in seguito.
Padre
nome_padre
nome_padre
nome_padre
nome_padre
nome_padre
1.2.2.5.3
Figli
a
b
c
d
e
Seconda Forma Normale
pag 9
In termini sbrigativi la II NF riferisce che nel caso in cui la chiave sia formata da più campi allora deve essere
possibile determinare tutti i campi della tabella dall’intera chiave e non da una parte di essa.
Detto in termini più precisi uno schema è in 2° Forma Normale se :


è in 1° NF
tutti i campi dipendono da una chiave e non da una parte di essa. (praticamente la chiave è
formata da un numero di campi minimo)
Se la tabella ha già una chiave su un solo attributo allora è già in 2° NF.
Vedi es [russo ]
NOTA: Praticamente dice che (se la chiave primaria è fatta da più attributi) tutti gli altri attributi dipendono
solo dalla chiave completa e non da una parte di essa (poi possono esserci altre dipendenze tra gli atri
attributi), da non confondere con la BCNF che invece dice che possono esistere solo le dipendenze
funzionali X A in cui X è chiave !!!!
ESEMPIO:
cod_città
1
1
2
3
cod_via
a
b
c
d
città
roma
roma
venezia
parma
via
centrale
del corso
platani
garibaldi
allora si vede che la chiave è {cod_città , cod_via} ma è anche cod_città  città e cod_via  via.
Quindi ci sono degli attributi facente parte della chiave che determinano altri campi.
In questo caso si risolve facendo un ascomposizione del tipo:
cod_città
1
2
3
città
roma
venezia
parma
cod_città
1
1
2
3
cod_via
a
b
c
d
via
centrale
del corso
platani
garibaldi
1.2.2.5.4 Terza Forma Normale
NOTA: se si vede l’esempio di [russo 56] si capirà tutto.
Bisogna conoscere i concetti di :

Chiave canditata
Un insieme di attriibuti possono formare una chiave. La chiave canditata è un insieme
che li determina tutti

Chiave primaria
E’ la chiave principale della relazione

Superchiave
E’ un superinsieme della chiave, cioè un insieme di attributi che contiene la chiave
pag 10

Attributo Primario
Un attributo è primario se fa parte di qualunque chiave. Cioè se è indispensabile a
formare qualsiasi chiave.
Un esempio che aiuta a capire questi concetti è quello di una relazione in cui abbiamo #patente,
#passaporto , nome, cognome, ecc. Allora possiamo dire che #patente è chiave primaria, mentre
#passaporto è chiave canditata, #patente e cognome è una superchiave.
DEF: Uno schema (già in 2° NF) è in 3° NF se non esistono dipendenze tra le colonne di una tabella se non
quelle basate su chiave primaria o se esistono vuol dire che l'attributo determinato è primario [russo 55]
Detto in termini più tecnici si potrebbe dire che data una relazione R questa è in III NF se ogni volta che
vale X  A allora o X è superchiave oppure A è attributo primario.
ESEMPIO: in una tabella “Comunicazioni in entrata”
Protocollo
1
mittente
tizio
tipo
1
urgenza
s
tipo
1
descrizione
Raccomandata
2
caio
2
n
2
lettera
3
sempronio
1
s
3
fax
Allora si verifica che nella prima tabella la chiave primaria è protocollo, che quindi (essendo chiave)
determina mittente e tipo, mentre urgenza è determinata da tipo.
Nella seconda tabella invece la chiave è tipo che determina la descrizione.
Lo schema della prima tabella non è in III NF in quanto tipo  urgenza
della prima tabella e urgenza non è primario.
La soluzione è di riorganizzare:
e quindi tipo non è superchiave
Protocollo
1
mittente
tizio
tipo
1
tipo
1
descrizione
Raccomandata
urgenza
s
2
caio
2
2
lettera
n
3
sempronio
1
3
fax
n
NOTA: Convertendo una schema di una relazione in II NF si eliminano già tanti di quei problemi dovuti alle
ridondanze in quanto si tende a isolare in ogni tabella tutta la semantica della realtà che rappresentano
(qesto appunto perchè si eliminano tutte le dipendenze tra campi che non sono chiave).
In origine invece troppe realtà erano mischiate insieme e generavano dei problemi di manipolazione dei dati
stessi.
NOTA: In [russo 57] c'è un algoritmo per la normalizzazione in 3° NF che costituisce un utile strumento di
analisi della qualità di un progetto. Questo in quanto se facciamo una buona rappresentazione del modello
semantico allora sarà molto facile produrre naturalmente in III NF. Quindi controllare che sia già in III NF è
uno strumento di bontà della progettazione.
Tenere presente che in generale le tabelle possono avere delle strutture complesse per cui non è facile che
si possano individuare le dipendenze e costruire quindi lo schema del database nella maniera dovuta.
pag 11
1.2.2.5.5 linee guida sulla normalizzazione
Essendo la III NF già una ottima soluzione per evitare la stragrande maggiornaza di anomalie si possono
allora eseguire i seguenti passi al fine di normalizzare uno schema di database.
1) partire dallo schema concettuale e creare le tabelle (non normalizzate) nel modo visto
precedentemente
2) individuare le chiavi primarie
3) individuare le eventuali altre dipendenze funzionali
4) portare lo schema in 1° NF rimuovendo gli attributi ripetuti e inserendo tali valori come tuple.
Eventualmente i valori ripetuti si possono mettere in una nuova tabella e la chiave primaria di
questa chiave esterna nella tabella originaria.
5) portare lo schema in 2° NF assicurando che ciascun attributo dipenda dall’intera chiave.
- se alcuni attributi non dipendono dall’intera chiave creare una nuova tabella
- eliminare dalla tabella princiaple gli attributi spostati
6) portare lo schema in 3° NF assicurando che non esistno attributi non primari che dipendono da
altri campi che non sono chiave
1.2.2.5.6
Boyce Codd Normal Form
NOTA: Elimina drasticamente le ridondanze (è infatti una condizione molto forte). Mentre nella 3° gli attributi
che originano le dipendenze devono essere primari qui devono essere chiave (e non parte di essa!).
E' una condizione molto forte e non sempre è possibile implementarla tramite scomposizione senza perdere
delle dipendenze.
DEF: Uno schema R con dipendenze funzionali F è tale se ogni volta che X  A (X determina A) e A non
appartiene a X, allora si deduce che X è una superchiave di R, cioè X è una chiave o contiene una chiave.
In pratica la BCNF dice che non esistono dipendenze tra gli attributi di una relazione se non basate
sulla chiave [russo 58].
Lo scopo di questa NF è quella di eliminare appunto le ridondanze che possono essere introdotte dalle
forme normali (in questo caso non è possibile infatti prevedere nessun dato se non dalla chiave quindi non ci
sono ridondanze di informazione).
Talvolta la scomposizione di uno schema concettuale in BCNF non è possibile [russo 59].
ESEMPIO:
città
torino
torino
milano
via
belfiore
roma
platani
CAP
10124
10125
12345
Le dipendenze sono:
-
{città,via}  CAP
CAP  città
Mentre le chiavi sono {città,via}. Questo schema non è in BCNF in quanto CAP  città e CAP non è
chiave.
Invece è in III NF in quanto città è primario
pag 12
1.2.2.5.7 Quarta Forma Normale
NOTA: Mai usata !!! E’ già OK la 3° NF.
Si trova in [russo 61].
Definiamo:
Chiusura di un insieme di dipendenze F l'insieme delle dipendenze funzionali che si possono dedurre a
partire da F.
Uno schema è in 4 NF se dato uno schema R e delle dipendenze D allora per ogni dipendenza nella
chiusura di D di tipo a multi valori (???) del tipo XY (con Y non è sottoinsieme di X) e XxY non contiene
tutti gli attributi di R, si verifica che X sia superchiave
1.2.3
Progettazione Fisica
Si traduce lo schema logico in fisico stabilendo come organizzare le strutture del livello logico. Dipende non
solo dal DBMS ma anche dal SO
1.2.3.1 Organizzazione
 Sequenziale
 Tabellare
 B-TREE
 Procedurale: Hashing
1.3
vedi [db2 105]
vedi [db2 112]
(vedi sezione B-Tree)
(vedi sezione HASH)
Gestione degli archivi con linguaggi di programmazione.
1.3.1
Basi di dati: struttura, progetto, linguaggi per la realizzazione e per l'interrogazione.
L’SQL è un linguaggio sia di manipolazione dei dati (DML) sia di definizione dei RDBMS .
NOTA: Ci sono degli appunti di SQL su [Linux01]
1.3.1.1
Tipi SQL ANSI
pag 13
Tipo SQL ANSI
CHAR(n)
Equivalente MS ACCESS
TEXT
Descrizione
In molti database il massimo è di 255
CHAR VARYNG
MEMO
come CHAR ma in questo caso il
numero di caratteri può essere di
molto superiore, dipende dal DBMS
INTEGER
INTEGER
numeri interi con segno. Occupa 4
bytes
SMALLINT
SMALLINT
integer a 2 bytes
FLOAT(n)
per n da 1 a 21 REAL
per n da 22 a 53 DOUBLE
REAL
DOUBLE
PRECISION
DATA
REAL
DOUBLE
DATA
numero in virgola mobile. Tra 1 e 21 n
cifre necessita di 8 bytes mentre da
22 a 53 necessita di 16 bytes.
NOTA: Alternativamente si può usare
double precision ne secondo caso
data nel formato aaaa-mm-gg
1.3.1.2 DML (Data Manipulation Language)
La parte di DML comprende 4 comandi principali:
1.3.1.2.1
Istruzione SELECT
SELECT [DISTINCT] * FROM tabelle WHERE cond
[ORDER BY lista_ord]
[GROUP BY lista_raggr]
[HAVING espressione]
1.3.1.2.2
Istruzione INSERT
Serve per fare degli inserimenti in una tabella già creata.
INSERT INTO [user.]tabella
(colonna_1, colonna_2, ..., colonna_n)
VALUES
(valore_1,valore_2, ..., valore_n)
ESEMPIO:
inseriamo in una tabella che ha 3 campi i seguenti valori. Notare che in questo caso manca
la definizione dei campi in quanto ci sono tutti.
INSERT INTO tabella_1 VALUES (50,’produzione’,’Roma’)
pag 14
ESEMPIO:
inseriamo in una tabella i campi con i seguenti valori.
INSERT INTO tabella_2
(campo_1, campo_3, campo_9)
VALUES
(NULL,’produzione’,1.3E4)
ESEMPIO:
Insert più elaborata:
INSERT INTO tabella_3
(campo_1, campo_3, campo_9)
SELECT nome, cognome, indirizzo FROM tabella_4
WHERE cognome=’Rossi’
1.3.1.2.3
Istruzione DELETE
La delete è molto semplice come sintassi:
DELETE FROM tabella WHERE condizione
1.3.1.2.4
Istruzione UPDATE
Serve per aggiornare dei record all’interno di una tabella.
UPDATE nome_tabella SET campo_1=valore_1 , ... colonna_2=campo_2
WHERE condizione
ESEMPIO:
Il seguente esempio serve per far capire come aumentare il prezzo dei prodotti casalinghi del
2%.
UPDATE articolo SET prezzo = prezzo + prezzo * 0.02
WHERE categoria = ‘casalinghi’
ESEMPIO:
UPDATE articolo SET prezzo = (SELECT max(prezzo) FROM articolo)
WHERE categoria = ‘casalinghi’
1.3.1.3
DDL (Data Definition Language)
1.3.1.3.1 Istruzione CREATE SCHEMA
Come DDL abbiamo anche delle istruzioni che permettono di definire degli schemi. Ogni RDBMS ha i propri
comandi per farlo ma inogni caso esistono quelli SQL che implementano le stesse cose.
Uno schema coincide con quello che noi chiamiamo ‘database’ cioè una collezione di tabelle di viste, di
indici e altro ancora.
La sintassi è:
pag 15
CREATE SCHEMA nome_schema
NOTA: tenere presente che questa istruzione non esiste in Access in quanto questi viene aperto sempre con
il database già esistente. Anche in altri database come PostgreSQL il database si crea con dei comandi
appositi.
1.3.1.3.2 Istruzione CREATE TABLE
Nella istruzione di creazione delle tabelle si possono specificare delle restrizioni campo per campo oppure
alla fine della tabella stessa.
CREATE TABLE [user.] table
(
{colonna
tipo restrizioni}
{,colonna
tipo restrizioni}
...
)
[Direttive]
dove:



user
è l’owner della tabella
colonna
è il nome della colonna, ce ne deve essere almeno una
Direttive
indicano delle caratteristiche come:
- il numero massimo delle transazioni che sono ammesse
- il TABLESPACE in cui si trova la tabella
- quale è la chiave primaria, tramite PRIMARY KEY

<tipo> può essere:
- UNIQUE
- NOT NULL
- CHECK(<valori di controllo>)
- REFERENCES tabella.campo (per creare un vincolo di chiave esterna)
ESEMPIO:
CREATE TABLE prova
(campo1
NUMBER NOT NULL PRIMARY KEY,
campo2
CHAR(10) NOT NULL CHECK (campo2= UPPER(campo2)),
data1
DATE CHECK (data1 >= SYSDATE),
float1
UMBER(10,2) DEFAUT 0
foreign_k
NUMBER(2) REFERENCES prova2.foreign_k
NOTA: E’ importante notare che si possono definire delle direttive che indicano come è
definito ogni campo e in particolare anche il vincolo di chiave esterna implementato dalla
direttiva REFERENCES. Inserire tale direttiva evita che:

si inserisca una tupla con il campo foreign_k nullo
pag 16


si inserisca una tupla con il campo foreign_k con un valore che non è
presente nella tabella esterna (qui è prova2)
si cancelli nella tabella corrente una tupla per la quale nella tabella
esterna esiste una tupla ad essa collegata (ES: dipartimento e
professori; non posso cancellare un dipartimento se ad esso sono
collegati dei professori!)
ESEMPIO:
CREATE TABLE prova
(campo1
NUMBER
campo2
CHAR(10)
data1
DATE CHECK (data1 >= SYSDATE),
float1
INTEGER)
NOT NULL( campo1, campo2)
1.3.1.3.3
Istruzione ALTER TABLE
1.3.1.3.4
Istruzione DROP TABLE
1.3.1.3.5 Istruzione CREATE VIEW
In [da1 pg 46] ci sono degli esempi
1.3.1.3.6 Istruzione DROP VIEW
Tabelle temporanee create con ASSIGN TO [da1 pg 35]
1.3.1.4
DCL (Data Controll Language)
1.3.1.4.1
Istruzione GRANT ALL
1.3.1.4.2
Istruzione REVOKE
[da1 pg 32], [da1 pg 33], clausola HAVING,
1.3.1.4.3
Istruzione NOT EXIST
Mentre come operatori abbiamo:





< , >, =,
betwen
like
any
all
<>,
per confrontare parti di campo (si usa % come carattere Jolly)
Se soddisfa almeno un elemento della lista
Se soddisfano tutti gli elementi della lista
pag 17
1.3.1.5 Operatori di aggregazione
Gli operatori di aggregazione sono:





sum
avg
count
min
max
somma
media
conteggio
NOTA: Un teorema [da1 pg 54] dice che ogni formula è traducibile in algebra
2
2.1
Varie
Bibbliografia
CODICE
TESTO
[ag]
Appunti universitari su automi e grammatiche
[ce]
Appunti di Comunicazioni elettriche dell’università
[corso]
Corso di Informatica 1
[da1]
appunti di documentazione automatica
[dev59]
rivista DEV n*59 di gennaio 99
[ei1]
fotocopie di Elettronica e Informatica Volume 1
[ei2]
fotocopie di Elettronica e Informatica Volume 2
[ei9]
fotocopie di Elettronica e Informatica Volume 9
[fon]
libro “Fondamenti di informatica” della bibblioteca comunale
[hal]
libro di TNA di Fred Halsal
[java1]
libro di java 1.1 della Hoepli
[linux01]
Mensile “Linux & Co” N° 1
[rose]
Libro di testo di Marshall Rose
[russo]
"Progettazione basi relazionali" di Nino Russo
[sis1]
appunti di Sistemi I
[sis2]
appunti di sistemi II
[tna]
appunti di TNA
pag 18