如果你开始为软件工程面试学习DBMS, 你可能会遇到诸如功能依赖,属性关闭, 候选密钥, 规范化,和Canonical Cover等术语。
对于许多初学者来说,"Canonical Cover"感觉像是另一个可以记住的算法.
事实并非如此。
在你学会如何计算卡通封面之前 你应该明白它为什么存在 本条仅侧重导言和基础。
我们不打算讨论这个算法 采访者的意图是什么?
当采访者询问Canonical Cover时,他们通常不会测试你的记忆.
相反,他们想知道你是否明白: 数据库如何代表业务规则 为什么多余的规则会产生问题 您是否可以简化复杂的依赖集 你是否理解正常化的基础 在访谈中,Canonical Cover经常出现在关于: 正常形式依赖性保存损失 BCNF Schema设计的问题之前 采访者正在检查你对数据库设计的理解,而不是你背诵定义的能力.
为什么采访者要问Canonical封面?
想象一个数据库里有成百上千的依赖规则。
重复相同信息,包含不必要的属性 可从其他规则中衍生出来。
Canonical Cover主要是关于回答一个问题:“我们能否用更少和简单的规则来代表完全相同的限制?” 故采访者所问.
他们想知道你是否欣赏: 简洁的正确性可维持性 有效的计划设计 将DBMS主题视为学习路线图.
Canonical Cover属于DBMS的数据库设计部分.
它作为理解依赖性与实现正常化之间的桥梁。
在学习冠状封面之前, 您必须先知道 :
1.
属性只是表格的列 。
示例:每个列是一个属性.
2.
功能依赖(FD) 功能依赖描述属性之间的关系.
示例:意指: 如果两行学生ID相同,它们也必须有同名.
学生ID 决定名称 。
3.
属性关闭属性 属性关闭回答:"赋予这些属性,我还能确定哪些属性?
它帮助我们发现: 候选键 Super Keys Reredundent 依赖性属性关闭是DBMS中最重要的工具之一.
4.
候选人密钥 A 候选人密钥是能够唯一识别每行的最小的一组属性.
示例:或两者均可单独确定雇员。
可能有多个候选密钥.
功能依赖、属性关闭、候选密钥和冠盖之间的关系 这些概念相辅相成。
概念目的 功能依赖 定义商业规则 属性 关闭 确定可以推断的属性 候选人 Key 识别出独有的记录 Canonical Cover 移除不必要的依赖 规范化 生成高效的图案 把它们视为分阶段而非孤立的专题。
A Real-Life Analogy 想象一下你的经理给你这些指示:一些指示重复了同样的想法.
有些是不必要的,因为它们已经可以推断。
最终你把它们简化成最小的组合,仍然能传达一切。
没有什么重要的事情会失去。
没有增加新的内容。
简化的指令清单类似于Canonical封面。
它表达的是完全相同的信息,但不重复。
定义前的先入为主 假设有人给你50个抚养规则 其中一些:重叠相互重复含有不必要的属性可以从其他属性中推断出来.
你可以保持所有50个规则。
或者你可以只保留基本的东西。
盖子只是这些依赖性规则中最小的干净代表,没有