电影院票务管理系统的数据库设计 (1)
这两天听到一道面试题:设计一个电影院票务管理系统的表结构。
挺有意思的,我自己也试着做了一做,感觉还是有不少收获的。在本文中我想把做这道题的整个思路重新理一下,也算做个整理了。
现在能得到的需求只有一个:设计一个电影院票务管理系统的表结构。再没有其他信息了,可能真的面试的时候面试官还会给出其他业务需求,但我这里没有。
所以我只能猜测可能的业务需求会有哪些。
最初想到的:
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中可以计算此值
--后面的内容还比较多,单独分出一篇“电影院票务管理系统数据库设计(2)”
推荐阅读
-
什么是数据库事物?为什么需要数据库事物,事物有哪些特征?事物的隔离级别是什么?-1.什么是数据库事务? 1.事务是作为一个逻辑单元执行的一系列操作。一个逻辑工作单元必须具备四个属性,即ACID(原子性、一致性、隔离性和持久性)属性,只有这样才能成为事务: 原子性 2.事务必须是一个原子工作单元;它的数据修改要么全部执行,要么全部不执行。 一致性 3.事务完成时,所有数据必须保持一致。在相关数据库中,所有规则都必须适用于事务的修改,以保持所有数据的完整性。事务结束时,所有内部数据结构(如 B 树索引或双向链接表)必须正确无误。 隔离 4.并发事务的修改必须与其他并发事务的修改隔离。一个事务会在另一个并发事务修改之前或之后查看某一状态下的数据,而不会查看中间状态下的数据。这就是所谓的可序列化,因为它允许重新加载起始数据和重放一系列事务,从而使数据最终处于与原始事务执行时相同的状态。 持久性 5.事务完成后,它对系统的影响是永久性的。即使在系统发生故障的情况下,修改也会保留。 2. 为什么需要数据库事物,事物有哪些特征? 事物对数据库的作用是对数据进行一系列操作,要么全部成功,要么全部失败,防止出现中间状态,确保数据库中的数据始终处于正确、和谐的状态。 特征:原子性、一致性、隔离性、持久性,以及其他特征 原子性(Atomicity):所有操作在事务开始后,要么全部做完,要么全部不做,不可能停滞在中间环节。事务执行过程中出现错误时,会回滚到事务开始前的状态,所有操作就像没有发生一样。也就是说,事务是一个不可分割的整体,就像化学中的原子一样,是物质的基本单位。 一致性(Consistency):在事务开始之前和结束之后,数据库的完整性约束都没有被破坏。例如,如果 A 转钱给 B,A 不可能扣除这笔钱,但 B 却没有收到这笔钱。 隔离:在同一时间内,只允许一个事务请求相同的数据,不同事务之间没有干扰。例如,甲正在从一张银行卡上取款,在甲取款过程结束之前,乙不能向这张卡转账。 持久性(耐用性):事务完成后,事务对数据库的所有更新都将保存到数据库中,无法回滚 3.事务的隔离级别有哪些? 数据库事务有四种隔离级别,从低到高分别是未提交读取(Read uncommitted)、已提交读取(Read committed)、可重复读取(Repeatable read)、可序列化(Serializable)。此外,事务的并发操作中可能会出现脏读、不可重复读、幽灵读等情况。事务并发问题 脏读:事务 A 读取事务 B 更新的数据,然后事务 B 回滚操作,那么事务 A 读取的数据就是脏数据。 不可重复读取:事务 A 多次读取同一数据,事务 B 在事务 A 多次读取期间更新并提交数据,导致事务 A 多次读取同一数据时结果不一致。 幻影读取:系统管理员 A 将数据库中所有学生的具体分数改为 ABCDE 等级,但系统管理员 B 在此时插入了具体分数的记录,当系统管理员 A 更改结束后发现仍有一条记录未被更改,仿佛发生了幻觉,这称为幻影读取。 小结:不可重复读和幻读容易混淆,不可重复读侧重于修改,幻读侧重于增删。解决不可重复读问题只需锁定满足条件的行,解决幻读问题则需要锁定表 MySQL 事务隔离级别
-
电影院票务管理系统数据库设计
-
影院票务和管理系统的设计与实施--附源代码 011449-第 5 章 系统实施
-
26 基于 Java 的电影院票务管理系统设计
-
电影院票务管理系统的数据库设计 (1)
-
基于 Springboot + vue 的电影院管理系统(Java 毕业设计)
-
基于 NFC 的无线电池管理 BMS - ● 主动读取内部传感器:利用 NFC 技术,BMS 能够主动读取内部传感器的数据 [... 考虑车辆外使用案例中的空闲状态场景:NFC 技术可用于处理闲置状态下的电池组读取,例如在第二次生命转移期间进行存储。 主动诊断读取:在邻近系统中部署了 BMS 的情况下,使用 NFC 技术进行主动诊断读取。 (ii) 系统结构 系统架构如图所示,在建立安全通道之前,需要对设备进行身份验证。数据链路通信层由 NDEF 记录处理,而数据存储可以是离线的,也可以是数据库中的在线存储。活动和空闲状态的诊断读数取决于设备和数据方向,需要与外部 NFC 阅读器进行通信。软件架构分为三层,包括硬件抽象层(HAL)、中间层(中间件)和应用层。HAL 处理硬件驱动组件,中间件执行设备验证,而应用层则由开发人员根据安全漏洞和格式扩展*定义。 为确保安全,系统采用了一个安全模型,为 BMS 和主动诊断读取情况格式化应用数据。安全考虑因素包括设备相互验证、使用安全通道(加密和防篡改)以及确保电池组内读数的安全。 考虑到不同的 BMS 拓扑,包括集中式、调制式、分布式和分散式,系统需要满足设备相互验证和使用安全通道的要求。对于每种拓扑结构,都必须考虑将性能开销降至最低。电池是封闭的,对其进行物理攻击不可行或成本太高。外部攻击可能也很困难。基于对称或非对称加密技术的自动验证可用于保护电池组读数。安全协议在验证阶段和会话密钥确认阶段采用双密钥加密,以抵御攻击。中间件在数据格式验证、确认和处理中发挥关键作用,确保数据传输安全。 (iii) 唤醒模型设计
-
个人健身和教练预约管理系统的设计与实施 | SpringBoot + Mysql + Java + B / S 结构(可运行源代码 + 数据库 + 设计文档)
-
[条目 29] 基于 OpenGauss 数据库设计人力资源管理系统的实验
-
数据库系统原理 - (7, 8) 数据库应用设计与开发实例 + 数据管理技术的发展