Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Best Practices in Data Warehousing to Support Business Initiatives and Needs

Jeff Lawyer
and
Shamsul Chowdhury

Walter E. Heller College of BusinessAdministration, Roosevelt University

Albert A. Robin Campus. 1400 North Roosevelt Boulevard. Schaumburg, IL 60173
schowdhu@roosevelt.edu

Abstract and business partnerships. Today, there are many

The paper presents the data warehousing archi-
tecture and practices used at a major U. S. retailing
company. Many considerations were assessed when
deciding which data warehousing architecture to
adopt. The paper discusses the two pre-dominant
styles in Data Warehousing, namely the “Bill Inmon
Style” or the top-down approach and the “Ralph
Kimball Style”or the bottom-up approach. The com-
pany chose the Inmon style due to a unique combina-
tion of circumstances in their business and technical
environments, which are being discussed in detail.
Much of the information presented in this paper
is based upon the direct experiences of the lead data
architect assigned to the projects under which this U.
S. retailing company’s customer data warehouse
evolved.
The architecture has evolved over time and cur-
rently has been accepted at the company as a best
practice. It is interesting to mention that both the
hardware platform (CPU and disk drives) and Rela-
tional Database Management System (RDBMS) soft-
ware employed today at this company for data ware-
housing is not the same as was selected for the first
instantiation. The implication was that the best plan
or practice was a flexible one.
There were many challenges, like organiza-
tional, technical, data sourcing and data naming,
needed to be solved during the pre-project, initial
stages, and throughout the project and beyond. The
initial data warehouse, implemented in 1996, was
termed an overall success and approved for expan-
sion. The current data warehouse data are being
used by over six hundred registered users to fine-tune
customer marketing and leverage and share data in
an enterprise manner. The data warehouse has al-
lowed the company to strengthen customer relation-
ship management (CRM) core capabilities
departments benefiting from queries and requests for
data warehouse data, many anticipated, some not.
Although not planned, the data warehouse has been a
valuable source of purchase and customer data in
case of a manufacturer recall of merchandise. Above
all, the company has been able to leverage and share
enterprise customer data to the benefit of the entire
company.
Keywords: Data Warehouse, Business Intelligence,
CRM
1. Introduction
A diverse U. S. retailing company was experi-
encing the usual growing pains of the middle 1990’s.
The diversity of businesses supported by multiple
business units and the company’s Information Tech-
nology organization had resulted in “stove-pipes” of
data, along with corresponding computer applica-
tions, which were built over several years. The data
in these legacy systems were not easily accessed,
causing difficulty in making information out of the
data, discerning knowledge from the information, and
implementing sound business decisions based upon
this knowledge. Also, the legacy operational data
were not integrated with other operational data, were
organized along process or functional orientations,
and were predominantly current-valued, containing
little or no history. Because the data as such could
yield very little business intelligence, the company
decided in 1995 that data warehousing could be used
to release their data from its “data jailhouse”.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 1

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004
2. Data Warehousing Architecture
Many decisions must be made when implement-
ing a data-warehousing environment. As if the tech-
nology decisions were not difficult enough in and of
themselves, deciding which data warehousing archi-
tecture approach to use is sometimes even more diffi-
cult. There are two general styles from which to
choose – one termed herein the “Bill Inmon Style”
[14] and the other the “Ralph Kimball Style” [8].
Both Bill Inmon and Ralph Kimball are acknowl-
edged experts in the data warehousing field, with Bill
Inmon being credited with inventing (or first formal-
izing) the concept. While both styles obtain source
data from legacy batch and online operational sys-
tems and specialized Operational Data Stores (ODS),
they differ in the arrangement of this data in the data
warehouse itself. The Inmon style calls for an
atomic-level, third-normal form (3NF) relational
format in which to store extracted and transformed
data, while the Kimball style calls for a multidimen-
sional style “dimension and fact” arrangement in
which to store extracted and transformed data. Kim-
ball’s multidimensional style design is often referred
to as a “star schema”, due to its typical arrangement
of dimension entities around a central facts entity [3,
4, 9, 11].
The Inmon style is considered application neu-
tral, while the Kimball style has data prearranged by
certain dimensions according to desired output [6, 7,
10, 11, 12]. If the Inmon style data warehouse has
data covering most or all data subjects for the com-
pany, it can be termed an “enterprise” data ware-
house. With the Kimball style, the sum of all indi-
vidual multidimensional data structures is considered
the “enterprise” data warehouse. Although highly
debated in some data warehousing data architecture
communities, the detail advantages and disadvan-
tages, as well as the recommended analysis and selec-
tion process of each style, is beyond the scope of this
paper. Companies usually pick one style over the
other based upon a combination of employee exper-
tise, assumed preference, consultant or vendor rec-
ommendation, budget, existing technologies, or per-
ceived net advantages.
The U. S. retailing company chose the Inmon
style due to a unique combination of circumstances in
their business and technical environments:
Business users had an overwhelming desire for
detail, transaction-level data. Under the Kimball ap-
proach, data are typically summarized by higher-level
dimensions [8]. In other words, it would be rare to
employ “Transaction ID” as the lowest-level dimen-
0-7695-2056-1/04 $17.00 (C) 2004 IEEE
sion, but rather “Product Type” or some other higher-
level dimensional measure. Under the Inmon ap-
proach, data are typically kept at the lowest level of
detail [13]. In other words, each transaction would
be stored in its 3NF form and could be summarized
by “Product Type” or other dimensional measure
upon reporting to the business user.
Due to traditional business “stove-pipes” of data,
potential cross-business use of data was unknown.
Under the Kimball approach, data are arranged in an
application- or data-view-specific manner [8]. Under
the Inmon approach, data are arranged according to
the rules of normalization and remain application-
and data-view-independent [13].
Legacy system data were predominantly non-
database and, therefore, not integrated nor standard-
ized. Under the Kimball approach, sourcing the leg-
acy system data would require a two-phase approach,
one for standardizing and one for summarizing and
arranging facts by their dimensions [8]. Under the
Inmon approach, only one phase of data sourcing is
required for standardizing the data [13].
Sufficient expertise existed in the business com-
munity to support user self-sufficiency incorporating
native SQL against an atomic-level data warehouse.
There was also a general absence of Business Intelli-
gence tools for accessing data warehouse data. Un-
der the Kimball approach, authoring SQL to access
data arranged in a multidimensional database would
be a very complex task. In order to handle the capa-
bilities of drilling up, down, and sideways within a
multidimensional structure, the business user typi-
cally requires a Business Intelligence tool, such as
used in On-Line Analytical Processing (OLAP) [8].
Under the Inmon approach, while the SQL can get
quite complex, it still will not be as complicated as
that needed to access a multidimensional structure
and perform drilling navigation [13].
There were other factors involved in the decision
to use the Inmon style, but the above list is sufficient
to illustrate the need for the flexibility of an applica-
tion-neutral, 3NF database to house and maintain a
“single source of truth” of company data. An addi-
tional advantage to the Inmon approach is the ability
to create dependent data marts from the atomic data
warehouse for those situations where a repetitive re-
porting requirement or application-specific need ex-
ists [13].
The architecture adopted as the best practice, as
shown in Figure 1, consists of four distinct, interact-
ing components. As depicted, the legacy operational
systems and ODS are used as sources for data ware-
house data. Outside sources, such as household
demographics or ZIP code geo-demographics, may
also be used as sources for data warehouse data. Any
needed data marts are built with data from the data
2
 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

warehouse, thus being “dependent” data marts. “In-
dependent” data marts should be discouraged, as the
data used to build them would not be of the same
assured quality as the data warehouse “single source
of truth”.
data warehouse is built [1, 2, 15]. It is extremely
important for the business champion to engage data
warehouse business partners in an “enterprise” man-
ner, not as individual vertical business units
(“stove pipes”). In conjunction with the business

champions, fully utilize or establish a data ownership

Legacy Operational Data Data

Operational Data Stores Warehouse Marts
Systems

•Process Orientation •Subject Orientation •Subject Orientation •Data subset: Summary;

•Not integrated •Integrated •Integrated Sample; Multidimensional
•Current-valued with •Current-valued with •Time Variant •Time Variant
little or no history light history •Non-Volatile •Non-Volatile
•Volatile •Volatile •Detail with much •Much history
•Detailed •Detailed history •Customized for local /
•Not easily accessed •Not arranged / tuned •Unpredictable application use
for mass retrieval requests / processing •User-friendly presentation
•Enterprise “single •Repetitive requests /
source of truth” processing
Figure 1. Chosen Data Warehousing Architecture / stewardship function and process [2]. Data owners
and data stewards are indispensable when negotiating
and standardizing multi-user differing views of the
3. Best Practices same data. To aid in accurately building the first
instantiation of the data warehouse, fully leverage
your Information Architecture organization’s enter-
As a reminder, the thrust of this paper is not prise data model [13]. If one does not exist, this is an
technological, so the various hardware and software opportune time to commence building and document-
selection decisions will not be covered. Those are ing one.
best left up to the company technicians and consult-
ants who are charged with selecting the best set of
3.2 Data Warehouse Growth
technological solutions to match the business prob-
lem. This analysis, research, testing, and selection
process can be a project in itself, and was handled as Most data warehousing initiatives have found
such at the U. S. retailing company. What may be that there is a continuous need for incremental addi-
interesting is that both the hardware platform (CPU tions to the data warehouse [2]. Treat the data ware-
and disk drives) and Relational Database Manage- house as an ongoing system and spawn specific pro-
ment System (RDBMS) software employed today at jects when appreciable expansion is needed. Keeping
this company for data warehousing is not the same as your data warehouse team intact after the initial build
was selected for the first instantiation in 1996. The is very important in order to sustain the capability to
implication here is that the best plan is a flexible one. react to this need. To paraphrase a popular saying,
“Data warehousing is not a destination – it is a jour-
ney”.
3.1 Data Warehouse Sponsorship
3.3 Data Warehouse Expertise
One of the basic best practices you can employ
for data warehousing is to ensure that a high-level
business champion exists, not just during building of In addition to the high-level business champion,
the data warehouse, but ongoing continually after the your organization should use data warehousing in-
dustry experts for both validation and expertise defi-

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 3

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004
ciencies [14]. Be sure to interview, hire, and contract
with individuals and firms according to the data
warehousing style, and perhaps even the technolo-
gies, you choose. Also, there are a number of indus-
try trade shows and conferences from which beginner
to experienced practitioners can benefit greatly.
Again, select and use these opportunities based upon
the style of data warehousing you choose.
3.4 Data Warehouse Scope
For the initial release of your data warehouse,
limit the number of data subjects implemented and
the extent of their content, perhaps employing an
evolutionary prototype or proof-of-concept develop-
ment methodology [15]. This will minimize initial
investment, help gain expertise with a smaller set of
data (and, thus, a smaller set of technical challenges),
and deliver business value sooner. This is an excel-
lent way of demonstrating the informational and
monetary benefits of data warehousing to the com-
pany's top-level management, increasing their overall
commitment and support of the concept.
3.5 Data Warehouse Data Modeling
It is important, once a data warehousing architec-
ture is chosen, to adhere to it from beginning to end .
This may seem rhetorical, but there can be many op-
portunities and much pressure to short-cut the process
necessary to create a quality data warehouse. Using a
robust data modeling tool, follow a typical concep-
tual to logical to physical data model progression,
maintaining all data models in as close to third-
normal form (3NF) as possible [14]. However, al-
though the goal is a 3NF data model for the atomic
data warehouse, employ practical denormalization
without compromising the basic entity-relationship
structure. For example, one allowable type of de-
normalization technique is where a parent entity in-
stance includes a total attribute computed from add-
ing together the attribute values from child entity
instances. Another allowable type is where child
entity instances include a redundant attribute, such as
“transaction date”, which has been replicated from a
parent entity instance. Denormalization actions
which combine or split entities should generally be
avoided unless necessary in the physical database
environment to address a demonstrated performance
issue.
3.6 Data Warehouse Attribution and Keys
When defining attributes for the entities of the
data warehouse data model, do not define intelligent,
0-7695-2056-1/04 $17.00 (C) 2004 IEEE
compound fields, especially when for attributes mak-
ing up the key of the entity [3]. Each component of a
compound legacy field should be broken out into
detail attributes in the data warehouse, as each com-
ponent is a unit of business data which could have
significance on its own. As a best practice, use na-
tive keys for primary keys; do not use token keys,
which are made up "serial" type numbers with no
meaning that represent a unique set of multiple native
key values. With multidimensional data warehouse
structures, however, it is often recommended to use
token keys because, with the multiple dimension enti-
ties surrounding a central facts entity, the primary
key list of the central facts entity would be the un-
wieldy list of all primary keys of its dimension enti-
ties [8]. This used to be primarily an RDBMS per-
formance issue, but most RDBMS vendors have pro-
vided technical enhancements or indexing capabili-
ties that alleviate the concern for non-numeric, multi-
ple keys. In practice, getting rid of the multiplicity of
keys has more to do with minimizing SQL keying of
power users than maximizing database performance.
A potential compromise would be to carry both the
native keys and the token keys, trading ease of use
for more database space consumed.
3.7 Data Warehouse Loading
When populating the data warehouse from the
legacy, external, and ODS files and databases, you
should employ the use of utility Extract / Transfor-
mation / Load (ETL) purchased software. Similarly,
build necessary dependent data marts from the data
warehouse using an ETL tool [14]. These tools are
somewhat costly, but provide necessary structure and
efficiency in ensuring data quality, transformation
and standardization of data values, and in building
and delivering the data stream necessary to load the
data warehouse.
3.8 Data Warehouse Data Marts
Independent ("end-run") data marts built directly
from legacy, external, and/or ODS data files and da-
tabases should be avoided. It is best to first source
the data into the data warehouse, thus becoming part
of the "single source of truth", and then into a data
mart, if necessary [14]. In addition, the data ware-
house should not feed any ODS or legacy systems
directly, as that makes the 24 hours per day x 7 days
per week operational systems dependent upon the
data warehouse, which is rarely set up in a 24 hours
per day x 7 days per week operational format. For
example, you may wish to compute a "relative cus-
tomer score" ("poor", "good", "better", or "best") to
4
 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004
be used in an operational system such as customer
service for customer treatment workflow. If you
need extensive history from the data warehouse to
compute this score, it is acceptable to "reverse-
source" this data from the data warehouse. However,
you should not make the operational system depend-
ent upon that action -- the operational system should
be able to function with the most recent score avail-
able. Other business and system requirements which
are pushing the architecture towards what is referred
to as "real-time data warehousing” are probably best
implemented as some form of legacy / ODS combi-
nation.
3.9 Data Warehouse Loading
Another consideration for loading the data ware-
house is load frequency. It is likely that no single
frequency (weekly, biweekly, monthly, etc.) will be
used for loading the data warehouse. The frequency
and volume of data associated with outside, legacy,
and ODS systems will likely determine when to in-
voke loading cycles. At the U. S. retailing company,
daily transaction data are collected, staged daily, and
loaded weekly due to the tremendous volume of
transactions (500 million per year). Customer data
for about 190 million individuals are loaded every
two weeks and is done so in conjunction with a cus-
tomer management ODS which operates on a similar
schedule. The credit account data for the retailer's
credit card portfolio are loaded on a monthly basis.
(Note the anomaly the business user must be aware of
-- for a customer who opens a credit account during a
transaction, the transaction data will arrive on the
data warehouse weeks before the customer's credit
account detail. Thus is the double-edged sword of
data warehousing.)
3.10 Data Warehouse Metadata
Data worth warehousing are data worth docu-
menting. This brings up the importance of ensuring a
good metadata thread exists throughout all environ-
ments [14]. There is little one can do regarding leg-
acy metadata, other than dedicating resources to ret-
rofitting any discrepancies uncovered. For the data
warehouse, however, the importance of good meta-
data can not be emphasized enough. ETL teams are
going to rely heavily on the accuracy and complete-
ness of metadata. Data warehouse power users and
casual users are going to access metadata frequently
in order to formulate their data warehouse queries.
The data warehouse metadata must consist of good
business names and definitions, as well as standard-
ized technical names and database formats. Data
0-7695-2056-1/04 $17.00 (C) 2004 IEEE
warehouse data columns defined as "code" type col-
umns should have all potential values and their mean-
ings either encoded in metadata extensions or, if
many values exist, consider building special data
warehouse code / decode tables. If you have a meta-
data repository that supports import and export of
metadata, use it. If not, strongly consider purchasing
a metadata repository package that supports not only
import and export of metadata, but also has Internet
or Intranet deployment capabilities. Since the thirst
for metadata will be great, it is important to have ro-
bust metadata direct access and reporting capability.
At this U. S. retailing company, there was
no formal, centralized metadata repository that could
be used for data warehousing. A cursory review of
metadata repositories available for purchase did not
produce any candidate repositories that matched the
requirements for use in their data warehousing envi-
ronment. Therefore, the development team initially
collected the all-important metadata and entered it
into an MS-Access database, from which rudimentary
reports were used to communicate the metadata.
Later, the MS-Access database was converted to In-
formix, and Java-based Intranet applications were
written to maintain, retrieve, and report on the meta-
data. Also available was bulk-loading of metadata
from MS-Excel spreadsheets.
3.11 Data Warehouse Education / Support
In addition to good metadata describing the data
warehousing environment, you need to provide for
regular and targeted education regarding the data
warehouse and data mart structure and content, SQL
coding techniques, access tools, data privacy, and any
other requests you need to field from the business
users. Consider setting up an official data warehouse
Intranet web site as a clearinghouse for detailed in-
formation, education requests, questions, forms, and
links to related web sites. Some companies have set
up a "decision support center" and allocated person-
nel to it to handle or route questions and assist in
getting data warehouse information to business
groups who are not users of the data warehouse, but
know the data warehouse may contain the detail an-
swer to their business question.
3.12 Data Warehouse Modification
Finally, you should maintain a detailed and con-
trolled data warehouse change management process
that involves the business sponsor, data / information
architecture, data / metadata administration, DBA,
analyst, programmer, and any other group involved in
the data warehousing community [14]. In the change
5
 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004
management process, allow for error corrections,
relatively small change requests, larger work requests
or enhancements, and major projects.
4. Challenges
A number of challenges were encountered during
creation of the U. S. retailing company's data ware-
house. Some of these challenges were anticipated
and others were not. Interestingly, throughout the
project to build the data warehouse, though, organiza-
tional and project process challenges overshadowed
technical challenges.
4.1 Organizational Challenges
Although a business sponsor was selected to rep-
resent the data warehouse, this sponsor was a mem-
ber of one of four vertical business units participating
in the data warehouse project. Interdepartmental
cooperative promises were made, but annual incen-
tives for members of these departments were tied to
their business performance alone. As well, the an-
nual incentives for the information technology asso-
ciates selected to participate were also tied to their
assigned business unit's performance. No incentive
dollars were tied to the data warehouse project di-
rectly. The difficulty here is that maximum attention
was paid to departmental systems, with secondary
consideration given to the data warehouse project.
This affected work priorities and project time-line
adjustments had to be made on a regular basis.
4.2 Data Sourcing Challenges
The data sourcing challenges have their roots in
the legacy system environment. Many companies
have no real system of record for critical enterprise
data, their legacy systems and data being aligned
more on critical process boundaries instead. Since
ODS systems and ODS databases are a relatively
recent spin-off of data warehousing, there is typically
little or no integrated ODS data from which to source
the data warehouse, as well. In an environment with
weak or informal data management practices, data
subjects are either not clearly established or not used
at all. Saddle this net situation with weak or nonexis-
tent metadata, then the data sourcing effort will seem
mammoth, and it usually is. This is why the phrase
"data warehouse sourcing" has been equated with the
phrase "data archaeology" -- you may know where to
dig, but you simply do not have any idea what the
next shovel-full will give you. Even with this reali-
zation, most data warehousing projects, even with the
use of an ETL tool, woefully underestimate the data
0-7695-2056-1/04 $17.00 (C) 2004 IEEE
warehouse sourcing requirement itself, sometimes by
as much as 100%.
A special data warehouse sourcing challenge is
what data to select to put in it. Legacy systems con-
tain many terabytes of data. How can anyone select
what subset of data to copy to the data warehouse?
The technique that represents perhaps the best way to
do this involves selecting key master files and data-
bases in the legacy environment and having the in-
tended business users rank each and every element
and column as to its significance from a business
intelligence standpoint. This could be as simple as a
"yes" / "no" designation, to a scoring system whereby
the resultant list could be sorted by score and evalu-
ated at many points of cost versus benefit. In addi-
tion, some business data that would score low now
may score higher in the future due to business, mar-
keting, societal, compliance, legal, or other factors.
Regardless of the method of selection, there is a risk
that not all needed detailed data will be captured.
However, as long as the data warehousing project is
never "closed", there will be future opportunity to
include that data, but only to the extent that this data
are kept from a historical standpoint.
4.3 Technological Pressures
As the data warehouse and its environment ma-
ture, certain technological pressures surface that seem
natural and creative to middle- and upper-level man-
agement, but violate standard data warehousing ar-
chitecture precepts. The first stems from the fact that
a data warehouse built with excellent cleansing and
integration techniques yields data that can be of
higher quality than the legacy data from which it
came. Top-level executives start referring to their
"Customer Data Warehouse" as their "Customer Da-
tabase". In turn, they will exert pressure to update
legacy customer data from the data warehouse, not
realizing the difference in data currency between the
warehouse (up to two-week old customer data) and
the legacy system (near-real-time).
Secondly, there is pressure to push the data
warehouse into a real-time or near-real-time envi-
ronment. This idea often comes from on-site vendors
that would dearly love to see the data warehouse
pushed into a 24 hours per day x 7 days per week
environment -- they would be the most likely recipi-
ents of the cost of the equipment and expertise to
support a multi-terabyte operational database in a
real-time environment and connect it to the opera-
tional legacy systems, as well. After seven years of
existence, the data warehouse at the U. S. retailing
company satisfies business user requirements by op-
erating on a service level agreement of 10 hours per
6
 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004
day and 5 days per week. The cost to operate this
database on a 24 hours per day x 7 days per week
basis would be several times higher.
Thirdly, there is pressure to build independent
data marts from non-data warehouse data directly
from legacy or ODS files and databases. Some argue
that this is nothing more than implementing a hybrid
Inmon / Kimball data warehousing environment,
however, there is no such thing. There are advan-
tages to either over the other, but only one can be
selected as the architecture for any particular data
warehousing implementation. In the case where the
Inmon style has been selected, all data marts should
be created from the data warehouse, where the data
has already been scrubbed, integrated, and stored
with a high degree of quality [14]. Creating data
marts from different sources for the same data allows
for error and variable tolerances such that different
answers may be given to the exact same business
intelligence question. Always create your data marts
from the "single source of truth" -- the data ware-
house.
A fourth technological pressure is to proliferate
application-specific data marts in an uncontrolled
fashion. It takes time, education, and experience to
become a skilled query writer using native SQL.
Many power users have no problem accessing the
native data warehouse directly using SQL. However,
new users of the data warehouse could easily become
discouraged if not enough time, education, and op-
portunity to practice are allowed to attain SQL self-
sufficiency. A typical solution would be to create a
data mart containing only the subset of data of inter-
est, perhaps pre-summarized and pared down to meet
a specific area of business interest. This, in itself, is
not a bad thing to do if there are a multitude of busi-
ness users that could benefit from this data. How-
ever, if only this one user will benefit, then this user
will request additional data marts. Multiply this by
several business users of the same skill, and you will
soon have uncontrolled proliferation of data marts.
The solution is not to prevent all creation of data
marts, but to analyze requests for data marts (views)
against other requests for data marts (views) and in-
stall actual data marts that satisfy more than one
view. For example, if one user needs view ABDE, a
second needs view ACE, a third needs view ABE,
0-7695-2056-1/04 $17.00 (C) 2004 IEEE
and a fourth needs view ABD, you could build a data
mart supporting view ABCDE to satisfy all four users
(and other users requiring the same views or even
new views of interest BCD, BCE, BCDE, etc.).
4.4 Customer Data Challenges
Customer name and address data is perhaps the
most difficult to establish and maintain, particularly
if you have multiple stove-pipe systems each main-
taining their own customer master files or databases.
Do not underestimate the effort needed to overcome
this challenge. You may need to purchase software
to assist you in standardizing name and address for-
mats. You will have to write some form of a cus-
tomer management system to collect the customer
data you have and determine if one vertical business
unit's "John Smith" is the same as another vertical
business unit's "John Smith". You may even need to
rely on an external vendor to assist you in keeping up
with name, address, and telephone number changes.
At the U. S. retailing company, no less than sixteen
customer master files had been identified across the
multiple businesses. Long term, their goal is to in-
stall a customer management system as a robust ODS
containing multiple detailed source customer data by
vertical business unit. A ranking process "survives"
the best individual name, address, and telephone
number data and prepares it for transmission to an
external vendor. The vendor matches the name and
address data to its files and appends an individual key
to the individual, as well as an address key to the
address. The data is then transmitted back from the
vendor and loaded into the data warehouse, after
which sophisticated SQL households individuals ac-
cording to those having the same address or other
shared detail data. History is kept on individuals
migrating from household to household, as well as
individuals and households migrating from address to
address. Currently, eight of the company's sixteen
customer master files are included, with the remain-
ing eight targeted for future incorporation, at which
time the customer management system ODS will be
upgraded and integrated with the sixteen legacy sys-
tems for two-way customer data communication.
7
 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004

Figure 2. Sample List of Customer Interactions

Customer Interaction
Sample List

Customer Interaction

Credit Application Credit Billing

Survey Mailing Credit Account Payment

Survey Response Catalog Request

Telemarketing Contact Catalog Mailing

POS Sale Transaction Other Purchase

POS Sale / Return Catalog Order

Home Improvement Item Insurance Coverage Payment

Parts Purchase Order Credit Protection Payment

Service Contract Agreement Club Membership / Fee

5. Successes customer interactions in the areas of inbound

customer requests and/or complaints, outbound cus-
tomer telemarketing, survey requests and responses,
At the U. S. retailing company, the first success
and other customer interactions.
came in 1995 with the initial, eleven-table, “credit-
By segmenting their customer portfolio, the
focused” proof-of-concept data warehouse. The
company has been able to provide both enterprise
eighty-gigabyte Inmon-style data warehouse was
(cross-business selling) and vertical business unit
used to select customers for a targeted credit-
marketing opportunities, along with enhanced access
stimulation marketing program. The additional mer-
to enterprise customer data. By establishing these
chandising and credit profit generated by this proof-
high-relevancy marketing programs, the company has
of-concept data warehouse exceeded the estimated
been able to participate in and respond to customers’
cost to build first full-blown, sixty-five-table, six-
life-style (credit heavy revolver, high tech consumer,
hundred-gigabyte credit customer data warehouse in
jewelry purchaser, etc.), life-stage (young married,
1996. The data warehouse has since grown to seven
mid-life spenders, empty-nesters, etc.), and life-event
terabytes with two hundred tables and two thousand
(newlyweds, birth of a baby, new home buyer, etc.)
seven hundred columns. The combined customer and
marketing opportunities.
prospect list on the data warehouse includes everyone
In addition, enhanced contact management has
in the U. S. who is eighteen years old and older.
been engaged for proactive management of high-
There are over six hundred registered users of the
value customer segments, alignment of vertical busi-
data warehouse.
ness unit and enterprise needs, and incorporation of
In addition to robust customer information, the
customer preferences. The data warehouse has al-
U. S. retaining company has captured many “cus-
lowed the company to strengthen customer relation-
tomer interactions” (see Figure 2) and associated
ship management (CRM) core capabilities and busi-
them with individuals. A “customer interaction”
ness partnerships. Today, there are many depart-
represents activity between the company and an indi-
ments benefiting from queries and requests for data
vidual, such as a store sale transaction, a return or
warehouse data, many anticipated, some not. Al-
exchange, an Internet sale, a catalog order, a service
though not planned, the data warehouse has been a
contract agreement, a credit insurance coverage pay-
valuable source of purchase and customer data in
ment, and other activities. Capturing these customer
case of a manufacturer recall of merchandise. In ad-
interactions has enabled the company to gain a cus-
dition, the company has been able to investigate and
tomer intimacy not attainable without the critical
alleviate some inventory shrinkage challenges.
mass of data they have amassed regarding their cus-
Above all, however, the company has been able
tomers and their customers’ preferences. Company
to leverage and share enterprise customer data to the
plans call for incorporation of even more
benefit of the entire company.

0-7695-2056-1/04 $17.00 (C) 2004 IEEE 8

 Proceedings of the 37th Hawaii International Conference on System Sciences - 2004
6. Discussions
The dilemma of choosing one or the other style
for data warehousing is a considerable issue in real
life data warehousing to solve organizational prob-
lems and bring benefits to the organization. The se-
lection depends on many factors and considerations.
There are also considerable philosophical debates,
obstacles, and pros and cons as to the selection of a
data warehousing methodology. However, whatever
methodology is chosen it must meet the business re-
quirements of the organization and be flexible and
scalable. In other words the methodology must
minimize the gaps between the business processes
and the technology that are being used to run the
business in the organization [5, 12]. The best prac-
tices (Inmon style) that have been adopted by the
company enabled them to create and deliver the nec-
essary analytical environment to meet the changing
needs of business.
7. References
[1] Agosta, L. (2000). The Essential Guide to Data Ware-
housing. Prentice Hall PTR, Upper Saddle River,
NJ 07458.
[2] Anahory, S and Murray, D. (1997). Data Warehousing
in the Real World: A Practical Guide for Building De-
cision Support Systems. Addison Wesley Longman
Limited, England.
0-7695-2056-1/04 $17.00 (C) 2004 IEEE
[3] Armstrong, R. (2002). White paper by NCR Corpora-
tion - The Fallacy of Data Mart Centric Strategies
(Short Term Gain, Long Term Pain).
[4] Chen, P. (1976). The Entity-Relationship Model –
Towards a Unified View of Data, ACM Transactions
on Database Systems, pp 9-36.
[5] Chowdhury, S (2002). Lecture notes on Data Ware-
house and Data Mining. The College of Business Ad-
ministration, Roosevelt University, IL.
[6] Inmon, B. (1999). “The Problem with Dimensional
Modeling” DM Review Magazine Archived Article.
[7] Ismail, W. and Chowdhury, S. (2003). Database Ap-
plications in Business. In Proceedings of the MBAA,
Chicago, IL.
[8] Kimball, R. (1996). The Data Warehouse Toolkit:
Practical Techniques for Building Dimensional Data
Warehouses, John Wiley.
[9] Kroenke, D. (2002). Database Processing – Funda-
mentals, Design and Implementation (8th ed.). Pearson
Education, Inc.
[10] Letowski, B. Parzatka, H. Woods, N (2002). North-
Wind Star Schema – a project work presented and
submitted in Seminar on Data Warehouse and Data
Mining at the College of Business Administration,
Roosevelt University, IL. 2002.
[11] McFadden, F. Hoffer, J. and Prescott, M (1999). Mod-
ern Database Management. (5th ed.). Addison-Wesley
Educational Publishers, Inc.
[12] Sperley, E (1999). "Planning, Building, and Imple-
mentation". The Enterprise Data Warehouse. Prentice
Hall.
[13] Utley, C. (2002). “Designing the Star Schema Data-
base” Data Warehousing Resources, November 2002.
[14] Inmon W H, Imhoff C, Sousa R. Corporate Informa-
tion Factory. New York, NY: John Wiley & Sons, Inc.,
1998.
[15] Data Management Association. Guidelines to Imple-
menting Data Resource Management. Bellevue, WA:
DAMA International, 2002.
9