컴퓨토피아

출처: http://www.gunkr.com

[DW]BI를 위한 DW !!
 
이번 홈페이지 개편 작업을 계기로 OLAP강좌를 진행하려고 합니다.

어떤 하나의 툴에대한 설명이나 세부운영방법 보다는 개념적인 강좌를 하려고 합니다.

다른 모든 것도 그렇지만 특히나 DW분야는 더욱 개념이 중요하다고 할 수 있습니다.

개념만 잡히면 어떤 툴이던지 적용하는데는 그리 어려운 일이 아니니까요..

우선 저의 간단한 소개와 OLAP강좌를 하게된 경위를 말씀드리겠습니다.

전 건이라고 합니다. (물론 본명아뉩니다. ㅠㅠ)

S전자에서 EIS 구축을 시작으로 DW에 대해 접하게 되었고 요즘 주 관심사가 되어버렸습니다.

해서 함께 나누려고 이런 공간을 마련하게 되었습니다.

서두가 너무 길었줘.. ^^

자 그럼 첫번째 강좌를 시작해 볼까요~ !!

비즈니스 인텔리젼스(Business Intelligence)..

일반 법인의 정보화의 목적은 BI에 있습니다.

데이터를 정보화 시키고 이를 이용해서 경영에 도움을 주기 위한 모든 시스템들이

궁극적으로 BI의 실현에 있는 것입니다. 그럼 어떻게 BI를 향한 접근을 할 수 있을까요..

사람들은 이를 실현하기 위해 DATA를 정보화 시키고 이를 축척하기 시작했줘,.

그리고 이제 그 데이터는 방대해지고.. DW라는 넘이 생겨나게 되었습니다.

그럼 DW는 무었이냐?

DW는 데이터 웨어하우스.. 음.냥..

쉽게 말하면 데이터의 집합체입니다.

DATA -> 정보화 -> DB -> 추출 -> DW

더미 데이터들을 모아 DB를 구축하게 됩니다. 

DW는 이렇게 구축된 DB의 데이터들이 해가 지나면서 쌓이게 되겠줘...

그러면 이렇게 모인 DATA에서 공통 차원을 추출해서

분석을 할 수 있게 하는 기초 공간이라고 생각하면 됩니다.

그리고 OLAP은 DW를 이용해서 유용한 DATA를 유연하게 신속하게 분석을 하는 작업을 말하게 되는거지요..

개념이 낮설죠.. 오늘은 이정도만 하죠.. 차차 자세하고 쉽게 설명해드리겠숨더.!! 

[DW]OLAP 과 OLTP
 
이번 강좌 부터는 존대를 하지 않겠습니다.

강좌는 원래 좀 딱딱해야하는법..!!

오늘은 OLAP에 대해서 알아보겠다.

왠 OLAP? DW에서 사용되는 모든 프로세싱은 OLAP이기 때문이다.

IT를 하는 사람이라면 DB를 사용 할 것이고, 그 대부분의 사람들이 OLTP에 대해서는 익히 잘 알고 있으리라고 생각된다.

하지만 노파심에서 설명드리자면..

OLTP는 "online transaction processing"의 약자로 Data의 입력,출력,조회,삭제 등을 위한 트랜젝션 처리를 기반으로 하는 모든 DATA작업을 말한다.

실 생활을 빌어 얘기하자면,, 은행에서 돈을 찾을때 돈이 찾아지기 까지의 DATA 처리 과정들이나,

인터넷을 사용할때 회원 가입 및 전자상거래 처리,

지하철 페스를 찍고 빠져나가는 과정 등 실생활에서 이루어지는 DATA관련된 모든 처리는 OLTP라고 생각하면 된다.

그럼 OLAP은 무엇인가?

OLAP란 "online analytical processing"의 약자로 Data를 여러관점에서 분석 하여 정보화하는 작업을 말한다.

위에서 설명한 OLTP와는 T와 A차이지만 실상 이는 비교의 대상은 아니다.

단지 이해를 돕기 위한 수단으로 비교를 할 뿐..

어쨌든.. OLAP은 분석을 위한 DATA작업을 말한다.

예를 들자면 피벗테이블같이 엑셀에서 데이터들을 여러 관점에서 분석이나 추출하는 과정이 이에 해당된다.

  즉 OLAP는 OLTP로 의해 만들어진 DATA들을 효과적으로 활용하기 위하여 몇가지 관점을 정해 놓고 그 관점을 기준으로 분석을 하는것을 이야기 하는것이다.

때문에 OLAP는 OLTP와 다르게 Online작업이 없다.

물론 ROLAP라는 놈이 있긴하지만 개념적으로는 이것도 온라인이 아니다.
(ROLAP에 대해서는 나중에 다시 설명하겠다.)

오늘은이만..

 
[DW] 구성요소
 
그럼 DW를 구성하고 OLAP를 하기 위한 구성요소는 무었이 있을까?

첫째 분석할 데이터가 있어야한다.

둘째 OLAP를 운영할 엔진이 필요하다.

셋째 분석용 데이터 마트가 필요하다. - (큐브(CUBE)와 차원(Dimension)으로 이루어진 객체)

  첫째는 다 알테고,,

  둘째의 엔진은 OLAP을 처리할 소프트웨어 즉 Hyperion사나 MS사, ORACLE사, MIS사 등의 OLAP용 툴을 지칭하는것이고.,

  셋째는 데이터 마트의 구성이다.

우리가 첫시간에도 말한바와 같이 DW는 일반기업체의 BI를 목적으로 만들어진다.

즉 과거를 분석하고, 측정하여, 앞으로 어떻게 될지를 예측할 수 있고, 이를 대비할 수 있는 것이다.

그러면 여기서 '어떤 것'을 분석하고, 측정하고 하는 대상을 정해야하고 이를 최대한 효과적으로

분석할 수 있는 모델이 필요하지 않을까? 그의 실체가 데이터 마트인 것이다.

데이터 마트는 우리가 마이닝을 하는 직접적인 대상이 된다.

그럼 데이터 마트는 데이터 웨어하우스의 하나의 작은 구성요소인가?

답은 아니다!!- 에구 어렵다 이걸 어떻게 설명해야하는가?

데이터 마트는 실제 분석을 위해 집약적으로 설계되고 만들어지는 DATA 모델인 것이다.

DW는 방대한 DATA를 과거에서 부터 모아서 이루어진 DATA의 집합체이지만..

요즘 개념은 많이 발전하여 이를 이용한 응용 프로그램 및 활용 마이닝 기법까기 포함하는

소프트웨어 공학용 개념으로도 사용되는 것 처럼 데이터 마트의 개념도 많이 바뀌게 되었다.
(이하 요점이 많이 빚나가서 생략합니다.)

어쨌든.. 효과적인 데이터 마이닝을 할 수 있게 설계하고 분석하여 만들어낸 실체가

큐브와 디멘전으로 이루어진 데이터 마트인 것이다.

다음 시간에는 큐브와 디멘전에 대해 설명하겠다.
 
   

[DW] Cube와 Dimension
 
데이터 마트는 큐브와 차원으로 이루어져있다.

차원? 많이 들어보았던 단어다.. 1차원 점,2차원 선, 3차원 면, 4차원 시공간..

빽투더 퓨쳐에서 4차원을 넘나드는 환상을 경험해봤으리고 생각된다..
(이 세대가 아니라면 둘리에서 바이올린을 타고 날아가서 둘리의 어머니를 찾는 장면을 생각해보라..)

OLAP은  DATA를 어떤 속성들에 의해 분석이 이루어 진다고 했다.

여기서 "어떤 속성"이란넘들이 바로 차원(Dimension)이 되는 것이다.

DATA들 중에 반복적이고 규칙적인 속성를 찾아서 이를 차원이라고 규정하는것이다.

각 차원은 멤버로 구성이 된다.

잘 이해가 안되리라... 예를 들겠다.

지난 월드컵을 생각하며 축구의 스코어에 대해서 생각해보자..

예를 들어 아래와 같은 데이터가 있다고 하자.
-------------아 래-----------------
년도  상대팀    골득   골실
-----------------------------------
1999  이태리          5      1
1999  브라질        10      5
1999  미 국         100     0
2000  이태리          5      1
2000  일 본         100     1
------------------------------------
위 표에서 나온 데이터를 예로 설명하자면
차원은 년도, 상대팀이 되는 것이다.

년도는 한정되며 반복적인 시간의 흐름이며,

상대팀 또한 전세계의 한계가 있는 반복적인 멤버들만 존재한다.
(멤버란? 차원의 원소 예.. 이태리, 미국,일본 하나하나)

때문에 이들을 차원으로 뽑아 낼 수 있는 것이다.

에거 힘들다. 그럼 이제 큐브!!

큐브는 디멘젼과 측정값로 이루어져 있다.

큐브란 넘을 사전적 의미로 찾아보면.. 정육면체이다. (영화 큐브를 상상하면 딱이겠군..)

여기서는 딱히 정육면을 얘기하는것이 아니라 무수히 많은 차원들로 이루어진 형태의 데이터의 집합체를 말한다.

즉 위에서 설명한 차원들이 하나하나 큐브의 면이 되는 셈이고, 그 디멘젼의 교차점이 가지는 값이 측정값이 되는것이다 .(측정값은 위의 예에서 골득과 골실이 됨)

꼭 찝어서 비교하지는 못하더라도 OLTP의 Table과 약간은 비슷하다고 생각하면 될것이다.

그럼 어느정도는 이해 했으리라고 생각되고 다음시간에는 큐브의 종류에 대해서 알아보겠다. 

    
 
[DW] OLAP의 스키마 I
 
정말 오랜만에 글을남긴다...

지금은 휴식 기간이라서.. ㅋㅋ

어쨌든..오늘은 OLAP에서 사용하는 스키마(schema)의 종류를 설명하겠다.

스키마라? 스키마라함은 어떤 객체의 근원이되는 구조를 말한다.??

물론 여기에서는 큐브에 대한 스키마를 말하려한다.

저번 강좌에서는 큐브가 차원과 값으로 이루어졌다고 설명했었다.

이차원이 어떤 식으로 구성되는냐에 따라서 스키마의 종류가 분리된다.

DW에서 사용하는 스키마의 종류는 3가지가 있다.

첫째는 가장 그형태가 쉽고 많이 쓰이는 별형(스타:star) 스키마.
둘째는 스타 스키마의 확장형인 눈송이 형(스노우플레이크:snowflake) 스키마.
셋째는 부모와자식형 (페어런트엔차일드:parent&child) 스키마.

우선 스타 스키마에 대해서 알아보자

저번강의에서 설명된 기본 큐브가 스타 스키마에 해당된다.
다시한번 보자

-------------아 래-----------------
년도  국가    경기장소  골득   골실
-----------------------------------
1999  이태리     서울          5      1
1999  브라질     브라질리아10      5
1999  미 국       LA          100     0
2000  이태리     로마          5      1
2000  일 본       도쿄        100     1
------------------------------------
이런 종류의 데이터를 분석하기 위한 스키마가 바로 스타스키마이다.

아래 그림을 보자.

                                      년도
                                         |
                                      골득- 경기장소
                                     /    
                                 국가

그림을 봐도 왜 *스타 스키마인지 이해가 갈거라고 생각된다..(별모양의 꼭지가 반듯이 5~6개가 있어야한다는 편견을 버려!! . 보통 2,3개의 차원이 더 있으면 비슷할것임!! ㅠㅠ)

가운데 골득은 측정값(measure)가 되며 그 주위에 차원들이 둘러싸여 있다.

이것이 하나의 스타스키마형 큐브가 되는것이다.

다음은 스노우 플레이크 스키마를 설명하겠다.

다음 장에서..

[DW] OLAP의 스키마 II
 
이제 OLAP의 스키마 II 인 스노우 플레이크에 대해서 설명하겠다.

스노우 플레이란 눈송이란 뜻이다. 물론 큐브가 구성된 모양이 비슷하게 생겼기 때문에 붙여진 이름이다.

스노우 플레이크 스키마는 앞 강좌에서 설명한 스타 스키마의 확장이라고 생각 하면 무난할 것이다.

아래 예를 보겠다.

                                       년도
                                         |
                                      매출- 지점-지역-국가
                                       /
                                    제품-제품그룹

위 도식화된 그림중에 매출이 측정값이 되며 나머지는 차원이 된다.

스노우 플레이크가 스타 스키마와 구별되는 것은 매출(측정값)을 기준으로

직접적으로 연관된 차원들을 제외한, 나머지 차원들이다.

지점 차원에 붙은 지역,국가 차원이라가 제품에 붙은 제품그룹차원 등 차원들간에 가지를 친다는 것이다.

현재는 몇 안되는 차원이지만 무수히 많은 차원들의 연관관계가 있는 큐브를 구성한다고 생각해 보라!!

  마치 눈송이 결정체를 보는 것 같은 구조가 아닌가?

스노우 플레이크의 구조는 좀 복잡하다.

하지만 실질적으로 스노우 플레이크 스키마를 이용하여 설계하는 경우는 매우 드믄 실정이다.

거의 대부분이 스타 스키마로 구현이 가능하기 때문이다.

그런데 왜 스노우 플레이크 스키마를 쓸까? 그건 확장성 때문이다.

스노우 플레이크로 설계를 하면 기존의 팩트테이블의 수정 없이 확장이 용이하기 때문이다.

하지만 속도나 운용상의 어려움이 많기 때문에 스노우플레이크의 설계는 그 구성이 커질수록 사용을 금하고 있다.

또한 스타스키마를 응용하면 마치 스노우 플레이크처럼 표현이 가능하다.

이부분은 나중에 연재를 마치고 실전을 강의 할때 다시 설명하기로 하겠다.

스노우 플레이크의 설명은 여기까지..
 
   

[DW] OLAP의 스키마 III
 
정말 오랜만에 글을 올린다.

2개월만인가? 그렇다고 너무 불평하지 말길...

오늘은 Parent & Child 구조에 대해서 알아보겠다.

부모 자식관계의 구조?라.. 음.. 설명하기가 좀 어렵겠군..

보통 기업에서 부모자식 구조를 사용하는곳은 계정 관리가 요하는 곳이다.

예를 들어 원가 계정이라는 것이 있고 이는 원자재+기타 부외 비용이라고 하고,

월 손익이라는 계정에는 매출 + (-) 원가가 포함되어 있다고 하자.

원가=원자재+기타부외비용
손익=매출+(-)원가

위에 있는 모든 계정(원가,원자재,기타부외비용,손익,매출)들은 모두 계정이라는 속성이 있으면서도 서로 부모자식과도 같이 레벨이 존재한다.

  손익
    ↓ ↘
  매출 원가
   :      ↓ ↘
   : 원자재  기타부외비용
   :       :          :

위와 같이 root가 있고 leaf가 있는 형태의 tree형태가 된다. 물론 이를 보모 자식이라고 칭한다.

좀더 데이터 구조적으로 접근해보자.

Account No | Name   | Parent | Operator
=======================================
0001            |  손익    |           |  
0101            |  매출    | 0001    |  +
0201            |  원가    | 0001    |  -
0202            |  원자재 | 0201    |  +
0203            |  기타    | 0201    |  +

이제 좀 감이 잡히는가?

이런 차원이 있는 구조를 Parent&Child 구조라 부른다..

이번 강좌를 마지막으로 OLAP의 스키마에 대해 알아보았다.

이제는 이론 강좌를 떠나서 직접 만들어보는 임플강의를 진행하겠다.

다음 강좌가 언제가 될지는 모르지만.. ^^ 그때까지 안녕히..