问题标签 [data-warehouse]

对于我们的报告应用程序，我们有一个流程，每晚将多个数据库聚合到一个“报告”数据库中。报告数据库的架构与我们正在聚合的单独“生产”数据库的架构完全不同，因此有大量的业务逻辑涉及数据的聚合方式。

现在这个过程是由几个每晚运行的存储过程实现的。随着我们向报告数据库添加更多详细信息，存储过程中的逻辑变得越来越脆弱和难以管理。

还有哪些其他策略可用于填充此报告数据库？

• 西斯？这已经被考虑过了，但似乎并没有提供比存储过程更清洁、更易于维护的方法。
• 一个单独的 C#（或任何语言）进程将内存中的数据聚合，然后将其推送到报告数据库中？这将允许我们为逻辑编写单元测试并以更易于维护的方式组织代码。

我正在寻找关于上述内容的任何新想法或其他想法。谢谢！

我熟悉在 Oracle 中使用分区作为向表发布增量添加的技术的概念（在 DW 上下文中）。

（像这个例子）

例如。数据集市事实表的每日快照会在后台加载到表中的分区中。例如使用日期作为分区键（1 个分区表，只有一个分区）。加载完成并验证内容后，可以将分区作为字典事件“交换”到真正的目标表（1 个分区表，具有许多分区）中。

SQL Server 2008 是否可以使用相同类型的发布模型？

伙计们，

我有一个名为 DIM_FILE 的维度表，其中包含我们从客户那里收到的文件的信息。每个文件都有构成我的 FACT 表 CUST_DETAIL 的详细记录。在主进程中，文件经历了几个阶段，每个阶段都为其标记一个状态。总而言之，我有多对多的关系。关于星型模式维度建模的任何想法。一个客户记录只属于一个文件，一个文件可以有多个状态。

我有两个表，记录从外部源源不断地插入到这些表中。假设这些表保存了用户交互的统计信息。当用户单击按钮时，该单击的详细信息（用户、单击时间等）将写入其中一个表。当用户将鼠标悬停在该按钮上时，会将带有详细信息的记录添加到其他表中。

如果有很多用户不断地与系统交互，就会产生大量的数据，并且这些表会大大增加。

当我想查看数据时，我想以每小时或每天的分辨率查看它。

有没有一种方法或最佳实践可以在所需的分辨率中以增量方式（随着数据的收集）不断总结数据？

或者有没有更好的方法来解决这类问题？

PS。到目前为止，我发现像 Talend 这样的 ETL 工具可以让生活变得轻松。

更新：我目前正在使用 MySQL，但我想知道无论数据库、环境等如何的最佳实践。

我有一个类型 2 数据的数据库表，我想查找自上次与它同步以来已删除的记录。它有date_from和date_to列，原始数据有一个 ID 列object_id。 date_to<>null表示它现在不存在，所以如果没有其他具有相同object_id和的记录date_to=null，则它已被删除。

我相信一个天真的实现会是这样的：

但显然这将是非常昂贵的。

我是否缺少一种明显更有效的方法？我怀疑没有（或者更确切地说，我应该假设删除的记录相对较少，并在 RDBMS 之外进行一些计算），但我想我会问以防万一。

谢谢！

假设您有一个具有类型 2 渐变维度的表。

让我们用以下列来表示这个表：

在此示例中，假设 [StartDate] 实际上是系统知道给定 [Key] 的值的日期。所以我们的主键将由 [StartDate] 和 [Key] 组成。

当给定 [Key] 的一组新值到达时，我们将 [ExpiryDate] 分配给一些预定义的高代理值，例如“12/31/9999”。然后，我们将该 [Key] 的现有“最近”记录设置为具有等于新值的 [StartDate] 的 [ExpiryDate]。基于联接的简单更新。

因此，如果我们总是想获取给定 [Key] 的最新记录，我们知道我们可以创建一个聚集索引：

尽管键空间可能非常宽（例如，一百万个键），但我们可以通过最初按 [ExpiryDate] 对它们进行排序来最小化读取之间的页数。而且由于我们知道给定密钥的最新记录将始终具有 [ExpiryDate] '12/31/9999'，因此我们可以利用它来发挥我们的优势。

但是...如果我们想在给定时间获取所有 [Key] 的时间点快照怎么办？从理论上讲，整个键空间并不是同时更新的。因此，对于给定的时间点，[StartDate] 和 [ExpiryDate] 之间的窗口是可变的，因此按 [StartDate] 或 [ExpiryDate] 排序永远不会产生您要查找的所有记录的结果连续的。当然，您可以立即丢弃 [StartDate] 大于您定义的时间点的所有记录。

本质上，在典型的 RDBMS 中，哪种索引策略提供了最小化读取次数以检索给定时间点的所有键值的最佳方法？我意识到我至少可以通过 [Key] 对表进行分区来最大化 IO，但这当然不是理想的。

或者，是否有不同类型的缓慢变化维度以更高效的方式解决此问题？

我试图弄清楚在我的数据库表中调用该列的内容，该列将 INT 保存到特定的“记录版本”。我目前正在使用“ RecordOrder ”，但我不喜欢这样，因为人们认为higher=newer，但我使用它的方式，lower=newer（“1”是当前记录，“2”是第二个最新的，“3”更老，依此类推）。我考虑过“ RecordVersion ”，但恐怕会有同样的问题。还有其他建议吗？“记录时代”？

我这样做是因为当我插入表格时，不必找出下一个版本，然后冒着在我写之前从我身上偷走该号码的风险，我只需插入带有“RecordOrder”为0的插入. 表 AFTER INSERT 上有一个触发器，它将该键的所有“RecordOrder”数字加 1，所以我刚刚插入的记录变为“1”，所有其他记录都加 1。这样，你可以得到一个人的当前记录通过选择 RecordOrder=1，而不是获取 MAX(RecordOrder) 然后选择它。

PS -我也愿意批评为什么这是一个糟糕的主意，我应该增加这个索引。这似乎使查找更容易，但如果这是一个坏主意，请赐教！

有关数据的一些详细信息，例如：

我有以下数据库表：

我的数据子集如下所示：

在此示例中，客户 100 有三行 - 他们欠 100 美元，然后是 10.05 美元，现在他们什么都不欠。让我知道是否需要进一步澄清。

更新：

“RecordOrder”和“RecordCreated”列对用户不可用 - 它们仅供内部使用，并帮助确定哪个是当前客户记录。此外，我可以使用它返回一个适当排序的客户历史记录，尽管我可以很容易地使用日期来完成。我想，我可以只用 RecordCreated 日期完成与递增“记录版本”相同的事情，但这消除了知道 RecordOrder=1 是当前记录的便利，我又回到做一个子查询DateTime 上的 MAX 或 MIN 以确定最近的记录。

我正在考虑在 Map/Reduce 解决方案（如 Hadoop）之上构建一些数据仓库/查询基础设施。

然而，令我震惊的是，所有 M/R 工作只是重复了 RDBMS 人员在过去 20 年中使用并行 SQL 数据库解决的问题。并行 SQL 实现跨节点扩展读写，就像 M/R 一样，但还包含来自常规数据库（SQL、现有集成库等）的细节。

问题是：您似乎没有发现这些公司的客户在网上发布了很多内容。那么，这里有没有人对这些解决方案有经验，可以给我一些见解和/或链接？

我是 OLAP 的新手。

我了解表结构和 ETL 过程。

我不明白什么时候应该从事实表中删除数据。假设我正在为事件创建一个报告应用程序。每个事件都有完成所需的持续时间、退出代码和读取的总字节数。有几个维度，例如时间和位置。

假设我每天为我的事实表准备 100 万条新记录，总共 1 GB。如果我的 ETL 流程只将数据添加到我的事实表中，它会无限增长。我应该什么时候从我的事实表中删除数据？我应该把数据分成几个事实表（例如月表）吗？

有没有经验法则？

谢谢

过去我们通过存储过程访问数据库。它们被视为管理数据的“更好”方式。我们将数据保存在数据库中，任何语言/平台都可以通过 JDBC/ODBC/等访问它。

然而，近年来，基于运行时反射/元数据的存储检索机制（如 Hibernate/DataNucleus）变得流行起来。最初我们担心它们会很慢，因为涉及额外的步骤（反射很昂贵）以及当我们只需要一个字段时它们如何检索不必要的数据（整个对象）。

我开始计划一个使用 J2EE 的大型数据仓库项目，但我有点不确定是选择存储过程还是 JDO/JPA 等。最近，我一直在使用 Hibernate，老实说，我不会错过编写 CRUD 存储过程的机会！

它基本上归结为：

存储过程
+ 可以在服务器上进行优化（尽管只有查询）
- 可能有超过一千个存储过程：每个表的添加、删除、更新、getById 等。

JDO
+ 我不会在接下来的几个月里写 parameters.add("@firstNames", customer.getFirstName()); ...
- 会比 SP 慢（但大多数支持分页）

在我的情况下，你会为​​了什么而丰满。在这种情况下，我认为这非常重要。

谢谢，

约翰