DATOR


Data Mart 분석 및 설계 방법1 BI


Mart 모델을 설계하기 위해서는 분석할 대상을 명확히 해야 한다.

 

앞서 분석할 대상을 명확히  할 수 있는 방법에 대해 알아봤다.

 

물론 현업이 쓰고 있는 보고서에 집중했지만 그것이 가장 중요하다고 할 수 있다.

 

그럼 그 대상이 무엇인지 다시 한번 알아보면..

 

1. 현업이 사용하는 보고서 항목

2. 운영계 레포트 출력화면 항목

3. 정보계(BI) 화면 항목

3. 출력화면 SQL

4. 운영계 ERD

5. 정보계 ERD

6. ETL SQL....

 

참 다양한 대상들이 있다. 여기서 한가지 짚고 넘어갈 것은 DW, DM 모델 설계나 BI 구축 프로젝트나 각각의 프로젝트마다

 

특성이 다르고 분석해야할 대상도 다르므로 진행 방법도 다를 수 밖에 없다는 것이다. 

 

그러나 여러 방법들을 참고하면서 이번 프로젝트에서는 어떤 방법으로 구축해야 할지 방향을 결정해야 할 것이다.

 

이러한 내용은 이글을 쓰는 내내 공통적으로 적용된다.

 

여러 일반적인 방법론이나 관련 참고자료에서도 결국은 똑같은 방법론을 적용하기는 힘들고 각 프로젝트의 특성에 맞는

 

방법론을 찾아야 한다는 점이다.

 

여러가지 분석대상과 요구사항을  놓고 분석을 진행하지만 결국은 Data Mart 에서 사용할 항목을 추출하는 일이다.

 

항목에는 기준값(Dimension) 과 측정값(Measure)  그리고 그외 참고용으로 사용되는 일반속성으로 구분되어 정리 할 수 있다.

 

※정리할 수 있는 양식은 아래 표를 참고

 

요구사항정의항목.JPG

 

이 내용이 상세할수록 Modeling 이 끝나고 매핑정의서를 작성할 때 수월하게 진행 할 수 있으나 자칫 초반기에 너무 많은 시간을 할애 할수 있음으로

 

진행상황을 보면서 상세화 레벨을 결정해야 한다.  

 

중요한 분석대상 그리고 우선순위가 높은 분석대상을 먼저 도출하는 것이 중요하며 주제영역이 서로 연관되어 있는 분석대상은 중요하더라도

 

뒤로 미루어서 진행하는것이 복잡도를 낮추는 길이다.

 

Dimension과 Measure 항목에 대한 상세 정의와 값에 대한 산식을 정리해 놓으면 필요할때 유용하게 사용할 수 있다.

 

여기까지 진행하면 Mart Model 을 진행하기 위한 분석단계는 끝이다.

 

사실 글은 간단하지만 많은걸 진행한것이다.(절대적인 量 의 압박)

 

결과물로 나오지만 않았지 사실 이행스크립트 까지도 분석자의 머리속에는 이미 그려져 있다고 봐도 무방하다. (너무 멀리 나갔다면 죄송^^) 

 

그러면 이제 설계단계로 돌입해 보자.

 

설계를 진행하기전 먼저 고려사항을 생각해보면...

 

1. 모델은 어떤 구조로 가져갈것인지 (스타 스키마? 스노우 플레이크?  통합?)

2. Dimension Entity 를 별도로 관리할 것인지?

3. 데이터 분석 레벨(넓이와 깊이)은 어느 단계까지 구성할 것인가? 

4. 이력(변경데이터) 관리를 어느레벨로 할것인가?

5. 프로젝트의 성격(DW, DM, BI)

 

모든것은 연관되어 종합적으로 판단해야 한다.

 

그리고 각 주제영역 마다 특성이 있음으로 일괄적으로 결정하지 말고 유연하게 접근해야 할 것이다.

 

어떤것이 정답이며 어떤것은 잘못된것이다 라기 보다는 프로젝트의 특성과 운영계 시스템의 특성등을 감안하여 설계를 해야 한다.

 

이제부터는 분석된 항목을 가지고 주제영역별로 Modeling 을 진행한다.

 

물론 우선순위가 높은것 부터 진행하고 여러 주제영역에 걸쳐있는 분석대상은 각 주제영역 설계가 완성된 후에 진행한다.

 

하나의 주제영역을 보자. 여러개의 분석대상들이 정리되어 있을 것이다.

 

먼저 식별자를 결정해야 한다.

 

위의 분석단계에서 정리한 Dimension, Measure, 일반속성 중에서 식별자가 결정될수도 있고 별도(이행일자, 년도, 월 등)의 식별자가 추가 될수도 있다.

 

어쨋든 식별자는 Data  Mart의 넓이와 깊이를 결정하는 아주 중요한 단계이다.

 

물론 변경 될수도 있음을 감안한 유연한 구조를 고려해야 한다.

 

보통 하나의 주제영역은 운영계 시스템의 부모엔터티와 자식엔터티간의 상속관계로 맺어져 있다.

 

양의 차이가 있을뿐 결국은 Main Entity와 Action Entity 의 관계속에서 우리는 하나의 주제영역에 대한 넓이와 깊이를 도출해 내야 한다.

 

여기서 식별자는 최하위 Action Entity의 식별자 레벨까지 고려해야 나중에 변경에 대해서도 유연하게 대처할 수 있다.

 

물론 분석대상에 없는데 미리 최하위 레벨까지 내려가서 식별자를 결정할 필요가 없으나 이것은 전적으로 설계자의 미래에 대한 안목 이라고 볼 수 있다.

 

이렇게 식별자가 결정되면 이제 나머지  Dimension, Measure, 일반속성을 가져온다.

 

물론 이 항목들은 레벨만 다를뿐 식별자에 종속적이다. 식별자에 종속되지 않은 속성이 있다면 다시 운영계 시스템을 확인하여 없는 항목이면

 

운영계 시스템에 먼저 추가해서 관리할 수 있도록 한다.

 

여기까지 진행되면 Dimension 항목에 대한 Entity 를 생성 할 것인지 Mart 에 포함할 것인지를 결정해야 한다.

 

1.Mart  데이터양\(속성 및 Data Size)

2. 성능상 문제

3. 변경데이터 관리문제

4. 운영계 코드관리 정책

 

위의 요소들을 고려하여 결정하는데 이것은 Data Mart 의 이력관리 레벨과 같이 생각해 봐야 한다.

 

Mart Modeling 시 변경 데이터만 가져오지 않고 과거 데이터 전체를 적재하는 방식(2번) 이라면 굳이 별도의 Dimension Entity 를 설계할 필요는 없다고 본다. 

 

만약 변경데이터(Insert Or Update) 만 이행하는 구조나 신규데이터(Truncate And Insert)만 가져 오는 경우라면

 

운영계 시스템의 변경데이터 관리정책에 맞게 별도의 Entity를 설계해서 적재하도록 설계해야 할 것이다.

 

아래그림은 Mart Model 설계시 고려해야할 Data 적재 방식이다.

 

 데이터적재방식.JPG

 

여기까지 결정하고 진행하면 이력관리까지 결정된것이다.

 

그러면 마지막으로 화면설계를 봐야한다.

 

어떤 항목이 어떤 화면에서 어떤 용도로 사용되고 있는지에 따라 Mart Model 에서의 속성 조정이 발생한다.

 

단순히 위치이동 일수도 있고 새로운 속성(계산된 속성, 가공된 속성)을 추가해야할 필요성도 있다.

 

또한 식별자를 인조식별자를 사용할 것인지 본질식별자(Mart Model에서의 본질식별자는 운영계의식별자를 사용함)를

 

사용할 것인지도 결정하여 성능상 문제를 미리 차단 할수도 있다.(항상 사용하는 조회 조건확인)

 

이제 하나의 주제영역에 대한 설계가 완료 되었다.

 

나머지 주제영역도 같은 방법으로 진행 하면 될것이다.

 

이제 남은것은 여러 주제영역을 포함하는 Mart Model 이다.

 

다음글에서 나머지 설계에 대한 내용과 개발 그리고 BI 처음 주제인

 

화면 개발자와  Model 설계자의 협업은  어떻게 진행해야 하는지에 대해서도 다시한번 살펴보겠습니다. 

Tag :

Leave Comments