What Is a Federated Database System?什么是联邦数据库系统?
Place this specific workflow in context with the federated queries and data virtualization guide, which connects the definitions, alternatives, validation steps, and related implementation guides.
可通过联邦查询与数据虚拟化指南理解本专题在整体流程中的位置;该指南串联了定义、替代方案、验证步骤与相关实施文章。
A federated database system, or FDBS, is a database management system that coordinates partial, controlled sharing across autonomous and potentially heterogeneous component database systems. It supplies the management services needed to expose a federated database: catalogs and mappings, source adapters, identity and policy enforcement, query planning and execution, transaction rules, observability, and change control.
联邦数据库系统(FDBS)是一种数据库管理系统,用于在自治且可能异构的组件数据库系统之间协调部分、受控的数据共享。它提供呈现联邦数据库所需的管理服务,包括目录与映射、来源适配器、身份与策略执行、查询规划与执行、事务规则、可观测性及变更控制。
Sheth and Larson’s foundational definition describes an FDBS as cooperating database systems that remain autonomous and may be heterogeneous. “Cooperating” matters: the federation does not merely store connection strings. It defines explicit interfaces through which components publish approved data and accept external operations while preserving local authority over schemas, users, schedules, and failures.
Sheth与Larson的奠基定义把FDBS描述为相互协作、保持自治且可能异构的数据库系统。“协作”十分关键:联邦并非只保存连接字符串,而是定义明确接口,让组件发布获批数据并接受外部操作,同时保留对本地Schema、用户、计划与故障的控制。
The term does not guarantee one implementation. A commercial system may offer a central federated server, a global catalog, wrappers, cost-based optimization, and selected remote writes. Another may be read-only and expose foreign tables. Evaluate named services and behavior rather than assuming that every product labeled “federated” implements the same FDBMS architecture.
该术语并不保证统一实现。某商业系统可能提供中央联邦服务器、全局目录、包装器、基于成本的优化与部分远程写入;另一系统可能只读并暴露外部表。应评估具名服务与实际行为,而不是假定所有标为“federated”的产品都实现相同FDBMS架构。
Federated Database System Architecture联邦数据库系统架构
A practical FDBS can be read as four cooperating planes. Products may combine them in one process, but separating responsibilities exposes missing controls.
实用FDBS可理解为四个协作平面。产品可能把它们合并在一个进程中,但按职责拆分更容易发现控制缺口。
Applications, analysts, drivers, APIs, sessions, and external schemas. It establishes caller identity, purpose, request context, deadlines, and result contract.
应用、分析人员、驱动、API、会话与外部Schema;建立调用者身份、用途、请求上下文、截止时间与结果契约。
Global catalog, schema and function mappings, authorization, query processor, transaction rules, cache policy, audit, and administration.
全局目录、Schema与函数映射、授权、查询处理器、事务规则、缓存策略、审计与管理。
Wrappers, connectors, drivers, server definitions, credentials, type translations, capability discovery, and protocol conversion.
包装器、连接器、驱动、服务器定义、凭据、类型转换、能力发现与协议转换。
Autonomous local DBMSs with local catalogs, users, transactions, optimizers, storage, owners, capacity, security, and release schedules.
自治本地DBMS,拥有本地目录、用户、事务、优化器、存储、所有者、容量、安全与发布计划。
IBM’s product documentation gives one concrete decomposition: clients access a database managed by a federated server; wrappers and the global catalog describe sources and capabilities; nicknames reference remote objects; the optimizer chooses work for sources or the federated server. This is evidence for one implementation, not a universal requirement that every FDBS use IBM names.
IBM产品文档提供了一个具体分解:客户端访问由联邦服务器管理的数据库;包装器与全局目录描述来源及能力;nickname引用远程对象;优化器选择在来源或联邦服务器执行工作。这是某种实现的证据,并不要求所有FDBS都使用IBM命名。
Core Components and Their Responsibilities核心组件及其职责
| Component组件 | Required contract必需契约 | Evidence证据 |
|---|---|---|
| Federated server or coordinator联邦服务器或协调器 | Session, routing, deadlines, resource limits, cancellation and result assembly会话、路由、截止时间、资源限制、取消与结果组合 | Request trace and resource accounting请求追踪与资源核算 |
| Global catalog全局目录 | Sources, objects, mappings, statistics, capabilities, owners and versions来源、对象、映射、统计、能力、所有者与版本 | Versioned metadata and lineage带版本元数据与血缘 |
| Schema mediatorSchema中介 | Export, federated and external mappings with semantic conversions导出、联邦与外部映射及语义转换 | Field-level mapping and contract tests字段级映射与契约测试 |
| Wrapper or connector包装器或连接器 | Authentication, protocol, type and function translation, source operations认证、协议、类型与函数转换、来源操作 | Capability matrix by source version按来源版本记录的能力矩阵 |
| Global query processor全局查询处理器 | Resolution, decomposition, costing, pushdown, compensation and result combination解析、分解、估算、下推、补偿与结果组合 | Explainable plan with rows and bytes带行数与字节的可解释计划 |
| Transaction manager事务管理器 | Read consistency, write scope, commit, recovery, retries and compensation读取一致性、写入范围、提交、恢复、重试与补偿 | Documented semantics and failure tests有文档语义与故障测试 |
| Security and policy service安全与策略服务 | Identity mapping, least privilege, row/column policy, secrets and audit身份映射、最小权限、行列策略、密钥与审计 | End-to-end allow/deny and revocation proof端到端允许/拒绝与撤销证明 |
| Operations plane运维平面 | Health, SLOs, alerts, source protection, change, backup and recovery健康、SLO、告警、来源保护、变更、备份与恢复 | Dashboards, runbooks and drill results仪表盘、运行手册与演练结果 |
A product does not need separate executables for all eight items. It does need an accountable implementation for every promise it makes. If the system claims transparent access but cannot identify who owns mappings, how revocation reaches sources, or where joins execute, the architecture is incomplete for production.
产品不必为八项职责分别运行独立程序,但必须为每项承诺提供可问责实现。如果系统声称透明访问,却无法指出映射所有者、撤销如何到达来源或连接在哪里执行,则其生产架构并不完整。
Identity, Authorization, and Trusted Sharing身份、授权与可信共享
The system must define an identity chain: human or service caller → federated session → connector identity → component-database principal. For every hop, document authentication method, credential owner, secret rotation, token lifetime, impersonation or service-account behavior, row and column filters, purpose restrictions, and audit correlation.
系统必须定义身份链:人员或服务调用者→联邦会话→连接器身份→组件数据库主体。每一跳都应记录认证方式、凭据所有者、密钥轮换、令牌寿命、模拟或服务账户行为、行列过滤、用途限制与审计关联。
Do not assume local permissions remain safe after composition. Two individually permitted datasets can reveal a prohibited fact when joined. A global policy layer may need to control aggregation, inference, export size, and purpose in addition to preserving source-native controls. NIST research on granular sharing across disparate DBMS resources treats security and privacy as first-class federation concerns rather than connector details.
不要假定本地权限在组合后仍然安全。两个分别允许的数据集连接后可能揭示被禁止事实。除保留来源原生控制外,全局策略层可能还需控制聚合、推断、导出规模与用途。NIST关于跨异构DBMS细粒度共享的研究把安全与隐私视为联邦的一等问题,而非连接器细节。
- Test both allow and deny paths through the federation and directly at each component.同时测试经联邦和组件直连的允许与拒绝路径。
- Revoke a principal and measure when every cache, connection pool, and source rejects it.撤销一个主体并测量所有缓存、连接池与来源何时开始拒绝。
- Correlate one request ID from client through coordinator, wrapper, and component audit logs.用一个请求ID关联客户端、协调器、包装器与组件审计日志。
How an FDBS Processes a RequestFDBS如何处理请求
- Establish context.建立上下文。 Authenticate the caller; bind role, purpose, active external schema, deadline, resource class, and result policy.验证调用者,并绑定角色、用途、当前外部Schema、截止时间、资源类别与结果策略。
- Resolve metadata.解析元数据。 Map logical objects and operations through federated and export contracts to component objects, identities, and capabilities.通过联邦与导出契约,把逻辑对象和操作映射到组件对象、身份与能力。
- Validate policy and semantics.验证策略与语义。 Check fields, rows, purposes, types, conversions, freshness, write scope, and incomplete-result rules before planning.规划前检查字段、行、用途、类型、转换、新鲜度、写入范围与不完整结果规则。
- Plan distributed work.规划分布式工作。 Use capabilities, statistics, transfer cost, source load, and deadlines to choose remote and coordinator operations.使用能力、统计、传输成本、来源负载与截止时间选择远端和协调器操作。
- Execute and control.执行并控制。 Submit bounded operations through wrappers, propagate cancellation, enforce limits, combine selected results, and handle retries without duplicating unsafe work.通过包装器提交受限操作,传播取消,执行限制,组合选定结果,并在不重复不安全工作的情况下处理重试。
- Return evidence.返回证据。 Attach provenance, observation times, warnings, partial-failure state, plan identity, and audit correlation to the result.为结果附加来源、观察时间、警告、部分失败状态、计划身份与审计关联。
This lifecycle defines system responsibilities. The next-level details of federated query syntax and algorithms depend on the specific engine and belong to a query-engine evaluation, not to the FDBS label alone.
该生命周期定义系统职责。更深入的联邦查询语法与算法取决于具体引擎,应在查询引擎评估中验证,不能由FDBS标签直接推断。
Transaction Management and Global Consistency事务管理与全局一致性
An FDBS does not automatically make local ACID guarantees global. Read snapshots may be selected at different times. Components can use different isolation levels and concurrency protocols. A coordinator may support remote updates for some sources but not others. Even if every local schedule is serializable, the combined global schedule requires separate reasoning.
FDBS不会自动把本地ACID保证扩展到全局。读取快照可能在不同时间选取,组件可能采用不同隔离级别与并发协议,协调器可能只支持部分来源远程更新。即使每个本地调度都可串行化,组合后的全局调度仍需独立论证。
| Class类别 | Required statement必须说明 | Failure question故障问题 |
|---|---|---|
| Read-only federated request只读联邦请求 | Observation time, isolation, cache age, repeatability, partial-result policy观察时间、隔离、缓存年龄、可重复性、部分结果策略 | Can a source disappear without making the answer visibly incomplete?来源消失时,答案会不会在无提示情况下不完整? |
| Single-source write through federation经联邦的单来源写入 | Owning DBMS, validation, lock, retry, idempotency and returned commit state拥有DBMS、验证、锁、重试、幂等与返回提交状态 | What happens when acknowledgment is lost?确认丢失时会发生什么? |
| Cross-source write跨来源写入 | Participants, commit protocol, recovery, in-doubt handling, compensation and operator参与者、提交协议、恢复、存疑处理、补偿与操作人员 | Can the system prove the state after a partial commit?部分提交后系统能否证明状态? |
Prefer read-only scope initially. Keep critical invariants inside one owning database where possible. Treat two-phase commit, XA, saga, or compensation as explicit architectures with their own compatibility and failure tests—not as implicit benefits of federation.
初期优先采用只读范围。尽可能把关键不变量保留在一个拥有数据库中。把两阶段提交、XA、Saga或补偿视为需要独立兼容性与故障测试的明确架构,而非联邦隐含收益。
Use InfiniSynapse for an Approved Multi-Source Analysis使用InfiniSynapse执行获批多来源分析
InfiniSynapse’s public product page presents direct connections to supported platforms such as Snowflake, Supabase, PostgreSQL, MySQL, MongoDB, SQL Server, Oracle, and ClickHouse, together with multi-source joint analysis without a complex migration. That makes the application a related entry for a bounded analysis after support and authorization are confirmed.
InfiniSynapse公开产品页面展示了对Snowflake、Supabase、PostgreSQL、MySQL、MongoDB、SQL Server、Oracle与ClickHouse等受支持平台的直接连接,以及无需复杂迁移的多来源联合分析。因此,在确认支持与授权后,该应用可作为有边界分析的相关入口。
This guide does not claim that InfiniSynapse is a general federated database management system, federated server, global catalog, schema mediator, query optimizer, distributed transaction manager, connector SDK, policy engine, observability plane, replication system, or warehouse replacement. Those FDBS responsibilities remain with the selected architecture and accountable owners.
本指南不声称InfiniSynapse是通用联邦数据库管理系统、联邦服务器、全局目录、Schema中介、查询优化器、分布式事务管理器、连接器SDK、策略引擎、可观测平面、复制系统或仓库替代品。这些FDBS职责仍属于选定架构及其问责所有者。
Before opening the application, prepare confirmed supported connection details, owner approval, least-privilege credentials, network and certificate requirements, approved views, keys, definitions, observation-time expectations, query scope, result limits, and source-load budgets.
打开应用前,请准备已确认支持的连接信息、所有者批准、最小权限凭据、网络与证书要求、获批视图、键、定义、观察时间预期、查询范围、结果限制与来源负载预算。
When connections, authorization, semantics, keys, freshness, and workload limits are ready, open InfiniSynapse to perform the confirmed multi-source analysis workflow.
当连接、授权、语义、键、新鲜度与负载限制准备就绪后,打开InfiniSynapse执行已确认的多来源分析工作流。
Analyze approved data sources分析获批数据来源Federated Database System FAQ联邦数据库系统常见问题
What is a federated database system?
什么是联邦数据库系统?
A federated database system, or FDBS, is a database management system that coordinates partial and controlled sharing across autonomous, potentially heterogeneous component database systems. It supplies catalogs and mappings, adapters, identity and policy enforcement, query processing, transaction rules, observability, and change control.
联邦数据库系统(FDBS)是一种数据库管理系统,用于在自治且可能异构的组件数据库系统之间协调部分、受控的数据共享。它提供目录与映射、适配器、身份与策略执行、查询处理、事务规则、可观测性及变更控制。
What are the main components of an FDBS?
FDBS的主要组件有哪些?
A practical FDBS needs consumer interfaces, a federated server or coordinator, a global catalog, schema mediation, wrappers or connectors, a global query processor, explicit transaction management, security and policy services, and an operations plane. Products may combine components, but every promised responsibility needs an accountable implementation.
实用FDBS需要使用者接口、联邦服务器或协调器、全局目录、Schema中介、包装器或连接器、全局查询处理器、明确的事务管理、安全与策略服务,以及运维平面。产品可以合并组件,但每项承诺职责都必须有可问责实现。
How does a federated database system work?
联邦数据库系统如何工作?
The system authenticates a caller, resolves logical objects through catalog and schema mappings, checks policy and source capabilities, builds a distributed plan, submits bounded operations through wrappers, combines selected results, and returns provenance, observation times, warnings, partial-failure state, and correlated audit evidence.
系统验证调用者,通过目录与Schema映射解析逻辑对象,检查策略和来源能力,构建分布式计划,经包装器提交受限操作,组合选定结果,并返回来源、观察时间、警告、部分失败状态与关联审计证据。
How is an FDBS different from a distributed DBMS?
FDBS与分布式DBMS有什么区别?
An FDBS coordinates component DBMSs that retain meaningful autonomy and may use different engines, schemas, owners, and lifecycles. A distributed DBMS usually manages one designed database across nodes under one DBMS or coordinated administration. A distributed DBMS can itself participate as an FDBS component.
FDBS协调仍保持有效自治、且可能采用不同引擎、Schema、所有者与生命周期的组件DBMS。分布式DBMS通常在一个DBMS或协调管理下跨节点管理统一设计的数据库。分布式DBMS本身也可成为FDBS组件。
Does an FDBS support writes and distributed transactions?
FDBS支持写入和分布式事务吗?
Not automatically. Support depends on the exact coordinator, wrapper, component DBMS, versions, configuration, and operation. Read snapshots may also differ across sources. Verify write scope, isolation, commit protocol, timeouts, retries, idempotency, in-doubt recovery, and compensation before enabling cross-source changes.
不会自动支持。能力取决于确切的协调器、包装器、组件DBMS、版本、配置与操作;不同来源的读取快照也可能不同。启用跨来源变更前,应验证写入范围、隔离、提交协议、超时、重试、幂等、存疑恢复与补偿。
How do you validate a federated database system for production?
如何对联邦数据库系统进行生产验收?
Trace catalog and schema mappings, reconcile representative results with source-native controls, inspect plans and source load, test allow and deny paths, and inject slow sources, outages, credential expiry, schema drift, cancellation, retries, partial commits, and coordinator restarts. Approve a versioned workload envelope with owners and rollback criteria.
追踪目录与Schema映射,用来源原生控制核对代表性结果,检查计划与来源负载,测试允许和拒绝路径,并注入慢来源、故障、凭据过期、Schema漂移、取消、重试、部分提交与协调器重启。最终批准带版本、具名所有者与回滚标准的工作负载范围。
Official Sources and Verification Notes官方来源与验证说明
- Sheth and Larson’s foundational FDBS definition and system/schema reference architectureSheth与Larson关于FDBS定义及系统/Schema参考架构的奠基论文
- IBM Db2 documentation for clients, federated server, federated database, data sources, and system capabilitiesIBM Db2关于客户端、联邦服务器、联邦数据库、数据源与系统能力的文档
- IBM Db2 documentation for federated query fragments, cost-based alternatives, pushdown, and compensationIBM Db2关于联邦查询片段、成本备选、下推与补偿的文档
- IBM Db2 documentation for federated-server responsibilities and source clientsIBM Db2关于联邦服务器职责与来源客户端的文档
- PostgreSQL current documentation for foreign-data-wrapper planning, pushdown, rechecks, joins, aggregation, and modification boundariesPostgreSQL当前关于FDW规划、下推、重检、连接、聚合与修改边界的文档
- NIST publication on trusted granular sharing across disparate database resourcesNIST关于跨异构数据库资源进行可信细粒度共享的论文
These sources support the formal concepts and concrete implementation examples; they do not establish one universal FDBS feature set. Verify the exact edition, source and version, connector, driver, catalog, query behavior, transaction semantics, identity model, limits, availability, and commercial terms you plan to operate.
这些来源支持形式概念与具体实现示例,但不建立统一FDBS功能集。请针对计划运行的具体版本、来源及版本、连接器、驱动、目录、查询行为、事务语义、身份模型、限制、可用性与商业条款重新验证。
