数据仓库注意事项:何时以及为什么?

我看看能否尽我所能简明扼要地回答你的问题。

1.在什么情况下构建数据仓库是值得考虑的选择? 换句话说,什么样的信号, 这是一个标准的事务

A.如果您发现报告和监视会影响生产系统和/或脱机数据存储的性能。

B如果您发现要获得业务问题的答案,每次都需要构建大量复杂的SQL。

C如果您发现每次更改事务模式时,都必须返回并重新处理所有报告查询。

D如果要将来自多个源的数据合并在一起。

2.除了全方位数据仓库,还有哪些替代方案? 事务模型中的非规范化 复制的“报表服务器”有两种 我想到的;有吗 其他我应该探索的 向DW承诺?

“这取决于”,那么它取决于什么呢

我将一起回答这些问题。我不认为数据仓库是一个全有或全无的冒险。这只是一个简单的短语,意思是“以一种允许您更轻松、更快速地回答业务问题的方式存储数据。”

事务数据库的设计目的是有效地与应用程序接口。数据仓库、数据集市、运营数据存储和报告表的构建是为了有效地与人进行交互(如果有意义的话)。

任何被宣布为“最佳实践”的东西 不管上下文如何。当然有 必须在某些情况下使用DW

好问题。如果您的事务系统为您提供了对业务的充分了解,那么您可能不需要仓储。

如果您只有一个数据源,并且性能不是问题,那么您可能可以从创建简单的报告表中获得见解。

通过引入数据 向我解释,端到端,什么种类 仓库,他们是怎么决定的 放什么进去,怎么放 做作的“让我们用它做一个立方体。” AdventureWorks数据库 我对规格很感兴趣 设计和总体思路 涉及的过程。

这是一个大问题,它将占用比我在这里分配的空间多得多的空间。

在这一点上,我可以为您指出一些可能提供您所寻求的见解的地方。

• 拉里萨·莫斯的“商业智能路线图”。标准票价。引导您完成在高级别构建BI实践的过程。

1. 数据仓库的主要目的是加速(简化)报告和分析。它支持以业务用户能够想到的任何方式对数据进行切片和切割。

2. 对于DW的第一步,您可以简单地实现一个Kimball星型模式并对其运行SQL查询。如果这仍然太慢,开始考虑预先计算的聚合(多维数据集)。

5. 我所有的经验都是在系统中,业务用户无休止地抱怨报告速度慢,无法编写“复杂的查询”,而生产人员则抱怨数据库因报告而陷入困境。在所有情况下,一个简单的Kimball star和一个带有缓存和快照的报表服务器就足够了。

1. 当下列两个标准匹配时,应考虑建立数据仓库:

   • 许多大型复杂的选择(可能与很少的插入、更新和删除相比)执行时间太长(并且编写起来很复杂)

2. 这确实是你考虑数据仓库的问题。在许多情况下,只要您坚持使用关系数据库管理系统,就可以逐渐从带有一些报告的OLTPs系统转移到完整的数据仓库。首先可以构建第一个事实表,并继续使用规范化的表作为维度。然后在游戏中添加更多事实、更多事实表或专用维度表。首先在同一个数据库(或相关系统的一个数据库)中,稍后可能移动到单独的数据库。

3. 一个完整的数据仓库(独立的数据库,星型模式)为调优select语句提供了最好的选择,而不是使用专门的系统。它还与OLTP系统完全解耦。要考虑模式设计,还要考虑CPU、I/O和内存等资源以及组织,比如新版本的调度。当然,这是很多你可能不需要的工作。

在什么情况下,构建数据仓库是一个值得考虑的选项?换句话说,我应该寻找什么样的迹象、指标或其他标准来表明标准事务环境不再足够?

我在这里没有什么可以提供的。我要说的是,保留事务数据库和报告数据库对我来说似乎是明智的,不管您是否将其称为仓库。数据挖掘可能是一项CPU密集型活动。

我在这里没有什么可以提供的。

我想说的是,如果您不需要保持长期的历史记录,不需要对数据进行密集的分析,并且您的报告需求仅限于偶尔的临时查询,那么可能不需要数据仓库。

在我到来之前,我的雇主已经使用数据仓库很多年了,所以我无法谈论我到来之前的情况。

如果长期使用事务系统,则可以考虑DW。后来,他们意识到他们需要执行一些数据挖掘,以确定业务的不同数据模式。最后,在确定的数据模式的帮助下,我们希望帮助最高管理层为公司的利益做出进一步的决策。

建立数据仓库需要采取以下步骤:

2. 需要为可视化选择SSRS、Tableau等报告工具。
4. 最后,所有这些将有助于开发数据仓库和报告工具。

“我想,为什么有些项目会失败?”

• IT部门与业务用户之间缺乏合作关系;
• 不正确的数据仓库架构;
• 规划不当,例如未能使用经验证的方法和计划来确保不遗漏任何细节;
• 依靠前沿技术。