核心是解决多人协作时的修改冲突与一致性问题，需通过Git管理XMI文本格式、分离逻辑/物理模型权限、锁定DBMS版本、禁用自动布局与类型推导、清理元数据干扰项，并明确转模责任与验证机制。

逻辑模型转物理模型时，如何保证多人修改不冲突

核心问题不是“能不能转”，而是“谁改了什么、改对没、别人会不会覆盖”。power designer 本身不带 git 式版本控制，直接共享 .pdm 文件极易产生合并失败——两个同事同时改了同一张表的主键，保存后一方的改动彻底消失，连 diff 都看不到。

• 别用 Windows 共享文件夹直连打开同一个 .pdm 文件；必须每人本地工作，通过外部版本工具管理
• 导出为文本格式再纳入 Git：File → Export → To XML (XMI)，选 XMI 2.1 标准，它可 diff、可 merge，比二进制 .pdm 实用十倍
• 团队约定「逻辑模型」和「物理模型」严格分离：xxx_concept.cdm 和 xxx_logic.lpm 只允许架构师/数据负责人提交；xxx_physical.pdm 由 DBA 或后端开发基于最新 .lpm 单向生成，禁止手工反向编辑

共享图纸里字段类型不一致？先锁死数据库平台和版本

同一个 DECIMAL(10,2) 在 MySQL 8.0 和 Oracle 19c 下含义不同，前者允许负精度，后者会报错；Power Designer 默认按“通用 SQL”映射，一导出就崩。共享图纸前，必须在物理模型属性里明确指定目标 DBMS 及版本，否则所谓“共享”只是假象。

• 建模前统一执行：Database → Change Current DBMS → MySQL 8.0（或你实际用的版本），不能只写“MySQL”
• 检查每个实体的 Code Page 和 Collation 设置，尤其含中文字段的表，MySQL 下漏设 utf8mb4_0900_as_cs 会导致后续 DDL 执行失败
• 禁用自动类型推导：关掉 Tools → Model Options → Physical Data Model → Auto-adjust data types，否则从逻辑模型拖拽生成表时，String 可能被擅自转成 VARCHAR(50)，而业务实际要 VARCHAR(255)

多人协作时，怎么让“关系线”不变成一团乱麻

ER 图里画一条关系线容易，但多人各自添加外键、索引、注释后，图面迅速不可读，更糟的是——图形布局≠逻辑约束。Power Designer 的视图（View）和模型（Model）是分离的，你拖动了连线位置，不等于改了参照完整性规则。

• 关闭自动布局：Format → Enable Auto Layout 取消勾选，否则每次另存都会重排，导致 Git diff 出大量无意义坐标变更
• 所有关键约束（如 ON DELETE CASCADE、CHECK 表达式）必须显式写在 Relationship → Properties → Referential Integrity 里，不能只靠连线样式暗示
• 用 View → Show/Hide → Display Name 统一开启“显示外键名”，避免出现“FK_123”这种无法追溯来源的命名

版本控制对接失败？重点查 .pdm 文件头和自定义扩展属性

Git 提交 .pdm 后，同事拉下来打不开，或者打开后缺字段、少索引——大概率是文件头里嵌了本地路径或临时 GUID。Power Designer 会在模型元数据中写入机器标识、插件扩展信息，这些在协作场景下全是噪音。

• 导出前清理：Tools → Resources → Remove Unused Resources，删掉未引用的域、数据项、模板
• 禁用非标扩展：Tools → Options → General → Disable all add-ins，尤其关掉“Reverse Engineer from JDBC”这类依赖本地驱动的插件
• 物理模型生成后，手动检查 File → Properties → Custom Properties 里有没有 CreatedBy、LastModifiedOn 这类带时间戳或用户名的字段，有就清空——它们每次保存都变，纯属干扰 Git

实际协作中最耗时的从来不是建模本身，而是当三个人同时改了客户表的地址字段、又各自生成了不同版本的建表语句之后，没人知道哪条 DDL 真正反映了当前逻辑模型的约束。所以与其纠结“怎么转”，不如先定死“谁有权转、在哪转、转完立刻验证”。