正規化されていないリレーショナルデータは、知らぬ間にレコードを破損させる3種類の異常を引き起こします。
- 同じ情報が複数の行に保存されます。ある行でお客様のメールアドレスを更新しても他の行に反映されなければ、データベースは矛盾した状態に陥ります。このテーブルからメールリストを取得するマーケティングチームは古いアドレスにメッセージを送信してしまい、重複排除ロジックは同一のお客様を別人として処理することになります。
- 新しいレコードを追加する際に、本来必要でないはずのデータが求められます。例えば、商品情報を注文行にのみ保存するスキーマでは、売上が発生するまで新商品を追加することができず、カタログの更新が遅れます。
- 行を削除すると、同じ行に保存されている無関係な情報も意図せず削除されます。例えば、お客様の最後の注文を削除した際に、連絡先情報も同一テーブルに保存されている場合、その情報まで消えてしまうことがあります。
こうした異常はそれぞれ、後続のレポートにエラーを引き起こします。しかし、その構造的な根本原因を突き止めるのは容易ではありません。行レベルでは問題なく見えるデータが、テーブルレベルでは矛盾していることがあるためです。
機械学習のpipelineでは、正規化されていない数値特徴量が別の種類の問題を引き起こします。k近傍法などの距離ベースのアルゴリズムや勾配降下法ベースの最適化処理は、0から1の値を持つ特徴量よりも、数千単位の値を持つ特徴量を大幅に重要視します。両者が同等の予測情報を持つ場合でも同様です。事業上のコストは、訓練データでは高精度を示しながら、本番環境では精度が低下するモデルの生成です。予測を左右しているのが特徴量の本来の情報価値ではなく、そのスケールだからです。
データクレンジングとデータ検証は、正規化と密接に関連する手法です。クレンジングは不正確なレコードを削除または修正し、検証はデータがpipelineに入る前に期待されるフォーマットや制約に準拠しているかを確認します。正規化は、データがすでにクリーンかつ有効であることを前提としています。不正確なデータに正規化を適用しても、信頼性の高いデータセットは生まれず、一貫した構造を持つ混乱が生じるだけです。正規化の前にデータクレンジングの手法をスキップしたチームは、後続のレポートで整然としたフォーマットの列にあり得ない値が表示されて初めて問題に気づくことがほとんどです。
複数のチャネルにまたがるお客様データを管理する組織では、この問題がより複雑な形で現れます。CRM、ECプラットフォーム、モバイルアプリ、サポートシステムなど複数のソースからお客様の属性データが届く際、それぞれが異なるフィールド名、値のフォーマット、データ型を使用しているのが一般的です。取り込みレイヤーで正規化を行わなければ、統合顧客プロファイルの信頼性が損なわれ、重複レコード、セグメントの漏れ、パーソナライゼーションのエラーが生じます。