接线表和标准化问题

Question

我很难弄清楚以下设计模式是否可以接受。我对关系模型有以下要求（以及其他一些要求）：

1）它必须能够表示应用程序（例如 AppA、AppB、AppC），每个都有它自己的一组属性。

2）每个应用程序都可以通过不同的渠道进行通信，例如互联网（电子邮件、Twitter、Facebook）、电话（短信、彩信等），因此有很多-节目和频道之间的一对多关系。

3) 有一组预定义的标识符（地址、电话号码、登录帐户）可以由许多程序共享，因此程序和标识符之间也存在多对多关系。

4）相同的标识符可以发送多种类型的消息，程序也可以（同样是多对多），但我需要能够在每个应用程序的基础上限制通信类型标识符的使用。

基本上，我所做的就是创建四个表：Program、Channel、Ident 和 CommunicationType 来存储以下信息：我没有为 (Program, Channel)、(Program, Identifier) 等创建联结表，这只会使设计变得复杂，而是创建了一个由这四个表的主键组成的单个表具有唯一的对（程序、通道、Ident、通信类型） 的约束。现在，该表的每条记录都链接到给定的通信。

当然，这以一种非常简单的方式解决了我的问题，但现在我问自己，如果它违反了规范化原则，这是否可以接受。有人可以给我意见吗？

Answer 1

基本上，我所做的就是创建
四个表，节目、频道、识别
和要存储的通信类型
有关其中每一项的信息以及，

这是个好主意。

而不是创建连接表
对于（节目，频道），（节目，
标识符），等等
只是使设计复杂化，我创建了
一个表由以下组成
这四个表的主键
对（程序，
通道、身份、通信类型）。

当你设计这样的表格时，你需要小心一件事。您的结构具有键 {Program, Channel, Ident, CommunicationType}，允许 Program 和 Channel、Channel 和 Ident、Program 和 CommunicationType 等各种可能的组合。有时这是一个坏主意。

同一个标识符可以发送多个
消息类型，因此可以
程序（再次，多对多），但我
需要能够限制使用
通信类型标识符
每个应用程序的基础。

这就是它成为一个坏主意的原因。您似乎是在说，并非 Ident、Program 和 CommunicationsType 的每个组合都是有效的。

将有效组合存储在自己的表中。使用外键引用来维护数据完整性。

构建一个具有键 {Program, Ident, CommunicationsType} 的表。具有键 {Program, Channel, Ident, CommunicationType} 的表可以设置对其的外键引用。

构建尽可能多的表来实现您所知道的所有约束。更多表意味着数据完整性检查更简单。 （您可能需要比我提到的更多的表。不要假设它们需要有两列；它们可能需要更多。）

您是否需要一个键为 {Program, Channel} 的表还不清楚。但如果你这样做，那么你需要按照这些思路构建表格。 （空气代码。）

create table pc (
    program_name varchar(10) not null references programs (program_name),
    channel_name varchar(10) not null references channels (channel_name),
    primary key (program_name, channel_name)
);

create table pict (
    program_name varchar(10) not null,
    channel_name varchar(10) not null,
    comm_type varchar(10) not null references communication_type (comm_type),
    primary key (program_name, channel_name, comm_type),
    foreign key (program_name, channel_name) 
        references pc (program_name, channel_name) 
);

create table your-table-name (
    program_name varchar(10) not null,
    channel_name varchar(10) not null,
    comm_type varchar(10) not null,
    ident varchar(10) not null,
    primary key (program_name, channel_name, comm_type, ident),
    foreign key (program_name, channel_name, comm_type) 
        references pict (program_name, channel_name, comm_type),
    foreign key (ident) references ident (ident)
);

根据需要添加其他列。在某些情况下，您可能会发现需要重叠的外键。我认为你在这里不需要它们，但我可能是错的。

我不确定你所说的“如果它违反了正常化原则”是什么意思。具有四列主键的表不会违反任何正常形式仅仅因为这个原因，尽管可能由于其他原因。未能实现所有已知的约束通常是，嗯，次优设计，但这并不是因为它违反了任何正常形式。

Answer 2

我不会这样做。

我会在每对（或 n 元组）表之间创建一个联结表。这最终将允许更简单的查询，并且还允许您根据需要在每种情况下独立于其他情况以适当的方式约束行。

您可能还会发现这些连接处需要额外的归因，例如从一个软件到另一个软件，方向性、有效负载、使用的语言、正在访问的查询点等是什么。

Answer 3

很抱歉为您提供了需要更多信息的答案。在这一点上，我的声誉不允许发表任何评论……

根据解释，我看不出所选择的设计有什么问题。

然而，要真正回答您的问题，了解您选择这种设计的原因会很有用。

毕竟，即使没有包含所有键和复合唯一索引的单个表，它也可以工作。以这种方式锁定所有组合是相当有限制的。

当您找到通信时，您仍然需要加入一个或多个其他表才能访问构成该通信的信息。

为什么要以这种方式存储每个唯一的通信路径？