对数据关系进行建模
在设计阶段创建ERD时，其实也是在定义系统数据库的逻辑结构或物理（实现）结构。从分析阶段开始完成的视图能够扩展或者完善对系统的理解和优化系统实现。
ERD
实体
实体本来可以代表物理上的实体（包括人）、对待分析业务或者待实现系统至关重要的数据聚合。
在ERD中实体被命名为一个单数的名词，显示在矩形框内。
属性
每个实体都有一个或多个属性，实体的不同实例具有不同的属性值。
逻辑关系
ERD图中，菱形表示实体之间的逻辑关系，通常用自然含义来命名
数量关系
一对一
一对多
如一个申请人，可以提出多个化学品申请。但是一个化学品申请，只能属于一个申请人，即在化学品申请单中，不允许同时出现两个申请名字。
用字母M或N表示多个，包含1。
多对多
如一个化学品申请中，可以列出多个化学品，共申请人选择，一次申请中可以选择多个化学品。当然这些被选择后的化学品，同时也可以在另外的申请中被再次选择。
用字母M或N表示多个，包含1。
功能
实体之间的关系通常会揭示出这类功能。化学品容器与容器历史信息这两个实体间是一种“跟踪”关系，我们需要某些功能（描述这些功能的形式可能是一个用例、一个用户故事或者一个流程图）来让用户方位某个特定化学品容器的历史信息。
UML 类图
使用面向对象开发方法的团队通常化UML类图表示各个类中的数据属性、类之间的逻辑关系以及这些关系上的数量关系。类图与ERD中的实体相对应
![[UML类图.png]]
数据字典
数据字典是应用中会用到的关于数据实体的详细信息之集合。数据的构成、数据类型、允许的取值等信息收集成一个公共资源，相比确定数据验证标准，者有助于开发人员正确写程序并使集成中出现的问题最小化。
数据分析
CRUD矩阵
crud矩阵是一种严格的数据分析技术，可以检测出遗漏的需求。
- C：创建（Create）
- R：读取（Read）
- U：更新（Update）
- D：删除（delete）
CRUD矩阵将系统行为与数据实体联系在一起，表示每个重要的数据实体应该如何创建、读取、更新以及操作。
CRUD的不同关联
- 数据实体和系统事件
- 数据实体和用户任务或者用例
- 对象类和用例
| 用例/实体 | 订单 | 化学品 | 申请人 | 供货商名录 |
|---|---|---|---|---|
| 提出订单 | C | R | R | R |
| 修改订单 | U,D | R | R | |
| 管理化学品库存清单 | C,U,D | |||
| 订单报表 | R | R | R | |
| 编辑申请人 | C,U | |||
| 上表中，申请人这一列没有D，也就是申请没有哪个用例可以删除，可能的解释如下： |
- 申请人删除的功能不是期望的功能，即申请人这个实体，是必不可少的。
- 遗漏了删除申请人这个用例
- 编辑申请人是一个不完整的用例，遗漏了删除申请人的功能。
报表的规范说明
许多应用都从一个或者多个数据库、文件或者其他信息源生成报表。报表包括由数据行与数据列构成的传统表格、各种类型的示意图和曲线图或者各种组合类型的图表。
报表规范说明横跨需求（报表怎么使用数据，怎么组织数据）和设计（报表的外观样式）两个部分。
获取报表需求
- 当前使用的是什么报表？
- 报表是现有系统生成的，还是业务手工生成的？
- 现有的报表需要在新系统中重复使用吗？
- 现有的报表中哪些需要进一步修改？
- 新建或优化现有信息同，有机会修改不能满足的报表。
- 当前生成了哪些没用的报表？
- 新系统中也许不需要实现他们。
- 描述报表必须遵守的任何部门标准或组织标准或政府标准？
- 提供一个一致的版式或者遵循一个规章。
- 获得一些副本或与之相符的现成报表样例。
报表外化信息
- 报表名称时什么？
- 报表的目的或业务上的意图是什么？报表的使用者如何使用这些信息？谁会依照报表来做出什么决策？
- 报表是手动生成吗？如果是，又由哪个用户类型生成？多久生成一次？
- 报表是自动生成的吗？如果是，生成的频率如何？他们报表生成的驱动条件或者事件时什么？
- 报表的标准大小或者最大大小是什么？
- 我们需要一个能够展示多个报表或者图表的显示面板吗？如果是，用户还需要对显示面板上的数据元素进行具体查看或者概览吗？
- 报表申城以后放在何处？是将它显示在屏幕上、发送给接受者、导出到电子表格还是将他自动打印出来？为了以后读取报表，需要将他们保存或者归档到某个位置吗？
- 在访问报表时是否存在一些安全上的、隐私方面的或者管理上的限制，而这些限制是针对某些特定的个人，还是用户类型？或者说没有这方面的限制使生成报表的人可以决定报表需要包含哪些数据？识别出涉及安全的所有业务规则。
报表内化信息
- 数据源有哪些？从库中拉取数据的过滤条件是什么？
- 用户可以选择的参数有哪些？
- 排序、分页和数据求和的标准是什么？
- 生成报表过程中，一个查询如果没有返回数据，系统会对此做出怎样的响应？
- 对于临时报表，报表的基础数据对用户来说可见吗？
- 这个报表可以作为一些列相似的报表的模板吗？
对报表需求规范的思考
- 考虑其他变量
- 优化或增强报表功能，提升业务价值
- 简单的优化，如改变排序规则，需要提供排序的工具
- 对数据进行摘要或进一步挖掘数据。
- 摘要报表能够将具体的结果细节聚合成一个更为简洁的概要视图。
- 数据挖掘的意思是生成一个报表来显示总结性的数据的源数据明细。
- 找到数据
- 保证有供系统生成报表的必要数据。
- 用户从生成他们期望的输出这一角度来思考问题，这意味着要有一些能够产生必要数据的特定输入和信息源。
- 这样的分析可以揭示出访问者生成所需数据的位置需求
- 还要识别将要应用于计算输出数据的业务规则。
- 预期的扩大
- 用户可能会基于他们对设计数据的多少或参数的多少的初步概念来提出一些特定的报表需求。
- 原来在少量数据下工作良好的报表可能会变得不在能够胜任。
- 如少量数据时，报表或图表展示正常。当数据量翻倍时，会显示错乱。
- 寻找相似性
- 不同的用户或者同一个用户可能会提出一个相似但不完全相同的报表需求。
- 是否存在一个灵活的报表来满足不同需求，节约开发维护成本。
- 尝试找出这个报表的可能性以便将相似但不完全不相同的需求合并在一个报表中。
- 参数能够提供一些必要的用户灵活性，有时能够通过参数来处理这些不同的需求
- 区别静态报表和动态报表
- 静态报表会刻印或者显示某一时间点的数据。
- 动态报表提供的是交互的、实时的数据，当基础数据发生变化时，系统将自动更新报表的显示。
- 原型报表
- 为演示一个可能的方案借此激发用户反馈时，仿制一个报表通常是有价值的（可废弃原型）。
- 或为演示一个预期的布局而使用现成的相似报表也是一个好方法。
- 在讨论续期中生成这些原型，能够使参与需求的人提出设计约束，这些约束可能是预期的也可能是没有预料的约束。
- 在设计过程中，开发人员会创建一个简单的报表布局来征求客户的反馈（迭代原型）
- 在仿制报表中使用合理的数据能够让评估它的用户感觉更真实
报表规范说明模板
| 报表元素 | 元素描述 |
|---|---|
| 报表ID | 用来识别报表或者分类报表的编号、代号或者标签 |
| 报表标题 |
|
| 报表用途 | 对报表缘由的项目、背景、上下文或者业务需要进行简要介绍 |
| 由报表而做出的决定 | 使用报表中的信息而做出的业务决策 |
| 优先级 | 实现该报表功能的相对有限顺序 |
| 报表用户 |
|
| 数据源 | 表示数据获取源的应用、文件、数据库等 |
| 频率以及处置方式 |
|
| 影响性能 |
|
| 直观布局 |
|
| 页眉与页脚 | 下面各项常常出现在报表页面或者页脚中的某个位置。对于包括的每个元素，我们要确定他在页面中的位置和外观。包括字体大小、样式、文本的加亮显示、颜色、大小写以及文本对齐方式。当标题或者其他的内容超出分配给他的空间时，是应被截断、换行还是做其他处理？
|
| 报表正体 |
|
| 报表结束标志 | 出现在报表结束位置的每个指标符的外观和位置 |
| 互动性 |
|
| 访问安安全方面的限制 | 哪些个人、团队或者组织有权限生成或者查看报表的任何限制，还有他们有权选择哪些数据并将其包括进来的相关限制条件。 |
