新しいレコード、更新、削除によって継続的に更新されるデータベースを扱う場合、ロード時間を最小限に抑え、Qlik Sense データ モデルを最新の状態に保つために、効率的なデータ ロード戦略が必要です。
手順の説明:
* QVD から既存のデータをロードします。
* このステップでは、以前のセッションから既にロードされ処理されたデータを取得します。これは、新しいレコードまたは更新されたレコードが追加されるベースとして機能します。
* データベースから新規データと更新されたデータをロードします。QVD からロードされたテーブルと連結します。
* 次のステップでは、データベースから新規レコードと更新されたレコードのみをロードします。これにより、ロードされるデータの量が最小限に抑えられ、変更点のみに焦点が当てられます。
* 新しいレコードと更新されたレコードは QVD の既存のデータと連結され、関連するすべての情報を含む結合されたデータセットが作成されます。
* 削除された行用に別のテーブルを作成し、WHERE NOT EXISTS を使用してこれらのレコードを削除します。
* 削除を処理するために別のテーブルが作成されます。WHERE NOT EXISTS 句は、ソース データベースで削除されたレコードを識別して結合されたデータセットから削除するために使用されます。

多数の同一の計算式を共有する複数の Qlik Sense アプリケーション (Sales、Finance、Operations) を開発する場合、冗長性を回避し、変更にかかる時間を節約し、資産の再利用性を高めるために、一元化された再利用可能なスクリプトを用意することが重要です。
Qlik Sense でこれらの目標を達成するための最適な方法は、Include スクリプト関数を使用することです。この関数を使用すると、データ アーキテクトはファイル サーバーに保存されているスクリプト ファイルを参照できます。Include 関数は、Include ステートメントが呼び出される時点で、外部スクリプト ファイルの内容を Qlik Sense スクリプトに挿入します。つまり、3 つのアプリ (Sales、Finance、Operations) すべてにこの共通スクリプトを含めることができ、スクリプトに加えられた更新は、それを含むすべてのアプリに自動的に適用されます。
この方法は、次の理由により、保守性の高いソリューションを提供します。
* 重複スクリプトなし:共有ロジックは 1 つのファイルで維持され、冗長性が排除されます。
* 変更の容易さ: スクリプトに加えられた変更は、そのスクリプトを含むすべてのアプリケーションに反映されます。
* 再利用可能なアセット:スクリプトはさまざまなアプリケーション間で再利用できるため、効率性と一貫性が向上します。

提供されているスクリプトでは、Table_A と Table_B の 2 つのテーブルがインラインでロードされています。スクリプトは Join 関数を使用して、共通フィールド Field_1 に基づいて Table_B と Table_A を結合します。結合操作の仕組みは次のとおりです。
* Table_A には、最初、Field_1 の値が 01、01、02 である 3 つのレコードが含まれています。
* Table_Bには、Field_1の値が01と03である2つのレコードが含まれています。
Join(Table_A) が実行されると、Qlik Sense はデフォルトで内部結合を実行します。つまり、両方のテーブルで Field_1 が一致する行を Table_B から Table_A に結合します。結果は次のようになります。
* Field_1 = 01 の場合、Table_A に 2 つの一致があり、Table_B に 1 つの一致があります。この結果、結合テーブルには 2 つのレコードが作成され、Table_A の各一致に対して Table_B の Field_4 と Field_5 の値が繰り返されます。
* Field_1 = 02 の場合、Table_B に対応する Field_1 = 02 がないため、このレコードの Field_4 と Field_5 の値は null になります。
* Field_1 = 03 の場合、Table_A には対応する Field_1 = 03 がないため、Field_1 = 03 の Table_B のレコードは最終的な結合テーブルには含まれません。
したがって、正しい出力は次のようになります。
* フィールド_1 = 01、フィールド_2 = AB、フィールド_3 = 10、フィールド_4 = 30%、フィールド_5 = 500
* フィールド_1 = 01、フィールド_2 = AC、フィールド_3 = 50、フィールド_4 = 30%、フィールド_5 = 500
* フィールド_1 = 02、フィールド_2 = AD、フィールド_3 = 75、フィールド_4 = null、フィールド_5 = null

このシナリオでは、公開されたアプリのユーザーが不完全な視覚化を報告していますが、データ アーキテクトはエラーを再現できません。この問題は 1 つのチームにのみ影響するため、問題はその特定のチームに対してデータが制限またはフィルター処理される方法に関連していると考えられます。
* セクション アクセス: これは、アプリ内の特定のデータへのユーザー アクセスを制御する Qlik Sense のセキュリティ機能です。セクション アクセスが誤って構成されていると、意図したよりも多くのレコードへのアクセスが制限され、特定のユーザーまたはチームの視覚化が不完全になる可能性があります。
* レコードの制限が多すぎる: セクション アクセスの制限が厳しすぎると、影響を受けるユーザーが利用できるデータが制限され、視覚化に不完全な情報が表示される可能性があります。これにより、フル アクセス権を持つ可能性のあるデータ アーキテクトが問題を再現できない理由が説明できます。

提供されたデータ モデルでは、特定の種類の経時的分析で期待されるデータが表示されないという問題があります。この問題は、多くの場合、Orders テーブルと MasterCalendar テーブル間の OrderDate フィールドのデータ形式の不一致によって発生します。
* オプション A:DatefFloor(OrderDate)) は最も近い日付境界に切り捨てますが、問題が異なる日付と時刻の形式に関連している場合は、根本的な原因に対処できない可能性があります。
* オプション B:TimeStamp#(OrderDate, 'M/D/YYYY hh.mm.ff') は、日付がタイムスタンプとして正しく解釈されることを保証しますが、日付形式の潜在的な不一致を直接解決するものではありません。
* オプション C:TimeStamp(OrderDate) は日付と時刻の両方を保持しますが、MasterCalendar が日付のみを扱っている場合は不一致が発生する可能性があります。
* オプション D:Date(OrderDate) は、OrderDate を書式設定して、日付部分のみを表示します (時刻部分は削除)。この関数は、タイムスタンプを日付のみに変換することで、Orders テーブルと MasterCalendar テーブル間で日付値の一貫性を確保します。これは、日付ベースの分析で一貫性を確保するための最も簡単で効果的な方法です。
Qlik Sense では、日付とタイムスタンプは二重値 (テキストと数値の両方) として保存されるため、不一致があると分析が不完全になったり、正しくなくなる可能性があります。Orders テーブルと MasterCalendar テーブルの両方で Date(OrderDate) を使用すると、分析の日付値が一定になり、前述の問題が解決されます。