数据库基础---数据库系统概论个人总结版

-----------------------------------------------------------------共复习使用，参考王珊萨师煊版-----------------------------------------------------------------------

一：基本知识

1，表的创建：

建立一个“学生选课”表SC，它由学号Sno、课程号Cno，修课成绩Grade课程名Cname组成，其中(Sno, Cno)为主码。

CREATE TABLE
SC(
         SnoCHAR(7),
         CnoCHAR(4),
         Gradeint,
         CnameCHAR(10), NOT NULL UNIQUE
         Primarykey (Sno,Cno)
         Foreignkey (Sno) References student(Sno).
         Foreignkey (Cno) References Course (Cno)
);

基本表的创建-说明

1、建表的同时可以定义与该表有关的完整性约束,这些约束条件被存入系统的数据字典中,当用户操作表时,DBMS会自动检查该操作是否有违背完整约束条件.

2、建立约束的考虑：如果完整性约束条件涉及到该表的多个属性列，则必须定义在表级上；否则既可以定义在列级上也可以定义在表级上。

3、表名、列名是不区分大小写的。

4、对一个用户而言，表名必须唯一；一个表中，列名必须唯一。

5、表名、列名必须以字母开头，长度不超过30个字符。

常用完整性约束

1、主码约束：    PRIMARY KEY

2、唯一性约束：UNIQUE

3、非空值约束：NOTNULL

4、参照完整性约束：FOREIGNKEY

常用数据类型：（不同DBMS数据类型不完全相同）

T-SQL数据类型：（SQL 程式设计语言的增强版，它是用来让应用程式与SQL Server 沟通的主要语言。T-SQL提供标准 SQL的DDL 和 DML 功能，加上延伸的函数、系统预存程序以及程式设计结构(例如 IF 和 WHILE)让程式设计更有弹性。）

2，删除基本表：

DROP TABLE table_name

3，修改基本表——添加列：

ALTER TABLE table_name
ADD new_column_name datatype
[constraints]

例：向Student表增加“入学时间”（SCome），数据类型为日期型。

ALTER TABLE student
ADD Scome DATE

4，修改基本表——改变列的数据类型：

ALTER TABLE table_name
ALTER COLUMN column_name new_datatype

例：将年龄的数据类型改为半字长整数。

ALTER TABLE Student
ALTER COLUMN Sage SMALLINT

5，修改基本表——删除完整性约束

ALTER TABLE table_name
DROP constraint

例：删除学生姓名必须取唯一值的约束。

ALTER TABLE student
DROP unique(sname)

6，建立索引：

CREATE INDEX index_name ON table_name(column_name)

7，将某个字段设为主键：

ALTER TABLE table_name ADD PRIMARY KEY(column_name)

8，将某个字段的主键定义取消：

ALTER TABLE table_name DROP PRIMARY KEY(column_name)

约束是为了数据的完整性而存在的，而数据的完整性是指数据的可靠性和准确性。

根据数据完整性大致可以分为四种：

1.实体完整性

就是说每个表代表一个实体，每个表与他所代表的实体一致，特定表的唯一实体。

    实现实体完整性的的方法：索引(index)，唯一约束（unique），主键约束(primarykey)，标识列属性

2.域完整性

给每个列定义输入的有效性

实现域完整性的的方法： 限制数据类型，格式，外键约束（foreign key references），检查约束(check(  between  and ))，默认值定义(default ' ')，非空(not null)约束。

3.引用完整性 

在输入或删除记录时，表与表之间已定义的关系

实现域完整性的的方法： 通过外键与主键的关系，外键与唯一键之间的关系，外键与检查约束

4.用户自定义完整性

所有的完整性都支持用户自定义完整性

注意：

1.在SQL中有个自动增长的自动编号列identity

2. mySQL不支持检查约束

3.索引就像字典的目录，把索引加在频繁的以某个字符段查询的的上面，在表上创建索引虽然会提高select语句的速度，但也会降低delete,update,insert语句执行的速度，如果一个表中太多的索引会降低数据库的整体性能

4.primary key = unique+not null(加primary key 要比加unique和not null效率膏，因为加primarykey时会自动加索引，加快了效率)

5.在SQL server中正在实用的数据库不能被删除（除非切换数据库才能被删除），mySQl中可以删除正在实用的数据库

SELECT Sno AS NO1234,Sname FROM student;
SELECT * FROM student;
SELECT Sname,'Age',2015-Sage FROM student;
SELECT DISTINCT Sno FROM SC; 
SELECT Sno,Sname FROM student WHERE Sno = '200215121'; 
SELECT * FROM student WHERE Sage<20; 
SELECT * FROM student WHERE Sage BETWEEN 20 AND 23; 
SELECT * FROM student WHERE Sage NOT BETWEEN 20 AND 23;
SELECT * FROM student WHERE Sdept IN ('CS');
SELECT * FROM student WHERE Sno LIKE '20021512_';
SELECT * FROM student WHERE Sno LIKE '20021512%';
SELECT * FROM student WHERE Sname NOT LIKE '李%'; 
SELECT * FROM student WHERE Sname NOT LIKE '李%' AND Sage = 19; 
SELECT * FROM student ORDER BY Sage ASC,Sno DESC;
SELECT * FROM student ORDER BY Sage DESC;
SELECT COUNT(*) FROM student;
SELECT COUNT(DISTINCT Sage) FROM student;
SELECT AVG(Grade) FROM SC WHERE Cno='1';
SELECT Cno,COUNT(Sno) FROM SC GROUP BY Cno; 
SELECT student.*,SC.* FROM student,SC WHERE student.Sno=SC.Sno;

INSERT INTO SC (Sno,Cno,Grade)VALUES('200215130','5','86');

UPDATE student SET Sage = '22' WHERE Sno = '200215121';

DELETE FROM SC WHERE  Sno = '200215130';

DELETE FROM SC;
 

二：范式

http://blog.csdn.net/m13666368773/article/details/8102074

其实就是设计数据库的基本规则。

第一范式

存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B

第一范式

定义：如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的

那么符合第一模式的特点就有

1)有主关键字

2)主键不能为空，

3)主键不能重复,

4)字段不可以再分

例如：

 StudyNo   |   Name   |   Sex   |   Contact

20040901      john         Male      Email:[email protected],phone:222456

20040901      mary         famale    email:[email protected] phone:123455

以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分

所以变更为正确的是

 StudyNo   |   Name   |   Sex   |      Email         |      Phone

20040901      john         Male       [email protected]       222456

20040902     mary          famale      [email protected]      123455

 

第二范式

存在非主属性对码的传递性依赖 R(A,B,C) A是码 A -->B ,B-->C

定义：如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。

所以第二范式的主要任务就是

满足第一范式的前提下，消除部分函数依赖。

StudyNo   |   Name   |   Sex   |         Email         |      Phone    |   ClassNo  | ClassAddress

01                  john        Male       [email protected]     222456      200401            A楼2

01                   mary       famale    [email protected]       123455      200402            A楼3

这个表完全满足于第一范式,

主键由StudyNo和ClassNo组成，这样才能定位到指定行

但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),

所以要变为两个表

表一

StudyNo   |   Name   |   Sex   |      Email         |      Phone |   ClassNo

      01            john         Male       [email protected]  222456   200401     

      01           mary         famale    [email protected]    123455      200402    

表二

 ClassNo  | ClassAddress

 200401      A楼2

 200402      A楼3

第三范式

不存在非主属性对码的传递性依赖以及部分性依赖 ，
StudyNo   |   Name   |   Sex   |      Email         |      bounsLevel   |   bouns

20040901      john         Male       [email protected]   优秀                    $1000

20040902     mary         famale    [email protected]       良                         $600

这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖

更改为：

StudyNo   |   Name   |   Sex   |      Email         |      bouunsNo

20040901      john         Male       [email protected]   1

20040902     mary         famale    [email protected]       2

bounsNo   |   bounsLevel   |   bouns

1                   优秀                $1000

 2                 良                   $600

这里我比较喜欢用bounsNo作为主键，

基于两个原因

1）不要用字符作为主键。可能有人说：如果我的等级一开始就用数值就代替呢？

2）但是如果等级名称更改了，不叫 1，2 ，3或优、良，这样就可以方便更改，所以我一般优先使用与业务无关的字段作为关键字。

 

一般满足前三个范式就可以避免数据冗余。

三：数据库设计三大范式（转载）

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

                 

在实际开发中最为常见的设计范式有三个：

1．第一范式(确保每列保持原子性)

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。

上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。

                

2．第二范式(确保表中的每列都和主键相关)

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

 订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

                 

3．第三范式(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。