当前位置：文江博客话题详情

在建模标题/详细信息关系时消除冗余关系？

发布于 2024-08-23 11:56:58 字数 257 浏览 5 评论 0原文

我有一个看起来像这样的模型：

Model

一个帐户有许多分支，每个报表都是为一个生成的帐户。该模型是多余的，因为可以从事务上的 BranchID 推断出帐户（标头上的 AccountID）（一条语句始终具有一个或多个事务）。

是否应该从 StatementHeader 中删除 AccountID，或者这种级别的冗余是否可以？或者有更好的解决方案吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夕嗳→ 2024-08-30 11:56:58

如果您有 StatementHeader，那么它应该有 AccountID 以保持引用完整性。

但是，最好完全删除 StatementHeader 并将 StatementDate 移至 Statement 记录中。这将使事情变得更清晰，并使模型更好地描述你想要的东西。

回复收藏 0 原文

旧时浪漫 2024-08-30 11:56:58

由于语句是历史性的，并且通常是只读的，因此数据有一些冗余是可以的。我同意 Richard Harrison 的观点，并将 [AccountID] 和 [StatementDate] 移至 [Statement] 表中；我的理由是你说一个账户有很多分支，所以你将为一个账户生成一份报表。

将所有这些数据存储在同一个地方将减少连接并加快报告速度，我认为这就是该数据库的原因。

回复收藏 0 原文

霓裳挽歌倾城醉 2024-08-30 11:56:58

有时，（真实的或感知的）冗余是业务规则的结果。在这种情况下，业务规则是：“向帐户发出的报表应仅包含属于该特定帐户的分支机构的交易。”

为了强制执行该规则，您可以尝试提出一个数据库模式，使其不可能违反该规则，或者使用约束或触发器显式强制执行该规则。使用 StatementHeader.AccountID 似乎更容易。在 Oracle 中，您可以编写如下内容：

create or replace trigger statement_has_unique_account
before insert or update on Statement
referencing old as old new as new
for each row
declare
  m integer;
  n integer;
begin
  select b.AccountID
  into m
  from Branch b 
  where b.ID = new.BranchID;

  select s.AccountID
  into n
  from StatementHeader s
  where s.ID = new.StatementID;

  if m <> n then
    raise_application_error(-1000, 'No way!');
  end if;
end;

如果 StatementHeader 中没有 AccountID，您必须编写与共享相同 StatementID 的所有其他 Statement 中的所有其他 AccountID 的比较，从而导致更复杂的语句序列。

因此，我将 AccountID 作为 StatementHeader 中的外键，并使用触发器显式强制执行业务规则。

Sometimes, (real or perceived) redundancy is a consequence of a business rule. In this case, the business rule is: "a statement that is issued to an account shall contain only transactions for branches that belong to that particular account."

To enforce that rule, you could try to come up with a database schema that makes it impossible to violate it, or enforce it explicitly with a constraint or trigger. And that seems to be easier with StatementHeader.AccountID. In Oracle, you could write something like this:

create or replace trigger statement_has_unique_account
before insert or update on Statement
referencing old as old new as new
for each row
declare
  m integer;
  n integer;
begin
  select b.AccountID
  into m
  from Branch b 
  where b.ID = new.BranchID;

  select s.AccountID
  into n
  from StatementHeader s
  where s.ID = new.StatementID;

  if m <> n then
    raise_application_error(-1000, 'No way!');
  end if;
end;

Without AccountID in StatementHeader, you'd have to write a comparison with all the other AccountIDs from all other Statements that share the same StatementID, resulting in a more complicated sequence of statements.

So i would keep AccountID as a foreign key in StatementHeader and enforce the business rule explicitly with a trigger.

回复收藏 0 原文

~没有更多了~