Qual'è la migliore politica di gestione della storicizzazione e del versionamento delle entità in un database ?
Giuseppe Arici
Sto cercando di risolvere il seguente problema:
"Poter recuperare lo stato, ad una determinata data passata, di un'entità
X e delle entità ad essa collegate.
Gestire le modifiche all'entità X con data di effetto differita rispetto
alla data di modifica del record."
In pratica devo poter vedere l'immagine di quella entità ad una data passata,
recuperando non solo i valori dei suoi campi, ma anche delle entità ad essa
collegate. Inoltre devo poter inserire una modifica a quella entità facendo
in modo che tale modifica abbia una data di validità successiva a quella
di inserimento, una sorta di versione potenziale non ancora attiva, tenendo
conto ovviamente delle possibili collisioni tra due modifiche future sullo
stesso campo.
Esistono in letteratura dei pattern per risolvere questo problema ?
Qualsiasi consiglio è ben accetto.
Grazie in anticipo.
Giuseppe.
Andrea Montanari
probabilmente trovi molto presso http://www.cs.arizona.edu/people/rts/
saluti
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz http://italy.mvps.org
DbaMgr2k ver 0.21.0 - DbaMgr ver 0.65.0 and further SQL Tools
--------- remove DMO to reply
AlessandroD
> "Poter recuperare lo stato, ad una determinata data passata, di
> un'entità
> X e delle entità ad essa collegate.
> Gestire le modifiche all'entità X con data di effetto differita
> rispetto alla data di modifica del record."
>
Tabelle legate da vincoli di foreign key? O legami solo logici implementati
in altri modo (trigger, SP)?
Ciao, Alessandro
Giuseppe Arici
> Giuseppe Arici wrote:
>> Ciao a tutti,
>>
>> Sto cercando di risolvere il seguente problema:
>>
>> "Poter recuperare lo stato, ad una determinata data passata, di
>> un'entità X e delle entità ad essa collegate.
>> Gestire le modifiche all'entità X con data di effetto differita
>> rispetto alla data di modifica del record."
>> In pratica devo poter vedere l'immagine di quella entità ad una data
>> passata, recuperando non solo i valori dei suoi campi, ma anche delle
>> entità ad essa collegate. Inoltre devo poter inserire una modifica a
>> quella entità facendo in modo che tale modifica abbia una data di
>> validità successiva a quella di inserimento, una sorta di versione
>> potenziale non ancora attiva,
>> tenendo conto ovviamente delle possibili collisioni tra due modifiche
>> future sullo stesso campo.
>> Esistono in letteratura dei pattern per risolvere questo problema ?
>>
> probabilmente trovi molto presso http://www.cs.arizona.edu/people/rts/
> saluti
>
Grazie,
ho trovato molti spunti interessanti a partire da questo articolo (http://www.cs.arizona.edu/people/rts/DBPD/collection.pdf
)
Il problema è che alcuni costrutti che il professor Snodgrass illustra fanno
uso di caratteristiche di SQL3 (http://www.cs.arizona.edu/~rts/sql3.html)
e in generale dei "Temporal Database" (http://en.wikipedia.org/wiki/Temporal_database)
Per quanto ne so, alcuni costrutti come PERIOD o VALIDTIME non sono attualmente
supportati da MS Sql Server 2005.
Comunque il materiale mi è risultato molto utile per focalizzare il problema.
Ho trovato questo libro (http://www.cs.arizona.edu/people/rts/tdbbook.pdf)
"Developing Time-Oriented Database Applications in SQL" di Richard T. Snodgrass
e Christian S. Jensen, liberamente scaricabile dalla rete e ho trovato anche
un pattern del Fowler sull'argomento (http://www.martinfowler.com/eaaDev/timeNarrative.html)
"Temporal Patterns".
Grazie ancora,
Ciao,
Giuseppe.
Giuseppe Arici
Ciao,
per entità collegate intendo principalmente tabelle collegate da foreign
key o da tabelle di legame.
Ti faccio un esempio per chiarire.
Ho un' entità "polizza" che ha delle entità "allegati" ad essa collegate.
Devo essere in grado di risalire allo stato della polizza e dei suoi allegati
ad una determinata data.
Ciao,
grazie,
Giuseppe.
AlessandroD
> Ho un' entità "polizza" che ha delle entità "allegati" ad essa
> collegate. Devo essere in grado di risalire allo stato della polizza
> e dei suoi allegati ad una determinata data.
>
Non che ci abbia ragionato molto su, ma, con due campi datetime per gestire
l'intervallo di validità di ogni record, una chiave surrogata che comunque
permette di identificare in modo "breve" ogni record per portarselo dietro
nei legami tra le tabelle, e un set di funzioni, una per ogni tabella, che
dati due parametri datetime, ti tiri fuori i record che attualizzano la
tabella per l'intervallo specificato, non sei "a posto"? Cioè, questo non
dovrebbe essere sufficiente per implementare tutto il resto come una
conseguenza?
Ciao, Alessandro
Andrea Montanari
mi associo ad Alessandro... solitamente viene indicato nel predicato un
attributo di validita' temporale, quindi, ovviamente, 2 colonne [ValidoDal]
[ValidoFino] o simili..
Andrea Montanari
Andrea Montanari wrote:
> salve,
> AlessandroD wrote:
>> Giuseppe Arici wrote:
>>
>>> Ho un' entità "polizza" che ha delle entità "allegati" ad essa
>>> collegate. Devo essere in grado di risalire allo stato della polizza
>>> e dei suoi allegati ad una determinata data.
>>>
>> Non che ci abbia ragionato molto su, ma, con due campi datetime per
>> gestire l'intervallo di validità di ogni record, una chiave surrogata
>> che comunque permette di identificare in modo "breve" ogni record per
>> portarselo dietro nei legami tra le tabelle, e un set di funzioni,
>> una per ogni tabella, che dati due parametri datetime, ti tiri fuori
>> i record che attualizzano la tabella per l'intervallo specificato,
>> non sei "a posto"? Cioè, questo non dovrebbe essere sufficiente per
>> implementare tutto il resto come una conseguenza?
>> Ciao, Alessandro
sulla chiave surrogata addizionale ho qualche perplessita'... la "ricerca"
infatti si dovrebbe sempre basare su "chiavi temporali", vista la natura del
predicato stesso, quindi, a mio parere, e' ininfluente tale attributo..
sapendo che ricerco l'articolo xxx nel periodo yyy, tutti i valori del
relativo predicato andrebbero scandagliati nella partizione temporale di
validita' del periodo..
AlessandroD
>
> sulla chiave surrogata addizionale ho qualche perplessita'... la
> "ricerca" infatti si dovrebbe sempre basare su "chiavi temporali",
> vista la natura del predicato stesso, quindi, a mio parere, e'
> ininfluente tale attributo.. sapendo che ricerco l'articolo xxx nel
> periodo yyy, tutti i valori del relativo predicato andrebbero
> scandagliati nella partizione temporale di validita' del periodo..
>
immaginato io la soluzione il fatto di avere tabelle legate tra loro in un
certo momento storico potesse essere fotografato usando come legame tra le
stesse il valore corrente delle varie chiavi surrogate (avendo fatto
ovviamente a monte i controlli necessari sulla consistenza delle varie date
di validità per tutte le tabelle chiamate in causa). In modo che poi,
volendo visitare una qualsiasi tabella della catena in un periodo temporale
arbitrario si potesse ricomporre velocemente tutta la catena attraverso le
varie chiavi surrogate usate in precedenza per fissare il legame.
Quindi io non la vedevo proprio come una soluzione completamente dinamica
senza nessun vero vincolo di foreign key e con l'affidamento alle sole
funzioni di attualizzazione delle tabelle per recuperare il legame temporale
in real-time per tutti i componenti della catena, era più una specie di via
di mezzo, o almeno così erano le mie intezioni... :-)
Ciao, Alessandro