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:
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!
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)
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.
Ricordare di inserire per ATTORE e REGISTA tutti gli attributi anagrafici: nome, cognome, data di nascita,
città di nascita ed eventuale data di morte, insomma tutti i dati che troviamo cercando un personaggio famoso in Wikipedia.
Per semplicità di disegno, ho inserito solo l'attributo nome, andrebbero inseriti tutti gli altri .
Entità per entità, devono essere indicate con cura e ragionate le cardinalità delle relazioni.
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.
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.
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.
.
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.
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.
