OLAP(OnLine Analytical Processing)
I. OLAP
OLAP(OnLine Analytical Processing)은 '
최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정을 활용하는 과정(조재희/박성진, 1996)'으로 정의 할 수 있다.
1.
다차원 정보
정보란 본질적으로 비교를 통해 얻어진다. 사용자는 단순히 '이번 달 매출액이 얼마인가?'라고 물어보지 않는다. 만약 어떤 사용자가 이렇게 질문을 했다면 사용자는 묵시적으로 지난달 매출액이 얼마인지, 혹은 목표로 잡은 매출액이 얼마인지를 알고 있기 때문에 이처럼 질문 했을 것이다. 이와 같이 사용자는 정보를 분석하기 위해 비교하기를 원하며 이러한 다양한 각도에서 수행되어야 한다. 이러한 각도를 정보를 구성하는 차원으로 생각할 수 있다. 이러한 의미에서 정보는 본질적으로 다차원적이며, 다차원 모델은 비즈니스를 표현하는 가장 자연스러운 형태이다.
2.
직접 접근
일반적으로 기업의 데이터는 전산부서에 의해 관리되며 기업의 전산 시스템은 데이터의 수집과 갱신에 초점을 맞추어 설계되어 있다. 따라서 데이터는 사용자가 원하는 형태로 존재하지 않으며, 이러한 시스템으로부터 필요한 정보를 찿아내고 가공하는 일은 전산 환경에 익숙하지 못한 사용자에게 어려운 일이다. 결국 사용자는 자신이 필요로하는 정보를 전산 부서에 요청하게 된다. 이에 비해 OLAP환경에서 정보는 쉽게 이해할 수 있고 조작하기 쉬운 형태로 존재한다. 다차원 정보는 사용자의 관점에서 구축된다. 사용자는 필요한 시점에 정보 매개자 없이 정보원에 직접 접근하여 다양한 각도에서 분석을 수행 할 수 있다.
3.
대화식 분석
기존의 정형화된 보고서만으로는 사용자의 다양한 정보 요구에 제대로 대처할 수 없다. OLAP환경에서 사용자는 정형화된 보고서를 단순히 조회하는 방식에서 벗어나 대화식으로 정보를 분석하게 된다. 대화식 정보 분석에서 하나의 질문에 대한 답은 질문을 이끌어낸다. 사용자는 필요한 테이터를 요청하고 결과를 얻는다. 사용자는 얻은 결과를 분석하고 이 새로운 정보를 이용해 또 다른 질문을 던진다. 이처럼 OLAP환경에서 사용자는 시스템과의 상호작용을 통해 정보를 분석하며 원하는 결과를 얻을 때까지 계속해서 분석을 수행하게 된다. OLAP시스템은 이러한 대화식 분석과정에서 사용자의 사고 흐름이 중간에 끊어지지 않도록 사용자 질의에 신속한 답을 제공해야 한다.
4.
의사결정에 활용
OLAP시스템의 목적은 사용자가 기업의 전반적인 상황을 이해할 수 있게하고 의사결정을 지원하는데 있다.
은행의 창구 업무나 항공사의 예약 업무 등은 전형적인 OLTP(OnLine Transaction Processing)의 예라고 할 수 있다. OLTP시스템은 원시 데이터가 실제로 발생하고 기록되는 '무엇(What)'에 초점을 맞추고 있으며, 현재 거래 상태를 정확하게 기록하고 갱신할 수 있도록 하는 것이 목표이다.
반면 OLAP시스템은 이렇게 수집된 데이터를 의사결정에 활용하는 측면을 담당하여 '왜(Why)'에 초점이 맞추어진다. 즉 OLTP시스템이 일상적인 기업의 운영을 지원하는 반면, OLAP시스템은 기업의 방향을 설정하는 역활을 한다.
|
OLTP |
OLAP |
| 워크플로우 기반 (업무 프로세스 중심) |
사용자의 분석 수행 기반 (주제 중심) |
트랜잭션 처리 (입력, 조회, 삭제, 수정)
운영자 계층 시스템 |
보고서, 분석, 계획 (조회, 제한적 입력/수정)
분석가 및 의사결정자 계층 시스템 |
| 2차원, 정규화 |
다차원, 계층구조 |
| 상세 데이터, 중복성 배제 |
요약 정보, 중복성 수용 |
소량의 데이터 처리
활용 패턴 단순, 고른 시간대 분포
시스템 자원 사용량 예측 용이 |
대량의 데이터 처리
활용 패턴 다양, 시간대 불규칙 분포
시스템 자원 사용량 예측 어려움 |
구축 후 데이터 축적 중심
전통적 개발 주기
시스템 구축 후 유지보수 단순 |
구축 후 데이터 축적 및 스키마 변경
반복 확장 개발 주기
시스템 구축 후 유지보수 전략 필요 |
사용자 중심 응용프로그램 (4GL)
Customizing 용이
정형화된 보고서/변경 어려움
단순한 화면 조작 |
전용 도구 (Off-the-Shelf, Out-of-Box)
Customizing 제한적
동적인 비정형 분석/변경 용이
EUC(End User Computing) 활성화 필요 |
OLAP라는 용어는 1993년 E.F.Codd에 처음 사용된 용어이며, “Analytical” 이라는 말에서 알 수 있듯이 OLAP은 데이터웨어하우스에 체계적으로 쌓여 있는 데이터 속에 담겨 있는 정보를 효율적으로 끌어내어 분석하고자 할 때 효율적이다. (물론, 데이터웨어하우스가 구축되어 있어야 OLAP 시스템을 구축할 수 있는 것은 아니다. “OLAP 마일스톤”에서 알 수 있듯이 OLAP은 데이터웨어하우스와 독립적으로 이미 훨씬 이전부터 태동하고 있었다.)
Nigel Pendse에 따르면 1995년에 OLAP Report를 설립할 때, OLAP 제품들의 기준을 정하는데 있어 많은 진통이 있었다. 많은 공급업체들이 OLAP을 표방했지만 이에 대한 적절한 기준을 제시하기가 어려웠던 것이다. 물론, RDBMS와 OLAP 개념의 창시자인 E.F Codd의 12가지 룰(1993)이 이미 널리 알려져 있었지만 복잡하고 실제로 적용하기 어려웠다. 그래서, 나름대로 개념을 다시 정립하였는데 이를 FASMI (Fast Analysis of Shared Multidimensional Information)라 하였다. 현재 대부분 OLAP의 정의를 언급하는 경우 FASMI를 이용하여 설명한다. (E.F. Codd의 12가지 룰은 6가지가 더 추가되어 18가지 룰로 재구성 되었다. 그렇지만, 별로 인용되지는 않는다.)
II. FASMI (Fast Analysis of Shared Multidimensional Information)(top)
FAST는 일반적으로 사용자의 쿼리에 대한 반응속도가 5초 이내인 것을 의미한다. 간단한 분석인 경우 1초 이내이고 아주 드물게 20초 이상 걸릴 수도 있다. 실제로 분석가들은 30초 이상 반응이 없으면 대개 “Crtl+Alt+Del”을 눌러 강제로 종료시킨다. 설사 끈기있게 기다려 결과를 본다 해도 분석과정에서 사고의 연속성을 상실해 버린다. 많은 OLAP 제품 공급업체들은 이러한 문제점을 해결하고자 나름대로의 기술을 개발하였지만 아직 완벽한 해결책을 내놓은 곳은 없다. 사용자들이 요구할 모든 데이터를 미리 구해 놓으면 반응속도는 빠르지만 데이터베이스가 폭발적으로 커졌고 (Data Explosion) 이를 피하기 위해 실시간으로 (on-the-fly) 계산하여 결과를 보여 주면 응답속도가 너무 느렸다. 그래서, 많은 경우 이 두 가지를 적절하게 조화시키는 방법을 추구하고 있다.
1. ANALYSIS
시스템이 사용자에게 임의의 비즈니스 로직과 통계적 분석 기능을 쉽게 제공해야 함을 의미한다. 최종 사용자에게 적절한 계산 능력을 부여함으로써 새로운 비정형 계산의 정의가 가능해야 하고 별도의 프로그래밍 없이 원하는 형태로 보고서를 만들어 낼 수 있어야 한다. 여기에는 타임 시리즈 분석, 비용 분배, 환율 변환, Goal-Seeking, 비정형 다차원 분석 등이 포함된다.
2. SHARED
동일한 데이터에 대해 다중 사용자가 동시에 공유하여 분석할 수 있어야 함을 의미한다. 여기에는 동일한 데이터에 대한 다중 사용자의 읽기/쓰기 작업이 포함된다. 따라서, 시스템은 이러한 작업이 적시에 안전하게 이루어질 수 있도록 하기 위하여 가능한한 데이터의 저장 단위인 셀 단위까지의 보안과 그 데이터에 대한 적절한 레벨에서의 락킹을 지원해야 한다. 이 부분은 많은 OLAP 제품들이 갖는 취약한 부분으로 읽기 전용만 지원하는 제품들도 많다.
3. MULTIDIMENSIONAL
OLAP을 정의하는데 있어 가장 키가 되는 개념인 다차원성을 의미한다. 시스템은 데이터를 다차원적으로(일단, 데이터를 바라보는 다양한 관점으로 이해하자. 나중에 개념을 다시 다룰 것이다.) 보여 줄 수 있어야 하며 여기에는 계층구조(Hierarchy)와 다중 계층구조(Multi-Hierarchy)에 대한 지원이 포함된다.
4. INFORMATION
얻을 수 있는 데이터와 필요에 의해 파생된 모든 정보를 의미한다. 이 때의 정보는 적절한 형태로 적절한 사람에게 적시에 제공됨으로써 정보로서의 가치를 극대화할 수 있다. (Right Form, Right People, Right Information, Right Time)
III. OLAP Milestone(top)
OLAP은 언뜻 생각하면 최근의 개념과 기술로 생각하기 쉬운데 실제로는 그 기원을 Ken Iverson이 1962년에 펴낸 “A Programming Language”라는 책에서 찾아볼 수 있다. 즉, 우리가 느끼지 못하고 있었을 뿐이지 특수한 형태로 이미 오래 전부터 존재해 왔었다는 것이다. 또한 어떤 분야 못지않게 치열한 경쟁이 있었고 그 속에서 기술 발전과 생존을 위해 업체와 업체간의 인수합병(실질적으로는 합병의 사례는 찾아보기 힘들다. 제품 중심의 인수가 대부분이었다고 보는 것이 더 적합하다.)이 많았던 것도 사실이다. 아래는 Nigel Pendse가 OLAP Report에서 제공하는 OLAP Milestone을 정리한 것이다.
OLAP Milestone (출처 : OLAP Report)
|
년도 |
사건 |
주석 |
|
1962 |
Ken Iverson :
“A Programming Language” |
최초의 다차원 언어
IBM 메인프레임 사용 (1960년 후반), 현재 제한된 영역에 사용.
일부 제품의 내부에 아직도 사용 (Adaytum Planning(1), Lex 2000) |
|
1970 |
Express 등장
(1970년대 후반에 기업용 버전) |
마케팅 응용프로그램을 겨냥한 최초의 다차원 툴
현재 시장 선두그룹 중 하나 (오라클 소유 : 1995)
코드는 많이 수정되었지만 개념과 데이터 모델은 유지. |
|
1982 |
Comshare System W 등장
(메인 프레임 용 : 1983) |
재무 응용프로그램을 겨냥한 최초의 OLAP 툴
신규 마케팅 없으며 IBM 메인프레임에 일부 사용.
윈도우 버전 Commander Prism은 여전히 사용
Essbase가 동일한 개념을 많이 이용 |
|
1984 |
Metaphor 출시 |
최초의 ROLAP 제품
Mac 전용 하드웨어와 제품의 고가로 판매 부진 |
|
1985 |
Pilot Command Center 출시 |
최초의 클라이언트/서버 EIS(2) 전용 OLAP
VAX 서버, PC 클라이언트 기반
타임 시리즈 지원
신규 마케팅 없음 |
|
1990 |
Cognos PowerPlay 출시 |
최초의 데스크-톱, 윈도우 OLAP
데스크-톱 영역에서 선두주자
최근 클라이언트/서버 및 웹버전 제공 (기능상 데스크-톱 영역으로 분류) |
|
1991 |
IBM : Metaphor 인수 |
OLAP 제품의 주인이 바뀌는 첫 사례
Metaphor는 Apple-IBM Taligent 합작 벤처의 일부가 됨
IDS라는 이름으로 명맥 유지, 고객사이트 거의 없음 |
|
1992 |
Essbase 출시 |
마케팅에 성공한 첫 OLAP 제품
1997년 이후 OLAP 서버 부분 선두주자 |
|
1993 |
Codd 백서 :
OLAP용어 탄생 |
Arbor Software의 의뢰로 작성
다차원분석에 대한 관심과 붐 조성 |
|
1994 |
MicroStrategy DSS Agent 출시 |
다차원엔진을 사용하지 않은 최초의 ROLAP 제품
Multi-pass SQL을 이용한 처리
거대 차원을 갖는 대용량 데이터베이스에 적합
서버 성능 저하 단점
3계층 하이브리드 아키텍쳐 (MicroStrategy 7.0) |
|
1995 |
Holos 4.0 출시 |
최초의 하이브리드 OLAP
관계형과 다차원데이터베이스를 동시에 접근
현재 다른 많은 OLAP 도구들도 동일한 접근방법 이용
현재 Seagate가 소유하고 있으며 시장에서 고전 중 |
|
1995 |
Oracle : Express 인수 |
OLAP을 세상에 알린 중요한 사건
다른 데이터베이스 공급업체들의 시장 참여 계기
Hybrid OLAP으로서 MOLAP, ROLAP 제품과 모두 경쟁 |
|
1996 |
BusinessObjects 4.0 출시 |
관계형 데이터로부터 동적으로 생성하는 데스크-톱 큐브로부터 매끄러운 다차원 및 관계형 보고서를 제공한 첫 제품
초기에는 문제가 많았으나 4.1, 5.0을 거치면서 많은 개선 |
|
1997 |
Microsoft :
OLE DB for OLAP 발표 |
프로젝트 코드명 : Tensor
업계 표준 OLAP API(3)로 자리 잡음
40여 이상의 업체들이 OLAP 제품 개발에 이용 |
|
1998 |
IBM DB2 OLAP Server 출시 |
모든 데이터를 관계형 DB2 또는 기타 관계형데이터베이스의 스타스키마 형태로 저장하는 Essbase 버전
ROLAP이라기 보다는 느린 MOLAP으로 이해 |
|
1998 |
Hyperion Solutions 출범 |
Arbor사와 Hyperion Software의 합병
OLAP 시장에서 최대 규모 합병
합병이라기 보다는 Hyperion에 대한 Arbor의 인수 성격
Microsoft의 OLAP 시장에 대한 신규 진출에 영향
대부분의 다른 OLAP 인수 경우와 같이 합병 결과는 부정적 |
|
1999 |
Microsoft OLAP Services 출시 |
프로젝트 코드명 : Plato
Panorama Software Systems 기술 기반 (1996년 인수)
OLAP 서버 시장에서 선두자리에 오름 : 배포의 용이성, 고성능의 저장 아키텍쳐 (ROLAP/MOLAP/Hybrid), 수많은 써드-파티 업체, 저가, 마케팅 능력 |
|
1999 |
CA :
소위 실패한 OLAP 서버들을 재정비 |
Platinum의 Prodea Beacon 인수, DecisionBase로 개명 (1999)
Sterling의 IA DecisionSuite 인수 (2000)
인수의 결과로 성장가능성을 보임 |
|
2000 |
Microsoft : 제품명 변경
OLAP Services -> Analysis Services |
(데이터마이닝 기능 추가에 따라) OLAP server의 두번째 출시 버전의 이름 변경. |
|
2000 |
XML for Analysis 공고 |
MS 주도의 다중 공급자, 크로스-플랫폼, XML기반 OLAP API(4) 발안. (나중에 Hyperion, SAS 조인) |
|
2001 |
Oracle :
Express의 후속 공급 시작 |
1970년부터 사용되어 오던 Express를 흡수하고 6년이 지나서, 그 후속으로 기대되는 Oracle9i OLAP 공급을 시작.
그렇지만, 새로운 세대의 Oracle OLAP 첫 출시는 완전하지 않았고 사용이 적합하지 않음.
기술 및 어플리케이션의 완전한 대체는, Express를 흡수한지 8년이 되는 2003년까지 그다지 기대되지는 않음. |
|
2001 |
MicroStrategy :
Strategy.com 포기 |
Strategy.com은 새로운 Microsoft가 되기 위한 MicroStrategy의 야심찬 전략이었다.
대신에, 거의 파산 직전에 직면하고 있고 결국은 2001년 말에 자회사를 정리하였다. |
|
(1) Iverson의 아들인 Eric Iverson이 현재 Adaytum Software의 CTO(Chief Technical Officer)로 있다.
(2) Executive Information System : 임원정보시스템
(3) Microsoft의 OLEDB for OLAP과 OLAP Council (Oracle 주축)의 MDAPI를 놓고 업계 표준으로 정하기 위해 소위 OLAP API War를 벌였다. 현재, OLEDB for OLAP의 승리로 끝났지만 Oracle은 새로운 OLAPI라는 것을 내세워 독자적인 노선을 고수하고 있다.
(4) 스펙 작성시 50여개 이상의 업체에서 100여명의 설계자 및 아키텍트들이 참여하였고 발표 후 20여개 이상의 주요 공급업체들이 지원을 선언하는 등 현재 강력한 업계 표준 후보로 자리잡고 있다. |
IV. OLAP 제품 분류(top)
일반적으로 OLAP 제품들은 MOLAP, ROLAP, DOLAP, HOLAP로 구분된다.
1. MOLAP(Multidimensional OLAP)
다차원 데이터베이스에 기반한 OLAP 아키텍처로 다차원 데이터의 저장과 프로세싱에 MDBMS가 사용된다. 다차원 데이터의 저장과 프로세싱에 동일한 엔진이 사용되기 때문에 타 아키텍처에 비해 네트워크 상의 데이터 이동이 최소화될 수 있다.
다차원 DMBS
다차원DMBS는 복잡한 비즈니스 로직을 쉽게 반영ㅎ여 모델을 구축하고, 다차원 데이터의 저장과 프로세싱을 효과적으로 수행하며 사용자 질의에 신속하게 응답할 수 있도록 제작되었다. 반면 다차원DB는 관계형DB에 비해 데이터 용량이나 에러 회복 능력, 하드웨어 활용등의 측면에서는 상대적으로 다소 떨어진다.
MDBMS는 다차원 배열(Array)형태의 데이터 구조를 사용하기 때문에 사용자 질의에 대해 빠른 응답성능을 제공하는 장점이 있다.
대표적인 제품 : 하이페리언 솔루션의 에스베이스, 오라클의 익스프레스, 파일롯 소프트웨어의 디시젼 서포트 등
[표] MOLAP 및 ROLAP 제품 비교
|
|
MOLAP 접근법 |
ROLAP 접근법 |
|
특성 |
다차원 모델링 및 질의도구 |
다차원 질의 도구 |
|
데이터 조작 |
읽기/쓰기 |
읽기 중심 |
|
데이터 요구량 |
대용량 |
초대용량 |
|
연산 기능 |
다양한 연산 |
제한된 연산 |
|
개발 주체 |
최종 사용자 주도형 |
전산부서 주도형 |
2. ROLAP(Relational OLAP)(top)
다차원 데이터는 관계형DB에 저장될 수있으며, 이경우 스타스키마가 많이 사용된다. 일단 스키마가 설계된 다음 필요한 테이블들이 물리적으로 생성된다. 질의응답성능을 향상시키기 위해 상세데이터를 가진 테이블과 함께 집계테이블이 만들어질 수 있다. 하지만 전통적인 SQL은 다차원 연산과 질의에 효가적으로 대처하지 못한다. SQL문이 가지는 가장 큰 약점은 비교능력을 결여하고 있다는 점과 순차적 연산을 지원하지 못한다는 점이다. 예를 들어 SQL문으로는 '매출액이 가장 좋은 상위 5개 제품은 무엇인가?' 또는 '매출액이 감소하고 있는 제품은 무엇인가?'와 같은 질문에 답하기 어렵다. 최근 SQL의 한계를 극복하고 보다 쉽고 효과적으로 다차원 질의문을 작성할 수 있도록 MDX(Multi-Dimensional eXpression)라는 다차원 질의언어가 개발되었다.
ROLAP엔진
ROLAP제품들은 사용자와 관계형DMBS사이에 위치하여 사용자를 대신해서 복잡한 SQL을 생성하고 다차원 연산을 수행한다. 메타데이터를 포함해 필요한 모든 데이터를 관계형 데이터베이스에 저장하고 활용하며 다차원 프로세싱을 위해 별도의 OLAP엔진을 가지고 있다. OLAP제품들은 관계형 DMBS와 ROLAP엔진 ROLAP클라이언트로 구성되는 3층구조를 취한다.
ROLAP엔진은 관계형 데이터와 클라이언트 사이의 연결역할을 수행한다. ROLAP엔진은 클라이언트의 다차원 질의를 적절한 SQL로 변환하여 관계형DBMS에 넘겨주고, 관계형DBMS로부터 처리된 결과를 다시 다차원 보고서로 변환하여 클라이언트에 넘겨주는 역할을 수행한다.
ROLAP은 방대한 데이터를 대상으로 다차원분석을 할 수 있지만 대부분의 RDBMS와 SQL언어가 아직은 OLAP에 최적화되지 않았기 때문에 그 응답성능에 많은 제한을 가진다. 따라서 SQL문을 통해 필요한 데이터를 관계형 데이터베이스로부터 추출한 다음 자신의 ROLAP엔진에서 필요한 추가적인 조작을 수행한다.
대표적인 제품 : 인포믹스의 메타큐브, 인포메이션 어드벤티지의 디시전 쉬이트, 마이크로스트래 티지의 DSS에이젼트 등이 있다.
3. DOLAP(Desktop OLAP) (top)
다차원 데이터의 저장 및 프로세싱이 모두 클라이언트에서 이루어진다. 분석에 필요한 데이터는 데이터베이스에서 추출되어 클라이언트에 특수한 화일 형태로 저장되며 제한된 기능의 다차원 분석을 수행한다. 비교적 설치와 관리가 용이하며, 유지보수 부담이 적고 적은 비용으로 OLAP시스템을 구축할 수 있다. 하지만 필요한 데이터가 모두 클라이언트로 이동될 필요가 있으며, 이러한 아키텍쳐 상의 문제로 대용량의 데이터를 처리하는데 한계를 가진다. 또 각각의 사용자들이 자신의 클라이언트에 데이터를 저장하고 유지하기 때문에 이러한 데이터들이 일관성을 갖도록 관리하는 것 역시 커다란 문제가 되기도한다. 최근 많은 DOLAP제품들이 서버용 엔진을 추가하고 있다.
대표적인 제품 : 코그노스의 파워플레이, 브리오 테크놀러지의 브리오쿼리 등이 있다.
4. HOLAP(Hybrid OLAP) (top)
HOLAP제품은 다차원 데이터의 저장 공간으로 다차원 데이터베이스와 관계형 데이터 베이스가 함께 사용될 수 있는 제품이다. 일반적으로 요약된 데이터나 관계식에 의해 새로 계산된 데이터는 "MDB"에 저장되며, 상세데이터는 "RDB"에 저장된다. 질의 과정에서 다차원 데이터베이스에 저장된 데이터보다 더 상세한 데이터가 필요하게 될 경우 자동적으로 RDBMS에 저장된 상세데이터를 가져오게된다. HOLAP솔루션은 빠른 응답성능을 제공하는 MOLAP의 장점과 보다 확장성이 뛰어난 ROLAP의 장점을 결합하여보다 나은 솔루션을 제공하고 있다.
대표적인 제품 : 오라클의 익스프레스, 마이크로소프트의 SQL서버 OLAP 등이다.
OLAP과 관련하여 가장 많은 논란이 되는 것은 MOLAP 제품과 ROLAP제품 사이의 선택이다. ROLAP제품은 일반적으로 MOLAP제품에 비해 복잡한 비즈니스 로직을 반영하기 힘들고 다차원 연산기능이 부족한 반면, MOLAP제품은 ROLAP제품에 비해 대용량의 데이터를 처리하지 못한다.
V. 다차원 모델의 구성 (top)
1. 큐브의 구성요소
1) 모델
하나의 큐브(Cube), 예로 아래그림은 매출분석모델의 큐브이다.
2) 차원(Dimension)
큐브를 구성하는 축(Axis)이다. 매출분석 모델은 변수, 매장, 제품이라는 3개 차원으로 구성된 큐브이다.
3) 차원 항목(Member 혹은 Element)
각 축의 좌표에 해당하는 것이다. 매출분석모델에서 살펴보면 제품 차원은 냉장고, 세탁기 등의 항목으로, 매장 차원은 반포, 잠실 등의 항목이 있다.
4) 셀(Cell)
각 차원을 구성하는 항목들의 조합에 의해 만들어지는 공간을 말하며 데이터가 저장되는 공간이다. 셀은 큐브를 구성하는 차원들의 가진 항목들의 조합수 만큼 존재한다. 모든 셀은 각 차원항목들의 조합에 의해 유일하게 참조될 수 있다. 이러한 항목들을 선택하여 큐브의 어떠한 영역이라도 참조할 수 있다.
5)
계층구조(Hierachy)
다차원 모델을 구성하는 대부분의 차원들은 일반적으로 계층구조를 가진다. 계층구조는 레벨들 간에 혹은 항목들간에 존재할 수 있다. 항목들간의 가장 기본적인 관계는 패어런트(Parent)-챠일드(Child)관계이다.
패어런트는 계층구조에서 어떤 항목의 바로 상위항목을 나타내며,
챠일드는 바로 하위항목에 해당한다. 예로 기간차원에서 '1/4분기' 항목의 챠일드는 '1월, 2월, 3월"이다. '7월'의 패어런트는 '3/4분기'이다. 한편 어떤 항목의
씨블링(Sibling)은 그 항목과 동일한 패어런트를 가진 항목을 말한다.'1월'의 씨블링은 '1월, 2월, 3월'이다.
패어런트를 갖지 않는
루트(Root)항목이라 한다. '년계' 항목은 기간차원의 루트항목에 해당한다. 반면 챠일드를 갖지 않는 항목을
리프(Leaf)항목이라 하며, 기간차원의 경우 '1월, 2월, 3월'등을 포함하여 12개의 리프항목이다. 리프항목을 상세(Detail)항목이라 부르기도 한다.
어떤 항목의
앤세스터(Ancestor)는 계층구조상의 루트항목까지 연결되는 가지(Branch)에서 그 항목의 상위에 나타나는 모든 항목을 말한다. 예를 들어 '1월'항목의 앤세스터는 '1/4분기, 상반기, 년계항목'이며, '3/4분기'항목의 앤세스터는 '하반기'와 '년계'항목이다. 반대로 어떤 항목의
디센던트(Descendent)는 계층구조상의 리프항목까지 연결되는 가지에서 그 항목의 하위에 나타나는 모든 항목을 말한다. '년계'항목의 디센던트는 '년계'를 제외한 모든 하위항목을 말한다.
6)
레벨
계층구조는 레벨(Level) 사이에 존재 할 수 있는데, 예를 들어 기간 차원의 경우 '일-월-분기-반기-년'과 같은 다단계(레벨) 계층구조가 존재할 수 있다. 계층구조에서 거리를 나타내는 개념과 차원항목들의 부분집합을 나타내는 개념으로 나눠볼 수 있다. 일부 OLAP제품들은 계층구조상의 거리나 위치를 나타내는 개념으로 레벨을 사용한다.
레벨은 리프항목에서 시작하여 루트항목 방향으로 항목이 속하는 계층의 위치를 계산한다. 두 항목이 임의의 가지에 대해 디센던트의 최대치가 동일할 경우 동일한 레벨에 속한다고 한다.
제네레이션(Generation)은 루트항목에서 시작하여 리프항목 방향으로 항목이 속하는 계층의 위치를 계산한다. 계층구조상의 두 항목의 동일한 수의 앤세스터를 가질 경우 동일한 제네레이션에 속한다고 말한다.
7)
애트리뷰트
하나의 차원에 대해 차원을 구성하는 항목들의 특성을 나타내는 이러한 정보를 애트리뷰트(Arribute)혹은 프라퍼티(Property)라고 한다. 예를 들어 매장차원을 구성하는 리프항목들의 특성을 나타내기 위해 매장의 주소, 전화번호, 담당자, 매장크기, 직영여부, 개점일 등과 같은 애트리뷰트가 사용될 수 있다.
2. 스타스키마(Star Schema) (top)
스타스키마는 정보를 사실(Fact)과 차원(Dimension)으로 분류한다. '사실'은 실제 데이터요소로 분석을 요하는 변수차원의 항목들로 구성된 정규화된 테이블을 말한다. 차원은 '사실'을 보는 관점을 나타내며 각각의 차원은 별도의 차원테이블에 표현되며 비정규화된 테이블로 존재한다.
1)
사실테이블
사실테이블은 스타스키마상에서
유일하게 정규화된 테이블로 스타스키마의 중심에 위치하며 스타스키마 설계시 가장 큰 테이블이다. 대규모 소매업이나 통신산업의 다차원 모델인 경우 수억 개의 행을 가질 수 있다. 위의 그림에서 사실테이블은 매장키, 제품키, 기간키, 매출액, 매출수량을
열(Column)로 가지고 있다. 매장키,제품키, 기간키는 각 차원 테이블과 연결되는
외래키(Foreign Key)이다. 이처럼 사실테이블은 일군의 외래키 열과 상세 데이터 값을 가지는 열로 구성되며, 외래키들은 차원테이블과의 조인에 사용된다.
사실테이블에 저장되는 대부분의 사실은 수치데이터이며, 각 차원들의 다양한 애트리뷰트에 따라 집계될 수 있다. 즉 월별 매출액은 분기별 매출액으로 합산될 수 있으며, 각 분기별 매출액은 년간 매출액으로 합산될수 있다. 이처럼 대부분의 경우 집계작업은 합산을 의미한다. 마찬가지로 제품차원이나 매장차원에 대해서도 집계될 수 있다. 반포매장의 매출액과 짐실 매장의 매출액이 집계되어 강남권의 매출액을 계산해 낼 수 있다. 이러한 사실을
'합산 가능한 사실(Addive facts)'이라 한다.
한편 일부 차원에 대해서만 값이 집계될 수 있는 사실도 있다. 예를 들어 특정시점에서 반포매장과 잠실매장에 대해 냉장고 재고량이 각각 10대, 20대이고 세탁기의 재고량이 각각 20대, 30대라고 하자. 이경우 전체매장의 냉장고 재고량과 세탁기 재고량은 각각 30대와 50대로 집계할 수 있다. 즉 매장차원에 대해서는 각 제품의 재고량을 전체 매장에 대해 집계 할 수 있다. 하지만 제품차원에 대해서는 재고량을 집계하는 것이 현실적으로 아무런 의미를 갖지 못한다. 반포 매장에 대해 '냉장고 재고량 10'과 '세탁기 재고량 20'을 더해 제품 전체 제고량 30이라는 값을 계산해 낼 수는 있지만 이 값은 아무런 의미가 없다. 이처럼 '재고량'은 매장차원에 대해서는 집계할 수 있지만 제품차원에 대해서는 집계할 수 없다. 즉 제품차원에 대해 집계된 값은 사용자에게 아무런 의미를 갖지 못한다. 이와 같은 사실을
'일부차원에 대해서만 합산 가능한 사실(Semiadditive facts)'이라고 한다.
사실 중에는 집계될 수 없는 사실도 있는데, 예를 들어 각 제품별 판매가격과 같은 사실은 어떤 차원에 대해서도 집계되지 않을 것이다. 이와 같은 사실을
'합산이 되지 않는 사실(Non-additive facts)'이라고 한다.
2)
차원테이블
차원테이블은 사실에 대한 사용자관점을 나타내며 차원에 관한
서술적(Descriptive)정보를 저장하며 비정규화된(Denormalized) 데이터구조를 취한다. 차원테이블은 필요한 정보가 모두 하나의 테이블에 저장되어 있기때문에 질의응답 성능을 떨어뜨리는 조인의 횟수를 최소한으로 줄일 수 있다. 이러한 이유는 OLAP시스템은 데이터의 효율적인 갱신이나 저장보다는 효과적인 활용을위해 구축되어지는 시스템이기 때문이다. 따라서 OLAP시스템을 OLAP시스템의 경우처럼 저장공간을 절약하기 위한 형태로 설계하는 것은 바람직하지 않다.
매장차원에 관한 정보를 가진 차원테이블을 나타내고 있다. 매장 테이블은 매장의 권역별 분류, 시도별 분류, 담당자, 유형, 개점일, 면적과 같은 매장차원의 다양한 특성을 나타내는 정보들을 가지고 있다. 이러한 정보들은 테이블 상에 열로 나타나고 있으며 이를 애트리뷰트라 한다. 차원 테이블의 내용은 전적으로 사용자 관점에서 설계되어지며, 따라서 각 애트리뷰트는 사용자에게 의미가 있고 실제로 사용자가 질의를 통해 볼 수 있는 형태의 값을 가진다. 차원테이블은 사용자들이 분석을 시작하는 일차적인 장소이며 사용자의 다양한 분석 니즈를 지원하도록 설계한다.
3. 스노우플레이크 스키마 (top)
스노우 플레이크(Snowflake)스키마는 스타스키마의 사실테이블 구조와 동일하게 유지하면서
차원테이블이 정규화(일반적으로 제3정규형)된 구조를 말한다. 스탈스키마에는 사실테이블과 직접 조인되는 차원테이블이 있으며, 이 차원테이블은 또 다른 차원 테이블 상의 기본키를 참조하는 외래키를 가진다. 이렇게 참조되는 테이블을 아웃트리커(Outtrigger) 테이블 혹은 아웃보드(Outboard)테이블이라한다.
하지만 실제 현업에서는 최상의 성능을 내기 위해서는 두가지 형태가 어느 정도 혼재된 상태로 사용되는 것이 일반적이다. 데이터의 무결성(Integrity)을 유지하고 데이터의 중복성을 줄이기 위한 정규화와 성능향상을 위한 비정규화가 일정한 수준에서 조합된 형태를 취한다. 설계자는 사용자 질의 유형과 질의 응답성능을 고려하여 적절한 수준에서 테이블을 비정규화할 필요가 있다.
4. 변수차원의 이해 (top)
논리적인 측면에서 변수차원은 모든 다차원 모델에 존재한다. 변수차원은 OLAP제품들에 따라 변수(Variables), 사실(Facts), 측정치(Measures), 계정(Accounts), 아이템(Items)등과 같은 다양한 이름으로 불리워진다. 다차원 모델의 구축은 바로 이러한 변수 차원의 항목을 정의하는 데서부터 시작한다.
변수차원은 다음과 같은 의미를 갖는다.
1)
변수차원은 다른 차원들의 존재기반을 제공해 준다.
변수차원은 비즈니스 상에서 우리가 측정하고자 하는 항목(매출분석모델의 경우 매출액과 매출수량이 변수차원)들로 구성된 차원이며, 나머지 차원들은 이러한 항목들을 사용자들이 분석하기 위한 하나의 관점을 나타낸다고 할 수 있다.
2)
변수차원은 나머지 차원들의 상세정도(Granularity)를 결정한다.
예를 들어 매출분석모델의 경우 일반적으로 일별 혹은 주별 항목으로 기간차원이 구성되는데 비해, 대부분의 재무모델에서 기간차원은 월별항목만으로도 충분할 것이다. 물론 실제 다차원 모델의 구축에는 데이터의 가용성이나 시스템 용량 등과 같은 다양한 요소들이 추가적으로 고려되기도 한다.
변수가 없는 다차원 모델은 존해하지 않는다. 때론 변수(혹은 '사실')이 물리적으로 표현되어지지않을 수도 있으나, 논리적인 의미에서 변수가 없다는 의미는 아니다. 예로 출석모델에서 사실테이블에는 '교과목 차원 키, 학생 차원 키, 일자/시간 차원 키, 교수차원의 키, 강의실 차원 키'가 존재 할뿐 실실적인 사실은없다. 하지만 이러한 외래키만으로도 특정 학생의 출석여부를 확인 할 수 있다.
5. 하이퍼큐브와 멀티큐브 (top)
다차원 데이터구조를 논리적으로 표현하는 방식은 크게 하이퍼큐브방식과 멀티큐브방식의 두가지 접근법으로 나눠볼 수 있다. 반면 이다.
1) 하이퍼큐브(Hypercube)
분석 모델에서 비용을 함께 분석한다고 생각해보자.
비용은 표준제조비용과 표준운송비용으로 구성되며 다음과 같은 관계식을 이용해 구해진다.
비용 = 매출 수량 X (표준제조비용 + 표준운송비용)
이때 매출액, 매출수량, 비용은 기간별, 제품별, 매장별로 데이터를 갖지만, 표준제조비용은 기간별, 제품별로만 데이터가 존재하고, 표준운송비용은 기간별, 매장별로만 데이터가 존재한다고 하자. 즉 표준제조비용에 대해서는 매장차원이 의미가 없으며, 표준운송비용에 대해서는 제품차원이 관련되지 않는다.
하이퍼 큐브 접근법은 하나의 모델을 하나의 큐브로 표현한다. 각각의 차원들을 구성하는 모든 항목들의 조합 수만큼 셀이 존재하게 된다. 즉 큐브를 구성하는 모든 변수가 동일한 차원을 공유하며, 큐브를 구성하는 모든 셀 역시 동일한 차원들을 가진다. 하이퍼 큐브 방식은 모델구축이 용이한 반면 큐브 내에 "의미 없는셀"이 존재할 수 있다는 단점을 가진다.
2) 블럭멀티큐브(Multicube)
멀티큐브 접근법은 하나의 모델을 여러 개의 큐브로 표현하는 방식이다. 멀티큐브 방식은 다시 블럭(Block) 멀티큐브방식 과 시리즈(Series)멀티 큐브 방식으로 구분해 볼 수 있다.
블럭(Block) 멀티큐브
앞의 매출분석 모델에는 매출액, 매출수량, 표준제조비용, 표준운송비용, 비용이라는 다섯 개의 변수항목이 존재했다.
이중에서 매출액, 매출수량, 비용 항목에 대해서는 기간, 제품 매장 3개의 차원이 모두 의미가 있지만, 표준제조비용의 경우 기간과 제품차원만이 의미가 있으며 표준운송비용의 경우 기간과 매장차원만이 의미가 있다.
블럭 멀티큐브방식은 동일한 차원을 공유하는 변수항목들의 집합에 대해 각각 차원을 설정해 준다. 블럭 멀티큐브 방식의 경우 의미 없는 셀이 생성되지 않기 때문에 보다 효율적으로 큐브를 유지할 수 있다. 반면 모델의 구축시 하이퍼큐브에 비해 보다 세심한 주의를 필요로 한다.
시리즈(Series)멀티 큐브 방식
모든 변수항목들을 별개의 큐브로 다룬다. 데이터는 변수에 저장되는 것으로 표현되며 각각의 변수는 데이터베이스에 정의된 차원들 중에서 필요한 차원들만을 취할 수 있다.변수(Variable)는 나머지 차원들과 분리되어 표현되고 있으며 각 변수는 생성과 함께 필요한 차원이 설정된다.
한편 하이퍼큐브 방식과 멀티큐브 방식은 전적으로 논리적인 의미에서 구분되는 것이며, 한 제품이 논리적으로는 하이퍼큐브 방식을 취하더라도 실제 물리적인 데이터 저장의 관점에서는 멀티큐브 방식을 취하는 경우도 있다.
VI. 다차원 모델링 (top)
1. 변수차원 구성항목 결정
설정된 주제영역에 대해 실제 사용자가 분석하고자 하는 항목들을 정의하는 단계이다.
2. 구분차원(Identifier Dimension)의 결정
변수차원을 구성하는 항목들을 어떤 관점에서 분석할 것인지 결정하는 간계로 이러한 관점은 모델의 나머지 차원을 구성한다. 이러한 차원들은 변수차원 항모들을 분석하는 하나의 관점을 나타내며 변수차원과 구분하기 위해 구분차원(Identifier Dimension)이라 불리기도 한다.
변수차원은 모델을 구성하는 다른 어떤 차원들보다 먼저 설정되며 나머지 차원들에 대한 존재기반을 제공한다. 즉 변수차원에 포함되어 있는 항목들의 성격에 따라 나머지 차원들이 정해진다. 모든 차원은 일차적으로 사용자의 분석목적에 적합하게 사용자의 관점에서 설정된다.
3. 데이터의 구체성 결정
데이터의 상세수준을 정하는 단계이다. 이처럼 데이터의 구체성정도를 결정하는 작업은 변수차원을 제외한 나머지 차원에 대해, 차원을 구성하는 항목들의 상세수준을 결정하는 작업이라 할 수 있다. 데이터의 구체성 정도는 OLAP시스템 구축에 있어 매우 중요한 문제로 시스템의 데이터 양과 응답될 수 있는 사용자 질의 유형에 절대적인 영향을 마친다.
4. 계층구조와 애트리뷰트 정의
각 차원에 대해 분석에 필요한 계층구조와 애트리뷰트를 설정하는 단계다.
5. 관계식 정의
항목들 간에 필요한 관계식을 설정한다. 관계식은 대부분 변수차원을 구성하는 항목들에 대해 정의한다.
6. 차원수의 결정
모델이 많은 차원을 가질수록 좋을 것 같지만 실제로 차원이 증가함에 따라 큐브의 희박성은 급격하게 커지며, 이에 따라 사용자가 다차원 질의를 수행하는데 예기치 못한 어려움을 가질 수도 있다. 또한 모델의 특성 이외에도 OLAP시스템의 저장공간과 성능에 큰 영향을 미치기 때문에 시스템적인 문제가 함께 고려되어야 한다. 따라서 차원 수는 분석요구와 시스템 용량 사이에 균형을 맞추어 결정되어야 한다.
VII.다차원 질의(다차원 분석) (top)
1.Slicing & Dicing
다차원 질의이 기본은 사용자가 큐브의 어떤 부분을 볼 것인지 정의하는 것이다. 다차원 질의는 마치 사용자가 큐브의 일부분을 자신의 원하는 형태로 절단하여 살펴보는 것에 비유할 수 있다. 이러한 이유로 다차원 질의를 슬라이싱과 다이싱(Slicing & Dicing)이라고 부른다.
변수(매출, 매출원가), 제품, 기간의 3차원으로 구성된 큐브를 제품 축을 기준으로 슬라이싱과 다이싱하였다고 생각해보자. 큐브를 구성하는 차원 중 변수차원은 보고서의 행을, 기간차원은 보고서의 열을 이루고 있으며 제품차원은 보고서의 데이터를 결정하고 있다. 이처럼 다차원 데이터를 2차원 보고서로 표현하기 위해서는 열, 행, 페이지의 3가지 차원개념이 필요하다. 기간차원이 보고서의 열 차원을, 변수차원이 행 차원을, 제품차원이 페이지 차원을 구성하고 있다. 열 차원과 행 차원은 보고서의 축을 구성하며, 따라서 열차원과 행 차원을 축차원으로 부르기도 한다.
보고서의 데이터는 페이지차원에 의해 결정되며, 따라서 페이지 차원을 필터(Filter)차원이라고 한다.
2. Drill-Down, Drill-up, Drill-Across, Drill-Through (top)
1)
드릴다운(Drill-Down), 드릴업(Drill-up)
드릴다운은 요약된 형태의 데이터 수준에서 보다 구체적인 내용의 상세데이터로 단계적으로 접근하는 분석기법을 말한다. 예로 2000년 지역별 매출데이터를 보다가 보다 상세한 2000년 상반기 지역별 매출데이터로 드릴다운 할 수 있다.
드릴업은 드릴다운과 반대의 방향으로 사용자가 정보를 분석하는 것을 말한다.
일반적으로 드릴다운과 드릴업의 경로는 모델의 계층구조를 따른다. 또한 사용자는 모델이 가진 다양한 애트리뷰트에 의해서도 드릴다운이나 드릴업을 할 수 있다.예를 들어 '색상'이라는 애트리뷰트를 가질 때, 전체제품의 매출액 데이터를 보다가 각 색상별 매출액 데이터로 드릴다운 할 수 있다. 즉 드릴 다운은 "좀 더 자세한 데이터를 보여 달라"라는 의미를 가진다.
2)
드릴어크로스(Drill-Across), 드릴쓰루(Drill-Through)
드릴어크로스는 다른 큐브의 데이터에 접근하는 것을 말한다. 예를 들어 사용자가 '매출액 모델'을 분석하는 과정에서 '반포'매장에서 '냉장고'의 매출액이 급격히 증가하고 있음을 발견했다면, 사용자는 '재고모델'로 드릴어크로스하여 각 매장별로 냉장고의 재고량을 파악하고 매장간 재고량을 조정할 수 있을 것이다.
드릴쓰루는 OLAP시스템으로부터 데이터 웨어하우스, 혹은 OLAP시스템에 존재하는 상세데이터에 접근하는 것을 말한다. OLAP시스템에 존재하지 않는 데이터가 추가적으로 필요한 경우 자동적으로 데이터 웨어하우스나 OLTP상의 데이터에 접근할 수 있는 통로를 제공한다. 이러한 드릴쓰루가 가능하기 위해서는 OLAP시스템에 있는 데이터와 웨어하우스에 있는 데이터 사이의 논리적인 관계가 메타데이터로 정의되고 관리될 필요가 있다. 드릴쓰루는 리치쓰루(Reach Through)라 불리기도 한다.
3. Sorting, Ranking (top)
소팅과 랭킹이 다차원 데이터에 사용될 경우 보다 세심한 주의가 필요하다. 다차원 질의 결과로 얻는 보고서에는 다수의 차원이 중첩되거나 계층구조의 여러 레벨에 속하는 항목들이 함께 나타나는 경우가 일반적이다. 이경우 사용자는 단순히 특정 행이나 열을 기준으로 소팅이나 랭킹을 수행하기 보다는 중첩된 차원이나 계층구조를 인식하여 소팅이나 랭킹이 이루어지길 원할 수 있다. 다차원 질의에서 차원의 중첩이 이루어진 경우 차원의 중첩을 인식하여 소팅이 수행되면 훨씬 효과적인 분석이 이루어질 수 있다.
4. OLAP조인 (top)
질의과정에서 다수의 큐브를 논리적으로 조인할 필요가 있는데 이를 OLAP조인이라 한다. 일반적으로 OLAP조인은 큐브들 사이에 공유된 차원을 중심으로 이루어진다.
예로, 매출큐브는 매출액과 매출 수량을 분석하기 위한 모델로 기간, 제품, 매장차원으로 구성된다. 한편 재고큐브는 재고량을 분석하기 위한 모델로 기간, 제품, 물류창고 차원으로 구성된다. 다차원 질의 결과는 매출액, 매출수량, 재고량을 동시에 필요로 한다. 즉 OLAP 조인이 발생하는데 매출액, 매출수량은 매출큐브에서, 재고량은 재고큐브에서 가져와야 한다.
자료출처 :
OLAP 테크놀로지
저자 : 조재희(광운대학교 경영정보학과 교수), 박성진(엠프레인 CRM사업부 책임컨설턴트) 저
출판사 : 시그마인 사이트컴
- 출처 :
http://innobizard.com.ne.kr/main/it/olap/olap.html -
