1700416050
1700416051
在这里,先记住一些数据库术语。在关系型数据库中,把录入到表中的每一行数据都称为记录,把构成一条记录中的各个数据项(在本例中是商品名称、单价等)所在的列称为字段。记录有时也被称为行或元组(Tuple),字段有时也被称为列或属性(Attribute)。上面提到的属性(数据的类型)就是设置在字段上的。为了代表字段所存储数据的内容还要为每个字段起一个名字。如图8.5所示,通过这个界面定义了构成一条记录的多个字段。之后只要在这个表中录入数据,表就可以使用了
1700416052
1700416053
1700416054
1700416055
1700416057
计算机是怎样跑起来的 8.4 通过拆表和整理数据实现规范化
1700416058
1700416059
既然表已经准备好了,那么只需要把带有用户界面并且能够读写数据的应用程序做出来,就大功告成了。可实际上却并非如此,如果就这样使用这张表,那么在数据库的运行过程有可能会产生一些问题。DBMS既然已经提供了用于手工输入数据的工具,那么我们就先试着录入几条测试数据看看(如图8.6所示)
1700416060
1700416061
图8.6 用一张表时产生的问题
1700416062
1700416063
1700416064
1700416065
1700416066
(维士忌一词的错误写法)
1700416067
1700416068
产生了两个问题。第一个问题是用户不得不多次录入相同的数据,就像第一条和第二条记录中的数据“日经次郎、东京都千代田区、03-2222-2222”。录入重复数据不仅使应用程序的操作变得繁琐,更浪费了存储空间。另一个问题是录入的名称不同指代的却是相同的商品,就像第三条记录中,应该输入“威士忌”却错误地输入了“维士忌”,如果让计算机来处理,这种情况就会被识别为不同的商品。也就是说,如果仅使用一张表,就会和应用卡片型数据库(每条记录对应一张卡片)时面临相同的问题。
1700416069
1700416070
为了解决这类问题,在设计关系型数据库时,还要进行“规范化”。所谓规范化,就是将一张大表分割成多张小表,然后再在小表之间建立关系,以此来达到整理数据库结构的目的。通过规范化,可以形成结构更加优良的数据库。DBMS提供了可视化的工具,用户仅仅通过简单的操作就可以进行规范化(如图8.7所示)
1700416071
1700416072
图8.7 经过规范化处理的酒铺数据库
1700416073
1700416074
1700416075
1700416076
1700416077
规范化的要点是在一个数据库中要避免重复存储相同的数据。因此在本例中,把酒铺的数据分为“商品表”、“顾客表”和“销售记录表”三张表,然后再在它们之间建立关系(用被细线连接起来的短杠表示)。通过这样的处理,既省去了多次重复录入相同的顾客姓名、住址、电话号码的麻烦,又能防止把相同的商品名称输入成不同名称的错误。如图8.8所示,酒铺的数据被分别存储到了三张表中。表格的最后一行只是表示在这里可以输入下一条记录,并非实际存在着这样一条记录
1700416078
1700416079
图8.8 将数据分别存储到三张表中
1700416080
1700416081
1700416082
1700416083
1700416084
1700416085
1700416086
1700416088
计算机是怎样跑起来的 8.5 用主键和外键在表间建立关系
1700416089
1700416090
为了在表间建立关系,就必须加入能够反映表与表之间关系的字段,为此所添加的新字段就称为键(key)。首先要在各个表中添加一个名为主键(primary key)的字段,该字段的值能够唯一地标识表中的一条记录(如图8.9所示)。
1700416091
1700416092
图8.9 把字段设置为主键
1700416093
1700416094
1700416095
1700416096
1700416097
在顾客表中添加的“顾客ID“字段、销售记录表中添加的“销售记录ID”字段以及在商品表中添加的“商品ID”字段都是主键
1700416098
1700416099
正如“顾客ID“一样,通常将主键命名为“某某ID”这是因为主键存储的是能够唯一标识一条记录的ID(Identification,识别码)。如图8.8所示,如果顾客表中顾客ID是1的话,就能确定是日经次郎这条记录;顾客ID是话,就能确定是矢泽三郎这条记录。正因为这种特性,在主键上绝不能存储相同的值。如果试图录入 在主键上含有相同值的记录,DBMS就会产生一条错误通知,这就是DBMS所具备的一种一致并且安全地存储数据的机制
[
上一页 ]
[ :1.70041605e+09 ]
[
下一页 ]