Может ли таблица базы данных содержать более одного первичного ключа?

Question

Может ли таблица базы данных содержать более одного первичного ключа?

Да, я говорю о РСУБД.

Answer 1

Таблица может иметь:

• Нет первичных ключей;
• Один первичный ключ, состоящий из одного столбца;или
• Один составной первичный ключ, состоящий из двух или более столбцов.

Кроме этого, у вас может быть любое количество уникальных индексов, которые в основном будут делать то же самое.

Answer 2

Краткий ответ - да. Первичный ключ является ключом-кандидатом и в принципе не отличается от любого другого ключа-кандидата. Широко распространено соглашение, что один ключ-кандидат на таблицу обозначается как «первичный», что означает, что он «предпочтителен» или имеет какое-то особое значение для разработчика базы данных или пользователя. Это просто соглашение однако. Это всего лишь знак удобства и напоминание о потенциальной значимости одного ключа. На практике все ключи могут служить одной и той же цели, и «основной» не является особенным или уникальным в какой-либо фундаментальной форме.

Answer 3

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

Могу ли я вежливо предложить вам сначала получить образование по этим же предметам, прежде чем вводить других людей в ошибочные убеждения? Я отвечу на две худшие из ваших глупостей ниже.

«Согласно принципам реляционной методологии, у каждого объекта должен быть только один и только один способ его идентификации».

Это самая большая чушь, которую я когда-либо слышал, о создании реляционных данных. Реляционная модель не ограничивает какой-либо «объект», как вы его ошибочно называете, точным количеством ключей. Любая «сущность» может иметь любое количество ключей, и КАЖДЫЙ ключ, по определению самого свойства сделать «строки» уникальными, является подходящим кандидатом для любой цели «идентификации». Выбор наиболее полезного / подходящего для использования в определенных контекстах (например, внешние ключи в ссылочных таблицах) является проблемой проектирования, и реляционная модель ничего не может сказать о таких вещах.

«Следовательно, СУБД« R »пытается облегчить моделирование отношений сущностей».

Статья Кодда "Реляционная модель даты для больших общих банков данных", которая отмечает реляционную модель, предшествует изобретению E-R на несколько лет. Таким образом, сказать, что реляционная модель пытается облегчить моделирование концепций ER, имеет вещи ПОЛНОСТЬЮ назад и не что иное, как отображение собственного полного и полного незнания «истории», на которую вы ссылались в своем собственном ответе. *

Answer 4

Да, у вас могут быть составные первичные ключи, то есть два поля в качестве первичного ключа.

Answer 5

Первичный ключ реляционной таблицы однозначно идентифицирует каждую запись в таблице. Таким образом, чтобы сохранить уникальность каждой записи, вы не можете иметь более одного первичного ключа для таблицы. Это может быть либо обычный атрибут, который гарантированно будет уникальным (например, номер социального страхования в таблице, содержащий не более одной записи на человека), либо он может быть создан СУБД (например, глобально уникальный идентификатор или GUID, в Microsoft SQL Server). Первичные ключи могут состоять из одного атрибута или нескольких атрибутов в комбинации.

Answer 6

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

Чтобы определить границы сущности и отношения, которые должны быть сформированы, должен быть уникальный дескриптор или уникальная комбинация дескрипторов для идентификации каждого отдельного экземпляра сущности, а затем для формирования отношений между ними.

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

Согласно принципам реляционной методологии, у каждого объекта должен быть только один и только один способ его идентификации. Поэтому СУБД "R" пытается облегчить моделирование отношений сущностей. Обратите внимание на различия между «Entity / Class» и «Entity / Class instance».

Однако СУБД широко используется и в основном людьми, которые не очень заинтересованы в точном изображении принципов проектирования E-R. Так что часто у нас есть несколько возможных определений сущностей внутри таблицы, которые я называю псевдонимами сущностей. В отличие от псевдонимов идентификаторов, когда два или более экземпляров набора сущностей скрываются под одним и тем же ключом, псевдоним сущностей подобен таблице

EmpProj([empId], empName, empAddr, projId, projLoc)

фактически имеет два набора сущностей с псевдонимом под одной таблицей:

Emp([empId], empName, empAddr)
Proj([projId], projLoc, empId)

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

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

Именно здесь хороши альтернативные уникальные ключи - для идентификации экземпляров сущностей из-за основных компонентов, существующих в базе данных как призрачных сущностей.

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

Что касается статистики, то, хотя база данных допускает только один первичный ключ на таблицу, альтернативные уникальные ключи являются для статистики первичными ключами для этих призрачных сущностей. Вот почему иногда вы разочарованы статистиками, которые, кажется, выполняют двойную работу, загружая данные в локальную базу данных своей рабочей станции / ПК.

В заключение, ограничение, наложенное производителем СУБД "R" на разрешение использования только одного первичного ключа на таблицу, является их предлогом в том, что он знает, как ведет себя информация, и полагает, что основные компоненты информации из-за совокупности не изменяются со временем.

Если у вас в таблице более одного уникального ключа, это означает одну или несколько возможностей

1. Как и я, тебе лень отделить их, так как они, кажется, работают довольно хорошо
2. Ради производительности, смешивая сущности в одну таблицу делают приложение работает невероятно быстрее
3. Как и статистик, вы постепенно обнаружить призрачные сущности в вашем информация.

Answer 7

Вот почему он называется Первичным ключом, потому что, ну, в общем, ПЕРВИЧНЫЙ