Понимание внешних ключей

Question

Я разложил одну таблицу ниже на 3 таблицы, чтобы преобразовать ее в 3NF на основе следующих зависимостей и составного ключа (FirstName, LastName, Career):

Первая нормальная форма:

FirstName, LastName, Address, Career, Pay, Managerial

Зависимости:

FirstName, LastName -> Address
Career -> Pay, Managerial

Третья нормальная форма:

People (FirstName, LastName, Career)
Addresses (FirstName, LastName, Address)
Careers (Career, Pay, Managerial)

Для целей этого примера мы можем предположить, что (FirstName, LastName) является уникальным, а также (Career) чтобы не создавать их идентификаторы в таблицах адресов и карьер.

Правильно ли я считаю, что в этой схеме нет внешних ключей?Ключи в Адреса и Карьера только частично составляют ключ в Люди.Или у людей фактически есть 2 внешних ключа: FK (FirstName, LastName) и FK (Career) и 1 первичный ключ: PK (FirstName, LastName, Career)?

Answer 1

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

Здесь, если ваши оригинальные FD образуют покрытие: у вас есть People CKs {{FirstName, LastName, Career}}, адреса CKs {{FirstName, LastName}} & Careers CKs {{Career}}. Таким образом, ФК - это ФК Людей {Имя, Фамилия} по адресам и {Карьера} для Карьеры.

PS Часто при нормализации мы понимаем, что не хотим проекций исходной таблицы, но вместо этого нам нужны таблицы с заголовками, похожими на некоторые компоненты, но которые содержат больше строк. (Иногда это искажается как часть нормализации.) (Мы обнаруживаем & перепроектируем для аномалий удаления и вставки, хотя нормализация только обращается к аномалиям обновления.) Тогда у этих различных таблиц, которые мы выбираем, вообще нет тех же CK или наборов значений subrow как компоненты нормализации.

PS Нормализация в высшие НФ не вводит новые столбцы. Сюда входят столбцы идентификаторов.

PS Относительно "FK" обычно включает набор столбцов. Но это может означать список столбцов, ссылающийся на другой. Или список столбцов, где каждое имя появляется один раз, ссылаясь на другое. Но SQL «FK» не означает ни одного из этих реляционных понятий FK - он более или менее означает иностранный суперключ. Точно так же SQL «PK» более или менее означает первичный суперключ. См. Этот ответ.

Answer 2

Вы не правы.Я не согласен с вашей схемой, но Person.Career является ссылкой внешнего ключа на Careers.Career.

Аналогично, где-то в схеме должны быть идентификатор адреса и идентификатор человека.

Answer 3

На самом деле у вас есть отношения многие ко многим. Таким образом, один адрес может занять много человек. У одного человека может быть много адресов. В этом случае у вас будут дубликаты в таблице персон и дубликаты в таблице адресов. Внешние ключи будут другими, но другие части будут повторяться. Обычно есть таблицы:

Персона Адреса (person_id, address_id, occulied_from, busy_till)

PersonCareers (person_id, career_id, employee_from, employee_till)

Другая часть заключается в том, что не существует СУБД, предоставляющих сложные ключи, как вы упомянули, как это описано в теории БД