ChatGPT解决这个技术问题 Extra ChatGPT

事实表和维度表之间的区别?

在阅读有关业务对象的书籍时,我遇到了术语事实表和维度表。

我想了解维度表和事实表之间的区别是什么?

我在互联网上阅读了几篇文章,但我无法清楚地理解..

有什么简单的例子可以帮助我更好地理解吗?

这个概念比较长,无法详细描述,如果您有超出基本定义的具体问题,请告诉我们。
基本上,我试图了解维度表是否也可以是事实表?

P
Premraj

在数据仓库建模中,星型模式和雪花模式由事实表和维度表组成。

事实表:

它包含维度的所有主键和相关的事实或度量(是可以进行计算的属性),如销售量、销售量和平均销售量。

尺寸表:

维度表为事实表中记录的所有测量提供描述性信息。

与事实表相比,维度相对非常小。

常用的维度是人、产品、地点和时间。

https://i.stack.imgur.com/aB9k9.jpg

image source


这比公认的答案更有帮助
嗯,一张图抵得上一千个字。阅读其他答案时,我什么都不懂,但是这个答案救了我。
与图中的事实表相比,维度看起来相对较大,因为它具有更多描述性数据。而且他们的人数也更多
@Blue Clouds:您必须意识到事实表包含一个条目,用于每个可能的暗淡组合(如果有数据,至少)。虽然位置维度最多包含每个可能位置的条目(例如 50 个销售点)并且很少增长,但当添加新 pos 时,Facts 表可能会每天按位置 x 项目 x 分支增长。因此,事实将很快获得大量记录。
@Kalana,是的,事实表可以在没有主键的情况下存在。例如,如果他/她在同一天/同一地点/同一数量两次订购,则包含列、cust_id、date_ordered、qty、时间、位置的销售表可以具有相同的所有记录。
A
AeyJey

这似乎是一个关于如何区分事实表和维度表的非常简单的答案!

将维度视为事物或对象可能会有所帮助。诸如产品之类的事物可以在不涉及商业事件的情况下存在。维度是你的名词。它可以独立于商业事件(例如销售)而存在。产品、员工、设备,都是存在的东西。维度要么做某事,要么对其做了一些事情。员工卖,客户买。员工和客户是维度的例子,他们确实如此。产品被出售,它们也是维度,因为它们对它们做了一些事情。事实,是动词。事实表中的条目标记发生在维度表中的某事上的离散事件。产品销售将记录在事实表中。销售事件将通过售出什么产品、哪个员工售出以及哪个客户购买来记录。产品、员工和客户都是描述事件、销售的维度。此外,事实表通常还具有某种定量数据。售出的数量、每件商品的价格、总价等。

来源:http://arcanecode.com/2007/07/23/dimensions-versus-facts-in-data-warehousing/


写得很好,只需要5分钟就可以理解这个概念。
总而言之:维度是事实事件的属性。达菲。你在做什么,达菲?
是的,这就是我记得他们的方式。这和你想的相反。你会认为事实是一成不变的,维度是动态的,基于单词本身。但是,恰恰相反:一个基本的暗表是一个相当静态的查找列表,一个基本的事实表是正在输入的活数据。
这是我最喜欢的解释,让它在我脑海中响起,谢谢!
S
Stephen Turner

这是回答部分:

我试图了解维度表是否也可以是事实表?

简短的回答 (INMO) 是否定的。那是因为这两种类型的表是出于不同的原因创建的。但是,从数据库设计的角度来看,维度表可以有一个父表,就像事实表一样,事实表总是有一个(或更多)维度表作为父表。此外,事实表可以聚合,而维度表不聚合。另一个原因是事实表不应该就地更新,而维度表在某些情况下可以就地更新。

更多细节:

事实表和维度表以通常称为星型模式的形式出现。星型模式的主要目的是简化一组复杂的规范化表,并将数据(可能来自不同系统)整合到一个可以以非常有效的方式查询的数据库结构中。

在其最简单的形式中,它包含一个事实表(例如:StoreSales)和一个或多个维度表。每个维度条目都有 0,1 个或更多与之关联的事实表(维度表示例:地理、项目、供应商、客户、时间等)。维度具有父级也是有效的,在这种情况下,模型的类型为“Snow Flake”。然而,设计师试图避免这种设计,因为它会导致更多的连接,从而降低性能。在 StoreSales 的示例中,Geography 维度可以由列(GeoID、ContentName、CountryName、StateProvName、CityName、StartDate、EndDate)组成

在雪花模型中,您可以有 2 个用于地理信息的标准化表,即:内容表、国家表。

您可以在 Star Schema 上找到大量示例。此外,请查看此内容以查看星型模式模型 Inmon vs. Kimball 的替代视图。 Kimbal 有一个不错的论坛,您可能还想在这里查看:Kimball Forum

编辑:回答有关 4NF 示例的评论:

违反 4NF 的事实表示例:

销售资料(ID、BranchID、SalesPersonID、ItemID、Amount、TimeID)

不违反 4NF 的事实表示例:

AggregatedSales (BranchID, TotalAmount)

这里的关系是 4NF

最后一个例子比较少见。


一些事实表反映事务级数据。有些反映了汇总数据。星型模式中的事实表甚至不必在 3NF 中。例如,Sales Fact 可能包含诸如(ID、BranchID、Amount、SalesPerson、Time)之类的数据——这违反了 3NF、BCNF 和 4NF,因为 SalesPerson 和 Branch 依赖关系。因此,典型的事实表在 4NF 中是不正确的。
R
RelativitySQL

超级简单的解释:

事实表:将查找 ID 映射在一起的数据表。通常是您的应用程序的主要表之一。

维度表:用于存储事实表中经常重复的值(如城市名称或州)的查找表。


S
Shriraj

维度表 维度表是包含存储在事实表中的测量属性的表。该表由可用于遍历节点的层次结构、类别和逻辑组成。

事实表包含业务流程的度量,它包含维度表的外键。

示例 – 如果业务流程是制造砖块

一个人/一台机器生产的砖块的平均数量——业务流程的衡量标准


u
user5729371

在最简单的形式中,我认为维度表类似于“主”表——可以说,它保留了所有“项目”的列表。

事实表是描述所有事务的事务表。此外,聚合(分组)数据,如销售人员的总销售额、分公司的总销售额——这类表也可能作为独立的事实表存在。


d
dz902

事实 = 行动:销售、交易、访问

Dimension = 一个对象:卖家、客户、日期、价格

然后...

事实参考维度:何时、何地、什么、谁、如何

真正有趣的是决定一个属性应该是一个维度还是一个事实。例如,订单中每件商品的价格,或合同中记录的最高保险金额。没有一般正确的方法来处理这些,只有在上下文中有意义的方法。

PS:如果我要创建这些行话,我会更喜欢 Log 表和 Object 表。


A
AbcAeffchen

事实表主要由业务事实和引用维度表中主键的外键组成。维度表主要由作为文本字段的描述性属性组成。维度表包含代理键、自然键和一组属性。相反,事实表包含外键、度量和退化维度。维度表为事实表的测量提供描述性或上下文信息。另一方面,事实表提供了企业的度量。比较两个表的大小时,事实表大于维度表。在比较表中,显示的维度比事实表多。在事实表中,观察到的事实数量较少。必须先加载维度表。在加载事实表时,应该查看维度表。这是因为事实表具有度量、事实和外键,它们是维度表中的主键。

阅读更多:维度表和事实表 |之间的区别|维度表与事实表 http://www.differencebetween.net/technology/hardware-technology/dimension-table-and-fact-table/#ixzz3SBp8kPzo


这是一个写得很好的答案。
K
Karthick Annamalai

在我看来,我的观点是,

维度表:主数据

事实表:交易数据


多年来,我也使用“主数据”和“交易数据”,我认为它们在语言上更明显地说明了这些词的含义。
S
Samir Malik

对于关系数据库用户,Dimension 相当于 Master Table。 Fact 等价于事务表。


正如目前所写的那样,您的答案尚不清楚。请edit添加其他详细信息,以帮助其他人了解这如何解决所提出的问题。您可以找到有关如何写出好答案的更多信息in the help center
M
Maheshwar Reddy

维度表:它只是我们可以维护有关称为维度表的特征日期的信息。

示例:时间维度、产品维度。

事实表:它只是我们可以维护有关指标或预计算数据的信息。

示例:销售事实、订单事实。

星型模式:一个以维度表形式作为起始模式的事实表链接。

enter image description here


(此帖子似乎没有为问题提供 quality answer。请编辑您的答案,或将其作为对该问题的评论发布)。