Appunti per l'esame orale di Databases

R R

In un caso di decomposizione vorremmo che per tutte le

1 2

possibili relazioni r dello schema R

= Π (r) ⋈ Π (r)

r R R

1 2

Una decomposizione di R in R1 ed R2 è lossless se e solo se vale

almeno una delle seguenti affermazioni

∩ →

R R R

1 2 1

Normalizzazione 6

∩ →

R R R

1 2 2

Preservare le Dipendenze

Una decomposizione di R in Ri tabelle con le loro D.F. Ri preserva le dipendenze se e solo

se: + +

(F ∪ ∪ ... ∪ ) =

F F F

1 2 n

⚙ esempio

→

α β

Algoritmo per verificare se la DF è preservata

ddalla decomposizione di R in R1...Rn (con la chiusura

degli attributi fatta rispetto a F)

α

result =

finchè: (risultato viene modificato) fai:

R

per ogni della decomposizione

i +

∩R )

t = (result i ∪

result = result t β

Se result contiene tutti gli attributi , allora la

→

α β

dipendenza funzionale è preservata

Utilizzando questa procedura possiamo verificare in

tempi polinomiali se le dipendenze vengono preservate

dalla decomposizione

Testing BCNF

⚙ →

α β

Algoritmo per verificare se una dipendenza non-banale causa una violazione

della BCNF +

α

1. Calcolare +

α α

2. Verificare che in ci sono tutti gli attributi di R, allora è superchiave di R

Test semplificato:

Per verificare se uno schema relazionale R è in BCNF + sufficicnte controllare solo le

dipendenze funzionali in F e non in F+, ma questo è solo possibile per la relazione

madre e non per le figlie.

⚙ Algoritmo per verificare se una relazione Ri in una decomposizione di R è in BCNF

Metodo 1:

Testare (non semplificato) se la Ri è in BCNF usando la rispettiva restrizione di

F di Ri (ovvero tutte le dipendenze funzionali in F+ che contengono gli attributi di

Ri)

Metodo 2:

Utilizzare l’insieme F delle dipendenze di R, con il seguente test:

⊆

α R

per ogni insieme di attributi controllare se vale una delle seguenti:

i

+ −

α R α

- non includa gli attributi di o

i

+

α R

- include tutti gli attributi di i →

α β

se la condizione è violata da una qualsiasi DF n F

+

→ (α − ∩

α α) R

si può dimostrare che la dipendenza implica Ri ed Ri viola

i

la BCNF si può utilizare la dipendenza sovrastante per decomporre Ri

Normalizzazione 7

Decomposizione in BCNF:

⚙ Algoritmo per decomporre una relazione in BCNF

result := {R} ;

done := false ;

compute F+ ;

while (not done) do

if (è presente uno schema Ri in result che non è in BCNF)

then begin

→

α β

sia una dipendenza funzionale non banale in Ri tale che:

→

α R non è presente in F+ ;

i

∩ = ∅

α β ;

(result − ) ∪ (R − ∪ (α,

R β) β);

result := // Rimuovo la tabella non in BCNF,

i i

inserisco le due tabelle figlie, // la prima è Ri senza beta, la

seconda contiene solo alpha e beta

end

else done := true

esempio

3NF

Vi sono casi in cui la BCNF non mantiene le dipendenze funzionali. esempio BCNF vs

3NF

In certi casi è necesario mantenere delle dipendenze funzionali

senza ricavarle con i join, motivo per il quale vi è la 3NF che:

ammette ridondanze

le dipendenze funzionali vengono mantenute dalle relazioni

“figlie”

vi è sempre una decomposizione lossless in 3NF

Normalizzazione 8

Testing 3NF

⚙ Algoritmo per verificare se una relazione è in 3NF →

α β

1. Utilizzare la chiusura degli attributi per verificare che ogni dipendenza ,

α

se è superchiave OK

α β

2. Se non è superchiave allora bisogna verificare che ogni attributo in è

contenuto in una chiave candidata di R

Ottimizzazione: Si possono controllare solo le DF in F, non è necessario controllare

quelle in F+

è un problema NP difficile

è molto costoso perchè bisogna individuare le chiavi candidate

Decomposizione in 3NF

⚙ esempio

Algoritmo per decomporre una relazione in 3NF: ongi

relazione Ri

è in 3NF

la

decomposizion

è lossless

è mantiene

le DF

3NF vs BCNF BCNF 3NF

Decomposizione Lossless Join Lossless Join

Dipendenze Preservate NON sempre Preservate sempre

Ridondanza No Si

Normalizzazione 9

Gli obiettivi della progettazione

Gli obiettivi della progettazione di un database relazionale sono i seguenti:

BCNF

Lossless Join

Mantenere le dipendenze

Nel caso in cui non fosse possibile, si può tollerare

NON DF preservate (meglio a livello teorico, ma sconsigliato nell’uso reale)

Ridondanza a causa della 3NF (peggio a livello teorico, ma consigliato nell’uso reale)

SQL non ha strumenti specifici per specificare le dipendenze funzionali

se non le superchiavi

Normalizzazione 10

Application Design and Development

Capito

Mastery

Fonte https://2022.aulaweb.unige.it/pluginfile.php/112450/mod_resource/content/1/ch8_APPL%

6

Ordine Media

Priorità

Introduzione

In generale chi utilizza un database lo fa attreverso un interfaccia e non tramite un

linquaggio come può essere l’SQL.

Vi sono due possibilità, una utilizzata un tempo e l’altra invece utilizzata ancora oggi:

1. Creare e distribuire un client adhoc

Si sviluppa un client in linguaggio procedurale

Si utilizzano delle librerie che permettono di passare da istruzioni procedurali a

quelle associative dell’sql

un pro è quello di poter gestire interamente il client

Un contro è che gli aggiornamenti devono essere fatti manualmente per ogni client

2. Sviluppare un client web

il database è accessibile attraverso il WWW

pro: si può mantenere aggiornato il client aggiornandolo in backend

pro: l’utente non deve installare nessun programma e il database è facilmente

accessibile da browser (interoperabilità)

pro: si possno utilizzare i protocolli messi a disposizione da internet

contro: il processo iniziale di sviluppo è più difficile rispetto al client ad hoc

si può creare un interfaccia attraverso HTML (e javascript)

HTML e HTTP

HTML: HyperText Markup Language

HTTP: HyperText Transfer Protocol

HTTPS: HyperText Transfer Protocol Secured

HTML:

È uno script language, indica la struttura/layout delle pagine web, il browser (client)

mostra la pagina web seguendo ciò che indica il linguaggio HTML.

Utilizza un protocollo di comunicazione, HTTP

HTTP:

È un protocollo di comunicazione connectionless

non viene mantenuta una connessione permanente tra client e server

Application Design and Development 1

ogni volta che viene richiesto qualcosa sul server, il client invia una richiesta http

e il server rispondeù

ho quindi una serie di richieste “indipendenti”

vantaggi:

maggiore scalabilità grazie alle brevi intereazioni

resistenza alle interruzioni di connessione

senza memoria

non vengono memorizzati i dati della sessione

il server non è in grado di mantenere le informazioni sullo stato della sessione tra

le richieste e il client

Cookie:

Nascono per permettere al server di memorizzare i dati della sessione

Sono dei file di testo/pezzi di codice caricati sul client

Sono salvati localmente

Contengono informazioni utili per connettersi al server

memorizzano le credenziali (ad esempio)

identificano la sessione assegnandogli un ID

permettono di utilizzare la connessione al DB in modo efficiente

Server Web

URL: Uniform Resource Locator

“Indirizza” il client verso il server

ODBC: Open DataBase Connectivity

Sono delle librerie che permettono ai linguaggi procedurali di interagire con il

database

Architettura e due livelli di un server web

Il client interagisce direttamente con Arrchitettura a tre livellu di un server web

il server per eseguire le operazioni

richieste. Il client intereagisce con il server di

client (browser) applicazione, che gestisce la logica

dell’applicazione e comunica con il server di

server (+ database) database per recuperare o salvare i dati, separando

la gestione logica dell’applicazione da quella dei

dati.

Application Design and Development 2

Più scalabile rispetto all’architettura a due

livelli

client

application server

separa la gestione dei dati dalla gestione

della logica dell'applicazione

database

Triggers

I trigger sono una sequenza di istruzioni procedurali che si attivano (da cui triggers) in

risosta ad un operazione specifica eseguita su una tabella.

Gli eventi che attivano i triggers possono essere degli specifici:

insert

delete

update

Quando essi si attivano eseguono una serie di azioni specificate.

Svantaggi:

non appartengono allo standard SQL (NO universali, NO portabilità)

impattano in modo significativo sulle prestazioni se mal progettati

se mal progettati potrebbero causare problemi di funzionamento al database

ad esempio potrebbero cambiare delle chiavi primarie

se sono molti possonon rallentare le prestazioni del DB e causare problemi di scalabilità

spesso sono indicatori di una normalizzazione insufficiente

after

il trigger viene eseguito prima della query

before

il trigger viene eseguito dopo la query

contiene delle istruzioni procedurali

Utilizzo:

vengono utilizzati per automatizzare processi comuni

utilizzati per garantire l’integrità del database

es. inviare una mail quando un dato viene aggiornato

Esempio

Application Design and Development 3

⚠ I triggers NON appartengono allo standard SQL

Utilizzare solo il DBMS attraverso i triggers

Per sviluppare delle applicazioni procedurali che interagiscono con il database ho due

opzioni:

1. Utilizzare un linguaggio procedurale ed accedere al database mediante le ODBC

2. Far fare tutto al DBMS tramite triggers

a. vengono sviluppate delle procedure SQL a disposizione degli utenti

b. caratteristiche

Il DBMS gestisce i propri dati

Ho uno “strato” di software sul DBMS che utilizza i triggers

Si ha una maggiore sicurezza

Sicurezza

Application Design and Development 4

Application Design and Development 5

OODB Capito

Mastery

Fonte https://2022.aulaweb.unige.it/pluginfile.php/112451/mod_resource/content/1/ch9_OODB_

7

Ordine Bassa

Priorità

Introduzi