Diagnostics — DWB11-035–051
DWB11-035 — C
Why C: DW/BI architecture describes source, destination, timing, rationale, movement and enabling environment—not merely hardware.
A: server inventory is only part of physical implementation.
B: report layouts are BI presentation.
D: a source dictionary is Metadata, not the full architecture.
Source: p. 374. · Confusion: architecture vs hardware/report-only views.
DWB11-036 — D
Why D: link-back mechanisms can give analysts access to operational detail without forcing the warehouse to persist every non-analytical field.
A: Chapter 11 explicitly values useful atomic warehouse data.
B: operational systems and warehouse serve different purposes.
C: BI can display history; that is not the issue.
Source: pp. 374–375. · Confusion: analytical detail vs operational-detail access.
DWB11-037 — A
Why A: the named concurrent tracks are Data, Technology, and BI tools/delivery.
B/C/D: useful concepts perhaps, but not the source’s three development tracks.
Source: pp. 375–376. · Confusion: three development tracks.
DWB11-038 — B
Why B: source-to-target mapping documents source/target equivalence and transformation rules while establishing lineage back to sources.
A: formatting is presentation.
C: mapping documents rules but does not replace defect remediation.
D: licensing is BI administration.
Source: p. 376. · Confusion: mapping vs remediation/tool administration.
DWB11-039 — C
Why C: a shared taxonomy/logical model provides enterprise semantics for reconciling differently named/structured source elements.
A: semantics do not guarantee data accuracy.
B: transformation rules are still needed.
D: logical taxonomy is not a performance setting.
Source: p. 376. · Confusion: semantic mapping vs quality/performance.
DWB11-040 — D
Why D: invalid state codes require remediation/cleansing—correcting/standardizing defective values.
A: BI portfolio delivers analytical capabilities.
B: release management governs delivery lifecycle.
C: coverage measures breadth, not value correctness.
Source: p. 376. · Confusion: remediation vs BI/release/metrics.
DWB11-041 — A
Why A: transformation executes intended integration/business conversions; remediation fixes or standardizes problematic data.
B/C/D: confuse these data-handling activities with metrics/report types or erase a source distinction.
Source: p. 376. · Confusion: transformation vs remediation.
DWB11-042 — B
Why B: provisional dimension member + later reconciliation is optimistic loading.
A: pessimistic handling waits/recycles.
C: historical reload is unrelated.
D: reporting fallback is not a load-integrity method.
Source: p. 376. · Confusion: optimistic vs pessimistic loading.
DWB11-043 — C
Why C: when placeholders are prohibited, retain the unresolved fact in a controlled recycle/reject process, alert, fix the dependency, then reload.
A: silently losing data violates control/auditability.
B: random key invents invalid identity.
D: reporting is not an exception-handling strategy.
Source: p. 376. · Confusion: pessimistic recycle vs data loss/provisional key.
DWB11-044 — D
Why D: population is a broad operating design involving latency, sources, batch windows, target needs, time consistency, DQ, transform time, late dimensions and rejects.
A/B/C: each narrows the problem to one unrelated concern.
Source: pp. 376–377. · Confusion: population design vs infrastructure/report-only.
DWB11-045 — A
Why A: user communities should be grouped by analytical/operational needs and matched to appropriate BI capabilities.
B/C/D: data architecture/load changes do not solve an interface/user-fit problem.
Source: pp. 377–378. · Confusion: BI user segmentation vs data architecture.
DWB11-046 — B
Why B: standard releases make warehouse enhancement predictable, proactively resourced and product-oriented.
A: warehouse continues evolving.
C: releases do not replace acceptance testing.
D: business priority remains essential.
Source: pp. 378–379. · Confusion: release plan vs freeze/reactive support.
DWB11-047 — C
Why C: a successful sandbox must still pass pilot evaluation and business+IT production-readiness gates including DQ/governance.
A/B: bypass readiness and controlled promotion.
D: analytics does not exempt DQ.
Source: pp. 379–380. · Confusion: pilot vs production.
DWB11-048 — D
Why D: usage evidence should prioritize high-impact tuning; indexes, aggregates/precomputation or query redesign can be justified by actual workload.
A: unused queries have low value.
B: disabling monitoring removes evidence.
C: operational DB substitution ignores analytical purpose.
Source: p. 380. · Confusion: usage-driven tuning vs guesswork.
DWB11-049 — A
Why A: large estates have many tools/versions; an integrated Metadata repository stitches their descriptions together for end-to-end understanding, trust and impact analysis.
B: Metadata repository is not the warehouse data store.
C: it complements, not replaces, models.
D: governance remains necessary.
Source: p. 381. · Confusion: Metadata repository vs data store/model/governance.
DWB11-050 — B
Why B: dictionary/glossary explains data in business terms and supplies context required for correct use.
A: server configuration is technical operations.
C: CDC scheduling is integration.
D: coverage is a metric.
Source: pp. 381–382. · Confusion: dictionary/glossary vs operations/metrics.
DWB11-051 — C
Why C: lineage is the direct capability for tracing metric origin and transformations.
A: usage measures adoption.
B: BPM manages strategic metrics, not provenance.
D: OLAP aggregates/explores data, not origin paths.
Source: p. 382. · Confusion: lineage vs usage/BPM/OLAP.