я вычислил затворы и обнаружил, что у меня есть 2 возможных ключи, которые {d_ID} и {Имя, d_ID} (Пожалуйста, поправьте меня, если я ошибаюсь).
No. По определению ключи-кандидаты неприводимы. Если d_ID является ключом-кандидатом, то {Name, d_ID} нет. {Name, d_ID} не является ключом-кандидатом, потому что это приводимо. Отбросьте атрибут «Имя», и у вас есть ключ-кандидат (d_ID).
1) Я хочу знать, есть ли мой стол уже в 2NF. Если нет, пожалуйста, дайте мне знать, как сломать отношение?
В этом случае действительно сложно сказать.Хотя у вас есть уникальный идентификационный номер для каждого врача, в вашем случае он служит только для определения ряда, а не врача. Ваша таблица позволяет такие данные.
d_ID Name Age Gender Contact_NO Speciality beg_Date End_Date
--
117 John Smith 45 M 123-456-7890 Cardio 2013-01-01 2015-12-31
199 John Smith 45 M 123-456-7890 Cardio 2013-01-01 2015-12-31
234 John Smith 45 M 123-456-7890 Cardio 2013-01-01 2015-12-31
Сколько врачей существует? (Я составил данные, поэтому я действительно единственный, кто знает правильный ответ.) Есть два. 234 - случайный дубликат 117. 199 - другой врач, чем 117; это просто совпадение, что они оба - сердечные специалисты в той же больнице, и их больничные привилегии начинаются и останавливаются в одни и те же даты.
В этом разница между идентификацией строки и идентификацией врача.
Независимо от того, зависит ли оно от 2NF от других функциональных зависимостей, которые еще не могут быть идентифицированы. Их может быть несколько.
2) У меня есть промежуточная таблица под названием patient_record, у которой есть идентификатор врача, идентификатор пациента, идентификатор медсестры, идентификатор кровати (внешний ключ) и т. Д. я запутался, если нормализация должна выполняться только для промежуточных таблиц, а не для других базовых таблиц.
Нормализация обычно выполняется для всех таблиц.
Поскольку базовые таблицы имеют только уникальные идентификаторы для столбцов и, следовательно, они автоматически попадают под 2NF?
Нет, это неправда. Для уточнения см. Мой ответ на Learning database normalization, confused about 2NF.
Определение строки и идентификация вещи
Это тонкий момент, но это действительно очень важно.
Давайте посмотрим на таблицу с хорошим поведением, в которой есть три ключа-кандидата.
create table chemical_elements (
element_name varchar(35) not null unique,
symbol varchar(3) not null unique,
atomic_number integer not null unique
);
Все три атрибута в этой таблице объявлены not null unique, который является SQL идиома для определения возможных ключей. Если вы чувствуете себя некомфортно, не имея хотя бы одного кандидата, объявленного как primary key, просто выберите его. На самом деле не важно, какой из них.
insert into chemical_elements
(atomic_number, element_name, symbol)
values
(1, 'Hydrogen', 'H'),
(2, 'Helium', 'He'),
(3, 'Lithium', 'Li'),
(4, 'Beryllium', 'Be'),
[snip]
(116, 'Ununhexium', 'Uuh'),
(117, 'Ununseptium', 'Uus'),
(118, 'Ununoctium', 'Uuo');
Каждый из трех ключей-кандидатов - atomic_number, ELEMENT_NAME, символ - однозначно идентифицирует элемент в реальном мире. Есть только один возможный ответ на вопрос: «Что такое атомный номер для бериллия?»
Теперь посмотрите на таблицу врачей. Существует более чем один возможный ответ на вопрос: «Каков идентификационный номер доктора« Джон Смит »? На самом деле, существует более одного возможного ответа для того же самого врача, потому что 234 и 117 относятся к тому же человеку.
Это не помогает включать больше столбцов, потому что данные для обоих врачей одинаковы. Вы можете получить более одного ответа на вопрос: «Какой идентификационный номер для 45-летнего мужчины-врача, чье имя« Джон Смит », чей номер телефона 123-456-7890 и чья специальность« Кардио », ?"
Если вы находите людей, делающих назначения для этих двух врачей, вы, вероятно, обнаружат, что их идентификационные номера, написанные на желтый липкий и застрял на своем мониторе.
- Доктор Джон Смит, который похож на Брэда Питта (!), ID 117.
- Другой доктор Джон Смит, ID 199.
каждый идентификационный номер однозначно идентифицирует строку в базе данных, но каждый идентификационный номер не однозначно идентифицировать врача. Вы знаете, при ID 117 идентифицирует врача по имени Джон Смит, но если бы оба Джона Смита стояли перед вами, вы не смогли бы сказать, какой из них принадлежал идентификационному номеру 117. (Если вы не читали эту желтую липкость, и вы знали как выглядел Брэд Питт. Но что информации нет в базе данных.)
Что это касается вашего вопроса?
Нормализация основана на функциональных зависимостях. О какой «функции» мы говорим, когда говорим о «функциональных зависимостях»? Речь идет о identity function.
не могли бы вы более подробно рассказать о «Это разница между определением строки и определением врача». Я не уверен, что понимаю, почему это имеет значение для нормализации любой таблицы. я думал, что нормализация означает просто найти FD и вывести из них ключи, чтобы узнать, зависят ли все другие непервичные атрибуты от всего ключа-кандидата. – Gayu
@Gayu: расширен ответ. –
oooohhhh okies спасибо за объяснение, эта ситуация по-прежнему сохраняется, если я меняю ID на SSN (номер социального страхования) ?. Насколько я понимаю, это решит проблему? поскольку SSN уникален независимо от того, сколько раз тот же самый доктор вводится в таблицу? Я прав? – Gayu