数据处理时的完整性保障
1 简介:设计数据
数据库设计是帮助创建、实施和维护企业数据管理系统的一系列步骤。
设计数据库的主要目的是为拟议的数据库系统生成设计的物理和逻辑模型,并在设计时保证数据完整性和消除冲突。
2 保证数据完整性
数据库完整性保证包括: 实体完整性,参照完整性,用户定义完整性。
实体完整性 Entity Integrity
实体完整性规则要求每个数据表都必须有主键,而作为主键的所有字段,其属性必须是唯一且非空值。
参照(引用)完整性 Referential Integrity
实体及实体间的联系是用关系来描述的,关系与关系间的引用。一般此表主键,在另一表有关联字段的外键可用于确保通过主键和外键将表链接在一起的值是有效且正确同步的。
用户定义完整性 User Defined Integrity
是针对某一具体的关系数据库的约束条件,反映某一具体应用所涉及的数据必须满足的语义要求,由应用的环境决定,例如 银行账户 必须大于 100000,小于 9999999,密码必须是六位等。
2.1 参照完整性关系。
因为数据库中的每个表都必须有一个主键,所以这个主键 键可以出现在其他表中,因为它与数据的关系 在这些表中。当一个表中的主键出现在 另一个表,称为外键。
定义主键和外键以及两者之间的关系 它们,使用 CREATE TABLE 和 ALTER TABLE 语句。
外键联接表并在表之间建立依赖关系。 表可以形成依赖关系的层次结构,如果 您更改或删除一个表中的行,则破坏了 其他表中的行。
参照完整性简单规则:
实例关系:多篇文章归属于某一类别(Class)
父子关系:一方为父多方为子
主外键关系:父方主键与子方外键关联
原理:父子关系是通过选定的键关联的,如果某一方的这个键变更了,而另一方不作更新,必然造成数据的完整性不正确。
2.2 参照完整性:博客文章例子
例1:有一个博客系统,文章分类存储,文章实体用Class外键与类别实体的主键ClassId关联(更确切是文章实体聚合了类别实体),当某类别ID被改或者删除了,如果文章实体不作相应的操作,那么文章就不知道是哪个类别的了。
反之,文章的类别被改,那么文章的类别就可能会出错,当然系统允许改文章类别另当别论了。
可用事件:看图,父方只有UPDATE和DELETE事件,而子方只有INSERT和UPDATE事件,是因为,父方插入新记录(新的类别)不影响子方(现存文章)的数据完整性。
反之,删除一篇文章不影响类别的数据完整性。这里要注意,事件的对象是关联双方的键
文章上级主键
None: 当上级的主键被更改时什么都不干;
Restrict(限制):这个报错,不允许更改,当下级有相应的记录关联时;如删除某一类别记录时,文章实体有该类别的文章。
Cascade(级联):使用最多。级联更改下级相关记录。
Set NULL:允许上级更改,下级外键设NULL,在某些场合有用。
Set default:和上类似。
文章下级外键
None:这个不用说了吧,什么都不干,当下级的外键被更改时;
Restrict(限制):这个报错,不允许更改。
2.3 参照完整性:银行账户例子
删除包含主键的行或对其进行更新时 使用不同的主键,可以破坏任何行的含义 包含该值作为外键。
参照完整性是 外键对主键的逻辑依赖关系。包含外键的行取决于 它引用的行 - 包含匹配的主行键。
客户表的customer_num列是主列 键以及订单和cust_call表中的外键。 客户编号 106,乔治, 在订单表和cust_calls表中引用。 如果从客户表中删除客户 106,则链接 在三个表之间,此特定客户被销毁。
从主数据库中删除行时保持参照完整性 键,使用引用中的“删除级联”选项 创建表和更改表语句的子句。
此选项 允许您从父表及其相应的 具有单个删除命令的匹配子表中的行。
有多个子项会发生什么?
如果父表具有两个子约束, 指定了级联删除的一个子项和另一个未指定级联的子项删除,并且尝试从父表中删除一行 适用于两个子表的DELETE 语句将失败,并且将不会有数据 从父表或子表中删除.
缺省情况下,数据库服务器不允许违反参照完整性,并在尝试删除时显示错误消息。
3 小结
一个好的数据库设计是:
将信息划分为基于主题的表,以减少冗余数据。
提供根据需要将表中的信息联接在一起所需的信息。
帮助支持并确保信息的准确性和完整性。
满足您的数据处理和报告需求
数据库设计:概念设计工具,E-R图工具,比如 UML工具
关系设计时可能需要解决的冲突:域冲突,字段冲突,命名冲突等
- 点赞
- 收藏
- 关注作者
评论(0)