NUNCA MAIS PASSE RAIVA POR NÃO CONSEGUIR RESOLVER UM PROBLEMA COM O EXCEL - GARANTIDO!

UNIVERSIDADE DO VBA - Domine o VBA no Excel Criando Sistemas Completos - Passo a Passo - CLIQUE AQUI

Você está em: PrincipalArtigos › ASP 3.0 › Capítulo 05 : 02
Quer receber novidades e e-books gratuitos?
« Lição anterior Δ Página principal ¤ Capítulos Próxima lição »
SITES DINÂMICOS COM ASP 3.0 - CURSO COMPLETO
Autor: Júlio Battisti


Promoção: Livro Windows Server 2012 R2 e Active Directory - Curso Completo, 2100 Páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!

Promoção: Livro Windows Server 2012 R2 e Active Directory

Curso Completo, 2100 páginas.

Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!

MAIS DETALHES | COMPRAR ESTE LIVRO


Lição 035 - Capítulo 05 - Uma revisão dos conceitos básicos de Banco de Dados

Neste item iremos revisar alguns conceitos básicos sobre Bancos de Dados. Estes conceitos são importantes para a correta utilização dos Bancos de dados, bem como para o projeto e criação de Bancos de dados.

Em muitas situações teremos que conectar nossas páginas ASP com Bancos de dados já existentes, neste caso precisamos conhecer os conceitos aqui apresentados, para podermos utilizar o Banco de dados de uma maneira otimizada.

Em outras situações teremos que criar o Banco de dados a ser utilizado pela aplicação Web. Neste caso os conceitos apresentados neste item, auxiliam na criação de um Banco de dados melhor estruturado e otimizado, tanto em termos de espaço de armazenamento, quanto da qualidade e disponibilidade das informações nele contidas. Revisaremos os seguintes conceitos:

  • Entidades e Atributos
  • Chave Primária
  • Relacionamentos entre Entidades (Tabelas)
  • Integridade Referencial
  • Normalização de Tabelas
  • Um Problema Proposto

Entidades e Atributos:

Toda a Informação de um Banco de Dados é armazenada em Tabelas, que na linguagem dos Banco de Dados, também são chamadas de Entidades. Por exemplo, poderíamos ter uma Tabela "Clientes", onde seriam armazenadas informações sobre os diversos clientes.

Sobre cada um dos clientes poderíamos armazenar informações tais como: Nome, Rua, Bairro, Telefone, CEP, Data de Nascimento, etc. Essas diversas características de cada Cliente são os "Atributos" do cliente, muitas vezes chamados de campos da entidade Cliente. "O Conjunto de todos os Atributos de um cliente e os valores dos mesmos forma o Registro do Cliente". Com isso teremos a Tabela constituída por um conjunto de Registros (Uma linha completa com informações sobre o cliente) e cada Registro formado por um conjunto de atributos (Nome, Endereço, etc).

Resumindo:

                        Entidade ou Tabela -> Um conjunto de Registros

                        Campos ou Atributos -> Características Individuais da Entidade

Considere o Exemplo da Figura 5.1, onde temos uma Tabela Cliente com os seus diversos Campos (atributos):

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.1 A entidade (tabela) Clientes e seus diversos atributos (campos).

No exemplo da Figura 5.1, temos uma entidade: Clientes e seus diversos atributos: Código do Cliente, Nome da Empresa, Nome do Contato, Cargo do Contato, Endereço, etc. Em cada linha temos um conjunto de atributos e seus valores. Cada linha forma um Registro. Cada Coluna é um atributo da Tabela Clientes.

Um dos grandes desafios em se projetar um Banco de Dados com sucesso é a correta Determinação das Entidades que existirão no Banco de Dados, bem como dos Atributos de Cada Entidade.

Chave Primária:

O Conceito de Chave Primária é fundamental para o Correto Entendimento do Funcionamento de um Banco de dados. Vamos Procurar entender o que significa um Campo Ser a chave Primária de uma Tabela.

Ao Definirmos um Campo como sendo uma Chave Primária, estamos informando ao Banco de dados que não podem existir dois registros com o mesmo valor de Chave Primária, ou seja, os valores no campo Chave Primária precisam ser únicos. Por exemplo, se defino um campo Número da Identidade da tabela Clientes como sendo uma Chave Primária, estou dizendo ao Banco de dados que não podem existir dois clientes com o mesmo valor no campo "Número da Identidade". Na prática estou garantindo que não podem ser cadastrados dois clientes com o mesmo Número de Identidade.

Em outras palavras poderíamos dizer que o Campo Chave Primária identifica de Maneira Única cada Registro de uma Tabela, isto é, de posse do valor da Chave Primária somente localizaremos um registro com aquele valor no campo Chave Primária.

Este é um conceito muito importante, pois conforme veremos mais adiante os conceitos de Integridade Referencial e Normalização estão diretamente ligados ao conceito de Chave Primária.

Na Figura 5.2 vemos um exemplo da tabela Cliente onde o Campo Código do Cliente é definido como uma Chave Primária. Observe que não existem dois clientes com o Mesmo Código.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.2 O campo Código do Cliente é uma Chave Primária.

Um detalhe importante é que a Chave Primária pode ser formada pela combinação de Mais de um campo. Podem existir casos em que um único campo não é capaz de atuar como chave primária, pelo fato do mesmo apresentar valores repetidos. Nestes casos podemos definir uma combinação de dois ou mais campos para ser a nossa chave primária. Além disso, uma tabela somente pode ter uma Chave Primária, seja ela simples ou composta.

Relacionamentos entre Tabelas:

Na prática, em um Banco de dados existem diversas tabelas, como por exemplo: Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informações estejam separadas em cada uma das Tabelas, na prática devem existir relacionamentos entre as mesmas.

Por exemplo: Um Pedido é feito Para um Cliente e neste Pedido podem existir diversos ítens, os quais são armazenados na tabela Detalhes do Pedido. Além disso cada Pedido possui um número único, mas um mesmo Cliente pode fazer diversos pedidos.

Em um Banco de dados precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e seus atributos. Isto é possível com a utilização de "Relacionamentos entre tabelas", os quais podem ser de três tipos:

  • Um para Um
  • Um para Vários
  • Vários para Vários

Relacionamento do Tipo Um para Um:

Esta relação existe quando os campos que se relacionam são ambos Chaves Primárias em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações onde utilizaremos um relacionamento deste tipo.

Um exemplo poderia ser o seguinte: Imagine uma escola com um Cadastro de Alunos na tabela Alunos, destes apenas uma pequena parte participa da Banda da Escola. Por questões de projeto do Banco de dados, podemos optar por criar uma Segunda Tabela "Alunos da Banda",  a qual pode se relacionar com a Tabela Alunos através de um relacionamento Um para Um. Cada aluno somente é cadastrada uma vez na Tabela Alunos e uma única vez na Tabela Alunos da Banda. Poderíamos utilizar o Campo Matrícula do Aluno como o Campo que relaciona as duas Tabelas.

Na Tabela Alunos da Banda poderíamos colocar apenas o Número da Matrícula do aluno, além das informações a respeito do Instrumento que ele toca, tempo de banda, etc. Quando fosse necessário buscar as informações tais como nome, endereço, etc, as mesmas podem ser recuperadas através do relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informação (Nome, Endereço, etc) tenha que ser duplicada nas duas tabelas, o que diminui a probabilidade de erros de digitação.

Na Figura  5.3 vemos o exemplo de um Relacionamento do tipo Um para Um entre as tabelas Alunos e Alunos da Banda.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.3 Um relacionamento do tipo Um para Um.

Relacionamento do Tipo Um para Vários:

Este, com certeza, é o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento) possui um campo que é a Chave Primária e a outra tabela (o lado vários) se relaciona através de um campo cujos valores relacionados podem se repetir várias vezes.

Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente é cadastrado uma única vez (por isso o campo Código do Cliente é uma chave primária, indicando que não podem existir dois clientes com o mesmo código), portanto a tabela Clientes será o lado um do relacionamento. Porém cada cliente pode fazer diversos pedidos, por isso que o Código de um Cliente poderá aparecer várias vezes na tabela Pedidos, tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por isso que temos um relacionamento do tipo Um para Vários entre a tabela Clientes e Pedidos, através do campo Código do Cliente, indicando que um mesmo Cliente pode realizar diversos pedidos.

Na Figura 5.4 vemos um exemplo de um Relacionamento Um para Vários entre as Tabelas Clientes e Pedidos, através do campo código do cliente.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.4 Um relacionamento do tipo Um para Vários.

No lado Um do relacionamento o campo é definido como uma Chave Primária (campo CódigoDoCliente na tabela Clientes) e no lado Vários não (campo CódigoDoCliente na tabela Pedidos), indicando que no lado vários o Código do Cliente pode se repetir várias vezes, o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos.

Relacionamento do tipo Vários para Vários:

Este tipo de relacionamento ocorre em uma situação onde, em ambos os lados do relacionamento, os valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos quais aparece um determinado produto, além disso vários Produtos podem aparecer no mesmo Pedido. Esta é uma situação em que temos um Relacionamento do Tipo Vários para Vários: Vários produtos podem aparecer em Vários pedidos.

Na prática não temos como implementar um relacionamento deste tipo, devido a uma série de problemas que este procedimento implicaria. Por exemplo, na tabela Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Nome do Funcionário, Data do Pedido, etc para cada item do Pedido.

Para evitar este tipo de problema é bastante comum quebrarmos um relacionamento do tipo Vários para Vários em dois relacionamento do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a qual fica com o lado Vários dos relacionamentos. No nosso exemplo poderíamos criar a tabela Detalhes do Pedido, onde ficam armazenadas as informações sobre os diversos ítens de cada pedido, aí ao invés de termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos do tipo um para vários, conforme indicado na Figura 5.5.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.5 “Quebrando” um relacionamento Vários para Vários.

Esta situação em que um relacionamento Vários para Vários é "quebrado" em dois Relacionamentos do tipo Um para Vários é bastante comum. Diversas vezes utilizamos esta técnica para eliminar uma série de problemas no Banco de Dados, tais como informação repetida e inconsistência de Dados.

Agora que já conhecemos os Tipos de Relacionamentos existentes, no próximo ítem veremos o conceito de  Integridade Referencial como uma maneira de Garantir a Consistência dos dados.

Integridade Referencial:

A Integridade Referencial é utilizada para garantir a Integridade dos dados entre as Tabelas Relacionadas, evitando inconsistências dos dados, bem como repetições desnecessárias.

Por exemplo, existe um Relacionamento do tipo Um para Vários entre a Tabela Clientes e a Tabela Pedidos (um cliente pode fazer vários pedidos). Com a Integridade Referencial, o Banco de dados não Permite que seja cadastrado um Pedido para um Cliente ainda não Cadastrado. Também podemos garantir o seguinte:

  • Quando o Código de um cliente for alterado na tabela Clientes, o Banco de dados atualiza, automaticamente, todos os Códigos do Cliente na tabela Pedidos, de tal maneira que não fiquem Registros Órfãos, isto  é , registros de Pedidos com um Código de Cliente que não existe mais na tabela Clientes. Essa ação é conhecida como "Propagar atualização dos campos relacionados";
  • Quando um Cliente for excluído da tabela Clientes, podemos pedir para que o Banco de dados exclua, na tabela Pedidos, todos os Pedidos para o cliente que está sendo excluído. Essa opção é conhecida como "Propagar exclusão dos registros relacionados" e pode ser habilitada ou não, dependendo da especificação do Banco de dados. Caso seja necessário manter todo o histórico de compras do cliente, por exemplo, esta opção não deve ser habilitada. Com isso, quando o cliente for eliminado da tabela Clientes, os seus pedidos continuarão gravados na tabela Pedidos.

Essas opções, são definidas no momento da criação do Banco de dados, quando da criação das Tabelas e dos relacionamentos entre as tabelas.

A Opção de Propagar atualização dos campos relacionados é utilizada na maioria das situações, já a opção de Propagar exclusão dos registros relacionados  deve ser estudada caso a caso.

Normalização de Tabelas:

O conceito de Normalização foi introduzido por Codd em um artigo sobre o Modelo Relacional em 1970.

O objetivo da normalização é evitar os problemas provocados por falhas no Projeto do Banco de Dados, bem como eliminar a mistura de assuntos e as correspondentes redundâncias de dados.

Uma Regra de Ouro que devemos observar quando do Projeto de Banco de Dados é a de "Não Misturar assuntos em uma mesma Tabela".

Por exemplo na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não devemos misturar campos relacionados com outros assuntos, tais como  Pedidos, Produtos, etc. Essa "Mistura de Assuntos" em uma mesma tabela acaba por gerar repetição desnecessária dos dados bem como inconsistência dos mesmos.

O Processo de Normalização aplica uma série de regras sobre as entidades de um Banco de Dados, para verificar se as mesmas estão corretamente projetadas. Embora existam 5 formas normais (ou regras de Normalização ), na prática usamos um conjunto de três Formas Normais.

Normalmente, após a aplicação das regras de Normalização, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final acaba gerando um número maior de tabelas do que o originalmente existente. Este processo causa a simplificação dos atributos de uma tabela, colaborando significativamente para a estabilidade do modelo, reduzindo-se consideravelmente as necessidades de manutenção.

Vamos estudar e entender o Processo de Normalização na Prática, através de exemplos.

Primeira Forma Normal:

"Uma Tabela está na Primeira Forma Normal quando seus atributos não contém grupos de Repetição."

Por isso dissemos que uma Tabela que possui Grupos de Repetição não está na Primeira Forma Normal. Considere a Tabela Indicada na Figura 5.6:

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.6 Uma tabela que não está na Primeira Forma Normal.

Podemos Notar que uma tabela com esta estrutura apresentaria diversos problemas. Por exemplo se um casal tiver mais de um filho, teríamos que digitar o Nome do Pai e da Mãe diversas vezes, tantas quantos forem os filhos. Isso forma um “Grupo de Repetição”.  Além do mais pode ser que por erro de digitação o nome dos pais não seja digitado exatamente igual todas as vezes, o que pode acarretar problemas na hora de fazer pesquisas ou emitir relatórios. Este problema ocorre porque "Misturamos Assuntos" em uma mesma tabela. Colocamos as informações dos Pais e dos Filhos em uma mesma tabela.

A Resolução para este problema é simples: Criamos uma tabela separada para a Informação dos Pais e Relacionamos a tabela Pais com a Tabela Filhos através de um relacionamento do tipo Um para Vários, ou seja, Um casal pode ter Vários Filhos.

Esta solução é indicada na Figura 5.7.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.7 As tabelas Pais e Filhos estão na Primeira Forma Normal.

As duas tabelas Resultantes da Aplicação da Primeira Forma Normal: Pais e Filhos, estão na Primeira Forma Normal, a tabela original, a qual misturava informações de Pais e Filhos, não estava na Primeira forma Normal.

Segunda Forma Normal:

Ocorre quando a chave primária é composta por mais de um campo. Neste caso, devemos observar se todos os campos que não fazem parte da chave de pendem de todos os campos que compõem a chave primária. Se algum campo depender somente de parte da chave composta, então este campo deve pertencer a outra tabela.

Observe o Exemplo Indicado na Tabela da Figura 5.8.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.8 Uma tabela que não está na Segunda Forma Normal.

A chave primária composta é formada pela combinação dos campos NúmeroDaMatrícula e CódigoDoCurso. O campo Avaliação depende tanto do CódigoDoCurso quanto do NúmeroDaMatrícula, porém o campo DescriçãoDoCurso, depende apenas do CódigoDoCurso. Com isso temos um campo que não faz parte da chave primária e depende apenas de um dos campos que compõem a chave Primária, por isso dizemos que esta tabela não está na Segunda Forma Normal.

A Resolução para este problema também é simples: Dividimos a tabela, que não está na Segunda Forma Normal, em duas outras tabelas, conforme indicado pela Figura 5.9, sendo que as duas tabelas resultantes estão na Segunda Forma Normal.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.9 Duas tabelas na Segunda Forma Normal.

A Distinção entre a Segunda e a Terceira forma normal,  que veremos no próximo item, muitas vezes é confusa. A Segunda Forma normal, na maioria das vezes, está ligada a ocorrência de Chaves Primárias compostas.

Terceira Forma Normal:

Na definição dos campos de uma entidade podem ocorrer casos em que um campo não seja dependente diretamente da chave primária,  ou de parte dela, mas sim dependente de um outro atributo constante na tabela e que não é a chave.

Quando isto ocorre, dizemos que a tabela não está na Terceira Forma Normal, conforme indicado pela tabela da Figura 5.10.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.10 Uma tabela que não está na Terceira Forma Normal.

Observe que o Campo DescriçãoDoCurso depende apenas do Campo CódigoDoCurso, o qual não faz parte da Chave Primária. Por isso dizemos que esta tabela não está na terceira forma normal.

A solução para este caso também é simples. Novamente basta dividir a tabela em duas outras, conforme indicado pela Figura 5.11. As duas tabelas resultantes estão na Terceira Forma Normal.

Curso Completo de ASP 3.0 - Júlio Battisti
Figura 5.11 Duas tabelas na Terceira Forma Normal.

IMPORTANTE! Com isso podemos concluir que como resultado do Processo de Normalização, iremos obter um número maior de tabelas, porém sem problemas de redundância e inconsistência dos dados, ou com estes problemas minimizados.

Passos para projetar um Banco de dados

Neste item iremos apresentar os passos básicos para  projetar um Banco de Dados. Aplicaremos os conhecimentos sobre Entidades, Atributos, Relacionamentos, Chave Primária e Normalização.

Um banco de dados bem projetado fornece um acesso conveniente às informações desejadas. Com uma boa estrutura, gasta-se menos tempo na construção de um banco de dados e , ao mesmo tempo, assegura-se resultados mais rápidos e precisos.

ETAPAS NA ESTRUTURAÇÃO DE UM BANCO DE DADOS:

  • Determinar qual o objetivo do banco de dados. Isto ajuda na determinação de quais os dados devem ser armazenados.
  • Determinar as tabelas necessárias. Após definirmos o objetivo do Banco de dados, as informações devem ser definidas e separadas em assuntos diferentes, tais como Clientes, Empregados, Pedidos, pois cada um irá compor uma tabela no banco de dados.
  • Determinar os campos necessários em cada tabela. Definir quais informações devem ser mantidas em cada tabela. Por exemplo, a tabela Clientes poderia ter um campo para o Código Do Cliente, outro para o Nome Do Cliente e assim por diante.
  • Determinar quais campos serão as chaves primárias. Determinar, em cada tabela, qual ou quais campos serão utilizados como Chave Primária. Esta é uma etapa importante para a definição dos Relacionamentos que vem a seguir.
  • Determinar os Relacionamentos. Decidir como os dados de uma tabela se relacionam com os dados de outras tabelas. Por exemplo, Clientes podem Fazer Vários Pedidos. Fornecedores podem fornecer Vários Produtos, etc.
  • Refinar a Estrutura do Banco de Dados. Antes de inserir muitos dados, ou até mesmo antes de inserir qualquer dado, verificar se a estrutura contém erros, isto é, verificar se os resultados obtidos são os desejados. Isto, normalmente, pode ser obtido através do processo de Normalização. Caso necessário, deve-se alterar a estrutura do banco de dados.

Com uma boa estrutura, gasta-se menos tempo na construção e manutenção do banco de dados e, ao mesmo tempo, assegura-se resultados mais rápidos e precisos.

DICAS PARA DETERMINAÇÃO DOS CAMPOS EM UMA TABELA:

  • Relacionar diretamente cada campo ao assunto da tabela. Se um campo descreve o assunto de uma tabela diferente, este campo deve pertencer a outra tabela. O mesmo acontece quando uma informação se repete em diversas tabelas. Este é um indício de que existem campos desnecessários em algumas tabelas.
  • Não incluir dados Derivados ou Calculados. Não é recomendado armazenar o resultado de cálculos nas tabelas. O correto é que o cálculo seja executado quando necessitarmos do resultado.
  • Incluir todas as informações necessárias. Como é fácil esquecer informações importantes, deve-se ter em mente todas as informações coletadas desde o início do processo e perguntar se com elas é possível obter todas os resultados desejados.
  • Armazenar todas as informações separadamente. Existe uma tendência em armazenar informações em um único campo. Por exemplo, o nome do curso e o tempo de duração em uma mesmo campo. Como as duas informações foram combinadas em um único campo, ficará difícil conseguir um relatório classificado pelo tempo de duração dos cursos, por exemplo.

COMO ESCOLHER O CAMPO QUE SERÁ A CHAVE PRIMÁRIA?

Um bom Sistema Gerenciador de Banco de Dados (SGBD) é aquele que encontra e nos fornece, rapidamente, todas as informações necessárias que nele estejam armazenadas, mesmo em diferentes tabelas. Para que isto seja possível é necessário incluir um campo ou conjunto de campos que identifiquem de um modo único cada registro de uma tabela. Esta informação é chamada Chave Primária, conforme descrito anteriormente. Deve-se ter certeza que este campo (ou conjunto de campos) seja sempre diferente para cada registro, por não ser permitido valores duplicados em um campo de chave primária.

Ao escolher campos de Chave Primária, considere os seguintes detalhes:

  • Não é permitido duplicidade de valores ou nulos (informações desconhecidas)

Caso não exista um identificador único para uma determinada tabela, pode-se usar um campo que numere os registros seqüencialmente.

  • Pode-se utilizar o valor deste campo para encontrar registros.
  • O tamanho da chave primária afeta a velocidade das operações, portanto, para um melhor desempenho, devemos utilizar o menor tamanho que acomode os valores necessários para armazenar no campo.


Promoção: Livro Windows Server 2012 R2 e Active Directory - Curso Completo, 2100 Páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!

Promoção: Livro Windows Server 2012 R2 e Active Directory

Curso Completo, 2100 páginas.

Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!

MAIS DETALHES | COMPRAR ESTE LIVRO


« Lição anterior Δ Página principal ¤ Capítulos Próxima lição »
Quer receber novidades e e-books gratuitos?

Cursos Online

  • Banco de Dados
  • Carreira
  • Criação/Web
  • Excel/Projetos
  • Formação
  • + Todas as categorias
  • Contato: Telefone: (51) 3717-3796 | E-mail: webmaster@juliobattisti.com.br | Whatsapp: (51) 99627-3434

    Júlio Battisti Livros e Cursos Ltda | CNPJ: 08.916.484/0001-25 | Rua Vereador Ivo Cláudio Weigel, 537 - Universitário, Santa Cruz do Sul/RS, CEP: 96816-208

    Todos os direitos reservados, Júlio Battisti 2001-2019 ®

    [LIVRO]: MACROS E PROGRAMAÇÃO VBA NO EXCEL 2010 - PASSO-A-PASSO

    APRENDA COM JULIO BATTISTI - 1124 PÁGINAS: CLIQUE AQUI