仿QQ聊天系统的数据库设计与实现

胡逸騉 仿QQ聊天系统的数据库设计与实现 第 ５页 共39页

消息消息记录编号消息接受状态消息类型名称QQ消息发消息时间11组成N消息类型好友记录1消息类型编号好友记录编号包括组成N收发消息者N两两好友QQ号QQ密码年龄昵称用户M真实姓名组成组成NN血型编号血型血型名称N好友策略头像好友策略编号好友策略名称组成MMM组成N星座星座名称性别星座编号头像编号头像图片 图3.1 QQ系统E-R图

3.3 E-R图向关系模型转换原则

(1) 一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模

式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是关系的候选码。如果与某一端实体对应的关系模式合并，则需要在改关系模式的属性中加入另一个关系模式的码和联系本身的属性。 (2)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

(3)一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

(4)3个或3个以上实体间的一个多元联系可以转换为一个关系模式。与该联系相连的

胡逸騉 仿QQ聊天系统的数据库设计与实现 第 ６页 共39页

各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

(5)具有相同码的关系模式可合并[6]。

根据这5项实体间的联系将上述E-R图转换为关系模型 QQ消息（消息记录编号、消息、消息接受状态、发消息时间）

此为消息实体对应的关系模式，该关系模式已包含了联系“组成”所对应的关系模式。 消息类型（消息类型编号、消息类型名称）

此为消息类型实体对应的关系模式，该关系模式已包含了联系“组成”所对应的关系模式。 用户（QQ号、QQ密码、昵称、真实姓名、年龄、性别）

此为用户实体对应的关系模式，该关系模式已包含了联系“组成”所对应的关系模式。 星座（星座编号、星座名称）

此为星座实体对应的关系模式，该关系模式已包含了联系“组成”所对应的关系模式。 血型（血型编号、血型名称）

此为血型实体对应的关系模式，该关系模式已包含了联系“组成”所对应的关系模式。 好友策略（好友策略编号、好友策略名称）

此为好友策略实体对应的关系模式，该关系模式已包含了联系“组成”所对应的关系模式。

胡逸騉 仿QQ聊天系统的数据库设计与实现 第 ７页 共39页

4 数据库逻辑结构设计

4.1 数据库需求分析

针对自己所要设计的仿QQ聊天系统的需求，设计如下所示的数据项和数据结构： 用户表：QQ号码、QQ密码、加好友的方式编号、昵称、QQ头像编号、性别、年龄、 实姓名、星座编号、血型编号 星座表：星座编号、星座名称

信息类型表：信息类型编号、信息类型

聊天信息表：聊天信息表记录编号、发送信息者QQ号、收到信息者QQ号、发送信息、信息类型编号、信息状态、发送时间

好友策略表：加好友的方式编号、加好友的方式设置 好友表：表添加记录、发送者的QQ、好友的QQ 血型表：血型编号、血型 以上内容如图4.1所示：

用户登录信息填写正确操作用户命令登录失败注册主窗体查找操作好友列表显示所有QQ执行命令操作选中加为好友删好朋，修改头像聊天 图4.1 数据流图

根据本系统的业务逻辑关系，得出了此数据流图，每一个箭头都带表着数据的流向，

胡逸騉 仿QQ聊天系统的数据库设计与实现 第 ８页 共39页

而数据的流向直接反映给数据库，并将此信息保存在数据库,从而比较正确的设计出数据库。

4.2 数据库初步关系框架

User(用户表)( QQ号码、QQ密码、加好友的方式编号、昵称、QQ头像编号、性别、年龄、真实姓名、星座编号、血型编号) Star(星座表)（星座编号、星座名称）

MessageType(信息类型表)( 信息类型编号、信息类型)

Messages(聊天信息表)( 聊天信息表记录编号、发送信息者QQ号、收到信息者QQ号、发送信息、信息类型编号、信息状态、发送时间)

FriendshipPolicy(好友策略表)( 加好友的方式编号、加好友的方式设置) Friends(好友表)( 表添加记录、发送者的QQ、好友的QQ) BloodType(血型表)( 血型编号、血型)

4.3数据库关系模式优化

该系统的数据库设计是满足数据库设计的第三范式。在设计数据库的时候例如对本数据库中任意一个表，例如用户表；

在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例如QQ号码，用户昵称，用户真实姓名，年龄（一个人可能只有一个用户昵称，一个QQ号码，用户的编号，一个姓名，电话号码??） 如果一是重复存储用户的QQ号码和姓名。这样，关键字只能是用户的编号。 很显然这种方法是不可取的；

如果用户的QQ号码是关键字，电话号码分为单位电话和住宅电话两个属性。

所以说：用户表中的列是不可再分的（即列的原子性），则可以说明该表满足第一范式！ 如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。

还拿出上面所说的用户表，例如每个用户都自己的详细信息（即，例如qq的头像编号，血型，星座??）

那么我们可以简单的举几个例子就可以很简单的看出；

a. 数据冗余，假设同一种血型由50个学生都一样，那么血型就重复了50次。 b. 更新异常，若调整了某种血型，相应的元组血型值都要更新，有可能会出现血型的不同。