Conceitos Bsicos de modelagem de dados

Se voc pretende desenvolver aplicaes que usam banco de dados relacionais dever possuir os conceitos bsicos sobre modelagem de dados. No importa se sua aplicao muito simples ; a correta modelagem dos seus dados ir com certeza tornar sua aplicao mais robusta e mais fcil de manter. O propsito deste artigo fornecer os conceitos bsicos sobre modelagem de dados. Este assunto daria centenas de livros por isto estarei sendo o mais direto e o objetivo possvel de forma a que voc possa aplicar de imediato os conceitos aprendidos. Como o ttulo j diz sero conceitos bsicos e sobre banco de dados relacionais. Nota: Estarei usando o ERWin como ferramenta para modelagem para os exemplos citados neste artigo. Eu no vou Qual o objetivo da modelagem de dados ? Por que modelar ? y y y y Representar o ambiente observado Documentar e normalizar Fornecer processos de validao Observar processos de relacionamentos entre objetos

Modelar implica em construir modelos ento como fazer isto ? Podemos definir as etapas envolvidas na construo de modelos em : 1 - Modelo conceitual - Representa as regras de negcio sem limitaes tecnolgicas ou de implementao por isto a etapa mais adequada para o envolvimento do usurio que no precisa ter conhecimentos tcnicos. Neste modelo temos : y y y y Viso Geral do negcio Facilitao do entendimento entre usurios e desenvolvedores Possui somente as entidades e atributos principais Pode conter relacionamentos n para m.

2- Modelo Lgico - Leva em conta limites impostos por algum tipo de tecnologia de banco de dados. (banco de dados hierrquico , banco de dados relacional ,etc.). Suas caractersticas so : y y y y y y Deriva do modelo conceitual e via a representao do negcio Possui entidades associativas em lugar de relacionamentos n:m Define as chaves primrias das entidades Normalizao at a 3a. forma normal Adequao ao padro de nomenclatura Entidades e atributos documentados

3- Modelo Fsico - Leva em considerao limites impostos pelo SGBD (Sistema Gerenciador de Banco de dados) e pelos requisitos no funcionais dos programas que acessam os dados. Caractersticas:

y y y y

Elaborado a partir do modelo lgico Pode variar segundo o SGBD Pode ter tabelas fsicas (log , lider , etc.) Pode ter colunas fsicas (replicao)

Precisamos definir agora entidade e atributo. O que so e o que representam ? Uma Entidade pode ser definida como qualquer coisa do mundo real , abstrata ou concreta , na qual se deseja guardar informaes. (Tabela , File, etc..). Exemplos de entidades : Cliente , Produto , Contrato , Vendas , etc. Um atributo tudo o que se pode relacionar como propriedade da entidade. (coluna , campo , etc,..). Exemplos de atributos : Cdigo do Produto (Entidade Produto) , Nome do Cliente (Entidade Cliente). Nota : Chama-se Domnio o conjunto de valores possveis do atributo. Obs: Nenhum modelo suficientemente claro se no for acompanhado de uma definio formal dos elementos , fazemos isto atravs do Dicionrio de Dados . Lembre-se , conceitos que podem ser triviais a quem esta modelando podem no ser para pessoas leigas no assunto. Assim o dicionrio de dados tem o objetivo de deixar claro qualquer informao que seja de valia para o processo de compreenso e unificao de conceitos. Para que fique claro vamos fazer um exerccio simples: Definir uma entidade que represente as informaes de uma Pessoa e descrever seus atributos. Podemos definir a entidade Pessoa que ir representar as informaes de uma pessoa. Abaixo temos a representao da entidade e de alguns de seus atributos feitos no ERWin. Ao lado temos a representao feita no ERWin da Entidade Pessoa e de alguns de seus atributos. Note que na definio dos atributos eu estou definindo a natureza do tipo de atributo. Exemplos de tipos de natureza:Texto , Nmero , Indicador(sim/no) , Cdigo, etc. Alguns atributos so obrigatrios outros so opcionais. Nome obrigatrio pois toda pessoa deve ter um nome Telefone opcional pois nem toda pessoa possui um telefone Ento podemos fazer as seguintes definies: Atributo obrigatrio - aquele que para uma instncia de uma entidade ou relacionamento deve possuir um valor. (NOT NULL)

Atributo opcional - aquele que para uma instncia da entidade ou relacionamento pode possuir um valor. (NULL) Podemos ainda classificar os atributos como : Atributo Identificador - (#) - Atributo capaz de identificar exclusivamente cada ocorrncia de uma entidade. Tambm conhecido como chave Primria ou Primary Key (PK). Ex: Cdigo do Cliente , Cdigo do Produto , etc.( O smbolo # usado para representar a chave primria em algumas notaes) Chave Candidata - Atributo ou grupamento de atributos que tm a propriedade de identificar unicamente uma ocorrncia da entidade . Pode vir a ser uma chave Primria. A chave candidata que no chave primria tambm chama-se chave Alternativa. Caractersticas de uma Chave Primria : a - NO PODE haver duas ocorrncias de uma mesma entidade com o mesmo contedo na Chave Primria b - A chave primria no pode ser composta por atributo opcional , ou seja , atributo que aceite nulo. c - Os atributos identificadores devem ser o conjunto mnimo que pode identificar cada instncia de um entidade. d - No devem ser usadas chaves externas. (Atributos sobre os quais voc no tem controle. Ex: CPF) e - Cada atributo identificador da chave deve possui um tamanho reduzido f - No deve conter informao voltil. Ao criar modelos geralmente temos diversas entidades cada uma com diversos atributos que podem se relacionar entre si. Vamos definir como podem ser estes relacionamentos. O que um relacionamento ? Um relacionamento pode ser entendido como uma associao entre instncias de Entidades devido a regras de negcio. Normalmente ocorre entre instncias de duas ou mais Entidades , podendo ocorrer entre instncias da mesma Entidade (auto-relacionamento). Por que o relacionamento necessrio ? y y y y Quando existem vrias possibilidades de relacionamento entre o par das entidades e se deseja representar apenas um Quando ocorrer mais de um relacionamento entre o par de entidades Para evitar ambiguidade Quando houver auto-relacionamento

Para definir o nmero de ocorrncias de uma entidade usamos o conceito de Cardinalidade. A Cardinalidade indica quantas ocorrncias de uma Entidade participam no mnimo e no mxima do relacionamento.

Cardinalidade Mnima - define se o relacionamento entre duas entidades obrigatrio ou no. Ex: Abaixo temos a entidade Pais e a Entidade UF. Um pas possui no mnimo ZERO UF (Existem paises que no possuem Estados . Ex: Vaticano) Uma UF pertence pelo menos a UM Pas. Nota: O nome UF talvez no seja mais apropriado. A entidade representa um estado ou subdiviso equivalente em um Pas Cardinalidade Mxima - define a quantidade mxima de ocorrncias da Entidade que pode participar do Relacionamento. Deve ser maior que zero. Ex: Abaixo temos a entidade Pais e a Entidade UF novamente.

Pas possui no mximo Vrias (mais de uma) UF

Juntando as duas cardinalidade temos o modelo lgico abaixo: Pas pertence no mnimo a ZERO UF e no mximo a VRIOS UF UF pertence no mximo e no mnimo a UM Pas. Agora vamos definir os tipos de cardinalidade quanto ao relacionamento: Cardinalidade UM para UM : PESSOA pode ser no mnimo um CLIENTE. (opcional) CLIENTE uma PESSOA.(Obrigatrio)

Nota: No relacionamento Um para Um temos o lado opcional e o lado obrigatrio . A chave primria se desloca em direo ao lado opcional. No exemplo acima o descolamento seria da entidade CLIENTE para a entidade PESSOA. Cardinalidade UM para N. PRODUTO possui nenhum ou muitas modalidade de produto MODALIDADE DE PRODUTO pertence a um produto. Nota : A cardinalidade UM para N leva a chave primria do lado UM para o lado N. Neste caso o atributo recebe o nome de chave estrangeira ou Foreign Key ( FK ). Chave Estrangeira a chave primria de uma entidade que aparece em outra entidade em virtude do relacionamento. Cardinalidade N para N. CLIENTE celebra um ou vrios Contratos CONTRATO celebrado por um ou vrios clientes A cardinalidade N para N leva para o modelo lgico a necessidade de definio de mais um entidade. Chamamos isto de ASSOCIATIVA. Para o exemplo acima teramos:

A Entidade CLIENTE DO CONTRATO necessria para que possamos identificar o contrato de um determinado cliente. Em toda Cardinalidade N para N temos a ASSOCIATIVA.

Normalizao

Normalizao o conjunto de regras que visa minimizar as anomalias de modificao dos dados e dar maior flexibilidade em sua utilizao. Por que Normalizar ? 1) Minimizao de redundncias 2) Facilidade de manipulaes do 3) Facilidade de manuteno do Sistema de Informaes e Banco inconsistncias; de Dados;

Para que voc compreenda melhor vou dar um exemplo. Vamos supor que voc criou uma entidade Funcionrios para armazenar as informaes dos funcionrios de um empresa e que o resultado fsico final seja a tabela mostrada abaixo.

Se voc olhar bem para a tabela acima vai ter que concordar comigo que ele sofre das seguintes anomalias: y Anomalia de Excluso - O que acontece se voc excluir o funcionrio de cdigo igual a 3 ? O Setor vai ser excludo junto e ai voc danou.. Anomalia de Alterao - O nome do Setor Suporte mudou para Apoio . Voc vai ter alterar o nome em todos os registros da tabela. Danou novamente... Anomalia de Incluso - Foi contratado um novo funcionrio para o Setor Suporte. Voc vai ter que incluir um funcionrio ao campo - QuantidadeFuncionarios - em todas as ocorrncias com setor de nome SUPORTE. Danou mais uma vez...

Para poder resolver o dilema acima temos que NORMALIZAR a entidade. Para isto aplicamos as formas normais a saber: 1- Primeira Forma Normal -(1FN)- Uma relao est na 1FN se somente todos os domnios bsicos contiverem somente valores atmicos (no contiver grupos repetitivos). Para atingir esta forma normal devemos eliminar os grupos de repetio. Como ?0 Procedimentos: a) Identificar a chave primria da entidade; b) Identificar o grupo repetitivo e exclu-lo da entidade; c) Criar uma nova entidade com a chave primria da entidade anterior e o grupo repetitivo. A chave primria da nova entidade ser obtida pela concatenao da chave primria da entidade inicial e a do grupo repetitivo.

Abaixo temos um exemplo de como efetuar a normalizao para a primeira forma normal:

No normalizada

Normalizada usando a primeira forma normal (1FN)

2- Segunda Forma Normal -(2FN)- Uma relao R est na 2FN se e somente se ela estiver na primeira e todos os atributos no chave forem totalmente dependentes da chave primria (dependente de toda a chave e no apenas de parte dela). Procedimentos: a) Identificar os atributos que no so funcionalmente dependentes de toda a chave primria. b) Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles. A chave primria da nova entidade ser o atributo do qual os atributos do qual os atributos removidos so funcionalmente dependentes. Exemplo: Sejam as entidades : Arquivo de Notas Fiscais (Num. NF, Srie, Cdigo do Cliente, Nome do cliente, Endereo do cliente, Total Geral da Nota) Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Descrio da Mercadoria, Quantidade vendida, Preo de venda e Total da venda )

Normalizando para segunda forma normal (2FN): Arquivo de Notas Fiscais (Num. NF, Srie, Cdigo do Cliente, Nome do cliente, Endereo do cliente, Total Geral da Nota) Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da Venda) Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda)

Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo de Notas Fiscais, no foi alterado, por no possuir chave composta) em duas estruturas a saber: Primeira estrutura (Arquivo de Vendas): Contm os elementos originais, sendo excludos os dados que so dependentes apenas do campo Cdigo da Mercadoria. Segundo estrutura (Arquivo de Mercadorias): Contm os elementos que so identificados apenas pelo Cdigo da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrio e o preo de venda sero constantes. 3- Terceira Forma Normal -(2FN)- Uma relao R est na 3FN se somente estiver na 2FN e todos os atributos no chave forem dependentes no transitivos da chave primria (cada atributo for funcionalmente dependente apenas dos atributos componentes da chave primria ou se todos os seus atributos no chave forem independentes entre si). Procedimentos: a) Identificar todos os atributos que so funcionalmente dependentes de outros atributos no chave; b) Remov-los e criar uma nova entidade com os mesmos. A chave primria da nova entidade ser o atributo do qual os atributos removidos so funcionalmente dependentes. Estrutura na segunda forma normal (2FN): Arquivo de Notas Fiscais (Num. NF, Srie, Data emisso, Cdigo do Cliente, Nome do cliente, Endereo do cliente, Total Geral da Nota) Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria) Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda) Estrutura na terceira forma normal (3FN): Arquivo de Notas Fiscais (Num. NF, Srie, Data emisso, Cdigo do Cliente e Total Geral da Nota) Arquivo de Vendas (Num. NF, Cdigo da Mercadoria, Quantidade vendida e Total da venda desta mercadoria) Arquivo de Mercadorias (Cdigo da Mercadoria, Descrio da Mercadoria, Preo de venda) Arquivo de Clientes (Cdigo do Cliente, Nome do cliente, Endereo do cliente) Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o nico que possua campos que no eram dependentes da chave principal (Num. NF),

uma vez que independente da Nota Fiscal, o Nome, Endereo so inalterados. Este procedimento permite evitar inconsistncia nos dados dos arquivos e economizar espao por eliminar o armazenamento freqente e repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente, haver o armazenamento destes dados e poder ocorrer divergncia entre eles. As estruturas alteradas e o motivo das alteraes : - Primeira estrutura (Arquivo de Notas Fiscais): Contm os elementos originais, sendo excludo os dados que so dependentes apenas do campo Cdigo do Cliente (informaes referentes ao cliente). - Segundo estrutura (Arquivo de Clientes): Contm os elementos que so identificados apenas pelo Cdigo do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereo sero constantes. Aps a normalizao, as estruturas dos dados esto projetadas para eliminar as inconsistncias e redundncias dos dados, eliminando desta forma qualquer problema de atualizao e operacionalizao do sistema. A verso final dos dados poder sofrer alguma alterao, para atender as necessidades especficas do sistema, a critrio do analista de desenvolvimento durante o projeto fsico do sistema

Exerccios sobre modelagem de dados

Vejamos a seguir alguns exerccios prticos onde iremos colocar toda esta teoria para funcionar em casos quase reais. Exerccio 1 Vou comear com um bem simples : De acordo com as regras , normalize as estruturas abaixo.

-MATRCULA DO FUNCIONRIO -NOME DO FUNCIONRIO -DATA DO NASCIMENTO -DEPENDENTE -CDIGO DO DEPENDENTE -NOME DO DEPENDENTE -CURSO -CDIGO DO CURSO -NOME DO CURSO -ANO DO CURSO Regras do negcio : y y Um funcionrio pode ter mais de um dependente Um funcionrio pode fazer mais de um curso

Relao de Funcionrio:

Esta simples. Veja abaixo uma das solues:

Resposta:

Exerccio 2: Voc acabou de fundar sua empresa de consultoria , a Maicrousofiti Consultoria , e seu primeiro trabalho e desenvolver um sistema para cadastro de clientes voc recebeu o cliente uma lista com os dados que devero compor o sistema , com base nesta lista lista normalize a estrutura de dados de acordo com as formas normais. Lista de informaes que devero compor o sistema cadastro de clientes: Nome Nome do Pai Nome da Me Endereo Telefone1 Telefone2 Nmero do Fax Nmero do Celular Telefone do trabalho Data de Nascimento Naturalidade Nacionalidade Endereo de correspondncia Nome do filho 1 idade do filho 1 Nome do filho 2 idade do filho 2 Nome do filho 3 idade do filho 3 Nome do filho 4 idade do filho 4 Nome do Cnjuge Nmero do CPF Nmero da carteira de

identidade Antes de ver a resposta sugiro que pelo menos tente esboar alguma tentativa de resolver a questo. Que tal deixar a soluo para um prximo artigo ? Brincadeira ! Uma das possveis solues dada abaixo: Resposta

Exerccio Para deixar voc ainda mais afiado vamos a outra situao. Voc deve representar usando o modelo lgico a situao descrita a seguir:

O Departamento de Vendas da Indstria Beleza Ltda, aps estudos de mercado, verificou

que para atingir seus objetivos seria necessrio adquirir frota de veculos prprios para motorizar seus vendedores. O mercado consumidor foi dividido em regies de venda; foram estabelecidos percursos de entrega abrangendo pontos estratgicos dessas regies e vendedores foram designados para cobrir estes percursos. Um sistema deve ser construdo

para administrao da nova sistemtica de vendas adotada pela empresa. Aps entrevistas com o gerente da rea, foram obtidas as seguintes informaes: -- cada regio identificada por um cdigo; - uma regio composta de vrios pontos estratgicos;

- as regies no tm pontos estratgicos em comum; - o vendedor tem a responsabilidade de cobrir uma regio; - uma regio pode ser coberta por vrios vendedores; - a cada dia, um veculo fica sob responsabilidade de um vendedor; - um vendedor pode vender quaisquer itens ativos da tabela de produtos; - o vendedor responsvel pela identificao de cada cliente consumidor na nota fiscal; - a nota fiscal contendo identificao do vendedor, itens e quantidades vendidas exigida
para comprovao da venda E ento ? Quer ver como seria uma das solues ? Ento espia... Resposta

Para encerrar aqui vai a ltima questo. Exercicio De acordo com as regras , normalize as estruturas abaixo. 4:

Numero da Matrcula Nome do Programador Setor Nvel ( 1,2,3) Descrio do Nvel ( 1 - Jnior, 2 - Pleno, 3 - Senior) Programas Codigo do Programa Nome do Programa

Relao de Programadores:

Tempo Estimado Nvel de Dificuldade ( 1, 2 ou 3 ) Descrio da Dificuldade ( Fcil, Mdio, Difcil) Regras do negcio: - Um programa pode ser feito por mais de um Programador; - Um programador pode fazer um ou mais programas; - O Nvel de dificuldade do programa depende do tempo estimado para a elaborao do mesmo; Resposta:

Voc no pode reclamar , dei a teoria e ainda mostrei alguns casos prticos clssicos resolvidos. claro que para se tornar um bom modelador de dados voc vai precisar ler mais e praticar muiiitooo maaaiiisss... At o prximo artigo VB.