0

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

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

2）每个应用程序都可以通过不同的渠道进行通信，例如Internet（E-Mail、Twitter、Facebook）、Phone（SMS、MMS 等），因此程序和渠道之间存在多对多的关系。

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

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

基本上，我所做的是创建四个表 , ,Program并存储有关每个表的信息，而不是为 , 等创建连接表，这只会使设计复杂化，我创建了一个由主表组成的表这四个表的键具有唯一约束。现在，该表的每条记录都链接到给定的通信。ChannelIdentCommunicationType(Program, Channel)(Program, Identifier)(Program, Channel, Ident, CommunicationType)

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

4

3 回答 3

2

基本上，我所做的是创建四个表，Program、Channel、Ident 和 CommunicationType 来存储有关每个表的信息，并且，

这是个好主意。

我没有为 (Program, Channel)、(Program, Identifier) 等创建联结表，这只会使设计复杂化，而是创建了一个由这四个表的主键组成的表，并对 (Program,通道、身份、通信类型）。

当您设计这样的表格时，您需要注意一件事。您的结构具有键 {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)
);

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

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

于 2011-07-03T00:31:13.667 回答
1

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

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

但是，要真正回答您的问题，了解您选择此设计的原因会很有用。

毕竟，如果没有具有所有键和复合唯一索引的单个表，它也可以工作。以这种方式锁定所有组合是相当严格的。

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

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

于 2011-07-02T23:59:10.067 回答
1

我不会这样做。

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

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

于 2011-07-03T00:10:50.353 回答