我目前正在从事一个数据模型设计(将由RDMS支持)。它基于大约3个与组织成员福利相关的实体。实体包括“福利”、“成员资格类型”和“提供者”。我已经创建了一个标准的多对多交叉表来关联两个实体,但从来没有创建过3。我想知道是否有人做过这样的事情,是否有任何我应该避免的潜在陷阱。该表如下所示:
create table BENEFIT_MEM_TYPE_PROVIDER
(
BENEFIT_ID reference BENEFITS not null,
MEMBERSHIP_TYPE_ID reference MEMBERSHIP_TYPES not null,
PROVIDER_ID reference PROVIDERS not null,
primary key (BENEFIT_ID, MEMBERSHIP_TYPE_ID, PROVIDER_ID)
)我觉得这段关系有些地方不对劲,所以我想我应该向聪明人请教。
谢谢
发布于 2010-08-10 17:43:08
是。
三元关系被广泛使用,尽管不像二元关系那样广泛使用。这甚至可以扩展到四元或一般的n元关系。
在数据库设计中可以看到n元关系的一个地方是星型模式。位于星形中心的事实表是一个n元关系,其中n是事实表引用的维度表的数量。
规范化过程包括检测与某些范式的背离,并分解表格以产生更规范化的等价物。分解有时会降低n元关系的顺序。
星型模式故意走另一条路。这就是为什么星型模式和规范化经常被视为彼此不一致的原因。
发布于 2010-08-10 04:02:01
任何人都做过这样的事情
是。
如果有任何我应该避免的潜在陷阱。
如果福利-成员资格、福利提供者和成员资格提供者之间的关系从该表中的数据看起来可能是真的,但实际上不应该是真的,这可能会导致问题。
例如,成员-提供者-利益可能有一个“限制”,即该利益仅在涉及特定提供者时才应用于该成员。这种关系可能不是普遍正确的,但由于某些限制,作为特殊情况是正确的。
在这种情况下,您需要在该表中包含该限定,以确保可以通过简单的SQL查询正确地发现这些异常情况。
简而言之,当您有多个关系时,请确保每行中的成对关系也是真的。
发布于 2010-08-10 06:50:33
您应该验证您的表是否满足第五范式(5NF)。如果不是这样,那么可能更好的做法是将其标准化,使其处于5NF中。
https://stackoverflow.com/questions/3443670
复制相似问题