数据仓库和多维数据库的区别在哪里
发布网友
发布时间：2022-04-23 00:49
共3个回答
懂视网
时间：2022-04-09 09:26
数据仓库中广泛采用的数据库设计模型有两种：关系型和多维型。普遍认为在数据仓库的设计方法中关系模型是“Inmon”方法而多维模型是“Kimball”方法。
先来看下关系模型，关系型数据以一种称为“标准化”的形式存在。数据标准化是指数据库设计会使数据分解成非常低的粒度级，标准化数据以一种孤立模式 存在，这种情况下对数据表里的数据关系要求很严格。一般遵循3NF范式。采用关系型设计的数据库一般具有较强的灵活性和多功能性（可以支持数据的多种视 图）。
再来看下多维模型，多维模型一般有星型模式、雪花模式、混杂模式（又叫星系模式）。多维模型设计的最大优点在于访问的高效性。
两种模型的区别
作为数据仓库设计的基础，星形连接和关系型结构两者之间存在很多不同。最重要的区别是在灵活性和性能方面。关系模型具有高灵活性，但是对用户来说在性能方面却不是很理想的。多维模型在满足用户需求方面是非常高效的，但是灵活性不好。
另一重要区别在于设计的范围不同。必然地，多维设计只能在有限的范围内进行，也就是说，数据库设计只能在一组请求过程下得到最优化。如果所有不同组请求全部加入到设计当中，最优化变得毫无意义。
当使用关系模型时，在性能方面没有特别的优化方法。既然关系模型要求数据以最低粒度级存储，那么就可以无限制地添加新数据。很显然，添加数据到关系 模型永远也不会停止。正因为这样，关系模式适合大范围数据（如一个企业模型）,而多维模型适用于小范围数据（如一个部门或甚至一个子部门）。
区别的起源：
关系环境是通过起源数据模型设计出来的。多维模型是根据最终用户的请求塑造的。换句话说，关系模型通过纯数据模型和其他模式设计，而多维模型通过处理请求塑造。
在适用性方面：由于关系模型通过抽象数据形成，所以模型自身非常灵活。但这种灵活性，对于直接数据访问的执行却不是最优化的。如果想得到一个高性能的关系模型，最佳方法是从模型中抽取出数据，并重新构造一种适合于快速访问的模式。
多维模型在直接访问数据方面是快速而高效的。从体系结构观点来看，在数据仓库设计基础方面关系模型是更好地支持数据仓库的模式，其原因是，数据仓库需要根 据不同的议程和多种观察数据的方式来支持许多不同的用户组。也就是说，数据仓库对于访问已给定的用户并不是最佳的。相反，数据仓库可以以多种方式支持多个 不同的用户。
关系模式，数据以最低粒度级和标准化形式存储；关系表间的关系已经定义好并且包含一个含有外键的关键字表；新表可以对关系表中的基本数据集定义新的 汇总和筛选标准；也就是说可以很简单以一种形式创建关系表，再以另一种形式重新塑造这些表，这样做对于数据仓库环境来说是非常理想的。
此外，关系模式支持将来未知的需求、支持适度变化的需求方面具有多维模型无法比拟的优势。
因此根据上面讨论过的原因可以看出：关系模型对数据仓库是理想的基础，而星形连接对于数据集市是最佳的。
独立集市和从属集市的区别：
独立集市是指直接通过历史应用创建的数据集市。建立独立数据集市不需要有“全局思想”考虑。
与独立数据集市相对应的是从属数据集市。从属数据集市是利用来自数据仓库的数据建立的。它的数据源不依赖与历史数据或操作型数据，只依赖于数据仓库。总之，从属数据集市要求有预先的计划、长期的观察、全局的分析和企业各不同部门对需求分析的合作与协调。
建立多个独立数据集市后，很快用户就会发现数据集市之间的信息不统一，也不同步，而且每增加一个数据集市就会出现不断增长的细节数据冗余的问题，需要大量的资源来建立接口程序，维护这些程序也变成了负担。因此独立数据集市不适合与解决企业中的信息问题。
当然，如果企业采用了从属数据集市，并在建立任何数据集市之前先创建了一个数据仓库，那么，独立数据集市固有的哪些体系结构方面的问题就不会出现了。
换句话说,独立数据集市表示的是不需要顾及全局及全景的一个短期的、有限范围的解决方法。另一方面，从属数据集市则要求一个长期和全局的展望。但是独立数据集市不能为企业信息提供一个坚实的基础，而从属数据集市确能为信息决策提供了一个真正的长期基础。
总结：数据仓库中数据库设计推荐采用关系模式设计方法，而数据集市推荐采用多维模型设计方法，其中数据集市推荐采用从属型的数据集市构建方法。
数据仓库数据库设计方法---关系模型和多维模型比较分析
标签：
热心网友
时间：2022-04-09 06:34
数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。
单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。
数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。
补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。
1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。
2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。
3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。
热心网友
时间：2022-04-09 07:52
数据仓库的输入方是各种各样的数据源，最终的输出用于企业的数据分析、数据挖掘、数据报表等方向。
*数据库由一个基本维度（它表示没有应用任何读取端隐私策略的数据库）和许多用户维度（它们是数据库的转换副本）组成。
为了获得良好的查询性能，我们希望预先计算每个用户的Universe。如果我们天真地那样做，我们最终会有很多领域需要存储和维护，而存储需求本身将是令人望而却步的。
一个空间和计算效率高的*数据库显然不能将所有用户维度全部实现，必须支持对用户维度的高性能增量更新。因此，它需要支持高性能更新的部分具体化视图。最近的研究提供了这个丢失的密钥原语。具体来说，可伸缩的并行流数据流计算系统现在支持部分有状态和动态变化的数据流。这些想法使得建立一个高效的多元维度数据库成为可能。
因此，我们将基础维度中的数据库表作为数据流的根顶点，并且随着基础维度的更新，记录将通过流移动到用户维度中。当数据流图中的边跨越通用边界时，将插入任何必要的数据流运算符以强制执行所需的隐私策略。所有适用的策略都应用于转换到给定用户群的每个边缘，因此无论数据通过哪个路径到达该边缘，我们都知道策略将被强制执行。
我们可以动态地构建数据流图，在第一次执行查询时为用户范围扩展流。通过在两个维度之间共享计算和缓存数据，可以减少基本更新所需的计算量。将其实现为一个联合的部分状态数据流是安全地执行此操作的关键。
通过将所有用户的查询作为一个联合数据流进行推理，系统可以检测到这样的共享：当存在相同的数据流路径时，它们可以合并。
逻辑上不同但功能上等价的数据流顶点也可以共享一个公共的后备存储。在给定的维度中，任何到达这样一个顶点的记录都意味着维度可以访问它，因此系统可以安全地公开共享副本。
