"主键"是什么?

lodge

哈, 终于看到关于数据库基础概念的讨论了.
关于主键和UNIQUE INDEX+NOT NULL字段的区别主要在于, 它们是不是主键, 呵, 听起来好象是脑筋急转弯, 原则上主键是不允许被更新的, 因为它是一个标识, 更新它就相当于删除一行再追加一行了, 当然这是一个概念化的说法, 实际的数据库基本上不限制更新主键, 但由于概念上的含糊更新主键的操作通常是比较复杂的.

"部分主键"这个词用得不太准确, 不好意思, (偶不太知道中文对一些术语的翻译), 但偶的意思不是候补主键, 而是说, 有部分字段可以确定另外一部分字段, 比如, 有这样一组数据
学号(PK),班级, 年级,  姓名
其中, 年级可以只通过班级来确定, 这种情况下班级就是偶说的"部分主键"了, 这样一个表只能达到第一范式的要求(有点忘记了, 也可能能到第二范式, 但肯定到不了第三范式), 这种冗余通常是要避免的, 因为它可能造成同样一个班却在不同的年级这样的矛盾, 或者叫数据不整合(好象是个日文词 )

当然, 要绝对避免冗余也是没有必要的, 如, magicangel所说冗余也有很多巧妙的运用.

从广意上说文档也可称做数据库的一种, 但偶还是有点不敢苟同, 存储数据的方式和数据库的概念应该是不同的, 单就查询这一个词来讲, 在数据库中叫QUERY而对文档来说叫INFORMATION RETREIVAL, 结构化数据和非结构化数据有着天壤之别, 在处理功能上二者应该没有可比性.
上文说到的二者结合, 确实有很多应用, 比较流行的做法是利用某种对文档内容的描述信息(如, 题目, 关键字, 摘要, 等等, 被叫做META-DATA)做成数据库, 利用对数据库的检索来提高文档检索的效率和准确性. 这种方法被GOOGLE等门户站广泛采用, 使用的META-DATA也五花八门, 如偶曾经给一门户网站设计过通过网页上的链接数来判断网页内容的相关性这样的算法, 偶现在也在考虑利用回复中的引用信息, 还有表情符号来做META-DATA的方法, 没准能用到PUB上来提高贴子的检索效率呢.

ccwlm741212

"部分主键" 叫“外键”

数据库基础概念的讨论我们会在2004年1月开始的课程中介绍和引导讨论,希望能看见你

server

谢谢大家，我想我明白了！

谢谢！

zhouyingbi

用帮助，她是最好的老师和助手

magicangel

最初由 lodge 发布
[B]"部分主键"这个词用得不太准确, 不好意思, (偶不太知道中文对一些术语的翻译), 但偶的意思不是候补主键, 而是说, 有部分字段可以确定另外一部分字段, 比如, 有这样一组数据
学号(PK),班级, 年级,  姓名
其中, 年级可以只通过班级来确定, 这种情况下班级就是偶说的"部分主键"了, 这样一个表只能达到第一范式的要求(有点忘记了, 也可能能到第二范式, 但肯定到不了第三范式), 这种冗余通常是要避免的, 因为它可能造成同样一个班却在不同的年级这样的矛盾, 或者叫数据不整合(好象是个日文词 )
[/B]

你上面的说明，我还是不太明白，小弟愚笨。

对于
学号(PK),班级, 年级,  姓名

只能达到1NF，存在依赖关系。可以这样：

s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级,系名) --当然这个表的设计也存在不完全依赖，但数据量应该不多，不常用到，就给出个意思

中文的说法，应该是叫数据的完整性吧，实际是一种约束规则，请指正。

你说的“同样一个班却在不同的年级这样的矛盾”，我不明白，能不能解释一下？

最初由 lodge 发布当然, 要绝对避免冗余也是没有必要的, 如, magicangel所说冗余也有很多巧妙的运用. [/B]

一般情况下，冗余是要避免的，范式的出现也是基于这个目的了。印象很深刻，前苏联的一次航天飞行出事，在半空中爆炸，就是有几行冗余代码的存在。

当然，任何事物都是有两面性的。为了一些特殊的需要，我们有时候会故意冗余。

magicangel

最初由 ccwlm741212 发布
[B]

lodge兄的意思是unique和not null一起的字段，还是要分开比较，否则区别就太明显了 [/B]

明白了

jackyzhung

能不能解釋下CODD博士的"关系数据库的理论模型的12条规则 "

lodge

最初由 magicangel 发布
[B]

你上面的说明，我还是不太明白，小弟愚笨。

对于
学号(PK),班级, 年级,  姓名

只能达到1NF，存在依赖关系。可以这样：

s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级,系名) --当然这个表的设计也存在不完全依赖，但数据量应该不多，不常用到，就给出个意思

中文的说法，应该是叫数据的完整性吧，实际是一种约束规则，请指正。

你说的“同样一个班却在不同的年级这样的矛盾”，我不明白，能不能解释一下？

[/B]

恩, 这里所说的是指逻辑上的数据完整性, 比如, 下面的例子
学号(PK),班级, 年级,  姓名
001        01     2      LODGE
002        01     1      SUSAN
在这个表里, 班级为01的记录中, 年级却有两个2年级和1年级, 这就是冗余代来的问题了, 尽管可以通过对输入的控制来避免这样的情况, 但由于逻辑上的问题往往使处理程序很复杂, 又很容易造成BUG, 比如由于某种疏忽而出现上述情况,而使用这些数据的处理, 就极有可能出现错误,.
那么, 怎样避免呢, 观察上面几个字段, 就不难发现年级对班级有依赖性, 换句话说, 只需知道班级就能知道年级了, 所以可以把表拆成这个样子
S(学号(PK),班级(FK), 姓名)
C(班级(PK),年级)
这样逻辑上就清晰了, 因为没了冗余, 对输入的控制就简单了, 因为, 如果有疏忽, 就会引起错误, 而一旦写到表里, 这样的数据就肯定是完整的, 从而避免了很多后期处理上出现BUG的可能性

现在来看看 上面的设计, 在这里偶要利用这个机会来说明一下, 数据库的设计思路.
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级,系名)
偶猜想编号是对班级的编号, 所以这个结构和上面的结构是一致的
但是, 问题在于这个结构中比已知条件多了两个字段, 编号和系名
这样很容易引起新的问题, 比如编号作为主键它的值如何确定的问题(这很重要, 如果处理不当就会发生逻辑上的错误). 在初期设计中, 应当特别注意这些问题, 不要任意追加实际上不存在的字段, 这样才能保证设计的严密性, 当然, 在处理中使用数字类型来保证处理的效率等问题是要考虑的, 不过这应该放在后面, 等到系统的基本逻辑完全确定了, 再做调整. 这样一个过程, 就是从物理设计到逻辑设计的过程,
在这里所谓物理设计, 就是完全按照实际的情况, 做出的数据库结构设计和处理逻辑设计. 在这一阶段完全不需要考虑, 和数据库库应用有关的问题, 是纯粹的现实的反映. 这一阶段的原则是, 原原本本反映出现实的情况, 特别是要明确界定系统和用户之间的分界点.

而所谓逻辑设计, 就是要把上面抽象好的物理设计进行优化, 作出高效益的数据库结构和系统处理流程, 并追加必要的逻辑字段如上面的编号和这些字段处理方法, 这时候的原则是, 完全反映物理逻辑并保持物理设计中已经确定的用户界面
就上面这个简单的例子来说
在物理设计的时候, 偶们确定好了这样的结构
S(学号(PK),班级(FK), 姓名)
C(班级(PK),年级)
这就意味着, 用户只需知道
学号,班级, 姓名,年级
就能使用偶们的系统
而在逻辑设计阶段, 偶们注意到, 实际上用户对班级名称有很多种不同的叫法, 直接作主键计算机处理起来比较难
因此, 设计出这样的结构
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级)
但是这样用户在输入数据的时候, 就必须要明白班级编号的意思, 这不符合偶们所设计的物理界面的要求, 所以要再改进
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级)
d(班级(PK), 编号)
偶们增加了表d这是一个字典, 它的作用是可以让用户输入班级名而系统可以找到对应的编号, 请注意, 在d中的编号不是外键, 因为它和偶们的主处理逻辑没有直接关系, 它只是个辅助表, 另外, c中保留了班级字段, 但这不是冗余, 这个班级和d的班级是两个概念, 前者是班级的表示名称, 而后者是班级的输入名称
最后, 要说明的是, 偶们的最终设计, 仍然犯了个错误, 这就是, 偶们增加了一个新物理流程-字典编辑, 这时候, 偶们需要和用户共同讨论, 看看他们是否真得愿意这么使用, 而通常的结果会是,
他们不打算用这个字典, 他们完全能够使用标准输入名称, 于是偶们的字典里就只能保存一个名称了, 显然然偶们可以去掉这个表, 但用户的保证是不可信的, 偶们不能允许在他们犯错误的情况下, 而使得系统可能保存错误的结果, 于是偶们再行调整偶们的设计方案
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级(NOT NULL UNIQUE), 年级)
这个最终方案是这个意思, 因为偶们不信任用户, 所以偶们仍然不能使用班级作为主键, 这样即使用户输入有误也不会增加错误的记录, 根据物理逻辑的要求, 偶们把班级作为候补主键, 使它不能为空而且不能重复, 这样就基本上满足要求了, 显然编号成为了内部逻辑字段, 它可以完全由偶们的系统自行决定

omencathay

最初由 lodge 发布
[B]呵呵, 偶也问个问题: 什么是关系型数据库? [/B]

丈夫和老婆，老婆生孩子

magicangel

最初由 lodge 发布
[B]

恩, 这里所说的是指逻辑上的数据完整性, 比如, 下面的例子
学号(PK),班级, 年级,  姓名
001        01     2      LODGE
002        01     1      SUSAN
在这个表里, 班级为01的记录中, 年级却有两个2年级和1年级, 这就是冗余代来的问题了, 尽管可以通过对输入的控制来避免这样的情况, 但由于逻辑上的问题往往使处理程序很复杂, 又很容易造成BUG, 比如由于某种疏忽而出现上述情况,而使用这些数据的处理, 就极有可能出现错误,.
那么, 怎样避免呢, 观察上面几个字段, 就不难发现年级对班级有依赖性, 换句话说, 只需知道班级就能知道年级了, 所以可以把表拆成这个样子
S(学号(PK),班级(FK), 姓名)
C(班级(PK),年级)
这样逻辑上就清晰了, 因为没了冗余, 对输入的控制就简单了, 因为, 如果有疏忽, 就会引起错误, 而一旦写到表里, 这样的数据就肯定是完整的, 从而避免了很多后期处理上出现BUG的可能性

现在来看看 上面的设计, 在这里偶要利用这个机会来说明一下, 数据库的设计思路.
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级,系名)
偶猜想编号是对班级的编号, 所以这个结构和上面的结构是一致的
但是, 问题在于这个结构中比已知条件多了两个字段, 编号和系名
这样很容易引起新的问题, 比如编号作为主键它的值如何确定的问题(这很重要, 如果处理不当就会发生逻辑上的错误). 在初期设计中, 应当特别注意这些问题, 不要任意追加实际上不存在的字段, 这样才能保证设计的严密性, 当然, 在处理中使用数字类型来保证处理的效率等问题是要考虑的, 不过这应该放在后面, 等到系统的基本逻辑完全确定了, 再做调整. 这样一个过程, 就是从物理设计到逻辑设计的过程,
在这里所谓物理设计, 就是完全按照实际的情况, 做出的数据库结构设计和处理逻辑设计. 在这一阶段完全不需要考虑, 和数据库库应用有关的问题, 是纯粹的现实的反映. 这一阶段的原则是, 原原本本反映出现实的情况, 特别是要明确界定系统和用户之间的分界点.

而所谓逻辑设计, 就是要把上面抽象好的物理设计进行优化, 作出高效益的数据库结构和系统处理流程, 并追加必要的逻辑字段如上面的编号和这些字段处理方法, 这时候的原则是, 完全反映物理逻辑并保持物理设计中已经确定的用户界面
就上面这个简单的例子来说
在物理设计的时候, 偶们确定好了这样的结构
S(学号(PK),班级(FK), 姓名)
C(班级(PK),年级)
这就意味着, 用户只需知道
学号,班级, 姓名,年级
就能使用偶们的系统
而在逻辑设计阶段, 偶们注意到, 实际上用户对班级名称有很多种不同的叫法, 直接作主键计算机处理起来比较难
因此, 设计出这样的结构
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级)
但是这样用户在输入数据的时候, 就必须要明白班级编号的意思, 这不符合偶们所设计的物理界面的要求, 所以要再改进
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级, 年级)
d(班级(PK), 编号)
偶们增加了表d这是一个字典, 它的作用是可以让用户输入班级名而系统可以找到对应的编号, 请注意, 在d中的编号不是外键, 因为它和偶们的主处理逻辑没有直接关系, 它只是个辅助表, 另外, c中保留了班级字段, 但这不是冗余, 这个班级和d的班级是两个概念, 前者是班级的表示名称, 而后者是班级的输入名称
最后, 要说明的是, 偶们的最终设计, 仍然犯了个错误, 这就是, 偶们增加了一个新物理流程-字典编辑, 这时候, 偶们需要和用户共同讨论, 看看他们是否真得愿意这么使用, 而通常的结果会是,
他们不打算用这个字典, 他们完全能够使用标准输入名称, 于是偶们的字典里就只能保存一个名称了, 显然然偶们可以去掉这个表, 但用户的保证是不可信的, 偶们不能允许在他们犯错误的情况下, 而使得系统可能保存错误的结果, 于是偶们再行调整偶们的设计方案
s(学号(PK),姓名,编号(FK))
c(编号(PK),班级(NOT NULL UNIQUE), 年级)
这个最终方案是这个意思, 因为偶们不信任用户, 所以偶们仍然不能使用班级作为主键, 这样即使用户输入有误也不会增加错误的记录, 根据物理逻辑的要求, 偶们把班级作为候补主键, 使它不能为空而且不能重复, 这样就基本上满足要求了, 显然编号成为了内部逻辑字段, 它可以完全由偶们的系统自行决定 [/B]

lodge兄分析的透彻。看来ccw一月份的开课离不开你的帮助。

有时候对于数据库的概念设计跟用户存在差异，我们常用视图(view)来解决。