昨天我们看了数据库的使用，只不过那都是我们手工去输入的数据，今天我们用java来实现对数据库的连接。

JDBC简介

JDBC就是java 数据库连接，是java中的API，我们将用它来执行SQL语句，除了我们平常的mysql数据库以外，jdbc还提供了统一的多种的数据库。

如上图所示客户端通过jdbc API加载驱动后实现了数据的连接。接下来我们给出详细的步骤。

入门程序

我们先来学习一个简单的，首先我们新建的Java项目，其次是导入mysql的数据驱动jar包，jar可以在网上直接找一个，很方便，不需要太高版本的。

准备工作都有做好了之后，我们就可开始啦~

1,.注册驱动

方式一

方式二

在这里我们建议使用第一种方式，第二种方式会多次注册数据库，因为Driver()中其实就封装了一个注册驱动的方法，我们在外面又注册一次。

2.建立连接

我们通过上述的语句实现连接数据库，数据库对应写上数据库的名字，在后面将自己的数据库的用户名和密码因为补上。第二步就结束了。

3.获取执行sql语句的statement

4.执行sql语句的增删改查

在上面图片中，我们一般将sql单独拿出来，赋值给sql，方便操作。

5.如果是查询语句，就会有结果集返回，我们对其进行处理。

6.释放数据库的资源

按顺序依次关闭数据库的资源，防止资源的恶意占有。

主要接口或类

---DriverManger---

作用

a、注册驱动

b、获取与数据库的链接

改进注册驱动：

DriverManager.registerDriver(new com.mysql.jdbc.Driver());

缺点：严重依赖具体的驱动类；会导致驱动被注册2次。

替代方案：Class.forName("com.mysql.jdbc.Driver");

获取与数据库的链接

DriverManager.getConnection("jdbc:mysql://localhost:3306/ssm", "root", "hang");

---Connection---

我们知道所有和数据库之间的连接我们都是通过链接的方式进行的，如果我们想要对数据库进行操作，我们就要从连接的对象中获取可以执行数据库的statement对象，实现我们的操作。

---statement---

---PreparedStatement---

我们在这里，能用PreparedStatement就不要使用Statement，上面已经很明确了PreparedStatement的优点。

---ResultSet---

作用：

代表者查询语句的查询结果集

上面就是对java连接数据库的简单介绍，下篇文章我们就会对上述的代码进行优化，解决代码中的硬编码问题，以及代码的冗余问题，我们还引入连接池强化数据连接速率。

有帮助到大家的话，关注支持一下~

感谢坚持关注的朋友

世界很大，幸好有你

欢迎在评论区留下你的问题或困惑，我将每天与你分享我的观点和心得。

聚焦最新科技咨讯，探寻未来智能领域，我是女陶。

信息数据以及数据处理与存储他们之间大概可以表示为信息数据以及数据处理的综合在经过处理过程，然后转化为我们所需要的信息当然这个过程是需要存储的，这就涉及到了数据存储。

而涉及到数据存储就不得不提及到数据管理的发展演变过程，数据的管理呢，在50年代中期以前呢，一般是人工管理。而人工管理用到的也就是基本的应用程序1和应用数据组1。然后，应用程序2和数据组2张，一一对应。以至于到应用程序n和数组n，每个应用程序的使用背后都有对应的应用数据组，呈分布式排列。

而从50年代后期到60年代中期，这一阶段，人工管理转变成了文件系统，所有的应用程序以及数据组全都与文件管理系统息息相关。不管是应用程序还是数据组都是从文件管理系统中调取，从而形成了以文件管理系统为核心的发散式分布。

而60年代后期开始呢，有文件系统转变为了数据库系统，而此时的核心就是数据库管理系统。所有的应用程序全都对接于数据库管理系统，数据库管理系统背后的操盘手就是数据库。数据库就是所有数据库管理系统的集合，他可以直接由应用程序调用，。更甚者有数据库集合，在数据库内分库分表以完成更高紧密度配合的数据处理以及管理分析。

数据库是在计算机内长期储存有组织可大量共享数据的集合。而这种结合的特点是，可以数据独立性比较高，统一管理和控制比较方便，应用程序对数据资源可以共享，具有最小的冗余度。

这样就是数据库的用户从以前不能直接通过操作系统访问数据库文件中的数据到如今用户可以通过DBMS访问数据库文件中的数据，经过数据库管理系统从操作系统的进程管理，内存管理，文件管理，设备管理等服务中调用。而这些都取自于数据库容器，而数据库容器中的数据对象都是以文件为单位存储在外存中这就是我们通常所说的表，视图以及索引。

而数据库操作系统就是在用户与操作系统之间的一层数据管理应用。它可以帮助用户有效的存储和组织数据，以及更加高效的获取有用的数据信息，同时也是维护和管理数据库的软件。而它通常包括的几个主要功能，其中有数据库的运行和管理功能，数据库的维护和建立功能，数据库的操纵功能以及数据库的定义功能。

数据模型在现实数据库管理的过程中起着关键作用，而数据模型也是数据库技术发展的主线现有的数据库基本上是基于某种数据模型。

而数据库都是依赖于数据模型来实现对于现实世界中的某些特征的模拟和抽象，比如我们数学中经常用matlab软件制作的数学模型，用来把抽象的场景具体化为模型，这就好比现实世界中理解和认识起来比较抽象的概念，用数据模型表达出来，这种数据模型就是数据库系统支持的逻辑数据模型，而这种模型又进一步转化为存储的物理数据模型这就是现实世界中客观对象的抽象过程，首先，现实世界的概念模型，是由数据库的设计人员完成，其次，概念模型和逻辑模型，也是由数据库设计人员完成，而最终，逻辑模型物理模型是数据库管理系统完成。

对于数据库，小编知之甚少，现学现卖，不知道有哪位大神还可以多为我补充指点一二？

很多院校有大数据课程和方向，关联度较高的专业有：软件工程、计算机科学、信息管理、应用数学/数学与统计。大数据应用有三个主要层面（即数据管理、系统开发、海量数据分析与挖掘），这三个层面系统地帮助企业掌握大数据应用中的各种典型问题的解决办法。

大数据的核心技术：（1）大数据与Hadoop生态系统。详细介绍分析分布式文件系统HDFS、集群文件系统ClusterFS和NoSQL Database技术的原理与应用；分布式计算框架Mapreduce、分布式数据库HBase、分布式数据仓库Hive。（2）关系型数据库技术。详细介绍关系型数据库的原理，掌握典型企业级数据库的构建、管理、开发及应用。（3）分布式数据处理。详细介绍分析Map/Reduce计算模型和Hadoop Map/Reduce技术的原理与应用。（4）海量数据分析与数据挖掘。详细介绍数据挖掘技术、数据挖掘算法–Minhash, Jaccard and Cosine similarity，TF-IDF数据挖掘算法–聚类算法；以及数据挖掘技术在行业中的具体应用。（5）物联网与大数据。详细介绍物联网中的大数据应用、遥感图像的自动解译、时间序列数据的查询、分析和挖掘。（6）文件系统（HDFS）。详细介绍HDFS部署，基于HDFS的高性能提供高吞吐量的数据访问。（7）NoSQL。详细介绍NoSQL非关系型数据库系统的原理、架构及典型应用。

1.前言

为了适应大数据应用场景的要求，Hadoop以及NoSQL等与传统企业平台完全不同的新兴架构迅速地崛起。而下层技术基础的革命必将影响上层建筑：数据模型和算法。简单地将传统基于第四范式结构化关系型数据库的模型拷贝到新的引擎上，无异于削足适履，不仅增加了大数据应用开发的难度和复杂度，又无法发释放新框架的潜能。

该如何构建基于NoSQL的数据模型?现在能供参考的公开知识积累要么是空虚简单的一句“去规范化“或粗暴的宽表化(将query和应用需要访问的所有字段“排排坐“，放在一个有很多列的结构化表中)，要么是针对具体工具或具体场景的实现细节，(如《HBase权威指南》中对于如何设计HBase主键的探讨)。没有一个像编程的设计模式一样的，在模型架构层面可以遵循的方法论。

在比较不同的NoSQL数据库时，通常使用功能以外其他各种指标，如可扩展性、性能和一致性。由于这些指标通常是使用NoSQL的初衷，所以无论从理论的角度还是实践的角度被深入地研究了，而像CAP定理这样的分布式系统基础结论也同样适用于NoSQL系统。另一方面，在NoSQL的数据模型领域，却还没有很好地研究过，也缺乏关系数据库中那种系统性的理论。

我在这篇文章中从数据建模的角度对NoSQL家族系统做了比较简单的比较，并简要介绍几种常见建模技术。

2.NoSQL数据模型视图

要探索数据建模技术，必须先从系统性的NoSQL数据模型视图着手，这多多少少能帮助我们揭示其发展趋势以及相互之间的关系。下图描绘了主要NoSQL家族系统的虚拟“进化”过程，即键值存储，BigTable类型的数据库，文档数据库，全文搜索引擎，数据库和图形数据库：

首先，我们应该注意到，一般意义上讲，SQL和关系型模型都是在很久以前就被设计出来，目的是为最终用户交互之用。这种面向用户的性质有极深的影响：

最终用户往往对汇总报表信息感兴趣而不是单独的数据项，因而SQL这方面做了大量的工作。

不能指望作为自然人的用户能显式地控制并发性、完整性、一致性或者数据类型有效性。这就是为什么SQL竭力关注于事务保证、schema和参照完整性。

另一方面，软件应用程序往往对在数据库内部做聚合没有太大的兴趣，而且至少在许多情况下，程序能够自己控制完整性和有效性。除此之外，剔除这些功能对于性能和可扩展性存储的影响极其重要。

新数据模型的演变开始了：

键-值存储是一个非常简单，但非常强大的模型。下面所描述的许多技术都完全适用于这个模型。

键值模型最致命的缺点之一就是不适合按范围处理主键的场景。有序的键-值模型突破了这一限制，并显著提高了聚合能力。

有序的键-值模型非常强大，但它不提供任何针对值(value)的建模框架。在一般情况下，值的建模可以由应用程序完成，但BigTable风格的数据库想得更加周到，它可以将值按照映射的映射的映射(map-of-maps-of-maps)进行建模，说得明确点，分别是列簇(column family)、列(column)和时间戳化的版本。

文档数据库对BigTable模式提出两个明显的改善。第一，值可以被声明为任意复杂的schema，而不仅仅是一个映射的映射(map-of-maps)。第二，至少有一些产品实现了被数据库管理的索引。就这个意义上来讲，全文搜索引擎也可以同样被认为提供了灵活的schema和自动化的索引。他们之间主要区别在于，文档数据库是根据字段名对索引进行编组，而搜索引擎是使用字段值对索引编组。值得注意的是像Oracle Coherence这样的键-值存储系统增加了索引和内嵌入口处理器的功能，正逐步向文件数据库演进。

最后，图形数据模型可以被视为有序的键-值模型朝另外一个方向的进化。图形数据库允许对业务实体进行非常透明的建模(这个东西取决于那个东西)，而分层建模技术在这方面用的是另外的数据模型，但也可与之媲美。图形数据库和文件数据库息息相关，因为许多实现允许建模的值是映射或者文档。

3.NoSQL数据建模的一般注意事项

与关系型建模不同，NoSQL数据建模往往是从特定查询的应用开始：

关系型建模是典型地被手上可用数据的结构所驱动。设计主要围绕着的是“我有什么样的答案?”

NoSQL数据建模通常由特定应用的访问模式所驱动，比如需要支持的查询类型。设计主要围绕着的是“我有什么问题?”

NoSQL数据建模往往比关系数据库建模需要更加深入地了解数据结构和算法。在这篇文章中，我介绍了几个著名的数据结构，他们虽然非NoSQL所特有，但对于实际的NoSQL建模非常有用。

数据复制和去规范化是一等公民。

关系数据库在对分层或图形数据进行建模和处理时不是很方便。图形数据库显然是这个领域的完美解决方案，但实际上大多数的NoSQL也都非常善于解决这样的问题。这就是为什么这篇文章为分层数据建模单独写了一个章节。

虽然数据建模技术基本上和具体实现无关，但我还是列出了在写这篇文章时我能想到的产品：

键值存储：Oracle Coherence，Redis，Kyoto Cabinet

BigTable风格的数据库： Apache HBase，Apache Cassandra

文档数据库： MongoDB，CouchDB

全文搜索引擎： Apache Lucene，Apache Solr

图形数据库：Neo4j，FlockDB

4.概念技术

本节专门介绍NoSQL数据建模的基本原则。

1、 去规范化(Denormalization)

可以将去规范化定义为把相同的数据复制到多个文档或数据表中，这样可以简化/优化查询处理，或者让用户数据能匹配一个特定的数据模型。在本文的大多数技术用到了这样或那样的去规范化。

一般来说，去规范化用于以下的折衷：

查询的数据量或每次查询IO**与总数据量的折衷。去规范化可以将一个查询所需的所有数据组合起来存放到同一个地方。这通常意味着对相同数据的不同的查询会访问不同的数据组合。因此，数据需要被复制多份，也就意味着增加了总数据量。

处理复杂性与总数据量的折衷。建模时的规范化和相应查询的连接(join)明显增加了查询处理器的复杂度，在分布式系统中尤为明显。去规范化允许将数据按照查询友好的方式存储，从而简化查询的处理。

适用性：键值存储，文档数据库， BigTable风格的数据库

2、 聚合(Aggregates)

所有主流NoSQL都提供了这样或那样的松散schema(soft schema)支持：

键值存储和图形数据库通常不对值进行约束，所以值可能是任意格式。另外，也可以通过使用组合键将一个业务实体表示为多条记录。例如，可以将一个用户帐户建模为UserID_name，UserID_email，UserID_messages等组合键表示的一个实体集合。如果用户没有电子邮件或消息，然后相应的实体不会被记录。

BigTable模式也支持松散schema，因为一个列簇是可变的列集合，一个单元格又能存储不定数目的数据版本。

文档数据库天生就没schema，虽然某些文档数据库允许在数据输入时使用用户定义的schema进行验证。

松散schema允许使用复杂的内部结构(嵌套实体)构造实体的类，也允许改变特定实体的结构。这个更能带来了两个重要的便利：

通过嵌套的实体，最小化了一对多的关系，也因此减少了连接(join)。

异构业务实体的模型可以使用一个文档集合或者一个数据表。松散schema掩藏了这种建模和业务实体之间“技术”上的差异。

我们用下面的图来说明这些便利。该图描绘了对电子商务领域中一个产品实体进行的建模。首先我们可以认为所有的产品都有一个ID、价格(Price)和描述(Description)。进一步来看，我们发现不同类型的产品有不同的属性，如图书包含作者信息，而牛仔裤有长度属性。这些属性中间的某些属性天生就有一对多或这多对多的特性，比如音乐唱片中的曲目。

更进一步来看，可能有些实体不可能使用固定的类型进行建模。例如，不同品牌的牛仔裤的属性是不固定的，而每个制造商出产的牛仔裤的属性也是不一致的。在规范化的关系型数据模型中虽然这些问题都可以解决，但方法很猥琐。松散schema软架构允许只使用一个聚合(Aggregation)(产品)就能对所有类型的产品及其属性进行建模：

内嵌的去规范化会在性能和一致性上对更新操作造成很大的影响，所以要特别注意更新过程。

适用性：键值存储，文档数据库， BigTable的风格数据库

3、 应用端连接(Application Side Joins)

很少有NoSQL解决方案支持连接。NoSQL“问题导向”性质的后果就是，通常在设计时处理join，而关系型模型是在执行查询时处理join。查询时处理join几乎肯定会带来性能上的损失，但在许多情况下，可使用去规范化和聚合，即嵌入嵌套实体来避免join。当然，join在许多情况下是不可避免的，而且应该由应用程序处理。主要的用例：

多对多关系往往是通过链接(link)建模的，这需要join。

聚合操作往往不适合内部实体会被频繁修改的场景。通常更好的办法是将发生的事情作为一条新的记录保留，并在查询的时候将所有记录做join，而不是去更改值。例如，对于一个信息系统而言，可以用嵌套包含了Message实体的User实体来建模。但是，如果会经常地添加消息，更好的办法可能是把Message提取出来作为独立实体，并在查询时再将其与User进行连接：

适用性：键值存储，文档数据库， BigTable风格数据库，图形数据库

5.一般建模技术

在本节中，我们将讨论适用于各种NoSQL实现的一般建模技术。

1、 原子聚合(Atomic Aggregates)

许多NoSQL解决方案提供了有限的事务支持，虽然有些NoSQL不支持。在某些情况下，人们还可以使用分布式锁或应用程序管理的MVCC机制实现事务行为，但常见的是使用聚合技术来对数据建模，以保证一些ACID特性。

强大的事务处理机制对于关系型数据库而言是不可或缺的，其中原因之一就是规范化的数据通常需要在多个地方进行更新。另一方面，聚合允许一个单个业务实体存储为一个文件，行或键值对，从而可以对其进行原子性的更新：

当然，做为一种数据建模技术，原子聚合并不是一个完善的事务型解决方案，但如果存储能提供原子性、锁或者TAS(test-and-set，测试并设置)指令上的一些担保，那原子聚合就是可行的。

(译者注：即将需要事务性操作的业务数据聚合放在一起，存储在一个NoQSQL提供或者应用能提供原子性操作的数据结构中。使用HBase时，将某个用户某个业务的所有数据，如上图，用一行存储就是这种模式的应用。)

适用性：键值存储，文档数据库， BigTable风格数据库

2、 可枚举主键(Enumerable Keys)

也许无序键-值数据模型最大的好处就是可以通过将主键哈希的办法把实体数据分别存储在多个服务器上。排序使事情变得更加复杂，但是即使存储不提供这样的功能，有时应用程序也能利用到有序主键的优势。让我们将对电子邮件建模作为一个例子：

某些NoSQL存储提供原子计数器，能生成一个顺序化的ID。在这种情况下，可以使用userID_messageID作为一个复合键来存储消息。如果最新的消息ID是已知的，那就可以遍历以前的消息。另外，对于任何一个给定的消息ID，也可以向前或向后进行遍历。

也可以将消息分桶(bucket)，例如，每天的数据放到一个桶里。这样就允许从任何指定日期或当前日期开始，向前或向后遍历一个邮箱。

适用性：键值存储

(译者注：能利用主键的一些自然或业务维度的特征，将随机读写转换为顺序读写能提高遍历性能，同时能方便应用逻辑编写。但需要注意对分布式部署时并发写的影响以及对于业务的过度耦合。对于无序主键和有序主键的讨论可以参见《HBase权威指南》中Schema设计章节。)

3、 降维(Dimensionality Reduction)

降维这种技术允许将一个多维数据模型映射到一个键-值模型或其他非多维模型。

传统的地理信息系统使用四叉树(Quadtree)或R树(R-tree)的某种变形来做索引。这些结构需要就地完成更新操作，因此在数据量很大时，维护开销相当的大。另一种方法是对这个二维结构进行遍历，并将其扁平化为一个普通的条目列表。使用这种技术的一个众所周知的例子是Geohash。 Geohash使用类似Z形状的路线来扫描整个二维空间，每次移动根据行进方向被编码为0或1。交错位的经度和纬度上的变更移动以及移动。编码过程在下图中进行了说明，其中黑色和红色位分别代表经度和纬度：

如图所示，Geohash的一个重要特性是能够通过这种逐位编码的近似程度来估计区域之间的距离。Geohash编码允许使用简单普通的数据模型来存储地理信息，比如用有序键值保存空间上的联系。[6.1]讲述了BigTable中的降维技术。更多有关Geohash及其相关技术的信息可以在[6.2]和[6.3]中找到。

(译者注：通过交织编码方式来能将原本需要多维度标示的数据，如cube，存储到一维的键值存储系统中，这是一种非常重要的建模模式：提供了不同缩放等级下在多维空间中邻接的数据仍然顺序存储，遍历高效;同时不同主键从前向后的相似度和空间距离的远近相一致，能通过键值的简单顺序比较判断其位置“相似度”。

它的应用远远不只地理信息的表示，有多个维度属性不同粒度的数据表示都能用到这个技术，比如线下销售交易数...

学习了Java的一些基础基础知识，今天我们学习到的是数据库的下载使用，比起单纯的读取本地文件，数据库可以更加快速的对数据进行操作。

Mysql数据库简介

数据库其实就是我们存储数据的一个仓库，它的本质是一个文件系统，我们将数据通过一定的格式存储起来，实现对数据的增加，删除，修改以及查询操作。

Mysql数据库是目前市面是开源的关系型数据库，它可以通过结构化语言SQL对数据库进行管理。

比起别的数据库，mysql数据库的占有内存系哦啊，运行的速度比较快，成本比较低，这样让一些小型的网站有了最好的选择，其中最重要的是开源。

数据库服务器安装

我们在网站上可以找到官方版和社区版2种版本的安装，一般我们会选择安装社区版的服务器，因为比起企业版的社区版是免费的呀~而企业版本是付费的，只有稳定的sql版本，付费也是会得到官方的技术支持。

在网站上下载到压缩包之后，开始下面步骤，我们这里选的是mysql-5.7.17-winx64.zip压缩包。

1.解压到mysql数据库压缩包d:data，这里主要尽量不要选太深的目录。

2.配置环境变量

MYSQL_HOME=d:/datapath=%MYSQL_HOME\bin;

文件路径都配置好之后，我们将Mysql添加到系统服务中并启动

3.以管理员身份运行cmd，切换目录到解压的文件夹下的bin

4，执行安装名mysqld install MySQL --defaults-file="D:\zhong\mysql-5.7.17-winx64\my-default.ini"

5 start mysql启动数据库

在这里我们可能会遇到sql服务器无法启动的情况

这时候我们的解决方法是

mysql --installmysql --initializenet start mysql

一般情况是正常的，但如果还是失败了，我们使用命令sc delete mysql，在进程中结束mysqld，删除原解压目录，在根目录下新建一个目录重新解压文件，再次执行上述步骤。

6.修改密码

mysql会在启动之后，初始化一个默认的密码，这个密码我们可以在安装目录下的data中 主机名.err这个文件中找到，如下图

数据库密码

登陆mysql -uroot -p，输入上面文件中的密码：lsix6)UhXhsJ，修改密码，执行：SET PASSWORD =PASSWORD('root');

上述就是对数据的简单安装程序，有帮助到大家话，关注一下呗~

感谢坚持关注的朋友~

世界很大，幸好有你~

欢迎在评论区留下你的问题或困惑，我将每天与你分享我的观点和心得。

聚焦最新科技咨讯，探寻未来智能领域，我是Mario女陶。

大数据技术在近几年发展十分迅速，在互联网公司以及传统公司都得到了广泛的应用。传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库NoSQL则由于其本身的特点得到了非常迅速的发展，NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题NoSQL一直伴随着大数据技术的发展，各种NoSQL层出不穷，应该如何学习及选择NoSQL？我们通过几个问题来让大家全面了解NoSql，以便更好的学习。

489034603

一、大数据技术有哪些？它们和NoSQL的关系是什么？

大数据技术很多，占据主流地位的大数据技术有：Hadoop、Storm、Spark等，它们又是由很多更具体的技术所组成。比如组成Hadoop大数据平台的技术有：HDFS、YARN、MapReduce、Ambari、Avro、Cassandra、Chukwa、HBase、Hive、Mahout、Pig、Tez、ZooKeeper等。

大数据技术是对海量的结构化和非结构化的数据进行提取、管理、处理、分析、存储等的技术，所以大数据技术和NoSQL的关系是包含关系。NoSQL技术主要是面向结构化数据和非结构化数据进行存储和管理的技术。所以NoSQL只是大数据的一个方面，大数据技术中，涉及存储的还可以是关系数据库，以及分布式文件系统等。

二、NoSQL兴起的原因是什么？有哪些主要的类型？这些类型NoSQL的特点是什么？

主要是因为Web 2.0时代的到来，关系数据库越来越不能满足互联网应用的需求，导致了NoSQL的兴起。这些需求包括：

1）数据的高并发读写 2）数据的高可用性 3）海量数据存储 4）海量数据的实时分析

NoSQL的主要类型包括：

1）文档型数据库 特点：面向集合存储，模式自由，使用高效的二进制数据存储等。

2）键值存储数据库 特点：以键为索引的存储方式，访问速度极快。

3）图数据库 特点：以节点/关系/属性为基础存储数据，善于处理大量复杂、互连接、低结构化的数据。

4）列式数据库 特点：以列相关存储架构进行数据存储，适合于批量数据处理和即席查询。

5）内存数据库 特点：将数据放在内存中直接操作，数据处理速度比传统数据库的数据处理速度要快很多。

6）XML数据库 特点：高效存储XML数据，并支持XML内部查询语法。

三、每种NoSQL有什么代表性的开源系统？其主要适合什么样的场景？

1）文档型数据库

代表：MongoDB、CouchDB、CouchBase、MarkLogic、Clusterpoint

应用场景：适用于数据变化较少，执行预定义查询，进行数据统计的应用程序。适用于需要提供数据版本支持的应用程序。

2）键值存储数据库

代表：Dynamo、FoundationDB、MemcacheDB、Redis、Riak、Aerospike

应用场景：高读取、快速检索。

3）图数据库

代表：Neo4j、OrientDB、ArangoDB、MapGraph

应用场景：社会关系，公共交通网络，地图及网络拓谱。

4）列式数据库

代表：Cassandra、HBase、Accumulo、Druid、Vertica

应用场景：适合于批量数据处理和即席查询。

5）内存数据库

代表：Redis、Membase

应用场景：适用于数据变化快且数据库大小可遇见(适合内存容量)的应用程序。

四、如果需要自己构建一个NoSQL系统，主要需要考虑哪些核心问题？

首先确定适用的应用场景，功能大而全是不现实的。

其次根据应用场景确定存储方式。

选择存储引擎，是自行开发还是借用开源引擎。

再次是设计访问协议，一般是基于TCP基础上的自定义协议。

接着是开发管理系统，提供NoSQL数据库的基本管理功能。

再次是编写各种语言的驱动包。

最后是提供客户端GUI工具。

读完这篇文章，我相信大家对NoSQL应该有了一个全面的了解，NoSQL运用越来越普通，正在学习的小伙伴抓紧了，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

真正要明白”范式（NF）”是什么意思，首先看下教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。实际上可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

在实际开发中最为常见的设计范式有三个：

首先是第一范式（1NF）

符合1NF的关系（你可以理解为数据表。“关系”和“关系模式”的区别，类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你可以把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。1NF的定义为：符合1NF的关系中的每个属性都不可再分。表1所示的情况，就不符合1NF的要求。

表1

实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：表2

表2

但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表3中的设计：

每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大

假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 ----—插入异常

假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常

假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。

正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

第二范式

第二范式在第一范式的基础之上更进一层。是指2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。

函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

表中的函数依赖关系例如：

系名 → 系主任

学号 → 系主任

（学号，课名） → 分数

但以下函数依赖关系则不成立：

学号 → 课名

学号 → 分数

课名 → 系主任

（学号，课名） → 姓名

码:假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。码也可以理解为主键。

第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

订单信息表

订单项目表

商品信息表

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

因此可以总结判断的方法是：

第一步：找出数据表中所有的码。

第二步：根据第一步所得到的码，找出所有的主属性。

第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。

第四步：查看是否存在非主属性对码的部分函数依赖。

第三范式

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。

则就是第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

订单信息表

客户信息表

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。

由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。

上篇文章我们学习对数据的单表操作，我们现在看数据库中的多表关联操作。很多时候我们的数据是单独分开存储的，这时候我们就需要多张表连接起来去去获取我们想要的数据。

外键约束

在多表操作时，每张表与另外的表之间的关系有一个对一个，有一个对多个，也有多个对多个的关系，而这些表之间的关系西哟啊通过外键来维护。外键也就是相当于我们所说的关系。

特征如下：

外键必须是另外的一张表或者自身表的主键的值，换句话说就是你在你的圈里面是老大，到了我这个圈里面我是老大，我能通过你找到你手里的人，我的仆人的仆人就是我的仆人。外键是可以有重复值的，不同的圈子里面，扮演不同的角色。外键也是可以为空值的。一张表可以有许多的外键，总之外键没有主键那么严格。

上述语句含义是设置一个外键 foreign key 是orders中的uid，起名字叫FK_UIK；设置一个主键 references 是 USER中的uid

交叉连接

交叉连接的语法就是上图的2中方法，我们可以使用cross join或者两张表之间加英文逗号来实现两表的连接。

除此之外，我们使用 A join B也是可实现的。

实现原理

内连接

内连接也就是我们说的自身连接，在内连接中我们有2中语法

显示内连接语法：

隐式内连接语法：

外连接

我们将外连接又分成了左外连接与右外连接。

左外连接，就是以左边为主，我们将查询到的结果是左边的表全部要显示，右面的表补齐。如下图。

右外连接，就是以右边为主，与左外连接相反。

联合查询

我们可以通过联合查询自动消除重复的记录。

子查询

我们将放在外面的查询语句称为父查询，而放在里面查询称为子查询。下图所示。

补充

Limit 起始行数 | 每页显示的行数

Md5() 给添加的密码加密

下篇我们带来的是在Java中对数据库进行连接操作，也就是JDBC，如果有帮助到大家，关注支持一下呗~

感谢坚持关注的朋友

世界很大，幸好有你

欢迎在评论区留下你的问题或困惑，我将每天与你分享我的观点和心得。

聚焦最新科技咨讯，探寻未来智能领域，我是女陶。

HBase是一种面向列的数据库，它常常会被拿来和传统的关系型数据库（RDBMS）进行比较。两者在实现和设计上的出发点差别很大，下面小鸟就客观的讲一讲两者的区别。

一、存储的量级

在传统的关系型数据库中，随着数据量的增大，查询速度会越来越慢，一张有上百个字段的数据表在有千万级别的数据量时，响应速度会变的非常缓慢。

而HBase是一个分布式的数据存储系统，他的建立是基于HDFS的。其设计的初衷就是为了解决传统关系型数据库在处理海量数据时，速度太慢的问题。

二、数据的灵活度

HBase是面向列存储的，其存储结构是一种key-value的方式，因此在数据有新的字段需求的时候可以随意增加。

而传统关系型数据库则只能通过关联表的方式，通过增加外键和索引来处理新的字段，因此极为不便。

三、响应的速度

传统关系型数据库读写数据是需要考虑主键、外键和索引等因素的，随着数据的剧增其响应速度也是梯度下降的。

而Hbase则不会有这样的问题，其写数据的性能和表的大小无关，并且由于其key-value的存储格式等原因，其读数据的速度也几乎不会下降。

四、良好的扩容

HBase的扩容只需要在集群上简单的增加节点。其新增节点的代价很小，HBase中增加一个节点服务器只需要3万不到，并且由于节点很多，某个节点宕机并不会对整个集群造成巨大影响。

而传统关系型数据库只能通过升级硬件来升级服务，单台高性能的服务器价格是非常昂贵的。

五、索引的支持

传统关系型数据库则会随着数据量的增加，出现索引膨胀的问题。

HBase是不支持索引的，在降低了查询便利度的同时增加了响应性能。

六、自动分区

HBase中的数据表会自动分裂，存入合适的RegionServer上。

传统关系型数据库则需要手动操作来实现分区。

如果传统型数据库已经成为了公司隐患的话，那么就应该好好考虑是否需要转型HBase了。并且这也意味着公司的规模越来越大了，毕竟只有海量的数据才需要使用到HBase，在数据量不大的时候，传统关系型数据库还是一个优先级更高的选择。

与其说HBase和传统关系型数据库各有优势，不如说HBase是大数据发展的必然产物，毕竟谁也不愿意忍受糟糕的延迟。

希望这篇文章能帮助到各位小伙伴们，关注小鸟，每天都有新的知识点！