Progetto Architetture Del Software e Dei Dati
Appello del 29/06/2016
Trasporto Merci
Gruppo BSV
Beretta Matteo, 763953
Scoca Luigi, 762115
Virgolino Dalila, 764097
Testo del Problema(1)
• Si deve realizzare un sistema per la pianificazione e la gestione del trasporto di merci da un
magazzino centrale (MC) a un insieme di destinazioni periferiche (DP). La struttura operativa
comprende:
1. Un Ufficio Logistico (UL)
2. Un Centro di Coordinamento (CC)
3. Un insieme di Mezzi di Trasporto (MT)
4. Un servizio esterno (MV) che fornisce la descrizione della mappa viaria e le stime dei tempi di
percorrenza sui singoli archi viari
• Le sedi di UL, di CC e dei parcheggi notturni dei mezzi sono in località fisicamente lontane fra loro.
UL ha il compito di definire giornalmente, per ciascun mezzo, le merci da caricare in MC e le destinazioni
finali DP. UL possiede già un sistema informativo che ne supporta le attività e produce giornalmente le
Bolle di Carico (BC), cioè i documenti che descrivono, per ciascun mezzo, le merci da caricare e le
destinazioni. Si assuma che ciascun mezzo effettui un solo viaggio per giorno. Le attività interne di UL e
la struttura interna del suo sistema informativo non devono essere progettate.
Testo del Problema(2)
• CC ha il compito di:
1. Pianificare per ciascun mezzo, in base alla BC ad esso relativa e utilizzando informazioni
fornite da MV, il percorso (PP) da seguire per raggiungere le destinazioni
2. Comunicare a inizio giornata le bolle di carico BC e i percorsi PP agli autisti dei mezzi MT
3. Verificare e segnalare tempestivamente a un operatore, gli eventuali scostamenti (spaziali e
temporali) dei percorsi effettivi dei mezzi MT rispetto ai percorsi pianificati
4. Effettuare analisi statistiche sugli scostamenti dei percorsi effettivi rispetto a quelli
pianificati.
• Ciascun MT è attrezzato in modo da:
1. Presentare all’autista le informazioni BC e PP
2. Rilevare, con temporizzazioni opportune la posizione effettiva
3. Comunicare le informazioni utili a CC per lo svolgimento dei suoi compiti.
Assunzioni
•
•
•
•
•
•
•
•
•
•
•
Assumiamo che la Bolla di Carico creata da UL sia in formato elettronico e contenga già le informazioni relative
al mezzo e all’autista che dovrà compiere la consegna. In questo modo il CC non deve preoccuparsi di
selezionare un mezzo idoneo e di controllare gli autisti disponibili. Il CC dovrà solamente notificare all’autista la
futura spedizione e inviare al mezzo le informazioni sulla bolla e sul percorso.
I percorsi di ogni MT vengono effettuati in giornata, dato che supponiamo che UL crei le BC in modo da
distribuire in modo appropriato e ottimizzato le consegne da effettuare.
Assumiamo che gli autisti possano sempre accedere alle Bolle di Carico e ai percorsi, fornitegli tramite e-mail.
I parcheggi notturni possono essere più di uno, assumiamo che un MT sia posizionato sempre nello stesso
parcheggio e che questa informazione sia trascritta nella bolla.
Assumiamo che il servizio MV sia aggiornato almeno una volta al giorno e che il nostro sistema prelevi i dati
necessari per pianificare i percorsi quotidianamente.
Il CC fa partire una spedizione solo se riceve la Bolla di Carico entro le 10 di mattina.
Se il CC riceve una bolla dopo le 10 di mattina, il percorso verrà calcolato il giorno successivo in modo da
utilizzare i dati aggiornati sulla viabilità.
Supponiamo che il collegamento tra i mezzi di trasporto e il CC sia sempre disponibile e che sia sempre possibile
ricavare la posizione tramite il ricevitore GPS.
Assumiamo che il sistema da noi progettato sia adatto a gestire un servizio logistico erogato a livello regionale.
Ogni spedizione può avvenire tra le 7:00 le 18:00, dal lunedì al venerdì. In questo modo, la gestione degli
scostamenti e della ricezione di informazioni utili da parte del CC, si limita a questo intervallo di tempo.
CC non gestisce le priorità delle spedizioni in quanto assumiamo che vengano già gestite da UL.
Dimensionamento del Problema
• Abbiamo assunto che il servizio operi a livello regionale. Considerando che
un’azienda di logistica di grandi dimensioni, che opera a livello nazionale, possiede
circa 3000 mezzi, possiamo dire che in media ne impiega 150 per ogni regione.
• Considerando di dimensionare il problema per essere utilizzato nella regione
Lombardia, una delle più estese, abbiamo stimato di avere a disposizione circa 200
mezzi.
• Considerando che in Lombardia avvengono circa 60 incidenti al giorno, possiamo
sovrastimare che almeno 3 mezzi ogni ora potrebbero incontrare o essere coinvolti
in questi incidenti e cambiare percorso, generando così una segnalazione di
scostamento.
• Abbiamo quindi calcolato che per gestire gli scostamenti e le info utili inviate dagli
MT siano necessari almeno 3 operatori. Poiché nelle nostre stime non sono coinvolti
gli scostamenti causati da traffico e lavori stradali non segnalati da MV, possiamo
considerare accettabile la presenza di 5 operatori.
Requisiti Funzionali e
Non Funzionali
Requisiti Funzionali
CC:
• Pianifica il percorso di MT in base alle informazioni ricevute da UL tramite la bolla
(BC).
• Comunica ai mezzi MT ed agli autisti le bolle e i percorsi.
• Comunica ad un operatore gli scostamenti (spaziali e temporali) effettuati da MT.
• Effettua analisi statistiche sugli scostamenti effettuati rispetto a quelli previsti.
MT:
• Presenta all’autista la bolla (BC) e il percorso previsto.
• Rileva la posizione effettiva.
• Comunica informazioni e le rilevazioni sulla posizione a CC.
Requisiti Non Funzionali
CC:
• Pianifica il percorso di MT giornalmente, con un ritardo massimo di 1 giorno
lavorativo, nel caso in cui la bolla arrivi al CC dopo le 10 di mattina.
• Comunica ai mezzi MT ed agli autisti le bolle e i percorsi all’inizio di ogni giornata.
• Comunica ad un operatore gli scostamenti (spaziali e temporali) effettuati da MT,
con un ritardo accettabile di 1 minuto.
• Effettua analisi statistiche ogni due settimane sugli scostamenti effettuati rispetto
a quelli previsti.
MT:
• Rileva la posizione effettiva ogni 10 secondi .
• Ogni minuto comunica le rilevazioni al CC.
• Effettua un solo viaggio al giorno.
Analisi
Who, Where, What
Who-Where: Diagramma dei Casi d’Uso
What: Diagramma delle Classi
Architettura del
Software
Diagrammi di Attività
How, Why, When
Acquisizione Raw Data
• Analizzando i casi limite (veicolo fermo – veicolo in autostrada 100km/h) la distanza massima
percorsa tra due rilevazioni consecutive del GPS, utilizzando una frequenza di campionamento di 10
secondi, è di circa 300 m, considerati trascurabili ai fini della rilevazione degli scostamenti.
Comunica Posizione
•
Considerando che i dati GPS vengono raccolti 6 volte al minuto, in un minuto il veicolo potrebbe percorrere una
distanza massima di 2 km (100km/h in autostrada). Abbiamo deciso di inviare i dati rilevati a CC ogni minuto per
le seguenti ragioni:
- non meno di 1 minuto per ridurre il numero di pacchetti inviati e poichè è considerato accettabile
conoscere in ritardo (di 1 minuto) la posizione e il percorso effettuato dal veicolo;
- non più di un minuto per ridurre le dimensioni dei pacchetti inviati dal veicolo.
Crea BC
Pianifica Percorso
• Poiché come da specifica, ogni MT può compiere un viaggio al giorno e avendo stimato di dover
gestire circa 200 mezzi, ogni giorno il CC elabora circa 200 percorsi.
• Il ritardo massimo di un giorno si riferisce ad un giorno lavorativo.
Segnala Scostamenti
Invio Informazioni a CC
Analisi Statistiche
Architettura Logica
Soluzione 1(1)
• La prima soluzione proposta è stata ottenuta suddividendo i componenti con un partizionamento
verticale per livelli di astrazione e secondo il criterio di omogeneità, non rispettando però i criteri di
isolamento e localizzazione.
• I diagrammi di attività son stati quindi divisi in modo tale che ogni componente si occupi di attività
omogenee tra loro.
Le componenti individuate sono:
• Gestore Dati: si occupa di acquisire i dati grezzi dal sensore GPS, salvarli in un datastore locale e inviarli
al CC periodicamente. Si occupa anche di monitorare gli scostamenti e notificare quest’ultimi
all’operatore. Infine, ogni due settimane si occupa anche di generare delle statistiche sugli scostamenti.
Ha molteplicità pari a 1, gestisce tutte le attività su ogni MT e nel CC.
• Gestore Informazioni: si occupa di notificare un evento al CC e di processarlo. Ha molteplicità pari 1.
• Gestore Spedizioni: prepara le Bolle di Carico della giornata e le manda al Centro di Coordinamento
che le utilizza per progettare i percorsi e per portare le merci a destinazione. Molteplicità pari a 1.
Soluzione 1(1)
Pro:
• Intraflow basso, le componenti
comunicano poco fra di loro.
• Non ci sono controlflow che passano
attraverso le diverse componenti.
Contro:
• Complessità ancora molto alta poiché
ogni componente si occupa di tutti i
mezzi di trasporto.
• Nello stesso componente coesistono
frequenze e ritardi differenti.
• Non si tiene conto del criterio di
localizzazione.
• Extraflow alto poiché ogni
componente comunica con molti
elementi esterni.
Soluzione 1(2)
Condivisione
IntraFlow
Astrazione
100
90
80
70
60
50
40
30
20
10
0
ExtraFlow
Complessità
60
Complessità
80
Frequenza
100
Ritardo
100
Localizzazione
100
ExtraFlow
80
IntraFlow
20
Condivisione
60
Frequenza
Ritardo
Localizzazione
Astrazione
Soluzione 2(1)
• La seconda soluzione proposta è stata ottenuta suddividendo i componenti secondo i criteri di
omogeneità, isolamento e localizzazione.
• Per rispettare il criterio di omogeneità abbiamo fatto in modo che ogni componente si occupi di un
compito specifico o includa attività tra loro omogenee.
• I componenti son stati suddivisi in modo da minimizzare il flusso di informazioni tra le componenti,
rispettando così il criterio di isolamento.
• Infine, per il criterio di localizzazione, ogni componente si occupa di gestire attività che avvengono
nello medesimo luogo o, per meglio dire, sullo stesso device dell’architettura di deployment.
Pro:
• Bassa complessità dei componenti.
• Minor grado di astrazione e localizzazione.
• Nello stesso componente coesistono frequenze e ritardi simili tra loro.
• Extraflow si abbassa perché ogni componente comunica con un numero più basso di attori esterni.
Contro:
• Intraflow più alto perché con più componenti c’è uno scambio di informazioni maggiore.
• Ci sono controlflow che passano attraverso le diverse componenti.
Soluzione 2(2)
Le componenti individuate sono:
• Gestore Dati Veicolo: si occupa di acquisire i dati grezzi dal sensore GPS, salvarli in un datastore
locale e inviarli al CC periodicamente. Ha molteplicità pari al numero di MT utilizzati per il trasporto
merci.
• Gestore Invio Info: si occupa di notificare un evento al CC. Ha molteplicità pari al numero di MT
utilizzati per il trasporto mezzi.
• Gestore Ricezione Info: gestisce le notifiche ricevute dai veicoli. Molteplicità pari a 1.
• Gestore BC: azioni svolte dall’Ufficio Logistico. Prepara le Bolle di Carico della giornata e le manda al
Centro di Coordinamento. Molteplicità pari a 1.
• Gestore CC: azioni svolte dal Centro di Coordinamento per quanto riguarda la spedizione delle merci.
Riceve le Bolle di Carico ed elabora i percorsi dei vari mezzi. Molteplicità pari a 1.
• Gestore Statistiche: si occupa di analizzare i dati degli scostamenti per generare dati statistici.
Molteplicità pari a 1.
• Gestore Scostamenti: analizza la posizione ed il percorso di ogni MT, rispetto al percorso atteso PP,
generando, nel caso di scostamenti, una segnalazione. Molteplicità pari a 1.
Soluzione 2(3)
Condivisione
IntraFlow
Astrazione
100
90
80
70
60
50
40
30
20
10
0
ExtraFlow
Complessità
Frequenza
Ritardo
Localizzazione
Astrazione
30
Complessità
30
Frequenza
45
Ritardo
60
Localizzazione
10
ExtraFlow
10
IntraFlow
40
Condivisione
20
Soluzione Scelta
• Osservando il grafo, risulta ovvio che la
scelta migliore comprende la soluzione 2
che, con un maggior grado di
partizionamento, ha permesso di ridurre la
complessità del sistema. Infatti, poiché la
maggior parte dei componenti si occupa di
un solo MT e di attività localmente
omogenee, è diminuita di molto la
complessità dei componenti.
• Consente di ottenere un compromesso fra
tutti i parametri mostrati nel grafico.
Condivisione
IntraFlow
Astrazione
100
90
80
70
60
50
40
30
20
10
0
ExtraFlow
Complessità
Frequenza
Ritardo
Localizzazione
Architettura Concreta
Gestore Dati Veicolo
Gestore
Scostamenti
Gestore Invio e Ricezione Info
Gestore Percorso
Gestore Statistiche
Architettura di
Deployment
Soluzione 1
Soluzione 2
Soluzione Scelta
Tra le opzioni mostrate in precedenza abbiamo optato per la soluzione 2, in quanto presenta i seguenti
vantaggi sulle altre soluzioni proposte:
• Permette outsourcing dei dati.
• I server del CC avranno una mole di lavoro inferiore in quanto non dovranno occuparsi della gestione
del DB.
• Inoltre i compiti del CC di generare i percorsi e quello di gestire le informazioni ricevute dai vari MT
sono partizionati su due nodi differenti, ognuno dei quali si occupa di uno solo di questi aspetti.
Architettura Hardware
e di Rete
Hardware: MT(1)
Tablet Huawei MediaPad T2 10.0 pro + Sim
Il seguente tablet è fornito di connessione internet 4G e del modulo GPS. Il modulo gps
riceve i segnali: GPS, A-GPS e GLONASS.
Ad ogni tablet è assegnata una sim Vodafone con piano dati aziendale, il costo viene
recepito mensilmente. Ad eventuali superamenti della soglia dati viene applicata una
mora ma il piano dati non viene bloccato.
Hardware: MT(2)
Ogni tablet dispone di un’apposita applicazione in grado di comunicare con il CC.
Ogni tablet è associato univocamente al suo mezzo con il codice identificativo di
quest’ultimo. In questo modo il CC può inviare direttamente al tablet le informazioni
sul percorso e sulla bolla di carico. L’app progettata permette anche all’autista di
consultare le informazioni riguardanti la spedizione e nel caso di necessità, segnalare
info utili al CC.
Hardware: CC(1)
Per la gestione dell’hardware di CC avevamo più soluzioni:
1. Creare in locale il server e la base di dati.
2. Creare in locale l’applicativo server e utilizzare un servizio remoto per la base di
dati.
3. Utilizzare un servizio remoto sia per l’applicativo server che per al base di dati.
Considerando che il nostro sistema dovrà gestire una notevole quantità di dati ma
non richiede un carico di lavoro eccessivamente alto abbiamo optato per la seconda
opzione. Inoltre nel nostro sistema non sono previsti picchi di carico in cui è
necessario aumentare esponenzialmente le caratteristiche hardware della macchina
con sistemi virtualizzati.
Come servizio di Database esterno abbiamo pensato ad una soluzione Amazon,
mentre per il server abbiamo pensato ad due server IBM di medio alte prestazioni,
uno che esegue delle operazioni sul percorso e uno per le informazioni e scostamenti.
Hardware: CC(2)
Amazon Relational Database (Amazon RDS)
Il seguente servizio offre una serie di database relazionali . Il costo varia in base
al numero delle query effettuate e alle caratteristiche dell’hardware richiesto.
Impostando una configurazione medio alta il costo è di 1,160 dollari all’ora.
Con questa configurazione il costo mensile è di circa 850€.
Hardware: CC(3)
Server IBM System x3500 M4
Il seguente server è fornito con assistenza da IBM ad un costo di
circa 3000€
Caratteristiche tecniche:
Processore (max): Fino a 2 processori Intel Xeon della famiglia
E5-2600 v2 a 3,5 GHz
Cache (max): Fino a 30 MB per processore
Memoria (max): Fino a 384 GB di RDIMM DDR-3 o 768 GB di
LRDIMM DDR-3
Slot di espansione: Fino a otto slot di espansione PCIe
Interfaccia di rete: Intel I350AM4 Quad Port GbE
Hardware: UL
Non dovendo progettare la struttura interna di UL, supponiamo, in maniera
semplificata, che il sistema hardware di UL sia composto da una base di dati e da un
server che svolge una serie di operazioni. Visto che il server non deve eseguire
operazioni particolarmente esose e il database non deve essere eccessivamente
popolato abbiamo pensato che si potesse realizzare in locale sia il server sia la base di
dati.
Infrastruttura di rete
Il CC (Centro di Coordinamento) è collegato alla rete internet tramite fibra ottica.
Sfrutta la rete internet per collegarsi con l’UL (Ufficio Logistico) attraverso una VPN.
Presenta un indirizzo IP statico per interfacciarsi con la rete.
MT è connesso alla rete internet tramite la SIM dati con un abbonamento ad internet,
comunica solamente con il CC.
Stime dei Costi
Costi Infrastrutture
Prodotto
Quantità
Costo unitario
Costo totale
Tablet 3G/4G
200
300€
60000€
Supporto tablet su
autoveicolo
200
15€
3000€
Cablaggio rete con fibra
ottica fino a CC
1
800€
800€
Server
2
3000€
6000€
UPS
2
500€
1000€
Router
1
160€
160€
Struttura comunicazione 1
1000€
1000€
Pc operatore
500€
2500€
5
Costo totale infrastrutture: €74460
Costi Software
Prodotto
Quantità
Costo unitario
Costo totale
Licenza sistema
operativo server
2
500€
1000€
Programmazione app
MT
1
30000€ (5 persone * 4
mesi * 1500€/mese)
30000€
Test app MT
1
1000€
1000€
Programmazione
applicativo server
2
60000€ (6 persone * 6
mesi * 1600€/mese)
120000€
Test applicativo server
2
2000€
4000€
Sviluppo base di dati
server
1
3000€ (2 persone * 1
mese * 1500€/mese)
3000€
Costo totale software: 159000€
Costi di Gestione e di Aggiornamento
Prodotto
Quantità
Costo unitario
Costo totale
Sim card + abbonamento 200
15€ /al mese
3000€
Costo mensile fibra
ottica
1
50€/mese
50€
Energia elettrica
1
300€/mese
300€
Assistenza software e
hardware
1
500€/mese
500€
Amazon RDS database
1
850€/mese
850€
Stipendio sistemista
1
1500€/mese
1500€
Stipendio
1
programmatore/databas
e manager
1500€/mese
1500€
Stipendio operatore
1500€/mese
7500€
5
Costo totale gestione e aggiornamento: 15200€
Costo Totale Previsto
Il costo totale è dato da una spesa iniziale per l’implementazione dell’architettura
hardware/software e da un costo di mantenimento calcolato su base mensile.
Costo infrastrutture:
74460 €
Costo software: 159000€
TOTALE COSTO REALIZZAZIONE: 233460€
Costo gestione e aggiornamento: 15200 €/mese
N.B: I costi si riferiscono a stime previste
Architettura dei Dati
DBCC – Schema Concettuale
DBCC – Schema Logico
Merce(idMerce, tipologia, peso, descrizione, destinazione, bolla)
Destinazione(idDestinazione, città, via, #civico)
BollaDiCarico(idBolla, data, MT, parcheggio, tipoDiSpedizione)
Percorso(idPP, data, orarioPartenza, orarioAttesoArrivo, bolla, kmTot)
Composto(idPP, idTratto)
TrattoViario(idTratto, città, via, coordinateInizio, coordinateFine, civicoIniziale, civicoFinale, tempoAtteso,
timestamp, kmTot)
InfoUtili(idInfo, descrizione, tipologia, timestamp, percorso)
Scostamento(idScostamento, percorso , tipologia, descrizione, ritardo, mScostamento, coordinateEff,
coordinateAtt, timestamp)
Statistiche(idStatistica, tipologia, dati)
Utilizza(idStatistica, idScostamento)
DBUL – Schema Logico
Destinazione(idDestinazione, città, via, #civico)
Carico(idCarico, tipologia, peso, descrizione, destinazione, volume)
BC(idBolla, data, causale, MT, parcheggio, priorità, tipoDiSpedizione, categoria)
Accompagna(idBolla, idCarico)
MT(idMT, parcheggio, targa, marca, modello, tipologia, caricoMassimo, volumeMassimo)
Autista(idAutista, nome, cognome, dataNascita, cittàNascita, cittàResidenza, indirizzo, tel)
Guida(idMT, idAutista, data)
N.B. Esiste la relazione Accompagna perché UL può non aver creato ancora la
bolla e Carico avrebbe un campo vuoto relativo a bolla.
DBUL – Reverse Engineering(1)
Fasi del Reverse Engineering:
1. Si associano le tabelle con chiavi semplici a delle entità. La chiave di ogni entità è
l’identificatore della tabella.
Considerando solo le tabelle con chiavi semplici che non possono corrispondere a relazioni N a N,
identifichiamo 5 entità: Carico, BC, MT, Autista e Destinazione, ognuna delle quali ha come chiave
l’identificatore della tabella.
DBUL – Reverse Engineering(2)
2. Si individuano le chiavi esterne e i vincoli di integrità referenziali e si stabiliscono le relazioni.
Le chiavi esterne e i vincoli di integrità referenziale vengono individuati grazie al fatto che i nomi degli
attributi sono stati scelti in modo chiaro e quasi univoco. Infatti possiamo notare subito che:
• BollaDiCarico.MT, BollaDiCarico.parcheggio -> MT.idMT, MT.parcheggio -> Relazione Legato;
• Carico.destinazione -> Destinazione.idDestinazione -> Relazione Destinato.
Le cardinalità di queste relazioni sono sicuramente 1 a N o 1 a 1, dato che una delle due entità è legata
ad una sola istanza dell’altra entità. L’altra cardinalità viene impostata in base alla conoscenza del
dominio delle entità. Dato che abbiamo assunto che una bolla può essere associata a più di un carico, la
relazione sarà 1 a N.
Lo stesso ragionamento viene fatto anche per la relazione Destinato.
DBUL – Reverse Engineering(3)
Inoltre abbiamo due tabelle identificate come relazioni e non come entità, poiché possiedono chiavi
esterne appartenenti a due entità diverse.
Accompagna(idBolla, idCarico)
Guida(idMT, idAutista, data)
La relazione Accompagna ha cardinalità 1(0) a N, perché sappiamo per certo che un carico può essere
associato al massimo ad una sola bolla. Mentre la relazione Guida ha cardinalità N a N poiché tutti i
mezzi possono essere guidati da tutti gli autisti.
3. Si indentificano eventuali relazioni IS-A o generalizzazioni.
Non ci sono relazioni IS-A o generalizzazioni.
DBUL – Schema Concettuale
Eterogeneità e Corrispondenze Interschema
Eterogeneità/
corrispondenza
DBUL
DBCC
Tipologia
Risoluzione
E1
BC
BollaDiCarico
Livello di schema – Eterogeneità di nome
(Sinonimi – stesso concetto , differenti nomi)
Abbiamo deciso di nominare l’entità in
modo univoco come BollaDiCarico
E2
MT
Bolla DiCarico.idMT
Livello di schema – Tipi di Concetti – Coppie di
Concetti (tipi differenti, attributi vs identità)
Abbiamo deciso di mantenere l’entità MT,
mantenendo la relazione Legato 1 a N
E3
BC.data
BollaDiCarico.data
Livello di schema – Eterogeneità di nome
(Omonimia – stesso nome, differenti concetti)
Abbiamo deciso di rinominare BC.data in
dataEmissione e BollaDiCarico.data in
dataConsegna
E4
-Carico
-Carico.idCarico
-Merce
-Merce.idMerce
Livello di schema – Eterogeneità di nome
(Sinonimi – stesso concetto , differenti nomi)
Abbiamo deciso di nominare l’entità Merce
e l’attributo in modo univoco come idMerce
E5
Relazione
Accompagna 0
aN
Relazione
Accompagna 1 a N
Livello di schema – Tipi di concetti – Coppie di
Concetti (diversa cardinalità tra relazioni)
Abbiamo deciso di mantenere la cardinalità
0 a N, avendo assunto che una Merce può
non essere stata ancora assegnata ad una
BollaDiCarico
C1
BC
BollaDiCarico
Diverso set di attributi
Abbiamo deciso di mantenere tutti gli
attrbuti delle due entità
C2
Carico
Merce
Diverso set di attributi
Abbiamo deciso di mantenere tutti gli
attrbuti delle due entità
Schema Concettuale Globale
Schema Logico Globale
Destinazione(idDestinazione, città, via, #civico)
Merce(idMerce, tipologia, peso, descrizione, destinazione, volume)
BollaDiCarico(idBolla, dataEmissione, dataConsegna, causale, MT, parcheggio, priorità, tipoDiSpedizione, categoria)
Accompagna(idBolla, idMerce)
MT(idMT, parcheggio, targa, marca, modello, tipologia, caricoMassimo, volumeMassimo, parcheggio)
Autista(idAutista, nome, cognome, dataNascita, cittàNascita, cittàResidenza, indirizzo, tel)
Guida(idMT, idAutista, data)
Percorso(idPP, data, orarioPartenza, orarioAttesoArrivo, bolla, kmTot)
Composto(idPP, idTratto)
InfoUtili(idInfo, descrizione, tipologia, timestamp, percorso)
TrattoViario(idTratto, città, via, coordinateInizio, coordinateFine, civicoIniziale, civicoFinale, tempoAtteso, timestamp, kmTot)
Scostamento(idScostamento, percorso , tipologia, descrizione, ritardo, mScostamento, coordinateEff, coordinateAtt, timestamp)
Statistiche(idStatistica, tipologia, dati)
Utilizza(idStatistica, idScostamento)
Mapping GAV(1)
CREATE VIEW Destinazione(idDestinazione, città, via, #civico) AS
SELECT *
FROM DBUL.Destinazione AS ULD LEFT JOIN DBCC.Destinazione AS CCD ON
ULD.idDestinazione = CCD.idDestinazione
CREATE VIEW Merce(idMerce, tipologia, peso, descrizione, destinazione, volume) AS
SELECT ULC.idCarico, ULC.tipologia, ULC.peso, ULC.descrizione, ULC.destinazione,
ULC.volume
FROM DBUL.Carico AS ULC LEFT JOIN DBCC.Merce AS CCM ON ULC.idCarico =
CCM.idMerce
• Considerato il fatto che nella base dati DBUL le tabelle Destinazione e Merce contengono i dati
relativi a tutte le spedizioni effettuate e da effettuare, mentre in DBCC sono presenti i dati relativi
alle spedizioni già associate ad una bolla, abbiamo deciso di mantenere, tramite un LEFT JOIN, tutti
i dati relativi alla DBUL. Lo stesso ragionamento viene applicato per BollaDiCarico.
Mapping GAV(2)
CREATE VIEW BollaDiCarico(idBolla, dataEmissione, dataConsegna, causale, MT, parcheggio, priorità,
tipoDiSpedizione, categoria) AS
SELECT ULBC.idBolla, ULBC.data AS dataEmissione, CCBC.data AS dataConsegna, ULBC.causale,
ULBC.MT, ULBC.parcheggio, ULBC.priorità, ULBC.tipoDiSpedizione, ULBC.categoria
FROM DBUL.BC AS ULBC LEFT JOIN DBCC.BollaDiCarico AS CCBC ON ULBC.idBolla =
CCBC.idBolla
CREATE VIEW Accompagna(idBolla, idMerce) AS
SELECT ULA.idBolla, ULA.idCarico AS idMerce
FROM DBUL.Accompagna AS ULA
UNION
SELECT CCM.bolla AS idBolla, CCM.idMerce
FROM DBCC.Merce AS CCM
CREATE VIEW MT(idMT, parcheggio, targa, marca, modello, tipologia, caricoMassimo, volumeMassimo,
parcheggio) AS
SELECT *
FROM DBUL.MT
Mapping GAV(3)
CREATE VIEW Autista(idAutista, nome, cognome, dataNascita, cittàNascita, cittàResidenza,
indirizzo, tel) AS
SELECT *
FROM DBUL.Autista
CREATE VIEW Guida(idMT, idAutista, data) AS
SELECT *
FROM DBUL.Guida
CREATE VIEW Percorso(idPP, data, orarioPartenza , orarioAttesoArrivo, bolla, kmTot) AS
SELECT *
FROM DBCC.Percorso
CREATE VIEW Composto(idPP, idTratto) AS
SELECT *
FROM DBCC.Composto
Mapping GAV(4)
CREATE VIEW Scostamento(idScostamento, percorso , tipologia, descrizione, ritardo, mScostamento,
coordinateEff, coordinateAtt, timestamp) AS
SELECT *
FROM DBCC.Scostamento
CREATEVIEW Statistiche (idStatistica, tipologia, dati) AS
SELECT *
FROM DBCC.Statistiche
CREATE VIEW TrattoViario(idTratto, città, via, coordinateInizio, coordinateFine, civicoIniziale,
civicoFinale, tempoAtteso, timestamp, kmTot) AS
SELECT *
FROM DBCC.TrattoViario
Mapping GAV(5)
CREATEVIEW Utilizza (idStatistica, idScostamento) AS
SELECT *
FROM DBCC.Utilizza
CREATEVIEW InfoUtili (idInfo, descrizione, tipologia, timestamp, percorso) AS
SELECT *
FROM DBCC.Utilizza
Query Su Schema Globale(1)
1.
Classifica degli autisti in base al numero di percorsi effettuati di almeno 30km
SELECT idAutista, nome, cognome, COUNT(*) AS ConsegneEffettuate
FROM Autista JOIN Guida ON Autista.idAutista = Guida.idAutista
JOIN MT ON MT.idMT = Guida.idMT
JOIN BollaDiCarico ON BollaDiCarico.MT = MT.idMT
JOIN Percorso ON Percorso.bolla = BollaDiCarico.idBolla
WHERE Percorso.kmTot > 30
GROUP BY idAutista
ORDER BY ConsegneEffettuate DESC
2.
Numero bolle di carico trasportate dall’autista Mario Rossi con almeno una consegna a Bergamo
SELECT COUNT(*) AS NumeroBolle
FROM Destinazione JOIN Merce ON Destinazione.idDestinazione = Merce.destinazione
JOIN Accompagna ON Merce.idMerce = Accompagna.idMerce
JOIN BollaDiCarico ON Accompagna.idBolla = BollaDiCarico.idBolla
JOIN MT ON BollaDiCarico.MT = MT.idMT
JOIN Guida ON MT.idMT = Guida.idMT
JOIN Autista ON Autista.idAutista = Guida.idAutista
WHERE Autista.nome = ‘Mario’ AND Autista.cognome = ‘Rossi’ AND Destinazione.città = ‘Bergamo’
Query su Schema Globale(2)
3.
Il percorso con la media più alta in km degli scostamenti spaziali tra tutti i percorsi effettuati
nel mese di Maggio 2016 dal mezzo con targa ‘DD216ZE’
SELECT idPP, AVG(mScostamento) AS MediaScostamenti
FROM MT JOIN BollaDiCarico ON BollaDiCarico.MT = MT.idMT
JOIN Percorso ON Percorso.bolla = BollaDiCarico.idBolla
JOIN Scostamento ON Scostamento.percorso = Percorso.idPP
WHERE (Percorso.data BETWEEN ‘01/05/2016' AND ’31/05/2016’) AND MT.targa = ‘DD216ZE’
GROUP BY idPP
HAVING AVG(mScostamento) = (SELECT MAX(AVG(mScostamento))
FROM MT JOIN BollaDiCarico ON BollaDiCarico.MT = MT.idMT
JOIN Percorso ON Percorso.bolla = BollaDiCarico.idBolla
JOIN Scostamento ON Scostamento.percorso = Percorso.idPP
WHERE (Percorso.data BETWEEN ‘01/05/2016' AND ’31/05/2016’) AND
MT.targa = ‘DD216ZE’
GROUP BY idPP)
Unfolding Query 1
1.
Classifica degli autisti in base al numero di consegne effettuate avendo percorso più di 30km
SELECT idAutista, nome, cognome, COUNT(*) AS ConsegneEffettuate
FROM
(SELECT *
FROM DBUL.Autista) AS Autista
JOIN (SELECT *
FROM DBUL.Guida) AS Guida ON Autista.idAutista = Guida.idAutista
JOIN (SELECT *
FROM DBUL.MT) AS MT ON MT.idMT = Guida.idMT
JOIN (SELECT ULBC.idBolla, ULBC.data AS dataEmissione, CCBC.data AS dataConsegna, ULBC.causale,
ULBC.MT, ULBC.parcheggio, ULBC.priorità, ULBC.tipoDiSpedizione, ULBC.categoria
FROM DBUL.BC AS ULBC LEFT JOIN DBCC.BollaDiCarico AS CCBC ON ULBC.idBolla = CCBC.idBolla) AS
BollaDiCarico ON BollaDiCarico.MT = MT.idMT
JOIN (SELECT *
FROM DBCC.Percorso) AS Percorso ON Percorso.bolla = BollaDiCarico.idBolla
WHERE Percorso.kmTot > 30
GROUP BY idAutista
ORDER BY ConsegneEffettuate DESC
Unfolding Query 2(1)
2.
Numero bolle di carico trasportate dall’autista Mario Rossi
SELECT COUNT(*) AS NumeroBolle
FROM
(SELECT *
FROM DBUL.Destinazione AS ULD LEFT JOIN DBCC.Destinazione AS CCD ON
ULD.idDestinazione = CCD.idDestinazione) AS Destinazione
JOIN
(SELECT ULC.idCarico, ULC.tipologia, ULC.peso, ULC.descrizione, ULC.destinazione, ULC.volume
FROM DBUL.Carico AS ULC LEFT JOIN DBCC.Merce AS CCM ON ULC.idCarico = CCM.idMerce) AS
Merce ON Destinazione.idDestinazione = Merce.destinazione
JOIN
(SELECT ULA.idBolla, ULA.idCarico AS idMerce
FROM DBUL.Accompagna AS ULA
UNION
SELECT CCM.bolla AS idBolla, CCM.idMerce
FROM DBCC.Merce AS CCM) AS Accompagna ON Merce.idMerce = Accompagna.idMerce
Unfolding Query 2(2)
JOIN
(SELECT ULBC.idBolla, ULBC.data AS dataEmissione, CCBC.data AS dataConsegna,
ULBC.causale, ULBC.MT, ULBC.parcheggio, ULBC.priorità,ULBC.tipoDiSpedizione, ULBC.categoria
FROM DBUL.BC AS ULBC LEFT JOIN DBCC.BollaDiCarico AS CCBC ON ULBC.idBolla =
CCBC.idBolla) AS BollaDiCarico ON Accompagna.idBolla = BollaDiCarico.idBolla
JOIN
(SELECT *
FROM DBUL.MT) AS MT ON BollaDiCarico.MT = MT.idMT
JOIN
(SELECT *
FROM DBUL.Guida) AS Guida ON MT.idMT = Guida.idMT
JOIN
(SELECT *
FROM DBUL.Autista) AS Autista ON Autista.idAutista = Guida.idAutista
WHERE Autista.nome = ‘Mario’ AND Autista.cognome = ‘Rossi’ AND Destinazione.città = ‘Bergamo’
Unfolding Query 3(1)
3.
Il percorso con la media più alta in km degli scostamenti spaziali tra tutti i percorsi effettuati
nel mese di Maggio 2016 dal mezzo con targa ‘DD216ZE’
SELECT idPP, AVG(mScostamento) AS MediaScostamenti
FROM
(SELECT *
FROM DBUL.MT) AS MT
JOIN
(SELECT ULBC.idBolla, ULBC.data AS dataEmissione, CCBC.data AS dataConsegna, ULBC.causale,
ULBC.MT, ULBC.parcheggio, ULBC.priorità, ULBC.tipoDiSpedizione, ULBC.categoria
FROM DBUL.BC AS ULBC LEFT JOIN DBCC.BollaDiCarico AS CCBC ON ULBC.idBolla =
CCBC.idBolla ) AS BollaDiCarico ON BollaDiCarico.MT = MT.idMT
JOIN
(SELECT *
FROM DBCC.Percorso) AS Percorso ON Percorso.bolla = BollaDiCarico.idBolla
JOIN
(SELECT *
FROM DBCC.Scostamento) AS Scostamento ON Scostamento.percorso = Percorso.idPP
Unfolding Query 3(2)
WHERE (Percorso.data BETWEEN ‘01/05/2016' AND ’31/05/2016’) AND MT.targa = ‘DD216ZE’
GROUP BY idPP
HAVING AVG(mScostamento) = (SELECT MAX(AVG(mScostamento))
FROM (SELECT *
FROM DBUL.MT) AS MT
JOIN (SELECT ULBC.idBolla, ULBC.data AS dataEmissione, CCBC.data AS
dataConsegna, ULBC.causale, ULBC.MT, ULBC.parcheggio, ULBC.priorità,
ULBC.tipoDiSpedizione, ULBC.categoria
FROM DBUL.BC AS ULBC LEFT JOIN DBCC.BollaDiCarico AS CCBC ON
ULBC.idBolla = CCBC.idBolla ) AS BollaDiCarico ON BollaDiCarico.MT =
MT.idMT
JOIN (SELECT *
FROM DBCC.Percorso) AS Percorso ON Percorso.bolla = BollaDiCarico.idBolla
JOIN (SELECT *
FROM DBCC.Scostamento) AS Scostamento ON
Scostamento.percorso = Percorso.idPP
WHERE (Percorso.data BETWEEN ‘01/05/2016' AND ’31/05/2016’) AND
MT.targa = ‘DD216ZE’
GROUP BY idPP)
Interazione fra CC e il servizio MV(1)
• Per la comunicazione tra il database DBCC e il servizio MV si può adottare la tecnologia di
replicazione, supportata dai principali DBMS. Questa tecnologia consente di condividere i dati
contenuti in un database con altri database.
• L’uso della tecnologia di replicazione nel nostro caso porta i seguenti vantaggi:
1. Disponibilità del servizio: la replicazione rende il sistema meno sensibile ai guasti. Nel caso di
malfunzionamento sul nodo principale, gli altri nodi possono accedere alla loro copia locale;
2. Riduzione del carico della rete: è possibile ridurre la quantità di dati trasmessi poiché i DB
locali acquisiscono e aggiornano solamente le informazioni che vengono aggiornate nella DB
principale;
3. Backup e recovery: la presenza di dati replicati in più DB permette di non dover effettuare il
backup dei dati.
Interazione fra CC e il servizio MV(2)
Interazione fra CC e il servizio MV(3)
• Tra le varie architetture per la replicazione troviamo:
1. Modello Master-Slave – (Replicazione Asimmetrica)
- server principale (master) che contiene la copia principale del DB. Operazioni di lettura e
scrittura;
- server secondari (slave) che possiedono una copia secondaria del DB. Operazioni di lettura.
2. Dual Master – (Replicazione Simmetrica)
Coppia di server di tipo master – Entrambi hanno al possibilità di accedere in scrittura/lettura al
database condiviso.
3. Multi-Master
Estende il modello Dual Master ad un numero più ampio di nodi.
• La nostra architettura prevede l’acquisizione di informazioni da parte del servizio MV. Poiché le
informazioni derivano da questo servizio esterno, la nostra base dati non deve modificare i dati relativi
ai tratti viari, perciò possiamo scegliere il modello Master-Slave, modello in cui vi è un nodo master (MV)
che aggiorna con una determinata frequenza le informazioni sul nostro DBCC, server secondario.
Interazione fra CC e il servizio MV(4)
Per quanto riguarda la modalità di aggiornamento dei dati contenuti nelle basi dati:
• Sincrona : tutte le copie devono essere mantenute consistenti e devono essere sincronizzate. Se una
copia subisce un aggiornamento, questo verrà propagato immediatamente a tutti i DB secondari;
• Asincrona: la transazione di allineamento verso i DB secondari può avvenire in un diverso momento
rispetto alla transazione che aggiorna la DB principale. L’aggiornamento può essere periodico, a
comando o ad accumulo di variazioni.
Nell’architettura da noi progettata abbiamo assunto che le informazioni di MV vengano aggiornate
almeno una volta al giorno, poiché il CC programma i percorsi in mattinata. Per le nostre esigenze, si
può adottare una sincronizzazione asincrona con aggiornamento periodico (una volta al giorno prima
dell’elaborazione dei percorsi).
Inoltre l’aggiornamento viene mediante un protocollo di tipo pull (client-based). In questo scenario, è il
lato client (CC) che richiede l’aggiornamento del database a MV.
I dati prelevati da MV vengono salvati nella tabella TrattoViario.
