第8章数据建模和分析

1、数据建模和分析

1.1数据建模简介

数据建模是一种为数据库定义业务需求的技术。因为数据模型最终要实现成数据库，所以数据建模也称为数据库建模。
下图是一个简单的数据模型，称为实体关系图（ER图）

1.2数据建模的系统概念

实体关系图（Entity Relationship Diagram ，ERD）提供了表示实体类型、属性和关系的方法，用来描述现实世界概念模型。

实体关系图.png

1.2.1 实体

实体（Entity）是我们需要收集数据和存储数据的人、地点、对象、事件或概念的类。
强实体: 实体拥有自己独立的主键。
弱实体：父实体贡献其主键称为子实体的一部分，子实体被称为若实体。

实体.png
公司拥有独立主键是强实体，劳动合同使用了父实体的主键（公司ID）是弱实体。

1.2.2 属性

属性：描述实体的性质或特征，比如实体Student的每个实例都可以用以下属性描述：Name、Age、Sex。 每个属性值按照三种性质定义：数据类型、域、默认值。
域： 定义了这个属性可以取的合法值。最终，系统设计人员必须使用相应计数据来强制所有属性的业务域。
默认值：每个属性都应该有默认值，属性的默认值是用户没有录入指定值时被记录在属性中的值，比如下图中的性别默认为“男”，日期默认为“空”
标识符：也可称为主键或组合键，一个实体有很多实例，有必要根据一个或多个属性的数据值唯一的标识每个实例。 比如受检者Id就是受检者的唯一标识符。

图片.png

1.2.3 实体关系

关系：关系是存在一个或多个实体之间的自然业务联系。包括关联关系、包含关系、继承关系、依赖关系、递归关系、三角关系（创建关联实体）

图片.png

基数：定义了了一个实体相对于另一个关联实体的最大值和最小值数量。
常见的对应关系有一对一、一对多、多对多。当然对应关系中也可能出现0的情况，比如新建一个部门，还没有招人，部门和人员的关系就可以表示为1对0..*

图片.png

度数：度数是参与关系的实体数量。例如上图中有部门、员工两个实体，度数就是2。 如果采用递归的方式看一个文件夹中有多少个文件夹，只有文件夹一个实体，度数就是1。如果是要看一个文件夹中有多少个文件，则有文件夹、文件两个实体，度数是2.

图片.png

外键：外键是一个实体的主键，他被贡献给（复制给）另一个实体以确定一个关系实例。

外键.png

非确定性关系： 每个参与关系的实体都有各自独立的主键，不共享主键属性，如上图公司和雇员就是就是非确定关系。

确定性关系：父实体贡献其主键成为子实体的外键，任何确定性关系的子实体经常被称为弱实体，因为其依赖于父实体的存在，比如公司ID作为劳动合同的外键，劳动合同依赖于公司，所以劳动合同是弱实体。

关联实体：关联类是对两个类的关系的进一步约束。比如最开始你可能认为薪金、职位、合同期限似乎应该是雇员的属性，经过思考，你可能意识到这三个关键属性应该体现在员工和雇员的的关系上，体现在劳动合同上。通过劳动合同这个案例，我们意识到，在绘制ER图的时候，最好把实体的属性描述出来，这个有助于我们完善实体关系，找出隐含的关联类

识别关联类的实践建议
1）如果觉得两个类有关系，则先拉一条直线再说。
2）如果觉得这两个类有关系，但怎么画都觉得不合适，那么可以思考是不是漏了一个关联类。
3）分别列出这两个类的关键属性，思考这些属性的属性值是不是由该类本身就可以确定了。例如：如果我们最开始将薪金作为员工的属性，你就可以思考薪金的数字是不是员工本身可以确定的？ 你会发现薪金其实是公司和员工商定后确定的，并不是员工自身可以决定的。
4）通过对属性的思考，可能会发现这个属性应该属于另一个类的，思考这个类是不是表征这两个类的关联类。

1.3 逻辑数据建模过程

数据建模可以在各种类型的项目中进行，也可以在项目的多个阶段中进行。数据模型是不断累积的，对于一个企业或应用来说，不存在“最终的”数据模型。相反，一个数据模型应该被看做是一个活动的文档，它将随着需求的变化而变化。理想情况下，数据模型应该存储在资料库中，以便可以随时访问、扩充和编辑。下面介绍系统计划和分析期间如何进行数据建模。

数据建模各阶段的产物.png

1.3.1 战略数据建模

许多组织根据战略信息系统规划选择开发项目。战略规划是一个独立的项目，这个项目生成了一个信息系统战略规划，它定义了一个用于信息系统的整体构想和架构。这个架构几乎都会包括一个企业数据模型，信息工程是一种包含了这种方法的方法学。
企业数据模型标识了最基本的实体，这些实体被一般地定义（如在一个字典中），不会以键或属性的形式进行描述。

1.3.1 系统分析期间数据建模

在系统分析阶段就数据建模而言主要考虑逻辑数据建模，单个信息系统的数据模型常称为*应用数据模型。

数据模型很少在系统分析的范围定义阶段构造，这个阶段在较短的工作时间进行及那么是不现实的。

问题分析阶段的模型应该仅仅包含实体和关系，而不包括属性，这称为上下文数据模型，其目的是提炼我们对项目范围的理解，而不是获取实体和业务规则的细节，其中许多关系都是非特定关系（多对多的关系）。

1、需求分析阶段可以得出一个逻辑数据模型，这个模型按以下步骤开发。

逻辑数据模型构建步骤.png

1）获取实体
2）我们从构造上下文数据模型开始确立项目范围。如果上下文数据模型再系统分析期间已经开发出来，那么可以修改模型以反映新的需求和项目范围。
3）绘制一个基于键的数据模型，这个模型讲消除非特定关系，增加关联实体，并包括主键和替代键。这个基于键的数据模型还将包括精确的基数和泛化层次
4）构造一个具有完整属性的数据模型。这个属性完整的数据模型包含了所有描述性属性和子集准则。每个属性的数据类型、域、默认值在会被定义并存在资料库
5）通过一个称为规范化的过程分析数据模型的适应性和灵活性。最终经过分析后的数据模型被称为规范化的数据模型，规范化指的是第一范式、第二范式、第三范式。

1.3.1.1 获取实体

1、获取实体的途径
1）业务功能
2）业务流程
3）业务规则
4）用户访谈过程中，系统所有者和用户面谈或JRP会议期间，讨论到的关键词。
5）研究系统相关的表格、文件和报告。

2、获取实体，并定义实体名词，同时描述实体的业务定义。应该按照业务逻辑定义实体，不要用技术词汇定义。明确清晰的业务实体定义有助于相关人员快速了解系统。以下是某运输公司报价系统的业务实体

业务实体定义

1.3.1.2 构建数据模型

1、构建数据模型
下图将步骤2、3、4绘制在了一起。
步骤2 问题分析阶段，绘制上下文数据模型时只包括公司、雇员两个实体
步骤3 需求分析阶段，基于键的数据模型,会加入主键和外键
步骤4 需求分析阶段，构造一个具有完整属性的数据模型，包含所有描述性属性和子集准则
步骤5，数据模型分析，构造满足第一范式、第二范式、第三范式的数据模型，产出物是规范化的数据模型。

图片.png

2、数据库设计

本章的重点是信息系统的数据库设计和初步构造，前置条件是来自第8章的数据需求模型，交付成果是一个数据库设计模式和数据库定义程序。

2.1、系统分析员的数据库概念

2.1.1 字段

字段是数据属性的物理实现，是数据库中有意义数据的最小单元。系统可存储4类字段：主键、次键、外键、描述性字段(非键字段)
主键：其值是唯一确定文件中的一条记录的字段，比如Customer Number，Order ID
次键：数据库的替代标识符，次键的值可以标识一条记录或者所有记录的一个子集（例如【订单状态】字段值待付款、待收货）
外键：指向数据库中里一个文件记录的指针，比如订单记录中包含了外键 UserId，用来指向订单记录相关的用户记录
描述性字段：存储业务数据的字段，比如用户表中，一些描述性字段包括地址、年龄、性别

2.1.2 文件和表

记录：是文件或数据库中的一条数据，记录时按照预定义格式安排的字段集合
文件：相似的记录被组织成文件。在数据库系统中，文件经常被称为表。文件是给定记录结构的所有具体值的集合。

2.1.3、数据库

2.1.3.1数据架构

1、数据架构是什么？
1）数据架构定义了企业如何开发、使用文件和数据库以存储组织中的所有数据
2）要使用的文件和数据库技术 (比如数据仓库、数据库管理系统DBMS)
3）管理数据资源的管理机构

数据架构

2、数据仓库
存储从运行数据库和常规文件中提取数据，用户可以在数据仓库的基础上进行数据挖掘。 数据仓库可以规避用户直接对用户对运行数据库访问、查询、生成报告带来的数据过载的风险

3、数据资源管理人员
数据管理员：负责数据规划、数据定义、数据架构、数据管理。
数据库管理员：负责数据库技术，数据库设计和构造咨询，安全、备份和恢复，以及性能调试。

2.1.3.2数据库架构

数据库架构是指数据库技术，包括数据库引擎、数据库工具、用于分析和设计数据库CASE工具及数据库应用开发工具。 数据库架构的控制中心是其数据库管理系统(DBMS)

数据管理系统架构

下图是一个物理关系数据库

实体关系图-逻辑数据库模型 物理数据库模型