在线订餐系统的ER图与逻辑图

作业题目：网上订餐数据库系统设计 作业时间：2012年11月 专业班级：XXXXXXXXXXXXXXXXX 姓名： 学号： 授课教师：

目录

第七章报告总结 ......................................................................................... 18

第一章需求分析

1.1订餐现状分析

现在普遍使用的订餐方式是进行电话预定，这种预订方式方便，错误率也比较低，但是由此引发的一些不良现象也比较多，主要是订餐后出现饭店并没有将信息记录在案，而且电话里不能看到菜品的图片，对菜量和菜品样式没有直观的概念。另外这种订餐方式只是进行电话的预约，很可能会出现订餐但是不履行订单也不进行订餐取消的现象，订餐人员对订购的餐桌信息不太了解会进行相关信息的询问，这样就在一定程度上造成了时间的浪费，饭店人员会在同一天反复重复相同的信息，造成了人力资源的浪费。

这样开发出图文并茂，信息能够及时更新和查看的在线网上订餐系统就具有了重要的意义。

1.2顾客需求分析

顾客模块的功能包括个人信息管理，美食选购，美食评价三大功能。其中，在个人信息管理中可以对个人信息进行修改、还可以查阅以往订过的美食信息；在选购美食中可以通过购物车直接购买的形式、也可已选择货到付款的形式完成交易；美食评价中顾客可以这对这次服务质量，留下自己相对餐厅说的话，完成用户与餐厅之间的交互。 1.3管理员需求分析

管理员模块的功能包括菜品管理，订单管理，会员信息管理三大功能。其中，在个菜品管理中可以对菜品信息进行添加、修改和查询操作；在订单管理中可以通过未确认、已确认、已下单三种形式进行管理、也可查看所有订单信息；会员信息管理中，可以添加会员信息和修改会员信息，进而方便顾客网上订购美食，并享有优惠，这一做法人性化的完成网站的推广，避免了顾客的抵触情绪。 1.4性能需求分析

该系统在性能功能上应达到如下需求：

 操作简单、界面友好:完全控件式的页面布局，使得菜品，资讯，座位等信息的录入工

作更简便，许多选项包括餐厅信息，桌位，包房信息等只需要点击鼠标就可以完成；另外，跟踪出现的提示信息也让用户随时清楚自己的操作情况。对常见的类似网站的管理的各个方面：基本信息录入、浏览、删除、修改、搜索等方面都大体实现，顾客对菜品的预定及支付方式；

 即时可见:对客户预定餐饮信息的处理（包括录入、删除）将立即在主页的对应栏目显

示出来，达到“即时发布、即时见效”的功能；  系统运行应该快速、稳定、高效和可靠；

 在结构上应具有很好的可扩展性，便于将来的功能扩展和维护。 1.5可行性分析

随着经济的快速发展，B2C电子商务越来越受到人们的关注。网上订餐类网站，已经如雨后春笋般的出现在了个大城市。特别在公司，企业内部，团体订餐已经成为了趋势。

同时，随着全国人民的精神、物质和文化生活高度的提高，人们已经不在仅仅停留在吃饱的程度，不但要吃饱，还要吃好，而且口味也越来越挑刺，正因为如此网络订餐业务的出现，正迎合了这些人的口味，他们不但省去了自己做饭的麻烦，而且也能寻找和发现新的菜品，品尝不同风格的菜品，网络订餐业务在中国有着极大的发展空间以及良好的背景。而当代大学生，白领工作人士作为社会中的重要群体，他们对饮食的要求都在不断提高,饮食在他们生活中起着重要作用。因此，面向大学生和都市白领人士的网络订餐网站的设计有着良好的现实意义。 1.6总体设计原则

1、开放性、可扩充性、可靠性原则

开放系统是生产各种计算机产品普遍遵循的原则，遵循这种标准的产品都符合一些公共的、可以相互操作的标准，能够融洽的在一起工作。开放系统使得各种类型的网络和系统互连简单、标准统一，容易扩展升级。从而适应广大用户需求的多变性和产品的更新换代。

2、良好的用户操作界面

用户操作界面美观、方便、实用，使用户能在较短的时间内掌握其使用方法。

3、实用性原则

任何系统的设计都要考虑其实用性，系统开发的目的是为了实现业务处理自动化、规范化，提高工作效率，减轻工作人员的劳动强度，减少开支。

4、工作平台设计原则

能适应不同的操作平台，不同的网络。

第二章概念结构设计阶段

2.1系统E-R图

通过上面的介绍，我们已近基本的实体有管理员、用户、订单和菜谱。实体之间有一个管理员可以有拥有多个用户、多个菜谱的管理关系，因此管理员与用户之间和菜单之间都是一对多的联系；一个用户只能属于管理员，因此用户与管理员是多对一的联系；一个订单只属于一个用户，但可以拥有多个菜谱，因此订单与菜谱的关系是一对多的联系。

据此分析，得到系统的ER图如图2-1所示。 图2-1网上订餐系统E-R图 2.2数据流图密 手机姓名 登录注册时图2-2订餐系统网上订餐数据流图 管理员用户编名2.3数据字典 2.3.1数据项 最后登录数据项含义说明 M 管理 用户的唯一标识 用户登陆时的名称 用户登陆时的密码 用户的真实姓名 用户的性别 用户的联系电话 1 生用户的联系电话 数据类型 用户 int char char 下单 char char char 订单 char 地长度 17 17 20 2 40 数据项编号 数据项名 管理员 DI-0 DI-1 DI-2 DI-3 管DI-4 DI-5 DI-6 菜系 用户编号 用户名 用户密码 用户姓名 用户性别 用户手机 用户固定电话 原DI-7 用户地址 40 地址 订单状用户的送货地址 char 图DI-8 DI-9 优惠DI-10 DI-11 编号菜用户邮箱 用户的个人邮箱会员编 创 建时用户的真实年龄 用户年龄订单编菜名的介用户生日 餐馆编号 100 备注 char 50 总金int 下单时 用户的出生日期订 单改date 变餐馆的唯一标识 int 数据项编号 数据项名 DI-12 DI-13 DI-14 DI-15 DI-16 DI-17 DI-18 餐馆名称 餐馆地址 餐馆电话 餐馆联系人 菜品编号 菜名名称 菜品类别 菜品类别编DI-19 号 DI-20 DI-21 DI-22 DI-23 DI-24 DI-25 DI-26 DI-27 DI-28 DI-29 DI-30 DI-31 菜品价格 菜品折扣 菜品份数 订单编号 订单日期 订单总额 送餐编号 送餐地址 送餐日期 送餐员名称 送餐员电话 省份编号 数据项含义说明 餐馆的全称 餐馆的详细地址 餐馆的联系电话 餐馆联系人的姓名 菜品的唯一标识 菜品的名称 数据类型 char char char char int char 长度 50 100 40 20 40 20 菜品所属的类别名称 char 菜品类别的唯一标识 int 菜品的单价 菜品的折扣率 菜品的份数 订单的唯一标识 订单产生的日期 float float int int date 100 20 40 订单所有菜品的总额 float 送餐的唯一标识 送餐的详细地址 送餐的日期 送餐员的真实姓名 送餐员的联系电话 省份的唯一标识 int char date char char int 数据项编号 数据项名 DI-32 DI-33 DI-34 2.3.2数据结构 数据项含义说明 省份的名称 城市的唯一标识 城市的名称 数据类型 char int char 长度 20 20 省份名称 城市编号 城市名称 数据结构编数据结构名 号 DS-1 Class 含义说明 组成 菜品分类信DI-18，DI-19 息 DS-2 DS-3 DS-4 DS-5 User Restaurant Meal Order 用户信息 餐馆信息 菜品信息 订单信息 DI-0至DI-10 DI-11至DI-15 DI-16至DI-22 DI-23、DI-24、DI-25、DI-27、DI-0 DS-6 DeliveryNote 送餐信息 DI-26至DI-30，DI-1、DI-14、DI-15 2.3.3处理过程 处理过程编处理过程说明 号 名 成功：跳转注册成功所有用用户详细信P-1 注册 户 息 败信息 失败：重新信息或失面 到登陆页输入 输出 处理 处理过程编处理过程说明 号 名 注册 输入 输出 处理 成功：跳转登陆成功所有用用户名和密P-2 登录 户 码 败信息 登陆 原用户名、已经登新的用户修改成功修改数据P-3 修改账号 陆的用名、确认新或失败信库信息 户 用户名、密息 码 原来的密已经登码、新的密P-4 修改密码 陆的用码、确认新户 密码 新的收货地已经登修改常用P-5 收货信息 户 式 陆的用新的联系方址、 库信息 修改数据息 或失败信库信息 修改成功修改数据信息或失失败：重新到首页 处理过程编处理过程说明 号 名 已经登添加收获P-6 信息 户 已经登修改用户P-7 信息 户 将用户所添加到购所有用P-8 物车 户 添加到购物车 修改购物所有用P-9 车 户 车信息 根据购物已登录P-10 下订单 用户 信息自动生成订单 查看并确已登录P-11 认订单 用户 已登录P-12 提交订单 用户 信息 库信息 订餐成功修改数据 车和用户修改购物选的菜品陆的用用户信息 库信息 修改数据陆的用息 新的收货信 库信息 修改数据输入 输出 处理 处理过程编处理过程说明 号 名 将订单信客服人P-13 接收订单 员 相关工作人员 所有用要检索的内检索信息P-14 信息检索 户 容 内容 修改数据 用户 P-16 系统维护 管理员 息 需要更新的P-17 信息更新 管理员 信息 库信息 库信息 修改数据 息传送给输入 输出 处理 已登录要发布的信P-15 发布信息 用户投诉已登录投诉/评价投诉/评价修改数据P-18 与评价 的用户 内容 内容 库信息 第三章数据库逻辑结构设计阶段

3.1数据库逻辑模式初步构思

根据ER图转换成基本表的思想，即每个实体转换成基本表，而1对多的联系根据实际需要可以转换或不转换为基本表，按照图2-1所示的ER图，该系统的基本表应为5个，分别为：

表3-1管理员表

管理员编号 姓名 密码 登陆IP 最后登录时间 主码 表3-2用户表 用户编号 姓名 地址 手机 注册时间 主码 表3-3订单表 订单编号 手机号 地址 总金额 下单时间 订单状态 订单改变时间 备注 会员编号 表3-4菜谱表

外码 主码 编号 菜名 原价 优惠价 菜名的介绍 图片 创建时间 主码 表3-5订单项表 订单项编号 订单编号 姓名 状态 主码 3.2具体逻辑模式设计

表的具体结构

表名 字段名 菜谱编号 菜名 原价 字段类型 10个字符 20个字符 20个字符 20个字符 50个字符 10个字符 10个字符 10个字符 50个字符 20个字符 10个字符 10个字符 10个字符 10个字符 20个字符 关键字 是 是 是 约束说明 不允许空值 菜谱信息 优惠价 菜名介绍 图片 创建时间 用户编号 姓名 用户信息 地址 手机 注册时间 管理员编号 姓名 管理员密码 管理员信息 登录IP 最后登录时10个字符 间 订单编号 订单信息 手机号 地址 15个字符 20个字符 20个字符 是 总金额 下单时间 订单状态 订单改变时间 备注 会员编号 10个字符 10个字符 10个字符 10个字符 50个字符 10个字符 参照用户信息表的用户编号，不允许空值 订单项编号 订单编号 订单项信息 姓名 状态 10个字符 15个字符 是 参照订单信息表的订单编号，不允许空值 10个字符 10个字符 第四章数据库的物理结构设计

4.1设计表间关系

在网上订餐系统中，存在着参照关系和被参照关系。

用户信息表参照关系 外部关键字 用户编号 姓名 主关键字 订单信息表被参照关系 萍 地址 手机 注册时间 王丽山东济 南 李杜江西南 娟 昌 黄大广东佛 洲 山 张子湖南长 将 沙 订单编用户编号 地址 号 总金下单时订单状订单手机 额 间 态 改变时间 备注 山东济28.0南 0 122311:23 122314:42 122315:33 等待付 款 货到付 款 已付款 江西南42.0昌 0 广东佛13.0山 0 湖南长25.0沙 0 122317:52 货到付 款 图4-1参照关系与被参照关系

4.2完整性设计

关系模型的完整性约束包括实体完整性、参照完整性和用户定义完整性。主要字段完整性的字段名、完整性约束条件指的是实体完整性。其中实体完整性的规则如下：

1． 实体完整性规则是针对关系而言的，而关系则对应一个现实世界中的实体集。

2． 现实世界中的实体是可区分的，它们具有某种标识特征；相应地，关系中的元组也是可区分的，在关系中用主关键字作唯一性标识。 3． 主关键字中的属性，即主属性不能取空值。

在网上订餐系统中，管理员表（管理员编号，名称，密码，登陆IP，最后登录时间）中，管理员编号是主关键字，不可以取空值；用户表（用户编号，姓名，地址，手机，注册时间）中，用户编号是主关键字，不可以取空值；订单表（订单编号，手机号，地址，总金额，下单时间，订单状态，订单改变时间，备注，会员编号）中，订单编号是主关键字，不可以取空值；菜谱表（菜谱编号，菜名，原价，优惠价，菜名的介绍,图片，创建时间）中，菜谱编号是主关键字，不可以取空值；订单项表（订单项编号，订单编号，姓名，状态）中，订单项编号是主关键字，不可以取空值。

除了实体完整性之外还有其他与应用密切相关的数据完整性约束，例如某个属性的值必须唯一，某个属性的取值必须在某个范围内，某些属性值之间应该满足一定的函数关系等。类似这些方面的约束不是关系数据模型本身所要求的，而是为了

满足应用方面的语义要求提出来的，这些完整性需求需要用户来定义，所以称为用户定义完整性。数据库管理系统需提供定义这些数据完整性的功能和手段，以便统一进行处理和检查，而不是由应用程序去实现这些功能。

在用户定义完整性中最常见的是限定属性的取值范围，即对值域的约束，这包括说明属性的数据类型、精度、取值范围、是否允许空值等。在网上订餐系统中，订单信息表中的订单编号不允许为空值，用户表中的用户编号为唯一值都是用了用户定义完整性约束。

现实世界中的实体之间存在着某种联系，而在关系模型中实体是用关系描述的，实体之间的联系也是用关系描述的，这样就自然存在着关系和关系之间的参照或引用户编号 n：n 订单信息表 n:n 订单项编号 订单编号 姓名 状态

订单项信息表

图4-2说明关联和参照关 订单编号 姓名 地址 手机 注册时间 手机号 地址 用。网上订餐系统参照完整性表如下： 用户信息表 总金额 下单时间 订单状态 用户编号 第五章 数据库系统的实现

5.1数据库的建立

启动服务管理器，打开查询分析器，在调试程序窗口输入下列语句：

Createdatabase网上订餐系统 On

（name=网上订餐系统_dat,

Filename='d:\\programfiles\\lzysql\\网上订餐系统_dat.mdf', Size=5mb Maxsize=100mb, Filegrowth=5mb) Logon

(name=网上订餐系统_log,

Filename='d:\\programfiles\\lzysql\\网上订餐系统_log.ldf', Size=5mb Maxsize=100mb, Filegrowth=5mb) 5.2数据载入

在网上订餐系统数据库中分别新建菜谱信息表、用户信息表、管理员信息表、订单信息表、订单项信息表，再陆续载入数据： 菜谱信息表的数据: 用户信息表的数据: 管理员信息表的数据 订单信息表的数据： 订单项信息表的数据：

第六章 数据库系统的运行和维护

作为网管员，无论其管理的网络的规模是大还是小，在日常的管理中除了维护网络平稳运行、及时排除网络故障、保护网络安全等工作以外，备份网络中关键数据也是其中的一个非常非常重要的工作环节。

网络中的各种故障无非就分两种:软件故障和硬件故障。对于“硬件故障”可以通过维修或更换硬件设备得到及时解决;对于“软件故障”则可以通过重新安装或升级软件、重做网络或应用软件系统等方法及时解决，而且用此方法来解决网络故障大多需要一些基础的、关键的数据支持才能得以恢复正常。但是，网络中诸如此类的关键数据(特别是“应用软件系统”中的关键数据)的损坏或丢失，绝大部分是无法恢复和弥补的。

6.1定义并设置备份策略：

1.每周1次完全备份，周日晚0点。超过4周清空之前的备份。 2.每天1次差异备份，每天0点。超过1周清空之前的备份。 3.每2小时一次日志备份，超过1天清空之前的备份。

6.2启用维护计划任务

在“管理”－>“数据库维护计划”上右键弹出菜单，选“新建维护计划”。如图6-2-1所示。设置数据库维护计划名，并完成向导如图6-2-2所示。

图6-2-1新建数据库维护计划 图6-2-2完成建数据库维护计划

第七章 报告总结

实践出真知。这句话说得一点也没错，在整个数据库课程设计过程中，只有实践才能对事物的本质有更深的认识，才能有发言权，一切认识都是建立在认识的基础上。通过了一个星期的数据课程设计，我对数据库这门课程有了更深的认识，对原本在我脑中像是火星语的SQL语言有了更加具体的认识。

数据库课程设计加深了我对数据库这门课程的兴趣，让我深刻了解了数据库的强大功能，引起我对研究SQL语言运用规则的兴趣。数据库概念设计、数据库逻辑结构设计和数据库保护设计是数据库设计的重要步骤，每一步的设计都是至关重要的，并且是相互联系的。经过一个星期的课程设计，让我对E-R图的设计有一个整体的想法，并且对逻辑结构设计中关键字的设定能够很好的把握，分析每个表中的联系，更加注意表间和数据之间的相互约束。课程设计一个重要的过程就是在SeverSQL2000上操作运行，这是运用实践去检验认识的一个过程，在这个过程中我学会了灵活运用SQL语言。总之，数据库课程设计一个很好地运用实践去发现认识的过程。

数据库课程设计不仅让我更进一步了解了数据库这门课程，而且让我在做事方面也形成了一套很好的想法。我在做事方面学会了坚持、合作、对待问题不断充满疑问和要有耐心去解决问题，更要和同学们交流，对不懂的问题也不耻下问。从课程设计中最深的还是做事要坚持和要有耐心。在运用ServerSQL2000设计数据库的过程中，会不断遇到种种问题，而且每个问题都会与上下步骤之间都会有联系，一个问题的不解可能会导致下一个问题的无法操作，所以我们要有耐心找出问题，分析原因，然后再解决问题，不要半途而废，要坚持下去，这样才能在学习上有所突破。

数据库课程设计目的在于通过对一个实际问题的分析，设计与实现，将原理与应用相结合，使学生学会如何把书本上学到的知识用于解决实际问题，培养学生的动手能力，使学生能深入理解和灵活掌握教学内容：另一方面，可以很好培养学生的处事能力。

总之，虽然在备战期末考试期间，为了做这个课程设计花了很多的时间，却让我感受到了要将书上的理论应用到实践绝对不只是停滞在课堂上的。一次实践可以让我看到自己的欠缺，同时也巩固了课堂上掌握的知识点。