SQL SERVER
Modulo 4
Relatore: Stefano Furlan
Una premessa
• Lezioni pratiche con in mente il progetto
• Requisiti
• Information retrieval
• Non avere paura di usare google
• Capacità progettuale
• Dove voglio arrivare? (definizione della specifica)
• Cosa mi serve per arrivarci? (analisi)
• In che ordine lo faccio? (separazione dei task)
• Come capisco che sono arrivato? (verifica del risultato)
• OVVERO:
Buonsenso!
Cos’è un DBMS?
• In realtà dovremmo chiederci…
?
• A COSA CI SERVE?
• A quali domande del nostro committente dobbiamo dare risposta?
Architettura di un sistema di telecontrollo
Dati
Sistema di
controllo
Controllo
Pannelli
fotovoltaici
Utente
Collettore
dati
DB
Applicazione
di
configurazio
ne
Sistema di
reportistica
A cosa serve un DBMS?
• Storage Dati
• Ma quali dati?
• Dati tecnici
• Configurazioni
• Logs
• Siamo fortunati: tipicamente una base dati per il
telecontrollo è piuttosto semplice
Struttura del DBMS
QUERY
SQL
MOTORE
Dati
DATI
LINGUAGGIO SQL
• Structured query language
• Comandi testuali strutturati per il database
• DML (data manipulation language)
• DDL (data definition language)
• Vantaggio: compatibilità
• TSQL: dialetto di MS Sql Server
SQL SERVER
• È un sw server!
• Come lo contatto?
• Meccanismo di istanze (Nomemacchina\nomeserver)
• Accesso usando tool SSMS
• Interfaccia user friendly
• Query testuali
Operazioni preliminari
• Accesso con SSMS
• Creazione di un DB vuoto
• Skip delle impostazioni
CREAZIONE DI UNA
BASE DATI
MAPPARE LA STRUTTURA
DELLA REALTA’
• PANNELLI (3 pannelli piccoli e uno grande)
• GRUPPI (divisi in due zone)
• ENERGIA PRODOTTA (che producono energia ad ogni
ora)
ENTITÀ FONDAMENTALI
in una base dati
• TABELLE
• Campi (colonne) tipizzati
• Chiavi
• Indici
• RELAZIONI
• Chiavi esterne
• VISTE
• PROCEDURE
OPERAZIONI FONDAMENTALI
in una base dati
• Lettura o selezione (SELECT)
• Scrittura o inserimento (INSERT)
• Modifica (UPDATE)
• Cancellazione (DELETE)
TABELLA
IdPannello
Nome
Potenza
DataInstallazione
1
Pannello 1
3kW
1/1/2013
2
Pannello 2
2kW
1/1/2013
3
Pannello 3
2kW
1/3/2013
4
Pannello 4
null
1/3/2013
Esempio di tabella
TABELLA
• CAMPI tipizzati
• Numerici
• Interi
• Tinyint (1 byte)
• Smallint (2 bytes)
• Integer (4 bytes)
• Bigint
(8 bytes)
• Frazionari
• Float
• Decimal(x,y)
• Money
0-255
-32000 +32000
+-miliardi
+- le particelle dell’universo
(attenzione: errori di arrotondamento)
(preciso ma lento)
(4 cifre decimali)
• Testuali
• Char(x)
• Varchar(x)
• nvarchar(x)
• Date
• Date
• Datetime
• Altri (poco usati)
(+-2^31)
(+-2^63)
(unicode)
TABELLE: chiave primaria
• Campo o campi che permettono di individuare
univocamente ciascuna riga
• Spesso un codice ID intero ad auto incremento
idPannello
1
2
3
CHIAVE
PRIMARIA
Nome
Panel1
Panel2
Panel3
TABELLA: altre features
• Identity
• Default value
• Vincoli check
• Indici Univoci
• Valori Nulli e campi nullabili
• Convenzione: i nomi tabella iniziano con «tab»
Un po’ di pratica
• Accediamo a SQL server per creare una tabella per i
pannelli
(Usando SSMS)
Interfaccia di creazione tabella
Ultime info su SSMS
• Gli oggetti non si aggiornano da soli in visualizzazione
• Refresh
• Ctrl-shift R
• Context menu
• Inserimento dei dati
in tabella manualmente
TABELLA: relazioni tra tabelle
• Si chiama «relazionale» per qualche motivo
• Relazioni tra entità
• Integrità referenziale enforced da DB (il db impedisce che nella
tabella dei consumi esista mai una riga «orfana»)
idPannello
Nome
1 Panel1
2 Panel2
3 Panel3
idPannello Data
Energia
2 01/01/2013
100
3 01/01/2013
200
4 01/01/2013
250
4 01/02/2013
10
5 01/01/2013
40
5 01/02/2013
5
Il diagramma database
• Metodo facilitato di creazione
• Permette di tenere sotto controllo in maniera grafica le
relazioni
• Usato per separare parti diverse di un progetto complesso
Esempio di semplice diagramma…
Torniamo alla nostra realtà…
• PANNELLI (3 pannelli piccoli e uno grande)
• GRUPPI (divisi in due zone)
• ENERGIA PRODOTTA (che producono energia ad ogni
ora)
Progettazione di una base dati: STEPS
• Individuazione delle entità
• (tipicamente ogni entità avrà la sua tabella)
• Individuazione delle relazioni
• Alcune tabelle saranno collegate ad altre in maniera naturale
• Produzione del diagramma
Esempio: dati di sistema fotovoltaico
• Dati di funzionamento (energia prodotta ogni quarto d’ora)
• Configurazioni (quanti e quali pannelli ho?)
• Dati di log (listato diagnostico)
REGOLE DI PROGETTAZIONE
• Buonsenso!
• Ogni tabella mappa un’entità (o una relazione)
• Deve esistere sempre una chiave primaria
• Evitare dati non atomici (concatenazione di dati nello
stesso campo)
• Mai lo stesso dato contemporaneamente in due posti
diversi!
• Mai perdere informazioni
• Evitare che vengano inserite porcherie
• Forme normali
TABELLE: alcuni consigli
• Usare il tipo di dato più corretto per ogni campo ma
pensando con lungimiranza
• Impedire l’inserimento di dati scorretti
• Se qualcosa può andare storto LO FARA’
• ES: Codici fiscali
• Campi di testo libero a Varchar(max)
• Vedi la legge di murphy sopra
ESERCITAZIONE
• Che tipo di dato è bene usare per :
• Per la temperatura del corpo umano? Perché?
• Per un numero civico? Perché?
• Per la potenza istantanea di un impianto? Perché?
• Che vincoli mettereste sui dati di cui sopra?
• Progettare un SEMPLICE database per gestire un parco
fotovoltaico (usando il diagramma)
• Entità: pannello, energia prodotta ogni quarto d’ora da ciascun
pannello, raggruppamento di pannelli in aree.
Esercitazione: data entry
• Una volta creata la base dati
• Creare 4 pannelli
• Creare due zone (una con tre pannelli l’altra con uno)
• Inserire dati di energia prodotta per tutti i giorni di Gennaio 2013
per tutti e 4 i pannelli
• Possibile utilizzo di excel per il data entry
Progettazione di una base dati
• PROGETTARE UNA BASE DATI È UN’ATTIVITÀ SOLO
APPARENTEMENTE BANALE
• MOLTI PERICOLI NASCOSTI
• FARE MODIFICHE IN CORSO D’OPERA PUÒ ESSERE
DISPENDIOSO
• MEGLIO PROGETTARE BENE DALL’INIZIO
• Chiara definizione delle entità
• Buone naming conventions (prefissi, camel-case)
APPROFONDIMENTI
• Indici e Considerazioni di performances
UTILIZZO
DI UNA BASE DATI
Azioni sulla base dati
• Lettura o selezione (SELECT)
• Scrittura o inserimento (INSERT)
• Modifica (UPDATE)
• Cancellazione (DELETE)
• QUERY
• Frase in pseudo inglese
• ES: seleziona <qualcosa> da una <tabella> quando <si verifica una
certa condizione>
SELECT
• La funzione più usata in assoluto
• Sintassi usata anche in altre funzionalità
• Ritorna un recordset
SELECT: sintassi
SELECT <lista campi>
FROM <tabella>
WHERE <condizione>
ORDER BY <lista campi ordinamento>
Es:
SELECT [idPannello]
,[Pannello]
,[Note]
FROM tabPannelli
Le Keyword in MAIUSCOLO per convenzione
SELECT : lista campi
IdPannello
Nome
Potenza
DataInstallazione
1
Pannello 1
3kW
1/1/2013
2
Pannello 2
2kW
1/1/2013
3
Pannello 3
2kW
1/3/2013
4
Pannello 4
null
1/3/2013
• SELECT Nome,Potenza as PotKWH FROM tabPannelli
Nome
PotKWH
Pannello 1
3kW
Pannello 2
2kW
Pannello 3
2kW
Pannello 4
null
SELECT: lista campi
• Asterisco= tutti i campi
• Es: select * from tabella
• Alias
• Es: SELECT nome as NomePannello from tabPannelli
• Sono possibili alcune operazioni in fase di select
(concatenazione di stringhe)
• ES: SELECT ‘il pannello ‘ + idpannello +’ è rotto’ as Anomalia
FROM tabPannelli
• 3 part naming convention
• Es: SELECT * FROM dbFotovoltaico.dbo.tabPannelli
• Parentesi quadre se campo contiene spazio
• ES: SELECT nome as [il mio nome] FROM tabPannelli
SELECT : condizioni
• WHERE <campo/valore><operatore><campo/valore>
• Es: WHERE idpannello=1
• WHERE IN (lista elementi)
• Es: WHERE idpannello IN (1,2,3)
• WHERE IN (query)
• Es: WHERE idpannello IN (select idpannello from tabPannelli
where nomepannello=‘pannello1’)
• WHERE LIKE
• Es: WHERE nome LIKE ‘Pannello%’
• Uso di valori testuali
• Padding
• SQL iniection
SELECT: condizioni
• Usabili tutti gli operatori di confronto (< , > , = , != , <>)
• Es: WHERE idPannello=1
• Altri operatori (LIKE, BETWEEN)
• Tutti i costrutti booleani (AND, OR, NOT)
• Usare sempre le parentesi
• Es:
SELECT *
FROM tabPannelli
WHERE idpannello=1
AND (nomepannello=‘Pannello1’ OR nomepannello=‘Pannello2’ )
SELECT: ordinamento
• La clausola ORDER BY specifica il criterio di ordinamento
• Es:
SELECT *
FROM tabPannelli
ORDER BY idPannello ASC
,NomePannello DESC
JOIN
Come collegare i dati di tabelle
distinte?
tabEnergia
tabPannelli
idPannello
Nome
1 Panel1
2 Panel2
3 Panel3
idPannello Data
Energia
2 01/01/2013
100
3 01/01/2013
200
4 01/01/2013
250
4 01/02/2013
10
5 01/01/2013
40
5 01/02/2013
5
JOIN (collegamento di più tabelle)
• INNER
idPannello
null
null
null
null
Nome
1 Panel1
2 Panel2
3 Panel3
null
null
null
null
idPannello Data
Energia
null
null
null
2 01/01/2013
100
3 01/01/2013
200
4 01/01/2013
250
4 01/02/2013
10
5 01/01/2013
40
5 01/02/2013
5
• È l’opzione più comune
• Vengono restituite solo le righe comuni a entrambe le tabelle
• Se in una delle tabelle non ho un match la riga «scompare»
• Possono essere restituite più righe delle due tabelle!
• (tipicamente è un errore)
JOIN
• LEFT
righe a sx
più righe a dx
che matchano
• RIGTH
idPannello
Nome
1 Panel1
2 Panel2
3 Panel3
null
null
null
null
idPannello Data
Energia
null
null
null
2 01/01/2013
100
3 01/01/2013
200
4 01/01/2013
250
4 01/02/2013
10
5 01/01/2013
40
5 01/02/2013
5
idPannell
o
Nome
1 Panel1
2 Panel2
3 Panel3
null
null
null
null
null
null
null
null
idPannello Data
Energia
null
null
null
2 ########
100
3 ########
200
4 ########
250
4 ########
10
5 ########
40
5 ########
5
null
null
null
null
è una left
con le tabelle scambiate
(da non usare per problemi di leggibilità)
JOIN
• FULL OUTER
idPannello
null
null
null
null
Nome
1 Panel1
2 Panel2
3 Panel3
null
null
null
null
idPannello Data
Energia
null
null
null
2 01/01/2013
100
3 01/01/2013
200
4 01/01/2013
250
4 01/02/2013
10
5 01/01/2013
40
5 01/02/2013
5
• CROSS
• Fa il cartesiano(tutte le combinazioni).
• Con le tabelle sopra sono 18 righe…
JOIN: sintassi
• SELECT <lista campi>
• FROM <tabella> as <Alias>
• INNER JOIN <tabella> as <Alias2>
• ON Alias1.campo = Alias2.campo
• Es:
• SELECT *
• FROM tabEnergia
• INNER JOIN tabPannelli
• ON tabEnergia.idPannello=tabPannelli.idPannello
ESERCITAZIONE:
• Mostrare la tabella consumi ma, al posto dell’idPannello
mostrare il nome del pannello
JOIN in cascata
• È possibile combinare più tabelle in una serie di join
successivi
• Es:
• SELECT *
• FROM tabEnergia
• INNER JOIN tabPannelli
• ON tabEnergia.idPannello=tabPannelli.idPannello
• INNER JOIN tabGruppi
• ON tabGruppi.idGruppo=tabPannelli.idGruppo
Best practices su SELECT e JOIN
• Attenzione ai cartesiani!
• Attenzione alle INNER su campi non chiave: potrebbero
«sparire righe» o uscire «righe in più»
• Ordinare le tabelle nella clausola di join a partire dalla più
informativa
• Usare solo left join e mai right join per facilità di lettura
• Formattazione delle query
AGGREGAZIONE E RAGGRUPPAMENTO
• Che succede se voglio sommare dei valori?
• Es: sapere quanto ha prodotto ogni pannello in un certo periodo?
Pannello
Pannello1
Pannello2
Pannello3
Energia Prodotta In Gennaio
1230
132
1244
• Ma io ho questo:
idPannello Data
Energia
2 01/01/2013
100
3 01/01/2013
200
4 01/01/2013
250
4 01/02/2013
10
5 01/01/2013
40
5 01/02/2013
5
AGGREGAZIONE E RAGGRUPPAMENTO
SELECT<lista campi>
<lista funzione di aggregazione(Campo)>
FROM <tabella>
WHERE <condizione>
HAVING <condizione su campi raggruppati>
Es:
SELECT tabPannelli.Pannello
, SUM(tabEnergiav2.Energia) AS EnergiaTot
FROM
tabEnergiav2
INNER JOIN tabPannelli
ON tabEnergiav2.idPannello = tabPannelli.idPannello
GROUP BY tabPannelli.idPannello
, tabPannelli.Pannello
ESERCITAZIONE
• Mostrare in una lista tutti i pannelli e, per ognuno
mostrare l’energia prodotta (sia che il pannello abbia
prodotto, sia no!)
ESERCITAZIONE
• Mostrare la quantità di energia prodotta da ogni pannello
(specificando il nome pannelloe non l’ID!)
• In totale
• Raggruppata per giorno
• Per la prima settimana di gennaio 2013
• Raggruppata per mese e salvare la query
• Raggruppata per settimana(!) (non si può fare con la base dati che
abbiamo: perché? Come si può fare?)
• Mostrare in una lista tutti i pannelli e, per ognuno mostrare l’energia
prodotta (sia che il pannello abbia prodotto, sia no!)
INSERT
• INSERT VALUES
INSERT INTO tabella
(lista campi)
VALUES
(lista valori)
• INSERT RESULTS
INSERT INTO tabella
(lista campi)
SELECT <lista campi>
FROM tabella
WHERE <condizione>
UPDATE
• Aggiornamento di tabelle
• Sintassi
• UPDATE <tabella>
• SET campo=<Valore>
• FROM <tabella>
• Es:
• UPDATE tabEnergia
• SET energia=0
• FROM tabEnergia
• WHERE (Ora >23 OR Ora<5)
DELETE
• Sintassi:
• DELETE FROM tabella WHERE idpannello=1
• In caso di join
DELETE FROM tabella
FROM tabella
INNER JOIN tabella2
ON tabella.id=tabella2.id
WHERE tabella2.Nome=‘Pannello2’
Attenzione in caso di relazioni con cascade!
ESERCITAZIONE
• Creare una tabella con i giorni dell’anno e alimentarla
• Eliminare tutti i dati di energia prodotta
• Inserire nuovi dati di consumo per tutto il 2013 (con QTA
casuali da 50 a 100 di giorno, 0 di notte) per i pannelli
1,2,4
• A marzo 2013 simulare un malfunzionamento del pannello
2 (aggiornando i dati con NULL in tabella)
• Lanciare la query salvata nella precedente esercitazione
per visualizzare i dati di ogni pannello per ogni mese
NOZIONI AVANZATE
UNA PREMESSA
• DATA ENCAPSULATION
• INFORMATION HIDING
• LOGICA N-TIERED
• Garanzie di successo del progetto
• Divisione efficiente in tasks
• Manutenibilità
VISTE
• Sono in pratica delle query di tipo SELECT nel DB
• Calcolate «on the fly»
• Piccole differenze
• tutti i campi devono essere univoci
• Ogni campo deve avere un nome
• Possono essere create con designer
• Ma fa un po’ schifo
VISTE: sintassi
• CREATE VIEW <nomevista>
• AS
• <query>
ES:
CREATE VIEV vwPannelli
AS
SELECT * FROM tabpannelli
VISTE: alcune considerazioni
• Vengono calcolate ogni volta
• Possibili lentezze
• Se varia un campo la modifica non è a cascata
• Utili per comunicare con l’esterno
• Nascondono complessità implementative (information hiding)
• Utenti
• Sistemi di reportistica
• Possono essere richiamate nelle query in maniera
semplice e comoda
STORED PROCEDURES
• Esigenze di data encapsulation e information hiding
• Molto potenti
• A differenza delle viste
• Possono eseguire azioni
• Possono non ritornare un recordset (dati tabellari)
• Possono usare step intermedi di calcolo (es: temp tables)
• Ammettono variabili in ingresso e uscita
• Svantaggi
• Non posso fare join sul risultato di una store
STORED PROCEDURES: sintassi
• CREATE PROCEDURE <nome>
• (
• <Parametri>
)
• AS
• BEGIN
• <istruzioni>
• END
• CREATE PROCEDURE spMostraEnergiaPerPannello
• (
• @idPannello as int
• )
• AS
• BEGIN
• Select sum(energia)
• From tabEnergiaProdotta
• WHERE idpannello=@idPannello
• END
STORED PROCEDURE: chiamata
• Sintassi:
• EXEC spVisualizzaPannello 1
•
• OPPURE
• EXEC spVisualizzaPannello @idPannello=1
ESERCITAZIONE
• Creare una procedura che cancelli la tabella dell’energia
prodotta (spResetData)
• Creare una procedura che chiamata con parametro
IdPannello mostri l’energia prodotta da quel pannello
SINTASSI TSQL: una piccola toolbox
• Variabili
• Strutture di controllo
• IF
• Cicli
• FOR
• WHILE
• Cursori
• Da vedere poi…
SINTASSI TSQL: VARIABILI
• Iniziano con @
• Vanno dichiarate
• DECLARE @intIdPannello as int=10
• Se non inizializzate sono NULL!
• DECLARE @intIdPannello as int è NULLA
• Si impostano con istruzione SET
• SET @intIdPannello =10
SINTASSI TSQL: Strutture condizionali
• IF (<condizione>)
• BEGIN
• <azione>
• END
• ELSE
• BEGIN
• <azione>
• END
• ES:
• IF (@idPannello=1)
• BEGIN
• DELETE FROM tabPannello WHERE idPannello=@idPannello
• END
SINTASSI SQL
• CONDIZIONE SU RISULTATO QUERY
• IF EXISTS(<query>)
• BEGIN
• <azioni>
• END
• ELSE
• BEGIN
• <altre azioni>
• END
SINTASSI TSQL: altro
• CASE WHEN <condizione> THEN <espressione>
WHEN <condizione> THEN <espressione>
ELSE
<espressione>
END
• CICLI
• FOR
• WHILE
ESERCITAZIONE
• Allo scopo di generare dei dati da analizzare:
• Creare una procedura sp_generaDatiDEmoPannello che,
dato un idpannello
• Elimini dalla tabella energia prodotta tutti i dati di quel pannello
• Generi per ogni giorno dell’anno 2013 una riga di misurazione con
una quantità randomica da 50 a 100 ( per tutte le ore dalle 8 alle
19) solo alle ore 12
• Cercare su google la funzione RAND per la funzione random
• Se il pannello è il 3 corregga il dato così prodotto simulando un
malfunzionamento per tutto marzo e aprile2013(tutte le qta
andranno a NULL)
ESERCITAZIONE
• Creare una procedura spGeneraDatiDemo che chiami la
procedura precedente per ogni pannello esistente in
tabella
• La soluzione adottata come reagisce al fatto che io aggiungo un
pannello? Si adatta? Cosa mi servirebbe?
• Eseguirla e Verificare usando la vista dell’energia prodotta
i risultati ottenuti
CASE STUDY: import massivo dati
Progettazione di una Procedura di
controllo per l’import dati.
• Una stored proc (parametro=idtrasmissione)
• Che la trasmissione sia arrivata(che sia arrivato almeno un dato)
• Il pannello esiste?(lo facciamo dopo)
• La qta non negativa
• Qta inferiore a soglia 500
• La data della misurazione deve essere univoca
• e non già presente nel database(per pannello)
• Chiamare la store:spVerificaTrasmissione (@idTrasmissione)
• Alla fine aggiornare il campo stato con 1 se successo, 0 se fallimento
• DECLARE @cnt AS int
• SELECT @cnt=count(*) FROM tabella
• (approfondire problema della quantizzazione temporale)
ALTRE FUNZIONALITA’
• FUNZIONI
• Richiamabili da query
• Solitamente non usate: problematiche di performances
• TABLE FUNCTIONS
• «viste» parametriche
• Anche qui problemi di performances