微软BI开拓者

在数据仓库(DW)之前使用ODS,将各分系统中的数据集成到此,在此基础上进行数据仓库的事实表与维度表加载,增量更新策略:使用缓慢变化维度,由源数据进入ODS使用完全更新,由ODS进入DW使用保留历史增量更新.

ＯＤＳ中存储各源系统数据，包含着实时数据，是源系统数据的快照，从源到ＯＤＳ的转换是复杂的，不止因为源系统结构复杂，多系统的数据集成，更有转换时各种ＭＡＰＰＩＮＧ关系的复杂性，所以ＥＴＬ架构设计的好坏直接关系到整个系统的稳定性，由于客户信息保密，不方便将架构设计传上来，有兴趣的朋友可以私下讨论．

１＼　架构设计图：
２＼　数据处理流程图（控制流部分）：
３＼　数据处理流程图（数据流部分）：


 附件: 您所在的用户组无法下载或查看附件

请问在实际应用中，
应主要依据哪些内容或指标来分别建立DW和ODS？
ODS是否也有提供给终端用户的应用？
是否允许用户直接修改DW和ODS中的数据？如果可以，又如何保持数据的一致性？
谢谢

这个要看用户需求,对于你的多个问题,分别回答如下:
1\ 应主要依据哪些内容或指标来分别建立DW和ODS？
    依据用户的需求和数据源的复杂程度,ODS的功能是存储当前各数据源的数据快照,不保留历史信息,ODS是各数据源的大集成,在这里数据还没有做一致性处理,用户可以基于此ODS数据对当前数据进行查询,可以做简单的报表,这里的指标(例如量度)与DW一致,不过缺少计算成员(例如财务上的同比,环比等,但这些可以在DW中处理得到,也可以在CUBE中建立KPI); 基于ODS数据建立DW,在DW中非常重要的一点,也是DW与ODS的主要区别是DW保留历史数据.在DW中,数据得到集成,异构数据在这里得到转换和一致性处理,各维度表和事实表里面的数据也得到集成且保留历史数据,各量度指标与ODS相同,且建立了其他更多需要的量度等数据信息.
2\ ODS是否也有提供给终端用户的应用？
    提供,基于ODS可以进行简要的报表查询,可以浏览当前细节数据,可以查看数据库快照.
3\ 是否允许用户直接修改DW和ODS中的数据？如果可以，又如何保持数据的一致性？
    这个问题很有代表性.ODS中的数据是可以修改的,在ODS中保留当前最新值,DW中保留当前值以及历史值.那么从源到ODS以及从ODS到DW都使用缓慢维度变化.具体是从源到ODS使用第一种缓慢变化---完全更新,这样做的原则是ODS只存储最新数据;从ODS到DW使用第二重缓慢变化---保留历史更新,这样做的原则是DW中保留历史数据,数据在DW中进行存储,后面的CUBE基于历史数据进行搭建.对于数据的一致性处理也使用缓慢变化.关于缓慢变化,这是我以前的一个总结:


对于缓慢变化维度，有三种情况：
1、缓慢变化维度第一种类型：历史数据需要修改。这种情况下，我们使用UPDATE方法来修改维度表中的数据。例如：产品的ID号码为123，后来发现ID号码错了，需要改写成456，那么，我们就在ETL处理时，直接修改维度表中原来的ID号码为456。
2、缓慢变化维度第二种类型：历史数据保留，新增数据也要保留。这时，要将原数据更新，将新数据插入，我们使用UPDATE / INSERT。比如：某一员工2005年在A部门，2006年时他调到了B部门。那么在统计2005年的数据时就应该将该员工定位到A部门；而在统计2006年数据时就应该定位到B部门，然后再有新的数据插入时，将按照新部门（B部门）进行处理，这样我们的做法是将该维度成员列表加入标识列，将历史的数据标识为“过期”，将目前的数据标识为“当前的”。另一种方法是将该维度打上时间戳，即将历史数据生效的时间段作为它的一个属性，在与原始表匹配生成事实表时将按照时间段进行关联，这种方法的好处是该维度成员生效时间明确。
3、缓慢变化维度第三种类型：新增数据维度成员改变了属性。例如：某一维度成员新加入了一列，该列在历史数据中不能基于它浏览，而在目前数据和将来数据中可以按照它浏览，那么此时我们需要改变维度表属性，即加入新的字段列。那么，我们将使用存储过程或程序生成新的维度属性，在后续的数据中将基于新的属性进行查看。


对于缓慢变化,SSIS中有个专门的组件,在后面我会详细介绍它.在该项目中,我们建立了90多个相关的事实表和维度表,每步数据处理我们都使用了缓慢变化,缓慢变化处理是解决维度表属性变化的好办法.

Roger,学习了
谢谢

受益匪浅~

我顶，我顶到你的肺

接触BI也有一段时间了，经过了项目的洗礼，我对ODS和DW数据库有了一些自己的看到，简单地谈一谈，欢迎大家多多指教：
1、
ODS数据库中可以分为SS、ODS、DW三种表，SS表中记录最原始的数据；ODS表中记录来自于SS表，并且经过了筛选和清洗后的数据；DW表记录最终数据；ODS表不是必要的表，可根据需要进行增减。例如，数据直接来自数据库，基本不需要进行清洗和转换，并且不需要经过数据的筛选和拆分，这个时候便可直接将数据由SS表导入至DW表；对于Excel数据源，由于Excel数据源的数据存在很多的问题，因此，进入SS表后，需要经过筛选和清洗，然后导入至ODS表，再根据需要对数据进行筛选和拆分，然后导入到需要的DW表中；如果有需要，还可以从DW表导入到其它的DW表。
2、
关于第1点中谈到的DW表记录最终数据，这里做个说明：个人认为，DW数据库中的表为最终数据表，不应该再对其进行任何的筛选、清洗或者通过DW库中的表抽取其它的表。而ODS库中的DW表就是DW库中表的原形，除了表的名称不一样外，表的结构以及表的字段类型、长度应该完全一致，也就是说DW库中的每个表都能够在ODS库中的DW表中找到一个原形。这样做开发者思路都很清晰，而且对于维护人员来说也方便，尤其在项目末期的时候，项目开发人员基本撤出，只会留下1-2人进行维护工作，当出现问题的时候就会发现，这样能够为维护人员节省出很多不必要的时间来解决真正的问题，而不是为了寻找各表之间的关系而浪费时间。
3、
DW库中的表分别以Dim和Fact作为前缀来命名表，Dim表示纬度表、Fact表示除纬度表以外包括事实表以及一些不容易界定的表。这样做同样是为了开发和维护能够更顺利。
4、
报表和cube的数据直接来自于DW库，不能够来自于ODS库。
5、
数据进入ODS库的时候可根据需要进行全量或增量更新；进入DW库的时候，采取全量更新，因为从ODS库到DW库的过程只是简单的导入过程，不会消耗很多时间，因此可以采用全量更新的过程。