精华内容
下载资源
问答
  • 数据库关系规范化
    千次阅读
    2019-05-26 14:18:10
    • 在关系数据库中,所有的数据文件都以 二维表的形式存在,这些二维表之间通常会 产生数据冗余,这样容易造成数据的不一致 或不完整,从而使数据的检索、插入、删除 和更新和等操作可能会出现错误。解决这种 问题的一个办法就是将这些关系进一步的分 解。这种分解的过程就叫做规范化。
    第一范式1NF
    • 第一范式的目标是确保每列的原子性 如果每列都是不可再分的最小数据单元(也称为最小的原子单 元),则满足第一范式(1NF)
    第二范式2NF
    • 如果一个关系满足1NF,并且除了主键以外的其他列,都依赖于该主键,则满足第二范式(2NF)第二范式要求每个表只描述一件事情
    • 这种关系不仅满足第一范式,而且所有非主属性完全依赖于其主键
    第三范式3NF
    • 如果一个关系满足2NF,并且除了主键以外的其他列 都不传递依赖于主键列,则满足第三范式(3NF)
    • 这种关系不仅满足第二范式,而且它的任何一个 非主属性都不传递依赖于任何主关键字。
    更多相关内容
  • 关系数据库设计:谈谈规范化技术

    千次阅读 多人点赞 2020-08-19 21:42:31
    通过实际案例介绍关系数据库设计中的规范化技术(Normalization),为什么需要规范化,常见的第一范式、第二范式和第三范式,反规范化应用的场景以及外键的取舍问题。

    在这里插入图片描述


    大家好,我是只谈技术不剪发的 Tony 老师。今天我们来聊聊关系数据库的规范化设计问题。本文不涉及数据库教材上晦涩难懂的各种公式,而是从实际应用出发,通过简单直白的方式介绍规范化的设计过程和常见范式。

    为什么需要规范化?

    很多教材和文章都是直接从第一范式开始介绍如何进行数据库设计,完全忽略了对事物前因后果的分析;从而导致我们看完之后,只知道要关系数据库要进行规范设计,但却不知道为什么要这么做。因此,我们首先来给大家介绍一下规范化之前发生了什么。

    假设我们需要为某公司设计一个数据库,用于管理员工、部门、职位等相关的信息。首先从直观上考虑,可以将员工信息、所在部门以及职位信息存储到一个表中,如下图所示:

    0nf
    每一行数据对应一个员工的信息,包括他/她所在的部门、职位等。如果真的这么设计,我们在实际应用中很快就会发现以下各种问题:

    • 数据冗余,同一个部门的信息存储了多份,这就需要占用更多的磁盘空间。另外,数据冗余有时候也可能是指在不同的表中存储了重复的信息;
    • 插入异常,假如现在需要成立一个新的部门,由于还没有增加新的员工,因此无法录入这个部门的信息;
    • 更新异常,如果需要修改某个部门信息,需要更新多行数据,效率低下;不小心忽略了某些记录的话,还会会导致数据不一致,尤其是当一个信息存储到多个表中时更容易出现这种情况。
    • 删除异常,如果某个部门的所有员工都被删除,将会导致这个部门的信息也将不复存在;

    关系数据库之父 Edgar F. Codd 显然意识到了这些问题,并且为此引入了规范化(Normalization)的设计过程。规范化使用范式(normal form)来定义和衡量,范式就是数据库设计时遵循的一种标准级别。Codd 最早提出了第一范式(1NF)、第二范式(2NF)以及第三范式(3NF),每个范式都基于前面的范式定义,例如第二范式需要先满足第一范式。

    📝更高级别的范式包括 BC 范式(BCNF)、第四范式(4NF)、基本元组范式(ETNF)、第五范式(5NF)、DK 范式(DKNF)以及第六范式(6NF);一般来说,满足第三范式的数据库就可以避免数据冗余和操作异常问题。

    通过以上介绍,我们知道了规范化是数据库设计过程中的一系列原理和技术,使用范式来定义和衡量,主要用于减少表中数据的冗余,消除异常,提高数据完整性和一致性

    下面我们基上面的非规范化数据库结构,逐步介绍第一范式到第三范式的实现过程。

    第一范式

    第一范式(First Normal Form)要求满足以下条件:

    • 表中的字段都是不可再分的单一属性;
    • 表需要定义主键(PRIMARY KEY)。

    简单来说,首先就是每个属性要有单独的字段。在上面的不规范设计中,员工的个人电话和工作电话存储在一个字段中,破坏了原子性。另外,还需要为表定义一个主键,用于唯一识别表中的每一行数据;假设每个部门中的员工不会同名,可以使用部门名称加员工姓名作为主键。

    将上面的示例修改成以下结构就可以满足第一范式:

    1nf
    第一范式要求表中的字段具有不可分割的原子特性;不过我们知道,原子是化学反应不可再分的基本微粒,但在物理状态中可以分割,它是由原子核和绕核运动的电子组成。因此,我们同样需要考虑字段不可分割到底是针对什么而言。

    例如,上面的“姓名”字段,实际上也可以拆分成两个字段:姓氏和名字。那么到达要不要拆分呢?显然这个取决于应用程序如何使用这些信息,一般我们将姓名作为一个字段存储;有些应用可能需要拆分,这样在给客户发送消息时可以方便地显示为“尊敬的刘先生/女生”。

    另一个类似的情况是地址信息,例如“XX省XX市XX区XX小区”,存储到一个字段还是拆分成多个字段?大部分情况下,应用程序可能需要统计不同地区的用户情况,拆分成多个字段便于分析。不过这时候需要注意的是如何确保数据的标准化,因为不同的用户虽然住在相同的小区,但会输入不一致的数据;所以最好提供一组标准的数据,提供下拉列表给用于进行选择。

    除了基本的数字、字符、日期等数据类型之外,SQL 还提供了一些复杂的类型,例如数组、XML、JSON 以及自定义类型等。假如我们使用一个 JSON 字段存储电话号码,数据如下所示:

    {
      "phoneNumbers": [
        {
          "type": "office",
          "number": "61238888"
        },
        {
          "type": "mobile",
          "number": "13612345678"
        }
      ]
    }
    

    那么这种设计算不算违反第一范式?从定义来说这显然不属于第一范式,因为这个字段中包含了多个可以分割的属性。

    但是,从 SQL 标准来说这些类型都属于原生类型,而且提供了对这种数据进行处理和查询的内置函数和方法;如果从应用程序的角度来看,例如电商平台中的产品信息、博客文章中的评论信息,可以将它们看作一个原子数据存储在 XML 或者 JSON 字段中,因为没有进行分割处理的需求。

    📝SQL 是关系数据库的标准语言,但 SQL 远远不只能够存储和处理关系模型,XML 或者 JSON 文档、多维数组、图形存储以及流数据处理已经成为了 SQL 标准中的一部分,具体可以参考这篇文章

    以上表结构满足第一范式,但仍然存在数据冗余(例如部门信息),可能导致插入异常、删除异常、修改异常等问题;所以我们还需要进一步规范化。

    第二范式

    第二范式(Second Normal Form)要求满足以下条件:

    • 满足第一范式;
    • 非主键字段必须完全依赖于主键或者候选键,不能只依赖于主键或者候选键的一部分。

    上面表结构中的“部门地址”取决于“部门名称”,也就是主键的一部分;这种依赖关系称为部分函数依赖(partial functional dependency)。显然,此时表中的部门信息存在冗余,可能导致各种操作异常。

    为此我们可以将部门信息单独存储到一张部门表中,并且在部门表和员工表之间维护一个一对多的关系。我们继续将表的结构修改如下:

    2nf
    我们将员工表拆成了 3 个表,员工表中的部门编号和职位编号是外键,分别引用了部门表的主键和职位表的主键。另外,我们为每个表增加了一个 id 主键字段(工号、部门编号、职位编号)。因为部门名称、职位名称等信息并不适合作为主键;如果使用部门名称作为主键,当需要修改某个部门的名称,员工表中可能需要相应修改多条记录。

    如果考虑到同一个部门中可能存在同名的员工,直接在员工表中增加一个 id 主键字段也可以满足第二范式的要求。

    2nf
    以上表结构满足第二范式,但仍然存在数据冗余(例如部门信息),可能导致插入异常、删除异常、修改异常等问题;所以我们还需要进一步规范化。

    第三范式

    第三范式要求满足以下条件:

    • 满足第二范式;
    • 属性不依赖于其它的非主属性,也就是非关键字段不依赖于其他非关键字段。

    当主键决定字段 A,字段 A 又决定字段 B 时,称为传递函数依赖(transitive functional dependency)。例如员工编号决定了部门编号,部门编号决定了部门名称;如果将部门信息和员工信息放在一张表中,就存在这种依赖。显然,在上一节中将员工表拆分成三个表之后就不存在这种问题,因此满足第三范式。

    最终,我们设计的公司数据库结构(ER 图)如下:

    erd
    其中,部门和员工的关系是一对多的关系;职位和员工的关系也是一对多的关系。

    现在我们来回顾一下非规范化设计时的几个问题:

    • 部门、员工以及职位信息分别存储一份,通过外键保持它们之间的联系。因此,不存在数据冗余的问题;
    • 如果想要成立一个新的部门,直接录入部门信息即可,解决了插入异常的问题;
    • 如果某个部门的所有员工都被删除,该部门的信息不会受到影响,不存在删除异常;
    • 如果需要修改部门信息,直接更新部门表即可,不会导致数据不一致。

    对于前三个范式而言,只需要将不同的实体/对象单独存储到一张表中,并且通过外键建立它们之间的联系即可满足。这也是大多数在线交易系统数据库理想的设计方法。

    反规范化

    简单来说,规范化就是将大表拆分成多个小表,并且通过外键建立它们之间的联系。但是,规范化可能导致连接查询(JOIN)过多。例如,为了查看员工所在的部门名称和职位名称,我们需要关联查询 3 个表:

    SELECT e.emp_name, e.hire_date, d.dept_name, j.job_title
    FROM employee e 
    JOIN department d ON (d.dept_id = e.dept_id)
    JOIN job j ON (j.job_id = e.job_id)
    WHERE e.emp_name = '孙尚香';
    
    emp_name|hire_date |dept_name|job_title|
    --------|----------|---------|---------|
    孙尚香   |2002-08-08|财务部    |财务经理  |
    

    如果表中的数据量很大,过多的表连接查询会增加数据库的 IO 操作,从而降低数据库的性能。因此,有时候为了提高某些查询或者应用的性能而故意降低规范反的程度,也就是反规范化(denormalization)。一般来说,数据仓库(Data Warehouse)和在线分析系统(OLAP)会使用到反规范化的技术,因为它们以复杂查询和报表分析为主。

    常用的反规范化方法包括增加冗余字段、增加计算列、将小表合成大表等。例如想要知道每个部门的员工数量的话,需要同时连接部门表和员工表;可以在部门表中增加一个字段(emp_numbers),查询时就不需要再连接员工表,但是每次增加或者删除员工时需要更新该字段。

    需要注意的是,反规范化会增加更新和修改数据的开销,导致数据存在冗余,可能带来数据完整性和一致性的问题;因此,通常我们应该先进行规范化设计,再根据实际情况考虑是否需要反规范化

    关于外键

    在数据库结构设计时,还有一个经常争论的问题就是需不需要使用外键(FOREIGN KEY)。外键是数据库用于实现参照完整型的约束,利用数据库的外键可以保证数据的完整性和一致性;外键的级联操作可以方便数据的自动处理,减少了程序出错的可能性。

    例如,员工属于部门,员工的部门字段上可以创建一个外键引用部门表的主键。此时,我们必须先创建部门,然后才能为该部门创建员工;不会出现员工属于一个不存在的部门的情况,保证了数据的完整性。同时,如果要删除一个部门的话,必须同时处理该部门下的员工;可以选择级联删除员工或者将员工的部门修改为其他部门等操作。

    既然外键拥有这么多好处,为什么我们还要讨论是否需要使用外键呢?主要是性能问题。因为任何事情都是有代价的,数据库为了维护外键需要牺牲一定的性能,尤其是在大数据量高并发的情况下。因此出现了另一种解决方案,就是将完整性检查放到应用层去实现,而应用程序相对比较容易扩展。

    不过,在应用端实现约束也可能导致一些问题。首先,无法百分之百保证不会出现问题,尤其是多个应用同时共享一个数据库时。缺失外键可能导致数据库的结构不明确,需要依赖相应的文档进行说明。

    总之,在系统的设计之初应该尽量使用外键确保完整性。如果随着业务增长出现性能问题,可以考虑在应用中实现约束。


    总结

    本文从非规范化数据库结构可能导致的问题出发,介绍了关系数据库为什么应该进行规范化设计以及常用的各种范式。同时,我们还讨论了特殊应用场景下的反规范化问题和外键的取舍。

    如果觉得文章对你有用,欢迎关注❤️、评论📝、点赞👍

    展开全文
  • 关系规范化

    千次阅读 2020-07-04 21:24:15
    关系规范化的目的 关系规范化的目的是为了消除储存异常,减少数据冗余,以保证数据的完整性,正确性,一致性和储存效率,一般讲关系规范到III范式即可 1NF范式 一个关系的每个属性都是可再分的基本数据项,则该...

    关系规范化的目的

    关系规范化的目的是为了消除储存异常,减少数据冗余,以保证数据的完整性,正确性,一致性和储存效率,一般讲关系规范到III范式即可

    1NF范式

    一个关系的每个属性都是不可再分的基本数据项,则该关系是I范式

    2NF范式

    II范式首先要满足I范式,而且关系中的每一个非主属性完全函数依赖于主关键字,则该关系是II范式

    个人理解:就是表中除主键其他的所有属性都要完全依赖主键,不能不完全

    实例:
    在这里插入图片描述

    将非II范式规范为II范式的方法

    将部分函数依赖关系中的主属性(决定方)和非主属性从关系中提取出来,单独构成一个关系

    实例分析: 学生成绩表主关键字/主键(学号,课程名称),成绩完全依赖主关键字。姓名不完全依赖主键,只依赖学号,所以讲学号和姓名单独构建成一个表

    3NF范式

    III范式首先要满足II范式,且关系中的每一个非主属性都不完全函数传递依赖主关键字,则此关系是III范式

    在这里插入图片描述

    展开全文
  • 关系模式的规范化理论

    千次阅读 2019-05-11 19:43:44
    范式级别可以逐级升高,而升高规范化的过程就是逐步消除关系模式中合适的数据依赖的过程,使模型中的各个关系模式达到某种程度的分离。一个低一级范式的关系模式,通过模式分解转为若干个高一级范式的关系模式的...

    关系模式规范化的定义

    到目前为止,规范化理论已经提出了六类范式。范式级别可以逐级升高,而升高规范化的过程就是逐步消除关系模式中不合适的数据依赖的过程,使模型中的各个关系模式达到某种程度的分离。一个低一级范式的关系模式,通过模式分解转为若干个高一级范式的关系模式的集合,这种分解过程叫作关系模式的规范化(Normalization)。

     

    关系模式规范化的目的和原则

    一个关系只要其分量都是不可分的数据项,就可称它为规范化的关系,但这只是最基本规范化。规范化的目的就是使结构合理,消除存储异常,使数据冗余尽量小,便于插入、最除和更新。
    规范化的基本原则就是遵循“一事一地”的原则,即一个关系只描述一个实体或者实体间的联系。若多于一个实体,就把它“分离”出来。因此,所谓规范化,实质上是概念的单一化,即个关系表示一个实体。

     

    关系模式规范化的步骤

    规范化就是对原关系进行投影,消除决定属性不是候选键的任何函数依赖。具体可以分为以下几步。
    (1)对1NF关系进行投影,消除原关系中非主属性对键的部分函数依赖,将1NF关系转换成若干个2NF关系。
    (2)对2NF关系进行投影,消除原关系中非主属性对键的传递函数依赖,将2NF关系转换成若干个3NF关系。
    (3)对3NF关系进行投影,消除原关系中主属性对键的部分函数依赖和传递函数依赖,也就是说,使决定因素都包含一个候选键,得到一组BCNF关系。
    (4)对BCNF关系进行投影,消除原关系中的非平凡且非函数依赖的多值依赖,得到一组4NF的关系。

    关系规范化的基本步骤如图所示。

     

    规范化过程

     

     

    一般情况下,我们说没有异常弊病的数据库设计是好的数据库设计,一个不好的关系模式也总是可以通过分解转换成好的关系模式的集合。但是在分解时要全面衡量,综合考虑,视实际情况而定。对于那些只要求查询而不要求插入、删除等操作的系统,几种异常现象的存在并不影响数据库的操作。这时便不宜过度分解,否则当对系统进行整体查询时,需要更多的多表连接操作,这有可能得不偿失。在实际应用中,最有价值的是3NF和BCNF,在进行关系模式的设计时,通常分解到3NF就足够了。

     

    关系模式规范化的要求

    关系模式的规范化过程是通过对关系模式的投影分解来实现的,但是投影分解方法不是唯的,不同的投影分解会得到不同的结果。在这些分解方法中,只有能够保证分解后的关系模式与原关系模式等价的方法才是有意义的。
    判断对关系模式的一个分解是否与原关系模式等价可以有三种不同的标准。
    (1)分解要具有无损连接性;
    (2)分解要具有函数依赖保持性;
    (3)分解既要具有无损连接性,又要具有函数依赖保持性。

     

     


    参考资料:[1]陈志泊,王春玲,许福,范春梅.数据库原理及应用教程(第3版)[M].北京:人民邮电出版社,2014:159-160.
     

     

     

    展开全文
  • 数据库原理-关系模式的规范化

    千次阅读 2021-08-26 12:29:02
    一个关系只要其分量都是可分的数据项,它就是规范化关系,但这只是最基本的规范化 规范化程度可以有6个不同的级别,即6个范式 规范化程度过低的关系不一定能够很好地描述现实世界,可能会存在插入异 常、删除...
  • MySQL关系规范化

    千次阅读 2020-10-21 21:07:08
    MySQL关系规范化 作者:就叫易易好了 时间:2020/10/21 指导老师:桃群老师 一、关系规范化 1、函数依赖 什么是函数依赖?比如学生管理系统数据库,有学生姓名(Sname)、学生系名(Sdept)、学生学号(Sno)等等。一...
  • 关系模式规范化(设计范式)

    千次阅读 多人点赞 2020-10-28 19:13:56
    数据库之六大范式详解 关系数据库中的关系满足一定要求的,满足不同程度要求的为不同的范式。...上表商品这一数据项又划分为名称和数量两个数据项,故符合第一范式关系。改正之后如下图所示:..
  • 关系模式的规范化

    千次阅读 2020-03-30 17:47:56
    了解关系模式规范化的作用 掌握第一范式-重点 掌握第二范式-重点 掌握第三范式-重点 回顾关系模式 关系模式:关系模式相当于一张二维表的框架,在这个框架下填入数据,称为关系模式的一个实例,或者叫关系(R) R...
  • 数据库设计中关系规范化理论总结

    千次阅读 多人点赞 2020-07-31 11:08:14
    数据库是一门对数据进行有效管理的技术,它研究信息资源如何被安全地储存和如何被高效地利用,它是现代计算机科学的一个重要分支。...本文通过例举具体事例来探讨关系规范化理论在数据库逻辑设计中的形成和方法。
  • [MySQL]关系规范化中的操作异常理解

    千次阅读 2019-01-02 19:25:58
    插入失败:该插入的没插入; 插入异常:该插入的被插入; 删除失败:该删除的没删除; 删除异常:该删除的被删除; 简单地说:失败:有心栽花花开,异常:无心插柳柳成荫...
  • 数据库关系模式的规范化

    千次阅读 2021-04-03 15:23:11
    1、第一范式(1NF) 在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,满足第一范式(1NF)的数据库就不是关系数据库。...例如,对于图3-2 中的员工信息表,员工信息都放在一列中显示,
  • 关系模式规范化

    千次阅读 2019-03-22 21:26:43
    3NF规范化:通过该算法可以获得一个保持函数依赖性并满足3NF的关系模式分解 先求出Fmin 1、X->A,XA=R 那么XA单独构成一个关系模式 2、如果关系模式R中的某些属性与函数依赖集F的左右部属性均无关的话,他们...
  • 关系数据库规范化理论

    万次阅读 2018-03-01 22:54:50
    1、关系规范化的作用所谓规范化,就是用形式更为简洁、结构更加规范的关系模式取代原有关系的过程。2、函数依赖2.1、属性间的联系实体间的联系有两类:一类是实体与实体之间的联系;另一类是实体内部各属性间的联系...
  • 关系型数据库规范化的通俗理解

    千次阅读 多人点赞 2019-05-26 11:17:35
    本文试图从工程化的角度,用大白话去解释数据库规范化的结论,如果有严谨之处,敬请指正。我不会去详细介绍每个范式的严格定义,重复别人的结论没有意义;也不会去解释为什么是这个结论,因为我这种俗人已经没办法...
  • 4.1 数据依赖 4.1.1 关系模式中的数据依赖 概念回顾 关系模式的形式化定义 4.1.2 数据依赖对关系模式的影响 什么是数据依赖 关系模式的简化表示 数据依赖与关系模式 ...4.3.1 关系范式规范化的步骤
  • 规范化会使实现变得更加复杂 逆规范化通常会降低灵活性 逆规范化会加快检索的速度,但却会降低更新的速度。(对数据库需要经常更新,频繁检索的应用更合适!) 合并一对一联系 如果两个关系之间的联系是一对一,...
  • 数据库设计之规范化和反规范化

    千次阅读 2019-09-09 20:50:36
    文章目录一、规范化二、反规范化      数据库设计的规范化能够经常被提及,但是反规范化很少被涉猎。实际应用中反规范化应用的场景很多。本文主要介绍一下数据库的反规范化。 一、规范化 ...
  • 概念模型与关系模型和关系规范化

    万次阅读 多人点赞 2017-05-20 16:18:34
     一个低一级范式的关系模式,通过模式分解逐步消除数据依赖中合适的部分,使模式中的各关系模式达到某种程度的分离,转换为若干个高一级范式的关系模式的集合,这种过程就是关系规范化。  通过消除非主键列对...
  • 何为规范化、标准化、精细化管理

    千次阅读 2020-12-22 13:36:32
    一、规范化管理规范化管理就是从企业生产经营系统的整体出发,对各环节输入的各项生产要素、转换过程、产出等制订制度、规程、指标等标准(规范),并严格地实施这些规范,以使企业协调统一地运转。实行规范化管理在...
  • SQL 规范化

    千次阅读 2019-01-09 18:22:02
    规范化关系数据库的概念是同时出现的。两者都来源于E.F.Codd(IBM)在1969年发表的著作。Codd提出这样的概念:数据库是由一系列无序的表组成的,可以对这些表进行非过程操作来返回表。 规范化实际上只是大型数据库...
  • 数据库——关系数据库规范化习题

    千次阅读 多人点赞 2019-06-29 16:39:00
    对以下的关系模式, 分别写出:(1)码 ,主属性,非主属性?(2)函数依赖?(3)属于第几范式?为什么?(4)有什么问题?(5)如何分解?分解后能否达到几范式? 原问题是否解决?ps(函数依赖的方法: 1.先找出码,再写出码...
  • 关系数据库规范化理论之范式

    千次阅读 2017-11-09 22:27:30
    因为在写项目时与同伴关于数据库到底建多少张表,每张表应包含哪些属性产生分歧,所以又好好研究了一下关系型数据库在设计时应该遵守怎样的规则以提高数据库性能。 在阅读本篇文章前读者须掌握关系数据库结构基础及...
  • 根据候选码判断关系F中的函数关系是否满足第二范式,若满足则为关系模式的规范化最高为第一范式 然后判断是否存在非主属性传递依赖,如果存在则满足第二范式,如果存在则关系模式的规范化最高为第三范式. 通俗...
  • 第一范式(1NF):关系中的所有分量可再分,即数据库表中的字段都是单一属性的,可再分。 在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,满足第一范式(1NF)的数据库就不是关系型数据库...
  • 关系数据库规范化

    千次阅读 2016-09-17 22:55:14
    第一范式(1NF):在关系模式R中的每一个具体关系r中,如果每个属性值 都是可再分的最小数据单位,则称R是第一范式的关系。例:如职工号,姓名,电话号码组成一
  • 规范化理论:函数依赖

    千次阅读 2019-05-11 19:35:44
    函数依赖(FunctionalDependency,FD)是关系模式中属性之间的一种逻辑依赖关系。例如,在一个有关学生的关系模式SCD(属性SNo,SN,Age,Dept,MN,CNo,Score分别代表学生证号,学生姓名,年龄,所属院系...
  • 数据库规范化理论

    千次阅读 2018-05-11 16:59:31
    函数依赖的定义设关系模式R(U,F),U是属性全集,F是U上的函数依赖集,X和Y是U的子集,如果对于R(U)的任意一个可能的关系r,对于X的每一个具体值,Y都有唯一的具体值与之对应,则称X函数决定Y,或Y函数依赖于X,记做.....

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 470,448
精华内容 188,179
关键字:

将不规范的关系规范化

友情链接: mario.zip