ⓘ Data warehouse
In computing, a data warehouse, also known as an enterprise data warehouse, is a system used for reporting and data analysis, and is considered a core component of business intelligence. DWs are central repositories of integrated data from one or more disparate sources. They store current and historical data in one single place that are used for creating analytical reports for workers throughout the enterprise.
The data stored in the warehouse is uploaded from the operational systems such as marketing or sales. The data may pass through an operational data store and may require data cleansing for additional operations to ensure data quality before it is used in the DW for reporting.
Extract, transform, load ETL and extract, load, transform E-LT are the two main approaches used to build a data warehouse system.
ELT based data warehousing gets rid of a separate ETL tool for data transformation. Instead, it maintains a staging area inside the data warehouse itself. In this approach, data gets extracted from heterogeneous source systems and are then directly loaded into the data warehouse, before any transformation occurs. All necessary transformations are then handled inside the data warehouse itself. Finally, the manipulated data gets loaded into target tables in the same data warehouse.
A data warehouse maintains a copy of information from the source transaction systems. This architectural complexity provides the opportunity to:
- Organize and disambiguate repetitive data
- Mitigate the problem of database isolation level lock contention in transaction processing systems caused by attempts to run large, long-running, analysis queries in transaction processing databases.
- Add value to operational business applications, notably customer relationship management CRM systems.
- Present the organizations information consistently.
- Integrate data from multiple source systems, enabling a central view across the enterprise. This benefit is always valuable, but particularly so when the organization has grown by merger.
- Restructure the data so that it delivers excellent query performance, even for complex analytic queries, without impacting the operational systems.
- Restructure the data so that it makes sense to the business users.
- Integrate data from multiple sources into a single database and data model. More congregation of data to single database so a single query engine can be used to present data in an ODS.
- Provide a single common data model for all data of interest regardless of the datas source.
- Improve data quality, by providing consistent codes and descriptions, flagging or even fixing bad data.
- Make decision–support queries easier to write.
- Maintain data history, even if the source transaction systems do not.
The environment for data warehouses and marts includes the following:
- Different tools and applications for the variety of users;
- Source systems that provide data to the warehouse or mart;
- Different architectures for storing data in an organizations data warehouse or data marts;
- Data integration technology and processes that are needed to prepare the data for use;
- Metadata, data quality, and governance processes must be in place to ensure that the warehouse or mart meets its purposes.
In regards to source systems listed above, R. Kelly Rainer states, "A common source for the data in data warehouses is the companys operational databases, which can be relational databases".
Regarding data integration, Rainer states, "It is necessary to extract data from source systems, transform them, and load them into a data mart or warehouse".
Rainer discusses storing data in an organizations data warehouse or data marts.
Metadata is data about data. "IT personnel need information about data sources; database, table, and column names; refresh schedules; and data usage measures".
Today, the most successful companies are those that can respond quickly and flexibly to market changes and opportunities. A key to this response is the effective and efficient use of data and information by analysts and managers. A "data warehouse" is a repository of historical data that is organized by subject to support decision makers in the organization. Once data is stored in a data mart or warehouse, it can be accessed.
3. Related systems
A data mart is a simple form of a data warehouse that is focused on a single subject or functional area, hence they draw data from a limited number of sources such as sales, finance or marketing. Data marts are often built and controlled by a single department within an organization. The sources could be internal operational systems, a central data warehouse, or external data. Denormalization is the norm for data modeling techniques in this system. Given that data marts generally cover only a subset of the data contained in a data warehouse, they are often easier and faster to implement.
Types of data marts include dependent, independent, and hybrid data marts.
Online analytical processing OLAP is characterized by a relatively low volume of transactions. Queries are often very complex and involve aggregations. For OLAP systems, response time is an effectiveness measure. OLAP applications are widely used by Data Mining techniques. OLAP databases store aggregated, historical data in multi-dimensional schemas usually star schemas. OLAP systems typically have data latency of a few hours, as opposed to data marts, where latency is expected to be closer to one day. The OLAP approach is used to analyze multidimensional data from multiple sources and perspectives. The three basic operations in OLAP are: Roll-up Consolidation, Drill-down and Slicing & Dicing.
Online transaction processing OLTP is characterized by a large number of short on-line transactions. OLTP systems emphasize very fast query processing and maintaining data integrity in multi-access environments. For OLTP systems, effectiveness is measured by the number of transactions per second. OLTP databases contain detailed and current data. The schema used to store transactional databases is the entity model usually 3NF. Normalization is the norm for data modeling techniques in this system.
Predictive analytics is about finding and quantifying hidden patterns in the data using complex mathematical models that can be used to predict future outcomes. Predictive analysis is different from OLAP in that OLAP focuses on historical data analysis and is reactive in nature, while predictive analysis focuses on the future. These systems are also used for customer relationship management CRM.
The concept of data warehousing dates back to the late 1980s when IBM researchers Barry Devlin and Paul Murphy developed the "business data warehouse". In essence, the data warehousing concept was intended to provide an architectural model for the flow of data from operational systems to decision support environments. The concept attempted to address the various problems associated with this flow, mainly the high costs associated with it. In the absence of a data warehousing architecture, an enormous amount of redundancy was required to support multiple decision support environments. In larger corporations, it was typical for multiple decision support environments to operate independently. Though each environment served different users, they often required much of the same stored data. The process of gathering, cleaning and integrating data from various sources, usually from long-term existing operational systems usually referred to as legacy systems, was typically in part replicated for each environment. Moreover, the operational systems were frequently reexamined as new decision support requirements emerged. Often new requirements necessitated gathering, cleaning and integrating new data from "data marts" that was tailored for ready access by users.
Key developments in early years of data warehousing:
- 1975 – Sperry Univac introduces MAPPER is a database management and reporting system that includes the worlds first 4GL. It is the first platform designed for building Information Centers a forerunner of contemporary data warehouse technology.
- 1991 – Prism Solutions, founded by Bill Inmon, introduces Prism Warehouse Manager, software for developing a data warehouse.
- 1984 – Metaphor Computer Systems, founded by David Liddle and Don Massaro, releases a hardware/software package and GUI for business users to create a database management and analytic system.
- 1988 – Barry Devlin and Paul Murphy publish the article An architecture for a business and information system where they introduce the term "business data warehouse".
- 1970s – Bill Inmon begins to define and discuss the term Data Warehouse.
- 1960s – General Mills and Dartmouth College, in a joint research project, develop the terms dimensions and facts.
- 1983 – Teradata introduces the DBC/1012 database computer specifically designed for decision support.
- 1995 – The Data Warehousing Institute, a for-profit organization that promotes data warehousing, is founded.
- 1985 - Sperry Corporation publishes an article Martyn Jones and Philip Newman on information centers, where they introduce the term MAPPER data warehouse in the context of information centers.
- 1990 – Red Brick Systems, founded by Ralph Kimball, introduces Red Brick Warehouse, a database management system specifically for data warehousing.
- 2000 – Dan Linstedt releases in the public domain the Data vault modeling conceived in 1990 as an alternative to Inmon and Kimball to provide long-term historical storage of data coming in from multiple operational systems, with emphasis on tracing, auditing and resiliance to change of the source data model.
- 2012 – Bill Inmon develops and makes public technology known as "textual disambiguation". Textual disambiguation applies context to raw text and reformats the raw text and context into a standard data base format. Once raw text is passed through textual disambiguation, it can easily and efficiently be accessed and analyzed by standard business intelligence technology. Textual disambiguation is accomplished through the execution of textual ETL. Textual disambiguation is useful wherever raw text is found, such as in documents, Hadoop, email, and so forth.
- 1992 – Bill Inmon publishes the book Building the Data Warehouse.
- 1970s – ACNielsen and IRI provide dimensional data marts for retail sales.
- 1996 – Ralph Kimball publishes the book The Data Warehouse Toolkit.
5.1. Information storage Facts
A fact is a value, or measurement, which represents a fact about the managed entity or system.
Facts, as reported by the reporting entity, are said to be at raw level; e.g., in a mobile telephone system, if a BTS base transceiver station receives 1.000 requests for traffic channel allocation, allocates for 820, and rejects the remaining, it would report three facts or measurements to a management system:
- tch_req_fail = 180
- tch_req_success = 820
- tch_req_total = 1000
Facts at the raw level are further aggregated to higher levels in various dimensions to extract more service or business-relevant information from it. These are called aggregates or summaries or aggregated facts.
For instance, if there are three BTS in a city, then the facts above can be aggregated from the BTS to the city level in the network dimension. For example:
- tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3
- avg_tch_req_success_city = tch_req_success_bts1 + tch_req_success_bts2 + tch_req_success_bts3 / 3
5.2. Information storage Dimensional versus normalized approach for storage of data
There are three or more leading approaches to storing data in a data warehouse - the most important approaches are the dimensional approach and the normalized approach.
The dimensional approach refers to Ralph Kimballs approach in which it is stated that the data warehouse should be modeled using a Dimensional Model/star schema. The normalized approach, also called the 3NF model Third Normal Form refers to Bill Inmons approach in which it is stated that the data warehouse should be modeled using an E-R model/normalized model.
5.3. Information storage Dimensional approach
In a dimensional approach, transaction data are partitioned into "facts", which are generally numeric transaction data, and "dimensions", which are the reference information that gives context to the facts. For example, a sales transaction can be broken up into facts such as the number of products ordered and the total price paid for the products, and into dimensions such as order date, customer name, product number, order ship-to and bill-to locations, and salesperson responsible for receiving the order.
A key advantage of a dimensional approach is that the data warehouse is easier for the user to understand and to use. Also, the retrieval of data from the data warehouse tends to operate very quickly. Dimensional structures are easy to understand for business users, because the structure is divided into measurements/facts and context/dimensions. Facts are related to the organizations business processes and operational system whereas the dimensions surrounding them contain context about the measurement Kimball, Ralph 2008. Another advantage offered by dimensional model is that it does not involve a relational database every time. Thus, this type of modeling technique is very useful for end-user queries in data warehouse.
The model of facts and dimensions can also be understood as a data cube. Where the dimensions are the categorical coordinates in a multi-dimensional cube, while the fact is a value corresponding to the coordinates.
The main disadvantages of the dimensional approach are the following:
- It is difficult to modify the data warehouse structure if the organization adopting the dimensional approach changes the way in which it does business.
- To maintain the integrity of facts and dimensions, loading the data warehouse with data from different operational systems is complicated.
5.4. Information storage Normalized approach
In the normalized approach, the data in the data warehouse are stored following, to a degree, database normalization rules. Tables are grouped together by subject areas that reflect general data categories. The normalized structure divides data into entities, which creates several tables in a relational database. When applied in large enterprises the result is dozens of tables that are linked together by a web of joins. Furthermore, each of the created entities is converted into separate physical tables when the database is implemented Kimball, Ralph 2008. The main advantage of this approach is that it is straightforward to add information into the database. Some disadvantages of this approach are that, because of the number of tables involved, it can be difficult for users to join data from different sources into meaningful information and to access the information without a precise understanding of the sources of data and of the data structure of the data warehouse.
Both normalized and dimensional models can be represented in entity-relationship diagrams as both contain joined relational tables. The difference between the two models is the degree of normalization also known as Normal Forms. These approaches are not mutually exclusive, and there are other approaches. Dimensional approaches can involve normalizing data to a degree Kimball, Ralph 2008.
In Information-Driven Business, Robert Hillard proposes an approach to comparing the two approaches based on the information needs of the business problem. The technique shows that normalized models hold far more information than their dimensional equivalents even when the same fields are used in both models but this extra information comes at the cost of usability. The technique measures information quantity in terms of information entropy and usability in terms of the Small Worlds data transformation measure.
6.1. Design methods Bottom-up design
In the bottom-up approach, data marts are first created to provide reporting and analytical capabilities for specific business processes. These data marts can then be integrated to create a comprehensive data warehouse. The data warehouse bus architecture is primarily an implementation of "the bus", a collection of conformed dimensions and conformed facts, which are dimensions that are shared in a specific way between facts in two or more data marts.
6.2. Design methods Top-down design
The top-down approach is designed using a normalized enterprise data model. "Atomic" data, that is, data at the greatest level of detail, are stored in the data warehouse. Dimensional data marts containing data needed for specific business processes or specific departments are created from the data warehouse.
6.3. Design methods Hybrid design
Data warehouses DW often resemble the hub and spokes architecture. Legacy systems feeding the warehouse often include customer relationship management and enterprise resource planning, generating large amounts of data. To consolidate these various data models, and facilitate the extract transform load process, data warehouses often make use of an operational data store, the information from which is parsed into the actual DW. To reduce data redundancy, larger systems often store the data in a normalized way. Data marts for specific reports can then be built on top of the data warehouse.
A hybrid DW database is kept on third normal form to eliminate data redundancy. A normal relational database, however, is not efficient for business intelligence reports where dimensional modelling is prevalent. Small data marts can shop for data from the consolidated warehouse and use the filtered, specific data for the fact tables and dimensions required. The DW provides a single source of information from which the data marts can read, providing a wide range of business information. The hybrid architecture allows a DW to be replaced with a master data management repository where operational, not static information could reside.
The data vault modeling components follow hub and spokes architecture. This modeling style is a hybrid design, consisting of the best practices from both third normal form and star schema. The data vault model is not a true third normal form, and breaks some of its rules, but it is a top-down architecture with a bottom up design. The data vault model is geared to be strictly a data warehouse. It is not geared to be end-user accessible, which when built, still requires the use of a data mart or star schema based release area for business purposes.
7. Data warehouse characteristics
There are basic features that define the data in the data warehouse that include subject orientation, data integration, time-variant, nonvolatile data, and data granularity.
7.1. Data warehouse characteristics Subject-oriented
Unlike the operational systems, the data in the data warehouse revolves around subjects of the enterprise database normalization. Subject orientation can be really useful for decision making. Gathering the required objects is called subject oriented.
7.2. Data warehouse characteristics Integrated
The data found within the data warehouse is integrated. Since it comes from several operational systems, all inconsistencies must be removed. Consistencies include naming conventions, measurement of variables, encoding structures, physical attributes of data, and so forth.
7.3. Data warehouse characteristics Time-variant
While operational systems reflect current values as they support day-to-day operations, data warehouse data represents data over a long time horizon up to 10 years which means it stores historical data. It is mainly meant for data mining and forecasting, If a user is searching for a buying pattern of a specific customer, the user needs to look at data on the current and past purchases.
7.4. Data warehouse characteristics Nonvolatile
The data in the data warehouse is read-only which means it cannot be updated, created, or deleted.
7.5. Data warehouse characteristics Summarized
In the data warehouse, data is summarized at different levels. The user may start looking at the total sale units of a product in an entire region. Then the user looks at the states in that region. Finally, they may examine the individual stores in a certain state. Therefore, typically, the analysis starts at a higher level and moves down to lower levels of details.
8. Data warehouse architecture
The different methods used to construct/organize a data warehouse specified by an organization are numerous. The hardware utilized, software created and data resources specifically required for the correct functionality of a data warehouse are the main components of the data warehouse architecture. All data warehouses have multiple phases in which the requirements of the organization are modified and fine tuned.
9. Versus operational system
Operational systems are optimized for preservation of data integrity and speed of recording of business transactions through use of database normalization and an entity-relationship model. Operational system designers generally follow Codds 12 rules of database normalization to ensure data integrity. Fully normalized database designs that is, those satisfying all Codd rules often result in information from a business transaction being stored in dozens to hundreds of tables. Relational databases are efficient at managing the relationships between these tables. The databases have very fast insert/update performance because only a small amount of data in those tables is affected each time a transaction is processed. To improve performance, older data are usually periodically purged from operational systems.
Data warehouses are optimized for analytic access patterns. Analytic access patterns generally involve selecting specific fields and rarely if ever select * as is more common in operational databases. Because of these differences in access patterns, operational databases loosely, OLTP benefit from the use of a row-oriented DBMS whereas analytics databases loosely, OLAP benefit from the use of a column-oriented DBMS. Unlike operational systems which maintain a snapshot of the business, data warehouses generally maintain an infinite history which is implemented through ETL processes that periodically migrate data from the operational systems over to the data warehouse.
10. Evolution in organization use
These terms refer to the level of sophistication of a data warehouse:Offline operational data warehouse Data warehouses in this stage of evolution are updated on a regular time cycle usually daily, weekly or monthly from the operational systems and the data is stored in an integrated reporting-oriented database. Offline data warehouse Data warehouses at this stage are updated from data in the operational systems on a regular basis and the data warehouse data are stored in a data structure designed to facilitate reporting. On time data warehouse Online Integrated Data Warehousing represent the real time Data warehouses stage data in the warehouse is updated for every transaction performed on the source data Integrated data warehouse These data warehouses assemble data from different areas of business, so users can look up the information they need across other systems.