SQL

(从mysql入手)
先数据库，再表，再有数据

一、数据库管理

1、查询所有数据库

1	show databases

2、创建数据库

1
2
3

create database 数据库名称      --使用默认字符集

create database 数据库名称 default character set utf8

3、查看数据库的默认字符集

1	show create database 数据库名称

4、删除数据库

1	drop database 数据库名称

5、修改数据库字符集格式

1	alter database 数据库名称 default character set gbk

二、表管理

1、查看所有表

1	show tables

2、创建表

create table 表名称(
  字段名 字段类型，
  字段名 字段类型(类型长度)
  ...
)

3、查看表结构

desc 表名

4、删除表

1	drop table 表名

5、修改表

(1)、添加字段

1	alter table 表名 add column 字段名字段类型(类型长度)

(2)、删除字段

1	alter table 表名 drop column 字段名

(4)、修改字段类型

1	alter table 表名 modify column 字段名字段类型（类型长度）

(5)、修改字段名称

1	alter table 表名 change column 字段名字段类型（类型长度）

(6)、修改表名称

1	alter table 表名 rename to 新表名

6、增删改数据

以后有时间再写，干不动了。先写数据库设计的

数据库设计

键：一个属性或多个属性组合
候选键：用来唯一标识一条元组。（一个关系可以有多个）
主键：所有候选键拿出来用的键。（一个关系只能有一个）
非主属性：不包含在任何候选键里的属性。
完全依赖和非完全依赖：
例：
部分函数依赖 (学生id,课程id)->学生所在系
因为：学生id->学生所在系，而学生id是(学生id,课程id)的真子集。
部分函数依赖 (学生id,课程id)->成绩
因为：不存在(学生id,课程id)的真子集决定成绩。

一、范式

里面的例子转自：http://blog.itpub.net/12125877/viewspace-474702/

第一范式(1NF)

条件：关系R的每个属性的值域是不可分割的值。
即：要求每个字段必须是不可分割的独立单元

第二范式(2NF)

条件一：关系R是1NF
条件二：关系R的每个非主属性都完全函数依赖于候选键（这种依赖包括传递的依赖）
A->B : A决定B，B依赖A
A->B B->C : A决定C。C依赖A（B传递了C对A的依赖）
例如：

假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系： 

(学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 

这个数据库表不满足第二范式，因为存在如下决定关系： 

(课程名称) → (学分) 

(学号) → (姓名, 年龄)

即存在组合关键字中的字段决定非关键字的情况。

把选课关系表SelectCourse改为如下三个表： 

学生：Student(学号, 姓名, 年龄)； 

课程：Course(课程名称, 学分)； 

选课关系：SelectCourse(学号, 课程名称, 成绩)。

这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。

第三范式(3NF)

条件一：关系R是2NF
条件二：关系R的每个非主属性都不传递对候选键的依赖。
即：每个非主属性都完全函数依赖于某一候选键（这种依赖不包括传递的依赖）
例如：
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字”学号”，因为存在如下决定关系：

(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话) 

这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系： 

(学号) → (所在学院) → (学院地点, 学院电话) 

即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。 

它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。 

把学生关系表分为如下两个表： 

学生：(学号, 姓名, 年龄, 所在学院)； 

学院：(学院, 地点, 电话)。

这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。

BSCNF范式

条件一：关系R是1NF
条件二：关系R的每个属性都不传递对候选键的依赖。

理解：3NF说的是每个非主属性，而BCNF范式说的是每个属性。
因为主属性（主键）可以是属性的组合。所以存在以下情况：
存在关系R: (A,B)->B B->C (A,B)是关系的候选键也是主键，B传递了C对于候选键的依赖。
所以R不是BCNF。
例如：
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量) 

(管理员ID, 存储物品ID) → (仓库ID, 数量) 

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系： 

(仓库ID) → (管理员ID) 

(管理员ID) → (仓库ID)

*即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现异常。
把仓库管理关系表分解为二个关系表：

仓库管理：StorehouseManage(仓库ID, 管理员ID)； 

仓库：Storehouse(仓库ID, 存储物品ID, 数量)。

这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。

二、关系的对应联系

1、一对一联系(1:1)

一个关系的一条元组唯一对另一个关系的一条元组。

两个关系的联系实质是在看两个关系的同名属性上的值的对应联系。

两个关系通过候选键属性进行关联

2、一对多联系(1:n)

一个关系的一条元组对应另一个关系的多条元组
条件：1）两个关系有同名属性
2）一方的同名属性一定是候选键
多方的同名属性一定不是候选键（是外键）
外键：连个关系在关联时，多方的同名属性。
作用：保证两个关系的关联。

若两个关系是一对多联系时，将一方的候选键放到多方作外键

3、多对多联系(m:n)

　两个关系必然没有同名属性，且不可将一方主键加到另一方作外键。 　两个关系分别向对方是一对多。

解决多对多联系：

产生第三方联系表。

第三方表：

a)包含两个多方候选键（主键）

b)主键：包含两个多方表的主键

c)外键：两个，分别是两个多方表的主键

将一个多对多(m:n)——>两个一对多(1:n)