作为一个在过去14年里为不同行业的客户提供原型设计、建议和构建仪表板的人，我注意到所有这些公司都有一个共同点数据库是形象化的垃圾桶。
猜猜我遇到过多少次数据库，它非常适合构建某人想要的仪表板和报告?你觉得呢?80%的时间?50%的时间?嗯，我见过一次!找到一个完全干净的数据库就像找到一只独角兽，有时我怀疑它们是否存在。独角兽，我是说……我很确定干净的数据库是真实存在的……
让我们以CRM系统和支持它的底层数据库为例。在许多情况下，公司可能需要对数据库应用正在进行的更改，以修复初始设计中的缺陷。然而，即使支持业务的数据库从一开始就设计得很好，公司也会变化和发展，每一位新的领导者都可能带来新的流程。随着时间的推移，原始数据库设计与当前业务需求的相关性越来越小。因此，由于这种相关性的丧失，为了保持它的运作，创可贴和短期变化是不可避免的。
部分问题在于你会这么做“厨房里有太多厨师”。市场、销售、会计和支持系统等部门都可能在任何给定时间与CRM的不同部分进行交互。每当其中一个部门的管理人员想要进行更改(比如添加一个新字段)时，他们都独立地要求数据库所有者对后端做一些事情来支持更改(可能没有意识到这一点)。不需要很长时间，事情就会从一个最初执行良好的系统变成一堆越来越多的垃圾;只要快进几年，并不断重复这个规律的业务变动。随着时间的推移，新流程、新员工、新想法和不断变化的组织不断涌现是很常见的。
您可能会对自己说，“为什么不在发生变化时正确地维护和重新连接数据库呢?”这个问题部分归结于大多数人的囤积心态。通常有一种观点认为不应该更改或删除任何内容，因此为了解决问题，可以将诸如hack之类的不太优雅的解决方案应用于数据库。数据库所有者通常会被告知，“不要删除任何东西”，“保留旧的东西以防万一”，因为“我不知道其他人可能会对它做什么”。快进到未来，您的后端系统会出现一些严重的混乱。
前面描述的移动目标问题只是数据库面临的一个问题，但它是一个严重的问题。您还应该注意其他一些问题，但这些通常是技术问题，而不是实际的滥用。当我说数据库是垃圾桶时，事实并非如此，就像把这些技术问题应用到已经是拼凑灾难的东西上一样;你有一个垃圾桶。
以下是一些复杂的问题:
- 弱规范化(性能)
- 冗余(性能)
- 参考完整性(数据质量)
- 忽略数据库特性(性能、质量、自动化)
- 索引差(性能)
- 糟糕的命名约定(可用性)
现在，让我们快进到现在，到一个场景高层领导决定他们需要做更好的报告，并选择实现商业智能(BI)工具．商务人士所青睐的大多数BI工具都非常易于使用，数据非常简单。这些工具需要完美和直接的数据，以允许简单和易于构建的仪表板。当然，问题在于后端系统一点也不简单，企业在一个无法解决问题的BI工具上花费了大量资金，因此陷入了一场灾难。你能做什么?嗯，你有两个主要的选择。
首先，重建整个后端数据库可能不太实际，因为所有的业务流程和应用程序都是相互连接的，因为这项任务将是巨大的。剩下的解决方案是构建一个用于报告的数据仓库。构建一个漂亮而干净的报告数据库，从数据库的垃圾桶中提取、清理和复制选择的数据。构建报告数据仓库可能是一项耗时且可能代价高昂的工作，但它将使报告成为可能。
您的另一个选择是返回您正在评估的易于使用的BI工具，并获得一个具有健壮的数据准备层的工具。找到一个具有ETL层、仓库功能和足够特性的BI工具，以确保它可以执行使数据库可用所需的大量任务．干净和准确的数据将有助于报告和仪表板的创建，之后您将为此感谢自己。
作者简介
Jeff Hainsworth是Dundas Data Visualization的高级解决方案架构师，在商业智能方面拥有超过15年的经验。他对建筑、编码和一切视觉上的东西都充满热情——你知道，闪亮的东西!看看“Off the Charts……”“与Jeff一起”，他的平台提供有关分析、数据可视化、仪表板和商业智能的精彩内容。每个人都有适合自己的东西!
关注我们
支持