Date post: | 17-Jun-2015 |
Category: |
Education |
Upload: | silvano-natalizi-itis-alessandro-volta-perugia |
View: | 336 times |
Download: | 2 times |
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 [email protected] 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…