预算友好型数据挖掘指南

本文概述

• 交易数据库
• ETL(提取转换负载)和报告
• 数据仓库
• OLAP多维数据集
• 视觉报告
• 总结

与API功能每天都在变化的传统应用程序编程不同, 数据库编程基本上保持不变。 Microsoft Visual Studio .NET的第一个版本于2002年2月发布, 大约每两年发布一次新版本, 不包括Service Pack版本。这种快速变化的步伐迫使IT人员每两年评估其公司的应用程序, 使他们的应用程序功能保持完整, 但源代码完全不同, 以便与最新技术保持同步。

关于数据库源代码不能说相同的话。在SQL的早期阶段, 对SELECT / FROM / WHERE / GROUP BY的标准查询今天仍然有效。当然, 这并不意味着关系数据库编程没有任何进步。过去, 他们比技术上更合乎逻辑。

多年来, 数据仓库的设计没有太大变化。但是, 我们提取和使用数据的方式正在发展, 并创造了新的可能性。

鸣叫

从Bill Inmon和Ralph Kimball发表有关数据仓库设计的理论开始, 数据库编程的发展就一直集中在防止有价值信息的丢失和从数据中提取所有有价值的信息上。 Inmon和Kimball将数据库世界引入数据仓库后, 对ETL(提取/转换/加载)工具进行了重大更改, 使数据库开发人员可以轻松访问元数据以及来自非关系数据库源的数据, 这很难使用以往。这增加了可用于提取有价值信息的可用数据量, 并且可用数据的增加导致通过OLAP多维数据集和数据挖掘算法的数据处理得到了进步。

在数据库体系结构中添加数据仓库, OLAP多维数据集和数据挖掘算法可以极大地简化业务流程并阐明数据中以前不曾存在的模式。自动化也可能对商业智能功能产生深远影响。

但是, 在开始添加新工具和技术之前, 应确保正确构建了事务数据库。

交易数据库

事务数据库是基础, 如果你的事务数据库不可靠且不准确, 则在顶部添加任何内容都会导致灾难。

向数据库添加其他层时要记住的重要一点是, 所有项目都需要显示投资回报率, 这就是为什么最好在添加更多层之前充分利用当前架构。所有这些层都利用源自事务数据库的数据。在许多情况下, 你只需查询事务数据库即可获得相同的输出。当然, 从数据仓库或OLAP多维数据集中读取所有报告是一种理想的方法, 但是当组织尚未准备好应对这种复杂性时, 首先满足其报告需求就显得尤为重要。一旦满足了基本的报告需求, 就可以开始讨论有关适当的数据仓库以及可能的OLAP多维数据集如何使业务受益的讨论。

几乎每个程序员都知道数据库规范化的三个规则。从事务数据库读取的存储过程是进行优化的途径。要寻找的问题是可读性, 对同一数据库表的多次调用以及不必要的变量使用。

所有精英数据库程序员都对存储过程的可读性保持谨慎。数据库专业人员格式化查询的方式存在一些共性, 这与应用程序开发人员不同。通常, 关键字和聚合函数用大写字母表示, 而表和字段名称则使用驼峰式或下划线。表别名与实际表名有一些关联。存储过程各部分的对齐方式具有某种类型的块模式。

以下是利用可读格式的查询示例。

SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount 
FROM customer c 
JOIN purchase_orders po    
    ON c.customer_id = po.customer_id 
GROUP BY c.customer_id, c.name 

接下来要查找的是查询是否多次击中一个表。在大多数查询中, 只需要对一个表进行一次访问, 而很少需要聚合另一个聚合函数。这是某些应用程序程序员犯的另一个错误, 可能是因为应用程序程序员从面向对象的设计角度进行思考。

面向对象的设计为每个唯一的数据元素创建单独的对象, 但是数据库程序员需要考虑集合逻辑。只是查询访问表的次数比需要的次数多并不意味着查询产生的数据不正确, 但是查询的性能会受到影响。

每次有联接时, 另一个关注点就会被删除或重复, 从而损害了查询的准确性。不必要使用变量是应用程序开发人员开发查询的另一个标志。应用程序开发人员在整个代码中都使用变量, 而查询很少需要使用变量, 除非声明为存储过程的参数。这再次表明开发人员没有考虑集合逻辑。

ETL(提取转换负载)和报告

客户的交易数据库中的查询正常运行后, 下一步就是简化业务流程。

确定企业对ETL流程或自动报告的需求的最简单方法是找出谁正在从交易数据库中读取数据, 然后使用电子表格对其进行操作。电子表格的结构与数据库表相同。两者都包含行和列。如果你有最终用户自己处理数据, 则应问自己：”为什么不能自动执行该过程？”

自动化业务流程可提供立即的投资回报, 在进行更昂贵的项目(例如数据仓库)之前, 应始终考虑自动化。识别通过电子表格处理数据的最终用户听起来很简单, 但此过程有一定的警告。

开发人员喜欢自动化流程。这就是他们的工作。最终用户不一定喜欢自动化流程, 尤其是在威胁到其工作的情况下。因此, 不要天真地认为最终用户会跑来跑去找你, 并确定可以自动化的日常任务。你确实需要带头确定精简的机会。

完善的ETL系统还应具有将事务数据库中加载的所有数据回溯到原始源文件的功能。这是数据库体系结构的关键部分。如果你不知道添加每条记录的确切日期/时间以及添加记录的源名称(用户名或文件名), 那么你就不准备处理加载到事务数据库中的不良数据。你应该问自己：”如果有人向我们发送了错误的文件该怎么办？”你需要花费多长时间来识别来自其​​中的记录？

数据仓库

数据仓库设计有两种理论。 Inmon和Kimball理论之间的差异可以总结如下：

Inmon理论是首先开发一个数据仓库, 然后建立维度数据集市以从该数据仓库进行报告。 Kimball理论是首先开发用于报告的维度数据集市, 然后将它们合并在一起以创建数据仓库。

你始终希望为客户提供最快的投资回报。建立数据集市是一个简单的过程。你首先要处理报表后面的查询, 然后将其从返回结果集更改为将结果集存储在永久表中。你只需添加TRUNCATE TABLE表名；在原始SELECT关键字之前插入表名。一旦有了几个功能正常的数据集市表, 就应该确定合并数据集市的机会。查找使用相同表列表的报表查询, 然后合并字段列表。这需要更复杂的查询, 尤其是在表列表增加时。但是, 只要你对查询进行了彻底的测试, 就可以在不影响正常业务流程的情况下进行每次增量更改。

每次你对Kimball数据仓库设计进行增强时, 就有机会向客户展示ROI。这是因为首先要构建数据仓库, 而报告数据集市则是从静态数据仓库构建的。因此, 你在数据仓库项目的早期就承担了大部分成本。

OLAP多维数据集

OLAP多维数据集可以通过为聚合数据提供快速响应时间, 针对最终用户的临时向下钻取功能以及数据挖掘来使组织受益。当你拥有合适的OLAP多维数据集时, 你可以从数据中提取每一点价值。 OLAP多维数据集建立在数据仓库的顶部, 但是它使用的语言不同于标准数据库SQL的MDX。与数据库服务器相比, 它还需要更多的配置工作。这种复杂性使OLAP项目变得昂贵, 而且很难找到经验丰富的MDX开发人员。

在某些情况下, 建立OLAP多维数据集可能会非常昂贵。混合OLAP多维数据集可能是你想要的答案。

鸣叫

数据架构师有时会看到现有的OLAP多维数据集, 无非就是一个使用该多维数据集的简单仪表板, 而没有一个无法用SQL查询, 数据仓库或罐装报表代替的流程。 OLAP多维数据集可以提供比罐装报表更快的响应时间, 但是在大多数情况下, 差异可以忽略不计。你还可以从追溯功能中受益, 但是, 在为最终用户提供追溯功能之前, 最好使用提供类似临时界面的固定报告。

这样, 你可以记录最终用户正在运行的临时查询, 然后可以识别出最终用户未意识到可以创建的新的固定报告。由于在开发OLAP多维数据集时, 响应时间和向下钻取的改进通常很少, 因此没有必要向客户端建议, 除非他们需要可以处理涉及的数据挖掘的数据库体系结构。在这种情况下, 你可以真正打动客户, 并向他们展示有关其业务的一些信息, 而如果没有健壮的数据库体系结构, 它们可能是未知的。

如前所述, 构建OLAP多维数据集可能具有挑战性。考虑使用混合OLAP多维数据集是一个好政策。 Microsoft Excel的PowerPivot提供了易于使用的数据挖掘工具, 而没有复杂的OLAP多维数据集那么复杂。混合动力的主要缺点是它没有相同的响应时间。但是, 最大的优势是, 与使用MDX相比, 使用Excel创建数据挖掘报告要容易得多。数据挖掘时, 有三个有用的报告。我们可以看一些真实的例子, 以及如何解释它们。

所有这些报告均来自作者构建的自动日间交易应用程序。

视觉报告

散点图报告

散点图报告是比较两个变量的详细程度报告。在实际点上添加颜色和大小有助于可视化与这些变量有关的实际结果。

散点图报告有助于可视化与变量相关的结果。

鸣叫

盒须报告

该报告总结了散点图报告中的x和y值。 x轴值离散化为一组存储桶。

每个晶须(线)的末端代表离群值。黄色和浅蓝色条分别代表一个标准偏差范围的上限和下限。

盒子和晶须报告清楚地显示了异常值和偏差范围。

鸣叫

线性回归模型

该报告显示了x和y轴值之间的相关性, 以及线条的平滑度, 这可以用数学公式表示。包含R平方值以显示相关性的可靠性。

线性回归擅长显示x和y轴值之间的相关性。

鸣叫

总结

随着公司的发展, 通常你的数据库也会增长。

大多数组织最初不需要处理他们的需求的数据库专业人士或专门的数据科学公司。取而代之的是, 他们让IT员工承担多种职责, 或者俗话说, “戴很多帽子”。这在一定程度上可行, 但是最终你需要聘请专家。

本文档中列出的项目是识别你可能尚未意识到的数据库问题的快速简便的方法。希望它还介绍了如何构建一流的数据挖掘工具, 而又无需花费大量昂贵的软件许可。这样, 你将更好地了解通过向IT员工添加数据库专业人员可以为你的组织带来多少收益。

相关：开发用于二硫键研究的生物信息学数据库