Lezione - Università degli Studi di Roma "Tor Vergata"

Corso di Laboratorio di
Applicazioni Informatiche
Progetti di Basi di Dati
a.a. 2008-9
Outline
•
•
•
•
•
•
Obbiettivi
Tecnologie
Struttura di un progetto
Esempi
Deadlines
Conlusioni
Obbiettivi
• Applicare le conoscenze sviluppate nel corso di
Basi di Dati a problemi di dimensione realistica
• Sviluppare competenze verticali nell’ambito di
alcune tecnologie
• Acquisire prassi tipiche nell’ambito della
ingegneria dei sistemi basati sulla tecnologia dei
DBMS
• Sviluppare le proprie attitudini relative al
teamwork
Tecnologie
• DBMS
– Progettazione ER
– Modelli logici (relazionali) dei dati
– SQL
• Three tier C/S architecture
– From Java stand-alone applications to C/S processes
– Web-based applications
• Server-side
• Client-side
• Data-side
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
Architettura a livello singolo
Tutte le funzionalità sono combinate in un singolo tier,
generalmente un mainframe
 Accesso utente tramite terminali non intelligenti
Vantaggi :
 facilità di manutenzione e amministrazione
Svantaggi :
– Oggi gli utenti si aspettano interfacce utente di tipo grafico
– Il calcolo centralizzato di tutte le interfacce grafiche è troppo
costoso per un singolo sistema
Architettura JDBC




Applicazione: Inizia e termina la connessione
ad un data source
Driver Manager :si occupa di caricare i
driver JDBC e di passare le chiamate JDBC
dell’applicazione al driver specifico
Driver : Stabilisce la connessione con il data
source
Data Source : processa i comandi
provenienti dal driver e restituisce i dati
richiesti
Architettura JDBC
Java Application
JDBC driver manager
JDBC/ODBC
JDBC/native
JDBC middleware
JDBC Driver
bridge
bridge
(various DBMS)
(DBMS Specific)
ODBC Driver
Native driver
(DBMS specific)
DBMS – Data Source
Applicazione Java connDB (1)
import java.sql.*;
Caricare il driver JDBC:
• Class.forName(“oracle/jdbc.driver.Oracledriver”);
• -D jdbc.drivers=oracle/jdbc.driver2
Definire l’URL della connessione al Data Base:
• url=“jdbc:oracle:www.uniroma2.it:308”;
"jdbc:connectionType://host:port/database"
Stabilire la connessione:
String user = "nomeutente"; password = "password";
Connection con = DriverManager.getConnection(url, user, password);
Creare un oggetto statement.
Statement statement =connection.createStatement();
Applicazione Java connDB (2)
Eseguire una query : (ad es.
INSERT,SELECT,DELETE)
String query = "SELECT col1, col2, col3 FROM table";
ResultSet results = statement.executeQuery(query);
Analizzare/Calcolare i risultati:analisi del risultato
contenuto nella classe ResultSet
while (results.next()) {
String a = results.getString(1);
Integer eta = results.getInt(2);
System.out.print(“NOME= " + a);
System.out.print("ETA’= " + eta.toString());
System.out.print("\n");}
Chiudere/Rilasciare la connessione e lo statement
con.close();
statement.close();
Architetture client-server
• Divisione del lavoro: thin client
– Il client implementa solo l’interfaccia utente grafica
– Il server implementa la logica dell’applicazione e la
gestione dei dati
• Divisione del lavoro: thick client
– Il client implementa sia l’interfaccia grafica che la
logica dell’applicazione
– Il server implementa la gestione dei dati
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
Architetture 3-tier
Databases
Legacy Systems
External
Applications
Thin
Client
Rich
Client
L’architettura a tre livelli
Livello di presentazione
Livello intermedio
Livello di gestione dati
Programma client (browser web)
Application Server
Sistema di base di dati
I tre livelli
Livello di presentazione
– Interfaccia primaria con l’utente
– Deve adattarsi a diversi dispositivi di visualizzazione
(PC, PDA, telefoni cellulari, accesso vocale?)
Livello intermedio
– 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
Esempio 1: prenotazioni aeree
• Costruire un sistema per prenotazioni aeree
• Cosa viene fatto dai vari livelli?
• Sistema di basi di dati
– Informazioni sulle aerolinee, posti disponibili,
informazioni sui clienti, etc.
• Application server
– Logica per fare le prenotazioni, cancellare le
prenotazioni, aggiungere nuove aerolinee, etc.
• Programma client
– Log in dei vari utenti, visualizzazione di moduli e
output in forma leggibile
Esempio 2: iscrizione a corsi
• Costruire un sistema usando il quale degli
studenti possono iscriversi a dei corsi
• Sistema di base di dati
– Informazioni sugli studenti, informazioni sui corsi,
informazioni sui docenti, disponibilità dei corsi, prerequisiti, etc.
• Application server
– 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
Tecnologie
Programma client
(Browser web )
Application Server
(Tomcat, Apache)
DBMS
(MySQL, Oracle, DB2)
HTML
Javascript
XSLT
JSP, Servlets,
PHP
CGI, Cookies
SQL,
Stored Procedures,
XML
Struttura di un progetto
• Studio del dominio e sviluppo del documento di
requisiti
• Progettazione
– Concettuale
– Logica
•
•
•
•
Sviluppo del DB
Sviluppo del server (logica applicativa)
Sviluppo del client
Validazione e Documentazione
Esempi: Calcio e Notizie
• Una agenzia di stampa specializzata in servizi sportivi
decide di realizzare un prodotto per la registrazione dei
dati tecnici di un incontro di calcio. Alcuni giornalisti
sportivi in tempo reale inseriscono dati su punizioni,
passaggi, attacchi e ammonizioni/espulsioni di un
incontro. Il parallelismo e la concorrenza dei dati
richiedono l'uso di un modello dei dati relazionali e la
progettazione di un database dedicato. Una componente
generale descriverà le squadre ed i giocatori dei diversi
team, mentre una seconda componente sarà utilizzata
per uno specifico incontro.
Calcio e Notizie (2)
• Modellare la nozione di campionato di calcio e di
incontro
– In un incontro saranno registrati i goal, i dati
disciplinari ed alcune notizie tattiche. Per la
registrazione i tecnici possono contare su una
applicazione (a menu) che permette l'inserimento dei
dati puntuali e l'aggiornamento in tempo reale. Ogni
inserimento si basa su una serie di scelte dai menu
corrispondenti, cosi' da minimizzare i tempi di
inserimento.
– A fine partita sara' possibile derivare l'insieme delle
statistiche per le due squadre, per i singoli giocatori
(per es. insieme dei falli fatti o subiti)
Calcio e Notizie: Applicazione
• Garantire la contabilizzazione di ogni evento;
• Segnalare al servizio dati generali relativi ad un
evento (per esempio se una squadra ha
totalizzato più di un certo numero di
ammonizioni)
• Creazione del menu finale (o tra primo e
secondo tempo) con la rassegna dei dati tecnici
(ad es. falli e ammoniti) e tattici (ad es. numero
di attacchi dal centro dalla destra o dalla
sinistra).
Calcio e Notizie: Componente
procedurale
• Gestione a video della interazione del giornalista
sportivo per l'inserimento in tempo reale dei dati
di gioco;
• Generazione del menu di sintesi tecnico-tattica
al termine della partita;
• Aggiornamento della componente generale del
campionato con i dati sintetici (ad es.
percentuali totali della partita) relativi
all'incontro effettuato con una successivo report
(per ogni squadra) delle partite effettuate e dei
dati accumulati durante il campionato.
Osservazioni e Scadenze
• L’esame avrà il voto in trentesimi
• L’iscrizione ad un'area progettuale è obbligatoria
• 27 Maggio 2009: deadline per inviare esplicita
mail al docente di riferimento
• ORARI di Ricevimento settimanali (4 ore) in
ufficio o per email
• Max dimensione di un gruppo (BDD: 3 persone)
• Deadline per la consegna del progetto: 10 Luglio
2009
• Validità del progetto: a.a. 2008/9
• Date ulteriori di discussione del progetto (una
per ogni appello previsto dalla Facoltà)
Summary
• Perché scegliere il progetto LAI di BdD:
– Per imparare ad usare le tecnologie DBMS
– Per sviluppare un sistema software completo
per la prima volta
– Per imparare a lavorare in team
• Scadenze
– Registrazione al progetto: 27 Maggio 2009
– Consegna progetto: 10 Luglio 2009