esempio di soluzione File - e-Learning

Sistema gestione interventi in
caso di neve
Simone Fontana
712638
Sebastiano Bassani 718583
Il Problema
Si richiede la progettazione di un sistema per la gestione degli
interventi in caso di emergenza neve.
● La struttura operativa comprende:
1. Un Centro di Coordinamento (CC).
2. Un Centro di Quartiere (CQ) per ogni quartiere della città.
3. Squadre di Quartiere (SQ) di spalatori, ciascuna con un Responsabile
di Squadra (RS). Le SQ sono permanentemente assegnate ai quartieri
e controllate dal CQ competente.
4. Mezzi Antineve (MA). I MA sono controllati da CC.
5. Un sistema esterno preesistente per la gestione dei mezzi pubblici
(GP), che è in grado di rilevare la regolarità dei transiti dei mezzi e di
segnalare eventuali situazioni di emergenza (blocco del mezzo)
indicando la via in cui un’anomalia si verifichi. GP si appoggia su una
mappa cartografica della città.
6. Vi è inoltre un sistema esterno preesistente per le previsioni meteo
(PM), che è accessibile attraverso un servizio web.
Il Problema
● Un centro di coordinamento CC che ha il compito di:
1. Allertare entro le ore 24 di ogni giorno, in base alle previsioni meteo,
CQ e MA, pianificando le attività dei MA.
2. Rivedere in tempo reale le attività dei MA, a fronte di segnalazioni di
emergenza provenienti da GP o da CQ.
3. Comunicare a Enti esterni (servizio sanitario, forze dell’ordine,
protezione civile) l’insorgere di eventuali situazioni di emergenza
grave.
● Ogni Centro di Quartiere CQ ha il compito di:
1. Pianificare dinamicamente le attività delle SQ in base alla situazione di
specifiche vie rilevata dai RS, alla pianificazione dei MA e all’insorgere
di situazioni di emergenza.
2. Interagire con i RS per comunicare la pianificazione e per acquisire
informazioni sullo stato della viabilità e sulla presenza di eventuali
situazioni di emergenza.
Assunzioni
● L'emergenza neve inizia con l'arrivo di un bollettino meteo
che annunci neve e con la pianificazione delle attività. A
partire dal quel momento la pianificazione viene aggiornata
ad intervalli temporali prefissati e al sorgere di situazioni
particolarmente gravi.
● L'algoritmo di pianificazione degli MA utilizza le seguenti
informazioni:
○ Il bollettino meteo
○ Posizione degli MA
○ Tipologia degli MA
○ Segnalazioni Aperte
○ Il lavoro che attualmente stanno svolgendo e il tempo
stimato di completamento
● Nel caso particolare della prima pianificazione, vengono
utilizzati solamente:
○ Tipologia degli MA (si presuppone che siano tutti in
deposito)
Assunzioni
● L'algoritmo di pianificazione delle SQ utilizza le stesse
informazioni ad eccezione della tipologia degli MA. Inoltre
necessita anche della composizione delle varie squadre
● Dato che gli algoritmi di pianificazione sono generalmente
piuttosto lenti e che le emergenze vanno risolte nel minor
tempo possibile, è stata introdotta una "pianificazione
urgente". Questa, tenendo conto della pianificazione
corrente, assegna risorse per la risoluzione dell'emergenza.
● Si presuppone che, dovendo ripianificare una sola attività e
avendo già a disposizione una pianificazione, sia molto più
veloce di quella ordinaria.
● I MA si possono guastare, in tal caso lo segnalano al CC
Assunzioni
● I centri di quartiere iniziano la pianificazione non appena ne
ricevono una nuova dal CC. Anche loro possono effettuare
una "pianificazione urgente".
● In caso di emergenza, solamente i CQ interessati effettuano
la ripianificazione.
Assunzioni
● Le segnalazioni possono riguardare situazioni di differente
gravità.
● I livelli di gravità massimi sono definiti "Emergenza" e
"Emergenza Grave"
● Per "Emergenza" si intende una situazione che deve essere
risolta in breve tempo
● Per "Emergenza Grave" si intende una situazione che deve
essere risolta in breve tempo e che necessita dell'intervento
anche di enti esterni
● Entrambe, data la loro urgenza, necessitano sempre
dell'intervento di Mezzi Antineve
● Il GP è in grado di segnalare al nostro sistema
un'emergenza
● Ciascun centro di quartiere può avere più squadre di
quartiere
Architettura Software
Who & Where
Who & Where
What
How, Why, When - Controllo Meteo e
Pianificazione
How, Why, When - Pianificazione MA
How, Why, When - Pianificazione SQ
How, Why, When - Segnalazione RS
How, Why, When - Segnalazione a CC
How, Why, When - Comunicazioni MA
How, Why, When - Comunicazioni RS
Architettura Logica
Architettura Logica
Architettura Logica
Architettura Logica
Architettura Concreta
Architettura Concreta
Architettura Concreta
Architettura Concreta
Architettura Concreta
Architettura Concreta
Architettura Concreta
Architettura di Deployment - Soluzione 1
Architettura di Deployment - Soluzione 2
Infrastruttura Hardware
Collegamento tra RS e CQ
Il collegamento potrebbe avvenire tramite due diverse
tecnologie:
● Sfruttando la rete UMTS
● Costruendo una rete WiFi Mesh
Vediamo i vantaggi e gli svantaggi di queste soluzioni
Rete UMTS
Bitrate: 2 Mb/s (in pratica è generalmente più basso)
Vantaggi:
● Nessuna infrastruttura da costruire
Svantaggi:
● E' una rete pubblica e potrebbe intasarsi
● Se, a causa di fortissime nevicate, dovessero esserci dei
guasti all'infrastruttura, il sistema sarebbe pesantemente
compromesso
● Bisogna pagare un operatore
● Non tutte le città italiane sono ben coperte
Rete WiFi Mesh
Si tratta di coprire tutta la città tramite una rete Wifi (802.11.n)
costituita da tanti hotspot (ad esempio posizionati sui semafori)
che comunicano tra di loro. La soluzione è già stata adottata da
altre città per esigenze analoghe. In alcuni casi, per estendere
la copertura, sono stati installati degli hotspot anche su dei
veicoli.
Vantaggi:
● Molto veloce (54 Mb/s)
● In caso di guasto ad un hotspot la rete non viene
interamente compromessa
Svantaggi:
● Infrastruttura costosa
Si è optato per la seconda soluzione per via della sua estrema
robustezza e affidabilità (caratteristiche molto importanti per un
sistema di gestione di emergenze).
Si noti che la stessa rete potrebbe venir condivisa con altri enti
(polizia, 118, protezione civile), in modo da suddividere il costo
di installazione.
Se nella città fosse già presente una rete wifi municipale si
potrebbe usare (al limite espandendone la copertura) quella.
Tropos 1410
Wireless Mesh
Router & Bridge
Ad Oklahoma City l'infrastruttura è costata 5 milioni
di dollari per una superficie di 1437 Km^2. Si noti
che Milano ha una superficie di 181 Km^2, mentre
Roma di 1285 Km^2.
Collegamento tra MA e CC
Avviene tramite la stessa rete utilizzata dagli RS
Device
Sia RS che MA avranno uno smartphone, dotato di Wifi e GPS,
sul quale verrà installata l'applicazione mediante la quale
possono essere fatte segnalazioni, si può comunicare l'inizio o
la conclusione di un task e sul quale riceveranno la
pianificazione.
L'applicazione non è particolarmente esigente in termini di
risorse, quindi si può optare anche per modelli economici.
Una caratteristica da tenere in considerazione, invece, è la
durata della batteria.
Samsung GT-5570 con Android 2.2.1
99 euro
Samsung GT-B5510 con Android 2.3.5
129 euro
Collegamento tra CQ e CC
● Si può sfruttare la stessa rete Wifi
● Alcune alternative possono essere:
○ Ponti radio
○ Una VPN
I Server
Nel CC e in ogni CQ sarà presente un server (o un cluster di
servers) su cui risiederanno il gestore della comunicazione e
della pianificazione, oltre ai vari datastore. Questi componenti
saranno installati ciascuno su una diversa macchina virtuale.
Per la virtualizzazione si è scelto di usare l'Hypervisor Xen,
dato che permette di ottenere prestazioni molto vicine a quelle
che si otterrebbero in assenza di virtualizzazione ma, allo
stesso tempo, permette di effettuare il load balancing e di
tenere separate le varie componenti applicative.
Alcune considerazioni...
● E' necessario che la pianificazione venga effettuata nel
minor tempo possibile (soprattutto quella di emergenza)
● Gli algoritmi di pianificazione sono generalmente
abbastanza lenti e "affamati" di risorse
● Scegliere dei server adeguati è quindi di fondamentale
importanza per il sistema
● Purtroppo è impossibile farlo senza conoscere l'algoritmo di
pianificazione
● Vengono comunque fornite delle soluzioni a scopo di
esempio
Base:
PowerEdge M710 Blade Server
Processore:
Intel Xeon X5690, 6C, 3.46GHz, 12M Cache, 6.40GT/s, 130W TDP, Turbo, HT,
DDR3-1333MHz
Processore aggiuntivo:
Intel Xeon X5690, 6C, 3.46GHz, 12M Cache, 6.40GT/s, 130W TDP, Turbo, HT,
DDR3-1333MHz
Memoria:
64GB Memory for 2 CPUs, DDR3, 800MHz (16x4GB Single Ranked LV RDIMMs),
Using 1333MHz DIMMs
Configurazione dei dischi rigidi:
C6 - RAID 5 using CERC 6, 3-4 SAS HDDs
Primo disco rigido:
300GB, SAS 6Gbps, 2.5-in, 10K RPM Hard Drive (Hot Plug) x 5
Tipo di NIC incorporata (fabric A):
Embedded Four Port Ethernet Gigabit Controller with 4P TOE and iSCSI Offload
for Fabric A
Costo:
6753 €
Base:
PowerEdge M710 Blade Server
Processore:
Intel Xeon X5690, 6C, 3.46GHz, 12M Cache, 6.40GT/s, 130W TDP, Turbo, HT,
DDR3-1333MHz
Memoria:
24GB Memory for 1 CPU, DDR3, 1333MHz (6x4GB Single Ranked LV RDIMMs)
Configurazione dei dischi rigidi:
C6 - RAID 5 using CERC 6, 3-4 SAS HDDs
Primo disco rigido:
146GB, SAS 6Gbps, 2.5-in, 10K RPM Hard Drive (Hot Plug) x 5
Tipo di NIC incorporata (fabric A):
Embedded Four Port Ethernet Gigabit Controller with 4P TOE and iSCSI Offload
for Fabric A
Costo:
4238 €
Scegliendo una CPU meno performante e rinunciando al RAID il
costo scende a 1829 €
Intel Xeon E5620, 4C, 2.40GHz, 12M Cache, 5.86GT/s, 80W TDP, Turbo,
HT, DDR3-1066MHz
Interazione con gli utenti e relativi levelli
di servizio
Gli utenti del sistema quali operatori sul campo RS e operatori sul mezzo MA
utilizzeranno un'applicazione sul dispositivo smartphone. (Es. applicazione
Android)
La robustezza del sistema viene garantita dall'utilizzo di dischi rigidi configurati
in RAID, dalla presenza di ridondanza per alcuni dati del db e dalla rete WiFi
Mesh.
I tempi di risposta, per quanto riguarda le segnalazioni, sono pesantemente
dipendenti dalla congestione della rete. Per questo motivo si è optato per una
rete dedicata che dovrebbe garantire, anche nella peggiore delle situazioni, dei
tempi molto brevi (secondi).
Per quanto riguarda il calcolo della pianificazione, i tempi di risposta dipendono
molto dall'hardware e dalla quantità di segnalazioni.
Per venire incontro alla necessità di interventi rapidi è stata introdotta la
"pianificazione urgente"
Architettura Database
Lo smartphone, per trasmettere i dati sulle segnalazioni al CQ
o al CC, usa il formato XML
<?xml version="1.0" encoding="UTF-8" ?>
<segnalazione>
<tipo>Forte accumulo di neve</tipo>
<gravità>6</gravità>
<posizione>
<via>Via San Marco</via>
<civico>16</civico>
</posizione>
<timestamp>04:01:1012:13:43</timestamp>
</segnalazione>
Inoltre ricevono la pianificazione a loro relativa in formato XML
<?xml version="1.0" encoding="UTF-8" ?>
<pianificazione timestamp="03:02:2012:14:56">
<task>
<descrizione>Descrizione del task 1</descrizione>
<posizione>
<via>Viale Sarca</via>
<civico>43</civico>
</posizione>
<durata>01:20</durata>
</task>
<task>
<descrizione>Descrizione del task 2</descrizione>
<posizione>
<via>Piazza della Scienza</via>
<civico>2</civico>
</posizione>
<durata>00:30</durata>
</task>
</pianificazione>
Assunzioni e Premesse
● Il sistema per la gestione degli interventi in caso di neve
(SN) contiene tutte le vie della città
● Il sistema GP contiene informazioni relative alla città in cui
installeremo il sistema
● I due sistemi SN e GP sono integrati tramite VDI (Virtual
Data Integration)
● Il mapping tra lo schema globale e gli schemi locali sarà un
GAV (Global As View)
Schema concettuale SN
Schema logico relazionale SN
Campi chiave: sottolineati.
Campi chiavi esterne: colore blu.
Task ( Id, Descrizione, Stato, Durata, OraInizio, Ordine,
IdPianificazione, IdSQ, IdMA, IdSegnalazione )
Segnalazione ( Id, Tipo, Stato, Gravità, Timestamp)
SegnalazioneChiusa ( idSegnalazione) // Chiave primaria ed
esterna
PosizioneSegnalazione ( IdSegnalzione, IdStrada, Civico)
PosizioneTask ( IdTask, IdStrada, Civico )
Schema logico relazionale SN
Quartiere ( Id, nome )
Strada ( Nome, Tipologia, IdQuartiere )
SQ ( Id, NomeRS, CognomeRS, IdQuartiere)
MA ( Id, Tipo, Stato )
Pianificazione ( Id, Timestamp, IdQuartiere) //Se idQuartiere è
null allora la Pianificazione è di MA
Dettaglio schema logico relazionale SN
TASK
POSIZIONESEGNALAZIONE
Id: numerico
Descrizione: string
Stato: boolean - aperto/chiuso
Durata: esperessa in ore e minuti
OraInizio: time
Ordine: numerico
IdPianificazione: numerico//chiave esterna Pianificazione
IdSQ: numerico//chiave esterna SQ
IdMA: string//chiave esterna MA
IdSegnalazione: numerico//chiave esterna Segnalazione
IdSegnalazione: numerico //chiave esterna segnalazione
IdStrada: string //chiave esterna strada
Civico: numerico
POSIZIONETASK
IdTask: numerico
IdStrada: string //chiave esterna strada
Civico: numerico
QUARTIERE
SEGNALAZIONE
Id: numerico
Tipo: string. Es: forti accumuli di neve, leggeri accumuli di neve,
strada ghiacciata, necessario sale, veicolo bloccato, ecc...
Stato: boolean - aperto/chiuso
Gravità: numerico (1-5 segnalazione non emergenza, 6 emergenza,
7 emergenza grave)
Timestamp: time ( gg:mm:yyyy:hh:mm )
SEGNALAZIONECHIUSA
IdSegnalazione: numerico //chiave esterna segnalazione
Id: numerico
nome: string
STRADA
Nome: string
Tipologia: string ( es. vicolo, piazza, una corsia, due corsie )
IdQuartiere: numerico //chiave esterna quartiere
Dettaglio schema logico relazionale SN
SQ
Id: numerico
NomeRS: string
CognomeRS: string
IdQuartiere: numerico//chiave esterna quartiere
MA
Id: string ( è la targa del mezzo antineve )
Tipo: string ( spargisale, spazzaneve...)
Stato: numerico (1- attivo, 2- guasto, 3- in
magazzino )
PIANIFICAZIONE
Id: numerico
Timestamp: time ( gg:mm:yyyy:hh:mm )
IdQuartiere: numerico //Se idQuartiere è null la
Pianificazione è di MA se invece è presente l'Id
del quartiere è del quartiere associato
Schema concettuale GP
Schema logico relazionale GP
Campi chiave: sottolineati.
Campi chiavi esterne: colore blu.
Veicolo (Targa, Tipologia)
Autista (Id, Cognome, Nome)
Ticket (Id, Descrizione, Aperto, Tipologia, Emergenza, Timestamp)
VeicoloBloccato (IdTicket, TargaVeicolo) //Chiavi esterne e chiave
CoordinateGps (Id, Long, Lat)
PosizioneTicket (IdTicket, IdCoordinate)//Chiavi esterne e chiave
Schema logico relazionale GP
Fermata ( Id, Nome )
FermataSiTrova (IdFermata, IdCoordinate)//Chiavi esterne e
chiave
Guida (TargaVeicolo, IdAutista)
CorsaFaFermata (IdCorsa, IdFermata, OraDiPassaggio)
Lista (IdPercorso, IdFermata, Ordine, Inizio, Fine)
Linea (Id, Descrizione)
Percorso (Id, Nome, IdLinea)
Corsa (Id, OraDiPartenza, OraDiArrivo, data, IdPercorso,
TargaVeicolo)
Dettaglio schema logico relazionale GP
VEICOLO
Targa: string
Tipologia: string (tram, autobus, snodato, filobus)
AUTISTA
Id: numerico
Cognome :string
Nome: string
TICKET
IdTicket: numerico
Descrizione: string
Aperto: boolean - true/false
Tipologia: string ( “guasto motore”, “foratura”, “guasto
elettronico” etc )
Emergenza: boolean - true/false
Timestamp: time ( gg:mm:yyyy:hh:mm )
VEICOLOBLOCCATO
IdTicket: numerico// Chiave esterna Ticket
TargaVeicolo: string// Chiave esterna Veicolo
COORDINATEGPS
Id: numerico
Long: gradi, minuti, secondi, char
Lat: gradi, minuti, secondi, char
POSIZIONETICKET
Id: numerico// Chiave esterna Ticket
IdCoordinate: numerico// Chiave esterna CoordinateGps
FERMATA
Id: numerico
Nome: string
FERMATASITROVA
IdFermata: numerico // Chiave esterna Fermata
IdCoordinate: numerico// Chiave esterna CoordinateGps
GUIDA
TargaVeicolo: string// Chiave esterna Veicolo
IdAutista: numerico// Chiave esterna Autista
CORSAFAFERMATA
IdCorsa: numerico// Chiave esterna Corsa
IdFermata: numerico// Chiave esterna Fermata
OraDiPassaggio: time ( gg:mm:yyyy:hh:mm )
LISTA
IdPercorso: numerico// Chiave esterna Percorso
IdFermata: numerico// Chiave esterna Fermata
Ordine: numerico
Inizio: boolean - true/false
Fine: boolean – true/false
Dettaglio schema logico relazionale GP
LINEA
Id: numerico
Descrizione: string
PERCORSO
Id: numerico
Nome: string
IdLinea: numerico// Chiave esterna Linea
CORSA
Id: numerico
OraDiPartenza: time ( gg:mm:yyyy:hh:mm )
OraDiArrivo: time ( gg:mm:yyyy:hh:mm )
data: date (gg:mm:yyyy)
IdPercorso: numerico// Chiave esterna Percorso
TargaVeicolo: string // Chiave esterna Veicolo
Entità integrate: Ma con Veicolo
Tabelle coinvolte:
SN: MA (Id, Tipo, Stato)
MA
Id: string (è la targa del mezzo antineve)
Tipo: string (spargisale, spazzaneve...)
Stato: numerico (1- attivo, 2- guasto, 3- in magazzino)
GP: Veicolo (Targa, Tipologia)
GP: VeicoloBloccato (IdTicket, TargaVeicolo)
VEICOLO
Targa: string
Tipologia: string ( bus di linea urbana, extraurbana, tram, snodato etc)
VEICOLOBLOCCATO
IdTicket: numerico// Chiave esterna Ticket
TargaVeicolo: string// Chiave esterna Veicolo
Mapping GAV tra schema integrato e schemi
locali
( SELECT V.Targa AS Id, V.Tipologia
AS Tipologia, 1
VISTA GLOBALE:
MezzoG (Id, Tipologia, Stato)
CREATE VIEW MezzoG AS
( SELECT V.Targa AS Id, V.Tipologia AS
Tipologia, 2
FROM Veicolo V
JOIN VeicoloBloccato VB ON V.targa =
VB.targa
UNION
FROM Veicolo V
EXCEPT
SELECT V.Targa AS Id, V.Tipologia
AS Tipologia, 1
FROM Veicolo V JOIN VeicoloBloccato
VB ON V.targa = VB.targa ))
UNION
SELECT M.Id AS Id, M.Tipo AS
Tipologia, M.stato AS Stato
FROM MA M
Mapping GAV tra schema integrato e
schemi locali-Strada e CoordinateGPS
VISTA GLOBALE:
StradaG ( Nome, Tipologia, IdQuartiere )
CREATE VIEW StradaG As
SELECT Nome, Tipologia, IdQuartiere
FROM Strada
Assumiamo che il db del SN abbia tutte le vie e i quartieri della
città memorizzati quindi si tratta solamente di un vista sulla
tabella Strada
Entità integrate: PosizioneSegnalazione in
SN e PosizioneTicket in GP
Tabelle coinvolte:
GP: PosizioneTicket (Id, IdCoordinate)
POSIZIONETICKET
Id: numerico //Chiave esterna Ticket
IdCoordinate: numerico //Chiave esterna
CoordinateGps
SN: PosizioneSegnalazione (Idsegnalazione, IdStrada,
Civico)
POSIZIONESEGNALAZIONE
IdSegnalazione: numerico //chiave esterna
segnalazione
IdStrada: string //chiave esterna strada
Civico: numerico
GP: CoordinateGps (Id, Long, Lat)
COORDINATEGPS
Id: numerico
Long: gradi, minuti, secondi, char
Lat: gradi, minuti, secondi, char
Mapping GAV tra schema integrato e schemi
locali
VISTA GLOBALE:
Posizione (Id, IdStrada, Civico)
CREATE VIEW Posizione As
SELECT PS.IdSegnalazione As Id, PS.IdStrada As IdStrada, PS.Civico As Civico
FROM PosizioneSegnalazione PS
UNION
SELECT PT. IdTicket As Id, getStreet ( C.Long, C.Lat ) As IdStrada, getCivico( C.Long, C.Lat
) As Civico
FROM PosizioneTicket PT JOIN CoordinateGps C ON PT.IdCoordinate=C.Id
DOVE:
getStreet e getCivico sono funzioni basate per esempio su servizi XML
quali google place xml oppure google geocoding xml.
Entità integrata: FermataSiTrova da GP
Tabelle coinvolte:
GP: FermataSiTrova (IdFermata, IdCoordinate)
FERMATASITROVA
IdFermata: numerico //Chiave esterna Fermata
IdCoordinate: numerico //Chiave esterna CoordinateGps
GP: CoordinateGps (Id, Long, Lat)
COORDINATEGPS
Id: numerico
Long: gradi, minuti, secondi, char
Lat: gradi, minuti, secondi, char
Mapping GAV tra schema integrato e schemi
locali
VISTA GLOBALE:
Trova (IdFermata, IdStrada)
CREATE VIEW Trova As
SELECT F.IdFermata, getStreet ( C.Long, C.Lat ) As IdStrada,
FROM FermataSiTrova F JOIN CoordinateGps C ON F.
IdCoordinate=C.Id
DOVE:
getStreet, è una funzione basata per esempio su servizi XML
quali google place xml oppure google geocoding xml.
Entità integrate Segnalazione con Ticket
Tabelle coinvolte:
GP: Ticket (Id, Descrizione, Aperto, Tipologia, Emergenza, Timestamp)
SN: Segnalazione (Id, Tipo, Stato, Gravità, Timestamp)
TICKET
IdTicket: numerico
Descrizione: string
Aperto: boolean - true/false
Tipologia: string (“guasto motore”, “foratura”, “guasto elettronico” etc)
Emergenza: boolean - true/false
Timestamp: time (gg:mm:yyyy:hh:mm)
SEGNALAZIONE
Id: numerico
Tipo: string - forti accumuli di neve, leggeri accumuli di neve,strada ghiacciata, necessario
sale, veicolo bloccato, etc...
Stato: boolean - aperto/chiuso
Gravità: numerico (1-5 segnalazione non emergenza, 6 emergenza, 7 emergenza grave)
Timestamp: time (gg:mm:yyyy:hh:mm)
Mapping GAV tra schema integrato e schemi
locali
Vista di supporto:
TicketS ( Id, Descrizione, Aperto, Tipologia, Gravità, Timestamp )
CREATE VIEW TicketS As
SELECT T.Id As Id, T.Descrizione As Descrizione, T.Aperto As Aperto, T.Tipologia As
Tipologia, 6, T.Timestamp As Timestamp
FROM Ticket T
WHERE T.Emergenza=true
UNION
SELECT T.Id As Id, T.Descrizione As Descrizione, T.Aperto As Aperto, T.Tipologia As
Tipologia, 3, T.Timestamp As Timestamp
FROM Ticket T
WHERE T.Emergenza=false
Mapping GAV tra schema integrato e schemi
locali
VISTA GLOBALE:
SegnalazioneG ( Id, Tipo, Stato, Descrizione, Gravità, Timestamp )
Entità/viste coinvolte:
Segnalazione ( Id, Tipo, Stato, Gravità, Timestamp )
TicketS ( Id, Descrizione, Aperto, Tipologia, Gravità, Timestamp )
CRATE VIEW SegnalazioneG As
SELECT S.Id As Id, S.Tipo As Tipo, S.Stato As Stato, Null As Descrizione, S.Gravità As Gravità, S.
Timestamp As timestamp
FROM Segnalazione S
UNION
SELECT T.Id As Id,T.Tipologia As Tipo, T.Aperto As Stato, T.Descrizione As Descrizione,T.Gravità As
Gravità, T.Timestamp As Timestamp
FROM TicketS T
Eterogeneità
Oggetto 1
Oggetto 2
Tipo eterogeneità
Soluzione
MA.Id
Veicolo.Targa
Schema->
Nome->Sinonima
Ridenominazione in
Id
MA.Tipo
Ma.Tipologia
Schema->
Nome->Sinonima
Ridenominazione in
Tipo
Ma.Stato
VeicoloBloccato
Schema->Tipo->Struttura
Scelgo l'attributo
(IdTicket,TargaVeicolo)
Stato e trasformo la
Veicolo.Targa
relazione in attributo
PosizioneSegnalazione.
IdSegnalazione
PosizioneTicket.Id
Schema->
Nome->Sinonima
Ridenominazione in
Id
PosizioneSegnalazione.IdStrada
CoordinateGps (Id,
Long, Lat )
PosizioneTicket.Id
Schema->Tipo:Long e Lat Funzione getStreet
identificano una strada. (Long, Lat) basata su
Schema->
google geocoding e
Nome->Sinonimia
ridenominazione in
Schema->Tipo->struttura
IdStrada
PosizioneSegnalazione.Civico
CoordinateGps (Id,
Long, Lat )
Schema->Tipo:Long e Lat Funzione getCivico
identificano un Civico.
(Long, Lat) basata su
Schema->
google geocoding e
Nome->Sinonimia
ridenominazione in
Civico
Eterogeneità
Oggetto 1
Trova.IdStrada
Oggetto 2
Tipo eterogeneità
Soluzione
CoordinateGps (Id, Schema->Tipo:Long e Lat Funzione getStreet
Long, Lat )
identificano una strada.
(Long, Lat) basata su
FermataSiTrova.
Schema->
google geocoding e
IdCoordinate
Nome->Sinonimia
ridenominazione in
Schema->Tipo->struttura
IdStrada
Ticket.Aperto
Segnalazione.stato
Schema->
Nome->Sinonima
Ridenominazione in
Stato
Ticket.Tipologia
Segnalazione.Tipo
Schema->
Nome->Sinonima
Ridenominazione in
Tipo
Ticket.Emergenza
Segnalazione.
Gravità
Schema->Tipo->dominio
Schema->
Nome->Sinonima
Se c'è emergenza
diventa gravità = 6
altrimenti se non c'è
emergenza diventa
gravità = 3 e
ridenominazione in
Gravità
Schema concettuale integrato
Schema logico relazionale integrato
SegnalazioneG ( Id, Tipo, Stato, Descrizione, Gravità,
Timestamp )
Trova (IdFermata, IdStrada)
Posizione (Id, IdStrada, Civico)
StradaG (Nome, Tipologia, IdQuartiere)
MezzoG (Id, Tipologia, Stato)
Dettaglio schema logico relazionale
integrato
SEGNALAZIONEG
TROVA
Id: numerico
Tipo: string ( “guasto motore”, “foratura”, “guasto elettronico”, "forti accumuli di neve",
"leggeri accumuli di neve" etc )
Stato: boolean - aperto/chiuso
Descrizione: string
Gravità: numerico (1-5 emergenza non grave, 6 emergenza, 7 emergenza grave)
Timestamp: time ( gg:mm:yyyy:hh:mm )
IdFermata :numerico
IdStrada : string
STRADAG
Nome: string
Tipologia: string ( es. vicolo, piazza, viale, una carreggiata, due corsie )
IdQuartiere: numerico
MEZZOG
Id: string
Tipologia: string ( spargisale, spazzaneve, tram, autobus, snodato, filobus etc )
Stato: numerico (1- attivo, 2- guasto, 3- in magazzino )
POSIZIONE
Id: numerico
IdStrada: string
Civico: numerico
Tabella delle frequenze
Operazione
Tabelle coinvolte
Frequenza
Pianificazione CC - CQ
Pianificazione,Task,
SegnalazioneG,
PosizioneTask,
PosizioneSegnalazione,
MezzoG
32/g
Pianificazione urgente
CC - CQ
Pianificazione,Task
PosizioneTask,
MezzoG
9/g
Segnalazione RS
SegnalazioneG,
PosizioneSegnalazione
540/g
Aggiornamento Task
iniziato - finito RS
Task,SegnalazioneG,
SegnalazioneChiusa
2880/g
Aggiornamento Task
iniziato - finito MA
Task,SegnalazioneG,
SegnalazioneChiusa
3200/g
Ipotizzando 9 quartieri con 20 squadre in media per quartiere
dislocati su una superfiecie di circa 180 Km^2 (Es. Milano)
Vantaggi - Svantaggi distribuzione base
di dati
La distribuzione della base dati nei centri di quartiere piuttosto che nel centro di coordinamento dipende
sia dall'architettura di deployment sia dalle frequenze con il quale un utente accede ad una o ad un
gruppo di tabelle, sia dai livelli di servizio che vogliamo garantire o sono richiesti, sia dall'infrastruttura di
telecomunicazione di supporto e dal budget a disposizione.
I fattori che nel nostro caso hanno più peso sono relativi all'architettura di deployment, i livelli di servizio
intesi come continuità di operatività in caso di guasto temporaneo della linea di telecomunicazione e di
conseguenza la relativa infrastruttura.
Una possibile distribuzione che qualitativamente è un buon compromesso tra i fattori sopra citati è la
seguente:
Tabella Segnalazione:
Il CC contiene la tabella con tutte le segnalazioni in quanto gli servono per la pianificazione,
mentre nei CQ troviamo la stessa tabella con le sole segnalazioni relative in quanto servono per la
pianificazione del quartiere che non verrebbe ritardata in caso di caduta temporanea della linea di
trasporto dati con il CC.
Le tabelle Segnalazione chiusa e PosizioneSegnalazione vengono trattate nello stesso modo della
tabella Segnalazione per le medesime motivazioni.
Vantaggi - Svantaggi distribuzione base
di dati
Tabella Quartiere:
Verrà posizionata nel CC
Tabella Pianificazione:
Si opererà una frammentazione orizzontale in modo da avere la pianificazione degli MA nel CC, mentre
quelle delle SQ nei CQ
Tabella MA:
Rimarrà nel CC
Tabella SQ:
Verrà frammentata orizzontalmente in maniera da avere i dati di una SQ nel CQ relativo
Tabella Task e posizione Task:
Anche in questo caso verrà effettuato un partizionamento orizzontale in modo da avere i Task e le
posizioni dei Task relativi agli MA nel CC, mentre quelli relativi alle SQ si troveranno nei rispettivi CQ
Vantaggi - Svantaggi distribuzione base
di dati
Tabella strada:
E' preferibile una tabella generale contenenti tutte le vie in CC e una tabella Strada per
ogni quartiere con le sole vie relative al quartiere in quanto i dati relativi al quartiere sono
direttamente accessibili alle attività del quartiere e i dati nel CC direttamente accessibili
dalle relative attività garantendo un maggior livello di robustezza con poco sforzo (infatti,
trattandosi di una tabella "statica" non si pone il problema di sincronizzare i vari dati).
Query 1
Si vuole sapere il numero di segnalazioni aperte per via.
SELECT ST.Nome, Count ( * )
FROM ( SegnalazioneG S JOIN Posizione P ON S.Id=P.Id ) SP
JOIN StradaG ST ON ST.Nome=SP.IdStrada
WHERE SP.Stato = true
GROUP BY ST.Nome
SegnalazioneG ( Id, Tipo, Stato, Descrizione, Gravità, Timestamp)
Posizione ( Id, IdStrada, Civico )
StradaG ( Nome, Tipologia, IdQuartiere )
TicketS ( Id, Descrizione, Aperto, Tipologia, Gravità, Timestamp )
Unfolding della query 1
SELECT ST.Nome, Count ( * )
FROM ( ( SELECT SE.Id As Id, SE.Tipo As Tipo, SE.Stato As Stato, Null As Descrizione, SE.Gravità As Gravità, SE.
Timestamp As timestamp
FROM Segnalazione SE
UNION
SELECT TI.Id As Id, TI.Tipologia as Tipo, TI.Aperto As Stato, TI.Descrizione As Descrizione,TI.Gravità As Gravità, TI.
Timestamp As Timestamp
FROM (
SELECT T.Id As Id, T.Descrizione As Descrizione, T.Aperto As Aperto, T.Tipologia As Tipologia, 6, T.Timestamp As
Timestamp
FROM Ticket T
WHERE T.Emergenza = true
UNION
SELECT T.Id As Id, T.Descrizione As Descrizione, T.Aperto As Aperto, T.Tipologia As Tipologia, 3, T.Timestamp As
Timestamp
FROM Ticket T
WHERE T.Emergenza = false ) TI ) S
Unfolding della query 1
JOIN
( SELECT PS.IdSegnalazione As Id, PS.IdStrada As IdStrada, PS.Civico As Civico
FROM PosizioneSegnalazione PS
UNION
SELECT PT. IdTicket As Id, getStreet ( C.Long, C.Lat ) As IdStrada, getCivico( C.Long, C.Lat ) As Civico
FROM PosizioneTicket PT JOIN CoordinateGps C ON PT.IdCoordinate = C.Id ) P
ON S.Id = P.Id ) SP
JOIN
( SELECT Nome, Tipologia, IdQuartiere
FROM Strada ) ST
ON ST.Nome = SP.IdStrada
WHERE SP.Stato = true
GROUP BY ST.Nome
Query 2
Si vuole identificare i mezzi che si sono guastati che hanno un task ancora
aperto e la relativa via
SELECT M.Id, M.Tipologia, S.Nome As Strada
FROM (( MezzoG M JOIN Task T ON T.IdMa=M.Id ) MT JOIN
PosizioneTask P ON MT.Id=P.IdTask ) MTP JOIN StradaG S
ON MTP.IdStrada = S.Nome
WHERE M.Stato=2 AND T.Stato=true
VISTE-TABELLE COINVOLTE:
MezzoG (Id, Tipologia, Stato)
Task ( Id, Descrizione, Stato, Durata, OraInizio, Ordine, IdPianificazione, IdSQ, IdMA, IdSegnalazione )
PosizioneTask ( IdTask, IdStrada, Civico )
StradaG ( Nome, Tipologia, IdQuartiere )
Unfolding della query 2
SELECT MZ.Id, MZ.Tipologia, S.Nome As Strada
FROM (((( SELECT V.Targa AS Id, V.Tipologia AS Tipologia, 2
FROM Veicolo V JOIN VeicoloBloccato VB ON V.targa = VB.targa
UNION
( SELECT V.Targa AS Id, V.Tipologia AS Tipologia, 1
FROM Veicolo V
EXCEPT
SELECT V.Targa AS Id, V.Tipologia AS Tipologia, 1
FROM Veicolo V JOIN VeicoloBloccato VB ON V.targa = VB.targa ))
UNION
Unfolding della query 2
SELECT M.Id AS Id, M.Tipo AS Tipologia, M.stato AS Stato
FROM MA M ) MZ
JOIN Task T ON T.IdMa = MZ.Id ) MT
JOIN PosizioneTask P ON MT.Id=P.IdTask ) MTP
JOIN
( SELECT Nome, Tipologia, IdQuartiere
FROM Strada) S ON MTP.IdStrada = S.Nome
WHERE MZ.Stato = 2 AND T.Stato = true
Query 3
Si vuole elencare tutte le segnalazioni aperte per un determinato quartiere (
IdQuartiere = 1 )
SELECT *
FROM ( SegnalazioneG S JOIN Posizione P ON S.Id = P.Id )
SP JOIN StradaG ST ON ST.Nome = SP.IdStrada
WHERE SP.Stato = true AND ST.IdQuartiere=1
SegnalazioneG ( Id, Tipo, Stato, Descrizione, Gravità, Timestamp)
Posizione ( Id, IdStrada, Civico )
StradaG ( Nome, Tipologia, IdQuartiere )
TicketS ( Id, Descrizione, Aperto, Tipologia, Gravità, Timestamp )
Unfolding della query 3
SELECT *
FROM ( ( SELECT SE.Id As Id, SE.Tipo As Tipo, SE.Stato As Stato, Null As Descrizione, SE.Gravità As Gravità, SE.Timestamp
As timestamp
FROM Segnalazione SE
UNION
SELECT TI.Id As Id, TI.Tipologia as Tipo, TI.Aperto As Stato, TI.Descrizione As Descrizione,TI.Gravità As Gravità, TI.
Timestamp As Timestamp
FROM (
SELECT T.Id As Id, T.Descrizione As Descrizione, T.Aperto As Aperto, T.Tipologia As Tipologia, 6, T.Timestamp As Timestamp
FROM Ticket T
WHERE T.Emergenza = true
UNION
SELECT T.Id As Id, T.Descrizione As Descrizione, T.Aperto As Aperto, T.Tipologia As Tipologia, 3, T.Timestamp As Timestamp
FROM Ticket T
WHERE T.Emergenza = false ) TI ) S
Unfolding della query 3
JOIN
( SELECT PS.IdSegnalazione As Id, PS.IdStrada As IdStrada, PS.Civico As Civico
FROM PosizioneSegnalazione PS
UNION
SELECT PT. IdTicket As Id, getStreet ( C.Long, C.Lat ) As IdStrada, getCivico( C.Long, C.Lat ) As Civico
FROM PosizioneTicket PT JOIN CoordinateGps C ON PT.IdCoordinate = C.Id ) P
ON S.Id = P.Id ) SP
JOIN
( SELECT Nome, Tipologia, IdQuartiere
FROM Strada ) ST
ON ST.Nome = SP.IdStrada
WHERE SP.Stato = true AND ST.IdQuartiere = 1