Lezione sullo schema logico del database

I lezioneLe liste e i loro problemi, soluzioni

Una semplice lista La figura mostra una semplice lista di studenti

e delle loro email, memorizzata in un foglio elettronico

Possiamo ordinarla alfabeticamente per nome o email,modificare i suoi valori a nostro piacimentoaggiungere i dati di un nuovo studente,eliminare i dati di uno studente.

Una lista più complicata Aggiungiamo, alla lista degi studenti, due

nuove colonne con i nomi dei loro tutor(adviser) e la email di costoro

Problemi di aggiornamento Se eliminiamo i dati dello studente Chip Marino,

eliminando la sesta riga, rimoviamo anche i dati del tutor Tran.

Analogamente, l’aggiornamento di un valore di questa lista dà inaspettate conseguenze. Se per esempio cambiamo l’email di adviser nell’ottava riga, otteniamo dei dati inconsistenti.

Dopo la variazione, la quinta riga indica una email del prof. Taing diversa da quella dell’ottava riga dello stesso prof. Taing. E’ il medesimo professore ? Da questa lista non possiamo dire se c’è un solo prof. Taing con due indirizzi email inconsistenti, oppure ci sono due prof. Taing con differenti email!

Abbiamo aggiunto confusione ed incertezza nei dati

Inserimento di una riga incompleta Infine, che succede se aggiungiamo i dati di

un professore che non ha studenti da seguire ? Ad esempio il Prof. Greene non ha allievi, ma vogliamo comunque memorizzare la sua email.

A tale scopo dobbiamo inserire una riga con valori incompleti, chiamati valori nulli (null values).

I tre problemi

Che cosa è accaduto in questi due esempi? Siamo partiti da una lista funzionante con due

sole colonne. Abbiamo aggiunto altre due colonne e ci

siamo inguaiati. Dipende dal fatto che la nuova lista ha 4

colonne anziché 2?

Esaminiamo quest’altra lista

Ci sono problemi di aggiornamento ?

Quale è la differenza tra le due liste ? Le due liste hanno entrambe 4 colonne, ma

quella dell’adviser dà problemi in fase di modifica, invece quella della pensione (dorm) non dà problemi

Nella lista Dorm si possono eliminare i dati dello studente Chip Marino e perdere i dati solo di quello studente. Non ci sono inattese conseguenze

Possiamo modificare il valore di Dorm per lo studente Tzu Lai senza introdurre inconsistenze.

Infine possiamo aggiungere un nuovo studente Garret Ingram senza null values.

Differenza essenziale tra le due liste La differenza essenziale tra le due liste è che

lo Studente con Dor ha a che fare con un’unica cosa. Tutti i dati di questa lista si riferiscono ad uno studente.

Al contrario la lista con studente e adviser si riferisce agli studenti e agli advisers

In generale ci sono dei problemi, quando una lista ha dei dati di due o più cose diverse

Lista con dati di tre cose diverse

I problemi peggiorano aumentando il numero delle cose di una lista Per rinforzare questa idea, esaminiamo la

precedente lista con i dati degli studenti, degli adviser e dei loro dipartimenti.

Questa lista ha i dati di tre cose diverse: studente, adviser, dipartimento

I problemi peggiorano. Infatti una modifica nel valore di adviser potrebbe richiedere solo la modifica della sue email oppure se cambia il dipartimento anche del dipartimento e della sue admin

Esercizio

Come si risolvono questi problemi ? La lista con Studente e Adviser ha due temi:

Studente e Adviser. Spezziamo la lista e mettiamola in due tabelle !

Legame tra le due tabelle Vogliamo sempre sapere per ogni studente

quale è il suo Adviser (tutor). Pertanto lasciamo la colonna AdviserName nella tabella studente.

I valori di AdviserName legano l’una con l’altra le righe delle due tabelle

Una tabella è come una lista: un insieme di righe e di colonne.

Azioni di modifica Le azioni di modifica sono: insert, update, delete Per valutare un progetto di un database dobbiamo

considerare ciascuna di queste tre azioni Possiamo inserire i dati del Prof. Greene aggiungendoli alla

tabella ADVISER. Nessun studente è legato al Prof. Greene, ma questo non è un problema. Forse qualche studente lo potrà avere come tutori in futuro.

L’email del Prof. Taing può essere modificata in Taing2@ourcampus.edu e non si hanno dati inconsistenti, perché l’email è memorizzata una sola volta nella tabella ADVISER

Possiamo anche eliminare i dati dello studente marino dalla tabella STUDENTE, senza per questo perdere i dati del adviser.

Azioni di modifica consistenti

Simile strategia Possiamo sviluppare una strategia simile per

trattare la lista dello studente con advisor e dipartimento

Questa lista ha tre temi, pertanto la spezziamo nelle tre tabelle STUDENTE, ADVISER, DEPARTMENT

Azioni di modifica consistenti

Effetto collaterale Il precedente disegno ha risolto il problema della

inconsistenza dei dati nella modifica di una lista, ma ha introdotto un altro problema come effetto collaterale!

Che cosa succede quando eliminiamo la prima riga di ADVISER ?

Succede che gli studenti Andrews e Fischer si trovano ad avere un nome AdviserName invalido perché un Baker non esiste più nella tabella ADVISER

Per prevenire il verificarsi di questo problema, possiamo progettare il nostro database in modo da impedire l’eliminazione di una riga se altre righe

dipendono da essa; oppure far si che anche le righe dipendenti siano eliminate insieme

con essa

Una lista con trabocchetto Art course list con problemi di modifica

Quali sono i temi della lista Art Course? Uno dei temi è customer, l’altro “art course”. Ma… Il customer ha pagato una certa cifra per un

corso. Questa quantità non è una proprietà del cliente perché dipende dal corso che viene frequentato. Ma non è neanche una proprietà del corso perché dipende dal cliente.

Pertanto c’è un terzo tema che riguarda l’iscrizione di un particolare studente ad un particolare corso.

Soluzione con una tabella associativa

Osservazioni Nel precedente disegno abbiamo introdotto una colonna ID

che assegna un numero identificativo a ciascuna riga di CUSTOMER

Ciò è necessario perché alcuni clienti potrebbero avere il medesimo nome.

Lo stesso abbiamo fatto per la tabella COURSE, ossia abbiamo introdotto una colonna ID chiamata CourseNumber che assegna un numero identificativo a ciascuna riga di COURSE.

Ciò è necessario perché alcuni corsi potrebbero avere il medesimo nome

Osserva che le righe della tabella ENROLLMENT mostrano il pagamento di un particolare cliente per uno specifico corso ed usa le colonne ID CustomerNumber e CourseNumber come colonne di legame alle altre due tabelle.

Lista più complicata

Soluzione

Questione scottante Può essere cosa buona l’aver spezzato la lista

in pezzi per eliminare il problema della sua modifica, ma se gli utenti vogliono vedere i loro dati nel formato originale ?

Con i dati separati in differenti tabelle, gli utenti devono saltare da una tabella all’altra per trovare l’informazione che vogliono e questa tarantella può diventare noiosa.

Come si risolve ?

Continua…