28,407
社区成员
发帖
与我相关
我的任务
分享新上任,先献上几篇原创文章之1--数据库范式在网站中的应用
如果把网站看成一个人，那么，数据库就象是网站所不可缺少的血液。可以说，如果ASP缺少了数据库的功能，那它的作用顶多只能发挥1/5。下面，我们就以浪漫情缘网城为例，看看ASP是怎么样利用ADO，把数据库融合到整个网站中的吧。
在了解ADO之前，我们要先了解数据库的一些基本知识，虽然比起这本书的其它部分，这一节会显得有点闷，但如果你想设计出一个优秀的WEB应用程序，这一节是必不可少的。为了让大家看这一节的时候不会闷到Zzz掉，我尽量用浅显的语言配合实例给大家讲解。
深呼吸，做好心理准备，Go……
首先，大家先看看这张表的结构：
(表1)
见http://unionbyte.com/Upload/小竹/art/A1.JPG
有很多初学数据库的朋友会把表结构定义成类似这样，也许有人会问，这样不是很好吗？一目了然，写程序的时候也容易操作。那么，我们就来看看这样会产生什么问题吧：
1． 如果要添加一个用户（假设昵称为小狗，Email为dog@19cn.com）的时候，由于小狗没有发布过文章，所以：
(A) 当文章标题不允许为空的时候，无法把小狗的记录插入到表中；
(B) 当文章标题 允许为空的时候，会产生一个除了作者和Email字段，其它都为空的记录。
这种应该插入的数据无法插入的情况，称为插入异常。
2． 如果有个用户（就假设是小竹吧）发布了1篇文章，现在要把这篇文章删除，就会产生又一个问题：删除文章的时候会把小竹的个人资料一起删掉，也就是删除文章的时候会导致用户丢失。这种情况我们称为删除异常。
3． 删除文章的时候，由于文章缺少一个唯一的标识，所以无法准确的判断要删除的是哪一篇文章。如果通过标题判断，则会误删同标题的文章，修改的时候也会出现同样的情况。
那么，怎样建表才规范呢？先让我们来学学数据库的三范式吧：
第一范式：数据库表中的字段都单属性，并且是由基本类型构成的。所谓的基本类型，就是整型、实数、字符型、逻辑型、日期型，结构类型和指针类型不能作为字段的值。
对照一下上面的表，是不是符合这个要求呢？大家一眼就可以看出，这个表是符合第一范式的。那么，如果要增加一个身高的字段，并把小竹的身高置为178－180CM，那么，对照第一范式，我们不能简单的在表中填入178－180，而是应该设置成两个字段，就叫Height_From和Height_To吧，分别填入178和180，那么，这个表就符合第一范式了。
第二范式：表结构中不存在非关键字段对关键字段的部分函数依赖。所谓部分函数依赖，是指存在组合关键字段决定（下文用→表示“决定”）非关键字段的情况。所以，所有单关键字的表结构都符合第二范式。
在分析到这一步的时候，我们发现，这个表中不存在关键字段。把标题当关键字段？当然不行！一般情况下，尽可能使用数据型字段做为关键字段。最普遍的做法是，在表中添加一个字段名（假设就叫编号吧），那么，编号就是这个表的关键字段，如下图：
(表2)
见http://unionbyte.com/Upload/小竹/art/A2.JPG
编号→标题、所以版区、文章内容、点击数、发发表时间、作者、作者Email，这样，表2的结构就符合第二范式的要求了。
第三范式：在第二范式的基础上，表结构中不存在非关键字段对关键字段的传递函数依赖。所谓传递函数依赖，就是关键字段→非关键字段1，非关键字段1→非关键字段2的情况。
研究一下表2，是否存在传递函数依赖呢？
首先，编号→作者，作者→作者Email，这就是一个传递函数依赖，怎样解决呢？把作者和作者Email单独作为一个表（假如就叫作者吧），因为作者名不会重复，所以可以作为关键字段。（如果你还记得我前面说的“尽量使用数字型字段作为关键字段”的话，你也可以在表“作者”中设置一个作者编号作为关键字，当然，在表“文章”中就要保留作者编号而不是作者名了），在表“文章”中只保留作者字段作为外键（什么叫外键？就是别的表的关键字段）。
另外，字段“所在版区”也要改一改，因为目前的结构很不灵活，如果要添加版区的相关信息（比如版区人气）的字段，就要重新建表，否则违反了第三范式的要求。所以，新建一个表叫版区信息表，包括版区编号和版区名称两个字段，而在表“文章”中，保留版区编号作为外键。
经过一番折腾，我们的表结构已经是面目全非了，看看新的表长的是什么样子的吧：
(表3：文章信息表)
见http://unionbyte.com/Upload/小竹/art/A3.JPG
(表4：版区信息表)
见http://unionbyte.com/Upload/小竹/art/A4.JPG
(表5：作者信息表)
见http://unionbyte.com/Upload/小竹/art/A5.JPG
最后，我们在这个基本上添加相关的字段，一个规范的论坛表结构就基本建立起来了。当然，如果你愿意的话，可以再参考一下BCNF范式和第四范式。但一般来说，符合第三范式的表结构在应用中已经符合一般的规范，在保证数据一致性、可扩展性和消除数据插入异常、减少数据冗余方面也有很好的表现。
在了解ADO之前，我们要先了解数据库的一些基本知识，虽然比起这本书的其它部分，这一节会显得有点闷，但如果你想设计出一个优秀的WEB应用程序，这一节是必不可少的。为了让大家看这一节的时候不会闷到Zzz掉，我尽量用浅显的语言配合实例给大家讲解。
深呼吸，做好心理准备，Go……
首先，大家先看看这张表的结构：
(表1)
见http://unionbyte.com/Upload/小竹/art/A1.JPG
有很多初学数据库的朋友会把表结构定义成类似这样，也许有人会问，这样不是很好吗？一目了然，写程序的时候也容易操作。那么，我们就来看看这样会产生什么问题吧：
1． 如果要添加一个用户（假设昵称为小狗，Email为dog@19cn.com）的时候，由于小狗没有发布过文章，所以：
(A) 当文章标题不允许为空的时候，无法把小狗的记录插入到表中；
(B) 当文章标题 允许为空的时候，会产生一个除了作者和Email字段，其它都为空的记录。
这种应该插入的数据无法插入的情况，称为插入异常。
2． 如果有个用户（就假设是小竹吧）发布了1篇文章，现在要把这篇文章删除，就会产生又一个问题：删除文章的时候会把小竹的个人资料一起删掉，也就是删除文章的时候会导致用户丢失。这种情况我们称为删除异常。
3． 删除文章的时候，由于文章缺少一个唯一的标识，所以无法准确的判断要删除的是哪一篇文章。如果通过标题判断，则会误删同标题的文章，修改的时候也会出现同样的情况。
那么，怎样建表才规范呢？先让我们来学学数据库的三范式吧：
第一范式：数据库表中的字段都单属性，并且是由基本类型构成的。所谓的基本类型，就是整型、实数、字符型、逻辑型、日期型，结构类型和指针类型不能作为字段的值。
对照一下上面的表，是不是符合这个要求呢？大家一眼就可以看出，这个表是符合第一范式的。那么，如果要增加一个身高的字段，并把小竹的身高置为178－180CM，那么，对照第一范式，我们不能简单的在表中填入178－180，而是应该设置成两个字段，就叫Height_From和Height_To吧，分别填入178和180，那么，这个表就符合第一范式了。
第二范式：表结构中不存在非关键字段对关键字段的部分函数依赖。所谓部分函数依赖，是指存在组合关键字段决定（下文用→表示“决定”）非关键字段的情况。所以，所有单关键字的表结构都符合第二范式。
在分析到这一步的时候，我们发现，这个表中不存在关键字段。把标题当关键字段？当然不行！一般情况下，尽可能使用数据型字段做为关键字段。最普遍的做法是，在表中添加一个字段名（假设就叫编号吧），那么，编号就是这个表的关键字段，如下图：
(表2)
见http://unionbyte.com/Upload/小竹/art/A2.JPG
编号→标题、所以版区、文章内容、点击数、发发表时间、作者、作者Email，这样，表2的结构就符合第二范式的要求了。
第三范式：在第二范式的基础上，表结构中不存在非关键字段对关键字段的传递函数依赖。所谓传递函数依赖，就是关键字段→非关键字段1，非关键字段1→非关键字段2的情况。
研究一下表2，是否存在传递函数依赖呢？
首先，编号→作者，作者→作者Email，这就是一个传递函数依赖，怎样解决呢？把作者和作者Email单独作为一个表（假如就叫作者吧），因为作者名不会重复，所以可以作为关键字段。（如果你还记得我前面说的“尽量使用数字型字段作为关键字段”的话，你也可以在表“作者”中设置一个作者编号作为关键字，当然，在表“文章”中就要保留作者编号而不是作者名了），在表“文章”中只保留作者字段作为外键（什么叫外键？就是别的表的关键字段）。
另外，字段“所在版区”也要改一改，因为目前的结构很不灵活，如果要添加版区的相关信息（比如版区人气）的字段，就要重新建表，否则违反了第三范式的要求。所以，新建一个表叫版区信息表，包括版区编号和版区名称两个字段，而在表“文章”中，保留版区编号作为外键。
经过一番折腾，我们的表结构已经是面目全非了，看看新的表长的是什么样子的吧：
(表3：文章信息表)
见http://unionbyte.com/Upload/小竹/art/A3.JPG
(表4：版区信息表)
见http://unionbyte.com/Upload/小竹/art/A4.JPG
(表5：作者信息表)
见http://unionbyte.com/Upload/小竹/art/A5.JPG
最后，我们在这个基本上添加相关的字段，一个规范的论坛表结构就基本建立起来了。当然，如果你愿意的话，可以再参考一下BCNF范式和第四范式。但一般来说，符合第三范式的表结构在应用中已经符合一般的规范，在保证数据一致性、可扩展性和消除数据插入异常、减少数据冗余方面也有很好的表现。
...全文
请发表友善的回复…
发表回复
