⏰ 📎 🍴 Desormalización de los sistemas de bases de datos ERP y su impacto en el desarrollo de software: abrir una taberna en Tortuga 🆑 👑 👊

¡Hola! Mi nombre es Andrey Semenov, soy analista senior en Sportmaster. En este post quiero plantear el tema de la desnormalización de los sistemas de bases de datos ERP. Consideraremos las condiciones generales, así como un ejemplo específico; digamos que será una maravillosa taberna de monopolio para piratas y marineros. En el que los piratas y los marineros deben ser atendidos de manera diferente, porque las ideas sobre los patrones hermosos y de consumo de estos buenos maestros son significativamente diferentes.

¿Cómo hacer felices a todos? ¿Cómo no volverse loco diseñando y manteniendo tal sistema? ¿Qué hacer si no solo piratas y marineros familiares comienzan a venir a la taberna? Todo está debajo del corte. Pero vamos en orden.

1. Limitaciones y supuestos

Todo lo anterior se aplica solo a las bases de datos relacionales. Bien iluminados, incluso en Internet, no se tienen en cuenta los efectos de la desnormalización en forma de anomalías de modificación, eliminación e inserción. Más allá del alcance de la publicación, quedan casos en los que la desnormalización es un lugar común, con ejemplos clásicos: serie y número de pasaporte, fecha y hora, etc.

La publicación utiliza definiciones intuitivas y prácticamente aplicables de formas normales, sin referencia a términos matemáticos. En la forma en que se pueden aplicar al examen de procesos comerciales reales (BP) y al diseño de software industrial.

Existe la opinión de que el diseño de almacenes de datos, herramientas de informes y acuerdos de integración (que utilizan la presentación tabular de información) difiere del diseño de los sistemas de bases de datos ERP en que la facilidad de consumo y la aplicación de desnormalización consciente para lograrlo pueden tener prioridad sobre la protección de integridad datos. Comparto esta opinión, y la descripción a continuación se aplica exclusivamente a los modelos de datos maestros y datos transaccionales de los sistemas ERP.

La explicación de las formas normales está dada por un ejemplo que es comprensible a nivel de hogar para la mayoría de los lectores. Sin embargo, como ilustración ilustrativa, en los párrafos 4-5, la tarea "inventada" enfatizada se usó deliberadamente. Si no hace esto y toma algún tipo de ejemplo de libro de texto, por ejemplo, el mismo modelo para almacenar un pedido de la Sección 2, puede encontrarse en una situación en la que la atención del lector se desplazará de la descomposición propuesta del proceso a un modelo, a la experiencia personal y la percepción de cómo Se deben construir procesos y modelos de almacenamiento de datos en IP. En otras palabras, tome dos analistas de TI calificados, deje que uno brinde servicios a los logísticos que transportan pasajeros, y el otro a los logísticos que transportan máquinas para la producción de microchips. Pídales, sin hablar sobre BP pre-automatizado, que creen un modelo de datos para almacenar información sobre el vuelo ferroviario.

Existe una probabilidad distinta de cero de que en los modelos propuestos encuentre no solo un conjunto de atributos notablemente diferente, sino también conjuntos de entidades diferentes, porque cada analista dependerá de sus procesos y tareas habituales. Y decir en tal situación qué modelo es "correcto" es imposible, porque no existe 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 el objeto A tiene atributos no clave a y b, de modo que c = f (a, b) y en la tabla que describe el objeto A almacena el valor del atributo c, la primera forma normal se viola en la base de datos. Por ejemplo, si la especificación del pedido especifica una cantidad cuyas unidades de medida dependen del tipo de producto: en un caso pueden ser piezas, en los otros litros, en el tercer paquete que consta de piezas (en el modelo anterior Good_count_WR), entonces la atomicidad de los atributos se viola en la base de datos. En este caso, para decir cómo debería ser el arbusto de las tablas para la especificación del pedido, necesita una descripción específica del proceso de trabajo en la IP, 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 del primer formulario y su propia tabla para cada entidad relacionada con el proceso de trabajo en IP. Si en una tabla hay dependencias c = f1 (a) yd = f2 (b) y no hay dependencia c = f3 (b), entonces la segunda forma normal se viola en la tabla. En el ejemplo anterior, en la tabla "Pedido", no hay relación entre el pedido y la dirección. Cambie el nombre de la calle o ciudad y no obtendrá ninguna influencia sobre los atributos esenciales del pedido.

La 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 de la siguiente manera: "todo lo que se puede calcular debe calcularse". En otras palabras, si hay dos objetos A y B. En la tabla que almacena los atributos del objeto A, se muestra el atributo C, el objeto B tiene el atributo b tal que c = f4 (b) existe, entonces se viola la tercera forma normal. En el siguiente ejemplo, el atributo "Número de piezas" (Total_count_WR) en el registro de la orden afirma claramente que viola la tercera forma normal

3. Mi enfoque para aplicar la normalización.

1. Solo el proceso de negocio automatizado objetivo puede proporcionar análisis con criterios para identificar entidades y atributos al crear un modelo de almacenamiento de datos. Crear un modelo de proceso es un requisito previo para crear un modelo de datos normal.

2. El logro de la tercera forma normal en sentido estricto puede no ser práctico en la práctica real de crear sistemas ERP cuando se cumplen parte o la totalidad de las siguientes condiciones:

los procesos automatizados rara vez están sujetos a cambios,
los plazos de investigación y desarrollo son ajustados,
Los requisitos para la integridad de los datos son relativamente bajos (los posibles errores en el software industrial no conducen a la pérdida de dinero o clientes por parte del cliente del software)
etc.

Bajo las condiciones descritas, los costos de identificación, una descripción del ciclo de vida de algunos objetos y sus atributos pueden no estar justificados desde el punto de vista de la eficiencia económica.

3. Cualquier consecuencia de la desnormalización del modelo de datos en el IP ya creado se puede detener mediante un estudio preliminar exhaustivo del código y las pruebas.

4. La desnormalización es una forma de transferir los costos laborales desde la etapa de investigación de las fuentes de datos y el diseño de un proceso comercial hasta la etapa de desarrollo, desde el período de implementación hasta el período de desarrollo del sistema.

5. Es aconsejable luchar por la tercera forma normal de la base de datos si:

La dirección del cambio en los procesos comerciales automatizados es difícil de predecir
Existe una división permeable del trabajo dentro del equipo de implementación y / o desarrollo
Los sistemas incluidos en el circuito de integración se desarrollan de acuerdo con sus propios planes.
La inconsistencia de datos puede conducir a la pérdida de clientes o dinero por parte de la compañía

6. El diseño del modelo de datos debe ser realizado por el analista solo en relación con los modelos del proceso de negocio objetivo y el proceso en IP. Si un desarrollador se dedica a diseñar un modelo de datos, tendrá que sumergirse en el área temática hasta tal punto que, en particular, necesita comprender la diferencia entre los valores de los atributos, una condición necesaria para distinguir los atributos atómicos. Por lo tanto, asumir funciones inusuales.

4 Tarea para ilustración

Digamos que tienes una pequeña taberna robótica en el puerto. Su segmento de mercado: marineros y piratas que visitan el puerto y necesitan descansar. Para los marineros, vendes té con tomillo, y para piratas, ron y peines de huesos para peinarte la barba. El servicio en la taberna en sí es proporcionado por un robot anfitrión y un robot cantinero. Debido a la alta calidad y los bajos precios, ha desplazado a todos sus competidores, para que todos los que abandonen el barco lleguen a su taberna, que es la única en el puerto.

El complejo de sistemas de información de taberna consta del siguiente software:

Sistema de alerta temprana del cliente que reconoce su categoría por características
Sistema de gestión para robots de azafatas y robots de barman.
Sistema de gestión de almacenes y puntos de entrega.
Sistema de gestión de relaciones con proveedores (SMSS)

Proceso:

el sistema de alerta temprana detecta personas que abandonan el barco. Si una persona está bien afeitada, ella lo define como un marinero, si se encuentra una barba en una persona, entonces él se define como un pirata.

Al entrar a la taberna, el invitado escucha un saludo del robot anfitrión según su categoría, por ejemplo: "Ho-ho-ho, querido pirata, ve a la mesa No. ..." El

invitado va a la mesa indicada, donde el robot-barman ya se ha preparado para le bienes de acuerdo a la categoría. El robot barman transmite información al sistema de almacén de que la siguiente parte de la entrega debe aumentarse, el almacén IS, en función del almacenamiento restante, forma una solicitud de compra en el sistema de control.

Deje que su departamento de TI interno desarrolle un sistema de alerta temprana, un contratista externo especialmente diseñado para que su empresa cree un programa de gestión de robots de barra. Y los sistemas para la gestión de almacenes y las relaciones con los proveedores son soluciones personalizadas en caja del mercado.

5. Ejemplos de desnormalización y su impacto en el desarrollo de software.

Al diseñar un proceso comercial, los expertos en la materia entrevistados declararon por unanimidad que los piratas de todo el mundo beben ron y se peinan la barba con crestas de hueso, y los marineros beben té con tomillo y siempre se afeitan sin problemas.

Aparece un directorio de tipos de clientes a partir de dos valores: 1 - piratas, 2 - marineros, comunes a todo el circuito de información de la empresa.

El sistema de notificación al cliente guarda inmediatamente el resultado del procesamiento de la imagen como el identificador (ID) del cliente reconocido y su tipo: marinero o pirata.

ID de objeto reconocido	Categoría de cliente
100500	Pirata
100501	Pirata
100502	Marinero

Una vez más, observamos que

1. Nuestros marineros son en realidad personas afeitadas
2. Nuestros piratas en realidad son personas con barba

Qué problemas en este caso deben abordarse para que nuestra estructura se esfuerce por una tercera forma normal:

atributo violación atómica - Categoría de cliente
mezcla del hecho analizado y la conclusión en una tabla
relación funcional fija entre atributos de diferentes entidades.

En forma normalizada, obtendríamos dos tablas:

resultado del reconocimiento en forma de un conjunto de características establecidas,

ID de objeto reconocido	Vello facial
100500	si
100501	si
100502	No

El resultado de determinar el tipo de cliente como una aplicación de la lógica integrada en el SI para la interpretación de los signos establecidos

ID de objeto reconocido	ID de identificación	Categoría de cliente
100500	100001	Pirata
100501	100002	Pirata
100502	100003	Marinero

¿Cómo puede una organización de almacenamiento normalizada facilitar el desarrollo de un complejo de IP? Digamos que de repente tienes nuevos clientes. Deje que sean los piratas japoneses quienes pueden no tener barba, pero caminan con un loro sobre sus hombros, y los piratas ambientales, los puede reconocer fácilmente por el perfil azul de Greta en su pecho izquierdo.

Los piratas ambientales, por supuesto, no pueden usar crestas de huesos y requieren un análogo del plástico marino reciclado.

Debe volver a trabajar los algoritmos de los programas de acuerdo con la nueva introducción. Si se cumplieran las reglas de normalización, entonces solo tendría que agregar entradas para algunas ramas de proceso y crear nuevas ramas solo para esos casos y en aquellas IP donde la línea del cabello en la cara es importante. Pero, dado que no se siguieron las reglas, tendrá que analizar todo el código, en todo el circuito, donde se utilizan los valores del directorio de tipos de clientes y establecer inequívocamente que en un caso el algoritmo debe tener en cuenta las actividades profesionales del cliente, y en las otras características físicas.

En una vista que tiende a normalizarse, obtendríamos dos tablas con datos operativos y dos directorios:

resultado del reconocimiento en forma de un conjunto de características establecidas,


100510	1	1	1
100511	0	0	1
100512		1	0

( , )

¿La desnormalización detectada significa que los sistemas no pueden modificarse bajo nuevas condiciones? Por supuesto no. Si imagina que todas las IP fueron creadas por un equipo con cero rotación de personal, el desarrollo está bien documentado y la información en el equipo se transmite sin pérdida, entonces los cambios requeridos pueden ser productos con un esfuerzo descuidadamente bajo. Pero si volvemos a las condiciones iniciales de la tarea, solo 1.5 teclados y otros 0.5 para el registro de los procedimientos de adquisición se borrarán solo para imprimir protocolos de discusiones conjuntas.

En el ejemplo anterior, se violan las tres formas normales, intentemos violarlas individualmente.

Violación de la primera forma normal:

Suponga que los bienes se entregan a su almacén desde los almacenes de los proveedores a su propio costo utilizando una gacela de 1,5 toneladas que pertenece a su taberna. El tamaño de sus pedidos es tan pequeño en relación con la rotación de proveedores que siempre se llevan a cabo uno a uno sin esperar la producción. ¿Necesita tablas separadas para tal PSU: vehículos, tipos de vehículos, necesita separar el plan y el hecho en sus pedidos a los proveedores que se fueron?

Imagínense cuántas conexiones "extra" tendrán que escribir sus programadores si utiliza el siguiente modelo para desarrollar un programa.

Supongamos que tomamos la decisión de que la estructura propuesta es innecesariamente complicada, para nuestro caso, separar el plan y el hecho en el registro de la orden es información redundante, y la especificación de la orden generada se sobrescribe por los resultados de la aceptación de las mercancías recibidas, la reordenación rara y la llegada de mercancías de calidad inadecuada se liquidan fuera del IP.
Y luego, un día, ves cómo todo el salón de la taberna está lleno de piratas indignados y descuidados. ¿Que pasó?

Resultó que junto con el crecimiento de su negocio, el consumo también creció. Una vez se tomó la decisión de gestión de que si una gacela se sobrecargaba en volumen y / o peso, lo cual era extremadamente raro, el proveedor priorizaba la carga a favor de las bebidas.

Las mercancías no entregadas cayeron en el siguiente pedido y partieron en un nuevo vuelo, la presencia de un saldo irreducible en el almacén de la taberna permitió no notar casos perforados.

El último competidor cerró en el puerto, y el caso de sobrecarga de la gacela pinchada, eludido por la priorización basada en la suposición de la suficiencia del saldo mínimo y la baja carga periódica del vehículo, se convirtió en una práctica común. El sistema creado idealmente funcionará de acuerdo con los algoritmos establecidos en él y se le privará de cualquier oportunidad de rastrear el incumplimiento sistemático de los pedidos planificados. Solo una reputación dañada y clientes insatisfechos podrán detectar el problema.

Un lector atento debe haber notado que la cantidad pedida en la especificación del pedido (T_ORDER_SPEC) en la sección 2 y la sección 5 puede o no cumplir con el requisito de la primera forma normal. Todo depende de si, para un surtido de productos seleccionado, unidades de medida esencialmente diferentes pueden caer en el mismo campo.

Violación de la segunda forma normal:

A medida que crecen sus necesidades, obtiene un par de vehículos más de diferentes tamaños. En el contexto anterior, la creación de un directorio de vehículos se consideró redundante, como resultado, todos los algoritmos de manipulación de datos que satisfacen las necesidades de entrega y almacenamiento perciben el movimiento de mercancías desde el proveedor al almacén como un vuelo exclusivo de gacelas de 1.5 toneladas. Entonces, junto con la compra de vehículos nuevos, aún crea un directorio de vehículos, pero al finalizarlo, deberá analizar todo el código que se refiere al movimiento de carga para averiguar si hay referencias a las características del automóvil desde el cual El negocio comenzó.

Violación de la tercera forma normal:

En algún momento, comienza a crear un programa de fidelización, aparece un registro regular de clientes. ¿Por qué, por ejemplo, pasar tiempo creando representaciones de materiales que almacenan datos de ventas agregados para un cliente individual para su uso en informes y transferencias a sistemas analíticos, si al comienzo del programa de lealtad todo lo que le interesa al cliente se puede colocar en sus propios registros? Y, de hecho, no tiene sentido a primera vista. Pero cada vez que su empresa se conecta, por ejemplo, con nuevos canales de ventas, debe haber alguien entre sus analistas que recuerde que existe un atributo de agregación de este tipo.

Al diseñar cada nuevo proceso, por ejemplo, vender en Internet, vender a través de distribuidores conectados a un sistema de lealtad común, alguien debe tener en cuenta que todos los nuevos procesos deben garantizar la integridad de los datos a nivel de código. Para una base de datos industrial con mil tablas, esto parece una tarea imposible.

Un desarrollador experimentado, por supuesto, sabe cómo detener todos los problemas mencionados anteriormente, pero, en mi opinión, la tarea de un analista experimentado no es llamar su atención.

Quiero expresar mi agradecimiento por los valiosos comentarios durante la preparación de la publicación al desarrollador líder Evgeny Yarukhin.

Literatura

https://habr.com/en/post/254773/
Connolly Thomas, Begg Carolyn. Base de datos. Diseño, implementación y mantenimiento. Teoría y práctica