数据库表设计的原则攻略
一、数据实体
什么是实体,客观存在并且可以相互区别的事物称为实体。这里我们就简单的把它理解为一个表吧,描述实体的特性,我们就把他们称为了属性。也可以说当我们把一个数据库表当作一个实体,那么它里面的所有字段是不是就是一个属性了呢?结果是肯定的。
二、实体间的联系
我想说的是,很简单,数据库里表跟表间的关系莫过于三种:一对一;多对多;一对多。
一对一其实就是说我们建的主表跟相关联的表之间是一一对应的,比如说,我建了一个学生基本信息表:t_student,然后我又建了一个成绩表,里面有个外键,studentID,学生基本信息表里的字段studentID和成绩表里的studentID就是一对一。
一对多,也是类似,我另外建一个班级表,而每个班级有多个学生,每个学生就对应一个班级,对班级来说当然就是一对多了。
多对多,我还举这个例子,我建个选课表,可能有许多科目,每个科目有很多学生选,而每个学生又可以选择多个科目。这就是多对多了。
三、基本表的完整性
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据(基础数据)的记录。
(3) 演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。
这是基本表的完整性,也是它特有的。这里我想说的是,在数据库里还有几种表也是常用的那就是中间表和临时表。
1、中间表
中间表是针对多对多关系的,就比如做公交查询系统。里面有两个表,分别是车站表、线路表。这里我们起个名字叫:t_busstation 、t_road,根据常识我们也知道,一个站有多个线路经过,而每个线路又有多个车站,怎么才能将两个表联系起来呢,如果是一对一,一对多,我们一个表,两个表就可以将他们实现了,但是多对多呢,这样我们就必须借助中间表用来连接两个表。一般中间表都是有一个本表的自增主键,还有另外两个表的主键。中间表是没有属性的因为它不是一个基本表。
2、临时表
在本次项目中,我们就要用到临时表,首先来看看什么是临时表吧。这是我从网上书上查到的。因为我们用的是MS SQL Server 2000数据库,而在这个数据库里是支持临时表的。
临时表:其实就是那些以#号开头为名字的数据表,它主要是用来存放临时数据的,当用户断开连接但没有出去临时表里的数据时,系统会自动把临时表里的数据清空。这里要说一点,临时表是放在系统数据库 tempdb中的,而不是当前数据库。
临时表总共是分两种:本地临时表和全局临时表。
(1)这里我们需要了解的就是,在数据库中本地临时表是以一个#开头的,这种临时表只对当前的数据库用户可见,而其他的用户是不可见的。当数据库实例断开后当然也就丢失了数据了,不管是显式清空还是系统回收。
(2)还有一个就是全局临时表。它是以“##”开头的,而且是对于所有的用户都是可见的,当你断开数据库实例连接时,只要还有别的系统项目在引用它,连着数据库,那么数据就存在,只有当别的系统也断开连接时,系统才会清除全局临时表的数据。
下面是建立临时表的语句:
本地临时表:
create table
#student
(
studentID
int ,
studentName nvarchar
(40),
classID
int
)
全局临时表:
create table
##student
(
studentID
int ,
studentName nvarchar
(40).
classID
int
)
这里我们也可以用SQL语句完成:
select * from employee into #student
现在就来看看三大范式。
第一范式:如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.比如一个工人的基本信息表,里面有工人的工号,性别,年龄,这些属性都是不可分割的,所以这个表就符合了第一范式。
第二范式: 就是在第一范式的基础上延伸,使之表里的每个字段都与主键发生关系。假如一个关系满足第一范式,并且除了主键以外的其它字段,都依赖于该主键,则满足第二范式.
例如:订单表(订单编号、产品编号、定购日期、价格、……),"订单编号"为主键,"产品编号"和主键列没有直接的关系,即"产品编号"列不依赖于主键列,这个列我们就可以把它删除。
第三范式:在第二范式的基础上更进一步,也就是为了实现表里的列都与主键列直接相关,不是间接相关。这个我们可以用“Armstrong 公理”中的传递规则来推理。
我们来看一下它的定义:
设U是关系模式R 的属性集,F 是R 上成立的只涉及U 中属性的函数依赖集。若X→Y 和 Y→Z在R 上成立,则X →Z 在R 上成立。因此我们就来看在网上搜索到的例子:例如:订单表(订单编号,定购日期,顾客编号,顾客姓名,……),初看该表没有问题,满足第二范式,每列都和主键列"订单编号"相关,再细看你会发现"顾客姓名"和"顾客编号"相关,"顾客编号"和"订单编号"又相关,最后经过传递依赖,"顾客姓名"也和"订单编号"相关。为了满足第三范式,应去掉"顾客姓名"列,放入客户表中。
这里其实就是为了说明数据库的表里步要出现冗余,在顾客表里已经有了"顾客姓名"了,而在订单表里就别出现了,而直接根据顾客编号相关联就可以,否则造成资源浪费。
以上就是三大范式。
延伸:我们来看这三大范式:
第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解;
第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性;
第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没
有冗余。
其实在设计数据库的时候我们最多的要遵循的就是第三范式,但是并不是越满足第三范式数据库就设计的越完美,这种错误是错误的。有时候增加点冗余相反的会提高访问速率,因此在实际的设计过程中应降低对范式的要求。
以前对数据冗余并不是很了解,在百度知道里的定义是这样的:在一个数据集合中重复的数据称为数据冗余.
但是不是说我们表的主键在其他表里重复出现就是冗余,这不是,而是为了连接两个表。只有非键字段就是既不是主键外键等约束的键如果重复出现,就会形成数据冗余。数据冗余也包括重复性冗余和派生冗余。比如工人表里有"基本工资","奖金"两列,然后还有一个"总工资"的列,这个总工资就是派生冗余。低级的重复性冗余一定要避免,杜绝,但是像派生冗余还是提倡的因为它能提高访问的效率。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。