사진과 음악을 좋아하는 개발자 지망생의 블로그

[데이터 웨어하우스] 4. 데이터 웨어하우스 모델링(사실, 사실 테이블, 차원, 차원 테이블, 가산 사실, 비가산적인 요소, 중간 가산 사실, 스타 스키마, 스노우플레이크 스키마, 키) 본문

개발/데이터 웨어하우스 - 기초

[데이터 웨어하우스] 4. 데이터 웨어하우스 모델링(사실, 사실 테이블, 차원, 차원 테이블, 가산 사실, 비가산적인 요소, 중간 가산 사실, 스타 스키마, 스노우플레이크 스키마, 키)

devculture309 2023. 5. 24. 12:02
반응형

 이 글은 데이터 웨어하우징의 설계 엔지니어링 측면과 특히 비즈니스 요구사항을 고려하여 데이터를 구조화하고 조직화하는 방법인 차원(dimension) 모델링에 대해 이야기합니다. 데이터 웨어하우스가 어떻게 사용되는지와 비즈니스 인텔리전스(BI)와 데이터 웨어하우징이 어떻게 상호작용하는지 이야기합니다. 또한, 특정 비즈니스 인텔리전스 범주가 데이터 모델을 결정하는 데 어떻게 영향을 미치며, 그에 따른 기본 보고와 온라인 분석 처리가 차원 모델링의 중요성을 설명합니다.

 

1. 데이터 웨어하우스에서의 '차원 모델링'

차원 모델링은 데이터 웨어하우스의 설계 방법 중 하나로, 데이터를 차원과 척도로 구성하여 분석의 효율성과 이해도를 높이는 방법입니다. 차원 모델링은 데이터 웨어하우스에서 사용되는 중요한 원리입니다. 데이터 웨어하우스는 비즈니스 인텔리전스(BI)를 위해 데이터를 분석하고 보고하는 데 사용됩니다. 이를 위해서는 데이터를 차원적으로 구성해야 합니다.

 

차원 모델링은 데이터 웨어하우스에서 사용되는 중요한 원리입니다. 이 모델링은 데이터를 구성하는 두 가지 요소인 측정값과 차원적 맥락을 제공합니다.

 

측정값은 어떤 종류의 측정인지를 나타냅니다. 예를 들어, 숫자 6644는 그 자체로는 무엇을 의미하는지 알 수 없습니다. 그러나 이 값에 "달러"라는 맥락을 추가하면, 이 값이 월급인지, 물건의 가격인지 등을 알 수 있습니다. 측정값은 데이터의 양을 나타내거나 계산 가능한 수치를 포함합니다.

 

하지만 측정값만으로는 데이터의 전체 의미를 파악하기 어렵습니다. 이를 위해 차원적 맥락이 필요합니다. 차원은 데이터를 분류하고 그룹화하는 기준을 제공합니다. 예를 들어, "평균 연봉"이라는 측정값은 직급, 부서, 학년 등의 차원에 따라 분류될 수 있습니다. 이러한 차원적 맥락은 데이터를 다양한 관점에서 분석하고 의미 있는 인사이트를 얻을 수 있도록 도와줍니다.

 

차원적인 질문은 "by""for"라는 단어를 사용하여 표현됩니다. 이 단어들은 데이터를 분석하고 그룹화하는 방법을 나타냅니다.

 

"by"는 해당 차원의 모든 값을 포함하여 결과를 분석하고 그룹화하는 것을 의미합니다. 예를 들어, "모든 학부 및 학년별로 평균 연봉을 알려주세요"라는 질문은 학부와 학년이라는 차원의 모든 값을 고려하여 결과를 요구하는 것을 의미합니다. 이 경우, 결과는 모든 학부와 학년에 대한 평균 연봉이 됩니다.

 

반면에, "for"는 차원 내에서 특정 값을 선택하여 결과를 얻고자 하는 것을 의미합니다. 예를 들어, "조교수의 평균 연봉을 알려주세요"라는 질문은 조교수라는 특정 직급에 대한 필터링을 통해 결과를 얻고자 하는 것을 의미합니다. 이 경우, 결과는 조교수에 해당하는 연봉의 평균값이 됩니다.

 

이러한 차원적인 질문은 데이터 웨어하우스에서 비즈니스 인텔리전스 작업을 수행할 때 사용됩니다. 측정값과 함께 차원적인 맥락을 고려하여 데이터를 분석하고 의미 있는 인사이트를 얻을 수 있습니다.

 

 

2. 사실(Fact), 사실 테이블(Fact Table), 차원(Dimension), 차원 테이블(Dimension Table)

이제 차원 모델링에 관해 추상적인 개념에서 구체적인 내용인 사실(fact), 사실 테이블(fact table), 차원(dimension)차원 테이블(dimension table)에 대해 알아보겠습니다.

 

1. 사실(Fact)

  • 데이터 웨어하우스에서 저장되는 중요한 정보
  • 건이나 트랜잭션을 나타내며, 숫자적이고 측정 가능한 값을 갖는다
  • 예를 들어, 매출, 주문량, 재고량, 방문자 수 등은 사실에 해당할 수 있음

2. 사실 테이블(Fact Table)

  • 사실 테이블은 데이터 웨어하우스에서 사실들이 저장되는 테이블
  • 사실 테이블은 관계형 데이터베이스의 테이블 형태로 구성되어 있다
  • 각 행은 개별 사실을 나타내고, 열은 해당 사실과 관련된 속성들을 포함함
  • 예를 들어, 매출 사실 테이블에서 열로는 날짜, 제품, 지역, 매출액 등의 속성이 포함될 수 있음

사실 테이블의 예

3. 차원(Dimension)

  • 데이터 웨어하우징에서 사실에 대한 맥락을 제공하는 구성 요소
  • 사실을 설명하는 추가 정보를 제공하며, 사실과 관련된 여러 관점을 포함함
  • 예를 들어, 제품, 시간, 지역, 고객 등은 차원에 해당할 수 있음

4. 차원 테이블(Dimension Table)

  • 차원과 관련된 정보를 저장하는 테이블
  • 주로 관계형 데이터베이스의 테이블 형태로 구성되며, 차원의 속성을 담음
  • 예를 들어, 제품 차원 테이블에서 열로는 제품 ID, 제품 이름, 제조사, 카테고리 등의 속성이 포함될 수 있음

차원 테이블의 예

 

 

3. 가산 사실 (Additive Fact), 비가산적인 요소 (Non Additive Factor), 중간 가산 사실 (Semi Additive Fact)

1. 가산 사실 (Additive Fact)

가산 사실 (Additive Fact)은 데이터 웨어하우스에서 합산이 가능한 사실을 의미합니다. 이는 여러 개별 사실을 더하여 전체를 계산할 수 있는 특성을 갖고 있습니다. 직원들의 매출 정보를 담고 있는 가상의 사실 테이블 예로 들어보겠습니다.

위의 표에서 각 행은 개별적인 사실을 나타내며, 각 열은 해당 사실의 특성을 의미합니다. 이 경우 "매출"은 수치적인 값으로 가산 사실에 해당됩니다. 가산 사실의 특성을 이용하여 다양한 집계 연산을 수행할 수 있습니다. 예를 들어, 위의 표에서 직원들의 매출을 합산하여 전체 매출을 계산할 수 있습니다

 

전체 매출 = 500 + 750 + 1000 + 800 + 600 + 1200 = 4850

 

위의 예시에서 볼 수 있듯이, 가산 사실은 개별 사실들의 값을 더하여 전체 값을 계산하는 데에 사용됩니다.

 

2. 비가산적인 요소 (Non Additive Factor)

비가산적인 요소는 데이터 웨어하우스에서 합산이 불가능한 사실을 말합니다. 비록 측정 가능한 지표이지만 값들을 단순히 더하는 것으로는 의미가 없는 경우를 말합니다. 고객의 판매 데이터가 데이터 웨어하우스에 저장되어 있다고 가정해보겠습니다.

위의 표에서 "판매량"은 개별적인 값으로 비가산적인 요소에 해당됩니다. 판매량은 개별적인 값으로 고객 및 날짜에 따라 달라지기 때문에 단순한 덧셈으로는 전체 판매량을 구할 수 없습니다.

 

비가산적인 요소의 경우 다른 방식으로 분석되거나 집계될 수 있습니다. 예를 들어, 특정 기간 동안의 총판매량을 계산하거나 각 고객의 평균 판매량을 파악하는 등의 연산이 가능합니다.

 

3. 중간 가산 사실 (Semi Additive Fact)

중간 가산 사실은 일부 경우에는 합산 가능하고, 다른 경우에는 합산이 불가능한 사실을 말합니다. 즉, 가산 사실처럼 동작하는 경우와 비가산적인 요소처럼 동작하는 경우가 혼합된 형태입니다. 중간 가산 사실은 일반적으로 주기적 스냅샷 사실 테이블(periodic snapshot fact table)에서 사용됩니다. 제품 재고 데이터가 데이터 웨어하우스에 저장되어 있다고 가정해 보겠습니다.해보겠습니다.

위의 표에서 "재고량"은 중간 가산 사실에 해당됩니다. 각 제품의 재고량을 날짜별로 기록하고 있습니다. 재고량은 개별 제품에 따라 달라지며, 날짜별로 누적되거나 합산될 수 있습니다.

 

중간 가산 사실은 시간적인 콘텍스트에서 값이 의미를 갖는 경우에 유용합니다. 예를 들어, 특정 날짜의 재고량을 조회하거나 특정 기간 동안의 재고량 변화를 분석하는 등의 작업에 활용될 수 있습니다.

 

 

4. 스타 스키마(Star Schema)와 스노우플레이크 스키마(Snowflake Schema)

스타 스키마(Star Schema)스노우플레이크 스키마(Snowflake Schema)는 데이터 웨어하우스에서 사용되는 두 가지 주요한 구조적 접근 방식입니다. 이 두 스키마는 차원 모델링의 구현 방법을 나타내며, 차원 테이블과 사실 테이블의 관계를 다르게 표현합니다.

 

스타 스키마(Star Schema)는 데이터 웨어하우스에서 가장 일반적으로 사용되는 차원 모델링의 한 형태입니다. 스타 스키마는 중심 사실(Fact) 테이블과 이에 연결된 여러 차원(Dimension) 테이블로 구성됩니다.

스노우플레이크(Snowflake Schema) 스키마는 데이터 웨어하우스에서 사용되는 차원 모델의 한 종류로, 차원 테이블을 더 세분화하여 정규화하는 방식입니다. 스노우플레이크 스키마는 스타 스키마의 확장된 형태로 볼 수 있습니다.

 

다음은 스타 스키마와 스노우플레이크 스키마의 비교입니다

  1. 구조: 스타 스키마는 단일 차원 테이블과 하나의 중심 사실 테이블로 구성되는 반면, 스노우플레이크 스키마는 차원 테이블이 정규화되어 다중 테이블로 분리됩니다
  2. 정규화: 스타 스키마는 차원 테이블이 비정규화되어 중복 데이터를 포함할 수 있지만, 스노우플레이크 스키마는 차원 테이블이 정규화되어 중복 데이터를 최소화합니다.
  3. 관계: 스타 스키마에서는 차원 테이블과 사실 테이블 간의 직접적인 관계가 형성됩니다. 반면에 스노우플레이크 스키마에서는 차원 테이블이 서로 연결되어 복잡한 관계를 형성할 수 있습니다.
  4. 유연성: 스노우플레이크 스키마는 데이터의 세분화와 복잡한 계층 구조를 지원하여 더 유연한 데이터 분석이 가능합니다. 반면, 스타 스키마는 간단하고 직관적인 구조로 분석이 용이합니다.
  5. 성능: 스타 스키마는 조인 연산이 적으므로 쿼리 성능이 좋습니다. 반면, 스노우플레이크 스키마는 조인 연산이 많아질 수 있으므로 쿼리 성능이 더 떨어질 수 있습니다.

스타 스키마는 간단하고 직관적인 구조로 데이터 웨어하우스를 구성할 때 유용하며, 스노우플레이크 스키마는 복잡한 계층 구조와 세분화된 데이터를 다룰 때 유용합니다. 선택은 데이터의 특성과 분석 요구사항에 따라 달라질 수 있습니다.

 

 

5. 데이터웨어하우스에서 데이터베이스 키(Key)

데이터 웨어하우스에서 데이터베이스 키(Database Key)는 데이터베이스 테이블에서 행(row)을 고유하게 식별하기 위해 사용되는 열(column) 또는 열의 집합입니다. 데이터베이스 키는 테이블 내에서 각 행을 구분하고 식별하는 데 사용되며, 데이터의 무결성과 일관성을 보장하기 위해 중요한 역할을 합니다.

 

주요한 데이터베이스 키의 종류는 다음과 같습니다

1. 기본 키 (Primary Key)

기본 키는 데이터베이스 테이블의 각 행을 고유하게 식별하는 데 사용되는 열 또는 열의 집합입니다. 즉, 기본 키는 테이블 내에서 각 행을 식별하는 데 사용되는 고유한 값입니다. 기본 키는 데이터의 무결성과 일관성을 보장하며, 데이터베이스에서 빠른 검색 및 연결 작업을 가능하게 합니다.

 

기본 키는 보통 한 열로 구성되지만, 경우에 따라 여러 열의 조합으로 구성될 수도 있습니다. 예를 들어, 고객 테이블에서는 각 고객에게 고유한 식별자인 고객 ID를 기본 키로 사용할 수 있습니다. 이러한 기본 키를 통해 각 고객의 정보를 식별하고 다른 테이블과의 관계를 맺을 수 있습니다.

 

기본 키는 데이터베이스 설계 시 정의되며, 중복되지 않고 비어 있지 않은 고유한 값을 가져야 합니다. 또한, 기본 키는 변경되지 않는 값이어야 하며, 특정 행을 식별하는 데에만 사용되어야 합니다. 데이터베이스 관리 시스템은 기본 키를 사용하여 테이블의 각 행을 식별하고, 효율적인 데이터 검색 및 조인 작업을 수행합니다.

 

1 - 1. 자연 키 (Natural Key)

데이터의 본질적인 특성을 나타내는 식별자입니다. 자연 키는 주로 데이터 자체에 내재된 고유한 속성이나 조합으로 구성됩니다. 예를 들어, 학생 테이블에서 학번(student ID)이나 주민등록번호(National ID)가 자연 키가 될 수 있습니다.

 

자연 키는 데이터의 의미와 의도를 반영하며, 보통 데이터 원본 시스템에서 이미 존재하는 속성을 활용합니다. 이러한 속성은 일반적으로 데이터의 고유성을 보장하며, 외부에서 생성된 키가 아니라 데이터 자체에 내재되어 있습니다.

 

자연 키는 데이터의 의미를 쉽게 이해할 수 있으며, 사용하기도 간편합니다. 또한 자연 키는 데이터를 다른 테이블과 연결하거나 조인하는 데 유용할 수 있습니다. 예를 들어, 학생 테이블의 학번을 다른 테이블에서 참조함으로써 학생의 성적, 출석 기록 등과 연결할 수 있습니다.

 

하지만 자연 키는 몇 가지 제한 사항을 가지고 있을 수 있습니다. 첫째, 자연 키가 충분히 고유하고 예측 가능해야 합니다. 둘째, 자연 키가 길거나 복잡한 경우 테이블의 크기를 증가시키고 인덱스를 관리하는 데 어려움을 줄 수 있습니다. 또한 데이터 원본 시스템에서 자연 키가 변경되는 경우 데이터 일관성을 유지하기 어려울 수 있습니다.

 

이러한 이유로 자연 키 대신에 인위적으로 생성되는 대체 키인 대체 키(Surrogate Key)를 사용하는 경우도 많습니다. 서로게이트 키는 데이터베이스에서 고유한 식별자로 사용되며, 자연 키의 한계를 극복할 수 있습니다.

 

1 - 2. 대리 키 (Surrogate Key)

데이터베이스에서 인위적으로 생성되는 고유한 식별자입니다. 대리키는 데이터의 자연 특성과는 독립적으로 생성되며, 주로 숫자나 암호화된 문자열 형태로 표현됩니다. 대리키는 데이터베이스 테이블에서 각 행을 고유하게 식별하기 위해 사용됩니다.

 

대리키는 데이터의 본질적인 의미나 의도와는 관계없이 생성되므로 비즈니스 도메인에서 사용되는 자연 키와는 다릅니다. 대리키는 일반적으로 자동으로 증가하는 정수값이나 UUID(Universally Unique Identifier)와 같은 무작위 한 문자열로 생성됩니다. 이러한 특성으로 인해 대리키는 데이터베이스 성능과 관리의 편의성을 향상할 수 있습니다.

 

대리키는 몇 가지 장점을 가지고 있습니다. 첫째, 대리키는 데이터의 고유성을 보장합니다. 데이터가 삽입될 때마다 자동으로 증가하는 값을 부여하므로 중복된 키를 생성하는 위험이 없습니다. 둘째, 대리키는 데이터의 의미를 숨길 수 있습니다. 외부에서 대리키를 보더라도 실제 데이터의 의미나 속성을 알 수 없으므로 보안 및 개인정보 보호 측면에서 유리합니다. 셋째, 대리키는 데이터의 변경에 유연하게 대응할 수 있습니다. 자연 키가 변경되는 경우에도 대리키는 일관성을 유지하며 데이터 간의 관계를 유지할 수 있습니다.

 

하지만 대리키를 사용하는 것은 항상 필수적이지는 않습니다. 데이터의 본질적인 의미나 의도를 나타내는 자연 키가 이미 존재하는 경우에는 대리키를 추가로 생성할 필요가 없을 수 있습니다. 또한 대리키를 생성하고 유지하기 위한 추가적인 비용과 노력이 필요할 수 있습니다.

 

따라서 대리키의 사용 여부는 데이터베이스 설계자와 비즈니스 요구에 따라 결정되어야 합니다. 데이터의 본질적인 의미나 고유성, 데이터베이스 성능 및 유지보수의 용이성을 고려하여 적절한 키 전략을 선택해야 합니다.

 

2. 외래 키 (Foreign Key)

관계형 데이터베이스에서 한 테이블의 데이터와 다른 테이블의 데이터 간의 관계를 정의하는 데 사용되는 열 또는 열의 집합입니다. 외래 키는 다른 테이블의 기본 키와 연결되어 두 테이블 간의 관계를 나타냅니다.

 

외래 키는 일반적으로 다른 테이블의 기본 키를 참조하는 열로 구성됩니다. 이를 통해 한 테이블의 데이터가 다른 테이블의 특정 행과 관련되어 있음을 나타낼 수 있습니다. 예를 들어, 주문 테이블에서는 고객의 주문과 해당 고객 정보를 연결하기 위해 고객 ID를 외래 키로 사용할 수 있습니다. 이러한 외래 키를 통해 주문 테이블과 고객 테이블 간의 관계를 설정할 수 있습니다.

 

외래 키는 데이터 무결성을 보장하고 데이터베이스에서 참조 무결성 제약 조건을 적용하는 데 사용됩니다. 외래 키를 통해 데이터의 일관성을 유지하고 관련 테이블 간의 데이터 무결성을 유지할 수 있습니다. 또한 외래 키를 사용하여 테이블 간의 조인 작업을 수행하고 데이터를 연결하는 데 도움을 줍니다.

 

외래 키는 관계형 데이터베이스 설계 시에 정의되며, 참조하는 테이블의 기본 키와 일치하는 값을 가져야 합니다. 일반적으로 외래 키는 참조 무결성 제약 조건을 설정하여 참조하는 테이블의 데이터가 변경되거나 삭제될 때 연관된 데이터의 일관성을 유지합니다.

반응형