2003 년 1 학기 Data Warehousing1 제 5 장 업무 요구사항 규정 DEFINING THE BUSINESS REQUIREMENTS

2003년 1학기 Data Warehousing 1

제 5 장

업무 요구사항 규정DEFINING THE BUSINESS

REQUIREMENTS


장의 목표

• Defining requirements is different for a data warehouse

• 업무 차원의 역할 이해• Information packages 와 그 용도• 요구 사항 수집 방버• Formal requirements definition document


DW system and OLTP system

• DW system– 정보 전달 시스템– 의사결정 지원 시스템– 요구사항들을 수집할

때 정보가 무엇인지에 집중

• OLTP system– 데이터 획득 시스템– 요구사항들 수집– 일일 업무 운용 시스템


5.1 차원 분석DIMENSIONAL ANALYSIS

• DW 구축 시 운용 시스템 구축과 다르다

• Usage of Information Unpredictable

• Dimensional Nature of Business Data

• Examples of Business Dimensions


Usage of Information Unpredictable

• Requirements for an operational system– Give precise details of required functions, information

content, and usage patterns

• Requirements for a data warehousing system– Generally unable to define their requirements clearly– Cannot define precisely what information from DW– Nor can express how they would like to use the

information or process it


업무 데이터의 차원 성질

• Users can provide very important insights into how they think about the business– What measurement units are important– How they measure success in the particular

department– How they combine the various pieces of

information for strategic decision making

• Figures 5-1 and 5-2




업무 차원의 예제

• Figure 5-3– Supermarket Chain

• Sales units

– Insurance Business• Claims

– Manufacturing Company• Shipments

– Airlines Company• Frequent flyer flights



5.2 정보 패키지INFORMATION PACKAGES

– A NEW CONCEPT

• A novel idea for determining and recording information requirements for a data warehouse

• Requirements Not Fully Determinate

• Business Dimensions

• Dimension Hierarchies/Categories

• Key Business Metrics or Facts


요구사항은 충분히 결정적이지 않다

• When requirements cannot be fully determined, we need a new and innovative concept to gather and record the requirements

• The new methodology is based on business dimensions– The basic measurements and the business

dimensions– Information package for the specific subject– Figure 5-4



정보 패키지는 당신에게 다음을 가능하게 할 수 있다 :

• Define the common subject areas• Design key business metrics• Decide how data must be presented• Determine how users will aggregate or roll up• Decide the data quantity for user analysis or query• Decide how data will be accessed• Establish data granularity• Estimate data warehouse size• Determine the frequency for data refreshing• Ascertain how information must be packaged


업무 차원Business Dimensions

• Data must be stored to provide for the business dimensions

• To identify business dimensions and their hierarchical levels

• Business dimensions for the subject of sales for an automaker– Product, dealer, customer demographic, method of

payment, and time

• Hotel occupancy information package– Hotel, room type, and time


차원 계층 / 범주Dimension Hierarchies/Categories

• Hierarchy of the time dimension– Levels of year, quarter and month– Dimension hierarchies are the paths for drilling down

or rolling up in our analysis

• Categories of data elements– Holiday flag in the time dimension– Package type in the product dimension

• Hierarchies and categories are included in the information packages for each dimension


주요 업무 측정 규준 또는 사실

• Using these business dimensions, what exactly are the users analyzing?– Numbers– Measurements or metrics– Facts

• Figures 5-5 and 5-6




5.3 요구사항을 수집하는 방법

• Who are the users that can make use of

the information in the data warehouse?

• Where do you go for getting the

requirements?


데이터 웨어하우스의 사용자

• Senior executives (including the sponsors)

• Key departmental managers

• Business analysts

• Operational system DBAs

• Others nominated by the above


어떤 요구사항을 수집해야 되는가 ?

• Data elements: fact classes, dimensions

• Recording of data in terms of time

• Data extracts from sources systems

• Business rules: attributes, ranges, domains, operational records


Meeting with groups of people

• Two basic techniques– Interviews– Joint application development(JAD) sessions


A Few Thoughts about Interviews

• Two or three persons at a time• Easy to schedule• Good approach when details are intricate• Some users are comfortable only with one-on-o

ne interviews• Need good preparation to be effective• Always conduct preinterview research• Also encourage users to prepare for the intervie


A Few Thoughts about Group Sessions

• Groups of twenty or less persons at a time

• Use only after getting a baseline understanding of the requirements

• Not good for initial data gathering

• Useful for confirming requirements

• Need to be very well organized


Interview Techniques

• A list of major tasks on page 100

• Figure 5-7

• A list of some key research topics on pages 100 and 101



Some Tips on the Types of Questions to be Asked

• Current Information Sources

• Subject Areas

• Key Performance Metrics

• Information Frequency


Interview Write-ups

1. User profile

2. Background and objectives

3. Information requirements

4. Analytical requirements

5. Current tools used

6. Success criteria

7. Useful business metrics

8. Relevant business dimensions


Adapting the JAD Methodology

• Joint process

• Methodology for developing computer applications jointly by the users and the IT professionals

• Discussion workshop lasting a certain number of days


Five-Phased Approach of JAD

1) Project Definition

2) Research

3) Preparation

4) JAD Session

5) Final Document


Review of Existing Documentation

• Be able to gather useful information from the review of existing documentation

• Documentation from User Departments– Everything about the functions of the business units– Documentation on the processes and procedures in t

hose units

• Documentation from IT– Data for the metrics and business dimensions– Operational system DBAs and application experts fro

m IT


5.4 요구사항 정의 : 범위와 내용

• Formal documentation– Detailed documentation of the requirements

definition– Basis for the next phases– 팀원이 떠나면 , 뒤의 사람이 어려움이 없다– Also validate your findings when reviewed

with the users


공식적인 요구사항 정의문서를 위한 정보의 유형

• Data Sources

• Data Transformation

• Data Storage

• Information Delivery

• Information Package Diagram


데이터 소스 Data Sources

• All the details you have gathered about the source systems– Available data sources– Data structures within the data sources– Location of the data sources– Operating systems, networks, protocols, and client

architectures– Data extraction procedures– Availability of historical data


데이터 변환 Data Transformation

• Involve mapping of source data to the data in the data warehouse

• Indicate where the data about your metrics and business dimensions will come from

• Describe the merging, conversion, and splitting


데이터 저장장치 Data Storage

• Sufficient details about storage requirements– Preliminary estimates on the amount of

storage needed for detailed and summary data

– Estimate the size of historical and archived data


정보 전달 Information Delivery

• Drill-down analysis

• Roll-up analysis

• Drill-through analysis

• Slicing and dicing analysis

• Ad hoc reports


정보 패키지 다이어그램

• Major and significant difference between operational systems and DW systems

• The best approach for determining requirements for a DW

• Crystallize the information requirements

• The accuracy and adequacy of the information package diagrams


요구사항 정의 문서 개요Requirements Definition Document

Outline1. Introduction

2. General requirements descriptions

3. Specific requirements

4. Information packages

5. Other requirements

6. User expectations

7. User participation and sign-off

8. General implementation plan

Documents

2003 년 1 학기 Data Warehousing1 제 5 장 업무 요구사항 규정 DEFINING THE BUSINESS REQUIREMENTS