Che materia stai cercando?

Tesina Basi di Dati Catena Cinema Multisala

Il documento riguarda la documentazione relativa all'elaborato d'esame di Basi di Dati. Il progetto presentato riguarda una catena di cinema multisala. E' descritta attentamente la progettazione e l'implementazione di tutti i servizi web necessari alla gestione dell'attività e la relativa creazione della base di dati.

Esame di Basi di Dati docente Prof. V. Moscato

Anteprima

ESTRATTO DOCUMENTO

3 Progettazione Concettuale

In fase di progettazione è stata scelta e adottata una strategia top-down. Questo perché le

specifiche utente son 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.

3.1 Glossario

Termine Descrizione Collegamenti

CINEMA Sala

Luogo dove sono presenti sale

cinematografiche

SALA Cinema, Poltrona,

La sala dove si proietta un film

POSTO Sala, Prenotazione

La poltrona fisica del cinema

FILM Programmazione, Sala

La pellicola proiettata

UTENTI Prenotazione

L’utente che prenota un film

PROGRAMMAZIONE Film, Sala

Lo svolgersi di una proiezione di un

film

PRENOTAZIONI Sala, Programmazione,

Effettuate dagli utenti per riservare Posto

un posto per una programmazione

3.2 Diagramma E/R

Figura 1: diagramma E/R del sistema cinema

3.3 Dizionario Dati

3.3.1 Entità

Classe Descrizione Attributi Identificatori

UTENTE Cod_utente,Cognome,Nome, Cod_utente

Utenti registrati alla piattaforma Username, Pwd, Email

FILM Cod, titolo, anno, Cod

Stora tutti i film mandati in Produttore, Genere,

programmazione fino ad ora durata, data_uscita

RECENSIONE Cod, testo Cod

Contiene le recensioni dei soli

film in programmazione

CAST Cod, nome, cognome, Cod

Gruppo persone che lavora nella data_nascita

produzione (generalizza le entità

attore e regista)

CALENDARIO Cod, Data, Ora, Cod

Comprende tutte le istanze di posti_occ, posti_disp

proiezione, identificate da un

codice univoco

CINEMA Cod, Nome, Numero_Sale, Cod

Insieme dei cinema multisala Città, indirizzo,

Civico, Recapito

SALA Numero, Capienza, Numero

Insieme delle sale Superficie

POSTO Numero, Fila Numero,Fila

Contiene tutti i posti, di tutte le

sale, di tutti i cinema Cod, data_prenotazione, Cod

PRENOTAZIONE Contiene tutte le istanze di pagato

prenotazione utente

3.3.2 Associazioni

Associazione Descrizione Classi coinvolte

AFFERENZA_REC FILM (0,1)

Mette in relazione i film con un'unica recensione RECENSIONE (1,1)

PARTECIPAZIONE FILM (1,N)

Mette in relazione i film con il relativo cast, specificando il CAST (1,N)

RUOLO (opzionale) degli attori

PROIEZIONE FILM (1,N)

Relaziona i film in programmazione con un calendario di CALENDARIO (1,1)

tutte le proiezioni

AFFERENZA_CIN CALENDARIO (1,1)

Associa un istanza del calendario ad un cinema CINEMA (1,N)

LISTA_SALE CINEMA (1,N)

Mette in relazione ogni cinema con le relative sale SALA (1,1)

LISTA_POSTI SALA (1,N)

Mette in relazione ogni sala con i relativi posti POSTO (1,1)

AFFERENZA_SALA CALENDARIO (0,1)

Associa una proiezione (istanza di calendario) ad una sala SALA (0,N)

AFFERENZA_POSTO PRENOTAZIONE (1,N)

Mette in relazione le prenotazioni con i posti, POSTO (0,N)

PREZZO

specificando il per ogni afferenza.

ORDINE UTENTE (0,N)

Associa un’istanza di prenotazione con l’utente che l’ha PRENOTAZIONE (1,1)

effettuata.

AFFERENZA_PREN CALENDARIO (0,N)

Mette in relazione le prenotazioni con le relative istanze PRENOTAZIONE (1,1)

di calendario

NOTE: CALENDARIO AFFERENZA_SALA

La cardinalità di partecipazione di all’associazione è opzionale

perché un cinema può o meno decidere di introdurre, al momento della pubblicazione, il numero

della sala nel calendario.

4 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.

4.1 Attributi Multivalore CINEMA,

E’ 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.

4.2 Analisi delle ridondanze

posti_occ posti_disp,

L’unica ridondanza è dovuta agli attributi e calcolabili, data una

PROGRAMMA, AFFERENZA_PREN

occorrenza p di contando le occorrenze di in cui è presente p

nel primo caso e sottraendo al numero di posti della sala, il numero di posti occupati, nel secondo

caso.

4.3 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.

4.4 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.

4.5 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 4.6 Diagramma E/R ristrutturato

Figura 2: Diagramma E/R ristrutturato

4.7 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 comprare 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 tabella

che traduce la relazione che ha per chiave l’identificatore lato 1 e include come attributo

AFFERENZA_SALA

l’identificatore lato N. è stata tradotta con questa strategia.

Le associazioni 1-1 possono essere tradotte anch’esse secondo la “soluzione 2”. La chiave dell’entità

lato opzionale diventa attributo della tabella che traduce l’entità lato non opzionale.

OSS. La traduzione tramite la soluzione 1 (l’associazione diventa una tabella) si rende necessaria

solo nel caso in cui entrambe le entità partecipano con cardinalità opzionale.

Nelle nostre associazioni 1-1 non si presenta questo caso.

Le associazioni N-N sono tradotte in una tabella la cui chiave primaria è la combinazione degli

identificatori delle due entità collegate.

4.8 Correttezza dello schema, verifica della normalità

Da un’attenta analisi, che tralasciamo, risulta che tutti gli schemi relazionali R della base rispettano

i

la BCNF pertanto è garantita una decomposizione senza perdita (R=R1joinR2).

4.9 Traduzione dello schema in relazionale

Risultato della traduzione finale, dopo aver ottimizzato lo schema con gli step precendenti.

RECENSIONI (CodRecensione, Film, Testo)

FILM_PROGRAMMAZIONE (CodFilm, Titolo, Anno, Produttore, Genere, Durata,

DataUscita)

CAST (IdCast, Tipo, Nome, Cognome, DataNascita)

PARTECIPAZIONE (Film, Cast, Ruolo)

CALENDARI (CodProgramma, Ora, Data, Film, Cinema)

CINEMA (CodCinema, Nome, NumeroSale, Citta, Indirizzo, Civico)

RECAPITI_CINEMA (Numero, Cinema)

SALE (NumSala, Cinema, Superficie, Capienza)

AFFERENZE_SALA (Programma, Sala, Cinema)

POSTI (Numero, Fila, Sala, Cinema)

PRENOTAZIONI (IdPrenotazione, DataPrenotazione, Pagato, Utente, Programma)

UTENTI (CodUtente, Username, Pwd, Cognome, Nome, E-mail)

AFFERENZE_POSTO(Prenotazione, NumPosto, NumFila, Sala, Cinema, Prezzo)

Figura 3: Schema E/R SQL Data Modeler tradotto

4.9.1 Vincoli di integrità referenziale

Chiave Esterna Chiave Primaria (referenziata)

PARTECIPAZIONE(Film) FILM_STORICO(CodFilm)

PARTECIPAZIONE(Cast) CAST(IdCast)

SALE(Cinema) CINEMA(CodCinema)

POSTI(Sala) SALE(NumSala)

POSTI(Cinema) CINEMA(CodCinema)

AFFERENZE_POSTO(Prenotazione) PRENOTAZIONE(CodPrenotazione)

AFFERENZE_POSTO(NumPosto) POSTI(Numero)

AFFERENZE_POSTO(NumFila) POSTI(Fila)

AFFERENZE_POSTO(Sala) POSTI(Sala)

AFFERENZE_POSTO(Cinema) POSTI(Cinema)

PRENOTAZIONI(Utente) UTENTI(CodUtente)

PRENOTAZIONI(Programma) CALENDARI(CodProgramma)

RECAPITI_CINEMA(Cinema) CINEMA(CodCinema)

CALENDARI(Film) FILM_PROGRAMMAZIONE(CodFilm)

CALENDARI(Cinema) CINEMA(CodCinema)

AFFERENZE_SALA(Programma) CALENDARI(CodProgramma)

AFFERENZE_SALA(Sala) SALE(NumSala)

AFFERENZE_SALA(Cinema) SALE(Cinema)

RECENSIONI(Film) FILM_PROGRAMMAZIONE(CodFilm)

5 Business Rules

BR01. Le prenotazioni sono spostate nello storico alla fine di ogni anno (Stored Procedure)

BR02. I film sono tenuti in programmazione per 7 giorni (gestito a livello applicativo)

BR03. Un utente può prenotare un film fino ad un’ora prima della sua programmazione (gestito a

livello applicativo)

BR04. Le chiavi delle tabelle sono incrementate automaticamente.

BR05. Le chiavi possono essere aggiornate senza perdita di dati riferiti.

BR06. Numero massimo di utenti registrabili 2500.

6 Implementazione fisica

6.1 Dimensionamento e specifiche

Per effettuare delle considerazioni sul comparto fisico della base, si presenta una Tavola dei volumi

nella quale si riportano le cardinalità delle entità e delle associazioni.

Le specifiche utente saranno integrate con opportune ipotesi.

I volumi verranno aggiornati dopo 2 anni di servizio. Pertanto lo storage è calcolato a partire da

quest’anno (anno inizio attività) e considerando l’anno seguente.

 La società gestisce 50 cinema con un totale di 150 sale. Si suppone inoltre che ogni sala

abbia mediamente 80 posti, per un totale di 12000 posti.

 Come da specifiche, sono registrati alla piattaforma circa 1000 utenti.

 Si suppone che ogni cinema abbia al massimo 2 recapiti telefonici.

 Si suppone che ogni sala effettui in media 3 proiezioni al giorno, per un totale di 450

proiezioni giornaliere (164.250 proiezioni all’anno).

 Supposto che un utente possa prenotare più posti con un istanza di prenotazione, e che per

ogni proiezioni in media la sala è piena al 40%, il numero giornaliero di posti prenotati

450proiezioni x 80postix 0,4 = 14.400 (5.256.800 afferenze_posto all’anno)

 Supposto che ogni prenotazioni sia effettuata in media su tre posti contiamo circa

5.256.800/3 = 1.752.266 prenotazioni all’anno

 Ogni anno sono proiettati circa 70 film.

 Per ogni film si suppone che il registra sia unico e che recitino in media 10 attori principali.

Ogni attore ha recitato in media in 3 film. Ogni occorrenza di film partecipa all’associazione

PARTECIPAZIONE 11 volte. L’associazione partecipazione ha un numero complessivo di 70 x

3 x 11 = 2310 occorrenze di partecipazione

 Se ogni attore ha recitato in 3 film, allora devono esserci circa 2310 / 3 = 770 attori e registi

registrati.

6.2 Tavola dei Volumi

Tipo Costrutto Volume

E Recensioni 70

E Film_Programmazione 70

E Cast 770

E Calendari 164.250

E Cinema 50

E Recapiti_cinema 100

E Sale 150

E Posti 12000

E Prenotazioni 1.752.266

A Afferenze_sala 164.250

A Afferenza_posto 5.256.800

A Partecipazione 2310

6.2.1 RECENSIONI

Attributo Tipo Byte Initial Next

Occorrenze: 70 Occorrenze: 70

CodRecensione NUMBER(3) 3 210 210

Film NUMBER(3) 3 210 210

Testo CLOB 4 280 280

TOT 700 700

Storage Initial (Kb) Next (Kb) Initial Next

0,68 0,68 701 701

6.2.2 FILM_PROGRAMMAZIONE

Attributo Tipo Byte Initial Next

Occorrenze: 70 Occorrenze: 70

CodFilm NUMBER(3) 3 210 210

Titolo VARCHAR2(30) 30 2100 2100

Anno CHAR(4) 4 280 280

Produttore VARCHAR2(10) 10 700 700

Genere VARCAHR2(10) 10 700 700

Durata NUMBER(4,2) 4 280 280

DataUscita DATE 7 490 490

TOT 4760 4760

Storage Initial (Kb) Next (Kb) Initial Next

4,65 4,65 4761 4761

Si presume che l’anno seguente escano ancora 70 film.

6.2.3 CAST

Attributo Tipo Byte Initial Next

Occorrenze: 770 -

IdCast NUMBER(4) 4 3.080 -

Tipo VARCHAR2(7) 7 5.390 -

Nome VARCHAR2(20) 20 15.400 -

Cognome VARCHAR2(20) 20 15.400 -

DataNascita DATE 7 5.390 -

TOT 40.040 -

Storage Initial (Kb) Next (Kb) Initial Next

43,61 - 44.661 -

6.2.4 PARTECIPAZIONE

Attributo Tipo Byte Initial Next

Occ: 2.310 Occ: 1.000

Film NUMBER(3) 3 6.930 3.000

Cast NUMBER(4) 4 9.240 4.000

Ruolo VARCHAR2(20) 20 46.200 20.000

TOT 62.370 27.000

Storage Initial (Kb) Next (Kb) Initial Next

60,90 26,37 62.371 27.001

6.2.5 CALENDARI

Attributo Tipo Byte Initial Next

Occ: 164.250 Occ: 82.125

CodProgramma NUMBER(6) 5 821.250 410.625

Ora NUMBER(4,2) 4 657.000 328.500

Data DATE 7 1.149.750 574.875

Film NUMBER(3) 3 492.750 246.375

Cinema CHAR(2) 2 328.500 164.250

TOT 3.449.250 1.724.625

Storage Initial (Kb) Next (Kb) Initial Next

3368,40 1684,20 3.449.251 1.724.626

Si suppongono per l’anno successivo 2 proiezioni per sala al giorno


PAGINE

30

PESO

1.04 MB

PUBBLICATO

9 mesi fa


DETTAGLI
Esame: Basi di Dati
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2018-2019

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher c.cesarano di informazioni apprese con la frequenza delle lezioni di Basi di Dati e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Moscato Vincenzo.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Basi di dati

Esercitazione Basi di dati
Esercitazione
Basi di Dati
Dispensa
Basi di Dati - Boyce /Codd
Dispensa
Basi di Dati – Campionato di calcio
Appunto