数据重复是困扰许多企业的问题，但是一旦你了解了它的特点，以及如何去处理它，就可以提前发现并预防。在识别和消除重复数据时，也有很多潜在的选择，这样就可以找到适合你的业务和需求的最佳方法。

但是如果你想解决这个问题，你怎么开始呢？

下面是一些值得注意的最大问题：

记录问题。第一个最明显的问题是你的记录的准确性和可靠性。例如，你无意中列出了同一业务在你的销售记录中有两次；该公司的销售数字将加倍，因此，导致你的收入预测不合理地激增。当查看数据组时，你会更容易出现错误，并且在查找特定实例时，你可能会遇到更大困难，跟踪你需要的确切数据。

系统存储和批量。重复数据也会增加你的表格负担，从而阻塞你的系统，显示不必要的信息。在小规模上，这不是一个主要的数据来源，但是如果重复的数据存在于整个系统中，它可能会导致整个系统减速。

一般问题。很多人发现当查找重要信息时，重复数据集知道跟踪“正确”条目是多么烦人。例如，如果正在寻找“abc通信”，但是有一些条目是“abc公司”，“abc”和“abc通信”，它将花费你三倍或更长时间来获得正确的记录。这对于任何一个工作者来说都是个难题。

其他问题。重复数据也可能是其他原因的问题，具体而言，对于你数据表的应用而言。例如，如果你的网站上有太多重复的内容要索引，那么它可能会危及百度搜索排名还有其他搜索引擎，或者增加被索引的“错误”页面的可能性。

那么，你能做些什么来主动识别和消除重复数据？

这是一些比较好的策略：

完美的数据录入标准。每个组织都需要有一些所有工作人员应遵循的数据输入标准无论您的系统多么好，可能会有一些重复的数据点，除非所有的数据点都是一直遵循这些标准。制定严格、清晰的入门规则是一个好的第一步；除此之外，你用比较好的方法去教育你的员工，并确保他们理解这些规则，并要求他们遵守这些规则，这样他们就会一直遵循这些规则。

算法匹配非相同名称。通过创建更好的自动化流程算法可以自动匹配非相同名称。从前面章节中的例子中，我们提到了“abc公司”、“abc”和“abc通信”词条。a算法围绕着识别和自动合并“模糊匹配”之类的构建，可以防止它们作为不同记录存储起来。幸运的是在sql中安装主数据服务使创建干净、更合并列表变得非常容易。

自动化数据库清理。如果你的数据库已经在许多章节中遭受重复数据，或者过期检查，你也可以运行自动检查。你需要创建一个算法来扫描记录，以获取重复条目的标志，然后将数据合并到一个记录中。这里出错的可能性很高，所以请注意在敏感表上使用它。

手动数据库清理。作为备份，你还要执行手动数据库清理，特别是对于小表。

这些策略无法严格保证你将来不会遇到重复数据问题，但它们将消除当前大多数问题。随着数据标准的提高和数据库的清洁，你的整个团队都将能够提高自己的公众效率。

斯科特·斯通(Scott Stone)2018年5月2日 相隔译

如果你认为我是标题党，那么你是对的。但是不管怎样，请允许我回顾一下关系数据库市场的发展历程——它从哪里来，将到哪里去?

什么是关系型数据库

任何阅读本文的人肯定已经知道这个定义，但是与其他数据管理系统相比，关系数据管理系统到底意味着什么?

关系数据库指的是将数据集组织成离散的表，这些表通过公共数据字段相互关联。它从早期搜索效率很低的一般数据管理系统发展而来。在ACID(原子性、一致性、隔离性、持久性)成为它的开发原则之后，现代关系型数据库开始真正起飞。ACID这个缩写是1983年Andreas Reuter和Theo Harder创造的。Oracle、Sybase和Informix都是早期关系数据库市场领导者。

ACID标准是关键，因为它支持可靠的数据事务，这可能是应用程序的基础，需要速度、数据可靠性和完整性。持久事务是支持在企业级数据库上构建ERP(企业资源计划,Enterprise Resource Planning)应用程序的关键要素。

那么，既然成功了，为什么还要考虑关系数据库管理系统是否已经死亡呢?

炒作和现实……以及炒作的现实

几年前，我开始思考这个问题，当时我的一个同事在一个小组会议上漫不经心地宣称，应用程序开发领域的时髦声音都不再讨论数据库(至少不是传统的数据库)。取而代之的是，新的热情都围绕着NoSQL、大规模的扩展架构、以及不用对数据存储施加烦人的限制。随着人们不断试验并推出不同类型的应用，人们对这一技术的兴趣越来越浓厚。

人们很难反驳这种乐观情绪，因为在所有领导者中，科技的普及程度显然越来越高。这些观点来自于那些渴望成为下一个技术爆炸前沿的开发者们的喋喋不休。这里肯定有点什么，但它将如何和何时发生?

Gartner公司提出了技术炒作周期的概念，技术炒作周期是产生革命性技术的一般模式。其中心思想是对新概念的大肆宣传总是领先于技术的有效使用。这种热潮通常会在科技热潮中催生大量初创企业，以便成为第一批将这种承诺货币化、并利用第一波人气致富的企业。

当然，炒作循环的周期部分意味着，尽管这种兴奋可能会持续下去，但将新产品货币化的努力可能无法满足膨胀的预期。幻灭的低谷来自于未能尽快实现革命。由于市场增长速度不够快，不足以维持最初的热情，通常会有一些初创企业必须重组。

如果所讨论的技术没有被更好的替代技术所取代，如果投资者能够经受住这个低谷，那么我们就会逐渐学习有效的技术方法。只有这样，这项技术才会触及生产率的停滞期，这意味着它将会扩散并产生持久的影响。

从NoSQL到NewSQL到混合体到“非传统”

尽管NoSQL这个术语最初是Carlos Strozzi在1998年为他的开源关系数据库创造的，但是2009年之后流行起来的NoSQL数据库却不同。在Strozzi NoSQL仅仅排除结构化查询语言接口的地方，2009年大多数被称为NoSQL的数据库现在完全背离了关系模型。(Strozzi建议，更合适的称呼是NoREL，表示“没有关系”，但NoSQL名称已经很常用了。)

他对这些NoSQL数据库感到兴奋，因为它们克服了传统RDBMS的范围限制，使应用程序能够在不受固定模式限制的情况下进行扩展。它允许对数据库的频繁更改能够适应应用程序的修改。缺点是事务完整性不那么可靠，应用程序必须在没有标准接口或语言的情况下依托特定的数据库编写。

为了获得NoSQL的可伸缩性能而维护传统RDBMS的ACID事务标准和SQL接口，RDBMS创建了NewSQL。不久，在与纵列数据库(columnar database)和内存数据库(in-memory databases)的市场讨论中，NewSQL和NoSQL被合并在一起，并被称为混合数据库或当前的“非传统数据库”。这个术语涵盖了各种特定目的的数据存储，这些数据存储非常适合解决传统RDBMS不适用的各种问题。

因此，尽管传统RDBMS新选项的炒作和轰动是不可否认的，但要识别与传统RDBMS类似的统一和优越的方面变得越来越困难。

熟悉的模式

我不确定最初的来源，但我曾经读到一个说法，随着不断成长，人们对从事的领域会变得越来越熟悉。并且如果你已经在特定的市场中扎根足够长时间，那么你将开始认识到其他熟悉的模式。

历史不会重演,但总是惊人的相似。

回想一下，在RDBMS世界中“三巨头”指的是Oracle、Sybase和Informix时，有一段时间，OODBMS(面向对象的数据库管理系统)是讨论组的新热点。大型数据库管理系统(DBMS)和微软(Microsoft)是Sybase SQL新贵公司，而IBM一直占据着传统地位。IDC和Gartner都将OODBMS作为一个新类别进行了介绍，具有其在面向对象应用程序开发方面的优势，有些讨论的主题是OODBMS是否会完全取代传统的RDBMS。

这张图表概述了过去以十年为单位的数据库系统发展历程。但这并不包括单个供应商在此期间的成败。

数据库管理系统(DBMS)的年度主要分析师报告追踪了微软SQL Server的快速增长，因为它将SQL Server重新塑造成一个以微软为中心的it后台。Sybase和Informix的营销失败和失误最终使它们脱离了Oracle团队。之后，三大巨头成为了甲骨文、微软和IBM，这些公司都拥有庞大的基础和垂直市场，但增长缓慢。

随着这些数据库市场的变化，由于更多的是营销的成功或失败，而不是技术上的优势，领导者在传统的RDBMS产品中采用了OODBMS特性，因此他们可以很容易地适应对数据类型的新需求。纯OODBMS产品又回到了一些特殊应用的小众产品。

从那时起，IBM收购了Informix以进一步整合，而SAP收购了Sybase，主要是为了保护Oracle积极追求SAP ERP客户。作为SAP应用程序的后端，SAP ASE仍然是一个可靠的技术产品，但不太可能再次获得领先的独立RDBMS市场地位。

与此同时,重复战场

让我们试着从定量的角度来看待我前面提到的关于新数据存储产品(如NoSQL)的流行“新热点”。很难衡量“炒作”，但是db-engine站点做的工作和我寻找的一样好。

db-engine站点（https://db-engines/en/ranking）最近的图表显示了各种数据存储产品的趋势。它不是试图衡量收入结果或分析师意见，而是依赖于公开信息、搜索、工作机会、网站提及率等方面的评分。它不衡量具体的因素，如安装或收入，只把排名作为未来成功的早期指标。(关于如何计算和校正分数的更多细节参见db-engine网)

当前的数据库市场格局

解读这个图表和“流行”的趋势是很有启发性的。三个传统的RDBMS引擎是扁平的、不变的和无趣的。在过去的几年里，Oracle、Microsoft SQL Server和MySQL的受欢迎程度并没有太大的变化。但它们都是聚集在一起的，远远超过其他所有条目。我怀疑，如果我们找到了合并收入或实际IT设施的方法，这种分离将会更加明显。

但是增长趋势确实来自NoSQL产品如MongoDB,Cassandra等...

与此同时,重复战场第二季

那么，传统市场分析师对RDBMS供应商的未来有何看法呢?我必须承认，我并没有像微软和甲骨文那样紧密地跟踪它们，因为它们在数据库市场上的地位是显而易见的。他们利用这种领导地位，在应用程序和基础设施中调查邻近的市场。

几年前，Gartner甚至停止了对“RDBMS市场”的报告，转而采用了“操作性数据库管理系统”这一类别。这个新的市场类别包括传统的RDBMS产品和在技术讨论中越来越流行的所有非传统的DBMS。

Gartner Magic quarter展示了Gartner如何根据短期结果以及远景和策略对所有这些供应商进行排名。

在这个Magic Quadrant排名中，首先突出的一点是旧的RDBMS市场领导者也是操作数据库市场领导者。正如预期的那样，在执行能力方面，它们比许多较新的产品要高。但引人注目的是，这两家公司在愿景的完整性方面也远远领先于新的竞争者。现在，这只代表了一家分析公司的一致意见，但他们显然不认为挑战者集团中的任何成员会对大型RDBMS供应商构成直接威胁。为什么?

总结和预测

问题的答案只是我自己的观点，但我的猜测与OODBMS和RDBMS的情况类似。大型供应商逐渐找到了将OODBMS的最佳部分合并在一起的方法，同时为企业维护RDBMS的稳定性。尽管小众应用程序是出于特殊目的而存在的，但很少有应用程序不能被大型RDBMS支持。

预计微软和Oracle将继续通过增加NoSQL和NewSQL优点来减轻RDBMS的局限性，这足以使传统RDBMS的其他事务优势保持大部分市场收入。收购和整合是不可避免的，这两家最有可能通过这种方式巩固市场领导地位。

虽然不同的DBMS产品之间的区别是模糊的，但直到他们犯下重大错误，旧的市场领导者会一直保持这种地位。

操作数据库万岁

请解除任何对NoSQL (NoREL)、NewSQL等新开发项目的怀疑，我并不认为它们是重要的开发，使我们能够超越现有的能力。但我怀疑我们是否会看到新的DBMS市场领导者纯粹来自技术优势。RDBMS市场引领者就是操作数据库市场的引领者。没有看到任何迹象表明这种情况会很快改变。

RDBMS与其说是死了，不如说是重新命名了。

融合已经开始了

求职，都想自己的简历完美，所以，想优化自己的履历，再正常不过。

这其中，写简历时合并工作经历，是最常见的手法，也是潜意识。你的潜意识归潜意识，我们得看在实际中能不能行得通吧？！

合并毕业后2个月空白期

上面这位帅哥，毕业后签了单位刚报到，不想这却是家皮包公司，上班一天他就走人了。俩月后找到了新单位，才开启了自己真正的第一份工作。但他“好面子”，下次跳槽时，简历里面就将这两个月空白期合并进了工作经历之中。你看，这才复试阶段，就后悔了。你说此时，是将简历改回来好，还是将错就错好？

实际上他这还是个学生问法，只有将错就错，或者就直接换一家面试，哪有复试的时候你重新拿一份简历过来，说“我上次面试造假了”？也就是他这家的面试，是没有机会“改回来”的。这又不是学校做题目，做错了还能橡皮擦一下改正，人生和求职，谁给你修正液？

合并考研“二战”那半年

与此类似的，毕业了三年半，但只有三年工作经验，觉得复习考研那半年不好看，合并进履历，将目前公司的入职时间提前了半年多。不过这种情况更加深入，已经面试成功，到了背调阶段。不过想法是一样，都快发Offer了，她要主动通知HR和部门领导，说自己的简历不真实，跟刚刚“改回来”一样，她称之为“打招呼”。

大家也结合自身，你理解下这里“打招呼”的意思，中国是个人情社会，到处需要关系来打招呼，但背景调查是彻底西方化的企业管理制度中的流程，属于人力资源的一个环节。你说“打招呼”有用不？同样仨候选者竞争一个岗位，此时你内部有个大领导关系，这可以打招呼，优先录用你。现在查你的履历真假，HR、部门、背调公司，三者跟你都是陌生人，又不是你家亲戚，你打啥招呼呢？

频繁跳槽怕简历不好看

当然，毕业几年后就会发现，也许自己过去确实跳槽频繁了，别人写两家经历，你时间比别人短却有了四家公司的经历。怕自己尴尬，所以合并简历，类似如上情况，也在“情理”之中。

5年前的工作经历合并

面试结束后，就进入了背景调查和发Offer的阶段。

上面这位，五年前的工作经验合并，情况相对还好一点。不过背调公司是国企中智，这中智本身帮很多公司代缴社保，人力资源和数据库强大，这就不走运了。

下面这位，她也是到了背调阶段，但发现背景调查的套路很深，尽管她只合并了很短的一份工作，但内心忐忑。

因为上上家时间短所以合并简历

也有各种特殊情况，如下这位，他短期工作的两家公司，经历被他合并了。因为俩都创业公司，现在都已经倒闭了，也许背调查不到。

公司倒闭所以合并工作经历

下面这位也是在背调中很担心，此时正是Offer之后，报到之前，已经在准备解释履历合并的质询了。

合并简历后等着背调穿帮

如下这位，腾讯的面试通过了，但他也合并了简历，尽管是9年前的经历。背景调查得看公司，小公司自然没钱，舍不得请第三方背景调查公司。但腾讯可不是穷公司，他富得流油，市值眼看下一步就是上万亿美元。舍不得你这点调查费？只怕腾讯这背调的级别比大外企还要高，一查到底。

腾讯的背调

好的，例子就不再举了，一句话总结：如上简历合并的鲜活案例，他们的工作经历合并，都被查出来了。

回到本文命题，简历上的工作经历能不能合并？最好别合并，除非你下家准备去夫妻老婆店。

对关系数据库进行查询统计时，需要查询到用户感兴趣的数据，这就需要对关系及关系间进行一定的运算。本篇主要讲述关系运算和关系的完整性约束，理解关系操作的含义，了解传统的集合运算，掌握关系代数中基本关系运算。通过本篇的学习，读者应该能掌握以下内容：

● 集合的合并、交集、求差、乘积操作

● 关系运算的选择、投影、连接操作

● 关系的完整性约束

● 关系的范式

关系运算

关系模型是目前用的最多的数据模型，具有严格的数学理论基础，其主要数学理论基础就是集合运算。关系模型提供了一系列操作的定义，这些操作称为关系代数操作。它可分为两类，一类是集合操作；另一类是关系专用的操作。

1、集合操作

集合操作是把关系看作元组的集合来进行传统的集合运算，其运算结果仍是关系，前提是参与运算的两个元组具有相同的结构，即含有相同的属性，且对应属性的值域相同。下面对传统的集合运算合并、交集、求差、乘积运算进行逐一说明。

集合运算——合并

假设有A、B两个集合

A = {1,3,5,9}， B = {2,3,5,7}

由所有属于集合A或属于集合B的元素组成的集合，叫做集合A与集合B的合并，也称为集合A与集合B的并集，记作：

A U B = {1,2,3,5,7,9}

由此可以推出，设R和S是两个关系，则R U S是合并R和S，合并后的结果仍是关系，结果表中的元组或属于R，或属于S，如图2-10所示：

集合运算——交集

假设有A、B两个集合

A = {1,3,5,9}， B = {2,3,5,7}

由所有属于集合A且属于集合B的元素组成的集合，叫做集合A与集合B的交集，记作：

A n B = {3,5}

由此可以推出，设R和S是两个关系，则R n S是R和S的交集，求交后的结果仍是关系，结果表中的元组属于R且属于S，如图2-11所示：

集合运算——求差

假设有A、B两个集合

A = {1,3,5,9}， B = {2,3,5,7}

由所有属于集合A且不属于集合B的元素组成的集合，叫做集合A与集合B的差，记作：

A - B = {1,9}

由此可以推出，设R和S是两个关系，则R - S是求R和S的差，求差后的结果仍是关系，结果表中的元组属于R且不属于S，如图2-12所示：

集合运算——乘积

假设有A、B两个集合

A = {1,3,5}， B = {2,3}

用A中元素为第一元素，B中元素为第二元素构成有序对，所有这样的有序对组成的集合叫做A与B的乘积（笛卡尔乘积），记作：

A X B = {(1,2),(1,3),(3,2),(3,3),(5,2),(5,3)}

由此可以推出，设R和S是两个关系，则R X S是求R和S的笛卡尔乘积，结果表是R和S的结构之连接，即前n个属性来自R，后m个属性来自S，属性个数等于n+m。结果表的值是由R中的每个元组连接S中的每个元组构成元组的集合。如图2-13所示：

2、专门的关系运算

专门的关系运算包括选择、投影、连接和除四种运算。下面介绍常用的三种运算选择、投影和连接。

选择运算

选择运算是单目运算，它从一个关系R中选择出满足给定条件的所有元组，并同R具有相同的结构。图2-14所示为由关系R选出编号为02的老师。

投影运算

投影运算也是单目运算，它从一个关系R所有属性中选择某些指定属性，组成一个新的关系。选择运算选取关系的某些行，而投影运算选取关系的某些列，是从一个关系出发构造其垂直子集的运算。图2-15所示为由关系R中选出所有老师的姓名和简介。

连接运算

连接运算属于二目运算，是从两个关系元组的所有组合中选取满足一定条件的元组，由这些元组形成连接运算的结果关系，其中条件表达式涉及到两个关系中属性的比较，该表达式的取值为真或假。图2-16所示为对课程表和老师表在老师编号相等的条件下进行了连接，在新的关系中仅选出名称、姓名两个属性，即在新关系中再进行一次投影运算，这样得到了所有老师编号为01的课程名称和老师姓名。

关系的完整性

关系模型的完整性主要分为以下四类。

（1）域完整性。关系模型中，每列属性的取值应是域所确定的值。即属性的取值范围应在其值集或值域内。例如在课程表中，名称属性值是汉字或英文字符串，所以不能取出数值来，同时，名称是课程的主要特征，要求必须有课程名称，即名称属性不能为空。

（2）实体完整性。关系模型中每一个表就是一个实体，在现实世界中，实体是可区分的，即它们具有唯一标识。实体映射到关系模型后，每个表也应该具有唯一的标识，这个标识称为主键，用于标识表中唯一的元组。主键不能为空，如果主键为空，则说明存在某个不可标识的实体，而这和唯一标识相矛盾，即不存在这样的实体。

（3）参照完整性。实体完整性是一个表内的约束，参照完整性是在不同表之间或同一表的不同元组之间的约束。例如课程表中的老师编号属性给出了老师的编号，但在课程表中并没有老师的信息，要想得到老师的信息，就必须通过表中的老师编号到老师表中去查找。由于编号在老师表中是主键，这样能够找到唯一的一行与该老师编号相对应。对于老师表中的编号属性来说，通常定义是该表的外关键字，简称外键，同时，编号属性也是老师表的主键。如图2-17所示：

从上图可以看出，课程表中老师编号属性的每一个值都能在老师表中找到唯一的一行元组，即能找到唯一的老师与其对应，则称为参照是完整的，否则，则称为参照不完整的。

（4）用户定义的完整性。用户定义的完整性用于满足用户对数据的语义要求，是由用户对数据库施加的约束条件。例如，课程视频长度不能超过30分钟、老师必须具备专业知识等约束条件。

关系模型的规范化

关系模型的规范化是指面对一个现实问题，如何选择一个比较好的关系模式集合。

当一个关系模式设计的不够规范时，就会出现插入异常、删除异常、冗余过多等问题。例如图2-18学生选课表中，其中编号、姓名属性是表的主键，在实际应用中，该表会存在插入、删除、冗余过多等异常。

（1）插入异常。比如一个刚刚成立的系，但尚未招收学生，则因属性编号、姓名为空，导致系名、系主任等信息无法存入数据库；同样，没被学生选修的课程也无法存入数据库。

（2）删除异常。如一个系的学生毕业了，删除学生记录时会将系主任、系名等信息一起删除。

（3）冗余过多。如一个系的系名、系主任姓名都有与该系学生每门课的成绩出现的次数一样多。既浪费存储空间又要付出很大的代价来维护数据库的完整性。当系主任更换后，必须逐一修改该系学生选修课程的每一个元组。

从上面的例子可以看出，一个好的关系模式不应当发生插入异常和删除异常，且数据冗余尽可能地少。引起数据冗余及其操作异常的原因在于关系的结构。现实世界中的许多事物都可以独立存在、独立地被标识、相互间又密切关联。如果将多个本该是独立存在地、具有不同标识的事物用一个关系描述，那么不可能找到这样一个属性集，它既是这个关系的标识，又是包含在其中的各个不同事物的标识，正是由于关系模式的属性之间存在过多的数据依赖，从而出现了数据冗余和更新的异常。

数据依赖是指关系中属性值之间的相互联系，它是现实世界属性间相互联系的体现，是数据之间的内在联系，是语义的体现。现在人们已经提出了许多种类型的数据依赖，其中最重要的是函数依赖。

函数依赖比较容易理解，且普遍地存在于现实生活中。在学生选课表中，因一个编号仅对应一个学生，一个学生只在一个系注册学习。因而，当编号的值确定后，姓名和所在系的值也就唯一确定了。当关系模式属性间存在这个关系时，我们就说姓名和所在系的值依赖于学号，即编号决定姓名和系名。

在学生选课表中除了姓名和系名依赖编号外，还存在其它数据依赖，如一个系只有一个系主任，因此系名依赖于系主任；再如，每个学生学习一门课都有一个成绩，因此成绩依赖于学号和课程名称。因为学生选课表中数据依赖过多，导致发生更新异常和数据冗余问题。

解决办法是将关系模式分解成若干只有单一数据依赖的关系模式，因为关系模式学生选课表出现异常问题是由于属性之间存在过多的数据依赖造成的，分解的目的就是减少属性间过多的数据依赖，已期消除关系模式中出现的异常。学生选课表关系模式分解成如图2-19所示的三个表。

学生选课表规范化后，分解为学生表、成绩表、系表三个表，解决了关系模式多数据依赖的问题，每个表都是单一的数据依赖。规范化后虽然解决了数据冗余、更新异常的问题，但检索效率明显降低了，需要多表查询。因此，一个关系是否要进行规范化，应当本着具体问题具体分析的原则进行处理。事实上，如果在一个关系上主要执行的是查询操作，未必一定要规范化，通过适当地增加一些关系或者在应用程序中注意到更新一致性的维护，非规范化的弊端是可以避免的。但是，如果在关系上要进行频繁的更新操作，还是要采用规范化的方式比较好。

关系的范式

前面讨论了关系模式没有规范化所引起的异常问题，因此规范化对数据库设计有着重要的意义。所以建立科学的，规范的数据库是需要满足一些约束条件的，在关系型数据库中这些约束条件被称为范式。根据一个关系满足数据依赖程度的不同，人们提出了第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。当然从理论上研究还有其他范式，但实际意义不大，这里不作讨论。

（1）第一范式（1NF）。表中所有的属性都是不可再分的。如学生选课表中系名和系主任就不能合并为一个属性，因为违反了第一范式。当前所有的关系数据库都支持第一范式，即要求表属性都是原子属性，即属性的不可分性。

（2）第二范式（2NF）。要求在满足第一范式的前提下，除去所有不完全依赖于主键的属性（部分依赖）。如学生选课表中，就存在不满足第二范式的问题，系名和系主任属性部分依赖于编号属性（主键），因此存在更新异常、数据冗余的问题。第二范式要求所有非主属性（不属于主键的属性）都完全依赖于主键。

（3）第三范式（3NF）。要求关系在满足第二范式的前提下，除去所有传递依赖于主键的属性，即关系中不含有对主键的传递依赖。传递依赖就是间接依赖。例如在关系R（学号，宿舍，费用）中，费用就间接依赖于学号。

前几天同和君被某粉丝吐槽不务正业，那今天咱们就来务一下正业，来简单讲讲有关SQL Server的基础操作（其实是为了交差）。

有关SQL（结构化查询语言）与其对应的各类数据库管理系统（SQL Server、Access等）的功能与运用范围，在这里就不做赘述了，有兴趣的可以去搜一下，然后你就会发现一个新的世界了~

首先下载安装SQL Server并配置其实例，这方面也不详细说明了，有点电脑基础的都会~然后就是正式的实操环节，首先连接到服务器：

进入后第一件事当然是创建属于自己的数据库啦~

右键「数据库」，选择新建，然后跳出右边的对话框，根据实际需求来设置「文件初始大小」、「文件增长量」、「日志初始大小」、「日志增长量」。

增长方式和文件大小上线可以自定义。

确定后就能看的建立好的数据库了。

试着生成一个有关数据库信息的脚本~

详细sql文件信息如下：

当然你也可以选择使用Transact-SQL语言直接来创建数据库：

先点「新建查询」调出查询分析编译器：

然后输入以下语句：

createdatabase HKSDBonprimary(name=HKSDB_data,filename='d:\File\TEMP\HKSDB_data.mdf',size=20MB,maxsize=500MB,filegrowth=5MB)log on(name=HKSDB_log,filename='d:\File\TEMP\HKSDB_log.mdf',size=20MB,maxsize=100MB,filegrowth=1MB)

右键相应的数据库属性会跳出很多选项：

如果你把数据库的初始值设高了，可以通过收缩来减小：

接着是通过代码来查看&修改数据库属性：

--查看数据库属性sp_dboption HKSDB--查看数据库信息sp_helpdb HKSDB--修改日志文件的最大值和初始值use HKSDBgoalterdatabase HKSDB modifyfile(name=HKSDB_log,maxsize=200MB)alterdatabase HKSDB modifyfile(name=HKSDB_log,size=40MB)--更改数据库use HKSDBalterdatabase HKSDBaddfile(name=HKSDBFZ,filename='D:\File\TEMP\HKSDBFZ.ndf',size=2mb,maxsize=10mb,filegrowth=1mb)alterdatabase HKSDBadd log file(name=HKSDBLOG1,filename='D:\File\TEMP\HKSDBLOG1.ldf',size=2mb,maxsize=10mb,filegrowth=1mb)use HKSDBalterdatabase HKSDBremove file SYDBFZalterdatabase HKSDBremove file HKSDBLOG1如果你对某个数据库不爽，想把它打入冷宫，可以直接右键数据库删除，也可以手动输入代码：

use HKSDBdropdatabase HKSDB似乎碰上了钉子户：

试试大神的代码：

USE MASTER GO DECLARE@dbname SYSNAME SET@dbname='同和君的的数据库'--这个是要删除的数据库库名 DECLARE@s NVARCHAR(1000)DECLARE tb CURSORLOCALFORSELECT s ='kill '+ CAST(spid ASVARCHAR)FROM MASTER..sysprocesses WHERE dbid = DB_ID(@dbname)OPEN tb FETCHNEXTFROM tb INTO@sWHILE @@fetch_status=0BEGINEXEC(@s)FETCHNEXTFROM tb INTO@sENDCLOSE tb DEALLOCATE tb EXEC('drop database ['+@dbname+']')

完美~

好的，那么到这里大家已经大致了解了数据库的定义与管理，接下来带大家起飞了~

手动一个个创建数据表是一件很苦逼的事情，再加上我们还没学到JAVA和SQL Server链接的JDBC技术，所以同和君选择一种取巧的方式：从Excel表格直接导入数据~

选好数据源类型：

选好目标文件后下一步：

然后对目标表的各项数据分别选好类型（其中大多都系统默认好了，局部地区稍微修改下就好，比如学号之类的）：

我们来预览一下~

成功~

然后我们可以开始骚操作了~

不过在此之前，还是先教大家如何备份&还原吧~

接下来是还原，这回我们导入一个不同的~

这个是我用来做多表连接的~详细的后边会讲到~

首先我们来查一下同和君初恋女孩高一的成绩：

然后保存该sql文件：

然后再查一下初中好基友的总分区排名：

再保存下：

然后查一下b站up主@SmartMogician 的黑历史

哟，竟然出现同校同学同名同姓的情况了！

这样的话就能成功筛选了：

没想到当年的语文竟然这么难！

当年的学霸……

这样看可能更直观：

（emmmm……这真的不是招生办的阴谋……）

这样看上去就舒心多了~

很多朋友应该都存在偏科的现象，但在我们的深入研究下，发现事情并不简单：

语文不好的同学不一定数学好，

但数学不好的同学就有可能语文好了……

三倍的人数差还是能说明问题的……

那么以上呢，就给大家详细展示了大多常用查询指令的用法~接下来给大家介绍的是「连接查询」，通过这个就能实现多表之间的查询了。

成绩与排名两个表连接，分析理科总成绩与数学成绩之间的关系：

看样子综合能力好的同学，真的是每一门都不偏科呢！

最后同和君要做一件集大成的骚操作~

首先合并一下数据：

嘿嘿嘿~

我们来看看初中的那些朋友们到了高中后学习状态如何~

唯一能对应上的只有姓名了，结果如下：

换个表试试：

大数据显示，初中成绩好的高中成绩不一定好，但高中成绩好的初中成绩一定不差！

什么？有人想看我的成绩？

抱歉，这两个表里都没有我的名字hhh，成绩好就是可以为所欲srgsrgz

[数据删除]

大家也看到了，现在在某二本混日子的我……(；д；)

所以学习这玩意嘛……哎，不谈了不谈了……

接下来介绍一些增删查改的相关操作：

--增加一条记录insert N校联考 (考号,姓名,班级,学校)values('10001','同和君','一班','社会大学')--求表中各校总分的平均分，并存入一个新的数据库createtable AvgMarks(学校 nvarchar(255),平均分 real)insertinto AvgMarks(学校,平均分)select 学校,AVG([9科总分分数])from N校联考groupby 学校--将「N校联考」中所有「广州市第五中学」的信息更新为「广州五中」update N校联考set 学校='广州五中'where 学校='广州市第五中学'执行结果：

ok，那么就暂且先告一段落吧，基本操作讲完了，下回咱们就讲讲高级操作吧~

鸣谢以上十七所高校提供的成绩信息~

大数据是所涉及的数据量规模巨大到无法通过人工，在合理时间内截取、管理、处理、并整理成为人类所能解读的信息。

大数据时代的到来，在商业、经济、医学及其他领域中，决策将日益基于数据和分析而作出，而并非基于经验和直觉。

医疗领域的大数据是指因为临床或者可以需要收集起来的有关健康或者诊疗的信息。其产生来源于日常诊疗过程，其中的数据都是未加修饰的纯天然数据，没有任何排除纳入标准，是一种普查数据。能直接反应临床疗效。

医疗大数据包括电子病历系统、慢性病及传染病注册登记系统、医疗保险信息系统、出生死亡登记系统等等。对于临床医生最关键的是电子病历系统，该系统包括了人口学特征（性别、年龄）、实验室检查、微生物检测、医嘱、诊疗操作、手术资料和临床转归等信息。

临床研究大体分为干预性研究和观察性研究。

干预性研究，又称随机对照临床试验（RCT），需要主动的、有目的地对受试者进行试验干预，一般有严格的纳入排除标准，采用随机化的方法来最大程度地消除混杂因素的干扰。

目前临床科研面临的困境：RCT与观察性研究两者差别较大，两者干预效应不一致。RCT得出的是一种生物学疗效，这反应了干预手段在严格的实验条件下的生物学作用。这种作用可能很弱或者实际的临床中无法发挥出来，生物学效应不能转化成临床疗效。

但基于大数据的临床研究（BCT）在未来可能成为一种研究的主流方式与RCT形成互补。

大数据的临床研究（BCT）其实属于观察性研究，因此必然存在观察性的缺陷，例如存在较多偏绮、混杂因素难以控制、基线资料不均衡等。如果分析了存在偏绮的数据，得出的结论有可能被夸大，目前尚不存在一种万能的统计学解决方案，但视乎可以通过采用随机效应模型或者bootstrap抽样法在一定程度上提高预测模型的准确度。

如何利用大数据进行临床研究：以MIMIC-II数据库为例

（1）、MIMIC-II数据库全称为重症监护多参数智能检测数据库II。该数据库是对公众开放的免费数据库，主要用于重症医学的各种临床研究。该数据库包含的信息来自于美国波士顿beth israel deaconess medical center。该数据库是不断更新的，已经收集了3万多ICU患者的住院信息。该数据库信息由人口学特征、实验室检查、液体及药物医嘱、病历信息、心电监护、呼吸波形监护、血压、血氧饱和度和护理记录。

（2）、MIMIC-II数据库使用步骤：访问网站physionte.org/mimic2/MIMIC-II --注册账号--通过伦理考试--提交申请--下载数据库--安装虚拟机（linux系统、sql语言）--进行临床研究--选择统计方法--对研究结论进行解释--发表论文。

运用大数据可以进行以下几种类型的研究。

如何凝练出实际可行的临床研究问题，有两种主要方式：

（1）、从数据中找灵感。

（2）、从要研究的内容去找数据。

数据提取之后，选用你熟悉常用统计软件（SAS,STATA,SPSS,R语言）对数据进行分析，以STATA为例对数据进行调研和分析。

使用STATA进行大数据分析时主要包括两个部分，数据处理和统计分析。

数据处理包括：

（1）、数变量的产生，比如希望把年龄变量转化成二分类变量；

（2）、数据核查，比如采用sum模块查看是否存在一些不合逻辑的错误值；

（3）、变量类型的调整，比如有些字符变量转化成数据变量；

（4）、数据库合并，患者的不同信息往往是存储在不同的关联表格中，需要合并，可以使用stata的merge或append命令执行。统计分析在数据处理的基础上进行，一个完好的数据处理前期准备是进行可靠统计分析的基础。

（5）、采用do-file方式进行数据统计可以完整记录数据分析的全过程，这样文章修回或发现统计结果错误的时候可以随时查看调用的命令。

下图是完整的大数据分析流程图

问答环节

1、目前各种指南以及高级别循证医学证据是怎么来的？

答：参考随机对照临床试验及相关的荟萃分析。

2、目前为什么生物学疗效不能转化为临床疗效？

答：（1）、RCT条件下干预措施执行比较严格，其中包括纳入的人群（没有大量的合并症和并发症，是所谓的单病种，这就剔除了大量的混杂因素）。

（2）、RCT有严格的治疗时机，而现实中繁忙的临床工作可能会延误给药时机。

（3）、RCT一般都在大医院进行，其结果无法推广到中小医院。

（4）、RCT只是对20%的患者进行研究，不能把这样的结论去治疗其余80%的患者。

（5）、观察性研究存在选择偏绮、混杂因素难以控制、基线资料不均衡等各种缺点。

在Lighttroom中，目录是一个数据库，用于跟踪照片的位置和有关它们的信息。当您编辑照片并在Lighttroom中向它们添加元数据或关键字时，所有这些更改都存储在目录中。照片文件本身没有被触摸。关于如何在Lighttroom中最佳地处理目录，存在着激烈的争论。有些摄影师说最好有一个主目录。其他人说，最好有多个目录，由客户组织，拍摄或约会(比如每年一次)。

每种方法都有优缺点。当您一直打开和关闭同一目录时，您的文件更有可能被破坏。另一方面，当您想从不同的文件夹访问不同的照片时，拥有多个目录可能会变得复杂，因为您无法在不打开每个目录的情况下搜索多个目录。还有，照明器移动同步只适用于一个目录。那么，如果你现在有几个目录，但只想要一个主目录，你能做什么呢？您可以对Lighttroom中的所有目录进行数据库合并。重要的是你这样做是正确的。您必须导入您的实际目录，而不是您的照片，否则您的虚拟副本和集合将不会被导入。让我们看一下将所有目录合并到一个主目录所需采取的步骤。

识别目录第一步是确定要作为主目录的目录。去照明室菜单(Mac)或编辑菜单(Windows)>目录设置并选择一般标签。这将告诉您当前正在使用的目录的名称。

使用聚光灯(Mac)或搜索(Windows)搜索要包含在主目录中的具有“.lrcat”文件扩展名的其他目录。记下他们的名字和地点。

你可能会从这个搜索中得到很多结果。注意我是如何有几个.zip文件的。这些是备份目录。我还有一些结尾是-2，-3。-4。这些号码扩展是由于升级目录和照明更新。查找同名但没有扩展名的.lrcat文件。检查它被修改的日期。如果这两个文件是在同一天修改的，则可以忽略该文件的扩展名。请注意，您可以将目录从较早版本的Lighttroom经典CC导入到更新的版本中。新的、更新的目录包含与前一个目录和照片相关联的所有元数据。做点清理此时，您可能希望打开您认为要导入的目录，并查看目录中的内容。现在是追踪和重新连接任何丢失的文件的好时机。如果你看下面的“灯光”胶片，你会看到在图片的右上角有一个带有感叹号的方框。如果单击它，您将收到一条消息，说明无法找到原始文件。当您在硬盘上移动文件时，不需要在Lighttroom中进行操作或重新连接，以便Lighttroom可以找到它们，就会发生这种情况。例如，如果您将文件从计算机的硬盘驱动器移动到外部驱动器，则可能会发生这种情况。

如果您希望在库中显示丢失的图像，请现在就花时间连接它们。如果有很多照片丢失，您可能只想链接您已经处理过的图片，并删除未经编辑的照片。

合并目录如果您还没有一个主目录来重要您的其他目录，您将不得不创建一个目录。在我的例子中，我有一个主要目录，在决定切换到有几个目录之前，我已经使用了几年。当我意识到多目录工作流程对我来说并不理想时，我简单地将这个较大的目录重新命名为“主目录”，并将其他较小的目录导入其中。但是，如果您没有一个主目录，则可以启动一个目录并将其用于所有目录。如果您有许多目录，这将需要一些时间，因为您必须合并每个目录单独。若要创建新的主目录，请转到档案菜单和选择新目录。一个盒子会弹出，上面写着用新目录创建文件夹。输入“主目录”，上面写着存为然后撞到创造。

若要导入目录，请转到档案 >从另一个目录导入。

选择要导入主目录的目录。在……下面文件处理选择；添加新的照片目录，不移动。无论您的照片位于内部硬盘还是外部硬盘上，在创建主目录时，您都很可能不想更改它们的位置。

它还会问你关于“改变现有照片”的问题。只有在许多目录中有相同的文件集时，您才需要在这里进行选择。这种情况不太可能发生，因为通常情况下，从给定的照片到一个特定的目录，而不是几个，您的照片很重要。对其他目录重复此步骤，直到将它们全部导入主目录。一旦所有的照片都在一个目录中，你可以做一些组织，例如整理文件夹结构、删除副本或不需要的照片等。

备份每次导入目录时，一定要备份主目录。这样，您将得到您所采取的每一步的备份。如果您犯了一个错误或最终得到了一个意外的合并结果，您不必重新开始，只需恢复到最后一个备份即可。一旦您完成了所有目录的导入，我建议您设置备份计划。选目录设置在照明室标签。在……下面备份目录，选择您想要备份的频率。我个人每次都会支持Lighttroom。我的目录被破坏了好几次。通过每天备份它，我可以轻松地从最近的备份中恢复我的文件，而不会丢失我的任何工作。

总结性本质上，这些步骤是您在合并多个Lighttroom目录时需要采取的步骤。当然，在这样做时，您可能会遇到超出一篇文章所能涵盖的场景或问题。但是，如果您已经相对有组织地导入了您的图像，并且知道在哪里可以找到您的各种目录，那么您应该能够很容易地从硬盘上的所有目录中创建一个主目录。

本文由卧龙会成员低调的人原创

现在AD软件制作使用库文件一般有以下两种方式：

1、绘制器件的原理符号，形成原理图库；绘制器件的封装形式，形成封装库，在绘制原理图的过程中调用器件的原理符号，然后再通过原理符号的属性对其参数进行设定，例如设定参数值，封装形式等信息，这种方式适合单人操作。

2、利用数据库关联的方式进行原理图库和封装库管理的方式，就是通过数据库进行关联原理图库和封装库，然后在原理图库进行调用时，相应的封装，参数值均一同调用，这样对于对于多人合作开发、导出BOM、物料管理、成本统计等都非常的好用。

下面我就通过数据库关联方式来进行原理图库和封装库管理谈下自己的理解，

1、在建立数据库格式的库文件之前必须要将封装库，原理图符号库，数据库文档，数据库链接文档保存到同一个目录下，如图1所示：（本例中以Excel文档为例）

图1

图1 保存在同一个目录下的示意图

2、一般来说，通过数据关联的方式一般有如下步骤：

1）新建一个Excel文档，其中的格式如图2所示。

图2 EXCEL文档格式

其中Library Path（原理图库路径）、Library Ref（原理图标号）、Footprint Path（PCB封装库路径）、Footprint Ref（PCB封装标号）必须建立，不然后面不能正确找到原理图库和封装库，其余的参数根据需要进行增删，比如物料代码、物料名称、价格等，方便查询管理。

2）打开AD软件，新建一个DBLIB文件， 执行“File New Library Database Library ”命令即可，如图3所示。

图3 新建一个DBLIB文件

3）数据库文件建立后，源数据链接框中点击数据选择栏，其中可以导入EXCEL和Access数据文件，此处选择Excel 2007，如图4所示。

图4 选择数据源格式

4）点击“Browse”，弹出“Select Database File”，选择在上面所说的目录中选中Excel文档，如图5所示。

图5 选择Excel文档

5)点击“Connect”，可以看到我们新建项目信息已经被识别，如图6所示。

图6 信息识别图

6）点击“Table Browser”，可以看到填写的器件相关参数，如图7所示。

图7 器件相关参数表

7）保存Dblib文件，至此，数据库链接工作完成，后续的原理图符合库和封装库再续。

文|原创：低调的人

校订：上尉Shonway

前言：

在职场报表中，EXCEL的魔法，可以说无处不在，是一项每个人必须掌握的技能，但是在EXCEL所有的函数之中，有一种函数，称之为【数据库函数】，高效，运行速度快，专门为大数据提供，却很少为人知

收藏+转发，传播知识，是一种美德

函数解释

数据库函数均有三个相同的参数：database、field 和 criteria。这些参数指向数据库函数所使用的工作表区域。其中参数 database 为工作表上包含数据清单的区域。参数 field 为需要汇总的列的标志。参数 criteria 为工作表上包含指定条件的区域。写法为=(database、field，criteria）

本篇主要介绍DGET、dcount、daverage、dmax、dmin 5个函数，套路完全一致。

特别提醒

这是一个让人又爱又恨的函数，爱，是因为这个函数，处理数据高效，快速。

恨，是因为如果不知道原理，会出大问题的

经典应用:

用法1：以关键词开头的处理

当我们在第三个参数，如实例，输入A的时候， 实际上，计算的是以A开头的所有物料的库存DSUM函数，计算以A开头的所有库存的和dcount函数，计算以A开头的物料的个数dmax函数，计算以A开头的物料的库存的最大值dmin函数，计算以A开头的物料的库存的最小daverage函数，计算以A开头的物料的库存的平均值特别提醒，是以A开头，不是单元格值等于A！！！！在第二个参数，我们这里输入的是2，是因为返回的值，在条件区域的第二列，当然我们可以直接输入B2，就是列号也是可以的用法2：不以A为结尾，的符合条件的值，主要为中间，或是首字母为A，如果末尾为A，只要中间有A这个字符，也是符合条件的

用法3：包含A的所有符合条件的个数

用法4：和用法3一样，为包含A的符合条件的个数

用法5：第二个字符为A的符合条件的个数，且字符长度大于等于3，因为一个问号，代表一个字符

用法6：以B开头的符合条件的值，因为没有，所以都为0

用法7：

这里输入的是，先切换到英文，而后输入单引号'，而后输入=A，意思是单元格值完全等于A的符合条件的个数，所以只有一个单元格

用法8：

第二个字符为A，并且长度等于3的符合条件的值的处理

数据库函数，使用方法，就介绍完了.

　　【IT168 技术】导语：根据DB-Engines的统计，过去三年来，图数据库已成为数据库增长最快的类别。而亚马逊进入图数据库市场将使这种增长加速。更重要的是，这为企业增加了更多的选择机会，与所有市场一样，更多的竞争和选择将带来更大的市场和更好的产品，最终，受益的是用户。

　　现在所有主要的数据库玩家都已经加入图形数据库的行列，市场发展的下一阶段将趋于成熟。虽然一些图形数据库已经存在十年以上（如：Neo4j），但是今天的大部分图数据库产品依然可以说都是全新的。图数据库是否引起了你关注？图数据库又是否适合你的应用程序？

　　什么是图数据库？

　　在研究图数据库之前，我们先定义一些术语。什么是图数据库？图数据库用图来存储数据，是最接近高性能的一种用于存储数据的数据结构方式之一。

　　构成一张图的基本元素是节点（点）和关系（线）。节点和关系都可以设置自己的属性。节点经常被用于表示一些实体，但依赖关系也一样可以表示实体。节点之间的关系是图数据库很重要的一部分。通过关系可以找到很多关联的数据，比如节点集合，关系集合以及他们的属性集合。

　　相对于关系数据库中的各种关联表，图形数据库中的关系可以通过关系能够包含属性这一功能来提供更为丰富的关系展现方式。

　　灵活性是推动图数据库流行度激增的关键因素。在过去10年的时间里，对可用性和大规模的相同需求推动了各种NoSQL产品的开发和采用，从图数据库近期的趋势中看，这种走势将继续走强。

　　何时需要图数据库？

　　与任何流行的技术一样，有人可能会将图数据库应用于任何类型的问题上。但了解图数据库擅长的应用领域依然是非常重要的。例如，图数据库通常应用于问题域有：

　　＊ 社交网络；

　　＊ 推荐和个性化；

　　＊ 客户360，包括实体解析（关联多个来源的用户数据）；

　　＊ 欺诈识别；

　　＊ 资产管理；

　　以上的各个应用领域或许与你的应用程序并不匹配，你也可以从以下因素中确定图数据库是否适合你的应用程序：

　　＊ 多对多的关系。Martin Kleppmann在《设计数据密集型应用程序》（O'Reilly）一书中提到，如果问题中频繁的出现多对多关系，建议使用图表，因为关系数据库往往难以有效地处理这些关系。

　　＊ 高价值的关系。经常听到的另一个观点：如果数据元素之间的关系与元素本身一样重要，甚至比元素本身更重要时，则应考虑使用图表。

　　＊ 大规模的低延迟。在应用程序中添加另一个数据库也会增加应用程序的复杂性，图数据库能够比其他类型的数据库更快地处理大型数据集所表示的关系。尤其是在复杂的关系连接查询不再执行，并且没有对查询或关系结构进行额外优化的情况下。

　　使用Gremlin定义图表模式和查询

　　让我们从一个真实的例子来开始了解图数据库。KillrVideo是一个参考应用程序，用于共享和观看为帮助开发人员学习使用DataStax Enterprise而制作的视频，其中包括DataStax Enterprise Graph —— 基于高度可扩展的数据技术（包括Apache Cassandra和Apache Spark）的图数据库。

　　使用Gremlin语言在DataStax Enterprise Graph中描述和交互图表，也是Apache TinkerPop项目的一部分。由于Gremlin的灵活性、可扩展性以及对声明式和命令式查询的支持，被称为描述图遍历的首选语言。Gremlin是基于Groovy语言的。最重要的是，Gremlin得到了DataStax Enterprise Grap等大多数流行图数据库的支持，包括DataStax Enterprise Graph、Neo4j、AWS Neptune和Azure Cosmos DB在内。

　　我们设计了一个推荐算法来识别作为需要输入的数据。该方法类似于给特定户推荐喜爱的视频。我们的目标是在用户与KillrVideo应用程序交互时（即作为OLTP交互）实时生成推荐。

　　为了定义模式，我们确定了由KillrVideo管理的数据的一个子集，这是图所需要的。包括用户、视频、评分和标签，以及可能在算法中引用的这些项目的属性，或者在推荐结果中提供的属性。然后我们在Gremlin中创建了一个如下所示的图表模式：

　　选择将用户、视频和标签建模为顶点，并使用线来确定哪些用户上传了哪些视频，用户给视频的评分以及与每个视频关联的标签。我们将属性分配给在查询中引用或包含在结果中的顶点和线上。DataStax Studio是一种用于在CQL和Gremlin中开发和执行查询的笔记本式开发工具。

　　基于这个模式，我们定义了将数据填充到图中的查询，以及从图中检索数据的查询。以下是生成推荐的图表查询基本流程：确定特定的用户、识别与特定用户喜欢同一类视频的类似用户、选择类似用户喜欢的视频、排除特定用户已经观看过的视频、按照受欢迎程度对这些视频进行排序，并生成结果。

　　到目前为止，在这个遍历中我们已经确定了类似用户。遍历的第二部分采用了类似的用户抓取他们喜欢的一定量的视频，去除特定用户已经观看过的视频，并生成按受欢迎程度排序的结果集。

　　虽然这个遍历看起来很复杂，但这是推荐算法的整个业务逻辑，在这里我们就不详细的介绍这个遍历过程中的每一步了。

　　我们建议使用DataStax Studio或Apache TinkerPop的Gremlin控制台等工具，在代表性数据集上交互式地开发遍历。这使你可以快速迭代并优化遍历。DataStax Studio是一个基于Web的环境，提供了多种方法来将遍历结果可视化为节点和边的网络，如下图所示。

　　将图数据库合并到架构中

　　一旦你设计了图表模式和查询，就可以将图表集成到你的应用程序中。以下是我们将DataStax Enterprise Graph集成到KillrVideo中的方法。 KillrVideo的多层架构由一个Web应用程序组成，该应用程序位于一组管理用户、视频（包括标签）和评级的微服务之上。这些服务利用DataStax Enterprise Graph数据库（基于Apache Cassandra）进行数据存储，并使用CQL访问数据。

　　我们将推荐引擎作为推荐视频服务的一部分实施，如下所示。此服务将生成一个特定用户标识的建议列表。为了实现推荐引擎，我们将上述的Gremlin遍历翻转换为Java代码。

　　这种架构突出了微服务体系结构中的一个常见挑战 —— 需要与多个服务拥有的数据进行交互。如上所示，用于生成推荐的图表依赖于用户管理、视频目录和评分服务的数据。

　　我们通过使用异步消息来保存现有服务的数据所有权。用户管理、视频目录和评分服务在数据更改上发布事件。推荐的视频服务订阅这些事件，并对这些图表进行相应的更新。

　　在Java中实现Gremlin遍历

　　DataStax Java驱动程序提供了一个友好又流畅的API来实现Gremlin与DataStax Enterprise Graph的遍历。API能轻易使在DataStax Studio中创建的基于Groovy的查询转换为Java代码。

　　然后，我们可以通过使用名为DSLs的Gremlin特性（即域名特定语言）来使Java代码更具可读性和可维护性。DSL是Gremlin进入特定领域的延伸。对于KillrVideo，我们创建了一个DSL来扩展与视频域相关的术语的Gremlin遍历实现。KillrVideoTraversalDsl类定义查询操作，例如user（）（它使用提供的UUID定位图中的顶点）和recommendByUserRating（），它根据参数（例如最低等级和请求推荐量）为用户生成推荐。

　　使用DSL将推荐视频服务的实现简化为如下的示例，它创建了一个GraphStatement，然后我们使用DataStax Java Driver执行：

　　使用DSL，可以在可重用函数中隐藏图表交互的一些复杂性，然后根据需要将它们组合起来形成更复杂的遍历。这将允许我们额外的推荐引擎，从user（）方法提供的特定用户顶点开始，允许应用程序在不同的实现之间进行交换。

　　希望通过这篇文章你能了解一些关于图数据库对你的应用程序的意义，以及如何使用Gremlin和DataStax Enterprise Graph。