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 Secci Stefano Ceresa Nausica

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 Ricalcolo Livello Rischio

AD Calcolo KVP Annuale

AD 8 - Visualizza Polizza

AD 9 - Visualizza Livello Rischio

ARCHITETTURA LOGICA

Suddivisione in componenti Gestore Sensori Rileva collisione Crea percorso Gestore Sinistri Riceve segnalazione collisione Gestore dati sensori Riceve percorso Gestore KVP mensile Calcola KVP mensile Gestore polizze Rinnova polizze Visualizza polizza Visualizza livello di rischio

Partizionamento: Gestore Sensori

FOOTPRINT : Gestore Sensori ABSTRACTION10 COMPLEXITY35 FREQUENCY40 DELAY30 LOCATION10 EXTRA FLOW80 INTRA FLOW0 SHARING20

Partizionamento: Gestore Sinistri

FOOTPRINT : Gestore Sinistri ABSTRACTION30 COMPLEXITY20 FREQUENCY20 DELAY20 LOCATION10 EXTRA FLOW50 INTRA FLOW10 SHARING50

Partizionamento: Gestore Dati Sensori

FOOTPRINT : Gestore Dati Sensori ABSTRACTION 10 COMPLEXITY 10 FREQUENCY 10 DELAY 20 LOCATION 10 EXTRA FLOW 10 INTRA FLOW 10 SHARING 60

Partizionamento: Gestore KVP Mensile

FOOTPRINT : Gestore KVP Mensile ABSTRACTION 10 COMPLEXITY 10 FREQUENCY 10 DELAY 10 LOCATION 10 EXTRA FLOW 5 INTRA FLOW 10 SHARING 80

Partizionamento: Gestore Polizze

FOOTPRINT : Gestore Polizze ABSTRACTION40 COMPLEXITY50 FREQUENCY50 DELAY50 LOCATION20 EXTRA FLOW50 INTRA FLOW30 SHARING80

FOOTPRINT Complessivo ABSTRACTION20 COMPLEXITY30 FREQUENCY30 DELAY30 LOCATION10 EXTRA FLOW40 INTRA FLOW10 SHARING60

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 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 € 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 avvioCosti mantenimento annui Analisi requisiti € Sviluppo testing € Acquisto HW €50 €/mese a postazione Server e cloud500 €/mese Totale €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 pero ̀ 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, , 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 O 1 e O 2 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 OCBSchema BDATipoRisolta come: Assicurato.ComuneComuneEterogeneità strutturale Scegliamo di rappresentare Comune come entità Via.ComuneComuneEterogeneità strutturale Comune.NomeComune.Nome_ComuneEterogeneità Sinonimia Nome Polizza.Targa_VeicoloPolizza.VeicoloEterogeneitàIn OCB ho Attributo, in BDA è chiave esterna riferita al veicolo. Polizza, Assicurato, Sinistro CorrispondenzaScegliamo di rappresentare le informazioni contenute in BDA e OCB

Schema concettuale Globale

Schema Logico Globale TIPOLOGIA ( ID_Tipologia, Nome, Limite_Velocità) OPERATORE ( User, Nome, Cognome, , 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( (SELECTS.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( (SELECTC1.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( (SELECTV1.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 Opertatore AS( (SELECT* FROM OCB.Operatore) ) CREATE VIEW Rilevamento_Collisione AS( (SELECT* FROM OCB.Rilevamento_Collisione) ) CREATE VIEW Report_Percorsi_Polizza AS( (SELECT* FROM OCB.Report_Percorsi_Polizza) ) CREATE VIEW Via AS( (SELECT* FROM OCB.Via) ) CREATE VIEW Tronco_Via AS( (SELECT* FROM OCB.Tronco_Via) ) CREATE VIEW BB AS( (SELECT* FROM OCB.BB) ) CREATE VIEW Velocità AS( (SELECT* FROM OCB.Velocità) )

Mapping – Schema Globale da OCB CREATE VIEW KV AS( (SELECT* FROM OCB.KV) ) CREATE VIEW Percorso AS( (SELECT* FROM OCB.Percorso) ) CREATE VIEW Rilevamento AS( (SELECT* FROM OCB.Rilevamento) ) CREATE VIEW Segnalazione AS( (SELECT* FROM OCB.Segnalazione)

Query sullo Schema Globale 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’ 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»

Query - Unfolding SELECT A.Nome, A.Cognome, P.Premio FROM (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, WHERE 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.