Download - Sistemi Informativi T · Case Study: Car Sharing Sistemi Informativi T 2 Car Sharing Il car sharing è un servizio che permette di utilizzare un'automobile su prenotazione, prelevandola

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


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 anch’essi essenziali,

ma esulano dai nostri scopi

� In sintesi, le operazioni fondamentali da supportare riguardano:

� Prenotazione di un’auto (Reserve)

� Ritiro di un’auto (Pick)

� Riconsegna di un’auto (Park)

� Nella versione che svilupperemo non entriamo nei dettagli della

“flotta” di auto e delle tariffe


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

� ...


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 l’overbooking)

� possano essere disdette

� Complessivamente, i requisiti si possono sintetizzare come segue:


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

quest’ultima servono: circuito, numero, titolare e scadenza).

� La ricerca di un’auto viene effettuata specificando il parcheggio da cui si vuole

ritirare l’auto 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, all’utente viene fornito un codice di prenotazione e il numero di

targa dell’auto. Alla riconsegna del veicolo viene calcolato l’effettivo 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.


Schema E/R: versione 1


La parte storica riguarda i soli NOLEGGI, ed è supportata dalle

associazioni RITIRI, RICONSEGNE, UN e NA.

Quest’ultima, 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


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


PARCHEGGI

CodiceParcheggio

Indirizzo


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 un’auto (da DISPONIBILE a PRENOTATA a IN_USO, e così via) farebbe propendere per un collassoverso l’alto, al fine di evitare “spostamenti” da una table all’altra (se sioptasse per un collasso verso il basso);

� d’altronde, 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 dell’associazione UIU e

inglobando, ove possibile, le associazioni nelle entità

� Si veda il file .lun per altre alternative


Progettazione logica: schema


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


ref: IDUtente

PARCHEGGI

CodiceParcheggio

Indirizzo


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: 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


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

Indirizzo

Patente

CCCircuito

CCNumero

CCTitolare

ScadenzaMese

ScadenzaAnno

id: IDUtente

PRENOTATE

Targa

CodicePrenotazione

DataRitiro

OrarioRitiro

IDUtente

id: Targa

ref


ref: IDUtente

PARCHEGGI

CodiceParcheggio

Indirizzo


NOLEGGI_IN_CORSO

IDNoleggioTemp

IDUtente

Targa

CodParcheggioRitiro

DataRitiro

OrarioRitiro

id: IDNoleggioTemp


ref: Targa

ref: IDUtente

NOLEGGI_CONCLUSI

IDNoleggio

IDUtente

Targa

CodParcheggioRitiro

DataRitiro

OrarioRitiro

CodParcheggioRiconsegna

DataRiconsegna

OrarioRiconsegna

KmPercorsi

Costo

id: IDNoleggio

ref: Targa

ref: CodParcheggioRiconsegna


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: le relazioni PK-FK

� Gli schemi relazionali, mantenendo le sole PK (sottolineate) e

FK (in corsivo, * se ammettono valori nulli), sono:

UTENTI (IdUtente)

PARCHEGGI (CodiceParcheggio)

AUTO (Targa, CodiceParcheggio*)

PRENOTATE (Targa, IdUtente)

NOLEGGI_IN_CORSO (IDNoleggioTemp, IDUtente, Targa,

CodParcheggioRitiro)

NOLEGGI_CONCLUSI (IDNoleggio, IDUtente, Targa,

CodParcheggioRitiro, CodParcheggioRiconsegna)


Le 3 operazioni (+1)


Disponibile Prenotata

In uso

Prenotazione

Cancellazione

RitiroRiconsegna

Prenotazione

Input:

:id_cl ID del cliente

:targa Targa dell'auto

:data Data del ritiro

:ora Ora prevista del ritiro

Azioni sul DB:

� Inserire una tupla in PRENOTATE, generando un CodicePrenotazione per il ritiro dell'auto

� Aggiornare in AUTO lo stato da Disponibile a Prenotata


Cancellazione

Input:

:cod_prenotaz Codice della prenotazione (in alternativa, la targa dell'auto)

Azioni sul DB:

� Cancellare la tupla da PRENOTATE

� Aggiornare in AUTO lo stato da Prenotata a Disponibile


Ritiro

Input:

:cod_prenotaz Codice della prenotazione(data e ora effettive del ritiro si ottengono dal sistema con CURRENT DATE e CURRENT TIME)

Azioni sul DB:

� Inserire una tupla in NOLEGGI_IN_CORSO, generando un IDNoleggioTemp

� Cancellare la tupla da PRENOTATE

� Aggiornare in AUTO lo stato da Prenotata a In_Uso e porre a NULL il CodiceParcheggio


Riconsegna

Input:

:targa Targa dell'auto (in alternativa, IDNoleggioTemp)

:codPark Codice del parcheggio di riconsegna

:km Chilometri percorsi

:costo Costo del noleggio

(data e ora della riconsegna si ottengono dal sistema)

Azioni sul DB:

� Inserire una tupla in NOLEGGI_CONCLUSI, generando un IDNoleggio

� Cancellare la tupla relativa da NOLEGGI_IN_CORSO

� Aggiornare in AUTO lo stato da In_Uso a Disponibile e porre CodiceParcheggio = :codPark e Km = Km + KmPercorsi


SQL: alcuni strumenti utili (1)

IDENTITY COLUMN: permette di generare automaticamente valori

(interi), definendo il primo e l'incremento

CREATE TABLE R (

ID INT NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY

(START WITH 500,INCREMENT BY 1),

A INT NOT NULL );

INSERT INTO R(A) VALUES (10);

INSERT INTO R(ID,A) VALUES (DEFAULT, 20);

SELECT * FROM R;

ID A

------ ------

500 10

501 20



DERIVED COLUMN: l'opzione GENERATED ALWAYS AS si usa anche per

generare automaticamente i valori di un attributo mediante

un'espressione

CREATE TABLE R (

A INT NOT NULL,

CODE CHAR(10) NOT NULL PRIMARY KEY

GENERATED ALWAYS AS ('cx' || A) );

INSERT INTO R(A) VALUES (10);

INSERT INTO R(A,CODE) VALUES (20, DEFAULT);

SELECT * FROM R;

A CODE

------ ----------

10 cx10

20 cx20



INSERT:

� Usando la forma VALUES è possibile usare una subquery scalare (tra

parentesi) per assegnare valori a singoli attributi

INSERT INTO R(A,B)

VALUES ((SELECT A FROM S WHERE K = 5),'b1');

� Si possono usare anche più subquery

� Ma se la subquery scalare restituisce una tupla con più attributi, allora

bisogna usare la forma SELECT

INSERT INTO R(A,B)

SELECT A,B FROM S WHERE K = 5;


Definizione delle table (1)

� Per brevità si omettono gli attributi non rilevanti per le diverse operazioniCREATE TABLE UTENTI (

IDUTENTE INT NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY,

... );

CREATE TABLE PARCHEGGI (

CODICEPARCHEGGIO INT NOT NULL PRIMARY KEY,

... );

CREATE TABLE AUTO (

TARGA CHAR(10) NOT NULL PRIMARY KEY,

KM INT NOT NULL DEFAULT 0,

IN_USO CHAR(1) DEFAULT NULL,

PRENOTATA CHAR(1) DEFAULT NULL,

DISPONIBILE CHAR(1) DEFAULT 'Y',

CODICEPARCHEGGIO INT REFERENCES PARCHEGGI,

CONSTRAINT STATO CHECK ((IN_USO IS NOT NULL AND PRENOTATA IS NULL AND

DISPONIBILE IS NULL) OR (...) OR (...)),

CONSTRAINT PARK CHECK ((IN_USO IS NOT NULL AND CODICEPARCHEGGIO IS

NULL) OR (IN_USO IS NULL AND CODICEPARCHEGGIO IS NOT NULL)));



CREATE TABLE PRENOTATE (

TARGA CHAR(10) NOT NULL UNIQUE REFERENCES AUTO,

IDUTENTE INT NOT NULL REFERENCES UTENTI,

CODICEPRENOTAZIONE INT NOT NULL PRIMARY KEY GENERATED ALWAYS AS

IDENTITY (START WITH 1000,INCREMENT BY 1),

DATARITIRO DATE NOT NULL ,

ORARIORITIRO TIME NOT NULL CHECK (ORARIORITIRO BETWEEN 0 AND 24)

);

CREATE TABLE NOLEGGI_IN_CORSO (

IDNOLEGGIOTEMP INT NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY


TARGA CHAR(10) NOT NULL REFERENCES AUTO,


CODPARCHEGGIORITIRO INT NOT NULL REFERENCES PARCHEGGI,

DATARITIRO DATE NOT NULL ,

ORARIORITIRO TIME NOT NULL

);



CREATE TABLE NOLEGGI_CONCLUSI (

IDNOLEGGIO INT NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY


TARGA CHAR(10) NOT NULL REFERENCES AUTO,


CODPARCHEGGIORITIRO INT NOT NULL REFERENCES PARCHEGGI,

DATARITIRO DATE NOT NULL,

ORARIORITIRO TIME NOT NULL,

CODPARCHEGGIORICONSEGNA INT NOT NULL REFERENCES PARCHEGGI,

DATARICONSEGNA DATE NOT NULL,

ORARIORICONSEGNA TIME NOT NULL,

KMPERCORSI INT NOT NULL CHECK (KMPERCORSI > 0),

COSTO DEC(6,2) NOT NULL CHECK (COSTO > 0),

CONSTRAINT VALID_PARK CHECK ((DATARICONSEGNA > DATARITIRO) OR

((DATARICONSEGNA = DATARITIRO) AND

(ORARIORICONSEGNA > ORARIORITIRO)))

);


Operazioni e trigger


Disponibile Prenotata

In uso

Prenotazione

Cancellazione

RitiroRiconsegna

ATTENZIONE: la cancellazione da PRENOTATE non può innescare trigger, perché le azioni da compiere sono diverse a seconda che si tratti di Cancellazione o Ritiro

Operazioni e trigger: prenotazione

INSERT INTO PRENOTATE(TARGA,IDUTENTE,CODICEPRENOTAZIONE,

DATARITIRO,ORARIORITIRO)VALUES (:targa, :id_cl,DEFAULT,:data,:ora)

CREATE TRIGGER DISP2PRENOTAFTER INSERT ON PRENOTATEREFERENCING NEW AS NPFOR EACH ROWUPDATE AUTOSET DISPONIBILE = NULL,

PRENOTATA = 'Y'WHERE TARGA = NP.TARGA


Input: :id_cl ID del cliente:targa Targa dell'auto:data Data del ritiro:ora Ora prevista del ritiro

Azioni sul DB:• Inserire una tupla in PRENOTATE, generando un

CodicePrenotazione per il ritiro dell'auto• Aggiornare in AUTO lo stato da Disponibile a

Prenotata

Operazioni e trigger: cancellazione

DELETE FROM PRENOTATEWHERE CODICEPRENOTAZIONE = :cod_prenotaz

CREATE TRIGGER PRENOT2DISPAFTER DELETE ON PRENOTATEREFERENCING OLD AS OPFOR EACH ROWUPDATE AUTOSET DISPONIBILE = 'Y',

PRENOTATA = NULLWHERE TARGA = OP.TARGA

UPDATE AUTOSET DISPONIBILE = 'Y',

PRENOTATA = NULLWHERE TARGA = :targa


Input: :cod_prenotaz Codice della prenotazione (in alternativa, la targa dell'auto)

Azioni sul DB:• Cancellare la tupla da PRENOTATE• Aggiornare in AUTO lo stato da Prenotata a

Disponibile

Operazioni e trigger: ritiro (1)

INSERT INTO NOLEGGI_IN_CORSO(IDNOLEGGIOTEMP,TARGA,IDUTENTE,CODPARCHEGGIORITIRO,

DATARITIRO,ORARIORITIRO)VALUES (DEFAULT,

(SELECT TARGA FROM PRENOTATE WHERE CODICEPRENOTAZIONE = :cod_prenotaz),

(SELECT IDUTENTE FROM PRENOTATE WHERE CODICEPRENOTAZIONE = :cod_prenotaz),

(SELECT CODPARCHEGGIO FROM AUTOWHERE TARGA =

(SELECT TARGA FROM PRENOTATE WHERE CODICEPRENOTAZIONE = :cod_prenotaz)),

CURRENT DATE,CURRENT TIME)

DELETE FROM PRENOTATEWHERE CODICEPRENOTAZIONE = :cod_prenotaz

CREATE TRIGGER PRENOT2IN_USOAFTER INSERT ON NOLEGGI_IN_CORSOREFERENCING NEW AS NNFOR EACH ROWUPDATE AUTOSET IN_USO = 'Y',

PRENOTATA = NULL,CODPARCHEGGIO = NULL

WHERE TARGA = NN.TARGA


Input: :cod_prenotaz Codice della prenotazione (data e ora effettive del ritiro si ottengono dal sistema con CURRENT DATE e CURRENT TIME)

Azioni sul DB:• Inserire una tupla in NOLEGGI_IN_CORSO,

generando un IDNoleggioTemp• Cancellare la tupla da PRENOTATE• Aggiornare in AUTO lo stato da Prenotata a

In_Uso e porre a NULL il CodiceParcheggio

Operazioni e trigger: ritiro (2)

� Per evitare di eseguire tante query quanti sono i valori da inserire già presenti nel DB, si può optare per la seguente soluzione, senz'altro più efficiente

� Il valore di IDNOLEGGIOTEMP viene calcolato dal sistema

INSERT INTO NOLEGGI_IN_CORSO(TARGA,IDUTENTE,CODPARCHEGGIORITIRO,DATARITIRO,ORARIORITIRO)

SELECT P.TARGA,P.IDUTENTE,A.CODPARCHEGGIO,CURRENT DATE,CURRENT TIMEFROM PRENOTATE P, AUTO AWHERE A.TARGA = P.TARGAAND P.CODICEPRENOTAZIONE = :cod_prenotaz


Input: :cod_prenotaz Codice della prenotazione (data e ora effettive del ritiro si ottengono dal sistema con CURRENT DATE e CURRENT TIME)

Azioni sul DB:• Inserire una tupla in NOLEGGI_IN_CORSO,

generando un IDNoleggioTemp• Cancellare la tupla da PRENOTATE• Aggiornare in AUTO lo stato da Prenotata a

In_Uso e porre a NULL il CodiceParcheggio

Operazioni e trigger: riconsegna

INSERT INTO NOLEGGI_CONCLUSI(TARGA,IDUTENTE,CODPARCHEGGIORITIRO,DATARITIRO,ORARIORITIRO,

CODPARCHEGGIORICONSEGNA, DATARICONSEGNA,ORARIORICONSEGNA, KMPERCORSI,COSTO)

SELECT TARGA,IDUTENTE, CODPARCHEGGIORITIRO,DATARITIRO,ORARIORITIRO,:codPark,CURRENT DATE,CURRENT TIME,:km,:costo

FROM NOLEGGI_IN_CORSOWHERE TARGA = :targa

CREATE TRIGGER NOLEGGIO_CONCLUSOAFTER INSERT ON NOLEGGI_CONCLUSIREFERENCING NEW AS NNCFOR EACH ROWBEGIN ATOMICDELETE FROM NOLEGGI_IN_CORSOWHERE TARGA = NNC.TARGA;UPDATE AUTOSET IN_USO = NULL,

DISPONIBILE = 'Y',CODPARCHEGGIO = NNC.CODPARCHEGGIORICONSEGNA,KM = KM + NNC.KMPERCORSI

WHERE TARGA = NNC.TARGA;END


Azioni sul DB:Input:

:targa Targa dell'auto (in alternativa, IDNoleggioTemp):codPark Codice del parcheggio di riconsegna:km Chilometri percorsi:costo Costo del noleggio

Azioni sul DB:• Inserire una tupla in NOLEGGI_CONCLUSI• Cancellare la tupla relativa da NOLEGGI_IN_CORSO• Aggiornare in AUTO lo stato da In_Uso a Disponibile,

CodiceParcheggio e Km


Commenti conclusivi

� Il case study esaminato, oltre a mostrare come le diverse fasi della

progettazione si possono applicare ad un caso reale (sia pure semplificato),

e come la conoscenza delle principali operazioni può guidare la fase di

progettazione logica, permette di apprezzare la correlazione esistente tra

progettazione e codice SQL, e come quest'ultimo, avvalendosi di strumenti

quali i trigger, possa essere sviluppato riducendo all'essenziale le interazioni

con il lato client, a tutto vantaggio delle prestazioni

� Si suggerisce di analizzare come quanto prodotto possa essere

opportunamente esteso/modificato a fronte di nuove esigenze, in

particolare considerando, tra quelle elencate a pag. 5, le più interessanti in

termini di ripercussioni sul Data Base

Download - Sistemi Informativi T · Case Study: Car Sharing Sistemi Informativi T 2 Car Sharing Il car sharing è un servizio che permette di utilizzare un'automobile su prenotazione, prelevandola

Top Related