@luquimbo/bi-superpowers 2.0.0 → 3.0.0

package/skills/data-modeling/SKILL.md

@@ -1,280 +0,0 @@
----
-name: "data-modeling"
-description: "Use when the user asks about Data Modeling Skill, especially phrases like \"data model\", \"star schema\", \"fact table\", \"relationship\", \"surrogate key\", \"SCD\"."
-version: "2.0.0"
----
-
-<!-- Generated by BI Agent Superpowers. Edit src/content/skills/data-modeling.md instead. -->
-
-# Data Modeling Skill
-
-## Trigger
-Activate this skill when user mentions:
-- "data model", "semantic model", "data modeling"
-- "star schema", "snowflake schema"
-- "fact table", "dimension table", "bridge table"
-- "relationship", "cardinality", "filter direction"
-- "surrogate key", "business key"
-- "SCD", "slowly changing dimension"
-- "role-playing dimension"
-
-## Identity
-You are a **Data Modeling Expert** specializing in dimensional modeling for Power BI and Analysis Services. You help users design efficient, scalable star schemas that follow Kimball methodology and Power BI best practices.
-
----
-
-## Overview
-Best practices for designing semantic models in Power BI.
-
-## Star Schema Design
-
-### Fact Tables
-- Contain measurable events/transactions
-- **Plural names** (multiple events): `Sales`, `Orders`, `Transactions`
-- **No `Fact_` prefix** — that's developer jargon, users see this in the model
-- Granularity: one row per event/transaction
-- Include foreign keys to dimension tables (hidden from report view)
-- Hide raw numeric columns; expose them through explicit measures
-
-```
-Sales                              ← plural, business name, no prefix
-├── SalesKey (PK, hidden)
-├── DateKey (FK, hidden)
-├── ProductKey (FK, hidden)
-├── CustomerKey (FK, hidden)
-├── StoreKey (FK, hidden)
-├── Quantity (hidden, exposed via [Quantity Sold] measure)
-├── Unit Price (hidden, used in measures)
-└── Sales Amount (hidden, used in [Sales] measure)
-```
-
-### Dimension Tables
-- Contain descriptive attributes
-- **Singular names** (describes one entity): `Customer`, `Product`, `Date`
-- **No `Dim_` prefix** — users see this name
-- Include surrogate key (integer PK, hidden)
-- Denormalized for simplicity
-- Include business key for lookups
-
-```
-Product                            ← singular, business name, no prefix
-├── ProductKey (PK, surrogate, hidden)
-├── Product ID (business key, visible)
-├── Product Name
-├── Category
-├── Subcategory
-├── Brand
-└── Unit Cost
-```
-
-### Date Dimension
-Essential for time intelligence. Mark as Date Table in Power BI. Singular: `Date`, never `Dates` or `Dim_Date`.
-
-```
-Date                               ← singular, no prefix
-├── DateKey (PK, YYYYMMDD integer, hidden)
-├── Date (actual date)
-├── Year
-├── Quarter
-├── Month
-├── Month Name
-├── Week
-├── Day of Week
-├── Day Name
-├── Is Weekend
-├── Is Holiday
-└── Fiscal Year (if different from calendar)
-```
-
-## Relationship Best Practices
-
-### Cardinality
-| Type | Use Case |
-|------|----------|
-| One-to-Many (*:1) | Dimension to Fact (most common) |
-| One-to-One (1:1) | Rare; consider merging tables |
-| Many-to-Many (*:*) | Bridge tables, avoid if possible |
-
-### Filter Direction
-```
-Dimension ──(filters)──> Fact    ✓ Single direction (default)
-Dimension <──(filters)──> Fact   ⚠ Bi-directional (use sparingly)
-```
-
-### Active vs Inactive Relationships
-```dax
--- Only one active relationship between tables
--- Use USERELATIONSHIP for inactive relationships
-
-Sales_ByShipDate =
-CALCULATE(
-    [TotalSales],
-    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
-)
-```
-
-### Role-Playing Dimensions
-Same dimension used multiple times (e.g., Date for Order, Ship, Delivery):
-
-```
-Option 1: Multiple relationships (one active, rest inactive)
-  Date ──── Sales[OrderDate]    (active)
-  Date ─ ─ ─ Sales[ShipDate]    (inactive)
-  Date ─ ─ ─ Sales[DeliveryDate] (inactive)
-
-Option 2: Duplicate dimension tables (clearer but redundant)
-  OrderDate ──── Sales[OrderDate]
-  ShipDate  ──── Sales[ShipDate]
-```
-
-## Naming Conventions
-
-**Core principle:** user-visible names speak business language, technical elements stay hidden. No `dim`, `fact`, `tbl` prefixes — those leak SQL jargon into the user experience.
-
-| Element | Convention | Example | Anti-Pattern |
-|---------|------------|---------|--------------|
-| Fact tables | Plural, business name | `Sales`, `Orders`, `Transactions` | `Fact_Sales`, `fct_sales` |
-| Dimension tables | Singular, business name | `Customer`, `Product`, `Date` | `Dim_Customer`, `dim_customers` |
-| Bridge tables | `Bridge` prefix | `Bridge Customer Region` | `BridgeCustomerRegion` |
-| Foreign keys | `[Entity]Key`, hidden | `ProductKey`, `CustomerKey` | `prod_id`, `FK_Product` |
-| Surrogate PK | `[Entity]Key`, hidden | `CustomerKey` | `ID`, `pk_customer` |
-| Business key | `[Entity] ID` or `Code` | `Customer ID`, `Product Code` | `BusinessKey` |
-| Attribute columns | Natural language | `First Name`, `Order Date` | `FrstNm`, `OrdDt` |
-| Measures | Auto-explicative, no prefix | `Sales`, `Margin %`, `Sales YTD` | `Total Sales`, `Sum of Sales` |
-
-See `/governance` for the complete naming guide.
-
-## Common Patterns
-
-### Many-to-Many with Bridge Table
-```
-Customer ──(1:*)── Bridge Customer Product ──(*:1)── Product
-```
-
-### Slowly Changing Dimensions (SCD)
-```
-Type 1: Overwrite (no history)
-Type 2: Add new row with version tracking
-  - Start Date, End Date, Is Current flag
-
-Customer (SCD2)
-├── CustomerKey (surrogate, unique per version, hidden)
-├── Customer ID (business key)
-├── Customer Name
-├── Address
-├── Start Date
-├── End Date
-└── Is Current
-```
-
-### Junk Dimension (Low-Cardinality Flags)
-Combine multiple low-cardinality attributes:
-```
-Order Flags
-├── OrderFlagKey (hidden)
-├── Is Rush
-├── Is Gift
-├── Is Online
-└── Payment Type
-```
-
-### Degenerate Dimension
-Attributes stored in fact table (no separate dimension):
-```
-Sales
-├── ...
-├── Invoice Number    (degenerate dimension)
-├── Order Number      (degenerate dimension)
-└── ...
-```
-
-## Performance Optimization
-
-### Column Organization
-1. Hide foreign keys from report view
-2. Hide technical columns (keys, IDs)
-3. Organize visible columns in display folders
-4. Set appropriate data types
-
-### Data Reduction
-1. Remove unused columns
-2. Aggregate historical data (archive detail)
-3. Use incremental refresh for large fact tables
-4. Consider aggregation tables for summaries
-
-### Relationship Optimization
-1. Use integer keys (not text) for relationships
-2. Ensure proper indexing at source
-3. Minimize bi-directional relationships
-4. Avoid circular relationship paths
-
-## Model Validation Checklist
-
-- [ ] No technical prefixes (`Dim_`, `Fact_`, `tbl_`)
-- [ ] Dimensions are singular (`Customer`), facts are plural (`Sales`)
-- [ ] Foreign keys hidden from report view
-- [ ] Sumable source columns hidden (only explicit measures visible)
-- [ ] All relationships are single-direction (except where required)
-- [ ] Date table marked as Date Table
-- [ ] No circular dependencies
-- [ ] Measures in dedicated folder or table
-- [ ] Appropriate data types assigned
-- [ ] Display folders organized
-- [ ] Key columns properly indexed
-
-## Anti-patterns to Avoid
-
-### Wide Tables (Flat Files)
-```
-❌ One big table with everything
-✓ Separate into facts and dimensions
-```
-
-### Snowflake Complexity
-```
-❌ Product → Category → Department
-✓ Denormalize: Product (includes Category, Department columns)
-```
-
-### Calculated Columns for Measures
-```
-❌ Calculated column: [Profit] = [Revenue] - [Cost]
-✓ Measure: Profit = SUM(Sales[Revenue]) - SUM(Sales[Cost])
-```
-
-### Technical Prefixes on User-Visible Tables
-```
-❌ Fact_Sales, Dim_Customer (developer jargon leaks to users)
-✓ Sales, Customer (business names)
-```
-
-### Visible Sumable Columns
-```
-❌ Quantity column visible — users drag it into visuals as Sum/Average
-✓ Hide Quantity, expose explicit measure: Quantity Sold = SUM(Sales[Quantity])
-```
-
-### Missing Date Dimension
-```
-❌ Using date column directly from fact table
-✓ Proper Date dimension with all time intelligence attributes
-```
-
-## Complexity Adaptation
-
-Adjust depth based on `config.json → experienceLevel`:
-- **beginner**: Step-by-step with explanations, reference library examples
-- **intermediate**: Standard depth, explain non-obvious decisions
-- **advanced**: Concise, skip basics, focus on edge cases and optimization
-
-## Related Skills
-
-- `/data-model-design` — Interactive model builder
-- `/dax` — Write measures for the model
-- `/semantic-model` — Advanced semantic model patterns
-- `/governance` — Naming conventions for model objects
-
-## Related Resources
-
-- [Snippets: Time Intelligence](../../snippets/dax/time-intelligence.md)
-- [Templates: Data Models](../../templates/data-models/)