DECISION SUPPORT AND
BUSINESS INTELLIGENCE SYSTEMS
Chapter 8:
Data Warehousing
LEARNING OBJECTIVES
Ò
Understand the basic definitions and concepts
of data warehouses
Ò
Learn different types of data warehousing
architectures; their comparative advantages
and disadvantages
Ò
Describe the processes used in developing
and managing data warehouses
Ò
Explain data warehousing operations
Ò
Explain the role of data warehouses in
LEARNING OBJECTIVES
Ò
Explain data integration and the extraction,
transformation, and load (ETL) processes
Ò
Describe real-time (a.k.a. right-time and/or
active) data warehousing
Ò
Understand data warehouse administration
MAIN DATA WAREHOUSING (DW) TOPICS
Ò
DW definitions
Ò
Characteristics of DW
Ò
Data Marts
Ò
ODS, EDW, Metadata
Ò
DW Framework
Ò
DW Architecture & ETL Process
Ò
DW Development
DATA WAREHOUSE DEFINED
Ò
A physical repository where relational data
are specially organized to provide
enterprise-wide, cleansed data in a standardized format
Ò
“
The data warehouse is a collection of
integrated, subject-oriented databases design
to support DSS functions, where each unit of
data is non-volatile and relevant to some
CHARACTERISTICS OF DW
Ò
Subject oriented
Ò
Integrated
Ò
Time-variant (time series)
Ò
Nonvolatile
Ò
Summarized
Ò
Not normalized
Ò
Metadata
Ò
Web based, relational/multi-dimensional
Ò
Client/server
DATA MART
A departmental data warehouse that
stores only relevant data
É
Dependent data mart
A subset that is created directly from a
data warehouse
É
Independent data mart
A small data warehouse designed for a
strategic business unit or a department
DATA WAREHOUSING DEFINITIONS
Ò Operational data stores (ODS)
A type of database often used as an interim area for a data warehouse
Ò Oper marts
An operational data mart.
Ò Enterprise data warehouse (EDW)
A data warehouse for the enterprise.
Ò Metadata
Data about data. In a data warehouse, metadata describe the contents of a data warehouse and the manner of its acquisition and use
A CONCEPTUAL FRAMEWORK FOR DW
Data Sources ERP Legacy POS Other OLTP/wEB External data Select Transform Extract Integrate Load ETL Process Enterprise Data warehouse Metadata Replication A P I / M id d le w a re Data/text mining Custom built applications OLAP, Dashboard, Web Routine Business Reporting Applications (Visualization) Data mart (Engineering) Data mart (Marketing) Data mart (Finance) Data mart (...) AccessGENERIC DW ARCHITECTURES
Ò
Three-tier architecture
1. Data acquisition software (back-end)
2. The data warehouse that contains the data & software
3. Client (front-end) software that allows users to access
and analyze data from the warehouse
Ò
Two-tier architecture
First 2 tiers in three-tier architecture is combined into one
GENERIC DW ARCHITECTURES
Tier 2: Application server Tier 1: Client workstation Tier 3: Database server Tier 1: Client workstation Tier 2:DW ARCHITECTURE
CONSIDERATIONS
Ò
Issues to consider when deciding which
architecture to use:
É
Which database management system (DBMS)
should be used?
É
Will parallel processing and/or partitioning be
used?
É
Will data migration tools be used to load the
data warehouse?
É
What tools will be used to support data
A WEB-BASED DW ARCHITECTURE
Web Server Client (Web browser) Application Server Data warehouse Web pages Internet/ Intranet/ ExtranetALTERNATIVE DW ARCHITECTURES
Source Systems
Staging Area
Independent data marts (atomic/summarized data)
End user access and applications
ETL
(a) Independent Data Marts Architecture
Source Systems Staging Area End user access and applications ETL
Dimensionalized data marts linked by conformed dimentions
(atomic/summarized data)
(b) Data Mart Bus Architecture with Linked Dimensional Datamarts
Source Systems Staging Area End user access and applications ETL Normalized relational warehouse (atomic data)
Dependent data marts (summarized/some atomic data)
ALTERNATIVE DW ARCHITECTURES
Source Systems Staging Area Normalized relational warehouse (atomic/some summarized data) End user access and applications ETL(d) Centralized Data Warehouse Architecture
End user access and applications Logical/physical integration of
common data elements Existing data warehouses
Data marts and legacy systmes
Data mapping / metadata (e) Federated Architecture
WHICH ARCHITECTURE IS THE BEST?
Ò
Bill Inmon versus Ralph Kimball
Ò
Enterprise DW versus Data Marts approach
DATA WAREHOUSING ARCHITECTURES
1. Information interdependence between organizational units 2. Upper management’s information needs3. Urgency of need for a
data warehouse
4. Nature of end-user tasks
5. Constraints on resources
6. Strategic view of the data
warehouse prior to implementation
7. Compatibility with existing
systems
8. Perceived ability of the in-house
IT staff
9. Technical issues
10. Social/political factors
Ten factors
that
potentially affect the
ENTERPRISE DATA WAREHOUSE
(BY TERADATA CORPORATION)
DATA INTEGRATION AND THE EXTRACTION,
TRANSFORMATION, AND LOAD (ETL)
PROCESS
Ò Data integration
Integration that comprises three major processes: data access, data federation, and change capture.
Ò Enterprise application integration (EAI)
A technology that provides a vehicle for pushing data from source systems into a data warehouse
Ò Enterprise information integration (EII)
An evolving tool space that promises real-time data integration from a variety of sources
Ò Service-oriented architecture (SOA)
E
xtraction,
t
ransformation, and
l
oad (ETL) process
DATA INTEGRATION AND THE EXTRACTION,
TRANSFORMATION, AND LOAD (ETL)
PROCESS
Packaged application Legacy system Other internal applications Transient data sourceExtract Transform Cleanse Load
Data warehouse
ETL
Ò
Issues affecting the purchase of and ETL tool
É Data transformation tools are expensive
É Data transformation tools may have a long learning curve
Ò
Important criteria in selecting an ETL tool
É Ability to read from and write to an unlimited number of
data sources/architectures
É Automatic capturing and delivery of metadata
É A history of conforming to open standards
É An easy-to-use interface for the developer and the
BENEFITS OF DW
Ò Direct benefits of a data warehouse
É Allows end users to perform extensive analysis
É Allows a consolidated view of corporate data
É Better and more timely information
É Enhanced system performance
É Simplification of data access
Ò Indirect benefits of data warehouse
É Enhance business knowledge
É Present competitive advantage
É Enhance customer service and satisfaction
É Facilitate decision making
DATA WAREHOUSE DEVELOPMENT
n
Data warehouse development approaches
n Inmon Model: EDW approach (top-down)
n Kimball Model: Data mart approach (bottom-up)
n Which model is best?
n There is no one-size-fits-all strategy to DW
n
One alternative is the hosted warehouse
n
Data warehouse structure:
n The Star Schema vs. Relational
DW DEVELOPMENT APPROACHES
See Table 8.3 for details (Inmon Approach) (Kimball Approach)
DW STRUCTURE: STAR SCHEMA
(A.K.A. DIMENSIONAL MODELING)
Claim Information
Driver Automotive
Time Location
Start Schema Example for an Automobile Insurance Data Warehouse
Dimensions:
How data will be sliced/ diced (e.g., by location, time period, type of automobile or driver)
Facts:
Central table that contains (usually summarized) information; also contains foreign keys to access each dimension table.
DIMENSIONAL MODELING
Data cube
A two-dimensional, three-dimensional, or higher-dimensional object in which each dimension of the data represents a measure of interest
- Grain
- Drill-down
BEST PRACTICES FOR IMPLEMENTING DW
Ò The project must fit with corporate strategy
Ò There must be complete buy-in to the project
Ò It is important to manage user expectations
Ò The data warehouse must be built incrementally
Ò Adaptability must be built in from the start
Ò The project must be managed by both IT and business
professionals (a business–supplier relationship must be developed)
Ò Only load data that have been cleansed/high quality
Ò Do not overlook training requirements
RISKS IN IMPLEMENTING DW
Ò No mission or objective
Ò Quality of source data unknown
Ò Skills not in place
Ò Inadequate budget
Ò Lack of supporting software
Ò Source data not understood
Ò Weak sponsor
Ò Users not computer literate
Ò Political problems or turf wars
Ò Unrealistic user expectations
RISKS IN IMPLEMENTING DW – CONT.
Ò Architectural and design risks
Ò Scope creep and changing requirements
Ò Vendors out of control
Ò Multiple platforms
Ò Key people leaving the project
Ò Loss of the sponsor
Ò Too much new technology
Ò Having to fix an operational system
Ò Geographically distributed environment
THINGS TO AVOID FOR SUCCESSFUL
IMPLEMENTATION OF DW
Ò
Starting with the wrong sponsorship chain
Ò
Setting expectations that you cannot meet
Ò
Engaging in politically naive behavior
Ò
Loading the warehouse with information just
because it is available
Ò
Believing that data warehousing database design is
the same as transactional DB design
Ò
Choosing a data warehouse manager who is
technology oriented rather than user oriented
REAL-TIME DW
(A.K.A. ACTIVE DATA WAREHOUSING)
Ò
Enabling real-time data updates for real-time
analysis and real-time decision making is
growing rapidly
É
Push vs. Pull (of data)
Ò
Concerns about real-time BI
É Not all data should be updated continuously
É Mismatch of reports generated minutes apart
É May be cost prohibitive
Active Data Warehousing
(by Teradata Corporation)
DATA WAREHOUSE ADMINISTRATION
Ò
Due to its
huge size
and its intrinsic nature, a DW
requires especially strong monitoring in order to
sustain its efficiency, productivity and security.
Ò
The successful administration and management of
a data warehouse entails skills and proficiency that
go past what is required of a traditional database
administrator.
É Requires expertise in high-performance software,
DW SCALABILITY AND SECURITY
Ò
Scalability
É The main issues pertaining to scalability:
Ð The amount of data in the warehouse
Ð How quickly the warehouse is expected to grow
Ð The number of concurrent users
Ð The complexity of user queries
É Good scalability means that queries and other
data-access functions will grow linearly with the size of the warehouse
Ò
Security
WHAT CAN HADOOP DO THAT MY DATA
WAREHOUSE CAN’T?
(1) Store any and all kinds of data more cheaply and
WHY DO WE NEED HADOOP IF WE’RE NOT
DOING BIG DATA?
WHY DO WE NEED HADOOP IF WE’RE NOT
DOING BIG DATA?
Ò
Contrary to popular belief, Hadoop is not
just for big data. (
big data
simply refers to
data that doesn't fit comfortably – or at all
– into our existing relational systems.)
Ò
Hadoop was originally developed to
address the big data needs of web/media
companies, but today, it's being used
around the world to address a wider set of
data needs, big and small, by practically
every industry.
IS HADOOP ENTERPRISE-READY?
Ò
Hadoop is not just another faster, more
cost-effective engine option. It’s a game
changer in the world of data management.
Ò
It all depends on what and why you want
to use Hadoop in your organization. If you
simply want to use it as an additional (or
alternative) storage repository and/or as a
short-term data processor, then by all
IS HADOOP ENTERPRISE-READY?
Ò
If you want to go beyond data storage and
processing, and you’re looking for some of
the same data management and analysis
capabilities you currently have with your
existing data ecosystem, Apache Hadoop
alone is not going to cut it.
Ò