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 Programma client (browser web) Livello intermedio Application Server Livello di gestione dati 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) HTML Javascript XSLT JSP, Servlets, PHP CGI, Cookies DBMS (MySQL, Oracle, DB2) 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