Data Warehouse Architecture and Design: A Reflective Guide


Data Warehouse Architecture and Design: A Reflective Guide

What is Data Modeling and Why Do You Need It?

Having worked in data-driven organizations make you observe the significant amounts of data that are produced every day within the systems. This data needs to be combined and stored on a single platform, which can be used for business intelligence, analytics, reporting, and decision-making by many divisions within a firm. In contrast to past times, data now comes in many different formats and from several platforms or sources. In order to transform the data into useful information, it must be carefully integrated into a common platform called a data warehouse.

If you are designing a data warehouse for your company, this guide will help you achieve that with a few simple steps.

What is a Data Warehouse?

A warehouse of something is generally a space where you store large amounts of it in an organized fashion. And that is what a data warehouse is - a space to store a large amount of data.

A data warehouse is a centralized server/location where you store massive amounts of data sourced from different channels for analytics purposes. The practice has become essential among businesses given the increasing reliance on data to make business decisions.

Characteristics of a Data Warehouse

You can identify a data warehouse using the following characteristics –

  1. Concept-oriented: Data warehouse presents information on a specific subject like inventory, etc., rather than talking about the operations. So, it gives you access to data around a particular theme, using which you can make business decisions and run operations.
  2. Time-variant: Data in a warehouse gets organized w.r.t time intervals. It could be daily, weekly, monthly, or yearly. Another aspect is that the data you store at a particular time cannot be altered later.
  3. Non-Volatile: Past data is stored in the records for future references. Thus, there is no immediate deletion once new data comes in. This property of a data warehouse is called non-volatility.
  4. Integrated: Data from various sources gets integrated into one shared entity that facilitates consistency and reliability. Implementation of common conventions, formats, and codes makes it easier to structure, handle, and analyze data.

Data Warehouse supported functions

  • Data Consolidation – The data needs to be collected & consolidated from different data sources. Data consolidation is the combining, corralling, and storing of assorted data in a single place.
  • Data Cleaning – It is a process of removing corrupted, duplicate, and incorrectly formatted data within the data set.
  • Data Transformation – Once you have cleaned your data, you transform it into a format suitable for data storage and operations.
  • Data Loading – The next logical step is to load this data into your warehouse. Hence, every data warehouse must support data loading.
  • Data Updating – You must keep data updated with time. Thus, this is another functionality that a data warehouse cannot do without.

The architecture of a Data Warehouse

There are three types of data architectures that organizations can scope for their requirements.

  1. Single-layer architecture
  2. Two-layer architecture
  3. Three-layer architecture

Let us look at how each is different from the other.

1. Single Layer Architecture

In a single-layer architecture, there is only one layer, i.e., the source layer. This layer represents the primary data sources and interfaces directly with the data warehouse layer. This architecture is essentially opted for by very early age startups/ businesses who have not organized their data operations for scaling. This architecture is not a recommended way of designing your warehouse.

In this architecture, the source layer delivers all the data directly to the warehouse. Result? It removes data redundancies. However, this approach is more error-prone, causing efficiency issues in the long run.

The source layer could be your legacy databases, any customer communication, and relationship management channels, or any other source connected to your business's information systems. The client layer of the system interacts with the Data warehouse directly for all query processing, data mining, reporting, and analytics.

Single Layer Architecture

2. Two-layer architecture

Although it is frequently referred to as two-layer architecture to highlight a division between physically accessible sources and data warehouses, in reality, it consists of four consecutive stages of data flow, i.e., source layer, data staging, data warehouse, and analysis. With a staging layer, data does not go directly from the data sources into the warehouse. Instead, It is cleansed and unified here so that only high-quality data gets stored in the data warehouse.

After the staging layer, this data moves to the data warehouse layer, where it reaches ready for BI operations. With the frontend reporting tools, you can thoroughly analyze this data to draw conclusions.

Two-layer Architecture

3. Three-layer architecture

When you adopt the three-layer architecture, you add an additional layer before the data finally gets to the warehouse. That layer is the Data Reconciliation layer. Data to this layer comes from the staging layer.

The Data reconciliation layer ensures that no error creeps in due to mapping or transformation mistakes. It avoids discrepancies like missing records, incorrect values, broken relationships across tables, etc. It creates a standardized reference data model for the whole enterprise. However, you need extra storage space for the additional layer introduced.

Additionally, the data warehouse supports division and organization into data marts. Data marts are specialized databases for each department within an organization. So, the sales division can have its own data mart, while the Finance department gets its own. This approach improves the operational efficiency of your database. Data marts can be introduced to single and two-layer architectures as well.

Three-layer architecture

How to Design a Data Warehouse?

When it comes to data warehousing, there is no one-size-fits-all approach. The design should be according to your business requirements.

Some questions that you might want to ask yourself are –

  1. What kind of data do we store?
  2. What are our data sources?
  3. What operations do we run on this data?
  4. What type of data organization suits our business objectives & operations?
  5. Is there any compliance risk?
  6. How to keep our data secure from loss and cyber threats?

Once you answer these questions, a picture should emerge in front of you that will act as a catalyst to help you in designing a data warehouse.

In this process, you decide upon hardware specifications, staff training requirements, data sources, and a project plan.

1. Collect what you need

To set up the environment, you must gather your requirements right. The first thing is to gauge the required throughput accurately. Once you know what you need, you can start collecting the resources.

What would be your peak load? What would be your general load? Once you have sized that requirement, that is when you can start preparing your environment. It will help you quantify your hardware requirements like the number and power of CPUs, required memory, bandwidth, and disks.

A rough estimate for the number of CPUs could be arrived at using the formula – #CPUs = Max required throughput/200

Similar best practices and general formulas can be used as a general guideline to decide on other requirements.

Additionally, your physical environment needs development, testing, and production units to facilitate proper warehousing. And these units need to be separate from each other. This approach ensures data integrity, increased resource availability, better testing, and efficient production.

2. Database setup for data warehouse

Before building a warehouse, you need to have a blueprint of what goes where. Data modeling helps you visualize the organization of your data.

However, data modeling typically takes place at the level of data marts. Data marts are specialized databases that concern a specific department of your organization. All the design decisions happen at this level.

The first step usually is to define the user requirements and then move towards the implementation part of the data warehouse. The implementation involves choosing the schema and setting up other parameters defining the rules and resources available. In simple words, you create data definitions in this step.

3. Defining ETL

Now that you have completed the last step, you need to define the ETL (Extract, Transfer, Load) logic that you will employ for your warehouse.

Mappings are visualizations of the processes of how data is extracted and transformed between sources and targets. You can use operators to define data sources, targets, and transformations in these mappings.

As your ETL processes will have a long-term effect on the performance of your warehouse, your definitions must be nothing short of optimal.

Here is what ETL means –

  • Extract – Extract data from its source.
  • Transform – Transform into a suitable format.
  • Load – Load it into the data warehouse.
  • Data Analysis

As per the business requirements, multiple data points are essential to track. That is why you will be collecting data from numerous sources in a single place. However, that might make it hard to organize and analyze such data if not done optimally. That is where OLAP data cubes come in.

An OLAP data cube is a multi-dimensional data structure having its primary application as a Business Intelligence enabler. Data from your warehouse gets sent to these data cubes for efficient analysis.

4. Frontend and Reporting

The frontend is just as important as the backend. A good visualization tool (like Tableau) can help your end-users interact with data with ease. The next part of visualization is report generation. During analysis, the end-users can generate reports, facilitating them to draw conclusions about business data.

Your business reports –

  • Must be customizable.
  • Should be easily accessible through multiple channels.
  • Should have restricted access based on authority.

Data Warehouse Design Best Practices

Data warehousing is an ongoing process. And to get the best out of it, it is prudent for you to follow the industry best practices. Here are a few suggestions for you to get started.

1. Don’t skip the initial work – The initial work while designing your warehouse might seem intimidating and useless, but it is quite the opposite. One should not go jumping right into the implementation part. Be methodical to ensure that your warehouse design solves the business problem you wish to address.

2. Data Quality – You must have proper standards & systems in place to ensure data quality in your organization. Your business might suffer eventual losses if you collect data that does not present you with the complete picture.

3. Query Optimization – Sub-optimally designed systems lead to SQL queries running into performance issues. You might face problems like slowing servers, obsolete data, etc. Some recommendations are – 1) Mirror resources for development, testing, and production. 2) Be specific while running your select queries.

4. Avoiding System Overloads – You should employ Database Diagnostic monitoring to prevent system overload by monitoring system performance and resource availability.

5. Performance Monitoring – You should monitor performance using various statistics. You can improve your warehouse performance using partitioning optimization (Partitioning pruning & Partition-wise joins), Query rewrites, indexes, and data compression.

6. Use resources optimally – You can use resources optimally via parallel processing of the queries.

7. Efficient Integrity Checks – They are resource-intensive thus checks should happen at the source of data instead of the data warehouse.

8. Backup your warehouse data – It becomes essential to successfully back up your warehouse data so that you can recover it later in case of a loss. As a data warehouse contains a massive amount of data, it becomes crucial that you have a backup strategy and design your system accordingly. You must prioritize what to back up and the frequency of such backups. Archive logs, recovery managers, etc., can be helpful.

9. Determine the acceptable standard – As an organization, you should be clear about your database standards in line with your business objectives.

10. Research and experiment with the agile approach in your warehouse design and development.

11. Use a data integration layer for better collation and data reporting to enable your business decisions.


Data Warehouse design is an evolving field. As data requirements of the organizations keep evolving, so will their design schemas and the corresponding best practices. Thus, in addition to what you have read here, it is suggested that you keep an eye on the evolving technologies that revolutionize the way we store and access data.

Follow Us!

Brought to you by DASCA
Brought to you by DASCA

Stay Updated!

Keep up with the latest in Data Science with the DASCA newsletter.


This website uses cookies to enhance website functionalities and improve your online experience. By browsing this website, you agree to the use of cookies as outlined in our privacy policy.

Got it