데이터 웨어하우징

이춘열 , 이종옥 -2000.1 괸계형데이타베이스관리론 제 17 장 데이타웨어하우징 -1

데이터 웨어하우징데이터 웨어하우징

• 데이타베이스와 데이타웨어하우스

• 데이타웨어하우스 개발 프로젝트

• 기술적 특성


데이타베이스와 데이타웨어하우스데이타베이스와 데이타웨어하우스

• 데이타베이스의 일차적인 목표 일상적인 업무 처리를 지원하는 것 .

정보 분석을 위해서는 필요한 데이터들을 개별적으로 추출하여 사용하여야 하는 경우가 대부분 .

- 데이터웨어 하우스는 정보 분석을 위하여 개별적인 소규모 데이터 베이스들을 구축하는 대신에 여러 분석 업무에 공통적으로 사용될 수 있도록 한 총괄 데이터베이스 .

- 이러한 데이터웨어 하우스와 대비하여 업무 처리를 위한 데이터베이스 들을 운영 데이터베이스 (operational database) 라고 함 .



• 데이타베이스다수 사용자를 위하여 ( 데이타 공유를 목적으로 ) 자료들을 구조화하여 모아 놓은 것 .

(A shared collection of logically related data, designed to meet the information needs of multiple users)

• 데이타웨어하우스경영의사결정을 위하여 필요한 데이타들을 여러 운영 데이타베이스들로부터 추출 , 정제 , 요약하여 축적한 데이터베이스

(A DWs are built in the business decision support and contain historical data summarized and consolidated from detail individual records from a number of operational databases)



• 운영 데이터와 분석정보 데이터베이스의 활용 용도는 크게 2 가지로 나누어짐 .

1) 업무 처리를 위하여 단편적인 데이터들을 제공하는 것 ,

--> 운영 데이터

2) 의사결정을 위한 일련의 자료들과 , 이로부터 추출될 수 있는 정보들을 제공하는 것 .

--> 분석정보

- 상품 대금 지불을 승인하기 위해서는 해당 카드의 신용 한도를 확인하여야 함 .

신용한도는 데이터베이스에 입력하여 저장하는 단편적인 데이터 .

품목 종류별 연간 구매액은 데이터베이스에 저장되어 있는 판매 거래 자료로부터 추출 되는 자료 .


데이타웨어하우스의 활용 예제데이타웨어하우스의 활용 예제

1. 카드번호 3672-XYZ-0001 고객의 신용한도

2. 제품 X 의 현 재고량

3. 제품 X 의 월 매출량

4. 할인 판매 품목의 매출량 변동

5. 02-910-4565 의 금월 통화 내역

6. 02-910-4565 의 시간대별 통화 내역

DB DW



• 분석 정보의 특성 - 분석 정보는 운영 데이터와 다른 여러 가지 특성을 가짐 . 1) 형태 운영 데이터는 특정 카드의 거래 한도와 같은 단일 사실을 나타냄 . 이들 데이터들은 대부분 기초 자료 (basic facts) 들임 . 이에 반해 분석 정보들은 일련의 유추 데이터 (derived data) 들임 .

2) 시간성 분석 정보의 가장 큰 특징은 시간차원에 따라 여러 자료들을 비교 , 이용함 . 운영 데이터는 주어진 시점의 단일 사실에 관한 자료 . ‘ 재고량’과 같이 현재 값을 나타내는 경우가 대부분 .

월별 재고량의 변동률과 같은 분석 정보를 추출하기 위해서는 월별 재고량을 월별로 기록하여 관리하여야 함 .



3) 관리의 단위 운영 데이터는 트랜잭션의 효율적 처리를 목적으로 함 .

따라서 , 이의 관리 단위는 최소한의 독립적인 단위들임 .

( 즉 , 관계형 데이터베이스에서 말하는 정규화된 테이블 단위임 .)

분석 정보는 경영 관리나 의사결정을 위한 단위 .

분석 주제별로 관리되며 , 요약 또는 처리된 단위로 저장됨 .

4) 데이터의 수명 주기 운영 데이터는 갱신을 수반함 . 즉 , 제품의 재고량이나 , 고객의 주소

등은 모두 바뀔 수 있음을 가정하여야 함 .

분석정보는 기록된 사실들로부터 도출된 것으로서 갱신될 필요 없음 .



5) 주요 관리 기능 운영 데이터는 갱신을 수반함 .

운영 데이터관리의 주요 현안은 효율적인 갱신 .

관계형 데이터베이스에서 테이블들을 정규화 하는 것은 모두 데이터의 갱신을 위함 .

6) 적시성 운영 데이터는 실시간 정보를 제공할 수 있어야 함 .

만약 특정 고객의 신용 한도가 정지되었거나 상품의 재고량이 변동 되었 으면 , 즉시 데이터베이스에 기록되어 해당 구매 거래의 승인이나 처리에 적용되어야 함 .

분석 정보들은 반드시 실시간 갱신을 필요로 하지 않음 .



• 분석 정보의 관리 방안

- 분석 정보는 운영 데이터들로부터 도출된 자료들임 . 이들은 이론적으로 운영 데이터들로부터 유도될 수 있으며 , 별도로 기록하여 관리하지 않아도 됨 .

- 분석 정보들을 매번 필요할 때마다 운영 데이터들로부터 도출해 내는 것은 쉬운 일이 아님 .

- 거래 자료로부터 분석정보를 추출하기 위해서는 많은 시간과 노력이 소요됨 . 이 결과 적시적인 의사결정이 지연될 수 있음 .

- 분석 정보를 운영 데이터베이스로부터 추출할 경우 , 운영 데이터베이스에 과도한 부하를 부과할 수 있음 .



• 분석 정보의 관리 방안

- 앞의 이유때문에 운영 데이터는 분석정보와 분리하여 별도로 저장하여

관리하는 것이 필요함 .

- 거래 처리를 위한 운영 데이터베이스와 , 경영관리와 의사 결정을 위한

분석 정보 데이터베이스를 별도로 운영하는 것이 바람직함 .


정보처리 형태와 데이터베이스정보처리 형태와 데이터베이스

Transaction processing system

Strategic information system

Management information system

OLAP

OLTP

Historical Data (Data Warehouse)

Operation Data

왜 분리가 필요 ?


데이터 웨어하우스의 특성데이터 웨어하우스의 특성

기간업무 데이타베이스 데이타웨어하우스

용도 업무 처리 응용 프로그램 중심

분석 주제 중심

데이타

현재 데이타, 자료값 갱신 ( 변경), 구조는 불변 상세 자료 비 중복성

시점별 자료 변경되지 않음 데이타 구조 가변 요약/처리 자료 중복이 필연적임

사용자 실무자 관리자

업무 처리

반복 업무 요구 사항 사전 정의 시스템 개발 수명 주기(SDLC) 적용 가능 개별 데이타 처리 가용성 필요 성능이 주관심사

휴리스틱 유구 사항 사전 식별 불가능 시스템 개발 수명 주기(SDLC) 적용 불가능 여러 데이타 처리 가용성 성능이 주요 관심사 아님


데이터웨어 하우스의 출현 배경데이터웨어 하우스의 출현 배경- 데이터웨어 하우스의 출현은 분석정보에 대한 요구 증대와 이를 충족시킬 수 있는 컴퓨터 시스템의 성능 향상에 따른 당연한 결과 .

- 기존의 데이터베이스는 운영 데이터와 분석정보를 위하여 동시에 사용 되어 왔다 .

- 분석 정보를 관리하기 위한 방법은 스냅샷과 같은 기법을 이용하여 ,

운영 데이터베이스로부터 필요한 분석 정보들을 추출하여 사용 용도 또는 사용자별로 별도로 저장하는 방법 .

그러나 이 방법은 분석 정보 데이터베이스들이 용도별로 양산되는 결과를 초래하게 됨 .


데이터웨어 하우스의 출현 배경데이터웨어 하우스의 출현 배경- 방대한 양의 자료를 서로 비교하기 위해서는 , 기존의 관계형

데이터베이스 관리 시스템의 경우 , 많은 시간이 소요되게 되었음 .

- 전사적으로 분석 정보들을 한 개의 데이터베이스에 통합하여 저장 관리할 수 있는 컴퓨터 시스템을 구축하는 것은 상당히 어려움 .

• 컴퓨터의 성능 향상MPP (massively parallel processing) computers

• 데이타베이스 관리 시스템의 성능 향상RDBMS terabytes capacity

이전에도 유사 기능이 있었음 : ( 예 ) Snapshot


분석 정보의 전통적 추출 방법 분석 정보의 전통적 추출 방법 : : 스냅샷스냅샷

- 시점별 분석정보들을 도출하기 위한 방법으로서 일반적으로 많이 이용된 것이 운영 데이터베이스의 내용을 스냅샷으로 촬영하여 그 내용을 별도의 테이블에 저장하는 방법 .

- 스냅샷 (snapshot) 은 특정 시점별로 데이터베이스의 내용을 스냅샷 테이블에

기록하는 방법 . 스냅샷으로 운영 데이터베이스의 내용을 기록하기 위해서는 스냅샷 테이블의 이름과 저장공간 , 저장 방법들을 명시하고 , 스냅샷이 촬영되는 시점을 사건에 명시하여야 함 . - 스냅샷은 개별 사용자들이 해당 운영 데이터들로부터 의사결정 정보를 도출하기 위하여 많이 사용됨 .


SnapshotSnapshot 과 데이타웨어하우스과 데이타웨어하우스

- 분석 정보는 시점별 자료를 누적 저장함 .

- 분석 정보들은 운영 데이터로부터 도출 됨 . 즉 , 운영 데이터베이스에 저장되어

있는 현재 데이터 또는 거래 처리 트랜잭션들을 시점별로 파악하여 시간 차원에 따라 누적하여 저장한 것인 분석 정보들임 .

• Snapshot개인용 ( 단일 목적 ) 데이타웨어하우스

( 예 ) CREATE SNAPSHOT emp_sfPCTFREE 5 PCTUSED 60TABLESPACE usersSTORAGE INITIAL 50K NEXT 50K PCTINCREASE 50REFRESH FAST NEXT sysdate + 7AS SELECT * FROM emp@ny


분석 정보의 예제분석 정보의 예제

운영 데이터베이스

분석정보 데이터베이스 (기초)

홍길 동서울 성 북구 정 릉동 12신용 등급 - A신용 한도 500 만원

홍길 동서울 성 북구 정 릉동 12신용 등급 - A신용 한도 500 만원

홍길 동1997.1 - 1997. 12서울 종 로구신용 등급 - AA신용 한도 100 0만원

홍길 동1997.1 - 1997. 12서울 종 로구신용 등급 - AA신용 한도 100 0만원

홍길 동1998.1 - 1998.12서울 성 북구 정 릉동 12신용 등급 - C신용 한도 100 만원

홍길 동1998.1 - 1998.12서울 성 북구 정 릉동 12신용 등급 - C신용 한도 100 만원

홍길 동1999.1 - 현 재서울 성 북구 정 릉동 12신용 등급 - A신용 한도 500 만원

홍길 동1999.1 - 현 재서울 성 북구 정 릉동 12신용 등급 - A신용 한도 500 만원

분석정보 데이터베이스 (분석용)

성북 구 지역 고 객수199 7. 1 - 4201 199 7. 2 - 4310 199 7. 3 - 4210199 7. 4 - 4105199 7. 5 - 4030199 7. 6 - 4070199 7. 7 - 4010 199 7. 8 - 4110 199 7. 9 - 4045199 7. 10 - 39 12199 7. 11 - 38 15199 7. 12 - 37 16199 8. 1 - 3610 …… ……… ………… …. …… ….…… ….

성북 구 지역 고 객수199 7. 1 - 4201 199 7. 2 - 4310 199 7. 3 - 4210199 7. 4 - 4105199 7. 5 - 4030199 7. 6 - 4070199 7. 7 - 4010 199 7. 8 - 4110 199 7. 9 - 4045199 7. 10 - 39 12199 7. 11 - 38 15199 7. 12 - 37 16199 8. 1 - 3610 …… ……… ……

…… …. …… ….…… ….


분석 정보 데이터베이스의 양산분석 정보 데이터베이스의 양산

- 개별 사용자들이 각자의 의사 결정 정보를 도출하기 위하여 분석 정보를 도출할 경우 , 이들은 각자의 필요성에 따라 분석 정보 데이터베이스를 도출함 .

- 사용 용도별로 개별적인 분석 정보들을 도출하는 것은 다음의 문제를 야기함 .

1) 분석 정보의 도출을 위하여 많은 시간과 노력을 소비하게 됨 .

정보 분석가들은 운영 데이터베이스로부터 분석 정보를 직접 도출해야

함 .

2) 통일된 분석정보가 존재하지 않음으로써 의사 결정의 효과가 저하됨 .


분석 정보 데이터베이스의 양산분석 정보 데이터베이스의 양산

- 분석 정보들이 개별적으로 관리됨으로써 , 관리의 비효율성 , 부정확성 ,

비일치성 , 무결성의 저하 등의 여러 문제들을 초래하게 됨 .

- 다양한 분석 정보들이 존재하게 되는 것은 결국 , 통일된 정보가 존재하지

않음을 의미하게 됨 .

이러한 문제들의 발생으로 단일의 공통 데이터베이스가 필요하게 됨 .


데이터웨어 하우스의 모형데이터웨어 하우스의 모형

- 데이터웨어 하우스는 전사적인 수준에서 분석 정보에 대한 정보 요구들을

충족시키기 위한 통합 데이터베이스 .

- 모든 유형의 분석 정보들을 도출하기 위한 기초 자료들을 저장함 .

- 전사적인 수준의 정보 요구를 충족시키고자 한다는 점에서 ( 운영 )

데이터베이스와 유사한 점을 갖음 .

- 운영 데이터베이스는 거래 처리를 위한 데이터들을 지원하며 ,

이에 반해 , 데이터웨어하우스는 분석 정보들을 지원한다는 점에서 서로 근본적인 차이가 있음 .



- 데이터웨어 하우스는 개별 사용자들이 필요로 하는 분석 정보들을 총괄적 으로 지원하기 위한 통합 데이터베이스 .

- 여러 사용자들이 원하는 분석 정보를 쉽게 도출할 수 있도록 하는 기초 분석 정보 데이터베이스를 데이터웨어 하우스 .

- 데이터웨어 하우스는 전사적인 수준에서의 분석정보를 저장 , 관리함 . 따라서 운영 데이터베이스를 위한 전사적인 데이터 모형이 존재하는 것과 마찬가지로 데이터웨어 하우스를 위해서도 전사적인 데이터 모형이 존재 하여야 함 . 그리고 이들 데이터 모형들은 서로 유기적으로 연결 되어야 함 . - 분석 정보들은 운영 데이터베이스로부터 도출됨 . 데이터웨어하우스와 운영 데이터베이스는 서로 독자적으로 구축되어서는 안됨 . 서로 유기적으로 구축 , 관리되어야 함 .



- 데이터웨어 하우스는 전사적인 수준에서 통합관리 되어야 하며 ,

전사적인 수준에서의 통합 관리가 결여될 경우에는 , 데이터웨어 하우스에

저장된 분석 정보들이 운영 데이터들과 일치하지 않거나 ,

분석 정보들이 서로 비교 기준이 다르거나 다른 의미를 가지는 문제들을 발생 시킴 .


데이터 마트 데이터 마트

- 데이터웨어 하우스는 전사적인 수준에서 구축하여 운영하는 것이 이론적으로 매우 바람직함 .

- 현실적으로 방대한 데이터웨어 하우스를 단일 프로젝트로 구축하는 것은 거의가 불가능함 .

- 비록 하나의 통합 데이터웨어 하우스가 구축되었다고 하여도 ,

모든 정보 사용자들이 모두 하나의 데이터웨어 하우스를 이용하는 것이 효율성의 관점에서 볼 때 효과적이지 않을 수 있음 .

- 데이터웨어 하우스의 구축과 이용이라는 관점에서 볼 때는 이를 소규모로 분할하여 구축 , 이용하는 것이 보다 효과적 .


데이터 마트 데이터 마트

- 소규모로 구축된 데이터웨어 하우스를 데이터마트 (data mart) 라고 함 .

- 데이터 마트는 보통 전사적인 수준이 아닌 이의 하위 단위로서 부서 업무를

위한 주제별로 구축되는 것이 일반적 .

판매 정보 분석을 위하여 고객 관리 데이터마트를 구축하며 , 생산 계획을 위하여 생산 / 판매 데이터마트를 구축하여 운용 가능 .

- 특정 지역 또는 사업부 별로 데이터마트를 구축 가능 .

- 데이터마트의 구축과 운용은 전사적 데이터웨어하우스와 비교하여 볼 때 , 훨씬 간단한 형태를 갖음 .


데이터웨어 하우스의 유형 데이터웨어 하우스의 유형

- 데이터웨어 하우스는 전사적인 수준에서 통합적으로 구축될 수 있음 , 개별 부서 또는 주제분야별로 복수의 데이터마트들을 구축하여 이용 가능 .

이러한 구축 전략에 따라 데이터웨어하우스는 그림 17-8 에 제시된 바와 같이 3 가지의 유형을 가짐 .

1) 전사적인 수준에서 하나의 통합 데이터웨어 하우스를 구축하여 운용하는 것 . 이 경우 모든 정보 사용자들은 단일의 데이터웨어하우스에 저장된 분석 정보들을 공유 .

2) 부서별 또는 주제 분야별로 독립된 데이터마트들을 구축하여 운용하는 것 . 이 경우 필요한 분석 정보를 위하여 개별 데이터마트를 이용하게 됨 . 따라서 데이터마트의 구축과 운용은 전사적 데이터웨어하우스와 비교하여 볼 때 , 훨씬 간단한 형태를 가짐 .


데이터웨어 하우스의 유형 데이터웨어 하우스의 유형

3) 데이터웨어하우스를 구축하고 이에 종속된 데이터마트들을 구축하여 이용하는 것 .

두번째의 유형에서 살펴본 바와 같이 독립 데이터마트는 구축과 운용적인 측면에서 매우 많은 장점을 가짐 .

개별적인 데이터마트들이 양산됨으로써 분석정보의 통합 관리가 매우 어려움 .

실제 운용은 데이터마트 중심으로 하되 이들을 개별적으로 구축하는

것이 아니라 , 전사적인 통합 데이터웨어 하우스를 매개로 하여 구축

하는 방안 .


데이터웨어 하우스 스키마 데이터웨어 하우스 스키마

- 데이터웨어 하우스는 정규화된 형태로 저장하여 관리하는 것 보다는 분석 및 검색 위주로 저장 , 관리하는 것이 보다 효과적 .

이를 위해 제시된 데이터베이스 스키마가 스타 스키마와 다차원 데이터

모형 .

- 스타 스키마 데이터웨어 하우스는 정보의 검색과 분석을 위주로 하는 데이터베이스 .

이의 데이터 구조 또한 이러한 목적에 부합되는 형태를 가짐 .

분석 영역별로 주요 분석 자료들을 저장하고 ,

이들 자료들을 여러 차원에서 분석할 수 있도록 하는 형태를 가짐 .

특히 데이터 마트들은 이러한 형태를 가짐 .



- 스타 스키마 ( 계속 )

분석 대상 자료들이 저장된 테이블을 자료테이블 (fact table) 이라고 하며 , 분석의 경로를 제공하는 테이블을 차원 테이블 (dimensional table) 이라고 함 .

자료 테이블은 분석 대상 자료들을 중복하여 하나의 테이블에 모두 포함 함 . 즉 , 자료 테이블은 제 1 정규형의 형태를 가짐 . 차원 테이블들은 분류키들만을 포함함 . 데이터마트의 데이터 구조가 스타 스키마의 형태를 가지는 이유는 검색의 편의를 위주로 한 데이터베이스 구축이기 때문 .



- 스타 스키마 ( 계속 )

몇백만 또는 몇천만개의 레코드로부터 유용한 정보들을 수시로 분석 도출 하기 위해서는 검색의 효율성이 무엇보다도 우선되어야 함 .

데이터웨어 하우스는 많은 경우 , 주기적으로 배치 작업에 의하여 갱신됨 .

따라서 갱신의 편의를 운영 데이터베이스의 스키마는 적합하지 않음 .

- 그림 17-9 의 스타 스키마에 포함된 데이터들을 정규화하여 저장하면 그림 17-10과

같이 설계됨 .

이들 정규화된 릴레이션들로부터 분석정보를 도출하기 위해서는 여러 릴레이션 들을 반복적으로 결합하는 과정을 거쳐야 함 .

- 정규화된 데이터베이스 스키마는 데이터베이스의 갱신 관리를 위해서는 적합한 모형이나 검색을 위해서는 비효율적인 모형 .


DWDW 의 의 DB DB 스키마스키마 : Star : Star 스키마스키마

주문주문번호

nonkey data공급자 번호 nonkey data고객번호

nonkey data제품번호

nonkey data송장번호

nonkey data

주문량일자

송장송장번호

nonkey data

고객고객번호

nonkey data

공급자공급자 번호 nonkey data

제품제품번호

nonkey data


상세주문주문번호 제품번호주문량

송장송장번호

nonkey data

고객고객번호nonkey data

공급자공급자 번호 nonkey data

제품제품번호nonkey data

공급공급자번호제품번호

주문주문번호 고객번호송장번호주문일

정규화 데이타베이스 스키마정규화 데이타베이스 스키마



- 스타 스키마 ( 계속 ) 관계형 데이터베이스를 이용 , 데이터웨어 하우스를 구축할 경우에는 스타스키마를 기준으로 함 .

- 다차원 데이터 모형 스타스키마는 관계형 데이터 모형에서 데이터 마트를 구축하고 , 정보 분석을 위한 매우 효과적인 수단 .

스타 스키마에서도 필요한 조건의 정보들을 추출하기 위해서는 차원 테이블과 자료 테이블들을 결합 하여야 함 .

스타 스키마는 평면적인 형태의 관계형 데이터베이스를 차원 분석이 가능

하도록 변형한 것임 .



- 다차원 데이터 모형 ( 계속 )

기본적인 데이터의 검색 작업은 관계형 데이터베이스의 테이블들을 이용하여 이들을 조인하고 선택하는 과정을 따름 .

관계형 데이터 모형과는 달리 , 이러한 분류별 자료들을 직접 표현하고 관리할 수 있도록 한 데이터 구조가 다차원 데이터 모형 .

행렬 (matrix) 과 같이 첨자를 이용 , 원하는 유형의 값을 곧바로 찾을 수 있도록 한 데이터 모형 .

다차원 데이터베이스에서는 데이터 검색을 위하여 다른 데이터들을 비교하거나 결합하는 과정이 불필요 .



- 다차원 데이터 모형 ( 계속 )

다차원 데이터베이스는 여러 데이터들 사이의 연관 분석이 불가능하며 ,

설계된 행렬 구조 안에서만 다차원 분석이 용이하다는 단점을 가짐 .

특정 주제별 분석을 위한 데이터마트에서 온라인 정보 분석을 위하여 많이 이용됨 ( 다차원 온라인 정보분석이라고 함 )

스타 스키마를 이용한 방법을 관계형 온라인 정보 분석이라고 함 .


데이터웨어 하우스의 기술적 구조 데이터웨어 하우스의 기술적 구조

- 데이터웨어하우스는 운영 데이터베이스 , 데이터마트 , 전사적 데이터웨어

하우스 , 정보 분석 도구 등의 여러 개념이 서로 연관된 데이터의 이용 환경 .

- 원시 데이터들은 반드시 관계형 데이터베이스에 저장된 것은 아님 .

즉 , 여러 가지 형태의 파일 시스템을 포함할 수도 있음 .

경우에 따라서는 IMS 와 같은 비관계형 데이터베이스 구조를 가질 수도 있음 .

데이터의 변환 처리 도구들은 여러 형태의 원시 데이터들로부터 필요한 분석 정보들을 추출 , 변환할 수 있는 기능을 제공할 수 있음 .



- 데이터마트는 데이터웨어하우스에 저장된 분석 정보들 중 일부를 복제 하거나 이로부터 새로운 형태의 분석 정보들을 증식하여 저장함 . 이러한 데이터마트를 효과적으로 구축하기 위해서는 이를 위한 데이터 복제 및 증식 도구들이 필요함 .

- 온라인 정보 분석 ( OnLine Analytic Processing ) 데이터웨어하우스 또는 데이터마트에 저장된 분석정보로부터 원하는 형태의 정보들을 실시간으로 추출하는 작업을 온라인 정보 분석이라 함 . - 온라인 정보 분석을 위해서는 분석 정보들이 분석 차원별로 정리되어 있어 , 이들 차원별로 세분화 (drill down) 와 합산 (scale up) 이 자동적으로 이루어 질 수 있음 .



- 질의 도구는 데이터 질의 및 조작 기능을 기반으로 하여 ,

사용자들이 원하는 유형의 정보를 쉽게 파악하고 보고서들을 손쉽게 작성할 수 있도록 함 .

- 검색된 데이터들을 쉽게 변환하여 시각적으로 도시할 수 있는 도구들이 필요함 .

- 데이터웨어하우스 또는 데이터마트를 기초로 업무 분석 또는 의사결정 지원 시스템을 매우 쉽게 구축 가능 .

- 의사결정시스템 ( DSS: Decision Support System ) 이나 중역 정보 시스템 ( EIS: Executive Information System ) 은 데이터웨어하우스에 저장된 분석 정보들을 사용자들이 실제로 활용할 수 있도록 하는 응용 시스템 .


전사적 데이터 관리 구조 전사적 데이터 관리 구조

- 기업 내에서 활용하는 데이터들은 크게 운영 데이터와 분석정보로 구분됨 .

운영 데이터는 업무 처리와 연관된 데이터로서 운영 데이터베이스에 저장됨

- 분석정보는 경영관리나 경영의사 결정을 위하여 필요한 정보들로서 데이터웨어 하우스에 저장됨 .

- 운영 데이터베이스로부터 분석 정보들을 도출 , 데이터웨어하우스에 적재 하기 위해서는 운영 데이터들을 변환 처리하고 정제하여야 함 .

- 운영 데이터들을 통합하여 조정하고 이로부터 분석정보를 도출하는 단계를 거쳐야 함 .



- 전사적 데이터관리 계층 운영 데이터베이스와 데이터웨어하우스는 물리적으로 분산하여 , 저장 관리됨 .

- 운영 데이터와 분석 정보의 성격이 서로 다르고 이들의 이용 양태 또한 서로 다름 . - 운영데이터들은 새로운 트랜잭션의 처리와 더불어 갱신됨 .

- 분석정보들은 업무 처리를 위한 트랜잭션들과는 별도로 이용됨 .

- 여러 개의 운영 데이터베이스들을 통합 , 구축한 전사적인 데이터베이스를

운영 데이터스토어 ( operational data store ) 라고 함 .



- 전사적 데이터관리 계층 기업내의 정보들은 운영 데이터베이스와 운영 데이터스토어 및 데이터웨어하우스에 저장되는 3 계층의 데이터관리 구조를 가짐 .

- 데이터웨어하우스는 전사적인 수준에서의 분석 정보들을 통합 저장함 . 따라서 사용자들이 필요로 하는 분석 정보들을 모두 포함함 . - 분석정보를 이용한 효과적인 경영 의사결정을 위해서는 요약 처리 데이터들만이 아니라 , 경우에 따라서는 상세 데이터들을 분석하여야 하는 경우도 발생함 .

- 요약 처리 데이터와 상세 운영 데이터를 같이 데이터웨어하우스에 저장 하여야 함 . 즉 , 운영 데이터의 처리는 요약 처리와 상세 보존의 2 계층 구조로 진행되어야 함 .


33 계층 데이터 구조계층 데이터 구조

요약 처리 데이터

통합 조정 데이터

Operational 데이터

informationalsystems

operationalsystems


2 2 계층 데이터 처리계층 데이터 처리 // 요약요약

운용데이터

상세 보존데이터

요약 처리데이터(profile data)


사례사례 : : 보험 데이터 웨어하우스보험 데이터 웨어하우스

보험 청구청구번호보험증권번호청구일청구액유형피해액보상액피보험자 과실

상담사별 요약 자료상담사별 요약 자료상담사월

총 청구건수총 청구액해결 건수

유형별 요약 자료유형별 요약 자료유형월

총 청구건수총 청구액해결 건수

상세 보존 데이터상세 보존 데이터

청구번호보험증권번호청구일청구액유형피해액보상액피보험자 과실


기술적 특성기술적 특성 : DW: DW 의 유형의 유형

( 출처 : Gardner, S. “Building the DW,” CACM 41(9), 1998, 52-60)

Enterprise Data Warehouse

Independent Data Mart

Dependent Data Mart


DW DW 프로젝트프로젝트

• 동기– 정보의 가용성 및 접근성 (better access to information)

– 정확한 정보 (more accurate information)

– 통일된 정보 (a single source of information)

• 기대효과– 시간 절약

데이터의 처리 : 데이터의 수집 / 정리 = 1 : 3~4

– 더 많은 더 좋은 정보– 더 나은 의사결정– 업무 처리 절차의 개선– 전략적 목표 달성 지원


DW DW 프로젝트의 수행프로젝트의 수행

• 애로점

– 경영적 애로

전사적 DW 에 대한 이익 실현 (ROI : Return On Investment) 증명

– 기술적 애로

• 접근 방법– 데이터 중심

– 응용 프로젝트 중심 : ( 예 ) 판매 및 마케팅 분석


DWDW 의 프레임워크의 프레임워크

Power analysts

Oper.MgrData Analyst Network Act App. DevDB admin

Sequential Nonrelational Relational External

Extract Filter Condition Scrub Household Load

Corporate Memory

Detail Data(Normalized)

RDBMS(Relational/Paralled)

Sample Version of the Truth

SourceTarget Target

Marketing, Finace,humanResources, Sale

Customers,supplier,Partners

% Clustering Statistical

w I I i i

?Artificial Intelligence

?Decision Tree

?

OLAP

Objects and LanguageDevelopment

?

EIS/DSS

Knowledge Worker

Executive Manager

Customer Contact

Application Server

Data Visualization Spreadsheet

IT User

Operational/Source Data

DataTransformationEnterpriseWarehouse andManagement

Replication andpropagation

Dependent orindependentData MartKnowledgeDiscovery,Data Mining

InformationAccess Tools

Business User

Dat

a A

cces

s La

yer

busi

ness

Info

rmat

ion

Dis

cove

ry /

Met

adat

aLog

ical

/ P

hysi

cal D

ata

Dic

tiona

ry

Net

wor

k / D

atab

ase

/ Sys

tem

s M

anag

emen

t

Bus

ines

s an

d T

echn

olog

y S

ervi

ce


데이타웨어하우스 개발 방법론데이타웨어하우스 개발 방법론

Business(Req.) Discovery

Data WarehouseConsulting

DataWarehouse

InformationDiscovery

DWLogicalData Modeling

DWArchitechure Design

Client/ServerApplicationDev. (Full Cycle)

Data PhysicalDB Design

DW DataTransformation

Data Warehouse Management(Process and Operation)

DataWarehouse

SolutionReadiness

Data Mining andAnalyticalApplication

DataWarehouse

Solutionintegration

EnterpriseSystem Support

DWLogicalDB Review

DWPhysicalDB Review

DWTuning

DWCapacity Planning

DWAudit

Data Warehouse PlainningData Warehouse Design and Implementation

Data Warehouse Usage,Support, and Enhancement


데이타웨어하우징의 공학적 성공요인 데이타웨어하우징의 공학적 성공요인 (CSF)(CSF)

• 메타데이타의 관리데이터의 외부 특성 (makeup of the data) 은 명료하게 유지하면서 기술적 특성들은 사용자로부터 차단

• 데이터의 변환 및 정제 ( 데이타웨어하우스의 운용 )

Data warehousing is a process, not a product,for assembling and managing data from various sources

for the purpose of gaining a single, detailed view of part or all of a business

• DBMS: scalability and high responsiveness

• 데이타베이스 구조 : 스타 스키마


기술적 특성기술적 특성• 대량의 데이터 관리• 다양한 저장 매체• 유연한 인덱싱• 다양한 외부 시스템과의 연동• 병행 데이터 관리 ( 저장 /검색 )

• 메타 데이터 관리• 다양한 검색 언어• 데이터 로딩• 복합키• 가변 길이 데이터의 처리

데이터 웨어하우징

Documents