¡Hola! Mi nombre es Andrey Semenov, soy analista senior en Sportmaster. En esta publicación quiero plantear la cuestión de la desnormalización de las bases de datos del sistema ERP. Consideraremos las condiciones generales, así como un ejemplo específico: digamos que sería una maravillosa taberna monopolista para piratas y marineros. En el que piratas y marineros deben ser atendidos de manera diferente, porque las ideas sobre la belleza y los patrones de consumo de estos buenos señores son significativamente diferentes.
¿Cómo hacer felices a todos? ¿Cómo se puede evitar volverse loco diseñando y manteniendo un sistema de este tipo? ¿Qué hacer si no sólo los habituales piratas y marineros empiezan a llegar a la taberna?
Todo está bajo el corte. Pero vayamos en orden.
1. Limitaciones y supuestos
Todo lo anterior se aplica sólo a bases de datos relacionales. No se tienen en cuenta las consecuencias de la desnormalización en forma de anomalías de modificación, eliminación e inserción, que están bien cubiertas, incluso en Internet. Fuera del alcance de esta publicación existen 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 de negocio (BP) reales y al diseño de software industrial.
Se argumenta que el diseño de almacenes de datos, herramientas de generación de informes y acuerdos de integración (que utilizan representaciones tabulares de información) difiere del diseño de bases de datos del sistema ERP en que la facilidad de consumo y el uso de la desnormalización consciente para lograrlo pueden tener prioridad sobre la integridad. datos de protección. Comparto esta opinión y lo que se describe a continuación se aplica únicamente a los modelos de datos maestros y de datos transaccionales de los sistemas ERP.
Se proporciona una explicación de las formas normales utilizando un ejemplo que es comprensible en el nivel cotidiano para la mayoría de los lectores. Sin embargo, como ilustración visual, en los párrafos 4 y 5 se utilizó deliberadamente una tarea deliberadamente "ficticia". Si no hace esto y toma algún ejemplo de libro de texto, por ejemplo, el mismo modelo de almacenamiento de pedidos del punto 2, puede encontrarse en una situación en la que el enfoque del lector se desviará de la descomposición propuesta del proceso en un modelo. a la experiencia y percepción personal de cómo se deben construir procesos y modelos para almacenar datos en SI. En otras palabras, tomemos a dos analistas de TI calificados y dejemos que uno proporcione 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 de antemano sobre los BP automatizados, que creen un modelo de datos para almacenar información sobre un viaje en tren.
Existe una probabilidad distinta de cero de que en los modelos propuestos se encuentre no sólo un conjunto de atributos notablemente diferente, sino también conjuntos de entidades divergentes, porque cada analista dependerá de los procesos y tareas que le son familiares. Y en tal situación es imposible decir qué modelo es “correcto”, porque no existe ningún criterio de evaluación.
2. Formas normales
Primera forma normal de la base de datos. Requiere atomicidad de todos los atributos.
En particular, si el objeto A tiene atributos a y b que no son clave, tales que c=f(a,b) y en la tabla que describe el objeto A almacena el valor del atributo c, entonces se viola la primera forma normal en la base de datos. . Por ejemplo, si en la especificación del pedido se indica una cantidad cuyas unidades de medida dependen del tipo de producto: en un caso pueden ser piezas, en otro litros, en un tercero paquetes compuestos por piezas (en el modelo anterior Good_count_WR) , entonces se viola la atomicidad de los atributos en la base de datos. En este caso, para decir cuál debería ser el grupo de tablas de la especificación del pedido, se necesita una descripción específica del proceso de trabajo en el SI y, dado que los procesos pueden ser diferentes, puede haber muchas versiones "correctas".
Segunda forma normal de la base de datos. exige el cumplimiento del primer formulario y de una tabla propia para cada entidad relacionada con el proceso de trabajo en el SI. Si en una tabla hay dependencias c=f1(a) y d=f2(b) y no hay dependencia c=f3(b), entonces se viola la segunda forma normal en la tabla. En el ejemplo anterior, no existe ninguna dependencia entre el pedido y la dirección en la tabla Pedido. Cambie el nombre de la calle o ciudad y no tendrá ningún efecto sobre los atributos esenciales del pedido.
Tercera base de datos en forma normal 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, el atributo C se manifiesta y el objeto B tiene el atributo b, de modo que existe c = f4 (b), entonces la tercera forma normal es violado. En el siguiente ejemplo, el atributo Cantidad de piezas (Total_count_WR) en el registro de pedido claramente afirma violar la tercera forma normal.
3. Mi enfoque para aplicar la normalización
1. Sólo un proceso de negocio automatizado objetivo puede proporcionar al analista 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 previo para crear un modelo de datos normal.
2. Lograr la tercera forma normal en sentido estricto puede no ser práctico en la práctica real de creación de sistemas ERP si se cumplen algunas o todas las siguientes condiciones:
- los procesos automatizados rara vez están sujetos a cambios,
- los plazos para la investigación y el desarrollo son ajustados,
- Los requisitos para la integridad de los datos son relativamente bajos (los errores potenciales en el software industrial no provocan pérdidas de dinero o de clientes por parte del cliente del software).
- etcétera
En las condiciones descritas, los costos de identificar y describir el 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 un SI ya creado puede mitigarse mediante un estudio preliminar exhaustivo del código y pruebas.
4. La desnormalización es una forma de transferir los costos laborales de la etapa de investigación de fuentes de datos y diseño de un proceso comercial a la etapa de desarrollo, desde el período de implementación hasta el período de desarrollo del sistema.
5. Es aconsejable optar por la tercera forma normal de base de datos si:
- La dirección del cambio en los procesos empresariales automatizados es difícil de predecir
- Existe una débil división del trabajo dentro del equipo de implementación y/o desarrollo.
- Los sistemas incluidos en el circuito de integración se desarrollan según sus propios planes.
- La inconsistencia de los datos puede resultar en que una empresa pierda clientes o dinero.
6. El diseño de un modelo de datos debe ser realizado por un analista únicamente en relación con los modelos del proceso de negocio objetivo y el proceso en el SI. Si un desarrollador diseña un modelo de datos, tendrá que sumergirse en el área temática hasta tal punto que, en particular, comprenda la diferencia entre los valores de los atributos, una condición necesaria para aislar los atributos atómicos. Asumiendo así funciones inusuales.
4 Problema a modo de ilustración.
Digamos que tienes una pequeña taberna robótica en el puerto. Su segmento de mercado: marineros y piratas que llegan a puerto y necesitan un descanso. Vendes té con tomillo a los marineros y ron y peines de hueso para peinar la barba a los piratas. El servicio en la taberna lo proporcionan una azafata robot y un barman robot. Gracias a tu gran calidad y bajos precios, has expulsado a tus competidores, de modo que todos los que bajan del barco van a tu taberna, que es la única que hay en el puerto.
El complejo de sistemas de información de la taberna consta del siguiente software:
- Un sistema de alerta temprana sobre un cliente que reconoce su categoría en función de rasgos característicos.
- Sistema de control para azafatas robot y bartenders robot
- Sistema de gestión de almacén y entrega al punto de venta.
- Sistema de Gestión de Relaciones con Proveedores (SURP)
Proceso:
El sistema de alerta temprana reconoce a las personas que abandonan el barco. Si una persona está bien afeitada, lo identifica como un marinero; si se encuentra que una persona tiene barba, entonces se lo identifica como un pirata.
Al entrar a la taberna, el huésped escucha un saludo de la anfitriona robot de acuerdo con su categoría, por ejemplo: “Ho-ho-ho, querido pirata, ve a la mesa No…”
El invitado se dirige a la mesa indicada, donde el robot bartender ya le ha preparado productos de acuerdo con la categoría. El robot bartender transmite al sistema de almacén la información de que se debe aumentar la siguiente porción de entrega; el IS del almacén, basándose en los saldos restantes en almacenamiento, genera una solicitud de compra en el sistema de gestión.
Si bien el sistema de alerta temprana puede haber sido desarrollado por su departamento de TI interno, el programa de gestión del robot de bar puede haber sido creado por un contratista externo específicamente para su negocio. Y los sistemas de gestión de almacenes y relación con proveedores son soluciones empaquetadas personalizadas del mercado.
5. Ejemplos de desnormalización y su impacto en el desarrollo de software
Los expertos en la materia entrevistados al diseñar un proceso de negocio afirmaron unánimemente que en todo el mundo los piratas beben ron y se peinan la barba con peines de hueso, y 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 circuito de información de la empresa.
El sistema de notificación al cliente almacena inmediatamente el resultado del procesamiento de imágenes 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
Notemos una vez más que
1. Nuestros marineros son en realidad personas afeitadas.
2. Nuestros piratas son en realidad personas barbudas.
Qué problemas en este caso deben eliminarse para que nuestra estructura se esfuerce por alcanzar la tercera forma normal:
- violación de atomicidad de atributo - Categoría de cliente
- mezclar el 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:
- el resultado del reconocimiento en forma de un conjunto de características establecidas,
ID de objeto reconocido
Vello facial
100500
Sí
100501
Sí
100502
No
- el resultado de determinar el tipo de cliente como aplicación de la lógica incorporada en el SI para interpretar las características establecidas
ID de objeto reconocido
Identificación de identificación
Categoría de cliente
100500
100001
Pirata
100501
100002
Pirata
100502
100003
Marinero
¿Cómo puede una organización de almacenamiento de datos normalizada facilitar el desarrollo de un complejo de propiedad intelectual? Digamos que de repente consigues nuevos clientes. Que sean piratas japoneses que quizás no tengan barba, pero caminan con un loro al hombro, y piratas ambientalistas, puedes reconocerlos fácilmente por el perfil azul de Greta en el pecho izquierdo.
Los piratas medioambientales, por supuesto, no pueden utilizar peines de huesos y necesitan un análogo hecho de plástico marino reciclado.
Es necesario reelaborar los algoritmos del programa de acuerdo con las nuevas entradas. Si se siguieran las reglas de normalización, entonces solo tendría que complementar las entradas para algunas ramas de proceso en algunos sistemas y crear nuevas ramas solo para aquellos casos y en aquellos SI donde el vello facial importa. Pero, como no se siguieron las reglas, habrá que analizar todo el código, a lo largo de todo el circuito, donde se utilizan los valores del directorio de tipo de cliente y establecer claramente que en un caso el algoritmo debe tener en cuenta al profesional. actividad del cliente, y en las demás características físicas.
En una forma que стремится Al normalizarlo, obtendríamos dos tablas con datos operativos y dos directorios:
- el resultado del reconocimiento en forma de un conjunto de características establecidas,
ID de objeto reconocido
Greta en el pecho izquierdo
Pájaro en el hombro
Vello facial
100510
1
1
1
100511
0
0
1
100512
1
0
- el resultado de determinar el tipo de cliente (que sea una vista personalizada en la que se muestran descripciones de los directorios)
¿La desnormalización detectada significa que los sistemas no se pueden modificar para cumplir con nuevas condiciones? Por supuesto que no. Si imaginamos que todos los sistemas de información fueron creados por un equipo sin rotación de personal, los desarrollos están bien documentados y la información se transfiere dentro del equipo sin pérdidas, entonces los cambios necesarios se pueden realizar con un esfuerzo insignificante. Pero si volvemos a las condiciones originales del problema, se borrarán 1,5 teclados sólo para imprimir protocolos de discusiones conjuntas y otros 0,5 para procesar procedimientos de adquisiciones.
En el ejemplo anterior, se violan las tres formas normales, intentemos violarlas por separado.
Violación de la primera forma normal:
Digamos que los productos se entregan a su almacén desde los almacenes de los proveedores mediante recogida 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 facturación de los proveedores que siempre se completan uno a uno sin esperar a la producción. ¿Necesita tablas separadas con dicho proceso comercial: vehículos, tipos de vehículos? ¿Es necesario separar el plan y los hechos en sus pedidos a proveedores salientes?
Imagínense cuántas conexiones “adicionales” tendrán que escribir sus programadores si utilizan el siguiente modelo para desarrollar un programa.
Digamos que decidimos que la estructura propuesta es innecesariamente compleja; en nuestro caso, separar el plan y el hecho en el registro del pedido es información redundante, y la especificación del pedido generada se reescribe en función de los resultados de la aceptación de los productos llegados, un error raro -la clasificación y llegada de mercancías de calidad inadecuada se liquidan fuera del SI.
Y un día ves cómo toda la taberna se llena de piratas indignados y descuidados. ¿Qué pasó?
Resulta que a medida que crecía tu negocio, también crecía tu consumo. Érase una vez, la dirección tomó la decisión de que si una gacela estaba sobrecargada en volumen y/o peso, lo cual era extremadamente raro, el proveedor priorizaría la carga en favor de las bebidas.
La mercancía no entregada acabó en el siguiente pedido y partió en un nuevo vuelo, la presencia de un saldo mínimo en el almacén de la taberna permitió no notar cajas faltantes.
El último competidor cerró en el puerto, y el caso pinchado de sobrecarga del gacela, ignorado por una priorización basada en el supuesto de suficiencia del saldo mínimo y una subcarga periódica del vehículo, se convirtió en una práctica común. Idealmente, el sistema creado funcionará de acuerdo con los algoritmos incorporados en él y se verá privado de cualquier oportunidad de rastrear el incumplimiento sistemático de los pedidos planificados. Sólo una reputación dañada y clientes insatisfechos podrán detectar el problema.
Un lector atento puede haber notado que la cantidad pedida en la especificación del pedido (T_ORDER_SPEC) en las secciones 2 y 5 puede cumplir o no con el requisito de la primera forma normal. Todo depende de si, teniendo en cuenta la gama de productos seleccionada, pueden entrar en el mismo campo unidades de medida esencialmente diferentes.
Violación de la segunda forma normal:
A medida que crecen sus necesidades, compra 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 procesamiento de datos que atienden las necesidades de entrega y almacén perciben el movimiento de la carga desde el proveedor al almacén como el vuelo de un vehículo exclusivamente de 1,5 toneladas. gacela. Entonces, junto con la compra de vehículos nuevos, aún creas un directorio de vehículos, pero al finalizarlo tendrás que analizar todo el código que hace referencia al movimiento de carga para saber si en cada lugar específico están implícitas referencias a las características. del mismo vehículo desde el cual comenzó el negocio.
Violación de la tercera forma normal:
En algún momento comienzas a crear un programa de fidelización, aparece un registro de un cliente habitual. ¿Por qué, por ejemplo, dedicar tiempo a crear vistas de materiales que almacenen datos agregados sobre las ventas a un cliente individual para usarlos en informes y transferirlos a sistemas analíticos, si al inicio de un programa de fidelización todo lo que le interesa al cliente se puede colocar en el registro del cliente? ? Y, efectivamente, a primera vista, no tiene sentido. Pero cada vez que su empresa conecta, por ejemplo, nuevos canales de ventas, debería haber alguien entre sus analistas que recuerde que dicho atributo de agregación existe.
Al diseñar cada nuevo proceso, por ejemplo, ventas en Internet, ventas a través de distribuidores conectados a un sistema de fidelización común, alguien debe tener en cuenta que todos los procesos nuevos 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 sacarlos a la luz.
Me gustaría expresar mi agradecimiento al desarrollador líder Evgeniy Yarukhin por sus valiosos comentarios durante la preparación de la publicación.
Literatura
Connolly Thomas, Begg Caroline. Base de datos. Diseño, implementación y soporte. Teoría y práctica
Fuente: habr.com