数据库知识点总结
2017-08-16 11:00
281 查看
1.delete 语句删除表中数据后,,删除操作是逻辑上删除,数据所占空间还在,以便回滚操作。
truncate删除数据是物理上删除,删除后会立即释放空间,不能恢复。
2. 数据库中,任何写操作都必须记录日志。因此,当日志满了,就只能执行查询操作等读操作,,不能执行更改、备份等等写操作。
3. union---》进行表的合并操作,union会删除重复元素。(速度较慢)
union all----》进行表合并操作,直接返回。不会删除重复元素 (速度较快)
4. 视图 是一个虚表。。 数据库中存放的只是视图的定义, 视图的数据项仍然在原来的基本表中。
使用视图,用户可以将注意力集中在关心的数据上而不是全部数据。 视图不能提高查询效率,因为数据都是在原来的基本表中,不在视图中。
创建视图
create view <视图名> (列名1,……,列名n)
as <子查询> //子查询可以是任意复杂的select 语句,但通常不包含order by 和 distinct 短语。
[ with check option ] //对视图进行update 、insert、delete操作的行 要保证满足子查询中的条件表达式。
删除视图 drop view <视图名> [ cascade级联删除 ]
查询视图 语法同基本表查询
更新视图 语法同基本表查询
5.触发器是一个特殊的存储过程,有事件触发,不能由程序调用或者手工启动。
6. 模式(schema) 是用于 在一个 大项目中 区分 各个小项目。每个小项目的表, 放在各自的模式(schema) 下面。这样, 遇到小项目里面有相同名字的表的话, 不会发生冲突。
例如一个公司的系统。里面分2个子系统, 分别为 财务系统 和人力资源系统。这2个子系统, 共用一个数据库。那么财务系统的表, 可以放在财务的模式(schema)。人力资源系统的表,放在 人力资源系统的模式里面。这2个子系统,能够互相访问对方的表,但是又不因为表重名的问题,影响对方。
没有指明的话,默认是使用dbo模式。
7.
(1). 创建模式 create schema <模式名> authorization <用户名>
删除模式drop schema <模式名> <cascade | restrict> (cascade级联,restrict限制)
(2) 创建表 create table <表名> (列名1 数据类型 列级约束条件 , 列名2……, 列名3…… , 表级约束条件)
删除表 drop table <表名> [cascade | restrict ]
修改表 alter table <表名> [ add列名 数据类型 约束条件 ] 或者[ drop 完整性约束名 ] 或者 [ alter column 列名 数据类型 ]
8.索引
创建索引 create [ unique | cluster ] index <索引名> on <表名> (列名1 [ asc | desc ] ),……,列名n [ asc|desc ])
默认是asc即升序, unique 代表一个索引只对应一个值; cluster 代表索引顺序与物理顺序一致
删除索引 drop index <索引名>
索引能加快查询速度。
在基本表上建立一个或多个索引,以加快查找速度。
索引已经建立,就由系统使用和维护它,不需要用户干预。索引一般采用B+树、hash索引来实现。
当表中有大量记录时,若要对表进行查询,第一种搜索信息方式是全表搜索,是将所有记录一一取出,和查询条件进行一一对比,然后返回满足条件的记录,这样做会消耗大量数据库系统时间,并造成大量磁盘I/O操作;第二种就是在表中建立索引,然后在索引中找到符合查询条件的索引值,最后通过保存在索引中的ROWID(相当于页码)快速找到表中对应的记录。
设置索引要付出代价的:一是增加了数据库的存储空间,二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
9. 数据查询
select [ all | distinct ] <目标表达式1> ,....... <目标表达式n> // distinct用于消除重复元素
from <表名或视图名1>,……,<表名或视图名n>
where <条件表达式>// 若两个或多个表中有相同的列,此处应写 表名.列名 来进行区分
[group by <列名1> having <条件表达式 >] //将查询结果 按某一列或多列的值分组,值相等的为一组。
[order by <列名2> asc | desc ]
注:
(1)目标表达式,常见为 表的列名, 还可以是表达式(算数表达式,字符串常量、函数(count、max、min、avg这些函数可以使用all或者distinct 指定统计范围)等等),此外还可以指定别名来改变查询结果的列标题。
比如 select name newName或者as newName from table1 ;
(2) 条件表达式 , 有大小比较运算符,> < = >= <= != <> !> !<
有确定范围 between and , not between and
确定集合 in , not in
字符匹配
%代表任意长度字符串
_单个字符(注意汉语腰斩两个字符,因此要有两个_ _ )
涉及空值
c642
的查询 is null ,is not null
多重条件 and or not
10.
插入数据 insert into <表名> (列名1,……,列名n) values (常量1,……,常量n)
更新数据 update <表名> set <列名1> = <表达式1>,……,<列名n> = <表达式n> [ where <条件> ]
删除数据
delete from <表名> [ where <条件> ]
11.
12.
13. 范式
◆ 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。
考虑这样一个表:【联系人】(姓名,性别,电话)
如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。
◆ 第二范式(2NF):首先是 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。
考虑一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。
因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合
2NF。不符合 2NF 的设计容易产生冗余数据。
可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)来消除原订单表中UnitPrice,ProductName多次重复的情况。
总结:如果 主键的列 大于等于1个,那么其他的列,要依赖于所有的主键列。不能只依赖于部分的主键列。
◆ 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。
考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。
其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合
3NF。
通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。
第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。
BCNF范式排除了任何属性(不光是非主属性,2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。
14. DTS 在SQL中也叫数据转换服务
SQLServer《-----》 excel、Access、其他数据库
15. MySQL存储引擎;
使用命令 : show engines;
MySQL主要有四种(还有其他)存储引擎: InnoDB、MyISAM
、 memory、merge
MyISAM
:它不支持事务,也不支持外键,尤其是访问速度快,对事务完整性没有要求或者以SELECT、INSERT为主的应用基本都可以使用这个引擎来创建表。
InnoDB存储引擎支持事务处理功能,提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM的存储引擎,InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。
truncate删除数据是物理上删除,删除后会立即释放空间,不能恢复。
2. 数据库中,任何写操作都必须记录日志。因此,当日志满了,就只能执行查询操作等读操作,,不能执行更改、备份等等写操作。
3. union---》进行表的合并操作,union会删除重复元素。(速度较慢)
union all----》进行表合并操作,直接返回。不会删除重复元素 (速度较快)
4. 视图 是一个虚表。。 数据库中存放的只是视图的定义, 视图的数据项仍然在原来的基本表中。
使用视图,用户可以将注意力集中在关心的数据上而不是全部数据。 视图不能提高查询效率,因为数据都是在原来的基本表中,不在视图中。
创建视图
create view <视图名> (列名1,……,列名n)
as <子查询> //子查询可以是任意复杂的select 语句,但通常不包含order by 和 distinct 短语。
[ with check option ] //对视图进行update 、insert、delete操作的行 要保证满足子查询中的条件表达式。
删除视图 drop view <视图名> [ cascade级联删除 ]
查询视图 语法同基本表查询
更新视图 语法同基本表查询
5.触发器是一个特殊的存储过程,有事件触发,不能由程序调用或者手工启动。
6. 模式(schema) 是用于 在一个 大项目中 区分 各个小项目。每个小项目的表, 放在各自的模式(schema) 下面。这样, 遇到小项目里面有相同名字的表的话, 不会发生冲突。
例如一个公司的系统。里面分2个子系统, 分别为 财务系统 和人力资源系统。这2个子系统, 共用一个数据库。那么财务系统的表, 可以放在财务的模式(schema)。人力资源系统的表,放在 人力资源系统的模式里面。这2个子系统,能够互相访问对方的表,但是又不因为表重名的问题,影响对方。
没有指明的话,默认是使用dbo模式。
7.
(1). 创建模式 create schema <模式名> authorization <用户名>
删除模式drop schema <模式名> <cascade | restrict> (cascade级联,restrict限制)
(2) 创建表 create table <表名> (列名1 数据类型 列级约束条件 , 列名2……, 列名3…… , 表级约束条件)
删除表 drop table <表名> [cascade | restrict ]
修改表 alter table <表名> [ add列名 数据类型 约束条件 ] 或者[ drop 完整性约束名 ] 或者 [ alter column 列名 数据类型 ]
8.索引
创建索引 create [ unique | cluster ] index <索引名> on <表名> (列名1 [ asc | desc ] ),……,列名n [ asc|desc ])
默认是asc即升序, unique 代表一个索引只对应一个值; cluster 代表索引顺序与物理顺序一致
删除索引 drop index <索引名>
索引能加快查询速度。
在基本表上建立一个或多个索引,以加快查找速度。
索引已经建立,就由系统使用和维护它,不需要用户干预。索引一般采用B+树、hash索引来实现。
当表中有大量记录时,若要对表进行查询,第一种搜索信息方式是全表搜索,是将所有记录一一取出,和查询条件进行一一对比,然后返回满足条件的记录,这样做会消耗大量数据库系统时间,并造成大量磁盘I/O操作;第二种就是在表中建立索引,然后在索引中找到符合查询条件的索引值,最后通过保存在索引中的ROWID(相当于页码)快速找到表中对应的记录。
设置索引要付出代价的:一是增加了数据库的存储空间,二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
9. 数据查询
select [ all | distinct ] <目标表达式1> ,....... <目标表达式n> // distinct用于消除重复元素
from <表名或视图名1>,……,<表名或视图名n>
where <条件表达式>// 若两个或多个表中有相同的列,此处应写 表名.列名 来进行区分
[group by <列名1> having <条件表达式 >] //将查询结果 按某一列或多列的值分组,值相等的为一组。
[order by <列名2> asc | desc ]
注:
(1)目标表达式,常见为 表的列名, 还可以是表达式(算数表达式,字符串常量、函数(count、max、min、avg这些函数可以使用all或者distinct 指定统计范围)等等),此外还可以指定别名来改变查询结果的列标题。
比如 select name newName或者as newName from table1 ;
(2) 条件表达式 , 有大小比较运算符,> < = >= <= != <> !> !<
有确定范围 between and , not between and
确定集合 in , not in
字符匹配
%代表任意长度字符串
_单个字符(注意汉语腰斩两个字符,因此要有两个_ _ )
涉及空值
c642
的查询 is null ,is not null
多重条件 and or not
10.
插入数据 insert into <表名> (列名1,……,列名n) values (常量1,……,常量n)
更新数据 update <表名> set <列名1> = <表达式1>,……,<列名n> = <表达式n> [ where <条件> ]
删除数据
delete from <表名> [ where <条件> ]
11.
12.
13. 范式
◆ 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。
考虑这样一个表:【联系人】(姓名,性别,电话)
如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。
◆ 第二范式(2NF):首先是 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。
考虑一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。
因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合
2NF。不符合 2NF 的设计容易产生冗余数据。
可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)来消除原订单表中UnitPrice,ProductName多次重复的情况。
总结:如果 主键的列 大于等于1个,那么其他的列,要依赖于所有的主键列。不能只依赖于部分的主键列。
◆ 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。
考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。
其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合
3NF。
通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。
第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。
BCNF范式排除了任何属性(不光是非主属性,2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。
14. DTS 在SQL中也叫数据转换服务
SQLServer《-----》 excel、Access、其他数据库
15. MySQL存储引擎;
使用命令 : show engines;
MySQL主要有四种(还有其他)存储引擎: InnoDB、MyISAM
、 memory、merge
MyISAM
:它不支持事务,也不支持外键,尤其是访问速度快,对事务完整性没有要求或者以SELECT、INSERT为主的应用基本都可以使用这个引擎来创建表。
InnoDB存储引擎支持事务处理功能,提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比MyISAM的存储引擎,InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。
相关文章推荐
- 数据库与SQL语言 知识点总结
- android知识点总结 包括数据库的使用 listview适配 contextmenu的使用 和 contentprovider使用
- 数据库事务知识点总结
- 数据库原理 知识点总结
- (原创)大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 神经网络分析算法)
- 数据库原理 知识点总结
- 传智播客数据库开发和ADO.NET知识点总结
- 大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 神经网络分析算法原理篇)
- 数据库知识点总结(2)
- 数据库原理 知识点总结
- (原创)大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 决策树分析算法)
- 总结关于管理数据库和表的知识点
- 大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 顺序分析和聚类分析算法)
- 数据库相关知识点总结
- (原创)大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 聚类分析算法)
- (原创)大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 线性回归分析算法)
- 数据库及SQL----常用知识点总结
- 数据库原理 知识点总结
- 大数据时代:基于微软案例数据库数据挖掘知识点总结(Microsoft 关联规则分析算法)
- (原创)大数据时代:基于微软案例数据库数据挖掘知识点总结(结果预测篇)