マスタデータとトランザクションデータ。データの性質による分類と設計の基本
システム設計において、まず整理すべきはデータの性質です。データベース内のデータは、大きく「マスタデータ」と「トランザクションデータ」の2種類に分類されます。
この2つを明確に区別して設計することで、システムは変更に強く、整合性の取れたものになります。
マスタデータ（静的データ）： 業務の土台
マスタデータとは、業務を遂行する上で「参照」される、比較的変化の少ない基礎情報です。
- 種類：顧客マスタ、商品マスタ、社員マスタなど。
- 特徴：一度登録されると長期間利用され、頻繁には更新されません。
- 設計上の重要性：マスタデータに一意なIDを付与し、他のデータから参照される「基準」とします。
マスタデータはさらに以下のように分類されます。
| 分類 | 説明 | 例 |
|---|---|---|
| ビジネスエンティティ | 業務の主要な登場人物・対象物 | 顧客、商品、社員、取引先 |
| コードマスタ | 区分や分類を管理する補助テーブル | 都道府県コード、商品カテゴリ、支払方法 |
| 組織マスタ | 会社の内部構造 | 部署、拠点、役職 |
特にコードマスタは軽視されがちですが、「東京」「東京都」「tokyo」のような表記ゆれを防ぎ、集計の信頼性を高める上で非常に重要な役割を果たします。
トランザクションデータ（動的データ）： 業務の記録
トランザクションデータとは、日々の業務で発生する「出来事」を記録したデータです。
- 種類：受注データ、入金履歴、出荷記録など。
- 特徴：時間の経過とともに継続的に蓄積されます。
- マスタとの関係：トランザクションデータは、必ず「どの顧客（マスタ）が、どの商品（マスタ）を扱ったか」という形で、マスタデータを参照して作成されます。
技術的な補足：機能としての「トランザクション」 本記事ではデータの分類としての意味で解説していますが、データベースの専門用語としての「トランザクション」には、複数の処理を一つのまとまりとして扱い、失敗時にすべてを元の状態に戻す（整合性を保つ）ための「機能」という意味合いもあります。
設計不備が招く「データ不整合」のリスク
もしマスタとトランザクションを分けずに、トランザクションデータの中に「直接」顧客名や商品価格を書き込んでしまうと、以下の問題が発生します。
- 情報の変更に対応できない：商品価格を改定した際、過去の全トランザクションを書き換えるか、集計時に矛盾を受け入れる必要が出てきます。
- データの冗長性：同じ情報を何度も保存するため、ストレージを無駄に消費し、更新ミスが発生しやすくなります。
「その時点の値」を保持するスナップショット設計
一方で、トランザクションデータが「当時の値」を保持すべきケースも存在します。
受注明細に商品価格を記録する場合、マスタの価格を参照するのではなく、 受注時点の価格を明細行にコピーして保存する のが正しい設計です。なぜなら、後日価格改定が行われても「その注文を受けた時点の価格」は変わらないからです。
これは「非正規化」に見えますが、「時点の記録」という業務上の要求に応えるための意図的な設計です。マスタを参照するか、値をコピーするかの判断は、「この値は変化したとき、過去の記録に影響を与えてよいか」という問いで切り分けます。
業務整理の視点： 「状態」か「履歴」か
自社のデータを整理する際は、その項目がどちらに属するかを判断してください。
- 状態（マスタ）：現在の名称、現在の価格、所属部署など。「今どうなっているか」を表す。
- 履歴（トランザクション）：いつ発生したか、その瞬間の数量、その瞬間の金額など。「あのとき何が起きたか」を記録する。
この問いを繰り返すことで、業務で扱うほぼすべてのデータをどちらかに分類できます。判断が難しい場合は、「複数の時点で異なる値を持ちうるか」を確認します。住所は変わりうる（マスタで管理し、変更を追う）、注文単価はその注文時点で確定する（トランザクションに記録）、という整理が基本です。
まとめ：正確な集計は「正しい切り分け」から
システム化の要件定義において、マスタデータの範囲を確定させることは、ビジネスルールの確定そのものです。
「顧客とは誰か？」「商品はどの単位で管理するか？」といった定義（マスタ設計）を丁寧に行うことで、日々の業務記録（トランザクション）が、経営判断に耐えうる精緻なデータへと昇華されます。マスタとトランザクションの責務を明確に分離することが、将来にわたってデータ資産の価値を守る最初の一歩です。