|
Genesis
A sua ferramenta de
desenvolvimento para geração de códigos VBA e SQL |
1 - INTRODUÇÃO
2 - O QUE SÃO BANCOS DE DADOS?
2.1 - Tabelas
2.2 - Dicionário de dados
2.3 - SQL
3 - O QUE É OO?
3.1 - Conceitos básicos
3.2 - OO no Visual Basic For Applications
4.1 - Trabalhando com tabelas
4.2 - Trabalhando com os campos da tabela
4.2.1 - PK - Primary Key
4.2.2 - Atributo
4.2.3 - Requerido
4.2.4 - Tipo
4.2.5 - Tamanho
4.2.6 - Valor Padrão
4.2.7 - Atributo FK - Foreign Key
4.2.8 - Tipo FK
4.2.9 - Ordem
4.2.10 - Descrição
4.3 - Gerando uma classe
4.4 - Gerando o código SQL da tabela
4.5 - Gerando a classe de conexão
4.6 - Visualizando o código SQL da tabela
4.7 - Visualizando o código da Classe
4.8 - Visualizando o relatório de estrutura das tabelas
4.9 - Visualizando o dicionário de dados
4.10 - Visualizando o relatório SQL
4.11 - Gerando o banco de dados
4.12 - Exportando as classes
5 - BIBLIOGRAFIA
Frequentemente nós, profissionais de informática, nos deparamos com alguns probleminhas chatos existentes no desenvolvimento de sistemas, alguns deles relacionados aos trabalhos repetitivos e cansativos, como, por exemplo, a documentação de atributos e a programação de métodos básicos da classe, ou seja, aqueles que atribuem ou retornam valores, buscam, salvam ou excluem um objeto, entre outros.
Segundo criadores de sistemas análogos, o trabalho de programação pode ser reduzido, em média, até 60%, ao se utilizar os geradores de código. Isto permite que o profissional concentre-se apenas em implementar os métodos inerentes às regras do negócio, diminuindo consideravelmente o tempo necessário para a conclusão do projeto.
Algumas das ferramentas de geração de código existentes mantém o seu foco na criação de classes a partir de um Banco de Dados pronto, conectando-se ao mesmo e buscando as informações sobre a estrutura das tabelas e relacionamentos. Outras geram as classes a partir dos modelos de projeto. Existem também algumas especializadas em modelar o próprio esquema do Banco de Dados, fornecendo os script´s SQL para a criação do mesmo. Umas mais simples, outras nem tanto, a verdade é que nunca encontramos aquela que atende às nossas necessidades completamente.
O Genesis, agora uma opção a mais, é uma ferramenta de desenvolvimento que busca a união entre os esforços de documentação, criação do Banco de Dados e programação, auxiliando na construção do software, a partir dos dados inseridos pelo usuário uma única vez, nestes três aspectos básicos:
Geração do Banco de Dados, com todas as tabelas e seus respectivos relacionamentos;
Geração do código das classes, uma para cada tabela, contendo os atributos e os métodos básicos;
Geração dos relatórios de estrutura das tabelas, dicionário de dados e script´s de criação das tabelas, podendo servir para análise do esquema ou fazer parte da documentação do sistema.

Por contar com uma interface simples e bastante prática, sua utilização torna-se quase que totalmente intuitiva. Desde que o desenvolvedor esteja familiarizado com os conceitos não encontrará problemas para iniciar de imediato a construção de um sistema.
* * * * * * * * * * * * * * * * * * * * * * * * * * * ATENÇÃO * * * * * * * * * * * * * * * * * * * * * * * * * * *
Para que ocorra um aproveitamento máximo é importante também conhecer os recursos diferenciados que o Genesis oferece, como a escolha do tipo de chave estrangeira e o valor padrão dos atributos, pois a utilização incorreta dos mesmos acarretaria a criação de trechos de código inúteis, ou até mesmo de erros.
Verifique os padrões para criação de nomes de tabelas, atributos e métodos, e siga-os, evitando que o código das classes fique esteticamente fraco.
Como é um projeto simples, objetivando apenas treinamento e compartilhamento dos conceitos de tecnologias de desenvolvimento de software, não destinado a fins comerciais, o Genesis não está totalmente preparado para tratamento de erros, nem mesmo de utilização.
O código do Genesis é aberto e o usuário pode fazer qualquer alteração no mesmo, sendo solicitado apenas a manter os créditos da criação, um princípio bastante razoável e ético.
2 - O QUE SÃO BANCOS DE DADOS?
Existem diversas formas de se trabalhar com informações, entre elas, o uso de arquivos de fichas cadastrais, contendo dados sobre um cliente, por exemplo. Até pouco tempo atrás era comum guardar todas as informações de uma empresa em fichas de papel, colocadas em pastas dentro de armários. Esse era o banco de dados da empresa, ou seja, o meio pelo qual se registrava ou buscava informações. No caso de haver poucas fichas, o trabalho de localizar uma delas era razoavelmente rápido e fácil, mas quando o número era grande, ficava praticamente impossível encontrar o que se procurava em um tempo satisfatório. Além disso, caso houvesse a necessidade de se cruzar informações de mais de um setor, ou dados diferentes de um mesmo cliente, por exemplo, seria preciso a colaboração de vários funcionários para que a tarefa fosse executada.
Com o auxílio do computador, foi possível agrupar todas essas informações, e organizá-las de forma que o acesso e a manutenção dos dados fossem agilizados consideravelmente, resultando em um trabalho muito mais rápido e eficiente. Para aumentar o desempenho, elas foram também relacionadas umas às outras, mantendo-se a ligação original que existia, por exemplo, entre uma venda e os produtos que foram vendidos, ou entre a venda e o cliente que comprou os produtos. A esse monte de informações organizadas e relacionadas deu-se o nome de Sistemas de Bancos de Dados Relacionais, ou seja, um sistema informatizado com capacidade de armazenar grande quantidade de dados, e com funções próprias que possibilitem a recuperação e o cruzamento de informações rapidamente e de maneira confiável.
Um Sistema de Banco de Dados é composto de duas partes principais: o Banco de Dados (BD) em si, que é um conjunto de tabelas onde os dados estão armazenados, e um Sistema Gerenciador de Banco de Dados (SGBD), que é o sistema que gerencia as informações armazenadas, possibilitando o manuseio dos dados e o controle de usuários, entre outras funções. O SGBD é a parte funcional do sistema.
Uma tabela é um conjunto de dados sobre um tópico específico, como produtos ou fornecedores. Ela é composta de registros, ou seja, itens de dados sobre o tópico. Um registro é formado por campos, que são informações relevantes sobre um mesmo item de dado. Vejamos, como exemplo, a tabela para armazenar informações sobre um cliente:
Tabela Cliente
| Código | Nome | Idade | Endereço | Telefone |
| 123 | José Santos | 26 | Av. Duque de Caxias 1544 Marco Belém-PA | 3276-4458 |
| 456 | Antônio Oliveira da Silva | 48 | Tv. Pirajá 122 Pedreira Belém-PA | 3277-8500 |
| 228 | Vanessa Medeiros Maia | 23 | Av. Pedro Álvares Cabral 23 Sacramenta Belém-PA | 9640-0216 |
Na tabela Cliente, cada linha representa um registro, ou um item de dado, a informação completa sobre um único cliente. As colunas Código, Nome, Idade, Endereço e Telefone são os campos que, juntos, formam um registro.
Utilizar uma tabela separada para cada tópico significa armazenar os dados somente um vez. Isso resulta em um banco de dados mais eficiente e em menos erros de entrada de dados.
Veja como poderia ser colocada a tabela Venda:
Tabela Venda
| Código | Data | Produto | Preço | Qtd | Cliente | Endereço | Telefone |
| 001 | 20/01/2005 | Aparelho de Barbear | 3,50 | 2 | José Santos | Av. Duque de Caxias 1544 Marco Belém-PA | 3276-4458 |
| 002 | 22/01/2005 | Sabonete | 1,40 | 4 | Antônio Oliveira da Silva | Tv. Pirajá 122 Pedreira Belém-PA | 3277-8500 |
| 003 | 27/01/2005 | Pilha alcalina | 4,85 | 2 | Vanessa Medeiros Maia | Av. Pedro Álvares Cabral 23 Sacramenta Belém-PA | 9640-0216 |
| 004 | 12/02/2005 | Aparelho de Barbear | 3,50 | 1 | Antônio Oliveira da Silva | Tv. Pirajá 122 Pedreira Belém-PA | 3277-8500 |
| 005 | 14/02/2005 | Sabonete | 1,40 | 1 | Vanessa Medeiros Maia | Av. Pedro Álvares Cabral 23 Sacramenta Belém-PA | 9640-0216 |
| 005 | 14/02/2005 | Creme dental | 2,34 | 5 | Vanessa Medeiros Maia | Av. Pedro Álvares Cabral 23 Sacramenta Belém-PA | 9640-0216 |
| 006 | 04/03/2005 | Sabonete | 1,40 | 3 | José Santos | Av. Duque de Caxias 1544 Marco Belém-PA | 3276-4458 |
| 006 | 04/03/2005 | Pilha alcalina | 4,85 | 10 | José Santos | Av. Duque de Caxias 1544 Marco Belém-PA | 3276-4458 |
| 006 | 04/03/2005 | Detergente líquido | 0,59 | 3 | José Santos | Av. Duque de Caxias 1544 Marco Belém-PA | 3276-4458 |
Esta é uma forma de se armazenar dados, mas não é a maneira correta. Repare que na mesma tabela repetimos informações várias vezes, como endereço de clientes e preços de produtos. Separando as informações e relacionando as tabelas teríamos um banco de dados "enxuto" e que não teria problemas de consistência, pois os dados estariam armazenados apenas em um lugar. Na tabela acima, caso alterássemos o endereço de um cliente, ou o preço de um produto, teríamos que fazê-lo em todos os locais em que eles aparecem. Imagine uma tabela com milhares de registros repetidos, seria uma tarefa árdua, não é mesmo?
O Modelo Relacional diz que cada informação deve aparecer apenas uma vez no Banco de Dados. Para isso criamos uma tabela para cada tópico e as ligamos, ou, em outras palavras, fazemos o relacionamento entre elas. Assim, quando alteramos algum dado, ele está automaticamente atualizado para todas as ocorrências no BD. Veja como ficaria a mesma tabela, agora organizada de acordo com as regras:
Tabela Produto
| Código | Descrição | Preço |
| 1 | Aparelho de Barbear | 3,50 |
| 2 | Sabonete | 1,40 |
| 3 | Pilha alcalina | 4,85 |
| 4 | Creme dental | 2,34 |
| 5 | Detergente líquido | 0,59 |
Tabela Venda
| Código | Data | Cliente |
| 001 | 20/01/2005 | 123 |
| 002 | 22/01/2005 | 456 |
| 003 | 27/01/2005 | 228 |
| 004 | 12/02/2005 | 456 |
| 005 | 14/02/2005 | 228 |
| 006 | 04/03/2005 | 123 |
Tabela ItemVenda
| CódigoVenda | CódigoProduto | Qtd |
| 001 | 1 | 2 |
| 002 | 2 | 4 |
| 003 | 3 | 2 |
| 004 | 1 | 1 |
| 005 | 2 | 1 |
| 005 | 4 | 5 |
| 006 | 2 | 3 |
| 006 | 3 | 10 |
| 006 | 5 | 3 |
As ligações entre venda e produto, e entre venda e cliente foram feitas através da utilização dos códigos, que servem como chaves primárias e chaves estrangeiras, elementos importantes para a criação de relacionamentos consistentes entre tabelas.
Chave primária é o elemento, ou conjunto de elementos, que identifica um registro entre os demais. Na tabela Cliente o campo Código é a chave primária, pois representa uma ocorrência única de um cliente. Em um campo de chave primária não pode haver repetições, e o próprio BD se encarrega de impor esta restrição, a partir do momento em que o usuário indica o tipo de campo durante a criação da tabela. Além disso todo campo de chave primária possui um índice, também criado automaticamente, para agilizar pesquisas. Nos outros campos da tabela pode haver repetições, a não ser que o usuário o indique como campo de valores únicos, sendo que neste caso, ele geralmente é uma chave candidata.
Uma tabela pode ter mais de um campo que sirva como chave primária por possuir valores que não se repetem, mas o usuário deve escolher apenas um deles, então os outros continuam sendo apenas chaves candidatas. Em tabelas onde não existe um campo com valores únicos, deve-se procurar um conjunto de campos em que a combinação dos mesmos resulte em uma chave primária, identificando apropriadamente o registro. Como exemplo, na tabela ItemVenda a chave primária seria a combinação dos campos CódigoVenda e CódigoProduto, pois uma venda pode ter vários produtos, assim como um produto pode aparecer em várias vendas, mas a combinação venda-produto não pode ocorrer mais de uma vez.
Para que ocorram as ligações entre tabelas, introduzimos na tabela de origem um campo que indique o valor da chave primária da tabela de destino, como fizemos em Venda, incluindo um campo que indique o código do cliente que comprou. Este campo é o que chamamos de chave estrangeira. A chave estrangeira também pode ser composta por uma combinação de campos.
Para um melhor entendimento sobre projeto de BD, regras de mapeamento e normalização de tabelas, consulte algum manual específico de sistemas de bancos de dados, pois isto foge ao escopo deste texto. Uma excelente referência é [5].
Quando construímos um banco de dados ou um sistema OO, geralmente o fazemos acompanhado de um planejamento, ou, mais especificamente, um projeto, que faz parte da documentação do sistema. Nele estão contidos os requisitos, os modelos de classes, o modelo de BD, a arquitetura do sistema e os planos de teste do software.
Um dos itens presentes na documentação é o dicionário de dados, um conjunto de informações que identifica e descreve as tabelas e seus campos (BD), ou as classes e seus atributos (OO). São descritos, por exemplo, o tipo de dado, tamanho e função de um campo ou atributo.
Através do dicionário de dados, assim como de toda a documentação, a manutenção do sistema fica bastante facilitada, principalmente se for realizada por um profissional que não tenha participado da construção do mesmo, pois ele poderá compreender a função de cada item do BD ou da classe onde será efetuada a manutenção, e quais outras partes serão afetadas por esta mudança.
Veja como poderia ser o dicionário de dados para a tabela Produto:
=> Produto: Armazena informações sobre os produtos que a empresa comercializa.
> Código: Código que identifica o produto.
Inteiro ( 2 ) Chave primária
> Descrição: Texto que descreve o produto. Nome do produto.
Texto ( 20 )
> Preço: Valor de venda do produto.
Moeda ( 8 )
Neste exemplo temos a descrição da tabela, a descrição dos campos, o tipo de dado e o tamanho de cada um deles, além da informação sobre campos de chave primária. Existem diversas maneiras de se preparar um dicionário de dados. Não há como dizer qual delas é a mais correta, mas a escolha deve recair naquela que puder apresentar as informações da maneira mais simples e direta possível. Vários autores propõem padrões de documentação. Cabe ao usuário, ou à empresa que desenvolve sistemas, escolher a sua.
SQL é a sigla para Structured Query Language, ou Linguagem de Consulta Estruturada. É uma linguagem estruturada para manipulação de dados. É padronizada para os bancos de dados relacionais, mas cada gerenciador pode possuir uma extensão própria dessa linguagem. Geralmente os fabricantes incluem recursos para diferenciar o seu SGBD dos demais, tentando atrair mais clientes do que o concorrente.
Através do uso do SQL podemos criar, alterar ou excluir bancos de dados, tabelas, campos, índices, enfim, podemos realizar qualquer tarefa relativa ao sistema de banco de dados.
O SQL possui vários tipos de linguagens, sendo as principais as DDL, Data Definition Language, ou Linguagem de Definição de Dados, e as DML, Data Manipulation Language, ou Linguagem de Manipulação de Dados. As DDL servem para a estruturação do BD, permitindo a criação, alteração ou exclusão de tabelas, campos, índices, etc, enquanto que as DML possibilitam a manipulação dos dados que serão armazenados nas tabelas, como a realização de consultas, a inserção e a exclusão de dados.
O Genesis oferece os script´s de criação de todas as tabelas, a partir das informações prestadas pelo usuário, no formulário principal. O código SQL gerado pelo Genesis contém a seguinte sintaxe básica:
CREATE TABLE NomeDaTabela(
nomeDoCampo1 tipo[(tamanho)] [NOT NULL]
:
[, nomeDoCampoN tipo[(tamanho)] [NOT NULL]]
[, PRIMARY KEY (nomeDoCampoPK[, ...])]
[, FOREIGN KEY (nomeDoCampoFK[, ...]) REFERENCES NomeDaTabelaFK(nomeDoCampoPKFK[, ...])]
[, ...]
);
Onde:
> NomeDaTabela - Nome da tabela a ser criada, informado pelo usuário;
> nomeDoCampo - Nome do campo a ser criado na tabela;
> tipo - Tipo de dado do campo;
> tamanho - Tamanho do campo;
> nomeDoCampoPK - Nome do campo que será a chave primária;
> nomeDoCampoFK - Nome do campo que será a chave estrangeira;
> NomeDaTabelaFK - Nome da tabela estrangeira;
> nomeDoCampoPKFK - Nome do campo de chave primária da tabela estrangeira.
Como exemplo, o script da tabela Produto ficaria assim:
CREATE TABLE Produto(
codigo SMALLINT NOT NULL,
descricao VARCHAR(20),
preco MONEY,
PRIMARY KEY (codigo)
);
Para maior aprofundamento no assunto consulte um manual de SQL, pois isto foge ao escopo deste texto. Uma excelente referência é [4].
Desde o surgimento da computação, as técnicas de programação e desenvolvimento de sistemas sofrem modificações, geralmente para melhor, a cada período de tempo.
No início os computadores eram programados diretamente no hardware, através de fios e interruptores, que eram conectados de acordo com a ocasião. Com a evolução dos equipamentos, e o conseqüente aumento das necessidades de processamento, surgiram as primeiras linguagens de programação, ainda de baixo nível, como o Assembly, de difícil compreensão, muito próximo da linguagem do computador.
Para vencer esta dificuldade começaram a ser desenvolvidas as linguagens de alto nível, mais próximas da linguagem humana, cuja sintaxe de comandos são palavras, inteiras ou abreviadas, em inglês. Até aí os programas eram desenvolvidos de forma linear, um comando depois do outro, e assim eram executados. Era a programação linear.
Com o aumento da complexidade dos softwares, pesquisadores começaram a se preocupar com a estrutura dos programas, de forma que ficasse mais fácil criar programas ainda mais complexos, pois a programação linear era muito difícil de ser corrigida, já que o programador freqüentemente se perdia em meio aos desvios e loops existentes. A partir do aperfeiçoamento e adequação das linguagens de alto nível, tornou-se possível desenvolver programas baseados em funções agrupadas em módulos, onde cada módulo era responsável por determinadas funções, e o conjunto de módulos formava o sistema completo. Eis que surge a programação estruturada. Este tipo de abordagem seguiu dois caminhos principais, a programação orientada a funções, onde a base do projeto do software eram os processos necessários à execução das tarefas, e a programação orientada a dados, no qual o projeto do sistema era baseado no modelo de dados. Alguns autores acreditam que a abordagem nos dados é melhor, pois funções são baseadas nas regras do negócio, e regras mudam constantemente, já os dados sofrem muito menos alterações no mesmo período de tempo, por isso apresentam maior consistência.
O paradigma estruturado resolveu grande parte dos problemas por um bom período. As críticas apareceram quando desenvolvedores do mundo todo perceberam que ainda era muito difícil realizar manutenção ou extensão dos softwares estruturados. Não se chega a um consenso sobre o motivo, alguns afirmam que isto se deve à falta de documentação, outros alegam falta de preocupação com a análise e o projeto. Contudo, todos concordam que ele não conseguia atender à crescente demanda por sistemas de grande complexidade, e que exigiam prazos reduzidos para conclusão, além de possibilitar a manutenção e a extensão de pontos específicos do sistema sem que isto afetasse tanto os outros componentes. Em grande parte dos sistemas estruturados, seria mais fácil começar do zero do que realizar uma alteração bem sucedida.
A proposta que alcançou o nível mais próximo do ideal foi a de tratar os sistemas como eles realmente são. Qualquer software é, na verdade, uma representação da realidade, e o mundo real é composto de objetos independentes que se relacionam. Os objetos possuem características e realizam ações próprias, que os diferenciam dos demais. Alguns objetos possuem características e realizam ações similares, por isso podem ser facilmente agrupados em um tipo de objeto, um modelo que serve de referência para qualquer objeto deste tipo.
A partir do estudo dos objetos surge a programação orientada a objetos, um novo paradigma cuja idéia principal é a de modelar os sistemas considerando que cada classe de objetos possui características (dados) e realizam ações (funções) próprias.
O sucesso da POO se deve ao fato de que representando o problema como objetos fica bem mais fácil analisar e compreender a complexidade de qualquer sistema, tanto os mais simples quanto os mais complexos, os quais a PE não conseguia representar com a fidelidade e a simplicidade desejadas. Na POO uma alteração realizada em uma classe geralmente não afeta o restante do software, então a manutenção ou a extensão se resume a alterar o ponto desejado.
A POO introduziu vários conceitos novos, além de utilizar alguns já existentes, mas que ganharam um novo sentido. Para compreender melhor uma sistema OO é importante conhecer pelo menos alguns deles.
Como ensinar orientação a objeto também não é o foco deste manual, os interessados em aprofundar os conhecimentos deverão procurar textos apropriados. Uma ótima referência é [1].
Objeto => Segundo [1], objeto é qualquer indivíduo, lugar, evento, coisa ou conceito aplicável ao sistema, sobre o qual se deseja armazenar informações, ou que seja necessário ao desenvolvimento do software.
Ex: um gato é um objeto, uma televisão é um objeto, um carro é um objeto, um cliente é um objeto, um relatório é um objeto, um documento de texto é um objeto, etc.
Classe => Grupo de objetos similares, utilizada para definir um objeto apenas uma vez. Imagine uma empresa com 1.000 clientes, tendo que modelar um objeto para cada cliente. Ao invés disso modelamos uma classe Cliente, que é a base para a criação de um objeto. A classe contém todas as informações que precisamos para construir um objeto.
Ex: Todas as características que um gato possui, e ações que ele executa são modeladas na classe. Quando criarmos o objeto gato usaremos as informações da classe para isto.
Normalmente modelamos uma classe como um retângulo dividido em três partes. A primeira contém o nome da classe, a do meio os atributos, e a inferior os métodos.
| Nome da classe | Cliente |
| Atributos |
cpf |
| Métodos |
obter( ) |
Instância => É o objeto criado a partir da classe. Cada objeto criado é uma instância da classe.
Abstração => Quando modelamos a classe não utilizamos, na verdade, todas as características do objeto, e sim apenas aquelas que tem alguma relação com o sistema a ser desenvolvido, ou seja, apenas aquilo que interessa. Quando escolhemos as características e ações que são importantes estamos abstraindo as informações do objeto a ser modelado.
Ex: Quando modelamos uma classe Cliente para uma farmácia não precisamos saber, por exemplo, o número do sapato ou do manequim do cliente. Já em uma loja de moda estas informações já seriam relevantes. Para decidir quais ações ou características são relevantes devemos fazer a abstração do objeto dentro daquele determinado propósito.
Atributo => São as características que o objeto possui. Para um objeto Cliente teríamos como atributos o nome, o cpf, o endereço, etc. Atributo é tudo aquilo que deva ser lembrado sobre o objeto.
Método => É tudo aquilo que o objeto é capaz de fazer. Um objeto Aluno pode, por exemplo, solicitar matrícula, realizar exame, ser reprovado, etc.
Persistência => É a capacidade de um objeto manter suas informações por tempo indeterminado. Em outras palavras um objeto é persistente quando ele foi salvo, ou gravado, em um meio físico, para que possa ser recuperado posteriormente.
Mensagem => Como no mundo real os objetos precisam da ajuda de outros objetos para realizarem suas funções. Um objeto Aluno, quando solicita trancamento de matrícula, precisa da ajuda do objeto Coordenação para realizar esta tarefa. Para que isto ocorra ele deve enviar uma mensagem ao objeto Coordenação informando seu desejo de trancar a matrícula. Na prática, a troca de mensagens se dá pelas chamadas de funções, ou métodos, das classes dentro do sistema.
Encapsulamento => Um dos maiores benefícios da OO é a possibilidade de escondermos do mundo externo o modo como são implementados os atributos e os métodos de uma classe. Para que um objeto solicite uma informação de outro, ou solicite a execução de uma ação, ele não precisa saber como ela se dará realmente, pois apenas o resultado interessa. Como ilustração podemos citar o sistema de frenagem dos carros. Para que um objeto Carro freie nós sabemos que basta pisar no pedal de freio. Como estão organizadas as engrenagens, mangueiras, pastilhas e discos não interessa. O sistema de freio de um carro popular é diferente do sistema de um carro de luxo com ABS, por exemplo, mas nos dois casos o motorista não precisa saber disso para frear, basta pisar no pedal e a ação frenagem será executada, resultando na parada do carro.
Herança => Um objeto pode herdar características ou funções de outro. Em um sistema escolar encontramos a necessidade de modelar duas classes distintas, Aluno e Professor, pois cada um deles possui informações e executam ações diferentes um do outro, mas também possuem similaridades, como nome, endereço, entre outras. Para evitarmos que uma eventual alteração neste tipo de dado seja feita em mais de um local, podemos modelar uma classe chamada Pessoa, que contenha os atributos comuns a Aluno e Professor, em seguida fazemos que Aluno e Professor herdem estas características de Pessoa. A regra também vale para quando temos uma classe que possui os mesmos atributos e executa as mesmas ações de outra, mas de uma maneira diferente. Para isto utilizamos a herança em conjunto com o polimorfismo.
Polimorfismo => Capacidade que as classes tem de possuir atributos ou métodos iguais, mas que executam suas ações de maneiras distintas, devendo ser implementadas separadamente. Conforme descrito no caso anterior, a segunda classe herda todos os atributos e métodos da primeira, e redefine os atributos e métodos próprios, mantendo o mesmo nome. Quando um objeto externo enviar uma mensagem a ação executada será aquela correspondente à classe para a qual a mensagem foi enviada. Em resumo, polimorfismo ocorre quando ações diferentes podem ser executadas a partir do mesmo comando, ou seja, quando da chamada de um mesmo método cada objeto responde a sua maneira.
3.2 - OO no Visual Basic for Applications
O Visual Basic for Applications oferece suporte à alguns dos aspectos da orientação a objeto, permitindo a criação de objetos personalizados com encapsulamento, métodos construtores e destrutores, e, inclusive, interface de classe.
Entretanto não é possível implementar a herança, uma das características mais importantes da OO. Como conseqüência, também não é possível utilizar o polimorfismo. O VBA não fornece suporte a este recurso, então qualquer sistema que envolva classes deve ser projetado utilizando-se cada classe implementada inteiramente. Mesmo que possua características semelhante a outras, a utilização dos mecanismos de generalização/especialização não poderão ser aplicados.
O VBA fornece um recurso nativo para a implementação de métodos que atribuem / retornam valores de atributos da classe. São os procedimentos Property Let (atribuem valores aos atributos) e Property Get (retornam valores de atributos). Eles devem ter o mesmo nome, mas ao instanciar um objeto o usuário tem acesso aos métodos como se fossem uma propriedade. Para atribuir um valor basta igualá-la a um valor de uma variável, por exemplo. Da mesma forma, para recuperar o valor de um atributo para igualar uma variável à "propriedade", por exemplo.
Exemplo de procedimentos Property Get e Property Let
Property Get codigo() As Integer
codigo = intCodigo
End Property
Property Let codigo(argCodigo As Integer)
intCodigo = argCodigo
End Property
Existe também um outro mecanismo, diferente de outras linguagens, utilizado para referência a objetos. Quando um objeto possui um atributo que faz referência a um objeto, esta referência é feita através do procedimento Property Set.
Exemplo de procedimentos Property
Set
Property Set atributo(argAtributo As
Object)
Set atributo = argAtributo
End Property
Conforme prevê as regras da POO, não se deve fornecer acesso direto aos atributos de um objeto, obedecendo ao conceito de encapsulamento, pois no caso de qualquer alteração no tipo de dado ou inclusão de uma ação a ser executada quando da atribuição ou recuperação de um valor do atributo, a classe continuará oferecendo a mesma interface de comunicação com outras classes. Isto resulta em esforço mínimo para a manutenção ou extensão do código.
Ao criar uma classe com o Genesis, todos os procedimentos Property Let, Property Get e Property Set são criados automaticamente, assim como os métodos construtor, destrutor, obter, salvar, incluir, excluir e o método valorPadrao, que redefine os valores dos atributos de um objeto para os valores padrão da classe. Dependendo do tipo de chave estrangeira escolhida pelo usuário, também será criado o método de vetor de registro, ou incluído o objeto de descrição de tipo. Os conceitos de vetor de registro e descrição de tipo são detalhados no tópico 4.2.
Os próximos tópicos descrevem as funcionalidade do Genesis, além de dar dicas para utilizar os recursos oferecidos de maneira a conseguir o máximo de desempenho.
A ferramenta foi desenvolvida no Access XP, porém com o padrão 2000. Como todos sabem (quem não sabe dê uma olhada no help) as bibliotecas do XP são diferentes das existentes no 2000, então quem for utilizá-lo com uma versão inferior ao XP, verifique antes as referências (menu Ferramentas/Referências no Editor do VB), pois com certeza o programa não rodará corretamente.
Além das bibliotecas padrão do Access, este programa utiliza as seguintes referências, na ordem em que aparecem:
OLE Automation
Microsoft ActiveX Data Objects 2.5 Library
Microsoft ActiveX Data Objects Recordset 2.7 Library
Microsoft DAO 3.6 Object Library
Caso não utilize o XP, sua versão deve possuir referências diferentes. Desmarque as existentes, que deverão estar indicadas como " AUSENTES ", e procure uma equivalente, a mais próxima possível. Normalmente elas têm o mesmo nome, alterando apenas o número da versão. Quando encontrá-la marque, compile e teste o programa até que encontre todas as bibliotecas necessárias.
O pacote inclui algumas das bibliotecas utilizadas pelo XP. Encontre-as na pasta " ado ". Apenas utilize-as se na sua versão XP estiver faltando alguma delas. Para saber teste o programa antes. Não tente utilizá-las com uma versão diferente do XP, ou seu sistema pode ser corrompido, e talvez seja necessário reinstalar o Office.
Visando padronizar o estilo das classes e do banco de dados que serão criados, siga os padrões para nomear tabelas e atributos, e inserir descrições conforme será apresentado no início dos tópicos 4.1 e 4.2. A funcionalidade não será afetada, mas os atributos, as tabelas e as classes geradas pelo Genesis tem seus nomes modificados ou são acrescentadas iniciais que podem prejudicar a estética do sistema caso as regras não seja seguidas.
Conforme indicado anteriormente, o código do Genesis é aberto, e você pode realizar modificações a seu critério para personalizar a padronização dos nomes de tabelas, atributos e classes.
Padrão proposto para tabelas:
Primeira letra em maiúscula;
Letras restantes em minúscula;
Nomes compostos por mais de uma palavra separados por maiúscula;
Não utilize acentos ou cedilha.
Ex: Departamento, Produto, Cliente, TipoCliente e CategoriaProduto
Quando o Genesis cria uma classe para a tabela é acrescentada a palavra classe no início do nome da mesma, resultando em uma classe com a inicial minúscula e as separações em maiúscula. Os exemplos acima ficariam assim:
Ex: classeDepartamento, classeProduto, classeCliente, classeTipoCliente e classeCategoriaProduto
Caso você colocasse um nome, por exemplo, em minúscula, não haveria a separação das palavras. Nomes com underscore também prejudicariam, resultando em nomes de classe da seguinte maneira:
Ex: classedepartamento, classePRODUTO, classeTipo_Cliente e classeCATEGORIA_PRODUTO
Para criar uma nova tabela clique no botão ►* (novo registro), localizado no canto inferior esquerdo do formulário principal. Será criado um registro em branco.
Coloque o nome da tabela que deseja criar no campo Tabela , localizado no canto superior esquerdo do formulário principal, e a descrição da mesma logo abaixo, no campo Descrição, para que esta seja adicionada aos relatórios de documentação (estrutura da tabela e dicionário de dados) e ao relatório SQL.
Apenas as tabelas que estiverem com o campo Criar marcado serão exportadas quando o botão Exportar Classes for clicado. Para excluir uma tabela clique no botão ao lado do campo Tabela. Uma tabela não pode ser excluída se ela tiver ainda algum campo. Exclua todos os campos antes de excluir uma tabela.
Criada a tabela inclua os atributos.
4.2 - Trabalhando com os campos da tabela
Padrão proposto para os campos das tabelas:
Primeira letra em minúscula;
Letras restantes em minúscula;
Nomes compostos por mais de uma palavra separados por maiúscula;
Campos de chave primária ou estrangeira em que será utilizado um código inclua a inicial cod no nome do campo;
Não utilize acentos ou cedilha.
Ex: codDepartamento, descricao, valor, codCliente, dataNascimento, mesEntradaProduto e categoriaProduto
Quando o Genesis cria um atributo de classe para um campo de tabela é acrescentado um prefixo que indica o tipo de dado, conforme a descrição a seguir:
String => str
Date/Time => dtm
Integer => int
Long => lng
Single => sgl
Double => dbl
Currency => cur
Object => obj
Recordset => rst
Boolean => boo
Além disso a primeira letra do nome do atributo é convertida para maiúscula para manter o padrão. Os exemplos acima ficariam assim:
Ex: intCodDepartamento, strDescricao, curValor, intCodCliente, dtmDataNascimento, intMesEntradaProduto e strCategoriaProduto
Os próximos tópicos descrevem como criar os campos da tabela
4.2.1 - PK - Primary Key
Marque este campo para indicar que o atributo faz parte da chave primária da tabela. Ao indicar um campo como chave primária ele aparecerá na caixa de combinação do campo Atributo FK de outras tabelas, para que possa ser usado como chave estrangeira.
4.2.2 - Atributo
Informe neste campo o nome do atributo, de acordo com o padrão apresentado para nomes de campos de tabela.
4.2.3 - Requerido
Marque este campo para indicar que o atributo é obrigatório e não pode conter um valor nulo.
4.2.4 - Tipo
Escolha o tipo de dado para o atributo. Os tipos possíveis são:
String => Texto com até 255 caracteres;
Memo => Texto com tamanho indeterminado;
Date/Time => Data e/ou hora, tamanho 8 bytes;
Integer => Número inteiro com 2 bytes de tamanho (-32.768 a 32.767);
Long => Número inteiro longo com 4 bytes de tamanho (-2.147.483.648 a 2.147.483.647);
Single => Decimal com ponto flutuante com 4 bytes de tamanho (±3,402823E38 a ±1,401298E-45);
Double => Decimal com ponto flutuante com 8 bytes de tamanho (±1,79769313486232E308 a ±4,94065645841247E-324);
Currency => Número com ponto fixo com 15 dígitos à esquerda da vírgula e 4 dígitos à direita da vírgula, utilizado para cálculos de precisão por envolver valores em dinheiro (-922.337.203.685.477,5808 até 922.337.203.685.477,5807);
Object => Endereços com tamanho de 4 bytes, que se referem a objetos (Imagens, documentos, planilhas, etc...);
Boolean => Número com tamanho de 2 bytes que representa os valores lógicos True e False. A equivalência entre os valores e os números é 0 para False e qualquer outro número para True. Um valor True convertido para número retorna 1.
4.2.5 - Tamanho
Informe neste campo o tamanho de atributos do tipo String. O tamanho mínimo permitido é 1 e o máximo é 255 caracteres. Caso seja colocado um valor fora do intervalo o Genesis informará o erro e colocará o valor padrão. Os outros tipos de campo não podem ter tamanho de campo diferente do padrão.
Estes são os tamanhos padrão para cada tipo de campo:
String => 30;
Memo => 0;
Currency, Double e Date/Time => 8;
Integer e Boolean => 2;
Object, Long e Single => 4.
4.2.6 - Valor Padrão
Informe neste campo o valor padrão para os atributos. O valor padrão deve estar de acordo com o tipo de dado. O valor padrão somente será utilizado pela classe, não causando efeito sobre o código SQL de criação da tabela, devido ao Access não aceitar a cláusula DEFAULT.
Os tipos de dados Object não aceitam valor padrão.
Para campos de tipo numérico o Genesis atribui o valor 0 como valor padrão. Caso seja inserido um valor de texto ou um valor fora do intervalo o Genesis informará o erro e atribuirá o valor padrão.
Campos tipo data e hora deve seguir o formato dd/mm/aaaa hh:mm:ss. É importante manter a barra e os dois pontos, mas os números podem ser escritos com dígitos menores (1/2/05 1:40). É permitido escrever somente a data ou a hora. Valores numéricos (sem as barras ou dois pontos) serão convertidos em data ou hora, podendo resultar em datas e horários não esperados. O valor padrão atribuído pelo Genesis é uma função que busca a data atual do sistema e converte em texto (CStr(Date)). A função é utilizada pela classe.
Campos do tipo String ou Memo aceitam qualquer valor como valor padrão. O Genesis não atribui valor padrão para estes tipos.
4.2.7 - Atributo FK - Foreign Key
Indique neste campo o atributo (chave primária da tabela de destino) que servirá de referência para a chave estrangeira.
Os possíveis atributos são listados e podem ser acessados inclusive a partir da mesma tabela. Isto ocorre quando, por exemplo, um atributo referencia outro atributo da mesma tabela, criando um auto-relacionamento. Esta situação poderia ocorrer em casos como o de uma empresa onde um funcionário é chefe de outro, ou um departamento é subordinado a outro, ou quando um produto é componente de outro, e a melhor forma de mapear este relacionamento seja uma tabela única.
Você só pode criar uma chave estrangeira que referencie um campo de chave primária de outra tabela, ou da mesma tabela, se os dois campos forem do mesmo tipo. Como exemplo um campo do tipo Integer não pode referenciar um String, e assim sucessivamente.
4.2.8 - Tipo FK
Ao incluir uma chave estrangeira na tabela com certeza você fará uso desta ligação também nas classes. Para compreender a utilidade deste recurso, imagine os dois casos a seguir:
| 1° Caso: Descrição de Tipo | ||
| Fita | Categoria | |
|
intCodFita |
* 1 |
intCodCategoria |
|
obter( ) |
obter( ) |
|
No primeiro temos uma relação entre Fita e Categoria, duas classes de uma locadora de fitas de vídeo. Nesta locadora o valor de locação não é colocado individualmente nas fitas. Elas são classificadas em categorias, como Lançamento, Catálogo, Infantil e Promoção, para que seja facilitado o trabalho de alteração de preços. Ao se modificar o valor de locação de uma categoria todas as fitas estarão atualizadas automaticamente.
Veja bem, no código da classe Fita deverá existir um método novaLocacao() ou algo parecido, que será responsável pela efetivação de uma locação de fita. Para calcular o valor da locação o método teria que instanciar a classe Categoria, verificar a que categoria a fita pertence, através do atributo intCategoria, e solicitar a ela o valor da locação.
Até aí tudo bem, mas então qual a utilidade do recurso Descrição de Tipo? Pois bem, este recurso cria automaticamente um atributo do tipo objeto da classe que precisa ser instanciada (Categoria), e toda vez que o atributo de chave estrangeira intCategoria é atualizado, a referência à classe Categoria também é atualizada através do atributo objeto criado.
No exemplo dado os atributos da classe Categoria podem ser acessados através da classe Fita, da seguinte maneira:
'Declaramos algumas variáveis conforme a necessidade
Dim curPrecoLocacao As Currency
Dim strDescricao As String
'Declaramos e instanciamos o objeto Fita
Dim objFita As New classeFita
'Obtemos o objeto fita cujo código é 1012
objFita.obter(1012)
'Acessamos os atributos da classe Categoria
strDescricao = objFita.Categoria.descricao
curPrecoLocacao = objFita.Categoria.valorLocacao
'De dentro da classe Fita o acesso seria mais simples, da seguinte maneira
strDescricao = Categoria.descricao
curPrecoLocacao = Categoria.valorLocacao
Vamos analisar agora o segundo caso, o Vetor de Registro. A descrição de tipo serve para buscarmos um valor único em outra classe, mas imagine, como no exemplo abaixo, um Departamento que queira obter uma relação com todos os Funcionários que trabalham no mesmo. Uma solução seria criar um Recordset, executar uma consulta e navegar através dele para coletarmos os dados desejados.
Visando facilitar este trabalho, ao se definir uma chave estrangeira como VR, o Genesis inclui automaticamente um método vetorNomeDaClasse() na classe atual, cujo valor de retorno é exatamente um Recordset contendo todos os objetos que pertencem ao objeto que possui o método, neste caso todos os funcionários que pertencem ao departamento.
| 2° Caso: Vetor de Registro | ||
| Funcionario | Departamento | |
|
strCpf |
* 1 |
codDep |
|
obter( ) |
Property Let codDep( ) |
|
Veja no modelo de classes que, após definir intCodDep como chave estrangeira do tipo VR, foi criado o método vetorFuncionario() na classe Funcionario, o qual utiliza o valor do atributo para saber a que Departamento pertence o funcionário. A consulta é feita via SQL, diretamente no BD, mas a atribuição dos valores foi originada anteriormente pelos atributos do objeto.
Além disso foram incluídos dois atributos na classe estrangeira, a que precisa da relação, um objeto da classe que contém o VR e um Recordset que recebe os registros retornados da consulta. A operação é executada toda vez que os atributos chave da classe estrangeira são atualizados. Neste caso quando codDep é alterado pelo procedimento Property Let codDep(), os atributos objFuncionario e rstFuncionario também são atualizados pelo procedimento.
A partir daí podemos navegar pelo Recordset normalmente através da classe Departamento, ou acessar suas propriedades, da seguinte maneira:
'Navegando pelo Recordset
objDepartamento.rstFuncionario.moveNext
'Verificando a quantidade de registros de funcionários
objDepartamento.rstFuncionario.recordCount
'Acessando um atributo do funcionário
objDepartamento.rstFuncionario.Fields("nome")
Devemos nos lembrar que em nenhum momento o programador necessita instanciar as classes ou os Recordset´s para implementar estes recursos, pois o Genesis deixa todo o código pronto. Ao programador cabe apenas instanciar a classe com a qual vai trabalhar e fazer uso das facilidades apresentadas.
Importante:
O recurso Descrição de Tipo só é implementado automaticamente quando a classe estrangeira possui chave primária única. Quando a classe estrangeira possui chave primária composta por mais de um atributo o Tipo FK será ignorado.
O recurso Vetor de Registro só é implementado automaticamente quando as duas classes possuem chave primária única. Nas classes em que a chave primária é composta de mais de um atributo o Tipo FK será ignorado.
4.2.9 - Ordem
Este recurso tem a única, mas não menos importante, utilidade de separar chaves estrangeiras para uma mesma chave primária da tabela estrangeira. Isto ocorre quando temos dois ou mais atributos semelhantes em uma tabela fazendo referência ao mesmo atributo FK de outra tabela. Raramente isto acontece, mas no caso de ocorrer lembre-se de utilizar a Ordem, ou ocorrerá um erro tanto na criação da tabela quanto da classe.
Para ilustrar melhor a necessidade veja um exemplo prático. Em um hospital os médicos trabalham por escala de plantão. Digamos que o sistema do hospital mantém o registro das equipes que concorrem ao plantão diariamente. Suponha que o BD esteja organizado mais ou menos assim:
Tabela Medico
| Código | Nome | Especialidade | CRM |
| 1 | Paulo Almeida | Clínico | 123456 |
| 2 | Adriana Mendes | Obstetra | 456123 |
| 3 | Otávio Santos | Pediatra | 228789 |
| 4 | Marcela Saraiva | Clínico | 456984 |
| 5 | Luciano Couto | Neurologista | 228156 |
Tabela Plantao
| Data | Turno | MedicoEscalado | MedicoSubstituto |
| 20/01/2005 | D | 2 | 2 |
| 22/01/2005 | N | 1 | 3 |
| 27/01/2005 | D | 4 | 4 |
| 12/02/2005 | N | 5 | 5 |
| 14/02/2005 | D | 1 | 1 |
| 04/03/2005 | N | 2 | 4 |
Podemos notar claramente que o sistema guarda os registros do médico que estava escalado para o plantão e o médico que efetivamente tirou o plantão. Quando os dois códigos são iguais significa que não houve substituição. Mas o importante é perceber que tanto o atributo MedicoEscalado quanto MedicoSubstituto da tabela Plantao referenciam a mesma chave primária da tabela Medico, ou seja, o atributo Codigo.
Para que o Genesis não confunda um caso como este com um caso de chave composta por mais de um atributo, você deve diferenciar os atributos FK definindo Ordens diferentes para os mesmos. Poderíamos definir o campo Ordem para o atributo MedicoEscalado com o valor 1 e para MedicoSubstituto com o valor 2, por exemplo. Nos casos de chave composta deve ser mantida a mesma Ordem para todos os atributos, para o caso de apenas um conjunto de chave estrangeira, ou uma ordem para cada conjunto, no caso de haver mais de um.
Em resumo, a Ordem representa uma seqüência de chaves, ou conjunto de chaves, estrangeiras para uma mesma chave, ou conjunto de chaves, primária.
4.2.10 - Descrição
Informe neste campo a descrição do atributo, para que ela seja adicionada aos relatórios de documentação (estrutura da tabela e dicionário de dados) e aos comentários da classe. A descrição pode ter até 150 caracteres.
Lembre-se de utilizar texto que deixe claro a função do atributo, e que esteja livre de erros de ortografia ou gramática, zelando, assim, pela estética da documentação e do sistema que será gerado.
Para campos de chave estrangeira, a sugestão é colocar a sigla FK - no início da descrição, para identificá-lo como tal.
Para gerar o código da classe atual clique no botão Gerar Classe. O código será criado e apresentado em um formulário independente. O campo Criar não precisa estar marcado para a utilização deste comando.
Um conhecimento prévio dos conceitos OO auxilia na compreensão dos códigos desta parte do manual. Em caso de dúvida consulte o item 3 ou uma das referências apresentadas, para se aprofundar no assunto.
Primeiramente vamos conhecer a estrutura completa de uma classe gerada pela ferramenta Genesis.
Estrutura da classe gerada pelo Genesis
| Nome da classe | classeNomeDaTabela |
| Atributos |
booChaveAlterada |
| Métodos |
Property Let
atributoIdentificador1( ) |
Nome da Classe => Conforme descrito anteriormente, o nome da classe é criado adicionando-se o prefixo classe ao nome da tabela.
classeNomeDaClasse
Atributos => É criado um atributo para cada campo da tabela. Para cada campo de chave primária é criado também um atributo de backup, utilizado pelo método salvar, pois no caso de ocorrer uma alteração de um atributo chave não seria mais possível atualizar o BD pelo novo valor. Neste caso o método salvar não faria efeito, então ele utiliza o valor do backup para executar a consulta atualização, em seguida altera todos os atributos para os novos valores, caso a operação ocorra com sucesso. Além destes atributos particulares de cada classe, são criados dois atributos genéricos, booChaveAlterada e booAtributoAlterado, ambos lógicos, utilizados para indicar alterações nos valores de atributos chaves e atributos comuns, respectivamente. Estes atributos não possuem função específica, e podem ser utilizados pelo desenvolvedor conforme a necessidade.
booChaveAlterada
booAtributoAlterado
bkpAtributoIdentificador1
tipoAtributoIdentificador1
: :
bkpAtributoIdentificadorN
tipoAtributoIdentificadorN
tipoAtributoExtra1
: :
tipoAtributoExtraN
Métodos de acesso aos Atributos => Para cada atributo originado de um campo da tabela são criados dois métodos, um para atribuir valor (Property Let, ou Property Set para objetos não chave) e outro para recuperar valor (Property Get). Dentro destes métodos podem existir funções extras, como as que implementam o VR, dependendo do contexto.
Property Let
atributoIdentificador1( )
Property Get atributoIdentificador1( )
:
:
Property Let
atributoIdentificadorN( )
Property Get atributoIdentificadorN( )
Property Let atributo1( )
[Property Set atributo1( )]
Property Get atributo1( )
:
:
Property Let atributoN( )
[Property Set atributo1( )]
Property Get atributoN( )
Métodos construtor e destrutor => Os métodos construtor e destrutor são criados sem qualquer código executável. Apenas a estrutura deles é gerada. Para utilizá-los basta inserir código dentro deles. Todo código que estiver dentro do método class_initialize() será executado sempre que um objeto da classe for instanciado. Da mesma forma todo código dentro de um método class_terminate() será executado sempre que a classe encerrar a sua existência, mas antes que isto realmente ocorra.
class_initialize( )
class_terminate( )
Métodos de acesso ao BD => São os métodos básicos de acesso ao banco de dados, utilizados para realizar a persistência dos objetos. O método obter() é utilizado para a recuperação de um objeto, recebendo como parâmetro o(s) valor(es) do(s) atributo(s) chave da classe, e realizando uma consulta a partir deste(s) valor(es). O método incluir() faz o oposto. Depois de definidos os valores dos atributos, este método os coleta e inclui o novo objeto no banco de dados, tornando-o persistente. O método salvar() grava as alterações feitas aos atributos do objeto no banco de dados. Um objeto só pode ser salvo se já existia anteriormente. Objetos novos devem ser incluídos antes que se possa salvá-los. O método excluir() apaga o registro referente ao objeto no banco de dados. Todos este métodos retornam verdadeiro caso a operação ocorra com sucesso, ou falso em caso contrário.
obter( )
incluir( )
salvar( )
excluir( )
Valor Padrão => Método que redefine todos os atributos de volta aos seus valores padrão, seja os que você informou quando da criação da tabela, ou os valores padrão do sistema, em caso contrário. O método valorPadrao() é executado toda vez que um objeto é excluído com sucesso, imediatamente após o término da operação. Você pode utilizá-lo a qualquer momento para "limpar um objeto".
valorPadrao( )
VR e DT => Os atributos e o método criados para a implementação da descrição de tipo e do vetor de registro foram detalhados no item 4.2.8, que trata sobre o campo TipoFK. São os objetos que referenciam outra classe para obter valores de atributos da mesma, no caso da DT, ou uma relação de registros, no caso do VR. Estes atributos e o método são gerados apenas quando o usuário define uma chave estrangeira com um dos dois tipos.
NomeDaClasse
rstNomeDaClasse
objNomeDaClasse
vetorNomeDaClasse( )
4.4 - Gerando o código SQL da tabela
Para gerar o script SQL de criação da tabela clique no botão Gerar SQL. O código será criado e uma mensagem de confirmação informará o sucesso da operação.
4.5 - Gerando a classe de conexão
Para gerar o código da classe de conexão clique no botão Gerar Conexão. O código será criado e apresentado em um formulário independente.
As classes geradas pelo Genesis necessitam da classe de conexão para acessar o banco de dados, pois ela encapsula as funcionalidades de consulta e atualização. Veja uma breve descrição dos métodos presentes na classe:
atualizaBanco(codigoSql As String) As Boolean => Recebe um código SQL como parâmetro e executa uma ação no banco de dados. Pode ser uma inclusão (Insert), atualização (Update), exclusão (Delete), uma criação de tabela (Create Table), ou qualquer outra ação que não retorne registros. O método retorna verdadeiro caso a operação ocorra com sucesso, ou falso em caso contrário.
consultaBanco(codigoSql As String) As Recordset => Recebe um código SQL como parâmetro e retorna um Recordset com o resultado da consulta. Caso ocorra algum erro na consulta o método retornará Null.
pontoVirgula(varValor As Variant) As String => Recebe um valor numérico qualquer, verifica se existe uma vírgula e, em caso positivo, substitui a vírgula por um ponto e retorna o valor convertido em uma String. Esta operação é necessária principalmente para os métodos que gravam valores no banco de dados, pois o código SQL não pode conter valores para campos numéricos com vírgula, os quais dever ser convertidos para o sistema decimal padrão da sintaxe SQL, ou seja, com ponto separando a parte inteira da parte decimal. Como a simples conversão pela função CStr(x) não retira a vírgula, os métodos devem lançar mão deste recurso oferecido pela classe de conexão sempre que necessitarem incluir ou alterar valores decimais no BD.
4.6 - Visualizando o código SQL da tabela
Para visualizar o script SQL de criação da tabela clique no botão Ver SQL. O código será apresentado em um formulário independente. O código pode ser copiado ou alterado.
4.7 - Visualizando o código da Classe
Para visualizar o código da classe clique no botão Código da Classe. O código será apresentado em um formulário independente. O código pode ser copiado ou alterado.
4.8 - Visualizando o relatório de estrutura das tabelas
Para visualizar o relatório de estrutura das tabelas clique no botão Listar Tabelas. O relatório com as informações solicitadas será apresentado. Para exportá-lo para o Word utilize a função Publicar com o MS Word.
4.9 - Visualizando o dicionário de dados
Para visualizar o dicionário de dados clique no botão Dicionário de Dados. O relatório com as informações solicitadas será apresentado. Para exportá-lo para o Word utilize a função Publicar com o MS Word
4.10 - Visualizando o relatório SQL
Para visualizar o relatório de código SQL das tabelas clique no botão Relatório Código SQL. O relatório com as informações solicitadas será apresentado. Para exportá-lo para o Word utilize a função Publicar com o MS Word
4.11 - Gerando o banco de dados
Para gerar o banco de dados completo clique no botão Gerar BD. A caixa de diálogo do Windows Salvar Como será apresentada. Escolha a pasta e nome do novo banco de dados e clique em Salvar. Caso não ocorram erros uma mensagem será apresentada ao término do processamento informando que o BD foi gerado com sucesso.
Para colocar o projeto em andamento, exporte as classes para uma pasta e, em seguida, importe-as para o BD que acaba de ser criado. Para isso abra o editor do Visual Basic e vá ao menu Arquivo / Importar Arquivo e inclua as classes. Esta operação só permite a importação de uma classe por vez, então seja paciente. Lembre-se sempre de importar a classe de conexão, ou o acesso ao banco de dados não será possível.
Na ocorrência de erros cada um deles será informado, sendo que isto não interrompe o processo de criação do BD. As mensagens tentaram informá-lo sobre o erro para que seja corrigido. Ao final será apresentada a mensagem de conclusão, na qual constará o número de erros ocorridos.
A mensagem final irá sugerir a você que verifique e organize a estrutura dos relacionamentos, pois eles são criados em ordem aleatória, fazendo com que as tabelas fiquem em posições que deixam as linhas dos relacionamentos cruzando-se entre si, de maneira totalmente caótica. Nada que interfira no funcionamento, mas para que você mantenha seu modelo adequadamente, um pouco de ordem não fará mal.
Para gerar e exportar todas as classes de uma só vez clique no botão Exportar Classes. A caixa de diálogo do Windows Procurar Pasta será apresentada. Escolha a pasta para onde deseja exportar suas classes e clique em OK. Caso não ocorram erros uma mensagem será apresentada ao término do processamento informando que as classes foram exportadas com sucesso e exibindo o caminho completo da pasta escolhida.
Atenção: Somente as tabelas que estiverem com o campo Criar marcado serão geradas e exportadas.
Segue abaixo a lista de obras e referências que contribuíram excepcionalmente para a elaboração deste projeto e deste manual.
[1] AMBLER, Scott W. Análise e Projeto Orientado a Objeto, volume II: seu guia para desenvolver sistemas robustos com tecnologia de objetos. Rio de Janeiro, Infobook, 1998.
[2] BOCTOR, David. Microsoft Office 2000 Visual Basic for Applications - Fundamentos. São Paulo, MAKRON Books, 2001.
[3] DEBONI, José Eduardo Zindel. Modelagem orientada a objetos com a UML: técnicas de análise, documentação e projeto de sistemas. São Paulo, Futura, 2003.
[4] PATRICK, John J. SQL Fundamentos: Segunda Edição. São Paulo, Berkeley Brasil, 2002.
[5] MACHADO, Felipe N. R.; MACHADO, Maurício P. A. Projeto de Banco de Dados: Uma Visão Prática - 8ª Edição. São Paulo, Érica, 1996.
[6] PROJETOS do Access 2003. Disponível em:
<<http://office.microsoft.com/pt-br/assistance/CH062526761046.aspx>> Acesso em: 20 fev. 2005.
[7] REFERÊNCIA SQL do Microsoft Jet. Disponível em:
<<http://office.microsoft.com/pt-br/assistance/CH062526881046.aspx>> Acesso em: 16 fev. 2005.