APPELLO 12/02/2014 STUDENTE: LUCA GRAZIOLI MATRICOLA: Progetto di Architetture del software e dei dati

Testo del problema - 1 Si deve realizzare un sistema per l’acquisizione dei dati fisiologici (ad esempio, la frequenza del battito cardiaco) di atleti che svolgono attività di allenamento. Gli utenti del sistema sono gli atleti e i loro allenatori. Il sistema deve supportare: 1. l’acquisizione “in tempo reale” dei dati fisiologici degli atleti; 2. l’indicazione, da parte degli atleti, dell’inizio e della fine di una attività di allenamento, specificandone il tipo (ad esempio, “corsa di 5000 metri); 3. l’archiviazione dei dati relativi ai singoli atleti in una Base relazionale DatiAllenamenti BDA; 4. la visualizzazione in remoto, da parte degli allenatori, dei dati relativi agli atleti di loro competenza che stanno svolgendo un allenamento;

Testo del problema la visualizzazione in remoto, da parte degli atleti, dei dati relativi all’allenamento che tanno svolgendo; 6. l’elaborazione di statistiche per ricavare informazioni aggregate (ad esempio, per atleta, per allenamento e per tipo di attività) e la loro visualizzazione da parte degli allenatori e degli atleti; 7. la comparazione, da parte degli allenatori, delle informazioni relative a un singolo atleta con informazioni analoghe relative ai diversi tipi di attività, che sono archiviate in una Base Dati relazionale dei Parametri Fisiologici BDF esterna preesistente. Si richiede di definire, utilizzando i formalismi opportuni: 1. l’architettura del problema in termini di informazioni e flussi informativi; 2. l’architettura logica in termini di componenti di elaborazione;

Testo del problema l’architettura concreta in termini di modalità di interazione fra componenti; 4. l’architettura di deployment; 5. le scelte tecnologiche (componenti hw, reti di comunicazione, piattaforme sw); 6. gli schemi concettuali delle basi di dati BDA e BDF, avendo cura di prevedere in tali schemi concettuali almeno una eterogeneita’ e almeno una proprieta’ interschema. 7. le modalità e i problemi di integrazione concettuale fra BDA e BDF. 8. lo schema concettuale globale risutato della integrazione delle Basi Dati BDA e BDF; 9. assumendo di utilizzare una architettura di integrazione dati (virtual data integration), e assumendo di scegliere i mapping secondo la modalita’ Global as View, i mapping tra schema logico globale relazionale e schemi locali relazionali di BDA e BDF; 10. una interrogazione sullo schema globale, con il suo unfolding sugli schemi locali;

Testo del problema Il sistema deve anche essere in grado di pubblicare parte dei dati contenuti nella architettura di integrazione (a scelta dello studente e tenuto conto di eventuali problemi di privacy) in formato aperto (indicando un insieme di metadati, tra cui il tipo di licenza con cui vengono rilasciati), indicando almeno una applicazione che potrebbe avvantaggiarsi dall’utilizzo di questi dati. Le scelte architetturali dovranno essere discusse presentandone le motivazioni ed evidenziando, ove opportuno, possibili scelte alternative con i relativi vantaggi e svantaggi (ad esempio, per la architettura dati, una scelta di tipo base dati distribuita, con le relative problematiche di replicazione e distribuzione dei frammenti).

Assunzioni Attività e allenamento sono la stessa cosa; Quali attività un atleta dovrà svolgere, vengono decise privatamente tra atleta e allenatore, tale decisione non è memorizzata nel sistema; Un atleta può svolgere una attività alla volta; Per un'attività in corso atleta e allenatore vedono dati con frequenza di aggiornamento differente; Il contesto è un centro sportivo di medie dimensioni (vedi dimensionamento); Gli allenamenti possono essere svolti anche lontani dal centro sportivo.

Dimensionamento - 1 Totale atleti iscritti: circa 3000; N° Atleti attivi in media all’ora: 100; Totale allenatori: 300; Atleti seguiti a settimana da un allenatore: 10; Numero attività svolte da un atleta giornalmente: 7; Totale attività svolte giornalmente: circa 10000; Richieste di visualizzazione allenamenti in corso: circa (metà atleta, metà allenatori); Richieste di visualizzazione storico allenamenti: (metà atleta, metà allenatori);

Dimensionamento - 2 Rilevazione battito cardiaco: da 1 a 3 volte al secondo massimo Variazione temperatura corporea: 0,06°C/s Richiesta comparazione dati fisiologici al giorno: circa 5000

Architettura del problema

Casi d’uso

Modello dei dati

Segnala inizio attività

Acquisisci frequenza cardiaca - 1

Acquisisci frequenza cardiaca - 2

Acquisisci temperatura - 1

Acquisisci temperatura - 2

Aggiungi dato fisiologico (generale)

Aggiorna attività

Concludi attività

Compara info atleta

Elabora statistiche allenamento

Elabora statistiche atleta/attività

Visualizza attività in corso allenatore

Visualizza attività in corso atleta

Visualizza attività svolte atleta

Visualizza statistiche aggregate

Architettura logica

Partizionamento Scelto partizionamento multidimensionale:  A livello sensori dei dati fisiologici scelto partizionamento orizzontale  Tutto il resto si può ricondurre a un partizionamento verticale Per quanto riguarda le molteplicità N intende il numero di atleti.

Rilevatore battiti/temperatura

Elaboratore frequenza cardiaca

Elaboratore temperatura

Segnala inizio attività (GestoreAtleta)

Concludi attività

Aggiorna attività

Comparatore parametri fisiologici

Gestore statistiche - 1

Gestore statistiche - 2

Visualizza attività in corso allenatore

Visualizza attività in corso atleta

Visualizza attività svolte atleta

Visualizzatore Statistiche Aggregate

Segnala inizio attività

Acquisisci temperatura

Acquisisci frequenza cardiaca

Aggiorna attività

Concludi attività

Elabora statistica

Visualizza attività in corso allenatore

Visualizza attività in corso atleta

Architettura concreta

Soluzione 1

Soluzione 1 valutazione Pro: Rispetta la suddivisione fornita dal problema Sensori estremamente semplici Device allenatore limitato alla sola interfaccia con il server Contro: Nodo centrale che necessità di un elevata potenza di calcolo Dispositivo atleta complesso Elevata frequenza di connessioni tra sensori e dispositivo atleta Sensore più difficile da reperire commercialmente

Soluzione 2

Soluzione 2 valutazione Pro: Rispetta la suddivisione fornita dal problema Device allenatore limitato alla sola interfaccia con il server Drastica diminuzione del numero di connessioni richieste tra device atleta e sensori Device atleta più semplice e modulabile Sensore più facilmente reperibile commercialmente Contro: Nodo centrale che necessita di un elevata potenza di calcolo

Soluzione 3

Soluzione 3 valutazioni Pro: Minor potenza di calcolo richiesta nel server centrale Device atleti più semplici Device allenatori limitati alla sola interfaccia server Contro: Solo per centri sportivi con sedi distaccate Aumento costi Necessità di continui collegamenti tra sedi distaccate e sedi centrali

Soluzione scelta: 2 Stima dei costi Costo infrastruttura hardware: Costo nodo centrale: 4000€ Costo elaboratore statistiche: 2000€ Costo storage: 10000€ Infrastruttura comunicazione: 35€/mese Sensori: 50€/sensore (a carico atleta)

Stima dei costi -2 Costo infrastruttura software: Sviluppo software:  Nodo centrale: 1 team di sviluppo 3 settimane di lavoro, costo 20000€  Nodo statistica: 1 team di sviluppo 2 settimane di lavoro, costo 15000€ Applicazione Android/iOS: 10000€ Costo licenze: 4000€ Manutenzione: 2 team di sviluppo 1 settimana al mese 1500€/mese Totale costi: 65000€ €/mese

Soluzione 2 & cloud computing Stima dei costi (es su Windows Azure)  Nodo centrale opzione A6, costo 394€/mese (0,53€/ora, per circa 700 ore di utilizzo)  Nodo statistiche opzione A7, costo 782€/mese (1,06€/ora)  Archiviazione 6TB/mese, costo 305€/mese  Costo mensile totale: 1481€/mese Costo sviluppo:  Nodo centrale: 10000€  Nodo statistica: 8000€  Applicazione Android/iOS: 10000€  Manutenzione: 700€/mese

Riassumendo Costo totale messa in cloud: 28000€ €/mese Differenza costo fase iniziale: ( )€ = 37000€ Differenza costo mensile: ( )€ = 646€/mese Per i primi 57 mesi conviene il servizio cloud Windows Azure, dopodiché a seconda dell’espansione del servizio dovrà seguire una valutazione ulteriore.

Architettura dati

Tavola delle frequenze OperazioneFrequenza T1 = inserimento nuova attività al giorno Q1= visualizza allenamento in corso atleti al giorno Q2 = visualizza allenamenti in corso allenatori al giorno Q3 = visualizza storico allenamenti da atleti al giorno Q4 = visualizza storico allenamenti da allenatori al giorno Q5 = visualizza attività svolte per elab. statistiche Circa 26 al giorno

BDA schema concettuale Atleta Allenatore Attività Allena Frequenza_cardiaca userID nome dataNascita userID (0,1) (0,N) Svolte (0,N) (1,1) cognome categoria nome dataNascita cognome tipologia inizio fine nome id sport settore (1,1) Temperatura timestamp temp tipoSensore unitàDiMisura Sensore nome precisione id grandezzaMisurata Utilizzo (0,N) heart_rate (0,N) (1,1) timestamp tipoSensore unitàDiMisura sesso

BDA Schema logico Atleta (UserID,Nome,Cognome,Categoria,DataDiNascita,Sesso) Allenatore (UserID,Nome,Cognome,Tipologia,DataDiNascita) Allena (Atleta,Allenatore) Attività (Id, Nome,Inizio,Fine,Atleta,Sport) Sensore (Id,nome,precisione,grandezzaMisurata) SensoreAtt (Attività,Sensore) Freq_cardiaca (heart_rate,Attività,timestamp,tipoSensore,unitàDiMisura) Temperatura (temp,Attività,timestamp,tipoSensore,unitàDiMisura)

BDF schema concettuale

BDF Schema logico DatoFisiologico (Nome,unitàDiMisura) Individuo (Id,sesso,età,categoria) Stato (Nome,,tipoSforzo) Sport (Nome,aSquadre/individuale) Misura (DatoFisiologico,Persona,Stato,Stagione,ValoreMax,ValoreMin,ValoreMedio) StatoSport (Stato,Sport) Strumento (nome,commerciale/professionale) DatoRaccolto (DatoFis,Strumento)

Soluzione centralizzata Pro: Compatibile con scelta di deployment Elaborazione statistiche semplice Costi minori Manutenzione più facile Contro: Rischio collo di bottiglia con crescita del servizio No ridondanza dati (servizio cloud può aggirare il problema) Basso parallelismo

Soluzione distribuita Supponendo che il centro sportivo abbia 3 sedi (rispettivamente una sede centrale a Milano, e due sedi distaccate a Bergamo e a Verona) e che in fasi di registrazione all’atleta venga aggiunto l’attributo sedeRegistrazione, si potrebbe avere la seguente allocazione di frammenti. Bergamo: AtletaBG, AttivitàBG, AllenatoreBG, Sensore, Frequenza_CardiacaBG, TemperaturaBG; Verona: AtletaVR, AttivitàVR, AllenatoreVR, Sesnsore, Frequenza_CardiacaVR, TemperaturaVR; Milano: Atleta, Attività, Allenatore, Sensore, Frequenza_Cardiaca, Temperatura;

Esempi di frammenti espressi secondo SLG BDA CREATE VIEW AtletaBG AS ( SELECT Atleta.userID, Atleta.Nome, Atleta.Cognome, Atleta.Categoria, Atleta.DataNascita, Atleta.Sesso FROM Atleta WHERE Atleta.SedeRegistrazione = «Bergamo» ) CREATE VIEW AttivitàBG AS ( SELECT * FROM Attività JOIN Atleta ON Attività.Atleta = Atleta.userID WHERE Atleta.SedeRegistrazione = «Bergamo» )

Soluzione distribuita valutazione Pro: Principio di località rispettato Prestazioni Resilienza Contro: Costi Manutenzione Complessità

Soluzione scelta: centralizzata Non richiede modifiche alla soluzione di deployment scelta; L’eventuale utilizzo di un servizio cloud aggira alcuni problemi del sistema centralizzato (esempio resistenza ai guasti); L’elaborazione delle statistiche viene eseguita in modo efficiente senza richiedere un’eccessiva replicazione dei dati.

Virtual Data Integration: individuazione etereogeneità e proprietà interschema Concetto 1 (da BDA)Concetto 2 (da BDF)Proprietà Attributo Attività.SportEntità SportEterogeneità (ET1) Attributo Atleta.DataNascita Attributo Individuo.EtaEterogeneità, legame funzionale. (ET2) Persona.Età = AnnoAttuale- Atleta.DataNascita Entità Frequenza_Cardiaca Entità DatoFisiologicoProprietà interschema, IS-A (IS1) Entità TemperaturaEntità DatoFisiologicoProprietà interschema, IS-A (IS2)

Risoluzione eterogeneità ProprietàConcetto 1Concetto 2Concetto SI ET1Attributo Attività.Sport Entità Sport ET2Attributo Atleta.DataNascita Attributo Individuo.DataNascita

Schema concettuale globale

Schema logico globale DatoFisiologico (Nome,unitàDiMisura,tipoSensore) Freq_cardiaca (Nome,unitàDiMisura,tipoSensore,heart_rate,Attività,timestamp) Temperatura (Nome,unitàDiMisura,tipoSensore,temp,Attività,timestamp) Attività (id,nome,inizio,fine,settore,Atleta,Sport) Strumento (nome,commerciale/professionale) DatoRaccolto (DatoFis,Strumento) Sensore (Id,nome,precisione,grandezzaMisurata) SensoreAtt (Attività,Sensore) Individuo (Id,sesso,DataNascita,categoria) Atleta (UserID,Nome,Cognome,Categoria,Individuo) Allenatore (UserID,Nome,Cognome,Tipologia,Individuo) Allena (Atleta,Allenatore) Stato (nome,tipoSforzo) Sport (Nome,aSquadre/individuale) Misura (DatoFisiologico,Persona,Stato,Stagione,ValoreMax,ValoreMin,ValoreMedio) StatoSport (Stato,Sport)

Mapping GAV CREATE VIEW DatoFisiologico AS ( SELECT DatoFisiologico.Nome, DatoFisiologico.unitàDiMisura, «» FROM BDF.DatoFisiologico UNION SELECT «frequenza_cardiaca», Frequenza_Cardiaca.unitàDiMisura, Frequenza_Cardiaca.tipoSensore FROM BDA.Frequenza_Cardiaca UNION SELECT «temperatura», Temperatura.unitàDiMisura, Temperatura-tipoSensore FROM BDA.Temperatura ) CREATE VIEW Frequenza_cardiaca AS ( SELECT «frequenza_cardiaca>>, frequenza_cardiaca.unitàDiMisura, frequenza_cardiaca.tipoSensore, frequenza_cardiaca.heart_rate, frequenza_cardiaca.attività, frequenza_cardiaca.timestamp FROM BDA.Frequenza_Cardiaca ) CREATE VIEW Temperatura AS ( SELECT «temperatura>>, temperatura.unitàDiMisura, temperatura.tipoSensore, temperatura.heart_rate, temperatura.attività, temperatura.timestamp FROM BDA.Temperatura )

Mapping GAV CREATE VIEW Attività AS ( SELECT * FROM BDA.Attività ) CREATE VIEW Strumento AS ( SELECT * FROM BDF.Strumento ) CREATE VIEW DatoRaccolto AS( SELECT * FROM BDF.DatoRaccolto ) CREATE VIEW Sensore AS ( SELECT * FROM BDA.Sensore )

Mapping GAV CREATE VIEW SensoreAtt AS ( SELECT * FROM BDA.SensoreAtt ) CREATE VIEW Individuo AS ( SELECT Individuo.Id, Individuo.sesso, (AnnoAttuale- Individuo.Età), Individuo.categoria FROM BDF.Individuo ) CREATE VIEW Atleta AS( SELECT Atleta.userID, Atleta.Nome, Atleta.Cognome, Atleta.Categoria, Individuo.ID FROM BDA.Atleta,BDF.Individuo WHERE BDA.Atleta.sesso = BDF.Individuo.Sesso AND BDA.Atleta.DataNascita = (AnnoAttuale – BDF.Individuo.Età) )

Mapping GAV CREATE VIEW Allenatore AS ( SELECT Allenatore.userID, Allenatore.Nome, Allenatore.Cognome, Allentatore.Tipologia, «» FROM BDA.Allenatore ) CREATE VIEW Allena AS ( SELECT * FROM BDA.Allena ) CREATE VIEW Stato AS ( SELECT * FROM BDF.Stato ) CREATE VIEW Sport AS ( SELECT * FROM BDF.Sport UNION SELECT Attività.Sport, «» FROM BDA.Attività )

Mapping GAV CREATE VIEW Misura AS ( SELECT * FROM BDF.Misura ) CREATE VIEW StatoSport AS ( SELECT * FROM BDF.StatoSport )

Esempio unfolding di query Q = Trovare frequenza cardiaca massima e minima attesa per l’atleta con userID «FL23». Interrogazione su SLG SELECT Atleta.userID, Misura.ValoreMax, Misura.ValoreMin FROM ((Atleta JOIN Individuo) ON Atleta.userID = Individuo.ID) JOIN Misura ON Indivduo.ID = Misura.Persona WHEREAtleta.userID = «FL23» AND Misura.DatoFisiologico = «frequenza_cardiaca»

Unfolding query SELECT userID, ValoreMax, ValoreMin FROM ( SELECT Atleta.userID, Atleta.Nome, Atleta.Cognome, Atleta.Categoria, Individuo.ID FROM BDA.Atleta,BDF.Individuo WHERE BDA.Atleta.sesso = BDF.Individuo.Sesso AND BDA.Atleta.DataNascita = (AnnoAttuale - BDF.Individuo.Età) JOIN( SELECT Individuo.Id, Individuo.sesso, (AnnoAttuale- Individuo.Età), Individuo.categoria FROM BDF.Individuo ) ON Atleta.userID = Individuo.ID ) JOIN SELECT * FROM BDF.Misura ON Individuo.ID=Misura.Persona WHERE Atleta.userID = «FL23» AND Misura.DatoFisiologico = «Frequenza_cardiaca»

Pubblicazione dati È stato scelto di pubblicare i dati relativi alle relazioni: Sensore; Attività; Sport; Frequenza_Cardiaca; Temperatura; In particolare dalla relazione Attività viene rimosso l’identificatore per motivi di privacy.

Licenza e insieme metadati La licenza scelta per la pubblicazione è la CC BY in quanto permette un utilizzo commerciale dei dati consentendo anche la compatibilità interlicenza. Inoltre tale licenza obbliga l’utilizzatore dei dati a riconoscere la paternità dell’autore. Insieme metadati scelti: Sensore: nome, precisione, grandezzaMisurata; Attività: nomeSensore, inizio, fine, settore, sport, frequenza_cardiaca, temperatura; Sport: nome; Frequenza_cardiaca: heart_rate; Temperatura: temp;

Applicazioni possibili Applicazione commerciale: sfruttando i dati sul sensore è possibile condurre indagini sulle caratteristiche dei sensori più utilizzati per ogni sport Applicazione biomedicale: confrontare i dati fisiologici di atleti con altri.