下载掌阅APP，畅读海量书库
立即打开
企业信息化规划实训将主要从研制职能域、业务过程、业务活动、用户视图分析、数据结构规范化、数据流分析、系统功能建模、系统数据建模等几方面进行。
本章在实训过程中，特别强调学生要拓展思路，结合自己熟悉的领域，多做练习，以提升自己的综合能力。
企业信息资源规划工作来源于信息工程的基本原理。约翰。柯林斯（JohnCollins）在为世界第一本信息工程专著所写的序言中说：“信息工程作为一个学科要比软件工程更为广泛，它包括了为建立基于当代数据库系统的计算机化企业所必需的所有相关的学科。”
“信息工程”的产生，是为了解决“数据处理危机问题”的必然结果，这是发达国家建立计算机企业初期和发展过程中曾遇到的问题，在迎接计算机时代到来的发展中国家，同样涉及到类似情况。突出的问题大体表现在：数据混乱、应用积压严重、应用开发效率低、系统维护困难等方面。
一些企业曾经花费大量人力财力物力购买并应用的系统，经过一段时间的使用后却发现系统不适用而不得不放弃。美国国防部开发的十个自动化系统，1977年的研究表明，这十个系统都存在着要修改的问题，而且这种修改耗资巨大。时至今日，一些企业中轻视信息规划工作而导致损失的事情仍时有发生。
一些企业中，无用的或效率很低的应用程序越积越多，即形成“应用积压”的问题。一方面，计算机系统的功能没有正常、高效地发挥出来，大量的应用程序或功能处于“无用”状态；另一方面，计算机部门或开发公司对于尽快满足最终用户的需求无能为力，许多用户需要的很有价值的应用项目，却因为计算机部门或开发公司负担过重而不能及时开发。开发人员承担着最终用户新需求压力日益增加、旧应用堆积严重且维护愈加困难的双重压力之中。
为了解决此类问题，计算机业界不断推出更好更快的开发工具、管理思想。如面向对象开发工具、软件工程思想等。然而，这些工具和思想方法主要是从开发者的角度出发的，提出的有利于完善开发过程、提高开发效率、尽量避免未来可能出现的各种冲突而做出的一种权宜。例如，开发方的系统分析人员会不断诱导最终客户，让其所提出的功能需求尽可能往自己已开发的功能方面靠拢；在需求管理方面，通过严格签字手续等方式约束最终客户过多的需求增长等。诚然，这些做法有利于保证最终双方约定功能的稳定性和系统的健壮性，但却不利于满足企业不断增长的正常需求，于是存在着系统用一段时间就显得“过时了”的情形。
信息工程（Information Engineering，IE）是美国管理及信息技术专家詹姆斯。马丁（James Martin）在20世纪80年代初提出的一整套建立“计算机化企业”的理论与方法。信息工程的基本原理是：
（1）数据位于现代数据处理系统的中心
借助于各种数据系统软件，对数据进行采集建立和维护更新。使用这些数据生成日常事务单据，例如：打印发票、收据、运单和工票等。当企业需要进行信息咨询，对这些数据进行汇总或分析，得出一些图表和报告。为帮助管理人员进行决策，要用这些数据来回答“如果怎样，就会怎样”一类问题。数据库管理人员检查某些数据，以确信是否有问题。所有这些都是以数据为中心的。
（2）数据是稳定的，处理是多变的
一个企业所使用的数据类很少变化。具体来说，数据实体的类型是不变的，除了偶尔少量地加入几个新的实体外，变化的只是这些实体的属性值。对于一些数据项集合，我们可找到一种更好的方法来表达它们的逻辑结构，即稳定的数据模型。这种模型是企业所固有的，问题是如何把它们提取出来，设计出来。这些模型在其后的开发和长远应用中很少变化，而且避免了破坏性的变化。在信息工程中，这些模型成为建立计算机化处理的坚实基础。虽然企业的数据模型是相对稳定的，但是应用这些数据的处理过程却是经常变化的。
事实上，最好是系统分析员和最终用户可以经常地改变处理过程。只有建立了稳定的数据结构，才能使行政管理或业务处理上的变化能被计算机信息系统所适应，这正是面向数据的方法所具有的灵活性，而面向过程的方法往往不能适应管理上变化的需要。
（3）最终用户必须真正参加开发工作
企业高层领导和各级管理人员都是计算机应用系统的用户，他们都在计算机终端上存取和利用系统的数据，是最终用户。正是他们最了解业务过程和管理上的信息需求，所以从规划到设计实施，在每个阶段上都应该有用户的参与。在总体规划阶段，有充分理由要求企业高层领导参加：
首先，信息资源规划是企业的重要资源，对于如何发挥信息资源作用的规划工作，高层领导当然要亲自掌握；其次，总体规划要涉及企业长远发展政策和目前的组织机构及管理过程的改革和重新调整，而只有高层领导才能决定这些重大事情。各管理层次上的业务人员对业务过程和信息需求最熟悉，单靠数据处理部门无法搞清用户的需求；最后，要使频繁的业务变化在计算机信息处理上得到及时的反映，满足管理上的变化要求，也是数据处理部门所不能完全胜任的。这样，用户的数据处理部门的关系应加以改变，用户要参与开发，由被动地使用系统变为积极地开发系统；数据处理部门由独立开发变为培训、组织、联合用户开发。
从上述的基本原理和前提出发，马丁阐述了一套自顶向下规划（Top-DownPlanning）和自底向上设计（Bottom-Up Design）的方法论。他指出：建设计算机化的企业需要该组织的每一成员都为这一共同目标进行一致的努力，这就包括采用新方法论的总体策略，并要求每一成员对此应用有清楚的理解。几经修改，他在《信息系统宣言》一书中提出了“信息工程”组成的13块构件（如图2.1）。这13块构件是相互联系的，构成一个统一体——信息工程方法论的宏伟大厦。
信息资源规划（Information Resource Planning，IRP）即是为解决此一问题提出的有效方案，它是指对企业生产经营活动所需要的信息，从产生、获取，到处理、存储、传输及利用进行全面的规划。与软件工程不同，信息资源规划的需求分析强调对全企业、企业的大部分或企业的主要部门进行分析，是一种全局性的分析，需要有全局观点。同时，分析过程需要业务人员参与，特别强调高层管理人员的重视和亲自参与工作。要求业务人员在需求分析阶段起主导作用，系统分析人员起协助辅导作用，整个需求分析过程是业务人员之间、业务人员与计算机人员之间的研讨过程。信息资源规划的数据需求分析要建立全局的数据标准，这是进行数据集成的基础准备工作。即全局性的数据标准化工作要提前开始并集中统一地进行，不是等到应用项目各自完成后再分散地进行（此时将无法进行标准化控制）。
图2.1 信息工程方法论的组成
大体来说，信息资源规划包括需求分析阶段和系统建模阶段两大部份。其中，需求分析阶段包括功能需求分析（定义职能域、定义业务过程、业务活动分析）和数据需求分析（用户视图分析、数据流分析、数据结构规范化）等工作，系统建模阶段包括系统功能建模（定义子系统、定义功能模块、定义程序模块、价值流分析）和系统数据建模（定义主题数据库、定义基本表、子数据模型、全域数据模型）等工作。
在信息工程方法论中，用“职能域－业务过程－业务活动”这样的层次结构来把握企业功能，称为企业模型（Enterprise Model）或业务模型（Business Model）。
业务模型的研制可分为三步：
第一步，企业的职能域模型；
第二步，扩展上述模型，识别定义每个职能域的业务过程；
第三步，继续扩展上述模型，列出每个过程的各项业务活动。
建立正确的业务模型，是一项复杂而又细致的认识活动。主要依靠企业高层领导和各级管理人员来分析企业的现行业务和长远目标；按照企业内部各个业务的逻辑关系，将它们划分为若干职能区域，弄清楚各职能区域中所包含的全部业务过程；再将各个业务过程细分为一些业务活动。
职能域（Function Area）是指一个企业或组织中的一些主要业务活动领域，如工程、市场、生产、科研、销售等。
★小提示：研究职能域的注意事项
研究定义职能域是信息资源规划第一阶段的一项重要任务，不能简单地将职能域理解为现在企业的机构部门名称，而是从业务发生的角度来进行重新认识和分析。
请更多关注现有和未来的业务需求，不要过多地被现有的部门名称所约束。职能域应该理解为一个实现某些职能的业务集群。
【参考2.1】某餐饮企业的职能域模型：
某餐饮企业，为顾客提供早餐、中餐和晚餐。公司高级厨师领域一个新菜系研究小组，负责每月创新至少一个新菜式。其他工作有：账务组，负责收款找零、每日将余款存银行；清洗组，负责洗碗、洗锅灶等工作；服务组：负责传菜、收拾餐馆、轮值打扫卫生；采买组，负责采购菜品或与供货商联系供货；仓储组，负责保证菜品材料的用量和新鲜，仓储组有时也会配合跟采买组一起去进货；烹调组，负责按照高级厨师研制的、客户点餐的菜品烹调，高级厨师在不研制新菜系时也与普通厨师一同烹调。公司未来还考虑与一些知名的团购网合作，提供团购点餐，未来也考虑有自己的网上订餐业务开展。
根据上述情况，考虑未来的业务发展，可以将职能域作如下考虑：
表2.1 某餐馆企业的职能域模型
【实训练习2.1】根据以下文字材料，研究天华电动自行车制造厂的职能域模型：
天华电动自行车制造厂主要从事电动自行车生产制造工作，其材料从市场采购，另外还有一个配套厂家为其生产发动机，企业的财务部门负责全部的财务管理工作，仓库负责材料与半成品、成品的收、发、保管等工作，采购与仓储目前皆由一个叫“物资处”的机构管理，不过物资处虽有权决定采购的材料，却在仓储管理方面无法细化。企业另外有一个研究所，专门研究和开发新型的电动自行车和改进已有的老型号。企业的生产车间是企业的最大部门，负责制造、组装各类电动自行车。企业的全部销售工作交给企业另设的销售公司打理，他们负责企业的外地市场和本地市场。外地市场主要是建立批发点或寻找总代理商，本地市场则是寻找二级代理或进驻相应的市场，未来他们打算开拓网络市场，可能会以B2C或B2B的方式进军电子商务领域。企业的老总们主要是考虑企业的经营计划和未来发展战略等工作。另外有一个后勤部门负责后勤工作，人事部门主要负责企业的人力资源管理（包括薪资管理、人员培训等工作）。由于培训工作越来越受重视，企业未来可能将培训工作独立出来形成独立的培训部以满足知识型企业管理的要求。企业很重视物料管理工作，对于物资的配送设有专门的配送部门，对外的配送也与第三方物流公司联系紧密。由于电动自行车在有些城市交通中处于受限制的领域，国家对于电动自行车的标准（超过标准就算机动车，需要纳入机动车管理，用户手续上更复杂）有要求；另外，为了保护自有的研究成果（专利产品）以规避未来可能的经济和法律风险，企业决定未来要在法律方面成立专门的机构。
请根据上述资料，研究该企业的职能域，并以EXCEL表格的方式列出你认为合适的职能域。
【实训练习2.2】根据你熟悉的某个领域（如餐饮业、手机业、平板电脑业、化妆品业、金融业、人力资源业、蔬菜种植业、水果种植业、鲜花种植业、畜牧业、园艺业、徒步运动业、酒店业、渔业、酒类业、小商品业、医药品业、汽车业、房地产业、旅游业、影视业、休闲食品业等）的情况，以EXCEL表格的方式定义一套的职能域。
每个职能域都包括一定数目的业务过程（Process），业务过程是职能域的细化，小型企业通常职能域在10个以内，涉及到约30－100个业务过程；中型企业职能域则可能在10多个，涉及到更多的业务过程（如表2.2）。
【参考2.2】一个中型制造厂的职能域和业务过程：
表2.2 一个中型制造厂的职能域和业务过程
职能域和业务过程的确定，应该独立于当前的组织机构。因此，为强调这一点，应称为“逻辑职能域（Logical Functional Area）”。组织机构可能变化，但企业仍然会执行同样的职能和过程。有的企业的组织机构形式每隔几年就改变一次，但一些主要的业务过程却是保持不变的。职能域与业务过程的确定，主要应该考虑独立于当前组织机构的职能，因而会有这样两种情况：
（1）经逻辑分析而得出的职能模型中可能包括这样的职能域，它横跨两个或多个现行系统的业务部门；
（2）对现行系统所列出的业务过程可能会有这样的一些过程，它们分别属于不同的职能域，但功能相同或相近。
识别业务过程一般来说缺乏较好的形式化方法，主要依靠有经验的业务人员和分析人员进行反复提炼。不过，也可以提出一种参考模式，它能帮助以套用在当前企业上，发现并列出其业务过程。这种参考模式就是：“产品、服务和资源等各型企业的四阶段物料生命周期”模式，任何企业或组织都可归入产品型、服务型或资源型（如表2.3）。
表2.3 根据企业物料生命周期划分的参考业务过程
业务过程的确定可以对照组织中各部门负责人来考虑，可以以矩阵表的形式，确定进行业务过程调查的访问对象。矩阵表的横向标题行为各职能域和细化的业务过程，纵向标题则为各部门的负责人，表中间则体现出参与状态（主要负责、主要参与、部门参与）。这种方式可以帮助建立业务过程而不致遗漏，并使每个业务活动的确定都能找到相应的负责人。
规划小组应该力求确定出所考察的企业或部门的全部业务过程，列出一张表；再从表中删去重复的业务过程。不应该为减少业务过程的数目而人为地合并一些业务过程。通常，一个大型企业会有100个或更多的业务过程。
从事过企业模型分析工作的人，通常有一些体验，值得初次从事这方面工作的人员借鉴：
（1）开始以为业务过程的定义没有毛病，可是规划工作进行一段时间再来复查时，会发现有许多不妥之处，还要继续修改。
（2）业务过程应该按照自顶向下规划的目的来确定，这些业务过程是企业运营的基本工作，应该不受报告层次或个体负责人变动的影响。
（3）一些业务部门的职能相互覆盖，其表现是有相同的或相似的业务过程，因此，职能域和业务过程的定义是一种逻辑模型化，不能简单地按现有机构、部门、职务来定义职能域和业务过程。
（4）在建立企业模型工作中，高层管理人员和最终用户的参与是很重要的，只有他们才知道这个企业是怎样真正工作的。许多规划负责人开始总是希望计算机系统分析人员起较重要的作用，其实不然，用户所扮演的角色要比他们最初想象的重要得多。
【实训练习2.3】根据上一节中完成的天华电动自行车制造厂的职能域模型表，参考上述两表的业务过程模型，定义出该企业的业务过程，并以EXCEL表格方式表现（请参考表2.2）。
【实训练习2.4】根据上一节中你熟悉的某个领域的情况定义的职能域，定义该领域各职能域的业务过程，并以EXCEL表格方式表现（请参考表2.2）。
在每个业务过程中，都包含一定数目的业务活动（Activity）。业务活动是企业功能分解后最基本的、不可再分解的最小功能单元。对业务活动命名可采用一个动宾结构，以表示该活动所执行的操作。
例如，前面提到的“F0402采购”业务过程可以包含下述业务活动：
●提出采购申请单
●选择供应商
●编制采购订单
●根据订单监督各项交货
●处理异常情况
●记录供应商执行合同情况
●分析供应商执行合同情况
一般每个业务过程含有5至30个业务活动，在一个小型的公司里可能有几百个业务活动，而在一个大型复杂的公司中可能有几千个业务活动。
在做业务分析时，一般是把职能域分解成多个功能，每个功能再分解成更低层的功能，这样逐级向下分解，直到产生最基本的活动为止。
某企业制造部功能逐级向下分解实例（如表2.4），其中不能分解的最低层的功能就是业务活动。
表2.4 某企业的功能分解初步
需要注意的是，表2.4中的“功能分解”有的分解出三层，有的分解出两层，由于对一个职能域只能统一分解出两层——业务过程、业务活动，所以需要做一些调整。调整的基本原则是合并同类项、将业务活动升级到业务过程或将业务过程降级到业务活动。
职能域的划分、业务过程的识别和定义、业务活动的分析和确定，都需要规划人员与企业从高层管理人员到基层业务人员的共同努力，由粗到细地加以完成。当初步的企业模型以图表形式得出以后，最后还要进行认真的复查和审核。
例如，对“材料”职能域调整后见表2.5。
表2.5 调整后的业务过程和业务活动（局部）
K.温特尔博士总结了活动分析工作，提出活动模型中每一活动应该是凝聚性活动（Coherent Activity），为寻求这样的活动，列出如下特征：
（1）一个凝聚性活动产生某种清晰可识别的结果
这种结果可以是销售一件产品、一个想法、一个决策、一组方案、一份工资单、一次顾客服务等，应该通用一个简单的例子来说明这个活动的目的或结果。相比之下，一个非凝聚性的活动，总是产生不可确定的结果，或者几个无关的结果。
（2）一个凝聚性活动有清楚的时空界限
在这个确定的时间和空间里，可清楚地指出，谁在这个活动中工作和谁不在这个活动中工作。活动有时间性，可以确定开始时间和结束时间，可以测定超过的时间。凝聚性的活动之间的转换具有清楚的标志，而非凝聚性的活动则互相重叠混杂，不能确定在何时何地进行。
（3）一个凝聚性的活动是一个执行单元
它明确规定一个人或一个小组去产生结果，活动的管理职责也有类似的明确规定，由一个人或一组人负责。而一个没有明确定义的活动可能由一些不确定的人去执行，谁应该做什么是不明确的，他们的工作虽有某种协同，但不是作为一个整体去工作，互相之间缺乏良好联系和配合。
（4）一个凝聚性的活动在很大程度上是独立于其他活动的
如果一个活动按某种方式与另一个活动相互作用十分紧密，就可以把它们看作一个活动。在执行一个活动的同一组人之间的联系，当然要比在不同活动中的联系频繁得多。
分析比较表2.4那样所有列出的基本活动，会发现有的活动不具备凝聚性特征，这就需要进行调整；有的活动是重复的或者相当接近的，就要清除重复活动的多余部分，合并相似的活动，才能得出良好的业务活动模型。
经过对业务活动的分析以及识别所有的凝聚性活动，再按相互联系的紧密程度分组，就可以积聚成一些业务过程。对业务过程再组合，就可以形成若干个逻辑职能域，以作为业务功能的信息系统基础。也就是说，逻辑职能域是对按企业的部门划分的职能域的修正。同样，按业务活动分析组合起来的业务过程模型，是对按业务人员的经验初步建立起来的业务过程模型的修正。这个过程又是一个从细到粗的逆过程，是对前两节中从粗到细的顺过程的迭代。
复查要在核心小组的组织下，除充分发挥用户分析员的作用外，还要有层次地与管理人员对话，请他们进行仔细的审查。复查可以从上向下进行，也可以从下向上进行，或交替进行。从上到下进行，是指首先看职能域划分和定义有没有问题，再看业务过程的识别和定义有没有问题，有问题就进行修正；从下向上进行，是指首先复查业务活动功能是否分解到基本活动，每一活动是否符合凝聚性特征？有无冗余的活动需要删除、有无类似的活动可以合并？当这些都确定之后，再看哪些活动组合在一起作为一个业务过程？与以前确定的过程有何矛盾？如果有矛盾就需要调整，最后再由业务过程组合成职能域。经过复查，可以认为所建立的企业模型已经是一种逻辑模型，这种业务模型应该具有下述特点：
（1）完整性
这处模型应该是表示组成一个企业的各个职能域，各种过程和活动的完整图表。
（2）适用性
这种模型应该是理解一个企业的合理有效的方法。在每一个分析层次上职能和活动的确定，对于参与工作的管理人员来说都应该是觉得自然和正确的。
（3）永久性
只要企业的目标保持不变，这种模型就应该是正确的和长期有效的。有些企业定期对自己的组织机构进行调整，或定期改变管理工作方式，但无论怎样，一些相同的职能必须继续执行。这种企业模型是企业改组时是很有用的，而与数据的管理方式是无关的，即不管数据是文件、数据库还是纸质的。
建立正确的业务模型，是一项复杂而细致的认识活动。主要依靠企业高层领导和各级管理人员来分析企业的现行业务和长远目标；企业内部各种业务的逻辑关系，将它们划分为若干职能域，弄清楚各职能域中所包含的全部业务过程；再将各个业务过程细分为一些业务活动。这是一个多人参与的反复过程，因此，进行业务分析建立业务模型的过程，是对现行业务系统再认识的过程。
提出业务模型是建设计算机化化企业的基础性工作。所谓企业的计算机化，是指将人工的业务过程和业务活动，变为以计算机为信息存储处理工具的过程和活动。由于电脑和人脑各自的特性，并非简单将日常手工工作照搬到电脑中来，而是在新的工作方式中各自得到发挥，使原来的过程和活动发生某些根本性的变化。因此，首先搞清楚现行系统的业务过程和业务活动，然后再考虑引进计算机系统对这些活动进行调整和改进，才是业务模型分析工作的实质。
【实训练习2.5】根据上两节中完成的天华电动自行车制造厂的职能域模型表、上一节中定义的业务过程，定义出的该企业的业务活动，并以EXCEL表格方式表现（请参考表2.2、表2.3、表2.4、表2.5）。
【实训练习2.6】根据上两节中你熟悉的某个领域情况定义的职能域，上一节中定义的该领域各职能域的业务过程，定义出该企业的业务活动，并以EXCEL表格方式表现（请参考表2.2、表2.3、表2.4、表2.5）。
虽然通过电子表格工具可以分别就职能域、业务活动、业务过程进行分析，但直观性不够。为了能够更直观地进行建构，我们引入思维导图的建构方法，使职能域的建构工作更加直观化、条理化。
思维导图绘制工具很多，常见的有Xmind（下载地址：http://www.xmindchina.net）、亿图思维导图软件MindMaster（下载地址：http://www.edrawsoft.cn/mindmap）、Mindmanager（下载地址：http://www.mindmanager.cc）、FreeMind等，用户可根据自己的需要选择下载。
本书以目前流行度最高的Xmind为建构软件，引导读者学会方便地构建职能域－业务活动－业务过程。
XMind采用Java语言开发，具备跨平台运行的性质，且基于EclipseRCP体系结构，可支持插件。XMind的程序主体由一组插件构成，包括一个核心主程序插件、一组Eclipse运行时插件、一个帮助文档插件和一组多语种资源文件插件。Eclipse用户会对它的界面非常亲切。
XMind 应用EclipseRCP软件架构，可以支持其他开发人员为其编写插件，为XMind增添新的功能或改进其设计。由于大部分插件是用Java语言编写，用本地语言编写的代码也针对各不同操作系统有不同版本，所以XMind理论上可以运行在几乎所有操作系统上，包括所有64位的操作系统，XMind支持Windows，Mac，Linux，iOS以及浏览器。
XMind 的文件扩展名为.xmind。.xmind本质上是由XML+ZIP的结构组成，是一种开放的文件格式，用户可以通过XMind开放的API为其开发插件或进行二次开发。
XMind能与用户其它的Office软件紧密集成，收费版的“.XMind”文件可以被导出成Word、PowerPoint、PDF、TXT、图片格式等，也可以在导出时选择“仅图片”、“仅文字”，还是图文混排，所得到的成果直接可以纳入用户的资料库，或用其他编辑软件打开编辑。此外，XMind还支持导入用户的MindManager和FreeMind文件，使得大量用户在从这两个软件转向XMind时，不会丢失之前绘制的思维导图。
图2.2 Xmind新建空白图
安装好Xmind之后，打开时先显示出“新建空白图”的界面，点击此按钮以创建一个新的空白图，并且在屏幕出现一个“中心主题”的字样。我们可以把此“中心主题”理解为最顶层（第1层）、肇始端，紧接着，按几下Enter键，就分别在其下建立了“分支1”、“分支2”、“分支3”等层次——这些分支可以理解为第2层（如图2.3）。
图2.3 Xmind中按下Enter键创建下级分支
如果要继续建立更深的层次（如第2、3层）则不能再按Enter键。而是要首先选择需要扩展的分支（例如选中“分支1”），再按下键盘上的Insert键，则出现了一个“子主题1”，如果要建立“子主题2”则有两种操作：一种是继续保持选中“分支主题1”按Insert键；第二种是选中“子主题1”按Enter键。
通过Enter和Insert键的多次操作之后，可以形成复杂的层次结构关系（如图2.4）。
图2.4 Xmind中结合Enter和Insert键创建的多层分支
虽然做出了Xmind的层次结构，但其格式其实可以更丰富。
选中任一主题，点击屏幕右侧工具栏中一个刷子形状的按钮，可以展示出主题与分支主题的定义（如图2.5，左侧为选中中心主题时的格式、右侧为选中子主题时的格式）。
其中“结构”可以定义为“组织结构图”、“树状图”、“逻辑图”、“水平时间轴”、“垂直时间轴”、“鱼骨图”、“矩阵”等多种类型。
其中“我的样式”则可以选择多种系统预定义的样式组合，以实现不同的风格。
其中“文字”可以选择字体、字号、大小写、字体颜色等跟文字定义相关的内容。
其中“外形和边框”则对中心主题或的外形或边框的形状、颜色、粗细等进行设置。
其中“线条”指对连接线的设置，可以设置粗细、线型、线条颜色。
其中“编辑”是对分支主题或子主题的设置，可以设置为多级编号、分隔符等。
图2.5 Xmind中主题与分支主题格式的定义
除了对主题格式的设置以外，还可以对画布格式进行设置。点击画面中空白处（不要选择任何主题），格式里面将显示画布格式的设置。
其中包括“背景色”设置、“墙纸”设置、“图例”设置、“高级”设置（线条渐细、渐变色效果）、“彩虹色”设置、“信息卡”设置，这些设置能够使画面的表现效果更加丰富。
图2.6 Xmind中画布格式的定义
这里以某运动APP的设计与开发为例，分析了所需要完成的工作（如图2.7），分析的过程应该是“由粗到精”，并且分析的过程应该既可以独立思考、又可以小组讨论的方式进行。
完成后点击“文件-保存新的版本”（或按热键Ctrl_S）以保存.Xmind文件；然后，再点击菜单“文件－导出－图片”，再点击“下一步”，并定义“至文件”的路径以保存为一张图片文件。读者可以参考此示例，独立完成自己的职能域-业务过程-业务活动甚至更细节功能的分析与绘制。
直接保存的.Xmind文件是源文件，可以继续修订，并在设计开发小组内分享；导出的图片文件则主要用于发布于外部用户，让外部用户在没有安装.Xmind文件的情况下也能分享。
★小提示：如何管理复杂图形
Xmind绘制的图形如果非常复杂，不利于用户观看。为了能够管理复杂图形，可以从以下三方面着手：
一是缩放功能，在画布右下角默认显示为100%，可以点击此百分比左右两侧的加减符号以缩放整个画布；
二是折叠功能，在每个子主题之前的连接线上有一个带圆圈的减号，点击此减号，则整个子主题的分支都被折叠起来，原来带圆圈的减号也变为带圆圈的加号了；
三是新增画布功能，在整个画布的左下角，有一个“画布1”的页标，用鼠标右键点击此页标，将会弹出“复制画页”、“新画布”、“彩色标签”等选项的弹出菜单；根据需要定义不同的画布，将复杂的功能分散到不同的画布中可以有效降低复杂度。
图2.7 Xmind绘制某运动APP运营设计与开放
数据需求分析是信息资源规划中最重要、工作量最大且较为复杂的分析工作，要求对企业管理所需要的信息进行深入的调查研究。信息工程的数据需求分析与软件工程的数据需求分析的区别在于：信息工程的数据需求分析强调对全企业或企业的大部分进行分析，就像业务分析一样，要有全局的观点，要建立全局的数据标准，进行数据集成的奠基工作；而软件工程的数据需求分析并不这样要求，只是根据具体的应用开发项目的范围进行调查，即使范围较大（涉及多个职能域）也是分散地进行各程序模块所需数据调查，因此它无须建立全局的数据标准。
信息工程的数据需求分析体现了面向数据的思想方法，从用户视图的调查研究入手，要求管理和计算机技术两类人员密切合作，认真分析企业各管理层次业务工作的信息需求，同时进行正规的信息资源管理工作，建立起各种基础标准。
用户视图（User View）是一些数据的集合，它反应了最终用户对数据实体的看法。基于用户视图的信息需求分析，可大大简化传统的实体－关系（E-R）分析方法，有利于发挥业务分析员的知识经验，建立起稳定的数据模型。
用户视图的定义与规范化表达包括：
用户视图标识、用户视图名称、用户视图组成和主码。
用户视图作为企业里各管理层次最终用户的数据实体，是一个非常庞杂的对象集合。在手工管理方式下，各种各样的单证、报表、账册不仅是数据的载体，而且还是数据传输的介质，甚至还是数据处理的工具。上级管理人中经常不经严格分析就“设计”出一些结构不科学的表格要求下级填报，尽管大家整天都在填表，但仍然做不到及时、准确、完整，有很多工作又显得重复与浪费，无法实现实时信息处理。进行数据分析，就是要从根本上结束这种局面，为此必须较彻底地清理一下长期以来一直忽视的那堆“乱表”，做好简化与规范工作。为此，首先要有一套科学的方法对所有用户视图进行分类。
用户视图分为三大类：输入大类、存储大类、输出大类。
每大类下分为四小类：单证/卡片小类、账册小类、报表小类、其他小类（记录显示）。
进行用户视图登记，需要做好如下规范：
（1）用户视图编码规则
用户视图标识是指它的一种编码，这对全企业的用户视图的整理和分析理学必要。
用户视图标识的编码规则如表2.6：
表2.6 用户视图标识编码规则
其中：
大类（流向）编码取值：1＝输入，2＝存储，3＝输出
小类（类型）编码取值：1＝单证，2＝账册，3＝报表，4＝其他
序号：01~99
（2）用户视图名称
用户视图名称是指用一条短语表示用户视图的意义和用途。
例如：
用户视图标识：D041309
用户视图名称：材料申报表
这里用户视图标识编码的具体意义是：“04”代表第四域“物资”，“1”代表“输入”，“3”代表“报表”，“09”代表同一大类同一小类中的第9个。
（3）用户视图生存期
用户视图生存期是指用户视图在管理工作中从形成到失去作用的时间周期。用户视图生存周期类型为：动态，日，周，旬，月，季，年，永久。用户视图生存周期可细分为“用户视图生命周期”和“用户视图保存周期”两个子项，其中前者是指该数据项的生效时间范围，而后者指保存的时间范围。有些用户视图的数据虽然已经失效，但其数据仍然具有历史统计意义，在未来某个时间可能会用于数据挖掘或数据分析工作，因此保存周期应该是一个较长的时间，一般至少为“年”，甚至为“永久”。
（4）用户视图记录数
用户视图记录数是指把它理解为一张表的行数，记录这个数据主要用于最后统计相关的数据量。最终得到统计的数据量将可用于规划与统计整个系统的数据量，甚至最终可以作为购置硬件的理论依据。
统计用户视图的数据量由用户视图数据项表（如表2.7）和用户视图生存周期与数量统计表（表2.8）来完成。为了今后统计方便，这两个表最好使用EXCEL电子表格来完成。
例如，“D041309材料申报表”是月表，每月计有5张表，每张表平均有30行，那么，该视图的记录数应该是：5×3＝150
用户视图主要来源于对该企业的调查，具体来说可以从搜集该企业现存的报表开始，深入分析该企业应该使用的数据项。有时，搜集到的企业报表将会非常复杂，甚至表中套表；有时，多张表之间又会有内容重复或混淆的地方；有时，企业实际存在的数据根本没有任何单据或报表的存在，只是口头说说……诸如此类纷繁复杂的数据项需要认真清理、分析，最后以用户视图数据项表的形式，逐一完善、整理并最终形成可用的表格（如表2.7）。
表2.7 “D031101图书证表”用户视图数据项表
表2.7中“D031101图书证表”用户视图总计有11个数据项，这些数据项的长度合计是67。根据图书证表的办理人数估计（假设每人只办一个证，总共最多有200,000人办理），那么年数量应该是67×200,000＝13,400,000。
同理，假设“D031102图书借阅记录”用户视图总计有9个数据项，这些数据项的长度合计是119，而年记录数是500,000，那么年数量应该是119×500,000＝59,500,000。再假设“D031103图书日查询记录”用户视图总计有12个数据项，这些数据项的长度合计是82，而日记录数是12,000，那么年数据量应该是82×12,000×365＝359,160,000（如表2.8）。
表2.8 用户视图生存周期与数据量统计表
最后，将整个系统的全部视图的年数据量进行汇总，即可估算出所需开销的数据大小。这些数据可以用于程序设计时进行数据处理效率的考虑，也可以用于考虑购买硬盘等存储设备的大小。
★小提示：主键与数据类型
● 主键
主键是被挑选出来，作表的行的惟一标识的侯选关键字。一个表只有一个主关键字。主关键字又可以称为主关键字。
主键（Primary Key）中的每一笔资料都是表格中的唯一值。换言之，它是用来独一无二地确认一个表格中的每一行资料。主键可以包含一个或多个数据项。当主键包含多个数据项时，称为组合键（Composite Key）。
每张二维表中的主键是唯一确定的、非空的数据项，主要用于该表的唯一编码，有时用两个或两个以上的数据项共同组成组合键以达到更复杂的唯一性。
● 数据类型
数据类型的出现，是因为电脑内存有限。把数据分成所需内存大小不同的数据，编程的时候需要用大数据的时候才需要申请大内存，就可以充分利用内存。
为了今后更好地将用户视图移植到数据库设计中，可以先简单地将数据类型做基本的定义，简单地划分为：字符型（长度为1一255）、数值型（总长，小数位长）、日期型（固定为8）、时间型（固定为6）、逻辑型（长度固定为1）、文本型（长度255以上）。
以后的数据库设计中，将充分依据这些基本的类型，设计出更加复杂、更能提高程序运行效率，更好地满足数据库复杂性要求的、更精细的数据类型来。
【实训练习2.7】参考前几节中完成的天华电动自行车制造厂的职能域模型表、业务过程、业务活动，以EXCEL表格方式编制该企业的整个系统所有用户视图数据项表和用户视图生存周期与数据量统计表（请参考表2.7、表2.8）。
【实训练习2.8】参考前几节中你熟悉的某个领域情况定义的职能域、业务过程、业务活动，以EXCEL表格方式编制该领域的整个系统所有用户视图数据项表和用户视图生存周期与数据量统计表（请参考表2.7、表2.8）。
完成用户视图之后，很多人会认为自己的数据项结构是合理的，其实细分析之下，可能还不规范；不规范的数据项结构是无法用于最终的程序设计等方面的。这就需要进行数据结构规范化。管理工作中经常有一些复杂的表格，有的是表中套表，因此用户视图编制时需要进行分析和一定程度的规范化工作。前一节中仅提到了用户视图项的编制，并未对其进行深入细致的规范，适当的规范不仅有利于计算机处理，还有利于数据库设计，同时也符合人类思维逻辑的理解。
用户视图可以理解为关系数据库的雏形，而关系数据库则是以关系模型为基础的数据库，它利用关系描述现实世界。一个关系既可用来描述一个实体及其属性，也可用来描述实体间的一种联系。关系模式是用来定义关系的，一个关系数据库包含一组关系，定义这组关系的关系模式的全体就构成了该库的模式。
关系实质就是一张二维表，它是所属性的笛卡尔积的一个子集。从笛卡尔积中选取哪些元组构成该关系，通常是由现实世界赋予该关系的元组语义来确定的。关系之间存在着数据依赖，它是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系，是现实世界属性间相互联系的抽象，是数据内在的性质。
比如，一个专业有若干学生，而通常一个学生只属于一个专业；一个系有多个专业，而一个专业只属于一个系；一个学院有多个系，而一个系只属于一个学院；一个系只有一名系主任；一个学生可以选修多门课程；每个学生每门所学课程都有一个成绩。
在企业信息化规划初期，由于未进行相关思维训练，极易将这种数据间的依赖关系搞混，并且容易形成将多个数据依赖关系未加区分地揉进一个用户视图（二维表）中，形成人为的数据项混乱。为了规避这种情况，需要对数据结构按范式进行重新规划。
范式是符合某一种级别的关系模式的集合，关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。目前主要有六种范式：第一范式、第二范式、第三范式、BC范式、第四范式、第五范式。满足最低要求的叫第一范式，简称1NF。在第一范式基础上满足一些要求的为第二范式，简称2NF，依次类推。
为了在信息规划的实践工作中简化范式，通常在只规范到第一、第二、第三范式。
数据项之间的关系有：一对一、一对多、多对多三种情形。对用户视图的所有数据项用这些基本关系进行分析，就会发现它们之间在结构上的问题。
第一范式是指一个关系模式中的所有属性都是不可再分的基本数据项，如果存在复合数据项，那么还需求继续细分出来，直到不可再分为止。在任何一个关系数据库系统中，第一范式是对关系模式的一个最起码的要求，不满足第一范式的数据库模式不能称为关系数据库。
为了能够更好地理解第一范式，下面以某公司的“月工资表”结构来说明，细分到哪个程度的数据项才符合第一范式（如表2.9）：
表2.9 某公司月工资表基本结构
这里“奖金项目金额”和“捐款项目金额”都是复合数据项，这类项目是经常变动的，可能增加项目可能减少项目，如果只是简单地将复合数据项展开，预先多留一些奖金或扣款项目，那么必然会造成某些月份某些数据项用不上而导致的“横向冗余”。无论增加或删除这些复合项目所内含的数据项，必然改变数据库结构，必然会同时影响程序的健壮性。
因此，凡有复合数据项的都需要重新组织，将其分解成几个表。以下，为了分解复合项目，将含有复合项目的工资表（如表2.9）分解为不再含有复合项目，并且各有唯一主键的关系型数据库表（如表2.10）。
表2.10 消除复合数据项后的职工工资用户视图表
按照这种新的数据结构组织起来的实际工资数据如表2.11、表2.12、表2.13、表2.14、表2.15：
表2.11 D051301职工编号－姓名对照表
表2.12 D051302收入代码－收入名称对照表
表2.13 D051303支出代码－扣除名称对照表
表2.14 D051304收入登记表
表2.15 D051305扣除登记表
上述表中，如何确各行数据记录呢（表中“※”表示主键）：
表2.11通过“职工编号”的不同值，唯一确定每一行数据；
表2.12通过“收入代码”的不同值，唯一确定每一行数据；
表2.13通过“支出代码”的不同值，唯一确定每一行数据；
表2.14通过“职工编号”+“收入代码”的不同值，唯一确定每一行数据；
表2.15通过“职工编号”+“支出代码”的不同值，唯一确定每一行数据。
这里的“+”号就是将两个数据项连接起来，求共同唯一，这也是复合主键（组合键）的用法。
虽然“收入登记表”和“支出登记表”的代码表达方式不太符合人类的阅读习惯，却是数据库处理时没有冗余的、高效的存储方式，在呈现在人类面前时，可以通过视图将职工编码、收入代码、支出代码分别显示为该代码对应的职工姓名、收入名称、支出名称。所以，实质上这种方式最终在电脑系统中实现时，并不影响人类的阅读习惯。
例如：某学校存在着“学院教师信息表”结构（如表2.16）：
表2.16 学院教师信息表
这个表的问题在于，把“学院编号”+“教师编码”作为共同主键，而其中“教师姓名”和“教师简介”两个数据项仅依赖于“教师编码”一个数据项，而不是共同主键的全部。这样的数据结构将会出现多种异常，导致错误的数据存储。
为了消除这种不完全的数据项依赖，可以重新组织成三个表（表2.17，表2.18，表2.19），这样就导出了二范式（2NF）结构：
表2.17 学院信息表
表2.18 学院教师关系表
表2.19 教师信息表
★小提示：怎样符合第二范式
如果一个数据结构的全部非主键的数据项都完全依赖于整个主键，那么这个数据结构就是符合第二范式（2NF）的。对于含有“不完全依赖”的数据结构，应该加以消除另行组织，从而导出二范式。
例如：某学院在着着“教师社保登记表”的结构（如表2.20）
表2.20 教师社保登记表
这个表的数据结构存着着“传递依赖”的问题：“社保号”依赖于“教师编码”，而“教师姓名”又依赖于“社保号”，这也是一种不好的数据结构。
为了消除这种“传递依赖”，重新组织以下四个表（表2.21，表2.22，表2.23，表2.24），这样就导出了第三范式（3NF）。
表2.21 教师编码社保号关系表
表2.22 社保记录表
表2.23 教师编码姓名表
表2.24 教师专业表
这四个表分别存在着各自不同的依赖关系，通过这种拆分的方式，将原有的“依赖传递”拆分开来，有利于处理不同的数据关系。
★小提示：怎样符合第三范式
如果一个数据结构的全部非主键数据项都完全依赖于主键，而不依赖于其他的数据项，就说明这个数据结构是三范式（3NF）的。对于含有“传递依赖”的数据结构，应该加以消除后另行组织，即导出了三范式。
用户视图的收集、分析与整理，是保证信息需求分析和其后系统建模的基础，业务分析员和系统分析员必须认真工作，还要注意下列事项：
（1）凡可作“输入”或“存储”大类的，以及可作“输出”或“存储”大类的，一律归类为“存储”大类；
（2）“存储”大类的用户视图应规范化到三范式，并定义其主键，其他大类视图则不必如此；
（3）“存储”大类的用户视图经过规范化，有的由原先一个用户视图分化为几个规范化的用户视图，称它们为“同族用户视图”；
（4）加强各职能域用户视图的交叉复查，等价用户视图只需要登记一次；
（5）不断修订数据项（包括增减、类型类化、长度变化等），以满足系统的需要。
【实训练习2.9】天华电动自行车制造厂在规划初期收集到的用户视图如表2.25，请参考前面的数据结构规范化方法，对其进行规范：
表2.25 物料编码－物料类别编码信息表
物料类别可以有：前叉、车架、车轮、外胎、内胎、齿盘、飞轮、链条、花鼓、龙头、货架、前后夹器、曲柄、脚踏、坐管、变速控制杆、车把、钢丝、加工设备、加工工具。
表2.26 物料编码相关信息表
设计参数可以有：体积、重量、弹性、抗裂度、驰动力、滚动阻力、行进空气阻力、加速阻力、坡道阻力、驱动扭矩、驱动半径、输出扭矩、刹车摩擦力等数据项；
生产参数可以有：管径、预应力、焊接方式、加工温度等数据项；
保管参数可以有：存储温度、空气湿度、气压等数据项。
表2.27 员工信息总表
员工号与职位号的关系：同一职位可以有多名员工，一名员工只能有一个职位；
员工号与工作地号的关系：同一工作地可以有多名员工，每名员工可以因工作调动拥有多个工作地；
员工号与身份证号的关系：一个身份证号只能有一个员工号，员工离职后原员工号可以分配给新员工，即一个员工号历史上可能会对应多个身份证号，但某一时间内只能一一对应；
员工号与内训号的关系：一个员工号可以因为多次不同的内训有多个内训号；
职位号与内训号的关系：某种职位必须经过某种内训才能晋升。
【实训练习2.10】参考前几节中你熟悉的某个领域情况，进行初期调研，完善并规范其用户视图的数据结构。
本书所谓的数据流是指用户视图的流动，数据流分析工作的结果是数据流程图（Data Flow Diagram，简称DFD），它是一种能全面地描述信息系统逻辑模型的主要工具，可以用少数几种符号综合地反映出信息在系统中的流动、处理、存储情况。数据流程图具有抽象性和概括性特，是描述系统数据流程的工具，它将数据独立抽象出来，通过图形方式描述信息的来龙去脉和实际流程。
分析数据流的方法是：
●绘制各职能域的一级数据流程图和二级数据流程图；
●完成数据流程图中所标注的用户视图的组成登记；
●将上述两项工作结合起来，进行数据流的量化分析。
数据流程图是结构化分析的重要方法，在信息工程中应用DFD经过了一定的简化，即一种标准化的一级数据流程图（1-DFD）和二级数据流程图（2-DFD）。通过数据流程图的绘制：有助于用户表达功能需求和数据需求及其联系，使业务系统和信息系统人员能够在统一的、便于理解的框图中沟通现行与未来的系统框架，清晰地表达了数据流的情况，同时也有利于系统建模。
许多年前，当人们开始绘制分析模型时，总是希望找到一种技术，可以把所有的内容全都包容进去，以形成一个完整的需求描述。而事实上，人们最终只能得出这样一个结论：不存在一个包罗万象的模型或图。早期的结构化系统分析的目标，是用比叙述文本更正式的图形表示来替换整个分类功能规格说明；然而，经验告诉我们：分析模型应该增强自然语言的需求规格说明，而不是替换之。于是，逐渐诞生并完善出来了一系列简单、易绘、易沟通理解的需求图形化表示模型。
需求的图形化表示的模型包括数据流图、实体关系图、状态转换图、活动图、对话图和类图等。在需求分析方面或设计方面是否使用模型取决于建模的定时和目的，在需求开发中通过建立模型来确信自己理解了需求——而数据流程图正是结构化系统分析的基本工具。
一个数据流程图确定了系统的转化过程、系统所操纵的数据或物质的收集、过程、存储、外部实体之间的数据流或物质流。数据流模型把层次分解方法运用到系统分析上，这种方法很适用于事务处理系统和其他功能密集型应用程序。
数据流程图是当前业务过程或新系统操作步骤的一种表示方法。数据流程图可以在一个抽象的广泛范围内表示系统。在一个多步骤活动中，高层数据流程图对数据和处理部分提供一个整体的统览，这是对包含在软件需求规格说明中的、详细叙述的补充。数据流程图描述了软件需求规格说明中的功能需求怎样结合在一起使用用户可以执行指定的任务，从图中迅速反馈的信息有助于所有探讨任务流的理解、加工和提炼。
一级数据流程图（1-DFD）是建立业务模型、调查记录某一职能域的内外信息流情况的手段。结合用户视图的定义，复查一级数据流程图，记录每个职能域的输出、存储和输入数据流，保证全企业的数据流一致性，是重要的数据分析工作。一级数据流程图（1-DFD）的基本符号如图2.8所示。
图2.8 一级数据流图（1-DFD）基本符号
图2.9 一级数据流程图示例
在需求分析开始阶段，一旦定义了职能域，就要开始一级数据流程图的绘制工作：每个职能域绘制一张一级数据流程图，该职能域即为中心处理框，居中；左方为数据输入来源单位，右方为数据输出去向单位；在进出数据流的箭杆上下（或中间）标出有关的用户视图标识或名称。这个过程，可以在调研中边研讨边绘制，直到草图相对完善后用电脑绘制（通常使用Microsoft VISIO软件绘制，如图2.9）。
一级数据流程图是从全企业的高度，综合、整体地观察每一个职能域，通过数据流将一些职能域联结起来，使分析人员形成对全企业的整体认识。
二级数据流程图（2-DFD）的基本符号如图2.10所示。二级数据流程图中的处理框代表业务过程，存储框代表存储类用户视图。
图2.10 二级数据流程图基本符号
二级数据流程图是某一职能域中业务过程和数据需求的进一步调查的记录，关键是业务过程的识别与定义，以及存储类用户视图的定义与规范化。类似地，它是业务模型调研和用户视图调研的“草图”。
★小提示：二级数据流程图规范
对于二级数据流程图有一个必须遵循的规范：
●任何两个处理框的连线必须经过存储框；
●任何两个存储框的连线必须经过处理框。
因此，下面两图的连接是不允许的（如图2.11）：
图2.11 错误的数据流程图连接方式
当一张图下布置不下的时候，一、二级数据流程图可以分别画在几张图上，其逻辑关系关联起来还是一个整体。
二级数据流程图是一级数据流程图的求精、细化。通过这种细化的工作，可以让一级数据流程图中的大致的、粗略的表格群细化为一张张明确的表，各流程、实体之间的关系也更加明确无误（如图2.12）。
图2.12 二级数据流程图示例
从用户视图的调研到数据流程图的绘制，都是在做数据流的分析，但还没有进行量化的分析。只有进行了数据流的量化分析，才能制定出科学的数据分析规划，进而提出数据存储设备和网络通信方案所需要的数据流数据。
为此，首先要有一些编码规范。我们将职能域编码进一步扩充，补上外单位的编码，采用两位大写英文字母，如上面数据流程图示例中用到的（如表2.28）。
表2.28 职能域编码名称
记录数据流的一般格式是：
来源代码－去向代码－用户视图代码
规划组分别简单地将各职能域的输入、输出数据流录入电子表格中，通过公式定义，可以确定相关输入、输出数据量。具体做法，可以参照表2.7和表2.8进行统计。
【实训练习2.11】参考前述资料，试绘制天华电动自行车制造厂一二级数据流程图（建议使用软件：Microsoft Visio）。
【实训练习2.12】根据你熟悉的某个领域情况，试绘制其一二级数据流程图（建议使用软件：Microsoft Visio）。
企业信息资源规划的主要成果就是建立起全企业集成化的信息系统模型——功能模型、数据模型。需求分析是系统建的准备，系统建模是需求分析的继续和“定型”。只有建立起全企业优化的信息系统模型，在这种总体模型的指导、控制和协调下，才能实现企业信息化的总体目标。
系统功能建模就是要解决“系统做什么”的问题。经过功能需求分析所得出的业务模型，在很大程度上是当前业务流程的反映。要想得到现代信息技术支持下的新的业务流程，还需要做进一步的分析工作。
系统的功能模型是对规划系统功能结构的概括性表示，采用“子系统－功能模型－程序模块”的层次结构来描述。经过功能需求分析，在业务模型的基础上建立功能模型，实际上就是用两类人员都能理解的表述方式，对要开发的信息系统的功能结构做出简明准确的定义。
为科学表达系统功能模型的层次结构，并便于建立计算机化的文档，需要对功能模型进行编码，其编码规则如表2.29：
表2.29 功能模块编码规则
末4位空格为系统标识，末2位空格为功能模块标识，完整7位为程序模块标识。
由业务研制出功能模型的主要分析工作是对业务过程和业务活动作计算机化的可行性分析。业务模型是对现行系统功能的概括性认识，功能模型是对新系统功能的概括性认识，两者大体存在如图2.13的对应关系。
图2.13 业务建模与功能建模对应关系
★小提示：功能模型不是业务模型的简单对应
需要注意的是，图2.13中的业务模型和功能模型的关系，绝对不是一种简单的对应关系。因为除了规划人员在调研阶段和建模阶段的认识有所不同而导致两个模型的关键成分、相互关系和内部逻辑顺序有所不同之外，更重要的是功能模型和研制要进行更为深入的分析研究工作，其中包括运用计算机与信息系统的若干专业知识。
对于业务过程和活动进行计算机化可行性分析，是指识别和区分：
A类：业务过程、业务活动可以由计算机自动进行
I类：人－机交互进行
M类：需要人工完成
这样一来，功能模型的建立就需要改造那些人工活动部分，并对某些过程或活动进行必要的分解与综合，包括重新设计。
系统功能建模的开始阶段，强调各规划小组继承职能域功能分析的成果——业务模型、进行计算机化的可行性分析。当有了功能模型初稿之后，一方面要组织有关业务负责人做好复查工作；另一方面要做好综合协调工作，从各子系统的定义到功能模块的定义，力求准确完整，各功能模块的程序模块分解也要求比较恰当。
定义子系统是建立功能模型的首要工作，就像建立业务模型首先要研究职能域的定义一样。首先，规划核心小组要通过讨论提出子系统的划分；然后适当调整规划小组，按子系统分工研究提出子系统的初步定义。
★小提示：定义子系统的注意事项
在研究提出子系统定义的过程中，要注意研究和回答如下的问题：
●子系统的目标是什么，即需要对系统总体目标进行分解，作更具体的界定；
●说明子系统的边界，即覆盖哪个职能域或跨职能域，为哪个管理层次或跨管理层服务；
●确定信息加工处理深度或信息系统类型，诸如：事务处理（TPS）、管理信息系统（MIS）、联机实时处理分析（OLTP/OLAP）、决策支持系统（DSS）、主管信息系统（EIS）、战略信息系统（SIS）等；
●列出子系统的主要功能，注意运用“关键成功因素”和“价值流”分析思想，在业务过程计算机化可行性分析的基础上加以识别。
综合以上几方面的内容，用一短文准确概括描述，即为子系统的定义。
在子系统划分定义工作完成后，就要对每一子系统定义其功能模块和程序模块。在定义过程中，需要对一些问题特别关注（见表2.30）
表2.30 定义功能模块和程序模块需要关注的问题
现以某企业的“物料管理”为例，说明由业务模型到功能模型规划工作中程序模块的定义工作。经过业务域分析，得出业务模型如表2.31：
表2.31 某企业“物料管理”业务模型局部
对这些业务活动作计算机化可行性分析，发现“编审物料需求计划”业务活动对于原先的人工处理来说，是任务明确的、可行的，但对计算机信息系统来说，则是任务不明确、不可行的。因为，编排物料需求计划和审查物料需求计划是两种信息处理过程，其中，编排物料需求计划，首先需要采集各基层单位的物料需求信息，然后再进行汇总，并对照当前库存信息；而审查物料需求计划，首先需要采集各基层单位的物料需求是否合理——这是非结构化或半结构化处理，不易实现自动化的计算。“编审采购计划”和“编审采购资金计划”等业务活动，也有类似情况。
一般来讲，对业务活动作计算机化可行性分析，一方面应该根据企业管理的实际情况，借助信息技术建立新的管理机制；另一方面要考虑信息技术的运用，这既有当前信息技术能达到什么程度，也有采用某种信息技术的开发费用和投资方面的考虑。因此，在对业务活动做计算机化可行性分析的工作中，要发挥信息技术人员的作用。
在本例中，经过分析，两类人员达成共识：对基层单位物料需求的审查，继续沿用人工审查方法；系统设“编制基层物料需求计划”程序模块，以采集、维护基层单位的物料需求信息；系统再设“汇总基层物料需求”程序模块，以自动分类汇总计算各计划期的材料总需求，作为编制采购计划的初稿，系统设有人－机交互的程序模块——“编制采购计划”……等。经过这些具体分析和规划，得出的功能模块如表2.32：
表2.32 某企业“物料管理”功能模型局部
通过这样一番研讨、修订、细化工作，业务模型就顺利转化为功能模型，这对于今后的程序设计提供了很大的支撑依据。
上述定义子系统和定义功能模块、程序模块的工作，首先由各个规划小组研究制定，作为子系统功能模型初稿按期提交给核心小组。
在核心小组研究的基础上，召开全体规划组讨论会，交叉讨论提出修订稿。交叉讨论的要点是：
●跨管理层次、跨业务部门的子系统和功能模块有无问题；
●关键功能模块的认定（在相应的子系统说明中描述）；
●共用或类似程序模块的认定（在相应的功能模块说明中描述）；
●去除冗余模块。
经过交叉讨论和修订，应及时提交给中高层业务负责人进行复查认定。复查要点是：
●子系统划分定义的准确性；
●关键功能模块识别定义的准确性；
●跨管理层次、跨业务部门的子系统和功能模块对建立信息管理制度的影响和对策；
●对意见不易统一的部分提出原型研究的要求。
信息资源规划组在进行系统功能建模进，要充分利用需求分析资料和有关的信息系统知识、经验，这些都是系统功能建模的重要资源。
与功能建模直接相关的包括业务分析结果（即业务模型，重点是职能域和业务过程的定义）的复查和数据流程图（一、二级数据流程图相匹配，并与业务模型相一致）的复查。复查工作决不能仅限于系统分析员和业务代表中进行，一定要使业务部门负责人参与复查工作，形成共识。
如图2.14中的虚线箭头部分，再经过计算机化可行性分析，将相当多部分的业务模型纳入到系统功能模型中（经过分析，并不是所有业务模型都全部纳入系统功能模型，有少部分可能只需要人工处理或暂时不做系统开发的将不纳入）。
如图2.14中的实绩箭头部分，还有其他应用软件中的有用模块也应该吸收，这些模块也被加进系统功能模块中。
需要着重说明的是，功能建模拟定的子系统是“逻辑子系统”（面向规划、设计人员），而不是“物理子系统”（面向最终用户）。
许多计算机应用系统都是按照当前的组织机构和业务流程设计的，系统或子系统名目繁多。机构或管理一发生变动，计算机应用系统就得修改或重做。而事实上，只要企业的生产经营方向不变，企业基本的职能域就相对不变，而基于职能域的业务过程和数据分析可以定义出相对稳定的功能模块和程序模块，这样建立起来的系统的功能模型是对机构管理变化有较强的适应性的。
图2.14 功能建模的资源利用——业务模型与已有应用模块
因此，“逻辑子系统”作为这些功能模块和程序模块的一种分类，是对全企业信息系统功能宏观上的把握。以后，可以在应用开发过程中参照面向对象软件工程，加强可重用模块的开发和类库建设，这些模块和类库部件都以存取主题数据库为基本机制，以实现以最终用户为对象的、模块化、可继承的组装“物理子系统”——以广泛适应机构变化而不必重开发的工作需求。
这样，可以从根本上长期改变计算机应用系统跟不上管理变化的被动局面，树立起企业规范、自适应的管理思想。
【实训练习2.13】参考前述资料，试为天华电动自行车制造厂进行系统功能建模。
【实训练习2.14】根据你熟悉的某个领域情况，试为其进行系统功能建模。
系统数据建模就是要解决系统的“信息组织”问题。这是信息资源规划的核心部分，是数据环境重建的根本保障。
理解数据模型概念及其建模方法，需要一些基本概念和有关知识，以达成数据建模的基础。数据建模的目的是为了全面考虑数据库设计实施问题，如果能把数据建模与数据库的设计实施联系起来，就会更好地做好数据建模工作。
在数据组织的各种模式中，“关系模式”特别适合企业管理数据环境的建设。按照关系模式的观点，现实世界中有联系的一些数据对象就构成了一个“数据实体”或简称为“实体”（Entity）。
例如：“物料”这个实体，是物料编码、物料名称、物料供货厂家、生产日期、适用产品等数据对象的抽象，这些数据对象称为实体的“属性”（Attributes）。
实体与实体之间存在着关系（Relationship）。有三种基本的关系：一对一（1：1）、一对多（1：n）及多对多（m：n）。
例如：
班级与班长是一对一关系（一个班级有一位班长）：班级（1）——班长（1）；
班级与学生是一对多关系（一个班级由多个学生组成）：班级（1）——学生（n）；
课程与学生是多对多关系（各门课程可以被多名学生选修）：课程（m）——学生（n）。
表是数据分析工作中经常乃至的概念，它是一组有联系的数据集合。数据分析工作经常需要列出一个表所含的数据元素或数据项，而不具体考察每一行的数据项的值。
数据库逻辑设计的主要任务，是仔细分析哪些是基础数据，哪些是非基础数据，怎样将基础数据组成“基本表”，如何根据基本表来设计非基本表（如各类归档表、中间表、临时表、虚表、视图等）。
基本表是由企业管理工作所需要的基础数据所组成的表，而其他数据则是在这些数据的基础之上衍生出来的，它们组成的表是非基本表。基本表可以代表一个实体，也可以代表一个关系，基本表中的数据项是实体或关系的属性。基本表应该具有一些基本特性：
原子性：即表中的数据项是数据元素；
演绎性：即可由表中的数据生成系统全部的输出数据；
稳定性：即表的结构不变，表中的数据一处一次输入，多处多次使用，长期保存；
规范性：即表中的数据满足三范式（3NF）；
客观性：即表中的数据是客观存在的数据，是管理工作需要的数据，不是主观臆造的数据。
概念模型的表示方法很多，其中最为常用的是实体－关系方法（entity-relationship approach），该方法用实体关系图（entity-relationship，E-R图）来描述现实世界的概念模型。每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。下一步，就需要将这些数据从数据字典中抽取出来。参照数据流图，标定局部应用中的实体、实体属性、标识实体的码，确定实体之间的联系及其类型。E-R图提供了表示实体型、属性和联系的方法：
●实体型：用矩形表示，矩形框内写明实体名。
●属性：用椭圆形表示，并用线段将其与相应的实体连接起来。
●联系：用菱形表示，菱形框内写明联系名，并用线段分别与有关实体联系起来，同时也在线段上标注联系的类型（1：1；1：n；m：n）。
需要注意的是，联系本身也是一种实体型，也可以有属性。如果一个联系具有属性，则这些属性也需要用线段与该联系连接起来。
【参考2.3】根据数据流图的分析，发现某系统的局部应用有五个实体型，分别是：学生、班级、课程、教师、参考书，根据相关的分析，绘制出班级实体属性图（如图2.15）和这五个实体之间的关系图（如图2.16）。
为了节省篇幅，E-R图中省略了各个实体的属性描述。需要注意的是，E-R图绘制实体属性前，应分别就各实体在不同子应用中的属性进行合并。这些实体的属性描述分别是（其中下划线的部分为实体中的关键属性）：
学生：{ 学号 、姓名、性别、年龄}
班级：{ 班级编码 、班级名称、所属专业系}
课程：{ 课程号 、课程名、学分}
教师：{ 职工号 、姓名、性别、年龄、职称}
参考书：{ 书号 、书名、内容提要、价格}
有了班级信息的实体属性图之后，根据情况进行分析，以绘制班级信息的实体关系模型图。根据情况分析，可得知道：
图2.15 班级信息实体属性图
一名教师将指导一个班级，所以教师与班级的关系是1:1；
一名教师可以讲授多门课程、同一门课程也可以被多名老师讲授，因此教师与课程之间的关系是n:m；
一名学生可以选多门课程、同一门课程也可以被多名学生选择，因此学生与课程之间的关系是m:n；
一个班级由多名学生组成，因此班级与学生之间的关系是1:n；
一门课程可拥有多本参考书，因此课程与参考书之间的关系是1:n；
图2.16 班级信息实体关系图
【实训练习2.15】参考前述资料，并根据这些资料绘制天华电动自行车厂的实体属性图和实体关系图，并根据实体属性图来列出实体的属性描述（其中关键属性加下划线）。
【实训练习2.16】根据你熟悉的某个领域情况，自拟资料，绘制其实体属性图和实体关系图，并根据实体属性图列出实体的属性描述（其中关键属性加下划线）。
数据模型（Data Model）是对用户信息需求的科学反映，是规划系统的信息组织框架结构。数据模型分为：
全域数据模型——整个集成系统的所有主题数据库及其基本表；
子系统数据模型——某个子系统所涉及的主题数据库及其基本表。
概念数据库（Conceptual Database）即概念数据模型，是最终用户对数据存储的看法，反映了用户的综合性信息需求。概念数据库一般用数据库名称及其内容（简单数据项或复合数据项）的列表来表达采取“离散集表达法”。
目前市面上主要的数据库类型为基于关系模型的关系型数据库，关系模型的逻辑结构是一组关系模式的集合。概念数据模型的表达法即为关系模式表达方法，即：
关系模式名（数据项列表……）
逻辑数据库（Logical Database）即逻辑数据模型，是系统分析人员的观点，是对概念数据库的进一步分解和细化。在数据组织的关系模式中，逻辑数据库是一组规范化的基本表。
由概念数据库深化的逻辑数据库，主要工作是采用数据结构中的规范化原理和方法（参见前述“数据结构规范化”章节），将每个概念数据库分解、规范化成三范式的一组基本表。
E-R图是由实体、实体属性和实体之间的三个要素组成的。所以，将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式，这种转换一般遵循如下原则：
实体的属性就是关系的属性，实体的关键属性就是关系的主键，例如在图2.16的例子中，“教师”实体可以转换为如下关系模式，其中“职工号”为“教师”关系的主键：
教师（ 职工号 ，姓名，性别，年龄，职称）
与该联系相连的各实体的关键属性的码以及联系本身的属性均转换为关系的属性，而关系的主键则为各实体主键的组合码：
讲授（ 职工号，课程号 ，学分）
选择（ 学号，课程号 ，学分）
可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的主键以及联系本身的属性均转换为关系的属性，而关系的主键为n端实体的主键。
例如，图2.16中的“拥有”联系为1：n联系，将其转换为关系模式的一种方法是使其成为一个独立的关系模式：
拥有（ 课程号 ，书号）
其中“课程号”为“拥有”关系的主键，另一种方法是将其与“参考书”关系模式合并，这时“参考书”关系模式为：
参考书（ 书号 、书名、内容提要、价格，课程号，学分）
可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并，如果转换为一个独立的关系模式，则与该联系相连的各实体的主键以及联系本身的属性均转换为关系的属性，每个实体的主键均是该关系的候选码。如果与某一端对应的关系合并，则需要在该关系模式的属性中加入另一个关系的主键和联系本身的属性。
例如，图2.16中的“指导”联系为1：1联系，可以将其转换为一个独立的关系模式：
指导（ 职工号 ，班级编码）
或
指导（ 班级编码 ，职工号）
在“指导”关系模式中，职工号与班级编码都是关系的候选码。由于“指导”联系本身没有属性，所以相应的关系模式中只有主键，它反映了教师与班级之间的对应关系。
“指导”联系也可以与班级或教师关系模式合并，则需要在“班级”关系中加入“教师”关系的主键，即“职工号”：
班级（ 班级编码 ，班级名称，所属专业系，职工号）
同样，如果与“教师”关系模式合并，则只需在教师关系中加入班级关系的主键，即“班级编码”：
教师（ 职工号 ，姓名，性别，年龄，职称，班级编码）
为了减少系统中的关系个数，如果两个关系模式具有相同的主键，可以考虑将他们合并为一个关系模式。合并方法是将其中一个关系全部属性加入到另一个关系模式中，然后 去掉其中的同义属性，并适当调整属性的次序。
按前述原则，图2.16中的关系可以合并为下列7个关系模式：
教师（ 职工号 、姓名、性别、年龄、职称，班级号）
学生（ 学号 ，姓名，性别，年龄，班级编码）
班级（ 班级编码 ，班级名称，所属专业系）
课程（ 课程号 ，课程名，学分）
参考书（ 书号 ，书名，提要，价格，课程号）
讲授（ 职工号，课程号 ，学分）
选择（ 学号，课程号 ，学分）
【实训练习2.17】参考前述天华电动自行车厂的资料及实体属性图、实体关系图，将实体属性图和实体关系图转换为关系模式，并进行合并。
【实训练习2.18】根据你熟悉的某个领域情况和自拟资料绘制的实体属性图和实体关系图，将实体属性图和实体关系图转换为关系模式，并进行合并。
长期以来，人们一直在寻求数据建模和数据库设计的自动化方法，但总也没有突破性的进展。其根本原因在于，数据建模和数据库设计的有效方法，归根到底是以业务知识和管理经验为基础的；采用某些软件辅助工具，只是为了加强规范化，省去分析处理和人工绘制图表等繁琐工作，没有能够自动产生数据模型的工具。
数据建模过程，实质上是从用户视图到主题数据库，从数据流程图到E-R图，从数据实体到基本表的研究开发过程。
各个职能域的用户视图及其组成；
各个职能域的数据流程图（1－DFD、2－DFD）；
各个职能域的输入数据流、输出数据流和数据存储分析报告；
全域的数据元素集；
全域的数据元素－用户视图分布分析报告等；
识别定义业务主题，按主题将用户视图分组定义为实体大组，提出概念数据模型；
按业务需要进一步分析实体的属性，规范化数据结构产生基本表，提出逻辑数据模型；
数据元素规范化，进一步审核基本表的组成。
数据建模需要业务人员与系统分析人员深入密切地合作，大致分为三步进行工作：
第一步，进行实体－关系分析——可以从业务主题出发确定实体大组，识别各个实体；也可以从数据流程图（DFD）出发，确定各个实体及关系，绘制E-R图。这样可以建立概念数据模型，并对逻辑数据模型的建立做好准备。
第二步，进行数据结构规范化分析——利用数据结构规范化的理论和方法，将每一实体规范化到三范式，即形成基本表，并确定基本表之间的关系，以建立逻辑数据模型。
第三步，进行数据元素规范化分析——利用数据元素规范化的理论和方法，建立较完整的类别词表和基本词表，以便控制数据元素的一致性，使基本表进一步规范化。
数据元素规范化之后，将每一个主题数据库（根据职能域中业务过程为依据划分）分解为一组基本表，即“一级基本表”和“二级基本表”。主题数据库与一级基本表之间的关系为“一对多”的关系，一级基本表与二级基本表之间的关系同样为“一对多”的关系。最多只设置二级基本表，个别情况下只需要一级基本表。设置方法，例如表2.33。
表2.33 一级基本表与二级基本表的划分
在具体划分一级基本表和二级基本表和定义其信息内容时，可以参考小提示，以帮助检查有无差漏或不妥之处。
★小提示：一级表与二级表区别
一级基本表和二级基本表之间具有一定的分类原则，为了能够更好地进行区分与细分，以下从几个方面分别列出二者的区别，以供编撰者参考：
●按产生关系：一级表为基本信息，二级表为派生信息；
●按详略程度：一级表为概要信息，二级表为详细信息；
●按变化情况：一级表为静态信息，二级表为动态信息；
●按时态关系：一级表为当前信息，二级表为历史信息……
为了符合前述的第三范式的要求，每个明细的基本表中并非如最终用户视图那样装载所有的内容。于是，关系型数据库中的基本表通常采用外键（Foreign Key，FK）的方式，在当前基本表中定义一个代码，并指向另一个基本表。一般来说，一个基本表的外键是另一个基本表的主键；通过外键的方式，可以将当前基本表的信息加以延伸（如图2.17）。
图2.17 外键引用在用户视图中展示
为了能够在全企业范围内规范地进行数据建模工作，必须要有建立全域数据模型的意识。如果在全企业的范围内进行，定义的主题数据库是面向全部职能域或所有子系统的，数目罗多；如果只在某一个职能域或子系统内进行，主题数据库数目相对要少得多。
全域数据模型应该先按全企业的要求定义主题数据库，然后 在各个子系统中定义相应的一级基本表和二级基本表，最终在全域范围内检视并包含所有的基本表。
★小提示：全域模型中相同基本表应遵循的原则
由于各个子系统可能会用到相同的基本表，通常需要遵循的原则是：
全域数据模型的某一主题或基本表可以存在于几个子系统数据模型中，它们之间完全保持一致性（同一表）；
全域数据模型是对各个子系统数据模型的统览，每一基本表的创建和维护必须由具体的子系统负责。通常情况是，一个子系统负责创建维护，多个子系统使用读取。
【实训练习2.19】参考前述天华电动自行车厂的资料（职能域、业务过程、业务活动等）、及实体属性图、实体关系图、关系模式，试按数据建模方法定义该厂的主题数据库、一级基本表、二级基本表（涉及图形绘制时建议使用软件：Microsoft Visio）。
【实训练习2.20】根据你熟悉的某个领域情况和自拟资料（职能域、业务过程、业务活动等）、及实体属性图、实体关系图、关系模式，试按数据建模方法定义该领域对象的主题数据库、一级基本表、二级基本表（涉及图形绘制时建议使用软件：Microsoft Visio）。