数据建模与ORM---构建通用的数据模型-毕业论文

本科毕业论文(科研训练、毕业设计)题 目：数据建模与ORM -构建通用的数据模型姓 名：学 院：软件学院系：专 业：软件工程年 级： 学 号：指导教师（校内）： 职称： 指导教师（校外）： 职称： 年 月 日数据建模与ORM-构建通用的数据模型摘要 本文回顾了数据建模的发展，指出在概念建模上ER和UML获取约束和业务规则的表达能力方面的不足，提出了一种适用于概念建模的方法对象角色建模（Object Role Modeling，ORM）。通过使用ORM，可以使原来难以表达的业务规则更容易表达，方便与业务人员交流。本文介绍了ORM图的基本要素和建立的流程，并用在ECIF项目中的一个案例来探讨利用ORM建立数据模型的方法。最后介绍了通用数据模型的作用及其实施方法。通过使用通用数据模型，可以在建立数据模型时站在更高的起点上并且降低成本。关键词 对象角色建模 实体关系 统一建模语言 通用数据模型Data Model and ORM-Build Universal Data ModelAbstract This paper first reviews the history of data modeling method, then points out ER and UML which gets constraints and operation rules has shortage, so presents a applied conceptual information modeling method named（Object Role Modeling , ORM）.You can use ORM to build model that express business rules and communicate with expert easily .The main elements of the ORM and the procedure to build it are then described in detail, and illustrates the use of it by a concrete case in ECIF project. Finally, introduces the function of universal Data Model and implements method. Builds the model at higher jumping-off point and saves cost since you uses Universal Data Model.Key words ORM ER UML Universal Data Model1目录第1章 绪论11.1 引言11.2 课题背景11.3 研究意义21.4 工作内容31.5 论文组织3第2章 ORM基本介绍42.1 ORM的几个基本概念42.2 对象关系图的表示42.3 ORM的特点62.3.1 在表达业务规则时更贴近业务人员62.3.2 完整表达业务逻辑72.3.3 对领域专家验证有效性和样本成员集有效性的支持好82.3.4 灵活的子类型方式92.4本章小结10第3章 通用数据模型的基本介绍113.1通用数据模型的提出113.2通用数据模型主要用途113.3本章小结12第4章 ORM的设计方案134.1 ORM的基本设计原则134.2构建通用数据模型144.3本章小结14第5章 ORM模型的设计155.1 概念模式设计过程155.2 用项目中的一个案例说明具体应用过程155.2.1 搜集原始信息155.2.2 把这些事实表达为对象和角色165.2.3 实体类型的合并175.2.4 添加惟一性约束185.2.5 添加强制约束195.2.6 添加值约束、子集约束以及子类约束205.2.7 添加其他约束，并作最后检验225.3 ORM模型的通用性225.3.1 ORM模型术语的改变225.3.2 企业所需的附加信息245.4 本章小结25第6章 通用数据模型的实施266.1 通用数据模型的实施方法266.2 本章小结27第7章 总结28致谢语29参考文献30附录311数据建模与ORM -构建通用的数据模型第1章 绪论1.1 引言众所周知，数据是一个数据库应用系统最核心的部分。好的数据建模，对于整个系统的质量具有重大影响。多年来，在业界广泛使用ER模型进行数据建模。但是ER模型存在着一些缺点，随着业务系统的进一步复杂，业务规则的多样化，ER模型的表达能力受到很大挑战；而且ER模型更贴近数据库实现，不利于与用户交流。新近推出的UML，解决了ER的一些问题，但是在表达静态业务规则上仍然不足。本文主要介绍ORM在概念数据模型方面的应用，该方法可在很大程度上解决这些问题。1.2 课题背景ER模型最早于1976年由Peter Chen提出，在数据库界产生了极其深远的影响，成为数据库建模的标准方法1。ER模型把业务领域的数据看成由两部分组成：首先是一个个实体，其次是实体与实体之间发生的相互联系。数据库即存储这些实体以及实体之间的关系。随着时间的推移，不少学者提出了各种各样的ER扩展，使其表达方式更丰富。其中最重要的是Oracle公司的Barker扩展，Oracle的数据建模工具，即使用该表达方式。由于Oracle在数据库市场的领头地位。Barker扩展也成为使用最广泛的表达方式。但是，即使如此，Barker扩展并没有最终完成标准化的任务。其他数据库厂商、数据建模工具厂商等各自有自己的表达方式。给使用者带来很大的困惑。因此，标准化成为困扰ER的一个很大的问题2。1997年11月，OMG正式推出UML，给数据库建模者一个全新的选择，但是，UML 设计的重点不在于数据库静态建模，而在于给面向对象软件过程整个生命周期的建模给予支持，数据库建模主要用到其类模型和对象模型两类模型。UML克服了ER标准不统一的问题，并且在表达方式上比ER丰富一些，但是UML把业务领域的数据看作是对象以及对象之间的联系。本质上与ER是相同的，所以可以看作是一种扩展的ER表达方式。无论是UML还是ER，在进行数据建模时主要存在以下几个问题：(1) 表达能力有限，不能完全表达业务领域的业务规则；(2) 表达方式太偏重实现细节，不易被业务人员所理解；(3) 建模流程比较粗糙，整个建模过程比较困难。ORM是微软的Terry Halpin博士在一些前人研究的基础上，着重解决以上一些建模方法的缺点，帮助数据建模人员更好把握业务规则而提出的一种全新的方法，是微软最新的Visual S的核心数据建模方法。ORM是Object-Role Modeling的缩写，核心思想是把客观事物看作是对象，用每个对象的角色来描述对象与对象之间的关系3。1.3 研究意义ORM相比于ER和UML有了重大的突破：1. 把事物的属性也分离出来，作为一个建模研究的对象。因为在ER建模中，把一个信息到底作为一个属性还是作为一个实体来描述，判断起来是十分困难的。往往一开始都倾向于简单化，把一个信息看作是属性，但随着建模的深入，会发现要把该属性分离出来，作为一个单独的实体来描述。这种变更会带来设计的很大变动。这也是ER和UML的一个很大的缺点，即模型不稳定。2. 强调表述的规范化，避免二义性，使用语言描述辅助业务规则表达。使用图形表达是ER、UML的优势所在。但是，如果不强调表述的规范化，由于图形描述的随意性，就会带来二义性。因此，ORM特别强调表达的规范，并且通过语言描述来弥补图形的缺点。使与业务人员交流更为方便，业务人员确认业务规则也更为容易。3. 强调建模流程。不管是ER、UML还是ORM，就像是建筑材料，而最后建筑物的质量好坏主要取决于建筑的流程。ORM有完整的建模方法学的支撑，使得业务规则成为一门技术，而不是依赖于建模人员个人能力的艺术。鉴于ORM相对于ER、UML的重大突破，对于我们研究ORM的数据建模非常有意义。1.4 工作内容本课题主要是在了解数据建模、ORM、通用数据模型的基本概念，理论知识及其优势后，分析传统的数据建模的方式和采用ORM进行数据建模的异同，进一步明确采用ORM数据建模的理论进行数据库建模的优点，运用ORM的规范流程进行数据建模，构建一个通用的数据模型。1.5 论文组织本文主要阐述设计的主要工作是用ORM进行概念数据建模，并使构建的模型能够成为通用数据模型。第2章介绍ORM的基本元素，以及如何用图形表示出这些形式化的语言。表述了ORM相比于ER和UML的优势。第3章介绍通用数据模型的基本情况，通用数据模型的提出和它的用途。第4章阐述本次ORM设计的方案，确定设计应遵循的原则以及达到的目标。第5章经过分析和调研进行具体的ORM模型设计，并以设计的一个模型中的部分进行分析，并说明ORM设计出的模型具有通用型。第6章对于ORM设计出的通用数据模型，介绍如何具体实施以支持不同类型的系统开发。第2章 ORM基本介绍ORM结合了图形建模方法和形式化语言建模方法的优点，本章介绍了ORM的基本元素，以及如何用图形表示出这些形式化的语言。2.1 ORM的几个基本概念 对象（Object）：现实世界中的一个物理存在或是一个概念，即可以是实体或值。 实体（Entity）：通过将它与其他对象相联系来引用的对象，不是值。一般地，实体随时间而变。实体是原子的或嵌套的。在顶层，实体被分割为基本实体类型，用它们可以定义子类。 角色（Role）：联系对象扮演的部分。 联系（Relationship）：涉及一个或多个对象性质或关联。如果谈论联系（即，联系本身扮演某个角色），那么，它也变成一个对象，称为对象化联系、对象化关联或嵌套。 约束（Constraint）：对可能状态（静态约束），或转换（动态约束）的限制。设计的模型主要使用到外部唯一性约束、内部唯一性约束、相等约束等。谓词（Predicate）：本身带有对象空穴的命题（如，“.works for.”）。2.2 对象关系图的表示O-R图的基本要素是：对象、角色和联系，其基本符号如下：1）椭圆a.实线表示实体类型，以命名的椭圆表示且必须有一个引用模式，即人们引用那种类型实例的方式。简单的引用模式可以用圆括号表示。b.虚线表述值类型，用虚线的椭圆表示。2）方框在概念模式图中，对象充当的角色用方框表示。每个元谓词（0）描述为个对象框的相邻序列（“相邻”表示框邻近，中间没有空隙）。谓词从一端到另一端顺序排列，它们的名字写在它们第一个角色框的里面或旁边。3）连线a.不带箭头连接对象和角色，表明这个角色只被这个类型的对象充当。b.带单箭头由子类指向超类表示继承关系。c.带双箭头表示对象间的关系，外部唯一性约束。如图2-1所示，为对象、角色和联系的简单表示。（该图为联系地址部分模型见附录b）如图2-2所示，唯一性约束的几种表述方法。图2-1O-R图中对象、角色和联系的表达方法Fig.2-1 Object、Role and Relationship in O-R diagram图2-2O-R图中唯一性约束表达方法Fig.2-2 Uniqueness constraint in O-R diagram2.3 ORM的特点下面将说明ORM与ER、UML相比具有的优势：2.3.1 在表达业务规则时更贴近业务人员ORM建立在语言学基础上，在与领域专家交流，确认有效性，利用语言表示成员集方面具有优势。图2-3 一个公司规模级别的ER图Fig.2-3 Companys size at grade in ER diagram图2-4 一个公司规模级别的ORM图Fig.2-4 Companys size at grade in ORM diagram比较图2-3和图2-4（该图在数据模型-公司中的部分）。虽然便于简单的观察，但ER模型与ORM模型相比，存在许多缺陷。首先，它与自然语言的差别很大，因此领域专家难以概念化。在这个实例中，应当自然地用三元关联描述，但是所有工业界支持的流行ER符号都限定为二元（两个角色）关系。只存在二元关联不会降低语言的表达能力，因为一个n元关联可以通过相互引用或嵌套转换为二元关联。然而，这种转换可能把一个人造的对象类型展现在领域专家面前，从而阻碍交流。无论可能性如何，都应当试着用一种让领域专家看起来自然的方式表达模型。2.3.2 完整表达业务逻辑业务逻辑主要可分为几个对象之间、对象属性之间和联系之间的关系。ER和UML主要能表达几个对象之间的关系，亦能表达部分联系之间的业务逻辑。但是对象属性之间的属性与另一个对象之间的业务逻辑就没办法表达了。如有以下业务逻辑。在参与人的信息中，若要更新柜员则应同时更新机构。如果用ER表达，只能表达为图2-5的形式。图2-5 ER表示的参与人部分信息Fig.2-5 Party information in ER diagram当要记录参与人中的更新柜员和更新机构这两个属性，应该同时记录。输入这些更新数据时，用复合事务输入这两个信息。对于数据库的任何状态，有更新柜员记录的参与人集合和有更新机构记录的参与人集合是相同的，这样的约束是相等约束。这样的业务规则，在ER中是难以表达出来的。而如果用ORM表达如图2-6。图2-6 ORM表示的参与人部分信息Fig.2-6 Party information in ORM diagram当中的等同约束可以清楚地表达出这一业务规则。使用ORM，可以表达出以下ER和UML难以表达的业务规则：（1）或约束；（2）异或约束；（3）子集约束；（4）等同约束；（5）环约束；如何表达上述规则可查阅参考文献4。2.3.3 对领域专家验证有效性和样本成员集有效性的支持好在UML模型中，虽然可以表达出三元关联，但是UML关联角色没有被排序。因此，通常不知道读取语句的顺序如何。如果相同的类在关联中扮演多于一个角色时，这会变得更糟糕。（比如，Person介绍Person给Person）。UML的确允许关联角色有名字，但这没有任何帮助，因为角色名字不形成常常在自然语言里排序的语句。UML关于事实语言表示的缺点延伸到约束和推导规则的语言表示中。基于属性的符号对于多重实例几乎没有用，并且会引入基本成员集的空值，及其全部的混乱特性。所以UML对领域专家验证有效性和样本成员集有效性的支持并不好。相反，ORM模型由于用混合谓词替换关联名称，用语言表述抽象成事实类型的事实实例的样本数据。然后，加入约束条件和可能的推导规则，通过语言表述和样本事实的成员集来验证自身的有效性。因此，ORM在对领域专家验证有效性和样本成员集有效性方面的支持好。2.3.4 灵活的子类型方式ORM的一个特性就是灵活的子类型方式，包括多重继承，由基于形式化的子类型定义所支持。子类型定义比单纯的关于子类型是否排他或无遗漏的声明提供了更强的约束。建模中使用子类的主要原因是声明特定的角色只被那个子类所扮演这样的约束。例如，图2-7中(可见附录b)，“PhoneNr”所扮演的角色只被子类“Telephone”所约束。ORM中子类化的灵活就在于避免纯粹为了暴露分类模式而引入子类。分类学可以用更经济的方式被建模。例如，为了表明有四种联系机制，可以在联系类型“Type”上加一个值约束，如T，E，W，P。 例如，图2-7中子类型“Telephone”被定义为联系地址中代码表示为T； 子类型“Email”被定义为联系地址中代码表示为E； 子类型“WebLocation”被定义为联系地址中代码表示为W； 子类型“PostedAddress”被定义为联系地址中代码表示为P。除非在应用中需要让它们扮演特殊的角色，否则没有必要引入这几个子类。这就避免了子类纯粹是为了分类法，那么，子类的数目就难以控制。这在子类数目多时尤其重要，例如，假设我们感兴趣根据出生地将人员分类。这时所需要的事实类型Person was born in Country。如果用每个国家都引入一个Person子类取而代之，那么，每个模式中可能会存在200多个子类！这个数字让人吃惊。如果这些子类中有一个扮演一个特殊的角色，我们才引入这个子类，否则，就没有必要将所有子类全部引入。综上，可以看出用ORM的子类化定义非常的灵活。 图2-7 ORM的子类型定义方式Fig.2-7 The define mode of Subtype in ORM diagram2.4本章小结本章对ORM进行了基本的介绍，描述了ORM的元素代表的意义以及它们的表达方式。特别用图文介绍了ORM相对于ER、UML所具有的一些不同的特点。通过比较可以看出对于概念信息分析，ORM比ER图及UML方法有一些优势。第3章 通用数据模型的基本介绍本章介绍通用数据模型的基本情况，包括为什么要提出通用数据模型和它的用途。3.1通用数据模型的提出传统的企业信息系统建模方式是从头开始，通过对企业的调研和与用户的交流，仔细了解企业的各个应用主题数据，通过多次反复，为企业的数据逐步建立起各种模型。在此过程中，建模人员和用户都需要花费大量的时间、精力和财力，才有可能建立起较为完善的企业数据模型。而再做另一个企业信息系统的建模工作的时候，可能还要花费差不多的时间和投资。但是通常50%以上的数据模型都是由适用于多数组织机构的通用构件组成的，有其他25%的数据是行业特殊的，平均起来，约有25%的企业数据模型是只有该企业才有的。这点意味着数据模型的大部分建模工作都是在重复建立其他许多组织机构曾多次建立过的数据模型构件。因此使用共同或通用数据结构，以使得在建立数据模型时能站在更高起点上并且省下时间和金钱5。具体的通用数据模型的概念的提出，是在对应某一具体应用背景所提出的相关需求后，创立共享数据库元数据的各组成部分，并将各组成部分结合成一个逻辑上协同的整体。3.2通用数据模型主要用途有助于建立一个能展示出不同应用中信息之间的关系的企业数据模型。这是企业信息集成的一个关键部分。为开发逻辑数据模型提供一个起点。为企业现存的数据模型添加新的部分。检验企业现有的逻辑数据模型，并为进一步的增添和修改提供思路。有助于系统开发者理解不同数据的本质和实现为企业提供更佳信息的选择和方案。有助于理解企业的信息需求，并可用于作为选择和实施应用包的基础。应用包的需求一般包括功能需求、数据需求和技术需求。数据模型可以用作数据需求。企业需要了解它自己的需求来合理地选择和实施应用包。可以作为一个信息路线图来确认和同步来自不同系统的数据。即使企业已经决定主要使用应用包而不是根据企业自身状况建立系统，它也可以使用企业数据模型来确认信息需求，来确定应用包存储冗余数据的位置。3.3本章小结通用数据模型可以用于迅速地建立企业数据模型，为企业提供一张“路线图”，它能够表明信息是如何同其他信息相关联的。有了这些路线图，在项目开发时可以使用相同格式的数据结构、相同定义的数据项，甚至相同的物理数据结构。这种方法可以极大地提高数据的一致性和质量，最终使得信息能够更好地用于改进企业的运作。企业数据模型记录了企业的信息需求，有助于企业对其信息进行集成5。第4章 ORM的设计方案本章阐述了本次的ORM模型设计应遵循的原则以及达到的目标，就是用ORM构建数据模型并使模型具有通用性。4.1 ORM的基本设计原则在构建ORM数据模型时应遵循以下的原则：可表达性语言的可表达性是对语言表达能力的度量。该语言能捕获的领域特征越多，它的表达能力就越强，概念语言应该能够完全表达建模概念相关的应用领域的所有细节。ORM是在概念层用于建模和查询信息的一种方法，并可以在概念层和逻辑层之间进行映射。虽然ORM的扩展部分针对过程建模，但ORM的核心是在信息建模，因为数据角度更稳定并提供了关于哪些操作可被定义的形式基础。总的来讲，UML比标准ORM的表达能力更强，因为UML采用用例、行为和实现图表模型，而不仅仅局限于静态结构。然而。对于概念建模，ORM的图表记号比UML的类图和ER图表的表达能力都要强大得多4。简洁性和正交性通过回避属性，ORM基于角色的记号是简化的，同时通过把它和事实实例结合也更易理解。正交性允许利用无论何处都可以使用其含义或值的表达式。ORM的结构是基于正交性建立的。例如，ORM约束在其有意义时可以被使用和结合。这在UML语言中是不正确的。语义稳定语义稳定是对表达建模和查询的语言面对不同的应用时能不能很好地保持它们最初的意图的度量。为了配合应用变化而对模型和查询所做的变化越多，语义的稳定性就越差。由于不被那些引起属性重新建模为联系（或相反）的变化所影响，ORM中的模型和查询在语义上的稳定性要强于ER和UML。有效性检验机制有效性机制是领域专家用来检验模型是否与应用匹配的方法。与ER和UML不同，ORM模型通常容易言语化。抽象机制抽象机制允许从直接构思中除去不必要的细节。这对于大型的模型来说很重要。ORM图往往比相应的ER或UML模型更详细、更大，所以常常使用抽象机制。这些机制可以用于隐藏或显示与用户的直接需求相关的那部分模型。通过很小的变换，这些技术可以应用于ORM，E-R和UML中。ORM同时包含一个属性抽象过程来产生E-R和UML 图的视图。形式基础需要一个形式化基础来确保清晰性和可执行性并允许模型之间的等价、蕴含的形式化证明。对于数据建模结构，ORM，E-R，UML有足够的形式化基础，并且ORM更丰富，图形约束记号为模式转化提供了一个更完备的图像化方法。4.2构建通用数据模型由于通用数据模型可以为企业提供一致的集成系统，避免了数据的不一致和冗余，可以为企业节省了人力和物力，使建模者站在更高的起点。所以在进行ORM数据建模时应尽量的对系统进行集成，成为通用的数据模型。为了成功运用通用数据模型，将其作为创建企业数据的基础，就必须从企业业务开始，将信息保持在一个业务人员能够理解的水平是非常重要的。在准备企业数据的过程中，应该完成企业概念的定义。为了能够广泛地表达各种视点，模型应该是灵活的，能够解决多个业务问题。本次的设计目标就是构建具有通用性的ORM数据模型。4.3本章小结为了构建出的ORM模型能满足通用性，在设计的过程中应遵循ORM建模的原则和建模流程（将在下章介绍）。在上述原则的指导下，构建出一个具有集成度和灵活性高，能解决多个业务问题的通用数据模型。第5章 ORM模型的设计本章阐述这次设计的实际工作，根据ORM概念模式设计过程来构建通用数据模型，并用ECIF项目一个公司模型中的角色人员来具体分析每个步骤是如何进行的。5.1 概念模式设计过程概念模式设计过程就是设计一个足够小、可以作为单元来管理的概念模式的过程。对于大型应用，论域被分成组件或小的部分（可能交叉）。对每个小部分应该这种设计，最后在把子模式集成为全局概念模式4。对于每个规模可控的应用，概念模式设计通过七步完成：把熟悉的信息实例转变成基础事实并进行质量检验。画出事实类，并用成员集检查。检验应该合并的实体类型，对所有的算术推导加以注释。增加惟一约束，检验事实类的数量。增加强制角色约束，检验逻辑推导。增加值、集合比较和子类约束。增加其他约束并执行最后的检验。5.2 用项目中的一个案例说明具体应用过程下面结合5.1的概念模式设计过程，具体介绍如何使用ORM进行建模。模型的完整图可见附录i，由于篇幅有限仅用模型中的部分有代表性的进行介绍。5.2.1 搜集原始信息如表1。符号“_”代表一个特殊的空值，表明在现场没有记录这个实际值。从原始信息中可以抽取出以下事实：f1 工号为702的员工在公司A01f2 工号为702的员工有姓名“张三”；f3 工号为702的员工持有证件“身份证”f4 工号为702的员工证件的号码为f5 工号为702的员工是法人f6 工号为702的员工学历为硕士f7 工号为702的员工从业时间是1995-10-20f8 工号为702的员工专业技术职称为高级同样还可以抽取出工号为321，562的基础事实。表1 原始信息公司id工号姓名证件类型证件号码人员性质法人学历法人从业时间法人专业技术职称委托法人有效期起日委托法人有效期迄日经办人联系电话A01702张三身份人硕士1995-10-20高级_A02321李四公司卡545421374834354656委托法人_2003-05-252005-5-25_A03562王五户口簿154487921215454646经办人_135093669595.2.2 把这些事实表达为对象和角色如图5-1中，把实体类型描述为命名的实线椭圆。数值类型用命名的虚线椭圆来表示。对象类型的名字写在椭圆旁边或里面。作为对已画出图的正确性的检验，还应该根据原始事实事例来填充图中的每个事实类型，这通过给每个事实类型，增加一个事实表，并给这个表相关列输入值来实现。在ORM中，事实表是用来显示基础事实类型中的事例的一个表。由于篇幅的限制，图中只显示了人员姓名之间的事实表内容。图5-1 初步的ORM数据模型Fig.5-1 primary in ORM data model5.2.3 实体类型的合并从原始数据可以看出，由于有的角色只能由它的相关对象类型扮演，因此需要子类化对象类型。例如，在图5-2中法人需要记录的是法人学历、法人从业时间及法人专业技术职称，但委托人和经办人就不需要记录。使用人员的类型来显示这种分类模式。一开始将委托法人的有效期起日和迄日分为两个对象来建模，但它们有共性是可以抽象出来的，用有效期这一对象来统一表达。图5-2经过合并化的数据模型Fig.5-2 combine in ORM data model5.2.4 添加惟一性约束每一个ORM事实类型附带一个隐含的惟一性约束，因为对于概念数据库的每一个状态，每一个事实实例都是惟一的。一元谓词只有一个角色，因此，对它只能应用一种惟一性约束。但是，二元或更长的谓词有多于一个的角色，因此，可以应用于其上的惟一性约束模式多于一种。所以这样的谓词，需要明确地说明惟一性约束。二元谓词惟一性约束的四种可能模式是多对多、多对一，一对多和一对一。这四种约束的画法可见第2章。对于二元谓词，最一般的情况是一个角色上只有一个惟一性约束。这表明角色事实列的每一个值必须是惟一的，其他列允许重复值。例如，图5-3上一个人最多只有一个名字，但一个姓名可以对应于多个人。因此在人-名字的人扮演的角色上面加上惟一性约束，则这列的值不可以重复，而名字列允许值重复。上面提到的是内部的惟一性约束每一个都是应用于单个谓词内的一个或多个角色。来自不同谓词的角色的约束就是外部惟一性约束。它的表示如图5-3所示，证件类型和证件号码的组合是惟一的。一个人可以有多种证件类型但每种证件只对应一个号码，由于证件号码可能是相同的，所以应将证件类型和证件号码组合起来才能惟一确定。图上的圈“U”代表“unique”来表示外部惟一性约束。如果用组合引用模式作为主引用模式，那么必须使用圈“P”来表示。图5-3 经过惟一性分析的数据模型Fig.5-3 Uniqueness constraint in ORM data model5.2.5 添加强制约束在设计过程的第五步，每一个角色都被分类为强制类型和可选类型。一个角色是强制角色，当且仅当对于数据库的所有状态，这个角色都必须由它的对象类型成员集中的每一个成员来扮演，否则，这个角色就是可选角色。强制角色被称为总角色，因为它被其对象类型的所有成员扮演。为了明确表明一个角色是强制的，在连接角色和其对象类型的线上加上强制角色点，这个点可以位于连线的任意一端。例如，图5-4所示，法人上的强制角色点表明，必须记录他的学历水平。同样委托人上的强制角色点表明，必须记录他的有效期起日和迄日。加上强制约束后，这样就在应用于对象类型成员时，限制了全局特性。如果向法人角色成员集添加实例，那么，也必须把该实例放到其他每一个对法人声明是强制角色的成员集中。这种意义上，强制角色约束可以产生超出它的谓词的影响。相反，惟一性约束是局部特性，只约束它的成员集，没有影响其他谓词。图5-4 经过强制约束的数据模型Fig.5-4 Mandatory constraint in ORM data model5.2.6 添加值约束、子集约束以及子类约束值约束指明值类型中允许那些值，有时称为“域约束”或者“对象类型约束”。只有值列表至少是相当稳定的，值约束才可以进行声明；否则，随着值列表的不断变化，约束需要不断改变，从而，模型也将随之改变。值类型可以通过把其外延声明为一个或多个枚举值或者括在大括号中的范围来定义，在一个模式图中，通过显示与值类型本身或值类型引用的实体类型相邻的范围来声明值约束。根据值类型来引入以下的三个子类是因为它们扮演了特殊的角色，否则没有必要引入。如图5-5，对象类型加了值约束L，C，H，E。还有另外一个约束要考虑。当且仅当有委托法人时，需要记录他们的有效期起日和迄日。有有效期起日记录的委托法人集合和有有效期迄日记录的委托法人集合是相同的。因此在图5-5中使用中间虚线的双箭头连接相关角色表示这种约束关系。为了表示两个或多个子类枚举它们的超类（即它们的并等于超类），使用强制符号“”通过点连线相关的子类表示。因此，在超类中的每一个实例，都会至少出现在一个子类中。在这个模型中，并没有强制的要求记录的人员是其中的一个子类，所以图中没有表示。图5-5 经过值、子集、子类约束的数据模型Fig.5-5 Value、Subset and Subtype constraint in ORM data model5.2.7 添加其他约束，并作最后检验在这一步中，可以增加其他的约束。例如：出现频率和环约束。还有一些图形约束，如：连接约束、相对闭包等。在这个模型中没有这种情况。在概念模式设计过程结尾，最后的检验确保了概念模式是内部一致的（它的约束模式组成没有矛盾），外部一致的（与原始数据和条件相匹配），无冗余的（基础事实不重复），且是完整的（满足所有需求）。各种导出冗余的实例可以被安全地处理。5.3 ORM模型的通用性在前一章中构建了一个公司里角色人员的ORM模型，本章主要讨论通过改变术语和添加企业所需的附加信息得到满足需求的模型，这就是模型通用性的体现。5.3.1 ORM模型术语的改变ORM数据模型表达出了重要的概念，但它们可能与组织的业务没有直接联系，通过对模型术语的改变可以表达各种视点并能够解决多个业务问题。如果能改变术语而尽量减少数据结构的更换，可以让企业节省分析源结构上所花的时间，从而建模者能够将精力集中到企业的特殊需求上来。假设一个正在为XXX公司定制公司当事人员的数据分析员，他发现模型中的大多数实体、关系和数据对象是适用于XXX公司的。在模型中很多的实体有多个别名，这些别名都可以成为定制后的ORM模型的实体名，那么他可以通过改变模型的术语，将XXX公司的业务名称应用到这个模型中。在改变术语时应注意处理这种语言上的不一致问题，因为人们常常发现一个类似的事物在企业的不同部门用不同的术语来表达或相反，类似的术语来表达不同的事物。所以在模型术语的改变时应与企业的业务人员达成一致，一起确定术语的优先级。在为模型更换别名是应注意对语言的理解，如果一个特殊术语过去有自己的含义，那么最好选一个新的、过去没有用过的词或术语来表达那个概念。例如，如果XXX公司中参与人表示与公司有往来的客户或可能成为的客户，那么使用它来代表公司里的角色人员是不明智的，所以应当为那个概念找一个替代术语而不是强迫那个词表达它以前没有表达过的含义。将XXX公司的业务术语应用到模型中（见表2）：人更换为公司员工，联系电话更换为电话号码等。对原ORM模型进行术语的变化后可以满足不同企业的需求，那么这个模型就具有通用性。图5-6是进行术语变化后的企业定制模型。表2公司ORM模型XXX公司别名公司XXX公司人公司员工经办人主管人员联系电话电话号码（包括传真、手机、呼机等）图5-6 定制的公司角色人员数据模型Fig.5-6 Customize Company member-role in data model5.3.2 企业所需的附加信息企业数据模型需要涵盖特定企业的信息需求。虽然许多的通用结构可以用来很快地建立一个模型，但是还是需要获取企业信息需求并加到模型中。通用数据模型可以作为企业数据模型的基础出现，然后根据特定企业的需求对其进行修改。例如，XXX公司也要构建一个公司角色人员的数据模型，他发现通用数据模型中的大多数实体、关系和数据对象是适用于XXX公司的，同时也发现了其他的需求。假设XXX公司需要知道人员进入公司的时间以及员工的收入，此外还需要知道公司业务人员的业绩以及有效的联络方式，那么可以在上一章用ORM建立的通用数据模型基础上添加这些需求。如图5-7所示，在模型上增加了聘用的时间和员工的收入两个实体对象以及与实体公司员工之间的角色关系。另外，在XXX公司的企业数据模型中，还需要在通用数据模型上加上一个子类来表示业务员，并表示这个子类所扮演的所有角色。图5-7 添加定制的公司角色人数据模型Fig.5-7 Add Customize Company member-role in data model对于模型而言，添加实体和关系比删除要容易些。因为数据模型是高度集成，删除和修改应考虑对其他部分的影响，所以并没有把企业的一些特定信息放在原始的模型中，而是作为特定企业的附加需求出现。因此应用ORM来构建适用于所有企业的通用数据模型或适用于各种具体行业和应用定制的通用数据模型时，应多考虑系统的通用性，避免加入过多的特定信息。5.4 本章小结ORM有完整的建模方法学支撑，本章就是讨论了用规范的建模流程来建立数据模型。建立的ORM模型不仅能表达业务规则，更因为它的通用性可以对已建立的ORM模型进行定制，对数据模型进行简单的修改或稍微复杂的修改，来满足企业的特定需求。第6章 通用数据模型的实施通过在前一章的介绍，知道ORM建立的模型具有通用性。本章将讨论这种通用数据模型是如何实施的。6.1 通用数据模型的实施方法实施通用数据模型的有效方法可以归纳为以下几条： 在开发企业数据模型的过程中，使用企业中常识性的业务术语来修改和增加通用数据模型的内容，并增添合适的信息需求。实际使用时，可能要对这些数据模型进行不同程度的修改。在修改或删除数据模型中的实体和关系时要更加小心。因为数据模型是高度集成的，所以这些数据模型中的许多实体和关系被用于多个图并有多种用途。在这种情况下，应该考虑和分析修改是如何影响模型的其他部分的。 根据具体应用的业务需求，为该应用建立适当的逻辑数据模型。首先理解业务过程，一旦对业务处理有了清晰的理解，就可以完成应用系统的逻辑数据模型了。逻辑数据模型需要解决在处理过程中的具体信息需求和业务问题。对于获取企业的整体需求和显示信息是如何在企业范围内集成的，企业数据模型的作用十分重要。在为某应用系统建立逻辑数据模型时，应该更详细地修订模型以满足该具体应用系统业务处理的数据需求。企业数据模型可以使读者从不同的角度观察企业，从而使最终的数据模型适应于企业的集成结构。有必要知道什么时候使用企业数据模型中的结构，什么时候为特殊应用提供特殊的定制6。 在逻辑数据模型和技术需求的基础上建立必要的物理数据库设计。任何一个数据库的设计都应该有一个牢固的逻辑数据模型作为基础。这是开发出的系统能够满足使用它的业务群体期望的关键一步。通用数据模型可以用于创建所需的逻辑数据模型。这些模型随后可以在一个物理数据库设计中实现。逻辑数据模型和物理数据库设计的主要区别在于后者可能对性能进行优化。物理数据库的设计者使用逻辑数据库设计作为数据库设计的起点，并根据性能和易于存取的需要对结构进行逆规范化物理数据库设计在考虑到所选用的数据库管理系统的数据库性能的同时，实现该逻辑数据模型的信息需求。根据数据不同的维护和存取方式，一个逻辑数据模型可以有多种物理实现方式。主要的有以下四种： 整个超类及其子类可以作为一个表实现，它有一个到速查表的的关系以指明该超类。在模型中的联系地址可以才用这种的实现方式。 每一个子类都各用一个表来实现，每个表包含有该超类的属性。模型中的大部分子类都用这种方式来实现。 超类及一个子类合并为一个表，其他子类各用一个表实现。 超类实现为一个表，其他子类也各自有自己的表。为完成物理数据库设计，设计者需要做成许多这样或那样的决定。由于企业的业务规则可能随时间发生变化，而数据库的设计应该使它能够处理许多这样的变化而不至于对数据库设计进行结构上的变动。 将数据库设计定制为适当的目标DBMS(数据库管理系统)。6.2 本章小结本章讨论了如何实施通用数据模型以支持不同类型的系统开发。每个通用数据模型都有多种实现方法。通过遵循清晰定义的设计原则，就可以使用通用数据模型建立物理设计。只要满足具体数据库的需求，就可以用这个设计生成可以装载数据和进行检验的物理数据库模式。目前，正在着手于这方面的工作。第7章 总结与ORM模型相比，ER模型和UML模型均不适于形式表示、转换或设计一个概念信息模型的任务。ER图和UML图与自然语言相差甚远，缺乏用于约束的基于角色符号的表达能力和简单性。在域的演化方面不稳定，难以和事实实例并存，并且常常隐藏附有模型的语义域的信息。对于概念信息分析，ORM比ER图及UML方法有一些优势。例如，ORM模型易于语言表示和成员化以便于领域专家的确认，应用域变化时，它们比较稳定，而且它们能够