リソース

/

ACP 実習ノート

[第6回] QueryPie ACPでSQLを承認してデータを変更する — 通常の参照権限を維持し、必要な作業だけ実行

DBアクセス制御 · 運用管理

2026年11月8日

本番DBを参照していると、配送済みなのに状態が古い、誤った値を訂正したいなど、1、2件を修正する場面がある。簡単な変更でも、誰が何のために変えたかは明確に残したい。

 

第5回ではDBアクセス権を申請して承認を受けた。今回はさらに、 実行するSQLを提出し、担当者の承認を受けてデータを変更することをQueryPie ACP Community EditionのSQL Requestで試した。

 

気になったのは、開発者の通常権限を広げずに対応できるかだ。実際には参照権限を維持したまま、承認済みSQLを実行して結果まで確認できた。

 

 

注文1件の配送状態を変更する

 

前回までのOrders Control Labを使い、配送済みなのにDBでは配送中のままという状況にした。実際の顧客注文ではなく実習データだ。

 

DBeaverで確認すると4002番はSHIPPED、金額32,000ウォンだった。変えるのは状態だけで、他の注文や金額は維持する。

 

画面1. 変更前の一覧。4002番はSHIPPEDだった。
画面1. 変更前の一覧。4002番はSHIPPEDだった。

 

申請者をDemo Developer、承認者をDemo Approverに分け、SQL用の規則も作った。担当者の確認・承認後に開発者が実行する。自己承認は使わなかった。

 

 

変更内容と理由をSQL申請に記載する

 

開発者でWorkflowのSQL Requestを開き、Orders Control Labとorders_controlを指定した。タイトルは「注文4002の配送完了状態への訂正」とし、次のSQLを入力した。

 

1234
UPDATE orders_control.ordersSET status = 'DELIVERED'WHERE order_id = 4002  AND status = 'SHIPPED';

 

WHEREには注文番号と現状態を指定し、4002番でまだSHIPPEDの注文だけを対象にした。理由にも配送完了の反映であり、変更予定は1件と記載した。

 

画面2. DB、SQL、作業理由、実行日を一つの申請にまとめた。
画面2. DB、SQL、作業理由、実行日を一つの申請にまとめた。

 

入力するうちに確認事項が整理された。どのDBで何をなぜ変更し、何件を見込むかがまとまる。実行希望日と有効期限はどちらも作業日に設定した。

 

提出後は申請者、承認者、実行者が順に表示され、次の担当が分かった。

 

画面3. 提出したSQL申請。申請・承認・実行の担当が区別されている。
画面3. 提出したSQL申請。申請・承認・実行の担当が区別されている。

 

 

承認者は実際のSQLを確認する

 

Demo ApproverでログインするとReceived RequestsのTo Doに届いていた。

 

開くとSQLと理由がそのまま表示された。注文番号4002と現状態の条件を確認し、「変更予定1件」とSQLを並べて検討できた。

 

画面4. 承認者がDB、SQL、理由を確認した。
画面4. 承認者がDB、SQL、理由を確認した。

 

判断に必要な情報が承認画面に集まる点がよかった。SQLの再送依頼が減り、データを変える前の確認手順を製品内で運用できる。

 

Approveを押し、注文番号と現状態条件を確認して1件の配送状態訂正を承認する旨をコメントした。

 

画面5. 確認した条件を承認コメントに残した。
画面5. 確認した条件を承認コメントに残した。

 

 

開発者が承認済み作業を実行する

 

開発者に戻るとExecutionsのTo Doに表示され、詳細にExecuteがあった。承認は完了し、次は実行だ。

 

画面6. 承認済み申請が開発者の実行待ち一覧へ移った。
画面6. 承認済み申請が開発者の実行待ち一覧へ移った。

 

承認と実行が別段階なのもよかった。確認後に指定実行者が続けられる。今回は申請した開発者を実行者に指定した。

 

Executeを押し、自動コミットで反映される案内を確認して実行した。完了後のResultsにはUPDATEとともに ‘1 Rows updated.’が表示された。申請時の予定件数と一致した。

 

画面7. 詳細画面で実行SQLと変更1件を確認した。
画面7. 詳細画面で実行SQLと変更1件を確認した。

 

申請、承認、結果確認が一つの作業としてつながった。後で変更理由を調べる際も、理由、SQL、担当者、結果を一緒に確認できて便利だ。

 

 

DBeaverでも変更後の値を確認する

 

DBeaverで元のSELECTを再実行すると4002番だけDELIVEREDになった。金額32,000ウォンと4001・4003番は変わっていなかった。

 

画面8. 承認済みSQLの実行後、4002番だけDELIVEREDに変わった。
画面8. 承認済みSQLの実行後、4002番だけDELIVEREDに変わった。

 

UPDATEはQueryPieの承認済み申請から実行し、DBeaverは変更前後の参照に使った。慣れたツールで確認し、変更は所定の承認手順で行う組み合わせが合っていた。

 

作業後に開発者のDBアクセス権も再確認した。 Read-Only (User), Selectの表示はそのままだった。今回のために通常アクセスを書き込み権限へ引き上げてはいない。

 

画面9. 変更作業後も通常のDBアクセス権はRead-Onlyのまま。
画面9. 変更作業後も通常のDBアクセス権はRead-Onlyのまま。

 

 

必要な修正を行い、通常権限は維持する

 

SQL Requestの利点は明確だった。開発者がSQLと理由を出し、承認者が内容を確認し、実行者が承認済み作業を処理する。それぞれの役割が画面で分かれていた。

 

一度限りの訂正のために通常権限を広げずに済む点が印象的だった。参照権限のまま1件を訂正でき、作業後に書き込み権限を回収する必要もなかった。

 

運用では速さだけでなく根拠を残すことも重要だ。同じ申請で、変更予定、承認者・実行者、実際の件数まで確認できた。

 

小さな状態変更だったが、業務を進めながら最小権限を維持する方法が具体的に見えた。本番DBの変更を一定の手順で管理したいチームに役立ちそうだ。

 

実習環境:QueryPie ACP Community 11.6.7 / MySQL 8.0.42 / DBeaver 26.2.4