如何设计关系数据库以捕获多个源报告的相同实体？

Question

我需要一个数据库，可以捕获由银行和两个会计师事务所报告的工具。让我们以沃尔玛股票为例。这家银行可能有一种名为“沃尔玛股票”的工具。其中一家会计师事务所可能将其命名为“沃尔玛股票”。另一家会计师事务所可能拥有“沃尔玛普通股”。

下面是我到目前为止所得到的图表：

*表中增加了五列。对于MasterInstrument和DataSourceInstrment，这五个列名是相同的。

DataSource代表银行、会计师事务所或任何其他能够提供数据的实体。

DataSourceInstrument表示由DataSource提供的仪器数据。

MasterInstrument是特定于应用程序本身的工具的一个版本。因此，在我们的例子中，它可能包含“沃尔玛普通股”的工具名称。它与DataSourceInstrument b/c不同，与DataSourceInstrument不同，它在整个应用程序中广泛使用，并且必须维护更改的历史。

Instrument表提供了一种方法，可以知道几个不同的数据源引用的是同一个工具。DataSourceInstrument和MasterInstrument具有相同的instrumentId指的是同一种仪器。(Instrument.id是一个代理密钥b/c，有些仪器没有自然密钥，DataSourceInstruments和MasterInstrument可能需要手动映射为引用同一仪器。)所以，以沃尔玛为例，我们可以知道，银行、两家会计师事务所和内部系统都是指同一家沃尔玛的工具。

Issuer代表该工具的发行者，如“沃尔玛商店公司”。注:只需为MasterInstruments拍摄即可。

我对这个设计有几分怀疑：

1. 只有一个代理项列的表(即Instrument)是否很糟糕？如果这是一个问题，它将如何设计不同？
2. 不同的*乐器表名称混乱吗？如果是这样的话，怎么会更清楚呢？

总之，设计应如何说明需要捕获多个来源，涉及同一工具，同时需要捕捉具有历史意义的该文书的内部版本？

更新

该系统的主要职能/存在理由是报告。它必须报告某一特定日期的内部文书(即MasterInstrument)在该日期的数据。这就是为什么我把MasterInstrument作为历史记录/temporal表而没有Instrument中的列的原因。

Answer 1

只有一根代用品柱的桌子(即仪器)设计不好吗？如果这是一个问题，它将如何设计不同？

如果这是实体的唯一常量属性，那么这是很好的，但我假设还有其他不变属性，如名称(在您的示例中是“Walmart”)。即使同一“工具”可以由每个源和发行者使用不同的名称(这些名称随后属于关系表)，它们不是有一个规范名称吗？

不同的*乐器表名称混乱吗？如果是这样的话，怎么会更清楚呢？

这在很大程度上取决于您如何记录它们和/或目标行业中的名称和命名约定。

表名应该尽可能具有描述性(在使用别名的查询中总是可以缩短它们)，尽可能避免泛型词。在需要泛型名称的地方，因为没有更多的形式是不太具体的，那么我建议使用最简单的通用词(项目、对象、事物)，而不是工具，但这是个人偏好。

对于连接表(关系表，或者您称之为它们的任何东西，因为对于相同的概念有几个通用名称)，我建议使用名称来表示关系中的行实体类型--所以在关系图中使用IssuerInstrument而不是MasterInstrument。