Almacén de datos típico de esquemas en estrella de Kimball: ¿vistas de modelo factibles? y como codificar gen

Question

Tengo un almacén de datos que contiene esquemas en estrella típicos y un montón de código que hace cosas como esta (obviamente mucho más grandes, pero esto es ilustrativo):

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

Estoy pensando en reemplazarlo con una vista ( MODEL_SYSTEM_1 , por ejemplo), para que se convierta en:

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

Pero la vista MODEL_SYSTEM_1 debería contener nombres de columna únicos, y también me preocupa el rendimiento con el optimizador si sigo adelante y hago esto, porque me preocupa que todos los elementos en la cláusula WHERE, a través de diferentes hechos y dimensiones, se optimizan, ya que la vista se vería a través de toda una estrella, y las vistas no se pueden parametrizar (chico, ¿no sería genial?)

Así que mis preguntas son -

1. ¿Está bien este enfoque, o simplemente va a ser una abstracción que daña el rendimiento y no me da una sintaxis mucho más agradable?

2. ¿Cuál es la mejor manera de codificar estas vistas, eliminando los nombres de columna duplicados (incluso si la vista más adelante necesita ser modificada a mano), dado que todos los PK y FK apropiados están en su lugar? ¿Debería escribir algo de SQL para extraerlo del INFORMATION_SCHEMA o hay un buen ejemplo ya disponible?

Editar: Lo he probado y el rendimiento parece ser el mismo, incluso en los procesos más grandes, incluso uniéndome a varias estrellas, cada una de las cuales usa estas vistas.

La automatización se debe principalmente a que hay varias de estas estrellas en el almacén de datos, y los diseñadores han hecho el FK / PK, pero no quiero tener que revisar todas las tablas o la documentación. . Escribí un script para generar la vista (también genera abreviaturas para las tablas), y funciona bien para generar el esqueleto de forma automática a partir de INFORMATION_SCHEMA , y luego se puede ajustar antes de confirmar la creación de la vista. .

Si alguien quiere el código, probablemente podría publicarlo aquí.

Answer 1

1. He usado esta técnica en varios almacenes de datos que cuido. No he notado ninguna degradación del rendimiento cuando se ejecutan informes basados ??en las vistas frente a un enfoque directo de tabla, pero nunca he realizado un análisis detallado.

2. Creé las vistas usando el diseñador en el estudio de administración de SQL Server y no usé ningún enfoque automatizado. No puedo imaginar que el esquema cambie tan a menudo que valga la pena automatizarlo. ¡Puede dedicar tanto tiempo a ajustar los resultados como hubiera sido necesario arrastrar todas las tablas a la vista en primer lugar!

Para eliminar la ambigüedad, un buen enfoque es prefaciar los nombres de las columnas con el nombre de la dimensión a la que pertenece. Esto es útil para los redactores de informes y para cualquier persona que realice consultas ad hoc.

Answer 2

Convierta la vista o vistas en una o más tablas de hechos de resumen y materialícelas. Estos solo deben actualizarse cuando se actualiza la tabla de hechos principal. Las vistas materializadas serán más rápidas de consultar y esto puede ser una ganancia si tiene muchas consultas que pueden ser satisfechas por el resumen.

Puede usar el diccionario de datos o las vistas de esquema de información para generar SQL para crear las tablas si tiene una gran cantidad de estos resúmenes o si desea cambiarlos con frecuencia.

Sin embargo, creo que no es probable que las cambies muy a menudo, por lo que la generación automática de las definiciones de vista podría no valer la pena.

Answer 3

Si usa MS SQL Server, puede probar un UDF en línea que es lo más cercano a un vista parametrizada a medida que se obtiene.