数据库设计漫谈
（2nd Edition）
青岛海洋地质研究所 戴勤奋
目 录
序 .......................................................................... I １ 什么是数据库 ............................................................ １ 1.1 数据库的定义 .......................................................... １ 1.2 数据模型发展历程 ...................................................... ２ 1.2.1 网状与层状数据模型................................................ ２ 1.2.2 关系数据模型...................................................... ２ 1.2.3 面向对象数据模型.................................................. ３ 1.2.4 后关系数据模型.................................................... ４ 2 数据模型设计 ............................................................. ６ 2.1 整体框架约束下的迭代渐进 .............................................. ７ 2.2 数据总体结构设计 ...................................................... ９ 2.2.1 工作流与数据流分析.............................................. １２ 2.2.2 面向对象分析与设计.............................................. １６ 2.3 概念数据模型设计 .................................................... ２４ 2.3.1 关于概念数据模型设计元素........................................ ２５ 2.3.1.1 关于概念与实体的含义........................................ ２５ 2.3.1.2 关于概念层与物理层.......................................... ２６ 2.3.1.3 关于范式.................................................... ２６ 2.3.1.4 关于属性定义................................................ ２７ 2.3.1.5 关于属性的域................................................ ２８ 2.3.1.6 关于联系定义................................................ ２９ 2.3.1.7 关于主键设计................................................ ３１ 2.3.1.8 关于外键设计................................................ ３１ 2.3.1.9 关于可取值列表.............................................. ３２ 2.3.2 实体关系图与数据字典............................................ ３２ 2.3.3 Geodatabase 数据库数据模型设计 .................................. ３９ 2.3.3.1 Geodatabase 框架结构元素 .................................... ４１ 2.3.3.2 划分专题及其要素类.......................................... ４２ 2.3.3.3 要素类定义.................................................... 45 2.3.3.4 要素分类编码.................................................. 45 2.3.3.5 拓扑规则定义.................................................. 48 2.3.4 测试与优化........................................................ 50 2.4 构建数据库模式 ....................................................... 51 2.4.1 什么是数据库模式.................................................. 52 2.4.2 什么是数据完整性.................................................. 53 2.4.3 Oracle 表空间部署 ................................................. 55 2.4.4 数据库模式对象部署................................................ 56 2.4.4.1 表及其约束.................................................... 57 2.4.4.2 索引.......................................................... 58
I
2.4.4.3 同义词........................................................ 59 2.4.4.4 视图 ......................................................... 59 2.4.4.5 存储过程或函数 ............................................... 59 2.4.4.6 触发器........................................................ 60 2.4.4.7 包 ........................................................... 61 2.4.5 数据库重构........................................................ 62 3 元数据设计 ............................................................... 63 3.1 元数据标准定制 ........................................................ 65 3.2 元数据内容 ............................................................ 66 3.3 元数据 XML 格式化 ...................................................... 67 3.3.1 XML 来源 .......................................................... 68 3.3.2 XML 有效性验证 .................................................... 68 3.3.3 XML 显示 .......................................................... 69 3.3.4 XML 格式元数据的实现 .............................................. 69 3.4 元数据编辑器 .......................................................... 71 3.5 一个元数据样式显示的核心元数据 ........................................ 72 3.6 一个元数据样式显示的完整元数据 ........................................ 74 4 应用架构设计与实例 ....................................................... 84 4.1 DINO 生存环境 ......................................................... 86 4.2 DINO 设计目标 ......................................................... 88 4.3 DINO 功能架构 ......................................................... 89 4.3.1 数据存储.......................................................... 89 4.3.2 数据管理.......................................................... 90 4.3.3 数据分发.......................................................... 91 4.4 DINO 技术架构 ......................................................... 94 4.4.1 数据存储层........................................................ 95 4.4.2 应用服务层........................................................ 95 4.4.3 前端服务层........................................................ 96 5 结束语 ................................................................... 98
II
序
我开始学着做数据库设计时把这项工作想得很简单，觉得数据库设计就是设计几个数 据表而已。随着工作的深入，发现并非如此，要建立一个性能良好、可扩展、经得起时间 考验的数据模型不容易，因为这是一个系统工程，做系统工程需要统筹，需要权衡，需要 在各种冲突中寻求折中方案。因此与其说数据库设计是科学，倒不如说是一门艺术，权衡 的艺术。 目前数据库在商业领域演绎得很成功，已经到了离不开数据库的地步，但在科研领域 并非如此，虽然近几年对数据库的重视程度有所提高，但实际上数据库也只是先进科技的 标志而已，数据重利用程度并不高，其中的原因是多方面的。但不管什么原因，数据库设 计在其中举足轻重，因此这里想就此谈谈我自己的体会，从比较基础的层面上来谈，希望 能对像我这样半路出家的数据库设计人员有用。 2008 年 10 月
暑假期间，我孩子有意看看我写的数据库设计工作体会，因而把三年前写的书又翻了 出来，以三年后的眼光重新审视，并作了修改，是为记。 2011 年 8 月
戴勤奋
I
１ 什么是数据库
1.1 数据库的定义
经常有人问我： “你们的数据库到底能干什么？” ；每年申请课题时会有课题负责要求 我写一段描述数据库重要性及先进性的文字插入他们的课题申请报告中；每当课题结束时 会有上级要求我们把数据库放到光盘里上交资料档案室（一直觉得这种要求挺怪的） 。这几 年，数据库在各种场合频频出现，科学数据共享、数字地球、数字海洋等等都离不开数据 库，但其实大家对数据库了解并不多。当然一般的数据库用户不需要去了解，但对科研决 策的制订者以及数据库建设人员来讲，给出数据库的准确定义将有助于工作的正确导向。 因此开门见山，先谈谈“什么是数据库” 。 韦氏大词典上说： “Database is a large collection of data in a computer,organized so that it can be expanded,updated,and retrieved rapidlly for various uses.” （数 据库是大量数据的集合，它们存储在计算机中，有组织，可扩展，并能快速更新、存取， 服务于不同的用户。 ） 从上述定义可知，数据库是能有效存储大量数据并提供数据应用服务的技术。但是现 实世界丰富多彩、错综复杂，数据库这一应用技术通过什么途径来实现繁杂数据的有效存 储与服务呢？从科学探索到市井生活，解决复杂问题的常规方法基本上都是由大化小，由 难化易，由特殊到共性，于是就有了数据库技术的核心和基础——数据模型，通过数据模 型抽取问题域的本质特征，将现实领域简化在我们的掌控之中。因此，数据库又可进一步 定义为：数据库是通过数据模型简化数据对象实现数据有效操作的应用技术。
数据库是通过数据模型简化数据对象实现数据有效操作的应用技术。
“数据模型+数据”是规范化后的数据； “数据有效操作”是对数据的快速检索和更新， 实际上是为了支持一个或多个工作流程，也就是为了实现应用，因此数据库可划分为两大 部分：数据和应用，数据库设计也即划分为两大部分：数据模型设计和数据库应用架构设 计。数据模型设计是将现实领域限制在数据模型的框架和约束下，让数据成为规范化数据，
１
为实现数据有效操作奠定基础；而数据库应用开发就是搭建良好的平台，让数据能得到大 范围共享与重利用。数据与应用是相互依托的，后台存储的数据是应用的支撑，前台的应 用是数据的表现，数据库技术的最高境界是让数据走出数据库活动在应用流程中。
数据库技术的最高境界是让数据走出数据库活动在应用流程中。
1.2 数据模型发展历程
过去几个世纪，数学家和物理学家们通过模型来简化复杂的自然现象，从模型中抽取 现象的各种研究特征，并通过实验来验证，使数学和物理学取得了巨大的进展，数据库技 术也有着同样的发展历程。
1.2.1 网状与层状数据模型
1961 年美国通用电气公司 Charles Bachman 等人开发出世界上第一个网状模型的数据 库管理系统 IDS（Integrated Data Store，集成数据存储） ，为网状模型数据库的发展奠定 了基础。 网状数据库模型对于层次和非层次结构的对象都能比较自然的模拟，在关系数据库出 现之前网状数据库管理系统要比层状数据库管理系统用得普遍。在数据库发展史上，网状 数据库占有重要地位。 1969 年 IBM 公司 Mc Gee 等人研制出层次模型（树型结构）的数据库管理系统 IMS （Information Management System，信息管理系统） ，成为最典型的层次型数据库管理系 统。 网状数据库和层次数据库都很好地解决了数据的集中和共享问题，但在数据独立性和 抽象性上有很大欠缺。
1.2.2 关系数据模型
1970 年，IBM 公司 San Jose 研究所的 E.F.Codd 博士发表了题为“A Relational Model
２
of Data for Large Shared Data Bank”（大型共享数据库数据关系模型）的著名论文， 开创了数据库的关系方法和关系规范化理论的研究，他本人因此荣获 1981 年国际计算机协 会（ACM）图灵奖。 由于关系模型有严格的数学基础，抽象级别比较高，而且结构简单，便于理解和使用， 对数据库的发展起到了至关重要的作用。 七十年代中期，IBM San Jose 研究所在 IBM 370 系列上研制了 System R 关系型数据库 管理系统；加州大学伯克莱分校在 Vax 系列机上实现了 Ingres 关系型数据库管理系统。上 世纪 80 年代中期，我在 Dual 68000 机上用的数据库就是 UNIX 系统上的 Ingres,它的代码 可以免费获得，因此后来不少公司使用这些代码形成了自己的产品线，例如 Informix、 Sybase、MS SQLServer 等，可说 Ingres 是历史上最有影响的计算机研究项目之一。这些早 期的实验性系统在关系数据库管理系统的实现和系统性能方面作了大量工作,为数据库商 业应用奠定了基础。 1976 年 HONEYWELL 公司推出了第一个商用关系数据库产品 Multics Relational Data Store。 1979 年 Oracle 公司推出了第一个商用 SQL 关系数据库管理系统，Oracle V2.0。 1983 年 IBM 推出了 DB2 for MVS V1 关系数据库产品。 大量商品化关系数据库系统的问世及推广，使得关系数据库的应用深入到人类生活的 各个领域。经过几十年的发展，关系数据库技术已经相当成熟，但是关系数据模型在处理 非结构化数据方面始终是心有余而力不足。随着网络技术的发展，WEB 页面、电子邮件、音 频、视频等非结构化数据爆炸式增长，关系数据模型在速度和性能方面的局限性也越来越 明显。
1.2.3 面向对象数据模型
九十年代，受当时面向对象技术风潮的影响，人们把大量的精力投入到面向对象的数 据库系统（Object Oriented Database）研究。 鉴于面向对象技术的特点，面向对象数据库能满足复杂数据结构和海量存储的需要， 并且在应用系统开发速度和维护等方面有着极大的优越性，同时也有利于异构平台间的分 布式数据库运行。但好的技术并不表示好的市场前景。 面向对象方法与一般人的思维规律相符合，因此面向对象数据库最大的性能优势是能
３
以使用数据的方式组织数据，但也由此带来了对象—关系不匹配障碍。面向对象模型是以 分类为基础的，类用来定义存储在数据库内对象的结构及行为；而关系模型的基础是关系， 也就是基于关系的表，它要求将数据组织成规范的二维表，这种组织方式往往要求对象在 经过分解后才能进入数据库，使用对象时再通过 SQL 语言进行组装。可见面向对象概念与 关系概念是两个完全不同的概念，采用纯粹的面向对象数据库意味着取代原有关系数据库。 但由此带来的数据转换工作量和巨额开支是关系数据库老用户们不愿意承受的，因此面向 对象数据库的市场发展情况并不理想。而且面向对象语言与关系型数据库使用的语言完全 不同，使得面向对象数据库缺乏对 SQL 的支持，即使带 SQL 接口也难以创建用于管理商业 智能应用所产生的这类查询机制，因此在通用性方面也失去了优势。 于是 1997 年出现了对象关系数据库，也就是在关系模型之上加入对象到关系的映射。 对象关系模型允许关系表中的列含有复杂的对象，这些对象能够捆绑“处理过程”来处理 复杂数据，并且允许 SQL 调用与关系型等同的“对象方法” 。因此既支持已经被广泛使用的 SQL，具有良好的通用性，又具有面向对象特性，支持复杂对象及其行为，达到了对象技术 和传统关系数据库技术的融合。但是，根本问题并没有解决，对象关系数据库仍受不匹配 障碍的困扰。
1.2.4 后关系数据模型
进入 21 世纪随着 WEB 应用的发展，如何有效地存储和管理 WEB 上的文档数据，使其既 能被高效地操作和维护，又能在 Internet 平台上方便地表示和交换，给数据库技术提出了 应用需求。于是出现了所谓的后关系型数据库，也就是 XML 加关系模型数据库。 1999 年 Oracle 8i 率先推出了支持 XML 的版本，它将每个 XML 文档完整地存储为一个 大对象，或者将 XML 转换为关系列和行分散到表中，实际上未能实现 XML 的原生态存储。 原生态 XML 是以层次格式组织数据的，早期研究已经证明数据的层次格式难以支持快速高 效的数据检索。2002 年 Oracle 9i 在其第 2 版 Oracle 9i R2 中引入了高性能的本地 XML 数 据管理技术 XML DB，为 XML 存储创建了新的数据类型 XMLTPYE。XMLTPYE 列提供了结构化和 非结构化两种存储方式，存储在非结构化 XMLTYPE 中的 XML 文档以大对象存储；存储在结 构化 XMLTYPE 中的 XML 文档可以通过优化方式进行解析和存储。Oracle 利用高度优化的文 件夹模型将关系结构影射到基于路径的结构，并在关系表中使用特定的索引来加速基于路 径的访问。据测试，Oracle 处理 XML 数据的速度非常快，可以通过事务以每秒 2500 条数据
４
的速度处理 XML。性能提高了，但是实际上仍未能实现 XML 的层次结构存储。2005 年 5 月 Oracle 10g 第 2 版 Oracle 10g R2 推出，声称第一个在商业上包含了对 XML Query（XQuery） 标准的支持（XQuery 语言于 2007 年 1 月正式成为万维网联盟 W3C—World Wide Web Consortium 推荐标准） ，完全将 XML 嵌入其体系结构中。 2007 年 7 月推出的 Oracle 11g 中 XML 成为热点，在 Oracle 11g 中还可以使用 CLOB 及二进制两种方式存储 XML 信息，灵 活性提高。 此外， Oracle 11g 还提供了二元性的 XML 支持， 即用户既可以将 XML 嵌入到 PL/SQL 中使用，也可以将 PL/SQL 整合到 XML 中使用。 微软公司在 2005 年底发布了代号为 Yukon 的 SQL Server 2005，该产品可以存储和处 理 XML 类型的数据，并支持 XQuery 的 XML 数据检索。 IBM 在 2006 年 7 月推出了基于 XML 技术的新一代数据库系统 DB2 9，代号为 Viper（毒 蛇） ，声称把数据库技术领入了 XML 时代。它利用 IBM 的 PureXML 技术，解决了关系模型和 层次模型的共存问题，用户可以混合使用 SQL 和 XQuery 进行数据搜索与处理，实现了关系 型数据和 XML 数据的无缝操作。 XML 数据库的出现和发展是否意味着数据库技术进入了一个新时代， 即混合型数据库时 代？现在还难以定论。
５
2 数据模型设计
数据库数据模型经历了近 50 年的发展历程，目前主流数据库仍然是关系模型数据库, 面向对象也好,XML 也好,都只不过是点缀,需要时可以用,不用也无妨。 不过本节所谈的不是 关系数据模型本身，而是关系数据模型基础上的专业领域数据模型。 专业领域数据模型具体怎么来设计，很难有明确答案，因为各专业领域具体情况各不 相同，数据库建设目标也各不相同，很难说这样好，那样就不好。数据模型的好坏标准是 它能否有效，而不是完不完美或正不正确。一个完美得可以预见未来任何变化的设计，或 一个灵活得可以容纳任何扩展的设计是不存在的。数据库设计不是追求完美，而是寻求平 衡，即根据实际情况与需求权衡，作出最佳折中方案。 涉及关系数据库系统产品的书很多，大部分针对特定数据库产品的操作使用和应用开 发，如：“SQL Server 2005 数据库开发详解”“Oracle 9i&10g 编程艺术：深入数据库体 、 系结构”“数据挖掘原理与应用：SQL Server 2005 数据库”“SQL Server 2005 数据库开 、 、 发实战”等等，但涉及数据库设计的书不多，就是有也是谈理论居多，谈实际设计过程的 少，看完了还是一头雾水，面对自己的专业领域不知从何入手，如果你是非专业领域人士 （大多数情况下是如此） ，对专业知识和工作流程不甚了解的话，更是举步维艰，只能根据 专业部门提供的报表格式照样画瓢。我刚开始做数据模型设计工作时就有这种感受，几年 工作下来，经历了不少挫折，也学到了不少知识。现在，我经常有一种冲动，恨不得把我 原来设计的数据模型推倒重来，因为里面有太多的毛病，但是这几乎是不可能的，数据库 建成后只能改良不能改革。于是就想把我的认识写下来，写给别人看，也写给自己看。 在进入正题前先谈谈数据模型设计前的前期预备工作。 首先，数据模型设计前必须明确设计目标，目标是衡量设计好坏的标准，也是设计必 须遵循的规则。经常有这样的感受，随着工作的深入会渐渐把真正的设计目标忽略了，结 果走了不少弯路，做了许多不该做的事。设计目标确定，就可以作为依据来划定工作范围， 工作范围确定了，工作的深度、广度与焦点也就确定了，你也就知道哪些该做，哪些不需 要做，哪些需要马上做，哪些可以在下阶段再做，这样工作就可以合理、有序地开展，不 至于陷入忙乱之中。 其次，在设计前应了解所设计数据库的特点，以便在设计时权衡利弊，把握设计的度， 在应用与约束之间寻找最佳折中方案。商业领域的数据库数据几乎每时每刻都可能变化，
６
用户量大，涉及大量的事务处理，因此需要多多关注数据在频繁变动过程中的完整性及可 恢复性。在科研领域，数据库的数据变动则取决于科研项目的工作进程，每期工程结束会 有大批的数据进库，平时变动不大，但数据量大，涉及大量数据的安全存储与管理；在数 据应用方面，一般会要求通过网络的数据快速定位与提取，要求数据的多方管理，要求数 据的可理解性，要求数据的可挖掘性等，但用户访问量不会太大。从另一角度来说，科研 领域的数据库接近维度数据库（数据仓库） ，主要目的是历史数据的管理，以及海量数据中 的钻取与挖掘。
2.1 整体框架约束下的迭代渐进
谈到关系数据模型设计，首先想到的可能会是“概念数据模型设计”及实体关系图（ER 图） ，但我认为完整的数据库数据模型设计需要经过三个阶段： （1） 数据总体结构设计； （2） 概念数据模型设计； （3） 构建数据库模式。 数据总体结构设计独立先行，工作内容是将问题域数据对象抽象为不同的类，构建出 数据整体框架。而后在整体框架约束下，根据需求，先后选取待设计的数据类，实施概念 数据模型设计与数据库模式设计。各数据类的概念数据模型与数据库模式的设计工作可按 实际需要渐进，当前不需要的可暂时放一放，待需要时再补充。这样做的好处在于一方面 能把设计工作大事化小；另一方面，如果总体结构设计合理，即使后期部分模块的数据模 型设计不理想，也不会造成全局性的倒塌。 这里，我将上述设计过程统称为整体框架约束下的迭代渐进设计过程。工作以迭代方 式进行，表示将设计工作分割成一系列小的整体，每一个小整体的工作包括分析、建模、 测试、优化、部署等各个环节，完成一个小整体的设计工作，即完成一个迭代，然后是下 一个迭代，再下一个迭代，各个迭代之间的关系是并联的关系，互相没有内容及先后依赖， 某一迭代中的问题与修改不会对其它迭代工作产生不良影响，见图 2-1。这种过程有别于串 行（瀑布式）的工作方式，在串行工作方式中，你必须首先确定所有需要实现的需求，然 后创建详细设计，然后实现该设计并进行测试，最后部署到数据库系统中，串行工作过程 中要求每一阶段的设计内容都是完美的，否则将会影响后面的设计内容。但是设计中出现 各种各样的问题是不可避免的，设计完成后出现各种各样的的变动也是正常的，因此串行
７
工作方式在一定程度上忽略了现实中的基本事实，由此引起的现实冲突和人员之间摩擦也 不可避免，在这方面，本人深有感触。
图 2-1 迭代渐进1
迭代渐进式设计方法与石油地质勘探过程有类似之处。石油勘探的目的当然是找石油， 目标很简单，就是找油，但地质工作者真正找的却不是油，而是有利于油气聚集的构造圈 闭。构造圈闭的勘测过程是一轮又一轮逐渐缩小包围圈向目标逼近的过程：先采用成本比 较低的方法扫面，了解目标区内的区域地质构造特征，圈出有油气前景的盆地及凹陷；然 后选择有前景的凹陷区布设成本较高的二维地震测网，进行加密勘测，把握次一级地质构 造特征；再在次一级油气前景构造中布设成本很高的三维地震测网进行详测，圈定可能的 储油构造；最后定井位打井，如果出油，则计算石油储量，进入石油开采阶段，如果没有 油气显示，则转移到下一个具油气前景的凹，开始新一轮调查。撇开传统的石油地质勘探 过程，假如有某位领导找来张三李四，吩咐他们先把凹陷区、凸起区、圈闭、井位、石油 储量统统写出来，然后交给勘探部门去打井，可能任何人都会认定那位领导不正常，但是 在数据库设计或计算机软件设计工作中这种现象经常发生，当然有时为了完成任务也不得 不这样做，但这样做的结果是可想而知的。与传统石油勘探工作方式相似，数据库设计也
1
假设总体结构为鱼骨状架构，架构内分 A、B、C、D、E、F、G 七个模块，那么设计可以分模块迭代进行，每个迭代工作包括 分析、建模、测试、优化、部署等各个环节。
８
应该在前期先做扫面性的整体分析工作，然后抓住重点逐步推进，在不断探索、总结及完 善过程中将设计模型从问题域中推出，然后让它再回到问题域中去，使其能在问题域中得 到优化及应用。 此外，设计过程中保持正确的设计态度，把握设计的度也非常重要。首先，设计过程 中应积极与相关专业人员沟通，学习专业领域的知识，把握专业数据的生产流程，发掘专 业人员心目中的重要专业要素。同时，应以发展的眼光去看待你遇到的问题，勇敢自信地 面对变化。在数据库设计领域，唯一不变的就是变化本身，变化是正常现象，如果害怕变 化，说明你的第六感觉正在告诉你，你的设计有问题，该改一改了。在设计尺度把握上， 应从简单实用出发，不要过度设计，但这个简单不是粗糙，简单意味着能让开发人员不需 要费时间学习就能理解你的设计意图；意味着你的设计应留有余地，能长期有效维护，当 日后需求有变更时，你能有自信在现有模型上进行重构（不影响大局的修改，也就是低成 本修改）或扩展。其次不要追求完美，没有必要试图在一开始就建立一个囊括一切细节的 模型，实际上你也很难做到。只要把住大方向，以当前需求为基准，在开始阶段设计一个 基础模型，然后在实际应用中慢慢地改进，这也就是所谓的递增思想。 最初的设计思想往往决定着一个系统的命运，现在我经常提醒自己的一句话是“别把 系统做死了” ，言下之意是系统的雏形有可能不太好，但可以改进，让丑小鸭有希望变天鹅， 而不是拔苗助长，一锤子买卖。我目击了太多这样那样的数据库系统，又宣传又获奖，然 后连用都没用就销声匿迹了，有时侯想起来心里有说不出的感觉。
2.2 数据总体结构设计
我们通过数据库前台看到的通常是以“表”形式组织的数据，因此数据模型设计常常 被误认为是数据表设计，总体结构设计部分就常被忽略。我曾参加过一些数据库项目的研 究成果汇报，上去做报告的会说我们的数据库在 XXX 国际主流平台上开发，共设计了XXX 个表，然后一个一个表展示，看着做了很多工作，实际上把最重要的工作忘了，即这些数 据表是应该有组织的，这个组织就是总体结构。总体结构是数据对象存储的整体框架，整 体框架是整个数据库的支撑，总体结构设计得好，数据库的支撑力就强，即使后期的设计 工作差一点也不至于影响全局。 做数据模型设计时必须明白，前台看到的与后台存储的不是一回事，就像商品在商场 柜台里的摆放方式与货物在仓库里的堆放方式不应该、也不可能是一致的。在商场里怎么
９
对销售有利就怎么放，而在仓库里肯定得考虑容易管理、容易提取、并且尽量少占仓储空 间。曾经遇到过做数据库设计的为投影坐标数据的存储发愁，因为假如每个投影存一套数 据的话，那数据库里要存多少套数据？这是目前最常见的把数据显示与数据存储混为一谈 的现象。投影是数据显示时的选择，后台数据可以完全用经纬度存储，待数据显示时再按 用户要求动态转换成需要的投影方式，数据模型设计时没必要去关心投影问题。还有一种 常见现象是把数据库中的存储表原封不动拿出来作为用户的视图或录入表，如果存储表是 实体分解后的多个子表，那么用户就会觉得这些表不仅烦琐而且不可理喻。因此，做数据 库设计的人员必须把数据显示与数据存储这两个层的概念范畴区分开，这将有利于设计工 作的简单化，GIS数据库的设计尤其如此。以ERSI 的地理数据库（Geodatabase）为例， Geodatabase是建立在关系型数据库管理信息系统之上的空间数据库，在Geodatabase框架 结构下，地图通过存储层与表现层的两组数据对象构建，空间数据以Geodatabase的要素类 与要素集组织并存储管理，最终通过图层、图层组及地图样式综合表现，如图2-2。存储层 与表现层的两组逻辑结构概念清楚了，Geodatabase的数据模型结构也就把握住了。
把数据显示与数据存储这两个层的概念范畴区分开将有利于设计工作的简单化。
Geodatabase实现了公共模型框架下的矢量、栅格、TIN、网络、地址等地理空间数据的 统一存储与管理，在Geodatabase基础上的数据库设计相对简单，因为总体结构框架确定了， 需要做的事情只是在框架内填空，而且后台的数据库模式都是通过前台的ArcCatalog由系统 自动创建，不需要考虑太多的后台技术问题。近来有趋势把数据库完全依托Geodatabase来 做，可能因为这样既简单快速，也容易见成效。Geodatabase就好比是架傻瓜相机，不需要 太多的专业知识就能完成任务，但一个专业的高级摄影师是不会用傻瓜相机的，因为很难 按自己的意愿拍摄希望达到的效果。因此，如果是一个大中型的企业级数据库，我个人认 为把数据库全部建在Geodatabase之上不是长久之计，因为这样过于依赖第三方产品；而且 从目前来看，ArcGIS产品本身的稳定性也不是太好，有能力的话应仍以传统的关系数据库 管理方式为主，将Geodatabase作为一个空间数据的管理模块比较合适。
１０
存储空间
数据集 地图数据 附属数据 按图幅提取
表现空间
地图
按图幅布局
要素集
图层组
按专题组合
按地图窗口组合
存储对象
要素属性 要素类
过滤
地图投影 地图样式
表现对象
图层
特征信息 要素
点、线、面
抽象
抽象
现实世界
图2-2 存储层与表现层的空间数据对象及对应关系
总体结构设计是面向专业领域（下面统称为问题域）的设计，首先需要全面分析并把 握专业领域工作过程中可能产生的数据流，在此基础上采用面向对象的分析方法，进行问 题域各种数据对象的抽象，构建出数据类图，然后理顺数据类之间的关系，创建出数据总 体结构。一个好的总体结构应能体现完整的框架体系、支持多层次应用开发、而且稳定能 包容变化。 由于总体结构只是一个静态框架，因此总体结构设计只涉及静态对象建模，建模工具 可采用UML。UML（Unified Modeling Language，统一建模语言）是目前最常用的面向对象 建模语言，1997年由OMG组织（Object Management Group，对象管理组织）发布，为开发 团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套统一的标准建模符 号，通过使用UML，IT专业人员能阅读和交流系统架构和设计规划，就像建筑工人使用的建 筑设计图一样。需要提醒的是，UML只是一种可视化的表达方式，促使你的设计思想能更容 易被人理解并接受，因此重要的当然是你的设计思想，而不是UML。常见的UML图包括用例
１１
图、类图、序列图、状态图、活动图、组件图和部署图，分别用于不同的建模用途。总体 结构设计主要涉及其中的类图，通过类图将面向对象分析过程划分的数据类及其关联可视 化。 根据面向对象分析与设计方法，总体结构设计工作可按下列流程开展： (1) (2) (3) (4) (5) (6) 剖析问题域（工作流与数据流分析） ； 划分对象（面向对象分析） ； 定义类（面向对象设计） ； 定义类之间的关系（面向对象设计） ； 绘制UML类图，小组讨论或专家认定； 发布总体结构，统一设计思想。
2.2.1
工作流与数据流分析
剖析问题域是期望通过问题域的工作流和数据流分析提取数据对象,从而构成数据类 的抽象。工作流和数据流分析可以通过UML活动图理顺工作过程以及工作过程中可能产生 的数据对象，图2-3是采用Microsoft Visio绘制的成果图数据处理与质量控制UML活动图。
１２
资料汇聚阶段 资料汇聚 分幅整理 分类加工
细化处理阶段 元数据编写 成品提交
成品提交阶段
《地理数据库数据模型》
《数据采集与处理规程》 纸介质图件矢量化 划分要素类1资料 矢量化图形
《元数据内容标准》 编写说明书 文档资料 电子介质资料加工 编写元数据 产品汇总打包
数 据 处 理
划定地图数据集 提交原始资料 汇集原始资料
划分要素类2资料 ... 提交地图数据集分类资料 划分要素类n资料
地图成品入库
修改或返工
修改
修改
数 据 输 出
要素类n原始资料 ·实测资料 ·数据产品 ·图件资料 ·文字资料 补充资料 要素类2原始资料 ... 要素类1原始资料 补充资料
地图数据产品 ·要素类 ·属性数据表 ·地图说明书 ·元数据
地图说明书 元数据产品
地图成品
拓扑规则
质 量 控 制
核查
核查 地图模板 [完整] [基本完整]
自查与互查 [不合格] [合格]
[不合格] [合格]
核查 [不合格]
审查 [不合格] [合格]
核查 [原始资料问题]
[合格]
[不完整]
[不完整]
[原始资料问题]
问 题 交 流
沟通
沟通
沟通
沟通
图2-3 成果图数据处理与质量控制UML活动图
１３
图2-3中的UML活动图符号说明如下：
动作
动作：完成某作业的动作 对象：由动作产生或使用的对象 起始：活动开始 终止：活动结束 同步条分叉：一个输入转换为多个并行输出 同步条汇合：多个输入转换为一个输出,输出直到所有输入到达才发生
对象
决策：互斥产生的分支 合并：任何延续输入的合并
控制流：从一个活动状态转换到另一个活动状态 对象流：活动输出或对象输入流
图2-3表示数字化成果图编制过程中的数据处理工作分为三个阶段、五个环节。三个阶 段即资料汇聚、细化处理和成品提交阶段，其中细化处理阶段又包括分幅整理、分类加工 及元数据编写环节，与数据供方的沟通交流和质量控制措施贯穿始终。在资料汇聚阶段， 数据处理方首先明确地图数据集的数据内容，并与数据供方沟通协调，畅通数据渠道，促 使双方形成一个有机的整体，保障工作顺利进行。细化处理阶段，按照数据模型设计要求 将数据集数据分解为以要素类为单位的数据子集，然后按载体类型对不同载体的数据子集 资料进行分类加工；加工后的数据再以数据子集为单元物理整合形成要素类数据，然后以 数据集为单元逻辑组合，质量检查合格后提交地图数据产品；最后，编写并提交数据集的 元数据或传统的地图说明书。成品提交阶段，将数据集的数据与元数据汇总打包成数据集 产品，数据质量审查合格后形成数据集成品提交入库。通过上述活动图的工作流分析，由 工作流使用及产生的对象就可清楚地显现，用于下一步的面向对象分析。活动图比较适合 非线性的工作流分析，也就是有多方参与和协作交互的工作流分析。
１４
工作流和数据流也可以采用结构化软件设计中的工作流与数据流图进行分析， 如图2-4、 图2-5。工作流与数据流图是结构化软件设计中的分析工具，虽然现在多采用面向对象以及 UML来进行软件系统的分析设计，但工作流与数据流图因其简易直观仍然有着不可替代的作 用。
导航定位
柱状取样、钻探取样
运抵室内
剖 样 粒 度 岩芯A 岩芯B 碎屑矿物 粘土矿物 贴标签 照 相 全岩矿物 封 存 分层描述 有孔虫、介形虫 孢粉、藻类 上 架 确定取样位置 地球化学 取分析样 碳十四测年 ESR测年 释光测年 古地磁
图2-4 柱状和钻孔岩芯采集及室内编录与送样工作流
定 名 称 重 装 袋 贴标签
填送样单
送 样
１５
甲方 粒度分析结果 矿物分析结果 古生物鉴定结果 地球化学分析结果 测年结果 古地磁分析结果 ……
柱状岩芯 钻孔岩芯
岩芯分层描述 岩芯照片
剖样
岩芯B
岩芯 编录
岩芯B
取分 析样
送样单 分析样品
分析 单位
外部交互方,表示数据的外部来源和去处，通常是系统之外的人员或组织 数据处理，把流入数据转变为流出数据 流经的数据
图 2-5
柱状和钻孔岩芯室内编录与样品分析数据流
图 2-4 与图 2-5 表示了柱状与钻孔岩芯的室内编录与分析样品采集流程。首先沿岩芯 管中轴线将柱状或钻孔岩芯剖分两半，其中的一半进行封装处理作永久保留，另一半用于 室内编录和分析样品采集。编录前对岩芯进行照相，然后进行岩芯分层描述。在岩芯描述 完成后，确定各类分析样品的取样位置，采取分析样品。采取的分析样品经定名、称重、 装袋、贴标签、填写送样单，最后送各实验室测试分析。通过上述简单的工作流和数据流 图顺藤摸瓜，也可抓住数据库系统的数据对象，为下一步的面向对象分析奠定基础。
2.2.2
面向对象分析与设计
把握数据流来笼去脉后，就可以根据数据流进行数据对象的抽象，即将专业领域的数 据分成不同的模块，从中提取各数据类。数据类的定义内容包括类的名称、属性（对象特 征）和方法（对象可实施的操作） 。对数据库数据的基本操作只有SELECT、UPDATE、INSERT、 DELETE有限的几种，具体操作与具体数据实体相关，只能在后期定义。因此在总体结构设 计阶段只需要关注类、类的关系及类的属性，最后的结果是一组没有定义操作的类图。此 外，在总体结构设计阶段，没必要关心类的所有属性，但需要关注类之间赖以关联的主、 外键属性，为后期概念数据模型设计打下良好的基础。不过请注意，在面向对象设计中， 将外键定义为属性是违反设计原则的，常规是通过关系类来定义数据对象之间的关联，
１６
第二章 数据库设计和ER 模型 (单选)在数据库规划阶段，包括在数据字典中Ⅰ.数据项、数据流；Ⅱ.数据结构、数据存储； ER 模型图例 (单选) 如下图所示是一个ER 模型，下列对其基数描述最为合理的是一个学生最少需要选1门课程，最多选6门课程；每个课程多最可以被50个学生选修。 (单选)关系中元组在组成主要的属性上不能有空值。 (单选)在数据库设计中，将E-R 图转换成关系数据模型的过程属于逻辑设计阶段。 (单选)将数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间，称为数据库系统的生存期。 (单选)数据字典是对数据描述的集中管理。 (单选)将概念模型转换逻辑模型是数据中逻辑设计阶段的主要步骤之一。 (单选)表示数据库的概念模型一般使用ER 图。 (单选)ER 模型中所指的实体一般是实体集。 (单选)一个联系涉及到的实体集个数，称为该联系的度数。 (单选)采用ER 模型进行数据库的概念设计，可以分成三步进行，下列正确的是先设计局部ER 模型，然后合成全局模型，最后体优进行整化。 (单选)下列不属于全局ER 模型的优化目的的是优化存储结构。 (单选)关系模式是对关系的描述，一般表示为关系名（属性名1，属性名2，…，属性名n ）。 (单选)已知有关系表R （如下表所示），其元数和基数正确的是数为6，基数为3. (单选)下列哪个不可以为空主键。 (单选)区别一个元组与另一个元组靠的是元组的属性而不是顺序，所以关系中的元组没有先后顺序。 (单选)表中可以唯一确定一个元组（一个记录）的某个属性组（字段组）称为主键。 (单选)若某个属性组不是关系A 的主码，但它是另一个关系B 的主码，则称属性或属性组称为关系A 的外键。 (单选)现有一个公司员工记录表，如下表所示内容，如果想以员工号为查询元组的标志，那
第3部分 习题及其解答 第一章的两道题 设计 N 开始时间 结束时间 版权 专利号 月薪
3-2 习题2 分别把习题、习题的ER 图转换成关系模型数据结构。 【参考答案】 1．习题的ER 图可转换成如下的关系模型数据结构。 ① 程序员(编号，姓名，性别，年龄，单位，职称)，其中编号是关键字； ② 程序(程序名称，版权，专利号，价格)，其中程序名称是关键字； ③ 设计(编号，程序名称，开始时间，结束时间)，其中(编号，程序名称)是关键字。 2．习题的ER 图可转换成如下的关系模型数据结构。 ① 工厂(工厂名称，厂址，联系电话)，其中工厂名称是关键字； ② 产品(产品号，产品名，规格，单价)，其中产品号是关键字； ③ 工人(工人编号，姓名，性别，职称，工厂名称，雇用期，月薪)，其中工人编号是关键字，工厂名称是外关键字，雇用期和月薪是联系属性； ④ 生产(工厂名称，产品号，月产量)，其中(工厂名称，产品号)是关键字,生产关系是表示联系的。 判断下列情况，分别指出它们具体遵循那一类完整性约束规则 生产 月产量 雇用 雇用期
1．用户写一条语句明确指定月份数据在1～12之间有效。 2．关系数据库中不允许主键值为空的元组存在。 3．从A 关系的外键出发去找B 关系中的记录，必须能找到。 【解答】 1．用户用语句指定月份数据在1～12之间有效，遵循用户定义的完整性约束规则。 2．关系数据库中不允许主键值为空的元组存在，遵循实体完整性约束规则； 3．从A 关系的外键出发去找B 关系的记录,必须能找到，遵循引用完整性约束规则。 判断下列情况，分别指出他们是用DML 还是用DDL 来完成下列操作 1．创建“学生”表结构。 2．对“学生”表中的学号属性，其数据类型由“整型”修改为“字符型”。 3．把“学生”表中学号“021”修改为“025”。 【解答】 1．创建“学生”表结构，即定义一个关系模式，用DDL 完成。 2．修改“学生”表中学号属性的数据类型,即修改关系模式的定义，用DDL 完成。 3．修改“学生”表中学号属性的数据值,即对表中的数据进行操作，用DML 完成。 给出两个学生选修课程关系A 和B ，属性为姓名、课程名、成绩。分别写出后列各关系代数运算的结果关系。 1．A 和B 的并、交、差、乘积、自然联接。 2．> '' (A )； 2= ''∧<'' (B )； ,(A )； (B )。 3． 关系A 姓名 课程名 成绩 李红 数学 89 罗杰明 英语 78 关系B 姓名 课程名 成绩 黄边晴 C++语言 86 李红 数学 89
第2章数据库设计方法 ※1.实体关系 ⑴概念模型 ①概念模型的基本概念 l实体：客观存在并可相互区别的事物称为实体。实体可以是具体的事物，也可以是抽象的事件。 l实体的属性：实体所具有的某一特性称为属性。一个实体可由若干个属性来描述。 l实体的主属性：主属性也称关键字，它能惟一的标识一个实体。关键字可以是属性或属性集。 l属性的域：属性的取值范围称为该属性的域。 l实体型：具有相同属性的实体必然具有共同的特征。用实体名及其属性名的集合来描述的同类实体，称为实体型或称实体结构。 l实体集：同类型实体的集合称为实体集。 l实体的联系：实体的内部联系是指组成实体的各属性之间的联系；实体间的联系是指不同实体集之间的联系。两个实体集之间的联系可以分为下列3种： n一对一联系（1：1）：是指第一实体集中的每个实体最多只与第二实体集中的一个实体相联系，反之亦然，此即为一对一联系。 n一对多联系（1：N）：是指第一实体集中的每个实体与第二实体集中的N个实体相联系，而第二实体集中的每个实体最多只与第一实体集中的一个实体相联系，此即为一对多联系。 n多对多联系（M：N）：是指第一实体集中的每个实体与第二实体集中的N个实体相联系，而第二实体集中的每个实体与第一实体集中的M个实体相联系，此即为多对多联系。 ②概念模型的表示方法 概念模型是对现实世界的建模，概念模型应当能够全面、准确地描述现实世界中的基本概念。概念模型最著名、最实用的方法是实体－联系方法，简称E-R方法。E-R图的使用请参阅课本第2章的2.2.1相关内容。 ⑵构造E-R模型 ①构造E-R模型的方法 构造E-R模型的步骤分为：确定实体、除去重复的实体、列出每个实体的属性、标记主
第二章数据库应用系统生命周期 2.1数据库应用系统生命周期 2.1.1 软件工程与软件开发方法 1、软件工程：将工程化应用于软件生产 2、软件工程的目标：在给定成本、进度的前提下，开发出满足用户需求并具有下述特征的软件产品：可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性。 3、软件生命周期：指软件产品从考虑其概念开始，到该产品交付使用的整个时期，包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装部署及交付阶段; 4、软件项目管理：为了能使软件开发按预定的质量、进度和成本进行，而对成本、质量、进度、人员、风险等进行分析和有效管理的一系列活动。 5、软件工程以关注软件质量为特征，由方法、工具和过程三部分组成; 6、软件过程模型(软件开发模型)：是对软件过程的一种抽象表示，表示了软件过程的整体框架和软件开发活动各阶段间的关系，常见的有：瀑布模型、快速原型模型、增量模型和螺旋模型。 2.1.2 DBAS软件组成 1、数据库应用软件在内部可看作由一系列软件模块/子系统组成，这些模块/子系统可分成两类： (1) 与数据访问有关的数据库事务模块：利用DBMS提供的数据库管理功能，以数据库事务方式直接对数据库中的各类应用数据进行操作，模块粒度较小; (2) 与数据访问无直接关联的应用模块：在许多与数据处理有关的应用系统中，对数据库的访问只是整体中的一部分，其他功能则与数据库访问无直接关系，这部分模块粒度可以比较大。 2、 DBAS设计开发的硬件方面：主要涉及根据系统的功能、性能、存储等需求选择和配置合适的计算机硬件平台，并与开发好的DBAS软件系统进行集成，组成完整的数据库应用系统; 2.1.3 DBAS生命周期模型 1、数据库应用系统的生命周期模型： (1) 参照软件开发瀑布模型的原理，DBAS的生命周期由项目规划、需求分析、系统设计、实现和部署、运行管理与维护等5个基本活动组成; (2) 将快速原型模型和增量模型的开发思路引入DBAS生命周期模型，允许渐进、迭代地开发DBAS; (3) 根据DBAS的软件组成和各自功能，细化DBAS需求分析和设计阶段，引入了数据组织与存储设计、数据访问与处理设计、应用设计三条设计主线，分别用于设计DBAS中的数据库、数据库事务和应用程序; (4) 将DBAS设计阶段细分为概念设计、逻辑设计、物理设计三个步骤，每一步的设计内容又涵盖了三条设计主线。
第3部分习题及其解答第一章的两道题
3-2 习题2 2.6 分别把习题1.10、习题1.11的ER图转换成关系模型数据结构。 【参考答案】 1．习题1.10的ER图可转换成如下的关系模型数据结构。 ①程序员(编号，，性别，年龄，单位，职称)，其中编号是关键字； ②程序(程序名称，，专利号，价格)，其中程序名称是关键字； ③设计(编号，程序名称，开始时间，结束时间)，其中(编号，程序名称)是关键字。 2．习题1.11的ER图可转换成如下的关系模型数据结构。 ①工厂(工厂名称，厂址，联系)，其中工厂名称是关键字； ②产品(产品号，产品名，规格，单价)，其中产品号是关键字； ③工人(工人编号，，性别，职称，工厂名称，雇用期，月薪)，其中工人编号是关键字，工厂名称是外关键字，雇用期和月薪是联系属性； ④生产(工厂名称，产品号，月产量)，其中(工厂名称，产品号)是关键字,生产关系是表示联系的。 2.8 判断下列情况，分别指出它们具体遵循那一类完整性约束规则？ 1．用户写一条语句明确指定月份数据在1～12之间有效。 2．关系数据库中不允许主键值为空的元组存在。 3．从A关系的外键出发去找B关系中的记录，必须能找到。 【解答】 1．用户用语句指定月份数据在1～12之间有效，遵循用户定义的完整性约束规则。 2．关系数据库中不允许主键值为空的元组存在，遵循实体完整性约束规则； 3．从A关系的外键出发去找B关系的记录,必须能找到，遵循引用完整性约束规则。 2.9 判断下列情况，分别指出他们是用DML还是用DDL来完成下列操作？ 1．创建“学生”表结构。 2．对“学生”表中的学号属性，其数据类型由“整型”修改为“字符型”。 3．把“学生”表中学号“021”修改为“025”。 【解答】 1．创建“学生”表结构，即定义一个关系模式，用DDL完成。 2．修改“学生”表中学号属性的数据类型,即修改关系模式的定义，用DDL完成。 3．修改“学生”表中学号属性的数据值,即对表中的数据进行操作，用DML完成。 2.12 给出两个学生选修课程关系A和B，属性为、课程名、成绩。分别写出后列各关系代数运算的结果关系。
第二章关系数据库 一、选择题 1. 下面的选项不是关系数据库基本特征的是（）。 A.不同的列应有不同的数据类型 B.不同的列应有不同的列名 C.与行的次序无关 D.与列的次序无关 2. 一个关系只有一个（）。 A.候选码 B. 外码 C. 超码 D. 主码 3. 关系模型中，一个主码是（）。 A.可以由多个任意属性组成 B.至多由一个属性组成 C.可有多个或者一个其值能够唯一表示该关系模式中任何元组的属性组成 D.以上都不是 4. 现有如下关系： 患者（患者编号，患者姓名，性别，出生日起，所在单位） 医疗（患者编号，患者姓名，医生编号，医生姓名，诊断日期，诊断结果） 其中，医疗关系中的外码是（）。 A. 患者编号 B. 患者姓名 C. 患者编号和患者姓名 D. 医生编号和患者编号 5. 现有一个关系：借阅（书号，书名，库存数，读者号，借期，还期），假如同一本书允许一个读者多次借阅，但不能同时对一种书借多本，则该关系模式的外码是（）。 A. 书号 B. 读者号 C. 书号+读者号 D. 书号+读者号+借期 6. 关系模型中实现实体间N：M 联系是通过增加一个（）。 A.关系实现 B. 属性实现 C. 关系或一个属性实现 D. 关系和一个属性实现 7. 关系代数运算是以（）为基础的运算。 A. 关系运算 B. 谓词演算 C. 集合运算 D. 代数运算 8. 关系数据库管理系统应能实现的专门关系运算包括（）。 A. 排序、索引、统计 B. 选择、投影、连接 C. 关联、更新、排序 D. 显示、打印、制表 9. 五种基本关系代数运算是（）。 A.∪－× σ π B.∪－σ π C.∪∩× σ π D.∪∩σ π 10. 关系代数表达式的优化策略中，首先要做的是（）。 A.对文件进行预处理 B.尽早执行选择运算 C.执行笛卡尔积运算 D.投影运算 11. 关系数据库中的投影操作是指从关系中（）。 A.抽出特定记录 B. 抽出特定字段 C.建立相应的影像 D. 建立相应的图形 12. 从一个数据库文件中取出满足某个条件的所有记录形成一个新的数据库文件的操作是（）操作。
Exercise 2.2.1a For relation Accounts, the attributes are: acctNo, type, balance For relation Customers, the attributes are: firstName, lastName, idNo, account Exercise 2.2.1b For relation Accounts, the tuples are: (12345, savings, 12000), (23456, checking, 1000), (34567, savings, 25) For relation Customers, the tuples are: (Robbie, Banks, 901-222, 12345), (Lena, Hand, 805-333, 12345), (Lena, Hand, 805-333, 23456) Exercise 2.2.1c For relation Accounts and the first tuple, the components are: 123456 → acctNo savings → type 12000 → balance For relation Customers and the first tuple, the components are: Robbie → firstName Banks → lastName 901-222 → idNo 12345 → account Exercise 2.2.1d For relation Accounts, a relation schema is: Accounts(acctNo, type, balance)
3.简述如下概念，并说明它们之间的联系与区别:。 （1）域，笛卡尔积，关系，元组，属性 答：域：域是一组具有相同数据类型的值的集合。 笛卡尔积：给定一组域D1，D2，…，Dn，这些域中可以有相同的。这组域的笛卡尔积为：D1×D2×…×Dn＝｛（d1，d2，…，dn）｜di?Di，i＝1，2，…，n ｝其中每一个元素（d1，d2，…，dn）叫作一个n元组（n-tuple）或简称元组（Tuple）。元素中的每一个值di叫作一个分量（Component）。 关系：在域D1，D2，…，Dn上笛卡尔积D1×D2×…×Dn的子集称为关系，表示为 R（D1，D2，…，Dn） 元组：关系中的每个元素是关系中的元组。 属性：关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。由于域可以相同，为了加以区分，必须对每列起一个名字，称为属性（Attribute）。 （2）超码，主码，候选码，外码 答：超码：对于关系r的一个或多个属性的集合A，如果属性集A可以唯一地标识关系r中的一个元组，则称属性集A为关系r的一个超码 (superkey) 。 候选码：若关系中的某一属性组的值能唯一地标识一个元组，则称该属性组为候选码（Candidate key）。 主码：若一个关系有多个候选码，则选定其中一个为主码（Primary key）。 外码：设F是基本关系R的一个或一组属性，但不是关系R的码，如果F与基本关系S 的主码Ks相对应，则称F是基本关系R的外码（Foreign key），简称外码。 基本关系R称为参照关系（Referencing relation），基本关系S称为被参照关系（Referenced relation）或目标关系（Target relation）。关系R和S可以是相同的关系。 (3)关系模式，关系，关系数据库 答：关系模式：关系的描述称为关系模式（Relation Schema）。它可以形式化地表示为：R（U，D，dom，F） 其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom 为属性向域的映象集合，F为属性间数据的依赖关系集合。 关系：在域D1，D2，…，Dn上笛卡尔积D1×D2×…×Dn的子集称为关系，表示为 R（D1，D2，…，Dn） 关系是关系模式在某一时刻的状态或内容。关系模式是静态的、稳定的，而关系是动态的、随时间不断变化的，因为关系操作在不断地更新着数据库中的数据。 关系数据库：关系数据库也有型和值之分。关系数据库的型也称为关系数据库模式，是对关系数据库的描述，它包括若干域的定义以及在这些域上定义的若干关系模式。关系数据库的值是这些关系模式在某一时刻对应的关系的集合，通常就称为关系数据库。 2.3.为什么需要空值null？ 答：引入空值，可以方便于数据库的维护和建立，数字或者字符有时并不能解决想要解决的问题，毕竟它们是真实的存在，有了空值，那么有些操作，比如查询，插入，删除都可以更加方便，比如公司的部门，新增的部门，信息是不存在的，是之后数据库人员进行添加之后才有的，所以让它为空，比给它0更加贴近实际。空值是所有可能的域的一个取值，表明值未知或不存在。 2.3.关系模型的完整性规则有哪些？ 答：关系模型的完整性规则是对关系的某种约束条件。关系模型中可以有三类完整性约束：实体完整性、参照完整性和用户定义的完整性。 其中实体完整性和参照完整性是关系模型必须满足的完整性约束条件，被称作是关系的