概要

Chains アーティファクトのベストプラクティスに沿って、Wdata アーティファクト（テーブルやクエリなど）の一貫した命名規則を実装し、ナビゲーションと管理を容易にすることが望ましい。ここに示したガイドラインは、最初から一貫して成果物を整理するためのものである。

ファクト テーブルおよびディメンション テーブル

ファクト・テーブルには通常、時間の経過とともに蓄積されるデータが格納され、ディメンション・テーブルには、データに追加のコンテキストを提供する補足的なデータセットが格納されます。両方のタイプのテーブルに名前を付ける場合は、以下のベスト・プラクティスを考慮すること：

• 命名規則： ファクト・テーブルとディメンション・テーブルの両方の目的と内容を明確に示す一貫した命名規則を使用する。
• 説明的な名前： 表が容易に識別でき、理解できるように、両方の表に説明的な名前を付ける。
• ソース・システム： データの送信元システムを名前に含める。

例：

• ファクト テーブル： 試算表 - Workday

  説明： Workday から取得した Avikro Financial の試算表トランザクションデータを格納。

• ディメンションテーブル： Chart of Accounts - Workday

  説明： Workday から取得した Avikro Financial の勘定表データを格納します。

• ディメンションテーブル： Profit Centers - SAP

  説明： SAPから取得したアビクロ・フィナンシャルのプロフィットセンター情報を格納。

• ディメンションテーブル： Exchange Rates - Central Bank API

  説明： 中央銀行 API から取得した Avikro Financial の通貨換算レートを提供します。

このテンプレートは、ファクト・テーブルとディメンジョン・テーブルの両方について、命名規則の一貫性、説明の明 確さ、およびソース・システムの正確な識別を保証します。

Wdataクエリー

クエリの命名規則を定義する際には、標準的なアプローチを維持することが不可欠です。これにより、ユーザーは特定のデータを検索するための正しいクエリを簡単に特定できる。

• 命名規則： クエリの目的と内容を明確に定義する一貫した命名規則を使用する。
• 説明的な名前： 識別と理解を容易にするために、クエリに説明的な名前を付けます。
• ソース・システム： データの送信元システムを指定します。

例

• クエリ名 Extended Trial Balance - Workday - Financial Statement

  Description： このクエリは、Workday から試算表データを取得し、財務諸表を作成するための補足データセットを追加します。

注： テーブルとクエリ でパイプ区切り（｜）の使用を避けることが重要である。代わりに、ハイフン（-）を使用して、これらのアーティファクトによる潜在的な問題を防いでください。

この命名規則に従うことで、スプレッドシートへの接続を作成する際に、どのクエリを使用すべきかが明確になります。

内容

説明文は、設計と構築のプロセスで最も見落とされがちな部分だが、理解と使いやすさを向上させるためには極めて重要である。説明には、次のような補足的な文脈を示すべきである：

• テーブルまたはクエリがプレースホルダであるかどうかを示す。
• クエリを使用する前に編集する必要があるかどうかを通知します。
• クエリのようなアーティファクトの具体的な機能を明確にすること、例えば、前期より20％以上低い支払いを特定する。

明確で詳細な説明を含めることで、ユーザーは各アーティファクトの目的と内容を素早く把握することができ、混乱を減らし、エラーを最小限に抑え、Wdata環境の管理における全体的な効率を高めることができます。

フォルダ/環境

ワークスペースを整理するときは、テーブルとクエリを使用目的に応じてフォルダに分類することをお勧めします。この構造により、ユーザーは簡単にナビゲートし、どの成果物が開発、テスト、本番用に指定されているかを判断できる。

Wdataは現在、アプリケーション・ライフサイクル管理をサポートしていないため、アーティファクトやフォルダには、それぞれの環境を示す名前を付けることを推奨する。これは、アプリケーションのライフサイクルを管理し、エラーや問題を回避するのに役立ちます。プロダクション・アーティファクトには、付加名は必要ない。