What Is a Federated Database?什么是联邦数据库？
For the full topic map and the neighboring methods that support this workflow, continue with the federated queries and data virtualization guide.
如需查看完整主题结构以及支撑本流程的相邻方法，请继续阅读联邦查询与数据虚拟化指南。
A federated database is a logical database that exposes selected objects from multiple autonomous, potentially heterogeneous databases through a coordinated view without requiring those databases to become one physical store. Users may query a shared namespace or purpose-specific views; the component databases keep their local data, schemas, engines, owners, and release cycles.
联邦数据库是一种逻辑数据库：它通过协调视图呈现多个自治且可能异构的数据库中的选定对象，而不要求这些数据库合并为一个物理存储。用户可以查询共享命名空间或面向特定用途的视图；组件数据库仍保留本地数据、Schema、引擎、所有者与发布周期。
The word “database” describes the consumer-facing composite, not proof of one storage engine, one snapshot, or one transaction manager. Behind the logical view, a catalog records accessible objects and mappings. A coordinating layer resolves names, asks component databases to perform supported work, and combines results. The foundational Sheth and Larson paper characterizes the participating systems as cooperating, autonomous, and possibly heterogeneous, and analyzes federation from both schema and system viewpoints.
这里的“数据库”描述的是面向使用者的组合对象，并不证明存在一个存储引擎、一个快照或一个事务管理器。逻辑视图背后，目录记录可访问对象与映射；协调层解析名称，请组件数据库执行其支持的工作，再组合结果。Sheth与Larson的奠基论文把参与系统概括为相互协作、保持自治且可能异构，并从Schema与系统两个视角分析联邦。
A useful definition therefore has four tests: more than one component database participates; local control remains meaningful; differences in models or interfaces can be mediated; and users receive a deliberate logical view. A collection of unrelated connection strings is not yet a federated database, while a single physical cluster marketed with “federated” may use the word in a different product-specific sense.
因此，一个实用定义包含四项检验：有多个组件数据库参与；本地控制仍然有效；模型或接口差异可被中介；使用者获得经过设计的逻辑视图。一组互不相关的连接字符串尚不构成联邦数据库；而被产品称作“federated”的单一物理集群，也可能采用不同的专有含义。
Loosely Coupled vs. Tightly Coupled Federated Databases松耦合与紧耦合联邦数据库
Coupling describes how much shared schema and central control the federated database imposes. It is a spectrum, not a vendor badge.
耦合程度描述联邦数据库施加多少共享Schema与中央控制。它是一条连续谱，而不是厂商徽标。
| Dimension维度 | Loosely coupled松耦合 | Tightly coupled紧耦合 |
|---|---|---|
| External view外部视图 | Consumers assemble or receive purpose-specific views使用者组装或获得面向用途的视图 | A governed shared federated schema is maintained维护受治理的共享联邦Schema |
| Semantic consistency语义一致性 | Local or team-scoped; duplication is likely局部或团队范围，容易重复 | Global definitions and keys are actively reconciled主动对齐全局定义与键 |
| Change coordination变更协调 | Lower central coordination, higher consumer burden中央协调较少，使用者负担较高 | Higher governance cost, stronger shared contract治理成本较高，共享契约更强 |
| Best fit适用情况 | Exploration, specialist teams, rapidly changing sources探索、专业团队、快速变化来源 | Repeated cross-domain use with stable common meanings具有稳定共同含义的重复跨域使用 |
A loose model is not inherently immature; it may be the honest choice when domains cannot agree on one meaning. A tight model is not automatically safer; it creates a shared contract that requires versioning, ownership, compatibility rules, and a funded change process. Many organizations use multiple federated schemas: a governed finance view, a flexible research view, and local views for specialist teams.
松耦合并不必然不成熟；当领域无法同意一个含义时，它可能更诚实。紧耦合也不自动更安全；共享契约需要版本、所有权、兼容规则与有资源保障的变更流程。许多组织会使用多个联邦Schema，例如受治理的财务视图、灵活的研究视图，以及专业团队的本地视图。
Federated Database vs. Distributed Database, Warehouse, and Virtual Database联邦数据库与分布式数据库、数据仓库及虚拟数据库
| Pattern模式 | Data placement数据位置 | Control model控制模型 | Best fit适用场景 |
|---|---|---|---|
| Federated database联邦数据库 | Selected data remains in autonomous components选定数据留在自治组件 | Shared logical view over local control本地控制之上的共享逻辑视图 | Cross-domain access when replacement or copying is undesirable不宜替换或复制时的跨域访问 |
| Distributed database分布式数据库 | One designed database distributes data across nodes一个设计统一的数据库把数据分布到节点 | Usually one DBMS and coordinated administration通常由一个DBMS与协调管理控制 | Scale, locality or resilience for one logical service为一个逻辑服务提供扩展、就近或韧性 |
| Sharded database分片数据库 | Partitions follow a shard key or routing rule分区遵循分片键或路由规则 | Shared application and partition design共享应用与分区设计 | Distributing one dataset’s capacity分散一个数据集的容量 |
| Data warehouse数据仓库 | Data is copied and transformed into an analytic store数据被复制并转换到分析存储 | Centralized analytic model and refresh process集中分析模型与刷新过程 | Repeatable history, heavy scans and workload isolation可重复历史、重扫描与负载隔离 |
| Virtual database / data virtualization虚拟数据库／数据虚拟化 | Usually query-time access across databases, files, APIs and services通常在查询时访问数据库、文件、API与服务 | Broader abstraction and delivery layer更广泛的抽象与交付层 | Unified access across many source types跨多种来源类型的统一访问 |
The categories can overlap. A distributed component can participate in a federation; a virtual database may expose a federated database; a warehouse can materialize expensive federated results. Decide at workload level. Small, selective, freshness-sensitive lookups may remain federated, while repeated wide historical scans often belong in a governed copy.
这些类别可以重叠。分布式组件可参与联邦；虚拟数据库可呈现联邦数据库；数据仓库可物化昂贵的联邦结果。应按工作负载决策：小型、选择性强且关注新鲜度的查询可保持联邦访问；重复的大范围历史扫描通常更适合受治理副本。
Federated Database Advantages and Disadvantages联邦数据库的优势与缺点
| Potential advantage潜在优势 | Corresponding cost or limit对应成本或限制 |
|---|---|
| Access data without replacing autonomous systems无需替换自治系统即可访问数据 | Availability and latency now depend on multiple systems and networks可用性与延迟转而依赖多个系统和网络 |
| Reduce unnecessary copies for selective, fresh queries为选择性强的新鲜查询减少不必要副本 | Repeated scans can overload operational sources and move excessive data重复扫描可能压垮业务来源并移动过多数据 |
| Offer common names and reusable views提供通用名称与可复用视图 | Semantic reconciliation, versioning, and stewardship require ongoing work语义对齐、版本与维护需要持续投入 |
| Preserve local ownership and specialized engines保留本地所有权与专用引擎 | Local change can break mappings or alter behavior independently本地变更可独立破坏映射或改变行为 |
| Support incremental cross-domain integration支持渐进式跨域集成 | Loose views can proliferate and produce conflicting definitions松散视图可能泛滥并产生冲突定义 |
The correct comparison is not “copying is bad” versus “federation is modern.” Copies create lag and governance work but can isolate workloads, preserve history, and make reruns repeatable. Federation avoids some copies but adds live dependencies and cross-boundary optimization. A hybrid often minimizes total risk.
正确比较不是“复制不好”与“联邦现代”。副本会产生延迟与治理工作，却能隔离负载、保存历史并使重跑可重复；联邦避免部分复制，却增加实时依赖与跨边界优化。混合方式往往能降低总体风险。
What to Prepare Before Choosing a Federated Database选择联邦数据库前需要准备什么
- Consumer contract: named users, questions, expected fields, latency, concurrency, result size, freshness, and failure tolerance.使用者契约：明确用户、问题、预期字段、延迟、并发、结果规模、新鲜度与故障容忍。
- Component inventory: engine and version, owner, endpoint, network zone, maintenance window, capacity ceiling, and supported access mechanism.组件清单：引擎与版本、所有者、端点、网络区域、维护窗口、容量上限与支持的访问机制。
- Export contracts: approved views, fields, row filters, classifications, keys, units, time zones, null meanings, and change notices.导出契约：获批视图、字段、行过滤、分类、键、单位、时区、空值含义与变更通知。
- Identity path: caller identity, federation identity, source identity, least privilege, secret ownership, revocation, and audit correlation.身份路径：调用者、联邦与来源身份，最小权限、密钥所有权、撤销与审计关联。
- Correctness rules: observation time, isolation, partial results, duplicate keys, conversions, quality thresholds, and reconciliation controls.正确性规则：观察时间、隔离、部分结果、重复键、转换、质量阈值与核对控制。
- Decision alternatives: estimate the same workload with direct access, federation, cache, replication, materialized view, and warehouse patterns.备选决策：用直连、联邦、缓存、复制、物化视图与仓库模式估算相同工作负载。
If owners cannot state keys, semantics, access approval, or safe capacity, the project is not ready for a tighter global schema. Begin with a narrow external view or fix the source contract first.
如果所有者无法说明键、语义、访问批准或安全容量，项目尚不适合更紧密的全局Schema。应先从窄范围外部视图开始，或先修复来源契约。
Federated Database Example: Regional Customer and Order Views联邦数据库示例：区域客户与订单视图
Hypothetical example: a company has an EU PostgreSQL customer database, a US SQL Server customer database, and a MySQL order database. Legal and operations teams do not authorize a full migration. Each owner publishes read-only export views with approved fields, local customer identifiers, currency, region, classification, and an observation timestamp.
假设示例：某公司拥有欧洲PostgreSQL客户数据库、美国SQL Server客户数据库，以及MySQL订单数据库。法务与运营团队不批准完整迁移。各所有者发布只读导出视图，其中包含获批字段、本地客户标识符、币种、地区、分类与观察时间戳。
The organization creates two external schemas over one set of exports. A loosely coupled fraud-research view preserves regional identifiers and lets specialists choose approved matches. A tightly coupled finance view uses a governed customer crosswalk, standard currency rules, versioned revenue definitions, and one set of stable logical names. Both retain provenance and separate observation times; neither claims a simultaneous global snapshot.
组织在同一组导出对象之上创建两个外部Schema。松耦合的欺诈研究视图保留地区标识符，让专家选择获批匹配；紧耦合的财务视图使用受治理的客户对照、标准币种规则、带版本的收入定义与一套稳定逻辑名称。两者都保留来源与独立观察时间，均不声称存在同时的全局快照。
Illustrative limits, not product guarantees: the pilot allows eight concurrent analytical requests, a 30-second deadline, at most 50,000 returned rows, and no remote writes. Load tests show quarter-end scans exceed the order database’s safe envelope, so historical revenue is materialized nightly while current order status remains federated. The architecture is hybrid because the workloads have different needs.
以下限制仅为示例，不是产品保证：试点允许八个并发分析请求、30秒截止时间、最多返回50,000行且禁止远程写入。负载测试表明季末扫描超出订单数据库安全范围，因此历史收入每晚物化，而当前订单状态保持联邦访问。由于工作负载需求不同，最终采用混合架构。
Use InfiniSynapse for a Bounded Multi-Source Analysis使用InfiniSynapse进行有边界的多来源分析
InfiniSynapse’s public product page presents direct connections to supported platforms such as Snowflake, Supabase, PostgreSQL, and MySQL, together with multi-source joint analysis without a complex migration. That makes the application a related entry when the goal is a bounded, authorized analysis over confirmed supported connections.
InfiniSynapse公开产品页面展示了对Snowflake、Supabase、PostgreSQL与MySQL等受支持平台的直接连接，以及无需复杂迁移的多来源联合分析。因此，当目标是在已确认支持的连接之上执行有边界、获授权的分析时，该应用可作为相关入口。
This guide does not claim that InfiniSynapse is a general federated DBMS, global-schema mediator, query-federation server, distributed transaction coordinator, policy engine, replication system, or warehouse replacement. Keep the federated database’s architecture, export contracts, identity, policies, source protection, monitoring, and recovery with the responsible platform and source owners.
本指南不声称InfiniSynapse是通用联邦DBMS、全局Schema中介、查询联邦服务器、分布式事务协调器、策略引擎、复制系统或数据仓库替代品。联邦数据库架构、导出契约、身份、策略、来源保护、监控与恢复仍由负责的平台和来源所有者管理。
Before opening the application, prepare supported connection details, owner approval, least-privilege credentials, required network and certificates, approved views, join keys, definitions, observation-time expectations, query scope, result limits, and source-load budgets. Then use the product only within the confirmed workflow.
打开应用前，请准备受支持连接信息、所有者批准、最小权限凭据、所需网络与证书、获批视图、连接键、定义、观察时间预期、查询范围、结果限制与来源负载预算；随后仅在已确认的工作流内使用产品。
When supported sources, authorization, semantics, keys, freshness, and workload limits are ready, open InfiniSynapse to perform the approved multi-source analysis.
当受支持来源、授权、语义、键、新鲜度与负载限制准备就绪后，打开InfiniSynapse执行获批的多来源分析。
Analyze approved data sources分析获批数据来源Federated Database FAQ联邦数据库常见问题
What is a federated database?
什么是联邦数据库？
A federated database is a logical database that exposes approved objects from multiple autonomous, potentially heterogeneous databases through a coordinated view without requiring those component databases to become one physical store. Each component can retain its local schema, engine, owner, security, and operational lifecycle.
联邦数据库是一种逻辑数据库：它通过协调视图呈现多个自治且可能异构的数据库中的获批对象，而不要求这些组件数据库合并为一个物理存储。各组件可保留本地Schema、引擎、所有者、安全与运维生命周期。
How does a federated database work?
联邦数据库如何工作？
A catalog maps logical objects to approved component export schemas. For each request, a coordinating layer authenticates the caller, resolves names, checks source capabilities and policy, executes eligible work near component databases, combines selected results, and returns provenance, observation times, warnings, and failure status.
目录把逻辑对象映射到获批的组件导出Schema。对每个请求，协调层验证调用者、解析名称、检查来源能力与策略、在组件数据库附近执行符合条件的工作、组合选定结果，并返回来源、观察时间、警告与故障状态。
What is the difference between a federated database and a distributed database?
联邦数据库与分布式数据库有什么区别？
A federated database coordinates databases that retain meaningful autonomy and may use different engines, schemas, owners, and lifecycles. A distributed database usually distributes one designed logical database across nodes under one DBMS or coordinated administration. A distributed database can itself be one component in a federation.
联邦数据库协调仍然保持有效自治、且可能采用不同引擎、Schema、所有者与生命周期的数据库。分布式数据库通常由一个DBMS或协调管理，把一个统一设计的逻辑数据库分布到多个节点。一个分布式数据库本身也可以成为联邦中的组件。
Does a federated database copy data?
联邦数据库会复制数据吗？
Not necessarily. Query-time federation can leave source records in component databases while transferring selected intermediate results. Implementations may also cache or materialize data. Repeated wide scans often justify a replica, warehouse, or materialized view, so the final architecture may be hybrid.
不一定。查询时联邦可让来源记录留在组件数据库中，仅传输选定的中间结果；实现也可能缓存或物化数据。重复的大范围扫描通常适合副本、仓库或物化视图，因此最终架构可能是混合方式。
Does a federated database provide one transaction?
联邦数据库会提供一个统一事务吗？
Not automatically. Components may use different snapshots, isolation levels, clocks, and write capabilities. Verify whether remote writes and commit coordination are supported for the exact source combination. Keep critical invariants in one owning database when possible, and define recovery and compensation before cross-source writes.
不会自动提供。各组件可能采用不同快照、隔离级别、时钟与写入能力。必须针对确切来源组合验证远程写入与提交协调是否受支持。尽可能把关键不变量保留在一个拥有数据库中，并在跨来源写入前定义恢复与补偿。
When should you use a federated database?
什么时候适合使用联邦数据库？
Use one when consumers need selective cross-database access, component owners must retain control, copying or replacing systems is undesirable, source capacity can support live demand, and the team can govern schemas, identity, semantics, observation times, failures, and workload limits. Prefer governed copies for heavy repeatable history or strict common snapshots.
当使用者需要选择性跨库访问、组件所有者必须保留控制、复制或替换系统不可取、来源容量能承受实时需求，且团队能治理Schema、身份、语义、观察时间、故障与负载限制时可以采用。重型可重复历史或严格共同快照更适合受治理副本。
Official Sources and Verification Notes官方来源与验证说明
- Sheth and Larson’s foundational paper on autonomous, heterogeneous federated database systems and reference architectureSheth与Larson关于自治、异构联邦数据库系统及参考架构的奠基论文
- IBM Db2 documentation for a federated database, catalog, wrappers, and distributed request planningIBM Db2关于联邦数据库、目录、包装器与分布式请求规划的文档
- PostgreSQL documentation for foreign servers, user mappings, foreign tables, and foreign-data wrappersPostgreSQL关于外部服务器、用户映射、外部表与外部数据包装器的文档
- MongoDB Atlas Data Federation architecture and federated database instance terminologyMongoDB Atlas Data Federation架构与federated database instance术语
- Databricks documentation for read-only JDBC database federation, foreign catalogs, and pushdownDatabricks关于只读JDBC数据库联邦、外部目录与下推的文档
- Oracle documentation illustrating the distinct “federated distributed database” product meaningOracle文档所展示的不同“federated distributed database”产品含义
These sources support the concepts and illustrate implementation-specific terminology; they do not establish one universal feature set. Verify the exact product edition, source and version, connector, read/write semantics, identity model, limitations, availability behavior, and commercial terms you plan to operate.
这些来源支持相关概念并展示实现专属术语，但不建立统一功能集。请针对计划运行的具体产品版本、来源与版本、连接器、读写语义、身份模型、限制、可用性行为与商业条款重新验证。