비즈니스 객체에 대한 책을 읽을 때 용어 테이블과 차원 테이블을 발견했습니다.
차원 테이블과 팩트 테이블의 차이점을 이해하려고합니다.
인터넷에서 기사를 몇 개 읽었지만 명확하게 이해할 수 없었습니다 ..
간단한 예가 내가 더 잘 이해하는 데 도움이 될까요?
답변:
이것은 부분에 대한 대답입니다.
차원 테이블이 사실 테이블이 될 수 있는지 여부를 이해하려고 했습니까?
단답형 (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의 예에 대한 의견에 답하려면 :
판매 사실 (ID, BranchID, SalesPersonID, ItemID, Amount, TimeID)
AggregatedSales (BranchID, TotalAmount)
여기서 관계는 4NF에 있습니다.
마지막 예는 드문 경우입니다.
데이터웨어 하우스 모델링에서 스타 스키마 와 눈송이 스키마 는 팩트 및 차원 테이블 로 구성됩니다 .
사실 테이블 :
차원 테이블 :
이것은 팩트 테이블과 차원 테이블을 구별하는 방법에 대한 매우 간단한 대답 인 것 같습니다!
차원을 사물이나 사물로 생각하면 도움이 될 수 있습니다. 제품과 같은 것은 비즈니스 이벤트에 참여하지 않고도 존재할 수 있습니다. 차원은 당신의 명사입니다. 판매와 같은 비즈니스 이벤트와 독립적으로 존재할 수있는 것입니다. 제품, 직원, 장비는 모두 존재합니다. 차원은 무언가를하거나 무언가를합니다.
직원은 판매하고 고객은 구매합니다. 직원과 고객은 차원의 예입니다.
제품이 판매되고, 제품에 어떤 조치를 취한 치수이기도합니다.
사실은 동사입니다. 팩트 테이블의 항목은 차원 테이블의 항목에 발생하는 불연속 이벤트를 표시합니다. 제품 판매는 팩트 테이블에 기록됩니다. 판매 이벤트는 판매 된 제품, 판매 한 직원, 구매 한 고객으로 표시됩니다. 제품, 직원 및 고객은 모두 이벤트, 판매를 설명하는 차원입니다.
또한 팩트 테이블에는 일반적으로 일종의 정량적 데이터가 있습니다. 판매 수량, 품목 당 가격, 총 가격 등.
출처 : http://arcanecode.com/2007/07/23/dimensions-versus-facts-in-data-warehousing/
이 답변은 DB / DW 용어를 잘 모르는 사람의 관점에서 이해하기 더 쉽다는 것을 알았습니다.
http://databases.about.com/od/datamining/a/Facts-Vs-Dimensions.htm
먼저 이것을 살펴본 다음 더 세분화하기 위해 Emmad Kareem의 답변을 살펴 보는 것이 좋습니다. 도움이 되었기를 바랍니다.
가장 간단한 형태로 차원 테이블은 모든 '항목'목록을 유지하는 '마스터'테이블과 비슷하다고 생각합니다.
사실 테이블은 모든 트랜잭션을 설명하는 트랜잭션 테이블입니다. 또한 영업 사원 별 총 판매량, 지점 별 총 판매량과 같은 집계 된 (그룹화 된) 데이터-이러한 종류의 테이블도 독립적 인 팩트 테이블로 존재할 수 있습니다.
더 읽기 : 차원 테이블 및 사실 테이블 | 차이점 | 차원 테이블 대 사실 테이블 http://www.differencebetween.net/technology/hardware-technology/dimension-table-and-fact-table/#ixzz3SBp8kPzo
차원 테이블 : 차원 테이블이라고하는 특성화 된 날짜에 대한 정보를 유지할 수 있습니다.
예 : 시간 차원, 제품 차원.
Fact Table : 그것은 아무것도 아니지만 우리는 메트릭 또는 사전 계산 데이터에 대한 정보를 유지할 수 있습니다.
예 : 판매 사실, 주문 사실.
스타 스키마 : 시작 스키마로 차원 테이블 양식이있는 하나의 팩트 테이블 링크.