객첵 관계 모델링은 모든 데이터를 객체(Entity), 관계(Relationship), 속성(Attribute) 세 가지 중 하나로 분류하는 방법이다.
흔히 "객체관계 다이어그램" 혹은 "ERD"라고 부르는 것을 통해 표현을 하는데 아래와 같은 그림을 많이 봤을것이다.
고객정보, 계좌정보, 주문내역이라는 각각의 테이블을 "객체"
각 테이블에 있는 컬럼들을 "속성"
테이블 간의 "관계"
객체 관계 모델은 보통 정규형과 연관이 있으며, 특히 제3정규형(3NF)과 관련이 있다. 객체관계 모델링과 정규화를 수행하는 기술적 목표는 "데이터 중복 감소" 및 관계형 DBMS에서 적용할 수 있는 1:1 또는 1:M관계 정립입니다.
OLTP시스템의 경우 DW와 다르게 쓰기 트랜잭션(INSERT, UPDATE, DELETE)을 많이 사용하는데 이러한 트랜잭션을 효과적으로 처리하기에 큰 장점이 있는 것이 정규화된 데이터베이스 입니다.
정규화된 DB의 경우 데이터의 중복을 제거하여 트랜잭션 자체를 작게 유지할 수 있으며, 매번 각 테이블에 불필요하게 중복해서 저장하지 않아도 되며, 이것은 서비스, 고객정보들이 변경시 한 개의 테이블에 한 개의 행을 갱신하면 된다는것을 뜻합니다.
제3정규형의 경우 데이터를 저장하는데 쉬워지는 장점이 분명하지만, DW처럼 데이터를 추출하는데 어렵다는 큰 단점이 존재합니다.
정규화를 한다는것은 테이블의 수를 증가시킨다는 것을 의미하며, 원하는 정보를 얻기위해서는 여러 테이블 JOIN해야 한다는것입니다. 원하는 데이터를 정확하게 추출하기 위한 쿼리를 만드는데 어렵고 불편해집니다.
단순히 추출하는데 너무 정규화된 테이블은 적합하지 않습니다.
실제로 DB속에 정규화된 테이블이 많게되면 적재적소에 필요한 테이블을 찾아서 JOIN을 시키는 일은 어렵습니다.
시간이 지날수록 쿼리나 JOIN을 향상시키는 방향으로 발전하고 있는데 객체관계모델링을 쓸 이유는 없습니다.
또한, 객체관계모델링의 경우 차원을 하나 추가하게 되면 1:M의 관계에서 M:M의 관계로 전환이 되어(ex, 시간차원이 증가할경우) 물리적으로 증가하는 테이블이 늘어나며, 쿼리복잡도가 계속해서 늘어나는 상황이 생깁니다.
한참 태블로를 많이 사용할때 객체관계모델로 모델링된 DB를 불러와 대시보드를 만들어본 경험이 있습니다. 당연히 BI툴에서도 성능의 저하가 심각함을 체감한 경험이 있었습니다, DW 혹은 DM을 구성하는데 있어서는 객체관계모델링이 단점이 많습니다.
디멘젼 모델을 Fact와 Dimension으로 이루어져 있습니다.
Fact는 양적인 수치를, Dimension은 질적인 차원을 나타냅니다.
예를들어 Fact의 예시가 "성적" 이라면, Dimension의 예시는 "학년", "과목"
이 될 수 있습니다.
디멘젼은 값에 대한 필터링, 그룹화, 통합화에 사용된다.
디멘젼의 경우 "데이터 큐브"형태로 시각화를 해 볼수 있는데 아래와 같다.
상품, 시간, 위치라는 세개의 디멘젼이 존재하며, 디멘젼에 따라 Fact의 요소들이 값으로 채워지게 됩니다.
위에서 표현한 데이터 큐브의 경우 3개의 디멘젼까지 표현이 가능합니다.
하지만 실제로는 훨씬 복잡한 형태의 데이터 모델링이 필요한 경우가 많습니다.
이렇게 복잡한 경우 디멘젼 모델의 물리적 구현을 쉽게 설명하기 위한 방법중 하나가 스타스키마 입니다.
스타 스키마는 그 형태가 별모양 같다고 해서 불리어진 이름이며, 아래와 같은 형태입니다.
(출처 : 데이터브릭스)
사진을 보면 중간에 있는 Fact Table을 기준으로 Dimension Table들이 둘러 싸고 있는 별모양의모습입니다.
위의 예시는 4가지의 차원을 표현하기 위해 스타스키마를 사용한 모습입니다.
스타스키마 다이어그램은 디멘젼 모델의 비정규화 된 객체 관계를 표현합니다.
팩트 테이블은 객체 관계 모델러는 디멘젼간의 M:N 관계로 표현하는 디멘젼 외래 키 또한 저장합니다. 디멘젼 외래 키들의 일부는 팩트 테이블의 기본 키를 구성하며 팩트 테이블의 그래뉼래러티(granularity:자세한 정보)와 상세 수준을 정의합니다.
비정규화된 모델을 설명하는 다른 표현법중에 snowflake 도 있습니다. 해당내용은 추후에 여건이 된다면 한번 다루어 보겠습니다. 간단하게 요약하면 snowflake는 스타스키마보다 한단계 더 정규화된 모습이라고 볼 수 있습니다.
데이터를 통합하여 부가적 측정값을 최대한 추출할 수 있도록 가용한 디멘젼들의 조합을 많이 생성할 수 있을수록 좋은 팩트 테이블이다.
BI사용자에게 친숙한 설명적 속성의 집합을 많이 제공할수록 좋은 디멘젼 테이블이다.
스타스키마에서 본것처럼 중앙에는 명확한 팩트 테이블과 적은 수의 테이블과의 조인의 연계성은 어떻게 팔매량을 측정할 수 있을지 쉽게 고려하며 쿼리를 쉽게 짤 수 있게해준다.
최적의 디멘젼 모델은 어떤 비즈니스 프로세스가 측정되어야 하고, 해당 프로세스를 어떻게 비즈니스적 용어로 표현하며, 어떤방식으로 측정할지에 대한 질문의 결과이다.
과정지향 디멘젼 모델링의 가장 큰 이점
데이터 웨어하우스의 범위, 디자인, 개발을 관리 가능한 개별 비즈니스 프로세스범위로 자연스럽게 분리할 수 있다는 점이다.
기존의 하나의 디자인을 사용할 때와 비교하여 애자일 개발팀은 스타 스키마별로 구분하여 구축 및 제공이 가능하다. 애자일 BI사용자는 처음에는 비즈니스 프로세스별로 분리한 후 이를 분석하여 초기값을 얻을 수 있다.