사실 테이블과 차원 테이블의 차이점은 무엇입니까?
비즈니스 객체에 대한 책을 읽을 때 용어 테이블과 차원 테이블을 발견했습니다.
차원 테이블과 팩트 테이블의 차이점을 이해하려고합니다.
인터넷에서 기사를 몇 개 읽었는데 명확하게 이해할 수 없었습니다 ..
간단한 예가 내가 더 잘 이해하는 데 도움이 될까요?
이것은 부분에 대한 대답입니다.
차원 테이블이 사실 테이블이 될 수 있는지 여부를 이해하려고 했습니까?
단답형 (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에 있습니다.
마지막 예는 드문 경우입니다.
데이터웨어 하우스 모델링에서 스타 스키마 와 눈송이 스키마 는 팩트 및 차원 테이블 로 구성됩니다 .
사실 테이블 :
- 여기에는 차원의 모든 기본 키와 판매 수량, 판매량 및 평균 판매와 같은 관련 사실 또는 측정 값 (계산할 수있는 속성)이 포함됩니다.
차원 테이블 :
- 차원 테이블은 팩트 테이블에 기록 된 모든 측정에 대한 설명 정보를 제공합니다.
- 차원은 팩트 테이블에 비해 상대적으로 매우 작습니다.
- 일반적으로 사용되는 차원은 사람, 제품, 장소 및 시간입니다.
이것은 팩트 테이블과 차원 테이블을 구별하는 방법에 대한 매우 간단한 대답 인 것 같습니다!
It may help to think of dimensions as things or objects. A thing such as a product can exist without ever being involved in a business event. A dimension is your noun. It is something that can exist independent of a business event, such as a sale. Products, employees, equipment, are all things that exist. A dimension either does something, or has something done to it.
Employees sell, customers buy. Employees and customers are examples of dimensions, they do.
Products are sold, they are also dimensions as they have something done to them.
Facts, are the verb. An entry in a fact table marks a discrete event that happens to something from the dimension table. A product sale would be recorded in a fact table. The event of the sale would be noted by what product was sold, which employee sold it, and which customer bought it. Product, Employee, and Customer are all dimensions that describe the event, the sale.
In addition fact tables also typically have some kind of quantitative data. The quantity sold, the price per item, total price, and so on.
Source: http://arcanecode.com/2007/07/23/dimensions-versus-facts-in-data-warehousing/
I found this answer easier to understand from the perspective of a person who does not know much of the DB/DW terminology.
http://databases.about.com/od/datamining/a/Facts-Vs-Dimensions.htm
I'll recommend going through this first and then going through Emmad Kareem's answer for more granularity. Hope it's helpful.
Super simple explanation:
Fact table: a data table that maps lookup IDs together. Is usually one of the main tables central to your application.
Dimension table: a lookup table used to store values (such as city names or states) that are repeated frequently in the fact table.
- The fact table mainly consists of business facts and foreign keys that refer to primary keys in the dimension tables. A dimension table consists mainly of descriptive attributes that are textual fields.
- A dimension table contains a surrogate key, natural key, and a set of attributes. On the contrary, a fact table contains a foreign key, measurements, and degenerated dimensions.
- Dimension tables provide descriptive or contextual information for the measurement of a fact table. On the other hand, fact tables provide the measurements of an enterprise.
- When comparing the size of the two tables, a fact table is bigger than a dimensional table. In a comparison table, more dimensions are presented than the fact tables. In a fact table, less numbers of facts are observed.
- The dimension table has to be loaded first. While loading the fact tables, one should have to look at the dimension table. This is because the fact table has measures, facts, and foreign keys that are the primary keys in the dimension table.
Read more: Dimension Table and Fact Table | Difference Between | Dimension Table vs Fact Table http://www.differencebetween.net/technology/hardware-technology/dimension-table-and-fact-table/#ixzz3SBp8kPzo
In the simplest form, I think a dimension table is something like a 'Master' table - that keeps a list of all 'items', so to say.
A fact table is a transaction table which describes all the transactions. In addition, aggregated (grouped) data like total sales by sales person, total sales by branch - such kinds of tables also might exist as independent fact tables.
Dimension table : It is nothing but we can maintains information about the characterized date called as Dimension table.
Example : Time Dimension , Product Dimension.
Fact Table : It is nothing but we can maintains information about the metrics or precalculation data.
Example : Sales Fact, Order Fact.
Star schema : one fact table link with dimension table form as a Start Schema.
참고 URL : https://stackoverflow.com/questions/20036905/difference-between-fact-table-and-dimension-table
'Program Club' 카테고리의 다른 글
| 로컬 저장소에서 업스트림을 제거하는 힘내 (0) | 2020.11.03 |
|---|---|
| Flask에서 매시간 실행되도록 함수 예약 (0) | 2020.11.03 |
| PostgreSQL : 두 날짜 사이의 일 / 월 / 년 (0) | 2020.11.02 |
| 새 Firebase로 업데이트 한 후 예외 java.lang.NoClassDefFoundError : com.google.firebase.FirebaseOptions 발생 (0) | 2020.11.02 |
| 설치에서 세션을 완료하지 못했습니다. 서명이 일치하지 않습니다.-Android (0) | 2020.11.02 |
