Buenas Practicas Diseño/Modelado Base de Datos

Para crear las entidades en una base de datos debe ser consistente y utilizar un estándar en la definición de los objetos y sus atributos; lo cual le permitira autodocumentar la base de datos, facilitar el mantenimiento y la correcta interpretación del sistema base de datos. Aquí algunas buenas practicas:  

Tablas.

1. Usar nombres en singular para las tablas ejemplo: Equipo, Proveedor, Cliente, Factura etc. La tabla representa una colección de registros pero no es necesario usar nombres en plural.
2. No incluya espacios en los nombres de la tablas.
3. La longitud del nombre de una tabla no debería superar los 30 caracteres
4. No use prefijos innecesarios  tales como TblCliente, o ProveedorTabla, etc.
5. Usar nombres consistentes y bien definidos para los atributos de una tabla (campos) por ejemplo: nombre, apellido, fecha_nacimiento, identificacion,
6. Todo registro de una tabla debe tener un ID único para identificar sin ambigüedad un registro y facilitar su ubicación y gestión del mismo (consultar, editar, eliminar)
7. Usar enteros como identificadores (campos claves) para todas la tablas. (Una columna con tipo varchar puede causar problemas de rendimiento)
8. Al definir y nombrar llaves primarias y foráneas utilice el nombre de la tabla origen y el elemento: _id al final, lo cual le recuerda que se trata de un campo clave por ejemplo: una llave primaria para la tabla cliente sería cliente_id, y una llave foránea dentro de la tabla cliente podría ser departamento_id, esta llave nos recuerda que el campo relacionado viene de la tabla maestra departamento.
9. Generación de llave primaria (PK). Confíe la generación de las claves primarias al motor de la base de datos y libere al programador de la dura carga de mantener y generar claves primarias, por cada tabla en la base de datos puede generar una secuencia ó consecutivo que el motor de base de datos asignará automáticamente al campo clave mediante un disparador. (trigger) .
• El manejo de claves únicas externas como la identificación ó DNI de una persona, el NIT de un proveedor debe ser único y obligatorio (not null) en la tabla que lo requiere.
• Para claves externas utilice el tipo de dato como carácter, ó varchar el cual le permitirá contener caracteres especiales como guion, espacio en blanco, letras etc.
• La identificación única de un cliente, persona, proveedor debería estar en un solo lugar dentro de la base de datos lo cual permitirá hacer mantenimiento fácilmente.
10. Utilizar constraints para llaves foraneas, checks, valores no nulos, unicos etc para controlar la integridad de los datos. (No depender del control desde el código de la aplicación)
11. Mediante una herramienta generar el diagrama entidad relacion (E-R) y el diccionario de datos del sistema.
12. Imágenes y columnas de tipo blob no deben estar definidas en las tablas utilizadas frecuentemente para evitar problemas de rendimiento.  Estos datos deben ser puestos en tablas separadas relacionadas por un identificador. (una buena opción es alojar las imágenes en un directorio en filesystem y referenciarlas en una columna de una tabla)

Invertir tiempo para diseñar la base de datos, será tiempo que gana en la implementación del sistema, (mínimos cambios en versiones superiores y facilidad de escalamiento)

El modelado lógico de datos: involucra las entidades, atributos y relaciones específicas que participan en una función de negocios, sirve como base para la creación del modelo de datos físico.

Créditos:

Cesar Berrio, versión 1.0, -Agosto 2017-

imagen: HR Oracle, esquema ejemplo.