敏捷开发框架下的软件工程/第二阶段/数据建模
| 数据建模 |
|
 |
数据是...
为什么有人认为数据是最重要的东西
系统的静态结构 - 就像地图一样
数据库方法的优势 程序-数据独立性 最小化数据冗余 改进数据一致性 改进数据共享 改进数据质量 降低程序维护成本
建模过程
数据建模是设计 需要创造性的解决方案 数据模型是需求的一种解决方案
数据建模很重要 需要蓝图来建造房子
数据建模是一门学科 需要专业的判断
数据建模贯穿整个开发过程。 
实体关系模型: 实体和关联的详细图形表示
关注点纯粹是数据 不是数据发生的事情 描述数据的形式 不是数据值 特定于业务需求
人、地点、物体、事件、概念，对组织来说很重要 单一、明确的名称 学生、书籍、产品
时间 空间 模糊的
一个或多个实体类型实例之间的关联 名字 强大 用一句话来描述关系 可能有属性 - 关联实体
一本书被一位读者借阅 一位读者可以借阅一本书
概念模式 对数据库整体结构的详细、与技术无关的规范 物理模式 从概念模式中存储数据的规格说明，存储在计算机的辅助存储器中
假设我们正在开发一个高中记录系统。从我们最初的需求确定阶段，我们收集了一批材料：班级名单、个人成绩单、班级成绩等等。数据建模的任务是提取信息的底层结构。这就是数据模型。
数据模型的核心是实体。实体是组织持有信息的某样东西。它可以是实际的东西，也可以是像概念（或学生成绩）那样不太具体的东西。请注意，这里的“实体”描述的是事物的通用级别：因此是 STUDENT，而不是 Bob。Bob、Jane 和他们的朋友都是 STUDENT 的实例。
在我们简单的学校里，我们可以轻松识别出三个实体：STUDENT、TEACHER 和 COURSE。
每个实体都由属性描述。这些属性是我们用来描述每个实体实例的。属性有严格的规则，它们需要是独立的，并且不能重复信息。它们还需要是原子性的（不能分解），并且不能依赖于其他值。
在下面的示例中，StudentName 不合适，因为它可以分解为姓和名；StudentAge 没有必要，因为它可以计算出来（手动输入会导致麻烦），StudentGrades 不是原子性的 - 它包含多个值 - 这将不起作用（我们稍后会回到这个问题）。
我们还需要一种方法来唯一地识别每个实例，这将成为实体的主键。它必须是不变的并且是唯一的。我们可以使用姓名，但尽管我们都感觉很特别，但我们的姓名并不唯一。我们可以将姓名与出生日期组合起来，生成一个连接键。不幸的是，日期非常难以处理（9 月 12 日的意义是什么？），而且它不能解决我们的非唯一性问题。因此，我们必须使用一个新值：STUDENT_ID。
我们可以从这些属性中获取相同的信息，并且数据结构更强大。
学生成绩不仅仅是关于学生的信息，它们是关于该学生与课程交互的信息。
学生注册的课程更难解决，但解决方案是基于数据（因此是数据库）方法来理解业务并实施解决方案的核心力量。
在上面的示例中，Bob 只学习地理（明智的选择），所以处理起来很容易。然而，Jane 学习了法语、地理和历史。如果我们尝试将这些信息存储在一个名为 Courses 的属性中，那么提取这些信息非常困难 - 虽然很容易获得 Jane 的课程列表，但获得学习地理的人员列表将非常困难（并且涉及复杂的字符串操作等）。
数据建模的真正优势在于识别关系。关系描述实体之间的关联。我们从在实体之间画一条线开始
我们可以看到 STUDENT 和 COURSE 以及 COURSE 和 TEACHER 之间存在明确的关系。我们可以在图上表示这些关系。沿着箭头方向阅读，这些关联可以用句子表达：“一位 STUDENT 学习这门 COURSE”、“一门 COURSE 由一位 TEACHER 教授”。（我们稍后会讨论数量，当我们查看基数时）。
然而，STUDENT-TEACHER 关联并不那么清晰。关系（至少是我们这里考虑的关系）已经由模型表达。我们可以通过他们教授和注册的 COURSE 来提取哪个老师教授了哪些学生。我们不需要显式的 STUDENT-TEACHER 关系。
即使在这个层面的考虑中，我们也正在被迫仔细考虑我们正在处理的业务。我们可以描述一个 STUDENT-TEACHER-COURSE 模型。为什么我们选择没有 STUDENT-TEACHER 关系而不是没有 STUDENT-COURSE？
我们还需要表达可能参与关系的实例数量。我们使用“乌鸦脚”来做到这一点，乌鸦脚在多端。
这里我们有“许多 STUDENTS 可能学习许多 COURSES”，或者反过来，“许多 COURSES 可能被许多 STUDENTS 学习”。我们在图上用“乌鸦脚”（挂在多端）来表示“许多”。
在概念模型开发的早期阶段，拥有这样的关系是可以的，但我们需要做更多工作才能使其有用。像这样的双端乌鸦脚被称为“非特定关系”，我们知道我们有很多学生和很多课程，但不知道谁在学习什么。
解决这些不连接列表的一种方法是在每个课程的属性中包含学习该课程的人员姓名（如下）。不幸的是，这也不起作用。当有人注册的课程比您之前考虑的更多时会发生什么，结果实际存储在哪里，我们仍然没有办法找出谁注册了地理。
我们需要一个新的实体来表示这种关系。这被称为关联实体。
我们可能在早些时候就识别出来了，因为它在“事物性”方面真的很强。STUDENT 和 COURSE 之间的关系本身也有一些参数：日期、结果、也许还有内部评估成绩等等。关系具有属性这一事实表明它实际上是一个实体。
我们再次回到这个过程在理解业务中的价值。它仅仅是一个实体吗？我们可以想到几个可能的实体名称 - 它们是同一个东西吗。
在某些情况下，多个名称表示多个关联 - 人力资源经理授权支付薪酬（一种关系），但她自己也在工资单上。
这个中间实体显示了学生和课程之间的关联，即注册。当我们实现模型时，注册实体（表）不包含学生的姓名或课程——计算机可以非常有效地获取它们。相反，我们只使用其他实体的主键——它们会变成外键。
但是，我们的模型存在一个缺陷。Jane Smith 似乎在历史课上注册了两次。这不是错误（除了 Jane），而是她第一次考试不及格。为了允许这种情况发生，我们需要表示更多信息，即注册年份。我们的模型可以生成所需的信息，随着开发的进行，它将变得更加有用，因为我们努力使其定义更加严格。
功能需求的主要重点是过程本身，通过开发这样的模型，我们被迫仔细考虑我们正在处理的业务。
此模型描述了工程公司的作业管理系统。
另一个小组为同一个系统制作了这个模型。
图书馆系统。在开发这个模型时，大多数人会想到“书”，但“书”在不同的情况下有不同的含义。是实际的书被借出，但人们实际上想读的是“书名”（以及特定类别，例如大字版）。请注意项目和用户之间关于借阅和预约的两种关系。
该系统描述了农业环境规划系统。
