电影院票务管理系统数据库设计
这两天听到一道面试题:设计一个电影院票务管理系统的表结构。
挺有意思的,我自己也试着做了一做,感觉还是有不少收获的。在本文中我想把做这道题的整个思路重新理一下,也算做个整理了。
现在能得到的需求只有一个:设计一个电影院票务管理系统的表结构。再没有其他信息了,可能真的面试的时候面试官还会给出其他业务需求,但我这里没有。
所以我只能猜测可能的业务需求会有哪些。
最初想到的:
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
|
if object_id(N
'Proc_GetBoxOffice'
)
is
not
null
begin
drop
procedure
dbo.Proc_GetBoxOffice;
end
go
create
procedure
dbo.Proc_GetBoxOffice
@MovieID
int
,
@StartDate datetime,
@EndDate datetime,
@TotalBoxOffice money
output
as
if @MovieID
is
null
begin
raiserror(
'@MovieID is null in Proc_GetBoxOffice'
, 16, 1);
end
if @StartDate
is
null
begin
raiserror(
'@StartDate is null in Proc_GetBoxOffice'
, 16, 1);
end
if @EndDate
is
null
begin
raiserror(
'@EndDate is null in Proc_GetBoxOffice'
, 16, 1);
end
推荐阅读
|