预算友好型数据挖掘指南

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

您的数据库源代码也不能这样说。 SELECT / FROM / WHERE / GROUP BY的标准查询，写在 SQL 的早期，今天仍然有效。 当然，这并不意味着关系数据库编程没有任何进步。 有，而且它们比技术更符合逻辑。

从 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关键字之前INSERT INTO表名。 一旦你有了一些功能性的数据集市表，就应该确定合并数据集市的机会； 查找使用相同表列表的报表查询，然后合并字段列表。 这需要更复杂的查询，尤其是当表列表增加时。 但是，只要您彻底测试查询，就可以在不中断正常业务流程的情况下进行每次增量更改。

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

OLAP 多维数据集

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

数据架构师有时会看到现有的 OLAP 多维数据集，只不过是一个使用多维数据集的简单仪表板，没有一个无法被 SQL 查询、数据仓库或预制报告替代的流程。 OLAP 多维数据集可以提供比预设报告更快的响应时间，但在大多数情况下，差异可以忽略不计。 您还可以从向下钻取功能中受益，但是，在向最终用户提供向下钻取功能之前，最好使用提供类似临时界面的预制报告。

这允许您记录最终用户正在运行的即席查询，然后您可以识别最终用户没有意识到可以创建的新预制报告。 由于在开发 OLAP 多维数据集时响应时间和向下钻取的改进通常都很小，因此在客户需要可以处理相关数据挖掘的数据库架构之前，没有必要向客户推荐它。 这是您真正可以给客户留下深刻印象并向他们展示他们的业务的一些东西，如果没有强大的数据库架构，他们可能永远不会知道。

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

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

可视化报告

散点图报告

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

盒须报告

此报告总结了散点图报告中的 x 和 y 值。 x 轴值被离散到一组桶中。

每个晶须（线）的末端代表异常值。 黄色和浅蓝色条表示上限和下限一个标准偏差范围。

线性回归模型

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

结论

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

大多数组织最初不需要数据库专业人士或专门的数据科学公司来处理他们的需求。 相反，他们让 IT 员工承担多项职责，或者俗话说，“身兼数职”。 这在一定程度上有效，但最终，您需要聘请专家。

本文档中列出的项目是识别您可能没有意识到的数据库问题的快速简便的方法。 希望它还涵盖了如何构建一流的数据挖掘工具，而无需在昂贵的软件许可证上花费大量资金。 通过这种方式，您将更好地了解通过向 IT 员工添加数据库专业人员可以使您的组织受益多少。