Esercitazione: Film - Cinema con soluzione passo passo

Traccia

Progettare una base dati per gestire Attori, Registi, Film, Sale, Cinema e Proiezioni.
Attori e Registi sono identificati da un codice e di essi interessano anche il nome, nazionalità e l’anno di nascita.
I Film sono identificati da un codice e di essi interessano anche il titolo, l’anno di produzione, il regista, gli attori che vi recitano e, per ogni attore, se è protagonista o non protagonista.
Il Cinema è identificato da un codice e di essi interessano anche un nome, dalla città e dal numero di sale. La Sala è identificata dal cinema di appartenenza, un numero univoco e deve essere indicato se è 3D o meno.
La Proiezione è il Film trasmesso in una determinata Sala e viene caratterizzata dalla data, l’ora e il numero di spettatori.

Scrivere le interrogazioni SQL che permettono di ottenere:

  • 1. Tutti i film del regista ‘George Lucas’
  • 2. Tutti i film in cui recita ‘Natalie Portman’
  • 3. Il cinema con maggior numero di sale nella città di ROMA
  • 4. L’elenco dei film e il totale degli spettatori che lo hanno visto il giorno 03/03/2014.


Soluzione prima parte - Progettazione Base Dati


Primo Passo: Sottolineare la traccia

Leggere con attenzione la traccia dell'esercizio e sottolineare le informazioni importanti che serviranno per la progettazione della base dati.
Mettere un cerchio alle entità e sottolineare gli attributi delle entità

La corretta comprensione della traccia è metà del lavoro!


Secondo Passo: Primo diagramma concettuale

Disegnare all'inizio solo le entità individuate dalla lettura della traccia.
Ricordare che le entità, e i successivi nomi delle tabelle, è stilisticamente più corretto indicarle al singolare (Es:. ATTORE, SALA, PROIEZIONE)


Terzo Passo: Aggiungere relazioni e attributi

Questo è un passaggio delicato. iniziare dal disegnare gli attributi e proseguire con le relazioni.
Individuare le relazioni non è sempre facile e in questa fase si commettono gli errori più clamorosi che poi comprometteranno tutto l'esercizio.
Rivedere più volte il disegno e aggiungere eventuali relazioni di generalizzazione, come nel nostro esempio nel caso di ATTORE e REGISTA che hanno entrambi gli attributi di una generica PERSONA.


Quarto Passo: Le cardinalità delle relazioni

Entità per entità, devono essere indicate con cura e ragionate le cardinalità delle relazioni.

  • Una proiezione avviene in una sala, e una sala ha una proiezione (RELAZIONE 1 a 1)
  • Un regista può girare molti film, un film ha un solo regista (RELAZIONE 1 a n)
  • Ad esempio, un attore è presente in molti film, in un film partecipano molti attori (RELAZIONE MOLTI A MOLTI)


Quinto Passo: Passaggio al modello logico

Traduzione della relazione molti a molti

Se abbiamo ben disegnato e ragionato il modello concettuale, il passaggio al modello logico avviene in automatico con la traduzione delle relazioni.
Per la relazione MOLTI A MOLTI tra ATTORE e FILM, deve essere introdotta una nuova tabella ATTORE_FILM che riporterà le coppie della chiave del FILM e dell'ATTORE.

Sesto Passo: Passaggio al modello logico

Traduzione della relazione uno a uno

Per la relazione UNO a UNO di SALA e PROIEZIONE, ci sono pochi dubbi su quale sia l'entità che deve puntare all'altra.
Basti pensare che la PROIEZIONE è caratterizzata dal fatto che sia all'interno di una sala, mentre viceversa una sala potrebbe essere chiusa per lavori e non avere PROIEZIONI, o meglio, la proiezione non caratterizza la sala, per cui è ragionevole che sia PROIEZIONE a contenere una chiave esterna verso la SALA.


Settimo Passo: Passaggio al modello logico

Traduzione della relazione uno a molti

Per la relazione UNO a MOLTI ad esempio del CINEMA e delle SALE in esso contenute, sulla entità SALA (entità MOLTI) va inserita la chiave esterna verso il CINEMA. Riflettere sul fatto che una SALA non ha senso di esistere se non all'interno di un dato CINEMA che la contiene e la caratterizza, per cui la tabella SALA, essendo l'entità 'MOLTI' non solo avrà la chiave esterna verso il CINEMA di appartenenza, ma sarà di sicuro una chiave esterna che non potrà mai essere NULL, ovvero o la sala appartiene ad un CINEMA o la sala stessa non esiste. .

Ottavo Passo: Passaggio al modello logico

Traduzione della generalizzazione

La generalizzazione va tradotta con un collasso verso l'alto o verso il basso? Non esistono soluzioni giuste o sbagliate in assoluto, ma solo decisioni opportunamente giustificate. Ovvero, nel momento in cui si prende una decisione deve essere motivata!

Collasso verso l'alto: ATTORE - REGISTA viene riportato in una sola tabella con l'aggiunta di un campo attributo RUOLO, perché alcuni registi sono anche degli attori (Es:. Ron Howard)

Collasso verso il basso: ATTORE - REGISTA vengono divise in due tabelle perché hanno una diversa relazione con il FILM. Mentre un FILM ha più attori (relazione tradotta con la tabella ATTORE_FILM), viene girato da un solo regista, per cui il REGISTA diventa proprio un attributo del FILM, o meglio, nella tabella FILM ci sarà una chiave esterna che punta alla tabella REGISTA. Questa differenza di relazione, a seconda del RUOLO, è più corretta che sia tradotta con due entità distinte per evitare ambiguità. Una sola tabella PERSONA renderebbe ammissibile, a livello di relazione tra i dati, che un FILM potrebbe essere girato da un attore o che potrebbe avere più registi.

Personalmente condivido la seconda scelta, ma da insegnante, opportunamente giustificata, avrei ritenuto praticabile anche la prima decisione.

Nono Passo: Passaggio al modello fisico

Il modello fisico non cambia molto dal livello logico se non per l'aggiunta di alcuni campi che possono essere utili nella vera implementazione reale della base dati. In questo caso sono stati aggiunti dei codici alla tabella ATTORE e REGISTA che identificano in maniera univoca l'attore o il regista senza possibilità di ambiguità in caso di omonimie.


Soluzione seconda parte - Le Query