问题标签 [snowflake-schema]

我正在寻找一个可以放在现有 OLAP 星型模式之上的控件，以允许用户定义自己的“查询”并生成报告。现在我有一些基于多维数据集的预定义报告，但我希望允许用户根据我创建的多维数据集定义他们自己的标准。我发现许多产品可以让您将事务表视为 OLAP 多维数据集，但没有专门针对预先存在的多维数据集的产品。

编辑：让我明确一点，我知道有无数的报告工具声称可以报告 OLAP 多维数据集。问题是他们都假设他们正在查看事务数据并尝试创建自己的多维数据集。我的表包含数以万计甚至数亿条记录。大多数工具在处理这么多数据时都会崩溃，其他工具的运行速度非常慢。我不想要针对商务人士的工具。

我想要一个了解星形和雪花模式的工具。我希望能够告诉它事实表是什么以及维度表是什么，然后在它们之上创建一个 UI。对于工具供应商来说，这是一个更容易解决的问题，因为我正在用勺子喂他们立方体。我想依靠立方体是一种标准化模式这一事实，并且我想要一个利用这一事实的工具。我想要一个针对开发人员的工具，并假设我实际上知道如何管理我的数据，它只需要为我构建漂亮的报告，而不是在我的数据的重压下崩溃。

我将为一些本地 ERP 启动一个关于销售、发票、订单、客户、库存等的报告工具。

我想知道是否存在适用于这种情况的示例模式（星形或雪花形式），这样我就可以有一个坚实的基础。

我对基本的 BI 设计有所了解，但考虑到这是一个常见问题，我想知道是否存在一个起始解决方案。显然，我需要改变一些东西以适应我的项目......

我知道星型模式和雪花模式之间的基本区别——雪花模式将维度表分解为多个表以便对其进行规范化，星型模式只有一个“级别”维度表。但是雪花模式的维基百科文章说

“有些用户可能希望向数据库提交查询，使用传统的多维报告工具，这些查询无法在简单的星型模式中表达。这在客户数据库的数据挖掘中尤其常见，其中一个共同要求是定位客户之间的共同因素“谁购买了满足复杂标准的产品。通常需要一些雪花来允许简单的查询工具形成这样的查询，特别是如果在最初设计数据仓库时没有预期提供这些形式的查询。”

什么时候不可能在星型模式中编写查询，而对于相同的基础数据可以在雪花模式中编写？似乎星型模式总是允许相同的查询。

这是简单仓库的示例： http ://en.wikipedia.org/wiki/File:Snowflake-schema-example.png

如果在 Fact_Sales 中仍然存在 Date2_ID，Date3_ID 这两个日期是否与相同的 Dim_Date 维度相关，或者我必须创建 Dim_Date2 和 Dim_Date3 维度（具有各自的雪花模式）？

Sales_fact:
Product_ID (FK)
价格

Dim_Product :
Product_ID
Product_Key
描述

我面临的问题是，如果我的产品可以属于多个类别，该怎么办。我应该在 Dim_Product 中为每个类别重复记录吗？

例子：

事实表：
Product_ID (FK)：1
价格：10.5

Dim_Product :
Product_ID:1
Product_Key: ABC
描述: 笔记本电脑
Category_ID: 1

Product_ID：1
Product_Key：ABC
描述：笔记本电脑
Category_ID：2

Dim_Category：
Category_ID (FK)：1
描述：HP

Category_ID (FK)：2
描述：东芝

一共有三张桌子——

1) 学生 - 我的事实表（带有 FK ADDRESS_ID 的引用地址

2) 地址 - 此表包含 FK COUNTRY_ID 引用 COUNTRY

3）国家 - 这有一个我会显示的名称列。（PK 标识符）

我已经写了这个，但不确定它是否正确

基本上我想加入学生（事实表）到事实的国家组合 --- Def .. 然后这个

我们的数据仓库使用来自数据源的累积数据（并且无法反转累积）来创建雪花模式。我们必须处理的一个要求是我们的架构必须能够用于创建基于日期范围的报告。

我们的模式看起来像这样（简化）：

我们想用这样的东西创建我们的报告数据集：

问题是我们的统计维度中的数据已经积累了，不能反积累。我们计算了事实表中的近似行数，得到了 5,250,137,022,180。我们的数据大约有 250 万个日期范围排列，由于累积，我们需要将它们计算到我们的日期维度和事实表中。SQL 的 SUM 函数由于累加对我们不起作用（不能将两个属于不相异集合的值相加）。

是否有我们可以遵循的最佳实践来使其在计算上可行？我们的架构设计有问题吗？

我们需要报告有关在线培训的数据。数据源是一个遗留数据提供者，其部件已超过 10 年——因此没有人可以重建内部逻辑。统计维度包含 - 例如 - 用户在基于 Web 的培训 (WBT) 中完成的进度（以 % 为单位）、每个 WBT 页面的调用次数、WBT 的状态（对于用户，例如“完成”） ，同样。数据提供者的重要之处在于：它只是为我们提供了当前状态的快照。我们无权访问历史数据。

我想使用 pygame实现 Koch Koch 雪花。

我正在使用来自http://en.wikipedia.org/wiki/File:KochFlake.svg的以下系列图片

我的算法是这样的

1. 画一个三角形
2. 计算三分之一大小的三角形的点并删除中心线
3. 找出外部点（如上图第二个图所示）
4. 列出所有端点
5. 使用多边形连接所有点

我已经完成了第二步。但是我在第三步上苦苦挣扎——因为我不知道如何找到外点——有什么提示吗？

这是我的代码到第二步

这是问题所在，我有一个包含销售信息的销售信息表，其中包含（主键 ID、产品名称、产品 ID、商店名称、商店 ID、销售日期）等列。我想做分析，比如向上钻取和向下钻取商店/产品/销售日期。

我正在考虑两种设计方案，

1. 在产品名称、产品 ID、商店名称、商店 ID、销售日期等列上创建单独的索引；
2. 使用数据仓库雪花模型，将当前销售信息表作为事实表，创建产品、店铺、销售日期维度表。

为了有更好的分析性能，听说雪花模型更好。但是为什么从数据库设计的角度来看它比相关列上的索引更好呢？

提前谢谢， 林

目前，我参与了一个基于仓库的智能交易分析银行系统，该系统具有客户流失行为、欺诈检测和 CRM 分析功能。我们一直使用Oracle它作为数据库，它完全是一个数据仓库项目，带有用于分析的数据挖掘算法。

我们有大约 1000 名银行客户的记录。对于建模，使用星型模式、雪花模式还是星座模式哪个更好？我知道星型和雪花模式的基本区别 - 维度表的规范化发生在雪花（又名雪花）模式中，这在大型数据库的情况下可能会出现问题。

那么，哪种模式更适合我的情况？非常欢迎参与数据仓库的经验丰富的程序员回答！

提前致谢！