Denodo

Convenciones de Nombres Virtual Data Port

Contenido
Alcance del Documento ...................................................................................................................... 3
Objetivos del Documento ................................................................................................................... 3
Recomendaciones Generales .............................................................................................................. 3
Estructura de Carpetas ........................................................................................................................ 3
01 – Connectivity ............................................................................................................................. 4
01 - Data Sources......................................................................................................................... 4
02 - Base Views............................................................................................................................ 4
02 – Integration ............................................................................................................................... 4
03 – Business Entities ...................................................................................................................... 4
04 - Report Views ............................................................................................................................ 4
05- Data Services ............................................................................................................................. 5
06 - Associations.............................................................................................................................. 5
07 – JMS Listeners ........................................................................................................................... 5
08 - Stored procedures.................................................................................................................... 5
09 - Summaries................................................................................................................................ 5
Reglas del negocio al utilizar la herramienta ...................................................................................... 5
Nomenclatura de nombres para los elementos a crear en DENODO ................................................. 5
Data Sources.................................................................................................................................... 5
Base Views....................................................................................................................................... 6
Data services ................................................................................................................................... 7
Stored procedures ........................................................................................................................... 7
Alcance del Documento
Este documento va dirigido a todas las personas que van a desarrollar en la
plataforma DENODO de Ecopetrol con el fin de proponer convenciones y nomenclatura
propuestas para todos los elementos que se pueden crear como parte de una Base de
Datos Virtual.

Objetivos del Documento

Reducir el esfuerzo de lectura y comprensión de los elementos creados en las
Bases de Datos virtuales

Recomendaciones Generales

• Nombre de las Vistas y/o Atributos en minúsculas y palabras separadas por "_".
• Nombre de las Vistas usando singular (cliente, contrato, ...).
• Use el idioma original de la aplicación, use español para las vistas finales y/o los
procedimientos almacenados a los que estas aplicaciones acceden directamente.
• Usar la opción de Metadatos > Descripción para documentar los elementos en una
base de datos.
• Usar el atributo descripción campo para documentar cada atributo.
• No incluya como parte del nombre algo que dependa del entorno donde se crea el
elemento. Ejemplo (DEV – QAS - PRD)

Estructura de Carpetas
Al crear una base de datos virtual en DENODO se creará una estructura de carpetas
recomendada, en esta sección se describirá la estructura de las mismas, la nomenclatura
sugerida y una breve descripción de lo que debe contener cada una de ellas

Es importante utilizar una estructura de carpetas organizada, especialmente para

proyectos complejos, ya que ayudará a localizar elementos y tener una comprensión clara
de los diferentes elementos del proyecto.
 Se tomarán las siguientes premisas para la estructura de carpetas:

• Una carpeta por tipo de información contenida en cada una

• Carpetas adicionales para otros elementos
• En proyectos complejos, se pueden agregar subcarpetas adicionales a los
elementos relacionados con el grupo.

01 – Connectivity
Esta carpeta almacena los orígenes de datos y las vistas base del proyecto. La
misma contiene las siguientes subcarpetas:

01 - Data Sources
En esta carpeta deben alojarse las fuentes de datos relacionadas con tu proyecto.

02 - Base Views
En esta carpeta se deben alojar las vistas bases como; tablas y querys hacia las
bases de datos

02 – Integration
Las vistas de integración creadas para combinar las diferentes vistas base se
almacenan en esta carpeta. Se pueden crear subcarpetas adicionales para agrupar las
vistas de integración relacionadas.

03 – Business Entities
Las Interfaces que representan las entidades comerciales se almacenarán en este
nivel. Se pueden agregar subcarpetas adicionales. Las vistas de implementación, puesto
que no van a ser accedidas directamente por la aplicación cliente, pueden estar en el nivel
de integración.

04 - Report Views
Las interfaces que representan los informes prediseñados publicados en la
aplicación final se almacenarán en esta carpeta.
05- Data Services
Esta carpeta almacena servicios de datos

06 - Associations
Esta carpeta almacena asociaciones.

07 – JMS Listeners
Esta carpeta almacena los JMS listeners (Java Message Service)

08 - Stored procedures
Esta carpeta almacena procedimientos almacenados personalizados desarrollados
con la API de VDP.

09 - Summaries
Esta carpeta almacena resúmenes.

Reglas del negocio al utilizar la herramienta

• Se deben respetar los pasos y promociones entre ambientes, se debe aprovechar
la virtualización.
• No se puede dar la administración total sobre la plataforma (solo en casos que lo
amerite)

Nomenclatura de nombres para los elementos a crear en DENODO

Las fuentes de datos se pueden nombrar de la siguiente manera:

Data Sources
Las fuentes de datos se identificarán con una nomenclatura definida en tres niveles

Nivel 1: Prefijo (ds) que indica que es una fuente de datos

Nivel 2: Abreviatura del Manejador de bases de datos (Estos son algunos de los más
comunes)
Microsoft SQL Server: sql
Oracle: ora
MySql: msql
PostgreSQL: pgsql
SAP HANA: hana
Synapse: syn

Nivel 3: Indica el nombre de la base de Datos

Por ejemplo:
■ ds_sql_pozos
■ ds_syn_productos
■ ds_hana_facturacion

Se debe evitar utilizar nombres largos para esta nomenclatura, (se recomienda 14
caracteres como máximo)

Base Views
Las vistas bases deben describirse de la siguiente forma:

Nivel 1: Prefijo (bv) que identifica que es una vista base

Nivel 2: Nombre de la fuente de datos, el nombre del origen de datos sobre el que se crea
la vista base, Eliminando el prefijo (ds)

Nivel 3: Nombre de la tabla, el procedimiento almacenado o cualquier texto descriptivo

para identificar qué se importa desde la fuente de datos

Nivel 4: Sufijo que identifica el tipo de objeto que se está importando

Tabla: (_t)

Query: (_q)
Vista: (_v)

Procedimiento: (_p)

Ejemplo:

bv_hana_perforacion_pozo_t

Data services
El nombre del servicio web puede ser un nombre del negocio, un concepto del
negocio o un proceso de negocio.

La denominación de estos elementos depende de las convenciones de

nomenclatura que se describe en este documento.

Los nombres de las operaciones de servicios web deben ser similares a la vista que
implementa

Al nombrar un Data services debe describirse de la siguiente manera:

Nivel 1: Método de la petición HTTP para indicar la acción que se desea realizar para un
recurso determinado (GET, POST y PUT)

Nivel 2: Vista que se implementa.

Nivel 3: Sufijo (_ws) que identifica que es un servicio web

Ejemplo: get_facturacion_ws

Stored procedures
Al nombrar un Stored procedures debe describirse de la siguiente manera:

Nivel 1: Prefijo que identifica que es un Stored procedures

(sp_)
Nivel 2: Nombre descriptivo del procedimiento almacenado