SQL关系数据库设计理论中提到的超健和候选键的概念怎么理解，很抽象。

超键就是指一组字段可以唯一确定一条数据，而候选键是最简洁的超键，也就是只有必要字段，

举例来说明，假如有一个班级，班级中没有同名的学生，有如下一张表。

std_idlast_namefirst_namegenderscore

10001张三男85

10002李四男86

10005妹子女95

10006李三男88

这张表里，因为我们前面说到这个班级里没有同名的学生。

因此last_name+first_name就是一个超键，因为可以唯一确定一行数据，同时也是一个候选键，因为这两个字段去掉任何一个都不再能唯一确定一行数据。

更明显的区别在于，last_name+first_name+gender还是一个超键，但是已经不再是候选键了，因为在确定唯一一条数据的时候，gender不是必要的字段。

也就是说候选键是可以唯一确定一条数据的必要字段的最小集合，而候选键加上任何的额外字段都是超键。

在上面的例子中，std_id自己就是一个候选键，std_id+任何额外的字段都是候选键。

同时从习惯而言，一般会把这种std_id字段定义为主键，主键并不一定只是一个字段，如果我们上面的表增加一列班级id(class_id)，同时加入每个班级中的std_id都是从10001开始的话，我们就可以用class_id+std_id来作为主键。

自己的理解，希望可以帮到题主。

前言

信息泛滥并没有减弱的趋势 人们被来自电视 Internet和塞满邮箱的广告等各种各样的信息所淹没 令人遗憾的是 随着信息数量的增长 信息的质量却在急剧下降 图书被期刊和杂志取代 然后被报纸 Web页面 博客取代 最终又被推特（eet）取代 信息量变得越来越庞大 也变得越来越不可信赖 更糟糕的是 在Internet时代数据永远不会真正消失 它不停地累积 隐藏在各种文件 日志和数据库中 根据Google的前CEO Eric Schmidt的说法 现在人类在两天之内创造的数据量就相当于自从出现书写记录到 年（或者任何一年）所创造的数据 即现在只需要两天就会创造出大约 EB（即 亿GB）的数据 这一步伐还在不停地加速

当以电子化方式存储数据变成现实之后 它也带来了自己的规则 要理解数据的含义 人们必须去学习相应的语言 关系数据库理论为人们带来了对电子化数据的掌控能力 它采用结构化查询语言（Structured Query Language SQL）来处理数据 到目前为止 关系数据库获取了巨大的成功

自从 世纪 年代第一次提出关系数据库以来 关系数据库和SQL已经取得了长足的进步 关系数据库和SQL中包含的那些概念对于初学者来说可能并不直观 本书将为读者抽丝剥茧 使读者理解SQL背后的原理 既让读者了解SQL的强大功能 也了解它存在的局限

读者对象

本书从入门知识开始介绍 读者无须具备SQL或关系数据库的预备知识 本书将带领读者走入SQL的发现之旅 读者将亲自创建示例数据库 它不仅结合了本书中所介绍的SQL概念 还将通过几次反复重构引入数据建模 查询调整和优化的概念 本书还介绍了一些适用于每一种SQL的最佳实践

本书适合于准备学习关系数据库程序设计的计算机程序员 也适合那些希望从数据库中释放更强大威力的商业用户 SQL是关系数据库世界的通用语言 每一个对学习SQL这门强大语言感兴趣的人都适合阅读本书

先前已具有一定数据库使用经验的读者可以略过前两章 直接跳到更高级的内容 当然也可以复习一下这两章中介绍的重要原则

　 　内容提要

本书介绍了当前已发布的SQL标准SQL: 把最主要的精力放在了SQL语言实际的运用上 强调了不同SQL实现之间存在的差异 本书介绍了很多示例 在这些示例中使用了最新版本的现代数据库系统对SQL的具体实现 这些数据库要么是可以免费下载的Express版本 要么是免费的开源软件 另外 本书还介绍了目前最流行的桌面型数据库软件Microsoft Access和OpenOffice 本书中介绍的数据库包括

IBM UDB

Oracle g

Microsoft SQL Server / /

MySQL /

PostgreSQL

Microsoft Access /

带有嵌入式 HSQLDB的OpenOffice BASE

本书结构

本书从整体着眼 向读者介绍了关系数据库的一般概念 特别是SQL中的概念 通过一个反复重构数据库的过程 循序渐进地向读者介绍了数据库的各种知识 在这一过程中 对于开始时介绍的每一个概念 随后都进行了更详细的分析 从而启发读者理解这些概念背后的关联性

第 章简要地介绍了SQL及其背后的关系理论 这一章只是浮光掠影般地介绍了数据库最基本的概念 后面的各章都在此基础上展开 该章介绍了数据与信息的区别 一些基本的原理还需要在后面章节中进一步解释 这一章还对本书中所使用的关系数据库管理系统（RDBMS）进行了一个概述

第 章对这些概念进行了更深入的介绍 根据关系模型的分析 应该将无组织的数据结构化 使之符合关系模型的要求 即将 冰箱磁铁 模式转换为 斗柜 模式 然后再将其转换为关系数据库中实际的表

第 章进一步介绍了关系模型 初步介绍了数据库的基本设计和规范化的基本过程 这一章还介绍了一些对规范化数据执行查询的SQL工具 此外 该章还介绍了动态SQL

SQL是一种基于集合的语言 这使得它既有强大的功能 也存在一定的局限 第 章讨论了最流行的过程化扩展（例如Oracle的PL/SQL和Microsoft的Transact SQL） 这一章还介绍了SQL函数 SQL函数可以作为一种补充手段 以弥补在处理基于记录的逻辑时SQL存在的固有不足

第 章介绍了聚合数据 总结了这种方式的威力和局限 该章将前面章节中介绍过的SQL聚合函数提高到了一个新的层次 演示了如何使用SQL来获取数据的聚合值

第 章介绍了子查询 当数据集是交错的 查询数据需要依靠多层次的数据筛选时 可以将一个查询作为另一个查询的筛选条件 可以调整SQL语句 用JOIN代替子查询 这是贯穿本书的主题之一

SQL的强大功能在于处理存储在多个关系表中的数据 第 章介绍了SQL如何在单个数据集中联合这些关系表的数据

本书介绍的是基本的SQL概念 打开了进一步学习SQL的大门 第 章是SQL发现之旅的下一站 它介绍了进一步学习SQL时应该考虑的问题

第 章介绍了性能优化技术 描述了在优化查询和数据库环境时常用的方法和最佳实践 第 章讨论了多用户环境中关系数据库的工作原理 介绍了SQL中实现的处理并发数据访问的机制

SQL所有的 *** 作都与结构和顺序有关 毕竟它是结构化查询语言 真实的数据可以是各种规模和结构 第 章介绍了SQL如何处理半结构化数据（XML文档） 非结构化数据（文本文件）和二进制数据（例如图片和声音）

第 章简要地讨论了数据库领域的最新发展 例如列式数据库 NoSQL数据库 对象数据库和面向服务的架构（SOA） 以及它们与SQL的关系

对于本书所讨论的每一种数据库 附录A按部就班地描述了安装示例数据库Library的过程 以及如何使用特定的指令生成Library数据库的初始数据 可以从本书支持网站上下载到这些SQL脚本

对于本书介绍的关系数据库软件包 附录B提供了一个详细的安装步骤

附录C描述了每一种数据库所提供的工具 使用这些工具可以访问 创建数据库对象 *** 纵存储在表中的数据

附录D介绍了开源项目SQuirreL Universal SQL Client 可以通过Java Database Connectivity（JDBC）接口 使用SQuirreL Universal SQL Client来访问各种数据库 该附录详细地介绍了如何安装和配置该软件

学习本书的条件

为了充分利用本书 建议下载和安装本书中使用的关系数据库软件 这些软件绝大多数都是免费的 或者具有免费的试用版 可以按照附录B中介绍的步骤来安装这些软件

支持网站和代码

在学习每一章时 建议下载相应的SQL脚本 创建并生成数据库 可以从 wrox 或者 agilitator 下载到本书的代码 在支持网站中 可以使用搜索框来查找指定名称的图书 在找到指定的图书之后 单击Download Code链接就可以访问允许下载的文件 可以通过HTTP或FTP下载这些代码 所有的文件都是以ZIP格式保存

本书的ISBN是 通过ISBN号查找本书 要比通过图书名称来查找更加方便

此外 还可以从Wrox的下载页面 wrox /dynamic/books/download aspx下载到本书的代码 只要单击Discovering SQL: A Hands On Guide for Beginners链接 就可以访问允许下载的文件

勘误表

尽管我们已经尽了最大的努力来保证文章或代码中不出现错误 但是错误总是难免的 如果您在本书中找到了错误 例如拼写错误或代码错误 请告诉我们 我们将非常感激 通过勘误表 可以让其他读者避免走入误区 当然 这还有助于提供更高质量的信息

要在网站上找到本书英文版的勘误表 可以登录// wrox 通过Search工具或书名列表查找本书 然后在本书的细目页面上 单击Book Errata链接 在这个页面上可以查看到Wrox编辑已提交和粘贴的所有勘误项 完整的图书列表还包括每本书的勘误表 网址是 wrox /misc pages/booklist s

如果你在勘误表上没有找到错误 那么可以到 wrox /contact/techsupport s上完成上面的表格 并把找到的错误发送给我们 我们将会核查这些信息 如果无误的话 会把它放置到本书的勘误表中 并在本书的后续版本中更正这些问题

p p wrox

要与作者和同行讨论 请加入p p wrox 上的P P论坛 这个论坛是一个基于Web的系统 便于您张贴与Wrox图书相关的消息和相关技术 与其他读者和技术用户交流心得 该论坛提供了订阅功能 当论坛上有新的消息时 它可以给您传送感兴趣的论题 Wrox作者 编辑和其他业界专家和读者都会到这个论坛上来探讨问题

在//p p wrox 上 有许多不同的论坛 它们不仅有助于阅读本书 还有助于开发自己的应用程序 要加入论坛 可以遵循下面的步骤

（ ） 进入p p wrox 单击Register链接

（ ） 阅读使用协议 并单击Agree按钮

（ ） 填写加入该论坛所需要的信息和自己希望提供的其他信息 并单击Submit按钮

（ ） 你会收到一封电子邮件 其中的信息描述了如何验证账户和完成加入过程

不加入P P也可以阅读论坛上的消息 但要张贴自己的消息 就必须加入该论坛

加入论坛后 就可以张贴新消息 回复其他用户张贴的消息 可以随时在Web上阅读消息 如果要让该网站给自己发送特定论坛中的消息 可以单击论坛列表中该论坛名旁边的Subscribe to this Forum图标

关于使用Wrox P P的更多信息 可阅读P P FAQ 了解论坛软件的工作情况以及P P和Wrox图书的许多常见问题 要阅读FAQ 可以在任意P P页面上单击FAQ链接

       返回目录 SQL实战新手入门

       编辑推荐

       Oracle索引技术

       高性能MySQL

lishixinzhi/Article/program/SQL/201311/16496

作者 石默研

关于CAP的讨论已经很多，包括作者的另一篇文章“对CAP的初步解释”，基本已经即定思维的理解就是：分布式系统必须遵循CAP，一个分布式系统的设计只能同时满足其中两个，不可能同时满足；传统关系数据库选择A与C，代表了互联网新兴技术的NoSQL数据库则选择A与P（或者C与P，虽然这种情况其实需要详细讨论）。

但是，近年来，新兴的NewSQL数据库（TiDB或者OceanBase），则是一种在分布式环境下，保证的ACID强事务特征的强一致性数据库，并且很显然，它同时也满足了高可用性与优秀的分区可容忍性（很好的可扩展特性便是其一个层面的证明），似乎看起来，C、A、P都同时保证了，这不是违反了已经经过严格证明的CAP理论吗？

这个问题初看起来，似乎是比较神奇，但仔细分析，其实答案是很明显的。

首先，需要读者区分“分布式”与CAP中所提到的分区可容忍性Paritition Tolerance并不是一回事。分区可容忍性P是指以下两种分布式的情况：

. 同一份数据的多个副本的可分布性

. 有相互关联的数据的可分布性（ *** 作中表现为保证ACID的强分布式事务）

即使是分库分表，如果不存在以上两种情况，只是独立数据在同一个节点上的情况，虽然也是分布式，但跟CAP中的P没有半毛钱关系。

那么，还是回到上面的问题，NewSQL数据库，确实也是在保证了同一份数据多副本的强读写一致性、以及强分布式事务特性这样的C的情况下，同时保证了A与P呀！事实确实如此，但这还是要仔细分析：

无论是TiDB，还是OceanBase，其在保证数据多副本的强一致性时，都采用了Paxos协议或者Raft，它们简单来讲就是多数选举的原则，即写不需要全部副本都完成，就能保证读的强一致性，反过来也是一样。因此，其在分布式情况下，保证数据读写强一致性的效率还是很高的，就是说，在同一个数据中心的网络环境下，虽然这种分布可容忍性的满足理论上讲也会比单节点多一点点效率损失，但实际上是可以忽略不计的。但需要指出的是，在跨数据中心、跨城市的分布式情况下，如果要保证数据多副本的强一致性，即保证分区可容忍性，对效率（实际上是可用性A）的影响那还是不可忽略的。因此，在这种情况下，CAP理论依然成立。

再来看相互关联数据的可分布性，这就涉及到了分布式事务。现有的NewSQL数据库，即使在同一数据中心，为了保证强的分布式事务，对效率的折衷都是不可忽略的，所谓的乐观事务，只是因为客观问题本身冲突就少，并不改变冲突很多时效率明显受影响的现实。因此，NewSQL数据库虽然提供强分布式事务的能力，但在现实应用中，都是提倡尽量避免大量的分布式事务出现。如果你所遇到的应用场景是确实需要大量的分布式事务执行，又不做应用优化全交给数据库执行，那么，现有的NewSQL分布式数据库，依然会遇到明显的性能问题，其实就是可用性A降低了。同学仔细去研究应用中的实际情况就会发现，很多互联网应用，当其所需要的QPS很高很高，而对读写一致性与强分布式事务的要求又不那很高时候，其实，NewSQL数据库还是不能满足他们的需求的，他们仍然需要根据自己的情况改造或者选用NoSQL数据库，这也是CAP理论并没有被NewSQL打破的现实证明。

因此，总结来讲，NewSQL数据库，也是遵循CAP理论的，只不过，在同中心数据多副本情况下，保证P的同时对A的影响微乎其微；而在分布式事务的情况下，又采用了与应用特性相关的策略（其实乐观、悲观事务本质上就有根本应用特性区分的意思）来保证性能而已。当然，随着网络与计算机性能的提高，CAP三个特征中，保证其中两个，折衷另外一个，所带来的影响也会逐渐变小，但其理论依然是正确的。

---