问题标签 [star-schema-datawarehouse]

我有一个案例，我正在为我的 DWH 构建无事实的事实表。对于这种情况，我想问两个维度：位置和商店。我有两种方法。

1. 构建 dim_store 和 fact_account。然后将所有位置数据放入fact_account表中

2. 构建 dim_store、dim_location 和 fact_account。然后把store_id和location_id放到fact_account上

这是这两种方法的可视化：

1.

2.

哪种方法最好，为什么？

先感谢您。

我在为事实表选择合适的表时遇到问题。我对以下两个表有疑问

订单数据表：

1. 订单编号
2. 客户ID
3. 订单状态
4. 订单购买
5. 订单批准时间
6. OrderDeliveredCarrier
7. 订单交付客户
8. 订单估计已交付

订单项表：

1. 订单编号
2. 订单项 ID
3. 产品编号
4. 卖家ID
5. 发货期限
6. 价格
7. 重量级

事实表适合什么表？我的数据源是https://www.kaggle.com/olistbr/brazilian-ecommerce

请给我一个支持。

背景：我正在尝试为数据仓库设计星型模式。我们有以下商业模式，我们的客户可以购买并使用的产品很少。客户是公司，然后他们的组织中有人员可以映射到他们为产品带来的许可证。

我有以下尺寸。

Account_dim：该维度包含我们当前/未来与我们公司合作的所有公司列表。它可能有那些仍然没有与我们签订合同并且仍处于讨论阶段的公司。所以有些行可能没有合同。

User_dim：这是公司为其公司指定联系人的用户列表。因此，用户将属于 Account_dim 中的一个特定帐户。一个帐户可以有多个用户。

Product_Dim：此维度包含有关我们销售的所有产品的所有信息。许可证的成本以及许可证允许多少用户。因此，例如，如果他带来产品 A，最多两个用户可以使用它。

现在我有三个表，其中包含有关合同的数据。

合同：它包含有关我们拥有的合同的信息，其中包括合同开始日期和结束日期以及该合同分配到的帐户。

products_bought：此表包含根据合同带来的产品。一份合约可以持有多个购买的产品。每个产品行都有产品开始日期/结束日期和客户支付的资产价格。

分配的用户：每个购买的产品都可以有用户映射到它，这些用户被允许使用该帐户的 user_dim 中的用户。基本上将许可证附加给用户。

我正在尝试对合同、购买的产品和分配的用户进行建模，以便生成以下数据。

1. 帐户在产品上花费的金额。
2. 帐户对许可证的使用。例如，一个帐户有一个允许 3 个用户的产品，但只有一个用户映射到它，这将显示该产品未得到充分利用。

我尝试将所有三个表非规范化为一个事实表，但我遇到了问题，即如果合同结束日期延长，则可以更改。以及新资产可以映射到它。最后同样重要的是，公司可以删除一个用户，然后将另一个用户映射到产品或删除用户，因为他们离开了公司或添加了更多用户。

如何最好地建模。因为他们的合同和资产用户可以更改，所以它们应该是 SCD 而不是事实表，或者我应该如何实现一个事实来处理这些更改以及必须捕获这些更改以保持随时间推移的使用历史。

I am trying to answer the below question given by the business (The business generates revenue from multiple apps through customer pay model) The business is interested in the below questions

1. new users (trend with respect to previous months)
2. daily active users
3. Day 1 retention I came up with the below DM

Dimension: users, app, deviceid, useractions, plan, date

Fact: fact_activity(userid, appid,deviceid, actionid)

Actions could be: app installed, app launch, registered, completed purchase, postedcomments, playgame etc

The questions I have is

1. should the fact table contain action_type instead of the actionid into the fact (to avoid join with useractions)
2. Definition of day 1 retention: No of apps installed/ app launches next day how do to avoid multiple counting of single user using multiple devices
3. Would it be advisable to have device details in the user dimension or separate.
4. If I need to measure average session duration, should I use another fact at session level or tweak the activity fact?

在这里，我有一个 FACT 表FACT_Orders，其中包含字段customer_id、order_id、total_cost、created_date、updated_date。

此外，我还有一个 FACT 表FACT_Order_List以保持项目的顺序，其中包含字段 order_list_id、order_id、item_id

我还有维度表DIM_Item和DIM_Customer来保留 Item 和 Customer 的属性

从 FACT 表中，我需要计算最畅销的商品和最不受欢迎的商品

这个好的设计是否有两个 FACT 表并连接 FACT 表进行计算？

我们知道 Snowflake 是一个压缩的列式存储数据库，并且经过调整可以使用 MPP 和自动缩放运行查询。我们还知道，为了创建数据集市和 DW，Kimball 和维度建模（星型模式）已经在市场和实践中使用了几十年。这是成功的，因为我们曾经为我们的 DW 拥有大量的 Row 存储 DB。

所以这里的问题是在 Snowflake 中创建数据集市和 DW，我们必须遵循 Kimball 吗？它是否为性能增加了任何价值，事实上我读到它增加了已经调整为处理列压缩数据的引擎的开销？我们是否仍然需要对列使用代理键并强制创建 Facts 和 Dimensions 以及星型模式，我们可以在其中简单地加入平面非规范化表以获得相似或更好的性能？

从建模的最佳实践的角度来看，像 Snowflake 这样的超级数据库推荐什么？Kimball 是必须拥有还是多余，因为它违背了柱状存储优势的目的？

我认为 SAP HANA / Redshift / Big Query 甚至 Azure SQL Datawarehouse，没有人推荐这个，我在任何地方都找不到推荐使用 Kimball 或星型模式的单行。很少有人提到“它也适用于星型模式”，这并不意味着必须使用星型模式？

目前面临一个问题，我正在尝试为 Web 应用程序创建登录利用率报告。为了稍微描述一下报告，我们系统中的用户被标记了关于用户的不同元数据。例如，我可能被标记为“纽约市”和“软件工程师”，而其他用户可能被标记为不同的位置和职位。利用率报告基本上如下：

1. 时间段（季度）
2. 登录总数
3. 唯一登录
4. 总用户
5. “参与百分比”（唯一登录/总用户）

问题是，报告需要有点动态。我需要能够应用职位和位置的任意组合，并让每个数字都反映应用的元数据。时间段还需要能够轻松调整以支持每周、每月和每年。理想情况下，我可以在 Redshift 中创建一个视图，允许我们的 BI 软件用户在他们认为合适的时候运行此报告。

我的问题是，设计数据模型来支持这份报告的理想策略是什么？我目前有一个原子事实表，其中包含使用此模式的所有登录：

• 用户身份
• 登录ID
• 登录时间戳
• 职称组 ID（职称的 MD5 散列以支持多值）
• 位置组 ID（位置的 MD5 哈希以支持多值）

事实表允许我轻松编写查询以汇总总计（登录 ID 计数）和唯一（用户 ID 的不同计数）。

如何补充我必须包含总用户数的数据？我目前有最好的方法吗？

我试图理解完整表、增量表和增量表的概念，原则上为了简化（更快的加载过程）每日 ETL 负载是使用增量表的好习惯

满桌

增量表

增量表

我读过一些地方

使用增量负载移动数据可以缩短 ETL 流程的运行时间并降低出现问题时的风险

有人可以帮我理解这个概念吗？

我想知道是否有人可以阐明以下内容。

我目前正致力于在金融领域建立一个金博尔数据仓库，特别是在养老金行业。

目前，我们正在努力将估值业务流程整合到一个计划中。

要求是将所有估值（无论产品如何）存储在单个 FACT 表中以进行报告。养老金可以持有许多不同类型的产品（投资组合、证券、财产等），因此我们决定走创建超类型和子类型维度的路线。产品将有一个包含公共字段的超类型，然后每个产品都有一个包含更多详细信息的子类型维度。

我们目前遇到的问题是，可以在投资组合中持有证券，但另一方面，投资组合可能不持有任何投资但仍包含价值（可能取决于我们如何存储基础数据）。

我们不想在投资组合的事实表中创建一条估值线，如果它有基础投资，我们只是希望显示基础投资，但以某种方式将其与投资组合联系起来。如果投资组合没有我们知道的基础投资，我们希望在 FACT 表中存储一行，其中仅包含投资组合的价值，这将直接作为产品表的关键。

有人对此有什么建议吗？

这是数据如何保存在源系统中的结构。带有样本数据的表格

这是我提出的设计，所有投资维度都可以互换，产品维度是核心，但是由于基础投资控股和投资组合之间没有联系，所以这个设计失败了。估值模型

使用 Fact UpdatedFact中的 Portfolio Key 更新模型

我很难将维度表（递归/分层）连接到事实表，因为有需要处理的问题/问题：

• 维度表属于父子关系结构
• 从原始表开始，它一直在增长

对这种表进行非规范化是不适合的，因为新的实体类型进来了，它会影响维度结构。

这种类型的最佳方法是什么？请提供一个示例以及连接事实和维度后的查询语句是什么。