UNIMINAS SISTEMA DE GESTÃO DE ESTOQUE E PRODUÇÃO DA FÁBRICA BRASILEIRA DE AERONAVES: PERSISTÊNCIA DE DADOS ANTÔNIO CARLOS DA SILVA

Transcrição

1 UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO SISTEMA DE GESTÃO DE ESTOQUE E PRODUÇÃO DA FÁBRICA BRASILEIRA DE AERONAVES: PERSISTÊNCIA DE DADOS ANTÔNIO CARLOS DA SILVA Uberlândia 2009

2 ANTÔNIO CARLOS DA SILVA SISTEMA DE GESTÃO DE ESTOQUE E PRODUÇÃO DA FÁBRICA BRASILEIRA DE AERONAVES: PERSISTÊNCIA DE DADOS Trabalho de Final de curso submetido à como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Esp. Carlos Henrique de Barros Uberlândia 2009

3 ANTÔNIO CARLOS DA SILVA SISTEMA DE GESTÃO DE ESTOQUE E PRODUÇÃO DA FÁBRICA BRASILEIRA DE AERONAVES: PERSISTÊNCIA DE DADOS Trabalho de Final de curso submetido à como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Esp. Carlos Henrique de Barros Banca Examinadora: Uberlândia, 29 de Agosto de Prof. Esp. Carlos Henrique de Barros Prof. M.Sc. Silvio Bacalá Júnior Profa. Dra. Kátia Lopes Silva Uberlândia 2009

4 A todos que direta ou indiretamente contribuíram para realização deste trabalho e se esforçaram acreditando em sua concretização.

5 AGRADECIMENTOS A Deus por ter me instruído e dado forças para seguir em frente. Ao professor Carlos Henrique de Barros pelo apoio e orientação durante todo o desenvolvimento do trabalho. À Faculdade de Ciências Aplicadas de Minas () e aos professores do curso de graduação de Sistemas de Informação, por terem instruído-me e compartilhado seus conhecimentos e experiências, contribuindo para formação pessoal a intelectual. À minha família pela confiança, motivação e orações durante o desenvolvimento do trabalho. À minha amada Simone P. Cortes e família pelo apoio e orações de todos os momentos. À minha queria tia Joana D. Ribeiro, a Suzana P. M. Marques e Daldy E. Marques, por toda ajuda que me foi dada sem a qual eu não poderia ter alcançado esta vitória.

6 RESUMO O projeto destina-se à Fábrica Brasileira de Aeronaves, uma indústria de aviões situada na cidade de Uberlândia. A empresa visa o desenvolvimento de um software, com o qual seus funcionários possam gerenciar a produção de seus aviões (agrícolas e executivos) e controlar o estoque das mercadorias em seu almoxarifado. Desenvolvido com a linguagem de programação Java juntamente com o framework Hibernate, Padrões de Projeto e o SGBD MySQL, o sistema será implementando com arquitetura MVC (Model View Controller). Palavras Chave: Hibernate, Padrões de Projeto, Java.

7 ABSTRACT The project is for the Brazilian Factory of Aircraft, an aircraft industry, located in the city of Uberlândia. The company aims at developing a system, which its officials manage the production of its aircraft (agricultural and executive) and controlling the stock of goods in its warehouse. Developed with the language programming Java and the Hibernate framework, Design Patterns and SGBD MySQL, the system will be build with the architecture MVC (Model View Controller). Key words: Hibernate, Design Patterns, Java.

8 LISTA DE FIGURAS Figura 1 Avião Falcão AG Figura 2 Avião Falcão AC Figura 3 Avião Bumerangue EX Figura 4 Prêmio de primeiro lugar na categoria Aeronave Experimental...14 Figura 5 Arquitetura SGBD...24 Figura 6 DER Sistema FABE...26 Figura 7 Arquitetura do Hibernate...30 Figura 8 Estrutura de funcionamento do DAO...35 Figura 9 Diagrama de Classe da camada de persistência...36

9 LISTA DE QUADROS Quadro 1 Arquivo hibernate.xml...31 Quadro 2 Arquivo Cidade.hbm.xml...32 Quadro 3 Classe CidadeBO...33 Quadro 4 Classe CidadeBO com annotation...34 Quadro 5 Classe AbstractDAO...38 Quadro 6 Classe FormaPagamentoBOBean...40

10 LISTA DE ABREVIATURAS E SÍMBOLOS ANSI American National Standards Institute API Application Programming Interface CAD Computer Aided Design CEP Código de Endereçamento Postal CSS Cascading Style Sheets DER Diagrama Entidade Relacionamento EJB Enterprise Java Bean ELU Experimental Leve de Uberlândia FABE Fábrica Brasileira de Aeronaves HTML Hypertext Markup Language ISO International Standardization Organization JDBC Java Database Connectivity MOR Mapeamento Objeto Relacional MVC Model View Controller SGBD Sistema de Gerenciamento de Banco de Dados SQL Structured Query Language XML Extensible Markup Language

11 SUMÁRIO 1. INTRODUÇÃO Cenário Atual Identificação do Problema Objetivos do Trabalho Objetivo Geral Objetivos Específicos Justificativa para a pesquisa Organização do trabalho ESPECIFICAÇÃO DO PROBLEMA Especificação de Requisitos Requisitos funcionais Requisitos não funcionais Regras de Negócio PERSISTÊNCIA DE DADOS Banco de Dados SGBD Modelagem de Banco de Dados MAPEAMENTO OBJETO RELACIONAL Padrão de projeto DAO Aplicação do padrão de projeto DAO no sistema FABE Uma melhor abordagem utilizando o DAO DAO e EJB CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS...42

12 12 1. INTRODUÇÃO 1.1. Cenário Atual A FABE surgiu em 1985 com a construção do primeiro ultraleve - o Experimental Leve de Uberlândia (ELU). Por se tratar de um modelo que possuía um bom desempenho e um design inovador, surgiram as primeiras encomendas. Assim iniciou-se a busca por investimentos que viabilizassem a produção de aeronaves em alta escala. Conforme o proprietário da FABE, Erick Nilson Rodrigues da Cunha (2006), para viabilizar uma produção em escala, seria necessária a alocação de um valor expressivo de capital, o que não dispúnhamos naquela época. A solução mais viável foi buscar investimentos. O Grupo Constrular, formado por empresas tradicionais que atuavam no mercado da construção civil em Uberlândia, adquiriu os direitos de fabricação do ELU, que após sofrer pequenas modificações para atender às exigências da legislação que regia a construção das aeronaves UTL (Ultraleves), conseguiu o licenciamento e a autorização para a montagem da sua fábrica, a ASA INDÚSTRIA AERONÁUTICA LTDA.. Segundo Erick, a partir de 1988 foram desenvolvidos novos projetos de aeronaves que desde então são comercializados. Tais projetos são determinados pelos modelos agrícola e executivo. No modelo agrícola encontram-se os aviões Falcão AG-21 (Figura 1) e o Falcão AC-22 Treinador (Figura 2). Na linha executiva encontra-se o modelo Bumerangue EX-25 Cross Contry (Figura 3). Figura 1 Avião Falcão AG-21

13 13 Figura 2 Avião Falcão AC-22 Figura 3 Avião Bumerangue EX-25 Com o Bumerangue EX-25 Erick recebeu o prêmio de primeiro lugar no Projeto Inovador na categoria Aeronave Experimental. Durante a Expo Aero Brasil 2006, a maior feira de aviação geral da América Latina, o Bumerangue EX-25 recebeu o prêmio de Primeiro Lugar na Categoria Aeronave Experimental. (FABE, 2006). O prêmio foi concedido na Expo Aero Brasil de 2006 na cidade de Araras SP. Figura 4.

14 14 Figura 4 Prêmio de primeiro lugar na categoria Aeronave Experimental A necessidade de um sistema de gestão que controlasse o estoque e a produção surgiu com o crescimento da fábrica, pois na área de fabricação e desenvolvimento de aeronaves é de extrema importância um sistema que ofereça o controle total das atividades realizadas na empresa, e que garanta a qualidade e a confiabilidade do produto final Identificação do Problema A Fábrica Brasileira de Aeronaves é uma indústria de aviões situada na cidade de Uberlândia com foco na fabricação de aviões agrícolas e executivos. Atualmente a empresa não possui sistema informatizado para controle de estoque e produção de aeronaves. Todos os processos da empresa são executados manualmente, fato que acarreta informações distorcidas. Diante desse cenário foi proposto à FABE o desenvolvimento de um sistema capaz de possibilitar a gestão informatizada do controle de produção dos aviões e do estoque, além de oferecer rotinas informatizadas para controlar os testes dos aviões fabricados. A fábrica não trabalha com estocagem de grandes quantidades de um mesmo item. Muitas das peças utilizadas em seu processo de fabricação são fabricadas na própria FABE. A empresa trabalha somente com a quantidade necessária de peças para a produção dos aviões salvo, algumas exceções, as

15 15 relativas às peças que são comuns a todos os aviões, tais como parafusos, porcas e outras Objetivos do Trabalho Objetivo Geral Implementar um aplicativo com suporte a Web para gestão de produção e controle de estoque da Fábrica Brasileira de Aeronaves. Este trabalho tem por objetivo apresentar o que foi desenvolvido para a persisitência de dados no sistema FABE, os detalhes de análise e levantamento de requisitos podem ser encontrados na monograifa de Raquel Temporal e Érica Santos Objetivos Específicos Para que o objetivo geral seja alcançado, este trabalho apresenta os seguintes objetivos específicos: Implementar o aplicativo em três camadas; Implementar o sistema utilizando a linguagem de programação Java; Construir o diagrama de classes no nível de projeto; Utilizar Padrões de Projeto para as camadas; Utilizar o banco de dados MySQL; Utilizar o framework Hibernate para mapeamento objeto-relacional; Testar o sistema implementado. Dos objetivos supra citados, o enfoque deste trabalho está na utilização do banco de dados MySQL e o framework Hibernate Justificativa para a pesquisa A FABE é uma empresa nova, mas com grande tradição e respeito no

16 16 mercado de ultraleves. Com uma equipe técnica experiente e capacitada a empresa tem se destacado a cada dia, apresentando soluções inovadoras e perfeitamente adequadas à realidade brasileira. A falta de um software de gestão ocasiona processos muito lentos e desordem no almoxarifado, pois as etapas de produção ainda são realizadas manualmente. Com a proposta do projeto esse cenário será corrigido, aumentando consideravelmente o controle de qualidade da FABE. O projeto prevê a utilização da linguagem Java, de vários recursos tecnológicos como: hibernate, Struts, banco de dados, arquitetura MVC e a utilização dos seguintes padrões de projeto: Application Controller, Front Controller, Business Delegate, Command, DAO (Data Acess Object) e Business Object. Desta forma, o sistema a ser implementado, além de solucionar os problemas apontados, irá contribuir para o crescimento da qualidade na empresa Organização do trabalho O capítulo 2 apresenta a descrição do problema e as especificações dos requisitos. O capítulo 3 aborda a persistência de dados propriamente dita. É neste capítulo que encontra-se o enfoque deste trabalho. No capítulo 4 é apresentado o Mapeamento Objeto-relacional e como se implementou o Padrão de projeto DAO para o sistema FABE, ainda neste capítulo, propostas de melhorias à arquitetura utilizada na codificação da camada de persistência. Por fim, no Capítulo 5 são apresentadas as conclusões do trabalho e sugestões para melhoria do sistema.

17 17 2. ESPECIFICAÇÃO DO PROBLEMA A Fábrica Brasileira de Aeronaves, apesar de trabalhar com tecnologia avançada, não possui um sistema de gestão integrado. Diante desse fato foi proposto junto ao cliente o desenvolvimento de um software que atendesse suas necessidades imediatas. Inicialmente foram feitas reuniões com o responsável pela fábrica e levantadas algumas funcionalidades, as quais são realizadas manualmente e que necessitam ser automatizadas. A principal requisição da empresa foi desenvolver um sistema que controlasse o estoque das mercadorias em seu almoxarifado e que gerenciasse a produção de seus aviões. O controle do almoxarifado é realizado de acordo com a quantidade de peças que entram e saem do estoque, as quais não devem ultrapassar um limite mínimo e máximo, determinado pelo gerente da fábrica. Tanto a falta, quanto o excesso, afetam negativamente o capital da empresa. Também é feito um controle de armazenamento no almoxarifado, onde cada peça será localizada através de um endereço, que é determinado por sala, corredor, estante, prateleira, gaveta e área da gaveta. A partir do momento que uma nova peça chega à fábrica, é realizado um cadastro de acordo com seu endereçamento, quantidade e fornecedor. Já na retirada das peças deverá ser registrado o decréscimo no seu estoque. O gerenciamento da produção é iniciado com a etapa de transformação da matéria prima, ou seja, algumas peças que são utilizadas nesse processo são produzidas na própria fábrica. Esse processo é relacionado diretamente ao controle de estoque, pois ao mesmo tempo em que a matéria-prima utilizada será retirada do mesmo, uma nova peça será inserida. Além disso, é preciso que haja um controle do tempo gasto em cada etapa da produção, a quantidade de matéria-prima, o peso de cada peça (se está de acordo com o padrão) e todas as peças que foram ou não utilizadas. É preciso documentar tanto o processo de controle de estoque quanto o de produção, pois é importante para a fábrica armazenar informações relevantes em cada etapa. Essa documentação será utilizada caso ocorra alguma fatalidade, indicando possíveis pontos de falha e para rastrear os dados relacionados a essa vulnerabilidade. Assim esse processo facilitará na identificação do problema, e consequentemente, na tentativa de sua correção.

18 18 No processo de compra de peças um técnico analisa a etapa de produção com antecedência e faz uma requisição para seu superior de sessão das peças que serão utilizadas. A partir daí o responsável pelo almoxarifado, com base no estoque já existente, efetua a programação da compra destas peças. O almoxarife faz um processo de cotação com pelo menos três fornecedores com intuito de encontrar um melhor preço. Mesmo que a compra não seja efetuada a FABE deseja manter essas cotações arquivadas para servirem de referências futuras. No momento da entrega das peças é feita uma conferência. Caso uma ou mais peças estejam em desacordo com a nota fiscal de compra, que é o documento que formaliza essa operação, a fábrica emitirá uma nota fiscal de devolução dessas mercadorias para o fornecedor. O mesmo procedimento é realizado quando há peças defeituosas. A fábrica agrupa os fornecedores com base nas cotações. Eles são agrupados nas categorias A, B e C, que são ordenadas por prioridade de compra. Para a separação desses grupos é analisada a qualidade da matéria prima, o custo e a rapidez na entrega. As peças são identificadas por códigos, ou seja, um código que a empresa cria para o controle interno e outro, referente à fábrica que produziu a peça (código de fabricação). As peças estão divididas em grupos e conjuntos. Por exemplo, uma peça usada para construir o flap (uma estrutura da asa do avião), estará no conjunto flap e no grupo asa. Para o almoxarifado é necessária a informação do momento que a peça atingiu o limite mínimo e máximo no estoque. Também é necessário o controle de endereço (sala, corredor, estante, prateleira, gaveta e área da gaveta). Quando chegarem peças novas, as mesmas devem ser cadastradas junto com seu endereço e logo após, as mesmas devem ser guardadas no endereço referenciado. O sistema deverá ter um módulo de produção, o qual apresentará a capacidade de transformar uma peça em um avião produzido. O sistema controlará o tempo gasto em cada etapa da produção, a quantidade de matéria-prima utilizada nessas etapas, o peso de cada peça (se estão de acordo com o padrão) e todas as peças que foram ou não utilizadas.

19 19 A linha de produção do avião é desenvolvida por etapas, as quais possuem características específicas. A primeira etapa de produção tanto dos aviões agrícolas (falcão) quanto executivos (Bumerangue), é a fase do projeto. Nessa fase os aviões são construídos em um aplicativo CAD, que segundo a definição encontrada, computer-aided Design (CAD), ou desenho auxiliado por computador, é o nome genérido de sistemas computacionais (software) utilizados pela engenharia, geologia, arquitetura, e design para facilitar o projeto e desenho técnicos. No caso do design, este pode estar ligado especificamente a todas as suas vertentes ( produtos como vertuário, eletroeletrônicos, automobilísticos, ect), de modo que os jargões de cada especialidade são incorporados na interface de cada programa. (CAD, 2008). Passada a fase de projetos inicia-se a produção do avião. Essa etapa é separada por várias fases que serão detalhas abaixo. Na etapa de produção a fábrica já é capaz de analisar e fazer o controle de todas as peças que irá utilizar. São definidas quais peças serão produzidas pela FABE e quais devem ser compradas. Assim já estarão disponíveis as peças que irão integrar o avião, começando então, a montagem dos conjuntos das peças. Os técnicos montam os conjuntos formando-se os grupos. A partir daí o avião começa a ganhar forma, podendo ser iniciada a etapa de acoplamento dos grupos para terem forma definida. Cumprida essa fase o avião é passado por um teste de peso a fim de verificar sua capacidade. Com isso os acessórios são inseridos e os acabamentos são feitos (pintura e parte elétrica). Após a conclusão de todas as etapas citadas acima o avião passa por uma fase muito importante, a de testes. Nela, o piloto deverá ter em mãos uma planilha de testes. Através dessa planilha ele confere todos os aspectos do avião. Caso algum problema seja identificado, o mesmo deve ser reportado aos responsáveis a fim de que sejam feitas as devidas correções.

20 Especificação de Requisitos Requisitos funcionais Segundo (SOMMERVILLE, 2003, p. 83): Aeronaves. Requisitos funcionais são declarações de funções que o sistema deve fornecer, como o sitema deve reagir a entradas específicas e como deve se comporar em determinadas situações. Em alguns casos, os requisitos funcionais podem também explicitamente declarar o que o sistema não deve fazer. Abaixo, são listados os requisitos funcionais da Fábrica Brasileira de Controlar tempo gasto em cada etapa de produção; Consultar tempo de produção; Testar qualidade; Controlar estoque; Emitir relatórios; Cadastro de dados de compra; Efetuar login; Consultar funcionário; Manutenir funcionário; Controlar teste de vôo; Cadastrar fornecedor Requisitos não funcionais Segundo (SOMMERVILLE, 2003, p. 83), requisitos não funcionais são restrições sobre os serviços ou as funções oferecidos pelo sistema. Entre eles destacam-se restrições de tempo, restrições sobre o processo de desenvolvimento, padrões, entre outros.

21 21 Os requisitos não funcionais descrevem atributos do sistema, bem como atributos do ambiente do sistema. Abaixo, são listados os requisitos não funcionais da Fábrica Brasileira de Aeronaves. Implementar o sistema utilizando a linguagem de programação Java; Implementar o aplicativo em três camadas; Utilizar Padrões de Projeto para as camadas; Utilizar o banco de dados MySQL; Utilizar o framework Hibernate para mapeamento objeto-relacional. Os requisitos vistos neste capítulo foram levantados através de entrevistas com o cliente. A monograifa de Raquel Temporal e Érica Santos apresenta estes requisitos detalhadamente Regras de Negócio As regras de negócio descrevem as políticas, condições e restrições para realização dos processos do negócio. No software desenvolvido, inicialmente foi analisado uma Regra de Negócio. A partir de projetos futuros, outras regras serão analisadas de acordo com a necessidade do cliente. Segue a explicação da Regra de Negócio identificada. Login inválido Caso o usuario erre sua senha 03 vezes, seu login sera bloqueado pelo sistema. Gerencia de estoque Caso a quantiade em estoque de uma peça ou matéria prima esteja acima do máximo ou abaixo do mínimo, o sistema deve informar este fado ao usuário. Relatório de testes O sistema deve emitir relatórios que ofereçam a possibilidade de rastrear todo o processo de fabricação, caso ocorra uma eventualidade nos testes de vôo dos aviões.

22 22 3. PERSISTÊNCIA DE DADOS 3.1. Banco de Dados Ao longo do tempo as organizações, diante da necessidade de armazenar informações, buscaram novos meios para mantê-las e recuperá-las de forma mais econômica, eficiente e segura. Essa necessidade foi crescendo juntamente com a quantidade de informações a ser armazenada. Hoje, mais do que em qualquer momento anterior, o sucesso de uma organização está na habilidade de adquirir dados precisos e em tempo real sobre suas operações, em gerenciar esses dados eficientemente e usá-los para analisar e guiar suas atividades. (RAMAKRISHNAN; GEHRKE, 2003, p. 3, tradução nossa) Semelhante a muitas tecnologias, os fundamentos de bancos de dados surgiram da necessidade das empresas. Neste caso, ter uma forma mais econômica de armazenar e organizar dados era o objetivo em questão. Por este motivo, eram válidos os esforços e investimentos em pesquisas para encontrar um meio menos dispendioso que fosse mais eficiente em armazenar e recuperar dados. Foi então durante as décadas de 1960 e 1970 que a empresa IBM deu os primeiros passos com as pesquisas de funções de automação de escritório. Durante este período muitas pesquisas foram desenvolvidas e contribuíram para o surgimento de vários modelos de dados como, o modelo hierárquico, de rede e relacional. Apesar de ser a inventora do conceito original de banco de dados e do padrão SQL, não foi a IBM que produziu o primeiro sistema comercial de banco de dados. O feito foi da Honeywell Information Systems Inc que realizou a façanha em junho de Mesmo sendo implementado fora da IBM, o sistema foi baseado em muitos princípios que ela concebeu. Durante a década de 1980, o software de banco de dados relacionais foi sendo refinado. Isso se deu devido à grande demanda dos usuários, ao desenvolvimento de sistemas para empresas e ao aumento da quantidade de computadores pessoais e sistemas distribuídos. Desde o surgimento dos bancos de dados a quantidade de dados a ser armazenada aumentou muito, por este motivo a capacidade de armazenamento teve que atender a essa necessidade. Posteriormente o padrão SQL passou da IBM para a ANSI e para a

23 23 ISO, os quais formaram um grupo de trabalho para continuar o desenvolvimento, que segue nas novas versões dos padrões definidos SGBD O primeiro SGBD (Sistema de Gerenciamento de Banco de Dados), assim como o banco de dados, foi desenvolvido durante a década de 1960, momento na história humana em que projetos de grande escala eram contemplados, planejados e arquitetados. Até então não havia-se trabalhado com grandes volumes de dados com a nova tecnologia de persistência, com isso, problemas eram identificados com frequência e precocemente, soluções eram propostas e desenvolvidas na maioria das vezes em tempo real. Nos primórdios da computação, uma base de dados geralmente era constituída de um único arquivo, que era dividido em blocos de dados, que por sua vez era constituído de registros e campos dentro dos registros. (HENDERSON, 2009, p 131, tradução nossa) O SGBD tornou-se imprescindível, não se podia gerenciar a crescente quantidade de dados da forma que se havia planejado, além do fator limitante do custo associado com suporte ao armazenamento de dados, somado a isso a necessidade que as transações fossem gerenciadas de forma a garantir um nível maior de detalhe e segurança. Para entender a necessidade de um SGBD, vamos considerar um motivante cenário: Uma companhia tem uma grande coleção (diga-se de 500 Gigabytes) de dados de funcionários, departamentos, produtos, vendas e outros. Esses dados são acessados simultaneamente por diversos funcionários. Questões sobre dados precisam ser respondidas rapidamente, mudanças feitas em um dado por diferentes usuários precisam ser aplicadas consistentemente e o acesso a centenas de partes de dados, a exemplo salários, precisa ser restrito. (RAMAKRISHNAN; GEHRKE, 2003, p. 7, tradução nossa) Como de costume, a IBM liderava o mercado de desenvolvimento, mas havia um crescente número de concorrentes que ofereciam uma grande variedade de soluções para persistência de dados. Os SGBDs evoluíram incorporando mais recursos, aumentando sua capacidade de gerenciamento das

24 24 transações, bem como permitindo maior facilidade para correções ou remodelagem das bases de dados que gerenciavam. Na Figura 5 tem-se uma ilustração da estrutura genérica de um SGBD. Nela nota-se que toda interação, seja dos usuários de aplicativos ou programadores e sistemas é realizada utilizando-se o SGBD. Os componentes funcionais do sistema de bando de dados podem ser divididos pelos componentes de processamento de consultas e pelos componentes de administração de memória. Segundo Silberschatz; Korth; Sundarshan (1999), um sistema gerenciador de banco de dados (SGBD) é uma coleção de dados inter-relacionados e uma coleção de programas para acesso a estes dados. Figura 5 Arquitetura SGBD Fonte: Como pode-se notar, para o gerenciamento de uma base de dados de maneira consistente, torna-se indispensável a utilização de um SGBD. Existem diversas alternativas no mercado, como exemplo pode-se citar: Oracle, Firebird, PostgreSQL, Sybase entre outras. Visando o uso acadêmico e por se tratar de uma

25 25 tecnologia Open Source que tem grande aceitação no mercado, uma ampla documentação, estabilidade, desempenho e portabilidade, o MySQL apresentou-se como uma excelente alternativa para o desenvolvimento do sistema da FABE Modelagem de Banco de Dados Fundamental para a estrutura de um banco de dados é o conceito de modelo de dados utilizado para sua modelagem, uma coleção de ferramentas conceituais para descrição de dados, relacionamentos de dados, semântica de dados e restrições de consistência. Para a modelagem e criação de bases de dados de sistemas de computador utiliza-se de diversas técnicas e ferramentas. Estas têm por objetivo propiciar a modelagem da base de dados de modo que ela ofereça melhor desempenho, menor redundância e facilite a sua manutenção e ou sua posterior ampliação. Para o desenvolvimento do sistema FABE foram realizadas reuniões com o responsável pela empresa com o objetivo de coletar informações sobre as regras de negócio e requisitos dos usuários, atividade esta de extrema importância para o desenvolvimento de um sistema. Após a atividade de levantamento de requisitos elaborou-se o DER, um modelo de dados que descreve as tabelas da base de dados e seus relacionamentos. Os modelos desenvolvidos atualmente são classificados em três diferentes grupos: modelos lógicos com base em objetos, modelos lógicos com base em registros e modelos físicos. O modelo entidade-relacionamento que faz parte do grupo de modelos lógicos com base em objetos, por dispor de recursos de estruturação mais flexíveis e por viabilizar a especificação explícita das restrições dos dados, demonstrou-se uma ótima escolha para modelar a base de dados do sistema FABE. Este modelo de dados tem por base a percepção do mundo real como um conjunto de objetos básicos denominados entidades e seus relacionamentos. Uma entidade nada mais é do que a representação de um objeto do mundo real. Por exemplo, uma pessoa é uma entidade, uma conta em um banco também pode ser considerada uma entidade. As entidades são descritas no banco de dados por meio de seus atributos. Os atributos definem o conjunto de propriedades que representam a entidade. Entre as entidades existem

26 26 relacionamentos, e é através dos relacionamentos que são realizadas as consultas na base de dados. Na Figura 6, tem-se o DER que modela a base de dados do sistema FABE exibindo todas as entidades e seus atributos que devem ser persistidos. Figura 6 DER Sistema FABE

27 27 Todas as entidades apresentadas na Figura 6 foram modeladas conforme levantamento de requisitos realizado com responsável pela empresa. A seguir, a descrição de cada tabela utilizada pelo sistema FABE. PECA Esta entidade tem por finalidade armazenar e persistir as informações das peças em estoque. Ela armazena as seguintes informações: nome da peça, peso bruto, peso líquido, custo, endereço de armazenamento, quantidade mínima e quantidade máxima permitida em estoque. Para facilitar a busca por uma peça na base de dados, foi criado o índice PEC_ID, contendo o código da peça e o PEC_NOME, contendo o nome da peça. AVIAO Entidade que persiste os dados referentes a aviões, estejam em produção, em testes ou armazenados. Tabela usada para armazenar as seguintes informações: nome e tipo de avião. Por se tratar de uma tabela de apenas dois registros (avião agrícola e executivo), não houve necessidade de se criar um índice para a mesma. ETAPA_PECA tabela de associação, ou seja, originária da associação entre as tabelas: PECAS e ETAPA_PRODUCAO. Por permitir que um registro da tabela PECA possua informações coincidentes na tabela ETAPA_PRODUCAO e um registro da tabela ETAPA_PRODUCAO possua informações coincidentes na tabela PECA, o relacionamento das duas só é possível através de uma terceira tabela, no caso ETAPA_PECA. ETAPA_PRODUCAO tabela que contém os seguintes dados: tempo inicial e tempo final de uma etapa de produção. Seu índice EP_ID referencia o campo com o código da etapa de produção, tornando o acesso aos dados dessa tabela mais rápido. GRUPO tabela usada para armazenar o nome do grupo de uma peça. Seu índice GRU_ID contém o código do grupo que faz parte da chave primária da tabela. CONJUNTO tabela usada para armazenar o nome do conjunto ao qual uma peça pertence. Seu índice CON_ID contém o código do conjunto e é usado para facilitar a busca de dados na tabela referenciada. CIDADE essa tabela contém os seguintes dados: nome, estado e DDD de uma cidade. Foi criada para facilitar o cadastro de fornecedores e

28 28 funcionários, além de diminuir a redundância na base de dados. Possui como índice o campo contendo o código da cidade, referenciado por CID_ID. BAIRRO tabela usada para minimizar redundâncias de informações no banco de dados. Seu índice contém o código do bairro BAI_ID. LOGRADOURO tabela que contém o nome e o tipo de um logradouro. É usada para diminuir a redundância na base de dados, assim como outras tabelas do sistema. Possui como índice sua chave primária, representada pelo campo LOG_ID. CEP essa tabela contém o número do CEP de uma rua e possui como índice o campo CEP_ID, chave primária da tabela. FABRICA tabela usada para armazenar as seguintes informações: CNPJ e número da inscrição da empresa. Seu índice é formado por sua chave primária, referenciada no campo FAB_ID. PESSOA tabela usada para armazenar as seguintes informações: nome, telefone, e CEP. Foi criada para diminuir as redundâncias da base de dados. Seu índice é formado pelo campo PES_ID que contém o código da pessoa. FUNCIONARIO essa tabela persiste as informações dos funcionários da FABE. Seus principais campos são: nome, cargo, matrícula e CPF. Possui como índice o campo FUN_ID que contém o código do funcionário - chave primária da tabela. FORNECEDOR tabela usada para armazenar as informações dos fornecedores da fábrica. Seus principais campos são: CNPJ, nome, telefone e endereço. Seu índice FOR_ID possui o código do fornecedor, definido como chave primária da tabela. COMPRA tabela que contém a data de compra e de entrega de um produto, bem como o valor pago pelo mesmo e o número de sua nota fiscal. Por se tratar de uma tabela com grande volume de dados, foi criado o índice COM_ID referenciando a chave primária da tabela. COMRA_ITEM tabela de associação, ou seja, originária da associação dos registros encontrados nas tabelas de COMPRA e PECAS. Possui o campo CI_ID como chave primária e índice. TESTE tabela usada para armazenar informações referentes aos