数据库系统应用案例学生信息管理数据库的设计PPT文件格式下载.ppt

数据库系统应用案例学生信息管理数据库的设计PPT文件格式下载.ppt

《数据库系统应用案例学生信息管理数据库的设计PPT文件格式下载.ppt》由会员分享，可在线阅读，更多相关《数据库系统应用案例学生信息管理数据库的设计PPT文件格式下载.ppt（26页珍藏版）》请在冰豆网上搜索。

学生学籍变动情况的记录，包括：

休学、复学、转系、结业和毕业等；

学生的奖惩情况的记录和修改，包括：

奖励和处罚。

学生信息的查询。

根据系统所要实现的功能，按照结构化程序设计的原则，可以将整个系统划分为如图所示的若干功能模块。

在明确了系统的功能后，还要进一步细化系统的操作流程，在进行这个步骤时，必须和最终用户反复沟通，不但要考虑实际工作的需要，而且最好能兼顾到用户的操作习惯，尽可能为用户提供最方便的操作。

通过操作流程分析，不但可以具体化系统的功能模块的组成，还可以明确系统中数据流程，明确系统中所要保存的数据以及数据间的关系。

操作数据存储数据流向数据输出,学生信息管理流程图。

需要说明的是，各所学校的实际情况可能有所不同，可以根据实际情况画出符合各自特点的操作流程图。

学生信息管理系统操作流程图,数据库设计数据库设计一般包括如下几个步骤。

需求分析。

概念结构设计。

逻辑结构设计。

物理结构设计。

应用程序设计及调试。

性能测试与确认。

数据库需求分析需求分析是整个数据库设计过程中最重要的步骤之一，是后继各阶段的基础。

在需求分析阶段，需要多方面对整个系统进行调查，收集和分析需求和处理两个方面的需求。

收集资料时数据库设计人员和用户共同完成的。

必须需要用户人员的参与，这是数据库应用系统设计的特点。

收集资料的目的是明确用户的需求。

用户的需求主要包括三个方面。

信息需求，用户要从数据库获取的内容。

处理需求，即完成什么处理功能及采用何种处理方式。

安全性及完整性需求,在对学生信息管理系统操作流程分析的基础上，可以列出概念模型包括以下实体,另外涉及到代码的实体有政治面貌奖励类别惩罚类别,详细的描述,院系设置：

院系编号，院系名称，院系领导，领导联系方式等。

班级设置：

班级编号，班级名称，班级创建事件，班级描述，所属院系，班主任，班主任联系方式。

学生基本情况：

学号，姓名，性别，出生日期，籍贯，所属班级等。

学籍变更记录：

记录号，学号，变更类型，记录时间，详细描述。

奖励记录：

记录号，学号，奖励类别，记录时间，详细描述。

处罚记录：

记录号，学号，处罚类别，记录时间，详细描述。

数据库逻辑结构设计概念结构设计的结果得到一个与计算机，软硬件的具体性能无关的全局概念模式。

数据库逻辑设计的任务是将概念结构转换成特定的DBMS所支持的的数据库模型。

从E-R图所表示的概念模型可以转换成任何一种具体的DBMS所支持的数据模型。

本系统采用关系模型，转换的原则如下。

每个实体转化成一个关系模式，实体的属性就是关系的属性，实体的关键字就是关系的关键字每个1：

1的联系转换成一个关系模式。

每个实体的关键字都是该关系模式的候选关键字。

每个1：

n的联系转换成一个关系模式。

多方的实体的关键字是该关系模式的关键字。

每个m：

n的联系专程一个关系模式。

联系中各实体关键字的组合作为该子模式的组合关键字。

数据库概念结构设计,根据以上概念模式，画出总体E-R：

根据学生信息管理系统的E-R图，通过简单的优化，可以设计6个关系模式（即数据表）来存储所有的信息,表1-1院系设置信息表,表1-2班级设置信息表,表1-3学生信息基本表,表1-4学籍变更记录表,表1-5奖励记录表,表1-6处罚记录表,下附某图书管理数据库的“实体联系图转换为关系表”、“优化”、“完整性约束”和“进一步的思考”的简略报告样式,实体联系图转换为关系表,实体转化为单独的一张表客户：

客户号、密码、姓名、性别、单位、电子信箱、身份证号、VIP等级VIP会员表：

会员等级、会员折扣商品：

商品号、商品名称、类别号、商品描述、单位、规格、单价生产厂商表：

厂商号，生产厂商名、地址、电话商品类别：

类别号、类别名称地址：

地址号、地址名称客户类型：

类型号、类型,多对多联系转换为一张单独的关系表订单：

订单号、客户号、商品号、收货地址、订货日期、订货数量、单价、订单状态、发票号码、订单金额、发货日期评论：

评论号、客户号、商品号、客户邮箱、评论内容、评论时间。

供应：

商品号、厂商号、最低存货量、实际存货量其他一对多的联系通过在多表中添加属性来实现：

客户：

客户号、姓名、密码、客户类型、性别、单位、电子信箱、身份证号、VIP等级商品：

商品号、商品名称、类别号、商品描述、单位、规格、单价,优化,为了减少读者表中的冗余，将读者表分解为：

读者表：

读者编号、姓名、性别、类型、单位号、电子信箱、能否借阅。

单位表：

单位号、单位名称、联系电话。

为了减少图书中的冗余，将图书表分解为：

图书表：

图书编号、名称、作者、ISBN号、出版社号、出版时间、字数、单价、内容简介、所属分类号、入库时间、语言、借出状态、图书种类、图书类别、所在分馆。

出版社表：

出版社号、出版社名称、出版地。

分解前后该表分别属于第几范式？

简化借阅类型表：

借阅类型表：

读者类型、图书种类、借阅册数、借期、续借时间。

若续借时间为0，则表示不允许续借。

优化,确定完整性约束,确定实体完整性约束借阅表：

读者编号、图书编号、借阅日期、应还日期、归还日期、能否续借。

主键是什么？

其他（略）参照完整性约束略用户定义完整性约束数据类型约束。

数据长度、精度约束。

取值范围约束。

电子信箱的格式应为“xxxxxx.xxx”格式。

图书表中出版时间要早于入库时间，语言取值范围为：

中文，外文、借出状态、图书种类、图书类别、所在分馆。

用户表权限的取值范围为0,1，取值0表示普通读者，取值1表示管理员。

借阅表中“借阅日期”大于图书表中“入库时间”，小于“应还日期”和“归还日期”，“能否续借”的取值首先要参照借阅类型表中“续借时间”，如果“续借时间”为0，则“能否续借”值为F，否者“能否续借”初始值为T。

如果借阅表中“归还日期”大于“应还日期”，则对应的读者表中“能否借阅”值为F。

确定完整性约束（续）,借阅表中“归还日期”如果非空，则应大于“借阅日期”。

其他：

如默认值、空值等等。

还有其他约束吗？

确定完整性约束（续）,进一步的思考,在这种数据库模式下，能否检测得到某一客户所购商品数量是否超过实际存量？

可以如何改进？

如何实现商品销售排行榜？

如何确认畅销商品、滞销商品？