问题标签 [surrogate-key]

您能否帮助了解如何使用维度中的代理键填充事实表。

我有以下事实表和维度：

索赔事实

ContractDim_SK ClaimDim_SK AccountingDim_SK ClaimNbr ClaimAmount

合同暗淡

ContractDim_SK (PK) ContractNbr(BK) ReportingPeriod(BK) 代码名称

会计昏暗

TransactionNbr(BK) ReportingPeriod(PK) TransactionCode CurrencyCode （我应该在这里添加 ContractNbr 吗？OLTP 中的原始表有）

ClaimDim

CalimsDim_Sk(PK) CalimNbr (BK) ReportingPeriod(BK) ClaimDesc ClaimName （我应该在这里添加 ContractNbr 吗？OLTP 中的原始表有）

我将数据加载到事实表中的逻辑如下：

1. 首先，我将数据加载到维度中（代理键被创建为标识列）

2. 从事务模型 (OLTP) 中，事实表将填充度量值 (ClaimNbr 和 ClaimAmount)

3. 我不知道如何用维度的 SK 填充事实表，如何知道将我从维度中提取的密钥放在事实表中的哪一行（哪个密钥属于该声明NBR？）我应该全部添加合同 Nbr在加载事实的关键时将它们连接在一起？

这样做的正确方法是什么？请帮忙，谢谢

嗨，我是数据库的初学者，因此我想问你应该使用哪些属性作为主键以避免错误：

可选地，我正在考虑将 idcustomer 添加为 auto_increment，但我不确定这是否是一个好主意。

有一个包含数百万条记录的表也有重复记录。创建一个新实体作为代理键的过程是什么（表示序列号）

例如表结构

col1 col2

101 A 101 A 101 B 102 A 102 B

我想创建一个新列 (col3) - 它表示一个序列号。

col1 col2 col3

101 A 1 101 A 2 101 B 3 102 A 1 102 B 2

请建议我为现有记录（3亿）创建代理键的步骤，即使在加载新记录时（我假设插入时需要触发器）。

我知道 hive 不能创建代理键或者相当困难。我想了解公司如何在其仓库中实施维度建模。

我能想到的一种方法是将尺寸细节保持原样。然后将不同的维度移动到不同的表中。但是然后如何处理scd1和scd2。我已经检查了 Kimball 在 cloudera 上的谈话，但我仍然不明白这是如何工作的。

我们有 180 万条记录的昏暗构建，并且当找不到业务密钥时，scd 正在更新旧记录而不是插入记录。

需要立即帮助，因为这是一个生产问题....

我们在目标表上有标识，我们没有使用代理键进行插入，而是使用我们正在使用的更新，这造成了很多麻烦......

我有一个正在进行的项目，我们必须在 Access 中为一所大学创建一个注册系统。其中一张表需要其中一个字段的代理键，我不确定如何创建代理键。

列说明如下所示：

Field Name Data Type Field Size Caption Format Req'd Index Unique Key Ref. Table Other

FacultyID Text 4 blank blank Yes Yes Primary blank Input Mask '0000;1;_'

FirstName Text 32 blank blank Yes No Surrogate* blank blank

因此，第一个字段FacultyID简单易行。但是该FirstName字段需要一个我不知道如何制作的代理键。

它旁边还有一个星号，在页面底部的星号显示：

*Index [LastName], [FirstName]: Duplicates Allowed (surrogate key)

该LastName字段稍后列出，但我没有在我的问题中显示它。然而，让我感到困惑的是，在列说明中，它说该Index字段应该是Nofor FirstName，但是页面底部的这个注释使它看起来应该是Yes (Duplicates OK)，我不知道该放什么。

那么任何人都可以帮我弄清楚如何制作FirstName代理键，以及我应该在该Index字段中放入什么？

我们正在从 AWS Redshift 迁移到 GCP BigQuery。

问题陈述：我们有一个 Redshift 表，它使用 IDENTITY 列功能为自然/业务键发出内部 EDW 代理键 (PK)。这些自然密钥来自至少 20 个不同的客户源系统。我们需要一种方法来识别它们，以防自然键以某种方式重复（因为我们有很多源系统）。在 BigQuery 中，不存在 Redshift IDENTITY 列的功能。我如何在 BQ 中复制它？我们不能使用 GENERATE_UUID() 因为我们所有的下游客户在过去 4 年中一直在使用 BIGINT。所有历史都基于 BIGINT，对于 VARCHAR 需要更改太多。有没有人有任何想法、建议或建议？

我做了一些考虑： 1. 将数据加载到 Spark 中并将其保存在内存中，并使用 scala 或 python 函数来发出代理键。2. 使用 nosql 数据存储（但这似乎不太可能作为用例）。欢迎任何想法！

我有一个用例，其中 apache flink 进程必须集成来自多个源的近乎实时的数据流（事件），但由于不同系统中缺乏统一的键，我需要从现有数据中使用代理键（SK）查找根据。SK 数据集非常大（超过 5000 万键）。是否可以/建议在没有数据库查找的情况下缓存这样的数据集以进行流内转换（映射）？如果是，什么是缓存限制？如果没有，Flink 有哪些替代方案？

免责声明：这与其他主题不同。

我们在使用自然键时面临的一个缺点是，如果业务逻辑发生变化并且我们需要更改一个键，我们需要将这种更改传播到所有链接表中。

但是，使用ON UPDATE CASCADE声明，我们可以让 DBMS 在我们更改键值时为我们传播更改。

我不明白的是：这种方法有什么缺点？是否存在使用ON UPDATE CASCADE对数据库有风险的情况？

因为如果不是，那么如果在某种情况下，使用代理键的唯一原因是更容易更改业务自然键，那么ON UPDATE CASCADE应该使用而不是将所有表转换为代理键。

我正在重建一个最初使用自然键的大型仓库数据库，现在我想切换到代理键。

因此，我正在考虑将数据库拆分为物理层和逻辑层。

在物理层，每个表基本上都有两个这样的字段：（简化情况）

tbl产品：

tbl销售：

• “Key”字段始终是主键，也用于所有外键关系。
• “ID”字段是唯一的 nvarchar。用户将始终使用“ID”而永远不会看到“密钥”。

在逻辑层，想法是为每个表创建视图，这些视图将“隐藏”代理键并允许我使用 ID。即使是数据库管理员最终也应该只使用视图！例如：

查看大众销售：

现在，如果我想使用这个视图，我需要创建处理所有更新/删除/插入的触发器并将其“翻译”到物理层。创建所有这些视图需要大量工作。所以：

• 有没有办法“自动”创建这样的视图？
• 将数据库拆分为物理层和逻辑层是一种好方法吗？