请教大家一个数据迁移的设计问题

[happy]

今天遇到一个数据迁移的问题，想了半天，不知是否正确，还请大家帮我指点一下吧。

我们要给客户实施数据仓库，先要把业务系统中的和复杂查询相关的操作都迁移到数据仓库中来，也就是说以后客户在业务系统中执行的复杂查询操作都是链接到数据仓库里面的数据中，而且有多个（五个）不同的业务系统，每个业务系统中需要的查询操作当然也不一样了。

第一步我打算先用数据库复制（目标、源相同时）、或者ETL工具来实现数据的迁移，到迁移到数据仓库中。但是对数据不做任何的处理，目标和源的结构都设计成一样，数据粒度也一样，把这一步骤的数据作为数据仓库中的详细数据；这时原来那些各自在各自的业务系统执行的查询，从物理上就分开了。

第二步我再根据需求按照事实表维表的设计方法进行数据的清洗、转换等处理；

第三步是进行轻度和深度的汇总，这些汇总数据是为分析需求准备的。


我现在有些疑惑的地方就是：
1 第一步和第二步需要存储的数据量应该是一样的，是不是太冗余了？
2 第一步和第二步是否应该合成一步来进行？如果合成一步的话，数据是迁移了，可以应用好像还没有迁移，各个系统中原来的查询如果按照第二步的数据来查询的话，会不会有差距？


不知我描述清楚没有，希望大家能抽空帮忙想想！

谢谢


　　　　　　　　致
礼！


　　　　　　　　happy
　　　　　　　　xinin...@prient.com
　　　　　　　　　　2005-09-19

[happy]

我这么想好像确实不太好，简单的把数据从业务系统复制到数据仓库里面，除了数据物理上和业务系统分离外，性能不会有什么改善，也不是数据仓库的做法。应该还是在迁移的时候就对多个数据源上的数据进行清洗、转换等操作，按照星型模型把数据集成在一起，作为最详细的数据。

然后再在此基础上进行不同粒度的汇总。

那么如果我模型建好了，数据也都抽取上去了，这时再增加一个数据源的话，如何做呢？

曾经看过有关数据仓库总线的概念，说的是如何从先建立多个数据集市入手，最后实现数据仓库的方法。那么对于新加的数据源来说，可不可以也利用类似的方法呢？先对应新的数据源建模，然后和已经建好的数据源比较，利用数据仓库总线的方法把两个模型集成在一起？

请大家指点一下吧！

谢谢



======= 2005-09-19 15:51:00 您在来信中写道：=======

= = = = = = = = = = = = = = = = = = = =

[Liu Qing]

其实你说的第一步在联通经营分析中就叫做ODS，大多数项目的ODS。当然，对于ODS究竟该如何设计并没有定论，所以在现实中也就存在着不同的建立方法。譬如郁闷派的理论中，这个ODS应当是3NF的，是对企业信息结构一次重新建模，之后数据可以流向企业数据仓库（EDW）或是数据集市。

 

然而，对于球派来说，他并没有强调3NF，甚至同样需要维度建模。这可以从这两派对数据仓库项目建设的方法论来区别，郁闷派有些自上而下的感觉，而球派注重实用。这有些扯远了。

 

不管如何，这个ODS的提出，一个很大的作用就是屏蔽掉对生产系统的压力，让各个系统分工更加明确一些。例如你提到的这个需求，业务系统应当将重点放在事务处理上面，至于复杂的查询，还是交给数据仓库系统负责好些，大数据量查询不是事务系统的强项。

 

就我所见的项目，能够达到郁闷派ODS那样的，很少有达到。一如我以往的观点，国内的从业人员并没有累积到那样的经验。常见的ods正是你所设想的"原封不动地按业务系统照办过来"，即便总体的方法论可能是沿用inmon的，例如ibm的数据仓库方案。当然，也有在ods就开始维度建模的例子，譬如说我们大多数项目都是如此，但仅仅也是进行维度转换和数据清洗，很少有业务重新建模的。然而不得不说，前者是数据仓库项目初期更好的策略，简单啊。在对业务不能充分理解的情况下，如果过早进行维度转换、数据清洗，甚至是重新建模，必然失去一些信息，造成最后数据统计的误差，也就是大家所看重的"数据质量"问题。这时，如果采用前者方案，当然有个保底方案——"大不了我从ODS取数据"。

 

当然，如果有了对业务重新建模的信心，那又另当别论。

 

[happy]

Liu Qing,您好！

还有两个问题：
1 如果项目的预算很少呢，真的是少的可怜（多少原谅我现在还不能说）。从公司成本来考虑，刘庆兄经验多，又是哪种比较合适呢？
2 就是我在另一封信里面提到的，在可以预测的将来，会有新的业务系统要加入到这个DW系统中，并且还会有新的系统取代现有系统的需求，对于这种情况，自上而下的方法是不是更合适呢？

happy


======= 2005-09-19 17:30:00 您在来信中写道：=======

= = = = = = = = = = = = = = = = = = = =

[Chang, Jay-JH]

让我来尝试回答happy的问题。如有不到之处，请liuqing兄拍砖。：）
在预算有限的前提下，是不是可以自上而下设计，自下而上开发。可以先从从需求出发，开发单独数据集市开始，这样项目成功的把握比较大。但是数据仓库的总体设计建议采用自上而下的方法，毕竟要考虑以后多个业务系统的兼容性和扩展性。在设计当前集市纬度时，考虑通用性。

至于那个ODS，比较保守的做法都是照搬业务系统数据，仅起到和业务系统隔离，减轻业务系统压力的目的。

IMPORTANT NOTICE:

The information in this email (and any attachments) is confidential.
If you are not the intended recipient, you must not use or disseminate the information.
If you have received this email in error, please immediately notify me by "Reply" command
and permanently delete the original and any copies or printouts thereof.
Although this email and any attachments are believed to be free of any virus or
other defect that might affect any computer system into which it is received and opened,
it is the responsibility of the recipient to ensure that it is virus free and no responsibility
is accepted by American International Group, Inc. or its subsidiaries or affiliates either
jointly or severally, for any loss or damage arising in any way from its use.

[Liu Qing]

在项目预算和目标之间的平衡选择，比较难说。但一般情况下，你之前考虑的那种方式应该成本不算太高，当然还得看数据量了，ods存储细节数据还是比较费存储的。

 

至于未来如何，有一点我现在倒是坚信——不去预测什么。如果能够看到变化，自然会将这些变化考虑在设计当中，否则，恐怕只是一厢情愿。有很多项目的例子证明人们在过度设计，当然，这种过度设计的另一种表现也是不满足需求。可能这个回答并不贴近西宁的问题，仅仅谈出个人的看法而已。
 

刘庆

9/20/2005
 

[iamg...@yahoo.com.cn]

看你就是当心存储冗余呀，冗余有什么，花不了多少成本。

不过，移动这边好像报表一类的都由数据仓库系统来完成了，所以你的1、2也可以合为一步来应付拮据的空间，清洗前后的影响，用户会慢慢接受。

[王艳丽]

iamgyyan,您好！

你是不是发错人了?我又不认识你，而且莫名其妙，你说的东西我不明白

======= 2005-09-21 09:50:40 您在来信中写道：=======

>看你就是当心存储冗余呀，冗余有什么，花不了多少成本。
>
>不过，移动这边好像报表一类的都由数据仓库系统来完成了，所以你的1、2也可以合为一步来应付拮据的空间，清洗前后的影响，用户会慢慢接受。

= = = = = = = = = = = = = = = = = = = =


　　　　　　　　致
礼！

　　　　　　　　王艳丽
　　　　　　　　wang...@lianchuang.com
　　　　　　　　　　2005-09-21

[happy]

王艳丽,您好！

应该不会发错，你一定是订阅了这个googlegroup。:)有句老话：同是天涯沦落人，相逢何必曾相识。看你的邮件地址，你应该是上海联创的吧，联创的数据仓库水平挺高的，平时多往这个googlegroup发些文章吧，让我们大家也互相学习一下。

happy


======= 2005-09-21 11:48:00 您在来信中写道：=======

　　　　　　　　happy
　　　　　　　　xinin...@prient.com
　　　　　　　　　　2005-09-21

[golde...@163.com]

我觉得为了避免大量数据的复制，可以去掉为统计分析不关心的非数值型数据。另外，数据中大部分是交易类（包含时间戳）的，如果不需要
达到那样细的粒度，可以在ODS中作简单汇总，将数据量降低一个量级。