Power Bi Model Design Review

Power BI model design review

Evaluate a Power BI semantic model from business purpose, table structure, relationship network, storage strategy, DAX and governance evidence, then return prioritized findings and an implementation roadmap.

When to invoke

• "Review this Power BI data model design."
• "Check whether our Power BI model follows star schema best practices."
• "Evaluate the relationships, storage modes, and performance risks in this model."
• "Run a pre-production Power BI semantic model review."
• "Create a modernization roadmap for this Power BI model."

Source evidence

Use the model description, business purpose, architecture overview, table and relationship metadata, performance requirements, known issues, specific review focus areas, and available time/resource constraints. If the user omits metadata, review what is available and mark missing evidence explicitly.

Review scope

Criteria

Schema architecture

• Fact table grain is stated, consistent, and compatible with all measures.
• Dimension tables carry descriptive attributes and hierarchies instead of repeating dimension data in facts.
• Snowflaking is minimal and justified by maintenance, reuse, or size constraints.
• Many-to-many relationships use bridge tables or another explicit design instead of accidental ambiguity.
• Date table implementation supports the model's time intelligence needs.

Relationship design

• Cardinality settings match data reality, including missing/orphaned records and referential integrity assumptions.
• Bidirectional relationships are present only when required and do not create ambiguous filter propagation paths.
• Relationship columns use efficient data types, preferably integer keys over high-cardinality text.
• Cross-filtering impact is understood for report interactions, RLS, and composite models.

Data quality and integrity

• All required business entities and critical relationships are represented.
• Related columns use consistent data types, formatting, and encoding.
• NULL values, orphaned records, slowly changing dimensions, surrogate keys, natural keys, and reference data are handled deliberately.
• Business rules, transformations, and calculated fields are traceable and validated.

Performance and scalability

• Data reduction opportunities are identified: unnecessary columns, redundant data, historical archiving, and pre-aggregation.
• High-cardinality columns, calculated columns in large tables, and measure complexity are flagged.
• Refresh requirements, query performance expectations, growth projections, and concurrent user capacity are considered.
• DirectQuery indexing requirements, aggregation tables, composite model optimization, and cache utilization are reviewed when applicable.

Governance and readiness

• Table and column descriptions, relationship justification, data source documentation, and measure calculation explanations are present.
• Testing, validation, deployment, rollback, and user communication procedures are defined.
• RLS design, role-based access control, dynamic security patterns, audit trails, data retention, and sensitive data handling are validated.

Review depth

Treat defects that affect functionality/performance as high priority even when the remediation work is small.

Recommendation format

For each issue, include:

Gotchas

• Do not reward complexity: snowflake schemas, bidirectional filters, and many-to-many relationships require evidence because they increase ambiguity and performance cost.
• Do not review storage mode in isolation: Import, DirectQuery, Composite, Dual, and Hybrid choices affect relationships, aggregations, refresh, and user experience together.
• Do not treat documentation as cosmetic: missing descriptions, business rules, and relationship justifications are maintainability defects.

Output template

## Data model review summary — <model name>

**Verdict:** approve | approve with risks | fix required | not enough evidence
**Business domain and scope:** <domain>
**Primary use cases and user groups:** <summary>
**Current size and complexity metrics:** <tables, relationships, rows, storage modes, if known>

### Key findings
- **Critical issues requiring immediate attention:** <count and summary>
- **Performance optimization opportunities:** <count and summary>
- **Best practice compliance assessment:** <summary>
- **Security and governance status:** <summary>

### Priority recommendations
1. **High Priority:** <critical issues impacting functionality or performance>
2. **Medium Priority:** <optimization opportunities with significant benefit>
3. **Low Priority:** <best practice improvements and future considerations>

### Detailed findings
| Area | Finding | Impact | Risk | Recommendation | Validation |
| --- | --- | --- | --- | --- | --- |
| Schema Architecture | <fact/dimension/relationship issue> | <performance/maintenance/accuracy> | High | <specific fix> | <test or evidence> |
| Performance Architecture | <storage/DAX/size issue> | <impact> | Medium | <specific fix> | <benchmark or review> |
| Governance and Security | <RLS/documentation/compliance issue> | <impact> | Medium | <specific fix> | <evidence> |

### Implementation roadmap
- **Quick wins (1-2 weeks):** <actions>
- **Short-term improvements (1-3 months):** <actions>
- **Long-term strategic enhancements (3-12 months):** <actions>

Quality gate

• The review states the model purpose, scope, known constraints, and evidence used.
• Fact table grain, dimension quality, relationship cardinality, filter direction, and storage modes were checked.
• Performance findings consider model size, DAX complexity, refresh, query performance, scalability, and concurrent usage.
• Security findings cover Row-Level Security, role-based access control, sensitive data, compliance, audit trail, and retention where applicable.
• Each issue includes impact, risk level, recommendation, implementation guidance, testing and validation, rollback consideration, and success criteria.
• The output follows ## Output template exactly and separates high, medium, and low priorities.