APPLICAZIONI DELLE
BASI DI DATI
APPLICAZIONI TRADIZIONALI
APPLICAZIONI INTERNET
SQL EMBEDDED
SQL nel codice applicativo
!
I comandi SQL possono essere chiamati dall’interno
di un programma in un linguaggio ospite (ad
esempio C++ o Java)
!
!
!
I comandi SQL possono far riferimento a variabili
dell’ospite (incluse variabili speciali usate per restituire uno
status)
Deve essere incluso un comando per connettersi alla base
di dati
Due principali approcci all’integrazione
!
!
Incorporare l’SQL nel linguaggio ospite (SQL incapsulato,
ad es., SQLJ)
Creare una speciale API per chiamare i comandi SQL (ad
es., JDBC)
Giorgio Giacinto 2010
Database
3
SQL incapsulato (embedded)
!
Approccio: incapsulare l’SQL nel linguaggio ospite.
!
!
!
Un preprocessore converte i comandi SQL in speciali
chiamate all’API
Successivamente un normale compilatore viene usato per
compilare il codice
Costrutti del linguaggio
!
!
!
connessione a una base di dati
EXEC SQL CONNECT
Dichiarazione di variabili
EXEC SQL BEGIN (END) DECLARE SECTION
Comandi
EXEC SQL comando
Giorgio Giacinto 2010
Database
4
SQL incapsulato: variabili
EXEC SQL BEGIN DECLARE SECTION
Char c_vnome[20];
Long c_vid;
Short c_esperienza;
Float c_età;
EXEC SQL END DECLARE SECTION
!
Inserimento di una riga
EXEC SQL
INSERT INTO Velisti
VALUES(:c_vnome,:c_vid,:c_esperienza,:c_età);
Giorgio Giacinto 2010
Database
5
SQL incapsulato: variabili
errore
!
Due speciali variabili “errore”
!
!
SQLCODE (long)
se negativa si è verificato un errore
SQLSTATE char[6]
codici predefiniti per errori comuni
Giorgio Giacinto 2010
Database
6
SQL nel codice applicativo
Cursori
Disadattamento di impedenza
! Le relazioni SQL sono (multi-)insiemi di
record senza un numero di record fissato a
priori. Nessuna struttura di questo tipo
esiste tradizionalmente in linguaggi di
programmazione procedurali come il C++
! SQL supporta un meccanismo chiamato
cursore per gestire questa situazione
Giorgio Giacinto 2010
Database
7
SQL incapsulato
SELECT senza cursori
EXEC SQL SELECT V.vnome,V.età
INTO :c_vnome, :c_età
FROM Velisti V
WHERE V.vid = :c_vid;
Questa SELECT restituisce al più una sola
tupla
•
•
non è necessario definire un cursore
Giorgio Giacinto 2010
Database
8
Cursori
!
!
Si può dichiarare un cursore su una relazione o un
comando di interrogazione
Si può aprire un cursore, e ripetutamente prelevare
una tupla, poi muovere il cursore fino a quando tutte
le tuple siano state lette.
!
!
!
Si può usare ORDER BY nelle interrogazioni cui si accede
tramite cursore, per controllare l’ordine in cui le tuple sono
restituite
! I campi nella clausola ORDER BY devono apparire anche
nella clausola SELECT
ORDER BYè permessa solo nel contesto di un cursore
Si può anche modificare/cancellare la tupla puntata
dal cursore
Giorgio Giacinto 2010
Database
9
Cursori che leggono
in ordine alfabetico i nomi dei velisti che hanno
prenotato una barca rossa
EXEC SQL DECLARE vinfo CURSOR FOR
SELECT V.vnome
FROM Velisti V, Barche B, Prenota P
WHERE V.vid = P.vid AND P.bid = B.bid
AND B.colore = ‘rosso’
ORDER BY V.vnome
Giorgio Giacinto 2010
Database
10
Incapsulare l’SQL in C: un
esempio
char SQLSTATE[6];
EXEC SQL BEGIN DECLARE SECTION
char c_vnome[20]; short c_minesperienza;
float c_età;
EXEC SQL END DECLARE SECTION
c_minesperienza = random();
EXEC SQL DECLARE vinfo CURSOR FOR
SELECT V.vnome, V.età FROM Velisti V
WHERE V.esperienza > :c_minesperienza
ORDER BY V.vnome;
EXEC SQL OPEN vinfo;
do {
EXEC SQL FETCH vinfo INTO :c_vnome, :v_età;
printf(“%s ha %d anni\n”, c_vnome, c_età);
} WHILE (SQLSTATE != ‘02000’);
EXEC SQL CLOSE vinfo;
Giorgio Giacinto 2010
Database
11
Proprietà dei cursori
!
Un cursore può essere dichiarato
!
!
!
SCROLL CURSOR
!
!
Flessibilità nel posizionamento di FETCH
INSENSITIVE
!
!
Sola lettura
Aggiornabile (per usare UPDATE e DELETE)
Il cursore è come se agisse su una copia privata della
relazione risultato
WITH HOLD
!
Il cursore non viene chiuso al termine di una transazione
Giorgio Giacinto 2010
Database
12
SQL dinamico
!
!
Le stringhe di interrogazione SQL non sono sempre
note al momento della compilazione (ad esempio
fogli di lavoro o frontend grafici per il DBMS)
Il linguaggio SQL consente di costruire comandi
SQL al volo
Esempio:
char c_stringasql[]=
{“DELETE FROM Velisti WHERE esperienza > 5”};
EXEC SQL PREPARE pronti FROM :c_stringasql;
EXEC SQL EXECUTE pronti;
Giorgio Giacinto 2010
Database
13
API per basi di dati
alternative all’incapsulamento
!
Piuttosto che modificare il compilatore, si possono
aggiungere librerie con chiamate alla base di dati
(API)
!
!
!
!
Speciale interfaccia standardizzata: procedure/oggetti
Si passano le stringhe SQL dal linguaggio, si
presentano gli insiemi risultato in maniera
comprensibile
JDBC della Sun: API Java
Generalmente neutre rispetto al DBMS
!
!
Un “driver” rileva le chiamate e le traduce in codice
specifico per il DBMS
La base di dati può essere distribuita
Giorgio Giacinto 2010
Database
14
Uso di Call Level Interface
(CLI)
!
I DBMS sono eseguiti come processi server
!
!
Processi attivi che offrono dei servizi a richiesta
Per fruire dei servizi occorre connettersi al DBMS
!
Interfacce fra DBMS e altri programmi
Applicazione
Interfaccia
(ADO, RDO, …)
Driver
(DBD,ODBC,…)
Database
(Oracle,MySQL,…)
Giorgio Giacinto 2010
Database
STORED PROCEDURE
15
Stored procedure
!
Cos’è una stored procedure
!
!
!
Programma eseguito tramite un singolo comando
SQL
Eseguito nello spazio del processo sul server
Vantaggi
!
!
!
Può incapsulare la logica dell’applicazione
rimanendo al contempo “vicino” ai dati
Riutilizzo della logica dell’applicazione da parte di
utenti diversi
Evita la lettura dei record tupla-per-tupla tramite i
cursori
Giorgio Giacinto 2010
Database
17
Stored procedure: esempi
CREATE PROCEDURE MostraNumPrenotazione
SELECT V.vid, V.vnome, COUNT(*)
FROM Velisti V, Prenota P
WHERE V.vid = P.vid
GROUP BY V.vid, V.vnome
Le stored procedure possono avere parametri
! Tre modi differenti: IN, OUT, INOUT
CREATE PROCEDURE AumentaEsperienza(
IN velista_vid INTEGER, IN aumento INTEGER)
UPDATE Velisti
SET esperienza = esperienza + aumento
WHERE vid = velista_vid
Giorgio Giacinto 2010
Database
18
Stored procedure: esempi (segue)
Le stored procedure non devono
necessariamente essere scritte in SQL
CREATE PROCEDURE VelistiTop(IN num INTEGER)
LANGUAGE JAVA
EXTERNAL NAME ”file://c:/storedProcs/rank.jar”
Giorgio Giacinto 2010
Database
19
Chiamare le stored procedure
EXEC SQL BEGIN DECLARE SECTION
int vid;
int esperienza;
EXEC SQL END DECLARE SECTION
// ora aumenta l’esperienza di questo velista
EXEC CALL AumentaEsperienza(:vid, :esperienza);
Giorgio Giacinto 2010
Database
20
SQL/PSM
La maggior parte dei DBMS consente agli utenti di
scrivere stored procedure in un linguaggio semplice e
general-purpose (vicino all’SQL) → lo standard SQL/PSM
ne è un esempio
Dichiarare una stored procedure:
CREATE PROCEDURE nome(p1, p2,... pn)
Dichiarazioni di variabili locali
Codice della procedura;
Dichiarare una funzione:
CREATE FUNCTION nome(p1, ..., pn) RETURNS
TipoDatoSQL
Dichiarazione di variabili locali
Codice della funzione;
Giorgio Giacinto 2010
Database
21
Principali costrutti
SQL/PSM
CREATE FUNCTION valuta Velista
(IN velistaID INTEGER)
RETURNS INTEGER
DECLARE esperienza INTEGER
DECLARE numRis INTEGER
SET numRis = (SELECT COUNT(*)
FROM Prenota P
WHERE P.vid = velistaID)
IF (numRis > 10) then esperienza = 1;
ELSE esperienza = 0;
END IF
RETURN esperienza;
Giorgio Giacinto 2010
Database
22
APPLICAZIONI VERTICALI
Sistemi informativi e basi di
dati
!
Le basi di dati sono il componente di base di
un sistema informativo
!
!
Nel corso dei decenni sono stati sviluppati
diversi applicativi verticali
!
!
Gestiscono la memorizzazione e il recupero
efficiente e efficace dei dati
Orientati a applicazioni aziendali specifiche
Oggi molti produttori di DBMS hanno
acquisito società specializzate nella
produzione di applicazioni verticali
Giorgio Giacinto 2010
Database
24
Processi Aziendali
!
!
!
!
HR
Human Resources Management
Finance Management
Procurement
CRM
Customer Relationship Management
Giorgio Giacinto 2010
Database
25
Gestione della produzione
!
!
!
ERP
Enterprise Resource Planning
SCM
Supply Chain Management
PLM
Product Lifecycle Management
Giorgio Giacinto 2010
Database
26
APPLICAZIONI INTERNET
Basi di Dati e Reti
!
La diffusione del protocollo http per lo
scambio di dati ha modificato tutte le
applicazioni delle basi di dati
!
!
Non più client dedicati, ma browser web per
accedere ai processi aziendali
Internet ha permesso la nascita del
cosiddetto commercio elettronico
!
Richiede accessi in lettura e scrittura a diverse
basi di dati
!
!
Prodotti del venditore
Mediatore per l’acquisto
Giorgio Giacinto 2010
Database
28
Internet e Basi di Dati
!
Le stesse informazioni messe a disposizione
sui siti Internet sono sempre più spesso
organizzate come basi di dati
!
!
Dall’HTML a XML
Questo approccio semplifica le operazioni di
inserimento, aggiornamento, cancellazione di
dati
Giorgio Giacinto 2010
Database
29
Web-service
!
E’ una applicazione che fornisce un servizio ben
definito
!
!
Un insieme di procedure richiamabili in remoto tramite
Internet
Le applicazioni possono essere scritte in linguaggi
diversi
!
Ma scambiano informazioni attraverso formati standard XML
SOAP: standard per chiamate basate su XML di
servizi remoti
Argomenti trattati nel corso TARI
!
Giorgio Giacinto 2010
Database
30
Componenti dei sistemi
“data-intensive”
!
Tre tipi separati di funzionalità
!
!
!
!
!
gestione dei dati
logica di applicazione
presentazione
L’architettura del sistema determina se queste tre
componenti risiedono su un singolo sistema (tier)
oppure se sono distribuite su diversi tier
Evoluzione delle architetture dipendente da
!
!
Evoluzione tecnologia
Riduzione costi (diffusione PC, ecc.)
Giorgio Giacinto 2010
31
Database
Architettura a livello singolo
!
Tutte le funzionalità sono
combinate in un singolo tier,
generalmente un mainframe
!
!
Client
Vantaggi
!
!
Accesso utente tramite
terminali “non intelligenti”
Logica dell’Applicazione
facilità di manutenzione e
amministrazione
Svantaggi
!
!
Gli utenti si aspettano
interfacce di tipo grafico
Il calcolo centralizzato di
tutte le interfacce grafiche è
troppo costoso per un
singolo sistema
Giorgio Giacinto 2010
DBMS
Database
32
Architetture client-server
thin client
!
!
Il client implementa solo l’interfaccia utente
grafica
Il server implementa la logica dell’applicazione
e la gestione dei dati
Client
Logica dell’Applicazione
Rete
DBMS
Giorgio Giacinto 2010
Client
33
Database
Architetture client-server
thick client
!
!
Il client implementa sia
l’interfaccia grafica che (parte
de) la logica dell’applicazione
Il server implementa la
gestione dei dati
Client
Logica dell’Applicazione
DBMS
Rete
Client
Logica dell’Applicazione
Giorgio Giacinto 2010
Database
34
Architetture client-server
(segue)
!
Svantaggi dei thick client
!
!
!
Nessun luogo centralizzato per aggiornare la logica
dell’applicazione
Problemi di sicurezza: il server deve fidarsi dei client
! Il controllo di accesso e l’autenticazione devono essere
gestiti dal server
! I client devono lasciare la base di dati del server in uno
stato consistente
! Una possibilità: incapsulare tutti gli accessi alla base di
dati in stored procedure
Non scalabile a più di un centinaio di client
! Grossi trasferimenti di dati tra server e client
! Più di un server crea un problema:
x client, y server: x*y connessioni
Giorgio Giacinto 2010
Database
35
L’architettura a tre livelli
Livello di presentazione
Programma client
(browser web)
Livello intermedio
Application Server
Livello di gestione dati
Giorgio Giacinto 2010
Sistema di base di dati
Database
36
I tre livelli
!
Livello di presentazione
!
!
!
Livello intermedio
!
!
!
Interfaccia primaria con l’utente (moduli HTML…)
Deve adattarsi a diversi dispositivi di visualizzazione (PC,
PDA, telefoni cellulari, accesso vocale?)
Implementa la logica dell’applicazione (implementa azioni
complesse, mantiene lo stato tra diversi passi di un flusso
di lavoro)
Accede a diversi sistemi di gestione dei dati
Livello di gestione dei dati
!
Uno o più sistemi standard per la gestione di basi di dati
Giorgio Giacinto 2010
37
Database
Tecnologie
Programma client
(Browser web )
HTML
Javascript
XSLT
Application Server
(Tomcat, Apache)
JSP
Servlets
Cookies
CGI
Sistema di basi di dati
(MySQL, ORACLE)
Giorgio Giacinto 2010
Database
XML
Stored Procedures
38
Archietture client-server
three tier
Client
DBMS
Rete
Logica
dell’Applicazione
Rete
Client
Giorgio Giacinto 2010
Database
39
Vantaggi architetture a tre
livelli
!
!
!
!
!
Sistemi eterogenei
Thin client
Accesso integrato ai dati
Scalabilità rispetto al numero di client
Benefici nello sviluppo del software
!
Interazioni fra livelli attraverso API standardizzate
Giorgio Giacinto 2010
Database
40
Esempio 1: prenotazioni aeree
!
!
!
Costruire un sistema per prenotazioni aeree
Cosa viene fatto dai vari livelli?
Sistema di basi di dati
!
!
Application server
!
!
Informazioni sulle aerolinee, posti disponibili, informazioni
sui clienti, etc.
Logica per effettuare le prenotazioni, cancellare le
prenotazioni, aggiungere nuove aerolinee, etc.
Programma client
!
Log in dei vari utenti, visualizzazione di moduli e output in
forma leggibile
Giorgio Giacinto 2010
Database
41
Esempio 2: iscrizione a corsi
!
!
Costruire un sistema usando il quale degli studenti
possono iscriversi a dei corsi
Sistema di base di dati
!
!
Application server
!
!
Informazioni sugli studenti, informazioni sui corsi,
informazioni sui docenti, disponibilità dei corsi, pre-requisiti,
etc.
Logica per modificare un corso, cancellare un corso, creare
un nuovo corso, etc.
Programma client
!
Login dei vari utenti (studenti, personale, professori),
visualizzazione di moduli e output in forma leggibile
Giorgio Giacinto 2010
Database
42