Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Normalização de dados na prática - Revista SQL Magazine 101
O objetivo deste artigo é introduzir os conceitos de normalização da estrutura de dados e explicar de uma forma clara e objetiva a maneira de se aplicar isto no momento da elaboração dos modelos de dados.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
SQL Magazine 101
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 101
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 101
Atualmente é muito comum encontrar sistemas com diversos problemas de performance decorrentes de uma modelagem de dados incorreta, com muita redundância e com o negócio mau planejado.
Na maioria das vezes, os problemas na estrutura de dados são tão complexos de serem solucionados que a alternativa mais viável é construir um novo sistema ou comprar algo pronto no mercado, abandonando o atual.
Mas quais são os fatores negativos que contribuem para um retrabalho tão grande?
Em muitos casos o sistema começa a ser planejado pela codificação, ou seja, ao invés de se desenhar o negócio no modelo de dados, o foco é o desenvolvimento, e desta forma, as tabela, colunas, relacionamentos e etc., são criados para atender o código e não o inverso.
Então, a melhor opção para aumentar a qualidade da aplicação é criar um modelo de dados que contemple todo o negócio, e para isso, é necessário utilizar as regras de normalização.
A normalização se refere a um conjunto de regras de modelagem de dados (ler Nota DevMan 1), que tem por objetivo reduzir os problemas de lógica, auxiliar no desenvolvimento de software, deixando a leitura da estrutura de dados mais fácil, contribuindo assim para melhoria na performance dos sistemas e, principalmente, evitar a redundância.
Nota DevMan 1. Modelo de Dados
Um banco de dados é projetado para armazenar os dados. A este projeto damos o nome de modelo de dados, que é uma tarefa do arquiteto de dados. É através da modelagem de dados que serão definidas quais as tabelas com seus respectivos campos e os relacionamentos entre essas tabelas.
Existem várias regras na normalização, mas utilizando a 1FN, 2FN e 3FN (ler Nota DevMan 2) é possível atingir um grau muito elevado de maturidade no modelo de dados.
Para construirmos nosso modelo de dados normalizado, vamos iniciar com o modelo lógico e depois, partimos para o modelo físico. O modelo lógico de dados já leva em conta algumas limitações e implementa recursos como adequação de padrão e nomenclatura. Além disto, neste modelo definimos as chaves primárias e estrangeiras. Já no modelo físico de dados fazemos a modelagem física do modelo de banco de dados. Levamos em conta as limitações impostas pelo SGBD escolhido e deve ser criado sempre com base nas definições feitas no modelo lógico de dados.
"
Este é um post disponível para assinantes MVP
Na maioria das vezes, os problemas na estrutura de dados são tão complexos de serem solucionados que a alternativa mais viável é construir um novo sistema ou comprar algo pronto no mercado, abandonando o atual.
Mas quais são os fatores negativos que contribuem para um retrabalho tão grande?
Em muitos casos o sistema começa a ser planejado pela codificação, ou seja, ao invés de se desenhar o negócio no modelo de dados, o foco é o desenvolvimento, e desta forma, as tabela, colunas, relacionamentos e etc., são criados para atender o código e não o inverso.
Então, a melhor opção para aumentar a qualidade da aplicação é criar um modelo de dados que contemple todo o negócio, e para isso, é necessário utilizar as regras de normalização.
A normalização se refere a um conjunto de regras de modelagem de dados (ler Nota DevMan 1), que tem por objetivo reduzir os problemas de lógica, auxiliar no desenvolvimento de software, deixando a leitura da estrutura de dados mais fácil, contribuindo assim para melhoria na performance dos sistemas e, principalmente, evitar a redundância.
Nota DevMan 1. Modelo de Dados
Um banco de dados é projetado para armazenar os dados. A este projeto damos o nome de modelo de dados, que é uma tarefa do arquiteto de dados. É através da modelagem de dados que serão definidas quais as tabelas com seus respectivos campos e os relacionamentos entre essas tabelas.
Existem várias regras na normalização, mas utilizando a 1FN, 2FN e 3FN (ler Nota DevMan 2) é possível atingir um grau muito elevado de maturidade no modelo de dados.
Para construirmos nosso modelo de dados normalizado, vamos iniciar com o modelo lógico e depois, partimos para o modelo físico. O modelo lógico de dados já leva em conta algumas limitações e implementa recursos como adequação de padrão e nomenclatura. Além disto, neste modelo definimos as chaves primárias e estrangeiras. Já no modelo físico de dados fazemos a modelagem física do modelo de banco de dados. Levamos em conta as limitações impostas pelo SGBD escolhido e deve ser criado sempre com base nas definições feitas no modelo lógico de dados.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Roberto De Angelantonio Jr.
Bacharel em Administração de Sistemas da Informação pela Universidade Ibero-Americana. Atua na área de sistemas a mais de vinte anos, sendo que, na maior parte da carreira trabalhou como Administrador de Dados. Experiência em implementar e reestruturar a área de Administração de Dados em diversas em...
O que você achou deste post?
Cursos relacionados
Publicidade
