|
|
PROGETTAZIONE FISICALa base di dati verrà realizzata e gestita per mezzo del DBMS Microsoft® Access®. Ci uniformeremo, quindi, alla nomenclatura utilizzata dal DBMS adoperato e pertanto chiameremo Tabelle le relazioni, Record le occorrenze (tuple) di una relazione e Campi gli attributi di una relazione; i tipi di dato cui faremo riferimento sono i tipi di dato utilizzati da Microsoft Access.DOMINÎ DEGLI ATTRIBUTI E VINCOLI DI DOMINIONelle tabelle seguenti vengono indicati, per ogni relazione della base di dati, i dominî degli attributi e, ove presenti, i vincoli di dominio, ovvero le regole di validità dei valori dei campi di un record, indipendentemente da altri record della medesima o di altre tabelle e indipendentemente dai valori degli altri campi del medesimo record; in Microsoft Access i vincoli di dominio vengono definiti imponendo delle condizioni in una apposita casella, etichettata con la dicitura Valido se, disponibile per ogni campo.La chiave primaria di ogni tabella è evidenziata dalla sottolineatura dei nomi degli attributi che la costituiscono. Le conclusioni di seguito riassunte vengono derivate con semplicità dalle informazioni raccolte nella fase di analisi dei requisiti e dalle valutazioni svolte nelle successive fasi di progettazione; ogni ulteriore analisi che si sia resa necessaria è anch'essa documentata di seguito. Ad alcuni attributi è stato assegnato un nome diverso, allo scopo di renderne più immediatamente comprensibile il significato.
VINCOLIVINCOLI DI TUPLAI vincoli di tupla sono delle regole che il valore di un campo deve rispettare in relazione ai valori assunti da altri campi del medesimo record (tupla). L'unico vincolo di tupla è quello espresso dalla RD01 (vedi Progettazione Logica), per la quale deve sussistere il legame Valutazione=VotoMedio*NumeroVoti per i campi della tabella DISCO. Tale vincolo può essere imposto avvalendosi della casella Valido se disponibile nella finestra Proprietà Tabella, nella quale si possono specificare le condizioni che devono essere verificate per ogni record della tabella.ALTRI VINCOLI INTRARELAZIONALII vincoli intrarelazionali rappresentano condizioni che devono essere verificate per i valori dei campi di un record in relazione ai valori assunti su altri record della medesima tabella. I vincoli di tupla sopra analizzati sono un particolare tipo di vincolo intrarelazionale, così come lo sono vincoli di chiave primaria già evidenziati sopra. Una particolare categoria di vincoli intrarelazionali è rappresentata dal vincolo unique, il quale impone che, dato un insieme di campi di una tabella, ogni combinazione di valori su essi può essere assunta su un solo record della tabella, quindi non possono esservi diversi record della tabella che presentano i medesimi valori sui campi dati. L'unica differenza dal vincolo di chiave primaria, in effetti, è che i campi sottoposti al vincolo unique possono assumere valore NULL; inoltre, mentre per ogni tabella si può definire una sola chiave primaria, è possibile definire un qualunque numero di vincoli unique. Sulla base di quanto asserito nelle regole RV06, RV07 ed RV08 (vedi Progettazione Logica) si evince che i campi Nome di GENERE, NomeArtista di ARTISTA e (CognomeRedattore,NomeRedattore) di REDATTORE devono essere sottoposti a vincolo di unicità; in Access tale vincolo può essere imposto creando un indice univoco sui campi interessati, il che può essere fatto scegliendo la voce Sì (Duplicati non ammessi) nella casella combinata etichettata con Indicizzato, disponibile per ogni campo, oppure accedendo alla finestra di dialogo Indici e indicando quali debbano essere gli indici univoci della tabella. Purtroppo, Access non consente la creazione di altri tipi di regole di vincolo interrelazionali: le regole di vincolo (dette Regole di convalida in Access) che si possono definire sono solo i vincoli di chiave, i vincoli unique, i vincoli di dominio e i vincoli di tupla; pertanto occorre affidare al codice che scriveremo per l'accesso alla base di dati il compito di assicurare che venga rispettata la regola RD02 sulla consecutività dei valori di NumeroBrano nei record che presentano il medesimo valore di CodiceDisco. Si rimanda alla sezione Implementazione per ulteriori dettagli.VINCOLI DI INTEGRITÀ REFERENZIALEUn vincolo di integrità referenziale crea un legame fra due tabelle, dette tabella interna e tabella esterna, ponendo in corrispondenza determinati campi di esse (N campi della tabella interna posti in corrispondenza con N campi della tabella esterna) e imponendo che, per ogni record della tabella interna, i valori assunti su tali campi siano assunti dai corrispondenti campi per un record della tabella esterna. È necessario che sui campi della tabella esterna coinvolti nel vincolo di integrità referenziale sia imposto anche un vincolo di tipo unique; tipicamente, i campi della tabella esterna che si considerano costituiscono la chiave primaria della stessa per cui la condizione di unicità è implicitamente verificata. In Microsoft Access è possibile realizzare tali vincoli creando quelle che vengono chiamate relazioni tra tabelle; quando si definisce una relazione, occorre specificare le due tabelle coinvolte, i campi posti in relazione, se debba essere imposta l'applicazione delle regole di integrità referenziale e, in tal caso, come vanno gestiti l'aggiornamento e la cancellazione di record; in base alle caratteristiche delle due tabelle indicate, Access stabilisce quale sia la tabella interna e quale quella esterna, nonché il tipo di relazione (uno-a-molti, uno-a-uno); osserviamo che la tabella esterna è detta tabella primaria, mentre la tabella interna è detta tabella correlata. È importante spendere qualche parola circa l'aggiornamento e cancellazione dei record. Innanzitutto, l'applicazione dell'integrità referenziale permette di effettuare il controllo sui valori dei campi correlati, quindi la attiveremo sempre per ogni relazione; riguardo l'aggiornamento e cancellazione a catena, vi sono due possibilità: abilitare l'aggiornamento (cancellazione) a catena, nel qual caso ogni variazione dei campi correlati apportata nella tabella primaria si ripercuote sulla tabella correlata, nella (dalla) quale verranno aggiornati i valori dei campi corrispondenti (verrammo eliminati i record corrispondenti), oppure disabilitare l'aggiornamento (cancellazione) dei record, nel qual caso viene rigettato ogni tentativo di aggiornare nella tabella primaria i campi posti in relazione (di eliminare un record dalla tabella primaria) se esistono dei record nella tabella correlata che siano collegati al record che si vuole aggiornare (cancellare).Tutto ciò detto, vediamo quali relazioni occorre definire per la base di dati in esame, che vengono riepilogate nella seguente tabella.
È opportuno motivare alcune delle scelte fatte. Rendere impossibile la cancellazione di un artista se vi sono record nella tabella REALIZZAZIONE correlati al record che si intende eliminare è necessario al fine di preservare la regola che un disco sia realizzato da almeno un artista; se si permettesse la cancellazione di un artista che ha collaborato alla realizzazione di un disco si correrebbe il rischio, a seguito di successive cancellazioni, di avere dischi che non risultano realizzati da alcun artista, il che violerebbe la condizione che un disco sia realizzato da almeno un artista; di fatto, quindi, per poter cancellare un artista è necessario aver cancellato tutti i dischi realizzati dall'artista e, di conseguenza, tutti i corrispondenti record della tabella REALIZZAZIONE. Si è scelto anche di imporre che non si possa cancellare un genere se esistono dischi classificati in base a quel genere; in effetti si potrebbe consentire la cancellazione a cascata, ma di fatto è assai improbabile che si voglia cancellare un disco andando a cancellare il genere corrispondente, mentre assai più probabile è che si commetta un errore nel cercare di cancellare un genere che è legato ad un disco, e quindi la scelta fatta vuole prevenire un simile errore; di fatto, quindi, sarà possibile eliminare un genere solo se non vi sono dischi in base ad esso classificati. Più delicato è l'esame delle relazioni che coinvolgono la tabella CARATTERIZZAZIONE. Ricordiamo, infatti, che esiste una regola di derivazione (vedi RD02 in Progettazione Logica) che impone un vincolo fra le istanze di CARATTERIZZAZIONE, DISCO, ARTISTA e GENERE, in quanto un artista è caratterizzato da un genere se e solo se ha realizzato dischi classificati in base a quel genere. Come questo vincolo debba essere rappresentato sarà discusso fra breve nel paragrafo successivo, per ora ci limitiamo a dire che inibendo la cancellazione a catena per le relazioni fra ARTISTA e CARATTERIZZAZIONE e fra GENERE e CARATTERIZZAZIONE rafforziamo il controllo riguardo il vincolo indicato. Infatti, se non si consente la cancellazione di un artista se sono ancora presenti dischi da esso realizzati, a maggior ragione non si può consentire la eliminazione a catena in CARATTERIZZAZIONE, perché altrimenti si rischierebbe di giungere alla situazione che un artista ha realizzato dischi di un determinato genere ma non risulta caratterizzato da quel genere, il che porterebbe ad ottenere una base di dati inconsistente; analogamente, se non si consente che venga eliminato un genere se esistono dei dischi in base ad esso classificati, allora non si può consentire neanche l'eliminazione a catena da CARATTERIZZAZIONE, altrimenti si rischierebbe di giungere in una situazione in cui un artista risulta caratterizzato da un genere benché non abbia realizzato alcun disco di quel genere, il che rappresenterebbe una inconsistenza nella base dei dati. ALTRI VINCOLI INTERRELAZIONALILa regola RD02 (vedi Progettazione Logica) impone un vincolo interrelazionale, ovverosia un vincolo che può essere verificato confrontando record di tabelle diverse. La regola indicata impone, in particolare, che vi sia un legame fra i record delle tabelle ARTISTA, REALIZZAZIONE, DISCO, GENERE e CARATTERIZZAZIONE tale da assicurare che venga rispettato il concetto che un artista è caratterizzato da un genere se e solo se ha realizzato dischi classificati in base a quel genere. Come detto, non è possibile in Access specificare una regola di questo tipo, per cui assicureremo il rispetto del vincolo scrivendo opportunamente il codice di modifica della base di dati. In particolare, considerato che le operazioni di modifica della base di dati che interessano dati sensibili alla regola in esame devono coinvolgere più di una tabella (ad es., se si inserisce un nuovo disco occorrerà inserire anche nuovi record in CARATTERIZZAZIONE per assicurarsi di conservare la consistenza dei dati), ci affideremo al meccanismo delle transazioni per assicurarci che la base di dati rimanga in uno stato consistente. In particolare, occorrerà assicurare che le operazioni di modifica alla base di dati avvengano secondo le seguenti modalità:
INDICIGli indici sono strutture ausiliarie che vengono associati a una tabella e definiti su un campo (o insieme di campi) di questa; scopo fondamentale degli indici è quello di velocizzare l'accesso alla tabella quando l'operazione di selezione sulla tabella sia fatta in base al campo (o insieme di campi) indicizzati, e analogamente per le operazioni di join. È conveniente, quindi, definire un indice su un campo rispetto al quale vengono frequentemente effettuate operazioni di selezione e/o join; è bene tenere presente che, per contro, gli indici occupano memoria e rallentano le operazioni di aggiornamento, in quanto richiedono che, oltre alla tabella stessa, venga aggiornato anche l'indice.In Microsoft Access è possibile definire indici per ogni tabella utilizzando l'apposita finestra di dialogo, dove è possibile dare un nome all'indice, specificare il campo (o i campi) su cui l'indice è definito, specificare il tipo di ordinamento (crescente o decrescente) da mantenere per ogni campo (gli indici sono sempre strutture ordinate) e, infine, stabilire se l'indice è primario, cioè se i campi coinvolti costituiscono la chiave primaria della tabella (ve ne può essere uno solo per tabella, ovviamente; si tratta di un modo alternativo per definire la chiave primaria di una tabella), se è univoco, ovvero se sui campi interessati vi è un vincolo di tipo unique, e se i valori NULL debbano essere o meno esclusi dall'indice. Un indice primario viene comunque definito automaticamente quando si specifica la chiave primaria di una tabella. Inoltre, come abbiamo poc'anzi visto, l'unico modo per imporre vincoli di unicità sui campi è quello di definire un indice univoco su essi. Vediamo, ora, quali altri indici è opportuno definire per la nostra base di dati. Dai requisiti sulle operazioni (vedi Analisi dei Requisiti) possiamo evincere che i campi più frequentemente coinvolti in operazioni di selezione e join sono quelli riportati nella seguente tabella; su di essi definiremo un indice le cui caratteristiche sono anch'esse riportate in tabella. La proprietà Ignora Null non è stata riportata in quanto ininfluente: vedremo che tutti gli indici sono definiti su campi che non possono assumere valori NULL, per cui non è necessario chiedersi se i valori NULL debbano o meno essere esclusi dall'indice. Per semplicità, e anche allo scopo di fornire una visione immediata, nella tabella sono riportati tutti gli indici che abbiamo deciso di definire, compresi quelli primari e quelli necessari per realizzare un vincolo di unicità, già discussi in precedenza.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||