XperimentoS

Con la experiencia, el diseño de una base de datos se convierte en algo casi mecánico. En el proceso de modelado aplicamos reglas y generamos diseños normalizados e incluso desnormalizados casi sin pensar a través de la información adquirida en entrevistas con las personas de negocio.

Ciertamente, un buen diseño de base de datos es crítico para cualquier proyecto, pero no siempre el fiel reflejo de la realidad es lo mejor en todos los casos.

En un proyecto se creó una base de datos para mantener la información de cierto tipo de construcciones que contenían varios elementos. Como ejemplo, contemplemos sólo 3 elementos y simplifiquemos llamándolos elementos A, B y C, donde: A está formado por n elementos B; y B está formado a su vez por n elementos C. El diseño sería:

Este modelo era totalmente correcto, pero la aplicación fracasó ya que no se utilizaba, ¿dónde está el problema?.

Durante la fase de diseño nadie se preocupo de averiguar que los datos que iban a ser almacenados fuesen mantenibles, es decir, que hubiera personas/procesos/sistemas encargadas de mantener la relación entre las entidades. Resultó que aunque en la teoría los elementos B se componían de elementos C, no era viable (por recursos humanos y coste) identificar a qué elemento B pertenecía cada elemento C, aunque sí era necesario almacenar los elementos C.

El diseño de datos fue cambiado por algo de este estilo:

Moraleja: El modelo de datos debe ser una herramienta de almacenamiento de datos mantenible por los usuarios.