本文目录
- 什么是数据库中的规范化
- 数据库概念模型的关系模型
- mysql数据库同一个字段里的内容,怎么分开读取啊
- 数据库第二范式和第三范式的区别的是什么
- mysql 一个表里有多少字段是合适的呢
- 第一范式第二范式第三范式怎么区分
什么是数据库中的规范化
规范化理论把关系应满足的规范要求分为几级，满足最低要求的一级叫做第一范式(1NF)，在第一范式的基础上提出了第二范式(2NF)，在第二范式的基础上又提出了第三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。范式的等级越高，应满足的约束集条件也越严格。第一范式（1NF）在关系模式R中中，如果每个属性值都是不可再分的原子属性，则称R是第一范式的关系。例如：关系R（职工号，姓名，电话号码）中一个人可能有一个办公室电话和一个住宅电话号码，规范成为1NF的方法一般是将电话号码分为单位电话和住宅电话两个属性，即 R（职工号，姓名，办公电话，住宅电话）。1NF是关系模式的最低要求。第二范式（2NF）如果关系模式R是1NF且其中的所有非主属性都完全函数依赖于关键字，则称关系R 是属于第二范式的。例：选课关系 SC（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）。在应用中使用以上关系模式有以下问题： （1）数据冗余，假设同一门课由40个学生选修，学分就重复40次；（2）更新复杂，若调整了某课程的学分，相应元组的CREDIT值都要更新，有可能会出现同一门课学分不同；（3）插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入；（4）.删除异常，若学生已经结业，从当前数据库删除选修记录，而某些课程新生尚未选修，则此门课程及学分记录无法保存。以上问题产生的原因是非主属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。解决方法是将以上关系分解成两个关系模式 SC（SNO，CNO，GRADE）和C（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC中的外键CNO相联系，需要时再进行自然联接，恢复原来的关系第三范式（3NF）如果关系模式R是2NF且其中的所有非主属性都不传递依赖于码，则称关系R是属于第三范式的。例如关系模式S（SNO，SNAME，DNO，DNAME，LOCATION）中各属性分别代表学号、姓名、所在系、系名称、系地址。关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但关系S肯定有大量的冗余，有关学生所在系的几个属性DNO，DNAME，LOCATION将重复存储，插入、删除和修改时也将产生类似以上例的情况。原因在于关系中存在传递依赖，即SNO -》 DNO，DNO -》 LOCATION, 因此关键字SNO对LOCATION函数决定是通过传递依赖SNO -》 LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。解决方法是将该关系模式分解为两个关系S（SNO，SNAME，DNO）和D（DNO，DNAME，LOCATION），两个关系通过S中的外键DNO联系。BC范式(BCNF)如果关系模式R的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或者说关系模式R中，如果每个决定因素都包含关键字（而不是被关键字所包含），则R是BCNF。 通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。
数据库概念模型的关系模型
在关系模型中，数据的逻辑结构是一张二维表。在数据库中，满足下列条件的二维表称为关系模型：① 每一列中的分量是类型相同的数据；② 列的顺序可以是任意的；③ 行的顺序可以是任意的；④ 表中的分量是不可再分割的最小数据项，即表中不允许有子表；⑤ 表中的任意两行不能完全相同。关系数据库采用关系模型作为数据的组织方式。 关系数据库因其严格的数学理论、使用简单灵活、数据独立性强等特点，而被公认为最有前途的一种数据库管理系统。它的发展十分迅速，目前已成为占据主导地位的数据库管理系统。自20世纪80年代以来，作为商品推出的数据库管理系统几乎都是关系型的，例如，Oracle，Sybase，Informix，Visual FoxPro，mysql，sqlserver等。关系模型范式只有满足一定条件的关系模式，才能避免操作异常。关系模式要满足的条件称为规范化形式，简称范式。下面介绍四种不同程度的范式，由低级向高级：1、第一范式（1NF）在关系模式R的每一个具体关系r中，如果每个属性值都是不可能再分的最小数据单元，则称R是第一范式。记为R∈1NF。1NF是关系数据库能够保存数据并且正确访问数据的最基本条件。2、第二范式（2NF）如果关系模式R（U，F）中的所有非主属性都完全函数依赖于任意一个候选关键字，则称关系R是属于第二范式。记为R∈2NF。3、第三范式（3NF）如果关系模式R（U，F）中所有非主属性对任何侯选关键字都不存在传递依赖，则称关系R是属于第三范式。记为R∈3NF。4、BCNF如果关系模式R（U，F）R属于1NF，对任何非平凡依赖的函数依赖X→Y（Y!→X）X均包含码。记为R∈BCNF。如果R是BCNF则一定是3NF；反之则不行。一个低级范式的关系模式，可以通过分解方法转换成若干个高一级范式的关系模式的集合，也可以说任何一个高层的范式，总是能够满足低层的范式。
mysql数据库同一个字段里的内容,怎么分开读取啊
你可以分两次读取 第一次只读取第一二段 然后处理图片 第二次在读取第三四段 也就是做两次查询
数据库第二范式和第三范式的区别的是什么
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。
第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。考虑一个订单明细表OrderDetail其属性如下： （OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。因为我们知道在一个订单中可以订购多种产品，所以单单一个OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF的设计容易产生冗余数据。
可以把OrderDetail表拆分为：
OrderDetail（OrderID，ProductID，Discount，Quantity）
Product （ProductID，UnitPrice，ProductName）
来消除原订单表中UnitPrice，ProductName多次重复的情况。第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。考虑一个订单表Order： （OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。其中OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。
不过问题是CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。通过拆分Order为Order（OrderID，OrderDate，CustomerID）和Customer（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。
mysql 一个表里有多少字段是合适的呢
不管多少字段，都要满足三大范式就行了，三大范式：第一范式，又称1NF，它指的是在一个应用中的数据都可以组织成由行和列的表格形式，且表格的任意一个行列交叉点即单元格，都不可再划分为行和列的形式，实际上任意一张表格都满足1NF； 第二范式，又称2NF，它指的是在满足1NF的基础上，一张数据表中的任何非主键字段都全部依赖于主键字段，没有任何非主键字段只依赖于主键字段的一部分。即，可以由主键字段来唯一的确定一条记录。比如学号+课程号的联合主键，可以唯一的确定某个成绩是哪个学员的哪门课的成绩，缺少学号或者缺少课程号，都不能确定成绩的意义。 第三范式，又称3NF，它是指在满足2NF的基础上，数据表的任何非主键字段之间都不产生函数依赖，即非主键字段之间没有依赖关系，全部只依赖于主键字段。例如将学员姓名和所属班级名称放在同一张表中是不科学的，因为学员依赖于班级，可将学员信息和班级信息单独存放，以满足3NF。
第一范式第二范式第三范式怎么区分
满足第一范式 就是每个属性都不可在拆分，满足第二范式，非属性值要完全依赖主编码 非码属性不相互依赖，满足第三范式，不存在传递依赖。
