当前位置：首页> BI-商业智能> TTNN-BI观点> 正文

探索“分析”之分门别类

作者：姜玲

2007/3/28 16:31:27

大中小

本文关键字： ttnn 2005年11期

昨天提到先分析问题再动手行事，接着来看看"分析问题"到底是个什么过程，拿些例子来说明。

最近有项将一组存储过程从sybase移植到oracle的任务，这项任务的工作量有多大？有哪些潜在的风险？以及该如何安排优先顺序呢？

有了这些问题，展开分析。借助excel来帮助分析是个不错的选择。首先在一个sheet上列出所有待移植的存储过程，在面对的问题域中，它就是分析的主体。

用excel帮忙的一个好处就是你在开始阶段，并不能确定从哪些角度去分析这些存储过程，excel可以灵活地增加一个属性作为区别它们。

例如最开始，规划了"过程名称"、"读取表"、"写入表"三个属性来描述这些过程。随着分析深入，要便于移植，还要列出每个过程传入的参数；再深入一些，需要区别每个过程移植需要的工作量几许，添加一个"工作量"属性来区别；可能他们之间还有些依赖关系，增加个"依赖"属性。最后再加上一个"优先级"属性，为不同过程标记顺序。如此，几乎就形成了描述存储过程的元数据。

这些属性的赋值比较简单，可以直接从过程的代码就能得到，例如参数、读取表、写入表等，有的则需要更进一步。

例如工作量的多少要看存储过程所依赖表的结构、逻辑变化是否大，有的新旧表结构不变，有的可能是字段名、程度有所调整，有的干脆表存放数据的意义都改变了。因此，可以将这些表提取出来，作为分析主体，放置另一张sheet中。为之添加"数据量级别"、"变动程度"等属性。

再比如存储过程中包含的语法元素，是否有游标处理？是否有不兼容的语法，如sybase下的_update..from语句。是否有动态sql？是否在过程中创建临时表？

通过excel来维护这种列表，可以轻松地使用自动筛选功能方便地查看各种不同类别的过程，例如最优先完成的，工作量最小的等等。

当然，还可以将这份列表导入数据库中，因为这是一份冗余量比较大的数据结构，非第三范式（例如过程参数和读取表没有关系）。在它的基础上建立一系列视图，例如过程读取表视图、过程参数视图、移植顺序视图等，可以更清晰地了解待移植过程信息。不过这有些脱离主题，就不在此多论。

OK，例子到此先暂停，可以看到"分析"的一个特性——分类。

分析是一个逐步分类的过程，当然是朝着目标的方向。如上例中描述，从参数、工作量、优先级等不同角度来区别过程，某个角度可能会引发另一个新的观察角度。例如从每个过程涉及到的依赖的表，可以根据这些表的结构变化情况来判断过程移植的工作量，工作量和依赖性又可以来判断其优先级。这里所说的"角度"，也可能称作是"类别"、"因素"、"属性"。

对这些不同的分类要给出恰当的名称，因此也可以将分析看作一个概念明晰化的过程。

可以看到这种分类和OLAP中的维度又多么相像，其实维度就是观察度量的角度，但显然OLAP中的维度就是分析过程的产物。例如对于一个销售量，我需要从日期、地区、产品种类等类别去区别它，每个维成员其层次、体系都已确定。而且OLAP已经比较确切地用在了数据分析这个领域中。
再用上例和数据挖掘中细分比较，也有几分相似。后者通过对一组若干变量数据集进行聚类，形成几种类别，而后者所依赖的变量大多都在分析者的脑中，更多凭借经验、感觉提取出最重要的因素。但其过程都是从若干角度将分析对象区分开来，最终将它们分成不同的类别。

责编：姜玲