第1章使用Oracle设计关系数据库

第 1 章

使用 Oracle 设计关系数据库

认证目标 ● 定位服务器技术 ● 理解关系结构 ● SQL 语言概述 ● 使用客户工具 ● 创建演示模式

OCA 认证考试指南(1Z0-061)：Oracle Database 12c SQL 基础

2

OCA 考试中没有直接测试本章内容的试题，但这些内容对于理解 SQL 的用途至关重要。

首先要正确理解各种 Oracle 服务器技术的组合方式以及每种产品作用的定位，这是每个学生的

必备知识。 Oracle 服务器技术产品集不仅仅是一个数据库，还包括 Oracle WebLogic Server 和 Oracle

Enterprise Manager。将它们组合在一起，就是构成 Oracle Cloud 的服务器技术。云计算(Cloud computing)是用于管理完整的 IT 环境并按需要为用户提供服务的一个新兴环境。

为了以一种有效的方式来组织、存储和检索数据，数据库基本上都提供了基础设施。Oracle Database 12c 已经从关系数据库管理系统(Relational Database Management System，RDBMS)演变为 Object RDBMS，几乎支持任何信息的组织并且对所存储的数据量没有实际的限制。

Amazon.com、欧洲 CERN 的 Large Hadron Collider(LHC)、一些金融机构和政府部门所产生的

巨大的数据量都可以通过 Oracle 数据库来组织和管理。虽然 Oracle 数据库的一些功能可以解

决可扩展性、高可用性和卓越的性能方面的需求，但本指南将集中介绍有关数据组织的问题。结构化查询语言(Structured Query Language，SQL，读作“sequel”)是管理关系数据库中存储的

数据的国际标准。Oracle Database 12c 提供一种 SQL 实现方式，它通常符合当前标准，即 Core SQL:2011。关于兼容性的完整细节请查看 SQL Language Reference 的附录 C，它是 Oracle Database Documentation Library 的一部分。通常可以假定是兼容的。

本书中有两种工具可广泛用于练习：SQL*Plus 和 SQL Developer。开发人员每天都要使用

这两种工具。这些练习和许多示例都建立在两组数据演示(称为 HR 和 OE 模式)的基础上。有

些指令可以指示如何启动工具、创建演示模式，不过，在开始时可能需要得到本地数据库管理

员的帮助。本章简要介绍 Oracle 服务器技术、SQL 语言、客户工具和演示模式。当讨论关系范例和

将数据规范到关系结构中的相关概念时，介绍几个有关数据组织的真实案例。

1.1 定位服务器技术

Oracle 服务器技术由一系列产品组成： ● Oracle Database ● Oracle WebLogic Server ● Oracle Enterprise Manager ● 各种应用程序开发工具和语言这些产品在 Oracle 产品集中都有各自的作用。数据库是存储数据的仓库和管理访问的引擎。

Oracle WebLogic Server 运行的是生成 Web 用户界面的软件，这些 Web 用户界面将对数据检索

和修改的请求提交给数据库执行。Oracle Enterprise Manager 是一种综合管理工具，可用来监控、

管理和调整 Oracle 进程以及第三方产品(通过插件)。最后，还有一些可用来开发应用程序的工

具和语言，这些应用程序包括：客户-服务器模型中在终端用户机上运行的应用程序，或者在

应用服务器上集中运行的应用程序。服务器技术和开发工具的结合为应用程序的开发和传递构建了一个平台，它支持云

(cloud)。云是传递 IT 服务的一种方法，它可以最大化整个环境的成本效率，其方法就是将计

算能力从一些可用资源按需传递到任何需要它的位置。

第 1 章使用 Oracle 设计关系数据库

3

1.1.1 Oracle 服务器的体系结构

Oracle 数据库就是磁盘上的一组文件。在有意删除这些文件之前，它一直存在。由于对这

些文件的大小和数量没有实际限制，因此对数据库的大小也就没有实际限制。可通过 Oracle实例访问数据库。实例就是一组进程和内存结构，它存在于 CPU 上以及服务器节点的内存中，

但这种存在是暂时的。可以启动和停止实例。数据库用户依据实例建立会话，之后由实例来管

理对数据库的所有访问。在 Oracle 环境中，任何用户都绝对不可能直接与数据库打交道。连接

Oracle 数据库的 Oracle 实例组成 Oracle 服务器。 Oracle 服务器实现的处理模型是客户-服务器处理模型，通常称为双层(two-tier)模型。在客

户-服务器模型中，用户界面以及许多应用程序逻辑的生成都独立于数据的管理。对于使用 SQL开发的应用程序(和所有关系数据库应用程序一样)而言，这意味着客户层生成 SQL 命令，服务

器层执行它们。这是基本的客户-服务器分离，两者之间通常还有局域网。用户进程和服务器

进程之间使用的网络通信协议是 Oracle 的专有协议——Oracle Net。客户层由两个组件组成：用户和用户进程。服务器层包含三个组件：执行 SQL 的服务器

进程、实例和数据库本身。每个用户都与用户进程交互。每个用户进程都与服务器进程交互，

通常这要跨局域网。服务器进程与实例交互，实例与数据库交互。图 1-1 用示意图显示了这种

关系。会话是与服务器进程进行通信的用户进程。通常每个用户有一个用户进程，每个用户进

程有一个服务器进程。组成会话的用户进程和服务器进程由用户根据需求来启动，当不再需要

时就终止，这就是登录和退出周期。实例进程和内存结构由数据库管理员启动，直到管理员有

意终止它们为止，这就是数据库的启动和关闭周期。

图 1-1 用户和数据库之间的间接连接

用户进程可以是能够连接 Oracle 服务器进程的任何客户端软件。本书广泛使用两个用户

进程：SQL*Plus 和 SQL Developer。它们是 Oracle 提供的简单进程，用来依据 Oracle 服务器建

立会话，并发布即席(ad hoc)SQL。广泛使用的另一个工具是来自 Quest Software 的 TOAD(Tool for Application Developers，应用程序开发人员工具)，这是一款拥有许可的软件。终端用户应用

程序需要使用比这些工具更复杂的东西来完成，这些东西必须能够管理窗口、菜单、正常屏幕

对话等。这种终端应用程序可以使用 Oracle Development Tools 来编写，也可以使用链接到

Oracle ODBC 驱动器的 Microsoft Access，或使用任何第三代语言(例如 C 或 Java)—— Oracle 已经为它们提供了函数调用库，使之与服务器交互，或者使用与 Oracle 兼容的任何第三方工具来

编写。其实用户进程是什么对于 Oracle 服务器根本不重要。当终端用户填表后单击 Submit 按钮时，用户进程会生成一个 INSERT 语句(第 10 章将详细讨论)，并将它发送给服务器进程以便


4

依据实例和数据库执行。至于服务器，可以将 INSERT 语句输入到 SQL*Plus，也就是所谓的

即席 SQL。注意，与 Oracle 服务器的所有通信都遵循这种客户-服务器模型。用户代码与服务器代码

的分离从数据库的最早版本开始就有，这不可避免。即使用户进程在与服务器相同的机器上运

行(例如，如果有人在自己的笔记本电脑上出于开发和培训的目的运行数据库)，也会实行客户-服务器分离，网络协议仍然适用于这两个进程之间的通信。对于数据库访问而言，在应用服务

器环境中运行的应用程序(下一节将介绍此内容)也遵循客户-服务器模型。数据库服务器的最简单形式是一个数据库连接一个实例，但在更复杂的环境中，一个数据

库可以被许多实例同时打开。这就是所谓的 RAC(Real Application Cluster，实时应用程序集群)。RAC 有许多潜在好处，包括可扩展性、性能和无停工期(zero downtime)。将在更多节点上运行

的更多实例动态地添加到数据库的能力，是数据库对云的主要作用。

1.1.2 Oracle WebLogic Server

随着 Web 作为将应用程序传递给终端用户的标准通信平台的出现，人们开始需要应用服

务器。应用服务器取代了通常安装在终端用户终端上的客户端软件，它集中运行应用程序，在

Web 浏览器的本地窗口中将它们呈现给用户。应用程序使用存储在一个或多个数据库服务器中

的数据。 Oracle WebLogic Server 是用于开发、部署和管理 Web 应用程序的平台。Web 应用程序可

以被定义为用户通过 HTTP 与之通信的任何应用程序。Web 应用程序通常至少在以下三层中运

行：数据库层管理对数据的访问，客户层(通常实现为 Web 浏览器)处理与用户通信的本地窗口

管理，中间的应用层执行程序逻辑，生成用户界面和对数据库的 SQL 调用。可以使用多种技术来开发 Web 应用程序，其中最主要的是 Java。使用 Java 编写的应用程

序应该符合 Java EE(Java Enterprise Edition，JEE)标准，该标准定义如何打包和部署这种应用程

序。JEE 及相关标准通常由 Oracle 控制，几乎已经被所有软件开发人员所接受。Oracle WebLogic Server 是与 JEE 兼容的应用服务器。通过 JEE 集群，Oracle 的标准实现方式允许多个机器上的

多个应用服务器之间的自动负载平衡和容错。集群提供的实际上是应用程序服务，用户可以从

多个位置请求应用程序，集群从能够最好地服务于会话或者请求的位置开始提供服务。如果一

个位置失败，其他位置会承担负载。如果有必要，应用程序也可以使用更多资源。Oracle WebLogic Server 对云的重要作用是，将服务请求与提供服务的位置相分离以及动态添加或者从

集群中删除 JEE 服务器。重要的是要注意，Oracle 对国际标准的承诺非常坚定。在 Oracle WebLogic Server 环境中

运行的应用程序可以连接到任何数据库，只要这些数据库中有与 Java 兼容的驱动器，不一定

要使用 Oracle 数据库。使用 Oracle WebLogic Server 工具箱开发的应用程序可以部署到与 JEE兼容的任何第三方应用服务器。

最简单的 Web 应用处理模型是三层：客户层管理用户界面，中间层生成界面并将 SQL 语

句发送给数据层，数据层管理数据本身。在 Oracle 环境中，客户层可能是一个浏览器(例如

Mozilla Firefox 或者 Windows Internet Explorer)，它处理本地窗口管理，控制键盘，跟踪鼠标运

动。中间层可能是运行软件(可能是用 Java 语言编写)的 Oracle WebLogic Server，它生成发送到

客户层用于显示的窗口，以及发送到数据层执行的 SQL 语句。数据层就是 Oracle 服务器：实

例和数据库。在这个三层环境中，存在两种类型的会话：从客户层到中间层的终端用户会话和


5

从中间层到数据层的数据库会话。终端用户会话使用 HTTP 建立。数据库会话是由用户进程和

服务器进程组成的客户-服务器会话，如上一节所述。应用程序可能使用从终端用户会话到数据库会话的一对一映射：每个用户都可以从他们的

浏览器中依据应用服务器建立会话，应用服务器可以依据代表用户的数据库服务器建立会话。

然而，事实证明，相对于连接池(connection pooling)模型而言，这种模型十分没有效率。使用

连接池模型，应用服务器会建立相对较少的永久数据库会话，并让它们按需求(如有必要可排

队请求)对相关的大量终端用户会话(相对于应用服务器)可用。图 1-2 说明了使用连接池的三层

体系结构。

图 1-2 连接池模型

从数据库的观点来看，SQL 语句是来自客户端进程(例如 SQL*Plus 或 Microsoft Access)还是来自到应用服务器的入池会话，这并没有什么不同。在前面的示例中，用户进程都在一台机

器上运行；在后面的示例中，用户进程被划分到两层：生成用户界面的应用层和显示它的客

户层。

1.1.3 Oracle Enterprise Manager

IT 装置不断增加的规模和复杂性让管理变成了一项具有挑战性的任务。这并不奇怪：没有

人说管理强大的环境一定很简单。然而，管理工具会让这项任务变得相对容易，让管理人员更

有效率。 Oracle Enterprise Manager 有如下三种形式： ● Database Express ● Fusion Middleware Control ● Cloud Control Oracle Enterprise Manager Database Express 是一种用来管理一个数据库的图形工具，这个

数据库可以是 RAC 集群数据库。它由在数据库服务器上运行的 Java 进程组成。管理员从浏览

器连接到 Database Express，Database Express 再连接到数据库服务器。Database Express 有利于

进行实时管理和性能监控，运行定期作业。Oracle Enterprise Manager Fusion Middleware Control是一种用来管理 Fusion Middleware 部署的图形工具。通常，这些部署包括 Oracle WebLogic Server，以及为 Java 虚拟机(Java Virtual Machine，JVM)提供容器的行业领先的应用服务器，其


6

中容器中驻留的是 Oracle 或定制的 Java 应用程序。 Oracle Enterprise Manager Cloud Control 全局化管理环境。管理仓库(驻留在 Oracle 数据库

内)以及一个或多个管理服务器管理整个环境：所有数据库和应用服务器，不管它们在哪里。

Cloud Control 也可以管理节点或者机器(服务器在其上运行)，以及通过插件管理大量第三方产

品。每个被管理的节点都运行代理进程，由代理进程负责监控节点上被管理的目标，即在节点

上执行作业，并将状态、活动等级和告警条件报告给管理服务器。 Cloud Control 从全局观察环境，如果配置良好，会让管理人员更有效率(相对于不使用它

而言)。这样，一个管理员就可以有效管理几百个目标。

1.1.4 云计算

云计算最重要的概念是服务虚拟化(service virtualization)。这意味着在所有级别上，在请求

服务和提供服务之间都有一个抽象层。终端用户请求应用服务，并让云计算出哪个集群的 JEE应用服务器最适合提供这个服务。然后，应用服务器请求数据库服务，并让云计算出最好从哪

个 RAC 节点提供数据。在云内，在可能的服务与可用的服务提供商之间有一种映射，并且还

有如何合理分配工作量和资源的算法。因此终端用户既不需要知道也无法知道实际上从哪里提

供计算资源。可以用国内电力的传递方式进行类比：按需求提供电，但房主并不知道目前是哪

个发电站在给他供电。云并不是 Oracle 独有的。在物理级别上，有些操作系统和硬件供应商也能够提供类似云的

性能。这些性能包括能够将服务器划分为几个虚拟机，并依据需要在虚拟机中动态添加或者删

除 CPU 和 RAM。从概念上讲，这与 Oracle 将应用服务器和数据库服务器资源动态分配给逻辑

服务的方法类似。将这两种方法结合起来使用是合情合理的，因为它们的目标相同，并且能够

一起运行。将它们结合起来可以形成一种环境，其中会按要求提供足够的资源，而不会面临有

时性能过强有时性能低下的问题。也可以设计一种云环境，其中没有失败点，从而实现运行时

间 100%正常的目标，这也是许多用户所希望的。 SQL 应用程序开发人员不需要知道如何实现云。连接到数据库的实例会从应用服务器中调

用 SQL 并执行，然后由云负责确保在任何时候都可以使用适合当前工作量大小的应用服务器

和实例池。

练习 1-1

研究数据库和应用程序环境

本练习是纸上练习，没有具体的解决方案。尝试确定在自己的环境中使用的用户进程、应用服务器和数据库服务器。试着弄清楚在哪

里生成 SQL，在哪里执行它。注意，终端用户通常使用的用户进程是图形化的，它们通常要穿

过应用服务器；而数据库管理和开发人员通常喜欢使用客户-服务器工具，这些工具直接连接

到数据库服务器。

1.1.5 开发工具和语言

Oracle 服务器技术包括用来开发应用程序的各种工具，这些工具有些在数据库之内，有些

在数据库之外。


7

在数据库内可以使用三种语言。有一种语言不可避免，它就是本书的主题——SQL。SQL可用于数据访问，但不能用来开发完整的应用程序。它没有用于开发用户界面的实际工具，也

缺少单独操作行所需的程序结构。可用于数据库的另外两种语言填补了这些不足。它们是

PL/SQL和Java，不过Java语言也可以用于数据库之外。PL/SQL是Oracle专有的第三代语言

(3GL)。它具有通常的程序结构(例如if-then-else和循环)以及用于用户界面设计的工具。在

PL/SQL代码中，可以嵌入对SQL的调用。因此，PL/SQL应用程序可以使用SQL从数据库中检

索一行或多行，然后依据其内容执行各种动作，也可以使用SQL将行写回数据库。Java提供类

似的功能，也能够在Java代码里嵌入SQL调用。有这样的行业标准技术：所有Java编程人员都

应该能够编写用来处理Oracle数据库(或者其他任何与Java兼容的数据库)的代码。其他语言可用于开发在数据库外部运行的客户-服务器应用程序。最常用的是C语言和 Java

语言，但也可以使用大多数主流3GL。对于所有这些语言而言，Oracle Corporation 提供了

OCI(Oracle Call Interface，Oracle 调用接口)库，它让用这些语言编写的代码依据 Oracle 数据库

建立会话，并调用 SQL 命令。许多组织不愿意使用 3GL 来开发数据库应用程序。但 Oracle Corporation 提供了一些快速

的应用程序开发工具，如 Oracle Application Express、JDeveloper、ADF 和许多其他产品。这些

工具可以让使用 3GL 的编程人员更有效率。和语言一样，所有这些应用程序开发工具最终都

要做同一件事：构造发送给数据库服务器执行的 SQL 语句。

注意：在 Oracle 环境中工作的所有开发人员和管理员都必须掌握 PL/SQL。C 和 Java并不是必须要掌握的，除非项目指定要使用它们。

1.2 理解关系结构

本节中引入了几个有关数据组织的真实案例，以此描述了关系范例并介绍了一些实际的建

模技术。对于理解 SQL 而言最重要的是，理解关系范例和将数据规范(normalize)到关系结构的

能力。规范化是系统分析员的工作，因为他们将公司数据建模为一种适合在关系表中保存的形

式。这门学科可能需要研究数年，许多学校都开发了自己的方法和符号。

1.2.1 真实的案例

本书中使用了几个假定的案例，其中包括 Oracle 提供的两个预先准备好的案例：HR 和

OE，它们经常用作 OCA 考题的上下文，以说明各种 SQL 概念。下面的案例进一步演示了所

讨论的新概念。

1. Car Dealership 案例

Sid 经营着一家汽车经销店，她需要一个能够跟踪汽车购买与销售的系统。Sid 发现她的生

意一落千丈，希望在进入 21 世纪后能够扭转局面，并创建一个网站来为库存做广告。她希望

该系统能够跟踪汽车购买与销售的记录以及这些交易的详情。


8

2. Geological Cores 案例

地球的岩芯样品都由当地的地质调查局收集。为了确保科学的严谨性，GeoCore 的开发人

员确定系统必须能够跟踪确切的地理位置、岩芯样品的元素含量以及收集日期。

3. Order Entry 案例

Order Entry(OE)案例是由 Oracle 提供的一个样例，包含了一个虚构的商业系统所跟踪的产

品、客户以及已下的销售订单的信息。

4. Human Resources 案例

Human Resources(HR)案例也是 Oracle 公司提供的一个样例，记录 HR 部门的员工、部门、

办公地点以及与工作相关的信息。尽管这些假定的案例所描述的复杂度各不相同，但它们有几个共同的特征：包括数据的潜

在增长，这种增长最终将导致基于纸张或电子表格的数据组织解决方案难以承受；也包括要求

以有效的方式来操作(插入、更新和删除)和检索数据。产生有效的数据组织设计(也就是所谓的

数据模型)面临的挑战或许在于理解如何利用这些已被组织的数据以及一些基本的数据建模方

法。其目标就是在数据存储和数据访问之间达到一种最佳平衡，从长远来看，这样可以为下游

节省成本。

1.2.2 数据建模

有多种正式的数据建模方法可用，如 Zachman 框架和 Rational Unified Process，从根本上

来讲，这些方法旨在提供一种表示企业对象的系统化且基于标准的方法。有众多的符号可用来

建模实体及其关系。其中 Oracle 在它的 CASE(Computer Aided Software Engineering)工具中和

近来在 SQL Developer 中采用的一种流行的符号是 crow’s foot 符号，该符号将在后文中讨论。

其他符号，如 Relational Schema 符号和 UML (Universal Markup Language)也很流行，但你必

须选择自己用起来得心应手和合乎情理的符号。逻辑建模基于将感兴趣的对象概念化为实体(entity)和将这些对象彼此间的交互概念化为

关系(relationship)。有多种方法可用来表示实体-关系图，这些方法各有利弊。下面将简要讨论

实体-关系图及其符号。

1.2.3 实体和关系

许多 Oracle 专家都采用由三个建模阶段组成的框架来建模关系数据库。当称作实体的高级

别的构造(由各种属性及其关系组成)通常都在一个图中表示时，采用逻辑模型比较方便。逻辑

模型中的实体通常被描述为圆角的正方形，由属性或标识符组成，有时由符号“o”来表示。

唯一标识实体实例的属性为主键，有时由符号“#*”来表示。属性中数据的输入就是在这个阶

段完成的，但这通常不会反映到设计中。之后逻辑模型会转换成为关系模型，方法是将实体转换为关系(也就是通常所指的表)。在

此建议将实体的一组实例都建模为一个表。属性被转换为表的列。实体的每个实例作为数据元

组(tuple)或数据行，每个元组或行都包含不同的属性值或列值。表中的行数是元组的基数。通

常，唯一标识每一行的属性称为唯一键(unique key)，也就是所说的主键(primary key)，后面将


9

讨论它。实体之间的关系通常被建模为外键(foreign key)，后面也将讨论它。关系模型中的关系通常被描述为长方形。在这个阶段，通常要为属性输入详细的数据，主

键和外键属性在关系模型中也分别表示为“P”和“F”。最后，在关系数据库中实现设计，将

关系模型工程化为物理模型。 crow’s foot 符号通常用来描述逻辑数据模型和关系数据模型中的关系。实体之间的关系可

以是如下之一，我们将在 Car Dealership 案例中探讨这些关系。 ● 1:N——一对多 ● N:1——多对一 ● 1:1——一对一 ● M:N——多对多考虑前面介绍的 Sid 的汽车经销店案例。可以将数据建模为由如下与汽车相关的属性组成

的实体：Make、Model、Engine Capacity 和 Color。也需要有关购买和销售汽车的信息，因此

可以添加 Purchase Date、Sold Date、Sellers Name、Sellers SSN (Social Security Number)、Sellers Company、购买者的详细信息，以及 Purchase Price 和 Selling Price，如图 1-3 所示。

图 1-3 一个汽车经销店实体

基于这个实体的存储在表中的样例交易数据看起来如图 1-4 所示，该图显示了

CAR_DEALERSHIP 表中的三行数据，每行由 14 列组成。创建表和用数据填充表的命令将在

本书后面讨论。现在，要注意几个更基本的重要事情。表将数据存储在行(也称为记录)中。每

个数据元素位于行和列的交叉点处(也称为单元格)。这相当直观，且十分类似于电子表格。

图 1-4 CAR_DEALERSHIP 表中的样例数据


10

CAR_DEALERSHIP 表中的前两行包含如下信息： ● 发动机容量为 1600cc 的银色 Mercedes A160 的车主是 SSN 为 12345 的私人卖家 Coda，

该车于 2013 年 6 月 1 日被来自 Sid’Car、SSN 为 12346 的 Sid 以 10 000 美元的价格购买。 ● 发动机容量为 1600cc 的银色 Mercedes A160 的车主是来自 Sid’Car、SSN 为 12346 的

Sid，该车于 2013 年 8 月 1 日被来自 Wags Auto、SSN 为 12347 的 Wags 以 12 000 美元

的价格购买。注意数据的重复。每个记录中都包含有关购买或销售汽车以及购买或销售汽车的客户的重

复信息。通常，数据的不必要重复表示设计比较糟糕，因为这是一种浪费并且经常需要不必要

的维护。如果维护工作做得不够仔细，这样的设计就会导致错误(有时是指插入、更新和删除

的异常)，并降低数据的整体完整性。数据库的规范化是指使用多个实体以及实体间的关系来对数据进行建模，这可能会减少或

完全消除数据冗余。虽然从理论上而言，定义了许多类型的范式，但关系数据库的设计主要使

用以下 3 种范式： ● 第一范式(1NF)消除不必要重复的数据组。图 1-4 中的一个重复组的示例是，表中描述

汽车的前两行的前 4 个列是重复的。可以定义一个新的 Cars 实体来唯一地标识具体的

汽车，方法是使用 Car ID 主键属性和 Make、Model、Engine Capacity 和 Color 属性。

然后，在相关的 Transactions 实体中可以使用该 Car ID 标识符来避免数据组的重复。 ● 第二范式(2NF)从不依赖于主键的实体(1NF)中删除属性。与上面描述的 Cars 实体相对

的是，Color 属性不依赖于特定的汽车。你可以定义一个新的 Colors 实体使用 Color ID主键属性来唯一标识具体的颜色。然后可以通过 Cars 实体来引用 Color ID。

● 第三范式(3NF)从 2NF 实体中删除所有相互依赖的属性。每辆汽车的购买者和销售者

都有一个唯一标识符 Social Security Number(SSN)。但他们的名字都相互依赖于 SSN 属

性。可以使用 Customer ID 主键属性来定义唯一标识客户的新 Customers 实体，以存储

类似于客户姓名和公司的这些相互依赖的信息。

注意：通常，有几种规范化的模型可用于应用程序，重要的是，一定要使用最合适的

模型——如果系统分析员为应用程序使用了错误的模型，那么对程序的性能、

存储需求和开发成本可能会带来严重的后果。

注意：在性能调整的上下文中，重复实体中的数据是有意而为之的且是可以接受的。当跨

多个被实例化为多个表的实体规范化数据时，这些数据必须要连接在一起，Oracle 服务器进程

需要从多个表中物理地获取数据，并将其连接到内存缓冲区中，生成所需的结果集。有时在查

询或操作规范化的数据时，需要额外的 IO 来证明非规范化的数据模型可以减少磁盘 IO 操作，

并因此而提高了性能。这种情况在数据仓库(Data Warehouse，DWH)和决策支持系统( Decision Support Systems，DSS)中很普遍，但在线事务处理系统(Online Transaction Processing，OLTP)中的规则例外。

考虑图 1-5 中的逻辑数据模型。与汽车相关的数据被建模为 Cars 实体。客户(购买者和销

售者)的信息实质上是一样的，因此他们被建模为 Customers 实体，可以通过该实体的 Customer


11

Type 属性来区分 Purchasers 和 Sellers。有关购买和销售的信息记录在 Transactions 实体中，而

名为 Colors 的查找(lookup)实体则跟踪不同的颜色。

图 1-5 汽车经销店的实体-关系图

将这种设计概念化为这 4 种相互关联的实体具有许多优点。首先数据已被规范化，不存在

重复的现象。多个实体相互关联的一个实际好处在于使得数据的维护变得更加轻松，因为每个

实体都记录了一个结构，如 Cars、Customers、Colors 和 Transactions。可以添加新的颜色，每

种颜色都有一个唯一的编码，并且当购买了新的汽车时，在一个地方定义和维护的这些颜色可

以用来描述同一颜色的多个汽车。通过为 Tires、Security Systems、Tracking Devices 或 Audio Visual 插件定义实体可以提高模型的精准性。同样，也可以增加对每辆汽车收集的细节(如 VIN和发动机编号)或对客户收集的细节(如地址和银行细节)。但这个假想的案例只是用来演示一些

概念，在未进一步改善的情况下，显然不能在生产应用程序案例中使用它。

1. 主键

图 1-5 中的每个实体都有一个主键属性，它通过一个#*和邻近的属性名来唯一地标识一个

数据元组或数据行。Car ID 主键的每个值在实体中都是唯一的。多行不能共享同一个主键值。

同样，Color ID 也唯一地标识 Colors 实体中的每一行。Customers 和 Transactions 实体中的

Customer ID 和 Transaction ID 也分别如此。


12

2. 关系

图 1-5 中链接各种实体的直线称为关系。crow’s foot 符号表示两个实体间关系的基数——

一对一、一对多、多对一和多对多。crow’s foot 符号显式地演示了实体在关系的多端带有多个

“脚”，而在一端只有一个脚。一对一关系中的属性是相同的，而多对多关系则表示实体 A 中

的多个元组与实体 B 中的多个元组有相同的属性值。一对一和多对多关系不是很常见，在关系

模型中使用这两种关系有时会导致一些缺陷。一对多和多对一关系常用来建模关系实体。它们

以主-从(master-detail)关系将两个实体中的属性关联起来。例如，从 Cars 和 Colors 实体(顺序

很重要)间的关系的角度来看，Cars 实体中的许多记录是一个 Color。许多汽车可能用同一个

Color ID 属性来表示它们具有相同的颜色。Colors 实体是该关系中的主(master)或查找(lookup)实体，而 Cars 实体是从(detail)实体。从 Colors 和 Cars 实体间的关系的角度来看，一个 Colors可以和多个 Cars 相关联。因此，这两个实体间的关系是一对多还是多对一，只是视角的问题，

这完全取决于你所考虑的关系的方向。crow’s foot 符号表示的其他关系显示了一辆汽车可以被

购买和销售多次，因此 Cars 和 Transactions 实体间是一对多的关系，并且一个客户可以实现多

个交易(例如，购买和销售多辆汽车)。

3. 参照完整性和外键

前面介绍的这些关系引入了参照完整性的概念。在一对多关系中，假设关系中位于“一”

端的实体有一个属性 A，且属性 A 描述了一个唯一值集合，位于“多”端的实体有一个属性 B。参照完整性通过确保属性 A 是唯一的，属性 B 的值包含在属性 A 描述的唯一值集合中，来确

保数据的一致性和完整性。属性 B 叫做外键，因为它对属性 A 有一个参照依赖。考虑基于 Color ID 属性的 Colors-Cars 关系。参照完整性可以确保 Cars 实体中每个元组的 Color ID 属性必须有

一个值完全等同于 Colors 实体中 Color ID 属性的实例。这种保证是关系建模的核心所在，因为

Cars 和 Colors 实体间通过 Color ID 的连接允许 Colors.Color(注意这是个点符号)属性与 Cars 实体中的相关属性相匹配。Cars 实体中的 Color ID 属性是外键，它与 Colors 实体中的唯一键 Color ID(碰巧也是主键)相关联。虽然一个实体中的外键基于另外一个相关实体的主键这种情况很常

见，但这并不是一种规则。

注意：虽然一个实体中的外键基于另外一个相关实体的唯一键，但这些唯一键并非必须是

主键，它们只是必须唯一即可。

通常，图 1-5 中的逻辑模型会演化成一个典型的关系模型，包含更多的数据输入细节和更

清楚明了的主键和外键，如图 1-6 所示。关系模型可以被工程化为物理模型，在这种物理模型中会创建一些实际的表和其他数据库

结构(本章后面将讨论)。图 1-4 中的样例数据从关系模型被转换为物理模型后，生成了 4 个数

据集，如图 1-7 所示。


13

图 1-6 汽车经销店的关系模型

图 1-7 使用汽车经销店关系模型的样例数据

Transactions 数据集中的前两行数据可以解释为： ● TX ID 为 100 的交易描述了 Car ID 为 1 的汽车的购买情况，该汽车于 2013 年 6 月 1


14

日由 Sid 汽车经销店从 Customer ID 为 2 的客户那里以 10 000 美元的价格购买。你查

找 Customer ID 为 2 的客户，并发现该客户是 SSN 为 12345 的私家车主 Coda。你查找

Car ID 为 1 的汽车，确定了该车是一辆 Color ID 为 1 的 2001-A160 Mercedes，其中 Color ID 为 1 可以进一步解析为颜色为 Silver。

● TX ID 为 101 的交易描述了在 2013 年 8 月 1 日，以 12 000 美元的价格将 Car ID 为 1的汽车销售给 Customer ID 为 4 的客户的情况，Customer ID 为 4 的客户可以进一步解

析为 SSN 为 12347、来自 Wags Auto 的 Wags。基于前面在单个实体设计中的描述，将这 4 个实体设计中的样例数据组织起来，其实什么

数据也没有丢失。相反我们却获益颇多。数据不再重复，而且当购买和销售新汽车时以及当新

顾客与 Sid 的汽车经销店进行交易时，数据的这种清晰性和简洁性使得其维护更加轻松。

练习 1-2

为 Geological Cores 案例设计实体-关系图

在本练习中，通过完成前面介绍的 Geological Cores 案例的实体-关系图，你将熟悉基本的

关系建模。扼要重述一下：地球的岩芯样品已由当地的地质勘查局收集。为了确保科学的严谨

性，GeoCore 的开发人员决定该系统必须能够记录确切的地理位置、岩芯样品的元素含量和收

集日期。 (1) GeoCore 的开发人员提出了 4 种实体，表 1-1 给出了这几个实体以及它们各自的属性，

并给出了每个实体的主键。

表 1-1 实体及其属性

实体属性

Elements Atomic Number(主键)

Element Description

Symbol

Atomic Mass

Contents Content ID(主键)

Atomic Number

Quantity

Depths Depth ID(主键)

Start Depth

End Depth

Cores Core ID(主键)

Depth ID

Collection Date

Longitude

Latitude

Content ID


15

(2) Elements 和 Contents 实体通过 Atomic Number 属性共享多对一关系。Cores 实体通过

Depth ID 属性和 Depth 实体共享多对一关系，通过 Content ID 属性和 Contents 实体共享多对一

关系。你的任务是更新实体图，以反映这些关系。完成后的实体-关系图应该十分类似于图 1-8。

图 1-8 完成后的实体-关系图

1.2.4 行和表

关系范例将数据建模为二维表。表由许多行组成，行由一组列组成。在表内，所有行都有

相同的列结构，虽然在有些行中有些列里面可能什么内容也没有。例如，表可以是某公司员工

列表，每行表示一名员工。列可以是员工编号、姓名和员工工作的部门编码。当前没有分配到

部门的员工该列为空白。表还可以是部门列表：每个部门一行，列表示部门编码和部门名称。关系表符合限制和定义数据的某些规则。在列级别，每列必须是一种数据类型，例如数字、

日期-时间或者字符。字符数据类型最常见，因为它可以接受所有类型的数据。在行级别，每

行通常必须有某种唯一确定的特征：可能是一列的值，例如前面示例中的员工编号和部门编号，

它们在不同行中不能重复。也有一些可以定义表间链接的规则，例如必须给每名员工分配一个

部门编码，而该编码必须匹配部门表中的行。表 1-2～表 1-5 是表格形式的数据定义的示例(表中的数据和结构是 Oracle 提供的 SCOTT 示例模式的一部分)：

表 1-2 DEPT 表

列名说明数据类型长度

DEPTNO 部门编号数字 2

DNAME 部门名称字符 14


16

表 1-3 EMP 表

列名说明数据类型长度

EMPNO 员工编号数字 4

ENAME 员工姓名字符 10

DEPTNO 部门编号数字 2

表 1-4 DEPT 表中的行数据

DEPTNO DNAME

10 ACCOUNTING

20 RESEARCH

30 SALES

40 OPERATIONS

表 1-5 EMP 表中的行数据

EMPNO ENAME DEPTNO

7369 SMITH 20

7499 ALLEN 30

7521 WARD 30

7566 JONES 20

7654 MARTIN 30

7698 BLAKE 30

7782 CLARK 10

7788 SCOTT 20

查看DEPT表(表 1-2)和EMP表(表 1-3)的布局，可以看到表中的二维结构显而易见。每行的

长度固定，每列的长度也固定(如果需要可以填充空格)，用直线来界定各行。表 1-4 显示了以

DEPTNO排序的DEPT表中的行，但这只是巧合，并不是设计时有意而为之：关系表对行不强

加任何特定的排序。表 1-5 显示了部门编号 10 有一名员工，部门编号 40 没有员工。通常，改

变数据会严重影响关系模型。可以将新员工追加到员工表，或者通过改变行中的DEPTNO值，

将他们从一个部门移动到另一个部门。考察另一种结构，它依据层次范例保存数据。因为技术的原因，对层次模型的开发早于对

关系模型的开发。在计算机早期，存储设备无法维护许多关系表所需的大量单独文件。但在

Oracle 数据库中，通过从逻辑存储(表)抽象物理存储(文件)，可以避免这个问题：表和文件之间

没有直接连接，当然也就没有一对一映射。其实，许多表可以保存在少数几个文件中。层次结构在一个单元中保存所有相关数据。例如，部门的记录包含该部门的所有员工。层

次范例速度非常快，也非常节省空间。一次文件访问可能只需要检索一些查询所需的数据。前

面列出的员工和部门可以分层保存，如下所示：


17

10,ACCOUNTING,7782,CLARK

20,RESEARCH,7369,SMITH,7566,JONES,7788,SCOTT

30,SALES,7499,ALLEN,7521,WARD,7654,MARTIN,7698,BLAKE

40,OPERATIONS

在这种示例布局中，行和列的长度是可变的。列用逗号分隔，行用直线分隔。如果查询可

以定位这种层次结构，那么数据检索的效率通常很高：只要知道员工的部门，就能快速找到该

员工。但是如果不知道，检索可能比较缓慢。如果对数据的变更需要发生移动，那么可能存在

问题。例如，要将员工号为 7566 的 JONES 从 RESEARCH 移动到 SALES，这可能涉及对数据

库的部分数据的大量工作，因为这种移动的实现过程是从一行中删除它然后再将它插入另一

行。注意，在这个示例中，虽然某个部门可以没有员工(如 OPERATIONS 部门)，但绝对不可

能出现员工没有所属部门的情况。如果公司规则规定所有员工都必须有所属部门，这就有利于

设计，否则，对设计就不利。对于许多类型的数据而言，关系范例在许多方面都很高效，但它不一定适合所有应用程序。

通常，关系分析应该是系统建模要采用的第一种方法。只有证明它不合适时才使用非关系结构。

已被证明关系模型很有效的应用程序几乎包括所有联机事务处理系统(Online Transaction Processing，OLTP)和决策支持系统(Decision Support Systems，DSS)。关系范例可能需要硬件条

件，需要开发应用程序所需的技巧，但如果数据合适，那么它就是最通用的模型。例如，可能

有一些由于维护索引产生的问题，这些索引维护表和空间(在索引内和列驻留的表中维护索引

数据的多个副本所需的空间)之间的链接。无论如何，在大多数情况下，关系设计都是最理想

的模型。许多软件发布商已经开发了许多数据库管理系统，这些系统在不同程度上符合关系范例，

Oracle 只是其中一个。IBM 也许是将主要资源保存到关系数据库的第一家公司，多年以来 IBM的关系数据库产品(后来发展为 DB2)都没有移植到非 IBM 平台。Microsoft 的 SQL Server 是另

一个关系数据库，它受到运行平台的限制。相反，Oracle 从首次发布开始就一直被移植到所有

主要平台，可能就是这一点让 Oracle 在 RDBMS 市场上占据了领先位置。术语提示：当与习惯使用 Microsoft 产品的人讨论关系数据库时，可能会出现混淆。SQL

是一种语言，SQL Server 是数据库，但在 Microsoft 中，术语 SQL 通常既表示语言也表示数据库。

案例&解决方案组织正在设计新的应用程序。

这会涉及哪些人？

所有人！项目小组必须包括业务分析员(建模业务流程)、系统分析员(建模数

据)、系统设计人员(决定如何实现模型)、开发人员、数据库管理员、系统管

理员以及(最重要的)终端用户

关系结构可能不适合特定应用

程序。这如何确定，下一步应

该怎么做？Oracle 有用吗？

尝试将数据规范化到二维表中，使用一对多关系链接。如果不能实现，请考

虑其他范例。Oracle可能会很有帮助。地图和地理数据的运行确实不会相关，

文本数据(例如字处理文档)也不会。例如，这时，可以使用Spatial和Text数据

库。也可以使用用户定义的对象来保存非表格式的数据


18

1.3 SQL 语言概述

SQL 由国际组织定义、开发和控制。Oracle Corporation 不一定要遵守 SQL 标准，但它选

择这样做。SQL 语言本身非常简单(仅包含 16 个命令)，但实际上 SQL 编码非常复杂。这就是

需要用一整本书来讨论 SQL 基本原理的原因。

1.3.1 SQL 标准

SQL (Structured Query Language，结构化查询语言)首先由 IBM 研究小组于 20 世纪 70 年代

开发，但实际上之后不久 Oracle Corporation(后来注册为 Relational Software, Inc.)就声称已使用

第一种商业实现方式：Oracle 2，发布于 1979 年，击败 IBM 占领市场数周。从那时开始，SQL语言就快速发展，并且不再由任何一个组织驱动。SQL 现在是国际标准。它由 ISO 和 ANSI委员会管理。ISO 就是国际标准化组织(Organisation Internationale de Normalisation)的简称，总

部位于瑞士日内瓦；ANSI 是美国国家标准学会(American National Standards Institute)的简称，

总部位于美国华盛顿特区。这两个团体相互合作，它们的 SQL 标准也是一样的。 Oracle 数据库的早期版本使用 SQL 的一种实现方式，这种实现方式与 SQL 标准有一些重

要区别。这不是因为 Oracle 有意不同，通常是因为 Oracle 实现的特性领先于标准，当标准赶

上来时，它又使用不同的语法。例如外连接(第 7 章将详细讨论)，Oracle 在标准 SQL 很早之前

就实现过它；当标准 SQL 引入外连接时，Oracle 又增加对新连接语法的支持，同时保留对自

身专有语法的支持。Oracle Corporation 通过在各个 ISO 和 ANSI 委员会中安排人员来确保未来

的一致性，帮助推动 SQL 标准向前发展。

1.3.2 SQL 命令

主要的 SQL 命令有 16 个，按照常用的分组划分如下：数据操作语言(Data Manipulation Language，DML)命令： ● SELECT ● INSERT ● UPDATE ● DELETE ● MERGE 数据定义语言(Data Definition Language，DDL)命令： ● CREATE ● ALTER ● DROP ● RENAME ● TRUNCATE ● COMMENT 数据控制语言(Data Control Language，DCL)命令： ● GRANT ● REVOKE


19

事务控制语言(Transaction Control Language，TCL)命令： ● COMMIT ● ROLLBACK ● SAVEPOINT 第一个命令 SELECT 是第 2 章到第 9 章讨论的主题。第 10 章讨论剩下的 DML 命令以及

TCL 命令。第 11 章详细讨论 DDL 命令。DCL 与安全性有关，这里只是简要提及，它更多地

属于数据库管理员而非开发人员的领域。

注意：依据所有文档所述，SELECT 是 DML 语句。实际上，当人们提到 DML 时，没

有人会包含它——他们讨论它，好像它本身就是一种语言一样(它几乎就是)，而使用 DML 来表示改变数据的命令。

1.3.3 面向集合的语言

大多数 3GL 都是过程语言。使用过程语言的编程人员指定如何操作数据，每次一行。使

用面向集合语言的编程人员指出他们要对一组行(“集合”)做什么，然后让数据库解决如何做，

无论集合中有多少行。对于开发和执行而言，过程语言在管理数据方面通常比面向集合的语言效率要低。循环一

组行并逐个更新它们的例程会包含许多行代码，而 SQL 可能只使用一个命令就能完成所有操

作。这样就提高了编程人员的效率。在程序执行过程中，程序代码没有给数据库提供选项，它

必须运行已经写好的代码。而使用 SQL，编程人员说明他要做什么，但不用说明如何做：数据

库能够解决如何最好地执行这种操作。这通常能够提供更好的结果。 SQL 不能提供完整的解决方案的原因在于，它纯粹是数据访问语言。大多数应用程序都需

要程序结构，例如流程控制：条件分支和迭代。它们通常还需要屏幕控制、用户界面工具和变

量。而 SQL 没有这些。SQL 是一种只能够进行数据访问的面向集合的语言。对于应用程序开

发而言，人们需要能够调用 SQL 的过程语言，因此 SQL 需要与过程语言一起使用。考察一个应用程序，它提示用户需要名称，使用该名称在表中检索所有人，提示用户选择

其中之一，然后删除选中的那个人。过程语言会绘制一个屏幕，并生成名称提示符。用户输入

名称。过程语言会使用该名称构建一条 SQL SELECT 语句，并通过数据库会话将该语句提交给

数据库服务器执行。服务器将一组行(所有具有该名称的人)返回给过程语言，过程语言以合适

的格式将这一组行显示给用户，并提示用户选择其中之一(或者多个)。然后使用选中者的标识

符来构建 SQL DELETE 语句，并提交服务器执行。如果标识符是唯一标识符(主键)，那么要删

除的就是一行；如果标识符是非唯一的，那么被选中要删除的集合可能会很大。程序代码并不

知道被检索或者删除的集合的大小。

1.4 使用客户工具

有许多工具可以用来连接 Oracle 数据库。最基本的两个是 SQL*Plus 和 SQL Developer。它们都由 Oracle Corporation 提供，完全能够胜任开发人员或者数据库管理员需要完成的工作。


20

对于它们之间的选择，部分原因是个人偏好，部分原因与环境有关，部分原因与功能性有关。

毫无疑问，SQL Developer 比 SQL*Plus 提供的功能更多，但它更苛刻，因为它需要图形终端，

而 SQL*Plus 可以在字符模式设备上使用。持续时间最长的工具是 SQL*Plus，即使 Oracle Corporation 强力开发 SQL Developer 作为

替代产品，但还是建议所有在 Oracle 环境中工作的人都应该熟悉它。

注意：许多有经验的开发人员和数据库管理员(也许还包括本书的作者)对新工具都有

所怀疑——不过这只能说明这些人有点守旧。本书始终使用这两种工具。

1.4.1 SQL*Plus

SQL*Plus 是用于连接数据库和发布即席 SQL 命令的客户-服务器工具。它也可以用来创建

PL/SQL 代码，并且有助于格式化结果。它可用于数据库能移植到的所有平台——接下来几小

节将讨论在 Linux 和 Windows 上使用 SQL*Plus 的细节。在不同平台上使用 SQL*Plus 没有太

大区别。在体系结构方面，SQL*Plus 是用 C 语言编写的用户进程。它建立与实例的会话，并通过

Oracle Net 协议建立数据库。客户和服务器的平台可以不同。例如，可以在 Windows PC 上使

用 SQL*Plus 来连接在 Unix 服务器上运行的数据库(或者相反)，假设 Unix 服务器已经将 Oracle Net 配置为可以进行连接。

1. Linux 上的 SQL*Plus

在 Linux 上安装的 SQL*Plus 的可执行文件是 sqlplus。该文件的位置由安装程序确定，通

常如下所示：

/u01/app/oracle/product/12.1.0/db_1/bin/sqlplus

应该建立相应的 Linux 账户来运行 SQL*Plus。还需要设置一些环境变量，它们是：

ORACLE_HOME PATH LD_LIBRARY_PATH

ORACLE_HOME变量指向Oracle Home。Oracle Home是Oracle软件安装程序：包含可执行

代码和某些配置文件的文件集和目录集。PATH必须包含Oracle Home中的bin目录。

LD_LIBRARY_PATH应该也包含Oracle Home中的lib目录，但实际上可以不设置它。图 1-9 显

示Linux终端窗口和一些测试(看看环境是否正确)。在图 1-9 中，首先 echo 命令检查这三个变量的设置是否正确：应该有 ORACLE_HOME 变

量，并且它里面的 bin 和 lib 目录分别被设置为 PATH 变量和 LD_LIBRARY_PATH 变量的最后

一个元素和第一个元素。然后 which 确定在 PATH 中 SQL*Plus 可执行文件确实可用。最后，

通过命令行上的用户名、密码和连接标识符启动 SQL*Plus。如果这些测试没有返回可接受的

结果，SQL*Plus 就无法启动，这时应该与系统管理员和数据库管理员进行讨论。本章稍后的

“创建和测试数据库连接”小节将讨论有关登录的一些常见错误。登录字符串的格式是数据库用户名，后面紧接着正斜杠(/)字符作为分隔符，然后是密码，


21

之后紧接一个@作为分隔符，最后是 Oracle Net 连接标识符。在本示例中，用户名是 system，

其密码是 admin123，数据库由 coda 来标识。

图 1-9 检查 Linux 会话设置

登录之后，接下来的几行文本显示所使用的 SQL*Plus 的版本(这里是 12.1.0.0.2)，连接的

数据库版本(它刚好与 SQL*Plus 工具的版本相同)，以及安装在数据库内的可选功能。最后一

行是用户提示符 SQL>，在此处用户可以输入任何 SQL*Plus 或者 SQL 命令。如果使用分配的

所有用户名(可能不是 system)都没有成功，就应该与数据库管理员联系。

2. Windows 上的 SQL*Plus

从历史的观点来看，一直有两种版本的 SQL*Plus 用于 Microsoft Windows：字符版本和图

形版本。字符版本是可执行文件 sqlplus.exe，图形版本是 sqlplusw.exe。在最新版本和 11g 中不

存在图形版本，但许多开发人员还是喜欢使用它。早期版本是处理 12c 数据库的极好工具。混

合这些版本没有问题：12c SQL*Plus 客户可以连接到 10g 数据库，10g SQL*Plus 客户可以连

接到 12c 数据库。依据 Oracle 数据库或者 Windows 上 Oracle 客户的默认安装，SQL*Plus 可用

作 Windows Start 菜单上的快捷方式。通过该快捷方式启动的可执行文件的位置通常如下所示：

D:\app\oracle\product\12.1.0\dbhome_1\BIN\sqlplus.exe

然而，确切路径应该是安装时指定的。图 1-10 显示使用 SQL*Plus 登录数据库的情况，

SQL*Plus 是通过快捷方式启动的。第一行文本显示 SQL*Plus 的版本(这里是 12.1.0.0.2 版本)和启动程序的时间。第三行文本是登录提示：

Enter user-name:

之后是手动输入的登录字符串，如下所示：

system/admin123@coda

有人喜欢变更启动 SQL*Plus 的快捷方式，以阻止它立即显示登录提示。为此，可以在命

令的结尾添加 NOLOG 转换：

sqlplus /nolog


22

图 1-10 使用 SQL*Plus 在 Windows 上登录数据库

也可以从操作系统提示符而不是从 Start 菜单快捷方式来启动 SQL*Plus：打开命令行窗口，

运行 sqlplus。程序会立即提示登录，除非使用上面介绍的 NOLOG 转换调用它。前面介绍过对于 Linux 安装而言，测试环境和设置变量(如果变量不正确)是很必要的，但

在 Windows 上安装通常不需要。这是因为，在安装软件时，已经由 Oracle Universal Installer在 Windows Registry 中设置了这些变量。如果没有成功启动 SQL*Plus，请检查 Registry 变量。

图 1-11 显示了 Registry 的相关部分(使用 Windows regedit.exe Registry Editor 实用程序进行查

看)。在 Registry Editor 内，导航到键：

HKEY_LOCAL_MACHINE SOFTWARE ORACLE KEY_OraDb12c_home1

图 1-11 Oracle Registry 变量


23

如果在机器上安装了几个 12c，那么导航路径的最后一个元素的名称就不同。请注意 Registry 变量 ORACLE_HOME 和 ORACLE_HOME_NAME 的值。它们与可执行文

件 sqlplus.exe 的位置以及到达启动它的快捷方式的 Start 菜单导航路径相关。

3. 创建和测试数据库连接

SQL*Plus 无法保存数据库连接细节。每次用户要连接数据库时，必须告诉 SQL*Plus 用户

是谁、数据库在哪里。虽然登录数据库的方式会由于站点特定的安全工具的不同而不同，但最

常见的方式是提供用户名和区分大小写的密码。可以提供两种常用形式的连接标识符来标识数

据库：提供解析到完整连接细节的别名或者输入完整细节。以下用这两种方法对应的命令分别从操作系统提示符启动 SQL*Plus 并连接数据库，该数

据库用户是 SCOTT，其密码是 tiger：

sqlplus scott/tiger@orcl sqlplus scott/[email protected]:1521/orcl.oracle.com

第一个示例使用别名 orcl 来标识数据库，它必须被解析为完整连接细节。有许多方法可以

完成这种解析，但无论采用哪种方法都必须完成。通常的方法是使用本地保存的文本文件(名为 tnsnames.ora 文件，该文件通常包含在 ORACLE_HOME 的 network/admin 子目录中)，或者

使用LDAP目录，例如Microsoft的Active Directory或者Oracle的Oracle Internet Directory(OID)。第二个示例提供所有连接细节。所需的连接细节包括运行数据库实例的计算机的主机名；

可以连接 Oracle Net 数据库侦听器的 TCP 端口；用户希望数据库侦听器连接的数据库服务。在

第一种方法中，用户只需要输入别名，这种方法要求数据库管理人员配置名称解析机制；第二

种方法只有在用户自己知道细节的情况下才能使用。有许多情况会导致 SQL*Plus 连接失败。图 1-12 显示了一些最常见的问题。

图 1-12 一些常见的登录问题


24

首先，用户从 Windows 操作系统提示符启动 SQL*Plus，使用 NOLOG 转换来阻止立即出

现登录提示符。到目前为止没有问题。接着，从 SQL>提示符中，用户发出连接请求，但请求失败，并产生了一个众所周知的

错误：

ORA-12154: TNS: could not resolve the connect identifier specified

产生这种错误是因为 Oracle Net 的 TNS(Transparent Network Substrate，透明网络底层)无法

将给定的连接标识符 wrongalias 解析到数据库连接细节。使用哪种名称解析方法以及如何配置

是数据库管理员需要考虑的事情。在这里，错误非常明显：用户输入了错误的连接标识符。第二个连接尝试给出正确的标识符 orcl。其错误为：

ORA-12541: TNS:no listener

这表示连接标识符已经正确解析到数据库侦听器的地址，但侦听器实际上没有运行。注意，

另一种可能是，地址解析不正确，它将 SQL*Plus 发送到错误的地址。对于这种错误信息，用

户应该联系数据库管理员，请求他启动侦听器。然后再试一次。第三个连接请求失败，错误为：

ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

这种错误由数据库侦听器生成。SQL*Plus 发现侦听器没有问题，但侦听器无法向前连接

到数据库服务。最有可能的原因是，数据库实例没有启动，因此用户应该请求数据库管理员启

动它，然后重试。第四个连接请求失败，错误为：

ORA-01017: invalid username/password; logon denied

要接收此消息，用户必须已经连接数据库。用户已经解决所有可能的网络问题，数据库实

例正在运行，数据库本身已经由实例打开。但是用户的密码或者用户名错误。注意，该消息没

有说明是密码错误还是用户名错误。如果要说明哪一个是错误的，给出的信息应该说明另一个

是正确的。最后，第五个连接尝试成功了。

注意：前面的示例演示了经常使用的解决问题的方法。如果连接失败，请逐步解决。

请认真阅读每一条错误消息。

1.4.2 SQL Developer

SQL Developer 是连接 Oracle 数据库(实际上也可以是某些非 Oracle 数据库)和发布即席

SQL 命令的工具。它也可以管理 PL/SQL 对象。与 SQL*Plus 不一样，它是一个图形工具，并

且有常见动作的导航键。SQL Developer 是用 Java 编写的，需要 Java 运行时环境(Java Runtime Environment，JRE)来运行。


25

因为是用 Java 语言编写的，所以 SQL Developer 可以在支持 JRE 相应版本的所有平台上运

行。在这些平台之间运行没有太大区别。

1. 安装和启动 SQL Developer

不能使用 Oracle Universal Installer 来安装 SQL Developer，虽然它可用来安装其他所有

Oracle 产品。SQL Developer 不在 Oracle Home 中，它是一个完全独立的产品。它的最新版本

可以从 Oracle Corporation 的网站下载。

注意： 12c 数据库的安装文件会包含 SQL Developer 的副本，但它不是当前版本。即

使碰巧安装了数据库，通常还要安装 SQL Developer 的当前版本。

要安装 SQL Developer，先解压缩 ZIP 文件。一切就绪。这要求 JDK，Java 运行时环境(Java Runtime Environment，JRE)可用，它来自 Oracle。但是如果在所用的机器上没有相应的 JDK 可

用，那么就可下载与该 Windows 相应的 SQL Developer 版本。对于除 Windows 之外的平台而

言，必须预安装 JDK。可以从 Oracle 的网站上下载它，并依据平台专用的指令安装。要检查

JDK 的版本是否正确，可以从操作系统提示符运行下面的命令：

java –version

这会返回如下结果：

java version "1.7.0_21" Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

如果没有返回该结果，那么使用 which java 可能有助于确定问题：搜索路径可以定位不正

确的版本。解压缩 SQL Developer 之后，将当前目录更改为解压缩 SQL Developer 的目录，然后启动

它。在 Windows 上，可执行文件是 sqldeveloper.exe。在 Linux 上，它是 sqldeveloper.sh shell脚本。在运行 shell 脚本之前，记得要检查 DISPLAY 环境变量是否已经设置为合适的值(例如

127.0.0.1:0.0，如果在系统控制台上运行 SQL Developer 的话)。与安装 JRE 和启动 SQL Developer 有关的所有问题都可以咨询系统管理员。

2. SQL Developer 用户界面

图 1-13 显示连接到数据库之后的 SQL Developer 用户界面。 SQL Developer 窗口的一般布局是，左边窗格显示导航对象，右边窗格用于显示和输入

信息。在图 1-13 中，左边窗格显示已经连接到数据库，该连接称为 orcl_sys。这个名称只是定义

连接时选择的一个标签，但大多数开发人员会使用某种类型的命名约定——这里，选择的名称

是数据库标识符(即 orcl)和产生连接的用户名(即 sys)。下面的分支列出了所有可能被托管的对

象类型。展开分支会列出对象本身。右边的窗格上面部分提示用户输入 SQL 语句，下面部分

显示该语句的结果。窗格以及上面可见标签的布局都可以自定义。


26

图 1-13 SQL Developer 用户界面

可以通过顶部菜单栏中的菜单按钮访问标准工具： ● File——常规的类似于 Windows 的文件菜单，可以保存工作和退出工具。 ● Edit——常规的类似于 Windows 的编辑菜单，能够实现撤消、重做、复制、粘贴、查

找等功能。 ● View——用于自定义 SQL Developer 用户界面的选项。 ● Navigate——在窗格之间移动以及移动被编辑的代码的工具。 ● Run——执行并调试 SQL 语句、SQL 脚本或者正在运行的 PL/SQL 代码块。对代码逐

行进行调试而不是运行整个代码块。 ● Versioning——支持代码版本控制库(code versioning repository)的创建，跟踪 SQL 程序

的不同版本。 ● Tools——链接到外部程序，包括 Data Modeler 和 SQL Worksheet。 ● Help——这个帮助文档十分有用。 SQL Developer 是一种非常有用的工具，它也可以自定义用户界面。为了试验它，请先阅

读帮助文档(Help)，用最适合你的方法建立用户界面。

3. 创建数据库连接

SQL Developer 可以创建和保存数据库连接以便重用。图 1-14 显示定义连接的窗口。为了

显现这个窗口，请单击前面图 1-13 中所示的 Connections 标签上的“+”符号。连接的名称是随意的。在本示例中，选择的名称是数据库连接标识符的名称(orcl)，后缀是

要嵌入到连接中的用户名(hr)。必须同时提供用户名和密码，但只保存用户名，除非选中 Save Password 复选框。保存密

码意味着不需要任何密码提示就能够实现以后的连接。这很方便，但如果使用的计算机不安全，

这样做就很危险。实际上，可以将连接认证委托给本地操作系统：如果能够登录它，那么就能


27

够登录数据库。

图 1-14 如何定义新的数据库连接

假设你正在使用 SQL Developer 连接到 Oracle 数据库而不是第三方数据库，选择 Oracle标签。

Role 下拉框会提供作为 sysdba 连接的选项。在执行特别重要的操作(例如数据库启动和关

闭)之前需要 sysdba 连接。本书中的练习不需要它。 Connection Type 单选按钮允许你在下面 5 个选项之间进行选择： ● Basic——它提示数据库服务器的名称，数据库侦听器接受连接请求的端口，以及连接

的实例(SID)或者服务。 ● TNS——如果已经配置了名称解析方法，那么可以从本地 tnsnames.ora 文件中选择数据

库的别名或者输入它，而不是 Basic 选项需要的完整细节。 ● LDAP——通过指定 LDAP Server 细节，可以查询存储在 LDAP 目录服务中的数据库服

务定义及其连接细节。 ● Advanced——它允许输入任何完整的 JDBC (Java Database Connectivity，Java 数据库连

接)连接字符串。它完全不依赖 Oracle，并可以用来连接任何符合 JDBC 标准的数据库。 ● Local/Bequeath——如果数据库与你的 SQL Developer 客户端正运行在同一台机器上，

该选项允许你绕过网络侦听器而直接连接到服务器进程。选择 Basic 要求用户知道如何连接到数据库；选择 TNS 要求数据库管理员在客户机上完成

某种配置，以便可以将别名解析到完整的连接细节。输入细节之后，Test 按钮会要求 SQL Developer 尝试登录。如果返回错误，要么就是连接

细节错误，要么就是服务器端有问题。典型的服务器端问题是数据库侦听器没有运行，或者数

据库没有启动。不管是什么错误，前面都有一个错误编号——一些常见的错误已在 1.4.1 节中

描述过。


28

案例&解决方案如果连接失败该怎么办？

如何解决这个问题

如果连接尝试失败，应该有一些错误消息。查看一下这些错误消息！如果不能

立即明白，可以查找 Oracle 文档或者 My Oracle Support。尽量遵循连接流程：

从用户进程到数据库侦听器到实例再到数据库，检查所有步骤

如果自己不能解决这个问

题，应该到哪里寻求帮助

文档和 My Oracle Support 会提供很多帮助。大多数支持小组会拒绝和你沟通，

除非你自己已经尽了力解决这个问题。然后你可以将该问题告诉网络管理员、

系统管理员和数据库管理员

1.5 创建演示模式

整本书中有几百个依据数据表运行 SQL 代码的示例。其中很大一部分示例以 Oracle 提供

的两种演示模式——HR 模式和 OE 模式——来使用表。HR 模式是模仿简单人力资源应用程序

的样本数据；OE 模式则模仿更复杂的订单录入应用程序。当创建数据库时可以创建这些模式，数据库配置帮助(Database Configuration Assistant，

DBCA)提供了这些选项。如果它们不存在，稍后可以通过运行数据库 Oracle Home 中的某些

脚本来创建它们。

注意：更早的演示模式是 SCOTT(密码为 tiger)。这种模式比 HR 和 OE 更简单。许多

长期使用 Oracle 的人都喜欢使用这种模式。这种模式还提供了创建脚本，即

utlsampl.sql。

1.5.1 用户和模式

首先，解释两个定义。在 Oracle 用语中，数据库用户(user)是能够登录数据库的人。数据

库模式(schema)是在数据库中一个用户拥有的全部对象。这两个术语通常可以交换使用，因为

用户和模式之间是一对一的关系。注意，虽然实际上有 CREATE SCHEMA 命令，但它其实不

创建模式——它只是一种利用模式创建对象的快速方法。当使用 CREATE USER 命令创建用户

时，最初创建的模式是空的。模式用于存储对象，这些对象可能是数据对象(例如表)或程序化对象(例如 PL/SQL 存储过

程)。用户通过登录来连接数据库和访问这些对象。在默认情况下，用户能够访问自己模式中

的对象，不能访问其他对象，但大多数应用程序改变了这一点。一般来说，一种模式可用来保

存数据，允许使用模式中的对象的其他用户访问这些数据，即使这些用户不拥有它们。实际上，

很少有用户会有自己模式中的对象或者有创建它们的权限：他们只有权限(严格控制的权利)访问其他模式中的对象。运行应用程序(模式保存这些应用程序的数据)的所有用户都能够使用这

些对象。相反，拥有数据保存模式的用户实际上可能从未登录：其模式的唯一目的就是包含其

他人使用的数据。数据对象不可能独立于模式而存在。换句话说，所有表都必须有所有者。所有者就是用户，

表驻留在该用户的模式中。表(或者其他模式对象)的唯一标识符是用户名加对象名称。具有相


29

同名称的两个表不可能在同一个模式中，但具有相同名称(虽然结构或者内容可能不同)的两个

表可以在不同模式中。如果对象不在自己的模式中，要访问它，就必须用它驻留的模式的名

称来限定它的名称。例如，HR.EMPLOYEES 是用户 HR 模式中名为 EMPLOYEES 的表。除

非可以使用同义词，否则在没有模式名称限定符的情况下，只有作为 HR 连接的用户才能通

过引用 EMPLOYEES 来访问表。同义词是一种结构，通过这种结构可以使其他用户访问对

象，而不必将对象的模式名称作为前缀。

1.5.2 HR 和 OE 模式

HR 演示模式由几个表组成，这些表由主键到外键的关系链接在一起。图 1-15 显示的是这

些表之间的关系，即实体关系图。

图 1-15 HR 实体关系图

图 1-15 中显示的两种关系可能不是很好理解。首先，EMPLOYEES 到 EMPLOYEES 存在

多对一(many-to-one)的关系。这就是所谓的自引用外键(self-referencing foreign key)。这意味着

多名员工可能连接到一名员工，因为多名员工可能有一名经理，但经理也是一名员工。这种关

系由列 manager_id 实现(它是相对于 employee_id 的外键)，而 employee_id 是表的主键。需要解释的第二种关系是 DEPARTMENTS 和 EMPLOYEES 之间的关系，它是双向的。一

个部门对多名员工的关系说明在一个部门中可能有许多员工，EMPLOYEES 的 dept_id 列是相

对于 DEPARTMENTS 的主键 dept_id 列的外键。一名员工对多个部门的关系表示一名员工可能

是几个部门的经理，由 DEPARTMENTS 中的 manager_id 列实现，它是相对于 EMPLOYEES中的主键 employee_id 列的外键。

表 1-6 显示 HR 模式中各表的列，使用与前文一致的符号来表示主键(#)、外键(\)以及列是

可选的(o)还是强制的(*)。


30

表 1-6 HR 模式中的表和列表列

REGIONS #* region_id

o region_name

COUNTRIES #* country_id

o country_name

\o region_id

LOCATIONS #* location_id

o street_address

o postal_code

* city

o state_province

\o country_id

DEPARTMENTS #* department_id

* department_name

\o manager_id

\o location_id

EMPLOYEES #* employee_id

o first_name

* last_name

* e-mail

o phone_number

* hire_date

\* job_id

o salary

o commission_pct

\o manager_id

\o department_id

JOBS #* job_id

* job_title

o min_salary

o max_salary

JOB_HISTORY #* employee_id

#* start_date

* end_date

\* job_id

\o department_id


31

这些表是： ● REGIONS——包含表示主要地区的行。 ● COUNTRIES——包含表示每个国家的行，一个国家被分配给一个地区(可选)。 ● LOCATIONS——包含地址，一个地址被分配给一个国家(可选)。 ● DEPARTMENTS——包含表示各部门的行，一个部门被分配给一个地址和一位经理(可

选)，经理必须作为员工存在。 ● EMPLOYEES——包含表示各员工的行，必须为每个员工分配一项工作，并且将他分

配给一个部门和一位经理(可选)，经理本身必须是员工。 ● JOBS——列出组织中所有可能的工作。多名员工可能有相同的工作。 ● JOB_HISTORY——列出员工以前从事的工作，由 employee_id 和 start_date 唯一标识。

一名员工不可能同时从事两份工作。每个工作历史记录都表示一名员工，当时他只有

一份工作，是一个部门中的成员。该 HR 模式适用于本书各章中的大多数练习和一些示例。

注意： EMPLOYEES 中有些行在 DEPARTMENTS 中没有匹配的父行。这可能是故意

的，但也可能是设计错误，因为 EMPLOYEES 中的 DEPARTMENT_ID 列可能

不是强制的。在 REGIONS—COUNTRIES— LOCATIONS 层次结构中也可能有

类似错误，但实际上没有太大影响。

OE 模式比 HR 模式要复杂得多。表结构也更加复杂：它们包含定义为嵌套表的列、用户

定义的数据类型和 XML 数据类型。在各章结尾处有许多可选做的练习，这些练习通常使用 OE模式。当遇到它们时再讨论所涉及的对象。

1.5.3 创建演示模式

如果正在使用的数据库专门用于研究 SQL 考试，那么就应该已经创建了演示模式。是否

创建演示模式是由 Database Configuration Assistant 在创建数据库时提供的一个选项。创建数据

库之后，必须解锁模式，设置密码。在默认情况下，账户是锁定的，这就意味着不能登录。可

以用 SQL*Plus 或者 SQL Developer 发布的命令，通过密码 hr 和 oe 以用户 HR 和 OE 的身份登

录，如下所示：

alter user hr account unlock identified by hr; alter user oe account unlock identified by oe;

当作为具有 DBA 特权的用户(例如，用户 SYSTEM)连接到数据库时才能发布这些 alter user命令。

如果在创建数据库时没有创建模式，那么通过运行安装在数据库 Oracle Home 中的脚本就

可以创建它们。必须由作为具有 SYSDBA 特权的用户从 SQL*Plus 或者 SQL Developer 运行这

些脚本。在运行时，脚本会提示需要某些值。例如，在 Linux 系统上，先从操作系统提示符启

动 SQL*Plus：

sqlplus / as sysdba


32

这种连接有许多可选参数，但如果数据库在运行 SQL*Plus 的机器上运行，上面的语句通

常就会运行。然后从 SQL>提示符调用脚本：

SQL> @?/demo/schema/human_resources/hr_main.sql

“?”字符是一个变量，SQL*Plus 会将该变量的内容扩展到 Oracle Home 目录所在的路径。

脚本会提示需要输入 HR 密码、默认表空间、临时表空间、SYS 密码和脚本运行日志文件的目

的地。默认表空间和临时表空间的典型值是 USERS 和 TEMP，但必须已经设置了这些值。完

成这些之后，就可以作为新的 HR 用户连接到数据库。要验证这一点，请运行下面的语句：

SQL> show user;

你会发现当前用户作为 HR 已连接到数据库。然后运行：

SQL> select table_name from user_tables;

将看到 HR 模式中 7 个表的列表。要创建 OE 模式，与以上步骤相同，运行如下脚本：

?/demo/schema/order_entry/oe_main.sql

在 Windows 上创建模式的过程也是类似的，除了路径分隔符不同之外——大多数操作系统

使用正斜杠，但 Windows 使用反斜杠。因此，在 Windows 上创建 HR 模式的脚本的路径是：

@?\demo\schema\human_resources\hr_main.sql

注意，运行这些创建模式的脚本会删除已经存在的模式(如果它们存在)。删除模式意味着

删除它里面的所有项，然后删除用户。这并不是问题，除非模式已被用于某些需要继续保持的

开发工作。如果创建演示模式的脚本不存在，这可能是因为 Oracle Home 的安装没有完成。可以从安

装 Oracle 的 CD 重新安装 Oracle Home。应该还有一个备用 CD(称为配套或示例 CD)，它包含

许多从严格意思上来讲是可以选择安装的组件，其中就有包含演示模式的组件。通常应该安装

配套 CD。如果没有这样做，必须告诉数据库管理员。

注意：在产品数据库中不应该存在演示模式。出于安全的原因，在数据库中包含

不必要的模式并不合适，因为这些模式通常有众所周知的用户名和功能，甚至

还可能有密码。

1.6 认证小结

SQL 是一种语言，用来管理对存储在关系数据库中规范化数据的访问。它不是一种应用程

序开发语言，但当开发语言需要访问数据时，会调用 SQL 语言。Oracle 服务器技术提供了开

发和部署应用程序的平台。Oracle 服务器技术和 SQL 的结合产生了一种符合关系数据库范例

的环境，它是一种用于云计算的可行方法。有许多客户工具可以用来连接 Oracle 数据库。Oracle Corporation 提供的两种工具是


33

SQL*Plus 和 SQL Developer：SQL*Plus 作为每个 Oracle 客户和 Oracle 数据库的一部分被安装，

但 SQL Developer 可以单独被安装。这两种工具都可以用于准备 OCP 考试，学生们应该熟悉

它们。演示模式保存示例数据，这些数据用来说明 SQL 以及更高级的 Oracle 开发工具的用法。

1.7 本章知识点回顾

定位服务器技术 ● Oracle 数据库保存数据并管理对用户数据的访问。 ● Oracle WebLogic Server 运行将用户连接到数据库的应用程序。 ● Oracle Enterprise Manager 是一种工具，用于管理数据库、应用服务器和整个计算环境

(如有必要)。 ● 内置于数据库中用于应用程序开发的语言是 SQL、PL/SQL 和 Java。

理解关系结构 ● 必须将数据规范化到二维表中。 ● 通过主键和外键链接表。 ● 实体-关系图用图形来表示表。

SQL 语言概述 ● DML 命令包括 SELECT、INSERT、UPDATE、DELETE 和 MERGE。 ● DDL 命令包括 CREATE、ALTER、DROP、RENAME、TRUNCATE 和 COMMENT。 ● DCL 命令包括 GRANT 和 REVOKE。 ● TCL 命令包括 COMMIT、ROLLBACK 和 SAVEPOINT。

使用客户工具 ● SQL*Plus 是安装到 Oracle Home 中的命令行实用程序。 ● SQL Developer 是安装到自身目录中的图形工具。 ● 这两种工具都需要数据库连接，由用户名、密码和连接标识符组成。

创建演示模式 ● 演示模式由 Oracle 提供以方便学习，但必须在使用之前创建它们。

1.8 本章测试题

1.8.1 自测题

定位服务器技术 1. Oracle Enterprise Manager Cloud Control 可以管理 IT 环境中的哪些组件(选择最佳答案)？

A. Oracle 数据库 B. Oracle 应用服务器


34

C. 第三方产品 D. 服务器 E. 以上所有

2. 什么语言能够在数据库内运行(选择所有正确答案)？ A. SQL B. C C. PL/SQL D. Java E. 链接到 OCI 库的任何其他语言

理解关系结构 3. 适合在关系数据库中处理的数据的范式是(选择最佳答案)：

A. 第一范式 B. 第三范式 C. 反常范式(abnormal form) D. 超常范式(paranormal form)

4. 实体-关系图显示在( )中建模的数据(选择最佳答案)： A. 二维表 B. 多维表 C. 层次结构 D. 面向对象结构

SQL 语言概述 5. SQL 是面向集合的语言。它具有下列哪种特性(选择最佳答案)？

A. 单行必须有唯一标识符 B. 能够分组管理用户集合 C. SQL 语句可以放置在用其他语言编写的代码块内，例如 Java 和 PL/SQL D. 一条语句可以影响多行

6. 下列哪些结构不是 SQL 语言的一部分(选择所有正确答案)？ A. 迭代，基于 WHILE.. B. 迭代，基于 FOR..DO C. 分支，基于 IF..THEN..ELSE D. 事务控制，基于 COMMIT E. 事务控制，基于 ROLLBACK

使用客户工具 7. 下列关于 SQL Developer 的陈述哪些是正确的(选择两个答案)？

A. SQL Developer 不能连接到 10g 版本之前的数据库 B. 可以在 Oracle Home 之外安装 SQL Developer C. SQL Developer 可以保存密码 D. SQL Developer 依赖用于名称解析的 LDAP 目录


35

8. 下列哪些是使用 SQL Developer 的必要条件(选择两个正确答案)？ A. Java 运行时环境 B. OCI 库 C. 名称解析方法(例如 LDAP)或者 TNSNAMES.ORA 文件 D. SQL*Plus 库 E. 图形终端

创建演示模式 9. 可以在哪里创建演示模式(选择最佳答案)？

A. 必须在演示数据库中创建演示模式 B. 不能在产品数据库中创建演示模式 C. 可以在任何数据库中创建演示模式 D. 如果创建了演示用户，那么就可以在任何数据库中创建演示模式

10. 如何将模式从一个用户移动到另一个用户(选择最佳答案)？ A. 使用 ALTER SCHEMA MOVE…命令 B. 不能将模式从一个用户移动到另一个用户 C. 如果模式是空的(或者如果它里面的所有对象已经被删除) 才能移动 D. 将新用户添加到模式，然后从模式中分离老用户

1.8.2 实验题

OE 模式包含下面这些表： ● CUSTOMERS ● INVENTORIES ● ORDERS ● ORDER_ITEMS ● PRODUCT_DESCRIPTIONS ● PRODUCT_INFORMATION ● WAREHOUSES 一个顾客可以有许多订单，一个订单可以有许多订购项。每一项都是一种产品，由

PRODUCT_INFORMATION 描述，每种产品都有几个 PRODUCT_DESCRIPTIONS(使用不同的

语言)。有许多仓库，每个仓库都可以保存许多产品；一种产品可以保存在许多仓库内。

INVENTORIES 条目将产品与仓库联系起来，显示每个仓库中每种产品有多少。用实体-关系图描述这种模式，显示表之间的多对一(many-to-one)连接，确保没有多对多

(many-to-many)连接。

1.8.3 自测题答案

定位服务器技术 1. E 正确。Cloud Control 可以管理整个环境(依据 Oracle Corporation)。 A、B、C、D 错误，所有这些都可以由 Cloud Control 管理。 2. A、C、D 正确。SQL、PL/SQL 和 Java 都可以在数据库中运行。


36

B、E 错误。C 不能在数据库之内运行；外部进程用 OCI 来连接数据库，在数据库里面 OCI不会运行。

理解关系结构 3. B正确。当系统分析员将数据规范化到关系结构中时，他们会使用第三范式作为一般

范式。 A、C、D 错误。A 错误，因为第一范式只是数据规范化的第一阶段。C 和 D 可能更适合

X-Files 而不是数据库。 4. A 正确。关系模型使用二维表。 B、C、D 错误。B 错误，因为二维是对关系结构的限制。C 和 D 错误，因为它们表示非

关系结构(尽管 Oracle 数据库中有工具可以模拟它们)。

SQL 语言概述 5. D正确。在面向集合语言中，一条命令可以影响许多行(集合)，而过程语言只能逐行

处理。 A、B、C 错误。A 错误，因为虽然在设计良好的应用程序中行有唯一标识符，但实际上

这不是必要条件。B 错误，因为在 Oracle 环境中不能将用户分组。C 错误，因为(尽管语句正

确)它与问题无关。 6. A、B、C正确。这些都是程序结构，而不是面向集合语言的一部分。它们用在PL/SQL中。 D、E 错误。这些是 SQL 的事务控制语句。

使用客户工具 7. B、C 正确。B 正确，因为可以在 SQL Developer 自己的目录里安装它。C 正确，因为

密码可以保存为连接定义的一部分(尽管这可能不是一个好主意)。 A、D 错误。A 错误，因为 Oracle Net 协议可以让 SQL Developer 连接到数据库的多个版

本。D 错误，因为 LDAP 只是命名解析的几种方法之一。 8. A、E 正确。A 正确，因为 SQL Developer 是用 Java 语言编写的，因此需要 Java 运行时

环境(Java Runtime Environment，JRE)。E 正确，因为 SQL Developer 需要图形终端来显示窗口。 B、C、D 错误。B 错误，因为 SQL Developer 使用 JDBC 来连接数据库，而不是 OCI。C

错误，因为虽然 SQL Developer 能够使用 LDAP 或者 TNSNAMES.ORA 文件，但它也能够使用

并保存基本连接细节。D 错误，因为 SQL Developer 是一个完全独立的产品。

创建演示模式 9. C 正确。可以在任何数据库中创建演示模式，要么在创建数据库时，要么在之后运行

脚本。 A、B、D 错误。A 和 B 错误，因为虽然它们可能是好的实践，但它们不是技术要求。D

错误，因为它不知道只能使用用户创建模式。 10. B 正确。模式和用户不可分离。 A、C、D 错误。A 错误，因为没有这种命令。C 和 D 错误，因为它们假设了这种不可能

性：可以将用户与模式分开。


37

1.8.4 实验题答案

图 1-16 显示了解决方案。

图 1-16 描述 OE 模式的实体-关系图

第1章使用Oracle设计关系数据库

Documents

Transcript of 第1章使用Oracle设计关系数据库

第1章 使用Oracle设计关系数据库

Documents

Transcript of 第1章 使用Oracle设计关系数据库

第1章使用Oracle设计关系数据库

Transcript of 第1章使用Oracle设计关系数据库