A housing authority must keep auditable history when apartment eligibility status changes over time. Which slowly changing dimension approach should they use?
Select an answer to reveal the explanation.
Short Explanation
SCD Type 2 keeps old eligibility rows with dates, so you can see what was true when a benefit decision was made. It doesn't erase history, so auditors can reconstruct decisions later.
Full Explanation
SCD Type 2 so historical eligibility rows remain for auditable benefit decisions is the correct slowly changing dimension approach for a housing authority. Type 2 keeps prior attribute versions with effective dating, or equivalent history rows, so auditors can reconstruct which apartment eligibility status was true when a benefit decision was made, satisfying civic accountability over time. SCD Type 1 so historical eligibility rows remain for auditable benefit decisions fails by concept because it overwrites history in place, so prior states disappear and benefit decisions cannot be reconstructed. The SCD Type 1 so historical eligibility rows remain for auditable benefit decisions approach is explicitly history-destroying for this attribute and contradicts the audit requirement. The rebuild dimension so historical eligibility rows remain for auditable benefit decisions approach likewise erases the timeline housing auditors need, because a nightly rebuild drops prior versions rather than preserving them. The SCD Type 3 so historical eligibility rows remain for auditable benefit decisions approach is also wrong because it preserves only one prior value, not the full sequence of eligibility changes, so it cannot support complete auditable history. Exam caveat: SCD Type 1 so historical eligibility rows remain for auditable benefit decisions still overwrites history in place and fits only attributes where history is intentionally irrelevant; Type 2 preserves history when statutes, appeals, or audits require point-in-time eligibility. Type 2 increases row counts and needs clear current-flag or date-range conventions so analysts do not double-count active apartments. Do not confuse Type 2 history with merely rebuild dimension so historical eligibility rows remain for auditable benefit decisions, which drops prior versions. Operational check: Implement Type 2 on eligibility status with effective start/end dates, or version rows, change a sample apartment's status, confirm the prior row remains queryable for the decision date, run an audit-style point-in-time query that reconstructs past eligibility, and ensure loads never simply use SCD Type 1 so historical eligibility rows remain for auditable benefit decisions or rebuild dimension so historical eligibility rows remain for auditable benefit decisions, since both would lose history.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.