No primeiro artigo, desenvolvemos um pequeno modelo lógico utilizando
a ferramenta de modelagem ErWin 4.0. Fiz uma breve explanação
sobre documentação e o processo de modelagem de dados.
Vamos agora transformar este
modelo lógico em um modelo físico, e gerar um banco de dados no SQL SERVER. Vamos definir “como” nossos dados serão armazenados, quais os tipos de dados utilizaremos para cada campo de nossas tabelas, quais relacionamentos terão exclusão
em cascata, etc.
Domínios
Este é um recurso que irá nos auxiliar muito na manutenção do nosso banco de dados, pois, através da definição de domínios, podemos criar tipos de dados personalizados e, ao alterar um domínio, todos os campos relacionados a ele herdarão esta alteração.
Por exemplo: Percebemos que existem diversos campos em diversas tabelas que armazenarão valores monetários. Neste caso, criaremos um domínio chamado ValMonetario e a ele atribuiremos o tipo “Money” com 10 dígitos sendo 2 decimais. Atribuiremos este domínio para todos os campos que necessitem armazenar valores monetários e, se no futuro for necessário redefinir estes campos para trabalhar com 3 dígitos decimais, basta alterar o domínio, e todos os campos que dele dependem herdarão esta informação.
Pronto, você não precisa sair revisando todo o seu banco de dados atrás de tabelas que possuam este campo para fazer esta alteração campo por campo.
Quem está habituado a trabalhar apenas com tabelas do VFP perceberá que o leque de opções para tipos de dados se amplia bastante, veja nos dois quadros abaixo as diferenças de tipos de dados entre o VFP nativo e o SQL SERVER:
Figura 1: Tipos de Dados Nativos do VFP
Figura 2: Tipos de Dados Utilizados pelo SQL SERVER
O Modelo Físico
A passagem do modelo lógico para o modelo físico é bastante simples, basta mudar a combobox LOGICAL para PHYSICAL, ou então utilizar o atalho das teclas CTRL + SETA ABAIXO, para retornar ao lógico mude a combobox ou então tecla CTRL + SETA ACIMA.
Figura 3: Visão de nosso modelo físico
Observe que a ferramenta de modelagem definiu nossos tipos de dados com um tipo padrão. Vamos agora definir nossos domínios e atribuir estes domínios aos campos, vamos também renomear os campos para que exista uma lógica entre o nome do campo e o nome da tabela.
Existem várias maneiras de fazer isso, e creio que cada um tem preferência por uma, então vou definir os nomes dos campos da maneira que eu acho a mais prática, mas você pode utilizar a sua maneira sem problema nenhum.
Analisando os dados que serão armazenados, percebemos que todas as tabelas possuem um identificador, CLIENTE e PRODUTO necessitam de dados tipo caracter. Também precisamos de campos numéricos e data.
Vamos criar os seguintes dominíos:
Domínio | Valor |
---|---|
Identificador | INT |
String01 | VarChar(60) |
String02 | VarChar(30) |
Quantidade | Number(10,1) |
ValMonetario | Money(10,2) |
CodBarra01 | VarChar(13) |
Data | DateTime |
Vamos lá!
Certifique que a ordenação
esteja na opção hierárquica (Sort -> Hierarchialy).
Clique em New:
Figura 4: Dados do novo Domínio
Figura 5: No próximo passo defina o tipo de dado
Dois pontos interessantes aqui:
O tipo VarChar armazena apenas os dados que foram digitados pelo usuário, ou seja, você irá definir o tamanho com 60 caracteres, este será o valor máximo permitido para o campo, mas se o usuário digitar 10 caracteres, apenas os 10 serão armazenados, economizando 50 caracteres.
Figura 6: Todos os Domínios definido
Projetando isso para um banco de dados que terá centenas de tabelas e receberá milhares de registros, a economia de espaço é muito considerável.
O tipo CHAR equivale ao CHARACTER do Visual FoxPro, este tipo não economiza o espaço ocioso, ou seja, se você definir char(60) todos os registros de sua tabela terão 60 espaços, mesmo se o usuário digitar apenas 10 caracteres.
O outro ponto interessante é a possibilidade de permitir ou não dados nulos nos campos. Como utilizaremos este domínio para definir o nome do cliente e do produto, não deveremos permitir dados nulos. Marque a opção correspondente a NOT NULL.
Se este processo ainda não está claro para você, pesquise um pouco mais sobre dominios pois é um recurso muito útil e que facilita muito a vida do desenvolvedor. Você terá no final deste artigo o link para fazer o download do arquivo de modelagem que foi utilizado como exemplo para este artigo.
Vamos dar um passo a mais.
Definiremos os nomes dos campos das tabelas. Isso já poderia ter sido feito no próprio modelo lógico, não fiz isso para que a idéia de Modelo Lógico ficasse bem diferenciada do modelo físico (LÓGICO = O quê armazenar. FÍSICO = Como armazenar). Neste ponto estes conceitos já devem estar bem definidos, então as coisas começarão a ficar mais homogêneas.
Aproveitando este processo já vamos definir os domínios de cada campo, veja como fazer:
Figura 7: Clique duas vezes sobre a tabela CLIENTE
Figura 11: Clique na guia GENERAL e selecione o domínio IDENTIFICADOR
Seguindo estes passos defina os demais campos da seguinte forma:
Campo | Nome | Dominio |
---|---|---|
Nome_do_Cliente | CliNome | String01 |
Telefone_do_Cliente | CliTelefone | String02 |
Endereco_do_Cliente | CliEndereco | String01 |
A tabela CLIENTE ficará assim
Defina as demais tabelas de forma que fiquem com a seguinte configuração:
Criando o Banco de Dados
Para criarmos nosso banco de dados diretamente da ferramenta de modelagem, é necessário que você possua uma conexão com o SQL SERVER. Caso você queira criar um arquivo com os comandos de criação do banco de dados (script), e depois conectar o servidor para criar o banco, também será possível. Vamos ver esta segunda opção, embora seja um pouco mais trabalhosa, você verá melhor o processo todo: Se você possui uma conexão com o banco de dados, estará instalado em seu computador uma ferramenta chamada QUERY ANALYZER. Execute este aplicativo, ele solicitará o nome do servidor e a senha de acesso. Forneça estas informações, utilize preferencialmente a conta de administrador do SQL SERVER e execute o comando abaixo:
Figura 14: Após escrever o comando tecle F5
Voltando ao ErWin, vamos gerar o arquivo de SCRIPT para criar nosso banco de dados. Vá ao menu TOOLS escolha a opção Forward Engineer/Schema generation…
Figura 15: Clique em Preview…
Figura 16: Na próxima tela clique no botão de salvar
Salvei o arquivo como UTMAG.SQL e está anexado neste artigo juntamente com o arquivo de modelagem atualizado.
Precisamos agora executar este script através do QUERY ANALYZER. Volte a essa ferramenta e abra o arquivo que acabamos de criar, o QUERY ANALYZER irá solicitar que você salve o comando que você utilizou anteriormente para criar o banco de dados. Não é necessário salvar este comando.
Um detalhe importante! Antes de executar o script UTMAG.SQL, certifique-se que o banco que acabamos de criar está em uso, para isso existe uma COMBOBOX que mostra qual banco está em uso, geralmente o banco MASTER é aberto como padrão. Mude esta combobox para o nosso banco (UTMAG).
Figura 17: O arquivo está aberto, observe o detalhe da Combobox e tecle F5
Abaixo você poderá ver se houve algum erro na execução dos comandos do script.
Engenharia Reversa
O processo de engenharia reversa consiste em trazer para a nossa modelagem um banco de dados já existente. Isso facilita a análise de estruturas antigas, assim como a correção da nossa própria estrutura. Observe as opções de engenharia reversa no ErWin, principalmente a opção de comparação entre um banco existente e a modelagem atual. A imagem abaixo mostra a tela de comparação do banco que acabamos de criar com a nossa modelagem. Como estão exatamente iguais não teremos muito o que fazer agora.
No próximo artigo iremos criar uma tabela no SQL SERVER e, através desta ferramenta, iremos trazê-la para a nossa modelagem. Vamos conhecer um pouco a ferramenta Enterprise Manager e fazer a conexão do Visual FoxPro com o SQL SERVER.
O post Um aplicativo VFP/SQL SERVER do início ao fim – Parte 02 apareceu primeiro em .