Cuando un proyecto de virtualización de datos en Denodo empieza a crecer, pasas de tener una decena de vistas a tener cientos. Y si no hay una convención de nombres clara desde el principio, acabas con un catálogo donde nadie sabe qué vista es segura para consultar, cuál es solo un paso intermedio, y cuál es la que realmente hay que conectar. Esto es la convención que uso yo para evitar ese caos.
Por qué importa la nomenclatura
Denodo permite construir capas de vistas unas encima de otras: una vista puede leer de otra, que a su vez lee de otra, y así sucesivamente. Esto es una de sus mayores ventajas — puedes separar la lógica de negocio de la fuente de datos — pero también es su mayor riesgo si no se documenta bien. Sin una convención, un consumidor de datos puede acabar conectándose directamente a una vista técnica intermedia, saltándose la lógica de negocio o la caché, y generando informes con datos incorrectos o consultas lentísimas.
Una buena convención de nombres no es una cuestión estética: es la diferencia entre un catálogo de datos autoexplicativo y una capa de gobierno real, o una lista de cientos de vistas donde nadie se atreve a tocar nada por miedo a romper algo.
La arquitectura por capas
Antes de hablar de nombres, hace falta tener claras las capas. Esta es la estructura que suelo aplicar, de la fuente de datos hasta el consumidor final:
La capa más cercana a la fuente. Es prácticamente un espejo de la tabla o el servicio origen, sin transformaciones de negocio. Nadie fuera del equipo de datos debería consultarla directamente.
Aquí vive la lógica de negocio: joins, cálculos, tokenización de datos sensibles, renombrado de campos técnicos a nombres de negocio. Es la capa donde de verdad se transforma el dato.
Cuando una derived view tiene campos anidados (arrays, estructuras), esta capa se limita a aplanarlos. No añade lógica de negocio nueva — solo adapta la forma del dato para que sea consultable de forma más sencilla.
Un simple SELECT sobre la flatten view cuyo único propósito es activar la caché de Denodo sobre ella. No se consulta directamente: existe solo para que Denodo materialice los datos.
La única vista pensada para que la consulten los consumidores de negocio: informes de Power BI, otras aplicaciones, analistas. Lee de la capa de caché, pero se renombra con un nombre de negocio limpio, sin prefijos técnicos.
Ejemplo con un dominio genérico
Imagina que estás modelando datos de pedidos. La cadena de vistas, siguiendo esta convención, quedaría así:
| Vista | Capa | Qué hace |
|---|---|---|
| bv_pedidos | Base | Espejo de la tabla origen de pedidos, sin transformar. |
| dv_pedidos_enriquecido | Derived | Añade lógica de negocio: cálculo de importes, cruces con clientes, tokenización de datos sensibles. |
| f_dv_pedidos_enriquecido | Flatten | Aplana los campos anidados de la derived view (por ejemplo, un array de líneas de pedido). |
| p_f_pedidos_cache | Cache | Activa la caché de Denodo sobre la flatten view. No se consulta directamente. |
| pedidos | Final | La vista de negocio, sin prefijo, lista para conectar desde Power BI o cualquier informe. |
Consejos prácticos
- Documenta la convención en un sitio accesible para todo el equipo — un wiki, una carpeta de gobierno en el propio Denodo — antes de que crezca el catálogo, no después.
- Organiza las carpetas de Denodo por dominio de negocio (pedidos, clientes, facturación…), no por capa técnica. La capa ya la indica el prefijo.
- Nunca expongas las capas intermedias (bv_, dv_, f_, p_) a los consumidores finales. Restringe permisos si es necesario para que solo puedan conectarse a las vistas finales.
- Cuando definas la caché, decide bien qué campo usarás como clave de carga incremental (por ejemplo, un identificador único o un campo de fecha) para no tener que recargar todo el histórico cada vez.
- Revisa la convención cada cierto tiempo con el equipo. Una convención que nadie sigue es peor que no tener ninguna.
¿Ya tienes clara la nomenclatura? El siguiente paso es decidir qué modo de caché usar en cada capa.
Leer el artículo sobre caché en Denodo