Business Intelligence Components: The 8 Building Blocks, Explained with an Example

The big picture

Think of BI as a pipeline with controls running along it:

Sources → Integration → Storage → Modeling → Analytics engine → Reports and dashboards → Decisions

Along the whole chain sit governance, metadata and security, and the people who build and use it. If one link is weak, the dashboards at the end are wrong, slow or ignored. For the wider context, see what big data is, and for a health-sector view, business intelligence in healthcare.

Terms differ between vendors and textbooks, and there is no single official list of BI components. The eight below are our way of organizing the common ones.

The 8 components at a glance

1–2: Data sources and integration (ETL and ELT)

Data sources are the operational systems that run the business: point-of-sale, accounting, customer records, websites and spreadsheets. They are built to record transactions quickly, not to answer questions about trends, so BI copies the data elsewhere rather than querying them directly. See how companies collect data.

Data integration moves the data. AWS describes ETL (extract, transform, load) as combining data from multiple sources into a central repository such as a data warehouse, in three stages:

1. Extract: pull raw data from the sources into a staging area.
2. Transform: clean and reshape it, for example by removing errors and duplicates, standardizing formats, joining datasets and summarizing.
3. Load: move the result into the target warehouse, as a full load or as incremental changes.

ELT reverses the last two steps: load first, transform afterwards. AWS says ELT suits high-volume, unstructured data and has become common with cloud infrastructure, while ETL requires more definition at the start, because target structures must be planned up front.

3: Storage: warehouse, lake and mart

The same AWS page, comparing data warehouses, data lakes and data marts, gives these definitions. The table summarizes them in our words.

AWS notes that most large organizations combine all three: data lands in a lake, then is loaded into warehouses and marts for specific uses. A smaller organization can often start with a single warehouse or even a well-organized database.

4–5: Data modeling and the analytics engine

Data modeling arranges data so that people can ask business questions without understanding every source system. The most common pattern in warehouses is a star schema:

• A central fact table holds the measurable events, such as one row per sale with units, revenue and cost.
• Surrounding dimension tables describe them: date, product, store, customer.

A good model also fixes the definitions. “Revenue,” “active customer” and “margin” should mean one thing everywhere. This is the semantic layer, and it is where metadata does its work; see why metadata matters.

The analytics engine is what runs the questions. It reads large amounts of data to find patterns and totals, which is a different job from recording a single transaction. It supports slicing by dimension (sales by store, then by month, then by product), drilling down and filtering. Predictive methods build on the same foundation; see predictive analytics in healthcare.

6: Reports and dashboards

This is the layer most people see. Common formats are:

• Operational reports: regular, detailed lists, such as yesterday’s orders.
• Dashboards: a screen of key measures with targets and trends.
• Ad hoc analysis: a user explores the data to answer a one-off question.
• Alerts: a message when a measure crosses a threshold.

Examples of tools in this layer include Power BI, Tableau and Looker. They are examples, not recommendations, and the choice matters less than the model and definitions underneath.

A good dashboard serves one decision, shows a small number of measures, defines each one, and compares it with a target or a prior period.

7–8: Governance, metadata, security and people

These two components run alongside everything else.

• Governance: who owns each data set, who approves definitions, how quality is checked, and who may see what.
• Metadata: the descriptions of data, such as source, meaning, owner and refresh time. A data dictionary or catalog makes it searchable.
• Security and privacy: role-based access, protection of personal data and a record of who used what.
• People and process: a BI system only changes outcomes if someone owns each measure and acts on it. Training, support and a clear request process matter as much as software.

A worked example

The data below is made up. A small retail chain has two stores, A and B, selling coffee beans and mugs. Each sale is recorded in the point-of-sale system (component 1). The nightly integration job (2) loads it into a warehouse (3), where a star schema (4) holds one fact table of sales and dimensions for store, product and date. The engine (5) totals it, and a dashboard (6) shows the result.

The fact table for one day (revenue and cost in dollars):

What the dashboard calculates (gross margin = (revenue − cost) ÷ revenue):

The insight. Both stores sold $570. Store B earned more because it sold more mugs, which have a higher margin than beans. The difference is product mix, not store performance. A manager who saw only revenue would have missed it, and one who saw only the margin might wrongly blame Store A’s staff. That is the value of a model that lets you slice by product and store, and of agreed definitions so “margin” means the same thing in every report.

The action. Try moving the mug display to a more visible place in Store A, and check the margin again next month.

Common problems

• Conflicting numbers. Two reports show different “revenue” because definitions differ. Fix the definition in the model.
• Dirty source data. Duplicates and missing values flow straight through unless the integration step catches them.
• Everything in the dashboard. Too many measures hide the one that matters.
• Slow queries. Poor modeling or too much detail loaded into the wrong place.
• No owner. Reports pile up, nobody maintains them and trust fades.
• Building the lake first. Collecting everything before knowing the questions often produces an unused swamp.
• Ignoring privacy. Personal data needs access controls from the start.

How to start small

1. Pick one decision and the three measures that inform it.
2. Write the definitions in plain words.
3. Find the source data and check a sample for errors.
4. Build one clean table for the facts and a few for the dimensions, even in a spreadsheet.
5. Make one dashboard and show it to the people who will use it.
6. Agree an owner and a review date, then grow from there.

To build the skills, see our business intelligence certificate guide. Providers such as Coursera and Udemy list BI courses. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. More guides are in the business intelligence hub.

Frequently asked questions

What are the main components of business intelligence?

Data sources, data integration (ETL or ELT), storage (warehouse, lake, marts), data modeling, an analytics engine, reports and dashboards, governance with metadata and security, and the people and processes that use them.

What is the difference between ETL and ELT?

ETL transforms data before loading it into the target. ELT loads it first and transforms it afterwards. AWS says ELT suits high-volume, unstructured data and is common in the cloud.

What is the difference between a data warehouse and a data lake?

A warehouse holds curated, structured data for BI. A lake holds raw data of many types, to be processed when needed.

What is a data mart?

A data warehouse scoped to one business unit, such as finance or marketing.

What is a star schema?

A way of modeling data with a central fact table of measurable events surrounded by dimension tables that describe them.

Do small businesses need all eight components?

Not at full scale. They still need clean data, agreed definitions and a clear view of the decisions they support, which can be done with modest tools.