A segunda parte pode ser lida no seguinte link:

Criando um Modelo na Prática

Vendas

Vamos analisar a criação de um sistema que atenderá a área de vendas de uma empresa. Sendo que não sabemos nada sobre vendas. Vem logo na mente uma entidade: Venda. Mas o que caracteriza uma venda?

Vejamos: uma venda caracteriza-se por um vendedor tirando pedidos de produtos para alguém que deseja comprá-los. Vemos então que numa venda existem: o Vendedor, o Pedido, o Cliente e o Produto que será vendido.

Os quatro itens mencionados anteriormente são Entidades, pois podemos identificar suas ocorrências individualmente. Além disso, podem ser construídas tabelas sobre eles e podemos armazenar dados. Temos então quatro Entidades:

Analisemos agora a existência de relacionamentos entre as entidades.

Pedido Contém Produto. Cardinalidade: Muitos-Para-Muitos (N:M). Explicação: Um pedido pode conter muitos produtos. Um produto pode pertencer a muitos pedidos.

Quem faz o pedido? O Cliente. Cliente Faz Pedido. Cardinalidade: Um-Para-Muitos (1:N). Explicação: Um cliente pode fazer vários pedidos, mas um pedido só pode pertencer a um cliente. A chave estrangeira fica no lado onde ocorrem muitas ocorrências, ou seja, na entidade Pedido. Portanto Pedido terá um campo identificando o Cliente que o fez.

Quem emite o pedido? O Vendedor. Vendedor Emite Pedido. Cardinalidade: Um-Para-Muitos (1:N). Explicação: Um vendedor pode emitir vários pedidos, mas um pedido só pode pertencer a um vendedor. A chave estrangeira fica no lado onde ocorrem muitas ocorrências, ou seja, na entidade Pedido. Portanto Pedido terá um campo identificando o Vendedor que o emitiu.

Vejamos como fica o diagrama do modelo proposto.

Observe como ficam as estruturas das tabelas.

E como ficariam as tabelas preenchidas com dados? Vejamos.

Com o tempo e prática, você será capaz de identificar Entidades e Relacionamentos facilmente, modelando rapidamente um banco de dados para o negócio existente no mundo real.

Normalização

Conceitos

O conceito de normalização foi introduzido por E. F. Codd em 1970 (primeira forma normal). Esta técnica é um processo matemático formal que tem seus fundamentos na teoria dos conjuntos.

Através da normalização pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta “purificado” em relação às anomalias de atualização (inclusão, alteração e exclusão) as quais podem causar certos problemas, tais como: grupos repetitivos de dados, redundâncias de dados desnecessários, perdas acidentais de informação, dificuldade na apresentação de fatos da realidade observada etc.

Esses problemas podem ser minimizados, sensivelmente, através da normalização, tornando o modelo de dados elaborado bastante estável e sujeito a poucas manutenções.

Exemplo: Pedido — Análise

Na tabela a seguir temos a relação de alguns pedidos. Vamos supor que este formulário está sendo mantido desta forma numa planilha do Excel, mas que é desejo do usuário migra-lo para um banco de dados com um respectivo sistema de emissão de pedidos.

Observando o formulário de pedido, podemos ver os seguintes campos ou atributos que fazem parte dessa entidade:

• Número do pedido;
• Prazo de entrega;
• Cliente;
• Endereço;
• Cidade
• UF
• CPF
• Código do produto (*)
• Unidade do produto (*)
• Quantidade do produto (*)
• Descrição do produto (*)
• Valor unitário do produto (*)
• Valor total do produto (*)
• Valor total do pedido (*)
• Código do vendedor
• Nome do vendedor.

* Atributos que se repetem no documento.

Caso esta entidade fosse implementada como uma tabela em um banco de dados, as seguintes anomalias apareceriam (dentre outras):

• Anomalia de inclusão: ao ser incluído um novo cliente, o mesmo tem que estar relacionado a uma venda;
• Anomalia de exclusão: ao ser excluído um cliente, os dados referentes às suas compras serão perdidos;
• Anomalia de alteração: caso algum fabricante de produto altere a faixa de preço de uma determinada classe de produtos, será preciso percorrer toda a entidade para se realizar múltiplas alterações.

Primeira Forma Normal — 1FN

Em uma determinada realidade às vezes encontramos algumas informações que se repetem (atributos multi-valorados), retratando ocorrências de um mesmo fato dentro de uma única linha e vinculadas a sua chave primária. Ao observarmos a entidade Pedido, visualizamos que um certo grupo de atributos (campos) se repete ao longo do processo de entrada de dados.

A 1FN diz que: cada ocorrência da chave primária deve corresponder a uma e somente uma informação de cada atributo, ou seja, a entidade não deve conter grupos repetitivos (multi-valorados).

Para se obter entidades na 1FN é necessário decompor cada entidade não normalizada em tantas entidades quanto for o número de conjuntos de atributos repetitivos. Nas novas entidades criadas, a chave primária é a concatenação da chave primária da entidade original mais o(s) atributo(s) do grupo repetitivo visualizado(s) como chave primária deste grupo.

Ao aplicarmos a 1FN sobre a entidade PEDIDO obtemos mais uma entidade chamada ITEM-PEDIDO, que herdará os atributos repetitivos e destacados da entidade Pedido.

Representação de PEDIDO no DER

Um PEDIDO possui no mínimo 1 e no máximo N elementos em ITEM-PEDIDO e um ITEM-PEDIDO pertence a 1 e somente 1 PEDIDO, logo o relacionamento POSSUI é do tipo 1:N.

Dependência Funcional

Para adentrarmos nas próximas formas normais, precisamos compreender o conceito de dependência funcional, sobre o qual a maior parte da teoria de normalização foi baseada.

Dada uma entidade qualquer, dizemos que um atributo ou conjunto de atributos A é dependente funcional de um outro atributo B contido na mesma entidade, se a cada valor de B existir nas linhas da entidade em que aparece, um único valor de A. Em outras palavras, A depende funcionalmente de B.

Exemplo: Na entidade PEDIDO, o atributo PRAZO DE ENTREGA depende funcionalmente de NUMERO DO PEDIDO.

O exame das relações existentes entre os atributos de uma entidade deve ser feito a partir do conhecimento (conceitual) que se tem sobre a realidade a ser modelada.

Na ocorrência de uma chave primária concatenada, dizemos que um atributo ou conjunto de atributos depende de forma completa ou total desta chave primária concatenada, se e somente se, a cada valor da chave (e não parte dela), está associado um valor para cada atributo.

Exemplo: Na entidade ITEM-PEDIDO, o atributo QUANTIDADE-DO-PRODUTO depende de forma total ou completa da chave primária concatenada (NÚMERO-DO-PEDIDO + CODIGO-DO-PRODUTO).

A dependência total ou completa só ocorre quando a chave primária for composta por vários (concatenados) atributos, ou seja, em uma entidade de chave primária composta de um único atributo não ocorre este tipo de dependência.

Quando um atributo ou conjunto de atributos A depende de outro atributo B que não pertence à chave primária, mas é dependente funcional desta, dizemos que A é dependente transitivo de B.

Exemplo: Na entidade PEDIDO, os atributos ENDEREÇO, CIDADE, UF e CPF são dependentes transitivos do atributo CLIENTE. Nesta mesma entidade, o atributo NOME DO VENDEDOR é dependente transitivo do atributo CODIGO DO VENDEDOR.

Com base na teoria sobre as dependências funcionais entre atributos de uma entidade, podemos continuar com a apresentação das outras formas normais.

Segunda Forma Normal — 2FN

Devemos observar se alguma entidade tem chave primária concatenada e, para aquelas que satisfizerem esta condição, analisar se existe algum atributo ou conjunto de atributos com a dependência parcial em relação a algum elemento da chave primária concatenada. A aplicação da 2FN sobre as entidades em observação geram novas entidades, que herdarão a chave parcial e todos os atributos que dependem desta chave parcial, ou seja, uma entidade para estar na 2FN não pode ter atributos com dependência parcial em relação à chave primária.

Exemplo: a entidade ITEM-PEDIDO apresenta uma chave primária concatenada e, por observação, notamos que os atributos UNIDADE DO PRODUTO, DESCRIÇÃO DO PRODUTO e VALOR UNITÁRIO dependem de forma parcial do atributo CODIGO DO PRODUTO, que faz parte da chave primária. Logo devemos aplicar a 2FN sobre esta entidade. Quando aplicamos a 2FN sobre ITEM-PEDIDO, será criada a entidade PRODUTO que herdará os atributos UNIDADE DO PRODUTO, DESCRIÇÃO DO PRODUTO e VALOR UNITÁRIO e terá como chave primária o CODIGO DO PRODUTO.

Observe que a entidade ITEM-PEDIDO “gerou” outra, chamada PRODUTO.

Representação Atual de PEDIDO no DER

Um Produto participa de no mínimo 1 e no máximo N elementos de ITEM-PEDIDO e um ITEM-PEDIDO só pode conter 1 e somente 1 PRODUTO. Logo, o novo relacionamento criado é do tipo N:1.

Terceira Forma Normal — 3FN

Uma entidade está na 3FN se nenhum dos seus atributos possui dependência transitiva em relação a outro atributo da entidade que não participe da chave primária, ou seja, que não exista nenhum atributo intermediário entre a chave primária e o próprio atributo observado.

Ao retirarmos a dependência transitiva, devemos criar uma entidade que contenha os atributos que dependem transitivamente de outro e a sua chave primária é o atributo que causou esta dependência.

Além de não conter atributos com dependência transitiva, entidades da 3FN não devem conter atributos que sejam o resultado de algum cálculo sobre outro atributo, que de certa forma pode ser encarada como uma dependência funcional.

Na entidade PEDIDO podemos observar que o atributo NOME DO VENDEDOR depende transitivamente do atributo CODIGO DO VENDEDOR que não pertence à chave primária. Para eliminarmos esta anomalia, devemos criar a entidade VENDEDOR com o atributo NOME DO VENDEDOR e tendo como chave primária o atributo CODIGO DO VENDEDOR.

Encontramos ainda o conjunto de atributos formados por ENDEREÇO, CIDADE, UF e CPF que dependem transitivamente do atributo CLIENTE. Neste caso, devemos criar a entidade CLIENTE que conterá os atributos ENDEREÇO, CIDADE, UF e CPF. Para chave primária desta entidade vamos criar um atributo chamado CODIGO DO CLIENTE que funcionará melhor como chave primária do que NOME DO CLIENTE, deixando este último como simples atributo da entidade cliente.

Agora vamos ver como o PEDIDO fica no DER depois de normalizado pela terceira forma normal. Observe na figura a seguir.

Quarta Forma Normal — 4FN

Na grande maioria dos casos, as entidades normalizadas até a 3FN são fáceis de entender, atualizar e de se recuperar dados. Mas às vezes podem surgir problemas com relação a algum atributo não chave, que recebe valores múltiplos para um mesmo valor de chave. Esta nova dependência recebe o nome de dependência multi-valorada que existe somente se a entidade contiver no mínimo três atributos.

Uma entidade que esteja na 3FN também está na 4FN, se ela não contiver mais do que um fato multi-valorado a respeito da entidade descrita.

É o caso da nossa tabela PRODUTO. Observe novamente o tabelão que tínhamos com todos os dados:

Na Segunda Forma Normal nós criamos a tabela PRODUTO. Mas se você observar bem, a tabela PRODUTO contém o campo “Unid” (unidade) que armazena as unidades dos produtos. Olhe para o tabelão acima para os quatro registros do pedido número “1234”. A unidade do produto de código 20 é “Um” e a unidade do produto de código 30 também é “Um”. Então nós temos agora a tabela PRODUTO com os campos: Código do Produto, Unidade do Produto, Descrição e Valor Unitário. No entanto, o valor para o campo Unidade poderá se repetir em alguns casos. Temos redundância de dados.

Para resolver essa questão nós vamos utilizar a 4FN criando uma tabela para armazenar as unidades e gravando o código da unidade na tabela de produtos. Teremos então uma nova tabela UNIDADE com os campos CODIGO e NOME e gravaremos o valor do campo CODIGO em um novo campo da tabela PRODUTO chamado COD_UNIDADE.

Quinta Forma Normal — 5FN

A 5FN trata do conceito de dependência de junção. Ela trata de casos bastante particulares, que ocorrem na modelagem de dados, que são os relacionamentos múltiplos. Você vai usar a 5FN quando um campo está em outra tabela sem a necessidade de estar na tabela pesquisada. Não há a perda de nenhuma informação.

Por exemplo, vamos supor que você tenha colocado o CODIGO da unidade na tabela ITEM-PEDIDO. No entanto, a tabela ITEM-PEDIDO também possui o código do produto. Se você fizer uma consulta no banco de dados utilizando um join (uma junção) entre ITEM-PEDIDO, PRODUTO e UNIDADE você conseguirá pegar todos os dados da tabela UNIDADE usando o CODIGO do produto que está armazenado em ITEM-PEDIDO. Logo, não é preciso armazenar o código da unidade na tabela ITEM-PEDIDO. Removendo o código da unidade nesse exemplo faria com que a tabela ficasse na 5FN.

Vale lembrar que as formas normais são encadeadas. Uma tabela só pode estar na segunda forma normal se ela já estiver na primeira forma normal. Ela só poderá estar na terceira forma normal se anteriormente estivesse na segunda forma normal e por aí vai. Não tem como uma tabela estar na quarta forma normal se não estiver na segunda e terceiras formas normais.

Roteiro de Aplicação da Normalização

Entidade ou documento não normalizado, apresentando grupos repetitivos e certas anomalias de atualização.

Aplicação da 1FN

1. Decompor a entidade em uma ou mais entidades, sem grupos repetitivos;
2. Destacar um ou mais atributos como chave primária das novas entidades, e este será concatenado com a chave primária da entidade original;
3. Estabelecer o relacionamento e a cardinalidade entre as novas entidades geradas e a entidade geradora;
4. Verificar a questão da variação temporal de certos atributos e criar relacionamentos 1:N entre a entidade original e a entidade criada por questões de histórico.

Agora as Entidades estão na 1FN.

Aplicação da 2FN

1. Para entidades que contenham chaves primárias concatenadas, destacar os atributos que tenham dependência parcial em relação à chave primária concatenada;
2. Criar uma entidade que conterá estes atributos, e que terá como chave primária o(s) atributo(s) do(s) qual(ais) se tenha dependência parcial;
3. Serão criadas tantas entidades quanto forem os atributos da chave primária concatenada, que gerem dependência parcial;
4. Estabelecer o relacionamento e a cardinalidade entre as novas entidades geradas e a entidade geradora.

Agora as Entidades estão na 2FN.

Aplicação da 3FN

1. Verificar se existem atributos que sejam dependentes transitivos de outros que não pertencem à chave primária, sendo ela concatenada ou não, bem como atributos que sejam dependentes de cálculo realizado a partir de outros atributos;
2. Destacar os atributos com dependência transitiva, gerando uma nova entidade com este atributo e cuja chave primária é o atributo que originou a dependência;
3. Eliminar os atributos obtidos através de cálculos realizados a partir de outros atributos.

Se você conseguir chegar na terceira forma normal, saiba que seu banco de dados está bem modelado.

Desnormalização

Já vimos o que é normalização e para que serve. O que seria então a Desnormalização?

Algumas vezes, ao aplicarmos as regras da normalização, podemos trazer prejuízo para a implementação do Modelo no Banco de Dados. Pode ser que o SGBD não fique com o melhor desempenho. Seguir à risca o modelo também pode trazer dificuldades na hora de criar relatórios.

Às vezes a realidade está normalizada num nível muito alto (5FN por exemplo), fazendo com que uma simples alteração acarrete um efeito cascata profundo no banco de dados, ocasionando um aumento bastante significativo de tempo.

Para evitar isso, seria interessante utilizar até no máximo a 3FN.

Considerações sobre Normalização

A normalização pode ser feita de duas formas:

• Botton-up — Normalização a partir de documentos já existentes no ambiente analisado. (pedidos, notas fiscais, orçamentos, etc).
• Top-down — Criado a partir da visualização da realidade.

Utilize os dois métodos. Sempre dando prioridade à visualização da realidade. Muitas vezes os documentos que existem já são uma bagunça e seguir esse modelo levará a um sistema inconsistente e que não resolverá todos os problemas do cliente.

Você vai observar que a construção de um sistema levará naturalmente ao desenvolvimento de entidades e relacionamentos na 3FN.

Generalizações

Este é um item muito importante e cabe falar sobre ele aqui na parte em que estamos tratando da normalização das entidades.

Vamos a um exemplo: digamos que a Entidade FUNCIONÁRIO tem uma variação. Se o funcionário for programador, existem informações adicionais exclusivas dessa profissão. Para o médico existem outras informações específicas.

Como não podemos ter campos com tamanhos variáveis, deveremos criar sub-entidades (subconjuntos do conjunto FUNCIONÁRIO) para os casos em que as informações variam.

Um elemento de funcionário só pode ter um e somente um subconjunto. As informações dos programadores serão completadas pelo subconjunto PROGRAMADOR.

Os subconjuntos tornam-se tabelas carregando o identificador do conjunto ao qual pertencem. Observe a figura a seguir.

Parte 3 — Considerações Finais

Nessa parte fizemos um breve exercício. Embora breve, ele foi muito importante. Nessa prática foi possível encontrar as entidades, atributos e relacionamentos do minimundo Venda. Você verá, com o tempo, que um minimundo pode conter várias visões. O minimundo Venda modelado aqui pode ser feito de forma diferente, com menos ou mais tabelas, dependendo da visão proposta.

Nós “preenchemos” as tabelas com dados para facilitar o entendimento do modelo criado. Tire um tempo para implementar alguns modelos, por exemplo: Clínica Veterinária.

Ainda nessa parte nos aprofundamos um pouco e abordamos os conceitos de Normalização. Para facilitar o entendimento fizemos a normalização através de um estudo de dado: Pedido.

Vimos que podemos normalizar as entidades utilizando as formas normais 1 a 5. O ideal, entretanto, é que fiquemos ali na 3FN para não ser preciso “desnormalizar” o banco.

No finalzinho vimos o conceito de Generalização, que abordaremos novamente mais a frente.

Continua na parte 4

T2Ti ERP — Aprenda a Desenvolver um ERP

O T2Ti ERP 2.0 é feito em C#, Delphi, Java (RIA e Web) e Lazarus. São cinco projetos diferentes. Que tal aprender a desenvolver esse ERP totalmente grátis? Parece bom?

Acompanhe o canal da T2Ti no Youtube. A T2Ti está postando todos os vídeos do T2Ti ERP 2.0 no Youtube. São quase 300 módulos!

Os vídeos estão organizados em Playlists. Então se inscreva no canal e ative o sininho para receber atualizações sobre as postagens.