DBT Voorbeeld

Een nader voorbeeld van een uitwerking op basis van DBT

Ja — hieronder een realistisch voorbeeld van een dbt-model voor een sales datamart.

Ik laat zien:

1. brondata (staging)
2. businessmodel (marts)
3. metadata (schema.yml)
4. metrics
5. hoe AI/Codex dit begrijpt

Structuur van een dbt project

dbt_project/
│├── models/│ ├── staging/│ │ ├── stg_sales.sql│ │ ├── stg_customers.sql│ │ └── schema.yml│ ││ ├── marts/│ │ ├── fact_sales.sql│ │ ├── dim_customer.sql│ │ └── schema.yml│├── macros/├── tests/└── dbt_project.yml

1. Staging model

models/staging/stg_sales.sql

SELECT order_id, customer_id, product_id, order_date, quantity, unit_price, quantity * unit_price AS sales_amountFROM raw.sales_ordersWHERE order_status = 'Completed'

Wat gebeurt hier?

Dit model:

• leest ruwe brondata
• filtert completed orders
• berekent omzet
• standaardiseert naming

dbt materialiseert dit als:

• tabel
• view
• incremental model

2. Customer dimension

models/marts/dim_customer.sql

SELECT customer_id, customer_name, customer_segment, country, cityFROM {{ ref('stg_customers') }}

Belangrijk: ref()

{{ ref('stg_customers') }}

Dit is dbt lineage.

Daardoor weet dbt:

• afhankelijkheden
• model relaties
• build order
• impact analysis

AI-agents begrijpen dit ook uitstekend.

3. Fact table: models/marts/fact_sales.sql

SELECT

order_date,

customer_id,

SUM(amount) AS revenue

FROM raw_sales

GROUP BY 1,2

Resultaat

Je krijgt:

fact_sales

als centrale analytische tabel. Dit lijkt sterk op:

• Power BI star schema
• Fabric warehouse model
• Kimball modeling

4. Metadata met schema.yml

models/marts/schema.yml

version: 2models: - name: fact_sales description: Sales fact table columns: - name: order_id description: Unique order identifier tests: - unique - not_null - name: sales_amount description: Total revenue for the order - name: customer_id tests: - relationships: to: ref('dim_customer') field: customer_id

Waarom dit krachtig is

Dit is:

• documentatie
• validatie
• governance
• semantic context

in één bestand.

5. dbt tests

dbt voert automatisch tests uit:

Voorbeelden

Unieke sleutel

- unique

Controleert:

• geen dubbele order_id

Relatie test

relationships:

Controleert:

• alle customer_id’s bestaan in dim_customer

6. Metrics model

metrics.yml

metrics: - name: total_revenue label: Total Revenue model: ref('fact_sales') calculation_method: sum expression: sales_amount - name: total_orders model: ref('fact_sales') calculation_method: count expression: order_id

Waarom dit belangrijk is

Nu heb je:

ÉÉN definitie van revenue

in plaats van:

• 12 verschillende Power BI measures
• inconsistenties
• duplicated logic

Hoe Codex hiermee werkt

Codex kan nu:

• lineage begrijpen
• metrics genereren
• SQL refactoren
• documentatie maken
• tests toevoegen
• dashboards bouwen

Omdat alles:

• tekstgebaseerd
• declaratief
• Git-native
  is.

Wat dbt genereert

dbt maakt uiteindelijk:

raw.sales_orders↓stg_sales↓fact_sales↓dashboard

met volledige lineage.

Vergelijking met Power BI

Moderne enterprise architectuur

Vaak zie je nu:

Databricks/Snowflake
↓
dbt
↓
Semantic layer
↓
Power BI / Omni / Hex
↓
AI agents

Heel belangrijk inzicht

dbt is eigenlijk:

“Software engineering voor analytics.”

Dat is waarom AI-tools zoals Codex er zo goed mee werken.