【近场社交项目】数据库系统期末设计——需求分析部分

1.需求求分析(用户部分为例）

1.2用户数据字典

1.2.1用户信息表（数据结构）：

属性名：用户ID、用户名、密码、手机号（账号）、邮箱。
数据项：用户的ID、用户名、密码、手机号（账号）、邮箱。
数据结构：用户信息表
数据流：通过两种途径获得用户数据：
1）由用户通过我们平台的注册页面、用户个人页面通过完善信息，填写上述信息，完成数据的收集；
2）通过用户个人的微信授权获取用户的上述必要信息。

数据项间的关系和结构定义：

1）用户ID、用户名、密码、手机号（账号）、邮箱都是可以唯一对应一个用户的，其中设置用户ID为这张表的主码。
2）约束条件：在定义的时候，各个属性都是设置 NOT NULL(非空约束)。UNIQUE（唯一） 的约束条件，从而保证数据的完整性。
3）各个属性的域：
用户ID：varchar类型 设置为00001~99999（考虑到自身平台大小，以及用户的预期最大数量进行考量）；
用户名：v varchar 类型， 4到12字节长度。根据我国《姓名登记条例》，对于姓名的规定是2~6个汉字的。
密码：varchar类型 6~32个字符长度；
手机号：char 类型 固定为11个字符长度，其还可以是用户的登陆的账号
邮箱：char类型，长度不超过35个字符（最长的电子邮件是35个字符长度）。

1.2.2.个人资料表（数据结构）：

属性名：用户ID（主码）、姓名、性别、出生日期、职业。
数据项：用户ID、姓名、性别、出生日期、职业。
数据结构：个人资料表。
数据流：通过两种途径获得用户数据：

1）用户个人页面通过完善信息，填写上述信息，完成数据的收集；
2）通过用户个人微信授权获取用户的上述必要信息。

数据项间的关系和结构定义：

1）将个人资料表的用户ID设置为个人资料表的主码。用户信息表和个人资料表通过主键进行关联。
2）约束条件：在定义的时候，各个属性都是设置 NOT NULL(非空约束)，不必设置UNIQUE约束条件，因为姓名、性别、出生日期、职业、内容都是可以重复的。用户ID是主码，已经设置了非空唯一的约束了。
3）各个属性的域：
用户ID：varchar类型 设置为00001~99999（考虑到自身平台大小，以及用户的预期最大数量进行考量）；
用户名：varchar 类型， 4_{12字节长度。根据我国《姓名登记条例》，对于姓名的规定是2}6个汉字的。
性别：char 类型 ，2个字节长度。
出生日期：char 类型， yyyy-mm-dd的格式，长度为10个字节长度。
职业：varchar 类型 ，0~255字节长度。

1.2.3.标签信息表（数据结构）：

属性名：标签ID、标签类别，标签描述
数据项：标签ID、标签类别，标签描述
数据结构：标签信息表
数据流：通过发布问卷，收集各类商家社交场所的类别，服务业务详情等相关信息。

数据项间的关系和结构定义：

1）设置标签id为标签信息表的主码。
2）约束条件：在定义的时候，各个属性都是设置 NOT NULL(非空约束)和 UNIQUE约束条件，从而保证数据的完整性。
3）各个属性的域：

标签ID：int 类型，从0开始自增。设置标签id为标签信息表的主码
标签类别：varchar类型，0~30字符长度 ，作用：对于社交场所和社交文化以及用户进行一个分类和匹配机制。设置非空约束和UNIQUE约束条件
标签描述：varchar类型，0~255字符长度 。对于该标签的类别进行一个比较简短的描述。设置非空约束和UNIQUE约束条件

3.2.4.用户-标签关系表（数据结构）：

属性名：S_id，F_id。
数据项：S_id，F_id。
数据结构：用户-标签关联表
数据流：来源于用户信息表和标签信息表中的数据。
数据项间的关系和结构定义：
1）将S_id 作为用户信息表的外键，F_id作为标签信息表的外键。通过用户信息表的用户id 和S_i进行关联，标签信息表的标签ID和F_id进行关联。
2）约束条件：外键和各自对应的主键设置为相同的约束条件，非空且唯一。
3）各个属性的域：
S_id：varchar类型 设置为00001~99999，用户信息表的外键
F_id：int 类型，标签信息表的外键。
4. 社交文化知识信息表：（数据结构）：
属性名：编号，知识类别， F_id
数据项：编号，知识类别， F_id
数据结构：社交文化知识信息表
数据流：

1）来源于平台对各种社交知识的收集、归纳和分类
2）与专业的社交知识服务的平台合作，引进相关的知识内容数据。

数据项间的关系和结构定义：

1）将编号作为该信息表的主码，F_id作为标签信息表的外键。
2）约束条件：都设置为 NOT NULL 和UNIQUE约束条件。
3）各个属性的域：
编号：int 类型 从0开始自增，无上限，主码
知识类别：varchar 类型 0~60个字符长度，非空约束
F_id：int 类型，从0开始自增。作用是：作为标签信息表的外键，通过这个数据项和标签信息表进行一个关联。

1.2.5. 文化内容详情表：（数据结构）：

属性名：编号，文本、音频、视频、图片
数据项：编号，文本、音频、视频、图片
数据结构：文化内容详情表
数据流：
1）来源于平台对各种社交知识的收集、归纳和分类
2）与专业的社交知识服务的平台合作，引进相关的知识内容数据。
数据项间的关系和结构定义：
1）将编号作为该信息表的主码
2）约束条件：文本、音频、视频、图片这几个属性内容可有可无，不用设置非空约束，但是需要设置UNIQUE唯一约束。
3）各个属性的域：
编号：int 类型 从0开始自增，无上限。由于社交文化知识信息表和文化详情表是一对一的关系，可以通过各自主键进行关联。
文本：text 类型，长度范围：0~65535个字节长度，设置UNIQUE唯一约束。
音频：varchar 类型，0~255个字节长度，存放音频的地址路径，设置UNIQUE唯一约束。
视频：varchar 类型，0~255个字节长度，存放视频的地址路径，设置UNIQUE唯一约束。
图片：varchar 类型，0~255个字节长度，存放图片的地址路径，设置UNIQUE唯一约束。

1.2.6订单（基础结构）

这里以用户预定社交场所的订单为例，其余的订单模式和这个类似。
属性名：订单号，用户ID、用户名、用户联系电话、审核状态、商家ID、下单时间
数据项：订单号，用户ID、用户名、用户联系电话、审核状态商家ID、下单时间
数据结构：订单，订单细节
数据流：通过用户ID在用户表中进行数据的快速填充用户信息
数据项间的关系和结构定义：
1）将订单号作为该订单的主码。是该订单的唯一标识。
2）约束条件：将属性都设置为NOT NULL非空约束和UNIQUE唯一约束。保证数据的完整性。
3）各个属性的域：
订单号：char 类型 长度固定为11个字符长度，前6为表示订单产生的时间，后六位表示订单的排号。例如230503000001，前五位表示2023年5月3日，后面表示1号订单。是订单的唯一标识。
用户ID：varchar类型 设置为00001~99999，外码。
用户名：varchar类型 4~12个字符长度；非空约束
用户联系电话：char 类型，11个字节长度，非空约束
唯一约束
审核状态：int类型，0或者1.当为0时，这张订单是没有审核的，一旦审核就会改为1。
商家ID：varchar类型 设置为002~999，作为商家信息表的外码
下单时间：datetime类型，非空约束。

1.2.7用户预定社交场所的订单细节（基础结构）

属性名：id、场所服务预定金额、场所规格（能容纳人数）、社交场所可预定时间，社交场所ID，订单号，F_id
数据项：编号、社交场所ID、场所服务预定金额、可预定时间、单位地点（一个房间或者其他）容纳的人数,F_id。
数据结构：订单细节
数据流：通过社交场所名，填充场所的相关信息。
数据项间的关系和结构定义：
1）将id作为该信息表的主码
2）约束条件：讲属性都设置为非空约束和UNIQUE唯一约束。
3）各个属性的域：
id：int 从0自动增长，无上限。主码
社交场所ID：char类型，000~999，场所服务表的外码
场所服务预定金额：int 类型，范围就是int所表示的数值范围。非空约束
场所规格：char类型，三个字节大小。非空约束
订单号：char 类型 长度固定为11个字符长度，作为订单的外码
可预定时间：datetime类型 ，数据格式为：yyyy-mm-dd。
F_id : int类型，作为折扣信息表的外键

1.2.8 会员信息表

属性名：会员ID、用户ID、会员有效时长、会员类别、会员起始时间、会员截止时间
数据项：会员ID、用户ID、会员有效时长、会员类别、会员起始时间、会员截止时间
数据结构：会员信息表
数据流：数据来源于用户信息表，以及根据用户的充值情况进行信息数据的匹配。
数据项间的关系和结构定义：
1）将会员ID作为会员信息表的主码
2）约束条件：将用户ID设置为外键约束，其他属性设置为非空约束，保证数据的完整性。
3）各个属性的域：
会员ID：int 类型 从0开始自增，作为会员信息表的主码
用户ID：varchar类型 设置为00001~99999（考虑到自身平台大小，以及用户的预期最大数量进行设置）作为用户信息表的外键；
会员有效时长：datetime类型。
会员起始时间：datetime类型。
会员截止时间：datetime类型。
会员类别：varchar类型，6个字节大小。年会员，月会员。

1.2.9用户预定社交场所的订单（审核）

数据存储名：用户预定社交场所的订单（审核）
用户提交订单后，商家和系统审核过的订单。
输入的数据流：来自制单的数据。
输出的数据：输出商家相关负责人和用户用的支付平台。
组成（数据结构）： 用户预定社交场所的订单和用户预定社交场所的订单细节。
数据量：3.6W/年，（出库单100*365）
存储频率：200次/天（商家相关负责人100+和用户用的支付平台100）

二、处理过程要求：

处理过程名：制单
输入数据流：用户填写相关数据，以及用户信息表和商家信息表的数据流入
输出数据流：将订单信息输出给相应的处理平台和负责人。
处理：根据用户填写的订单数据，查询商家的社交场所相关信息和客户 的数据存储。锁定社交场所的状态，完成制单的新增。
处理过程名：审核
输入数据流：订单的数据流入
输出数据流：将审核后的，需要修改的数据输出到相应的处理平台和负责人
处理：经过商家那边确认自己的社交场所在该段时间是空闲状态，并且足以容纳提供的人数信息，可以将该社交场所设定为以预定状态，其他客户想要预定就拒绝预定。支付平台那边进行用户账面余额的修改。

简洁的数据流图，如下图所示：

3.2.10用户可以进行下单业务操作：

下单业务的详细操作流程：
具体步骤如下所示：

1.用户在社交场所平台浏览商家页面信息，并选择心仪的社交场所。
2.用户进入该场地的详细信息页面，查看该场地的可预定时间、价格、设施等信息，并选择想要预定的日期和时间。
3.用户填写预定场地的相关信息，包括姓名、联系方式、预定时间、预定人数等，并提交订单。
4.系统生成订单号，并回显用户订单信息和订单号。
5.用户完成支付。
6.系统将订单状态更新为“已支付”。
7.社交场所平台通知社交场所进行预订确认，预订确认后将社交场所信息发送给用户。
8.用户到达预定场地并享受社交体验。

具体流程图如下：

总结撒花💞

   本篇文章旨在分享的是我数据库系统设计需求分析阶段中，用户部分的数字字典。希望大家通过阅读此文有所收获！
   😘如果我写的有什么不好之处，请在文章下方给出你宝贵的意见😊。如果觉得我写的好的话请点个赞赞和关注哦~😘😘😘

本文链接：https://www.kjpai.cn/news/2024-05-04/164728.html，文章来源：网络cs，作者：言安琪，版权归作者所有，如需转载请注明来源和作者，否则将追究法律责任！