关系数据库中关系由什么表示

关系数据库

​ 数据模型是实际全球数据特性的模仿和抽象。在数据库中用数据模型这个工具来抽象、表现和处置实际全球中的数据和信息。数据模型通常由数据布局、数据操纵和完备性束缚三部分构成,称为数据模型三要素。

  • 数据布局:所研究对象种类的聚集。这些对象是数据库的构成部分,重要包括两类:一类是与数据种类、内容、性子有关的对象。另一类是与数据之间联系有关的对象。数据布局是对系统静态特性的描述,是描画一个数据模型性子最重要的方面,因此在数据库系统中,人们通常根据其数据布局的种类来定名数据模型。比方,条理布局、网状布局和关系布局的数据模型分别定名为条理模型、网状模型和关系模型。
  • 数据操纵:对数据库中种种对象容许实行的操作聚集及有关的操作规矩。常用的数据操纵有检索和更新(包括新增、删除、修改)。数据模型必须定义这些操作的确切含义、操作标记、!操作规矩(如优先级)以及实现操作的语言。数据操纵是对系统动态特性的描述。
  • 数据的束缚条件:是一组完备性规矩的聚集。完备性规矩是给定命据模型中数据及其联系所具有的制约和储存规矩,用来限定切合数据模型的数据库状态以及状态变革,以保证数据的准确性、有用性和相容性。

关系模型

  • 关系模型的数据布局:数据布局非常单一,无论是实体还是实体间的联系,均由单一的布局来表现,该布局是一张规定化了的二维表,由行和列构成,称之为关系。
  • 关系模型的数据操纵:包括查询、新增、删除、修改,此中查询的表达本领是最重要的部分。关系模型数据操纵的特点是聚集操作,即操作的对象和结果都是聚集,这种操作方法也称为一次一聚集方法。
  • 关系模型的完备性束缚:包括实体完备性、参照完备性和用户定义的完备性三大类。此中实体完备性和参照完备性是关系模型必须满意的完备性束缚条件,由关系DBMS主动支持,用户定义的完备性是由应用范畴需要遵照的束缚条件,是详细范畴中的语义束缚。

关系的数学定义

    域(Domain):一组具有相同数据种类的值的聚集,如整数、实数等。情势化表现为D

    笛卡尔积(Cartesian Product) :一组域D1,D2,…Dn的笛卡尔积:

此中(d1,d2,d3,…dn)称为一个元组,di称为一个分量;若Di的基数(值的个数)为Mi,则笛卡尔积的 基数 M为:

  • 数学上关系是笛卡尔积的任意子集,但在实际应用中关系是笛卡尔积中所取的故意义的子集。
    比方:教师关系中的两个域姓名D1 、性别D2分别如下:D1={李力,王平,刘伟},D2={男,女}。表2虽然是表1的子集,但在实际中却如任何意义。因此可以说关系是故意义的笛卡尔积的子集。
  • 关系的基本术语

    • 元组(Tuple):关系表中每一个横行称作一个元组,构成元组的元素称为分量。
    • 属性(Attribute):关系中的每一列即为一个属性,都有一个属性名。一个关系中每每有多个属性,用于描画实体的特性,由于关系中的属性名具有标识列的作用,因而同一关系中的属性名不能相同。
    • 主码(Primary Key)当一个关系有多个候选码时,选定此中的一个候选码为主码。若关系中只有一个候选码,则这个唯一的候选码就是主码。

    • 主码是关系模型中的一个重要观点。每个关系必须选择一个主码,选定以后,不能随意改变。每个关系肯定有且仅有一个主码,由于关系的元组无重复,至少关系的全部属性的组合可作为主码。
    • 主属性(Prime Attribute)和非主属性(Non-Prime Attribute)主码中的属性称为主属性,不包含在主码中的属性称为非主属性。

    • 有些教科书把候选码中的属性称为主属性,不包含在任何候选码中的属性称为非主属性。如表3-2中,“姓名”为主属性,“性别”及“年纪”属性黑白主属性。
      若无特殊说明,本书接纳前肯定义,即主码中的属性称为主属性。
    • 外码(Foreign Key) 假如关系R2的一个或一组属性X不是R2的主码,而是另一关系R1的主码,则该属性或属性组X称为关系R2的外码,并称关系R2为参照关系(Referencing Relation),关系R1为被参照关系(Referenced Relation)。

        由外码的定义可知,被参照关系的主码和参照关系的外码必须定义在同一个域上。在实际的应用中,为了便于辨认,当外码与相应的主码属于差别的关系时,每每给它们取相同的名字,不外需要指出的是,外码并不肯定要与相应的主码同名。

        比方,表3-4是学生关系,学号属性为其主码,表3-5是选课关系,学号与课程号的属性组合为其主码,则选课关系中的“学号”属性不是该关系的主码,但却是学生关系的主码。根据外码定义,“学号”属性为选课关系的外码,选课关系为参照关系,学生关系为被参照关系。

    关系的种类

  • 关系分为基本表、视图表和查询表。这三种种类的关系以差别的身份保存在数据库中,其作用和处置方法也各不相同。
    • 基本表:是关系数据库中实际存在的表,是实际存储数据的逻辑表现。
    • 视图表:是由基本表或其他视图表导出的表。视图表是为数据查询方便、数据处置轻便及数据安全要求而计划的虚表,它不对应实际存储的数据。由于视图表依附于基本表,我们可以使用视图表进行数据查询,或使用视图表对基本表进行数据维护,但视图表本身不需要进行数据维护。
    • 查询表:是查询结果表或查询中天生的暂时表。由于关系运算是聚集运算,在关系操作過逞中会产生一些暂时表,称为查询表。尽管这些查询表是实际存在的表,但其数据可以从基本表中再抽取,且一样平常不再重复使用,以是查询表具有冗余性和一次性,可以以为它们是关系数据库的派生表。
  • 关系的基天性质

    • 列是同质的。每一列中的分量是同一种类的数据,来自同一个域。
    • 差别列可来自同一个域。每一列为一个属性,差别的属性要赐与差别的属性名。
    • 列的位置具有次序无关性,列的序次可以任意互换。由于列次序是可有可无的,因此在很多实际关系数据库产品中,增长新属性时,一样平常是插至最后一列。
    • 任意两个元组不能完全相同。这是由笛卡尔积的性子决定的。
    • 元组的位置具有次序无关性,元组的序次可以任意互换。
    • 分量必须取原子值,即每一个分量都必须是不可分的数据项。下表是数据库中不容许出现的布局。

    关系模式

    ​ 关系的描述称作关系模式,包括关系名、关系中的属性名、属性向域的映象!、属性间的数据依靠关系等,其情势化描述为:

    R(U,D,dom,F),简记作R(U)或R(A1 , A2 ,…, An ) 。

    • 属性向域的映象一样平常直接说明为属性的种类、长度等。
    • 某一时候对应某个关系模式的内容(元组的聚集)称作关系。
    • 关系模式是型,是稳定的,静态的。关系是某一时候的值,是随时间不停变革的,是动态的。

    关系操作

    • 关系操作:包括数据查询、数据维护和数据控制三大功能。
    • 关系操作语言根据其理论(查询的表达方法)的差别可分为以下三类:
      • 关系代数语言:关系代数语言是一种通过关系的运算来表达查询要求的语言。
      • 关系演算语言:关系演算语言是一种通过查询结果元组应满意的谓词条件来表达查询要求的语言。
      • 基于映象的语言:基于映象的语言是一种具有关系代数和关系演算双重特点的语言。

    关系代数

  • 差(Difference):关系R与关系S的差由属于R而不属于S的全部元组构成,即R中删去与S中相同的元组,构成一个新关系,其结果仍为n目关系。记作:
    R-S={t|t∈R∧┐t∈S}。
  • 交(Intersection):关系R与关系S的交由既属于R又属于S的元组构成,即R与S中相同的元组,构成一个新关系,其结果仍为n目关系。记作:R∩S={t|t∈R∧t∈S}。
  • 广义笛卡尔积(Extended Cartesian Product):两个分别为n目和m目关系R和S的广义笛卡尔积是一个(n+m)列的元组的聚集,元组的前n列是关系R的一个元组,后m列是关系S的一个元组。若R有k1个元组,S有k2个元组,则关系R和关系S的广义笛卡尔积有k1*k2个元组,记作:
    R×S={tr⌒ts|tr∈R,∧ts∈S}
  • 象:
  • 运算实例

  • 选取

  • 选取运算:是单目运算,是根据肯定的条件在给定的关系R中选取多少个元组,构成一个新关系,记作:
  • 此中,σ为选取运算符,F为选取的条件,它由运算对象(属性名、常数、简单函数)、算术比较运算符( > ,≥,<,≤,=,≠)和逻辑运算符(∨ ∧ ┐)连接起来的逻辑表达式,结果为逻辑值“真”或“假”。
  • 投影

  • 投影是单目运算。关系R上的投影是从R中选择出多少属性列,构成新的关系,从左到右根据指定的多少属性及次序取出相应列,删去重复元组。记作:
  • 此中A是R中的属性列, 为投影运算符, 为R中元组相应于属性集A的分量。

    前言

    此文是用以快速回首关系数据库重要计划步骤的几篇散文中的第三篇,描述的是数据库计划中的第三阶段——物理模型(physical model)计划的步骤,对应 (Connolly and Beg 2015) 第18和19章的内容。为方便读者查阅原书相关内容,我已在本文中给出了重要观点的英文名称。

    步骤1:根据目的数据库管理系统特性对逻辑模型进行转换

    计划关系数据库物理模型的第一步是将逻辑模型中定义的关系(relation)转换成可以由目的数据库管理系统(database management system, DBMS)实现的情势。此步骤又可以进一步细分为以下三个小步骤。

    步骤1.1:定义底子关系

    使用目的数据库的数据定义语言(data definition language, DDL)定义底子关系。在定义时应偏重关注以下要点:

    • 关系的名称;
    • 底子属性(base attribute)的名称、定义域(内容包括数据种类、长度、正当值、能否为空等)、默认值;
    • 主键(primary key)、可更换键(alternate key)、外键(foreign key),需要特殊一提的是,在定义外键时不但要描述属性的参照关系,还应该描述当参照完备性遭到粉碎时,应该接纳何种策略(比方NO ACTION、CASCADE等,详见 另一篇文章 的相关介绍)应对。

    步骤1.2:选择派生数据的表现方法

    针对每个派生属性(derived attribute),思量是否需要在数据库中存储其数据值。一样平常而言,思量重要基于以下几个因素:

    • 存储开销;
    • 盘算开销,以及目的DBMS是否支持相关盘算;
    • 维护数据同等性的难度。

    假如经过思量,决定要在数据库中存储某派生属性的话,应该在对应关系的DDL中增长该属性的定义,并通过解释说明其盘算方法。

    步骤1.3:计划用户定义完备性束缚

    在步骤1.1中,我们通过设置定义域、主键和外键保证了定义域完备性(domain integrity)、实体完备性(entity integrity)和参照完备性(referential integrity)。而在此步骤1.3中,我们需要进一步美满数据完备性,并设置逻辑模型中描述的用户定义完备性(user-defined integrity);实现该类完备性的方法重要包括:

    • 在DBMS中设置 CHECK 束缚;
    • 在DBMS中设置触发器(trigger);
    • 编写特定的应用程序代码。

    步骤2:选择文件组织方法和索引

    计划关系数据库物理模型的第二步是选择合适的文件组织方法和索引,以便满意系统性能需求。此步骤又可以进一步细分为以下四个小步骤。

    步骤2.1:分析事务

    在此步骤中,可以借助事务/关系交织引用矩阵(transaction/relation cross-reference matrix)、事务使用图(transaction usage map)、事务分!析表(transaction analysis form)等本领理解系统中存在那些重要的事务、以及这些事务的相关信息,比方:所涉及的关系、属性(在分析时应特殊关注属性的用法,比方是否出如今WHERE或JOIN等子句中)、访问种类(查询、插入或更新)及数据量,运行频率、峰值实时间段等等。

    步骤2.2:选择文件组织方法

    在目的DBMS支持的条件下,为每个关系选择最佳的文件组织方法;假如目的DBMS不支持用户选择文件组织方法,则跳过此步骤。

    原书附录F.7介绍了选择文件组织方法的一样平常性原则,此处不再赘述。

    步骤2.3:选择索引

    在决定是否为某些属性创建索引时,可以参考以下一样平常指南:

    1. 不要为仅含有少量数据的关系创建索引,由于直接从内存中进行搜索大概更快;
    2. 一样平常来说,假如尚未为主键构建索引,则应该补建索引(一样平常来说,DBMS会主动为主键构建索引,但也大概有破例);
    3. 假如一个外键常常被访问,则应该为其构建索引(有的DBMS会主动为外键构建索引);
    4. 假如一个可更换键常常被使用,那么应该为其构建索引;
    5. 为常常出如今WHERE、JOIN、ORDER BY、GROUP BY子句中的属性创建索引;
    6. 为常常出如今聚集函数(aggregate function)中的属性创建索引;
    7. 为能产生仅用索引计划(index-only plan)的属性创建索引;
    8. 制止为常常需要插入、删除、更新的关系或属性创建索引;
    9. 假如查询大概检索出占关系中相当比例(好比>25%)的元组,就应该制止为关系中的属性添加索引,由于直接在内存中检索大概更快;
    10. 制止为长字符串种类的属性构建索引。

    步骤2.4:预计硬盘空间需求

    预计硬盘空间需求,以决定系统硬件设置。

    原书附录J介绍了怎样对数据库中关系的大小进行评估的方法,此处不再赘述。

    步骤3:计划用户视图

    计划关系数据库物理模型的第三步是使用目的数据库DDL定义在需求分析阶段产生的用户视图(user view)。

    步骤4:计划安全机制

    计划关系数据库物理模型的第四步是根据需求分析结果为数据库设置安全机制,以实现系统安全(system security)和数据安全(data security)。此中,系统安全内容涵盖数据库系统层面上的访问和使用,如用户名和密码等;数据安全内容则涵盖用户对数据库对象(如关系、视图等)的访问、使用以及可进行的操作。

    原书第20章对安全进行了更全面的讨论,此处不再赘述。

    步骤5:思量引入可控冗余

    计划关系数据库物理模型的第五步是联合系统性能,思量是否需要对关系进行去规定化(denormalization)。通常来说,假如系统性能无法满意要求,而且查询所涉及的关系具有较低的更新频率但同时具有较高的查询频率,去规定化就很大概是一种有用的策略。详细而言,可以思量以下逆规定化操作:

    1. 归并一对一(1:1)联系;
    2. 在一对多(1:*)联系中引入重复的非键属性(non-key attribute)以淘汰连接操作;
    3. 在一对多(1:*)联系中引入重复的外键属性以淘汰连接操作;
    4. 在多对多(*:*)联系中引入重复属性以淘汰连接操作;
    5. 引入重复组(repeating group);
    6. 创建抽取表(extract table);
    7. 对关系进行分区(partitioning)。

    每种操作的实用条件及所需留意的问题请拜见原书第19章,此处不再赘述。

    步骤6:对系统性能进行监测并调优

    计划关系数据库物理模型的第六步是监控系统运作环境,并保证系统性能满意需求。系统性能重要通过事务吞吐率、相应时间和磁盘占用空间三个指标来评价;当发现这些指标达不到要求时,需要寻找性能瓶颈,并进行有针对性的优化。

    小结

    本文扼要描述了关系数据库逻辑模型计划的重要步骤。对于本文中提到、但未深入解说的内容,感爱好的读者可以从原书 (Connolly and Beg 2015) 相关章节中获取更多信息。

    参考文献

    Connolly, Thomas M., and Carolyn E. Beg. 2015. Database Systems: A Practical Approach to Design, Implementation, and Management . Sixth edition. Boston: Pearson.

    概叙

    关系数据库的基本特性是使用关系模型的组织数据,20世纪80年代以后,在商用DBMS中,关系模型渐渐代替早期的网状模型和条理模型。

    关系数据模型

    作为数据模型,关系模型包含三个构成要素:关系数据布局、关系操作聚集和关系完备性束缚。

    关系数据布局

    布局只包含单一的数据布局(关系),实际全球的实体与实体间的种种联系均用关系来表现。关系模型是把数据库表现为关系的聚集,并以二维表格的情势组织数据。

    录入一张二维表格如:

    学号 姓名 性别 籍贯 民族
    001 张三 陕西
    002 李四 湘西
    003 王五 河北
    004 赵六 东北

    基本术语

    1. 表(Table):也称为关系,是二维数据布局,由表名、组成表的各列及多少行数据构成,每个表由唯一的表名,每一行数据描述一条详细的记载值。
    2. 关系(Relation):一个关系逻辑上对应一张二维表,可以为每个关系取一个名称来标识。关系有三种种类:基本关系(基表,实际存在的表,是实际存储数据的逻辑表现)、查询表(查询布局对应的表)和视图表(由基本表或其他视图导出的表,不对应实际存储的数据)。
    3. 列(Column):称为字段(Field)或属性(Attribute)。每一列有一个名称,表现实体属性,具有相同数据种类。在一个数据库中,表名,字段名必须唯一,差别的表可以有相同的字段名,且定名须故意义,简单。
    4. 属性(Attribute):表列即属性,给属性起名即属性名。属性的个数称为关系的元或度。列值为属性值;取值范畴为值域。
    5. 行(Row):称为元组(Tuple)或记载(Record)。表中的数据按行存储,一行数据即一条记载或元组,每行又多少个字段值构成。
    6. 分量(Component):元组的属性值为分量
    7. 码/键(key):在一个关系中,有一个属性或属性组,能用来标识该关系的元组,则为该关系的码或键。
    8. 超码或超键(Super Key):从码中去除某个属性,它仍旧是对应关系的码,则为超码;每个关系至少有一个默认的超码(全部属性的聚集)。
    9. 候选码或键(Candidate Key):关系中的一个码或键中,不能去除任何一个属性,不然它就不是对应关系表的码或键,则此码为候选码(键),它是关系表中最小的超码或超键。
    10. 主键/码(Primary Key):在一张关系表中的多少候选键中指定一个用来唯一标识该关系的元组,则该候选键为主键。
    11. 全键/码(All-Key):一个关系中全部的属性聚集是是这个关系是主键/码,则为全键/码。
    12. 主/非属性(Primary Attribute/Nonprimary Attribute):关系中包含任何一个候选键/码的属性为主/码属性,不包含任何一个候选码的属性为非主/码属性。
    13. 外键/码(Foreign Key):关系中的某个属性或属性组不是这个关系的主键或候选键,而是另一个关系的主键,则该属性(属性组)为关系的外键/码。
    14. 参照关系(Referencing Relation)/被参照关系(Referenced Relation):参照关系也称从关系,被参照关系又称主关系,它们指以外码相关联的两个关系。而以外码为主码的关系为被参照关系;外码地点的关系为参照关系,这种联系通常是一对多关联。
    15. 域(Domain):指属性取值范畴。
    16. 数据种类(Data Type):每列(元关系)都有相应的数据种类,用于限定该列中存储的数据。
    17. 关系模式(Relation Schema):通数据模型一样,数据库也有型和值,在关系数据库中关系模式是型,关系是值,关系模式是对关系的描述。
    中文字段名 数据种类 宽度
    学号 字符种类 8
    姓名 字符种类 10
    身份证 字符种类 18

    上表是学生基本星系登记表关系的布局定义,关系则是元组的聚集,是关系模式在某一时候的状态或内容

    实际工作中关系模式和关系统称为关系。

  • 关系数据库(Relation Database):以关系模型作为数据的逻辑模型,并接纳关系作为数据组织方法的一类数据库,其数据库操作创建在关系代数的底子上。在给定的应用范畴中,以是关系的聚集组成一个关系数据库。
  • 在实际的数据库应用系统中,一样平常使用英文作为表名、字段名等。由于在编写数据库应用程序时,表名、字段名会作为变量名,使用中文不方便标识,且有些DBMS不能很好的兼容中文。
    因此上表应该变动为:

    含义 字段名 数据种类 宽度
    学号 studentNo 字符种类 8
    姓名 sutdentName 字符种类 10
    身份证 studentId 字符种类 18
    关系数据库对关系的限定:
    • 每个属性都不可剖析,是关系数据库对关系的最基本的限定,要求关系的每个分量必须是一个不可分的数据项,即不容许表中有表
    • 一个关系对应一种关系模式,模式中的属性的数据种类及属性的个数是相对固定的
    • 每个关系模式中的属性必须定名,在同一模式中,属性名必须是差别的
    • 同一关系中不容许出现候选码或键值完全相同的元组
    • 关系中的元组次序是可任意互换
    • 关系中的属性次序可以任意互换

    本文网址: http://www.appike.com/d/202102224830_6295_639927311/home