Tradurre entit`a isolate ed identificatori interni

54 CAPITOLO 3. PROGETTAZIONE LOGICA

con un attributo A e tre identificatori, di cui uno composto dagli attributi IA11 e IA12.

Prima fase. Per definizione, il risultato della traduzione della entit`a E1 deve essere il seguente schema di relazione:

E₁(I₁₁, I₁₂, IA₁₁, IA₁₂, A) (3.1) in cui:

• il nome dello schema coincide con quello dell’entit`a, evidenziando la cor-rispondenza con lo schema EA. L’omonimia tra oggetto da tradurre e traduzione, per quanto possibile, sar`a mantenuta in ogni frangente del processo di traduzione;

• esiste un dominio per ogni attributo. La corrispondenza `e evidente per omonimia.

In particolare:

– ogni identificatore semplice dell’entit`a deve essere tradotto nel nome di un dominio, quest’ultimo, sottolineato;

– ogni identificatore composto dell’entit`a deve essere tradotto da una sequenza, sottolineata, di tanti nomi di dominio quanti sono gli at-tributi che compongono l’identificatore dell’entit`a.

Per definizione:

Ogni dominio di schema di relazione che sia sottolineato `e detto chiave dello schema.

Lo stesso dicasi per le sequenze di attributi sottolineati: ciascuna di esse costituisce una chiave composta dello schema di relazione.

Seconda fase. Lo schema di relazione (3.1) `e tradotto in E1:Tabella, tabella di Access:

3.2. PROCEDURA DI TRADUZIONE INCREMENTALE 55

• il nome della tabella coincide con quello dello schema di relazione;

• esiste un campo per ogni dominio dello schema di relazione. La corrispon-denza `e evidente per omonimia;

• la tabella deve rappresentare istanze arbitrarie dello schema di relazio-ne (3.1), ovvero istanze di un insieme.

Questo risultato si assicura imponendo che il campo I11 della tabella sia chiave principale, o chiave primaria della tabella stessa, per cui valgono le seguenti propriet`a:

– ogni istanza del campo chiave principale di una tabella `e unica all’in-terno della tabella;

– non possono esistere istanze indefinite, ovvero, convenzionalmente, con valore NULL, del campo chiave principale di una tabella.

In assenza di preoccupazioni sull’efficienza della base di dati da realizzare, come nel nostro caso, sarebbe stato indifferente imporre il vincolo di chiave principale sul singolo I12 o sulla coppia di campi IA11 e IA12, traduzione di I12 e IA11, IA12, rispettivamente.

Tuttavia, una volta stabilito quale sia la chiave dello schema di relazio-ne (3.1) che debba essere tradotta in chiave principale della tabella, occorre rappresentare opportunamente le rimanenti chiavi dello schema (3.1), anch’esse rappresentanti di identificatori della entit`a E1.

Questo significa imporre che sia i valori del singolo campo I12, sia i valori della coppia di campi IA11,IA12, rendano E1:Tabella rappresentazione di un insieme.

Tale necessit`a, tuttavia, non pu`o essere soddisfatta imponendo il vincolo di chiave principale sia su I12, che sulla coppia IA11,IA12, dopo averlo gi`a imposto su I11.

Il motivo `e che, per definizione, ogni DBMS non permette di definire pi`u di una chiave principale per ogni tabella.

La soluzione sta nello stabilire che sia I12, sia la coppia IA11,IA12 della tabella E1, siano indici a valore unico e sempre definito, ovvero diverso dal valore convenzionale NULL, privo d’informazione.

56 CAPITOLO 3. PROGETTAZIONE LOGICA

elenca gli indici associati alla tabella E1.

Ogni indice di tabella permette un’efficiente verifica che i valori assunti dai campi, coinvolti nell’indice stesso, soddisfino le propriet`a volute.

Nella tabella degli indici, appena illustrata, la prima colonna individua il nome dell’indice, la seconda i campi sui cui esso `e definito, e la terza specifica una propriet`a dell’indice, per noi irrilevante.

L’indice di nome PrimaryKey `e stato introdotto automaticamente dal DBMS nel momento in cui si `e definito il vincolo di chiave primaria sul campo I11.

Il nome TerzaChiavePrimaria indica che la coppia di campi IA11,IA12 dovr`a rappresentare una chiave dello schema di relazione (3.1), e lo stesso vale per il nome SecondaChiavePrimaria, relativamente al campo I12.

L’ordine di definizione di TerzaChiavePrimaria e SecondaChiavePrimaria `e invertito per evidenziare il modo in cui si definiscano indici composti da pi`u di un campo: i nomi dei campi che seguono il primo, affiancato dal nome dell’indice, sono parte dell’indice stesso.

Il vincolo sull’unicit`a dei valori di SecondaChiavePrimaria `e impostato per mezzo del valore S`ı nel campo Univoco, evidenziato in rosso, nella par-te Propriet`a indice della finestra dal titolo Indici:E1; lo spar-tesso dicasi per TerzaChiavePrimaria:

3.2. PROCEDURA DI TRADUZIONE INCREMENTALE 57

Al contrario, il vincolo secondo il quale i valori dei campi componenti un indice non possano essere indefiniti (NULL) non pu`o essere imposto durante la definizione dell’indice.

Valori sempre definiti. La necessit`a di imporre che un dato attributo sia sempre definito, ovvero che esso non possa assumere il valore NULL, il quale, per convenzione, indica assenza di informazione, non `e, necessariamente, legata alla definizione di indici.

Quanto illustrato qui di seguito, quindi, potr`a essere usato quando neces-sario, inclusa la situazione in cui occorra evitare che i campi di un indice, che possa giocare un ruolo analogo a quello di chiave principale, non possano essere lasciati indefiniti.

Il vincolo che i valori di un campo di una tabella debbano sempre essere definiti va specificato al momento della definizione del campo stesso.

Se, per esempio, per un qualsiasi motivo, l’attributo A di E1 dovesse sempre avere valori definiti, la sua definizione sarebbe la seguente:

Ovvero, nella parte Propriet`a campo della finestra in cui si specifica la strut-tura di E1:Tabella, il valore della propriet`a Richiesto per l’attributo A deve essere S`ı.

Lo stesso dovr`a succedere per i campi I12, IA11 e IA12, come, ad esempio, in:

58 CAPITOLO 3. PROGETTAZIONE LOGICA

Operazioni base sul DBMS di riferimento: “filmati”

Verranno illustrate le operazioni fondamentali per la realizzazione di una base di dati sul DBMS di riferimento, attraverso brevi filmati, visibili con programmi capaci di interpretare risorse multimediali con flusso audio mp2 e flusso video mpeg4, ovvero DivX.

L’Appendice D suggerisce strumenti per l’interpretazione delle risorse mul-timediali.

“Filmati”.

• Definire una Nuova base di dati.

• Definire una Tabella con chiave principale semplice ed un campo.

• Definire una Tabella con chiave principale composta.

• Estendere una tabella con unCampo a valori sempre definiti.

• Definire unIndice di tabella composto da un singolo campo.

• Definire unindice composto da pi`u campi.

L’AppendiceDsuggerisce strumenti per l’interpretazione delle risorse multime-diali.