ricevo
Buonasera professore,
Le scrivo per chiedere alcuni
chiarimenti riguardo i miei errori commessi nello schema ER e per poter
riflettere con Lei sulle diverse soluzioni.
Premetto subito a
scanso di equivoci che non invio questo messaggio per sindacare sulla
correzione o polemizzare. Desidero solamente comprendere al meglio i
miei errori per poter imparare a non commetterli di nuovo e credo che
l'unico modo per fare ciò (oltre che a leggere il commento alla
soluzione) sia di discutere e approfondire con Lei.
In una
situazione di normalità ne avrei discusso di persona in aula, ma ad oggi
uno scambio di mail è la soluzione più immediata.
Il mio primo dubbio è l'errore nelle cardinalità minime tre ingrediente e religione/patologia.
Per
rappresentare questo concetto non ho utilizzato delle relazioni is-a
come nella soluzione proposta, ma due relazioni binarie collegate a
ingrediente.
Il mio ragionamento è stato il seguente: una
patologia deve essere causata da almeno un ingrediente (altrimenti non
ci sarebbe motivo di inserirla nel DB), ma può anche essere causata da
più ingredienti. Allo stesso tempo, un ingrediente può causare nessuna
patologia, così come ne può causare diverse. Ecco il motivo delle
cardinalità (1, n) e (0, n).
Ho inoltre notato che la
soluzione da me proposta per quella porzione di schema è presentata a
pagina 19 del powerpoint da lei inviato ed è descritta come accettabile.
Il mio dubbio è il seguente: c'è per caso una sostanziale differenza in
quella sezione del mio schema che nonostante i miei sforzi non sono
riuscito a trovare? Oppure l'errore è stato segnalato in quanto il mio
schema è poco comprensibile? Nella seconda eventualità mi scuso e
fornisco (oltre al pdf consegnato con la scorsa mail) un file immagine
aggiuntivo in alta definizione, in modo da poter essere zoomato con
comodità. Lo allego a questo messaggio.
Il mio
secondo errore riguarda l'identificatore di ristorante, che era un
aspetto sollevato anche da un collega e di cui ho letto l'intervento sul
forum. La mia scelta era dovuta alla ricerca di un identificatore in
grado di rendere assolutamente impossibile l'esistenza di due ristoranti
con uno stesso identificatore. Riguardando la correzione mi sono reso
conto del mio errore, in quanto usare comune+indirizzo+nome è
effettivamente eccessivo. Al tempo stesso però mi è sorta una
perplessità riguardo la soluzione indicata da Lei come migliore, quindi
colgo l'occasione per chiedere ulteriori informazioni.
Quando
svolgo questo genere di esercizi trovo sempre utile immaginare
situazioni al limite che "mettono alla prova" gli identificatori per
fare in modo che siano effettivamente in grado di garantire l'univocità.
In
questa situazione ho provato a pensare a un nome di un ristorante
piuttosto comune, come ad esempio "Ristorante Bella Napoli" che si trova
in un comune molto grande, come ad esempio Milano. Trovo abbastanza
plausibile l'esistenza di due ristoranti con lo stesso nome in una città
come Milano. Seppur trattandosi di un caso abbastanza raro, non me la
sentirei di rischiare. Propongo quindi una soluzione alternativa, non
presente nella mia consegna originale: è ragionevole utilizzare come
identificatore indirizzo+comune? In questo modo l'univocità è garantita
in un senso molto "geografico", quindi sicuramente efficace. L'assenza
dell'attributo "nome" dall'identificatore è un grave problema?
La
mia terza perplessità riguarda un errore molto comune, cioè
l'identificatore esterno di piatto. So che la descrizione del piatto è
una questione abbastanza complessa che è già stata parzialmente discussa
sul forum, quindi le chiedo se è disponibile a spendere qualche minuto
alla fine della lezione webex di lunedì per poter approfondire questo
punto. Provo però ad anticiparle la mia visione del problema e a
spiegare la mia scelta di usare solamente una entità "piatto" senza
l'identificatore esterno.
Ho pensato al piatto come
caratterizzato dagli ingredienti utilizzati e dalla loro quantità, cioè
dalla ricetta usata per generarlo. Utilizzare gli stessi ingredienti ma
in quantità differenti consiste nell'usare due ricette differenti (anche
se poco), quindi generano due piatti diversi, con codici diversi (anche
se eventualmente possono avere un nome simile o uguale). Ho poi
collegato piatti e ristoranti con una relazione molti-a-molti, in quanto
è sicuramente possibile che più ristoranti usino la stessa ricetta
(cioè propongano lo stesso identico piatto fatto con la stessa quantità
di ingredienti). In questa prospettiva non ho immaginato i piatti come
entità "generali" o un po' "astratte", presenti nei libri di cucina. Al
contrario li ho immaginati come l'applicazione di diverse ricette, che
anche se molto simili danno vita a piatti comunque differenti. In questo
modo, la quantità di ingredienti scelta da ogni ristorante per un
piatto si ricava sulla base di quale versione del piatto fornisce il
ristorante sul menu (cioè quale ricetta decide di adottare).
In
aggiunta, ciò fornisce la possibilità ad un ristorante di offrire più
di una versione dello stesso piatto (magari una versione light con
ingredienti grassi in minor quantità). In questo caso le due versioni
sono da considerarsi piatti diversi, dato che la quantità degli
ingredienti cambia.
Vedendo il problema da questa prospettiva
non ho trovato necessario utilizzare un identificatore esterno per
piatto, dato che il testo chiedeva piatti con un "codice unico per tutti i ristoranti".
Mi
rendo conto di aver scritto un messaggio piuttosto lungo, spero di non
averla importunata o di essere stato troppo tedioso, ma come le ho già
scritto all'inizio della e-mail, vorrei poter discutere e approfondire
degli errori se Lei è disponibile.
La ringrazio per il tempo dedicatomi.
Cordiali saluti.
rispondo
primo punto; cardinalità minime su ingrediente
ho riguardato il suo compito e effettivamente lei usa cardinalità (0,n) lato ingrediente e (1,n) lato patotlogia e religione, mi sono sbagliato nell'attribuirle questo errore, lo elimino dal fogflio excel, mi scuso
secondo punto: 'identificatore di ristorante
la questione degli indicatori ha una valenza concettuale e una valenza logico fisica. occorre ricordare che la progettazione concettuale viene introdotta proprio per separare gli aspetti "indipendenti dalla realizzazione" e gli aspetti di natura fisica, implementativa. nel video in inglese io faccio vedere uno di questi esempi, il fattore di blocco neella lettura/scrittura di dati su un disco. è il principio generale della "separation of concerns", della separazione dei problemi.
a livello concettuale io devo pensare a un insieme di attributi ed eventualmente una o più relationships che permettano di rispettare la definizione di entità come classe di observables, di occervabili, del mondo reale che abbiano proprietà comuni e esistenza autonoma nella relatà; appunto "classe" cioè insieme, ereditando in tal modo la proprietà delle istanze degli schemi di essere distinguibili l'una dall'altra (questa proprietà è resa dal concetto di esistenza autonoma, ma afferisce al concetto stesso di classe/insieme, alla natura originaria delle entità come classi, quindi conviene vederlo come proprietà incardinata nel concetto di classe, prima ancora che nella proprietà di autonomia.
l'identificatore, a livello concettuale, permette di isolare, di individuare. come quando siamo in una folla (non in questo momento storicfo!) e dobbiamo indicare a un'altra persona una terza persona nella folla, magari diciamo: vedi quel tipo, con gli occhiali rosa e i capelli neri, sicuri che di persone con gli occhiali rosa e i capelli neri ce ne sia una sola. ma se la persona accanto a noi dice, ma ce ne son oalmeno tre con gli occchiali rosa e i capelli neri, no isiamo costretti a dire: è vero, quello che dico io ha i pantaloni rossi, ecc.
ma noi non siamo in una folla siamo davanti a un compito di esame. e dobbiamo esercitare la fantasia, con razionalità. come fa lei quando fa l'esempio di Bella Napoli. Arrivando alla conclusione che se mai dobbiamo spiegare a una persona dove gli proponiamo di andare a mangiare stasera, probabilmente diremmo
al ristorante bella napoli a portici
al ristorante bella napoli che sta a via vesuvio 37 (meno probabile)
maq non diremmo
al ristorante che sta a via vesuvio 37 a portici
se non altro perchè questa persona ci guarderebbe con uno sguardo perplesso.
(quindi per rispondere a una sua domanda, il nome fa parte "naturalmente" dell'identificatore.
ecco nella progettazione concettuale il test per capire se un insieme di attributi + relationship è identificatore.
dopodichè se abbiamo dubbi (ma gli andrà bene al professore?) c'è una rete di sicurezza, metterci un codice e scrivere "assumo che il codice dei ristoranti sia univoco nella regione". è una soluzione un pò forzata e, come potrei dire, sporca, perchè viola il patto implicito tra docente e studente, quello di rappresentare solo ciò che è nei requisiti, ma è anche essa riportata nel patto non scritto, "sappi che nelle siutazioni molto incerte, in cui si può sbagliare, in cui la progettazione concettuale sconfina nella discussione retorica, in cui si possono portare tanti argomenti fino allo sfinimento, in quei casi, e solo in quei casi, si può inserire un codice univico. è come se lei avesse una freccia al suo arco, una sola freccia, che può usare in questi casi. basta che aggiunga una frase esplicativa.
spero di aver chiarito
terzo punto: piatto e ricetta
il suo argomento è molto efficace, e una grande soddisfazione che può avere un docente è di aiutare a formare studenti che forniscano osservazioni e analisi come la sua, dico aiutare a formare non retoricamente ma perxhè credo in un metodo didattico in cui il docente è una levatrice che forniecew gl istrumenti all ostudente di percorrere autonomamente il processo cognitivo di apprendimento, process oche porta a raginamenti del livello di profondità del suo messaggio relativo al terzo punto. come dicevo in altro messaggio, il voto a un esame è un voto sì allo studente, ma anche al docente (doipodichè so bene che del voto rimane traccia nella carriera dello studente e non in quella del docente, e che molti docenti non la pensano come me..)
il suo ragionamento è corretto in una prima fase poi improvvisamente fallisce.
è corrretto nel concepire questo concetto di ricetta, che è ben noto, e che in questo caso, in un compito tutto rivolto ai ristoranti e ai piatti nel menu, non compariva neanche nei requisiti, e che lei "inventa" per individuare una classe di piatti tutti dello stesso tipo, e con le stesse quantità di ingredienti. questa invenzione è lecita, anzi molto interessante, perchè sembra individuare una soluzione al problema della "dicotomia" del concetto di piatto, che è da una parte uguale per tutti i ristornanti (il piatto ha un nome e un codice unico .,..) e dall'altra in virtù della fantasia dei cuochi è diverso per tutti i ristoranti. lei dice: sì diverso ma io posso mettere insieme tutte le diversità in diversità omogenee, chiamandole ricette.
E lei ha ragione, ma qui comincia a perdersi, perchè le ricette non esistono in natura, ma sono ricette di piatti, la ricetta del cacciucco in cui uso il pepe e la ricetta del cacciucco in cui uso il sale dell'himalaia.
ma non la ricetta in cui uso il pepe, o la ricetta in cui uso il sale dell'himalaia. e la conferma che qui lei si perde nasce dal fatto, vada a rivedere come è scritto sopra, le ricette sono classi, dunque entità, e sono classi associate ai piatti, non ai ristoranti.
è per questo che la sua soluzione è sbagliata.
dopodichè le propongo di provare a produrre uno schema che colga la sua idea e rispetti la mia osservazione/obiezione
un saluto
carlo batini