SQL中的数据冗余的最佳解决方法是什么?

发布网友 发布时间：2022-04-28 11:53

我来回答

共4个回答

热心网友 时间：2022-04-08 03:13

数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中， 因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 从一范式转化到二范式根据第二范式的定义，转化为二范式就是消除部分依赖。考察表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 NumberEmployee NameSalary CategorySalary Package200001JohnsonA2000200002ChristineB3000200003KevinC4000200004AppleB3000

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范式和四范式，但是这两种形式在商业应用中很少用到，在绝大多数情况下，三范式已经满足了数据库表规范化的要求，有效地解决了数据冗余和维护操作的异常问题。

热心网友 时间：2022-04-08 04:31

严格按照数据库设计几大范式做就行了，但为了性能，一定的数据冗余是可以容忍的

热心网友 时间：2022-04-08 06:06

分类存储

热心网友 时间：2022-04-08 07:57

1：当数据表插入数据后，不需维护（例如：更新）或者需维护的概率较少时，允许适当的冗余来提高查询效率2：若要保存历史记录（例如：某个项目审批前由A科室负责，审批后由B负责，为了查询项目是哪个科室负责的，就需要把科室编号或者名称作为冗余数据）3：为避免多表的连接而导致降低查询效率和提高逻辑复杂性的问题，允许适当的数据冗余（请按实际情况考虑）
冗余字段的使用在多表联合查询都是大数据量的表的情况下，确实是个不错的选择，有效的减少了IO操作。但结合已有的项目产品来看，冗余字段确实是双刃剑。尤其是大项目的开发，如果忽略某个表的冗余字段的更新，那么后果是灾难性的。如何有效的管理冗余字段是开发组内必须解决的问题。我的解决方案是：使用专门的表来管理冗余字段。例如article表有以下冗余字段 fromUserName，toUserName 如何管理这两个字段呢？通过建立一个表，表结构如下 id，objTable，objName，sourceTable， sourceId，level，isUpdate 其中objTable=目标表，objName= 目标字段，sourceTable=源表，sourceId=源表ID，level=是否需要立即更新，isUpdate=是否已更新 其中，level字段很有必要，有些冗余字段并不需要在源表修改后立即更新，那么可以通过一个定期更新策略来更新。 通过库表的管理，配合一个合理的存储过程，冗余字段的使用将不再是难题。考试通 举例，如果上面两个字段发生变化，则使用触发器或者调用这个存储过程来检查是否有需要立即更新的冗余字段，需要则立即更新，不需要则isUpdate置0，等到周期性的策略来更新同时isUpdate=1。注：很多时候，数据冗余是资源浪费、数据不一致的根源，同时数据冗余付出代价是很高的（特别是更新数据的时候）