Introdução
Hoje em dia, o argumento mais comum entre os gestores de armazém de dados é determinar qual o esquema mais orientado para o desempenho. Contudo, é fundamental saber que nenhuma das abordagens de normalização ou desnormalização pode ser anulada, uma vez que ambas têm prós e contras.
Por isso, antes de detalhar as suas diferenças através de casos de uso, vamos olhar para a normalização e desnormalização.
Normalização
Normalização é o acto de reorganização de dados num armazém de dados para satisfazer dois requisitos fundamentais:
- Remover a redundância de dados, armazenando todos os dados estritamente num só local
- Asegurar a dependência de dados i.e. todos os itens de dados correspondentes são armazenados em conjunto
A normalização é crítica por várias razões, mas principalmente porque permite que os armazéns de dados ocupem o mínimo espaço de disco possível. Isto resulta num melhor desempenho.
Denormalização
Esta estratégia de armazenamento de dados é utilizada para melhorar a funcionalidade de uma infra-estrutura de base de dados. A desnormalização chama dados redundantes a um armazém de dados normalizado para minimizar o tempo de execução de consultas específicas de base de dados que unem dados de muitas tabelas em uma.
De facto, a interpretação da desnormalização depende da normalização, que se caracteriza como o acto de organizar uma base de dados em tabelas, removendo repetições para implementar um determinado caso de utilização. Lembre-se, uma base de dados desnormalizada nunca deve ser confundida com uma base de dados que nunca foi normalizada.
Normalização e Desnormalização – Casos de Utilização
Amazon DynamoDB
A opção de um esquema normalizado ou desnormalizado numa base de dados NoSQL, tal como DynamoDB, depende do seu caso de utilização. Contudo, os profissionais recomendam a concepção das suas tabelas DynamoDB com um esquema desnormalizado devido às duas seguintes razões:
- DynamoDB da Amazon é sem esquema, e quando uma tabela é criada nesta base de dados, é-lhe exigido que especifique apenas os atributos primários da chave, como chave de ordenação e chave de partição, ou apenas a chave de partição. Além disso, não é necessário definir previamente quaisquer outros atributos.
- li>DynamoDB não endossa operações de junção através de tabelas.
não obstante, existem certas situações em que se pode utilizar um esquema normalizado.
Sistema Normalizado pode ser considerado Quando:
- é necessário armazenar itens com tamanhos superiores a 400 KB. Contudo, o tamanho máximo de item permitido no DynamoDB é de 400 KB. Portanto, atributos maiores podem ser armazenados na Amazon S3 ou numa tabela individual DynamoDB.
- Você está à espera de vários padrões de acesso. Por exemplo, pegue numa tabela de encomenda de produtos, que é acedida cada vez que um cliente encomenda um produto. Agora pegue numa tabela de disponibilidade de produtos, a qual só é acedida ocasionalmente. Ambas as tabelas têm leitura diferente &Requisitos de capacidade de escrita.
- As suas aplicações efectuam várias actualizações. Na Amazon DynamoDB, uma WCU (unidade de capacidade de escrita) é delineada como uma unidade de escrita/segundo, para um item de 1 KB em tamanho. Além disso, numerosas escritas de itens de dados superiores a 1 KB influenciarão o número de WCUs esgotadas por escrita. Além disso, mesmo que se esteja a actualizar apenas um atributo, o cálculo da WCU depende do tamanho do item completo.
Esquema desnormalizado pode ser considerado Quando:
- li>Itens pequenos com poucos atributos são necessários para serem armazenados. Além disso, o tamanho do item não deve exceder 4 KB para leituras. Lembre-se, uma RCU (unidade de capacidade de leitura) é especificada como uma leitura/segundo para um item com menos de 4 KB de tamanho. Alternativamente, para leituras, o tamanho do item não deve exceder 1 KB.
As suas aplicações são necessárias para ler e escrever dados num ambiente rico em tráfego, sem considerar a sincronização e consistência dos dados em várias tabelas.
Normalização Caso de Utilização em Armazenamento de Dados de Cuidados de Saúde
Hoje em dia, a normalização de dados desempenha um papel mais amplo numa série de cenários de cuidados de saúde, uma vez que oferece um quadro de interpretação de dados para facilitar vários casos de utilização.
Para simplificar, o seguinte é uma área comum que emprega normalização de dados:
Fazer Dados Úteis Dentro do Armazém de Dados
Um típico armazém de dados vai buscar dados de pacientes a uma série de sistemas de TI e clínicos. É porque as organizações querem centralizar os seus projectos de relatórios, programas de qualidade, utilizar dados para engendrar modelos preditivos, e utilizar reclamações e dados clínicos para supervisionar o processo de prestação de cuidados.
Então, quais são as aplicações dos dados normalizados nos cuidados de saúde?
Vamos dizer que um hospital pretende fazer evoluir os níveis de hemoglobina A1C para uma demografia de pacientes diabéticos. No entanto, é comum que os sistemas laboratoriais ponham em prática os seus códigos de laboratório de propriedade pessoal que não estão normalizados no LOINC. O armazém de dados do hospital pode muito bem possuir resultados do laboratório A codificados como 4321/Hgb A1c sangue. No mesmo repositório, o hospital pode ter resultados LAB B já padronizados como código 17855-8 no LOINC.
Both representam resultados laboratoriais A1C, mas os dados devem ser normalizados para um padrão como o LOINC para que o sistema de saúde interprete e analise correctamente tanto os resultados laboratoriais.
Denormalização Use-Case
Considerar uma plataforma de blogging onde se armazenariam publicações e utilizadores. Os posts estão a referenciar os seus autores através de um campo Author_ID. Estas duas entidades seriam armazenadas em colecções separadas. É porque os posts conterão opiniões, gostos, comentários e outras estatísticas, e por isso, necessitarão de mais produção escrita em comparação com os utilizadores.
Agora, talvez possa fazer um feed dos posts mais recentes e o feed agregará directamente os autores em cada post. No armazenamento de dados, isto é conseguido definindo o Autor_ID dos posts como uma chave estrangeira, seguido de consultar tanto os utilizadores como as tabelas dos posts com uma transformação Join para construir o feed em tempo real.
No entanto, essa opção não está disponível aqui; em vez disso, terá de desnormalizar os seus dados preservando o feed num recipiente individual que está à espera de ser consultado. Este contentor transportará uma cópia dos dados armazenados nos utilizadores e nos contentores dos postes, com os autores consolidados nos postes.
Conclusion
O esquema que escolher para o seu armazém de dados depende principalmente dos padrões de acesso das aplicações e do tamanho dos seus itens de dados. Pode consultar os nossos arquitectos de soluções para garantir a utilização de técnicas avançadas de automatização ao normalizar ou desnormalizar o seu armazém de dados.
