データ正規化手法の解説 | 完全ガイド | アドビ
View this page in English (US).Continue

データ正規化の手法を徹底解説

一貫性がなく冗長で、構造が不十分なデータは、チームに何時間もの手直しを強いるだけでなく、誰も信頼できない分析結果を生み出します。データ正規化は、こうした問題がレポート、モデル、またはカスタマーエクスペリエンスに影響を与える前に解消するための取り組みです。

この記事の概要:

データ正規化とは?

データ正規化とは、データの一貫性を確保し、冗長性を排除しながら、信頼性の高いクエリや分析をサポートする構造にデータを整理するプロセスです。分かりやすい例を挙げると、その重要性がよく理解できます。あるシステムではお客様の国がUS, 別のシステムではUnited States, さらに別のシステムではUSA,保存されている場合、値を単一の標準に正規化しない限り、システム間の結合で正確な結果を得ることはできません。このような不整合は特殊なケースではなく、複数のソースからデータを収集するあらゆる組織に共通する、デフォルトの状態です。

データ正規化いう用語は2つの異なる分野で使われており、どちらもデータチームにとって重要です。

  • リレーショナルデータベース正規化は、重複データを排除し、論理的な依存関係を適切に管理するためにテーブルを構造化します。データベーススキーマの設計や保守を担うすべての人に関連しており、「正規形」と呼ばれる段階的なルールセットに従います。
  • 数値正規化は、数値を共通の範囲や分布に再スケーリングします。機械学習モデルの構築や、クラスタリング・回帰など、スケールに敏感なアルゴリズムへのデータ投入を行うすべての人に関連します。

エンタープライズのデータ環境において、正規化は一度きりのデータベース設計タスクではありません。データの取り込み、変換、アクティベーションにわたる継続的な取り組みであり、データを生成・活用するすべてのチームに関わります。データエンジニアは正規化されたスキーマを設計し、マーケティングアナリストは正確なセグメント数を得るために正規化されたデータを活用し、データサイエンティストはモデルのトレーニング前に数値正規化を適用します。このコンセプトは現代のデータスタックのあらゆるレイヤーで重要な役割を果たします。だからこそ、お客様のデータや業務データを扱うすべての人にとって、両分野のデータ正規化手法を理解することは不可欠なのです。

主なデータ正規化の手法とは?

主なデータ正規化の手法は以下のとおりです:

リレーショナル正規化:正規形

リレーショナル正規化の手法は、正規形と呼ばれる段階的なプロセスで体系化されています。各正規形は前の段階を土台として、特定の構造的問題に対処します。

  • 第1正規形 (1NF)は、各列が分割不可能な単一の値のみを格納し、各行が一意であることを求めます。例えば、カンマ区切りで複数の値を持つ 電話番号 列は1NFに違反しています。解決策は、それらの値を個別の行または関連テーブルに分割することです。
  • 第2正規形 (2NF)は、すべての非キー列が主キー全体に依存することを求め、主キーの一部への部分依存を排除します。これにより、複合キーを持つテーブルで発生する更新異常を防ぐことができます。典型例として、受注明細テーブルで商品説明が注文IDと商品IDの複合キー全体ではなく、商品IDのみに依存しているケースが挙げられます。この場合、商品説明を独立した商品テーブルに移動することで違反を解消できます。
  • 第3正規形 (3NF)は、非キー列が他の非キー列に依存することを禁じ、推移的依存を排除します。例えば、顧客テーブルに郵便番号と市区町村名の両方を格納している場合、市区町村名は郵便番号から導出できるため、市区町村名だけを更新して郵便番号を変更しないとデータが矛盾した状態になります。郵便番号と市区町村の対応関係を専用テーブルに分離することで、このリスクを排除することができます。
  • ボイス・コッド正規形 (BCNF)は、複数の重複する候補キーを持つテーブルに適用される、3NFより厳格な正規形です。適用が必要なケースはまれですが、3NFでは対処できない例外的なケースを解決することができます。

数値正規化:スケーリング手法

数値正規化の手法は、数値特徴量を再スケーリングすることで、値の大きさの違いがモデルの出力結果を歪めないようにします。

  • Min-maxスケーリングは、すべての値を固定範囲(通常0から1)に圧縮します。既知の母集団における年齢など、特徴量の分布が既知で有界な場合に有効です。ただし、極端な外れ値が1つでもあると、残りの値が狭い範囲に押し込められ、特徴量の識別力が低下するリスクがあります。
  • Zスコア標準化は、特徴量の平均が0、標準偏差が1になるように値を変換します。データに外れ値が含まれる場合や、ロジスティック回帰・主成分分析など正規分布を前提とするアルゴリズムに適しています。ただし、出力値が元の単位ではなくなるため、ビジネス部門の担当者にとって結果の解釈が難しくなる点には注意が必要です。
  • 対数スケーリングは、対数変換を適用して大きな値の範囲を圧縮します。数桁にわたる売上やページビューのデータに特に有効です。ただし、ゼロや負の値には、変換前に定数を加えるなどの調整を行わずに直接適用することはできません。
  • クリッピングは、上限または下限を厳密に設定し、その範囲外の値を制限することで、行全体を削除せずに極端な外れ値がモデルを歪めるのを防ぎます。ただし、閾値を厳しく設定しすぎると、真のシグナルを失うリスクがあります。

手法選択ガイド

手法
カテゴリー
対象
注意点
1NF / 2NF / 3NF
リレーショナル
データベーススキーマ設計、冗長性の削減
過度な正規化は、クエリ時に多数のテーブル結合が必要になり、コストが増大することがある
BCNF
リレーショナル
複数の重複した候補キーを持つスキーマ
テーブル分割を強制し、アプリケーションロジックが複雑になることがある
Min-maxスケーリング
数値
値の範囲が既知の有界な特徴量 (年齢やスコアなど)
外れ値の影響を受けやすく、1つの極端な値が他の値を圧縮してしまう
Zスコア標準化
数値
正規分布する特徴量、ゼロ平均を前提とするアルゴリズム
解釈可能性が低下し、出力値は元の単位ではなくなる
対数スケーリング
数値
大きく偏った分布 (売上、カウントなど)
調整なしにゼロまたは負の値に適用することはできない
クリッピング
数値
抑制すべき極端な外れ値が既知のデータセット
閾値を厳しく設定しすぎると、真のシグナルが失われる

データ品質においてデータ正規化が重要な理由

正規化されていないリレーショナルデータは、知らぬ間にレコードを破損させる3種類の異常を引き起こします。

  • 更新異常。同じ情報が複数の行に保存されます。ある行でお客様のメールアドレスを更新しても他の行に反映されなければ、データベースは矛盾した状態に陥ります。このテーブルからメールリストを取得するマーケティングチームは古いアドレスにメッセージを送信してしまい、重複排除ロジックは同一のお客様を別人として処理することになります。
  • 挿入異常。新しいレコードを追加する際に、本来必要でないはずのデータが求められます。例えば、商品情報を注文行にのみ保存するスキーマでは、売上が発生するまで新商品を追加することができず、カタログの更新が遅れます。
  • 削除異常。行を削除すると、同じ行に保存されている無関係な情報も意図せず削除されます。例えば、お客様の最後の注文を削除した際に、連絡先情報も同一テーブルに保存されている場合、その情報まで消えてしまうことがあります。

こうした異常はそれぞれ、後続のレポートにエラーを引き起こします。しかし、その構造的な根本原因を突き止めるのは容易ではありません。行レベルでは問題なく見えるデータが、テーブルレベルでは矛盾していることがあるためです。

機械学習のpipelineでは、正規化されていない数値特徴量が別の種類の問題を引き起こします。k近傍法などの距離ベースのアルゴリズムや勾配降下法ベースの最適化処理は、0から1の値を持つ特徴量よりも、数千単位の値を持つ特徴量を大幅に重要視します。両者が同等の予測情報を持つ場合でも同様です。事業上のコストは、訓練データでは高精度を示しながら、本番環境では精度が低下するモデルの生成です。予測を左右しているのが特徴量の本来の情報価値ではなく、そのスケールだからです。

データクレンジングとデータ検証は、正規化と密接に関連する手法です。クレンジングは不正確なレコードを削除または修正し、検証はデータがpipelineに入る前に期待されるフォーマットや制約に準拠しているかを確認します。正規化は、データがすでにクリーンかつ有効であることを前提としています。不正確なデータに正規化を適用しても、信頼性の高いデータセットは生まれず、一貫した構造を持つ混乱が生じるだけです。正規化の前にデータクレンジングの手法をスキップしたチームは、後続のレポートで整然としたフォーマットの列にあり得ない値が表示されて初めて問題に気づくことがほとんどです。

複数のチャネルにまたがるお客様データを管理する組織では、この問題がより複雑な形で現れます。CRM、ECプラットフォーム、モバイルアプリ、サポートシステムなど複数のソースからお客様の属性データが届く際、それぞれが異なるフィールド名、値のフォーマット、データ型を使用しているのが一般的です。取り込みレイヤーで正規化を行わなければ、統合顧客プロファイルの信頼性が損なわれ、重複レコード、セグメントの漏れ、パーソナライゼーションのエラーが生じます。

データの正規化は、より広範なデータpipelineにどう組み込まれるか

正規化は、標準的なextract-transform-load (ETL)またはextract-load-transform (ELT) pipelineのデータ変換ステージに位置します。これは、生データが取り込まれた後、分析や活用のために宛先システムに書き込まれる前の段階です。この順序が重要です。フォーマット変換やフィールドマッピングなどのデータ変換タスクは通常、正規化の前に実行されます。一方、データエンリッチメント (サードパーティの属性の追加や派生情報の生成) は正規化の後に続くのが一般的です。クリーンで一貫性のあるデータを基盤にすることで、エンリッチメントの信頼性が高まります。

データの標準化は、正規化と密接に関連しながらも、明確に異なるプロセスです。標準化とは、すべての日付をISO 8601形式に統一するなど、共通の語彙やフォーマットに値を揃えること、あるいは国名をISO 3166コードにマッピングすることを指します。正規化はさらに踏み込んで、テーブル間のデータ構造を再編したり、数値を再スケーリングしたりします。この2つを混同すると、誤った対処につながります。本来の問題がスキーマの構造にあるにもかかわらずフィールド形式を標準化したり、値のエンコードが不整合であるにもかかわらずテーブルを正規化したりといったケースがその例です。データ正規化と標準化の詳細な比較については、パイプライン設計に着手する前にその違いをしっかり理解しておくことをお勧めします。

実際には、パイプラインの各ステージ間の境界は流動的です。成熟したデータチームは、正規化をプロジェクト開始時に一度行うスキーマ設計の決定としてではなく、継続的なデータ品質プログラム一環として捉えています。プラットフォームに新しいデータソースが追加されるたびに、正規化に関する判断が求められます。既存スキーマへのフィールドのマッピング方法、値の競合への対処方法、そしてダウンストリームでの利用前に数値特徴量の再スケーリングが必要かどうかといった問題が生じます。

データモデリングは、正規化が機能するための構造的な設計図を提供します。適切に設計されたデータモデルは、どのエンティティが存在するか、それらがどのように関連するか、各テーブルに適した正規形はどれかを定義します。こうしたデータモデリングの手法が、正規化作業の量と、その結果として生じるクエリ層の複雑さを左右します。モデリングのステップを省略したチームは、新しい要件が浮上するたびにテーブルを繰り返し再正規化することになりがちです。分析用の出力先システム活性化のための書き込みには十分な事前計画が欠かせないのは、まさにそのためです。

自社に合った正規化アプローチの選び方

リレーショナル正規化と数値正規化は、どちらかを選ぶという二者択一の問題ではありません。エンタープライズのデータ環境では、多くの場合、両方が必要です。重要なのは、どの場面でどの手法を、どの深さまで適用するかという判断です。

トランザクションシステムのデータベーススキーマ設計を主な課題としている場合、CRM、受注管理プラットフォーム、お客様データストアなどが該当しますが、リレーショナル正規化を第3正規形(3NF)まで適用することを優先してください。これにより、ストレージコストを削減し、更新時の異常を防ぎ、要件の変化にも柔軟に対応できるスキーマを維持できます。結果的にJOINの複雑さによってクエリパフォーマンスが低下する場合は、正規化の基盤を捨てるのではなく、読み取り負荷の高いテーブルに限定して選択的な非正規化を検討してください。

機械学習モデルや統計分析のためのデータ準備が主な目的であれば、 数値の正規化を優先してください。特徴量の範囲が既知かつ有界であり、アルゴリズムが特定の分布を前提としない場合は、min-max scalingを選択してください。特徴量に外れ値が含まれる可能性がある場合、またはアルゴリズムが平均ゼロの入力を想定している場合は、Z-score標準化を選択してください。分布が右に大きく偏っている特徴量には、他の手法を検討する前に対数変換を適用してください。

複数のソースシステムからお客様データを管理するケースは、 小売業、金融サービス、デジタルメディアでよく見られます。この場合、正規化の課題は主にソース間のスキーマの整合性と値の一貫性にあります。データ取り込み時に共通データモデルを適用する顧客データプラットフォームが、運用上重要な意味を持つのはまさにこのような場面です。Adobe Experience Platformは、エクスペリエンスデータモデル(XDM)という標準化されたスキーマフレームワークを適用することで、このユースケースに対応しています。XDMは、異なるソースから取り込まれたデータを統合顧客プロファイルへと正規化し、データエンジニアリングチームが手動で担う正規化作業を削減することができます。エンタープライズプラットフォームを評価するチームは、データ取り込み時にスキーマの正規化が適用されるのか、後続の処理側に委ねられるのかを確認する必要があります。

正規化戦略を確定する前に、 次の実践的な評価チェックリストを確認してください:

  1. データの主な利用先を特定してください。 レポートツール、機械学習(ML)モデル、データ活用システムはそれぞれ、結合処理の複雑さへの許容度やスケールへの感度が異なります。
  2. 正規化戦略を設計する前に、既存のスキーマに含まれる3種類の異常 ——更新、挿入、削除——を確認してください。どの異常が存在するかが、必要な正規形を示します。
  3. 数値の特徴量の分布形状と外れ値の密度を把握した上で、 スケーリング手法を選択してください。
  4. 上流工程でデータクレンジングとデータ検証が適切に実施されているかを確認してください。 品質の低いデータに正規化を適用しても、根本的なデータ品質の問題は解決されません。
  5. 法規制およびプライバシー要件を考慮してください。 特に複数のソースからのお客様データを統合プロファイルへと統合する際は、正規化の前またはそれと並行して、データ匿名化の手法を適用する必要がある場合があります。

よくある質問

リレーショナルスキーマの正規化、数値特徴量のスケーリング、数十のソースシステムからのお客様データの統合など、適切なプラットフォームを活用することで、数か月を要する手作業のデータエンジニアリングを、ガバナンスの行き届いた再現性のあるプロセスへと変えることができます。Adobe Experience Platformがエクスペリエンスデータモデルを通じてスキーマレベルの正規化を行い、エンタープライズ規模で統合された顧客プロファイルを作成する方法については、Adobe Experience Platformご覧ください。

関連トピックス

アドビがお客様のビジネスにどのように役立つのかをご案内します

使い始める