简介泛微E9表结构压缩包是面向泛微OA协同办公平台二次开发的数据库结构参考材料适合需要做系统集成、权限优化或数据迁移的开发者与运维人员。压缩包整体约3.67MB虽然资源页未标注具体文件数与类型但根据内容介绍可确定其中包含E9系统各核心业务模块的表结构说明或以SQL脚本、数据库设计文档形式呈现涉及用户信息、流程定义、任务实例、文档管理、权限角色、组织结构、日程管理、通讯录等常用表。已有289人学习下载。借助字段定义、数据类型、主外键关系可以完整还原系统数据模型支撑管理员合理制定权限策略、调整审批流也能帮助开发者对接ERP、HR等外部系统并提升数据迁移和性能调优效率。对于需要深入理解和扩展泛微OA能力的技术团队这份资料具有很高的参考价值。1. 泛微OA E9表结构.zip先弄清楚里面装了什么再动手泛微OA E9表结构.zip 是不少实施、二开和运维同事收到后容易“光速翻车”的文件包。解压之后你大概率看到一堆 .sql 脚本或者几个按数据库类型区分的目录部分包里还附带 HTML/Excel 版本的数据字典说明文档。这些内容描述的是 E9 产品运行所需的全部数据库表结构流程引擎相关表、组织人事表、系统配置表、表单数据物理表。它的作用有且只有两个一是在全新数据库里把 E9 的表建出来二是给二次开发和报表开发当“数据地图”让你知道某条流程数据到底落在哪张表、哪个字段上。做实施布库、接口对接、数据迁移、BI 取数的人都绕不开它。这篇笔记只讲一件事拿到这份表结构包之后怎么把它用得明明白白少走弯路。这里有个反直觉的坑这份 zip 往往不是一份“总表”而是多个数据库版本脚本的集合直接全量执行大概率报错或者执行成功却不知道该查哪张表。后面章节会按“确认版本 → 导入建库 → 读懂核心表 → 写实战 SQL → 避坑 → 沉淀字典”的顺序展开适合已经有 E9 环境、或者刚收到这份 zip 的从业者照着复现。2. E9表结构包落地选对数据库版本把建表脚本变成能查的库2.1 先确认E9版本和数据库类型这份zip最容易被误用的地方泛微 E9 本身可以在多种数据库上跑实际项目里最常见的是 SQL Server、Oracle 和 MySQL 三类部分政企项目还会用国产数据库适配版本。表结构包通常也会按数据库类型拆成不同脚本但命名规则并不统一有的叫“SQLServer目录”“Oracle目录”有的只是在文件名后缀上区分还有的干脆全部平铺在一个文件夹里。你不先确认数据库类型就直接执行脚本第一个报错往往就是语法不兼容。我的习惯是解压后先别急着导入花三分钟做两件事。第一看有没有 readme、说明.txt 或者按库拆分的子目录。E9 实际部署时不只是“一个库”主库、日志库、第三方集成库有时候是分开的表结构包如果按库拆分文件命名里一般能看出来例如带 log、integration、ecology 等字样。别把日志库的脚本执行到主库里。第二如果命名不清晰随机打开一个 .sql 文件看语法特征。SQL Server 脚本里会出现[dbo].[ec_workflow_requestbase]这种方括号写法Oracle 脚本里会大量出现TABLESPACE、COMMENT ON COLUMNMySQL 脚本则使用反引号包裹表名和字段名。只看文件头几行就能判断出来。确认好之后再决定到底用哪一个脚本。常见做法是优先选择和目标库完全匹配的版本而不是“先跑起来再说”。某公司当初把 SQL Server 版本的脚本执行到 MySQL 库里光修字段类型就花了两天后面报表还是对不上。2.2 以SQL Server为例执行建表脚本最小操作步骤以最常见的 SQL Server 环境为例整个导入过程并不复杂但有几个顺序上的讲究。假设你已经把 zip 解压到D:\E9_Scripts里面是一个完整的建表脚本或者多个按序号排列的脚本文件。第一步在 SQL Server 里新建一个数据库命名建议直接叫ecology或者按项目规范来排序规则选择Chinese_PRC_CI_AS避免日后查中文出现乱码排序问题。第二步在 SSMS 中打开主脚本文件执行。如果脚本是按序号拆分的按顺序逐个执行不能跳跃。脚本执行时间取决于机器性能几百张表通常几分钟内能跑完。第三步如果你更习惯命令行用 sqlcmd 也可以命令示例如下sqlcmd -S . -d ecology -E -i D:\E9_Scripts\01_create_tables.sql -b-S .表示连接本机默认实例-d ecology指定目标数据库-E使用 Windows 身份认证-i指定要执行的脚本文件-b的作用是遇到错误就终止执行并返回非零退出码。这个-b参数很重要默认情况下 sqlcmd 碰到报错会继续往下跑最后你根本不知道哪些表建成功了哪些失败了。加-b后脚本在第一条错误处停下来便于定位问题。执行完成后不要直接开始写业务查询先做一轮自查见下一节。2.3 导入完成后先自查三件事表数量、主键、说明注释脚本执行完不代表一切正常我一般会在库里跑三条 SQL把“建表是否完整”这件事量化确认一下。第一条查表数量看核心前缀表是否齐全SELECT COUNT(*) AS ec表数量 FROM sys.tables WHERE name LIKE ec\_% ESCAPE \; SELECT COUNT(*) AS hrm表数量 FROM sys.tables WHERE name LIKE hrm%;ESCAPE \是为了让\_被当成普通下划线而不是通配符否则ec_会被理解成“ec 开头、任意字符、任意长度”统计结果会偏大。如果你期望看到的数量和实际数量差距很大说明脚本没跑全先回到执行环节排查。第二条验证最关键的表是否存在。SELECT OBJECT_ID(ec_workflow_requestbase) AS 流程主表对象ID, OBJECT_ID(hrmresource) AS 人员表对象ID;返回NULL说明表没有建成功返回数字说明对象存在。这一步是给后续章节的实战查询打底。第三条检查字段说明注释是否存在。SELECT TOP 10 t.name AS 表名, c.name AS 字段名, ep.value AS 注释 FROM sys.tables t JOIN sys.columns c ON t.object_id c.object_id LEFT JOIN sys.extended_properties ep ON ep.major_id c.object_id AND ep.minor_id c.column_id AND ep.name MS_Description WHERE t.name ec_workflow_requestbase;如果注释列大面积是 NULL说明这份表结构 zip 是“纯建表脚本”字段说明可能在配套的 HTML/Excel 数据字典文档里需要另外打开文档看。这不是导入失败只是信息来源不同别慌。3. 读懂E9表结构主干流程数据是怎么从发起查到明细的3.1 流程实例主表ec_workflow_requestbase 先背熟进入 E9 表结构之后最先要建立的概念是“一条流程在数据库里长什么样”。你发起一个合同审批数据库里并不是只在一个表里插一条记录而是至少要在流程主表里写一条“流程实例”记录再往表单对应的物理表里写业务数据。这个“流程实例”记录就存在ec_workflow_requestbase里。这张表里最常见的字段有requestid流程实例 ID主键、requestname流程标题就是你发起时填的主题、workflowid关联流程定义表workflow_base用来知道你走的是哪个流程、creater发起人 ID关联hrmresource、createdate发起时间注意是字符串还是日期时间类型E9 里常见是字符串格式、status流程状态但不同版本取值含义有差异后面避坑章节会细说。你可以先跑一条最简单的 SQL 感受一下这张表的内容SELECT TOP 20 requestid, requestname, workflowid, creater, createdate, status FROM ec_workflow_requestbase ORDER BY requestid DESC;刚执行完建表脚本的库是空的这条 SQL 会返回 0 行这是正常的。它的意义是让你熟悉字段名和字段顺序等到联调环境有真实数据后再跑你就能立刻把“流程标题”“发起人”“发起日期”和业务数据对应起来。理解这张表之后后续所有“查流程数据”的需求都会以它为起点再通过workflowid拿到流程名、通过creater拿到发起人信息。这张表是整个 E9 表结构里你花时间最值得的一张表。3.2 组织与人员hrmresource 及周边表为什么永远是核心如果说ec_workflow_requestbase是流程数据的主干那么hrmresource就是所有“人”信息的唯一权威来源。E9 里几乎所有跟人相关的字段最终都通过一个数字 ID 关联到这张表上。hrmresource的关键字段包括id人员 ID其他表里的人字段都是拿这个 ID 做关联、loginid登录账号也就是你登录 OA 时输的那个、lastname姓名泛微历史版本一直用这个字段名而不是username、departmentid部门 ID关联hrmdepartment、subcompanyid1分部/公司 ID多分部架构下用来区分人员属于哪个公司。配套的两张表也建议一起记住hrmdepartment存部门信息核心字段是id和departmentname通过supdepartmentid可以上下级递归hrm_subcompany存公司/分部信息核心字段是id和subcompanyname。实际看表结构时你会发现人员表和部门表在设计上并不复杂但有个细节会让很多人踩坑离职人员不会从hrmresource里物理删除而是通过状态字段或离职时间字段标记。所以写统计类 SQL 时一定要根据项目实际确认“有效人员”的过滤条件不能默认表里所有人都是在职状态。验证这张表的数据也很简单SELECT TOP 5 id, loginid, lastname, departmentid, subcompanyid1 FROM hrmresource;有数据的环境下你会看到loginid里有类似zhangsan、wangwu这样的账号但有些项目会带域前缀或工号后缀写查询时要注意匹配方式后面实战章节会专门提到。3.3 自定义建模表uf_前缀标准包查不到的动态表标准表结构 zip 里能覆盖流程引擎、组织架构、系统配置但覆盖不了一个东西客户在实施过程中用 E9 建模引擎自建的业务表。这些表才是真正存放“合同台账”“项目信息”“报销明细”的地方。E9 的建模引擎在创建业务对象时会在数据库里生成对应的物理表。很多项目里这些表名以uf_开头后面跟业务对象的标识例如uf_contract_main、uf_contract_detail也有实施团队自定义前缀的比如bill_、biz_。前缀本身不是固定的这和项目初始化时的建模配置有关。你如果翻遍表结构 zip 没找到uf_开头的表是正常的因为这份 zip 是标准产品表结构不包括客户现场后建的建模物理表。那么实际项目中怎么发现这些表直接在库里搜SELECT name AS 表名, create_date AS 创建时间 FROM sys.tables WHERE name LIKE uf\_% ESCAPE \ OR name LIKE bill\_% ESCAPE \ ORDER BY create_date;找到之后重点关注两件事。第一表里有没有requestid或docid这类字段。建模表和流程关联时系统通常会写入这些字段作为与ec_workflow_requestbase的关联键有它们才能把流程实例和业务数据串起来。第二主表和明细表的关系。主表一条记录对应流程一张主表单明细表通过主表 ID 关联多条明细记录。这部分没有统一答案每张建模表都不一样只能靠“先看表结构、再对数据”的方式摸。好在表名本身通常有业务含义配合字段名的中文注释十分钟内能大致判断出来。4. 用E9表结构写实战SQL从库表到业务数据的两种典型查询4.1 查询某人员发起的流程及当前状态现在把前面的表串起来。最常见的需求是给我查某个用户发起了哪些流程现在走到哪个节点流程叫什么名字什么时候发起的。这是一个三表关联查询ec_workflow_requestbase关联hrmresource拿发起人姓名再关联workflow_base拿流程名称。SELECT wr.requestid AS 流程实例ID, wr.requestname AS 流程标题, wb.workflowname AS 流程名称, hr.lastname AS 发起人, wr.createdate AS 发起时间, wr.status AS 流程状态 FROM ec_workflow_requestbase wr JOIN hrmresource hr ON wr.creater hr.id JOIN workflow_base wb ON wr.workflowid wb.workflowid WHERE hr.loginid zhangsan ORDER BY wr.createdate DESC;JOIN hrmresource hr ON wr.creater hr.id是人员关联的标准写法creater存的是hrmresource.id不是loginid这一步别搞反。workflow_base是流程定义表workflowname就是在 OA 后台“流程引擎”里配置的流程名称。有个实际查询里的细节loginid的匹配不一定总能用等号。有些项目做域集成后人员登录名会变成DOMAIN\zhangsan这类带前缀的格式有的还区分大小写。我一般会先用LIKE探一下数据长什么样SELECT TOP 20 loginid, lastname FROM hrmresource WHERE loginid LIKE %zhangsan%;如果返回多条记录再决定用等号还是模糊匹配。这个探路动作能省不少排查时间。4.2 主表关联建模物理表带明细的关键代码第二条典型需求是查流程里的业务数据比如“合同审批通过后合同编号和合同金额在哪张表里”。这类查询要从ec_workflow_requestbase关联到建模物理表但建模物理表不是标准表关联字段要现场确认。假设你已经通过第 3.3 节的方式找到了合同主表uf_contract_main并且确认它里面有requestid字段那么查询可以这样写SELECT wr.requestname AS 流程标题, hr.lastname AS 申请人, uf.contract_no AS 合同编号, uf.amount AS 合同金额, uf.sign_date AS 签订日期 FROM ec_workflow_requestbase wr JOIN hrmresource hr ON wr.creater hr.id LEFT JOIN uf_contract_main uf ON uf.requestid wr.requestid WHERE wr.workflowid 123 AND uf.amount 100000 ORDER BY wr.createdate DESC;这里我用的是LEFT JOIN而不是INNER JOIN原因是建模物理表里的requestid不一定每条都回填成功尤其在流程尚未结束或者表单被退回重填的情况下INNER JOIN会把数据悄悄丢掉而LEFT JOIN至少能让你发现哪些流程没有关联上业务数据。WHERE wr.workflowid 123这个条件需要你先在 OA 后台或者workflow_base表里确认流程对应的workflowid。不同环境的流程 ID 不一样别把这个值写死到文档里当通用答案。如果业务表还有明细比如一张合同对应多笔付款计划明细表通常是uf_contract_payplan里面会有主表 ID 字段再用主表 ID 关联明细表即可。流程模式下明细表里一般还会带requestid或主表外键具体用哪一个同样以现场表结构为准。4.3 E9常用表速查一张表记住核心入口为了让你在拿到其他表结构包时不至于迷失这里按业务域整理一份常用表速查。这不是完整清单但覆盖了八成以上日常查询会用到的入口。表名业务含义核心字段ec_workflow_requestbase流程实例主表requestid, requestname, workflowid, creater, createdateworkflow_base流程定义表workflowid, workflownameworkflow_nodebase流程节点定义表nodeid, workflowid, nodenamehrmresource人员表id, loginid, lastname, departmentid, subcompanyid1hrmdepartment部门表id, departmentname, supdepartmentidhrm_subcompany分部/公司表id, subcompanynameec_workflow_requestdoc流程文档记录表requestid, docid, workflowiduf_% / bill_% 表建模引擎生成的业务物理表含 requestid 或主表外键 业务字段ec_workflow_requestdoc这张表要特别提一下它保存的是流程和表单文档的关联记录不代表所有业务字段都存里面。表单的业务字段大概率存在建模物理表里所以查业务数据时优先找建模表而不是在 requestdoc 里翻字段。这正好引出下一章的避坑内容。5. E9表结构展开后的常见问题与避坑每一条都是真踩过的5.1 现象全量执行脚本报“对象已存在”拿到 zip 之后最容易犯的错就是把所有脚本一股脑执行。报错通常是这样执行到某个CREATE VIEW或CREATE INDEX时提示“数据库中已存在名为 xxx 的对象”。原因主要有两个一是脚本里有重复定义同一个视图或索引在多个文件里出现二是把两套数据库版本的脚本混在同一个库里执行了SQL Server 脚本执行完又跑去执行 Oracle 脚本低版本对象和高版本对象互相冲突。解决方法是执行前先做版本隔离确认当前库里只跑一套目标数据库的脚本。用 sqlcmd 加-b参数执行遇到第一个错误就停下来先查sys.objects看冲突对象属于哪个脚本再决定跳过还是重建。不要用“出错继续”的模式跑完整套脚本最后你得到的库到底缺了多少张表你根本不知道。5.2 现象查流程表单发现字段值对不上你按标准表的思路去查某个流程的表单数据结果发现ec_workflow_requestdoc里只有requestid、docid这些关联字段真正想要的“报销金额”“出差城市”一个都找不到。这是对 E9 存储机制理解偏差导致的典型困惑。原因在于 E9 的表单数据存储分好几种流程自带的系统表单、HTML 自定义表单、建模引擎生成的业务表它们的字段落库位置不一样。很多自定义表单的业务字段直接落在建模物理表里ec_workflow_requestdoc只是文档关联记录。解决方法是先确认这张流程表单对应的物理表再去物理表里查字段而不是在 requestdoc 里大海捞针。定位方法前面章节已经说过按uf_、bill_前缀搜表或者看表名和表单标识的对应关系。5.3 现象需要的表在zip里根本不存在翻遍了整个表结构包也没找到客户提到的“项目台账表”“合同付款计划表”。这不代表表结构包不完整而是标准产品表结构包本来就不包含实施阶段建模生成的业务表。真实项目里客户的自定义业务对象都是在 E9 后台通过建模引擎创建的创建时系统在数据库里生成物理表这些表只存在于客户的实际业务库中不会进到产品自带的表结构 zip 里。解决方法是直接连上目标库用查询系统表的方式把现有业务表导出来例如前面写过的WHERE name LIKE uf\_% ESCAPE \再按实际表结构梳理。如果你需要一份“完整表结构”给第三方做接口应该从目标库反向导出而不是依赖产品自带 zip。5.4 现象表注释为空数据字典“像是没导入”跑完建表脚本后用系统表查字段注释发现全是 NULL。这不一定是导入失败而是这份 zip 里的脚本本身没有提取注释。SQL Server 的字段说明存放在扩展属性MS_Description里如果生成脚本时没有把扩展属性一起导出你就算重新执行一百遍也不会有注释。解决方法是分两步走。先找 zip 里有没有配套的 HTML 或 Excel 数据字典文档泛微实施资料里常见这种文档格式字段说明以文档形式存在。如果文档也没有就自己动手生成一份字典方法见下一章。这个坑的实质是“注释在脚本里还是脚本外”的信息差别跟导入是否成功混为一谈。5.5 现象流程状态字段 status 的含义和你猜的不一样写流程查询时很多人会直接按网上流传的“0 表示审批中1 表示已完成”来写过滤条件结果数据对不上。ec_workflow_requestbase.status的取值在不同 E9 版本、不同项目配置里是有差异的有的项目里 0 表示已提交有的项目里 0 反而是已删除。原因在于 E9 的流程状态本身是枚举值不同版本演进中做过调整而 zip 里的注释脚本如果没更新这个字段的说明就是过时的。解决办法很简单先看库里真实数据的分布再定过滤条件。SELECT status, COUNT(*) AS 数量 FROM ec_workflow_requestbase GROUP BY status;把每类状态的数据量列出来再结合 OA 界面上看到的具体流程状态去对照反推每档数字的含义。不要猜不要套网上答案以现场数据为准。6. 把E9表结构包变成团队数据字典两级沉淀6.1 用系统视图批量导出字段说明表结构 zip 的价值不该止于“建一次库”。我更推荐的做法是拿到脚本后顺手跑一段导出的 SQL把表名、字段名、类型、注释批量导成一张可检索的表或者 Excel 文件作为团队的数据字典底稿。下面这是 SQL Server 版本SELECT t.name AS 表名, c.name AS 字段名, tp.name AS 数据类型, c.max_length AS 长度, CAST(ep.value AS NVARCHAR(500)) AS 字段说明 FROM sys.tables t JOIN sys.columns c ON t.object_id c.object_id JOIN sys.types tp ON c.user_type_id tp.user_type_id LEFT JOIN sys.extended_properties ep ON ep.major_id c.object_id AND ep.minor_id c.column_id AND ep.name MS_Description WHERE t.name LIKE ec\_% ESCAPE \ OR t.name LIKE hrm% OR t.name LIKE workflow% ORDER BY t.name, c.column_id;max_length对nvarchar类型返回的是字节数实际字符容量要除以 2这一点看结果时注意换算。ep.value为 NULL 的字段说明脚本里没有注释需要人工补充。跑完后把结果复制到 Excel按表名分组慢慢补业务含义这份文件就是项目里的活字典。6.2 维护一张“表名-业务含义”速查笔记导出字典之后再维护一张轻量的速查表只记录核心表名和业务含义不用涉及字段级细节方便新同事快速上手。比如表名业务含义备注ec_workflow_requestbase流程实例主表一切流程查询的起点hrmresource人员表离职人员不物理删除uf_contract_main合同主表示例建模生成requestid 关联流程workflow_base流程定义表拿流程名称靠它这张表放在团队文档库里每次遇到新的建模业务表就追加一行半年后它就是项目里最值钱的表结构文档。我自己的习惯是每接一个新 E9 项目先花半天把字典导出来、把速查表建起来再开始写业务 SQL。这样后面每一次查询都是在查字典而不是反复翻脚本盲猜少走很多弯路。希望帮到你。本文还有配套的精品资源点击获取