Consejos para un mejor diseño de base de datos

A lo largo de los años, trabajando como modelador de datos y arquitecto de bases de datos, me di cuenta de que hay un par de reglas que se deben seguir durante el desarrollo y el modelado de datos. Aquí describo algunos consejos con la esperanza de que puedan ayudarte. He enumerado los consejos en el orden en que ocurren durante el ciclo de vida del proyecto en lugar de enumerarlos por importancia o por lo comunes que son.

1. Planifique con anticipación

No planear es planear fallar.

Alan Lakein

Un problema que he visto es cuando el modelado de datos ocurre al mismo tiempo que el desarrollo de software. Esto es como construir los cimientos antes de completar los planos. En el pasado, la planificación parecía un paso obvio antes de iniciar el desarrollo. Los equipos de desarrollo no crearían bases de datos sin planificación, al igual que los arquitectos no construirían edificios sin planos.

En el desarrollo de aplicaciones, es fundamental comprender la naturaleza de los datos.

La planificación a menudo se ignora para que los desarrolladores puedan simplemente "comenzar a codificar". El proyecto comienza y cuando surgen problemas, no hay demora en el cronograma para abordarlos. Los desarrolladores toman atajos con la intención de corregirlos más tarde, pero esto rara vez sucede.

La planificación cuidadosa es cómo asegurarse de que termine con una base de datos adecuada que no se piratee. Si no dedica el tiempo y el esfuerzo por adelantado a abordar los datos requeridos por los procesos, lo pagará más tarde con una base de datos que debe volver a trabajarse, reemplazarse o desecharse.

Incluso si no siempre se realiza la planificación, muchos modeladores de datos aún siguen estas pautas. Eso no quiere decir que podamos predecir cada necesidad de diseño por adelantado, pero la mayoría de los modeladores creen que vale la pena el esfuerzo de comprender los datos y su uso. No desearía un diseño para el procesamiento de transacciones cuando lo que se necesita es la creación de informes analíticos.

Los tiempos han cambiado; Las metodologías ágiles son más frecuentes, por lo que los equipos de bases de datos deben repensar su enfoque del modelado de datos. En Agile, se utiliza el modelo de dominio de los casos de uso en lugar de los diagramas de relación de entidad. Sin embargo, la necesidad de planificación no ha disminuido. Necesitamos entender los datos y lo que se supone que deben hacer. En general, los primeros Sprints deben centrarse en el diseño de datos.

Por lo tanto, Agile no es el problema para los modeladores de bases de datos, sino las personas que no comprenden la naturaleza de los datos. Algunos ven el desarrollo de bases de datos como lo mismo que el desarrollo de aplicaciones. El modelado de bases de datos y el desarrollo de software son diferentes y necesitan un enfoque adecuado.

La base de datos es el núcleo de la mayoría de las aplicaciones de software. Debe tomarse el tiempo para analizar los requisitos y cómo los cumplirá el modelo de datos. Esto disminuye la posibilidad de que el desarrollo pierda rumbo y dirección.

Los desarrolladores deben comprender la importancia de los datos y su contribución al proceso de desarrollo. Vivimos en la era de la información. Las aplicaciones muestran y manipulan datos. Es la información contenida en los datos la que da sentido a la aplicación.

No es posible prever todos los requisitos ni todos los problemas, pero es importante prepararse para los problemas mediante una planificación cuidadosa.

2. Documente su modelo

Al hacer un modelo de datos, todo parece obvio. Nombras los objetos para que su propósito sea evidente y todos entiendan el significado con solo leer el nombre. Esto puede ser cierto, pero no es tan obvio como podría pensar. Al elegir nombres para tablas y columnas, aclare cuál será el uso de cada objeto. Con el tiempo, el significado de los objetos no estará claro sin documentación.

El uso de una convención de nomenclatura es un paso hacia una documentación eficaz. Cuando tenga que hacer cambios en el futuro, apreciará cualquier documentación existente. Un documento breve y simple que describa las decisiones que tomó y describa el diseño ayudará a explicar la elección de diseño en ese momento.

Desea suficiente documentación para que un nuevo administrador pueda administrar la base de datos y pueda comprender el significado sin tener que volver a pedirle una explicación. Si el modelo de datos y el entorno no están documentados, es difícil mantenerlo o cambiarlo a medida que cambian los requisitos.

Hasta cierto punto, la documentación tiene poco que ver con el modelado de datos. La documentación consiste en comunicar el diseño y hacerlo comprensible en el futuro.

La documentación es a menudo una idea de último momento. Cuando los horarios son cortos, la documentación se ignora. Sin embargo, esta es una deuda técnica con un alto costo. Tomar atajos durante el ciclo de desarrollo acumulará costos en el futuro por cambios en la base de datos, identificación de problemas, seguimiento de errores y por comprender el modelo de datos y la naturaleza de los datos.

Como ejemplo, los modelos de datos a menudo tienen un campo de "ID" como clave principal para una tabla o una parte del nombre de una clave. Esta podría ser una clave principal como TransactionID en la Transaction mesa. Si algunas tablas usan "Número" como parte del nombre de una clave, entonces es bueno documentar por qué. Quizás ReferenceNumber se usa como el nombre de la clave principal en el mensaje porque así se llama la referencia en el área comercial. Por ejemplo, en los servicios financieros, los mensajes financieros suelen incluir un número de referencia.

Documentar la definición de tablas, columnas y relaciones para que los programadores puedan acceder a la información. La documentación debe describir las expectativas de la estructura de la base de datos.

En la herramienta Vertabelo, puedo incluir inmediatamente comentarios sobre cualquier elemento:tablas, columnas, referencias, claves alternativas, lo que significa que la documentación se almacena inmediatamente con mi modelo en lugar de en algún documento adicional para mantenerlo por separado.

La documentación deficiente o ausente a menudo se debe a un pensamiento miope, pero no ignore su importancia. Este es todavía un problema que debe abordarse.

3. Seguir convenciones

Las convenciones de nomenclatura pueden no parecer importantes durante el diseño. En realidad, los nombres brindan la perspectiva para comprender un modelo. Son una introducción y deben ser lógicos.

Los nombres inconsistentes no sirven para nada. Solo frustra a los desarrolladores que deben acceder a los datos, a los administradores de la base de datos y a los modeladores que deben realizar cambios en el futuro.

Cuando se usa "ID" para algunas claves artificiales, pero algunas tablas usan una convención de nomenclatura diferente (como Número), los desarrolladores, analistas y administradores de bases de datos pueden perder tiempo para comprender las excepciones. Las convenciones de nomenclatura débiles también conducen a errores en el desarrollo porque la nomenclatura no es consistente.

De la mano con la documentación, el uso de una convención de nomenclatura hace que en el futuro alguien entienda el modelo. No cambie aleatoriamente entre el uso de "ID" (como CustomerID ) y “Número” (AccountNumber ) como claves para las tablas. Sólo haga excepciones a las convenciones cuando estén justificadas. Documente cuál es la excepción y por qué no se respeta la convención.

Lo mismo se aplica a los nombres crípticos como "XRT1":¿son las tablas de referencia extendidas? Tu invitado es tan bueno como el mío. Espero que el diseñador supiera por qué eligió un nombre tan críptico, pero dudo que la próxima persona que acceda a la base de datos pueda adivinar el motivo.

Las convenciones de nomenclatura son una cuestión de elección personal. Asegúrese de que las decisiones sean coherentes y estén documentadas.

Si logré convencerlo de aplicar la convención de nomenclatura en el diseño de su base de datos, siéntase libre de leer mi próximo artículo completamente dedicado a este tema.

4. Piense cuidadosamente en las llaves

Las claves a menudo generan controversia:claves primarias, claves externas y claves artificiales. Las tablas necesitan una clave principal que identifique cada fila. El arte es decidir qué columnas deben ser parte de la clave principal y qué valores incluir.

Para una correcta normalización, cada tabla necesita una clave de identificación. La singularidad debe estar garantizada. Sin embargo, las claves naturales y las claves primarias no tienen por qué ser iguales. De hecho, es posible que no lo sean, siempre que la tabla tenga una clave natural.

Algunos modeladores de datos prefieren una clave artificial para la unicidad. Sin embargo, algunos modeladores prefieren una clave natural para garantizar la integridad de los datos.

Entonces, ¿deberíamos usar una clave natural como clave principal? Surge un desafío si se debe cambiar la clave natural. Si la clave natural consta de muchas columnas, es posible que deba realizar cambios en muchos lugares. Otro desafío es usar una clave artificial como única clave para una tabla.

Como ejemplo, puede tener una tabla que almacene información sobre productos. La tabla se puede definir con una clave artificial como una secuencia, un código para el nombre alfabético corto del producto y la definición del producto. Si la unicidad está garantizada solo por la clave artificial, puede haber dos filas con el mismo código de producto. ¿Son estos el mismo producto que se ingresa dos veces? Quizás una llave con el código del producto sea más apropiada.

5. Utilice las comprobaciones de integridad con cuidado

Para garantizar la integridad de los datos, necesitamos claves externas y restricciones. Tenga cuidado de no abusar o infrautilizar estas comprobaciones de integridad.

Las tablas de dominio son efectivas para hacer cumplir la integridad. Las tablas de dominio funcionan bien cuando hay muchos valores que comparar o cuando los valores que se comprueban cambian con frecuencia.

Un problema puede ser que los desarrolladores decidan que la aplicación verificará la integridad. El problema aquí es que muchas aplicaciones pueden acceder a una base de datos central. Además, generalmente desea proteger los datos donde están:en la base de datos.

Si los valores posibles son limitados o están dentro de un rango, entonces puede ser preferible una restricción de verificación. Digamos que los mensajes se definen como entrantes o salientes, en cuyo caso no hay necesidad de una clave externa. Pero, para algo como las monedas válidas, si bien pueden parecer estáticas, en realidad cambian de vez en cuando. Los países se unen a una unión monetaria y las monedas cambian.

Las aplicaciones también deben realizar comprobaciones de integridad, pero no confíe solo en la aplicación para la comprobación de integridad. La definición de reglas de integridad en la base de datos garantiza que esas reglas nunca se infrinjan. De esta forma, los datos cumplen en todo momento las reglas de integridad definidas.

6. No olvide los índices en su diseño

Algunos diseños de indexación son útiles durante el modelado de la base de datos, incluso si los índices pueden cambiar durante la implementación y el uso reales. Por supuesto, es posible tener demasiados índices, al igual que es posible tener muy pocos.

La indexación es un proceso continuo. Durante el diseño, inicia el proceso en su modelo. El trabajo de diseño se basa en las claves principales y las restricciones.

Los índices son importantes cuando se consideran consultas sobre los datos. Al modelar, debe considerar cómo se consultarán los datos. Tenga cuidado de no sobre indexar. La indexación gira en torno a la optimización de consultas.

7. Evite las tablas de búsqueda comunes

A menudo he visto una tabla de búsqueda común para pares de atributos. Se percibe que la definición de una única tabla de dominio genérica simplifica el diseño. Este estilo de tabla de dominio hace una definición abstracta para contener texto. Escuché que se llama tabla de "Valor permitido" o "Valores válidos", pero el término tabla "MUCK" se acuñó para este antipatrón en 2006:Clave de código unificada masivamente.

Las tablas MUCK contienen datos no relacionados.

Por ejemplo, podría tener una tabla que defina el dominio, la entrada y una descripción. Volviendo al ejemplo de mensaje anterior, dos entradas podrían ser:

Ahora agregue entradas para otro dominio:

Esto es solo un desastre. ¿Qué significa la tabla?

Solo por diversión, modelé un ejemplo simple de una tabla MUCK (o OTLT, "One True Lookup Table" si eres fanático de Tolkien) e incluí algunos comentarios. Tenga en cuenta que este es un antipatrón y no le recomiendo que lo use en su modelo de datos.

Con las tablas MUCK, no se pueden definir restricciones. Los MUCK pueden convertirse en muchas filas sin ningún significado. Cuando debe consultar otra tabla para comprender el significado de un campo, esto no es lo ideal.

Estas tablas de "todo vale" hacen que las comprobaciones de integridad sean complejas o incluso imposibles. Una razón por la que se pueden crear estas tablas es porque varias tablas dentro de la base de datos tienen una definición similar. Entonces, las comprobaciones de integridad de los datos se vuelven imposibles. Además, su tamaño puede volverse bastante grande.

La normalización debería alejarse de las tablas MUCK. Una sola tabla debe representar un solo dominio; en lugar de una sola tabla (MUCK) que represente todos los dominios. Sin tablas MUCK, podemos implementar restricciones de clave externa.

Use tablas separadas para objetos de dominio en lugar de agruparlos en una sola tabla. Esto permite tipos de columnas, restricciones y relaciones adecuadas. Una tabla de "Valores permitidos" es pura basura y no tiene cabida en un modelo de datos.

8. Definir una estrategia de archivo

Con demasiada frecuencia, he visto bases de datos creadas sin una estrategia adecuada de retención y archivo de datos. ¿Cuánto tiempo se mantendrán los datos disponibles en línea en las tablas de bases de datos activas? La mayoría de los sistemas están diseñados para mantener los datos en la base de datos "para siempre". Para la mayoría de los sistemas, esta no es una estrategia razonable de retención de datos a largo plazo. En algún momento, los datos activos deben archivarse.

Un enfoque que defiendo es incluir la retención de datos como parte de sus consideraciones de diseño. ¿Tendrá tablas activas e históricas para que las inserciones de nuevas filas en las tablas activas se mantengan rápidas, mientras que las búsquedas en datos históricos se pueden optimizar?

Esto evita tener que rediseñar el archivo en su base de datos además del diseño original.

9. Pruebe temprano, pruebe con frecuencia

Parafraseando a Al Capone (o John Van Buren, hijo del octavo presidente de los EE. UU.), "prueba temprano, prueba a menudo". De esta manera, sigues el camino de la Integración Continua. Las pruebas en una etapa temprana de desarrollo ahorran tiempo y dinero.

La prueba es siempre un desafío en el plan de desarrollo. A menudo hay una fase de prueba al final de un Agile Sprint y una prueba del sistema al final del desarrollo. Las pruebas son generalmente lo primero que se exprime cuando se acorta el tiempo.

Al probar la base de datos, el objetivo debe ser simular un entorno de producción:"Un día en la vida de la base de datos". ¿Qué volúmenes se pueden esperar? ¿Qué interacciones de usuario son probables? ¿Se están manejando los casos límite?

Por lo tanto, el plan de prueba y las pruebas adecuadas deben ser una parte integral del modelado de datos y el desarrollo de la base de datos.

Conclusión

Estos son los principales problemas que he visto al trabajar con modeladores de datos y revisar modelos de datos. Al prestar atención a estos consejos, su base de datos estará mejor diseñada y será más sólida. Sin embargo, la recuperación de algunas de estas inversiones no siempre es obvia o visible. ¡Planifique, documente, use estándares, cree claves, asegure la integridad, realice indexación, evite MUCK, desarrolle estrategias y PRUEBE!

Ninguna de estas actividades llevará una enorme cantidad de tiempo y, sin embargo, tendrá un enorme impacto en la calidad de su modelo de datos.

¿Cuál es su opinión sobre estos consejos?

¿Tienes tus propios consejos?