电影院售票系统
挺有意思的，我自己也试着做了一做，感觉还是有不少收获的。在本文中我想把做这道题的整个思路重新理一下，也算做个整理了。
现在能得到的需求只有一个：设计一个电影院票务管理系统的表结构。再没有其他信息了，可能真的面试的时候面试官还会给出其他业务需求，但我这里没有。
所以我只能猜测可能的业务需求会有哪些。
最初想到的：
1. 电影院会有多个播放厅，从而在同一时间播放不同的电影来满足客户需求
2. 每个厅的大小可能不同，即容纳的人数不同
3. 电影院会不断引进新片
4. 电影院会把电影安排在各个播放厅的不同时间段来进行播放，即会有一个排片表
5. 一个客户可能买一张或多张电影票，这些电影票可能会是不同厅，不同场次的电影
对于以上的需求设计中应该会有一张存放电影的表（Table_Movie），一张存放影院各个厅信息的表（Table_Hall）。
还应有一张排片表，其中会包含两个外键分别指向Table_Movie的主键和Table_Hall的主键，还有时间、价格等信息。
对于用户买票的需求，使用经典ERP订单结构来设计就行了，即会有Table_orderHead，Table_OrderDetail表。
简单表关系图如下：
这一设计需要注意的有两点：
1. 票价信息存储在Table_Schedule中（Schedule_Price列），即影片在不同时间段和不同厅中播放票价可以不同。
2. Table_OrderDetail中有外键Schedule_ID指向Table_Schedule。
加入会员信息
如上设计已满足最初提出的5点需求。但这样的电影院无法办会员卡，也就没法打折了。为了与其他影院竞争提供会员卡功能，即：
6. 影院应提供会员卡功能，根据会员卡的等级，给予不同的折扣
对于这一需求加入一张会员信息表Table_Customer显得很自然，同时为了能根据不同等级给予不同的折扣，需要再加一张等级表Table_Class
简单表关系图如下：
需要注意的是：
1. Table_Customer中外键Class_ID指向Table_Class
2. 我给Table_Class加了一个Class_IsActive列，当一个会员等级无效时只要置标签，而无需做删除操作
3. Table_OrderHead中加了一列Customer_ID，我把该列的默认值设为-1。当非会员顾客买票时，改列值即为-1，当会员买票时，该列值为在Table_Customer中对应的Customer_ID
4. Table_OrderDetail中加了一列OrderDetail_AdjustedPrice，该列可以不加，出于方便的考虑，我还是加了此列。对于会员该列值为原票价打折后的值，即Schedule_Price * Class_Discount，对于非会员该列为原票价
再进一步思考
以上做的设计作为面试题的解答，应该差不多了，所有前面提到的6点需求已满足。
但这是否真的满足实际影院的需求呢？
我的答案是否定的，其中有一个很致命的缺陷，我们的设计中没有包含座位号。
系统出的票只知道什么时间，哪个厅，什么电影，但没有座位号，顾客只能去抢位子了。
那我们再加一条需求：
7. 顾客可以在买票时选择座位
对于这一需求，我们直接来看表关系图
如上设计增加了Table_Seat和Table_OrderSeat两张表，改动比较小。
需要注意的有：
1. Table_Seat中的外键Hall_ID指向Table_Hall
2. Table_Seat中除包含座位的排数（Seat_Row）和列数（Seat_Column）外，还包含Seat_IsActive列来表示此座位是否可用，如果座位坏了，这个位子的票就不应该卖
3. Table_OrderSeat中OrderDetail_ID，Seat_ID为联合主键，同时OrderDetail_ID为外键指向Table_OrderDetail的OrderDetail_ID列
4. Table_OrderDetail中的OrderDetail_Qty列被删除了，从Table_OrderSeat中可以计算此值
最后给出如下影院票务管理系统的表关系图
以上的设计是否易用？
首先想一下订票最简单的过程，不包括意外情况。
- 顾客先来到柜台，跟柜台服务员说要买哪场电影的哪几个空位的票
- 服务员创建一个订单（在Table_OrderHead中插入一条记录）
- 若顾客为会员，刷会员卡（Update Table_OrderHead中的Customer_ID的值）
- 服务员选择顾客指定场次的多个位子
- 服务员点击出票（在Table_OrderDetail和Table_OrderSeat中插入相应记录）
- 若顾客还需要买其他场次的电影，重复步骤4～5
想了一下这个过程，我自己感觉步骤1比较累赘，服务员每次都需要创建一个空订单头，之后才真正开始选位出票，比较麻烦。
而且如果在选位子之前，顾客突然决定不看电影了，服务员必须把前面创建的订单头删除，否则会在系统中留下孤立的OrderHead记录，会破坏数据完整性。
同时想到平日自己去电影院买票时，服务员都是直接选位子出票的，所以我们修改设计如下：
现在系统的订票流程如下：
- 顾客先来到柜台，跟柜台服务员说要买哪场电影的哪几个空位的票
- 服务员选择顾客指定场次的多个位子
- 若顾客为会员，刷会员卡
- 服务员点击出票
- 若顾客还需要买其他场次的电影，重复步骤2～4
这个流程去除了每次服务员创建订单的动作，简化了最一般的情况，即顾客买某场电影的多张票。但若顾客要买多场电影的票时，需要多次刷会员卡，这里变麻烦了但这种情况不多，我觉得这更符合影院的实际需求。
统计一下票房收入
统计某段时间内，某部电影总共销售收入应该是比较常见的需求，我们用T-sql来实现这一需求。
输入：电影ID（@MovieID），起始时间（@StartDate），终止时间（@EndDate）
输出：总票房收入（@TotalBoxOffice）
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
|
相关阅读
1.概念数据库设计就是根据业务系统的具体需求，结合我们所选用的DBMS（数据库管理系统），为这个业务系统构造出最优的数据存储模型。并建
关联映射：一对一 一对一关系就如球队与球队所在地址之间的关系，一支球队仅有一个地址，而一个地址区也仅有一支球队。数据表间一对一
原文地址：http://blog.csdn.net/hnkontecna/article/details/61672983标签 PostgreSQL , 12306 , 春节 , 一票难求 , 门禁广告 ,
G.1 引言 G.1.1 编写目的 数据库的表结构设计是整个项目开发中一个非常重要的环节,一个良好的数据库设计，可以提高开发效率，方便
大家都应该在电影院看过3D电影吧，超大屏幕配上3D眼睛，看电影带来一种超强的沉浸感。有些人问，这种沉浸感，我们能在家里实现吗？能不能买