信息系统分析与设计案例集.doc

1、信息系统分析与设计案例集案例一 餐厅信息系统的业务流程一家使用了计算机点菜的连锁餐厅最近在某市开业，生意格外兴隆。客人到餐厅后，在计算机上进行选菜，计算机就会显示出餐厅所供应的品种，想吃什么莱，在上面轻轻一点，屏幕上就会出现菜的样子、价钱，原材料以及菜中所含蛋白质和各种维生素的含量，供客人根据自己的需求和口味情况选择。顾客选好莱并付款后，计算机自动将选菜结果通知厨房进行配菜。计算机的使用，不仅给顾客提供了方便而且使餐厅环境改观。现在我们看看该餐厅的信息系统是怎样工作的。假定餐厅中整个业务流程设计成这样：所有微机连成一个局域网，在餐厅、厨房、配餐间、收款处、经理室等都有终端。当顾客来到餐厅时，由

2、服务员携带一台掌上型微机到餐桌前开点菜单，顾客选好后，点菜单的信息被传送到后台的服务器上，在该过程中系统会自动分类，根据顾客点的菜的品种，直接将信息送到制作它的厨师那里。例如顾客点的凉菜订单会被送到凉菜配餐间的计算机上；酒水饮料会被送到饮料室的计算机上：如果是炒菜就送到厨房的计算机上。如果某菜原材料用完，厨师可以在厨房中通过计算机立即送入信息，从而服务员在顾客订菜时，马上就可以通知他某菜的缺货情况。顾客输入信息后，马上就可看到他订的莱的总价格。通过餐厅的打印机也可以很快得到账单，上面列出所有顾客点的莱名和计算的结果。系统也对经理提供信息。例如能提供关于各种原料的价格和采购量，系统能对销售额和各

3、种菜的成本进行比较，从而可以进行成本控制。经理也可以看到一定时期内每一道菜的销售情况，算出它们在总销售额中所占的比例。经理可以根据这些信息来调整菜谱。一、教学目的本案例通过描述某餐厅信息系统的工作流程，说明了信息在业务过程中流动的特点，理解业务流程的含义，体会优化的信息系统业务流成为组织带来的效益。二、讨论参考题1.该餐厅存在哪些业务，用系统的观点画出业务流程示意图。2.该餐厅有哪些信息?它们是如何与以上业务相关联的?3.该餐厅的信息是如何发生，又是如何被加工、转换和被传递的?三、使用建议本案例可以作为讲授信息的流动与转换时使用，也可以作为讲授管理业务调查时使用。信息系统分析与设计案例集案例二

4、 伦敦路透社信息产品的市场显示系统伦敦路透社 70%的收入来源于出售他们国际新闻以及金融信息等基于信息产品。这些产品是通过它的市场显示系统向用户展示的。为改进市场显示系统的可用性，使其能更容易、更方便地满足顾客的要求，路透社让加里森支负责一个最高优先权的项目，任务是改进显示系统的用户界面。为此，加里森去组建了“可用性小组” 。这实际上是一个“虚拟小组” ，除包括加里森及三名路透社成员之外，还包括一些有关的技术公司，如交互图形公司、微软公司的代表。该组还与 500 多名专家保持联系，其中一位是“符号学专家” ，专门负责把计算机的动作翻译成像 Windows 的图标那样的一些符号。该小组并不通过市

5、场调查，去问顾客想要一些什么，而是在他们建立的“可用性实验室”中观察客户们怎样利用路透社的显示系统查找他们想要的信息产品。可用性实验室有两个房间，一个给用户们用。用户在路透社助理人员的伴随下完成一系列就应用系统的实验。另一间房间被玻璃隔成一些小间，各放有一台显示器，显示内容与用户屏幕上的内容相同并用可视信号或者是内部通信系统与用户保持联系实验时，要求客户完成一系列的操作。例如，可以要求用户去查询某支股票的价格，画出它在一定期间内走势图，找出一些相关的消息和公司的财务数据。随着用户的操作，可用性小组的人员就在监视器上观察用户在什么地方发生问题，测试出完成每项操作的时间，留意引起用户工作中断的过程

6、。用户操作过程还被录像，从录像带上能够更精确地测量所用的时间。该实验室每个月能完成 100 个用户的三项至四项主要测试。 实验室还要去了解路透社服务机构接听的用户求助电话，将用户求助问题分为四类，录入数据库并进行统计分析，找出用户遇到的主要问题并设法改进。例如，1994 年 4 月有 34%的电话是有关 RT 工作站反映出的可用性问题的，进一步分析表明 28%的电话是关于报价单问题的，于是路透社就将报价单在工作站上的显示形式进行了改进。可用性小组最后制订了一系列规范，要求所有路透社开发小组开发的软件产品都要经过可用性小组的审查，相同的功能要用相同的图标，图标也必须在可用性小组开发的一系列标准图

7、标集中选用。这些图标，开发小组可以在网络上得到。一、教学目的通过伦敦路透社信息产品的市场显示系统的改进过程的描述，使学生理解原型法等系统开发的方法，以及开发过程中对用户需求进行分析的重要性。二、参考讨论题1.可用性实验室为路透社解决了什么问题？2.说明上述系统采用了什么开发方法？说明该方法的基本思想和基本步骤？3.这种开发方法适合于解决哪一类问题？4.常用的信息系统开发方法有哪些？这些方法分别具有哪些优缺点？分别适用于那些场合？三、使用建议本案例适用于讲授信息系统开发方法的时使用。信息系统分析与设计案例集案例三 A 公司信息化建设的问题出在那里？A 企业属于制造型企业，不仅生产自有产品，而且承

8、接其他企业的外协件生产。几年前，已相继建立起 MPRII 系统，产品设计部使用 CAD、CAPP 、与 PDM 系统，极大的提高的工作效率和质量。A 企业最高决策者是张总裁。 B 企业是 A 企业强有力的竞争对手。关于 A 公司信息化建设状况的描述：日历上写的是星期四，但对于张总裁，这天更象是另一个星期一。每天看起来都象是星期一。因为，从每个星期一的市场情报资料上，张总裁了解到 B 公司逐步在销售上超过了他们，B 公司已经变得更加的盈利，张总裁感到竞争的紧迫感和焦虑，这种紧迫感和焦虑不仅来自外部，而且公司内部也存在很大问题。不管他说什么做什么，他的公司仍在不停的出现各种各样的错误。大到付出昂贵

9、代价，小到让人讨厌，还有一切不大又不小的错误，它们正在缓慢地，但又非常有效的扼杀制约着公司的发展，错误不是由别有用心的人故意制造出来损害公司的，那么问题出在哪了？就在上个月，他们最重要的一个客户对产品规格的要求发生了变动，但是最后满足变动需求的产品没有及时送发货部门，使得货物的集中、装箱、上船的一系列行动无法按时进行，于是他们把另一个不太重要的客户预定的产品用飞机送到该重要客户处，尽管这样，还是比预定的到货期迟了。 （当然那个不太重要的客户也没有按时收到预定的产品） 。尽管他们做了种种的努力（甚至船运改为航运） ，但这个重要的客户并没有感谢他们，只是对 A 公司的销售人员说：他们不能再容忍这种

10、错误了。一个顾客开始越来越延迟的付款，信用部门经理决定先押下他的所有订单。尽管信用部经理已经告诉了发货部领班扣押下那个顾客的所有订单，不幸的是，当时这个领班正在休两星期的假，发货部发货员将该客户的订单集中、检验、并发给顾客。一周后这个拖欠付款的顾客宣布破产了。但当张总裁对着发货人发火的时候。发货部领班反驳说：仅仅一周前，你告诉过我们要确保货物按时发出，我正是照你说的做。自从那次激烈的讨论后，发货部门总被一种愤怒、委屈的沉寂包围着。销售人员完成了他们的销售计划，但公司的利润还在持续下滑。面对市场竞争环境，下游客户从自身业务出发对供应链上游成员，提出了新的要求，他们需要建立更紧密的联系，以节约投产

11、准备阶段时间和费用。例如，下游客户希望供应伙伴A 公司的工程师，能参与他们的设计过程中，利用电子手段，实现双方采购信息系统和销售信息系统的信息对接、实时交换和查询产品设计的相关技术文件。他们希望接到自己的订单时，只需“按一下鼠标按键”就可把订单实施计划直接变成原材料计划，通过跨组织的网络系统传递和纳入 A 公司的生产制造系统和托运计划。但是 A 公司无法满足上述要求，导致下游客户的原材料短缺，A 公司也经常运载体积不够而大伤脑筋。就在两周前，为了按期交货，A 公司刚刚航空托运了一批货给一个客户。这件事源于船运时遇到的运载空间问题。更早一周，是由一个 A 公司的主要供应商引起的，再早两周前，总是

12、有各种各样的原因造成了一次又一次的损失。A 公司现在使用的 MRPII 系统，假设前提是供应商都能够按照约定无条件供货，而且不得更改。实际操作时，往往存在供应商有条件改动的可能。即使供应商做到无条件供货，A 公司的管理者们也没有足够的时间和能力来应付大量的改变的约定，他们也没有合适的信息处理系统来支持他们调整生产计划。信息系统分析与设计案例集三个月以前，张总裁和他的所有管理层职员一起用两天时间召开了的关于企业销售策略实施计划的决策会议，这个会议开的非常成功，至少他们是这样说的。但是这些实施计划并没有被贯彻到日常的决策和销售运做中。这种现象早年也发生过。因为，张总裁不肯定管理人员做出的那些决策是

13、最佳的，他感到那些高层职员，包括他自己都不能获得较全面的市场与营销方面的细节层次数据的支持。例如：他的销售人员每隔一段时间就会发现有一个减价销售大量商品的机会，A 公司应该接受这个价格吗？原材料采购部经理正试图说服 A 公司实施他们制定的关于“减少计划” ，即减少投产准备时间，减少存货。这听起来似乎是有前途的，但积压的存货并不能如他们所愿地减少，况且，经理还需要对操作工作中决策过程与规则做必要的改变。A 公司承接其它制造企业的定制产品订单任务时，销售人员必须不停的向 A 公司办公室汇报很多各种各样的产品报价单，因为那些专业的规格资料实在是多的数不胜数。客户们反映 B 公司（A 公司的竞争对手）

14、的销售员就可以把报价单放在客户的办公室上，并且邀请客户上网联接到他们的主机，实现在线实时的报价和订单合同洽谈。A 公司的售后服务是相对独立的一套业务系统，通过公司计算机网络系统，售后服务人员可以使用常用的自行研制的软件工具，从数据库中直接调用资料，获取关于产品数据及技术资料，服务维修咨询和指导。当他们更换了一个由 A 公司的供应商处得到的配件时，他们也试图从供应商那里得到支持。但是，不论是售后服务系统，还是 MRP系统都没有记录和保存这些信息，而且，当外出服务工程师在外面修理一台机器时，售后服务系统并不能给出该客户的一张完整清晰的合同订单，无法清楚提供哪些更换部分是客户质量保证书或服务协议涵盖

15、的，哪些不是。对于 A 公司的工程设计部门负责产品开发设计，产品数据管理系统（PDM）和MRP系统用的都是一样的重要信息系统，但它们不是集成的，所以工程师必须把 PDM系统的产品数据的变化人工输到 MRP系统中，以保证它们同步性、数据的一致性。产品的设计过程，从产品概念构思到产品上市，需要大约个月的时间。市场部本来应能提供关于新产品开发的创意思想，尽管他们基本没有能力也不必要按工程设计规范要求进行描述。但当设计工程师开始设计新产品时，市场部门却不能直接十分清楚表述市场、客户真正需要的具体细节数据和信息。所以工程师只是在那些已掌握的数据信息基础上尽量发挥。A 公司相当大的一部分不断增长的商业机会

16、，需要更多资深工程师的努力，而不是简单体力劳动力，公司的优良业绩必须体现在财务利润报表上，但 A 公司已经连续三年利润滑坡了，因此它不得不解雇了一大批工程师，其它的一些工程师也纷纷跳槽，使得A 公司失去了更多的有丰厚的利润的商业机会，这远比节省的劳动力费用高的多。总而言之，A 公司和许多其它制造公司一样，高层决策者们必须在低效率、缺少活力的公司和高效率、充满活力的公司之间最出果断的战略决策和信息系统的规划。一、 教学目的通过运用系统规划理论和方法的学习，结合对此案例的分析，帮助学生理解信息化建设对企业经营发展和竞争能力的重要作用，提高对企业信息管理需求分析的能力，培养设计企业信息系统的目标与建

17、设方案的能力。二、讨论参考题1.分析整理 A 企业的管理业务流程中存在的问题？2.分析整理 A 企业对信息系统的需求？3.你对 A 企业目前如何有效地进行信息系统的选择有什么建议？信息系统分析与设计案例集4.A 企业的信息系统建设正处于那个阶段？5.谈谈你们对 A 企业信息系统规划的设想 ?三、使用建议本案例可用于本科生开设的“管理信息系统”课程， “信息系统分析与设计”课程，“信息系统的战略规划”教学专题。四、案例需要的背景知识计算机基础知识，企业生产运作与管理知识，信息系统规划、分析与设计知识，数据库原理及应用知识，企业经营战略与管理知识、企业资源计划知识等。信息系统分析与设计案例集案例四

18、 对某企业的信息系统的初步调查（1）企业背景：该企业于 1983 年开展计算机辅助管理工作，在硬件设备配置、软件开发、技术队伍方面已初具规模，对企业的发展起了积极的推动作用。到了 1999 年达到顶峰，年产值 1个多亿，利润率为 20%。但是，随着企业从单纯生产型向生产经营型转变，由原来只生产空调压缩机的零件到现在的整机生产，生产过程日趋复杂，企业管理水平落后的矛盾日益尖锐，具体表现在长期采用的传统手工业或微机加手工管理方式无法满足经营中多层次、多品种、多批量生产计划的管理，也满足不了任何一种产品生产全过程的动态信息管理。各部门间信息沟通不畅造成信息大量冗余和差异，决策者得不到他所想要的准确信

19、息，加之，原材料的不断涨价，市场需求减少等原因，使产品成本连年上升，由于压缩机需求关系趋向饱和，使得市场价格又不断下降，企业利润大幅度下滑。从 2000 年开始，企业领导为了有效地降低成本，提出划小核算单位、分级核算的方案，用信息系统完成企业的各级核算工作，对成本进行定量化的分析，其目标是完成全企业的各级核算工作，有效地控制成本。（2）该企业现行的系统主要用于人事管理、财务管理、计划、统计、计件、工资管理等，没有把已建立的系统与相关的数据结合起来，完成成本核算。经过对企业目前的经济状况及技术力量的调查分析，认为比较容易把这些彼此分散开发的软件系统化、标准化，把相关的数据结合起来，开发一个使得企

20、业的决策经营以市场为核心，以成本为依据，以利润为目的的成本核算管理信息系统。（3）企业成本核算系统的目标、结构及功能：系统目标。首先，建立一个能覆盖从原材料进厂到产品出厂，物料全过程的成本核算系统。该系统集成了车间成本核算、材料核算、动力核算、销售核算、资产核算等子系统；通过各个子系统的运行，信息共享，数据互相传递，完成整个企业的成本核算工作，有效地控制成本，提高利润率。系统结构及功能。从对企业的现状提出问题到确定目标，经过组织机构调查、确定系统边界，分析业务流程及功能分析等步骤，需要确定的系统结构如下图所示，图中表明了成本核算系统的各子系统要完成的基本功能。成本核算系统车 间 成 本 材 料

21、 核 算 动 力 核 算 销 售 核 算 资 产 核 算车间统计车间材料车间动力车间工资车间材料科室材料消耗分析统计材料消耗动力核算销售费用仓库库存运输费用销售分析设备管理资产核算仓库库存仓库库存仓库库存信息系统分析与设计案例集（4）计算机逻辑配置方案。总体规划的后期，要考虑计算机逻辑配置方案，这是从系统需求的角度提出对计算机配置的基本要求，而不涉及其具体硬件型号。计算机逻辑配置方案设计从以下几个方面考虑：客观条件约束。包括资金、现有计算机系统、技术力量（开发和维护） 。网络布局。按照系统的要求制定网络布局方案。硬件系统。包括计算机的存储量、运算速度、外部设备的功能、效率、可靠性、通行设备的能

22、力等。软件系统。包括操作系统、数据库管理系统、网络软件、程序设计语言等。一、教学目的通过对某企业的管理背景的初步调查，说明初步拟定信息系统目标、初步构建信息系统的框架的过程。二、讨论参考题1 分析该企业成本管理存在的问题？2 分析该企业对信息系统的需求状况？3 你对该企业成本核算系统的目标的拟定、结构及功能的构建有何建议和设想？三、使用建议：本案例可在讲授系统规划阶段进行初步调查拟定系统目标、设想系统功能时使用。信息系统分析与设计案例集案例五 一个某零部件生产厂的销售系统一个某零部件生产厂的销售系统。该厂的产品是各种不同类型的零部件，其加工周期为 10 天左右。工厂的生产逐渐转向以销定产。工厂

23、设有销售科，销售科的工作除推销产品外，还进行接受合同、处理合同(、向计划科提出生产要求并如期执行合同的信息加工工作) ，另外还要管理一个成品 库。我们要开发一个用于销售管理的信息系统，它可以是整个企业管理信息系统的一个子系统，也可以是一个独立的信息系统。现行销售系统的详细业务如下：接受合同: 用户(即顾客通过各种方式向厂方订货，当收到用户 订单 后， 首先对每份订单粗略地检查，看是否合理.例如填写是否正确，订货货名是否属于本厂产品等。 然后根据年度 生产计划 以及现有 库存 数，估计是否能按合同日期交货，如能满足或超出预定计划 30%之内，则同意此项订货，还要将此订货合同送到科内会计那里，会计

24、审查订货单位的信用情况，会计处有一本 顾客付款情况账本 ，如该顾客无欠款或是新顾客则会计签字表示同意接收，送至科长，科长审核上述几方面情况后正式接受此订货合同，形成正式订货 合同文件 ， 将合同情况向生产计划科作 出报告 ，以便安排生产，同时向订货单位发出 付款通知 ，也通知财务科准备 收款 。处理合同:由于顾客既不希望厂方拖延交货日期以致延误生产又不希望过早收货以致材料堆积而造成浪费。 本厂在每周一查询 合同文件 中本周到期合同，找到本周该到期交货的合同后，核实库存 账，看看库存中是否已有此批该发的货物。一般情况应该已有库存， 如果发现没有库存，及时通知计划科，赶紧 补生产 ，由于本厂产品周

25、期较短，所以可以在下次查找时再次处理该合同。 如库房已有此货，再核实 顾客付款情况账本 中顾客是否已付款， 如已付款则作 发货单 ，一份交发货员，将货发出， 一份随货寄 至顾客。并在订货合同文件上注销。 管理成品库:该科还有一个成品库，它的管理也在该信息系统中， 当接收 发货单 后，完成修改 库存 账的出库处理。 当成品车间送来成品 入库单 时，保管员验收入库时应在 库存 账上登记。该销售信息系统的数据流程图：信息系统分析与设计案例集信息系统分析与设计案例集信息系统分析与设计案例集信息系统分析与设计案例集一、教学目的本案例通过描述一个某零部件生产厂的销售系统，说明了系统分析阶段针对业务流程和数

26、据流程进行调查分析的描述表达方法，有助于学生掌握业务流程的描述方法和数据流程图的绘制方法。 二、讨论参考题1分析该系统的业务流程和数据流程有那些需要改进的地方？2结合案例请你谈谈绘制数据流程图时的基本思路以及应注意的事项？三、使用建议本案例可以作为讲授信息系统的系统分析阶段详细调查工作时使用，也可作为绘制数据流程图的示例。信息系统分析与设计案例集汽车修理管理信息系统某汽车修理厂根据业务发展的需要，决定建立一个以数据库为基础的管理信息系统，以代替单一的人工管理。目标系统取名为“汽车修理管理信息系统”(QCXLM 工 S)。通过用户调查，初步整理出以下的结果：1系统的数据需求分析调查获悉，该厂在业

27、务管理上共使用 5 种单据，4 种帐册和 3 种主要报表。现分述如下：(1) 5 种单据 编号 名称 填写人D1D2D3D4D5修车登记单汽车修理单零件领用单零件入库单修车发票送修人修理派工员和修理工修理工仓库管理员财务人员业务流程： D1 由送修人填写。修理派工员据此开出修理单 D2，分派给指定的修理工执行。如果在修理中更换零件，一律由修理工填写零件领用单 D3 向仓库领用。修理结束后，修理工将 D2 交回派工员，然后转财务部门结帐并开修车发票 D5。D4 在零件入库时由仓库管理员验收并且填写。图 9。498 显示了这些单据的格式与内容。信息系统分析与设计案例集信息系统分析与设计案例集信息系

28、统分析与设计案例集除上述 3 种报表外，该厂还使用若干种统计表，供有关部门作分析或预测之用。例如在半年一次的统计， “平均修理周期分月统计表”(含月份和平均修理天数两项) 、 “修理次数分型统计表“（含汽车型号、修理次数二项)、 “修理次数分类统计表”( 含修理项目、修理项数二项)等多种，为了简化所讨论的问题，这里就不细述了。对目标系统的功能需求通过对当前系统的调查和与用户的共同讨论，对将要开发的目标系统提出了如下的总体需求；(1)用数据文件代替现用的全部帐册；(2)具有对各种数据文件装入和修改数据的功能；(3)能计算修车费用和开发票。其中修车费按下列各式计算：零件费 零件价格*耗用数量修理费

29、小时工资*修理工时* 3总 计零件费+ 修理费(4)能找出需要订货的零件，编制并打印零件订货计划。订货条件：零件库存量 最低库存量订货数量：额定订货量(5)按现行格式和内容编制和打印零件耗用月报表和修理工资月报表；(6)有多种查询和统计功能。为了简化讨论，具体需求就从略了。2数据分析（ DFD 和数据字典）这是数据库系统开发中十分重要的一项活动。其首要任务，是确定目标系统中使用的 全部数据，为它们取名和定义。在传统的软件工程方法中，数据常区分为数据文件、数据流 (组合数据)和数据项(单个数据) 三大类。分析中要为每一数据编写一个数据条目，然后将 所有条目合编为数据字典。这样，在随后进行的系统设

30、计中不论有多少人信息系统分析与设计案例集参加，大家都可 以数据字典为统一的根据不必担心因数据不一致而导致矛盾和混乱了。（一） 确定各个单项数据(不含数据文件和数据流 )在目标系统中的名称。为数据取名时应注意：(1)同一数据不要使用不同的名称，例如 “汽车牌号”和“牌号”可统称为“牌号” ；(2)在容易识别的前提下尽量简化名称，以方便输入输出操作。在本例中，一律取汉字拼音的首字母作为数据名称，其结果如下：(1)与 4 种账册相关的数据Zl(PH，XH，SCC，CZM，DZ，DH)Z2(GH，XM，XSGZ，CSRQ，JCRQ，DZ ，DH)Z3(BH， PH，GH，XLXM， XLXS，LJH

31、，SL ，XLF，LJF ，ZJ，SXRQ，WGRQ)Z4(LJH，LJM ，CB，JG，KCL，ZDKC ，DHL)(2)与 5 种单据相关的数据Dl(PH，XH，SCC，XLXM，CZM，DZ，DH)D2(BH，PH，GH，XLXM，XLXS，LJH，SL，SXRQ，WGRQ)D3(BH，LJHSL) D4(LJH，LJM，CB ，SL)D5(C2M，DZ，PH，XLXM，XLF，LJF，ZJ，WGRQ)(3)与 3 种报表相关的数据B1(LJM，SL，JG ，LJF，LR)B2(GH，XM，XLXS，XSGZ，YGZ) B3(LJM，DHL，CB，ZJ)（二） 定义数据项的含义与取值将上

32、一步得到的全部数据项综合起来，加上含义与取值，便可得到整个目标系统的数 据项条目，如表 95 所示。不言而喻，这些数据项将构成定义应用系统字段变量和内存变 量的根据。信息系统分析与设计案例集（三） 定义目标系统的数据流系统的输入数据和输出的打印数据，一般可转换为目标系统的输入和输出数据流。就本例而言，D1D5，B1B3 共可定义 8 种数据流，如表 96 所表示。数据字典卡片（略） ，举例如下：3 。概念设计：用 E-R 图描述概念模型（一）确定 E-R 模型应含的实体汽车，修理工，修理单，零件（二）建立对应的单项应用的局部 E-R 图在实体之间建立联系，通常作法，在系统功能分析中首先选出一至

33、数项有代表性（设计实体较多的）单项应用功能，建立局部 R-E。然后在次基础上逐步扩充，直到在所有试题之间建立应有的联系。例：“开设修理发票”：计算修理费涉及到修理工的“小时工资” ，修理单的“修理小时” ，计算零件费涉及到修理单的“零件用量”和零件“价格”发票中的“车主名”和“地址” ，涉及到汽车，信息系统分析与设计案例集（三）将局部 E-R 图综合为系统的总体 E-R 图（四）* 改进总体 E-R 图：最小数据冗余。(1)删去修理单中的 3 个属性“零件费“、 “修理费”和“ 总计” 。这 3 个属性数据均可从其它数据计算得出。通常把这类数据称为“衍生数据”或“可到出数据” ，以区别于不能从

34、推倒得到的“基本数据” 。把他们删去可以减少冗余。（2）将实体“汽车”分解为“汽车”和“车主” ，因为汽车属性集中含有汽车与车主两方面的信息。如果车主送修 N 辆汽车，则关于车主名、地址、电话等会重复存贮 N 次，造成数据冗余。信息系统分析与设计案例集4逻辑设计。将 E-R 模型转换为关系模型，且规范化。（一）每个实体转换为一个关系（二）把每一联系转换为关系联系的情况比较复杂。例如在 E-R 模型中，有的联系不带属性，有的联系可能带一个或者多个属性。在转换成关系时，在关系的属性集中一般应包括(1)联系本身的属性；(2)由它所联系的各个实体的主键。以图 1010 中的三个联系为例，可分别按下述的

35、步骤进行转换：(1)联系名：使用所联系的实体及其主键：修理单(主键为“编号” )零 件(主键为“零件号 ”)零件用量表（编号，零件号，数量）对应的关系因为一张修理单可能使用几种零件，只有编号加上零件号，才能唯一地决定某种零件在修理中使用的数量。所以本例的主键应由两个属性编号与零件号一起组成。这种由几个属性组合起来的主键，通常称为关系的“复合键” 。(2)联系名；属于所联系的实体及其主键：汽车(主键为“牌号”)车主(主键为“车主名” )对应的关系；汽车归属表(车主名，牌号 )一个车主可能仅送修一辆汽车，也可能送修多辆汽车。有了汽车归属表，便可知道哪辆汽车是哪一车主送修的，或某一车主共计送修了哪几

36、辆汽车。由于“属于”本身不带属性，所以对应的关系将仅含两个属性车主名与牌号。它们构成新关系的元组，信息系统分析与设计案例集同时也是新关系的主键。这种由整个元组构成的主键，在有些文献中称为“全键”(AII，KEY)(3)联系名：修理所联系的实体及其主键：修理单(主键为“编号” )汽 车(主键为“牌号” )修理工(主键为“工号” )对应的关系：修理（编号，牌号，工号，修理项目，修理小时，送修日期，完工日期）上述关系式中的后面 4 项，都是“修理”本身的属性。显然，这一关系与前面由实体“修理单”转换得到的关系是重复的，只需要保留一个修理单就可以了。 综上可知，从 5 个实体可导出 5 个关系，3 个

37、联系可导出 3 个关系，去掉重复的一个，关系的总数为7 个。 （三）转换结果的改进 上述的结果仍有改进的余地。一般地说，对于由“联系”建立起来的关系，如果联系本身不带属性，都可以仿照方法处理，即：删除掉联系转换生成的“关系” ，但对于1：M 的联系的两个实体，将处于“1”端的实体的主属性附加到处于“M”端的实体(本例中为汽车)的属性集中，而不是相反。例如：“汽车归属表”来说，它唯一的作用是建立“车主”与“汽车”的联系是1：M，且联系本身没有属性，在删除“汽车归属表” ，有两种方案(a)在关系“汽车”中附加“车主名”b)在关系“车主 ”中附加汽车“牌号”(a) 汽车(牌号，型号，生产厂，车主名)

38、 - 汽车 (牌号，型号，生产厂)(b)车主(车主名，地址，电话) - 车主(车主名，地址，电话，牌号)分析：如图 1012 所示，假设有一位车主大华纺织厂送修了三辆汽车。当“汽车”与“车主”间没有直接联系(即通过“汽车归属表”联系 )时，该车主在“车主”中只占一个元组，在“汽车”中占用 3 个元组。 采用图 l012(b)的方法，则在两个关系中占用的元组数不变，但在“车主”关系中，大华纺织厂的名字将重复 3 次。 采用图 1012(c)的方法，则在两个关系中占用的元组数都将达到三个。后一方案的冗余数据显然较多。造成以上差别的原因，是因为车主与汽车间存在着一对多(1：M) 的联系。一个车主可能

39、送修多辆汽车。把送修汽车的牌号附加到“车主”中，则送修 M 辆汽车的车主，其全部属性就会重复出现 M 次。信息系统分析与设计案例集（四） 转换结果小结根据以上的讨论，汽车修理管理信息系统的关系模式将由下列 6 个关系组成：(1)修理：（工号，姓名，地址，电话，出生日期，进厂日期，小时工资)(2)修理单表(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)(3)汽车(牌号，型号，生产厂，车主名)(4)车主(车主名，地址，电话)(5)零件库存表(零件号，零件名，成本，价格，库存量，最低库存量，订货量)(6)零件用量表(编号，零件号，数量 ) 将上述结果与当前人工系统的四种账册比较(参阅第

40、931 节) ，关系(1)、(5)分别对应于当前系统的修理工名册和库存零件台账，内容也基本相同；当前系统的汽车登记册在新系统中一分为二，变成汽车(3)和车主(4)两个关系，与此相似，汽车修理台账也一分为二，变成修理单表(2)和零件用量表(6)两个关系。这些改变的作用是什么?在理论上是否合理? （五）关系规范化在逻辑设计阶段，需要用规范化理论来指导数据库的设计。如果设计关系模式时都要像上面那样计算冗余，当然太麻烦了。实际上判断一个关系会不会产生冗余，是有规律可循的，这就是下面要讨论的在属性之间存在的“依赖” 。多数的冗余，都是由于在属性之间存在不适当的依赖关系引起的。第一、第二和第三范式 为了建

41、立冗余较小、结构合理的数据库，Codd 把关系应满足的规范划分为若干等级，每级称为一个范式。满足最低的要求称为第一范式(1NF) ， 在 1NF 基础上又满足某些特性叫第二范式(2NF)，在 2NF 基础上再满足一些要求的为 第三范式(3NF)等等。以下是这些范式的定义。信息系统分析与设计案例集完全函数依赖与部分函数依赖 关系中的属性可区分为主属性和非主属性两类。主属性组成关系的主键，它能唯一地识别关系中的一个元组在主属性和非主属性数据之间存在的这种关系，可称为“函数依赖”关系。在非主属性中所有属性完全依赖于主键中的全部主属性，称这种依赖为“完全函数依赖” ，在非主属性中只有部分属性完全依赖于

42、主键中的全部主属性，其余非主属性均仅依赖于主键中的部分主属性。通常称这种依赖为“部分函数依赖” 。属于完全依赖的关系中，在非主属性之间，存在函数依赖关系，说明，牌号通过某隐含的属性(这里是车主名)间接地决定地址与电话的值。规范式定义定义一；如果一个关系 R 的每一属性都是不可再分的，则称 R 为第一范式的，记作RE1NF 定义二：若 RlNF，且它的每一非主属性完全依赖于主键，则 R2NF。定义三：若 R2NF，且它的每一非主属性不传递依赖于主键，则 R3NF。从这些定义可知，2NF 关系可从 1NF 关系消除非主属性对主键的部分依赖后获得， 而 3NF 关系可从 2NF 关系消除非主属性对主

43、键的传递依赖后获得。这一过程也可以表示为下面请看几个例子。信息系统分析与设计案例集例 1 判断下列关系的范式等级：修理单(编号，牌号，工号，修理项目，修理小时，零件号，数量，送修日期，完工日期)分析；(1) 所有属性均为不可分的原子项，(2) 主键为编号和零件号，且存在部分依赖，例如( 编号，零件号)一牌号判断修理单为1NF 。如果把上述关系分解成如下的两个关系修理单(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)零件用量表(编号，零件号，数量 )，就可以消除关系中的部分依赖。又因关系中原来就不存在传递依赖，所以两个新关系都属于 3NF。例 2 判断 10-2 中三个关系的范式等级

44、。方案(1)汽车(牌号，型号，生产厂，车主名，地址，电话)分析：(1)属性均不可再分，(2)主键为单个属性，不可能存在部分依赖：(3)有传递依赖，例如牌号一地址。判断：汽车为 2NF方案(2)：汽车(牌号，型号，生产厂，车主名 )最后结果(1)修理：（工号，姓名，地址，电话，出生日期，进厂日期，小时工资)(2)修理单表(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)(3)汽车(牌号，型号，生产厂，车主名)(4)车主(车主名，地址，电话)(5)零件库存表(零件号，零件名，成本，价格，库存量，最低库存量，订货量)(6)零件用量表(编号，零件号，数量 ) （六）规范化小结 (1)所谓范式

45、，其实就是施加于关系模式的约束条件。要求所有的关系模式至少要满足 1NF，是为了避免“表中套表”给计算机处理增加的麻烦。但由于仅仅满足 1NF的关系可能存在部分依赖或传递依赖，仍可能有较大的冗余，同时给数据处理带来诸多的不便。较高的范式代表了较严的约束，从而能使数据的结构更趋简单，数据间的联系更为清晰，数据的操作更加简便。以例 104 为例，如果有一位送修了多辆汽车的车主因搬家改变了地址与电话，当汽车与车主合用同一个关系( 为 2NF)时，需要同时修改多条记录的内容万一有一处漏改；就破坏了数据的一致性。但若分解为两个独立的关系(均为3NF)，只需在“车主”中修改一个记录就行了。不仅操作方便，出

46、错的机会也少得多。(2)模式分解可用于提高范式的等级。从例 103 到例 105 所举的几个例子，都说明了这个问题。一般地说，随着规范化程度的提高，关系的冗余将相对降低，因插入、删除或修改引起的操作异常也会减少但事情总是一分为二的。分解愈细，查询时花费在关系连接上需要的时间也愈多。权衡利弊，有时会得不偿失。所以在具体应用中，模式分解应该从实际出发，适可而止，不应片面追求提高范式的等级。综上可知，不但要熟悉 ER 模型向关系模式转换的规则，更应该懂得规范化理论和通过模式分解优化设计的方法，才能在实现设计中作到结合实际，灵活运用。5 .物理设计关系数据库的物理设计比较简单。对于一般的微机关系数据库

47、系统来说，在这一阶信息系统分析与设计案例集段的工作内容主要包括；（一）确定所有数据库文件的名称，及其所含字段的名称、类型与宽度（二）确定各数据库文件需要建立的索引，在什么字段上建立索引等。下面仍以汽车修理管理信息系统为例进行说明。第一步：确定所有字段的名称、类型与宽度，见表 10：1。第二步：确定数据库文件的名称及其组成，见表 102。第三步：确定索引文件与索引码。文件妁名称与索引码见表 103。第四步：按选定的语言建立上述的数据库文件及其索引文件。信息系统分析与设计案例集一、教学目的本案例通过描述某汽车修理管理信息系统，说明了数据库设计的基本过程，使学生对于用户需求分析的方法、数据库的设计方法有更深刻的理解。二、讨论参考题1系统的物理设计方案是如何提出的?它包括哪些内容？2结合案例请你谈谈数据库设计的步骤以及具体的方法。三、使用建议本案例可以作为讲授信息系统数据库设计时使用。