标签: data-warehouse

数据仓库建模的主要拓扑（星形、雪花）在设计时考虑了一对多关系。当面临这些建模方案中的多对多关系时，查询可读性、性能和结构会严重下降。

有哪些方法可以在数据仓库中实现维度之间或事实表与维度之间的多对多关系？它们对必要的粒度和查询性能造成了哪些影响？

我意识到我的公司使用 ELT（提取-加载-转换）流程而不是使用 ETL（提取-转换-加载）流程。
这两种方法有什么区别，在哪些情况下一种会比另一种“更好”？如果您能提供一些示例，那就太好了。

我偶尔会以 Postgres dB 的形式下载公开可用的数据集。这些数据集由存储库主机随时间更新/修改/扩展。

是否有 Postgres 命令或工具（最好是 FOSS）可以显示旧 Postgres 数据库和新 Postgres 数据库之间的差异？（一个可行的假设是 95% 的条目没有改变，表和关系也没有改变）。

我正在使用索引对数据仓库进行性能调整。我对 SQL Server 2014 还是很陌生。Microsoft 描述了以下内容：

“我们将聚集列存储索引视为存储大型数据仓库事实表的标准，并预计它将用于大多数数据仓库场景。由于聚集列存储索引是可更新的，您的工作负载可以执行大量的插入、更新、和删除操作。” http://msdn.microsoft.com/en-us/library/gg492088.aspx

但是，如果您进一步阅读文档，您会发现限制和限制：

“不能有唯一约束、主键约束或外键约束。”

这让我很困惑！出于各种原因（数据完整性、语义层可见的关系......）

所以微软提倡数据仓库场景使用聚集列存储索引；但是，它不能处理外键关系？！

我在这方面正确吗？您会建议哪些其他方法？过去，我在数据仓库场景中使用了非聚集列存储索引，对数据加载进行删除和重建。然而，SQL Server 2014 并没有为数据仓库增加真正的新价值？？

我想知道这个问题还没有被问过。谷歌对我来说只有很少的结果没有显示高质量的工具

有哪些用于数据仓库的开源（也可以免费）解决方案，更具体地说是商业智能工具？你和他们有什么经历。我在我的硕士课程中有过一门课程，我们使用 MS 商业智能和 MSSQL 作为数据仓库存储。现在我想通过“开放”的工具深入探讨这个话题。

是否有任何可比较的商业智能工具（主要是独立于数据库的），您是否有使用它们的经验？

编辑玛丽安对斯蒂芬妮的回答的评论，我发现我把这个问题表述错了。我知道 DWH 只是“报告优化”数据库，斯蒂芬妮对此的解释非常清楚。我更感兴趣的是如何使用什么类型的 BI 软件/工具/其他技术将数据转换为这种优化的形式。

当使用系统版本控制的时态表（SQL Server 2016 中的新功能）时，当使用此功能处理大型关系数据仓库中的缓慢变化维度时，查询创作和性能影响是什么？

例如，假设我有一个Customer带有Postal Code列的 100,000 行维度和一个Sales带有CustomerID外键列的数十亿行事实表。并假设我想查询“按客户邮政编码划分的 2014 年总销售额”。简化的 DDL 是这样的（为了清楚起见省略了很多列）：

CREATE TABLE Customer
(
    CustomerID int identity (1,1) NOT NULL PRIMARY KEY CLUSTERED, 
    PostalCode varchar(50) NOT NULL,
    SysStartTime datetime2 GENERATED ALWAYS AS ROW START NOT NULL, 
    SysEndTime datetime2 GENERATED ALWAYS AS ROW END NOT NULL,   
    PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime) 
)
WITH (SYSTEM_VERSIONING = ON);

CREATE TABLE Sale
(
    SaleId int identity(1,1) NOT NULL PRIMARY KEY CLUSTERED,
    SaleDateTime …

我参与了一个新项目，我必须从现有的关系数据库系统创建数据立方体。

我明白，现有的系统设计不当，我不知道从哪里开始。

我的问题是：

• 星型模式和数据立方体有什么区别？
• 我必须从哪里开始？从星型模式还是直接数据立方体？
• 数据立方体是从星型模式生成的吗？

我对关系数据建模的经验很少，这个问题可能看起来太基础了，我试图从很少的资源中弄清楚，仍然不清楚。请给出您的意见和建议？

如果我错过了与此问题相关的非常重要的内容，请也分享您对此的看法。

我们开始设计数据集市/仓库的构建块，我们需要能够支持所有时区（我们的客户来自世界各地）。从在线（和书籍）阅读讨论来看，一个常见的解决方案似乎是在事实表中具有单独的日期和时间维度以及时间戳。

但是，我很难回答的问题是，考虑到我的动态时区要求，日期和时间维度实际上对我有什么好处？时间维度更有意义，但我很难处理日期维度。日期维度的一般设计方法通常包括日期名称、星期几、月份名称等属性。我遇到的所有问题是 UTC 时间 2013 年 12 月 31 日星期二晚上 11:00 是星期三, 2014 年 1 月 1 日，在 UTC+2 之后的所有时区。

因此，如果我必须对每个查询（和报告）进行所有这些时区转换，那么拥有和存储这些我可能永远不会使用（似乎）的属性有什么意义？有些人建议为每个时区设置事实行，但这对我来说似乎很荒谬。我们需要能够每月存储数百万条记录。

其他人建议有一个时区桥接表，虽然有一定的意义，但它似乎也需要额外的复杂性和额外的连接来完成我的客户端应用程序和报告应该能够轻松地从日期中找出的东西（报告将主要基于网络那里有无数的库可以帮助转换、显示和格式化日期）。

我唯一能想到的是按日期和小时分组的简便性和可能的​​性能，但是按日期部分分组的做法有多糟糕（我们正在使用 MS SQL，但我们将查询数百万行），或者我们应该考虑只是非常简单的日期和时间维度，大多数情况下不超过小时、日、月和年数字，因为大多数文字（例如星期一）在时区发挥作用时没有多大意义？

根据我的分析，我们数据仓库的完整维度模型需要从 200 多个源表中提取。其中一些表将作为增量加载的一部分提取，而其他表将作为完整加载。

需要注意的是，我们有大约 225 个具有相同架构的源数据库。

据我所知，在 SSIS 中构建一个带有 OLE DB 源和 OLE DB 目标的简单数据流需要在设计时确定列和数据类型。这意味着我最终会得到 200 多个数据流，仅用于提取。

从可维护性的角度来看，这对我来说是一个大问题。如果我需要对提取代码进行某种彻底的更改，我将不得不修改 200 个不同的数据流。

另一种选择是，我编写了一个小脚本，用于读取我想从一组元数据表中提取的源数据库、表名和列。代码在多个循环中运行，并使用动态 SQL 通过链接服务器和 OPENQUERY 从源表中提取。

根据我的测试，这仍然不如使用带有 OLEDB 源和目标的 SSIS 数据流快。所以我想知道我有什么样的选择。到目前为止的想法包括：

1. 使用EZAPI以编程方式生成具有简单数据流的 SSIS 包。要提取的表和列将来自前面提到的相同元数据表。
2. 购买第 3 方软件（动态数据流组件）

解决这个问题的最佳方法是什么？当谈到 .NET 编程时，我是一个初学者，所以仅仅学习基础知识所需的时间也是一个问题。

我需要在大数据仓库中支持动态字段和值来存储 API 请求日志，我的用户案例是我需要存储所有 API 请求查询字符串并能够在未来对它们执行查询（所以它不仅仅是存储，所以我不能为他们使用 blob）

例如 http://example.com/?action=test&foo=abc&bar=def...

我需要存储所有field => value映射，即(action => test), (foo => abc), (bar => def)，由于该字段是如此动态，我找到的唯一解决方案是使用 Entity-Attribute-Value，但是，人们一直说这是一个非常糟糕的设计。

那么，考虑一下我上面的用例，什么是 EAV 的合适替代品？

我当前使用 KAV 的模式

1. 表requests
(id, timestamp, uri)
   例如(1, 149382220, '/')

2. 表params
(request_id, key, value)
   例如(1, 'action', 'test'), (1, 'foo', 'abc'), (1, 'bar', 'def')

有什么建议？

更新：我们在 AWS RedShift 上运行仓库