잃어버린 시간을 찾는 개발자

개요SCD(Slow Change Dimension)처리 유형에 대해서 정리해본다. 차원, 마스터 데이터의 변경 사항을 어떻게 처리할 것인지는 비즈니스 요구사항과 데이터 분석 목적에 따라 다양한 유형으로 나뉠 수 있다. 이를 유형별로 정리 소개해보고자 한다. TYPE 0 : 원래 값 유지절대 변하지 않는 값에 취하는 방식이다.사례: 날짜 차원, 최초 계약 정보 차원TYPE 1 : 덮어쓰기변하는 데이터를 덮어쓴다. 이력 관리가 되지 않기에 이전의 값이 비즈니스 적으로 의미가 없을 때 사용한다.사례: 과거 주소가 필요없을 경우의 고객 주소 등. 히스토리 데이터를 분석할 일이 없을 때.주의사항: 과거 마스터 데이터를 토대로 계산, 집계된 데이터는 재집계의 과정을 거쳐야 한다. 히스토리 분석이 존재할 경우 피해야..

개요대시보드나 보고서를 유지보수 하다보면 이전 개발자들이 잘 못 짠 로직에 대하여 수정 요청이 올때가 많다. 일반적인 조건에서 괜찮게 보이다가 특정 조건에서는 문제가 생기는 로직이 그런 문제를 만든다. 이번에 들어온 증감률 계산 실수를 기록하여 가능한 실수를 줄일 수 있었으면 해서 이 글을 쓴다.본문증감률은 보고서에서 많이 쓰는 비율이다. 예산 대비 증감률이라고 한다면 (실적 - 예산) / 예산 * 100 이라는 형식으로 이루어진다. 보고서를 요청하는 측에서 이러한 형태의 로직을 알려줄 것이다. 현업팀 입장에서는 예외 상황에 대하여 디테일한 로직을 알려줄 의무가 없기에 로직을 짜는 IT 팀에서 각 예외 상황에 대한 고려를 할 필요가 있다.가장 대표적인 예외 상황은 0으로 나누기이다. 이건 너무 유명하고 ..

개요데이터 웨어하우스를 설계할 때 가장 중요한 원칙 중 하나는 단순하고 효율적인 데이터 모델링입니다. 하지만 종종 설계 과정에서 너무 많은 차원(Dimension)을 포함하는 비효율적인 팩트 테이블, 즉 센티피드 팩트 테이블(Centipede Fact Table)이 생성되기도 합니다.센티피드 팩트 테이블은 불필요하게 많은 차원을 포함하는 팩트 테이블을 의미하며, 이는 데이터 모델을 복잡하게 만들고 쿼리 성능을 저하시킬 수 있습니다. 하지만 컬럼 기반 데이터베이스와 같은 특정 환경에서는 예외적으로 허용될 수도 있습니다.이번 글에서는 센티피드 팩트 테이블이 무엇인지, 데이터 웨어하우스에서 피해야 하는 이유, 그리고 컬럼형 데이터베이스에서 예외적으로 사용할 수 있는 경우를 살펴보겠습니다.본론1. 센티피드 팩트..

개요이번 글에서는 재고(Inventory) 팩트 테이블의 처리 방식에 대해 다뤄보려고 합니다. 재고 데이터는 물품을 판매하는 모든 기업에서 필수적으로 다루는 데이터입니다. 특히 기업의 규모가 커지고 취급하는 품목이 많아질수록 데이터의 양은 기하급수적으로 증가합니다. 이에 따라 데이터 웨어하우스에서 재고 팩트 테이블을 어떻게 설계하고 관리할 것인지가 중요한 이슈가 됩니다.재고 팩트 테이블을 처리하는 대표적인 방법은 세 가지로 나눌 수 있습니다.트랜잭션 팩트 테이블: 개별 재고 변동 사항을 기록하는 방식정기 스냅샷 팩트 테이블: 특정 시점의 재고 상태를 기록하는 방식누적 스냅샷 팩트 테이블: 일정 기간 동안의 재고 흐름을 업데이트하며 관리하는 방식각 방식의 특징과 활용 방안을 살펴보겠습니다.본론1. 트랜잭션..

랄프 킴벌의 데이터웨어하우스 툴킷 책을 읽으며 개념을 정리하다가 대리 키 개념을 정리해보았고 SAP에서의 활용과 비교해보았다. 아래는 GPT를 통한 정리. 서론데이터웨어하우스(DW) 설계에서 대리 키(Surrogate Key)는 데이터 통합과 성능 최적화를 위한 핵심 요소로 알려져 있습니다. 하지만 SAP 시스템에서는 전통적으로 대리 키보다는 자연 키(Natural Key)를 사용하는 방식이 주류를 이루어 왔습니다. 이번 글에서는 SAP의 데이터 모델링 철학과 대리 키 사용 여부에 대해 살펴보고, SAP BW와 최신 SAP HANA 환경에서의 대리 키 활용 사례를 탐구합니다.1. 대리 키란 무엇인가?대리 키(Surrogate Key)는 의미 없는 정수형 키로, 차원 테이블의 기본 키로 사용됩니다. 이는 ..

SAP BW업무를 하게 된 지도 두 달이 되어간다. 안정화된 운영업무인만큼 그다지 많은 일들이 있지는 않았고 내게 맡겨진 일은 BO 중심이었기에 업무적으로 많이 배울 수는 없었다. 아쉬운 일이지만 그만큼 여유가 있었다. 그 여유를 활용해서 이론적 지식은 많이 익혔고 그것을 정리해보고자 한다. 간단하게 정리하는 것인만큼 캡쳐 화면이나 그림 자료는 없이 글로만 적고 설명하려고 한다. BW 변천사 SAP BW가 어떻게 변하였는지 이해하는 것은 SAP BW를 운영하는 입장에서 중요하다. 회사마다 환경이 다르고 버전이 다르기에 그에 맞는 운영법을 알아야하기 때문이다. SAP BW의 버전은 크게 셋으로 나누어 생각할 수 있다. SAP BW on Any DB, SAP BW On HANA, SAP BW/4HANA가 그..

개요DW 비즈니스 환경에서는 기간 단위로 누계 데이터를 요구하는 케이스가 무척 많다. 대표적으로 연 누계(Year-To-Date, YTD)와 월 누계(Month-To-Date, MTD)이다. 연 누계란 특정 년도의 시작일부터 기준일까지의 누적 데이터를 의미하며 MTD는 특정 월 시작일부터 기준일까지의 누적데이터를 의미한다. 이 두가지 누계 데이터가 많이 사용되는 이유는 비즈니스 환경에서 데이터를 유의미하게 나누는 기준이 년, 월 단위이기 때문이다. 년, 월 단위 누계 데이터를 조회할 경우 성장세, 목표달성률, 트랜드 등을 한 눈에 보기 편하고 유의미한 전략적 의사결정을 내리기 쉽다. 따라서 기간 누계 데이터를 다루는 방법에 대해서 알 필요가 있다.MTD와 YTD 물리 적재의 문제점우선 DW에서는 MTD,..

개요팩트 테이블은 실적, 판매 수량과 같은 수치를 차원 ID 들과 함께 매핑하여 저장하는 테이블이다. 이때 저장되는 데이터를 몇 가지 특징으로 나눌 수 있다. 이 특징에 따라서 해당 수치값을 어떻게 저장해야 하는지, 어떻게 계산하여 새로운 마트로 구성할 수 있는지가 다를 수 있다. 이글에서는 이 부부에 대해서 다루어 보고자 한다. 가산성수치값은 대부분 합산하여 활용하는 것이 직관적이다. 하지만 모든 수치값이 합산하여 계산할 수 있는 것은 아니다. 합산해서는 안 되는 값을 합산하여 계산하여 활용하거나 저장할 경우 의미없는 데이터를 조회하게 될 뿐이다. 이를 방지하기 위해서라도 저장되는 데이터의 가산성에 대해서 제대로 이해하고 있을 필요가 있다. 데이터의 가산성은 완전 가산성, 반 가산성, 비가산성으로 나눌..

개요스타스키마와 스노우 플레이크 스키마는 데이터웨어하우스와 데이터 마트에서 많이 사용되는 스키마이다. 차원과 팩트 테이블로 나누어지고 중앙에 팩트 테이블이 존재하는 스키마라는 점에서 둘은 동일하나 세부적인 면에서 차이가 있다. 이 글에서는 이 두 스키마에 대해서 정리해보도록 하겠다. 스타스키마구성 요소팩트 테이블: 주요 비즈니스 이벤트나 트랜잭션 데이터를 저장한다. 예를 들어, 매출, 수익, 판매량 등의 측정 값이 포함된다. 팩트 테이블은 외래키를 통해 차원 테이블과 연결된다.차원 테이블: 분석에 필요한 다양한 속성을 저장한다. 예를 들어 시간, 제품, 고객, 지역 등이 차원 테이블에 해당한다. 차원 테이블은 각 속성을 설명하는 컬럼들을 가지고 있으며 주로 비정규화된 형태로 저장된다.비정규화비정규화는 데..

개요데이터웨어하우스의 설계에서 팩트 테이블과 차원 테이블은 데이터를 효율적으로 저장하고 분석하기 위해 필수적인 요소이다. 이번 글에서는 팩트 테이블과 차원 테이블의 설계 방법에 대해 자세히 알아보도록 하겠다.팩트 테이블 설계팩트 테이블은 비즈니스 이벤트나 활동을 나타내는 데이터를 저장한다. 주로 수량, 금액, 획수 등의 측정값을 포함한다. 팩트 테이블은 다음과 같은 단계를 따른다.측정값 정의:팩트 테이블에 저장할 측정값을 정의한다. 예를 들어, 판매 데이터의 경우 판매량, 매출액, 할인 금액 등이 측정값이 될 수 있다.핵심 이벤트 식별:팩트 테이블은 특정 비즈니스 이벤트를 나타내므로 어떤 이벤트를 저장할 것인지 결정한다. 예를 들어, 판매 이벤트, 주문 이벤트, 클레임 이벤트 등이 있을 수 있다.키 구성..