我正在尝试学习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
这是对的吗？
答案 0 :(得分：19)
星型模式实际上位于数据关系模型和数据维模型的交叉点。它实际上是一种从维度模型开始，并将其映射到SQL表的方式，这些表有点类似于从关系模型开始时获得的SQL表。
我说有点类似，因为许多关系设计方法导致标准化设计，或至少几乎标准化的设计。星型模式将与完全标准化有很大差异。
每次偏离完全正常化都会导致数据更新异常。 （我在一个伞下包含插入，更新和删除操作的异常）。这些异常与您开始使用的数据模型无关。
OLTP与OLAP的评论在这里是相关的。在这两种情况下，更新异常将对性能和/或编程难度产生不同的影响。
除了SQL数据库中的星型模式之外，还有维度数据库产品，它们以物理形式存储数据，该数据对于该产品是唯一的。对于这些产品，您没有看到星型模式，因为您看到了维度模型的直接实现，以及可能是产品特有的界面。其中一些接口允许OLAP操作完全是点击式的。
就像你的问题中的一个题外话一样，我曾经构建了一个星型模式，作为支持基于事务的应用程序的OLTP数据库和Cognos PowerPlay中的数据立方体之间的中间步骤。使用标准ETL技术，从OLTP数据库到星型模式，然后从星型模式到数据立方体的组合传输实际上优于从OLTP数据库到数据立方体的直接传输。这是一个意想不到的结果。
希望这会有所帮助。
答案 1 :(得分：16)
简单来说，OLTP规范化数据库的设计具有最佳的“事务性”观点。数据库被规范化以最佳地工作到事务系统。当我说事务系统的优化时，我的意思是......进入数据库结构的设计状态，其中所有事务操作如删除，插入，更新和选择都是平衡的，以便在任何时间点给予所有这些操作相同或最佳的重要性。因为它们在交易系统中同等重要。
这是规范化系统提供的最小数据更新，最小插入可能用于新条目，一个地方删除类别删除等（例如新产品类别）...这一切都是可能的我们分支创建主表.....但这是以“选择”操作延迟为代价的。但正如我所说的那样（规范化）并不是所有操作的最有效模型..“最佳”......说完了获得其他方法来增强数据获取速度..如索引等
另一方面，维度模型（主要用于数据仓库设计）...仅用于重视数据选择的一种操作...如数据仓库..数据更新/插入定期发生......以及一次性费用。
因此，如果一个人尝试调整规范化数据结构，以便只选择是任何时间点最重要的操作......我们最终会得到一个非规范化（我会说部分非规范化）。维度星形结构。< / p>
有关详细信息，请阅读有关此主题的详细书籍。
答案 2 :(得分：7)
我刚刚读到了Dimensional和Relational Data Modeling之间的区别，因为我们主要在我们存储企业数据仓库（EDW）的业务中使用Relational模型。
根据史蒂夫·霍伯曼（Steve Hoberman）在他的着作“数据建模变得简单”中的说法，两种模型之间的区别是：
可以说，关系模型也可以作为回答商业问题的基础，但在战术层面。 “由于信用保留，客户x有多少订单处于未履行状态？”但区别在于报告问题需要表格中的“原生粒度”以及何时可以使用汇总数据回答报告问题。
在上面的两个示例中，它们实际上都是维度数据建模的示例，因为这两个表都没有将销售订单存储在其“原始粒度”中，因此不会捕获创建销售订单的业务流程。两个表之间的唯一区别是，在第二个表中，城市维度已转换为事实表。
答案 3 :(得分：5)
我发现我在http://www.orafaq.com/node/2286上找到的描述在从关系角度来看星型模式时非常有用。
考虑完全规范化的数据模型。现在想想完全相反的情况，在那里你完全非规范化你的关系数据模型，这样你就只有一个平坦的记录，比如一个非常宽的行的大型电子表格。现在稍微从这个平坦的记录中备份，以便你有一个只有两个级别的数据模型;一张大桌子，以及大桌子指向的几张小桌子。这是一个STAR架构。因此，真正的星形数据模型有两个属性，它总是两层深度，而真正的星形模型总是只包含一个大型表格，它是模型的焦点。