主流数据库应用 - (≧∇≦)你又回来了

分布式数据库
分布式数据库（Distributed Database）是指数据物理上分布在网络的不同节点（场地），但逻辑上是一个统一数据库的系统。

核心目标
透明性：对用户隐藏数据分布的细节，像使用单一数据库一样。
可用性与可靠性：通过多副本提高容错能力。
可扩展性：通过增加节点来扩展存储与处理能力。
高性能：数据就近访问，并行处理。

透明性分类
位置透明性：用户无需知道数据存储在哪
复制透明性：用户无需知道数据有几个副本
分片透明性：用户感觉不到数据被分区
事务透明性：分布式事务的执行如同本地事务

为什么叫“透明性”？
分布式数据库设计的最高目标，是让用户在使用时，完全感觉不到“分布”这件事。它追求的不是简单地“把复杂的网络、多节点、数据分片给藏起来”，而是要让这些复杂性在用户的体验层面根本不存在。

分布式数据库的核心准则包括：本地自治、分布透明性（含分片透明、位置透明、复制透明等）、数据独立性、连续操作等。而“依赖中心结点”违背了分布式系统去中心化、高可用的基本原则，因此它不是应遵循的准则，而是需要避免的设计缺陷。

ACID 挑战
在分布式环境下，原子性（A）和一致性（C）的实现需要额外协议。

一致性模型
强一致性：任何时刻所有节点看到的数据一致（如分布式事务）
最终一致性：在一段时间无更新后，所有副本最终一致（如DNS、Cassandra）

主流分布式数据库分类与技术

核心挑战与解决方案

虽然“半连接”本身是关系代数中的一个理论操作，但它在分布式数据库的查询优化中是一个核心且实用的技术。

在分布式数据库中，数据存储在不同的物理节点上。当一个查询需要连接（Join）两个分别位于不同节点上的表时，最直接的（也是性能最差的）方法是：将其中一个完整表通过网络传输到另一个表所在的节点，然后进行连接操作。

问题：传输整个表会产生巨大的网络开销，速度慢、成本高。
解决方案：使用半连接（Semi-Join）进行优化。

半连接在分布式查询优化中的应用原理

目标：减少需要通过网络传输的数据量。
步骤（以查询 “找出所有有订单的客户” 为例，客户表R在节点A，订单表S在节点B）：
投影：在节点B上，从订单表S中投影（Project）出连接键（如客户ID），得到一个很小的键值列表。
传输：只将这个小列表从节点B发送到节点A。
半连接：在节点A上，用这个键值列表对客户表R进行半连接过滤，只选出那些ID在列表中的客户元组。
传输结果：将这些筛选后的、数量大大减少的客户元组从节点A发送回节点B。
最终连接：在节点B上进行最终的完整连接，得到结果。

核心思想：用一次很小的投影数据的传输，换取了避免传输整个大表的开销。半连接在这里充当了一个高效的“过滤器”。

它之所以在分布式数据库中被单独提出来考，是因为：

在分布式环境下，网络传输是最大的性能瓶颈。
假设你要连接两个表 R（在上海）和 S（在北京）：
直接做法：把整个表 R 传到北京做连接 → 传输成本巨大。
聪明做法（用半连接）：
在北京先把 S 中连接键投影出来（得到一个小结果集 K）。
只把 K 传到上海。
在上海用 K 对 R 做半连接，筛选出相关的 R'。
把 R'（远小于 R）传到北京做最终连接。
→ 传输数据量大大减少。
这就是为什么在分布式数据库的考试中会出现半连接 —— 它不是理论游戏，而是解决分布式查询性能的核心优化技术。

形式上，半连接可以通过自然连接和投影操作组合而成：
R⋉S=πR.∗(R⋈S)

在基于 Java 的 Web 电子商务应用中，业务对象（如 JavaBean、EJB 等）通常通过 JDBC API 连接和操作数据库，实现数据持久化。JDBC 提供了与数据库无关的统一访问接口，是 Java EE 体系中的标准数据访问方案。

JDBC：Java 数据库连接，是 Java Web 应用中业务对象访问数据库的标准方式，通过驱动程序与数据库交互，广泛用于电子商务等企业级应用。

COM：组件对象模型，是微软的组件技术，可用于数据库访问（如 ADO），但通常与 Windows 平台绑定，不属于跨平台 Web 应用中的通用数据库访问方式。

CGI：通用网关接口，是 Web 服务器与外部程序交互的早期标准，本身不是数据库访问方式，但 CGI 程序可调用其他接口（如 ODBC）访问数据库。

XML：可扩展标记语言，是一种数据格式或传输协议，并非数据库访问技术。

面向对象数据库（OODB）
把“对象”直接存进数据库，而不是拆成表格。
核心思想
对象即数据：程序中的对象（类实例）可直接存入数据库，无需转换
属性+方法：数据库不仅能存数据，还能存对象的方法（函数）
继承与多态：支持类之间的继承关系，子类自动拥有父类特性

与传统关系数据库对比

关键特性

对象持久化

# 伪代码示例：对象直接存数据库
car = Car("Tesla", "Model 3", 2023)
database.save(car)  # 整个对象直接存

复杂类型支持
可直接存储：数组、列表、集合、嵌套对象
无需拆表：一个对象的所有属性存一起

继承体系

       [Vehicle]
          △
   _______|_______
  |               |
  [Car]           [Truck]
  △               △
  |               |
[ElectricCar]   [HeavyTruck]

数据库自动维护继承关系

对象标识符（OID）
每个对象有唯一ID，类似内存地址，用于快速定位

在面向对象数据模型中，对象实例是实际创建的具体数据实体，属于模型的实例化内容，而非模型本身的抽象组成部分。模型的核心要素包括属性集合、方法集合和消息集合，它们共同定义了对象的结构和行为。因此，对象实例不属于面向对象数据模型的构成要素。

对象-关系模型是关系模型的扩展，引入了面向对象的特性，允许属性具有复杂类型，如嵌套关系、数组、结构体等。这意味着一个表的一列可以包含另一个表（嵌套关系），突破了关系模型第一范式的原子性约束。

关系模型遵循第一范式，要求所有属性必须是原子、不可再分的，不支持嵌套关系。
对象-关系模型明确支持 BLOB（二进制大对象）类型，而传统关系模型最初并不支持 BLOB，它是后来为处理多媒体数据而扩展的。
对象-关系模型是融合了面向对象特征的数据模型，并非“不是数据模型”。