# Tabelle di modifica
È possibile utilizzare gli strumenti per l'endpoint di destinazione per ottenere informazioni utilizzando i metadati nelle tabelle di modifica. Questi dati sono definiti dalle colonne di intestazione aggiunte allo schema delle tabelle di modifica. Per una descrizione di tali intestazioni, vedere la tabella qui sotto.
Per ogni tabella di destinazione nell'attività di replica, viene mantenuta una tabella di modifica con il nome corrispondente nel database, insieme alle tabelle di destinazione. Per ulteriori informazioni, vedere [Utilizzo delle tabelle di modifica](https://help.qlik.com/it-IT/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Replicating/use_change_table_model.htm). Una tabella di modifica contiene le colonne della tabella originale e le colonne di intestazione. I nomi delle colonne di intestazione includono un prefisso, in modo da non creare un conflitto con i nomi delle colonne della tabella. Il prefisso predefinito è `header__`. Per informazioni su come cambiare il prefisso, vedere l'elenco Tabelle di modifica nella sezione Metadati nelle impostazioni di Attività. La seguente tabella elenca le colonne di intestazione delle tabelle di modifica predefinite.
| Nome colonna | Tipo | Descrizione |
| --- | --- | --- |
| `[header__]change_seq` | varchar (35) | Un sequencer di modifica monotonicamente crescente comune a tutte le tabelle di modifica di un'attività. La sequenza di modifica ha il seguente formato:
YYYYMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx
Dove:
YYYY indica l'anno a quattro cifre (ad esempio 2012)
MM indica il mese a due cifre (intervallo 01-12)
DD indica il giorno a due cifre (intervallo 01-31)
HH indica l'ora del giorno (intervallo 00-23)
mm indica i minuti nell'ora (intervallo 00-59)
mm indica i secondi nel minuto (intervallo 00-59)
hh indica i centesimi di secondo (intervallo 00-99)
xxxxxxxxxxxxxxxxxxx è un numero di modifica a 19 cifre con prefisso zero (globale per attività)
La parte oraria di norma di riferisce all'ora in cui è stato effettuato il commit della transazione che include il record della modifica. Qlik Talend Data Integration include la logica che mantiene la monotonicità del numero della sequenza, quindi la modifica o la regolazione dell'ora dell'endpoint può causare più modifiche per fare in modo che sembrino incluse nello stesso timestamp ma con un numero di modifica crescente.
La parte xxx...xxx di norma è il numero di modifica interno dal record dei dati, tranne che i record BEFORE-IMAGE coincide con il numero di modifica del record UPDATE corrispondente (ad esempio, se il numero di modifica BEFORE-IMAGE è 1000 e quello di UPDATE è 1001, entrambi saranno 1001). Ciò consente un left outer join semplice tra la tabella e se stessa in cui a sinistra viene eseguita la scansione fino al punto nel tempo escludendo `operation=before-image`, mentre a destra viene completata l'unione nella stessa sequenza `change_seq` con `change_oper` che equivale a 'B'. |
| `[header__]change_oper` | varchar (1) | Il tipo di operazione. Può essere uno dei seguenti:
I: INSERT
D: DELETE
U: UPDATE
B: prima dell'immagine
|
| `[header__] change_mask` | varbinary (128) | La maschera di modifica indica quali colonne di dati nella tabella di modifica sono associate alle colonne che sono state modificate nella tabella di origine.
La posizione dei bit nella maschera di modifica si basa sul numero ordinale della colonna nella tabella di modifica. Questo significa che se vi sono 5 colonne intestazione, queste occupano i bit da 0 a 4 e la prima colonna di dati è il bit 5 nella maschera di modifica.
La maschera di modifica è una colonna binaria (un array di byte) che rappresenta la maschera di modifica in ordine little-endian:
In questo esempio, `bit#N` indica che la colonna della tabella di modifica di un N. ordinale è correlata a una colonna che è stata modificata nella tabella di origine. Se la maschera di aggiornamento è 11000 e l'ordinale della colonna è 3, la colonna non è stata modificata.
Per una descrizione della semantica dei bit, vedere di seguito:
Per i record INSERT, tutte le colonne inserite hanno i set di bit associati.
Per i record DELETE solo le colonne con chiave primaria (o indice univoco) hanno i set di bit associati. Ciò consente a un utente applicatore di creare un'istruzione DELETE senza dover cercare i campi della chiave primaria in un'altra sorgente.
Per i record BEFORE-IMAGE, tutti i bit sono liberi (la maschera di modifica può essere vuota).
Per i record UPDATE, ogni colonna il cui valore è stato modificato tra BEFORE-IMAGE e UPDATE avrà il set di bit associato.
Per garantire l'efficienza per elaborazione e spazio, il numero effettivo di byte archiviati nella maschera di modifica può avere un trim pari a null. Questo significa che gli zero finali non devono essere archiviati. La logica di gestione dovrebbe tenere in considerazione questi elementi. |
| `[header__] stream_position` | varchar (128) | La posizione del flusso della CDC di origine. |
| `[header__] operation` | varchar (12) | L'operazione associata al record di modifica. Può essere una delle seguenti:
INSERT
UPDATE
DELETE
BEFOREIMAGE
|
| `[header__] transaction_id` | varchar (32) | L'ID della transazione a cui appartiene il record di modifica.
Il valore è una stringa esadecimale dell'ID della transazione a 128 bit. |
| `[header__] timestamp` | data e ora | Il timestamp UTC originale della modifica (il valore può essere approssimativo).
Nota informatica Con le sorgenti PostgreSQL, il timestamp diviene noto solo una volta completato il commit. Pertanto, fino a quando non viene effettuato il commit sulle tabelle di origine, verrà visualizzata la data predefinita (ad es. 1970-01-01). |
| [header\_\_] `partition_name` | stringa | Il nome della partizione creata nella destinazione quando Cambia partizione dati è abilitato. Il nome della partizione è costituito dall'ora di inizio e di fine.