2024年公司数据库建设 篇1
数据平台的建设可以当做一个产品来设计。从广义上来讲，所有以数据驱动为核心的都可以称为数据产品（如数据报表平台，DMP，BI平台），从狭义上来讲，就是公司内部的数据平台。今天我们要讨论的，主要是在公司内部搭建数据平台。
公司的内部数据平台，主要是给各业务提供数据处理、分析、展示，供内部所有部门人员使用的，涉及数据的收集（填报）、数据的整合、业务报表制作、业务员数据分析以及可视化数据展示，目的是让公司内部的所有业务都能通过数据来驱动和辅助决策。简单点讲就是通过数据分析平台来驱动公司内部的数据化运营。
那么如何设计符合企业实情并能解决实际问题的数据分析平台呢？
1. 平台建设主导人需要对每一块业务需求有深刻的了解，知道每个业务部门想要看什么样的数据，需要什么样的分析报表；这些数据是否现在就可以获取到，是否需要收集；业务部门通过这些数据分析，是如何推进和改善业务，是否有提升的价值意义。
2. 平台的设计需要根据业务的要求设计符合使用者需要的内容，产品要有层级和结构。如果设计的一张数据报表既要满足管理层的需求又要满足一线业务人员的需要，那么这样的数据产品体验很大可能是比较差的。因为领导和业务人员的关注点不一样，看数据的视角也不一样。领导往往需要一些能帮助把握大方向的关键指标，并且希望知道这些指标之后的问题是什么？原因是什么？所以给领导设计的报表需要直观易懂，并且能够基于这些指标的一场定位到问题。而业务人员更在乎业务的执行，关注的数据往往粒度很细，需要知道各项指标的明细。
领导关注的报表（FineReport制作）
销售领导关注的指标明细（FineReport制作）
3. 数据平台一定要注意数据质量、规范、统一。因为数据分析平台是面向所有业务的，怎么保证公司的所有部门人员对于数据的理解是一致的，这点特别难。（比如服装行业的“断码”，从领导层来讲，公司仓储的服装全部尺码如果不完整就是断码；从仓库的仓管员角度来讲，仓库内的服装尺码不全就是断码；从门店的业务员角度来讲，客户需要的尺码当前门店无货就是断码）。公司的业务系统各有不同，数据库分布，数据口径不一，数据孤岛问题，导致数据的质量和结构也千差万别，越是这样，数据仓库的数据建设就显得尤为重要。平台的数据质量依赖于数据仓库底层的数据模型，所以一个好的数据仓库很大程度上决定了数据分析平台的数据质量。
4. 工具选型上，有报表平台、BI。报表平台适合构建基础的规范化的数据分析平台，从明细报表（表格类）的，项目档案，文件报备，数据填报，数据报表，业务主题分析，文中的所有demo就是用FineReport制作，侧重于展示和报表管理。BI侧重于分析，拿到数据可以自己拖拽维度来分析，不同于报表受模板框架的限制，涵盖简单的明细报表、分析报表和主题分析，制作要简单很多，大数据量的处理性能也强劲很多，代表：FineBI、Tableau.
下面我们就从实战的角度来加以阐述。
某公司是一家电商公司，那么该公司的各部门需要看哪些数据呢？首先收集日常常用的数据指标，哪些是经常要查询的，哪些是要日常填报的，这些在过往的经营中都有备案，好收集。这就构成了日常的基础查询类报表，这类报表最占大头。
其次，我们可以观察一下各部门的KPI是什么？下放到团队以及个人的KPI是什么？是否能以具体的数字来量化？如果对负责支持的部门的KPI不了解，就去寻求部门领导帮助（使用者最懂要什么），不落实指标如何能设计出好的数据报表？通常粗略的，例如采购部门的KPI基本就是销售额、订单数、销售毛利润、采购成本；运营部门的KPI就是新老用户述、留存率、复购率、用户流失、转化率，市场部门的KPI就是PV/UV、新客数，这就构成了各部门日常管理的报表。
那么知道各个部门的核心KPI后，下一步就是针对一些特定场景的主题报表。主题报表往往是记录某一事件，其中的指标都是相互关联的。
比如，我希望知道这个月我的绩效完成的怎么样？在团队内排名是提升还是下降？每个人的绩效结果明细是怎样的？——这就构成了日常考核报表。
又比如在分析产品时，需要重点关注某些产品的相对市场份额和市场增长率，则要建立波士顿矩阵分析，以便让资源有效地分配到合理的产品结构中（当然还有其他分析角度）——这就是品类分析。
产品分析（FineReport制作）
再从业务分析和使用场景入手，拿采购部门的小王来说，他是怎样看数据的呢？
每天早上，我希望知道昨天的销售情况怎么样？所以这时候应该设计一张基础查询报表给到他，这张数据报表应该具有以下功能和内容：
1.能够查看昨天以及过去各时段的数据；能够按照产品、地域来统计；能够与过往的平均值做比较，看看是不是某区域某产品的趋势上有大的变化，是不是广告投放，活动推广带来的，影响大不大。其次，每个月，每季度的数据是多少，能够选定时间段自动展示。
2. 指标越丰富越好，如果销售额下降了，看看是不是订单数下降了，订单数没变是不是客单价的问题，是由于商品结构的原因还是活动门槛调整导致的。
3. 数据分析的能够下达的粒度越细越好。比如数据粒度可以从全国下钻到省份，从省份下钻到城市，这样交易额下降了就能知道是哪个省哪个城市出了问题？就能针对性的解决。
经过以上几个步骤，即可形成平台雏形，形成规划文档。但一个数据分析平台，无论前期规划得多么丰富，也不可能一蹴而就。公司的业务在不断变化，分析的内容也越来越丰富，在这过程中总需要不断磨合和调整，只有不断完善之后，才能形成一个更加量身定制的实用平台。
2024年公司数据库建设 篇2
想在企业中做好数据分析，无非就是三件事情：选对工具和方法，结合业务需求，让老板点头（也叫作内部推广）。
工具和方法自然不用多说，这里我就不多做介绍，题主应该也都清楚，下面我只讲怎么结合业务需求分析和进行内部推广。一、结合业务
我们都知道数据的最终价值还是要落实到业务上，得出更好的决策，让利润增加，让成本降低，让风险减少，让效率提升等等。
那数据分析在这过程中扮演的角色就是，用数据把业务的现状清晰描述，让业务更清晰；然后从业务现状里挖掘出有价值的点，利用数据分析的方式提升好的数字，降低坏的数字，让业务做出正确决策。
说来说去，就是一个关键词：业务。
了解业务，一般从两个角度/方向着手：锁定部门和KPI，从我们的经验讲起围绕他们的困难点，切磋思路，从而挖掘到真实的需求
为了理清思路，我们可以填好下面这个表格：
也就是说，你需要知道和你对接的业务部门每天，每个月都在做什么？他们最关注什么数据？由哪些环节会产生数据？以及哪些行为对数据会产生影响？为什么这些行为会对数据产生影响？影响的幅度大吗？回答好了上面这个表格的问题，你就算对业务有所了解了。
那该怎么具体了解呢？可以通过业务模式、产品、渠道、用户、运营、部门、KPI来充分了解一个公司的业务、信息。
先建立基本概念，明白到底企业：可以有几种模式：To B模式还是 To C 模式？必须有哪些角色：包括产品，渠道，用户，运营。他们在三大问题（是什么，为什么，怎么做）上有什么基本特征？如果想分析，切入点有哪些？为什么？
再结合具体情况，把部门，KPI与套路结合，深入理解部门现状。
有了思路，我们具体怎么做呢？总结一下就是下面三个步骤：
1、理解业务的本质。也就是业务是怎么挣钱的，其背后是对整个业务经营模式的理解，比如，某个业务是靠什么挣钱的，要理解产品；挣的是谁的钱，要挖掘用户需求；怎么吸引用户来挣钱，要搞清业务渠道；靠谁来挣钱，要掌握业务分工。
2、梳理业务信息，建立分析系统。业务的复杂程度决定了系统的复杂程度，若一个复杂的业务能够被梳理的逻辑清晰条理清晰，系统也不会很复杂，但前提是你很懂很懂业务。比如，业务环节的处理动作是否清楚？跨部门的业务关系是否了解？业务基础数据、信息流向是否掌握？
3、带着数据意识去看业务。业务分析的逻辑思维是以业务经验为基础的，有时候跟业务走的太近往往会忘记了数据方法论，从而使得业务脱离了数据，导致结果偏离实际，不能为决策提供支持。因此，要带着数据意识去看业务，才能加深对业务的理解，否则跟普通的业务人员就没有区别了。二、内部推广
不管是选择数据分析的方法、工具，还是结合业务需求进行分析，都不是整个数据分析过程中最困难，如何让老板、其他部门、基层员工意识到数据分析的重要性才是最重要的关键一步！
某位数据专家说过，数据分析的最好实现价值应该是不仅得到有创造力价值的数据分析结果，还要能够让数据和业务部门合作。但是现状是，很多企业没有学会走，就开始了跑，如果说互联网的数据分析是短平快，那大部分企业的数据分析工作更需要一步一步来。
1、用户有痛点，老板也有痛点。当领导负责了数据管理，并开始去对比分析管理情况，看到了他一直想要关心的结果，数据的价值就出现了。
但是怎么具体实施呢，结果或者目标是要被领导认可，那么一定要落脚到如何实现，比如满足领导关心和棘手的问题解决，优先把眼下的痛点解决，那么数据的好处就在于可以把日常数据，关键的指标，包括人员绩效，核心客户销量等关心的结果，用可视化的方式呈现，同时做分析和KPI管理，就能带来领导的认可。
2、用数据分析的过程去优化管理决策。换句话说，不要让领导拍脑袋想决策，而是用数据分析去辅助领导决策，那么这个过程就是一个分析场景，然后具体决策也会有那么几个方向，比如上层的是战略决策，或者公司业务决策和经营决策等等，影响都不一样，战略层面影响是最大，一般企业都是会过好几年，或者更长去做一次战略变化。
当然中小企业可能会把这个周期缩短，其次是公司业务决策，数据分析只有把每个业务部门核心目标都服务好，比如公司建立了一个数据中心平台，会定一些目标和不定时的成果展示，那么业务人员和领导的分享，建议及评价就会帮助这个平台不断改善，也就能持续把数据的效力发展出来。
3、可视化这种东西永远都不过时。学会告诉领导数据分析带给企业的效益，用一个有表现力的图表或报告让领导眼前一亮，也许背后开发的心血可能领导看不到，但是一个非常亮丽的报表尤其是在超越了领导期望的情况下才是IT的最高境界。数据分析要在领导下一个需求位置等而不是永远跟在他的需求后面跑，力求创新。
4、细节着手，潜移默化地培养领导和老板的数据化意识。首先，让数据快速地展现，创造方便，尽量少用邮件Excel以及纸质报表，可以用移动端把领导关心的指标展示出来，每天定时定点推送，培养这样的习惯。
其次，数据分析和大数据已经成为很多的共识，外界各行各业都有关于数据的大会，有特定的CIO圈，老板圈，比如地产界的明源。其实老板比任何人都重视效益和效率，可以说服他们经常参加这样的会议，看行业其他人如何做的，看竞品如何做的。
最后，汇报时强调这是数据分析带来的结果，现在很多汇报都可以用电子的形式，总监可以直接用数据发报的功能跟领导汇报。
2024年公司数据库建设 篇3
数据的重要性不言而喻，已经被越来越多的公司接受、熟知和应用。那么关乎数据，到底在哪些方面可以促进业务的腾飞？或者换种说法，业务对数据有哪些层次的需求？还有，数据对管理有哪些方面的贡献？
依据我多年在数据分析岗位上的工作经验和对业务的理解，业务对数据的需求可归纳为四个层次。
第一层：知其然
就是知道数据是多少，发生了什么情况。就如目前大多数企业都会有自己的数据库，严格一点会有对应的系统对应的业务数据库，数据收集的工作已经完备了，无论是通过报表还是数据分析的手段，都可以掌握发生了什么，程度如何，建立数据监控体系，做到“知其然”。也有一些企业，在管理内部数据的同时，也在考虑外部数据的引进，向第三方机构买数据，观察行业整体趋势、政策环境的影响，其次了解竞争对手的表现。这样的数据工作是长期的也可是周期性的管理。长期的可尽力数据展现模板，形成一定的管理规范，固化下来。短期性的比如监测某次营销活动的情况，可联合IT部门或者数据分析师自己动手，做到严格的“自省”。
1、数据是散的，看数据需要有框架。
数据展现很有讲究，把数据放到业务框架，能体现业务分析，才能发挥整体价值。所谓有效的框架至少包含两重作用：
（1）不同层级的人对数据的需求不同。比如市场销售数据，业务层需要指导自己每日指标的完成情况和等级排名，需要提交每日每周每月的数据。领导层需要知道固定周期的业绩完成率，各地区销售额，营销成本和组内业绩排名。管理层，CEO级别的可能需要知道每个业务部门的一些关键指标，比如总营收，市场增长率，重要的研发进度等等。有效的框架能够让不同的人各取所需。
（2）好的框架能定位问题，指导决策制定。例如电商销售额下降了30%，业务很可能出现了重大问题。我们需要分析问题原因，但如果只从客单价、交易单数、转化率难以说明问题，好的业务分析框架能够支持我们往下钻，从品类、流量渠道等找到问题所在，找到对应负责人。这也是我们通常所说的，看数据要落地。
2、数据，有对比才能考量。
日销售额100万，你说多还是少呢？一个孤零零的数据是很难说明问题的。数据判断要么有一个参考的指标，要么有能准确判断趋势的指标数据，如增长率上升率。这样一个基准可以是历史总结的同期数据，也可以是行业的平均水平，也可以是预先设定的而目标，一切脱离目标的数据分析都是“耍流氓”。
第二层：知其所以然
遇到问题寻找原因这是很顺当的衔接。但走到这一步还不够，解决问题才是真理。数据结合业务，找到数据表象背后的真正原因，解决之。解决问题的过程就会涉及数据整理、加工，还会涉及数据分析模型的建立和工具，这在以往的篇幅已经介绍的够多的了。
在第二层里也有两点分享：
1、数据是客观的，但对数据的解读则可能带有很强的主观意识。
数据本身是客观的，但解读数据的人都是有主观能动性的。这样的问题往往是因为多数人通多数据先对问题定性，而不是通过问题解决问题，这样的事儿总有发生。
2、懂业务才能真正懂数据。
笔者认为，数据分析业务占6分，方法占4分。不懂业务无法理解数据的真正含义也是有理可寻的，这里特地拿出来强调一下。
第三层：辅助业务，发现机会
利用数据可以帮助业务发现机会。举个电商的例子，通过用户搜索的关键词与实际成交的数据比较，发现有很多需求并没有被很好地满足，反映出需求旺盛，但供给不足。假如发现了这样的细分市场，公布出来给行业小二，公布出来给卖家，是不是可以帮助大家更好地去服务消费者呢？这个例子就是现在我们在做的“潜力细分市场发现”项目。
讲这个案例不是想吹牛数据有多厉害，而是想告诉大家：数据就在那里，有些人熟视无睹，但有些人却可以从中挖出“宝贝”来。差异就在于商业感觉，对数据的直觉。搜索数据和成交数据很多人都能够看到，但并没有人把这两份数据联系在一起，这背后体现出的就是商业的感觉。
第四层：建立数据化运营体系
我理解的数据化运营，包含了两重意思：数据作为直接生产力和间接生产力。
1、数据作为直接生产力。
数据作为直接生产力是指数据能将价值直接投入到前线，作用于消费者，时髦点讲就是“数据变现”，这也是大家最为关注的。以前有沃尔玛将啤酒和尿布两个产品关联摆放，引出了商品关联度的概念。如今，又有餐饮企业利用数据统计分析，选型餐厅面积，优化前后厅布置，使得单位面积营收最大。
2、数据作为间接生产力。
所谓间接生产力，是指数据价值不直接传递给消费者或企业，而是需要通过一系列的分析，制定策略传递给消费者，即通常所说的决策支持。数据工作者通常做的是产出报表、分析报告等供各级业务决策者参考。我们可以称之为决策支持1.0模式。然而随着业务开拓和业务人员对数据重要性理解的增强，对数据的需求会如雨后春笋般冒出来，显然单单依赖人数不多的分析师是满足不了的。授人以鱼不如授人以渔，让业务人员能够独立地进行数据分析，而不依赖于技术人员是我认为的决策支持2.0模式。
实现决策支持2.0模式有两个关键：工具和能力。
如果让他们和数据从业者一样，掌握SQL，学会SPSS，SAS甚至R和Python，大可不必要。现在自助型的BI工具等低门槛、用户体验良好的数据产品完全可以让用户快速上手，比如自助式BI工具FineBI，最佳的使用方式是让IT人员准备好数据，按照权限，业务人员可以自己决定分析维度，将分析字段拖入表中，类似excel的数据透视表。这是实现决策支持2.0模式的基础。
当然，这里讲的产品，不仅仅是操作功能集，还需要承载分析思路和实际案例。数据分析的门槛还是有的，深入的分析还是得往数据分析师方向走，这就会对大家提出一些其他的基本能力，比如统计学知识，数学能力等等。但是内心若有强大的意愿，有持之以恒的毅力，那都不叫事儿。
2024年公司数据库建设 篇4
数据仓库（DW）起到了数据大集中的作用。通过数据抽取，把数据从源系统源源不断地抽取出来，可能每天一次，或者每3个小时一次（当然是自动的）。这个过程，我们称之为ETL过程。
那么，今天，我们就来谈一谈：如何搭建数据仓库，在这个过程中都应该遵循哪些方法和原则；然后介绍一些项目实践中的技巧。
一、数据仓库的架构
数据仓库（Data Warehouse DW）是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库，它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题的，以OLAP系统的分析需求为目的。
数据仓库的架构模型包括了星型架构与雪花型架构两种模式。星型架构的中间为事实表，四周为维度表，类似星星；而相比较而言，雪花型架构的中间为事实表，两边的维度表可以再有其关联子表，从而表达了清晰的维度层次关系。
从OLAP系统的分析需求和ETL的处理效率两方面来考虑：星型结构聚合快，分析效率高；而雪花型结构明确，便于与OLTP系统交互。因此，在实际项目中，我们将综合运用星型架构与雪花型架构来设计数据仓库。
那么，下面我们就来看一看，构建企业级数据仓库的流程。
二、构建企业级数据仓库五步法
（一）、确定主题
即确定数据分析或前端展现的主题。例如：我们希望分析某年某月某一地区的啤酒销售情况，这就是一个主题。主题要体现出某一方面的各分析角度（维度）和统计数值型数据（量度）之间的关系，确定主题时要综合考虑。
我们可以形象的将一个主题想象为一颗星星：统计数值型数据（量度）存在于星星中间的事实表；分析角度（维度）是星星的各个角；我们将通过维度的组合，来考察量度。那么，“某年某月某一地区的啤酒销售情况”这样一个主题，就要求我们通过时间和地区两个维度的组合，来考察销售情况这个量度。从而，不同的主题来源于数据仓库中的不同子集，我们可以称之为数据集市。数据集市体现了数据仓库某一方面的信息，多个数据集市构成了数据仓库。
（二）、确定量度
在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。
量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标（KPI）等的设计和计算。
（三）、确定事实数据粒度
在确定了量度之后，我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。
例如：假设目前的数据最小记录到秒，即数据库中记录了每一秒的交易额。那么，如果我们可以确认，在将来的分析需求中，时间只需要精确到天就可以的话，我们就可以在ETL处理过程中，按天来汇总数据，此时，数据仓库中量度的粒度就是“天”；反过来，如果我们不能确认将来的分析需求在时间上是否需要精确到秒，那么，我们就需要遵循“最小粒度原则”，在数据仓库的事实表中保留每一秒的数据，以便日后对“秒”进行分析。
在采用“最小粒度原则”的同时，我们不必担心海量数据所带来的汇总分析效率问题，因为在后续建立多维分析模型（CUBE）的时候，我们会对数据提前进行汇总，从而保障产生分析结果的效率。关于建立多维分析模型（CUBE）的相关问题，我们将在下期栏目中予以阐述。
（四）、确定维度
维度是指分析的各个角度。例如我们希望按照时间，或者按照地区，或者按照产品进行分析，那么这里的时间、地区、产品就是相应的维度。基于不同的维度，我们可以看到各量度的汇总情况，也可以基于所有的维度进行交叉分析。
这里我们首先要确定维度的层次（Hierarchy）和级别（Level）（图四：pic4.bmp）。如图所示，我们在时间维度上，按照“年-季度-月”形成了一个层次，其中“年”、“季度”、“月”成为了这个层次的3个级别；同理，当我们建立产品维度时，我们可以将“产品大类-产品子类-产品”划为一个层次，其中包含“产品大类”、“产品子类”、“产品”三个级别。
那么，我们分析中所用到的这些维度，在数据仓库中的存在形式是怎样的呢？
我们可以将3个级别设置成一张数据表中的3个字段，比如时间维度；我们也可以使用三张表，分别保存产品大类、产品子类、产品三部分数据，比如产品维度。
另外，值得一提的是，我们在建立维度表时要充分使用代理键。代理键是数值型的ID号码，它唯一标识了每一维度成员。更重要的是，在聚合时，数值型字段的匹配和比较，JOIN效率高，便于聚合。同时，代理键对缓慢变化维度有着重要的意义，在原数据主键相同的情况下，它起到了对新数据与历史数据的标识作用。
在此，我们不妨谈一谈维度表随时间变化的问题，这是我们经常会遇到的情况，我们称其为缓慢变化维度。
比如我们增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，我们在ETL的过程中，就要考虑到缓慢变化维度的处理。对于缓慢变化维度，有三种情况：
1、缓慢变化维度第一种类型：历史数据需要修改。这种情况下，我们使用UPDATE方法来修改维度表中的数据。例如：产品的ID号码为123，后来发现ID号码错了，需要改写成456，那么，我们就在ETL处理时，直接修改维度表中原来的ID号码为456。
2、缓慢变化维度第二种类型：历史数据保留，新增数据也要保留。这时，要将原数据更新，将新数据插入，我们使用UPDATE / INSERT。比如：某一员工2005年在A部门，2006年时他调到了B部门。那么在统计2005年的数据时就应该将该员工定位到A部门；而在统计2006年数据时就应该定位到B部门，然后再有新的数据插入时，将按照新部门（B部门）进行处理，这样我们的做法是将该维度成员列表加入标识列，将历史的数据标识为“过期”，将目前的数据标识为“当前的”。另一种方法是将该维度打上时间戳，即将历史数据生效的时间段作为它的一个属性，在与原始表匹配生成事实表时将按照时间段进行关联，这种方法的好处是该维度成员生效时间明确。
3、缓慢变化维度第三种类型：新增数据维度成员改变了属性。例如：某一维度成员新加入了一列，该列在历史数据中不能基于它浏览，而在目前数据和将来数据中可以按照它浏览，那么此时我们需要改变维度表属性，即加入新的字段列。那么，我们将使用存储过程或程序生成新的维度属性，在后续的数据中将基于新的属性进行查看。
（五）、创建事实表
在确定好事实数据和维度后，我们将考虑加载事实表。
在公司的大量数据堆积如山时，我们想看看里面究竟是什么，结果发现里面是一笔笔生产记录，一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据，即关于某一主题的事实记录表。
我们的做法是将原始表与维度表进行关联，生成事实表。注意在关联时有为空的数据时（数据源脏），需要使用外连接，连接后我们将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各量度数据，这将来自原始表，事实表中将存在维度代理键和各量度，而不应该存在描述性信息，即符合“瘦高原则”，即要求事实表数据条数尽量多（粒度最小），而描述性信息尽量少。
如果考虑到扩展，可以将事实表加一唯一标识列，以为了以后扩展将该事实作为雪花型维度，不过不需要时一般建议不用这样做。
事实数据表是数据仓库的核心，需要精心维护，在JOIN后将得到事实数据表，一般记录条数都比较大，我们需要为其设置复合主键和索引，以实现数据的完整性和基于数据仓库的查询性能优化。事实数据表与维度表一起放于数据仓库中，如果前端需要连接数据仓库进行查询，我们还需要建立一些相关的中间汇总表或物化视图，以方便查询。
三、什么是ETL
在数据仓库的构建中，ETL贯穿于项目始终，它是整个数据仓库的生命线，包括了数据清洗、整合、转换、加载等各个过程。如果说数据仓库是一座大厦，那么ETL就是大厦的根基。ETL抽取整合数据的好坏直接影响到最终的结果展现。所以ETL在整个数据仓库项目中起着十分关键的作用，必须摆到十分重要的位置。
ETL是数据抽取（Extract）、转换（Transform）、加载（Load ）的简写，它是指：将OLTP系统中的数据抽取出来，并将不同数据源的数据进行转换和整合，得出一致性的数据，然后加载到数据仓库中。例如：下图就向我们展示了ETL的数据转换效果。
那么，在这一转换过程中，我们就完成了对数据格式的更正、对数据字段的合并、以及新增指标的计算三项操作。类似地，我们也可以根据其他需求，完善数据仓库中的数据。
简而言之，通过ETL，我们可以基于源系统中的数据来生成数据仓库。ETL为我们搭建了OLTP系统和OLAP系统之间的桥梁。
五、项目实践技巧
（一）、准备区的运用
在构建数据仓库时，如果数据源位于一台服务器上，数据仓库在另一台服务器端，考虑到数据源Server端访问频繁，并且数据量大，需要不断更新，所以可以建立准备区数据库。先将数据抽取到准备区中，然后基于准备区中的数据进行处理，这样处理的好处是防止了在原OLTP系统中频繁访问，进行数据运算或排序等操作。
例如我们可以按照天将数据抽取到准备区中，基于数据准备区，我们将进行数据的转换、整合、将不同数据源的数据进行一致性处理。数据准备区中将存在原始抽取表、转换中间表和临时表以及ETL日志表等。
（二）、时间戳的运用
时间维度对于某一事实主题来说十分重要，因为不同的时间有不同的统计数据信息，那么按照时间记录的信息将发挥很重要的作用。在ETL中，时间戳有其特殊的作用，在上面提到的缓慢变化维度中，我们可以使用时间戳标识维度成员；在记录数据库和数据仓库的操作时，我们也将使用时间戳标识信息。例如：在进行数据抽取时，我们将按照时间戳对OLTP系统中的数据进行抽取，比如在午夜0：00取前一天的数据，我们将按照OLTP系统中的时间戳取GETDATE到GETDATE减一天，这样得到前一天数据。
（三）、日志表的运用
在对数据进行处理时，难免会发生数据处理错误，产生出错信息，那么我们如何获得出错信息并及时修正呢? 方法是我们使用一张或多张Log日志表，将出错信息记录下来，在日志表中我们将记录每次抽取的条数、处理成功的条数、处理失败的条数、处理失败的数据、处理时间等等。这样，当数据发生错误时，我们很容易发现问题所在，然后对出错的数据进行修正或重新处理。
（四）、使用调度
在对数据仓库进行增量更新时必须使用调度，即对事实数据表进行增量更新处理。在使用调度前要考虑到事实数据量，确定需要多长时间更新一次。比如希望按天进行查看，那么我们最好按天进行抽取，如果数据量不大，可以按照月或半年对数据进行更新。如果有缓慢变化维度情况，调度时需要考虑到维度表更新情况，在更新事实数据表之前要先更新维度表。
调度是数据仓库的关键环节，要考虑缜密。在ETL的流程搭建好后，要定期对其运行，所以调度是执行ETL流程的关键步骤。每一次调度除了写入Log日志表的数据处理信息外，还要使用发送Email或报警服务等，这样也方便的技术人员对ETL流程的把握，增强了安全性和数据处理的准确性。
五、总结
构建企业级数据仓库需要简单的五步，掌握了这五步的方法，我们可以构建一个强大的数据仓库。然而，每一步都有很深的内容需要研究与挖掘，尤其在实际项目中，我们要综合考虑。例如：如果数据源的脏数据很多，在搭建数据仓库之前我们首先要进行数据清洗，以剔除掉不需要的信息和脏数据。
ETL是OLTP系统和OLAP系统之间的桥梁，是数据从源系统流入数据仓库的通道。在数据仓库的项目实施中，它关系到整个项目的数据质量，所以马虎不得，必须将其摆到重要位置，将数据仓库这一大厦的根基筑牢！