Lez Appl. per basi di dati

114 Pages·2017·2.1 MB·Italian

by  Emanuele Galli

Sviluppo di applicazioni per basi di dati

Ing. Emanuele Galli

[email protected]
Università degli studi di Roma Tor Vergata
Department of Civil Engineering and Computer Science Engineering
1
Applicazione per basi di dati
• Quattro parti:
1. Gestione dei dati (transazioni, gestione
dei dati persistenti, controllo accessi)
2. Business rules (vincoli di integrità e
dati derivati)
3. Logica applicativa
4. Interfaccia utente
• Diversi tipi di architettura per risolvere lo
stesso problema
2
Architetture software
• Architettura client server
3
Architetture software
• Architettura thin-client server
4
Architetture software
• Three tier architecture
Presentation tier
Business Logic tier
Data tier
5
Design Patterns
• DP Model-View-Controller (MVC)
• Non è uno stile architetturale
• Possiamo avere una architettura Three-tier che fa uso dell’MVC
Model View Controller
<<Controllore>> Form da visualizzare
<<Vista>>
Logica Applicativa
Interfaccia Utente
Validazione dati Eventi utente
Presentation
Notifica
Cambiamento
Richiesta di
Richiesta
Refresh
aggiornamento
<<Modello>>
Business Logic
Business Logic
Database
Data Access
6
Architetture software
• Libri suggeriti per patterns architetturali:
• Software Engineering
by Ian Sommerville
• Patterns of Enterprise Application
Architecture
by Martin Fowler (with Dave Rice,
Matthew Foemmel, Edward Hieatt, Robert Mee,
and Randy Stafford)
7
Problema principale
• SQL permette di accedere ai dati memorizzati in una
base di dati e di aggiornarli
• Il suo potere espressivo è però limitato (rispetto a
quello di un generico linguaggio di programmazione)
• Questo significa che non tutte le elaborazioni che
possiamo volere applicare ai dati possono essere
espresse in SQL
• In particolare, SQL non è:
• Computazionalmente completo (Touring
Completo), né
• Operazionalmente completo o system complete
8
Completezza computazionale
• È relativa alla capacità di esprimere nel linguaggio
tutte le computazioni teoricamente possibili
• In SQL mancano costrutti tipici dei generici linguaggi
di programmazione (imperativi) quali il costrutto di
scelta o quello di iterazione
Esempio:
•
flight(flight_n,dep_time,arr_time,origin,destination)
– trovare tutte le destinazioni raggiugibili da Singapore,
anche con più cambi solo in SQL-99, non in SQL-92
– calcola il cammino più corto tra due aereoporti
non può essere espressa neppure in SQL-99
9
Completezza operazionale
• Abilità di esprimere in un linguaggio
operazioni che richiedono comunicazioni
con l’hardware e le periferiche
• SQL non contiene costrutti per scrivere
su file, stampare, creare un’interfaccia
utente,...
10