Schema relazionale, vincoli e viste
Vediamo una traduzione dello schema ER del caso di studio in uno schema relazionale equivalente. Come primo passo rimuoviamo dallo schema ER gli attributi multivalore. In particolare:
- per gli attributi multivalore video e immagini dell'entità messa in scena creiamo una unica entità materiale con attributi file (percorso e nome del file che contiene l'informazione), tipo (immagine o video e relativo tipo) e dimensione (dimensione del file in MB) e la colleghiamo con una relazione uno a molti all'entità di appartenenza;
- l'attributo multivalore orario dell'entità biglietteria viene trasformato in un'entità debole di biglietteria con attributi giorno, inizio e fine e chiave parziale giorno e inizio;
- l'attributo multivalore stipendio dell'entità biglietteria viene trasformato in un'entità debole di dipendente con attributi importo e inizio e chiave parziale inizio.
La traduzione dello schema ER risultante è la seguente:
teatro(nome, telefono, fax, indirizzo, email, url)
biglietteria(nome, indirizzo, email, telefono, teatro)
orario(biglietteria, giorno, inizio, fine)
notizia(data, ora, oggetto, testo)
newsletter(teatro, data, ora, oggetto)
dipendente(cf, nome, cognome, dataDiNascita, luogoDiNascita, residenza, telefonoFisso, telefonoMobile, email)
lavoro(teatro, dipendente, dataDiAssunzione, ruolo, cda)
stipendio(dipendente, inizio, importo)
spazio(nome, indirizzo, pianta, capienza)
luogo(teatro, spazio)
stagione(nome, biennio, teatro)
spettacolo(titolo, descrizione, annoProduzione)
proposta(nomeStagione, biennioStagione, spettacolo)
messaInScena(data, ora, spazio, spettacolo, postiDisponibili, prezzoIntero, prezzoRidotto, prezzoStudenti)
materiale(file, tipo, dimensione, dataSpettacolo, oraSpettacolo, spazioSpettacolo)
prenotazione(dataSpettacolo, oraSpettacolo, spazioSpettacolo, numero, data, ora, posto, tipo, prezzo)
commento(autore, data, ora, testo, dataSpettacolo, oraSpettacolo, spazioSpettacolo)
risposta(autoreRisposta, dataRisposta, oraRisposta, autore, data, ora)
produzione(produttore, spettacolo)
produttore(nome, tipo, indirizzo, telefono, email)
interprete(nome, ruolo, cv)
cast(spettacolo, interprete)
biglietteria(teatro) --> teatro(nome)
orario(biglietteria) --> biglietteria(nome)
newsletter(teatro) --> teatro(nome)
newsletter(data, ora, oggetto) --> notizia(data, ora, oggetto)
lavoro(teatro) --> teatro(nome)
lavoro(dipendente) --> dipendente(cf)
stipendio(dipendente) --> dipendente(cf)
luogo(teatro) --> teatro(nome)
luogo(spazio) --> spazio(nome)
stagione(teatro) --> teatro(nome)
messaInScena(spazio) --> spazio(nome)
messaInScena(spettacolo) --> spettacolo(titolo)
materiale(dataSpettacolo, oraSpettacolo, spazioSpettacolo) --> messaInScena(data, ora, spazio)
prenotazione(dataSpettacolo, oraSpettacolo, spazioSpettacolo) --> messaInScena(data, ora, spazio)
commento(dataSpettacolo, oraSpettacolo, spazioSpettacolo) --> messaInScena(data, ora, spazio)
risposta(autoreRisposta, dataRisposta, oraRisposta) --> commento(autore, data, ora)
risposta(autore, data, ora) --> commento(autore, data, ora)
produzione(produttore) --> produttore(nome)
produzione(spettacolo) --> spettacolo(titolo)
cast(spettacolo) --> spettacolo(titolo)
cast(interprete) --> interprete(nome)
Seguono alcune osservazioni:
-
un contributo multimediale associato ad una messa in scena viene inserito nella tabella materiale mediante un riferimento al nome del file che lo contiene, piuttosto che con l'uso di campi binari. Questo nome può essere usato come chiave;
- la specializzazione di produttore in interno e esterno viene tradotta in una unica tabella produttore. L'attributo tipo di tale tabella discrimina se il produttore è interno o esterno. In caso di produttore esterno possono essere usati i campi indirizzo, telefono e email;
- alcune tabelle derivanti da entità concettuali hanno chiavi lunghe. Le tabelle che corrispondono a relazioni molti a molti che coinvolgono queste entità soffrono dello stesso problema. Esempi sono messaInScena, commento, notizia e la relazione newsletter. Per ragioni di efficienza dell'implementazione è possibile introdurre, per queste relazioni incriminate, degli attributi codice che vanno a sostituire le chiavi lunghe. Questa soluzione ha il vantaggio di ridurre la dimensione delle chiavi e lo svantaggio di introdurre un attributo sintetico che non corrisponde ad una informazione presente nella realtà modellata. Inoltre, il codice deve essere mantenuto univoco per ogni istanza dell'entità;
I vincoli di dominio verranno aggiunti in fase di progettazione fisica quando gli attributi delle tabelle verranno associati ai loro domini. Altri vincolo che verranno realizzati durante la progettazione fisica sono le regole aziendali identificate nel modello ER.
Infine possiamo definire le seguenti viste sui dati:
- una vista spettacoli che descrive, per ogni teatro e relativa stagione, i corrispondenti spettacoli messi in scena. Ogni spettacolo deve essere descritto da: titolo, descrizione, data, ora, luogo, indirizzo, posti disponibili e prezzi per i diversi tipi di biglietto. Le porzione di base di dati coinvolta è formata dalle seguenti tabelle: stagione, proposta, spettacolo, scena, messaInScena e spazio. La vista può essere accessibile sia dagli utenti esterni della rete (i clienti dei teatri) che dai dipendenti interni alla rete;
- una vista interpreti che descrive, per ogni teatro e relativa stagione, gli interpreti che hanno partecipato agli spettacoli. Le tabelle coinvolte sono: stagione, proposta, spettacolo, cast e interprete. La vista è accessibile solo dai dipendenti interni alla rete del settore comunicazione, ufficio stampa e relazioni con il pubblico;
- una vista dipendenti che descrive, per ogni teatro, i relativi dipendenti. Per ogni dipendente si vuole esporre: cognome, nome, cf, età, telefono, email, ultimo stipendio, data di assunzione, ruolo nel teatro e se il dipendente fa parte del CdA del teatro. Le tabelle coinvolte sono: lavoro, dipendente e stipendio. La vista è accessibile dai dipendenti interni alla rete del settore amministrazione, controllo e finanza;
- una vista che, per ogni spettacolo terminato, mostra il numero di spettatori paganti, l'affluenza (il rapporto tra paganti e capienza) e l'incasso. Le tabelle usate sono spettacolo, scena, messaInScena, spazio e prenotazione. La vista è riservata ai dipendenti interni alla rete del settore amministrazione, controllo e finanza.
Si noti che le viste definite possono essere usate in due modi: per far accedere un gruppo di utenti ad una porzione specifica dei dati e, come vedremo in fase di progettazione fisica, per realizzare alcune transazioni tipiche dell'applicazione.