多学两招——使用E-R图设计数据库
多学两招——使用E-R图设计数据库根据需求分析结果,在数据库中应保存歌曲曲目信息、管理人员登录信息及顾客的点播信息。
数据库设计通常从概念设计开始,它通过对需求的分析了解需要在数据库中存储的数据对象,然后对这些需要存储的数据进行抽象,得出应当记录的属性信息,最终一般形成以实体关系图(E-R图)为描述手段的成果物。
歌曲曲目信息中应当保存足够的信息以便为顾客提供查询,而根据需求分析,需要为顾客查询提供的信息应包含歌曲名、歌曲名首字母组成的字符串、歌曲名字数长度、演唱歌手名、歌曲语种。而客户程序播放歌曲时则需要知道歌曲文件的存储位置,此外,在数据库中为了唯一标识每一首歌曲,需要为每首歌曲添加一个ID属性。
顾客点播信息中则记录了被点歌曲的信息及相应包房信息。为了便于顾客对已点信息进行查询及删除,顾客点播信息表中除了存储被点歌曲的ID外,还存储了歌曲名及歌手名。基于在播放顾客点播的歌曲时应按照点播顺序播放,所以点播信息中还应包含播放次序的序号,以及是否被播放过的标志。需要特别说明的是:从减少数据冗余的角度及数据库设计规范化的角度考虑,点播信息中包含的歌曲名、歌手名在歌曲曲目信息中都已经存在,因此在点播信息中不应还出现这两项信息。不过,点播信息在数据库中有临时表的性质,当包房顾客结账后其点播信息会被删除掉,因此这里在设计时为了和程序中操作的方便,选择了数据的冗余,而不是完全按照数据库设计范式进行设计。
管理人员登录信息主要是为了限制普通员工对点歌系统的数据管理功能,当管理人员成功登录后,后台管理界面将提供更多的管理功能给管理人员使用。因此管理人员登录信息中应包含登录名及登录密码两项内容,考虑到以后系统可能升级,管理人员亦可以有多层分级管理,管理人员信息中也加入了管理人员级别信息。
在数据库概念设计阶段,被广泛使用的概念模型是E-R模型,即实体联系模型。实体联系模型基本的概念包含实体、属性、联系。所谓实体是指客观存在的且又能相互区别的事物,而属性刻画了实体的特征,实体集之间的关联则称为联系。这些概念其实与数据库理论中的概念是一样的,并没有什么特殊之处。
E-R模型的直观图形表示法即E-R图,在E-R图中通常用矩形表示实体集,并需要在矩形内写上该实体集的名字;而椭圆形则用于属性,同样也需要在椭圆内写上属性的名称;实体之间的联系则用菱形表示,同样菱形中间也要写上联系的名字。另外,实体和依附于它的属性之间需要使用无向线段进行连接,而实体与实体之间要通过联系进行关联,在图形表现上,实体与联系之间也是使用无向线段进行连接的。
根据上述对需求的分析可知,需要保存的实体信息为歌曲曲目、点播信息、管理人员,它们各自包含一些相关的属性,而根据对E-R图的介绍可以绘制出如图7-19所示的实体联系图。
数据库概念设计完成之后,就可以在具体的数据库上进行逻辑设计了。而在进行具体设计之前应选择一个系统使用的数据库,基于点歌系统会应用于实际的生产环境之中,对数据库系统的可靠性及稳定性有一定的要求,所以点歌系统选用SQL Server 2000作为数据库服务器。选定数据库后,就可以根据概念设计的结果向逻辑设计进行转化了,其具体工作就是根据数据库的特征及其提供的数据类型将概念设计中各实体(有些时候也可以包含有联系)转化为数据库中的表,而将实体的属性转化为表中的字段,在表设计完成后,还要用表之间的关系体现实体之间的联系。其具体设计如下:
表7-1 歌曲曲目信息表songlist结构
表7-2 顾客点播信息表request结构
表7-3 管理人员信息表userinfo结构
数据库设计通常从概念设计开始,它通过对需求的分析了解需要在数据库中存储的数据对象,然后对这些需要存储的数据进行抽象,得出应当记录的属性信息,最终一般形成以实体关系图(E-R图)为描述手段的成果物。
歌曲曲目信息中应当保存足够的信息以便为顾客提供查询,而根据需求分析,需要为顾客查询提供的信息应包含歌曲名、歌曲名首字母组成的字符串、歌曲名字数长度、演唱歌手名、歌曲语种。而客户程序播放歌曲时则需要知道歌曲文件的存储位置,此外,在数据库中为了唯一标识每一首歌曲,需要为每首歌曲添加一个ID属性。
顾客点播信息中则记录了被点歌曲的信息及相应包房信息。为了便于顾客对已点信息进行查询及删除,顾客点播信息表中除了存储被点歌曲的ID外,还存储了歌曲名及歌手名。基于在播放顾客点播的歌曲时应按照点播顺序播放,所以点播信息中还应包含播放次序的序号,以及是否被播放过的标志。需要特别说明的是:从减少数据冗余的角度及数据库设计规范化的角度考虑,点播信息中包含的歌曲名、歌手名在歌曲曲目信息中都已经存在,因此在点播信息中不应还出现这两项信息。不过,点播信息在数据库中有临时表的性质,当包房顾客结账后其点播信息会被删除掉,因此这里在设计时为了和程序中操作的方便,选择了数据的冗余,而不是完全按照数据库设计范式进行设计。
管理人员登录信息主要是为了限制普通员工对点歌系统的数据管理功能,当管理人员成功登录后,后台管理界面将提供更多的管理功能给管理人员使用。因此管理人员登录信息中应包含登录名及登录密码两项内容,考虑到以后系统可能升级,管理人员亦可以有多层分级管理,管理人员信息中也加入了管理人员级别信息。
在数据库概念设计阶段,被广泛使用的概念模型是E-R模型,即实体联系模型。实体联系模型基本的概念包含实体、属性、联系。所谓实体是指客观存在的且又能相互区别的事物,而属性刻画了实体的特征,实体集之间的关联则称为联系。这些概念其实与数据库理论中的概念是一样的,并没有什么特殊之处。
E-R模型的直观图形表示法即E-R图,在E-R图中通常用矩形表示实体集,并需要在矩形内写上该实体集的名字;而椭圆形则用于属性,同样也需要在椭圆内写上属性的名称;实体之间的联系则用菱形表示,同样菱形中间也要写上联系的名字。另外,实体和依附于它的属性之间需要使用无向线段进行连接,而实体与实体之间要通过联系进行关联,在图形表现上,实体与联系之间也是使用无向线段进行连接的。
根据上述对需求的分析可知,需要保存的实体信息为歌曲曲目、点播信息、管理人员,它们各自包含一些相关的属性,而根据对E-R图的介绍可以绘制出如图7-19所示的实体联系图。
数据库概念设计完成之后,就可以在具体的数据库上进行逻辑设计了。而在进行具体设计之前应选择一个系统使用的数据库,基于点歌系统会应用于实际的生产环境之中,对数据库系统的可靠性及稳定性有一定的要求,所以点歌系统选用SQL Server 2000作为数据库服务器。选定数据库后,就可以根据概念设计的结果向逻辑设计进行转化了,其具体工作就是根据数据库的特征及其提供的数据类型将概念设计中各实体(有些时候也可以包含有联系)转化为数据库中的表,而将实体的属性转化为表中的字段,在表设计完成后,还要用表之间的关系体现实体之间的联系。其具体设计如下:
图7-19 实体联系图
歌曲曲目信息是本系统中的核心实体,它是系统提供服务的基础,其数据库表结构如表7-1所示。表7-1 歌曲曲目信息表songlist结构
字 段 |
含 义 |
类 型 |
长 度 |
默 认 值 |
NULL/主键 |
ID |
曲目ID号 |
bigint |
8 |
主键 | |
songname |
歌曲名 |
varchar |
50 |
||
namelen |
歌曲名长度 |
int |
4 |
||
speech |
歌曲语种 |
varchar |
50 |
||
fstalphabet |
首字母字符串 |
varchar |
50 |
||
singer |
演唱歌手名 |
varchar |
50 |
||
songpath |
曲目存储路径 |
varchar |
256 |
点歌曲目信息的存储是为顾客提供服务的前提,将点歌信息的概念设计转换为逻辑设计之后的结果如表7-2所示。
表7-2 顾客点播信息表request结构
字 段 |
含 义 |
类 型 |
长 度 |
默 认 值 |
NULL/主键 |
ID |
曲目ID号 |
bigint |
8 |
外键 | |
username |
包房标识(用户名) |
varchar |
50 |
||
songname |
歌曲名 |
varchar |
50 |
||
singer |
演唱歌手名 |
varchar |
50 |
||
playseq |
播放顺序 |
int |
4 |
||
played |
已播放标记 |
char |
2 |
‘0’ |
管理人员登录信息数据库表结构如表7-3所示。
表7-3 管理人员信息表userinfo结构
字 段 |
含 义 |
类 型 |
长 度 |
默 认 值 |
NULL/主键 |
username |
登录名 |
varchar |
20 |
||
password |
登录密码 |
varchar |
20 |
||
levels |
用户等级 |
char |
1 |
7.3.2 数据表关系设计管理人员与歌曲曲目及顾客点播信息之间并无直接联系,而顾客点播的歌曲必然会存在于歌曲曲目信息之中,因此数据库中表关系主要体现为歌曲曲目与点播信息之间的关系。歌曲曲目信息表的主键是ID,而点播信息表中的字段ID则为对应的外键,因此它们的联系是通过歌曲曲目的ID发生的。其实这一点在E-R图中已经有所体现了。