下载文档原格式
关系数据库范式
关系数据库范式是一种用于设计关系数据库的规则和标准，以确保数据的一致性、完
整性和有效性。
主要目的是减少数据冗余和数据维护的复杂性，从而提高数据库的性能和
可靠性。
在关系数据库中，范式共有6个阶段，分别为第一范式（1NF）、第二范式（2NF）、
第三范式（3NF）、巴斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
第一范式（1NF）：属性不可分
第一范式指任何一个关系模式的所有属性都是不可分的原子值，也就是属性的值都不
能再细分成更小的部分。
例如，一个表中的地址字段，可以将其拆分为街道、城市、州和邮政编码等多个部分，但是在1NF中，这些部分都必须被当做单独的属性来存储。
第二范式（2NF）：满足1NF的基础上，消除部分依赖
第二范式指任何非主键属性都必须完全依赖于主键，也就是非主键属性不能只依赖于
主键的一部分。
例如，一个订单表中的商品名称、商品价格和商品数量，都必须依赖于唯一的订单编
号（主键），而不能只依赖于日期等其他属性。
如果存在部分依赖，需要对表进行拆分。
例如，一个客户和订单表中，一个客户可以下多个订单，但是每个订单只能对应一个
客户。
如果将客户的联系方式和收货地址存储在订单表中，就会出现多值依赖的问题。
因此，需要对表进行拆分。
第五范式（5NF）：尽量避免冗余
第五范式指关系模式中的数据不能通过拆分为更小的关系模式来避免冗余数据。
例如，一个图书馆书籍表中，如果将每个书籍作者的个人信息存储在作者表中，就会
出现多次重复的数据。
因此，需要将重复的数据存储在单独的表中，并通过关联方式进行
连接。
补充讲义一、范式举例BCNF.如：课程号与学号）例4：R(X,Y,Z),F={XY->Z},R为几范式？BCNF。
例5：R(X,Y,Z),F={Y->Z，XZ->Y},R为几范式？3NF。
R的候选码为{XZ,XY}，（R中所有属性都是主属性，无传递依赖）二、求闭包数据库设计人员在对实际应用问题调查中，得到的结论往往是零散的、不规范的（直观问题好办，复杂问题难办了），所以，这对分析数据模型，达到规范化设计要求，还有差距，为此，从规范数据依赖集合的角度入手，找到正确分析数据模型的方法，以确定关系模式的规范化程度。
例1．已知关系模式R(U、F)，其中，U={A,B,C,D,E}; F={AB→ C, B→ D, EC → B , AC→B} ,求（AB）+F.解：设X(0)=AB○1计算X(1),在F中找出左边为AB子集的FD,其结果是：AB→C,B→D∴X(1)=X(0)UB=ABUCD=ABCD 显然，X(1)≠X(0)○2计算X(2),在F中找出左边为ABCD子集的FD，其结果是：C→E,AC→B∴X(2)=X(1)UB=ABCDUBE=ABCDE 显然，X(2)=U所以，（AB）+ F=ABCDE.（等于U，所以AB是唯一候选关键字）例2．设有关系模式R(U、F)，其中U={A,B,C,D,E，I};F={A→D,AB→E,B→E,CD→I,E→C},计算（AE）+解：令X={AE},X(0)=AE○1在F中找出左边是AE子集的FD,其结果是：A→D,E→C∴X(1)=X(0)UB=X(0)UDC=ACDE 显然，X(1)≠X(0)○2在F中找出左边是ACDE子集的FD，其结果是：CD→I∴X(2)=X(1)UI=ACDEI显然，X(2)≠X(1)，但F中未用过的函数依赖的左边属性已含有X(2)的子集，所以不必再计算下去，即（AE）+=ACDEI.因为，X（3）＝X（2），所以，算法结束。
关系数据库范式关系数据库范式是指在关系数据库中，为了避免数据冗余和数据不一致性而设计的一种规范化方法。
范式分为一般范式和高级范式，一般范式包括第一范式、第二范式和第三范式，高级范式包括BC 范式和第四范式。
第一范式（1NF）第一范式是指关系模式中的所有属性都是原子性的，即不可再分解。
例如，一个学生的信息包括姓名、性别、年龄、地址等，这些属性都是原子性的，不可再分解。
如果将地址拆分成省、市、区、街道等多个属性，则不符合第一范式。
第二范式（2NF）第二范式是指关系模式中的非主属性必须完全依赖于主键，而不是依赖于主键的一部分。
例如，一个订单的信息包括订单号、商品编号、商品名称、商品单价、商品数量等，其中商品名称、商品单价、商品数量都依赖于商品编号，而不是订单号。
因此，应该将商品编号作为主键，将商品名称、商品单价、商品数量作为非主属性。
第三范式（3NF）第三范式是指关系模式中的非主属性不应该存在传递依赖关系。
传递依赖关系是指非主属性依赖于其他非主属性，而不是直接依赖于主键。
例如，一个学生的信息包括学号、姓名、班级、学院、学院地址等，其中学院地址依赖于学院，而不是直接依赖于学号。
因此，应该将学院作为一个独立的关系，与学生信息关系进行关联。
BC范式BC范式是指关系模式中的所有非主属性都必须依赖于候选键，而不是依赖于主键。
候选键是指可以唯一标识一个元组的属性集合。
例如，一个订单的信息包括订单号、商品编号、商品名称、商品单价、商品数量等，其中商品名称、商品单价、商品数量都依赖于商品编号，而商品编号不是主键，而是候选键。
因此，应该将商品编号作为主键，将商品名称、商品单价、商品数量作为非主属性。
第四范式（4NF）第四范式是指关系模式中的多值依赖关系必须被消除。
多值依赖关系是指一个关系模式中的某些属性可以有多个取值，而这些属性之间存在依赖关系。
例如，一个学生的信息包括学号、姓名、选修课程、成绩等，其中选修课程和成绩之间存在多值依赖关系，即一个学生可以选修多门课程，每门课程有一个成绩。
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。
反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
范式说明第一范式（1NF）无重复的列所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
简而言之，第一范式就是无重复的列。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
例如，如下的数据库表是符合第一范式的：字段1 字段2 字段3 字段4而这样的数据库表是不符合第一范式的：字段1 字段2 字段3 字段4字段字段数据库表中的字段都是单一属性的，不可再分。
这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。
因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
第二范式（2NF）属性完全依赖于主键[ 消除部分子函数依赖]如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则称为第二范式模式。
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
设计范式简介（范式,数据库设计范式,数据库的设计范式）是符合某一种级别的关系模式的集合。
构造数据库必须遵循一定的规则。
在关系数据库中，这种规则就是范式。
关系数据库中的关系必须满足一定的要求，即满足不同的范式。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。
满足最低要求的范式是第一范式（1NF）。
在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。
一般说来，数据库只需满足第三范式（3NF）就行了。
下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。
这样可能使数据库产生重复数据，从而导致创建多余的表。
范化是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。
下面是范化的一个例子Customer Item purchased Purchase price------------------------------------------------------------------------Thomas Shirt $40Maria Tennis shoes $35Evelyn Shirt $40Pajaro Trousers $25如果上面这个表用于保存物品的价格，而你想要删除其中的一个顾客，这时你就必须同时删除一个价格。
范化就是要解决这个问题，你可以将这个表化为两个表，一个用于存储每个顾客和他所买物品的信息，另一个用于存储每件产品和其价格的信息，这样对其中一个表做添加或删除操作就不会影响另一个表。
关系数据库的几种设计范式介绍第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
数据库三⼤范式通俗解释⼀、三⼤范式通俗解释：（1）简单归纳： 第⼀范式（1NF）：字段不可分； 第⼆范式（2NF）：有主键，⾮主键字段依赖主键； 第三范式（3NF）：⾮主键字段不能相互依赖。
（2）解释： 1NF：原⼦性。
字段不可再分,否则就不是关系数据库;； 2NF：唯⼀性。
⼀个表只说明⼀个事物； 3NF：每列都与主键有直接关系，不存在传递依赖。
⼆、例⼦说明 （1）不符合第⼀字段的例⼦表：字段1，字段2（字段2.1，字段2.2），字段3字段2可以拆分成字段2.1和字段2.2，不符合第⼀范式。
（2）不符合第⼆范式的例⼦表：学号，姓名，年龄，课程名称，成绩，学分这个表明显说明了两个事务：学⽣信息，课程信息。
1）存在以下问题：a、数据冗余：每条记录都含有相同信息；b、删除异常：删除所有学⽣成绩，就把课程信息全删除了；c、插⼊异常：学⽣未选课，⽆法记录进数据库；d、更新异常：调整课程学分，所有⾏都调整。
2）修正：学⽣表：学号，姓名，年龄课程表：课程名称，学分选课关系表：学号，课程名称，成绩 （3）不符合第⼆范式的例⼦表：学号，姓名，年龄，所在学院，学院联系电话其中关键字为单⼀关键字"学号"。
存在依赖传递:：(学号) → (所在学院) → (学院联系电话) 。
1）存在问题:： a、数据冗余：有重复值； b、更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不⼀致的情况 c、删除异常 2）修正：学⽣表：学号，姓名，年龄，所在学院；学院表：学院，电话⼀范式就是属性不可分割。
属性是什么？就是表中的字段。
不可分割的意思就按字⾯理解就是最⼩单位，不能再分成更⼩单位了。
这个字段只能是⼀个值，不能被拆分成多个字段，否则的话，它就是可分割的，就不符合⼀范式。
不过能不能分割并没有绝对的答案，看需求，也就是看你的设计⽬标⽽定。
举例：学⽣信息组成学⽣信息表，有姓名、年龄、性别、学号等信息组成。
构造数据库必须遵循一定的规则。
在关系数据库中，这种规则就是范式。
范式是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求，即满足不同的范式。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。
满足最低要求的范式是第一范式（1NF）。
在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。
一般说来，数据库只需满足第三范式（3 NF）就行了。
下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3 NF）。
3.4.1 第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。
简而言之，第一范式就是无重复的列。
3.4.2 第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。
如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。
这个唯一属性列被称为主关键字或主键、主码。
在创建一个数据库的过程中，必须依照一定的准则，这些准则被称为范式，从第一到第六共六个范式，一般数据库设计只要遵循第一范式，第二范式，和第三范式就足够了。
满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。
反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
阅读对象最好了解关系数据库的基本知识想从事软件开发的人员I、关系数据库设计范式介绍1.1 第一范式（1NF）无重复的列所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
简而言之，第一范式就是无重复的列。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
1.2 第二范式（2NF）属性完全依赖于主键第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。
这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
数据库设计三⼤范式为了建⽴冗余较⼩、结构合理的数据库，设计数据库时必须遵循⼀定的规则。
在关系型数据库中这种规则就称为范式。
范式是符合某⼀种设计要求的总结。
要想设计⼀个结构合理的关系型数据库，必须满⾜⼀定的范式。
⼀、基础概念要理解范式，⾸先必须对知道什么是关系数据库，如果你不知道，我可以简单的不能再简单的说⼀下：关系数据库就是⽤⼆维表来保存数据。
表和表之间可以……（省略10W字）。
然后你应该理解以下概念：实体：现实世界中客观存在并可以被区别的事物。
⽐如“⼀个学⽣”、“⼀本书”、“⼀门课”等等。
值得强调的是这⾥所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，不如说“⽼师与学校的关系”。
属性：教科书上解释为：“实体所具有的某⼀特性”，由此可见，属性⼀开始是个逻辑概念，⽐如说，“性别”是“⼈”的⼀个属性。
在关系数据库中，属性⼜是个物理概念，属性可以看作是“表的⼀列”。
元组：表中的⼀⾏就是⼀个元组。
分量：元组的某个属性值。
在⼀个关系数据库中，它是⼀个操作原⼦，即关系数据库在做任何操作的时候，属性是“不可分的”。
否则就不是关系数据库了。
码：表中可以唯⼀确定⼀个元组的某个属性（或者属性组），如果这样的码有不⽌⼀个，那么⼤家都叫候选码，我们从候选码中挑⼀个出来做⽼⼤，它就叫主码。
全码：如果⼀个码包含了所有的属性，这个码就是全码。
主属性：⼀个属性只要在任何⼀个候选码中出现过，这个属性就是主属性。
⾮主属性：与上⾯相反，没有在任何候选码中出现过，这个属性就是⾮主属性。
外码：⼀个属性（或属性组），它不是码，但是它别的表的码，它就是外码。
在实际开发中最为常见的设计范式有三个：1．第⼀范式(确保每列保持原⼦性)【属性不可分】第⼀范式是最基本的范式。
如果数据库表中的所有字段值都是不可分解的原⼦值，就说明该数据库表满⾜了第⼀范式。
第⼀范式的合理遵循需要根据系统的实际需求来定。
⽐如某些数据库系统中需要⽤到“地址”这个属性，本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。
10.范式2020年4月13日15:341.* 概念：设计数据库时，需要遵循的一些规范。
要遵循后边的范式要求，必须先遵循前边的所有范式要求设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
2.* 分类：1. 第一范式（1NF）：每一列都是不可分割的原子数据项2. 第二范式（2NF）：在1NF的基础上，非码属性必须完全依赖于码（在1NF基础上消除非主属性对主码的部分函数依赖）* 几个概念：1. 函数依赖：A-->B,如果通过A属性(属性组)的值，可以确定唯一B属性的值。
则称B依赖于A例如：学号-->姓名。
（学号，课程名称） --> 分数2. 完全函数依赖：A-->B， 如果A是一个属性组，则B属性值得确定需要依赖于A属性组中所有的属性值。
例如：（学号，课程名称） --> 分数3. 部分函数依赖：A-->B， 如果A是一个属性组，则B属性值得确定只需要依赖于A属性组中某一些值即可。
例如：（学号，课程名称） --> 姓名4. 传递函数依赖：A-->B, B -->C . 如果通过A属性(属性组)的值，可以确定唯一B属性的值，在通过B属性（属性组）的值可以确定唯一C属性的值，则称 C 传递函数依赖于A例如：学号-->系名，系名-->系主任5. 码：如果在一张表中，一个属性或属性组，被其他所有属性所完全依赖，则称这个属性(属性组)为该表的码例如：该表中码为：（学号，课程名称）* 主属性：码属性组中的所有属性* 非主属性：除过码属性组的属性3. 第三范式（3NF）：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）分区1.MySQL 的第1 页。
数据库范式举例
数据库范式是指关系型数据库中不同表之间的数据关系达到一
定标准的程度。
具体来说，就是通过对表进行规范化设计，使得每个表中的数据都符合一定的数据约束规则，以达到数据存储和查询的高效性和准确性。
下面举例说明数据库范式的具体应用：
第一范式（1NF）：表中的所有字段都是单一属性的，不可再分。
比如，一个学生信息表中，姓名和性别是两个不同的字段，而不是一个字段。
第二范式（2NF）：表中的所有字段都必须依赖于表的主键。
举个例子，一个订单表中，订单号是主键，而订单号、产品和数量是一个组合字段，在这种情况下，应该将产品和数量拆分成一个新的表，这样每个表的字段都只与主键相关。
第三范式（3NF）：表中的每个字段都必须直接依赖于主键，而不是依赖于其他非主键字段。
例如，在一个学生选课表中，课程名和教师名是两个独立的字段，而不是依赖于课程编号的字段。
以上就是数据库范式的三个级别，通过对表的规范化设计，使得数据之间的关系更加清晰，查询效率更高。
当然，在实际应用中，范式设计并不是绝对的，也需要根据具体的业务需求进行灵活的调整。
- 1 -。
3范式原则3范式原则是关系数据库设计中的基本原则，它主要用于规范数据库的结构和数据之间的关系，以提高数据库的一致性和效率。
本文将介绍3范式原则的概念、应用和优势。
1. 第一范式（1NF）第一范式要求数据库表中的每个字段都是原子性的，即不可再分解的最小数据单位。
每个字段只能包含一个值，不允许存在重复的数据项。
通过将数据分解为更小的数据项，可以避免数据冗余和不一致性的问题。
2. 第二范式（2NF）第二范式要求数据库表中的非主键字段完全依赖于主键，即每个字段与主键之间存在唯一的关联关系。
通过将数据分解为多个表，并建立关联关系，可以消除数据冗余，并确保数据的一致性和完整性。
3. 第三范式（3NF）第三范式要求数据库表中的非主键字段不依赖于其他非主键字段，即每个字段只与主键直接相关，而不与其他字段相关。
通过进一步分解表结构，可以提高数据的灵活性和可扩展性，减少数据冗余和数据更新的复杂性。
3范式原则的应用可以提供以下优势：1. 数据一致性：通过避免数据冗余和不一致性，可以确保数据库中的数据始终保持一致性。
2. 数据完整性：通过建立关联关系和约束条件，可以保证数据库中的数据完整性，防止无效或错误的数据插入。
3. 数据查询效率：通过合理的数据结构设计和查询优化，可以提高数据库的查询效率，加快数据检索和处理速度。
4. 数据更新简便：通过分解表结构和建立关联关系，可以减少数据更新的复杂性，简化数据的增加、删除和修改操作。
在实际数据库设计中，应根据具体业务需求和数据特点来确定是否采用3范式原则。
对于简单的数据结构和查询需求，可以适当放宽3范式的要求，以提高数据操作的效率。
但对于复杂的业务系统和大规模数据存储，遵循3范式原则是十分重要的，可以确保数据的一致性、完整性和可靠性。
总结起来，3范式原则是关系数据库设计中的基本原则，通过规范数据库的结构和数据之间的关系，可以提高数据库的一致性和效率。
在实际应用中，根据具体需求和数据特点来确定是否采用3范式原则，以确保数据的一致性、完整性和可靠性。
数据库三范式定义
数据库三范式是指在关系型数据库设计中，通过不断分解数据表，将其规范化为满足特定条件的三个级别的标准化形式。
这三个级别分别是第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
1. 第一范式（1NF）
第一范式要求数据表中的每个属性都是原子性的，即不可再分解。
也就是说，一个属性不能包含多个值或者是一个集合。
如果一个属性包含多个值，则需要将其拆分成多个独立的属性，并且每个属性都应该有自己的列名。
2. 第二范式（2NF）
第二范式要求数据表中不存在非主键列对主键列的部分依赖。
也就是说，一个表必须有一个主键，并且非主键列必须完全依赖于主键。
如果出现了部分依赖，则需要将其拆分成多个独立的表。
3. 第三范式（3NF）
第三范式要求数据表中不存在非主键列对其他非主键列的传递依赖。
也就是说，在一个表中，任何非主键列都不能依赖于其他非主键列。
如果出现了传递依赖，则需要将其拆分成多个独立的表。
总之，数据库三范式是一种规范化的设计方法，它可以帮助我们避免冗余数据和数据不一致性的问题。
在实际应用中，我们需要根据具体情况来选择合适的范式级别来设计数据库表结构。
