食堂管理信息系统设计资料.doc

精品文档
前言
学校食堂管理信息系统是一个实用并且是与我们的学校生活密切相关的一个管理信息系统；如果能够很好的研究、开发并加以利用，那么就会提高食堂的效益，降低食堂的成本，降低食堂的饭、菜价从而能够给学校的学生带来莫大的利益和好处。
同时随着高校的扩招，高校的食堂也变得越来越多。有的学校的食堂非常的分散，要实现如此之多的食堂的良好、协调、统一的管理，就需要借助现代的更加先进的技术和科技，比如说：电子信息管理系统、射频技术、网络技术、计算机技术等以实现更加方便、快捷、有效的食堂管理。
我们所选的食堂管理信息系统是在以学校现行的运行结构上进行的设计和说明。
1） 设计选题方向，确定选题
2） 确定小组内部课程设计工作的分工及相应要求
3） 上网搜索查阅和收集相关参考资料和学习资料
4） 进行可行性分析
5） 认真撰写选题说明、系统功能目标和可行性分析报告
6） 完善选题说明、系统功能目标和可行性研究报告
进行调查，深入了解和熟悉选题范围内的组织结构、业务功能、业务数据、管理要求、管理决策模型

1需求分析及可行性分析
1.1系统目标
利用食堂信息管理系统可以做到信息的规范管理、科学统计和快速查询，从而减少管理工作方面的工作量。大大降低食堂管理人员在信息管理精力上的投入，使企业获得更大的利润空间。与此同时给广大学生用户带来方便。在实用性上达到了双赢。
1.2需求分析
（1）功能分析：根据调查，确定食堂信息管理系统主要实现以下功能：饭卡管理（注册，充值，挂失，退卡等），餐费管理，统计管理等。
（2）非功能分析：主要包括以下非功能：性能需求；资源和环境需求；可靠性需求；安全保密要求；用户界面需求；成本消耗与开发进度需求；预先估计的可扩展性需求。
（3）管理的信息需求：由于当前食堂的规模不断扩大，面对庞大的信息量，有效地提高食堂管理工作的效率是急需解决的问题。同时随着计算机的普及以及网络技术的迅速发展，它已经深入到社会生活的各个角落。各行业纷纷应用计算机网络技术进行操作和管理，以改善自己的工作环境和工作效率，进而提高自己在行业内的竞争力。开发食堂管理信息系统有宏观上的意义，顺应时代信息化，提高效益，促进国民经济结构优化；也有微观上的意义，提高管理的现代化程序，加强管理的信息化手段，提高工作效率，增加单位效益。
（4）决策的信息需求：食堂经营者需要根据一个可靠的管理信息系统来进行分析，依据销售情况统计来进行成本核算，不断的做出调整使经营效益达到最优。而管理者通过了解食堂近来的销售情况以及饭卡、餐费等信息，并及时对信息作出统计，以便对食堂进行及时改革，提高效率。
1.3可行性分析
可行性分析是系统分析阶段的重要活动，是对系统进行全面、概要的分析。它的任务是确定项目开发是否必要和可行。主要从以下三方面进行分析：
(1)经济的可行性：对组织的经济现状和投资能力进行分析，对系统建设、运行和维护费用进行评估，对系统建成后可能取得的社会及经济效益进行评估，食堂信息管理系统开发成本不高。
(2)技术可行性：对现有技术的评价，以明确能否利用现有技术进行系统开发及系统实施。计算机网络技术的发展和计算机硬件性价比的不断提高，使计算机全面应用于管理各个环节成为可能。C/S开发模式等技术在国内各行各业的信息管理系统开发中已经被广泛采用，目前该类系统已经普遍应用于生活中，同时该系统也逐步趋于成熟。实践证明这些技术非常适合食堂管理系统的开发。
(3)操作上的可行性：由于本系统管理的对象比较明确，就是对消费者信息的管理，因此整个软件的使用非常简便。任何一个普通的计算机用户都能很快的熟悉整个软件的使用。并且本系统所耗费的资源非常小，任何管理员只需要在一般的电脑上面，就能够使用这个软件，简单、方便、快捷的实现对消费者信息的管理。
1.4新系统介绍
本食堂管理信息系统是在计算机技术、网络技术、面向对象的新数据库技术以及其他相关的科学技术的支持下形成的。它主要是从以下几个管理方面：饭卡管理，餐费管理，统计管理。通过此系统能够很好的处理大量的相关的食堂相关信息。
1.4结论
通过以上的分析可知，食堂管理信息系统是非常有必要的、可行的。

2.系统分析
2.1系统概述
食堂管理信息系统是针对学校食堂的具体的业务而开发和设计的，其目的在于促进学校食堂的高效、便捷、快速的管理。开发食堂管理信息系统，期望实现以下目标。
（1）提高经济效益、增效资源
（2）提高食堂服务质量、建立良好形象
（3）提高食堂员工工作效率
（4）实行学校学生可接受的饭菜价
（5）完善食堂内部管理体制
2.2系统功能分析
系统功能分析是在系统开发的总体任务的基本上完成的。
主要功能：
l 饭卡管理
l 餐费管理
l 统计管理
总的功能特点：
l 完善、全面的综合查询
l 报表翔实，实用性强

2.2.1 系统整体功能管理模块

退卡人员查询
消费查询
个人存款明细
挂失人员查询
食堂管理信息系统
饭卡管理
餐费管理
个人消费
统计管理
解除挂失
饭卡挂失
饭卡充值
补发新卡

退卡

2.3 业务流程分析
该系统主要实现的包括对食堂的饭卡管理，餐费管理以及统计管理三大模块的功能，。其中饭卡管理主要包括对饭卡注册、充值、挂失、解除挂失、补发新卡和退卡的管理，餐费管理主要针对学生消费情况进行管理，统计管理主要是对消费、持卡人、退卡人、个人存款明细及挂失人员的查询。

饭卡信息记录
消费者
饭卡
刷卡消费
个人消费记录
挂失人员记录
充值
挂失
解除挂失
补发新卡
退卡
消费查询
持卡人查询
退卡人员查询
个人存款明细
挂失人员查询
退卡人记录
持卡人名录
个人存款记录
消费记录
饭卡
管理员
注册饭卡
消费者信息
图2-1：食堂管理业务流程图
业务流程图如图2-1所示

2.4 系统数据流程分析
根据调查及分析的结果绘出系统数据流程图如下：
0层数据流程图：

P0

食堂信息管理
消费者信息表
个人消费信息
消费者信息表
消费者信息表
个人消费信息
统计信息表

图2-2：0层数据流程图

1层数据流程图：

P1

基础数据
管理
消费者信息表
消费者信息表
P3

统计管理
消费者信息表
统计信息表

P2

餐费管理
个人消费信息表
个人消费信息表

图2-3：1层数据流程图

2层数据流程图：

S1
消费者
P1.6
D1.1
消费者信息
退卡
F1.1
消费者信息表
S1
消费者
P1.5
D1.1
消费者信息
补发
新卡
F1.1
消费者信息表
S1
消费者
P1.1
D1.1
消费者信息
注册
饭卡
F1.1
消费者信息表
S1
消费者
P1.2
D1.1
消费者信息
饭卡
充值
F1.1
消费者信息表
S1
消费者
P1.3
D1.1
消费者信息
饭卡
挂失
F1.1
消费者信息表
S1
消费者
P1.4

解除
挂失
D1.1
消费者信息
F1.1
消费者信息表

S1
消费者
P2.1
D2.1
消费者信息
个人
消费
F2.1
个人消费记录

P3.1
D2.1
个人消费信息
消费
统计
F3.1
消费统计信息
S2
管理员
F2.1
个人消费记录

F3.2
退卡统计表
P3
D1.1
消费者信息
退卡
统计
S2
管理员
F1.1
消费者信息表

图2-4：2层数据流程图
P3
D1.1
消费者信息
挂失
统计
S2
管理员
F1.1
消费者信息表
F3.3
挂失统计表

2.5 数据字典
由于数据流程图只是对数据处理及彼此之间的联系进行说明，未对数据的详细内容及数据的加工过程进行说明，而这正是数据字典所要表达的。数据字典是关于数据信息的集合，也就是对数据流程图中包含的所有元素的定义的集合。它能将数据流程图中全部数据流及其组成部分的数据元素、数据存储、数据加工等描述清楚，便于后续工作—系统设计的进行。
数据字典是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。数据字典通常包括数据项、数据结构、数据流、数据存诸、数据处理和外部实体6个部分。其中数据项是最小组成单位，若干数据项组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储和逻辑内容。
针对一般食堂管理信息系统的需求，通过对食堂管理工作过程的内容和数据流程分析，设计如下所示的数据字典各项内容：
2.5.1数据项及数据结构
数据项定义：
数据项编号：I1
数据项名称：卡号
别 名：Card-number
简 述：消费者使用的用来付款的卡的编号，与消费者办卡的先后顺序有关
类型及宽度：字符型，6位
取值范围 ：“000001”~”999999”

数据项编码：I2
数据项名称：余额
别 名：Balance
简 述：消费者卡中所剩的金钱数量
类型及宽度：字符型，6位
取值范围 ：“000000”~“999999”

数据项编码：I3
数据项名称：办卡日期
别 名：Card-data
简 述：消费者办卡的日期
类型及宽度：日期型，8位

数据项编码：I4
数据项名称：持卡者姓名
别 名：Person-name
简 述：拥有信息卡的消费者的名称
类型及宽度：字符型，10位

数据项编码：I5
数据项名称：花费
别 名：Consume
简 述：消费者所消费的金钱数量
类型及宽度：字符型，20位

数据项编码：I6
数据项名称：学号
别 名：S-number
简 述：学生在校所编的号码
类型及宽度：字符型，6位
取值范围 ：“000000”~”999999”

数据项编码：I7
数据项名称：系别
别 名：S-system
简 述：学生所在的系的名称
类型及宽度：字符型，16位

数据项编码：I8
数据项名称：班级
别 名：class
简 述：学生所在的班级的班号
类型及宽度：字符型，16位

数据项编码：I9
数据项名称：姓名
别 名：S-name
简 述：学生的姓名
类型及宽度：字符型，10位

数据项编码：I10
数据项名称：性别
别 名：S-sex
简 述：学生的性别
类型及宽度：字符型，4位

数据项编码：I11
数据项名称：宿舍
别 名：S-dorm
简 述：学生所在的宿舍名称
类型及宽度：字符型，20位

数据项编码：I12
数据项名称：联系方式
别 名：S-tel
简 述：学生的手机号码
类型及宽度：字符型，20位

数据项编码：I13
数据项名称：一楼窗口
别 名：Floor-one
简 述：一楼所有窗口一天内收入总和
类型及宽度：字符型，6位

数据项编码：I14
数据项名称：二楼窗口
别 名：Floor-two
简 述：二楼所有窗口一天内收入总和
类型及宽度：字符型，6位

数据项编码：I15
数据项名称：一天消费总额
别 名：Total
简 述：一天内在食堂用餐的消费者所花费的总额
类型及宽度：长整型，6位

数据项编码：I16
数据项名称：日期
别 名：Data
简 述：记录的日期
类型及宽度：日期型，8位

数据项编码：I17
数据项名称：管理员编号
别 名：Manager_number
简 述：管理员在食堂的编号
类型及宽度：字符型，6

数据项编码：I18
数据项名称：姓名
别 名：Manager_name
简 述：管理员的姓名
类型及宽度：字符型，6

数据项编码：I19
数据项名称：性别
别 名：Manager_sex
简 述：管理员的性别
类型及宽度：字符型，4

数据项编码：I20
数据项名称：家庭住址
别 名：Manager_address
简 述：管理员的家庭住址
类型及宽度：字符型，6

数据项编码：I21
数据项名称：联系方式
别 名：Manager_tel
简 述：管理员的联系方式
类型及宽度：字符型，20

数据项编码：I22
数据项名称：工资
别 名：Income
简 述：管理员每个月的收入
类型及宽度：整型，20

数据结构定义：

数据结构编号：DS1
数据结构名称：饭卡
简 述：是消费者用来使用付款的工具卡的一系列信息，它记录了包括它本身以及持卡者的一些信息
数据结构组成：I1+I2+I3+I4+I5

数据结构编号：DS2
数据结构名称：学号
简 述：主要消费者，可以自由选择消费方式，办过卡用卡交易或者用现
数据结构组成：I6+I7+I8+I9+I10+I11+I12

数据结构编号：DS3
数据结构名称：消费情况
简 述：消费者在食堂的消费总体情况，用于管理员的审查工作。
数据结构组成：I13+I14+I15+I16

数据结构编号：DS4
数据结构名称：管理员
简 述：食堂的主要负责人
数据结构组成：I17+I18+I19+I20+I21+I22

2.5.2 数据流
数据流编号：D1.1
数据流名称：消费者信息
简述：消费者信息的添加、修改、查询、注销
数据流来源：消费者
数据流去向：消费者信息表
数据流组成：消费者卡号+姓名+性别+班级+系+余额+联系方式
数据流量：随机，高峰流量：随机

数据流编号：D2.1
数据流名称：个人消费信息
简述：所有消费者的个人消费信息
数据流来源：消费者信息表
数据流去向：消费统计信息表
数据流组成：消费者卡号+姓名+消费金额+消费日期
数据流量：随机，高峰流量：随机

2.5.3处理逻辑
处理逻辑编号：P1.1
处理逻辑名称：注册饭卡
简述：对消费者注册新饭卡的一些处理
输出的数据流：注册后的消费者信息
处理频率：随机

处理逻辑编号：P1.2
处理逻辑名称：饭卡充值
简述：对饭卡进行充值的处理
输出的数据流：更改后的消费者信息
处理频率：随机
处理逻辑编号：P1.3
处理逻辑名称：饭卡挂失
简述：对丢失的饭卡的一些处理
输出的数据流：更改后的消费者信息
处理频率：随机

处理逻辑编号：P1.4
处理逻辑名称：解除挂失
简述：对挂失后又找回的饭卡的一些处理
输出的数据流：更新后的消费者信息
处理频率：随机

处理逻辑编号：P1.5
处理逻辑名称：补发新卡
简述：对已确认丢失的饭卡进行补办的一些处理
输出的数据流：更新后的消费者信息
处理频率：随机

处理逻辑编号：P1.6
处理逻辑名称：退卡
简述：对已不再使用的饭卡进行的一些处理
输出的数据流：更新后的消费者信息
处理频率：随机

处理逻辑编号：P2.1
处理逻辑名称：个人消费
简述：对消费者个人消费的一些处理
输出的数据流：个人消费记录
处理频率：随机

处理逻辑编号：P3.1
处理逻辑名称：消费统计
简述：对所有消费者日常消费的统计
输出的数据流：消费统计信息表
处理频率：随机
处理逻辑编号：P3.2
处理逻辑名称：退卡统计
简述：对所有退饭卡的的消费者进行统计操作
输出的数据流：退卡统计表
处理频率：随机

处理逻辑编号：P3.3
处理逻辑名称：挂失统计
简述：对所有挂失饭卡的消费者进行统计操作
输出的数据流：挂失统计表
处理频率：随机

2.5.4数据存储
数据存储编号：F1.1
数据存储名称：消费者信息
简述：存储消费者信息的表单
数据存储组成：卡号+姓名+性别+所在系+余额+联系方式
关键字：卡号
相关联的处理：P1.1， P1.2, P1.4, P1.5

数据存储编号：F2.1
数据存储名称：个人消费记录
简述：存储个人消费信息的表单
数据存储组成：卡号+消费日期+消费金额
关键字：卡号
相关联的处理：P2.1

数据存储编号：F3.1
数据存储名称：消费统计信息
简述：存储所有消费者消费信息的表单
数据存储组成：卡号+姓名+消费金额
关键字：卡号
相关联的处理：P3.1

数据存储编号：F3.2
数据存储名称：退卡统计表
简述：存储退卡人信息的表单
数据存储组成：卡号+姓名+所在系+联系方式
关键字：卡号
相关联的处理：P3.2

数据存储编号：F3.3
数据存储名称：挂失统计表
简述：存储挂失人信息的表单
数据存储组成：卡号+姓名+所在系+联系方式
关键字：卡号
相关联的处理：P3.3

2.5.5外部实体
外部实体编号：S1
外部实体名称：消费者
简述：食堂主要消费人员，主要指学生
输入数据流：无
输出数据流：关于消费者的一些信息

外部实体编号：S2
外部实体名称：管理员
简述：食堂办理饭卡以及更改饭卡信息的人员
输入数据流：无
输出数据流：关于饭卡注册及更改的信息

3系统详细设计
3.1 代码设计
代码是用来表征客观事物实体类型与属性的一个或一组易于计算机识别和处理的特定符号，它可以是字符、数字、某些特殊符号或它们的组合。代码设计就是要把系统中要处理的事物用特定的代码来描述，便于计算机系统识别、处理，便于数据的共享，提高用户使用数据的效率。
代码设计原则、方法及步骤 

1.代码设计原则    
（1）标准化、系统化
        标准化、系统化的代码具有适合计算机处理，便于实现，提高处理速度等优点。凡已制定了统一标准代码的，均应采用标准代码形式。
（2）惟一性：设计代码代表的实体或属性惟一。
（3）统一性、直观性、逻辑性        具备这些特点的代码便于记忆，且有助于减少错误。    
（4）可扩展性        既代码设计要预留足够位置，便于增加实体时，可直接在原代码系统中进行扩充，而不必改变原编码结构。    
（5）代码设计要在逻辑上能满足用户要求，在结构上与处理方法相一致。    
（6）简短性：避免使用易错字符、易混淆字符。　　
2.代码设计方法        
（1）顺序编码法 ：顺序编码法通常是将编码对象按一定顺序排列，然后对其依次编号，所得的编码为顺序码。例如，01表示数学系，02表示物理系，03表示哲学系
（2）重复编码法 ：这种方法直接采用编码对象原人工系统中的编号和编码对象的某种特征作为代码。    
（3）分组编码：分组编码法将数据项按一定顺序分组以表示不同类型，并以两个具有特定含义的码的组合来表示某一实体，例如，餐位号码：A座301。　　　　通常分组编码法都在每组留有备用码，以便扩充。    
（4）字母编码法　　
（5）按位编码法，按位编码法将编码的每一位表示一定的含义。使用此方法所得编码为区间码。     　　
（6）十进制编码法  　
（7）专用编码法  　
（8）组合编码法
3.代码设计步骤
  　（1）确定代码编制目的。
  　（2）确定编码对象，包括已在使用的代码对象。
  　（3）确定代码使用场合和使用期限。
  　（4）分析编码对象的使用要求。如使用频率、变更周期、输出要求等。
  　（5）确定具体编码方法，考虑是否采用检验位。
  　（6）针对每种代码编写代码设计书。
  　（7）将总代码设计书归类编写代码薄,并规定代码管理制度。
4、代码的功能
1·它为事物提供一个概要而不含糊的认定，便于数据的存储和检索。代 码缩短了事物的名称，无论是记录、记忆还是存储，都可以节省时间和空间。　
　　2，使用代码可以提高处理的效率和精度。按代码对事物进行排序、累计 或按某种规定算法进行统计分析，可以十分迅速。　　
　　3·代码提高了数据的全局一致性。这样，对同一事物，即使在不同场合 有不同的叫法，都可以通过编码统一起来，提高了系统的整体性，减少了因数 据不一致而造成的错误。
　　4·代码是人和计算机的共同语言，是两者交换信息的工具。 在手工处理系统中，许多数据如零件号、设备号、图号等早已使用代码。 为了给尚无代码的数据项编码，为了统一和改进原有代码，使之适应计算机处 理的要求，在建立新系统时，必须对整个系统进行代码设计。　　
　　现代化企业的编码系统已由简单的结构发展成为十分复杂的系统。为了有 效地推动计算机应用和防止标准化工作走弯路，我国十分重视制订统一编码标 准的问题，并己公布了GB2260-80中华人民共和国行政区划代码、GBl988- 80信息处理交换的七位编码字符集等一系列国家标准编码，在系统设计时要 认真查阅国家和部门已经颁布的各类标准。
5、注意的问题
l设计的代码在逻辑上必须能满足用户的需要，在结构上应当与处理的 方法相一致。例如，在设计用于统计的代码时，为了提高处理速度，往往使之 能够在不需调出有关数据文件的情况下，直接根据代码的结构进行统计。
　　2一个代码应惟一标志它所代表的事物或属性。
　　3代码设计时，要预留足够的位置，以适应不断变化的需要。否则，在 短时间内，随便改变编码结构对设计工作来说是一种严重浪费。一般来说，代愈短，分类、准备、存储和传送的开销愈低;代码愈长，对数据检索、统计 分析和满足多样化的处理要求就愈好。但编码太长，留空太多，多年用不上， 也是一种浪费。　　
　　 4代码要系统化，代码的编制应尽量标准化，尽量使代码结构对事物的 表示具有实际意义，以便于理解及交流。　　
　　 5要注意避免引起误解，不要使用易于混淆的字符。如0、2、1、S、V 与0、2、1、5、U易混;不要把空格作代码;要使用乃小时制表示时间等。　　
　　 6要注意尽量采用不易出错的代码结构，例如字母-字母-数字的结构 (如W吧)比字母一数字-字母的结构 (如W2W)发生错误的机会要少一些。
　　 7当代码长于4个字母或5个数字字符时，应分成小段。这样人们读写 时不易发生错误。如726一499一6135比7264996135易于记忆，并能更精确地 记录下来。
8若已知码的位数为p，每一位上可用字符数为Si，则可以组成码的总 数为: C=∏Si 例如，对每位字符为0-9的三位码，共可组成C=l0xl0xl0=1000种 码。
　　代码设计在系统分析阶段就应当开始。由于代码的编制需要仔细调查和多 方协调，是一项很费事的工作;需要经过一段时间，在系统设计阶段才能最后确定
本系统在综合各个实体及其之间的关系的基础上，决定采用的是顺序编码方法。具体的代码规则如下：

代码表
编号： 填表人： 填表日期：
编码对象
学生学号
代码种类
层次码
代码位数
8
代码结构
00 00 00 00
学院代码 入学年份 班级代码 班级内顺序号
检验位
无
备注

编号： 填表人： 填表日期：
编码对象
卡号
代码种类
层次码
代码位数
8
代码结构
00 00 0000
学校代码 学院代码 学生入学顺序
检验位
无
备注

编号： 填表人： 填表日期：
编码对象
管理员编号
代码种类
层次码
代码位数
7
代码结构
00 00 000
学校代码 工作年份 工作顺序
检验位
无
备注

3.2数据库设计
3.2.1概念结构设计
E-R图：

工资
联系方式
管理员编号
家庭住址
花费
办卡日期
姓名
性别
管理员
卡号
余额
饭卡
饭卡实体E-R图：

姓名

学生实体E-R图：

学生
学号
姓名
系别
班级
性别
联系方式
宿舍

管理员实体E-R图：
管理员
管理员编号
姓名
家庭住址
联系方式
性别
工资

消费情况E-R图：

消费情况
一楼窗口
二楼窗口
一天消费总额
日期
图3-3

3.2.2系统整体E-R图
由上面的分E-R图可以得到整体E-R图，如下图所示：

1
n
学生
个人消费情况
消费

n

1

持有
管理查询

1
1

1
n
饭卡
管理员

信息处理

3.2.3 将E-R图转换为关系模式
管理员
（管理员编号 姓名 性别 家庭住址 联系方式 工资）
管理查询
（管理员编号 日期）
消费情况
（日期 一楼窗口 二楼窗口 一天消费总额）
消费
（日期 卡号）
学生
（学号 系别 班级 姓名 性别 宿舍 联系方式）
使用
（卡号 学号）
饭卡
（卡号 余额 办卡日期 持卡者姓名 花费）
注册
（卡号 学号 姓名 班级 系别）
挂失
（卡号 学号 姓名 班级 系别）
补卡
（卡号 学号 姓名 班级 系别）
退卡
（卡号 学号 姓名 班级 系别）
充值
（卡号 学号 姓名 班级 系别）

3.3 导出数据库表
3.3.1创建管理员表Manager
表3-1 管理员表（Manager）
列名
数据类型
可否为空
说明
声明
Manager_number
varchar(6)
NOT NULL
管理员编号
主键
Manager_name
varchar(6)
NOT NULL
姓名

Manager_sex
Varchar(4)
NULL
性别

Manager_address
varchar(50)
NULL
家庭住址

Manager_tel
varchar(20)
NULL
联系方式

Income
int
NULL
工资

3.3.2创建消费情况表ConsumeSituation
表3-2 消费情况表（ConsumeSituation）
列名
数据类型
可否为空
说明
声明
data
datatime
NOT NULL
日期
主键
Total
bigint
NULL
一天消费总额

Floor_one
varchar(6)
NULL
一楼窗口

Floor_two
varchar(6)
NULL
二楼窗口

3.3.3创建学生表Student
表3-3 学生表（Student）
列名
数据类型
可否为空
说明
声明
S_number
varchar(6)
NOT NULL
学号
主键
S_name
varchar(10)
NOT NULL
姓名

S_sex
varchar(4)
NULL
性别

Class
varchar(20)
NULL
班级

S_system
varchar(16)
NULL
系别

S_dorm
varchar(20)
NULL
宿舍

S_tel
varchar(20)
NULL
联系方式

3.3.4创建饭卡表Card
表3-4 饭卡表（Card）
列名
数据类型
可否为空
说明
声明
Card number
Varchar（6）
NOT NULL
卡号
主键
Balance
varchar(6)
NOT NULL
余额

Card_date
datetime（8）
NULL
办卡日期

Person_name
varchar(10)

Does the Huan  Juan 嶅 hook Chen?NULL
持卡者姓名

The Xiang 戠偣 Qi ℃伅Consume
varchar(20)
NULL

The Bi 勯噾 Huan 幆花费

The 鏀 Duo Chuai Cong plank 綍

Does the 鍐 go crazy 棌鍖 ?

The 鎸佹湁 Xi 撳簱3.3.5管理查询表Manage

The Ma 涘嚭鍙ｅ晢鍝佹 Nan?表3-5 管理查询表（Manage）

The 鐗╄祫鍚堢悊 Xian 佸悜列名
数据类型
可否为空
说明
Manager_number
varchar(6)
NOT NULL
管理员编号

The 鍔 hurtles the 姩鍔涘啀鐢熶 HaiDate

The strand у搧鍥炲datetime
NOT NULL
日期

3.3.6创建使用表Use
表3-6 使用表（Use）
列名
数据类型
可否为空
说明
S_number
varchar(8)
NOT NULL
学号
Card_number
varchar(6)
NOT NULL
卡号

3.3.7创建注册表R1
表3-7 注册表(R1)
列名
数据类型
可否为空
说明
声明
Card_number
varchar(6)
NOT NULL
卡号
主键
S_number
varchar(8)
NOT NULL
学号

S_name
varchar(10)
NOT NULL
姓名

S_sex
varchar(4)
NULL
性别

Class
varchar(20)
NULL
班级

Money
int
NULL
金额

3.3.8创建挂失表R2
表3-8 挂失表（R2）
列名
数据类型
可否为空
说明
声明
Card_number
varchar(6)
NOT NULL
卡号
主键
S_number
varchar(8)
NOT NULL
学号

S_name
varchar(10)
NOT NULL
姓名

S_sex
varchar(4)
NULL
性别

Class
varchar(20)
NULL
班级

Money
int
NULL
余额

3.3.9创建退卡表R3
表3-9 退卡表（R3）
列名
数据类型
可否为空
说明
声明
Card_number
varchar(6)
NOT NULL
卡号
主键
S_number
varchar(8)
NOT NULL
学号

S_name
varchar(10)
NOT NULL
姓名

S_sex
varchar(4)
NULL
性别

Class
varchar(20)
NULL
班级

Money
int
NULL
余额

3.3.10 创建补卡表R4
表3-10 补卡表（R4）
列名
数据类型
可否为空
说明
声明
Card_number
varchar(6)
NOT NULL
卡号
主键
S_number
varchar(8)
NOT NULL
学号

S_name
varchar(10)
NOT NULL
姓名

S_sex
varchar(4)
NULL
性别

Class
varchar(20)
NULL
班级

3.3.11 创建充值表R5
表3-11 充值表（R5）
列名
数据类型
可否为空
说明
声明
Card_number
varchar(6)
NOT NULL
卡号
主键
S_number
varchar(8)
NOT NULL
学号

S_name
varchar(10)
NOT NULL
姓名

S_sex
varchar(4)
NULL
性别

Class
varchar(20)
NULL
班级

Money
int
NULL
余额

3.4用户子模式设计
前面我们根据用户需求设计了局部应用视图，这种局部应用视图只是概念模型，用E-R图表示。在我们将概念模型转换为逻辑模型后，即生成了整个应用系统的模式后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。
目前关系数据库管理系统一般都提供了视图概念，支持用户的虚拟视图。我们可以利用这一功能设计更符合局部用户需要的用户外模式。 　　
定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。由于用户外模式与模式是独立的，因此我们在定义用户外模式时应该更注重考虑用户的习惯与方便。
包括：
(1) 使用更符合用户习惯的别名
(2) 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。
(3) 简化用户对系统的使用

l 学生查询信息所建立的视图

学生查询自己卡中余额

学生查询视图S_Balance

管理员查询学生信息

查询学生的信息

3.5人机对话设计
基本概念：
人机对话设计的基本原则是为用户操作着想，而不应该从设计人员设计劣来考虑。因此，对话设计应注意以下几点：
(1)可使用性：对话要清楚、简单，用词要符合用户观点和习惯；所有的用术语要标准化、一致化；有帮助功能等。
(2)灵活性：对话要适应不同操作水平的用户，便于维护和修改。这是衡