GESTIONE VIDEONOLEGGIO

GESTIONE VIDEONOLEGGIO Si vuole automatizzare la gestione del noleggio di video (in formato VHS, DVD ed altri). Nel database si devono organizzare i dati relativi ai video, ai clienti del negozio, ai produttori dei video e ai noleggi effettuati. La gestione deve comprendere : l inserimento di nuovi video nel catalogo; l inserimento, la modifica o la cancellazione dei dati riguardanti i clienti ed i produttori; l elenco dei clienti e dei produttori; il controllo della disponibilità in negozio di un video richiesto da un cliente; il servizio di noleggio e restituzione; la stampa del catalogo dei video (eventualmente anche per genere); Considerato il problema proposto, precisando eventuali ipotesi aggiuntive, si realizzi: un analisi della realtà di riferimento che illustri le premesse per i successivi passi della progettazione della base di dati; uno schema concettuale della base di dati; uno schema logico della base di dati; la definizione delle relazioni della base di dati in linguaggio SQL. SOLUZIONE Analisi del problema Ipotesi aggiuntive Analisi dei dati Schema concettuale Schema logico Definizione delle relazioni Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 1

Analisi del problema Le entità caratteristiche per la risoluzione del problema si riferiscono alla gestione dei video, dei clienti che li richiedono e dei produttori che li producono. Le proprietà utilizzate per la definizione delle suddette entità devono consentire di soddisfare le richieste proposte dal problema. In particolare deve essere possibile la gestione dei noleggi e delle restituzioni dei video da parte dei clienti e, fondamentalmente, la gestione delle quantità disponibili nei vari formati in cui un video può essere riprodotto. Introducendo opportuni attributi (Numero tessera e Credito residuo) nell entità Cliente è possibile gestire anche un pagamento tramite scheda prepagata supponendo di fornire ai clienti un tale servizio mediante lettori di badge collegati al sistema ed alla procedura utilizzata per risolvere il problema proposto. Per quanto riguarda le tabelle relative ai video, ai clienti e ai produttori, la loro gestione deve essere realizzata mediante un tipico programma di aggiornamento che prevede le funzioni di inserimento, cancellazione e modifica dei record contenuti nelle suddette tabelle. Un altra entità riguarda l elenco dei comuni in cui risiedono i clienti. L utilizzo di tale entità è giustificato da problemi esclusivamente legati alla ridondanza dei dati. Senza tale entità, infatti, si dovrebbe inserire il nome del comune fra gli attributi dell entità Cliente. L uso dell entità genere si rende necessaria in quanto si vuol distinguere i video secondo una classificazione diversa che può, per es., essere vincolata alla trama del film registrato (film comico, film di fantascienza, ecc.). L uso dell entità formato si rende necessaria per distinguere i vari formati (VHS, DVD, ecc.) in cui un video può essere registrato ma soprattutto per dare la possibilità di gestire il prezzo del noleggio del video in funzione del formato utilizzato. In base a questa esigenza l associazione fra l entità Video e l entità Formato è di tipo molti-a-molti in quanto per un video possono essere disponibili più formati ed, ovviamente, un formato può essere utilizzato per registrare video diversi. L entità che scaturisce da questa associazione molti-a-molti può servire anche ad introdurre altri attributi che consentono di risolvere il problema legato alla gestione della disponibilità di copie relative ad un determinato video. In questo modo, infatti, si può conoscere esattamente il numero di copie di un video disponibili nei vari formati (è facile intuire che si può anche conoscere il numero complessivo). Le tabelle relative ai Comuni, ai Generi ed ai Formati video possono essere definite come tabelle di controllo che vengono create nella fase iniziale di creazione ed avviamento del database e che, nel tempo, subiranno poche modifiche. Il programma di creazione di tali tabelle deve, comunque, prevedere la possibilità di aggiornamento dei dati presenti nelle stesse tabelle. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 2

L entità che consente di gestire il noleggio di un video e la relativa restituzione scaturisce dall associazione ternaria fra l entità Cliente, l entità Video e l entità Formato (è ovvio che un cliente può richiedere in noleggio uno o più video in formati diversi ed uno stesso video, in formati diversi, può essere richiesto da uno o più clienti). La gestione della tabella in esame rappresenta il nucleo fondamentale della procedura che risolve il problema proposto in quanto è sicuramente la tabella che, per i dati che contiene, sarà più frequentemente sottoposta ad operazioni di aggiornamento. Tale tabella consente, nella sua definizione, di gestire effettivamente tutti i movimenti relativi a tutti i noleggi effettuati. Il movimento viene generato nel momento in cui viene effettuato un noleggio e lo stesso movimento viene utilizzato per gestire la restituzione del video preso in prestito. E possibile ridurre ad un solo movimento le operazioni noleggio/restituzione introducendo, nello stesso movimento, la data del noleggio e la data di restituzione. Quindi il movimento viene aperto nella fase del noleggio e viene chiuso nella fase di restituzione. Tale soluzione facilita, come si può intuire, la gestione di questa tabella consentendo di conoscere in modo estremamente semplice dei dati indispensabili per l applicazione. Effettuando, per esempio, un controllo sulla data di restituzione (se è per es. Null) è possibile conoscere quali sono i video che non sono stati ancora restituiti; per calcolare l importo che il cliente deve pagare o si deve detrarre dalla scheda prepagata è sufficiente calcolare i giorni (come differenza fra la data della restituzione e la data del noleggio) e moltiplicare per il costo del noleggio giornaliero. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 3

Ipotesi aggiuntive Entità Comune : la chiave primaria è artificiale ad autoincremento per evitare i problemi generati dalle omonimie (comuni con lo stesso nome) ma si potrebbe usare il codice proprio di ogni comune (quello utilizzato, per es., nella generazione del codice fiscale). L attributo della sigla della provincia può essere, eventualmente, utilizzato per un collegamento alla tabella delle province (in questo problema non utilizzata). Entità Genere : la chiave primaria è artificiale ad autoincremento. L utilizzo dell entità Genere permette di ottenere una descrizione univoca per ogni genere di film. E prevista solo la proprietà strettamente necessaria per la risoluzione dei quesiti, ovvero la descrizione che serve a classificare i diversi generi di film (drammatico, western, comico, giallo, fantascienza, ecc). Entità Formato : la chiave primaria è artificiale ad autoincremento. L utilizzo dell entità Formato permette di classificare i diversi tipi di supporto usato per la riproduzione dei video. Sono previsti solo gli attributi strettamente necessari per la risoluzione dei quesiti, ovvero la descrizione del tipo di supporto (VHS, DVD, ecc.) ed il costo del noleggio (relativo al tipo di formato); Entità "Cliente": la chiave primaria è artificiale ad autoincremento per evitare i problemi generati dalle omonimie. Sono previste le proprietà strettamente necessarie per la risoluzione dei quesiti, ovvero sia i dati anagrafici del cliente (nome e cognome, indirizzo, città di residenza, codice fiscale, numero di telefono, ecc.) che i dati per la gestione dei noleggi (documento di riconoscimento, eventuale credito residuo nel caso il negozio adotti un sistema di carta prepagata per il pagamento del noleggio dei video). La chiave primaria può essere anche utilizzata per fornire al cliente una tessera con un numero identificativo con la quale poter usufruire di tutti i servizi del negozio. Per la residenza è prevista una chiave esterna all entità Comune; Entità "Produttore": la chiave primaria è artificiale ad autoincremento. Per l entità Produttore gli attributi riguardano solo la ragione sociale del produttore e dati per ottimizzare eventuali comunicazioni con il produttore (indirizzo e-mail); Entità Video la chiave primaria è artificiale ad autoincremento. Gli attributi individuati devono consentire la gestione completa del video ed in particolar modo riguardano: il titolo del video, la trama, il genere di film, il regista, il produttore, la durata in minuti del video, anno di produzione del video, l indicazione se la visione del video è vietata ai minori; Relazione Copie : La relazione, che consente di realizzare l associazione molti-amolti fra l entità Video e l entità Formato, contiene, oltre alle chiavi esterne alle entità interessate (Video e Formato), gli attributi necessari per la completa gestione delle quantità suddivise per formato : numero di copie disponibili, numero di copie noleggiate. La chiave primaria della relazione è costituita dall insieme del codice video (chiave esterna all entità Video) e del codice formato (chiave esterna all entità Formato); Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 4

Relazione Movimento : la chiave primaria è artificiale ad autoincremento. La relazione, che consente di realizzare l associazione ternaria fra l entità Cliente, l entità Video e l entità Formato, contiene, oltre alle chiavi esterne alle entità interessate (Cliente, Video e Formato), gli attributi necessari per la completa gestione delle registrazioni dei movimenti di entrata/uscita relativi al servizio di noleggio/restituzione dei video : data del noleggio, data del reso. Si noti che non è possibile utilizzare, come chiave primaria, la terna di campi costituiti dalle tre chiavi esterne in quanto è possibile che uno stesso cliente noleggi lo stesso video nello stesso formato in date, ovviamente, diverse. La chiave primaria potrebbe, quindi, essere costituita dalle tre chiavi esterne e dalla data di noleggio. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 5

Analisi dei dati Le entità che possono essere individuate per risolvere il problema sono : ENTITA Comune contiene l elenco dei comuni d Italia in cui possono risiedere i clienti; Genere contiene la classificazione dei possibili generi di video; Formato contiene la classificazione dei possibili formati in cui è riprodotto il video; Produttore contiene informazioni dei produttori dei video; Cliente contiene informazioni anagrafiche dei clienti che noleggiano i video; Video contiene informazioni sui video che possono essere noleggiati; Gli attributi, per ciascuna entità, individuati per risolvere il problema sono : ATTRIBUTI Tipo di entità Comune Genere Formato Produttore Cliente Video Sistema informativo Gestione Negozio Noleggio Video Attributi idcomune, codiceistat, nome comune, provincia, regione, prefisso, cap, codcatastale, numero_abitanti, link idgenere, descrizione del genere di film idformato, descrizione formato, costo del noleggio idproduttore, ragione sociale, email, sito idcliente, cliente, indirizzo, codice fiscale, telefono, cellulare, email, documento, credito residuo idvideo, titolo, trama, regista, durata, annoproduzione, vietato Tra l entità Comune e l entità Cliente esiste un associazione uno-a-molti in quanto in un comune possono avere la residenza uno o più clienti ed un cliente deve avere la residenza in un solo comune. Tra l entità Produttore e l entità Video esiste un associazione uno-a-molti in quanto un produttore produce uno o più video ed un video è prodotto da un solo produttore. Tra l entità Genere e l entità Video esiste un associazione uno-a-molti in quanto un genere (comico, fantascienza, ecc..) può essere abbinato ad uno o più film ma un film deve essere abbinato ad un solo genere. Tra l entità Video l entità Formato esiste un associazione molti-a-molti in quanto un video è riprodotto in almeno un formato (su VHS, su DVD, ecc.) ed uno stesso formato può essere utilizzato per riprodurre più video. Tra l entità Cliente, l entità Video e l entità Formato esiste un associazione ternaria in quanto un cliente può noleggiare uno o più video di formati uguali o diversi. Definizione : Si definisce grado di un associazione il numero n di entità che sono coinvolte nell associazione. Se n=3 l associazione di definisce ternaria. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 6

Schema concettuale della base di dati Le relazioni tra i tipi di entità nel modello dei dati sono individuate nel seguente Modello Entità/Associazioni (E/R) : COMUNE PRODUTTORE CLIENTE Movimento VIDEO GENERE DataNoleggio DataReso FORMATO Copie Disponibili Noleggiate Nel modello E/R sono indicati i nomi delle entità, l opzionalità od obbligatorietà delle associazioni. Il modello viene verificato utilizzando le regole di lettura : ogni comune può essere la residenza di uno o più clienti, ogni cliente deve avere la residenza in un solo comune; ogni genere può essere abbinato ad uno o più video, ogni video deve essere abbinato ad un solo genere; ogni produttore produce uno o più video, ogni video deve essere prodotto da un solo produttore; ogni video può essere riprodotto in uno o più formati, ogni formato può essere utilizzato per riprodurre uno o più video; ogni cliente può richiedere uno o più video in formati diversi, ogni video di diverso formato può essere richiesto da uno o più clienti. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 7

Schema logico della base di dati Come tipo di schema logico, dovendo poi realizzarlo nello standard SQL, si sceglie di utilizzare quello relazionale. Applicando le regole di corrispondenza tra il modello E/R ed il modello Relazionale si passa dal precedente schema concettuale al modello logico che viene descritto sia nella forma testuale che in quella grafica. Rappresentazione testuale dello schema logico : Nella rappresentazione testuale si elencano le tabelle (indicando per ciascuna i campi) che rappresentano le entità dello schema concettuale e le tabelle che rappresentano le eventuali relazioni molti-a-molti, introducendo, inoltre, le chiave esterne per rappresentare le associazioni (le chiavi primarie sono sottolineate, le chiavi esterne sono in corsivo). Nello schema E/R precedente si può osservare che esiste : una associazione molti-a-molti (N:N) tra i tipi di entità Video e l entità Formato. Applicando il processo di normalizzazione (definito dalle forme normali) si deve inserire una entità ausiliaria (Copie) che trasforma l associazione molti-a-molti in due associazioni uno-a-molti, anche per consentire di rappresentare gli attributi dell associazione. Per esempio, nell associazione fra l entità Video e l entità Formato il numero di copie disponibili (per quel formato) ed il numero di copie noleggiate non sono attributi né dell entità Video né dell entità Formato (il numero di copie di un certo video acquistate in un certo formato si ottiene come somma fra i valori dei suddetti attributi). Le associazioni, quindi, che ne derivano sono: uno-a-molti (1:N) tra Video e Copie (ogni video deve essere disponibile in uno o più formati ed ogni copia deve essere relativa ad un solo video), e uno-a-molti (1:N) tra Formato e Copie (ogni formato può essere utilizzato per uno o più video disponibili e ogni copia deve essere associata ad un solo formato). un associazione ternaria tra le entità Cliente, Video e Formato. Applicando il processo di normalizzazione (definito dalle forme normali) si deve inserire una entità ausiliaria (Movimento) anche per consentire di rappresentare gli attributi propri dell associazione (la data del noleggio o della restituzione non sono attributi né dell entità Cliente, né dell entità Video e né dell entità Formato). Si definiscono, innanzitutto, le tabelle che rappresentano le entità dello schema concettuale e successivamente si definiscono le tabelle che rappresentano le associazioni. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 8

Le seguenti tabelle rappresentano le entità : tabcomuni (idcomune, codiceistat, comune, ksprovincia,ksregione, prefisso, cap, codcatastale, numero_abitanti, link) tbgeneri (idgenere, genere) tbformati (idformato, formato, costonoleggio) tbclienti (idcliente, cliente, indirizzoc, kscomunec, codicefiscalec, telefonoc, cellularec, emailc, documento, creditoresiduo) tbproduttori (idproduttore, produttore, emailp, sitop) tbvideo (idvideo, titolo, trama, ksgenere, regista, ksproduttore, durata, annoproduzione, vietato) La seguente tabella rappresenta l associazione molti-a-molti : tbcopie (ksvideoc, ksformatoc, disponibili, noleggiate) La seguente tabella rappresenta l associazione ternaria : tbmovvideo (idmovvideo, kscliente, ksvideo, ksformato, datanoleggio, datareso) Per realizzare l associazione uno-a-molti fra l entità Cliente e l entità Comune si introduce, fra gli attributi dell entità a molti (Cliente), la chiave esterna kscomune associata alla chiave primaria idcomune dell entità a uno (Comune). Per realizzare l associazione uno-a-molti fra l entità Video e l entità Genere si introduce, fra gli attributi dell entità a molti (Video), la chiave esterna ksgenere associata alla chiave primaria idgenere dell entità a uno (Genere). Per realizzare l associazione uno-a-molti fra l entità Video e l entità Produttore si introduce, fra gli attributi dell entità a molti (Video), la chiave esterna ksproduttore associata alla chiave primaria idproduttore dell entità a uno (Produttore). Per realizzare l associazione molti-a-molti fra l entità Video e l entità Formato si introduce (oltre alle tabelle derivanti dalle due entità) la tabella tbcopie. Tale tabella, oltre agli attributi propri dell associazione (disponibili, noleggiate) ha, come attributi, la chiave esterna ksvideoc associata alla chiave primaria idvideo dell entità Video e la chiave esterna ksformatoc associata alla chiave primaria idformato dell entità Formato. L insieme di questi due attributi, inoltre, costituiscono la chiave primaria dell associazione. Per realizzare l associazione ternaria fra l entità Video, l entità Cliente e l entità Formato si introduce (oltre alle tabelle derivanti dalle tre entità) la tabella tbmovvideo. Tale tabella, oltre agli attributi propri dell associazione (datanoleggio, datareso) ha, come attributi, la chiave esterna ksvideo associata alla chiave primaria idvideo dell entità Video, la chiave esterna kscliente associata alla chiave primaria idcliente dell entità Cliente e chiave esterna ksformato associata alla chiave primaria idformato dell entità Formato. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 9

Rappresentazione grafica dello schema logico : La rappresentazione grafica dello schema logico relativo al sistema informativo per la gestione del Noleggiovideo è il seguente : Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 10

Definizione delle Tabelle Nel definire le tabelle e la struttura delle stesse, è consigliabile elencarle partendo dalle tabelle che non presentano chiavi esterne. In successione si definiscono le tabelle le cui chiavi primarie sono utilizzate da altre tabelle come chiavi esterne. Nel prospetto seguente, per es., si definiscono prima le tabelle tbcomuni, tbgeneri, tbformati e tbproduttori che non presentano chiavi esterne, successivamente le tabelle tbclienti (che ha fra gli attributi un campo definito come chiave esterna alla tbcomuni), ed infine le tabelle : tbvideo (che ha fra gli attributi un campo definito come chiave esterna alla tbgeneri ed un campo definito come chiave esterna alla tabella tbproduttori), la tabella tbcopie (che ha fra gli attributi un campo definito come chiave esterna alla tabella tbvideo ed un campo definito come chiave esterna alla tabella tbformati) e la tabella tbmovvideo (che ha fra gli attributi un campo definito come chiave esterna alla tabella tbvideo, un campo definito come chiave esterna alla tabella tbclienti ed un campo definito come chiave esterna della tabella tbformati). Tabella Nome campo Chiave Tipo dati Dim. Dec. Null Descrizione tabcomuni idcomune Primaria Numerico 4 Autoincremento codiceistat Carattere 6 Vincolo : valori unici comune Carattere 30 ksprovincia ksregione Carattere Carattere cap Carattere 5 codcatastale Carattere 5 2 Eventuale chiave esterna alla tabelle province 2 Eventuale chiave esterna alla tabelle regioni abitanti Carattere 8 Numero abitanti link Carattere 50 al sito del comune bgeneri idgenere Primaria Numerico 3 Autoincremento genere Testo 30 Vincolo: valori unici tbformati idformato Primaria Numerico 2 Autoincremento formato Testo 10 Vincolo: valori unici costonoleggio Numerico 4 2 costo giornaliero tbproduttori idproduttore Primaria Numerico 4 Autoincremento produttore Testo 30 emailp Testo 30 SI indirizzo E-mail sitop Testo 30 SI indirizzo del sito tbclienti idcliente Primaria Numerico 4 Autoincremento cliente Testo 30 cognome e nome indirizzoc Testo 30 kscomunec Esterna Numerico 4 codicefiscalec Testo 16 SI telefonoc Testo 15 SI cellularec Testo 15 SI emailc Testo 30 SI Integrità referenziale con idcomune della tabella tbcomuni Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 11

Tabella Nome campo Chiave Tipo dati Dim. Dec. Null Descrizione documento Testo 20 SI estremi del documento creditoresiduo Numerico 6 2 SI tbvideo idvideo Primaria Numerico 4 Autoincremento titolo Testo 80 trama Testo 300 SI del video ksgenere Esterna Numerico 3 regista Testo 30 SI ksproduttore Esterna Numerico 4 SI durata Numerico 3 SI in minuti annoproduzione Testo 4 SI Integrità referenziale con idgenere della tabella tbgeneri Integrità referenziale con idproduttore della tabella tbproduttori vietato Testo 2 SI numero anni tbcopie ksvideoc Primaria Numerico 4 ksformatoc Primaria Numerico 2 disponibili Numerico 3 noleggiate Numerico 3 SI Integrità referenziale con idvideo della tabella tbvideo Integrità referenziale con idformato della tabella tbformati tbmovvideo idmovvideo Primaria Numerico 4 Autoincremento kscliente Esterna Numerico 4 Integrità referenziale con idcliente della tabella tbclienti ksvideo Esterna Numerico 4 ksformato Esterna Numerico 2 datanoleggio Data/ora 8 datareso Data/ora 8 SI Integrità referenziale con idvideo della tabella tbvideo Integrità referenziale con idformato della tabella tbformati Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 12

Definizione delle relazioni della base di dati in SQL Lo schema logico relazionale precedente (tabelle, relazioni ed applicazione dei vincoli di integrità dei dati e referenziale) può essere creato con le seguenti istruzioni SQL (proposte in versione per ACCESS e MySQL). ACCESS CREATE TABLE tabcomuni ( idcomune Counter PRIMARY KEY, codiceistat Char(6) UNIQUE, comune Char(35) NOT NULL, ksprovincia Char(2) NOT NULL, ksregione Char(2) NOT NULL, cap Char(5), codcatastale Char(5) UNIQUE, abitanti Char(8), link Char(50) ); MySQL CREATE TABLE tabcomuni ( idcomune int (4) unsigned AUTO_INCREMENT PRIMARY KEY, codiceistat char(6) UNIQUE, comune char(30) NOT NULL, ksprovincia char(2) NOT NULL, ksregione char(2) NOT NULL, cap char(5), codcatastale char(5) UNIQUE, abitanti char(8), link char(50) ) TYPE=MyISAM; CREATE TABLE tbgeneri ( idgenere Counter PRIMARY KEY, genere Char(30) NOT NULL UNIQUE, ); CREATE TABLE tbformati ( idformato Counter PRIMARY KEY, formato Char(10) NOT NULL UNIQUE, costonoleggio Currency NOT NULL ); CREATE TABLE tbproduttori ( idproduttore Counter PRIMARY KEY, produttore Char(30) NOT NULL, emailp Char(30), sitop Char(30) ) ; CREATE TABLE tbgeneri( idgenere int(3) unsigned AUTO_INCREMENT PRIMARY KEY, genere char(30) NOT NULL UNIQUE ) TYPE=MyISAM; CREATE TABLE tbformati( idformato tinyint unsigned AUTO_INCREMENT PRIMARY KEY, formato char(10) NOT NULL UNIQUE, costonoleggio decimal(4,2) NOT NULL ) TYPE=MyISAM; CREATE TABLE tbproduttori( idproduttore int(4) unsigned AUTO_INCREMENT PRIMARY KEY, produttore char(30) NOT NULL, emailp char(30), sitop char(30) ) TYPE=MyISAM; Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 13

ACCESS CREATE TABLE tbclienti ( idcliente Counter PRIMARY KEY, cliente Char(30) NOT NULL, indirizzoc Char(30) NOT NULL, kscomunec Long NOT NULL, codicefiscalec Char(16), telefonoc Char(15), cellularec Char(15), emailc Char(30), documento Char(20), creditoresiduo Currency, FOREIGN KEY(kscomunec) REFERENCES tbcomuni(idcomune) ); CREATE TABLE tbvideo ( idvideo Counter PRIMARY KEY, titolo Char(80) NOT NULL, trama Char(255), ksgenere Long NOT NULL, regista Char(30), ksproduttore Long, durata Byte, annoproduzione Char(4), vietato Char(2), FOREIGN KEY(ksgenere) REFERENCES tbgeneri(idgenere), FOREIGN KEY(ksproduttore) REFERENCES tbproduttori (idproduttore) ) ; CREATE TABLE tbcopie ( ksvideoc Long, ksformatoc Long, disponibili Short NOT NULL, noleggiate Short, PRIMARY KEY (ksvideoc,ksformatoc), FOREIGN KEY(ksvideoc) REFERENCES tbvideo(idvideo), FOREIGN KEY(ksformatoc) REFERENCES tbformati(idformato) ) ; CREATE TABLE tbmovvideo ( idmovvideo Counter PRIMARY KEY, kscliente Long NOT NULL, ksvideo Long NOT NULL, ksformato Long NOT NULL, datanoleggio Datetime NOT NULL, datareso Datetime, FOREIGN KEY(kscliente) REFERENCES tbcliente(idcliente), FOREIGN KEY(ksvideo) REFERENCES tbvideo(idvideo), FOREIGN KEY(ksformato) REFERENCES tbformati(idformato) ); MySQL CREATE TABLE tbclienti( idcliente int(4) unsigned AUTO_INCREMENT PRIMARY KEY, cliente char(30) NOT NULL, indirizzoc char(30) NOT NULL, kscomunec int(4) NOT NULL, codicefiscalec char(16), telefonoc char(15), cellularec char(15), emailc char(30), documento char(20), creditoresiduo decimal(6,2) ) TYPE=MyISAM; CREATE TABLE tbvideo( idvideo int(4) unsigned AUTO_INCREMENT PRIMARY KEY, titolo char(80) NOT NULL, trama text(300), ksgenere int(3) UNSIGNED, regista char(30), ksproduttore int(4) UNSIGNED, durata smallint UNSIGNED, annoproduzione char(4), vietato char(2) DEFAULT NO ) TYPE=MyISAM; CREATE TABLE tbcopie( ksvideoc int(4) unsigned, ksformatoc tinyint unsigned, disponibili smallint unsigned NOT NULL DEFAULT 0, noleggiate smallint unsigned NOT NULL DEFAULT 0, PRIMARY KEY(ksvideoc,ksformatoc) ) TYPE=MyISAM; CREATE TABLE tbmovvideo( idmovvideo int(6) unsigned AUTO_INCREMENT PRIMARY KEY, kscliente int(4) unsigned, ksvideo int(4) unsigned, ksformato tinyint unsigned, datanoleggio date NOT NULL, datareso date ) TYPE=MyISAM; Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 14

Nota : le istruzioni proposte per MySQL sono relative all uso di tabelle tipo MyISAM che non supportano l integrità referenziale definita con FOREIGN KEY. Il tipo di tabella InnoDB, invece, supporta la FOREIGN KEY similmente ad ACCESS. OSSERVAZIONI SULLE QUERY PROPOSTE Query n. 10) Elenco ordinato dei clienti con l indicazione del video noleggiato, del formato ed il relativo costo pagato per il noleggio (moltiplicando il costo giornaliero del noleggio per il numero dei giorni): SELECT cliente, titolo, formato, costonoleggio * ((TO_DAYS(datareso) - TO_DAYS(datanoleggio)) + 1) AS Totale FROM tbmovvideo, tbformati, tbclienti, tbvideo WHERE idformato=ksformato AND idcliente=kscliente AND idvideo=ksvideo AND datareso <> 0 ORDER BY cliente,titolo, datanoleggio; Note : I giorni complessivi di noleggio sono calcolati con l espressione : ((TO_DAYS(datareso) - TO_DAYS(datanoleggio)) + 1). Viene sommato 1 alla differenza fra la data di restituzione e la data in cui il video è stato noleggiato in quanto si deve considerare anche il caso in cui il video viene restituito nello stesso giorno in cui è stato noleggiato. In tale caso la differenza fra le due date sarebbe zero. La condizione datareso <> 0 è necessaria in quanto nell elenco occorre considerare solo i video che sono stati restituiti e quindi i record che hanno il campo datareso uguale a 0. In fase di immissione dei record il campo datareso è stato immesso con valore = a '0000/00/00' e, quindi, si può effettuare il controllo anche nel seguente modo : datareso <> 0000/00/00. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 15

Query n. 13) Elenco, ordinato per titolo, dei video con il maggior numero di noleggi effettuati: SELECT titolo,count(*) AS noleggi_max FROM tbvideo, tbmovvideo WHERE idvideo=ksvideo GROUP BY ksvideo HAVING COUNT(*)=(SELECT MAX(noleggi) FROM (SELECT COUNT(*) AS noleggi FROM tbmovvideo GROUP BY ksvideo) AS calcola) ORDER BY titolo; titolo noleggi_max DRAGONFLY 9 IL CICLONE 9 TI AMO IN TUTTE LE LINGUE DEL MONDO 9 WATERWORLD 9 a) La subquery : SELECT COUNT(*) AS noleggi FROM tbmovvideo GROUP BY ksvideo calcola il numero di preferenze per ciascun video noleggiato : noleggi 8 4 4 4 5 1 3 b) La subquery : ecc., ecc SELECT MAX(noleggi) FROM (SELECT COUNT(*) AS noleggi FROM tbmovvideo GROUP BY ksvideo) AS calcola 9 MAX(noleggi) preleva il valore max fra il numero di noleggi effettuati per ciascun video. Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 16

c) La query principale calcola il numero di noleggi effettuati per ciascun video e lo confronta con il valore max calcolato, restituendo solo i record in cui questo valore è uguale. Query n. 14) Elenco, ordinato per titolo, dei video noleggiati con la percentuale di noleggi effettuati rispetto al totale complessivo : SELECT titolo, COUNT(*) AS noleggi, (SELECT COUNT(*) FROM tbmovvideo) AS noleggi_totali, (COUNT(*) * 100 /(SELECT COUNT(*) FROM tbmovvideo)) AS percentuale FROM tbvideo, tbmovvideo WHERE idvideo=ksvideo GROUP BY ksvideo, titolo ORDER BY titolo; a) Con COUNT(*) AS noleggi, associato alla GROUP BY, si calcolano i noleggi di ciascun video; b) La subquery (SELECT COUNT(*) FROM tbmovvideo) AS noleggi_totali calcola il numero complessivo di noleggi effettuati; b) La percentuale di noleggi per ciascun video, rispetto al totale complessivo, viene calcolata, semplicemente, moltiplicando il numero di noleggi del video (COUNT(*)) per 100 e dividendo per il totale complessivo di noleggi effettuati (SELECT COUNT(*) FROM tbmovvideo) Nota : nella target list non si possono, con MySQL, utilizzare il nome degli alias per effettuare, eventualmente, dei calcoli sugli stessi come avviene, per es., con Access che supporta anche la seguente query : SELECT titolo, COUNT(*) AS noleggi, (SELECT COUNT(*) FROM tbmovvideo) AS noleggi_totali, (noleggi * 100 /noleggi_totale) AS percentuale Esempio di Progettazione di un database a cura del Prof. Salvatore DE GIORGI Pag. 17