如何建设企业数据仓库？可能是大家最关心的一点。换个角度思考一下，谁应该建模？或者谁应该参与模式建设？

整理工作的想法。
谁应该参与模型建设。
一个模型的成功好坏可能有很多层次。但是，模型无法解决某些问题，显然失败了。那么，业务人员应该参与，他们应该是需求的出发者。
模型建设者必须做什么？
数仓人员的工作定义在哪里？他们负责什么样的东西？是指导业务整理还是业务提出模型需求？企业的规模和组织结构都会影响这一选择。但是，最终的模型落地，必须由模型负责人决定，提供相应的设计。
什么样的支持？
没有高层的重视，模型建设就像盖烟囱。
实施程序。
业务模式->领域模式->逻辑模式->物理模式。
业务模型生成业务模型，主要解决业务水平的分解和程序化。
|划分整个单位的业务，一般按业务部门的划分，进行各部分之间业务工作的定义，整理各业务部门之间的关系。
|深入了解各业务部门内部的具体业务流程，程序化。
|提出修改和改进业务部门工作流程的方法和程序化。
|数据建模范围定义，数据仓储项目整体目标和阶段划分。
领域建模生成领域模式，主要是对业务模式进行抽象处理。
|抽取重要业务概念，抽象化。
|将业务概念分组，按业务主线收集类似的分组概念。
|细分组概念，整理组概念内的业务流程，抽象化。
|整理分组概念之间的关联，形成完整的领域概念模型。
逻辑建模生成逻辑模型，主要是将领域模型的概念实体和实体之间的关系进行数据库水平的逻辑化。
|业务概念实体化，考虑其具体属性。
|事件实体化，考虑其属性内容。
|说明实体化，考虑其属性内容。
物理建模生成物理模型，主要解决，逻辑模型针对不同关系数据库的物理化和性能等具体技术问题。
|针对特定的物理平台，进行相应的技术调整。
|针对模式性能考虑，对特定平台做出相应调整。
|针对管理需求，结合特定平台，做出相应的调整。
|生成最后的执行脚本，完善。
建模方法和实施。
建模方法论是目前主流的Immon模式建模、Kimball维度建模和DataVault(数据湖)。不同的建模方式实际上是从不同的角度看待世界。由于在实际过程中使用维度建模的方法很多，所以我们以维度建模为例进行模型建设。
选择业务流程。
在确定业务流程之前，要了解企业的经营范围，了解各业务线。面对不同的业务流程，业务专家应确定业务相关过程，如电子商务，包括订单、付款、交付、退货等。有业务的主线结构。
根据主线结构，选择简单重要的业务过程。明确核心指标(事实)和模型评价标准，为后期检查设定基调。
确定粒度。
粒度是不能再分解的细分。例如，订单的事实也可以分为订单下的商品。最细粒度便于后期扩展，无需考虑统计口径变化时，模型无法使用或担心大变化。
确定维度。
维度是描述事实的环境。是where、when、who、how的回答。根据业务流程的不同，维度的考虑也不同。订单事实关系，如订单量、订单金额、商品渗透等。如果是进货过程，更关系到每个商品的进货价格、进货量、库存周转问题。
确定事实。
事实是对发生的事务的量。买裤子35元，买牛肉5斤等。
在实际的模型建设过程中，更多的问题就像迷宫一样，不知道出口在哪里。个人建议，与业务专员握手，了解多少业务流程，明确划分模式的主线结构。根据主线结构，选择最重要的业务流程，整理当前业务需求中集中的问题和关注点。以此为出发点，进行需求扩展。
需求扩展时，应从维度表开始，如常见的时间维度、商品维度、自然人维度等。确认维度表丰满事实，采用维度建模方式，在事实表中只保存维度键。
规范建设。
临时表格管理。
在数据处理过程中，我们必须使用临时手表(中间手表)。一般来说，我们认为临时手表没有储存意义，但我们不能立即删除或在完成后删除(有时过程有问题，我们必须依靠手表找出原因。或者想避免对功能库的污染，在temp库进行数据备份)。如果没有生命周期限制临时表的话，必须面对临时表的库存爆炸问题。那么我们该怎么办呢？
约定统一的临时表命名方式。
例如，建立统一的临时库(如TEMP)。要求该库数据表全部删除，不影响业务。命名规则因数据处理过程而异，命名指定的意思不同。
表的生命周期。
对于不同的手表，周期是有限的。制定统一的表格删除策略。
代码规范。
脚本格式的规范。
脚本头部评论编写规范、评论规范、sql规范google规范参考。
文件/表格命名规范。
在一个文件中，只有一张表，其馀只有临时表的表名必须与文件名相同。
字段命名规范。
去除多词同义和同词多义问题。特别是模型层(一般也称为一致性维度)
流程规范。
「数据仓库建设」如何建设企业数据仓库？重要的是流程，明确各步骤需要完成的事项，减少代码错误的风险。