Text Comment Dimension (コメントディメンション) は、ファクトイベントに付随する長文テキスト属性 (ユーザーレビューやアンケートの回答等) を専用のディメンションテーブルに切り出し、[[ファクトテーブル]]から FK で参照する設計パターンである。 長文テキスト属性は、メジャーにも通常のディメンション属性にも当てはまらない。この扱いにくさに対し、[[Ralph Kimball]] が Text Comments テクニックを定式化し、[[ディメンショナルモデリング]] の設計テクニックの 1 つに位置づけている。 > [!info] > 原典は『[[The Data Warehouse Toolkit]]』(3rd Edition) 9 章 "Human Resources Management"。Kimball Group の [Text Comments](https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/text-comment/) テクニックとして解説されている。 > [!note] > ここでの「text comment」は、人間が書いた文章 (レビュー / 自由記述回答) だけでなく、SQL クエリのような長文テキストも含めて解釈している。これは両者に「ファクトイベントに付随する長文テキストで、ファクトにもディメンションにも分類できない」という共通点があるためである。 ## 構造 注文トランザクションの例では、注文時の自由入力コメント `order_comment` を `dim_order_comment` に切り出し、`fct_order` から `order_comment_key` で参照する。 ```mermaid erDiagram dim_date ||--|{ fct_order : order_date_key dim_user ||--|{ fct_order : user_key dim_product ||--|{ fct_order : product_key fct_order }|--|| dim_order_profile : order_profile_key fct_order }|--|| dim_order_comment : order_comment_key dim_order_comment["dim_order_comment [CV]"] { order_comment_key int64 "[SK]" order_comment string "[GD]" } ``` > [!warning] > 注文データに長文テキスト属性 (`order_comment` / `gift_message` など) が複数あると、それぞれを別の Text Comment Dimension に切り出すうちにファクトから多数の FK が伸びる [[Centipede Fact Table]] に陥る。 > > この場合は、トランザクション粒度のディメンション (例: `dim_order_header`) を 1 つ作り、複数の長文をまとめて配置する。 > > ただしトランザクション粒度はディメンションの圧縮が効かない最終手段である。長文が事実上ユニークで行数がファクトと変わらない場合にのみ許容され、最初からこの粒度で設計してはならない。 ## 命名規約 Text Comment Dimension は概念的に親ファクトテーブルに付随するディメンションであり、独立したビジネスエンティティではない。命名は `dim_{{ FACT_ENTITY }}_{{ ROLE }}` の形に揃えると、テーブル名から所属するファクトテーブルと役割が両方読み取れる。 - ✅ 推奨: `dim_order_comment` (親ファクトテーブルと役割の両方が読み取れる) - ❌ 非推奨: `dim_comment` (役割しか分からず、親ファクトテーブルが分からない) - ❌ 非推奨: `dim_order` (注文ディメンション全体と読めてしまい、役割が分からない) ## 関連ノート - **[深掘り]** [[長文テキスト属性は Text Comment Dimension に切り出す]]: この概念を使うべき理由と、アンチパターンに対する優位を示す中心ノート