Navicat 17 不支持 ClickHouse 星型模型自动识别与生成，因其无法解析 MERGE TREE 表引擎、物化视图及逻辑主键，且元数据读取仅限基础结构，缺乏外键、维度/度量语义等关键信息，星型图需完全手动建模与标注。
Navicat 17 本身不支持 ClickHouse 的星型模型自动识别与生成——它无法解析 ClickHouse 的 MERGE TREE 表引擎、物化视图或 ReplacingMergeTree 中的逻辑主键，更不会把 JOIN 查询语义映射为维度关系。所谓“绘制成星型模型图”，本质是手动建模 + 视觉对齐，而非逆向工程自动生成。
为什么 Navicat 的「逆向工程」对 ClickHouse 宽表基本失效
Navicat Data Modeler 对 ClickHouse 的元数据读取仅限于基础表结构（列名、类型、是否允许 NULL），但星型模型依赖的关键信息它拿不到：
- ClickHouse 没有外键约束，
FOREIGN KEY字段在 Navicat 里显示为普通列，自动布局完全无视其语义 - 宽表中常见的维度字段（如
user_id、product_sku、date_id）无类型标记，Navicat 不会将其归类为“维度键” - 事实表中的度量列（如
sales_amount、click_count）没有AGGREGATE FUNCTION或MATERIALIZED标识，Navicat 不做区分 - 物化视图（
MATERIALIZED VIEW）被当作独立表拉入模型，但 Navicat 不理解它和源表的计算依赖关系
手动构建星型图前必须补全的三类元数据
要在 Navicat 画布上让星型结构“看起来合理且可维护”，得先人工注入逻辑层信息：
- 为所有疑似维度字段（如
user_id、region_code）右键 → 「属性」→ 在「注释」栏写明dim: user或dim: geo，后续靠这个快速筛选 - 在事实表中，将度量列（如
revenue、impression）的「数据类型」手动改为Decimal(18,2)或Float64，避免被误判为维度标识符 - 用 Navicat 的「层（Layer）」功能新建两个层：
fact_layer和dim_layer，把对应表拖进去——这是唯一能让「自动布局」分组排版的依据
点击「自动布局」前必须做的清理动作
直接点按钮大概率导致所有表堆在左上角、连线交叉成网。真正起效的操作链是：
- 先关闭所有表的「参照完整性」开关（因为 ClickHouse 没外键，开它反而干扰布局权重计算）
- 右键画布空白处 → 「选择全部」→ 再右键 → 「对齐」→ 选「水平居中对齐」，给所有表一个初始坐标基准
- 分别进入
fact_layer和dim_layer→ 右键层标题 → 「仅显示此层」→ 各自执行一次「自动布局」 - 最后切回「全部显示」，手动微调事实表位置到中央，拖拽维度表呈放射状环绕（Navicat 不支持星型锚点，这步必须手拖）
导出图像时最容易被忽略的逻辑断点
图看起来像星型，不代表建模正确。检查以下三点：
- 某张“维度表”如果没设
PRIMARY KEY（ClickHouse 中常以ORDER BY替代），它在 Navicat 里会显示为无主键表，自动布局可能把它当成临时宽表挤到角落 - 所有维度字段的命名必须统一：比如用户 ID 在事实表叫
user_id，在用户维表就必须叫id或也叫user_id；混用uid/user_key会导致你后期无法在画布上连虚线示意关联 - 别依赖图上的连线表达业务关系——Navicat 不允许为 ClickHouse 表添加虚拟外键线。真要标注，只能用「便签（Note）」工具写文字说明，放在连线旁
星型图在 Navicat 里只是沟通辅助，不是执行蓝图。ClickHouse 的真实星型逻辑，始终藏在 SQL 的 JOIN 条件、物化视图定义和 DICTIONARY 配置里。画完图，务必回到「查询」界面，用实际 SELECT … JOIN 验证字段可关联性——这才是唯一靠谱的校验方式。
