在我的数据库中有一个名为doctor的基表，我有列
Name, d_ID, Age, Gender, Contact_NO, Speciality, beg_Date, End_Date
我希望我的桌子正常化。我发现医生表的依赖关系如下：
Name, d_ID ---> Age, gender, Speciality
d_ID----> Name, Contanct_NO, Beg_Date, End_Date
还有一些具有类似结构的基表。
我已经计算了闭包，发现我有2个候选键，它们是{d_ID}和{Name,d_ID}。我选择{d_ID}作为主键，{Name,d_ID}作为次要键。
我的问题是：
patient_record的中间表，它有doctor id，patient id，nurse id，bed id (foreign key)等等。我的混淆在于，如果规范化只需要对中间表而不是其他基表进行。我相信这一点，因为基表只有列的唯一标识符，因此它们会自动落在2NF以下？我计算了闭包，发现我有2个候选键{d_ID}和{Name，d_ID}（如果我错了请纠正我）。
根据定义，候选键是不可简化的。如果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的意外复制品.1991是与117不同的医生;他们都是同一家医院的心脏病专家，他们的医院特权在同一天开始和停止，这只是巧合。
这是识别行和识别医生之间的区别。
它是否在2NF中取决于可能尚未识别的其他功能依赖性。可能有几个。
2）我有一个名为patient_record的中间表，其中包含医生ID，患者ID，护士ID，床名（外键）等。如果必须仅对中间表而不是其他基表进行规范化，我感到很困惑。
通常对所有表进行标准化。
因为基表只有列的唯一标识符，因此它们会自动落在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，symbol--明确地标识现实世界中的元素。对于这个问题，只有一个可能的答案：“铍的原子序数是多少？”
现在看看医生的表。这个问题的答案不止一个，“名叫'约翰史密斯'的医生的身份证号码是多少？”事实上，对于同一位医生来说，有多个可能的答案，因为234和117指的是同一个人。
包含更多列没有帮助，因为两位医生的数据相同。你可以得到一个以上的答案：“45岁的男医生的名字是什么，名字是'John Smith'，他的电话号码是123-456-7890，他的专长是'Cardio' ？”
如果您发现有人为这两位医生预约，您可能会发现他们的身份证号码写在黄色粘稠物上，并卡在他们的显示器上。
每个ID号明确地标识数据库中的一行，但每个ID号不能明确地识别医生。你知道ID 117识别出一个名叫约翰史密斯的医生，但是如果约翰史密斯都站在你面前，你将无法分辨哪一个属于身份证号码117.（除非你读过那个黄色粘稠的，并且你知道布拉德皮特的样子。但这些信息不在数据库中。）
这与你的问题有什么关系？
规范化基于功能依赖性。当我们谈论“功能依赖”时，我们谈论的是什么“功能”？我们在谈论identity function。
这是规范化过程：