DATA WAREHOUSE-LEGACY SYSTEMS-DATA MARTS-MARKETING DATABASEBy Davin Abraham

1701310002

M.tech/DB/SRM

12 rules of a Datawarehouse Data Warehouse and Operational

Environments are Separated Data is integrated Contains historical data over a long

period of time Data is a snapshot data captured at a

given point in time Data is subject-oriented

12 rules of a Datawarehouse Mainly read-only with periodic batch

updates Development Life Cycle has a data

driven approach versus the traditional process-driven approach

Data contains several levels of detail Current, Old, Lightly Summarized, Highly

Summarized

12 rules of a Datawarehouse Environment is characterized by Read-only

transactions to very large data sets System that traces data sources,

transformations, and storage Metadata is a critical component

Source, transformation, integration, storage, relationships, history, etc

Contains a chargeback mechanism for resource usage that enforces optimal use of data by end users

Life cycle of the DW

Warehouse Database

First time load

Refresh

Refresh

Refresh

Purge or Archive

1001

1007

1010

1020

Relational Database Model

31

42

22

32

F

M

M

F

Anderson

Green

Lee

Ramos

Attribute 1Name

Attribute 2Age

Attribute 3Gender

Row 1

Row 2

Row 3

Row 4

The table above illustrates the employee relation.

Attribute 4Emp No.

Multidimensional Database Model

The data is found at the intersection of dimensions.

Store

GL_Line

Time

FINANCE

Store

Product

Time

SALES

Customer

Two dimensions

Three dimensions

Data marts

Small Data Stores More manageable data sets Targeted to meet the needs of small

groups within the organization

Small, Single-Subject data warehouse subset that provides decision support to a small group of people

Data Mart

A subset of a data warehouse that supports the requirements of a particular department or business function.

Characteristics include: Do not normally contain detailed

operational data unlike data warehouses. May contain certain levels of aggregation

Independent Data Mart

Sales or Marketing

External Data

Flat FilesOperational Systems

Reasons For Creating a Data Mart To give users more flexible access to the

data they need to analyse most often. To provide data in a form that matches

the collective view of a group of users To improve end-user response time. Potential users of a data mart are clearly

defined and can be targeted for support

To provide appropriately structured data as dictated by the requirements of the end-user access tools.

Building a data mart is simpler compared with establishing a corporate data warehouse.

The cost of implementing data marts is far less than that required to establish a data warehouse.

Legacy Systems

Older software systems that remain vital to an organisation

The legacy Dilemma it is expensive and risky to replace the

legacy system It is expensive to maintain the legacy system Businesses must weigh up the costs and

risks and may choose to extend the system lifetime using techniques such as re-engineering.

The system may be file-based with incompatible files. The change required may be to move to a database-management system

In legacy systems that use a DBMS the database management system may be obsolete and incompatible with other DBMSs used by the business

Legacy System Design

Most legacy systems were designed before object-oriented development was used

Rather than being organised as a set of interacting objects, these systems have been designed using a function-oriented design strategy

Several methods and CASE tools are available to support function-oriented design and the approach is still used for many business applications

Legacy system categories

Low quality, low business value These systems should be scrapped

Low-quality, high-business value These make an important business contribution but

are expensive to maintain. Should be re-engineered or replaced if a suitable system is available

High-quality, low-business value Replace with COTS, scrap completely or maintain

High-quality, high business value Continue in operation using normal system

maintenance

Legacy System Evolution

The structure of legacy business systems normally follows an input-process-output model

The business value of a system and its quality should be used to choose an evolution strategy

The business value reflects the system’s effectiveness in supporting business goals

System quality depends on business processes, the system’s environment and the application software

Marketing Database

 is a systematic approach to the gathering, consolidation, and processing of consumer data (both for customers and potential customers) that is maintained in a company's databases.

Although databases have been used for customer data in traditional marketing for a long time, the database marketing approach is differentiated by the fact that much more consumer data is maintained, and that the data is processed and used in new and more sophisticated ways.

Among other things, marketers use the data to learn more about customers, select target markets for specific campaigns (through customer segmentation), compare customers' value to the company and provide more specialized offerings for customers.

Need for a Marketing Database Emails sent based on email response

alone, not on overall purchases Gold customers are seldom recognized Long time customers treated as

strangers Customers feel unappreciated You may lose your best supporters

What You Can Do with a Marketing DB?

Store behavior and append demographic data

Create customer segments, and develop a marketing plan for each segment.

Personalize all your email communications to customers – to build loyalty and sales

Append demographic data Determine customer lifetime value.

Thank You