La importancia de llamarse Ernesto

En el último artículo cuestionaba si seguía teniendo sentido evitar los “espacios” en el nombre de las tablas y los campos. Sea cual sea vuestra opinión, está claro que los criterios de nomenclatura son una cuestión importante que debe definirse dentro de la arquitectura DWH/BI…

He encontrado un artículo de Kimball Group que habla sobre esto, y que me parece oportuno compartir en el blog. Además también recomienda los nombres con espacio. Me he tomado la molestia de traducirlo rápidamente (disculpadme si hay alguna imprecisión…). El artículo original es este: “What’s in a name?”, y a continuación mi traducción.

¿Qué hay en un nombre?

Parece que una cosa pequeña, pero los nombres son importantes. Nombrar correctamente las tablas y columnas es particularmente importante para los usuarios que realizan consultas ad hoc al sistema DW/BI que necesitan encontrar los objetos que están buscando. Los nombres de objetos deben escogerse pensando en los usuarios de negocio no en el personal técnico.

En la medida de lo posible, intenta que los nombres del sistema DW/BI permanezcan sin cambios en la capa semántica y sin cambios para los diseñadores de informes. Más complicado todavía: Se debe desincentivar que los usuarios cambien los nombres de los objetos una vez han seleccionado la información. Por lo general, no podemos impedir que lo hagan, pero nombres atractivos pueden reducir la tentación.

Aquí están mis diez mejores sugerencias para nombrar objetos en su sistema de Business Intelligence/Data Warehouse:

1. Sigue las convenciones de nomenclatura

Si no las tienes, crea (¡y documenta!) las convenciones acorde a este articulo (Design Tip). Si tu organización ya tiene convenciones de nomenclatura, es posible que tengas un problema: las convenciones de nomenclatura existentes se han definido para los técnicos, pero los nombres en el entorno de DW/BI deben estar orientados a los usuarios de negocios. Los nombres que se seleccionen se convertirán en los nombres de los encabezados de fila y columna de consultas ad hoc y de los informes predefinidos. Volveremos a este tema más adelante.

2. Cada objeto tiene un nombre

No perpetuemos la confusión en torno a las definiciones de datos que ya existe en nuestras organizaciones. No es correcto que el equipo de ventas llame a una columna "Geografía" y que el grupo de marketing llame a la misma entidad "Región". Si se trata de la misma columna, con el mismo contenido, tiene que tener el mismo nombre. Si no puedes llegar a un acuerdo de toda la organización en los nombres de objetos, cuenta con la ayuda del patrocinador negocio.

3. Los nombres tienen que ser descriptivos

Los usuarios no deberían necesitar 20 años en la organización para descifrar lo que significa un nombre. Esta regla prohíbe un montón de tonterías, como RBVLSPCD (¡podemos utilizar más de ocho caracteres!). También prohíbe que una columna se llame "Nombre", que no es descriptivo fuera del contexto de la tabla que está examinando.

4. Se debe disuadir el uso de abreviaturas y acrónimos

Abreviaturas y acrónimo son endémicas en el mundo empresarial. Una gran cantidad de información puede ser codificada en un acrónimo, pero representa una enorme carga para los recién llegados. El método más eficaz es mantener una lista de abreviaturas aprobadas, y tratar de no añadir ninguna más sin una buena razón. Incluso puede que desee documentar la razón en la lista. Los ejemplos incluyen:

5. Los nombres deben ser bonitos

Recuerde que los nombres de los objetos se convierten en las cabeceras de informes y análisis. A pesar de que la belleza está en el ojo del espectador, encuentro que poner todas las letras en mayúscula es particularmente molesto. Los nombres de objetos deben contener una pista visual de donde terminan las palabras.

• Espacios: [Nombre de columna]
• CamelCase: NombreColumna
• Subrayado: Nombre_Columna o NOMBRE_COLUMNA

Yo recomiendo el uso de los espacios. Se ven mejor cuando se muestran en los informes. Me río de la tesis de que los desarrolladores tienen que teclaer los corchetes al escribir el nombre de la columna. Estoy seguro de que cualquier desarrollador que escribe SQL sabe donde se encuentran los corchetes en su teclado, y ya de paso pueden desarrollar los músculos de los dedos necesarios.

6. Los nombres deben ser únicos

Esta regla es un corolario de la regla de que cada objeto tiene un nombre. Si dos objetos son diferentes, deben tener nombres diferentes. Esta norma prohíbe los nombres de columna como [Ciudad]. Un nombre mejor es [Ciudad de cliente]. Esta regla es especialmente importante para el uso ad hoc del sistema de DW/BI. Aunque el contexto de [Ciudad] puede ser obvio durante el proceso analítico, una vez que el análisis se guarda y se comparte, se pierde ese contexto. ¿Estamos mirando la ciudad del cliente o de la ciudad de la tienda? ¿la dirección postal o la dirección de envío? Aunque no podemos evitar que los usuarios cambien los nombres de objeto una vez que se exportan a Excel, no queremos obligarles a hacerlo si necesitan esta claridad adicional.

7. Los nombre no deben ser muy largos

Esta norma entra en conflicto con los puntos 3, 4 y 6. Si tenemos nombres de objetos únicos, sin abreviar, y descriptivos lo más probable es que algunos nombres de columnas terminen siendo muy largos. Piensa en [Mandatory Second Payer Letter Opt Out Code] o [Vocational Provider Referral Category]. Estos son nombres de columna razonablemente descriptivos para alguien en el negocio de seguros pero, ¿Qué va a suceder cuando el usuario o diseñador de informe arrastre esa columna en el cuerpo de un informe o análisis? El nombre será poco atractivo porque el encabezado de la fila será muy largo. O utilizará un tipo de letra tan pequeña que nadie pueda leerlo. Y, finalmente, el usuario cambiará el nombre de la columna, que viola nuestra regla fundamental de que cada objeto tiene un nombre.

Yo trato de limitar los nombres de columna a 30 caracteres, aunque a veces utilizo hasta 35. Con el fin de lograr este objetivo, tengo que registrar más abreviaturas o acrónimos de los que me gustaría.

8. Valora la posibilidad de anteponer el nombre de tabla abreviado al nombre de la columna

No me gusta hacer esta recomendación, porque no cumple con varios de mis reglas anteriores sobre las abreviaturas y los nombres cortos. Pero frecuentemente me encuentro a mi mismo haciéndolo con el fin de garantizar la coherencia y la singularidad.

9. Cambia el nombre en la capa vistas si es necesario

Siempre hemos recomendado una capa de vistas en el sistema DW/BI que se coloquen sobre las tablas físicas. El propósito principal de la capa de vistas es el de proporcionar una capa de aislamiento entre las aplicaciones de BI y la base de datos física, y proporcionar un poco de flexibilidad para migrar sin problemas el cambio a un sistema que ya está en producción. Además, la capa de vistas también puede ser un lugar adecuado para poner los nombres orientados a los usuarios de negocio.

Nuestra recomendación es nombrar las tablas físicas y columnas con nombres orientado a Negocio. Si esto no puede ser, utilicemos la capa de vistas. No nos gusta cambiar el nombre en las herramientas BI por varias razones:

• La mayoría de las organizaciones tienen varias herramientas de BI; los nombres deben ser coherente en todas las herramientas de BI.
• La lógica de negocio más se pone en la herramienta de BI, más difícil será para migrar a una herramienta diferente.
• Si los nombres son sólo en la herramienta de BI, hay una barrera para la comunicación entre los usuarios, equipo de soporte habitación del frente, y la gente de base de datos trastienda.

10. ¡Sé coherente!

La necia coherencia es el duende de las mentes pequeñas. La coherencia en la nomenclatura es sumamente valiosa para sus usuarios.