Architetture
del software e dei dati
Appello del 24/2/2016
Università degli Studi di Milano-Bicocca Dipartimento di
Informatica Sistemistica e Comunicazione
Magrinelli Andrea - 736358
Secci Stefano - 756610
Ceresa Nausica - 708917
ANALISI DEL PROBLEMA
Studio del problema
Il sistema di Osservazione del Comportamento degli Automobilisti (OCA) deve:
Fornire assistenza in caso di sinistro:
Riconoscimento di eventuali sinistri (collisioni);
Notifica all’operatore competente delle informazioni necessarie per organizzare
l’assistenza;
Attivazione di una connessione telefonica tra operatore e assicurato coinvolto
Inviare i soccorsi sul luogo dell’incidente
Studio del problema
Consentire all’operatore di visualizzare, per ciascun assicurato e per ciascuna
polizza, le attuali condizioni di polizza e il livello di rischio dell’assicurato.
Calcolare il livello di rischio R di ciascun assicurato:
R= f(K,V,P,D,E,C)
Dove:
D: numero denunce di sinistro;
E: età dell’assicurato;
C: comune di residenza;
Consentire di ridefinire per ciascuna polizza su base annuale:
Il chilometraggio totale K;
La velocità media V per ciascuna tipologia di tronco viario;
Il livello di prudenza P definito come la percentuale di chilometri percorsi rispettando i
limiti di velocità con una tolleranza di 10 km/h.
Acronimi
OCA : sistema di Osservazione del Comportamento
degli Automobilisti.
ACC : sensore di accelerazione (accelerometro).
TAC : sensore di velocità (tachimetro).
GPS : sensore di posizione
BDG : Base Dati Geografica
BDA : Una Base Dati Assicurati
Ambiguità
Qual è il target del sistema? (Regionale o nazionale)
Gli operatori, hanno ruoli assegnati?(ex: un operatore destinato a
gestire le polizze e uno destinato a gestire sinistri)
Che tipologia di incidenti vengono gestiti?
Qual è il limite minimo di decelerazione per far partire
autonomamente la segnalazione?
L’utente può inviare manualmente la segnalazione?
Quali parametri contiene la segnalazione incidente?
Quanti sono i clienti della compagnia di assicurazioni?
Quanti sono i veicoli assicurati dalla compagnia e quali?
ASSUNZIONI
Assunzioni generali
Il target del sistema OCA è a livello regionale (Regione
Lombardia)
Gli operatori sono divisi in due categorie: operatore sinistri e
operatori polizze
I veicoli assicurati con OCA sono automobili, camion, camper,
autobus, pullman. Sono esclusi rimorchi.
Assunzioni sui sinistri
L’accelerometro fornisce dati utili al rilevamento di impatti
Gli incidenti che rientrano nelle casistiche del sistema,
riguardano frontali, tamponamenti e ribaltamenti dei veicoli,
solo in caso venga superato il valore di soglia stabilito dalla
compagnia (variabile)
Il guidatore assicurato non può inviare manualmente la
segnalazione di sinistro.
Assunzioni sulle polizze e livello di rischio
La quotazione del premio assicurativo viene calcolata sui dati
dell’assicurato, cioè colui che ha stipulato la polizza con la
compagnia;
Le polizze contenute in BDA sono riferite all’anno corrente e ad ogni
rinnovo il numero di polizza rimane invariato
Al rinnovo di una polizza il livello di rischio R viene calcolato
basandosi sugli ultimi 12 mesi di ciascuna polizza dell’assicurato
indipendentemente dalla loro scadenza
Il livello di rischio R può essere ricalcolato e visualizzato in qualsiasi
momento ma viene salvato, sovrascrivendo il dato precedente, solo
alla scadenza di ognuna delle polizze sottoscritte.
Stime
I veicoli assicurati dalla compagnia sono 1 milione 500 mila (in Lombardia
6 milioni di veicoli secondo Statistiche ACI 2014)
Il sistema OCA è utilizzato dalla compagnia assicurativa su un milione di
assicurati;
L’assicurazione ha tre agenzie per ogni provincia dove lavorano gli
operatori polizze, mentre gli operatori sinistri sono collocati nella sede
principale nel capoluogo (Milano)
Ogni agenzia ha 4 operatori polizze e la sede centrale ha 100 operatori
sinistri, quindi:
Operatori polizze: 4(operatori)x12(numero province)x3(agenzie per
provincia)=144
Operatori sinistri: 100
Vincoli funzionali
La rilevazione del percorso avviene ad ogni accensione del veicolo
ed i dati vengono inviati ogni volta che il veicolo viene spento.
Il rilevamento delle collisioni viene notificato all’operatore
competente, il quale sarà messo in contatto con l’assicurato e
qualora lo ritenesse necessario, provvederà all’invio di soccorsi.
Il sistema OCA deve inoltre:
Calcolare il KVP per percorso e generare dunque il report mensile al fine di
calcolare il valore di rischio R aggiornato.
Visualizzare lo stato di ogni di ogni polizza e il valore di rischio R alla data
odierna.
Rinnovare la polizza in base a R
Vincoli non funzionali
Il sistema OCA è attivo 24h su 24h, tutti i giorni dell’anno
I rilevamenti di velocità e posizione vengono effettuati ogni 5 secondi.
I dati del sensore ACC sono campionati ogni 0,1 secondi, questo dovrebbe
premettere di rilevare la collisione nel momento in cui avviene (secondo i
dati ACI una collisione avviene in 1/10 secondo);
Use Case
Diagram
Modello
dei dati
AD 1 - Rilevamento Posizione Velocità
AD 2 - Creazione Percorso
AD 3 - Rileva Collisione
AD 4 - Riceve Segnalazione Collisione
AD 5 - Riceve Percorso
AD 6 - Calcolo KVP Mensili
AD 7 – Rinnova Polizza
AD 7.1 - Ricalcolo Livello Rischio
AD 7.2 - Calcolo KVP Annuale
AD 8 - Visualizza Polizza
AD 9 - Visualizza Livello Rischio
ARCHITETTURA LOGICA
Suddivisione in componenti
Gestore polizze
• Rinnova polizze
• Visualizza polizza
• Visualizza livello di rischio
Gestore dati sensori
•
Riceve percorso
Gestore Sensori
• Rileva collisione
• Crea percorso
Gestore KVP mensile
•
Calcola KVP mensile
Gestore Sinistri
• Riceve segnalazione
collisione
Partizionamento: Gestore Sensori
FOOTPRINT : Gestore Sensori
ABSTRACTION
10
COMPLEXITY
35
Gestore Sensori
ABSTRACTION
100
SHARING
FREQUENCY
80
COMPLEXITY
60
40
40
DELAY
30
LOCATION
10
EXTRA FLOW
80
INTRA FLOW
0
SHARING
20
20
INTRA FLOW
FREQUENCY
0
EXTRA FLOW
DELAY
LOCATION
Partizionamento: Gestore Sinistri
FOOTPRINT : Gestore Sinistri
ABSTRACTION
30
COMPLEXITY
20
Gestore Sinistri
ABSTRACTION
100
SHARING
FREQUENCY
80
COMPLEXITY
60
20
40
DELAY
20
LOCATION
10
EXTRA FLOW
50
INTRA FLOW
10
SHARING
50
20
INTRA FLOW
FREQUENCY
0
EXTRA FLOW
DELAY
LOCATION
Partizionamento: Gestore Dati Sensori
FOOTPRINT : Gestore Dati Sensori
ABSTRACTION
10
COMPLEXITY
10
Gestore Dati Sensori
ABSTRACTION
100
SHARING
FREQUENCY
10
80
COMPLEXITY
60
40
DELAY
20
LOCATION
10
EXTRA FLOW
10
INTRA FLOW
10
SHARING
60
20
INTRA FLOW
FREQUENCY
0
EXTRA FLOW
DELAY
LOCATION
Partizionamento: Gestore KVP Mensile
FOOTPRINT : Gestore KVP Mensile
ABSTRACTION
10
COMPLEXITY
10
Gestore KVP Mensile
ABSTRACTION
100
SHARING
FREQUENCY
80
COMPLEXITY
60
10
40
DELAY
10
LOCATION
10
EXTRA FLOW
5
INTRA FLOW
10
SHARING
80
20
INTRA FLOW
FREQUENCY
0
EXTRA FLOW
DELAY
LOCATION
Partizionamento: Gestore Polizze
FOOTPRINT : Gestore Polizze
ABSTRACTION
40
COMPLEXITY
50
Gestore Polizze
ABSTRACTION
100
SHARING
FREQUENCY
80
COMPLEXITY
60
50
40
DELAY
50
LOCATION
20
EXTRA FLOW
50
INTRA FLOW
30
SHARING
80
20
INTRA FLOW
FREQUENCY
0
EXTRA FLOW
DELAY
LOCATION
FOOTPRINT Complessivo
Kiviat Chart
ABSTRACTION
COMPLEXITY
20
ABSTRACTION
100
30
SHARING
FREQUENCY
30
80
COMPLEXITY
60
40
DELAY
30
LOCATION
10
EXTRA FLOW
40
INTRA FLOW
10
SHARING
60
20
INTRA FLOW
FREQUENCY
0
EXTRA FLOW
DELAY
LOCATION
PRO E CONTRO DELLA SOLUZIONE
Per l’analisi che è stata effettuata, si è scelto di utiizzare 5 gestori complessivi, in
modo tale da raccogliere alcune attività comuni in un unico Gestore.
Gestore Sensori: Si occuperà di raccogliere i dati del percorso e di eventuali collisioni.
Presenta una Frequenza e Complessità nella media, mentre è affetto da alto
ExtraFlow, dovuto all’alta interazione con attori differenti quali ACC, TAC, GPS.
Gestore Sinistri: si occupa solo di gestire la parte delle collisioni, è un componente a
sè stante.
Gestore Dati Sensori: viene eseguito in autonomia, non necessita di un attore
principale; permette di raccogliere le informazioni dai percorsi e di catalogarle.
Gestore KVP Mensile: Puramente indipendente, Unica nota è lo Sharing elevato.
Gestore Polizza: il più complesso in quanto racchiude tutte le attività che si possono
eseguire sulle polizze.
La media dei KVIAT Chart da luogo al Footprint Complessivo
ARCHITETTURA CONCRETA
Diagrammi di Sequenza delle varie Attività
Architettura di Deployment
Tipo di Comunicazione
Stime dei Costi
SD – Rileva Posizione e Velocità
SD – Creazione percorso
SD – Rileva
Collisione
SD – Riceve
Segnalazione
di Collisione
SD – Riceve
Percorso
SD – Calcola
KVP mensili
SD – Rinnova
Polizza
SD – Ricalcola Livello Rischio
SD – Calcola KVP Annuale
Deployment Soluzione 1
Analisi della soluzione 1
Disponiamo di due nodi “Centrali”, il server per le analisi che comprende il
gestore per il calcolo di KVP_Mensile e il Gestore per l’analisi dei dati
pervenuti dai device sulle automobili.
Questa soluzione permette di avere due nodi separati per il bilanciamento
del carico applicativo.
Deployment Soluzione 2
Analisi della soluzione 2
Nell’ottica di rimanere Cost-Effective e visto che la priorità del sistema è il
raccogilmento dei dati a fini di Rinnovo polizza (indicativamente una volta
l’anno), si può optare per una soluzione caratterizzata da un solo nodo
centrale che svolgerà le principali funzioni di elaborazione e di rimandare
ai nodi “remoti” situati nelle sedi assicurative il “Calcolo del Gestore
Polizze”.
Devices: BB
Al fine di raccogliere le informazioni dai sensori installati sul veicolo è
necessario installare sullo stesso una periferica che permetta la
comunicazione con il Body Computer installato su ogni autovettura.
Quest’ultimo permette di collegare periferiche di terze parti tramite la
porta OBD, installata sullo stesso, la quale fornisce sia l’alimentazione
+12V anche a vettura spenta, che il BUS di comunicazione nel quale
transiteranno i dati del veicolo.
Devices: Operatori
Per gli operatori la scelta ricade su dei desktop SFF (Dell Optiplex 302), i
quali permettono prestazioni da ufficio in dimensioni ridotte rispetto ai
normali Tower.
Le operazioni che devono svolgere non richiedono una potenza di calcolo
particolare, quindi la maggior parte dei Desktop aziendali può soddisfare le
richieste.
Devices: Server
Per poter elaborare i dati inviati dai veicoli sul territorio e per gestire le
richieste di rinnovo, mettiamo a confronto due possibili architetture, con i
loro pro e contro:
Cloud Server
Pro: Elevata Scalabilità, costi di gestione limitati e costanti nel tempo. Nessuna
infrastruttura di rete, banda garantita e nessun costo di manutenzione.
Contro: Non creato ad hoc per il sistema. Privacy e sicurezza degli utenti.
Server Fisico:
Pro: Privacy e sicurezza ”in-house”
Contro: Poca scalabilità, Costi elevati, necessità di personale specializzato.
Per le opzioni viste, la più appropriata al problema è quella che vede
l’utilizzo di server Cloud per l’immagazzinamento dei dati, e di un
elaboratore ‘in house’ per gestire i sinistri.
Comunicazione
Per soddisfare le esigenze del sistema, l’opzione di comunicazione più
consona è quella di avere per ogni dispositivo presente nelle vetture una
scheda SIM installata, che permetta il traffico dati con il server remoto il
quale si occupa di raccogliere i rilevamenti.
Il device (BB) utilizzerà quindi la connessione GPRS/UMTS per inviare al
server i dati raccolti dai percorsi e le rilevazioni di collisione.
Per quanto riguarda i Client degli Operatori Polizza situati nelle varie
agenzie sul territorio, verranno dotati di una connettività xDSL/Fibra che gli
permetta di interagire con il sistema in Cloud.
Stima dei costi 1/2
Per lo sviluppo del sistema supponiamo i seguenti costi:
Analisi requisiti e creazione documenti di implementazione/architettura:
5
per 20-25 gg a 150€/gg
Sviluppo del sistema partendo dalla documentazione prodotta nella fase
di analisi (Inclusi test per rilasci in collaudo, produzione):
8
per 140 gg a 150€/gg
Per un totale di 170.000€ di costi di Sviluppo SW
Stima dei costi
244 Desktop Dell Optiplex 302, a 539 Euro caduno.
244 Monitor Dell 22 P2214H a 200 Euro caduno
1 Milione di blackbox al costo di 25 euro ciascuna (a carico dell’assicurato)
Installazione di una blackbox:
1
per 30min a 30€/h (a carico dell’assicurato)
Costo traffico UMTS/GSM: 3€/mese per BlackBox (a carico dell’assicurato)
Costo cloud: 500€/mese
Costo server sede centrale:4000 €
Stima dei costi
Costi avvio
Analisi requisiti
20.000 €
Sviluppo testing
150.000 €
Acquisto HW
180.000 €
Server e cloud
Totale
Costi mantenimento
annui
50 €/mese a postazione
500 €/mese
350.000€
550 € /mese
Sviluppi futuri
I chilometri in cui l’assicurato rispetta i limiti vengono calcolati per ogni
tipologia di strada, questo potrebbe permettere alla compagnia
assicurativa di raffinare il calcolo di R
Al momento sappiamo avere solo 3 sensori. Su un autovettura sono molti di
più, questo permetterebbe sviluppi futuri.
L’esempio più intuitivo (per rimanere in tema OCA) è sapere se al
momento dell’impatto le cinture fossero correttamente allacciate.
Architettura Dati
Integrazione
L’integrazione ha come principale obiettivo quello di federare più database
che ricadono nel controllo di singoli soggetti giuridici che però accettano
tramite accordi di condividere una architettura di integrazione su una parte
dei loro dati.
Approccio scelto:
Virtual Data Integration
Virtual Data Integration
Lo schema globale SG è caratterizzato dalle
seguenti proprietà:
• Tutto il contenuto informativo di SL1 e SL2
deve essere rappresentato in SG
• Le eterogeneità tra SL1 e SL2 sono
riconcigliate in SG
• Le corrispondenze interschema sono
rappresentate in SG
• Non viene definito un nuovo DB fisico
Integrazione – Le fasi
Passi dell’integrazione:
1. Data Reverse Engineering : consiste nell’analizzare i diversi schemi locali
producendo come risultato un insieme di schemi concettuali localmente
completi e consistenti.
2. Integrazione Schemi: è la fase più importante in cui i diversi schemi locali
vengono fusi in un unico schema globalmente consistente.
3. Progettazione Logica: utilizzando lo schema logico riconciliato si definisce
la relazione (mapping) tra concetti degli schemi sorgenti e dello schema
riconciliato.
4. Data Integration: Record Linkage e Fusion
1. Data Reverse Engineering - BDA
Il testo riporta le seguenti specifiche:
«Una Base Dati Assicurati (BDA) che contiene l’anagrafica degli
assicurati, le relative polizze e le denunce di sinistro. Si consideri che un
assicurato può avere più polizze corrispondenti a veicoli diversi.»
Da queste informazioni ricaviamo lo schema logico relazionale con le
seguenti entità:
Assicurato
Polizza
Sinistro
Vengono inoltre modellate anche le entità:
Veicolo
Comune
Schema Logico Relazionale Locale BDA
COMUNE (CAP, Nome_Comune, Regione_Comune)
ASSICURATO (ID_Assicurato, CF_Assicurato, Nome_Assicurato, Cognome_Assicurato,
Data_Nascita_Assicurato, Telefono, CAP)
VEICOLO (Targa, Marca, Modello, Data_Immatricolazione, Categoria)
POLIZZA (ID_Polizza, Data_Stipula, Data_Rinnovo, Premio, ID_Assicurato, Targa)
SINISTRO (ID_Sinistro, Data, Ora, Luogo, ID_Polizza)
Legenda
Testo rosso: chiave esterna
Testo Grassetto e sottolineato: chiave primaria
Schema Concettuale Locale - BDA
Schema
Concettuale
Locale - OCB
Schema Logico Relazionale Locale – OCB
TIPOLOGIA(ID_Tipologia, Nome, Limite_Velocità)
OPERATORE(User, Nome, Cognome, Email, Password, Tipo_Op)
VIA(ID_Via, Nome, Comune)
TRONCO_VIA(ID_TroncoVia, ID_Via, ID_Tipologia)
ASSICURATO(ID, CF, Telefono, R, Comune)
POLIZZA(ID_Polizza, Targa_Veicolo, Assicurato, OP_Creaz_Polizza, OP_UltimoAgg)
SINISTRO(ID_Sinistro, Polizza, ID_Segn, OP_Creaz_Sinistro,Op_Gest_Sinistro)
BB(IMEI, Data_Attivazione, Soglia, Targa)
RILEVAMENTO_COLLISIONE(ID_RilColl, X, Y, Z, Acc_G, IMEI)
RILEVAMENTO(ID_Ril, Latitude,Longitude, Speed, IMEI, ID_TroncoVia)
SEGNALAZIONE(ID_Segn, Data, ID_RilColl, ID_Ril, IMEI)
PERCORSO(ID_Percorso, Data_Start, Data_Stop, KM_Totali, P_Percorso, ID_ReportMensile)
KV(ID_Percorso, ID_Tipologia, V_Media_Percorso, KM_Idonei)
REPORT_PERCORSI_POLIZZA(ID_RPP, Anno, Mese, K, P, Polizza)
VELOCITÀ(ID_RPP, ID_Tipologia, V_Media)
2. Integrazione schemi
Si Identificano i concetti comuni tra i due schemi concettuali identificando:
Eterogeneità: sono relative allo stesso oggetto (concetto) nei due schemi,
vanno rilevate e risolte nello schema globale. Stesso oggetto
rappresentato con proprietà differenti
Corrispondenza interschema: sono proprietà relative a oggetti diversi nei
due schemi e vanno rilevate e rappresentate nello schema globale.
Relazioni semantiche tra due oggetti O1 e O2 rappresentati in schemi
differenti.
Si integrano i due schemi concettuali in un solo globale, integrando le parti
comuni.
In modo tale da ricavare lo schema concettuale globale
Eterogeneità e Corrispondenze
interschema
Schema OCB
Schema BDA
Tipo
Risolta come:
Assicurato.Comune
Comune
Eterogeneità
strutturale
Via.Comune
Comune
Eterogeneità
strutturale
Comune.Nome
Comune.Nome_Comune
Eterogeneità
Sinonimia
Nome
Polizza.Targa_Veicolo
Polizza.Veicolo
Eterogeneità
In OCB ho Attributo, in BDA è chiave esterna
riferita al veicolo.
Polizza, Assicurato,
Sinistro
Polizza, Assicurato, Sinistro
Corrispondenza
Scegliamo di rappresentare le informazioni
contenute in BDA e OCB
Scegliamo di rappresentare Comune come entità
Schema
concettuale
Globale
Schema Logico Globale
TIPOLOGIA(ID_Tipologia, Nome, Limite_Velocità)
OPERATORE(User, Nome, Cognome, Email, Password, Tipo_Op)
VIA(ID_Via, Nome, Comune)
TRONCO_VIA(ID_TroncoVia, ID_Via, ID_Tipologia)
ASSICURATO (ID_Assicurato, Nome, Cognome, CF, Data_Nascita, Telefono CAP, R)
POLIZZA(ID_Polizza, Targa, Data_Rinnovo, Data_Stipula, Premio, Assicurato, OP_Creaz_Polizza, OP_UltimoAgg)
SINISTRO(ID_Sinistro, Data, Ora, Polizza, ID_Segn, OP_Creaz_Sinistro, Op_Gest_Sinistro, Luogo)
COMUNE (CAP, Nome_Comune, Regione_Comune)
BB(IMEI, Data_Attivazione, Soglia, Targa)
RILEVAMENTO_COLLISIONE(ID_RilColl, X, Y, Z, Acc_G, IMEI)
RILEVAMENTO(ID_Ril, Latitude,Longitude, Speed, IMEI, ID_TroncoVia)
SEGNALAZIONE(ID_Segn, Data, ID_RilColl, ID_Ril, IMEI)
PERCORSO(ID_Percorso, Data_Start, Data_Stop, KM_Totali, P_Percorso, ID_ReportMensile)
KV(ID_Percorso, ID_Tipologia, V_Media_Percorso, KM_Idonei)
REPORT_PERCORSI_POLIZZA(ID_RPP, Anno, Mese, K, P, Polizza)
VELOCITÀ(ID_RPP, ID_Tipologia, V_Media)
VEICOLO (Targa, Marca, Modello, Data_Immatricolazione, Categoria)
3. Progettazione Logica - Mapping
I Mapping sono delle Viste SQL che permettono di mettere in relazione i
vari SLi con lo schema globale.
È stato richiesto l’utilizzo di GAV (Global as View), ovvero lo schema
Globale andrà a contenere l’unione degli SLi (andando a risolvere come al
passo precedente le Corrispondenze ed Eterogenità.
Mapping – Schema Globale
per Assicurato
CREATE VIEW Assicurato AS(
(SELECT A.ID_Assicurato as ID_Assicurato,
A.Nome_Assicurato as Nome,
A.Cognome_Assicurato as Cognome,
A.CF_Assicurato as CF,
A.Data_Nascita as Data_Nascita,
A.Telefono as Telefono,
A.CAP as CAP,
O.R as R
FROM BDA.Assicurato as A, OCB.Assicurato as O)
WHERE A.ID_Assicurato=O.ID
)
Mapping – Schema Globale
per Polizza
CREATE VIEW Polizza AS(
(SELECT P.ID_Polizza as ID_Polizza,
P.Targa as Targa,
P.Data_Rinnovo as Data_Rinnovo,
P.Data_Stipula as Data_Stupula,
P.Premio as Premio,
P.ID_Assicurato as Assicurato,
P1.OP_Creaz_Polizza as OP_Creaz_Polizza,
P1.Op_UltimoAgg as OP_UltimoAgg
FROM BDA.Polizza as P, OCB.Polizza as P1
WHERE
P.ID_Polizza = P1.ID_Polizza
)
Mapping – Schema Globale
per Sinistro
CREATE VIEW Sinistro AS(
(SELECT S.ID_Sinistro as ID_Sinistro,
S.Data as Data,
S.Ora as Ora,
S1.ID_Polizza as Polizza,
S1.ID_Segn as ID_Segn,
S1.OP_Creaz_Sinistro as OP_Creaz_Sinistro,
S1.Op_Gest_Sinistro as Op_Gest_Sinistro,
S.Luogo as Luogo
)
FROM BDA.Sinistro as S, OCB.Sinistro as S1
WHERE S.ID_Sinistro = S1.ID_Sinistro
Mapping – Schema Globale da BDA
CREATE VIEW Comune AS(
(SELECT C1.CAP as CAP,
C.Nome_Comune AS Nome,
C.Regione_Comune AS Regione
FROM
BDA.Comune as C, OCB.Assicurato as C1
WHERE C.CAP = C1.CAP)
)
CREATE VIEW Veicolo AS(
(SELECT V1.Targa_Veicolo AS Targa,
V.Data_Immatricolazione as Data_Immatricolazione,
V.Marca as Marca,
V.Modello as Modello,
V.Categoria as Categoria
FROM BDA.Veicolo as V, OCB.Polizza as V1
)
WHERE V.Targa=V1.Targa_Veicolo)
Mapping – Schema Globale da OCB
CREATE VIEW Tipologia AS(
(SELECT * FROM OCB.Tipologia)
)
CREATE VIEW Via AS(
(SELECT * FROM OCB.Via)
)
CREATE VIEW Opertatore AS(
(SELECT * FROM OCB.Operatore)
)
CREATE VIEW Tronco_Via AS(
(SELECT * FROM OCB.Tronco_Via)
)
CREATE VIEW Rilevamento_Collisione AS(
(SELECT * FROM
OCB.Rilevamento_Collisione)
)
CREATE VIEW BB AS(
(SELECT * FROM OCB.BB)
)
CREATE VIEW Report_Percorsi_Polizza AS(
(SELECT * FROM
OCB.Report_Percorsi_Polizza)
)
CREATE VIEW Velocità AS(
(SELECT * FROM OCB.Velocità)
)
Mapping – Schema Globale da OCB
CREATE VIEW KV AS(
(SELECT * FROM OCB.KV)
)
CREATE VIEW Rilevamento AS(
(SELECT * FROM OCB.Rilevamento)
)
CREATE VIEW Percorso AS(
(SELECT * FROM OCB.Percorso)
)
CREATE VIEW Segnalazione AS(
(SELECT * FROM OCB.Segnalazione)
Query sullo Schema Globale
La query ideata per il problema è:
«Visualizzare il premio di tutti gli assicurati (nome, cognome) che hanno percorso
almeno 1000 km nel mese di Gennaio 2016»
SELECT A.Nome, A.Cognome, P.Premio
FROM Polizza as P, Report_Percorsi_Polizza as RPP, Assicurato as A
WHERE P.Assicurato = A.ID_Assicurato AND
P.ID_Polizza=RPP.Polizza AND
RPP.Mese=«Gennaio» AND
RPP.Anno=«2016» AND
RPP.K >’1000’
Query - Unfolding
SELECT A.Nome, A.Cognome, P.Premio
FROM
WHERE
(SELECT A.ID_Assicurato, A.Nome, A.Cognome, P.Premio
FROM BDA.Assicurato as A JOIN BDA.Polizza as P
ON A.ID_Assicurato = P.ID_Assicurato),
(SELECT * FROM OCB.Report_Percorsi_Polizza)AS RPP,
RPP.Polizza = P.ID_Polizza AND
OCB.RPP.Mese=«Gennaio» AND
OCB.RPP.Anno=«2016» AND
OCB.RPP.KM>1000
Modello di rappresentazione dati non
relazionale - NoSQL
Poiché i database relazionali RDBMS presentano numerose limitazioni, si sono
largamente diffusi i database non relazionali NRDBMS.
I vari database non relazionali vengono raggruppati nel NoSQL (NotOnly
SQL).
Fra i differenti approci, proponiamo l’utilizzo dell’approccio Document
Based, che estende il modello Key-Value, per la rappresentazione dei dati
del database OCB.
I documenti sono caratterizzati da una chiave unica e perciò vengono
indirizzati nel database per mezzo di questa. Rispetto ai normali database
relazionali basati sulle tabelle, è possibile salvare i dati in un documento,
che può contenere un numero illimitato di campi. In questo modo non ci
possono essere campi inutilizzati poiché ogni documento contiene solo gli
attributi effettivamente utilizzati.
MongoDB
Fra le diverse possibilità, scegliamo MongoDB, un approccio Document-Based.
Il modello non relazionale MongoDB utilizza documenti in formato JSON,
permettendo di avere uno schema più dinamico e flessibile e una
integrazione dei dati più semplice e veloce.
L’assenza di tabelle permette ai database non relazionali di non utilizzare il
JOIN, ottenendo risultati in tempi ridotti. Questo modello consente anche
una scalabilità orizzontale, ovvero è possibile aggiungere al database
nuove risorse e/o aggiungere al cluster nuovi nodi, gestirli in modo semplice
senza compromettere il funzionamento del sistema.
MongoDB
Vantaggi:
Document-oriented: le informazioni vengono memorizzate in un singolo
documento.
Performance: tempi di risposta più rapidi in quanto non utilizza le join.
Scalabilità: sfrutta la scalabilità orizzontale.
Storage: permette di bilanciare il carico applicativo.
