ERwin方法论

ERwin Methods

2003年10月17日星期五

目 录

1

简介.................................................................................................................................................. 1 1.1 1.2 1.3 1.4 2

欢迎 ..................................................................................................................................... 1 适用于 ................................................................................................................................. 1 文档习惯 ............................................................................................................................. 1 如何使用本文 ..................................................................................................................... 2

信息系统、数据库和数据模型 ...................................................................................................... 2 2.1 2.2 2.3

关系数据库和ERWIN模型 ................................................................................................ 2 关系模型 ............................................................................................................................. 3 什么是信息建模型? ........................................................................................................... 5

3 语言概述 .......................................................................................................................................... 6 3.1 3.2

实体、属性和关系 ............................................................................................................. 6 关系和外键属性 ................................................................................................................. 9

4 命名、定义实体、属性 ................................................................................................................ 14 4.1 4.2 4.3 4.4 4.5 4.6 4.7

命名为什么重要? ............................................................................................................. 14 实体定义 ........................................................................................................................... 15 属性定义 ........................................................................................................................... 17 域 ....................................................................................................................................... 17 数据类型与角色名 ........................................................................................................... 18 定义与业务规则 ............................................................................................................... 20 同义词、同音异义字与别名 ........................................................................................... 20

5 一些模型细节 ................................................................................................................................ 20 5.1 5.2 5.3 5.4 5.5 5.5.1 5.5.2 5.5.3

更多实体与属性 ............................................................................................................... 20 关系类型与基数 ............................................................................................................... 26 多对多关系 ....................................................................................................................... 29 角色名与申明 ................................................................................................................... 33 存在与标识依赖 ............................................................................................................... 34

关系描述与插入、替换、删除 (IRD)规则 ....................................................... 34 删除规则 ............................................................................................................... 35 插入与替换规则 ................................................................................................... 36

6 标准化 ............................................................................................................................................ 36 6.1 6.2 6.2.2

介绍 ................................................................................................................................... 36 普遍问题 ........................................................................................................................... 36

相同属性的多个用途 ........................................................................................... 38

重复数据组 .................................................................................................................................... 37

相同事实的多个值 ........................................................................................................................ 40 6.2.4 6.2.5 6.2.6 6.3 6.4 6.5 7

相矛盾的事实 ....................................................................................................... 40 丢失信息 ............................................................................................................... 42 统一....................................................................................................................... 43

范式汇总 ........................................................................................................................... 44 ERWIN支持的规范化 ....................................................................................................... 45 需要多高的范式级别? ..................................................................................................... 46

信息模型方法学 ............................................................................................................................ 50 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.3 7.4 7.4.1 7.5

信息模型对象 ................................................................................................................... 50 ERWIN 支持的模型理论 .................................................................................................. 51

Area Information Models ...................................................................................... 52 The Key Based (KB) Model.................................................................................. 52 The Project Information Models ........................................................................... 53 The Fully-attributed (FA) Model ........................................................................... 53 The Transformation Model ................................................................................... 53

关系系统的DBMS模型 .................................................................................................. 54 信息建模对话 ................................................................................................................... 54

Session Roles ........................................................................................................ 54

小结 ................................................................................................................................... 55

1 简介

1.1 欢迎

欢迎使用ERwin信息模型，以前如果你从未见过模型，ERwin Methods Guide将帮助你了解什么是模型，以及它适合于什么。如果你已经有一些使用数据和信息模型的经验，那么你知道它在业务需求中是很有用的。如果在设计新的信息系统或在维护和修改存在的东西，模型能帮助你。本文没有包括信息模型的许多细节。但是，到你读完它的时候，你将足够地了解它，即使你仅仅初学者，ERwin的方法也将为你工作。本文覆盖了由 ERwin支持的信息模型方法，它不包括了ERwin的详细使用，如何使用 ERwin工具请见”ERwin User's Guide”。由 ERwin支持的信息模型方法是神秘的缩写字：”IDEF1X”，IDEF1X方法由 U.S.空军开发。目前，它应用于空军、政府机构、航空工业和财政部门、大公司、大型企业。并且，信息模型在各种主要的管理严格的大公司是必需的。

有关标题: 目的 目的

总体上, ERwin Methods Guide 有下列目的:

? 提供对ERwin支持的信息模型方法的基本层次理解，来做实际数据库设计； ? 介绍一些IDEF1X建模语言的能力和丰富的功能，为将来学习提供基础知识； ? 提供附加信息，让你更好地了解 ERwin的建模特点。

1.2 适用于

ERwin方法指南适用于：

数据库设计新手 ------ 信息建模入门书，使用ERwin方法的指南；

经验丰富的信息建模者 ------ 作为IDEF1X数据建模和 ERwin方法的指南； 经验丰富的IDEF1X用户 ------ 作为了解ERwin支持的IDEF1X特点的指南；

1.3 文档习惯

Bold italics 表示新的重要概念：

e.g., \attribute is a property of an entity.\

Non-bold italics bring words or phrases to the reader's attention:

e.g., \

1

ENTITY-NAMEs appear in CAPS:

e.g., “A CUSTOMER is described in the model as ...\

Plural ENTITYs are referred to by appending an 's' (ignoring spelling):

e.g., “A COMPANY operates in many CITYs\

“Attribute-names\

e.g., “A \” is recorded for each CUSTOMER.”

appear inside brackets:

e.g., “A CUSTOMER one or more MOVIE-RENTAL-AGREEMENTs.”

1.4 如何使用本文

如果你刚开始：

我们假定你对数据库有一些了解，因为它对你读下一节特别地重要。ERwin指南将提供你所需要的所有背景知识。不要犹豫，立即把ERwin应用到你的应用领域，你会发现 ERwin将帮助教你方法。

如果你有使用其它建模型语言的经验：

鼓励你复习所有的 ERwin Methods Guide，重点在第4, 5和6章。

如果你已经有使用IDEF1X经验：

你可能会找到一些注趣册背景资料，特别注意第5, 6和7章，虽然许多叙述是熟悉的，你将会找到一些新思想和有趣例子。

2 信息系统、数据库和数据模型

2.1 关系数据库和ERwin模型

为了竞争，许多企业正在了解使用信息系统的好处，信息系统通常提供企业服务 ------ 更好地管理和 readier访问信息资源。在某些情况下，信息系统不仅仅是服务，而且是用于提供战略界限(strategic edge)的产品，如在航空公司订座或金融服务行业。要认识到信息系统的好处，必须以及时和节约的方式来开发它，他们必须满足实际业务需要，并且必须是可修正的、可维护的、和最小费用的，实现这个目标是今天的主要挑战。

2

开发信息系统的理由之一仍然是那个挑战，正如经常注意到的，软件的进步尚未与硬件的发展进度并驾齐驱，软、硬件发展差距的原因部分地归结于在软件开发过程的各个阶段中缺乏推动生产力的标准方法和工具，简而言之, “皮匠的孩子没有鞋。”

然而，最近十年，在应用开发的方法和工具有了明显的进步，有了开发战略信息系统的有效工具和方法，因此，说 “皮匠的孩子没有鞋”就不真实了，而是有鞋了。但是时常看到那鞋太贵，不合适，或有些孩子简单地拒绝穿他们。

最近十年出现的最重要工具是数据库管理系统或DBMS ------ 提供可靠、方便的存储、恢复和更新数据的方法。假设在建一个使用DBMS的应用和根本不使用DBMS的应用之间作一个选择，只有少数人认为用DBMS建立的应用是不合适的。

随着 DBMS的发展，为模型化数据和设计数据库的新逻辑设计方法已出现，最重要的和广泛地使用的方法被称为 ------ 实体-关系模型或 “ER”模型。

在 ER模型中，所有数据被看成是说明关于实体和关系的事实，如：连接或实体间的关联。例如，航空公司订座信息系统有记录有关乘客订座信息数据库。如：在”FLIGHT <运送carries>许多PASSENGER”中，数据库描述关于FLIGHT实体，PASSENGER实体和关系”运送(carries)”。

2.2 关系模型

ER模型提供查看数据的高级”逻辑”，在 ER下模型，有数据三个主要的数据模型：关系模型，层次模型和网状模型。现代 DBMS通常建立于三模型中的一个之上，基于层次模型的DBMS，用嵌套的数据结构存储数据；基于网状模型的DBMS，层次模型不适于特殊环境，其数据被组织在网的节点和连接中；基于关系模型的DBMS，所有数据被存储在二维表格中。ER模型适用于所有三种模型，但最适用于关系模型。

TEAM Team-Name Year Team-City Mets 1989 NYC Yankees 1989 NYC Dodgers 1989 LA Red Sox 1989 Boston

Figure 2.1: TEAM table

表名和所有列名被说成是构成表格模式(schema)，这里是TEAM schema：

模式(schema) ------ 一组以数据定义语言来表达的语句集，该语句集完整地描述了数据库的结构。

TEAM ( team-name, year, team-city)

在关系模型中，所有数据值必须是原子的(不可再分) ------ 在一个单元中不允许存储分离的值。如果我们想存储有关1990 Mets的信息，不能简单地把1990加入到已存在的行，(Mets，1989 1990，NYC)。

相反，我们必须单独增加一行 (Mets, 1990, NYC)到数据库。

这个数据库的逻辑模型有２个实体，PLAYER、TEAM和关系”has”位于他们之间。读作”A TERM many PLAYERs”。

3

Figure 2.2: 数据库模型

相应于表的每个实体，下面是PLAYER表中一些行的数据例子： PLAYER Player-name player-number team-name year BA D. Gooden 16 Mets 1989 .186 O. Herchiser 55 Dodgers 1989 .075 D. Mattingly 23 Yankees 1989 .269

Figure 2.3: PLAYER table.

位于实体间的关系 “has”通过共享”team”和”year”的值体现出来。列 “team-name”和”year”是TERM实体的键 (如果我们假定一个队一年只能在一个城市)，要了解1989年Mets队有哪些球员？你必须查看PLAYER表的这些键，在3-7章中我们将了解更多的键和关系。

有关标题: 模型关系 数据模型例子

模型关系

所有三种数据模型以相似的形式表示有关实体的信息------例如：他们全都用记录表来存储详细的FLIGHT信息，不同的是关系的表示方法上。

层次和网状模型使用明确的物理指针结构来编码关系；关系模型用共享值来隐含地编码关系；ERwin使用的ER方法是使用共享键表示关系，这是关系系统的特点。

网状或层次DBMS根据物理指针结构的”导航”来访问关系信息；相对地，关系 DBMS需要使用连接在相关的表中找到匹配的值。通过隐含的存储关系，关系模型获得数据独立。关系DBMS允许物理数据存储结构的变化，而使应用代码的改变很小。日益增加的向关系DBMS迁移的主要原因是数据的独立性。

无论何时，两个实体间都有关系，一个实体中的因素引用或关联于另一个实体的因素。保持相关实体间的关系被称为参照完整性。由于关系被隐含地存储在关系模型中，需要额外的负担来保持参照完整性。今天大多数负担由程序员负责，然而，逐渐地关系DBMS提供对参照完整性的各种形式的自动支持，如触发器------依附于表的存储式过程，条件满足就触发。

无论你使用什么类型的DBMS，绘制数据库ERwin模型都是有用的。最明显的好处是数据库使用的系统文件的编制，应用开发人员用来定义系统，与最终用户的相互交流；第二个好处是提供清楚的参照完整性限制图片，在隐含的关系中，保持参照完整性在关系模型中尤其重要；第三个好处是提供一个”逻辑的” 、独立于数据库的DBMS图片，可用工具自动产生 DBMS-专用信息。因此，从属性层次图表中，ERwin产生 DB2表格模式，相同图

4

表也可用于产生其他 DBMS模式。

数据模型例子

Figure 2.4: Example of a video store data model.

2.3 什么是信息建模型?

信息模型是用来支持业务领域的数据结构和业务规则的规范，它表示一套业务信息需求。

信息建模是描述信息结构和捕获业务规则的过程，是信息系统设计的重要组成部分。对图2.4作如下说明：

? 仓库中的一部电影MOVIE有１个或多个电影拷贝MOVIE-COPY，记录信息包括

电影的名称、名字、等级、租用率。每个电影拷贝MOVI-COPY都产生它自己的记录。

? 消费者CUSTOMER租用电影-拷贝MOVIE-COPY。电影-租金-记录

MOVIE-RENTAL-RECORD记录消费者CUSTOMER租用的每个电影拷贝MOVIE-COPY。有时相同的电影-拷贝MOVIE-COPY也许租给多个消费者CUSTOMER。

? 每个电影-租金-记录MOVIE-RENTAL-RECORD也记录电影的期限日期，和一个

5

指示是否超期的状态，根据他的或她以前和商店关系，指定消费者CUSTOMER信用状态代码，它指示结帐方式：记帐、信用卡、现金。

? 当由牵连类型指定时，商店的雇员EMPLOYEE被包括在许多的电影-租金-记录中

MOVIE-RENTAL-RECORD，至少一职员包括在每个记录。由于同一天同一个职员EMPLOYEE也许多次包括在相同的租用记录中，将来通过时间邮戳来区分。 ? 消费者CUSTOMER的支付的租金被记录在电影-租金-记录

MOVIE-RENTAL-RECORD中，超期费用也记录在其中。超期通知OVERDUE-NOTICE用来提醒消费者返还磁带，有时职员被列在超期通知中OVERDUE-NOTICE。

? 商店保存雇员的工资和地址信息在雇员表EMPLOYEEs中，有时需要查看消费者、

雇员、电影名字，而不是他们的 “编号”。

这是个相对小的模型，但是它说明许多有关视频租用商店的信息。从它，我们不仅能获得业务数据库的思想，而且也到达对业务的一个好的形象描述。在这个框图中有一些不同类型的图形：实体、属性、关系和其它描述业务规则的符号。

在下列章节中，你将学到更多的不同类型的图形对象的含义，以及如何应用 ERwin创建你自己信息模型。

3 语言概述

3.1 实体、属性和关系

在这章，我们将介绍ERwin所使用的信息模型方法，以及它所提供的描述业务信息结构的强大功能的简要概述。

ERwin Motheds Guide中使用的例子是为清楚地展示而有意挑选的，如果你是信息模型的新手，你应该不被简单的例子所误导，认为 ERwin方法对你的业务应用起不了作用，实践证明该方法已经广泛地应用于从航空航天工业到银行业和财政的各个领域已近十年。

用ERwin做信息模型的主要好处之一是容易使用，它能产生一个概述信息模型工作的框图。

有关标题: 框图组件

实体和属性的基本用框图语法 候选键属性 关系定义 读模型

泛化结构(Generalization Hierarchies)和继承

框图组件

ERwin框图主要由三种主要构建块组成------实体、属性和关系，如果我们把框图看成是表达业务语句的图形语言，那么实体是名词，属性是形容词或修饰，关系是动词。用ERwin

6

构建信息模型是一件简单的事情------找出正确的名词、动词、形容词集，并把放在一起。本章我们将介绍实体和关系的基本概念，4,5,6章提供ERwin方法的高级特性的细节。

有关标题:

“实体”的定义

实体和属性的基本用框图语法

在 ERwin框图中，消费者CUSTOMER实体由一个带有名字的方框来表示，实体的所有属性在框内。实体名将总是单一的------是CUSTOMER不是CUSTOMERs，是MOVIE不是MOVIEs，是COUNTRY不是COUNTRYs。总是用单数名词，你将获得一致命名标准的好处，有助于把实体实例作为一套说明语句来 “读”框图。

Figure 3.2: Example entity.

实体框图中的水平线把属性分为两套：键和非键。线上叫做键区，线下叫做数据区。CUSTOMER的键属性是”customer-number”，非键属性是”customer-name”、”customer-address”。

标识实体的属性集称着实体的键。键属性本身是一个属性，或者独自，或者与其它键属性结合，将形成对实体的唯一标识符。主键被放置在线上方的键区域，非键属性是不能作为键的属性，它们被放置在数据区。

为了在信息模型和稍后的数据库中正确地使用消费者CUSTOMER实体，我们必须能唯一的别实例。

如何区别一个消费者?一方法是用用户姓名作为键，另一个方法是给每个消费者指定唯一编号，如图3.2。

格言

无论谁要在模型中加入一个实体，最重要的问题之一是你需要问： “我们怎样标识实例?”

这儿有句格言帮助你记得这: “No entity without identity! “

ERwin模型中的实体实例总是由键属性标识。

候选键属性

选择实体的键是重要的一步，并且需要认真地考虑，也许有几个属性，或属性组作为主键。那些被选择出来作为主键的属性、或属性组叫候选键属性，候选键必须唯一地标识实体的每一个实例，不允为NULL，如”空empty”或 “忽略missing”。通常，主键的选择需要一定的判断力，而且必须仔细选择，不能仅凭想像，例如：如果政府以姓名来标识每个纳税人，并且你碰巧是约翰史密斯，你可能花一生时间来核对到底是谁纳的税。

有关标题: 例子键选择

7

选择主关键字 替代键属性 关系定义

关系表示实体间的连接(connection)、链接(link)或关联，他们是框图的 “动词”，用来显示实体间的相互联系，这里是一些例子：

A TEAM many PLAYERs.

A PLANE-FLIGHT many PASSENGERs.

A DOUBLES-TENNIS-MATCH exactly 4 PLAYERs. A HOUSE one or more OWNERs. A COMPUTER many DISK-DRIVEs. A SALESPERSON many PRODUCTs. 所有这些，都是 1---对---多的关系，意思是第一个实体的一个实例与第二个实体的多个实例关联或连接，在 “1-端”的实体叫父实体，在 “多端”或圆点端的实体称为子实体。

有关标题:

多少是 “多”?

关系的基本框图语法

读模型

如果选择正确的动词短语，就可以使用动词短语从父实体到子实体来读关系。前一图表将被读作为：

A PLANE-FLIGHT many PASSENGERs 下一个框图被读作：

A CUSTOMER many MOVIE-RENTAL-RECORDs

Figure 3.7.

A MOVIE many MOVIE-COPYs.

Figure 3.8.

A PERSON many HOBBYs.

Figure 3.9.

下一个例子包括关联的实体，他们更难于”读”，因此，在第5.2章 (图5.14.)我们将回到这个例子。

A PERSON many ADDRESS-USAGEs.

8

An ADDRESS is many ADDRESS-USAGEs.

Figure 3.10. Associative entity example.

动词短语也可以从子实体读起，如”被动动词”短语表达，例如：

Figure 3.7: A MOVIE-RENTAL-AGREEMENT a CUSTOMER. Figure 3.8: A MOVIE-COPY a MOVIE. Figure 3.9: A HOBBY a PERSON. 信息模型揭示了许多由模型描述的业务规则，动词短语提供了关系包含的业务规则的简要概述，虽然他们不能精确地描述规则，他们让看模型的人获得实体是如何被连接的初步了解。保证读模型给出有效的语句是一个好的实践，把模型读回到业务，是验证所获取的业务规则正确性的主要方法之一。

泛化结构(Generalization Hierarchies)和继承

泛化或继承层次也叫做子类，或子范畴层次，是实体集分组的一种方法，这些被分组的实体共享公共特性。例如，在建模型工作中，我们也许发现，在一个银行中有几个不同类型的帐户ACCOUNTs存在，如：支票、存款和贷款帐户ACCOUNT，叫做ACCOUNT的泛化实体（或类实体）被形成来表示这三类帐户的共用信息，如图3.11所示。

有不同的术语来表示泛化层次的实体，IDEF1X使用概念范畴category来引用”子类型”，其它人为这些子实体使用概念子范畴(subcategory)。在本文中，我们按照IDEF1X来 “分类”。

有关标题: 分类甄别器

3.2 关系和外键属性

在前一章关系模型 (2.2)，关系模型、层次模型和网状模型的主要区别是关系的表示，层次和网状模型是在物理层上用指针型数据结构来表示关系；相对地，相关模型在逻辑层上用共享键来获取关系。

ERwin使用的 IDEF1X模型语言也用共享键表示关系，虽然 IDEF1X确定地用于被存

9

储在非关系型数据库管理系统的模型信息，但IDEF1X对键的处理是关系的。

无论何时，在 ERwin框图中的实体通过关系来连接，关系贡献键给子实体，外键属性定义为父实体的主关键字属性，通过关系贡献给子实体，贡献的键称为父实体到子实体的迁移，在模型中外键属性通过属性名后的(FK)来表示，如图3.12所示。

有关标题:

标识和非标识关系 独立实体 依赖实体 角色名

标识和非标识关系

在标识关系中，外键迁移到键区(线上)。

Figure 3.12: Identifying relationship. 关系被称为标识，是因为父实体的键成了子实体标识的一部分，即子实体的标识依赖于父实体。标识关系用连接两个实体间的带点实线来表示，到目前为止，我们见到的所有关系都是标识关系。

Figure 3.13: Identifying relationship.

在这个例子中，PLAYERs由”team name”和”player name”两个来标识，这必须的，因为有时，同一个球员可以参加不同球队，并且有时，业务 (比如说管理的棒球统计)需要区分球队成员。

标识关系运用其业务规则，即通过父实体的标识符来标识子实体。在3.8中电影和电影-拷贝例子中，通过它拥有的唯一编号来标识拷贝，相反，我们决定用电影的标识符和增加第二部分(拷贝-编号)来区分每一个拷贝。

非标识关系 (虚线)也连接父实体和子实体，由非标识关系迁移的非空外键子集被置于数据区（线下）。

10

Figure 3.14: Non-identifying relationship.

既然在非标识关系中一些 (或所有)迁移的键不是子实体主关键字的一部分，那么子就不能由父来标识。正如我们将在第5和 6章所要了解的，当我们在插入、删除和更新操作下需要保持的父子关系完整性时，这个差别非常重要。这被称作参照完整性问题。

在乘客-座位例子中，航空公司已挑选”seat number”来标识座位-预留的实例。

Figure 3.15: PASSENGER-SEAT example.

由于相同座位占有者在每一次飞行中是变化的，目前乘客PASSENGERi不是键的一部分。然而，这个模型仍然不恰当，只用 “seat number”不能充分地标识当前乘客所预订的座位。在下面的模型中，我们扩展了座位-保留SEAT-RESERVATION的键，增加了”flight-number”来申明FLIGHT和SEAT-RESERVATION关系。（更多的非标识关系见第５章）

Figure 3.16: SEAT-RESERVATION example.

独立实体

实体被指定作为独立实体，或依赖实体，取决于其键的获得方式。

11

Figure 3.17: Independent entity and dependent entity. 独立实体由方角盒来指定，独立实体不依赖于模型中任何其它实体来标识。在先前例子中 (图2.4和 3.7)，每个消费者由唯一的 “消费者-编号”来标识；另一方面，我们的出租店有许多电影拷贝，在此有两个选择------或者使用它本身的唯一”电影-拷贝-编号”来标识每个电影拷贝(使它成为一个独立实体)，或组合 “电影-编号”和”拷贝-编号”来标识每个拷贝。由于 “电影-编号”是电影的标识符，那么称对电影-拷贝MOVIE-COPY的标识依赖电影MOVIE。

依赖实体

依赖实体被指定为圆角盒，依赖实体依存于模型中的其它实体。

通常，关系引起父子实体间的依赖。在存在依赖中子实体的存在依赖于父实体的存在。在标识依赖中，不使用父实体的键就无法标识依赖实体。标识关系总是导致存在依赖和标识依赖。

举例说明标识依赖，没有标识电影（独立实体）的 “电影-编号”，电影-拷贝就不能被标识，没有”球队名”就不能标识球员。

Figure 3.18: Movie example.

Figure 3.19: Team example repeated from above.

没有电影就没有电影-拷贝，没有球员所属的球队就没有球员，非标识关系不引起任何标识依赖 (迁移键到数据区)，然而，如第５章所示，他们中许多导致存在依赖。

角色名(Rolename)

rolename是外键属性的新名字，角色名定义一个新属性，它用来描述由关系体现的业务陈述。

这儿有一个简单例子：

12

Figure 3.20: Rolename example.

球员PLAYER的键属性 “player-team-id.team-id”给我们演示定义和显示角色名的语法，第一半 (点号之前)是角色名，第二半是外来键的原始名称，有时称基本名称。

role-name.base-name

就象任何其他属性一样，角色名通过关系迁移。如下例所示，演示了在各种比赛中各个球员的得分情况。

Figure 3.21: Diagram with rolenames migrated.

这里，我们为SCORING-PLAY的主键创建一个新角色，如图3.22所示。

角色的”链”沿着所有路径从SCORING-PLAY回朔到TEAM。然而，注意只有一个链的”链接”被显示。

13

Figure 3.22: Diagram with new rolenames.

4 命名、定义实体、属性

4.1 命名为什么重要?

命名为什么重要？因为它包含中几乎所有的实体和属性。

在信息做模型中非常地重要，通常在系统开发中，为对象选择清楚和容易辨认的名字，命名和定义实体、属性如此重要，以臻于我将用这一章来讨论。

有关标题: 单数名称 清楚的名称

单数名称

Entity names are always singular. We have made a point to do this throughout all the examples. Doing so facilitates reading the model with declarative statements such as “A FLIGHT zero or more PASSENGERs” and “A PASSENGER one FLIGHT.” When we name the set of instances represented by the entity we are giving a name to an instance. Each instance of the PASSENGER entity is an individual passenger, not a set of “passengers.”

Attribute names are singular too, e.g., “person-name,” “employee-SSN,” “employee-bonus-amount.” The reason for naming attributes in the singular is partly a matter of a consistent naming policy and partly to avoid certain kinds of normalization errors. You might have an intuitive sense that something was amiss if you saw an attribute name like “person-hobbies.” How many? How do we tell one from another? How would we represent them in a sample instance table? And so on. Your intuition would be correct ?there is something wrong. We will

14

return to this in our discussion of normalization in a later chapter.

清楚的名称

清楚地表达实体和属性的名称是非常重要的，例如，人 、消费者、职员，虽然它们都表示一些个体，但其意义是有差别的，他们有不同的特性。

小心地挑选名称，不要把两个不同的东西叫做相同的名字。

为了符合业务习惯，使用不清楚的名称，应给这个名称一个新的别名。 有时发现不首先给出它的定义是难于给实体和属性取一个好名称的，通常，给实体和属性一个好的定义与取一个好名称一样重要。一个意味深长的名称来自对模型的理解和经验。

在图3.10中，我们给人和地址的联合或交叉点命名为地址-使用，我们是如何选择这个名字呢?

Figure 3.10: From previous chapter.

大多数人也许喜欢把这个实体命名为”个人-地址”，问题是这个实体即不表示个人也不表示地址，它让我们误以为这个实体是一些个人或地址的分类。

这个实体真正代表的是个人地址的使用，我们要保存的信息是”使用”，地址-使用表达大多数信息，但它有一点不足，个人-地址-使用将已告诉我们更多的信息。

记住信息模型是对业务规则的描述，无论何时都要尽可能地选择一个意味深长的业务名称，然而可能没有这样的业务名称 (业务也许不喜欢 “个人地址使用”)?

这种情况，最好直接给出适合实体目的的名称。

4.2 实体定义

所有实体都应当定义，虽然 ERwin并不强迫使用这个定义(作没有伴随定义的框图是件快意的事)，写一个好的定义似乎比作框图更困难。每个人都知道什么是人，对吧?给人写一个定义，便于以后检查。

在实际中，你会发现采用结构化的长定义有助于读者了解被定义的东西，某些这样的定义达几页纸 (如：人)。你可能想采用下列 “标准”作为定义结构的起点，即使 IDEF1X不为定义提供标准。

15

有关标题: 描述 业务例子

描述

描述应当清楚、简明，告诉我们是否是我们要定义的东西，通常，这样的描述相当地短，然而注意，描述不能太概括或使用没有定义的概念，这里是一对例子，一个质量好的，一个可疑的。

“商品是东西哪一个有值哪一个能被决定在交换.” 这不是太可惜了.

我们可以惊讶于什么 “交换”是,并且我们可以需要了解一点儿更多什么 “值”是,但是我们能通常知道那东西是商品如果某人是,或将是,自愿的经营东西为它.

如果某人愿意给我们三花生和根使为有粘性大理石,然后我们知道那大理石是商品. 并且如此是花生和根有粘性.

“消费者是某人谁买东西从我们的公司.” 这太好.

第一,能 “某人”是另一个公司?

第二,消费者不得不有已经已买东西从我们到被考虑一? 怎么样 “潜力”为销售以后,即使有毫不现在? 等等.

业务例子

对要定义的东西提供典型的企业例子是一个好主意，但要避免用例子来定义，虽然有点“不专业”，但好例子能够帮助读者理解定义，如注释花生，大理石有助于读者理解商品COMMODITY的概念，定义说商品是有“价值”的东西，例子可以帮助读者理解，价值并不总是“钱”。

通常应当给定义加入注释，如，它的状态，何时做的修改，来源等，它作为定义的一部分是非常有用的记录。注释解释了被定义实体类似的东西，而不是其中的每一个实例，例如：消费者CUSTOMER和可能的主顾PROSPECT是有区别的，初看时它们好象是相同的东西，但他们的确不同。

如图3.10所示，对联合实体下定义是有点困难的，定义为ADDRESS-USAGE。联合实体记录的是“交叉点”数据------是被“联合”的一对键，可象下面一样尝试。

\“人使用的地址”

No. The only problem is, this is not an ADDRESS! How about: 问题是这不是地址，咱办？

\人使用的地址信息

Closer, but still not correct. Information about an ADDRESS is recorded as attributes of ADDRESS. How about:

接近了，但仍然不正确，地址信息是ADDRESS的属性，咱办？

16

\“人所用地址用途的信息”

Yes. Remember that associative entities often represent many-to-many relationships which have been broken down into a pair of one-to-many relationships with the associative entity in the middle.

正确，联合实体经常用于表示多对多的关系，多对多关系被拆分成中间带有联合实体的两个一对多关系。

4.3 属性定义

和实体一样，清楚地定义所有属性是很重要的，应用相同的规则------比较要定义的东西，我们能够判断它是否合适，

As with entities, it is important to define all attributes clearly. The same rules apply?------by comparing a thing to a definition, we should be able to tell if it fits. Again, this is more difficult than it may first sound.

例如：什么是\的最好定义？我们总是认为“这是每个人都知识的”，但人名与绰号仍然是有区别的，什么是名字？

Is it a title by which the PERSON is commonly addressed? Or what is listed on a birth certificate? Or with the government for tax and other purposes? Or what? Or are all of these \

是找人的标题？，是列在出生证上的？，给政府纳税和别的目的？，还是别的什么？或是所有这些“用途”？

Beware of things like \was opened.\

Attribute definitions generally should have the same basic structure as entity definitions (i.e., description, examples, comments, etc.). Description and comments certainly apply. Business examples are useful sometimes. Business examples lead us to the world of domains. 通常，属性的定义应当与实体定义的基本结构一样（如：描述，例子，注释等），描述和注释肯定要用，有时业务实例也是有用的，业务实例把我们带入域的世界。

4.4 域

域可以被看作是允许属性接受的一组值，这些值有抽象和企业意义，例如：\如果定义为“the preferred form of address chosen by the PERSON”，那么域就是所有字符串的集合，人们也可用短语、编号、描述或其它这样的东西、也可用传统的“名字”如Ben或Tom来称呼自己。

在IDEF1X的正式描述中，通常关系模型中，据说属性定义在域之上，属性的定义如代码，标识符，数量等，但这通常不用于业务例子。包含属性域的描述通常都是好主意，定义域时也应列出属性可以采用的“值”，假设我们定义属性\如下：

Customer-status：描述消费者与商行间关系的代码 下列域的说明没有多在帮助。

17

Domain: A, P, F, N

应当更好： Domain A: Active

Meaning

The CUSTOMER is currently involved in a purchasing relationship with our company.

Someone with which we are interested in P: Prospect

cultivating a relationship, but with whom we have no current purchasing relationship.

The CUSTOMER relationship has lapsed F: Former

---i.e., there has been no sale in the past 24 months.

The company has decided (for reasons we N: Never (do business with this guy)

might go on to describe) that no business will be done with this CUSTOMER.

属性域已经定义，这些定义是属性定义的重要组成部分。

4.5 数据类型与角色名

经常是模型中的几个属性通过相同的域来定义，换句话说，他们将有相同允许值，而不是相同定义。

通常通过关系把外键贡献给实体，IDEF1X提供角色名来允许相同属性的不同出现，来扮演不同角色（见第3章）。

考虑图4.1中的例子，我们看到FOREIGN-EXCHANGE-TRADE同CURRENCY间有两个关系。

Figure 4.1: Currency Example.

CURRENCY的键是\(我们感兴趣的有效货币标识符)，从关系中可以看到\和\。

我们看到CURRENCY的标识符(the \用于识别两种货币中的一种，其中一个表示买叫\，另一个表示卖叫\，这些是角色名名，我们把\和\看作是\的数据类型，但它们与\是不同的。

同一时间，同一汇率下交易同一种货币是愚蠢的，因此，在每一次交易中 (FOREIGN-EXCHANGE-TRADE的实例) \和\必须

18

是不同的通过给不同定义两个角色名，可以获是两个不同的货币代码。

Attribute/Rolename Attribute Definition

The unique identifier of a CURRENCY. currency-code

The identifier (\of the bought-currency-code

CURRENCY bought by (purchased by) the FOREIGN-EXCHANGE-TRADE.

The identifier (\of the sold-＊currency-code

CURRENCY sold by the FOREIGN-EXCHANGE-TRADE.

买、卖代码的定义和域是基于\的， \叫基本属性base attribute。

循环定义，如果你打开字典，如Webster's韦氏字典，时常会发现这样的情况：

TERM-1 Definition includes reference to, or is based on TERM-2. TERM-2 Definition includes reference to, or is based on TERM-3. TERM-3 Definition includes reference to, or is based on TERM-1.

如果不仔细些，实体和属性的定义也可能发生这样的情况，例如：

CUSTOMER: Someone who buys one or more of our PRODUCTs. PRODUCT: Something we offer for sale to CUSTOMERs.

上面这种情况，只要小心是可以避免的。 在定义实体和属性时，都应加注释，例如：

“A CURRENCY-SWAP is a complex agreement between two PARTYs in which they agree to exchange cash flows in two different CURRENCYs over a period of time. Exchanges can be fixed over the term of the swap, or may float. Swaps are often used to hedge currency and interest rate risks.”

上例中黑斜体标注的概念是没必要，因为，只要需要就可以查到。

要是习惯使用非实体名和属性名的概念(如，通用企业概念)，应提供它们的基本定义， 可使用从模型中分离出来的使用概念的术语表，如上面黑斜体表示的通用企业概念。

If it will be convenient to use terms which are not the names of entities or attributes, (e.g., common business terms), it is a good idea to provide base definitions of them, and refer to these definitions as would be done for references to entity or attribute definitions. A glossary of commonly used terms, separate from the model, can be used. Such common business terms are highlighted with bold-italics, as in the above passage.

It may seem that a strategy like this will lead to a lot of flipping back and forth among definitions, and it will. The alternative, however, is to completely define each term every time it is used. If these \definitions\appear in many places, they will have to be maintained in many places, and the probability that a change will be applied to all of them at the same time will be very small.

开发一个通用企业概念术语表可服务于几个目的，它是模型定义的“基础”，可帮助人们交流和理解模型。

19

4.6 定义与业务规则

业务规则是完整信息模型的一部分，许多业务规则可以从实体、属性、域的定义中找到。 图4.1中的CURRENCY实体，可被定义为“所有公认流通的有效货币”，也可定义为“公司日常业务中使用的货币”，这两个定义是不同的。

后一种情况，是一个关于“政策纲领policy statement”的业务规则。 这个规则体现在\的域中，它把\限制在可用货币的子集中，这个业务规则的维护变成了对CURRENCY 表的维护，要允许或禁止交易的货币，建立或删除实例即可。

\和 \属性的域也受到类似的限制，它依赖其它属性实际使用的值。重要的是理解这儿涉及到的基本原理，域需要在属性的定义中找到（因为在IDEF1X标准处理中没有直接给出）。

4.7 同义词、同音异义字与别名

不是每一个人都说同一种语言，在名字的使用中并不总是准确的。

同义司 synonym 是已有名字的对象的另一个名字 同名异物homonym 两个不同的对象有相同的名字。 别名alias 对象的同义词，通常是业务领域中通用的。 由于在信息模型中实体和属性用它们的名字来标识，我们需要一套解决同义词和同名异物词的方法体系。

在逻辑层次上，模型中的每个数据对象（实体或属性）都必须指定一个唯一的名字。

5 一些模型细节

5.1 更多实体与属性

在第３、第４章中，我们引入了ERwin语言，并提供了简要介绍。本章我们对第３、第４章作一个简要概述。

? 实体是信息模型的基本建筑块，他们有称着属性和通过关系连接的特性；实例是实

体的单个具体取值；键属性标识实体，如果需要，实体能够被收集进入概括分层结构。

? 属性有域，域描述了允许属性使用的值或值的范围。 ? 关系连接两个实体，并且有叫做基数的特性，基数表示两个实体中的每一个有 “多

少”被涉及 (如：一个实体Ａ与一个或多个实体Ｂ关联，且实体Ｂ精确地关联一个实体Ａ)，关系从父实体贡献外键到子实体；外键可能有角色名。 有关标题: 实体类型

概括分层结构与继承

20

完全与不完全分类结构 何时形成概括分层结构 更多属性 转置实体属性 导出属性

实体类型

第３章介绍了独立与依赖实体，这里再次定义他们：

独立实体：它的标识不依赖于模型中任何其他实体的实体。

依赖实体：它的存在和对它的标识都依赖于模型中其它实体的实体。

有几种类型的依赖实体，用ERwin来建立信息模型，你并不真正地需要知道差别的细节，除了对它们的好奇外，这里是一些定义：

实体类型 描述 特征实体： 特征实体表示一组属性，它们在一个实体中多次重复，并且不能由其它实

体直接标识。例如：假若一个人有许多嗜好，嗜好就被说成是人的特征。见图3.8，这儿再举一例。

Figure 5.1: Example of characteristic entity. 联合实体： 联合实体记录两个以上实体间的关系。例如，一个人有多个地址，一个地

址可被多个人共用，需要地址-使用实体来人和地址间的关系。在这个例子中，地址-使用是联合实体，联合实体携带有关关系信息，本章后面我将看到更熟悉的例子。

Figure 5.2: Example with associative entity.

指示器实体： 指示器实体除了没有自己的属性外，与联合实体相似。在前面例子中，如

果除了保存人和地址的标识信息外，不保存别的信息，那么地址-使用就是一个指示器实体(从人的方面看，它 “指定”地址；从地址方面看，它 “指定”人)。

分类实体： 在第三章中我们介绍了分类实体，这些是子类关系下的依赖实体。分类实

体是在子类关系中，超类的子类。紧接着，我们将更详细地包括概括分层结构。

概括分层结构与继承

在第３章(图3.11)中，我们提供了下列概括层次结构的例子。

21

Figure 5.3: Example of generalization hierarchy.

让我们看看创建过程，推测模型模型的开发，我们已找到下列三个实体：

Figure 5.4: Example accounts.

当我们在开发不同类型三个帐户的模型时，也许已认识了图5.4中的一些类似的东西，我们要做的是，把这三种类型的帐户中的共有属性收集在一起，放入层次结构中。

这些公共属性将移动到叫做类属父（generic parent）的更高层次的实体中，那些专有属性仍然留在类实体（category entity）中。

假定我们还没有为这三类帐户选择物理系统键，这里，我们工作在逻辑，或概念层上。 首先，我们将形成类属父、帐户ACCOUNT和键”account-number”，为了区分ACCOUNT的类型，增加一个属性”account-type”作为类甄别器，它的值将告诉我们ACCOUNT所属的类，然后我们增加三个类，CHECKING-ACCOUNT，SAVINGS-ACCOUNT，和 LOAN-ACCOUNT。

其次，我们比较三分类的属性，每一个都有”open-date”，如果三种类型的”open-date”是相同的（我们假设它们是相同的），我们就把它们移到类属父，同时从类中删除它们。以同样分析方法来移动”account-review-date”(帐户-复核-日期)。

三类中都有结算，CHECKING-ACCOUNT中有两个 (“核对”和”有效”)，SAVINGS-ACCOUNT 有一个，LOAN-ACCOUNT有两个，我们应当把它们移到类属父中吗？

再次，回答取决于它们的定义，”checking-balance,” “savings-balance,” 和 “current-loan-balance”含义是乎是相同的，但仔细分析后会发现，”checking-balance,” “savings-balance,”是相同的，而”current-loan-balance”却差别很大。

几乎所有属性是相同的，而只有少数不同，在这种情况下有两个选择：要么把这些属性留在类中；要么移动相同的属性，留下不同的属性。

这将意味着，没有移动的类的类属父中该属性值是NULL，非-键属性允许为NULL。

22

在高层次的模型中，如何决策取决于有多少类共享公共属性，如果全都共享，移动它们，如果只有少数类共享，最好是不移动；在低层次的模型中，取决于目的，经常是不移动。

例如，在图5.5中，余额仍然留在类中，根据定义我们把其余的属性留在类中。

Figure 5.5: Completed account example.

完全与不完全分类结构

用不同的符号来标记类属父的类集合是否是完全的，图5.6表示不完全结构(也许还有没发现的其它类)。这里我们看到，EMPLOYEE 职员或者是顾问CONSULTANT或者是专职职员FULL-TIME-EMPLOYEE，类符号底部的单线表示也许还有其它没有包括的类。

Figure 5.6: Incomplete category structure.

图5.7表示一个完全结构，在这里职员EMPLOYEE要么是男职员MALE-EMPLOYEE，

23

要么是女职员FEMALE-EMPLOYEE。

Figure 5.7: Complete category structure.

图5.8显示完全与不完全类的结合，职员EMPLOYEE是FULL-TIME-EMPLOYEE 专职职员或顾问CONSULTANT。同时，也是男职员MALE-EMPLOYEE 或女职员FEMALE-EMPLOYEE。

Figure 5.8: Example with a combination of complete & incomplete structures.

图5.9继续扩展这个结构，在专职职员FULL-TIME-EMPLOYEE下增加类BENEFIT-ACCOUNT。

24

Figure 5.9: Example with many combinations of complete & incomplete structures.

何时形成概括分层结构

小结，形成概括分层结构有如下三个理由：

? 实体共享公共属性集，上面的例子就是这种情况。 ? 实体共享公共关系集，我们尚未探索这种，但是，当需要时，将引用于帐户结构中，

收集类实体已有的共有关系，把它们放入单个关系中。例如：如果我们发现每类帐户的结构都与许多消费者CUSTOMER关联，那么我就在帐户ACCOUNT级建立单个关系(到多个CUSTOMER)，从单个类中消除独立的关系。

? 如果业务需要，在模型中应展示实体的类（通常是为了交流或理解的目的），即使

类没有不同的属性、参加在不能区分其它类的关系中。记住模型的主要目的之一是有助于信息结构的交流，然而，小心不要做得过火，在详细的类结构网页中，全面公开模型意义。

更多属性

假定我们想在上述例子中增加消费者的名字，除了帐户编号之外，还想通过消费者的名字来查寻帐户，就要建立如下模型：

25

Figure 5.10: Entity with an inversion entry. 注意”customer-name”属性后面的(IE1)。

转置实体属性

转置入口表示访问数据的附加方法，是一个或一组用于访问数据的普通属性，但不能精确查找一个实例。如，上面的”customer-name”就是这样一个属性，通过”customer-name”可以得到０，１或多个帐户ACCOUNT（注意：也许有一个以上的约翰史密）。

有关标题: 倒转入口符号

导出属性

导出属性是来自其它属性的计算机项(如，合计)，并且不需要保存。如第６章将见到的，在模型中记录的导出属性是规范化错误，规范化的目标是保证只有一种方法来了解数据库中记录的每个事实。如果我们知道导出属性的值，也知道导出算法以及用于该算法的属性值，那么就有知道事实的两种方法（查找导出属性的值，或计算）。如果我们用两不同方法来获得答案，就有可能两个答案不同。

例如，假如我们记录了职员的”出生-日期birth-date ”和”年龄age”，并假设”年龄age”属性只能在当月末的维护工作改变。然后，当我们问, “某某职员多大?”的问题时，我们可以直接访问 “年龄”来获得答案，或我们可用 “今天的-日期”减”出生-日期”得出答案，如果我们用减法，那么将总是获得正确答案，如果 “年龄”最近尚未更新，它就会给我们一个错误答案，并且将总是存在着潜在的相矛盾答案。

在模型中记录导出数据有意义的情形是，计算数据的代价是昂贵的。虽然建模理论说绝不要包含导出数据 (我们主张你保守地这样做)，但当你必须打破规则时，至少记录导出属性的事实，同时陈述导出算法。

5.2 关系类型与基数

关系携带大量的信息，一些可以说是信息模型的心脏，在很大程度上，他们描述业务规则和参照完整性限制。

有关标题: 基数

关系类型细节：一对多，标识 一对多，非标识 递归关系

基数

26

关系有一个叫做基数的特性，定义了每个参与实体可以或必须有多少参加。基数语句表示父实体中有”多少”实例与子实体的”多少”实例连接。

图形中，在关系符号的点附近显示基数。

Figure 5.11: Cardinality notation.

在键-基本和完全-属性模型中，所有关系都是 “(零或)一”，任何多对多关系必须分成两个一对多关系。这些模型在第7章讨论。

关系类型细节：一对多，标识

在第２、３章中，我们见过许多标识关系，现看图3.8，电影 /电影-拷贝例子。图5.12重复的这个图，稍微有些不同。

Figure 5.12: One-to-many identifying relationship.

在这例子中，电影-拷贝不能被标识，除非电影的标识被知道( “电影-编号”)，由ERwin支持关系模型基本原则之一是：如果实体的实例不能被标识，那么实例就不存在。电影-拷贝是存在依赖电影。

基数所陈述意思是，关系上不带点的一端是确定的一部电影，电影-拷贝端(带点端)怎么样?

在我们的视频商店中，我们把电影-拷贝定义为原带的几个复制品中的一个，业务规则说电影必须有一非零(一个以上)的复制份数，简而言之，”available as”是一对一或多的关系。点附近的”P”符号说明了这个关系，在这个数据库中，电影没有拷贝不是合法的业务对象。

然而，假如我们要为不同的视频商店构造模型，且该商店对跟踪有不同政策，他们关心世界上的所有电影，甚至那些他们没有拷贝的电影。如此，他们的业务规则是对存在的电影（记录在信息系统中）不一定需要拷贝。

要记录这个业务规则, “P”被删除，变成一对零或多的关系。

(如你所了解的，通过标识关系贡献键给子实体对更直接的物理系统查寻是有利的，但还有许多不利之处，一些高级关系理论建议键的贡献不要以这种方式发生，相反，每个实体不仅仅由它拥有的主关键字来标识，而且系统的用户绝不会见到逻辑编号或代理键，该理论请见E. F. Codd and C. J. Date的评论)。

一对多，非标识

27

非标识关系贡献父实体的键给子实体，但是，由定义知，一些 (或所有)键不变成子实体的键，意思是子不标识依赖于父，允许这样的情形，关系中”多”端的实体没有”父”而可能存在，即它不是存在依赖。

从子实体看，如果关系是强制mandatory的，那么子存在依赖于父。如果可选，那么子既不存在也不标识依赖于关系 (虽然它也许依赖于其他关系)。ERwin用菱形为表示可选的情况，菱形只存在于非标识关系中(因为标识关系贡献主关键字，而主关键字部分不能为NULL)。带菱形的非标识关系是”零或一对多”的关系。这儿有个简单例子。

图5.13，属性 “passenger-id”变成SEAT座位的外键属性，它不标识座位，它标识占用座位的乘客，因为没有乘客座位仍然存在，关系是可选的，应使用菱形符号。

Figure 5.13: One-to-many, non identifying relationship. 我们已经定义，在一次飞行中乘客可占零或一个座位。

座位可以空 (不被任何乘客占有)，当座位空时，”passenger-id”属性将是空 (NULL)。 由业务政策知道，这是允许发生的 (因为航空公司不能迫使乘客填满每次飞行的每个座位)，从子实体看，关系是可选的，关系父端的菱形就意味着这个。除菱形以外，非标识关系的基数符号与标识关系的相同。

递归关系

实体能参加递归关系 (也称 “捕鱼钩”)，同一个实体既是父也是子，任何递归关系必须是非标识的。

图5.14所示情形，公司被给看作是 “parent of”其他公司，和所有非-标识关系一样，父实体把键带入到子实体的数据区。

Figure 5.14: Example of a recursive relationship.

但是，注意发生的两件事件，第一，出现在数据区的键名字已被改变，而不是简单的”company-id”，而是”parent-id.company-id”，属性”parent-id” 是”company-id”的角色名。

属性不能以相同名字在同一个实体中出现两次，在规范化中这是错误的 (见第6章)。规范化的基本原则之一是如果两件东西有相同的名字，他们就是同一件东西。

公司的标识符”company-id”与”父的”公司标识符不是相同东西。它未被规定相同，虽然它来自相同域，但它将有不同的值 (它指不同公司)。定义和范例例子表将有帮助。

28

company-id: 公司的唯一标识符 parent-id: 上级公司的”company-id”，不是所有公司都有上级公司。

让读者来完善这些定义，如，概念\父”意味着?所有者?已启动的公司，倒闭的公司？更多的定义见第4章。

这儿有范例例子表格：

COMPANY company-id parent-id company-name C1 NULL Big Monster Company C2 C1 Smaller Monster Company C3 C1 Other Smaller Company C4 C2 Big Subsidiary C5 C2 Small Subsidiary C6 NULL Independent Company

Figure 5.15: Sample instance table for COMPANY.

从范例实例表中我们看到”Big Monster Company” 是”Smaller Monster Company\和 \Smaller Company.\的父。依次，\Monster Company,\是 \Subsidiary\和 \Subsidiary.\的父，\Company\不是其它公司的父，自己也无父，\Monster Company\也无父。

Figure 5.16: Company hierarchy.

当公司没有父时，前一框图中显示的菱形符号表示外来的键可以为NULL。递归关系也是可选的（菱形），或强迫的 (无菱形)。

为什么递归关系叫 \捕鱼钩\

5.3 多对多关系

考虑下列框图，第３章见过的，第４章中讨论定义的例子。 有关标题:

把多对多变成一对多关系 读多对多关系 N-ary关系

把多对多变成一对多关系

29

图 5.17显示人与地址之间的多对多关系，而且，它似乎说关系在两个方向标识。

Figure 5.17: Many-to-many relationship.

倘若我们简单地试着说那人 <使用>许多地址，地址 <被使用于>许多人，从概念上的观看，这没有错误。的确，在关系模型图(ERD)中允许出现，不用担心键。

多对多关系 (实线两端都是圆点)被称为不确定关系。

换言之，这种关系没有意义，如果我们对图5.13应用迄今为止已学到的有关标识关系，我们将发现人的键必须是地址的键的一部分，地址的键必须是人的键一部分。但是，地址由他们自己的键来标识，人也同样。成了死循环!

在正式标准中，IDEF1X不象其它一些模型语言，强调所有关系是二元的。如，他们确定地连接两个实体，这并不意味着三、四或 \个关系不需要，就只有这些情形被用来与其它结构充分地寻址------关联的实体。

无论如何，我们仍然需要记录多对多关系，如图3.10，让我们再一次更详细地看它。 我们已加叫地址-使用的联合实体，并把多对多关系转换成了两个一对多。

人的键 (\与地址的键(address-id)都移动到联合实体，这些不是唯一的地址-使用的属性，注意第三部分, \

Figure 5.18: Associative entity.

多对多关系时常隐藏意思，在图 5.17中，我们看到，人们使用许多地址，但我们不能看到他们是如何使用的，在完整结构的图 5.18中，我们能看到 \如何使用\，属性 \将告诉我们，为什么这个属性在键区域，而不在数据区？

再次，除非我们问业务规则，否则我们不能知道。如果每个人只能用一个地址于一个目的，那么\可放在数据区。但是，假定一个人用以多种用途来使用同一个地址时(如，邮寄地址、住宅地址)，如果\不在键区域，就不能记录信息，实例表有助于理解。

ADDRESS address-id address-detail A1 Princeton

30

A2 A3 A4 A5 New Brunswick Berkeley 1 Berkeley 2 New York City

PERSON person-id person-name P1 Ben P2 Margaret P3 Tom P4 John P5 Leon

ADDRESS-USAGE person-id address-id usage-type P1 A1 business P1 A2 residence P1 A2 mailing P2 A1 business P3 A1 business P3 A3 residence P3 A3 mailing P3 A4 mailing P4 A5 residence

Figure 5.19: Sample instance table for ADDRESS-USAGE.

为了讨论我们如此定义：

PERSON: 要记录的那些人 ADDRESS: 人们保持联系的地方 ADDRESS-USAGE: 记录地址用途

use-start-date 01 Jun 88 15 Sep 86 15 Sep 86 01 Jan 89 01 Feb 89 15 May 75 01 Jun 75 01 Mar 89 30 Sep 87

从例子中我们看到，Ben使用两个地址，普林斯顿和New Brunswick，他以两个不同的用途使用New Brunswick，即住址和邮件地址。汤姆与Berkeley情形相似。

如果 \不是地址-使用的主键的一部分，那么使用地址New Brunswick的Ben (P1/A2)就只有一个实例，那将意味着只有一个New Brunswick被记录，它是住址还是邮件地址？

你将时常查看实例例子表，以免设计不正确的模型结构，积极推荐使用实例来检验结构。

读多对多关系

让我们回到个人地址用途的例子（图5.18），要是读这个关系，我们会在此遇到麻烦。 对于模型者是个困难的选择，它们有两种方法来构造动词短语，要读图5.18 是困难的，除非通过关联实体来读到另一边实体的关系。如果你通过ADDRESS-USAGE来读，那么你能提出合理的语句：“An ADDRESS one or more PERSONs”和“A PERSON one or more ADDRESSs”。这些，至少是可读的语句，许多模型师采用这种格式来构造和读模型。

有另一种格式，它相当正确，但更麻烦点。模型结构相同，但动词短语不同，以一种稍微不同的方式来读模型，如图5.20所示。

31

Figure 5.20:

如何读它？

\ \

注意，短语动词变得相当的长，按照我们的标准模式从父实体直接读到子实体。

当结构相当简单时，无论选择哪种格式记录多对多的动词短语都不困难。然而，当结构变得更复杂时，记录这种动词短语就更困难，有时候关联实体的一边与它自身关联，它们表

Figure 5.21: Three-way relationship. 示了另一种多对多的关系。

32

当你熟习本章描述的模型方法后，应用它们来读难读的模型，发展出自己的风格。

N-ary关系

我们已经讨论的所有关系都是二元关系，关系线准确地连接两个实体。此外，我已可能把多对多关系转化为两个一对多关系。我们如何表示三个或更多实体间的关系呢？

我们以类似于联合实体的方法来处理它，关系线不连接三个 (或更多)实体，而是把 \关系表示为一套联合实体的二元关系，考虑图5.21所示业务规则。

这里我们看到合同表示了公司、产品、消费者中的三路关系。结构表示多个公司卖多产品给多个消费者。

４路、５路关系可以用类似的方法来构造。

然而，当你看这样的关系时，有一些业务问题要问，例如，\产品在出售之前必须由公司提供吗？\，不同公司的产品可以只签一个合同吗？, \我们需要记录消费者 \属于\哪一个公司吗?\，根据这些回答，结构可能会改变。

例如，如果对第一个问题的回答是\是\，第二回答是\不\，我们必须把结构改成图 5.22。

Figure 5.22: Altered model construct from 5.21.

注意到现在的 \三-路\关系，已被两个２路关系代替。通过对这些业务问题的提问，你会发现，将\关系分解成一系列的2路关系是恰当的，”真正”的３路关系在IDEF1X模型中是少见的，４路、５路就更罕见。

5.4 角色名与申明

角色名是给属性的多个新名称。在第4章，我们看到，命名的角色属性与基本属性有着

不同的定义，角色名想要描述属性扮演的角色（目的）( 4.5节)。角色名也带有连接由角色名表示的实体实例标识的申明。

33

Figure 5.23: Rolename example.

请看NEGOTIATION-ASSIST，我们看到\的两个不同角色\和 \，这说明\职员与 \谈判\职员是有区别的，由于涉及两类不同的职员，要求标识每个属性，角色可为我们实现这个。

如来自不同关系的两个外键具有相同的名字，就要检查结构，可能有规范化错误，第６章讲述了规范化基础。

5.5 存在与标识依赖

5.5.1 关系描述与插入、替换、删除 (IRD)规则

我们已经学习了关系的几个方面，了解了基数(参与关系的每一个实体有多少个实例)、阅读模型的动词短语。关系记录的更重要的方面是插入、替换、删除 (IRD)规则，下列各节不是 IDEF1X语言的正式部分。

34

Figure 5.24: IRD example.

本例中，PROJECT 与 PROJECT-EMPLOYEE是标识关系，PROJECT 的键是PROJECT-EMPLOYEE主键的一部分，根据基数规则，PROJECT-EMPLOYEE的每一个实例都有一个PROJECT实例与之对应，标识关系自然明确地记载了PROJECT-EMPLOYEE存在依赖于PROJECT。

如果我们删除PROJECT的实例会怎么样呢？

为什么，我们将也不得不全部删除PROJECT-EMPLOYEE中相应的实例？因为部分主键将会变成NULL，而这又是不允许的。

5.5.2 删除规则

如此我们有两种选择：或者删除PROJECT-EMPLOYEE中与已删除PROJECT实例对应的全部实例；或者只要具有不完全主键的PROJECT-EMPLOYEE中存在着对应于PROJECT的实例，就禁止删除PROJECＴ。这种与删除规则相关的情况叫级联cascade和限制restrict。被记录在模型中。

级联表示受PROJECT实例删除影响的所有PROJECT-EMPLOYEE实例也应被删除，限制表示只要在PROJECT-EMPLOYEE中有与PROJECT对应的实例存在，就不能删除PROJECT。

为什么我们要限制删除?原因之一是了解PROJECT-EMPLOYEE其它因素，如项目\项目启动日期，除了限制删除外，如果我们决定PROJECT-EMPLOYEE不存在或标识依赖于PROJECT，我们就可以通过在这两个实体间使用非标识依赖关系来改变参照完整限制。

Figure 5.25: Example with non-identifying relationship.

在这种情况下，IRD稍微有点不同，通过非标识关系贡献的外键允许为NULL（记得菱形吗？），这样对非标识关系我们有第三个选择，设置NULL。设置NULL表示，当PROJECT中的某个实例被删除时，PROJECT-EMPLOYEE中与这个实例对应的值设置为NULL，在前面的例子中，我们不级联删除，同时也不限制删除，而是设置为NULL。这种方法的优点是既保留了PROJECT-EMPLOYEE中的信息，又不严重破坏PROJECT-EMPLOYEE与

35

PROJECT的关系。

5.5.3 插入与替换规则

IRD规则记录业务规则的附加方法，决定使用级联或设置NULL，反映了维护历史信息的业务决策。

正如我们已经看到的，删除规则决定了表中的一行数据被删除时数据库的反映，插入和替换规则决定了当数据行被插入或改变时数据库的反映，插入和替换规则被明确地在模型中说明，它们通过关系类型本身来说明。

插入，只当所有引用的外键与引用表中已存在的数据行匹配时，一行数据才能被插入，除非关系明确地被说明为别的关系（如非标识关系）。在效果上，替换与插入应用现样的规则。

让我们看例子，在MOVIE / MOVIE-COPY电影/电影-拷贝图中，MOVIE-COPY保存有MOVIE相应的键，因此，我们不能在MOVIE-COPY中插入MOVIE中没有的电影。关系中的\也告诉我们，不能插入MOVIE电影之外的MOVIE-COPY电影-拷贝。

Figure 5.26: Example for insert and replace rules.

6 标准化

6.1 介绍

规范化的目标是保证只有一种了解 \事实\途径，规范模型的过程是删除所有模型结构中那些提供多种途径来了解相同事实的模型结构，另一个方面，是作为控制的方法，消除数据存储中的冗余。

规范化的目标的口号是：ONE FACT IN ONE PLACE! 为了规范化原理的基本了解，我们将使用一些有设计问题的例子，规范化是设计好数据库的一个重要组成部分。

6.2 普遍问题

36

6.2.1 重复数据组

图6.1中有些错误，你能看出来吗？

Figure 6.1: Employee entity.

实例表如下：

EMPLOYEE Emp-id emp-name emp-address children's-names E1 Tom Berkeley Jane E2 Don Berkeley Tom, Dick, Donna E3 Bob Princeton ------ E4 John New York Lisa E5 Carol Berkeley ------

Figure 6.2: EMPLOYEE instance table.

问题出在\。

在实体和属性的讨论中，我们说所有名称必须是单一的，明摆着问题是\我们需要记录多少个孩子的名字?\，\名字列要预留多少空间?\，\如果预留的空间超出了怎么办？\

这个设计违反了第一范式，第一范式是设计\外形\的基本定义，即数据的行和列组成一个在任何单元中没有嵌套结构的二维表格，数据库中每一个数据值必须是原子的，没有列表、重复元素或内部结构。

为了修正上面的设计，我们必须知道怎样删除孩子的名字列表。方法是把这个非一范式的实体转换成图6.3所示的结构，现在我们就孩子的名字表示为单个的实体了。(根据职员物理记录结构，就可以决定分配空间的问题，如为没有孩子的职员浪费空间问题，相反，也能决定给那些有孩子的职员分配多少空间)。

Figure 6.3: Altered model construct from Figure 6.1.

EMPLOYEE

37

本文来源：https://www.bwwdw.com/article/jawg.html