|
|
| Linha 6: |
Linha 6: |
| <br> | | <br> |
|
| |
|
| * Consiste numa restrição entre dois conjuntos de atributos de uma mesma entidade/relação | | * O que é? |
| * Uma dependência funcional é representada pela relação X -> Y, em que X e Y são subconjuntos de atributos de uma relação qualquer
| | ** |
| * Isso impõe uma restrição na qual um componente Y de uma tupla (registro) é dependente de um valor do componente X (ou é determinado por ele)
| |
| <br>
| |
| | |
| * Do mesmo modo, o valores do componente X determinam de forma unívoca os valores do componente Y
| |
| * Resumindo, Y é dependente funcionalmente de X
| |
| <br>
| |
| | |
| * Supondo o esquema de uma relação abaixo, onde os três primeiros atributos, cujos nomes se encontram destacados, representam a chave primária da relação | |
| ** '''MatriculaAluno''' | |
| ** '''CodigoCurso'''
| |
| ** '''CodigoDisciplina'''
| |
| ** NomeAluno
| |
| ** DataMatricula
| |
| ** NomeCurso
| |
| ** NomeDisciplina
| |
| ** NotaProva
| |
|
| |
| <br>
| |
| | |
| * Podemos estabelecer 4 dependências funcionais neste exemplo:
| |
| # MatriculaAluno -> {NomeAluno, DataMatricula) => O valor do atributo MatriculaAluno determina o valor dos atributos NomeAluno e DataMatricula
| |
| # CodigoCurso -> NomeCurso => O valor do atributo CodigoCurso determina o valor do atributo NomeCurso
| |
| # CodigoDisciplina -> NomeDisciplina => O valor do atributo CodigoDisciplina determina o valor do atributo NomeDisciplina
| |
| # {MatriculaAluno, CodigoCurso, CodigoDisciplina} -> NotaProva => A combinação de valores dos atributos MatriculaAluno, CodigoCurso e CodigoDisciplina determina o valor do atributo NotaProva.
| |
| <br> | | <br> |
|
| |
|
| Linha 37: |
Linha 13: |
| <br> | | <br> |
|
| |
|
| * Após a construção do modelo conceitual dos dados (Modelo Entidade/Relacionamento) é feita a transformação para o modelo lógico (Esquema de Tabelas)
| | * O que é? |
| * O desenho de tabelas obtido representa a estrutura da informação de um modo natural e completo. | | ** |
| | |
| | |
| * Normalização é um processo baseado nas chamadas formais normais
| |
| ** Uma forma normal é uma regra que deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem estruturadas
| |
| ** A normalização pode ser entendida como um processo submetido a estas varias formas normais | |
| <br> | | <br> |
|
| |
|
| * Objetivo principal: eliminar a redundância nos dados armazenados em tabelas, resultando na diminuição do espaço e dos riscos de inconsistências em atualizações de dados
| |
| * Quando um atributo é alterado em uma tabela que não está totalmente normalizada, é necessário alterá-lo em todas as linhas em que ele ocorre, haja visto a sua repetição
| |
| * Tal operação poderia ser executada apenas uma vez, caso este atributo estivesse normalizado
| |
| * As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.
| |
| <br>
| |
|
| |
| * Efetivamente, a Normalização tem como objetivo avaliar a qualidade do Modelo de Tabelas e transformá-lo (em caso de necessidade) num Modelo (Conjunto de Tabelas) equivalente, menos redundante e mais estável.
| |
| <br>
| |
|
| |
|
| == 1FN == | | == 1FN == |
| <br> | | <br> |
|
| |
|
| * Verificação de Tabelas Aninhadas | | * Procedimento |
| | | ** |
| | |
| * Uma relação está na 1a. Forma Normal se e somente se cada linha contiver exatamente um valor para cada atributo
| |
| * Dado que as Relações(Tabelas) são estruturas bidimensionais, então no cruzamento de uma linha com uma coluna (atributo) só é possível armazenar valores atômicos.
| |
| * Para isso, não deve conter tabelas aninhadas
| |
| <br>
| |
| | |
| * Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta:
| |
| ** Este campo depende de algum outro?
| |
| | |
| | |
| * Se sim, então devemos arrumar um método para corrigir o problema.
| |
| <br>
| |
| | |
| * Método:
| |
| ** Remover o grupo de repetição
| |
| ** Expandir a chave primária
| |
| <br>
| |
| | |
| * Seguindo a definição devemos normalizar a tabela decompondo-a em duas
| |
| ** Uma relação R está na 1FN se:
| |
| ** Todo valor em R for atômico
| |
| ** Ou seja, R não contém grupos de repetição
| |
| <br>
| |
| | |
| * Considerações:
| |
| ** Geralmente considerada parte da definição formal de uma relação
| |
| ** Não permite atributos multivalorados, compostos ou suas combinações
| |
| <br>
| |
| | |
| === Caso 1 ===
| |
| <br>
| |
| | |
| cliente (NroCliente, Nome, {End-Cliente})
| |
| Corrigindo o problema:
| |
| Solução: cliente (NroCliente, Nome, End-Cliente, CidCliente, UFCliente)
| |
| <br>
| |
| | |
| === Caso 2 ===
| |
| <br>
| |
| | |
| * Exemplificando com a tabela Venda
| |
| * Esquema relacional da tabela:
| |
| Venda
| |
| Codvenda (Int)
| |
| Cliente (Str)
| |
| Endereco (Str)
| |
| Cep (Int)
| |
| Cidade (Str)
| |
| Estado (Str)
| |
| Telefone (Int)
| |
| Produto (Str)
| |
| Quantidade (Float)
| |
| ValorUnitário (Float)
| |
| PreçoTotal (Float)
| |
| <br>
| |
| | |
| * Análise:
| |
| ** A tabela Venda, deve armazenar informações da venda
| |
| ** O campo Cliente é dependente de CodVenda, afinal para cada Venda há um cliente
| |
| ** Campo Endereço: não depende de Codvenda, e sim de Cliente, pois é uma informação particular ao cliente
| |
| ** Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda
| |
| ** Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não é venda
| |
| Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone], Produto, Quantidade, ValorUnitário, PreçoTotal)
| |
| <br>
| |
| | |
| * Solução:
| |
| ** Extrair estes campos para uma nova tabela
| |
| ** Adicionar uma chave-primária à nova tabela
| |
| ** Relacioná-la com a tabela Venda criando uma chave-estrangeira
| |
| <br>
| |
| | |
| * Resultado:
| |
| Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone).
| |
| Venda (Codvenda, Codcliente, Produto, Quantidade, ValorUnitário, PreçoTotal).
| |
| <br>
| |
| | |
| * Aplicando novamente a 1a. forma normal às 2 tabelas geradas
| |
| * Uma situação comum em tabelas de cadastro é o caso Cidade-Estado
| |
| * Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade
| |
| * No entanto Cidade, também depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre deverá ser Paraná, porém se o Estado for Paraná, a cidade também poderá ser Londrina
| |
| * Isso é o que chamamos de Dependência funcional:
| |
| ** aparentemente, uma informação depende da outra | |
| <br> | | <br> |
|
| |
| * No caso Cidade-Estado a solução é simples:
| |
| ** Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela
| |
| ** Em seguida, o mesmo processo feito anteriormente:
| |
| *** Adicionar uma chave-primária à nova tabela e relacioná-la criando uma chave-estrangeira na antiga tabela
| |
|
| |
|
| |
| Cidade (Codcidade, Nome, Estado).
| |
| Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone)
| |
| Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, ValorUnitário, PreçoTotal)
| |
| <BR>
| |
|
| |
| * Seguindo com o exemplo, a tabela Cliente encontra-se na 1a. forma normal, pois não há mais tabelas aninhadas
| |
| * Verificando Venda, identificamos mais uma tabela aninhada
| |
| * Os campos entre colchetes são referente à mesma coisa: Produto de Venda
| |
|
| |
| Venda (Codvenda, Codcliente, Codcidade, [Produto, Quantidade, Valorunitario, Valorfinal])
| |
| <BR>
| |
|
| |
| * Na maioria das situações, produtos têm um valor previamente especificado
| |
| * O ValorUnitário depende de Produto
| |
| * Já a Quantidade não depende do Produto e sim da Venda
| |
|
| |
| Cidade (Codcidade, Nome, Estado)
| |
| Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone)
| |
| Produto (Codproduto, Nome, ValorUnitário)
| |
| Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal)
| |
| <BR>
| |
|
| |
| * Utilizando a 1a. Forma Normal na tabela Venda, obtivemos 3 tabelas
| |
| <BR>
| |
|
| |
|
| == 2FN == | | == 2FN == |
| <BR>
| |
|
| |
| * A 2a. Forma Normal exige um pouco mais de conhecimento sobre as dependências funcionais, prioritariamente para a dependência funcional total
| |
| * Uma relação está na 2a. Forma Normal se estiver na 1a. e se todos os atributos descritores (não pertencentes a nenhuma chave candidata) dependerem da totalidade da chave (e não apenas de parte dela)
| |
| <br>
| |
|
| |
| * Isso quer dizer que uma tabela encontra-se na 2FN, quando, além de estar na 1FN, não contem dependências parciais
| |
| ** Dependência parcial = uma dependência parcial ocorre quando uma coluna depende apenas de parte de uma chave primária composta
| |
| <br>
| |
|
| |
| * Resumindo, a entidade se encontra na 2FN se, além de estar na 1a., todos os seus atributos são totalmente dependentes da chave primária composta
| |
| * Significa que atributos que são parcialmente dependentes devem ser removidos.
| |
| * Se observarmos as tabelas e identificarmos repetição dos dados nas tuplas requer-se a 2FN
| |
| <br>
| |
|
| |
| * Relendo cada campo e questionando:
| |
| ** Este campo depende de toda a chave?
| |
| ** Se não, temos uma dependência parcial
| |
| <br>
| |
|
| |
| === Caso 3 ===
| |
| <br>
| |
|
| |
| * Uma entidade Item possui chave primária composta que é constituída pelos atributos NumPedido e CodProduto
| |
| * Os atributos Descricao e PrecoUnit não dependem totalmente dessa chave, ao contrário de Quantidade e ValorTotal
| |
| ** Nova entidade: Produto
| |
| <br>
| |
|
| |
| === Caso 4 ===
| |
| <br>
| |
|
| |
| * Reavaliando o caso Cidade-Estado que gerava uma dependência funcional
| |
| * Após a normalização da tabela Venda, obtivemos uma chave composta de 4 campos:
| |
| Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal)
| |
| <br>
| |
|
| |
| * A questão agora é verificar se cada campo não-chave depende destas 4 chaves
| |
| <br>
| |
|
| |
| * Procedimento:
| |
|
| |
| * O 1o. campo não-chave é Quantidade
| |
| ** Quantidade depende de Codvenda => Para cada venda há uma quantidade específica de itens
| |
| ** Quantidade depende de Codvenda e Codcliente => Para um cliente podem ser feitas várias vendas, com quantidades diferentes
| |
| ** Quantidade não depende de Cidade e quem depende de Cidade é Cliente
| |
| <br>
| |
|
| |
| * Temos uma dependência parcial pois Quantidade depende de Codproduto, pois para cada produto da Venda há uma quantidade certa
| |
| <br>
| |
|
| |
| * Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda
| |
| * Quem sobra nessa história é Codcidade
| |
| * A tabela Cidade já está ligada com Cliente, que já está ligada com Venda
| |
| * A chave Codcidade em Venda é redundante, portanto podemos eliminá-la
| |
|
| |
| Venda (Codvenda, Codcliente, Codproduto, Quantidade, PrecoTotal)
| |
| <br>
| |
|
| |
| * Problema:
| |
| ** Existe alguma necessidade de manter CodCidade como campo não-chave?
| |
| <br>
| |
|
| |
| * O próximo campo não-chave é PreçoTotal
| |
| <br> | | <br> |
|
| |
|
| * Avaliando PreçoTotal da mesma forma que Quantidade | | * Procedimento |
| ** Chega-se à conclusão de que ele depende de toda a chave de Venda. | | ** |
| <br> | | <br> |
|
| |
|
| Linha 248: |
Linha 35: |
| <br> | | <br> |
|
| |
|
| * Uma relação encontra-se na 3a. Forma Normal se estiver na 2a. Forma Normal e se não existirem atributos descritores (não pertencentes a nenhuma Chave Candidata) a dependerem funcionalmente de outros atributos descritores (não-chaves) | | * Procedimento |
| | | ** |
| | |
| * Após a aplicação das regras da 2FN se ainda restarem dados redundantes na tabela avaliada pode-se empregar a 3FN
| |
| <br>
| |
| | |
| * Terceira Forma Normal (3FN):
| |
| ** Efetivamente, uma tabela encontra-se na terceira forma normal, quando, além de estar na 2FN, não contém dependências transitivas
| |
| * Dependência transitiva:
| |
| ** Uma dependência funcional transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas da tabela
| |
| ** Assim sendo, cada atributo deve depender apenas das Chaves Candidatas da relação. | |
| <br> | | <br> |
|
| |
|
| === Caso 5 === | | = Referëncias = |
| <br>
| |
| | |
| * Em Pedidos, existem atributos que identificam:
| |
| ** um cliente (nome do cliente e endereço completo)
| |
| ** um vendedor (nome do vendedor)
| |
| <br>
| |
| | |
| * Os dados dos atributos:
| |
| NomeCliente
| |
| EndCliente
| |
| CidCliente
| |
| UFCliente
| |
| * são dependentes de CodCliente
| |
| * Podemos criar outra entidade => Cliente
| |
| <br>
| |
| | |
| * Da mesma forma, NomeVendedor é dependente de CodVendedor
| |
| <br>
| |
| | |
| == Resumo ==
| |
| <br>
| |
| | |
| * 1FN
| |
| # Cria-se uma tabela na 1FN referente à tabela N e que contém apenas colunas com valores atômicos, isto é, sem as tabelas aninhadas;
| |
| # Para cada tabela aninhada, cria-se uma tabela na 1FN compostas pelas seguintes colunas:
| |
| ## A chave primária de uma das tabelas na qual a tabela em questão está aninhada
| |
| ## As colunas da própria tabela
| |
| # São definidas as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas
| |
| | |
| | |
| * 2FN
| |
| # Copiar para a 2FN cada tabela que tenha chave primária simples ou que não tenha colunas além da chave
| |
| # Para cada tabela com chave primária composta e com pelo menos uma coluna não chave
| |
| # Criar na 2FN uma tabela com as chaves primárias da tabela na 1FN
| |
| # Para cada coluna não chave fazer a seguinte pergunta: a coluna depende de toda a chave ou de apenas parte dela?
| |
| # Caso a coluna dependa de toda a chave
| |
| ## Criar a coluna correspondente na tabela com a chave completa na 2FN
| |
| # Caso a coluna não dependa apenas de parte da chave
| |
| ## Criar, caso ainda não existir, uma tabela na 2FN que tenha como chave primária a parte da chave que é determinante da coluna em questão
| |
| # Criar a coluna dependente dentro da tabela na 2FN
| |
| <br>
| |
| | |
| * 3FN
| |
| # Copiar para o esquema da 3FN cada tabela que tenha menos de duas colunas não chave, pois neste caso não há como haver dependências transitivas
| |
| # Para tabelas com duas ou mais colunas não chaves, fazer a seguinte pergunta: a coluna depende de alguma outra coluna não chave?
| |
| # Caso dependa apenas da chave
| |
| ## Copiar a coluna para a tabela na 3FN
| |
| # Caso a coluna depender de outra coluna
| |
| ## Criar, caso ainda não exista, uma tabela no esquema na 3FN que tenha como chave primária a coluna na qual há a dependência indireta
| |
| ## Copiar a coluna dependente para a tabela criada
| |
| ## A coluna determinante deve permanecer também na tabela original
| |
| <br>
| |
| | |
| | |
| === Caso 7 ===
| |
| <br>
| |
| | |
| * Sistema de uma loja de materiais elétricos:
| |
| ** Venda de materiais como fios, fusíveis, lâmpadas, etc
| |
| ** Padrões de entrada do cliente: postes de concreto, caixa de medidor, etc
| |
| ** Na venda de um padrão, o sistema deve baixar o estoque de cada um dos seus componentes
| |
| * Cada um desses componentes pode ser comprado pela loja individualmente, ou sejam podem constar de vários pedidos de compra
| |
| <br>
| |
| | |
| === Caso 8 ===
| |
| <br>
| |
| | |
| * Se realizarmos uma junção dessas três entidades, utilizando o atributo NumeroPedido como o determinante, teremos como resultado o seguinte:
| |
| <br>
| |
| | |
| * Repare que o penúltimo registro abaixo (destaque) não havia na relação original
| |
| * Se a junção for efetuada tomando o atributo Fornecedor, o resultado será:
| |
| <Br>
| |
| | |
| * Novamente, um registro que não existia na relação original é gerado
| |
| <br>
| |
| | |
| * Durante o processo de normalização de dados, descobre-se duas situações, diametralmente opostas:
| |
| ** o número de campos das tabelas diminui enquanto o número de tabelas aumenta
| |
| * O SGBD gerencia tranquilamente e eficientemente, as associações que vão aumentando em função de análise do profissional
| |
| <br>
| |
| | |
| * Exemplo
| |
| | |
| | |
| * 1a. Forma Normal
| |
| | |
| | |
| * Uma Tabela está na 1a. FN quando seus atributos não contém grupos de repetição (tabelas aninhadas):
| |
| Projeto (CodProjeto, Descricao, (CodFunc, Nome, Salario, DataInicio)) => Não está na 1FN
| |
| Projeto (CodProjeto, Descricao) => Está na 1FN
| |
| ProjFunc (CodProjeto, CodFunc, Nome, Salario, DataInicio) => Está na 1FN
| |
| | |
| | |
| * 2a. Forma Normal
| |
| | |
| | |
| * Ocorre quando a chave primária é composta por mais de uma coluna
| |
| * Neste caso, deve-se observar se todas as colunas que não fazem parte da chave dependem de todos os colunas que compõem a chave
| |
| * Se alguma coluna depender somente de parte da chave composta (dependência funcional parcial), então esta coluna deve pertencer a outra tabela
| |
| ProjFunc (CodProj, CodFunc, Nome, Cargo, Salario, DataInicio) => Não está na 2FN
| |
| ProjFunc (CodProj, CodFunc, DataInicio) => Está na 2FN
| |
| Func (CodFunc, Nome, Cargo, Salario) => Está na 2FN
| |
| | |
| | |
| * 3a. Forma Normal
| |
| | |
| | |
| * Uma tabela está na 3a. Forma Normal quando cada coluna não chave depende diretamente da chave primária, isto é, quando não há dependências funcionais transitivas ou indiretas
| |
| * Uma dependência funcional transitiva acontece quando uma coluna não chave primária depende funcionalmente de outra coluna ou combinação de colunas não chave primária
| |
| Func (CodFunc, Nome, Cargo, Salario) => Não está na 3FN
| |
| Func (CodFunc, Nome, CodCargo) => Está na 3FN
| |
| Cargo (CodCargo,Salario) => Está na 3FN
| |
| | |
| = Exercícios =
| |
| | |
| | |
| * Normalizar sequencialmente segundo as formas normais, sempre que possível:
| |
| | |
| | |
| | |
| * 01. Encomenda de Livros:
| |
| PedidoLivro (NomeCliente, ISBN, DataPedido, Titulo, Autor(es), Quantidade, Preço, ValorTotal)
| |
| * Arquivo:Normalizacao-PedidoLivro.pdf
| |
| | |
| | |
| * 02. Projetos:
| |
| Empregado (NroEmpregado, NomeEmpregado, NroDepto, NomeDepto, NroGerente, NomeGerente, NroProjeto, NomeProjetom, DataInicio, FTE)
| |
| | |
| * Arquivo:Normalizacao-Empregado.pdf
| |
| | |
| | |
| * 03. Compras:
| |
| Ordem de Compra (CodOrdemCompra, DataEmissao, CodFornecedor, NumFornecedor, EndFornecedor, CodMaterial (n vezes), DescricaoMaterial (n vezes), QuantComprada (n vezes), ValorUnit (n vezes), ValorTotalItem (n vezes), ValorTotalOC)
| |
| * Arquivo:Normalizacao-OC.pdf
| |
| | |
| | |
| * 04. Notas Fiscais:
| |
| NotasFiscais (Num_ NF, Série, Data emissão, CodCliente, Nome Cliente, EndCliente, CgcCliente, CodigoMercadoria, DescricaoMercadoria, QuantidadeVendida, PrecoVenda, TotalVendaMercadoria, TotalGeral)
| |
| * Arquivo:Normalizacao-NF.pdf
| |
| | |
| | |
| * 05. Gestão de Projetos:
| |
| Gestao Projetos (NumProjeto, NumEmpregado, NomeProjeto, NomeEmpregado, Funcao, Salario, Horas)
| |
| * Arquivo:Normalizacao-GestaoProjetos.pdf
| |
| | |
| | |
| * 06. Vendas:
| |
| Vendedor (NumVendedor, NomeVendedor, EndVendedor, Telefone, Cep, Localidade, NumProduto, DescricaoProduto, Saldo, PrecoUnitário, NumFatura, QuantVendida, Total)
| |
| * Arquivo:Normalizacao-Vendedor.pdf
| |
| | |
| | |
| * 07. Recursos Humanos:
| |
| Funcionario (NumFuncionario, NomeFuncionario, NumEmpresa, NomeEmpresa, NumDepto, NomeDepto)
| |
| * Arquivo:Normalizacao-Funcionario.pdf
| |
| | |
| | |
| * 08. Controle Acadêmico:
| |
| Aluno ( NroAluno, CodDepto, NomeDepto, SiglaDepto, CodOrientador, NomeOrientador,FoneOrientador, CodCurso)
| |
| * As seguintes depend�ncias funcionais devem ser garantidas na normalização:
| |
| CodDepto ? {NomeDepto, SiglaDepto}
| |
| CodOrientador ? {NomeOrientador, FoneOrientador}
| |
| NroAluno ? {CodDepto, CodOrientador, CodCurso}
| |
| * Observações adicionais:
| |
| ** Um aluno somente pode estar associado a um departamento
| |
| ** Um aluno cursa apenas um único curso
| |
| ** Um aluno somente pode ser orientado por um único orientador
| |
|
| |
| Arquivo:Normalizacao-Aluno.pdf
| |
| | |
| | |
| * 09. Corporativo:
| |
| Empresa (CodEmpresa, NomeEmpresa, EndEmpresa, NomeFundador, NacionalidadeFundador, { Filial (FilialNro, FilialLocal, FilialDataAbertura) })
| |
| * As seguintes depend�ncias funcionais devem ser garantidas na normalização:
| |
| CodEmpresa ? {NomeEmpresa, EndEmpresa, NomeFundador}
| |
| NomeFundador ? NacionalidadeFundador
| |
| {CodEmpresa, FilialNro} ? {FilialLocal, FilialDataAbertura}
| |
| * Observações adicionais:
| |
| Uma empresa somente pode ter sido fundada por um único fundador
| |
| * Arquivo:Normalizacao-Empresa.pdf
| |
| | |
| | |
| * 10. Vendas:
| |
| Vendedor (NroVendedor, NomeVendedor, SexoVendedor,{Cliente (NroCliente, NomeCliente, EndCliente ) })
| |
| * As seguintes depend�ncias funcionais devem ser garantidas na normalização:
| |
| NroVendedor ? NomeVendedor, SexoVendedor
| |
| NroCliente ? NomeCliente, EndCliente
| |
| * Observações adicionais:
| |
| ** Um vendedor pode atender diversos clientes, e um cliente pode ser atendido por diversos vendedores
| |
| * Arquivo:Normalizacao-Vendas.pdf
| |
| | |
| <br> | | <br> |
|
| |
|
| * Material de consulta: | | * |
| ** [[Arquivo:BDA - Normalização.pdf]]
| |
| <BR>
| |