㈠ 数据库中的“关系”是什么意思怎么理解
楼上的没错,不过这样说你有点抽象.
你看下什么叫关系数据库就知道"关系"是什么了
=================================================
在关系模型中，实体以及实体间的联系都是用关系表示的。例如，系实体，学生实体，系与学生之间的一对多的联系都可以分别用一个关系来表示。在一个给定的应用领域中，所有实体和实体之间联系的关系模式集合构成一个关系数据库的描述，称作关系数据库的内涵。
关系数据库也有型和值之分，关系数据库的型也称为关系数据库模式，是对关系数据库的描述，包括若干域的定义以及在这些域上定义的若干关系模式。关系数据库的值是这些关系模式在某一时刻对应的关系的集合，通常称为关系数据库称关系数据库的外涵。
㈡ 数据库中“关系模式”的定义是什么
关系的描述称为关系模式（Relation
Schema）。一个关系模式应当是一个五元组。它可以形式化地表示为：R(U,
D,
DOM,
F)。其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，DOM为属性向域的映象集合，F为属性间数据的依赖关系集合。
关系模式通常可以简记为:R(A1,
A2,
…,
An)。其中R为关系名，A1,
A2,
…,
An为属性名。而域名及属性向域的映象常常直接说明为属性的类型、长度。
关系实际上就是关系模式在某一时刻的状态或内容。也就是说，关系模式是型，关系是它的值。关系模式是静态的、稳定的，而关系是动态的、随时间不断变化的，因为关系操作在不断地更新着数据库中的数据。但在实际当中，常常把关系模式和关系统称为关系，读者可以从上下文中加以区别。
㈢ 数据库中关系模式如何定义
数据库中关系模型的一般定义可以理解：用二维表来描述现实世界中的事物以及事物之间联系的数据模型。从数学角度，又可以简单定义为R(U,F),其中R表示关系模型名，U表示该关系中的属性，F表示属性之间的依赖关系。
㈣ 如何定义数据库表之间的关系
唯一需要注意的是，外键字段的数据类型必须和主键的数据类型相同。但是有些系统可以允许这条规则有一个例外，它允许在数字和自动编号（autonumbering）字段（例如在SQL服务器系统中访问Identity和AutoNumber）之间建立关系。此外，外键的值可以是空（Null），尽管强烈建议在没有特别原因的情况下，不要让外键为空。你有可能永远都不会有机会来使用需要这项功能的数据库。 现在回到我们的示例关系表，并开始输入合适的外键。（请继续在纸上打草稿——在你的数据库系统中创建真正的数据表还为时过早。要知道在纸上纠正错误要容易得多。）要记住，你正在把主键的值添加到关系表里。只要调用实体之间的关系就行了，而其他的就简单了： 书籍和分类是有关系的。 书籍和出版社是有关系的。 书籍和作者是有关系的。 作者和邮政编码（ZIP）是有关系的。 邮政编码和城市是有关系的。 城市和州是有关系的。 这一步并不是一成不变的，你可能会发现在规范化的过程中加入外键会更容易一些。在把字段移动到一个新的数据表时，你可能要把这个新数据表的主键添加到原来的数据表里，将其作为外键。但是，在你继续规范化剩余数据的时候，外键常常会发生改变。你会发现在所有这些数据表被全部规范化之后，一次添加所有的外键，这样效率会更高。 操作数据表 现在让我们一次操作一个数据表，就从Books数据表开始，它在这个时候只有三个字段。很明显，Authors、Categories和Publishers数据表的主键会被添加到Books里。当你完成的时候，Books数据表就有了七个字段： Books Title (PK) ISBN (PK) Price FirstNameFK (FK) Authors.FirstName many-to-many LastNameFK (FK) Authors.LastName many-to-many CategoryFK (FK) Categories.Category many-to-many PublisherFK (FK) Publishers.Publisher one-to-many 要记住，Authors数据表里的主键是一个基于姓和名两个字段的复合关键字。所以你必须要把这个两个字段都添加到Books数据表里。要注意，外键字段名的结尾包含有FK这个后缀。加入这个后缀有助于提高可读性和自我归档。通过名称这种方式来区别外键会使得追踪它们更简单。如果主键和外键的名称不同，这没有关系。 这里出现了三种关系：Books和Authors、Books和Categories，以及Books和Publishers。这三种关系中所存在的两种问题可能没有那么明显： Books和Authors之间的关系：一本书可以有多个作者。 Books和Categories之间的关系：一本书可以被归入多个类。 这两者的关系是多对多的关系。先前我告诉过你，数据表不能直接实现这样的关系，而需要第三个联系表来实现。（Books和Publishers的关系是一对多的关系，就像现在所说的，这样是没有问题的。） 这两个新发现的多对多关系将需要一个联系表来包含来自每个数据表的主键，并将其作为外键。新的联系表是：BooksAuthorsmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many FirstNameFK (FK) Authors.FirstName one-to-many LastNameFK (FK) Authors.LastName one-to-many BooksCategoriesmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many CategoryFK (FK) Categories.Category one-to-many 没有必要更改Categories、Authors或者Publishers数据表。但是，你必须把FirstNameFK、LastNameFK和CategoryFK这三个外键从Books里移走： Books Title (PK) ISBN (PK) Price PublisherFK (FK) Publishers.Publisher one-to-many 现在，让我们转到Authors数据表上来，它现在有两个字段。每个作者都和ZIPCodes数据表中的邮政编码的值相关。但是，每个邮政编码会和多个作者相关。要实现这种一对多的关系，就要把ZIPCodes数据表中的主键添加进Authors数据表作为外键： Authors FirstName (PK) LastName (PK) ZIPCodeFK (FK) ZIPCodes.ZIPCode one-to-many 至此，你已经准备好了处理剩下的地址部分了。看到它们被分在不同的数据表里是很让人奇怪的，但是这是遵照BCNF正确规范化数据的结果。每个邮政编码的值只会有一个对应的城市值和州值。每个城市和州的值只会被输入进其对应的数据表里一次。ZIPCodes和Cities数据表需要外键字段来实现这些关系： ZIPCodes ZIPCode (PK) CityFK (FK) Cities.City one-to-many Cities City (PK) StateFK (FK) States.State one-to-many States State (PK) 从一个到九个 最后，你有了九个数据表：Books、Authors、Categories、Publishers、ZIPCodes、Cities、States、BooksAuthorsmmlink和BooksCategoriesmmlink。图A是这个示例数据表的数据库最终的图形形式。很难想象一个简单的数据表会被分成九个数据表。 图A 最初的一个数据表现在需要九个数据表了 由于这个示例数据库很简单，你可能会问这些关系有什么作用。看起来仍在保存冗余的数据，只不过形式不同罢了——通过外键来实现。这是因为我们的数据表现在只有很少几个字段。试想一下有十几个字段的数据表，会是什么样的一个情形。需要承认的是，你仍然需要把数据表的主键作为外键保存进关系表里，但是至多可能最多增加一到两个字段。比较一下为这个数据表里的每一条记录都添加十几个条目的情形吧。
㈤ 如何定义数据库表之间的关系
唯一需要注意的是，外键字段的数据类型必须和主键的数据类型相同。但是有些系统可以允许这条规则有一个例外，它允许在数字和自动编号（autonumbering）字段（例如在SQL服务器系统中访问Identity和AutoNumber）之间建立关系。此外，外键的值可以是空（Null），尽管强烈建议在没有特别原因的情况下，不要让外键为空。你有可能永远都不会有机会来使用需要这项功能的数据库。 现在回到我们的示例关系表，并开始输入合适的外键。（请继续在纸上打草稿——在你的数据库系统中创建真正的数据表还为时过早。要知道在纸上纠正错误要容易得多。）要记住，你正在把主键的值添加到关系表里。只要调用实体之间的关系就行了，而其他的就简单了： 书籍和分类是有关系的。 书籍和出版社是有关系的。 书籍和作者是有关系的。 作者和邮政编码（ZIP）是有关系的。 邮政编码和城市是有关系的。 城市和州是有关系的。 这一步并不是一成不变的，你可能会发现在规范化的过程中加入外键会更容易一些。在把字段移动到一个新的数据表时，你可能要把这个新数据表的主键添加到原来的数据表里，将其作为外键。但是，在你继续规范化剩余数据的时候，外键常常会发生改变。你会发现在所有这些数据表被全部规范化之后，一次添加所有的外键，这样效率会更高。 操作数据表 现在让我们一次操作一个数据表，就从Books数据表开始，它在这个时候只有三个字段。很明显，Authors、Categories和Publishers数据表的主键会被添加到Books里。当你完成的时候，Books数据表就有了七个字段： Books Title (PK) ISBN (PK) Price FirstNameFK (FK) Authors.FirstName many-to-many LastNameFK (FK) Authors.LastName many-to-many CategoryFK (FK) Categories.Category many-to-many PublisherFK (FK) Publishers.Publisher one-to-many 要记住，Authors数据表里的主键是一个基于姓和名两个字段的复合关键字。所以你必须要把这个两个字段都添加到Books数据表里。要注意，外键字段名的结尾包含有FK这个后缀。加入这个后缀有助于提高可读性和自我归档。通过名称这种方式来区别外键会使得追踪它们更简单。如果主键和外键的名称不同，这没有关系。 这里出现了三种关系：Books和Authors、Books和Categories，以及Books和Publishers。这三种关系中所存在的两种问题可能没有那么明显： Books和Authors之间的关系：一本书可以有多个作者。 Books和Categories之间的关系：一本书可以被归入多个类。 这两者的关系是多对多的关系。先前我告诉过你，数据表不能直接实现这样的关系，而需要第三个联系表来实现。（Books和Publishers的关系是一对多的关系，就像现在所说的，这样是没有问题的。） 这两个新发现的多对多关系将需要一个联系表来包含来自每个数据表的主键，并将其作为外键。新的联系表是：BooksAuthorsmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many FirstNameFK (FK) Authors.FirstName one-to-many LastNameFK (FK) Authors.LastName one-to-many BooksCategoriesmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many CategoryFK (FK) Categories.Category one-to-many 没有必要更改Categories、Authors或者Publishers数据表。但是，你必须把FirstNameFK、LastNameFK和CategoryFK这三个外键从Books里移走： Books Title (PK) ISBN (PK) Price PublisherFK (FK) Publishers.Publisher one-to-many 现在，让我们转到Authors数据表上来，它现在有两个字段。每个作者都和ZIPCodes数据表中的邮政编码的值相关。但是，每个邮政编码会和多个作者相关。要实现这种一对多的关系，就要把ZIPCodes数据表中的主键添加进Authors数据表作为外键： Authors FirstName (PK) LastName (PK) ZIPCodeFK (FK) ZIPCodes.ZIPCode one-to-many 至此，你已经准备好了处理剩下的地址部分了。看到它们被分在不同的数据表里是很让人奇怪的，但是这是遵照BCNF正确规范化数据的结果。每个邮政编码的值只会有一个对应的城市值和州值。每个城市和州的值只会被输入进其对应的数据表里一次。ZIPCodes和Cities数据表需要外键字段来实现这些关系： ZIPCodes ZIPCode (PK) CityFK (FK) Cities.City one-to-many Cities City (PK) StateFK (FK) States.State one-to-many States State (PK) 从一个到九个 最后，你有了九个数据表：Books、Authors、Categories、Publishers、ZIPCodes、Cities、States、BooksAuthorsmmlink和BooksCategoriesmmlink。图A是这个示例数据表的数据库最终的图形形式。很难想象一个简单的数据表会被分成九个数据表。 图A 最初的一个数据表现在需要九个数据表了 由于这个示例数据库很简单，你可能会问这些关系有什么作用。看起来仍在保存冗余的数据，只不过形式不同罢了——通过外键来实现。这是因为我们的数据表现在只有很少几个字段。试想一下有十几个字段的数据表，会是什么样的一个情形。需要承认的是，你仍然需要把数据表的主键作为外键保存进关系表里，但是至多可能最多增加一到两个字段。比较一下为这个数据表里的每一条记录都添加十几个条目的情形吧。
㈥ 关系数据库中的关系是什么意思
关系型数据库实际上是基于关系模型的数据库,也就是你所问到的关系是什么意思.
因为关系实际上是一张二维表,表的每一行是一个元素,每一列是一项属性,而一个元组就是该关系所涉及的属性集的笛卡尔积的一个元素.
一个关系模式应当是一个5元组.定义关系的描述称为关系模式）.它可以形式化地表示为：R（U,D,dom,F） 其中R为关系名,U为组成该关系的属性名集合,D为属性组U中属性所来自的域,dom为属性向域的映象集合,F为属性间数据的依赖关系集合.
㈦ 数据库中“关系模式”的定义是什么
关系模式是指关系的描述
关系模式仅涉及关系名、各属性名、域名、属性向域的映象四部分。
它可以形式化地表示为：R、U、D、DOM、 F。其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，DOM为属性向域的映象集合，F为属性间数据的依赖关系集合。
现实世界随着时间在不断地变化，因而在不同的时刻，关系模式的关系也会有所变化。但是，现实世界的许多己有事实限定了关系模式所有可能的关系必须满足一定的完整性约束条件。这些约束或者通过对属性取值范围的限定。
(7)数据库关系的数字定义扩展阅读：
数据库中，关系模式是型，关系是值，关系模式是对关系的描述。
1、关系实质上是一张二维表，表的每一行为一个元组，每一列为一个属性。一个元组就是该关系所涉及的属性集的笛卡尔积的一个元素。关系是元组的集合，
因此关系模式必须指出这个元组集合的结构，即它由哪些属性构成，这些属性来自哪些域，以及属性与域之间的映象关系。
2、一个关系通常是由赋予它的元组语义来确定的。
元组语义实质上是一个n目谓词（n是属性集中属性的个数，凡使该n目谓词为真的笛卡尔积中的元素（或者说凡符合元组语义的那部分元素）的全体就构成了该关系模式的关系。
㈧ 关系数据库中数据库,表,字段及元组的概念及相互之间的关系
一、概念
（1）关系数据库的表采用二维表格来存储数据，是一种按行与列排列的具有相关信息的逻辑组，它类似于Excle工作表。一个数据库可以包含任意多个数据表。
（2）关系数据库：在一个给定的应用领域中，所有实体及实体之间联系的集合构成一个关系数据库。它是一种以关系模式为基础存储数据以及用数字方法处理数据库组织的方法，是目前最为流行的一种数据组织形式。
（3）元组（记录）。表中的一行即为一个元组，或称为一条记录。
（4）字段，数据表中的每一列称为一个字段，表是由其包含的各种字段定义的，每个字段描述了它所含有的数据的意义，数据表的设计实际上就是对字段的设计。创建数据表时，为每个字段分配一个数据类型，定义它们的数据长度和其他属性。字段可以包含各种字符、数字、甚至图形。
二、关系
一个数据库可以包含若干张表；一张表有若干个字段；每张表又有若干条记录（元组），每条记录（元组）对应每个字段都有一个值。
(8)数据库关系的数字定义扩展阅读
关系数据库，是建立在关系数据库模型基础上的数据库，借助于集合代数等概念和方法来处理数据库中的数据。
同时也是一个被组织成一组拥有正式描述性的表格，该形式的表格作用的实质是装载着数据项的特殊收集体，这些表格中的数据能以许多不同的方式被存取或重新召集而不需要重新组织数据库表格。
关系数据库的定义造成元数据的一张表格或造成表格、列、范围和约束的正式描述。每个表格（有时被称为一个关系）包含用列表示的一个或更多的数据种类。 每行包含一个唯一的数据实体，这些数据是被列定义的种类。
㈨ 关系数据库中的关系是什么意思
关系数据库种的关系主要是指创建在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。
关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。
关系模型是由埃德加·科德于1970年首先提出的，并配合“科德十二定律”。现如今虽然对此模型有一些批评意见，但它还是数据存储的传统标准。
标准数据查询语言SQL就是一种基于关系数据库的语言，这种语言执行对关系数据库中数据的检索和操作。
(9)数据库关系的数字定义扩展阅读：
1．数据库
关系数据库可按其数据存储方式以及用户访问的方式而分为本地数据库和远程数据库两种类型。
(1)本地数据库：本地数据库驻留在本机驱动器或局域网中，如果多个用户并发访问数据库，则采取基于文件的锁定(防止冲突)策略，因此，本地数据库又称为基于文件的数据库。
典型的本地数据库有Paradox、dBASE、FoxPro以及Access等。基于本地数据库的应用程序称为单层应用程序，因为数据库和应用程序同处于一个文件系统中。
(2)远程数据库：远程数据库通常驻留于其他机器中，用户通过结构化查询语言SQL来访问远程数据库中的数据，因此，远程数据库又称为SQL服务器。
有时，来自于远程数据库的数据并不驻留于一个机器而是分布在不同的服务器上。典型的SQL服务器有InterBase、Oracle、Sybase、Informix、MicrosoftSQLServer，以及IBMDB2等。
基于SQL服务器的应用程序称为两层或多层应用程序，因为数据库和应用程序驻留在彼此不依赖的系统(层)中。
本地数据库与SQL服务器相比较，前者访问速度快，但后者的数据存储容量要大得多，且适合多个用户并发访问。
究竟使用本地数据库还是SQL服务器，取决于多方面因素，如要存储和处理的数据多少，并发访问数据库的用户个数，对数据库的性能要求等。
2．表
关系数据库的基本成分是一些存放数据的表(关系理论中称为“关系”)。数据库中的表从逻辑结构上看相当简单，它是由若干行和列简单交叉形成的，不能表中套表。
它要求表中每个单元都只包含一个数据，可以是字符串、数字、货币值、逻辑值、时问等较为简单的数据。一般数据库中无法存储c++语言中的结构类型、类对象。图像的存储也比较烦琐，很多数据库无法实现图像存储。
3．视图
为了方便地使用数据库，很多DBMS都提供对于视图(Access中称为查询)结构的支持。视图是根据某种条件从一个或多个基表(实际存放数据的表)或其他视图中导出的表，数据库中只存放其定义，而数据仍存放在作为数据源的基表中。故当基表中数据有所变化时，视图中看到的数据也随之变化。