Lesson 1 — BI, Data Warehouse, Data Warehousing & Principles
Three related ideas that are not synonyms
Business Intelligence (BI) is the analytical activity of understanding organizational performance, activity, opportunity, and risk—and also the technologies that enable reporting, querying, visualization, analysis, mining, and related work.
A Data Warehouse (DW) is the integrated analytical environment/store that provides durable, historically useful data for that work.
Data Warehousing is the continuing set of processes that create and sustain that environment: collect, profile, cleanse, transform, integrate, load, control, document, monitor, and maintain the data.
A dashboard is therefore not “the warehouse.” A large operational database is not a warehouse just because it is old. An ETL pipeline is not the entire warehousing discipline.
Why the distinction matters
Imagine an order application. Its job is to accept a new order, update status, check inventory, take payment, and show the current operational state. Those are transaction-execution needs.
Management asks different questions: Which product families grew over three years? Did fulfillment performance change after a policy? Can last quarter’s regulatory report be reproduced exactly? Those questions require integrated definitions and history that operational applications are not designed primarily to preserve.
Program goals
The current Chapter 11 package reduces the program purpose to two broad outcomes: 1. build and maintain an integrated analytical data environment; and 2. enable reliable insight and better analysis/decision-making from it.
Compliance and operational analysis can also consume the warehouse, so “DW exists only for dashboards” is too narrow.
Eight guiding principles
Use these as reasoning rules rather than slogans:
- Focus on business goals. Start from decisions and outcomes, not products.
- Start with the end in mind. Intended analytical delivery should shape the warehouse content.
- Think/design globally; act/build locally. Keep an enterprise direction while delivering increments.
- Summarize and optimize last. Preserve useful atomic detail before locking the design into aggregates.
- Promote transparency and self-service. Users should be able to understand and appropriately explore trusted data.
- Build Metadata with the warehouse. Meaning and provenance are not after-the-fact documentation.
- Collaborate across disciplines. DW/BI depends on business, data, architecture, integration, operations, governance, and support.
- One size does not fit all. Different users, decisions, and latency needs require different stores and analytical tools.
Atomic detail: why “summarize later” matters
Suppose raw sales detail contains each order line. A monthly total can always be derived later. If the order lines are discarded first, you cannot later answer a new question about product mix, customer segment, sequence, or exception without returning to sources and reconstructing history.
Atomic does not mean “store every useless operational field forever.” It means preserve the lowest useful analytical grain required for flexible future analysis, audit, reconstruction, and downstream aggregation.
Stop and check
1. Why is a large operational database not automatically a warehouse? Because purpose and behavior matter: operational systems execute current transactions; warehouses integrate analytical data and preserve useful history.
2. Why build Metadata with the warehouse? Because users need definitions, calculations, source relationships, rules, and provenance to trust what they analyze. Reconstructing that evidence later is expensive and incomplete.
Source anchor: pp. 361–364.