Qlik アプリ内で意図しない合成キーが勝手に生成されていませんか？

合成キー（Synthetic Key）は、Qlik が与えられたテーブル群に対して仕様通りに関連付けを行った結果です。複数のテーブル間で複数のフィールド名が重複している場合、連想エンジンは何らかの形でそれらを結びつけるしかありません。

合成キーが示している本当の問題

• 複数のテーブル間で複数の共通フィールドが存在する： Qlik はその組み合わせごとに $Syn テーブルを自動生成し、モデルビューアはそれらで埋め尽くされます。
• 同一テーブルに至る複数の結合ルートが存在する： これが循環参照（Circular Reference）であり、Qlik はループを遮断するためにテーブルを強制的に疎結合化します。
• 対症療法的な修正に追われる： リンクテーブル、ファクトの連結、QUALIFY、AS によるリネーム、AutoNumber による複合キー生成など、構造的なパッチが必要になります。
• 修正はそのアプリ内でしか通用しない： そのアプリの問題は解決できても、同じソースデータを利用する別のアプリではまたゼロから同じ修正を繰り返すことになります。

これらはすべて、「データが Qlik に届く前に解決されているべきだったキーの不備」を物語っています。

なぜその負担がアナリストに押し付けられるのか

• 各ソースシステムがたまたま使用していたフィールド名のまま、抽出データがアナリストに丸投げされました。
• どの CustomerID が真の顧客を表すのかを上流の誰も定義しなかったため、ロードスクリプト側で判断せざるを得ませんでした。
• Qlik 側でフィールド名を変更することはできても、その大元であるディメンションの標準化（コンフォーミング）はアナリストにはできません。

本来その処理が行われるべき場所

• テーブル間のリレーションシップの設計はウェアハウスの責務： Qlik 側でそれをやらせると、すべてのアプリのロードスクリプトで毎回同じパッチワークを繰り返すことになります。
• 1 箇所の中央基盤に集約すべき： データウェアハウスやデータハブ側で 1 度だけ解決し、すべてのアプリが統一されたスタースキーマを参照すべきです。
• 「DWH の改修は高額で時間がかかる」と思われるかもしれませんが： その見積もりは手作業でパイプラインを構築することを前提としています。専用の自動化プラットフォームを活用すれば、モデルからパイプラインが自動生成されるため、必要なコストと期間は劇的に圧縮されます。

完成したモデルが届いたときに変わること

Datavault Builder は、Snowflake、Databricks、SQL Server、Fabric、Oracle、PostgreSQL 上で、データボルトおよびディメンショナルレイヤーをネイティブに自動生成します。

• 適合ディメンション（Conformed Dimensions）： すべてのファクトで共有される単一の顧客テーブルと単一の顧客キーが提供されます。
• 明示的なサロゲートキー： 単一のフィールドで結合されるため、Qlik が合成キーを生成する余地がそもそも存在しなくなります。
• 明確な粒度のファクトテーブル： 手作業で保守していたリンクテーブルが不要になります。
• ロードスクリプトがシンプルに： スクリプト冒頭の複雑なリネーム処理が一切不要になり、完成テーブルからの単純な LOAD だけで完結します。
• 新しいアプリを作成する際も、過去のワークアラウンドをコピペするのではなく、共通モデルから安全に開始できます。

上流チームに何を要求すべきか

単に「Qlik が合成キーを勝手に作ってしまう」と伝えるのではなく、以下のように依頼してください：

「受注、請求、出荷の各テーブルがそれぞれ独自の顧客キーや日付キーを持っているため、アプリ側でリンクテーブルやリネームによる対症療法を強いられています。すべてのアプリが同じスタースキーマを直接読み込めるよう、サロゲートキーを持つ適合ディメンションをウェアハウス側で提供してもらえませんか？」

もし上流から「ディメンションの標準化には何ヶ月もかかる」と返答されたなら、まさにその構築障壁を自動化によって排除するのが Datavault Builder です。