監査ログ用のデータベース設計を考えていますか？ヘンゼルとグレーテルに何が起こったかを思い出してください。彼らは、パンくずリストの簡単な跡を残すことが、自分たちの歩みをたどる良い方法だと考えました。
データモデルを設計するとき、今が存在するすべてであるという哲学を適用するように訓練されています。 。たとえば、製品カタログの価格を格納するスキーマを設計する場合、データベースは現時点で各製品の価格を通知するだけでよいと考えるかもしれません。しかし、価格が変更されたかどうか、変更された場合はいつ、どのように変更されたかを知りたい場合は、問題が発生します。もちろん、変更の時系列の記録を保持するようにデータベースを特別に設計することもできます。これは一般に、監査証跡または監査ログとして知られています。
監査ログにより、データベースは過去のイベントの「メモリ」を持つことができます。価格表の例を続けると、適切な監査ログにより、データベースは、価格がいつ更新されたか、更新前の価格、誰が更新したか、どこから更新されたかを正確に知ることができます。
データベース監査ログソリューション
データベースが、データで発生するすべての変更について、その状態のスナップショットを保持できれば素晴らしいと思います。このようにして、任意の時点に戻って、映画を巻き戻しているかのように、その正確な瞬間のデータがどのようになっていたかを確認できます。しかし、監査ログを生成するその方法は明らかに不可能です。結果として得られる情報量とログの生成にかかる時間は長すぎます。
監査ログ戦略は、削除または変更できるデータに対してのみ監査証跡を生成することに基づいています。変更をロールバックしたり、履歴テーブルのデータをクエリしたり、疑わしいアクティビティを追跡したりするには、それらの変更を監査する必要があります。
一般的な監査ロギング手法はいくつかありますが、いずれもすべての目的に役立つわけではありません。最も効果的なものは、多くの場合、高価で、リソースを大量に消費するか、パフォーマンスが低下します。他のものはリソースの点で安価ですが、不完全であるか、維持するのが面倒であるか、または設計品質の犠牲を必要とします。どの戦略を選択するかは、アプリケーションの要件と、尊重する必要のあるパフォーマンスの制限、リソース、および設計の原則によって異なります。
すぐに使用できるロギングソリューション
これらの監査ログソリューションは、データベースに送信されたすべてのコマンドをインターセプトし、別のリポジトリに変更ログを生成することで機能します。このようなプログラムは、ユーザーのアクションを追跡するための複数の構成およびレポートオプションを提供します。最高の特権を持つユーザーからのものであっても、データベースに送信されたすべてのアクションとクエリをログに記録できます。これらのツールは、パフォーマンスへの影響を最小限に抑えるように最適化されていますが、多くの場合、金銭的なコストがかかります。
データの変更を完全に監視および監査可能にする必要があり、監査証跡を変更できないようにする必要がある機密性の高い情報（医療記録など）を処理する場合は、専用の監査証跡ソリューションの価格を正当化できます。ただし、監査証跡の要件がそれほど厳しくない場合は、専用のログソリューションのコストが高額になる可能性があります。
リレーショナルデータベースシステム（RDBMS）が提供するネイティブ監視ツールを使用して、監査証跡を生成することもできます。カスタマイズオプションを使用すると、記録されるイベントをフィルタリングして、不要な情報を生成したり、後で使用されないログ操作でデータベースエンジンに過負荷をかけたりしないようにすることができます。この方法で生成されたログにより、テーブルで実行された操作の詳細な追跡が可能になります。ただし、イベントを記録するだけなので、履歴テーブルのクエリには役立ちません。
監査証跡を維持するための最も経済的なオプションは、監査ログ用にデータベースを特別に設計することです。この手法は、データベースを更新するアプリケーションに固有のトリガーまたはメカニズムによって入力されるログテーブルに基づいています。監査ログデータベースの設計に広く受け入れられているアプローチはありませんが、一般的に使用される戦略がいくつかあり、それぞれに長所と短所があります。
データベース監査ログの設計手法
監査ログインプレースの行バージョン管理
テーブルの監査証跡を維持する1つの方法は、各レコードのバージョン番号を示すフィールドを追加することです。テーブルへの挿入は、初期バージョン番号とともに保存されます。変更または削除は実際には挿入操作になり、更新されたデータを使用して新しいレコードが生成され、バージョン番号が1つインクリメントされます。この監査ログインプレース設計の例を以下に示します。
注：行のバージョン管理が埋め込まれたテーブルデザインは、外部キー関係によってリンクすることはできません。
バージョン番号に加えて、レコードに加えられた各変更の原因と原因を特定するために、いくつかの追加フィールドをテーブルに追加する必要があります。
- 変更が記録された日時。
- ユーザーとアプリケーション。
- 実行されたアクション（挿入、更新、削除）など。監査証跡を有効にするには、テーブルは挿入のみをサポートする必要があります（更新と削除は許可されません）。他のフィールドの組み合わせは繰り返しの対象となるため、テーブルには必ず代理主キーが必要です。
クエリを介して更新されたテーブルデータにアクセスするには、各レコードの最新バージョンのみを返すビューを作成する必要があります。次に、レコードの時系列を表示することを特に目的としたクエリを除くすべてのクエリで、テーブルの名前をビューの名前に置き換える必要があります。
このバージョン管理オプションの利点は、監査証跡を生成するために追加のテーブルを使用する必要がないことです。さらに、監査対象のテーブルに追加されるフィールドはごくわずかです。ただし、これには大きな欠点があります。最も一般的なデータベース設計エラーのいくつかを実行する必要があります。これらには、必要なときに参照整合性または自然主キーを使用しないことが含まれ、エンティティ関係図の設計の基本原則を適用することが不可能になります。データベース設計エラーに関するこれらの有用なリソースにアクセスできるため、他にどのような方法を避けるべきかについて警告が表示されます。
シャドウテーブル
別の監査証跡オプションは、監査が必要なテーブルごとにシャドウテーブルを生成することです。シャドウテーブルには、監査するテーブルと同じフィールドに加えて、特定の監査フィールド（行のバージョン管理手法で説明したものと同じもの）が含まれています。
シャドウテーブルは、監査するテーブルと同じフィールドに加えて、監査目的に固有のフィールドを複製します。
シャドウテーブルに監査証跡を生成するための最も安全なオプションは、挿入、更新、および削除のトリガーを作成することです。これにより、元のテーブルの影響を受けるレコードごとに、監査テーブルにレコードが生成されます。トリガーは、シャドウテーブルに記録する必要のあるすべての監査情報にアクセスできる必要があります。データベースエンジンの特定の機能を使用して、現在の日時、ログに記録されたユーザー、アプリケーション名、操作が開始された場所（ネットワークアドレスまたはコンピューター名）などのデータを取得する必要があります。
トリガーを使用するオプションがない場合、監査証跡を生成するロジックは、データベースに向けられたすべての操作をインターセプトできるように、データ永続化レイヤーの直前に理想的に配置されたレイヤーのアプリケーションスタックの一部である必要があります。
この種のログテーブルでは、レコードの挿入のみを許可する必要があります。それらが変更または削除を許可する場合、監査証跡はその機能を果たさなくなります。また、元のテーブルの依存関係と関係をテーブルに適用できないため、テーブルは代理主キーを使用する必要があります。
監査証跡を作成したテーブルに、それが依存するテーブルがある場合、これらにも対応するシャドウテーブルが必要です。これは、他のテーブルに変更が加えられた場合に監査証跡が孤立しないようにするためです。
シャドウテーブルは、その単純さとデータモデルの整合性に影響を与えないため便利です。監査証跡は別々のテーブルに残り、簡単に照会できます。欠点は、スキームが柔軟ではないことです。メインテーブルの構造の変更は、対応するシャドウテーブルに反映される必要があるため、モデルの保守が困難になります。さらに、監査ログを多数のテーブルに適用する必要がある場合は、シャドウテーブルの数も多くなり、スキーマの保守がさらに困難になります。
監査ログ用の汎用テーブル
3番目のオプションは、監査ログの汎用テーブルを作成することです。このようなテーブルを使用すると、スキーマ内の他のテーブルをログに記録できます。この手法に必要なテーブルは2つだけです：
以下を記録するヘッダーテーブル：
- 変更の日時。
- テーブルの名前。
- 影響を受ける行のキー。
- ユーザーデータ。
- 実行される操作のタイプ。
記録する詳細テーブル：
- 影響を受ける各フィールドの名前。
- 変更前のフィールド値。
- 変更後のフィールド値。 （これは、監査証跡の次のレコードまたは監査済みテーブルの対応するレコードを参照することで取得できるため、必要に応じて省略できます。）
一般的な監査ログテーブルを使用すると、監査できるデータの種類が制限されます。
この監査ログ戦略の利点は、上記の2つ以外のテーブルを必要としないことです。また、操作の影響を受けるフィールドのレコードのみが格納されます。これは、1つのフィールドのみが変更された場合に、テーブルの行全体を複製する必要がないことを意味します。さらに、この手法を使用すると、多数の追加テーブルでスキーマを乱雑にすることなく、必要な数のテーブルのログを保持できます。
欠点は、値を格納するフィールドが単一のタイプである必要があり、監査ログを生成するテーブルの最大のフィールドでさえも格納するのに十分な幅である必要があることです。多数の文字を受け入れるVARCHARタイプのフィールドを使用するのが最も一般的です。
たとえば、8,000文字のVARCHARフィールドが1つあるテーブルの監査ログを生成する必要がある場合、監査テーブルに値を格納するフィールドも8,000文字である必要があります。これは、そのフィールドに整数を1つだけ格納する場合でも当てはまります。一方、テーブルに画像、バイナリデータ、BLOBなどの複雑なデータ型のフィールドがある場合は、ログテーブルのVARCHARフィールドに格納できるように、その内容をシリアル化する必要があります。
データベース監査ログの設計を賢く選択する
監査ログを生成するためのいくつかの代替案を見てきましたが、どれも実際には最適ではありません。データベースのパフォーマンスに実質的に影響を与えず、データベースを過度に増大させず、トレーサビリティ要件を満たすことができるロギング戦略を採用する必要があります。いくつかのテーブルのログのみを保存する場合は、シャドウテーブルが最も便利なオプションです。任意のテーブルをログに記録する柔軟性が必要な場合は、一般的なログテーブルが最適な場合があります。
データベースの監査ログを保持する別の方法を発見しましたか？以下のコメントセクションで共有してください-あなたの仲間のデータベース設計者は非常に感謝するでしょう！