数据库记录规格有哪些，招标书中数据库的规格怎么写

1，招标书中数据库的规格怎么写

平均查询响应时间数据条目上限（10万/百万/千万/亿万）级别一个数据库内的组件数目：模快数一个组件名称的字节数一个密码的字节数共用的使用者数目数据表一个栏位名称的字节数一个数据表的栏位数目可开户的数据表数数据表大小一个备注栏位的字节数一个OLE组件栏位的大小一个数据表的索引数目一个索引的栏位数目一笔记录的字节数查询强迫关联的数目一个查询的数据表数目一个记录集的栏位数目记录集的大小巢状查询的层次数目查询设计格线内一个储存格的字节数参数查询内一个参数的字节数在WHERE或HAVING子句内的AND数目一个SQL陈述式的字节数●窗体及报表一个标签的字节数一个文字框的字节数窗体或报表的字节数带区的宽度所有带区的高度巢状窗体或报表的层次数目：报表内排序或分组的字段数：报表内表头及表尾的数目：报表中可列印的页数：窗体或报表内，控制项或带区的数目：宏宏的宏指令数目一个条件的字节数一个注解的字节数

任务占坑

招标书中数据库的规格怎么写

2，Access数据库最多能存多少条记录

经过测试：如果到百万条记录的时候,就不能在数据库里设置字段类型为(备注)类型了.但是,还是可以多加些记录,所以,access数据库的容量应该是按照存储容量来说的,而不是记录多少。

没有限制，但是如果数据库到几十兆的时候，运行速度很慢

还是用SQL server吧

access数据库对记录数没有限制，但对数据库容量限制在2g字节以内。由于access是桌面数据库，最好单个表中的记录数应限制在10万条以内，否则性能会大大降低，当然你可以通过创建索引、优化查询等途径进行性能改善，但这种改善属于“改良”手段，而非“革命”处理。如果你的表中的数据要求很大，可考虑使用sql server数据库。

Microsoft Access 帮助中有Microsoft Access 数据库规格属性最大值文件大小 2G 字节减去系统对象所需的空间。数据库中的对象个数 32,768 模块 1,000 对象名称中的字符数 64 密码的字符个数 14 用户名或组名的字符个数 20 并发用户的个数 255 表名的字符个数 64 字段名的字符个数 64 表中字段的个数 255 打开表的个数 2048；实际可打开的表的数目可能会少一些，因为 Microsoft Access 还要打开一些内部的表。表的大小 2G 字节减去系统对象所需的空间 “文本”字段的字符个数 255 “备注”字段的字符个数通过用户界面输入为 65,535；以编程方式输入时为 1G 字节的字符存储。 “OLE 对象”字段的大小 1G 字节表中的索引个数 32 索引中的字段个数 10 有效性消息的字符个数 255 有效性规则的字符个数 2,048 表或字段说明的字符个数 255 当字段的 UnicodeCompression 属性设置为“是”时的记录的字符个数（除“备注”字段和“OLE 对象”字段外） 4,000 字段属性设置的字符个数 255

Microsoft Access 数据库 (.mdb) 文件大小 2 G 字节。不过，由于数据库可以包括其他文件中的链接表，所以它的大小仅实际上只受可用存储空间大小的限制。数据库中的对象个数 32,768 模块（包括 HasModule 属性为 True 的窗体和报表） 1,000 对象名称的字符数 64 密码的字符个数 14 用户名或组名的字符个数 20 用户个数 255 Microsoft Access 项目常规规格

Access数据库最多能存多少条记录

3，数据库五大范式是什么

第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话和一个家里电话号码）规范成为1NF有三种方法：一是重复存储职工号和姓名。这样，关键字只能是电话号码。二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性三是职工号为关键字，但强制每条记录只能有一个电话号码。以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。由以上条件，关键字为组合关键字（SNO，CNO）在应用中使用以上关系模式有以下问题： a.数据冗余，假设同一门课由40个学生选修，学分就重复40次。 b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。 c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。 d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。例：如S1（SNO，SNAME，DNO，DNAME，LOCATION）各属性分别代表学号，姓名，所在系，系名称，系地址。关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。原因：关系中存在传递依赖造成的。即SNO -> DNO。而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。解决目地：每个关系模式中不能留有传递依赖。解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件 a.一个仓库有多个职工。 b.一个职工仅在一个仓库工作。 c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。 d.同一种型号的配件可以分放在几个仓库中。分析：由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） -> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）-> ENO。因为一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有（ENO，PNO）-> QNT。找一下候选关键字，因为（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此（WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而P->WNO，故（ENO，PNO）-> WNO 也是传递依赖。虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO 缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。 1NF直到BCNF的四种范式之间有如下关系： BCNF包含了3NF包含2NF包含1NF

前三大范式就不是说了第四范式：在一个多对多的关系中，独立的实体不能存放在同一个表格中第五范式：原来的表格必须可以通过由它分离出去的表格重新构建

什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。什么是三大范式：第一范式：当关系模式r的所有属性都不能在分解为更基本的数据单位时，称r是满足第一范式的，简记为1nf。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。第二范式：如果关系模式r满足第一范式，并且r得所有非主属性都完全依赖于r的每一个候选关键属性，称r满足第二范式，简记为2nf。第三范式：设r是一个满足第一范式条件的关系模式，x是r的任意属性集，如果x非传递依赖于r的任意一个候选关键字，称r满足第三范式，简记为3nf。

第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。 3.4.2 第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。3.4.3 第三范式（3NF）满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

数据库五大范式是什么

4，详细说明数据库规范的三个范式

第三范式的要求如下： 1，每一列只有一个值 2，每一行都能区分。 3，每一个表都不包含其他表已经包含的非主关键字信息。实质上，设计范式用很形象、很简洁的话语就能说清楚。这里将对范式进行通俗地说明，以一个简单论坛的数据库为例讲解怎么样将这些范式应用于实际工程. 范式说明第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。例如，符合第一范式：字段1 字段2 字段3 字段4 不符合第一范式：字段1 字段2 字段3 字段4 字段3.1 字段3.2 很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个表不满足第二范式，因为存在如下决定关系： (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定非关键字的情况。由于不符合2NF，这个选课关系表会存在如下问题： (1) 数据冗余：同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。 (2) 更新异常：若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。 (3) 插入异常：假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字, 课程名称和学分也无法记录入数据库。 (4) 删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。把选课关系表SelectCourse改为如下三个表： 1).学生：Student(学号, 姓名, 年龄)； 2).课程：Course(课程名称, 学分)； 3).选课关系：SelectCourse(学号, 课程名称, 成绩)。这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，

我不说！~！！~！~！~！~！~！~呵呵！~！~！~！~！~

http://hi.baidu.com/vhion/blog/item/e54b1f460d99220c6a63e569.html 你看下这个应用实例。任何一本数据库书籍都有解释第一范式（1NF;The First Normal Form）第一范式是最低的规范化要求，第一范式要求数据表不能存在重复的记录，即存在一个关键字。1NF的第二个要求是每个字段都不可再分，即已经分到最小，关系数据库的定义就决定了数据库满足这一条。主关键字达到下面几个条件： 1．主关键字段在表中是唯一的 2．主关键字段中没有复本 3．主关键字段不能存在空值 4．每条记录都必须有一个主关键字 5．主关键字是关键字的最小子集满足1NF的关系模式有许多不必要的重复值，并且增加了修改其数据时疏漏的可能性。为了避免这种数据冗余和更新数据的遗漏，就引出了第二范式（2NF）。第二范式（The Second Normal Form）定义：如果一个关系属于1NF，且所有的非主关键字段都完全地依赖于主关键字，则称之为第二范式，简记为2NF。为了说明问题现举一个例子来说明：有一个库房存储的库有四个字段（零件号码，仓库号码，零件数量，仓库地址），这个库符合1NF，其中“零件号码”和“仓库号码”构成主关键字。但是因为“仓库地址”只完全依赖与“仓库号码”，即只依赖于主关键字的一部分，所以它不符合2NF，这样首先存在数据冗余，因为仓库数量可能不多。其次，存在如果更改仓库地址时，如果漏改了某一记录，存在数据不一致性。再次，如果某个仓库的零件出完了，那么这个仓库地址就丢失了，即这种关系不允许存在某个仓库中不放零件的情况。我们可以用投影分解的方法消除部分依赖的情况，而使关系达到2NF的标准。方法是从关系中分解出新的二维表，是每个二维表中所有的非关键字都完全依赖于各自的主关键字。我们可以如下分解：分解成两个表（零件号码，仓库号码，零件数量）和（仓库号码，仓库地址）。这样就完全符合2NF了。第三范式（The Third Normal Form）定义：如果一个关系属于2NF，且每个非关键字不传递依赖于主关键字，这种关系是3NF。从2NF中消除传递依赖，就是3NF。比如有一个表（姓名，工资等级，工资额），其中姓名是关键字，此关系符合2NF，但是因为工资等级决定工资额，这就叫传递依赖，它不符合3NF，我们同样可以使用投影分解的办法分解成两个表：（姓名，工资等级），（工资等级，工资额）。一般情况，规范化到3NF就满足需要了

第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。第三范式（3NF）满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2 的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

5，数据库三大范式

作用嘛，主要是规范数据库设计，且视你自己实现的功能而定。满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。关系数据库的几种设计范式介绍 1 第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。 2 第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。 3 第三范式（3NF）满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

第一范式（1NF）：字段不能划分成更多字段；不符合第一范式的例子：表：字段1 字段2 字段3 字段4 字段3.1 字段3.2现有的DBMS中设计出不符合第一范式的数据库都是不可能的。第二范式（2NF）：单关键字的表，或者若为组合关键字则必须没有候选关键字段→非关键字段的表；不符合第二范式的例子：表：学号, 姓名, 年龄, 课程名称, 成绩, 学分 (课程名称) → (学分) (学号) → (姓名, 年龄) 存在问题：数据冗余，每条记录都含有相同信息；删除异常：删除所有学生成绩，就把课程信息全删除了；插入异常：学生未选课，无法记录进数据库；更新异常：调整课程学分，所有行都调整。修正：学生：Student(学号, 姓名, 年龄)；课程：Course(课程名称, 学分)；选课关系：SelectCourse(学号, 课程名称, 成绩)。第三范式（3NF）：在第二范式的基础上，数据表中如果不存在传递函数依赖：关键字段 → 非关键字段x → 非关键字段y 不符合第三范式的例子：学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话，关键字为单一关键字"学号" 这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系： (学号) → (所在学院) → (学院地点, 学院电话)修正：学生：(学号, 姓名, 年龄, 所在学院)；学院：(学院, 地点, 电话)。

数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。设计范式是不是很难懂呢？非也，大学教材上给我们一堆数学公式我们当然看不懂，也记不住。所以我们很多人就根本不按照范式来设计数据库。实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。范式说明第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。例如，如下的数据库表是符合第一范式的：字段1 字段2 字段3 字段4 而这样的数据库表是不符合第一范式的：字段1 字段2 字段3 字段4 字段3.1字段3.2 很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式，因为存在如下决定关系： (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定非关键字的情况。由于不符合2NF，这个选课关系表会存在如下问题： (1) 数据冗余：同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。 (2) 更新异常：若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。 (3) 插入异常：假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。 (4) 删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。把选课关系表SelectCourse改为如下三个表：学生：Student(学号, 姓名, 年龄)；课程：Course(课程名称, 学分)；选课关系：SelectCourse(学号, 课程名称, 成绩)。这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：关键字段 → 非关键字段x → 非关键字段y 假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系： (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系： (学号) → (所在学院) → (学院地点, 学院电话) 即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。把学生关系表分为如下两个表：学生：(学号, 姓名, 年龄, 所在学院)；学院：(学院, 地点, 电话)。这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系： (仓库ID, 存储物品ID) →(管理员ID, 数量) (管理员ID, 存储物品ID) → (仓库ID, 数量) 所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系： (仓库ID) → (管理员ID) (管理员ID) → (仓库ID) 即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况： (1) 删除异常：当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。 (2) 插入异常：当仓库没有存储任何物品时，无法给仓库分配管理员。 (3) 更新异常：如果仓库换了管理员，则表中所有行的管理员ID都要修改。把仓库管理关系表分解为二个关系表：仓库管理：StorehouseManage(仓库ID, 管理员ID)；仓库：Storehouse(仓库ID, 存储物品ID, 数量)。这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。范式应用我们来逐步搞定一个论坛的数据库，有如下信息：（1）用户：用户名，email，主页，电话，联系地址（2）帖子：发帖标题，发帖内容，回复标题，回复内容第一次我们将数据库设计为仅仅存在表：用户名 email 主页电话联系地址发帖标题发帖内容回复标题回复内容这个数据库表符合第一范式，但是没有任何一组候选关键字能决定数据库表的整行，唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段，即将表修改为：用户名email主页电话联系地址发帖ID发帖标题发帖内容回复ID回复标题回复内容这样数据表中的关键字(用户名，发帖ID，回复ID)能决定整行： (用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容) 但是，这样的设计不符合第二范式，因为存在如下决定关系： (用户名) → (email,主页,电话,联系地址) (发帖ID) → (发帖标题,发帖内容) (回复ID) → (回复标题,回复内容) 即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗余和操作异常。我们将数据库表分解为（带下划线的为关键字）：（1）用户信息：用户名，email，主页，电话，联系地址（2）帖子信息：发帖ID，标题，内容（3）回复信息：回复ID，标题，内容（4）发贴：用户名，发帖ID （5）回复：发帖ID，回复ID 这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的呢？不一定。观察可知，第4项"发帖"中的"用户名"和"发帖ID"之间是1：N的关系，因此我们可以把"发帖"合并到第2项的"帖子信息"中；第5项"回复"中的"发帖ID"和"回复ID"之间也是1：N的关系，因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余，新的设计为：（1）用户信息：用户名，email，主页，电话，联系地址（2）帖子信息：用户名，发帖ID，标题，内容（3）回复信息：发帖ID，回复ID，标题，内容数据库表1显然满足所有范式的要求；数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖，即不满足第二范式的要求，但是这一设计并不会导致数据冗余和操作异常；数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖，也不满足第二范式的要求，但是与数据库表2相似，这一设计也不会导致数据冗余和操作异常。由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求，同时导致操作异常和数据冗余。对于1：1的关系，我们可以将左边的1或者右边的1合并到另一边去，设计导致不符合范式要求，但是并不会导致操作异常和数据冗余。

文章TAG：数据数据库记录规格数据库记录规格有哪些