一、数据库常见对象

数据库对象是数据库的组成部分，常见的有以下几种：
1.表（Table ）
数据库中的表与我们日常生活中使用的表格类似，它也是由行（Row）和列（Column）组成的。列由同类的信息组成，
每列又称为一个字段，每列的标题称为字段名。行包括了若干列信息项。一行数据称为一个或一条记录，它表达有一定
意义的信息组合。一个数据库表由一条或多条记录组成，没有记录的表称为空表。每个表中通常都有一个主关键字，用
于惟一地确定一条记录。
2.索引（Index）
索引是根据指定的数据库表列建立起来的顺序。它提供了快速访问数据的途径，并且可监督表的数据，使其索引所指向
的列中的数据不重复。
3.视图（View）
视图看上去同表似乎一模一样，具有一组命名的字段和数据项，但它其实是一个虚拟的表，在数据库中并不实际存。在
视图是由查询数据库表产生的，它限制了用户能看到和修改的数据。由此可见，视图可以用来控制用户对数据的访问，
并能简化数据的显示，即通过视图只显示那些需要的数据信息。
4.图表（Diagram）
图表其实就是数据库表之间的关系示意图。利用它可以编辑表与表之间的关系。
5.缺省值（Default）
缺省值是当在表中创建列或插入数据时，对没有指定其具体值的列或列数据项赋予事先设定好的值。
6.规则（Rule）
规则是对数据库表中数据信息的限制。它限定的是表的列。
7.触发器（Trigger）
触发器是一个用户定义的SQL事务命令的集合。当对一个表进行插入、更改、删除时，这组命令就会自动执行。
8.存储过程（Stored Procedure）
存储过程是为完成特定的功能而汇集在一起的一组SQL 程序语句，经编译后存储在数据库中的SQL 程序。
9.用户（User）
所谓用户就是有权限访问数据库的人。

二、视图（view）

创建视图时名称不能和表名重名,视图实际上是代表了一段sql查询语句,可以理解成视图是一张虚拟的表,表中的数据会随着原表的改变而改变.
为什么使用视图:因为有些数据的查询需要书写大量的sql语句,每次书写比较麻烦,使用视图可以起到sql重用的作用,可以隐藏敏感信息

创建视图

create view 视图名 as 子查询;

修改视图

create or replace view 视图名 as 子查询

删除视图

drop view 视图名;
drop view if exists 视图名;(如果存在删除不存在也不会报错)

视图的分类

简单视图:创建视图的子查询中不包含:去重,函数,分组,关联查询的视图称为简单视图. 可以进行增删改操作
复杂视图: 和简单视图相反.

在简单视图中进行增删改操作

视图中插入数据 insert into 视图名 (字段名....) values (字段值....);
数据污染: 往视图中插入一条视图中不显示,但是原表会显示的数据称为数据污染
如果需要避免数据污染的出现,创建视图时需要使用 with check option的关键字
修改和删除只能操作视图中存在的数据

视图别名

如果创建视图的时候使用了别名,则对视图操作的时候只能使用别名

三、索引

提高查询速度
如果不使用索引,数据会零散的保存在磁盘块中,磁盘块大小(4-8kb),查询数据时需要挨个遍历每一个磁盘块,直到找到数据为止；使用索引之后会在磁盘中将数据以树状结构进行保存,查询数据时从树状结构中进行查询,可以大大降低磁盘块的访问数量,从而提高查询速度
索引内部原理图
索引会占用磁盘空间,所以创建时需谨慎,根据查询需求来决定创建什么索引.
索引需要建立在大量数据的表中,如果数据量不够大,有可能会降低查询效率
索引的分类

聚集索引(聚簇索引):数据保存在树状结构中,一张表只有一个聚集索引,数据库会自动为添加了主键的表创建聚集索引.
非聚集索引: 树状结构中没有数据,保存的是磁盘块的地址

创建索引(非聚集索引)

create index 索引名 on 表名(字段名[(长度)]);

create table 表名(字段名...,index 索引名(字段));(创建表时添加索引)

查看索引

show index from 表名;

删除索引

drop index 索引名 on 表名;

复合索引

创建索引的时候添加多个字段,这种索引称为复合索引
当频繁使用多个字段作为查询条件的时候使用复合索引

create index 索引名 on 表名(字段1,字段2...);

四、数据库设计常见三大范式

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。
范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
在实际开发中最为常见的设计范式有三个：
1．第一范式(确保每列保持原子性，所有字段值都不可分解)

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

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

2．第二范式(确保表中的每列都和主键相关而不能只与主键的某一部分相关（主要针对联合主键而言））

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

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

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等
信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。而如果把这个订单信
息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

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