2.5 VISTAS
2.5.2 VISTAS MATERIALIZADAS
Las vistas materializadas son un tipo especial de vista que permite acelerar el acceso a la información, creando copias físicas del contenido de la vista (un tabla) en lugar de acceder al origen real de la información. En este apartado se detallan las normas básicas a tener en cuenta a la hora de crear vistas materializadas en bases de datos de ICM. Estas normas están orientadas a conseguir que la implementación impacte menos al rendimiento de las bases de datos y a facilitar la administración y el mantenimiento de las mismas.
Para el correcto mantenimiento de las vistas, hay que tener en cuenta que cualquier cambio en la estructura de la tabla origen (añadir o cambiar de tipo de una columna…) puede hacer que el refresco de las vistas materializadas creadas sobre ella dejen de funcionar con lo que debería comunicarse a los departamentos encargados del mantenimiento de las mismas.
A continuación se muestran una serie de normas y buenas prácticas relativas a las vistas materializadas:
BUE
NA
PR
A
C
T
I
CA
VISMatDefinicionBuenas prácticas sobre el uso de vistas materializadas:
66 de 124
mínimo número de columnas posibles en las vistas materializadas.
· Se crearán los índices necesarios para que las consultas sobre las vistas materializadas sean rápidas.
NO
RMA
VISMatProhibido
Se prohíbe el uso de vistas materializadas en modelos de datos de ICM, salvo autorización expresa.
NO
RMA
VISMatNombre
La nomenclatura de las vistas materializadas debe ser [XXXX]_MV_[NOMBRE_VISTA], donde: · XXXX: Nombre del proyecto (Ejemplo: AGCC)
· NOMBRE_VISTA: Nombre de la vista materializada, en mayúsculas. Si contiene varias palabras pueden separarse por guiones bajos (Ejemplo: ARTICULOS_CLIENTE).
Un ejemplo de nombre de vista materializada correcto sería: AGCC_MV_ARTICULOS_CLIENTE.
NO
RM
A
VISMatLecturaTodas las vistas materializadas serán de sólo lectura.
Siempre que creemos una vista materializada en el modelo, debemos activar la opción “Physical Properties” de la pestaña “General”, y en el cuadro de diálogo “Storage Properties” asignar el tablespace de datos (TBSDAT_XXXX_100), según se muestra en la siguiente figura:
67 de 124
En la siguiente norma se fuerza a que todas las vistas materializadas tengan asignado este tablespace:
NO
RM
A
VISMatTablespaceTodas las vistas materializadas del modelo deberán obligatoriamente tener activada la opción “Physical Properties”, y tener asignado el tablespace de datos (TBSDAT_XXXX_100).
68 de 124
Las sentencias que definen el refresco de las vistas materializadas no se incluirán en la definición del modelo ERWIN, ya que son creadas manualmente por el personal de ICM (utilizando un Job). En lugar de esto, en la solapa de comentarios de la vista materializada se incluirá la siguiente información de refresco:
· Volumetría estimada de la vista materializada y, en su caso, del log de vista materializada. · Tipo (completo/incremental)
· Frecuencia (diario, semanal …)
· Si debe actualizarse junto con otras vistas materializadas o puede hacerse de manera individual.
El refresco se programará a lo largo de la noche teniendo en cuenta el tiempo que lleva y los horarios de backup de las bases de datos implicadas. Salvo autorización expresa, la frecuencia del refresco de las vistas materializadas será diaria o superior (semanal, mensual, etc.).
No se permite el refresco incremental de vistas materializadas. En casos excepcionales, debidamente justificados, puede permitirse la utilización de refresco incremental teniendo en cuenta las siguientes consideraciones:
69 de 124
· En ningún caso se permitirá el refresco incremental por ROWID. Por tanto, si la tabla sobre la que se crea la vista debe tener primary key. En caso contrario, el refresco será forzosamente completo. · Únicamente se estudiará la posibilidad de refresco incremental en caso de que los tiempos del
refresco completo sean inviables para el funcionamiento de la aplicación. Esto puede ocurrir por varias razones, entre otras:
o Las tablas originales muy grandes1
o Línea de comunicación lentas entre las dos bases de datos o Se requieren actualizaciones frecuentes
· Dado que el refresco incremental supone la creación y mantenimiento en la base de datos donde reside la tabla origen de un log de vista materializada, la autorización de este tipo de refresco estará siempre condicionada a que el impacto en el rendimiento de la base de datos origen sea asumible por las aplicaciones que se ejecutan en ella. Esto puede presentar problemas especialmente en tablas con muchas actualizaciones.
NO
RM
A
VISMatNoRefrescoLas sentencias que definen el refresco de las vistas materializadas no se incluirán en la definición del modelo ERWIN.
NO
RM
A
VISMatComentario
En la solapa de comentarios de la vista materializada se incluirá la siguiente información de refresco:
· Volumetría estimada de la vista materializada y, en su caso, del log de vista materializada. · Tipo (completo/incremental)
· Frecuencia (diario, semanal …)
· Si debe actualizarse junto con otras vistas materializadas o puede hacerse de manera individual.
NO
RMA
VISMatTipoRefr
Las vistas materializadas por defecto tendrán el tipo de refresco bajo demanda (DEMAND). Los refrescos periódicos se planificarán de manera externa a la base de datos.
NO
RMA
VISMatFrecuenciaRefr
Salvo autorización expresa, la frecuencia del refresco de las vistas materializadas será diaria o superior (semanal, mensual, etc.).
70 de 124
NO
RM
A
VISMatMetodoRefrLas vistas materializadas por defecto se refrescarán con el método de refresco completo. Salvo autorización expresa, no se permite el refresco incremental de vistas materializadas.