Mejores prácticas de diseño de bases de datos para aplicaciones de alto rendimiento

Para que una aplicación tenga un buen rendimiento, se necesita un servidor de aplicaciones potente, un ancho de banda amplio y garantizado y un trabajo de programación bien hecho. Pero hay un aspecto que no siempre se tiene en cuenta y que suele tener un gran impacto en el rendimiento de cualquier aplicación: el diseño de la base de datos.

A continuación analizaremos las mejores prácticas de diseño de bases de datos para garantizar que el acceso a los datos no sea un cuello de botella que afecte negativamente al rendimiento de la aplicación.

¿Cuál es el propósito de un buen diseño de la base de datos?

Además de mejorar el rendimiento del acceso a los datos, un buen diseño consigue otros beneficios, como mantener la coherencia, precisión y fiabilidad de los datos y reducir el espacio de almacenamiento eliminando redundancias. Otro beneficio de un buen diseño es que la base de datos es más fácil de utilizar y mantener. Cualquiera que tenga que gestionarla sólo tendrá que echar un vistazo al diagrama entidad-relación (ERD) para comprender su estructura.

Los ERD son la herramienta fundamental del diseño de bases de datos. Pueden crearse y visualizarse en tres niveles de diseño: conceptual, lógico y físico.

El diseño conceptual muestra un diagrama muy resumido, con sólo los elementos necesarios para acordar criterios con las partes interesadas del proyecto, que no necesitan comprender los detalles técnicos de la base de datos. El diseño lógico muestra las entidades y sus relaciones en detalle, pero de forma agnóstica a la base de datos.

Hay muchas herramientas que puede utilizar para facilitar el diseño de bases de datos a partir de ERD. Entre las mejores se encuentran DbSchema, SqlDBM y Vertabelo.

DbSchema

DbSchema le permite diseñar y gestionar visualmente bases de datos SQL, NoSQL o en la nube. La herramienta permite diseñar el esquema en un ordenador y desplegarlo en múltiples bases de datos, así como generar documentación en diagramas HTML5, escribir consultas y explorar visualmente los datos, entre otras cosas. También ofrece sincronización de esquemas, generación de datos aleatorios y edición de código SQL con autocompletado.

SqlDBM

SqlDBM es una de las mejores herramientas de diseño de diagramas de bases de datos porque proporciona una forma sencilla de diseñar su base de datos en cualquier navegador. No se necesita ningún otro motor de base de datos ni herramientas de modelado para utilizarla, aunque SqlDBM le permite importar un esquema de una base de datos existente. Es ideal para el trabajo en equipo, ya que permite compartir proyectos de diseño con compañeros de trabajo.

Vertabelo

Vertabelo es una herramienta visual en línea de diseño de bases de datos que le permite diseñar una base de datos de forma lógica y derivar automáticamente el esquema físico. Puede realizar ingeniería inversa, generar diagramas a partir de bases de datos existentes y controlar el acceso a los diagramas diferenciando los privilegios de acceso a propietarios, editores y visualizadores.

Por último, el diseño físico es el que añade al ERD todos los detalles necesarios para convertirlo en una base de datos utilizable en un DBMS concreto, como MySQL, MariaDB, MS SQL Server o cualquier otro. Echemos un vistazo a las mejores prácticas que hay que tener en cuenta al diseñar una ERD para que la base de datos resultante funcione al máximo.

Definir el tipo de base de datos a diseñar

Se suelen distinguir dos tipos fundamentales de bases de datos: relacionales y dimensionales.

Las bases de datos relacionales se utilizan para aplicaciones tradicionales que ejecutan transacciones sobre los datos, es decir, obtienen información de la base de datos, la procesan y almacenan los resultados.

Por otro lado, las bases de datos dimensionales se utilizan para la creación de almacenes de datos: grandes depósitos de información para el análisis de datos y la minería de datos con el fin de obtener perspectivas.

El primer paso en cualquier tarea de diseño de bases de datos es elegir uno de los dos tipos principales de bases de datos con los que se va a trabajar: relacionales o dimensionales. Es vital tener esto claro antes de empezar a diseñar. De lo contrario, puede caer fácilmente en errores de diseño que, a la larga, acarrearán muchos problemas y serán difíciles (o imposibles) de corregir.

Adoptar una convención de nombres

Los nombres utilizados en el diseño de la base de datos son esenciales porque, una vez creado un objeto en una base de datos, cambiar su nombre puede ser fatal. Cambiar sólo una letra del nombre puede romper dependencias, relaciones e incluso sistemas enteros.

Por eso es fundamental trabajar con una convención de nomenclatura saludable: un conjunto de reglas que le ahorren la molestia de probar 50 posibilidades diferentes para encontrar el nombre de un objeto que no puede recordar.

No existe una guía universal sobre cómo debe ser una convención de nomenclatura para cumplir su función. Pero lo importante es establecer una convención de nomenclatura antes de nombrar cualquiera de los objetos de una base de datos y mantener esa convención para siempre. Una convención de nomenclatura establece directrices como si se debe utilizar un guión bajo para separar las palabras o unirlas directamente, si se deben utilizar todas las letras mayúsculas o las palabras en mayúsculas (estilo Camel Case), si se deben utilizar palabras en plural o en singular para nombrar los objetos, etc.

Empiece por el diseño conceptual, luego el diseño lógico y, por último, el diseño físico.

Ese es el orden natural de las cosas. Como diseñador, puede tener la tentación de empezar creando objetos directamente en el SGBD para saltarse pasos. Pero esto le impedirá disponer de una herramienta para debatir con las partes interesadas y asegurarse de que el diseño cumple los requisitos de la empresa.

Tras el diseño conceptual, debe pasar al diseño lógico para disponer de la documentación adecuada que ayude a los programadores a comprender la estructura de la base de datos. Es vital mantener actualizado el diseño lógico para que sea independiente del motor de base de datos que se vaya a utilizar. De este modo, si con el tiempo migra la base de datos a un motor diferente, el diseño lógico seguirá siendo útil.

Por último, el diseño físico puede ser creado por los propios programadores o por un DBA, tomando el diseño lógico y añadiendo todos los detalles de implementación necesarios para implantarlo en un DBMS concreto.

Crear y mantener un diccionario de datos

Aunque un ERD sea claro y descriptivo, debe añadir un diccionario de datos para que sea aún más claro. El diccionario de datos mantiene la coherencia y la consistencia en el diseño de la base de datos, sobre todo cuando el número de objetos que la componen crece significativamente.

El objetivo principal del diccionario de datos es mantener un único repositorio de información de referencia sobre las entidades de un modelo de datos y sus atributos. El diccionario de datos debe contener los nombres de todas las entidades, los nombres de todos los atributos, sus formatos y tipos de datos, y una breve descripción de cada uno.

El diccionario de datos proporciona una guía clara y concisa de todos los elementos que componen la base de datos. Así se evita crear múltiples objetos que representan lo mismo, lo que dificulta saber a qué objeto recurrir cuando se necesita consultar o actualizar información.

Mantenga criterios coherentes para las claves primarias

La decisión de utilizar claves naturales o claves sustitutivas debe ser coherente dentro de un modelo de datos. Si las entidades de un modelo de datos tienen identificadores únicos que pueden gestionarse eficazmente como claves primarias de sus respectivas tablas, no hay necesidad de crear claves sustitutas.

Pero es habitual que las entidades se identifiquen mediante múltiples atributos de distintos tipos -fechas, números y/o largas cadenas de caracteres- que pueden resultar ineficaces para formar claves primarias. En estos casos, es mejor crear claves sustitutas de tipo numérico entero, que proporcionan la máxima eficacia en la gestión de índices. Y la clave sustituta es la única opción si una entidad carece de atributos que la identifiquen de forma exclusiva.

Utilice los tipos de datos correctos para cada atributo.

Ciertos datos nos dan la opción de elegir qué tipo de datos utilizar para representarlos. Las fechas, por ejemplo. Podemos elegir almacenarlos en campos de tipo fecha, campos de tipo fecha/hora, campos de tipo varchar o incluso campos de tipo numérico. Otro caso son los datos numéricos que no se utilizan para operaciones matemáticas, sino para identificar a una entidad, como el número de un permiso de conducir o un código postal.

En el caso de las fechas, es conveniente utilizar el tipo de datos del motor, que facilita la manipulación de los datos. Si necesita almacenar sólo la fecha de un acontecimiento sin especificar la hora, el tipo de dato a elegir será simplemente Fecha; si necesita almacenar la fecha y la hora en que se produjo un determinado acontecimiento, el tipo de dato deberá ser DateTime.

Utilizar otros tipos, como varchar o numérico, para almacenar fechas puede ser conveniente, pero sólo en casos muy particulares. Por ejemplo, si no se sabe de antemano en qué formato se expresará una fecha, es conveniente almacenarla como varchar. Si el rendimiento de la búsqueda, la ordenación o la indexación son críticos en el manejo de campos de tipo fecha, una conversión previa a float puede marcar la diferencia.

Los datos numéricos que no intervienen en operaciones matemáticas deben representarse como varchar, aplicando validaciones de formato en el registro para evitar incoherencias o repeticiones. De lo contrario, se expone al riesgo de que algunos datos superen las limitaciones de los campos numéricos y le obliguen a refactorizar un diseño cuando ya está en producción.

Uso de tablas de consulta

Algunos diseñadores inexpertos pueden creer que el uso excesivo de tablas de consulta para normalizar un diseño puede complicar innecesariamente el ERD de una base de datos porque añade un gran número de tablas «satélite» que a veces no tienen más que un puñado de elementos. Quienes piensen esto deberían comprender que el uso de tablas de consulta tiene muchas más ventajas que inconvenientes. Si la complejidad o el tamaño de un ERD suponen un problema, existen herramientas de diseño de ERD que permiten visualizar los diagramas de distintas formas para que se entiendan a pesar de su complejidad.

Esta consulta de ejemplo ilustra el uso correcto de las tablas de consulta en una base de datos bien diseñada:

SELECT
	NombreCalle
	CalleNúmero,
	Ciudades.Nombre COMO Ciudad,
	Estados.Nombre COMO Estado
DESDE
	Direcciones
	INNER JOIN Ciudades ON
		Ciudades.CityId = Direcciones.CityId
	INNER JOIN Estados ON
		Estados.IdEstado = Direcciones.IdEstado

En este caso, estamos utilizando tablas de consulta para Ciudades y Estados.

Las ventajas de las tablas de consulta son, entre otras, la reducción del tamaño de la base de datos, la mejora del rendimiento de las búsquedas y la imposición de restricciones sobre el conjunto de datos válidos que puede contener un campo. También es una buena práctica que todas las tablas de consulta incluyan un bit o un campo booleano que indique si un registro de la tabla está en uso o es obsoleto. Este campo puede utilizarse como filtro para evitar elementos obsoletos como opciones en la interfaz de usuario de la aplicación.

Normalizar o desnormalizar según el tipo de base de datos

En las bases de datos relacionales utilizadas para aplicaciones tradicionales, la normalización es imprescindible. Es bien sabido que la normalización reduce el espacio de almacenamiento necesario al evitar redundancias. Mejora la calidad de la información y proporciona múltiples herramientas para optimizar el rendimiento en consultas complejas.

Sin embargo, en otros tipos de bases de datos se aplica una técnica conocida como desnormalización. En las bases de datos dimensionales, utilizadas como almacenes de datos, la desnormalización añade cierta información redundante útil en las tablas del esquema.

Aunque parezcan conceptos opuestos, la desnormalización no significa deshacer la normalización. En realidad, es una técnica de optimización que se aplica a un modelo de datos después de normalizarlo para simplificar la escritura de consultas y la elaboración de informes.

Diseñar modelos físicos por partes

En un proyecto de desarrollo de software, el diseñador de la base de datos presenta a los interesados un modelo conceptual a gran escala, en el que no se muestran detalles de implementación. A su vez, para trabajar con los desarrolladores, el diseñador debe proporcionar un modelo físico con todos los detalles de cada entidad y atributo. Sin embargo, no es necesario que ambos modelos estén completamente creados al principio del proyecto.

Cuando se aplican metodologías ágiles, cada desarrollador toma al principio de cada ciclo de desarrollo una o varias historias de usuario con las que trabajar durante ese ciclo. El trabajo del diseñador de la base de datos consiste en proporcionar a cada desarrollador un submodelo físico que incluya sólo los objetos que necesita para una unidad de trabajo.

Al final de cada ciclo de desarrollo, los submodelos creados durante ese ciclo se fusionan para que el modelo físico completo tome forma paralelamente al desarrollo de la aplicación.

Hacer un buen uso de las vistas y los índices

Las vistas y los índices son dos herramientas fundamentales en el diseño de bases de datos para mejorar el rendimiento de las aplicaciones. El uso de vistas permite manejar abstracciones que simplifican las consultas, ocultando detalles innecesarios de las tablas. A su vez, las vistas facilitan las tareas de optimización de las consultas a los motores de bases de datos, ya que les permiten anticipar cómo se obtendrán los datos y elegir las mejores estrategias para ofrecer los resultados de las consultas con mayor rapidez.

Los índices pueden mejorar el rendimiento de una consulta lenta en función de la experiencia del usuario una vez que la base de datos está en producción. Sin embargo, la creación de índices puede realizarse como parte de las tareas de diseño de la base de datos, anticipándose a las necesidades de la aplicación.

Para la creación de índices, es necesario tener una idea aproximada de la magnitud de cada tabla -en términos de recuento de registros- y, a continuación, crear índices para las tablas más grandes. Para elegir los campos que se incluirán en un índice, debe tener en cuenta principalmente los que representan claves externas y los que se utilizarán como filtros en las búsquedas.

Cuando crea que el trabajo está terminado, es el momento de refactorizar.

El diseño de una base de datos siempre puede mejorarse. Cuando no hay cambios en la base de datos debido a nuevos requisitos o nuevas necesidades empresariales, es una buena oportunidad para llevar a cabo procedimientos de refactorización que mejoren el diseño. Refactorizar significa simplemente eso: introducir cambios que mejoren un diseño sin afectar a la semántica de la base de datos.

Existen muchas técnicas de refactorización para mejorar el diseño de una base de datos que quedan fuera del alcance de este artículo, pero es bueno conocer su existencia para utilizarlas cuando sea necesario.

Tener a mano esta lista de mejores prácticas siempre que necesite diseñar una base de datos le permitirá obtener los mejores resultados para que las aplicaciones mantengan siempre un rendimiento óptimo en el acceso a los datos.