数据库设计理论及应用(3)——需求分析及数据流图

20 篇文章 1 订阅
19 篇文章 0 订阅

图4.1 数据流图图元
 
接口:用直角矩形表示。这里接口可以是与其它信息系统的接口,也可以是角色(人机接口)。

l         进程:一般用椭圆表示,但Visio中用圆角矩形表示,可能是考虑椭圆中可以容纳的字比较少的原因。数据流图中的矩形一般表示一个功能模块或一个过程,对应一个或一组动作。

l         数据存储:用右边开口的矩形表示,表示数据库中存储的对象。另外在数据流图中,如果一个存储过程在同一个图中出现多次(主要是防止画的线交叉),还经常在在矩形左侧向右一点加个竖直线表示,但Visio中没有做区别。

l         数据流:用带箭头的直线表示,表示数据的流动方向。

5.数据流图举例
这是教科书上的一个例子(王珊,《数据库系统概论》),某厂管理信息系统包括三个模块:销售管理子系统、劳动人事管理子系统和物资子系统。其中销售子系统的基本需求是:

(1)       处理顾客和销售员送来的订单。

(2)       工厂是根据订货(订单)安排生产的。

(3)       交出货物同时开出发票,并记入应收帐款。

(4)       收到顾客付款后,根据发票存根和信贷情况进行应收帐款处理。

这个需求太笼统了,我们逐步细化这个需求,并采用数据流图作为辅助分析手段。

5.1 销售管理子系统第一层数据流图

图5.1 第一层数据流图
 
该图的绘制依据以下需求(可以将下面的描述与图形对比以理解图形):

(1)       不管是顾客还是销售员送来的订单,发起者都是顾客,销售员只是顾客的一个代理,因此系统都认为是顾客送来的订单。

(2)       顾客送来订单后,订单数据进入1.0(送进订单)模块进行处理。这里编号为1.0是为了后续分析方便,如果这个模块还能细分处其它子功能,则编号为1.n。

(3)       主管部门在送进订单模块对订单进行核对,主要核对价格是否正确,以及顾客账目状况(是否拖欠了太多应收帐款),因此要参考产品描述信息和应收帐款信息。这里我们就发现了两个需要存储的对象。

(4)       主管部门审核后,告知1.0模块(一般是点个按钮),不管批准与否,都要通知顾客。

(5)       已批准订单送入2.0模块进行处理。

(6)       2.0模块首先将订单信息保存,存入“订单记录本”。同时生成生产通知单,发送给生产部门以进行生产。

(7)       生产部门的生产是一个封闭过程,该系统无法控制。生产完成后,开具发票。

(8)       开发票时,一方面要调整应收帐款(财务术语,只要开了发票,就是应收帐款;付款后冲抵掉应收帐款);另一方面,生成包装通知单(包括发票、产品说明等、配件说明等)发送给顾客。

(9)       顾客结算数据时,使用支付过账模块(4.0),调整应收帐款。

(10)   另外系统需要提供一个应收帐款辅助模块,用于:为主管部门生成应收帐款报表;若实际业务往来中出现漏操作的情况,手工调整未付差额,并将财务变动通知顾客。

图中两个“应收帐款”是同一个数据存储,画到一起数据线会出现大量交叉的情况,所以画了两个。

下面我们看一下各个功能模块是否可以细分。

5.2 接收订单
这个对应第一层数据流图的1.0模块,对顾客来说,在第一层数据流图中名为“送进订单”,但对于我们的系统来说,称为“接收订单”更确切一些。

这一步的过程是:主管部门拿着用户(或销售员)填写的订单,调出价格信息和该顾客账目信息进行核对,决定是否批准,然后将订单的某一联反馈给顾客(毕竟顾客没有操作这个系统的权限,只好手工处理了)。对已批准的订单,送入下一步进行处理(2.0)。

图5.2 接收订单
 
顾客送进订单数据后,首先核对价格,这时要参考“产品描述”里面存储的价格信息。

(2)       价格核对后,核对顾客账目状况,看一下该顾客是否拖欠了太多款项,这时要参考“应收帐款”信息。

(3)       账目已核对的订单,将价格和账目的核对情况,发送给主管部门,由主管部门决定是否批准。

(4)       不管是否批准,都要通知顾客。

(5)       已批准订单送入2.0(处理订单)。

5.3 处理订单
已批准的订单进行登记,并分配工种(如车工、钳工、焊工、电工等),生成生产通知单发送给生产部门安排生产。同时生成待完成订货清单,供生产部门参考。

生产完成后由生产部门将数据送入下一环节:开发票(3.0)。

5.4 开发票
图5.4 开发票
 
生产完成后,开具发票。开发票后合同额即记入应收帐款,同时将发票信息存入发票主清单,并由系统生成包装通知单信息提供给顾客。

开发票后将发票分配一个发票号(当然现在的发票都是全国统一编号,每张发票事先都已经编好号了,呵呵),并记人发票记录本。

5.5 支付过账
顾客结算时有两种方式:支付货款或信贷。

支付货款后,系统记入贷方余额,具体操作是调整应收帐款信息。如果信贷,需要根据有个审批环节,如果批准,则记入借方余额,操作也是调整应收帐款(似乎这个地方不用调整,因为开发票时已经调整了)。

5.6 提供应收帐款
这步不能进一步细化,已经完成。

本文转自: http://www.dezai.cn/Article_Show.asp?ArticleID=23988&ArticlePage=1

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库课程设计——健康档案管理系统 数据库 课程设计报告 课 题: 健康档案管理系统 目 录 课程设计的目的和意义…………………………………2 课程设计的目的 …………………………………………2 课程设计的意义 …………………………………………2 需求分析…………………………………………………3 2.1、数据流图……………………………………………………4 2.2、数据字典……………………………………………………7 三、概要结构设计……………………………………………10 四、逻辑结构设计……………………………………………13 五、物理结构设计……………………………………………13 总结 …………………………………………………………15 数据库课程设计——健康档案管理系统全文共35页,当前为第1页。参考文献 ……………………………………………………16 一、课程设计的目的和意义 数据库课程设计——健康档案管理系统全文共35页,当前为第1页。 1.1、课程设计的目的 数据库课程设计数据库原理及应用实践环节极为重要的一部分,其目的主要是为了加强学生对数据库基本概念、原理和技术的掌握,结合实际的操作和设计,巩固课堂教学内容,将理论与实际相结合,强化学生的实践意识,从而提高学生的实际动手能力和创新能力。通过课程设计,可以培养学生分析问题、解决问题以及自学能力,提高和加强学生的计算机应用与软件开发能力,使学生熟练掌握数据库设计工具的使用,提高从事数据库系统建设和管理工作的基本技能和能力。 课程设计的意义 课程设计是学完基础知识后必须进行的一个实践环节。进行课程设计: 有利于基础知识的理解,学生可以掌握一些信息时代生存与发展必需的信息技术基础知识和基本技能,具备了在日常生活与学习应用信息技术解决问题的基本态度与基本能力; 有利于逻辑思维的锻炼 ,在许多常规学科的日常教学,我们不难发现这样一个现象,不少学生的思维常常处于混乱的状态。写起文来前言不搭后语,解题步骤混乱,这些都是缺乏思维训练的结果。程序设计是公认的、最能直接有效地训练学生的创新思维,培养分析问题、解决问题能力的学科之一。即使一个简单的程序,从任务分析、确定算法、界面布局、编写代码到调试运行,整个过程学生都需要有条理地构思,这间有猜测设想、判断推理的抽象思维训练,也有分析问题、解决问题、预测目标等能力的培养; 有利于与其他学科的整合 ,在程序设计,我们可以解决其它学科有关问题,也利用其它课程的有关知识来解决信息技术比较抽象很难理解的知识。在信息技术课整合其它学科的知识,发挥信息技术的优势; 数据库课程设计——健康档案管理系统全文共35页,当前为第2页。有利于治学态度的培养, 程序设计,语句的语法和常量变量的定义都有严格的要求,有时输了一个文标点、打错了一个字母,编译就不能通过,程序无法正常运行。程序设计初学阶段,学生经常会犯这样的错误,可能要通过几次乃至十多次的反复修改、调试,才能成功,但这种现象会随着学习的深入而慢慢改观。这当就能培养严谨治学、不怕失败、百折不挠的科学精神和态度。 数据库课程设计——健康档案管理系统全文共35页,当前为第2页。 二、 需求分析 任务:设计一个健康档案管理系统 1、功能要求: 该系统的健康文件包括病历文件和体检文件。 登记 将学生的健康信息插入健康文件; 修改 修改一个学生的健康档案记录; 删除 删除学生的健康档案记录; 查询 可以组合各种条件进行查询,显示学生健康信息并打印健康文件报表; 统计 对学生的基本健康状况进行各种必要的统计和分析,由一般统计和动态分析两种。一般统计包括计数和求平均值;动态分析由健康历史求出平均年增长值和年增长率。 2、数据要求: 体检文件:学号、姓名、性别、系别、年龄、身高、体重、胸围、日期 病历文件:学号、姓名、性别、系别、 诊断、日期 数据库课程设计——健康档案管理系统全文共35页,当前为第3页。在这次的课程设计,用户要求我们对该系统的健康文件实现学生信息登记、修改、删除、查询、统计等操作,其健康文件还包含病历文件和体检文件。在病历文件的数据要求有学号、姓名、性别、系别、 诊断、日期,而体检文件的数据要求有学号、姓名、性别、系别、年龄、身高、体重、胸围、日期。而为了使这个健康档案管理系统的设计能够更加接近现实生活,并充分考虑到今后可能的扩充和改变,我们在里面加了一些相应的东西,比如我们将病历文件和体检文件都看成是很多学生的分类,每个学生都有一份相应的病历文件和体检文件,文件是他们不同时期的病历表和体检表,而病历表的属性不止包括学号、姓名、性别、系别、 诊断、日期,还有医疗记录和是否住院等,体检表又包含体检项目,而身高、体重、胸围等均包含在项目名称数据库课程设计——健康档案管理系统全
目录 一 Codd的RDBMS12法则——RDBMS的起源 二 关系型数据库设计阶段 三 设计原则 四 命名规则   数据库设计一个软件项目成功的基石。很多从业人员都认为,数据库设计其实不 那么重要。现实的情景也相当雷同,开发人员的数量是数据库设计人员的数倍。多数 人使用数据库的一部分,所以也会把数据库设计想的如此简单。其实不然,数据库设 计也是门学问。   从笔者的经历看来,笔者更赞成在项目早期由开发者进行数据库设计(后期调优需 要DBA)。根据笔者的项目经验,一个精通OOP和ORM的开发者,设计数据库往往更为合 理,更能适应需求的变化,如果追其原因,笔者个人猜测是因为数据库的规范化,与OO 的部分思想雷同(如内聚)。而DBA,设计数据库的优势是能将DBMS的能力发挥到极致 ,能够使用SQL和DBMS实现很多程序实现的逻辑,与开发者相比,DBA优化过的数据库更 为高效和稳定。如标题所示,本文旨在分享一名开发者的数据库设计经验,并不涉及复 杂的SQL语句或DBMS使用,因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开 发者能有所帮助,也希望读者能帮助笔者查漏补缺。 一?Codd的RDBMS12法则——RDBMS的起源   Edgar Frank Codd(埃德加·弗兰克·科德)被誉为"关系数据库之父",并因为在数据库管理系统的理 论和实践方面的杰出贡献于1981年获图灵奖。在1985年,Codd 博士发布了12条规则,这些规则简明的定义出一个关系型数据库的理念,它们被作为所 有关系数据库系统的设计指导性方针。 1. 信息法则?关系数据库的所有信息都用唯一的一种方式表示——表的值。 2. 保证访问法则?依靠表名、主键值和列名的组合,保证能访问每个数据项。 3. 空值的系统化处理?支持空值(NULL),以系统化的方式处理空值,空值不依赖于数 据类型。 4. 基于关系模型的动态联机目录?数据库的描述应该是自描述的,在逻辑级别上和普通 数据采用同样的表示方式,即数据库必须含有描述该数据库结构的系统表或者数 据库描述信息应该包含在用户可以访问的表。 5. 统一的数据子语言法则?一个关系数据库系统可以支持几种语言和多种终端使用方式 ,但必须至少有一种语言,它的语句能够一某种定义良好的语法表示为字符串, 并能全面地支持以下所有规则:数据定义、视图定义、数据操作、约束、授权以 及事务。(这种语言就是SQL) 6. 视图更新法则?所有理论上可以更新的视图也可以由系统更新。 7. 高级的插入、更新和删除操作?把一个基础关系或派生关系作为单个操作对象处理的 能力不仅适应于数据的检索,还适用于数据的插入、修改个删除,即在插入、修 改和删除操作数据行被视作集合。 8. 数据的物理独立性?不管数据库的数据在存储表示或访问方式上怎么变化,应用程序 和终端活动都保持着逻辑上的不变性。 9. 数据的逻辑独立性?当对表做了理论上不会损害信息的改变时,应用程序和终端活动 都会保持逻辑上的不变性。 10. 数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库 子语言定义,而且可以存储在数据目录,而非程序。 11. 分布独立性?不管数据在物理是否分布式存储,或者任何时候改变分布策略,RDBM S的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。 12. 非破坏性法则?如果一个关系数据库系统支持某种低级(一次处理单个记录)语言, 那么这个低级语言不能违反或绕过更高级语言(一次处理多个记录)规定的完整 性法则或约束,即用户不能以任何方式违反数据库的约束。 二?关系型数据库设计阶段 (一)规划阶段   规划阶段的主要工作是对数据库的必要性和可行性进行分析。确定是否需要使用数 据库,使用哪种类型的数据库,使用哪个数据库产品。 (二)概念阶段   概念阶段的主要工作是收集并分析需求。识别需求,主要是识别数据实体和业务规 则。对于一个系统来说,数据库的主要包括业务数据和非业务数据,而业务数据的定义 ,则依赖于在此阶段对用户需求的分析。需要尽量识别业务实体和业务规则,对系统的 整体有初步的认识,并理解数据的流动过程。理论上,该阶段将参考或产出多种文档, 比如"用例图","数据流图"以及其他一些项目文档。如果能够在该阶段产出这些成果, 无疑将会对后期进行莫大的帮助。当然,很多文档已超出数据库设计者的考虑范围。而 且,如果你并不精通该领域以及用户的业务,那么请放弃自己独立完成用户需求分析的 想法。用户并不是技术专家,而当你自身不能扮演"业务顾问"的角色时,请你选择与项 目组的相关人员合作,或者将其视为风险呈报给PM。再次强调,大多数情况,用户只是 行业从业者,而非职业技术人员,我们仅仅从用户那里收集需求,而非依赖于用户的

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值