dimensional data model data warehouse tutorial with examples
이 튜토리얼은 데이터웨어 하우스에서 차원 데이터 모델의 이점과 통념을 설명합니다. 또한 예제와 함께 차원 테이블 및 사실 테이블에 대해 알아보십시오.
데이터웨어 하우스 테스트 이전 튜토리얼에서 설명했습니다. 모두를위한 데이터웨어 하우스 교육 시리즈 .
방대한 데이터는 차원 데이터 모델링 기술을 사용하여 데이터웨어 하우스 (DW)에 구성됩니다. 이러한 차원 데이터 모델링 기술을 사용하면 최종 사용자가 비즈니스 데이터에 대해 매우 쉽게 조회 할 수 있습니다. 이 튜토리얼은 DW의 차원 데이터 모델에 대한 모든 것을 설명합니다.
대상 청중
- 데이터웨어 하우스 / ETL 개발자 및 테스터.
- 데이터베이스 개념에 대한 기본 지식이있는 데이터베이스 전문가.
- 데이터웨어 하우스 / ETL 개념을 이해하고자하는 데이터베이스 관리자 / 빅 데이터 전문가.
- 데이터웨어 하우스 일자리를 찾고있는 대학 졸업자 / 신입생.
학습 내용 :
차원 데이터 모델
차원 데이터 모델은 ETL 흐름에서 최종 사용자가 데이터를 쿼리하고 분석하기 위해 사용할 수있는 데이터 구조입니다. ETL 프로세스는 데이터를 대상 차원 데이터 모델로로드하는 것으로 끝납니다. 모든 차원 데이터 모델은 여러 차원 테이블로 둘러싸인 사실 테이블로 작성됩니다.
차원 데이터 모델을 디자인하는 동안 따라야 할 단계 :
차원 데이터 모델링의 이점
다음은 차원 데이터 모델링의 다양한 이점입니다.
- 지속적으로 변화하는 DW 환경을 사용할 수 있도록 보안됩니다.
- 차원 데이터 모델을 사용하여 방대한 데이터를 쉽게 작성할 수 있습니다.
- 차원 데이터 모델의 데이터는 이해하고 분석하기 쉽습니다.
- 고성능 쿼리를 위해 최종 사용자가 빠르게 액세스 할 수 있습니다.
- 차원 데이터 모델을 사용하면 데이터를 계층 적으로 드릴 다운 (또는) 롤업 할 수 있습니다.
ER 모델링 대 차원 데이터 모델링
- ER 모델링은 운영 시스템에 적합하고 차원 모델링은 데이터웨어 하우스에 적합합니다.
- ER 모델링은 상세한 현재 트랜잭션 데이터를 유지하는 반면 차원 모델링은 현재 및 과거 트랜잭션 데이터의 요약을 유지합니다.
- ER 모델링에는 정규화 된 데이터가있는 반면 차원 모델링에는 비정규 화 된 데이터가 있습니다.
- ER 모델링은 쿼리 검색 중에 더 많은 조인을 사용하는 반면 차원 모델링은 더 적은 수의 조인을 사용하므로 차원 모델링에서 쿼리 성능이 더 빠릅니다.
차원 데이터 모델링 신화
다음은 기존의 차원 데이터 모델링 신화 중 일부입니다.
- 차원 데이터 모델은 데이터 요약을 나타내는 데만 사용됩니다.
- 조직의 부서별로 다릅니다.
- 확장 성을 지원하지 않습니다.
- 최종 사용자 보고서 및 쿼리의 목적을 제공하도록 설계되었습니다.
- 차원 데이터 모델을 통합 할 수 없습니다.
차원 테이블
차원 테이블은 분석 된 모든 메트릭 값을 저장하여 DW 시스템에서 중요한 역할을합니다. 이러한 값은 테이블에서 쉽게 선택할 수있는 차원 속성 (열) 아래에 저장됩니다. DW 시스템의 품질은 주로 차원 속성의 깊이에 따라 다릅니다.
따라서 우리는 차원 테이블에서 각각의 값과 함께 많은 속성을 제공해야합니다.
차원 테이블의 구조를 살펴 보자 !!
# 1) 차원 테이블 키 : 모든 차원 테이블에는 각 행을 고유하게 식별하기위한 기본 키로 차원 속성 중 하나가 있습니다. 따라서 해당 속성의 고유 한 숫자 값이 기본 키로 작동 할 수 있습니다.
어떤 경우에도 속성 값이 고유하지 않으면 순차적으로 생성 된 시스템 번호를 기본 키로 고려할 수 있습니다. 이를 대리 키라고도합니다.
차원 데이터 모델에는 차원과 팩트 사이의 각 키에 대한 참조 무결성 제약 조건이 있어야합니다. 따라서 팩트 테이블은 참조 무결성을 유지하기 위해 차원 테이블의 각 기본 / 대리 키에 대한 외래 키 참조를 갖습니다.
실패하면 해당 차원 키에 대해 해당 사실 테이블 데이터를 검색 할 수 없습니다.
# 2) 테이블이 넓다 : DW주기의 어느 시점에서나 차원 테이블에 속성을 추가 할 수 있으므로 차원 테이블이 넓다고 말할 수 있습니다. DW 설계자는 ETL 팀에 각각의 새 속성을 스키마에 추가하도록 요청합니다.
실시간 시나리오에서는 속성이 50 개 (또는) 이상인 차원 테이블을 볼 수 있습니다.
# 3) 텍스트 속성 : 차원 속성은 텍스트 (또는) 숫자로 모든 유형이 될 수 있습니다. 텍스트 속성에는 코드가 아닌 실제 비즈니스 단어가 있습니다. 차원 테이블은 계산을위한 것이 아니므로 숫자 값은 차원 속성에 거의 사용되지 않습니다.
# 4) 속성은 직접 관련되지 않을 수 있습니다. 차원 테이블의 모든 속성은 서로 관련되지 않을 수 있습니다.
# 5) 정규화되지 않음 : 차원 테이블을 정규화하면 효율적이지 않은 중간 테이블이 더 많이 표시됩니다. 따라서 차원 테이블은 정규화되지 않습니다.
차원 속성은 쿼리에서 제약 조건의 소스 역할을 할 수 있으며 보고서에 레이블로 표시 될 수도 있습니다. 차원 테이블에서 속성을 직접 선택하고 다른 중간 테이블을 건드리지 않고 각 사실 테이블을 직접 참조하면 쿼리가 효율적으로 수행됩니다.
# 6) 드릴 다운 및 롤업 : 차원 속성에는 필요할 때마다 데이터를 드릴 다운 (또는 롤업)하는 기능이 있습니다.
# 7) 다중 계층 : 여러 계층이있는 단일 차원 테이블은 매우 일반적입니다. 차원 테이블은 맨 아래에서 맨 위로 경로가 하나만있는 경우 간단한 계층 구조를 갖습니다. 마찬가지로 하단 수준에서 상단까지 도달하는 경로가 여러 개인 경우 여러 계층이 있습니다.
# 8) 몇 가지 기록 : 차원 테이블은 팩트 테이블 (백만 단위)보다 적은 수의 레코드 (백 단위)를 갖습니다. 팩트보다 작지만 팩트 테이블에 모든 입력을 제공합니다.
다음은 고객 차원 테이블의 예입니다.
위의 개념을 이해하면 데이터 필드가 소스 자체에서 데이터를 추출하는 동안이 아닌 차원 속성으로 작동 할 수 있는지 여부를 결정할 수 있습니다.
차원에 대한 기본 부하 계획
차원은 두 가지 방법, 즉 외부 소스 시스템에서 차원 데이터를 추출하여 생성 할 수 있습니다 (또는) ETL 시스템은 외부 소스를 사용하지 않고 스테이징에서 차원을 빌드 할 수 있습니다. 그러나 외부 처리가없는 ETL 시스템이 차원 테이블을 작성하는 데 더 적합합니다.
이 프로세스와 관련된 단계는 다음과 같습니다.
자바 배열을 뒤집는 방법
- 데이터 정리 : 일관성을 유지하기 위해 차원 테이블에로드하기 전에 데이터를 정리하고 유효성을 검사하며 비즈니스 규칙을 적용합니다.
- 데이터 준수 : 데이터웨어 하우스의 다른 부분에서 가져온 데이터는 차원 테이블의 각 필드와 관련하여 단일 값으로 적절하게 집계되어야합니다.
- 동일한 도메인 공유 : 데이터가 확인되면 스테이징 테이블에 다시 저장됩니다.
- 데이터 전달 : 마지막으로 모든 차원 속성 값은 기본 / 대리 키가 할당 된 상태로로드됩니다.
치수 유형
참조 용으로 다양한 유형의 치수가 아래에 나열되어 있습니다.
시작하자!!
# 1) 작은 치수
데이터웨어 하우스의 작은 차원은 행과 열 수가 적은 조회 테이블로 작동합니다. 작은 차원의 데이터는 스프레드 시트에서 쉽게로드 할 수 있습니다. 필요한 경우 작은 치수를 슈퍼 치수로 결합 할 수 있습니다.
# 2) 적합 치수
준수 차원은 관련된 모든 사실 테이블에서 동일한 방식으로 참조 할 수있는 차원입니다.
날짜 차원은 연도, 월, 주, 일 등과 같은 날짜 차원의 속성이 여러 사실에 걸쳐 동일한 방식으로 동일한 데이터를 전달하므로 일치 차원의 가장 좋은 예입니다.
Conformed Dimension의 예.
# 3) 정크 차원
플래그 및 표시기와 같은 팩트 테이블의 일부 속성은 별도의 정크 차원 테이블로 이동할 수 있습니다. 이러한 속성은 다른 기존 차원 테이블에도 속하지 않습니다. 일반적으로 이러한 속성의 값은 단순히 '예 / 아니요'(또는) '참 / 거짓'입니다.
모든 개별 플래그 속성에 대해 새 차원을 생성하면 사실 테이블에 더 많은 수의 외래 키를 생성하여 복잡해집니다. 동시에 이러한 모든 플래그와 지표 정보를 팩트 테이블에 보관하면 팩트에 저장된 데이터의 양이 증가하여 성능이 저하됩니다.
따라서이를위한 최상의 솔루션은 정크 차원이 '예 / 아니요'또는 '참 / 거짓'표시기를 보유 할 수 있으므로 단일 정크 차원을 만드는 것입니다. 그러나 정크 차원은 활성 및 보류 등 이러한 표시기에 대한 설명 값 (예 / 아니요 (또는) 참 / 거짓)을 저장합니다.
팩트 테이블의 복잡성과 지표에 따라 팩트 테이블에는 하나 이상의 정크 차원이있을 수 있습니다.
정크 차원의 예.
# 4) 롤 플레잉 차원
팩트 테이블에서 여러 목적으로 참조 할 수있는 단일 차원을 롤 플레잉 차원이라고합니다.
롤 플레잉 차원의 가장 좋은 예는 다시 날짜 차원 테이블입니다. 차원에있는 동일한 날짜 속성은 주문 날짜, 배달 날짜, 거래 날짜, 취소 날짜와 같은 사실에서 다른 목적으로 사용될 수 있습니다. 기타
필요한 경우 팩트 테이블의 4 가지 다른 날짜 속성과 관련하여 날짜 차원 테이블에 4 개의 다른보기를 만들 수 있습니다.
롤 플레잉 차원의 예.
# 5) 차원 퇴화
차원 (메트릭)도 팩트 (측정 값)도 아닐 수 있지만 분석에 필요한 속성은 거의 없습니다. 이러한 모든 속성은 퇴화 차원으로 이동할 수 있습니다.
예를 들면 주문 번호, 송장 번호 등을 퇴화 차원 속성으로 고려할 수 있습니다.
Degenerate Dimension의 예.
# 6) 천천히 변화하는 차원
느리게 변경되는 차원은 데이터가 정기적으로 정기적으로 변경되지 않고 언제든지 느리게 변경 될 수있는 종류입니다. 차원 테이블의 수정 된 데이터는 아래에 설명 된대로 다양한 방식으로 처리 할 수 있습니다.
차원 테이블의 모든 속성에 대해 개별적으로 변경에 응답하도록 SCD 유형을 선택할 수 있습니다.
(i) 유형 1 SCD
- 유형 1에서 차원 속성의 값이 변경된 경우 기존 값은 업데이트 일 뿐인 새로 수정 된 값으로 덮어 씁니다.
- 이전 데이터는 기록 참조를 위해 유지되지 않습니다.
- 이전 데이터가 없기 때문에 이전 보고서를 다시 생성 할 수 없습니다.
- 유지하기 쉽습니다.
- 사실 테이블에 미치는 영향은 더 큽니다.
유형 1 SCD의 예 :
(Ii) 유형 2 SCD
- 유형 2에서는 차원 속성의 값이 변경되면 이전 행 데이터를 변경하지 않고 수정 된 값으로 새 행이 삽입됩니다.
- 팩트 테이블의 이전 레코드에 대한 외래 키 참조가있는 경우 이전 서로 게이트 키는 새 서로 게이트 키로 모든 곳에서 자동으로 업데이트됩니다.
- 위의 단계를 사용하면 팩트 테이블 변경에 미치는 영향이 매우 적습니다.
- 변경 후 이전 데이터는 고려되지 않습니다.
- 유형 2에서는 차원 속성에 발생하는 모든 변경 사항을 추적 할 수 있습니다.
- 기록 데이터의 저장에는 제한이 없습니다.
- 유형 2에서 변경된 날짜, 유효 날짜-시간, 종료 날짜-시간, 변경 이유 및 현재 플래그와 같은 각 행에 몇 가지 속성을 추가하는 것은 선택 사항입니다. 그러나 이는 비즈니스가 특정 기간 동안 변경된 횟수를 알고 자하는 경우 중요합니다.
유형 2 SCD의 예 :
(ii) 유형 3 SCD
- 차원 속성의 값이 변경되면 유형 3에서 새 값이 업데이트되지만 이전 값은 여전히 두 번째 옵션으로 유효합니다.
- 모든 변경 사항에 대해 새 행을 추가하는 대신 이전에 존재하지 않는 새 열이 추가됩니다.
- 이전 값은 위에서 추가 된 속성에 배치되고 기본 속성의 데이터는 유형 1에서와 같이 변경된 값으로 덮어 씁니다.
- 기록 데이터의 저장에는 제한이 있습니다.
- 사실 테이블에 미치는 영향은 더 큽니다.
유형 3 SCD의 예 :
(iv) 유형 4 SCD
- 유형 4에서는 현재 데이터가 하나의 테이블에 저장됩니다.
- 모든 기록 데이터는 다른 테이블에 유지됩니다.
유형 4 SCD의 예 :
(v) 유형 6 SCD
- 차원 테이블에는 유형 6 (또는) 하이브리드 천천히 변화하는 차원으로 알려진 세 가지 SCD 유형 1, 2 및 3의 조합이있을 수도 있습니다.
사실 테이블
팩트 테이블은 계산에 사용되는 정량적으로 측정 된 값 세트를 저장합니다. 팩트 테이블의 값이 비즈니스 보고서에 표시됩니다. 차원 테이블 텍스트 데이터 유형과 달리 사실 테이블 데이터 유형은 상당히 숫자입니다.
사실 테이블은 더 많은 수의 행과 적은 수의 열을 가지므로 사실 테이블은 깊지 만 차원 테이블은 넓습니다. 사실 테이블에 정의 된 기본 키는 주로 각 행을 개별적으로 식별하는 것입니다. 기본 키는 사실 테이블에서 복합 키라고도합니다.
팩트 테이블에서 복합 키가 누락되고 두 레코드에 동일한 데이터가있는 경우 데이터를 구분하고 차원 테이블의 데이터를 참조하기가 매우 어렵습니다.
따라서 적절한 고유 키가 복합 키로 존재하는 경우 각 팩트 테이블 레코드에 대한 시퀀스 번호를 생성하는 것이 좋습니다. 또 다른 대안은 연결된 기본 키를 형성하는 것입니다. 이는 차원 테이블의 참조 된 모든 기본 키를 행 방식으로 연결하여 생성됩니다.
단일 팩트 테이블은 여러 차원 테이블로 둘러싸 일 수 있습니다. 팩트 테이블에 존재하는 외래 키의 도움으로 측정 된 값의 각 컨텍스트 (상세 데이터)를 차원 테이블에서 참조 할 수 있습니다. 쿼리의 도움으로 사용자는 드릴 다운 및 롤업을 효율적으로 수행합니다.
사실 테이블에 저장할 수있는 가장 낮은 수준의 데이터를 Granularity라고합니다. 사실 테이블과 연관된 차원 테이블의 수는 해당 사실 테이블 데이터의 세분성에 반비례합니다. 즉, 가장 작은 측정 값은 더 많은 차원 테이블을 참조해야합니다.
차원 모델에서 팩트 테이블은 차원 테이블과 다 대다 관계를 유지합니다.
판매 팩트 테이블의 예 :
사실 테이블에 대한로드 계획
다음 포인터를 고려하여 사실 테이블 데이터를 효율적으로로드 할 수 있습니다.
# 1) 인덱스 삭제 및 복원
사실 테이블의 인덱스는 데이터를 쿼리하는 동안 좋은 성능 향상 요소이지만 데이터를로드하는 동안 성능을 떨어 뜨립니다. 따라서 대용량 데이터를 팩트 테이블에로드하기 전에 주로 해당 테이블의 모든 인덱스를 삭제하고 데이터를로드하고 인덱스를 복원합니다.
# 2) 업데이트에서 삽입물 분리
팩트 테이블에로드하는 동안 삽입 및 업데이트 레코드를 병합하지 마십시오. 업데이트 수가 적 으면 삽입 및 업데이트를 별도로 처리하십시오. 업데이트 수가 더 많은 경우 빠른 결과를 위해 팩트 테이블을 자르고 다시로드하는 것이 좋습니다.
# 3) 파티셔닝
벌크 팩트 테이블의 데이터에 대한 더 나은 쿼리 성능을 위해 팩트 테이블에서 물리적으로 미니 테이블로 분할을 수행합니다. DBA와 ETL 팀을 제외하고는 아무도 사실의 파티션을 인식하지 못할 것입니다.
로 예 , 테이블을 월 단위, 분기 단위, 연 단위 등으로 분할 할 수 있습니다. 쿼리하는 동안 전체 테이블을 스캔하는 대신 분할 된 데이터 만 고려됩니다.
# 4) 병렬로드
자바 인터뷰 코딩 질문 및 답변
이제 팩트 테이블의 파티션에 대한 아이디어를 얻었습니다. 사실에 대한 파티션은 방대한 데이터를 사실에로드하는 동안에도 유용합니다. 이를 수행하려면 먼저 데이터를 논리적으로 다른 데이터 파일로 나누고 ETL 작업을 실행하여 데이터의 모든 논리적 부분을 병렬로로드하십시오.
# 5) 벌크로드 유틸리티
다른 RDBMS 시스템과 달리 ETL 시스템은 중간 트랜잭션 실패에 대해 명시 적으로 롤백 로그를 유지할 필요가 없습니다. 여기서 '대량로드'는 'SQL 삽입'대신 팩트에 발생하여 방대한 데이터를로드합니다. 단일로드가 실패하는 경우 전체 데이터를 쉽게 다시로드 할 수 있습니다 (또는 대량로드로 중단 된 위치에서 계속할 수 있습니다).
# 6) 사실 기록 삭제
사실 테이블 레코드 삭제는 비즈니스가 명시 적으로 원하는 경우에만 발생합니다. 소스 시스템에 더 이상 존재하지 않는 팩트 테이블 데이터가있는 경우 해당 데이터를 물리적으로 (또는) 논리적으로 삭제할 수 있습니다.
- 물리적 삭제 : 원하지 않는 레코드는 사실 테이블에서 영구적으로 제거됩니다.
- 논리적 삭제 : 비트 (또는) 부울 유형의 '삭제됨'과 같은 새 열이 사실 테이블에 추가됩니다. 이것은 삭제 된 레코드를 나타내는 플래그 역할을합니다. 사실 테이블 데이터를 쿼리하는 동안 삭제 된 레코드를 선택하지 않았는지 확인해야합니다.
# 7) 팩트 테이블에서 업데이트 및 삭제 순서
업데이트 할 데이터가있는 경우 차원 테이블을 먼저 업데이트 한 다음 필요한 경우 검색 테이블에서 대리 키를 업데이트하고 그 후에 각 팩트 테이블을 업데이트해야합니다. 사실 테이블에서 원치 않는 모든 데이터를 삭제하면 차원 테이블에서 링크 된 원치 않는 데이터를 쉽게 삭제할 수 있으므로 삭제는 역순으로 발생합니다.
차원 테이블과 팩트 테이블은 항상 참조 무결성을 유지하므로 두 경우 모두 위의 순서를 따라야합니다.
사실의 유형
팩트 테이블 데이터의 동작을 기반으로 트랜잭션 팩트 테이블, 스냅 샷 팩트 테이블 및 누적 된 스냅 샷 팩트 테이블로 분류됩니다. 이 세 가지 유형은 모두 서로 다른 데이터로드 전략으로 서로 다른 기능을 따릅니다.
# 1) 거래 사실 테이블
이름에서 알 수 있듯이 트랜잭션 팩트 테이블은 발생하는 각 이벤트에 대한 트랜잭션 수준 데이터를 저장합니다. 이러한 종류의 데이터는 팩트 테이블 수준 자체에서 쉽게 분석 할 수 있습니다. 그러나 추가 분석을 위해 관련 차원을 참조 할 수도 있습니다.
예를 들면 마케팅 웹 사이트에서 발생하는 모든 판매 (또는) 구매는 거래 사실 테이블에로드되어야합니다.
트랜잭션 팩트 테이블의 예는 다음과 같습니다.
# 2) 주기적 스냅 샷 팩트 테이블
이름에서 알 수 있듯이 주기적 스냅 샷 팩트 테이블의 데이터는 비즈니스 요구에 따라 매일, 주, 월, 분기 등과 같은주기적인 간격으로 스냅 샷 (사진) 형태로 저장됩니다.
따라서 이것이 항상 데이터의 집합이라는 것이 분명합니다. 따라서 스냅 샷 팩트는 트랜잭션 팩트 테이블에 비해 더 복잡합니다. 예를 들면 모든 성능 수익 보고서 데이터는 쉽게 참조 할 수 있도록 스냅 샷 팩트 테이블에 저장할 수 있습니다.
주기적 스냅 샷 사실 테이블의 예가 아래에 나와 있습니다.
# 3) 스냅 샷 팩트 테이블 누적
스냅 샷 팩트 테이블을 누적하면 제품의 전체 수명 동안 데이터를 테이블에 저장할 수 있습니다. 이는 언제든지 모든 이벤트에 의해 데이터가 스냅 샷으로 삽입 될 수있는 위의 두 가지 유형의 조합으로 작동합니다.
이 유형에서는 각 행에 대한 추가 날짜 열과 데이터가 해당 제품의 모든 이정표로 업데이트됩니다.
누적 스냅 샷 팩트 테이블의 예.
위의 세 가지 유형 외에도 다음과 같은 몇 가지 다른 유형의 팩트 테이블이 있습니다.
# 4) 사실이없는 사실 테이블 : 팩트는 측정 값의 모음 인 반면 팩트리스는 측정 값이 포함되지 않은 이벤트 (또는) 조건 만 캡처합니다. 사실이없는 사실 테이블은 주로 시스템을 추적하는 데 사용됩니다. 이 테이블의 데이터를 분석하여보고에 사용할 수 있습니다.
예를 들면 1 년 동안 휴가를 낸 직원의 세부 사항과 휴가 유형 등을 찾을 수 있습니다. 이러한 모든 불명확 한 사실 세부 사항을 사실에 포함하여 테이블은 확실히 사실의 크기를 늘릴 것입니다.
Factless Fact Table의 예는 다음과 같습니다.
# 5) 준수 된 사실 테이블 : 일치 된 사실은 관련된 모든 데이터 마트에서 동일한 방식으로 참조 할 수있는 사실입니다.
사실 테이블의 사양
다음은 팩트 테이블의 사양입니다.
- 사실 이름 : 팩트 테이블의 기능을 간략하게 설명하는 문자열입니다.
- 비즈니스 프로세스 : 해당 팩트 테이블을 통해 비즈니스를 수행해야한다고 말합니다.
- 질문 : 해당 팩트 테이블에서 답변 할 비즈니스 질문 목록을 언급합니다.
- 곡물: 해당 사실 테이블 데이터와 관련된 가장 낮은 수준의 세부 정보를 나타냅니다.
- 치수: 해당 사실 테이블과 연관된 모든 차원 테이블을 나열하십시오.
- 측정: 사실 테이블에 저장된 계산 된 값입니다.
- 부하 주파수 팩트 테이블에 데이터를로드하는 시간 간격을 나타냅니다.
- 초기 행 : 처음으로 사실 테이블에 채워진 초기 데이터를 참조하십시오.
차원 데이터 모델링의 예
판매 및 주문에 대한 아래의 차원 데이터 모델링 다이어그램을 살펴보면 시스템에 대해 차원 테이블과 팩트 테이블을 디자인하는 방법에 대한 아이디어를 얻을 수 있습니다.
결론
지금 쯤이면 차원 데이터 모델링 기술, 이점, 통념, 차원 테이블, 사실 테이블, 유형 및 프로세스에 대한 뛰어난 지식을 얻었을 것입니다.
데이터웨어 하우스 스키마에 대해 자세히 알아 보려면 다가오는 자습서를 확인하십시오 !!
=> 처음부터 데이터웨어 하우징에 대해 알아 보려면 여기를 방문하십시오.