问题标签 [data-warehouse]

Star-Schema 设计对数据仓库来说是必不可少的吗？或者你能用另一种设计模式做数据仓库吗？

我有一个包含典型星型模式的数据仓库，还有一大堆代码可以做这样的事情（显然要大得多，但这只是说明性的）：

我正在考虑用一个视图（MODEL_SYSTEM_1例如）替换它，这样它就变成了：

但是视图MODEL_SYSTEM_1必须包含唯一的列名，如果我继续这样做，我还担心优化器的性能，因为我担心 WHERE 子句中跨不同事实和维度的所有项目都会得到优化，因为视图将跨越整个恒星，并且视图无法参数化（男孩，那不是很酷！）

所以我的问题是——

1. 这种方法可以吗，或者它只是一种抽象，会损害性能并且除了更好的语法之外没有给我任何东西？

2. 考虑到所有适当的 PK 和 FK 都已到位，对这些视图进行代码生成、消除重复的列名（即使稍后需要手动调整视图）的最佳方法是什么？我是否应该只编写一些 SQL 将其从其中提取出来，INFORMATION_SCHEMA或者是否已经有一个很好的示例可用。

编辑：我已经对其进行了测试，即使在更大的过程中，性能似乎也是一样的——甚至加入了多个使用这些视图的星星。

自动化主要是因为数据仓库里面有很多这样的star，设计者已经做好了FK/PK，但我不想把所有的表格或文档都挑一遍。我编写了一个脚本来生成视图（它还生成表格的缩写），它可以很好地从 自动生成骨架INFORMATION_SCHEMA，然后可以在提交视图创建之前对其进行调整。

如果有人想要代码，我可能会在这里发布。

我们正在做一些复杂的数据积累。我们的客户向我们发送了一些包含两个维度（时间和业务单位）的内容。时间主要是年月。业务单位维度只有几个属性：名称和几个类别，BU 可以属于这些类别以用于报告和分析目的。

他们发给我们的东西包括一些当前状态信息（日期和代码）。这些看起来像事实。他们还发送一些描述与业务部门关系的信息（主要是附加代码）。同样，这些对于业务部门和时间段来说是独一无二的。

最后，他们向我们发送了显然是附加事实的东西。它包括具有适当单位的货币和计数。

我应该将这些定性信息与附加事实混合在一个事实表中吗？或者我应该将定性的东西（只能与计数一起使用）与定量的东西（可以与总和一起使用）分开吗？

我正在构建一个数据仓库，其中包含餐厅的送货信息。数据存储在 SQL Server 2005 中，然后放入 SQL Server Analysis Services 2005 多维数据集。

交付信息由下表组成：

事实交付

• 分支键
• 交货日期密钥
• 产品密钥
• InvoiceNumber（DD：退化维度）
• 数量
• 单位成本
• 线路成本

笔记：

• FactDeliveres 的粒度是发票上的每一行
• 产品维度包括供应商信息

问题是：事实表没有主键。主键应该是唯一标识每个交付加上 ProductKey 的东西。但是我没有办法唯一标识一个交付。

在源 OLTP 数据库中，有一个 DeliveryID，对于每个交付都是唯一的，但这是一个对用户没有意义的内部 ID。InvoiceNumber 是供应商的发票编号——这是手动输入的，所以我们得到了重复。

在多维数据集中，我仅基于 FactDeliveres 中的 InvoiceNumber 字段创建了一个维度。这确实意味着，当您按 InvoiceNumber 分组时，您可能会合并 2 个交付，只是因为它们（错误地）具有相同的 InvoiceNumber。

我觉得我需要包含 DeliveryID（称为 DeliveryKey），但我不确定如何。

我也是：

1. 将其用作 InvoiceNumber 维度的基础键？
2. 创建一个每次有新交付时都会增长的 DimDelivery？这可能意味着某些属性来自 FactDeliveries 并进入 DimDelivery，例如 DeliveryDate、Supplier、InvoiceNumber。

毕竟，我只能问你：当我的源数据库中有以下信息时，我如何创建一个 Deliveries 多维数据集

DeliveryHeaders

• DeliveryID (PK)
• 交货日期
• 供应商 ID (FK)
• 发票号码（手动输入）

交货详情

• DeliveryID (PK)
• 产品 ID (PK)
• 数量
• 单位成本

我有很多需要从中生成报告的 mysql 数据。它主要是历史数据，因此不会发生太大变化，但它的重量很容易达到 20-30 GB，并且预计会增长。我目前有一组 php 脚本，它们将执行一些复杂的查询并输出 csv 和 excel 文件。我还将 phpMyAdmin 与书签查询一起使用。我手动编辑它们以更改参数。数据量在增长，需要访问它的人数也在增长，所以我正在抽出时间来改善这种情况。

前几天我开始阅读有关数据仓库的信息，这似乎与我需要做的事情有关。我读过一些 好 文章，甚至在等一本书。我想我已经掌握了这些系统的功能和可能性。

为我的数据创建报告系统一直在待办事项列表上，但直到最近我才认为这将是一个高度利基的编程冒险。由于我现在知道数据仓库是很常见的事情，我认为必须有某种报告/仓库框架可用于简化开发。我很乐意跳过编写界面和脚本来安排和通过电子邮件发送报告等，而是坚持编写查询和建立关系。

我大部分时间都是一个灯人，但我并没有超越切换语言或平台。我只需要一个更强大的解决方案，因为我的一次性脚本不能很好地扩展。

那么从哪里开始呢？

我们有两个不同来源的数据：一些来自客户，一些来自不同的供应商。目前，我们将这些数据物理地“合并”成一个近百列、数万行且两个维度没有正式分离的海量表。因此，我们实际上不能多次使用该表。

我将把这个烂摊子重新设计成一个适当的、但很小的星型模式。

两个维度很明显。例如，其中之一是时间。

客户提供的数据提供了许多事实值。每个供应商可能（或可能不）提供符合相同维度的附加事实值。

这个事实数据都具有相同的粒度。它可以被称为“稀疏”，因为我们并不经常从所有供应商那里获得信息。

这是我的困境。

这是一个从不同来源填充的事实表（带有一些空值）吗？

或者这是n +1 个事实表——一个来自客户，另一个来自每个供应商？

每种设计都有优点和缺点。对于“合并”或“单独加载”之间的选择，我需要一些第二意见。

客户提供收入、成本、计数、重量和其他他们知道的关于交易结束的信息。

供应商一提供了一些关于一些交易的额外细节——权重、成本、持续时间。其他交易对供应商一没有任何价值。

供应商二提供了一些关于一些交易的额外细节——数量、持续时间、长度、外币汇率。其他交易对供应商二没有价值。

一些交易将有两个供应商。少数交易将没有供应商。

一张有空值的表？三张桌子？

在哪里可以下载可用于创建数据仓库的示例数据库？它不应该是来自 Microsoft（Northwind 等）的样本。

编辑：很抱歉没有澄清我的问题。在我的大学，我们有必须创建一些数据仓库的课程，由于 Northwind 在网络上如此受欢迎，所以教授告诉我们不要使用这个数据库。我们将使用此 SQL Server 2008，但禁止使用 Northwind。

有人在使用商业智能工具 Inetsoft Style Report 吗？我坚持下去，想知道是否有人对服务器管理员的调整和/或最佳实践有建议？我们在使用 Tomcat 和 db2 数据库的快速 Solaris 机器上运行。

我有大量数据需要存储，并且能够生成报告——每个数据都代表网站上的一个事件（我们说每秒超过 50 个，因此显然需要汇总旧数据）。

我正在评估实现这一点的方法，显然它需要可靠，并且应该尽可能容易扩展。还应该可以以灵活有效的方式从数据中生成报告。

我希望一些 SOer 有此类软件的经验并可以提出建议，和/或指出其中的缺陷。

理想情况下，我想在 EC2 上部署它。

看起来我的数据仓库项目明年将转移到 Teradata（从 SQL Server 2005 开始）。

我正在寻找有关 Teradata 最佳实践的资源——从其 SQL 方言的限制到使查询执行良好的惯用语和约定——尤其是当它们突出显示与 SQL Server 2005 显着不同的事物时。特别提示类似于在SQL 的艺术（更侧重于 Oracle）。

我的业务流程目前在 T-SQL 存储过程中，并且相当依赖 SQL Server 2005 的功能，如 PIVOT、UNPIVOT 和通用表表达式，每月从 4TB 数据仓库产生大约 2700 万行输出。