自助餐管理系统详细设计说明书.docx
《自助餐管理系统详细设计说明书.docx》由会员分享，可在线阅读，更多相关《自助餐管理系统详细设计说明书.docx（26页珍藏版）》请在冰豆网上搜索。
自助餐管理系统详细设计说明书
自助餐管理系统详细设计说明书
一、引言
背景与目的
随着一些公司的规模不断扩大，公司后勤管理工作也日趋繁杂。
许多大型公司拥有自己的食堂，这些食堂要实现统一的协调管理，就不得不借助现代化的管理模式——网络管理模式。
由于某公司为了提高职工的福利待遇，规定每个员工每天可以在职工食堂用餐两次（每餐3元），可以中午用餐一次，下午用餐一次；也可以集中到中午或下午一次用餐两次。
月底进行核算，如果用餐次数不足，餐费不退还职工。
公司根据实际的用餐次数支付食堂餐费。
根据题目要求，需要设计并创建该公司的自助餐管理系统，这样不仅提高了工作效率，也避免了以前手工作业的麻烦，从而使管理者能够准确，有效的管理餐饮。
后台数据库SQLSever2008简介
SQL全称是“数据化查询语言”，其结构简单，功能强大，简单易学，所以自从IBM公司1981年推出以来，SQL语言得到了广泛的应用。
SQL语言是高级的非过程化编辑语言，允许用户在高层数据结构上工作。
SQL语言不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式，所以具有完全不同底层结构的不同数据库可以使用相同的SQL语言作为数据输入与管理的接口。
它以记录集合作为操纵对象，所有SQL语句接受集合作为输入，返回集合作为输出，这种集合特性允许一条SQL语句的输出作为另一条SQL语句的输入，所以SQL语言可以嵌套，这使它具有极大的灵活性和强大的功能，在多数情况下，在其他语言中需要一大段程序实现的一个单独事件只需要一个SQL语句就可以达到目的，这也意味着用SQL语言可以写出非常复杂的语句。
二、系统需求分析
随着21世纪的到来，人们深切的感受到了计算机在生活和工作中的作用，越来越多职业需要具有计算机的应用技能。
掌握计算机是职业的需要，更是事业发展的需要。
信息在社会和经济的发展中所起的作用越来越为人们所重视。
信息资源的开发利用水平已成为衡量一个国家综合国力的重要标志之一。
在计算机的三大主要应用领域（科学计算、数据处理与过程控制）中，数据处理的比重占70%左右。
计算机作为信息处理的工具，为适应数据处理需求的迅速提高，满足各类系统对数据处理的要求，在文件系统的基础上发展起了数据库系统。
随着计算机技术的飞速发展，计算机在企业管理中应用及普及，利用计算机实现企业信息管理势在必行。
本课题以企业食堂为对象，作为要面对大量的课程设计项目及相关信息的处理，这就需要一个课程设计管理系统来提高管理工作的效率。
通过本系统，可以做到信息的规范管理、科学统计和快速查询，从而减少管理工作方面的工作量。
数据处理工作已深入到我们工作和生活的方方面面，而数据库技术是数据处理必不可少的手段。
随着数据库技术的发展，面向对象的数据库、分布式数据库、多媒体数据库、数据库开发工具的研究方兴未艾，这些技术的发展使软件的开发速度更快、成本更低、质量更好、功能更强。
管理信息系统是一门新兴的、集管理科学、信息科学、系统科学及计算机科学为一体的综合性学科，研究的是信息管理活动的全过程，以便有效的管理信息，提供各类管理决策信息，辅助企业进行现代化的管理。
管理信息系统它具备数据处理、计划、控制、预测和辅助决策功能，具体作用如下5点内容:
（1）用统一标准处理和提供信息，排除使用前后矛盾的不完整信息；
（2）完整、及时提供在管理及决策中需要的数据；
（3）利用指定的数据关系分析数据、客观预测未来；
（4）向各级管理机构提供不同详细程度的报告，缩短分析和解释的时间；
（5）用最低的费用最短的时间提供尽可能精确、可靠的信息，以便使决策者选择最佳的实施方案，以提高企业的经济效益。
系统功能分析
系统开发的总体任务是受用计算机信息管理技术，实现公司的自助餐管理各种信息的系统化，规范化，自动化，提高公司食堂管理的效率。
对应用系统项目的开发，首先要对程序要实现的功能和目标进行整体分析和规划，确保在后期开发中不会出现遗漏或重大缺陷。
因此在软件开发中，要严格按照软件工程的流程进行系统的分析和设计
系统功能分析是在系统开发的总体任务的基本上实现的。
主要功能：
（1）职工信息管理；
（2）职工食堂信息管理；
（3）成本核算管理。
其中主要任务为职工信息管理和成本核算管理。
总的功能特点：
完善、全面的综合查询；
报表翔实，实用性强；
子模块功能分析
职工信息管理：
对来自客户端的不同用户进行权限审查，限定对数据库的访问级别
图2-1
职工用餐信息管理：
记录员工用餐的次数，包括每日用餐次数和每月的用餐次数；
图2-2
本日用餐次数：
记录本日用餐次数，每增加一个便同步使每月用餐次数也增加一次，每日用餐次数不大于2次。
成本核算管理：
对成本利润的综合分析。
成本包括公司的本月开销和之前月份公司开销的统计记录：
图2-3
公司本月开销：
统计公司本月的开销，员工本月消费一次则增长3元的开销。
公司每月开销：
记录之前每月的开销情况。
系统功能模块设计
对上述各项功能进行集中、分块分析，按照结构化程序设计的要求，得到如图所示的这个系统的功能模块图。
图2-4
数据流图
数据流程图是组织中信息运动的抽象，是管理信息系统逻辑模型的主要形式。
它可以综合的反映出信息在系统中的流动、处理和存储情况，具有良好的抽象性和概括性。
它在调查的基础上，从系统的科学性、管理的合理性、实际运行的可行性角度出发，将信息处理功能和彼此之间的联系自顶向下、逐层分解，从逻辑上精确地描述系统应具有的数据输入、数据加工、数据输出、数据存储及数据来源和去向（外部实体）等项目。
数据流程图和系统的物理描述无关，它所描述的内容不涉及技术细节，而是面向用户的，即使完全不懂信息技术的用户也容易理解。
因此，数据流程图成为系统分析员与用户进行交流的有效手段，同时也成为系统设计的主要依据之一。
用户的需求具体体现在各种信息的提供、保存、更新和查询等方面，这就要求数据库结构能充分满足各种信息的输入和输出。
收集基本数据、数据结构及数据处理的流程，组成一份详尽的数据字典，为数据库的具体设计打下基础。
数据流图表达了数据和处理之间的关系。
数据流图是有层次之分的，越高层次的数据流图表现的业务逻辑越抽象，越底层次的数据流图表现得业务逻辑越具体。
在仔细的分析调查有关食堂管理信息需求的基础上，得到如下图所示的这个系统所处理的数据流程。
根据以上的分析，我们可以先画出分流程图，然后可以综合分流程图，画出整个系统操作的业务流程图。
图2-5
整体流图简图：
图2-6
可行性分析
可行性分析是系统分析阶段的重要活动，是对系统进行全面、概要的分析。
它的任务是确定项目开发是否必要和可行。
它的主要目标是：
进一步明确系统的目标、规模和功能，对系统开发背景、必要性和意义进行调查分析，并根据需要和可能提出拟开发系统的初步方案和计划，明确问题，对所提供系统大致规模和目标的几个有关约束条件进行论证，并且提出系统的逻辑模型和各种可能的方案，从而为系统开发项目的决策提供科学依据。
其主要从三个方面进行研究：
技术可行性：
对现有技术进行评价，以明确能否利用现有技术进行系统开发及系统实施。
计算机网络技术的发展和计算机硬件性价比的不断提升，使计算机全面应用于医院管理的各个环节成为可能。
C/S开发模式、COM、DCOM技术在国内各行各业的信息管理系统开发中已经被广泛采用，实践证明这些技术都非常适合食堂管理系统的开发。
经济可行性：
对组织的经济状况和投资能力进行分析，对系统建设、运行和维护费用进行评估，对系统建成后可能取得的社会及经济效益进行估计。
连锁餐饮企业整体规模庞大，个体规模小而营管理相对简单统一，开发成本不高，一旦开发成功，即能直接应用在所有同种食堂。
营运可行性：
指系统对组织机构的影响，对现有人员和机构、设施、环境等的适应性以及进行人员培训补充计划的可行性。
连锁餐饮企业整体规模庞大，个体规模小而营管理相对简单统一。
所以食堂系统的计算机信息管理人才、计算机硬件设备、操作员的计算机应用能力都为系统的运行过程提供了可靠保证。
数据字典
由于数据流程图只是对数据处理及彼此之间的联系进行说明，未对数据的详细内容及数据的加工过程进行说明，而这正是数据字典所要表达的。
数据字典是关于数据信息的集合，也就是对数据流程图中包含的所有元素的定义的集合。
它能将数据流程图中全部数据流及其组成部分的数据元素、数据存储、数据加工等描述清楚，便于后续工作—系统设计的进行。
数据字典是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。
数据字典通常包括数据项、数据结构、数据流、数据存诸和处理过程5个部分。
其中数据项是最小组成单位，若干数据项组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储和逻辑内容。
针对一般食堂管理信息系统的需求，通过对食堂管理工作过程的内容和数据流程分析，设计如下所示的数据项和数据结构：
●数据结构名称：
职工用餐卡信息
含义说明：
这里指的是职工用来使用付款的工具卡的一系列信息，它记录了包括它本身以及持卡者的一些信息
包括的数据项有：
1）卡号
（消费者使用的用来付款的卡的编号，与消费者办卡的先后顺序有关
别名Card_number字符型长度6）
2）余额（今日剩余用餐量）
（消费者卡中所剩的金钱数量，别名Balance字符型长度6）
3）办卡日期
（消费者办卡的日期别名Card_date日期型长度8）
4）持卡者姓名
（拥有信息卡的消费者的名称别名Person_name字符型长度10）
5）花费（用餐次数统计）
（消费者所消费的金钱数量别名Consume字符型长度20）
●数据结构名称：
员工信息
含义说明：
消费者群体之一，可以自由选择消费方式，办过卡用卡交易或者用现金交易
包括的数据项有
1）工号：
（职工在公司所编的号码别名S_number字符型长度6）
2）部门：
（职工所在的部门的名称别名S_system字符型长度16）
3）职位:
（职工所担任的职位别名S_class字符型长度20）
4）姓名：
（职工的姓名别名S_name字符型长度10）
5）性别：
（职工的性别别名S_sex字符型长度4）
6）地址：
（职工的所在地址别名S_dorm字符型长度20）
7）联系方式：
（职工的手机号码别名S_tel字符型长度20）
三、概念结构设计
这一设计阶段是在需求分析的基础上，设计出能满足用户需求的各种实体，以及它们之间的关系，为后面的逻辑结构设计打下基础。
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。
它是整个数据库设计的关键。
概念结构设计的特点是能真实、充分的反映现实世界，包括事物和事物的联系，能满足用户对数据的处理要求，是对现实世界的一个真实的模型。
易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库设计成功的关键。
易于改正，当应用环境和应用要求改变时，易于对概念模型修改和扩充。
易于向关系、网状、层次等各种数据模型转换。
概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。
概念结构是对现实世界的一种抽象。
所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念准确的加以描述。
概念结构设计通常分为四种方法：
自顶向下，即首先定义全局概念结构的框架，然后逐步细化。
自底向上，即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。
逐步扩张，首先定义最重要的核心概念结构，然后向外扩张。
混合策略，即自顶向下和自底向上结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
通常分为两步，第一步是抽象数据并设计局部视图，第二步是集成局部视图，得到全局视图。
下面首先对实体和其属性加以描述，再写出系统的分E-R图，进而合并成为整体的E-R图。
构思ERD的四条原则
原则1：
能独立存在的事物，例如人、物、事、地、团体、机构、活动、事项等等，在其有多个由基本项描述的特性需要关注时，就应把它作为实体。
原则2：
两个或多个实体间的关联与结合，如主管、从属、组成、占有、作用、配合、协同等等，当需要予以关注时，应作为联系。
联系通常是某类行为动作，ERD中关注的是其状态与结果而非其过程。
原则3：
实体的属性是实体的本质特征。
实体应有标识属性（能把不同个体区分开来的属性组），并指定其中一个作为主标识。
联系的属性是联系的结果或状态。
属性具有如下几个特点：
a.非多值性；b.非复合性；c.非导出性。
而实体的属性还应有非关联性。
原则4：
（一事一地原则）：
所有基本项在同一E-R图中作为属性要在仅在一个地方出现
设计E-R图
根据上面的设计规划出的实体有：
卡信息实体、员工信息实体、消费者实体、包房信息实体、订餐信息实体、消费情况实体、管理员信息实体。
各个实体具体的描述E-R图及其之间的关系描述如下。
图3-1为卡信息实体E-R图
图3-2为职工信息实体E-R图
图3-3为消费情况实体E-R图
图3-4为卡信息实体、职工信息实体、消费者实体关系E-R图
四、逻辑结构设计
现在需要把上面设计好的数据库概念结构转化为SQLServer2008数据库系统所支持的实际数据库模型，也就是数据库的逻辑结构。
先对数据库进行结构设计，最终导出物理结构模型和逻辑结构模型，并生成SQLServer2008数据库文件。
一般逻辑模型设计
由ERD导出一般关系模型的四条原则
原则1：
E-R图中的每一个独立实体变换为一个关系，其属性变为关系的属性，其主标识变为关系的主码。
原则2：
E-R图中的从实体及相应的主从联系变换为一个关系，从实体的属性加上主体关系的主码构成这个关系的属性。
主从联系是1：
1的，则以主实体关系的主码（作为外码）为这个关系的主码；主从联系是1：
M的，则以主实体关系的主码加上同一主实体个体联系的不同从属实体个体赖以相互区分的属性组，组成该关系的主码。
原则3：
1：
M联系通过在“多”实体关系中增加相联系的“1”实体关系的主码及联系本身的属性来表达。
其中“1”实体主码为外来码。
原则4：
M：
M联系转换成一个独立的关系，被联系实体关系的主码（作为外来码）和联系本身的属性作为该关系的属性，被联系实体关系的主码组成其复合主码。
数据库初步的关系框架（E-R图向关系模型转化）
关系模型转化
消费情况：
（日期用餐次数剩余次数）
消费：
（日期消费序号）
消费者：
（消费序号姓名性别消费类别消费者类别）
属于：
（员工号消费序号）
员工信息：
（员工号部门职位姓名性别地址联系方式）
使用：
（卡号员工号）
卡信息：
（卡号余额办卡日期持卡者姓名花费）
持有：
（卡号员工号）
数据库逻辑设计的结果不是唯一的，为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。
关系数据模型的优化通常以规范化理论为指导，方法为:
1、确定数据依赖
2、对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系
冗余数据和冗余联系容易破坏数据为的完整性，给数据库维护增加困难，应当予以消除。
经过规范化理论得出，原关系模式之间的数据依赖已经达到极小化，没有冗余的联系，消除冗余的E-R图称为基本E-R图
3、按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖，传递函数依赖，多值依赖等，确定各关系模式分别属于第几范式。
4、按照需求分析阶段得到的处理要求，分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合并或分解。
5、对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。
根据需求分析阶段系统的功能分析，这样的应用环境，这些模式可以完成包括消费者信息管理，预订信息管理，成本核算管理，审查工作，库存管理这些模块的要求，分析结果中可在设计用户子模式中对不同级别的用户定义不同的view。
优化后的关系模式：
消费情况：
（日期员工用餐次数消费序号）
消费者：
（消费序号姓名性别消费类别消费者类别）
属于：
（员工号消费序号）
组成：
（员工号消费序号）
员工信息：
（员工号部门职位姓名性别地址联系方式）
使用：
（卡号员工号）
卡信息：
（卡号余额办卡日期持卡者姓名花费）
持有：
（卡号员工号）
具体逻辑模型设计
在上面的实体以及实体之间关系的基础上，形成数据库中的表格以及各个表格之间的关系。
公司自助餐管理系统数据库中各个表格的设计结果如下面的几个表格所示。
每个表格表示在数据库中的一个表。
表4-1创建消费情况表ConsumeSituation
列名
数据类型
可否为空
说明
声明
Date
datetime
NOTNULL
日期
主键建立唯一索引
Total
int
NULL
一天消费总额
建立聚簇索引
Consumer_number
numeric（12）
NOTNULL
消费序号
外键
图4-1
表4-2创建消费者表Consumer
列名
数据类型
可否为空
说明
声明
Consumer_number
varchar（6）
NOTNULL
消费序号
主键
Consumer_name
varchar（10）
NOTNULL
姓名
Consumer_sex
Varchar（4）
NULL
性别
Consume_sort
varchar（10）
NULL
消费类别
Consumer_sort
varchar（10）
NULL
消费者类别
图4-2
表4-3创建员工信息表Worker
列名
数据类型
可否为空
说明
声明
S_number
int
NOTNULL
员工号
主键
S_name
varchar（10）
NOTNULL
姓名
建立聚簇索引
S_sex
varchar（4）
NULL
性别
class
varchar（20）
NULL
职位
S_system
varchar（16）
NULL
部门
S_dorm
varchar（20）
NULL
地址
S_tel
numeric（15）
NULL
联系方式
图4-3
表4-4创建消费卡信息表Card
列名
数据类型
可否为空
说明
声明
Card_number
varchar（6）
NOTNULL
卡号
主键建立唯一索引
Balance
int
NOTNULL
余额
建立聚簇索引
Card_date
Datetime（8）
NULL
办卡日期
Person_name
varchar（10）
NULL
持卡者姓名
Consume
varchar（20）
NULL
花费
建立聚簇索引
图4-4
表4-5创建管理查询表Manage
列名
数据类型
可否为空
说明
Manager_number
varchar（6）
NOTNULL
管理员编号
Date
datetime
NOTNULL
日期
图4-5
表4-6创建属于表Attribute
列名
数据类型
可否为空
说明
S_number
varchar（6）
NOTNULL
员工号
Consumer_number
varchar（6）
NOTNULL
消费序号
图4-6
表4-7创建使用表Use
列名
数据类型
可否为空
说明
S_number
varchar（8）
NOTNULL
员工号
Card_number
varchar（6）
NOTNULL
卡号
图4-7
表创建持有表Hold
列名
数据类型
可否为空
说明
Card_number
varchar（6）
NOTNULL
卡号
S_number
varchar（6）
NOTNULL
员工号
图4-8
设计用户子模式
将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点设计用户的外模式。
目前关系数据库管理系统一般都提供了视图（View）概念，可以利用这一功能设计更符合局部用户需要的用户外模式。
定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。
由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以注重考虑用户的习惯与方便。
包括：
1）使用更符合用户习惯的别名。
在合并各分E—R图时，曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。
这在设计数据库整体结构时是非常必要的。
用View机制可以在设计用户View时重新定义某些属性名，使其与用户一致，以方便使用。
2）可以对不同级别的用户定义不同的View，以保证系统的安全性。
3）简化用户对系统的使用。
如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图，用户每次只对定义好的视图进行查询，大大简化了用户的使用。
●消费者查询信息所建立的视图
1）员工查询自己卡中余额
员工查询视图S_Balance
图4-9
2）管理员查询消费者信息
查询员工的信息Worker_consumer
图4-10
五、物理结构设计
数据库在物理设备上的存储结构与存取方法称为数据库物理的物理结构，它依赖于选定的数据库管理系统。
为一个给定的逻辑数据模型选取最适合应用要求的物理结构的过程，就是数据库的物理设计。
数据库的物理设计通常分为两步：
1）确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构；
2）对物理结构进行评价，评价的重点是时间和空间效率。
如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
建立索引
建立索引是加快查询速度的有效手段。
用户可以根据应用环境的需要，在基本表上建立一个或多个索引，以提供多种存取路径，加快查找速度。
一般来说，建立与删除索引由数据库管理员DBA或表的属主（owner），即建立表的人负责完成。
系统在存取数据时会自动选择合适的索引作为存取路径，用户不必也不能显示地选择索引。
索引的选择方法，一般来说：
1.如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）；
2.如果一个属性经常作为最大值或最小值等聚集函数的参数，则考虑在这个属性上建立索引；
由上所述建立以下索引：
●为消费情况表ConsumeSituation建立索引
1）按Total建立聚簇索引
2）按Date升序建立唯一索引
●为消费者consumer建立索引
1）按Consumer_number升序建立唯一索引
●
升级会员 