Transcript
iMasters - Por uma Internet mais criativa e dinâmica
Página 1
Frederico Tomazzeti Sexta-feira, 28 de abril de 2006
Um aplicativo VFP/SQL Server do início ao fim - Parte 01 Este artigo é o primeiro de uma série em que pretendo mostrar como desenvolver um sistema em Visual FoxPro utilizando o banco de dados SQL Server. Esta série de artigos é direcionado à desenvolvedores em VFP que trabalham com tabelas livres ou com tabelas em um DBC do Visual FoxPro e buscam aprender novos métodos de desenvolvimento. Para esta tarefa utilizarei o Erwin 4.0 como ferramenta de modelagem, o SQL Server 2000 e o Visual FoxPro 7.0. Aqui farei alguns comentários sobre documentação, modelagem de dados e o uso do Erwin 4.0. Nesta primeira série não vamos tratar de modelagem de processos e de classes (UML), vamos apenas modelar um pequeno banco de dados que possua um cadastro de clientes, produtos e a emissão de pedidos de venda. Será um exemplo bem didático para que você entenda o processo como um todo. Documentação Este tópico é o ponto fraco da maioria dos desenvolvedores, pois como sempre temos o processo todo em mente deixamos a documentação em segundo plano e, podem ter certeza, sempre saímos prejudicados. Existem vários argumentos que poderia utilizar para lhe convencer a documentar corretamente o seu sistema, entre eles: Facilidade no estudo do projeto por outro desenvolvedor ou até por você mesmo, clareza dos processos, etc. Confesso que o argumento que me convenceu definitivamente da necessidade de uma documentação foi: "Se você não documentar o seu projeto você perderá tempo e principalmente dinheiro". Eu explico. Quando você desenvolve um projeto para um cliente e não detalha o que você vai fazer, não tem um controle do que você já fez e do que ainda falta fazer, você não terminará nunca este projeto. O seu cliente sempre encontra uma "coisinha que ficou faltando", com certeza, depois de tudo funcionando, você já ouviu algo assim: "Aonde está o módulo de integração com o sistema contábil ou com a folha de pagamento?" Se você possuir uma documentação bem feita (e assinada pelo cliente) basta mostrar a ele que este módulo não foi incluído no projeto e se ele quiser este módulo será feito outro projeto, o que certamente significará outra negociação de valores, prazos, etc. Viu como você perde tempo e dinheiro se não documentar o seu processo de trabalho? Espero que este argumento funcione com você também. A modelagem dos dados Enquanto estudava algumas teorias do processo de modelagem com outro desenvolvedor, ele me falou uma coisa que com certeza todos nós já sentimos: "Vou precisar aprender uma coisa que eu não sei para fazer uma coisa que eu já sei". Realmente a modelagem de dados tem como fim a criação do banco, com suas tabelas, campos e relacionamentos, conceitos que todos nós já conhecemos muito bem na prática. Então, para que eu tenho que fazer a modelagem dos dados, por que eu não abro o SQL Server e crio as tabelas que eu preciso de uma vez? Se o argumento da documentação lhe convenceu, você já tem uma resposta para esta pergunta, mas caso você ainda não esteja convencido, tente este: Com a modelagem de dados eu posso criar a mesma estrutura de tabelas em outro banco de dados, como o Oracle, MySQL, SyBase, etc. Ou seja, não preciso ficar recriando tabelas se o meu cliente resolver um dia mudar de plataforma ou se eu quiser aproveitar o mesmo banco para outro cliente. O processo de modelagem Se você ler um livro sobre modelagem de dados verá que tudo, ou quase tudo, que está escrito lá você já faz durante o seu trabalho diário. A modelagem pode ser dividida em três grandes partes: Modelo conceitual: Nesta fase da modelagem é feito um levantamento geral das necessidades do cliente, aqui você não deve se preocupar como você vai fazer o seu banco ou sistema, nem quais ferramentas vai utilizar. Concentre-se em entender o processo todo que você irá informatizar, converse com os futuros usuários, entenda o funcionamento de cada setor da empresa (cliente), faça anotações e acompanhe os processos de produção. Depois disso, você já terá um protótipo do que será desenvolvido. O maior erro desta fase do desenvolvimento é já começar a pensar em quais tabelas você vai criar, quantos "IFS" ou "CASES" seu sistema terá. Esqueça isso por enquanto. Modelo lógico: Agora as coisas começam a tomar uma forma mais lógica para nós desenvolvedores, aqui vamos especificar quais entidades farão parte do nosso modelo de dados, para nosso exemplo as entidades serão: CLIENTE, PRODUTO, PEDIDO e ITEM (é uma boa prática colocar as entidades sempre no singular) e quais os relacionamentos existem entre eles: "CLIENTE faz PEDIDO" e "PRODUTO compõe PEDIDO", ou se você preferir: "CLIENTE compra PRODUTO através de PEDIDO". Neste modelo já definiremos os atributos principais das entidades, por exemplo: CLIENTE possui Código, Nome, Endereço e telefone. PRODUTO possui Código, Nome, preço e código de barras, etc. Aqui você detalha como as coisas acontecem, não se preocupe com a forma que os dados serão armazenados, teoricamente você não sabe ainda nem o banco que será utilizado. Deixe os "IFS" e "CASES" para depois. Modelo físico: Aqui sim você irá definir quais entidades ou relacionamentos serão transformadas em tabelas, quais campos serão considerados como índices, qual o tamanho e o tipo de cada campo, qual campo participa de relacionamentos entre tabelas, ou seja, aqui você já está praticamente "em casa". Você aprendeu uma coisa que você não sabe para chegar em uma coisa que você já sabe. Você deve estar se perguntando: Terei que fazer tudo isso separadamente? A resposta é não. O Erwin fará boa parte do trabalho, pois após definir o modelo lógico, o físico será gerado automaticamente, mas do modelo conceitual você não tem como fugir, ainda não inventaram um aplicativo que substitui a capacidade humana para a análise de situações do mundo real.
http://imasters.uol.com.br/artigo/4005/visual_foxpro/um_aplicativo_vfpsql_server_do_inicio_ao_fim_parte_01/imprimir/
9/28/2010 3:55:41 PM
iMasters - Por uma Internet mais criativa e dinâmica
Página 2
A ferramenta Erwin 4.0 Não cabe ao escopo deste artigo mostrar todas as funcionalidades desta ferramenta, mesmo porque isso levaria muitas páginas de texto. Vamos trabalhar apenas com o necessário para que nosso banco seja modelado. No entanto, existe um tutorial que explica muito bem o funcionamento do ErWin. Ao abrir o ErWin, vá no menu HELP, opção TUTORIAL
Tutorial do ErWin Vamos fazer um rápido "tour" através da ferramenta para identificarmos alguns ítens básicos:
Quando clicamos em NOVO, abre-se um diálogo solicitando maiores detalhes sobre a modelagem que iremos criar, escolha o modelo lógico/físico e o banco SQL Server 2000. Clique em Ok e abrirá então uma área de trabalho totalmente em branco.
Estas são basicamente todas as ferramentas que vamos precisar agora O Botão "A" é utilizado para criar nossas entidades, o conjunto "B" utilizamos para definir os relacionamentos, neste caso os relacionamentos possíveis são, respectivamente: 1 -> N com relacionamento Identificado, N -> N e 1 -> N com relacionamento não identificado. Observe que a figura é formada por uma linha e um ponto em uma das extremidades, o ponto significa o lado "N" do relacionamento, no caso do relacionamento N -> N existe um ponto em cada extremidade. Veremos isso na prática, será mais fácil de entender. A ComboBox "C" indica que estamos trabalhando no modelo lógico, mais adiante vamos mudar esta combobox para trabalhar com o modelo físico de dados. Clique na ferramenta "Entidade" e clique em qualquer parte da área de Trabalho.
http://imasters.uol.com.br/artigo/4005/visual_foxpro/um_aplicativo_vfpsql_server_do_inicio_ao_fim_parte_01/imprimir/
9/28/2010 3:55:41 PM
iMasters - Por uma Internet mais criativa e dinâmica
Página 3
Digite o nome de nossa entidade e tecle enter.
Aqui temos um detalhe bastante importante
Observe que o "attribute_name" está posicionado na entidade como se fosse um sub-título, isto indica que este atributo indicará a nossa futura chave primária da tabela. É bom deixar claro aqui que nós ainda não sabemos "onde" vamos gravar nossos dados, estamos definindo apenas "como" eles serão gravados. N ão vamos nos preocupar com nome de campo, tipo (caractere, numérico, data, etc) ou tamanho. Podemos utilizar nomes compostos sem problema nenhum. Veja como ficará: Agora devemos teclar "TAB", pois assim iremos para a parte inferior da entidade onde colocaremos os demais atributos, caso você tecle "ENTER" novamente você irá colocar mais um atributo que fará parte da chave primária da futura tabela (Você teria neste caso uma chave composta).
Não é o nosso caso agora, vamos então teclar "TAB". Observe o "Attribute_name"
Vamos colocar agora os demais atributos, sempre teclando "ENTER" para mudar de linha.
Já podemos completar nossa modelagem com as demais entidades. Estas serão nossas entidades: (não esqueça! Salve o seu arquivo) O relacionamento entre as entidades Depois de definirmos nossas entidades e seus atributos vamos relacionar uma com a outra conforme a lógica de nosso sistema. Observe o ícone e o relacionamento criado Vamos definir que: Um CLIENTE pode fazer no minimo zero (0) PEDIDOS e no máximo vários PEDIDOS.
http://imasters.uol.com.br/artigo/4005/visual_foxpro/um_aplicativo_vfpsql_server_do_inicio_ao_fim_parte_01/imprimir/
9/28/2010 3:55:41 PM
iMasters - Por uma Internet mais criativa e dinâmica
Página 4
Um PEDIDO terá no mínimo zero (0) ITEM e no máximo vários ITENS. Um ITEM poderá ter apenas 1 PRODUTO mas o PRODUTO pode participar de muitos ITENS de diferentes PEDIDOS. Observe que não é obrigatório ter um PEDIDO para que você possa cadastrar um CLIENTE, mas para você fazer um PEDIDO, você precisa ter pelo menos um PRODUTO cadastrado. Vamos relacionar CLIENTE e PEDIDO, clique na ferramenta relacionamento não identificado (aquela com linha tracejada e um ponto no final). Clique na entidade CLIENTE e depois na entidade PEDIDO, veja como fica:
Novamente obtemos um relacionamento com linhas tracejadas
Vamos relacionar PRODUTO com ITEM. Usaremos a mesma opção:
http://imasters.uol.com.br/artigo/4005/visual_foxpro/um_aplicativo_vfpsql_server_do_inicio_ao_fim_parte_01/imprimir/
9/28/2010 3:55:41 PM
iMasters - Por uma Internet mais criativa e dinâmica
Página 5
Note que o ponto preto no final do traço sempre indica o lado "N" do relacionamento e o ponto branco indica a não dependência do lado "1". Você com certeza já deduziu que o outro ícone utilizará uma linha contínua e representará um relacionamento obrigatório. É isso mesmo, vamos relacionar agora PRODUTO com ITEM:
Considerações finais sobre o Modelo lógico. Observe que ao criarmos os relacionamentos o campo chave da entidade "1" é levado para a entidade "N", quando o relacionamento não é identificado, este campo é colocado com um atributo normal, porém quando utilizamos o relacionamento Identificado (PRODUTO X ITEM) o campo chave do lado "1" fará parte do identificador da outra entidade. Observe ainda que a entidade ITEM sofreu uma alteração no seu formato, agora ela está com os cantos arrendondados, isto indica que ela participa de um relacionamento "N -> N" entre PEDIDO e PRODUTO (Muitos PEDIDOS possuem Muitos PRODUTOS). Nosso modelo lógico está criado, no próximo artigo vamos transformar este modelo lógico em modelo físico, falaremos sobre domínios, criação do banco de dados e engenharia reversa. Código fonte .
http://imasters.uol.com.br/artigo/4005/visual_foxpro/um_aplicativo_vfpsql_server_do_inicio_ao_fim_parte_01/imprimir/
9/28/2010 3:55:41 PM
