第八章实体活动分析.docx
《第八章实体活动分析.docx》由会员分享，可在线阅读，更多相关《第八章实体活动分析.docx（21页珍藏版）》请在冰豆网上搜索。
第八章实体活动分析
第八章：
实体活动分析
第一节 引言
前一章中所讨论的主题数据库或数据类的确定，在一定程度上有点随意性，自顶向下规划的一个主要目标是消除数据中的大量冗余和矛盾冲突，同时也避免重复的应用程序编制和维护工作，这些工作已经耗费了大量的数据处理资源。
但是，主题数据库中的数据分类还过于粗略，不能实现这一目标。
本章将介绍一种更加细致的自顶向下规划方法，可以用来对企业实体进行分析，并用图表加以描述。
因为针对实体层次进行工作，所以能够发现有害的冗余。
图8.1 自上而下规划方法的三个层次
另外，针对实体层次进行工作，还能够确定使用各个主题数据库的系统的边界，而图7.15这样的图表却不能够精确的描述系统的边界。
我们前面已经提出过，自顶向下的规划能够在几个层次上进行。
图8.1表明了三个层次：
前面一章描述的主题数据库层次，这一章前半部主要描述的实体层次，以及后半部所要描述的实体和活动层次。
为了便于数据库实施，实体需要被划分为一些群组，这一划分实际群组的过程，实际上就产生了主题数据库。
这些主题数据库可以被用在高层次的系统概貌图中。
图8.1说明了这一点。
第二节 企业实体和实体分析
实体分析是一项自顶向下地确定企业的全部实体的工作。
实体是指某种含有数据特征的事或物，也就是数据实体的简称。
实体可以是有形的对象，例如：
雇员、零件、客户、机床或一间办公室；也可以是无形的，例如：
工作职务、利润中心、协会、财务补贴、采购、估价、或者保险赔偿。
每个实体应该用一个名词来命名，有时也可以加上一个修饰词。
可以认为一个实体具有该名词所确定的性质。
一个实体具有各种我们需要描述的属性，例如：
颜色、货币价值、利用率或者名称。
实体这个术语有概括性，它的意思是实体类或者一类实体。
与此相似，记录这个术语也有概括性，含意是记录类，或者一类记录。
数据项、属性和其它描述数据的词，也有类似情况。
一个实体类是确定了名称具有相同属性类集合的一类实体，例如，雇员就是一个实体类。
一个实体实例是某一实体类中的一个具体实体。
例如，吴大海是雇员这个实体类中的一个具体实例。
在本书中我们用实体来指实体类，用记录来指记录类，以此类推，通常这种简称的意思都是明了的。
每一个实体类至少有一个记录类，有时这一记录类被称为实体记录。
例如，雇员记录是一个包含关于雇员这一实体数据的记录。
一个实体类往往需要多个记录类来存储有关该实体类的数据。
这往往是因为数据经过了规范化处理，规范化处理是将数据分解为独立的记录，使得每一个记录具有清晰的结构。
一个实体通常有一个能够唯一确定它的数据项。
例如，雇员号码是确定雇员实体的唯一标识。
这个数据项被用作该实体记录的主关键字。
当一个实体存在着多个有关的记录时，这种唯一的标识由多个主关键字结合而成。
例如，雇员历史记录的关键字有两个数据项；雇员号码和日期。
有些记录包含实体之间关系的信息。
例如，供应商和零件是两个实体类，它们的唯一的标识是供货商号码加上零件号码。
我们可以用包含这两个主关键字的记录来存放由某人供应商所提供的某个零件的详细情况，例如，它的价格和交货时间。
这种数据有时被称为相交数据。
供应商零件记录有两个主关键字：
供应商号码和零件号码，它们在一起唯一地标识一个记录。
这种记录可以被称为相交实体记录。
实体图描述了多个实体，其中包括含有多个主关键字的实体和实体之间的联系。
因为实体图是一个概貌图，它不指出这些实体中包含的具体数据项，因此实体图可以比较迅速地绘出。
数据项的细节在以后建立详细数据模型时再来确定。
图8.9是一张实体图。
一个中等规模的企业通常有数百个实体，一个大型企业如果业务是单一的，那么它所含有的实体数目也不比小企业多很多。
有些大型企业从事多种业务，例如，既从事钢铁业务又从事石油勘探业务的企业，它们所包含的实体比业务单一的企业要多得多如果企业不转向另外完全不同类型的业务，那么企业中的实体集合就不会随着时间的推移而发生过大的变化。
描述实体的属性存贮在记录之中。
一个大型的企业常常有几千种记录类型。
但是，如果进行了良好的自顶向下的分析，那么就会发现它只含有几百个实体类型。
在许多企业中，实体类型有大量的重复，这是因为没有进行自顶向下的规划。
这种重复导致了大量不必要的应用程序编写工作和复杂的维护工作，为管理部门取得汇总信息带来困难而且也不好控制。
最高领导对缺乏控制常常比数据处理部门更加敏感，但是他们不知道应该怎么办。
在一个组织中，确定实体的工作通常由用户分析员来完成，因为他们了解有关的业务。
他们必须受到培训，从而知道什么是实体。
有时候，进行自顶向下规划工作的人员，要求用户去确定一些不如实体概念明确的事物。
例如，他们要求用户确定与自己工作有关的"信息集合"。
上面给出的关于实体的定义是精确而且易于理解的。
必须由用户分析员来确定实体和实体之间的联系。
象"信息集合"这样的模糊词语是不恰当的。
不同的用户分析员常常提出一些相同的实体，却给它们取了不同的名字，例如，顾客和客户。
由受过数据库训练的专业数据处理人员所担任的协调分析员，必须在规划小组的帮助下发现这些同义词。
每一种实体都必须只有一个名称。
这一要求有时可能遇到困难，因为不同的用户部门常常使用自己习惯的名称。
这时，通常可以使用一个同义词字典，来把用户所使用的不同的名称与选定为实体模型中所使用的名称联系起来。
当对所有的实体达成一致的理解，并且排除了重复的实体之后，关于实体的详细描述可以存放在一个字典中。
第三节 实体间的联系
在描述实体之间的联系时，我们使用几种不同类型的连线。
如果实体A的一个实例只与B的一个实例相联系，我们称实体A与实体B是一对一联系。
如果实体A的一个实例与实体B的多个实例相联系，我们称实体A与实体B是一对多联系。
在实体图上，我们在表示实体的方块之间画上连线，以表明实体之间的联系。
一对一的联系用单箭头的连线相连接，因此，下图就表示一个实体A的实例总是与一个且仅仅一个实体B的实例相联系：
一对多的联系用双箭头连线表示。
因此，下图表示实体B的一个实例可以与多个实体A的实例相联系：
我们可以在同一根连线上表示A→B的联系业务和B→A的联系，如下图：
下图是一个例子：
它表示每一个分部可以有多个推销员，而一个推销员总是与一个分部相联系。
在连线上画一个"0"表示可以与零个实例相联系，因此，下图表示实体C的一个实例可以与一个或者零个实体D的实例相联系：
读者现在可以参看图8.2，以帮助理解图上连线的意义。
图8.2中产品/物料是一个复合实体，含意是其数据表明某一具体产品所需要的原材料，而这些数据又不能仅仅由产品或者物料来有效地确定。
例如，它可以表明用于某一给定产品中的某一给定物料的数量。
有些联系是互斥的，如果A可以与B或者C相联系，但是不能与B和C同时联系，我们就以下图来表示：
两条连线之间的短线指出这两个联系是互斥的，下面是两个例子：
有些联系是相互依赖的，或者说如果A与B相联系，它必须同时也与C相联系，我们用连线之间的双短线来表示这种联系：
下面有一个例子：
在建立数据模型时，有时还使用另外两种表示方法，一种是用端部分叉的连线表示一对多的联系，如下图
另一种在连线的一端加上一条小的短线来表示一对一的联线，如下图：
这两种表示方法都用不加任何标志的连线表示一个联系，例如，上图中从推销员到分部的联系。
建立详细数据模型时，唯一最重要的输入是函数依赖关系。
上述两种表示方法不能表示出函数依赖关系。
另外，我们有时也用一条没有任何标志的连线来表示我们还不了解的联系或者无关紧要的联系。
因此，我们建议避免使用最后这两种表示方法，其它一些符号用于实体图和详细数据模型，实际效果都很好。
第四节 结构化的实体图
我们把图8.2中的图表称为实体图，它与数据模型是不同的。
数据模型要精确得多，并且表示出第三范式的数据结构，以及后来仔细确定的主关键字，其中有一些可能是复杂的联合关键字。
数据模型从对最终用户视图的全面综合，以及对综合结果所进行的稳定性分析中产生。
实体图只是对企业实体的一个汇总，它常常省略比较复杂的联合关键字。
建立全面的详细数据模型的工作，需要的时间比仅仅确定企业实体要长得多。
建立数据模型的过程所需要的时间往往过长，不能使最高领导始终保持兴趣，但是最高领导的兴趣对于实体分析却是至关重要的，因为它反映了企业真正的信息需求。
数据库设计中一种快速但是草率的常见方法，就是先确定需要存储数据的实体，然后列出与这些实体相关的属性。
有时候每一份属性清单还被加以第三范式处理。
这种方法在课堂教学的简单环境中是可行的，但是在实际复杂的企业或政府机构中，这种方法效果不好。
建立全面数据模型的工作，没有妥善的捷径可走。
我们曾经有机会将用简便的实体图方法设计的数据结构，与同一环境中用正规的综合方法所得到的结果加以比较，它们之间的差别相当大。
好的数据库设计，既需要本章中所描述的实体分析，也需要建立详细的数据模型，并将两种方法的结果相互参照。
当只有20到30个实体时，实体图可以用手工绘制，但通常实体图要大得多，因此，有必要使绘图过程自动化。
有些设计人员在手工绘制了很大的实体图之后，不能迅速地重复绘制，当需要修改时，就只能在图面上进行，结果使得图面非常杂乱。
经过多次修改后的实体图，最后只能再用手工重新绘制一遍。
这份新的实体图，犹如一件艺术品，因此设计人员往往不大愿意再去修改它。
我们曾经见过某些数据处理人员保存的实体图，其杂乱程度叫人感到害怕。
毫无疑问，这些实体图中包含着一些需要进一步改进的地方，但是这些数据处理人员不敢让用户对这些实体图提出修改建议。
我们建议把这些杂乱无章的实体图称?
quot;蚯蚓图"（"COWchart"）。
许多蚯蚓图的作者们，对他们烦琐的作品印象深刻，并且自豪地把它们钉在墙上。
图8.3是一张有16个实体的实体图，它那种面条式的结构，使得人们难以使用。
真正的实体图常常有几百个实体，往往非常庞大，难以用手工绘制和维护。
实体图应该以一种清晰和更加结构化的方式，由计算机来绘制和维护。
这项工作的具体具体步骤如下：
图8.3 一种杂乱的实体图—“蚯蚓图”
首先，除去所有冗余的联系。
至少暂除去以便于重复绘制，它们可以在重新绘制出来的实体图上替换回来。
然后可以找出实体图中的根实体。
根实体是图上没有单箭头连线离开的实体。
通常把根记录、根字段或者根实体画在数据库图的顶部。
我们把根实体称之为第一层实体。
接着可以确定第二层实体。
第二层实体具有一个指向第一层实体的单箭头连线。
具有一个指向第二层实体的单箭头连线的实体，可以被定义为第三层实体。
第n层实体（n>1）可以被定义为具有一个指向第n-1层实体，但是没有指向更低层次实体的单箭头连线的实体。
图8.4中表明了图8.3中实体的层次数字。
然后将第一层实体画在图纸的左边，第二层实体向右缩进一格，第n层实体向右缩进n-1格。
第n层实体（n>1）画在它所指向的第n-1层实体下面。
每个第一层实体下面的实体构成一组。
跨越组的这些箭头画在图的左边，离开各组实体，如图8.5所示。
图8.5与图8.3实际上是等价的。
重新绘制图8.3这种实体图的工作，可以从确定第一层实体（没有单箭头连线离开的实体）开始，然后确定第二层实体，再确定第三层实体，直到所有实体都有了层次数字，再将每一个根实体下面的根实体组绘制出来，最后加上跨越这些实体组的连线。
图8.4 图中数字指出每个节点的层次
图8.5 图8.3中四个实体组的结构化画法
有时，一个非根实体具有多个上层实体，例如图8.4中实体A是一个第二层实体，它可以被画在B，G或L这三个第一层实体中的任何一个下面。
与此相似，H是一个第三层实体，它可以被画在第二层实体J或者K下面。
那末，应该选择哪一个上层实体呢？
最好是选择联系最强的上层实体，或者是最常使用的联系。
让我们假定A←←→B联系比A←←→C联系强，那末A就画在B的下面。
与此相似，如果J←→→H联系比K←→→H联系使用得更加频繁，那末H就可以在J下面，如图8.5所示。
与此相似，遇到形成回路的联系时，回路中最弱的联系必须被暂时断开，以便于绘图。
在绘制图8.5时，假定C→N是最弱的联系。
如果联系的强度是未知的，或者是相同的，只要进行一个任意的选择，以便能够形成可以自动绘制的实体图。
有些实体图的绘制者把图上的连线标上名称，以表示它们的含义，如图8.6所示。
图8.6是一家电话公司的实体图。
给连线加上名称，使得实体图更加明了。
有时候连线上必须加名称，因为在相同的实体之间，有多条连线，或者因为联系的意义不确定。
但是通常这些连线的含义是明确的，因此，许多实体图中的连线没有标上名称，意义也很明确。
强制性地给连线加上名称，似乎是不必要的。
有些人正在研究数据模型更高级的形式。
在这些数据模型中，连线的含义被编成代码，以便于计算机理解，还可以被使用数据库的高级语言利用。
第五节 实体的组合
数据库系统与描述它们的实体图一样需要被划分成若干部分，以便于实施。
这些部分就是前面所提到的主题数据库或者数据类。
后面我们还要使用实体大组这个术语。
图8.6 实体图中加上名称的联系
我们将把图8.5中分层次的实体分组称为实体组。
图8.5有四个实体组。
更高层次上的实体组，就是实体大组。
它可以包含一个或多个实体组。
实体大组是在一个主题数据库中实施的实体的集合。
实体可以根据实体间的联系及被使用的频繁程度，组合成为大组。
在一个大组内的联系，应该具有较高的使用频率。
大组之间的联系，应该具有较低的使用频率。
要做到这一点，在进行实体分析时，就应该在实体间的联系加上分类标志。
联系的分类标志可以有五种，从最强联系或者最常使用的联系，到最弱的联系或者最不常使用的联系：
1）极弱的联系：
必须在不同的大组中。
2）较弱联系或不常使用的联系：
可以在不同的大组中。
3）一般联系：
可以在一个大组中，也可以不在一个大组中。
4）较强联系或经常使用的联系：
可以在同一个大组中。
5）极强联系：
必须在一个大组中。
基于这种简单的分类，可以把一组庞大而笨拙的实体图划分成为易于使用的子实体图，或者把实体组合成实体大组。
也可以用计算机算法进行这种分组。
图8.7表示的是连线上加了上述分类标志的图8.3。
A到L和M到G是第一类联系，因此，应处于不同的实体大组。
图8.7 给图8.3中的连线标上联系的类别
图8.8表示的是根据联系的分类，划分成实体大组。
第一类联系指出这些实体不应该设计在同一个主题数据库之中。
因为有两个第一类联系，所以至少应该划分出两个实体大组，实体A和实体M分别属于两个实体大组。
再来看第二类联系。
C到F就是图8.7中唯一的一个第二类联系，根据联系的分类原则，C和F可以在不同的大组之中。
这样，C和F在图8.5中属于一个实体组，现在，我们把它们分开来，放在两个实体大组中。
总之，这些实体被组合成图8.8的三个实体大组。
图8.8 根据图8.7的实体联系类别，将图8.5划分为实体大组
当一个实体有多个上层实体时，这些联系分类可以被用来决定该实体应该属于哪个实体组。
例如图8.8中的实体A被画在实体B下面，而不是画实体G或L下面。
与此相似，在C、D、N中的联系回路上，较弱的联系是C→N联系。
同一组中同一层次上与上层实体联系较强的实体被画在与上层实体联系较弱的实体上面。
因此，图8.8中A画在J的上面。
在进行详细数据库设计时，有必要采用更加详细的联系分类方法来更精确地表明这些联系的使用量。
但是在自顶向下的规划阶段，上述分类方法已经足以把实体图划分成为实体大组。
将实体图划分成为主题数据库的工作，也许不应该完全根据一个算法来进行。
主题数据库还应当考虑规模和内容因素，以便于数据管理员在适当的时间内完成详细设计。
这种详细设计需要考虑现有文件和第二类数据库中不便转换的数据。
上述的联系也可以被用来根据设计人员的愿望，将实体组合成易于实施的数据库。
利用第一类联系可以强制计算机算法将某些实体分裂成为不同的大组。
利用第五类联系，可以将某些实体划分到同一个大组中。
有时这些做法会使得实体组分裂。
由第二类联系相连接的大组应尽可能画在相邻的位置上，如图8.8所示。
第六节 一个实例
图8.9表示的是一家制造公司的实体图。
该企业年销售额为4000万美元。
这张图是计算机设计工具"数据设计软件"辅助绘制的。
图8.9 一家制造公司的实体图
图8.10 图8.9中的裕本图划分为实体大组，从而成为主题数据库
这家公司的企业数据处理规模相当小，只有95个实体。
一家规模庞大而复杂的制造公司中实体的数目，可以十倍于这家公司。
这份结构化的实体图可以帮助我们了解哪些实体之间是相互联系的。
为了简化图形，实体组内的层次联系没有画出。
这张图比较小，能够用手工将实体组合成为实体大组。
但因为这项工作往往要重复多次，所以如果能用机器来绘制，是很有帮助的。
图8.10将图8.9中的实体划分成为实体大组，这些实体大组可以作为绘制图7.9和图7.14中系统规划矩阵的依据。
第七节 实体图的计算机表示
如果实体只有10个左右，那么还可以用手工绘制和管理。
但是如果有几百个实体，没有计算机图形工具，就很难绘制和维护。
即便有了计算机图形工具绘制如此庞大的实体图，也没有多大价值，除非数据管理人员想把它挂在墙上来炫耀。
计算机图形工具非常有助于从总的实体中抽取出实体子集图来。
这些子集图可以被用户和分析人员用来绘制逻辑存取图和设计数据库过程，它还可以被物理设计人员用来检查应用项目中事务处理对数据的使用情况。
因此总体实体图应该保存在计算机中，这样就能够方便地对其进行更新和处理。
可以利用计算机图形工具从中产生小的子集图，以便于数据管理人员、最终用户或系统分析人员进行研究、讨论和绘制存取图。
实体图应该为以后建立详细数据模型的过程提供资料。
如果我们要获得设计和管理数据库环境的计算机化的便利工具，就必须存储大量关于数据的数据。
关于数据的数据被称为元数据，我们需要把这类元数据放入数据库--一个关于数据库的数据库。
第八节 实体分析应注意的问题
1．关于自顶向下的规划与自底向上的设计相结合问题
自顶向下的规划与自底向上的设计常常被区分开来。
自顶向下的规划是本书中所讨论的一系列过程，这些过程如图8.11的左半部所示。
自底向上的设计是建立详细数据模型的过程，它产生数据库的物理设计和过程设计，如图8.11中右半部所示。
图8.11 自顶向下的规划与自底向上的设计
许多组织都进行了这种或那种形式的自顶向下的信息规划，他们常常用不同的名称来称呼这些规划工作。
这些规划工作通常不够详细，因而不能指导下一步数据库设计工作。
自顶向下的规划与自底向上的设计不应该被看成为互不关联和相互矛盾的过程，自底向上的设计是自顶向下规划的延伸，数据模型与实体图性质相同，只不过数据模型往往更加详细。
更加详细的设计工作能给自顶向下的规划工作提供进行调整的反馈信息。
这很象编写一本教科书。
作者心中有了目的和要完成的使命以及一系列目标，要实现这些目标，他必须首先写出提纲和每章内容的提要，然后开始一章一章地编写。
在他编写每一章的时候，具体编写工作有时会使他回过头来修改提纲和各章的提要。
那么提纲和各章的提要应该详细到什么程度呢？
作者们意见可能会很不一致，但是如果最初的规划工作进行得比较全面，最终著作质量会比较好。
自顶向下的数据库规划工作也是如此，它必须足够全面，但时间不能过长而拖延数据处理应用项目的开发工作。
编写提纲或者绘制实体图的工作，必须在较短的时间内迅速完成，所确定的实体必须非常正确。
它们的关键字和联合关键字不一定要定死，这些详细工作可以在建立详细数据模型时完成。
建立详细数据模型时会导致实体图中的一些变化，为强调绘制实体图的短期快速要求，或许可以用"粗略实体"来称呼最初绘制的实体。
一个组织所需要的是自顶向下的规划和自底向上的设计两方面的最好结果。
自顶向下的规划应该主要考虑生产率，消除重复的应用程序和维护工作，重新组织公司的业务流程和组织结构，以获得更高的效率；自底向上的设计应该考虑稳定性、第三或第四范式设计、最终用户语言、降低维护成本、灵活性和未来应用程序的快速开发等等。
自顶向下的绘制实体图和自底向上的建立详细数据模型，可以起到相互参照的作用。
应该使用相同的设计工具，从而使得在实体分析阶段所确定的属性或所收集的资料能够被存储起来，供建立详细数据模型的工作使用。
2．关于研究范围的控制问题
在开始进行实际分析研究时，必须决定所要研究的组织的范围。
对于小的企业当然肯定应当研究整个企业，对于大型企业有必要一部分一部分地进行研究。
要求实体分析尽可能简单的一个原因，是为了使得能够对组织中尽可能大的范围进行研究，这样做是为了要能够在尽可能大的范围内发现共同的实体。
3．关于重复处理问题
我们曾经强调在文件环境中存在着大量的重复数据。
在第二类数据环境中许多不相关的人员都在建立他们的自己的数据库，因此也存在着大量的重复数据。
另外一个较为隐蔽的事实是，在大多数企业中还存在大量的重复应用程序。
采用数据库技术以后，不一定必须会消除重复的应用程序和重复的处理工作。
互相不通气的分析人员，常常提出一些对相同数据的重复处理。
在一家小型纺织公司中，人们发现有9项独立的活动在处理到货业务，实际上每项活动都进行一系列相同的作业，产生一个到货记录。
公司中有好几个地方都接收货物，先后为每一个收货地点都设计了有关的表格和单据，并且开发了不同的应用程序来处理这些单据。
因此，产生了9套应用程序，而实际上一套就够了。
这9套应用程序都会带来维护成本。
这9项活动粗看起来都有一些细微的差别，但是，在仔细研究了单据上的数据之后，显然可以看出，它们实际上是相同的。
在公司的发展和成长过程中，常常会出现这种职能的重复，浪费了大量的数据处理资源。
公司实体分析目标之一应该是尽可能消除不必要的重复处理。
我们曾经指出，在大多数公司中数据变得非常混乱，当人们对其进行全面协调的分析时，结果是令人震惊的。
而且数据处理逻辑也非常混乱，会有很多不必要的重复。
互不联系的系统分析人员，各自开发出自己的处理程序，而没有意识到他们在互相重复着别人的工作。
4．关于管理人员的参与问题
当非数据处理管理人员参与实体分析工作时，会迫使他们考虑企业管理需要哪些实体和关于哪些实体的数据能够提供他们所需要的信息。
数据处理专业人员通常难以回答这样的问题。
只有非数据处理专业的管理人员知道公司到底是怎样经营的，以及他们怎样才能够改进公司的经营效率。
当高级管理人员准备投入至少一小部分时间时，常常会发现数据处理人员和他们之间发展了良好的沟通关系。
实体分析是他们之间的共同基础。
在这方面不需要任何技术术语，一旦非数据处理管理人员知道实体是什么之后，他们就能够确定自己业务范围内的实体。
教会他们第一范式的概念，能够帮助他们理解实体的概念。
有时物理数据组织的传统概念会限制数据处理人员的创造性思维，而非数据处理人员则没有传统数据处理概念的限制。
另一方面，非数据处理人员的思想往往受到现有系统的限制。
因此，也必须使他们的思想活跃起来，他们必须认识实体之间的基本共同点，理解为什么一张单据实际上与另一张单据是相同的。
应当尽可能让非数据处理管理人员的业务直觉起指导作用。
实体分析向他们提供了重新考察组织中的工作以及考虑如何改进工作的一次机会。
非数据处理管理人员的业务直觉常常能够产生比仅仅由数据
升级会员 