Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
SOMMARIO
Base di dati 3
Proprietà del DBMS: 3
ANSI/SPARC 3
Diagrammi E/R 3
Chiavi 4
EER 5
Valori Nulli / mancanti 6
Vincoli 6
Fasi di Progettazione DB 6
1. Analisi dei requisiti: 6
2. Progettazione concettuale: 6
3. Progettazione logica: 7
Traduzione EE/RModello relazionale 8
Chiave esterna 8
Molteplicità 8
Specializzazione/Generalizzazione 9
Algebra relazionale 9
Operatori Unari: 9
Operatori Binari: 10
Operatori Giunzione 10
Relazione universale 10
Operatori di Aggregazione – Raggruppamento 11
Riscrittura algebrica 11
SQL 12
DDL 12
DML 12
DCL 13
Politiche di reazione 13
Viste 13
Asserzioni 13
Triggers 14
Estensioni 14
Transazione 15
Proprietà ACID 15
Implementazione dei livelli di isolamento 16
Teoria relazionale 17
Dipendenza funzionale 17
Assiomi di Armstrong 17
Chiusura [Insieme di attributi] 18
Chiusura [insieme di dipendenze funzionali] 18
Definizione di chiave ed attributo primo 18
Copertura Canonica 18
Regole di decomposizione 19
Normalizzazione 19
1 forma normale: 19
2 forma normale: 19
3 forma normale: 20
Attenzione
I seguenti appunti sono stati redatti dopo aver:
Il fine è quello di voler preparare l’esame orale di Basi di Dati, ma quando si posseggono già le nozioni essenziali.
Pertanto, consiglio di usare questi appunti solo come ripasso, una settimana prima dell’esame.
Inoltre, visti i primi due punti, molti esempi e/o riferimenti saranno talvolta non comprensibili, se non si sono viste
prima le video-lezioni.
Infine, sono state saltate alcune cose, quali query innestate, query complesse, uml, use case, ed altri argomenti che,
si suppone, si padroneggino bene. Se così non fosse, siete invitati a far riferimento ad altro materiale per
approfondire meglio l’argomento.
Vanore Davide
Collezione di dati raccolti, ma in relazione tra loro. Tali dati devono essere strutturati, ovvero della forma
attributo=valore (e non semi-strutturati (es: file html) o non strutturati (es: file binari, multimedia, ecc.)).
Per evitare problemi come inconsistenza, copia dei dati, ecc., non si utilizza più il File System, bensì il DBMS.
Consistenza: si ha una sola copia dei dati. Si garantisce rispettando tutti i vincoli di integrità;
Affidabilità: Resistenza ai guasti grazie ad un algoritmo di ripristino che evita la corruzione dei dati;
Coerenza
Indipendenza: Lettura e scrittura degli stessi dati da più applicazioni.
Privatezza: ciascun utente è abilitato a svolgere solo determinate azioni sui dati, tramite autentificazione.
Efficienza: capacità di svolgere le operazioni in un tempo accettabile.
ANSI/SPARC
N.B: un buon DBMS garantisce le 2 dipendenze! Cioè, è possibile cambiare uno dei due livelli senza modificare anche
l’altro.
DIAGRAMMI E/R
[Entity Relationship / Entità – Associazione] Sono lo strumento più importante per la modellazione concettuale.
Si compone di tre elementi fondamentali: [esempio: studente]
Entità: una descrizione astratta dello studente, ovvero ciò che accomuna a tutti gli studenti. Può non essere
un oggetto fisico/concreto (es: dipartimento, azienda, ecc.)
o Aspetto intensionale: lo schema astratto che accomuna tutto ciò che fa parte di quell’entità, che è
sempre lo stesso ed è conservato nel catalogo.
o Aspetto estensionale: lo stato, collezione di unità che appartengono ad una determinata entità.
Variabile nel tempo e con infinite possibili estensioni.
N.B: Questo implica che studente NON ESISTE se non è iscritto ad un corso di laurea
Quindi le caratteristiche di un’entità debole sono: dipendenza di esistenza, mancanza di una chiave
primaria, presenza di una chiave parziale
Attributi: proprietà particolare che descrivono l’entità. Possono essere:
o Atomici / strutturati: unico valore non scomponibile (es: matricola) / più valori (es: indirizzo).
o Univoci / multivalore: valore singolo (es: matricola) / più valori (es: telefono).
o Totali / parziali: es: matricola (qualsiasi estensione di studente DEVE averla) / es: patente.
o Derivati: sono ricavati sulla base di attributi già presenti (es: data di nascita -> età).
o Complessi: strutturati e multivalore (es: indirizzo di contatto)
o Obbligatori: Deve essere inserito per forza. La differenza con la totalità è che, la totalità è una
proprietà dello schema, l’obbligatorietà la sceglie il progettista. Esempio: si può costruire una base
di dati in cui il codice fiscale non viene inserito.
Associazioni: associano due o più entità. Sono caratterizzate da:
o Molteplicità: univoche (1:N), biunivoche(1:1), multivalore(1:N), multivalore doppia(M:N).
o Totalità: può essere: totale (ad esempio, tutti gli studenti seguono almeno un corso), oppure
parziale (ad un corso può non partecipare alcuno studente).
o Cardinalità: numero minimo e massimo di istanze che sono in associazione.
o Grado di associazione: numero di entità coinvolte nell’associazione.
CHIAVI
Superchiave: insieme di attributi che identificano univocamente un’entità. Es: (matricola, nome) -> studente.
N.B: La proprietà vale sullo schema (si pensi ad una superchiave (nome, cognome) su una particolare estensione,
potrebbe sembrare univoco, ma non lo è!).
Chiave minimale: si ottiene rimuovendo gli attributi “superflui” da una superchiave. Es di prima: la superchiave
(matricola, nome), diventa (matricola). (una chiave è una superchiave minimale)
Tra un insieme di chiavi (candidate), una sola diventerà la chiave primaria. La chiave primaria deve rispettare 3
proprietà: univocità (deve identificare univocamente un’entità), totalità (ogni attributo DEVE averne un valore),
costanza (non deve variare nel tempo).
Chiave artificiale: contatore a cui viene assegnato un numero progressivo. Serve quando non si riesce a trovare una
chiave naturale. È quindi da evitare, e da usare come ultima spiaggia.
N.B: chiavi che contengono attributi opzionali non possono diventare chiavi primarie.
Può capitare che un’entità non abbia una chiave, ma è identificata componendo una propria chiave parziale con la
chiave di un’altra entità alla quale è associata mediante una relazione. L’entità priva di chiave viene chiamata entità
debole, l’entità associata a questa è detta entità proprietaria e la relazione che le lega è detta identificante.
Ereditarietà di attributi e relazioni (sottoclasse) da una entità madre (superclasse). Tra la classe e
superclasse si indica un “IS A” a indicare che un’istanza di una sottoclasse, è un’istanza di una superclasse.
Studente è una specializzazione di Persona. Top-Down (da entità madre a sottoclassi), processo di
definizione di un insieme di sottoclassi di un entità (superclasse)
Vincoli:
o di Specificazione: Ogni istanza della superclasse appartiene o meno ad una delle sottoclassi in base al
valore di un attributo.
o di Disgiunzione: se due o più sottoclassi hanno elementi in comune si dicono sovrapposte (overlap)
ad esempio Persona può essere sia Studente che Guidatore. [O]
Altrimenti sono disgiunte, ad esempio Persona può essere Lavoratore o Non Lavoratore (non
entrambi) [D].
o di Completezza: le sottoclassi “coprono” (includono) TUTTE le occorrenze della superclasse??
Il primo esempio fatto prima non era di copertura, mentre il secondo si.
Viceversa, Persona è una generalizzazione di Studente. Bottom-up (si parte dal riconoscimento di attributi o
relazioni comuni di entità, li definisce a un livello superiore attribuendoli ad una nuova entità superclasse e
le entità di partenza diventeranno sottoclassi).
Tipo unione: È possibile costruire
diagrammi EER aventi più superclassi. In
questo caso la sottoclasse rappresenta
una collezione di oggetti che è l’unione
di diversi tipi di entità.
C’è ereditarietà selettiva: cliente eredita
gli attributi di: o P o A o B (solo una di
queste entità diventeranno le “madri”).
N.B: anche se mettessimo “nome” a P, A e B, non sarebbe un attributo comune, in quanto hanno dominio
diverso (una banca non si può chiamare “Mario”).
Aggregazione vs Composizione: corso {è aggregato} lezione la lezione può esistere senza il corso;
persona {è composta} organi un organo non può esistere senza la persona (organi potrebbe diventare
entità debole).
N.B: Se l’associazione è M:N, non si può parlare né di aggregazione né di composizione.
SQL ha varie regole per gestire i valori NULL, che può essere interpretato nei seguinti modi:
Ma spesso è impossibile stabilire il giusto significato, e un valore NULL potrebbe addirittura averne ognuno.
Quando NULL è coinvolto in un’operazione di confronto, il risultato è
considerato UNKNOWN (sconosciuto, ovvero può essere true o false). Si
parla infatti di logica a tre valori, e non a due.
VINCOLI
Insieme di regole non esprimibili nel diagramma ER, ma presenti nella realtà.
Statici / Dinamici : che non variano nel tempo (es: età > 17) / dipendono dall’evoluzione della BD (es: per
iscriversi al 3° anno, uno studente dev’essere prima iscritto al 2°).
Intensionali / Estensionali: fanno riferimento allo schema / stato.
Sull’entità / associazione: lavoratore ha stipendio minimo 500€ / vincoli di molteplicità, cardinalità, di chiave.
FASI DI PROGETTAZIONE DB
La progettazione consiste in una fase preliminare nel quale vengono analizzati costo e impatto, e in 3 fasi principali:
analisi dei bisogni informativi (raccolti in linguaggio naturale) del cliente, fatte mediante interviste, analisi
documentazione, ecc. Si procede costruendo, per ogni settore, uno schema scheletro di settore (ad es uno schema
EER). Una volta costruiti gli N schemi scheletri di settore, si unificano (eliminando le possibili ridondanze) ottenendo
lo schema definitivo.
2. PROGETTAZIONE CONCETTUALE:
1. Aspetti strutturali: struttura statica delle informazioni (Schemi ER, Vincoli di integrità statici);
2. Aspetti dinamici: aspetti che si evolvono nel tempo (Evoluzione del DB, vincoli di integrità dinamici,
operazioni di base e operazioni degli utenti)
3. Aspetti quantitativi: quantità prese in considerazione nel DB (numero utenti potenziali, numero delle istanze
di associazione, frequenza di operazioni, ecc.)
a. Tavola dei volumi: numero stimato di istanze per ogni entità e associazione (R) dello schema.
b. Tavola degli utenti: utente, tipo, volume, permessi
c. Tavola delle operazioni: nome, scopo, argomenti, risultati, errori, tabelle usate, tabelle modificate,
prima, poi
Approcci all’implementazione
Al termine della progettazione si ottengono specifiche non eseguibili, cioè non si ottiene
codice; questo è infatti prodotto nella fase di
implementazione, nella quale possiamo avere due approcci
Waterfall
Prototipazione
In caso ci siano sinonimie o omonimie, nella progettazione concettuale ci va anche un glossario dei termini. Il suo
fine è la comprensione e la precisazione dei termini usati, in quanto conterrà una breve descrizione, possibili
sinonimi ed altri termini contenuti nel glossario con il quale esiste un legame logico.
3. PROGETTAZIONE LOGICA:
Modello relazionale: schema logico che si basa sulla teoria degli insiemi.
Negli insiemi si contano solo gli elementi distinti. Se ci interessa tenere traccia di quali e quanti sono gli elementi
ripetuti occorre usare una generalizzazione del concetto di insieme: il multinsieme. Si si indica con una coppia (A,f),
dove: A, è l’insieme di supporto del multinsieme; f è una funzione a valori naturali che rappresenta la molteplicità
del multinsieme.
Matematica: Sottoinsieme del prodotto cartesiano di due o più insiemi. R ⊆ (D1 x D2 x D3 x D4)
Ordine non rilevante nelle n-uple (a meno di usare il prodotto cartesiano etichettato: {s:’m’, n:’ciro’} );
Ordine rilevante nelle coppie. No n-uple uguali! (perché per def. È basata sul concetto di insieme).
Del modello relazionale: n-uple etichettate. Rappresentabile mediante una tabella.
o Ha schema R(Mat: String, Eta: int) e stato R(‘0124000884’, 21).
o ADOM(dominio di stato, variabile nel tempo) è SEMPRE SOTTINSIEME di DOM(dominio di schema).
Ordine di righe (intera riga) e colonne (ciascuna avente nome univocamente identificante) non rilevante!
Tuple ripetute possibile, a meno di chiavi!
Tra entità ed associazione (vista prima).
Lo schema relazionale è uno schema logico che ha un potere espressivo minore rispetto allo schema concettuale, di
conseguenza quando lo si “traduce” a partire da quest’ultimo è necessario fare delle scelte di compromesso.
È definito da una terna {R i}, {IC j}, {DF k} (relazioni, integrity constraint, dipendenze funzionale)
CHIAVE ESTERNA
Le associazioni tra le entità si rappresentano tramite il vincolo di chiave esterna: una o più chiavi primarie delle
tabelle coinvolte, finiscono in altre tabelle, assumendo il ruolo di puntatori alle entità coinvolte nelle associazioni.
Per esprimere il vincolo di obbligatorietà si usa il comando NOT NULL.
Per esprimere la non ripetibilità di valori di un attributo usiamo: CF Madre DISTINCT (ogni madre ha un solo figlio) (in
quanto stiamo imponendo che i codici fiscali delle madri non possano essere ripetuti). (UNIQUE è la stessa cosa ma
funziona solo su Oracle, e veniva utilizzata prima dello standard ansi che prevede DISTINCT).
Vincolo di integrità referenziale: il dominio di una chiave esterna è incluso nel dominio della chiave primaria
[ADom(FK) ⊆ ADom(PK)], quindi, non può succedere che la chiave esterna di una tabella punti ad un valore non
concretamente esistente nella tabella a cui fa riferimento.
Loop di chiavi esterne: bisogna fare attenzione a come si gestiscono le totalità sulle chiave esterne, in quanto
potremmo trovarci in un loop, dal momento che il vincolo di integrità referenziale impone un ordine. In altre parole,
potrebbe capitare che non possiamo inserire i dati in nessuna tabella, perché ognuna ha una totalità su una chiave
esterna dell’altra.
Paradossi di popolamento: in modo molto simile, ipotizziamo di avere la relazione: [persona] è madre di [persona].
Se mettessimo NOT NULL alla chiave esterna CF_madre, in fase di inserimento, si creerebbe nuovamente un loop, o
meglio un paradoso, in quanto quando si vogliono inserire i dati del figlio, si devono inserire i dati della madre; ma
quando quindi si vogliono inserire i dati della madre, bisogna inserire i dati della madre della madre, ecc.
MOLTEPLICITÀ
1:1 (senza totalità), si inserisce indifferentemente la chiave esterna in una delle 2 tabelle presenti
1:1 (con totalità), si inserisce preferibilmente la chiave esterna nella tabella dove c’è la totalità, in modo da
evitare spreco di spazio (causato dal fatto che la chiave esterna presenta valori nulli).
1:N, viene messa la chiave esterna sul lato N, in modo da non produrre tuple ripetute.
M:N, nuova tabella, con chiavi primarie delle 2 tabelle, ed eventualmente gli attributi dell’associazione
Tabella unica: si crea una tabella che contiene gli attributi della superclasse e di tutte le sottoclassi, e uno o
più discriminatori per specificare a quale sottoclasse appartiene la tupla.
Se c’è disgiunzione, il discriminatore è singolo, altrimenti c’è bisogno di più discriminatori in quanto le
sottoclassi si sovrappongono.
Vantaggi: è conveniente solo quando gli attributi specifici (cioè delle sottoclassi) sono pochi
Svantaggi: bisogna creare uno o più discriminatori, e nelle tuple potrebbero esserci molti campi vuoti.
Partizionamento Verticale: Oltre alla tabella della superclasse, si crea una tabella per ogni sottoclasse,
contenente gli attributi specifici ed una chiave esterna (che funge anche da chiave primaria).
Vantaggi: è conveniente solo quando gli attributi specifici (cioè delle sottoclassi) sono MOLTI.
Svantaggi: i dati vengono suddivisi (aumenta il costo per ricostruirli); c’è una duplicazione del campo chiave.
Partizionamento Orizzontale: Oltre alla tabella della superclasse, si crea una tabella per ogni sottoclasse,
contenente gli attributi specifici e gli attributi della superclasse stessa.
Svantaggi: si perde la possibilità di riconoscere che due sottoclassi provengano da una superclasse comune;
in presenza di sovrapposizione, si avranno duplicazioni; è applicabile solo quando c’è totalità; non è
applicabile quando c’è una relazione che coinvolge la classe madre.
ALGEBRA RELAZIONALE
Linguaggio procedurale che permette di recuperare le informazioni interne ad uno schema relazionale.
Si avvale di operatori che agiscono su relazioni (tabelle) e producono come risultato ancora relazioni (tabelle).
Essendo basata sulla teoria degli insiemi, nessuna relazione può presentare tuple ripetute.
Si noti che se una relazione ha una chiave primaria, certamente non presenta tuple ripetute.
OPERATORI UNARI:
Selezione: individua un sottoinsieme di tuple della tabella R che soddisfano la condizione c. σ<c> (R).
La condizione viene valutata nR volte (numero di di righe della tabella R).
Il numero di righe della nuova tabella sarà compreso nell’intervallo [0, nR].
Il numero di colonne della nuova tabella (attributi) resta invariato.
selettività: rapporto tra numero di tuple che verificano la condizione e il numero totale delle tuple nT / nR
Proiezione: fa una selezione sulle colonne. c. π <a> (R).
La condizione viene valutata nR volte (numero di di righe della tabella R).
Il numero di righe della nuova tabella sarà compreso nell’intervallo [0, nR] (varierà solo nel caso in cui fosse
compresa una chiave nella lista a).
Il numero di colonne della nuova tabella (attributi) sarà pari al numero di attributi specificati nella proiezione.
La proiezione generalizzata permette, in più, di proiettare colonne ricavate tramite operazioni fatte su
colonne già esistenti. πCF, Stip, Stip*0.2 as Tasse (Impiegato)
Sono gli operatori insiemistici. Le relazioni devono avere lo stesso schema (devono cioè essere compatibili all’unione)
Unione: date due relazioni R ed S, restituisce tutte le tuple appartenenti ad R, ad S o ad entrambi, evitando
le ripetizioni. R U S
Intersezione: date due relazioni R ed S, restituisce tutte le tuple appartenenti sia ad R che ad S (cioè
restituisce le tuple comuni). R ∩ S
Differenza: date due relazioni R ed S, restituisce tutte le tuple appartenenti ad R e non ad S R – S
OPERATORI GIUNZIONE
Sono gli operatori JOIN (un caso particolare del prodotto cartesiano, che tra X,Y è l’insieme di istanze, cioè l’insieme
di tutte le coppie possibili (x,y) con x Є X e y Є Y), ovvero si pone una condizione di giunzione, al fine di non ottenere
tuple spurie (che avrebbe restituito un prodotto cartesiano).
Consentono di unire, in un’unica tupla, più tuple logicamente collegate tra loro. R ⨝condizione S
Il Join avrà, quindi: un numero di righe compreso nell’intervallo [0, nR * nS ], un numero di colonne dato dalla
somma degli attributi delle tabelle.
La selettività del Join sarà data da: nT / (nR * nS) [nT = tuple che verificano la condizione]
RELAZIONE UNIVERSALE
Vantaggi: facilità e velocità nel recupero di informazioni (basta solo selezione e proiezione).
RISCRITTURA ALGEBRICA
Processo tramite il quale si sfruttano le proprietà algebriche degli operatori relazionali per riformulare una data
interrogazione, in modo da sceglierne la variante più efficiente. Infatti, non vi è un unico modo di esprimere
un’interrogazione in algebra relazionale. Sebbene più modi portino ad uno stesso risultato, bisogna fare attenzione a
quale scegliere, per motivi di efficienza. In particolare, bisogna fare attenzione ai Join, e cercare di ridurre le tuple su
cui esso opera.
Proprietà associativa: R ⨝ S = S ⨝ R , ( R ⨝ S ) T = R ⨝ ( S T )
Si vogliono i nomi di tutti i docenti dello studente Mario Rossi. Tale operazione può essere fatta in più modi, tra cui:
Supponiamo i seguenti valori delle selettività dei Join, dove J1=Join con condizione CodEs=CodEsame, e J2
Matr=Cand, e l’ultima è la selettività della selezione. S ( J1 ) = 0.2 S ( J2 ) = 0.1 S(Mario Rossi)=0.01
Ora calcolare il numero di risultati intermedi che generano i 2 metodi visti, quello migliore sarà quello che ne avrà
generati di meno.
1)
2)
È facile notare che la prima soluzione è molto più efficiente della seconda.
SQL
L’SQL (Structured Query Language) è un linguaggio di interrogazione strutturato, creato per l’accesso a informazioni
memorizzate nei database. Permette di interrogare e gestire basi di dati mediante l'utilizzo di costrutti di
programmazione denominati query.
Le interrogazioni SQL, SPJ(Select,Project,Join), a differenza dell’algebra relazionale, sono MULTINSIEME e si possono
avere duplicati.
DDL
Data Definition Language, linguaggio che permette di creare, modificare ed eliminare un database.
Non permette di gestire i dati presenti (per quello c’è il DML).
DML
Data Manipulation Language, linguaggio che permette di leggere, inserire, modificare ed eliminare dati di un
database.
Una sequenza di modifiche ad un database (ad esempio una sequenza di comandi INSERT, UPDATE
e DELETE) viene chiamata transizione. Le modifiche delle tuple vengono temporaneamente
memorizzate nel DBMS. Diventano permanenti solo dopo aver eseguito il comando COMMIT.
Fintantoché l’utente non ha eseguito il comando COMMIT, è possibile annullare tutte le modifiche
fino al precedente COMMIT. L’annullamento delle modifiche viene eseguito con il comando ROLLBACK.
E’ consigliabile completare ogni modifica del database con un comando COMMIT.
Un comando COMMIT è inoltre implicitamente eseguito quando l’utente termina una sessione ORACLE.
Data Control Language, linguaggio che permette di dare/revocare permessi agli utenti.
POLITICHE DI REAZIONE
N.B. Non si può cancellare con DROP TABLE una tabella che ha chiavi esterne (relazionate ad un’altra tabella).
Si provvede a forzare il cancellamento della tabella rendendo il campo “chiave esterna” dell’altra tabella vuoto.
VISTE
La lista è l’alias di una query, che serve a dare un nome ad un’interrogazione, per trattarla come se fosse una tabella.
Esempio: [tabella che contiene il nome e il cognome degli studenti]
CREATE VIEW NOME_COMPLETO AS SELECT NOME, COGNOME FROM STUDENTE
Vantaggi: sono dinamiche, ovvero vengono eseguite ogni volta che vengono richiamate.
le righe sono recuperate/modificate come se fosse una tabella vera e propria.
Svantaggi: costo computazionale elevato; aggiornamento dei dati (la lista è riferita ad un particolare istante).
Materializzate: Viste che vengono registrate nel database; preferite alle viste semplici se vi è un frequente accesso.
Vantaggi: computazionale (è salvata sul disco, quindi basta leggere i dati, senza rieseguire la query);
Svantaggi: resta il problema dell’aggiornamento.
La politica di REFRESH è decisa dal progettista: [in coda alla query] REFRESH ON [commit] / [demand],
rispetttivamente per rigenerare ogni volta che c’è un’operazione di modifica[pericolosa], o ogni sera, ora, ecc…
ASSERZIONI
Permettono di specificare dei vincoli su attributi, domini e tuple, che annulleranno un’operazione che causa una
violazione. Esempio: [stipendio di un impiegato < di quello di un dirigente del dipartimento per cui egli lavora]
CREATE ASSERTION VINCOLO_STIPENDIO CHECK (NOT EXISTS ( SELECT *
AND D.SSN_DIR=M.SSN ) ); [Se il risultato dell’interrogazione non è vuoto, allora l’asserzione è violata].
Differenza con il CHECK: i vincoli di quest’ultimo sono vincoli di domini (molto limitati).
Assertion dovrebbe essere usata per fare controlli più sofisticati e complessi.
TRIGGER
Blocchi di istruzioni procedurali che si attivano in caso di determinati eventi. Modello ECA: evento-condizione-azione.
Gli eventi sono solitamente operazioni di INSERT/UPDATE/DELETE (combinabili usando la logica OR).
La condizione determina se l’azione del trigger dev’essere eseguita o no.
L’azione da intraprendere, è di solito una sequenza di istruzioni SQL e una lancio e gestione di un’eccezione.
Differenze con assertion: è “agganciato” ad una sola tabella, si riduce dunque l’overhead.
I trigger possono essere utilizzati per implementare le regole di business e vincoli dinamici. La differenza tra questi
due è molto sottile. Infatti i vincoli dinamici sono intesi come vincoli di integrità sui dati, cioè controlli su azioni che
non si dovrebbero compiere sulla base di dati; le regole di business, invece, sono regole di funzionamento
dell’azienda che non necessariamente consistono nell’impedire un azione.
Solitamente, specialmente per la progettazione di applicazioni web che utilizzano database, si cerca di tenere
separati la logica di business e la gestione dei dati in modo da poter modificare la logica di business senza dover
alterare la base di dati.
ESTENSIONI
Embedded SQL: separate istruzioni, ad esempio, Java ed SQL. [es: Pro-C, SQLJ, ecc.]
È definito come un approccio di programmazione.
Vantaggi: Costrutti dei linguaggi, quali if, for, while, ecc.
Svantaggi: approccio statico (l’interrogazione è scritta all’interno del programma e non può essere cambiata
senza ricompilare o rielaborare il codice sorgente); conflitto di impedenza;
API: chiamate di sistema standard per sottomettere query al DB. [es: Java: JDBC.]
Vantaggi: Basta montare il driver del DBMS;
passaggio sottoforma di stringhe (il sorgente resta al 100% nel linguaggio originale).
Svantaggi: conflitto di impedenza non risolto; query passate a run-time (nessun controllo sintattico).
4GL (Fourth Generation Language): [es: PL/SQL]
si aggiungono ad SQL alcuni costrutti dei linguaggi di programmazione, estendendone le funzionalità.
Vantaggi: Nessun conflitto di impedenza ( i tipi sono quelli di SQL );
compilatore/motore DBMS specifici per codice SQL, + controllo sintattico, + efficienza.
Conflitto di impedenza : problemi che possono causare perdita della struttura della tabella e/o incoerenze.
I tipi di dato non sono “nativi”, quindi ad esempio il tipo TABLE subirà una “conversione”.
N.B: TRUNCATE è come DELETE, ma essendo un comando di tipo DDL, Oracle esegue una COMMIT automatica.
PROPRIETÀ ACID
Atomicità: indivisibile nella sua esecuzione (non sono ammesse esecuzioni parziali), e ammette 2 stati: (fallito, no).
Consistenza: garantisce tutti i vincoli (sia quando prima che dopo operato).
Isolamento: ogni connessione ha una transazione diversa, ed agiscono come se fossero isolate.
Dirty Read: più transazioni possono leggere i dati modificati da altri, mentre le stesse sono in corso.
T1 | R(disp) | | W(prenotaz) |
T2 | | R(disp) | | R(disp) <- disponibilità è cambiato
Unrepeatable Read: Simile a DR; leggendo la stessa variabile nel corso della stessa transazione, non ottengo lo
stesso risultato.
Phantoms: supponiamo di voler stampare su schermo i valore disponibili. T2 stampa, T1 inserisce nuovi valori, T2
stampa nuovi valori. Nella seconda stampa, T2 ha stampato valori che non erano nella prima stampa.
N.B: è diverso da lettura non ripetibile, in quanto i dati restano gli stessi, ma compaiono più tuple.
Servono dei protocolli per garantirli. Le famiglie di protocolli più grandi ed usati che ci sono sono:
Riveste un ruolo importante nella valutazione della qualità di uno schema relazionale.
DIPENDENZA FUNZIONALE
R: [cf_proprietario, nome, cognome, cod_casa, via, cap, civico, tel_fisso, email, superficie]
T=insieme di tutti gli attributi di R (relazione universale), X,Y,W = uno o più attributi qualsiasi.
t1 e t2 sono 2 tuple di R, se si verifica che la proiezione di t1 su x è uguale alla proiezione di t2 su x, e questo implica
che la proiezione di t1 su y è uguale alla proiezione di t2 su y, allora X determina funzionalmente Y, o Y dipende
funzionalmente da Y. Formalmente:
Es: quando il cf è uguale => nome e cognome sono uguali. CF -> NOME
quando il telefono (fisso dell’abitazione, unico) è lo stesso, anche codice casa è lo stesso. CF -> COGNOME
Tale relazionale non è simmetrica (X -> Y non implica per forza Y -> X), es: se il telefono fisso è uguale, la superficie è
uguale, ma quando la superficie è uguale, il telefono fisso non lo è (ci possono essere più appartamenti con la stessa
superficie).
È una proprietà DELLO SCHEMA, quindi NON può essere osservata dalle tuple (stato), in quanto vale lo stesso
discorso della chiave (potremmo avere una tabella con 100 studenti, ma tra questi nessuno ha lo stesso cognome,
ma cognome non può fare da chiave). Non ci può essere tra più relazioni.
Due insiemi di dipendenze funzionali F,G sono equivalenti (una copertura) quando F+=G+
Le regole più comuni che si usano, come regole di inferenza (cioè per dedurre) delle df, sono i cosiddetti:
ASSIOMI DI ARMSTRONG
Correttezza: Se F |- X->Y, allora F |= X->Y [se f è derivabile da X->Y, allora F implica logicamente X->Y]
(ESISTE DAVVERO)
Completezza: Se F |= X->Y, allora F |- X->Y [tutte le df che esistono sono derivabili!]
COPERTURA CANONICA
Siccome esistono più insiemi di dipendenze funzionali equivalente, ci poniamo il problema di quale sia un insieme
minimo di dipendenze funzionali, a partire dalle quali si possono generare tutte le altre: copertura canonica.
Si tratta di un insieme df, che gode di 3 proprietà:
No attributi estranei (X -> Y appartiene ad F+, dire che c’è un attributo estraneo equivale a dire che anche la
df X – {A} -> Y appartiene ad F)
No df ridondanti (F+ - {X -> Y} coincide con F+)
Ogni parte dx di una df ha un unico attributo: X -> Y, Y dev’essere composto da un solo attributo.
È sempre possibile, partendo da un insieme di dipendenze funzionali, costruire la copertura canonica. A destra ci sta
sempre un solo attributo. X->ABC => X->A, X->B, X->C
In pratica: quando si fa una scomposizione, questa deve conservare i dati, e conservare le dipendenze.
NORMALIZZAZIONE
N.B: Talvolta, di proposito, si consente di avere schemi non normalizzati, per ragioni sostanzialmente prestazionale,
in quanto frammentando le relazioni, occorrono join (costosi). In caso di aggiornamento raro, e milioni di record, si
potrebbe pensare di utilizzare un’unica tabella. Molto utilizzata nelle data warehouse.
1 FORMA NORMALE:
Il rispetto è in qualche modo implicito nel concetto di modello relazionale, che tra le tante assunzioni, include anche
quella dell’atomicità degli attributi (semplici e divisibili).
2 FORMA NORMALE:
Tutti gli attributi non primi dipendono(df) in maniera completa (e non parziale!) dalla chiave.
Entra in gioco nel momento in cui ci sono chiavi con più di un attributo. Attributi primi sono quelli che fanno parte
di una qualsiasi chiave, anche tra quelle candidate.
Es: [nome, VIA, CAP, città, STATO] via,cap,stato -> nome; via,cap,stato -> città;
La seconda forma normale vuole che, ad esempio, la dipendenza di città sia completa, ovvero sia rispetto a TUTTI gli
attributi (via,cap,stato) e non solo a una parte di questi. In altre parole, vuole che non si siano attributi estranei.
Se tolgo stato (o via, o cap), la dipendenza funzionale con nome non c’è più (dipende in modo completo).
Ma se lo faccio da città, assumendo che ci sia un solo cap per ogni città, non perdo la df. Quindi città è un attributo
primo, e non violiamo la 2FN; ma se città è un attributo non primo(supponiamo ci siano più cap per ogni città),
abbiamo che dipende solo PARZIALMENTE dagli attributi della chiave, e violiamo la 2FN.
Più formalmente: Il rispetto di questa forma si basa sul concetto di dipendenza funzionale completa. Ricordiamo
infatti che una dipendenza funzionale X Y si dice completa se per ogni attributo non primo(ovvero che non fa
parte di nessuna chiave candidata) Y, si ha che esso non dipende solo da una parte della chiave. In altre parole, la
rimozione di qualsiasi attributo dalla chiave, annulla la dipendenza funzionale tra X e Y.
Boys Codd Normal Form: le decomposizioni che la rispettano conservano sia i dati che le dipendenze.
3FN: sempre raggiungibile (Algoritmo di sintesi: Serve per portare uno schema in 3FN), è meno restrittiva, ma non
possiamo essere sicuri di conservare le dipendenze.
Per la verifica della terza forma normale, le relazioni non devono contenere attributi non chiave
funzionalmente dipendenti da altri attributi non chiave (o da un insieme di attributi non chiave), ed in
effetti non esiste alcuna dipendenza transitiva tra attributi non chiave e la chiave primaria.
Si verifica una dipendenza funzionale transitiva quando un attributo J appartenente alla relazione r dipende da un
attributo K della relazione che non è chiave candidata e che a sua volta dipende da un attributo A, che è chiave
candidata o primaria.
VIDEOCASSETTE (Identificativo_videocassetta, Genere, Collocazione)
Identificativo_videocassetta è la chiave primaria, essa identificando la videocassetta
determina il Genere; le videocassette vengono collocate raggruppandole per genere.