翻译 大型共享数据库的数据关系模型(精选.)
大型共享数据库的数据关系模型
E.F.Codd
IBM 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——而不用考虑这些域之间的任何排序。
总之，提出多数用户应该与由随时间变化的联系集合（而不是关系）组成的数据的关系模式交互。每个用户不必知道除了关系的名字和其相应的域的名字外的其它更多信息（只要有需要就可以采用角色资格）。甚至信息可以是系统（具有安全和隐私约束）根据用户的请求以菜单形式提供的。
数据库关系模型的建立通常还有其他很多可供选择的方法。为了讨论更好的方式（或标准形式），我们必须引入另外几个概念（活动域、主码、外码、非单一域）并建立一些与目前在信息系统编程中使用的术语的链接。在本文后面的部分，我们将不再烦恼地去区别关系（relation）和联系（relationship），而在需要显示他们不同之处的地方我们会显示地指出。
下面考虑这样一个数据库实例，该数据库包含关于部件，工程和供应者的一系列关系。一个叫part的关系被定义在以下的域上：
（1）部件编号（part number）
（2）部件名称（part name）
（3）部件颜色（part col or）
（4）部件重量（part weight）
（5）在手的数量（quantity on hand）
（6）预订的数量（quantity on order）
可能还有其他的域。事实上，每个这样的域都是一池数值，这些数值中的一些或全部可以在任一瞬时在数据库中表示出来。可以想象，在某些瞬间，所有部件颜色都被显示出来，但是难以做到的是把所有可能存在的部件的重量、部件名字和部件编号都显示出来。我们称在某个时刻表现出来的值的集合为在那个时刻的活动域（active domain）。
通常，一个给定关系的一个域（或者域的组合）有一组唯一识别该关系的每一元素（n元组）的值。这样的一个域（或组合）被叫做主码（primary key）。在上面的例子中，部件号可能是一个主码，而部件颜色可能就不是了。主码是非冗余的，如果他满足它是一个简单域（非组合的）或者一个组合，而对于组合的情况，在唯一识别每一元素时参与到这个组合中的简单域没有一个是多余的（也就是组合中的所有的简单域共同构成一个唯一识别关系元素的码）。一个关系可以有多个非冗余的主码。如果上面所说的部件的名字都互不相同，那么就成了这种情况的一个实例。无论什么时候，只要一个关系有两个或者更多非冗的主码，它们中的任意一个都可以选作这个关系的主码。
一个普遍的要求就是，关系当中的元素交叉引用同一关系的其他元素或者引用一个不同关系的元素。码提供了一种用于表示这种交叉引用的面向用户的方式（但不是唯一的方式）。如果一个域（或者域组合）不是关系R的主码，但是它的元素是某个关系S的主码值（排除S和R是同一关系的可能），那么我们就把关系R的这个域（或者域组合）叫做外码。在图1supply关系中，supplier、part、project 是主码，而这三个域中每一个都被单独看作是一个外码。
在前面的工作中已经显现出一个很强的趋势，即把一个数据库中的数据看成由两个部分组成，一个部分由实体描述组成（如supplier的描述），而另一个部分由不同实体间或者实体类型间的关系组成（如supply关系）。当一个关系有任何其他关系的外码时，要维持这种区别是困难的。在用户的关系模式中，做出这样的区别似乎是没有益处的（但是，当把关系概念用于用户联系集的机器表示时，这种区分
可能有些益处）。
到目前为止，我们已经讨论了一系列定义在简单域上的关系的例子，而那些简单域的元素是原子的（非组合的）值。非原子值会在关系框架中讨论。因此，一些域可以把关系当做元素。相应地，这些关系可以被定义在非简单域等等。例如，关系empl oyee定义的其中一个域可以是salary history（薪水历史）。Salary history 域中的一个元素是一个定义在date域和salary域上的二元关系。Salary history域就是这种二元关系的一个集合。在数据库中任意瞬间都会有与empl oyee（员工）数量相同的salary history关系实例。相比之下，empl oyee关系就只有一个实例。
在表示数据库的术语中属性和重复组分别在简单域和非简单域中是大致相似的。现在术语中的多混淆之处是由于没能把类型和实例（如在“record”中）区别开和把数据的用户模式的组成和它们相应的机器表示区别开（再次以“record”为例）。
1.4标准形式
一种所有域都是简单域的关系能够用如上讨论过的二维的齐次列数组来表示其存储形式。一些更为复杂的数据结构对一个有一个或多个非简单域的关系是必要的。由于这个原因（其他的将在下面举例），消除非简单域的潜力似乎值得投资。事实上，有一种简单的消除过程，而我们把这个过程叫做标准化。
例如，考虑图3（a）显示的关系集合。Job history和children是employee关系的非简单域。Salary history是job history的一个非简单域。图3（a）中的树展示了各个非简单域之间相互关系。
图3（a）
图3（b）
标准化按如下程序进行。从关系的树顶端开始，记住它的主码，并且通过插入主码域或者域组合来扩展每个直属的下层关系。每个扩展关系的主码由从父关系（即上一层的关系）拷贝下来主码在进行扩大前的主码构成。现在，从父关系中化掉所有非简单域，删除树的顶节点，并且在留下的子树上重复同样的操作程序。
图3（a）中标准化关系集合的结果就是图3（b）中的集合。每个关系的主码都用斜体表示以显示这些码值是如何通过标准化来扩展的。
如果要使得如上所述的标准化是可用的，那么关系集合的非标准化必须满足如下条
件：
（1）非简单域之间的相互关系图是一个树集合。
（2）没有主码是由非简单域构成的
作者不知道哪个应用是不严格满足以上这些条件的。那这类标准化的更进一步的操作就可进行了。这些在本文中不会讨论。
当所有关系都以标准形式出现时，变得可行的数组表示的简单性不仅有利于存储的目的，而且有利于广泛采用不同数据表示的系统之间的大量数据的通信。这种通信形式是数组表示的一个相称的压缩版本，并且有如下有利条件：
（1）没有指针（值地址或值替换）
（2）避免了所有对哈希选址方式的依赖性
（3）不包含索引和有序列表
如果用户的关系模式以标准形式建立，那么数据库中数据项的名字可以是一种更简单的形式，反之亦然。一个通用的名字有如下形式：
R (g).r.d
其中R是关系名字；g是同辈标识符（可选的）；r是角色名（可选的）；d是域名。由于g只有在当一个给定的关系中多个同辈存在时才需要，而且r只有在当关系R有两个或更多名为d的域时才需要，所以简单形式R.d通常是恰当的。
1.5一些语言方面
如上所述，数据关系模式的采用使基于实用谓词演算的通用数据子语言的发展成为可能。如果关系结合是标准形式的，那么一阶谓词演算就足够了。这种语言为所有其它提议的数据语言提供了语言影响力的一个衡量标准，并且它自己也是嵌入（有适当的句法修改）在许多其它主流语言（编程，面向命令的或面向问题的）中的一种强势的候选者。虽然详细地描述这样一种语言不是本文的目的，但是它显著的特征有如下几点。
我们用R标记数据子语言，用H标记主语言。R允许关系及他们的域的声明。
每一个关系的声明都为这个关系确定了它的主键。声明过的关系被添加到系统资料库，从而被任何拥有合适权限的使用者群体的一员使用。H允许支持声明，这些声明可能没那么永久性的表明了这些关系在存储时时如何表示的。R允许定义数据库中的任何数据子集的检索。这样的一个检索请求之后能发生的动作受制于安全限制条件。
数据子语言的普适性是由它的描述能力决定的（而非它的计算能力），在一个大型数据库中，每一个数据子集都拥有大量的可能的（而且合理的）描述。即使我们假设（正如我们所做的）系统有权使用的、确定搜索数据合格性的功能子程序的有限集合只有一个。因此，能够应用于集规范资格表达式的集合的必须拥有对应用谓词演算的格式规范的公式集合的描述能力。众多周知，为了维护这种描述能力，不必要表示（无论选择的是什么语法）选中的谓词演算的所有公式。比如，那些以前束规范格式的就够了。
在搜索体验行业的合格性或其他方面可能要用到算术函数。这些函数用H语言定义，用R语言调用。
这样指定的一个集合可能仅用于查询，或者用于可能发生的变化。插入采用向已声明的关系中加入新的元素的形式实现，同时不考虑在机器中表示的顺序。删除对公共组都有效（而不是个人用户或子组），删除以从已声明的关系中移除元素的形式实现。如果指定关系之间的删除和更新依赖性已经用R语言声明，那么一些删除和更新可能会由其他的删除和更新引发产生。
用这种视图看数据，对查询数据的语言有一个重大的影响，这个影响就是数据元素和集合的命名。这其中的一些方面已经在上一节讨论过。使用通常的网络视图，用户常常为创造和使用更多的而不是完全有必要的关系名称所累。因为名称适合路径（或路径类型）有关，而不是和关系有关。
一旦用户意识到存储了某个特定的关系，他会希望使用他的已知参数和未知参数的任意组合来利用这个关系，因为信息（如珠穆朗玛峰）是存在的。这是一个系统特征，我们叫做（逻辑上）关系的对称利用。当然，性能上的对称性是不可能的。
为了支持一个二元关系的对称性利用，需要两条直接路径。对于一个n元的关系，被命名和控制的路径数量是n的阶乘。同样，如果采取这样的关系视图：每一个n 元关系必须被用户以只包含2元关系的一张网状表达式表示出来（比如，参见
Feldman’s LEAP系统），那么必须创造2n-1个名称而不仅仅是1.2节描述的n+1个拥有直接n元标记的名称。例如，图片1这的4元关系supply，它以n元标记初始化了5个名称，用如下形式表示
P (supplier, & (part, R (project, quantity)))
以网状二元标记，包含7个名称。
这种表示方式的进一步的缺点是它的不对称性。尽管这种不对称性不会禁止对称性利用，它肯定会使用户的一些询问操作很不方便表示（比如，对于跟给定的使用Q和R写的项目相关的那些部分和数量的查询）。
1.6可表达的、已命名的而且已存储的关系
有两个关系集合跟资料库有关：命名集和可表达集。命名集市用户群能够通过一个简单名字（或标识）识别的所有关系的集合。当恰当授权的用户声明R时，关系R拥有了命名集的成员资格。当恰当授权的用户取消R的声明时，它失去了成员资格。
可表达集是能够用数据语言中的表达式表示的所有关系的集合。这些表达式是由名字集中关系的简单名字组建起来的。阶段的名称、角色和域、逻辑连接词、谓词演算的量词以及某些常量关系符号，如= ，> 。名字集是可表达集的一个子集——通常是一个很小的子集。
由于名称集合中的某些关系可能是集合中其它关系的时间无关的组合，将名称集和定义这些时间无关的限制条件的语句的集合联系起来考虑很有用。我们将推迟讨论这个，直到我们介绍了对关系的几种操作（参看第二节）。
为用户设计一个支持关系模型的数据系统时，设计者所面临的主要问题之一是确定支持存储表示所用的集合。理想情况下，允许的数据表现形式的多样性应该正好足够覆盖性能安装总集合要求的范围。太大的范围导致不必要的存储开销和连续的对当先结构描述的重新解释。
对于任意选定的存储表示集合，数据系统必须提供把用关系模型的数据语言表达的用户需求转换成相应且有效的当前存储表示的方法。对于高层数据语言，这好似一个具有挑战性的设计问题。不过，随着更多的用户拥有了对大型资料库的访问权限，这就变成了一个必须解决的问题。同时，也能为从个人用户到数据系统提供有效的响应和吞吐量。
2冗余和兼容
2.1对关系的操作
由于关系是集合，所有普通的集合操作也都适用于关系。不过，结果可能不是一个关系，比如，一个二元关系和三元关系的连接不是一个关系。下面讨论的操作是专门针对关系的。介绍这些关系是因为它们在从其他关系中派生出关系上扮演重要角
色。它们主要应用在非推理的信息系统中，这种系统不提供逻辑推理服务，尽管当类似的服务被添加后不一定会损害它们的适用性。大多数用户不会直接关心这些操作。然而，信息系统设计人员和与资料库控制相关的人员应该彻底熟悉它们。
2.1.1置换。一个二元关系有一个具有两列的数组表示。将这两个列换位得到逆关系。
更一般的，如果一个置换被应用于一个n元关系的列，由此产生的列被称作
给定序列的排列。例如，图1中有关系supply的4！=24种排列，如果我们
包括不改变列顺序的恒等排列。
2.1.2投影。假设我们从一个关系中选出特定的某些列（剔除其它的列），然后从
结果中删除数组中的任何行重复。最终的数组表示了一个叫做给定关系的投
影的关系。
选择算子π被用来获取任何所需的排列、投影或两个操作的组合。因此，如
果L是K个标记的列表L = i1, i2, …, ik，R是一个n元关系（n>=k）,那么πL
（R）一个k元关系，这个关系的第j列是R的第ij列（j=1, 2, …,k），同时
结果的行中的冗余也将移除。考虑图1中的关系supply，图4展示了这个
关系的置换投影。注意，在这个特殊的情况下，投影比产生该投影的关系的
n元组要少。
2.1.3连接。假设给定两个二元关系，它们有一部门共同域。在什么情况下我们可以
结合这两个关系，以形成一个三元关系，其中保留了所给关系的所有信息？
图5中的例子显示了两个可以进行无信息损失连接的两个关系R,S，图6显示
了R和S的连接。如果存在一个三元关系U，满足π12（U ) = R 且π23 (U) = S.，则二元关系R和S则是可连接的。任意这样的三元关系都叫做R和S的连接。
如果R,S是二元关系且π2（R）=π1（S），则R和S是可连接的。自然连接是肯定
存在的一个连接，定义为
R*S = {(a, b, c):R(a, b) A S(b, c))
其中，如果（a,b）是R的一个成员且和S(b,c)相似，则R(a,b)的值是真。即
π12 (R*S) = R 且π23 (R*S) = S.
注意，图6中显示的连接是图5中的R和S的自然连接，图7显示了；另一个连
接。
检查这些关系展示了域part（连接操作发生的域）中的一个元素（元素1），该元素有性质：它拥有在R和S中不止一个关系。正是这个元素引起了连接的多元化。在连接域里这样的元素叫做有关R和S连接的歧义点。
如果π21（R ）或R是一个函数，在R和S的连接中不会出现歧义点。在这种情况下，R和S的自然连接就是R和S的连接。注意反复的限定“R和S”是必需的，应为S可能和S可连接（R和S 同样），而且这个连接应该完全分开考虑。在图5中，关系R，π21（R ），S，π21（S ）都不是一个函数。
R和S连接中的歧义点有时可以用其它关系消除。假设我们被给定，或者可以从R,S中产生一个关系T，关系在域project和supplier上拥有以下性质：
这样我们可能形成R,S,T的三路连接，也就是一个三从关系，如下：
这样的一个连接被叫做循环三路连接以和线性三路连接区别开来，后者将会是一个四元关系V，如下：
尽管可能存在不止一个循环三路连接（参看图8，9），这种情况可能发生的环境比2元关系的多元性要发生该情况的环境要有更严格的限制.
具体来说，关系R,S,T必须处理关于R和S连接（假设是点x），S和T 的连接（假设是y）和T和R的连接（假设是z）的歧义点。而且，更进一步，y必须是x在S下的一个关系，z是y在T下的一个关系，x是z在R下的一个关系。注意在图8中，点x=a;y=d;z=2有这个属性。
3个2元关系R,S,T的自然线性三路连接如下：
其中，因为是2元自然连接,等号左边不用圆括号。为了获取循环副本，我们引入操作符号r,它可以通过将一个n元关系的首位相连产生一个n-1元的关系。因此，如果R是一个n元关系（n>=2），R产生的环由下面的公示定义：
我们现在可以用下面的表达式表示R,S,T的自然循环三路连接：
线性概念，循环S-连接和n元关系的连接的自然副本的扩展很明显。然而，考虑到一些进行连接的关系不一定是二元的，所以可能需要一些额外的描述。考虑关系R（r元），S（s元）的情况，在它们的p个域上连接两个关系。
简单的说，假设这p个域是R的r个域中的最后p个域和S的s个域中的前p 个域。如果不是这样，我们可以总是采用适当的排列使它这样。现在，取得R 的前r-p个域的笛卡尔乘积，并且叫这个新的域为A。取得R的后p个域的笛卡尔乘积，并称之为B。取得S的后s-p个域的笛卡尔乘积，并称之为C。我们可以把R看作是在域A.B上的二元函数。类似的，我们可以把S看作是域B,C上的二元关系。线性和循环S-连接的概念现在成为可以直接接受的了。可以对线性的和各种元的n个关系的循环n元连接也采用这种方法。
2.1.4组成。读者很可能对应用在函数上的组成概念非常熟悉。我们将会讨论这个
概念的概括而且首先把它应用到二元关系上。我们对组成和可组合型的定义
是直接基于以上给出的联合和可联合性的定义上的。
假设我们被给予两个关系R,S。T是R和S的组合，如果存在一个R和S的
连接且满足。因此，当且仅当两个关系是可连接的时，它们
是可组合的。然而，存在多于一个的R和S的连接并不意味着存在多余一个
的R和S的组合。
与R与S的自然连接相应的是S伴随R的自然组成，定义为：
R?S = π13（R*S）
将关系R和S从表5中提取出来看，他们的天然组成由表10展示，而另一
个组成由表11展示（与表7展示的连接相区别）
表10. S伴随R的天然组成（由表5所得）
表11. S伴随R的另一个组成（由表5所得）
当存在2个或更多的连接时，不同的组成数量可能少至1个也可能多至与不同连接数目相同。表12展示了一个有许多连接关系但是只有一个组成的2个关系的例子。注意到在由S组成R时，点c的不确定性丢失了，因为通过点a,b,d,e 造成了确定性的关联。
表12. 多个连接，只有一个组成
多对非必须二元（可能是多维的）的关系的组成的扩展与这种关系成对连接的情况如出一辙。
对于关系组合了解的缺乏导致许多系统设计员陷入了一种我们称为连接陷阱的困境。这种陷阱可能被依照以下举例描述。假设每个供应商的描述与供应商供应的每一部分的描述相关联，并且每一部分的描述近似地与使用这些部分的工程描述相关联。通常，现在就可以得出一个错误的结论：换句话说，如果所有可能的通道通过供应商在工程中供应的部分来遵循供应商，就可以得到一个该供应商供应的所有工程的有效集。这样一个结论只有在非常特殊的情况下才是正确的，即是目标的工程和供应商关系实际上是另两个关系的自然组成——而我们通常必须加上一个词“对于所有时间”，因为这通常是在跟踪控制技术的要求中暗示到的。
*别的作者倾向于忽略组成而不是自然组成，于是把这一特别的组成看做“那个组成”——看，举个例子，Kell ey的”General Topol ogy”.
2.1.5 限制。一个关系的子集还是一个关系。关系S可能对关系R操作从而形成
一个R的子集的一种途径是通过S对R进行限制操作。这个操作是函数对子集的域的限制的一般化，它的定义如下。
设L,M为等长目录列表，L=i1,i2,……, i k，M=j1, j2,……j k其中k≤R的维数且k≤S的维数。则L,M对由S对R的限制R L|M S表示R的最小子集R’，πL（R’）= πM(S)。
这个操作只有当相等可以对于h=1,2,…,k，应用到πih(R)的成员和πjh(R)之间才被定义。
表13中R,S,R’这3个关系满足等式R’ = R(2,3)|(1,2)S。
表13. 限制举例
我们现在立足于考虑这些操作在关系上的应用。
2.2 冗余
一个指定关系集的冗余必须可以与存储陈述集的冗余相区别。在这里我们主要关心的是前者。首先，我们需要一个关于关系的可导出性的精确概念。
假设θ是关系上的一个操作集合，而且每个操作都有对每个操作数产生一个唯一关系的性质（因此自然连接是合理的，但是连接是不合理的）。如果一个关系R在所有情况下存在一个集合θ的操作序列，使R从S的一个成员中产生，则R对一个关系集合S θ-可导。“在所有情况下”这一描述是现在时的，因为我们正在处理随时间变化的关系，而且我们的兴趣在于保持一段关键时期的可导性。对于非推理性系统上的指定关系，似乎一个恰当的集合θ1包含了一下操作：投影，自然连接，束缚和限制。排列是不相干的且自然成分需要被包含，因为在进行连接然后投影的情况下是可行的。对于表示的存储集来说，一个恰当的对θ2集合的操作会包含排列和更多的关于子集合和合并关系的操作，并且排列和关联它们的元素。
2.2.1 强冗余。如果一个关系集包含了最少一个关系，这个关系控制了一个不同
于其他关系集投影的投影，我们就称这个关系集是强冗余的。以下两个例子
是为了解释为什么强冗余性是这样定义的，和证明它的实际作用。在第一个
关系系列的例子中包含了下面这个关系：
Empl oyee( serial #, name, manager#, managername)
其中serial#是主键而manager#是外键。让我们用△来指定有效域，并假设对于所有时间t满足：
△t（manager#）?△t（serial#）且△t（managername）?△t（name）这种情况下的冗余就很明显了：域managername就是不必要的。要证明这个是我们在之前定义的强冗余，我们发现
π34（employee）= π12（empl oyee）1|1π3（empl oyee）。
在第二个关系系列的例子中包含了一个描述供应商的关系S，S的主键为s#，一个关系描述部门的关系D，D的主键为d#，一个描述工程的关系J，J
的主键为j#，以及一下关系：
P（s#, d#, …），Q(s#, j#, …)，R(d#, j#, …)
其中…表示除了s#，d#, j# 的其他域。让我们假设接下来一个情况C，已知C保持时间的图理性：供应商s当且仅当他提供的工程J（关系Q）是部门
d可以被分配到的工程时(关系R)，s才将这个部门d（关系P）提供出来。然
后，我们就可以写出这个等式并因此展示出一个强冗余：
π12(P) = π12(Q)?π21(R)
强冗余存在于指定关系系列的一个重要原因是用户方便性。对此一个特别的情况是指定关系集特征关系的保持，从而从名字上涉及到它们的旧程序可以
继续正确运行。关于指定集强冗余存在性的知识使一个系统或者数据库管理员
得以在选择展示形式上有更多自由行，从而在处理当前流量时更高效。如果一
个指定集的强冗余直接被存储集的强冗余影响（或者如果其他强冗余被引入这
一存储集），那么一般来说，将会在一些查询的时间和装载中央处理器时间突
然变化的同时，消耗更多存储空间和更新时间。
2.2.2 弱冗余。第二种类型的冗余可能存在。与强冗余相反，它不是用一个等式
来描述的。如果一个关系系列包含了一个关系，这个关系包含一个无法区别
于其他成员的工程，但是这个关系对于任何时候都是一个该集合关系中其他
投影连接的投影，那么这一关系系列就是弱冗余的。
我们可以用第二个强冗余的例子（前面提到的）来展示一个弱冗余，并且假设现在状态C并不能在所有时间下保持稳定。关系π12（P），π12（Q），π12
（R）是复杂关系，在潜在的任两个关系连接的同时观点模糊的可能性时不时
产生。在这种情况下，没有一个关系可以区分于另外两个。但是，在他们之间
确实存在约束，因为每一个关系都是这3个关系循环链接的投影。其中一个
弱冗余可以用这个陈述来表现：对于所有时间，π12（P）是一个π12（Q）和π12
（R）的组合。问题的组成可能是自然的那个发生在某个瞬时而不自然的那个
发生在另一个瞬时。
通常来说，弱冗余是随着用户沟通的逻辑需要而固有出现的。他们无法被系统或数据库管理员移动。如果它们彻底出现了，那必然在指定集和存储集的
表现形式中同时出现了。
2.3 一致性
无论什么时候从什么角度看，指定的关系集都是多余的，我们应当将那个集合与一个定义了所有冗余的系列相关联，那个系列在成员关系之间保持了时间的独立性。如果那个信息系统缺少细节每个指定关系的语义信息，这是很有可能的，它就无法屯论处冗余是否适合那个指定集。这就可能在一段时间后，尝试引入冗余，但这种尝试将会失败。
给定一个随时间变化的关系系列C，一个约束申明的相关Z集合，和一个C系列的瞬间值V，我们应当把状态（C,Z,V）称为一致的或用V是否满足Z来判断不一致。比如说，给出存储关系R,S,T和一个约束申明“π12（T）是一个π12（R）和π12（S）的组合”，我们可以随着时间变化检查R,S,T满足这一约束的存储值变化情况。一个用来检测的算法可以对每个R,S,T检测最前面的两列（无论它们在系统中是以怎样的方向展示）且判定是否满足：
（1）π1（T）=π1（R）
（2）π2（T）=π2（R）
（3）对于每一组关系π12（T）中的元素组（a,c）都有一个元素b使得(a,b)在π12（R）中且（b,c）在π12（S）中。
这里在提取关系系列的瞬时状况下存在一些实际问题（我们将不在这里讨论），有些问题可能是很大且有很大变化性的。
注意到一点很重要：上面定义的一致性是一个数据库约束申明的性质，而且它对状态是怎么出现的保持独立性。因此特别地，一个用户造成的不稳定性究竟归结于一个不作为的行为还是一个委任动作都没有区别。一个简单例子的检测证明这一引向一致性的方法（可能是非正规的）的合理性。
假设被命名为C的集合包含2.2节中的例子的关系S,J,D,P,Q,R且P,Q,R在其中有强
或弱冗余被描述（现在考虑在一些特定情况下，它并不被究竟是发生了何种冗余而影响）。进一步地，假设在某个时刻t资料库的状态是保持不变的且不包含一个由供应商2号供应的工程J且该工程J被分配给部门5。因此，在π12（P）中不存在元素（2,5）。
现在，一个用户利用在P中插入一些适当元素将元素（2,5）引进π12（P）中。此时资料库的状态是不稳定的。假如插入（2，5）是正确的，且不存在一个由供应商2号供应并被分配到部门5的工程j，那么这种不稳定性有可能会被上升到一种遗漏的行为。
在这种情况下，很有可能用户的进一步工作是向对引入（2,j）、（2,5）到π12（Q）、π12（R）有影响的Q和R插入元素。另一方面，插入（2,5）可能会是错误的。这有可能是用户想要向P插入一些其他元素的情况——一个在稳定状况下插入了就能改变这种稳定状况的元素。这里的关键是系统通常没有办法在无法审查环境的情况下解决这种问题（可能是用户造成了这种不稳定性）。
当然地，让一个系统能够检测和支持不一致性有多种可能的途径。一种方式是系统在任意插入、删除、主键更新发生时都进行检测。自然地，这种检测会使操作速度减慢。
如果一个不稳定性已经形成了，细节已经被输入计算机内部，而且假设它没有被某些合理的时间间隔补救，用户或其他合理的负责安全和数据完整性的人将被通知。
2.4总结
在第一部分一个数据的关系模型被提出作为保护用户的格式化数据系统，而不因资料库增长和流量改变而引起的数据显示的潜在破坏性改变。一个正常的随时间变化而改变的关系集合被介绍。
在第2部分对关系的操作和两种类型的冗余被定义和应用到以兼容状态保存数据的问题上。随着越来越多不同种类的数据类型被集成到普通的资料库中这一定会成为一个重要的实际问题。
有很多问题被提出而且未被解决。比如说，只有一些数据子语言的更重要的属性在
1.4节中被提及。不论是语言的纯粹语法细节还是问题的实现都没有被讨论。不仅如此，
所展示的材料应该适合有经验的系统程序员去预见各种方法。同时希望这篇论文能够对格式化数据系统更精确地工作有所帮助
致谢：是IBM Poughkeepsie的C.T.Davies让作者确信的未来信息系统中数据独立性的必要性。作者希望谢谢他，还有IBM San Jose 研究实验室的F.P.Palermon, C.P.Wang, E.B.Altman, 和M.E.Senko所提供的有用的讨论。
最新文件仅供参考已改成word文本。方便更改
数据库关系模式 练习题
已知关系模式R（city, street, zip）其中city为城市编号，street为街道编号，zip为邮政编码，一个城市的一条街道只有一个邮政编码，一个邮政编码只属于一个城市。请写出R上成立的所有函数依赖及所有候选键，并说明R最高是第几范式。 现有某个应用，涉及到两个实体集，相关的属性为： 实体集R(A1,A2,A3，A4),其中，A1为码 实体集S(B1,B2,B3)，其中B1为码 从实体集R到S存在一对一的联系，联系属性是C1和C2。 1.设计相应的关系数据模型； 2.如果将上述应用的数据库设计为一个关系模式，如下： RS(A1,A2,A3,A4，B1,B2,B3,C1，C2) 这种设计是否合适并说明理由。 3.上述第2题的关系模式RS满足第二范式吗为什么 4.如果将上述应用的数据库设计为两个关系模式，如下： R1 (A1,A2,A3，A4，B1，C1，C2) R2 (B1，B2,B3) 假设存在函数依赖A2→A3，B2→B3 指出关系模式R1、R2最高满足第几范式(在1NF～BCNF之内)。 设基商业集团数据库中有商店、商品、职工三类实体。其中商店的属性有：商店编号、商店名称、地址；商品的属性有：商品号、商品名、规格、单价；职工的属性有：职工号、姓名、性别。 每个商店可销售多种商品，每种商品也可放在多个商店销售。 每个商店聘用多名职工，每名职工只能在一个商店工作。 根据上面叙述，解答以下问题： (1)设计E—R模型，要求标注连通词，可省略属性。 (2)将E—R模型转换成关系模型，标出每一个关系的主码和外码(如果存在)。 (3)写出定义参照完整性的SQL子句，要求满足“当参照表中数据更新时，外码也自动更新”。 关系模式中R（B，C，M，T，A，G），根据语义有如下函数依赖集： F={ B-C, (M,T)-- B,(M,C)-T, (M,A)-àT ,(A,B)- G } 关系模式R的码是（ D ） A. （M，T） B. （M，C） C. （M，A） D.（A，B） R的规范化程度最高达到（B ） A. 1NF B. 2NF C. 3NF D. 4NF 描述学生的关系模式r(sno，sd，mn，cno，g)，其中sno表示学号，sd表示系名，mn表示系主任姓名，cno
对象关系模型数据库解析
面向对象数据库系统（Object Oriented Data Base System，简称OODBS）是数据库技术与面向对象程序设计方法相结合的产物。 对于OO数据模型和面向对象数据库系统的研究主要体现在：研究以关系数据库和SQL为基础的扩展关系模型；以面向对象的程序设计语言为基础，研究持久的程序设计语言，支持OO模型；建立新的面向对象数据库系统，支持OO数据模型。 面向对象程序设计方法是一种支持模块化设计和软件重用的实际可行的编程方法。它把程序设计的主要活动集中在建立对象和对象之间的联系（或通信）上，从而完成所需要的计算。一个面向对象的程序就是相互联系（或通信）的对象集合。面向对象程序设计的基本思想是封装和可扩展性。 面向对象数据库系统支持面向对象数据模型（以下简称OO模型）。即面向对象数据库系统是一个持久的、可共享的对象库的存储和管理者；而一个对象库是由一个OO模型所定义的对象的集合体。 一个OO模型是用面向对象观点来描述现实世界实体（对象）的逻辑组织、对象间限制、联系等的模型。一系列面向对象核心概念构成了OO模型的基础。概括起来，OO模型的核心概念有如下一些: （1）对象（Object）与对象标识OID（Object IDentifier） 现实世界的任一实体都被统一地模型化为一个对象，每个对象有一个唯一的标识，称为对象标识（OID）。 （2）封装（Encapsulation） 每一个对象是其状态与行为的封装，其中状态是该对象一系列属性（Attribute）值的集合，而行为是在对象状态上操作的集合，操作也称为方法（Method）。 （3）类（C1ass） 共享同样属性和方法集的所有对象构成了一个对象类（简称类），一个对象是某一类的一个实例（instance）。 （4）类层次（结构） 在一个面向对象数据库模式中，可以定义一个类（如C1）的子类（如C2），类Cl 称为类C2的超类（或父类）。子类（如C2）还可以再定义子类（如C3）。这样，面向对象数据库模式的一组类形成一个有限的层次结构，称为类层次。 （5）消息（Message） 由于对象是封装的，对象与外部的通信一般只能通过显式的消息传递，即消息从外部传送给对象，存取和调用对象中的属性和方法，在内部执行所要求的操作，操作的结果仍以消息的形式返回。 OODB语言用于描述面向对象数据库模式，说明并操纵类定义与对象实例。OODB语言主要包括对象定义语言（ODL）和对象操纵语言（OML），对象操纵语言中一个重要子集是对象查询语言（OQL）。OODB语言一般应具备下述功能： （1）类的定义与操纵 面向对象数据库语言可以操纵类，包括定义、生成、存取、修改与撤销类。其中类的定义包括定义类的属性、操作特征、继承性与约束等。 （2）操作/方法的定义 面向对象数据库语言可用于对象操作/方法的定义与实现。在操作实现中，语言的命令
翻译 大型共享数据库的数据关系模型(精选.)
大型共享数据库的数据关系模型 E.F.Codd IBM Research Laboratory,SanJose,California 未来的数据库使用者一定是和数据在机器中的存储（即数据库的内部模式）相隔离的。而通过提示服务来提供信息是一个不太令人满意的解决方法。当数据的内部模式表示发生改变，甚至数据内部表示的多个方面发生改变时，终端用户和大多数应用程序的活动都不会受到影响。因此，查询、更新和报告存储信息类型的自然增长和变动都需要在数据表示中表现出来。 现存的不可推断的、格式化的数据系统给用户提供了树结构的文件或者更一般的网格模式的数据。本文在第一部分讨论这些模式的不足之处。并且会介绍一种基于n元组关系的模式，一种数据库关系的正式形式和通用数据子句的概念。第二部分将讨论一些关系的操作（不是逻辑层面的），并且把这些操作应用于用户模式上解决冗余和一致性问题。 1关系模式和一般模式 1.1简介 这篇文章是关于系统的基本关系原理的应用，这个原理提供了共享大型格式化数据库的方法。除了Childs[1]的文章有介绍外，用于数据库系统的关系的主要应用 还表现在演绎推理型的问-答系统中。Levein和Maron[2]提供了大量关于这个领域的参考资料。 相比之下，这里要解决的问题是一些数据独立性的问题——应用程序和终端活动之于数据类型增长和数据表示变动的独立性，而数据一致性问题即使在非演绎推 理型系统中也是很棘手的。 在目前流行的非推论性系统中，第一部分要介绍的数据的关系视图（或叫做模式）在一些方面似乎优于图模式和网格模式[3,4]。这种模式提供了一种根据数据的自然结构来描述描述数据的方式——也就是说，不用为了数据的机器表示而添加其 他的将结构。因此，这种模式为高水准的数据语言提供了基础，而这种数据语言机 制一方面可以达到最大化程序之间的独立性，另一方面也可以最大化数据的机器表 示和组织之间的独立性。 关系模式更高一级的优势在于它构成了关系处理可导性、冗余性和一致性的坚固基础——这些将在第二部分讨论。另一方面，网络模型产生了一些混淆，尤其是 把连接的源误作为关系的源（见第二部分“连接陷阱”） 最后，关系视图允许对目前格式化数据系统的范围和逻辑限制的更清晰的估算，并且有在单独的系统内竞争数据表示方式的优点（从逻辑的观点）。更清楚的这个观点的示例会在本文中的不同部分中被阐释。但是支持关系模式的系统实现不会讨论。 1.2目前系统的数据相关性 最近发展的信息系统中数据描述表的提供是向数据独立性目标[5,6,7]靠近的重要提高。这些表可以使改变数据库中数据表示的某些特征变得更容易些。但是，许 多数据表示特征可以在不逻辑地削弱一些应用程序的情况下被改变的功能仍受到相 当的限制。更进一步，与用户交互的数据模式仍然有一些散乱的代表性特征，特别
面向对象数据模型
第三节面向对象数据模型 1、传统数据模型存在的主要问题 已于前述，目前非空间数据最主要的数据模型是层次模型、网状模型和关系模型。这里，我们分别介绍它们用于GIS地理数据库的局限性 (1)层次模型用于GIS地理数据库的局限性 层次模型反映了地理世界中实体之间的层次关系，在描述地理世界中自然的层次结构关系时简单、直观，易于理解，并在一定程度上支持数据的重构。它用于GIS地理数据库存在的主要问题是： 1）、很难描述复杂的地理实体之间的联系，描述多对多的关系时导致物理存储上的冗余； 2）、对任何对象的查询都必须从层次结构的根结点开始，低层次对象的查询效率很低，很难进行反向查询； 3）、数据独立性较差，数据更新涉及许多指针，插入和删除操作比较复杂，父结点的删除意味着其下层所有子结点均被删除； 4）、层次命令具有过程式性质，要求用户了解数据的物理结构，并在数据操纵命令中显式地给出数据的存取路径； 5）、基本不具备演绎功能和操作代数基础。 (2)网状模型用于GIS地理数据库的局限性 网状模型是层次模型的一般形式，反映了地理世界中常见的多对多关系，在一定程度上支持数据的重构，具有一定的数据独立和数据共享特性，且运行效率较高。用于GIS地理数据库的主要问题如下： 1）、由于网状结构的复杂性，增加了用户查询的定位困难，要求用户熟悉数据的逻辑结构，知道自己所处的位置； 2）、网状数据操作命令具有过程式性质，存在与层次模型相同的问题； 3）、不直接支持对于层次结构的表达； 4）、基本不具备演绎功能和操作代数基础。 (3)关系模型用于GIS地理数据库的局限性
关系模型表示各种地理实体及其间的关系，方式简单、灵活，支持数据重构；具有严格的数学基础，并与一阶逻辑理论密切相关，具有一定的演绎功能；关系操作和关系演算具有非过程式特点。尽管如此，关系模型用于GIS地理数据库也还存在一些不足。主要问题是： 1）、无法用递归和嵌套的方式来描述复杂关系的层次和网状结构，模拟和操作复杂地理对象的能力较弱； 2）、用关系模型描述本身具有复杂结构和涵义的地理对象时，需对地理实体进行不自然的分解，导致存储模式、查询途径及操作等方面均显得语义不甚合理； 3）、由于概念模式和存储模式的相互独立性，及实现关系之间的联系需要执行系统开销较大的联接操作，运行效率不够高。 不难看出，关系模型的根本问题是不能有效地管理复杂地理对象。 2、面向对象的概念 面向对象的基本概念是在本世纪70年代萌发出来的，它的基本做法是把系统工程中的某个模块和构件视为问题空间的一个或一类对象。到了80年代，面向对象的方法得到很快发展，在系统工程、计算机、人工智能等领域获得了广泛应用。但是，在更高级的层次上和更广泛的领域内对面向对象的方法进行研究还是90年代的事。 (1)基本思想和基本概念 面向对象的基本思想是通过对问题领域进行自然的分割，用更接近人类通常思维的方式建立问题领域的模型，并进行结构模拟和行为模拟，从而使设计出的软件能尽可能地直接表现出问题的求解过程。因此，面向对象的方法就是以接近人类通常思维方式的思想，将客观世界的一切实体模型化为对象。每一种对象都有各自的内部状态和运动规律，不同对象之间的相互联系和相互作用就构成了各种不同的系统。 在面向对象的方法中，对象、类、方法和消息是基本的概念。 对象——含有数据和操作方法的独立模块，可以认为是数据和行为的统一体。如一个城市、一棵树均可作为地理对象。对于一个对象，应具有如下特征： ·具有一个唯一的标识，以表明其存在的独立性； ·具有一组描述特征的属性，以表明其在某一时刻的状态； ·具有一组表示行为的操作方法，用以改变对象的状态。
2015数据库复习题答案
(说明：仅仅代表个人观点，答案正确率为98%，可能会有错的地方，有问题请问度娘) 复习参考资料 选择题:30分（15题） 名词解释：20分（4题） 综合题：50分 一、选择题： 1. 数据库系统是采用了数据库技术的计算机系统，数据库系统由数据库、数据库管理系统、应用系统和（C）。 A. 系统分析员 B. 程序员 C. 数据库管理员 D. 操作员 2. 数据库（DB），数据库系统（DBS）和数据库管理系统（DBMS）之间的关系是（A）。 A. DBS包括DB和DBMS B. DBMS包括DB和DBS C. DB包括DBS和DBMS D. DBS就是DB，也就是DBMS 3. 下面列出的数据库管理技术发展的三个阶段中，没有专门的软件对数据进行管理的是（D）。I．人工管理阶段II．文件系统阶段III．数据库阶段 A. I 和II B. 只有II C. II 和III D. 只有I 4. 下列四项中，不属于数据库系统特点的是（C ）。 A. 数据共享 B. 数据完整性 C. 数据冗余度高 D. 数据独立性高 5. 数据库系统的数据独立性体现在（B）。 A. 不会因为数据的变化而影响到应用程序 B. 不会因为数据存储结构与数据逻辑结构的变化而影响应用程序
C. 不会因为存储策略的变化而影响存储结构 D. 不会因为某些存储结构的变化而影响其他的存储结构 6. 描述数据库全体数据的全局逻辑结构和特性的是（A ）。 A. 模式 B. 内模式 C. 外模式 D. 以上三种 7. 要保证数据库的数据独立性，需要修改的是（C）。 A. 模式与外模式 B. 模式与内模式 C. 三级模式之间的两层映射 D. 三层模式 8. 要保证数据库的逻辑数据独立性，需要修改的是（A）。 A. 模式与外模式之间的映射 B. 模式与内模式之间的映射 C. 模式 D. 三级模式 9. 用户或应用程序看到的那部分局部逻辑结构和特征的描述是（C）模式。 A. 模式 B. 物理模式 C. 子模式 D. 内模式 10. 下述（D）不是DBA数据库管理员的职责。 A. 完整性约束说明 B. 定义数据库模式 C. 数据库安全 D. 数据库管理系统设计 11. 概念模型是现实世界的第一层抽象，这一类模型中最著名的模型是（D ）。 A. 层次模型 B. 关系模型 C. 网状模型 D. 实体-关系模型 12. 区分不同实体的依据是（B ）。 A. 名称 B. 属性 C. 对象 D. 概念 13. 关系数据模型是目前最重要的一种数据模型，它的三个要素分别是（B ）。 A. 实体完整性、参照完整性、用户自定义完整性 B. 数据结构、关系操作、完整性约束 C. 数据增加、数据修改、数据查询 D. 外模式、模式、内模式 14. 在（A ）中一个结点可以有多个双亲，结点之间可以有多种联系。 A. 网状模型
关系数据库理论练习题
一、选择题 1.为了设计出性能较优的关系模式，必须进行规范化，规范化主要的理论依据是（）。 A.关系规范化理论 B.关系代数理论 C．数理逻辑 D.关系运算理论 2.规范化理论是关系数据库进行逻辑设计的理论依据，根据这个理论，关系数据库中的关系必须满足：每一个属性都是（）。 A.长度不变的 B.不可分解的 C．互相关联的 D.互不相关的 3.已知关系模式R（A，B，C，D，E）及其上的函数相关性集合F＝{A→D，B→C，E→A}，该关系模式的候选关键字是（）。 A.A B B.B E C.C D D.D E 4.设学生关系S（S N O，S N A M E，S S E X，S A G E，S D P A R T）的主键为S N O，学生选课关系S C（S N O，C N O，S C O R E）的主键为S N O和C N O， 则关系R（S N O，C N O，S S E X，S A G E，S D P A R T，S C O R E）的主键为S N O和C N O，其满足（）。 A.1N F B.2N F C.3N F D.B C N F 5.设有关系模式W（C，P，S，G，T，R），其中各属性的含义是：C表示课程，P表示教师，S表示学生，G表示成绩，T表示时间，R表示教室，根据语义有如下数据依赖集：D={C→P，（S，C）→G，（T，R）→C，（T，P）→R，（T，S）→R}，关系模式W的一个关键字是（）。 A.（S，C） B.（T，R） C.（T，P） D.（T，S） 6.关系模式中，满足2N F的模式（）。 A.可能是1N F B.必定是1N F C.必定是3N F D.必定是B C N F 7.关系模式R中的属性全是主属性，则R的最高范式必定是（）。 A.1N F B.2N F C.3N F D.B C N F 8.消除了部分函数依赖的1N F的关系模式，必定是（）。 A.1N F B.2N F C.3N F D.B C N F 9.如果A－>B,那么属性A和属性B的联系是（）。 A.一对多 B.多对一 C．多对多 D.以上都不是 10.关系模式的候选关键字可以有1个或多个，而主关键字有（）。 A.多个 B.0个 C.1个 D.1个或多个 11.候选关键字的属性可以有（）。 A.多个 B.0个 C.1个 D.1个或多个 12.关系模式的任何属性（）。 A.不可再分 B.可以再分 C.命名在关系模式上可以不唯一 D.以上都不是 13.设有关系模式W（C，P，S，G，T，R），其中各属性的含义是：C表示课程，P表示教师，S表示学生，G表示成绩，T表示时间，R表示教室，根据语义有如下数据依赖集：D={C→P，（S，C）→G，（T，R）→C，（T，P）→R，（T，S）→R}，若将关系模式W分解为三个关系模式W1（C，P），W2（S，C，G），W2（S，T，R，C），则W1的规范化程序最高达到（）。 A.1N F B.2N F C.3N F D.B C N F 14.在关系数据库中，任何二元关系模式的最高范式必定是（）。 A.1N F B.2N F C.3N F D.B C N F 15.在关系规范式中，分解关系的基本原则是（）。 I.实现无损连接 I I.分解后的关系相互独立 I I I.保持原有的依赖关系 A.Ⅰ和Ⅱ B.Ⅰ和Ⅲ C.Ⅰ D.Ⅱ 16.不能使一个关系从第一范式转化为第二范式的条件是（）。 A.每一个非属性都完全函数依赖主属性
自考数据库系统原理 第九章 数据库技术的发展 课后习题答案
自考数据库系统原理第九章数据库技术的发展课后习题答案 2009-09-15 10:51 9.1 名词解释 （1）OODBS：是指面向对象数据库系统，它既具数据库管理的基本功能，又能支持面向对象的数据模型。 （2）ORDBS：基于对象关系数据模型的DBS称为对象关系数据库系统（ORDBS）。 （3）平面关系模型：传统的关系模型称为“平面关系模型”，它要求关系模式具有第一范式(1NF)性质，关系具有规范化的结构。也就是规定属性值是不可分解的，即不允许属性值具有复合结构(元组或关系)。 （4）嵌套关系模型：是从平面关系模型发展而成的。它允许关系的属性值又可以是一个关系，而且可以出现多次嵌套。嵌套关系突破了1NF的定义框架，是“非1NF关系”。 （5）复合对象模型：在嵌套关系模型上进一步放宽要求。在关系定义上，集合与元组不再有交替出现的严格限制，此时的关系中，属性类型可以是基本数据类型、结构类型(元组类型)或集体类型(即关系类型)。 （6）数据的泛化/细化：是对概念之间联系进行抽象的一种方法。当在较低层上的抽象表达了与之联系的较高层上抽象的特殊情况时，就称较高层上抽象是较低层上抽象的"泛化"，而较低层上抽象是较高层上抽象的"细化"。 （7）对象关系模型：在传统关系数据基础上，提供元组、数组、集合等更为丰富的数据类型及处理新数据类型操作的能力而形成的数据模型。(注：传统关系模型只支持字符、数值、字串，布尔值等等基本数据类型及其处理功能) （8）类型级继承性：当继承性发生在类型级时，子类型继承了超类型的属性。也就是说，超类型所具有的属性，在子类上也具有。 （9）表级继承性：继承性也可发生在表级，(就是元组集合上发生继承)，子表继承超表全部属性，超表中每个元组最多可以与子表中一个元组对应，而子表中的每个元组在超表中恰有一个元组对应，并在继承的属性值上具有相同的值。 （10）引用类型：数据类型可以嵌套定义，在嵌套引用时，不是引用对象本身，而是个用对象标识符(即指针)，这种指针被称为引用类型。 （11）对象：客观世界中的实体经过抽象称为问题空间中的对象，它是对一组信息及其操作的描述。 （12）类：是具有相同的变量名和类型、相同的消息和使用方法的对象的集合。 （13）单重继承性：一个子类继承某一个超类的结构和特性，称为单重继承性。 （14）多重继承性：一个子类继承多个超类的结构和特性，称为多重继承性。 （15）对象标识：在面向对象语言中，对象标识是一个指针一级的概念，在对象创建的瞬间，由系统赋给每个对象一个“标识”,即系统内的一个唯一的指针，在对象生存期内，这个标识不可改变。 （16）对象包含：不同类的对象之间存在的包含关系称为对象包含。包含是一种“一部分”(is part of)的联系。 （17）类继承层次图：表示类继承关系的图，由超类名、子类名和一组线条自上而下有序的表示。（18）类包含层次图：表示对象包含关系的图，由一些具有包含关系的对象和线条自上而下表示(下方的对象为其连线所指上方对象的一部分)。 （19）持久数据：是指创建这些数据的程序运行终止后数据依然存在于系统之中。数据库中的关系就是持久数据。 （20）持久对象：程序运行结束后，被保留下来的对象称为持久对象。 （21）持久指针：持久指针可看作是数据库中指向对象的指针。持久化指针不像内存中的指针，
数据库系统2-1：关系模型及其描述
数据库系统2-1：关系模型及其描述 关系数据库以其坚实的数学理论基础、严密的逻辑结构和简单明了的表示方式深得广大用户的青睐，目前已经占据数据库系统的市场，成为应用最为广泛的数据处理工具。 数据模型主要描述两类信息:一是实体；二是实体之间的联系。在层次、网状模型中，实体之间的联系是通过指针来实现的，而在关系模型中，实体之间的联系是通过二维表中公共属性值建立起来的联系来实现的。 关系数据库系统是支持关系数据模型的数据库系统，即以关系模型为基础而构建起来的数据库系统。关系数据模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。 １．关系数据结构 在关系模型中，现实世界中的实体和实体之间的联系都用单一的关系来描述，这些关系的逻辑结构非常简单，就象人们日常所熟悉的二维表。 ２．关系操作 关系模型是集合操作方式，操作对象和结果都是集合，称为“一次一集合”。 关系操作有三种不同的描述方式：关系代数、关系演算和结构化查询语言SQL。 关系代数是一种抽象的查询语言，它是用集合论中的关系运算来表达查询要求的方式。关系演算是以数理逻辑中的谓词演算来表达查询要求的方式，它又可分为元组关系演算和域关系演算。若在关系演算中，谓词变元的基本对象是元组变量，则称之为元组关系演算；若谓词变元的基本对象是域变量，则称之为域关系演算。 SQL是介于关系代数和关系演算之间的查询语言。这种语言除具有数据查询功能之外，还具有数据定义DDL和数据控制DCL等功能，是集数据查询、数据定义、数据操纵、数据控制于一体的关系数据语言。是关系数据库的标准语言。 ３．关系的完整性约束 数据的完整性约束是指在给定的数据模型中，数据及其联系所遵守的一组通用的完整性规则，以确保数据库中数据的一致性和正确性。在关系模型中允许定义三类完整性约束：实体完整性、参照完整性和用户自定义完整性。 【
对象关系在模型中的实现案例
对象关系在模型中的实现案例 —基础软件部吴春云一、案例介绍： 在一个项目中，存在多个业务对象，各个业务对象间存在各种关系。从结构上来看，对象关系可以分为依赖、继承、关联、聚合、组合，从数量上来看，对象关系可以分为一对一、一对多、多对多。本案例主要介绍如何在开发中通过代码来表示对象间的各种关系，并基于这种关系进行前后端数据交互及持久化。 二、关系的概念及实现： 1.结构关系 1.1继承 继承指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力。所以继承关系，确切的说是类与类之间的关系，但是对象又是类的实例，所以就这个角度理解为对象之间的关系，例如父与子的关系，动物与狗的关系，汽车与大众的关系等。 工作流结构部分的实体类:SysNode（环节）、SysTransactNode （办理环节）、SysActivityNode（活动环节）、SysDecisionNode（决策环节）应用了这种继承关系，使得子类拥有了父类环节中的属性，但子类本身代码大大简化，结构清晰。 public class SysTransactNode extends SysNode{}
public class SysActivityNode extends SysTransactNode{} public class SysDecisionNode extends SysTransactNode{} 1.2依赖 依赖就是一个对象A使用到了另一个对象B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是对象B的变化会影响到对象A。比如某人要过河，需要借用一条船，此时某人与一条船之间的关系就是依赖。表现在代码层面，一般指由局部变量、返回值建立的对于其他对象的调用关系，如对象B作为参数被对象A在某个方法中使用。 1.3关联 关联体现的是两个类之间语义级别的一种强依赖关系，这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的。关联可以是单向、双向的。表现在代码层面，为被关联类B以类的属性形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量。 1.4聚合 聚合是关联关系的一种特例，它体现的是整体与部分的关系，即has-a的关系。此时整体与部分之间是可分离的，它们可以具有各自的生命周期，部分可以属于多个整体对象，为多个整体对象共享，比如计算机与CPU、公司与员工的关系等。表现在代码层面，和关联关系是一致的，只能从语义级别来区分。 1.5组合 组合也是关联关系的一种特例，它体现的是一种contains-a的
王珊《数据库系统概论》课后习题(对象关系数据库系统)【圣才出品】
第15章对象关系数据库系统 1．定义并解释OO模型中以下核心概念：对象与对象标识、封装、类、类层次。 答：（1）对象 是由一组数据结构和在这组数据结构上的操作的程序代码封装起来的基本单位。对象通常与实际领域的实体对应。一个对象包括属性集合和方法集合。 （2）对象标识OID 面向对象数据库中的每个对象都有一个唯一的不变的标识称为对象标识（OID）。对象标识具有永久持久性，即一个对象一经产生系统就会赋于一个在全系统中唯一的对象标识符，直到它被删除。 （3）封装 每一个对象是其状态与行为的封装，其中状态是该对象一系列属性值的集合，而行为是在对象状态上操作的集合，操作也称为方法。 （4）类 共享同样属性和方法集的所有对象构成了一个对象类简称类。 （5）类层次 在一个面向对象数据库模式中，可以定义一个类（如C1）的子类（如C2），类C1称为类C2的超类（或父类）。子类（如C2）还可以再定义子类（如C3）。这样，面向对象数据库模式的一组类形成了一个有限的层次结构，称为类层次。 2．OO模型中对象标识与关系模型中的“码”有什么区别？
答：对象标识具有永久持久性。一个对象一经产生，系统就给它赋予一个在全系统中惟一的对象标识符，直到它被删除。对象标识是由系统统一分配的，用户不能对对象标识符进行修改。对象标识是稳定的，独立于值的，它不会因为对象中某个值的修改而改变。 关系模型中的“码”是值标识，不具有永久持久性，只具有程序内持久性。码是由用户建立的，用来区分关系的不同元组。 3．什么是单继承？什么是多重继承？继承性有什么优点？ 答：（1）单继承是指一个子类只能继承一个超类的特性（包括属性、方法和消息）；多重继承是指一个子类能继承多个超类的特性。 （2）继承性的优点有以下两点： ①它是建模的有力工具，提供了对现实世界简明而精确的描述； ②它提供了信息重用机制。子类可以继承超类的特性，可以避免许多重复定义。
数据库系统原理与设计(第2版) 万常选版 第2章 关系模型与关系代数 课后答案(完整资料).doc
【最新整理，下载后即可编辑】 3.简述如下概念，并说明它们之间的联系与区别:。 （1）域，笛卡尔积，关系，元组，属性 答：域：域是一组具有相同数据类型的值的集合。 笛卡尔积：给定一组域D1，D2，…，Dn，这些域中可以有相同的。这组域的笛卡尔积为：D1×D2×…×Dn＝｛（d1，d2，…，dn）｜di?Di，i＝1，2，…，n ｝其中每一个元素（d1，d2，…，dn）叫作一个n元组（n-tuple）或简称元组（Tuple）。元素中的每一个值di叫作一个分量（Component）。 关系：在域D1，D2，…，Dn上笛卡尔积D1×D2×…×Dn的子集称为关系，表示为 R（D1，D2，…，Dn） 元组：关系中的每个元素是关系中的元组。 属性：关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。由于域可 以相同，为了加以区分，必须对每列起一个名字，称为属性（Attribute）。 （2）超码，主码，候选码，外码 答：超码：对于关系r的一个或多个属性的集合A，如果属性集A可以唯一地标识关系r中的一个元组，则称属性集A为关系r的一个超码(superkey) 。 候选码：若关系中的某一属性组的值能唯一地标识一个元组，则称该属性组为候选码（Candidate key）。 主码：若一个关系有多个候选码，则选定其中一个为主码（Primary key）。 外码：设F是基本关系R的一个或一组属性，但不是关系R 的码，如果F与基本关系S的主码Ks相对应，则称F是基本关系R的外码（Foreign key），简称外码。 基本关系R称为参照关系（Referencing relation），基本关系S 称为被参照关系（Referenced relation）或目标关系（Target relation）。关系R和S可以是相同的关系。 (3)关系模式，关系，关系数据库
数据库关系数据例题
作业1： 已知关系模式R
对象关系模型数据库
对象数据库关系数据库 我们将对象数据库管理系统（）定义为一个集成了数据库能力与面向对象编程语言能力地数据库管理系统（），使数据库对象看起来像是已有地一个或多个程序设计语言中地程序设计语言以象.——，委员会主席. 在多用户客户机服务器环境中提供了持久性存储器.可以处理对象地并行访问，提供锁定和事务保护，保护对象存储器免遭各种类型地威胁，照管像备份和恢复之类传统任务.这所以与关系数据库不同，是因为存储地是对象，而不是表格.对象地引用通过持久性标识（）进行，可以独一无二地识别各个对象，可以用来在对象之间建立标记和容器关系.还加强了封装，支持继承.结合了对象属性和传统地功能，如锁定、保护、事务处理、查询、版式本、并发和持久性.文档来自于网络搜索 不是利用分离地语言（如）定义、检索和处理数据，而是利用类定义和传统地面向对象地程序语言（通常是、和语言）构造来定义和访问数据.只来过是存储器内语言数据结构地多用户、持久性扩展.换句话说，客户就是或是程序，服务器就是——没有像和这样地可视中间对象.将数据库能力直接集成进语言.文档来自于网络搜索 地价值.很显然，最好是以自然地形式存储那些对象，而不是将数据修饰得光光滑滑或撕得七零八落之后放进关系表格中.文档来自于网络搜索 对于那些数据复杂难以在表格里简单排列地用户来说，特别适合.曾经长期是学者和研究人员极为感兴趣地领域.最早地商品化出现在年，是公司（现在地公司）和公司推出地.后来（九十年代）（）、、、、、、和等公司也加入了这个开拓行列.这些厂商首先瞄准了那些复杂数据结构和长命期事务处理地应用程序——包括计算机辅助设计、和智能办公室等.随着多媒体、群件、公布式对象和万维网技术地出现，与那些深奥难懂地特性现在变成了客户机服务器系统地主流要求.技术填补关系数据库最弱地那些空隙——复杂数据、版式本和长生命期事务、持久性对象存储、继承和用户定义地数据类型等等.文档来自于网络搜索 以下是厂商开拓地各个特性： 自由创建新地信息类型 快速存取 组合结构地灵活视图 与面向对象地程序语言紧密集成 利用多继承支持可定制地信息结构 支持版本事务、嵌套事务和长生命期事务 分布式对象储库 支持复合对象地生命期管理 对象狂已经掌握了整个行业.面向对象技术支持者正在宣告，对象关系数据库和将成为医治关系技术地所谓弱点地良药.这纯属胡说……在数据库上直接地和不加区分地就应用面向对象技术，将再次引入关系数据库花了二十年才克服地那些问题.文档来自于网络搜索 在用户中间，很少有人会怀疑最终将成为地后继技术.在诗人地比喻中，年轻地革命上帝已经开始衰老，变成冷冰冰地暴君——戒律和标准地守护人.文档来自于网络搜索 我们可以两者兼得.要点是将这两项技术结合起来，而不是相互扔泥块.对二十多处踏踏实实地关系数据库研究地开发熟视无睹，不加以利用，就不太应该了.文档来自于网络搜索 和都承认目前地数据库实现有缺点；但他们两人都有觉得关系模型本身能够处理将解决地那些问题，有能力，可以利用嵌套关系、域（或用户定义地数据封装类型）以及一种比更强大地面向集合语言在关系技术世界里近似.这些特性完成这项工作，无需追逐对象指针或操纵低级地专用语言记录结构.没有必要减轻关系理论地联合能力.开发者没有必要退回到用手工方法去最佳化或重新优化应用程序地性能——将时钟倒拔回去了.认为域和对象是同一回
面向对象的关系数据库设计
面向对象的关系数据库设计 2007-11-23 21:29 一、概念的区分 有些人把面向对象的数据库设计(即数据库模式)思想与面向对象数据库管理系统(OODBMS) 理论混为一谈。其实前者是数据库用户定义数据库模式的思路,后者是数据库管理程序的思路。用户使用面向对象方法学可以定义任何一种DBMS数据库,即网络型、层次型、关系型、面向对象型均可,甚至文件系统设计也照样可以遵循面向对象的思路。 面向对象的思路或称规范可以用于系统分析、系统设计、程序设计,也可以用于数据结构设计、数据库设计。OOSE自上至下、自始至终地贯彻面向对象思路,是一个一气呵成的统一体。面向对象的数据库设计只是 OOSE 的一个环节。 二、数据库设计的重要性 一般数据库设计方法有两种,即属性主导型和实体主导型。属性主导型从归纳数据库应用的属性出发,在归并属性集合(实体)时维持属性间的函数依赖关系。实体主导型则先从寻找对数据库应用有意义的实体入手,然后通过定义属性来定义实体。一般现实世界的实体数在属性数 1/10 以下时,宜使用实体主导型设计方法。面向对象的数据库设计是从对象模型出发的,属于实体主导型设计。 一般数据库应用系统都遵循以下相关开发步骤: 1 、设计应用系统结构; 2 、选择便于将应用程序与 DBMS 结合的DBMS体系结构,如RDBMS; 3 、根据应用程序使用的环境平台,选择适宜的DBMS(如Oracle)和开发工具(如PB); 4 、设计数据库,编写定义数据库模式的SQL程序; 5 、编写确保数据正确录入数据库的用户接口应用程序; 6 、录入数据库数据; 7 运行各种与数据库相关的应用程序,以确认和修正数据库的内容。 对以上各步骤,有几点需要说明: (1) 这不是瀑布模型,每一步都可以有反馈。以上各步不仅有反馈、有反复,还有并行处理。 比如一些库表在数据录入时,另一些库表设计还在修改。 这与我们的递增式开发方法有关,也与面向对象的特征有关。 (2) 上述顺序不是绝对的,大多数场合是从第三步开始的。 (3) 对大多数数据库应用系统来说,上述各步中最重要、最困难的不是应用系统设计而是数据库设 三、DBMS的支持和数据库设计 很多数据库应用系统开发者不重视数据库设计的原因是:他们太迷信DBMS,认为购入一个功能强大的 DBMS后数据库设计就不困难、不重要了。一些国内外的数据库教材常常是在为DBMS的开发厂商做宣传,而很少站在数据库用户角度,从数据库应用系统出发介绍数据库设计方法。结果往往使读者搞不清书中介绍的是数据库管理程序的设计思想,还是应用这种 DBMS 进行数据库设计的思想。 其实,DBMS只是给用户为已采用的数据库提供一个舞台,而是否使用这个舞台上
数据模型及关系数据模型的基本组成内容
什么是数据模型什么是数据模型？？请给出关系数据模型的基本组成内容请给出关系数据模型的基本组成内容。。 答：数据（data ）是描述事物的符号记录。模型（Model)是现实世界的抽象。数据模型（Data Model ）是数据特征的抽象，是数据库管理的数学形式框架。数据库系统中用以提供信息表示和操作手段的形式构架。数据模型包括数据库数据的结构部分、数据库数据的操作部分和数据库数据的约束条件。关系数据模型把概念模型中实体以及实体之间的各种联系均用关系来表示。从用户的观点来看，关系模型中数据的逻辑结构是一张二维表，它由行列构成。每一个关系用一张二维表来表示，常称为表。每一个关系表都有个区别于其他关系表的名字，称关系名。关系是概念模型中同一类实体以及实体之间联系集合的数据模型表示。二维表中的每一列即为一个属性，每个属性都有一个显示在每一列首行的属性名。在一个关系表当中不能有两个同名属性。关系中每个属性的值是有一定变化范围的。每一个属性所对应的变化范围叫做属性的变域或简称域，它是属性值的集合，关系中所有属性的实际取值必须来自于它对应的域。二维表中的每一行数据总称为一个元组或记录。一个元组对应概念模型中一个实体的所有属性值的总称。由若干个元组就可构成一个具体的关系，一个关系中不允许有两个完全相同的元组。在关系数据库中，对每个指定的关系经常需要根据某些属性的值来唯一的操作一个元组，也就是要通过某个或某几个属性来唯一的标识一个元组，我们把这样的属性或属性组称为指定关系的关键字。关系运算：并、交、差、选择、连接、投影。关系数据模型的基本理论不但对关系模型的结构进行了严格的定义，而且还有一组完整的数据约束规则，它规定了数据模型中的数据必须符合的某种约束条件。在定义关系数据模型和进行数据操作时都必须保证符合约束。关系模型中共有四类完整性约束：域完整性、实体完整性、参照完整性、用户自定义完整性。其中实体完整性和参照完整性是关系模型必须满足的完整性约束条件，任何关系系统都应该能自动维护。
数据库关系数据模型
第3章关系数据模型 3.1 关系数据模型和关系数据库 关系模型由三部分组成： ·数据结构 ·操作集合 ·完整性约束 这三部分也称为关系模型三要素。 3.1.1 数据结构 ·关系数据模型用二维表来组织数据。 ·这个二维表在关系数据库中就称为关系。 ·关系数据库就是表或者说是关系的集合。 ·表是逻辑结构而不是物理结构。 3.1.2 数据操作 关系数据模型中的操作包括： ·传统的关系运算：并、交、差、广义笛卡尔乘积； ·专门的关系运算：选择、投影、连接、除; ·有关的数据操作：查询、插入、删除、更改。 操作特点 ·关系模型中操作的数据以及查询的结果都是完整的集合（或表）， ·这些集合可以只包含一行数据，也可以是不包含任何数据的空集合。 ·非关系模型数据库中典型的操作是一次一行或一次一个记录。 ·集合处理能力是关系系统区别于其他系统的重要特征。 关系模型与非关系模型区别 ·在非关系模型中，各个数据记录之间是通过指针等方式连接的，当要定位到某条记录时，需要用户自己按指针的链接方向逐层查找——导航。 ·在关系模型中，用户只需指定数据的定位条件，数据库管理系统就可以自动定位到该数据记录——非导航。 关系操作 关系模型的数据操作主要包括： 查询、插入、删除、更改 关系数据库中的信息表示方式：表中的行列位置有明确的值——逻辑层。 关系数据库的物理层 关系数据库在物理层也使用指针，但这些物理层的存储细节对用户来说都是不可见的，用户所看到的物理层实际上就是存放数据的数据库文件: ·文件名 ·存放位置 ·关系语言特点 关系操作是通过关系语言实现的，关系语言的特点是高度非过程化： 用户不必关心数据的存取路径和存取过程，只需要提出数据请求，DBMS会自动完成用户请求的操作；
数据库表关系模型解析1——概述
数据库模型解析 代码生成器是一款为程序员设计的辅助工具，是一个软件项目智能开发的平台，它可以自动生成https://www.wendangku.net/doc/1c11096486.html,页面及后台代码。 实践开发过程中，我们使用PowerDesigner设计数据库模型。代码生成器就是读取PowerDesigner设计的数据库模型，分析其中的表与表之间的关系模型，分析其中的表和字段的说明信息中的关键字，自动生成不同的页面。 对于一对一的数据模型，暂时没有找到比较好的业务需求，欢迎大家多多探讨，给出形式业务需求，最好能给出页面展示形式，在此谢过。 以下的设计思路在2.0中大部分已经得到体现，在3.0版本（9月19号正式发布）中会完全体现，谢谢大家这么久的支持。 表与表之间的关系模型包括： 1.单表数据模型 2.自连接数据模型 3.一对多数据模型 4.一对多数据模型中的一张表是自连接 5.多对多数据模型 6.多对多数据模型中的一张表是自连接 关键字包括： 1.查询 2.状态 3.上传 4.工作流 单表数据模型 就是一个表，有主键没外键 列表
查询 删除：先选中一条或者多条，然后点击删除
创建 查看详细信息
自连接数据模型 就是自己连接自己，一个自己的主键连接了一个自己的外键 目录列表
创建，单选是因为“自连接” 删除，如果删除的数据，作为了其他数据的根节点，则给出不能删除的提示
查询，详细和单表一样，修改和创建一样 同一种表结构可以有多种表现形式 在我们的权限系统中采用数据树形结构来表示，这就需要我们自动生成不同的结构，根据需求的不同，采用不同的形式展现，在分配角色的模块中也是这样体现的。 一对多数据模型 就是我们说的父子表，一个父亲可以有多个儿子，父表是一个单表，子表保存了父表的主键