数据模型与查询语言
多数应用使用层层叠加的数据模型构建。对于每层数据模型的关键问题是：它是如何用低一层数据模型来表示的？例如：
- 作为一名应用开发人员，你观察现实世界（里面有人员，组织，货物，行为，资金流向，传感器等），并采用对象或数据结构，以及操控那些数据结构的API来进行建模。那些结构通常是特定于应用程序的
- 当要存储那些数据结构时，你可以利用通用数据模型来表示它们，如JSON或XML文档，关系数据库中的表、或图模型
- 数据库软件的工程师选定如何以内存、磁盘或网络上的字节来表示JSON/XML/关系/图数据。这类表示形式使数据有可能以各种方式来查询，搜索，操纵和处理
- 在更低的层次上，硬件工程师已经想出了使用电流，光脉冲，磁场或者其他东西来表示字节的方法
一个复杂的应用程序可能会有更多的中间层次，比如基于API的API，不过基本思想仍然是一样的：每个层都通过提供一个明确的数据模型来隐藏更低层次中的复杂性。这些抽象允许不同的人群有效地协作。
关系模型与文档模型
现在最著名的数据模型可能是SQL。它基于Edgar Codd在1970年提出的关系模型：数据被组织成关系（SQL中称作表），其中每个关系是元组（SQL中称作行)的无序集合。
NoSQL的诞生
NoSQL：不仅是SQL（Not Only SQL）
采用NoSQL数据库的背后有几个驱动因素
- 需要比关系数据库更好的可扩展性，包括非常大的数据集或非常高的写入吞吐量
- 相比商业数据库产品，免费和开源软件更受偏爱。
- 关系模型不能很好地支持一些特殊的查询操作
- 受挫于关系模型的限制性，渴望一种更具多动态性与表现力的数据模型
可预见的未来，关系数据库似乎可能会继续与各种非关系数据库一起使用 - 这种想法有时也被称为混合持久化（polyglot persistence）
对象关系不匹配
- 应用程序使用面向对象的语言，需要一个转换层，才能转成 SQL 数据模型：被称为阻抗不匹配
- Hibernate这样的 对象关系映射（ORM object-relational mapping） 框架可以减少这个转换层所需的样板代码的数量，但是它们不能完全隐藏这两个模型之间的差异
- 对于一份简历而言，关系型模型需要一对多（比如工作经历）
传统SQL模型表示简历
-
而表述这样的简历，使用 JSON 是非常合适的。JSON 比多表模式有更好的局部性，可以一次查询出一个用户的所有信息。JSON 其实是一棵树
一对多关系构建了一个树结构
多对一和多对多的关系
- 为什么在 SQL 中，地域和公司都以 ID，而不是字符串进行标识呢？
- 如果数据库不支持链接，那么就需要在应用代码中，对数据库执行多个查询进行模拟。执行连接的工作从数据库被转移到应用程序代码上。
- 哪怕最开始的应用适合无连接的文档模型，但是随着功能添加，数据会变得更加互联
文档数据库是否在重蹈覆辙？
20 世纪 70 年代，最受欢迎的是层次模型（hierarchical model），它与文档数据库使用的JSON模型有一些惊人的相似之处。它将所有数据表示为嵌套在记录中的记录树。虽然能处理一对多的关系，但是很难应对多对多的关系，并且不支持连接。
- 网络模型(最初很受关注，但最终变得冷门)
- 关系模型(它变成了SQL，统治了世界)
- 与文档数据库相比
关系型数据库与文档数据库在今日的对比
- 支持文档数据模型的主要论据是架构灵活性，因局部性而拥有更好的性能，以及对于某些应用程序而言更接近于应用程序使用的数据结构。
- 关系模型通过为连接提供更好的支持以及支持多对一和多对多的关系来反击。
数据查询语言
- 关系模型包含了一种查询数据的新方法：SQL是一种 声明式 查询语言，而IMS和CODASYL使用 命令式 代码来查询数据库。
- 命令式语言：告诉计算机以特定顺序执行某些操作，比如常见的编程语言。
- 声明式查询语言（如SQL或关系代数）：你只需指定所需数据的模式 - 结果必须符合哪些条件，以及如何将数据转换（例如，排序，分组和集合） - 但不是如何实现这一目标。数据库系统的查询优化器决定使用哪些索引和哪些连接方法，以及以何种顺序执行查询的各个部分。
Web上的声明式查询
MapReduce查询
图数据模型
- 多对多关系是不同数据模型之间具有区别性的重要特征。
- 文档模型：适合数据有一对多关系、不存在关系
- 图数据模型：适合多对多关系
- 一个图由两种对象组成：
a. 顶点（vertices）（也称为节点（nodes） 或实体（entities））
b. 边（edges）（ 也称为关系（relationships）或弧 （arcs） ）。 - 举例：社交图谱，网络图谱，公路或铁路网络
- 图数据结构示例（以社交网络为例）
图数据结构示例（框代表顶点，箭头代表边）
- 存储方式：属性图，三元组
网友评论