第二章 数据模型和查询语言

数据模型不仅仅影响软件的编写方式，还影响这我们的解题思路。

多数应用使用层层叠加的数据模型构建。对于每层数据模型的关键问题是：它是如何用低一层数据模型来表示的？

基本思路是：每层通过提供一个明确的数据模型来隐藏更低层次中的复杂性。

• 关系模型与文档模型
  • 关系模型起源商业数据处理：事务处理、批处理（报告、报表）
  • 文档模型：不仅是SQL（Not Only SQL），驱动因素：
    • 大数据集、高吞吐
    • 免费开源
    • 关系数据库不能支持一些特殊的查询
    • 更多动态与表现力的数据模型
  • 对象关系不匹配
    • 对象关系映射（ORM object-relational mapping） 框架可以减少这个转换层所需的样板代码的数量，但是它们不能完全隐藏这两个模型之间的差异
    • 后续的 SQL 标准增加了对结构化数据类型和 XML 数据的支持；这允许将多值数据存储在单行内，并支持在这些文档内查询和索引（当然不支持的只能将数据直接编码比如 JSON 后存入单行，缺点就是通常无法查询这一列）
  • 多对一和多对多的关系
    • 如果用户界面一个自由文字字段输入行业或者区域，一种是存储纯文本，一种是给出标准化列表供选择。后者的优势为：样式统一、避免歧义、易于更新、i18n、更好的搜索支持
    • 存储 ID 还是字符串，这是个 副本 问题
    • 存储 ID 的意义在于 ID 永远不需要改变，而其信息可能会发生变化。去除此类重复信息是数据库 [[ 规范化 ]]（normalization）的关键思想。
    • 但是这种数据进行规范化需要多对一的关系，这和文档模型不太符合。文档数据库对一对多支持通常很弱。
    • 即使程序最初版本是无连接的，但是随着功能的增加，数据会变得更加互联
  • 文档数据库是否在重蹈覆辙？
    • 如何在数据库中更好的表示多对多关系？
    • IBM 信息管理系统（IMS）使用了成为 层次模型（hierarchical model） 的数据模型，和 JSON 类似
    • IMS 能良好的处理一对多，但是很难应对多对多，不支持连接，开发人员需要自己决定是否复制（非规范化）
    • 人们提出 关系模型（relational model） 和 网络模型（network model）
    • 网络模型
    • 关系模型
    • 与文档数据库相比
  • 关系型数据库与文档数据库在今日的对比