案例一 餐厅信息系统的业务流程
一家使用了计算机点菜的连锁餐厅最近在某市开业，生意格外兴隆。客人到餐厅后，
在计算机上进行选菜，计算机就会显示出餐厅所供应的品种，想吃什么莱，在上面轻轻一点，屏幕上就会出现菜的样子、价钱，原材料以及菜中所含蛋白质和各种维生素的含量，供客人根据自己的需求和口味情况选择。顾客选好莱并付款后，计算机自动将选菜结果通知厨房进行配菜。计算机的使用，不仅给顾客提供了方便．而且使餐厅环境改观。
现在我们看看该餐厅的信息系统是怎样工作的。假定餐厅中整个业务流程设计成这
样：所有微机连成一个局域网，在餐厅、厨房、配餐间、收款处、经理室等都有终端。
当顾客来到餐厅时，由服务员携带一台掌上型微机到餐桌前开点菜单，顾客选好后，点菜单的信息被传送到后台的服务器上，在该过程中系统会自动分类，根据顾客点的菜的品种，直接将信息送到制作它的厨师那里。例如顾客点的凉菜订单会被送到凉菜配餐间的计算机上；酒水饮料会被送到饮料室的计算机上：如果是炒菜就送到厨房的计算机上。如果某菜原材料用完，厨师可以在厨房中通过计算机立即送入信息，从而服务员在顾客订菜时，马上就可以通知他某菜的缺货情况。顾客输入信息后，马上就可看到他订的莱的总价格。通过餐厅的打印机也可以很快得到账单，上面列出所有顾客点的莱名和计算的结果。系统也对经理提供信息。例如能提供关于各种原料的价格和采购量，系统能对销售额和各种菜的成本进行比较，从而可以进行成本控制。经理也可以看到一定时期内每一道菜的销售情况，算出它们在总销售额中所占的比例。经理可以根据这些信息来调整菜谱。
一、教学目的
本案例通过描述某餐厅信息系统的工作流程，说明了信息在业务过程中流动的特
点，理解业务流程的含义，体会优化的信息系统业务流成为组织带来的效益。
二、讨论参考题
1. 该餐厅存在哪些业务，用系统的观点画出业务流程示意图。
2. 该餐厅有哪些信息? 它们是如何与以上业务相关联的?
3. 该餐厅的信息是如何发生，又是如何被加工、转换和被传递的?
三、使用建议
本案例可以作为讲授信息的流动与转换时使用，也可以作为讲授管理业务调查时
使用。
案例二 伦敦路透社信息产品的市场显示系统
伦敦路透社70%的收入来源于出售他们国际新闻以及金融信息等基于信息产品。
这些产品是通过它的市场显示系统向用户展示的。为改进市场显示系统的可用性，使其能更容易、更方便地满足顾客的要求，路透社让加里森支负责一个最高优先权的项目，任务是改进显示系统的用户界面。为此，加里森去组建了“可用性小组”。这实际上是一个“虚拟小组”，除包括加里森及三名路透社成员之外，还包括一些有关的技术公司，如交互图形公司、微软公司的代表。该组还与500多名专家保持联系，其中一位是“符号学专家”，专门负责把计算机的动作翻译成像Windows 的图标那样的一些符号。该小组并不通过市场调查，去问顾客想要一些什么，而是在他们建立的“可用性实验室”中观察客户们怎样利用路透社的显示系统查找他们想要的信息产品。
可用性实验室有两个房间，一个给用户们用。用户在路透社助理人员的伴随下完成一
系列就应用系统的实验。另一间房间被玻璃隔成一些小间，各放有一台显示器，显示内容与用户屏幕上的内容相同并用可视信号或者是内部通信系统与用户保持联系实验时，要求客户完成一系列的操作。例如，可以要求用户去查询某支股票的价格，画出它在一定期间内走势图，找出一些相关的消息和公司的财务数据。随着用户的操作，可用性小组的人员就在监视器上观察用户在什么地方发生问题，测试出完成每项操作的时间，留意引起用户工作中断的过程。用户操作过程还被录像，从录像带上能够更精确地测量所用的时间。该实验室每个月能完成100个用户的三项至四项主要测试。 实验室还要去了解路透社服务机构接听的用户求助电话，将用户求助问题分为四类，录入数据库并进行统计分析，找出用户遇到的主要问题并设法改进。例如，1994年4月有34%的电话是有关RT 工作站反映出的可用性问题的，进一步分析表明28%的电话是关于报价单问题的，于是路透社就将报价单在工作站上的显示形式进行了改进。
可用性小组最后制订了一系列规范，要求所有路透社开发小组开发的软件产品都要经
过可用性小组的审查，相同的功能要用相同的图标，图标也必须在可用性小组开发的一系列标准图标集中选用。这些图标，开发小组可以在网络上得到。
一、教学目的
通过伦敦路透社信息产品的市场显示系统的改进过程的描述，使学生理解原型法
等系统开发的方法，以及开发过程中对用户需求进行分析的重要性。
二、参考讨论题
1. 可用性实验室为路透社解决了什么问题？
2. 说明上述系统采用了什么开发方法？说明该方法的基本思想和基本步骤？
3. 这种开发方法适合于解决哪一类问题？
4. 常用的信息系统开发方法有哪些？这些方法分别具有哪些优缺点？分别适用于那
些场合？
三、使用建议
本案例适用于讲授信息系统开发方法的时使用。
案例三 A 公司信息化建设的问题出在那里？
A 企业属于制造型企业，不仅生产自有产品，而且承接其他企业的外协件生产。几年前，已相继建立起MPRII 系统，产品设计部使用CAD 、CAPP 、与PDM 系统，极大的提高的工作效率和质量。
A 企业最高决策者是张总裁。B 企业是A 企业强有力的竞争对手。
关于A 公司信息化建设状况的描述：
日历上写的是星期四，但对于张总裁，这天更象是另一个星期一。每天看起来都象是
星期一。因为，从每个星期一的市场情报资料上，张总裁了解到B 公司逐步在销售上超过了他们，B 公司已经变得更加的盈利，张总裁感到竞争的紧迫感和焦虑，这种紧迫感和焦虑不仅来自外部，而且公司内部也存在很大问题。不管他说什么做什么，他的公司仍在不停的出现各种各样的错误。大到付出昂贵代价，小到让人讨厌，还有一切不大又不小的错误，它们正在缓慢地，但又非常有效的扼杀制约着公司的发展，错误不是由别有用心的人故意制造出来损害公司的，那么问题出在哪了？
就在上个月，他们最重要的一个客户对产品规格的要求发生了变动，但是最后满足变
动需求的产品没有及时送发货部门，使得货物的集中、装箱、上船的一系列行动无法按时进行，于是他们把另一个不太重要的客户预定的产品用飞机送到该重要客户处，尽管这样，还是比预定的到货期迟了。（当然那个不太重要的客户也没有按时收到预定的产品）。尽管他们做了种种的努力（甚至船运改为航运），但这个重要的客户并没有感谢他们，只是对
A 公司的销售人员说：他们不能再容忍这种错误了。
一个顾客开始越来越延迟的付款，信用部门经理决定先押下他的所有订单。尽管信用
部经理已经告诉了发货部领班扣押下那个顾客的所有订单，不幸的是，当时这个领班正在休两星期的假，发货部发货员将该客户的订单集中、检验、并发给顾客。一周后这个拖欠付款的顾客宣布破产了。但当张总裁对着发货人发火的时候。发货部领班反驳说：仅仅一周前，你告诉过我们要确保货物按时发出，我正是照你说的做。自从那次激烈的讨论后，发货部门总被一种愤怒、委屈的沉寂包围着。销售人员完成了他们的销售计划，但公司的利润还在持续下滑。
面对市场竞争环境，下游客户从自身业务出发对供应链上游成员，提出了新的要求，
他们需要建立更紧密的联系，以节约投产准备阶段时间和费用。例如，下游客户希望供应伙伴——A 公司的工程师，能参与他们的设计过程中，利用电子手段，实现双方采购信息系统和销售信息系统的信息对接、实时交换和查询产品设计的相关技术文件。他们希望接到自己的订单时，只需“按一下鼠标按键”就可把订单实施计划直接变成原材料计划，通过跨组织的网络系统传递和纳入A 公司的生产制造系统和托运计划。但是A 公司无法满足上述要求，导致下游客户的原材料短缺，A 公司也经常运载体积不够而大伤脑筋。就在两周前，为了按期交货，A 公司刚刚航空托运了一批货给一个客户。这件事源于船运时遇到的运载空间问题。更早一周，是由一个A 公司的主要供应商引起的，再早两周前，„„总是有各种各样的原因造成了一次又一次的损失。
A 公司现在使用的MRPII 系统，假设前提是供应商都能够按照约定无条件供货，而
且不得更改。实际操作时，往往存在供应商有条件改动的可能。即使供应商做到无条件供货，A 公司的管理者们也没有足够的时间和能力来应付大量的改变的约定，他们也没有合适的信息处理系统来支持他们调整生产计划。
三个月以前，张总裁和他的所有管理层职员一起用两天时间召开了的关于企业销售策
略实施计划的决策会议，这个会议开的非常成功，至少他们是这样说的。但是这些实施计
划并没有被贯彻到日常的决策和销售运做中。这种现象早年也发生过。因为，张总裁不肯定管理人员做出的那些决策是最佳的，他感到那些高层职员，包括他自己都不能获得较全面的市场与营销方面的细节层次数据的支持。例如：他的销售人员每隔一段时间就会发现有一个减价销售大量商品的机会，A 公司应该接受这个价格吗？
原材料采购部经理正试图说服A 公司实施他们制定的关于“减少计划”，即减少投产
准备时间，减少存货。这听起来似乎是有前途的，但积压的存货并不能如他们所愿地减少，况且，经理还需要对操作工作中决策过程与规则做必要的改变。
A 公司承接其它制造企业的定制产品订单任务时，销售人员必须不停的向A 公司办公
室汇报很多各种各样的产品报价单，因为那些专业的规格资料实在是多的数不胜数。客户们反映B 公司（A 公司的竞争对手）的销售员就可以把报价单放在客户的办公室上，并且邀请客户上网联接到他们的主机，实现在线实时的报价和订单合同洽谈。
A 公司的售后服务是相对独立的一套业务系统，通过公司计算机网络系统，售后服务
人员可以使用常用的自行研制的软件工具，从数据库中直接调用资料，获取关于产品数据及技术资料，服务维修咨询和指导。当他们更换了一个由A 公司的供应商处得到的配件时，他们也试图从供应商那里得到支持。但是，不论是售后服务系统，还是MRP Ⅱ系统都没有记录和保存这些信息，而且，当外出服务工程师在外面修理一台机器时，售后服务系统并不能给出该客户的一张完整清晰的合同订单，无法清楚提供哪些更换部分是客户质量保证书或服务协议涵盖的，哪些不是。
对于A 公司的工程设计部门负责产品开发设计，产品数据管理系统（PDM ）和MRP Ⅱ系统用的都是一样的重要信息系统，但它们不是集成的，所以工程师必须把PDM 系统的产品数据的变化人工输到MRP Ⅱ系统中，以保证它们同步性、数据的一致性。产品的设计过程，从产品概念构思到产品上市，需要大约９－１２个月的时间。
市场部本来应能提供关于新产品开发的创意思想，尽管他们基本没有能力也不必要按
工程设计规范要求进行描述。但当设计工程师开始设计新产品时，市场部门却不能直接十分清楚表述市场、客户真正需要的具体细节数据和信息。所以工程师只是在那些已掌握的数据信息基础上尽量发挥。
A 公司相当大的一部分不断增长的商业机会，需要更多资深工程师的努力，而不是
简单体力劳动力，公司的优良业绩必须体现在财务利润报表上，但A 公司已经连续三年利润滑坡了，因此它不得不解雇了一大批工程师，其它的一些工程师也纷纷跳槽，使得A 公司失去了更多的有丰厚的利润的商业机会，这远比节省的劳动力费用高的多。
总而言之，A 公司和许多其它制造公司一样，高层决策者们必须在低效率、缺少活力
的公司和高效率、充满活力的公司之间最出果断的战略决策和信息系统的规划。
一、 教学目的
通过运用系统规划理论和方法的学习，结合对此案例的分析，帮助学生理解信息化建
设对企业经营发展和竞争能力的重要作用，提高对企业信息管理需求分析的能力，培养设计企业信息系统的目标与建设方案的能力。
二、讨论参考题
1. 分析整理A 企业的管理业务流程中存在的问题？
2. 分析整理A 企业对信息系统的需求？
3. 你对A 企业目前如何有效地进行信息系统的选择有什么建议？
4.A 企业的信息系统建设正处于那个阶段？
5. 谈谈你们对A 企业信息系统规划的设想?
三、使用建议
本案例可用于本科生开设的“管理信息系统”课程，“信息系统分析与设计”课程，
“信息系统的战略规划”教学专题。
四、案例需要的背景知识
计算机基础知识，企业生产运作与管理知识，信息系统规划、分析与设计知识，数据库原理及应用知识，企业经营战略与管理知识、企业资源计划知识等。
案例四 对某企业的信息系统的初步调查
（1）企业背景：
该企业于1983年开展计算机辅助管理工作，在硬件设备配置、软件开发、技术队伍
方面已初具规模，对企业的发展起了积极的推动作用。到了1999年达到顶峰，年产值1个多亿，利润率为20%。
但是，随着企业从单纯生产型向生产经营型转变，由原来只生产空调压缩机的零件到
现在的整机生产，生产过程日趋复杂，企业管理水平落后的矛盾日益尖锐，具体表现在长期采用的传统手工业或微机加手工管理方式无法满足经营中多层次、多品种、多批量生产计划的管理，也满足不了任何一种产品生产全过程的动态信息管理。各部门间信息沟通不畅造成信息大量冗余和差异，决策者得不到他所想要的准确信息，加之，原材料的不断涨价，市场需求减少等原因，使产品成本连年上升，由于压缩机需求关系趋向饱和，使得市场价格又不断下降，企业利润大幅度下滑。从2000年开始，企业领导为了有效地降低成本，提出划小核算单位、分级核算的方案，用信息系统完成企业的各级核算工作，对成本进行定量化的分析，其目标是完成全企业的各级核算工作，有效地控制成本。
（2）该企业现行的系统主要用于人事管理、财务管理、计划、统计、计件、工资管
理等，没有把已建立的系统与相关的数据结合起来，完成成本核算。经过对企业目前的经济状况及技术力量的调查分析，认为比较容易把这些彼此分散开发的软件系统化、标准化，把相关的数据结合起来，开发一个使得企业的决策经营以市场为核心，以成本为依据，以利润为目的的成本核算管理信息系统。
（3）企业成本核算系统的目标、结构及功能：
①系统目标。首先，建立一个能覆盖从原材料进厂到产品出厂，物料全过程的成本核
算系统。该系统集成了车间成本核算、材料核算、动力核算、销售核算、资产核算等子系统；通过各个子系统的运行，信息共享，数据互相传递，完成整个企业的成本核算工作，有效地控制成本，提高利润率。
②系统结构及功能。从对企业的现状提出问题到确定目标，经过组织机构调查、确定
系统边界，分析业务流程及功能分析等步骤，需要确定的系统结构如下图所示，图中表明了成本核算系统的各子系统要完成的基本功能。
（4）计算机逻辑配置方案。总体规划的后期，要考虑计算机逻辑配置方案，这是从系统需求的角度提出对计算机配置的基本要求，而不涉及其具体硬件型号。计算机逻辑配置方案设计从以下几个方面考虑：
①客观条件约束。包括资金、现有计算机系统、技术力量（开发和维护）。
②网络布局。按照系统的要求制定网络布局方案。
③硬件系统。包括计算机的存储量、运算速度、外部设备的功能、效率、可靠性、通行设备的能力等。
④软件系统。包括操作系统、数据库管理系统、网络软件、程序设计语言等。
一、教学目的
通过对某企业的管理背景的初步调查，说明初步拟定信息系统目标、初步构建信息系统的框架的过程。
二、讨论参考题
1． 分析该企业成本管理存在的问题？
2． 分析该企业对信息系统的需求状况？
3． 你对该企业成本核算系统的目标的拟定、结构及功能的构建有何建议和设想？
三、使用建议：
本案例可在讲授系统规划阶段进行初步调查拟定系统目标、设想系统功能时使用。
案例五 一个某零部件生产厂的销售系统
一个某零部件生产厂的销售系统。该厂的产品是各种不同类型的零部件，其加工周期为10天左右。工厂的生产逐渐转向以销定产。工厂设有销售科，销售科的工作除推销产品外，还进行接受合同、处理合同(、向计划科提出生产要求并如期执行合同的信息加工工作) ，另外还要管理一个成品库。我们要开发一个用于销售管理的信息系统，它可以是整个企业管理信息系统的一个子系统，也可以是一个独立的信息系统。现行销售系统的详细业务如下：
接受合同:
● 用户(即顾客通过各种方式向厂方订货，当收到用户订单后，
● 首先对每份订单粗略地检查，看是否合理. 例如填写是否正确，订货货名是否属于本
厂产品等。
●
超出预定计划30%之内，则同意此项订货，还要将此订货合同送到科内会计那里，会计审查订货单位的信用情况，
如该顾客无欠款或是新顾客则会计签字表示同意接收，送至科长，科长审核上述几方面情况后正式接受此
● 将合同情况向生产计划科作，以便安排生产，同时向订货单位发出付款通知，
也通知财务科准备
收款。
处理合同:由于顾客既不希望厂方拖延交货日期以致延误生产又不希望过早收货以致材料堆积而造成浪费。
●
● 如果发现没有库存，及时通知计划科，赶紧补生产，由于本厂产品周期较短，所以可
以在下次查找时再次处理该合同。
●
● 如已付款则作发货单，一份交发货员，将货发出，一份随货寄至
顾客。并在订货合同
文件上注销。
管理成品库:该科还有一个成品库，它的管理也在该信息系统中，
● 当接收发货单
● 当成品车间送来成品
该销售信息系统的数据流程图：
一、教学目的
本案例通过描述一个某零部件生产厂的销售系统，说明了系统分析阶段针对业务流程和数据流程进行调查分析的描述表达方法，有助于学生掌握业务流程的描述方法和数据流程图的绘制方法。 二、讨论参考题
1．分析该系统的业务流程和数据流程有那些需要改进的地方？
2．结合案例请你谈谈绘制数据流程图时的基本思路以及应注意的事项？ 三、使用建议
本案例可以作为讲授信息系统的系统分析阶段详细调查工作时使用，也可作为绘制数据流程图的示例。
汽车修理管理信息系统
某汽车修理厂根据业务发展的需要，决定建立一个以数据库为基础的管理信息系统，以代替单一的人工管理。目标系统取名为“汽车修理管理信息系统”(QCXL—M 工S) 。通过用户调查，初步整理出以下的结果：
1．系统的数据需求分析
调查获悉，该厂在业务管理上共使用5种单据，4种帐册和3种主要报表。现分述如下：
(1) 5种单据
业务流程： D1由送修人填写。修理派工员据此开出修理单D2，分派给指定的修理工执行。如果在修理中更换零件，一律由修理工填写零件领用单D3向仓库领用。修理结束后，修理工将D2交回派工员，然后转财务部门结帐并开修车发票D5。D4在零件入库时由仓库管理员验收并且填写。图9。4—9．8显示了这些单据的格式与内容。
除上述3种报表外，该厂还使用若干种统计表，供有关部门作分析或预测之用。例如在半年一次的统计，“平均修理周期分月统计表”(含月份和平均修理天数两项) 、“修理次数分型统计表“（含汽车型号、修理次数二项) 、“修理次数分类统计表”(含修理项目、修理项数二项) 等多种，为了简化所讨论的问题，这里就不细述了。 对目标系统的功能需求
通过对当前系统的调查和与用户的共同讨论，对将要开发的目标系统提出了如下的总体需求； (1)用数据文件代替现用的全部帐册；
(2)具有对各种数据文件装入和修改数据的功能；
(3)能计算修车费用和开发票。其中修车费按下列各式计算： 零件费＝Σ零件价格*耗用数量 修理费＝小时工资*修理工时* 3 总 计＝零件费+修理费
(4)能找出需要订货的零件，编制并打印零件订货计划。 订货条件：零件库存量
(5)按现行格式和内容编制和打印零件耗用月报表和修理工资月报表； (6)有多种查询和统计功能。为了简化讨论，具体需求就从略了。
2．数据分析（ DFD 和数据字典）
这是数据库系统开发中十分重要的一项活动。其首要任务，是确定目标系统中使用的 全部数据，为它们取名和定义。在传统的软件工程方法中，数据常区分为数据文件、数据流 (组合数据) 和数据项(单个数据) 三大类。分析中要为每一数据编写一个数据条目，然后将 所有条目合编为数据字典。这样，在随后进行的系统设计中不论有多少人参加，
大家都可 以数据字典为统一的根据．不必担心因数据不一致而导致矛盾和混乱了。
（一）．确定各个单项数据(不含数据文件和数据流) 在目标系统中的名称。
为数据取名时应注意：(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 ，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，LJH ．SL)
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) （二）．定义数据项的含义与取值
将上一步得到的全部数据项综合起来，加上含义与取值，便可得到整个目标系统的数 据项条目，如表9．5所示。不言而喻，这些数据项将构成定义应用系统字段变量和内存变 量的根据。
（三）．定义目标系统的数据流
系统的输入数据和输出的打印数据，一般可转换为目标系统的输入和输出数据流。
就
本例而言，D1～D5，B1～B3共可定义8种数据流，如表9．6所表示。 数据字典卡片（略），举例如下：
3 。概念设计：用E-R 图描述概念模型
（一）确定E-R 模型应含的实体
汽车，修理工，修理单，零件
（二）建立对应的单项应用的局部E-R 图
在实体之间建立联系，通常作法，在系统功能分析中首先选出一至数项有代表性（设计实体较多的）单项应用功能，建立局部R-E 。然后在次基础上逐步扩充，直到在所有试题之间建立应有的联系。
例：“开设修理发票”：
计算修理费涉及到修理工的“小时工资”，修理单的“修理小时”， 计算零件费涉及到修理单的“零件用量”和零件“价格” 发票中的“车主名”和“地址”，涉及到汽车，
（三）将局部E-R 图综合为系统的总体E-R 图
（四）* 改进总体E-R 图：最小数据冗余。
(1)删去修理单中的3个属性“零件费“、“修理费”和“总计”。这3个属性
数据均可从其它数据计算得出。通常把这类数据称为“衍生数据”或“可到出数据”，以区别于不能从推倒得到的“基本数据”。把他们删去可以减少冗余。 （2）将实体“汽车”分解为“汽车”和“车主”，因为汽车属性集中含有汽车与车主两方面的信息。如果车主送修N 辆汽车，则关于车主名、地址、电话等会重复存贮N 次，造成数据冗余。
4．逻辑设计。将E-R 模型转换为关系模型，且规范化。
（一）每个实体转换为一个关系 （二）把每一联系转换为关系
联系的情况比较复杂。例如在E-R 模型中，有的联系不带属性，有的联系可能带一个或者多个属性。在转换成关系时，在关系的属性集中一般应包括(1)联系本身的属性；(2)由它所联系的各个实体的主键。以图10．10中的三个联系为例，可分别按下述的步骤进行转换：
(1)联系名：使用—所联系的实体及其主键： 修理单(主键为“编号”) 零 件(主键为“零件号”)
零件用量表（编号，零件号，数量）
对应的关系因为一张修理单可能使用几种零件，只有编号加上零件号，才能唯一地决定某种零件在修理中使用的数量。所以本例的主键应由两个属性——编号与零件号一起组成。这种由几个属性组合起来的主键，通常称为关系的“复合键”。
(2)联系名；属于所联系的实体及其主键： 汽车(主键为“牌号”) 车主(主键为“车主名”) 对应的关系；
汽车归属表(车主名，牌号)
一个车主可能仅送修一辆汽车，也可能送修多辆汽车。有了汽车归属表，便可知道哪辆汽车是哪一车主送修的，或某一车主共计送修了哪几辆汽车。由于“属于”本身不带属性，所以对应的关系将仅含两个属性——车主名与牌号。它们构成新关系的元组，同时也
是新关系的主键。这种由整个元组构成的主键，在有些文献中称为“全键”(AII，KEY)
(3)联系名：修理所联系的实体及其主键：
修理单(主键为“编号”)
汽 车(主键为“牌号”)
修理工(主键为“工号”)
对应的关系：
修理（编号，牌号，工号，修理项目，修理小时，送修日期，完工日期）
上述关系式中的后面4项，都是“修理”本身的属性。显然，这一关系与前面由实体“修理单”转换得到的关系是重复的，只需要保留一个修理单就可以了。
综上可知，从5个实体可导出5个关系，3个联系可导出3个关系，去掉重复的一个，关系的总数为＝7个。
（三）转换结果的改进
上述的结果仍有改进的余地。一般地说，对于由“联系”建立起来的关系，如果联系本身不带属性，都可以仿照方法处理，即：删除掉联系转换生成的“关系”，但对于1：M 的联系的两个实体，将处于“1”端的实体的主属性附加到处于“M ”端的实体(本例中为汽车) 的属性集中，而不是相反。
例如：“汽车归属表”来说，它唯一的作用是建立“车主”与“汽车”的联系是1：M ，且联系本身没有属性，在删除“汽车归属表”，有两种方案(a)在关系“汽车”中附加“车主名”b) 在关系“车主”中附加汽车“牌号”
(a) 汽车(牌号，型号，生产厂，车主名) ----- 汽车(牌号，型号，生产厂)
(b)车主(车主名，地址，电话) ------ 车主(车主名，地址，电话，牌号)
分析：如图10．12所示，假设有一位车主——大华纺织厂送修了三辆汽车。当“汽车”与“车主”间没有直接联系(即通过“汽车归属表”联系) 时，该车主在“车主”中只占一个元组，在“汽车”中占用3个元组。
● 采用图l012(b)的方法，则在两个关系中占用的元组数不变，但在“车主”关系中，
大华纺织厂的名字将重复3次。
● 采用图10．12(c)的方法，则在两个关系中占用的元组数都将达到三个。后一方
案的冗余数据显然较多。
造成以上差别的原因，是因为车主与汽车间存在着一对多(1：M) 的联系。一个车主可能送修多辆汽车。把送修汽车的牌号附加到“车主”中，则送修M 辆汽车的车主，其全部属性就会重复出现M 次。
（四）．转换结果小结
根据以上的讨论，汽车修理管理信息系统的关系模式将由下列6个关系组成：
(1)修理：（工号，姓名，地址，电话，出生日期，进厂日期，小时工资)
(2)修理单表(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)
(3)汽车(牌号，型号，生产厂，车主名)
(4)车主(车主名，地址，电话)
(5)零件库存表(零件号，零件名，成本，价格，库存量，最低库存量，订货量)
(6)零件用量表(编号，零件号，数量)
将上述结果与当前人工系统的四种账册比较(参阅第9．3．1节) ，关系(1)、(5)分别对应于当前系统的修理工名册和库存零件台账，内容也基本相同；当前系统的汽车登记册在新系统中一分为二，变成汽车(3)和车主(4)两个关系，与此相似，汽车修理台账也一分为二，变成修理单表(2)和零件用量表(6)两个关系。这些改变的作用是什么? 在理论上是否合理?
（五）关系规范化
在逻辑设计阶段，需要用规范化理论来指导数据库的设计。如果设计关系模式时都要像上面那样计算冗余，当然太麻烦了。实际上判断一个关系会不会产生冗余，是有规律可循的，这就是下面要讨论的在属性之间存在的“依赖”。多数的冗余，都是由于在属性之间存在不适当的依赖关系引起的。
第一、第二和第三范式 为了建立冗余较小、结构合理的数据库，Codd 把关系应满足的规范划分为若干等级，每级称为一个范式。满足最低的要求称为第一范式(1NF)， 在1NF 基础上又满足某些特性叫第二范式(2NF)，在2NF 基础上再满足一些要求的为 第三范式(3NF)等等。以下是这些范式的定义。
完全函数依赖与部分函数依赖
关系中的属性可区分为主属性和非主属性两类。主属性组成关系的主键，它能唯一地识别关系中的一个元组．在主属性和非主属性数据之间存在的这种关系，可称为“函数依赖”关系。
在非主属性中所有属性完全依赖于主键中的全部主属性，称这种依赖为“完全函数依赖”，在非主属性中只有部分属性完全依赖于主键中的全部主属性，其余非主属性均仅依赖于主键中的部分主属性。通常称这种依赖为“部分函数依赖” 。
属于完全依赖的关系中，在非主属性之间，存在函数依赖关系，说明，牌号通过某隐含的属性(这里是车主名) 间接地决定地址与电话的值。
规范式定义
定义一；如果一个关系R 的每一属性都是不可再分的，则称R 为第一范式的，记作R
∈E1NF ．
定义二：若R ∈lNF ，且它的每一非主属性完全依赖于主键，则R ∈2NF 。
定义三：若R ∈2NF ，且它的每一非主属性不传递依赖于主键，则R ∈3NF 。 从这些定义可知，2NF 关系可从1NF 关系消除非主属性对主键的部分依赖后获得， 而3NF 关系可从2NF 关系消除非主属性对主键的传递依赖后获得。这一过程也可以表示为
下面请看几个例子。
[例1] 判断下列关系的范式等级：
修理单(编号，牌号，工号，修理项目，修理小时，零件号，数量，送修日期，完工日期) 分析；
(1) 所有属性均为不可分的原子项，
(2) 主键为编号和零件号，且存在部分依赖，例如(编号，零件号) 一》牌号判断修理单为
1NF 。
如果把上述关系分解成如下的两个关系
修理单(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)
零件用量表(编号，零件号，数量) ，
就可以消除关系中的部分依赖。又因关系中原来就不存在传递依赖，所以两个新关系都属于3NF 。
[例2] 判断10-2中三个关系的范式等级。
方案(1)汽车(牌号，型号，生产厂，车主名，地址，电话)
分析：(1)属性均不可再分，
(2)主键为单个属性，不可能存在部分依赖：
(3)有传递依赖，例如牌号一》地址。
判断：汽车为2NF
方案(2)：汽车(牌号，型号，生产厂，车主名)
最后结果
(1)修理：（工号，姓名，地址，电话，出生日期，进厂日期，小时工资)
(2)修理单表(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)
(3)汽车(牌号，型号，生产厂，车主名)
(4)车主(车主名，地址，电话)
(5)零件库存表(零件号，零件名，成本，价格，库存量，最低库存量，订货量)
(6)零件用量表(编号，零件号，数量)
（六）规范化小结
(1)所谓范式，其实就是施加于关系模式的约束条件。要求所有的关系模式至少要满足1NF ，是为了避免“表中套表”给计算机处理增加的麻烦。但由于仅仅满足1NF 的关系可能存在部分依赖或传递依赖，仍可能有较大的冗余，同时给数据处理带来诸多的不便。较高的范式代表了较严的约束，从而能使数据的结构更趋简单，数据间的联系更为清晰，数据的操作更加简便。以例10—4为例，如果有一位送修了多辆汽车的车主因搬家改变了地址与电话，当汽车与车主合用同一个关系(为2NF) 时，需要同时修改多条记录的内容万一有一处漏改；就破坏了数据的一致性。但若分解为两个独立的关系(均为3NF) ，只需在“车主”中修改一个记录就行了。不仅操作方便，出错的机会也少得多。
(2)模式分解可用于提高范式的等级。从例10—3到例10—5所举的几个例子，都说明了这个问题。一般地说，随着规范化程度的提高，关系的冗余将相对降低，因插入、删除或修改引起的操作异常也会减少．但事情总是一分为二的。分解愈细，查询时花费在关系连接上需要的时间也愈多。权衡利弊，有时会得不偿失。所以在具体应用中，模式分解应该从实际出发，适可而止，不应片面追求提高范式的等级。
综上可知，不但要熟悉E —R 模型向关系模式转换的规则，更应该懂得规范化理论和通过模式分解优化设计的方法，才能在实现设计中作到结合实际，灵活运用。
5 .物理设计
关系数据库的物理设计比较简单。对于一般的微机关系数据库系统来说，在这一阶段的工作内容主要包括；
（一）确定所有数据库文件的名称，及其所含字段的名称、类型与宽度
（二）确定各数据库文件需要建立的索引，在什么字段上建立索引等。
下面仍以汽车修理管理信息系统为例进行说明。
第一步：确定所有字段的名称、类型与宽度，见表10：1。
第二步：确定数据库文件的名称及其组成，见表10．2。
第三步：确定索引文件与索引码。文件妁名称与索引码见表 10．3。
第四步：按选定的语言建立上述的数据库文件及其索引文件。
信息系统分析与设计案例集
一、教学目的
本案例通过描述某汽车修理管理信息系统，说明了数据库设计的基本过程，使学生对于用户需求分析的方法、数据库的设计方法有更深刻的理解。
二、讨论参考题
1．系统的物理设计方案是如何提出的? 它包括哪些内容？
2．结合案例请你谈谈数据库设计的步骤以及具体的方法。
三、使用建议
本案例可以作为讲授信息系统数据库设计时使用。
案例一 餐厅信息系统的业务流程
一家使用了计算机点菜的连锁餐厅最近在某市开业，生意格外兴隆。客人到餐厅后，
在计算机上进行选菜，计算机就会显示出餐厅所供应的品种，想吃什么莱，在上面轻轻一点，屏幕上就会出现菜的样子、价钱，原材料以及菜中所含蛋白质和各种维生素的含量，供客人根据自己的需求和口味情况选择。顾客选好莱并付款后，计算机自动将选菜结果通知厨房进行配菜。计算机的使用，不仅给顾客提供了方便．而且使餐厅环境改观。
现在我们看看该餐厅的信息系统是怎样工作的。假定餐厅中整个业务流程设计成这
样：所有微机连成一个局域网，在餐厅、厨房、配餐间、收款处、经理室等都有终端。
当顾客来到餐厅时，由服务员携带一台掌上型微机到餐桌前开点菜单，顾客选好后，点菜单的信息被传送到后台的服务器上，在该过程中系统会自动分类，根据顾客点的菜的品种，直接将信息送到制作它的厨师那里。例如顾客点的凉菜订单会被送到凉菜配餐间的计算机上；酒水饮料会被送到饮料室的计算机上：如果是炒菜就送到厨房的计算机上。如果某菜原材料用完，厨师可以在厨房中通过计算机立即送入信息，从而服务员在顾客订菜时，马上就可以通知他某菜的缺货情况。顾客输入信息后，马上就可看到他订的莱的总价格。通过餐厅的打印机也可以很快得到账单，上面列出所有顾客点的莱名和计算的结果。系统也对经理提供信息。例如能提供关于各种原料的价格和采购量，系统能对销售额和各种菜的成本进行比较，从而可以进行成本控制。经理也可以看到一定时期内每一道菜的销售情况，算出它们在总销售额中所占的比例。经理可以根据这些信息来调整菜谱。
一、教学目的
本案例通过描述某餐厅信息系统的工作流程，说明了信息在业务过程中流动的特
点，理解业务流程的含义，体会优化的信息系统业务流成为组织带来的效益。
二、讨论参考题
1. 该餐厅存在哪些业务，用系统的观点画出业务流程示意图。
2. 该餐厅有哪些信息? 它们是如何与以上业务相关联的?
3. 该餐厅的信息是如何发生，又是如何被加工、转换和被传递的?
三、使用建议
本案例可以作为讲授信息的流动与转换时使用，也可以作为讲授管理业务调查时
使用。
案例二 伦敦路透社信息产品的市场显示系统
伦敦路透社70%的收入来源于出售他们国际新闻以及金融信息等基于信息产品。
这些产品是通过它的市场显示系统向用户展示的。为改进市场显示系统的可用性，使其能更容易、更方便地满足顾客的要求，路透社让加里森支负责一个最高优先权的项目，任务是改进显示系统的用户界面。为此，加里森去组建了“可用性小组”。这实际上是一个“虚拟小组”，除包括加里森及三名路透社成员之外，还包括一些有关的技术公司，如交互图形公司、微软公司的代表。该组还与500多名专家保持联系，其中一位是“符号学专家”，专门负责把计算机的动作翻译成像Windows 的图标那样的一些符号。该小组并不通过市场调查，去问顾客想要一些什么，而是在他们建立的“可用性实验室”中观察客户们怎样利用路透社的显示系统查找他们想要的信息产品。
可用性实验室有两个房间，一个给用户们用。用户在路透社助理人员的伴随下完成一
系列就应用系统的实验。另一间房间被玻璃隔成一些小间，各放有一台显示器，显示内容与用户屏幕上的内容相同并用可视信号或者是内部通信系统与用户保持联系实验时，要求客户完成一系列的操作。例如，可以要求用户去查询某支股票的价格，画出它在一定期间内走势图，找出一些相关的消息和公司的财务数据。随着用户的操作，可用性小组的人员就在监视器上观察用户在什么地方发生问题，测试出完成每项操作的时间，留意引起用户工作中断的过程。用户操作过程还被录像，从录像带上能够更精确地测量所用的时间。该实验室每个月能完成100个用户的三项至四项主要测试。 实验室还要去了解路透社服务机构接听的用户求助电话，将用户求助问题分为四类，录入数据库并进行统计分析，找出用户遇到的主要问题并设法改进。例如，1994年4月有34%的电话是有关RT 工作站反映出的可用性问题的，进一步分析表明28%的电话是关于报价单问题的，于是路透社就将报价单在工作站上的显示形式进行了改进。
可用性小组最后制订了一系列规范，要求所有路透社开发小组开发的软件产品都要经
过可用性小组的审查，相同的功能要用相同的图标，图标也必须在可用性小组开发的一系列标准图标集中选用。这些图标，开发小组可以在网络上得到。
一、教学目的
通过伦敦路透社信息产品的市场显示系统的改进过程的描述，使学生理解原型法
等系统开发的方法，以及开发过程中对用户需求进行分析的重要性。
二、参考讨论题
1. 可用性实验室为路透社解决了什么问题？
2. 说明上述系统采用了什么开发方法？说明该方法的基本思想和基本步骤？
3. 这种开发方法适合于解决哪一类问题？
4. 常用的信息系统开发方法有哪些？这些方法分别具有哪些优缺点？分别适用于那
些场合？
三、使用建议
本案例适用于讲授信息系统开发方法的时使用。
案例三 A 公司信息化建设的问题出在那里？
A 企业属于制造型企业，不仅生产自有产品，而且承接其他企业的外协件生产。几年前，已相继建立起MPRII 系统，产品设计部使用CAD 、CAPP 、与PDM 系统，极大的提高的工作效率和质量。
A 企业最高决策者是张总裁。B 企业是A 企业强有力的竞争对手。
关于A 公司信息化建设状况的描述：
日历上写的是星期四，但对于张总裁，这天更象是另一个星期一。每天看起来都象是
星期一。因为，从每个星期一的市场情报资料上，张总裁了解到B 公司逐步在销售上超过了他们，B 公司已经变得更加的盈利，张总裁感到竞争的紧迫感和焦虑，这种紧迫感和焦虑不仅来自外部，而且公司内部也存在很大问题。不管他说什么做什么，他的公司仍在不停的出现各种各样的错误。大到付出昂贵代价，小到让人讨厌，还有一切不大又不小的错误，它们正在缓慢地，但又非常有效的扼杀制约着公司的发展，错误不是由别有用心的人故意制造出来损害公司的，那么问题出在哪了？
就在上个月，他们最重要的一个客户对产品规格的要求发生了变动，但是最后满足变
动需求的产品没有及时送发货部门，使得货物的集中、装箱、上船的一系列行动无法按时进行，于是他们把另一个不太重要的客户预定的产品用飞机送到该重要客户处，尽管这样，还是比预定的到货期迟了。（当然那个不太重要的客户也没有按时收到预定的产品）。尽管他们做了种种的努力（甚至船运改为航运），但这个重要的客户并没有感谢他们，只是对
A 公司的销售人员说：他们不能再容忍这种错误了。
一个顾客开始越来越延迟的付款，信用部门经理决定先押下他的所有订单。尽管信用
部经理已经告诉了发货部领班扣押下那个顾客的所有订单，不幸的是，当时这个领班正在休两星期的假，发货部发货员将该客户的订单集中、检验、并发给顾客。一周后这个拖欠付款的顾客宣布破产了。但当张总裁对着发货人发火的时候。发货部领班反驳说：仅仅一周前，你告诉过我们要确保货物按时发出，我正是照你说的做。自从那次激烈的讨论后，发货部门总被一种愤怒、委屈的沉寂包围着。销售人员完成了他们的销售计划，但公司的利润还在持续下滑。
面对市场竞争环境，下游客户从自身业务出发对供应链上游成员，提出了新的要求，
他们需要建立更紧密的联系，以节约投产准备阶段时间和费用。例如，下游客户希望供应伙伴——A 公司的工程师，能参与他们的设计过程中，利用电子手段，实现双方采购信息系统和销售信息系统的信息对接、实时交换和查询产品设计的相关技术文件。他们希望接到自己的订单时，只需“按一下鼠标按键”就可把订单实施计划直接变成原材料计划，通过跨组织的网络系统传递和纳入A 公司的生产制造系统和托运计划。但是A 公司无法满足上述要求，导致下游客户的原材料短缺，A 公司也经常运载体积不够而大伤脑筋。就在两周前，为了按期交货，A 公司刚刚航空托运了一批货给一个客户。这件事源于船运时遇到的运载空间问题。更早一周，是由一个A 公司的主要供应商引起的，再早两周前，„„总是有各种各样的原因造成了一次又一次的损失。
A 公司现在使用的MRPII 系统，假设前提是供应商都能够按照约定无条件供货，而
且不得更改。实际操作时，往往存在供应商有条件改动的可能。即使供应商做到无条件供货，A 公司的管理者们也没有足够的时间和能力来应付大量的改变的约定，他们也没有合适的信息处理系统来支持他们调整生产计划。
三个月以前，张总裁和他的所有管理层职员一起用两天时间召开了的关于企业销售策
略实施计划的决策会议，这个会议开的非常成功，至少他们是这样说的。但是这些实施计
划并没有被贯彻到日常的决策和销售运做中。这种现象早年也发生过。因为，张总裁不肯定管理人员做出的那些决策是最佳的，他感到那些高层职员，包括他自己都不能获得较全面的市场与营销方面的细节层次数据的支持。例如：他的销售人员每隔一段时间就会发现有一个减价销售大量商品的机会，A 公司应该接受这个价格吗？
原材料采购部经理正试图说服A 公司实施他们制定的关于“减少计划”，即减少投产
准备时间，减少存货。这听起来似乎是有前途的，但积压的存货并不能如他们所愿地减少，况且，经理还需要对操作工作中决策过程与规则做必要的改变。
A 公司承接其它制造企业的定制产品订单任务时，销售人员必须不停的向A 公司办公
室汇报很多各种各样的产品报价单，因为那些专业的规格资料实在是多的数不胜数。客户们反映B 公司（A 公司的竞争对手）的销售员就可以把报价单放在客户的办公室上，并且邀请客户上网联接到他们的主机，实现在线实时的报价和订单合同洽谈。
A 公司的售后服务是相对独立的一套业务系统，通过公司计算机网络系统，售后服务
人员可以使用常用的自行研制的软件工具，从数据库中直接调用资料，获取关于产品数据及技术资料，服务维修咨询和指导。当他们更换了一个由A 公司的供应商处得到的配件时，他们也试图从供应商那里得到支持。但是，不论是售后服务系统，还是MRP Ⅱ系统都没有记录和保存这些信息，而且，当外出服务工程师在外面修理一台机器时，售后服务系统并不能给出该客户的一张完整清晰的合同订单，无法清楚提供哪些更换部分是客户质量保证书或服务协议涵盖的，哪些不是。
对于A 公司的工程设计部门负责产品开发设计，产品数据管理系统（PDM ）和MRP Ⅱ系统用的都是一样的重要信息系统，但它们不是集成的，所以工程师必须把PDM 系统的产品数据的变化人工输到MRP Ⅱ系统中，以保证它们同步性、数据的一致性。产品的设计过程，从产品概念构思到产品上市，需要大约９－１２个月的时间。
市场部本来应能提供关于新产品开发的创意思想，尽管他们基本没有能力也不必要按
工程设计规范要求进行描述。但当设计工程师开始设计新产品时，市场部门却不能直接十分清楚表述市场、客户真正需要的具体细节数据和信息。所以工程师只是在那些已掌握的数据信息基础上尽量发挥。
A 公司相当大的一部分不断增长的商业机会，需要更多资深工程师的努力，而不是
简单体力劳动力，公司的优良业绩必须体现在财务利润报表上，但A 公司已经连续三年利润滑坡了，因此它不得不解雇了一大批工程师，其它的一些工程师也纷纷跳槽，使得A 公司失去了更多的有丰厚的利润的商业机会，这远比节省的劳动力费用高的多。
总而言之，A 公司和许多其它制造公司一样，高层决策者们必须在低效率、缺少活力
的公司和高效率、充满活力的公司之间最出果断的战略决策和信息系统的规划。
一、 教学目的
通过运用系统规划理论和方法的学习，结合对此案例的分析，帮助学生理解信息化建
设对企业经营发展和竞争能力的重要作用，提高对企业信息管理需求分析的能力，培养设计企业信息系统的目标与建设方案的能力。
二、讨论参考题
1. 分析整理A 企业的管理业务流程中存在的问题？
2. 分析整理A 企业对信息系统的需求？
3. 你对A 企业目前如何有效地进行信息系统的选择有什么建议？
4.A 企业的信息系统建设正处于那个阶段？
5. 谈谈你们对A 企业信息系统规划的设想?
三、使用建议
本案例可用于本科生开设的“管理信息系统”课程，“信息系统分析与设计”课程，
“信息系统的战略规划”教学专题。
四、案例需要的背景知识
计算机基础知识，企业生产运作与管理知识，信息系统规划、分析与设计知识，数据库原理及应用知识，企业经营战略与管理知识、企业资源计划知识等。
案例四 对某企业的信息系统的初步调查
（1）企业背景：
该企业于1983年开展计算机辅助管理工作，在硬件设备配置、软件开发、技术队伍
方面已初具规模，对企业的发展起了积极的推动作用。到了1999年达到顶峰，年产值1个多亿，利润率为20%。
但是，随着企业从单纯生产型向生产经营型转变，由原来只生产空调压缩机的零件到
现在的整机生产，生产过程日趋复杂，企业管理水平落后的矛盾日益尖锐，具体表现在长期采用的传统手工业或微机加手工管理方式无法满足经营中多层次、多品种、多批量生产计划的管理，也满足不了任何一种产品生产全过程的动态信息管理。各部门间信息沟通不畅造成信息大量冗余和差异，决策者得不到他所想要的准确信息，加之，原材料的不断涨价，市场需求减少等原因，使产品成本连年上升，由于压缩机需求关系趋向饱和，使得市场价格又不断下降，企业利润大幅度下滑。从2000年开始，企业领导为了有效地降低成本，提出划小核算单位、分级核算的方案，用信息系统完成企业的各级核算工作，对成本进行定量化的分析，其目标是完成全企业的各级核算工作，有效地控制成本。
（2）该企业现行的系统主要用于人事管理、财务管理、计划、统计、计件、工资管
理等，没有把已建立的系统与相关的数据结合起来，完成成本核算。经过对企业目前的经济状况及技术力量的调查分析，认为比较容易把这些彼此分散开发的软件系统化、标准化，把相关的数据结合起来，开发一个使得企业的决策经营以市场为核心，以成本为依据，以利润为目的的成本核算管理信息系统。
（3）企业成本核算系统的目标、结构及功能：
①系统目标。首先，建立一个能覆盖从原材料进厂到产品出厂，物料全过程的成本核
算系统。该系统集成了车间成本核算、材料核算、动力核算、销售核算、资产核算等子系统；通过各个子系统的运行，信息共享，数据互相传递，完成整个企业的成本核算工作，有效地控制成本，提高利润率。
②系统结构及功能。从对企业的现状提出问题到确定目标，经过组织机构调查、确定
系统边界，分析业务流程及功能分析等步骤，需要确定的系统结构如下图所示，图中表明了成本核算系统的各子系统要完成的基本功能。
（4）计算机逻辑配置方案。总体规划的后期，要考虑计算机逻辑配置方案，这是从系统需求的角度提出对计算机配置的基本要求，而不涉及其具体硬件型号。计算机逻辑配置方案设计从以下几个方面考虑：
①客观条件约束。包括资金、现有计算机系统、技术力量（开发和维护）。
②网络布局。按照系统的要求制定网络布局方案。
③硬件系统。包括计算机的存储量、运算速度、外部设备的功能、效率、可靠性、通行设备的能力等。
④软件系统。包括操作系统、数据库管理系统、网络软件、程序设计语言等。
一、教学目的
通过对某企业的管理背景的初步调查，说明初步拟定信息系统目标、初步构建信息系统的框架的过程。
二、讨论参考题
1． 分析该企业成本管理存在的问题？
2． 分析该企业对信息系统的需求状况？
3． 你对该企业成本核算系统的目标的拟定、结构及功能的构建有何建议和设想？
三、使用建议：
本案例可在讲授系统规划阶段进行初步调查拟定系统目标、设想系统功能时使用。
案例五 一个某零部件生产厂的销售系统
一个某零部件生产厂的销售系统。该厂的产品是各种不同类型的零部件，其加工周期为10天左右。工厂的生产逐渐转向以销定产。工厂设有销售科，销售科的工作除推销产品外，还进行接受合同、处理合同(、向计划科提出生产要求并如期执行合同的信息加工工作) ，另外还要管理一个成品库。我们要开发一个用于销售管理的信息系统，它可以是整个企业管理信息系统的一个子系统，也可以是一个独立的信息系统。现行销售系统的详细业务如下：
接受合同:
● 用户(即顾客通过各种方式向厂方订货，当收到用户订单后，
● 首先对每份订单粗略地检查，看是否合理. 例如填写是否正确，订货货名是否属于本
厂产品等。
●
超出预定计划30%之内，则同意此项订货，还要将此订货合同送到科内会计那里，会计审查订货单位的信用情况，
如该顾客无欠款或是新顾客则会计签字表示同意接收，送至科长，科长审核上述几方面情况后正式接受此
● 将合同情况向生产计划科作，以便安排生产，同时向订货单位发出付款通知，
也通知财务科准备
收款。
处理合同:由于顾客既不希望厂方拖延交货日期以致延误生产又不希望过早收货以致材料堆积而造成浪费。
●
● 如果发现没有库存，及时通知计划科，赶紧补生产，由于本厂产品周期较短，所以可
以在下次查找时再次处理该合同。
●
● 如已付款则作发货单，一份交发货员，将货发出，一份随货寄至
顾客。并在订货合同
文件上注销。
管理成品库:该科还有一个成品库，它的管理也在该信息系统中，
● 当接收发货单
● 当成品车间送来成品
该销售信息系统的数据流程图：
一、教学目的
本案例通过描述一个某零部件生产厂的销售系统，说明了系统分析阶段针对业务流程和数据流程进行调查分析的描述表达方法，有助于学生掌握业务流程的描述方法和数据流程图的绘制方法。 二、讨论参考题
1．分析该系统的业务流程和数据流程有那些需要改进的地方？
2．结合案例请你谈谈绘制数据流程图时的基本思路以及应注意的事项？ 三、使用建议
本案例可以作为讲授信息系统的系统分析阶段详细调查工作时使用，也可作为绘制数据流程图的示例。
汽车修理管理信息系统
某汽车修理厂根据业务发展的需要，决定建立一个以数据库为基础的管理信息系统，以代替单一的人工管理。目标系统取名为“汽车修理管理信息系统”(QCXL—M 工S) 。通过用户调查，初步整理出以下的结果：
1．系统的数据需求分析
调查获悉，该厂在业务管理上共使用5种单据，4种帐册和3种主要报表。现分述如下：
(1) 5种单据
业务流程： D1由送修人填写。修理派工员据此开出修理单D2，分派给指定的修理工执行。如果在修理中更换零件，一律由修理工填写零件领用单D3向仓库领用。修理结束后，修理工将D2交回派工员，然后转财务部门结帐并开修车发票D5。D4在零件入库时由仓库管理员验收并且填写。图9。4—9．8显示了这些单据的格式与内容。
除上述3种报表外，该厂还使用若干种统计表，供有关部门作分析或预测之用。例如在半年一次的统计，“平均修理周期分月统计表”(含月份和平均修理天数两项) 、“修理次数分型统计表“（含汽车型号、修理次数二项) 、“修理次数分类统计表”(含修理项目、修理项数二项) 等多种，为了简化所讨论的问题，这里就不细述了。 对目标系统的功能需求
通过对当前系统的调查和与用户的共同讨论，对将要开发的目标系统提出了如下的总体需求； (1)用数据文件代替现用的全部帐册；
(2)具有对各种数据文件装入和修改数据的功能；
(3)能计算修车费用和开发票。其中修车费按下列各式计算： 零件费＝Σ零件价格*耗用数量 修理费＝小时工资*修理工时* 3 总 计＝零件费+修理费
(4)能找出需要订货的零件，编制并打印零件订货计划。 订货条件：零件库存量
(5)按现行格式和内容编制和打印零件耗用月报表和修理工资月报表； (6)有多种查询和统计功能。为了简化讨论，具体需求就从略了。
2．数据分析（ DFD 和数据字典）
这是数据库系统开发中十分重要的一项活动。其首要任务，是确定目标系统中使用的 全部数据，为它们取名和定义。在传统的软件工程方法中，数据常区分为数据文件、数据流 (组合数据) 和数据项(单个数据) 三大类。分析中要为每一数据编写一个数据条目，然后将 所有条目合编为数据字典。这样，在随后进行的系统设计中不论有多少人参加，
大家都可 以数据字典为统一的根据．不必担心因数据不一致而导致矛盾和混乱了。
（一）．确定各个单项数据(不含数据文件和数据流) 在目标系统中的名称。
为数据取名时应注意：(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 ，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，LJH ．SL)
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) （二）．定义数据项的含义与取值
将上一步得到的全部数据项综合起来，加上含义与取值，便可得到整个目标系统的数 据项条目，如表9．5所示。不言而喻，这些数据项将构成定义应用系统字段变量和内存变 量的根据。
（三）．定义目标系统的数据流
系统的输入数据和输出的打印数据，一般可转换为目标系统的输入和输出数据流。
就
本例而言，D1～D5，B1～B3共可定义8种数据流，如表9．6所表示。 数据字典卡片（略），举例如下：
3 。概念设计：用E-R 图描述概念模型
（一）确定E-R 模型应含的实体
汽车，修理工，修理单，零件
（二）建立对应的单项应用的局部E-R 图
在实体之间建立联系，通常作法，在系统功能分析中首先选出一至数项有代表性（设计实体较多的）单项应用功能，建立局部R-E 。然后在次基础上逐步扩充，直到在所有试题之间建立应有的联系。
例：“开设修理发票”：
计算修理费涉及到修理工的“小时工资”，修理单的“修理小时”， 计算零件费涉及到修理单的“零件用量”和零件“价格” 发票中的“车主名”和“地址”，涉及到汽车，
（三）将局部E-R 图综合为系统的总体E-R 图
（四）* 改进总体E-R 图：最小数据冗余。
(1)删去修理单中的3个属性“零件费“、“修理费”和“总计”。这3个属性
数据均可从其它数据计算得出。通常把这类数据称为“衍生数据”或“可到出数据”，以区别于不能从推倒得到的“基本数据”。把他们删去可以减少冗余。 （2）将实体“汽车”分解为“汽车”和“车主”，因为汽车属性集中含有汽车与车主两方面的信息。如果车主送修N 辆汽车，则关于车主名、地址、电话等会重复存贮N 次，造成数据冗余。
4．逻辑设计。将E-R 模型转换为关系模型，且规范化。
（一）每个实体转换为一个关系 （二）把每一联系转换为关系
联系的情况比较复杂。例如在E-R 模型中，有的联系不带属性，有的联系可能带一个或者多个属性。在转换成关系时，在关系的属性集中一般应包括(1)联系本身的属性；(2)由它所联系的各个实体的主键。以图10．10中的三个联系为例，可分别按下述的步骤进行转换：
(1)联系名：使用—所联系的实体及其主键： 修理单(主键为“编号”) 零 件(主键为“零件号”)
零件用量表（编号，零件号，数量）
对应的关系因为一张修理单可能使用几种零件，只有编号加上零件号，才能唯一地决定某种零件在修理中使用的数量。所以本例的主键应由两个属性——编号与零件号一起组成。这种由几个属性组合起来的主键，通常称为关系的“复合键”。
(2)联系名；属于所联系的实体及其主键： 汽车(主键为“牌号”) 车主(主键为“车主名”) 对应的关系；
汽车归属表(车主名，牌号)
一个车主可能仅送修一辆汽车，也可能送修多辆汽车。有了汽车归属表，便可知道哪辆汽车是哪一车主送修的，或某一车主共计送修了哪几辆汽车。由于“属于”本身不带属性，所以对应的关系将仅含两个属性——车主名与牌号。它们构成新关系的元组，同时也
是新关系的主键。这种由整个元组构成的主键，在有些文献中称为“全键”(AII，KEY)
(3)联系名：修理所联系的实体及其主键：
修理单(主键为“编号”)
汽 车(主键为“牌号”)
修理工(主键为“工号”)
对应的关系：
修理（编号，牌号，工号，修理项目，修理小时，送修日期，完工日期）
上述关系式中的后面4项，都是“修理”本身的属性。显然，这一关系与前面由实体“修理单”转换得到的关系是重复的，只需要保留一个修理单就可以了。
综上可知，从5个实体可导出5个关系，3个联系可导出3个关系，去掉重复的一个，关系的总数为＝7个。
（三）转换结果的改进
上述的结果仍有改进的余地。一般地说，对于由“联系”建立起来的关系，如果联系本身不带属性，都可以仿照方法处理，即：删除掉联系转换生成的“关系”，但对于1：M 的联系的两个实体，将处于“1”端的实体的主属性附加到处于“M ”端的实体(本例中为汽车) 的属性集中，而不是相反。
例如：“汽车归属表”来说，它唯一的作用是建立“车主”与“汽车”的联系是1：M ，且联系本身没有属性，在删除“汽车归属表”，有两种方案(a)在关系“汽车”中附加“车主名”b) 在关系“车主”中附加汽车“牌号”
(a) 汽车(牌号，型号，生产厂，车主名) ----- 汽车(牌号，型号，生产厂)
(b)车主(车主名，地址，电话) ------ 车主(车主名，地址，电话，牌号)
分析：如图10．12所示，假设有一位车主——大华纺织厂送修了三辆汽车。当“汽车”与“车主”间没有直接联系(即通过“汽车归属表”联系) 时，该车主在“车主”中只占一个元组，在“汽车”中占用3个元组。
● 采用图l012(b)的方法，则在两个关系中占用的元组数不变，但在“车主”关系中，
大华纺织厂的名字将重复3次。
● 采用图10．12(c)的方法，则在两个关系中占用的元组数都将达到三个。后一方
案的冗余数据显然较多。
造成以上差别的原因，是因为车主与汽车间存在着一对多(1：M) 的联系。一个车主可能送修多辆汽车。把送修汽车的牌号附加到“车主”中，则送修M 辆汽车的车主，其全部属性就会重复出现M 次。
（四）．转换结果小结
根据以上的讨论，汽车修理管理信息系统的关系模式将由下列6个关系组成：
(1)修理：（工号，姓名，地址，电话，出生日期，进厂日期，小时工资)
(2)修理单表(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)
(3)汽车(牌号，型号，生产厂，车主名)
(4)车主(车主名，地址，电话)
(5)零件库存表(零件号，零件名，成本，价格，库存量，最低库存量，订货量)
(6)零件用量表(编号，零件号，数量)
将上述结果与当前人工系统的四种账册比较(参阅第9．3．1节) ，关系(1)、(5)分别对应于当前系统的修理工名册和库存零件台账，内容也基本相同；当前系统的汽车登记册在新系统中一分为二，变成汽车(3)和车主(4)两个关系，与此相似，汽车修理台账也一分为二，变成修理单表(2)和零件用量表(6)两个关系。这些改变的作用是什么? 在理论上是否合理?
（五）关系规范化
在逻辑设计阶段，需要用规范化理论来指导数据库的设计。如果设计关系模式时都要像上面那样计算冗余，当然太麻烦了。实际上判断一个关系会不会产生冗余，是有规律可循的，这就是下面要讨论的在属性之间存在的“依赖”。多数的冗余，都是由于在属性之间存在不适当的依赖关系引起的。
第一、第二和第三范式 为了建立冗余较小、结构合理的数据库，Codd 把关系应满足的规范划分为若干等级，每级称为一个范式。满足最低的要求称为第一范式(1NF)， 在1NF 基础上又满足某些特性叫第二范式(2NF)，在2NF 基础上再满足一些要求的为 第三范式(3NF)等等。以下是这些范式的定义。
完全函数依赖与部分函数依赖
关系中的属性可区分为主属性和非主属性两类。主属性组成关系的主键，它能唯一地识别关系中的一个元组．在主属性和非主属性数据之间存在的这种关系，可称为“函数依赖”关系。
在非主属性中所有属性完全依赖于主键中的全部主属性，称这种依赖为“完全函数依赖”，在非主属性中只有部分属性完全依赖于主键中的全部主属性，其余非主属性均仅依赖于主键中的部分主属性。通常称这种依赖为“部分函数依赖” 。
属于完全依赖的关系中，在非主属性之间，存在函数依赖关系，说明，牌号通过某隐含的属性(这里是车主名) 间接地决定地址与电话的值。
规范式定义
定义一；如果一个关系R 的每一属性都是不可再分的，则称R 为第一范式的，记作R
∈E1NF ．
定义二：若R ∈lNF ，且它的每一非主属性完全依赖于主键，则R ∈2NF 。
定义三：若R ∈2NF ，且它的每一非主属性不传递依赖于主键，则R ∈3NF 。 从这些定义可知，2NF 关系可从1NF 关系消除非主属性对主键的部分依赖后获得， 而3NF 关系可从2NF 关系消除非主属性对主键的传递依赖后获得。这一过程也可以表示为
下面请看几个例子。
[例1] 判断下列关系的范式等级：
修理单(编号，牌号，工号，修理项目，修理小时，零件号，数量，送修日期，完工日期) 分析；
(1) 所有属性均为不可分的原子项，
(2) 主键为编号和零件号，且存在部分依赖，例如(编号，零件号) 一》牌号判断修理单为
1NF 。
如果把上述关系分解成如下的两个关系
修理单(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)
零件用量表(编号，零件号，数量) ，
就可以消除关系中的部分依赖。又因关系中原来就不存在传递依赖，所以两个新关系都属于3NF 。
[例2] 判断10-2中三个关系的范式等级。
方案(1)汽车(牌号，型号，生产厂，车主名，地址，电话)
分析：(1)属性均不可再分，
(2)主键为单个属性，不可能存在部分依赖：
(3)有传递依赖，例如牌号一》地址。
判断：汽车为2NF
方案(2)：汽车(牌号，型号，生产厂，车主名)
最后结果
(1)修理：（工号，姓名，地址，电话，出生日期，进厂日期，小时工资)
(2)修理单表(编号，牌号，工号，修理项目，修理小时，送修日期，完工日期)
(3)汽车(牌号，型号，生产厂，车主名)
(4)车主(车主名，地址，电话)
(5)零件库存表(零件号，零件名，成本，价格，库存量，最低库存量，订货量)
(6)零件用量表(编号，零件号，数量)
（六）规范化小结
(1)所谓范式，其实就是施加于关系模式的约束条件。要求所有的关系模式至少要满足1NF ，是为了避免“表中套表”给计算机处理增加的麻烦。但由于仅仅满足1NF 的关系可能存在部分依赖或传递依赖，仍可能有较大的冗余，同时给数据处理带来诸多的不便。较高的范式代表了较严的约束，从而能使数据的结构更趋简单，数据间的联系更为清晰，数据的操作更加简便。以例10—4为例，如果有一位送修了多辆汽车的车主因搬家改变了地址与电话，当汽车与车主合用同一个关系(为2NF) 时，需要同时修改多条记录的内容万一有一处漏改；就破坏了数据的一致性。但若分解为两个独立的关系(均为3NF) ，只需在“车主”中修改一个记录就行了。不仅操作方便，出错的机会也少得多。
(2)模式分解可用于提高范式的等级。从例10—3到例10—5所举的几个例子，都说明了这个问题。一般地说，随着规范化程度的提高，关系的冗余将相对降低，因插入、删除或修改引起的操作异常也会减少．但事情总是一分为二的。分解愈细，查询时花费在关系连接上需要的时间也愈多。权衡利弊，有时会得不偿失。所以在具体应用中，模式分解应该从实际出发，适可而止，不应片面追求提高范式的等级。
综上可知，不但要熟悉E —R 模型向关系模式转换的规则，更应该懂得规范化理论和通过模式分解优化设计的方法，才能在实现设计中作到结合实际，灵活运用。
5 .物理设计
关系数据库的物理设计比较简单。对于一般的微机关系数据库系统来说，在这一阶段的工作内容主要包括；
（一）确定所有数据库文件的名称，及其所含字段的名称、类型与宽度
（二）确定各数据库文件需要建立的索引，在什么字段上建立索引等。
下面仍以汽车修理管理信息系统为例进行说明。
第一步：确定所有字段的名称、类型与宽度，见表10：1。
第二步：确定数据库文件的名称及其组成，见表10．2。
第三步：确定索引文件与索引码。文件妁名称与索引码见表 10．3。
第四步：按选定的语言建立上述的数据库文件及其索引文件。
信息系统分析与设计案例集
一、教学目的
本案例通过描述某汽车修理管理信息系统，说明了数据库设计的基本过程，使学生对于用户需求分析的方法、数据库的设计方法有更深刻的理解。
二、讨论参考题
1．系统的物理设计方案是如何提出的? 它包括哪些内容？
2．结合案例请你谈谈数据库设计的步骤以及具体的方法。
三、使用建议
本案例可以作为讲授信息系统数据库设计时使用。