我是数据仓库的新手,我一直在阅读有关这些原则的文章和视频,但我对如何采用下面的设计并将其转换为星型模式感到有些困惑。在这个例子中,我假设事实表是 (order-orderitem-book) 而度量是 (category-customer-time) 我的问题是关于书籍作者我们如何把它作为度量?是否允许在星型模式中放置多对多关系?如果我错了,如何将星型模式绘制到这个关系数据库?
我是数据仓库的新手,我一直在阅读有关这些原则的文章和视频,但我对如何采用下面的设计并将其转换为星型模式感到有些困惑。在这个例子中,我假设事实表是 (order-orderitem-book) 而度量是 (category-customer-time) 我的问题是关于书籍作者我们如何把它作为度量?是否允许在星型模式中放置多对多关系?如果我错了,如何将星型模式绘制到这个关系数据库?
您可以在数据仓库中放置多对多关系,但许多人认为这样做是不好的做法——即使某些数据仓库工具根本不允许创建它。以下是我如何根据您的设计创建星型模式:
由于您的
Author
表格和Category
表格只有一个有价值的属性(名称),因此我会将它们滚动到Book
表格中,然后该表格将成为您的第一个维度。Customer
表格可以保持原样,也可以成为一个维度。然后,您可以将这两个Order
表合二为一,并创建一个Order
包含OrderID
,Date
,BookID
,CustomerID
,Price
- 的事实表,如下所示:您可能还想考虑一个
Date
在星型模式和数据仓库中也常见的维度,以便更轻松地按日期搜索。一个非常基本的实现如下:然后,只需将
Date
事实表中属性的外键添加到表中的Date
键中DimDate
。这会产生类似的东西:如果您需要处理一本书可能有许多作者的情况(这种情况经常发生),有几种方法可以做到这一点。
第一个,也是我的建议,是让所有作者都在
Author
属性内。这将允许您轻松搜索由相同作者组合撰写的所有书籍。第二种方法将
Author
属性非规范化为它自己的维度,然后由书籍维度引用。这将创建一个雪花模式(您的问题表明您想要一个星型模式,所以我避免了这种方法)并且在尝试由多个作者搜索时也会变慢。最终,这取决于您的确切需求和您试图满足的要求。我个人会坚持让所有作者都具有相同的属性,因为这是最简单的设计并且符合您的星型模式要求。
所以你的问题是几个不同的问题 -
Author
不应该是它自己的维度,它只是Book
维度的一个属性。因为事实表的主键是由一组外键组成的复合键,所以每个具有多对多关系的表都必须表示为事实表。您将不得不使用桥接表,但实现这一点的最佳方式取决于您的需要。
我认为你的方法没有错,但只是为了帮助你澄清你在做什么,你会想要
Order
一个事实表,并且Book
(我将作为属性移动并进入)Author
(或与彼此)并在您的示例中作为尺寸。您所有的定量数据(除了)都应该进入,所有描述性和定性数据都应该进入您周围的维度。Category
DateTime
Date
Time
Customer
DateTime
Order