SQL实战新手入门：关系型数据库管理系统

关系型数据库管理系统

本书是讲述SQL的 它是一种关系型数据库或者关系型数据库管理系统（RDBMS）的语言 自从Codd博士在 世纪 年代奠定关系型数据库的理论基础以来 已经产生了相当多的关系型数据库实现 一些新的关系型数据库实现也不断出现

很多人将DB 视为所有数据库的鼻祖 IBM的研究员Edgar Frank Codd博士在 年的一份IBM的研究报告中发表他的论文 Derivability Redundancy and Consistency of Relations Stored inLarge Data Banks 时 给这种数据库理论定义了一个非常恰当的术语 关系型 关系型数据库被其他两种技术竞争 一种是Honeywell Information Systems在 年销售的Multics RelationalData Store 另一种是密歇根大学从 年起作为实验性设计的Micro DBMS（它开创了Codd博士两年之后提出的规范化理论） Micro DBMS的最后一个产品已经于 年退役 这两种技术演变成了 年发布的Oracle V 商业数据库 在通往RDBMS的道路上 包含了很多其他公司的产品所树立的里程碑（当然偶尔也有墓碑） 这些产品包括 IBM PRTV（ ） IBM SQL/DS（ ） QBE（ ） Informix（ ） Sybase（ ） Teradata（ ） Ingres 一个给其他很多成功的系统带来灵感的开源项目 例如PostgreSQL（ ） Nonstop SQL（ ）和MicrosoftSQL Server（ ）等 这些系统使用了原始SQL的不同方言 SEQUEL QUEL Informix SQL等 直到 年 人们才第一次试图为SQL语言制定标准 毫无疑问 各个厂商关于SQL语言的战争仍在继续

当前的RDBMS市场已经被几个重量级的专有关系型数据库瓜分 Oracle（ %） IBM（ %）和Microsoft（ %） 更小的专有数据库系统Teradata和Sybase 每种不到 %的市场份额 其他数据库厂商 包括开源数据库 大约占有 %的市场份额

对于大型企业来说 选择一个数据库产品作为应用程序的基础并不是一个简单的任务 这不仅仅是因为数据库系统软件需要花费好几万美元的许可证费用 几十万美金的维护和技术支持费 而且在于与其他软件 硬件和人力资源投资相比 数据库软件的投资还是一个决定整个企业架构的关键要素 尽管近年来从一个RDBMS迁移到另一个RDBMS变得更加容易 但考虑选择哪一种数据库依然会给CFO带来噩梦

IBM DB LUW

从带有MVS系列 *** 作系统的大型机到z/OS 以及后来的UNIX和Windows系统 IBM在RDBMS领域都是一个长期的领跑者 IBM数据库的当前版本是IBM DB LUW（Linux UNIX和Windows）

IBM DB 在事务处理速度上保持了绝对领先的记录（更多信息请参见第 章） 它具有多个不同的版本 从Advanced Server Enterprise版本到免费的DB Express C版本（尽管功能上有限制） 免费的DB Express C版本可用于运行本书中的示例

直到DB 的 版本 依然遵循ANSI/ISO SQL Entry标准（请参考本章后面的内容）并支持由其他标准化组织制定的一些高级功能 例如Open Geospatial Consortium（开放地理信息联盟） JDBC X/Open XA 它还包含了最新SQL: 标准的部分功能 除了自己内置的过程化扩展语言SQL PL之外 它还支持使用Oracle的PL/SQL语言 Java语言 甚至Microsoft的 NET家族的语言来创建存储过程（更多内容请参见第 章）

Oracle

Oracle数据库可以追溯到 年第一次发布的Oracle V 开始时用于VAX/VMS系统 并于 年支持UNIX系统 经过多年发展 对于SQL标准定义的绝大多数功能 Oracle数据库都添加了相应的支持 在最新发布的Oracle g版本中功能支持达到了极致 它声称遵循最新SQL: 标准的很多功能

在高性能事务处理的标杆上 Oracle占据了第二名的位置 它是企业生态系统的核心 Oracle是一个安全的 健壮的 可伸缩的 高性能的数据库系统 它统治UNIX市场长达数十年 除了对SQL标准的支持之外 Oracle还提供了一种内置的过程化语言PL/SQL（关于过程化扩展的更多内容 请参见第 章） 另外它还支持通用的程序设计语言 例如Java

在写作本书之时 Oracle的最新版本是Oracle g 只有Oracle g有免费的速成版 该版本在数据存储的容量和RDBMS能够利用的处理器（CPU）数量上存在一定的限制 速成版完全支持本书所讨论的所有SQL功能

Microsoft SQL Server

SQL Server来源于Microsoft Ashton Tate和Sybase合作的结果 开始的目标是改写已有的 仅适用于UNIX的Sybase SQL Server数据库 使之适用于新的IBM *** 作系统OS/ Ashton Tate随后退出了这一合作 IBM OS/ *** 作系统也逐渐被人淡忘 Microsoft和Sybase为了分享成果 开始小心地避免触犯彼此 Microsoft致力于发展并支持Windows和OS/ 系统上的SQL Server 而Sybase则致力于UNIX平台 尽管在SQL Server的核心技术上Microsoft依然采用了相当多的Sybase技术 但双方的合作关系于 年正式结束 Microsoft于 年发布了Microsoft SQLServer 它消除了Sybase余留的痕迹 为世界（Windows系统的世界）带来了一个完全崭新的RDBMS系统 时至今日 Microsoft占据了RDBMS大约 %的市场份额 而在Windows系统上它占据了至高无上的位置

在写作本书之时 最新版本是Microsoft SQL Server Release Microsoft还提供了一个免费但有限制的Express版本 它支持本书所介绍的全部SQL功能

Microsoft Access

Microsoft Access也被称为Microsoft Office Access 它是一个桌面型关系数据库（相对来说是关系型的） Microsoft Access的设计目标是成为一个集成的解决方案 结合关系型数据库引擎的要素和应用程序开发的基础结构（配套有内置的程序设计语言和程序设计模型） 并作为一个报表平台 与本书中讨论的其他RDBMS不同的是 Microsoft Access是一个基于文件的数据库 因此它在性能和可伸缩性方面都存在固有的局限 例如 虽然最新版本的Access理论上允许最多 个并发用户 但在实践中超过 多个用户就会减慢Access的性能 Access仅支持SQL标准的一个子集 它提供了许多仅在Access环境中有效的功能

Access提供的功能之一就是从远程数据库链接表的能力 该功能使Access可以作为应用程序

的前端 访问任何与ODBC/OLEDB兼容的数据库

PostgreSQL

PostgreSQL是从美国加州伯克利大学的Michael Stonebraker所领导的一个项目演变而来的 Michael Stonebraker是关系型数据库理论的先驱 在最初的Ingres项目以及其继任者PostgreSQL中采用的那些原则也以各种方式被其他RDBMS产品采用 例如Sybase Informix EnterpriseDB和Greenplum

PostgreSQL的第一个版本发布于 年 之后第二年以 版本的名义发布 并保留了一个由一组专门的开发人员维护的开源项目 PostgreSQL具有很多个商业版本 最著名的是EnterpriseDB 一个私人公司为该产品提供企业支持（以及大量专有的管理工具） 在一些苛刻的企业级应用环境中 很多高端客户（例如Sony和Vonage）都采用了开源的RDBMS 这充分证明了EnterpriseDB的性能

在对SQL标准的支持方面 PostgreSQL可以说是最接近SQL标准的 另外它还提供了很多在其他数据库中所没有的功能 与它的开源伙伴（例如MySQL）不同 PostgreSQL从一开始就提供了参照完整性和事务支持 PostgreSQL内置了对PL/pgSQL过程化扩展语言的支持 另外实际上还具有适配其他任何语言来实现过程化扩展的功能

MySQL

MySQL最先是由Michael Widenius和David Axmark于 年开发的 并于 年发布了第一个版本 MySQL最初定位为一个轻量级的快速数据库 用于作为数据驱动型网站的后台数据库 尽管MySQL缺乏更加成熟的RDBMS产品所具有的许多功能 但在提供信息服务的速度上非常快 对于很多场合来说都已经 足够好 （为了达到真正的快速 MySQL避开了参照完整性约束和事务支持 更多内容请参见第 章和第 章） 另外 MySQL有着无法抗拒的价格 它是免费的 因此 在中小规模的用户群中 MySQL成为最流行的关系型数据库 在数据库产品的市场上 很多其他的免费产品在功能上都有所缺乏或者带有近乎商业炒作的宣传 数据库产品的巨人 Oracle IBM Microsoft和Sybase在那时也都没有提供各自RDBMS产品的免费速成版 在 年 Sun Microsystems公司收购了MySQL 随后Sun公司又被Oracle收购

目前 Oracle提供了一个带有商业支持的MySQL版本和一个Community Edition版本 伴随着这一收购 出现了大量分支版本 例如MariaDB和 Percona Server 它们在通用公共许可证（General PublicLicense GPL）下继续保持免费状态 GPL是一种限制最小的开源许可证

MySQL的最新版本是 MySQL 也已经指日可待 它是多平台的（Linux/UNIX/Windows） 并且支持SQL: 的绝大多数功能 其中一些功能依赖于选定的配置选项（例如 存储引擎）

存储引擎选项是MySQL独一无二的特性 它允许采用不同的方式处理不同的表类型 每一种引擎都有独特的功能和一定的限制（例如事务支持 聚集索引 存储限制等） 可以采用不同的存储引擎选项来创建MySQL数据库中的表 默认使用的是MyISAM引擎

HSQLDB和OpenOffice BASE

超结构化查询语言数据库（Hyper Structured Query Language Database HSQLDB）是一个用Java程序设计语言实现的关系型数据库管理系统 它是伯克利软件发行（BSD）许可证（这个许可证相当宽松）下的一个开源数据库

HSQLDB是OpenOffice BASE自带的默认RDBMS引擎 OpenOffice BASE是一个桌面型数据库 被定位于和Microsoft Access进行市场竞争 OpenOffice BASE也是一个关系型数据库 它健壮 功能丰富且相当快速 支持多种平台 包括Linux 各种版本的UNIX和Microsoft Windows OpenOffice BASE声称几乎完全遵循SQL: 标准 该标准包含了本书所讨论的绝大多数SQL子集

改写过的HSQLDB可以作为OpenOffice 套件组件BADE的一个嵌入的后端 并从 版本开始成为OpenOffice 套件中的一部分 与Microsoft Access类似 假如有适当的驱动程序的话 OpenOffice BASE可以连接到多种不同的RDBMS 在OpenOffice BASE产品中 已经包含了大量可用的Java Database Connectivity（JDBC）和ODBC（Open Database Connectivity）驱动程序

随着Oracle收购了OpenOffice 而其在Oracle的资助下作为开源项目的状态并不明确 OpenOffice 社区决定启动一个名为LibreOffice的新项目 意图在原来的BSD许可证的授权下将LibreOffice作为一个免费软件 实现OpenOffice的所有功能

关系型数据库并不是数据库领域中唯一的主角 一些似乎已经被关系型数据库理论打败的旧技术在更快和更便宜的硬件以及软件创新的帮助下卷土重来 对更高性能和更容易创建应用程序的需求催生了对列式数据库（columnar database）和面向对象数据库 使 将所有数据放在一个桶中 方法可行的框架 特定领域扩展（例如测地数据管理或多媒体）以及各种数据访问机制的研究 第 章将讨论这些话题

       返回目录 SQL实战新手入门

       编辑推荐

       Oracle索引技术

       高性能MySQL

lishixinzhi/Article/program/SQL/201311/16492

针对sqlite数据库文件，进行加密。现有两种方案如下:

1对数据库中的数据进行加密。

2对数据库文件进行加密

1uin怎么获取？

这个uin不是登录的帐号，而是属于内部的、程序界面上不可见的一个编号。

至于查看，最简单的方法就是登录web微信后，按F12打开网页调试工具，然后ctrl+F搜索“uin”，可以找到一串长长的URL，里面的uin就是当前登录的微信的uin。

还

有一种方法就是配置文件里，导出的微信目录下有几个cfg文件，这几个文件里有保存，不过是java的hashmap，怎么解析留给小伙伴们自己琢磨吧，

还有就是有朋友反应退出微信（后台运行不叫退出）或者注销微信后会清空这些配置信息，所以小伙伴们导出的时候记得在微信登陆状态下导出。博主自己鼓捣了一

个小程序来完成解析。

2一个手机多个登录帐号怎么办（没有uin怎么办）

根

据博主那个解密的帖子，必须知道串号和uin。串号好说，配置中一般都有可以搞到，uin从配置中读取出来的时候只有当前登录的或者最后登录的，其他的几

个记录都没办法解密。网上某软件的解决方法是让用户一个一个登录后再导出。这个解决方法在某些情况下是不可能的，或者有时候根本不知道uin。

后来经过一个朋友的指点，博主终于发现了解决方法，可以从配置中秒读出来这个uin，这个方法暂时不透漏了，只是说明下这个异常情况。

3串号和uin怎么都正确的怎么还是没办法解密

先

说说串号这个玩意，几个热心的朋友反馈了这个问题，经过博主测试发现不同的手机使用的不一定是IMEI，也可能是IMSI等等，而且串号也不一定是标准的

15位，可能是各种奇葩，比如输入#06#出来的是一个，但是在微信程序里用的却是另一个非常奇葩的东西，这种情况多在双卡双待和山寨机中出现，经过严

格的测试，现在已经能做到精确识别，那几位热心的朋友也赠与了不同的代码表示鼓励。

4计算出来了正确的key为什么无法打开数据库文件

微

信这个变态用的不是标准的sqlite数据库，那个帖子也提到了不是数据库加密，是文件的内容加密，其实是sqlcipher。官方上竟然还卖到

149$，不过倒是开放了源码，水平够高的可以自己尝试编译。google还能搜索到sqlcipher for

windows这个很好编译，不过博主不知是长相问题还是人品问题，编译出来的无法打开微信的数据库，后来改了这份代码才完成。

5数据库文件内容是加密的，怎么还原

这

个是某些特殊情况下用到的，比如聊天记录删除了数据库中就没了，但是某个网友测试说数据库无法查询出来了，但是在文件中还是有残留的。这个情况我没测试

过，不过想想感觉有这个可能，就跟硬盘上删除了文件其实就是删除了文件的硬盘索引，内容还是残留在硬盘上可以还原一样，sqlite数据库删除的条目只是

抹去了索引，内容还存在这个文件中。

网上的都是直接打开读取，并没有解密还原这个文件成普通的sqlite数据库，使用sqlcipher

的导出方法也只是将可查询的内容导出。后来博主花了时间通读了内容加密的方式，做了一个小程序将加密的文件内容直接解密，不 *** 作修改任何数据，非数据库转

换，直接数据流解密，完全还原出来了原始的未加密的数据库文件，大小不变，无内容损失，可以直接用sqlite admin等工具直接打开。

6已经删除的聊天内容可以恢复么

通过上述第5的方式还原出原数据后，经测试可以恢复。sqlite的删除并不会从文件中彻底删掉，而是抹掉索引，所以可以通过扫描原始文件恢复。前提是没有重装过微信。。。

两种加密方式的优缺点，比较如下：

一、对数据库中的数据进行加密

优点：

1实现数据加密快速，只需添加两个方法

一是：对明文数据进行加密返回密文数据

二是：对密文数据进行解密返回明文数据

2程序无需进行太大变动，仅在对数据进行添加，修改，删除，查询时。针对指定的表字段进行修改进行加密，解密的字段即可。

不足：

1由于对数据进行了加密。所以为了看到明文，必须密文进行解密。因此会增加处理器的消耗。因终端手机的处理能力有限，可能会出现处理数据缓慢的现象发生。

2仅仅对数据进行了加密，还是可以看到数据表的sql语句，可能猜测到表的作用。另外，如果没有对一个表中的所有字段加密，则可以看没有加密的明文数据。

需要做的工作：

1无需考虑平台差异性，qt,android,ios都能快速的实现。只需在每个平台上，使用各自的语言，实现同样的加密，解密算法即可。

2需要对加密算法进行了解，选择一种加密算法，进行实现。

二、对数据库文件进行加密

优点：

1对整个文件进行了加密，用户通过编辑器看不到任何有用的数据，用户使用sqlite browser软件也无法打开文件查看数据，保证了数据安全。

2进行打开数据库时，使用程序sqlite3_key(db,””,8);即可对文件解密，对数据表的 *** 作无需进行加密，采用明文即可。

不足：

1需要修改sqlite的源代码，这个工作难度比较大。

2需要对修改后的sqlite进行编译，需要对makefile有所了解，手动编写makefile文件，对源程序进行编译。因平台差异性，可能会造成某个平台无法编译生成动态链接库的可能。

3需要对数据访问层代码进行修改，例如qt平台需要将以前对数据库 *** 作使用的QSqlQuery类，更改为使用sqlite3h文件中定义 *** 作，对数据库 *** 作。其他平台也一样，都要做这一步的修改。

4在程序编译时，要加入使用加密的动态链接库（linux为共享库so文件）windows平台最容易，只需将所使用的dll文件copy到应用程序中即可。其他平台需要实验，看如何引入库,如果编译。

需要做的工作：

1修改sqlite源代码，追加对数据库文件进行加密的功能。

2编译含有加密功能的程序源代码，生成各自平台需要使用的库文件。

3将加密sqlite库文件引入各自平台中，修改数据库访问层代码。

4进行程序的部署，测试。

三、数据库加密原理

目前主流的数据库都采用了各种安全措施，主要包括用户认证、访问控制、数据加密存储和数据库 *** 作审计等措施。

用户认证：用户或者程序向数据库提供自己的有效身份z明，数据库鉴别用户的身份是否合法，只有合法的用户才能存取数据

库中的数据。用户认证是所有安全机制的前提，只有通过认证才能进行授权访问和审计。

访问控制：数据库管理系统为不同的用户分配不同的权限，保证用户只能进行授权的访问。目前，一些大型数据库(如Oracle 等)

都采用了基于角色的访问控制机制，即为用户授予不同的角色，如db—owner，security administrator 等，不同的角色允许对数据库执行不同的 *** 作。

数据库加密：用户认证以及访问控制对访问数据库进行了控制，但攻击者可能会利用 *** 作系统或数据库漏洞，或物理接触计算机，而直接接触数据库系统文件，从而可能绕过身份认证和存取控制而直接窃取或篡改数据库内容。对数据库中的数据进行加密是防范这类威胁的有效手段。

数据库 *** 作审计：监视和记录用户对数据库所做的各种 *** 作的安全机制，它记录并存储用户的 *** 作，用于事后分析，以检查导致数据库现状的原因以及提供追踪攻击者的线索。数据库的备份与恢复：当数据库发生不可恢复的故障时，可以将数据库恢复到先前的某个一致性的状态。

四、SQLite 加密

由于SQLite 是开放源码的，并且在其源码中预留了加密接口，我们可以通过实现其预留的加密接口实现口令认证和数据库加密以完善其加密机制。

1口令认证

SQLite 数据库文件是一个普通文本文件，对它的访问首先依赖于文件的访问控制。在此基础上，再增加进一步的口令认证，即在访问数据库时必须提供正确的口令，如果通过认证就可以对数据库执行创建、查询、修改、插入、删除和修改等 *** 作；否则，不允许进一步的访问。

2数据库加密

数据库加密有两种方式：

1)在数据库管理系(Data Base Management System，DBMS)中实现加密功能，即在从数据库中读数据和向数据库中写数据时执行加解密 *** 作；

2)应用层加密，即在应用程序中对数据库的某些字段的值进行加密，DBMS 管理的是加密后的密文。

前者与DBMS 结合好，加密方式对用户透明，但增加了DBMS 的负载，并且需要修改DBMS的原始代码；后者则需要应用程序在写入数据前加密，在读出数据后解密，因而会增大应用程序的负载。在此，通过实现SQLite 源码中预留的加密接口，实现DBMS 级的加密。

3使用xxx-tea 算法加密SQLite 数据库

微型加密算法（TEA）及其相关变种（XTEA，Block TEA，XXTEA） 都是分组加密算法，它们很容易被描述，实现也很简单（典型的几行代码）。

TEA 算法最初是由剑桥计算机实验室的 David Wheeler 和 Roger Needham在 1994 年设计的。该算法使用

128 位的密钥为 64 位的信息块进行加密，它需要进行 64 轮迭代，尽管作者认为 32

轮已经足够了。该算法使用了一个神秘常数δ作为倍数，它来源于黄金比率，以保证每一轮加密都不相同。但δ的精确值似乎并不重要，这里 TEA 把它定义为

δ=「(√5 – 1)231」（也就是程序中的 0×9E3779B9）。

之后TEA 算法被发现存在缺陷，作为回应，设计者提出了一个 TEA 的升级版本——XTEA（有时也被称为“tean”）。XTEA 跟

TEA 使用了相同的简单运算，但它采用了截然不同的顺序，为了阻止密钥表攻击，四个子密钥（在加密过程中，原 128 位的密钥被拆分为 4 个 32

位的子密钥）采用了一种不太正规的方式进行混合，但速度更慢了。

在跟描述 XTEA 算法的同一份报告中，还介绍了另外一种被称为 Block TEA 算法的变种，它可以对 32

位大小任意倍数的变量块进行 *** 作。该算法将 XTEA

轮循函数依次应用于块中的每个字，并且将它附加于它的邻字。该 *** 作重复多少轮依赖于块的大小，但至少需要 6

轮。该方法的优势在于它无需 *** 作模式（CBC，OFB，CFB 等），密钥可直接用于信息。对于长的信息它可能比 XTEA 更有效率。

在1998 年，Markku-JuhaniSaarinen 给出了一个可有效攻击 Block TEA 算法的代码，但之后很快 David

J Wheeler 和 Roger MNeedham 就给出了 Block TEA 算法的修订版，这个算法被称为 XXTEA。XXTEA

使用跟 Block TEA 相似的结构，但在处理块中每个字时利用了相邻字。它利用一个更复杂的 MX 函数代替了 XTEA 轮循函数，MX 使用 2

个输入量。

生信分析论文写法如下：

这次我们来讲解的这边文献是 2019-10-12 发表的 OTT 杂志上的一篇生信加少量实验验证的文章。实话实说，目前对于生信最最最基本的，如果没有实验验证还是不好发文章的。所以一般都会加一些实验验证的。

这个文章的主要流程是个这样的:这里我们就基于文童的材料方法来说一下具体的内容:公共数据获取：当中关于公共数据获取部分提到了这些东西。使用了 GEO 数据库来进行候选数据筛选。

这 GEO 里面找到了三个芯片，其中描述了这三个芯片的平台。差异表达分析：作者使用了 GEO2R 来进行数据的筛选。富集分析：接着作者对差异表达的基因进行了富集分析，其中包括 GO 分析和 KEGG 分析。

作者使用的富集分析的软件是 DAVID，这个软件我们也吐槽过说，更新不及时，是很好用，所以推荐是 WebSestalt 富集分析软件，或者 clusterprofiler。蛋白相互作用分析：5TCGA 数据库验证再往下作者做的其实是 TCGA 的数据库验证，但是在材料方法里面没写。我们可以在结果当中具体的过程。

对于肿瘤研究，现在如果只是用 GEO 数据集分析，不用 TCGA 再看一下的话，都觉得不好意思，所以一般的肿瘤研究可能都会用到 TCGA 的验证的。其目的也就类似于多加了一个数据集来增加结果准确性。但是对于 TCGA 有些肿瘤正常样本很少。分析的结果可能偏差更大。文章使用的 GEPIA 的数据库。这个数据库对于查询 TCGA 表达结果还是很好用的，简单上手。

核心基因甲基化相关分析：在核心基因选择之后，利用了 TCGA 的甲基化数据MEXPRESS 来查看基因的田基化水平有没有变化。由于版本的更新。现在的这个数据库的 20 版本的结果会比之前的更加详细一些。

以上就是关于SQL实战新手入门：关系型数据库管理系统全部的内容，包括:SQL实战新手入门：关系型数据库管理系统、破解链接，DB链接、生信分析论文怎么写等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！