什么是数据冗余(Redundancy),数据冗余的意思是什么.
什么是数据冗余(Redundancy),数据冗余的意思是什么
什么是数据冗余(Redundancy)
数据冗余的作用就是将额外的数据或数据信息保存在一个独立的硬盘上，来防止数据丢失。
数据冗余的意思是什么？
数据冗余是指数据之间的重复，也可以说是同一数据存储在不同数据文件中的现象。可以说增加数据的独立性和减少数据冗余是企业范围信息资源管理和大规模信息系统获得成功的前提条件。
冗余数据的管理所谓的数据冗余是指数据库的数据中有重复信息的存在,这自然浪费了很多的存储空间,尤其是存储海量数据的时候。
数据冗余是指同一数据被反复存放.这样着某一属性值发生改变其他与之相同的属性值也要改变.数据冗余不仅增加了更新代价更严重的是其潜在的数据不一致及存贮空间浪费等问题。
在数据库中存贮这类导出数据项需占用较多的存贮空间亦称为数据冗余.存贮冗余数据不仅代价高也是产生数据不一致的根源。
有关数据冗余说法错误的是()(选择一项)
1) 有关数据冗余说法错误的是（）。（选择一项） a) 数据库中，数据存在副本的现象，就是数据冗余 b) 通过分类存储，可以有效减少数据冗余，但是会增加数据查找的复杂性 c) 在数据库设计阶段，一定要尽最大可能避免数据冗余，最好做到无数据冗余。 d) 数据冗余通常是由于数据库设计引起的。 2) 假定有一个用户表，表中包含字段：userid (int)、username (varchar)、 password(varchar)、等，该表需要设置主键，以下说法正确的是（）。（选择两项） a) 如果不能有同时重复的username和password，那么username和password可以 组合在一起作为主键。 b) 此表设计主键时，根据选择主键的最小性原则，最好采用userid作为主键。 c) 此表设计主键时，根据选择主键的最小性原则，最好采用username和password 作为组合键。 d) 如果采用userid作为主键，那么在userid列输入的数值，允许为空。 3) 关于数据完整性，以下说法正确的是（）。（选择两项） a) 引用完整性通过主键和外键之间的引用关系实现。 b) 引用完整性通过限制数据类型、检查约束等实现。 c) 数据完整性是通过数据操纵者自身对数据的控制来实现的。 d) 如果两个表中存储的信息相互关联，那么只要修改了一个表，另外一个表也要 做出相应的修改，则称该这两个表中的数据具备完整性。 4) 关于标识列，以下说法正确的是（）。（选择一项） a) 使用sql语句插入数据时，可以为标识列指定要插入的值。 b) 设定标识时，必须同时指定标识种子和标识递增量。 c) 若设定标识时，未指定标识递增量，那么使用sql语句插入数据时，可以为标 识列指定递增值。 d) 只能把主键设定为标识列。 5) 现有表user，字段：userid，username, salary, deptid，email; 表department，字段： deptid, deptname;下面（）应采用检查约束来实现。（选择一项） a) 若department中不存在deptid为2的纪录，则不允许在user表中插入deptid 为2的数据行。 b) 若user表中已经存在userid为10的记录，则不允许在user表中再次插入userid 为10的数据行。 c) User表中的salary（薪水）值必须在1000元以上。 d) 若User表的email列允许为空，则向user表中插入数据时，可以不输入email 值。 6) 现有表book，主键bookid设为标识列。若执行语句：select * into book2 from book, 以 下说法正确的是（）。（选择两项）
数据库性能优化之冗余字段的作用
什么是冗余字段？ 在设计数据库时，某一字段属于一个表，但它又同时出现在另一个或多个表，且完全等同于它在其本来所属表的意义表示，那么这个字段就是一个冗余字段。 ——以上是我自己给出的定义 冗余字段的存在到底是好还是坏呢？这是一个不好说的问题。可能在有人看来，这是一个很蹩脚的数据库设计。因为在数据库设计领域，有一个被大家奉为圭臬的数据库设计范式，这个范式理论上要求数据库设计逻辑清晰、关系明确，比如，”用户昵称”字段”nickname”本来属于表”user”，那么，表示”用户昵称”的字段就唯一的只应该属于”user”表的”nickname”字段，这样，当用户要修改昵称的时候，程序就只需要修改user.nickname这个字段就行了，瞧，很方便。不过问题也随之而来，我在其他数据表(如订单orders表)里只存储了用户的ID，我要通过这个ID值得到用户昵称该怎么办呢？一个普遍的解决方法是通过联接(join)，在查询时，通过id这个唯一条件联接两个表，从而取到用户的昵称。 这样确实是没问题，我也一直觉得这样是最好的方案，扩展方便，当要更新用户信息时，程序中要修改的地方很少，但是随着数据库里数据不断增加，百万，千万，同时，用户表的数据肯定也在不断的增加的，它可能是十万，百万。这个时候，你会发现两个表通过联接来取数据就显得相当费力了，可能你只需要取一个nickname这个用户昵称属性，你就不得不去联一下那个已经几十万的用户表进行检索，其速度可想而知了。 这个时候，你可以尝试把nickname这个字段加到orders这个订单表中，这样做的好事是，当你要通过订单表呈现一个订单列表时，涉及用户的部分可能就不需要再进行联接查询了。当然，有利就有弊，这样做的弊端就是，当你尝试更新用户信息时，你必须记得用户信息表里当前被更新的字段中，有哪些是冗余字段，分别属于哪些表，找到他们，然后加入到你的更新程序段中来。这个是程序中的开销，开销在开发人员的时间上了。至于这样做是否值得，就得看具体情况而定了。 所以，目前要创建一个关系型数据库设计，我们有两种选择： 尽量遵循范式理论的规约，尽可能少的冗余字段，让数据库设计看起来精致、优雅、让人心醉。 合理的加入冗余字段这个润滑剂，减少join，让数据库执行性能更高更快。 选择哪一种呢？如果你是一个美学狂人，并且财大气粗，非要使用第一种方案，也没关系，这种方案的短板并非不可救药的。比如，你可以增加服务器，从数据库集群入手，进行读写分离，读的时候可以将压力分散到不同的数据库服务器上，这样也可以获得很好的性能，只是多付出了硬件成本和维护成本。或者，你可以在数据库前端架设Memcached之类的缓存服务，减少读写数据库的次数，也可以达到同样的效果。问题在于你确定你需要缓存之类的东西。 当然，如果你跟我一样，只有一台每月几十元买来的vps，甚至可能是一个虚拟主机，建议还是暂时压制你的美学欲望，跟我一起选择第二种方案吧，除非你愿意你的整个数据库都一直只有零零星星的几条数据 更多信息请查看IT技术专栏
数据库的基本特点之一是数据冗余小
1、数据库的基本特点之一是数据冗余小、易于扩充 2、数据库管理系统（DBMS）是一组软件 3、电子商务结构框架中，社会人文环境、自然科技环境和电子商务技术构成了电子商务应 用平台的三个支柱 4、电子商务活动中的信息通常是以多媒体的形式在Internet上传播的 5、数据库技术的产生与发展经历了人工管理阶段、文件系统阶段和数据库系统阶段 6、在数据库系统中，对数据库的存取全部由DBMS（数据库管理系统）统一管理，从而保 证了数据库和程序的逻辑独立性 7、数据库系统安全问题的核心是身份识别 8、数据操纵功能包括查询、插入、删除和修改 9、规范换的目的使结构合理，清除存储异常并使得数据冗余尽量减少，便于插入。删除和 更新 10、一个关系模型包括了一组关系模式，并且他们之间是相互关联的 11、从一般情况来看使用WEB数据库要解决数据库的归纳、索引和维护问题 12、ODBC驱动管理器是一个共享的程序管理器，称为ODBC.DLL 13、数据模型通常是由数据结构、数据操作和完整性约束三个要素组成 14、E-R图三要素包括实体、属性和联系 15、E-R图中实体用矩形表示，属性用椭圆形表示，联系用菱形表示 16、联系分为1:1、1：n和m:n三种 17、在关系中，能唯一标识组的属性集称为关系模式的主键 18、常用的数据库软件有Access,Oracle,Foxpro,SQL 19、SQL语言中删除一个表的命令是DROP 20、在SQL中使用FOREIGN KEY时，与之配合的语句是references 21、在SQL中建立视图使用create view命令 22、要保证数据库的独立性需要修改的是三层模式之间的两种映射 23、SQL语言具有的功能是数据定义、数据操纵和数据控制 24、记在数据库系统运行过程中所有更新操作的文件称为日志文件 25、在关系数据库中表与表之间的联系是通过参照完整性规则实现的 26、关系是满足一定条件的二维表，表中的一行称为关系的一个元组，表中的一列称为关系的一个属性 27、关系代数包括常规的集合运算：交、并、差、乘；还有专有的运算：选择、投影、连接、除 28、SQL的含义是结构化的查询语言 29、SQL语句对大小写不敏感 30、SQL语句的结束符为； 31、创建数据库使用create database语句，删除数据库使用drop database语句 32、对数据库进行插入操作使用的SQL语句为insert into 33、删除满足条件的元组使用的SQL命令为delete 34、对数据模型的规范化主要是解决插入异常、删除异常和数据冗余过大的问题 35、模式/内模式映象为数据库提供了物理数据独立性 36、能够消除部分函数依赖引起的冗余的范式是第二范式；能够消除传递函数依赖引起的冗余的范式是第三范式 37、第一代DBMS系统主要是指层次和网状 38、最常用的概念模型是E-R图
关系数据库的数据冗余
桂林工学院学报990313 桂林工学院学报 JOURNAL OF GUILIN INSTITUTE OF TECHNOLOGY 1999年 第19卷 第3期 Vol.19 No.3 1999 关系数据库的数据冗余 浦 路 平 摘 要 关系数据库的数据冗余形成的原因有表的重复、属性的重复、元组的重复、属性值的重复。有的数据冗余用于数据间建立联系、数据安全或为了数据使用的便利，是必需的数据冗余，而其余的数据冗余为非必需的数据冗余应尽量予以消除。按属性值域集合基的特点将其分为有限类和无限类。无限类属性值偶尔重复不是数据冗余，有限类属性值的重复由一对多或多对多的关系所致，可相机处理之。 关键词 关系数据库; 数据冗余; 必需的数据冗余, 有限类;无限类 DATA REDUNDANT IN RELATIONAL DATABASE Pu Luping Department of Electonics and Computer, Guilin Institute of Technology Abstract The data redundant in relational database is caused by the reduplication of the table, attribute, record, or attribute value. Data redundant should be removed as possible except necessary data redundant—the data redundant used to set relation between the data of databases, secure databases or be convenient for using data. Attribute values are classified into the limited class and the unlimited class according to their character of domain set base. The replicate of the limited class attribute value may result from the relation of one-to-one or one-to-many but the occasional replicate of the unlimited class attribute value is not data redundancy. Key words relational database; data redundant; necessary data redundant; limited class; unlimited class 关系数据库中的数据冗余主要是指关系数据库中同一信息数据的重复存贮。 数据冗余浪费了宝贵的资源，应尽量减少。但关系数据库中为实现一些功能有些数据冗余是必需的。必需的数据冗余主要用于以下用途： (1)数据间建立联系，如两表间通过共同属性建立联系［1］； (2)数据恢复，如建立备份文件以备正式文件被破坏时恢复； (3)数据核查，如设立数据校验位可以检查数据在存贮、传输等过程中的改变； (4)数据使用的便利，如为了查看数据的直观，使用数据的方便、高效。 (5)减少数据通讯开销，如分布式数据库在不同场地重复。 1 数据冗余的成因 file:///E|/qk/glgxy/glgx99/glgx9903/990313.htm（第 1／3 页）2010-3-22 20:08:17
数据库冗余设计
数据库性能优化之冗余字段的作用 作者：yoom时间：2011-03-01文档类型：原创来自：蓝色理想 什么是冗余字段？ 在设计数据库时，某一字段属于一个表，但它又同时出现在另一个或多个表，且完全等同于它在其本来所属表的意义表示，那么这个字段就是一个冗余字段。 ——以上是我自己给出的定义 冗余字段的存在到底是好还是坏呢？这是一个不好说的问题。可能在有人看来，这是一个很蹩脚的数据库设计。因为在数据库设计领域，有一个被大家奉为圭臬的数据库设计范式，这个范式理论上要求数据库设计逻辑清晰、关系明确，比如，”用户昵称”字段”nickname”本来属于表”user”，那么，表示”用户昵称”的字段就唯一的只应该属于”user”表的”nickname”字段，这样，当用户要修改昵称的时候，程序就只需要修改user.nickname这个字段就行了，瞧，很方便。不过问题也随之而来，我在其他数据表(如订单orders表)里只存储了用户的ID，我要通过这个ID值得到用户昵称该怎么办呢？一个普遍的解决方法是通过联接(join)，在查询时，通过id这个唯一条件联接两个表，从而取到用户的昵称。 这样确实是没问题，我也一直觉得这样是最好的方案，扩展方便，当要更新用户信息时，程序中要修改的地方很少，但是随着数据库里数据不断增加，百万，千万，同时，用户表的数据肯定也在不断的增加的，它可能是十万，百万。这个时候，你会发现两个表通过联接来取数据就显得相当费力了，可能你只需要取一个nickname这个用户昵称属性，你就不得不去联一下那个已经几十万的用户表进行检索，其速度可想而知了。 这个时候，你可以尝试把nickname这个字段加到orders这个订单表中，这样做的好事是，当你要通过订单表呈现一个订单列表时，涉及用户的部分可能就不需要再进行联接查询了。当然，有利就有弊，这样做的弊端就是，当你尝试更新用户信息时，你必须记得用户信息表里当前被更新的字段中，有哪些是冗余字段，分别属于哪些表，找到他们，然后加入到你的更新程序段中来。这个是程序中的开销，开销在开发人员的时间上了。至于这样做是否值得，就得看具体情况而定了。 所以，目前要创建一个关系型数据库设计，我们有两种选择： 1.尽量遵循范式理论的规约，尽可能少的冗余字段，让数据库设计看起来精致、 优雅、让人心醉。 2.合理的加入冗余字段这个润滑剂，减少join，让数据库执行性能更高更快。 选择哪一种呢？如果你是一个美学狂人，并且财大气粗，非要使用第一种方案，也没关系，这种方案的短板并非不可救药的。比如，你可以增加服务器，从数据库集群入手，进行读写分离，读的时候可以将压力分散到不同的数据库服务器上，这样也可以获得很好的性能，只是多付出了硬件成本和维护成本。或者，你可以在数据库前端架设