Ch11. Telecommunications
DMLAB 김지연
Content
스키마 설계 검토 시 일반적 고려 사항
설계 검토 가이드라인
통신 회사의 버스 매트릭스 일부
설계 검토 전∙후 스키마
기존 데이터 구조의 재설계
지리적 위치 디멘션
General Design Review Considerations
비즈니스 요건과 원천 데이터, 이해 기반의 다차원 모델 설계하기
비즈니스 프로세스 집중하여 다차원 모델 설계하기
• 점진적 스냅샷 : 요약집계, 프로세스의 흐름 파악
• 통합 팩트 테이블 : 공통적인 그래뉼래러티를 가진 여러 프로세스로부터의 팩트 테이블 결합
• 부분 집합 팩트 테이블 : 보안, 데이터 배포의 목적으로 사용
⇒ 프로세스 중심의 다차원 모델을 보충하는 역할
그래뉼래러티
• 팩트 테이블의 그레인을 명확하게 정의해야 생산적인 모델링이 가능하다
• 질의의 예측 불가능한 제한 조건이나 그룹핑을 만족시키기 위해, 가장 낮은 수준의 그래뉼래러티를 정의해야 한다
General Design Review Considerations
팩트 테이블의 그래뉼래러티 확정 후에는 포함된 팩트들이 정의된 그레인과 부합하는지 검토해야 한다
• 텍스트 값들은 팩트 테이블이 아닌 디멘션 테이블에 넣어 데이터 접근을 용이하게 하고, 롤업도 할 수 있게 해야 한다
디멘션 그래뉼래러티와 계층
• 속성들 간 다대일 관계가 있는 경우, 디멘션 계층 관계를 비정규화할 수 있는 방안을 모색해야 한다
• 팩트 테이블 내 외래키가 20개 이상이라면, 통합할만한 디멘션이 없는가 모색해야 한다
• 스노우플레이크 형태로 서로 연결된 여러 디멘션 테이블로 정규화하는 것은 지양해야 한다
• 디멘션은 계층 수준을 가리키는 속성을 가지고 있어 가장 하위인지 중간 계층 이상인지를 판단해야 한다
General Design Review Considerations
일자 디멘션 (Date Dimension) • 팩트 테이블에는 일자 디멘션이 외래키로 연결되어 있는데 연결된 날짜
가 무엇을 의미하는지 알 수 없어 일반적인 일자 디멘션과 팩트 테이블을 조인한다
• 일자 디멘션 대신 월 디멘션을 사용 할 때 문제점 특정 월에 대한 하드코딩된 식별자가 유연하지 못하다
일자 디멘션이 존재하지 않기 때문에 일자의 속성은 DB가 아닌 애플리케이션이 관리해야 한다
측정값이 특정 월에만 있는 경우 많은 컬럼이 NULL로 채워져 비효율적이다
퇴화 디멘션 (DD, Degenerate Dimensions) • 송장번호나 주문번호와 같은 운영 트랜잭션 번호를 퇴화 디메션으로 보
고, 트랜잭션 일자나 고객과 같은 트랜잭션 헤더 레코드에 있는 속성을 갖는 트랜잭션 번호를 위한 별도의 디멘션 테이블을 만든다
대체키 (Surrogate Keys) • 디멘션 테이블의 기본키를 사용한다
General Design Review Considerations
디멘션 코드와 설명 (Dimension Decodes and Descriptions)
• 디멘션 내의 모든 식별자와 코드에는 설명이 있어야 한다
데이터의 중복성을 줄이는 방법을 써온 모델러들은 필요성을 느끼지 못함
사용자는 모든 코드를 외우지 못하기에 필요성이 절실함
• 보고서 레이블의 일관성 유지를 위해 데이터의 속성으로 DB안에서 코드 값을 관리해야 한다
일관성과 통합성을 갖추기 위해 표준 디멘션 사용하기
Design Review Guidelines
설계 검토 전 추천 사항
• 업무와 업무요건을 아는 사람(모델링팀과 BI개발팀)을 참석시켜야 한다
• 검토팀이 검토의 목표에서 벗어나지 않도록 조절해주는 리더를 지정해야 한다
• 검토 중 부수적인 주제에 빠지지 않도록 검토의 범위를 사전에 합의해야 한다
• 다차원모델 검토는 보통 이틀 정도 소요되는데, 참석자가 검토 기간 전체를 참여할 수 있도록 모든 참석자의 일정을 확보해야 한다
• 회의에 적합한 장소를 예약해야 한다
• 참석자가 현재 모델에 대한 문제점 또는 개선점에 대해 생각해보도록 숙제를 주어야 한다
Design Review Guidelines
설계 검토 중 추천 사항 • 기존의 설계 관련 사항에 대해 방어적 자세(더 나은 방법이 없다고 체념)
보다는 열린 자세를 가져야 한다
• 검토 과정에서 필요하지 않은 pc∙스마트폰 등을 금지하여 회의에 집중하도록 해야 한다
• 리더는 팀이 집중할 수 있도록 돕고, 범위에서 벗어나는 논의를 막을 수 있는 리더십을 보여주어야 한다
• 참가자들이 검토대상 모델에 대해 공통적 이해를 가지도록 해야 한다
• 논의되는 내용과 의사결정 결과를 필기할 사람을 정해야 한다
• 큰 그림부터 시작해야 한다 버스 매트릭스 → 최우선순위 프로세스 집중 → 그래뉼래러티 정의 → 관련
차원 정의
Fact table → Dimension
• 업무 요건을 만족시키는 게 가장 중요하다는 것을 주시시켜야 한다
• 샘플 데이터를 이용하여 참가자들이 개선안에 대해서 같은 이해를 하도록 해야 한다
• 참가자들이 회의 결과를 복기할수록 요약 정리 후 회의를 마쳐야 한다
Design Review Guidelines
설계 검토 후 추천 사항
• 아직 미결인 문제를 해결 할 수 있도록 책임자를 지정해야 한다
• 개선안의 비용 대비 효용을 살펴야 하며, 개선안을 어떻게 구현할지 구체적인 계획을 짜야 한다
• 모델은 12개월 또는 24개월마다 재검토해야 한다
Telecommunications company’s sample bus matrix
구매
내부 재고
채널 재고
회선 활성화
상품 판매
프로모션 참여
통화 상세 트래픽
고객 청구
고객 지원 콜
수리 요청
일자 상품 고객 요금제 영업 회선 스위치 직원 지원 콜 조직 번호 특성
Draft schema prior to design review
청구 시스템은 회선(전화번호)별로 청구서 생성
팩트 테이블의 그레인 : 각 월별로 청구서
각 회선은 한 고객, 하나의 요금제, 영업조직과 채널과 연결
한 고객이 여러 회선을 가질 경우, 하나의 청구서 안에 회선별로 분리되어 나타남
요금제는 고객의 사용 행태에 따라 변함
각 채널 파트너가 만든 청구 금액의 흐름 평가 할 수 있음
Draft schema following design review
팩트 테이블의 그레인 : 청구서에 포함된 회선 하나
청구 로우가 적재될 때마다 청구서 디멘션에도 로우가 적재되기에 퇴화디멘션 처리
청구 일자를 청구서 디멘션에서 팩트 데이블로 옮기고 청구 일자 역할을 하는 일자 디멘션과 조인
텍스트 형태인 요금제 유형 코드는 요금제 디멘션 테이블에서 관리 영업 조직과
영업 채널 디멘션의 계층 통합
운영계의 식별자를 기본키로 그대로 사용하고 있어 모든 디멘션의 기본키로 대체키를 구현하도록 하고, 팩트 테이블에는 해당 대체키를 외래키로 사용해야 한다
Year-to-Date Service Charge는 일자 디멘션의 연도에 조건을 걸어서 해당 값을 보거나 BI 툴의 기능을 이용하면 되기에 제거해도 된다
Remodeling Existing Data Structures
기존 디멘션 테이블에 새로운 속성 추가
• 디멘션 이력 관리 Type 1
해당 속성의 과거의 정확한 값은 상관없이 지금부터 정확히 이력 관리를 한다면 쉬운 방법이나 정확한 분석은 어렵다
• 디멘션 이력 관리 Type 2
해당 속성의 변경 사항과 다른 디멘션 속성의 변경 사항을 같이 고려하면서 디멘션 데이블의 로우가 추가되어야 하고, 팩트 테이블에 있는 로우의 일부분은 적절한 디멘션 로우와 연결되기 위해 갱신되어야 한다
기존의 데이터 구조를 사용하던 BI리포팅∙분석 애플리케이션의 영향
• BI 애플리케이션이 물리적인 데이터 구조 대신 뷰를 사용하게 된다면 어느 정도 완충이 가능하지만, BI 환경에 일반적으로 적절하지 않다
기존의 데이터 구조 개선 시, 효용과 비용을 고려
• 문제점이 복잡함에도 불구하고 개선하겠다고 결정
• 현재의 구조를 버리고 해당 주제 영역을 새롭게 만드는 방법
• 비용이 효용을 초과하여 기존의 최적화되지 않은 데이터 구조 유지
• 원천 시스템의 변경이나 새로운 BI 툴 전환 필요 시 리모델링 고려
Geographic Location Dimension
통신이나 전력 분야는 많은 디멘션들이 정확한 지리적 위치 정보를 속성으로 가진다
• 도로명, 시∙군∙구, 우편번호, 경도와 위도 등
• 경도와 위도는 지리 공간 분석과 지도와 연결하여 시각화 이용
시나리오 : 주소 데이터가 표준화되어 있는 하나의 마스터 위치 테이블 생성하고, 다른 여러 디멘션 테이블을 붙인다
• 마스터 위치 테이블의 로우 : 모든 지리적인 정보를 롤업한 특정한 위치
• 디멘션 테이블 : 회선 전화번호, 설비, 네트워크 장비(전봇대, 스위치 박스), 부동산, 서비스 위치, 출동 위치, 선로 점유권, 고객 디멘션 등 포함
위치 정보는 그 자체가 분석에 쓰이기 보다는 다른 디멘션들의 속성으로 쓰인다
Thank you
Recommended
