# 変更テーブル

ターゲット エンドポイントのツールを使用し、変更テーブルのメタデータを使用して情報を取得できます。このデータは、変更テーブル スキーマに追加されたヘッダー列によって定義されます。これらのヘッダーについては、次の表で説明します。

レプリケーション タスクのすべてのターゲット テーブルについて、対応する名前を持つ変更テーブルが、ターゲット テーブルを持つデータベース内で保持されます。詳細については、「[変更テーブルの操作](https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Replicating/use_change_table_model.htm)」を参照してください。変更テーブルには、元のテーブル列とヘッダー列が含まれます。名前がソース テーブルの列名と競合しないように、ヘッダー列にはプレフィックスが含まれています。既定のプレフィックスは `header__` です。このプレフィックスを変更する方法については、 [タスク設定] の [メタデータ] にある、 [変更テーブル] リストを参照してください。次の表は、既定の変更テーブルのヘッダー列を示しています。

| 列名 | [Type] (タイプ) | 説明 |
| --- | --- | --- |
| `[header__]change_seq` | varchar (35) | タスクのすべての変更テーブルに共通の、単調に増加する変更シーケンス。変更シーケンスの形式は次のとおりです。<br><br>YYYYMMDDHHmmSShhxxxxxxxxxxxxxxxxxxx<br><br>条件:<br><br><ul> <li>YYYY は 4 桁の年 (2012 など)</li> <li>MM は 2 桁の月 (01 ～ 12 の範囲)</li> <li> <p>DD は 2 桁の日 (01 ～ 31 の範囲)</p> </li> <li>HH は 1 日の時間 (00 ～ 23 の範囲)</li> <li>mm は分 (00 ～ 59 の範囲)</li> <li>SS は秒 (00 ～ 59 の範囲)</li> <li>hh は 100 分の 1 秒 (00 ～ 99 の範囲)</li> <li>xxxxxxxxxxxxxxxxxxx は 19 桁の接頭辞ゼロの変更番号 (タスクごとにグローバル)</li> </ul><br><br>時間部分は通常、変更レコードを含むトランザクションのコミット時間を指します。Qlik Talend Data Integration にはシーケンス番号の単調性を維持するロジックが含まれているため、エンドポイント時間を変更または調整すると、同じタイムスタンプ内でありながら変更番号が増加しているように見える複数の変更が生じる可能性があります。<br><br>xxx...xxx は通常、データ レコードの内部変更番号です。ただし、BEFORE-IMAGE レコードの場合は、一致する UPDATE レコードの変更番号と同じになります (例: BEFORE-IMAGE の変更番号が 1000 で UPDATE の変更番号が 1001 である場合、両方とも 1001 になります)。これにより、テーブルとそれ自体の間の単純な左外部結合が可能になります。左側では、ある時点までスキャンしますが、`operation=before-image` を除外し、右側では、`change_oper` が「B」である同じ `change_seq` で結合します。 |
| `[header__]change_oper` | varchar (1) | 操作の種類。これは次のいずれかになります。<br><br><ul> <li><code>I</code>: INSERT</li> <li><code>D</code>: DELETE</li> <li><code>U</code>: UPDATE</li> <li><code>B</code>: 前画像</li> </ul> |
| `[header__] change_mask` | varbinary (128) | 変更マスクは、変更テーブル内のどのデータ列がソース テーブルで変更された列に関連付けられているかを示します。<br><br>変更マスク内のビット位置は、変更テーブル内の列の序数に基づきます。つまり、ヘッダー列が 5 つある場合、それらはビット 0 ～ 4 を占め、最初のデータ列は変更マスクのビット 5 になります。<br><br>変更マスクは、変更マスクをリトルエンディアン順で表すバイナリ列 (バイト配列) です。<br><br>バイト0 bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0<br><br>バイト 1 bit15 bit14 bit13 bit12 bit11 bit10 bit9 bit8<br><br>この例では、`bit#N` は、序数 N の変更テーブル列がソース テーブルで変更された列に関連していることを示します。更新マスクが 11000 で、列の序数が 3 の場合、列は変更されません。<br><br>ビットのセマンティクスの説明は次のとおりです。<br><br><ul> <li>INSERT レコードの場合、挿入されたすべての列に関連するビットが設定されます。</li> <li>DELETE レコードの場合、主キー (または一意のインデックス) 列にのみ関連ビットが設定されます。これにより、アプライヤーは、別のソースから主キー項目を見つけなくても DELETE ステートメントを構築できます。</li> <li>BEFORE-IMAGE レコードの場合、すべてのビットはクリアされます (変更マスクは空にできます)。</li> <li>UPDATE レコードの場合、BEFORE-IMAGE と UPDATE の間で値が変更された各列には、関連するビットが設定されます。</li> </ul><br><br>スペースと処理効率を高めるために、変更マスクに保存される実際のバイト数は null を取り除くことができます。つまり、末尾のゼロを保存する必要はありません。処理ロジックではこれを考慮する必要があります。 |
| `[header__] stream_position` | varchar (128) | ソース CDC ストリームの位置。 |
| `[header__] operation` | varchar (12) | 変更レコードに関連付けられた操作。次のいずれかになります。<br><br><ul> <li>INSERT</li> <li>UPDATE</li> <li>DELETE</li> <li>BEFOREIMAGE</li> </ul> |
| `[header__] transaction_id` | varchar (32) | 変更レコードが属するトランザクションの ID。<br><br>値は、128 ビットのトランザクション ID の 16 進文字列です。 |
| `[header__] timestamp` | タイムスタンプ | 元の変更の UTC タイムスタンプ (値はおおよその値である可能性があります)。<br><br>情報メモ PostgreSQL ソースの場合、タイムスタンプはコミットが発生した後にしかわかりません。したがって、変更がソース テーブルにコミットされるまでは、既定の日付 (例: 1970-01-01) が表示されます。 |
| [header\_\_] `partition_name` | 文字列 | [データ パーティションの変更] が有効な場合にターゲット上に作成されるパーティションの名前。パーティションの開始時刻と終了時刻で構成されるパーティション名。<br><br>例:<br><br>20170313T123000\_20170313T170000 |