Newsgroup: it.comp.software.database
Titolo: Progettazione DB:Dati che cambiano nel tempo e ricostruzione storica

Consideriamo un semplice db per la gestione ordini/fornitori.
Tabelle con le ovvie relazioni: Fornitori, Prodotti, Ordini, RigheOrdine
Ora il problema è che nel tempo il prezzo dei prodotti cambia, ma io voglio 
poter ricorstruire la situazione di un ordine di due anni fa con i dati di 
due anni fa (ovviamente potrebbero cambiare anche l'indirizzo del fornitore 
etc...) ad es. per poter ristampare e ovviamente vorrei poter eseguire query 
di ricerca per fornitore, prodotto etc.
- Se utilizzo solo le relazioni canoniche, ovviamente perdo l'informazione 
storica.
- Se copio il valore dei campi del prodotto al momento della creazione del 
dettaglio degli ordini, replico molti dati, e perdo il legame con il 
prodotto
- Posso utilizzare una via di mezzo, lasciando sia la chiave esterna per il 
prodotto che la replica delle informazioni correnti.
- Posso dividere la tabella prodotti lasciando la parte immutabile Codice, 
Descrizione, etc e legarla ad una tabella con le informazioni modificabili, 
magari introducendo pure la data di validità per tali informazioni
Sicuramente ci sono molte altre possibilità, vorrei sapere se qualcuno di 
voi ha suggerimenti, e ovviamente anche dei link specifici su questo tema 
(ho alcuni testi sulla progettazione dei database ma nessuno tratta questo 
tipo di argomento che direi, ironicamente, troppo pratico).
Ringrazio tutti per la collaborazione.


il prezzo sulla riga d'ordine non è una replica, ma una necessità!
è vero che avendo una tabella del listino prezzi con le date di inizio
e fine validità avresti lo storico dei prezzi, ma credimi prima o poi
capita che devi gestire un prezzo "particolare" e allora...

Anderthal ha scritto:

Aggiungo che in sistemi di questo tipo, una denormalizzazione del
database
sui dettagli ordini, sacrifica sicuramente dello spazio, ma da
vantaggi sia in
termini di storicizzazione che velocità nello recupero dei dati.
Il legame col prodotto lo dovresti mantenere con il codice prodotto.
Se per il cliente serve, puoi creare una tabella con la struttura
simile a quella
dei prodotti, con in più una data di cambiamento, dove storicizzerai
una
riga per ogni volta che cambia un prodotto. Questo occupa molto (?)
spazio,
dipende dal tuo catalogo, ma conoscendo la data dell'ordine ed avendo
uno
storico...


Ringrazio, pertanto riassumendo:
Mantenere sia la chiave esterna per sfruttare il legame con la tabella 
prodotti in modo immediato, sia la copia delle informazioni, diciamo 
snapshot, utili per la storicizzazione nella stessa tabella, risulta essere 
una tecnica che, seppur denormalizzando il db, si usa frequentemente.
Ovviamente lo stesso vale per tutte quelle tabelle che vengono utilizzate 
per produrre documenti contrattuali come fatture, offerte, etc.
Il prezzo da pagare è quindi principalmente relativo allo spazio occupato.
La mia domanda era per vedere se tutta la teoria della normalizzazione viene 
poi, come dire, "aggiustata", per i casi pratici o se invece esistono 
tecniche diffuse che permettono di non violarla.
Domanda: Sapreste indicarmi testi che affrontino le problematiche di 
progettazione db a questo livello (come anche il problema del legame con 
entità di provenienti da tabelle diverse, relazioni ISA), saltando la teoria 
base?
Grazie a tutti

 Grazie a tutti
Lucazeo

 storica.
[CUT]
Puoi sempre prevedere due colonne "valdido dal" "valido al"
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa 
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 direi, ironicamente, troppo pratico).
Il vero problema e' che il supporto dovrebbe essere incorporato
nel dbms (o meglio ancora, nel linguaggio), altrimenti vai a fare
una faticaccia immane con concreto rischio di errori.
bye