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 Abstract
The paper presents the data warehousing architecture 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 company chose the Inmon style due to a unique combination 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 currently 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 Relational Database Management System (RDBMS) software employed today at this company for data warehousing 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 organizational, 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 expansion. 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 allowed the company to strengthen customer relationship management (CRM) core capabilities and business partnerships. Today, there are many 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 experiencing the usual growing pains of the middle 1990’s. The diversity of businesses supported by multiple business units and the company’s Information Technology organization had resulted in “stove-pipes” of data, along with corresponding computer applications, 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


Under the Kimball approach. 4. but the above list is sufficient to illustrate the need for the flexibility of an application-neutral. data are arranged according to the rules of normalization and remain applicationand data-view-independent [13]. assumed preference. data are typically summarized by higher-level dimensions [8]. While both styles obtain source data from legacy batch and online operational systems and specialized Operational Data Stores (ODS). it can be termed an “enterprise” data warehouse. or perceived net advantages. An additional advantage to the Inmon approach is the ability to create dependent data marts from the atomic data warehouse for those situations where a repetitive reporting requirement or application-specific need exists [13]. only one phase of data sourcing is required for standardizing the data [13]. Due to traditional business “stove-pipes” of data. The Inmon style calls for an atomic-level. As depicted. Any needed data marts are built with data from the data 0-7695-2056-1/04 $17. such as household demographics or ZIP code geo-demographics. Under the Inmon approach. 11. 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]. existing technologies. transaction-level data. as well as the recommended analysis and selection process of each style. Under the Kimball approach. Under the Kimball approach. In order to handle the capabilities of drilling up. and sideways within a multidimensional structure.00 (C) 2004 IEEE 2 . while the SQL can get quite complex. Data Warehousing Architecture Many decisions must be made when implementing a data-warehousing environment. 12]. 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. Companies usually pick one style over the other based upon a combination of employee expertise. may also be used as sources for data warehouse data. The U. There were other factors involved in the decision to use the Inmon style. consultant or vendor recommendation. as shown in Figure 1. In other words. therefore. not integrated nor standardized. As if the technology decisions were not difficult enough in and of themselves. third-normal form (3NF) relational format in which to store extracted and transformed data. There was also a general absence of Business Intelligence tools for accessing data warehouse data. Outside sources. Under the Inmon approach. sourcing the legacy system data would require a two-phase approach. In other words. due to its typical arrangement of dimension entities around a central facts entity [3. while the Kimball style calls for a multidimensional style “dimension and fact” arrangement in which to store extracted and transformed data. the business user typically requires a Business Intelligence tool. potential cross-business use of data was unknown. down. they differ in the arrangement of this data in the data warehouse itself. deciding which data warehousing architecture approach to use is sometimes even more difficult. Although highly debated in some data warehousing data architecture communities. the detail advantages and disadvantages. Sufficient expertise existed in the business community to support user self-sufficiency incorporating native SQL against an atomic-level data warehouse.2004 2. Under the Kimball approach. 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. authoring SQL to access data arranged in a multidimensional database would be a very complex task. data are arranged in an application. Under the Inmon approach. The Inmon style is considered application neutral. 10. consists of four distinct. The architecture adopted as the best practice. data are typically kept at the lowest level of detail [13]. the legacy operational systems and ODS are used as sources for data warehouse data. Legacy system data were predominantly nondatabase and. it still will not be as complicated as that needed to access a multidimensional structure and perform drilling navigation [13]. budget. but rather “Product Type” or some other higherlevel dimensional measure.or data-view-specific manner [8]. with Bill Inmon being credited with inventing (or first formalizing) the concept. it would be rare to employ “Transaction ID” as the lowest-level dimen- sion. If the Inmon style data warehouse has data covering most or all data subjects for the company. such as used in On-Line Analytical Processing (OLAP) [8]. 3NF database to house and maintain a “single source of truth” of company data. 7. 11]. S. 9. Both Bill Inmon and Ralph Kimball are acknowledged experts in the data warehousing field. while the Kimball style has data prearranged by certain dimensions according to desired output [6. one for standardizing and one for summarizing and arranging facts by their dimensions [8]. Under the Inmon approach. interacting components. is beyond the scope of this paper. the sum of all individual multidimensional data structures is considered the “enterprise” data warehouse.Proceedings of the 37th Hawaii International Conference on System Sciences . With the Kimball style. Kimball’s multidimensional style design is often referred to as a “star schema”.

To paraphrase a popular saying. not just during building of the data warehouse. Sample. / stewardship function and process [2]. as the data used to build them would not be of the same assured quality as the data warehouse “single source of truth”. your organization should use data warehousing industry experts for both validation and expertise defi- 0-7695-2056-1/04 $17. and selection process can be a project in itself. but ongoing continually after the 3. Chosen Data Warehousing Architecture 3. not as individual vertical business units (“stove pipes”). In conjunction with the business champions. Multidimensional •Time Variant •Non-Volatile •Much history •Customized for local / application use •User-friendly presentation •Repetitive requests / processing Figure 1. testing. and was handled as such at the U. 3. It is extremely important for the business champion to engage data warehouse business partners in an “enterprise” manner. so the various hardware and software selection decisions will not be covered. The implication here is that the best plan is a flexible one. 2. If one does not exist. “Independent” data marts should be discouraged. retailing company. fully leverage your Information Architecture organization’s enterprise data model [13]. thus being “dependent” data marts. Those are best left up to the company technicians and consultants who are charged with selecting the best set of technological solutions to match the business problem. Best Practices As a reminder. To aid in accurately building the first instantiation of the data warehouse. 15]. data warehouse is built [1. this is an opportune time to commence building and documenting one. 3. Data owners and data stewards are indispensable when negotiating and standardizing multi-user differing views of the same data.00 (C) 2004 IEEE 3 . research. What may be interesting is that both the hardware platform (CPU and disk drives) and Relational Database Management System (RDBMS) software employed today at this company for data warehousing is not the same as was selected for the first instantiation in 1996.3 Data Warehouse Expertise In addition to the high-level business champion. Treat the data warehouse as an ongoing system and spawn specific projects when appreciable expansion is needed. the thrust of this paper is not technological. fully utilize or establish a data ownership Legacy Operational Systems Operational Data Stores Data Warehouse Data Marts •Process Orientation •Not integrated •Current-valued with little or no history •Volatile •Detailed •Not easily accessed •Subject Orientation •Integrated •Current-valued with light history •Volatile •Detailed •Not arranged / tuned for mass retrieval •Subject Orientation •Integrated •Time Variant •Non-Volatile •Detail with much history •Unpredictable requests / processing •Enterprise “single source of truth” •Data subset: Summary.2004 warehouse.1 Data Warehouse Sponsorship One of the basic best practices you can employ for data warehousing is to ensure that a high-level business champion exists.2 Data Warehouse Growth Most data warehousing initiatives have found that there is a continuous need for incremental additions to the data warehouse [2]. “Data warehousing is not a destination – it is a journey”.Proceedings of the 37th Hawaii International Conference on System Sciences . Keeping your data warehouse team intact after the initial build is very important in order to sustain the capability to react to this need. S. This analysis.

perhaps employing an evolutionary prototype or proof-of-concept development methodology [15]. Another allowable type is where child entity instances include a redundant attribute. and/or ODS data files and databases should be avoided. the data warehouse should not feed any ODS or legacy systems directly. Be sure to interview. Again. Denormalization actions which combine or split entities should generally be avoided unless necessary in the physical database environment to address a demonstrated performance issue. as each component is a unit of business data which could have significance on its own. With multidimensional data warehouse structures. help gain expertise with a smaller set of data (and. "good". external. such as “transaction date”. For example.4 Data Warehouse Scope For the initial release of your data warehouse. hire. This may seem rhetorical. there are a number of industry trade shows and conferences from which beginner to experienced practitioners can benefit greatly. It is best to first source the data into the data warehouse. which are made up "serial" type numbers with no meaning that represent a unique set of multiple native key values. "better". increasing their overall commitment and support of the concept. although the goal is a 3NF data model for the atomic data warehouse. multiple keys. A potential compromise would be to carry both the native keys and the token keys. In addition. do not define intelligent. 3. select and use these opportunities based upon the style of data warehousing you choose. however. 3. the primary key list of the central facts entity would be the unwieldy list of all primary keys of its dimension entities [8]. and in building and delivering the data stream necessary to load the data warehouse. as that makes the 24 hours per day x 7 days per week operational systems dependent upon the data warehouse. it is often recommended to use token keys because. Also.2004 ciencies [14]. or "best") to 3. thus becoming part of the "single source of truth". once a data warehousing architecture is chosen. compound fields. if necessary [14]. These tools are somewhat costly. build necessary dependent data marts from the data warehouse using an ETL tool [14]. but most RDBMS vendors have provided technical enhancements or indexing capabilities that alleviate the concern for non-numeric.8 Data Warehouse Data Marts Independent ("end-run") data marts built directly from legacy. and contract with individuals and firms according to the data warehousing style. getting rid of the multiplicity of keys has more to do with minimizing SQL keying of power users than maximizing database performance. In practice. 3. which has been replicated from a parent entity instance. use native keys for primary keys.5 Data Warehouse Data Modeling It is important. This is an excellent way of demonstrating the informational and monetary benefits of data warehousing to the company's top-level management. but provide necessary structure and efficiency in ensuring data quality. 3. which is rarely set up in a 24 hours per day x 7 days per week operational format. Similarly. Using a robust data modeling tool. external. and then into a data mart.Proceedings of the 37th Hawaii International Conference on System Sciences . you choose. especially when for attributes making up the key of the entity [3]. This will minimize initial investment. 0-7695-2056-1/04 $17. trading ease of use for more database space consumed. follow a typical conceptual to logical to physical data model progression.7 Data Warehouse Loading When populating the data warehouse from the legacy. and deliver business value sooner. transformation and standardization of data values. one allowable type of denormalization technique is where a parent entity instance includes a total attribute computed from adding together the attribute values from child entity instances. For example. maintaining all data models in as close to thirdnormal form (3NF) as possible [14]. and ODS files and databases. limit the number of data subjects implemented and the extent of their content. However. thus. but there can be many opportunities and much pressure to short-cut the process necessary to create a quality data warehouse.00 (C) 2004 IEEE 4 . employ practical denormalization without compromising the basic entity-relationship structure.6 Data Warehouse Attribution and Keys When defining attributes for the entities of the data warehouse data model. with the multiple dimension entities surrounding a central facts entity. As a best practice. you should employ the use of utility Extract / Transformation / Load (ETL) purchased software. a smaller set of technical challenges). This used to be primarily an RDBMS performance issue. do not use token keys. to adhere to it from beginning to end . Each component of a compound legacy field should be broken out into detail attributes in the data warehouse. you may wish to compute a "relative customer score" ("poor". and perhaps even the technologies.

it is acceptable to "reversesource" this data from the data warehouse. It is likely that no single frequency (weekly. 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 combination. For the data warehouse. Therefore. legacy. The credit account data for the retailer's credit card portfolio are loaded on a monthly basis. S. Data warehouse power users and casual users are going to access metadata frequently in order to formulate their data warehouse queries. use it. Later. Also available was bulk-loading of metadata from MS-Excel spreadsheets.11 Data Warehouse Education / Support In addition to good metadata describing the data warehousing environment. forms.10 Data Warehouse Metadata Data worth warehousing are data worth documenting. The frequency and volume of data associated with outside. and Java-based Intranet applications were written to maintain. however. daily transaction data are collected. 3. the importance of good metadata can not be emphasized enough. etc. and links to related web sites. the development team initially collected the all-important metadata and entered it into an MS-Access database. SQL coding techniques. from which rudimentary reports were used to communicate the metadata.) warehouse data columns defined as "code" type columns should have all potential values and their meanings either encoded in metadata extensions or. if many values exist. and loaded weekly due to the tremendous volume of transactions (500 million per year). other than dedicating resources to retrofitting any discrepancies uncovered. 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 environment. you should not make the operational system dependent upon that action -. the transaction data will arrive on the data warehouse weeks before the customer's credit account detail. and any other group involved in the data warehousing community [14]. data / metadata administration. At the U. Customer data for about 190 million individuals are loaded every two weeks and is done so in conjunction with a customer management ODS which operates on a similar schedule. Thus is the double-edged sword of data warehousing. access tools. you should maintain a detailed and controlled data warehouse change management process that involves the business sponsor. and report on the metadata. education requests. At this U. There is little one can do regarding legacy metadata. If you have a metadata repository that supports import and export of metadata. but also has Internet or Intranet deployment capabilities. Data 3. there was no formal. Since the thirst for metadata will be great. (Note the anomaly the business user must be aware of -. This brings up the importance of ensuring a good metadata thread exists throughout all environments [14].12 Data Warehouse Modification Finally. analyst. consider building special data warehouse code / decode tables. data privacy. If you need extensive history from the data warehouse to compute this score. S. In the change 0-7695-2056-1/04 $17.2004 be used in an operational system such as customer service for customer treatment workflow. staged daily. as well as standardized technical names and database formats. retailing company. data / information architecture. biweekly. 3. but know the data warehouse may contain the detail answer to their business question. Some companies have set up a "decision support center" and allocated personnel 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. programmer.Proceedings of the 37th Hawaii International Conference on System Sciences . The data warehouse metadata must consist of good business names and definitions. the MS-Access database was converted to Informix. retrieve. centralized metadata repository that could be used for data warehousing.for a customer who opens a credit account during a transaction. If not. 3. and any other requests you need to field from the business users.) will be used for loading the data warehouse. However. and ODS systems will likely determine when to invoke loading cycles.the operational system should be able to function with the most recent score available.9 Data Warehouse Loading Another consideration for loading the data warehouse is load frequency. it is important to have robust metadata direct access and reporting capability. Consider setting up an official data warehouse Intranet web site as a clearinghouse for detailed information.00 (C) 2004 IEEE 5 . monthly. strongly consider purchasing a metadata repository package that supports not only import and export of metadata. questions. ETL teams are going to rely heavily on the accuracy and completeness of metadata. you need to provide for regular and targeted education regarding the data warehouse and data mart structure and content. retailing company. DBA.

The difficulty here is that maximum attention was paid to departmental systems. there is pressure to push the data warehouse into a real-time or near-real-time environment. 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 -. 4. Interestingly. This could be as simple as a "yes" / "no" designation. Some of these challenges were anticipated and others were not. 4. In addition. not realizing the difference in data currency between the warehouse (up to two-week old customer data) and the legacy system (near-real-time). but annual incentives for members of these departments were tied to their business performance alone. Even with this realization. and it usually is. After seven years of existence. 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. S.3 Technological Pressures As the data warehouse and its environment mature. Challenges A number of challenges were encountered during creation of the U. Interdepartmental cooperative promises were made. Secondly. relatively small change requests. this sponsor was a member of one of four vertical business units participating in the data warehouse project. This is why the phrase "data warehouse sourcing" has been equated with the phrase "data archaeology" -. as well. Regardless of the method of selection. data subjects are either not clearly established or not used at all. some business data that would score low now may score higher in the future due to business. throughout the project to build the data warehouse. but violate standard data warehousing architecture precepts.2004 management process. No incentive dollars were tied to the data warehouse project directly. sometimes by as much as 100%. warehouse sourcing requirement itself. may know where to dig. the data warehouse at the U. A special data warehouse sourcing challenge is what data to select to put in it.and upper-level management. there will be future opportunity to include that data. certain technological pressures surface that seem natural and creative to middle. then the data sourcing effort will seem mammoth. legal. However. the annual incentives for the information technology associates selected to participate were also tied to their assigned business unit's performance. marketing. they will exert pressure to update legacy customer data from the data warehouse. Since ODS systems and ODS databases are a relatively recent spin-off of data warehousing. 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 databases in the legacy environment and having the intended business users rank each and every element and column as to its significance from a business intelligence standpoint. most data warehousing projects.00 (C) 2004 IEEE 6 . woefully underestimate the data 0-7695-2056-1/04 $17. as well. societal. In an environment with weak or informal data management practices. but only to the extent that this data are kept from a historical standpoint. Top-level executives start referring to their "Customer Data Warehouse" as their "Customer Database". with secondary consideration given to the data warehouse project. allow for error corrections. even with the use of an ETL tool. larger work requests or enhancements. This affected work priorities and project time-line adjustments had to be made on a regular basis. but you simply do not have any idea what the next shovel-full will give you. there is a risk that not all needed detailed data will be captured. their legacy systems and data being aligned more on critical process boundaries instead. compliance. S. Many companies have no real system of record for critical enterprise data.1 Organizational Challenges Although a business sponsor was selected to represent the data warehouse. retailing company's data warehouse. In turn. and major projects.they would be the most likely recipients 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 operational legacy systems.2 Data Sourcing Challenges The data sourcing challenges have their roots in the legacy system environment. retailing company satisfies business user requirements by operating on a service level agreement of 10 hours per 4.Proceedings of the 37th Hawaii International Conference on System Sciences . organizational and project process challenges overshadowed technical challenges. 4. Saddle this net situation with weak or nonexistent metadata. there is typically little or no integrated ODS data from which to source the data warehouse. Legacy systems contain many terabytes of data. As well. as long as the data warehousing project is never "closed". to a scoring system whereby the resultant list could be sorted by score and evaluated at many points of cost versus benefit. or other factors.

0-7695-2056-1/04 $17. their goal is to install a customer management system as a robust ODS containing multiple detailed source customer data by vertical business unit. You may need to purchase software to assist you in standardizing name and address formats. It takes time. there is no such thing. Many power users have no problem accessing the native data warehouse directly using SQL. after which sophisticated SQL households individuals according to those having the same address or other shared detail data. is not a bad thing to do if there are a multitude of business users that could benefit from this data. BCE.).00 (C) 2004 IEEE 7 .the data warehouse.Proceedings of the 37th Hawaii International Conference on System Sciences . education. History is kept on individuals migrating from household to household. but to analyze requests for data marts (views) against other requests for data marts (views) and install actual data marts that satisfy more than one view. The cost to operate this database on a 24 hours per day x 7 days per week basis would be several times higher. 4. if only this one user will benefit. Long term. education. eight of the company's sixteen customer master files are included. address. no less than sixteen customer master files had been identified across the multiple businesses. and telephone number data and prepares it for transmission to an external vendor. integrated. and you will soon have uncontrolled proliferation of data marts. particularly if you have multiple stove-pipe systems each maintaining their own customer master files or databases. however. if one user needs view ABDE. where the data has already been scrubbed. 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. BCDE. A fourth technological pressure is to proliferate application-specific data marts in an uncontrolled fashion. but only one can be selected as the architecture for any particular data warehousing implementation. The vendor matches the name and address data to its files and appends an individual key to the individual. in itself. You will have to write some form of a customer 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". Multiply this by several business users of the same skill. etc. Do not underestimate the effort needed to overcome this challenge. There are advantages to either over the other. as well as an address key to the address. Always create your data marts from the "single source of truth" -. A ranking process "survives" the best individual name. However. Thirdly. However. and a fourth needs view ABD. A typical solution would be to create a data mart containing only the subset of data of interest.2004 day and 5 days per week. with the remaining eight targeted for future incorporation. and telephone number changes. This. a second needs view ACE. You may even need to rely on an external vendor to assist you in keeping up with name. perhaps pre-summarized and pared down to meet a specific area of business interest. new users of the data warehouse could easily become discouraged if not enough time.4 Customer Data Challenges Customer name and address data is perhaps the most difficult to establish and maintain. 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. In the case where the Inmon style has been selected. address. The data is then transmitted back from the vendor and loaded into the data warehouse. and stored with a high degree of quality [14]. a third needs view ABE. and experience to become a skilled query writer using native SQL. At the U. S. there is pressure to build independent data marts from non-data warehouse data directly from legacy or ODS files and databases. Currently. then this user will request additional data marts. For example. and opportunity to practice are allowed to attain SQL selfsufficiency. all data marts should be created from the data warehouse. Some argue that this is nothing more than implementing a hybrid Inmon / Kimball data warehousing environment. as well as individuals and households migrating from address to address. retailing company. The solution is not to prevent all creation of data marts. at which time the customer management system ODS will be upgraded and integrated with the sixteen legacy systems for two-way customer data communication.

Although not planned. Above all. eleven-table. many anticipated. In addition to robust customer information. the company has been able to participate in and respond to customers’ life-style (credit heavy revolver. The combined customer and prospect list on the data warehouse includes everyone in the U. etc. sixhundred-gigabyte credit customer data warehouse in 1996. and incorporation of customer preferences. survey requests and responses. S. Capturing these customer interactions has enabled the company to gain a customer intimacy not attainable without the critical mass of data they have amassed regarding their customers and their customers’ preferences. the U. The eighty-gigabyte Inmon-style data warehouse was used to select customers for a targeted creditstimulation marketing program. the data warehouse has been a valuable source of purchase and customer data in case of a manufacturer recall of merchandise.2004 Figure 2. a catalog order. an Internet sale. A “customer interaction” represents activity between the company and an individual. such as a store sale transaction. Company plans call for incorporation of even more customer interactions in the areas of inbound customer requests and/or complaints. retailing company. 0-7695-2056-1/04 $17. outbound customer telemarketing. Sample List of Customer Interactions Customer Interaction Sample List Customer Interaction Credit Application Survey Mailing Survey Response Telemarketing Contact POS Sale Transaction POS Sale / Return Home Improvement Item Parts Purchase Order Service Contract Agreement Credit Billing Credit Account Payment Catalog Request Catalog Mailing Other Purchase Catalog Order Insurance Coverage Payment Credit Protection Payment Club Membership / Fee 5. “creditfocused” proof-of-concept data warehouse. some not. the first success came in 1995 with the initial. jewelry purchaser. In addition. The data warehouse has allowed the company to strengthen customer relationship management (CRM) core capabilities and business partnerships. the company has been able to leverage and share enterprise customer data to the benefit of the entire company. who is eighteen years old and older. The data warehouse has since grown to seven terabytes with two hundred tables and two thousand seven hundred columns. alignment of vertical business unit and enterprise needs. life-stage (young married. a service contract agreement. etc. birth of a baby. etc. and life-event (newlyweds. The additional merchandising and credit profit generated by this proofof-concept data warehouse exceeded the estimated cost to build first full-blown. and other customer interactions. There are over six hundred registered users of the data warehouse. and other activities. new home buyer. the company has been able to provide both enterprise (cross-business selling) and vertical business unit marketing opportunities.00 (C) 2004 IEEE 8 . S. empty-nesters. By segmenting their customer portfolio. mid-life spenders.) marketing opportunities. By establishing these high-relevancy marketing programs. In addition. high tech consumer.Proceedings of the 37th Hawaii International Conference on System Sciences . however. the company has been able to investigate and alleviate some inventory shrinkage challenges. Successes At the U. retaining company has captured many “customer interactions” (see Figure 2) and associated them with individuals. a return or exchange. enhanced contact management has been engaged for proactive management of highvalue customer segments.). S. sixty-five-table. a credit insurance coverage payment.). along with enhanced access to enterprise customer data. Today. there are many departments benefiting from queries and requests for data warehouse data.

“Designing the Star Schema Database” Data Warehousing Resources. England. Upper Saddle River. Parzatka. The Enterprise Data Warehouse. (2000). ACM Transactions on Database Systems. and Prescott. New York. IL. (2002). Roosevelt University. Long Term Pain). 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. Chicago. Corporate Information Factory.The Fallacy of Data Mart Centric Strategies (Short Term Gain. (1997). N (2002). Woods. and Chowdhury. C. (1976). pp 9-36. 0-7695-2056-1/04 $17. IL. [3] Armstrong. 12]. 2002. [9] Kroenke. Guidelines to Implementing Data Resource Management. The Entity-Relationship Model – Towards a Unified View of Data. [10] Letowski. (2003). W. and Implementation". obstacles. The best practices (Inmon style) that have been adopted by the company enabled them to create and deliver the necessary analytical environment to meet the changing needs of business.). Building. The selection depends on many factors and considerations. E (1999). [2] Anahory. NorthWind Star Schema – a project work presented and submitted in Seminar on Data Warehouse and Data Mining at the College of Business Administration. [8] Kimball. B. R. The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses.). (2002). [14] Inmon W H.2004 6. Pearson Education.Proceedings of the 37th Hawaii International Conference on System Sciences . NY: John Wiley & Sons. Database Applications in Business.. (5th ed. Bellevue. (2002). Addison-Wesley Educational Publishers. “The Problem with Dimensional Modeling” DM Review Magazine Archived Article. D. [7] Ismail. J. M (1999). S. Imhoff C. Prentice Hall PTR. [15] Data Management Association. NJ 07458. Database Processing – Fundamentals. The Essential Guide to Data Warehousing. Prentice Hall. The College of Business Administration. [13] Utley. John Wiley. White paper by NCR Corporation . WA: DAMA International. [11] McFadden. 1998. Addison Wesley Longman Limited. In Proceedings of the MBAA. L. F. Inc. B. Roosevelt University. Modern Database Management. H. Data Warehousing in the Real World: A Practical Guide for Building Decision Support Systems. whatever methodology is chosen it must meet the business requirements of the organization and be flexible and scalable. [6] Inmon. November 2002. Design and Implementation (8th ed. 7. P. References [1] Agosta. S (2002). (1999). However. 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 problems and bring benefits to the organization. IL. Inc. Inc.00 (C) 2004 IEEE 9 . and pros and cons as to the selection of a data warehousing methodology. R. [12] Sperley. 2002. [5] Chowdhury. [4] Chen. (1996). Sousa R. "Planning. S and Murray. There are also considerable philosophical debates. D. Hoffer. Lecture notes on Data Warehouse and Data Mining.