[DB] problemino concettuale con diagramma E-R

[}gu|do[z]{®©]

allora.. ho ripreso in mano un vecchio progetto per l'uni che forse è il caso di consegnare prima o poi
Come piero.mac ricorderà [] è un minidatabase (piuttosto semplificato insomma) per una rete di agenzie turistiche.

Fatta quasi tutta la parte di progettazione se non che mi sorge il seguente dubbio:

Una parte dello schema (non è proprio la notazione E-R.. non ricordo come si chiama questa notazione, ma è chiara credo ) associa clienti, pacchetti viaggio, e agenzie che li vendono......



Visto così pare corretto e semplice: l'associazione "ordine" si traduce con una tabella che non fa altro che associare gli id delle tre entità coinvolte. Il problema è che nella traccia è espressamente richiesto di tener traccia degli ordini passati... per cui si presenta il problema di un cliente abitudinario che fa in diverse date lo stesso viaggio acquistando il pacchetto nella stessa agenzia.
In soldoni: anche la data di partenza dovrebbe entrare a far parte della chiave... o sbaglio?
Ecco.. il punto è: in questa notazione schematica le associazioni non possono avere chiavi... per cui, è sbagliato lo schema? O posso tenerlo così e aggiungere la data alla chiave in fase di traduzione (non mi sembra una cosa pulita)?

Altri colleghi hanno inserito la data di partenza direttamente in pacchtto.. ma così facendo hanno una certa ridondanza in quell'entità (lo stesso pacchetto ripetuto per ogni data di partenza... ) e credo sia decisamente sbagliato.

Che fo?
Grazie a chiunque mi dia una dritta

[Teuzzo]

Lo stesso pacchetto ma in data diversa ha lo stesso costo oppure il costo cambia?

[}gu|do[z]{®©]

Originariamente inviato da Teuzzo
Lo stesso pacchetto ma in data diversa ha lo stesso costo oppure il costo cambia?

lo stesso..

il paccheto è un insieme di tratte e soggiorni (ognuno dei quali può essere anche nullo)..

no è chiaro.. io voglio u unico pacchetto per tutti i viaggi dello stesso tipo (chiaro che se un viaggio è in aereo e uno in treno il costo cambia..)

[piero.mac]

non e' che capisco granche' dei tuoi dubbi a dir la verita'...

hai tre entita' unite in un ordine a cui corrisponde una (o piu') data. Se la data cambia per una ripetizione di ordine avrai un nuovo record con la/le date nuove e le stesse entita'.

In altre parole la tabella ordini presenta un record per ogni ordinativo, poco importa se le tre entita' sono le stesse... sono ordini diversi, diversificati dal periodo.

Il tenere traccia penso si limiti a non utilizzare un record precedente simile nell'unione delle entita'. Tutto li', e quindi sara' un record diversificato dalla/dalle date.

un esempio alla guidozz... vado dal panettiere e compro un kg di pane pagando 2.5 euro. Lui (il panettiere) mi fa ogni giorno uno scontrino nuovo con le stesse entita' contenute tranne la data. Devo tenere lo scontrino e non riusare (lo scontrino) per il pane che comprero' domani. (se ti sfugge il senso... poi lo te lo spiega xxxxx modificato da kuarl )...

[}gu|do[z]{®©]

sì.. a livello di database fisico è chiaro... il problema è più che altro di notazione in effetti. E temo che questa notazione spiegataci dalla nostra prof sia poco comune.

E' evidente che la data dev'essere diversa... e quindi deve far parte della chiave dell'ordine (voglio selezionare esattamente quell'ordine fatto dal cliente x per il pacchetto y nel'agenzia z... in data tal dei tali).

Questo è chiaro.. il punto è che non sapendo come indicare che la dtaa deve far parte della chiave (credo non sia possibile in questa notazione) mi era venuto il dubbio che non ci fosse qualcosa di sbbagliato nello schema.
Ma mi son reso conto che se creassi una quarta entità "data" e una relazione a 4... sarebbe corretto, perchè la data entrerebbe a far parte dlla chiave in modo notazionalmente pulito.

Alla fine più tardi vado a chiedere alla prof quale sia la notazione corretta.. può essere che si ossa annerire il pallino dell'attributo ad indicare che fa parte della chiave, o che si possa esprimere "verbalmente" dopo lo schema... o che si possa fare una quarta entità data (che poi a livello pratico non diventa una tabella ma solo un attributo avendo cardinalità 1,1 sull'associazione)...

Insmma.. grazie per aver provato ad aiutarmi ma temo sia un problema di notazione