前两篇讲了数据仓库的价值和构建思路，这里根据实际的业务系统数据实现一个数据仓库模型，最近项目是招投标系统的数据仓库建设，涉及的业务逻辑较复杂，参与方较多，但数据量不大，数据仓库构建后主要是支撑招标采购的流程监管层面；
按照数据仓库的构建思路，顺序是概念模型-->逻辑模型-->物理模型，最重要和复杂度较高的是概念模型的设计，需要结合业务，并根据业务特性设计事实表、维度表、顶层数据汇总表；
一、概念模型设计
概念模型需要结合生产系统的ER关系模型，梳理业务逻辑，当前生产交易系统使用的是ORACLE数据库，将数据分成多个库：业务库（包含招标采购项目流程）、主体+组织库（招标人、投标人、评标专家、代理机构）、财务库（标书费、平台服务费、招标保证金、CA办理费用等），项目表即是一个招标流程表，该表会记录关于招标过程中的，招标、投标、开标、评标、定标相关的数据：
招标：招标流程是招标人发起的，招标人将招标过程委托给代理机构，代理机构会发布招标公告，投标人在报名、响应阶段产生数据，响应后需要付投标保证金；
投标：投标人给代理机构缴纳标书费并下载招标文件，开标之前需要响应，并缴纳投标保证金；发售招标文件和投标人购买标书后，如果投标人对招标文件提出质疑，或招标人要修改招标文件，此时要在规定时间内发布一个澄清公告。
开标：开标一般是线下进行，代理机构把投标人召集到开标室，公开宣读投标人关于投标人报价、工期、质量、工程项目经理等投标人有实质要求的内容，此阶段拆封投标文件，解密电子的投标文件；
评标：评标一般是线下进行，代理机构把监督人、投标人、专家召集到评标室，专家对投标人资质及投标书打分，分为技术、商务、报价分；
定标：专家对投标人综合打分后，做一个总体排名，排名第1即为中标候选人，评标结束后需要发布预中标公告，将前3名公布，公告期间接受社会监督，期间产生的疑问、质疑需要代理机构/招标人澄清，澄清伴随着澄清公告，若质疑生效则可能废标和流标（评标成本高，一般不废标）；
合同：若预中标发布后，质疑期间对于预中标候选人无影响，在预中标发布xxx天后，招标人需要同中标候选人签订合同，同时招标人需要退还其他没有中标单位的保证金；
对于整个流程的梳理和业务了解后，客户更加关注流程的监管预警，以此为准整理一些监管维度：
二、逻辑模型设计
逻辑模型采用上一篇博文提及的维度建模模型，雪花模型，项目ID、投标人ID、招标人ID、代理机构ID、专家ID分别是整个招、投、开、评、定标流程的主要参与主体，数据抽取工具使用kettle：
数据表命名规范：tb_模型层次_主题域_业务域_汇总粒度
kettle命名规范：kt_模型层次_主题域_业务域_汇总粒度
三、物理模型设计
按照上一篇博客讲到的物理模型设计，构建ODS-->DWD-->DWS-->ADS的分层模型，这里ODS只抽取oracle库中源数据，不做任何清洗和变动，DWD层开始做数据的清洗和数据工程，DWS作轻度汇总，ADS面向应用查询提供更上层的汇总；以项目和供应商的汇总维度为例，项目流程是模型设计主体，供应商是类似维度表的数据，两者结合能够得到业务需要的一些投/中标相关的汇总维度（比如中标率排行、某个项目的投标人的注册金额相关统计、某投标人参与投标相关统计等）：
在项目流程表中（定标流程），将招标人的编号设计在内，定标流程的统计项从该类ADS汇总维度出结果：
