OLAP 대해서

OLAP 테크놀로지

제1부: OLAP의 이해

OLAP의 정의

• 그림 1.1 P 전자 매출액 분석

– 이 달의 각 권역별 매출액을 전년 동월과 비교한 결과는?

– Drill-Down: 강남권의 매출 정보는?

– Drill-Down: 압구정점에서 각 제품별 매출액은?

– 제품별 목표대비 실적현황은?

• Online으로 분석(Analysis) 처리: OLAP

• 1993년 E.F.Codd에 의해 정의

– 최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하여 의사결정에 활용하는 과정

• 다차원 정보란? 

– 다양한 관점/각도에서 정보를 재구성하여 조회, 그림 1.2

OLAP 히스토리

• 그림 2.1

– 1962년 다차원 프로세싱의 개념 탄생

– 1972년 EXPRESS 분석 소프트웨어 등장

– 1999년 Microsoft OLAP 등장: 대중화 및 표준화

• OLAP Council 설립, 표준화 기여

– OLAP API

– RDB처럼 표준화 추진

• 기업의 데이터가 중요한 전략적 자산

• 최근에 많은 제품들이 등장

– RDB Vendor들도 자사 제품에 포함

– 국내에서도 관심 증대

데이타웨어하우징과 OLAP

• 운영시스템(Operational system)

– Transation Processing sytstem: OLTP

– 은행 업무, 비행기 예약 등 일상적 업무 처리 영역

• 의사결정 지원시스템(Decision support system)

– 다양한 DSS 시스템의 개발 및 활용: 그림 3.1의 현상 발생

• 데이터 웨어하우징

– 기존 시스템의 한계 극복, 그림 3.2

– 분산된 DSS 시스템을 통합

– DB가 응용시스템의 데이터를 통합한 것과 동일

– 아키텍쳐: 그림 3.3

• 데이터 추출 및 가공: Extraction, Transformation, cleansing

• 추출 및 변형 과정에서 Mapping rule 등의 부가 데이터를 메타 데이터로 관리, 통제: Metadata Repository로 중앙집중적으로 관리

– RDB의 시스템 카탈로그 참조

데이터 웨어하우스와 데이터 마트

• Data Mart: 이해가 동일한 사용자 집단에 특화된 DW

– 응답 성능 향상 및 부서별 데이터 관리

– 그림 3.4

– 웨어하우스로의 Drill-Through가 필요

• 상세한 FACT DATA가 필요한 경우

• 데이터 마트의 종류

– 종속형 데이타마트: 그림 3.5

• Top down approach

• DW를 구축한 후에 Mart를 구축: DW에 종속적(dependent)

– 독립형 데이타마트

• Bottom up approach

• DW없이 구축:DW 구축 비용 및 절차 생략

• 단발적 솔루션(point-solution)의 가능성

• 데이터 통합이 부분적으로 구성, 사업 부서 사이의 연계적 부분(cross function)이 부족

웨어하우스 액세스 툴

• Query & Reporting Tool

– 기존의 RDB에서 사용된 전통적인 도구

• OLAP Tool

• Data Mining Tool

– 현재 가장 많이 사용되는 도구

• 데이터 웨어하우징과 OLAP

– 그림 3.6, 구축: Warehousing, 활용: OLAP

메타 데이터 관리

• 웨어하우스의 관리를 위한 메타데이타

– 추출될 데이터

– 추출된 데이터의 변환 규칙

– 웨어하우스 데이터와의 대응관계

– 추출 주기 등

• 다양한 Vendor의 제품에 따른 형식 상이, 데이터 교환 문제!

• Meta Data Coalition

– 다양한 툴간의 메타 데이터 교환을 위한 표준 정의

– 1996년 MDIS(Meta Data Interchange Spec) 정의

– Http://www.mdcinfo.com

• Microsoft의 OIM(Open Information Model)

– UML, XML 기반 정의, de facto standard?

제2부 다차원 모델

4장: 다차원 모델의 구성요소

5장 스타 스키마

6장 차원 및 큐브의 이해

4장. 다차원 모델의 구성 요소

• 차원과 차원 항목

– 다차원 모델은 큐브(cube)로 표현

– 차원(dimension)은 큐브의 축(axis)

• 예) 변수, 매장, 제품의 3개 차원 큐브, 그림 4.1

– 차원 항목은 차원을 구성하는 멤버(member, element)

• 제품 차원은 냉장고, 세탁기 등, 변수 차원은 매출액, 수량 등

• 4차원 이상의 경우 시각화가 곤란

– 5차원 큐브의 예: 그림 4.2, 

• 큐브와 셀

– 셀: 큐브의 차원 조합으로 만들어지는 공간, 데이터가 저장

– 셀의 개수: 차원 항목의 조합 수

– 그림 4.3 및 셀의 참조 예: 그림 4.4

– 셀은 논리적으로 존재하는 가상 공간, 물리적으로 없을 수 있음

• 예) 반포 매장에서 냉장고 판매가 없는 경우 데이터는 없음.

• 데이터의 희박성(sparsity)

계층 구조

• 차원들은 계층 구조를 가진다.

– 그림 4.5의 기간 차원 계층 구조 예, 총 19개 항목으로 구성

– 항목들간의 Parent, Child, sibling의 관계

– 루트 항목과 리프 항목(detail)

– Ancestor와 descendent 관계

• 복수의 계층 구조

– 항목들의 그룹핑 구조가 계층, 분석을 용이하게 함.

– 그림 4.6과 같이 매장 차원을 지역/부서별 2개 계층으로 구성

– 계층 구조는 데이터가 집계(aggregation, 또는 consolidation)되는 경로임

– 다중 parent가 가능함

– 계층 구조에 이름을 부여하여 구별 가능

레벨

• 계층에는 다단계 레벨이 있음

– 레벨: 계층 구조상의 거리: 그림 4.7

– Generation: 루트에서 동일 거리의  항목들

• 계층 구조의 종류

– 대칭 계층 구조(symmetric, balanced): 그림 4.7

– 비대칭 계층 구조(asymmetric, unbalanced, ragged): 그림 4.8

• OLAP 제품마다 비대칭 계층 지원 여부에 차이

• 차원 항목들의 부분 집합으로 볼 수 있음.

• 그림 4.9 ORACLE DISCOVERER의 계층 구조 표현 예

• 계층과 레벨을 이용한 항목의 상대적 참조에 사용

– 1월, 2월, 3월 대신 1/4분기의 차일드

– 1월, 2월,…, 12월 대신 ‘월’ 레벨의 항목

애트리뷰트

• 차원을 구성하는 항목들의 특성, 또는 property

• 예) “제품의 특정 색상에 따른 매출액?”

– 이때 제품 차원의 색상이 애트리뷰트(attribute)임

• 예) 매장 차원의 경우

– 주소, 전화번호, 담당자, 매장 크기, 개점일 등

• OLAP 제품마다 애트리뷰트 처리가 상이

– ROLAP에서 차원의 레벨과 애트리뷰트는 테이블의 열로 동일하게 취급

관계식

• 변수차원 예: 매출액과 매출수량

• 새로운 항목을 기존 항목 사이의 관계식으로 유도 가능

– 평균매출가격=매출액/매출수량

– Spreadsheet에서 다양한 계산식 활용과 유사: 그림 4.10

• OLAP 툴마다 관계식 지원 상이

– Essbase에서의 관계식 정의 예: 그림 4.12

– 대체로 변수 차원에 한정: 수치 데이터

– 수치가 아닌 항목들간의 관계식과 응용 분야는?

• 계층 구조와 관계식

– 계층 구조는 큰 의미에서의 관계식

• 1/4분기 항목은 차일드 항목간에 덧셈연산 관계

• 1/4분기=1월+2월+3월(additive relationship)

차원간 관계식

• 차원내 (intra-dimension)의 항목간외에도 차원간(inter-dimension)의 관계식도 가능

– 예1) 변수 차원: 매출액, 세금이 있고, 제품유형에 따라 적용 세율이 다른 경우

• 에어컨: 세금 = 제품 매출액 * 0.2

• 기타 제품: 세금 = 제품 매출액 * 0.1

• 셀에 저장된 값을 따라 관계식이 다른 경우

– 예2) 매출액이 100,000 이상인 경우 세금은 20%, 이하이면 10%

• 매출액 >= 100000 이면 세금 = 매출액 * 0.2

• 계층 구조나 데이터 값을 참조한 관계식 지원여부는 OLAP 제품마다 상이

• 복잡한 비즈니스 로직을 반영할 수 있음.

다차원 모델의 구성 요소

• 구성 요소: 그림 4.13

• 차원의 설정

– 사용자의 관점에서 설정

– 다른 항목과 독립적인 항목들의 집합

– 구체적인 정의 방식은 제품마다 상이

– 4차원-8차원 이내가 일반적

• 차원이 많은 경우: 상관 관계가 높은 차원이 발생

• 차원의 독립성 검토 필요

– 비즈니스에 대한 깊은 지식이 필요

• OLAP 메타데이타

– 차원, 계층 구조, 레벨, 관계식, 애트리뷰트

5장 스타스키마

• 다차원 데이터를 표현하기 위한 관계형 DB design

• 사실(fact) 테이블과 차원(dimension) 테이블로 구성

• 그림5.1 스타스키마 예

– 사실: 분석을 요하는 변수차원의 항목

• 매출액, 매출 수량 등, numeric data/measure data

• 사실 테이블에 저장

– 차원: ‘사실’을 보는 관점

• 각 차원은 별도의 각각 차원 테이블에 저장

• 사실 테이블

– 유일하게 정규화된(normalized) 테이블

– 가장 큰 테이블: 대규모 소매업의 경우 수억 개의 행을 가짐

– 그림5.2

• 매장키, 제품키, 기간키: 각 차원 테이블을 연결하는 외래키

• 차원 테이블의 기본키와 조인에 사용(매장 차원의 매장키)

– 사실 테이블의 기본키는 외래키의 조합(composite key)

스타스키마

• 스타스키마의 키값: 무의미, 인위적으로 생성된 키

– 각 레코드를 구분할 수 있는 정수로 생성

– 최소 인덱스 공간과 많은 인덱스가 메모리로 적재 가능

• 사실의 유형

– 차원 항목의 계층 구조에 따른 집계 연산에서 주로 합계 가능한 사실

– 매출액, 판매수량 등

– 모든 차원에 대해 합산 가능한 사실: Additive facts

– 일부 차원에 대해서만 합산 가능한 사실

• 재고량의 경우, 매장 차원의 합산은 의미가 있음

• 제품 차원에서 재고량을 집계하는 것은 무의미(그림 5.3)

• Semi-additive facts

– 합산이 되지 않는 사실

• 제품별 판매가격은 합산이 무의미

• Non-additive facts

차원 테이블

• 사실에 대한 사용자 관점으로 서술적(descriptive) 정보를 저장

• 그림5.5 매장 차원 테이블의 예

– 매장 차원의 계층 정보와 애트리뷰트 정보로 구성

– 비정규화(denormalized) 구조: 조인 횟수 감소

– Read Only이므로 OLTP와 차이

• 차원 테이블의 공유

– 여러 스타스키마 사이에서 공유 가능

– 매출분석에서 매장, 제품, 기간과 재무분석의 계정, 부서, 기간 차원이 사용되는 경우

– 기간 차원이 주로 공유

– 공유 차원을 중심으로 다차원 모델간에 Drill-across 연산이 가능

차원 테이블

• 애트리뷰트

– 주로 텍스트 형태의 데이터

– 매장의 면적 등 수치 데이터도 가능

– 차원에 대한 다양한 조건 필터링이 가능

– 각 차원 테이블에 대한 조건 질의를 만족하는 레코드를 가지고 사실 테이블을 검색

– 그림5.2 강남권 매장의 매출액 조회시 SQL 예 (p. 83)

• 사실 테이블에 비해 크기 현저히 작다

• 스타스키마에 대한 분석시 차원테이블 우선 검색 후 사실 테이블 검색

• 애트리뷰트와 계층 구조: 그림5.6

– 애트리뷰트의 일부를 이용하여 차원의 계층 표현

– 애트리뷰트 계층구조(attribute hierarchy)

– ROLAP 툴에 의해 정의, Metadata로 관리

– 그림 5.7 플래티늄사의 InfoBeacon 예 

차원 테이블

• 비대칭 계층 구조의 처리

– 대부분의 ROLAP 제품은 비대칭 계층 구조의 효과적인 표현 곤란

– MOLAP 제품은 효과적으로 처리

– 그림 5.8, 관계형 테이블에서 리커시브(recursive) 테이블 을 이용하여 계층 표현 예

• 페어런트와 차일드 컬럼 2개로 모든 비대칭 계층을 표현

• self recursive join이 필요: SQL로 표현이 어려움.

• 실제 ROLAP에서 사용되는 경우 드뭄.

• 연속된 값을 가지는 애트리뷰트

– 나이와 소득 애트리뷰트의 경우 연속된 값(continuous value)

– 구체적인 값 자체는 무의미

– 몇 개의 그룹으로 묶는 것이 합리적

• 나이: 연령대별, 소득: 일정 액수대별

차원 테이블

• 차원 항목간 다대다 관계가 있는 경우 차원 테이블 구조

• 제품 차원에서

– 한 제품이 여러 제품군에 속하는 경우: 제품과 제품군은 다대다의 관계

– 그림 5.9

– Normalized table design: Snowflake Schema

• 점진적으로 변화하는 차원(slowly changing dimension)

– 차원 항목의 애트리뷰트 값이나, 계층 구조가 시간에 따라 변화

– 예) 매장 담당자, 전화번호 변경, 권역 조정 등 (그림5.10)

– 3가지 접근 방법

• 새로운 값으로 갱신 (그림5.11, 매장 유형의 변경예)

– 구현 용이, 과거 자료 분실, 추이 파악 불가

• 새 값을 가지는 레코드의 추가 (그림5.12)

• 새 필드를 추가: 그림5.14, 시작유형/현재유형/최종 변경일 추가

– 추가 애트리뷰트의 생성, 관리 부담

– 초기값과 현재값만 파악 가능/중간 단계의 값은 분석불가

E-R 모델과 스타스키마

• 1976년 데이터 모델링 기법으로 제안

• 논리적 데이타베이스 설계의 표준적 접근법

• 정규화(normalization)

– 데이터 항목간의 종속성을 기반으로 중복성 제거 이론

– 데이터 무결성(integrity)를 유지하기 용이

– 갱신 성능의 최적화

– 질의 연산의 경우 많은 조인이 요구

• 비정규화(denormalization)

– 릴레이션을 분해하지 않고 통합, 고의적인 중복성 허용

– 그림 5.14: 차원과 사실을 모두 한 테이블에 표현한 예

• Matrix 스키마라고도 함

• Excel의 Pivot, Delphi 3.0의  DecisionCube에서 사용

• 데이터 양이 소규모인 경우에 가능

• OLAP 환경에서는 스타 스키마를 사용

E-R 모델과 스타스키마

• 1980년대 초 메타포어(Metaphor)에 의해  개발

• OLAP을 위한 비정규화의 특수 형태

– 최종 사용자의 관점에서 모델을 간단히 표현

– Application oriented, End-user oriented model!!

• 스노우플레이크(snowflake, 눈송이) 스키마

– 스타 스키마는 특정 차원의 모든 정보를 한 테이블에 비정규화해서 저장

– 차원테이블을 정규화한 것, 그림 5.15

– 대권역 정보 검색시 신속 처리 가능

– 저장 공간 감소 및 무결성 유지

– 구조 복잡, 조인에 따른 응답 성능 저하

– Kimball은 이 스키마를 반대: 저장 공간은 무시해도 좋다!

– 그림5.16, 적절한 수준에서의 비정규화 필요!

스타스키마와 ROLAP 툴

• 스타스키마는 데이타베이스 모델 스키마임.

• ROLAP 툴이 스타스키마를 다차원 모델로 변환

– 메타데이타 정의 요구

– 그림5.17

– 그림5.18 인포비콘 ROLAP 툴의 

• 예: 스타스키마에서 메타데이타를 정의하여 다차원 모델로 변환되는 과정

– ROLAP 툴에서, 메타데이타도 테이블로 저장

– 사용자의 질의는 메타데이타를 참조하여 적절한 SQL로 변환

– 하나의 OLAP 툴에서 정의된 메타데이타는 다른 툴에서 이용 불가능

• ROLAP 간, ROLAP/MOLAP간 교환 필요

• DB에서는 테이블간의 EXPORT/IMPORT가 용이

• DB TABLE SCHEMA(Metadata)는 SQL 표준안에서 정의