DBT governance

Thid markdown document will specify the rules that need to follow by every developer.
Short naming converntion lists that need to follow

model_type Shortcut	Full name
seed	Seed
src	Source
snap	Snapshot
stg	Stage
int	Intermediate
fct	Fact
dim	Dimension
rep	Report
sem	Semantic

model_name Shortcut	Full name	Use case
brg	Brigde	relationship table
log	Log	log data

CIEF General Rule

• Snowflake SQL use to write dbt SQL code
• Star schema is use
• First week of the day is start at Monday, and last week of the day will be Sunday
• Fiscal 1st quarter is start from Febuary
• Timezone: Kuala Lumpur / Malaysia (GMT +8)
• Some status/type is not input in raw database (You should found in seed)

DBT Rule

Structure of the dbt model layer

• Analyses
  1. Analyses layer will not create in Snowflake
  2. You can write some adhoc queries
  3. Test some SQL code before write in Models

• Macros
  1. Jinja function that reuse in other models

• Models

  • Staging

    • [system_name]
      1. Materialise: View
      2. 1-to-1 relationship (or mapping) to source tables.
      3. Column renaming
      4. Column remove
      5. Column data renaming, such as (status integer to string)
      6. Data input error cleansing
      7. Check for raw data freshness
      8. Data type transformation
      9. Data split and merge
      • Source
        1. Source will write in YML
        2. Check Freshness
        3. Check duplicate id
        4. Check null id

  • Intermediate

    1. Materialise: Ephemerally
    2. Stacking layers of logic with clear and specific purposes to prepa our staging models to join into the entities we want
    3. Be referenced repeatedly in more than one model
    4. Isolating complex operations

  • Marts/warehouse

    1. Materialise: Table
    2. Store fact and dimension models

  • Marts/reporting

    1. Materialise: Table
    2. Store custom reports

• Seeds
  1. Store custom dataset in csv format
  2. The dataset must not change frequently

• Snapshots
  1. DBT build-in SCD type 2 function
  2. Prefer to use after the source table and before the staging layer

• Tests
  1. Can write some yml test case

File Naming Rules

• File names must be unique
• Each sql/python file must start with [model_type]_[system_name]__[model_name]s.sql/py
• The model should be name as plural. (eg: stg_exchange__orders.sql)

Column Naming Rules

• If array datatype, the column naming must be plural (eg: ids, messages)
• all the date & time field will need to name as datetime / date (eg: created_datetime)

SQL Coding Rule

• The SQL clause must be UPPERCASE (eg. SELECT, FROM, WHERE, GROUP BY, LIMIT, WITH, AS, SUM, PARTITION OVER, DIV0, LEFT JOIN, ON ....)
• Try to avoid using EXCLUDE in the SQL
• Avoid using multi layer subquery, and try to use CTE, subquery must not more than 1 layer
• Each model structure must contain with

--IMPORT
WITH [table_names] AS (
    SELECT * FROM {{ ref('file_names')}}
),

--LOGIC
[logic_names] AS (
    .....
),

--FINAL
final__[table_names] AS (

)
SELECT * FROM final__[final_table_names]