luvv to helpDiscover the Best Free Online Tools

Data Governance Basics

Learn Data Governance Basics for BI Developer for free: roadmap, examples, subskills, and a skill exam.

Published: December 24, 2025 | Updated: December 24, 2025

Why this skill matters for BI Developers

Data governance turns dashboards into trusted decisions. As a BI Developer, you are the bridge between raw data and business outcomes. Governance helps you define owners, standardize metrics, control access, document logic, manage changes, and monitor adoption—so your dashboards are reliable and safe to scale across the company.

  • Deliver consistent, repeatable metrics people trust.
  • Reduce ad-hoc chaos and supportability costs.
  • Protect sensitive data and comply with regulations.
  • Know what to fix first when quality drops.

What you will be able to do

  • Set metric ownership, definitions, and certification criteria.
  • Write lightweight data quality checks and SLAs for BI.
  • Apply role-based access and simple row-level security patterns.
  • Document dashboards and datasets so others can self-serve.
  • Version and communicate metric changes safely.
  • Track usage to focus on what matters.

Who this is for

  • BI Developers and Analysts building dashboards and semantic layers.
  • Analytics Engineers partnering with BI and data platform teams.
  • Team leads who need reliable, compliant reporting.

Prerequisites

  • Basic SQL (SELECT, JOIN, GROUP BY).
  • Familiarity with a BI tool (any).
  • Understanding of your company’s core business metrics.
Quick definitions
  • Metric Owner: Accountable person for correctness/usage.
  • Data Steward: Operates data processes and quality checks.
  • Certified Dashboard: Governed and approved for official use.
  • RLS (Row-Level Security): Restricts which rows a user can view.
  • PII: Personal data requiring extra protection.

Learning path (fast, practical)

Milestone 1 — Establish accountability

  • Pick 3–5 core metrics and assign an Owner and a Steward for each.
  • Write a one-page metric card: definition, formula, owner, freshness, caveats.
  • Set a simple escalation path for data issues.

Milestone 2 — Quality expectations

  • Define “good enough”: acceptable null rates, freshness, duplicates, and coverage.
  • Add 2–3 SQL checks per key dataset (not-null, uniqueness, referential integrity).
  • Schedule checks to run daily or before refresh.

Milestone 3 — Certification and documentation

  • Choose 1–2 dashboards to certify. Add certification badge and version.
  • Create consistent doc sections: purpose, audience, metric list, data source, refresh time, owner.

Milestone 4 — Access and privacy

  • Map roles (Viewer, Analyst, Admin) and grant least privilege.
  • Add simple RLS for sensitive metrics (e.g., region, department).
  • Remove broad “All Users” access where not needed.

Milestone 5 — Change management

  • Adopt semantic versioning for metrics (MAJOR.MINOR.PATCH).
  • Publish change notes and deprecation windows.
  • Notify impacted stakeholders before breaking changes.

Milestone 6 — Monitor usage and improve

  • Track views, active users, refresh success rate.
  • Archive dashboards with near-zero use after a review period.
  • Review adoption and quality monthly with owners/stewards.

Worked examples

1) Metric card: Active Customers

Metric: Active Customers
Owner: Head of Customer Analytics
Steward: BI Developer (You)
Business question: How many customers engaged this month?
Definition: Customers with at least 1 order OR at least 1 product usage event in the last 30 days.
Formula (SQL-ish):
  active_customers = COUNT(DISTINCT customer_id)
  FROM (
    SELECT customer_id, event_date FROM fct_orders WHERE event_date >= CURRENT_DATE - INTERVAL '30 day'
    UNION ALL
    SELECT customer_id, event_date FROM fct_usage WHERE event_date >= CURRENT_DATE - INTERVAL '30 day'
  ) s
Freshness target: within 6 hours of event capture.
Data quality checks: s.customer_id NOT NULL; deduplicate on (customer_id, event_date).
Caveats: Trial users excluded if no sign-up verification.
SLA for change: 2 weeks notice for definition changes.

2) Data quality checks for BI tables

-- Uniqueness check on order_id
SELECT order_id
FROM fct_orders
GROUP BY order_id
HAVING COUNT(*) > 1;

-- Not-null check for critical dims
SELECT COUNT(*) AS null_customer_ids
FROM fct_orders
WHERE customer_id IS NULL;

-- Referential integrity (dangling foreign keys)
SELECT o.customer_id
FROM fct_orders o
LEFT JOIN dim_customer c ON c.customer_id = o.customer_id
WHERE c.customer_id IS NULL;

-- Freshness (last load timestamp)
SELECT MAX(loaded_at) AS last_loaded_at FROM fct_orders;

Agree thresholds with owners, e.g., duplicates = 0, null rate <= 0.5%, freshness <= 6 hours. Alert if thresholds are breached.

3) Simple row-level security (RLS) via authorized views

-- Assume a mapping table of user_email -> region
-- Create a view filtering rows based on the current user's region
CREATE OR REPLACE VIEW sales_secure AS
SELECT s.*
FROM fct_sales s
JOIN user_region_map m ON m.region = s.region
-- Replace CURRENT_USER with your BI tool's session user function
WHERE m.user_email = CURRENT_USER;

Point the dashboard to sales_secure instead of the raw table. Keep the mapping table updated by your admin process.

4) Dashboard certification checklist

Certification Criteria (pass all):
[ ] Metric definitions match approved cards
[ ] Data quality checks green for last 7 days
[ ] Owner and Steward named on dashboard
[ ] Documented refresh schedule and data sources
[ ] Access reviewed; sensitive fields masked if needed
[ ] Version set (e.g., v1.1.0) and change notes added

5) Change management for metric definitions

Example: Changing Active Customers window from 30 to 28 days
- Impact: Slightly lower counts; affects weekly KPIs.
- Version: v2.0.0 (MAJOR change)
- Deprecation: Keep v1.?.? dashboards for 30 days with notice banner.
- Communication: Email/Data Slack + note in dashboard header.
- Rollback plan: Keep old view as active_customers_v1 for 30 days.

Drills / exercises

  • Pick one KPI and write a one-page metric card with owner, steward, formula, and caveats.
  • Add two SQL checks (uniqueness and not-null) to a source you maintain.
  • Map 3 roles and remove one overly broad permission.
  • Add a certification badge and version to one dashboard.
  • Write a short change note for a small metric tweak (PATCH level).
  • Create a monthly adoption snapshot: views, unique viewers, top 3 dashboards.

Common mistakes and how to fix them

  • No named owners: Fix by assigning an accountable owner and visible steward on the dashboard.
  • Over-engineering: Keep governance lightweight—start with top 3 metrics and 2–3 checks.
  • Undefined certification: Publish a simple checklist and apply it consistently.
  • Access sprawl: Review role grants quarterly and remove “All Users” where not needed.
  • Silent breaking changes: Use semantic versions and add deprecation banners.
  • No adoption tracking: Log views and act—archive stale dashboards to reduce noise.
Debugging tips
  • If numbers don’t match: Compare metric cards, filters, and time windows before checking code.
  • If quality is flaky: Look at freshness and duplicates first; then join logic.
  • If users see wrong data: Verify RLS view logic and mapping table.
  • If adoption stalls: Interview 3 users; improve title, description, and default filters.

Practical projects

  • Govern one KPI suite: Choose Revenue, Active Customers, and Churn; add metric cards, certification, and access controls.
  • Quality wallboard: Create a simple dashboard tracking nulls, duplicates, and freshness across key tables.
  • Adoption pulse: Build a weekly report with views per dashboard and top 10 users by engagement.

Mini project: Govern a Sales Starter Pack in a day

Goal: Ship a governed Sales Overview dashboard with clear ownership, quality checks, and basic access control.

  1. Define 3 metrics: Total Sales, Average Order Value, Active Customers (30d). Create metric cards.
  2. Add SQL checks: uniqueness on order_id, not-null customer_id, freshness <= 6h.
  3. Create an RLS view by region and point the dashboard to it.
  4. Document the dashboard: audience, refresh, owners, data sources.
  5. Certify it using the checklist, tag version v1.0.0, publish change notes.
  6. Log adoption for the first week and plan improvements.
Definition of done
  • Owners named, docs present, quality checks green.
  • Access least-privilege, RLS view used.
  • Dashboard shows version and certification badge.

Monitoring usage: quick SQL

-- Example: dashboard views by month
SELECT dashboard_id,
       DATE_TRUNC('month', viewed_at) AS month,
       COUNT(*) AS views,
       COUNT(DISTINCT user_id) AS unique_viewers
FROM bi_audit_log
GROUP BY 1, 2
ORDER BY 2 DESC;

Use this to focus quality and governance where it matters most.

Subskills

  • Defining Metric Owners And Stewards
  • Data Quality Expectations For BI
  • Certified Versus Ad Hoc Reporting
  • Access And Privacy Policies Basics
  • Change Management For Metric Definitions
  • Documentation Standards
  • Monitoring Usage And Adoption
  • Compliance Awareness Basics

Next steps

  • Adopt the governance checklist on at least two more dashboards.
  • Automate your top three data quality checks.
  • Schedule a monthly governance review with owners and stewards.

Skill exam

When you are ready, take the exam below. Everyone can take it for free; sign in to save your progress.

Data Governance Basics — Skill Exam

This exam checks your practical understanding of BI data governance. Everyone can take it for free. If you sign in, your progress and results will be saved so you can pause and resume anytime.Tip: Aim for at least 70% to pass. You can retake the exam as needed.

12 questions70% to pass

Have questions about Data Governance Basics?

AI Assistant

Ask questions about this tool