国家电子政务外网安全等级保护实施指南新视角

9.2反馈循环数据仓库开发成功的关键在于数据体系结构设计者与DSS分析者之间的反馈循环，如图9-4所示。第9章迁移到体系结构设计环境167下载现存系统环境开始载入第一个主题区，继续载入并鼓励数据集市部门使用。警告：如果您等待清理现有系统而不进行反馈，您将永远无法建立数据仓库。

9.3 图9 - 5显示了企业的D S S需求路径，设计和建立数据仓库环境以支持企业的需求。除了D S S外，企业还有其他需求。图9 - 6展示了企业的操作型环境，状态混乱，数据未集成，系统老化且难以维护。操作型应用需求已发生变化。迁移方案只涉及D S S部分，是否可以在创建数据仓库时改善操作型环境的混乱呢？答案是在一定程度上可以进行重建工作，而不仅仅是美化操作型环境。

4.1 在确定适当的粒度级起点时，我们需要精确估算数据仓库将来的数据行数和所需的直接访问存储设备（DASD）。即使在最佳情况下，我们也只能进行估计。在建立数据仓库的初期阶段，仅需要一个数量级的估算。有一个计算数据仓库空间的算法，详见图4 - 1。首先确定将在数据仓库中创建的所有表，然后估计每张表中行的大小。确切的大小可能难以确定，但可以估计一个下限和一个上限。接下来，估算每张表在一年内的最少和最多行数，这是设计者需要解决的主要问题。例如，对于客户表，可以根据商业环境和公司的业务计划估计当前客户数量；如果没有业务数据，可以估计市场总体业务量乘以市场份额；如果市场份额未知，则可以使用竞争对手的业务量来进行估算。总之，需要从多方收集客户合理估算信息的一面开始。如果数据仓库用于存储业务活动，还需要估计客户数量以及每个时间单位内的业务活动量。同样的方法可以用于分析当前业务量、竞争对手的业务量、经济学家的预测报告等。一旦对一年内和五年内的数据单位数量进行了估算（采用上下限推测的方法），就需要计算索引数据所占的空间。对每张表中的每个键码确定键码的长度，并检查原始表中是否存在键码。现在，将每张表中的行数可能的最大值和最小值乘以数据的最大长度和最小长度，然后将索引项的数目与键码长度的乘积累加到总数据量中。计算每个已知表的行数和空间大小，重复这个步骤。

如果条件允许且经济可行，外部数据和非结构化数据可以直接存储在数据仓库中。然而，在任何情况下，都需要将外部数据和非结构化数据与其元数据一同登记，具体存储则依据其规模和访问频率来决定是否存入数据仓库。

7.3支持向下探察处理生成用于向下探察分析的基本数据是成功地完成向下探察处理的主要障碍，如图7-6所示。图7-6困难在于生成用于EIS处理的基本数据事实上，有一些研究表明，每花费1美元用于开发E I S软件和硬件，就要为向下探察准备数据花费9美元。之所以要夸大这个问题，是因为高级管理人员关于感兴趣的事情总是不时地改变主意。图7- 7显示了使高级管理人员感兴趣的事情总是不时变化的特性。某天，高级管理人员想了解公司的财务状况， E I S分析员花费很大精力找出了支持这个E I S需求的基本数据。第二天，意外地出现了一个生产问题，管理者又把注意力转向这个问题， E I S分析员就赶紧尽力收集高级管理人员需要的数据。第三天， E I S分析员又不得不将注意力转向发货中出现的问题。第7章高级管理人员信息系统和数据仓库147下载E I S软件和向下探察处理购买及安装E I S软件既快又容易。

星型连接数据模型作为数据仓库设计的基础，尽管在实际应用中存在一些缺点。图3-56展示了一个简单的二维数据模型，其中包含四个相互关联的实体。然而，仅从数据模型角度出发的设计容易导致数据的扁平化效应，实际数据仓库中的实体和它们之间的关系绝不是对等的。例如，订单实体需要处理大量数据，而其他实体的数据量较少。因此，在设计数据仓库时，需要考虑不同的处理策略，以应对数据量的不均衡。

在现有系统环境和数据仓库中，数据仓库和数据模型的应用十分广泛。图3-8详细解释了不同层次模型之间的关系，包括操作型数据仓库、部门个人数据类型和企业模型。操作型模型和数据仓库模型直接或间接地影响数据仓库的过程模型和企业模型。在数据库设计阶段，必须考虑性能因素，并在操作型数据中增加时间元素，优化键码。此外，根据需求适当增加导出数据的功能，以促进数据之间的人工关系。

在体系结构设计环境中，由于原始数据和导出数据的不同，数据分离是一个自然的扩展过程。尽管在图1-11中不太显著，但数据冗余在体系结构设计环境中很少见。发展数据仓库以支持操作型原子和数据仓库部门的个体体系结构层次，涵盖细节、粒度、领域狭隘、暂时性、逐日变化等方面，包括特定目的的当前值、集成的原始数据和启发式访问高可能性数据。

“国家电子政务外网安全等级保护实施指南”中提出了一种数据驱动的开发方法，指导数据仓库的建设和使用。然而，该方法在实际应用中存在一些局限性： 1. 线性工作流程与迭代开发的矛盾: 该方法倾向于线性工作流程，而实际的数据仓库建设需要不断迭代和优化。 2. 任务粒度和完整性问题: 方法中列举的任务缺乏必要的粒度区分，部分任务过于笼统，同时忽略了一些实际操作中必不可少的步骤。 3. 方法描述的抽象性: 该方法侧重于“如何做”，缺乏对“做什么”的明确定义，导致在具体应用中难以把握细节和处理特殊情况。 4. 缺乏对项目规模的适配性: 方法未能针对不同规模的项目提供差异化的指导，对于小型项目显得过于繁琐，对于大型项目又缺乏足够的指导性。 5. 项目管理与开发工作混淆: 该方法将项目管理与设计开发混为一谈，不利于项目管理的清晰化和专业化。 为了更好地指导数据仓库建设，建议对该方法进行优化，使其更加灵活、实用、可操作。