数据库应用基础

1. 数据库应用基础 第3章 数据模型

2. 第3章数据模型

3. 3.1 数据模型

4. 3.1.1 数据模型的基本概念 • 怎样才能理清并描述各个表自身结构以及表之间的诸多的逻辑联系呢？方法就是建模，描述就用数据模型。 • 模型是对现实或构想的一种表述，在许多情况下模型以图形方式表述而很少使用文字，因为“一幅图胜过千言万语”。 • 人们可以对现有的系统构造模型，这种方法能使人们更好地理解那些系统； • 可以对拟建的系统构造模型，以描述系统的目标、任务、结构，以帮助人们全面、准确的理解和设计新的系统。

5. 两种常见模型 • 过程模型 • 过程模型是一种组织和记录数据的结构和流向的技术，它记录系统的“过程”和由系统的“过程”实现的逻辑、策略和程序，其重点在于描述数据经过哪些加工，发生了哪些转变，从哪里读取和保存。过程模型的成果是生成数据流图（Data Flow Diagram,DFD）。 • 数据模型 • 数据模型是一种组织和记录系统数据的技术，该技术以数据为中心，重点在于描述系统所需的数据以及数据间的联系。数据模型的成果是生成实体联系图（Entity Relationship Diagram，ERD）。 • 因为数据模型通常实现成数据库，所以数据建模有时被称为数据库建模。

6. 数据模型的优越性 数据模型有助于设计人员快速地确定业务词汇。 数据模型几乎总是比过程模型构造得快。 数据模型占用的篇幅比其他模型小，通常可以记在一张纸上，而过程模型则常常需要十几页纸。 过程模型建模经常容易陷入不必要的细节中。 现实系统与拟建系统的数据模型之间的相似性远比它们与过程模型之间的相似性高。

7. 3.1.2 数据模型的主要元素 E-R模型的主要元素是实体、属性、标识符和联系

8. 实体 • 实体 • 指的是某些事物，系统需要存储有关这些事物的数据。 • 实体是可以从用户的工作环境中标识出的，并且是人们想要跟踪的某个事物。 • 实体可以是具体的物体、项目、事件、活动，也可以是抽象的概念、结构、联系等等。 • 实体实例是实体的具体值，一个实体应该拥有一个以上的实例。

9. 实例1 考试成绩（实体） 实例2 051会计（1） 20050313005 李雪 管理信息系统 89 051金融（1） 20050512018 张毓敏 管理信息系统 75 班级 学号 姓名 课程 成绩 实体与实体实例

10. 确定实体 一般来说，确定实体既要考虑到实体自身的因素，也要考虑到实体间的联系因素；既要考虑到实体的逻辑意义，也要考虑到实现数据库时相关的物理意义。 开始建立E-R模型的最好方法是确定潜在的实体。实体通常由文档或访谈中的名词（地点、人物、概念、事件、设备等）表述。

11. 属性 • 属性是实体的描述性性质或特征，特征是具有相对重要意义的某一方面情况的描述结果。每个实体有描述它们特征的一个或多个属性。 • 成为一个实体属性的因素应该是具有特殊性质的项目，这些项目是在进行某种业务处理时所关注的。也就是说，选择属性是根据所要表述的“事物”的主题来决定的，一般来说，与主题无关的项目是不选做其属性的。

12. 选择属性 • 属性的自身也有一定的结构，其结构也影响着对特征的表述。多数情况下，使用已知的简单的且单值数据项目作为属性。 • 所谓简单，是指它们仅由不可分割的单一数据项目组成；所谓单值，是指在每一个实例中，该属性仅有一个值。

13. 定义属性 • 当分析系统、建立数据模型时，应该为属性定义合法或者有业务含义的值。 • 每个属性的值按照三种性质定义： • 数据类型 • 属性的数据类型定义了这个属性中可以存储什么类型的数据。 • 域 • 属性的域定义了这个属性可以取的合法值。 • 默认值 • 如果用户没有为某个实例的该属性指定值的话，就将默认值作为其值。

14. 标识符 为了便于准确区分不同的实体实例，每个实体必须具有一个标识符。 标识符如果是惟一的，则它能且只能标识一个实例。 标识符由一个或多个属性组成。 由两个或多个属性构成的标识符叫组合标识符。

15. 键 • 键: 唯一标识符的同义词. • PK • PK的意思为主键（Primary Key），即所标注的属性为主键。 • 通常主键用以惟一标识实体实例 • 一个实体可能有多个键。就是说，一个实体有若干个的属性或属性组都可以作为键。具有这种特点的属性或者是一组属性都可以称为候选键。 • 主键是最常被用来惟一地确定一个实体实例的候选键，没有被选做主键的其它任何候选键都称做次键，或者替代键（Alternate Key）。

16. 键的选择与组成 • 在每个实体实例的生命期中，一个键的值不应该改变。 • 键的值不能为空。 • 键的作用是惟一标识一个实体实例。 • 键值的编码要有一定的规则。 • 使用代理键。 • 当独立实体中复合键涉及到太多的属性时，可以考虑使用代理键来代替它。代理键是为解决实体的标识问题而增加的属性，当实体没有明确或者简洁的键时，可以采用自然编码的方式来建立代理键。

17. 编码要点 编码应该可扩展。 全部编码应该对每个实体实例指定一个惟一的值。 编码应该足够大（位数足够多），以便描述有区别的特征。 编码应该方便使用，即在需要为新实例设置编码时容易创建。

18. 选修课程 在修学生 学生 课程 拥有学生 专业 学生 联系 系统中的实体都不是孤立存在的，实体各自代表的事物间互相交流并且互相影响，共同支持业务的正常运行。 联系，是存在于一个或多个实体之间的自然业务联系。联系可以表示链接实体的一个事件，或者仅仅是存在于实体之间的逻辑关系。

19. 选修课程 在修学生 学生 课程 拥有学生 专业 学生 联系 所有的联系都隐含为双向的，意味着它们可以从联系的两个方向上进行解释，并且可以用动词短语来描述。 联系应该使用动词词组和实体名称的组合命名，形成一个简单的业务语句或判断。

20. 专业 学生 联系 A B 所谓父实体就是在联系涉及的实体中存在这种情况，A实体的一个实例可以联系到B实体的多个实例，但是，B实体的一个实例仅可联系到A实体的一个实例，那么，A实体就是B实体的父实体，B实体就是A实体的子实体。

21. 基数含义 最大实例数 图形化符号 最小实例数 1 正好一个 1 零或一个 0 1 一或多个 1 N 0 零或多个 N 联系的基数 基数定义了一个实体相对于另一个与之关联的实体的某个具体值的(实例)最小和最大数量，同时，因为所有的联系都是双向的，所以对于每个联系在两个方向上都必须定义基数。

22. 入住学生 使用汽车 汽车 雇员 宿舍 学生 1:1 联系 1:N 联系 诊治病人 就诊医生 医生 病人 M:N 联系 联系的类型

23. 入住学生 宿舍 学生 二元联系 前置课程 下属职工 职工 课程 (b) (a) 一元(递归)联系 联系的度数 联系的度数是参与那个联系的实体数量。

24. 班级 课程 授课 教师 教室 四元联系 关联实体 • 关联实体是一个从多个其他实体（也称为父实体）继承其主键的实体。 • 也就是说关联实体包含有相关的几个实体的主键属性。关联实体的键是复合键，由各父实体的主键组合而成。

25. 外键 • 外键（ Foreign Key ）为来自另外一个实体的主键，它被复制到该实体以确定相关两个实体间存在的一个联系。 • 通常，把贡献出自己主键的实体叫做父实体，而把接受者称做子实体，子实体中的外键总是匹配父实体中的主键。

26. 非特定联系 多对多联系也称做非特定联系，是一个实体的多个实例同另一个实体的多个实例相关联的联系，这种联系仅仅适用于初始数据模型中，并应该尽快地分解掉。 多数多对多联系可以分解成两个一对多联系，原有的每个实体都成为父实体，引入一个新的关联实体作为它们的子实体。

27. 3.1.3 弱实体 强实体 弱实体 在数据库中的存在情况依赖于其他实体的存在情况的实体是弱实体，否则就是强实体。

28. 非确定性联系和确定性联系 • 实体间联系的连线形式描述了相连的两个实体间的非确定性联系和确定性联系。 • 所谓非确定性联系，是每个参与联系的实体都有各自的独立主键的联系，这时的实体就属于强实体。如果，外键参与子实体作为其主键的一部分，父实体和子实体之间的联系被称为确定性联系，这时的子实体就是弱实体。 • 通常，两个实体间的非确定性联系在E-R图中表现为用虚线连接，确定性联系表现为用实线连接。

29. 3.2 数据建模过程

30. 3.2.1 获取实体 • 获取实体是数据建模的第一项任务，这个任务相对容易。完成此任务需要获取系统中的基本实体，这些基本实体由数据描述，或者可能由数据描述。 • 在与用户的面谈或商讨会议期间，注意他们讨论中的关键词。 • 专门地要求系统所有者和用户确定那些他们想收集、存储和产生信息的事物。那些事物常常表示了应该在数据模型中描述的实体。 • 研究现有的表格、文件和报告。 当实体被发现时，给它们设置简单的、有意义的、面向业务的名字。实体应该用描述有关存储数据的人、事件、地点、对象或者事物的名词来命名。尽量不要简写或者使用缩写词。为了更好地描述实体，名字可以包含合适的形容词或者短语。实体应该按照业务词汇定义，不要用技术词汇定义实体，也不要定义成“关于…的数据”。

31. 3.2.1 获取实体 • 获取实体是数据建模的第一项任务，这个任务相对容易。完成此任务需要获取系统中的基本实体，这些基本实体由数据描述，或者可能由数据描述。 • 在与用户的面谈或商讨会议期间，注意他们讨论中的关键词。 • 专门地要求系统所有者和用户确定那些他们想收集、存储和产生信息的事物。那些事物常常表示了应该在数据模型中描述的实体。 • 研究现有的表格、文件和报告。 当实体被发现时，给它们设置简单的、有意义的、面向业务的名字。实体应该用描述有关存储数据的人、事件、地点、对象或者事物的名词来命名。尽量不要简写或者使用缩写词。为了更好地描述实体，名字可以包含合适的形容词或者短语。实体应该按照业务词汇定义，不要用技术词汇定义实体，也不要定义成“关于…的数据”。

32. 3.2.1 获取实体 学院、班级、学生、教师、课程、教室、场次

33. 班级 学院 课程 教室 教师 学生 场次 3.2.2 上下文数据模型 上下文数据模型仅仅包括实体和联系，而不包括实体的属性，其目的是提炼对系统项目范围的理解，而不是获取实体的细节和业务规则的细节。 在这时的实体间可能会有一些多对多的联系。

34. 3.2.3基于键的数据模型 • 主要完成两个任务 • 通过增加关联实体的方法消除多对多联系； • 确定每个实体的主键，并通过外键描述实体间如何联系。

35. 3.2.4 具有完整属性的数据模型 具有完整属性的数据模型包括了所有描述性属性，每个属性都用数据类型、域和默认值定义在资料库中。

36. 3.2.4 具有完整属性的数据模型 • 对数据模型进行检查，看看它是否能提供所需数据。该模型存储的数据能回答以下问题吗？ • 某个学院有哪些教师； • 某一门课共有多少学生参加考试； • 某个教室安排了几场考试； • 某个教师具体的监考日程情况； • 某个学生要参加哪几场考试； • 等等。 • 当模型不能提供问题的答案，设计就有可能出了问题，如果问题是必须回答的，那么就必须修改模型。

37. 3.3 评价数据模型 • 数据模型可以用来有效地描述和沟通系统的数据库需求，但它不一定就代表了一个好的数据库设计。数据模型中的某些结构特征可能会降低模型的灵活性和扩展性，或者产生不必要的冗余，因此必须为数据库设计和实现准备好合理的、高质量的数据模型。 • 可以参考以下的评价标准 • 好的数据模型应该是简单的 • 好的数据模型基本上是无冗余的 • 好的数据模型应该是灵活的而且对未来的需求具有可适应性