一个人、一本书、一辆汽车都是一个实体。实体可以相互区分，这是因为每个实体具有不完全相同的特征。
b.特征和码。实体的特征又称为实体的属性。一个实体可以由若干个属性来描述，其中能够惟一地标识实体的一个或一组属性称为实体的码或者关键字。
c.实体集。实体集是具有相同特征的实体集合，例如，全部产品组成了产品实体集，全体员工组成了员工实体集等。实体集的整体结构称为型，其中的一个成员（个体）又称为值。在内部模式中，实体型通常被定义为表（table），实体的属性则是表的字段或者域（field），实体值就是表的记录。
d.联系。现实世界中的事物是有联系的，这种联系必然要在信息世界中予以反映。实体间的联系主要有3类：一对一联系、一对多联系、多对多联系。
（3）E-R图
E-R模型是用E-R图来表示的。画E-R图时一般作如下约定：
a.实体型用矩形框表示，在框内标注实体名。
b.实体的属性用椭圆框表示，并用无向边把实体与其属性连接起来，在椭圆框上部加短横线表示该属性为实体的码。
c.实体联系用菱形表示，菱形的旁边写上联系名。用无向边把菱形分别与有关实体相连接。如果联系也有属性，则将其与菱形也用无向边相连接。
（4）管理信息系统
管理信息系统（MIS）是建立在数据库上的应用软件。企业早期开发的管理信息系统大部分是根据局部视图建立起来的，由于缺乏集成的思想，成为支离破碎的信息孤岛，不能给企业带来最大的效益。现在流行的企业管理软件MRPⅡ和ERP是集成化的管理软件。这样的软件整体上对应着全局数据模式，包含了大量的功能模块，每个完整的功能模块可以看成是由一个局部视图产生的软件，或者说是某一个子模式的应用软件。如果打算自己开发集成化的管理软件，那么在设计策略确定后，就要从用户的局部视图设计开始，经视图集成，得到一个能够支持企业管理各种应用的全局数据模式。这个过程称为数据库的概念设计。然后，再进行数据库的逻辑设计。常见的情况是把E-R模型转换为关系数据模型，再对所得到的关系模式规范化，至少要达到3范式（3NF），高要求则应该形成5范式（5NF）。最后，进行数据库的物理设计，也就是把逻辑设计得到的概念模式转换为内部模式。
数据库设计对设计人员的专业知识和经验要求非常高。加上开发应用软件的工作量和对软件的测试，企业技术人员很难在短时间内完成这项工作。
在购买商品化软件的情况下，也需要进行信息系统的设计，一般只要给出用户视图便可，然后根据用户视图去寻找合适的商品软件。用户视图通常反映了企业当前的管理水平和运行逻辑，它与商品化软件经常会发生矛盾，软件很可能不支持用户已经习惯了的业务流程，而软件提供的很多功能用户觉得不需要或者不理解。
这种矛盾意味着管理思想的冲突，也就是信息化促使企业管理改革的关键所在。
在处理当前企业管理方法和软件的冲突时，要具体问题具体分析。如果是因为企业管理思想落后，那么要改革企业管理；如果是因为软件设计考虑不周到，那么就要对软件重新进行开发。当修改软件功能时涉及数据库的模式，一定要特别慎重，不能修改或者删除原有系统的基表和基表的字段。
2.3.2管理信息的采集
2.3.2.1整理流程
在正常情况下，企业运行了一段时间或者企业机构进行了调整都会提出改变管理流程的要求。企业流程整理实际上是企业为了提高工作效率经常要做的工作。从更广义的角度，可以将其称为企业的经营过程重组（BPR）。企业信息化是企业管理的重大变革，必然要涉及BPR。整理企业管理流程只是BPR的第1步。
对于没有BPR基础的企业，流程整理可以分3步进行：画业务流程图、画数据流程图、设计新的管理流程图。
（1）画业务流程图
画业务流程图并不困难。一些通过ISO9000论证的企业，应该有比较完整的业务流程图和相应的管理规范文档。由于业务流程图一般由各业务部门分别完成，经常出现的问题是不同部门对于业务流程图中的图形和符号的规定不一致。
因此，在本项工作开始前，要对有关人员进行简单的培训，说明目的、作图规则、进度要求等。
业务流程图还应该附有文字说明。
本业务流程图说明外购件或者转包部件入库的过程：货物到达后，采购部门开出入库五联单，把其中的质检单送质检部、入库单送仓库、应付款通知（发票）送财务部；质检部收到质检单后，对入库物品进行质量检查，出具质检报告单，合格品的质检报告单送仓库作为物品入库的依据，不合格品的质检报告单随质检单一起退回采购部；采购部及时收回入库单和应付款通知；仓库收到入库单和质检报告单后，清点货物数量，完成入库操作，把入库报告单送财务部；财务部收到入库报告单后，安排付款，通知采购部回收发票。
全部业务流程图完成后，进行分类，装订成册，并在档案室保留一份。如果企业已经通过ISO9000论证，可以把其中的业务流程图作为信息化工程的原始材料，直接进入下一个工作步骤。
（2）画数据流程图
数据流程图（DFD）是在业务流程图的基础上，对企业管理全部功能和主要数据流的全局性描述。先把业务流程由下至上整理成功能树，如图2.6所示。
把功能树和业务流程图结合在一起，就可以画出系统的DFD。作图前要约定图中使用的符号，一般用圆型框表示功能，矩型框表示部门，不封口的矩型表示文件，带箭头的连线表示信息流向。
我们只是从原理和方法上简单地介绍DFD的概念，实际使用时比较复杂。在图上一般还要注明作者、审核、批准人员的姓名和日期，还应该有必要的文字说明。
全部DFD完成后，将其装订成册。
（3）设计新的管理流程
新的管理流程应该在软件的实施中逐步完成。一般也要从业务流程开始，根据软件提供的功能对原来的业务流程进行分析和确认，由新的业务流程图修改DFD。新的DFD应该与软件安排的数据流向基本一致。新的管理流程还应该包括一套新的管理规范和计算机操作手册，有关管理规范和操作手册的问题将在第2.6.3节讨论。
2.3.2.2定义用户实体
定义用户实体的工作相当于建立数据库初期的抽象数据对象的工作，而不是为建立概念模式定义实体。为了不混淆概念，我们把这里的实体称为用户实体。
（1）定义用户实体的目的
定义用户实体是企业信息化工程的一项基础工作，其主要目的是：
a.结合业务流程图和DFD分析企业的业务过程以及在业务过程中数据流动情况，删除冗余的实体、属性和流动环节。
b.奠定分析软件的基础。在购买商品软件的前提下，不再对用户实体作进一步的整理和规范化，但是要考察它们能不能由当前软件的数据库产生出来，差异有多少。
c.作为企业流程重组的基本文档。
d.作为进一步软件开发的依据。
（2）定义用户实体的步骤
第1步：详细调查每一项业务过程，在画业务流程图时收集所涉及的原始表格、单据等数据载体。
第2步：命名实体和实体联系。根据业务流程图和上面收集到的数据载体，可以发现每一类事务活动总要涉及1个或几个实体。在同一种活动中涉及多个实体，意味着这些实体间存在某种联系。一个简单的判别方法是：在业务流程的描述中，名词对应实体，动词对应联系。
第3步：调查各类用户对数据处理的要求。主要包含如下内容：
a.处理周期；
b.处理内容；
c.处理频度；
d.数据规模；
e.安全保密的要求。
第4步：识别数据元素。根据已经找出的实体，初步识别描述它们的数据元素，即确定实体属性，包括数据元素的名称、是否可以作为关键字、数据类型、取值范围（值域）等。设计实体属性汇总表。
第5步：检验数据的完备性。对于所收集到的数据集，验证它们是否能支持所有的应用需求。如果在检验中发现新的数据需求、新的数据实体、新的联系和相关的事务规则，还要对前面收集到的数据集作必要的补充或调整。
（3）建立E-R模型
完成了实体、实体属性、实体联系的定义，又有业务流程图作为参考资料，建立ER模型就不困难了。E-R模型的概念已在第2.3.1节作了简要介绍，这里要强调的是购买软件时，供应商提供的资料中也应该有软件的E-R图或者类似的模型。
两种E-R模型除了因为对实体的定义和处理的不同而造成差异之外，在一定程度上反映了现行的管理模式与软件代表的管理模式之间的差别。这是企业在信息化过程中要重点关注的问题之一。
E-R模型是企业信息化工程的重要里程碑。不管是购买ERP软件还是自行开发ERP软件，建立E-R模型都是必要的工作阶段。在对购买还是自行开发ERP软件作出决策后，需要进行不同的后续工作。如果决定购买软件，可以按照本书的思路继续工作。如果决定自行开发软件，后续工作将是：E-R视图集成、数据库逻辑设计、数据库的物理设计、应用软件开发，这些工作已经超出了本书的内容，有兴趣的读者可以参考其他书籍。
E-R视图集成对设计人员有较高的要求。如果决定购买商品软件，可以不进行E-R视图集成，此时我们得到的是局部视图。在进行E-R模型对比时要考虑下列问题：我们建立的是局部视图，商品软件提供的很可能是全局视图，两种视图在形式上的差别可能非常大。因此，在对比时重点考虑我们建立的局部E-R模型如何从全局E-R模型中映射出来，在映射的过程中发现两者的差异。
2.3.2.3分析数据流向
在购买ERP商品软件之前，有必要详细分析数据流向，其结果将是考察软件能否满足企业需求的重要依据。可以从两个角度分析数据流向：按照职能部门的流向和按照功能模块的流向。按照职能部门的数据流向分析可以在业务流程图的基础上进行。按照模块的数据流向分析与软件有直接关系，只有在对于软件有一定程度的了解后才能进行此项工作。
2.3.2.4建立原型
计算机软件和硬件安装完毕并且测试正常后，接下来的工作是建立系统原型。
系统原型是现实世界在计算机内的仿真环境。除了数据是虚拟的而且规模比较小之外，其他方面的要求与实际运行的系统相同。
系统原型的主要作用是：
（1）作为设置软件参数的对象；
（2）协调部门工作的试验环境；
（3）支持管理规范和操作手册的制定工作；
（4）研究管理模式和培训人才的基础。
建立系统原型要在软件供应商的参与和咨询公司的支持下才能够顺利完成，一般工作步骤为：
（1）供应商安装计算机硬件和软件，使其工作正常；
（2）在软件供应商或者咨询公司的指导下设置系统参数；
（3）在软件供应商或者咨询公司指导下建立模拟数据并将其输入系统，测试系统在加载情况下运行是否正常，数据的一致性如何；
（4）与职能部门讨论管理模式和数据流程，建立管理规范和操作手册，培训操作员；
（5）设计实例，模拟运行。
2.4工程信息的定义和采集
工程信息是指在产品设计和产品工艺设计中产生的数据。本书不强调信息和数据两个名词在学术概念上的差异，所以又称工程信息为工程数据。在生产过程中，这些数据一般不能够随意变化，即使需要修改也要按照一定的管理程序操作，以保证数据的权威性。管理信息系统中的很多固定信息，例如零件主数据中的一部分属性、物料清单（BOM）、工时定额、材料定额、工艺路线等，来源于产品设计和工艺流程设计。工程信息和管理信息的集成是企业级信息集成研究的重点之一，本书将在第5章讨论这个问题。
2.4.1工程信息的定义原则
每个生产企业都有负责产品设计的部门和技术人员，其职责是按照市场和经营决策的要求开展产品及其零部件的设计、绘图、分析并编写技术文档。从信息技术的角度看，他们定义与产品有关的工程数据并把这些数据输入信息系统。计算机辅助设计（CAD）产生的信息有三维造型图、二维工程图、工程分析数据、动态模拟数据等；计算机辅助工艺设计（CAPP）产生的信息有毛坯设计、加工方法、工序设计、工艺路线、工时定额和材料定额等。这些数据中包含了大量相互关联的图形、公式和表格，不能用简单的E-R模型表达，只能用工程数据库来管理。
工程数据的管理包括两方面内容：一方面是对于CAD/CAPP/CAM（计算机辅助制造），即3C产生的数据和3C系统内部集成的工程数据进行管理；另一方面是对于3C系统和MRPⅡ系统集成的工程数据进行管理。很多人都倾向于用面向对象的数据库技术来实现工程数据库的管理。工程数据库作为产品模型数据库，既具有管理数据的基本功能，又包括支持产品及工艺设计的功能，主要表现为：
（1）方便地定义和处理存储在内部的层次结构数据，使之符合产品模型数据交换标准（STEP）；
（2）支持用户定义新的数据类型和相应操作的能力；
（3）灵活地定义和修改系统数据模式的能力；
（4）版本管理的能力；
（5）方便的数据检索和约束检查的能力；
（6）以工程形式管理数据的能力；
（7）CAD/CAPP/CAM工程事务处理的能力；
（8）支持合适的产品数据建模语言。
