Fact 테이블과 Dimension 테이블을 구분하는 포인트는 차원 테이블 에 팩트 테이블 에서 측정 값을 가져 오는 특성이 포함되어 있다는 것 입니다. Fact Table과 Dimension Table간에 차이를 만들어 다른 요인을 확인하는 몇 가지 다른 요인이 있습니다. 아래 비교 차트를 한 번 살펴 보도록하겠습니다.
비교 차트
| 비교의 근거 | 팩트 테이블 | 치수 표 |
|---|---|---|
| 기본 | 팩트 테이블에는 차원 테이블의 특성을 따른 측정 값이 포함됩니다. | 차원 테이블에는 팩트 테이블에서 메트릭을 계산하는 데 사용되는 특성이 포함됩니다. |
| 속성 및 레코드 | 사실 테이블에는 적은 속성과 많은 레코드가 있습니다. | 차원 테이블에는 더 많은 특성과 적은 레코드가 있습니다. |
| 표 크기 | 팩트 테이블이 수직적으로 커집니다. | 치수 표가 수평으로 커집니다. |
| 키 | 팩트 테이블은 모든 차원 테이블의 기본 키를 연결 한 기본 키를 포함합니다. | 각 차원 테이블에는 기본 키가 들어 있습니다. |
| 창조 | 팩트 테이블은 차원 테이블이 완료 될 때만 생성 될 수 있습니다. | 먼저 차원 테이블을 만들어야합니다. |
| 개요 | 스키마에는 팩트 테이블의 수가 적습니다. | 스키마에 더 많은 수의 차원 테이블이 포함됩니다. |
| 속성 | 사실 테이블은 텍스트 형식뿐만 아니라 숫자로 된 데이터를 가질 수 있습니다. | 측정 기준 표에는 항상 텍스트 형식의 특성이 포함됩니다. |
사실 표의 정의
팩트 테이블은 차원 테이블의 특성을 따른 측정 값 을 포함하는 테이블입니다. 가능한 가장 낮은 수준의 정보를 포함 할 수 있습니다. 일부 사실 테이블에는 집계 된 사실 테이블 이라는 요약 데이터 만 있습니다. 사실 테이블에는 날짜가 찍힌 데이터가 거의 들어 있습니다. 사실 테이블의 특성에 대해 논의합시다.
연결된 키
사실 테이블에는 모든 차원 테이블의 기본 키가 결합 된 연결 키가 들어 있습니다. 사실 테이블의 연결된 키는 사실 테이블의 행을 고유하게 식별해야합니다.
데이터 그레인
데이터 그레인은 사실 테이블의 측정 값이 얼마나 깊이 저장되었는지 보여줍니다. 데이터 그레인은 가능한 가장 높은 수준에 있어야합니다.
첨가제
팩트 테이블의 속성은 완전히 첨가물 이거나 준 첨가물 일 수 있습니다. 완전 부가 측정은 사실 테이블의 모든 차원에 대해 쉽게 요약 할 수있는 측정입니다. 예를 들어, quantity_ordered는 모든 차원에 대해 요약 할 수있는 속성입니다. 마찬가지로, 우리는 특정 고객, 지역, 날짜, 브랜드 등에 대해 total quantity_order를 추출 할 수 있습니다. 부가 가치 측정은 사실 테이블의 일부 차원을 따라 합산 될 수 있지만 모든 차원을 합산 할 수없는 값입니다. 시간이 지남에 따라 균형 금액을 시간 차원에서 합산 할 수 없습니다.
스파 스 데이터
때때로 우리는 null 측정 값 이있는 속성 이있는 사실 테이블의 레코드를 볼 수 있습니다. 예를 들어 휴일에 주문이 없을 수 있습니다. 따라서이 날짜의 속성에는 null 값이 있습니다. 우리는 정보를 제공하지 않는 그런 종류의 기록에 대한 조치를 저장할 필요가 없습니다.
변형 된 크기
때로는 사실 테이블의 일부 차원을 접할 수도 있습니다. 사실은 전혀 첨가하지 않습니다. 예를 들어 order_number, customer_id의 경우 이러한 유형의 측정 기준을 추가 할 수 없습니다. 그러나이 경우에는 특정 고객이 주문한 주문을 찾아야합니다. 검색과 관련된 customer_id가 필요합니다. 사실 테이블의 속성 또는 차원을 축약 차원 이라고하는 경우 이러한 유형입니다.
치수 표 정의
차원 테이블은 스키마 시작을위한 핵심 구성 요소입니다. 차원 테이블에는 측정을 팩트 테이블에서 수행하는 차원을 나타내는 특성이 들어 있습니다. 또한 차원 테이블의 특성에 대해 설명합니다.
속성 및 키
모든 Dimension 테이블에는 테이블의 각 레코드를 고유하게 식별하는 기본 키 가 있어야합니다. 일반적으로 차원 테이블에는 많은 특성이 포함되어 있습니다. 따라서 넓게 보입니다. 즉 치수 표를 만들면 가로로 펼쳐집니다.
속성 값
차원 테이블의 특성 값은 거의 숫자가 아니므로 특성 값을 텍스트 형식으로 찾을 때가 대부분입니다. 예 : 제품 이름, 브랜드, 카테고리, 하위 카테고리 등
속성 간의 관계
종종 차원 테이블에서 발견되는 특성은 직접 관련되지 않은 것으로 관찰 할 수 있습니다. 마찬가지로 Product_brand는 package_date에 아무 작업도 수행하지 않아도되지만 둘 다 Product 차원 테이블의 특성이 될 수 있습니다.
표준화
차원 테이블은 정규화 되지 않아야합니다. 테이블을 표준화하면 많은 중간 테이블이 작성되기 때문입니다. 쿼리가 차원 테이블에서 특성을 선택하고 팩트 테이블의 특성을 따라 측정을 복구하면 쿼리는 비효율적 인 중간 테이블을 통과해야합니다. 따라서 차원 테이블은 정규화되지 않습니다.
드릴 다운, 롤업
차원 테이블의 특성을 사용하면 더 높은 수준의 집계 된 특성에서 낮은 수준의 특성으로 이동하여 세부 정보를 얻을 수 있습니다. 예를 들어 한 지역에서 총 판매량을 찾고 싶다면 주, 도시, 우편별로 매출을 찾을 수 있습니다. 당신은 총 판매액을 찾기 위해 먼저 구불 구불 한 다음 도시와 국가별로 차례로 검색 할 수 있습니다.
다중 계층 구조
종종 차원 테이블은 여러 계층 구조를 제공합니다. 예를 들어 부서별 매장에 대한 제품 차원 테이블이 있습니다. 자, 우리는 두 부서의 마케팅 및 회계 부서가 있습니다.
마케팅 부서는 팩트 테이블에 대한 측정을 얻기 위해 특정 계층 구조에서 제품 차원 테이블의 속성 중 드릴 다운합니다.
다른 한편으로, 회계 부서는 다른 계층 구조의 제품 차원 테이블 속성에서 드릴 다운하여 팩트 테이블에 대한 측정 값을 얻습니다.
따라서 차원 테이블에는 사용자가 여러 계층 구조 중 하나를 따라 드릴 다운 할 수 있도록 여러 계층 구조 또는 특성 집계 수준이 있어야합니다.
기록
차원 테이블에 너무 많은 특성이 있지만 레코드 수가 적습니다.
사실 테이블과 차원 테이블의 주요 차이점
- 팩트 테이블에는 차원 테이블의 차원 / 특성을 통한 측정 값이 포함됩니다.
- 사실 테이블에는 차원 테이블과 비교하여 더 많은 레코드와 속성이 포함되지만 차원 테이블에는 더 많은 특성과 레코드가 포함됩니다.
- 팩트 테이블의 테이블 크기는 수직으로 커지는 반면 차원 테이블의 테이블 크기는 수평으로 커집니다.
- 각 차원 테이블에는 테이블의 각 레코드를 식별하는 기본 키가 들어 있지만 사실 테이블에는 모든 차원 테이블의 모든 기본 키가 결합 된 연결 키가 들어 있습니다.
- 팩트 테이블을 만들기 전에 차원 테이블을 기록해야합니다.
- 스키마는 더 적은 팩트 테이블을 포함하지만 더 많은 차원 테이블을 포함합니다.
- 팩트 테이블의 속성은 숫자뿐만 아니라 텍스트이지만 치수 테이블의 속성에는 텍스트 속성 만 있습니다.
결론:
두 스키마 모두 스키마 작성에 동일하게 중요하지만 차원 테이블은 사실 테이블보다 먼저 기록해야합니다. 차원이없는 팩트 테이블을 생성하는 것은 불가능하기 때문입니다.
