Dica do Mês – Você sabe o que é Normalização de Banco de Dados?

Olá galera, bom dia, bom dia comunidade!!!

Estou de volta com mais um post da sessão Dica do Mês, nossa como o tempo esta passando, este é o sexto post desta nova sessão criada este ano no meu blog e que lentamente começa a apresentar alguns resultados. Como você já deve estar acostumado quando visita o meu blog, todo final de mês é dedicado a post exclusivos das sessões Dica do Mês e Para que Serve.

No último post publicado no mês de Maio, apresentei um conteúdo mais focado para área acadêmica e hoje não será diferente, vou falar sobre um dos conceitos mais importantes quando falamos sobre banco de dados, estou me referindo a Normalização de Dados ou para muitos Normalização.

 Acredito que você já deve ter ouvir falar sobre este conceito, para muitos algo bastante complexo, mas na verdade não é bem assim, por isso eu decidi compartilhar com vocês um pouco do meu conhecimento nesta área.

Então, seja bem vindo a mais uma dica do mês, começa aqui a Dica do Mês – Você sabe o que é Normalização de Banco de Dados?


Introdução

Conhecida como técnicas de racionalização das estruturas de dados de um sistema, eliminando redundâncias, problemas de manipulação e armazenamento, basicamente a normalização é um processo através do qual esquemas de relação, que não sejam satisfatórios às características do modelo relacional, são decompostos em esquemas menores que satisfaçam as propriedades desejáveis.

Inicialmente proposta como uma ferramenta de auxílio no projeto físico para a definição de relações, porém na prática tornou-se uma ferramenta de verificação, pois serve para verificar se os esquemas do projeto físico satisfazem algumas características básicas. Estas características são conhecidas como medidas de qualidade que devem obrigatóriamente estar alinhadas as necessidades do projeto de banco de dados e seu modelagem conceitual.

Medidas de Qualidade

Na normalização, são analisadas algumas medidas de qualidade para o projeto de um esquema de relação. Estas medidas de qualidade visam, por exemplo, evitar um mau uso da memória. As medidas são as seguintes:

1 – Correta representação semântica – os dados devem ser projetados de forma a terem seus significados bem definidos e coerentes com o que realmente querem representar;

2 – Redução de valores redundantes – sempre que possível deve-se reduzir ao máximo os valores redundantes desnecessários, ou seja, valores que muitas vezes aparecem repetidos quando isto não seria preciso;

3 – Redução de valores nulos – sempre que possível deve-se reduzir o número de atributos que por alguma razão receberão muitos valores nulos;

4 – Não geração de tuplas espúrias (sem sentido) – durante o processo de normalização deve-se atentar para evitar que sejam geradas tuplas que não façam sentido diante da realidade, isto pode ocorrer devido a alguma decomposição.

Estas medidas de qualidade nos ajudam a estabelecer uma estrutura organizacional para nosso modelo de banco de dados, onde podemos tentar afirmar que estamos criando um cenário para armazenar com coerência.

Outro elemento muito importante quando estamos trabalhando com Normalização é a chamada dependência funcional, conhecida como propriedade da semântica ou do significado dos atributos. Você pode estar se perguntando poxa vida o que seria isso, calma vou tentar se ajudar neste respostas.

Dependência Funcional

As decomposições da normalização ocorrem seguindo os conceitos de dependências funcionais. A seguir estes conceitos serão apresentados, juntamente com as três principais e mais utilizadas formas normais.

Uma dependência funcional (DF) é uma propriedade da semântica ou do significado dos atributos. Formalmente, uma dependência funcional entre dois conjuntos de atributos, x e y, que são subconjuntos de um esquema de relação R, denotada por x® y é uma restrição que estabelece que para quaisquer tuplas t1 e t2 de uma instância r de R, tal que, se temos t1[x] = t2[x], então também devemos ter que t1[y] = t2[y].

Em outras palavras, os valores do componente y em uma tupla de r dependem de (ou são determinados por) valores do componente x.

Por exemplo:  Seja x = {Matrícula} e y = {Nome, Endereço, Telefone, CodCurso}, então {Matrícula} {Nome, Endereço, Telefone, CodCurso}, ou seja, a depender do valor da Matrícula, serão determinados os valores do Nome, Endereço, Telefone, e CodCurso.

Quando se define uma dependência funcional, esta regra deve valer para todas as instâncias da relação, é como se fosse uma restrição de integridade, onde em muitos casos não se pode deduzir a existência de uma dependência, conforme a Figura 1 apresentada abaixo demonstra:

Normalização

Figura 1 – Exemplo de como podemos identificar a existência ou não de dependência funcional.

Seguindo em frente, agora que conhecemos um pouco sobre a normalização, suas medidas de qualidade e seu principal elemento de decomposição chamado dependência funcional, o próximo passo é justamente conhecer e entender um pouco mais sobre esta técnica de decomposição de estrutura, para tal será necessário se aprofundar um pouco mais, vamos então começar a desmistificar as tão temidas Formas Normais (kkkkkk), tenho a certeza que você vai gostar.

Formas Normais Baseadas em Chaves Primárias

O processo de normalização é realizado gradativamente através de formas normais, definidas a partir do conceito de DF. As três principais formas normais são a Primeira Forma Normal (1FN), a Segunda Forma Normal (2FN) e a Terceira Forma Normal (3FN).

1FN  2FN  3FN……

Este processo de normalização é composto por algumas propriedades:

  1. Junções sem perda – uma vez definida uma decomposição, caso esta seja recomposta através de uma operação de junção, no resultado gerado não pode haver perdas;  e
  2. Preservação de dependências – assegura que cada DF seja representada em algumas relações individuais resultantes após a decomposição.

A Figura 2 apresentada a seguir ilustra como as formas normais trabalham, sua forma de uso e finalidade:

Normalização1
Figura 2 – Resumo formas normais.

Primeira Forma Normal (1FN)

Um esquema de relação R está na 1FN se todos os seus atributos forem atômicos e monovalorados, ou seja, não possuem valores que formam atributos compostos.

1 – Exemplo:
ESTUDANTES = {MATRÍCULA + NOME + ENDEREÇO + CODCURSO} e
ENDEREÇO é um atributo composto, ENDEREÇO = {RUA + NUMERO + BAIRRO + CIDADE + UF}.

Para colocar na 1FN faz:
ESTUDANTES={MATRÍCULA+NOME+RUA+NUMERO+BAIRRO+CIDADE+UF+CODCURSO}

Um esquema de relação R está na 1FN se todos os seus atributos forem atômicos e monovalorados, ou seja, não possuem valores que formam atributos compostos.

2 – Exemplo:

FUNCIONÁRIOS = {CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATAFIM}}

Para colocar na 1FN faz:

– FUNCIONÁRIOS = {CODFUNC + NOME + CARGO}

– FUNC_PROJ = {CODFUNC + PROJETO + DATAINI + DATAFIM}

Observação: todas as tabelas são relações na 1FN.

 

Segunda Forma Normal (2FN)

Dependência funcional total ou completa: Uma DF x® y é total, se não existir nenhum atributo A em x, tal que (x – {A})® y, para qualquer AÎ x, ou seja, se retirarmos este atributo A da relação x a DF deixa de existir. Caso contrário, x® y é parcial.

Definição da 2FN: Um esquema de relação está na 2FN se: estiver na 1FN e, além disso, todo atributo que não pertença a alguma de suas chaves for totalmente dependente da sua chave primária.

Em outras palavras, para que uma relação esteja na 2FN é preciso que esteja na 1FN e que, havendo uma chave primária composta, todos os dados que não são chaves dependem de toda a chave primária (a chave primária completa).

Seja o exemplo de uma relação que represente o estoque de um estabelecimento comercial, da seguinte forma:

ESTOQUE = {PRODUTO + ALMOX + END_ALMOX + UNID_EST + QTD + PRECO}

Não está na 2FN porque alguns dados não chave dependem somente de parte da chave, como END_ALMOX depende só de ALMOX, e UNID_EST depende só de PRODUTO.

Com a normalizando ficaria:
– Estoque = {PRODUTO + UNID_EST}
– Almoxarifado = {ALMOX + END_ALMOX}
– Produto= {PRODUTO + ALMOX + QTD + PRECO}

 

Terceira Forma Normal (3FN)

Dependência funcional transitiva: Uma DF x® y é transitiva em um esquema de relação R se existir um conjunto de atributos z, que não seja um subconjunto de alguma chave de R, e as DFs x® z e z® y forem válidas em R.

Um esquema de relação está na 3FN se: estiver na 2FN e, além disso, nenhum atributo que não pertença a alguma das suas chaves for transitivamente dependente da sua chave primária.

Em outras palavras, para que uma relação esteja na 3FN é preciso que esteja na 2FN e todo atributo, que não pertença a alguma chave for não dependente de algum outro atributo, que também não pertença a alguma chave.

Seja o exemplo de uma relação que represente os dados referentes às músicas, da seguinte forma:

Exemplo: MÚSICA = {CÓDIGO + TÍTULO + GÊNERO + PAÍS_ORIGEM}, supondo que neste exemplo, o PAÍS_ORIGEM refere-se ao GÊNERO musical e não a música, sendo assim, apesar de estar na 2FN, a relação não está na 3FN, pois existe  dependência entre GÊNERO e PAÍS_ORIGEM.

Com a normalizando ficaria:
MÚS_1 = {CÓDIGO + TÍTULO + GÊNERO}
MÚS_2 = {GÊNERO + PAÍS_ORIGEM}

Acredito que você pode ter entendido como inicialmente a normalização de dados vai influenciar na estrutura da sua modelagem de dados, como a mesma vai ser elaborada, estruturada e elaborada.

Para tentar ajudar o seu entendimento e tentar praticar o que estamos vendo neste post, vou deixar algumas perguntas que podem ser de extrema importância para o esclarecimento de dúvidas, como também, um exercício prático de normalização.


Questionário

1.O que é uma dependência funcional?

2.Quem especifica as dependências funcionais que se mantêm (são válidas) entre os atributos de um esquema de relação?

3.A que se refere a expressão “relação desnormalizada”?

4.Defina primeira, segunda e terceira formas normais quando somente chaves primárias são consideradas. Como as definições da 2FN e 3FN, que consideram todas as chaves de uma relação, diferem daquelas que consideram somente chaves primárias?

Exercício

Sejam os seguintes dados de uma locadora de automóveis:

A locadora aluga automóveis de uma determinada marca apenas para clientes pessoa jurídica (empresas). Estes clientes credenciam motoristas para utilizarem os veículos, o preço diário de aluguel e a potência do carro dependem de seu modelo. Considerando que a locadora necessite, para seu controle, dos dados descritos na seguinte relação:

  • REGISTRO_ALUGUEL = {NumCNH + NomeMotorista + DataNasc + CGCCliente + NomeCliente + EndCliente + {PlacaCarro + Modelo + Cor + Potência + QTDDiárias + PreçoDiária}}

Sendo assim chegamos ao final de mais uma dica do mês.

O conhecimento técnico é muito importante para qualquer profissional, mas o conceito é algo que sempre devemos valorizar e conhecer, a diferença entre um bom profissional e um profissional reconhecido e respeitado no mercado de trabalho é saber aliar o conhecimento teórico com o conhecimento prática, como muitos costumam dizer aliar a téoria a prática, sendo este o objetivo deste post.

Espero que você tenha gostado, que as informações e exemplos publicadas possam de alguma maneira ajudar e colaborar com suas atividades diárias, profissionais e ou acadêmicas.

Desejo um forte abraço, agradeço mais uma vez a sua visita.

Até mais.

 

Este post foi publicado em Banco de Dados, Banco de Dados, Carreira, Curiosidades, DBA, Dica do Mês, Dicas, Diversos, Educação, Interoperabilidade, Microsoft, MSDN, Mundo SQL Server, Sistema Operacional, SQL Server, TechNet, Treinamento, Utilitários, VIRTUAL PASS BR, Windows e marcado com a tag , , , , , , , , , , , , , em por .

Sobre Junior Galvão - MVP

Profissional com vasta experiência na área de Tecnologia da Informação e soluções Microsoft. Mestre em Ciências Ambientes na linha de pesquisa em Geoprocessamento e Modelagem Matemática pela Universidade Estadual Paulista "Júlio de Mesquita Filho". Pós-Graduado no Curso de Gestão e Engenharia de Processos para Desenvolvimento de Software com RUP na Faculdade FIAP – Faculdade de Informática e Administração Paulista de São Paulo. Graduado no Curso Superior em Gestão da Tecnologia de Sistemas de Informação pela Uninove – Campus São Roque. Formação MCDBA Microsoft, autor de artigos acadêmicos e profissionais postados em Revistas, Instituições de Ensino e WebSistes. Meu primeiro contato com tecnologia ocorreu em 1994 após meus pais comprarem nosso primeiro computador, ano em que as portas para este fantástico mundo se abriram. Neste mesmo ano, comecei o de Processamento de Dados, naquele momento a palavra TI não existia, na verdade a Tecnologia da Informação era conhecida como Computação ou Informática, foi assim que tudo começou e desde então não parei mais, continuando nesta longa estrada até hoje. Desde 2001 tenho atuado como Database Administrator – Administrador de Banco de Dados – SQL Server em tarefas de Administração, Gerenciamento, Migração de Servidores e Bancos de Dados, Estratégias de Backup/Restauração, Replicação, LogShipping, Implantação de ERPs que utilizam bancos SQL Server, Desenvolvimento de Funções, Stored Procedure, entre outros recursos. Desde 2008 exerço a função de Professor Universitário, para as disciplinas de Banco de Dados, Administração, Modelagem de Banco de Dados, Programação em Banco de Dados, Sistemas Operacionais, Análise e Projetos de Sistemas, entre outras. Experiência na Coordenação de Projetos de Alta Disponibilidade de Dados, utilizando Database Mirroring, Replicação Transacional e Merge, Log Shipping, etc. Trabalhei entre 2011 e 2017 como Administrador de Banco de Dados e Coordenador de TI no FIT – Instituto de Tecnologia da Flextronics, atualmente exerço a função de Professor Universitário na FATEC São Roque. CTO da Galvão Tecnologia, consultoria especializada em Gestão de TI, Administração de Servidores Windows Server, Bancos de Dados Microsoft SQL Server e Virtualização. Possuo titulação Oficial Microsoft MVP e reconhecimentos: MCC, MSTC, MIE e MTAC.