数据库的三个范式
数据库范式 通俗讲解

数据库范式通俗讲解
数据库范式是一种设计数据库表结构的方法,旨在消除数据冗余并提高数据存储的效率。
通俗来讲,数据库范式就是一种规范,它告诉我们如何把数据存储在数据库中,以便更好地组织和管理数据。
数据库范式通常分为不同的级别,即第一范式(1NF)、第二范式(2NF)、第三范式(3NF)等。
每个级别都有其特定的规则和要求,用于确保数据库表的结构合理且数据不会重复存储。
第一范式要求每个数据表中的每一列都是不可再分的原子值,不可再分的意思是不能再分解为更小的数据单元。
这样可以避免数据冗余和复杂的数据结构。
第二范式要求数据表中的非主键列完全依赖于主键,即非主键列必须完全依赖于主键,而不是部分依赖。
这样可以确保数据表中的数据结构更加清晰和简洁。
第三范式要求数据表中的每一列都与主键直接相关,而不是与其他非主键列相关。
这样可以进一步减少数据冗余,提高数据的一
致性和完整性。
总的来说,数据库范式的目标是通过合理的数据表设计,减少数据冗余,提高数据存储和检索的效率,确保数据的一致性和完整性。
然而,有时候过度范式化也可能导致查询性能下降,因此在实际应用中需要根据具体情况进行权衡和调整。
三大范式——精选推荐

三⼤范式数据库设计三⼤范式为了建⽴冗余较⼩、结构合理的数据库,设计数据库时必须遵循⼀定的规则。
在关系型数据库中这种规则就称为范式。
范式是符合某⼀种设计要求的总结。
要想设计⼀个结构合理的关系型数据库,必须满⾜⼀定的范式。
在实际开发中最为常见的设计范式有三个:1.第⼀范式(确保每列保持原⼦性)第⼀范式是最基本的范式。
如果数据库表中的所有字段值都是不可分解的原⼦值,就说明该数据库表满⾜了第⼀范式。
第⼀范式的合理遵循需要根据系统的实际需求来定。
⽐如某些数据库系统中需要⽤到“地址”这个属性,本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。
但是如果系统经常会访问“地址”属性中的“城市”部分,那么就⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储,这样在对地址中某⼀部分操作的时候将⾮常⽅便。
这样设计才算满⾜了数据库的第⼀范式,如下表所⽰。
上表所⽰的⽤户信息遵循了第⼀范式的要求,这样在对⽤户使⽤城市进⾏分类的时候就⾮常⽅便,也提⾼了数据库的性能。
2.第⼆范式(确保表中的每列都和主键相关)第⼆范式在第⼀范式的基础之上更进⼀层。
第⼆范式需要确保数据库表中的每⼀列都和主键相关,⽽不能只与主键的某⼀部分相关(主要针对联合主键⽽⾔)。
也就是说在⼀个数据库表中,⼀个表中只能保存⼀种数据,不可以把多种数据保存在同⼀张数据库表中。
⽐如要设计⼀个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所⽰。
订单信息表这样就产⽣⼀个问题:这个表中是以订单编号和商品编号作为联合主键。
这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,⽽仅仅是与商品编号相关。
所以在这⾥违反了第⼆范式的设计原则。
⽽如果把这个订单信息表进⾏拆分,把商品信息分离到另⼀个表中,把订单项⽬表也分离到另⼀个表中,就⾮常完美了。
如下所⽰。
这样设计,在很⼤程度上减⼩了数据库的冗余。
如果要获取订单的商品信息,使⽤商品编号到商品信息表中查询即可。
三范式

三范式关系型数据库是现在广泛应用的数据库类型,对关系型数据库的设计就是对数据进行组织化和结构化的过程。
对于小规模的数据库我们处理起来还是比较轻松地,但是随着数据库规模的扩大我们将发现用户操控数据库的SQL语句将变得笨拙、复杂。
更糟糕的是很有可能导致数据不完整,不准确。
所以我们有必要将数据设计的更加符合规范。
怎样使我们的数据库更加规范呢,前人总结了三个范式(其实一共有五个,但是一般的数据库只需满足三个就已经很高效了。
)主要内容:注意:斜体字部分为逻辑性语言,不容易理解,但很准确;粗体字部分为通俗语言,容易理解,但有失准确。
第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。
这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。
换句话说:能分就分,分到不能分为止!例1:原表1上表中“地点”字段中的值就不符合第一范式。
正确的做法应该是把大地点和小地点分开,保持每列的原子性,即不可分割性,如下表:修改后的表第二范式(2NF):在满足第一范式的基础上,数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。
(另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。
)也就是说:1、尽可能的使用单关键字吧!2、每个表只表述一个事,别傻乎乎的把所有信息都放到一个表里!例2:原表2上表满足第一范式,即每个字段具有不可再分性。
但是不满足第二范式。
从表可以看出组合关键字为(学号,课程名称),但表中“学分”完全依赖“课程名称”,而“姓名”和“年龄”完全依赖“学号”。
也就是说在这一张表里描述了两个事情:学生信息、课程信息。
这样的后果是(1) 数据冗余:同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。
数据库设计三大范式

数据库设计三⼤范式为了建⽴冗余较⼩、结构合理的数据库,设计数据库时必须遵循⼀定的规则。
在关系型数据库中这种规则就称为范式。
范式是符合某⼀种设计要求的总结。
要想设计⼀个结构合理的关系型数据库,必须满⾜⼀定的范式。
1NF:字段不可分;2NF:有主键,⾮主键字段依赖主键;3NF:⾮主键字段不能相互依赖;解释:1NF:原⼦性字段不可再分,否则就不是关系数据库;2NF:唯⼀性⼀个表只说明⼀个事物;3NF:每列都与主键有直接关系,不存在传递依赖;在实际开发中最为常见的设计范式有三个:1.第⼀范式(确保每列保持原⼦性)第⼀范式是最基本的范式。
如果数据库表中的所有字段值都是不可分解的原⼦值,就说明该数据库表满⾜了第⼀范式。
第⼀范式的合理遵循需要根据系统的实际需求来定。
⽐如某些数据库系统中需要⽤到“地址”这个属性,本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。
但是如果系统经常会访问“地址”属性中的“城市”部分,那么就⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储,这样在对地址中某⼀部分操作的时候将⾮常⽅便。
这样设计才算满⾜了数据库的第⼀范式,如下表所⽰。
上表所⽰的⽤户信息遵循了第⼀范式的要求,这样在对⽤户使⽤城市进⾏分类的时候就⾮常⽅便,也提⾼了数据库的性能。
2.第⼆范式(确保表中的每列都和主键相关)第⼆范式在第⼀范式的基础之上更进⼀层。
第⼆范式需要确保数据库表中的每⼀列都和主键相关,⽽不能只与主键的某⼀部分相关(主要针对联合主键⽽⾔)。
也就是说在⼀个数据库表中,⼀个表中只能保存⼀种数据,不可以把多种数据保存在同⼀张数据库表中。
⽐如要设计⼀个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所⽰。
订单信息表这样就产⽣⼀个问题:这个表中是以订单编号和商品编号作为联合主键。
这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,⽽仅仅是与商品编号相关。
简述数据库设计3个范式的含义

数据库设计是指按照特定的规范和要求,对数据库的数据存储和管理进行规划和设计的过程。
数据库设计的三个范式是指数据库设计中的基本规范,其中第一范式(1NF)、第二范式(2NF)和第三范式(3NF)分别规定了数据库中的数据应该满足的标准和要求。
下面我们将简要介绍数据库设计的三个范式的含义。
一、第一范式(1NF)1. 第一范式是指数据库表中的所有字段都是不可再分的最小单元,即每个数据项都是不可再分的,不能再被分割为更小的数据项。
2. 数据库表中的每一列都是单一的值,不可再分。
3. 所有的字段都应该是原子性的,即不能再分。
4. 如果数据库表中的字段不满足第一范式的要求,就需要进行适当的调整和修改,使之满足第一范式的要求。
二、第二范式(2NF)1. 第二范式是指数据库表中的所有非主属性都完全依赖于全部主键。
2. 所谓主属性是指唯一标识一个记录的属性,而非主属性是指与主键相关的其他属性。
3. 如果一个表中的某些字段与主键没有直接关系,而是依赖于其他字段,则需要将这些字段拆分到另一个表中。
4. 通过将非主属性与主键分离,可以避免数据冗余和更新异常。
5. 第二范式要求数据库表中的数据项应该是唯一的,不可再分,且完全依赖于全部主键。
三、第三范式(3NF)1. 第三范式是指数据库表中的所有字段都不依赖于其他非主字段。
2. 也就是说,一个表中的字段之间应该相互独立,不应该存在字段之间的传递依赖关系。
3. 如果一个字段依赖于其他非主字段,则应该将其拆分到另一张表中,以避免数据冗余和更新异常。
4. 第三范式要求数据库表中的字段之间应该是独立的,不应该存在传递依赖关系。
数据库设计的三个范式分别规范了数据库表中数据的原子性、依赖性和独立性。
遵循这些范式可以有效地减少数据冗余和更新异常,提高数据库的数据完整性和稳定性。
在进行数据库设计时,设计人员应该严格遵循这些范式的要求,以确保数据库的高效性和可靠性。
众所周知,数据库设计的三个范式是设计和维护关系型数据库时非常重要的标准和指导原则。
第一第二范式第三范式关系

第一第二范式第三范式关系关系数据库是现代应用开发中常用的数据存储和管理方式,而范式化是一种设计数据库的方法。
在关系数据库中,范式分为第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
本文将介绍三个范式的概念、原则和关系,以帮助读者更好地理解和运用范式化方法。
第一范式是关系数据库设计中的基本要求,它要求每个数据列都是原子的,不可再分。
具体来说,每个表的每个字段都只能有一个单一值,不能包含多个值或重复的分组。
这样可以确保数据的唯一性和一致性,方便数据的查询和管理。
例如,一个学生信息表应该将学生姓名、学号、性别等信息分开存储,而不是将它们合并在一个字段中。
第二范式在第一范式的基础上进一步规范了关系数据库的设计。
第二范式要求每个非主键字段都完全依赖于主键,即非主键字段必须和主键直接相关,而不能和其他非主键字段相关。
这种规范化可以避免数据的冗余和更新异常。
举个例子,一个订单表中,订单号是主键,订单日期和客户名称完全依赖于订单号,而不是互相依赖。
第三范式在第二范式的基础上进一步规范了数据库的设计。
第三范式要求所有非主键字段都不传递依赖于主键,即非主键字段之间不能相互依赖。
这样可以消除数据冗余和处理更新异常的可能性。
例如,一个员工表中,员工编号是主键,部门号和部门名称之间存在函数依赖关系,因此应该将它们分开存储,而不是将部门名称作为员工表的字段。
范式化的好处是可以提高数据的一致性、完整性和可维护性,减少数据冗余和更新异常的可能性。
但过度范式化也可能导致查询性能下降,因此在实际应用中需要权衡范式化和性能的关系。
一般来说,高频查询的字段可以冗余存储,以提高查询性能,但需要注意保持数据的一致性。
在数据库设计过程中,应该根据实际需求选择合适的范式化级别。
如果数据结构相对简单,可以选择较高的范式化级别;如果数据结构复杂,可以适当冗余存储以提高查询性能。
同时,还可以使用索引、优化查询语句等方法来提高数据库的性能。
第一、二、三范式

设计范式简介(范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合。
构造数据库必须遵循一定的规则。
在关系数据库中,这种规则就是范式。
关系数据库中的关系必须满足一定的要求,即满足不同的范式。
目前关系数据库有六种范式:第一范式(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)的数据库就不是关系数据库。
数据库三范式理解

数据库三范式理解
一、数据库三范式
数据库三范式是指数据库设计和维护时应遵循的三条准则,它是从实体、属性、范式三个角度构成的。
数据库三范式(即1NF、2NF 和3NF)旨在确保数据库表中的数据可以得到完整的保护,并被正确和有效地访问。
1.第一范式(1NF)
第一范式要求一个数据库表中的每一列都必须存储一个不可再分的数据值。
第一范式的目的是确保每一行都可以被惟一地识别,从而避免出现任何重复的数据项。
2.第二范式(2NF)
第二范式要求满足第一范式的表,每个非主属性都必须有完全的相关性,且主属性必须能够唯一确定。
这意味着非主属性要完全依赖主属性,这样删除主属性时,才能够保证非主属性不会被删除。
3.第三范式(3NF)
第三范式要求满足第二范式的表,其中每一个属性必须与主属性直接相关,或者通过已有的属性间接相关。
3NF规定了任何非主属性都必须直接依赖于主属性,而不是依赖其它非主属性。
- 1 -。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据库规范化三个范式应用实例5. 通俗地理解三个范式通俗地理解三个范式,对于数据库设计大有好处。
在数据库设计中,为了更好地应用三个范式,就必须通俗地理解三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解):第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解;第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性;第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余.没有冗余的数据库设计可以做到。
但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。
具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。
降低范式就是增加字段,允许冗余。
规范化为什么重要?目前很多的数据库由于种种原因还没有被规范化。
本文中解释了其中一些原因,并用不同形式的范式(normal form)规范化了一个保险公司的理赔表。
在这个过程中表的改变以及添加的一些附加表使数据库效率更高、错误更少、更容易维护。
数据库的规范化是优化表的结构和把数据组织到表中的实践,这样做数据才能更明确。
规范化使你能够改变业务规则、需求和数据而不需要重新构造整个系统。
通过改变存储数据的方式--仅仅改变一丁点--并改变访问这些信息的程序,你就可以消除很多错误或垃圾数据出现的机会并减轻更新信息所必要的工作量。
公司现实存在的一个问题可以用一句话概括"我们一般都这样做"。
我们一般像采用那种方式存储信息;我们一般允许人们把任何信息写入<insert field name>;我们一般采用那种方式编程。
这通常是一件坏事,特别是对于年轻的和正在学习的公司来说。
但是,当有新的系统和更好的完成任务的途径的时候,有时"采用那种方式任务完成得很好"这句话可能需要重新探讨和修改。
规范化数据就是公司常常采用的有益的方式之一。
尽管对于cobol程序(例如任何cobol程序员都熟悉的文件布局)使用数据来说,把它们(数据)存储在关系数据库中与存储在平面文件中很相似,但是存储在平面文件中的方法并不是完成任务的必要的最好的途径,特别是由于你不了解两者之间的差别或害怕改变,而简单地把过去的观念带入到现在的方式。
注意:是这样定义规范化的:"使其标准,特别使导致它符合某种标准或规范。
"或"某种标准的强制接受"。
webopedia认为规范化是"在关系数据库设计中,组织数据以最小化冗余的过程。
规范化通常包括把一个数据库分成两个或多个表并定义表之间的关系。
其目标是隔离数据,这样添加、删除和修改某个字段只需要在一个表中进行,接着可以通过定义的关系传递到数据库中剩余的表中"。
我更喜欢这个定义。
术语在你了解现实世界中的一个保险公司的例子之前,你需要了解一些在讨论中会用到的术语。
处理数据库的时候,特别是在处理规范化问题的时候,下面一部分讲到的一组新的关键字很有作用:·关系(relation):从本质上说,关系是一个包含行和列的二维表或数组。
·关联(relationship):关联是不同表之间的数据彼此联系的方法。
关联同时存在于形成不同实体的数据项之间和表实体本身之间,构成了数据库规范化的基本核心问题。
数据关联有三种基本的类型,对它们有所了解是很重要的:一对一(1:1):一对一关联意味着任何给定的每个(而不是大多数)实例严密地与另一个实体的一个实例对应。
每个人只有一个正确的指纹就是唯一的。
每个电话号码准确地与一个付帐的独立私人客户对应(不是公司)。
美国的每个人都只有一个社会保障号码。
一对多(1:m):一对多关联意味着给定实体的一个实例可以可以与另一个实体的零个实例、一个实例或者多个实例关联。
每个人可能没有小孩、有一个小孩或多个小孩。
每个人可能没有汽车、有一辆汽车或多辆汽车。
多对多(m:n):多对多关联(给定实体的零个、一个或多个实例与另一个实体的零个、一个或多个实例关联)是一种直接模拟很复杂的关联,它经常被分解为多个1:m关联。
由于多个家庭混合在一起,一个或多个小孩可能没有父母亲(孤儿)、一个父母(单亲家庭),多于一个父母(两个仍然在一起或者离婚的两个父母、或者离婚了又复婚了的父母)。
房屋或财产可以转让给一个人或多个人,而这些人(一个或多个)在遗嘱上可能又一个或多个房屋或财产。
·属性(attribute):属性被认为是程序或数据库中的某些组件的可以修改的特性或特征,它可以被设置为不同值或者关系或表中的列。
·tuple:tuple是关系数据库或非关系数据库中的排序了的一组值或值属性:关系中的一行。
·删除异常:删除异常指由于其它数据故意的删除而导致的数据矛盾或未预料到的数据(信息)丢失。
·插入异常:插入异常指由于数据的缺少或缺乏导致没有能力把信息添加到数据库。
·更新异常:更新异常指由于数据冗余或者冗余数据的不完整更新造成的数据矛盾。
·关系的分解:关系的分解指把一个关系分解成多个关系,从而使关系符合更高的范式。
·数据冗余:数据冗余指数据库中没有必要的数据重复。
·数据完整性:数据完整性指数据库中数据的一致性。
保证数据完整性很重要,只有这样用户才知道他们依赖的数据是正确的、他们查询的结果以及程序才是精确的和符合期望的。
·原子值:原子值是一个值,它既不是能被进一步拆分的一组值,也不是一个重复的组。
每个列都有一个完整的值,但是只有一个值--这个值不能被分解为多个部分,它要么被数据库使用,要么被使用数据库的用户访问的信息。
·参考完整性规则:参考完整性规则指存储在非空的外部健中的值必须是某种关系中的关键数据项。
·外部健:外部健是一个关系中的一组属性(一个或多个列),它同时也是某种(相同的或其它的)关系中的主键。
它是关系之间的逻辑链接。
参考自己关系的外部健称为递归外部健。
·功能依赖:功能依赖意味着一行中某个属性的值由该行中另一个属性的值决定。
这通常出现在主键(使某行唯一的信息片断)与该行的其它信息之间。
城市和州的组合依赖于zip(邮政)代码,即使给定的一个州中有很多zip代码与某个城市关联。
美国的每个合法的人员身份依赖于他的社会保障号码。
·决定性:功能依赖左边的属性决定行中其它属性的值(zip代码决定了城市和州;社会保障号码决定了人的身份;执照号码和州决定了汽车的拥有者)。
·实体完整性规则:实体完整性规则指某一行的关键属性可能为空(如果你在某个城市就有一个zip代码;如果你有一辆汽车就有一个执照号码)。
·约束:约束是一种规则,它限定了数据库中的值。
电话号码必须是数字的;美元数量必须是数字的;state必须是合法的州或省;country必须是合法的国家;日期不能是2月31号。
现在你已经知道了很多相关的术语了,我们可以看看相关术语中规范会的意义了。
下面的例子并不是典型的雇员―经理―部门示例,也不是学生―教授―课程提供示例。
我将演示一个假设的保险公司的数据库。
数据库中的表比本示例中用到的要复杂得多,但是与人们遇到的比较相近。
图1显示了理赔(claim)表的非规范化定义。
尽管在某个保险公司的数据库中的表比它多得多,但是这些表为我们提供了一些背景,通过它我们可以看到规范化和其分支。
请记住每个章节中的示例都只有部分列,这样就简化了示例并使你轻易地看到发生变化的东西。
claim_num、occurance_num 、claim_status、accdnt_yr、accdnt_dt、reported_dt、entered_dt、claim_dt1、claim_dt2、claim_dt3 、claim_dt4、claim_dt4 、claim_dt5 、claim_dt6 、claim_dt7、claim_dt8 、claim_dt9 、claim_dt10、closed_dt 、death_dt、assigned_dt、adjster_cd 、adjuster_name 、agent_cd 、award_cd 、cause_cd 、cause_desc、location 、site 、coverage_cd 、coverage_desc、ded_recov、deductible_remain 、paid_1 、reserved_1 、paid_2 、reserved_2 、paid_3 、reserved_3 、paid_4 、reserved_4 、paid_5 、reserved_5 、paid_6 、reserved_6 、paid_7 、reserved_7 、paid_8 、reserved_8、paid_9 、reserved_9 、paid_10 、reserved_10 、legal_flg、key1、key2、key3、key4、key5、key6、key7、key8、key9、key10、severity_cd 、policy_num 、payment_num 、ssn、state、actvy_dt、entry_dt、admin_cd、admin_desc、reopen_dt、insured_name、insured_address、insured_phone、insured_city、insured_state、insured_zip、claimant_name、claimant_address、claimant_city、claimant_state、claimant_zip、claimant_phone、special_dt_1 、special_dt_2、special_dt_3、special_dt_4 、special_dt_5、special_dt_6 、special_dt_7 、special_dt_8 、special_dt_9 、special_dt_10 、gross_pd、policy_id图1:未规范化的理赔表的列第一范式(1nf)把数据库或数据库的表转换为第一范式一般都相当简单。
第一范式要求消除数据中重复的组,这是通过建立相关数据的单独表来实现的。
它通过观察数据和表结构来确定表以完成第一范式。
第一范式是通过把重复的组放到每个独立的表中,把这些表通过一对多关联联系起来这种方式来消除重复组的。
没有重复的属性以及没有重复的一组值--这听起来足够简单了。
但是,有时候由于没有其它的选择,使人们相信只有简单地给设计添加任何其它集合却很困难,但是这也是你所做的事情。