UTENTE_REG

Noleggio bici
1 N N 1
1 1

UTENTE STAZIONE
1 1

consegna bici
N N

UTENTE_REG (Cod_utente, N_Carta_Credito, password, tipoU) //password per login al sito

UTENTE (ID_U, cod_fiscale,cognome, nome,indirizzo, mail, telefono, Cod_utente)
NOLEGGIO_BICI ( ID_N, dataN, oraN, cod_bici, COD_U, COD_ST)
CONSEGNA_BICI ( ID_C dataC, oraC, cod_bici, COD_U, COD_ST)
STAZIONE (ID_S, nome, indirizzo, slot_liberi)

UTENTE_REG contiene dati sensibili dell’utente (N° carta di credito, password) si potrebbe
aggiungere l’attributo ‘tipoU’ per indicare ,per esempio con U, l’utente che noleggerà la bici e con
A, l’amministratore/gestore. Se si considera invece che gli user d’accesso dei gestori/amministratori
siano presenti in altre relazioni (e quindi verificate su queste relazioni), l’attributo’tipoU’ non sarà
necessario

Punto 3.a
SELECT slot_liberi
FROM STAZIONE
WHERE nome= [ inserire nome stazione]

Punto 3.b
SELECT cod_bici, cognome, nome, Stazione.nome
FROM UTENTE, NOLEGGIO_BICI, STAZIONE
WHERE ID_U = COD_U AND COD_S=ID_S
AND dataN = [‘inserire data’] AND ora_N = [‘inserire ora’] //attualmente in uso

SECONDA PARTE
II. quesito QUERY

a. SELECT DISTINCT nome, cogmome

FROM UTENTE, NOLEGGIO_BICI
WHERE ID_U = COD_U
AND month(dataN) = [‘inserire mese attuale’]
AND cod_bici = [‘inserire codice bici’]
b. CREATE TABLE TEMP //conterrà per ogni stazione il numero di noleggi
as SELECT count(*) as ‘noleggio’
FROM NOLEGGIO_BICI
WHERE dataN BETWEEN ‘01/02/2019’ AND ‘25/03/2019’
GROUP BY COD_ST

SELECT MAX(noleggio) AS Numero_massimo_noleggi, COD_ST

FROM TEMP

OPPURE

SELECT MAX(noleggio) AS Maggior_Numero_noleggi, COD_ST

FROM (SELECT count(*) as ‘noleggio’ //conterrà per ogni stazione il numero di noleggi
FROM NOLEGGIO_BICI
WHERE dataN BETWEEN ‘01/02/2019’ AND ‘25/03/2019’
GROUP BY COD_ST)

III. quesito NORMALIZZAZIONE

Non è in 1NF perché lo stesso quadro può essere esposto in diversi musei, ciò comporta la
duplicazione dei dati relativi al quadro per ogni museo. È necessario individuare una PK composta:

1NF
QUADRO (Cod_Quadro, Cod_Museo, titolo_quadro, Nome_Museo, Citta_museo, prezzo,
DataInizioEsposizione, DataFineESposizione)

Non è in 2NF perché alcuni campi dipendono da una parte della chiave (es. Nome_Museo)

2NF
QUADRO (Cod_Quadro, titolo_quadro, ID_Museo)
MUSEO ( Cod_Museo, Nome_Museo, Citta_museo, prezzo, DataInizioEsposizione,
DataFineESposizione)

Non è in 3NF perché le date di inizio/fine esposizione dipendono dalla città dove si trova il museo,
e quindi ‘città’ è determinante per gli attributi data inizio/fine.

3NF
QUADRO (Cod_Quadro, titolo_quadro, ID_Museo)
MUSEO ( Cod_Museo, Nome_Museo, prezzo, ID_Citta_museo)
CITTA (COD_Citta_museo, DataInizioEsposizione, DataFineESposizione)

CONSIDERAZIONI sulla simulazione

 Associazioni 1:1 molto rare, assimilabili a funzioni biunivoche: ad un elemento di E1

corrisponde UN SOLO elemento di E2 e VICEVERSA!!!
 Attributi dell’associazione 1:1  praticamente non hanno senso, ma nel caso ci fossero
ricordare come diventa associazione 1:1 nel mod. logico:
  Una sola relazione, di conseguenza anche gli attributi dell’associazione vengono
inseriti in questa relazione
 Due relazioni e si sceglie quale tra le PK delle due entità diventerà FK; gli attributi
dell’associazione 1:1 andranno in una delle due relazioni
 Perché un’entità (BICI) con un solo attributo che è pure PK???
 Tra modello concettuale e logico deve essere mantenuta la coerenza  se non si sa dove
mettere alcuni attributi necessari/richiesti, rivedere il modello E/R, forse c’è qualcosa che
non va bene
 Spesso le associazioni 1:1 trovano significato quando attributi di una stessa entità devono
essere mantenuti separati dagli altri per poter consentire accessi diversi alle due relazioni:
esempio UTENTE_REGISTRATO e UTENTE. (partizionamento verticale in caso di
ristrutturazione del mod. E/R prima di passare al mod. logico)
 Mantenere UTENTE_REGISTRATO e UTENTE separati fa diventare le associazioni
obbligatorie  se un utente è registrato (e quindi presente nella prima relazione) la azioni
fatte dall’utente sono totali (poiché chi noleggia una bici è registrato, e se non lo fosse non
potrebbe noleggiare alcuna bici, l’azione NOLEGGIO_BICI tra UTENTE e STAZIONE è
totale)
 Parte web: in base al problema, se si prevede che un gestore/amministratore del DB acceda
tramite sito, la tipologia di utente deve essere verificata per fare in modo che se user=
utente, siano visualizzate le pagine riservate all’utente, mentre se user =
amministratore/gestore, dovranno (tendenzialmente) essere visualizzate pagine diverse.

IN GENERALE

ORGANICITA’ della soluzione

 Dopo aver letto più volte TUTTA la prova:
 elencare i punti che devono essere sviluppati in ciascun ambito (rete o DB), anche se
non vengono in mente in modo ordinato
 rileggere la prova entrando sempre più nel dettaglio ed eventualmente
aggiungere/rimuovere punti all’elenco prodotto
 ordinare i punti da trattare
 sviluppare ciascun punto senza mai perdere di vista il testo del problema
LA LISTA OTTENUTA RAPPRESENTA LA TRACCIA DELLA SOLUZIONE, LA
VOSTRA PROGETTAZIONE
 Si ricordi che l’infrastruttura della rete è funzionale ai dati, ovvero in base all’architettura di
rete richiesta dal problema si dovrà poter accedere ai dati (DB)
 Nel problema proposto si deve considerare che, a parte UTENTI (relazione riempita
dall’utente stesso all’atto della registrazione) e STAZIONE (relazione compilata dal
gestore/amministratore il quale conosce tutte le informazioni delle stazioni), le altre
relazioni che contengono informazioni su noleggio e consegna delle bici vengono riempite
tramite applicazione (non c’è data entry manuale)
 Per l’organizzazione dei dati concentrarsi su modello concettuale, logico, …
 L’analisi del problema dovrebbe contenere tutte le ipotesi iniziali riguardante sia
l’architettura di rete che la progettazione del DB. Eventuali specifiche possono essere
indicate nel momento dello sviluppo di ciascuna parte  l’analisi quindi non viene descritta
completamente all’inizio, ma si sviluppa durante la trattazione
NUCLEI FONDAMENTALI DA TRATTARE
 Architettura della rete
 Progettazione fisica e logica
 descrizione degli apparati HW e SW necessario
 protocolli
 ….
 Parte applicativa
 Programmi/transazioni che consentono la comunicazione/passaggio dei dati
 Progettazione del sito
 Rappresentazione contestuale
 Approfondimento/trattazione della parte specifica
 Registrazione/accesso
 Progettazione DB
 Eventuali ipotesi e/o considerazioni da specificare in relazione al problema e
sempre mantenendo la COERENZA con lo sviluppo delle altre parti (rete, parte
applicativa
 Sicurezza: è trasversale alla soluzione proposta
 Sicurezza sulla rete
 Crittografia di dati sensibili (password)
 Protezione dei dati del BD tramite comandi del DCL
 Protezione del server (firewall, DMZ, …)
 Backup dei dati, disaster recovery,
 Eventuali file di log
 Controllo degli accessi diversificato (utente, amministratori, gestori, ..)