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

JDBC/ODBC

bridge

Java Application

JDBC driver manager

Architettura JDBC

JDBC Driver

(DBMS Specific)

JDBC middleware

(various DBMS)

DBMS – Data Source

JDBC/native

bridge

Native driver

(DBMS specific)ODBC Driver

Applicazione Java connDB (1)

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();

import java.sql.*;

Chiudere/Rilasciare la connessione e lo statement

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

con.close();

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");}

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

External

Applications

Legacy Systems

Databases

Thin

Client

Rich

Client

Architetture 3-tier

L’architettura a tre livelli

Sistema di base di dati

Application Server

Programma client (browser web)Livello di presentazione

Livello intermedio

Livello di gestione 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, pre-requisiti, 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

DBMS

(MySQL, Oracle, DB2)

Application Server

(Tomcat, Apache)

Programma client

(Browser web )

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