보통 정규화를 하다가 성능 문제(조인이 많아지니)가 발생하면 역정규화를 하는 것으로 생각하지만
이건 항상 그러한 것은 아니다. 오히려 그렇게 생각하면 설계가 무너질 수 있다.
좋은 설계를 위해선, 패턴이 심플하고 명확해야 한다.(이 패턴이 정규화와 부딪히더라도 이유가 있다면 그 패턴을 사용한다)
대표적인 사례로 스타 키마라는 것이 있다.
정규화된 테이블은 다음과 같다.
고객 테이블: 고객 정보만 담김 (이름, 연락처, 주소 등)
제품 테이블: 제품 정보만 담김 (제품명, 가격, 카테고리 등)
판매 테이블: 판매 거래만 담김 (날짜, 고객ID, 총액 등)
판매상세 테이블: 각 판매에 포함된 제품들 (판매ID, 제품ID, 수량 등)
이렇게 돼 있으면 데이터는 중복이 없고, 업데이트가 쉽다. 제품 가격이 바뀌면, 제품 데이터만 변경하며 된다.
이걸 단순히
하나의 거대한 테이블: 고객정보, 제품정보, 판매정보 모두 포함
하나의 테이블에 다 때려박으면 조회는 빠를 수 있지만, 데이터 중복이 심하고 업데이트 시 오류가 발생할 수 있다.
이때 스타 스키마를 사용할 수 있다.
중심(팩트 테이블)
판매_팩트 테이블: 판매량, 판매액 등의 측정값과 각 차원에 연결되는 ID들
가장자리(차원 테이블):
시간차원: 날짜, 월, 분기, 연도 등
제품차원: 제품명, 카테고리, 브랜드, 크기 등
고객차원: 고객 정보, 연령대, 지역 등
매장차원: 매장 위치, 크기, 유형 등
이렇게 되면, "2024년 3월 서울 매장의 음료 카테고리 판매량" 같은 복잡한 분석도 팩트 테이블과 관련 차원 테이블 2-3개만 연결하면 된다.
비즈니스 질문에 빠르게 답할 수 있게 된다. 조인을 줄일 수 있으면서, 중심 데이터를 하나의 테이블에 모으는 방식이라고 생각하면 될 것같다.
역정규화를 통해서 읽게 되는 행이 줄어들면 물리적인 입출력 I/O가 감소해서 쿼리 실행 속도가 빨라진다.
부모 테이블의 P개의 행이 있고 자식 테이블의 2Xp개의 행이 있다. 조인 연산시 p + 2 × p = 3 × p가 된다. 모든 정보를 자식 행에 포함시키면 읽어야 할 행의 개수가 2xp이다.
