明日方舟WIKI

—— 数据库课程期末项目

应用需求介绍

本应用旨在构建为广大玩家以及有兴趣的人们提供明日方舟有关资料的搜寻展示以及一些趣味功能。实现了干员、皮肤的总体展示页面以及详细资料展示；并且设计了用户的登录功能，各个用户有查看自己拥有的一些资源等权限；还有投票功能以及一些彩蛋跳转等。这些游戏信息、工具和社区互动，使得无论是新手还是资深玩家，都能通过这个应用更好地享受明日方舟的游戏体验。当然要拓展成对于其它游戏或者应用的创意网站也极其方便。

准备工作

数据爬取：

数据爬取工作，需要爬取干员（游戏人物）的信息、游戏设定中的地区信息、游戏中的干员皮肤信息等等。数据主要是从明日方舟wiki网站 明日方舟wiki百科 爬取得到，然后根据标签过滤出需要的信息，最终保存在xlsx文件中。最终的数据文件包括：

游戏内干员初始立绘、精二立绘、皮肤立绘，爬虫下载到本地之后进行良好的命名组织，然后上传到图床中去。

skin_info.xlsx，存储游戏中干员皮肤的名字、关联的干员名、画师、所在系列、简要介绍。

明日方舟干员数据+半身像+立绘URL.xlsx，存储游戏中干员的ID（自定义的主键）、名字、性别、种族、职业等信息，最重要的是半身像URL和立绘URL。我们将所需要的图片上传到图床中去，使用opengauss数据库存储其URL以定位大文件。

这里给出一个例子，获得干员半身像的py文件get_bust.py：

首先获取一个格式化的URL并且使用request.get得到从服务器返回的HTML文件。然后，使用BeautifulSoup第三方库进行对于HTML文件的解析，得到解析好的HTML文本。接着根据标签进行过滤得到想要的半身像的所在URL。最后再去获得半身像的图片(png格式)

数据批量导入：
由于干员表和皮肤表都有非常大量的数据需要导入数据库，手工进行导入无疑会耗费大量的时间并且容易产生错误，所以在网上检索了相关资料之后，发现有django-import-export库为django的导入提供了简便的方法。然后依照着网上关于这个库的教程在resource.py以及admin.py对相关的批量导入类进行了创建以及注册。完成后即可在admin站点里看到import和export按钮，选取相应的数据文件后即可完成批量数据导入和导出（我们的数据库中对于导出功能并没有使用）。

图片批量压缩：
由于对于高分辨率的图片的展示较为缓慢，为了提高展示的观感，我们利用imagemagick库对图片进行批量分别率压缩。

应用系统设计（尤其是数据库设计/ER图等

ER 图设计：

上图即为我们概念模式中ER图的构建，总共有6个实体集以及5个联系集。

实体集分别有Operators用于存储干员信息；Zhenying用来存储阵营信息；Record用来存储职业信息；Skin用来存储皮肤信息；Jiaju用来存储家具信息；Account存储账户信息。

联系集有三个多对一的联系，另外有两个多对多的联系，在后文关系模式中会谈到一些更具体的实现。

关系模式：

首先是从实体集直接转换出来的Operators表，其以ID作为主键，另外还有诸多其它信息字段，需要注意这里我们的occupation字段以及zhenying字段，由于我们对应有两个多对一（Operators为多端，zhenying和Record为一端）联系集，所以在转换为关系模式后我们将这两个字段设置为外键，分别对zhenying和Record进行引用。

然后是从实体集直接转换出来的zhenying和Record表，他们分别以name和Occupations为主键，另外zhenying表中还有一个intro字段存储一些介绍文本，这两个关系都作为被参照关系被Operators所参照。

接下来是从实体集转换出来的Skin表，本表以name作为主键，由于其与Operators有多对一关系，所以表格中的opID设计外键，参照关系是Operators，另外还有一些存储其它相关信息的字段。

Jiaju表亦是从实体集转换而成的表，以name为主键，另外存储了家具的一些介绍信息。

Account表也是如此，以email为主键，另外存储了一些有关注册登录的相关信息。

两个多对多的关系我们通过单独建一张表来在关系模式中实现，对于Operators与Account之间的多对多关系user_op，我们综合了Operators以及Account两个表的主键作为主键；而对于Jiaju与Account之间的多对多关系user_jiaju，我们综合了Jiaju以及Account两个表的主键作为主键。

Django框架结构：

URLs: 虽然可以通过单个功能来处理来自每个 URL 的请求，但是编写单独的视图函数来处理每个资源更具有可维护性。

URL 映射器用于根据请求 URL 将 HTTP 请求重定向到相应的视图。URL 映射器还可以匹配出现在 URL 中的字符串或数字的特定模式，并将其作为数据传递给视图功能。

View: 视图是一个请求处理函数，它接收 HTTP 请求并返回 HTTP 响应。视图通过模型访问满足请求所需的数据，并将响应的格式委托给模板。

Models: 模型是定义应用程序数据结构的 Python 对象，并提供在数据库中管理（添加，修改，删除）和查询记录的机制。

Templates: 模板是定义文件（例如 HTML 页面）的结构或布局的文本文件，用于表示实际内容的占位符。一个视图可以使用 HTML 模板，从数据填充它动态地创建一个 HTML 页面模型。可以使用模板来定义任何类型的文件的结构; 它不一定是 HTML！

系统实现（包括系统主要运行界面

主页面首页：
在主页面首页中展现了已注册用户的用户名以及值班干员塞雷娅的立绘

主页面首页的部分html展示：

主页面干员一览：
点击首页中的指纹图标可以浮现出全308个干员的半身像一览：

在演示视频中可以看到这些干员的展示图片具有与鼠标的交互功能，会随着鼠标的移动以及触碰产生变化。

主页面中罗列干员半身像框的html实现代码：
使用一个循环遍历数据库中的干员信息，根据干员对应的ID号在数据库中查找出干员的半身像url并且在前端中显示

点击登录按钮或点击干员头像（首次登陆）即可跳转至登陆界面：

登录按钮是正常的跳转登录的方式，未登录时点击干员头像的跳转则是违反了数据库应用的权限设计导致的，因为用户在没有登陆的时候不具有查看干员详细信息的权限，所以强制跳转到登录界面推荐用户登录之后进行查看。

登陆界面展示：

用户登录在view.py中的login函数实现如下。在前端的html中，如果用户点击了提交按钮，则获取POST的request请求，用各个变量接收用户输入的email，password，phone等等信息，进入数据库中查找是否有对应的用户名/手机号以及密码，如果遇到错误，如密码错误或账号不存在等等情况，则抛出异常并重定位回登录界面，否则，成功登录并重定位回主页，将用户的email信息存储在request.session的字典中（用于实现检测用户是否登录，并限制只有登录了的用户可以查看干员信息的功能）

注册界面展示：

用户注册在view.py中的logon函数实现如下。在前端的html中，如果用户点击了提交按钮，则获取POST的request请求，用各个变量接收用户输入的email，password，phone等等信息，如果信息不合法（如手机号不足11位或两次密码不一致等），抛出异常并重定位回注册界面，否则，成功注册并在数据库中的Account表插入一条新的记录，将用户的信息存储进opengauss数据库中

实现的附加功能：找回密码。实现思路是通过用户的手机号或用户名，在数据库中查找并修改对应的记录

后端中用户信息表Account在model.py中的存储模型如下：

干员信息展示页面：
点击干员半身像框即可进入干员信息页面

当用户点击了干员半身像框后，前端中通过超链接跳转至/man的url中，跳转后执行view.py文件中的man函数，在该函数中，后端获取用户点击以后传来的request请求，其中包含的干员的ID信息，通过该ID信息进入数据库中查找对应的实体。此外，函数中也实现了如果没有获取到用户的登录session信息，则将重定位至登陆界面的功能。最后，将干员信息整合入operator.html并进行页面渲染即可实现干员的信息展示

view.py中的man函数展示：

operator.html展示：

点击首页左上角的skin按钮，即可进入皮肤展示页面：

其中展示了皮肤名，对应的干员名字，皮肤系列名，画师以及皮肤描述等信息:

展示皮肤的后端skin函数实现如下。实现思路是从数据库中获取所有的skin实体并传送给前端

点击首页左上角的bag按钮，即可进入用户的背包展示页面：
（如果用户尚未登陆则被重定位至登陆界面）

背包展示页面，其中展示了用户的用户名，拥有的家具以及拥有的干员：

这里的展示是基于两个多对多联系建立的表实现的。

为干员投票页面，在主页中点击左下角的第三个按钮进入到投票页面：

点击进入后投票页面如下：

点击ViewResult按钮后进入到展示票数页面：

对于投票主界面而言，主题框架如下：

投票主界面主要由头部栏、light_card、dark_card三个部分组成。后两者为两张卡片，卡片包括干员信息、投票按钮。通过脚本文件json的编写，实现了“投票按钮转换”，“详细信息开关”等一些动态效果，以及一些保存开关状态、开关静默的逻辑功能。

投票按钮需要提交一个POST请求传给后端，让数据库中对应干员的票数加1;

保存开关效果的逻辑功能需要使用到State变量存储上一次的状态，以免刷新就清空开关效果，产生不良体验。

“详细信息开关”的目的是产生动态效果，让用户和网页有更好的交互而不是单纯的看和点击按钮。使用了按钮球平移的方法控制开关状态，进而控制干员信息的浮现。

投票展示界面的功能就比较简单，只是根据干员的信息、票数进行展示：

组员分工

张嘉祺：
负责数据库的概念模式以及逻辑模式的设计，HOME应用程序的编写，网站展示页面相关资料的收集以及编写，完成数据批量导入功能的设计。

黄光恒：
负责数据的爬取、数据的组织和Vote应用程序的编写，以及部分关于数据库搭建的配置（尝试虚拟机配置并连接）。参与了数据库关系模式表的设计，合作设计了这个wiki的数据库idea。

梁乐峰：
负责login应用中登录注册的实现以及账号数据库的实现。前端html和后端数据库的联系等。Opengauss在Docker虚拟机上的部署。

展示视频

请到文件夹中的“数据库final.mp4”中查看展示视频。