A general data warehouse architecture provides a structured framework for collecting, storing, managing, and analyzing data to support decision-making. This architecture is typically organized into four main tiers: the back-end tier, the data warehouse tier, the OLAP tier, and the front-end tier. Each tier has specific responsibilities, and together they form an integrated environment for business intelligence and analytics. 

The back-end tier is responsible for preparing data before it enters the data warehouse. Its central process is ETL, which stands for extraction, transformation, and loading. During extraction, data is gathered from multiple and often heterogeneous sources. These sources may include operational databases, files in different formats, or even external systems. To ensure interoperability, standard interfaces such as ODBC and JDBC are often used. In the transformation step, extracted data is converted into a format suitable for the data warehouse. This involves cleaning the data to remove errors and inconsistencies, integrating data from different sources to ensure consistency at both the schema and data levels, and aggregating data according to the granularity required by the warehouse. The final step, loading, transfers the transformed data into the data warehouse. Loading also includes refreshing the warehouse at defined intervals so that it contains up-to-date information. Refresh frequencies may range from monthly to near real time, depending on organizational needs. ETL processes usually rely on a data staging area, often called an operational data store, where intermediate transformations are performed before final loading. 

The data warehouse tier contains the central storage structures of the architecture. It may include an enterprise data warehouse and one or more data marts. An enterprise data warehouse is a centralized repository covering the entire organization, while a data mart is a smaller, specialized warehouse focused on a specific department or function. Data marts may derive their data from the enterprise warehouse or directly from operational sources. Another critical component of this tier is the metadata repository. Metadata, or “data about data,” provides essential information for understanding and managing the warehouse. Business metadata describes the meaning of data and the business rules associated with it, while technical metadata explains how data is structured, stored, and processed. Metadata may describe warehouse schemas, facts, dimensions, hierarchies, indexes, partitions, security rules, usage statistics, and error logs. It also documents source systems and ETL processes, including data lineage, transformation rules, refresh schedules, and summarization algorithms. 

The OLAP tier provides multidimensional analytical capabilities. It typically consists of an OLAP server that presents users with a multidimensional view of data stored in the warehouse or data marts. OLAP systems enable users to explore data through operations such as slicing, dicing, drill-down, and roll-up. Although many database systems offer OLAP features, there is no single standardized language for cube manipulation. However, several important languages exist. XMLA supports data exchange between OLAP clients and servers. MDX is a widely used query language for OLAP databases and has become a de facto standard. SQL has also been extended with analytical capabilities through SQL/OLAP. The OLAP tier plays a crucial role in translating stored data into forms suitable for complex analytical queries. 

The front-end tier consists of tools that allow users to interact with the data warehouse. These client tools include OLAP tools for interactive data exploration and ad hoc querying, reporting tools for generating regular or on-demand reports, statistical tools for advanced data analysis and visualization, and data mining tools for discovering patterns, trends, and predictive insights. Modern reporting environments often include dashboards and key performance indicators (KPIs) to provide summarized views of business performance. 

In practice, variations of this architecture exist. Some organizations may have only an enterprise data warehouse without data marts, while others may rely solely on independent data marts. Building an enterprise warehouse is complex and costly, but relying only on separate data marts can create integration challenges later. In some environments, an OLAP server may be absent, and client tools may directly query the data warehouse. An extreme variation is the virtual data warehouse, which consists of views over operational databases rather than a physical warehouse. Although easier to implement, virtual warehouses lack historical data, centralized metadata, and data cleaning capabilities, and they may negatively affect operational system performance. In rare cases, a staging area may not be required if source data closely matches warehouse requirements, but this situation is uncommon in real-world systems. 

Overall, data warehouse architecture provides a layered, systematic approach to integrating diverse data sources, storing consolidated and historical data, and enabling advanced analytical processing. Each tier contributes to transforming raw operational data into meaningful information for decision support, making the architecture fundamental to modern business intelligence systems. 

Reference: 

Vaisman, A., & Zimányi, E. (2014). Data warehouse systems: Design and implementation. Springer.