Question

我正在建立一个存在Presents的系统。这些礼物可以是您提供或呈现给您的礼物。此外，这些礼物可以是单人或多人，最后他们也可以是类型，如玩具，食品，旅行或其他。

所以，我想到了：

Presents --> Toys --> Offer   --> Single
         |        |           --> Multiple
         |        --> Receive --> Single
         |                    --> Multiple
         --> Food --> Offer   --> Single
         |        |           --> Multiple
         |        --> Receive --> ...
         --> Trip --> ..
         --> Other --> ..

我发现这是我系统的唯一解决方案。所有“叶子”都将在不同的表中实现，因为所有“叶子”可以有不同的模型，有时它将是另一个属性。有时它会更多。因此，它是一个三重继承，其中Present类的模型根据三个因素而变化。

问题是，如果你知道我的意思，我发现这个解决方案非常难看。那就是为什么我想问你们这个问题你们的看法。

提前致谢。琼

Answer 1

我不知道更多，我只能推测，但做出一些假设：

有概念：礼物，玩具，食物，旅行，其他，优惠，接收，单，多个。
这些概念中的每一个都有一组稳定的属性。
目前您有16个表，每个表的结构不同。

您的模型可以用10个表来描述，每组稳定属性一个，加上一个将它们组合在一起的链接表。

链接表需要稀疏列，即（玩具，食物，旅行，其他）四个参考列中的三个都有空，所以这不是规范化的，而是更像数据仓库模式。

事实表看起来有点像（省略列类型）：

gift_id not null, //primary key
present_id not null, // always have one of these
toy_id null, //refers to a row in the toy table
food_id null, // refers to a row in the food table...and so on below
trip_id null,
other_id null,
offer_id null,
receive_id null,
single_id null,
multiple_id null

由于需要新的东西，因此这个事实表可能需要额外的列，但仍然有点不愉快，但添加可空的列是一件非常安全的事情。

Answer 2

这里有一个非常相似的问题......

How to model this multiple inheritance relationship with a RDBMS?

如果您正在使用PostgreSQL，则允许多重继承。

 CREATE TABLE presents
 (
    gift_id INT,
    PRIMARY KEY(gift_id)
 );

 CREATE TABLE offer_receiver
 (
   is_offer BOOLEAN,
   PRIMARY KEY(is_offer)
 );

 CREATE TABLE present_quantity
 (
   qty_received INT,
   PRIMARY KEY(qty_received)
 );

 CREATE TABLE present_info
 (
   person_id INT,
   PRIMARY KEY(person_id)
 ) INHERITS(present, offer_receiver, present_quantity);

本文对何时以及如何使用继承进行了很好的解释：

http://ledgersmbdev.blogspot.com/2012/08/postgresql-or-modelling-part-3-table.html

所有这一切，重新考虑这个设计可能是一个好主意。这看起来更像是对象层次结构而不是ER模型。请记住，对程序中的数据建模可能是parent-＆gt; child，但是对数据库中的数据建模可能是倒退的。

Dbs中的多重继承建模

2 个答案: