Diagnostics — DWB11-001–017
Use only after answering the matching practice questions.
DWB11-001 — A
Why A: DW/BI is the coordinated planning, implementation and management of an integrated analytical data system supporting reporting, query and analysis.
B loses: transaction recording describes operational processing.
C loses: dashboards without integrated data omit the warehousing foundation.
D loses: infrastructure management is only one enabling concern.
Source: pp. 361–362. · Confusion: DW/BI discipline vs transaction processing/tooling.
DWB11-002 — B
Why B: a Chapter 11 goal is to create insight supporting effective analysis and decisions.
A loses: multiple operational SORs may remain.
C loses: central analytical data does not eliminate governance.
D loses: premature summarization contradicts atomic-detail guidance.
Source: p. 362. · Confusion: program goals vs overreach.
DWB11-003 — C
Why C: integrated history can provide evidence that prior regulatory/reporting obligations were met.
A loses: a warehouse does not automatically certify compliance.
B loses: source controls remain necessary.
D loses: compliance evidence does not universally require streaming.
Source: p. 363. · Confusion: compliance evidence vs automatic compliance.
DWB11-004 — D
Why D: “start with the end in mind” means intended BI delivery/business priority should drive warehouse content.
A loses: the source says summarize/optimize last.
B loses: the principle is the opposite—one size does not fit all.
C loses: staging is an intermediate role, not the end-state principle.
Source: p. 363. · Confusion: end-state BI need vs technology-first design.
DWB11-005 — A
Why A: preserve useful atomic detail; aggregate after requirements/performance needs are understood.
B: important but less specific to the premature aggregation clue.
C: concerns user/tool fit.
D: concerns transparency/access.
Source: pp. 363–364. · Confusion: atomic detail vs premature summarization.
DWB11-006 — B
Why B: Metadata supplies meaning, derivation and provenance needed for trust, and should be captured during development.
A loses: Metadata is far broader than storage sizing.
C loses: mappings are themselves important Metadata/lineage evidence.
D loses: after-production documentation is too late.
Source: pp. 363–364. · Confusion: Metadata-by-design vs after-the-fact documentation.
DWB11-007 — C
Why C: enterprise vision plus incremental business-process releases is exactly “think/design globally; act/build locally.”
A: contradicts summarize-last.
B: concerns user/tool diversity.
D: is a warehouse data property, not delivery strategy.
Source: p. 363. · Confusion: enterprise vision vs incremental delivery.
DWB11-008 — D
Why D: BI denotes both analytical activity and technologies enabling that activity.
A/B/C: pair unrelated operational/storage/organizational concepts rather than the source’s two meanings.
Source: p. 364. · Confusion: BI activity vs BI technology.
DWB11-009 — A
Why A: Inmon’s classic four are subject-oriented, integrated, time-variant, non-volatile.
B/C/D: substitute unrelated design/operational attributes and reverse the historical/non-volatile character.
Source: pp. 365–366. · Confusion: Inmon properties vs unrelated attributes.
DWB11-010 — B
Why B: subject-oriented means organized around major business subjects/entities rather than application/function silos.
A: does not mean only one subject.
C: source table organization is application/source orientation.
D: user exclusivity is unrelated.
Source: p. 365. · Confusion: subject-oriented vs application-oriented.
DWB11-011 — C
Why C: integration reconciles common keys, definitions, codes, names and representations across sources.
A: integrated does not mean summarized.
B: Master/Reference Data often help integration.
D: cube storage is not required for integration.
Source: p. 365. · Confusion: integrated vs copied data.
DWB11-012 — D
Why D: time-variant design preserves historical states/points in time for reproducible queries.
A: subject orientation concerns organization.
B: volatility is opposite the historical stability needed.
C: self-service concerns access.
Source: p. 366. · Confusion: time-variant vs current-state processing.
DWB11-013 — A
Why A: non-volatility means prior historical states are generally preserved rather than repeatedly overwritten like operational records.
B: new loads still occur.
C: not a literal storage-engine read-only requirement.
D: does not imply summary-only storage.
Source: p. 366. · Confusion: non-volatile vs immutable/no-load misunderstanding.
DWB11-014 — B
Why B: ODS = integrated current/near-current, lower latency, shorter history, more volatile than DW.
A: describes deep historical archive/DW behavior.
C: strategic dimensional mart is different.
D: staging is preparation and normally not end-user queried.
Source: p. 366. · Confusion: ODS vs DW vs staging.
DWB11-015 — C
Why C: an OpDM supports tactical current/near-term analysis and is sourced from ODS rather than historical DW.
A: Reference Data is unrelated.
B: it is not the enterprise integration layer.
D: it is not staging.
Source: p. 366. · Confusion: OpDM vs historical data mart.
DWB11-016 — D
Why D: Kimball structures transaction/process data dimensionally for query and analysis.
A: central normalized warehouse first is an Inmon clue.
B: no-history operational store is ODS-like, not Kimball warehouse.
C: raw files queried directly omit dimensional integration.
Source: p. 368. · Confusion: Kimball dimensional approach vs Inmon/operational/raw.
DWB11-017 — A
Why A: facts hold quantitative process measures; dimensions supply descriptive context.
B/D: invent unrelated roles.
C: analytical role, not numeric/text datatype, determines fact vs dimension.
Source: p. 368. · Confusion: fact vs dimension.