UPDATE
UPDATEについては、UPDATEが正常に完了し、行われた行レベルの変更が正確にキャプチャーされていることを確認する必要がある更新シナリオを考えてみましょう。 と説明があります。
上記をテストするためのSQLサンプルがこちら
--
-- update case --- simple usage to return table values of what was updated
--
select SALES_ID, sales , SALES_PERSON
from final table (
update toystore.sales
set sales = sales + 5
where sales_person = 'ROWE'
);
sales＝売上数です。FINAL TABLEでROWEさんの売上数を+5しています。
以下、上記SQLの実行前後のレコードの比較です。
UPDATE実行前 全件SELECTの結果。42, 43行目がROWEさんの売上レコードで売上数はそれぞれ1です。
UPDATE実行結果
上記のSQLサンプルを実行すると以下が実行されます
1. UPDATE命令が実行される（ROWEさんのレコードの売り上げがそれぞれ+5される）
2. UPDATEされたレコードが返される
1.と2.を同時に実行できるのがFINAL TABLEのメリット（使いみち）その1のようです。
通常の手順と比較してみる
FINALテーブルを使用しない、普通の?処理手順と比較してみましょう。
まず、レコードの初期状態を確認します。今回はLEEさんの Ontario-Southでの売上レコードを対象にしてみます。
実行前データの確認
select * from toystore.sales
where sales_person = 'LEE' and REGION = 'Ontario-South' ;
実行結果はこちら
普通の手順1. LEEさんの売上を+1する
update toystore.sales
set sales = sales + 1
where sales_person = 'LEE' and REGION = 'Ontario-South' ;
実行結果はこちら
メッセージから5行が更新されたことが分かりますが、どのレコード？変更後の値？はわかりません。
普通の手順2. LEEさんの更新されたレコードを検索する
select * from toystore.sales
where sales_person = 'LEE' and REGION = 'Ontario-South' ;
実行結果は、
エウレカ（Eureka）！ 、と叫んだかもしれませんｗ
FINAL TABLEの手順
あー、と、それではFINAL TABLEを使ってみましょう。
LEEさんのOntario-Southでの売上をさらに+1してみます。同時に結果を表示します。
select SALES_ID, sales , SALES_PERSON
from final table (
update toystore.sales
set sales = sales + 1
where sales_person = 'LEE' and REGION = 'Ontario-South'
);
上記の実行結果は
つまりFINAL TALBEの使い方の一つは、UPDATEを実行し、同時にUPDATEの結果を取得できるということのようです。
メタデータを使用するUPDATEのサンプル
UPDATEはもう一つ、サンプルが掲載されています。こちらは以下のようなユースケース説明があります。
監査シナリオでは、すべての更新操作が正常に実行され、変更に関する明確で検証可能な記録が維持されていることを確認します。この検証には、各更新がエラーなく正しいレコードに影響を与えていることを確認することが含まれます。また、行われた変更に関する詳細情報の取得も含まれます。このような情報には通常、更新されたフィールドの前後の値、変更を行ったユーザーまたはシステム、タイムスタンプ、関連するトランザクション識別子が含まれます。
トレーサビリティとコンテキストを向上させるには、カスタム監査メッセージをターゲットテーブルまたは関連する監査ログに直接埋め込むことを検討してください。このメッセージは、「年度末調整による調整済み」など、変更の説明に関する追加情報を提供できます。このメッセージは、内部ガバナンスと外部コンプライアンス要件の両方をサポートするのに役立ちます。
平たく書くと、UPDATEの更新前後の値を表示する、その際、いつ、誰によって更新されたかも表示する というユースケースです。
サンプルSQLはこちら
※サンプルを修正して、LEEさんのOntario-Southの売上を対象にしてみました
select SALES_ID,SALES_PERSON, sales ,OLD_SALES, REGION, AFTER_UPDATE_MESSAGE
from final table (
update toystore.sales
INCLUDE (
OLD_SALES INTEGER,
AFTER_UPDATE_MESSAGE VARCHAR(126)
)
set
sales = sales + 1,
old_sales = sales, --- old sales value for perhaps audit tracing before the update passed ?
AFTER_UPDATE_MESSAGE = 'UPDATE completed normally by user:' CONCAT current user CONCAT ' on 'CONCAT CHAR(current timestamp)
where sales_person = 'LEE' and REGION = 'Ontario-South'
);
ポイントは以下だと思います。
OLD_SALESにUPDATE前の売上数をセットする
いつ、だれによって更新されたかのメッセージを表示する
上記SQLの実行結果がこちら
FILNAL TABLEのメリットその2はUPDATE前の値を取得できる、
その3はメタデータをセットできる
という事のようです。
だいぶ分かった気がします。（SQLで開発している人は1.の記事だけで分かったんだなあ、と思いました。^^;）