Mastering Data Warehouse DesignRelational and Dimensional Techniques phần 3 ppsx

Three major ben-efits were cited in Chapter 2: ■■ The subject area model guides the business data model development.. The sidebar shows how the subject area model can be used toassist in

Introductions. The participants introduce themselves, and the sessionobjectives are reviewed.

Education. Education is provided on the relevant concepts, on the process,and on the starter model

Review and refinement of subject areas. The subject areas in the startermodel are reviewed, and a set of subject areas is derived Definitions forthose subject areas are then reviewed and refined

Refinement. The list of potential subject areas is reviewed and refined toarrive at the set of subject areas

A critical part of the agenda for the first session is education During the cational portion of the meeting, the facilitator explains what a subject area is,how it should be identified and defined, and why the resultant model is bene-ficial The processes (for example, brainstorming) to be employed are alsodescribed along with the rules for the facilitated session

edu-TIP

If some members of the group understand the concepts and others don’t, consider having an educational session before the actual facilitated session This provides the attendees with a choice and does not force people who know the topic to attend redundant education.

The remainder of this section presumes that the group is not beginning with astarter model

Following the educational session, the group engages in a brainstorming sion to identify potential subject areas In a brainstorming session, all contri-butions are recorded, without any discussion It is, therefore, not uncommonfor people to identify reports, processes, functions, entities, attributes, organi-zations, and so on, in addition to real subject areas Figure 3.1 shows the poten-tial result of such a brainstorming session for an automobile manufacturersuch as the Zenith Automobile Company If you look closely at the flip charts,you’ll see that most of the second sheet and part of the third sheet deviatedinto too great a level of detail When this happens, the facilitator shouldremind the group of the definition of a subject area

ses-Figure 3.1 Result of brainstorming session.

The next step in the process is to examine the contributed items and excludeitems that are not potential subject areas Each item is discussed and, if it doesnot conform to the definition of a potential subject area, it is removed and pos-sibly replaced by something that conveys the concept and could conform tothe definition of a subject area When this process is over, there will be fewersubject areas on the list, as shown in Figure 3.2 Some of the transformationactions that took place follow:

■■ ITEMS and PRODUCTS were determined to be the same thing and

AUTOMOBILES was selected as the term to be used since all the productsand items were driven by the automobiles Further, these were found toencompass CARS, PAINT, LUXURY CAR, PARTS, PACKAGES, MOTORS,USED CARS

■■ CUSTOMER and CONSUMER were determined to be the same thing andCUSTOMERS was selected as the term to be used PROSPECTS wasabsorbed into this area

■■ VARIANCE REPORT and SALES ANALYSIS REPORT were determined

to be reports and eliminated

■■ MARKETING was determined to be a function and was eliminated During the discussion, ADVERTISEMENTS and PROMOTIONS wereadded.

■■ CREDIT CARD and LOAN were grouped into PAYMENT METHODS

■■ EMPLOYEES and CONTRACTOR were combined into HUMAN

RESOURCES

■■ DEALERSHIPS and DEALERS were deemed to be the same, and

DEALERS was chosen as the subject area

The resultant list should consist solely of data groupings, but some may bemore significant than others Next, the group is asked to look at the list and try

to group items together For example, WAREHOUSES, DISTRIBUTION TERS, and FACTORIES are shown in Figure 3.2 WAREHOUSES and DISTRI-BUTION CENTERS could be grouped into a potential subject area ofFACILITIES, with FACTORIES also established as a subject area When thisprocess is over, the most likely candidates for the subject areas will have beenidentified, as shown in Figure 3.3

CEN-Figure 3.2 Result of refinement process.

Figure 3.3 Result of reduction process.

This virtually completes the first facilitated session In preparation for the nextsession, each subject area should be assigned to two people Each of these peo-ple should draft a definition for the subject area and should identify at least threeentities that would be included within it (Some people may be responsible formore than one subject area.) The work should be completed shortly followingthe meeting and submitted to the facilitator The group should be advised that

on the intervening day, the facilitator uses this information and informationfrom subject area model templates (if available) to provide a starting point forthe second session

Consolidation and Preparation for Second Facilitated Session

During the period (potentially as little as one day) between the two facilitatedsessions, the facilitator reviews the definitions and sample entities and usesthese to create the defined list of subject areas that will be used in the secondfacilitated session The facilitator should create a document that shows thecontributions provided, along with a recommendation For example, for thesubject area of Customers, the following contributions could have been made:

Contribution 1. “Customers are people who buy or are considering buyingour items.” Sample entities are Customer, Wholesaler, and Prospect

Contribution 2. “Customers are organizations that acquire our items fortheir internal consumption.” Sample entities are Customer, Customer Sub-sidiary, and Purchasing Agent

POTENTIAL SUBJECT AREAS - PAGE 4

The subject area template information (previously shown in Table 3.3) vides a definition of Customers as “People and organizations who acquireand/or use the company’s products,” and provides Customer, Prospect, andConsumer as sample entities Using this information, the facilitator couldinclude the information for CUSTOMERS shown in Table 3.5 Similar informa-tion would be provided for each of the subject areas.

pro-Second Facilitated Session

The agenda for the second session should include the following items:

Review. The results of the first session and the work performed since thenare reviewed

Refinement. The subject areas and their definitions are reviewed andrefined

Relationships. Major relationships between pairs of subject areas are created

Conclusion. The model is reviewed, unresolved issues are discussed, andfollow-up actions are defined

Table 3.5 Potential Subject Area: CUSTOMER

The success of the second session is highly dependent on each of the pants completing his or her assignment on time and on the facilitator compiling

partici-a document thpartici-at reflects the input received partici-and best prpartici-actices A limit should beplaced on the discussion time for each subject area If the subject area is notresolved by the end of the allotted time, the responsibility to complete theremaining work should be assigned to a member of the team Often, theremaining work will consist of refining the wording (but not the meaning) ofthe definition

After all of the subject areas have been discussed, the major relationshipsamong the subject areas are identified and the resultant subject area diagram

is drawn This step is the least critical one in the process because the subjectarea relationships can be derived naturally from the business data model as it

is developed A critical final step of the second facilitated session is the opment of the issues list and action plan

devel-Follow-on Work

The issues list and action plan are important products of the second facilitatedsession, since they provide a means of ensuring that the follow-on work iscompleted The issues list contains questions that were raised during the ses-sion that need to be resolved Each item should include the name of the personresponsible and the due date The action plan summarizes the remaining stepsfor the subject area model Often, the product of the session can be appliedimmediately to support development of the business data model, with refine-ments being completed over time based on their priority

Subject Area Model Benefits

Regardless of how quickly the subject area model can be developed, the effortshould be undertaken only if there are benefits to be gained Three major ben-efits were cited in Chapter 2:

■■ The subject area model guides the business data model development

■■ It influences data warehouse project selection

■■ It guides data warehouse development projects

The subject area model is a tool that helps the modeler organize his or herwork and helps multiple teams working on data warehouse projects recognizeareas of overlap The sidebar shows how the subject area model can be used toassist in data warehouse project definition and selection

Subject Area Model for Zenith Automobile Company

A potential subject area model for the Zenith Automobile Company is vided in Figure 3.5 Only the subject areas needed to answer the business ques-tions and Customers are shown

pro-Data Warehouse Project Definition and Selection

Figure 3.4 shows the primary subject areas that are needed to answer the ness questions for the Zenith Automobile Company.

busi-Figure 3.4 Mapping requirements to subject areas.

Using the information in Figure 3.4, a logical implementation sequence would

be to develop the Automobiles, Dealers, and Sales Organizations subject areas first since virtually all the questions are dependent on them Factories or Incen- tive Programs could be developed next, followed by the remaining one of those two For the business questions posed, no information about Customers and Sup- pliers is needed

Even if the business considered question 3 or 7 to be the most significant, they should not be addressed first The reason for this conclusion is that in order to answer those questions, you still need information for the other three subject areas

This is an example of the iterative development approach whereby the data warehouse is built in increments, with an eye toward the final deliverable.

QUESTION

1

MOBILES

AUTO-CUSTOMERS DEALERS

SUBJECT AREA FACTORIES INCENTIVE

Figure 3.5 Zenith Automobile Company partial subject area.

Definitions for each subject area follow:

■■ Automobiles are the vehicles and associated parts manufactured by Zenith

Automobile Company and sold through its dealers

■■ Customers are the parties that acquire automobiles and associated parts

from Dealers

■■ Dealers are agencies authorized to sell Zenith Automobile Company

automobiles and associated parts

■■ Factories are the facilities in which Zenith Automobile Company

manufac-tures its automobiles and parts

■■ Incentive Programs are financial considerations designed to foster the sale

DEALERS AUTOMOBILES

INCENTIVE

PROGRAMS

SALES ORGANIZATIONS

Figure 3.6 Retail subject area model starter.

Sample definitions for each of the subject areas follow

■■ Communications are messages and the media used to transmit the

■■ Human Resources are individuals who perform work for the company.

■■ Financials is information about money that is received, retained,

expended, or tracked by the company

■■ Internal Organizations are formal and informal groups to which Human

Resources belong

■■ Items are goods and services that the company or its competitors provide

or make available to Customers

LOCATIONS

EQUIPMENT INTERNAL ORGANIZATIONS

HUMAN RESOURCES COMMUNICATIONS

■■ Locations are geographic points and areas.

■■ Other Facilities are real estate and other structures and their integrated

components, except stores

■■ Sales are transactions that shift the ownership or control of an item from

the Company to a Customer

■■ Stores are places, including kiosks, at which Sales take place.

■■ Vendors are legal entities that manufacture or provide the company with

items

Business Data Model

As we explained in Chapter 2, a model is an abstraction or representation of asubject that looks or behaves like all or part of the original The business datamodel is one type of model, and it is an abstraction or representation of thedata in a given business environment It helps people envision how the infor-mation in the business relates to other information in the business (“how theparts fit together”) Products that apply the business data model include appli-cation systems, the data warehouse, and data mart databases In addition, themodel provides the meta data (or information about the data) for these data-bases to help people understand how to use or apply the final product Thesubject area model provides the foundation for the business data model, andthat model reduces the development risk by ensuring that the application sys-tem correctly reflects the business environment

Business Data Development Process

If a business data model does not exist, as is assumed in this section, then aportion of it should be developed prior to embarking on the data warehousedata model development The process for developing the business data modelcannot be described without first defining the participants In the ideal world,the data stewards and the data modelers develop the business data modeljointly

Most companies do not have formal data stewardship programs, and the ness community (and sometimes the information technology community)may not see any value in developing the business data model After all, itdelays producing the code! The benefits of the business data model were pre-sented in Chapter 2, but in the absence of formal data stewards, the data mod-eler needs to identify the key business representatives with the necessaryknowledge and the authority to make decisions concerning the data defini-tions and relationships These are often called “subject matter experts” or

busi-SMEs (pronounced “smeeze”) Once these people are identified, the modelerneeds to obtain their commitment to participate in the modeling activities.This is no small chore, and often compromises need to be made For example,the SMEs may be willing to answer questions and review progress, but maynot be willing to participate in the modeling sessions After the modelerunderstands the level of participation, he or she should evaluate the risk of thereduced SME involvement to the accuracy and completeness of the model.Then, the modeler should adjust his or her effort estimate and schedule if there

is a significant difference between the SMEs’ committed level of involvementand the level that was assumed when the plan was created

Development of a complete business data model can take 6 to 12 months, with

no tangible business deliverable being provided during that timeframe Whilethis may be the theoretically correct approach, it is rarely a practical one Werecommend using the following approach:

1 Identify the subject area(s) from which data is needed for the project iteration

2 Identify the entities of interest within the affected subject area(s) andestablish the identifiers

3 Determine the relationships between pairs of entities

4 Add attributes

5 Confirm the model’s structure

6 Confirm the model’s content

The remainder of this section describes these six activities

Identify Relevant Subject Areas

The subject areas with information needed to answer the questions posed inthe scenario described for are shown in Figure 3.5 These are: Automobiles,Dealers, Factories, Incentive Programs, and Sales Organizations

There are other subject areas in the subject area model, but these do not appear

to be needed for the first few iterations of the data warehouse This first cation of the subject area model provides us with a quick way of limiting thescope of our work We could further reduce our scope if we want to addressonly a few of the questions For example, let’s assume that the first iterationdoesn’t answer questions 3 and 7

appli-To answer these questions, we don’t need any information from Factories andIncentive Programs, nor do we need information about Customers for any ofthe questions Being able to exclude these subject areas is extremely important

Customer data, for example, is one of the most difficult to obtain accurately Ifthe business is initially interested in sales statistics, then information about thespecific customers can be excluded from the scope of the first iteration of themodel This avoids the need to gain a common definition of “customer” and tosolve the integration issues that often exist with multiple customer files (In theautomotive industry, information about Customers requires cooperation fromthe Dealers.) It is important to remember that excluding a subject area has nobearing on its importance—it only has a bearing on the urgency of defining thebusiness rules governing that area and hence the speed with which the nextbusiness deliverable of the data warehouse can be created, as shown in Figure3.7 Similarly, in developing the details for the other subject areas, the focusshould remain on the entities needed for the iteration being developed Figure 3.7 points out several benefits of using the subject areas to limit scope.First, the project can be subdivided into independent iterations, each of which

is shorter than the full project Second, the iterations can often overlap (ifresources are available) to further shorten the elapsed time for completing theentire effort For example, once the analysis and modeling are completed forthe first iteration, these steps can begin for the second iteration, while thedevelopment for the first iteration proceeds Some rework may be needed asadditional iterations are pursued, but this can often be avoided through rea-sonable planning The value of providing the business deliverables quicker isusually worth the risk

Figure 3.7 Schedule impact of subject area exclusion.

DATA WAREHOUSE PROJECT SCHEDULE-THREE ITERATIONS

Identify Major Entities and Establish Identifiers

An entity is a person, place, thing, event, or concept of interest to a companyand for which the company has the capability and willingness to capture infor-mation Entities can often be uncovered by listening to a user describe the busi-ness, by reviewing descriptive documents for an area, and by interviewingsubject matter experts We concluded that information from three subjectareas—Automobiles, Dealers, and Sales Organizations—is needed to addressthe first three questions Let’s examine Sales

Potential entities should be developed through a brainstorming session, views, or analysis The initial list should not be expected to be complete As themodel is developed, entities will be added to the list and some items initiallyinserted in the list may be eliminated, particularly for the first iteration of thedata warehouse Each of the entities needs to be defined, but before spendingtoo much time on an entity, the modeler should quickly determine whether ornot the entity is within the scope of the data warehouse iteration being pur-sued The reason for this screening is obvious—defining an entity takes timeand may involve a significant amount of discussion if there is any controversy

inter-By waiting until an entity is needed, not only is time better spent, but the SMEsare also more inclined to work on the definition since they understand theimportance of doing so

Eventually, the model will be transformed into a physical database with eachtable in that database requiring a key to uniquely identify each instance Wetherefore should designate an identifier for each entity that we will be model-ing Since this is a business model, we need not be concerned with the physi-cal characteristics of the identifier; therefore, we can simply create a primarykey attribute of “[Entity Name] Identifier” or “[Entity Name] Code” foreach entity The difference between Identifier and Code is described in the

“Entity- and Attribute-Modeling Conventions” sidebar, which shows theentity-modeling conventions we’ve adopted Most modeling tools generateforeign keys when the relationships dictate the need and, by including theidentifier, our model will include the cascaded foreign keys The “Entity- andAttribute-Modeling Conventions” sidebar summarizes the conventions weused to name and define entities and attributes Table 3.6 presents the results

of this activity for the entities of interest for the business questions that need to

be answered

Entity- and Attribute-Modeling Conventions

The rules for naming and defining entities and attributes should be established within each enterprise Entities and attributes represent business-oriented views, and the naming conventions are not limited by physical constraints Some of the conventions to consider are as follows.

Entity naming conventions include:

◆ Each entity should have a unique name.

◆ The entity name should be in title case (that is, all words except for

prepositions and conjunctions are capitalized).

◆ Entity names should be composed of business-oriented terms:

■ Use full, unabbreviated words.

■ Use spaces between words.

■ Use singular nouns.

■ Avoid articles, prepositions, and conjunctions.

◆ The length of the name is not limited (A good entity name would be Bill to Customer; a poor one would be BTC or Bill-to-Cust.)

Attribute naming conventions include:

◆ Attribute names should contain one or more prime words, zero or more modifiers, and one class word.

■ The prime word describes the item It is often the same as the name of the entity within which the attribute belongs.

■ The qualifier is a further description of the item

■ The class word (for example, amount, name) is a description of the type

of item.

◆ Each attribute should have a unique name within an entity If the same attribute, except for the prime word (for example, expiration date, status)

is used in several entities, it should always have the same definition.

◆ The attribute name should be in title case.

◆ Each attribute name should be composed of business-oriented terms:

■ Use full, unabbreviated words The length of the name is not limited.

■ Use spaces between words.

■ Use singular nouns.

■ Avoid articles, prepositions, and conjunctions such as “the” and “and.”

Table 3.6 Entity Definitions.

Dealer It now becomes part of the Dealer’s inventory and the Dealer assumes

responsibility for the car and its ultimate sale to a Customer.

produced by ZAC There are two lines of automobiles: Zeniths and Tuxedos Each line has several models to choose from, and each model has three series containing different features.

are manufactured, in inventory, at the Dealer, sold to a Customer.

the exterior of an Automobile.

that acquires an Automobile.

chooses to sell ZAC cars The Dealer must purchase the cars and then sell them to its customers ZAC supports the dealers by running national ads, supplying sales brochures, providing sales incentive programs, and so on

The Dealer must, in turn, supply ZAC with its financial statements and agree to abide by ZAC’s quality guidelines and service standards.

(continued)

Entity and attribute definition conventions include:

◆ Definitions should use consistent formats.

◆ Definitions should be self-sufficient.

◆ Definitions should be clear and concise.

◆ Definitions should not be recursive A word should not be used to define itself.

◆ Definitions should be business-oriented.

◆ Definitions should be mutually exclusive.

◆ Definitions should be independent of physical system constraints.

Table 3.6 (continued)

method of verifying the sales that the Dealer claims to have made This is especially important for Incentive Program Sales where the Dealer receives an incentive for each sale.

sell during the month These figures are used to calculate the allocations of cars to Dealers by ZAC.

payment is received While on Credit Hold, the Dealer cannot receive any more of its allocated cars.

require different emissions equipment installed

in the automobiles sold in their area—some are more stringent than others The cost of the Automobile varies according to the complexity

of the emissions equipment.

Automobile This is sometimes referred to as the Source Zenith automobiles are built in Asheville, NC; Cortez, CO; and Southington, CT

Tuxedo automobiles are made in Greenville, SC;

Newark, OH; and Bremen, IN.

rebate or reduction in an automobile’s price so that the Dealer may offer this reduced price to the Customer, thus enhancing the Customer’s purchase desire.

their purchasing desire.

Automobile, for example, Zenith or Tuxedo.

Table 3.6 (continued)

and sold Examples are the Zenith Zipster, Zenith Zoo, Tuxedo Tiara, and Tuxedo Thunderbolt.

Automobile to enhance the car.

is a convenient way of identifying a standard grouping of options.

a group of smaller cities, or a geographic area.

of Employee.)

Organization.

with the Make and Model For example, the Zenith Models come in the following series: NF (no frills),

SF (some frills), MF (max frills) The Tuxedo Models come with these series: CF (costly frills), PF (pricey frills), DF (decadent frills), and TDF (truly decadent frills).

to the Customer or to the Customer’s loaning institution.

when it is allocated.

which manufactured automobiles are stored prior

to allocation and shipment to dealers.

In the business model, we can provide an attribute for the description (andavoid having a reference entity for translating the code into the description).The code is needed only when we migrate to the data warehouse, where it isused either to ensure that only valid codes are used (domain constraints canalso accomplish this) or to reduce the storage requirements We create code—description entities—when we build the data warehouse model.

Define Relationships

A modeling tool is essential for developing and maintaining all data models.Some of the common tools on the market follow There are advantages and dis-advantages to each of the tools, but every one of them performs at least thebasic modeling functions The differences among the tools change with eachrelease and hence are not described in this book

Common data modeling tools include

■■ ERwin by Computer Associates

■■ ER Studio by Embarcadero

■■ Oracle Designer by Oracle

■■ Silverrun by Magna Solutions

■■ System Architect by Popkin

■■ Visio by Microsoft

■■ Warehouse Designer by Sybase

The relationships diagrammatically portray the business rules Following is apartial set of business rules that need to be reflected in the business data model

■■ An automobile is classified by make, model, series, and color

■■ An automobile is manufactured in a factory

■■ An option package contains one or more options, each of which may beincluded in several option packages

■■ An automobile contains zero, one, or more option packages

■■ An automobile is allocated to a dealer

■■ An automobile is sold by a dealer

These rules would be uncovered through discussions with appropriate subjectmatter experts The next step in the process is to define the relationshipsbetween pairs of entities Figure 3.8 shows the entities needed in the model tosupport these questions

Figure 3.8 Entity-relationship diagram—entities.

An examination of the business data model reveals that the entities aregrouped by subject area This organization of the business data model is veryhelpful as more and more entities are added to the model

Another source of information for the business data model is the database of an ing system While this is a source, the modeler needs to recognize that the physical database used by a system reflects technical constraints and other (frequently undocu- mented) assumptions made by the person who designed it as well as erroneous or

exist-outdated business rules It should, therefore, not be considered to be the business

model, but it certainly can be used as input to the model Any differences discovered

in using a database from an existing system should be documented These will be used when the transformation rules are developed.

TIP

In the business model, information that changes with time should be tied to calendar dates whenever possible For example, instead of store age, the date the store was opened or last renovated should be shown In the data warehouse model, we have options on whether to store just the date of birth or both the date of birth and the age If we’re doing analysis based on a range of ages, we may choose to store the age range in the mart (If we choose this option, we will need to include logic for updating the age range unless the mart is rebuilt with each load cycle.)

The difficulty with a data warehouse data model is anticipating the attributesthat business users will eventually want Since the business data model is beingbuilt primarily to support the warehouse, that problem manifests itself at thispoint Part of the reason for the difficulty is that the business users truly do notknow everything they need They will discover some of their needs as they usethe environment Some sources to consider in identifying the potential elementsare existing reports, queries, and source system databases This area is discussedmore thoroughly in Chapter 4 as part of the first step of creating the data ware-house data model

The “Entity- and Attribute-Modeling Conventions” sidebar summarizes the ventions we used to name and define attributes Figure 3.9 shows the expandedmodel, with the attributes included As was the case with the entities, we shouldexpect additions, deletions, and changes as the model continues to evolve

con-Figure 3.9 Entity-relationship diagram—entities and attributes.

The model in Figure 3.9 reflects attributes that, from a business perspective,appear to fit within the designated entities for the Automobiles Subject Area.(Some entities from other subject areas are included in the diagram to provide

a more complete picture.)

Confirm Model Structure

The business data model should be presented in what is known as “third normalform.” The third normal form was described in Chapter 2 By way of summary,

in the third normal form, each attribute is dependent on the key of the entity inwhich it appears, on the whole key, and on nothing but the key

Model Series Color

Suggested Retail Price Amount Option Package ID (Fx)

VIN (Fx) Customer ID (Fx) Incentive Program ID (Fx) Actual Selling Price Amount

VIN (Fx) Automobile Status Code

USA ID (Fx) Dealer Name Dealer City Dealer Zip Code Dealer Ser

Establishment Date Credit Hold Indicator

Allocation Date Dealer ID (Fx)

Remember that the business model does not need to provide good mance It is never implemented It is the basis of subsequent models that may

perfor-be used for a data warehouse, an operational system, or data marts For thatusage, the third normal form provides the greatest degree of flexibility and sta-bility and ensures the greatest degree of consistency

TIP

A purist view of the business data model is that it is a third normal form model that is concerned only with the logical (and not physical) view Several of the data- modeling tools store information about the physical characteristics of the table for each entity and about the physical characteristics of the column for each attribute The theoretician would address these only when the model is applied for an applica- tion such as the data warehouse

A more practical approach is to include some information pertaining to the physical model in the business model The reason for this is that several applications will use the business model, and they start by copying the relevant section of the model If more than one application needs the same entity, then each is forced to establish the physical characteristics such as datatype for the resultant table and its columns This creates duplicate effort and introduces a potential for inconsistency A better approach

is to create some of this information within the business model in the modeling tool The use of domain definitions is another technique that experienced modelers use

to minimize work and provide flexibility The domain feature of the modeling tool can be used to define valid values, data types, nullability, and so on One application

of domains is to establish one for each unique combination of these, then instead of defining each of the physical characteristics of a column, it is merely assigned to a domain In addition to reducing the workload, this provides the flexibility to accomo- date future changes.

Confirm Model Content

The last, and possibly most important, step in developing the business datamodel is to verify its content This is accomplished through a discussion withbusiness representatives The techniques used vary In meeting with the busi-ness users, the modeler must remember that the model is a means to an end It

is a technique for describing the business in a way that facilitates the ment of systems and data warehouses Some business representatives may beboth willing and able to review the actual model With others, the modelermay need to ask questions in plain English that verify the business rules anddefinitions For example, the modeler may need to conduct an interview inwhich he or she confirms the relationships by asking the business representa-tive if each of the business rules that the relationships represents is valid

The subject area model is inherent in the foundation of the data warehouse,since the warehouse itself is “subject oriented.” The subject area model pro-vides a good way of organizing the business data model The subject areamodel identifies the 15–25 major groupings of significance to the company,with each one mutually exclusive of the others The subject area model can becreated in a few days, using facilitated sessions The first of two facilitated ses-sions includes education on the relevant concepts, brainstorming a list ofpotential subject areas, and refinement of the list Preliminary definitions aredeveloped prior to the second meeting, at which the results of the first sessionand the work performed since then are reviewed, the subject areas and theirdefinitions are reviewed and refined, major relationships are added to themodel, and the model is reviewed Unresolved issues and follow-up actionsmay also be identified

This business data model is the foundation of everything that follows cant errors can have a cascading effect, so it is very important to verify both thestructure and the content of the model The business data model describes theinformation of importance to an enterprise and how pieces of information arerelated to each other It is completely independent of any organizational, func-tional, or technological considerations It therefore provides a solid foundationfor designing the database for any application system, including a data ware-house A complete business data model is complex and can easily require ayear to complete Instead of developing a complete business data model, thedata warehouse modeler should create only those portions of the model thatare needed to support the business questions being asked

Signifi-Within the scope of the business questions being asked, the business datamodel is developed by identifying the subject areas from which data isneeded, identifying and defining the major entities, establishing the relation-ships between pairs of entities, adding attributes, conforming to the third nor-mal form, and confirming the content of the model