Таблицы с общим первичным ключом - PullRequest
3 голосов
/ 09 октября 2010

Какой термин описывает отношения между таблицами, которые имеют общий первичный ключ?

Вот пример:

Таблица 1
свойство (property_id, property_location, property_price, ...);

Таблица 2
квартира (property_id, flat_floor, flat_bedroom_count, ...);

Ответы [ 6 ]

5 голосов
/ 09 октября 2010

То, что у вас есть выглядит как наследование таблиц. Если ваша структура таблицы такова, что все записи flat представляют одну property, но не все записи property относятся к flat, то это наследование таблицы. Это способ моделирования чего-то близкого к объектно-ориентированным отношениям (другими словами, flat наследуется от property) в реляционной базе данных.

4 голосов
/ 09 октября 2010

Если я правильно понимаю ваш пример, термин моделирования данных будет Supertype / Subtype.Это метод моделирования, при котором вы определяете корневую таблицу (супертип), содержащую общие атрибуты, и одну или несколько ссылочных таблиц (подтипов), которые содержат различные атрибуты на основе моделируемых объектов.

Например, вы можетеиметь таблицу Person (супертип), содержащую столбцы для атрибутов, относящихся ко всем людям, таких как Name.После этого вы можете иметь таблицу Employee (подтип), содержащую атрибуты, относящиеся только к сотрудникам, такие как ставка заработной платы и дата найма.Затем вы можете продолжить этот процесс с дополнительными таблицами для других специализаций Person, таких как Подрядчик.Каждая из таблиц подтипа будет иметь столбец ключа PersonID, который может быть первичным ключом таблицы подтипа, а также внешний ключ, ссылающийся на таблицу Person.

Для получения дополнительной информации найдите в Google «supertype иподтип сущностей "и см. ссылки ниже.

1 голос
/ 10 октября 2010

(Неисправность сайта не позволяет мне добавить это в качестве комментария в нужном месте.)

"Как бы вы интерпретировали" ... который имеет общий первичный ключ? ""

Я понимаю, что в единственно возможном смысле: в таблице 1 значения атрибутов для первичного ключа гарантированно будут уникальными, а в таблице 2 значения атрибутов для первичного ключа гарантированно будут уникальными.Более того, первичный ключ в обеих таблицах имеет одинаковые имена атрибутов [set of], и что типы, соответствующие атрибуту первичного ключа [s], также попарно одинаковы.Не больше и не меньше.

В частности, «совместное использование первичного ключа» означает «наличие общего первичного ключа», а это, в свою очередь, означает «наличие определенного общего« внутреннего правила уникальности », ночто общность никоим образом не гарантирует , что значение первичного ключа, появляющееся в одной таблице, также должно присутствовать во второй таблице.

"Можете ли вы привести пример, включающий две таблицы с общими первичными ключами, где одинтаблица не будет содержать все ключевые значения, которые появляются в другом? ""

Table1: столбец A целочисленного типа, первичный ключ A Table2: столбец A целочисленного типа, первичный ключ A

Строки в table1: {A: 1}. Удовлетворяет первичный ключ длятаблица 1. Строки в таблице 2: {A: 2}. Удовлетворяет первичный ключ для таблицы 2.

Убедительно?

1 голос
/ 09 октября 2010

«Логика и базы данных» продвигает термин «не более одного до не более одного» для такого рода отношений.(Обратите внимание, что безумно присваивать имена таблицам из-за того, в каких отношениях они участвуют.)

Остерегайтесь людей, предложивших такие вещи, как "внешний ключ", "наследование таблиц", кратко, все остальные ответы даны здесь.Эти люди делают предположения, которые вы явно не указали как действительные, а именно, что одна из ваших двух таблиц будет гарантированно содержать все ключевые значения, которые появляются в другой.

1 голос
/ 09 октября 2010

В общей терминологии базы данных нет подходящего названия для этих отношений (насколько я знаю).Это не взаимно-однозначное отношение, поскольку не гарантируется наличие записи в «расширяющейся» таблице для каждой записи в основной таблице.Это не отношение «один ко многим», потому что на одной стороне «многие» разрешено не более одной записи.

Лучшее, что я могу сделать - это один к одномуили-нет или отношения один-к-одному-в-большинстве.(Я признаю, что неаккуратная терминология - я просто называю это отношения один-к-одному.)

Независимо от того, что вы решите назвать, вы можете правильно смоделировать его и сохранить целостность в своей базе данных, указав property_idстолбец свойства PK и столбец property_id в квартире PK, а также FK обратно в свойство.

0 голосов
/ 09 октября 2010
...