비즈니스 개체에 대한 책을 읽는 동안 용어 팩트 테이블과 차원 테이블이 나타났습니다. 이것이 모든 팩트 테이블과 차원 테이블을 가지고 있거나 비즈니스 객체 디자인만을위한 모든 데이터베이스의 표준 것입니까? 나는 둘 사이의 차별화 된 설명과 그들이 어떻게 관련되어 있는지를 찾고있다.데이터베이스 - 팩트 테이블 및 차원 테이블
편집 :
왜 쿼리 그냥 팩트 테이블에서 필요한 데이터를 얻을 수없는 이유는 무엇입니까? 모든 정보가 하나의 사실 테이블에만 저장되면 어떻게됩니까? 별도의 팩트 및 차원 테이블을 만들고 결합하면 어떤 장점이 있습니까?
한 번에 너무 많은 질문을 드려 죄송합니다.하지만 관계와 소음에 대해 알고 싶습니다.
Dimension 및 Fact은 OLAP 데이터베이스 디자인의 핵심 용어입니다.
그들은 이러한 개념 (예를 들어 Microsft SSAS, Tableau Software)과 언어 (예. MDX)와 함께 작동 BI 도구 많이 있습니다.
데이터가 측정 값 또는 측정 값인지 알기가 때로는 쉽지 않습니다..
net profit, overheads, interestprofit 및 1 차원 : profit type (3 개 요소 예를 들어, 우리가 revenue 분석하고, 어떤 경우 든 possibles이다 : 순수익, 간접비,이자)BI 분석가 i 누가 각 솔루션에 가장 적합한 설계인지 결정합니다.
때문에 또한 편집중인 질문에 편집 :
하여 OLAP 솔루션은 일반적으로 의미 계층이있다. 이 계층은 OLAP 도구에 어떤 요소가 사실 데이터인지, 어떤 요소가 차원 데이터 및 테이블 관계인지에 대한 정보를 제공합니다.OLTP 시스템과 달리 OLAP 데이터베이스가 적절하게 표준화 될 필요는 없습니다. 이러한 이유로 팩트 테이블을 비롯한 여러 테이블에서 차원 데이터를 가져올 수 있습니다. 팩트 테이블에서 데이터를 가져 오는 차원의 이름은 Fact Dimension or Degenerate dimension입니다. "스타 스키마", "눈송이 스키마", "대리 키", "부모 - 자식 계층 구조를"...
데이터웨어 하우스에서 팩트 테이블과 차원 테이블을 갖는 표준입니다. 팩트 테이블에는 측정하려는 데이터 (예 : 합계)가 들어 있습니다. 차원 테이블은 제품 데이터, 상태, 고객 등과 같이 팩트 테이블에서 지속적으로 반복하지 않으려는 데이터가 포함 된 테이블입니다. 키와 관련이 있습니다. 스타 스키마에서 팩트 테이블의 각 행 차원 테이블에 행의 키가 들어 있습니다.
않습니다
그들은 OLAP 데이터베이스를 설계 할 때 염두에 두어야 할 개념이 많이 있습니다 이는 데이터베이스 디자이너가 데이터베이스를 설계 할 때 팩트 테이블과 차원 테이블을 따로 생성해야한다는 것을 의미합니다. –
예, 별도로 만듭니다. 사실 테이블에 모든 차원 데이터가있는 경우 사실 테이블은 필요한 것보다 훨씬 더 커집니다. 데이터웨어 하우스는 비정규 화되어야하지만 테이블 하나만 남겨두면 정규화되지 않아야합니다. –
내 업데이트 된 질문을 참조하십시오. 지금까지 귀하의 답변에 감사 드리며 조금 더 알고 싶습니다. –
답을 다시 읽으십시오. – danihp