1

我是维度建模的新手，我正在为一所大学做维度模型。我掌握的当前业务流程实际上是销售/收入。我一直在阅读不同书籍的不同章节，虽然我认为我对事实和维度有很好的理解，但我很难将销售过程与论文相适应。

理想情况下，学校的销售过程类似于其他企业，学生是客户，产品是他们学习的“课程”。但是在某些情况下有不同的产品类型，我不知道如何适应产品类型。例如，学生支付与任何课程无关的申请费、滞纳金或成绩单申请费。如何在我的明星中适应这些不同类型的收入流？

到目前为止我所做的是这样的

Sales_FACT
====
Date_Key_FK
Product_Key_FK
Campus_Key_FK
Student_Key_FK
ChargeCredit_SKU
Amount


Product_Key
------
Product_Key_PK
SectionID
AcademicYear
AcademicTerm
AcademicSession
CourseCode
CourseName
ProductType???

现在对于某些类型的产品（例如成绩单申请费）——我没有课程名称、代码、学期、课程——我正在努力解决这个问题。

有人对此有任何意见吗？或任何有用的材料/模式示例肯定会欣赏它们

谢谢，

4

1 回答 1

1

将来你会发现很多这样的案例。通常，您遇到此问题是因为您正在混合两种不同类型的“产品”。

它可以从逻辑上或技术上解决。

在 ETL 过程中，在清理步骤中，您可以使用与字段相关的 sql (nvl, coalesce, CASE WHEN) 重写您的空字段

nvl(CourseCode, 'No Course Code') as CourseCode

然后，当您按 ProductType 和 CourseName 分组时，您应该得到如下信息：

ProductType     CourseName     sum(Amount)
------------------------------------------
AppFee          Course1             345.13
AppFee          Course4            8901.00
TranscriptFee   No Course Name      245.99

或者，您可以将其放在单独的表格中。即使这与您的业务流程相矛盾（实际上不能有不同的产品行），有时您想要合并的术语（即 ApplicationFee 和 TranscriptFee）有许多不同的分组级别，这通常很难映射。

编辑：

不，当存在大维度表、高基数、多层次以及多对多关系（即电影、类别）时，雪花是有意义的。在您的情况下，好主意是遵循 ERP/CRM 数据库设计，因为它是当前有效的解决方案。如果没有您想要的此类报告可能性，您可以制作更通用的维度表：

Product-Service Dimension
--------------------------------------------
SurogateKey
NaruralKey
Type(Product/Sevrice/Other)
Level1(ProductType/ServiceType)
Level2(ProductSubType/ServiceSubType)
Level3
Level4
Attribute1
Attribute2
于 2014-08-20T01:28:15.383 回答