基于Python实现LOOK电影管理系统

LOOK电影管理系统

注：数据库需要根据1.3数据元素表自行创建

一、需求分析

1.1 需求描述

本项目（LOOK电影管理系统）借鉴了豆瓣网、时光网等传统网站，并结合创新操作，建立起一个多功能的电影网站。它需要包括以下基本功能：

1.1.1 个人信息修改及查看

用户注册并登陆后，可以在个人主页更改自己的昵称、性别、邮箱、电话等基本信息，支持用户自定义头像上传并保存，支持用户选择偏好的电影类型，可查看已收藏的电影、参加的粉丝团，可以选择注销以退出登陆。

1.1.2 电影信息及相关功能

电影界面支持预告片的在线放映、电影海报、简介、评分、电影类型的显示，支持用户对电影进行评分，支持电影收藏功能，可以查看有关该电影的所有影职员（导演、编剧、演员），并能直接访问其主页。能够根据该电影的题材推荐相似的电影，并能直接跳转到相关电影主页。电影页面下部支持话题区，对于别人或者自己创建的话题可以进行广播（即回复）以进一步针对某话题进行讨论，可以删除自己创建的话题、广播，但无权删除由他人创建的话题、广播，一旦话题被删除，其下所有广播都将被删除。

1.1.3 总览、个性化推送与检索

广场能够总览所有的电影、影人以及粉丝团信息，并同时支持根据用户的电影偏好实现个性化推送，以及按电影评分推送电影。广场能够显示最新成立的粉丝团、最新的有关电影的话题讨论，支持按关键字模糊搜索影人、电影。

1.1.4 影人（影职员）信息查看

影人主页支持查看影人写真、个人详细信息，展示该影人曾经作为导演、编剧或者演员所创作过的电影、曾经有过合作关系的其他影人，并支持跳转到合作影人的对应影人主页。

1.1.5 粉丝团相关操作

粉丝团页面可查看粉丝团名称（例如：xx宇宙后援会）、对应的影人姓名、该粉丝团的粉丝成员及个人信息、相关粉丝团（例如：与该影人有过合作关系的影人的粉丝团），并支持跳转到相关粉丝团的对应页面。此外，用户可在此页面加入或退出该粉丝团。

1.1.6 管理员相关操作

在登陆页面可选择以管理员模式登陆，管理员具有一般用户不具有的权限，包括：管理员可在影人主页为该影人创立粉丝团，管理员可以向数据库中添加新的影人及其相关信息，可在电影页面中为某部电影新增参与该电影创作的影人等。此外管理员不具有一般用户的某些权限，包括：更改电影类型偏好、收藏电影、加入粉丝团等。

1.2 数据流图

1.2.1 顶层

以下为顶层图的细节部分

（1）

（2）

（3）

1.2.2 登录页面

1.2.3 个人页面

1.2.4 电影页面

1.2.5 影人页面

1.2.6 广场页面

1.2.7 粉丝团页面

1.3 数据元素表

1.3.1 注册请求数据组

数据项名字	数据类型	空值约束
user_id	varchar(20)	非空
user_name	varchar(20)	非空
password	varchar(40)	非空

1.3.2 登陆请求数据组

数据项名字	数据类型	空值约束
user_id	varchar(20)	非空
password	varchar(40)	非空

1.3.3 个人信息数据组

数据项名字	数据类型	空值约束
gender	varchar(6)
email	varchar(20)
phone	varchar(20)
user_picture	longtext
user_id	varchar(20)	非空
theme_id	int	非空

1.3.4 收藏信息数据组

数据项名字	数据类型	空值约束
film_id	int	非空
film_name	varchar(20)	非空
film_date	varchar(10)	非空
film_score	float	非空
film_score_people	int	非空
introduction	varchar(250)	非空
picture	longtext	非空
theme_id	int	非空

1.3.5 粉丝团信息数据组

数据项名字	数据类型	空值约束
club_id	int	非空
club_name	varchar(20)
worker_name	varchar(45)	非空
worker_picture	longtext	非空
worker_id	int	非空

1.3.6 电影信息数据组

数据项名字	数据类型	空值约束
film_id	int	非空
film_name	varchar(20)	非空
film_area	varchar(10)	非空
film_date	varchar(10)	非空
film_score	float	非空
film_score_people	int	非空
introduction	varchar(250)	非空
picture	longtext	非空
video	longtext	非空

1.3.7 话题信息数据组

数据项名字	数据类型	空值约束
film_id	int	非空
topic_id	int	非空
user_id	varchar(20)	非空
title	varchar(45)	非空
topic_text	varchar(200)	非空
topic_time	datetime	非空

1.3.8 广播信息数据组

数据项名字	数据类型	空值约束
broadcast_id	int	非空
topic_id	int	非空
user_id	varchar(20)	非空
broadcast_text	varchar(100)	非空
broadcast_time	datetime	非空

1.3.9 影人信息数据组

数据项名字	数据类型	空值约束
broadcast_id	int	非空
topic_id	int	非空
user_id	varchar(20)	非空
broadcast_text	varchar(100)	非空
broadcast_time	datetime	非空

1.3.10 粉丝团信息数据组

数据项名字	数据类型	空值约束
club_id	int	非空
club_name	varchar(20)	非空
粉丝团成员信息数据组
worker_picture	varchar(100)	非空
worker_name	varchar(45)	非空
合作影人粉丝团信息数据组

1.3.11 粉丝团成员信息数据组

数据项名字	数据类型	空值约束
user_name	varchar(20)	非空
gender	varchar(6)
email	varchar(20)
phone	varchar(20)
user_picture	longtext

二、数据库概念模式设计

2.1 系统初步E-R图

该E-R图是系统设计报告初稿中的E-R图。经助教指出，其存在实体数量未达到要求等问题，在迭代过程中被取代。

黄色方块表示实体（包括：用户、题材、影人、电影）；

红色菱形表示关系；

蓝色椭圆表示属性。

2.2 系统基本E-R图

该E-R图与系统的最终呈现一致。由于若按初步E-R图的方式进行表示，实体及属性个数过多，将导 致图的展示不够清晰。因此，在与助教进行沟通后，采用以下形式进行展现：

• 黄色方块表示实体（包括：用户、管理员、电影、影人、粉丝团、主题、话题）；
• 红色菱形表示实体之间的关系；
• 蓝色椭圆表示属性，其中深蓝椭圆表示实体的属性，而浅蓝椭圆表示关系的属性；
• 灰色方块将实体与该实体对应的属性包裹起来（取代了用线段连接的表现方式）。由于此处用线连 接实体与属性会导致图的呈现过于冗杂，因此在与助教沟通后采用这种方式表现。

三、数据库逻辑模式设计

3.1 数据库关系模式

按照系统E-R图，我们为数据库创建了16种关系模式，每种关系模式可以用五元组R(U,D,Dom,F)来表示。其中，R表示关系名， U表示组成该关系的属性名集合， D为 U 中属性所来自的域，Dom 为属性向域的映像集合，F 为属性间数据的依赖关系集合。对于数据库关系模式的设计而言，我们此处不讨论 D和 Dom，仅用三元组来描述R<U,F>我们设计的关系模式。

3.1.1 user_list

关系名 :user_list

属性集合 U：

属性名	中文含义
user_id	用户唯一标识
user_name	用户名称
password	用户登陆密码
gender	用户性别
email	用户电子邮箱
phone	用户电话号码
user_picture	用户头像

3.1.2 manager_list

关系名:manager_list

属性集合U ：

属性名	中文含义
manager_id	管理员唯一标识
manager_name	管理员名称
password	管理员登陆密码
gender	管理员性别
email	管理员电子邮箱
phone	管理员电话号码
manager_picture	管理员头像

函数依赖集合F:

3.1.3 theme_list

关系名:theme_list

属性集合 U：

属性名	中文含义
theme_id	主题ID
theme_name	主题名称

函数依赖集合F：

3.1.4 user_theme

关系名属性集合 ：

属性名	中文含义
ut_id	用户-偏好主题关系的唯一标识
user_id	用户ID
theme_id	用户偏好的主题ID

3.1.5 user_collection

关系名user_collection

属性集合U ：

属性名	中文含义
collection_id	用户-电影关系的唯一标识
user_id	用户ID
film_id	用户收藏的电影ID

3.1.6 user_score

关系名user_score

属性集合U ：

属性名	中文含义
user_score_id	用户评分动作的唯一标识
user_id	用户ID
film_id	用户评分的电影ID
score_number	用户评分

3.1.7 worker_list

关系名worker_list

属性集合 U：

属性名	中文含义
worker_id	演职人员（简称影人，包括导演、编剧和演员）ID
worker_name	影人姓名
worker_picture	影人照片
worker_introduction	影人简介

3.1.8 film_info

关系名film_info

属性集合U ：

属性名	中文含义
film_id	电影ID
film_name	电影名称
film_date	电影上映日期
film_area	电影上映地区
film_score	电影评分
film_score_people	电影评分人数
introduction	电影简介
picture	电影海报图片
video	电影预告片视频

3.1.9 film_theme

关系名film_theme

属性集合U ：

属性名	中文含义
ft_id	电影-主题关系的唯一标识
film_id	电影ID
theme_id	电影主题ID

3.1.10 film_actor

关系名film_actor

属性集合U：

属性名	中文含义
fa_id	电影-演员从属关系的唯一标识
film_id	电影ID
worker_id	演员ID

3.1.11 film_writer

关系名film_writer

属性集合U：

属性名	中文含义
fw_id	电影-编剧从属关系的唯一标识
film_id	电影ID
worker_id	编剧ID

3.1.12 film_director

关系名film_director

属性集合U：

属性名	中文含义
fd_id	电影-导演从属关系的唯一标识
film_id	电影ID
worker_id	导演ID

3.1.13 topic_list

关系名topic_list

属性集合 U：

属性名	中文含义
topic_id	话题ID
film_id	话题所属的电影ID
user_id	话题发布者（用户）的ID
title	话题标题
topic_text	话题内容
topic_time	话题发布时间

3.1.14 broadcast_list

关系名broadcast_list

属性集合 U：

属性名	中文含义
broadcast_id	广播ID
topic_id	广播所属的话题ID
user_id	广播发布者（用户）的ID
broadcast_text	广播内容
broadcast_time	广播发布时间

3.1.15 fan_club

关系名fan_club

属性集合U ：

属性名	中文含义
club_id	粉丝团ID
worker_id	粉丝团对应的影人ID
club_name	粉丝团名称

3.1.16 user_in_club

关系名user_in_club

属性集合 ：

属性名	中文含义
user_in_club_id	用户-粉丝团关系的唯一标识
user_id	用户ID
club_id	用户加入的粉丝团ID

3.2 关系模式范式等级的判定与规范化

3.2.1 user_list

在关系模式user_list中，满足：

• 每一个非主属性完全函数依赖于所有候选码（user_id），因此属于2NF。
• 不存在码（user_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.2 manager_list

在关系模式manager_list中，满足：

• 每一个非主属性完全函数依赖于所有候选码（manager_id），因此属于2NF。
• 不存在码（manager_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.3 theme_list

在关系模式theme_list中，满足：

• 每一个非主属性完全函数依赖于所有候选码（theme_id），因此属于2NF。
• 不存在码（theme_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.4 user_theme

在关系模式user_theme中，满足：

• 每一个非主属性完全函数依赖于所有候选码（ut_id），因此属于2NF。
• 不存在码（ut_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.5 user_collection

在关系模式user_collection中，满足：

• 每一个非主属性完全函数依赖于所有候选码（collection_id），因此属于2NF。
• 不存在码（collection_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.6 user_score

在关系模式user_score中，满足：

• 每一个非主属性完全函数依赖于所有候选码（user_score_id），因此属于2NF。
• 不存在码（user_score_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.7 worker_list

在关系模式worker_list中，满足：

• 每一个非主属性完全函数依赖于所有候选码（worker_id），因此属于2NF。
• 不存在码（worker_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.8 film_info

在关系模式film_info中，满足：

• 每一个非主属性完全函数依赖于所有候选码（film_id），因此属于2NF。
• 不存在码（film_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.9 film_theme

在关系模式film_theme中，满足：

• 每一个非主属性完全函数依赖于所有候选码（ft_id），因此属于2NF。
• 不存在码（ft_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.10 film_actor

在关系模式film_actor中，满足：

• 每一个非主属性完全函数依赖于所有候选码（fa_id），因此属于2NF。
• 不存在码（fa_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.11 film_writer

在关系模式film_writer中，满足：

• 每一个非主属性完全函数依赖于所有候选码（fw_id），因此属于2NF。
• 不存在码（fw_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.12 film_director

在关系模式film_director中，满足：

• 每一个非主属性完全函数依赖于所有候选码（fd_id），因此属于2NF。
• 不存在码（fd_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.13 topic_list

在关系模式topic_list中，满足：

• 每一个非主属性完全函数依赖于所有候选码（topic_id），因此属于2NF。
• 不存在码（topic_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.14 broadcast_list

在关系模式broadcast_list中，满足：

• 每一个非主属性完全函数依赖于所有候选码（broadcast_id），因此属于2NF。
• 不存在码（broadcast_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.15 fan_club

在关系模式fan_club中，满足：

• 每一个非主属性完全函数依赖于所有候选码（club_id），因此属于2NF。
• 不存在码（club_id）对非主属性的传递函数依赖，因此属于3NF。

3.2.16 user_in_club

在关系模式user_in_club中，满足：

• 每一个非主属性完全函数依赖于所有候选码（user_in_club_id），因此属于2NF。
• 不存在码（user_in_club_id）对非主属性的传递函数依赖，因此属于3NF。

3.3 数据库设计优化

3.3.1 表及字段的命名优化

• 采用下划线命名法对表及字段的名字进行格式化，具备良好的可读性；
• 表（及字段）的名字足够描述它所标识的内容。例如：film_info表存储电影实体的基本信息； user_name字段代表用户的昵称等等。具备良好的表意性。
• 不与数据库中的专有字段命名冲突。例如，在MySQL中存在user表，因此在创建系统的用户实体表时，将其命名为user_list而避免冲突，具备良好的敏感性。

3.3.2 “三少原则”的遵守

• 提倡“三少原则”，是为了防止用户利用“打补丁”等技术，不断对数据库进行增、删、改，使得数据库中的表变得杂乱无章、不计其数而难以维护。
• “三少原则”意指少而精，有效地降低了数据冗余。它包括三点：表的个数少、表中主键的字段个数少、表的字段个数少。该系统的数据库遵循该原则，例如：精简E-R图，只建立E-R图中所对应的实体（或关系）表，减小表的数量，进行数据集成和高度的抽象；将每个表主键的字段个数降为1，节省了运行时间和索引存储空间；采用“列变行”的思想（例如将电影的影职员等信息拉出去单建表）。

3.3.3 主码（索引）的优化

• 首先如前文所述，每个表的主码字段数量均为1。这是因为主码的作用之大：一是建立主键索引，二是需要作为其他表（例如关系表）的外键。因此，对主码字段数量的优化能够有效节省存储空间，并提高检索的效率。
• 考虑主键是否需要自动顺序增长：如关系表的主键按照创建顺序自动增长，关系数据也按照主键的顺序进行逻辑存储；而用户表、管理员表等信息表的主键则无需自动增长，具体问题具体分析，提高建模的合理性。

3.3.4 正确处理关系

• 多对多（m-n）关系是需要重视并合理处理的关系。例如，用户与电影之间的收藏关系：一位用户可以收藏多部电影；而一部电影可以被多位用户收藏。要合理地表示这样的关系，需要在两个信息表（用户列表及电影列表）之外增加一个关系表，这张关系表存储用户对电影的收藏。它包含三个字段：两个外码（用户表主码及电影表主码）和一个主码（为该关系表定义的自增主码）。

3.3.5 各类异常的避免

• 通过数据库的多种设定，有效地避免了各类异常。例如：通过上文所述的多对多关系的处理，避免了删除异常等（删除掉某关系，并不会将对应的实体误删）；通过表的拆分（例如将影人表独立出来，建立与电影无关的影人实体）等操作，避免插入异常、删除异常等。