关系键
 
 
 

  维基百科，自由的百科全书
 
 
 
 
  
关系键是关系数据库的重要组成部分。关系键是一个表中的一个或几个属性，用来标识该表的每一行或与另一个表产生联系。
 
  
 
   
 
    
目录
 
   
 
   
1 主键
2 超键
3 候选键
4 外键
5 代理键 
     
5.1 何时使用代理键
 
6 自然键
7 外部链接
 
  
 
  
主键
 
  
 
   

     
    
 
     

      
     
 数据库理论中, 超键、候选键与主键之间的关系:
     
 • 候选键是超键的一种：不含有多余属性的超键
     
 • 某个候选键被选为主键
    
 
   
 
  
 
  
主键，又称主码（英语：primary key或unique key）。数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值（Null）。
 
  
从技术的角度来看，primary key和unique key有很多相似之处。但还是有以下区别：
 
  
作为primary key的域／域组不能为Null。而unique key可以。
在一个表中只能有一个primary key，而多个unique key可以同时存在。
更大的区别在逻辑设计上。primary key一般在逻辑设计中用作记录标识，这也是设置primary key的本来用意。而unique key只是为了保证域／域组的唯一性。
 
  
超键
 
  
超键（英语：superkey），有的文献称“超码”，是在数据库关系模式设计中能够唯一标示多元组的属性集。
 
  
包含所有属性的集叫做明显超键。
 
  
候选键
 
  
在关系模型中，候选键或候选码（英语：candidate key）是某个关系变量的一组属性所组成的集合，它需要同时满足下列两个条件：
 
  
这个属性集合始终能够确保在关系中能唯一标识元组
在这个属性集合中找不出合适的子集能够满足条件(1)
 
  
满足第一个条件的属性集合称为超键，因此我们也可以把候选键定义为“最小超键”，也就是不含有多余属性的超键。
 
  
候选键的重要性是它们能够在关系中唯一标识出不同的元组，因此超键也是在设计数据库模式时需要指定的最重要的约束之一。由于在关系模型中，每个关系都是一个集合（没有重复的元素），所以每个关系都至少有一个候选键（因为所有属性组合必然是个超键）。但是在某些关系型数据库中表也能代表多重集，所以在每个关系中都显式地定义至少一个候选键是一条很重要的设计原则。数据库管理系统通常都需要将每个关系中的某个候选键定义为主键，亦即这个候选键是区分不同元组时首选的识别方式，例如外键通常就是引用主键而非其他候选键。
 
  
外键
 
  
外键（英语：foreign key，台湾译作外来键），又称外部键。其实在关系数据库中，每个数据表都是由关系来连系彼此的关系，父数据表（Parent Entity）的主键（primary key）会放在另一个数据表，当做属性以创建彼此的关系，而这个属性就是外键。
 
  
比如，学生跟老师之间是教学的关系，学生数据表会有个属性叫指导老师(FK)，而这个值就是对应到老师数据表的老师代号(PK)，学生的指导老师就是外键。
 
  
代理键
 
  
在关系型数据库设计中，代理键是在当数据表中的候选键都不适合当主键时，例如数据太长，或是意义层面太多，就会请一个无意义的但唯一的字段来代为作主键。
 
  
代理键是：
 
  

   
    Surrogate (1) – Hall, Owlett and Codd (1976)
   
   

    一个代理键值确定了外部世界的一个实体。代理键值是数据库生成的，从来不显示给用户或应用程序看。
   
   
    Surrogate (2) – Wieringa and De Jonge (1991)
   
   

    一个代理键值确定了数据库中的一个对象。代理键值是数据库生成的，用户或应用程序看不到它。
   
  
 
  
在实践中，代理键值通常是个自动递增的数字。在Sybase或SQL Server，用identity column标识代理键，PostgreSQL里用serial，Oracle里用SEQUENCE，在MySQL里用一个标记有AUTO_INCREMENT的字段。
 
  
何时使用代理键
 
  
以中国大陆的十八位身份证号为例，从左往右为六位数字地址码，八位数字出生日期码，三位数字顺序码和一位数字校验码。
 
  
一家公司想要将它的客户记入数据库，以客户的身份证号作为主键当然是可以的；但是这18位身份证号是用于标识大陆13多亿人口的，一家公司的客户显然没有这么多，所以用18位的数字作为主键有点浪费空间。
 
  
另外，身份证号中包含了地区、生日信息，若以身份证号为主键，要不要另开字段记录客户的地区、生日也是个问题。如果不另开字段，从主键（身份证号）中提取地区、生日有点麻烦；如果开字段，主键和地区、生日字段的数据存在冗余。
 
  
所以，一般的做法是，根本不记录客户的身份证号（除非有其他需求），用一个代理键作为主键，另开字段记录客户的地区、生日等信息。
 
  
自然键
 
  
自然键与代理键相反，它是在自然生活中唯一确定一个事物的标识。身份证号就是一个自然键，用于确定一个人。
 
  
外部链接
 
  
一个详细介绍外键的网站
数据库系统理论
 
  
 
  

 
 
  
数据库管理系统（DBMS） (查看 ·  讨论 ·  编辑)
 
概念
 数据库 ·  数据模型 · 数据库存储结构 ·  关系 (数据库) ·  关系模型 ·  分布式数据库 ·  ACID (  原子性 ·  一致性 ·  隔离性 ·  持久性 ) ·  Null值
 关系数据库 ·  关系模型 ·  数据库规范化 ·  数据库完整性 ·  实体完整性 ·  引用完整性 ·  关系数据库管理系统 
 主键 · 外键 · 代理键 · 超键 · 候选键 
 
 
数据库组件
 触发器 ·  视图 ·  数据库表 ·  指标 (数据库) · 事务日志 ·  数据库事务 ·  并发控制 ·  乐观锁 ·  悲观锁 ·  数据库索引 
 存储程序 ·  数据库分区
 
 
SQL
 分类：  数据查询语言 (DQL) -  数据定义语言 (DDL) -  数据操纵语言 (DML) -  数据控制语言 (DCL)
 指令：SELECT ·  INSERT ·  UPDATE ·  MERGE ·  DELETE ·  JOIN ·  UNION ·  CREATE ·  DROP ·  Begin work ·  COMMIT ·  ROLLBACK ·  TRUNCATE ·  ALTER
 安全：  SQL注入攻击 ·  参数化查询
 
数据库管理系统的实现
 
实现类型
 关系数据库 ·  文件型数据库 ·  Deductive ·  维度化数据库 ·  层次结构式 ·  图形数据库 ·  对象数据库 ·  对象关系数据库 ·  Temporal ·  XML数据库
 
 
数据库产品
 对象型 (对比) ·  关系型 (对比)
 
 
数据库组件
 数据查询语言 ·  查询优化器 ·  查询计划 ·  嵌入式SQL ·  ODBC ·  JDBC ·  OLE DB
 
 
  

   分类： 
   
数据库
数据建模
数据库管理系统
 
  
 
  
 
  

 
 ======================================================================
  
 
  
Natural key
 
  

   From Wikipedia, the free encyclopedia
  
 
  
 
   
In  relational model  database design, a natural key is a key that is formed of attributes that already exist in the real world. For example, a USA citizen's social security number could be used as a natural key. In other words, a natural key is a  candidate key that has a logical relationship to the attributes within that  row. A natural key is sometimes called domain key.
 
   
The main advantage of a natural key over a  surrogate key, which has no meaning outside the database environment, is that it already exists; there is no need to add a new, artificial  column to the  schema. Using a natural key (when one can be identified) also simplifies data quality: It ensures that there can only be one row for a key; this "one version of the truth" can be verified, because the natural key is based on a real-world observation.
 
   
The main disadvantage of choosing a natural key is that its value may change and the relational database engine may not be able to propagate that change across the related  foreign keys. For example, if person_name is used as the primary key for the person table, and a person gets married and changes name, then all of the  one-to-many related tables need to be updated also. The secondary disadvantage of choosing a natural key is identifying  uniqueness. The primary key must consist of the attributes that uniquely identify a row. However, it may be difficult (or it may add constraints) to create a natural key on a table. For example, if person_name is used as a primary key for the person table, many persons may share the same name and all but the first entry will be rejected as a duplication. The uniqueness constraint may be overcome by adding an additional column to the primary key, like street_address, to increase the likelihood of uniqueness.
 
   
External links
 
   
"Intelligent Versus Surrogate Keys", B Carter.
"Avoid Unique Indexes – (Mistake 3 of 10)", Near Infinity, Create Data Disaster.
"Natural versus surrogate keys", c2.
 
  
 
  
 
   

    Categories: 
    
Data modeling
 
   
 
  
 
  
 
 
 

一、选择题
 
1、关系规范化中的删除操作异常是指  ①  ，插入操作异常是指 ② 。
 
 A．不该删除的数据被删除 B．不该插入的数据被插入 C．应该删除的数据未被删除 D．应该插入的数据未被插入【答案：】①A ②D
 
2、设计性能较优的关系模式称为规范化，规范化主要的理论依据是   。
 
 A．关系规范化理论 B．关系运算理论 C．关系代数理论  D．数理逻辑   
 
【答案：】A
 
3、规范化过程主要为克服数据库逻辑结构中的插入异常，删除异常以及   的缺陷。
 
 A．数据的不一致性 B．结构不合理  C．冗余度大   D．数据丢失   
 
【答案：】C
 
4、当关系模式R(A，B)已属于3NF，下列说法中   是正确的。
 
 A．它一定消除了插入和删除异常 B．仍存在一定的插入和删除异常  C．一定属于BCNF  D．A和C都是 
 
【答案：】B
 
5、关系模型中的关系模式至少是   。 
 
 A．1NF B．2NF C．3NF D．BCNF            
 
【答案：】A
 
6、在关系DB中，任何二元关系模式的最高范式必定是   。
 
 A．1NF B．2NF C．3NF D．BCNF             
 
【答案：】D
 
7、在关系模式R中，若其函数依赖集中所有候选关键字都是决定因素，则R最高范式是   。
 
 A．2NF B．3NF C．4NF D．BCNF          
 
【答案：】C
 
8、候选关键字中的属性称为   。
 
 A．非主属性 B．主属性 C．复合属性 D．关键属性      
 
【答案：】B
 
9、消除了部分函数依赖的1NF的关系模式，必定是   。
 
 A．1NF B．2NF C．3NF D．4NF          
 
【答案：】B
 
10、关系模式的候选关键字可以有 ① ，主关键字有 ② 。
 
 A．0个 B．1个 C．1个或多个 D．多个        
 
【答案：】①C ②B
 
11、关系模式的分解   。
 
 A．惟一 B．不惟一              
 
【答案：】B
 
12、根据关系数据库规范化理论，关系数据库中的关系要满足第一范式。下面“部门”关系中，因哪个属性而使它不满足第一范式?   。
 
 部门(部门号，部门名，部门成员，部门总经理)
 
 A．部门总经理 B．部门成员  C．部门名  D．部门号    
 
【答案：】B
 
二、填空题
 
1、在关系A(S，SN，D)和B(D，CN，NM中，A的主键是S，B的主键是D，则D在S中称为    。
 
【答案：】外部键
 
2、对于非规范化的模式，经过  ①  转变为1NF，将1NF经过 ②  转变为2NF，将2NF经过  ③  转变为3NF。
 
 
 
【答案：】①使属性域变为简单域 ②消除非主属性对主关键字的部分依赖③消除非主属性对主关键字的传递依赖 
 
3、在关系数据库的规范化理论中，在执行“分解”时，必须遵守规范化原则：保持原有的依赖关系和无损连接性  。 
 
【答案：】无损连接性
 
三、概念解释：
 
平凡的函数依赖
在关系模式R(U)中，对于U的子集X和Y，
 
如果X→Y，但Y Í X，则称X→Y是非平凡的函数依赖
 
非平凡的函数依赖
在关系模式R(U)中，对于U的子集X和Y，
 
若X→Y，但Y Í X, 则称X→Y是平凡的函数依赖
 
四、综合练习
 
1、已知学生关系模式
 
S(Sno，Sname，SD，Sdname，Course，Grade)
 
其中：Sno学号、Sname姓名、SD系名、Sdname系主任名、Course课程、Grade成绩。
 
(1)写出关系模式S的基本函数依赖和主码。
 
(2)原关系模式S为几范式？为什么？分解成高一级范式，并说明为什么? 
 
(3)将关系模式分解成3NF，并说明为什么? 
 
(1)写出关系模式S的基本函数依赖和主码。
 
答: 关系模式S的基本函数依赖如下：
 
 Sno→Sname，SD→Sdname，Sno→SD，(Sno，Course) →Grade
 
关系模式S的码为：（Sno，Course）。
 
(2)原关系模式S为几范式？为什么？分解成高一级范式，并说明为什么?
 
答: 原关系模式S是属于1NF的，码为(Sno，Course)，非主属性中的成绩完全依赖于码，而其它非主属性对码的函数依赖为部分函数依赖，所以不属于2NF。
 
消除非主属性对码的函数依赖为部分函数依赖，将关系模式分解成2NF如下：
 
S1(Sno，Sname，SD，Sdname)
 
S2(Sno，Course，Grade) 
 
 (3)将关系模式分解成3NF，并说明为什么?
 
 答: 将上述关系模式分解成3NF如下：
 
 关系模式S1中存在Sno→SD，SD→Sdname，即非主属性Sdname传递依赖于Sno，所以S1不是3NF。进一步分解如下：
 
 S11(Sno，Sname,SD)  S12(SD，Sdname)
 
 分解后的关系模式S11、S12满足3NF。
 
 对关系模式S2不存在非主属性对码的传递依赖，故属于3NF。所以，原模式S(Sno，Sname，SD，Sdname，Course，Grade)按如下分解满足3NF。
 
S11(Sno，Sname，SD) 
 
S12(SD，Sdname)
 
S2(Sno，Course，Grade) 
 
2、设有如下关系R
 
 
 (1)它为第几范式? 为什么? 
 
(2)是否存在删除操作异常?若存在，则说明是在什么情况下发生的? 
 
(3)将它分解为高一级范式，分解后的关系是如何解决分解前可能存在的删除操作异常问题? 
 
(1)它为第几范式? 为什么?
 
解:它是2NF。 因为R的候选关键字为“课程名”。 依赖关系: 课程名→教师名，教师名 → 课程名，教师名→教师地址，所以 课程名→教师地址。即存在非主属性“教师地址”对候选关键字课程名的传递函数，因此R不是3NF。但：因为不存在非主属性对候选关键字的部分函数依赖，所以R是2NF。
 
(2)是否存在删除操作异常?若存在，则说明是在什么情况下发生的?
 
解: 存在。当删除某门课程时会删除不该删除的教师的有关信息。
 
(3)将它分解为高一级范式，分解后的关系是如何解决分解前可能存在的删除操作异常问题?
 
解: 分解为高一级范式如图所示。
 
R1如下:        R2如下: 
 
 
分解后，若删除课程数据时，仅对关系R1操作，教师地址信息在关系R2中仍然保留，不会丢失教师方面的信息。 
 
3、设某商业集团数据库中有一关系模式R如下：
 
R （商店编号，商品编号，数量，部门编号，负责人）
 
如果规定：（1） 每个商店的每种商品只的在一个部门销售；（2） 每个商店的每个部门只有一个负责人；（3） 每个商店的每种商品只有一个库存数量。
 
试回答下列问题：（1） 根据上述规定，写出关系模式R的基本函数依赖；
 
答: 关系模式S的基本函数依赖如下： (商店编号，商品编号) →部门编号，（商店编号，部门编号）→负责人，(商店编号，商品编号) →数量
 
（2） 找出关系模式R的候选码；答:关系模式R的码为：（商店编号，商品编号, 部门编号）。
 
（3） 试问关系模式R最高已经达到第几范式？为什么？答: 原关系模式R是属于1NF的，码为（商店编号，商品编号, 部门编号），非主属性对码的函数依赖全为部分函数依赖，所以不属于2NF。
 
消除非主属性对码的函数依赖为部分函数依赖，将关系模式分解成2NF如下：
 
R1(商店编号，商品编号, 部门编号, 数量)
 
R2(商店编号，部门编号, 负责人) 
 
（4） 如果R不属于3NF，请将R分解成3NF模式集。
 
答：将R分解为
 
R1(商店编号，商品编号, 部门编号, 数量)
 
R2(商店编号，部门编号, 负责人) 
 
分解后的R不存在传递的函数依赖，所以分解后的R已经是第3NF

一、关系规范化理论背景
 
关系规范化理论是以关系模型为背景。一个关系模式应当是一个五元组：R(U，D，DOM，F）；其中，关系名R是符号化的元组语义，U为一组属性元组，D为属性组U中的属性所来自的域，DOM为属性到域的映射,F为属性组U上的一组数据依赖。由于D、DOM与模式设计关系不大，因此在可以把关系模式看作一个三元组：R < U，F >，当且仅当U上的一个关系r满足F时，r称为关系模式R < U，F>的一个关系。
 作为一个二维表，关系要符合一个最基本的条件，即第一范式：每一个分量必须是不可分的数据项。
 数据依赖：一个关系内部属性与属性之间的一种约束关系。这种约束关系是通过属性间值与否体现出来的数据间相关联系，是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。
 
 
 
一个好的模式应当不会发生插入异常、删除异常和更新异常，并且数据冗余应尽可能少。
 
 
二、规范化
 
 
 
根据属性间依赖情况来区分关系规范化程度为第一范式、第二范式、第三范式和第四范式等。
 数据依赖的类型有函数依赖（FD）和多值依赖（MVD）。
 
 
1. 函数依赖
 
函数依赖和别的数据依赖一样是语义范畴的概念，只能根据语义确定一个函数依赖。函数依赖不是指关系模式R的某个或某些关系满足的约束条件，而是指R的一切关系均要满足的约束条件。
 
2. 码
 
码是关系模式中的一个重要概念。其中，候选码是最小的超码，若候选码多于一个，则选定其中的一个为主码。包含在任何一个候选码中的属性为主属性；不包含在任何候选码中的属性称为非主属性或非码属性。最简单的情况属为单个属性是码；最极端的情况是整个属性组是码，称为全码。
 
3. 范式
 
关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足第一要求的叫第一范式（1NF）；在第一范式中满足进一步要求的为第二范式，其余以此类推。
 所谓“第几范式”原本是表示关系的某一种级别，所以常称某一关系模式R为第几范式。
 一个低一级范式的关系模式通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程叫规范化。
 
2NF
 如果R∈ 1NF，且每一个非主属性完全函数依赖于任何一个候选码，则R∈ 2NF。一个关系模式R不属于2NF，就会导致插入异常、删除异常、修改复杂。
3NF
 设关系模式R<U，F>∈ 1NF，若R中不存在这样的码X，属性组Y及非主属性Z使得X→ Y,Y→ Z成立，Y不→ X，则称R < U,F > ∈ 3NF。如果R∈ 3NF，则每一个非主属性既不传递依赖码，也不部分依赖于码，也就是说R属于3NF，必有R属于2NF。
BCNF
 BCNF被称为修正的第三范式，或者扩充的第三范式。R < U，F > 中，若每一个决定因素都包含码，则R < U ，F > ∈ BCNF。一个满足BCNF的关系模式有：所有非主属性对每一个码都是完全函数依赖；所有主属性对每一个不包含它的码也是完全函数依赖；没有任何属性完全函数依赖于非码的任何一组属性。
 其中，3NF和BCNF是在函数依赖的条件下对模式分解所能达到的分离程度的测度。一个模式中的关系模式如果都属于BCNF，那么在函数依赖范畴内它已实现了彻底的分离，已消除了插入和删除的异常。3NF的“不彻底”性表现在可能存在主属性对码的部分依赖和传递依赖。
 
4. 多值依赖
 
多值依赖的性质：
 
对称性
传递性
函数依赖可以看作是多值依赖的特殊情况
 多值依赖于函数依赖的区别：多值依赖的有效性与属性集的范围有关。
 4NF就是限制关系模式的属性之间不允许有非平凡非函数依赖的多值依赖，它所允许的非平凡的多值依赖实际上是函数依赖。如果一个关系模式是4NF，则必为BCNF。
 
三、Armstrong公理系统
 
 
 
数据依赖的公理系统是模式分解算法的理论基础。
 
 
设U为属性集总体，F是U上的一组函数依赖，于是有关系模式R< U ,F >，对R < U ,F >来说有以下的推理规则：
 A1 自反律：若Y⊆ X⊆ U，则X->Y为F所蕴涵。
 A2 增广律：若X -> Y为所蕴涵，且Z⊆ U，则XZ -> YZ为F所蕴涵。
 A3 传递律：若X -> Y及Y -> Z为F所蕴涵，则X -> Z为F所蕴涵。
 注意：由自反律所得到的函数依赖均是平凡的函数依赖，自反律的使用并不依赖于F。
 由A1、A2、A3可得到：
 
合并规则：由X -> Y，X -> Z，有X->YZ。
伪传递规则：由X -> Y，WY -> Z，有XW -> Z。
分解规则：由X -> Y及Z⊆Y，有X -> Z。
 人们把自反律、传递律和增广律为Armstrong公理系统。Armstrong公理系统是有效的、完备的。
 
四、模式的分解
 
1. 模式分解的三个定义
 
对于一个模式的分解是多种多样的，但是分解后产生的模式应与原模式等价。“等价”的概念有三种不同的定义：
 
分解具有无损连接性。
分解要保持函数依赖。
分解既要保持函数依赖，又要具有无损连接性。
 这三个定义是实行分解的三条不同的准则。按照不同的分解准则，模式所能达到的分离程度各不相同，各种范式就是对分离程度的测度。
 
2. 分解的无损连接性和保持函数依赖性
 
对于R< U, F >的一个分解ρ=｛R1<U1,F1>,R2< U2 ,F2>｝，如果U1∩U2->U1-U2∈F+或U1∩U2->U2-U1∈F+，则ρ具有无损连接性。其中F+叫作F的闭包。
 
3.模式分级的算法
 
若要求分解保持函数依赖，那么模式分离总可以达到3NF，但不一定能的达到BCNF。若要求分解既要保持函数依赖，又具有无损链接性，可以达到3NF，但不一定能达到BCNF。若要求分解具有无损连接性，那一定可达到4NF。
 
规范化小结
 
在关系数据库中，对关系模式的基本要求就是满足第一范式，这样的关系模式就是合法的、允许的。规范化的基本思想是逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的“分离”，即“一事一地”的设计模式原则。让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它“分离”出去。规范化的实质就是概念的单一化。
 
规范化过程图示：
 
 
 
 
规范化理论为数据库设计提供了理论的指南和工具，但仅仅是指南和工具，并不是规范化程度越高模式就越高，必须结合应用环境和现实世界的具体情况合理地选择数据库模式。
 
 
规范化小结图示：
 
 
关系模式的规范化过程是通过对关系模式的分解来实现的。把低一级的关系模式分解为若干个高一级的关系模式。这种分解不是唯一的。

      关系模型有三个原理组件：结构性组件、完整性组件以及操纵性组件。
 
     本文主要介绍结构性组件及其它组件的一些基本概念。本文的产生，基于阅读The Definitive Guide to Sqlite后的一些感想！
 
（1）结构性组件
 
        定义了信息的组织方式和表示方式。具体点说，所有的信息都用关系（relations)来表示。关系是由tuple(元)组成的，元又是由属性和值两部分组成。关系（relation）是数据库中用来表示各种信息的唯一的数据结构。关系模型中的relation概念起源于数学集合理论中的relation概念，因此它们很多属性有很多相似之处。
 
       
 
       tuple可理解为值的集合，每一个值都有相关联的属性。 A set of values, each of which has an associated attribute!
 
       tuple由属性和值两部分组成。属性定义了value的名字（name）和域（domain），name可以用来区分tuple中的value, domain则限制了value的范围。把attribute属性和value值组合起来，就是一个component.
 
      那么，什么是relation呢？ A set of one or more tuples that share the same heading!
 
我们先看看heading的概念。heading就是tuple中一群属性的集合，如上图所示。
 
      一个relation，简单的说，就是具有相同heading的一个或多个tuple。也就是说，在一个relation中，所有的tuple share一个heading.
 
    
 
        接下来，什么是table呢？ 简单的说，可以认为是relation变量。即：Relation Variables.
 
       一个relation,虽然它本身包含很多value, 自己本身也是一个value, 就如同一个整数或字符串一样。不禁要问，relation的value是什么呢？每一个relation的value是由该relation内部的某个tuple赋值的。与此类似，每一个tuple的值也是由该tuple内部的某个值。因此，一个relation是由它各个部分综合来决定的。下面这个图可以用来深入理解下此概念。
 
       
 
           上图描述了3个relation, 用R1\R2\R3表示，替代了IXF。他们各自代表不同的值，也就是不同的relation。然而，R1\R2\R3本身并不被认为是relation,而被认为是relation variables.在SQL中，它们被形象的称为tables.他们也被称为基表，由于他们也是变量，并且变量的值为relations.
 
          在实际应用中， Relation的准确定义可能比较让人难以理解，其定义比较模糊。通常，relations和table都在同样的语境中使用。然而，relation和table并不是一样的东西。可以这么理解， relation是值，而table是变量。
 
       tables，是变量，既有名字，也有值。名字只是一个标记，而值就是relations. tables具有relations的所有属性（heading,degree,cardinality等），这就如同一个整型变量具有所有整数的特性一样。请注意：
 
         A table is a variable holding an entire relation as its value。
 
      有了前面这些知识作为基础，大家可以思考下，如果更新或者修改一个table，意味着什么呢？无论变化多么细微， 你都将改变整个relation.也就是说，你不会只是改变某个行或列，实际上你会用一个relation去交换一个新的relation. 在新的relation里， 包含有你希望改变的行和列。
 
      接下来   ，我们介绍视图的概念。
 
      然而不能说视图就是table. 这 就比如说，代数表达式x+y本身不是一个数字，但是如果给表达式赋值，它可以得到一个数字。例如，如果数据系统管理员（DBA）把一个大的table拆成2个小的table，他可以创建一个视图，这个视图看起来就与拆分前的table一模一样。实际上，这个。这样，对于用户和应用程序来说，似乎就没有差别。这样，就实现了一种逻辑数据的独立性。
 
      逻辑数据的独立性，不仅仅体现在用户查看数据的时候。实际上，你也可以对视图进行写操作，就像对普通的table进行写操作一样。
 
      
 
       结构组件是其它组件的基础，它定义了信息表示的表格或形式。定义的规则最早由codd提出。
 
      信息原理：关系数据库中的所有信息都是在逻辑层明确表示，并且只通过唯一的方式表示。这种唯一的方式就是通过表（table）中的value来表示。
 
       也可总结如下：
 
     数据库中的所有信息内容都是通过表（table）中的由行和列共同确定的位置处存放的值来表示的。这种表示方式是唯一的。
 
        逻辑层指的是用户查看数据库和查找其中的数据的方式。它有2个重要属性：
 
       第一，逻辑层的视图（VIEW）由表（table）组成，table由许多行（rows）组成，行由许多value值组成；
 
       第一，逻辑层的视图（VIEW）与数据库系统是完全独立的，包括实现它的软件技术和硬件技术；
 
       也就是说，逻辑层的表示自成体系，完全不同于数据库的具体实现方式、数据库的物理存储方式以及数据库内部如何操作数据。如果数据库供应商决定改变数据库表格（tables）在磁盘上的存储方式，信息原理保证了这种物理层的改变不能影响数据的逻辑表示，即你看到数据的方式是不能改变的。可以参看下面的示意图深入体会下：
 
     
 
            可见，信息原理的强制性特点，使得我们无论采用什么硬件，无论运行什么操作系统，无论采用什么方法来实现软件，用户都可以看到完全一致的信息逻辑视图。
 
           我们已经知道，数据库是由tables和views组成的。你也许还想知道，如何在数据库中找到指定的数据呢？ 所有的表，视图，约束条件以及其他数据库对象都注册到了系统目录中。
 
          
 
（2）完整性组件:
 
        定义了结构性组件中relation内部和relation(或者table)之间的生成和维持关联性（relationship）的方法。这些方法以规则的形式表示，被称为约束条件（constraints）.完整性组件有三种原理类型：（一）domain integrity域的完整性，该类型主要限制了列中的值大小；（二）实体完整性(entity integrity)，主要控制table的行数；（三）引用（referential）完整性，主要管理表（table）之间的关系。
 
       
 
 
 
 
 
 
（3）操纵性组件:
 
         定义了用于操纵或管理信息的方法，如relations。这些方法起源于数学中的关系代数理论和关系微积分理论。