新设计数据仓库应该如何规划结构呢？

xblues

公司已经有了生产数据库，现在需要设计以数据仓库，用来存储历史数据，便于分析查询。

生产数据库以及生产系统程序已经设计多年，数据库结构并不是完全结构化的设计方案。

那么数据仓库的库设计方案应该怎么做呢？是参考生产系统，进行表复制，然后插入历史记录呢？这种实现起来最简单，因为同构表，以后查询的时候 ，可以用过数据库编程，用这些原始表来更新数据仓库的后期设计的更加结构的表。

这样实现方法的好处是 ETL工具的实现步骤相对简单，其实就是表复制。大部分的编程都是直接在数据库内部实现的表转换。

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

上面是我的思路，有没有另外的思路呢？比如直接利用ETL工具实现表转换？有经验的同学分享一下自己的实战经验吧，谢谢！

kaile

没用过，坐等高手

aroma

围观中！

youngrex

如果是要做数据仓库，那肯定不能简单的做表复制，应该基于现有的生产数据库作为数据源，设计数据仓库。

Mike23

生产数据库一般是relational db， 但是数据仓库是dimensional db

google "Kimball Method"

nicoleflopy

我做这块的。
如果单纯表复制只是把查询分析的负荷从生产数据库上转移到数据仓库，但是考虑到查询和分析的性能，应该要好好利用ETL，如ls说的，dimension+fact表的结构要弄出来。

xblues

我试着看了一下生产数据库，有很多表没有主键和更新标志，如果利用ETL工具编写包，拷贝生产数据库到查询数据库的话，查询语句会很复杂。

而另外一方面，我觉得可是利用发布和订阅，在生产数据上建立发布，查询数据库上建立订阅，这样从数据库级别上每天同步数据到查询数据库，这就声调了ETL工具。

至于数据仓库的专门为了查询目的，可以在这些同步的表的基础上再建立查询数据库。

Mike23

可能是个好办法。但是对历史数据就没有办法了。