策略：首先基于多个视图生成一致性表示，再应用现有的聚类算法，如谱聚类来实现最终的聚类结果。

子空间学习（subspace learning):假设视图间有一个潜在子空间，学习目的是从视图中获得一个合适的子空间，然后为所有视图生成一致性表示，然后将共同的子空间表示矩阵利用谱聚类得到最后的聚类结果。

例如：

• Gao hongchang等人首先学习得到多个视图数据的公共子空间表示，再用谱聚类方法对子空间表示矩阵进行聚类得到最后的聚类结果。[16]
• Liu Iialu等人首先利用非负矩阵分解对多个视图信息进行融合，得到集成多个视图信息的系数矩阵，再用K均值方式得到最后的聚类结果。[25]
• Yuhong等人利用低秩表示融合多个视图信息获得一致性低秩矩阵，再将其一致性矩阵利用主动三支谱聚类得到最后的聚类结果。[34]
• K等人利用典型相关分析（Canonical correlation analysis，CCA）将多视图的高维数据投影到低维子空间中，再进行选标准聚类方法进行聚类。[37]

基于非负矩阵分解的多视图聚类方法[28-30]

由于多视图数据常常具有高维的数据特点，非负矩阵分解(Non-negative MatrixFactorization，NMF)在数据降维上具有优良的性能。基于NMF的多视图聚类方法由于其简单性和可解释性而已成为广泛使用的多视图聚类算法。

• Liu Jialu等[25]首次将非负矩阵分解应用于多视图聚类中，结合基与中心的共正则化策略融合视图间的信息，提出的MultiNMF方法取得了较好的聚类结果。
• Zong Xianchao等[26]将局部结构约束与NMF结合用于多核视图聚类,在聚类的同时保持数据的局部结构。
• Wang Xiumei 等[27]利用成对约束和NMF用于多视图聚类，同时考虑视图内的相似性和视图间的相似性，获得视图的一致性信息。
• Cheng Wei等[48]利用semi-NMF用于多视图聚类。
• 2014年 Li Shaoyuan等[49]提出的PVC方法首次利用NMF和L1稀疏规则算子对两个存在缺失数据的视图进行聚类，PVC的主要思想是在不同视图中描述同一样本的实例应该彼此相似，在视图内部相似的实例应该被划分到同一类。该方法在处理部分视图聚类表现更好，使得基于NMF的多视图聚类方法更多的被用于处理不完整多视图数据。例如 Shao Weishang 等[50]提出的MIC方法结合weighted-NMF和 L2,1规则化对不完整多视图数据进行聚类。Hu Meng等[51]对MIC进行扩展通过weighted semi-NMF和L2,1规则化，使之能处理属性值为负的样本。G.Rai等[52提出的GPMVC方法利用NMF和对每个视图添加图约束使得能处理多个不完整多视图聚类。Zhao Handong 等[53提出的IMG方法结合PVC 和流形学习去捕捉所有样本的全局结构。Qian Bin 等[54提出的DCNMF方法利用簇间相似性和图约束两层约束进行部分多视图聚类。Zhang Xianchao 等[55]和Zong Linlin 等l56利用半监督学习方法结合非负矩阵分解解决视图间的样本对应关系是完全未知的问题，通过在少量视图间样本的对应关系已知的情况下，并提供一种视图间样本关系传递的方式，来得到尽可能多视图间样本的匹配信息，已获得更好的聚类结果。
   

---

adaptive weighted graph fusion incomplete multi-view subspace clustering 2020 

 本文方法：首先，为了消除噪声，我们将全部的原始数据转换成潜在表示（可以为每个视图贡献出更好的graph construction），然后我们合并特征提取和不完整的图融合入一个统一的框架，同时两个过程可以相互协商，共同为一个图学习任务服务。一个稀疏正则化被强加在完整图上为了使其具有鲁棒性关于视图不一致。除此之外，不同视图的重要性被自动学习，大大指导了完整视图的构建。

现有的多视图聚类方法：多核聚类；协同训练和协同正则化；第三种策略协作地转换多视图信息为紧密的共同二进制代码空间，然后在hamming空间进行聚类处理并且使用超越算法加速；最后一种基于子空间的聚类算法，它假设高维数据点是从各种低维子空间描绘得到的，并且每一个簇也能从一个子空间中得到，主要思想是找到几个嵌入在潜在空间中的低维表示然后为下游聚类任务获得一个联合的表示，除此之外，目标是通过矩阵分解/非负矩阵分解找到一个共享的低维潜在表示。

不完整多视图聚类方法：基于非负矩阵分解的方法和基于图的。基于NMF的方法旨在直接获得一个共同的低维表示通过非负矩阵分解。

半非负矩阵分解：

本文想法： 

---

Feature concatenation multi-view subspace clustering

FCMSC

 为了利用互补信息，加入图正则化约束，可以保留局部流形结构，gr-FCMSC:

数据集：

BBCSport （2个视图，每个视图有5个class,总共544条数据） 

Movies617(2个视图，每个视图有17个class，总共617条数据）

MSRCV1(5个视图，每个视图有7个class,总共210条数据）

Olympics(9个视图，每个视图有28个class，总共464条数据）

ORL（3个视图，每个视图有40个class,总共400条数据）

Yale Face(3个视图，每个视图有15个class，总共165条数据）

---

2.子空间聚类聚类问题

①代数方法

        包括基于矩阵分解的方法和代数几何的方法。基于矩阵分解的方法通过对数据矩阵的低秩分解获得点的划分，因此可以看作PCA从单个到多个独立线性子空间的拓展。但该方法需要预先知道矩阵的秩且要求各子空间相互独立。
       广义主成分分析 (GPCA)是代数方法中的一个代数几何方法，与基于矩阵分解的方法不同的是GPCA不要求线性子空间独立，因此既能处理子空间相互独立的情形也能处理子空间不独立的图形。GPCA用一组 多项式对高维数据进行拟合，多项式在某一数据点的梯度给出了包含该点的子空间的法向量。因此当子空间的个数和维度较小时，算法的计算复杂度也低，但随着子空间个数和维度的增加算法的计算复杂度将呈指数增长。当数据无噪声时，GPCA不用预先知道子空间的个数和维度。另外，由于计算多项式系数向量时采用最小二乘法，因此算法对异常值敏感。

②迭代方法
迭代式方法可以看作是对代数式方法的一种提升。首先通过对数据集的随机分割获得类簇的初始划分，然后对各簇数据集用PCA拟合一个子空间，接着将每个数据点划分到距离它最近的子空间，最后不断重复后两步直到满足收敛条件。K平面算法和K子空间算法是两个经典的迭代方法，两者思路类似K均值(K-Means) 算法，但数据的空间分布存在不同，前者的数据来自超平面，后者则来自仿射子空间。该类算法的优点主要体现在算法的简单上，且能保证迭代在有限步内收敛到一个局部最优解。同时类似于K-Means算法，迭代方法的也将对初始化结果敏感。另外，显然该方法需要预先给定子空间的个数和维度。

③统计方法

代数方法和迭代方法只利用了联合子空间的代数和几何性质，并未对子空间内的数据和噪声的分布做出假设，因此所得的结果并非最优。为解决该问题，统计方法为子空间内的数据定义了生成模型。譬如混合概率主成分分析(MPPCA)通过使用混合的概率PCA模型将概率PCA模型 (PPCA)拓展到了联合子空间。然后通过期望最大化(EM)算法获得混合模型参数的极大似然估计。类似于软K均值算法与K均值算法(也称为硬K均值)之间的关系，MPPCA可以看作K子空间算法在数据点的再分配中采用软分配替代硬分配。但MPPCA预先获知子空间的个数和维度。
        随机抽样一致性算法 (RANSAC)通过迭代法从一组有离群点的数据样本点中拟合统计模型。假设子空间的维度均为d,那么RANSAC每次拟合的模型就是一个维度为d的子空间。RANSAC算法有如下优点:有明确的步骤处理离群点:不需要假设子空间独立，也不需要知道子空间的个数,但实际上子空间的个数间接决定于用户定义的阈值。RANSAC也有严重的缺点，比如上述算法描述中假设每个子空间的维度相同，当子空间的维度各不相同时，则需要通过遍历的方式进行。

④基于谱聚类

基于谱聚类的方法是高维数据聚类分析的重要方法之一-。该类算法主要分两步:第一步也是最为重要的一步，构建数据点间的相似度矩阵。第二步，对所得相似度矩阵使用谱聚类。该类方法最大困难点在于如何定义一个好的相似度矩阵。因为两个数据点可能距离很近却位于不同的子空间，或者两个点距离很远却位于相同的子空间，所以使用基于距离度量的相似度矩阵并不合理。按照相似度矩阵的计算方式，基于谱聚类的方法又可以大致分为三类:基于分解的方法、基于高阶模型的方法、基于自表示的方法。
       基于自表示的方法的基本思想是将样本点表示为同一子空间内其它点的线性组合，然后利用组合系数矩阵构建相似度矩阵。不同于其它基于临近点的线性表示方法，例如局部子空间邻接算法 (LSA)、谱局部最佳拟合平面 (SLBF)、局部线性流型聚类(LLMC)等，后者往往根据点对之间的角距离或者欧式距离确定表示字典，而基于自表示的方法将整个数据集视为表示字典，然后将每个点表示成其它数据点的线性组合。为了解决数据的自表示模型所产生的不适定问题，Elhamifar 和Vidal在文献中引入了稀疏性准则，提出了SSC算法。该算法将每个点写成所有其它点的稀疏线性组合, 然后最小化非零表示系数的个数。文献中 表明如果各子空间独立或不相交，每个点可以表示为同一子空间中其它点的稀疏线性组合。文献中 Liu等人对自表示系数矩阵引入了低秩约束提出了LRR算法。LRR算法在低秩性约束下共同地获得了所有数据点的子空间表示，因此能更好地获得数据的全局结构关系。但是相比SSC算法，LRR算法所获得的系数矩阵往往是稠密的，不利于谱图算法的类簇划分。
       在自表示模型和稀疏低秩约束的基础上，研究人员还提出了许多改进的算法。在文献中，Lu等人在子空间划分问题中引入最小二乘回归(LSR)模型，所提算法不仅对有界扰动具有鲁棒性，而且由于算法具有闭式解大大提高了算法的运行效率。在文献中，Wang等人认为系数表示矩阵一般同时具有稀疏性和低秩性，提出了低秩稀疏子空间聚类算法(LRSSC)， 并且给出了算法有效的理论保证。实验结果表明LRSSC算法能既能保留自表示特性，又能拥有图连通性。针对数据不充分或严重受噪声污损情况，提出隐低秩表示算法(LatLRR)。该算法同时使用观测数据和隐式数据构建表示字典，并将子空间分割和特征提取过程融合到同一的框架之中。Lu 等人认为稀疏性和整体效应(grouping effect)对子空间分割都十分重要，前者保证所得系数表示矩阵的块对角特性，后者保证同一空间中的数据点能被正确分组，因此通过引入trace Lasso约束，提出了关系自适应子空间分割算法(CASS)。（2018）
 

概念

什么是视图？

视图是基于 SQL 语句的结果集的可视化的表。

当然视图也是数据库中对象之一，其它的对象包括：表，数据字典，约束,索引，触发器，存储过程，以及存储函数。这些后面再聊，本篇主要聊的就是视图。

而视图本身不存储数据，而是通过映射原表，方便用户对数据进行查看和操作。

视图让用户使用表或者多个表的一部分数据，而不是所有的表数据。这样可以针对不同的用户定制不同的查询视图，这样让同样的数据对不同的人呈现不同的假表数据，其实保证了数据的安全。

视图时一种虚拟表，本身是不具有数据，占用很少的内存空间，是SQL中的重要对象。

视图的存在依托于已有的表，而这些表时基表。

• 视图的创建和删除只影响视图本身，不会影响到基表，但是如果对视图的数据进行增删改等操作的时候，基表的数据也会相应的放生变化，反之亦然。
• 其实创建视图 的时候，需要通过SELECT语言，所以可以将视图简易理解位存储起来的SELECT语言查询结果。视图本身不存储数据的，还是前面说的时映射的数据。

其实视图时向用户提供基表数据的另一种形式，通常情况下小型项目的数据库可以不适用视图。所以再大型项目，以及数据表比较复杂的情况下，视图就体现出有点了。将经常查询的记过放在视图中，提升使用效率，

其实视图本质：就是将一个表或多个表关联的查询的结果生成一个视图。而视图本身不存储数据，而是通过映射基表，方便用户对数据进行查看和操作。视图创建和删除不影响基表，但增删改会影响基表。

创建视图

创建视图的格式：

CREATE [OR REPLACE ]
[ALGORITHM ={ UNDEFINED |MERGE | TEMPTABLE }]
VIEW 视图名 [(字段名)]
AS 查询语句
[WITH [CASCADED |LOCAL] CHECK OPTION ]

-- 上面时完整的结构，但是一般使用格式如下，有点像是通过数据创建表的样式。
CREATE [OR REPLACE ]
VIEW 视图名 [(字段名)]
AS 查询语句

对有些新的关键子进行讲解

• REPLACE 表示替换已经创建的视图
• ALGORITHM 表示的时视图的算法，其中参数有三个。
  • UNDEFINED： 表示MYSQL将自动选择算法。
  • MERGE：表示将使用的视图语句和视图定义合并，使得视图定义的某一部分取代语句对应的部分。
  • TEMPTABLE：表示将视图的结果存入临时表，然后用临时表执行语句。
• CASCADED与LOCAL为可选参数
  • CASCADED为默认值。表示更新视图时要满足所有先关视图和表的条件；
  • LOCAL表示更新视图时满足该视图本身定义的条件即可。

现在开始演示，这个时候就用之前聊查询语言的是表进行，演示也就是，三张表：员工表，部门表和工资等级表。

员工表：

部门表：

工资等级表：

为了方便演示，直接通过员工表和部门表进行演示。

SELECT dept.dname,emp.empno,emp.ename FROM  emp, dept WHERE emp.deptno=dept.deptno;

然后创建视图：

CREATE VIEW table_v AS  SELECT dept.dname,emp.empno,emp.ename,emp.sal FROM  emp, dept WHERE emp.deptno=dept.deptno;

-- 然后查询视图
SELECT * FROM table_v;

这个视图没有写视图的字段，这个是可以重新写字段名，但是有一点 ，就是字段个数和SELECT中的字段个数要一样。

现在有一个一个问题，前面说是的映射的表，那么带有函数的查询语句可以创建视图吗？

SELECT dept.dname,AVG(emp.sal) FROM  emp, dept WHERE emp.deptno=dept.deptno GROUP BY emp.deptno

然后创建视图：

CREATE VIEW table_v1 (dname,ave_sal) AS  SELECT dept.dname,AVG(emp.sal) FROM  emp, dept WHERE emp.deptno=dept.deptno GROUP BY emp.deptno;
 
SELECT * FROM table_v1;

可以看出调用的MYSQL的函数也是可以创建视图的。如何证明是映射，后面可以通过更新基表，看其是否改变即可。后面修改后面会演示，暂时保留。

视图的有关的sql

查询数据库中有多少视图：

SHOW TABLES; 

查看视图结果：

DESC / DESCRIBE 视图名

例子：

DESC table_v1;

查看视图的属性信息

-- 查看视图信息（显示存储引擎，版本，数据行数和数据大小等）
SHOW TABLE STATUS  LIKE '视图名';

演示例子

-- 先查询表的属性
SHOW TABLE STATUS  LIKE 'emp';

SHOW TABLE STATUS  LIKE 'table_v1';

通过视图和表的对比可以看出，视图中的所有属性都是NULL，所以可以通过这个命令确立要查询的表是虚拟表还是真表。

这个截图看着有点长，如果方便看可以在dos创建查看：

SHOW TABLE STATUS  LIKE 'table_v1' \G

还有一个可以看创建视图的语句。

SHOW CREATE VIEW 视图名称;
-- 这个就不在演示了，毕竟前面在表中演示过。

还有可以通过视图生成视图，就像是套娃了，这个就不在演示了。

视图更新数据

前面说过如果对数据库视图进行增删改操作会影响原来的数据库。

当然如果对基表进行操作也会影响视图，两者彼此会影响的。

现在更新一下视图的

-- 可以看出更新视图中 empno='7900'的工资950更改位1000
UPDATE table_v SET table_v.sal='1000'  WHERE table_v.empno='7900';

现在看一下员工表

SELECT * FROM emp   WHERE emp.empno='7900';

前面不是演示了上面没有更新的视图table_v1如下

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EKOWnpku-1643175420470)(F:\文档\笔记\数据库\mysql\12：视图.assets\image-20220123204753145.png)]

现在看一下 更新视图中 empno='7900'的工资950更改位1000,影响了基表，然后看一下基表会不会影响视图table_v1；

这个又涉及到一个神奇的操作，那就是是否可以操作table_v1中的ave_sal的值？

UPDATE table_v1 SET table_v1.ave_sal='1000'  WHERE table_v1.dname='SALES';

这个可以看出视图中的字段如果在基表中没有，就会报错，这种没有不是说字段名不一样而是其来源直接没有，这个是通过计算得到的。

现在看是否删除会相互影响：

-- 通过删除视图中 empno='7900'的数据
DELETE FROM table_v  WHERE empno='7900';

前面说过是UPDATE,这个相对限制很小，几乎所有的都可以操作，但是对于INSERT 和DELETE 就有点不同，这个限制有点多。

如果INSERT 和DELETE可以用前提是视图中行和底层基表中的行必须存在一对一的关系。然后看一下不能增删的视图条件：

• 在定义视图的是时候指定了”ALGORITHM=TEMPTABLE“，视图将不支持INSERT 和DELETE操作。
• 视图中不包含基表中所有被定义位非空又未指定默认值的列，视图不支持INSERT 操作。
• 在定义视图的SELECT语言中使用了JOIN联合查询，视图将不支持INSERT和DELETE操作。所以前面说一下要一对一，毕竟联合查询得到视图，视图就不是一一对应基表了。
• 在定义视图的SELECT 语言后的字段列表中使用了数字表达式或子查询，视图将不支持INSERT，也不支持INSERT，也不支持UPDATE使用数学表达式，子查询的字段。如果子查询应用了FROM后面的表不但不支持INSERT，还不支持UPDATE，DELETE.
• 在定义视图的SELECT语句后的字段使用了DISTINCT，聚合函数，GROUP BY，HAVING，UNION等，视图不支持INSERT,UPDATE，DELETE。
• 视图定义了一个不可更新的表或者式常量视图表。

上面总结其实有点绕，下面依次演示。

为了演示效果，所以只是简单的演示，所以数据本身就没有多少意义。

CREATE TABLE  test_a(
t_id INT,
t_name VARCHAR(5),
t_flag INT
);

CREATE TABLE test_b(
t_flag INT,
t_flag_name VARCHAR(10)
);

INSERT INTO test_a VALUES (1,'a_a','1');
INSERT INTO test_a VALUES (2,'a_b','2');
INSERT INTO test_a VALUES (3,'a_c','2');
INSERT INTO test_a VALUES (4,'a_d','3');
INSERT INTO test_b VALUES (1,'b_a');
INSERT INTO test_b VALUES (2,'b_b');
INSERT INTO test_b VALUES (3,'b_c');

非一对一

通过join on（= 也是这个其中一个）关联

CREATE VIEW t_v1 AS
SELECT  t_name, t_flag_name FROM   test_a,test_b WHERE test_a.`t_flag`=test_b.`t_flag`;

其实UPDATE就不在演示了，毕竟前面已经演示了，现在看是否可以插入和删除。

首先插入：

INSERT INTO t_v1 VALUES ('a_g','b_g');

提示前面没有知名后面的数据指定的字段名，所以这个可以补充字段才行，前提可以试一下如果只有一个字段呢？

CREATE VIEW t_v2 AS
SELECT  t_name  FROM   test_a,test_b WHERE test_a.`t_flag`=test_b.`t_flag`;

INSERT INTO t_v2 VALUES ('a_gg');

可以看出在多表形成视图中哪怕只有一个字段也是需要加入字段名的。

INSERT INTO t_v1 ( t_name, t_flag_name ) VALUES ('a_g','b_g');

然后加全后就报错，无法插入超过一个表以上的视图，无论是否非显示字可以非空都会报错。

但是如果你插入的是虽然是两个表产生的视图，但是另一个表对呈现的数据没有任何作用，比如上面的t_v2；

-- 这个就无法通过视图 SELECT * FROM  test_a查看了
-- 而是通过
SELECT * FROM  test_a;

虽然没有显示但是t_flag 无法匹配 test_b中数据所以只能通过基表看。

可以看出这个虽然是两个表，但是字段只是一个表显示字段没有用另一个表的，所以可以看成一个表。

现在看一下如果删除的话：

DELETE FROM  t_v1;

可以看出无法删除多表关联生存的视图。

现在试一下

DELETE FROM  t_v2;

虽然插入的数据t_v2可以成功，但是删除就报错。

至于添加默认和非空这个限制就不在多表中体现了，而是在单表演示了。

子查询

其实t_v2有点像是用了子查询的意思了，不过还是不同的。现在重新来一个，不过子查询也有两种情况，一种是子查询作为一个条件存在，一个是子查询作为一个字段。

-- 这一种有人会让其放入一对一的关系中
CREATE VIEW t_v3 AS
SELECT  t_name  FROM   test_a  WHERE t_flag IN (SELECT t_flag FROM test_b) ;

update就不在演示了，这个其实除非不可改或者限制唯一然后更改了数据重复，一般都是可以用的，主要针对是插入和删除。

INSERT INTO  t_v3  VALUES ('a_zc');

如果使用的是子查询，在插入的时候可以不带字段名。

所以就不用演示带字段名的了，现场尝试一下是否可以删除。

DELETE FROM  t_v3 WHERE t_name='a_d';

可以看出可以删除，同时也影响了原表。

现在在来一个子查询，这个关联可以在FROM前面

CREATE VIEW t_v4 (t_name,t_flag_name) AS
SELECT  t_name ,(SELECT test_b.`t_flag_name` FROM test_b WHERE test_b.`t_flag`=test_a.`t_flag` ) FROM   test_a ; 

插入就不尝试用前面无字段的，直接演示带字段的，因为带字段的都会报错，不要提不带字段的了

INSERT INTO  t_v4  (t_name,t_flag_name) VALUES  ('a_v4','b_v4');

插入都不靠谱，那就说实话删除也会报错

DELETE FROM t_v4;

一对一

对于一对一，这个很好理解就是视图本身通过一个表而生成视图，不过这个又会分好几种。如果不涉及任何运算，同时字段中没有非空的或者有非空限制但是又默认值的基表，通过其生成的视图完全可以增删改，而下面举的例子是插入删除的例子。

聚合函数

这个最常见的就是AVG,COUNT等所以只列出一个例子。

test_a表的内容恢复到初始化。

CREATE VIEW t_v5 AS 
SELECT t_flag,COUNT(t_flag) t_count FROM test_a GROUP  BY t_flag;

现在尝试一下是否可以更新：

UPDATE t_v5 SET t_flag='5' WHERE t_flag='1';

直接报错，那通过函数操作的t_count就更不用演示更新了，这个也会报错的。

现在尝试一下插入和删除。

INSERT INTO t_v5   VALUES ('11','12');

这种不会报错其没有限制字段，而是直接报错不可以插入数据。

INSERT INTO t_v5 (t_flag,t_count) VALUES ('11','12');
-- 和不带字段的报错一样，所以不在截图

可以删除吗？

DELETE FROM  t_v5 WHERE t_flag='1'

可见也无法删除。所以说有了聚合函数只能更新无法插入和删除。

HAVING

在聚合函数中演示的时候说无法插入和删除，一般使用HAVING的时候常与函数搭配使用，但是目前不考虑效率讲HAVING只作为一个类似WHERE的操作呢？

CREATE VIEW t_v6 AS 
SELECT t_flag  FROM test_a HAVING t_flag>'1' ;

更新尝试：

UPDATE t_v6 SET t_flag='5' WHERE t_flag='3'

更新都无法操作，为什么会这样呢？虽然讲HAVING当作一个WHERE使用，但是其在SQL中读取的顺序中还是GTOUP BY 等后面，所以前面都无法插入后面的就更不可能会允许更改了，后面的插入和删除就不在演示了，毕竟更新要求最低都不满足插入和删除更不可能了。

DISTINCT

CREATE VIEW t_v7 AS 
SELECT DISTINCT t_id   FROM test_a 

其实为了体现DISTINCT应该使用的字段是t_flag,但是为了演示哪怕这个DISTINCT关键没有意义，但是其还是会影响增改删。

UPDATE t_v7 SET t_id='5' WHERE t_id='1'

看这个就不允许演示插入和删除了吧，还是老话要求最低的你都满足不了，要求更高的就不要想了。

有时候记前面的有点复杂个人总结记住虽然不敢说全，但是好记够用。

两表以上相关联，无论通过join还是子查询，删除插入不要想。

还有一种怪现象，两表想联呈现字段为一表可插不可删。

更新要求它最低，两表以上就不提哪怕一表有函数，HAVING，DISTINCT等增删改就莫想了。

没有上面的限制，基表只唯一，查看字段是否有限制。

修改视图

这个有两种 第一种：

CREATE OR REPLACE VIEW 视图名
[字段]
as
查询语句

第二种：

ALTER VIEW 视图名
as
查询语句

这个是整体将视图修改了，比如增加字段或者修改再视图中呈现的字段名。这个感觉有点像是将视图又重新生成了一遍。

删除视图

删除视图只是删除视图的定义，并不会删除基表的数据。（是drop 而非delete ）

--
DROP VIEW [IF EXISTS] 视图名

--
DROP VIEW [IF EXISTS] 视图名1，视图名2………………

如果是基于视图创建的视图，如果刹车删除所谓的假基表（视图）也会导致基于假基表视图无法查询出数据，所以需要清楚这个关系。

类推也就是如果删除基表也会影响视图的查询。

总结

• 优点

  • 操作简单，将一些不关心的数据屏蔽掉让开发人员可以更简单的操作表。不用关心表直接关系，只需要查询即可。同时也可以将很多复杂的逻辑进行分解，创作多个视图获取数据，再将视图集合得到最终数据
  • 减少数据冗余: 如果满足操作简单，可以创建一个表插入即可但是占用空间，而视图不会。
  • 数据安全：前面一直说可以隐藏没必要显示的字段，无法得知数据库本来的数据库表结构以及表关系。再结合用户的权限控制会更加保证了数据的安全。
  • 适应灵活多变需求：毕竟业务系统的需求变化后，一般数据库表也会改变结构，则工作量相对较大，可以使用视图来减少这些改动带来的工作量。

• 缺点

  视图本身是依托基表的，所以基表的修改都会影响视图，有时候修改过大可能需要即使对相关的视图进行维护。有些是视图上创建视图，这样套娃的方式让其维护变得比较负责，可读性不是很友好。

  视图可以重新定义字段名，还可以包含复杂的逻辑，这些都会增加维护成本。

  所以视图是否需用这个需要，需要依托于自己的项目是否需要以及公司要求。