Informatica generale ed applicazioni gestionali - Soluzione Maturità 2013

Analisi dei requisiti funzionali

Analizziamo di seguito i requisiti funzionali fornitici per la strutturazione della base di dati

demandata all’emissione dei biglietti elettronici di un museo.

L’obiettivo di tale discussione e’ qullo di chiarificare e disambiguare tali requisiti nonche’ aggiungere

ipotesi accessorie necessarie alla strutturazione logico/concettuale del database.

Da una prima analisi condotta sulle richieste del committente emergono le seguenti’ ambiguita’ per

le quali saranno necessarie dovute ipotesi accessorie iniziali:

1. Non si evince se le percentuali di sconto applicate alle categorie speciali sono specifiche per

singolo evento o possono essere riferite ad eventi multipli (o semplice emissione ordinaria).

Esempio: si consideri la categoria over-70 e le seguenti tipologie di biglietto: mostra

Pirandello, biglietto in emissione ordinaria; non e’ chiaro se e’ possible avere una

percentuale di sconto separata per ciascuna tipologia o tali valori sono comuni. Si supporra’

in tal caso che le possibili opzioni di sconto possono essere condivise tra le diverse tipologie

di biglietti memorizzati nel sistema.

2. Non si evince se i servizi accessori (audioguida, accompagnatore specializzato) sono attivi su

tutte le tipologie di biglietto o possono esistere casi in cui un servizio e’ mancante. Esempio:

si consideri il servizio accessorio “audioguida” e e le seguenti tipologie di biglietto: mostra

Pirandello, biglietto in emissione ordinaria; non e’ chiaro se e’ possible avere un servizio di

audioguida sulla sola emission ordinaria e non sulla mostra Pirandello o viceversa. Si

supporra’ che i servizi acecssori sono sempre disponibili per tutti i biglietti memorizzati.

3. Sulla base dei requisiti forniti inoltre non si evince se le percentuali di scontistica applicate,

cosi’ come il prezzo ordinario del biglietto e dei servizi accessori, possano variare nel tempo

e se il costo delle emissioni effettuate, ossia il costo dei biglietti venduti, sia memorizzato

fisicamente o dedotto dale informazioni attualmente presenti nella base dati. Un’operazione

di alterazione dei dati potrebbe portare a possibili inconsistenze di questi ultimo; Esempio: si

supponga che il costo del biglietto ordinario sia di 5€ in data 20/Giungo/2013 e che nella

stessa data venga emesso un singolo ticket, ricavo giornaliero 5€. Se in data

21/Giugno/2013 il prezzo del biglietto fosse variato a 7€ ed il costo delle emissioni fosse

calcolato sulla base delle informazioni attualmente memorizzato e non fisicamente persistito

allora il ricavo complessivo, che in data 20/Giugno/2013 era di 5€, risulterebbe essere di 7€.

A tal proposito si supporra’ che il prezzo finale pagato dal cliente sara’ fisicamente

memorizzato nella tabella delle emissioni e che le percentuali di sconto, cosi’ come il costo

del prezzo ordinario, possano variare nel tempo. Inoltre si supporra’, sempre al fine di

mantenere consistenza tra le relazioni , che i record dei biglietti, quelli delle percentuali di

scontistica e dei servizi aggiuntivi non siano mai fisicamente cancellati base di dati. Tale

soluzione oltre a garantire consistenza permette anche di storicizzare i dati per future

operazionir eportistiche.

Modellazione logico concettuale

Fatte le dovute ipotesi iniziali e’ possible passare alla parte di modellazione logico/concettuale della

base dati illustrando le entita’ di dominio e fornendo per ciascuan di esse una descrizione:

1. Biglietti: tale entita’ rappresenta lo storico dei biglietti ordinary e di quelli riferiti ad venti

tenuti dal museo.

2. Riduzioni: tale entita’ raprpesenta le possibili percentuali di sconto applicabili alle singole

emissioni giornaliere.

3. Servizi Accessori: tale entita’ rappresenta i possibili servizi accessori che i museo mette a

disposizione dei propri client.

4. Emissioni: tale entita’ memorizza le single emissioni eseguite attraverso il sistema di

biglietteria on-line del museo.

Schema cocnettuale (0,N) (1,N)

ha

Biglietti Riduzioni

(1,N) (0,N)

riferis possi

cono ede

(0,1)

(1,1) Servizi

Acecssori

Emissioni (0,N) possi (0,N)

ede

Gli attributi di entita’ possono essere cosi’ riassunti:

1. Biglietti: ID – codice identificativo del biglietto, EVENTO – identificativo evento/emission

ordinaria, TARIFFA – costo ordinario del biglietto, DATA_INIZIO – data inizio evento,

DATA_FINE – data fine evento;

2. Riduzioni: ID – codice identificativo della riduzione, DESCRIZIONE – descrizione della

riduzione, DOCUMENTO – tipologia di document necessario per accedere allo sconto,

SCONTO – percentuale di sconto da applciare (valore da 1 a 100);

3. Servizi acecssori: ID – codice identificativo del servizio, DESCRIZIONE – descrizione del

servizio, COSTO – costo del servizio;

4. EMISSIONI: ID – codice identificativo dell’emisione, DATA_EMISISONE – date emission del

biglietto, INIZIO_VALIDITA: data inizio validita’, FINE_VALIDITA – data fine validita’, COSTO –

costo totale pagato

Si conduce nel seguito un’analisi delle relazioni per lo schema concettuale proposto. Si noti, anche

sulla base delle supposizioni fatte durante l’analisi del problem ache:

1. La relazione biglietti/riduzioni e’ di tipo molti a molti e necessita di essere normalizzata sulla

base delle regole di normalizzazione definite nelal teoria delle absi di dati. A tal proposito si

aggiungera’ una tabella intermedia per la trasformazione della relazione molti a molti in una

relazione di tipo uno a molti.

2. Medesimo discorso vale per la relazione tra le emissioni e is ervizi accessory pertanto sara’

aggiunta una tabella intermedia per la trasformazione della relazione molti a molti in una

relazione di tipo uno a molti.

3. Non si rende necessaria alcuna normalizzazione intermedia tra le entita’ emissioni e biglietti

ed emissioni e riduzioni in quanto tali relazioni sono di tipo uno a uno / uno a molti

4. Sempre epr le regole di normalizzazione si rende inoltre necessaria una entita’

supplementare per i documenti di riconoscimento al fine di evitare la duplicazioni di

informazioni sulla tabella delle riduzioni (due distinti riduzioni possono infatti richiedere il

medesimo tipo di documento per la verifica pertanto e’ bene centralizzare tale

informazioni).

Modello relazionale