问题标签 [star-schema]

Star-Schema 设计对数据仓库来说是必不可少的吗？或者你能用另一种设计模式做数据仓库吗？

我正在研究用于分析已发布表单数据的星型模式。表单数据将发布到的站点实际上在托管表单的站点之外，因此只有表单中的数据可用。我将提供包含一些额外有用信息的选项，包括隐藏字段、原始推荐人、会话 ID 等。

我将能够使用正则表达式来匹配某些数据类型并将它们提取到特定维度，例如邮政编码。

我有一个解决维度的任意性质的解决方案，它不是一个很好的解决方案，但它会起作用。

我遇到的问题是我不知道我的事实表中会出现什么，它不像我可以聚合一个很好的数值。除了满足这些标准的“是的，有一个表单帖子”这一事实之外。

我想知道我是否以正确的方式处理这个问题？我是否使用了错误的工具来完成这项工作？还是我只是错过了什么？

西蒙。

更多细节：

有两个功能区域，根据标准过滤表单帖子，例如在两个时间戳之间。但就过滤而言，几乎所有东西都可以争夺。选定的表单帖子将用于生成 csv 文件以供导出。

另一个主要领域是分析，研究广告支出转化为客户线索是一个明显的起点。也有点开放式，取决于表单数据。

这是一个悬而未决的问题，但我真的很想听听人们的意见。

我很少使用显式声明的临时表（表变量或常规#tmp 表），因为我相信不这样做会导致更简洁、可读和可调试的 T-SQL。我还认为，在需要时（例如在查询中使用派生表时），SQL 可以比我更好地利用临时存储。

唯一的例外是当数据库不是典型的关系数据库而是星型或雪花模式时。我知道最好先将过滤器应用于事实表，然后使用生成的临时表从您的维度中获取值。

这是普遍观点还是有人持反对意见？

我们正在使用 SQL Server 数据库在 .net 3.5 中构建一个新应用程序。该数据库相当大，大约有 60 个表，其中包含数据负载。.net 应用程序具有将数据从数据输入和第三方系统导入此数据库的功能。

数据库中的所有数据都可用后，系统必须进行大量计算。计算逻辑相当复杂。计算所需的所有数据都在数据库中，输出也需要存储在数据库中。每周都会进行数据收集，并且需要每周进行计算以生成所需的报告。

由于上述情况，我正在考虑使用存储过程进行所有这些计算。问题是我们还需要数据独立性，而存储过程将无法为我们提供。但是，如果我一直在.net 中通过查询数据库来完成所有这些工作，我认为它无法快速完成工作。

例如，我需要查询一个表，该表将返回 2000 行，然后对于每一行我需要查询另一个表，该表将返回 300 个结果，而不是每行我需要查询多个表（大约 10 个）以获得所需数据，进行计算并将输出存储在另一个表中。

现在我的问题是我应该继续使用存储过程解决方案并忘记数据库独立性，因为性能很重要。我也认为如果我们使用存储过程解决方案，开发时间会少很多。如果任何客户想要在 oracle 数据库上使用此解决方案（因为他们不想维护另一个数据库），那么我们将存储过程移植到 oracle 数据库并维护两个版本以供将来任何更改/增强。同样，其他客户可能会要求其他数据库。

我上面提到的 2000 行是产品 skus。我提到的 300 行是我们要计算的不同属性，例如处理成本、运输成本等。我提到的 10 个表包含有关货币换算、单位换算、网络、区域、公司、售价、每人售出数量的信息天等。生成的表将所有信息存储为星型模式，用于分析和报告目的。目标是获取有关产品的任何详细信息，以便了解产品销售的哪些属性正在花费我们的钱以及我们可以在哪里进行改进。

我正在为当前使用 SQL Server、SSIS 和 SSAS 的数据仓库设计 Fact 和 Dimension 表。将维度和事实表之间的关系编程到 SQL 中是否会真正受益？还是在创建多维数据集时手动定义关系更好？

如果我对将数据插入表中没有任何限制并因此省略了关系，那么加载和转换数据似乎更容易。

我在为大量数据设计数据库的过程中，我想知道主键使用什么数据类型？

将进行表分区，数据库最终将被集群化，并将热故障转移到替代数据中心。

编辑

表格 - 考虑多个时间段和多个事物的聊天系统，与多个用户聊天的时间段和事物。

指数问题是我正在考虑的 - 即某些东西可能会在短时间内生成数十亿行。即在我们可以更改数据库或 DBA 做 DBA 事情之前

马克 - 我和你一样关心 GUID - 我不喜欢 GUID 飞来飞去的编码。

I am confused where should I start to design a star schema.

for example I have tables in database as follows:

I want to design a data-warehouse to analysis the loads such as :

1. The total amount of loans in 2008.
2. For the type of loans with more than 10 loan contracts, the type of loan and the number of contracts

when creating a star schema, what where should I start?

For what I understanding, all the star schemas must have a center, and the center fact table, contains "Measures" and "Relations to other fact tables".

So, is it that, when designing the star schema, we always start from the center, confirm what are the measure first? and then choose proper relation to another fact table?

But I still have another question, what should we choose to be Measures? When choosing measures, what question should I ask myself?

我有一个要在 SQLAlchemy 中表示的星型架构数据库。现在我有一个问题是如何以最好的方式做到这一点。现在我有很多带有自定义连接条件的属性，因为数据存储在不同的表中。如果可以为不同的事实表重新使用维度，那就太好了，但我还没有弄清楚如何才能很好地做到这一点。

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

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

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

在星型模式中将表名作为维度表或事实表的前缀是常见的做法吗？以表名作为前缀的列名也是常见的做法吗？

在我的普通 OLTP 数据库中，我不这样做，但我在星型模式中看到了这种类型的命名示例。

为数据仓库模式和 OLTP 模式设置不同的命名标准是否有意义？

谢谢德怀特