A. Veneziani Analisi e soluzione esercizio 2 pagina 53

Transcript

1 A. Veneziani Analisi e soluzione esercizio 2 pagina 53 Testo del problema Rappresenta i dati e le relazioni tra i dati necessari a gestire un sistema di prenotazione di un teatro di 1000 posti suddivisi in 25 file di 40 poltrone l una. Ogni poltrona è individuata da una lettera e da un numero. Analisi del problema Il testo parla di un singolo teatro in cui si dovrà effettuare la gestione delle prenotazioni. Il teatro, come il testo ben evidenzia è dotato di numero poltrone. Le prenotazioni saranno effettuate da potenziali spettatori agli spettacoli. Le prenotazioni dovrebbero essere relative ad uno spettacolo, e presumibilmente avvenire su un determinato giorno. Si suppone anche che lo spettatore possa effettuare un gruppo di prenotazioni, ad esempio per se ed amici o familiari, quindi le stesse siano sotto lo stesso nominativo. Le entità che possiamo derivare dalla logica di questo discorso sono: Poltrone Spettatori Prenotazioni Spettacoli Esse saranno legate nel seguente modo: Gli spettatori effettueranno delle prenotazioni, relative alle poltrone per una certa data (legata ad uno spettacolo). Ossia gli Spettatori saranno quindi correlati all entità Prenotazioni. L entità Prenotazioni sarà a sua volta associata all entità Poltrone, in quanto sono le poltrone l oggetto della prenotazione. Nel contempo le singole prenotazioni dovranno tener conto, ossia essere associate agli spettacoli, in quanto una prenotazione che non sia abbinata ad uno spettacolo non ha senso. Si conclude che il diagramma ha come entità centrale dello stesso l entità Prenotazioni e ad essa e tramite essa sono collegate le entità Poltrone, Spettatori e spettacoli. Infatti, ad ogni prenotazione vi è un prenotante (Persone), una o più poltrone (Poltrone) prenotate e la prenotazione si riferisce sicuramente a qualche spettacolo (Spettacoli). Vediamo quali saranno le molteplicità da assegnare. Uno spettatore può compiere più prenotazioni, ed una prenotazione è nominale (ossia legata a chi l ha effettuata) e quindi può essere correlata e viene effettuata (richiesta da) ad unico spettatore. Quindi tra Prenotazioni e Spettatori la molteplicità sarà 1 a n con 1 verso Spettatori e N verso Prenotazioni. Si suppone che l associazione sia totale in entrambi i sensi, in quanto uno spettatore, se registrato avrà compiuto delle prenotazioni in teatro e la prenotazione ovviamente se esiste ha certamente uno spettatore che l ha richiesta. Una prenotazione sarà relativa ad un certo spettacolo e uno spettacolo potrà avere più prenotazioni che lo riguardano. Anche qui difficile che esista uno spettacolo senza prenotazioni (quindi totalità), e viceversa una prenotazione deve sempre riguardare una data in cui vi sia uno spettacolo (altrimenti si prefigura una evidente incoerenza logica nel DB stesso). Una prenotazione potrà riguardare anche più posti e quindi più poltrone (per la stessa data), e una poltrona (nel tempo) potrà subire più prenotazioni. Sicuramente una prenotazione riguarda qualche poltrona, mentre si potrebbe ipotizzare (con ipotesi un poco forzata) che certe poltrone non abbiano mai subito alcuna prenotazione (magari perché in posizione scomoda e lontana dal palco). Fatta ed accettata questa ipotesi, l associazione tra Poltrone e Prenotazioni risulterebbe parziale da Poltrone verso Prenotazioni. Infine tra Prenotazioni e Spettacoli si ha una associazione che li lega, ossia una prenotazione si deve riferire necessariamente ad uno spettacolo, e uno spettacolo avrà più prenotazioni. Anche qui l associazione è in entrambi i versi totale. Come vincoli, prevederemo che la data di una prenotazione sia inclusa all interno delle due date nel quale la rappresentazione di un certo spettacolo (quello per il quale avviene la prenotazione) è prevista. Pagina 1

2 Potremo anche attribuire ad ogni poltrona un attributo che indichi se la stessa (al momento della prenotazione) risulti disponibile o no, in quanto magari soggetta a lavori di riparazione della stessa o manutenzione del locale. Consideriamo ora gli attributi delle varie entità considerate: Poltrone o Fila o Numero o Disponibile Spettatori o CodFisc o Nome o Cognome o Via o NCiv o Citta o Telefono o Mail Spettacoli o Id_Spettacolo o Titolo o DataInizio o DataFine o Prezzo o AttorePrinc o Compagnia Prenotazioni o Id_Prenotazione o DataPreno o DataReg Schema del DB e delle relazioni Poltrone(Fila, Numero, Disponibile) Spettatori(CodFisc, Nome, Cognome, Via, NCiv, Citta, Telefono, Mail) Spettacoli(Id_Spettacolo, Titolo, DataInizio, DataFine, Prezzo, AttorePrinc, Compagnia) Prenotazioni(Id_Prenotazione, DataPreno, DataReg, Id_Spettacolo, CodFisc) Prenotazioni_Poltrone(Id_Prenotazione, Fila, Numero) La relazione Prenotazioni_Poltrone permette l associazione n a m tra Poltrone e Prenotazioni, ossia di prenotare più posti per ogni operazione di prenotazione a nome di un certo spettatore. Forma tabellare delle relazioni Poltrone Fila CHAR 1 Numero TINYINT Primaria Disponibile BIT 1 Pagina 2

3 Spettatori CodFisc CHAR 16 Primaria Nome VARCHAR 40 Cognome VARCHAR 40 Via VARCHAR 40 NCiv VARCHAR 6 Citta VARCHAR 30 Telefono VARCHAR 20 Mail VARCHAR 30 Spettacoli Id_Spettacolo INT UNSIGNED Primaria Titolo VARCHAR 80 DataInizio DataFine Prezzo DECIMAL 5,2 AttorePrinc VARCHAR 60 Compagnia VARCHAR 40 Prenotazioni Id_Preno INT UNSIGNED Primaria DataPreno DataReg Id_Spettacolo INT UNSIGNED Esterna CodFisc CHAR 16 Esterna Prenotazioni_Poltrone Id_Preno INT UNSIGNED Fila CHAR 1 Primaria Numero TINYINT Esterna Esterna Si noti anche che, come regola generale: Il tipo delle chiavi primarie ed esterne utilizzate per implementare delle associazioni sono identici (in tipo ed ampiezza). I campi su due tabelle diverse, che implementano una relazione, hanno di norma un nome uguale. Vincoli V1(Spettacoli): DataInizio < DataFine V2(Prenotazioni): DataPreno >= DataReg V3(Poltrone): Numero <= 40 V4(Poltrone): Riga >= A AND Riga <= Z I vincoli sopra indicati saranno implementati con opportune istruzioni CHECK, da inserire dentro la CREATE TABLE della tabella dove operano. Dal punto di vista prettamente operativo c è da sottolineare che solo le Pagina 3

4 ultimissime versioni di MySQL (ad es. vers. 8.x) e del suo clone open source MariaDB (vers x) hanno reso effettivamente operante tale istruzione SQL. Script di creazione SQL CREATE TABLE Poltrone ( Fila CHAR(1) NOT NULL, Numero TINYINT NOT NULL, PRIMARY KEY(Fila, Numero), CHECK (Numero <= 40), CHECK (Fila >= 'A' AND Fila <= 'Z'), Disponibile BIT NOT NULL ); CREATE TABLE Spettatori ( CodFisc CHAR(16) PRIMARY KEY, Nome VARCHAR(40) NOT NULL, Cognome VARCHAR(40) NOT NULL, Via VARCHAR(40) NOT NULL, NCiv VARCHAR(6) NOT NULL, Citta VARCHAR(40) NOT NULL, Telefono VARCHAR(20) NOT NULL, Mail VARCHAR(20) NOT NULL ); CREATE TABLE Spettacoli ( Id_Spettacolo INT UNSIGNED PRIMARY KEY, Titolo VARCHAR(80) NOT NULL, DataInizio NOT NULL, DataFine, PrezzoBigl DECIMAL(5,2) NOT NULL, AttorePinc VARCHAR(60), Compagnia VARCHAR(40), CHECK(DataInizio <= DataFine) ); CREATE TABLE Prenotazioni ( Id_Preno INT UNSIGNED PRIMARY KEY, DataPreno NOT NULL, DataReg NOT NULL, Id_Spettacolo INT UNSIGNED NOT NULL, CodFisc CHAR(16) NOT NULL, CHECK (DataPreno >= DataReg), FOREIGN KEY(Id_Spettacolo) REFERENCES Spettacoli(Id_Spettacolo), FOREIGN KEY(CodFisc) REFERENCES Spettatori(CodFisc) ); CREATE TABLE Prenotazioni_Poltrone ( Id_Preno INT UNSIGNED NOT NULL, Fila CHAR(1) NOT NULL, Numero TINYINT NOT NULL, PRIMARY KEY(Id_Preno, Fila, Numero), Pagina 4

5 FOREIGN KEY(Id_Preno) REFERENCES Prenotazioni(Id_Preno), FOREIGN KEY(Fila, Numero) REFERENCES Poltrone(Fila, Numero) ); Schema UML del database Pagina 5