数据库中数据冗余会产生什么问题？？

数据冗余的缺点：

1、存储空间的浪费。

2、数据交互和数据库访问执行效率降低。

但适当的数据冗余又能加快查询。数据冗余究竟是好是坏还是要根据自己所做的项目进行合理的取舍。

当同一数据块存储在两个或多个单独的位置时, 就会发生数据冗余。假设创建了一个数据库来存储销售记录, 并在每个销售的记录中输入客户地址。但是，有多个销售到同一客户，因此同一地址被多次输入。重复输入的地址是冗余数据。

扩展资料

一定的冗余可以提升性能

1、空间换时间

有一张字典表 city 其中有 id 和 cityName 两个字段，有一张业务表，其中有 id 、cityId、XXX、XXX…字段。如果查询业务表的话，就必须 join 一下 city 字典表，如果业务表很大很大，那么就会查询的很慢，这个时候我们就可以使用冗余来解决这个问题。

直接将业务表中的 cityId 更换成 cityName，这样我们在查询业务表的时候就不需要去 join 那一张 city 的字典表了。这样的方式显然是不符合我们数据库设计的范式的，但是这样的冗余或许很有必要。

2、查询某一个状态值数据

业务表中有一个字段 status 用来存储提交和未提交，假设这张表中未提交的数据相对于提交的数据是很少的，当用户查询所有未提交的数据的时候，就需要在全部的数据，然后筛选出未同意的数据。如果这张业务表非常的庞大，那么这样的查询的效率就非常的慢。

这个时候我们就可以把这张业务表中的未同意的数据冗余到一张新表中，这样用户查询未提交的数据的时候就可以直接在这张未提交的表中查询，查询速度提交很多。

数据库中的冗余数据是指由基本数据导出。数据冗余发生在数据库系统中，指的是一个字段在多个表里重复出现。举个例子，如果每条客户购买商品的信息里都连带记录了客户自身的信息，这样的数据冗余可能造成不一致，因为客户自身的信息可能不一样。数据冗余会导致数据异常和损坏，一般来说设计上应该被避免。数据库规范化防止了冗余而且不浪费存储容量。适当的使用外键可以使得数据冗余和异常降到最低。但是，如果考虑效率和便利，有时候也会设计冗余数据，而不考虑数据被破坏的风险。

数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中， 因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 从一范式转化到二范式根据第二范式的定义，转化为二范式就是消除部分依赖。考察表1-1，我们可以发现，非主属性<Project Name>部分依赖于主键中的<Project Number>非主属性<Employee Name>，<Salary Category>和<Salary package>都部分依赖于主键中的<Employee Number>；表1-1的形式，存在着以下潜在问题：1． 数据冗余：每一个字段都有值重复；2． 更新异常：比如<Project Name>字段的值，比如对值"TPMS"了修改，那么就要一次更新该字段的多个值；3． 插入异常：如果新建了一个Project，名字为TPT, 但是还没有Employee加入，那么<Employee Number>将会空缺，而该字段是主键的一部分，因此将无法插入记录；Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100003, 'TPT', NULL, NULL, NULL, NULL)

4． 删除异常：如果一个员工 200003, Kevin 离职了，要将该员工的记录从表中删除，而此时相关的Salary信息 C 也将丢失, 因为再没有别的行纪录下 Salary C的信息。Delete from sample where EMYNUM = 200003

Select distinct SALCATEGORY, SALPACKAGE from SAMPLE因此，我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来，形成一张新的表，而新表和旧表之间是一对多的关系。由此，我们得到：

CREATE TABLE "PROJECT" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200)) IN "USERSPACE1"ALTER TABLE "PROJECT" ADD PRIMARY KEY ("PRJNUM")Insert into PROJECT(PRJNUM, PRJNAME) values(100001, 'TPMS'), (100002, 'TCT')

表1-2

表 1-3

CREATE TABLE "EMPLOYEE" ( "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER) IN "USERSPACE1"ALTER TABLE "EMPLOYEE" ADD PRIMARY KEY ("EMYNUM")Insert into EMPLOYEE(EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(200001,'Johnson', 'A', 2000), (200002, 'Christine', 'B', 3000), (200003, 'Kevin', 'C',4000), (200004, 'Apple', 'B', 3000)Employee Number Employee Name Salary Category Salary Package200001 Johnson A 2000200002 Christine B 3000200003 Kevin C 4000200004 Apple B 3000

CREATE TABLE "PRJ_EMY" ( "PRJNUM" INTEGER NOT NULL, "EMYNUM" INTEGER NOT NULL) IN "USERSPACE1"ALTER TABLE "PRJ_EMY" ADD PRIMARY KEY ("PRJNUM", "EMYNUM")Insert into PRJ_EMY(PRJNUM, EMYNUM) values(100001, 200001), (100001, 200002),(100001, 200003), (100002, 200001), (100002, 200004)

同时，我们把表1-1的主键，也就是表1-2和表1-3的各自的主键提取出来，单独形成一张表，来表明表1-2和表1-3之间的关联关系：

表 1-4

这时候我们仔细观察一下表1-2, 1-3, 1-4, 我们发现插入异常已经不存在了，当我们引入一个新的项目 TPT 的时候，我们只需要向表1-2 中插入一条数据就可以了， 当有新人加入项目 TPT 的时候，我们需要向表1-3, 1-4 中各插入一条数据就可以了。虽然我们解决了一个大问题，但是仔细观察我们还是发现有问题存在。

回页首

从二范式转化到三范式考察表前面生成的三张表，我们发现，表1-3存在传递依赖关系，即：关键字段<Employee Number >-->非关键字段<Salary Category >-->非关键字段<Salary Package >。而这是不满足三范式的规则的，存在以下的不足：1、 数据冗余：<Salary Category>和<Salary Package>的值有重复；2、 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况；3、 删除异常：同样的，如果员工 200003 Kevin 离开了公司，会直接导致 Salary C 的信息的丢失。Delete from EMPLOYEE where EMYNUM = 200003

Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE因此，我们需要继续进行规范化的过程，把表1-3拆开，我们得到：

表 1-5

和

表 1-6

这时候如果 200003 Kevin 离开公司，我们只需要从表 1-5 中删除他就可以了， 存在于表1-6中的Salary C信息并不会丢失。但是我们要注意到除了表 1-5 中存在 Kevin 的信息之外， 表1-4中也存在 Kevin 的信息， 这很容易理解， 因为 Kevin 参与了项目 100001， TPMS， 所以当然也要从中删除。 至此，我们将表1-1经过规范化步骤，得到四张表，满足了三范式的约束要求，数据冗余、更新异常、插入异常和删除异常。在三范式之上，还存在着更为严格约束的BC范式和四范式，但是这两种形式在商业应用中很少用到，在绝大多数情况下，三范式已经满足了数据库表规范化的要求，有效地解决了数据冗余和维护 *** 作的异常问题。

---