会议管理系统数据库设计文档概要.docx

会议管理系统数据库设计文档概要.docx

《会议管理系统数据库设计文档概要.docx》由会员分享，可在线阅读，更多相关《会议管理系统数据库设计文档概要.docx（16页珍藏版）》请在冰豆网上搜索。

会议管理系统数据库设计文档概要

会议管理系统数据库计说明书

编写：

 非常6+2

日期：

2013-7-31

审核：

日期：

批准：

日期：

受控状态：

是

发布版次：

5.0

日期：

2013-7-31

编号：

变更记录

日期

版本

变更说明

作者

2013-7-17

1.0

初始文档

匿名

2013-7-25

2.0

升级文档

匿名

2013-7-29

3.0

升级文档

匿名

2013-7-30

4.0

升级文档

匿名

2013-7-31

5.0

最终文档

匿名

签字确认

职务

姓名

签字

日期

1

引言

1.1预期的读者

主要为本公司以及承包方的阅读者，如设计人员、开发人员等。

有时可以包括客户方的阅读者,如：

业务人员、系统管理人员等。

1.2数据库说明

会议管理系统采用的时当前流行的企业级数据库oracle，使用的版本是9i。

设计的数据库全局数据库名为icss，开发用的表空间名是test，操作的用户名为test，密码为test。

1.3目的和作用

将业务分析，系统设计中对信息的描述进一步分析并加以总计，抽象出数据集合（数据库表）。

对数据集合做进一步分析，确定集合之间的关系并最终形成数据库物理模型，以便开发人员建立物理数据库。

2数据库设计

2.1抽象数据对象

2.1.1系统主要业务分析

根据物流系统的业务流程描述，我们大致可以从中抽象出几个数据集合，如：

普通用户、会议申请、会议室管理、设备管理、会议管理

按照业务及系统功能简单总结数据对象：

●用户

●会议申请信息

●会议审批

●会议设备

2.1.2需求分析参考

根据系统需求分析内容进一步确定数据对象。

由于系统需求分析中考虑到会议室和会议设备间有一定的区别和联系，即会议室一般包含固定设备和移动设备，两者之间并不是并列关系而是所属关系，所以将会议室默认含有固定设备，这样，设备只有移动设备分开，并提出单独的信息维护功能，数据库对象也进一步细化将会议设备分成，会议室和相关设备。

会议申请和会议审批操作的都是相同对象所以将两个数据对象进行合并，其他数据对象没有变化。

总结数据对象：

●用户信息

●会议信息

●会议室

●会议设备

2.2数据库结构设计

根据系统的分布式部署设计，数据库将部署到一部独立的计算机中。

根据前期的分析，系统将有大量的数据存放入数据库。

预留数据库空间500m，日增长约3m，日志空间1G，日增长5m。

数据库位置：

*oracle9ipath*/n2ms/db/

日志位置：

*oracle9ipath*/n2ms/log/

2.3数据库设计命名规范

1，表名命名规则

本数据库使用的表名一律采用有意义的小写英文字符命名，考虑将来编码方便，表名不

使用‘-’连接相关

2，表项命名规则

本数据库各个表的每个字段，依照表名命名规则，全部使用有意义的小写英文字符命名，字段名不适用‘-’连接相关字符，方便编码书写。

2.4数据库逻辑设计

表设计中应注意的问题：

1．对于字符类型的字段，要仔细确认字段的可能长度。

在oracle数据库设计中，一般来说，对于定长的字符数据字段，取字符类型（char），对于不定长的，取变长字符类型（varchar）。

2．对于以分类形式出现的字段，建议不使用字符类型，而使用数字类型。

如：

货物是否配送为是或（和）否；如果用字符类型，则将这些字符串需要入库；如果使用数字类型分别用1、0代表高职、中职、低职，则入库的是数字信息，从程序编写的角度考虑，后者更好维护一些，主要体现在如果是多语言版本时，我们不需要在程序中将这些字符串信息进行判断处理。

2.4.1数据库表名汇总

表2-1数据库表

数据库表名

中文名

文字说明

meet_app

会议申请信息

保存所开会议的基本信息

meet_room

会议室

保存会议室情况的相关信息

facilty_meet

设备信息

保存会议设备的相关信息

Equipment_stype

设备类型

保存相关设备类型信息

users_inf

用户信息

保存系统用户的基本信息

power_info

权限信息

保存系统的权限信息

role_u

角色

保存相关角色信息

dept_u

部门信息

保存相关部门信息

e_mail

邮件信息

保存邮件信息

file_inf

文件信息

保存相关文件信息

2.4.2数据库表结构设计

2.4.2.1逻辑表结构

●Meet_app

表2-2meet_app表项

中文

英文

数据类型

可否空

初始值

说明

会议信息主键

meet_id

Number

否

主键，流水自增

会议主题

meet_title

Variablecharacters（30）

可

主要内容

meet_content

Variablecharacters（300）

可

会议开始时间

start_time

Date&Time

可

会议结束时间

end_time

Date&Time

可

与会人数

meet_num

Longfloat

可

审批状态

meet_state

Variablecharacters（10）

可

审批意见

meet_idea

Variablecharacters（100）

可

●meet_room

表2-3meet_room表项

中文

英文

数据类型

可否空

初始值

说明

会议室主键

meetroom_id

Number

否

主键，流水自增

会议室名称

meetroom_name

Variablechar（30）

会议室地址

meetroom_addr

Variablecharacters（30）

可

可用状态

possib_state

Shortinteger

可

目前状态

now_state

Shortinteger

可

容纳人数

meetroom_num

Number

可

●facilty_meet

表2-4facilty_meet表项

中文

英文

数据类型

可否空

初始值

说明

设备主键

facility_id

Number

否

主键，流水自增

设备名称

facility_name

Variablecharacters（40）

可

设备购入时间

buy_time

Date

可

占用状态

on_state

Number（10）

可

可用状态

posib_state

Shortinteger

可

设备标识

facility_tag

Variablecharacters（10）

否

●user_info

表2-5user_info表项

中文

英文

数据类型

可否空

初始值

说明

用户主键

us_id

Number

否

主键，流水自增

用户名称

us_name

Variablecharacters（30）

可

用户登陆账号

us_account

Variablecharacters（30）

可

所属部门

us_department

Variablecharacters（30）

可

用户密码

us_psw

Variablecharacters（30）

可

●power_info

表2-6power_info表项

中文

英文

数据类型

可否空

初始值

说明

权限主键

power_id

Number

否

主键，流水自增

权限描述

power_describe

Variablecharacters（30）

可

●e_mail

表2-7e_mail表项

中文

英文

数据类型

可否空

初始值

说明

邮件主键

mail_id

Number

否

主键，流水自增

主题

topic

Variablecharacters（30）

可

发送时间

sendtime

Date

可

内容

mail_content

Variablecharacters

可

●role

表2-8role_u表项

中文

英文

数据类型

可否空

初始值

说明

角色主键

role_id

Number

否

主键，流水自增

角色名字

role_name

Variablecharacters（30）

可

●dept_u

表2-9dept_u表项

中文

英文

数据类型

可否空

初始值

说明

部门主键

dept_id

Number

否

主键，流水自增

部门名字

dept_name

Variablecharacters（30）

可

●file_inf

表2-10file_inf表项

中文

英文

数据类型

可否空

初始值

说明

文件信息主键

flileinf_id

Number

否

主键，流水自增

文件大小

file_size

Longfloat

可

文件名称

file_name

Variablecharacters（30）

可

文件格式

file_format

Variablecharacters（10）

可

2.4.2.2数据库表逻辑ER图

图中“”表示多对一关系，三叉线表示对应的多方表，多对多应该为“

”。

2.4.2.3表之间的关联设计

在数据库ER逻辑模型的基础上确定ER物理模型，通过主外键的约束明确表之间的关系。

该物理模型可直接映射到数据库中进行物理操作，以便据此建立数据库结构。

ER物理模型如下：

物理模型字段表如下：

Table

column

Code

description

会议室

会议室主键

meetroom_id

主键索引

会议室名称

meetroom_name

会议室地址

meetroom_addr

可用状态

possib_state

容纳人数

meetroon_num

目前状态

now_state

会议申请

会议信息主键

meet_id

主键索引

会议室id

meetroom_id

由会议室信息表引用的外键

会议主题

meet_title

主要内容

meet_content

与会人数

meet-num

会议开始时间

start_time

会议结束时间

end_time

审批意见

meet-idea

对应建议修改的会议申请要写明原因，如：

会议内容欠妥、申请会议室冲突等

审批状态

meet_state

会议申请有未审批、审批通过、建议修改三种状态

会议设备

设备主键

facility_id

主键索引

设备名称

facility_name

类型主键

ft_id

由设备类型表引用的外键

当前状态

now-state

可用状态

posib_state

购入时间

buy_time

设备标识

facility_tag

标志移动还是固定设备

设备类型

类型主键

ft_id

主键索引

类型名称

ft_name

用户信息

用户主键

us_id

主键索引

部门id

dept_id

姓名

us_name

账号

us_account

密码

us_psw

部门

us_department

文件信息

文件信息主键

file_id

主键索引

会议信息主键

meet_id

由会议信息表引用的外键

文件名称

file_name

文件大小

file_size

文件格式

file_type

部门

部门主键

dept_id

主键索引

部门名称

dept_name

权限信息

权限主键

power_id

主键索引

权限描述

power_describe

角色信息

角色主键

role_id

主键索引

角色名字

role-name

role_power

角色主键

role_id

权限主键

power_id

邮件

邮件id

mail_id

主键

主题

topic

发送时间

sendtime

内容

mail_content

会议申请—设备

会议申请id

meet_id

主键索引

设备id

facility_id

主键索引

用户—邮件

用户id

us_id

邮件id

mail_id

会议申请—用户

会议申请id

meet_id

用户id

us_id

申请人id

appop_id

外键关联说明：

表2-7外键关联说明

描述表名

外键引用表

外键字段名

关联表

表关系

说明

文件信息

会议申请

会议信息主键

不是

多对一

一个会议信息可以有多个文件信息

会议申请

用户信息

用户主键

是

多对一

该表是用户信息表与会议室表多对多关系的关系表，每个关系就是一个会议申请

会议室

会议室主键

多对一

会议设备

会议室

会议室主键

是

多对一

该表室会议室与设备类型多对多的一个关系表，每一个关系代表一个设备

设备类型

类型主键

多对一

权限信息

角色

角色主键

不是

多对多

一个角色可拥有多个权限，一个权限可以给多个角色。

邮件

用户信息

用户主键

是

多对多

一个用户可以发送多个邮件，一个邮件可以被多个用户接受

2.4.2.4难点说明：

会议设备与会议申请的复杂关系

●由ER物理模型局部表关系如下“图2-3物理ER图局部1”

图2-3物理ER图局部1

会议申请与会议室是多对一的关系，会议室和设备是一对多的关系，

系统需求中有些设备不属于任何现有会议室，这些设备不会象其他设备那样成组的与会议申请对应，而是具有单独的对应关系。

由于从局部图中可以看出，会议申请和移动设备间的对应关系是多对多关系。

系统需求中，移动设备不属于任何会议室，这些设备不会像固定设备那样成组的与会议申请相对应。

会议室和会议申请是一对多的关系，会议室和设备间是一对多的关系，会议申请和设备是多对多关系。

复杂关系成因

从上面两种情况，会议室和会议申请的关系是指的是和移动设备和固定设备都有这种关系，而会议申请和会议设备的关系是指的移动设备的关系，一个会议申请多个移动设备，而移动设备能被多个会议申请。

本来应将移动设备和移动设备分开，而为了减少冗余，将其合为一个表，从而减少开发麻烦。

这就在不影响业务功能的情况下简化了一张表。

2.5存储过程设计

存储过程是一组预先定义并编译好的SQL语句，可以接受参数、返回状态值和参数值，并可以嵌套调用。

使用存储过程可以改变SQL语句的运行性能，提高其执行效率。

存储过程还可用做一种安全机制，使用户通过它访问未授权的表或视图。

在本系统中可协助应用服务器完成日志记录功能，及当用户进行个中数据库CURD操作室记录相应信息到到日志表中。

举例：

createorreplaceprocedureloginsert

（optypeinstring,optimeinstring,useridinoutint,tablenameinstring,opflagoutint）

2.6isbegin

insertintologtablevalues（power_seq.nextval,optime,optype,userid,tablename）;

selectpower_seq.currvalintoopflagfromdual;

endloginsert;

触发器设计

触发器是一种特殊的存储过程，当表中的数据被修改时，由系统自动执行。

使用触发器可以实施更为复杂的的数据完整性约束。

举例：

createorreplacetriggerautodel

afterdeleteonroom

foreachrow

declare

--localvariableshere

begin

deletefacilityfwheref.rid=:

old.id;

endautodel;

2.7Job设计（定时触发功能）

数据库系统提供了Job功能，该功能可以用来解决需要定期处理商业数据的问题。