Newsgroup: it.comp.software.database
Titolo: terza dimensione ... il tempo

Ciao a tutti,
ho una domanda molto semplice da porvi, quali, e se esistono, DB che 
gestiscono lo storico dei dati ?.
Vi faccio uno stupido esempio ... il mio mulo nasce ed il primo anno gli 
misuro peso e altezza al secondo lo rimisuro e ne stabilisco il dato 
aggiornato ... come faccio a non cancellare il vecchio dato ma a 
conservarlo ? esiste qualche db che lo gestisce in automatico ? ho 
provato a leggere qua e la ma non sono molto convinto di quello che ho 
trovato si parla di uno standard di gestione introdotto in sql3 ? vi 
risulta ...
Aiuto ! Grazie

 gestiscono lo storico dei dati ?.
Mi auguro che tu stia scherzando.
-- 
                Molti desiderano ammazzarmi.
                Molti desiderano fare un'oretta
        \ | /   di chiacchiere con me.
        (@ @)   Dai primi mi difende la legge.
  ---o00-(_)-00o--------------------------------------------

se mi occupavo nella vita di db non sarei qui a porvi una domanda che a 
voi può sembrare banale.

salvem

scarica il pdf ed altro matariale disponibile presso 
http://www.cs.arizona.edu/people/rts/
saluti
-- 
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtm
 
http://italy.mvps.org
DbaMgr2k ver 0.18.0  -  DbaMgr ver 0.62.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual 
interface)
--------- remove DMO to reply 

No, no, no... è una cosa che devi prevedere tu al momento della 
progettazione della struttura.
Una cosa è riportare il DB ad uno stato in cui si trovava in un 
determinato istante, un'altra gestire dati storici.
Nel tuo esempio, devi separare i due tipi di informazione: "il mulo" e 
"le sue dimensioni".
In "il mulo" metti i dati invariabili (o di cui non ti servirà tenere 
traccia delle modifiche)
In "le sue dimensioni" inserisci in coda i nuovi valori via via che si 
rendono disponibili, impostando il valore relativo in una colonna di 
timestamp.
Una bella relazione uno-a-molti tra i due, qualche query ben fatta ed 
hai tutto ciò che ti serve.
Alex.



Non credo che esistono DB Server di questo tipo.
Comunque, il problema si risolve semplicemente aggiungendo 2 ulteriori 
campi nella struttura tabellare: Data/ora inizio validità e Data/ora fine 
validità.
Poi è sufficiente scrivere oppure rivedere le query in maniera tale da 
tener conto in quale periodo temporale devo eseguire la query.
Ciauzzzzz

 gestiscono lo storico dei dati ?.
Premesso che stai parlando di dbms e non di db...
Stai tranquillo che non è per niente una domanda banale.
Il problema è trovare una soluzione che estenda l'Sql senza rompere
i programmi esistenti; inoltre, quando si prendono in considerazione
tabelle temporali, si intendono concetti differenti:
1) Una semplice storia dei dati; questa è la più semplice da
fare; è parte logica del predicato della tabella. Esempio:
PesatureMuli { Nome, DataPesatura, Kg }
Le query e l'integrità funzionano esattamente come in un db classico.
Da notare che non si considerano intervalli di tempo, ma istanti.
2) Tabelle con RIGHE (NB: non record) che variano nel tempo, vale a
dire che dal punto di vista LOGICO un fatto è vero oggi ma può essere
falso nel passato.
PesoMuli { Nome, Kg }
dovrebbe diventare:
PesoMuli { Nome, Kg, DataStart, DataEnd }
per registrare il fatto che una riga è valida solo entro un arco di
tempo. Questa apparentemente innocua aggiunta entra a far parte
del predicato della tabella e *deve assolutamente* essere considerata
in ogni aspetto sia del db (es. primary key, integrità referenziale)
sia delle query che la interrogano, PENA RISULTATI ERRATI!
Come effetto collaterale, rompe irrimediabilmente tutte le query
precedentemente scritte col "vecchio metodo" (!).
3) Tabelle con valore dei RECORD (NB: non righe) che vengono cambiati
nel tempo. Qui non si intende dire che un fatto che è vero oggi non
lo era nel passato, ma si intende dire proprio che il valore fisico
è stato alterato, ad esempio a causa di errori di inserimento.
Per quale motivo bisognerebbe tenerne traccia? Ad esempio, per un
controllo della sicurezza (potrei dover sapere chi ha cambiato il
record e quando).
Stesso metodo del punto 2, si aggiungono due colonne, MA SIGNIFICANO
UN'ALTRA COSA: non riguardano più un fatto della realtà (riga), ma
riguardano un fatto al livello FISICO, ovverosia quando un record è
stato effettivamente inserito.
Il problema è che comunque queste righe te le ritrovi nella tabella
a livello logico, alterando risultati delle query etc etc.
4) Una combinazione dei punti 3 e 4.
Voglio rimarcare che una tabella temporale è completamente tutta
un'altra cosa rispetto a quella di cui siamo abituati a parlarne.
La strada da seguire imho non è da ricercarsi in una
soluzione fatta a colpi di aggiunte "a mano", ma va riprogettato
il motore del dbms in modo che lo faccia lui in automatico.
Soprattutto i valori temporali non devono apparire a meno che
esplicitamente l'utente non li richieda, e quindi è preparato a
manipolarli correttamente; questo per far sì che il db sembri
quello "classico" a cui siamo abituati.
PS: la soluzione che ti ha dato APB è quella più "redditizia"

 
http://www.cs.arizona.edu/people/rts/
Il libro di Snodegrass l'avevo letto e poi stampato un annetto fa.
Bel libro ben fatto.

Innanzitutto mi inchino alla vostra disponibilità e vi ringrazio di 
cuore. E' la prima volta che mi rivolgo ad un forum e devo dire che mi 
avete veramente sorpreso con la vostra disponibilità. GRAZIE !
In secundis, ho letto attentamente le vostre risposte e devo dire che mi 
hanno aiutato molto a indirizzarmi verso una soluzione " veloce " al mio 
problema, infondo si tratta solo di una tesi.
Vi è una curiosità che mi girella in capo... nessuna software house ha 
già commercializzato qualche dbms che supporti questo tipo di " dato " ? 
  o forse tutti hanno già messo a disposizione dei tool per la gestione 
della 4 dimensione ( dopo che avevo scritto il titolo mi sono accorto 
che vi è un piccolo difetto ... il tempo è la 4 e non la terza 
dimensione .... :-) )
Grazie mille di nuovo a tutti e complimenti.