Outline

What is a data warehouse? A multi-dimensional data model Data warehouse architecture Data warehouse implementation Further development of data cube technology From data warehousing to data mining

What is Data Warehouse?

Defined in many different ways, but not rigorously

A decision support database that is maintained separately from the organisations operational database Support information processing by providing a solid platform of consolidated, historical data for analysis A data warehouse is a subject-oriented, integrated, time-variant, and non-volatile collection of data in support of managements decision-making process The process of constructing and using data warehouses

Definition by Inmon

Data warehousing

Data WarehouseSubject-Oriented
Organized around major subjects, such as customer, product, sales Focusing on the modeling and analysis of data for decision makers, not on daily operations or transaction processing Provide a simple and concise view around particular subject issues by excluding data that are not useful in the decision support process

Data WarehouseIntegrated
Constructed by integrating heterogeneous data sources

multiple,

relational databases, flat files, on-line transaction records

Data cleaning and data integration techniques are applied

Ensure consistency in naming conventions, encoding structures, attribute measures, etc. among different data sources
E.g., Hotel price: currency, tax, breakfast covered, etc.

When data is moved to the warehouse, it is converted

Data WarehouseTime Variant

The time horizon for the data warehouse is significantly longer than that of operational systems

Operational database: current value data Data warehouse data: provide information from a historical perspective (e.g., past 5-10 years)

Every key structure in the data warehouse

Contains an element of time, explicitly or implicitly But the key of operational data may or may not contain time element

Data WarehouseNon-Volatile
A physically separate store of data transformed from the operational environment Operational update of data does not occur in the data warehouse environment

Does not require transaction processing, recovery, and concurrency control mechanisms Requires only two operations in data accessing: initial loading of data and access of data

Data Warehouse vs. Heterogeneous DBMS

Traditional heterogeneous DB integration

Build wrappers/mediators on top of heterogeneous databases Query driven approach When a query is posed to a client site, a meta-dictionary is used to translate the query into queries appropriate for individual heterogeneous sites involved, and the results are integrated into a global answer set Complex information filtering, compete for resources

Data warehouse

update-driven, high performance

Information from heterogeneous sources is integrated in advance and stored in warehouses for direct query and analysis

Data Warehouse vs. Operational DBMS

OLTP (On-Line Transaction Processing)

Major task of traditional relational DBMS Day-to-day operations: purchasing, inventory, banking, manufacturing, payroll, registration, accounting, etc. Major task of data warehouse system Data analysis and decision making User and system orientation: customer vs. market Data contents: current, detailed vs. historical, consolidated Database design: ER + application vs. star + subject View: current, local vs. evolutionary, integrated Access patterns: update vs. read-only but complex queries

OLAP (On-Line Analytical Processing)

Distinct features (OLTP vs. OLAP):

OLTP vs. OLAP

OLTP users function DB design data clerk, IT professional day to day operations application -oriented current, up -to-date detailed, flat relational isolated repetitive read/write index/hash on prim. key short, simple transaction tens thousands 100MB -GB transaction throughput OLAP knowledge worker decision support subject -oriented historical, summarized, multidimensio nal integrated, consolidated ad-hoc lots of scans complex query millions hundreds 100GB -TB query throughput, response

usage access unit of work # records accessed #users DB size metric

Why Separate Data Warehouse?

High performance for both systems

DBMS tuned for OLTP

access methods, indexing, concurrency control, recovery

Warehousetuned for OLAP

complex OLAP queries, multidimensional view, consolidation.

Different functions and different data

Missing data: Decision support requires historical data which operational DBs do not typically maintain Data consolidation: DS requires consolidation (aggregation, summarization) of data from heterogeneous sources Data quality: different sources typically use inconsistent data representations, codes and formats which have to be reconciled

Outline

What is a data warehouse? A multi-dimensional data model Data warehouse architecture Data warehouse implementation Further development of data cube technology From data warehousing to data mining

From Tables and Spreadsheets to Data Cubes

A data warehouse is based on

multidimensional data model which views data in the form of a data cube

A data cube allows data to be modeled and viewed in multiple dimensions (such as sales)

Dimensions are the perspectives or entities with respect to which an organization wants to keep records Dimension tables, such as item (item_name, brand, type), or time(day, week, month, quarter, year) Fact table contains measures (such as dollars_sold) and keys to each of the related dimension tables

2-D View of Data

3-D view of Data

Data Cube

4D data cube representation

Definitions related to Data Cubes

An n-Dimensional base cube is called a base cuboid, i.e. the cuboid that holds the lowest level of summarization. e.g. 4D cuboid is the base cuboid for the time, location , item and supplier.

The top most 0-D cuboid, which holds the highest-level of summarization, is called the apex cuboid e.g. total sales or dollars sold summarized over all four dimensions..

The lattice of cuboids forms a data cube.

Cube: A Lattice of Cuboids

all time item location supplier 0-D(apex) cuboid

1-D cuboids

time,item

time,location

item,location

location,supplier

time,supplier time,item,location

item,supplier

2-D cuboids 3-D cuboids 4-D(base) cuboid

time,location,supplier

time,item,supplier

item,location,supplier

time, item, location, supplier

Conceptual Modeling of Data Warehouses

Modeling data warehouses: dimensions & measures Star schema

The most common modeling paradigm is the star schema, in which the data warehouse contains a large central table (fact table) containing the bulk of the data, with no redundancy, and a set of smaller attendant tables (dimension tables), one for each dimension. The schema graph resembles a starburst, with the dimension tables displayed in a radial pattern around the central fact table.

Example of Star Schema

Time time_key day day_of_the_week month quarter year

Sales Fact Table

Item item_key item_name brand type supplier_type Location location_key street city province_or_street country

Time_key Item_key Branch_key

Branch branch_key branch_name branch_type

Location_key Unit_sold Euros_sold Avg_sales

Measures

Contd
Snowflake schema

A refinement of star schema where some dimension tables are normalized by splitting the dimension tables into a set of smaller dimension tables, forming a shape similar to snowflake

Fact constellations

Multiple fact tables share dimension tables, viewed as a collection of stars, therefore called galaxy schema or fact constellation

Example of Snowflake Schema

Time time_key day day_of_the_week month quarter year Supplier Item item_key item_name brand type supplier_key City
city_key city province_or_street country

Sales Fact Table

Time_key Item_key Branch_key

supplier_key supplier_type

Branch branch_key branch_name branch_type

Location_key Unit_sold Euros_sold Avg_sales Location location_key street city_key

Measures

Example of Fact Constellation

Shipping Fact Table Time time_key day day_of_the_week month quarter year Branch branch_key branch_name branch_type Item Time_key

Sales Fact Table

Time_key Item_key Branch_key Location_key Unit_sold Euros_sold Avg_sales

Item_key shipper_key from_location to_location Euros_sold

item_key item_name brand type supplier_key

Location location_key street city Province/street country

unit_shipped

shipper
shipper_key shipper_name location_key shipper_type

Measures

DMQL: Language Primitives

Cube Definition (Fact Table)

define cube <cube_name> [<dimension_list>]: <measure_list>

Dimension Definition (Dimension Table)

define dimension <dimension_name> as (<attribute_or_subdimension_list>)

Special Case (Shared Dimension Tables)

First time as cube definition define dimension <dimension_name> as <dimension_name_first_time> in cube <cube_name_first_time>

Defining a Star Schema in DMQL

define cube sales_star [time, item, branch, location]:
dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*)

define dimension time as

(time_key, day, day_of_week, month, quarter, year)

define dimension item as

(item_key, item_name, brand, type, supplier_type)

define dimension branch as

(branch_key, branch_name, branch_type)

define dimension location as

(location_key, street, city, province_or_state, country)

Defining a Snowflake Schema in DMQL

define cube sales_snowflake [time, item, branch, location]:
dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*)

define dimension time as

(time_key, day, day_of_week, month, quarter, year)

define dimension item as

(item_key, item_name, brand, type, supplier(supplier_key, supplier_type))

define dimension branch as

(branch_key, branch_name, branch_type)

define dimension location as

(location_key, street, city(city_key, province_or_state, country))

Defining a Fact Constellation in DMQL

define cube sales [time, item, branch, location]:
dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*)

define dimension time as (time_key, day, day_of_week, month, quarter, year) define dimension item as (item_key, item_name, brand, type, supplier_type) define dimension branch as (branch_key, branch_name, branch_type) define dimension location as (location_key, street, city, province_or_state, country) define cube shipping [time, item, shipper, from_location, to_location]:
dollar_cost = sum(cost_in_dollars), unit_shipped = count(*)

define dimension time as time in cube sales define dimension item as item in cube sales define dimension shipper as (shipper_key, shipper_name, location as location in cube sales, shipper_type) define dimension from_location as location in cube sales define dimension to_location as location in cube sales

Measures: Three Categories

Distributive

if the result derived by applying the function to n aggregate values is the same as that derived by applying the function on all the data without partitioning.
E.g., count(), sum(), min(), max()

Algebraic

if it can be computed by an algebraic function with M arguments (where M is a bounded integer), each of which is obtained by applying a distributive aggregate function.
E.g., avg(), min_N(), standard_deviation()

Holistic

An aggregate function is holistic if it is applied on data as a whole.

median(), mode() etc.

A Concept Hierarchy: Dimension (location)

all region country city office North_America Canada ... Mexico Dublin Belfield ... all ... Ireland ... Europe ... France

Toronto

...

Belfast

Blackrock

View of Warehouses and Hierarchies

Specification of hierarchies Schema hierarchy
day < {month < quarter; week} < year

Set_grouping hierarchy
{1..10} < inexpensive

Multidimensional Data
Sales volume as a function of product, month, and region
Re gi on
Dimensions: Product, Location, Time Hierarchical summarization paths Industry Region Year

Product

Category Country Quarter Product City Office Month Day Week

Month

A Sample Data Cube

Pr od uc t
TV PC VCR sum 1Qtr 2Qtr

Date

3Qtr

4Qtr

sum

Total annual sales of TV in Ireland Ireland France Germany sum

Country

Cuboids Corresponding to the Cube

all 0-D(apex) cuboid

product product,date

date
product,country

country
date, country

1-D cuboids

2-D cuboids 3-D(base) cuboid

product, date, country

Browsing a Data Cube

Visualization OLAP capabilities Interactive manipulation

Outline

What is a data warehouse? A multi-dimensional data model Data warehouse architecture Data warehouse implementation Further development of data cube technology From data warehousing to data mining

Typical OLAP Operations

Roll up (drill-up): summarize data

It performs aggregation on data cube either by climbing up a concept hierarchy or by dimension reduction

Drill down (roll down): reverse of roll-up

from higher level summary to lower level summary or detailed data, or introducing new dimensions

Slice and dice: project and select

The slice operation performs the selection on one dimension of the given cube , resulting in the sub cube. The dice operation defines a sub cube by performing a selection on two or more dimensions.

Typical OLAP Operations

Pivot (rotate) reorient the cube, visualization, 3D to series of 2D planes. Other operations drill across: involving (across) more than one fact table drill through: through the bottom level of the cube to its back-end relational tables (using SQL)

SLICE ROLL UP

DICE DRILL DOWN

PIVOT

Star-Net Query Model

The querying of multidimensional databases can be based on a star net model. A star net model consists of radial lines emanating from a central point, where each line represents a concept hierarchy for a dimension. Each abstraction level in the hierarchy is called a footprint. These represent the granularities available for use by OLAP operations such a s drill-down and roll-up. For Modeling business queries a star net model is used.

A Star-Net Query Model

Shipping Method Customer Orders Customer CONTRACTS ORDER PRODUCT LINE ANNUALY QTRLY CITY COUNTRY DISTRICT REGION Location DIVISION Promotion Organization DAILY PRODUCT ITEM Product

AIR-EXPRESS TRUCK Time

PRODUCT GROUP

SALES PERSON

Each circle is called a footprint

Design of a Data Warehouse: A Business Analysis Framework

Four views regarding the design of a data warehouse

Top-down view

allows selection of the relevant information necessary for the data warehouse. This information matches the current and future business needs.

Data source view

exposes the information being captured, stored, and managed by operational system. This information may be documented at various levels of detail, from individual data source tables to integrated data source tables.

Design of a Data Warehouse: A Business Analysis Framework

Data warehouse view

consists of fact tables and dimension tables. It represents the information that is stored inside the data warehouse, including precalculated totals and counts, as well as information regarding the source, date, and time of origin, added to provide historical context.

Business query view

sees the perspectives of data in the warehouse from the view of end-user

Data Warehouse Design Process

Top-down, bottom-up approaches or a combination of both

Top-down: Starts with overall design and planning (mature) Bottom-up: Starts with experiments and prototypes (rapid) Combination: In this approach, an organization can exploit the planned and strategic nature of top down approach while retaining the rapid implementation and opportunistic application of the bottom-up approach.

Data Warehouse Design Process

From software engineering point of view:

Construction of data warehouse may consist of following steps:

Planning, Requirements study, problem analysis, warehouse design, data integration and testing and deployment of the data warehouse.

Waterfall: structured and systematic analysis at each step before proceeding to the next Spiral: rapid generation of increasingly functional systems, short turn around time, quick turn around

Data Warehouse Design Process

Typical data warehouse design process

Choose a business process to model, e.g., orders, invoices, etc. if the business process is organizational and involves multiple complex object collections, a data warehouse model should be followed. However, if the process is departmental and focuses on the analysis of one kind of business process, a data mart model should be chosen. Choose the grain (atomic level of data) of the business process The grain is the fundamental, atomic level of data to be represented in the fact table for this process, for example, individual transactions, individual daily snapshots, and so on. Choose the dimensions that will apply to each fact table record Choose the measure that will populate each fact table record

Generic architecture of a data warehouse

Heterogeneous lLegacy OLTP systems

Centralized, unique and integrated corporate DW (includes metadata)

Data Cleaning and Integration

Distributed clients OLAP Query engines Data mining Report generators etc.

Legacy systems vs data warehouses

LEGACY SYSTEM Built for transactions Original source Detailed data Application-oriented Current data only Normalized data structure run on DBMS, GIS, web servers, CAD ... DATA WAREHOUSE Built for analysis, decisions Copy or read-only data Aggregated/summary data Enterprise-oriented Current + historic data Denormalized, redundant data structure run on Super RDBMS, MDDBMS, ...

Physical vs virtual data warehouses

PHYSICAL Persistent data A priori integration All data integrated Requires warehouse specific DBMS Faster response OK for Large DB VIRTUAL No persistent data On the fly integration Integrate as required Requires no DW specific DBMS Slower response Not for Large DB

Standard federated three-tiered architecture of data warehouse

Clients

Department A

Data Cleaning and Integration

Department B

Department C Organisational DW (aggregated data) Legacy OLTP systems

Departmental Datamarts

Clients

Tiers 3

Tiers 2

Tiers 1

Data Marts

Data warehouse vs datamart

DATA WAREHOUSE Built for analysis Aggregated/summary data Enterprise-oriented Denormalized, redundant data structure VLDB DATAMART Built for high-level analysis Highly aggregated and summarized data Subject-oriented Highly denormalized, redundant data structure Smaller DB

Datamart architecture without a data warehouse

Department A

Department B

Department C

Legacy OLTP systems

Datamarts

Distributed Clients

Multi-tiered architecture of a data warehouse

Department A

Data Cleaning and Integration

Department B

Department C DW 2 (aggregated data) Datamarts Distributed Clients

DW 1 (detailed data) Legacy OLTP systems

Tiers 1

Tiers 2

Tiers 3

Tiers 4

Multi-Tiered Architecture
Monitor & Integrator OLAP Server

other

Metadata

sources
Operational Extract Transform Load Refresh

DBs

Data Warehouse

Serve

Analysis Query Reports Data mining

Data Marts

Data Sources

Data Storage

OLAP Engine Front-End Tools

Three Data Warehouse Models

Enterprise warehouse

collects all of the information about subjects spanning the entire organization a subset of corporate-wide data that is of value to a specific groups of users. Its scope is confined to specific, selected groups, such as marketing data mart
Independent vs. dependent (directly from warehouse) data mart

Data Mart

Virtual warehouse

A set of views over operational databases Only some of the possible summary views may be materialized

Data Warehouse Development: A Recommended Approach

Multi-Tier Data Warehouse

Distributed Data Marts

Data Mart

Data Mart
Model refinement

Enterprise Data Warehouse

Model refinement

Define a high-level corporate data model

OLAP Server Architectures

Relational OLAP (ROLAP)

Use relational or extended-relational DBMS to store and manage warehouse data and OLAP middle ware to support missing pieces Include optimization of DBMS backend, implementation of aggregation navigation logic, and additional tools and services greater scalability Array-based multidimensional storage engine (sparse matrix techniques) fast indexing to pre-computed summarized data User flexibility, e.g., low level: relational, high-level: array specialized support for SQL queries over star/snowflake schemas

Multidimensional OLAP (MOLAP)

Hybrid OLAP (HOLAP)

Specialized SQL servers

MOLAP
MOLAP based products organize, navigate and analyze data typically in an aggregated form. They require tight coupling with the application and depend multidimensional database system. upon a

MOLAP technology is suited for the applications requiring iterative and comprehensive time series analysis of trends. For Example: Financial Analysis and budgeting Some of the problems faced by users are related to maintaining support to multiple subject areas in an RDBMS, these problems can be solved by some vendors by maintaining the access from MOLAP tools to detailed data in an RDBMS.

MOLAP Architecture
Front-end Tools
Database Server

Load
MOLAP Server

Info request

SQL
Metadata Request Processing

Result Set

Result Set

ROLAP
It is the latest and fast growing OLAP technology. In this there is no requirement of creating a static, multidimensional data structure as required in MOLAP. This approach enables multiple multidimensional views of two-dimensional relational tables to be created, avoiding structuring data around the desired view.

ROLAP Architecture
Front-end Tools
Database Server

ROLAP Server

Info request

SQL
Metadata Request Processing

Result Set

Result Set

Managed Query Environment (MQE) or Hybrid OLAP

Recent trend in OLAP is to enable capability for users to perform limited analysis directly against RDBMS Products or by bringing in an intermediate limited MOLAP Server.

Hybrid OLAP Architecture

SQL Query
Database Server

Front-end Tools

Result Set OR Load SQL RDBMS Result Set

MOLAP Server

Info request Result Set