MySQL-视图&数据库设计原则

MySQL-视图

视图（view）：是根据用户需求定义的数据结构，是从一个或多个表导出的虚拟的表，其内容由查询定义。具有普通表的结构，但是不实现数据存储。视图本身并不包含任何数据，它只包含映射到基表的一个查询语句，当基表数据发生变化，视图数据也随之变化。

视图：是一张虚拟表（逻辑表），视图只有表的结构（字段信息），没有表的数据，视图的数据通过sql从物理表获取。

一：视图语法

语法：create view 视图名称 as dql

CREATE VIEW view_emp_email_phone AS
SELECT email,phone_number FROM employees

CREATE VIEW  view_emp_info AS

SELECT 
CONCAT(first_name,last_name) AS 'fullname',
email,
salary,
dept.department_name,
jobs.job_title,
locations.city

FROM employees emp

LEFT JOIN departments dept ON emp.department_id = dept.department_id
LEFT JOIN jobs ON emp.job_id = jobs.job_id
LEFT JOIN locations ON dept.location_id = locations.location_id

SELECT * FROM view_emp_info

二：视图的优点

1）简单：使用视图的用户完全不需要关心后面对应的表的结构、关联条件和筛选条件，对用户来说已经是过滤好的复合条件的结果集。

2）安全：使用视图的用户只能访问他们被允许查询的结果集，对表的权限管理并不能限制到某个行某个列，但是通过视图就可以简单的实现。

总而言之，使用视图的大部分情况是为了保障数据安全性，提高查询效率。

数据库设计原则

数据库设计需要达到的目的
1：尽量避免数据的冗余
2：方便对数据的维护（增删改查）

一：第一范式

第一范式(1NF)：属性不可分割，即每个属性都是不可分割的原子项。

反例

正例

二：第二范式

第二范式(2NF)：满足第一范式；且不存在部分依赖，即非主属性必须完全依赖于主属性。(主属性即主键；完全依赖是针对于联合主键的情况，非主键列不能只依赖于联合主键的一部分)

反例

弊端
1：存在数据的冗余
2：数据维护效率比较低

正例

设计表的经验

1：一张表只能描述一个实体，不能描述多个实体

2：如果实体与实体之间是多对多的关系，那么必须通过中间表来维护他们之间的多对多关系

三：第三范式

第三范式(3NF)：满足第二范式；且不存在传递依赖，即非主属性不能与非主属性之间有依赖关系，非主属性必须直接依赖于主属性，不能间接依赖主属性。（A -> B, B ->C, A -> C）

弊端
1：存在数据的冗余
2：数据维护效率比较低

反例

正例

经验：
1：一张表只能描述一个实体
2：如果实体与实体之间是一对多的关系，通过外键去维护一对多的关系，外键设计在多的一方

如果两个实体是一对一的关系？

通过外键来维护实体之间的一对一的关系，外键可以放在任何一方。