分析の問題は、最終的にその下にあるデータにたどり着きます。重複した顧客レコード、レポート間で一致しない収益の数値、互いに矛盾するダッシュボードなどは、視覚化やクエリの問題ではありません。スキーマの問題であり、データの正規化が、チームがソースでそれらを修正する方法です。

以下では、データの正規化の仕組み、正規化されたスキーマの実際の構造、分析チームやウェアハウスチームにとって現実のトレードオフがどこに現れるかについて説明します。

主なポイント

• データの正規化は、各情報が正確に 1 か所に存在するよう、リレーショナルデータベースを構成します。これにより、重複する値や競合する値が排除されます。

• 分析チームは、最初に正規化されたコアエンティティテーブルを構築し、その上に非正規化されたレポートを重ねることで、パイプライン全体に正規化を適用できます。

• 最新の決済代行業者により、支払いデータをビジネスのウェアハウスに直接同期させることができます。これにより、サードパーティのコネクターを介して機密性の高い財務データをルーティングすることなく、構築元となる完全で最新のソースを、正規化されたスキーマに提供できます。

データの正規化とは何ですか？

データの正規化とは、各情報が正確に 1 か所に存在するよう、リレーショナルデータベースを編成するプロセスのことです。これは、行全体で同じ値を繰り返すのではなく、データを関連するテーブルに分割し、キーを使用してそれらをリンクさせることによって行います。

目的は一貫性を持たせることです。データ量が増加するにつれて、その構造上の規律が、信頼できるウェアハウスと常に監査が必要なウェアハウスを分ける要素となります。

なぜデータの正規化が分析の精度とガバナンスにとって重要なのですか？

正規化されていないデータは、データが増加するにつれて複合する種類に属する問題を生み出す可能性があります。

以下のそれぞれは、スキーマ自体の構造上の欠陥です。

• 更新の異常: これらは、同じ事実が複数の行に表示されるときに発生します。サブスクリプションプランの名前がすべての請求書の行に直接保存されている場合、プランの名前を変更することは、何千ものレコードを更新することを意味し、1 つでも見逃すと不一致が発生します。正規化されたスキーマでは、プラン名は plans (プラン) テーブルに存在し、請求書には plan_id のみが保持されます。

• 挿入の異常: これらは、関連性のない別のことを記録しなければ、何かを記録できない場合に発生します。顧客と注文のデータを一緒に保存するフラットテーブルでは、注文を行わないと新しい顧客を追加できません。つまり、営業チームがウェアハウスに見込み顧客の読み込みを開始した瞬間に、そのテーブルは機能しなくなります。

• 削除の異常: これらは、特定のレコードを削除した際に、重要で関連のないデータが意図せず削除される場合に発生します。フラットテーブルから顧客の最後の注文を削除すると、独立した保存場所がなかったために、連絡先情報も失われます。

主な正規形にはどのようなものがありますか？

正規形とは、データをどのように構成すべきかについて、厳格さが増していく一連のルールのことです。

データの正規化を利用するチームが優れたスキーマの意思決定を行うためには、第三正規形 (3NF) までの形式を理解する必要があります。データベースは 3NF を満たしている場合、「正規化されている」とよく表現されます。

• 第一正規形 (1NF): これには、すべての列がアトミック値 (リスト、カンマ区切りの文字列、1 つのフィールドにパックされた配列ではない値) を保持している必要があります。「shirt, pants, jacket (シャツ、パンツ、ジャケット)」を含む products (商品) 列は 1NF に失敗します。それぞれに product_id と product_name を持つ 3 つの行であれば合格します。

• 第二正規形 (2NF): これは、すべての非キー列が主キーの一部だけでなく、主キー全体に依存することを要求することで 1NF に基づいています。line items (ラインアイテム) テーブルのキーとして「(order_id, product_id)」を使用しながら、order_id にのみ依存する顧客の都市も保存している場合、それは部分的な依存であり、2NF 違反です。顧客の都市は orders (注文) テーブルに属します。

• 第三正規形 (3NF): これにより、推移的依存関係、つまりキー自体ではなく他の非キー列に依存する非キー列が排除されます。orders (注文) テーブルに zip_code (郵便番号) と city (都市) の両方が保存されていて、都市が注文ではなく郵便番号によって決定される場合、それらのフィールドは別の geography (地理) テーブルに属します。

• ボイス・コッド正規形 (BCNF): これは、重複する候補キーが関係するエッジケースを処理する、より厳格なバージョンの 3NF です。分析スキーマの場合、3NF に到達すれば十分です。

データの正規化は実際にどのように機能しますか？

正規化の実際の効果を理解する最も明確な方法は、問題のあるテーブルから始めてそれを修正することです。ここでは、正規化されていない注文テーブルの例と、正規化後にどうなるかの説明を示します。

正規化されていない注文テーブル

このテーブルには、すぐにわかる問題が 3 つあります。Ana のメールアドレスが 2 回表示されています。ある行でそれを更新すると、競合が発生します。商品の名前とカテゴリがすべての注文行で繰り返されているため、カテゴリを変更すると、そのカテゴリが含まれる過去のすべての注文を変更することになります。そして、注文を関連付けずに新しい顧客や商品を追加する方法はありません。

正規化後、3 つのテーブルが作成されます。

• Customers: customer_id、name、email
  
• Products: product_id、name、category
  
• Orders: order_id、customer_id、product_id、qty、unit_price
  

Ana のメールアドレスは 1 つだけ存在します。ヘッドセットのカテゴリも 1 つだけ存在します。Orders (注文) は ID で両方を参照します。SQL (Structured Query Language) の 2 回の結合による SELECT ステートメントを使用すると、共通の条件に基づいて複数のテーブルのデータを組み合わせることができます。これは、スケールしてもエラーが蓄積されないスキーマに対する小さく恒久的なコストです。

データの正規化に共通するトレードオフにはどのようなものがありますか？

正規化には重要なメリットがありますが、チームに現実的なコストをもたらす可能性もあります。

トレードオフは、次の 3 つの領域に分けられます。

• クエリの複雑さ: 各テーブルに正規化する関係はすべて、後で記述する結合になります。以前は 1 つのフラットテーブルから読み取ることができたレポートには 3 つの結合が必要になり、SQL で直接作業するアナリストチーム全体で認知のオーバーヘッドが蓄積します。

• 事前のモデリングの労力: 正規化されたスキーマを設計するには、エンティティ、その属性、およびそれらの間の関係を特定できるほどにドメインを理解している必要があります。リリースに追われているチームは多くの場合、これをスキップして、その時点では簡単に見えても後でコストが高くなるフラットな構造を構築します。

• 読み取りパフォーマンス: 非常に大規模なテーブルでは、結合はスキャンよりも遅くなります。最新のデータウェアハウス (BigQuery、Snowflake、Redshift など) には結合を適切に処理するクエリオプティマイザーがありますが、数十億行に対する分析ワークロードの純粋なクエリ速度では、非正規化構造の方が優れていることがよくあります。

分析チームやウェアハウスチームはどのようにワークフローにデータの正規化を適用していますか？

実際には、分析チームはパイプライン全体に正規化を階層化します。構造のさまざまなレベルは、それぞれ異なる目的や懸念事項に対応します。データの整合性は正規化されたコア層で処理され、クエリのパフォーマンスとアナリストの使いやすさはレポート層で処理されます。

具体的な方法は以下の通りです。

• ステージング層: 生データは、ソースからほぼそのままの状態でここに配置されます。この段階では、変換はほとんど、あるいはまったく行われません。目的は、データをそのままクエリ可能な状態でウェアハウスに取得することであり、モデル化することではありません。

• 正規化されたコア層: 変換ツールにより、顧客用、サブスク用、取引用の 1 つずつ、ステージング層から正規化されたエンティティテーブルが作成されます。これらは約 3NF のレベルにあり、ダウンストリームのモデルにとっての信頼できる唯一の情報源として機能します。

• レポート層: チームは正規化されたコアの上に、Tableau や Looker などのビジネスインテリジェンス (BI) ツールでの速度と使いやすさを重視して設計された、幅の広い非正規化テーブルを構築します。収益ダッシュボードモデルでは、BI ツールが直接読み取る 1 つの幅の広いファクトテーブルに、5 つの正規化テーブルを結合することがあります。

下流の正規化に向けた、クリーンでより信頼性の高いデータの確保を Stripe がサポートする仕組み

正規化されたスキーマの品質は、そこに供給されるデータの品質と完全性に完全に依存します。古い、または不完全な取引記録は照合のギャップを生み出す可能性があり、これはスキーマの設計をどれほど綿密に行っても修正できません。

決済代行業者が提供できる機能は次のとおりです:

• 同期: Stripe Data Pipeline は、Stripe データ (支払い、顧客、サブスクリプション、返金、不審請求の申請、入金など) を、中間にサードパーティのコネクターを挟まず、アプリケーションプログラミングインターフェイス (API) のレート制限なしに、データウェアハウスやクラウドストレージの宛先へ直接移動させます。

• 完全性: Stripe は、すべての Stripe データ、構築済みの財務レポート、および厳選されたデータセットを同期することにより、データの完全性を確保します。

• セキュリティ: サードパーティの抽出、変換、格納 (ETL) コネクターを経由して Stripe データをルーティングする場合、機密性の高い財務データを別のベンダーのインフラストラクチャーに送信することになります。Data Pipeline は転送を直接処理するため、仲介となるシステムが排除され、データセキュリティの審査対象からベンダーを 1 つ減らすことができます。

Data Pipeline は、完全な ETL プラットフォームの代わりになるものではありません。Stripe データを他の多数のソースのデータと組み合わせる場合は、引き続き変換ツールが必要です。しかし、このソリューションはサードパーティのコネクターよりも適切に Stripe データを同期するように特別に設計されており、財務データが確実、安全、かつ正確に同期されるようにします。