Tesina Basi di Dati Catena Cinema Multisala

Base dati catena multisala

Facoltà di Ingegneria Informatica, Federico II Anno accademico 2016-2107 Corso di Basi di Dati tenuto dal prof. Vincenzo Moscato. Studenti: Carmine Cesarano, Michele De Sena, Enza D’Angelo.

Questo lavoro si basa sulla traccia assegnata al corso di Basi di Dati I dell’attuale anno accademico, riguardante la creazione di un database per la gestione di una serie di servizi web forniti da una catena di cinema multisala. Dapprima verrà introdotta la traccia, poi si passerà all'analisi del problema e alla strutturazione della soluzione, andando dalla descrizione in ER alla implementazione SQL. In seguito sarà analizzata la costruzione della GUI in PHP/HTML.

Traccia

Una multinazionale di informatica ha recentemente acquisito una serie di società che gestiscono una serie di servizi web per la prenotazione di biglietti a cinema collocati sul territorio svizzero (in particolare ogni società gestisce la prenotazione per i cinema di un singolo cantone). Come parte della nuova strategia gestionale, la suddetta società intende fornire ai propri utenti un servizio centralizzato per:

• La consultazione della programmazione delle proiezioni di film presso i vari cinema;
• La prenotazione ed acquisto on-line di biglietti.

La società prevede che i servizi sopraelencati siano accessibili dai propri utenti mediante interfacce web. Ovviamente le informazioni riguardo i cinema di un dato cantone, la relativa programmazione, gli orari, i prezzi sono di competenza delle singole società locali, ciascuna delle quali ha nel tempo sviluppato un proprio sistema informativo. Mentre le informazioni sui film devono essere recuperate da siti specializzati gestiti da terze parti (e.g. IMDb). Infine, il pagamento con carta di credito deve essere effettuato in modalità sicura sfruttando web service offerti da istituti di credito certificati.

Descrizione del problema

Il database è incentrato sugli elementi che appartengono alla realtà di interesse “consultazione, prenotazione e gestione del calendario”, quali Cinema, Sale, Film, Programmazione, Prenotazioni, Utenti e Biglietti. Pertanto sono considerate solo quelle classi in stretta correlazione con la traccia, ovvero non sono implementate altre funzionalità standard che potrebbero essere implementate in un sistema gestionale (amministrazione personale ad esempio).

Progettazione concettuale

In fase di progettazione è stata scelta e adottata una strategia top-down. Questo perché le specifiche utente sono chiare fin dall’inizio. Sono stati quindi individuati i macro concetti e a partire da questi si è proceduto con raffinamenti successivi, esplicitando di volta in volta nuovi dettagli. Analizzando le specifiche del paragrafo 1 possiamo stilare il seguente glossario.

Glossario

Diagramma E/R

Figura 1: diagramma E/R del sistema cinema

Dizionario dati

Entità

Associazioni

NOTE: CALENDARIO AFFERENZA_SALA La cardinalità di partecipazione all’associazione è opzionale perché un cinema può o meno decidere di introdurre, al momento della pubblicazione, il numero della sala nel calendario.

Progettazione logico-relazionale

Prima ancora di tradurre lo schema concettuale in quello logico è opportuno analizzare lo schema ER, al fine di apportare delle modifiche che rendano più efficiente l’implementazione finale.

Attributi multivalore

Cinema, È stato rimosso l’attributo “recapito”, presente per essere sostituito dall’entità “RECAPITO_CINEMA” opportunamente associata al cinema da una relazione 1-N, effettuando di fatto un partizionamento verticale.

Analisi delle ridondanze

posti_occ, posti_disp, L’unica ridondanza è dovuta agli attributi calcolabili, data una occorrenza p di contare le occorrenze in cui è presente p nel primo caso e sottraendo al numero di posti della sala, il numero di posti occupati, nel secondo caso.

Eliminazione delle generalizzazioni

CAST: ATTORE, REGISTA La specializzazione in e è del tipo totale e disgiunta. Questa può essere tradotte accorpando le entità sottoclassi nella superclasse ed includendo nella superclasse l’attributo “tipo” che indica la sottoclasse a cui appartiene ciascuna tupla. Questa soluzione è attuabile solo per le spec. totali/disgiunte. Il fatto che le sottoclassi non specificano con alcun attributo la superclasse garantisce la non CAST presenza di valori nulli in e quindi il massimo grado di efficienza per questa soluzione.

Eliminazione attributi composti

Era stato pensato, in una fase iniziale della progettazione, di implementare nello schema ER gli indirizzi come attributi composti. Questa funzionalità non è resa però disponibile dal tool utilizzato (JDER), dunque questa fase non è necessaria.

Scelta identificatori codice

Quasi per tutte le entità è stato preferibile introdurre l’attributo come identificatore. Osserviamo infatti che quasi tutte le entità referenziano chiavi esterne, quindi il codice, rispetto alle altre possibili alternative, garantisce un risparmio sia in termini di byte che di tempo durante i join tra le tabelle. Solo per l’entità POSTO si è deciso di identificare le tuple con gli attributi numero e fila.

Diagramma E/R ristrutturato

Figura 2: Diagramma E/R ristrutturato

Approcci di conversione da E/R a relazionale

Per rendere più comprensibile il significato dello schema è stato opportuno rinominare gli identificatori delle entità coinvolte assegnando loro un nome più comprensibile rispetto a “codice”. Le entità sono state tradotte con una tabella che ha il nome dell’entità stessa, ma al plurale. Le associazioni 1-N possono essere tradotte con la “soluzione 2”. Questa risulta essere la più efficiente perché permette di ridurre notevolmente il numero di tabelle (quindi la dimensione fisica della base) e la ridondanza dati. Secondo questa soluzione l’associazione non compare nella traduzione e i suoi attributi insieme all’identificatore lato N vengono inclusi come attributi nella tabella lato 1. L’unico inconveniente di questa soluzione, è la presenza di molti valori null in corrispondenza di partecipazione opzionale dell’entità lato 1. Si preferisce in questi casi considerare una terza tabellache traduc