DATOR


Data Mart 분석 및 설계 방법2 BI


이전글에 이어서,

 

여러 주제영역에 걸쳐있는것을 Mart Model 로 설계를 할것인가? 아니면 Join 으로 해결할 것인가 하는 문제는

 

화면의 요구사항, 그리고 성능문제를 고려해 봐야 한다.

 

Data Mart 의 목적은 여러가지로 사용될 수 있다.

 

1. 경영진을 위한 종합현황정보, 대쉬보드.

 

2. OLAP

 

3. 실적 통계 활용 ...

 

어느 용도로 사용하든 과연 최적의 Data 구조는 무엇인가? 를 고민하면 답을 얻을 수 있을 것이다.

 

Data 의 넓이와 깊이에 대한 레벨의 결정이 여기서도 중요하다. 과연 어느정도의 요약레벨을 가져갈 것인가를 여러 요구사항을 종합하여 결정해야 한다.

 

여러 주제영역에 해당하는 요구사항을 Mart 구조에 포함시키면 요구사항을 명확하게 만족시키며 개발자나

 

현업에서 분석데이터로 사용이 편이할 것이다.

 

반면 또 다른 관리 포인트가 발생함 으로 득과 실을 따져볼 필요가 있다.

 

OLAP Tool 에서도 거의 Mart간의 Join으로 새로운 데이터 구조 생성을 지원을 하고 있음으로 현업들이 사용을 잘 한다면 굳이  

 

주제영역간 Mart 는 생성 할 필요는 없겠다.

 

결국은 설계자의 판단이 중요하다고 볼 수 있고 그만큼 전체 업무 영역을 바라 볼 수 있는 분석력이 필요하다고 하겠다.

 

업무와 요구사항 그리고 설계자의 분석력과 판단력이 조화를 이루어야 하고 이것이 진행 방법론이나 결과에도 큰 차이를 가져 올 것이다.

 

여기까지 진행하면 논리설계가 완료된다.

 

이렇게 많은 판단과 분석이 녹아 들어간것이 Mart Model 이다

 

이것을 Model 설계자와 화면 설계자, 개발자들과 협업이 없이 이루어진다면 단시간 설명으로 해결될 수 있는 문제는 아니다.

 

모델에 대한 설명을 자세히 하더라도 개발자들은 Mart Model 의 속성 하나하나를 분석하고 이행 SQL과 매핑정의서를 참고하여 개발을 진행해야 한다.

 

이때 Model 설계자는 Data 이행을 진행하면서 검증을 하게 되는데 일반적인 건수나 금액에 대한 전체 검증은 가능하지만

 

화면 요구사항에 대한 비지니스 룰에 대한 검증은 할 수 없게 된다.

 

이 부분이 상당히 애매한 부분으로 화면 개발자는 자신이 개발한 SQL 이 맞다고 생각하고 검증하기 때문에

 

Data 를 넘겨준Modeler 에게 데이터 확인을 재차 요구하게 된다.(물론 다 그런것은 아님)

 

여기서도 협업이 중요한 요소로 작용하게 되는데 Model 설계자는 화면 설계자(개발자)의 SQL을 검증해 주어야 하고

 

화면설계자(개발자)는 이행된 Data 전체에 대한 정확성을 상호 비교해야 한다.

 

각자가 서로 같은 Data 에 대하여 다른 관점으로 바라 볼 경우 총합계는 맞지만 세부구분으로 Data 에 보여질 경우 달라질 수 있기 때문이다.

 

결국 최종 사용자는 어느 View 에서도 같은 Data 를 보기 원하기 때문에 설계이후 이행, 검증의 작업에서도 Model 설계자와 화면설계자의 협업은 필수이다.

 

여기까지 BI 프로젝트의 분석, 설계와 개발에 대한 Data Model 과 화면 설계 및 개발을 진행할때 우리가 생각해 봐야 할 점들 위주로

 

진행했지만 상세한 기술적인 부분은 이야기 하지 않았다.

 

요즘 빅데이터 분석에 관련된 여러가지 기술이 나오고 있고 분석 데이터에 대한 요구가 많은것이 사실이다.

 

하지만 결과와 기술에만 치중하고  과정의 중요성은 간과하고 있지 않나 생각해 볼 필요가 있다.

 

빅데이터에 분석에 대한 좋은 결과는 그 과정에서 다양한 사람 관계 사이의 소통과 상호 작용에 의한 결정의 결과물이 아닐까 생각해본다. 

 

프로젝트를 진행함에 있어서도 좀더 많은 부분을 사람과의 소통에 할당함이 시대의 요구로 다가오고 있는 듯 하다.

 

Tag :

Leave Comments