4 recomendaciones

Desgraciadamente la imagen que acompaña a esta entrada será familiar para casi todos. Pero no es algo exclusivo de Windows. Las aplicaciones informáticas fallan más de lo razonable.

 

Pero no debería ser así. No hay programa informático que se merezca ese nombre que no lleve aparejado una planificación similar a la que se utiliza para, por ejemplo, levantar un edificio.. Desde la recogida de requisitos del cliente hasta las pruebas de carga que se realizan con el producto ya terminado todo debería estar documentado y preparado de antemano, ejecutado con exactitud y revisado posteriormente.

 

Uno de los puntos más críticos es el diseño de la base de datos que tendrá organizada toda la información que posteriormente servirá para la explotación de la aplicación.

 

 

 

Un error en este diseño es mucho más grave que un fallo de en la programación. Mientras que un bug generado por un programador descuidado conlleva un parche o un retraso, una base de datos mal estructurada puede hundir toda la aplicación. Sencillamente no podrá hacer aquello para lo que fué diseñada.

 

Para evitar esto las bases de datos deben cumplir un conjunto de requisitos entre los que se encuentran los denominados como formas normales, Son un conjunto de condiciones acumulativas que nos permiten ir confirmando que posteriormente esa base de datos podrá ser usada de forma coherente por los diferentes conjuntos de programas.

 

Sin embargo no es suficiente. Las cincos formas normales nos aseguran que la base de datos está correctamente diseñada pero no que sea totalmente operativa.

Para cumplir este último e imprescindible criterio vamos a tener que saltarnos las reglas anteriores que tan cuidadosamente hemos seguido y desnormalizar.

 

Puede que la causa esté en el propio sistema de gestión de la base de datos, o puede que sea una optimización que la realidad del negocio nos plantea como imprescindible. En cualquier caso la desnormalización puede ser tan importante como la normalización anterior.

¿Una contradicción?, realmente no. Y no es algo que ocurra sólo en el ámbito informático.

Todo esto viene a cuento de una pregunta que me hice hace poco revisando la documentación de las estrategias. He visto que tengo un fallo recurrente, y la pregunta que me he planteado es precisamente la que aparece en el encabezado de esta entrada. ¿Estoy improvisando o desnormalizando?

 

Realmente la acción es la misma, saltarse la normas que uno mismo se ha impuesto.

 

Pero tal como pasa en el caso de la desnormalización de base de datos la desnormalización en la operación en bolsa implica una mejora en la operación. Pero si en lugar de mejorar sencillamente te estás saltando la reglas no haces más que engañarte a ti mismo.

 

¿Cómo diferenciar ambas? Bueno hay una serie de criterios que suelen ir bien.

  • Primero y más importante: sólo se puede desnormalizar lo que está previamente normalizado. Si no tienes un sistema de operación en bolsa bien estructurado olvidate de las mejoras, no puede mejorar lo que todavía no tienes.

  • Segundo, no puedes cambiar ninguna regla que no domines previamente. Y dominar no es sólo conocerla, también debes tener experiencia en su aplicación. Hasta que no lleves un tiempo con tu sistema no estás en posición de cambiarlo.

  • Tercero. La desnormalización tiene que tener como objetivo solventar un problema previo no simplificar tu trabajo o sumar algún concepto novedoso. Dicho de otra manera, no arregles lo que funciona bien.

  • Y cuarto. La solución aplicada debe mejorar los resultados y además no debe ser un problema en si misma . Y esto último es más habitual de lo que podría parecer. Cuando partes de un sistema estable no es fácil cambiar algo sin que algún otro elemento se resienta.

 

Improvisar es fácil, desnormalizar no. Para improvisar no tienes que tener ningún requisito previo. Pero para mejorar un sistema que ya funciona te tienes que tomar un trabajo previo de análisis y otro posterior de confirmación de resultados.

 

Igual la diferencia entre ambos conceptos está en el origen de muchos fallos informáticos.

 

Hasta la próxima.

 

  1. en respuesta a David Snchz
    #2
    Theta Positivo

    Hola David.
    Es una buena pregunta.
    Si partimos de que, genéricamente, una desnormalización es un acercamiento a la realidad de la que te has distanciado por tu propia reglamentación debería ser una mejora.
    Pero el cambio tiene que ganarse su sitio en tu sistema. Si los rendimientos o tu sensación en el mercado no reflejan esa mejora, mejor quedarse como antes.

    2 recomendaciones
  2. #1
    David Snchz

    Hola Theta Positivo! ¿A la hora de desnormalizar podría darse el caso de que sea peor el remedio que la enfermedad o siempre conlleva una mejora?

    Un saludo!

4 recomendaciones
Escribe aquí tu comentario...