Periti Informatici - Corriere della Sera

Informatica generale
Un’associazione “Banca del Tempo” vuole realizzare una base di dati per
registrare e gestire le attività dell’associazione.
La “Banca del Tempo” (BdT) indica uno di quei sistemi organizzati di
persone che si associano per scambiare servizi e/o saperi, attuando un aiuto
reciproco.
Attraverso la BdT le persone mettono a disposizione il proprio tempo per
determinate prestazioni (effettuare una piccola riparazione in casa, preparare
una torta, conversare in lingua straniera, ecc.) aspettando di ricevere
prestazioni da altri.
Non circola denaro, tutte le prestazioni sono valutate in tempo, anche le
attività di segreteria.
Le prestazioni sono suddivise in categorie (lavori manuali, tecnologie,
servizi di trasporto, bambini, attività sportive, ecc.).
Chi dà un’ora del suo tempo a qualunque socio, riceve un’ora di tempo da
chiunque faccia parte della BdT. La base di dati dovrà mantenere le
informazioni relative ad ogni prestazione (quale prestazione, da chi è stata
erogata, quale socio ha ricevuto quella prestazione, per quante ore e in quale
data) per consentire anche interrogazioni di tipo statistico.
Il territorio di riferimento della BdT è limitato (un quartiere in una grande
città o un piccolo comune) ed è suddiviso in zone; la base di dati dovrà
contenere la mappa del territorio e delle singole zone, in forma grafica.
Si consideri la realtà di riferimento sopra descritta e si realizzino:
1. la progettazione concettuale della realtà indicata attraverso la produzione di uno
schema (ad esempio ER, Entity-Relationship) con gli attributi di ogni entità, il tipo
di ogni relazione e i suoi eventuali attributi;
2. una traduzione dello schema concettuale realizzato in uno schema logico (ad
esempio secondo uno schema relazionale);
3. le seguenti interrogazioni espresse in algebra relazionale e/o in linguaggio SQL:
a. produrre l’elenco dei soci (con cognome, nome e telefono) che hanno un “debito”
nella BdT (coloro che hanno usufruito di ore di prestazioni in numero superiore a
quelle erogate);
b. data una richiesta di prestazione, visualizzare la porzione di mappa del territorio nel
quale si trova il socio richiedente e l’elenco di tutti i soci che si trovano in quella
zona in grado di erogare quella prestazione, visualizzandone il nome, cognome,
indirizzo e numero di telefono;
c. visualizzare tutti i soci che fanno parte della segreteria e che offrono anche altri tipi
di prestazione;
d. produrre un elenco delle prestazioni ordinato in modo decrescente secondo il
numero di ore erogate per ciascuna prestazione.
4. (Facoltativo) Sviluppare il problema posto scegliendo una delle due seguenti
proposte descrivendone le problematiche e le soluzioni tecniche adottabili:
4.1 l’associazione BdT vuole realizzare un sito Web per rendere pubbliche le sue attività
consentendo anche di effettuare on-line le interrogazioni della base di dati previste
nel punto 3;
4.2 l’associazione BdT vuole realizzare un sito Web attraverso il quale possa
raccogliere l’adesione on-line di altri associati, attraverso il riempimento di un
modulo da inviare via Internet all’associazione.
-------------------Soluzione
La situazione prevista dal testo conduce facilmente alla determinazione delle seguenti entità:
1. ZONA caratterizzata da un codice e una mappa grafica
2. SOCIO caratterizzata da un codice, dati anagrafici, zona di appartenenza, elenco dei servizi
offerti, ore complessive (valore positivo per crediti e negativo per debiti)
3. TIPO PRESTAZIONE caratterizzata da una sigla di riconoscimento, una descrizione e la
categoria di appartenenza
4. PRESTAZIONE, caratterizzata da un numero progressivo di registrazione, il codice del
socio che usufruisce della prestazione, il codice del socio che fornisce la prestazione, la
durata in ore e la data.
Il modello E/R che descrive le relazioni tra le entità assume la seguente forma:
abita
ZONA
1
offre
n
n
SOCIO
1
m
TIPO
PRESTAZIONE
1
1
appartiene
fornisce
fruisce
n
n
n
PRESTAZIONE
Dato che la maggior parte dei DBMS di tipo relazionale non offre la possibilità di implementare
relazioni n a m e campi ripetuti, abbiamo introdotto una tabella intermedia, denominata Offerta, che
lega le tabelle PRESTAZIONE e SOCIO.
Inoltre, per semplificare la costruzione delle query richieste abbiamo aggiunto alla tabella SOCIO
un campo booleano, che indica l’appartenenza alla segreteria.
La trasposizione delle altre entità nelle relative tabelle è del tutto banale, in quanto la struttura E/R
prevede già la presenza di chiavi esterne come attributi.
Analisi delle queries
a) Un valore negativo nel campo Ore complessive della tabella SOCIO indicherà debito.
Nel database ogni volta che si fruisce di una prestazione la sua durata viene sottratta al
valore del campo, mentre ogni volta che si fornisce la prestazione, la durata verrà sommata
al valore del campo.
SELECT socio.cognome, socio.nome, socio.telefono, socio.indirizzo, socio.[ore complessive]
FROM socio
WHERE (((socio.[ore complessive])<0));
b) Il metodo più semplice per ottenere la schermata richiesta è quello di predisporre due
sottomaschere affiancate, associate alle query, che forniscono, rispettivamente, il grafico e i dati dei
soci.
Vista la complessità della richiesta riguardante l’elenco di coloro che offrono il servizio, per non
appesantire il codice SQL abbiamo optato per una serie di query in cascata che selezionano, man
mano, gli elementi necessari. Si tratta ovviamente di query parametriche che fanno riferimento ai
valori inseriti dal richiedente.
Query per la visualizzazione del grafico
SELECT zona.grafico
FROM zona INNER JOIN socio ON zona.[codice zona] = socio.[codice zona]
WHERE (((socio.[codice socio])=[codice socio richiedente]));
Query per l’individuazione della zona (Zona del richiedente)
SELECT socio.[codice socio], socio.[codice zona]
FROM socio
WHERE (((socio.[codice socio])=[codice del richiedente]));
Query per l’individuazione dei soci che offrono la prestazione richiesta (Disponibilità)
SELECT socio.[codice socio], tipo.[sigla prestazione], tipo.descrizione
FROM tipo INNER JOIN
(socio INNER JOIN offerta ON socio.[codice socio] = offerta.[codice socio])
ON tipo.[sigla prestazione] = offerta.[sigla prestazione]
WHERE (((tipo.descrizione)=[richiesta]));
Query che fornisce i dati richiesti dal tema
SELECT [zona del richiedente].[codice zona] AS [zona del richiedente].[codice zona],
[disponibilita].[codice
socio],
[socio].[cognome],
[socio].[nome],
[socio].[telefono],
[socio].[indirizzo], [socio].[codice zona] AS [socio_codice zona]
FROM disponibilita INNER JOIN
([zona del richiedente] INNER JOIN socio
ON [zona del richiedente].[codice zona]=[socio].[codice zona])
ON [disponibilita].[codice socio]=[socio].[codice socio];
b) Considerando tutti i servizi di segreteria come prestazione specifica, la query di selezione
dovrà
estrarre
l’elenco
dei
soci
aventi:
il
campo
segreteria
settato
a
“True”
- il codice che compare più di una volta nella tabella Offerta
(una per la segreteria e una o più per le altre prestazioni offerte).
SELECT DISTINCTROW socio.[codice socio], socio.cognome, socio.nome, socio.segreteria
FROM socio INNER JOIN offerta ON socio.[codice socio] = offerta.[codice socio]
GROUP BY socio.[codice socio], socio.cognome, socio.nome, socio.segreteria
HAVING (((socio.segreteria)=True) AND ((Count(*))>1));
d) Si tratta di una semplice query di aggregazione, con un campo per la somma delle ore.
SELECT [prestazione].[sigla prestazione], [tipo].[descrizione],
Sum([prestazione].[durata]) AS somma
FROM prestazione INNER JOIN tipo
ON [tipo].[sigla prestazione]=[prestazione].[sigla prestazione]
GROUP BY [prestazione].[sigla prestazione]
ORDER BY somma DESC;
Parte facoltativa
Le richieste del punto 4 risultano generiche. Ci limiteremo a considerazioni di carattere generale.
Per entrambe le situazioni l’Associazione dovrà dotarsi di un dominio. Potrà scegliere la soluzione
in “hosting” presso un provider ufficiale, con il vantaggio di delegare la gestione della sicurezza,
oppure una soluzione “proprietaria”, che richiede un server (almeno uno), un indirizzo IP statico e
connessioni adeguate al volume di traffico previsto. Il tutto sotto il controllo di adeguati dispositivi
di sicurezza.
Considerando nello specifico la richiesta 4.1 si arriva alla conclusione che bisogna consentire agli
utenti, provvisti di un adeguato codice di accesso, la sola interrogazione del database. Questa
operazione è gestibile con un link dinamico ad un “oggetto database”.
Con queste premesse rimane da controllare la correttezza formale e la congruenza delle richieste
dell’utente. A tal fine sarebbe comodo fissare le scelte possibili, associandole a pulsanti o zone
sensibili delle varie pagine, collegati ai dati richiesti. Sono necessari per questa attività degli script
di controllo sulla prestazione richiesta. La zona e le altre informazioni possono essere ricavate dal
codice di accesso dell’associato.
Nel caso 4.2 la situazione proposta è più complessa in quanto richiede form di input da compilare a
cura dell’associato. Ovviamente i controlli di correttezza e congruenza risultano più complessi.
Il passo successivo potrebbe essere lo sviluppo di un modulo software finalizzato all’aggiornamento
dinamico del database con le informazioni contenute nei moduli.
Considerazioni più specifiche sulla sicurezza e sull’ambiente (sistema operativo, server web, ...)
sembrano andare oltre le richieste del testo e comunque richiederebbero approfondimenti più
puntuali.
(soluzione a cura di:
prof. Domenico Capezzuto, docente di Sistemi presso Itis Lagrange di Milano
prof. Antonio Garavaglia, docente di Informatica presso Itis Lagrange di Milano
prof. Umberto Torelli, docente di Elettronica presso Itis Feltrinelli Milano)