本文主要是介绍数据密集型应用系统设计--第2章 数据模型与查询语言，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、引言
数据模型可能是开发软件最重要的部分,而且还对如何思考待解决的问题都有深远的影响。
大多数应用程序是通过一层一层叠加数据模型来构建的。每一层都面临的关键问题是：如何将其用下一层来表示？
1.作为一名应用程序开发人员，观测现实世界（其中包括人员、组织、货物、行为、资金流动、传感器等），通过对象或数据结构，以及操作这些数据结构的API来对其建模。这些数据结构往往特定于该应用。
2.当需要存储这些数据结构时，可以采用通用数据模型（例如JSON或XML文档、关系数据库中的表或图模型）来表示。
3.数据库工程师接着决定用何种内存、磁盘或网络的字节格式来表示上述JSON/XML/关系／图形数据。数据表示需要支持多种方式的查询、搜索、操作和处理数据。
4.在更下一层，硬件工程师则需要考虑用电流、光脉冲、磁场等来表示字节。
复杂的应用程序可能会有更多的中间层，例如基于API来构建上层 API ，但是基本思想相同：每层都通过提供一个简洁的数据模型来隐藏下层的复杂性。这些抽象机制使得不同的人群可以高效协作
精通一种数据模型都需要很大功夫（试想有多少关于关系数据建模的书籍）。即使只使用一种数据模型且不用担心内部机制，构建软件也很有挑战.本章将介绍一系列用于数据存储和查询的通用数据模型.将比较关系模型、文档模型和一些基于图的数据模型
现在最著名的数据模型可能是SQL ，它基于Edgar Codd于 1970年提出的关系模型［ I]:数据被组织成关系（ relations ），在SQL中称为表（ table ），其中每个关系者J）是元组(tuples ）的无序集合（在SQL 中称为行）。
关系数据库的核心在于商业数据处理， 20世纪60年代和70年代主要运行在大型计算机之上。从今天的角度来看，用例看起来很常见，主要是事务处理（包括输入销售和银行交易、航空公司订票、仓库库存）和批处理（例如客户发票、工资单、报告）。
二、关系模型与文档模型
如何在关系模式中表示简历,整个简历可以通过唯一的标识符 userid来标识。像first name和 lastname这样的字段在每个用户中只出现一次，所以可以将其建模为U sers表中的列。然而，大多数人在他们的职业（职位）中有一个以上的工作，并且可能有多个教育阶段和任意数量的联系信息。用户与这些项目之间存在一对多的关系，可以用多种方式来表示.
在传统的SQL模型（ SQL : 1999之前）中， 最常见的规范化表示是将职位、教育和联系信息放在单独的表中 ， 并二使用外键引用 users表.
之后的SQL标准增加了对结构化数据类型和XML数据的支持。这允许将多值数据存储在单行 内 ，井支持在这些文档中查询和索引。
第三个选项是将工作、教育和联系信息编码为JSON或XML文档，将其存储在数据库的文本列中，并由应用程序解释其结构和内容。对于此方峙，通常不能使用数据库查询该编码列中的值。
对于像简历这样的数据结构，它主要是一个自包含的文档（ document ），因此用JSON表示非常合适， 参见示 17tl2- l 。与 XML相比， JSON的吸引力在于它更简单。 面向文档的数据库（女口MongoDB [9J 、 RethinkDB [ I OJ 、 CouchDB [IIJ和Espresso l121 ）都支持该数据模型.JSON作为数据编码格式也存在问题。缺乏模式常常被认为是一个优势.
如果要在关系模式中读取一份简历，那么要么执行多个查询（通过user id查询每个表），要么在users表及其从属表之间执行混乱的多路联结。而对于ISON表示方毡，所有的相关信息都在一个地方，一次查询就够了。
如果用户界面是可以输入地区或行业的自由文本字段，则将其存储为纯文本字符串更有意义。但是，拥有地理区域和行业的标准化列表，并让用户从下拉列表或自动填充器中进行选择会更有优势.
无论是存储ID还是文本字符串，都涉及内容重复的问题。当使用 ID时，对人类有意义的信息（例如慈善这个词）只存储在一个地方，引用它的所有内容都使用ID (ID只在数据库中有意义）。当直接存储文本时，则使用它的每条记录中都保存了一份这样可读信息。
使用ID的好处是，因为它对人类没有任何直接意义，所以永远不需要直接改变：即使ID标识的信息发生了变化，它也可以保持不变。任何对人类有意义的东西都可能在将来某个时刻发生变更。如果这些信息被复制，那么所有的冗余副本也都需要更新。这会导致更多写入开销，并且存在数据不－致的风险.
数据规范化需要表达多对一的关系（许多人生活在同一地区，许多人在同一行业工作），这并不是很适合文档模型。对于关系数据库，由于支持联结操作，可以很方便地通过ID来引用其他表中的行。
如果数据库本身不支持联结，贝lj必须在应用程序代码中，通过对数据库进行多次查询来模拟联结（对于上述例子，地区和行业的列表很小且一段时间内不太可能发生变化，应用程序可以简单地将它们缓存在内存中。但无论如何，联结的工作其实从数据库转移到了应用层）.
即使应用程序的初始版本非常适合采用无联结的文档模型，但随着应用支持越来越多的功能，数据也变得更加互联一体化。例如，考虑以下我们可能对简历进行的修改或扩充：
组织和学校作为实体，公司名称不是－个字符事，而星一个指向公司实体的链撞；
相比之下，关系模型所做的则是定义了所有数据的格式：关系（表）只是元组（行）的集合，仅此而已。。
数据查询语言
命令式编程语言、关系代数（其中 σ （希腊字母 σ ）是选择操作构，只返回符合条件的那些动物）、sql
对于声明式查询语言（如SQL或关系代数），只需指定所需的数据模式，结果需满足什么条件，以及如何转换数据（例如，排序、分组和聚合），而不需指明如何实现这一目标。数据库系统的查询优化器会决定采用哪些索引和联结，以及用何种顺序来执行查询的各个语句。
声明式查询语言很有吸引力，它比命令式API更加简洁和容易使用。但更重要的是，它对外隐藏了数据库引擎的很多实现细节，这样数据库系统能够在不改变查询语句的情况下提高性能。
声明式语言通常适合于并行执行。现在CPU主要通过增加核，而不是通过比之前更高的时钟频率（31 ］来提升速度。而命令式代码由于指定了特定的执行顺序，很难在多核和多台机器上并行化。声明式语言则对于并行执行更为友好，它们仅指定了结果所满足的模式，而不指定如何得到结果的具体算住。所以如果可以的话，数据库都倾向于采用井行方式实现查询语言。
介绍js操作样式部分--忽略
MapReduce查询（第10章批处理系统--详细介绍）
MapR 巳 duce既不是声明式查询语言，也不是一个完全命令式的查询A凹，而是介于两者之间：查询的逻辑用代码片段来表示，这些代码片段可以被处理框架重复地调用。它主要基于许多函数式编程语言中的map（也称为collect ）和reduce（也称为fold或inject）函数
图状数据模型--不深入
这篇关于数据密集型应用系统设计--第2章 数据模型与查询语言的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
