|
bsp;
在明白了涉及数据仓库的几大要素之后，OK! Let’s go on. 下面的问题将很深入的讨论类似于设计细节和管理细节的话题。看过之后需要深入的思考，这才能从中领悟作者的本意。主要原因也包括翻译问题。
来看看第一个问题：
数据仓库的粒度
数据仓库中的粒度是指数据的详细程度，同样为了描述一个情况，我可以用很多的数据，但同样我也可以只用必需的数据。而这起决于存储器。如果有很大的硬盘，那就没有我们不能存的事情。所以，估计一年内里表中的最大行数和最小行数，是设计者的最大问题。这里牵扯到了一个概念：上下限推测的方法。（别问我，我也不懂）
然后通过简单的计算可以知道数据库大概的情况，然后可以调整我们的策略。说的仔细一点，我们可以采用双重粒度或者单一粒度的办法。
双重粒度是降低数据量的最佳方法。而且，大多数公司都采用这种方法。下面来一个分析：
双重粒度包括：低细节级和高细节级。要知道：在很低的细节级上建立轻度汇总数据是没有意义的。反过来，在太高的细节级建立汇总数据也是没有用的。所以，一定要进行数据粒度的评估，然后才能得出最佳的汇总方案。而可笑的是，这根本都是猜测出来的，没有正确性的保证，嘿嘿，没办法，谁让我们本来就是在做一件不知道条件，指知道结果的方程式呢，但你可以把你的结果给最终用户看，让她来评价这个好坏，别指望%100的通过，%50就很不错了：）
这里有一些反馈技巧和一个例子，在90页，你可以参考一下。
如果说，数据粒度教你建数据仓库的话，下一个话题就是教你管理啦！
数据仓库和技术
这里有好多我看不懂的管理技术，嘻嘻，比如说：通过寻址，通过检索，通过数据外延，通过有效的溢出管理…… 这里的管理包括：管理大量数据库的能力和能管理好数据仓库的能力。任何生成支持数据仓库的技术都要满足能力于效率的要求。
你要能管理多介质，主存、扩展内存、高速缓存、DSAD(如硬盘)、光盘、磁带……
数据仓库的灵魂就在于灵活性和对数据的不可预测性的访问，看不懂么？所的简单点，就是它能对以往所有的数据进行评估，提供分析依据。数据仓库如果不能方便有效的利用索引，那么数据仓库的建立就是不成功的。多利用一些二级索引、动态索引、临时索引等等。
多种技术接口，这我不用再解释了吧，这你应该明白的。
对数据存放位置的控制，就像一开始讲的，必须使数据仓库有一整套完善的数据存放机制。而且最好是自动的噢！
数据的并行存储和管理，假定对数据的访问都是等概率的，则性能的提高与数据所分布的物理设备的多少成正比。
元数据的管理，记住这个事实吧，再好的房子，如果没有钥匙你也没办法！！所以，管理元数据的重要性甚至超过了管理数据仓库中的数据。这包括表的结构，表的属性，源数据（纪录系统），映射关系，数据模型说明，抽取日志，共用例行程序。
语言接口，SQL语言接口，就是你要做一个前台控制程序，可以插入、删除……。
数据的高效装入，自己想吧，（什么，老师偷懒，我就偷懒，怎么样）这里没有什么好说的，你需要根据不同的环境做不同的处理。
高效索引的利用、数据压缩、复合键码、变长数据、加锁管理、快速恢复。我就不再多说了，这你比我还明白。
DBMS类型和数据仓库,
多维数据库管理系统（俗称”数据集市”），提供了一种信息系统结构使得对数据库的访问非常灵活。如果我没理解错误的话，数据集市提供了一种数据的管理、考察方案，所以它是凌驾于数据仓库之上的，所以数据仓库的数据，是数据集市的主要数据来源，可以这么说，两者的差别就在于数据粒度的不同，数据仓库中的粒度很小，DBMS的数据粒度很大。当然，这样做是有目的的，这不仅是为了使储存的时间更长，也可以数据更集中！
这里还有很多其他的作用：
例如：
ü 支持数据的动态连接。
ü 能够支持通用的数据更新处理。
ü 关系结构清晰明了。
那它是不是就完美了呢？其实不然！其实也有不少弊病需要克服。
数据量不如关系数据库支持的那么多。
¨ 不支持通用的更新技术。
¨ 张如时间长。
¨ 结构不灵活。
¨ 动态支持还有问题。
这是我看完数据仓库后的一点感受，拿出来大家一起研究、研究，哈哈……
上一页 [1] [2] [3]
没有相关教程
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
