问题标签 [snowflake-schema]

我有一个关于星型模式设计的问题，我是否需要使用雪花（我应该避免阅读）。我有以下三个维度表：

• 主列表暗淡。- 包含人员列表
• 子列表暗淡。- 包含主列表中的各种组合
• 程序昏暗。- 识别程序列表，每个程序都可以连接到一个子列表

事实表中的每一行都将包含来自以下三个表（和指标）的键，但问题是 - 一些子列表可能是确切的列表（就列表内容而言）但指向不同的程序。那么我应该在子列表维度中创建相同内容的重复，还是应该使用雪花来连接子列表和程序？示例 - 假设我的主列表包含 100K 记录，并且我有 3 个程序 A、B 和 C。程序 A 有 10K 子列表，所以我将在子列表维度中有 10K 条目，但是程序 B 和 C 具有相同的子列表30K 记录，所以我应该创建 60K 条目，每个 30K？需要注意的是，程序 DIM 中还有其他属性可以区分每个程序，并且事实数据位于程序级别。

谢谢！

我犹豫是否应该添加一个Country_Dimension，因为我已经有一个Customer_Dimension包含一些冗余字段的字段，例如：

• 大陆名称
• 国家的名字
• 邮政编码_＃

https://web.stanford.edu/dept/itss/docs/oracle/10g/olap.101/b10333/globdiag.gif

假设我们有一个如上所述的启动模式。

我的问题是 - 我们如何实时填充事实表的列 (unit_price, unit_cost) 列..？

谁能给我一个带有真实数据的起始模式表？

我很难理解星型模式......

请帮忙！..

第一个使用星型模式的项目，仍处于规划阶段。我们将不胜感激对以下问题的任何想法和建议。

我们有一个“使用的产品特性”的维度表，并且特性集会随着时间的推移而增长和变化。由于特征的动态集，我们认为特征不能是列，而必须是行。

我们有一个“用户事件”的事实表，我们需要知道每个事件中使用了哪些产品功能。

所以看起来我们需要在事实表上有一个主键，它被用作维度表中的外键（与传统的星型模式正好相反）。我们有几个不同的维度表，它们具有相似的动态，因此对事实表的外键也有类似的需求。

另一方面，我们的大多数维度表都比较常规，事实表可以只在这些常规维度表中存储一个外键。我们不喜欢这意味着某些连接（多对一）将使用维度表的主键，但其他连接（一对多）将使用事实表的主键。我们已经考虑在所有维度表中使用事实表键作为外键，只是为了保持一致性，尽管存储需求会增加。

有没有更好的方法来实现“动态”维度表的键？

这是一个不完全是我们正在做但类似的示例：

• 假设我们的应用搜索餐馆。

• 用户可以指定的可选功能包括价格范围、最低星级或美食。可选功能集随时间而变化（例如，我们可能会去掉指定美食的选项，并添加一个最受欢迎的选项）。对于记录在数据库中的每个搜索，使用的特征集是固定的。

• 每个搜索将是事实表中的一行。

• 我们目前在想，事实表中应该有一个主键，在“特征”维表中应该作为外键。所以我们有：

  fact_table（search_id，user_id，metric1，metric2）
  feature_dimension_table（feature_id，search_id，feature_attribute1，feature_attribute2）
  user_dimension_table（user_id，user_attribute1，user_attribute2）

• 或者，为了一致的连接和为了论证而忽略存储要求，我们可以在所有维度表中使用事实表的主键作为外键：

  fact_table( search_id , metric1, metric2) /* 不再有 user_id */
  feature_dimension_table(feature_id, search_id, feature_attribute1, feature_attribute2)
  user_dimension_table(user_id, search_id , user_attribute1, user_attribute2)

• 这些关键模式的缺陷是什么？有什么更好的方法来做到这一点？

为了填充 SCD2 维度表，标记最新活动行的标记总是有益的。

我可以想到两种方法 1) valid_from/valid_to 2) active_status: active/deleted

很明显，valid_from/valid_to 保留了更多信息，但这会使 ETL 过程变得复杂吗？

这两种方法的 prons 和 crons 是什么？

在我的星型模式中，我有一个项目维度，其中包含start_date、finish_date、service_date、onhold_date、resume_date等列。

我应该为事实表中的所有日期引入外键并将它们连接到日期维度，还是应该使用date_dimension对project_dimension进行雪花化？并非所有日期都可用于给定项目，因此将所有这些列保留在 fact_table 中可能会导致 fact_table 中的键为空。

在这种情况下处理日期的最佳方法是什么？

我有一个事实表，其中有一个RESOURCE_ID链接到资源表。资源有一个角色，它本身就是一个资源。

现在我想创建一个ROLE包含属性的维度TITLE。

这个怎么做？Mondrian 4 Schema 的示例将不胜感激。

我知道有<Link>for the<PhysicalSchema>和 the <ForeignKeyLink>for the，<DimensionLinks>但我不知道如何正确使用它们。

Snowflake S3 数据在 .txt.bz2 中，我需要将此 SnowFlake S3 中存在的数据文件导出到我的 AWS S3，导出的结果必须与源位置中的格式相同。这是我试过的。

COPY INTO @mystage/folder from (select $1||'|'||$2||'|'|| $3||'|'|| $4||'|'|| $5||'|'||$6||'|'|| $7||'|'|| $8||'|'|| $9||'|'|| $10||'|'|| $11||'|'|| $12||'|'|| $13||'|'|| $14||'|'||$15||'|'|| $16||'|'|| $17||'|'||$18||'|'||$19||'|'|| $20||'|'|| $21||'|'|| $22||'|'|| $23||'|'|| $24||'|'|| $25||'|'||26||'|'|| $27||'|'|| $28||'|'|| $29||'|'|| $30||'|'|| $31||'|'|| $32||'|'|| $33||'|'|| $34||'|'|| $35||'|'|| $36||'|'|| $37||'|'|| $38||'|'|| $39||'|'|| $40||'|'|| $41||'|'|| $42||'|'|| $43 from @databasename) CREDENTIALS = (AWS_KEY_ID = '*****' AWS_SECRET_KEY = '*****' ) file_format=(TYPE='CSV' COMPRESSION='BZ2'); PATTERN='*/*.txt.bz2

我必须为旅行社创建数据仓库。我是第一次这样做。我已经学习了有关星形、雪花和星座模式以及创建数据仓库的所有基础知识。我想问问有什么可以改进的，这个设计总体上是否不错。

这是我的维度层次结构：

这是我现在所取得的成果（在 MySQL Workbench 中创建模式）：

首先，我试图通过说明它们来区分 Star Schema 和 Snowflake Schema。但是在尝试规范化表以创建雪花模式时遇到了麻烦。所附图像是星型模式 在此处输入图像描述

我尝试为 dimcustomer 创建另一个暗表，但不确定我可以为该表命名。请，任何帮助将不胜感激。

雪花模式 在此处输入图像描述