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;