1.4. Creacion y borrado de vistas

Como hemos observado, la arquitectura ANSI/SPARC distingue tres niveles, que se describen en el esquema conceptual, el esquema interno y los esquemas externos. Hasta ahora, mientras creábamos las tablas de la base de datos, íbamos describiendo el esquema conceptual. Para describir los diferentes esquemas externos utilizamos el concepto de vista del SQL.

Para crear una vista es necesario utilizar la sentencia CREATE VIEW. Veamos su formato:

CREATE VIEW nombre_vista [(lista_columnas)] AS (consulta)
            [WITH CHECK OPTION];

Lo primero que tenemos que hacer para crear una vista es decidir qué nombre le queremos poner (nombre_vista). Si queremos cambiar el nombre de las columnas, o bien poner nombre a alguna que en principio no tenía, lo pode- mos hacer en lista_columnas. Y ya sólo nos quedará definir la consulta que formará nuestra vista.

Las vistas no existen realmente como un conjunto de valores almacenados en la base de datos, sino que son tablas ficticias, denominadas derivadas (no materializadas). Se construyen a partir de tablas reales (materializadas) almacenadas en la base de datos, y conocidas con el nombre de tablas básicas (o tablas de base). La no-existencia real de las vistas hace que puedan ser actualizables o no.

Creación de una vista en BDUOC

Creamos una vista sobre la base de datos BDUOC que nos dé para cada cliente el número de proyectos que tiene encargados el cliente en cuestión.

CREATE VIEW proyectos_por_cliente (codigo_cli, numero_proyectos) AS
(SELECT c.codigo_cli, COUNT(*)
FROM proyectos p, clientes c
WHERE p.codigo_cliente = c.codigo_cli
GROUP BY c.codigo_cli);

 

Si tuviésemos las siguientes extensiones:

•   Tabla clientes:

clientes
codigo_cli
nombre_cli
nif
dirección
ciudad
teléfono
10
EGICSA
38.567.893-C
Aragón 11
Barcelona
NULL
20
CME
38.123.898-E Valencia 22
Girona
972.223.57.21
30
ACME
36.432.127-A
Mallorca33
Leida
973.23.45.67

 

 

 

 

 

•   Tabla proyectos:

codigo_proyec
nombre_proyec
precio
fecha_inicio fecha_prev_fin fecha_fin codigo_cliente
proyectos
1
GESCOM
1.000.000
1-1-98
1-1-99
NULL
10
2
PESCI
2.000.000
1-10-96
31-3-98
1-5-98
10
3
SALSA
1.000.000
10-2-98
1-2-99
NULL
20
4
TNELL
4.000.000
1-1-97
1-12-99
NULL
30



Y mirásemos la extensión de la vista proyectos_por_clientes, veríamos lo que encontramos en el margen.

En las vistas, además de hacer consultas, podemos insertar, modificar y borrar filas.

codigo_cli
numero_proyectos
proyectos_por_clientes
10
2
20
1
30
1

 

Actualización de vistas en BDUOC

Si alguien insertase en la vista proyectos_por_cliente, los valores para un nuevo cliente 60 con tres proyectos encargados, encontraríamos que estos tres proyectos tendrían que figurar realmente en la tabla proyectos y, por lo tanto, el SGBD los debería insertar con la información que tenemos, que es prácticamente inexistente. Veamos gráficamente cómo quedarían las tablas después de esta hipotética actualización, que no llegaremos a hacer nunca, ya que iría en contra de la teoría del modelo relacional:

•   Tabla clientes:

clientes
codigo_cli
nombre_cli
nif
dirección
ciuda
teléfono
10
ECIGSA
38.567.893-C
Aragón 11
Barcelona
NULL
20
CME
38.123.898-E
Valencia 22
Girona
972.23.57.21
30
ACME
36.432.127-A
mallorca 33
Lleida
973.23.45.67
60
NULL
NULL
NULL
NULL
NULL






 

 

 

•   Tabla proyectos: 

clientes

codigo_proyec
nombre_proyec
precio
fecho_inicio
fecha_prev_fin
fecha_fin
codigo_cliente
1
GESCOM 1.000.000 1-1-98
1-1-99
NULL
10
2
PESCI
2.000.000
1-10-96
31-3-98
1-5-98
10
3
SALSA
1.000.000
10-2-98
1-2-99
NULL
20
NULL NULL NULL NULL NULL NULL 60
NULL NULL
NULL
NULL
NULL
NULL
60
NULL NULL NULL NULL NULL NULL 60


 

 

 

El SGBD no puede actualizar la tabla básica clientes si sólo sabe la clave primaria, y todavía menos la tabla básica proyectos sin la clave primaria; por lo tanto, esta vista no sería actualizable.

En cambio, si definimos una vista para saber los clientes que tenemos en Barcelona o en Girona, haríamos:

 

CREATE VIEW clientes_Barcelona_Girona AS
(SELECT *
FROM clientes
WHERE ciudad IN (‘Barcelona’, ‘Girona’))
WHITH CHECK OPTION;

Si queremos asegurarnos de que se cumpla la condición de la cláusula WHERE, debemos poner la opción WHITH CHECK OPTION. Si no lo hiciésemos, podría ocurrir que alguien incluyese en la vista clientes_Barcelona_Girona a un cliente nuevo con el código 70, de nombre JMB, con el NIF 36.788.224-C, la dirección en NULL, la ciudad Lleida y el teléfono NULL.

Si consultásemos la extensión de la vista clientes_Barcelona_Girona, veríamos:

codigo_cli
nombre_cli
nif
dirección
ciudad
teléfono
clientes_Barcelona_Girona
10
ECIGSA
38.567.893-C
Aragón 11
Barcelona
NULL
20
CME
38.123.898-E
Valencia 22
Girona
972.223.57.21


 

Esta vista sí podría ser actualizable. Podríamos insertar un nuevo cliente con código 50, de nombre CEA, con el NIF 38.226.777-D, con la dirección París 44, la ciudad Barcelona y el teléfono 93.422.60.77. Después de esta actualización, en la tabla básica clientes encontraríamos, efectivamente:

codigo_cli
nombre_cli
nif
dirección
ciudad
teléfono

clientes

10
ECIGSA
35.567.893-C
Aragón 11
Barcelona
NULL
20
CME
38.123.898-E
Valencia 22
Girona
972.23.57.21
30
ACME
36.432.127-A
Mallorca 33
Lleida
973.23.45.67
50
CEA
38.226.777-D
París 44
Barcelona
93.442.60.77







 

 

 

Para borrar una vista es preciso utilizar la sentencia DROP VIEW, que presenta el formato:

 

DROP VIEW nombre_vista (RESTRICT|CASCADE);

 Si utilizamos la opción RESTRICT, la vista no se borrará si está referenciada, por ejemplo, por otra vista. En cambio, si ponemos la opción CASCADE, todo lo que referencie a la vista se borrará con ésta.

 

Borrar una vista en BDUOC

Para borrar la vista clientes_Barcelona_Girona, haríamos lo siguiente:

DROP VIEW clientes_Barcelona_Girona RESTRICT;