[database] 사실 테이블과 차원 테이블의 차이점은 무엇입니까?

이것은 부분에 대한 대답입니다.

차원 테이블이 사실 테이블이 될 수 있는지 여부를 이해하려고 했습니까?

단답형 (INMO)은 ‘아니요’로 두 가지 유형의 테이블이 서로 다른 이유로 생성되기 때문입니다. 그러나 데이터베이스 디자인 관점에서 차원 테이블은 항상 차원 테이블 (또는 그 이상)을 상위로 갖는 팩트 테이블의 경우와 같이 상위 테이블을 가질 수 있습니다. 또한 팩트 테이블은 집계 될 수 있지만 차원 테이블은 집계되지 않습니다. 또 다른 이유는 팩트 테이블이 제자리에서 업데이트되지 않아야하는 반면 차원 테이블은 경우에 따라 제자리에서 업데이트 될 수 있기 때문입니다.

자세한 내용은:

팩트 및 차원 테이블은 일반적으로 스타 스키마라고하는 항목에 나타납니다. 스타 스키마의 주요 목적은 복잡한 정규화 된 테이블 집합을 단순화하고 데이터 (다른 시스템의 데이터)를 매우 효율적인 방식으로 쿼리 할 수있는 하나의 데이터베이스 구조로 통합하는 것입니다.

가장 단순한 양식에는 사실 테이블 (예 : StoreSales)과 하나 이상의 차원 테이블이 포함됩니다. 각 차원 항목에는 0,1 개 이상의 팩트 테이블이 연결되어 있습니다 (차원 테이블의 예 : 지역, 품목, 공급자, 고객, 시간 등). 치수에 상위가있는 경우에도 유효합니다.이 경우 모델은 “Snow Flake”유형입니다. 그러나 디자이너는 이러한 종류의 디자인을 피하려고합니다. 더 많은 조인이 발생하여 성능이 저하되기 때문입니다. StoreSales의 예에서 Geography 차원은 열 (GeoID, ContenentName, CountryName, StateProvName, CityName, StartDate, EndDate)으로 구성 될 수 있습니다.

Snow Flakes 모델에서는 지리 정보에 대해 2 개의 정규화 된 테이블, 즉 Content Table, Country Table을 가질 수 있습니다.

Star Schema에서 많은 예제를 찾을 수 있습니다. 또한 스타 스키마 모델 Inmon 대 Kimball 에 대한 대체보기를 보려면 이것을 확인하십시오 . Kimbal에는 좋은 포럼이 있습니다. Kimball Forum .

편집 : 4NF의 예에 대한 의견에 답하려면 :

• 4NF를 위반하는 사실 테이블의 예 :

판매 사실 (ID, BranchID, SalesPersonID, ItemID, Amount, TimeID)

• 4NF를 위반하지 않는 팩트 테이블의 예 :

AggregatedSales (BranchID, TotalAmount)

여기서 관계는 4NF에 있습니다.

마지막 예는 드문 경우입니다.

---

답변