¡Hola! Me llamo Andrei Semenov, soy analista senior en Sportmaster. En este post quiero plantear la cuestión de la desnormalización de bases de datos de sistemas ERP. Revisaremos las condiciones generales, así como un ejemplo concreto: digamos que será una hermosa taberna monopolista para piratas y marineros. En la que los piratas y marineros deben ser atendidos de diferentes maneras, ya que sus percepciones de lo hermoso y los patrones de consumo difieren significativamente.
¿Cómo hacer para que todos estén contentos? ¿Cómo no volverse loco al diseñar y mantener un sistema así? ¿Qué hacer si a la taberna comienzan a llegar no solo los habituales piratas y marineros?
Todo a continuación. Pero vayamos por partes.
1. Limitaciones y supuestos
Todo lo expuesto se refiere únicamente a bases de datos relacionales. No se consideran las consecuencias de la desnormalización, como las anomalías de modificación, eliminación e inserción, que están bien documentadas, incluso en Internet. Quedan fuera de esta publicación los casos en los que la desnormalización es algo común, con ejemplos clásicos: serie y número de pasaporte, fecha y hora, entre otros.
En el post se utilizan definiciones intuitivas y prácticamente aplicables de las formas normales, sin referencias a términos matemáticos. En la forma en que pueden aplicarse a la investigación de procesos de negocio reales y al diseño de software industrial.
Existe la opinión de que el diseño de almacenes de datos, herramientas para crear informes y acuerdos de integración (que utilizan una representación tabular de la información), difiere del diseño de bases de datos de sistemas ERP en que la facilidad de consumo y la aplicación de una desnormalización consciente pueden tener prioridad sobre la integridad de los datos. Comparto esta opinión, y lo que se describe a continuación se refiere exclusivamente a los modelos de datos maestros y datos transaccionales de sistemas ERP.
La explicación de las formas normales se presenta con un ejemplo que resulta comprensible para la mayoría de los lectores en un nivel cotidiano. Sin embargo, como ilustración visual, en los puntos 4-5 se utiliza deliberadamente un problema «inventado». Si no se hace esto y se toma algún ejemplo canónico, como el mismo modelo de almacenamiento de pedidos en el p. 2, se puede caer en la situación en que la atención del lector se desvíe de la descomposición del proceso propuesto al modelo, a su experiencia personal y percepción de cómo deben construirse los procesos y modelos de almacenamiento de datos en SIS. En otras palabras, tome a dos analistas de TI calificados: uno que preste servicios a logistas que transportan pasajeros, y otro a logistas que mueven máquinas para la producción de microchips. Pídales, sin discutir previamente los procesos automatizables, que formulen un modelo de datos para almacenar información sobre un viaje en tren.
Existe una probabilidad no nula de que en los modelos propuestos encuentre no solo un conjunto notablemente diferente de atributos, sino también conjuntos de entidades no coincidentes, porque cada analista se basará en los procesos y tareas que le son familiares. Y decir en tal situación cuál modelo es "correcto" es imposible, porque no hay un criterio de evaluación.
2. Formas normales
La primera forma normal de la base de datos requiere la atomicidad de todos los atributos.
En particular, si un objeto A tiene atributos no clave a y b, tales que c=f(a,b) y en la tabla que describe el objeto A almacena el valor del atributo c, entonces en la base de datos se ha violado la primera forma normal. Por ejemplo, si en la especificación del pedido se indica una cantidad cuya unidad de medida depende del tipo de producto: en un caso puede ser piezas, en otro litros, en otro paquetes compuestos por piezas (en el modelo anterior Good_count_WR), entonces en la base de datos se ha violado la atomicidad de los atributos. En este caso, para determinar cómo debe ser el conjunto de tablas de la especificación del pedido, se necesita una descripción objetiva del proceso de trabajo en SIS, y dado que los procesos pueden ser diferentes, puede haber muchas versiones "correctas".
La segunda forma normal de la base de datos requiere el cumplimiento de la primera forma y de una tabla propia para cada entidad relacionada con el proceso de trabajo en el SI. Si en una tabla existen dependencias con=f1(a) y d=f2(b) y no existe dependencia con=f3(b), entonces se ha violado la segunda forma normal en la tabla. En el ejemplo anterior, en la tabla 'Pedido' no existe dependencia entre el pedido y la dirección. Cambie el nombre de la calle o de la ciudad, y no tendrá ningún impacto en los atributos sustanciales del pedido.
Tercera forma normal de la base de datos requiere el cumplimiento de la segunda forma normal y la ausencia de dependencias funcionales entre atributos de diferentes entidades. Esta regla se puede formular así: 'todo lo que puede ser calculado debe ser calculado'. En otras palabras, si existen dos objetos A y B. En la tabla que almacena los atributos del objeto A, se manifiesta el atributo C, y del objeto B existe un atributo b tal que hay c=f4(b), entonces se ha violado la tercera forma normal. En el siguiente ejemplo, el atributo 'Cantidad de piezas' (Total_count_WR) en el registro del pedido claramente tiende a violar la tercera forma normal.
3. Mi enfoque para aplicar la normalización
1. Solo un proceso de negocio automatizable objetivo puede proporcionar al analista los criterios para identificar entidades y atributos al crear un modelo de almacenamiento de datos. La creación de un modelo de proceso es un requisito indispensable para crear un modelo de datos normalizado.
2. Alcanzar la tercera forma normal en un sentido estricto puede no ser práctico en la práctica real de creación de sistemas ERP al cumplirse parte o todas las siguientes condiciones:
- los procesos automatizables rara vez están sujetos a cambios,
- los plazos para la investigación y el desarrollo son ajustados,
- los requisitos de integridad de los datos son condicionalmente bajos (los posibles errores en el software industrial no conducen a la pérdida de dinero o de clientes para el contratista del software)
- etc.
Bajo las condiciones descritas, los costos de identificación y descripción del ciclo de vida de algunos objetos y sus atributos pueden no ser justificados desde el punto de vista de la efectividad económica.
3. Cualquier consecuencia de la desnormalización del modelo de datos en un SI ya creado puede ser contrarrestada mediante una investigación cuidadosa del código y pruebas.
4. La desnormalización es una forma de transferir los esfuerzos de trabajo de la etapa de investigación de fuentes de datos y diseño de procesos de negocio a la etapa de desarrollo, del periodo de implementación al periodo de evolución del sistema.
5. Es recomendable aspirar a la tercera forma normal de la base de datos si:
- La dirección del cambio en los procesos de negocio automatizados es difícil de predecir.
- Dentro del equipo de implementación y/o desarrollo hay una clara división del trabajo poco permeable.
- Los sistemas que forman parte del contorno de integración evolucionan de acuerdo con sus propios planes.
- La incoherencia de datos puede llevar a la pérdida de clientes o dinero para la empresa.
6. El diseño del modelo de datos debe ser realizado por un analista solo en relación con los modelos del proceso de negocio objetivo y el proceso en el sistema de información. Si el diseño del modelo de datos lo realiza un desarrollador, tendrá que sumergirse en el área temática hasta el punto de entender la diferencia entre los valores de los atributos, que es una condición necesaria para la identificación de atributos atómicos. De esta manera, asumiendo funciones que no le son propias.
4 Tarea para ilustrar
Supongamos que tienes una pequeña taberna robotizada en el puerto. Tu segmento de mercado: marineros y piratas que llegan al puerto y necesitan descansar. A los marineros les vendes té de tomillo, y a los piratas, ron y peines de hueso para arreglarse la barba. El servicio en la taberna es proporcionado por un robot anfitrión y un robot bartender. Gracias a la alta calidad y bajos precios, has desplazado a todos los competidores, así que cada persona que desembarca de un barco viene a tu taberna, que es la única en el puerto.
El conjunto de sistemas de información de la taberna está compuesto por el siguiente software:
- Sistema de alerta temprana del cliente, que reconoce su categoría por características distintivas.
- Sistema de gestión de robots anfitriones y robots bartenders.
- Sistema de gestión de inventario y entrega en el punto de venta.
- Sistema de gestión de relaciones con proveedores (SGRP).
Proceso:
El sistema de alerta temprana reconoce a las personas que desembarcan de los barcos. Si la persona está afeitada, se la clasifica como marinero; si tiene barba, se le clasifica como pirata.
Al entrar en la taberna, el huésped escucha del robot anfitrión un saludo acorde a su categoría, por ejemplo: "¡Ho-ho-ho, estimado pirata, dirígete a la mesa No....!"
El cliente se acerca a la mesa designada, donde el robot barman ya ha preparado los productos según la categoría. El robot barman comunica a la sistema de gestión de almacén que la próxima entrega debe ser incrementada; el sistema logístico genera una solicitud de compra con base en el inventario disponible.
Suponga que el sistema de alerta temprana fue desarrollado por su equipo interno de TI, mientras que el programa para gestionar los robots de bar fue creado por un contratista externo específicamente para su negocio. Los sistemas para la gestión de inventarios y relaciones con proveedores son soluciones empaquetadas personalizadas del mercado.
5. Ejemplos de desnormalización y su impacto en el desarrollo de software
Al diseñar el proceso empresarial, los expertos encuestados coincidieron en que en todo el mundo los piratas beben ron y se peinan la barba con peines de hueso, mientras que los marineros toman té con tomillo y siempre están bien afeitados.
Aparece un directorio de tipos de clientes con dos valores: 1- piratas, 2- marineros, común para todo el contorno informático de la empresa.
El sistema de alerta sobre el cliente guarda de inmediato el resultado del procesamiento de la imagen como el ID del cliente reconocido y su tipo: marinero o pirata.
ID del objeto reconocido
Categoría del cliente
100500
Pirata
100501
Pirata
100502
Marinero
Recalquemos que
1. Nuestros marineros son personas realmente afeitadas
2. Nuestros piratas son personas realmente barbadas
¿Qué problemas deben resolverse en este caso para que nuestra estructura aspire a la tercera forma normal?
- violación de la atomicidad del atributo — categoría del cliente
- mezcla del hecho analizado y la conclusión en una misma tabla
- dependencia funcional fijada entre atributos de diferentes entidades.
En forma normalizada, tendríamos dos tablas:
- resultado del reconocimiento en forma de un conjunto de atributos establecidos,
ID del objeto reconocido
Vello facial
100500
Sí
100501
Sí
100502
No
- resultado de la determinación del tipo de cliente como una aplicación de la lógica incorporada en el sistema para interpretar los atributos establecidos
ID del objeto reconocido
ID de identificación
Categoría del cliente
100500
100001
Pirata
100501
100002
Pirata
100502
100003
Marinero
¿Cómo puede una organización de almacenamiento de datos normalizada facilitar el desarrollo del sistema de información? Supongamos que de repente tiene nuevos clientes. Que sean piratas japoneses que pueden no tener barba, pero llevan un loro en el hombro, y piratas ecologistas, los reconocerá fácilmente por el perfil azul de Greta en su pecho izquierdo.
Los piratas ecologistas, por supuesto, no pueden usar peines de hueso y exigen una alternativa hecha de plástico marino reciclado.
Es necesario que modifique los algoritmos de los programas de acuerdo con las nuevas entradas. Si se hubieran cumplido las reglas de normalización, solo tendría que complementar las entradas para algunas ramas de los procesos en ciertos sistemas y crear nuevas ramas solo para aquellos casos y en aquellos sistemas donde la presencia de vello facial sea relevante. Pero, dado que las reglas no se han cumplido, deberá analizar todo el código en todo el contorno donde se utilizan los valores del directorio de tipos de clientes y establecer claramente que, en un caso, el algoritmo debe tener en cuenta la actividad profesional del cliente y, en el otro, las características físicas.
En la forma que está buscando normalizado, obtendríamos dos tablas con datos operativos y dos directorios:
- resultado del reconocimiento en forma de un conjunto de atributos establecidos,
ID del objeto reconocido
Greta en el pecho izquierdo
Un loro en el hombro
Vello facial
100510
1
1
1
100511
0
0
1
100512
1
0
- resultado de la determinación del tipo de cliente (supongamos que esto es una representación de usuario, en la que se muestran descripciones de los directorios)
¿Significa la desnormalización detectada que los sistemas no se podrán adaptar a nuevas condiciones? Por supuesto que no. Si imaginamos que todos los sistemas fueron creados por un mismo equipo con una rotación de personal nula, el desarrollo está bien documentado y la información se transmite en el equipo sin pérdidas, entonces los cambios requeridos podrían hacerse con costos de esfuerzo despreciables. Pero si volvemos a las condiciones iniciales del problema, solo en la impresión de las actas de las discusiones conjuntas se desgastarán 1.5 teclados y otros 0.5 en la formalización de los procedimientos de compra.
En el ejemplo anterior, se han violado las tres formas normales. Intentemos violarlas por separado.
Violación de la primera forma normal:
Supongamos que los productos en su almacén se entregan desde los almacenes de los proveedores mediante la auto-recolección utilizando una furgoneta de 1.5 toneladas que pertenece a su taberna. El tamaño de sus pedidos es tan pequeño en relación con el volumen de los proveedores que siempre se cumplen exactamente uno a uno sin esperar la fabricación. ¿Se necesitan tablas separadas: vehículos, tipos de vehículos, es necesario diferenciar entre el plan y la realidad en sus pedidos enviados a los proveedores?
Solo imagina cuántas conexiones «innecesarias» tendrán que escribir tus programadores si se utiliza el modelo a continuación para desarrollar el programa.
Supongamos que hemos decidido que la estructura propuesta es innecesariamente compleja, para nuestro caso, separar el plan y la realidad en el registro de pedidos es información excesiva, y la especificación del pedido se sobrescribe según los resultados de la aceptación de la mercancía recibida, el raro error de clasificación y la llegada de productos de calidad no adecuada se manejan fuera del sistema de información.
Y un día ves cómo toda la sala de la taberna está llena de piratas indignados y desaliñados. ¿Qué ha pasado?
Resultó que, junto con el crecimiento de su negocio, también creció el consumo. En algún momento, se tomó la decisión administrativa de que si la furgoneta estaba sobrecargada en volumen y/o peso, lo cual ocurría muy rara vez, el proveedor priorizaba la carga en favor de las bebidas.
Los productos no entregados se incluían en el siguiente pedido y se enviaban en un nuevo viaje, la existencia de un inventario mínimo en el almacén de la taberna permitía no notar los casos de falta de entrega.
En el puerto cerró el último competidor, y el caso de sobrecarga de la furgoneta, pasado por alto debido a la priorización basada en la suposición de que había suficiente inventario mínimo y la carga periódica insuficiente del vehículo, se convirtió en una práctica habitual. El sistema creado funcionará perfectamente de acuerdo con los algoritmos establecidos, y no habrá manera de rastrear la falta sistemática de cumplimiento de los pedidos planificados. Solo una reputación dañada y clientes descontentos podrán detectar el problema.
El lector atento seguramente habrá notado que la cantidad solicitada en la especificación del pedido (T_ORDER_SPEC) en la sección 2 y en la sección 5 puede cumplir o no con los requisitos de la primera forma normal. Todo depende de si, con el surtido de productos seleccionado, diferentes unidades de medida pueden caer en el mismo campo.
Violación de la segunda forma normal:
A medida que aumentan sus necesidades, adquiere un par más de vehículos de diferentes tamaños. En el contexto expuesto anteriormente, se consideró redundante crear un catálogo de vehículos, como resultado de lo cual todos los algoritmos de manejo de datos que atienden las necesidades de entrega y almacén perciben el movimiento de mercancías del proveedor al almacén como un viaje exclusivamente de una furgoneta de 1.5 toneladas. Así, junto con la compra de nuevos vehículos, aún así crea un catálogo de vehículos, pero al final tendrá que analizar todo el código que hace referencia al movimiento de las cargas para determinar si en cada lugar específico hay referencias a las características del mismo vehículo con el que comenzó el negocio.
Violación de la tercera forma normal:
En algún momento, comienza a crear un programa de fidelización, aparece el registro de un cliente habitual. ¿Para qué, por ejemplo, perder tiempo creando representaciones materiales que almacenan datos agregados sobre ventas a un cliente específico para su uso en informes y transferencia a sistemas analíticos, si en la etapa inicial del programa de fidelización todo lo que le interesa al cliente se puede colocar en el registro del propio cliente? Y, de hecho, no parece tener sentido a primera vista. Pero cada vez que su negocio conecte, por ejemplo, nuevos canales de venta, entre sus analistas debe haber alguien que recuerde que existe ese atributo de agregación.
Al diseñar cada nuevo proceso, como la venta por Internet o las ventas a través de distribuidores conectados al sistema de fidelización común, alguien debe tener en mente que todos los nuevos procesos deben garantizar a nivel de código la integridad de los datos. Para una base de datos industrial con miles de tablas, esto parece una tarea poco realizable.
Un desarrollador experimentado, por supuesto, sabe cómo abordar todos los problemas mencionados anteriormente, pero, en mi opinión, la tarea de un analista experimentado es evitar que se lleguen a esos problemas.
Quiero expresar mi agradecimiento por la valiosa retroalimentación al preparar la publicación para el desarrollador líder, Evgeny Yarukhin.
Literatura
Connolly Thomas, Begg Caroline. Bases de datos. Diseño, implementación y mantenimiento. Teoría y práctica.
Fuente: habr.com
