🧑🏼 👓 ✅ Desnormalização dos sistemas de banco de dados ERP e seu impacto no desenvolvimento de software: abra uma taberna no Tortuga ⛳️ 👋🏻 ➿

Olá! Meu nome é Andrey Semenov, sou analista sênior da Sportmaster. Neste post, quero levantar a questão da desnormalização dos sistemas de banco de dados ERP. Vamos considerar as condições gerais, bem como um exemplo específico - digamos que será uma maravilhosa taberna de monopólio para piratas e marinheiros. Em que piratas e marinheiros precisam ser servidos de maneira diferente, porque as idéias sobre os padrões bonitos e de consumo desses bons mestres são significativamente diferentes.

Como fazer todo mundo feliz? Como não ficar louco projetando e mantendo esse sistema? O que fazer se não apenas piratas e marinheiros familiares começarem a chegar à taverna? Tudo está em risco. Mas vamos em ordem.

1. Limitações e premissas

Todas as opções acima se aplicam apenas aos bancos de dados relacionais. Bem iluminados, inclusive na Internet, os efeitos da desnormalização na forma de anomalias de modificação, exclusão e inserção não são considerados. Além do escopo da publicação, ainda existem casos em que a desnormalização é comum, com exemplos clássicos: número de série e passaporte, data e hora e assim por diante.

O post usa definições intuitivas e praticamente aplicáveis de formas normais, sem referência a termos matemáticos. Na forma em que eles podem ser aplicados ao exame de processos de negócios reais (BP) e ao design de software industrial.

Há uma opinião de que o design de data warehouses, ferramentas de relatório e acordos de integração (que usam apresentação tabular de informações) difere do design de sistemas de banco de dados ERP, pois a facilidade de consumo e o uso de desnormalização consciente para alcançá-lo podem ter precedência sobre a proteção de integridade dados. Partilho essa opinião e a descrição abaixo se aplica exclusivamente a modelos de dados mestre e dados transacionais de sistemas ERP.

A explicação das formas normais é dada por um exemplo compreensível em nível familiar para a maioria dos leitores. No entanto, como ilustração ilustrativa, nos parágrafos 4-5, a tarefa "inventada" enfatizada foi usada deliberadamente. Se você não fizer isso e usar algum tipo de exemplo de livro didático, por exemplo, o mesmo modelo de armazenamento de pedidos da cláusula 2, poderá encontrar-se em uma situação em que a atenção do leitor será desviada da decomposição proposta do processo em um modelo, para a experiência pessoal e a percepção de como processos e modelos de armazenamento de dados em IP devem ser construídos. Em outras palavras, pegue dois analistas de TI qualificados, deixe um fornecer serviços aos logísticos que transportam passageiros e o outro aos logísticos que transportam máquinas para a produção de microchips. Peça a eles, sem discutir a BP pré-automatizada, para criar um modelo de dados para armazenar informações sobre o voo ferroviário.

Há uma probabilidade diferente de zero de que, nos modelos propostos, você encontrará não apenas um conjunto visivelmente diferente de atributos, mas também conjuntos diferentes de entidades, porque cada analista confiará em seus processos e tarefas habituais. E dizer em tal situação qual modelo é "correto" é impossível, porque não há critério de avaliação.

2. Formas normais

A primeira forma normal do banco de dados requer a atomicidade de todos os atributos.
Em particular, se o objeto A tiver atributos não chave a e b, de modo que c = f (a, b) e na tabela que descreve o objeto A você armazene o valor do atributo c, a primeira forma normal será violada no banco de dados. Por exemplo, se a especificação do pedido especificar uma quantidade cujas unidades de medida dependem do tipo de produto: em um caso, podem ser peças, nos outros litros, no terceiro pacote composto por peças (no modelo acima Good_count_WR), a atomicidade dos atributos é violada no banco de dados. Nesse caso, para dizer como deve ser o arbusto das tabelas para a especificação do pedido, você precisa de uma descrição direcionada do processo de trabalho no IP e, como os processos podem ser diferentes, pode haver muitas versões "corretas".

A segunda forma normal do banco de dadosrequer conformidade com o primeiro formulário e sua própria tabela para cada entidade relacionada ao processo de trabalho em PI. Se em uma tabela houver dependências c = f1 (a) ed = f2 (b) e não houver dependência c = f3 (b), a segunda forma normal será violada na tabela. No exemplo acima, na tabela "Pedido", não há relação entre o pedido e o endereço. Mude o nome da rua ou cidade e você não terá nenhuma influência sobre os atributos essenciais da ordem.

A terceira forma normal do banco de dadosrequer conformidade com a segunda forma normal e a ausência de dependências funcionais entre atributos de diferentes entidades. Essa regra pode ser formulada da seguinte maneira: "tudo o que pode ser calculado deve ser calculado". Em outras palavras, se houver dois objetos A e B. Na tabela que armazena os atributos do objeto A, o atributo C é exibido, o objeto B possui o atributo b, de modo que c = f4 (b) existe, a terceira forma normal é violada. No exemplo abaixo, o atributo "Número de peças" (Total_count_WR) no registro do pedido afirma claramente violar a terceira forma normal

3. Minha abordagem para aplicar a normalização

1. Somente o processo de negócios automatizado de destino pode fornecer à análise critérios para identificar entidades e atributos ao criar um modelo de armazenamento de dados. Criar um modelo de processo é um pré-requisito para criar um modelo de dados normal.

2. A obtenção da terceira forma normal, no sentido estrito, pode ser impraticável na prática real de criação de sistemas ERP quando parte ou todas as seguintes condições são atendidas:

processos automatizados raramente estão sujeitos a alterações,
os prazos de pesquisa e desenvolvimento são apertados,
os requisitos de integridade dos dados são relativamente baixos (erros em potencial no software industrial não levam à perda de dinheiro ou de clientes pelo cliente do software)
etc.

Sob as condições descritas, os custos de identificação, uma descrição do ciclo de vida de alguns objetos e seus atributos podem não ser justificados do ponto de vista da eficiência econômica.

3. Quaisquer conseqüências da desnormalização do modelo de dados no IP já criado podem ser interrompidas por um estudo preliminar completo do código e do teste.

4. A desnormalização é uma maneira de transferir custos de mão-de-obra do estágio de pesquisa de fontes de dados e design de um processo de negócios para o estágio de desenvolvimento, do período de implementação ao período de desenvolvimento do sistema.

5. É aconselhável buscar a terceira forma normal do banco de dados se:

É difícil prever a direção da mudança nos processos de negócios automatizados
Existe uma divisão permeável do trabalho dentro da equipe de implementação e / ou desenvolvimento
Os sistemas incluídos no circuito de integração estão se desenvolvendo de acordo com seus próprios planos.
A inconsistência dos dados pode levar à perda de clientes ou dinheiro da empresa

6. O design do modelo de dados deve ser realizado pelo analista apenas em conexão com os modelos do processo de negócios de destino e o processo em IP. Se um desenvolvedor estiver envolvido no projeto de um modelo de dados, ele terá que mergulhar na área de assunto a tal ponto que, em particular, ele precisará entender a diferença entre valores de atributo - uma condição necessária para distinguir atributos atômicos. Assim, assumindo funções incomuns.

4 Tarefa para ilustração

Digamos que você tenha uma pequena taberna robótica no porto. Seu segmento de mercado: marinheiros e piratas que visitam o porto e precisam descansar. Para os marinheiros, você vende chá com tomilho, e para piratas, rum e pentes de ossos para pentear sua barba. O serviço na taberna em si é fornecido por um robô anfitrião e um robô barman. Devido à alta qualidade e aos preços baixos, você superou todos os seus concorrentes, para que todos que saem do navio cheguem à sua taverna, que é a única no porto.

O complexo de sistemas de informação da taberna consiste no seguinte software:

Sistema de aviso prévio do cliente que reconhece sua categoria por recursos característicos
Sistema de gerenciamento para robôs hostess e robôs barman
Sistema de gerenciamento de armazém e ponto de entrega
Sistema de Gerenciamento de Relacionamento com Fornecedores (SMSS)

Processo:

O sistema de alerta precoce detecta pessoas que saem do navio. Se uma pessoa está barbeada, ela o define como um marinheiro, se uma barba é encontrada, então ele é definido como um pirata.

Ao entrar na taberna, o hóspede ouve uma saudação do robô anfitrião de acordo com sua categoria, por exemplo: “Ho-ho-ho, querido pirata, vá para a tabela nº ...” O

hóspede vai para a mesa indicada, onde o robô-barman já se preparou para ele bens de acordo com a categoria. O robô barman transmite informações ao sistema do armazém que a próxima parte da entrega deve ser aumentada; o IS do armazém, com base no armazenamento restante, forma um aplicativo para compra no sistema de controle.

Deixe a sua TI interna desenvolver um sistema de aviso prévio, um contratado externo especialmente projetado para a sua empresa para criar um programa de gerenciamento de robôs de barras. E os sistemas de gerenciamento de armazém e relacionamento com fornecedores são soluções in a box personalizadas do mercado.

5. Exemplos de desnormalização e seu impacto no desenvolvimento de software

Ao projetar um processo de negócios, os especialistas entrevistados declararam por unanimidade que piratas de todo o mundo bebem rum e penteiam as barbas com crista óssea, e marinheiros bebem chá com tomilho e são sempre barbeados sem problemas.

Um diretório de tipos de clientes aparece com dois valores: 1 - piratas, 2 - marinheiros, comuns a todo o circuito de informações da empresa.

O sistema de notificação do cliente salva imediatamente o resultado do processamento da imagem como o identificador (ID) do cliente reconhecido e seu tipo: marinheiro ou pirata.

ID do objeto reconhecido	Categoria de cliente
100500	Pirata
100501	Pirata
100502	Marinheiro

Mais uma vez, observamos que

1. Nossos marinheiros são na verdade barbeados
2. Nossos piratas são na verdade barbudos

Que problemas nesse caso precisam ser resolvidos para que nossa estrutura se esforce para uma terceira forma normal:

violação atômica do atributo - categoria do cliente
mistura do fato analisado e conclusão em uma tabela
relação funcional fixa entre atributos de diferentes entidades.

Na forma normalizada, teríamos duas tabelas:

resultado de reconhecimento na forma de um conjunto de recursos estabelecidos,

ID do objeto reconhecido	Pêlos faciais
100500	sim
100501	sim
100502	Não

o resultado da determinação do tipo de cliente como uma aplicação da lógica incorporada no SI para a interpretação dos sinais estabelecidos

ID do objeto reconhecido	ID de identificação	Categoria de cliente
100500	100001	Pirata
100501	100002	Pirata
100502	100003	Marinheiro

Como uma organização de armazenamento normalizada facilita o desenvolvimento de um complexo de IP? Digamos que de repente você tenha novos clientes. Sejam piratas japoneses que podem não ter barba, mas andam com um papagaio nos ombros, e piratas ambientais, você pode reconhecê-los facilmente pelo perfil azul de Greta no peito esquerdo.

Os piratas ambientais, é claro, não podem usar cristas ósseas e requerem um análogo de plástico marinho reciclado.

Você precisa refazer os algoritmos dos programas de acordo com a nova entrada. Se as regras de normalização fossem atendidas, você teria apenas que adicionar entradas para algumas ramificações do processo e criar novas ramificações apenas para os casos e IPs em que a linha do cabelo na face é importante. Mas, como as regras não foram seguidas, você terá que analisar o código inteiro, em todo o circuito, onde os valores do diretório de tipos de clientes são usados e estabelecer inequivocamente que, em um caso, o algoritmo deve levar em consideração as atividades profissionais do cliente e os outros recursos físicos.

Em uma visão que tende a normalizar, obteríamos duas tabelas com dados operacionais e dois diretórios:

resultado de reconhecimento na forma de um conjunto de recursos estabelecidos,


100510	1	1	1
100511	0	0	1
100512		1	0

( , )

A desnormalização detectada significa que os sistemas não podem ser modificados sob novas condições? Claro que não. Se você imagina que todos os IPs foram criados por uma equipe com rotatividade zero, o desenvolvimento está bem documentado e as informações da equipe são transmitidas sem perdas, as alterações necessárias podem ser produtos com um esforço negligentemente baixo. Porém, se retornarmos às condições iniciais da tarefa, apenas 1,5 teclados e outros 0,5 para registro de procedimentos de compras serão apagados apenas para imprimir protocolos de discussões conjuntas.

No exemplo acima, todas as três formas normais são violadas, vamos tentar violá-las individualmente.

Violação da primeira forma normal:

Suponha que as mercadorias sejam entregues em seu armazém a partir de armazéns de fornecedores às suas próprias custas, usando uma gazela de 1,5 tonelada que pertence à sua taberna. O tamanho de seus pedidos é tão pequeno em relação à rotatividade de fornecedores que eles sempre são executados individualmente, sem aguardar a produção. Você precisa de tabelas separadas para esse PSU: veículos, tipos de veículos, precisa separar o plano e o fato em seus pedidos para fornecedores que partiram?

Imagine quantas conexões "extras" seus programadores terão que escrever se você usar o modelo abaixo para desenvolver um programa.

Suponha que tenhamos decidido que a estrutura proposta é desnecessariamente complicada, para o nosso caso, separar o plano e o fato no registro do pedido são informações redundantes, e a especificação do pedido gerada é substituída pelos resultados da aceitação das mercadorias recebidas, rara triagem e chegada de mercadorias de qualidade inadequada.
E então um dia você vê como todo o salão da taverna está cheio de piratas indignados e desleixados. O que aconteceu?

Aconteceu que, juntamente com o crescimento do seu negócio, o consumo também cresceu. Uma vez, foi tomada uma decisão de gerenciamento de que, se uma gazela estava sobrecarregada em volume e / ou peso, o que era extremamente raro, o fornecedor priorizava o carregamento em favor de bebidas.

As mercadorias não entregues caíram na ordem seguinte e partiram em um novo voo; a presença de um saldo irredutível no armazém da taberna tornou possível não notar casos perfurados.

O último concorrente fechado no porto, e o caso de sobrecarga de gazela perfurada, contornado por priorização com base no pressuposto da suficiência do equilíbrio mínimo e subcarga periódica do veículo, tornaram-se prática comum. O sistema criado funcionará idealmente de acordo com os algoritmos estabelecidos nele e será privado de qualquer oportunidade de rastrear o não cumprimento sistemático de ordens planejadas. Somente uma reputação danificada e clientes insatisfeitos poderão detectar o problema.

Um leitor atento deve ter notado que a quantidade solicitada na especificação do pedido (T_ORDER_SPEC) na seção 2 e na seção 5 pode ou não atender ao requisito da primeira forma normal. Tudo depende se, para um sortimento selecionado de mercadorias, unidades de medida essencialmente diferentes podem cair no mesmo campo.

Violação da segunda forma normal:

À medida que suas necessidades aumentam, você recebe mais alguns veículos de tamanhos diferentes. No contexto acima, a criação de um diretório de veículos foi considerada redundante, como resultado, todos os algoritmos de manipulação de dados que atendem às necessidades de entrega e armazém percebem o movimento de mercadorias do fornecedor para o armazém como um voo de apenas uma gazela de 1,5 tonelada. Assim, junto com a compra de veículos novos, você ainda cria um diretório de veículos, mas, ao finalizar, terá que analisar todo o código que se refere ao movimento da carga para descobrir se há referências às características do carro a partir do qual negócio iniciado.

Violação da terceira forma normal:

Em algum momento, você começa a criar um programa de fidelidade, um registro regular do cliente é exibido. Por que, por exemplo, dedicar tempo criando representações materiais que armazenam dados de vendas agregados para um cliente individual para serem usados nos relatórios e transferidos para sistemas analíticos, se no início do programa de fidelidade tudo o que interessa ao cliente pode ser colocado nos próprios registros do cliente? E, de fato, não há sentido à primeira vista. Porém, toda vez que sua empresa conectar, por exemplo, novos canais de vendas, deve haver alguém entre seus analistas que se lembre de que existe esse atributo de agregação.

Ao projetar cada novo processo, por exemplo, vender na Internet, vender através de distribuidores conectados a um sistema de fidelidade comum, alguém deve ter em mente que todos os novos processos devem garantir a integridade dos dados no nível do código. Para um banco de dados industrial com mil tabelas, isso parece uma tarefa impossível.

Um desenvolvedor experiente, é claro, sabe como parar todos os problemas mencionados acima, mas, na minha opinião, a tarefa de um analista experiente não é chamar a atenção deles.

Quero expressar minha gratidão pelo valioso feedback durante a preparação da publicação ao principal desenvolvedor Evgeny Yarukhin.

Literatura

https://habr.com/en/post/254773/
Connolly Thomas, Begg Carolyn. Base de dados. Projeto, implementação e manutenção. A teoria e a prática