药房业务数据仓库：事实表粒度确定及star schema合理性评估

一、不同粒度的对比与你的选择合理性 #

先逐个拆解三种粒度的适用场景和局限：

• 咨询级粒度：每行对应1次患者咨询，适合统计咨询量、药师咨询效率、门店咨询频次这类宏观聚合需求，但完全无法追踪处方内的药物明细，也没法关联到具体药物的销售、使用情况，对于需要分析药物维度的业务需求支持严重不足。
• 处方级粒度：每行对应1张处方，能统计处方数量、单处方药物种类数、处方关联的咨询信息，但同样无法直接分析单个药物的销售趋势、患者对特定药物的使用频次，当需要拆分行项目数据时，得额外做数据拆分，增加了分析复杂度。
• 处方行项目级粒度：每行对应处方中的1个药物条目，这是当前场景下最灵活的细粒度选择，能覆盖几乎所有潜在分析需求：
  • 可以追踪单个药物的销售、处方情况，支持药物维度的多维度分析（比如不同门店、药师、患者类型下的药物处方量）
  • 能向上关联到所属处方、对应咨询，通过聚合就能得到处方级、咨询级的统计数据（比如某咨询开具的所有药物，某处方的总药物种类）
  • 完美匹配“一次咨询→多张处方→多个药物条目”的业务层级关联逻辑

你的选择完全合理，这个粒度能最大化覆盖当前及未来的分析场景，避免后续因为粒度不足而重构数据模型。

二、星型模型的适配性评估与优化建议 #

假设你当前的星型模型包含核心维度表：患者维度表、药师维度表、门店维度表、咨询维度表、处方维度表、药物维度表，事实表为处方行项目事实表，要满足该粒度需求，需关注以下要点：

必须满足的关联规则 #

• 每张处方行项目必须关联唯一的处方ID，每个处方必须关联唯一的咨询ID，确保从药物条目向上能完整追溯到对应咨询
• 维度表主键需与事实表外键严格对应，比如药物维度表的药物ID关联事实表的药物ID，建议在事实表直接保留核心维度外键（如患者ID、门店ID），提升查询效率

具体优化建议 #

1. 事实表字段设计

   • 保留核心度量字段：药物剂量、处方金额、行项目录入时间，同时补充咨询时间、处方时间，满足不同时间维度的分析需求
   • 补充业务标识字段：比如是否初诊（从咨询维度同步，避免关联查询）、患者复诊次数（患者的累计复诊次数，方便统计复诊患者的药物处方情况）

2. 维度表补充完善

   • 咨询维度表需包含咨询类型（初诊/复诊）、评估项数量（每次咨询的评估项总数）、药师ID、门店ID等信息，方便从咨询维度做聚合分析
   • 处方维度表需包含处方编号、是否急诊处方、处方状态等业务属性，与行项目事实表关联后，支持处方级的统计分析
   • 药物维度表需完善药物分类（处方药/非处方药、药理分类）、生产厂商、规格等字段，支持多维度的药物分析

3. 数据一致性与冗余控制

   • 同一维度的属性不要重复存储在事实表中，比如门店名称仅在门店维度表存储，事实表只保留门店ID
   • ETL流程中要严格校验咨询、处方、行项目的关联关系，避免出现“一行处方行项目对应多个咨询”这类数据错误

4. 性能优化

   • 对事实表的核心外键（处方ID、咨询ID、药物ID、患者ID）建立索引，提升关联查询速度
   • 如果数据量较大，可按开具时间进行分区（比如按季度或月份），加快时间范围查询的效率

内容的提问来源于stack exchange，提问作者Maokai