sql-server - 如何识别事务表？

Question

我的数据库有 ma​​ster 表，前缀为 mt_ 和 transactions 表，前缀为 tr_ 。但是当我浏览数据库时，我开始怀疑事务表和主表的实际定义是什么。据我了解，事务表应该有一个复合主键(主键由其他表的两个或多个 PK 组成)。但是当我查看数据库中的事务表时，有些表具有前面提到的复合键，它也有标记为 tr_ 的表，但只有一个标记为 PK 的键，它们也有属于其他表的 PK 键，但它们甚至没有被标记为 FK...

那么这里有谁能解释一下主表和事务表之间的区别以及如何在数据库中识别它们吗？

已更新这是我的数据库的一个例子

tr_orders

OrderId int PK
CustomerId int Fk
OrderDate datetime  etc

tr_reciept

RecieptId int PK
OrderId int **(but not FK)**
PaindAmount money
recieptDate datetime

完整的两张表的表结构如下:

tr_orders

tr_reciept

我不明白为什么这些表是 tr 表？

Answer 1

为什么你不总是把主键放在所有外键上

当某事“发生”时，它会进入交易。有人在商店买玩具。创建一行记录它是一个玩具，它发生的日期时间以及它的价格。

十分钟后别人买了玩具

我们的交易表中有两条记录:

Date          Time     Product_Key     Shop_Key    Amount
--------------------------------------------------------------------------
18 Dec 2015   13:05    7                12           10
18 Dec 2015   13:15    7                12           10

这里我们有两个外键:Product_Key 和 Shop_Key

我们不能仅在这两个外键上创建 PK，因为这样一个商店只能卖一个玩具。

所以PK不会自动上所有FK的

但真正要带走的是您的数据模型(表、字段、键、数据类型)反射(reflect)了您的业务。如果一家商店真的只能销售一种玩具，那么在这两个领域进行 PK 将是一个有效的数据模型。

“事务表与主表”的一些特征

“交易”和“主”表通常具有多对一关系，这意味着许多交易匹配一个主记录。许多购买记录匹配同一个玩具记录。尽管“主”表也有 FK，但 FK 是对这种关系的死赠品

“交易”表通常有一个日期或某种事件 ID，并且在报告时通常被“聚合”。这可以是记录数或金额的总和。

现实世界系统的一些特征

很可能有人忘记了 FK 或 PK，或者可能有一个唯一的 key (不是 PK)强制执行您期望看到的内容。

我见过 key 明显不正确或根本没有 key 的实时系统。