第3正規形（3NF）とData Vault：恐れる必要はまったくない

Datavault Builderの導入を検討されている方から、時折このような興味深い質問をいただきます。
「Datavault BuilderというDWH自動化ツールは、第3正規形（3NF）をサポートしていますか？」

私たちの回答は、明確に 「Yes」 です。

私たちはDWHの永続化コア層として3NFを採用しないことを意図的に選択しました。データをキー（ハブ）、関係性（リンク）、コンテキスト・属性（サテライト）という個別の役割に分離することこそが、従来の3NFデータウェアハウスが抱えていた数多くの課題を根本解決すると確信しているからです。

異なるビジネス領域から独立してモデリングを開始しシームレスに結合できる柔軟性、仕様変更時における極めて低い保守コスト、各ロードプロセスの完全な独立性など、これらはData Vaultがもたらす無数のメリットのほんの一部に過ぎません。

では、なぜ3NFが必要なのかと尋ねると、その回答の多くは「既存のデータ利用者やアナリストが3NF構造のDWHに慣れ親しんでおり、Data Vaultモデルを直接クエリできるか不安だから」というものです。

インターフェース層（マート層）の活用

ここで声を大にして強調したい原則があります。「誰もDWHのコア層を直接クエリすべきではない」 ということです。これはインモン型のエンタープライズDWHでも当然の原則でしたが、Data Vaultコアにおいてはなおさら徹底されるべきです。

分析やレポーティングを行うには、クエリ用に最適化された「インターフェース層（情報マート）」を必ず設ける必要があります。

多くの最新BIツールがディメンショナルモデル（スタースキーマ）に最適化されているため、インターフェースはディメンショナル形式で構築されるのが一般的です。しかし、Data Vaultは3NFよりもさらに高い正規化レベル（6NF相当）でデータを保持しているため、ディメンショナルモデルだけでなく、3NF形式のインターフェース層を提供することも極めて容易なのです。

3NFレイヤーを自動生成する方法

Data Vaultのモデリング段階で期待されるカーディナリティ（多重度：1対多、多対多など）を定義していれば、Data Vaultモデルを3NFインターフェースへと決定論的（確実）に自動変換するためのすべての情報が既に揃っています：

• ハブのビジネスキー（またはハッシュキー）が主キー（PK）になる
• 「多対1」または「1対1」で接続された相手先ハブのキーが外部キー（FK）になる
• サテライト内の全フィールドが属性カラムになる

これを「現在時点（As-of-Now）」または「過去特定時点（As-of-Then）」のビューとして作成するだけです。ハブのリストを走査し、手作業によるSQL記述なしにハブごとに3NFビューを自動生成できます。

Data Vault側に新しいサテライト属性を追加した場合でも、該当ハブのインターフェースビューを再生成するだけで即座に反映されます。構築もメンテナンスも極めてシンプルです。

Datavault Builderはすべての機能に対してREST APIを提供しているため、独自の命名規則（外部キーに FK_ プレフィックスを付けるか、キー名そのままにするか等）に従ったインターフェースビューを完全自動で生成できます。利用するデータアナリストから見れば、背後でデータがData Vault形式で永続化されていることを意識する必要すらありません。

結論：Data Vaultと3NFの共存

私たちの結論はこうです：
「データの提示（プレゼンテーション）には3NFを全面的にサポートする。ただし、データの格納（ストレージ）には常にData Vaultを使用する。」

これこそが、既存の分析手法に慣れ親しんだデータ消費者を安心させ、同時にモダンで俊敏なデータアーキテクチャを確立するための最善のメッセージです。

私たちがスーパーマーケットで買い物をする際、店舗のバックヤード（倉庫）の整理方法まで気にする人はいません。整然と商品が陳列された棚（インターフェース）があれば十分なのです。