Olá! Meu nome é Andrey Semenov, sou analista sênior da Sportmaster. Neste post quero levantar a questão da desnormalização dos bancos de dados do sistema ERP. Veremos as condições gerais, bem como um exemplo específico - digamos que seria uma maravilhosa taverna monopolista para piratas e marinheiros. Em que piratas e marinheiros devem ser atendidos de forma diferenciada, pois as ideias de beleza e padrões de consumo desses bons senhores são significativamente diferentes.
Como fazer todo mundo feliz? Como você pode evitar enlouquecer ao projetar e manter tal sistema? O que fazer se não apenas os piratas e marinheiros habituais começarem a chegar à taverna?
Tudo está sob corte. Mas vamos em ordem.
1. Limitações e suposições
Todos os itens acima se aplicam apenas a bancos de dados relacionais. As consequências da desnormalização na forma de anomalias de modificação, exclusão e inserção, que são bem cobertas, inclusive na Internet, não são consideradas. Fora do âmbito desta publicação há casos em que a desnormalização é um lugar comum, com exemplos clássicos: série e número do passaporte, data e hora, etc.
A postagem usa definições intuitivas e praticamente aplicáveis de formas normais, sem referência a termos matemáticos. Na forma como podem ser aplicados ao exame de processos de negócios (BP) reais e ao projeto de software industrial.
Argumenta-se que o design de data warehouses, ferramentas de relatórios e acordos de integração (que usam representações tabulares de informações) difere do design de bancos de dados de sistemas ERP porque a facilidade de consumo e o uso da desnormalização consciente para alcançá-lo podem ter precedência sobre a integridade. dados de proteção. Partilho desta opinião, e o que é descrito abaixo aplica-se apenas aos dados mestre e aos modelos de dados transacionais dos sistemas ERP.
Uma explicação das formas normais é dada usando um exemplo que é compreensível para a maioria dos leitores no nível cotidiano. No entanto, como ilustração visual, nos parágrafos 4-5, uma tarefa deliberadamente “fictícia” foi usada deliberadamente. Se você não fizer isso e pegar algum exemplo de livro, por exemplo, o mesmo modelo de armazenamento de pedidos do ponto 2, você poderá se encontrar em uma situação em que o foco do leitor será desviado da decomposição proposta do processo em um modelo, à experiência pessoal e à percepção de como devem ser construídos processos e modelos de armazenamento de dados em SI. Por outras palavras, pegue dois analistas de TI qualificados, deixe um prestar serviços a logísticos que transportam passageiros, o outro a logísticos que transportam máquinas para a produção de microchips. Peça-lhes, sem discutir antecipadamente os BPs automatizados, que criem um modelo de dados para armazenar informações sobre uma viagem ferroviária.
Há uma probabilidade diferente de zero de que nos modelos propostos você encontre não apenas um conjunto de atributos visivelmente diferente, mas também conjuntos de entidades divergentes, porque cada analista contará com os processos e tarefas que lhe são familiares. E em tal situação é impossível dizer qual modelo é “correto”, porque não existe critério de avaliação.
2. Formas normais
Primeira forma normal do banco de dados requer atomicidade de todos os atributos.
Em particular, se o objeto A tiver atributos não-chave a e b, tais que c=f(a,b) e na tabela que descreve o objeto A você armazena o valor do atributo c, então a primeira forma normal é violada no banco de dados . Por exemplo, se a especificação do pedido indica uma quantidade cujas unidades de medida dependem do tipo de produto: em um caso podem ser peças, em outro litros, em um terceiro embalagens compostas por peças (no modelo acima Good_count_WR) , então a atomicidade dos atributos é violada no banco de dados. Nesse caso, para dizer qual deve ser o cluster de tabelas da especificação do pedido, é necessária uma descrição direcionada do processo de trabalho no SI e, como os processos podem ser diferentes, pode haver muitas versões “corretas”.
Segunda forma normal do banco de dados exige o cumprimento do primeiro formulário e de tabela própria para cada entidade relacionada com o processo de trabalho no SI. Se em uma tabela houver dependências c=f1(a) e d=f2(b) e não houver dependência c=f3(b), então a segunda forma normal é violada na tabela. No exemplo acima, não há dependência entre pedido e endereço na tabela Pedidos. Altere o nome da rua ou cidade e você não terá efeito nos atributos essenciais do pedido.
Terceiro banco de dados de forma normal requer o cumprimento da segunda forma normal e a ausência de dependências funcionais entre atributos de diferentes entidades. Esta regra pode ser formulada da seguinte forma: “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 é manifestado, e o objeto B possui o atributo b, de modo que c=f4(b) existe, então a terceira forma normal é violado. No exemplo abaixo, o atributo Quantidade de Peças (Total_count_WR) no registro do pedido afirma claramente violar a terceira forma normal
3. Minha abordagem para aplicar normalização
1. Somente um processo de negócios automatizado alvo pode fornecer ao analista critérios para identificar entidades e atributos ao criar um modelo de armazenamento de dados. A criação de um modelo de processo é um pré-requisito para a criação de um modelo de dados normal.
2. Alcançar a terceira forma normal em sentido estrito pode não ser prático na prática real de criação de sistemas ERP se algumas ou todas as seguintes condições forem atendidas:
- processos automatizados raramente estão sujeitos a alterações,
- os prazos para pesquisa e desenvolvimento são apertados,
- os requisitos de integridade de dados são relativamente baixos (erros potenciais em software industrial não levam à perda de dinheiro ou de clientes por parte do cliente do software)
- и т.п.
Nas condições descritas, os custos de identificação e descrição do ciclo de vida de alguns objetos e dos seus atributos podem não ser justificados do ponto de vista da eficiência económica.
3. Quaisquer consequências da desnormalização do modelo de dados num SI já criado podem ser mitigadas por um estudo preliminar aprofundado do código e testes.
4. A desnormalização é uma forma de transferir os custos trabalhistas da fase de pesquisa de fontes de dados e concepção de um processo de negócios para a fase de desenvolvimento, do período de implementação para o período de desenvolvimento do sistema.
5. É aconselhável buscar a terceira forma normal de banco de dados se:
- A direção da mudança nos processos de negócios automatizados é difícil de prever
- Há uma fraca divisão de trabalho dentro da equipe de implementação e/ou desenvolvimento
- Os sistemas incluídos no circuito de integração desenvolvem-se de acordo com seus próprios planos
- A inconsistência de dados pode resultar na perda de clientes ou dinheiro de uma empresa
6. O desenho de um modelo de dados deve ser realizado por um analista apenas em conexão com os modelos do processo de negócio alvo e do processo no SI. Se um desenvolvedor estiver projetando um modelo de dados, ele terá que mergulhar na área temática a tal ponto que, em particular, entenda a diferença entre os valores dos atributos - uma condição necessária para isolar atributos atômicos. Assim, assumindo funções inusitadas.
4 Problema para ilustração
Digamos que você tenha uma pequena taverna robótica no porto. Seu segmento de mercado: marinheiros e piratas que chegam ao porto e precisam de uma pausa. Você vende chá com tomilho aos marinheiros e rum e pentes de osso para pentear a barba aos piratas. O serviço na própria taberna é prestado por uma anfitriã robô e um bartender robô. Graças à sua alta qualidade e preços baixos, você expulsou seus concorrentes, para que todos que saem do navio venham para sua taberna, que é a única do porto.
O complexo de sistemas de informação da taberna consiste no seguinte software:
- Um sistema de alerta precoce sobre um cliente que reconhece sua categoria com base em características
- Sistema de controle para recepcionistas robôs e bartenders robôs
- Sistema de gerenciamento de armazém e entrega ao ponto de venda
- Sistema de Gestão de Relacionamento com Fornecedores (SURP)
Processo:
O sistema de alerta precoce reconhece pessoas que saem do navio. Se uma pessoa estiver barbeada, ela a identifica como um marinheiro; se uma pessoa tiver barba, ela será identificada como um pirata.
Ao entrar na taberna, o hóspede ouve uma saudação da anfitriã robô de acordo com sua categoria, por exemplo: “Ho-ho-ho, querido pirata, vá para a mesa nº...”
O convidado dirige-se à mesa indicada, onde o robô bartender já preparou para ele produtos de acordo com a categoria. O robô bartender transmite ao sistema do armazém a informação de que a próxima parcela da entrega deve ser aumentada; o IS do armazém, com base nos saldos restantes em armazenamento, gera um pedido de compra no sistema de gestão.
Embora o sistema de alerta precoce possa ter sido desenvolvido pela sua TI interna, o programa de gerenciamento do robô do bar pode ter sido criado por um contratante externo especificamente para o seu negócio. E os sistemas de gestão de armazéns e relacionamento com fornecedores são soluções customizadas do mercado.
5. Exemplos de desnormalização e seu impacto no desenvolvimento de software
Ao desenhar um processo de negócio, os especialistas entrevistados afirmaram unanimemente que em todo o mundo os piratas bebem rum e penteiam a barba com pentes de osso, e os marinheiros bebem chá com tomilho e estão sempre barbeados.
Aparece um diretório de tipos de clientes com dois valores: 1 - piratas, 2 - marinheiros, comuns a todo o circuito de informação da empresa.
O sistema de notificação do cliente armazena 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
Notemos mais uma vez que
1. Nossos marinheiros são, na verdade, pessoas barbeadas
2. Nossos piratas são na verdade pessoas barbudas
Quais problemas neste caso precisam ser eliminados para que nossa estrutura busque a terceira forma normal:
- violação de atomicidade de atributo - Categoria do cliente
- misturar o fato analisado e a conclusão em uma tabela
- relacionamento funcional fixo entre atributos de diferentes entidades.
Na forma normalizada, obteríamos duas tabelas:
- resultado de reconhecimento na forma de um conjunto de características estabelecidas,
ID do objeto reconhecido
Pêlos faciais
100500
Sim
100501
Sim
100502
Não
- o resultado da determinação do tipo de cliente como aplicação da lógica embutida no SI para interpretar as características estabelecidas
ID do objeto reconhecido
ID de identificação
Categoria de cliente
100500
100001
Pirata
100501
100002
Pirata
100502
100003
Marinheiro
Como uma organização normalizada de armazenamento de dados pode facilitar o desenvolvimento de um complexo IP? Digamos que você de repente consiga novos clientes. Que sejam piratas japoneses que podem não ter barba, mas andam com um papagaio no ombro, e piratas ambientalistas, você pode reconhecê-los facilmente pelo perfil azul de Greta no lado esquerdo do peito.
Os piratas ambientais, naturalmente, não podem usar pentes de osso e exigem um análogo feito de plástico marinho reciclado.
Você precisa retrabalhar os algoritmos do programa de acordo com as novas entradas. Se as regras de normalização fossem seguidas, então você só teria que complementar as entradas para algumas ramificações do processo em alguns sistemas e criar novas ramificações apenas para os casos e naqueles SI onde os pelos faciais são importantes. Mas, como as regras não foram seguidas, você terá que analisar todo o código, ao longo de todo o circuito, onde são utilizados os valores do diretório do tipo cliente e estabelecer claramente que em um caso o algoritmo deve levar em consideração o profissional atividade do cliente e nas demais características físicas.
De uma forma que procura para normalizado, obteríamos duas tabelas com dados operacionais e dois diretórios:
- resultado de reconhecimento na forma de um conjunto de características estabelecidas,
ID do objeto reconhecido
Greta no peito esquerdo
Pássaro no ombro
Pêlos faciais
100510
1
1
1
100511
0
0
1
100512
1
0
- o resultado da determinação do tipo de cliente (seja uma visualização personalizada na qual as descrições dos diretórios são exibidas)
A desnormalização detectada significa que os sistemas não podem ser modificados para atender às novas condições? Claro que não. Se imaginarmos que todos os sistemas de informação foram criados por uma equipa com zero rotatividade de pessoal, os desenvolvimentos são bem documentados e a informação é transferida dentro da equipa sem perdas, então as alterações necessárias podem ser feitas com pouco esforço. Mas se voltarmos às condições originais do problema, 1,5 teclados serão apagados apenas para impressão de protocolos de discussões conjuntas e outros 0,5 para processamento de procedimentos de compras.
No exemplo acima, todas as três formas normais são violadas, vamos tentar violá-las separadamente.
Violação da primeira forma normal:
Digamos que as mercadorias sejam entregues em seu armazém a partir dos armazéns dos fornecedores por meio de coleta usando uma gazela de 1.5 tonelada que pertence à sua taverna. O tamanho dos seus pedidos é tão pequeno em relação ao volume de negócios dos fornecedores que eles são sempre concluídos individualmente, sem esperar pela produção. Você precisa de tabelas separadas com esse processo de negócio: veículos, tipos de veículos, é necessário separar plano e 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.
Digamos que decidimos que a estrutura proposta é desnecessariamente complexa; no nosso caso, separar o plano e o fato no registro do pedido é uma informação redundante, e a especificação do pedido gerada é reescrita com base nos resultados da aceitação das mercadorias recebidas, raros erros -a classificação e a chegada de mercadorias de qualidade inadequada são liquidadas fora do SI.
E então um dia você vê como todo o salão da taverna está cheio de piratas indignados e desleixados. O que aconteceu?
Acontece que à medida que o seu negócio crescia, também crescia o seu consumo. Era uma vez uma decisão gerencial de que se uma gazela estivesse sobrecarregada em volume e/ou peso, o que era extremamente raro, o fornecedor priorizaria a carga em favor das bebidas.
A mercadoria não entregue foi parar no pedido seguinte e partiu em novo voo, a presença de saldo mínimo no armazém da taberna permitiu não notar casos perdidos.
O último concorrente fechou no porto, e o caso furado de sobrecarga da gazela, contornado pela priorização baseada no pressuposto da suficiência do saldo mínimo e da subcarga periódica do veículo, tornou-se prática comum. O sistema criado funcionará idealmente de acordo com os algoritmos nele incorporados e será privado de qualquer oportunidade de rastrear a falha sistemática no cumprimento dos pedidos planejados. Somente uma reputação prejudicada e clientes insatisfeitos serão capazes de 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, dada a gama de produtos selecionada, unidades de medida essencialmente diferentes podem cair no mesmo campo.
Violação da segunda forma normal:
À medida que suas necessidades aumentam, você compra 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 processamento de dados que atendem às necessidades de entrega e armazém percebem o movimento de carga do fornecedor para o armazém como o voo de um avião exclusivamente de 1,5 tonelada. gazela. Então, junto com a compra de veículos novos, você ainda cria um diretório de veículos, mas ao finalizá-lo terá que analisar todo o código que faz referência à movimentação de carga para saber se em cada local específico estão implícitas referências às características do próprio veículo a partir do qual o negócio começou.
Violação da terceira forma normal:
Em algum momento você começa a criar um programa de fidelidade, aparece um registro de um cliente regular. Por que, por exemplo, gastar tempo criando visualizações de materiais que armazenam dados agregados sobre vendas para um cliente individual para uso em relatórios e transferência para sistemas analíticos, se no início de um programa de fidelidade tudo que interessa ao cliente pode ser colocado no registro do cliente ? E, de fato, à primeira vista, não faz sentido. Mas toda vez que seu negócio conectar, por exemplo, novos canais de vendas, deverá haver alguém entre seus analistas que se lembrará que existe tal atributo de agregação.
Ao desenhar cada novo processo, por exemplo, vendas na Internet, vendas através de distribuidores ligados a um sistema de fidelização comum, deve-se ter em mente que todos os novos processos devem garantir a integridade dos dados ao nível do código. Para um banco de dados industrial com mil tabelas, esta parece uma tarefa impossível.
Um desenvolvedor experiente, claro, sabe como eliminar todos os problemas mencionados acima, mas, na minha opinião, a tarefa de um analista experiente não é trazê-los à luz.
Gostaria de expressar minha gratidão ao desenvolvedor líder Evgeniy Yarukhin por seu valioso feedback durante a preparação da publicação.
Literatura
Connolly Thomas, Begg Caroline. Base de dados. Design, implementação e suporte. A teoria e a prática
Fonte: habr.com