Vistas (InterBase y Firebird)

Alexey Kovyazin, última actualización 13-abril-2012

Aquellos que están familiarizados con el lenguaje SQL no requieren explicaciones detalladas sobre este tema, pero para preservar la secuencia de presentación, introduciremos una breve definición de vistas.

Una VISTA es una tabla virtual creada sobre la base de una consulta a tablas ordinarias. Una vista se implementa como la consulta, almacenada en un servidor y ejecutada cada vez que nos referimos a una vista.

Consideremos diferentes variantes de uso de las vistas. Las vistas permiten crear niveles de estructura de datos, permitiendo separar la implementación del almacenamiento de datos de su tipo. Por ejemplo, podemos crear una vista que seleccione datos de varias tablas. Si los clientes usan esta vista en lugar de referirse directamente a las tablas subyacentes, el desarrollador de la base de datos podrá cambiar la consulta subyacente a la vista, alterarla (para optimizarla, por ejemplo), y el cliente no notará nada - seguirá siendo la misma vista para él. Aparte del hecho de que aíslan la implementación del almacenamiento de datos del usuario, las vistas permiten organizar los datos de una manera más conveniente y simple. El problema de la “simplificación” de la estructura de datos surge cuando el número de tablas en una base de datos crece lo suficiente y las interrelaciones entre ellas se vuelven complicadas. La vista permite eliminar (o, por el contrario, añadir) una parte de los datos no necesarios para el cliente concreto de la base de datos (o - necesarios).

Además, las vistas permiten organizar la seguridad en la base de datos InterBase de manera más simple. ¡Algunos usuarios pueden tener derechos solo para leer/actualizar los datos en la vista, pero no tener derechos (e incluso no tener idea) sobre las tablas subyacentes a la vista! Para más detalle sobre la seguridad en InterBase, consulte el capítulo “Seguridad en InterBase: usuarios, sus funciones y derechos” (parte 4).

Sintaxis DDL para trabajar con vistas

Ahora consideraremos los comandos para crear y eliminar vistas definidos por DDL (Data Definition Language - subconjunto de SQL, ver el glosario). Para crear una vista en InterBase, debemos usar la sentencia de la siguiente sintaxis:

CREATE VIEW nombrevista [(columna_vista[, columna_vista…])] AS [WITH CHECK OPTION]; Aquí nombrevista es el nombre de la vista que debe ser único dentro de una base de datos, y luego va un grupo de nombres de campos incluidos en la vista, no siempre obligatorios: [(columna_vista [, columna_vista …])]. Es esencial definir la sentencia que selecciona los datos incluidos en la vista. Discutiremos el parámetro opcional WITH CHECK OPTION un poco más adelante en la parte “Vistas modificadas”.

Para alterar la vista, tendremos que recrearla, es decir, eliminarla y crearla de nuevo. Al eliminar la vista, es necesario eliminar también todos los objetos dependientes - los disparadores, procedimientos almacenados y otras vistas. Esta es una de las principales inconveniencias del trabajo con vistas: la necesidad de recrear el árbol de objetos que usan la vista (hay utilidades que nos permiten hacerlo más fácilmente, por ejemplo IBAlterView, ver la aplicación “Herramientas de administrador y diseñador de InterBase”). Debemos usar el siguiente comando DDL si queremos eliminar la vista:

DROP VIEW nombrevista;

Ejemplos de vistas

Aquí hay un ejemplo de una vista simple:

CREATE VIEW MyView AS SELECT NAME, PRICE_1 FROM Table_example;

En este ejemplo, creamos una vista basada en la consulta a la tabla Table_example que consideramos en el capítulo “Tablas. Claves primarias y generadores”. En este caso, la vista consistirá en dos campos - NAME y PRICE_1, que se seleccionarán de la tabla Table_example sin ninguna condición, es decir, el número de registros en la vista MyView será igual al número de registros en Table_example. Sin embargo, las vistas no siempre son tan simples. Pueden basarse en datos de varias tablas e incluso en base a otras vistas. Además, las vistas pueden contener datos recibidos sobre la base de diferentes expresiones - incluyendo sobre la base de funciones agregadas. Para considerar el uso de esta aplicación de vista con más detalle, creemos dos tablas unidas por una relación uno-a-muchos (a menudo tal relación se llama maestro-detalle). Aquí está el script DDL para crear estas tablas:

/\* Tabla: WISEMEN */

CREATE TABLE WISEMEN ( ID_WISEMAN INTEGER NOT NULL, WISEMAN_NAME VARCHAR(80));

/\* Definición de claves primarias */

ALTER TABLE WISEMEN ADD CONSTRAINT PK_WISEMEN PRIMARY KEY (ID_WISEMAN);

/\* Tabla: WISEBOOK */

CREATE TABLE WISEBOOK ( ID_BOOK INTEGER NOT NULL, ID_WISEMAN INTEGER, BOOK VARCHAR(80));

/\* Definición de claves primarias */

ALTER TABLE WISEBOOK ADD CONSTRAINT PK_WISEBOOK PRIMARY KEY (ID_BOOK);

/\* Definición de claves foráneas */

ALTER TABLE WISEBOOK ADD CONSTRAINT FK_WISEBOOK FOREIGN KEY (ID_WISEMAN) REFERENCES WISEMEN (ID_WISEMAN);

Entonces, hemos creado dos tablas - WISEMEN y WISEBOOK unidas por una relación maestro-detalle usando una restricción de clave foránea - FOREIGN KEY. Supongamos que estas tablas almacenarán la información sobre los grandes sabios chinos y sus obras. Ahora podemos crear algunas vistas basadas en estas tablas. Por ejemplo, creemos la vista que muestre cuántas obras tiene cada sabio:

CREATE VIEW WiseBookCount (WISEMAN, HOW_WISEBOOKS) AS SELECT M.WISEMAN_NAME, COUNT(B.BOOK) FROM WISEMEN M, WISEBOOK B WHERE (M.ID_WISEMAN = B.ID_WISEMAN) GROUP BY M.WISEMAN_NAME

Preste atención a que al usar cualquier expresión calculada como funciones agregadas COUNT (), SUM (), MAX (), etc., es esencial usar nombres definidos de los campos de la vista, es decir, dar nombres a todos los campos devueltos por la consulta. Como podemos ver en este ejemplo, estos nombres no deben necesariamente coincidir con los nombres de los campos de la consulta, pero su cantidad debe coincidir con la cantidad de campos devueltos por la consulta. La definición de qué campo devuelto por la consulta corresponde a qué campo de la vista se hace por un número de serie - el primer campo de la consulta se reflejará en el primer campo de la vista, el segundo - en el segundo, etc.

¿Y si quisiéramos saber cuál de los sabios ha escrito más libros? Intentaremos añadir la expresión para ordenar - ORDER BY a la consulta subyacente a la vista. Sin embargo, este intento no tendrá éxito: el uso de la ordenación ORDER BY en vistas no está permitido y al intentar crear la vista con la consulta que contiene ORDER BY, surgirá un error. Si queremos ordenar los resultados devueltos por la vista, tendremos que hacerlo en nombre del cliente:

SELECT * FROM WiseBookCount ORDER BY HOW_WISEBOOKS

La ejecución de esta consulta SQL conducirá a un resultado deseable. Aparte de la restricción para usar la expresión ORDER BY en vistas, tampoco podemos usar el conjunto de datos recibido como resultado de ejecutar procedimientos almacenados como fuente de datos (ver el capítulo “Procedimientos almacenados” más abajo).

Quizás, vale la pena dar un ejemplo más que ilustre la aplicación de las vistas. Supongamos que tenemos que mostrar una lista de sabios cuyo nombre comienza con la letra “K”. En este caso, usaremos la vista con condiciones:

CREATE VIEW WiseMen2 (WISEMAN) AS SELECT M.WISEMAN_NAME FROM WISEMEN M WHERE M.WISEMAN_NAME LIKE ‘K%’

Así, es fácil crear vistas que juegan un papel de proveedores de datos constantemente actualizables, seleccionándolos de una base de datos según condiciones definidas.

Vistas modificadas

Hemos mencionado anteriormente que hay una capacidad de crear vistas de datos modificadas. ¡Es realmente así - hay una capacidad no solo de leer los datos de la vista, sino también de modificarlos!

Hay dos maneras de hacer que la vista sea modificable. La primera manera se aplica cuando la vista se crea sobre la base de una tabla única (u otra vista modificada), y todas las columnas de la tabla dada deben permitir la presencia de NULL. Así, la consulta en la que se basa la vista no puede contener subconsultas, funciones agregadas, UDF, procedimientos almacenados, sentencias DISTINCT y HAVING. Si todas estas condiciones se cumplen, la vista automáticamente se vuelve modificable, es decir, podemos ejecutar las consultas DELETE, INSERT y UPDATE para ella, que alterarán los datos en la tabla fuente.

La lista de condiciones es bastante impresionante y restringe en gran medida la aplicación de tales vistas modificadas, consecuentemente se usan muy raramente.

Para hacer una vista modificada que viole cualquiera de las condiciones listadas anteriormente, se aplica el mecanismo de disparadores. Para más detalles sobre los disparadores, ver el capítulo “Disparadores” (parte 1). Ahora solo consideraremos los principios generales de organización de la alteración de datos en VIEW.

Para la implementación de una vista actualizada usando disparadores, se debe hacer lo siguiente. Crear 3 disparadores para la vista dada para los eventos: BEFORE DELETE, BEFORE UPDATE y BEFORE INSERT. Describir en estos disparadores qué se debe hacer con los datos al eliminar, actualizar e insertar.

Luego debemos usar la vista dada en consultas de modificación - DELETE, INSERT o UPDATE. Cuando InterBase reciba esta consulta, comprobará si hay disparadores apropiados para la vista dada, es decir, BEFORE DELETE/INSERT/UPDATE. Si el disparador para la acción ejecutable existe, InterBase lo llamará para la modificación de datos reales en las tablas subyacentes a la vista (aunque pueden ser otros datos - no hay restricciones de texto de estos disparadores), y luego releerá la(s) cadena(s) sobre la(s) que se realizó la modificación.

Así, hay una capacidad de realizar cadenas complejas de actualización de datos en vistas.

La opción WITH CHECK OPTION se mencionó en la descripción de la sintaxis de creación de la vista. Si esta opción se establece al crear una vista modificada, cada cadena de datos insertada o alterada en esta vista será comprobada sobre una condición de llegar a la vista. Se puede explicar así: si un nuevo registro insertado por el usuario o recibido como resultado de actualizar el registro existente no satisface las condiciones de la consulta, que es el proveedor de datos para VIEW, la inserción de este registro será cancelada y surgirá un error.

Conclusión

A pesar de la aparente simplicidad de crear y usar vistas, proporcionan grandes capacidades para mejorar la organización de datos en una base de datos y permiten crear una jerarquía de organización de datos.

Algunos diseñadores de aplicaciones de bases de datos usan vistas muy a menudo en su trabajo, otros evitan su aplicación, motivándolo por una complejidad de modificación de vistas y la tendencia a preservar el esquema de la base de datos tan simple y efectivo como sea posible. Depende de usted cómo aplicará las vistas en su trabajo. El punto más importante es recordar la existencia de una herramienta tan poderosa como lo es la vista, y saber cómo usarla.