Если у меня есть несколько ключей-кандидатов, какой из них является первичным ключом и оправдывает ли ваш выбор?

Question

Дано:

R = {Счет, Аналитик, Активы, Брокер, Клиент, Комиссия, Компания, Дивиденд, Обмен, Инвестиции, Офис, Профиль, Возврат, Риск_профиль, Запас, Объем}

и набор функциональных зависимостей:

F {fd1, fd2, fd3, fd4, fd5, fd6, fd7, fd8, fd9, fd10, fd11}

где:

fd1: Клиент -> Офис
fd2: Фондовая биржа -> Обмен, Дивиденд
fd3: Брокер -> Профиль
fd4: Компания -> Акции
fd5: Клиент -> Risk_profile, Аналитик
fd6: Аналитик -> Брокер
fd7: Фондовая, Брокер -> Инвестмент, Объем
fd8: Фондовая -> Компания
fd9: Инвестиции, Комиссия -> Возврат
fd10: Акции, Брокер -> Клиент
fd11: Аккаунт -> Активы

это ключи-кандидаты:

(Аккаунт, Комиссия, Аналитик, Компания)
(Счет, комиссия, аналитик, акция)
(Счет, комиссия, брокер, компания)
(Счет, комиссия, брокер, акция)
(Счет, комиссия, клиент, компания)
(Счет, комиссия, клиент, акция)

(Q) Выберите первичный ключ и обоснуйте свой выбор?

Я был выбран
(счет, комиссия, брокер, акция) в качестве первичного ключа ???

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

пожалуйста, проверьте, правдив ли мой ответ? или нет

Я жду вашего ответа как можно скорее

спасибо

Answer 1

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

Я подозреваю, что они просто злые.

Для всех соответствующих возможных ключей я бы порекомендовал создать уникальные индексы, которые давали бы преимущества (гарантированная уникальность и быстрый поиск) и ни одного из недостатков (не начинайте меня).

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

Answer 2

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

Вот почему Дата отбросила понятие «первичный ключ» более 15 лет назад. Каждый ключ соответствует определенному правилу уникальности, и ни один ключ не является «более уникальным», чем любой другой. Период.

Системы баз данных никогда не должны были быть такими, чтобы они заставляли разработчика базы данных принимать такие незначительные решения. Причина, по которой они действительно заставляют проектировщика базы данных делать такой выбор, отчасти по историческим причинам (времена, когда считалось, что первичное / вторичное различие имеет какое-то значение), а отчасти потому, что большие собаки на земле dbms довольно счастливы, НЕ улучшаются их существующие генерирующие денежные потоки системы в любой реляционной степени.