A checker at a data layer is used to define a naming convention for and unify the naming formats of tables and derived metrics at the data layer. When you create a table or a derived metric, you can select a checker to generate a name for the table or the derived metric based on the naming convention defined in the checker. After the table or the derived metric is published, you can quickly understand the business information about the table or the derived metric based on the table name or metric name. This topic describes how to configure and use a checker at a data layer in Data Warehouse Planning.
Prerequisites
A data layer for which you want to configure a checker is created. For more information about how to create a data layer, see Create a data layer.Configure a checker at a data layer
- Log on to the DataWorks console. In the left-side navigation pane, click Workspaces. On the Workspaces page, find the workspace in which you want to configure a checker and click DataStudio in the Actions column. On the DataStudio page, click the More icon in the upper-left corner and choose Data Modeling > Data Warehouse Planning. The Data Layer page appears. On the Data Layer page, click the created data layer to go to the details page of the data layer.
- Configure a checker at the data layer.
- Run the configured checker and view check results.
Use a checker
- Example 1An enterprise wants the names of tables at the desired data layer to start with
dim_
. If the data layer contains tables named dim_sku, dim_store, dimension_warehouse, and fact_order, the checker used by the enterprise starts the check after the checker is triggered. The following table shows the check results.Table name Naming convention observed dim_sku Yes. dim_store Yes. ension_warehouse No. The name of the table does not start with dim_
.fact_order No. The name of the table does not start with dim_
. - Example 2
An enterprise wants tables at the DWD layer to be named in the format of
dwd_sale_order_df/di
.dwd
represents the prefix for the names of tables.sale
represents the name of the data domain to which tables belong.order
represents the abbreviation of the name of a custom tag for tables.df/di
represents a storage policy.If the data layer contains tables named dwd_sale_order_df, dwd_sale_order_di, dwd_sale_order, and dws_sale_order_df, the checker used by the enterprise starts the check after the checker is triggered. The following table describes the check results.Table name Naming convention observed dwd_sale_order_df Yes. dwd_sale_order_di Yes. dwd_sale_order No. The name of the table does not contain df or di
.dws_sale_order_df No. The name of the table does not contain dws
. - Example 3The model committee of an enterprise wants to unify and standardize the display names of derived metrics at the DWS layer in the
Period_Modifier_Atomic metric
format. The model committee creates a checker that meets the following conditions: The Rule Type parameter is set to Display Name, the Rule Definition parameter is set to Period_Modifier_Atomic metric, and the Strength Type parameter is set to Strong Rule for the rule defined in the checker. When developers create derived metrics namedLast one day_Shop A_Users
,Last 30 days_Beijing_Commodity B_Sales volume
,Shop A_Users_Last seven days
, andShop A_Users
at the DWS layer and save the configurations of the derived metrics, the checker is triggered and starts the check. The following table describes the check results.Derived metric name Naming convention observed Last one day_Shop A_Users Yes Last 30 days_Beijing_Commodity B_Sales volume Yes Shop A_Users_Last seven days No Shop A_Users No