DB2

数据库设计的范式

    1NF 属性不可分割
    2NF 没有部分依赖
    3NF 没有传递依赖

反规范化设计

反规范化设计的前提
反规范化设计是规范化设计之后的步骤，首先令所有关系满足规范化设计（一般到3NF），之后的反规范化设计才能是可控的。

反规范化设计的优点
能够减少数据库查询时SQL的连接次数，从而减少磁盘IO，提高查询效率。

反规范化设计的缺点
反规范化设计会带来数据的重复存储，浪费了额外的磁盘空间，并且由于多处存储，增加了数据维护的复杂性。

反规范化设计的方法
增加冗余列
增加派生列
表合并
表分割
水平分割
建立多个列定义相同的表，将一个表中的数据行分别保存在多个表中。水平分割可以降低单表索引的层数和大小。
水平分割应用的几种情况：
表记录数很多
表中的数据具有独立性，比如数据可明显按所属地区、年度等属性进行划分
表内容需要存储在多个介质上
垂直分割
把一个表的列定义拆分到多个表中，并且具有相同的主键列。水平分割可以降低数据行的大小。
比如一个表中列数太多，并且某些列数据常用，而某些列数据不常用，就可以进行垂直分割。

反规范设计的数据维护
反规范设计的数据需要额外的工作来维护数据的完整性，一般可以通过以下几种方式进行
应用逻辑
在应用程序的事务中对同一数据的多处存储进行维护。
这种方式比较难于管理，一个维护逻辑很容易出现在多个应用程序当中，容易遗漏。
批处理维护
由批处理程序批量的处理所有的非规范化关系涉及的数据。一般定期运行，运行间隔根据业务来决定，并且可以利用Job来自动运行批处理程序。可用于对冗余数据的实时性要求不高或者有一定规则的环境。
触发器
在数据库端建立触发器，对原数据的修改会立即触发对冗余列的修改。可用于对数据实时性要求较高的环境，但同时会降低数据的插入和更新速度。

扇形陷阱与深坑陷阱 （Fan Trap and Chasm Trap）

两个陷阱的解释  

设计过程中应注意避免扇形陷阱出现，在设计玩成之后也应检查所有连续顺序相邻的两个one to many关系，以确保没有实际的深坑陷阱出现。

谁适合阅读本文

本文适合已经掌握数据库基本设计理论或者已经具有实际经验，打算借助Power Designer进行辅助设计的读者。

如果你已经是一个Power Designer的熟练使用者，或者你期望的是一些数据库的设计理论，请跳过本文。

如果你还不清楚数据库的基本设计理论，比如关系模型，范式，又有志于数据库设计领域的话，最好能够先打好基础，先找些与上面有关的资料看看，即使是优秀的辅助设计工具也并不能够替代我们设计出一个规范化的模型。

假设您已经安装好Power Designer 9.5 版本，如果您还没有获得软件，请到Sybase网站下载试用版本 。

定义更复杂的关系

使用依赖关系(Dependent)

还是使用上面的例子，我们假定这样的业务描述：雇员享有假期，雇员每次休假，需要记录雇员休假的起始日与结束日，假期以天为单位，一个雇员和一个开 始日唯一确定一个假期。根据这个业务描述，我们知道，对于假期而言，其必须依存于实体“Employee”而存在，即一个休假，必定有一个主体雇员。我们 在上一个模型的基础之上，添加一个实体，名称是“Holiday”，定义假期的属性开始日与结束日，这里并不需要重复定义一个雇员编号，而是替代的，使用 依赖关系，来表示实体“Holiday”依赖于实体“Employee”，关系定义如下图：

在实体“Holiday”中，我们需要设置开始日为主键标识符，开始日与其依赖实体中的雇员编号一起作为实体“Holiday”的标识符，用来唯一确定一个假期。这种依赖关系在概念图中表现如下：

从途中可以看出，在实体“Holiday”一端多了一个朝外的三角▲箭头，这个含义就是这个实体“的依赖于三角箭头所指的另外一个实体，在转化出来 的物理模型当中，实体“Employee”的empNo，在Holiday实体中不仅会作为一个外键，还同时会作为主键出现（与startData一起作 为复合主键）。

使用Dominant role

当两个实体之间的关系是1..1 时（尽管这种关系比较少见，常见于面向对象的设计方法当中，依赖实体中的主键通常与外健重合），你需要明确指定这两个实体，哪一个是父实体，哪一个是依赖实体，否则，系统在由概念模型转化为物理模型时，将不能确定需要在哪一端生成外键，这时就需要用到“Dominant role”选项，这个选项只有在1..1 的关系中才允许进行设置。我们假定这样的业务描述，企业中的部分雇员拥有一个系统帐号，并且是唯一的一个帐号，这些雇员需要保存一些额外的信息，比如帐号名称、密码等等。我们添加了一个新的实体“User”，其与雇员之间为1..1 的关系，由于一个用户帐号必定属于一个雇员，而一个雇员则可能没有用户帐号，所以我们定义实体“Employee”支配实体“User”。同时，由于 “User”依赖于“Employee”而存在，所以再定义一个由前者到后者的依赖关系，如下图：

Dominant role 选项中，箭头所指的实体为被支配的实体，即作为依赖实体。在模型图中，支配实体的一方会出现一个用圆括号括起来的大写字母“D”。

转化出来的物理模型中，表User中，empNo作为单独的主键，同时也是引用Employee表的一个外键。

处理多对多(n..n)的关系

在概念模型中，一般很少看见两个实体之间是直接的n..n 的关系，一般这种情况下我们会增加一个中间实体，在Power Designer中，提供了一个专门的符号来对应，叫做“Association”。请考虑以下的情形：

企业中拥有帐号的雇员在系统中具有不同的操作权限，这通过用户角色来进行管理，权限已经分配给了多个不同的角色，一个用户帐号至少属于一个角色，并 且可能会同时属于多个角色，一个角色可以包含0个或多个用户帐号。根据以上描述，我们添加一个实体“Role”，它与实体“User”之间是n..n 的关系，为了表达这种关系，我们增加一个“Association”并分别使用“Association Link”与其他两个实体建立关系，表示如下：

使用一个普通的实体，合理定义关系，并选择“Dependent”选项，是可以替代“Association”的，但使用 “Association”更方便、直观，使模型更容易理解，并可以减少因不谨慎而可能导致的错误。

(完)

8/23/2005 更新了下载链接

参考资源

• 数据库设计－在Power Designer 中应用概念模型进行数据库第一阶段设计的示例(一)
• 下载本文示例中所使用的概念模型文件
• 本文内容以及模型文件基于Sybase Power Designer 9.5 版本，您可以到 Sybase中国网站免费下载最新的 PowerDesigner10 试用版本，以及 PowerDesigner10的技术文档。

• 《Database Solution－A Step by Step Guide to Building Database》by Thomas M.Connolly, Carolyn E.Begg, 译者: 何玉洁，梁琦等
• 下载第三方 Power Designer 使用教程

谁适合阅读本文

本文适合已经掌握数据库基本设计理论或者已经具有实际经验，打算借助Power Designer进行辅助设计的读者。

如果你已经是一个Power Designer的熟练使用者，或者你期望的是一些数据库的设计理论，请跳过本文。

如果你还不清楚数据库的基本设计理论，比如关系模型，范式，又有志于数据库设计领域的话，最好能够先打好基础，先找些与上面有关的资料看看，即使优秀的辅助设计工具也并不能够替代我们设计出一个规范化的模型。

建立一个概念模型

对于数据库的设计，我们一般从概念模型开始，在概念模型设计阶段，我们着重分析数据的逻辑结构，避免陷入具体的存储细节，所有的设计都与将来所要采用的具体数据库产品无关。

假设您已经安装好Power Designer 9.5 版本，如果您还没有获得软件，请到Sybase网站下载试用版本 。运行程序，使用“Ctrl+N” 新建模型，在弹出的窗口中选择“Conceptual Data Model”，点击“OK”。

在窗口左侧浏览器中的当前工作区节点下会新增一个概念模型，自动建立了一个默认的概念图Diagram_1，并且已经在当前工作窗口打开。一个概念模型可以拥有多个这样的概念图，可以在模型的属性中指定其中一个作为默认。

工作区中有一个元件面板，包含了在概念模型中可以使用的各种符号。最常用的是：实体（Entity）和关系（Relationship），如下图：

定义实体

用鼠标双击实体的符号，可以进入实体的属性页。

1. General 项目

   Name：是用来在模型中标识一个实体，一般用于模型在界面中的显示（这个可以通过更改选项设置进行改变）。在一个模型当中，实体的名字不能重复。

   Code：在模型转化时一般作为对象的物理名称，比如把实体属性的Code转化为数据库中的列名，当然我们现在不必为了这个实体将来叫什么而费神，一般采取与Name一致即可。

   Generate：默认是选择状态，如果取消，则在转化为其他模型时，会忽略这个实体。

2. Attributes 项目

窗口中下面表格里的各项很类似于一个表结构的定义，但数据类型是经过抽象化的，采用独立的表示方法，不与任何一个具体的数据库系统相关。

在此项目中为当前实体添加属性。

后面的三列CheckBox分别代表：

• M：此属性不允许为空值
• P：此属性为主键标识
• D：为可显示属性

按“Crtl+U”呼出“定制列过滤器”的窗口，可以根据自己的喜好和实际需要选择那些列出现在窗口中，那些隐藏。使用快捷键 “Crtl+E”可以允许或者禁止当前过滤器。

我们分别重新命名了以上两个实体为部门（Department）和雇员（Employee），并分别添加了属性，如下图：

默认的，概念图只显示作为主键标识的属性，并且隐藏了数据类型。这样是为了使概念图更加简洁、易于理解，你完全可以通过选项更改这些显示配置。

定义关系

双击关系（Relationship）的符号，进入关系的属性页，在Detail项目中，我们可以对两个实体的关系进行详细的定义，如下图：

1. General 项目

   一般最好为关系取一个贴切的名字，本例的业务关系描述如下：一个部门有多个员工，我们使用“Has”作为这个关系的名字。

   同样的我们也可以描述为：多个员工属于一个部门，可不可以使用“Belong to”作为关系名字呢？一般不推荐这样做，在概念图中有一个约定，关系的名字采用从“1,n”中“1”所在的方向向“n”所在一方进行读取的语义。本例即 “1”在部门一方，从部门一方向雇员一方读取语义，即：部门有（Has）多个员工。

2. Detail 项目

假定对于实体部门（Department）和雇员（Employee），具有如下关系：

• 一个部门可以有多个雇员，新成立的部门也可以暂时没有任何雇员；

• 一个雇员必须属于一个部门，并且同时只能属于一个部门；

根据以上关系，我们修改属性页，部门－雇员的方向采用默认的0,n，雇员－部门的方向修改为强制约束（Mandatory），或者从下拉框中选择“1,1”，如下图：

最后定义完成的关系（Relationship）在概念图中表示如下：

注：在Power Designer中，关系符号靠近实体端的一个“横线”代表强制性约束，“空心圆圈”代表无强制约束，即这一方可以无对象关联；“非分岔”线代表为“1” 的关系，“分岔”线代表“多”的关系。以上四个符号共可以组合出16种关系（包含反向）。其中“多对多”的关系一般通过给出一个中间实体来进行分解，所以在许多概念图中，是看不到实际的“多对多”的关系存在的。

另外在关系的属性中还有两项：Dominant role 和Dependent，可以表示更复杂的关系，会在后面讲到。

(待续)

8/23/2005 更新了下载链接

参考资源

• 在Power Designer 中应用概念模型进行数据库第一阶段设计的示例(二)
• 下载本文示例中所使用的概念模型文件
• 本文内容以及模型文件基于Sybase Power Designer 9.5 版本，您可以到 Sybase中国网站免费下载最新的 PowerDesigner10 试用版本，以及 PowerDesigner10的技术文档。

• 《Database Solution－A Step by Step Guide to Building Database》by Thomas M.Connolly, Carolyn E.Begg, 译者: 何玉洁，梁琦等
• 下载第三方 Power Designer 使用教程

10:34 2004-07-29
在物理模型中,对于一个关联非常多的表,可以使用Ctrl+M 创建这个表的多个快捷方式,然后使用Ctrl+鼠标拖动已有的联接矛点.

16:00 2004-07-31
如果需要一次性加入多个相同类型的对象,可以在左侧的窗口右击模型名称,选择List of 想要加入的对象,这样就可以在一个列表中使用向下键加入了,也可以方便的copy和paste.
使用模型check的功能,可以自动检查模型存在的一些问题,并可以选择自动修正操作.
有时PowerDesigner自动生成的唯一约束Key会重复,并且重复的key有时不能够全部被check出来,需要手动修改.

14:29 2004-08-02
在编辑视图时,column标签页中不能删除无用的字段,只能进入SQL Query页进行编辑,同时,在column页更改字段的顺序也无法在实际SQL中生效.
当在SQL Query的字段列表中使用as语法时,有时更改as后面的列名不能在Column页中进行同步,导致创建视图中实际的列名与想要的不一致.可以通过检查 Preview标签,比较快速的判断是否有这种情况发生,当有不一致时,Preview中的sql会使用这样的格式:
create or replace view v1(column1, column2, ..., columnN) as
...
/
如果没有不一致,则不会生成括号部分.

19:02 2004-08-05
定义的视图可能互相之间会有引用关系,必须严格的按先后顺序创建,否则会出错,但powerDesigner在生成视图sql时不能指定先后顺序,是以视图名称来安排生成顺序的.
如果在oracle中,可以指定视图的属性 force 为true, 这样创建视图引用的对象即使不存在也不会报错.

16:18 2004-9-29
目前9.5版本中没有定义临时表类型的对象,无法定义oracle的global temporary 表.

V11

2006-04-04

Ctrl+C之后，使用Ctrl+K粘贴对象的快捷方式，用Ctrl+V会复制对象。

对于对象非常多的项目，比如上千个表，可以建立一个总览PDM，之后未各个模块分别建立PDM，只放入相关的表，并表示这这些表之间的关系，忽略这组表与外部的关系。 

改变Diagram 的显示格式

在Diagram的tables 中显示Schema

• Tools -> Display Preferences -> Object view -> Table，选中 Owner.
• 默认地, 这只改变当前的diagram，如果希望一起变更其他已经建立的diagrams，点击左下角的 Apply To按钮，然后选择希望变更的diagrams。如果希望这个变更对所有新建的diagram都有效，就点击按钮Set As Default。

默认的References 线条很难看

• Tools -> Display Preferences -> Format -> Reference，点击Modify，Line Style -> Corners，选择第二个或者第三个折线格式，OK退出。

表的列数太多，导致diagram中对象太长

• Tools -> Display Preferences -> Object view -> Table -> Table Columns，uncheck All Columns，选择Limit，数值用10或者20。也可以选择PK Columns 只显示primary keys，或者选择Key Columns 只显示primary keys, foreign keys, alt keys等keys。

把整个diagram 或者部分导出为图形文件

• 选择要导出的对象（用shift多选，或者鼠标划亮多个） ，如果导出整个diagram就Ctrl+A，然后Edit -> Export Image，文件类型选择jpeg或者png，保存。
  

同时修改多个对象格式 

• 如果使用shift键选中多个，然后右键->Format，不会同时修改多个对象。但选中多个后，使用Ctrl＋T快捷键却可以。

设置命名转换

设置概念模型Entry只显示主键

设置允许Relationship code重名

设置改面模型允许Data Item Reuse

Data Item

• 似乎是版本11带来的功能，原来9.5版本的模型没有这个选项
  
• 可以在不同的表之间Reuse Data Item（Column），这样可以实现一处修改，到处生效。
• Reused Data Item，一个表中修改非空约束，不会反映到其它表。
  
• 可以在List Of Data Item视图中删除重复的项目。
  

Sysbase 发布PowerDesigner 版本12

• 最主要的新功能包括：
• 增强的用户界面定制，并简化操作，使新手很容易上手，同时高级用户也拥有期望的控制
• 增强的Report功能
• 增加对最新标准的支持，包括UML 2.0 和最新的DBMS 版本
• 改善了对导入ERWin模型的支持
• 15天评估版下载地址
• http://www.sybase.com/detail?id=1038605
• 官方在线资源
• PowerDesigner Technical Corner:
  http://www.sybase.com/developer/products/pdtechcorner
• PowerDesigner Newsgroups: powersoft.public.powerdesigner.general
• PowerDesigner at the Sybase Developer Network (SDN):
  http://www.sybase.com/developer
• Demonstration Videos:
  http://www.sybase.com/products/developmentintegration/powerdesigner/videos
• PowerDesigner Web Documentation All Version
• PowerDesigner Web Documentation Version 12.1
• Sybase网站Archive文档的速度很慢，PowerDesigner最新的Archive 版本还是8.0
• PowerDesigner有个版本叫做PowerAMC，是专门针对法语的版本。
  

索引

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

正文

1. Access method（访问方法）：此步骤包括从文件中存储和检索记录。
2. Alias（别名）：某属性的另一个名字。在SQL中，可以用别名替换表名。
3. Alternate keys（备用键，ER/关系模型）：在实体/表中没有被选为主健的候选键。
4. Anomalies（异常）参见更新异常（update anomalies）
5. Application design（应用程序设计）：数据库应用程序生命周期的一个阶段，包括设计用户界面以及使用和处理数据库的应用程序。
6. Attribute（属性）（关系模型）：属性是关系中命名的列。
7. Attribute（属性）（ER模型）：实体或关系中的一个性质。
8. Attribute inheritance（属性继承）：子类成员可以拥有其特有的属性，并且继承那些与超类有关的属性的过程。
9. Base table（基本表）：一个命名的表，其记录物理的存储在数据库中。
10. Binary relationship（二元关系）：一个ER术语，用于描述两个实体间的关系。例如，panch Has Staff。
11. Bottom-up approach（自底向上方法）：用于数据库设计，一种设计方法学，他从标识每个设计组建开始，然后将这些组件聚合成一个大的单元。在数据库设计中，可以从表示属性开始底层设计，然后将这些属性组合在一起构成代表实体和关系的表。
12. Business rules（业务规则）：由用户或数据库的管理者指定的附加规则。
13. Candidate key（候选键，ER关系模型）：仅包含唯一标识实体所必须得最小数量的属性/列的超键。
14. Cardinality（基数）：描述每个参与实体的可能的关系数目。
15. Centralized approach（集中化方法,用于数据库设计）：将每个用户试图的需求合并成新数据库应用程序的一个需求集合
16. Chasm trap（深坑陷阱）：假设实体间存在一根，但某些实体间不存在通路。
17. Client（客户端）：向一个或多个服务器请求服务的软件应用程序。
18. Clustering field（群集字段）：记录总的任何用于群集（集合）航记录的非键字段，这些行在这个字段上有相同的值。
19. Clustering index（群集索引）：在文件的群集字段上定义的索引。一个文件最多有一个主索引或一个群集索引。
20. Column（列）：参加属性（attribute）。
21. Complex relationship（复杂关系）：度数大于2的关系。
22. Composite attribute（复合属性）：由多个简单组件组成的属性。
23. Composite key（复合键）：包含多个列的主健。
24. Concurrency control（并发控制）：在多用户环境下同时执行多个十五并保证数据完整性的一个DBMS服务。
25. Constraint（约束）：数据库不允许包含错误数据的一致性规则。
26. Data conversion and loading（数据转换和加载）：数据库应用生命周期重的一个阶段，包括转换现有数据到新数据库中以及酱下耨应用程序转换到新的数据库上运行。
27. Data dictionary（数据字典）：参见系统目录（system catalog）。
28. Data independence（数据独立性）：使用数据的应用程序的数据描述部分。这意味着，如果将新的数据结构添加到数据库中，或者数据库中现有的结构被修改了，那么使用此数据库的就会受到影响，除非应用程序不直接依赖于被修改的部分。
29. Data model（数据模型）：描述数据、数据间关系以及数据的约束的概念的一个集成的集合。
30. Data redundancy（数据冗余）：参见冗余数据（redundant data）。
31. Data security（数据安全）：包括对数据库对象（如表和视图）的访问和使用以及用户可以在这些对象上实施的操作。
32. Database（数据库）：是逻辑上相关的数据（以及这些数据的描述）的一个共享的集合，用于解决公司对信息的需求。
33. Database design（数据库设计）：数据库应用生命周期中的一个阶段，包括创建一个支持公司的操作和目标的数据库的设计。
34. Database integrity（数据库完整性）：指存储数据的正确定和一致性。完整性通常用约束来表达。
35. Database Management System，DBMS（数据库管理系统）：一个能够让用户定义、创建和维护数据库并控制对数据库的访问的软件系统。
36. Database planning（数据库规划）：能尽可能有效的实现数据库应用的各阶段的管理活动。
37. Database server（数据库服务器）：同服务器。
38. DBMS engine（DBMS引擎）：同服务器。
39. DBMS selection（DBMS选择）：数据库应用生命周期中的一个阶段，包括选择一个合适的DBMS来支持数据库应用。
40. Degree of a relationship（关系的度）：一个关系中参与的实体的个数。
41. Denormalization（反规范化）：形式上，这个术语指的是对基本表结构的修改，这样新的表比原始的表的规范化程度要低。但也可以用此属于更宽泛地形容将两个表和并成一个新表的情形，而这个新表与原来的表具有相同的范式，但比原表包含更多的空值。
42. Derived attribute（派生属性）：表示其值可以从一个相关属性和属性集的值派生得到的属性，这个属性在实体中不是必须的。
43. Design methodology（设计方法学）：一种结构化的方法，它使用过程、工具和文档来支持和简化设计过程。
44. Disjoint constraint（无连接约束）：描述子类的成员间的关系，并指明超类某个成员是否有可能成为一个或多个子类的成员。
45. Domain（域）：一个或多个属性的取值范围。
46. Entity（实体）：具有相同性质的对象的集合，它是由用户或公司标识并可独立存在的。
47. Entity integrity（实体完整性）：在一个基本表中，主健列的值不能为空。
48. Entity occurrence（实体出现）：实体中的一个唯一可标识的对象。
49. Entity-Relationship model（实体关系模型）：公司的实体、属性和关系的详细逻辑表示。
50. Fact-finding（事实发现）：使用诸如面谈和提问等技术收集关于系统的事实、需求和性能的形式化过程。
51. Fan trap（扇形陷阱）：但从第三个实体扇出的两个实体有1:*关系时出现扇形陷阱，但这两个实体在他们之间应该有直接关系以提供必要的信息。
52. Field（字段）：同元组（Tuple）。
53. File（文件）：存储在副主存储器中的相关记录的一个命名集合。
54. File-based system（基于文件的系统）：一个文件集合，用来管理（创建、插入、删除、更新和检索）一个或多个文件中的数据，并产生基于这些文件中的数据的应用（通常是报表）。
55. File organization（文件组织）：当文件存储在磁盘上时，对文件中的记录的安排方式。
56. First normal form（1NF，第一范式）：表中的每个列的交叉处以及记录包含切进包含一个值的表。
57. Foreign key（外健）：一个表中的一个列或者多个列的集合，这些列匹配某些其他（也可能是同一个）表中的候选键。
58. 4GL, Fourth-Generation Language（第四代语言）：一种非过程化语言，比如SQL，他只需要用户定义必须完成什么操作，4GL负责将所进行的操作翻译成如何实现这些操作。
59. Full functional dependency（完全函数依赖）：一个列在功能上依赖于复合主健，但不依赖于主健的任何一个子集的条件。
60. Functional dependency（函数依赖）：描述表中列之间的关系。
61. Generalization（泛化）：通过标识实体间的公共特征使实体间差别最小化的过程。
62. Generalization hierarchy（泛化层次结构）：同类型层次（type hierarchy）。
63. Global data model（全局数据模型）：代表整个公司（和被模型化的公司的一部分）的数据模型。
64. Implementation（实现）：数据库应用生命周期中的一个阶段，包括数据库和应用程序设计的物理实现。
65. Index（索引）：一种允许DBMS将特定的记录更快的放置到文件中，从而加快对用户查询的响应的数据结构。
66. Infomation system（信息系统）：能够在整个公司范围内收集、管理、控制和分发数据/信息的资源。
67. Inheritance（继承）：参见属性继承（attribute inheritance）。
68. Integrity constaints（完整性约束）：防止出现数据库中的数据不一致的约束。
69. IS-A hierarchy（IS－A层次结构）：同类型层次结构（type hierarchy）。
70. Local logical data model（局部逻辑数据模型）：代表特定用户视图或用户视图的组合的数据模型。
71. Logical database design（逻辑数据库设计）：基于特定的数据模型构建公司的数据的模型的过程，但不依赖于特定的DBMS以及其他的物理条件。
72. Meta-data（元数据）：关于数据的数据，参见系统目录（system catalog）。
73. Mision objective（使命目标）：标识数据库必须支持的特定任务。
74. Mission statement（使命语句）：定义数据库应用程序的主要目标。
75. Multiplicity（多样性）：定义与某个相关实体的一次出现有关的实体的出现数目。
76. Multi-valued attribute（多值属性）：为一个实体的出现保存多个值的属性。
77. Nonkey attribute/column（非键属性/列）：不是键的一部分的属性/列。
78. Normal forms（范式）：规范化过程的一个阶段。前三个范式分别为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。
79. Normalization（规范化）：一种产生带有需要的特性的技术，这种特性能支持用户和公司的需求。
80. Null（空值）：表示当前不知道或对于这条记录来说不可使用的一个列的值。
81. Operational maintenance（操作维护）：数据库应用生命周期的一个阶段，包括监视和维护系统安装后的运行。
82. Participation constraint（参与约束，EER模型）：确定超类中的每个出现是否必须作为子类的一个成员进行参与。
83. Participation constraint（参与约束，ER模型）：确定是否所有或者仅仅是某些实体出现参与到关系中。
84. Physical database design（物理数据库设计）：在二级存储上产生数据库实现的描述的过程，它描述基本表、文件的组织、用于获得有效访问的索引以及所有与完整性约束和安全性限制有关的说明。
85. Primary index（主索引）：在文件的有序键字段上构建的索引。一个文件最多可以有一个主索引或一个群集索引。
86. Primary key（主健，ER模型）：用来标识每个实体的出现的候选键。
87. Primary key（主健，关系模型）：在一个表中用来标识记录唯一性的候选键。
88. Privileges（权限）：允许用户在给定基本表和视图上执行的操作。
89. Prototyping（原型）：数据库的应用程序生命周期的一个阶段，包括勾践数据库应用程序的工作模型。
90. Query-by-Example（QBE）：一种用于关系型DBMS的非过程化的数据库语言。QBE是一个图形化的“点－按”查询数据库的方法。
91. RDBMS：关系型DBMS。
92. Record（记录）：同元组（Tuple）。
93. Recovery control（恢复控制）：当时百事，将数据库还原到正确状态的过程。
94. Rcursive relationship（递归关系）：一种关系，挡同一个实体在不同的角色中参与多次时就会出现递归关系。例如Staff Supervises Staff。
95. redundant data（冗余数据）：在多个表中存储的重复数据。
96. Referential integrity（参照完整性）：如果一个表中存在外健，则外健值必须匹配主表中的某些记录的候选键的值。
97. Relation（关系）：一个关系是一张表，它也有列和行。
98. Relational model（关系模型）：以表（或关系）的形式表示数据的数据模型。
99. Relational database（关系数据库）：规范化表的集合。
100. Relation （关系）：实体间有意义的关系。
101. Relationship occurrence（关系出现）：两个实体出现之间的唯一可标识的联系。
102. Requirements collection and analysis（需求收集于分析）：数据库应用程序生命周期的一个阶段，包括收集和分析数据库应用程序所要支持的关于公司的信息，并使用这些信息来标识新的数据库应用需求。
103. Row（行）：同元组（Tuple）。
104. Second normal form（第二范式）：一个已经是第一范式的表，同时满足所有的非主健列只能从构成主健的全部列中获得。
105. Secondary index（二级索引）：在数据文件的非有序字段上定义的索引。
106. Security（安全）：指防止数据库被非授权的用户访问，包括有意的和无意的。RDBMS通常提供两种类型的安全：数据安全和系统安全。
107. Server（服务器）：为发出请求的客户提供服务的软件应用程序。参见两层/三层客户端－服务器体系结构。
108. Simple attribute（简单属性）：只有一个组件的属性。
109. Single -valued attribute（单值属性）：对于一个实体出现只有一个值的属性。
110. Specialization（特化）：通过标识用来区分实体间成员的特征来最大花实体间成员的差别的过程。
111. Specialization hierarchy（特化层次结构）：同类型层次结构（Type hierarchy）。
112. SQL（Structured Query Language，结构化查询语言）：一种用于RDBMS的非过程化数据库语言。换言之，你只需要指定你需要那些信息，而不需要指定如何得到这些信息。SQL已经被国际标准化组织（ISO）标准化了，因此SQL是定义和操纵RDBMS的正式和实际上的标准语言。
113. Strong entity（强实体）：一个不依赖于其他实体的主健的存在而存在的实体。
114. Subclass（子类）：为（超类）实体中的某些出现并保持特定属性和关系并有不同角色的实体
115. Superclass（超类）：为实体中的所有出现保存公共属性和关系的实体。可参见特化和泛化。
116. Superkey（超键，ER模型）：一个属性或属性集，诶译的标识了每个实体地出现。
117. Superkey（超键，关系模型）：一个列或者列集，唯一的标识了表中地一个记录。
118. System catalog（系统目录）：保存关于数据库地结构、用户、应用程序等信息地数据。
119. System definition（系统定义）：数据库应用声明周期重的一个阶段，包括定义数据库应用程序以及他的主要用户视图地范围和边界。
120. System security（系统安全）：在系统级保护数据库地访问和使用，不如用户名和密码。
121. Table（表）：同关系（relation）。
122. Ternary relationship（三元关系）：三个实体间的关系。例如panch，staff和member之间的Registers关系。
123. Testing（测试）：数据库应用生命周期的一个阶段，包括执行应用程序并有意地发现错误。
124. Third normal form，3NF（第三范式）：一个已经是1NF和2NF的表，同时满足所有的非主健的列的值仅能从主健列得到，而不能从其他列得到。
125. 3GL, Third-Generation Language（第三代语言）：一种过程化的语言，比如COBOL、C、C＋＋，它需要用户（通常是程序员）指定必须要干什么事情以及如何干这些事情。
126. Three-tier client-server architecture（三层客户端－服务器体系结构）：由处理用户界面的客户和处理业务逻辑的应用程序服务器以及数据处理曾组成，而数据库服务器是用来来运行DBMS的。
127. Top-down approach（自顶向下方法，用于数据库设计）：一种设计方法，此种方法从定义系统的主要结构开始，然后将这些结构逐步细分成更小的单元。在数据库设计中，通过标识实体和数据间的关系开始这个顶层的步骤，然后逐步添加细节，比如你希望保存的关于实体和关系的信息（成为属性）以及在实体、关系和属性上的所有约束。
128. Transaction（事务）：由用户和应用程序执行的一个动作或一系列动作，这些动作访问或修改数据库的内容。
129. Transaction Processing Monitor，TPM（事务处理监视器）：控制数据在客户端和服务器键转换的程序，以便为联机事务处理（OLTP）提供一个一致的环境。
130. Transitive dependency（传递依赖）：假设A、B、C是表中的列，如果B依赖于A（A-->B），并且C依赖于B（B- ->C），则C通过B传递而依赖于A（假设A不依赖于B或C）。如果在主健上存在一个传递依赖，则此表就不是3NF的。必须从表中去掉传递依赖以达到3NF的要求。
131. Tuple（元组）：关系中的一行记录。
132. Two-tier client-server architecture（两层客户端－服务器体系结构）：由处理主要业务和数据处理逻辑以及与用户的接口的客户端应用程序和管理和控制数据库访问的服务器程序组成。
133. Type hierarchy（类型层次结构）：一个是提以及它的子类和他们的超类，等等。
134. UML（Unified Modeling Language，统一建模语言）：在20世纪80年代和90年代引入的诸多面向对象分析与设计方法重的一种较新的方法。
135. Update anomalies（更新异常）：当用户视图更新一个包含冗余数据的标识可能引起的不一致。有三种类型的异常：插入、删除和更新。
136. User view（用户视图）：从特定的作业（比如经理或管理者）角度或业务应用领域（比如市场、职员或库存控制）定义的数据库应用的需求。
137. View（视图）：一个“虚拟底表”，它不实际存在数据库中，但他由 DBMS从现有底它所涉及的基本表中产生。
138. View integration approach（视图综合法，用于数据库设计）：每个用户视图的需求，用来构建代表用户试图底独立数据模型。在数据库设计阶段，结果数据库模型被合并成一个更大的模型。

参考资源

• 《Database Solution－A Step by Step Guide to Building Database》by Thomas M.Connolly, Carolyn E.Begg, 译者: 何玉洁，梁琦等