大数据仓库是数据中台内容端建设的载体，将医保各业务数据统一汇聚，并按照一定的方式进行分层组织和存储。
建设大数据仓库的目的包括：
a) 避免烟囱式开发：重复建设、消耗集群存储空间、增大集群计算压力；
b) 保证数据的质量、统一指标口径；
c) 底层业务数据结构变动和上层数据需求改动可以减少对模型的影响。
缓存层（STG）
缓存层是为 ETL 加工便利性和效率考虑而设的区域。用于对所有源系统的数据进行统一存储和管理。数据缓存层应符合以下要求：
a) 表结构宜与源系统一致或近似；
b) 具备数据快速删除能力；
c) 具备明细数据快速查询能力；
d) 表名应具备识别不同层级及增量和全量加载模式的命名规则；
e) 每条记录包括数据的插入、更新时间字段；
f) 每条记录包括数据的插入、更新的作业实例。
操作数据层（ODS）
操作数据层是对缓存层的数据基于数据标准和质量校验规则，借助数据开发与治理工具对数据进行相关的数据清洗和治理等操作的区域，也是对当前及历史数据进行存储的区域。
操作数据层应符合以下要求：
a) 表结构宜与源系统一致或近似；
b) 具备支持数据快速删除能力；
c) 支持明细数据查询功能；
d) 具备数据历史全量存储能力；
e) 具备基于日期、系统快速删除和数据抽取能力；
f) 具备存储脏数据和对脏数据快速查询能力；
g) 针对脏数据存储需要包括源数据记录的唯一标识和记录违反的详细说明信息；
h) 表名应具备识别不同层级及增量和全量加载模式的命名规则；
i) 每条记录包括数据的插入、更新时间字段；
j) 每条记录包括数据的插入、更新的作业实例。
通用数据模型层（CDM）
通用数据模型层用来存放对引入层进行主题化后的数据，主题过程采用 LDM 建模的方式对数据进行处理。通用数据模型层应符合以下要求：
a) 采用 LDM 对数据进行主题建模；
b) 能从表名识别出从属主题；
c) 每条记录包括数据的插入、更新时间字段；
d) 每条记录包括数据的插入、更新的作业实例编号。
LDM 建模
建模方法
LDM 面向主题，应采用三范式建模方法，构建单一数据视图，模型扩展性强且具有业务中立性，用于支持各类整合型分析型应用。
业务规则和逻辑表达
应通过图形方式体现业务规则和逻辑，在整个设计过程中都应保证业务规则的正确性和完整性。
历史数据的表达
对于状态变更，需要保留历史状态的信息，在逻辑数据模型中体现为“历史表”或者“拉链表”。设计历史表应满足以下要求：
a) 包含“开始日期”和“结束日期”，表示信息在介于开始日期和结束日期的时间段上有效；
b) 包含“当前是否有效”字段，用于提高查询效率；
c) 明确初始加载和日常加载时两个时间字段的填写规则以及缺省的“最大日期”填写规则。
父子类数据的表达
LDM 中宜采用父子类来组织分类数据。父类实体中存放数据对象的共性信息，子类实体中存放数据对象的个性信息，子类实体中存储的数据对象是父类实体中的子集。在设计父子类时应满足以下要求：
a) 父类实体与子类实体应具有完全一致的主键；
b) 子类实体中的记录应是父类实体中记录的子集，通过主键可以关联；
c) 父子类可以设计成多层结构，考虑到使用时的效率问题，物理实现的层次不宜超过3层；
d) 子类实体之间可以相互排斥，也可以相互有所覆盖，宜根据实际情况进行设计。
主键编码规则
LDM 每个主题中核心实体的数据可能来自多个源系统，应根据统一的编码规则，以保证主键的唯一性。编码规则应满足以下要求：
a) 不同的主题下的数据记录主键不重复；
b) 同一主题下的数据记录主键不重复；
c) 主键包含主要业务字段来源子系统的标识。
命名规则
数据模型命名规则宜为：主题域_业务表含义名。此种命名方式能高效区分各主题域下的模型表，以及表存储的数据信息。
不同数据模型中同业务含义的字段应有相同的命名。
LDM 主题域
采用 ER 图方式展示的通用数据模型层 LDM 见图 3。医疗保障信息平台大数据仓库通用数据模型层应包含以下主题域：
a) 当事人（Party）：在医疗保障业务过程中，所有个人与机构的参与者，包括人员、家庭、参保人、医疗机构、公司单位、税务机构、银行单位等；
b) 诊疗信息（Clinical）：描述医疗提供者为患者提供诊疗服务的相关信息，包括医疗门诊记录、住院记录、特殊诊疗信息等；
c) 医保服务及产品（Item）：国家医保提供的医疗保险产品、产品组、产品包和医疗保险服务信息以及政策参数等；
d) 协议（Agreement）：当事人之间签立的契约关系，它的形式可以是多样化的，如单位或者个人参加基本医疗保险，包含参保人账户信息、机构征缴方案、机构待遇方案等；
e) 事件（Event）：事件是涉及个人、医疗服务提供者的任何交易或联系活动，包括征缴事件、结算事件、基金结算事件等；
f) 财务管理（Financial Management）：主要记录总账以及相关处理日志/发票的重要信息，包括：发票、总账科目等；
g) 地理位置(Geography)：描述与医疗保险业务相关的各种地理区域和地址信息，及地理区域气象、环境、经济等信息。
LDM 主题参考实现
数据应用层（ADS）
数据应用层存储从通用数据模型层转换加工后的数据，为应用提供数据服务。数据应用层中的数据结构根据各子系统数据应用主题需求进行设计。
数据应用区
数据应用区应包含医学知识库、主题业务库和专题应用库等，具体要求如下：
a) 医学知识库应存储疾病、药品、处方、专家等数据；
b) 主题业务库应根据主题和前端应用需求，存储从引入层加工出来的汇总数据，通常对应各子系统的统计分析和固定维度的数据查询等，应支持高并发的快速查询；
c) 专题应用库应存储根据专题应用对数据特殊加工计算后的数据；
d) 数据应用区还是数据探索和数据挖掘的区域，通过多实例的方式支持多用户独立使用，实例之间相互独立，互不影响；数据中台应对该区域应提供实例的管理、监控功能；
e) 数据应用区可用来支撑模型建设、统计分析等工作，例如医疗服务价格调整模拟运行、药品目录范围调整影响分析、支付方式政策调整影响分析、政策仿真模拟运行等。
实时数据区
根据各子系统对实时数据计算的需求，将相关数据直接从源系统采集到实时数据区，提供相应的实时数据服务。
数据建模
建模方法
数据应用层按照维度模型方法构建，即维度建模。维度建模的好处包括易理解、高性能、灵活的扩充性。维度建模是一个可不断扩充添加的过程，扩充方式如下：
a) 在事实表中增加维度；
b) 在事实表中增加事实；
c) 在维度表中增加属性。
可先以底层细粒度构建，也可以从业务需求开始，自上向下构建。按照星型结构进行构建，一个星型结构包含两个基本部分：
a) 事实表：描述数据应用层中最密集的数据。在医保行业中，参保、结算的数据是典型的密集数据。事实表是预先被连接到一起的多种类型数据的组合体，包括一个反映事实表建立目的实体的主键，如一次结算。主键信息也是连接事实表与维度表的外键，外键携带非键值外部数据，如果这种非键外部数据经常用于事实表中的数据分析，它就会被包括在事实表的范围内；
b) 维度表：围绕着事实表建立，包含非密集型数据，它通过外键与事实表相连。典型的维度表包括人员信息、医院信息、药品信息等。
建模流程
数据应用层建模流程为：
a) 选取建模的业务过程：确定要建模的业务过程或者度量事件，在业务需求收集过程明确；
b) 定义模型的粒度：声明事实表的粒度，定义事实表的行代表的含义；
c) 选定维度：模型的粒度本身就能够确定一个基本维度集合，在此基础上添加其他维，这些维在已经声明的事实表粒度都有一个唯一对应值；
d) 确定事实：选择适用于业务过程的事实和指标，事实可以从度量事件中采用物理手段捕捉，或者也可以从这些度量中导出。
维度表设计
维度表包含内容如下：
a) 代理键：整型，不可重复，唯一标识每一条记录，不包含任何业务信息；
b) 代理键有效开始时间和结束时间；
c) 当前有效标志；
d) 主键：传统意义的业务键，包含相应的业务信息，如医院编号；
e) 名称：数据分析时显示的内容，如医院名称等；
f) 排序键：自定义序列；
g) 自定义汇总：利用自定义表达式进行特定的数据运算；（可选）
h) 父键：父子维度中用来标识主键的上级；（可选）
i) 一元运算符：在父子维度中用来定义上下级的汇总关系；（可选）
j) 属性：属性包含有关维度的信息。
事实表设计
事实表中一般要包含两部分：
a) 由主键和外键所组成的键部分；
b) 用户希望在数据仓库中所了解的数值指标，这些指标是为每个派生出来的键而定义和计算的，称为事实或指标。由于事实是一种度量，所以事实表中的这种指标往往需要具有数值化和可加性的特征。