HUGO KAZUYA YOSHIDA. Aprovada em 05 de Julho de COMISSÃO EXAMINADORA

Tamanho: px
Começar a partir da página:

Download "HUGO KAZUYA YOSHIDA. Aprovada em 05 de Julho de 2013. COMISSÃO EXAMINADORA"

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO UNIVERSITÁRIO NORTE DO ESPÍRITO SANTO DEPARTAMENTO DE ENGENHARIAS E TECNOLOGIA CURSO DE ENGENHARIA DE PRODUÇÃO HUGO KAZUYA YOSHIDA INTEGRAÇÃO DO MÉTODO FMEA COM UM BANCO DE DADOS PARA A MELHORIA CONTÍNUA APLICADO AO PROJETO DE AUTOMAÇÃO DO TESTE FÍSICO DE PELOTAS DE MINÉRIO DE FERRO DA EMPRESA DO SETOR DE MINERAÇÃO SÃO MATEUS 2013

2 HUGO KAZUYA YOSHIDA INTEGRAÇÃO DO MÉTODO FMEA COM UM BANCO DE DADOS PARA A MELHORIA CONTÍNUA APLICADO AO PROJETO DE AUTOMAÇÃO DO TESTE FÍSICO DE PELOTAS DE MINÉRIO DE FERRO DA EMPRESA DO SETOR DE MINERAÇÃO Trabalho de Conclusão de Curso apresentado ao Departamento de Engenharias e Tecnologia da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do grau de Bacharel em Engenharia de Produção. Orientador: Prof. Thiago Padovani Xavier SÃO MATEUS 2013

3 HUGO KAZUYA YOSHIDA INTEGRAÇÃO DO MÉTODO FMEA COM UM BANCO DE DADOS PARA A MELHORIA CONTÍNUA APLICADO AO PROJETO DE AUTOMAÇÃO DO TESTE FÍSICO DE PELOTAS DE MINÉRIO DE FERRO DA EMPRESA DO SETOR DE MINERAÇÃO Trabalho de Conclusão de Curso apresentado ao Departamento de Engenharias e Tecnologia da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do grau de Bacharel em Engenharia de Produção. Aprovada em 05 de Julho de COMISSÃO EXAMINADORA Prof. Thiago Padovani Xavier Universidade Federal do Espírito Santo Orientador Profª. Gisele de Lorena Diniz Chaves Universidade Federal do Espírito Santo Profª. Karina Pedrini Fraga Universidade Federal do Espírito Santo

4 Melhor ter gerentes com qualidade do que gerentes da qualidade Kaoru Ishikawa

5 AGRADECIMENTOS Agradeço primeiramente ao professor Dr. Marcos Aurélio Scopel Simões pela aceitação do desenvolvimento deste trabalho em seu projeto de automação e por apoiar no desenvolvimento do mesmo. Agradeço ao professor orientador Thiago Padovani Xavier no apoio do desenvolvimento deste trabalho, aos engenheiros Daniel Scopel Paviotti e José Fernando Fernandes Carvalho por ajudar nas informações necessárias para o desenvolvimento do mesmo e ao engenheiro Akira Yoshida por apoiar na elaboração do Banco de Dados e do relatório. Agradeço também aos demais professores, principalmente os da banca examinadora e aos amigos que em tantos momentos de alegria e dificuldades compartilharam conosco no decorrer de todo o curso de graduação em Engenharia de Produção. Obrigado.

6 RESUMO Observa-se que a qualidade se tornou um dos principais fatores na decisão dos consumidores, fazendo com que o mercado fique cada vez mais exigente. Isto faz com que ocorra uma necessidade crescente de investimento em qualidade. Tal qualidade, que deverá estar presente tanto em produtos quanto em processos, poderá fazer com que ocorra uma redução significativa dos custos. Com isso, para adquirir o sucesso, nota-se que há uma grande importância na pesquisa e no desenvolvimento da qualidade. Tendo em vista esta necessidade constante de aperfeiçoamento do produto, serviço e processo produtivo para a manutenção do sucesso, destaca-se a importância da utilização de técnicas e ferramentas dedicadas à melhoria contínua. Para isso, foi realizada neste trabalho a integração do método FMEA (Failure Mode and Effect Analysis) com um Banco de Dados (BD), onde, tal método foi aplicado no processo de instalação dos equipamentos desenvolvidos por um projeto de automação em uma empresa do setor de mineração. Após a utilização desta ferramenta integrada, observou-se uma otimização no método, ou seja, foi possível observar e avaliar, de forma sistemática e contínua, os impactos das ações de melhoria, nas falhas potenciais dos processos estudados, através de índices pré-definidos da metodologia. Palavras-chave: Método FMEA. Banco de Dados. Falha Potencial.

7 ABSTRACT It is observed that the quality has become one of the main factors in the decision of consumers, making the market each time more demanding. This makes it occurs a growing investment in quality. This quality, which should present in its products and in its processes, can cause a significant reduction of costs. With this, it is observed the large importance of investing in quality to the success. Given this need for constant improvement of product, service and production process to maintain the success, stands out the importance of using tools and techniques dedicated to continuous improvement. For this, it was performed in this work the integration of FMEA (Failure Mode and Effect Analysis) with a database (DB), where this method was applied in the process of installation of equipment developed by an automation project in a mining company. After use of this integrated tool, it was observed an optimization on the method, in other words, it was possible to observe and evaluate, systematically and continuously, the impact of improvement actions, in the potential failures of the processes studied, through predefined indexes methodology. Keywords: FMEA Method. Database. Potential Failures.

8 LISTA DE FIGURA FIGURA SISTEMA DE BANCO DE DADOS FIGURA EXEMPLO DE TABELAS DO MODELO RELACIONAL CLIENTE - CONTA CORRENTE.. 26 FIGURA DESCRIÇÃO DE UMA TABELA FIGURA EXEMPLO DE TABELA DE DEPENDENTES FIGURA EXEMPLO DE TABELAS DE DEPARTAMENTOS E EMPREGADOS FIGURA EXEMPLO DE TABELA DE EMPREGADOS COM CHAVE ESTRANGEIRA FIGURA EXEMPLO DE TABELA DE EMPREGADOS COM CHAVE ALTERNATIVA FIGURA EXEMPLOS DE RELACIONAMENTOS 1: FIGURA EXEMPLOS DE RELACIONAMENTOS 1:N FIGURA EXEMPLOS DE RELACIONAMENTOS N:N FIGURA EXEMPLO DE RELACIONAMENTO TERNÁRIO FIGURA PASSOS DE TRANSFORMAÇÃO DA NORMATIZAÇÃO FIGURA ÍNDICE PRINCIPAL DO APLICATIVO FIGURA ÍNDICE DA TABELA FMEA FIGURA FORMULÁRIO GERENCIAR PROCESSO FIGURA FORMULÁRIO ADICIONAR PROCESSO FIGURA FORMULÁRIO SUBPROCESSO FIGURA FORMULÁRIO ADICIONAR RESPONSÁVEL FIGURA FORMULÁRIO FALHA POTENCIAL FIGURA FORMULÁRIO EFEITO FIGURA FORMULÁRIO CAUSA FIGURA FORMULÁRIO CONTROLE ATUAL FIGURA FORMULÁRIO ÍNDICES FIGURA DETALHAMENTO DA SEVERIDADE FIGURA DETALHAMENTO DA OCORRÊNCIA FIGURA DETALHAMENTO DA DETECÇÃO FIGURA FORMULÁRIO AÇÃO RECOMENDADA FIGURA FORMULÁRIO MEDIDA IMPLANTADA FIGURA FORMULÁRIO TAREFA FIGURA FORMULÁRIO ÍNDICES ATUAIS FIGURA ÍNDICE PESQUISA... 63

9 II FIGURA FORMULÁRIO GERENCIAR RESPONSÁVEL FIGURA RELATÓRIO DE PROCESSOS NÃO INICIADOS FIGURA RELATÓRIO DE SUBPROCESSOS NÃO INICIADOS FIGURA RELATÓRIO DE MEDIDAS IMPLANTADAS NÃO INICIADAS FIGURA RELATÓRIO DE TAREFAS NÃO INICIADAS FIGURA RELATÓRIO DE SUBPROCESSOS SOB A RESPONSABILIDADE DO FRANCISCO FIGURA RELATÓRIO DE TAREFAS SOB A RESPONSABILIDADE DO MÁRCIO LUIZ FIGURA RELATÓRIO DE NÍVEL DE RISCO DA FALHA POTENCIAL FIGURA RELATÓRIO DE NÍVEL DE RISCO APÓS A MEDIDA IMPLANTADA FIGURA RELATÓRIO DOS RESPONSÁVEIS FIGURA GRÁFICO DE PARETO 80/

10 LISTA DE TABELA TABELA EXEMPLOS DE DOCUMENTOS PARA A ANÁLISE FMEA TABELA EXEMPLO DE ÍNDICE PARA SEVERIDADE TABELA EXEMPLO DE ÍNDICE PARA OCORRÊNCIA TABELA EXEMPLO DE ÍNDICE PARA DETECÇÃO TABELA SEVERIDADE NO PROCESSO DE IMPLANTAÇÃO TABELA OCORRÊNCIA NO PROCESSO DE IMPLANTAÇÃO TABELA DETECÇÃO NO PROCESSO DE IMPLANTAÇÃO TABELA NÚMERO DE PRIORIDADE DE RISCO TABELA AÇÕES RECOMENDADAS TABELA TAREFAS TABELA NOVOS NPR... 78

11 LISTA DE SIGLAS 1FN Primeira Forma Normal 2NF Segunda Forma Normal 3NF Terceira Forma Normal ANFAVEA Associação Nacional dos Fabricantes de Veículos Automotores BD Banco de Dados Cpk Índice de Capacidade DBA Administrador de Banco de Dados DER Diagrama Entidade-Relacionamento EPI Equipamento de Proteção Individual ER Entidade-Relacionamento FMEA Failure Mode and Effect Analysis HACCP Hazard Analysis and Critical Control Points NPR Número de Prioridade de Risco OEE Overall Equipment Effectiveness PDF Portable Document Format SGBD Sistema Gerenciador de Banco de Dados

12 SUMÁRIO 1. INTRODUÇÃO JUSTIFICATIVA OBJETIVOS OBJETIVO GERAL OBJETIVOS ESPECÍFICOS FUNDAMENTAÇÃO TEÓRICA FMEA PLANEJAMENTO ANÁLISE DE FALHAS EM POTENCIAL AVALIAÇÃO DOS RISCOS MELHORIA CONTINUIDADE BANCO DE DADOS MODELO RELACIONAL TABELAS CHAVES CHAVE PRIMÁRIA CHAVE ESTRANGEIRA CHAVE ALTERNATIVA RELACIONAMENTOS NORMATIZAÇÃO PRIMEIRA FORMA NORMAL (1FN) SEGUNDA FORMA NORMAL (2FN) TERCEIRA FORMA NORMAL (3FN) METODOLOGIA DESENVOLVIMENTO A ESTRUTURA DO FMEA A INTEGRAÇÃO DO MÉTODO COM O BANCO DE DADOS CRIAÇÃO DE TABELAS E RELACIONAMENTOS DESENVOLVIMENTO DE FORMULÁRIOS E RELATÓRIOS CRIAÇÃO DE MACROS... 47

13 II 5.3. O APLICATIVO ÍNDICE DA TABELA FMEA FORMULÁRIO PROCESSO FORMULÁRIO SUBPROCESSO FORMULÁRIO FALHA POTENCIAL FORMULÁRIO EFEITO FORMULÁRIO CAUSA FORMULÁRIO CONTROLE ATUAL FORMULÁRIO ÍNDICES FORMULÁRIO AÇÃO RECOMENDADA FORMULÁRIO MEDIDA IMPLANTADA FORMULÁRIO TAREFA FORMULÁRIO ÍNDICES ATUAIS ÍNDICE PESQUISA RELATÓRIO DE PROCESSOS RELATÓRIO DE SUBPROCESSOS RELATÓRIO DE MEDIDAS IMPLANTADAS RELATÓRIO DE TAREFAS RELATÓRIO DE RESPONSÁVEIS DOS SUBPROCESSOS RELATÓRIO DE RESPONSÁVEIS DAS TAREFAS RELATÓRIO DE NÍVEIS CRÍTICOS RELATÓRIO DE NÍVEIS CRÍTICOS APÓS A MEDIDA IMPLANTADA RELATÓRIO DE DADOS DOS RESPONSÁVEIS RESULTADOS CONCLUSÕES SUGESTÕES PARA TRABALHOS FUTUROS REFERÊNCIAS ANEXO A - FORMULÁRIO FMEA ANEXO B - FORMULÁRIO FMEA COM DEFINIÇÕES E FLUXOGRAMA ANEXO C - CRONOGRAMA DE INSTALAÇÃO APÊNDICE A - TABELA FMEA APÊNDICE B - ESTRUTURA DO BANCO DE DADOS APÊNDICE C - NÍVEL DE RISCO APÊNDICE D - NÍVEL DE RISCO (APÓS ADOTAR MEDIDAS)... 92

14 13 1. INTRODUÇÃO O controle da qualidade, ao ser implantado em um projeto, tem o objetivo reduzir a variabilidade dos produtos e/ou processos. Consequentemente é observada que a carência de qualidade pode fazer com que ocorram grandes desperdícios e ineficiência no processo de produção. A utilização do método FMEA (Failure Mode and Effect Analysis) é uma forma de aprimorar a qualidade dos produtos e processos de qualquer tipo de setor empresarial. Tal método é aplicado quando necessita de: Diminuir os riscos de erros e aumentar a qualidade em procedimentos administrativos; Diminuir a probabilidade da ocorrência de falhas em projetos de novos produtos; Diminuir a probabilidade de falhas potenciais (ou seja, que ainda não tenham ocorrido) em produtos ou processos já em operação; Aumentar a confiabilidade de produtos ou processos já em operação por meio da análise das falhas que já ocorreram. A metodologia FMEA proporciona uma forma sistemática de se catalogar informações sobre as falhas dos produtos e processos, facilitando o conhecimento dos problemas e gerando a oportunidade de ações de melhoria no projeto do produto e/ou processo, baseando-se, para tanto, em dados. Dessa forma, aplicando esta metodologia, é possível reduzir os custos de produção, eliminando as causas de falha do processo e melhorando a qualidade do produto, uma vez que a aplicação do FMEA do produto tende a eliminar as potenciais falhas do produto, tornando-o mais atrativo aos clientes. Para Stamatis (2003) e Palady (1997), a utilização desta metodologia tem as seguintes vantagens: Melhoria na qualidade, segurança e confiabilidade de produtos e/ou serviços; Contribuição para a melhoria na imagem e competitividade da empresa frente aos seus clientes; Auxílio na identificação de redundâncias no processo de prestação de serviços e/ou na elaboração do produto; Diminuição do tempo e custo do desenvolvimento do produto e/ou processo;

15 14 Identificação dos procedimentos desenvolvidos, elaboração dos diagnósticos de falhas, levantamento das ações corretivas, prevenção das falhas e priorização das ações corretivas; Redução dos riscos e das falhas; Maior satisfação dos clientes. Os Bancos de Dados (BD) são utilizados para armazenar, manipular e recuperar dados na estrutura de tabelas. Ou seja, eles facilitam aos acessos dos dados, providenciando que os usuários utilizem uma grande variedade de abordagens no tratamento de informações. Para isso, utiliza-se um Sistema Gerenciador de Banco de Dados (SGBD), que seria um software com finalidade de facilitar na gestão desses bancos de dados. Segundo Canedo (2012), as vantagens na abordagem deste sistema são: Gerenciar grandes volumes de dados; Facilitar a eliminação de redundância e inconsistência de dados; Facilitar o armazenamento e acesso aos dados; Garantir o acesso a vários usuários ao mesmo tempo; Garantir a segurança dos dados (por exemplo: garantir a recuperação dos dados caso haja danificação do meio onde estão armazenados; garantir segurança de acesso); Garantir a integridade dos dados. Portanto, propõe-se neste trabalho a utilização do método FMEA, integrada a um SGBD, visando à construção de um método otimizado de melhoria contínua de produtos e processos. Assim, para a verificação da viabilidade deste método otimizado, essa integração de ferramentas foi aplicada ao processo de montagem dos equipamentos desenvolvidos em um projeto de automação, onde, tal projeto consiste no desenvolvimento de equipamentos automatizados para a realização dos testes físicos de pelotas de minério de ferro em uma empresa do setor de mineração JUSTIFICATIVA O método FMEA, já consolidada teoricamente, é utilizado para identificar e estudar as falhas atuais e potenciais, com isso, definindo ações que visem reduzir ou eliminar os riscos

16 15 associados a cada falha. Abaixo são citados alguns exemplos de trabalhos que fazem aplicações deste método: Scipioni e outros (2002) fazem a aplicação do método FMEA integrada a um sistema de HACCP (Hazard Analysis and Critical Control Points) em uma empresa de alimentos. Tal integração tem por objetivo à otimização do método FMEA para estes setores empresariais. Onde, utiliza-se o sistema de HACCP que se baseia em analisar as diversas etapas da produção de alimentos, analisando os perigos potenciais à saúde dos consumidores, determinando medidas preventivas para controlar esses perigos através de pontos críticos de controle. Xu e outros (2002) aplicam o método FMEA em um motor diesel com turbo. Com a finalidade de adquirir resultados mais reais e flexíveis do método, os autores fazem a utilização de uma lógica, fuzzy logic, para uma avaliação mais precisa das severidades, ocorrências e detecção nas falhas potenciais. Ahire e Relkar (2012) aplicam dois métodos, FMEA e a Eficiência Global de Equipamentos (Overall Equipment Effectiveness - OEE), em um sistema. Após isso, os autores fazem a correlação entre a Severidade, Ocorrência e Detecção do método FMEA com a Disponibilidade, Performance e Qualidade do método OEE. Rosa e Garrafa (2009) fazem a aplicação do método FMEA no subprocesso de colheita de canola. Ou seja, a análise teve como foco a produção primária da canola, cujo processo foi dividido nos subprocessos: escolha da área e insumos, sistematização da área de cultivo, semeadura, tratos culturais e colheita. Após este estudo, a abordagem usada demonstrou a viabilidade do uso da técnica FMEA na determinação de ações preventivas para aperfeiçoar processos de cultivo agrícola. O BD é uma ferramenta utilizada para o controle de operações empresariais, ou seja, é uma maneira de armazenar, manipular e recuperar dados estruturados na forma de tabelas. Logo, a integração do método FMEA com esta ferramenta tem como um dos principais objetivos a otimização do método de resolução de problemas e solução de falhas potenciais. Dessa forma, o BD permite um estudo mais organizado dos aspectos estudados pelo FMEA (modo, causa e

17 16 efeito de falha). Com isso, para averiguar esta questão a pergunta para essa pesquisa deverá ser: Como otimizar um método, já consolidado teoricamente, integrando-o com um banco de dados?

18 17 2. OBJETIVOS 2.1. OBJETIVO GERAL Integrar o método FMEA com um Banco de Dados, visando à otimização deste método, aplicando-o no processo de montagem dos equipamentos desenvolvidos em um projeto de automação OBJETIVOS ESPECÍFICOS Analisar teoricamente a correspondência entre o método FMEA e o banco de dados; Avaliar a execução do banco de dados desenvolvido para a aplicação do método FMEA nos processos de montagem dos equipamentos desenvolvidos pelo projeto de automação; Propor ações para a redução de falhas encontradas no banco de dados; Avaliar as ações recomendadas adicionados no banco de dados.

19 18 3. FUNDAMENTAÇÃO TEÓRICA 3.1. FMEA A análise FMEA (Failure Mode and Effect Analysis), segundo Toledo e Amaral (2011), [...] é uma metodologia que objetiva avaliar e minimizar riscos por meio da análise das possíveis falhas (determinação da causa, efeito e risco de cada tipo de falha) e implantação de ações para aumentar a confiabilidade. Para Capaldo e outros (1999, p. 1), o método FMEA [...] é uma ferramenta que busca, em princípio, evitar, por meio da análise das falhas potenciais e de propostas de ações de melhoria, que ocorram falhas no projeto do produto ou do processo. O objetivo básico desta técnica é detectar possível falha antes que se produza o produto. Com isso, ocasionando uma redução do processo ou produto falhar, ou seja, aumentando a sua confiabilidade. A Associação Nacional dos Fabricantes de Veículos Automotores (COMISSÃO PARA ASSUNTOS DA QUALIDADE DA ANFAVEA, 1997) destaca que o método FMEA possui os seguintes objetivos: reconhecer e avaliar a falha potencial de um produto e/ou processo e seus efeitos; identificar ações que podem eliminar ou reduzir a chance do modo de falha potencial vir a ocorrer; documentar o processo de análise, funcionando em um processo de sete passos, como aponta Slack e outros (1996): 1. Identificar todas as partes componentes dos serviços; 2. Listar todas as formas possíveis segundo as quais os componentes poderiam falhar (os modos de falhas); 3. Identificar os efeitos possíveis das falhas (tempo parado, insegurança, necessidade de ajustes e/ou consertos, efeitos para os clientes); 4. Identificar todas as causas possíveis das falhas para cada modo de falha; 5. Avaliar a probabilidade de falha, a severidade dos efeitos da falha e a probabilidade de detecção; 6. Identificar o número de prioridade de risco (NPR); 7. Desenvolver e implementar ações para minimizar as falhas identificadas.

20 19 Desta forma, o FMEA funciona seguindo os sete passos indicados por Slack e outros (1996) juntamente com o planejamento do trabalho, descrevendo os objetivos e abrangência da análise, a formação dos grupos de trabalho, o planejamento das reuniões e da preparação da documentação, como será descrito nas próximas seções. Para Stamatis (2003), o método FMEA pode ser classificado em FMEA de Sistema, de Processo e de Produto. Visto que a maneira de aplicar a técnica é a mesma, diferenciando-se somente quanto ao objetivo. O FMEA de Sistemas é utilizado para avaliar as falhas em sistemas nos estágios iniciais da conceituação e do projeto. Tem por objetivo enfocar as falhas do sistema em relação às suas funcionalidades e no atendimento das expectativas dos clientes. Para a aplicação deste sistema, são consideradas as falhas potenciais de cada etapa do processo com o objetivo de diminuir os riscos de falha (STAMATIS, 2003). O FMEA de Processo enfoca as falhas do processo em relação à concretização dos seus objetivos pré-definidos e está ligado à capacidade do processo em cumpri-los, ou seja, é utilizado para avaliar as falhas em processos antes do início de sua produção. Contudo, é nesta metodologia onde se define as necessidades de alterações no processo, estabelece prioridades para as ações de melhoria, auxilia na execução do plano de controle do processo e na análise dos processos de manufatura e montagem (PALMIERI et al., 2008, p. 3). Ainda, o Instituto da Qualidade Automotiva (2001) destaca que o FMEA de Processo pode ser definido como o resumo dos pensamentos da equipe durante o desenvolvimento de um processo e inclui a análise de itens que poderiam falhar baseado na experiência de problemas anteriores. Esta abordagem sistemática acompanha, formaliza e documenta a linha de pensamento normalmente percorrida durante o planejamento da manufatura. O FMEA de Produto enfoca as falhas do projeto em relação à concretização dos seus objetivos pré-definidos para cada uma de suas características e está ligado à capacidade do projeto em atender tais objetivos, ou seja, é utilizado para avaliar possíveis falhas no projeto do produto antes do início de sua produção. Contudo, é nesta metodologia onde se definem as necessidades de alterações no projeto do produto, estabelece prioridades para as ações de melhoria, auxilia na definição de testes e validação do produto, na identificação de

21 20 características críticas e na avaliação dos requisitos e alternativas do projeto (PALMIERI et al., 2008, p. 4). Simplificando a metodologia, pode-se classificar basicamente entre FMEA de Processo e FMEA de Produto, onde: A de Processo estuda as falhas que poderão ocorrer durante algum processo, ou seja, ela analisa como tal processo pode falhar considerando os possíveis efeitos desta falha no processo e as causas geradoras de tal falha. A de Produto estuda as falhas que poderão ocorrer com o produto, ou seja, ela analisa como tal produto possa falhar considerando os possíveis efeitos que elas geram e as causas motivadoras de tal falha. Segundo Toledo e Amaral (2011), o processo de aplicação do FMEA pode ser dividia em: planejamento; análise de falhas em potencial; avaliação dos riscos; melhoria; e continuidade. Tais divisões serão explicadas nas próximas seções PLANEJAMENTO A fase de planejamento é onde realiza o desenvolvimento do formulário FMEA. Capaldo e outros (1999, p. 1) consideram que esta fase é realizada pelo responsável da aplicação desta metodologia e compreende: Descrição dos objetivos e abrangência da análise: identificações de quais produtos ou processos serão analisadas; Formação dos grupos de trabalho: definição dos integrantes do grupo, que deve ser preferencialmente pequeno (entre 4 a 6 pessoas) e multidisciplinar (contando com pessoas de diversas áreas como qualidade, desenvolvimento e produção); Planejamento das reuniões: as reuniões devem ser agendadas com antecedência e com o consentimento de todos os participantes para evitar paralisações; Preparação da documentação: a Tabela 3.1 mostram alguns exemplos de tipos de documentação.

22 21 Tabela Exemplos de documentos para a análise FMEA FMEA de Produto Lista de peças; Desenhos; Resultados de ensaios; FMEA de produtos similares; FMEA já realizados para o produto. FMEA de Processo Lista de peças; FMEA de produto da peça; Desenhos de fabricação; Planos de inspeção; Estatística de falhas do processo; Estatística de falhas do produto; Estudos de capacidade de máquina. Fonte: Toledo e Amaral (2011) ANÁLISE DE FALHAS EM POTENCIAL A análise de falhas em potencial consiste basicamente no preenchimento do formulário FMEA (ver exemplo no ANEXO A), onde é realizada pelo grupo de trabalho. Esse formulário é onde se caracterizam as funções e as características do produto e/ou processo; os tipos de falhas potenciais para cada função; os efeitos do tipo de falha; as causas possíveis da falha; e os controles atuais. As definições de cada termo estão apresentadas no ANEXO B AVALIAÇÃO DOS RISCOS Fernandes e Rebelato (2006, p. 248) explicam que a FMEA avalia a severidade de cada falha relativamente ao impacto causado aos clientes, sua probabilidade de ocorrência e de detecção antes de os produtos chegarem às mãos dos clientes. Estes autores esclarecem que com base nestes três elementos, severidade, ocorrência e detecção, o método FMEA leva à priorização de quais modos de falhas acarretam os maiores riscos ao cliente e que, portanto, merecem mais atenção.

23 22 Nesta etapa, inicialmente, são definidos os critérios e os índices para as questões severidade (S), ocorrência (O) e detecção (D) (as Tabelas 3.2, 3.3 e 3.4 mostram exemplos para tal definição). Com isso, para cada problema descrito no formulário FMEA são determinados os valores para S, O e D e em seguida é feita a multiplicação desses índices. Adquirindo assim, os Números de Prioridade de Risco (NPR). Tabela Exemplo de índice para severidade SEVERIDADE Índice Severidade Critério Mínima Pequena Moderada Alta Muito Alta Fonte: Toledo e Amaral (2011). O cliente mal percebeu que a falha ocorreu Ligeira deterioração no desempenho de um sistema com leve descontentamento do cliente Deterioração significativa no desempenho de um sistema com descontentamento do cliente Sistema deixa de funcionar e grande descontentamento do cliente Idem ao anterior porém afeta a segurança Tabela Exemplo de índice para ocorrência OCORRÊNCIA Índice Ocorrência Proporção Cpk 1 1 Remota 1 : Cpk > 1, Pequena 1 : : Cpk > 1, : : 400 Moderada 6 1 : 80 Cpk < 1,00 7 Alta 1 : Muito Alta Fonte: Toledo e Amaral (2011). 1 : 20 1 : 8 1 : 2 1 No caso do FMEA de processos pode-se utiliza os índices de capacidade (Cpk) da máquina para se determinar o índice de ocorrência.

24 23 Tabela Exemplo de índice para detecção DETECÇÃO Índice Detecção Critério Muito Grande Grande Moderada Pequena Muito Pequena Fonte: Toledo e Amaral (2011). Certamente será detectado Grande probabilidade de ser detectado Provavelmente será detectado Provavelmente não será detectado Certamente não será detectado MELHORIA A fase de melhoria consiste na utilização dos conhecimentos, criatividade e outras técnicas como o brainstorming. Nesta fase podem ser adotadas medidas de prevenção total ao tipo de falha; medidas de prevenção total de uma causa de falha; medidas que dificultam a ocorrência de falhas; medidas que limitem o efeito do tipo de falha; e medidas que aumentam a probabilidade de detecção do tipo ou da causa de falha. Tais medidas são estudadas para verificar sua viabilidade. Em seguida, são definidas as que serão implantadas. Os resultados destas medidas são controlados pelo próprio formulário FMEA por meio de colunas onde é feita a descrição das ações recomendadas, o responsável e prazo, medidas que foram implantadas e a nova avaliação dos riscos CONTINUIDADE Capaldo e outros (1999, p. 1) consideram que o formulário FMEA é um documento vivo, ou seja, uma vez realizada uma análise para um produto ou processo qualquer, deve-se revisar sempre que ocorrerem alterações neste produto ou processo específico. Além disso, mesmo que não hajam alterações, deve-se regularmente revisar a análise confrontando as falhas potenciais imaginadas pelo grupo com as que realmente vêm ocorrendo no dia-a-dia do

25 24 processo e uso do produto, de forma a permitir a incorporação de falhas não previstas, bem como a reavaliação, com base em dados objetivos, das falhas já previstas pelo grupo BANCO DE DADOS Canedo (2012) afirma que um Banco de Dados (BD) é um conjunto de dados, relativos a um determinado ambiente, armazenados em um ou vários computadores e que guardam entre si algum tipo de relacionamento. O BD, segundo Takai, Italiano e Ferreira (2005, p. 14), é uma coleção de dados logicamente relacionados, com algum significado. Associações aleatórias de dados não podem ser chamada de BD. O mesmo é projetado, construído e preenchido com dados para um propósito específico. Ele tem um grupo de usuários e algumas aplicações pré-concebidas para atendêlos. O Sistema de Gerenciador de Banco de Dados (SGBD), que se consiste de um conjunto de dados inter-relacionados e de um conjunto de programas para acessá-los, é projetado para gerenciar grandes volumes de dados. Para isso, tem como característica principal fornecer uma maneira adequada de armazenamento e recuperação de dados no BD (CANEDO, 2012, p. 3). Segundo Takai, Italiano e Ferreira (2005, p. 14), afirmam que um SGBD é uma coleção de programas que permitem aos usuários criarem e manipularem um BD. Um SGBD é, assim, um sistema de software de propósito geral que facilita o processo de definir (envolve a especificação de tipos de dados a serem armazenados), construir (processo de armazenar os dados em algum meio que seja controlado pelo SGBD) e manipular (utilização de funções como a de consulta, para recuperar dados específicos, modificação, e geração de relatórios) BD de diversas aplicações. A pessoa que fica com a responsabilidade de gerenciar os dados do banco e dos programas de acesso é o Administrador de Banco de Dados (DBA), ou seja, é a pessoa responsável que garante a implantação e o funcionamento do BD.

26 25 O BD e o software de gerenciamento compõem o chamado Sistema de Banco de Dados. A Figura 3.1 apresenta um esquema genérico de um Sistema de Banco de Dados em sua interação com seus usuários. Figura Sistema de Banco de Dados Fonte: Takai, Italiano e Ferreira (2005) MODELO RELACIONAL O modelo relacional apareceu devido às seguintes necessidades: aumentar a independência de dados nos sistemas gerenciadores de BD; prover um conjunto de funções apoiadas em álgebra relacional para armazenamento e recuperação de dados; e permitir processamento dedicado. O modelo relacional, tendo como base a teoria dos conjuntos e a álgebra relacional, foi resultado de um estudo teórico realizado por Codd (investigador da IBM). Tal resultado mostrou ser o mais adequado e flexível para solucionar vários problemas da implantação e concepção de um BD (TAKAI; ITALIANO; FERREIRA, 2005, p. 8).

27 26 A estrutura fundamental deste modelo é a tabela que é constituída por um ou mais campos (atributo) que traduzem o tipo de dados a armazenar. Cada linha da tabela é chamada de tupla (registro). O modelo relacional implementa estruturas de dados organizadas em relações. Porém, para trabalhar com essas tabelas, algumas restrições precisaram ser impostas para evitar aspectos indesejáveis, como: repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves e integridade de junções de relações. A Figura 3.2 traz exemplos de tabelas sob o modelo relacional. Figura Exemplo de tabelas do modelo relacional Cliente - Conta Corrente Fonte: Heuser (1998). Nota: Dados adaptados pelo autor TABELAS Uma tabela é um conjunto não ordenado de linhas (tuplas). Onde, cada linha é composta por uma série de campos (valor de atributo) e cada campo é identificado por nome do campo (nome do atributo). O conjunto de campos das linhas de uma tabela que possuem o mesmo nome forma uma coluna. Na Figura 3.3 abaixo podemos ver estas definições.

28 27 Figura Descrição de uma tabela Fonte: Heuser (1998). Nota: Dados adaptados pelo autor. O autor Heuser (1998) compara uma tabela de um banco de dados relacional com um arquivo convencional do sistema de arquivos de um computador. Com isso, identificando-se as seguintes diferenças: As linhas de uma tabela não estão ordenadas. A ordem de recuperação pelo SGBD é arbitrária, a menos que a instrução de consulta tenha especificado explicitamente uma ordenação. Não é possível referenciar linhas de uma tabela por posição. Já em arquivos convencionais, o programador tem controle sobre a ordem de armazenamento e pode referenciar registros por sua posição relativa dentro do arquivo; Os valores de campo de uma tabela são atômicos e mono-valorados. Em arquivos convencionais, campos podem ser compostos por outros campos ( itens de grupo ) e campos podem ser multi-valorados ( arrays de Pascal, ou grupos repetidos de COBOL); As linguagens de consulta a banco de dados relacionais permitem o acesso por quaisquer critérios envolvendo os campos de uma ou mais linhas. Em arquivos convencionais, para buscar registros com base em valores de seus campos de forma rápida é usualmente necessário que exista algum tipo de caminho de acesso. Um caminho de acesso é uma estrutura auxiliar, como um índice ou uma cadeia de ponteiros, que acelera a recuperação de registros por determinados critérios, evitando a leitura exaustiva de todos os registros de um arquivo. Caminhos de acesso também

29 28 existem em bancos de dados relacionais, mas não são visíveis pelos programadores, isto é, os programadores escrevem consultas à base de dados sem considerar a existência ou não de caminhos de acesso CHAVES O conceito básico para estabelecer relações entre linhas de tabelas de um banco de dados relacional é através da chave. Em um banco de dados relacional, podemos classificá-los ao menos três tipos de chaves: a chave primária, a chave estrangeira e a chave alternativa CHAVE PRIMÁRIA Uma chave primária é uma coluna ou uma combinação de colunas cujos valores distinguem uma linha das demais dentro de uma tabela (HEUSER, 1998, p. 77). Na tabela da Figura 3.3, a chave primária é a coluna Cod_Empregado. A Figura 3.4 apresenta um exemplo de uma tabela ( Dependentes ) que possui uma chave primária composta (colunas Cod_Empregado e Num_Dependente ). Neste caso, apenas um dos valores dos campos que compõem a chave não é suficiente para distinguir uma linha das demais, já que tanto um código de empregado ( Cod_Empregado ) pode aparecer em diferentes linhas, quanto um número de dependente ( Num_Dependente ) pode aparecer em diferentes linhas. É necessário considerar ambos os valores ( Cod_Empregado e Num_Dependente ) para identificar uma linha na tabela, ou seja para identificar um dependente.

30 29 Figura Exemplo de tabela de Dependentes Fonte: Heuser (1998). Nota: Dados adaptados pelo autor. Pela definição acima, na tabela da Figura 3.4, qualquer combinação de colunas que contenha as colunas Cod_Empregado e Num_Dependente é uma chave primária. Por isso, nas definições formais de chave primária, exige-se que essa seja mínima. Uma chave é mínima quando todas suas colunas forem efetivamente necessárias para garantir o requisito de unicidade de valores da chave. Exemplificando, alguém poderia considerar a combinação de colunas Cod_Empregado e Num_Dependente e Tipo como sendo uma chave primária. Entretanto, se eliminarmos, desta combinação a coluna Tipo continuamos frente a uma chave primária. Portanto, a combinação de colunas Cod_Empregado e Num_Dependente e Tipo não obedece o princípio da minimalidade e não deve ser considerada uma chave. Cabe salientar que, na abordagem relacional, o termo chave é empregado com uma conotação diferente daquela usada na área de organização de arquivos e em alguns sistemas operacionais. Em arquivos convencionais, entende-se por chave qualquer coluna sobre a qual será definido um índice ou algum outro tipo de estrutura de acesso. Na abordagem relacional, ao definir uma chave primária, está definindo apenas uma restrição de integridade e não um caminho de acesso. Contudo, deverá ser uma regra que será obedecida em todos os estados válidos do BD. No caso da chave primária, a regra é a unicidade de valores nas colunas que compõem a chave (HEUSER, 1998, p. 78) CHAVE ESTRANGEIRA Uma chave estrangeira é uma coluna ou uma combinação de colunas, cujos valores aparecem necessariamente na chave primária de uma tabela. A chave estrangeira é o

31 30 mecanismo que permite a implementação de relacionamentos em um banco de dados relacional (HEUSER, 1998, p. 78). Nas tabelas da Figura 3.5, a coluna Cod_Departamento da tabela Empregados é uma chave estrangeira em relação a chave primária da tabela Departamentos. Isso significa que, na tabela Empregados, não podem aparecer linhas que contenham um valor do campo Cod_Departamento que não exista na coluna de mesmo nome da tabela Empregados. A interpretação desta restrição é que todo empregado deve estar associado a um departamento. Figura Exemplo de tabelas de Departamentos e Empregados Fonte: Heuser (1998). Nota: Dados adaptados pelo autor. Segundo Heuser (1998), cita que a existência de uma chave estrangeira impõe restrições que devem ser garantidas em diversas situações de alteração do BD: Quando da inclusão de uma linha na tabela que contém a chave estrangeira - Neste caso, deve ser garantido que o valor da chave estrangeira apareça na coluna da chave primária referenciada. No caso do exemplo da Figura 3.5, isso significa que um novo empregado deve atuar em um departamento já existente no BD; Quando da alteração do valor da chave estrangeira - Deve garantir que o novo valor de uma chave estrangeira apareça na coluna da chave primária referenciada; Quando da exclusão de uma linha da tabela que contém a chave primária referenciada pela chave estrangeira - Deve garantir que na coluna chave estrangeira não apareça o valor da chave primária que está sendo excluída. No caso do exemplo da Figura 3.5,

32 31 isso significa que um departamento não pode ser excluído, caso nele ainda existirem empregados. A palavra estrangeira usada para denominar este tipo de chave pode ser enganosa. Ela pode levar a crer que a chave estrangeira sempre referencia uma chave primária de outra tabela. Entretanto, esta restrição não existe. Uma chave primária pode referenciar a chave primária da própria tabela, como mostra a Figura 3.6. Nesta tabela, a coluna Cod_EmpGerente é o código de um outro empregado, o gerente do empregado correspondente a linha em questão. Como todo gerente é ele mesmo também um empregado, existe a restrição de que todo valor da coluna Cod_EmpGerente deve aparecer na coluna Cod_Empregado. Assim, a coluna Cod_EmpGerente é chave estrangeira em relação a chave primária da própria tabela Empregados. Figura Exemplo de tabela de Empregados com chave estrangeira Fonte: Heuser (1998). Nota: Dados adaptados pelo autor CHAVE ALTERNATIVA Em alguns casos, mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais. Uma das colunas (ou combinação de colunas) é escolhida como chave primária. As demais colunas ou combinações são consideradas chaves alternativas. A Figura 3.7 mostra um exemplo de uma tabela com dados de empregados (tabela Empregados ) na qual tanto a coluna Cod_Empregado quanto a coluna CPF podem ser usadas para distinguir uma linha das demais. Nesta tabela, como a coluna Cod_Empregado foi escolhida como chave primária, diz-se que a coluna CPF é uma chave alternativa.

33 32 Figura Exemplo de tabela de Empregados com chave alternativa Fonte: Heuser (1998). Nota: Dados adaptados pelo autor. Quando, em uma tabela, mais de uma coluna ou combinações de colunas podem servir para distinguir uma linha das demais, surge à questão de que critério deve-se usar para determinar qual das possíveis colunas (ou combinação de colunas) será usada como chave primária. No exemplo da Figura 3.7, o critério foi usado para preferir a coluna Cod_Empregado como chave primária e considerar a coluna CPF como chave alternativa. Se considerarmos apenas a tabela em que a coluna aparece, não há diferença entre uma coluna ser chave primária ou alternativa. Em ambos os casos, apenas está sendo especificada a unicidade de valores de chave. Entretanto, ao considerarmos chaves estrangeiras, a diferenciação entre chave primária e chave alternativa passa a ser relevante. Quando especificamos que uma chave é primária, estamos especificando, além da unicidade de valores, também o fato de esta coluna ser usada nas chaves estrangeiras que referenciam a tabela em questão. Assim, no caso da tabela da Figura 3.7, estamos especificando que tanto os valores de Cod_Empregado quanto os valores de CPF são únicos e adicionalmente que a coluna Cod_Empregado será usada nas chaves estrangeiras que referenciam a tabela Empregados RELACIONAMENTOS Segundo Heuser (1998), a técnica de modelagem de dados entidade-relacionamento (ER) é mais consagrado. Onde, o modelo de dados é representado através de um modelo entidaderelacionamento (modelo ER). Usualmente, um modelo ER é representado graficamente, através de um diagrama entidade-relacionamento (DER). Uma entidade representa, no modelo conceitual, um conjunto de objetos da realidade modelada. Como o objetivo de um modelo ER é modelar de forma abstrata um BD, para o

34 33 desenvolvimento, adquire-se somente os objetos sobre os quais deseja manter informações. Ou seja, considerando um sistema de contas correntes, por exemplo, algumas entidades podem ser os clientes, as contas correntes, os cheques e as agências. Nota-se que uma entidade pode representar objetos concretos da realidade (uma pessoa, um automóvel) ou objetos abstratos (um departamento, um endereço). Além de especificar os objetos sobre os quais deseja manter informações, o DER deve permitir a especificação das propriedades dos objetos que serão armazenadas no BD. Uma das propriedades sobre as quais pode ser desejável manter informações é a associação entre objetos. Em um DER, uma entidade é representada através de um retângulo que contém o nome da entidade, e, um relacionamento é representado através de um losango, ligado por linhas aos retângulos representativos das entidades que participam do relacionamento. A cardinalidade máxima pode ser usada para classificar relacionamentos binários. Um relacionamento binário é aquele cujas ocorrências envolvem duas entidades, como todos vistos até aqui. Heuser (1998) cita que os relacionamentos podem ser classificados em n:n (muitos-para-muitos), 1:n (um-para-muitos) e 1:1 (um-para-um). A Figura 3.8, a Figura 3.9 e a Figura 3.10 apresentam exemplos de relacionamentos com cardinalidades máximas 1:1, 1:n e n:n, respectivamente.

35 34 Figura Exemplos de relacionamentos 1:1 Fonte: Heuser (1998). Nota: Dados adaptados pelo autor.

36 35 Figura Exemplos de relacionamentos 1:n Fonte: Heuser (1998). Nota: Dados adaptados pelo autor.

37 36 Figura Exemplos de relacionamentos n:n Fonte: Heuser (1998). Nota: Dados adaptados pelo autor. Os exemplos mostrados acima são de relacionamentos binários, ou seja, de relacionamentos que associam exatamente duas entidades. A abordagem ER permite que sejam definidos relacionamentos de grau maior do que dois (relacionamentos ternários, quaternários, entre outros). O DER da Figura 3.11 mostra um exemplo de um relacionamento ternário.

38 37 Figura Exemplo de relacionamento ternário Fonte: Heuser (1998). Nota: Dados adaptados pelo autor. Além da cardinalidade máxima, outra informação que pode ser representada por um modelo ER é o número mínimo de ocorrências de entidade que são associadas a uma ocorrência de uma entidade através de um relacionamento. Para fins de projeto de BD, consideram-se apenas duas cardinalidades mínimas: a cardinalidade mínima 0 e a cardinalidade mínima 1. A cardinalidade mínima 1 também recebe a denominação de associação obrigatória, já que ela indica que o relacionamento deve obrigatoriamente associar uma ocorrência de entidade a cada ocorrência da entidade em questão. Com base na mesma linha de raciocínio, a cardinalidade mínima 0 também recebe a denominação de associação opcional NORMATIZAÇÃO O processo de normatização baseia-se no conceito de forma normal. Uma forma normal é uma regra que deve ser obedecida por uma tabela para que esta seja considerada bem projetada. Há diversas formas normais, isto é, diversas regras, cada vez mais rígidas, para verificar tabelas relacionais. Canedo (2012) menciona que o processo de normatização pode

39 38 ser classificado em três formas normais. As formas normais são denominadas simplesmente primeira, segunda e terceira forma normal, abreviadamente 1FN, 2FN e 3FN PRIMEIRA FORMA NORMAL (1FN) O primeiro passo da normalização consta da transformação do esquema de tabela não normalizada em um esquema relacional na primeira forma normal (1FN). Uma tabela encontra-se na 1FN quando não contém colunas multivaloradas. Portanto, a passagem à 1FN consta da eliminação destas colunas eventualmente existentes. Heuser (1998) estabelece duas alternativas para transformar um esquema de tabela nãonormatizada em um esquema na 1FN: Construir uma única tabela com redundância de dados, ou seja, cria-se uma tabela na qual os dados das linhas externas à coluna multivalorada são repetidos para cada linha desta coluna; Construir uma tabela para cada coluna multivalorada, ou seja, cria-se uma tabela referente à própria tabela que está sendo normalizada e uma tabela para cada coluna com dados redundantes. Considerando apenas a correção do processo de normalização, a primeira alternativa (tabela única) é a preferida. Ao decompor uma tabela em várias tabelas, como ocorre na segunda alternativa, podem ser perdidas relações entre informações. Entretanto, para fins práticos, preferimos a segunda alternativa (decomposição de tabelas), mesmo sabendo que ela pode levar a modelos imperfeitos. A motivação é de ordem prática. No caso de uma tabela não normalizada, que possui apenas uma coluna multivalorada, fica fácil visualizar a tabela na 1FN, na primeira alternativa. Entretanto, quando houver diversas colunas multivaloradas, eventualmente com diversos níveis de valores, fica difícil visualizar a tabela na 1FN. Na decomposição de tabelas, segundo Heuser (1998, p. 126), a passagem à primeira forma normal de tabelas é feita nos seguintes passos:

40 39 1. Criar uma tabela na 1FN referente à tabela não normalizada e que contém apenas as colunas com valores atômicos, isto é, sem as colunas multivaloradas. A chave primária da tabela na 1FN é idêntica à chave da tabela não normalizada; 2. Para cada coluna multivalorada, criar uma tabela na 1FN composta pelas seguintes colunas: a chave primária de cada uma das tabelas na qual a tabela em questão está multivalorada; e as colunas da própria coluna multivalorada; 3. Definir as chaves primárias das tabelas na 1FN que correspondem a colunas multivaloradas SEGUNDA FORMA NORMAL (2FN) Uma tabela encontra-se na segunda forma normal (2FN) quando, além de encontrar-se na primeira forma normal, cada coluna não chave depende da chave primária completa. Uma tabela que não se encontra na 2NF contém dependências funcionais parciais, ou seja, contém colunas não chave que dependem apenas de uma parte da chave primária. Obviamente, uma tabela que está na 1FN e que possui apenas uma coluna como chave primária não contém dependências parciais, já que nesta tabela é impossível uma coluna depender de uma parte da chave primária, visto que a chave primária não é composta por partes (por diversas colunas). Assim, toda tabela que está na 1FN e que possui apenas uma coluna como chave primária já está na 2FN. O mesmo aplica-se para uma tabela que contenha apenas colunas chave primária. Segundo Heuser (1998, p. 132), os processos de passagem da 1FN a 2FN são, segundo: 1. Copiar para a 2FN cada tabela que tenha chave primária simples ou que não tenha colunas além da chave; 2. Para cada tabela com chave primária composta e com pelo menos uma coluna não chave: a. Criar na 2FN uma tabela com as chaves primárias da tabela na 1FN; b. Para cada coluna não chave fazer a seguinte pergunta: a coluna depende de toda a chave ou de apenas parte dela?

41 40 i. Caso a coluna dependa de toda a chave: 1. Criar a coluna correspondente na tabela com a chave completa na 2FN. ii. Caso a coluna dependa apenas de parte da chave: 1. Criar, caso ainda não existir, uma tabela na 2FN que tenha como chave primária a parte da chave que é determinante da coluna em questão; 2. Criar a coluna dependente dentro da tabela na 2FN TERCEIRA FORMA NORMAL (3FN) Uma tabela encontra-se na 3FN quando, além de estar na 2FN, toda coluna não chave depende diretamente de chave primária, isto é, quando não há dependências funcionais transitivas ou indiretas. Uma dependência funcional transitiva ou indireta acontece quando uma coluna não chave primária depende funcionalmente de outra coluna ou combinação de colunas não chave primária. A passagem à 3FN consta em dividir tabelas de forma a eliminar as dependências transitivas. Segundo Heuser (1998, p. 135), os processos de passagem da 2FN a 3FN são: 2. Copiar para o esquema na 3FN cada tabela que tenha menos que duas colunas não chave, pois neste caso não há como haver dependências transitivas; 3. Para tabelas com duas ou mais colunas não chave: a. Criar uma tabela no esquema da 3FN com a chave primária da tabela em questão; b. Para cada coluna não chave fazer a seguinte pergunta: a coluna depende de alguma outra coluna não chave (dependência transitiva ou indireta)? i. Caso a coluna dependa apenas da chave: 1. Copiar a coluna para a tabela na 3FN. ii. Caso a coluna depender de outra coluna:

42 41 1. Criar, caso ainda não exista, uma tabela no esquema na 3FN que tenha como chave primária a coluna da qual há a dependência indireta; 2. Copiar a coluna dependente para a tabela criada; 3. A coluna determinante deve permanecer também na tabela original. Assim, resumidamente, os passos para transformar uma tabela não normatizada até a terceira forma normal, segundo o autor Canedo (2012) e o autor Heuser (1998), podem ser descritas conforme a Figura Figura Passos de transformação da normatização

43 42 4. METODOLOGIA O estudo metodológico considera o tipo de abordagem da pesquisa e o método de coleta de dados. A integração de uma ferramenta de melhoria contínua com um banco de dados são temas de difícil mensuração. Desta forma, este trabalho utiliza uma abordagem qualitativa para o tratamento dos dados. Uma vez que, na abordagem qualitativa ocorre uma relação dinâmica entre o mundo real e o sujeito, ou seja, um vínculo indissociável entre o mundo objetivo e a subjetividade do sujeito que não pode ser traduzido em números (SILVA; MENEZES, 2005, p. 20). Visando atender aos objetivos deste trabalho, que consiste em desenvolver um banco de dados a fim de interagir com o método FMEA, o estudo de caso torna-se um método de pesquisa viável. Gil (2002, p. 54) afirma que o estudo de caso tem como propósito de formular hipóteses ou desenvolver teorias e, também, explicar as variáveis causais de determinado fenômeno em situações muito complexas que não possibilitam a utilização de levantamentos e experimentos. Logo, este método foi selecionado para a condução deste trabalho devido à dificuldade de se acessar e modificar dados e rotinas de um projeto, isto é, aplicar o método em um projeto específico, manipulando os dados. Uma vez que se trata de aplicar e avaliar, hipoteticamente, o método FMEA integrada com um banco de dados, este trabalho se enquadra como estudo de caso exploratório. Pois, as pesquisas exploratórias têm o objetivo principal de desenvolver ideias visando fornecer hipóteses em condições de serem testadas em estudos posteriores (GIL, 2002, p. 131). O desenvolvimento do trabalho necessita da observação de fatos e fenômenos exatamente como ocorre na realidade, da coleta de dados referente aos mesmos, e da análise e interpretação desses dados obtidos. A análise dos dados coletados em campo tem como base uma fundamentação teórica consistente, objetivando compreender e explicar o problema pesquisado. O tipo do método FMEA utilizado foi a de processos, onde, tal análise foi voltada aos processos de instalação dos equipamentos desenvolvidos pelo projeto de automação para o teste físico de pelotas de minério de ferro de uma empresa do setor de mineração.

44 43 O tipo de banco de dados que foi utilizado neste trabalho é o Bando de Dados Relacional. Ou seja, por possuir acesso facilitado aos dados, possibilita que os usuários utilizem uma grande variedade de abordagens no tratamento das informações. O programa Microsoft Office Access 2007 foi escolhido como Sistema Gerenciador de Banco de Dados (SGBD), para o desenvolvimento do mesmo, por ser uma ferramenta de fácil utilização na gestão dos dados que serão adquiridos ao longo do trabalho. A coleta de dados foi realizada por meio de observação direta e levantamento documental. A observação foi realizada através do acompanhamento diário das instalações de todos os equipamentos desenvolvidos pelo projeto de automação. Alguns dados foram adquiridos através dos Cadernos de Instrução de Montagem, onde, está a descrição de todos os processos que serão realizadas para as instalações de cada equipamento. Foram realizadas pequenas reuniões com os funcionários responsáveis de cada processo, com isso, coletando dados importantes para o desenvolvimento e preenchimento do formulário FMEA. Na parte da Ação de Melhoria, foram realizadas reuniões para propor Ações de Melhorias e definir as Tarefas para sua concretização. Porém, uma das limitações do trabalho, devido à grande dificuldade modificar rotinas de um projeto, foi da impossibilidade de realizar estas ações e avaliar a real redução do NPR. No entanto, para avaliar as ações propostas, foi feito um novo estudo com a hipótese de que todas as ações propostas foram implantadas no processo e, com isso, adquirindo, hipoteticamente, novos NPR.

45 44 5. DESENVOLVIMENTO 5.1. A ESTRUTURA DO FMEA Primeiramente foi feito um estudo do projeto automação. Com isso, observou-se que os processos de implantação dos equipamentos desenvolvidos no projeto de automação seriam os mais convenientes para a aplicação do método, pois, quando foi iniciado o estudo, notou-se que o projeto já estava na iminência de implantação dos equipamentos e constatou-se, também, grande quantidade de falhas potenciais nestes processos. Os dados dos processos foram adquiridos no cronograma do processo de instalação. Mais especificamente, o cronograma adotado foi o da implantação dos equipamentos desenvolvidos pelo projeto para uma empresa do setor de mineração, como mostra no ANEXO C. Após a seleção do tipo do método e quais processos seriam estudados, foi feita uma análise do método nos processos de implantação e, com isso, estruturou-se a Tabela FMEA como mostra o APÊNDICE A. Além disso, com as informações adquiridas pelos responsáveis destes processos, determinou-se o índice e o critério da severidade, ocorrência e detecção como mostra nas Tabelas 5.1, 5.2 e 5.3, respectivamente. Tabela Severidade no processo de implantação SEVERIDADE Índice Severidade Critério Remota Pequena Moderada Alta Muito Alta Sem defeito perceptível Ligeira deterioração no desempenho de um sistema Deterioração significativa no desempenho de um sistema Sistema deixa de funcionar Sistema deixa de funcionar e afeta a segurança

46 45 Tabela Ocorrência no processo de implantação OCORRÊNCIA Índice Ocorrência Critério Remota Pequena Moderada Alta Muito Alta Chance remota de falha Ocorrência de falhas entre 1 a 5 vezes por mês Ocorrência de falhas entre 6 a 10 vezes por mês Ocorrência de falhas entre 11 a 15 vezes por mês Ocorrência de falhas acima de 16 vezes por mês Tabela Detecção no processo de implantação DETECÇÃO Índice Detecção Critério Muito Alta Alta Moderada Pequena Remota Certamente será detectado Grande probabilidade de ser detectado Provavelmente será detectado Provavelmente não será detectado Certamente não será detectado Para uma organização e descrição mais detalhada da Medida Implantada na Tabela FMEA, adicionou-se a coluna Tarefa, onde, tal coluna é constituída de: Tarefas para realizar a Medida Implantada; Data de Início e de Conclusão de cada Tarefa; Responsável para a realização de cada Tarefa; Status que classifica cada Tarefa (Não Iniciada, Em Andamento ou Concluída) para o seu controle.

47 A INTEGRAÇÃO DO MÉTODO COM O BANCO DE DADOS O programa Microsoft Office Access 2007 foi escolhido como o Sistema Gerenciador de Banco de Dados (SGBD) para o desenvolvimento da integração do método FMEA com um Banco de Dados (BD), pois o programa é de fácil acesso por fazer parte do Pacote Office e foi possível encontrar vários tutoriais em websites para o aprendizado da utilização desta ferramenta CRIAÇÃO DE TABELAS E RELACIONAMENTOS Para o início do desenvolvimento foram criadas todas as tabelas no programa, onde, basicamente, cada tabela da estrutura do BD seria uma coluna da Tabela FMEA desenvolvida (APÊNDICE A). Após esta etapa, foram adicionadas todas as colunas das tabelas criadas no programa. Tais colunas foram formadas com base nos dados do APÊNDICE A, ou seja, cada constituição das colunas da Tabela FMEA forma cada coluna das tabelas do programa. Em todas as tabelas criadas no BD, foram inseridas as chaves primária, secundária e/ou estrangeira para a realização de todos os relacionamentos das tabelas e, com isso, gerando a estrutura da integração do método FMEA com o programa, conforme mostra no APÊNDICE B DESENVOLVIMENTO DE FORMULÁRIOS E RELATÓRIOS Os formulários foram desenvolvidos para que o usuário utilize o programa de uma forma rápida e clara. Além disso, tem por objetivo de evitar a entrada inválida de dados e evitar, também, excluir dados de uma forma errada fazendo com que ocorra a perda de outros dados correlacionados. Para a visualização de dados, adicionados no BD, foram criadas vários relatórios. Onde, tem por objetivo de facilitar no controle dos dados e também divulga-los para outras pessoas que fazem parte do projeto.

48 CRIAÇÃO DE MACROS As macros foram criadas para facilitar na utilização do BD, onde, é uma ferramenta que permite automatizar tarefas e adicionar funcionalidades aos formulários, relatórios e controles. Tais macros foram utilizadas para adicionar botões de comando a um formulário, executar automaticamente o menu principal ao entrar no BD, atualizar formulários automaticamente e entre outros O APLICATIVO Ao entrar no programa, ele abrirá a janela principal automaticamente (Figura 5.1). Onde possui o botão de minimizar ( ), sair do aplicativo ( ), o índice da Tabela FMEA ( ) e o índice de pesquisa ( ). Os dois índices serão explicados adiante. Figura Índice principal do aplicativo

49 ÍNDICE DA TABELA FMEA A finalidade do índice da FMEA - Failure Mode and Effect Analysis (Figura 5.2) seria obter um layout similar ao de uma Tabela FMEA tradicional para facilitar no uso do programa. Para isso, foi inserido um botão, em cada título das colunas, que abre uma nova janela para realização da adição/edição dos dados desta coluna. Cada janela será descrito adiante. Figura Índice da Tabela FMEA FORMULÁRIO PROCESSO Ao clicar em Processo será aberta uma nova janela (Figura 5.3) onde o usuário seleciona o processo na caixa de combinação do Selecionar Processo, com isso, gerando o Nome do Processo, o Prazo e o Status. Além disso, o usuário tem a opção de modificar todos os dados gerados, voltar para o Índice da Tabela FMEA ( ), excluir o processo selecionado ( ) e adicionar um novo processo ( ). Esta ultima opção abrirá uma nova janela, Formulário Adicionar Processo (Figura 5.4), para realização desta tarefa.

50 49 Figura Formulário Gerenciar Processo Figura Formulário Adicionar Processo

51 FORMULÁRIO SUBPROCESSO O formulário Subprocesso (Figura 5.5) é onde realiza o detalhamento de todos os Processos adicionados. Onde, é constituído de: Subprocesso do Processo selecionado na caixa de combinação; Data de Início e de Conclusão de cada Subprocesso; Responsável para a realização de cada Subprocesso; Status que classifica cada Subprocesso (Não Iniciado, Em Andamento ou Concluído) para o seu controle. Figura Formulário Subprocesso Caso o usuário deseje adicionar um novo dado na caixa de combinação do Responsável, foi adicionado um botão, Adicionar, que direciona para o formulário Adicionar Responsável (Figura 5.6), onde, entra-se com o Nome, Telefone e do responsável.

52 51 Figura Formulário Adicionar Responsável FORMULÁRIO FALHA POTENCIAL O formulário Falha Potencial (Figura 5.7) é onde o usuário pode realizar a adição, a exclusão e a edição das Falhas Potencias do Subprocesso selecionado na caixa de combinação.

53 52 Figura Formulário Falha Potencial Para que não sejam exibidos todos os Subprocessos de todos os Processos na caixa de combinação do Subprocesso foi feito um comando para filtrar os dados, com isso, mostrando somente os Subprocessos do Processo selecionado na caixa de combinação de Processo. Além de facilitar na utilização deste programa, o filtro serve, também, para que não ocorra erro na entrada de dados no BD. Tendo como objetivo de facilitar na gerência de dados e evitar entrada de dados inconsistentes, este comando foi criado para todos os formulários que necessitam de filtrar algum tipo de dado FORMULÁRIO EFEITO O formulário Efeito (Figura 5.8) é onde o usuário pode realizar a adição, a exclusão e a edição dos Efeitos da Falha Potencial selecionada na caixa de combinação.

54 53 Figura Formulário Efeito FORMULÁRIO CAUSA O formulário Causa (Figura 5.9) é onde o usuário pode realizar a adição, a exclusão e a edição das Causas da Falha Potencial selecionada na caixa de combinação.

55 54 Figura Formulário Causa FORMULÁRIO CONTROLE ATUAL O formulário Controle Atual (Figura 5.10) é onde o usuário pode realizar a adição, a exclusão e a edição dos Controles Atuais da Falha Potencial selecionada na caixa de combinação.

56 55 Figura Formulário Controle Atual FORMULÁRIO ÍNDICES O formulário Índices (Figura 5.11) é onde o usuário adiciona os índices da Severidade, Ocorrência e Detecção da Falha Potencial selecionada na caixa de combinação. Após o preenchimento destes três índices, o programa gera automaticamente o valor do Risco (NPR) que é a multiplicação destes índices.

57 56 Figura Formulário Índices Este formulário possui três botões ( ) para auxiliar o usuário na determinação dos valores dos índices da Severidade, Ocorrência e Detecção. Ou seja, ao clicar nestes botões, o formulário abrirá uma nova janela onde terá o detalhamento destes índices, conforme mostram as Figuras 5.12, 5.13 e 5.14.

58 57 Figura Detalhamento da Severidade Figura Detalhamento da Ocorrência

59 58 Figura Detalhamento da Detecção FORMULÁRIO AÇÃO RECOMENDADA O formulário Ação Recomendada (Figura 5.15) é onde o usuário pode realizar a adição, a exclusão e a edição das Ações Recomendadas da Falha Potencial selecionada na caixa de combinação. Ou seja, são armazenadas todas as possíveis soluções, geradas após um brainstorming de uma equipe, para a Falha Potencial selecionada.

60 59 Figura Formulário Ação Recomendada FORMULÁRIO MEDIDA IMPLANTADA O formulário Medida Implantada (Figura 5.16) é onde o usuário realiza a seleção da Medida Implantada para a Falha Potencial selecionada na caixa de combinação, ou seja, é selecionada quais Ações Recomendadas serão implantadas. Com isso, definindo seu Prazo e selecionando o Status para seu acompanhamento.

61 60 Figura Formulário Medida Implantada FORMULÁRIO TAREFA O formulário Tarefa (Figura 5.17) é onde realiza o detalhamento da Medida Implantada selecionada na caixa de combinação. Onde, é constituído de: Tarefas da Medida Implantada selecionado na caixa de combinação; Data de Início e de Conclusão de cada Tarefa; Responsável para a realização de cada Tarefa; Status que classifica cada Tarefa (Não Iniciada, Em Andamento ou Concluída) para o seu controle.

62 61 Figura Formulário Tarefa Caso o usuário deseje adicionar um novo dado na caixa de combinação do Responsável, foi adicionado um botão, Adicionar, que direciona para o formulário Adicionar Responsável (Figura 5.6), onde, entra-se com o Nome, Telefone e do responsável FORMULÁRIO ÍNDICES ATUAIS Após a medida ser implantada, o usuário utiliza o formulário Índices Atuais (Figura 5.18) para adicionar os novos índices da Severidade, Ocorrência e Detecção da Falha Potencial selecionada na caixa de combinação. Após o preenchimento destes três índices, o programa gera automaticamente o valor do Risco (NPR) que é a multiplicação destes índices.

63 62 Figura Formulário Índices Atuais ÍNDICE PESQUISA Para facilitar no gerenciamento e na pesquisa de dados do BD, foi desenvolvido um Índice de Pesquisa (Figura 5.19). Onde, o usuário pode gerar relatórios, que serão explicados no próximo tópico, e também há a opção de salvá-los em formato PDF (Portable Document Format) para a divulgação de resultados obtidos neste programa.

64 63 Figura Índice Pesquisa Os tipos de relatórios gerados neste programa são: Lista de processos, subprocessos, medidas implantadas e tarefas por status; Lista de subprocessos e tarefas por responsável; Lista de Níveis Críticos (antes e após a ação de melhoria) em ordem Decrescente; Lista com os Dados dos Responsáveis. Caso o usuário deseje alterar ou excluir os dados dos Responsáveis, foi adicionado um botão ( ) que direciona para o formulário Gerenciar Responsáveis (Figura 5.20), onde é possível alterar o Nome, Telefone e do responsável selecionado na caixa de combinação Selecionar Nome.

65 64 Figura Formulário Gerenciar Responsável RELATÓRIO DE PROCESSOS O Relatório dos Processos (Figura 5.21) faz a descrição de todos os Processos e seus Prazos do Status selecionado na caixa de combinação Status dos Processos do Índice Pesquisa. Para a geração do relatório, o usuário seleciona o Status do Processo desejado na caixa de combinação e, em seguida, o mesmo tem a opção de Visualizar ou Salvar tal relatório, onde, a segunda opção salvará em formato PDF.

66 65 Figura Relatório de Processos Não Iniciados RELATÓRIO DE SUBPROCESSOS O Relatório dos Subprocessos (Figura 5.22) faz a descrição de todos os Subprocessos com sua Data de Início, Data de Conclusão e Responsável do Status selecionado na caixa de combinação Status dos Subprocessos do Índice Pesquisa. Para a geração do relatório, o usuário seleciona o Status do Subprocesso desejado na caixa de combinação e, em seguida, o mesmo tem a opção de Visualizar ou Salvar tal relatório, onde, a segunda opção salvará em formato PDF.

67 66 Figura Relatório de Subprocessos Não Iniciados RELATÓRIO DE MEDIDAS IMPLANTADAS O Relatório das Medidas Implantadas (Figura 5.23) faz a descrição de todas as Medidas Implantadas com seu Prazo do Status selecionado na caixa de combinação Status das Medidas Implantadas do Índice Pesquisa. Para a geração do relatório, o usuário seleciona o Status da Medida Implantada desejado na caixa de combinação e, em seguida, o mesmo tem a opção de Visualizar ou Salvar tal relatório, onde, a segunda opção salvará em formato PDF.

68 67 Figura Relatório de Medidas Implantadas Não Iniciadas RELATÓRIO DE TAREFAS O Relatório das Tarefas (Figura 5.24) faz a descrição de todas as Tarefas, das Medidas Implantadas, com seu Prazo do Status selecionado na caixa de combinação Status das Tarefas do Índice Pesquisa. Para a geração do relatório, o usuário seleciona o Status da Tarefa desejado na caixa de combinação e, em seguida, o mesmo tem a opção de Visualizar ou Salvar tal relatório, onde, a segunda opção salvará em formato PDF.

69 68 Figura Relatório de Tarefas Não Iniciadas RELATÓRIO DE RESPONSÁVEIS DOS SUBPROCESSOS O Relatório dos Responsáveis dos Subprocessos (Figura 5.25) faz a descrição de todos os Subprocessos e sua Data de Início, Data de Conclusão e Status do Responsável selecionado na caixa de combinação Responsável dos Subprocessos do Índice Pesquisa. Para a geração do relatório, o usuário seleciona o Responsável dos Subprocessos desejado na caixa de combinação e, em seguida, o mesmo tem a opção de Visualizar ou Salvar tal relatório, onde, a segunda opção salvará em formato PDF.

70 69 Figura Relatório de Subprocessos sob a Responsabilidade do Francisco RELATÓRIO DE RESPONSÁVEIS DAS TAREFAS O Relatório dos Responsáveis das Tarefas (Figura 5.26) faz a descrição de todas as Tarefas e sua Data de Início, Data de Conclusão e Status do Responsável selecionado na caixa de combinação Responsável das Tarefas do Índice Pesquisa. Para a geração do relatório, o usuário seleciona o Responsável das Tarefas desejado na caixa de combinação e, em seguida, o mesmo tem a opção de Visualizar ou Salvar tal relatório, onde, a segunda opção salvará em formato PDF.

71 70 Figura Relatório de Tarefas sob a Responsabilidade do Márcio Luiz RELATÓRIO DE NÍVEIS CRÍTICOS O Relatório dos Níveis Críticos (Figura 5.27) faz a descrição de todas as Falhas Potenciais e sua Severidade, Ocorrência, Detecção e Índice, onde, as Falhas Potenciais são ordenadas, automaticamente, em ordem decrescente em relação ao seu Número de Prioridade de Risco (NPR). Para a geração do relatório, o usuário tem a opção de Visualizar ou Salvar o mesmo em formato PDF.

72 71 Figura Relatório de Nível de Risco da Falha Potencial RELATÓRIO DE NÍVEIS CRÍTICOS APÓS A MEDIDA IMPLANTADA O Relatório dos Níveis Críticos Após a Medida Implantada (Figura 5.28) faz a descrição de todas as Falhas Potenciais e sua Severidade, Ocorrência, Detecção e Índice, onde, as Falhas Potenciais são ordenadas, automaticamente, em ordem decrescente em relação ao seu NPR. Para a geração do relatório, o usuário tem a opção de Visualizar ou Salvar o mesmo em formato PDF.

73 72 Figura Relatório de Nível de Risco Após a Medida Implantada RELATÓRIO DE DADOS DOS RESPONSÁVEIS O Relatório dos Responsáveis (Figura 5.29) faz a descrição de todos os Responsáveis, seu telefone e seu de contato. Para a geração do mesmo, o usuário tem a opção de Visualizar ou Salvar em formato PDF. Figura Relatório dos Responsáveis

74 73 6. RESULTADOS Após o preenchimento do Banco de Dados (BD), que foi desenvolvido para a aplicação do Método FMEA, estudou-se os 26 processos de implantação dos equipamentos desenvolvidos pelo projeto de automação, conforme mostra o cronograma presente no ANEXO C. Onde, adquiriu-se um total de 199 Falhas Potenciais, 769 Efeitos gerados pelas falhas, 1016 possíveis Causas das falhas e 192 Controles para estas falhas. Com a realização dos estudos, observou-se que muitos processos possuem falhas potenciais similares. Com isso, após o preenchimento do BD, observou-se que os 26 processos possuem somente 9 falhas potenciais distintas, conforme mostra abaixo: Acidentes de trabalho; o Efeito: Atraso no cronograma; Aumento do custo de produção; Insatisfação do cliente; Mão de obra ociosa; Necessidade de paralisação do processo; o Causas: Falta de equipamentos de segurança; Inadequação da mão de obra existente; Inadequação de equipamentos para a realização do processo; Inadequação do local de trabalho; o Controle: Treinamento e certificação da mão de obra existente; Utilização de equipamentos de proteção individual (EPI); Utilização de ferramentas de segurança do trabalho; Atraso no cronograma; o Efeito: Aumento do custo de produção; Insatisfação do cliente; o Causa: Falta de aprovação da empresa para a realização do processo; Falta de energia no local de trabalho; Falta de equipamentos para a realização do processo; Falta de mão de obra; Furto de equipamentos; Inadequação da mão de obra existente; Inadequação de componentes do módulo; Inadequação de equipamentos para a realização do processo; Inadequação do local de trabalho; Necessidade de paralisação dada pela empresa; Problemas climáticos; o Controle: Utilização de cronograma no Microsoft Project 2007;

75 74 Falta de energia no ambiente da empresa; o Efeito: Atraso no cronograma; Aumento do custo de produção; Mão de obra ociosa; Necessidade de paralisação do processo; o Causa: Sobrecarga da energia da empresa; o Controle: Nenhum; Falta de mão de obra adequada para a realização da tarefa; o Efeito: Acidente de trabalho; Atraso no cronograma; Mão de obra sobrecarregada; o Causa: Falta de contratação da mão de obra; Inadequação da mão de obra existente; o Controle: Treinamento e certificação da mão de obra existente; Falta/Inadequação de equipamentos para a realização do processo; o Efeito: Acidente de trabalho; Atraso no cronograma; Aumento do custo de produção; Insatisfação do cliente; Mão de obra ociosa; Necessidade de paralisação do processo; o Causa: Falta de compra/aluguel de equipamentos adequados para a realização do processo; o Controle: Contrato com empresas para o aluguel de equipamentos; Fiscalização realizada pelos funcionários responsáveis da obra; Furto de equipamentos; o Efeito: Atraso no cronograma; Aumento do custo de produção; Insatisfação do cliente; Mão de obra ociosa; Necessidade de paralisação do processo; o Causa: Falta de segurança; o Controle: Nenhum; Inadequação de componentes do módulo; o Efeito: Atraso no cronograma; Aumento do custo de produção; Insatisfação do cliente; Necessidade de paralisação do processo; Necessidade de retrabalho/troca da peça;

76 75 o Causa: Falta de informações necessárias para a produção/desenvolvimento de componentes pelas empresas contratadas; Falta de qualidade nos componentes produzidos pelas empresas contratadas; o Controle: Contrato com empresas para o desenvolvimento de equipamentos; Fiscalização realizada pelos funcionários responsáveis da obra; Mão de obra ociosa; o Efeito: Atraso no cronograma; Aumento do custo de produção; o Causa: Falta de aprovação da empresa para a realização do processo; Falta de energia no local de trabalho; Falta de equipamentos para a realização do processo; Falta de equipamentos de segurança; Furto de equipamentos; Inadequação da mão de obra existente; Inadequação de equipamentos para a realização do processo; Inadequação do local de trabalho; Necessidade de paralisação dada pela empresa; Problemas climáticos; o Controle: Nenhum; Necessidade de paralisação do processo; o Efeito: Atraso no cronograma; Aumento do custo de produção; Insatisfação do cliente; Mão de obra ociosa; o Causa: Falta de aprovação da empresa para a realização do processo; Falta de energia no local de trabalho; Falta de equipamentos para a realização do processo; Falta de equipamentos de segurança; Falta de mão de obra; Furto de equipamentos; Inadequação da mão de obra existente; Inadequação de componentes do módulo; Inadequação de equipamentos para a realização do processo; Inadequação do local de trabalho; Necessidade de paralisação dada pela empresa; Problemas climáticos; o Controle: Nenhum. Verificou-se que a maioria dos processos presentes no cronograma (ANEXO C) possuíam falhas potenciais similares. Com isso, para a simplificação da avaliação, de índices da Causa, Efeito e Controle, de falhas potenciais nos processos de implantação, no BD, foram analisados os 5 primeiros processos do cronograma onde foi possível estudar todas as 9 falhas distintas, como mostra no APÊNDICE C, adquirindo assim, os NPR mostrados na Tabela 6.1.

77 76 Tabela Número de Prioridade de Risco N Falha Potencial NPR 1 Furto de equipamentos Falta de energia no ambiente da empresa Necessidade de paralisação do processo Atraso no cronograma Falta de mão de obra adequada para a realização da tarefa 64 6 Inadequação de componentes do módulo 64 7 Mão de obra ociosa 64 8 Falta/Inadequação de equipamentos para a realização do processo 56 9 Acidentes de trabalho 40 Para a seleção das falhas potenciais que foram estudadas, foi utilizado o Gráfico de Pareto 80/20, conforme mostra a Figura 6.1. Figura Gráfico de Pareto 80/20 Para a análise do gráfico, inicialmente, foi feita uma linha vermelha que vai do valor 80%, no eixo que tem os percentuais acumulados, até o encontro da curva que representa este acúmulo e, em seguida, foi feita outra linha, paralela ao eixo dos percentuais, até o eixo horizontal. Com isso, pode-se concluir que as falhas potenciais 1, 2, 3 e 4 devem ser priorizadas por representarem mais de 80% do total do NPR.

78 77 Observado que as 4 primeiras falhas foram as mais criticas para processo do projeto de automação, foram realizadas reuniões para propor Ações Recomendadas para estas falhas, como mostra a Tabela 6.2, e, também foram descrito as Tarefas (Tabela 6.3) para concretização destas ações. Falha Potencial Furto de equipamentos Falta de energia no ambiente da empresa Necessidade de paralisação do processo Atraso no cronograma Tabela Ações Recomendadas Ação Recomendada Instalar câmera de segurança Solicitar a contratação de um vigia à empresa Utilizar contêiner para armazenar os equipamentos Utilizar um gerador de energia Reduzir o índice da Falha Potencial Furto de Equipamentos Fazer um estudo do clima Ação Recomendada Instalar câmera de segurança Solicitar a contratação de um vigia à empresa Utilizar contêiner para armazenar os equipamentos Utilizar um gerador de energia Tarefa Tabela Tarefas Solicitar à empresa a instalação de câmeras Realizar a solicitação Contratar uma empresa de aluguel de contêiner Pegar a liberação para a entrada do contêiner na empresa Programar os dias que haverá a necessidade de utilização do gerador Firmar um contrato com uma empresa que alugue geradores de energia a diesel Fazer a aquisição do gerador Adquirir um veículo para o transporte do gerador Fazer a liberação da entrada do gerador Reduzir o índice da Falha Potencial Furto de Equipamentos Fazer um estudo do clima Calcular a probabilidade (porcentagem) de chuva do mês em relação aos anos anteriores Acrescentar os dias adicionais em relação a esta porcentagem para cada evento no cronograma (((Porcentagem Calculada) + 1)*(Prazo do evento))

79 78 Com a hipótese de que todas as Ações Recomendadas foram implantadas, foi realizado um novo estudo para estimar os novos NPR destes 4 riscos nas tarefas 2 Realizar a limpeza física da área, removendo os materiais que recobrem o piso do pátio e Adequar os contraventamentos, gerando um novo relatório, conforme mostra no APÊNDICE D. Com isso, obtendo os resultados estimados da Tabela 6.4 abaixo. Tabela Novos NPR Falha Potencial NPR Antes NPR Depois Redução Furto de equipamentos Falta de energia no ambiente da empresa Necessidade de paralisação do processo Atraso no cronograma Observa-se que o Furto de equipamentos obteve a maior diminuição do seu NPR, pois, inicialmente, esta falha potencial possuía um índice de severidade 8 (sistema deixa de funcionar), um índice de ocorrência 6 (ocorrência de falhas entre 6 a 10 vezes por mês) e um índice de detecção 10 (certamente não será detectado), com isso, tendo o seu NPR de 480. Após a hipótese de que a ação recomentada Instalar câmera de segurança seja aplicada, supôs-se, através de reuniões com os funcionários responsáveis, que foi possível reduzir o índice de detecção para 6 (provavelmente será detectado), pois, esta ação seria uma ação para a melhoria da detecção da falha. Com as ações Solicitar a contratação de um vigia à empresa e Utilizar contêiner para armazenar os equipamentos, foi possível supor uma redução no seu índice de ocorrência para 2 (chance remota de falha), onde, tais ações são medidas para minimizar a frequência da falha potencial. Com isso, tendo o seu novo NPR de 96, ou seja, houve uma redução de 384 do seu NPR. A falha potencial Falta de energia no ambiente da empresa obteve, também, uma considerável redução do seu NPR. Onde, após a hipótese de que a ação recomendada Utilizar um gerador de energia fosse implantada, foi deduzido que o índice da ocorrência de 6 (ocorrência de falhas entre 6 a 10 vezes por mês) para 1 (chance remota de falha), ou seja, caso ocorra a falta de energia, sempre haverá um gerador de energia disponível, com isso, 2 Tais tarefas foram selecionadas por apresentarem as 4 falhas potenciais desejadas da realiar o estudo.

80 79 sempre possuindo energia para a realização dos processos. Tendo assim, uma possível redução de 350 do seu NPR. A redução do NPR da falha potencial Furto de equipamentos acarretaria, consequentemente, a redução do NPR da falha potencial Necessidade de paralisação do processo, onde, tal redução seria mais especificamente na diminuição dos índices de ocorrência e detecção. Com isso, supondo uma redução de 6 para 5 nos dois índices e consequentemente reduzindo seu NPR de 288 para 200. Por fim, com a hipótese de que a ação recomendada Fazer um estudo do clima fosse implantada, o índice de ocorrência da falha potencial Atraso no cronograma reduziria por fazer com que tal cronograma fique mais preciso, ou seja, foi deduzido que a ação recomendada reduziria o índice de ocorrência de 8 (ocorrência de falhas entre 11 a 15 vezes por mês) para 6 (ocorrência de falhas entre 6 a 10 vezes por mês), pois, tal ação é uma medida para reduzir a ocorrência da falha potencial. Com isso, diminuindo seu NPR de 192 para 144.

81 80 7. CONCLUSÕES A metodologia FMEA proporcionou uma nova visão para a empresa em relação às tomadas de decisões para a redução das falhas potenciais. Após as suposições de que todas as ações recomendadas foram implantadas e as avaliações dos novos NPR após estas ações, foram possíveis estimar seus impactos nos processos através dos NPR antes e depois das ações recomendadas. A integração do Método FMEA com o BD nos forneceu uma otimização na gestão de dados do método estudado, pois, houve uma grande facilidade tanto na adição, quanto na exclusão, na análise e na divulgação destes dados devido ao modo formulário e modo relatório do Microsoft Office Access Com isso, simplificou-se a utilização e o entendimento desta ferramenta. Vale ressaltar que a utilização desta nova metodologia serve não só para este projeto, mas também para outras áreas onde o FMEA é aplicável. Além de ser uma ferramenta de melhoria contínua dos processos, este programa serviu para o gerenciamento de todos os processos, subprocessos e das tarefas das medidas implantadas devido à facilidade de modificar os dados pelos formulários e visualizar os mesmos em vários modelos de relatórios pré-programados. Por fim, podemos concluir que, a realização desta integração faz com que o Método FMEA, que é considerado como um documento vivo, por ser uma ferramenta de melhoria contínua, torne-se ainda mais vivo, ou seja, a integração com o SGBD faz com que o usuário tenha facilidade na modificação, na pesquisa, na visualização e na conservação dos dados deste método.

82 81 8. SUGESTÕES PARA TRABALHOS FUTUROS A metodologia FMEA é uma ferramenta de melhoria contínua, ou seja, ela tem por objetivo reduzir o NPR continuamente. Com isso, propõe-se atualizar este programa periodicamente a fim de reduzir os NPR de todas as falhas potenciais no processo de implantação. Além disso, recomenda-se, também, aprofundar nos estudos dos processos de instalação dos equipamentos e acrescentar outras novas falhas potenciais. Além de integrar o método FMEA com um Sistema Gerenciador de Banco de Dados (SGBD), visando à otimização do método, propõe-se integrar, também, outras ferramentas de controle da qualidade. Pois, tal integração facilita no entendimento da metodologia, na organização dos dados, na agilidade na procura de dados, na possibilidade de filtrar dados a fim de gerar relatórios específicos, na conservação de dados e entre outros. Com isso, podendo otimizar, ainda, outras ferramentas da qualidade.

83 82 9. REFERÊNCIAS AHIRE, C. P.; RELKAR, A. S. Correlating FMEA & Overall Equipment Effectiveness (OEE). Elsevier Ltd., Procedia Engineering, n. 38, p CANEDO, I. R. Banco de Dados I. Ciências da Computação - UCG. Disponível em: <http://professor.ucg.br/sitedocente/admin/arquivosupload/4483/material/banco%20dd%20 Dados%20I(1).pdf>. Acesso em: 23 ago CAPALDO, D. et al. FMEA (Failure Model and Effect Analysis) Disponível em: <http://www.numa.org.br/conhecimentos/conhecimentos_port/pag_conhec/fmeav2.html>. Acesso em: 27 ago COMISSÃO PARA ASSUNTOS DA QUALIDADE DA ANFAVEA. Análise de Modo e Efeitos de Falha Potencial (FMEA). Manual de Referência, p. FERNANDES, J. R. M.; REBELATO, M. G. Proposta de um Método para Integração entre QFD e FMEA. GESTÃO & PRODUÇÃO, v. 13, n. 2, p GIL, A. C. Como Elaborar Projetos de Pesquisa. 4. ed. São Paulo: Editora Atlas S. A., HEUSER, C. A. Projeto de Banco de Dados. 4. ed. Porto Alegre: Editora Sagra Luzzatto, INSTITUTO DA QUALIDADE AUTOMOTIVA. Análise de Modo e Efeito de Falha Potencial: FMEA. Manuais QS ª Edição. São Paulo, PALADY, P. FMEA: Análise de Modos de Falhas e Efeitos: Prevendo e Prevenindo Problemas Antes que Ocorram. São Paulo: IMAM, p. PALMIERI, M. P. S. M. et al. FMEA como Ferramenta da Qualidade: O Caso do Departamento de Embalagens de uma Indústria do Setor Farmacêutico. Encontro Nacional de Engenharia de Produção - ENEGEP. Rio de Janeiro, 2008.

84 83 ROSA, L. C.; GARRAFA, M. Análise dos Modos de Falha e Efeitos na Otimização dos Fatores de Produção no Cultivo Agrícola: Subprocesso Colheita da Canola. Gestão da Produção, São Carlos, v. 16, n. 1, p SCIPIONI, A. et al. FMEA Methodology Design, Implementation and Integration with HACCP System in a Food Company. Elsevier Science Ltd., Food Control, n. 13, p SILVA, E. L.; MENEZES, E. M. Metodologia da Pesquisa e Elaboração de Dissertação. 4. ed. Florianópolis: UFSC, SIMÕES, M. A. S. Caderno de Instrução de Montagem dos Módulos de Controle e Ensaio - USINA VII. Vitória, SLACK, N.; CHAMBERS, S.; HARRISON, A. et al. Administração da Produção. São Paulo: Atlas, p. STAMATIS, D. H. Failure Mode and Effect Analysis: FMEA from Theory to Execution. 2. ed. ASQC, Milwaukee: Quality Press, p. TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J. E. Introdução a Banco de Dados. DCC- IME-USP TOLEDO, J. C.; AMARAL, D. C. FMEA - Análise do Tipo e Efeito de Falha. GEPEQ Grupo de Estudos e Pesquisa em Qualidade. DEP - UFSCar. Disponível em: <http://www.gepeq.dep.ufscar.br/>. Acesso em: 29 ago XU, K. et al. Fuzzy Assessment of FMEA for Engine Systems. Elsevier Science Ltd., Reliability Engineering and System Safety, n. 75, p

85 84 ANEXO A - FORMULÁRIO FMEA Fonte: Toledo e Amaral (2011).

86 85 ANEXO B - FORMULÁRIO FMEA COM DEFINIÇÕES E FLUXOGRAMA Fonte: Toledo e Amaral (2011).

87 86 ANEXO C - CRONOGRAMA DE INSTALAÇÃO Fonte: Simões (2013).

FMEA - Análise do Tipo e Efeito de Falha. José Carlos de Toledo Daniel Capaldo Amaral GEPEQ Grupo de Estudos e Pesquisa em Qualidade DEP - UFSCar

FMEA - Análise do Tipo e Efeito de Falha. José Carlos de Toledo Daniel Capaldo Amaral GEPEQ Grupo de Estudos e Pesquisa em Qualidade DEP - UFSCar FMEA - Análise do Tipo e Efeito de Falha José Carlos de Toledo Daniel Capaldo Amaral GEPEQ Grupo de Estudos e Pesquisa em Qualidade DEP - UFSCar FMEA - Análise do Tipo e Efeito de Falha 1 1 Introdução

Leia mais

FMEA (Failure Model and Effect Analysis)

FMEA (Failure Model and Effect Analysis) Definição FMEA (Failure Model and Effect Analysis) Conceitos Básicos A metodologia de Análise do Tipo e Efeito de Falha, conhecida como FMEA (do inglês Failure Mode and Effect Analysis), é uma ferramenta

Leia mais

ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL

ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 5 ABORDAGEM RELACIONAL PROF. MS C. RICARDO ANTONELLO WWW.ANTONELLO.COM.B R PORQUE SER RELACIONAL? Hoje, há um claro predomínio dos SGBD relacionais, principalmente

Leia mais

a norma utiliza o termo PANE para expressar falha.

a norma utiliza o termo PANE para expressar falha. FMEA Prof. Andréa CONCEITO DE FMEA CONCEITO DE FMEA ABNT, na norma NBR 5462 (1994), adota a sigla originária do inglês FMEA (Failure Mode and Effects Analysis) e a traduz como sendo Análise dos Modos de

Leia mais

MSc. Daniele Carvalho Oliveira

MSc. Daniele Carvalho Oliveira MSc. Daniele Carvalho Oliveira AULA 2 Administração de Banco de Dados: MSc. Daniele Oliveira 2 CONCEITOS FUNDAMENTAIS DE BANCO DE DADOS Administração de Banco de Dados: MSc. Daniele Oliveira 3 Conceitos

Leia mais

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc.

PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL. Prof. Angelo Augusto Frozza, M.Sc. PROJETO DE BANCO DE DADOS -PROJETO CONCEITUAL Prof. Angelo Augusto Frozza, M.Sc. PROJETO CONCEITUAL Levantamento de requisitos Modelagem Conceitual Modelo ER PROJETO CONCEITUAL Parte integrante do Projeto

Leia mais

Unidade II ADMINISTRAÇÃO DE. Prof. Luiz Fernando de Lima Santos

Unidade II ADMINISTRAÇÃO DE. Prof. Luiz Fernando de Lima Santos Unidade II ADMINISTRAÇÃO DE BANCOS DE DADOS Prof. Luiz Fernando de Lima Santos Modelagem de Dados Coleção de ferramentas conceituais para descrever dados, suas relações e restrições Modelo Conceitual:

Leia mais

FMEA: ORIENTAÇÕES CONCEITUAIS PARA A APLICAÇÃO DE UMA FERRAMENTA DE ANTECIPAÇÃO DE FALHAS

FMEA: ORIENTAÇÕES CONCEITUAIS PARA A APLICAÇÃO DE UMA FERRAMENTA DE ANTECIPAÇÃO DE FALHAS FMEA: ORIENTAÇÕES CONCEITUAIS PARA A APLICAÇÃO DE UMA FERRAMENTA DE ANTECIPAÇÃO DE FALHAS Flávio Zorzan (FAHOR) fz000872@fahor.com.br Leandro Dorneles (URI-Santo Ângelo) leandro1902@gmail.com Marcos Eduardo

Leia mais

MODELAGEM DE DADOS MODELAGEM DE DADOS. rafaeldiasribeiro.com.br 04/08/2012. Aula 7. Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord

MODELAGEM DE DADOS MODELAGEM DE DADOS. rafaeldiasribeiro.com.br 04/08/2012. Aula 7. Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 7 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Aprender sobre a modelagem lógica dos dados. Conhecer os

Leia mais

BANCO DE DADOS. Fixação dos conteúdos Integridade Referencial Normalização Exercícios

BANCO DE DADOS. Fixação dos conteúdos Integridade Referencial Normalização Exercícios BANCO DE DADOS Fixação dos conteúdos Integridade Referencial Normalização Exercícios BANCO DE DADOS X SGBD Banco de Dados: Um "banco de dados" pode ser definido como um conjunto de "dados" devidamente

Leia mais

Banco de Dados 1 Prof. MSc Wagner Siqueira Cavalcante

Banco de Dados 1 Prof. MSc Wagner Siqueira Cavalcante Banco de Dados 1 Programação sucinta do curso:. Conceitos fundamentais de Banco de Dados.. Arquitetura dos Sistemas Gerenciadores de Banco de Dados (SGBD ou DBMS).. Características típicas de um SGBD..

Leia mais

CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1

CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1 CIn/UFPE Projeto Conceitual de BD - Prof. Robson Fidalgo 1 Projeto Conceitual de BD Transformação ER/Relacional Por: Robson do Nascimento Fidalgo rdnf@cin.ufpe.br CIn/UFPE Projeto Conceitual de BD - Prof.

Leia mais

FMEA - 4ª. EDIÇÃO (Análise dos Modos de Falha e de seus Efeitos)

FMEA - 4ª. EDIÇÃO (Análise dos Modos de Falha e de seus Efeitos) Curso e-learning FMEA - 4ª. EDIÇÃO (Análise dos Modos de Falha e de seus Efeitos) Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão

Leia mais

Fernando Fonseca Ana Carolina

Fernando Fonseca Ana Carolina Banco de Dados Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados Modelagem Conceitual Projeto do Banco de Dados Fernando Fonseca Ana Carolina Implementação do Banco

Leia mais

BANCO DE DADOS E BUSINESS INTELIGENCE. C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03)

BANCO DE DADOS E BUSINESS INTELIGENCE. C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03) MBA em Gestão de TI MÓDULO: BANCO DE DADOS E BUSINESS INTELIGENCE C/H: 20 horas (20/02, 25/02, 27/02, 04/03, 06/03) PROFESSOR: Edison Andrade Martins Morais prof@edison.eti.br http://www.edison.eti.br

Leia mais

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD Introdução 1. CONCEITOS BÁSICOS DE BD, SBD E SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Utilização de FMEA nos Processos de Desenvolvimento e Teste de Software

Utilização de FMEA nos Processos de Desenvolvimento e Teste de Software Utilização de FMEA nos Processos de Desenvolvimento e Teste de Software Bolívar Arthur Butzke 1, Karine Baiotto 1, Msc. Adalberto Lovato 1, Msc. Vera Lúcia Lorenset Benedetti 1 1 Sistemas de Informação

Leia mais

Modelo Entidade-Relacionamento

Modelo Entidade-Relacionamento Modelo Entidade-Relacionamento Banco de Dados I Fases do Projeto jt de BD Enunciado de requisitos entrevista com o usuário do banco de dados para entender e documentar seus requerimentos de dados. Projeto

Leia mais

Capítulo 5 Complemento. 5.1 Laudon, Cap. 5

Capítulo 5 Complemento. 5.1 Laudon, Cap. 5 Capítulo 5 Complemento Fundamentos de Bancos de Dados: Modelo de Entidade e Relacionamento - MER 5.1 Laudon, Cap. 5 Modelo mais utilizado: simplicidade e eficiência. Banco de dados relacional. Base: percepção

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1.

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1. Universidade Federal de Santa Maria Curso de Arquivologia Disciplina de Banco de Dados Aplicados à Arquivística Prof. Andre Zanki Cordenonsi Versao 1.0 Março de 2008 Tópicos Abordados Conceitos sobre Banco

Leia mais

ENGENHARIA DA COMPUTAÇÃO

ENGENHARIA DA COMPUTAÇÃO ENGENHARIA DA COMPUTAÇÃO BANCO DE DADOS I CONTEÚDO 2 Prof. Msc. Ricardo Antonello ABORDAGEM ER A primeira etapa do projeto de um banco de dados é a construção de um modelo conceitual ou modelagem conceitual.

Leia mais

AULA 11-12. Entidade-Relacionamento

AULA 11-12. Entidade-Relacionamento AULA 11-12 Modelo Conceitual, Lógico e Físico, Entidade-Relacionamento Curso: Técnico em Informática (Integrado) Disciplina: Banco de Dados Prof. Abrahão Lopes abrahao.lopes@ifrn.edu.br Modelos de banco

Leia mais

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão SISTEMAS DE BANCO DE DADOS Prof. Adriano Pereira Maranhão 1 REVISÃO BANCO DE DADOS I O que é banco de dados? Ou seja afinal o que é um SGBD? REVISÃO BD I REVISÃO DE BD I Um Sistema de Gerenciamento de

Leia mais

8.3. FMEA (Failure Mode and Effects Analysis)

8.3. FMEA (Failure Mode and Effects Analysis) seu produto nas unidades respectivas de cada grandeza, isto é, o produto tem $4,50 na característica "custo", 170 mm na característica "dimensão", e assim por diante. As colunas "concorrente };' e "concorrente

Leia mais

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Diretoria de Sistema - DS Superintendência de Arquitetura de Sistemas - SAS Gerência de Arquitetura de Informação - GAAS

Leia mais

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011 Banco de Dados Aula 1 - Prof. Bruno Moreno 16/08/2011 Roteiro Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza autodescritiva

Leia mais

MC536 Bancos de Dados: Teoria e Prática

MC536 Bancos de Dados: Teoria e Prática Universidade Estadual de Campinas - UNICAMP Instituto de Computação - IC MC536 Bancos de Dados: Teoria e Prática Aula #3 : MER e MER Estendido Profs. Anderson Rocha e André Santanchè Campinas, 1 de Agosto

Leia mais

Introdução à Banco de Dados

Introdução à Banco de Dados Introdução à Banco de Dados Introdução à Banco de Dados Agenda O que é Banco de Dados Como ele funciona Sistema Gerenciador de Banco de Dados Modelagem de Dados Modelo de dados Entidade-Relacionamento

Leia mais

Curso de Aprendizado Industrial Desenvolvedor WEB. Disciplina: Banco de Dados Professora: Cheli Mendes Costa Modelo de Dados

Curso de Aprendizado Industrial Desenvolvedor WEB. Disciplina: Banco de Dados Professora: Cheli Mendes Costa Modelo de Dados Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Banco de Dados Professora: Cheli Mendes Costa Modelo de Dados Modelo para organização dos dados de um BD. define um conjunto de conceitos para

Leia mais

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses

Leia mais

BARBIERI, Carlos. BI Modelagem de Dados. Rio de Janeiro: Infobook, 1994.

BARBIERI, Carlos. BI Modelagem de Dados. Rio de Janeiro: Infobook, 1994. Faculdade Pitágoras Unidade 1 Curso Superior de Tecnologia: Banco de Dados Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan Imagem: BARBIERI, Carlos. Material usado na montagem dos Slides INTRODUÇÃO

Leia mais

Banco de Dados Modelo Entidade-Relacionamento. Frederico D. Bortoloti freddb@ltc.ufes.br

Banco de Dados Modelo Entidade-Relacionamento. Frederico D. Bortoloti freddb@ltc.ufes.br Banco de Dados Modelo Entidade- Frederico D. Bortoloti freddb@ltc.ufes.br Modelo Entidade- Proposto por Peter Chen, em 1976 Baseado na percepção do mundo real Consiste de um conjunto de objetos básicos

Leia mais

1. Introdução ao Modelo Entidade-Relacionamento (MER)

1. Introdução ao Modelo Entidade-Relacionamento (MER) MODELAGEM CONCEITUAL 1. Introdução ao Modelo Entidade-Relacionamento (MER) Conforme comentado no capítulo anterior, o sistema de banco de dados deve prover uma visão abstrata de dados aos usuários, isolando-os

Leia mais

Banco de Dados 1 2º Semestre

Banco de Dados 1 2º Semestre Banco de Dados 1 2º Semestre Aula 07 Prof. Gladimir Ceroni Catarino gladimir@gmail.com SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL FACULDADE DE TECNOLOGIA SENAC PELOTAS o Uma coletânea de conceitos que

Leia mais

Ciclo de vida de um banco de dados relacional

Ciclo de vida de um banco de dados relacional Ciclo de vida de um banco de dados relacional 1. Formulação e análise de requisitos: a) Relacionamentos naturais entre os dados (independentes de processo). b) Requisitos de uso (dependentes de processo).

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Introdução Ilka Kawashita Material preparado :Prof. Marcio Vitorino Ementa do Curso n Banco de Dados n Sistemas de Apoio à Decisão (SAD) n ORACLE BANCO DE DADOS (BD) n Modelo Entidade

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

Modelo Entidade-Relacionamento. Prof. Antonio Almeida de Barros Jr.

Modelo Entidade-Relacionamento. Prof. Antonio Almeida de Barros Jr. Modelo Entidade-Relacionamento Prof. Antonio Almeida de Barros Jr. Conteúdo Contexto Histórico A Importância da Modelagem de Dados Projeto de Banco de Dados Modelagem Conceitual Projeto Lógico Projeto

Leia mais

PROPOSTA DE IMPLANTAÇÃO DE FMEA EM UMA EMPRESA DE MÁQUINAS - FERRAMENTA

PROPOSTA DE IMPLANTAÇÃO DE FMEA EM UMA EMPRESA DE MÁQUINAS - FERRAMENTA PROPOSTA DE IMPLANTAÇÃO DE FMEA EM UMA EMPRESA DE MÁQUINAS - FERRAMENTA Afrânio Quintino da SILVA 1 Denner TRINDADE 1, Eduardo Araújo de PAULA 1, Israel do Nascimento BATISTA 1 Jevion Prates MARTINS 1

Leia mais

Profa. Daniela Barreiro Claro

Profa. Daniela Barreiro Claro Profa. Daniela Barreiro Claro Modelar é criar representações do mundo real A modelagem relacional pode ser representada via MER (Modelo de Entidade Relacionamento) O MER define estruturas e restrições

Leia mais

CONHECIMENTOS ESPECÍFICOS

CONHECIMENTOS ESPECÍFICOS CONHECIMENTOS ESPECÍFICOS Acerca dos conceitos básicos de gerenciamento de projetos e considerando o PMBOK, julgue os itens a seguir. 51 No gerenciamento de um projeto, deve-se utilizar não apenas as ferramentas

Leia mais

Modelo Relacional. Modelo Relacional. Tabelas

Modelo Relacional. Modelo Relacional. Tabelas MODELO RELACIONAL Banco de Dados Relacional = consiste em uma coleção de tabelas ou relações, cada uma das quais com um nome único. 2 1 Tabelas Conjunto não ordenado de linhas (tuplas); Cada linha é composta

Leia mais

INF01145 - Fundamentos de Banco de Dados Exercícios sobre normalização

INF01145 - Fundamentos de Banco de Dados Exercícios sobre normalização INF045 - Fundamentos de Banco de Dados Exercícios sobre normalização Carlos A. Heuser 28 de Junho de 2006 Exercícios do Capítulo 5 do livro Exercício. Considere as seguintes alternativas de implementação

Leia mais

MÓDULO 7 Ferramentas da Qualidade

MÓDULO 7 Ferramentas da Qualidade MÓDULO 7 Ferramentas da Qualidade Os modelos de Qualidade Total apresentam uma estrutura teórica bem consistente, pois: não há contradições entre as suas afirmações básicas; há uma estrutura bem definida

Leia mais

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados -

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados - Banco de Dados Aula 02 Modelagem de Dados Roteiro Definição Evolução Projeto de BD Abstração Esquema e Instância Definição É uma representação, normalmente gráfica, de estruturas de dados reais. Auxilia

Leia mais

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE]

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE] 1/6 Banco de Dados O que é um Banco de Dados? Uma coleção de dados relacionados [ELMASRI/NAVATHE] Conjunto de dados integrados que tem por objetivo atender a uma comunidade específica [HEUSER] Um conjunto

Leia mais

APLICAÇÃO DO FMEA DE PROCESSO EM MANUFATURA DE LUMINÁRIAS

APLICAÇÃO DO FMEA DE PROCESSO EM MANUFATURA DE LUMINÁRIAS APLICAÇÃO DO FMEA DE PROCESSO EM MANUFATURA DE LUMINÁRIAS Fábio Ferraz PRODOCIO 1 Marivaldo Ferreira DA SILVA 1 Romulo André Della VECCHIA 1 Wellington Johnny DOMINGOS 1 Jorge Antonio Vaz GUERRA 2 RESUMO

Leia mais

Banco de Dados I. 1. Conceitos de Banco de Dados

Banco de Dados I. 1. Conceitos de Banco de Dados Banco de Dados I 1. Conceitos de Banco de Dados 1.1. Características de um Banco de Dados. 1.2. Vantagens na utilização de um BD. 1.3. Quando usar e não usar um Banco de Dados. 1.4. Modelos, Esquemas e

Leia mais

Disciplina: Unidade III: Prof.: E-mail: Período:

Disciplina: Unidade III: Prof.: E-mail: Período: Encontro 08 Disciplina: Sistemas de Banco de Dados Unidade III: Modelagem Lógico de Dados Prof.: Mario Filho E-mail: pro@mariofilho.com.br Período: 5º. SIG - ADM Relembrando... Necessidade de Dados Projeto

Leia mais

Disciplina de Banco de Dados Parte V

Disciplina de Banco de Dados Parte V Disciplina de Banco de Dados Parte V Prof. Elisa Maria Pivetta CAFW - UFSM Modelo de Dado Relacional O Modelo Relacional O Modelo ER é independente do SGDB portanto, deve ser o primeiro modelo gerado após

Leia mais

Banco de Dados I. Introdução. Fabricio Breve

Banco de Dados I. Introdução. Fabricio Breve Banco de Dados I Introdução Fabricio Breve Introdução SGBD (Sistema Gerenciador de Banco de Dados): coleção de dados interrelacionados e um conjunto de programas para acessar esses dados Coleção de dados

Leia mais

Modelo de Dados. Modelos Conceituais

Modelo de Dados. Modelos Conceituais Modelo de Dados Modelo para organização dos dados de um BD define um conjunto de conceitos para a representação de dados exemplos: entidade, tabela, atributo,... existem modelos para diferentes níveis

Leia mais

Introdução à Banco de Dados. Definição

Introdução à Banco de Dados. Definição Universidade Federal da Bahia Departamento de Ciência da Computação (DCC) Disciplina: Banco de Dados Profª. Daniela Barreiro Claro Introdução à Banco de Dados Definição Um banco de dados é uma coleção

Leia mais

Conceitos básicos. Aplicações de banco de dados. Conceitos básicos (cont.) Dado: Um fato, alguma coisa sobre a qual uma inferência é baseada.

Conceitos básicos. Aplicações de banco de dados. Conceitos básicos (cont.) Dado: Um fato, alguma coisa sobre a qual uma inferência é baseada. Conceitos básicos Angélica Toffano Seidel Calazans E-mail: angelica_toffano@yahoo.com.br Conceitos introdutórios de Modelagem de dados Dado: Um fato, alguma coisa sobre a qual uma inferência é baseada.

Leia mais

Engenharia do Produto

Engenharia do Produto Ministério da Educação Universidade Tecnológica Federal do Paraná Campus Curitiba Departamento de Eletrônica Engenharia do Produto Slides elaborados a partir de Rozenfeld et al. (2006) AULA 6 Favor colocar

Leia mais

Qualidade de Software

Qualidade de Software Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br A expressão ISO 9000 (International Organization for Standardization) designa um grupo de normas técnicas que estabelecem

Leia mais

TREINAMENTO ITAIM INTERPRETAÇÃO DA NORMA NBR ABNT ISO 9001:2008. Maria das Graças Ferreira mgferreira@prefeitura.sp.gov.

TREINAMENTO ITAIM INTERPRETAÇÃO DA NORMA NBR ABNT ISO 9001:2008. Maria das Graças Ferreira mgferreira@prefeitura.sp.gov. TREINAMENTO ITAIM INTERPRETAÇÃO DA NORMA NBR ABNT ISO 9001:2008 Maria das Graças Ferreira mgferreira@prefeitura.sp.gov.br 11 3104-0988 Este treinamento tem por objetivo capacitar os participantes para

Leia mais

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I CONCEITOS BÁSICOS 1. Conceitos básicos de BD, SBD e SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Projeto de Banco de Dados

Projeto de Banco de Dados Projeto de Banco de Dados Atividade de modelagem de dados em diversos níveis de abstração Modelagem conceitual (projeto conceitual) abstração de mais alto nível objetivo: representação dos requisitos de

Leia mais

FMEA. FMEA - Failure Mode and Effects Analysis (Análise dos Modos e Efeitos de Falha)

FMEA. FMEA - Failure Mode and Effects Analysis (Análise dos Modos e Efeitos de Falha) FMEA FMEA - Failure Mode and Effects Analysis (Análise dos Modos e Efeitos de Falha) Técnica auxiliar no projeto de sistemas, produtos, processos ou serviços. Flávio Fogliatto Confiabilidade 1 FMEA - Definição

Leia mais

Banco de Dados I. Introdução Conceitos

Banco de Dados I. Introdução Conceitos Banco de Dados I Introdução Conceitos Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Apresentação Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Ementa Conceitos Fundamentais de Banco de Dados; Características

Leia mais

Fundamentos de Bancos de Dados Prova 3

Fundamentos de Bancos de Dados Prova 3 Fundamentos de Bancos de Dados Prova 3 Prof. Carlos A. Heuser 26 de janeiro de 2004 Duração: 2 horas Prova com consulta Questão 1 (Construção de modelo ER - Peso 3) Deseja-se construir uma base de dados

Leia mais

Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001

Tradução livre do PMBOK 2000, V 1.0, disponibilizada através da Internet pelo PMI MG em abril de 2001 Capítulo 8 Gerenciamento da Qualidade do Projeto O Gerenciamento da Qualidade do Projeto inclui os processos necessários para garantir que o projeto irá satisfazer as necessidades para as quais ele foi

Leia mais

Este trabalho tem como objetivo propor um modelo multicritério para a priorização dos modos de falha indicados a partir de uma aplicação do processo

Este trabalho tem como objetivo propor um modelo multicritério para a priorização dos modos de falha indicados a partir de uma aplicação do processo 1 Introdução A atual regulamentação do setor elétrico brasileiro, decorrente de sua reestruturação na última década, exige das empresas o cumprimento de requisitos de disponibilidade e confiabilidade operativa

Leia mais

Aplicabilidade das Data: FMEA Falta de Energia Elétrica. 3º SEPAGE - Coren-SP 22/07/2011

Aplicabilidade das Data: FMEA Falta de Energia Elétrica. 3º SEPAGE - Coren-SP 22/07/2011 Aplicabilidade das Ferramentas Título da da Palestra: Qualidade Data: FMEA Falta de Energia Elétrica 3º SEPAGE - Coren-SP 22/07/2011 História dos Riscos Construção do Empire State 1930 102 andares Cenário

Leia mais

MODELAGEM DE DADOS TEORIA E PRÁTICA

MODELAGEM DE DADOS TEORIA E PRÁTICA MODELAGEM DE DADOS TEORIA E PRÁTICA ARAÚJO, M. A. P. 1. INTRODUÇÃO Modelagem de sistemas, tanto a nível funcional quanto de dados, é um requisito fundamental para a obtenção de produtos de software de

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Agenda Introdução Conceitos do Modelo Relacional Restrições de Integridade Básicas Esquema do BD Relacional Restrições

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 04 SGBD Sistemas Gerenciadores de Bancos de Dados Prof. MSc. Edilberto Silva edilms@yahoo.com Conceitos Básicos DADOS: são fatos em sua forma primária. Ex: nome do funcionário,

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Bancos de Dados. Conceitos F undamentais em S is temas de B ancos de Dados e s uas Aplicações

Bancos de Dados. Conceitos F undamentais em S is temas de B ancos de Dados e s uas Aplicações Conceitos F undamentais em S is temas de B ancos de Dados e s uas Aplicações Tópicos Conceitos Básicos Bancos de Dados Sistemas de Bancos de Dados Sistemas de Gerenciamento de Bancos de Dados Abstração

Leia mais

FERRAMENTAS DA QUALIDADE

FERRAMENTAS DA QUALIDADE FERRAMENTAS DA QUALIDADE FEMEA Análise do Modo e Efeito das Falhas Desenvolvido pela Professora Patrícia Roggero 1 Análise do Modo e Efeito das Falhas Desenvolvido pela Professora Patrícia Roggero 2 -

Leia mais

Faculdade Lourenço Filho - ENADE 2011-1

Faculdade Lourenço Filho - ENADE 2011-1 1. Quando se constrói um banco de dados, define-se o modelo de entidade e relacionamento (MER), que é a representação abstrata das estruturas de dados do banco e seus relacionamentos. Cada entidade pode

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados.

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Histórico Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Sistemas Integrados: racionalização de processos, manutenção dos

Leia mais

Diagrama de Entidade e Relacionamento

Diagrama de Entidade e Relacionamento Diagrama de Entidade e Relacionamento Através deste diagrama poderemos representar, de forma sucinta e bem estruturada, todos os elementos essenciais abstraídos no processo de análise de sistemas. Denominamos

Leia mais

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP Banco de Dados Introdução João Eduardo Ferreira Osvaldo Kotaro Takai jef@ime.usp.br DCC-IME-USP Importância dos Bancos de Dados A competitividade das empresas depende de dados precisos e atualizados. Conforme

Leia mais

Modelo Relacional. 2. Modelo Relacional (Lógico)

Modelo Relacional. 2. Modelo Relacional (Lógico) Modelo Relacional 2. Modelo Relacional (Lógico) Derivado do modelo conceitual; Depende do SGBD escolhido; Independe dos dispositivos de armazenamento; Primitivas: tabelas, linhas e colunas; Transformação

Leia mais

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS

UNIVERSIDADE VEIGA DE ALMEIDA CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS BANCO DE DADOS CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CURSO SUPERIOR DE TECNOLOGIA EM PROCESSAMENTO DE DADOS CLAUDIO RIBEIRO DA SILVA MARÇO 1997 2 1 - CONCEITOS GERAIS DE 1.1 - Conceitos Banco de Dados - Representa

Leia mais

Docente: Éberton da Silva Marinho e-mail: ebertonsm@gmail.com

Docente: Éberton da Silva Marinho e-mail: ebertonsm@gmail.com INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Introdução a Banco de Dados Docente: Éberton da Silva Marinho e-mail: ebertonsm@gmail.com 12/06/2013 Sumário Motivação da Disciplina

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Apostila de Banco de Dados

Apostila de Banco de Dados 1 Apostila de Banco de Dados 1.) Banco de Dados Definição: conjuntos de dados inter-relacionados que tem como objetivo atender a uma comunidade de usuários. A Informação é o valor fornecido pelo usuário

Leia mais

Administração de Bancos de Dados

Administração de Bancos de Dados Modelo Entidade-Relacionamento Prof. Rodrigo M. Silva Administração de Bancos de Dados 1 silvars@gmail.com Plano de Aula Modelos de Dados (Revisão) O Modelo Entidade-Relacionamento Entidades Atributos

Leia mais

Simulação Computacional de Sistemas, ou simplesmente Simulação

Simulação Computacional de Sistemas, ou simplesmente Simulação Simulação Computacional de Sistemas, ou simplesmente Simulação Utilização de métodos matemáticos & estatísticos em programas computacionais visando imitar o comportamento de algum processo do mundo real.

Leia mais

Comercial. Gestão da Qualidade

Comercial. Gestão da Qualidade Gestão da Qualidade Comercial Ferramentas da Qualidade: Ações preventivas são tomadas em problemas potenciais, aqueles que ainda não ocorreram, mas que podem vir a ocorrer no futuro caso não seja tomada

Leia mais

Modelagem de dados e uso do SGBD MySQL

Modelagem de dados e uso do SGBD MySQL CURSO DE VERÃO EM BIOINFORMÁTICA ESTRUTURAL Modelagem de dados e uso do SGBD MySQL Modelagem e projeto de banco de dados Arquitetura de três esquemas [1] USUÁRIOS Nível externo Visão externa Mapeamento

Leia mais

Banco de Dados I Ementa:

Banco de Dados I Ementa: Banco de Dados I Ementa: Banco de Dados Sistema Gerenciador de Banco de Dados Usuários de um Banco de Dados Etapas de Modelagem, Projeto e Implementação de BD O Administrador de Dados e o Administrador

Leia mais

SISTEMAS DE INFORMAÇÃO GERENCIAIS

SISTEMAS DE INFORMAÇÃO GERENCIAIS SISTEMAS DE INFORMAÇÃO GERENCIAIS Aluno: Luiza Cavalcanti Marques Orientador: Silvio Hamacher Introdução A modelagem e a utilização de bancos de dados em atividades gerenciais têm sofrido um aumento significativo

Leia mais

GBC043 Sistemas de Banco de Dados. Introdução. Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM

GBC043 Sistemas de Banco de Dados. Introdução. Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM GBC043 Sistemas de Banco de Dados Introdução Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM Página 2 Definição BD Def. Banco de Dados é uma coleção de itens de dados

Leia mais

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

Banco de Dados Modelo Conceitual, Lógico, Físico, Entidade- Relacionamento (ER) Hélder Nunes

Banco de Dados Modelo Conceitual, Lógico, Físico, Entidade- Relacionamento (ER) Hélder Nunes Banco de Dados Modelo Conceitual, Lógico, Físico, Entidade- Relacionamento (ER) Hélder Nunes Modelos de banco de dados Modelo de banco de dados é uma descrição dos tipos de informações que estão armazenadas

Leia mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

Ciclo de Desenvolvimento de Sistemas de BD

Ciclo de Desenvolvimento de Sistemas de BD Gerenciamento de Dados e Informação Fernando Fonseca Ana Carolina Valeria Times Bernadette Loscio Robson Nascimento Ciclo de Desenvolvimento de Sistemas de BD Investigação dos Dados Modelagem dos Dados

Leia mais

Banco de Dados I Introdução

Banco de Dados I Introdução Banco de Dados I Introdução Prof. Moser Fagundes Curso Técnico em Informática (Modalidade Integrada) IFSul Campus Charqueadas Sumário da aula Avaliações Visão geral da disciplina Introdução Histórico Porque

Leia mais

INTRODUÇÃO. Diferente de Bando de Dados

INTRODUÇÃO. Diferente de Bando de Dados INTRODUÇÃO Diferente de Bando de Dados 1 INTRODUÇÃO DADOS São fatos conhecidos que podem ser registrados e que possuem significado. Ex: venda de gasolina gera alguns dados: data da compra, preço, qtd.

Leia mais

Revisão de Banco de Dados

Revisão de Banco de Dados Revisão de Banco de Dados Fabiano Baldo 1 Sistema de Processamento de Arquivos Antes da concepção dos BDs o registro das informações eram feitos através de arquivos. Desvantagens: Redundância e Inconsistência

Leia mais

Modelo Entidade-Relacionamento DCC011. Modelo Entidade-Relacionamento. Processo de Projeto de Bancos de Dados

Modelo Entidade-Relacionamento DCC011. Modelo Entidade-Relacionamento. Processo de Projeto de Bancos de Dados DCC011 Introdução a Banco de Dados -06 Modelo Entidade-Relacionamento Mirella M. Moro Departamento de Ciência da Computação Universidade Federal de Minas Gerais mirella@dcc.ufmg.br Processo de Projeto

Leia mais

Banco de Dados I. Prof. Bal. Emerson Meneses Inocente

Banco de Dados I. Prof. Bal. Emerson Meneses Inocente Banco de Dados I Prof. Bal. Emerson Meneses Inocente Continuação aula 1 Arquitetura de SGBD Relacional ocaracterísticas: Independência de dados e programas; Suporte a múltiplas visões de usuários; Uso

Leia mais

Análise estruturada de sistemas

Análise estruturada de sistemas Análise estruturada de sistemas Prof. Marcel O que é Engenharia de software Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de

Leia mais