sistemi informativi t .case study: car sharing sistemi informativi t 2 car sharing il car sharing

Download Sistemi Informativi T .Case Study: Car Sharing Sistemi Informativi T 2 Car Sharing Il car sharing

Post on 09-Jul-2018

216 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • PickACar Case study di progettazione DB

    Sistemi Informativi T

    Versione elettronica: 0.CarSharingCaseStudy.pdf

    NB: Questo file viene aggiornato periodicamente

    Versione del 8/12/2017

  • Case Study: Car Sharing Sistemi Informativi T 2

    Car Sharing

    Il car sharing un servizio che permette di utilizzare un'automobile su

    prenotazione, prelevandola e riportandola in un parcheggio, e

    pagando in ragione dell'utilizzo fatto.

    https://it.wikipedia.org/wiki/Car_sharing

    Un fenomeno in continuo aumento

    "As of December 2012, there were an estimated

    1.7 million car-sharing members in 27 countries.

    https://en.wikipedia.org/wiki/Carsharing

    Diverse applicazioni online, tra cui:

    Enjoy https://enjoy.eni.com , Zipcar http://www.zipcar.com/

    Car2go https://www.car2go.com , Playcar http://www.playcar.net,

    TPER http://www.tper.it/car-e-bike-sharing/carsharing

  • Come funziona

    Dalla home di Zipcar

    Case Study: Car Sharing Sistemi Informativi T 3

  • Prime considerazioni

    La parte di registrazione (Join) essenziale, ma non molto

    interessante dal punto di vista progettazione DB

    Serve solo a definire che dati mantenere di ogni utente registrato

    Gli aspetti pi tecnologici (Zipcard) sono anchessi essenziali,

    ma esulano dai nostri scopi

    In sintesi, le operazioni fondamentali da supportare riguardano:

    Prenotazione di unauto (Reserve)

    Ritiro di unauto (Pick)

    Riconsegna di unauto (Park)

    Nella versione che svilupperemo non entriamo nei dettagli della

    flotta di auto e delle tariffe

    Case Study: Car Sharing Sistemi Informativi T 4

  • Possibili estensioni

    Di seguito alcuni suggerimenti per estendere la versione base:

    tariffario (con calcolo automatico dei costi)

    sistema di punti bonus che danno luogo a sconti

    diverse categorie di utenti

    descrizione della "flotta"

    preavviso disponibilit

    gestione parcheggi

    gestione prenotazioni non disdette, ma senza ritiro auto

    sistema integrato per il tracking dei veicoli in uso

    ...

    Case Study: Car Sharing Sistemi Informativi T 5

  • PickACar (PAC)

    Il sistema che vogliamo progettare deve consentire la prenotazione

    di auto, il loro ritiro e la riconsegna

    Supponiamo che tutto si basi su un insieme di parcheggi, ovvero

    punti di ritiro/riconsegna

    Un aspetto rilevante riguarda la gestione delle prenotazioni, che

    supponiamo

    si possano fare solo su auto disponibili (si evita loverbooking)

    possano essere disdette

    Complessivamente, i requisiti si possono sintetizzare come segue:

    Case Study: Car Sharing Sistemi Informativi T 6

  • Requisiti

    PickACar (PAC) un servizio che permette di noleggiare auto, prelevandole da un

    parcheggio e rilasciandole presso lo stesso o un altro parcheggio PAC.

    Per la prenotazione occorre preventivamente registrarsi, fornendo i dati anagrafici

    (nome, cognome, indirizzo), un numero di patente e una carta di credito (per

    questultima servono: circuito, numero, titolare e scadenza).

    La ricerca di unauto viene effettuata specificando il parcheggio da cui si vuole

    ritirare lauto e la data e orario previsto di ritiro. Per evitare spiacevoli inconvenienti,

    PAC permette di prenotare solo le auto disponibili, ovvero n in uso n gi

    prenotate.

    Effettuata la scelta, allutente viene fornito un codice di prenotazione e il numero di

    targa dellauto. Alla riconsegna del veicolo viene calcolato leffettivo costo (che tiene

    conto della data e orario di riconsegna e dei chilometri percorsi) e quindi addebitato

    sulla carta di credito.

    Non necessario mantenere informazioni storiche sulle prenotazioni non pi attive,

    ovvero che han gi dato luogo a un noleggio oppure che sono state disdette.

    Viceversa, vanno mantenute le informazioni relative a tutti i noleggi.

    Case Study: Car Sharing Sistemi Informativi T 7

  • Schema E/R: versione 1

    Case Study: Car Sharing Sistemi Informativi T 8

    La parte storica riguarda i soli NOLEGGI, ed supportata dalle

    associazioni RITIRI, RICONSEGNE, UN e NA.

    Questultima, p roprio perch relativa a tutti i noleggi

    (sia presenti che passati), associa NOLEGGI con AUTO.

    In alternativa si poteva distinguere tra noleggi passati (conclusi) e

    p resenti (in corso), e associare solo i presenti a IN_USO

    (vedi versione 2).

    1-1

    0-NUP

    1-1

    0-NUN

    1-1

    0-N UIU

    1-1 0-N

    RITIRI

    DataRitiro

    OrarioRitiro

    0-1 0-N

    RICONSEGNE

    DataRiconsegna

    OrarioRiconsegna

    KmPercorsi

    Costo

    0-N 1-1PIP

    1-1

    0-NNA

    P

    P

    UTENTI

    IDUtente

    Cognome

    Nome

    Indirizzo

    Patente

    CartaCredito

    Circuito

    Numero

    Titolare

    Scadenza

    M ese

    Anno

    id: IDUtente

    PRENOTATE

    CodicePrenotazione

    DataRitiro

    OrarioRitiro

    id': CodicePrenotazione

    PARCHEGGI

    CodiceParcheggio

    Indirizzo

    id: CodiceParcheggio

    NOLEGGI

    IDNoleggio

    id: IDNoleggio

    IN_USOIN_PARCHEGGIO

    DISPONIBILI

    AUTO

    Targa

    M odello

    Km

    id: Targa

  • Schema E/R: versione 2

    Case Study: Car Sharing Sistemi Informativi T 9

    Viene partiizionata l'entit NOLEGGI.

    L'associazione UIU ridondante:

    l'utente che ha in uso un'auto infatti

    univocamente determinato dal cammino

    NICIU -> NOLEGGI_IN_CORSO -> UN -> UTENTI

    Gli attributi vengono, equivalentemente, modellati come

    propriet delle entit che partecipano con cardinalit (1,1).

    1-1

    0-NUP

    1-1

    0-NUN

    1-1

    0-N UIU

    1-1 0-NRITIRI

    1-1 0-NRICONSEGNE

    0-N 1-1PIP

    1-1

    1-1 NICIU

    1-1 0-NNCA

    P

    P

    P

    UTENTI

    IDUtente

    Cognome

    Nome

    Indirizzo

    Patente

    CartaCredito

    Circuito

    Numero

    Titolare

    Scadenza

    M ese

    Anno

    id: IDUtente

    PRENOTATE

    CodicePrenotazione

    DataRitiro

    OrarioRitiro

    id': CodicePrenotazione

    PARCHEGGI

    CodiceParcheggio

    Indirizzo

    id: CodiceParcheggio

    NOLEGGI_IN_CORSO

    NOLEGGI_CONCLUSI

    DataRiconsegna

    OrarioRiconsegna

    KmPercorsi

    CostoNOLEGGI

    IDNoleggio

    DataRitiro

    OrarioRitiro

    id: IDNoleggio

    IN_USOIN_PARCHEGGIO

    DISPONIBILI

    AUTO

    Targa

    M odello

    Km

    id: Targa

  • Progettazione logica: scelte

    Si parte dalla versione 2 dello schema concettuale, in quanto appare

    opportuno tenere distinta la parte storica (NOLEGGI_CONCLUSI)

    dal resto. Per la gerarchia dei noleggi si adotta pertanto una

    traduzione verso il basso

    Per quanto riguarda la gerarchia delle AUTO, appare opportuna una

    traduzione ibrida, in quanto:

    Il cambio frequente di stato di unauto (da DISPONIBILE a PRENOTATA a IN_USO, e cos via) farebbe propendere per un collassoverso lalto, al fine di evitare spostamenti da una table allaltra (se sioptasse per un collasso verso il basso);

    daltronde, le auto PRENOTATE, a differenza delle altre, hanno diverse informazioni aggiuntive, che conviene memorizzare separatamente.

    Lo schema che ne deriva (PAC/logico-manuale-2 nel file .lun)

    ottenuto eliminando la ridondanza dellassociazione UIU e

    inglobando, ove possibile, le associazioni nelle entit

    Si veda il file .lun per altre alternative

    Case Study: Car Sharing Sistemi Informativi T 10

  • Progettazione logica: schema

    Case Study: Car Sharing Sistemi Informativi T 11

    Traduzione ibrida per la gerarchia delle AUTO.

    Collasso verso il basso di NOLEGGI.

    Si elimina l'associazione UIU.

    L'associazione NICIU 1-1 si assorbe in NOLEGGI_IN_CORSO

    UTENTI

    IDUtente

    Cognome

    Nome

    Indirizzo

    Patente

    CCCircuito

    CCNumero

    CCTitolare

    ScadenzaM ese

    ScadenzaAnno

    id: IDUtente

    PRENOTATE

    Targa

    CodicePrenotazione

    DataRitiro

    OrarioRitiro

    IDUtente

    id: Targa

    ref

    id': CodicePrenotazione

    ref: IDUtente

    PARCHEGGI

    CodiceParcheggio

    Indirizzo

    id: CodiceParcheggio

    NOLEGGI_IN_CORSO

    IDNoleggio

    IDUtente

    Targa

    CodParcheggioRitiro

    DataRitiro

    OrarioRitiro

    id: IDNoleggio

    ref: CodParcheggioRitiro

    ref: Targa

    ref: IDUtente

    NOLEGGI_CONCLUSI

    IDNoleggio

    IDUtente

    Targa

    CodParcheggioRitiro

    DataRitiro

    OrarioRitiro

    CodParcheggioRiconsegna

    DataRiconsegna

    OrarioRiconsegna

    KmPercorsi

    Costo

    id: IDNoleggio

    ref: Targa

    ref: CodParcheggioRiconsegna

    ref: CodParcheggioRitiro

    ref: IDUtente

    AUTO

    Targa

    M odello

    Km

    IN_USO[0-1]

    DISPONIBILE[0-1]

    PRENOTATA[0-1]

    CodiceParcheggio[0-1]

    id: Targa

    ref: CodiceParcheggio

    exact-1: IN_USO

    DISPONIBILE

    PRENOTATA

    exact-1: IN_USO

    CodiceParcheggio

  • Progettazione logica: vincoli

    Case Study: Car Sharing Sistemi Informativi T 12

    Per evitare il vincolo di mutua esclusione tra gli ID dei NOLEGGI,

    conviene avere domini distinti.

    Quando un noleggio termina, si genera un nuovo IDNoleggio

    Targa referenzia IN_USO NOT NULL

    Targa referenzia PRENOTATA NOT NULL

    UTENTI

    IDUtente

    Cognome

    Nome

    I