Autor: ISC. Alejandro Humarán Santiago
alejandro.humaran@sepdf.gob.mx
04/11/2016
Objetivo
El objetivo de este documento es adoptar buenas prácticas y estandarizar la nomenclatura utilizada en el diseño y mantenimiento de bases de datos.
Por defecto todas las indicaciones que se presentan aplican a todos los manejadores de bases de datos a menos que se especifique lo contrario.
Audiencia
Este documento se encuentra dirigido a programadores, analistas, jefes de proyecto y especialistas técnicos de desarrollo, que tengan entre sus tareas realizar el diseño o mantenimiento de una base de datos.
Fuentes utilizadas
Entre las fuentes utilizadas para la creación de este documento se encuentran diferentes publicaciones sobre nomenclatura de base de datos, las cuales son referenciadas en la sección de bibliografía.
Condiciones de uso de este documento
Una regla puede romperse sólo ante razones justificadas, discutidas, con previa autorización del responsable del producto, y en caso que no pueda aplicarse ninguna alternativa razonable. El autor de la excepción, obligatoriamente debe documentar el código explicando la causa de la violación de la regla.
Las preferencias personales no se consideran una razón justificada.
Alejandro HUmarán
Convenciones utilizadas en este documento
| Abreviaciones | Descripción |
| OBL | Obligatorio |
| REC | Recomendado |
| Negrita | Texto con énfasis adicional que debe ser considerado importante. |
| Siempre | Indica que esta regla DEBE ser respetada, en los términos de este manual. |
| Nunca | Indica que esta acción NO DEBE ser realizada, en los términos de este manual. |
| No hacer | Indica que esta acción NO DEBE ser realizada, en los términos de este manual. |
| Evitar | Indica que esta práctica debe ser evitada siempre que sea posible, pero pueden existir excepciones AUTORIZADAS para su utilización. |
| Intentar | Indica que esta práctica debe aplicarse siempre que sea posible y apropiado. |
| Razón | Explica el propósito y las causas que motivan la regla o recomendación. |
.Convenciones de nomenclatura
Guías genéricas y buenas prácticas
- OBLIGADO – Utilizar nombres en español para todos los elementos de la base de datos, tablas, vistas, campos, etc.
- RECOMENDADO – Utilizar nombres descriptivos para los campos. Utilizar nombres que resulten intuitivos y permitan entender el significado de los campos (mnemotécnicos). Evitar las abreviaciones, y si esto no es posible documentarlas bien.
- OBLIGADO – Utilizar solo mayúsculas para nombrar los elementos de la base de datos, schemas, tablas y campos.
- RECOMENDADO – Usar el mismo nombre del campo en las diferentes tablas que lo referencien (no cambiarles el nombre). La forma en que se nombran iguales propiedades debe ser consistente en todo un esquema. Ejemplo: Nombrar al campo clave de la tabla Customers como Id, y después referenciarlo en otras tablas como CustomerId es INCORRECTO. El campo debe ser nombrado CustomerId en todos los casos que se quiera almacenar una clave de Customers.
- RECOMENDADO – Evitar tener demasiadas columnas NULLABLES en una tabla. Esto es indicio de un esquema poco o nada normalizado. Falta de normalización puede conllevar problemas de consistencia en los datos en la medida que un mismo campo se puede terminar almacenando en varias tablas. Excesiva normalización puede tener asociada una perdida de performance en ciertas operaciones sobre la base de datos. Es necesario encontrar el equilibrio correspondiente a los requerimientos de cada proyecto en este punto. Como regla general la tercera forma normal es un buen punto intermedio.
- RECOMENDADO – Evitar tener tablas sin definición de primary keys.
- RECOMENTADO – Usar claves primarias subrogadas numéricas siempre que sea posible, en lugar de claves primarias naturales. Es decir utilizar un ID Numérico en lugar de un atributo de negocio que identifique la identidad.
- RECOMENDADO – Evitar tener tablas innecesarias en el sistema. Un buen diseño es uno simple (keep it simple).
- RECOMENDADO – Intentar evitar el uso de código propietario en la definición de expresiones SQL.. Intentar utilizar código Standard SQL-92.
Nomenclatura para los elementos de una base de datos
En esta sección se presenta la nomenclatura definida para los distintos elementos de una base de datos.
La base de datos o schema
Los schemas deberán nombrarse usando la siguiente:
NOMECLATURA: EMPRESA_SOLUCIÓN_MÓDULO_AUX
Donde:
- EMPRESA, será el mismo prefijo para todos los proyectos de la empresa, no debe ser mayor a tres letras .
- SOLUCIÓN representa una SOLUCIÓN de nivel macro completo, no debe ser mayor a dos letras.
- MÓDULO se reserva para diferenciar un módulo correspondiente a una misma solución, el cual no deberá ser mayor a seis letras.
Tablas
Las tablas deberán nombrarse usando la siguiente:
- <SOLUCION>_<NOMBRE_DE_LA_TABLA>S
- <SOLUCION>_<AGRUPACIÓN LÓGICA>_<NOMBRE_DE_LA_TABLA>S
Donde:
- La tabla debe nombrarse en plural;
- Iniciando con la nomenclatura de la Solución seguido de guion bajo;
- Sin utilizar espacios en blanco;
- Si el nombre es compuesto solo la última palabra debe ir en plural
- Deben nombrarse con notación Underscore Separated, en mayúsculas.
- En aquellos escenarios en donde se quiera agrupar tablas según cierta lógica del negocio se puede agregar un prefijo que permita esto.