思路:
1. 需求分析
2. 概念模型设计
3. 逻辑模型设计
4. 数据库物理设计与数据库保护设计
5. 处理功能设计
6. 数据库应用系统的实现
7. 数据库应用系统运行
1.需求分析
用户需求:系统现状,要解决的主要问题,达到的具体指标等。
业务流程分析:描述系统的业务流程,画出规范的业务流程图。
信息需求分析
资料收集:了解业务流程中用到的相关实体对象及其属性信息。
事项分析:分析资料中的数据,检查是否有要补充的基本数据项,是否有要改进的地方,补充改进之后,得出所有基本项。
功能需求分析:改进完善业务流程图,分析用户需要系统完成哪些任务,逐层分解,画出功能层次图。
2. 概念模型设计
按照ERD设计原则进行概念模型设计,具体原则如下:
原则①确定实体:能独立存在的事物,例如人、物、事、地、团体、机构、活动、事项等等,在其有多个由基本项描述的特性时,就应把它作为实体。
原则②确定联系:两个或多个实体间的关联与结合,如主管,从属,组成,占有,作用,配合,协同等等,当需要予以关注时,应作为联系。实体间的联系可分为一对一、一对多、多对多等三类,在确定联系时还要确定其类型。
原则③确定属性:实体的属性是实体的本质特征。实体应有标识属性(能把不同个体区分开来的属性组),并指定其中一个作为主标识。联系的属性是联系的结果或状态。
原则④一事一地:信息分析中得到的基本项要在且仅在实体联系图中的一个地方作为属性出现。
这条原则是对ERD的检验原则,对确定其构思是否正确具有很大的意义。首先要看ERD中有没有重复出现的属性名,如果有,一定是错误的,要分析原因,消除重复。然后要看有无不在信息分析中作为基本项出现的属性,如果有,不一定是错误,但如果不符合基本项的要求,就是错误的,要分析原因,予以改正;如果是基本项,则往往是业务流程用到的资料不太完备,数据库设计者与用户协商后加上去的,要分析增加是否真有必要;如果信息分析中列出的基本项在ERD中没有作为属性出现,则一定要分析原因:有时是不小心遗漏了,那就要补充到适当的地方;有的是联系的表现形式。上图符合一事一地检验原则
3. 逻辑模型设计
一般逻辑模型设计:写出由ERD导出一般关系模型的四条原则,列出数据库初步构思的关系框架(二维表的表头)[与具体DBMS无关],并检查改进之。
具体逻辑模型设计:按所用的DBMS要求,设计表(文件)的具体结构,在关系框架下补充字段类型、长度、小数位数等行。
4. 数据库物理设计与数据库保护设计
设计索引:在表(文件)的具体结构关系框架下补充字段索引行或在框架外补充索引说明,指出索引字段或索引表达式、索引类型。
设计表间关系:列出父表与子表的关联索引,指出要建立的表间关系的类型。
完整性设计:列出主要字段完整性的字段名、完整性约束条件;列出记录完整性约束及其约束条件;列出参照完整性表。
在有多个用户操作时,考虑用户授权与安全性控制。
5. 处理功能设计
注意:此时系统未实现,设计结构都是写出或画出的,而不能是系统运行生成的
模块设计:用户身份验证、菜单等。
子模块设计:按系统业务要求设计各项业务模块和系统管理模块,要能完成系统业务和系统管理功能。
6. 数据库应用系统的实现
数据库及其表结构的建立:建立数据库描述文件及用命令定义并建立其数据库表),注意完整性、索引与永久关联的实现,并附打印出的源模式(CREATE TABLE命令)与作为命令执行结果的数据库表结构及其关联图、参照完整性表。
数据输入:实现5.2.1中的输入程序后,用这些输入程序或系统的追加插入命令录入数据,并打印出的各表的内容。
7. 数据库应用系统运行
写出系统操作使用的简要说明。
按使用说明运行系统并打印出运行结果(至少有两个查询结果和两个报表输出结果)。
系统评价:采用的有特色的技术与技巧;成功之处与主要特点;系统会改进完善之处和进一步工作的打算。
这么大的题目,指望有人专门给你解决,1000分估计也没人干