简介：本资源是致远OA V8.1官方版本配套的结构化数据字典PDF文档，面向OA系统二次开发人员、数据库管理员及低代码平台集成工程师，用于快速掌握核心业务表结构与字段语义，解决开发对接中因字段含义不清、类型不明确导致的接口异常、数据映射错误等问题。文档以ADDRESSBOOK等关键表为范例，完整呈现主键约束、必填标识、扩展字段分组（文本/数字/日期/枚举/选人/选部门/选岗位共7类）及业务注释，覆盖50+扩展属性的设计逻辑与使用边界。资源为单文件PDF格式，大小2.2MB，轻量易读，适合作为开发手册随查随用。目前已有2606人学习下载，可直接用于数据库建模参考、SQL脚本编写、流程引擎字段绑定及系统升级兼容性分析，显著提升致远OA定制化开发效率与数据治理规范性。
1. 致远OA V8.1 数据字典：不是说明书，而是你和系统之间的“普通话词典”
想象一下，你刚接手一个老同事留下的OA系统——界面熟悉，流程能跑，但一打开数据库，满屏都是ADDRESSBOOK_SET_SCOPE、AI_DEAL_CONDITION、ATTENDANCE_NO_REMIND_MEMBER这类名字。你查字段EXT_ATTR_47，它存的到底是“审批人ID”还是“抄送人岗位编码”？改个导出逻辑，结果把ZX_DISPLAY_COLUMN（致信专用显示列）误当成DISPLAY_COLUMN（通用显示列），导出的通讯录在手机端全乱了……这种“看得见表名、读不懂含义”的状态，就是没数据字典的真实写照。
致远OA V8.1 数据字典，不是一份技术文档，更不是给DBA看的建表SQL清单；它是整套OA系统里所有数据库表、字段、约束、业务含义的权威汉语翻译本。它把系统内部用的“数据库黑话”，一句句翻成你能拍着桌子说清楚的话：比如TYPE SMALLINT TRUE不是“类型是小整数”，而是“这个组必须是系统组（0）、个人组（1）或私人通讯录（2）三选一，缺一不可”；CANCEL_FLAG SMALLINT FALSE也不是“取消标记可为空”，而是“一旦代理被取消，这里就记1，后续所有流程都绕开这个人——哪怕他还在组织架构里”。
为什么值得花时间搞懂它？因为你在做这五件事时，90%的翻车都源于没查它：
- 写报表时连错表（把
ADDRESSBOOK_MEMBER当成ADDRESSBOOK主表，漏掉外部联系人关联逻辑）； - 做接口时传错字段（把
MEMBER_ID当作用户登录账号，实际它只是内部人员编号）； - 配置考勤规则时填反值（
IS_WORKDAY=0是“非工作日”，但你按常识理解成“未设置”，结果全员旷工）； - 扩展字段乱用（把
EXT_ATTR_31（枚举）当EXT_ATTR_1（文本）存长字符串，字段直接截断）； - 升级后功能异常（V8.1 新增
AI_ORG_CHANGE_RECORD表记录部门变更，但旧脚本还去查已废弃的ORG_HISTORY）。
它不教你写代码，但它能让你写的每一行SQL、每一个API参数、每一次配置修改，都踩在系统设计的真实路基上——而不是靠猜、靠试、靠重启服务器碰运气。
2. 它到底是什么：一张表、一个字段、一行注释，全在讲“业务怎么活”
2.1 表不是容器，是业务场景的切片
在致远OA V8.1里，一张表从来不是孤立的数据集合，而是对某个具体管理动作的完整快照。以ADDRESSBOOK（通讯录主表）为例：
它不叫“联系人表”，而叫“通讯录”——这意味着它承载的不是静态信息，而是动态协作关系。
MEMBER_ID字段标为FALSE（非强制），是因为通讯录既要存内部员工（有MEMBER_ID），也要存客户、合作伙伴等外部联系人（此时MEMBER_ID为空，靠NAME+COMPANY_NAME唯一识别）；
而ADDRESSBOOK_MEMBER表里的CREATOR_ID和CREATOR_NAME必填，是因为每条外部联系人记录，必须明确“谁在系统里亲手加的这个人”，这是审计溯源的硬要求。
再看考勤模块的ATTENDANCE_DAY_STATISTICS（签到日统计表）：
AM_START_STATE和PM_END_STATE类型都是SMALLINT，取值却不是0/1，而是有明确定义：1=正常、2=迟到、3=早退、4=旷工、5=外勤、6=缺卡……- 这些数字背后没有魔法，全靠数据字典里那句注释：“上午签到结果”。它把数据库里冰冷的数字，直接锚定到HR每天晨会说的“张三今天上午迟到了”。
关键点：当你看到一张表名，先问自己——这个业务动作，在办公室里是谁、在什么场景下、为什么要做？答案就在表注释里。AGENT表注释写的是“代理设置应用表”，不是“代理人表”，说明它的核心价值不是存人，而是存“谁在什么时间段替谁处理哪类事务”的授权契约。
2.2 字段不是变量，是业务规则的晶体化表达
数据字典里每个字段的“数据类型+强制+注释”，合起来才是一条完整业务规则。拆开看：
- 数据类型是底线：
EXT_ATTR_11 DECIMAL(19,4)看似只是“存数字”，但(19,4)意味着它能存最大999999999999999.9999的数——为什么这么设计？因为致远OA里某些绩效分值要精确到小数点后4位（如“领导力评估：4.9999分”），少一位就会四舍五入失真。 - 强制（TRUE/FALSE）是红线：
ID BIGINT TRUE不仅是主键要求，更是系统底层校验逻辑的开关——如果某条ADDRESSBOOK_TEAM记录的ID为空，整个团队分组功能会直接报错退出，而不是默默跳过。 - 注释是灵魂：
TYPE VARCHAR(50) FALSE后面那句“0：系统组 1：个人组 2：私人通讯录”，比任何代码注释都管用。它告诉你：这个字段不是随便填的字符串，而是有且仅有三个合法值的枚举项；填3或abc，系统不会存，也不会报错，而是静默转成空值——然后你的“私人通讯录”功能就永远找不到了。
提示：所有
EXT_ATTR_*扩展字段（共70个！）都不是备用字段池。它们是致远OA预留的“业务插槽”：EXT_ATTR_31~40专供下拉枚举（如“紧急程度：高/中/低”），EXT_ATTR_41~50专供选人组件（如“法务审核人”），EXT_ATTR_51~60专供选部门（如“预算归口部门”）。混用即失效——把选人字段当文本字段存，前端就无法联动组织架构树。
2.3 约束不是限制，是业务语言的语法
数据字典里没有显式写出“外键约束”“唯一索引”，但字段间的逻辑关系早已藏在命名和注释中：
ADDRESSBOOK_SET_SCOPE表里ADDRESSBOOK_SET_ID字段，注释写“通讯录设置 ID”，而ADDRESSBOOK_SET表的ID是主键——这就是隐式外键：没有它，SET_SCOPE就是无源之水；AI_DEAL_CONDITION表中SENDER_ID和USER_ID都标为BIGINT FALSE，但注释分别写“发起人 ID”和“处理人 ID”，意味着同一笔流程里，这俩ID可以相同（自审自批），也可以不同（跨岗审批），但绝不能同时为空——否则系统无法判断“谁发的、谁该办”。
这些不是DBA该操心的性能优化点，而是你写业务逻辑时的语法检查器。比如开发一个“自动催办”功能，你要查AI_REMIND_RECORD表，就必须先确认REMIND_AFFAIR_ID对应的是AFFAIR表里的有效事项ID——数据字典不写“外键”，但REMIND_AFFAIR_ID的注释“被查看的已办或已发事项 ID”，已经告诉你：它必须指向一个真实存在的事项，否则催办消息发出去，收件人点开就是404。
3. 它为什么存在：解决OA系统里最痛的三个“不知道”
3.1 不知道“这个字段到底管什么”——告别字段名玄学
新手最容易栽在字段名上。比如ATTENDANCE_INFO表里的PUNCH_TYPE：
- 字段名是“打卡类型”，但数据字典写明：“排班类型：0-固定排班，1-周期排班”。
- 如果你只看名字，可能以为它存的是“手机打卡/指纹打卡/人脸识别”；
- 实际上，它决定的是整个考勤计算逻辑：固定排班走日历匹配，周期排班走7天循环模板。填错值，员工本月考勤全部算错。
再如BBS_ARTICLE表的SPACETYPE：
- 名字像“空间类型”，但注释写清“（1，部门；2，单位；3，集团；4，自定义团队；17，自定义单位；18，自定义集团）”。
- 这意味着：当你要查“集团级公告”，不能
WHERE SPACETYPE = 3，而必须WHERE SPACETYPE IN (3,18)——因为“自定义集团”也是集团空间的一种，但名字里没体现。
数据字典把这种“名字像A、实际是B”的陷阱，全摊开在阳光下。它不假设你知道行业黑话，而是用最直白的业务语言重写一遍。
3.2 不知道“改这里会不会崩其他功能”——看清字段的辐射半径
OA系统最怕“牵一发而动全身”。数据字典帮你画出每个字段的影响地图：
ADDRESSBOOK_SET表的VIEW_SCOPE字段（查看范围），注释写“查看范围”，看似简单。但往下看ADDRESSBOOK_SET_SCOPE表，你会发现它通过ADDRESSBOOK_SET_ID关联，并按USER_TYPE（组织模型实体类型）细分权限。这意味着：改VIEW_SCOPE，不仅影响通讯录列表展示，还会同步控制ADDRESSBOOK_SET_SCOPE里所有USER_TYPE='DEPARTMENT'的部门可见性。AGENT表的AGENT_TYPE字段（代理类型），注释写“1-代理设置 2-离职交接”。这直接决定AGENT_DETAIL表里APP字段的取值逻辑：AGENT_TYPE=1时，APP存的是应用ID（如“公文”“合同”）；AGENT_TYPE=2时，APP固定为0，表示全系统交接。改错这里，离职交接单可能只流转到公文模块，合同审批却没人处理。
它不告诉你“技术上怎么改”，但明确标注“改这个，会影响哪些表、哪些业务流”。就像修电路前先看接线图——你知道EXT_ATTR_21（日期类型扩展字段1）被ATTENDANCE_ARRANGE和AI_PROCESSING_CONDITION两个模块共用，就不会在考勤排班里随便删它。
3.3 不知道“新功能用哪个表”——快速定位业务模块的入口
V8.1 新增了AI相关表（AI_*前缀），但没人告诉你它们怎么用。数据字典就是你的功能导航仪：
AI_ORG_CHANGE_RECORD注释是“组织变更记录”，字段OLD_VALUE/NEW_VALUE存变更前后的文本值，ORG_TYPE标明是部门/岗位/职务级别——这说明它是做组织架构异动审计的，不是用来查当前部门树的；AI_PROCESSING_CONDITION注释“自动处理条件”，CONDITION_VALUE类型是TEXT，注释写“自动处理条件”——结合V8.1升级说明，它存的是JSON格式的规则引擎表达式（如{"field":"status","op":"eq","value":"approved"}），用于配置“审批通过后自动归档”这类动作；AI_REMIND_COUNT和AI_REMIND_RECORD是一对：前者存“被催办次数”，后者存“谁催的、催了几次、是否已发消息”。这意味着做催办统计报表，必须两表JOIN，且IS_SEND_MSG=1才是有效催办。
没有数据字典，你可能花三天研究AI_DEAL_CONDITION，最后发现它只在流程引擎内部调用，根本不对外开放API；有了它，你一眼锁定AI_REMIND_RECORD，两小时就做出催办漏斗分析。
4. 怎么区分：别再把数据字典、数据库ER图、接口文档搞混了
4.1 数据字典 vs 数据库ER图：一个讲“意思”，一个讲“结构”
| 维度 | 数据字典（致远OA V8.1） | 数据库ER图 |
|---|---|---|
| 核心目标 | 解释每个字段“在业务里代表什么、怎么用、为什么这样设计” | 描绘表与表之间“谁引用谁、一对多还是多对多” |
| 你查它时想问 | “EXT_ATTR_61能不能存岗位名称？填错会怎样？” | “ADDRESSBOOK_TEAM和ADDRESSBOOK_TEAM_MEMBERS怎么关联？” |
| 关键内容 | 字段注释、强制性、数据类型精度、枚举值含义、业务场景说明 | 表名、字段名、主键/外键连线、基数（1:1, 1:N） |
| 典型错误 | 把ER图当字典用：看到ADDRESSBOOK_TEAM.ID → ADDRESSBOOK_TEAM_MEMBERS.TEAM_ID，就以为TEAM_ID可以为空（实际数据字典写明FALSE） | 把字典当ER图用：在AGENT_SCOPE表里找ENTITY_ID的外键指向，却发现注释只写“对应 ENTITY_TYPE 中的实体 ID”，没写具体关联哪张表 |
通俗地说：ER图是建筑的钢筋骨架图纸，告诉你梁柱怎么搭；数据字典是装修说明书，告诉你“这个开关控制客厅灯，那个插座专供空调，别把冰箱插头塞进厨房插座”。
4.2 数据字典 vs 接口文档：一个管“存什么”，一个管“怎么拿”
| 维度 | 数据字典（致远OA V8.1） | 接口文档（如REST API） |
|---|---|---|
| 关注对象 | 数据库表、字段、约束、业务含义 | API路径、请求方法、入参格式、返回JSON结构、错误码 |
| 你查它时想问 | “ATTENDANCE_DAY_STATISTICS.AM_START_STATE的值2代表迟到，那前端显示该用什么文案？” | “查员工考勤日报，该调哪个URL？参数传memberId还是userId？” |
| 关键内容 | AM_START_STATE SMALLINT+ 注释“上午签到结果：1=正常，2=迟到…” | GET /api/v1/attendance/daily?memberId=12345+ 返回示例{ "amStartState": 2, "stateText": "迟到" } |
| 典型错误 | 用接口文档替代字典：看到API返回stateText="迟到"，就以为数据库里也存字符串，结果去ATTENDANCE_DAY_STATISTICS表里搜"迟到"，永远找不到（实际存的是数字2） | 用字典替代接口文档：查到BBS_ARTICLE.REPLY_NUMBER是“回复数”，就直接SELECT REPLY_NUMBER FROM BBS_ARTICLE，却不知接口已做权限过滤（只返回当前用户有权限看的帖子） |
打个比方：数据字典是菜市场的价目表（青菜5元/斤，猪肉38元/斤），接口文档是外卖App的下单按钮（点“青菜”弹出规格选择，点“提交”才真正扣款）。你不能看着价目表就以为能直接扫码支付。
4.3 数据字典 vs 系统配置手册：一个讲“数据本质”，一个讲“操作步骤”
| 维度 | 数据字典（致远OA V8.1） | 系统配置手册 |
|---|---|---|
| 核心价值 | 揭示数据背后的业务规则和设计意图 | 指导管理员在Web后台点哪里、填什么、保存后生效范围 |
| 你查它时想问 | “ATTENDANCE_SETTING.AVAILABLE=0是禁用围栏，那AVAILABLE=1是启用，还是启用+默认开启？” | “怎么在后台设置考勤围栏？第几步点‘启用’按钮？” |
| 关键内容 | AVAILABLE SMALLINT FALSE+ 注释“是否启用（0，否；1，是）” | 截图步骤：“1. 进入【考勤管理】→【围栏设置】；2. 勾选‘启用地理围栏’；3. 输入经纬度范围…” |
| 典型错误 | 把配置手册当字典：手册说“勾选启用”，你就以为数据库AVAILABLE字段填1就行，却不知ATTENDANCE_SETTING表还有LONGITUDE/LATITUDE字段必须非空，否则启用无效 | 把字典当配置手册：查到BBS_BOARD.ANONYMOUS_FLAG=0是允许匿名，就直接UPDATE数据库，结果因未触发后台缓存刷新，前台还是显示“不允许” |
注意：配置手册是“怎么做”，数据字典是“为什么这么做”。比如
ADDRESSBOOK_SET.EXPORT_PRINT字段，手册教你怎么在后台勾选“允许导出”，字典告诉你：这个字段值为1时，ADDRESSBOOK_SET_SCOPE表里对应范围的用户才能看到导出按钮——没它，勾选了也白搭。
5. 什么时候用、什么时候别用：我的血泪经验总结
5.1 必须查数据字典的5个生死时刻
场景1：写SQL报表，字段值对不上业务需求
某次给HR做“近3个月考勤异常分析”，我写了这条SQL：
SELECT MEMBER_ID, COUNT(*) as late_count FROM ATTENDANCE_DAY_STATISTICS WHERE AM_START_STATE = 2 -- 迟到 AND PUNCH_DATE >= '2024-01-01' GROUP BY MEMBER_ID;结果导出的“迟到人数”比HR手工统计少了一半。查数据字典才发现：AM_START_STATE=2确实是迟到，但ATTENDANCE_DAY_STATISTICS表只存“当日有打卡记录”的数据；而很多员工迟到后根本没打卡，他们的异常记录在ATTENDANCE_HISTORY表里，TYPES=1（签到）且STATES=3（上班迟到）。
教训：只要报表涉及“异常统计”，必须对照字典确认：异常状态是存在主统计表，还是分散在历史流水表？ATTENDANCE_DAY_STATISTICS注释写的是“签到日统计表”，ATTENDANCE_HISTORY注释是“打卡历史”，一字之差，数据源天壤之别。
场景2：配置新流程，节点参数总报错
给合同模块加“法务终审”节点，需要指定审批人。我在流程设计器里填EXT_ATTR_41（选人类型数据字段），但保存时报“人员ID不存在”。查字典发现：EXT_ATTR_41的注释是“选人类型数据字段”，但没写清楚它存的是单个ID还是ID列表。翻到ADDRESSBOOK_MEMBER表的CREATOR_ID（同为选人字段），注释写“创建人 Id”，类型BIGINT TRUE——立刻明白：EXT_ATTR_41只能存一个数字ID，不能存逗号分隔的字符串。而流程设计器要求的是人员集合，必须换用EXT_ATTR_41关联的ADDRESSBOOK_TEAM_MEMBERS表来实现多人审批。
教训：所有带“选人”“选部门”字样的扩展字段，必须查清它是存ID（单值）、ID列表（字符串）、还是关联表ID（需JOIN）。字典里VARCHAR(50)类型基本排除ID列表可能（长度不够），BIGINT才是单值ID。
场景3：升级后功能异常，排查范围太大
V8.1升级后，“通讯录共享给外部联系人”功能失效。我先查ADDRESSBOOK_SET表的EXTERNAL_SCOPE字段（编外人员权限设置），字典注释写“1（按工作范围显示）2（全部隐藏）”，值是1，没问题。再查ADDRESSBOOK_SET_SCOPE表，发现USER_TYPE='ACCOUNT'的记录里ADDRESSBOOK_SET_ID指向的设置ID，其VIEW_SCOPE是2（仅限本单位）。原来EXTERNAL_SCOPE控制“是否对外”，VIEW_SCOPE控制“对外看到什么”——两个字段必须协同生效。
教训：涉及权限的功能，永远不是单字段问题。字典里凡是有“范围”“权限”“可见性”字样的字段，必须顺藤摸瓜查关联表。ADDRESSBOOK_SET_SCOPE的注释“通讯录设置范围”，就是明确提示你：这里才是权限落地的最终执行层。
场景4：对接第三方系统，字段映射总出错
对接钉钉通讯录，要把ADDRESSBOOK_MEMBER的MOBILEPHONE同步过去。我直接SELECT MOBILEPHONE FROM ADDRESSBOOK_MEMBER，结果部分号码带+86前缀，部分不带，钉钉校验失败。查字典发现：MOBILEPHONE VARCHAR(20) FALSE，注释是“手机”，但没写格式规范。再翻BBS_ARTICLE_ISSUE_AREA表的MODULE_ID字段，注释写“组织模型编号”，类型BIGINT——立刻意识到：致远OA里所有VARCHAR类型的号码字段，都不做格式标准化，必须由应用层清洗。
教训：VARCHAR类型的文本字段（尤其是电话、邮箱、地址），字典从不承诺格式统一。MOBILEPHONE存的是用户输入原值，EMAIL可能大小写混用，ADDRESS可能含换行符。对接时必须加清洗逻辑，不能信字段名。
场景5：开发自定义报表，想加个新维度却找不到表
想统计“各岗位员工使用致信的活跃度”，需要岗位ID。我查ADDRESSBOOK_MEMBER表，有COMPANY_POST（岗位），但它是VARCHAR(50)文本字段，无法和组织架构表关联。查字典发现：AI_ORG_MEMBER_CHANGE表里有OLD_POST_ID/NEW_POST_ID（岗位 ID），注释是“旧岗位 ID”“新岗位 ID”，类型BIGINT。再看ATTENDANCE_INFO表，也有OWNER_ID（打卡人ID），但没岗位字段。最终方案：用OWNER_ID关联ADDRESSBOOK_MEMBER.MEMBER_ID，再通过ADDRESSBOOK_MEMBER的COMPANY_POST做模糊匹配——虽然不精准，但字典确认了这是唯一可用的岗位信息源。
教训：当你要的字段不在主表，先查所有AI_*（AI相关）、ATTENDANCE_*（考勤相关）、BBS_*（社区相关）表，它们常存业务过程中的中间状态。AI_ORG_MEMBER_CHANGE注释“组织成员变更”，就是岗位变更的黄金数据源。
5.2 别用数据字典的3个危险区
危险区1：当它能替代测试
字典写CANCEL_FLAG SMALLINT FALSE（取消标记，0-未取消 1-已取消），我就以为设成1就万事大吉。结果上线后发现，代理取消后，AGENT_DETAIL表里对应的记录没清理，导致流程还能走到已取消的代理人。查日志才发现：系统取消代理时，除了更新AGENT.CANCEL_FLAG，还会调用存储过程清理AGENT_DETAIL。
结论：数据字典描述的是数据状态，不是业务流程。状态变更的副作用（如级联删除、缓存刷新、消息通知），必须看代码或流程图，字典不保证。
危险区2：当它能解释所有NULL值
UPDATE_DATE DATETIME FALSE（最后修改日期），字典没写“何时为空”。我默认“新建记录时空”，结果发现：有些表的UPDATE_DATE在INSERT时不设值，UPDATE时才更新；有些表（如BBS_ARTICLE）的MODIFY_TIME在INSERT时就设为ISSUE_TIME。
结论：FALSE只代表数据库允许NULL，不解释业务逻辑。UPDATE_DATE为空，可能是“从未修改”，也可能是“修改逻辑未触发”，必须查代码或测试验证。
危险区3：当它能预测未来版本
V8.1字典里AI_*表全标“AI相关”，但没写清楚哪些是V8.1新增、哪些是V7.x遗留。我基于AI_DEAL_CONDITION开发了自动处理规则，结果V8.2升级后，这个表被废弃，新逻辑移到PROCESS_RULE表。
结论：数据字典是当前版本的快照，不是演进路线图。所有带AI_、M3_、ZX_前缀的表，都要查版本发布说明确认生命周期，字典本身不标注废弃状态。
从那以后我每次接到需求，第一件事不是打开数据库客户端，而是打开这份《致远OA V8.1 数据字典》，用Ctrl+F搜关键词，把涉及的表、字段、注释、关联关系全抄到笔记里，再动手写第一行代码。它不能代替思考，但能让我避开90%的“我以为”陷阱。希望帮到你。
本文还有配套的精品资源，点击获取
