如果这似乎是一个新手问题,很抱歉,但我是数据仓库和商业智能世界的新手。
根据我所读到的内容,我可以看到,由于关系模型的限制,需要一个多维数据库。对于多维数据库,您需要做的任何事情都可以在具有非常复杂的查询和缓慢性能的连接和聚合操作的普通关系数据库上完成。
问题是,当我们谈论对象数据库的商业智能时,我们是否需要相同的概念(多维数据库-数据仓库等)?对象数据库没有连接,因为对象之间的关系是由直接引用维护的。
发布于 2009-09-08 00:27:33
多维性是数据仓库的一个基本特征。
对于关系模型的限制,这是而不是的“变通办法”。
星型模式查询并不是很复杂。它们实际上非常简单,因为它们几乎总是SELECT SUM(MEASURE) FROM FACT JOIN DIM1 ON ... JOIN DIM2 ON ... WHERE...的形式。
Join操作通常很慢。但是,连接可以在面向对象的代码中完成,而不是在SQL仓库中。
在许多情况下,大多数维度实际上相当小,完全可以放在内存中。分析查询可以简化为简单地获取所有事实,然后在内存中查找维度属性。
在这种情况下,数据库中的关系连接很有帮助。
“对象数据库没有联接,因为对象之间的关系是由直接引用维护的。”
并不是完全正确的。对象数据库具有从对象到对象的导航。如果您检索一组对象及其相关对象,则实际上已经执行了联接操作。
是。多维性是必不可少的。绝对一点儿没错。对象数据库表示这一点与关系数据库一样好(或者可能更好)。然而,这两个模型都必须代表度量及其维度的基本真理。
发布于 2009-09-08 00:38:27
也许您最好看看所谓的文档数据库。CouchDB是流行的、开源的(免费获取和销毁),并且简单易懂。CouchDB将所有数据存储为JSON (易于解析的JavaScript对象表示法)文档,并且仅使用REST (如果您是新手,只使用REST)与外部世界通信。更有趣的CouchDB特性之一是,您可以使用MapReduce范例选择数据来处理和聚合数据。
查看CouchDB可能会让您对非关系数据库的一些可能性有所了解。要知道,CouchDB主要关心的是存储数据文档,而不是整个对象。一些数据库是真正的对象数据库,因为它们在程序中存储给定对象的状态。请比较db4o。
https://stackoverflow.com/questions/1391215
复制相似问题