一份全面的“数据库设计需求分析”是怎样的?

本文笔者将与大家分析数据库外部设计需求、结构设计需求、运用设计需求以及安全保密设计需求。

数据库设计需求

1. 需求概述

建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。

数据库的框架和结构必须根据设备和运行状态而设计,方便提供强大的录入、查询、统计、分析和报表等各种功能操作,较好的反映平台业务的基本情况和运行状况,满足平台的基本要求。

2. 外部设计需求

2.1 标识符和状态

数据库表前缀:根据模块名定义(如用户模块:sys_)

用户名:root

密码:待定

权限:全部

有效时间:开发阶段

说明:系统正式发布后,可能更改数据库用户/密码。

2.2 使用它的程序

本系统主要利用java作为后端的应用开发工具,使用MySQL作为后台的数据库,  Linux或Windows均可作为系统平台。

2.3 约定

  • 所有命名一定要具有描述性,杜绝一切拼音、或拼音英文混杂的命名方式。
  • 字符集采用 UTF-8,请注意字符的转换。
  • 所有数据表第一个字段都是系统内部使用主键列,自增字段,不可空,名称为:id,确保不把此字段暴露给最终用户。
  • 除特别说明外,所有日期格式都采用date格式。
  • 除特别说明外,所有字段默认都设置不充许为空, 需要设置默认值。
  • 所有普通缩影的命名都是表名加设置缩影的字段名组合,例如用户表User中name字段设置普通所以,则缩影名称命名方式为user_name_index。

2.4 专门指导

对本系统的开发者、使用这、测试员和维护人员,提出以下参考意见:

  • 在使用数据库时,首先要参考上面的约定内容,做好软件的安装以及表格的建立。
  • 数据库的输入统一采用键盘。对于数据库的使用权限,请参考本系统其他相关文档。
  • 数据库的后台管理员没用等级差异,可根据实际情况添加删除管理员。

2.5 支持软件

操作系统: Linux / Windows

数据库系统:MySQL

查询浏览工具:Navicat Premium

命令行工具:mysql

注意:mysql 命令行环境下对中文支持不好,可能无法书写带有中文的 SQL 语句。

3. 结构设计需求

3.1 概念结构设计需求

概念数据库的设计是进行具体数据库设计的第一步,概念数据库设计的好坏直接影响到逻辑数据库的设计,影响到整个数据库的好坏。

我们已经得到了系统的数据流程图和数据字典,现在就是要结合数据规范化的理论,用一种模型将用户的数据要求明确地表示出来。

概念数据库的设计应该极易于转换为逻辑数据库模式,又容易被用户所理解。概念数据库设计中最主要的就是采用“实体-关系数据”模型来确定数据库的结构。

数据是表达信息的一种重要的量化符号,是信息存在的一种重要形式。数据模型则是数据特征的一种抽象。它描述的是数据的共性,而不是描述个别的数据。一般来说,数据模型包含两方面内容:

  • 数据的静态特性:主要包括数据的基本结构、数据间的关系和数据之间的相互约束等特性。
  • 数据的动态特性:主要包括对数据进行操作的方法。

在数据库系统设计中,建立反映客观信息的数据模型,是设计中最为重要的,也最基本的步骤之一。

数据模型是连接客观信息世界和数据库系统数据逻辑组织的桥梁,也是数据库设计人员与用户之间进行交流的共同基础。概念数据库中采用的实体-关系模型,与传统的数据模型有所不同。“实体-关系”模型是面向现实世界,而不是面向实现方法的,它主要是用使用方便,因而在数据库系统应用的设计中,得到了广泛应用。“实体-关系”模型可以用来说明数据库中实体的等级和属性。

以下是实体-关系模型中的重要标识:

  • 在数据库中存在的实体;
  • 实体的属性;
  • 实体之间的关系;

3.2 逻辑结构设计需求

项目结构实体、实体属性ER图如下:

用户权限实体、实体属性ER图如下:

进度计划权限实体、实体属性ER图如下:


3.3 物理结构设计需求

1)定义数据库、表及字段的命名规范:

  • 数据库、表及字段的命名要遵守可读性原则。
  • 数据库、表及字段的命名要遵守表意性原则。
  • 数据库、表及字段的命名要遵守长名原则。

2)选择合适的存储引擎:

3)为表中的字段选择合适的数据类型。

4)建立数据库结构

4. 运用设计需求

4.1 表名的命名规范

表名以英文单词、单词缩写、简写、下划线构成,总长度要求小于30位。

4.2 表字段的命名规范

  • 字段名以英文单词、单词缩写、简写、下划线构成,总长度要求不超过30位。
  • 字段名以名词或名词短语,字段采用单数形式。若表名由多个单词组成,则取各个单词的缩写组成,单词缩写间使用下划线作为分隔。
  • 若某个字段是引用某个表的外键,则字段名应尽量与源表的字段名保持一致,一面混淆。

5. 安全保密设计需求

5.1 防止用户直接操作数据库的方法

通过把关键应用服务器和数据库服务器进行分离,防止用户对数据库服务器的直接操作,保证数据库安全。

5.2 应用系统的用户口令进行加密

在软件系统中,对于数据的保护、业务操作的许可是通过识别用户身份和权限来完成的。用户口令相比较,相同的话系统将该用户的操作权限分配给用户,用户再根据所分配的权限对系统进行操作。

由以上过程可知,用户口令在传输过程中容易被窃取泄漏,另外如果数据库被非法进入则其中保存的口令能够被非法查看。因此,在传输过程中和数据库中的口令记录字段不应使用明文传递和保存,应该在口令被传递前对其明文口令使用有效的主流技术,对传输数据进行加密部分描述的加密算法进行加密,在加密后传输到系统。系统将用户提交的经过加密的口令数据保存的加密口令进行比较,相一致则进行后续操作。

通过以上措施和过程,证了加密口令即使被窃取仍无法得到原始口令。

5.3 对用户进行权限识别和分级

在XXXXXX平台中,不同的业务不同的人员处理,并且对于不同的操作人员其所能够访问的数据是不同的。

为了保障各功能模块的授权使用和数据不被非法访问,系统划分了不同的操作权限和数据读写等级。系统管理人员可以方便、灵活的将这些权限登记分配给某一个或某一类用户。

当用户登陆时,系统在用户身份验证通过后取得用户的权限,根据用户权限显示相应的功能菜单。当用户对数据进行读、写、删除后浏览操作时,系统判断用户对该数据的访问权限确定是否允许该操作的执行。

 

本文由 @卧枕江山 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
评论
欢迎留言讨论~!
  1. 请问这份设计应该是开发出还是产品经理出?

    回复
    1. 能力出众的(动后端的话)产品经理可以出,如果产品经理这方面的能力不够的话,可以与一名后端开发人员共同完成这项工作。

      回复
  2. yue

    回复
  3. 请路过的朋友们多多支持哈,笔者在这里先谢谢了,以后会有更多优质的文章在这个平台上进行发布,请尽请期待呦!

    回复