Making changes in a data warehouse is unavoidable. Business definitions evolve, data models improve, and naming conventions change. However, uncontrolled changes to views or tables can easily break live reports, especially when those objects are already being consumed by Power BI, Excel, APIs, or downstream models.
This article describes how we manage change safely, using common real‑world scenarios and the checks we perform before making any change.
Step 1: Always Check Usage First
Before changing anything, we ask:
Is anyone using this view or table?
Things we check:
- DataView usage analysis Power BI report
Outcomes
- ✅ If no one is using it
The object can usually be changed freely. - ⚠️ If it is being used
We must treat the change as breaking and apply additional safeguards.
Step 2: Identify Whether the Object Has History
Not all views or tables behave the same.
How to tell
- MDM schema → ✅ Has history (SCD / Delta history)
- MVW schema → ❌ No history (thin, logical views)
This distinction is critical because history limits what we can safely change.
Change Scenarios
Scenario 1: Renaming a View
Example
Renaming:
invoice_item_dates_stage
→ invoice_event_stage
Checks
- Is the view being used?
- Is it an MVW or an MDM object?
Case 1: MVW View (No History)
✅ Safer scenario
- MVWs do not contain history
- They are defined in SQL from the container
- The old view definition can remain in place
Recommended approach
- Create the new view
- Leave the old view untouched
- Both continue working side‑by‑side
This allows:
- Existing reports to keep working
- Zero immediate breaking changes
Case 2: MDM View or Table (Has History)
⚠️ Higher risk
MDM objects are backed by Delta tables with historical tracking. Renaming the SQL view file without renaming the underlying MDM table would result in the creation of a new table with no historical data, effectively breaking history‑aware reporting.
Required approach
- Duplicate object in MyBMT catalogue
- Duplicate the existing MDM Delta table .
- Rename the duplicated delta table to the new viewname
- Do not immediately rename or remove the original object in the MyBMT catalogue.
Important:
The original MDM table associated with the old view name will stop being updated if the old view name no longer exists in the catalogue. For this reason, we withhold renaming or removing the old name in the catalogue until we are confident that the old view name is no longer required and all consumers have migrated.
This ensures:
- Historical queries remain valid
- Old reports do not silently return incorrect results
- New development can progress cleanly
Scenario 2: Renaming a Column
Example
Renaming a field:
lifecycle_stage
→ lifecycle
Checks
- Is this column part of an MDM table?
- Does it participate in history tracking?
Case: Column Change in an MDM Table
⚠️ History must be rebuilt
Because column names are embedded in:
- SCD logic
- Delta history
- Active/expiry filtering
- Consumer queries
✅ Correct approach
- Rebuild the full history for that MDM table
- Validate row counts before and after
- Confirm historical timelines still make sense
Skipping the rebuild risks:
- Partial history
- Broken point‑in‑time reporting
- Incorrect analytics
Validation Checklist (What We Always Verify)
Before and after any change, we validate:
- ✅ Row counts (before vs after)
- ✅ Historical continuity (MDM tables)
- ✅ Report outputs (spot checks)
Summary Table
| Change Type | MVW | MDM |
|---|---|---|
| Rename view | Safe to duplicate | Duplicate table |
| Rename column | Safe | Rebuild history |
| Logic change | Version view | New MDM version |
| Drop object | Only if unused | Only if unused |
Final Thoughts
Managing change in a data warehouse is less about making the change and more about protecting consumers. By:
- checking usage,
- understanding history,
- and preferring duplication over destruction,
we can evolve the warehouse without breaking reports or trust.
This approach gives teams flexibility to improve models while providing report users with stability and confidence in the data.