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