综述
这是一个系列连载，主要是思考在各种业务场景下如何去抽象业务、建设数据模型、为使用方提供数据产品支持业务发展。
我们把参与公司业务活动的主体称为当事人，其中 当事人可以分为两类：人员和组织。
本章主要说明我们如何在逻辑、关系型数据库、数仓层面描述人员和组织的信息、结构和变化。同时如何在数据应用中使用我们得出来的数据模型。
原文见：数据建模1-人员和组织
逻辑模型
人员是实际参与业务的人
-
可能是雇员、客户、甚至是虚拟的人。
人员和人员之间有着多对多的关联关系
主题内需要保留员工的基本信息及历史的变化记录
组织是人的集合
-
组织有着多种类型，比如家庭、公司、部门、政府等等
组织和组织之间有着多对多的关系，比如关联公司、子公司、部门树、户籍
主题内需要保留员工的基本信息及历史的变化记录
角色是人在组织内扮演的角色
-
角色同样有着多种类型，比如家庭的父母子女、公司职位、政府市长等等
角色之间一般没有从属关系，但是在部分组织内有可能
主题内需要保留角色的属性信息、历史的修改记录及人员与组织关系的变化记录
关系型数据库模型
根据上文，在业务系统中，我们会按照三范式设计关系型数据库的物理模型如下：
人员
-
人员表：核心表，存储人员当前的各种属性
主键为统一ID（UID）：很多人喜欢用证件号作为人员主键，但是实践中会发现由于法定证件包含身份证军官证护照，直接使用证件号作为主键是不太可取的，建议主键设置为统一ID，然后将证件设置为扩展属性表（证件表）
扩展属性表：存储人员会不断调整或者一对多的信息，如地址簿、通讯方式、证件等
主键为自增ID，
外键为归属人UID
人员关系表：存储人员之间的关系
主键为：角色甲UID+角色乙UID
可以根据复杂程度按照类型拆分为多个关系表。如分为家庭关系表、社会关系表等。也可合并为一张表
人员业务流程日志表：存储人员各种会影响到个人信息的业务流程，比如员工的入职离职等
主键为业务流程ID
外键为UID
具体表结构根据业务流程确定，在本章节内不再展开
组织
-
组织表：核心表，存储组织属性
主键为组织ID
扩展属性表：类似人员关系表，存储组织会不断调整的或者一对多的信息，如通讯方式、证件等
主键为自增ID，
外键为组织ID
组织关系表：存储组织之间的关系，如子公司等
主键为：组织甲ID+组织乙ID
人员组织关系表：存储人员和组织之间的关系，如任职等
主键为：人员UID+组织ID
组织业务流程日志表：与人员业务流程日志表类似，存储各种会影响到组织信息的业务流程，比如公司的注册、法人变更等，具体见后续的业务流程设计章节
主键为：业务流程ID
角色
-
角色表：存储角色属性
主键为角色ID
人员角色关系表：核心表，存储人员和角色的关联关系
主键为角色ID和人员ID
角色组织关系表：核心表，存储组织和角色的关联关系
主键为角色ID和组织ID
离线数据仓库模型
数据仓库往往是业务系统的关系型数据库下游，目标是抽象业务流程和实体，为后续的管理报表、商业分析、算法等提供支持。
由于当前存储相对计算资源更廉价，因此为了使用方便，数仓会进行一定程度反范式建模，将常用字段展示出来。当然有得必有失，缺陷就是如果要更新数据需要大量重刷历史数据。
人员和组织的关系相对简单的场景
-
场景：只包含多对一的关系（比如一个员工只能归属于一个岗位，一个岗位也只能挂在一个组织下面，一个员工的证件、联系方式和地址等在同一时间内只能生效一个）
物理结构，一般情况下我们会按照星型模型设计
人员表：
维表DIM，主键为UID
人员和组织关系、人员和角色关系都作为属性保留组织ID，角色ID字段
一般情况下我们会采用快照方式保存人员的历史变更，存储为快照表，如每天的员工花名册快照，如果数据量较大，还可以采用拉链表的方式进行压缩。
优点：实现方便，一次配置后期不需要维护
缺陷：
如果变化周期不固定，则会丢失固定周期内的更细粒度的变化，比如如果一个员工在一天内改了两次名字，我们只能抓取到最后一次变更结果。
在离线数仓场景下想要修改更正历史数据非常复杂
还可能存在时间错位的可能。
可以从员工业务流程日志表内取每一次变更都新增一条员工信息快照，
优点：可以保留最细粒度的每一次变化，当然也可以按照自己预定的周期进行更新，比如同样加工出日快照表。
缺陷：实现复杂，同时后期需要跟着业务系统变更维护变更
组织
维表DIM，主键为组织ID
和人员表类似，一般情况下使用快照方式，如果需要更细粒度可以用日志表加工
组织角色
维表DIM，主键为组织ID
和人员表类似，一般情况下使用快照方式，如果需要更细粒度可以用日志表加工
人员组织关系相对复杂的场景
-
场景：人员、角色和组织之间的关系为多对多（一人多角色，一角色多组织）
物理结构：此时我们需要抽离关系表出来，数仓的结构会和关系型数据库模型类似。但是在数仓中抛弃了变更日志表，将其合并到对应的实体表中，使用快照的方式体现属性时间维度上的变化
图中绿色的为表示实体的表，包含人员表、组织表、角色表地址簿表等
主键为各种ID+快照日期
绝大部分情况下，这些表都是快照表，如果数据量较大也可以用拉链表来压缩存储，但是使用拉链表会导致数据使用难度大增
图中黄色的为表示关系的表，包含人员组织关系表、人员关系表、组织关系表、人员角色关系表，角色组织关系表
主键为双方ID+快照日期
绝大部分情况下，这些表都是快照表，如果数据量较大也可以用拉链表来压缩存储，但是使用拉链表会导致数据使用难度大增
也可以考虑合并人员角色关系表，角色组织关系表。合并后主键为人员ID、组织ID和角色ID。
基于数据使用的应用层设计
基础数据准备好了，业务中如何使用这类数据呢？
对于各种统计报表来说，往往核心关注数据的分布和变化。横向分析当事人在各个维度的分布，纵向分析当事人在时间维度的变化。借此反应组织的人员（客户、员工等等）的情况。
对于不同的数据使用方，会有着不同的诉求，我们可以提供的支持产品也往往不同
管理层
对于管理层来说：
需要快速掌握负责的业务的全貌，同时直观看到指标异动
对于异动或者关注的指标，提供下钻和简单问题分析能力
可以在移动端查看
定时或者满足某些条件推送的能力
基于以上的诉求，我们可以提供的是
一个具有交互能力且直观清晰的管理报表，包含管理层关心的所有指标，并有合理的分类
-
一般由产品级别管理大盘+各个业务方向管理大盘组合构成
管理报表提供强时效性(SLA）和正确性保障
有下钻和上卷能力，一定程度的问题分析能力
移动端查看能力和数据推送（IM/邮件等）能力
运营&业务
运营和业务同学日常需要的是
使用明细数据去排查问题，比如员工状态是否正常，查询员工历史岗位变化
根据组织或者人员状态分析报表，制定运营策略。如根据每月离职人数波动制定薪酬策略
基于标签系统如用户画像，去做人员圈选，进行营销活动
基于汇总或者明细报表进行风控
基于以上的诉求，我们可以提供的是
基于维度建模的明细大宽表，展示人员和岗位信息
各种时间粒度的组织/人员信息分析报表
-
提供各类维度：组织、城市、区域、年龄等等
标签系统，如用户画像
-
主键是快照日期+员工/组织ID
结构
一张大宽表放下所有指标（快照日期+UID+指标A+指标B……），
优点是使用方便直观，同时通过元数据管理系统可以直观看到现有指标数量和是什么，方便管理
缺点是每次变更数据的时候还需要改表结构，同时加工的时候由于上游较多，产出时间会以最晚的数据源为准
每个指标一行（快照日期+UID+指标名+指标值）。
优点是表结构无需变更，同时可以做到每个指标的产出都尽可能早
缺点是不够直观，同时表内含有多少个指标在多年维护后只能翻代码才知道
数据科学家/BI
数据科学家或者BI同学需要的是
基于汇总或者明细报表进行写SQL或者EXCEL分析业务现状，进行未来预测，提供分析报告
根据业务和基础数据，制定指标口径，选择能够真实反映业务的指标
基于以上的诉求，我们可以提供的是
基于维度建模的明细大宽表，展示人员和岗位信息
各种时间粒度的组织/人员信息分析报表
-
提供各类维度：组织、城市、区域、年龄等等
在数据科学家们建立新的指标后，将其新建或者融入管理报表中的开发能力
算法
算法同学往往需要的是
标签表，供他们训练模型和使用模型。同时按照他们的需求去迭代标签表内的标签还有优化标签产出速度
基于以上的诉求，我们可以提供的是
标签系统，如用户画像
-
结构和设计见上文
小结
人员和组织的核心是人员、组织两个实体和他们之间的关系。建立模型的时候关键是体现出实体之间的关系。而使用数据的时候，使用方核心关注数据的分布和变化，同时也需要最明细的数据去查看细节。