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

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

• 前言🙌
• • 1.需求求分析(用户部分为例）
  • • 1.2用户数据字典
    • • 1.2.1用户信息表（数据结构）：
      • • 数据项间的关系和结构定义：
        • 1.2.2.个人资料表（数据结构）：
        • 1.2.3.标签信息表（数据结构）：
        • 3.2.4.用户-标签关系表（数据结构）：
        • 1.2.5. 文化内容详情表：（数据结构）：
        • 1.2.6订单（基础结构）
        • 1.2.7用户预定社交场所的订单细节（基础结构）
        • 1.2.8 会员信息表
        • 1.2.9用户预定社交场所的订单（审核）
        • 二、处理过程要求：
        • 3.2.10用户可以进行下单业务操作：
        • 总结撒花💞

          

             

          😎博客昵称：博客小梦

          😊最喜欢的座右铭：全神贯注的上吧！！！

          😊作者简介：一名热爱C/C++，算法等技术、喜爱运动、热爱K歌、敢于追梦的小博主！

          😘博主小留言：哈喽！😄各位CSDN的uu们，我是你的博客好友小梦，希望我的文章可以给您带来一定的帮助，话不多说，文章推上！欢迎大家在评论区唠嗑指正，觉得好的话别忘了一键三连哦！😘

          

          前言🙌

              哈喽各位友友们😊，我今天又学到了很多有趣的知识，现在迫不及待的想和大家分享一下！😘我仅已此文，分享数据库系统期末设计——需求分析部分*~ 都是精华内容，可不要错过哟！！！😍😍😍

          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 类型， 412字节长度。根据我国《姓名登记条例》，对于姓名的规定是26个汉字的。

          性别：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.用户到达预定场地并享受社交体验。

          具体流程图如下：

          

          总结撒花💞

             本篇文章旨在分享的是我数据库系统设计需求分析阶段中，用户部分的数字字典。希望大家通过阅读此文有所收获！

             😘如果我写的有什么不好之处，请在文章下方给出你宝贵的意见😊。如果觉得我写的好的话请点个赞赞和关注哦~😘😘😘