Ola! Chámome Andrey Semenov, son analista senior de Sportmaster. Neste post quero plantexar o tema da desnormalización das bases de datos do sistema ERP. Veremos as condicións xerais, así como un exemplo específico: digamos que sería unha marabillosa taberna de monopolio para piratas e mariñeiros. No que os piratas e os mariñeiros deben ser servidos de xeito diferente, porque as ideas de beleza e os patróns de consumo destes bos señores son significativamente diferentes.
Como facer felices a todos? Como pode evitar volverse tolo proxectando e mantendo un sistema así? Que facer se non só comezan a vir á taberna os piratas e mariñeiros habituais?
Todo está baixo o corte. Pero imos en orde.
1. Limitacións e supostos
Todo o anterior aplícase só ás bases de datos relacionais. Non se consideran as consecuencias da desnormalización en forma de anomalías de modificación, eliminación e inserción, que están ben cubertas, incluso en Internet. Fóra do ámbito desta publicación hai casos nos que a desnormalización é un lugar habitual, con exemplos clásicos: serie e número de pasaporte, data e hora, etc.
A publicación usa definicións intuitivas e practicamente aplicables de formas normais, sen facer referencia a termos matemáticos. Na forma na que se poden aplicar ao exame de procesos empresariais reais (BP) e ao deseño de software industrial.
Argumenta que o deseño de data warehouses, ferramentas de informes e acordos de integración (que utilizan representacións tabulares da información) difire do deseño das bases de datos do sistema ERP en que a facilidade de consumo e o uso da desnormalización consciente para conseguilo pode primar sobre a integridade. datos de protección. Comparto esta opinión, e o que se describe a continuación aplícase unicamente aos datos mestres e aos modelos de datos transaccionais dos sistemas ERP.
Ofrécese unha explicación das formas normais mediante un exemplo que é comprensible no nivel cotián para a maioría dos lectores. Non obstante, como ilustración visual, nos parágrafos 4-5 utilizouse deliberadamente unha tarefa deliberadamente "ficcional". Se non fas isto e tomas algún exemplo de libros de texto, por exemplo, o mesmo modelo de almacenamento de pedidos do punto 2, podes atoparte nunha situación na que o foco do lector pasará da descomposición proposta do proceso a un modelo. á experiencia persoal e á percepción de como se deben construír procesos e modelos para almacenar datos en SI. Noutras palabras, leva dous analistas informáticos cualificados, que un preste servizos aos loxísticos que transportan pasaxeiros, o outro aos loxísticos que transportan máquinas para a produción de microchips. Pídalles, sen discutir os BP automatizados con antelación, que creen un modelo de datos para almacenar información sobre unha viaxe en ferrocarril.
Hai unha probabilidade distinta de cero de que nos modelos propostos atopes non só un conxunto notablemente diferente de atributos, senón tamén conxuntos diverxentes de entidades, porque cada analista dependerá dos procesos e tarefas que lle son familiares. E en tal situación é imposible dicir que modelo é "correcto", porque non existe un criterio de avaliación.
2. Formas normais
Primeira forma normal da base de datos require atomicidade de todos os atributos.
En particular, se o obxecto A ten atributos non clave a e b, de tal forma que c=f(a,b) e na táboa que describe o obxecto A almacena o valor do atributo c, entón a primeira forma normal infrixase na base de datos. . Por exemplo, se a especificación do pedido indica unha cantidade, cuxas unidades de medida dependen do tipo de produto: nun caso poden ser pezas, noutro litros, noutro paquetes compostos por pezas (no modelo anterior Good_count_WR) , entón a atomicidade dos atributos é violada na base de datos. Neste caso, para dicir cal debe ser o clúster de táboas da especificación do pedido, necesitas unha descrición específica do proceso de traballo no IS e, dado que os procesos poden ser diferentes, pode haber moitas versións "correctas".
Segunda forma normal da base de datos esixe o cumprimento do primeiro formulario e dun cadro propio para cada entidade relacionada co proceso de traballo no SI. Se nunha táboa hai dependencias c=f1(a) e d=f2(b) e non hai dependencia c=f3(b), entón a segunda forma normal infrinxerase na táboa. No exemplo anterior, non hai ningunha dependencia entre orde e enderezo na táboa Orde. Cambia o nome da rúa ou da cidade e non terás ningún efecto sobre os atributos esenciais da orde.
Terceira base de datos de formato normal require o cumprimento da segunda forma normal e a ausencia de dependencias funcionais entre atributos de diferentes entidades. Esta regra pódese formular do seguinte xeito: “todo o que se poida calcular debe ser calculado”. Noutras palabras, se hai dous obxectos A e B. Na táboa que almacena os atributos do obxecto A, maniféstase o atributo C e o obxecto B ten o atributo b, de xeito que existe c=f4(b), entón a terceira forma normal. está violado. No seguinte exemplo, o atributo Cantidade de pezas (Total_count_WR) no rexistro do pedido afirma claramente que infrinxe o terceiro formulario normal
3. O meu enfoque para aplicar a normalización
1. Só un proceso de negocio automatizado obxectivo pode proporcionar ao analista criterios para identificar entidades e atributos ao crear un modelo de almacenamento de datos. A creación dun modelo de proceso é un requisito previo para crear un modelo de datos normal.
2. O logro da terceira forma normal en sentido estrito pode non ser práctico na práctica real de crear sistemas ERP se se cumpren algunhas ou todas as seguintes condicións:
- os procesos automatizados raramente están suxeitos a cambios,
- os prazos de investigación e desenvolvemento son axustados,
- Os requisitos para a integridade dos datos son relativamente baixos (os potenciais erros no software industrial non levan á perda de diñeiro ou clientes por parte do cliente do software)
- etc
Nas condicións descritas, os custos de identificar e describir o ciclo de vida dalgúns obxectos e os seus atributos poden non estar xustificados desde o punto de vista da eficiencia económica.
3. Calquera consecuencia da desnormalización do modelo de datos nun IS xa creado pódese mitigar mediante un estudo preliminar exhaustivo do código e as probas.
4. A desnormalización é unha forma de transferir os custos laborais desde a fase de investigación de fontes de datos e de deseño dun proceso empresarial ata a fase de desenvolvemento, desde o período de implementación ata o período de desenvolvemento do sistema.
5. É aconsellable esforzarse pola terceira forma normal dunha base de datos se:
- A dirección do cambio nos procesos de negocio automatizados é difícil de predicir
- Existe unha débil división do traballo dentro do equipo de implementación e/ou desenvolvemento
- Os sistemas incluídos no circuíto de integración desenvólvense segundo os seus propios plans
- A incoherencia dos datos pode provocar que unha empresa perda clientes ou diñeiro
6. O deseño dun modelo de datos debe ser realizado por un analista só en relación cos modelos do proceso de negocio obxectivo e do proceso no SI. Se un desenvolvedor está a deseñar un modelo de datos, terá que mergullarse na área temática ata tal punto que, en particular, entenda a diferenza entre os valores dos atributos, unha condición necesaria para illar os atributos atómicos. Así, asumindo funcións pouco habituais.
4 Problema para ilustración
Digamos que tes unha pequena taberna robótica no porto. O teu segmento de mercado: mariñeiros e piratas que chegan a porto e necesitan un descanso. Vendes té con tomiño aos mariñeiros, e peites de ron e óso para peitear barbas aos piratas. O servizo na propia taberna é proporcionado por unha azafata robot e un camarero robot. Grazas á túa alta calidade e prezos baixos, expulsastes aos teus competidores, para que todos os que saian do barco acudan á túa taberna, que é a única do porto.
O complexo de sistemas de información da taberna consta do seguinte software:
- Un sistema de alerta temperá sobre un cliente que recoñece a súa categoría en función dos trazos característicos
- Sistema de control para robots azafatas e robot bartenders
- Sistema de xestión de almacén e entrega ao punto de venda
- Sistema de xestión de relacións con provedores (SURP)
Proceso:
O sistema de alerta temperá recoñece ás persoas que abandonan o barco. Se unha persoa está ben afeitada, ela identifícao como un mariñeiro; se se atopa unha persoa con barba, entón identifícase como un pirata.
Ao entrar na taberna, o convidado escoita un saúdo da anfitrioa robot acorde coa súa categoría, por exemplo: "Ho-ho-ho, querido pirata, vai á mesa No..."
O hóspede vai á mesa especificada, onde o barman robot xa preparou produtos para el de acordo coa categoría. O robot barman envía información ao sistema de almacén que a seguinte parte da entrega debe ser aumentada; o almacén IS, en función dos saldos restantes en almacenamento, xera unha solicitude de compra no sistema de xestión.
Aínda que o sistema de alerta temprana puido ser desenvolvido pola túa TI interna, o programa de xestión de robots de barras pode ser creado por un contratista externo especificamente para a túa empresa. E os sistemas de xestión de almacéns e relacións con provedores son solucións empaquetadas personalizadas do mercado.
5. Exemplos de desnormalización e o seu impacto no desenvolvemento de software
Á hora de deseñar un proceso empresarial, os expertos na temática entrevistados afirmaron por unanimidade que en todo o mundo os piratas beben ron e peitean a barba con peites de óso, e os mariñeiros beben té con tomiño e sempre están ben rapados.
Aparece un directorio de tipos de clientes con dous valores: 1 - piratas, 2 - mariñeiros, común a todo o circuíto informativo da empresa.
O sistema de notificación ao cliente almacena inmediatamente o resultado do tratamento da imaxe como o identificador (ID) do cliente recoñecido e o seu tipo: mariñeiro ou pirata.
ID de obxecto recoñecido
Categoría de cliente
100500
Pirata
100501
Pirata
100502
Mariñeiro
Notemos unha vez máis que
1. Os nosos mariñeiros son en realidade xente rapada
2. Os nosos piratas son en realidade xente barbuda
Que problemas neste caso hai que eliminar para que a nosa estrutura se esforce pola terceira forma normal:
- violación da atomicidade do atributo - Categoría de cliente
- mesturando o feito analizado e a conclusión nunha táboa
- relación funcional fixa entre atributos de diferentes entidades.
En forma normalizada, obteriamos dúas táboas:
- resultado do recoñecemento en forma dun conxunto de características establecidas,
ID de obxecto recoñecido
Pelo facial
100500
Si
100501
Si
100502
Non
- o resultado de determinar o tipo de cliente como aplicación da lóxica incrustada no SI para interpretar as características establecidas
ID de obxecto recoñecido
ID de identificación
Categoría de cliente
100500
100001
Pirata
100501
100002
Pirata
100502
100003
Mariñeiro
Como pode unha organización normalizada de almacenamento de datos facilitar o desenvolvemento dun complexo IP? Digamos que de súpeto obtén novos clientes. Que sexan piratas xaponeses que quizais non teñan barba, pero anden cun loro no ombreiro, e piratas ecoloxistas, podes recoñecelos facilmente polo perfil azul de Greta no peito esquerdo.
Os piratas ambientais, por suposto, non poden usar peites óseos e requiren un análogo feito de plástico do mar reciclado.
Debe reelaborar os algoritmos do programa de acordo coas novas entradas. Se se seguisen as regras de normalización, só tería que complementar as entradas para algunhas ramas de proceso nalgúns sistemas e crear novas ramas só para aqueles casos e naqueles IS nos que importa o vello facial. Pero, dado que non se seguiron as regras, terás que analizar todo o código, ao longo de todo o circuíto, onde se usan os valores do directorio de tipo de cliente e establecer claramente que nun caso o algoritmo debería ter en conta ao profesional. actividade do cliente, e nas demais características físicas.
Nunha forma que busca para normalizar, obteriamos dúas táboas con datos operativos e dous directorios:
- resultado do recoñecemento en forma dun conxunto de características establecidas,
ID de obxecto recoñecido
Greta no peito esquerdo
Paxaro no ombreiro
Pelo facial
100510
1
1
1
100511
0
0
1
100512
1
0
- o resultado de determinar o tipo de cliente (que sexa unha vista personalizada na que se amosan as descricións dos directorios)
A desnormalización detectada significa que os sistemas non se poidan modificar para cumprir novas condicións? Por suposto que non. Se imaxinamos que todos os sistemas de información foron creados por un equipo con cero rotación de persoal, os desenvolvementos están ben documentados e a información transfírese dentro do equipo sen perda, entón os cambios necesarios pódense facer con pouco esforzo. Pero se volvemos ás condicións orixinais do problema, borraranse 1,5 teclados só para imprimir protocolos de discusións conxuntas e outros 0,5 para tramitar procedementos de contratación.
No exemplo anterior, as tres formas normais son violadas, imos tentar violalas por separado.
Violación da primeira forma normal:
Digamos que as mercadorías son entregadas ao teu almacén desde os almacéns dos provedores mediante a recollida mediante unha gacela de 1.5 toneladas que pertence á túa taberna. O tamaño dos teus pedidos é tan pequeno en relación coa facturación dos provedores que sempre se realizan un a un sen esperar a produción. Necesitas táboas separadas cun proceso de negocio deste tipo: vehículos, tipos de vehículos, é necesario separar o plan e os feitos nos teus pedidos aos provedores abandonados?
Imaxina cantas conexións "extra" terán que escribir os teus programadores se usas o modelo a continuación para desenvolver un programa.
Digamos que decidimos que a estrutura proposta é innecesariamente complexa; no noso caso, separar o plan e o feito no rexistro de pedidos é información redundante, e a especificación da orde xerada reescríbese en función dos resultados da aceptación dos bens chegados, raramente. -a clasificación e a chegada de mercadorías de calidade inadecuada liquidan fóra do IS.
E entón un día ves como todo o salón da taberna se enche de piratas indignados e descoidados. Que pasou?
Resulta que a medida que o teu negocio creceu, tamén o teu consumo. Noutrora, tomouse a decisión da dirección de que se unha gacela estaba sobrecargada en volume e/ou peso, cousa moi rara, o provedor priorizaba a carga en favor das bebidas.
A mercancía non entregada acabou no seguinte pedido e saíu nun novo voo; a presenza dun saldo mínimo no almacén da taberna permitiu non notar as caixas desaparecidas.
O último competidor pechouse no porto, e o caso pinchado de sobrecarga de gacela, obviado pola priorización baseada na suposición da suficiencia do equilibrio mínimo e da subcarga periódica do vehículo, converteuse nunha práctica habitual. O sistema creado funcionará idealmente de acordo cos algoritmos incorporados nel e quedará privado de calquera oportunidade de rastrexar o fallo sistemático para cumprir as ordes planificadas. Só unha reputación danada e os clientes insatisfeitos poderán detectar o problema.
Un lector atento pode ter notado que a cantidade solicitada na especificación do pedido (T_ORDER_SPEC) na sección 2 e na sección 5 pode cumprir ou non o requisito da primeira forma normal. Todo depende de se, dada a variedade seleccionada de produtos, poden caer no mesmo campo unidades de medida esencialmente diferentes.
Violación da segunda forma normal:
A medida que crecen as túas necesidades, compras un par de vehículos máis de diferentes tamaños. No contexto anterior, a creación dun directorio de vehículos considerouse redundante; como resultado, todos os algoritmos de procesamento de datos que atenden ás necesidades de entrega e almacén perciben o movemento da carga do provedor ao almacén como o voo dun vehículo exclusivamente de 1,5 toneladas. gacela. Así que, xunto coa compra de vehículos novos, aínda se crea un directorio de vehículos, pero ao finalizalo terás que analizar todo o código que fai referencia ao movemento de carga para saber se en cada lugar concreto están implicadas referencias ás características. do propio vehículo do que comezou o negocio.
Violación da terceira forma normal:
Nalgún momento comeza a crear un programa de fidelización, aparece un rexistro dun cliente habitual. Por que, por exemplo, dedicar tempo a crear vistas materiais que almacenan datos agregados sobre as vendas a un cliente individual para o seu uso en informes e transferencia a sistemas analíticos, se ao inicio dun programa de fidelización todo o que interesa ao cliente pódese poñer no rexistro do cliente? ? E, efectivamente, a primeira vista, non ten sentido. Pero cada vez que a túa empresa conecte, por exemplo, novas canles de venda, debería haber alguén entre os teus analistas que lembrará que existe tal atributo de agregación.
Ao deseñar cada novo proceso, por exemplo, vendas en Internet, vendas a través de distribuidores conectados a un sistema de fidelización común, alguén debe ter en conta que todos os novos procesos deben garantir a integridade dos datos a nivel de código. Para unha base de datos industrial con mil táboas, isto parece unha tarefa imposible.
Un desenvolvedor experimentado, por suposto, sabe como eliminar todos os problemas mencionados anteriormente, pero, na miña opinión, a tarefa dun analista experimentado non é sacalos á luz.
Gustaríame expresar o meu agradecemento ao desenvolvedor líder Evgeniy Yarukhin polos seus valiosos comentarios durante a preparación da publicación.
Literatura
Connolly Thomas, Begg Caroline. Base de datos. Deseño, implementación e apoio. Teoría e práctica
Fonte: www.habr.com