标签: dimensional-modeling

Star-Schema设计对数据仓库至关重要吗？或者您可以使用其他设计模式进行数据仓库吗？

我来自SQL Datawarehouse世界,从平面Feed我生成维度和事实表.在一般数据仓库项目中,我们将Feed分为事实和维度.例如:

我是Hadoop的新手,我开始知道我可以在hive中构建数据仓库.现在,我熟悉使用guid,我认为它适用于蜂巢中的主键.那么,下面的策略是在hive中加载事实和维度的正确方法？

1. 将源数据加载到配置单元表中; 比方说Sales_Data_Warehouse

2. 从sales_data_warehouse生成维度; 例如:

   从Sales_Data_Warehouse中选择New_Guid(),Customer_Name,Customer_Address

3. 完成所有维度后,再加载事实表

   SELECT New_Guid()AS'Fact_Key',Customer.Customer_Key,Store.Store_Key ... FROM Sales_Data_Warehouse AS'source'JOIN Customer_Dimension Customer on source.Customer_Name = Customer.Customer_Name AND source.Customer_Address = Customer.Customer_Address JOIN Store_Dimension AS'Store' ON Store.Store_Name = Source.Store_Name JOIN Product_Dimension AS'Product'ON .....

这是我应该在hive中加载我的事实和维度表的方式吗？

此外,在一般仓库项目中,我们需要更新维度属性(例如:Customer_Address更改为其他内容)或者必须更新事实表外键(很少,但它确实发生).那么,如何在hive中加载INSERT-UPDATE.(就像我们在SSIS中查找或在TSQL中使用MERGE语句一样)？

我一直在努力解决一个问题,到目前为止,我还没有达到我所说的最佳解决方案.我有一个维度(功能)需要在其他2个维度(操作和会话)中引用,而这些维度又是从同一个事实表(UserAction)引用的.这会产生歧义,我无法完成架构:

(注意:模型的剪辑,而不是整个事物)(包括桥表,以显示模型中具有多对多关系的一些增加的复杂性)

我认为问题可能在于Dim_Features在技术上在两个维度之间具有不同的含义,但我仍然试图使用它作为相同的？它意味着:

• 动作属于此功能/特征区域
• 会话有此功能/功能区可用(拥有)

我需要完成的是能够通过Sessions过滤/切片Fact_UserActions,其中某些功能可用/不可用,然后分析如下内容:

• 当拥有特征'A'时使用哪些特征(如,某些特征之间的相关性,以及其他特征是否被使用)？
• 拥有功能的用户有多少未使用过它？
• 功能的使用频率是多少？(受拥有它的会话数量限制,即实际可以使用的会话数量)

关于我可能做错了什么,或者我如何改进模型的任何想法？

编辑:如果它有所帮助,我们想要摆脱的事情就是这样一个表:

我们可以看到一个特征对整个人口以及拥有它的人口的影响.

我是SSDT的新手,我正在学习名为Multidimensional Modeling(Adventure Works Tutorial)的Analysis Services教程.我目前正在第3课,关于修改 "修改属性关系"标题下的客户维度的步骤.

当我打开Customer Dimension 的Dimension Designer窗口时,如果单击属性选项卡,则会收到一条很长的错误消息.我一直在网上搜索,没有发现这个错误.有谁知道这个错误的原因是什么？我已经检查了我的字体文件夹,我已经有了Arial字体.

 ===================================

 An error prevented the view from loading. (Microsoft Visual Studio)

 ===================================

 Exception has been thrown by the target of an invocation. (mscorlib)

 ------------------------------
Program Location:

   at System.RuntimeMethodHandle.SerializationInvoke(IRuntimeMethodInfo method, Object target, SerializationInfo info, StreamingContext& context)
   at System.Runtime.Serialization.ObjectManager.CompleteISerializableObject(Object obj, SerializationInfo info, StreamingContext context)
   at System.Runtime.Serialization.ObjectManager.FixupSpecialObject(ObjectHolder holder)
   at System.Runtime.Serialization.ObjectManager.DoFixups()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler …

我有一个PostgreSQL数据库,其中包含各种教育数据,如学校级别的考试成绩和入学人数.我需要将注册与测试分数分开,因为数据是在不同的谷物上.即使注册与测试分数数据的粒度不同,但许多维度都是相同的.例如,我有:

~ ---------------------------------------------------------------------------------~
| Test Scores Fact                                                                 |
|-------------|-----------|----------|-----------|--------------|------------|-----|
| school_code | test_code | grade_id | gender_id | ethnicity_id | subject_id | ... |
|-------------|-----------|----------|-----------|--------------|------------|-----|

~ --------------------------------------------------------~
| Enrollment Fact                                         |
|-------------|----------|-----------|--------------|-----|
| school_code | grade_id | gender_id | ethnicity_id | ... |
|-------------|----------|-----------|--------------|-----|

这种结构在后端很好,但在Qlikview中,这会创建一个合成密钥.合成密钥的解决方案似乎通常是通过Qlikview脚本来替换它的链接表,这也是我的方法.但这似乎没有扩展,因为当我添加第三个事实表(在另一个谷物上)包含更多相同的维度时,如果我创建另一个链接表,现在我的两个链接表开始关联,因为它们通常包含几个命名字段,Qlikview的回应是创建更多的合成密钥？

我对Qlikview比较陌生,而且我自己也在工作.如何处理具有共同尺寸的不同颗粒的多个事实？

编辑:

我已经提供了解决这个问题的解决方案,这个问题已经在生产环境中工作了不到一年!请参阅下面的答案......

如果请求的报告需要有关相同维度(并且具有相同的粒度)的汇总信息,但基础数据存储在单独的事实表中,那么数据仓库设计的好方法是什么？

例如,一份报告显示每个员工每年报告的工资总额和报告的总费用,当时工资和费用记录在不同的事实表中.或者一份报告,列出公司销售的每个SKU每月的总销售额和每月收到的库存,当销售来自一个事实表并且接收来自另一个.

天真地解决这个问题看起来很简单:只需并行查询和聚合两个事实表,然后将聚合结果拼接在数据仓库或客户端应用程序中.

但我也有兴趣考虑其他方法来思考这个问题.别人怎么解决了？我想知道数据仓库架构和设计,以及使客户端工具设计友好,以构建报告,如上面的例子.

此外,这个"维度三明治"用例是否在规范数据仓库术语中有名称？如果是,则可以更轻松地通过Google进行研究.

我们正在使用SQL Server,但此时我提出的问题有望与平台无关.

这不完全是我在做什么，但我觉得这是一个很好的例子：

假设我有一个 Product 维度表，它连接到我的 ProductSales Fact 表。dimProduct 中的每一行都包含单个产品的所有相关数据（代码、名称、描述等），并且大约有 100 万种产品。

我现在需要将产品类别存储到仓库中。每个产品有多个类别，平均为 5 个。

我是否应该为产品适合的每个类别复制 Product Dimension 中的整行，还是应该使用 dimCategory 维度和两者之间的 dimProductCategory 链接表将我当前的星型模式雪花化？

恐怕如果我做前者，那么我的 Dimension 表会变得更大 5 倍以上，如果我做后者，那么模型会变得更加复杂。

在SQL Server 2008+中,我们希望启用对运营数据库中"客户"表的历史更改的跟踪.

这是一个新表,我们的应用程序控制所有写入数据库,所以我们不需要像触发器这样的邪恶黑客.相反,我们会将更改跟踪构建到业务对象层,但我们需要找出要使用的正确数据库模式.

行数将低于100,000,每条记录的变化数量平均为每年1.5.

我们至少有两种方法可以对此进行建模:

1. 作为2型渐变维度称为表CustomersHistory,以列EffectiveStartDate,EffectiveEndDate(设置为NULL为客户的当前版本),以及审计列像ChangeReason和ChangedByUsername.然后我们构建一个Customers过滤到该表的视图EffectiveEndDate=NULL.我们的应用程序的大多数部分将使用该视图进行查询,并且只有需要具有历史记录功能的部分才会查询基础表.为了提高性能,我们可以实现视图和/或在EffectiveEndDate = NULL上添加过滤索引.

2. 使用单独的审计表.对Customer记录的每次更改都会一次写入Customer表并再次写入CustomerHistory审计表.

通过快速回顾StackOverflow问题,#2似乎更受欢迎.但这是因为大多数数据库应用程序必须处理遗留和流氓作家吗？

鉴于我们从一个空白的板岩开始,这两种方法的优点和缺点是什么？你会推荐哪个？

我有一个DimPlace维度,其中包含该地点的名称(由用户手动输入)以及该地点的纬度和经度(自动捕获).由于手动输入地点,因此可以在多个时间使用不同名称的同一地点,另外,两个不同的地方可能彼此非常接近.

我们希望能够分析两个"位置"之间的MPG,但我们希望将它们分组以形成更大的区域 - 即使用lat和long将一个位置的所有各种拼写,以及不同但非常接近的位置,一个记录.

我打算为此制作一个新的维度 - 像DimPlaceGeozone.我正在寻找一个资源来帮助加载映射到...的所有lat和long值？也许邮政编码或城市名称？有时候你可以找到一个加载常见维度的脚本(比如DimTime) - 我会喜欢类似于北美的lat和long值的东西吗？

我被要求对星图进行建模。
我有3个维度：

1. 日期（日、月、年、周、季度...）
2. 地点（500 个不同值）
3. 产品（80k 种不同产品）

主要问题是一天结束时每个地方存储了多少物品（产品）。

经过一些有关维度建模的学习时间。我想我应该实现一个定期快照表。然而，通过阅读 Kimball 文档，我注意到定期快照需要为每个维度组合提供一个条目。这意味着我应该每天添加40M行 (80k*500)。
知道产品（真正的）移动缓慢，并且许多地方长期存储零产品，这听起来像是一种极端的杀伤力。
仅供参考，三年后源数据库中的事务为 150k 行。

那么我真的应该每天添加 40M 行，还是可以只添加指定产品的非空商店？另外，如果出于某种原因有一天所有商店都空了，我是否应该在当天进行输入（商店和产品的尺寸不适用）？