翻译 大型共享数据库的数据关系模型(精选.)
第3章关系数据模型(基本概念和ER转换)
返回
25
4. 关系中每一分量必须是不可分的数据项，或者说所有属性值都 是原子的，即是一个确定的值，而不是值的集合。属性值可 以为空值，表示“未知”或“不可使用”，即不可“表中有 表”。满足此条件的关系称为规范化关系，否则称为非规范 化关系。 例如，在表2.8中，籍贯含有省、市／县两项，出现了“表中有表” 的现象，则为非规范化关系，而把籍贯分成省、市／县两列，将 其规范化，如表2.9所示。 姓名 籍贯 姓名 省 市／县 省 张强 王丽 吉林 山西 市／县 长春 大同 张强 王丽 吉林 山西 长春 大同
返回
27
课堂练习
62页 3.1.1
返回
28
2.4 关系的键
2.4.1 候选键与关系键 能唯一标识关系中元组的属性或属性集，则称该属性 或属性集为候选键(Candidate Key)，也称候选关键字 或候选码。如：
“学生关系”中的学号能唯一标识每一个学生，则属性 学号是学生关系的候选键。 在“选课关系”中，只有属性的组合“学号+课程号” 才能唯一地区分每一条选课记录，则属性集“学号+课 程号”是选课关系的候选键。
CNO 课程号 C1 C2 CN 课程名 程序设计 微机原理 CT 课时 60 80
C3
C4 C5 C6 C7
数字逻辑
数据结构 数据库 编译原理 操作系统
60
80 60 60 60
返回
16
SC（选课表）
SNO 学号 S1 S1 CNO 课程号 C1 C2 SCORE 成绩 90 85
TC（授课表）
返回14t教师表tno教师号tn姓名sex性别age年龄prof职称sal工资comm岗位津t1李力47教授15003000计算机t228讲师8001200信息t3刘伟30讲师9001200计算机t451教授16003000自动化t539副教授13002000信息返回15s学生表sno学号sn姓名sex性别age年龄dept17计算机s218信息s320信息s421自动化s519计算机s620自动化返回16c课程表cno课程号cn课程名ct课时c1程序设计60c2微机原理80c3数字逻辑60c4数据结构80c5数据库60c6编译原理60c7操作系统60返回17sc选课表tc授课表sno学号cno课程号score成绩tno教师号cno课程号s1c190t1c1s1c285t1c4s2c557t2c5s2c680t3c1s2c7t3c5s2c570t4c2s3c1t4c3s3c270t5c5s3c485t5c7s4c193s4c285s4c383s5c289返回181关系relation一个关系对应一张二维表如图的五张表对应五个关系
关系模型(计算机)-详解
关系模型(计算机)-名词详解出自 MBA智库百科()(重定向自关系模型)关系模型（Relational Model）目录• 1 关系模型• 2 关系模型理论的起源与发展• 3 关系模型的原理与特点• 4 关系模型的组成• 5 关系模型的优点关系模型用于数据库管理的关系模型是基于谓词逻辑和集合论的一种数据模型，广泛被使用于数据库之中。
最早于1969年由埃德加•科德提出。
关系模型的基本假定是所有数据都表示为数学上的关系，就是说n个集合的笛卡儿积的一个子集，有关这种数据的推理通过二值（就是说没有NULL）的谓词逻辑来进行，这意味着对每个命题都没有两种可能的赋值：要么是真要么是假。
数据通过关系演算和关系代数的一种方式来操作。
关系模型是采用二维表格结构表达实体类型及实体间联系的数据模型.关系模型允许设计者通过数据库规范化的提炼，去建立一个信息的一致性的模型。
访问计划和其他实现与操作细节由DBMS引擎来处理，而不应该反映在逻辑模型中。
这与SQL DBMS普遍的实践是对立的，在它们那里性能调整经常需要改变逻辑模型。
基本的关系建造块是域或者叫数据类型。
元组是属性的有序多重集（multiset），属性是域和值的有序对。
关系变量（relvar）是域和名字的有序对（序偶）的集合，它充当关系的表头（header）。
关系是元组的集合。
尽管这些关系概念是数学上的定义的，它们可以宽松的映射到传统数据库概念上。
表是关系的公认的可视表示；元组类似于行的概念。
关系模型理论的起源与发展网状数据库和层次数据库已经很好地解决了数据的集中和共享问题，但是在数据独立性和抽象级别上仍有很大欠缺。
用户在对这两种数据库进行存取时，仍然需要明确数据的存储结构，指出存取路径。
而后来出现的关系数据库较好地解决了这些问题。
关系数据库理论出现于60年代末到70年代初。
1970年，IBM的研究员E.F.Codd博士发表《大型共享数据银行的关系模型》一文提出了关系模型的概念。
数据库 关系模型(参考)
9
关系数据结构的定义
直观的讲：
关系是笛卡儿积的子集，是一张二维表，表的每行 对应一个元组，列对应一个域，给每个列取名属性 名以示区别 若关系中的某一组属性的值能唯一地标识一个元组， 则称该属性组为候选码。 候选码的超集为超码。 候选码之一可被选作主码（PrimaryKey,PK）。
R和S的差，R-S，是在R中而不在S中的 元素的集合 R和S必须同类型（属性集相同、次序相 同，但属性名可以不同）
R-S
38
集合运算——差Minus (-)
39
集合运算——笛卡儿积(×)
关系R、S的笛卡儿积是两个关系的元组 对的集合所组成的新关系 R×S： 属性是R和S的组合（有重复） 元组是R和S所有元组的可能组合 是R、S的无条件连接，使任意两个关 系的信息能组合在一起
关系代数——实例1
查询选修了2号课程的学生的学号 课程号、学号←SC表
59
关系代数——实例1
2号课程的选课情况
σcno=‘2’(SC)
60
关系代数——实例1
选修2号课程的学号
πsno(σcno=‘2’(SC))
61
关系代数——实例2
列出选修‘数学’课的学生的学号、姓名以及成绩 学号、姓名←Student表 课程名称←Course表 成绩←SC表 Student← SC→Course
12
查询表
视图表
关系模式
关系数据模型
连接是从两个关系的广义笛卡儿积中选取属性间满足一定条 件的元组。连接又称θ连接。记作：
（3）连接
R
AθB
S {t | t tr t s tr R t s S tr [ A]θt s [ B ]} σ A B ( R S )
其中，A和B分别是R和S上个数相等且可比的属性组（名称可 不相同）。AθB作为比较公式F，F的一般形式为 F1∧F2∧…∧Fn，每个Fi是形为tr[Aiθts][Bj]的公式。对于 连接条件的重要限制是条件表达式中所包含的对应属性必 须来自同一个属性域，否则是非法的，即属性的来源必须 相同。
D1 D2 Dn {(d1 , d2 , d3 , , dn ) | di Di , i 1, 2,3, , n}
其中每一个元素 (d1，d2，d3，…，dn)叫做一个n元组（n-tuple）或简称元组 （Tuple）。元素中的每一个值叫做一个分量 （Component）。
数据库原理
数据库原理
3．关系模式
实际上完整的关系模式的数学定义为： R (U、D、dom、F) 其中：R为关系模式名，U为组成该关系的属性名的集 合，D为属性组U中属性所来自的域的集合，dom为属 性向域映像的集合，F为属性间函数依赖关系的集合。 关系模式通常简写为： R (U)或R (A1，A2，A3，…，An) 其中：R为关系名，Ai (i=1,2,3,…,n)为属性名。域名构 成的集合及属性向域映像的集合一般为关系模式定义 中的属性的类型和长度。
数据库原理
2.1.4 关系数据模型的完整性约束
关系模型中共有四类完整性约束：域完 整性、实体完整性、参照完整性、用户 自定义完整性。其中实体完整性和参照 完整性是关系模型必须满足的完整性约 束条件，任何关系系统都应该能自动维 护。
图灵奖的三位获奖人
巴赫曼1924年12月11日生于堪萨斯州的曼哈顿。1948年在 密歇根州立大学取得工程学士学位，1950年在宾夕法尼亚 大学取得硕士学位。20世纪50年代在Dow化工公司工作， 1961- 1970年在通用电气公司任程序设计部门经理，19701981年在Honeywell公司任总工程师，同时兼任Cullinet软 件公司的副总裁和产品经理。 Cullinet公司对中国人来说 知之者不多，但这个公司当时在美国很有名气，它是1978 年第一家在纽约股票交易所上市的软件公司，其时微软在 新墨西哥州的阿尔伯克基开张不久，鲜为人知，它的股票 是1986年上市的，比Cullinet 晚8年之久。但Cullinet最终被 CA公司购并。1983年巴赫曼创办了自己的公司Bachman Information System，Inc.。
后来出现了文件管理系统FMS（File Management System） 作为应用程序和数据文件之间的接口，一个应用程序通过 FMS可以和若干文件打交道，在一定程度上增加了数据处 理的灵活性。但这种方式仍以分散、互相独立的数据文件 为基础，数据冗余、数据不一致性、处理效率低等问题仍 不可避免。这些缺点在较大规模的系统中尤为突出。以美 国在20世纪60年代初制定的阿波罗登月计划为例，阿波罗 飞船由约200万个零部件组成，它们分散在世界各地制造 生产。为了掌握计划进度及协调工程进展，阿波罗计划的 主要合约者Rock-well公司曾研制、开发了一个基于磁带的 零部件生产计算机管理系统，系统共用了18盘磁带，虽然 可以工作，但效率极低，18盘磁带中60%是冗余数据，维 护十分困难。这个系统的状况曾一度成为实现阿波罗计划 的重大障碍之一。
DBTG首次确定了数据库的三层体系结构，明确 了数据库管理员DBA（DataBase Administrator）的概念，规定了DBA的作用 与地位。DBTG系统虽然是一种方案而非实际的 数据库，但它所提出的基本概念却具有普遍意义， 不但国际上大多数网状数据库管理系统，如 IDMS、PRIME、DBMS、DMS 170、 DMS II和DMS 1100等都遵循DBTG模型， 而且对后来产生和发展的关系数据库技术也有很 重要的影响，其体系结构也遵循DBTG的三级模 式（虽然名称有所不同）。
数据库 关系模型
数据库关系模型数据库关系模型数据库关系模型是一种数据组织方式，它使用表格和键来描述数据之间的关系。
关系模型是现代数据库系统最常用的数据模型之一，它使用关系（表格）来表示实体和实体之间的联系。
表格中的每一行代表一个记录，每一列代表一个属性。
这些属性是具有相同数据类型的数据项集合。
关系模型中的键是一种特殊列，它用来唯一地标识表格中的每一行。
主键是一种特殊的键，它用来唯一地标识表格中的每一行，并且不能重复。
如果一个表格没有主键，则它不符合关系模型的要求。
在关系模型中，每个表格代表一个实体，每个实体都有一个或多个属性。
属性可以是数值、字符串、日期、时间或其他数据类型。
属性可以是必需的或可选的，也可以是单值的或多值的。
关系模型中有三种基本的关系：一对一关系、一对多关系和多对多关系。
一对一关系表示两个实体之间的唯一对应关系。
例如，一个人只能有一个身份证号码，一个身份证号码也只能对应一个人。
一对多关系表示一个实体可以对应多个实体，但是每个实体只能对应一个实体。
例如，一个订单可以对应多个订单项，但是每个订单项只能对应一个订单。
多对多关系表示两个实体之间的关系是多对多的。
例如，一个学生可以选修多个课程，一个课程也可以被多个学生选修。
在关系模型中，表格之间的关系可以通过外键来表示。
外键是一个表格中的列，它引用另一个表格中的主键。
外键用来确保表格之间的数据完整性和一致性。
关系模型的优点是数据结构清晰，易于理解和维护。
它还具有灵活性，可以方便地进行数据查询和分析。
缺点是不适合处理大规模数据和高并发访问。
此外，关系模型需要进行表格设计和规范化，这需要花费大量时间和精力。
数据库关系模型是一种常用的数据组织方式，它使用表格和键来描述数据之间的关系。
关系模型具有结构清晰、易于理解和维护的优点，但是不适合处理大规模数据和高并发访问。
在实际应用中，需要根据具体情况选择合适的数据模型。
数据库 关系模型02 英文
E.g., sid is a key for Students. (What about name?) The set {sid, gpa} is a superkey.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
2
Primary Key Constraints (Cont.)
Also delete all Enrolled tuples that refer to it. Disallow deletion of a Students tuple that is referred to. Set sid in Enrolled tuples that refer to it to a default sid. (In SQL, also: set an attribute to a special value null, denoting `unknown’ or `inapplicable’.)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke
10
Transactions and Constraints
CREATE TABLE Students (sid CHAR(20), name CHAR(20), CHAR(20) NOT NULL, honors PRIMARY KEY (sid), FOREIGN KEY (honors) REFERENCES Courses (cid)) CREATE TABLE Courses (cid CHAR(20), CHAR(20), cname grader CHAR(20) NOT NULL, PRIMARY KEY (cid), FOREIGN KEY (grader) REFERENCES Students (sid))
数据库原理(双语)-Chapter03
D1
…
D2 … Dn D1×D2×…×Dn
…
m1 m m2 m1 denoted as : The Cartesian product of n sets (D1,nD2, . . ., Dn) is× m2 ×… mn elements elements n={(d1, d2, . . . , dn) | d1D1, d2elementsdnDn} elements D1×D2× . . .×D D2, . . . , or Component(分量) n in D2(D2中任意一个元素) An element in Dn1(Dn1中任意一个元素) An element An element in D (D 中任意一个元素) n-tuples( nDn} the number 2of .elements in1,ad2D2,Cardinality ×D = {(d1, d , . . , dn) | d1D set: . . . , dn元组,简称元组) i=1 i
1. Relational Data Structure
Relation(关系) is a table with columns and rows (二维表). – Only applies to logical structure of the database, not the physical structure (只是逻辑结构而非物理结构). Attribute (属性) is a named column of a relation(关系的列). Domain(域) is the set of allowable values for attributes
Domain Name
postcode SW1 4EH AB2 3SU G11 9QX BS99 1NZ NW10 6EU
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
大型共享数据库的数据关系模型E.F.CoddIBM Research Laboratory,SanJose,California未来的数据库使用者一定是和数据在机器中的存储（即数据库的内部模式）相隔离的。
而通过提示服务来提供信息是一个不太令人满意的解决方法。
当数据的内部模式表示发生改变，甚至数据内部表示的多个方面发生改变时，终端用户和大多数应用程序的活动都不会受到影响。
因此，查询、更新和报告存储信息类型的自然增长和变动都需要在数据表示中表现出来。
现存的不可推断的、格式化的数据系统给用户提供了树结构的文件或者更一般的网格模式的数据。
本文在第一部分讨论这些模式的不足之处。
并且会介绍一种基于n元组关系的模式，一种数据库关系的正式形式和通用数据子句的概念。
第二部分将讨论一些关系的操作（不是逻辑层面的），并且把这些操作应用于用户模式上解决冗余和一致性问题。
1关系模式和一般模式1.1简介这篇文章是关于系统的基本关系原理的应用，这个原理提供了共享大型格式化数据库的方法。
除了Childs[1]的文章有介绍外，用于数据库系统的关系的主要应用还表现在演绎推理型的问-答系统中。
Levein和Maron[2]提供了大量关于这个领域的参考资料。
相比之下，这里要解决的问题是一些数据独立性的问题——应用程序和终端活动之于数据类型增长和数据表示变动的独立性，而数据一致性问题即使在非演绎推理型系统中也是很棘手的。
在目前流行的非推论性系统中，第一部分要介绍的数据的关系视图（或叫做模式）在一些方面似乎优于图模式和网格模式[3,4]。
这种模式提供了一种根据数据的自然结构来描述描述数据的方式——也就是说，不用为了数据的机器表示而添加其他的将结构。
因此，这种模式为高水准的数据语言提供了基础，而这种数据语言机制一方面可以达到最大化程序之间的独立性，另一方面也可以最大化数据的机器表示和组织之间的独立性。
关系模式更高一级的优势在于它构成了关系处理可导性、冗余性和一致性的坚固基础——这些将在第二部分讨论。
另一方面，网络模型产生了一些混淆，尤其是把连接的源误作为关系的源（见第二部分“连接陷阱”）最后，关系视图允许对目前格式化数据系统的范围和逻辑限制的更清晰的估算，并且有在单独的系统内竞争数据表示方式的优点（从逻辑的观点）。
更清楚的这个观点的示例会在本文中的不同部分中被阐释。
但是支持关系模式的系统实现不会讨论。
1.2目前系统的数据相关性最近发展的信息系统中数据描述表的提供是向数据独立性目标[5,6,7]靠近的重要提高。
这些表可以使改变数据库中数据表示的某些特征变得更容易些。
但是，许多数据表示特征可以在不逻辑地削弱一些应用程序的情况下被改变的功能仍受到相当的限制。
更进一步，与用户交互的数据模式仍然有一些散乱的代表性特征，特别是关于数据收集的描述（如个人名目）。
三个仍然需要提高的数据独立性的主要类型是：排序依赖，索引依赖和存取路径的依赖。
在一些系统中这些依赖之间并不是明确分隔的。
1.2.1顺序依赖。
数据库中的数据元素可以有很多种存储方式，一些是不考虑顺序的，一些是允许一个元素只参与一个排序，而另外一些允许每个元素参与多个排序。
现在让我们来看看要求或允许数据元素存储在至少一个总排序的现存系统，而这种总体排序是与硬件决定的排序地址密切相关的。
这种系统通常允许应用程序自己假定文件记录的表示顺序与其在磁盘上的存储顺序是相同的（或者说是存储排序的子目）。
这些运用文件存储顺序有利条件的应用程序，如果由于某些原因而变得需要用一个新排序替换这种顺序时，很可能不能正确运行。
以指针方式实现的存储排序也有相似的问题。
我们没有必要挑选出任何一个系统作为例子，因为现在上市的所有著名的信息系统在清楚区别表示顺序和存储顺序两方面都是失败的。
重要的实现问题必须得到解决来提供这种独立性。
1.2.2索引依赖。
格式化数据的上下文联系中，索引通常被看成数据表示的一个纯粹的效能导向组件。
它倾向于提高对查询和更新的响应，同时减慢了对插入和删除的响应。
从信息的观点来看，索引是数据表示的冗余构成成分。
如果一个系统王全用索引，并且如果它在变化活动形式的数据库环境中能够表现的很好，那么不时地产生和销毁索引的能力可能是必须的。
那么问题产生了：应用程序和终端活动在索引项来去的时候仍然能够不受影响吗？目前格式化数据系统采用很不相同的方法来进行索引。
TDMS[7]无条件地提供了所有属性上的索引。
IMS[5]目前发布的版本为用户提供了为每一文件选择的权利：是完全没有索引（层次序列的组织）和只有主键索引（层次化索引序列组织）之间的选择。
没有一种会使用户的应用逻辑依赖于无条件提供的索引的存在。
但是，IDS[8]允许文件设计者选择用于索引的属性和指定用于与索引通过外加链的方式组合成文件结构的属性。
运用索引链性能的优势的应用程序必须通过名字来引用这些链。
如果这些链后来被删除，那么这些程序就无法正确运行。
1.2.3存取路径依赖。
许多现存格式化数据系统为用户提供了树结构的文件或者更一般的数据网络模式。
为和这类系统共同工作而发展的应用程序，在树或网格的结构改变时，往往会在逻辑层受到削弱。
一个简单的例子如下。
设想数据库包含关于部件和工程的信息。
对于每一个部件，其部件号码、部件名字、部件描述、在手的数量和订单上的数量的信息都被记录。
对于每一个工程，其工程编号、工程名字和工程描述信息被记录。
无论什么时候，一个工程要用特定部件时，用于这个工程的那种部件的数量也会被记录。
假如系统要求用户或者文件创作者根据树结构声明或者定义数据。
那么，任一层次结构都可以用到如上提到的信息上（见结构1——5）。
现在考虑打印用于名为“alpha“的工程每个部件的编号、部件名和数目。
不考虑可用于面向树的信息系统可以用于解决这个问题，我们可以得到以下的发现。
如果程序P是开发用于解决这个问题（假设结构是上面五种结构中的一种），也就是说P不会检测哪一种结构对他来说有效，然而这样的结果是P至少在其中三个结构上是失败的。
更具体地，如果P对结构5行之有效，那么在其他结构上就会失败；如果P对结构3或4行之有效，那么它至少会在结构1,2,5上是失败的；如果P对结构1或2行之有效，那么它至少会在结构3,4,5上是是小的。
对于每一种情况的原因都很简单。
在没有经过检测来决定哪种结构是有效的情况下，P会失败是因为它试图引用一个不存在的文件（现可用的系统把这种情况视为error）或者是它没有引用包含它必需信息的文件。
有疑问的读者应该找一些样例程序来理解这个简单的问题。
由于在一般情况下，开发可以检测系统允许的所有树结构的应用程序是不实际的，而且这种程序在结构需要改变时也会失败。
为用户提供网格数据模式的系统也会遇到相似的问题。
在树和网格两种情形下，用户（或者是用户的程序）都被要求采用用户数据存取路径的集合。
这些路径是否与存储表示的指针定义的路径有较近通信是没有影响的，而在IDS中这种通信时极其简单的，但在TDMS中就正好相反了。
不考虑存储表示来看这种问题，结果就是，终端活动和程序变得依赖于用户存取路径的连续存在性。
对于这个问题的一个解决方案就是采用如下策略：一旦用户存取路径被定义了，那么除非所有应用这个路径的所有程序都废弃了（finish了），否则这个路径就不会过时。
由于在团体总体模式的数据库用户的存取路径的数量最终可能变得过大，因此这种策略是不实际的。
1.3数据的关系视图关系这个词在这里使用的是其被广泛认可的数学意义。
给定集合S1,S2,……,Sn（这些集合没有必要一定是不同的），如果R是一个满足如下条件的n元组集合：其每个元素的第一个元素来自S1，第二个元素来自集合S2，以此类推，那么R就是这n 个集合（S1,S2,……,Sn）上的一个关系。
我们用Sj来表示R的第j个域。
正如上面所定义，R被称作是n级的。
1级的关系通常叫做一元关系，2级的被叫做二元关系，3级的被叫做三元关系，而n级的叫n元关系。
（更简单地说，R是S1,S2,……,Sn这n个集合的笛卡尔乘积的一个子集）说明一下，我们将频繁地使用关系的数组表示，但是必须清楚的是这个特定表示并不是用于解释关系视图必须的部分。
用于表示n元关R的数组有如下特征：（1）每一行代表R的一个n元组（2）行的排列顺序是无关紧要的（3）所有行都是不相同的（4）列的顺序是有意义的——列应该符合R定义时的域的顺序S1,s2,……,Sn（但是注意，排序的域和无序的域下标之间的关系）（5）每个列的意义部分是由命名相应域来传达的图1中的例子展示了一个叫做supply 4级的关系，这个关系显示的是特定工程的特定供应者的特定数量的零件发货过程。
图1有人可能会问：如果列由相应域的名字来标识，那么为什么列的顺序会有影响呢？正如图2中例子显示的一样，两列可以有相同的头（表示同样的域），但是对于这个关系他们有不同的含义。
这里描述的关系叫做component。
它是一个三元关系，其中前两个域叫做part而第三个域叫做quantity。
Component（x，y，z）的意思就是部件x部件y的直接构成成分（或者子部件），而需要z个的x部件来组成一个的y部件。
这个关系在零件扩大问题中有重要作用。
图2一个引人注目事实是，一些现存的信息系统（主要是基于树结构文件组织）不能够为有两个或两个以上的相同域的关系提供有效地数据表示。
IMS/360[5]的目前版本就是这种系统的一个实例。
一个数据库中的总体数据可以看做一个随着时间变化的关系的集合。
这些种类的关系有各种各样的级（或度）。
随着时间的前进，每个n元关系都可能经历插入另外的n元组，删除现存的n元组和改变现存任意n元组的组成部分的操作。
但是，在很多商业、政府和科学数据库中，一些关系的度（或作级别）是相当高的（30级的关系也是很常见的）。
用户通常不能记住任何关系的所有域的顺序（例如，关系supply中定序的提供者、零件、工程和数量）。
因此，我们提出用户不必处理域排序的关系，而处理与其非排序域的有同样效果的关系的方法。
为了达到这个目的，关系中的域必须是在不采用位置时唯一可确认的，至少在某个给定的关系中是这样的。
因此，在有两个或更多相同域的地方，我们要求对每一种情况下域名都是合格的不同的角色名（rol e name），这些角色名用于识别给定的关系中的域所扮演的角色。
例如，在图2的component关系中，第一个域part可以用合格角色名sub指示，而第二个用super，以便用户能够处理component关系和它的域——sub.partsuper.part,quantity——而不用考虑这些域之间的任何排序。
总之，提出多数用户应该与由随时间变化的联系集合（而不是关系）组成的数据的关系模式交互。