Appunti Basi di dati completi

HAVING

pone delle condizioni sui valori aggregati cosa che non può fare la WHERE perché può avere accesso ai dati di un singolo record e non aggregati

, (incasso-giorni

sum

Selec t cittá

From vendite

Citta

By

Group L'Milano'

(Incassagiorni) atta

And

> 100

HavinG Sum 000 ,

.

È più performante mettere nella clausola HAVING solo le condizioni , (incasso-giorni

sum

Selec t cittá

sui valori aggregati e le altre condizioni nella WHERE From vendite

# ,

t Milano

WHERE

By

Group

Le condizioni relative a valori aggregati possono essere inserite solo (Incassagiorni) > 100

HavinG Sum 000

nella HAVING .

Le condizioni che insistono su tuple singole possono essere inserite

sia nella WHERE sia nella HAVING e quando possibile è meglio

spostarle nella WHERE per ragioni di performance

operatori matematici

possibile combinare gli operatori aggregati con gli operatori matematici,

É

l’uso delle formule matematiche permette di memorizzare solamente un

insieme minimale di dati risparmiando spazio

* at)

(Cricavo-costo From

SELECT vendite

Sum where"

Nel nel from

non

e

al id-cliente

tab-ore-lavorate (importa

dipendente

SELECT SELECT Store sum

from ,

,

(

10) tab-vendite

...

(1

In store

Store From

WHERE NOT AND In

2 ,

, valo

di

pie

↳ totto 10

1 2

ID ,

,

,

& Cliente)

id

(store (in124)

Where in

not

-

, id id

Store cliente

visualizza per ogni cliente l’importo

Where

trow Importo

anche

Nelle < ALL

query =

>

- massimo

st From

LECT importo

-

---

&

operatori insiemistici

# vendite tv

tab

SELECT As

from - le

tv di

Visualizza vendite

Importo cliente

WHERE ogni

All per

. del

vendite

(delle

media

alla

importo sup . Cliente)

Singolo

(Select tab-vendite tue

(importo) from

aua as

tuid

id-cliente cliente

tv2

WHERE =

. -

C ,

ALL, ANY, IN

sono utilizzati nelle espressioni condizionali , permettono di confrontare un elemento con un insieme

valore/un attributo

un almeno uno

5 ↳

ES .

→ sintassi Elemento [operatore] ANY/ALL/IN insieme di

↳ risultato query

una

↳ 2 4

L =, =...

,

, di valori

elenco

o un (7

t r a

racchiusi risultato

>

-

producono stesso

La seconda query più efficiente perché nel primo caso la sotto-

è

query viene rieseguita per ogni record della query esterna. Le

sotto-query correlate sono inefficienti !

Nel secondo caso la sotto-query viene eseguita una sola volta

Considerazioni

Le sotto-query prendono le interrogazioni in efficienti:

• va data la preferenza a query senza annidamenti

• non sempre possibile farne a meno

è

Le query annidate evitano di dover materializzare i risultati di alcune query, tuttavia in alcuni casi può essere conveniente materializzare:

• se i dati di partenza sono stabili nel tempo

• I dataset hanno grosse dimensioni

• La computazione delle sotto-query molto onerosa

è

IN E NOT IN

rallentando la query permettere

>

- Necessario per

di lavorare

all'HavinG

le condizioni per realizzare il collegamento tra tabelle

JOIN

Permette di separare la condizione clausola WHERE in due parti le condizioni di selezione vere e proprie

Esempio

→ nel where, si indicano n-1 condizioni tabelle

3 Condizioni 3-1

n -1 2

>

- =

=

Where tab1 tab

esterna

chiare tab

chiave Chiave primaria chiave

primaria 2 AND 2

= =

.

. tab

esterna 3

.

Sintassi con chiave on per distinguere JOIN e condizioni di selezione

>

- Condizione di JOIN l'insieme di due operazioni:

è

• prodotto cartesiano, l'ordine non crea problemi

• condizioni con and non crea problemi l'ordine; se ci fosse or si

Left (outer) JOIN

Con il left JOIN si aggiungono anche i dati della tab.di sx con

nessun attributo della tabella di dx con valore "NULL" E

prietariasp p)

id

id-p

>

- a

(p =

JOIN ;

LEFT As

AUTO on

a . -

.

LEFT JOIN

un Join ma vengono aggiunti anche i dati che non partecipano normalmente al Join

É

SELECT Nella tabella risultato entrano:

FROM B

JOIN

LEFT

A • le tuple di A e di B che soddisfano la

(A KEY)

ON B

KEY A B

;

= condizione A.key = B.key

.

. • Le tuple di A che non soddisfano A.key = B.key

*

L’intersezione rappresenta i

record delle due tabelle con

chiavi in comune

Left excluding (OUTER) JOIN SELECT Restituisce solo le tuple di A che non

Visualizza tutti i proprietari che >

- B soddisfano A.key = B.key

non hanno l'auto proprietari A

Asp

From (pid-p id-p)

LEFT JOIN ON

auto a

As a = .

id-P is NULL

WHERE

RIGHT (OUTER) JOIN Nella tabella risultato entrano:

• le tuple di A e B che soddisfano la condizione

A

SELECT A B A.key = B.key

key)

(A

FROM RIGHT JOIN B

B Key

ON

A = ;

·

. • Le tuple di B che non soddisfano la condizione

A.key = B.key

FULL OUTER JOIN Nella tabella risultato entrano:

SELECT

# • le tuple di A e B che soddisfano la condizione

B

A A.key = B.key

(A

BON

OUTER Key)

ROM JOIN

FULL

A B

- KEY ;

= . • Le tuple di B che non soddisfano la

condizione A.key = B.key

• Le tuple di A che non soddisfano la

condizione A.key = B.key

I

Il FULL OUTER JOIN può essere ottenuto con un escamotage

- A

SELECT LEFTJOIN ON

B KEY

FROM KEY-B

A A .

UNION

SELEG RIGHT JOIN

FROM KEY-B

B ON KeY

A

A ,

.

UNION

permette di unire il risultato di due o più query

Le due query devono avere un output compatibile:

• stesso numero di attributi in output

• Alcuni DBMS richiedi i che i tipi degli attributi corrispondenti siano compatibili

in caso di due o più record identici, solamente uni viene visualizzato (eliminazione di duplicati)

ATTENZIONE

SELECT B B

ON A KEY

JOIN Key

LEFT

A

FROM =

. . Questa query non equivalente alla prima perché viene cambiato l’ordine degli attributi e questo può dare problemi

é

UNION A

SELECT B

ON

FROM A

JOIN Key

B RIGHT Key A

= ;

. .

distinct

SELECT query

una

da

duplicati

record

eliminare

per

Serve attrn

Select attra

attra

Distinct , ...,

,

taba

From ;

Se ci sono due o record duplicati nella tabella di output solo il primo viene visualizzato, gli altri vengono eliminati

equivalente ad usare group by

É attun

attra

Attra

SELECT , ...,

,

From tab A

.

Group by attra

attra N

ater

, , ...,

Permette di capire quali sono i possibili valori che lui assumere un attributo (il dominio dell’attributo)

I Non conviene usare DISTINCT con le funzioni di aggregazione

① where

nel

Esempio Join

Visualizzate per ogni libro il titolo,il prezzo e la descrizione del formato

LIBRI

FORMATO codice

Codice

· ·

descrizione #

· cod-formal

-

·

descrizione from

titolo formato

Select libri

prezzo

,

, ,

libri

where formato

coo-format Codice

= .

. titolo

As Select

>

- F

film regista

From as as r

,

QUERY ANNIDATE

Livelli di aggregazione

sum

- BY

GROUP

-

GRANULARITÀ l'insieme delle un'unità

ad di informazione

chiavi associate (senza f

determinate attributi

da

tab

nella output

di aggregazione)

Le chiave

chiari

↳ sono

. .

la

attributi By

usati Group 2

per

ESEMPI (importa

select sum granularità

· di data

sum(importo) store

..., - : ,

tab-vendita

From

Group By data store ;

,

A

SELECT

· Granularità id-cliente

tab-vendita di data

importo Store

From ,

: ,

; >

-

aggregazione

Nessuna

Nelle tabelle dove abbiamo dei valori numerici associati a chiavi formate da più

valori ci si può porre i problema della granularità

→ l’inverso della granularità

LIVELLO è

DI DETTAGLIO più aggrego i dati, più perdo i dettagli e più aumenta la granularità delle informazioni

fine/alto dettaglio

livello di

granularità

e >

-

dettaglio

elevata/basso

granularità livello di

2

ESEMPI

① tab-vendite

from

a

Select

② (importa

Select sum

..., vendite

tab

From -

Store

By

Group ;

(store

TAB-vendite data importa

id-cliente

,

, ,

(Store ore-lavorate

data id-dipendente

Tab-ore-lavorate , ,

, ?

degli attributi

granularità

è la

Qual

· P.S. Se la chiave primaria composta da un solo attributo difficilmente ci possono essere

Per importo: store,data, id-cliente → posso unirle con un JOIN solo se le granularità sono compatibili è

problemi di granularità.

In questo caso

Per ore_lavorate: store, data, id_dipendente Non possibile perché le funzioni di aggregazione avvengono dopo il JOIN

è

→ Prima aggregare per uniformare la granularità e poi mettere in JOIN i risultati dell'aggregazione, significa che flusso standard

non può essere usato

prima di collegare le informazioni ho bisogno di uniformare la granularità

Id_cliente e id_dipendente non sono compatibili

↓ tot-importa

(importo

data sum

store data

Select store

· -

,

, ,

, → ora i singoli record delle due tabelle aggregate possono essere messi in Join, MA NON CON UNA QUERY STANDARD

tab-vendite

From By data

Group store Perché in una query standard l’operazione di join avviene prima delle operazioni di aggregazione

;

, (store

sumcorelavorate) ore-lavorate)

Select data data tot

store

· -

, , -

,

From tab-o