关系数据库与维度数据库数据库有什么区别？

Question

我正在尝试学习OLAP和数据仓库,我对关系和维度建模之间的区别感到困惑.维度建模基本上是关系建模,但允许冗余/非标准化数据？

例如,假设我有(产品,城市,#销售)的历史销售数据.我理解以下是关系的观点:

Product | City | # Sales
Apples, San Francisco, 400
Apples, Boston, 700
Apples, Seattle, 600
Oranges, San Francisco, 550
Oranges, Boston, 500
Oranges, Seattle, 600

虽然以下是更具维度的观点:

Product | San Francisco | Boston | Seattle
Apples, 400, 700, 600
Oranges, 550, 500, 600

但似乎两种观点仍然可以在相同的星型模式中实现:

Fact table: Product ID, Region ID, # Sales
Product dimension: Product ID, Product Name
City dimension: City ID, City Name

直到你开始向每个维度添加一些额外的细节,差异才会开始出现.例如,如果您也想跟踪区域,关系数据库往往会有一个单独的区域表,以便保持所有规范化:

City dimension: City ID, City Name, Region ID
Region dimension: Region ID, Region Name, Region Manager, # Regional Stores

虽然维度数据库允许非规范化以将区域数据保留在城市维度内,以便更容易切片数据:

City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores

它是否正确？

Answer 1

星型模式实际上位于数据的关系模型和数据的维度模型的交叉点.它实际上是一种从维度模型开始,并将其映射到SQL表的方式,这些表有点类似于从关系模型开始时获得的SQL表.

我说有点类似,因为许多关系设计方法导致标准化设计,或至少几乎标准化的设计.星型模式将与完全标准化有很大差异.

每次偏离完全标准化都会带来随之而来的数据更新异常.(我在一个伞下包含插入,更新和删除操作的异常).这些异常与您开始使用的数据模型无关.

OLTP与OLAP的评论在这里是相关的.在这两种情况下,更新异常将对性能和/或编程难度产生不同的影响.

除了SQL数据库中的星型模式之外,还有维度数据库产品,它们以物理形式存储数据,该数据对于该产品是唯一的.对于这些产品,您没有看到星型模式,因为您看到了维度模型的直接实现,以及可能是产品特有的界面.其中一些接口允许OLAP操作完全按点击.

就像你的问题中的一个题外话一样,我曾经构建了一个星型模式,作为支持基于事务的应用程序的OLTP数据库和Cognos PowerPlay中的数据立方体之间的中间步骤.使用标准ETL技术,从OLTP数据库到星型模式,然后从星型模式到数据立方体的组合传输实际上优于从OLTP数据库到数据立方体的直接传输.这是一个意想不到的结果.

希望这可以帮助.

Answer 2

简而言之,OLTP规范化数据库设计具有最佳的"事务性"观点.数据库被规范化以最佳地工作到事务系统.当我说事务系统的优化时,我的意思是......进入数据库结构的设计状态,其中所有事务操作如删除,插入,更新和选择都是平衡的,以便在任何时间点给予所有这些操作相同或最佳的重要性.因为它们在交易系统中同等重要.

并且标准化系统提供了什么...数据更新可能的最小更新,新条目可能的最小插入,类别删除的一个地方删除等(例如新产品类别)...这一切都是可能的我们分支创建主数据表.....但这是以"选择"操作延迟为代价的.但正如我所说的那样(规范化)并非所有操作的最有效模型.."最佳"...说我们得到其他方法提高数据获取速度..如索引等

另一方面,维度模型(主要用于数据仓库设计)...意味着只重视一种操作,即选择数据...如数据仓库..数据更新/插入定期发生.和它的一次性成本.

因此,如果试图调整规范化数据结构,以便只有选择是任何时间点最重要的操作......我们最终会得到一个非规范化(我会说部分非规范化)维度星形结构.

• 所有外键一个地方事实 - 维度连接的维度(即主表到主表连接)..雪花表示相同的维度
  • 理想设计的事实只带有数字.措施或外键
  • 维度用于携带描述和非聚合信息
  • 数据冗余被忽略......但在极少数情况下,如果Dimensions本身增长太多.snowflake设计被视为选项..但仍然是可以避免的

有关详细信息,请阅读有关此主题的详细书籍.

Answer 3

我刚刚读到了Dimensional和Relational Data Modeling之间的区别,因为我们主要在我们存储企业数据仓库(EDW)的业务中使用Relational模型.

根据史蒂夫·霍伯曼(Steve Hoberman)在他的着作"数据建模简单"(Data Modeling Made Simple)中的说法,两种模型之间的区别是:

• 关系数据模型捕获业务解决方案,了解业务的一部分工作方式,即业务流程
• 维度数据模型捕获业务所需的详细信息,以回答有关其运行情况的问题

可以说,关系模型也可以作为回答业务问题的基础,但在战术层面."由于信用保留,客户x有多少订单处于未履行状态？" 但区别在于报告问题需要表格的"原生粒度"以及何时可以使用汇总数据回答报告问题.

在上面的两个示例中,它们实际上都是维度数据建模的示例,因为这两个表都没有将销售订单存储在其"原始粒度"中,因此不会捕获创建销售订单的业务流程.两个表之间的唯一区别是,在第二个表中,城市维度已转换为事实表.

Answer 4

我发现在http://www.orafaq.com/node/2286上找到的描述在从关系角度来看星型模式时非常有用.

考虑完全标准化的数据模型.现在想想完全相反的情况,你完全非规范化你的关系数据模型,这样你就只有一个平坦的记录,比如一个非常宽的行的big'ol电子表格.现在从这个平坦的记录中稍微备份,以便你有一个只有两个级别的数据模型; 一张大桌子,以及大桌子指向的几张小桌子.这是一个STAR架构.因此,真正的星形数据模型有两个属性,它总是两层深度,而真正的星形模型总是只包含一个大型表格,它是模型的焦点.