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!
Guia simplificado para as 5 formas normais- Artigo Revista SQL Magazine 87
O artigo descreve um guia para as 5 formas normais que podem ser aplicadas na estrutura de um banco de dados a fim de reduzir, principalmente, redundância nos dados e prover uma melhor estrutura para recuperação das informações em um banco de da
SQL Magazine 87
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 87
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 87
Guia simplificado para as 5 formas normais
As formas normais definidas na teoria de banco de dados relacional representam diretrizes para projeto de como as informações ficarão organizadas no banco. As diretrizes correspondentes da primeira à quinta formas normais são apresentadas no artigo, de forma a não exigir um entendimento da teoria relacional. As diretrizes de projeto são significativas mesmo se não estivermos usando um sistema de banco de dados relacional. As diretrizes são apresentadas sem se referir aos conceitos do modelo relacional para enfatizar sua generalidade, e também para facilitar seu entendimento.
As regras de normalização são projetadas para prevenir anomalias e inconsistência de dados. Com respeito à contrapartida no desempenho, essas diretrizes são enviesadas supondo que todos os campos que não são chaves serão atualizados frequentemente. Elas tendem a penalizar recuperações de dados, pois os dados a serem recuperados a partir de um registro em um projeto não normalizado pode ter que ser recuperado a partir de vários registros na forma normalizada. Por este motivo, não existe obrigação por normalizar completamente todos os registros quando os requisitos de desempenho da aplicação são levados em conta.
A primeira forma normal
A primeira forma normal lida com a “forma” de um tipo de registro.
Sob a primeira forma normal, todas as ocorrências de um tipo de registro devem conter os mesmos números de campos.
A primeira forma normal exclui variáveis repetindo campos e grupos. Isso não chega a ser uma diretriz de projeto em sua definição, pois na teoria de banco de dados relacional não são tratados registros que possuam um número variável de campos.
Segunda e terceira formas normais
A segunda e terceira forma normal lidam com o relacionamento entre campos não-chaves e aqueles que são chaves.
Sob segunda e terceira forma normal, um campo não-chave deve prover um relacionamento (fato) com a chave, sendo toda ela, e nada além. Além disso, o registro deve satisfazer à primeira forma normal.
Nós lidamos agora apenas com fatos "simplesmente-valorados". O fato pode ser um relacionamento do tipo um-para-muitos, tal como o departamento de um funcionário, ou um relacionamento um-para-um, tal como a/o esposa/esposo de um funcionário. Assim, a frase "Y é um fato sobre X" significa um relacionamento um-para-um ou um-para-muitos entre Y e X. No caso geral, Y pode ser composto de um ou mais campos, assim como X. No exemplo mais à frente neste artigo, QUANTIDADE é um fato sobre a combinação de PEÇA e ARMAZÉM.
A segunda forma normal
A segunda forma normal é violada quando um campo não-chave é um fato sobre um subconjunto de uma chave. Isso é relevante quando a chave é composta, ou seja, é formada por vários campos. Considere o seguinte registro de inventário apresentado na Listagem 1.
Listagem 1. Campos formando um Registro de Inventário
--------------------------------------------------
| PECA | ARMAZEM | QUANTIDADE | ENDERECO-ARMAZEM |
--------------------------------------------------
A chave neste registro é formada pelos campos PECA e ARMAZEM juntos, mas ENDERECO-ARMAZEM é um fato sobre o campo ARMAZEM sozinho. Os problemas básicos com este projeto são:
• O endereço do armazém é repetido em todo registro que se refere a uma peça armazenada no armazém.
• Se o endereço do armazém mudar, todos os registros se referindo a uma peça armazenada neste armazém devem ser atualizados.
• Por causa da redundância, os dados podem se tornar inconsistentes, com diferentes registros mostrando diferentes endereços para o mesmo armazém.
"
Este é um post disponível para assinantes MVP
As formas normais definidas na teoria de banco de dados relacional representam diretrizes para projeto de como as informações ficarão organizadas no banco. As diretrizes correspondentes da primeira à quinta formas normais são apresentadas no artigo, de forma a não exigir um entendimento da teoria relacional. As diretrizes de projeto são significativas mesmo se não estivermos usando um sistema de banco de dados relacional. As diretrizes são apresentadas sem se referir aos conceitos do modelo relacional para enfatizar sua generalidade, e também para facilitar seu entendimento.
As regras de normalização são projetadas para prevenir anomalias e inconsistência de dados. Com respeito à contrapartida no desempenho, essas diretrizes são enviesadas supondo que todos os campos que não são chaves serão atualizados frequentemente. Elas tendem a penalizar recuperações de dados, pois os dados a serem recuperados a partir de um registro em um projeto não normalizado pode ter que ser recuperado a partir de vários registros na forma normalizada. Por este motivo, não existe obrigação por normalizar completamente todos os registros quando os requisitos de desempenho da aplicação são levados em conta.
A primeira forma normal
A primeira forma normal lida com a “forma” de um tipo de registro.
Sob a primeira forma normal, todas as ocorrências de um tipo de registro devem conter os mesmos números de campos.
A primeira forma normal exclui variáveis repetindo campos e grupos. Isso não chega a ser uma diretriz de projeto em sua definição, pois na teoria de banco de dados relacional não são tratados registros que possuam um número variável de campos.
Segunda e terceira formas normais
A segunda e terceira forma normal lidam com o relacionamento entre campos não-chaves e aqueles que são chaves.
Sob segunda e terceira forma normal, um campo não-chave deve prover um relacionamento (fato) com a chave, sendo toda ela, e nada além. Além disso, o registro deve satisfazer à primeira forma normal.
Nós lidamos agora apenas com fatos "simplesmente-valorados". O fato pode ser um relacionamento do tipo um-para-muitos, tal como o departamento de um funcionário, ou um relacionamento um-para-um, tal como a/o esposa/esposo de um funcionário. Assim, a frase "Y é um fato sobre X" significa um relacionamento um-para-um ou um-para-muitos entre Y e X. No caso geral, Y pode ser composto de um ou mais campos, assim como X. No exemplo mais à frente neste artigo, QUANTIDADE é um fato sobre a combinação de PEÇA e ARMAZÉM.
A segunda forma normal
A segunda forma normal é violada quando um campo não-chave é um fato sobre um subconjunto de uma chave. Isso é relevante quando a chave é composta, ou seja, é formada por vários campos. Considere o seguinte registro de inventário apresentado na Listagem 1.
Listagem 1. Campos formando um Registro de Inventário
--------------------------------------------------
| PECA | ARMAZEM | QUANTIDADE | ENDERECO-ARMAZEM |
--------------------------------------------------
A chave neste registro é formada pelos campos PECA e ARMAZEM juntos, mas ENDERECO-ARMAZEM é um fato sobre o campo ARMAZEM sozinho. Os problemas básicos com este projeto são:
• O endereço do armazém é repetido em todo registro que se refere a uma peça armazenada no armazém.
• Se o endereço do armazém mudar, todos os registros se referindo a uma peça armazenada neste armazém devem ser atualizados.
• Por causa da redundância, os dados podem se tornar inconsistentes, com diferentes registros mostrando diferentes endereços para o mesmo armazém.
"
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!
O que você achou deste post?
Cursos relacionados
Publicidade
