标签: star-schema

我需要在大数据仓库中支持动态字段和值来存储 API 请求日志，我的用户案例是我需要存储所有 API 请求查询字符串并能够在未来对它们执行查询（所以它不仅仅是存储，所以我不能为他们使用 blob）

例如 http://example.com/?action=test&foo=abc&bar=def...

我需要存储所有field => value映射，即(action => test), (foo => abc), (bar => def)，由于该字段是如此动态，我找到的唯一解决方案是使用 Entity-Attribute-Value，但是，人们一直说这是一个非常糟糕的设计。

那么，考虑一下我上面的用例，什么是 EAV 的合适替代品？

我当前使用 KAV 的模式

1. 表requests
(id, timestamp, uri)
   例如(1, 149382220, '/')

2. 表params
(request_id, key, value)
   例如(1, 'action', 'test'), (1, 'foo', 'abc'), (1, 'bar', 'def')

有什么建议？

更新：我们在 AWS RedShift 上运行仓库

我希望在 SQL Server 2008 数据库中填充日期维度表。表中的字段如下：

[DateId]                    INT IDENTITY(1,1) PRIMARY KEY
[DateTime]                  DATETIME
[Date]                      DATE
[DayOfWeek_Number]          TINYINT
[DayOfWeek_Name]            VARCHAR(9)
[DayOfWeek_ShortName]       VARCHAR(3)
[Week_Number]               TINYINT
[Fiscal_DayOfMonth]         TINYINT
[Fiscal_Month_Number]       TINYINT
[Fiscal_Month_Name]         VARCHAR(12)
[Fiscal_Month_ShortName]    VARCHAR(3)
[Fiscal_Quarter]            TINYINT     
[Fiscal_Year]               INT
[Calendar_DayOfMonth]       TINYINT
[Calendar_Month Number]     TINYINT     
[Calendar_Month_Name]       VARCHAR(9)
[Calendar_Month_ShortName]  VARCHAR(3)
[Calendar_Quarter]          TINYINT
[Calendar_Year]             INT
[IsLeapYear]                BIT
[IsWeekDay]                 BIT
[IsWeekend]                 BIT
[IsWorkday]                 BIT
[IsHoliday]                 BIT
[HolidayName]               VARCHAR(255)

我编写了一个函数 DateListInRange(D1,D2)，它返回两个参数日期 D1 和 D2 之间的所有日期。

IE。参数“2014-01-01”和“2014-01-03”将返回：

2014-01-01
2014-01-02
2014-01-03

我想为一个范围内的所有日期填充 DATE_DIM 表，即 2010-01-01 到 2020-01-01。大多数字段都可以用 SQL 2008 DATEPART、DATENAME 和 YEAR …

与在事实表本身中拥有时间属性相比，在星型模式中拥有时间维度有什么好处？

例如：

我有一个交易数据，其中包含每笔交易的用户信息、交易发生的国家和日期。

选项 1 如果我错了，请纠正我，但这可能是广泛使用的方法，也是许多人最推荐的方法：

• 包含transaction_ID(PK)、user_id(FK) 和country_id(FK) 以及 date_id (FK) 的交易事实表

• 包含user_id(PK) 和其他用户属性的用户维度，比方说name& phone_number。

• 由date_id(PK), date, day, month, year, , 组成的日期维度quarter。

选项 2 我只是想而不是选择选项 1，但不确定：

• 包含transaction_ID(PK), user_id (FK) 和country_id(FK), date, day, month, year, 的交易事实表quarter。

• 包含user_id(PK) 和其他用户属性的用户维度，比方说name& phone_number。

选择 1比选择 2有什么好处？我不知道为什么加入另一个 Date 维度会是更好的选择，即使它是最广泛使用的方法。非常感谢！

在Oracle文档包括以下建议：

应该在事实表的每个外键列上建立位图索引

在该参考文献中，日期列甚至还有一个位图索引。使用位图索引的基数规则发生了什么变化？日期列最不符合该规则，但其他列customer_key也有点太大而不能被视为位图索引的候选者。item_key如果您没有数千件物品，我可以理解穿上一件。

如果不是位图索引，那么是什么 - 特别是对于具有时间维度外键的日期列 - 典型的东西 - 月，年，日等？显然，它经常被查询。

几天前我在 Stack Overflow 上问过这个问题，但我打算删除它，因为它没有收到回复。

我正在构建一个供 SSAS 用于创建多维数据集的数据仓库，并且我正在两种可能的模式之间进行辩论。在我的仓库中，我有两个不同的事实表，用于跟踪美元价值的每日变化。这些事实表中的每个实体都有一个与其相关的基础销售订单和行。这些 SO 和产品线还有其他相关维度，例如客户、产品等。到目前为止总共大约有 12 个子维度。

我的问题是，我是否应该将所有这些子维度直接滚动到事实表中，或者是否应该在我的仓库中使用一点雪花，并让它们从销售订单和行维度中分支出来。

第一个选项显然更好地遵循星型模式模型。但是，如果进行更改（例如添加附加维度），则需要更多维护，基本上必须对每个事实表执行两次 ETL，而不仅仅是在 SO 维度上执行一次。同样，如果添加与销售订单相关的新事实，我就必须再次完成整个过程。

由于这是我的第一个 DW/OLAP 项目，我不熟悉雪花的界限应该在哪里划定，非常感谢其他人的想法。

我们使用 Postgres 进行分析（星型模式）。每隔几秒钟，我们就会收到大约 500 种指标类型的报告。最简单的模式是：

timestamp      metric_type     value
78930890       FOO              80.9
78930890       ZOO              20

我们的 DBA 提出了一个建议，将所有相同 5 秒的报告展平为：

timestamp   metric1     metric2     ...  metric500
78930890    90.9        20          ...  

一些开发人员反驳这种说法，称这增加了开发的巨大复杂性（批处理数据，以便一次性编写）和可维护性（仅查看表或添加字段更复杂）。

DBA 模型是此类系统中的标准做法还是仅在原始模型显然不够可扩展时的最后手段？

编辑：最终目标是为用户绘制折线图。因此，查询主要是选择几个指标，按小时/分钟折叠它们，然后选择每小时（或任何其他时间段）的最小值/最大值/平均值。

编辑：DBA 的主要论点是将行数减少 x500 次将允许更高效的索引和内存（在此优化之前，该表将包含数亿行）。然后在选择多个度量标准时，建议的架构将允许一个通过数据而不是每个度量的单独索引搜索。

编辑：500 个指标是一个“上限”，但实际上大部分时间每 5 秒只报告约 40 个指标（虽然不是相同的 40）

我听说过关于如何设计关于事实表中的内容和维度表中的内容的星型模式的教科书定义，例如：

事实表应包含有关对象的核心信息，维度应包含有关事实的信息

（转述）

但是，实际上在业务中，我看到过设计的星型模式，其中事实表包含代理键、业务键和对象的所有单值字段，每个维度存储对象的所有多值字段（因此是维度这个词）。例如，一个人可能是事实表中表示的对象。一个人有一个名字、一个年龄等，这些都在事实表中构成了可行的事实。一个人可能拥有多辆汽车，每辆汽车都有自己的属性，这些属性代表一个人的汽车维度，存储为一个维度表，其中包含多个列来描述每辆车的属性。在这个例子中，这个维度表还包括一个外键，表示来自事实表的相应行的业务键。

所以，如果我们同意这可能是一个合适的设计，我试图克服的问题是如何在多值维度表上执行 SCD 类型 2（历史）。对于我充满单一事实的事实表，这是显而易见的。我包括两个额外的列，有效日期和到期日期，并且我使用业务密钥链接公共记录，其中最近的记录具有NULL到期日期，并且同一业务密钥的所有其他历史记录都具有有效日期和到期日期表明他们是最新记录的时间点。

如何在表示多值列表的维度上使用相同的概念？我基本上想要相同的概念，我可以（1）识别当前列表（在这个例子中，一个人拥有的汽车）和（2）识别历史上任何给定时刻的列表。我可以在每个维度值上设置有效日期和到期日期吗？那么我如何区分一段时间后添加的值？还是删除的值？

但是，如果我们不同意这种设计方法，请告诉我什么行业标准，这样我才能正确地做到这一点。

我正在尝试设计一个星型模式事实表以及一些围绕它的维度表。如果我再利用被称为自然键customer_key同时在fact_table和dim_customer当时我没有看到调用朦胧的东西和查找表之间的差异。此外，如果我每次都需要更新，customer_name我将丢失在录制时代表此事实的历史数据。尝试对暗表和事实表进行建模时，我缺少什么？

我想了解关系“查找”表技术和数据仓库“维度”表之间的区别？

fact_table               dim_customer          dim_product
-------------            ------------          -----------
customer_key             customer_key          product_key
product_key              name                  name
units_sold               email                 description
unit_price

请原谅我在这个问题中可能表现出的任何无知。我是数据仓库新手。

我在我的报告数据库中使用 MS SQL Server 2016 聚集列存储索引（我们称之为 CCI）。

在最初的设计中，我考虑的是星型模式，但后来我开始使用 CCI。现在我放弃了许多维度表，转而将字符串直接展平到“事实”表中。我保留维度表的唯一地方是当该维度具有频繁更改的属性并且要求使更改的属性适用于所有历史记录时。我做了这么多让一位拥有更多 DW 经验但没有空闲时间探索 CCI 的同事感到沮丧。

似乎作为单独列存储在磁盘上的平面表（以及提供的大规模压缩）根本不需要很窄。使用 CCI 时，何时还需要维度表？

从生产数据库构建DW星型模式设计的步骤/规则是什么？具体来说，您如何处理多对多关系。

我了解如何获取包括多对多关系在内的基本数据，并获得规范化的生产数据库：

例如：

如果我想处理销售交易，给表Product Entity，Promotion和Employee中，第一步是建立一个表，SaleTransaction：

SaleTransaction
- TransactionID
- ProductID
- EmployeeID
- SellingDateID
- Quantity
- SaleAmount
- PromotionID

该Promotion实体将是：

Promotion
- PromotionID
- ProductID
- DiscountAmount

但是，这将只允许每次销售交易 1 个产品和 1 个促销活动。由于我们希望允许一种或多种产品以及零个或多个促销：

• 我删除PromotionID，ProductID，Quantity，和（除非因某些业务规则）SaleAmount从SaleTransaction

• 我创建SaleTransactionDetail：

  - DetailID
  - TransactionID
  - ProductID
  - Quantity
  - SaleAmount
  

  Run Code Online (Sandbox Code Playgroud)

• 我会创造SaleTransactionPromotion：

  - TransPromoID
  - PromotionID
  

  Run Code Online (Sandbox Code Playgroud)

将生产 DB 设计转换为 DW 星型模式设计的等效步骤是什么？