Normalizar o no normalizar, ese es el dilema…

Comúnmente me encuentro con el debate acerca de si la normalización de bases de datos es una buena idea, o genera más problemas de los que soluciona. Mi opinión al respecto podría resumirse en los siguientes pros y contras:

·         Pros

o   Una vez alcanzada la madurez de un sistema, si la base de datos está bien normalizada, es más fácil de mantener y escalar.

o   Es más improbable que se alcancen los límites de un motor de base de datos relacional (RDMS) con un diseño normalizado que sin él.

o   Las entidades suelen ser pequeñas y mucho más manejables.

o   La normalización favorece escenarios tales como el diseño de bases de datos orientados a objetos, lo cual genera un diseño limpio y profesional de la solución.

o   La indexación de bases de datos es mucho más sencilla y lógica, además de no verse obstaculizada  por los límites del RDMS, pues el diseño en soluciones normalizadas es mucho más granulado.

o   El diseño es más lógico a pesar de su nivel de abstracción; una vez entendido resulta evidente que el diseño es más fácil de ejecutar y mantener.

·         Contras

o   En fase de análisis y diseño, cuidar la normalización implica mucho más trabajo que generar un diseño no normalizado.

o   El diseño normalizado genera una cantidad mucho más significativa de tablas que el diseño no normalizado.

o   El diseño final es mucho más abstracto y requiere más especialización.

o   Las sentencias de consulta y actualización de datos se vuelven complejas rápidamente. Además es común que la normalización implique gestión transaccional, que resulta innecesaria en escenarios no normalizados.

o   La normalización hace necesario un buen manejo de índices y claves foráneas. De otra manera el software resultante puede terminar siendo sumamente lento.

o   La normalización en sí misma, no es una solución infalible; la forma de conceptualizar las entidades en una base de datos cumple un papel vital. Una mala normalización puede ocasionar más problemas que los que soluciona.

Como con todo, al normalizar hay que saber cuándo detenerse. Pongamos por ejemplo una entidad proveedor. ¿Cuál sería su estructura básica?, imaginemos que un cliente nos ha definido que el proveedor tiene un nombre, una dirección física, un correo electrónico, datos de facturación, teléfono y fax. Esta podría ser la entidad en un esquema no normalizado:

¿Qué problemas puede representar diseñar la tabla de esta manera?, dependiendo del escenario real, de los alcances del sistema y de la potencial escalabilidad del mismo, las siguientes preguntas demuestran cómo podría volverse inútil el diseño anterior rápidamente en ciertos escenarios:

·         ¿Un proveedor solo tendrá una dirección?, puede que tenga una de embarque, otra de facturación, otra de su matríz, y otras 20 de sus sucursales, ¿cuáles de estas necesitará controlar su sistema?

·         ¿Los datos de facturación serán siempre los mismos?, ¿el proveedor no se maneja mediante diferentes empresas, cada una con una razón social?, o más complicado aun, tiene 20 marcas comerciales, y 10 razones sociales cada una de las cuales se usan por una o varias de las 20 marcas citadas…

·         ¿Solo necesitamos un teléfono del proveedor?, ¿El fax no es un teléfono también?, ¿Por qué no tener un catálogo de teléfonos asociado al proveedor?, esto no limitaría el número de teléfonos posibles y evitaría que tuviéramos campos como Telefono1, Telefono2, Telefono3, en la misma tabla.

·         En lugar de guardar el nombre de cada ciudad, estado y país del proveedor, ¿Por qué no tener un catálogo con dicha información?, si tuviéramos esta información, solo necesitaríamos almacenar los identificadores primarios del lugar asociado a cada dirección y esto facilitaría las consultas. Además las consultas basadas en llaves primarias enteras, son siempre más rápidas que las basadas en texto.

Si todo lo anterior tiene sentido o no, depende totalmente del contexto. Puede que en un sistema ERP que vaya a controlar el grueso de las operaciones de un negocio y del cual dependa su día a día, pensar así se justifique con creces, más no en un programa de utilería que va a servir para una encuesta de marketing que se piensa realizar una sola vez y cuya relevancia no es de carácter tan vital para la vida del negocio.

Normalizar es como obedecer a la máxima divide y vencerás; partir un problema en sus componentes para solucionarlo es una excelente alternativa para encontrar su solución, la decisión aquí es más bien, si el trabajo extra vale la pena versus los beneficios. Cuando vaya a tomar la decisión de normalizar o no, piense en las implicaciones de sus datos, y en qué tan difícil será después cambiar las cosas si se requieren en el futuro.

Para terminar esta reflexión, observe como puede volverse complejo el esquema si normalizamos la estructura del proveedor en sus partes:

Ahora tenemos diez entidades en lugar de una, y aun podrían ser más; observe que los datos fiscales en realidad los estamos considerando como una dirección, en la cual el campo opcional RFC es distinto de nulo. Si esto es correcto o no, depende de cómo se mire. Observe también, cómo la entidad Direcciones, almacena claves foráneas a la ciudad, estado y país de la dirección, siendo que esto es innecesario en sentido estricto. Podría solo guardar la ciudad y con ello obtener el estado y país relacionados. No obstante, en este diseño se considera que guardar estos datos de forma redundante es un buen diseño también, pues simplifica las consultas y la carga de datos en un escenario muy habitual, tal como la consulta de direcciones.

Conclusión

No hay que tomarse la normalización de datos como una regla aplicable a todos los casos. No hay que olvidar que la primera finalidad en la creación de un sistema es solucionar problemas de la vida real y existen muchas maneras de solucionarlos.

En lo personal considero que a mayor complejidad en un sistema, mayor necesidad de normalización. Si el sistema es simple y no tiene mucha relevancia ni trascendencia en la vida de una empresa, la normalización puede dificultar las cosas más de lo que las simplifica. Caso contrario, cuando un sistema es trascendente y es propenso a una escalabilidad interesante o constante, la normalización es una excelente idea pues, pese a los retos que conlleva, permite mantener todo organizado y bajo control. El esquema  no normalizado de datos, es confuso en soluciones grandes.

Por esta razón recomiendo que siempre que vaya a desarrollarse un sistema se considere su escalabilidad y mantenimiento como factores directamente asociados a la necesidad de normalización. Espero que este artículo les sirva de ayuda en su trabajo diario, nos vemos en las siguientes entregas.