我一直在阅读有关锚定建模的内容，并且非常喜欢这个概念。我的希望是将其合并到一个数据管理框架中，在该框架中我将多个数据源整合到一个锚定模型中，然后使其直接可用或将其提供给我们的数据科学家的数据集市。
但我不确定如何进行实体解析。该指南规定不更新，仅插入，并且可以选择仅删除以删除错误数据。现在假设我的源系统有重复的实体（例如约翰·史密斯出现多次），这会进入我的锚模型吗？清理这个的最好方法是什么？
我的橡皮鸭告诉我在我的锚模型之上创建一个实体解析层，以查找这些问题并纠正它们。纠正意味着合并锚点中的实体并相应地修复后续关系。但现在我正在更新我的锚模型......这违背了最佳实践。
或者我是否认为这个错误......并且应该在数据进入锚模型之前处理实体解析？但错误可能会发生，如果知道我可以解决锚模型内部的问题（如果它出现的话），那就太好了。
锚模型可以帮助您进行重复数据删除和实体解析，但您可能至少需要某种形式的输入准备才能将其正确输入数据库。这很大程度上取决于您拥有哪种类型的重复项以及您使用的时态化模型。
为了简单起见，我假设您使用单时锚模型。
为了更好地理解锚模型的语义，我建议您阅读 Rönnbäck 的论文 “建模冲突、不可靠和变化的信息”（DOI：10.13140/rg.2.2.34381.49121/1），该论文涉及过渡建模理论，该理论形成了锚建模的基础及其三个时间化/历史化模型：单时态（版本化）、双时态（版本化和更正）和并发依赖时态（具有语句依赖的多时态）。 Rönnbäck 的演讲“Posits and Assertions”也很擅长解释这些细节。
论文第 14 页介绍了具体的理论，演示文稿第 26 至 27 页的定义很好地解释了它：
撤回对于使用依赖的并发依赖时间模型很重要。对于所有其他情况，您只需插入一个新值。尽管有一些模型功能您可以使用。
对于具有等效含义的数据，您可以使用“生成”菜单中的等效设置，根据建模者的说法，这“对于多租户和多语言化很有用”。这可能最接近您的问题。
根据其实施方式，这可能是比批处理密钥更好的解决方案。
对于属性，您可以通过在锚建模器中设置“可重述”来启用重述来禁用重述。解释：重述是指随着时间的推移，两个值相同，只有断言时间不同。
如果您可以确保数据同步到达，您还可以使用幂等性属性设置来仅记录值发生更改时的情况。对于随着时间变化而异步到达的数据，不建议使用幂等性。
更新锚模型时，请始终使用建模器，否则您可能最终会以某种方式更改架构，从而无法再正确更新。锚定模型使用大量触发逻辑进行健全性和一致性检查，如果你搞砸了某些东西，这将是第一个被破坏的，而且我不会通过任何更改模式的手动操作来触及锚定模型。
如果您不知道，您可以就地更新锚点模型并将生成的 SQL 应用到现有的锚点模型数据库，因为生成的 SQL 代码是幂等的，并且只会更新更改的元素。每个先前的模式都保留为最新模式的子集，这避免了昂贵的模式维护，也是锚定建模最初被开发的主要原因之一。