数据库—设计规范(依赖、范式、分解)

这篇具有很好参考价值的文章主要介绍了数据库—设计规范(依赖、范式、分解)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

函数依赖

  • 如果在一个二维表中:Students(Sno , name, age),Sno 是这个表中的主键,所以对于其他属性来说,Sno决定name,Sno决定age,反过来则叫做name函数依赖于Sno…
    • 定义:主码决定其他属性,其他属性函数依赖于主码
  • 非平凡函数依赖
    SC(Sno,Cno,Grade)这么一个表中解释,首先主码是Sno和Cno联合主键,然后Grade必须要联合主键才能唯一标识,否则就是非平凡的。(一般研究的都是非平凡函数依赖)
  • 平凡函数依赖
    假如:SC(Sno,Cno,Grade,Cname)中讨论Cname的函数依赖,则Cname只需要Cno就能唯一标识,对于联合主键来说只是用了一部分,那么这个叫做部分函数依赖,同时这种依赖叫做平凡函数依赖。(因为这每一个联合主键表都会有,所以平凡)
    • 总结的说法就是:在对于联合主键这里就一定会出现的情况(平凡函数依赖),只有一个主键的不会有,所以只要出现了联合主键就必然有平凡函数依赖。但这里只是引出一个定义,后面只会研究非主属性,而不会对于主属性还研究是否依赖自己

认识了平凡和非平凡依赖后开始进入正题


  • 完全函数依赖
    SC(Sno,Cno,Grade,Cname)中,Grade就是完全函数依赖于联合主键,而不是依赖其中一个
  • 部分函数依赖
    对于非主属性部分依赖于主键的也就是出现了联合主键,非主属性仅仅依赖于某个而已的时候就叫做部分函数依赖。
  • 完全函数依赖有什么用? 部分依赖有什么问题?
    个人理解:举一个极端情况,假如说出现一个表有联合主键,有一个非主属性仅仅依赖于联合主键(主属性)中的一个的时候就出现了一个问题就是你的联合主键标识就显得冗余了,对于这个非主属性来说你的联合主键没啥用,只要一个就可以标识了,到时候查询的时候你的另一个也感觉是用不太到。
  • 主码与候选码
    主码只能设置一个(可一个属性也可联合属性),当出现非主属性函数依赖的时候就可以考虑是否是联合主码出问题了是否能将其多余的修改成一个主属性作为主码,还是说要单拎出来分解出来一个新表。
    • 另外在候选码中,他自己本身也能够唯一标识一个元组,但假如说没有选他做主属性的时候还能继续完善,就是最完美的要到达主属性除了自身外还要完全依赖于其他候选码,注意是候选码而不是其他主属性,而是其他所有的候选码,不管是否被选中为主属性(BC范式的要求)

范式

第一范式

关系数据库最基本的要求。

  • 满足每一个属性都是不可再分(小的斗胆认为自己不会写出这么沙壁的东西)
  • 存在的问题
    • 函数依赖
      因为你仅仅是满足了不可再分,很可能很多漏洞还存留着。

第二范式

  • 首先是满足第一范式
  • 然后第二范式必然是为了解决第一范式存在的问题,那就是解决部分函数依赖。
  • 满足非主属性完全函数依赖于主码(主属性)
  • 存在的问题
    • 存在传递依赖函数,即可能出现:一个主码决定a非主属性,然而a这个非主属性又决定b这个非主属性就叫做传递函数依赖。(primarykey->a->b)
    • 即:非主属性出现了传递函数依赖关系

到底怎么解决的

主要是通过分解来解决的,将原本第一范式的进行分解后到达了第二范式。

第三范式

  • 首先第三范式有点特殊,他是要满足第一范式的,书上没有说明要满足第二范式,但是我认为只要能细分到属于第三范式即可,无须说我满足了某某范式这一说。(因为我看到网上好多的答案都不同一,有的说二三范式其实隶属于一个范式只是二范式是特殊的三范式等等)
  • 三范式解决的必然是二范式中传递依赖的
  • 三范式必然要满足完全函数依赖
  • 三范式中的属性不可再分(无可厚非的必须要满足第一范式)
  • 即三范式:所有的非主属性定要完全函数依赖于主属性,且非主属性也不存在传递依赖关系

到底如何解决的

主要是通过分解来解决的,将原本第二范式的传递依赖进行分解后到达了第三范式。

  • 第三范式还存在着某些数据库的插入与删除异常(其实到这里一般的小项目就OK了)
  • 问题存在主要是第三范式只解决了非主属性的问题,主属性的问题还没解决。

BC范式(BCNF)

  • 首先要满足第一(第三范式基本的也要满足,但是书上也没说,和第三范式没写满足第二范式一样,网上答案也不统一说法)
  • 解决插入删除异常
  • 满足第一范式后,写出的所有的依赖关系,都必须是属于候选码(只要是候选码就行,没有说明是非得主码)
    • 这里比第三范式说的更明白了,就是一个关系中列出的所有函数依赖,左边的那个决定性的属性都必须是属于候选码(只要是候选码就行,没有说明是非得主码)
    • 这里我刚接触的时候愣了很久才搞明白,就是用我们学平凡依赖非平凡依赖的时候,列出所有的函数依赖,然后这里的BS范式分析的就是这些函数依赖左边的决定性属性(或联合属性)必定是我们在这个关系中的候选码(只要是候选码就行,没有说明是非得主码)

范式学习总结

  • 解决方式都是通过分解属性之间的联系
  • 我个人不太喜欢范式说法,为何要定义这么一说要满足几几范式,何必呢,无非是用来衡量数据库好坏的一个方式,其实我觉得只要设计出来的数据库合理,给程序用查询的速度高效,满足用户与程序员即可。

如何分解低范式->高范式

  • 分解后必须保持原有的函数依赖

    • 原因很简单,假如说是用户提的需求固然不能修改他给的函数依赖(人家说这个程序一定要鸡再有蛋或者先有蛋再有鸡那就不能把人家的需求改掉)
  • 分解后具有无损连接

    • 意思是你未分解前的数据元组,在你分解后(假如说分解了两个表),那么这些表进行自然连接后所得的数据必须和你的原有的(原本未分解前给的数据一模一样),这样才叫做无损连接(必须是一模一样,少了几条不行,多了也不行,别看名字叫无损连接,数据多了也是错)
  • 如何分解:这里就是具体问题具体分析了,一般来说正常思维都不会分解得离谱到哪里去,只要按照规范化去整,尽可能分解拆分到力所能及的最高范式即可

  • (因为有时候不是不能完美,而是这个东西他本身就不能太完美。)文章来源地址https://www.toymoban.com/news/detail-523118.html

到了这里,关于数据库—设计规范(依赖、范式、分解)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 数据库设计-范式

    范式就是数据库的构建规则,目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多要求的称为第二范式(2NF),

    2024年02月03日
    浏览(40)
  • 数据库期末复习(SQL,范式,数据库设计例题)

    创表 视图 例题:建立一个视图V1,显示老师与学生的授课关系,包括年份,学期,课程名称,老师ID,老师姓名,学生ID,学生姓名 向表中添加或删除约束 添加信息 例题:给“Aufr”同学选上2010年秋季学期的所有课程 删除信息 例题:删除“Comp. Sci.”学院“Ploski”同学,所有

    2024年02月02日
    浏览(65)
  • 数据库三大范式的学习与数据库表设计的了解

    内容简单介绍 对于数据库三大范式的理解以及一些设计表示要注意的方面 本章内容梳理图 数据库的三大范式(Normal Forms)是关系数据库设计中用于确保数据结构化、减少数据冗余、并提高数据完整性的指导和规则。 以下是三大范式的简述: 第一范式(1NF) 定义 :如果关系

    2024年03月27日
    浏览(64)
  • SQL笔记 -- 范式(第一范式、第二范式、第三范式、巴斯范式、反范式)及数据库设计原则

    1.1 范式简介 在关系型数据库中,关于数据表设计的基本原则、规则就称为范式。可以理解为,一张数据表的设计结构需要满足的某种设计标准的级别 。要想设计一个结构合理的关系型数据库,必须满足一定的范式。 目前关系型数据库有六种常见范式,按照范式级别,从低到

    2024年01月18日
    浏览(46)
  • 数据库的三大设计范式和BCNF

    第一范式(1NF):确保数据表中的每个列都是原子的,即每个列都包含不可再分的数据项。这意味着在每个列中不能有重复的数据,也不能包含多个值。每个数据项应该是独立的,以便能够对其进行有效的排序、搜索和过滤。 第二范式(2NF):在满足第一范式的基础上,要求

    2024年02月06日
    浏览(43)
  • 7种系统设计中的数据库范式

      在设计系统时,选择合适的数据库并明确原因是最重要的决策之一。市场上有许多不同的数据库可供选择,这使得做出正确选择变得困难且令人困惑。每个数据库都有其自己的故事和自己独特的视角。 因此,让我们深入了解可以将数据库分类为的7个广泛范畴: 这些是最流

    2024年02月08日
    浏览(41)
  • MySQL:事务、索引、用户管理、备份、数据库设计(三大范式)

    事务 (transaction):要么都成功,要么都失败。 核心 :将一组 SQL 放在一个批次中去执行。 原则 ACID :原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)。 原子性 :一个事务中的所有步骤 要么都 成功, 要么都 失败,不能只成功一个步骤。 一致性 :包括

    2023年04月26日
    浏览(81)
  • MySQL高级特性篇(6)-数据库设计模式与范式

    数据库是现代软件开发中非常重要的一环,而MySQL作为一种常用的关系型数据库管理系统,在数据库设计方面也有一些常见的模式和范式。本博客将介绍MySQL数据库设计模式与范式,让读者对MySQL数据库的设计有一个全面的了解。 一、数据库设计模式 数据库设计模式是数据库

    2024年02月22日
    浏览(46)
  • 数据库表设计(一):字段设计规范和命名规范

    1.1.是否需要自增ID? 数据库表,一定要有id,而且要用自增id! 有些人喜欢用自定义的,用UUID或者其他七七八八的id,如果在架构设计,代码比较好的情况下,不会出啥大问题,但是一旦代码写的不行,极有可能就造成id重复之类的问题。 自增id另外还有一个好处,就是在数

    2023年04月08日
    浏览(108)
  • MySQL笔记(一):设计范式、基础概念、数据库定义语言DDL

    MySQL是一种数据库管理系统 (DBMS),是基于客户机-服务器的数据库; 分为两个不同的部分, 服务器软件(MySQL DBMS)是负责所有数据访问和处理的一个文件,这个软件运行在称为数据库服务器的计算机上,与数据文件打交道; 客户机则是与用户打交道的软件,对于用户提出的

    2024年02月03日
    浏览(62)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包