如果在创建关系数据库基本表时,未创建完整性约束条件,对于数据库会有何影响?

如果在创建关系数据库基本表时,未创建完整性约束条件,对于数据库会有以下影响:

1:在以后使用数据库的增加时:有可能插入无效或重复的数据,使数据库的数据有重复或不健全.那数据便没有存在的价值.这是数据库建表之大忌也!

2:在以后使用数据库的删除和修改时:如有多张表,其约束又不健全,在执行其过程时,会使得多张表数据不全面,有时会多余的数据存在,例:你想删除一个人信息,但是这个人信息却在两张表中,如你只删除了他的名字而他的其它的信息依然存在,这样数据库的就有多余的数据.大忌也!

大概是这样的 因为你现在给的表是4个 关系图中的实体是5个 其关系大概只满足2NF 所以这个比较笼统 也不是一个比较标准的数据库 不符合3NF或BCNF 所以要确定数据关系比较困难追问：我从数据库里就只有这4个表 那个用户表是不需要建立的 因为不需要用户注册所以不需要存储的这4个表如果连接那是不是只有后台登录日志和网站后台有关系的 其他2个表是相对独立的回答：如果是没有管理员 没有用户的话 那么数据值涉及到后台日志 免费信息和收费信息 那么 只是这三个表有关系其他的都可以忽略了 按照所给的表 网站后台对应后台日志中的内容 收费供求信息和免费供求信息分别对应收费信息和免费信息 网站后台登录日志对应的则是管理员和用户的登录和数据 *** 控情况（可认为是审计） 那么 网站后台为主键表 那两个则为外键表 因为收费信息和免费信息是归用户使用的 可认为是外模式的表或视图 所以为外键表追问：管理员如果编号管理的话 要确定其数据库和管理员的关系则一定要重新创建表格来存储相关信息 如果不刻意要求管理员 只是管理 则没有创建表格的需要 至于外键表 刻意没有primary key也可以用多组来当primary key 如果要满足BCNF则定义多原组primary key 如果只要求3NF就可以不定义primary key 但数据维护时可能会有很大的工作量 对于primary key的定义与选取这是具体问题具体分析的 至少现在我不能帮你确定 至于用户表 应该是数据库用户定义里的内容 应该不用表格来创建 大概用SCHEMA 如果需要列出所有用户的信息 大概要创建一个表格来存储 一般是不用的追问：先谢谢了我是新手你说的东西我都没接触过，如果只有我那4个表 强行建立关系 是不是免费和收费之间是独立的 网站后台做主表主键设置为 ID号 外键为sysName 和 后台日志建立关系 网站后台和免费收费之间的关系是管理的关系 这3个表可不可以不连接？我自己连接了张图 您能帮我看下么回答：表的连接不是创立新的关系表格 而是在跨表查询时用的 连接的条件是有相同列 也就是主键和外键 对于现在的关系模式 任意两个表格都是可以连接查询的 因为都有ID列 对于连接查询要有控制条件 否则是两个表格的笛卡尔乘积 那是没有意义的追问：那么我的关系表的连接就是把4个都连接起来？那不是没有外键了对不起了 麻烦你了 我实在是个新手回答：那就是说 他们直接的关系是不需要连接的 是么 因为我要查询的数据都在这2个表了回答：大哥 你现在数据库学了多少 别太着急 连接在查询那里面 现在你问的主键外键在数据库建立里面 先立库再查询 然后是完整性约束条件与视图 触发器 外模式与应用程序 最后是角色与用户授权 最后是数据库的维护与管理 那不是简单几句话就能讲清楚的 我也没必要给你像讲课似的说这么一大堆 学的太少是没办法明白的 基础很重要追问：大哥我知道我数据库学的不好可是那不是没有办法么..我毕业答辩需要说这个关系图 我做不出来啊

多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。

按照数据库的增删查改 *** 作，多对多关系的查找都可以用inner join或者

select * from 主表 where id in (select 主表id from 关系表)

1，角色任命型

特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。

界面特点：显示主表，用checkbox或多选select设置多选关系。

例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。

增加关系：如果没有组合纪录，insert之。

删除关系：如果有组合纪录，删除之。

2，集合分组型

特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。

界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。

例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表）

增加关系：同版主任命型。

删除关系：同版主任命型。

3，明细帐型

特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。

界面特点：显示关系表，用radio或下拉设置单选关系。

例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。

增加关系：不管有没有组合纪录，insert之，纪录时间。

删除关系：根据关系表PK删除。

4，评论回复型

特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。

界面特点：回复文本框。

例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。

增加关系：不管有没有组合纪录，insert之，纪录时间和文字。

删除关系：根据关系表（回复表）PK删除。

5，站内短信型

特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息）或者其他标记位来表示文字已读状态时间等。

界面特点：回复文本框。

例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。

增加关系：不管有没有组合纪录，insert之，纪录时间和文字。

删除关系：根据关系表（回复表）PK删除。

6，用户好友型

特点：主副表是同一个，同集合分组型，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。

界面特点：同集合分组型，显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。

例如：下载站点的文件，（文件表-关系表-文件表）可以被软件工具打开，软件工具本身也是一种文件，可以被下载。用户的好友，也是用户（用户表-好友关系表-用户表）

增加关系：同版主任命型。

删除关系：同版主任命型

---