具有公共主键的表

发布于 2024-09-26 22:32:34 字数 208 浏览 0 评论 0原文

描述共享公共主键的表之间关系的术语是什么?

下面是一个示例:

表 1
property(property_id, property_location, property_price, ...);

表 2
公寓(property_id, flat_floor, flat_bedroom_count, ...);

What's the term describing the relationship between tables that share a common primary key?

Here's an example:

Table 1
property(property_id, property_location, property_price, ...);

Table 2
flat(property_id, flat_floor, flat_bedroom_count, ...);

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

扫码二维码加入Web技术交流群

发布评论

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

评论(6

迷你仙 2024-10-03 22:32:34

您所拥有的看起来类似于表继承。如果您的表结构是所有 flat 记录代表单个 property,但并非所有 property 记录都引用 flat ,那就是表继承。它是一种在关系数据库中对类似于面向对象关系的事物进行建模的方法(换句话说,flat 继承于property)。

What you have looks like table inheritance. If your table structure is that all flat records represent a single property but not all property records refer to a flat, then that's table inheritance. It's a way of modeling something close to object-oriented relationships (in other words, flat inherits from property) in a relational database.

面如桃花 2024-10-03 22:32:34

如果我正确理解你的例子,数据建模术语是超类型/子类型。这是一种建模技术,您可以定义一个包含公共属性的根表(超类型),以及一个或多个引用表(子类型),其中包含基于建模实体的不同属性。

例如,您可以有一个“人员”表(超类型),其中包含与所有人相关的属性列,例如“姓名”。然后,您可以拥有一个 Employee 表(子类型),其中仅包含特定于员工的属性,例如工资率和雇用日期。然后,您可以使用其他人员专业化的附加表(例如承包商)继续此过程。每个子类型表都有一个 PersonID 键列(可以是子类型表的主键)以及引用 Person 表的外键。

有关其他信息,请在 Google 中搜索“超类型和子类型实体”,然后查看下面的链接。

If I understand your example correctly, the data modeling term is Supertype/Subtype. This is a modeling technique where you define a root table (the supertype) containing common attributes, and one or more referencing tables (subtypes) that contain varying attributes based on the entities being modeled.

For example, you could have a Person table (the supertype) containing columns for attributes pertaining to all people, such as Name. You could then have an Employee table (the subtype) containing attributes specific to employees only, such as rate of pay and hire date. You could then continue this process with additional tables for other specializations of Person, such as Contractor. Each of the subtype tables would have a PersonID key column, which could be the primary key of the subtype table, as well as a foreign key referencing the Person table.

For additional info, search Google for "supertype and subtype entities", and see the links below.

人间不值得 2024-10-03 22:32:34

在通用数据库术语中,这种关系没有一个好的名称(据我所知)。它不是一对一的关系,因为不能保证主表中的每条记录在“扩展”表中都有一条记录。这不是一对多关系,因为关系的“多”方最多允许一条记录。

我能做的最好的就是一对一或无或最多一对一的关系。 (我自己承认使用了草率的术语 - 我只是将其称为一对一关系。)

无论您决定如何称呼它,您都可以通过将属性中的 property_id 列设置为 PK 来正确建模并维护数据库中的完整性property_id 列中的 PK 和 FK 返回到属性。

There isn't a good name for this relationship in common database terminology (as far as I know). It's not a one-to-one relationship because there isn't guaranteed to be a record in the "extending" table for each record in the main table. It's not a one-to-many relationship because there a maximum of one record allowed on what would otherwise be the "many" side of the relationship.

The best I can do is a one-to-one-or-none or a one-to-one-at-most relationship. (I will admit to sloppy terminology myself — I just call it a one-to-one relationship.)

Whatever you decide to call it, you can model it properly and maintain integrity in your database by making the property_id column in property a PK and the property_id column in flat a PK and also an FK back to property.

掀纱窥君容 2024-10-03 22:32:34

《逻辑与数据库》将这种关系的术语“最多一到最多一”推进了。 (请注意,根据表参与的关系来为表分配名称是疯狂的。)

请注意那些提出诸如“外键”、“表继承”、简短等建议的人 。此处给出的其他答案。这些人正在做出您没有明确声明有效的假设,即您的两个表之一将保证包含另一个表中出现的所有键值。

"Logic and Databases" advances the term "at most one to at most one" for this kind of relationship. (Note that it is insane to assign names to tables on account of which relationships they participate in.)

Beware of the people who have suggested things like "foreign key", "table inheritance", brief, all the other answers given here. Those people are making assumptions that you have not explicitly stated to be valid, namely that one of your two tables will be guaranteed to contain all key values that appear in the other.

甜点 2024-10-03 22:32:34

(该网站的功能障碍使我无法在适当的位置将其添加为评论。)

“您如何解释“...共享一个公共主键?””

我以唯一可能的合理意义解释这一点:在 table1 中,主键的属性值保证是唯一的,并且在table2中,主键的属性值保证是唯一的。此外,两个表中的主键具有相同的属性名称,并且主键属性对应的类型也成对相同。不多也不少。

特别是,“共享主键”意味着“具有共同的主键”,这又意味着“共同具有某种‘内部唯一性规则’”,但这种共同性并不能保证 出现在一个表中的主键值也必须出现在第二个表中。

“您能否举一个涉及两个具有共享主键的表的示例,其中一个表不会包含另一个表中出现的所有键值?” "

表1:整数类型的列A,主键A
表2:整数类型的列A,主键A

表1 中的行:{A:1}。满足table1的主键。
表 2 中的行:{A:2}。满足table2的主键。

确信吗?

(Disfunctionality of the site prevents me from adding this as a comment in the proper place.)

"How would you interpret "...that share a common primary key?" "

I interpret that in the only reasonable sense possible: that within table1, attribute values for the primary key are guaranteed to be unique, and that within table2, attribute values for the primary key are guaranteed to be unique. And that furthermore, the primary key in both tables has the same [set of] attribute names, and that the types corresponding to the primary key attribute[s] are also pairwise the same. Nothing more and nothing less.

In particular, "sharing a primary key" means "having a primary key in common", and that means in turn "having a certain 'internal uniqueness rule' in common", but that commonality guarantees in no way that a primary key value appearing in one table must also appear in the second table.

"Can you give an example involving two tables with shared primary keys where one table wouldn't contain all the key values that appear in the other?" "

Table1: column A of type integer, primary key A
Table2: column A of type integer, primary key A

Rows in table1: {A:1}. Satisfies the primary key for table1.
Rows in table2: {A:2}. Satisfies the primary key for table2.

Convinced ?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文