DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO · Sistemas de Informação Informação Empresarial...

DESENVOLVIMENTO DE SISTEMAS DE

INFORMAÇÃO

FEA/USP – EAD-0658

Prof. ANTONIO GERALDO DA ROCHA VIDAL

[email protected]

2011

FEA/USP – EAD-0658 – Desenvolvimento de Sistemas de Informação

Prof. Antonio Geraldo da Rocha Vidal

II

SUMÁRIO

CONCEITOS BÁSICOS ............................................................................................................................... 1

A NECESSIDADE DE INFORMAÇÃO ............................................................................................................... 1 O CONCEITO DE SISTEMA ............................................................................................................................ 2 A EMPRESA COMO UM SISTEMA .................................................................................................................. 4

SISTEMAS DE INFORMAÇÃO ................................................................................................................. 5

INFORMAÇÃO EMPRESARIAL ....................................................................................................................... 5 DECISÕES EMPRESARIAIS ............................................................................................................................ 6 TIPOS DE SISTEMA DE INFORMAÇÃO............................................................................................................ 7

Sistemas de Informação Operacionais ................................................................................................... 7 Sistemas de Informação Gerenciais ....................................................................................................... 8

REQUISITOS DE UM SISTEMA DE INFORMAÇÃO ............................................................................................ 8 COMPONENTES DE UM SISTEMA DE INFORMAÇÃO ..................................................................................... 10 PROBLEMAS ORGANIZACIONAIS E SISTEMAS DE INFORMAÇÃO ................................................................. 10

DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO .............................................................. 11

INTRODUÇÃO ............................................................................................................................................. 11 Etapa 1 Análise dos Processos de Negócio .................................................................................... 12 Etapa 2 Análise de Informações ..................................................................................................... 12 Etapa 3 Definição da Interface com os Usuários ........................................................................... 13 Etapa 4 Análise de Regras do Negócio .......................................................................................... 13 Etapa 5 Definição dos Módulos do Sistema ................................................................................... 14

ANÁLISE DE PROCESSOS ...................................................................................................................... 15

INTRODUÇÃO ............................................................................................................................................. 15 FATORES CRÍTICOS DE SUCESSO ................................................................................................................ 16 A ORGANIZAÇÃO POR PROCESSOS ............................................................................................................. 17 DEFINIÇÃO DE PROCESSO .......................................................................................................................... 19 TIPOS DE PROCESSOS DE NEGÓCIO ............................................................................................................ 21 FASES DA ANÁLISE DE PROCESSOS DE NEGÓCIO ....................................................................................... 21 RESULTADO DA ANÁLISE DE PROCESSOS .................................................................................................. 22 PROJETO DO NOVO PROCESSO ................................................................................................................... 23 CARACTERÍSTICAS DOS NOVOS PROCESSOS .............................................................................................. 24 MODELAGEM DE PROCESSOS DE NEGÓCIO ................................................................................................ 24

Introdução ............................................................................................................................................ 24 O BPMN ............................................................................................................................................... 25 Símbolos do BPMN .............................................................................................................................. 33 Objetos de Conexão ............................................................................................................................. 37 Artefatos ............................................................................................................................................... 37 Atividades ............................................................................................................................................. 38 Decisões (Divergência e Convergência de Fluxos) ............................................................................. 40

ANÁLISE DE INFORMAÇÕES ............................................................................................................... 41

INTRODUÇÃO ............................................................................................................................................. 41 NECESSIDADES DE INFORMAÇÃO ............................................................................................................... 42



III

Introdução ............................................................................................................................................ 42 Definição de Classes de Dados ............................................................................................................ 46 Definição dos Requisitos de um Sistema de Informação...................................................................... 48

BANCOS DE DADOS ................................................................................................................................... 50 Introdução ............................................................................................................................................ 50 Estrutura de uma Base de Dados ......................................................................................................... 52 Projeto de Bancos de Dados ................................................................................................................ 56

MODELAGEM DE DADOS ........................................................................................................................... 57 Introdução ............................................................................................................................................ 57 Relacionamentos Um-para-Um ........................................................................................................... 60 Relacionamentos Um-para-Muitos ...................................................................................................... 62 Relacionamentos Muitos-para-Muitos ................................................................................................. 63 Conjuntos de Relacionamentos ............................................................................................................ 64 Variação no Tempo .............................................................................................................................. 67 O Modelo Relacional de Dados (RDM - Relational Data Model) ....................................................... 68

DICIONÁRIO DE DADOS ............................................................................................................................. 68 Introdução ............................................................................................................................................ 68 Nome dos Dados .................................................................................................................................. 69 Sinônimos ............................................................................................................................................. 70 Homônimos .......................................................................................................................................... 70 Domínio ............................................................................................................................................... 70 Características dos Dados ................................................................................................................... 71 Dados-chave ........................................................................................................................................ 73

NORMALIZAÇÃO DE TABELAS DE DADOS .................................................................................................. 74 Introdução ............................................................................................................................................ 74 Primeira Forma Normal (1FN) ........................................................................................................... 75 Segunda Forma Normal (2FN) ............................................................................................................ 76 Terceira Forma Normal (3FN) ............................................................................................................ 78 Resultado da Normalização de Tabelas ............................................................................................... 79 Utilização de Índices ............................................................................................................................ 81 Desempenho do Sistema....................................................................................................................... 82

ANÁLISE DAS REGRAS DO NEGÓCIO ................................................................................................ 83

INTRODUÇÃO ............................................................................................................................................. 83 LÓGICA ESTRUTURADA ............................................................................................................................. 83 TABELAS DE DECISÃO ............................................................................................................................... 84 ÁRVORES DE DECISÃO ............................................................................................................................... 84 DIAGRAMAS DE TRANSIÇÃO DE ESTADOS ................................................................................................. 85

CONSTRUÇÃO DO MODELO DO SISTEMA ....................................................................................... 86

MÓDULOS DO SISTEMA ............................................................................................................................. 86 DIAGRAMA HIERÁRQUICO DO SISTEMA ..................................................................................................... 87 ESPECIFICAÇÃO DE MÓDULOS DO SISTEMA ............................................................................................... 88

Introdução ............................................................................................................................................ 88 Implementação por Uma Pessoa ......................................................................................................... 88 Implementação por Várias Pessoas ..................................................................................................... 89 Diálogo Sistema x Usuário .................................................................................................................. 89 Exemplo de Especificação de Módulo ................................................................................................. 90

BIBLIOGRAFIA ......................................................................................................................................... 93



1

Conceitos Básicos

A Necessidade de Informação

Ao procurar um número de telefone, conferir seu saldo bancário, escrever um relatório,

cuidar da velocidade do seu carro, escolher um filme para assistir no cinema, você está

processando dados.

O resultado de suas atividades de processamento de dados é a informação, que você usa

para conduzir suas atividades. Quanto melhor informado você estiver, mais facilmente

alcançará seus objetivos.

Ao menos três grandes motivos combinados tornam o processamento de dados e a

obtenção de informações tão importante nas organizações:

A competitividade crescente.

A administração científica.

A tecnologia da informação e comunicação (TIC).

A globalização da economia, a competitividade e o constante crescimento das

organizações, ao mesmo tempo e na mesma proporção em que afasta os administradores

de alto nível da supervisão mais direta das operações, tende a tornar cada vez mais crítico

o recurso informação e, conseqüentemente torna necessário o uso das tecnologias de

informação e comunicação (TIC) para auxiliá-los.

Imagine-se flutuando em um lugar completamente escuro e silencioso. Não há odores,

não existe a sensação de calor ou frio. O ar está parado, ou seja, você não sente sensação

alguma. Certamente você se sentiria mal e não saberia exatamente o que fazer. O que está

faltando? Informação! Você precisa ver, ouvir e cheirar, enfim sentir o seu lugar.

Assim como o seu corpo depende de ar, água e alimentos para sobreviver, você depende

de informação. E não apenas para sobreviver, mas para alcançar seus objetivos: aprender,

divertir-se, relacionar-se os outros, trabalhar, se afirmar na sociedade e, certamente,

administrar empresas.

A informação possui importância fundamental para todos nós, individual e coletivamente,

isto é, para as pessoas, famílias, associações, comércio, escolas, indústrias, governo,

enfim indivíduos e organizações de qualquer natureza.

A sobrevivência e o sucesso das organizações criadas pelo homem dependem

fundamentalmente da informação. Sem ela estarão a esmo no escuro e não poderão ser

administradas para alcançar seus objetivos.



2

O Conceito de Sistema

Um sistema pode ser definido como um conjunto de elementos ligados entre si por

cadeias de relações de modo a constituir um todo organizado que visa o alcance de

determinado objetivo. A idéia-chave é a ênfase na existência de um todo, ou seja, a idéia

de que tudo faz parte de um contexto maior. As relações e trocas entre as partes e o todo

caracterizam a dinâmica dos sistemas.

A palavra sistema envolve, de fato, amplo espectro de idéias. Pode-se pensar em sistema

solar, ou no corpo humano como um sistema. Diariamente deparamo-nos com sistemas

de transporte, sistemas de comunicação, sistemas biológicos, sistemas financeiros,

sistemas de informação etc.

Considera-se sistema um conjunto de elementos interdependentes, ou partes que

interagem formando um todo unitário e complexo que possui um objetivo. No entanto, é

preciso distinguir sistemas fechados, como as máquinas, um relógio etc., dos sistemas

abertos, como os sociais e biológicos: o homem, a sociedade, a empresa e a informação.

Os sistemas abertos envolvem a idéia de que determinadas entradas são introduzidas no

sistema e que, após processadas, geram certas saídas. Com efeito, a empresa vale-se de

recursos materiais, humanos, tecnológicos, financeiros e informações, de cujo

processamento resulta produtos e/ou serviços a serem fornecidos ao mercado.

Elementos do Sistema Empresa

Cada um destes elementos, por sua vez também pode ser visto como um subsistema.

Teremos, então, uma hierarquia de sistemas e subsistemas (ou níveis).



3

Elementos do Subsistema de Produção

As relações entre os componentes podem representar as mais variadas interações entre os

elementos, tais como autoridade, comunicação, precedência temporal, precedência

operacional, proximidade etc.

As características inerentes a todos os sistemas são:

Objetivo: a proposta fundamental de existência de qualquer sistema.

Componentes: partes do sistema que funcionam juntas para alcançar o objetivo.

Estrutura: a relação existente entre os componentes, definindo a fronteira

entre o sistema e seu ambiente.

Comportamento: a maneira como o sistema reage ao seu ambiente.

Ciclo Vital: nascimento, evolução, desgaste, obsolescência, envelhecimento,

substituição, reparo e "morte" do sistema.

Uma grande contribuição da teoria de sistemas foi a de estudar as interações do ambiente

com a empresa e como adaptá-la de modo eficiente às suas contingências.

O ambiente do sistema empresa do exemplo anterior contém os seguintes elementos:

Clientes

Fornecedores de matéria-prima

Mercado de mão-de-obra

Concorrentes

Fornecedores de recursos financeiros

Governo

Tecnologia

Etc.

Obviamente, uma empresa não pode ignorar as suas interações com estes elementos.



4

A aplicação destes conceitos aos sistemas produtivos permite-nos entender as

transformações recentes no ambiente de produção de bens e serviços. A perspectiva

sistêmica vê as organizações produtivas como redes de relações. Isso amplia

profundamente a visão organizacional. As funções claramente delimitadas e bem

definidas nos modelos prescritivos podem ser substituídas por padrões de relações. O

ambiente de produção modelado e normativo pode ser visto como uma dinâmica de

configurações. As estruturas verticais podem ser complementadas ou substituídas por

cadeias de processos horizontais, fluxos de insumos que se transformam em produtos

para responder às demandas dos clientes.

A Empresa como um Sistema

As empresas, portanto, devem ser estudadas como sistemas abertos e, para efeito deste

estudo, é conveniente subdividir o sistema empresa em subsistemas, alguns dos quais

podem ser apenas conceituais, isto é, sem existência física, mas apenas para uma melhor

compreensão e estudo do fenômeno.

Assim, podemos identificar nas empresas um subsistema de produção, cujas operações

resultam nos objetivos da empresa (fabricação de produtos ou prestação de serviços), um

subsistema de administração, cuja função é assegurar o eficaz funcionamento da

produção e um subsistema de informação, cuja função é captar, armazenar e fornecer as

informações necessárias para a empresa atingir eficazmente seus objetivos.

Ao considerarmos a empresa como um sistema, devemos nela identificar suas

características básicas, ou seja, objetivo, componentes, estrutura, comportamento e ciclo

vital.

Um objetivo típico das empresas é elevar o poder aquisitivo de seus proprietários através

de operações lucrativas. Este é um objetivo fundamental, de longo prazo, e estratégico em

sua natureza. Os objetivos de prazos mais curtos incluem os táticos, como aumento das

vendas de um determinado produto, redução de horas extras de funcionários e

aperfeiçoamento da manutenção de equipamentos. Existem objetivos operacionais

(rotineiros), tais como possuir o número adequado de funcionários para atendimento de

clientes, descobrir a causa do atraso na entrega de uma mercadoria, efetuar a venda de um

produto, fabricar um produto, manter o controle de estoques atualizado etc.

Os indivíduos de uma empresa são geralmente agrupados em subsistemas, com atividades

especializadas denominadas funções. Estes subsistemas são os componentes principais

de uma empresa. Algumas funções organizacionais encontradas com maior freqüência

incluem vendas, compras, finanças, contabilidade, produção, recursos humanos,

informática etc.

A estrutura de uma empresa é a maneira como autoridade e responsabilidades são

distribuídas entre os funcionários e administradores de seus componentes ou funções.



5

O comportamento das empresas é determinado por seus processos de negócio, que são

seqüências específicas de atividades a serem desenvolvidas em conseqüência da política

da empresa e da busca de seus objetivos. Os processos orientam os funcionários em como

efetuar as tarefas que cada componente da empresa requer para que seus objetivos sejam

alcançados.

Finalmente, o ciclo vital, que pode ser facilmente percebido através do surgimento de

novas empresas, sua evolução, crescimento e suas mudanças; e também através do

desaparecimento de empresas antigas, obsoletas ou mal administradas.

Sistemas de Informação

Informação Empresarial

Há muitas formas de se conceituar informação, dependendo do ângulo de observação e

do campo de conhecimento em estudo. Do ponto de vista mais específico de sistemas de

informação pode-se examiná-lo a partir do entendimento da informação como o resultado

do tratamento de dados. Entende-se neste caso um dado como um item elementar de

informação (um conjunto de idéias ou fatos expressos através de letras, dígitos ou outros

símbolos) que, tomado isoladamente, não transmite nenhum conhecimento, ou seja, não

possui significado intrínseco.

Partindo-se do conceito acima, pode-se definir informação como o resultado de fatos e

idéias relevantes, ou seja, dados, que foram transformados (processados) numa forma

inteligível para quem os recebe, e tem valor (utilidade) real ou aparente para a tomada de

decisões presentes e/ou futuras.

Dentro desse conceito de informação, um sistema de informação é um componente do

sistema organizacional, constituído por uma rede espalhada pela empresa inteira e

utilizada por todos os seus demais componentes. Seu propósito é obter informações

dentro e fora da empresa, torná-las disponíveis para os outros componentes, quando

necessitarem, e apresentar as informações exigidas pelos que estão fora (ambiente

externo).

Hoje, os sistemas de informação são essenciais para conduzir os negócios. A

sobrevivência e até mesmo a existência de organizações em muitos setores é difícil sem

largo uso da tecnologia da informação e comunicação. As empresas hoje utilizam os

sistemas de informação para atingir seis objetivos principais: a excelência operacional;

novos produtos, serviços e modelos de negócios; relacionamento mais estreito com

clientes e fornecedores; melhor tomada de decisão; vantagem competitiva; e

sobrevivência diária.

Um sistema de informação coleta, armazena e dissemina informações oriundas do

ambiente organizacional e das operações internas para apoiar as funções organizacionais,



6

e para auxiliar a tomada de decisão, a comunicação, a coordenação, o controle, a análise e

a visualização.

Os sistemas de informação transformam dados brutos em informações úteis por meio de

três atividades básicas: entrada, processamento e saída de dados. Sob a perspectiva

organizacional, um sistema de informação oferece uma solução para um problema ou

desafio enfrentado pela empresa e representa uma combinação de elementos humanos,

organizacionais e tecnológicos.

A dimensão humana dos sistemas de informação envolve questões tais como treinamento,

atitudes profissionais e comportamento da administração. A dimensão tecnológica

engloba hardware computacional, software e tecnologia de administração de dados, além

de tecnologia de rede e telecomunicações. A dimensão organizacional dos sistemas de

informação diz respeito a questões como hierarquia da organização, especializações

funcionais, processos organizacionais, cultura e grupos internos de interesse.

Decisões Empresariais

Os sistemas de informação, em geral, são utilizados para orientar a tomada de decisão

dentro de processos de negócio, em três níveis diferentes na administração de uma

empresa: o operacional, o tático (ou gerencial) e o estratégico. O nível operacional

envolve decisões pelas quais o administrador consegue que atividades específicas sejam

executadas de modo eficaz e eficiente. Já o nível tático envolve decisões pelas quais o

administrador assegura que os recursos são obtidos e usados de modo eficaz e eficiente

para que os objetivos da empresa sejam atingidos. Finalmente, o nível estratégico envolve

as decisões ligadas à definição ou mudança dos objetivos da empresa, identificação dos

recursos que deverão ser usados para atingir estes objetivos e políticas para aquisição e

uso destes recursos.

As decisões envolvidas nestes três níveis também podem ser divididas em três tipos,

conforme a necessidade de uso de intuição e criatividade ou de raciocínio lógico:

decisões estruturadas, decisões semi-estruturadas e decisões não-estruturadas.

As decisões estruturadas são, em geral, repetitivas (rotineiras). O tomador de decisão tem,

neste caso, paradigmas bastante precisos que lhe prescrevem quais as informações

necessárias e como utilizá-las no processo de decisão. Existem critérios objetivos para

medir a qualidade da decisão tomada e os seus resultados.

Já as decisões não-estruturadas são, em geral, únicas. O tomador de decisão está diante de

um problema novo para o qual não há experiência anterior que indique quais são as

informações relevantes, tampouco existe um consenso sobre um processo racional que

deve ser seguido na tomada de decisão. É difícil reconhecer uma decisão bem tomada.

Por fim, as decisões semi-estruturadas são as que possuem componentes estruturados e

não-estruturados. Pela sua natureza e apoiando-se na própria experiência, o tomador de



7

decisões procura transformar decisões não-estruturadas em estruturadas, já que deste

modo se torna mais fácil decidir ou então delegar o processo de tomada de decisão.

Estas duas classificações permitem uma caracterização bastante útil dos processos de

decisão e dos sistemas de informação resultantes. Observa-se que as decisões não-

estruturadas são mais freqüentes nos altos escalões da empresa, envolvidos com

planejamento estratégico, ao passo que no nível operacional predominam as decisões

estruturadas (por delegação dos níveis hierárquicos superiores).

Este processo de tomada de decisão dos administradores cria fluxos de informação entre

os diversos componentes da empresa. As informações estratégicas, táticas e operacionais

fluem em geral para cima e para baixo dos níveis de gerência da empresa. Outras

informações e ações criam fluxos laterais de um componente operacional da empresa

para outro. E ainda outras informações e ações criam fluxos entre as partes individuais

dentro dos componentes da empresa.

Qualquer sistema de informação empresarial, como o de contabilidade ou o de recursos

humanos, possui o mesmo comportamento: captar e transportar os dados ao longo da

estrutura da empresa (componentes da empresa) até o processamento, isto é, a aplicação

das regras do negócio e, a partir daí, produzir informações que desencadeiam outros

fluxos de informação dentro da empresa. Portanto, um sistema de informação integra-se

na empresa, em função de sua estrutura, sua política, seus processos, suas pessoas e o tipo

de decisão para a qual servirá de base.

Em vista disso, os sistemas de informação podem ser classificados em dois grandes

grupos:

Operacionais: Sistemas de Informação de Apoio às Operações

Gerenciais: Sistemas de Informação de Apoio à Gestão

Tipos de Sistema de Informação

Sistemas de Informação Operacionais

No nível operacional (do processo do negócio), os sistemas de informação são em geral

condicionados pela tecnologia da empresa e pela organização do seu processo produtivo.

Os sistemas de apoio às operações são tipicamente sistemas armazenadores de dados e

processadores de transações, ou seja, são redes de procedimentos rotineiros que servem

para o registro e processamento das transações correntes. Dentro desta categoria podemos

identificar como sendo típicos os de contabilidade, folha de pagamento, controle de

estoques, faturamento de vendas, e o financeiro (contas a receber e a pagar). Os sistemas

que se voltam para decisões referentes às operações envolvem o registro de muitos dados

e a integração e agregação de muitas transações, tais como planejamento de vendas,

controle da produção, controle de custos, controle de qualidade e contabilidade.



8

Sistemas de Informação Gerenciais

No nível gerencial, os sistemas de apoio à gestão, ou sistemas de informações gerenciais,

não são orientados para o processamento de transações rotineiras, mas existem para

auxiliar nos processos decisórios de planejamento e controle. Por essa razão, tais sistemas

devem ser flexíveis e podem ter uma assistemática freqüência de uso. Incluem sistemas

de previsão de vendas, de análises financeiras, orçamentos, isto é, sistemas voltados, de

modo geral, para o planejamento e controle das operações da organização. Os sistemas de

informação gerenciais, porém, são mais difíceis de serem construídos e avaliados, porque

suportam decisões nos níveis superiores da hierarquia das empresas. O modo de tomar

decisões é bastante variável e a sua avaliação é muito subjetiva, com forte dependência

do estilo do tomador de decisões.

Estes fatos indicam a necessidade de metodologias distintas para o desenvolvimento,

seleção e implantação de sistemas de informação operacionais e gerenciais, pois os

sistemas de informação devem ser estudados à luz dos processos transacionais ou

decisórios aos quais devem servir. Das peculiaridades destes processos pode-se, então,

derivar suas características mais adequadas.

Requisitos de um Sistema de Informação

Um sistema de informações eficaz e que utiliza adequadamente os mais recentes recursos

da tecnologia da informação e comunicação (TIC) deve satisfazer os seguintes requisitos:

Produzir as informações realmente necessárias, confiáveis, em tempo hábil e com

custo condizente, atendendo aos requisitos de processos de negócio operacionais e

gerenciais a que tais informações devem suprir.

Assegurar o atendimento dos objetivos da organização, de maneira direta, simples e

eficiente.

Integrar-se à estrutura da organização e promover a execução de processos de negócio

e apoiar a coordenação das diferentes unidades organizacionais (departamentos,

divisões e diretorias) por ele interligadas.

Ter um fluxo de procedimentos (internos e externos) racional, integrado, rápido e de

menor custo possível.

Contar com dispositivos de controle interno que garantam a confiabilidade das

informações de saída e adequada proteção aos dados controlados pelo sistema.

Ser fácil, simples, seguro e rápido em sua utilização.

Realizar cálculos numéricos em alta velocidade e de grande volume.

Fornecer comunicação rápida, exata, confiável e de baixo custo dentro de e entre

organizações, a qualquer hora e em qualquer lugar.

Armazenar enormes quantidades de informações em um pequeno espaço de fácil

acesso.



9

Permitir acesso rápido e de baixo custo a grandes quantidades de informações por todo

o mundo a qualquer hora.

Permitir a colaboração em qualquer lugar e em qualquer momento.

Aumentar a efetividade e eficiência das pessoas que trabalham em grupos em um lugar

ou em várias localizações.

Facilitar o trabalho em ambientes arriscados.

Automatizar tanto o processo de negócio semiautomático como as tarefas feitas

manualmente.

Facilitar a interpretação de vastas quantidades de dados.

Facilitar transações entre organizações e pessoas a qualquer hora em qualquer lugar.

Permitir a automação de tomada de decisões rotineiras e auxiliar a tomada de decisões

complexas.

Realizar todos os requisitos mencionados acima com um custo muito menor do que

quando feito manualmente.

Estes requisitos suportam os seguintes objetivos estratégicos dos negócios das

organizações:

1. Aprimorar a produtividade;

2. Reduzir custos;

3. Aprimorar processos de negócio;

4. Aprimorar a tomada de decisões;

5. Melhorar relacionamentos com clientes e fornecedores;

6. Desenvolver novos negócios.

A tecnologia de informação e comunicação (TIC), pela sua capacidade de armazenar

considerável volume de dados e de processá-los a grandes velocidades, pelos recursos

que oferece para aumentar a confiabilidade da informação e pelas possibilidades que

introduz de retenção, recuperação, pesquisa e transmissão de informações e comunicação

entre pessoas, devem ser aplicadas na implementação de sistemas de informação de alta

qualidade. Porém, a simples introdução de recursos de TIC nos sistemas de informação

de uma empresa, não representa uma garantia de solução de seus problemas. Por si só, a

TIC não assegura que a empresa passe a contar com sistemas de alta qualidade. Ao

mesmo tempo, porém, sem o seu emprego, certas necessidades e benefícios objetivados

no planejamento dos sistemas de informação empresariais não são factíveis, e até mesmo

pode não ser possível encontrar soluções viáveis para determinados problemas ou

processos de negócio.

A crescente competitividade e o constante crescimento das organizações, ao mesmo

tempo e na mesma proporção em que afasta seus dirigentes da supervisão mais direta das

operações, tende a tornar cada vez mais crítico o recurso da informação e,



10

conseqüentemente, necessário e cada vez mais intenso o uso das tecnologias da

informação e comunicação nas empresas.

No contexto atual, é imprescindível que as organizações apliquem a TIC em seus

sistemas de informação, com o risco de se não o fizerem tornarem-se menos

competitivas, menos ágeis e até mesmo não sobreviverem.

Componentes de um Sistema de Informação

Em um sistema de informação que utiliza os recursos da TIC, existem cinco componentes

essenciais: hardware, software, dados, processos e usuários. Estes, por sua vez, estão

inseridos num contexto mais amplo, de aplicação numa empresa ou organização, com o

objetivo de produzir determinados produtos ou serviços.

Hardware: composto pelos equipamentos de informática utilizados pelo sistema,

como computadores, impressoras, leitores óticos, mouse etc., e pelos recursos de

comunicação (redes) que os conectam entre si, como modems, linhas e cabos,

concentradores, roteadores, switches etc.

Software: composto pelos sistemas operacionais e diversos programas aplicativos de

computador que fornecem instruções específicas sobre as tarefas que o hardware deve

executar regras (operações de decisão e cálculo) e gerar a informação desejada.

Processos: compostos por conjuntos organizados e seqüenciais de atividades ou

tarefas a serem executadas que definem como os negócios da empresa ou organização

devem ser conduzidos, e que decisões precisam ser tomadas.

Dados: compostos por fatos e idéias relevantes que registrados e processados de

forma adequada permitem gerar a informação necessária para os processos de

negócio.

Usuários: compostos pelas pessoas que realizam as tarefas e atividades inerentes aos

processos de negócio e pelas pessoas que solicitam e utilizam informações para a sua

execução e o gerenciamento da organização.

Problemas Organizacionais e Sistemas de Informação

A resolução de problemas organizacionais envolve quatro passos: identificação do

problema, propostas de solução, escolha de uma das alternativas de solução e

implantação da solução escolhida.

A identificação do problema envolve descobrir o tipo de problema – se tem origem em

fatores humanos, organizacionais ou tecnológicos, ou, ainda, em uma combinação deles.

Para propor soluções, é preciso delinear as alternativas ao problema identificado. A

escolha implica selecionar a melhor solução, levando em conta os custos, recursos e

conhecimento disponíveis na organização. A implantação de uma solução de sistema de

informação implica em adquirir ou desenvolver o hardware e o software, testar o



11

software, oferecer aos funcionários treinamento e documentação de apoio, administrar a

mudança enquanto o novo sistema é introduzido na organização e avaliar o resultado. Em

todas as etapas, a resolução de problemas exige senso crítico e analítico, ou seja, que não

se forme um juízo até considerar as múltiplas perspectivas, alternativas e possibilidades

de resultados.

Os principais campos de estudo na área de negócios exigem o domínio de sistemas de

informação. Os estudantes de sistemas de informação precisam entender o papel central

que os bancos de dados desempenham na administração dos recursos de informação da

empresa e como as novas tecnologias de hardware e software podem elevar o

desempenho organizacional. Eles também devem ter capacidade de liderar o projeto e a

implantação de novos sistemas de informação, de trabalhar com outros profissionais da

empresa para assegurar que os sistemas atendam aos objetivos organizacionais e de

trabalhar com softwares aplicativos que oferecem novas soluções para os sistemas de

informação da organização.

As competências em sistemas de informação comuns a todas as carreiras da área de

negócios incluem a compreensão de como os sistemas de informação ajudam as empresas

a atingir os objetivos organizacionais mais importantes; a noção do papel central dos

bancos de dados; conhecimentos sobre análise de informação e inteligência empresarial;

sensibilidade a questões éticas, sociais e legais levantadas pelos sistemas; e capacidade de

trabalhar com especialistas em tecnologia e outros profissionais da empresa no projeto e

desenvolvimento de sistemas.

Desenvolvimento de Sistemas de Informação

Introdução

Uma das abordagens para o desenvolvimento de sistemas de informação empresariais é a

“regra dos três passos” que começa com a análise dos processos de negócio da

organização, passa então para a análise das entidades e eventos que os processos

abrangem e sobre os quais precisam de informação e termina com a análise do

relacionamento entre os dados que compõem as informações necessárias aos processos de

negócio que o sistema deve apoiar.

Perguntas que devem ser feitas:

Quais informações são entrada para o processo?

Quais informações são modificadas ou geradas durante o processo?

O que acontece com as informações depois do processo ter sido concluído?

Quais informações para planejamento e controle o processo produz?

Quais informações são utilizadas para avaliar o desempenho do processo?



12

Com base na “regra dos três passos” e para responder a estas perguntas vamos

desenvolver um sistema de informação através das seguintes etapas:

Etapa 1 Análise dos Processos de Negócio

Definição e caracterização dos processos de negócio que serão beneficiados pelo sistema

de informação, isto é, cujas atividades serão executadas ou automatizadas com base nas

informações fornecidas pelo sistema. Nesta etapa se define a abrangência do sistema de

informação, através da especificação dos processos de negócio que serão por ele

atendidos.

Uma vez que todos os processos de negócio de uma organização estão relacionados e

trocam informações uns com os outros, dentro do processo global que é a própria

organização, uma tendência natural nesta fase é aumentar demasiadamente a abrangência

do sistema a ser desenvolvido, na tentativa de fazê-lo suprir as necessidades de

informação de todos os processos.

Para não correr este risco considere que assim como existe um processo de negócio

global que corresponde à organização como um todo, existe um sistema de informação

global que atende à organização como um todo. Porém, desenvolver o processo global ou

o sistema de informação global é uma tarefa extremamente complexa. Por esse motivo,

dentro do conceito de sistemas, eles devem ser divididos em partes, subprocessos ou

subsistemas, de forma a tornar mais simples sua análise e desenvolvimento, tomando-se

obviamente o cuidado de não se perder a visão do todo. Desta forma, assim como no caso

dos processos, o sistema de informação de uma empresa é composto por diversos

subsistemas integrados entre si e que são analisados, desenvolvidos e implementados

separadamente, cada um ha seu tempo, conforme as necessidades do negócio.

Nesta etapa, para os processos de negócio definidos como prioritários, é desenvolvido de

um conjunto de diagramas denominado Modelo de Processos de Negócio ou BPM

(Business Process Model). O BPM abrange todos os processos que serão beneficiados

pelo sistema de informação a ser desenvolvido. Para representar o fluxo de atividades e as

decisões dos processos o BPM utiliza uma linguagem gráfica denominada BPMN

(Business Process Model Notation) que estudaremos e utilizaremos para modelar os

processos.

Etapa 2 Análise de Informações

A partir do BPM, a segunda etapa consiste na elaboração de uma análise de entidades e

eventos cujas informações são necessárias para os negócios, ou seja, na definição dos

objetos de informação de interesse para a organização, cujos dados devem ser

armazenados e relacionados através das tabelas que formarão a base de dados do sistema

de informação a ser desenvolvido.

Para modelar a estrutura dos dados do sistema, é construído um diagrama contendo cada

entidade e evento identificado e linhas interligando-as, representando o relacionamento

entre elas. Uma das principais vantagens obtidas com a construção deste diagrama,



13

denominado Modelo Relacional de Dados ou RDM (Relational Data Model) é o

conhecimento do tipo de relacionamento existente entre as entidades ou tabelas que

comporão a base de dados do sistema de informação que apoiará os processos de negócio

da empresa.

A construção do RDM, que será estudada mais adiante, fornece uma visão de alto nível

das tabelas de dados envolvidas no sistema e ajuda a descobrir os objetos de informação

ou entidades que não foram detectados pelo BPM. Além disso, através do RDM são

definidas as chaves identificadoras ou primárias de cada tabela de dados, bem como suas

chaves estrangeiras, necessárias para estabelecer o relacionamento entre as entidades.

Durante a construção do RDM também é elaborada uma lista detalhada com as

características de todos os dados que serão armazenados em cada tabela que formará o

banco de dados do sistema de informação. Os dados deverão ser descritos em termos de

seus nomes completos, nomes código, tipo, tamanho, precisão, domínio (valores válidos),

regras de validação, máscaras de formatação etc., de forma a permitir a construção da

base de dados através do software gerenciador de banco de dados (SGBD) escolhido.

Etapa 3 Definição da Interface com os Usuários

A partir a construção do modelo de dados do sistema de informação, nesta etapa são

construídos modelos de formulários para entrada e saída de dados, que correspondem à

interface do sistema com os usuários. Os formulários de entrada normalmente

correspondem a telas ou páginas eletrônicas, contendo títulos e campos de dados, através

das quais os usuários poderão alimentar o sistema de informação com dados. Os

formulários de saída correspondem a consultas a informações efetuadas pelos usuários.

As consultas normalmente apresentam seus dados aos usuários através de telas ou

relatórios contendo listas ou relações de dados que atendem suas necessidades de

informação.

As consultas e os modelos de formulários e de relatórios são construídos através de

ferramentas automatizadas normalmente associadas ao banco de dados do sistema de

informação.

Etapa 4 Análise de Regras do Negócio

A partir da análise de processos e da análise das informações, a quarta etapa consiste na

análise das regras de negócio necessárias para a execução do processo, e que deverão ser

automatizadas pelo sistema de informação. Ou seja, na definição das decisões, cálculos e

outros processamentos que traduzam as políticas e as regras que definem a forma como

os processos de negócio devem ser conduzidos. Automatizar estas regras através do

sistema de informação geralmente aumenta o desempenho e a qualidade do processo.

As regras que definem a condução dos processos de negócio podem ser modeladas

através de várias técnicas, porém, estudaremos apenas as mais utilizadas: Lógica

Estruturada, Tabela de Decisão, Árvore de Decisão e Diagrama de Transição de Estados.



14

Etapa 5 Definição dos Módulos do Sistema

Na quinta e última etapa do desenvolvimento de um sistema de informação, a partir dos

resultados das etapas anteriores, dividimos o sistema de informação em módulos, ou seja,

em partes que serão desenvolvidos como unidades individuais.

A definição dos módulos que comporão o sistema de informação é representada em

forma de um diagrama hierárquico (a árvore do sistema) que traduz a hierarquia de

operação ou execução do sistema. Cada módulo, e suas correspondentes operações, será

executado através de listas ou "menus de opções". O diagrama hierárquico de módulos do

sistema deve representar a divisão e a hierarquia dos módulos que comporão o sistema e a

forma como suas operações serão desencadeadas de acordo com as necessidades de

informação dos processos de negócio.

Após a definição da árvore ou diagrama hierárquico do sistema, deve ser elaborado um

protótipo ou uma especificação detalhada de cada módulo definido, necessária para

construí-lo através de ferramentas de desenvolvimento de software (linguagens de

programação, gerenciadores de bancos de dados etc.). Como estudaremos mais adiante, a

especificação dos módulos deve constar de:

Um trecho detalhado do BPM do sistema no qual o módulo se encaixa no restante

do sistema;

Um trecho detalhado do RDM com as tabelas de dados utilizados pelo módulo;

Um trecho da árvore do sistema através da qual o módulo poderá ser acessado e

suas operações executadas;

A definição da interface com os usuários, isto é, os formulários e relatórios

envolvidos na execução do módulo e que serão utilizados pelos usuários;

As definições relativas às funções e operações a serem implementadas pelos

processos que compõem o módulo em questão, retratando as regras de negócio ou

lógica necessária, a ser implementada nos programas de computador;

As definições relativas ao diálogo do sistema com o usuário.



15

Etapas do Desenvolvimento de Sistemas de Informação

Análise de Processos

Introdução

A dinâmica imposta por uma economia estável e globalizada coloca os sistemas de

informação como diferencial competitivo para a sobrevivência das empresas no mercado.

A compreensão das necessidades do negócio, transformando-os em requisitos sistêmicos

transformou-se no grande desafio para os administradores conseguirem manter o seu

negócio competitivo e permitir a exploração ou a descoberta de novas oportunidades.

As empresas têm sentido cada vez mais a necessidade de compreender os mecanismos

que conduzem a empresa, como meio de garantir que a tomada de decisões seja feita de

maneira ágil e com mínimo de risco. A habilidade de modelar os seus processos,

permitindo que a organização conheça detalhadamente suas áreas de negócio, facilita

quaisquer esforços visando melhoria de desempenho, seja do ponto de vista monetário,



16

quantitativo, ou qualitativo, além de possibilitar o uso inteligente da TIC na busca do

sucesso organizacional.

O cenário de negócios atual exige das organizações:

Flexibilidade para mudanças;

Ação rápida;

Conhecimento dos processos que conduzem o negócio;

Utilização de inovações tecnológicas.

Fatores Críticos de Sucesso

Um dos mais relevantes aspectos a serem analisados no posicionamento estratégico de

qualquer empresa refere-se aos fatores fundamentais para o sucesso no seu ramo de

atividade.

Um número muito grande de fatores influi no desempenho de uma empresa. Por exemplo,

ter a contabilidade mensal encerrada dentro dos limites de prazos estabelecidos, e com

exatidão nas informações, é uma das principais preocupações dessa área funcional da

empresa; da mesma forma, ter a folha de pagamento pronta e correta alguns dias antes da

data de pagamento dos funcionários é um a das principais preocupações da área de

pessoal. Entretanto, apenas alguns fatores respondem pela quase totalidade das

possibilidades de sucesso de qualquer negócio. Esses fatores são essenciais para o bom

desempenho da empresa e, por isso, são denominados fatores críticos de sucesso ou

fatores chave de sucesso. Por mais que uma empresa possa ser eficiente em suas diversas

áreas operacionais, se ela estiver vulnerável em fatores críticos de sucesso, é muito

provável que não consiga ter a competitividade necessária para garantir sua

sobrevivência.

Para uma loja comercial, podem ser considerados os seguintes fatores críticos de sucesso:

Localização.

Variedade de produtos e marcas.

Preços e crédito para os clientes.

Conforto do cliente para realizar suas compras.

As seguintes características fundamentais são típicas para os fatores críticos de sucesso

(FCS) de uma empresa:

São poucos.

Têm importância vital para a organização.

São diferenciadores entre organizações.



17

Têm grande influência sobre as relações da empresa com o ambiente, principalmente

com os mercados atingidos ou pretendidos.

São características do ramo ou categoria de produtos.

Podem estar distribuídos pelas diversas atividades operacionais da empresa,

principalmente por aquelas que representam as partes mais significativas de seus

processos operacionais.

Muitos dos FCS são relacionados às características da categoria de produtos em face

das necessidades básicas dos consumidores ou clientes e às utilidades por eles

percebidas.

Os principais pontos de pesquisa para encontrar e identificar os fatores críticos de sucesso

são:

Necessidades básicas para atender as utilidades fundamentais percebidas pelos

consumidores ou clientes.

Relações da empresa com o mercado.

Processos, tecnologias e custos.

Análise dos insumos vitais.

Capacidade de produção.

Capacidade financeira.

Porte e estrutura organizacional.

Relacionamento empresa x ambiente.

Como primeiro passo, a empresa deve, portanto, identificar claramente os seus objetivos,

os fatores críticos de sucesso para alcançá-los e os problemas existentes nos

procedimentos atuais.

A Organização por Processos

Um processo é simplesmente um conjunto de atividades estruturadas e medidas,

destinadas a resultar num produto especificado para um determinado cliente ou mercado.

É, portanto, uma ordenação específica das atividades de trabalho no tempo e no espaço,

com um começo, um fim e entradas (inputs) e saídas (outputs) claramente identificados:

uma estrutura para ação. A estrutura de processo é uma visão dinâmica da forma como

uma organização produz valor; os processos são a estrutura pela qual uma organização

faz o necessário para produzir valor para os seus clientes. Ver a organização a partir de

seus processos significa focar mais na ação (a atividade de trabalho) do que na estrutura

(as funções, os departamentos).

Uma organização pode ser vista como um grande processo que recebe insumos,

informações e recursos do ambiente, os processa e os devolve ao ambiente na forma de

produtos e serviços. O processo organização também pode ser visto como um conjunto de



18

processos menores, operacionais e gerenciais, que se desdobram em etapas, e que por sua

vez se subdividem em atividades e estas em tarefas que devem ser executadas pelas

pessoas para o alcance dos objetivos.

Conceito Definição

Atividade Termo genérico para o trabalho desempenhado pela organização.

Processos, subprocessos e tarefas são tipos de atividades.

Tarefa Tarefa é uma atividade atômica incluída num processo. Num modelo

de processos, a tarefa é o desdobramento mais detalhado do trabalho

executado no processo.

Processo Qualquer atividade desempenhada no interior da organização. No

modelo de processos, é retratada como uma rede constituída por

outras atividades em fluxo e por seus respectivos controles de

seqüenciamento (eventos e junções). Um processo de negócio contém

um ou mais processos.

Evento Algo que “acontece” no curso do processo de negócio, influenciando

seu fluxo. Sempre há o evento inicial, o evento final e as muitas vezes

também há eventos intermediários.

As pessoas que atuam na organização podem ser fontes de processos e/ou participantes de

processos. Normalmente é mais conveniente avaliar processos do que avaliar pessoas,

pois a avaliação de processos reforça o caráter sistêmico e complementar do conjunto de

pessoas.

O desempenho dos processos de uma organização deve ser avaliado sistematicamente, de

forma a se poder avaliar adequadamente o desempenho da organização como um todo.

As melhorias de desempenho a serem alcançadas precisam ser quantificadas e para isso é

necessário comparar padrões desejados de desempenho e indicadores de desempenho

para cada processo da organização.

Em princípio sempre é possível melhorar processos, mas para isso é necessário:

Modelar os processos de modo a atender eficazmente os objetivos da organização;

Direcionar os processos da organização ao atendimento dos clientes – internos

e/ou externos;

Utilizar recursos, ferramentas e inovação para aumentar a eficiência de processos;

Capacitar as pessoas a fazerem certo desde a primeira vez;

Conhecer como cada tarefa, executada por cada pessoa, se insere no processo

global da organização.

Os benefícios que podem ser obtidos da modelagem de processos de negócio

compreendem, entre outros:

Melhoria da satisfação do cliente (interno e/ou externo);

Melhoria da produtividade (redução de tempos e custos);



19

Melhoria da qualidade (de produtos e serviços);

Avaliação sistemática de desempenho (medição do desempenho);

Melhoria da comunicação interdepartamental;

Utilização eficaz de novas tecnologias;

Aumento da competitividade da empresa;

Melhoria do relacionamento interno e externo entre clientes e fornecedores.

Aumento da visibilidade do desempenho;

Trabalho integrado e em equipe.

A relação entre fornecedores e clientes de um processo é definida de forma que cada

atividade, tarefa, processo ou sistema sempre possui um cliente e um fornecedor:

Fornecedor: responsável pelas entradas (recursos e/ou insumos); pode ser interno

ou externo à organização.

Cliente: recebe as saídas (resultados, produtos e/ou serviços); pode ser interno ou

externo à organização.

Desta forma, a qualidade do produto ou serviço da organização pode ser vista como o

resultado da qualidade dos processos.

Definição de Processo

Um processo de negócio pode ser definido como um conjunto de atividades e tarefas

estruturadas, seqüenciais e medidas que transforma um ou mais tipos de entrada e cria um

produto ou serviço que tem valor para determinados clientes ou mercados.



20

Processos eficientes e eficazes possuem as seguintes características:

Repetição: é repetido diversas vezes o longo do tempo;

Estabilidade: é executado sempre da mesma forma;

Previsibilidade: pode ser planejado e controlado;

Mensurabilidade: pode ser medido e ter seu desempenho avaliado com base em

critérios e parâmetros pré-definidos;

Documentação: tem todas as atividades e tarefas que o compõem descritas de

forma que diferentes pessoas possam executá-las da forma prevista.

Elementos de um processo:

1. Nome do Processo

2. Escopo e Limites

3. Participantes

a. Clientes (internos e/ou externos)

b. Fornecedores (internos e/ou externos)

4. Requisitos de Entrada e Saída

5. Atividades

a. Tarefas

b. Decisões



21

6. Indicadores

a. Critérios e parâmetros

b. Medidas

7. Documentação.

Tipos de Processos de Negócio

De acordo com H. James Harrington e seus colegas no livro Business Process

Improvement Workbook (1997, p. 23-31) os principais tipos ou grupos de processos a

serem considerados para a gestão de negócios são:

1. Entender o mercado e os clientes.

2. Desenvolver visão e estratégia de negócios.

3. Projetar e desenvolver produtos e serviços.

4. Elaborar plano de vendas e vender produtos e serviços.

5. Produzir e entregar produtos e serviços.

6. Gerenciar serviços aos clientes.

7. Faturar e assistir clientes.

8. Desenvolver e gerenciar atividades de recursos humanos.

9. Gerenciar recursos de informações (sistemas de informação).

10. Gerenciar recursos físicos e financeiros.

11. Gerenciar meio ambiente, saúde e segurança.

12. Gerenciar relacionamentos externos.

13. Gerenciar conhecimento, melhorias e mudança.

Fases da Análise de Processos de Negócio

Há diversas técnicas ou procedimentos que podem ser utilizados para levantar

informações e descrever os processos de negócio de uma organização. Todas elas, no

entanto, têm a finalidade de promover a compreensão do analista de processos sobre a

ordem, a hierarquia e a seqüência lógica das atividades necessárias para a produção de

bens e/ou prestação de serviços.

Inicialmente deve-se buscar o entendimento do negócio da organização através de:

1. Definição de objetivos da organização;

2. Definição dos produtos e/ou serviços produzidos;

3. Definição de necessidades em relação à produção dos produtos e/ou serviços;

4. Definição dos processos utilizados para a produção dos produtos e/ou serviços e;

5. Definição de parâmetros ou critérios para medir desempenho e qualidade.



22

Após o entendimento do negócio, a análise dos processos estabelece e detalha a

seqüência de atividades de cada processo que converte uma entrada específica na saída

necessária (resultado), identificando as áreas, pessoas e recursos envolvidos, pontos que

geram impacto negativo sobre o processo.

Problemas são representados como a diferença entre a situação desejada e a situação

atual, geralmente envolvendo medidas de qualidade e desempenho.

Se existem problemas na execução dos processos, eles podem estar relacionados com

falhas na sua definição, inadequação das atividades ou a ocorrência de situações que

conduzam a erros.

Problemas são sinônimos de desperdícios:

a. Eliminar um problema significa eliminar suas causas básicas ou primárias.

b. Administrar um problema significa agir sobre suas causas secundárias.

Identificar um problema significa comparar uma situação real com uma situação desejada

(ideal) e, para que essa comparação seja possível, são necessários no mínimo:

a. Padrão para desempenho do processo;

b. Indicador do desempenho da situação real.

Solucionar um problema (eliminar suas causas básicas) significa comparar a situação

atual do processo (onde ele ocorre) com a situação desejada ou projetada e eliminar a

diferença existente entre elas.

Resultado da Análise de Processos

1. Identificação de Processos: a partir do entendimento dos negócios da organização.



23

2. Matriz Processo/Fornecedor/Cliente.

a. Detalha os produtos e/ou serviços finais e intermediários de processo.

b. Detalha os participantes (fornecedores e clientes internos e externos) de cada

processo.

c. Detalha as responsabilidades envolvidas em cada processo.

3. Modelo do Processo de Negócio (BPM – Business Process Model)

a. Diagrama do Processo: define o fluxo de atividades, unidades

organizacionais, tarefas, tempos, pessoas e interfaces que compõe o processo.

b. Diagrama de Informações: define o fluxo de informações sobre entidades

utilizadas no processo, detalhando seu recebimento, processamento, envio e

registro.

Projeto do Novo Processo

Após a análise do processo atual deve-se projetar um novo processo buscando

obviamente aprimorar o anterior, corrigindo falhas e problemas e aumentando seu

controle e desempenho. Para o projeto do novo processo deve-se:

Estabelecer metas de desempenho e qualidade para agregar valor para a

organização, tornando-a mais competitiva.

Elaborar a Matriz Cliente/Fornecedor do novo processo.

Elaborar o modelo (BPM) do novo processo considerando as correções de erros e

melhorias no processo atual.

Avaliar o novo processo (analisar solução de problemas antigos e a possibilidade

do surgimento de novos problemas).

Estabelecer um sistema de medição de desempenho.

Validar e ajustar o novo processo.

Elaborar plano de implantação do novo processo.

Elaborar matriz de controle do novo processo:

o Definir recursos e métodos para manter o processo sob condição

controlada.

o Definir parâmetros de controle, desempenho e qualidade.

o Definir faixas estabelecidas para os parâmetros.

o Definir responsabilidades pelas ações de controle.



24

Características dos Novos Processos

1. Vários serviços ou atividades são combinados em um.

2. Os trabalhadores tomam as decisões (equipes auto-gerenciadas).

3. As etapas do processo são realizadas em uma ordem natural.

4. Os processos podem ter variações.

5. O trabalho é realizado onde faz mais sentido.

6. Verificação e controles são reduzidos e otimizados.

7. A reconciliação e o re-trabalho são minimizados.

8. Um gerente possui um único ponto de contato.

9. Uso de novas tecnologias.

10. Definição clara do que deverá ser automatizado com uso da TI.

11. Visão do todo com responsabilidades bem definidas.

12. Garantia de informatização de um processo já racionalizado e preparado para usar

a TI.

13. Necessidades de suporte de sistemas de informação já identificadas (dados,

informações, políticas, normas, regras do negócio, procedimentos, etc.)

14. Redução do tempo para obtenção da visão global do negócio da organização.

Modelagem de Processos de Negócio

Introdução

Para a elaboração do modelo do processo de negócio utilizaremos uma notação gráfica

padronizada denominada BPMN - Business Process Modeling Notation que permite

descrever o fluxo lógico de atividades de um processo de negócio. Esta notação foi

especialmente projetada para coordenar a seqüência das atividades dos processos e as

mensagens que fluem entre os participantes das diferentes atividades. Por que é

importante modelar processos de negócio com BPMN?

1. BPMN é um padrão internacional de modelagem de processos aceito por toda a

comunidade.

2. BPMN é independente de qualquer metodologia para modelagem de processos.

3. BPMN cria uma ponte padronizada para diminuir a distância entre os processos de

negócio e sua execução.

4. BPMN permite a modelagem de processos de negócio de uma maneira unificada e

padronizada, facilitando seu entendimento por todas as pessoas da organização.



25

O BPMN

O Business Process Modeling Notation ou BPMN proporciona uma linguagem comum

para que as partes envolvidas no processo de negócio a ser modelado possam se

comunicar de forma clara, completa e eficiente. Desta forma BPMN define a notação e a

semântica de um Diagrama de Processos de Negócio (Business Process Diagram ou

BPD).

O BPD é um diagrama projetado para representar graficamente a seqüência de todas as

atividades que ocorrem durante um processo, baseado na tradicional técnica do

“fluxograma”, incluindo toda a informação adicional que se considerar necessária para a

análise.

O BPD é um diagrama concebido para ser usado pelos analistas de processos de negócio,

aqueles que desenham, controlam e gerenciam os processos. Dentro de um Diagrama de

Processos de Negócio (BPD) se utiliza um conjunto de elementos gráficos, que se

encontram agrupados em categorias.

Para introduzir o tema do BPMN, ao longo deste texto você será apresentado a uma série

de exemplos desenvolvidos em torno de um processo de “Solicitação de Crédito” de um

cliente para uma entidade financeira.

Um processo de solicitação de crédito consta basicamente de um registro da solicitação,

onde um cliente manifesta interesse em adquirir crédito, nesta primeira etapa inclui-se a

apresentação da solicitação e da documentação requerida pela entidade financeira. Em

seguida é realizada uma verificação da informação. Posteriormente vem a etapa onde se

realiza a análise e o estudo da solicitação de crédito e por último são executadas as

atividades referentes concessão do crédito e sua liberação para o cliente.

Como se pode observar neste exemplo, dentro de um Diagrama de Processos de Negócio

existe um conjunto de elementos gráficos que nos permite representar um processo de

negócio.



26

No exemplo acima podemos visualizar diferentes tipos de elementos que descrevem o

comportamento do processo, entre estes elementos encontramos as atividades que

representam o trabalho realizado, os eventos de início e de fim que indicam o início e o

fim do processo e os elementos de desvio do fluxo conhecidos no BPMN como “decisão”

que indicam uma divisão no caminho do fluxo de atividades de acordo com uma decisão

tomada. Estes elementos se encontram conectados por linhas de seqüência, que mostram

como flui o processo.

Elemento de Início

No início do processo de solicitação de crédito está inserido o símbolo de “evento de

início” indicando o seu início. Os processos podem se iniciar de distintas formas, o

BPMN provê diferentes tipos de eventos de inicio (simples, mensagem, sinal, entre

outros).

Elemento de Fim

Ao final do processo encontra-se o símbolo de “evento de fim", indicando o término do

processo. Como podemos observar no exemplo, o processo termina quando o solicitante

foi recusado, a solicitação de crédito foi reprovada, ou se realizou o desembolso do

crédito para o cliente.

Elemento de Desvio

O desvio utilizado no exemplo anterior é um desvio exclusivo, este desvio como

elemento de decisão se comporta como um “XOR”, isto é, das várias alternativas

apresentadas somente uma pode ser escolhida. Dentro do processo de solicitação de

crédito podemos observar dois exemplos do uso do desvio exclusivo, a princípio,

dependendo do resultado da verificação da informação do solicitante o fluxo tomaria um

caminho ou outro, se o resultado for “solicitante reprovado” o processo terminaria, mas

se solicitante for aceito o processo continua. No segundo desvio a decisão se baseia no

resultado da análise do crédito, já que se a solicitação foi recusada, se informa ao cliente

e se for aprovada se procede à realização da liberação.

Se analisarmos o processo de Solicitação de Crédito, podemos ver que existem atividades

que podem ser analisadas em mais detalhe, uma destas atividades é a verificação da

informação fornecida pelo solicitante, já que normalmente as entidades financeiras que

oferecem créditos realizam várias análises do solicitante, por exemplo, verificam se o

solicitante já é um cliente da entidade, se é um bom pagador ou pelo contrario se encontra

em alguma lista de clientes devedores. Finalmente consultam sua situação financeira.

As atividades podem ser compostas ou simples. No BPMN as atividades compostas são

conhecidas como subprocessos, e as atividades simples (atômicas) como tarefas.



27

Tarefa

Utiliza-se uma tarefa quando o trabalho realizado no processo não pode ser decomposto

em mais detalhes. Uma tarefa normalmente é executada por uma pessoa e/ou um sistema

de informação.

SubProcesso

Um subprocesso é uma atividade composta que é incluída dentro de um processo. Uma

atividade composta é representada por uma figura que inclui um conjunto de atividades e

uma seqüência lógica (processo) que indica que esta atividade pode ser analisada em mais

detalhe. Visualmente pode ser apresentada fechada (colapsada) ou aberta (expandida).

O diagrama do fluxo do processo de Solicitação de Crédito ficaria da seguinte maneira ao

se incluir a atividade de verificação de informação como um subprocesso.

O subprocesso de Verificação de Informação do Solicitante é o seguinte.

Também é possível visualizar o processo de solicitação de crédito com o subprocesso de

verificação de informação do solicitante expandido, da seguinte forma:



28

Adicionalmente, dentro do subprocesso de Verificação de Informação do Solicitante,

encontramos que as atividades de Verificação de Existência do Cliente, Consulta ao

Serviço de Proteção do Crédito e Consulta à Área de Crédito, são tarefas automáticas,

isto é, que são realizadas por um sistema de informação sem intervenção humana, pode

ser, por exemplo, uma aplicação automática ou um serviço Web. Para diagramar isto o

BPMN propõe um tipo de tarefa, chamado tarefa Automática (ou Service).

O subprocesso de Verificação de Informação seria visualizado da seguinte forma, com as

atividades Automáticas:

Outra das atividades do processo de Solicitação de Crédito que pode ser mais detalhada é

a Liberação do Crédito.

Se visualizamos o subprocesso de Liberação do Crédito no diagrama a seguir, podemos

observar que existem varias formas de liberar um crédito: depósito em conta,

refinanciamento de outro crédito ou carta de crédito. Estas formas não necessariamente

têm que ser excludentes, isto é, um crédito pode ser desembolsado usando somente uma

das formas disponíveis, ou usando diferentes combinações, por exemplo, uma parte com

depósito em uma conta e outra parte em carta de crédito. Para diagramar esta situação de

negócio utiliza-se o desvio inclusivo como elemento de decisão, esta decisão permitirá

ativar um ou vários caminhos dependendo dos dados do processo.



29

Uma vez liberado o crédito deve-se informar ao cliente o resultado, sem dúvida é

necessário que todas as formas de liberação que tenham sido utilizadas estejam

finalizadas para realizar a atividade de informar o resultado ao cliente, para isto se utiliza

o desvio inclusivo como elemento de convergência, (sincronizador) o que significa que

esperará a conclusão de todas as formas de liberação antes de continuar com o fluxo.

No exemplo anterior pode-se visualizar uma anotação dentro do diagrama de processo. O

BPMN prove diferentes símbolos que permitem incluir informação adicional sobre o

diagrama, e de esta forma fornece ao leitor maior detalhe sobre o processo.

Com o BPMN também é possível detalhar que atividades são automáticas (tarefas

automáticas) o que atividades são realizadas com ajuda de um sistema (tarefas de

usuário), o que atividades são realizadas manualmente (tarefas manuais), entre outras.

Dentro do subprocesso de Liberação de Crédito, as tarefas de Depósito em Conta, Carta

de Crédito e Refinanciamento de Outro Crédito são tarefas automáticas, isto é, são

realizadas por um sistema de informação sem intervenção humana. Além disso,

poderíamos especificar que a atividade de “Entregar Carta de Crédito” é uma tarefa

completamente manual e que a atividade “Completar Informação de Desembolso” é feita

com ajuda de um sistema de informação, portanto é utilizada uma tarefa de usuário.



30

Suponhamos que uma vez aprovado o crédito é necessário ser agendada uma data para a

liberação do crédito para o cliente. Portanto a liberação só pode ser efetivada no dia

acordado com o cliente, sendo necessário realizar uma espera antes de executar as tarefas

de desembolso. Para isso, o BPMN oferece o evento temporizador, que é um tipo de

evento intermediário que representa uma espera dentro do fluxo.

Retomando o processo de Solicitação de Crédito, é possível que em o momento da

solicitação o cliente não apresente todos os documentos requeridos, sem dúvida não é

possível continuar com o processo até que todos os documentos estejam completos.

Portanto, torna-se necessário incluir uma atividade de Recepção de Documentos. Sem

dúvida o cumprimento de esta atividade depende do cliente e não do funcionário da

entidade financeira. Para isto é possível utilizar um evento intermediário simples.

Em o caso anterior o evento intermediário Simples “Receber Documentos” representa

algo que pode ocorrer dentro do fluxo do processo e não depende do usuário, mas sim de

uma atividade externa.

Sem dúvida, a entrega de documentos é algo que pode ou não ocorrer dentro do processo,

isto é, o cliente pode não apresentar os documentos ou demorar tempo demais. Portanto,

pode ser necessário controlar o prazo a ser dado ao cliente para entregar os documentos e

desta forma poder dar prosseguimento para as atividades pendentes.



31

Para isto torna-se necessário diagramar dentro da Solicitação de Crédito a seguinte

situação: o cliente tem um prazo para realizar a entrega dos documentos, se este não for

cumprido, se desabilita o evento intermediário simples “Receber Documentos” e se

procede a contatar o cliente para dar prosseguimento. Sem dúvida se os documentos são

entregues pelo cliente dentro do prazo, se revisam os documentos e o tempo que controla

a entrega de documentos deixa de ser contato, isto é, se desabilita o evento intermediário

temporizador. Para diagramar esta situação, vamos a utilizar o desvio exclusivo baseado

em eventos, este desvio permite habilitar vários caminhos alternativos e só um deles será

executado; o primeiro que ocorrer desabilita os outros caminhos.

O processo seria visualizado da seguinte forma.

Por último, os diagramas de processos de negocio normalmente utilizam separadores

visuais indicando os papéis dos responsáveis pelas atividades de um processo. O BPMN

permite diagramar as diferentes áreas dos participantes que intervierem dentro do

processo, para isto vamos a utilizar faixas, e o processo ficaria da seguinte forma:



32

Como vimos através dos exemplos anteriores temos utilizado alguns elementos gráficos

do BPMN. Estes elementos se encontram classificados dentro de 4 categorias:

Objetos de Fluxo

São os principais elementos gráficos que definem o comportamento dos processos.

Dentro dos objetos de Fluxo encontramos:

1. Evento: é algo que acontece durante o curso de um processo de negócio, afeta o fluxo

do processo e usualmente possui uma causa e um resultado. Nos exemplos anteriores

utilizamos os eventos de inicio, fim e intermediários (temporizadores). Dentro do

BPMN existem muitas formas de se iniciar ou finalizar um processo e igualmente

existem muitas coisas que podem ocorrer durante o transcurso do processo, portanto

existem diferentes tipos de eventos de inicio, eventos de fim e eventos intermediários.

2. Atividade: representa o trabalho que é executado dentro de um processo de negócio.

As atividades podem ser compostas ou não, dentro dos exemplos utilizamos os dois

tipos de atividades existentes: tarefas (simples) e sub-processos (compostas). Como

podemos ver dentro do exemplo existem diferentes tipos de tarefas (simples,

automáticas, manuais, de usuário, entre outras) e de sub-processos (embutido,

reutilizável, etc.) que nos permitem diagramar com mais profundidade os processos

de negócio fornecendo mais informação e esclarecendo o leitor.

3. Desvio: são elementos do modelo que são utilizados para controlar a divergência e a

convergência do fluxo. Existem 5 tipos de desvios dentro do exemplo apresentado

neste texto: desvio exclusivo (XOR), desvio inclusivo, desvio baseado em eventos,

desvio paralelo e desvio complexo.



33

Objetos de Conexão

São os elementos usados para conectar os objetos do fluxo dentro de um processo. Dentro

de os exemplos utilizamos as linhas de seqüência, que conectam os objetos de fluxo, e as

associações, que são as linhas pontilhadas que nos permitem associar anotações dentro de

alguns fluxos. Existem 3 tipos de objetos de conexão: Linhas de Seqüência, Associações

e Linhas de Mensagem.

Canais

São elementos utilizados para organizar as atividades do fluxo em diferentes categorias

visuais que representam áreas funcionais, papéis ou responsabilidades: Raias e Faixas.

Artefatos

Os artefatos são usados para prover informação adicional sobre o processo. Dentro do

exemplo utilizamos algumas anotações. Existem 3 tipos: Objetos de Dados, Grupos e

Anotações.

Símbolos do BPMN

Eventos

Os eventos representam algo que acontece ou pode acontecer no decurso de um processo.

Eventos afetam o fluxo do processo e geralmente têm uma causa ou um impacto. Há três

categorias de eventos com base em como o fluxo do processo é afetado: eventos de

início, eventos intermediários e eventos de fim.

Evento Início

Indican a instância ou o início de um processo e não têm qualquer entrada de

seqüência de fluxo. Não especificam qualquer comportamento em particular.

São também usados para iniciar subprocessos.

Evento Sinal

Indicam que um processo é iniciado quando um sinal proveniente do outro

processo é capturado. Note que o sinal não é uma mensagem; mensagens têm

claramente definido quem enviou e quem recebeu.

Evento Condicional

Indica que um processo é iniciado quando uma condição de negócios torna-se

verdadeira.

Evento Mensagem

Indica que um processo é iniciado quando uma mensagem é recebida de outro

processo.



34

Evento Múltiplo

Indica que há muitas maneiras de se iniciar o processo. Apenas uma delas será

necessária.

Eventos Intermediários

Eventos intermédios indicam algo que ocorre ou pode ocorrer no decurso do processo,

entre seu início e fim. Podem ser usados dentro do fluxo de seqüência de atividades ou

anexados a uma atividade. Eventos intermediários podem ser usados para capturar ou

para lançar o disparador de eventos. Quando o evento é usado para capturar o marcador

do eventos não será preenchido, por outro lado, quando o evento intermediário é usado

para lançar o evento o marcador será preenchido.

Evento Vazio

Indica algo que ocorre ou pode ocorrer dentro do processo. Ele só pode ser

usado dentro do fluxo seqüencial do processo.

Evento Mensagem

Indica que uma mensagem pode ser enviada ou recebida. Se o evento for de

recepção, ele indica que o processo tem que esperar até que a mensagem seja

recebida. Esse tipo de evento pode ser usado dentro do fluxo seqüencial de

atividades ou anexado a uma atividade para indicar um fluxo de exceção.

Evento Temporizador

Indica um tempo de espera dentro do processo. Esse tipo de evento pode ser

usado dentro do fluxo seqüencial de atividades indicando uma espera de tempo

entre as atividades ou anexado a uma atividade para indicar um fluxo de

exceção quando um tempo limite ocorrer.

Evento Cancelamento

É usado somente em subprocessos de transações. Este evento é sempre

anexado ao subprocesso transacional e indica um fluxo alternativo que pode

ser executado quando o subprocesso de transação for cancelado.

Condicional

É usado quando o fluxo precisa esperar por uma condição de negócios a ser

efetivada. Ele pode ser usado dentro do fluxo seqüencial de atividades

indicando que se deve aguardar até que uma condição de negócios tenha sido

atendida.



35

Evento Sinal

É usado para enviar ou receber sinais. Se for um elemento dentro do fluxo

seqüencial de atividades de um processo pode enviar ou receber sinais. Se for

anexado a uma atividade, só pode receber sinais indicando uma exceção de

fluxo que é ativada quando o sinal é capturado.

Evento Link

É usado para conectar duas partes do processo.

Evento Múltiplo

Significa que existem vários gatilhos atribuídos para o evento. Se estiver

dentro do fluxo de seqüência de atividades pode ser uma "captura" do

disparador ou "recepção" de disparadores de eventos. Se for anexado a uma

atividade pode apenas "travar" o disparador. Quando usado para "receber" um

disparador, apenas um dos disparadores atribuídos será necessário. Quando

usado para "receber" o disparador todos eles serão lançados.

Evento Erro

É usado para capturar erros e lidar com eles. Esse tipo de evento só

pode ser usado anexado a uma atividade. Ou seja, caso ocorra um erro

durante a execução da atividade, o fluxo é desviado para o tratamento

deste erro.

Evento Compensação

Um evento intermediário de compensação permite que você manipule

compensações. Quando usado dentro do fluxo seqüencial de atividades de um

processo indica que uma compensação é necessária. Quando usado anexado a

uma atividade indica que esta atividade será compensada por outra quando o

evento for acionado.

Eventos Fim

Um evento final indica onde termina um processo. Um processo pode ter mais de um

evento final. Um evento final não tem saída fluxos de seqüência.

Evento Múltiplo

Indica que muitos resultados podem ser fornecido com o final do processo.

Todos os resultados devem ocorrer.



36

Evento Vazio

Indica que um caminho do processo chegou ao fim. Um processo só pode

terminar quando todas as rotas de fluxo chegarem a um fim.

Evento Sinal

Indica que um sinal é gerado quando o processo termina.

Evento Cancelamento

Só é usado em transações de subprocesso e indica que a transação deve ser

cancelada.

Evento Encerramento

Este evento termina o processo imediatamente. Quando uma das rotas do fluxo

chega ao seu final, indicando que o processo foi completamente concluído.

Evento Mensagem

Indica que uma mensagem é enviada para outro processo quando o processo

chega ao fim.

Evento Compensação

Indica que o processo foi concluído e que uma compensação é necessária.

Evento Erro

Indica que um erro nomeado é gerado quando o processo termina.

Pool

Um “pool” (piscina) é um contêiner de um

único processo. O nome do pool pode ser

considerado como o nome do processo.

Sempre há pelo menos um pool.



37

Raias

Uma raia é uma subdivisão de um “pool” e

representa um papel ou uma área

organizacional.

Objetos de Conexão

Fluxo de seqüência

É usado para mostrar a ordem em que as atividades serão realizada em um

processo. Ele é usado para representar a seqüência de objetos do fluxo, onde

podemos encontrar atividades, desvios e eventos.

Fluxo de Mensagem

Um fluxo de mensagens é usado para mostrar o fluxo de mensagens entre

duas entidades ou processos. Fluxos de mensagens representam mensagens,

não fluxo de controle. Nem todos os fluxos de mensagens são preenchidos

para cada instância do processo, também não existe uma ordem específica

para mensagens.

Associação

Uma associação é usada para associar informações e artefatos com objetos

de fluxo.

Artefatos

Permitem fornecer informações adicionais sobre um processo.

Anotação

Fornece informações adicionais sobre o processo, necessárias para

esclarecimentos ao leitor.



38

Grupo

É um mecanismo visual que permite o agrupamento de

atividades para fins de documentação ou análise.

Objeto de Dados

Fornece informações sobre a entrada e saída de dados (informações) de uma

atividade. Ou seja, documentos, relatórios e outros dados usados, gerados ou

atualizados durante a execução das atividades do processo. Objetos de dados

não têm qualquer efeito direto no fluxo de seqüência ou fluxo de mensagens

do processo.

Atividades

Atividades representam o trabalho realizado por uma organização; é um passo dentro do

processo; pode ser atômica ou composta. Quando uma atividade é composta, seu

detalhamento é definido como um fluxo de outras atividades através de um sub-processo

incorporado ao processo principal.

Tarefa

Uma tarefa é uma atividade simples que representa o trabalho

executado dentro do processo, não sendo definida em um mais nível

detalhado. BPMN define diferentes tipos de tarefas.

Tarefa Usuário

É uma atividade simples que representa o trabalho executado por um

usuário de sistema de informação dentro do processo, não sendo

definida em um mais nível detalhado.

Tarefa Manual

É uma atividade simples que representa o trabalho executado

manualmente dentro do processo, não sendo definida em um mais

nível detalhado.



39

Tarefa Serviço

É uma atividade simples que representa o trabalho executado

automaticamente dentro do processo, não sendo definida em um mais

nível detalhado.

Tarefa Envio

É uma atividade simples que representa o envio de resultados

(informações) do processo, não sendo definida em um mais nível


Tarefa Recebimento

É uma atividade simples que representa o recebimento de resultados

(informações) no processo, não sendo definida em um mais nível


Tarefa de Script

É uma atividade simples que representa o processamento de instruções

(script) dentro do processo, não sendo definida em um mais nível


Tarefa Referência

É uma atividade simples que representa uma referência a uma

atividade já existente, de forma a não duplicá-la dentro do processo

Subprocesso Incorporado

Representa o detalhamento de uma atividade composta através de um

conjunto de atividades a serem executadas. Depende completamente o

processo pai e não pode conter pools ou raias.



40

Subprocesso reutilizável

É um processo definido como outro BPM (diagrama de processo de

negócio diagrama), que não depende do processo pai. Ou seja, é a

reutilização de um processo já definido em outro, de forma

independente.

Decisões (Divergência e Convergência de Fluxos)

As decisões são elementos usados para controlar a divergência e convergência do fluxo

de atividades do Processo. (Split e Merge) Com base em dados exclusivo gateway

Desvio Exclusivo Baseado em Dados

Divergente: a decisão do desvio exclusivo tem duas ou mais saídas de

fluxos de seqüência, mas apenas um deles pode ser executado de cada vez e

a decisão será tomada depois de avaliar uma condição de negócio.

Convergente: é usado para mesclar caminhos alternativos.

Desvio Exclusivo Baseado em Evento

É usado como um elemento de divergência, este desvio representa um ponto

no processo em que apenas um dos muitos caminhos do processo pode ser

selecionado, mas com base em um evento, não um condição de expressão de

dados.

Desvio Paralelo

Divergente: é usado para criar fluxo paralelo.

Convergente: é usado para sincronizar vários caminhos paralelos em um

único caminho.

Desvio Inclusivo

Divergente: indica que um ou mais caminhos podem ser ativados de muitos

disponíveis, e a decisão se baseia em dados do processo.

Convergente: indica que muitos caminhos de saída são sincronizados em um

único.

Desvio Complexo

Divergente: é usado para controle de pontos de decisão complexa que não

são podem ser gerenciados com outros tipos de desvio.

Convergência: quando o desvio é usado como uma combinação de fluxos em

série. Haverá uma expressão que irá determinar quais fluxos de seqüência de

entrada serão necessários para o processo para continuar.



41

Para mais informações consulte

Introdução ao BPMN em http://www.bpmn.org/Documents/Introduction to BPMN.pdf

Especificação do BPMN em http://www.bpmn.org/

http://www.bpmn.org/Documents/OMG Final Adopted BPMN 1- Spec 06-02-01.pdf

Análise de Informações

Introdução

Como vimos, as organizações de todos os tamanhos gastam seu tempo e recursos

executando processos de negócios complexos. Um processo de negócio consiste em

regras e na execução de muitas atividades no decorrer do tempo. Quem atualmente

mantém esses processos funcionando nas organizações modernas são sistemas de

informação.

Um processo de negócio também pode ser visto como uma coleção de regras (milhares)

que definem como o negócio é conduzido ao longo do tempo. Pensar nos processos em

termos de regras permite automatizar as partes mecânicas e estruturadas do negócio.

Exemplo de regras de negócios:

Todas as regras para a compra/venda de um produto.

Todas as regras para a produção de um produto ou serviço.

Todas as regras da contabilidade.

Todas as regras para cálculo de salários dos funcionários.

O papel central dos sistemas de informação empresariais é conduzir os processos de

negócios, para isso eles devem manter um banco de dados, fornecer informações para

toda a organização e coordenar o acesso a elas, ao longo da execução de cada atividade

dos processos de negócios.

Um dos princípios da modelagem de processos é a eliminação de esperas. Esperas custam

dinheiro e atrasam o negócio. Na modelagem do processo cada atividade, cada

intervenção ou cada decisão deve ser analisada. Que decisões, análises ou aprovações

podem ser automatizadas? Quais regras de negócio podem ser colocadas num programa

de computador para serem executadas automaticamente sem intervenção humana?

O objetivo certamente não é conseguir automação total, mas eliminar a intervenção

humana desnecessária (processamento de informações, análises, decisões, aprovações,

controles etc.) para aumentar a eficiência dos processos.



42

Os sistemas de informação fazem a sua parte, automatizando atividades e decisões mais

simples e mecânicas (operacionais), deixando para as pessoas as decisões e atividades

que realmente se beneficiam com as intervenções humanas.

A obtenção desse ideal torna mais importante do que nunca a aplicação da tecnologia da

informação como agente dos processos de negócios.

Necessidades de Informação

Introdução

Para a concepção dos sistemas de informação que irão apoiar os processos de negócio de

uma organização, é interessante classificar-se as informações necessárias em externas e

internas. As informações externas são aquelas que a empresa troca com o seu meio

ambiente (outras empresas, clientes e governo) e as internas são aquelas trocadas entre

suas diversas áreas de negócio e níveis de decisão (contabilidade, pessoal, produção e

diretoria).

Informações Externas

Qualquer empresa está inserida num ambiente e, por isso, tem necessidade de se

comunicar com este ambiente. Tipicamente pode-se considerar que o ambiente de uma

empresa é formado por fornecedores, clientes, instituições financeiras, acionistas,

concorrentes, governo e o público em geral.

Fornecedores: todas as empresas se relacionam com fornecedores, com quem

negociam para a aquisição de produtos (matérias-primas) e serviços, ou seja, insumos

necessários ao desenvolvimento de seus negócios. Algumas informações básicas a

respeito dos fornecedores seriam: nome, endereço, telefones, produtos/serviços

ofertados, prazos de entrega, preços e condições de pagamento.

Clientes: são fundamentais a qualquer empresa. São os clientes que geram resultados

para a empresa, sem clientes não há empresa. Algumas informações básicas a respeito

dos clientes seriam: nome, endereço, telefones, produtos/serviços e respectivas

quantidades adquiridas, pagamentos efetuados/a efetuar, pagamentos em atraso,

pedidos efetuados/pendentes, nome do comprador e nome do vendedor.

Instituições Financeiras: para qualquer atividade empresarial são necessários

serviços bancários. Além do aspecto de prestação de serviços (conta corrente,

cobranças e recebimentos), as instituições financeiras têm o papel de financiar

negócios (descontos de duplicatas e empréstimos) e de realizar investimentos

(aplicações financeiras).

Concorrentes: são as empresas que atuam no mesmo ramo de atividade, disputando o

mesmo mercado. A empresa precisa obter informações sobre seus concorrentes, pois

somente assim poderá se situar no mercado (volume de vendas e tipos de produtos),

verificar os lançamentos de novos produtos ou serviços, os pontos de venda que estão

sendo atingidos, a política de preços está sendo praticada e a tecnologia que está



43

sendo utilizada. Quanto aos concorrentes, é preciso ter informações como quem são,

onde estão localizados, quais os produtos que estão vendendo mais, quanto estão

faturando e que estratégias competitivas estão praticando.

Sócios/Acionistas: são as pessoas que investiram seu capital na empresa, e esperam

um retorno compensatório. Mesmo sendo de capital fechado, como é o caso da

maioria das pequenas e médias empresas, poderão haver vários acionistas ou sócios

que deverão ser periodicamente informados sobre a situação da empresa e sobre a

divisão dos lucros.

Governo: o governo é um elemento muito importante, principalmente pelo controle

que exerce sobre a atividade das empresas. Assim, é necessário fornecer-lhe uma

série de informações fiscais e sociais que dependem do setor de atuação da empresa,

entre elas: Imposto de Renda (empresa e funcionários), Descontos para a Previdência

Social (empresa e funcionários), FGTS (empresa e funcionários), impostos (ICMS,

ISS, IPI, PIS e FINSOCIAL) e RAIS.

Público em Geral: apesar de não ter um relacionamento direto com o público, cada

vez mais, devido a movimentos ecológicos, controle de poluição e urbanização e

código do consumidor, as empresas são solicitadas a fornecer informações sobre suas

atividades, produtos e serviços, principalmente aquelas que atuam em setores

sensíveis a estes problemas.

Informações Internas

Qualquer empresa, na medida em que se desenvolve, é dividida em áreas funcionais ou

departamentos, para que consiga executar suas atividades de forma mais eficiente. Além

disso, há uma hierarquia de decisões na empresa, que vai dos níveis operacionais

(inferiores) aos gerenciais e estratégicos (superiores). O conceito de níveis de hierarquias,

nos quais o superior determina as ações dos inferiores, não se limita à coordenação de

pessoas, mas estende-se para as demais funções da empresa, e até para outros tipos de

sistemas.

Para as decisões operacionais são necessárias informações sobre processos que se referem

à operação da empresa, como volumes de estoques, produção, vendas e pagamento de

funcionários. Para as decisões gerenciais são necessárias informações para os processos

de planejamento e o controle das operações da empresa, como estatísticas de vendas,

análise da rotatividade dos estoques e análises financeiras. Finalmente, para as decisões

estratégicas são necessárias informações relacionadas à alta direção da empresa, como

processos de avaliação de oportunidades de investimento e de aplicação de novas

tecnologias. O conceito de nível decisório é importante, pois os processos em cada nível,

operacional, gerencial e estratégico, são diferentes, e conseqüentemente as necessidades

de informação são diferentes. Contudo, estes níveis não são estanques. Ao contrário,

interagem entre si, gerando um fluxo de informações dos níveis inferiores para os

superiores e vice-versa.



44

As áreas funcionais desempenham papéis específicos ligados a cada um dos processos

necessários ao alcance dos objetivos da empresa. Para tanto, são necessárias informações

operacionais, gerenciais e estratégicas, que geram um fluxo de informações dentro de

cada processo e entre processos, pois o processo global de uma organização corresponde

à integração de processos executados por cada função e uns dependem dos outros.

A seguir é apresentada uma lista de processos de negócio, tanto a nível operacional como

gerencial, que inclui a maioria dos processos a serem apoiados por sistemas de

informação de uma empresa industrial típica:

01. Administração Financeira e Contábil

01.1 Contabilidade Geral

01.2 Contabilidade Fiscal

01.3 Contas a Pagar

01.4 Contas a Receber

01.5 Tesouraria

01.6 Controle de importações

01.7 Controle de exportações

01.8 Custos

01.9 Orçamentos

02. Administração de Recursos Humanos

02.1 Folha de pagamentos

02.2 Controle de Férias

02.3 Controle de ponto

02.4 Controle financeiro de pessoal

02.5 Assistência médica

02.6 Administração de salários

02.7 Administração de cargos/funções

02.8 Desenvolvimento/treinamento

02.9 Higiene e segurança do trabalho

02.10 Apoio à assistência social

03. Administração Comercial

03.1 Cotações de preços para clientes

03.2 Administração da carteira de pedidos

03.3 Faturamento

03.4 Estatísticas de vendas

03.5 Expedição

03.6 Cálculo de comissões de vendas

03.7 Administração de transportes

03.8 Informações para clientes

03.9 Assistência técnica



45

04. Administração da Rede Logística

04.1 Administração interna de vendas

04.2 Administração de filiais

05. Administração de Marketing

05.1 Análises de mercados

05.2 Administração de preços

05.3 Apoio à propaganda

05.4 Planejamento de vendas

06. Planejamento Financeiro

06.1 Projeção do fluxo de caixa

06.2 Análises econômico/financeiras

06.3 Análises de investimentos

06.4 Análises de financiamentos

07. Administração Geral

07.1 Follow-up administrativo

07.2 Controle de projetos

07.3 Controle de contratos

07.4 Controle de seguros

07.5 Controle de veículos

08. Administração de Compras e Materiais

08.1 Compras nacionais

08.2 Importações

08.3 Recebimento de materiais

08.4 Controle de estoques de matérias-primas

08.5 Controle de obsolescências

08.6 Controle de materiais indiretos

08.7 Controle de estoques materiais de escritório

08.8 Cadastro de fornecedores

09. Pesquisa e Desenvolvimento

09.1 Apoio à pesquisa de produtos

09.2 Apoio ao desenvolvimento de produtos

09.3 Cadastro de informações técnicas

10. Administração da Produção

10.1 Planejamento da produção

10.2 Programação da produção

10.3 Carga de máquinas

10.4 Controle da produção

10.5 Fechamento de ordens de produção

10.6 Controle de produtividade

10.7 Controle de processos



46

10.8 Controle de serviços externos

10.9 Estatísticas de produção

11. Controle de Qualidade

11.1 Especificações de padrões

11.2 Verificação de qualidade

11.3 Estatísticas de qualidade

12. Manutenção e Ferramentaria

12.1 Planejamento de manutenção preventiva

12.2 Controle de manutenção

12.3 Estatísticas de paradas

12.4 Controles de moldes e dispositivos

12.5 Controle de ferramental

12.6 Metrologia e instrumentos

13. Outros Sistemas Industriais

13.1 Apoio a tempos e métodos

13.2 Projeto de produtos

13.3 Projeto de moldes e ferramentas

Na prática as necessidades de informações externas e internas estão integradas. Por

exemplo, o processo de faturamento deve também fazer o controle do ICMS, assim como

o processo de folha de pagamento deve fazer o controle de descontos de Imposto de

Renda, Previdenciário e FGTS. Portanto, as necessidades de informações globais da

empresa combinam informações externas e internas, e estas devem ser atendidas pelos

sistemas de informação.

Definição de Classes de Dados

Uma classe de dados é uma categoria de dados logicamente relacionados que são

necessários para fornecer informações aos processos de negócio da empresa. Estes dados

devem ser identificados e classificados com o objetivo de determinar:

Exatidão, oportunidade e disponibilidade dos dados que são normalmente utilizados

nos processos de negócio.

Classes de dados utilizadas nos sistemas de informações existentes ou a implantar.

Dados atuais e potenciais compartilhados pelos processos de negócio.

Dados criados, controlados e utilizados por cada processo de negócio.

Informações que são necessárias, mas que não estão disponíveis.

Quais são, tendo em vista fatores críticos de sucesso, os sistemas de informação

prioritários ou que precisam ser melhorados.

As classes de dados são mais facilmente identificadas se divididas nos quatro tipos,

relacionados a seguir.



47

Dados Cadastrais

São dados referentes ao registro de entidades e recursos ligados à atividade da empresa.

Por exemplo, dados sobre: clientes, fornecedores, funcionários e produtos.

Dados Transacionais

São os dados referentes a todas as transações efetuadas pelos processos de negócio da

empresa. Por exemplo, dados sobre: compras, vendas, ordens de produção, pagamento a

funcionários, contas a pagar e contas a receber.

Dados de Controle

São extraídos dos dados cadastrais e transacionais para permitir análises sobre o

desempenho da empresa. Geram medidas para controle do desempenho dos processos de

negócio; por exemplo, volumes de vendas por produto, vendedor ou cliente, custo de

produção por produto etc.

Dados de Planejamento

Representam os objetivos ou níveis esperados dos dados cadastrais e do volume de

transações. São obtidos e estudados a partir dos três tipos anteriores; por exemplo,

previsão de vendas por produto, por vendedor ou por cliente.

As necessidades de informação, ou seja, dados a serem processados e informações a

serem geradas devem ser consolidadas e classificadas, de acordo com os processos de

negócio a que darão apoio e com a classe de dados de que fazem parte.

Dados Cadastrais e Transacionais em Processos de Negócio de uma Empresa Industrial

DADOS CADASTRAIS DADOS TRANSACIONAIS

01. Contas contábeis 01. Lançamentos contábeis

02. Bancos 02. Custos e despesas

03. Centros de custos 03. Notas Fiscais/Faturas

04. Funcionários 04. Duplicatas a receber

05. Clientes 05. Processos de exportações

06. Vendedores 06. Consultas de clientes

07. Filiais e escritórios 07. Pedidos de clientes

08. Representantes 08. Pedidos a fornecedores

09. Produtos e acessórios 09. Processos de importações

10. Classes de produtos 10. Notas Fiscais de compras

11. Veículos 11. Títulos a pagar

12. Máquinas e equipamentos 12. Lançamentos bancários



48

DADOS CADASTRAIS DADOS TRANSACIONAIS

13. Matérias primas 13. Requisições de matérias primas

14. Produtos Semi-acabados 14. Ordens de produção

15. Materiais indiretos 15. Registros de produção

16. Fornecedores 16. Ordens de manutenção

17. Centros de produção 17. Requisições de ferramenta

18. Padrões de produção 18. Requisições instrumentos

19. Processos de produção 19. Requisições de moldes

20. Projetos e Desenhos 20. Alterações de projeto

21. Especificações e moldes 21. Assistência técnica

22. Ferramentas 22. Manutenções Preventivas

23. Transportadoras 23. Ordens de embarque

24. Concorrentes

Para efeito de planejamento e projeto de sistemas de informação devem ser estimados os

principais volumes de dados cadastrais e transacionais processados na empresa

diariamente, semanalmente ou mensalmente, e seus incrementos futuros. Essa estimativa

servirá como uma das bases para o dimensionamento do sistema de informação

(hardware, software, dados, processos e usuários) necessário para a empresa.

Os processos e sistemas de informação transacionais são relativamente comuns entre as

empresas, o mesmo acontecendo com os dados cadastrais. Desta forma, pode-se utilizar

uma tabela de referência para consulta quanto aos volumes a serem levantados.

Definição dos Requisitos de um Sistema de Informação

Introdução

O projeto detalhado de um sistema de informação a ser desenvolvido somente deve

ocorrer após a definição das necessidades de informação da organização ou dos usuários

que irão utilizá-lo.

Tradicionalmente, para a obtenção das definições necessárias para o desenvolvimento de

um sistema de informação, o desenvolvedor deve entrevistar cada usuário da informação,

ou gerente da organização, envolvidos nos processos e áreas que serão afetadas pelo

sistema. Após este trabalho, que poderá demandar considerável tempo, as anotações

coletadas devem ser resumidas num documento de definição de requisitos ou de

especificação do sistema de informação a ser desenvolvido.



49

Relação de Requisitos do Sistema

Um documento, com a definição dos requisitos de um sistema de informação, deve conter

basicamente:

Processos a serem beneficiados

Dados a serem processados

Informações a serem geradas

Recursos especiais

Processos a Serem Beneficiados

Devem ser relacionados e descritos resumidamente os processos de negócio a serem

beneficiados pelo sistema, isto é, cujas necessidades de informações operacionais e

gerenciais para a execução de suas atividades deverão ser supridas pelo sistema de

informação a ser desenvolvido e implantado.

Dados a Serem Processados

Devem ser relacionados os dados a serem captados, armazenados e processados pelo

sistema para gerar as informações necessárias aos processos. Assim, por exemplo, para o

processo de faturamento de vendas, o cadastro dos clientes deverá conter o código do

cliente, o nome, o endereço, o limite de crédito, a região de venda, condições de

comercialização, o vendedor responsável e o saldo atual do cliente. Para validação, é

fundamental analisar os documentos utilizados pelo sistema de informação atual (manual

ou não), para verificar se todos os dados necessários foram incluídos. Também é

interessante anotar-se o número de posições necessário para cada dado, por exemplo, o

nome do cliente pode ter até 40 letras ou posições e as regras necessárias para verificar a

validade de cada dado, por exemplo, o sexo do funcionário só deve aceitar as letras M ou

F.

Informações a Serem Geradas

Devem ser relacionadas as consultas desejadas na tela do computador e os relatórios a

serem impressos pelo sistema, de forma a satisfazer as necessidades de informação dos

processos, informando sua freqüência, (diária, semanal, mensal ou anual), seu conteúdo,

ordem de emissão e cálculos necessários para a obtenção das informações.

Regras do Negócio

Deve-se obter com a máxima precisão possível uma descrição das regras, cálculos ou

processamentos especiais que o sistema deve seguir para gerar as informações

necessárias, as facilidades e recursos que deve oferecer e as exceções à regra geral que

poderão ocorrer. Todos os códigos que serão utilizados para classificar clientes, produtos,

funcionários, processos, contas contábeis e transações também devem ser descritos com

detalhes.



50

Bancos de Dados

Introdução

Uma base de dados (ou banco de dados) pode ser definida como um conjunto unificado

de informação que vai ser compartilhado pelas pessoas autorizadas de uma organização.

A função básica de uma base de dados é permitir o armazenamento e a recuperação da

informação necessária para as pessoas da organização tomar decisões, eliminando

redundâncias. Quando coexistem várias cópias de uma mesma informação, é comum

ocorrer discrepâncias entre elas, podendo-se chegar ao extremo de se tornar impossível

determinar qual das diferentes versões é a correta. Em uma base de dados corretamente

projetada não deve existir informação redundante e, portanto, a possibilidade de que se

produzam inconsistências entre os dados é minimizada.

Em um banco de dados os dados que descrevem entidades (pessoas, produtos, materiais,

locais, etc.) e eventos (vendas, compras, pagamentos, recebimentos, etc.) são

armazenados em registros. Cada característica ou qualidade que descreve uma entidade

ou um evento em particular é denominada atributo, que é armazenado em um campo de

dados. Um registro é, portanto, formado por um conjunto de atributos (campos de dados)

que descrevem uma entidade ou evento.

Os registros, por sua vez são armazenados em arquivos de dados. Um arquivo de dados

é, portanto, formado por um conjunto de registros que descrevem as mesmas entidades ou

eventos. Cada registro em um arquivo deve conter pelo menos um dado que identifique

de forma única este registro para que ele possa ser recuperado (lido), atualizado e

classificado. Esse dado identificador único de cada registro é chamado de chave

primária. Chaves secundárias são outros dados do registro que contém alguma

característica identificadora da entidade ou evento, mas, em geral, não os identificam de

forma única. Chaves estrangeiras são dados que permitem o relacionamento entre

registros, normalmente contidos em arquivos diferentes.

Assim, portanto, um banco de dados é composto por um conjunto de arquivos, um

arquivo é composto por um conjunto de registros e um registro é composto por um

conjunto de dados que descreve determinada entidade ou evento de interesse da

organização.



51

BANCO DE

DADOS

ARQUIVO

CLIENTE

ARQUIVO

PRODUTO

ARQUIVO

VENDA

ARQUIVO

COMPRA

ARQUIVO

....

Registro Cliente

Registro Cliente

Registro Cliente

Registro Cliente

Identificação (1) Nome do Cliente Endereço Cidade Estado

Identificação (2)

Identificação (3)

Identificação (N)

......

Nome do Cliente Endereço Cidade Estado



Dados (atributos) do ClienteChave Primária

Estrutura de um Banco de Dados

A estrutura lógica de um arquivo de dados é mais facilmente representada através de uma

tabela. Nesta tabela de dados, as linhas correspondem aos registros do arquivo e as

colunas correspondem aos campos de dados de cada registro. Cada coluna é identificada

pelo nome do dado que será nela armazenado enquanto que cada linha é identificada pela

chave primária de cada registro. Na figura a seguir é representada a estrutura lógica de

um banco de dados, bem como a representação dos arquivos de dados através de tabelas.

Dependendo do porte e da natureza da organização, um banco de dados corporativo

normalmente é composto por centenas ou milhares de tabelas relacionadas. Cada tabela

possui dezenas ou centenas de colunas de dados e milhares ou milhões de linhas ou

registros.

Um banco de dados é, portanto, um agrupamento lógico organizado de arquivos

relacionados. Em um banco de dados os dados são integrados e estão relacionados para

que um conjunto de softwares forneça acesso a todos eles, reduzindo problemas de

redundância, isolamento e inconsistência de dados, além de oferecer maior segurança e

integridade. Os softwares aplicativos e os dados permanecem independentes entre si.

Bancos de dados centralizados mantêm todos os arquivos de dados relacionados em uma

única localização física. Bancos de dados distribuídos contem cópias completas de um

banco de dados ou partes de um banco de dados, em mais de uma localização física, que

normalmente próxima aos usuários.



52

Descentralização

Normalmente, nos microcomputadores, as informações necessárias a uma organização se

distribuem em um conjunto de bases de dados departamentais. Cada uma das bases de

dados contém informações sobre uma determinada área ou função da organização. Uma

delas pode ter sido desenvolvida para armazenar informações da área financeira, outra da

área de pessoal e uma terceira da área de vendas ou produção. O grande problema é que,

nesse caso, o processo de negócio como um todo, que invariavelmente envolve diversas

áreas, não é contemplado pelo sistema.

Centralização

Por outro lado, em computadores de maior porte (servidores), as informações necessárias

a uma organização são armazenadas numa única base de dados corporativa, que contém

informações sobre todas as áreas e funções da organização de forma integrada,

consistente e consolidada. Todos os sistemas de informação da organização compartilham

esta única base de dados. A grande vantagem é que, neste caso, todos os processos de

negócio da organização podem ser contemplados pelo sistema, independentemente da

área ou função que execute cada atividade.

SGBD

Independentemente da base de dados que será implantada, a função de um software de

Gerenciamento de Base de Dados (SGBD) é a mesma. O SGBD pode ser definido como

sendo o conjunto de recursos de TIC que possibilitará aos usuários o acesso e a utilização

eficiente da base de dados. O SGBD deve se encarregar da comunicação entre o usuário e

a base de dados, proporcionando a este os meios de pesquisar e obter informações,

introduzir novas informações e atualizar as existentes.

Estrutura de uma Base de Dados

Tabelas de Dados

Uma base de dados é formada por um conjunto de tabelas de dados que contém a

informação nela armazenada. O conjunto de tabelas ilustrado a seguir pode ser

considerado como pertencente a uma base de dados de compras.

Esta base de dados contém informações de três tipos, ou melhor, sobre três entidades:

Dados sobre produtos (entidade produto), armazenados na tabela de produtos;

Dados sobre fornecedores (entidade fornecedor), armazenados na tabela de

fornecedores e;

Dados sobre a origem dos produtos (entidade origem do produto), ou seja, os

produtos que são fornecidos por cada fornecedor e vice-versa, armazenados na

tabela de origem dos produtos.

TABELA DE PRODUTOS



53

Código Nome Unidade

1.01.001 CD-R Caixa com 10

1.01.002 CD-RW Caixa com 10

1.02.001 DVD-R Caixa com 10

2.01.001 Cartucho de Tinta para Impressora Unidade

3.01.001 Papel A4 para impressora. Pacote com 1000 folhas

4.01.001 Microcomputador Unidade

4.02.001 Notebook Unidade

4.02.002 Impressora Unidade

4.02.003 .

.

.

.

.

.

TABELA DE FORNECEDORES

Código Nome Endereço Telefone

0001 Arapuca Suprimentos Ltda. Rua Intel, 486 666-6666

0002 Infosup Ltda. Rua FoxPro, 70 680-6868

0003 AGV Suprimentos Ltda. Rua Delphi, 60 343-5643

. . . .

. .

.

.

.

.

.

TABELA DE ORIGEM DOS PRODUTOS

Fornecedor Produto Preço

0001 1.01.001 130,00

0002 1.01.001 11,00

0003 1.01.001 9,00

0002 2.01.001 15,00

0001 3.01.001 40,00

.

.

.

.

.

.

.

.

.



54

As informações relativas a cada uma das entidades de interesse da organização são

armazenadas numa tabela de dados individual. Por sua vez, cada uma destas tabelas é

formada por um conjunto de linhas (ou registros) que descreve, através de colunas (ou

dados), os atributos de cada entidade nela armazenada.

Todos os registros de uma tabela, identificados pelas linhas de cada tabela, possuem o

mesmo formato, ou seja, o mesmo conjunto de colunas de dados ou atributos que

descrevem as entidades.

Os registros ou linhas são formados por um conjunto de dados, armazenados em campos,

identificados pelas colunas das tabelas. Cada registro deve conter o conjunto de dados ou

campos necessários para descrever completamente cada entidade sobre a qual uma

organização necessita armazenar e obter informações.

Chave Primária ou Identificadora

Em uma base de dados, para cada tabela de dados existe pelo menos um arquivo de índice

de acesso que é criado a partir de um atributo (ou campo) ou de um conjunto deles, para

identificar cada registro de forma inequívoca. O conjunto de atributos ou campos

utilizados para gerar este índice é denominado chave primária ou chave identificadora

da tabela. A chave primária é, portanto, aquele atributo, ou conjunto de atributos,

utilizado para distinguir ou identificar de forma única cada registro ou linha dentro de

uma tabela de dados.

Uma chave primária não deve possuir atributos desnecessários para a identificação dos

registros. Considera-se que uma chave primária não contém atributos ou campos

desnecessários quando, ao se eliminar qualquer um dos que a compõem, a informação

proporcionada pelos restantes não é suficiente para identificar de forma inequívoca cada

registro ou linha da tabela de dados.

No caso da base de dados de compras, exemplificada anteriormente, as chaves primárias

de cada tabela são:

Tabela dos Produtos: código do produto.

Tabela dos Fornecedores: código do fornecedor.

Tabela de Origem dos Produtos: código do fornecedor + código do produto.

Cada chave primária é suficiente para identificar univocamente cada um dos registros das

tabelas da base de dados. Em conseqüência, em cada tabela não deverá haver mais do que

um registro ou linha que possua o mesmo valor para sua chave primária.

Em um SGBD adequadamente projetado deve ser gerado um erro se um usuário tentar

incluir um novo registro cuja chave primária coincida com a de outro registro já existente

na mesma tabela.

Índices de Acesso

Um índice de acesso é um arquivo auxiliar utilizado internamente pelo SGBD para acesso

direto a cada registro da tabela de dados a ele associado. A operação de indexação



55

(criação do arquivo de índice pelo SGBD) ordena os registros de uma tabela de dados de

acordo com os campos utilizados como chave e incrementa sensivelmente a velocidade

de execução de operações sobre a tabela de dados, principalmente as relacionadas com a

localização de dados em registros. Normalmente, para cada tabela de dados deve haver

um índice cuja chave de indexação seja idêntica à sua chave primária. Este índice é

chamado de índice primário.

Também é possível criar índices para uma tabela de dados utilizando atributos (ou

campos), ou conjuntos de atributos, diferentes dos da chave primária. Este tipo de índice,

chamado de índice secundário, é utilizado para reduzir o tempo necessário para localizar

determinada informação dentro de uma tabela ou para classificar os registros da tabela de

acordo com ordem necessária para a obtenção da informação desejada.

Na figura a seguir é ilustrado um exemplo didático simplificado do funcionamento de um

arquivo de índice associado a uma tabela de dados. Normalmente, os registros de uma

tabela de dados não estão ordenados, mas contém todos os dados que descrevem a

entidade nela armazenada. Para acessá-los de forma ordenada, é criado e mantido um

arquivo especial, denominado arquivo de índice, que contém apenas as chaves de

ordenação (ou acesso) e os números dos registros da tabela de dados que as possuem.

Assim, localizando-se uma determinada chave no arquivo de índice, torna-se possível o

acesso direto ao registro da tabela de dados por ela identificado.

Comparando uma tabela de dados a um livro, o processo seria equivalente a localizar o

número da página na qual se encontra um determinado assunto através do índice

remissivo do livro e, em seguida, abrir o livro na página determinada para ter acesso

direto ao assunto desejado, sem precisar folhear todo o livro até encontrá-lo.

A localização das chaves no arquivo de índice é extremamente rápida, pois normalmente

os SGBDs utilizam uma variação aperfeiçoada da técnica de pesquisa binária, conforme

esquematizado na figura a seguir. Através desta técnica o arquivo de índice é inicialmente

dividido em duas partes iguais, ou seja, em duas metades. A seguir, como o índice está

ordenado de acordo com a chave de pesquisa, verifica-se se a chave desejada está

localizada na metade superior ou na inferior, comparando-a com o valor da chave central.

Novamente a metade escolhida é dividida ao meio, daí o nome pesquisa binária, pois

sempre se divide o índice em duas partes, e o processo é repetido até que seja localizada a

chave desejada.

Uma vez localizada a chave no arquivo de índice, obtém-se o número do registro da

tabela de dados que a contém e é realizado o acesso direto às informações nele contidas.

Utilizando-se a técnica de acesso binário, o tempo necessário para ser localizada uma

determinada informação numa tabela de dados praticamente independe da quantidade de

registros ou linhas que a mesma possui, o que é essencial para sistemas de informação

empresariais onde normalmente as tabelas de dados armazenam milhares ou milhões de

registros.



56

Esquema de arquivos de índice e da busca binária numa tabela de dados

Projeto de Bancos de Dados

Antes de começarmos a examinar as técnicas para o projeto e desenvolvimento de

sistemas de informação, vamos fixar alguns dos objetivos que se deve alcançar no projeto

e determinar, em particular, qual é o resultado final que se deseja obter para a construção

de uma base de dados para um sistema de informação. Os principais objetivos do projeto

de uma base de dados são:

Armazenar Toda a Informação Pertinente ao Sistema

Ao se desenvolver um sistema de informação, se supõe que sua base de dados deva

armazenar e manter toda a informação relevante para a organização. Um dos primeiros

passos do projeto deve ser, portanto, determinar as entidades e seus respectivos atributos,

cujos dados deverão ser armazenados na base de dados. Apenas após estas terem sido

identificadas poderemos determinar o número de tabelas de dados necessárias e quais

dados comporão os registros ou linhas de cada uma delas. Num sistema implantado em

computadores de pequeno ou médio porte, deve ser tomada ainda a decisão de dividir a

informação em várias bases de dados distribuídas ou mantê-la em uma só.

Informação Redundante deve ser Eliminada

As implicações deste objetivo podem não ser evidentes para o desenvolvedor

inexperiente no projeto de bases de dados. A chave de sua importância está na diferença

entre informação duplicada e informação redundante. Em muitos casos é necessário

duplicar dados contidos em tabelas diferentes para que se possa obter a informação

desejada. Isso é especialmente válido quanto forem estabelecidos relacionamentos

(ligações) entre tabelas de dados diferentes para podermos obter informações completas

sobre entidades complexas. Neste caso, se a duplicação for eliminada as informações não

mais poderão ser obtidas. Portanto, a informação é duplicada, porém necessária.

A informação redundante é a informação duplicada desnecessária, ou seja, se for

eliminada não haverá nenhuma perda, pois os relacionamentos ainda poderão ser



57

estabelecidos e a informação completa obtida. Além disso, uma vez que é desnecessária,

a informação redundante ocupa espaço precioso no disco do computador e, muito pior do

que isso, poderão ser geradas versões diferentes da mesma informação sem que seja

possível saber qual é a versão correta. Nas seções seguintes serão examinadas técnicas

que nos ajudarão a definir o conjunto de dados que deverá estar contido em cada tabela

que formará a base de dados do sistema de informação.

Minimizar o Número de Tabelas

Este objetivo contempla o fato de que, se a divisão das tabelas de dados em outras tabelas

menores pode ser interessante para eliminar certos problemas de atualização e

armazenamento, a existência de um número muito elevado de tabelas na base de dados de

um mesmo sistema pode tornar incomoda e trabalhosa a manutenção de todos eles.

Poderíamos resumir dizendo que não é conveniente que o número de tabelas de uma base

de dados cresça incontrolavelmente.

Normalizar as Tabelas

Certos tipos de tabelas de dados são mais propensas do que outras a problemas de

atualização e manutenção. O desenvolvedor que está projetando uma base de dados deve

saber detectar as tabelas que são potencialmente problemáticas para poder normalizá-las.

A normalização de tabelas é basicamente uma técnica de decomposição ou subdivisão de

uma tabela de dados em duas ou mais tabelas menores, através de um procedimento

específico para determinar a melhor maneira de efetuar o armazenamento dos dados, de

forma a evitar problemas de atualização de dados nas tabelas.

Você provavelmente deve ter percebido que os dois últimos objetivos perseguem

propósitos opostos. Normalmente, o projeto da base de dados de um sistema de

informação é o resultado de um compromisso equilibrado entre ambos, de acordo com as

características do sistema que estiver sendo desenvolvido.

Modelagem de Dados

Introdução

Uma das definições mais importantes para o projeto de sistemas de informação é a

definição dos objetos de informação de interesse da empresa ou organização para a qual o

sistema será construído, pois para que seja possível gerar as informações necessárias para

os processos de negócio precisamos armazenar os dados que as compõem.

Os objetos de informação são geralmente entidades ou eventos de interesse dos

processos, por exemplo: clientes, fornecedores, produtos, vendas, compras e cobranças.

Entidades: são objetos de informação que existem durante um determinado tempo, como

produtos, clientes, fornecedores etc.

Eventos: são objetos de informação que ocorrem num determinado momento como

vendas, compras, cobranças, ordens de produção etc.



58

As informações necessárias para apoiar os processos de negócio normalmente envolvem

diversas entidades e eventos relacionados. Assim, uma entidade poderá ter um ou mais

eventos a ela associados. Por exemplo: um produto pode estar relacionado a uma ou mais

vendas, ou uma venda a uma ou mais cobranças. Por outro lado, um evento pode

representar a associação de uma ou mais entidades. Por exemplo: uma venda com

diversos produtos vendidos para um cliente, ou uma compra com diversas matérias-

primas compradas de um fornecedor.

Em um modelo de dados, cada entidade ou evento deve ser representado pelo menos por

uma tabela de dados. Conseqüentemente, algo que não requeira pelo menos dois dados

para ser descrito não será uma entidade ou um evento, e sim um atributo ou dado de um

outro objeto de informação. Desta forma, uma data não é uma entidade ou um evento,

mas apenas um dado ou atributo de uma entidade. Por exemplo: a "data de admissão" da

entidade funcionário, ou a "data da compra" de um evento compra.

Como regra geral, cada tabela de dados armazena os dados que descrevem entidades e

eventos de interesse dos processos de negócio da organização e farão parte de seu sistema

de informação. Normalmente, a base de dados de um sistema de informação é composta

por entidades ou tabelas de dados relacionadas umas às outras. Assim, por exemplo, um

cliente poderá estar relacionado a várias vendas, uma venda relacionada a vários produtos

vendidos, um vendedor relacionado a várias vendas, e assim por diante.

Uma vez que as entidades que formarão a base de dados de um sistema de informação

estão relacionadas, e que, através desses relacionamentos são geradas informações, como

por exemplo, “todos os produtos vendidos para um cliente”, para o desenvolvimento de

um sistema de informação é muito importante definir todos os relacionamentos entre as

entidades.

O Modelo Relacional de Dados (RDM) é um diagrama gráfico através do qual

identificamos todas as entidades que formarão a base de dados de um sistema de

informação, definimos todos os relacionamentos entre elas e descreveremos o tipo de

cada relacionamento. Por esse motivo RDM é fundamental para o projeto da base de

dados de um sistema de informação.

O RDM mostra os três tipos de relacionamento possíveis entre as entidades e os eventos

de interesse de um processo de negócio: um-para-um (1,1), um-para-muitos (1,∞) e

muitos-para-muitos (∞,∞).

No RDM cada entidade é representada por um retângulo, e o relacionamento entre elas

por uma linha unindo os retângulos. O tipo do relacionamento pode ser representado por

vários símbolos. Particularmente, por motivos didáticos, nesta apostila adotaremos a

notação utilizada pelo SGBD Microsoft Access, representada por um par de números nas

extremidades da linha de relacionamento entre entidades ou tabelas de dados:

1 identifica um relacionamento com uma única entidade da tabela;

∞ identifica um relacionamento com muitas entidades.



59

Na figura a seguir é representado o relacionamento entre as entidades PESSOA e

DEPARTAMENTO. O número 1 indica que uma pessoa trabalha em um único

departamento. Por outro lado, o símbolo ∞ indica que em um departamento podem

trabalhar várias ou N (∞) pessoas.

Relacionamento 1:N entre PESSOA e DEPARTAMENTO

Portanto, uma pessoa está relacionada a um departamento. Por outro lado, um

departamento está relacionado várias ou N (∞) pessoas.

Relacionamento 1:N entre VENDA E ITENS DA VENDA

No exemplo da figura anterior, cada VENDA envolve um ou mais ITENS ou produtos

vendidos (∞), mas um ITEM ou produto vendido é parte de apenas uma única venda (1).



60

Relacionamento N:N entre FORNECEDOR e PRODUTO

No exemplo da figura anterior cada FORNECEDOR fornece um ou mais produtos (∞) e

cada PRODUTO pode ser fornecido por um ou mais fornecedores (∞).

Um relacionamento entre duas entidades ou eventos poderá ser lido em qualquer uma das

direções como "objeto 1 está relacionado ao objeto 2" ou o "objeto 2 está relacionado ao

objeto 1". Por exemplo, "um fornecedor fornece um ou vários produtos (1, ∞)" ou "um

produto é fornecido por um ou vários fornecedores (1, ∞)".

Relacionamentos Um-para-Um

Ao ser identificado um relacionamento um-para-um (1,1), deve-se inicialmente verificar

se os dois objetos relacionados são realmente distintos ou se podem ser unidos em um

único. Se cada objeto for identificado pela mesma chave primária e se ambos se

completarem, há uma forte razão para unir os dois objetos em um único. Por exemplo,

tomemos as entidades PRODUTO e ESTOQUE:

Relacionamento 1:1 entre PRODUTO e ESTOQUE

Como cada PRODUTO é armazenado no ESTOQUE, podemos considerar apenas uma

entidade PRODUTO que então apenas contém o atributo ou dado SaldoEstoque:

Entidade PRODUTO com o atributo SaldoEstoque



61

Neste caso, as entidades PRODUTO e ESTOQUE não são realmente distintas e, por esse

motivo, devemos armazená-las numa única tabela de dados, pois o saldo no estoque é

apenas um atributo de cada produto.

Se os dois objetos forem realmente distintos, cada um deverá ser identificado por um

dado chave que o distinga de forma inequívoca dos demais. Este dado chave é

fundamental para estabelecer relacionamentos entre entidades e recebe a denominação de

chave primária do objeto (primary key ou PK). É identificado no diagrama do RDM

pelo símbolo de uma chavinha, como ilustrado nas figuras.

O relacionamento entre dois objetos deverá ser realizado através de uma chave de

relacionamento, denominada chave estrangeira (foreign key ou FK). A chave estrangeira

é uma cópia da chave primária do objeto principal (pai) no objeto relacionado (filho). A

chave estrangeira recebe este nome porque, na verdade, ela não é um atributo do objeto

relacionado, mas sim é a chave primária do objeto ao qual este se relaciona.

Relacionamento e suas chaves

No caso do relacionamento um-para-vários (1, ∞) entre disciplina e professor que a

leciona, temos a chave primária da DISCIPLINA (código que a identifica) e a chave

primária do PROFESSOR (número que o identifica). Se admitirmos que um

PROFESSOR está relacionado com uma única DISCIPLINA, então a chave estrangeira,

que realiza o relacionamento (código da disciplina) deve ser armazenada na tabela de

dados que descreve o professor, e aponta ou determina a disciplina por ele lecionada.,

como ilustrado na figura anterior.

Portanto, na tabela PROFESSOR, o dado "código da disciplina" é uma chave estrangeira,

significando que se trata de um dado da tabela DISCIPLINA, mas que precisa existir na

tabela PROFESSOR para permitir o relacionamento entre ambos. Note que neste

relacionamento entre DISCIPLINA e PROFESSOR, um professor pode apenas lecionar

uma única disciplina.

Outra forma alternativa de relacionar professores e disciplinas seria admitir que uma

disciplina somente pode ser ministrada por um professor. Isto significa incluir a chave

estrangeira "número do professor" na tabela DISCIPLINA.



62

Chave estrangeira PROFESSOR x DISCIPLINA

Embora estas duas soluções sejam possíveis para o relacionamento entre PROFESSOR e

DISCIPLINA, nenhuma delas está totalmente correta. Uma solução melhor deve permitir

que um professor possa lecionar várias disciplinas ou que uma disciplina possa ser

ministrada por vários professores. Ou seja, o relacionamento entre PROFESSOR e

DISCIPLINA não é um-para-um (1,1), ou um-para-muitos (1, ∞), mas muito-para-muitos

(∞,∞).

Relacionamentos Um-para-Muitos

Um relacionamento um-para-muitos (1, ∞) ocorre quando um único objeto está

relacionado com vários outros objetos. Como cada objeto de informação sempre possui

uma tabela de dados contendo seus atributos, a chave primária do "objeto um" deve ser

uma "chave estrangeira" na tabela que descreve o "objeto muitos", podendo ser parte de

sua chave primária ou não.

No exemplo ilustrado pela figura a seguir, mostrando o relacionamento entre uma

DISCIPLINA (objeto um) e vários PROFESSORES (objeto muitos), o atributo "código

da disciplina" é a chave estrangeira de PROFESSOR.

Relacionamento um-para-muitos entre DISCIPLINA e PROFESSOR

Neste caso, uma disciplina pode ser ministrada por vários professores (1, ∞), mas um

professor somente pode lecionar uma única disciplina (1,1).

Já no exemplo ilustrado pela figura a seguir, mostrando o relacionamento entre um

PROFESSOR (objeto um) e várias DISCIPLINAS (objeto muitos), o atributo "número do

professor" é a chave estrangeira de DISCIPLINA.



63

Relacionamento um-para-muitos entre PROFESSOR e DISCIPLINA

Neste caso, um professor pode ser lecionar várias disciplinas (1, ∞), mas uma disciplina

pode ser ministrada somente por um professor (1,1).

Relacionamentos Muitos-para-Muitos

Se analisarmos os exemplos anteriores, perceberemos que o relacionamento mais correto

entre PROFESSOR e DISCIPLINA não é um-para-um e nem um-para-muitos, mas sim

muitos-para-muitos. Ou seja, um professor pode lecionar muitas disciplinas e uma

disciplina pode ser ministrada por muitos professores.

Um relacionamento muitos-para-muitos sempre deve ser resolvido por dois

relacionamentos um-para-muitos (1, ∞), pois não é possível que tanto PROFESSOR

como DISCIPLINA recebam chaves estrangeiras. Neste caso, inicialmente, as chaves

primárias de ambos os objetos relacionados ∞, ∞ deverão ser identificadas e, a seguir, um

"objeto de interseção" deverá ser criado. A chave primária do objeto de interseção será a

combinação ou concatenação das chaves primárias dos dois objetos originais.

Para determinar os dados que deverão estar contidos no objeto de interseção a ser criado,

devemos analisar o relacionamento muitos-para-muitos entre DISCIPLINA e

PROFESSOR fazendo as seguintes perguntas:

Qual deve ser o objeto que possui uma chave primária que corresponda à

concatenação de um determinado "código de disciplina" e de um determinado

"número de professor"?

Quais dados ou atributos dependem exclusivamente desta combinação?

Quais dados podem ser obtidos se soubermos que estamos lidando com uma

determinada disciplina ministrada por um determinado professor?

Ao tentarmos responder estas perguntas verificaremos que diferentes disciplinas podem

ser ministradas por diferentes professores em determinados horários e salas de aula ou,

por outro lado, diferentes professores lecionam diferentes disciplinas em determinadas

salas de aula e em determinados horários.



64

Portanto, como uma dada disciplina poderá ser ministrada por diferentes professores em

diferentes salas de aula e em diferentes horários, podemos criar um objeto de interseção

denominado TURMA. Desta forma, um determinado professor poderá lecionar várias

disciplinas, cada uma em sua respectiva sala de aula e horário; assim como cada

disciplina poderá ser ministrada por vários professores, e para cada professor haverá uma

determinada sala de aula e horário.

A figura a seguir ilustra o relacionamento muitos-para-muitos (∞,∞) entre DISCIPLINA

e PROFESSOR resolvido por um relacionamento um-para-muitos (1, ∞) entre

DISCIPLINA e TURMA e um relacionamento um-para-muitos (1, ∞) entre

PROFESSOR e TURMA.

Relacionamento muitos-para-muitos resolvido

Neste caso, para que uma TURMA seja identificada é necessário saber qual é a disciplina

e qual é o professor. Como o "código da disciplina" pertence a DISCIPLINA e o "número

do professor" pertence a PROFESSOR, ambos são chaves estrangeiras em TURMA.

Conjuntos de Relacionamentos

Consideremos agora outro exemplo, o relacionamento entre VENDA e ITEM

VENDIDO. Uma venda possui vários itens ou produtos vendidos, mas um item ou

produto vendido somente pode fazer parte de uma venda. O relacionamento entre

VENDA e ITEM VENDIDO é, portanto, um-para-muitos (1, ∞), como indica a figura a

seguir.

Relacionamento entre VENDA e ITEM VENDIDO



65

Consideremos agora o lado dos produtos. Deve haver um relacionamento entre ITEM

VENDIDO e PRODUTO. Como cada produto pode ser vendido várias vezes, o

relacionamento deve ser um-para-muitos (1, ∞), ou seja, um produto pode estar

relacionado a vários itens vendidos. Para estabelecer o relacionamento entre PRODUTO

e ITEM VENDIDO, a chave primária de PRODUTO, CodigoProduto, precisa aparecer

como chave estrangeira em ITEM VENDIDO, como ilustra a figura a seguir.

Relacionamento entre ITEM VENDIDO e PRODUTO

Se agora considerarmos pelo lado dos clientes, verificaremos que para um mesmo cliente

poderá haver várias vendas e, portanto, o "código do cliente", identificador do cliente,

deverá ser parte da tabela de dados VENDA, mas não é parte de sua chave primária, pois

apenas o "número da nota fiscal" por si só é suficiente para identificar unicamente cada

venda, como ilustrado na figura a seguir.

Relacionamento entre CLIENTE e VENDA

É claro que se um cliente está relacionado a várias vendas, cada venda está relacionada a

vários itens vendidos e cada item vendido a um produto e um produto a vários

fornecedores, surge, então, um conjunto mais amplo de relacionamentos um-para-muitos,

como ilustrado pela figura a seguir.



66

Relacionamento CLIENTE - VENDA - ITEM VENDIDO – PRODUTO – ORIGEM - FORNECEDOR

Não é necessário incluir o "código do cliente" também na tabela ITEM VENDIDO, pois

se desejarmos produzir um relatório que informe a quais clientes foram vendidos

produtos, é possível pesquisar todos os "números de notas fiscais" na tabela ITEM

VENDIDO à procura dos produtos da tabela PRODUTO e depois, usando estes números,

pesquisar todos os clientes nas tabelas VENDA e CLIENTE.

Conjuntos de Relacionamento para VENDAS e COMPRAS são “simétricos”



67

No projeto da base de dados de um sistema de informação, devemos, portanto, incluir

chaves primárias e chaves estrangeiras nas tabelas, com o objetivo de criar os

relacionamentos necessários para a obtenção das informações que deverão ser fornecidas

aos usuários. A análise dos relacionamentos e dados chave que deverão ser incluídos em

cada tabela de dados deve ser feita nesta fase, com a ajuda do modelo de relacionamento

de dados (RDM - Relational Data Model).

Variação no Tempo

Para cada objeto de informação deve-se analisar se seus atributos (dados) variarão com o

tempo. Para cada um destes dados deve-se verificar se será necessário armazenar o

histórico dos valores que assumiu durante um determinado período de tempo ou de

acordo com um determinado número de variações.

Por exemplo, no caso do custo de um determinado produto armazenado no estoque, seu

preço poderá variar no decorrer do tempo. De acordo com as necessidades dos usuários

do sistema devemos analisar se será suficiente apenas guardar o preço atual ou se

devemos manter disponível o histórico do preço de cada produto dentro de um

determinado período. A quantidade do produto no estoque também será alterada ao longo

do tempo. Devemos analisar se será necessário manter a movimentação do estoque para

cada produto, ou seja, entradas (compras) e saídas (vendas), ou apenas suficiente manter

o saldo atual. Além disso, devemos decidir se produtos descontinuados serão mantidos

nos registros das tabelas de dados que comporão a base de dados do sistema.

Da mesma forma que no exemplo com produtos em estoque, diversos outros objetos de

informação, como funcionários, vendas, compras etc., deverão ser analisados para se

decidir se deverão ser mantidos registros históricos.

Toda vez que for tomada uma decisão de se armazenar um dado histórico de um objeto

de informação determina-se implicitamente um relacionamento um-para-muitos, com

uma tabela de dados dependente, contendo a data de alteração, o valor do dado a partir

desta data e outros dados que forem necessários para caracterizar a alteração ocorrida.

Uma vez criado esse arquivo histórico dependente, deve-se decidir também se o valor

atual do dado, por exemplo, saldo atual do produto no estoque, deve ser armazenado na

tabela principal dos produtos, ou se ele deve ser calculado (derivado) a partir do arquivo

histórico, apenas quando for necessário. Na verdade, esta decisão também envolve uma

questão de desempenho do sistema, pois o cálculo do valor atual sempre consumirá

algum tempo.

Assim como na análise da necessidade de se armazenar dados históricos sobre

determinadas entidades, como produtos, também devemos considerar por quanto tempo

os registros de eventos, como vendas ou compras, precisam ser mantidos em

disponibilidade no sistema. Cada registro de evento deve possuir uma periodicidade fixa

no sistema para o seu armazenamento na tabela de dados, como por exemplo, um mês,

seis meses ou um ano. Após este período, o registro do evento e todos os outros a ele

relacionados, devem ser transferidos para um ou mais arquivos históricos, destinados ao



68

armazenamento permanente deste tipo de evento. A tabela original poderá ser, então,

totalmente limpa para iniciar um novo período. Posteriormente, os dados históricos

deverão poder ser recuperados dos arquivos históricos caso sejam necessários.

O Modelo Relacional de Dados (RDM - Relational Data Model)

O resultado final da análise de entidades e relacionamentos é um diagrama em que cada

retângulo representa uma tabela na base de dados do sistema. Todos os relacionamentos

um-para-um (1,1) devem ter sido examinados e determinados como não sendo

subdivisíveis. As chaves estrangeiras que estabelecerão cada relacionamento também já

deverão ter sido definidas.

Finalmente, nenhum relacionamento muitos-para-muitos (N,N) ou (∞,∞) deve aparecer

explicitamente, pois todos já deverão ter sido resolvidos em relacionamentos um-para-

muitos (1,N) ou (1, ∞) através da utilização de tabelas de interseção.

Dicionário de Dados

Introdução

Após a construção do RDM, deve ser definido o conteúdo exato de cada tabela de dados

que comporá a base de dados do sistema. Deverão ser detalhadas as características de

todos os dados que serão armazenados em cada tabela que descreve os atributos das

entidades e eventos definidos pelo modelo relacional de dados.

Para detalhar os dados que deverão estar contidos nas tabelas inicialmente devemos

considerar todas as entradas e saídas sobre as quais se tenha o máximo de informações.

Trabalhamos para frente a partir das entradas e para trás a partir das saídas, para definir

os dados de cada tabela. O objetivo é obter o menor número possível de dados em cada

tabela, suficiente para derivar as saídas (relatórios ou consultas na tela) e capturar a

essência das entradas. Entretanto, utilizando apenas esta técnica, estaremos correndo o

risco de não descobrir todos os dados necessários, principalmente por ser muito difícil

para os usuários de um sistema anteciparem toda a saída futura possível e toda a entrada

necessária.

Por esse motivo, após a definição inicial dos dados de cada tabela a partir das entradas e

saídas previstas devemos efetivamente visitar os locais nos quais os usuários efetuam

suas operações para observá-las e examinar todas as entidades (como produtos) e todos os

eventos (como vendas) a elas relacionados. Com esta visita poderemos verificar todos os

atributos que estas entidades e eventos possuem e que serão de interesse para o

fornecimento de informações; completando o que eventualmente tiver sido esquecido ou

não percebido pelos usuários na definição inicial.

Normalmente, toda entidade, como por exemplo, um produto, deve possuir um

identificador único e exclusivo, como um código; além disso, é preciso armazenar o seu

nome ou descrição, juntamente com a quantidade, o custo e o preço de venda. Produtos



69

grandes podem possuir também uma localização, um volume e um peso; enquanto que

produtos pequenos poderão estar acondicionados em embalagens com um determinado

número de unidades.

Por outro lado, todo evento também deverá receber um identificador exclusivo e único,

como um número de documento, quase sempre tem uma data de ocorrência, e muitas

vezes uma ou mais entidades relacionadas, como a venda de produtos a um cliente.

Finalmente, após a verificação dos dados que descrevem todas as entidades e eventos de

interesse do sistema in loco, você deve se perguntar:

"Se eu dirigisse este negócio, o que gostaria que fosse armazenado no sistema?"

Certamente, quanto mais você conhecer o negócio e compreender os objetivos dos

usuários em requisitar o sistema, tanto melhor poderá responder a esta pergunta. Contudo,

você não deverá tentar dizer a um empresário como a empresa dele deve ser

administrada, mas poderá certamente fazer sugestões. Em geral, é mais fácil oferecer uma

lista de sugestões de dados ao usuário e solicitar que ele elimine e/ou acrescente itens na

lista. Deste modo, você estará dizendo ao usuário: "Segundo meus limitados

conhecimentos do seu negócio, parece que seria útil ter essas informações armazenadas

no sistema. Há alguma coisa que eu esqueci? E, considerando o custo de coletar e

armazenar informações, há alguma coisa na lista que pode ser omitida sem lhe fazer

falta no futuro?" Ao formular estas perguntas, você estará efetivamente envolvendo o

usuário no projeto do sistema, fazendo com que ele se sinta comprometido com sua

definição e, portanto, sendo mais cuidadoso e responsável ao respondê-las.

A partir dos resultados obtidos você poderá produzir uma definição preliminar do

conteúdo de cada tabela de dados que descreve uma entidade ou um evento de interesse

para o sistema e, obviamente, para a organização.

Nome dos Dados

Cada dado deve possuir um nome exclusivo, e ser tão significativo quanto possível, sem a

inconveniência de ser longo. Há muitas formas e convenções que foram propostas para

dar nomes aos dados, você poderá utilizar uma delas ou criar a sua própria. Porém,

definindo-se por uma, procure mantê-la em todos os seus sistemas.

Recomendamos que cada dado possua uma descrição resumida, um nome completo e um

nome abreviado ou codificado. A descrição deverá explicar inteiramente a natureza do

dado e será utilizada para descrever o dado num dicionário de dados que fará parte da

documentação do sistema. O nome completo deverá ser o nome do dado que será

apresentado ao usuário na tela ou num relatório, identificando o dado. Finalmente, o

nome abreviado deverá ser o nome-código do dado dentro do sistema, ou seja, o nome do

dado dentro das tabelas de dados (nome do campo) e dentro dos programas que comporão

o sistema.

Por exemplo:



70

Nome Completo Nome Abreviado Descrição

Código do produto CodProd Código de identificação do produto.

Nome do produto NomProd Nome que identifica o produto.

Quantidade pedida QtdPed Quantidade de um produto que foi pedida por

um cliente.

Devido à limitação de 10 caracteres para identificar nomes de campos nas tabelas de

dados de alguns softwares e para economizar digitação e simplificar a programação,

recomendamos que os nomes abreviados dos dados tenham no máximo 10 posições.

Além disso, pode ser utilizado o sublinhado ( _ ) para separar nomes compostos, pois os

nomes abreviados não poderão conter espaços em branco. Por exemplo: cod_prod,

cod_cli, num_vend etc.

Sinônimos

Muitas vezes, nomes diferentes são utilizados para identificar uma mesma entidade ou

evento em locais diferentes de uma organização. Os termos "empregado", "funcionário"

ou "servidor" poderão ser utilizados em diferentes áreas para significar uma pessoa que

trabalha na organização. Eles são sinônimos e, embora seja melhor evitar a utilização de

sinônimos num sistema, eles podem ser tratados escolhendo-se um dos nomes como

sendo o principal e descrevendo os demais como sinônimos do nome principal. O mesmo

ocorre com os nomes de dados, por exemplo, "estado" e "uf" ou "cidade" e "município",

ou ainda, em alguns casos, "custo" e "preço".

Homônimos

A situação inversa também existe, ou seja, um determinado nome poderá ter significados

diferentes para entidades ou eventos distintos em diversas áreas da organização. Por

exemplo, o nome "preço", poderá significar o "preço unitário de venda" para o

departamento de vendas, o "preço unitário de custo" para o departamento de compras e o

"preço total de venda ou de compra" para o departamento de contabilidade.

Deve ficar suficientemente claro, dentro do contexto no qual o homônimo é utilizado, que

significado, dentre os diversos possíveis, ele terá. Se não se conseguir determinar com

clareza um significado único, então cada dado deverá receber um nome diferente.

Domínio

O domínio de um dado é o conjunto de valores válidos para ser seu conteúdo. Assim, o

domínio de uma data pode ser qualquer data válida posterior a 01/01/1900; o domínio do

preço de um produto pode ser um valor entre R$ 100,00 e R$ 2.000,00; o domínio da

sigla dos estados do Brasil é um par de letras contidas num conjunto bem definido; e

assim por diante. Se for possível determinar o domínio de um dado, você poderá definir

critérios de validação para determinar os valores aceitáveis durante a entrada ou edição de

dados.



71

Características dos Dados

Além do nome, da descrição, do nome abreviado e do domínio, outras características

relativas a cada elemento de dado devem ser definidas para descrever completamente o

conteúdo de uma tabela de dados:

1. Tipo de dado: refere-se ao conteúdo do dado, podendo ser normalmente, numérico

(NÚMERO, INTEIRO ou FLUTUANTE), cadeia de caracteres curta (TEXTO), data

(DATA), lógico (LOGICO) ou cadeia de caracteres longa (MEMO). Dependendo da

ferramenta de software que estiver sendo utilizada para implementar o sistema, estes

tipos poderão variar.

2. Tamanho do dado: refere-se ao tamanho ou ao número máximo de posições que

poderá assumir o valor ou conteúdo de cada dado. Normalmente, dados do tipo

numérico poderão assumir até 19 posições, com até 18 casas decimais; dados do tipo

caractere curto poderão assumir até 256 posições; dados do tipo data assumirão

automaticamente 8 posições; dados do tipo lógico apenas uma posição e dados tipo

memo ou caractere longo não precisam ter o comprimento pré-definido, podendo

assumir até 65.535 posições. Recomendamos que, em vez de solicitar que os usuários

especifiquem o comprimento dos dados, você peça exemplos dos valores de dados que

os usuários desejam armazenar nas tabelas e, a partir deles, especifique de forma

equilibrada (como uma média entre os maiores e os menores) os comprimentos ideais.

3. Formato do dado: refere-se à forma com que os dados deverão ser apresentados,

definindo as posições de determinados símbolos, como pontinhos, traços e barras,

geralmente contidos em códigos, ou a presença de pontos separando os milhares em

valores numéricos. Para definir o formato dos dados são utilizadas máscaras de

formatação, nas quais normalmente os símbolos "# ou 0" representam posições onde

somente devem ser aceitos dígitos numéricos; o símbolo "@", posições onde devem

ser aceitas letras alfabéticas ou espaços em branco. Por exemplo, o formato do dado

CPF deve ser assim representado como "000\.000\.000-00.

4. Máscara de Entrada: refere-se à forma com que os dados deverão ser digitados,

definindo as posições de determinados símbolos, como pontinhos, traços e barras,

geralmente contidos em códigos, ou a presença de pontos separando os milhares em

valores numéricos.

5. Legenda: especifica o rótulo a ser apresentado para identificar o dado em formulários

e relatórios.

6. Valor padrão: especifica um valor padrão a ser atribuído ao conteúdo do dado quando

este for deixado vazio.

7. Tipo de domínio: especifica se os valores de dados aceitáveis são definidos por

estarem numa lista (domínio discreto, como a sigla dos estados), ou por satisfazer

determinada regra (domínio contínuo, como faixa de valores numéricos, letras

maiúsculas etc.). Para um domínio discreto, os valores aceitáveis devem ser



72

relacionados numa tabela conveniente, junto com o significado de cada valor, pois os

significados serão utilizados pelo sistema. Por exemplo, o dado estado civil poderá

possuir o seguinte domínio discreto: S = solteiro, C = casado, V = viúvo, P = separado,

J = separado judicialmente e O = outros. Para um domínio contínuo, o critério de

validação deve ser especificado, relacionando, quando relevante, os valores máximos e

os mínimos aceitáveis. Em qualquer caso, deve ser especificado se o valor vazio ou

nulo, ou seja, ausência de valor, pode fazer parte do domínio do dado. Por exemplo,

dados chave não podem aceitar o valor nulo.

8. Regra de Validação: especifica uma regra que deve ser verificada para que os dados

sejam considerados válidos. Uma regra de validação pode ser uma expressão

matemática, obrigando um dado numérico a se situar dentro de uma determinada faixa

de valores válidos, ou uma expressão qualquer valide os dados digitados pelo usuário,

comparando-o inclusive com outros dados já digitados. Quando a regra validar o dado,

o mesmo será aceito e armazenado na tabela de dados; em caso contrário o sistema

deverá apresentar uma mensagem ao usuário informando que o dado está incorreto,

solicitando a digitação de dados válidos.

9. Texto de validação: especifica o texto a ser apresentado caso a regra de validação

falhe.

10.Requerido: indica se o dado deve ser obrigatoriamente informado.

11.Permitir comprimento zero: indica se o dado pode ficar vazio.

12.Indexado: indica se o dado será utilizado para a criação de um índice secundário de

acesso.

13.Alinhamento do texto: especifica o alinhamento do texto do conteúdo do dado

quando este for apresentado em formulários e relatórios.

14.Origem do dado: querendo dizer se os valores de dados são capturados fora do

sistema (como uma entrada de dados através de digitação), se são originados dentro do

sistema (como identificadores de transações, definidos pelo próprio sistema) ou se são

derivados de outros elementos de dados (como custo total = custo unitário x

quantidade, calculados pelo sistema). Em cada caso será necessário especificar como o

dado é obtido ou gerado, ou seja, a partir de que documento, de que transação ou de

que cálculo o valor do dado é obtido.

15.Responsabilidade pelo dado: revela a pessoa ou a unidade da empresa responsável

pelo dado, ou seja, que tenham a autoridade final pela correta maneira como o dado

deve ser inserido e atualizado no sistema. Por exemplo, o Gerente de Pessoal é

responsável pelo dado salário, uma vez que somente ele pode autorizar uma alteração

do valor do salário de qualquer funcionário.



73

Dados-chave

Tendo já definido os dados que constituirão os campos de uma tabela de dados, conforme

o RDM um ou mais dados deverão ser escolhidos para funcionar como chave primária ou

identificadora de registros, de modo que sabendo o valor da chave, você poderá acessar

um determinado registro da tabela, ou seja, a chave que identifica cada registro

armazenado numa tabela de dados. Toda tabela de dados deverá ter pelo menos um

campo definido como chave primária ou identificadora.

Assim, o valor contido numa chave primária deverá ser exclusivo, ou seja, único por

registro da tabela e, uma vez designado, nunca deverá ser alterado. Além disso, um dado

que faça parte de uma chave (primária ou estrangeira) nunca deverá possuir um valor

ausente ou nulo, pois perderá sua utilidade, tanto como identificador de registros como

apontador de relacionamentos entre tabelas de dados.

Se uma chave primária não existir naturalmente entre os dados que descrevem as

entidades e os eventos de interesse do sistema, uma chave identificadora exclusiva deverá

ser criada, como código do produto, número do funcionário, número do pedido etc. Esta

chave primária poderá ser arbitrária, designada possivelmente pelo próprio sistema,

incrementando um número para cada novo registro, com o único objetivo de poder

acessá-los inequivocamente. Em qualquer caso, a chave primária assim criada deverá ser

concisa para facilitar a digitação sem erros e o acesso inequívoco aos dados de cada

registro.

Normalmente, a chave primária determinará os campos que serão utilizados para a

criação do índice primário de acesso à tabela de dados, permitindo, desta forma, a

localização instantânea dos registros que as possuem.

Múltiplas Chaves

Em algumas situações, há mais de um campo ou conjunto de campos que serão utilizados

para identificar exclusivamente cada registro numa tabela de dados. Neste caso,

deveremos certificar-nos de que todos os campos que formarão a chave primária sejam

não nulos, não sejam alterados e que sua combinação seja exclusiva para identificar cada

registro inequivocamente.

Em outras situações, poderá existir mais de um campo que possa ser utilizado como

chave identificadora de registros. Por exemplo, o número do empregado, seu CIC e seu

RG poderão ser utilizados para identificá-lo. Neste caso, para decidir qual dos campos

será a chave primária deveremos verificar se há garantia de exclusividade, se os dados

não serão alterados e se não existirão dados nulos. O campo que melhor satisfizer estas

características deve ser escolhido como chave primária.



74

Normalização de Tabelas de Dados

Introdução

Um sistema de informação utiliza um conjunto de tabelas de dados relacionadas,

conforme definido pelo RDM e pela modelagem de dados, nos quais são armazenados os

dados que descrevem as entidades e eventos sobre os quais se deseja obter informação.

Podemos definir uma base de dados ou banco de dados como sendo este conjunto de

tabelas de dados vinculadas ou relacionadas, dentro de um determinado contexto,

definido pelos objetivos do sistema em questão.

Definidos as tabelas e os respectivos dados que constituirão a base de dados do sistema, o

próximo passo do projeto é simplificá-los para adequá-los ao processamento do

computador, removendo dados redundantes e grupos repetitivos. Este processo de

simplificação de tabelas de dados que compõem uma base de dados é denominado

normalização.

Os conceitos e as técnicas de normalização de tabelas de dados foram desenvolvidos pelo

Dr. E.F. Codd da IBM e sua equipe, quando pesquisavam a matemática de conjuntos. No

conjunto matemático, nenhuma duplicata de qualquer objeto é permitida. Como uma

tabela é um conjunto de registros, na teoria nenhum registro, numa tabela de dados, pode

ser uma duplicata de qualquer outro. Além disso, de acordo com a teoria dos conjuntos,

foram estabelecidos cinco tipos de tabelas normalizadas, denominados, em ordem

crescente de simplicidade: primeira forma normal (1FN), segunda forma normal (2FN) e

terceira forma normal (3FN), quarta forma normal (4FN) e quinta forma normal (5FN).

Através da normalização, as tabelas de dados tornam-se mais adequadas para o

armazenamento e atualização de dados, evitando-se redundâncias e inconsistências na

base de dados. O processo de normalização consiste, basicamente, na aplicação de um

conjunto de regras para definir adequadamente os dados ou campos que comporão as

tabelas de dados. Essas regras visam:

Minimizar redundâncias;

Eliminar anomalias de atualização;

Prover o melhor caminho de acesso a qualquer dado;

Assegurar resistência a manutenções no modelo de dados;

Evitar dados não identificáveis através de definição rigorosa de identificadores e

relacionamentos.

Definiremos a seguir as três primeiras formas normais e discutiremos a maneira de

simplificar as tabelas de dados até a terceira forma normal. Em geral, apenas as três

primeiras regras básicas de normalização são suficientes para resolver a grande maioria

dos casos. Poderíamos resumir estas três formas normais mais utilizadas da seguinte

forma:



75

1. Eliminar dados repetitivos;

2. Eliminar dados redundantes;

3. Eliminar dados dependentes.

Primeira Forma Normal (1FN)

Refere-se a qualquer tabela que possua apenas um valor por campo, ou interseção

linha/coluna. O relacionamento entre a chave primária de uma tabela e cada um dos

outros campos (dados ou colunas) deve ser de um-para-um (nesta direção). Cada um dos

campos que não faz parte da chave primária é chamado "funcionalmente dependente"

desta chave. Tabelas de dados que obedecerem esta regra estarão na Primeira Forma

Normal (1FN).

De uma maneira prática, devemos remover grupos repetidos de dados, até que cada dado

tenha uma chave primária para cada ocorrência.

A tabela de dados exemplificada a seguir não está sob qualquer forma normal; entre

outras coisas, há mais de um valor ou supermercado no campo loja.

Produtos em Estoque Não Normalizado

Produto Loja

Arroz Sé, Eldorado, Carrefour, Jumbo

Feijão Sé, Carrefour, Jumbo, Minibox

Farinha Eldorado, Carrefour, Jumbo

Açúcar Carrefour, Jumbo, Minibox

Como pode ser percebido, no campo loja, existem vários valores de dados (grupos

repetidos). Através desta tabela podemos obter a informação de que existe, por exemplo,

arroz nos supermercados Sé, Eldorado, Carrefour e Jumbo. Entretanto, como poderemos

saber a quantidade de arroz existente em cada um?

De acordo com a primeira forma normal esta tabela deve ser revisada para que sejam

eliminados os grupos repetidos, ou seja, no campo loja deve haver o nome de apenas um

supermercado. Isso implicará na criação de um número maior de linhas ou registros na

tabela, pois deverá haver uma linha para cada produto em cada loja. Contudo, a partir daí,

poderemos facilmente registrar a quantidade existente de cada produto em cada loja.

Após a aplicação da primeira regra de normalização, a tabela de dados dos produtos em

estoque assume a seguinte estrutura de dados:



76

Produtos em Estoque na 1FN

Produto Loja Telefone Quantidade. Preço Total

Arroz Sé 213-0909 200 10,00 2.000,00

Arroz Eldorado 814-0845 500 9,00 4.500,00

Arroz Jumbo 453-1111 700 11,00 7.700,00

Arroz Carrefour 864-1212 1000 8,00 8.000,00

Feijão Sé 213-0909 300 13,00 3.900,00

Feijão Carrefour 814-0845 500 12,00 6.000,00

Feijão Jumbo 453-1111 200 14,00 2.800,00

Feijão Minibox 284-5967 800 11,00 8.800,00

Farinha Eldorado 814-0845 400 8,00 3.200,00

Farinha Carrefour 864-1212 600 9,00 5.400,00

Farinha Jumbo 453-1111 100 7,00 700,00

Açúcar Carrefour 814-0845 1100 4,00 4.400,00

Açúcar Jumbo 453-1111 900 5,00 4.500,00

Açúcar Minibox 284-5967 1200 3,00 3.600,00

Segunda Forma Normal (2FN)

Uma tabela de dados na primeira forma normal também estará na segunda forma normal

se todo campo não-chave depender totalidade da chave primária.

Para testar se uma tabela de dados está na segunda forma normal devemos fazer

inicialmente as seguintes perguntas:

1. Qual é o campo ou conjunto de campos que constitui a chave primária da tabela? Se a

chave primária for concatenada, isto é, formada por mais de um campo, perguntamos

também:

2. Há qualquer campo não-chave que dependa de apenas parte da chave primária?

Na tabela do exemplo anterior, o produto, por si só não é suficiente para identificar

inequivocamente um determinado registro, pois vários registros possuem o mesmo

produto. Para obtermos uma chave primária exclusiva devemos concatenar produto com

loja, pois não há nenhuma chave "produto + loja" duplicada. Neste caso, como a chave é

concatenada, devemos ainda fazer a segunda pergunta para cada campo não-chave:

1. A quantidade em estoque depende apenas de parte da chave? A resposta é não, é

preciso conhecer tanto o produto como a loja para se obter a quantidade.

2. O preço depende apenas de parte da chave? A resposta também é não, é preciso

conhecer tanto o produto como a loja para se obter o preço.

3. O telefone da loja depende apenas de parte da chave? Neste caso a resposta é sim, pois

se você conhecer a loja também poderá saber qual é o seu telefone, independentemente



77

do produto. Portanto, a tabela exemplificada anteriormente não está na segunda forma

normal, pois ela não passou pelo teste.

Quando uma tabela de dados não está na segunda forma normal, a base de dados não

estará correta pelas seguintes razões:

1. A tabela de dados ocupará mais espaço no disco do que seria necessário, pois o

número do telefone se repete para cada produto armazenado na mesma tabela;

2. Se uma loja mudar de número de telefone, todos os registros de produtos para aquela

loja deverão ter o campo telefone alterado;

3. Se ocorrer algum problema com o processo de atualização dos dados, uma mesma loja

poderá aparecer com números de telefones diferentes, dependendo de qual registro

seja acessado posteriormente, ou seja, a integridade da base de dados estará perdida;

4. Quando uma loja possuir um único produto e seu registro for eliminado (por que

acabou o estoque), também será eliminado o telefone da loja, pois poderá não haver

outro lugar na base de dados que o armazene.

Para evitar estes problemas, a tabela anterior deverá ser dividida em duas, como ilustrado

a seguir.


Produto Loja Quantidade Preço Total

Arroz Sé 200 10,00 2.000,00

Arroz Eldorado 500 9,00 4.500,00

Arroz Jumbo 700 11,00 7.700,00

Arroz Carrefour 1000 8,00 8.000,00

Feijão Sé 300 13,00 3.900,00

Feijão Carrefour 500 12,00 6.000,00

Feijão Jumbo 200 14,00 2.800,00

Feijão Minibox 800 11,00 8.800,00

Farinha Eldorado 400 8,00 3.200,00

Farinha Carrefour 600 9,00 5.400,00

Farinha Jumbo 100 7,00 700,00

Açúcar Carrefour 1100 4,00 4.400,00

Açúcar Jumbo 900 5,00 4.500,00

Açúcar Minibox 1200 3,00 3.600,00



78

Lojas

Loja Endereço Telefone

Sé Rua Inflação, 100 213-0909

Eldorado Rua Carestia, 50 814-0845

Jumbo Rua Salário Mínimo, 10 453-1111

Carrefour Av. Preço Alto, 1000 814-0845

Minibox Rua Novo Pacote, 5 284-5967

Agora as duas tabelas estão na segunda forma normal. A tabela de produtos em estoque

está na segunda forma normal porque os campos não-chave (quantidade, preço e valor

total) são dependentes de toda chave primária concatenada produto+loja e de nada mais.

A segunda tabela, lojas, também está na segunda forma normal porque ele não possui

uma chave concatenada e, portanto, uma coluna não-chave como endereço ou telefone

naturalmente será dependente da totalidade do único campo chave, que é a loja.

Analisando sob outro ângulo, é fácil perceber que a tabela, apesar de estar na primeira

forma normal, contém dados descrevendo duas coisas distintas: produtos e lojas. Como

regra geral e importante, uma tabela de dados numa base de dados deve armazenar dados

que descrevam apenas uma entidade ou evento. Portanto, uma tabela de dados, para estar

na segunda forma normal deve conter dados apenas sobre um único objeto de informação

ou uma única classe de objetos. Neste nosso exemplo, a primeira tabela agora contém

apenas dados sobre produtos em estoque e o segundo sobre lojas.

Terceira Forma Normal (3FN)

Uma tabela na segunda forma normal também estará na terceira forma normal se nenhum

campo não-chave depender de qualquer outro campo não-chave.

Para verificar se uma tabela na segunda forma normal também está na terceira forma

normal devemos perguntar: algum campo não-chave é dependente de qualquer outro

campo não-chave?

A tabela dos produtos em estoque possui três campos (ou colunas) não-chave:

quantidade, preço e valor total. Se soubermos a quantidade em estoque e o preço,

saberemos o valor total em estoque. Portanto, o campo "valor total" é dependente de dois

campos não-chave, pois pode ser obtido a partir da quantidade multiplicada pelo preço.

Concluímos que a tabela de produtos em estoque não está sob a terceira forma normal.

Se o campo "valor total" for eliminado, a tabela de produtos em estoque passa a estar na

terceira forma normal, ocupando menos espaço no disco, sem qualquer perda de

informação.



79


Produto Loja Quantidade Preço

Arroz Sé 200 10,00

Arroz Eldorado 500 9,00

Arroz Jumbo 700 11,00

Arroz Carrefour 1000 8,00

Feijão Sé 300 13,00

Feijão Carrefour 500 12,00

Feijão Jumbo 200 14,00

Feijão Minibox 800 11,00

Farinha Eldorado 400 8,00

Farinha Carrefour 600 9,00

Farinha Jumbo 100 7,00

Açúcar Carrefour 1100 4,00

Açúcar Jumbo 900 5,00

Açúcar Minibox 1200 3,00

Resultado da Normalização de Tabelas

Apesar de existirem as simplificações da quarta e da quinta forma normal, que ainda

poderão ser feitas em tabelas de dados, via de regra, as tabelas que estiverem na terceira

forma normal não contém redundâncias, são simples de serem compreendidos, simples de

serem atualizados e seus dados podem ser facilmente recuperados. Já estão, portanto,

numa forma adequada para serem implementados num sistema de informação.

Ao adquirir experiência no desenvolvimento de sistemas, a simplificação de tabelas até a

terceira forma normal se tornará praticamente automática e poderá já ser feita durante a

elaboração do RDM. Contudo, a simplificação dos dados também requer conhecimento

da empresa, dos métodos e regras por ela utilizados, os quais determinam os

relacionamentos entre os dados, e as possíveis alterações que esses relacionamentos

possam sofrer.

O processo de normalização pode resultar em um grande número de tabelas de dados.

Entretanto, uma boa parte das tabelas resultantes possuirá apenas dois campos: um código

de algum tipo, que será a chave primária, e o significado correspondente a cada código.

Considere a tabela de turmas ilustrada a seguir. Esta tabela não está na terceira forma

normal porque há uma dependência entre campos não-chave: se você souber o código da

disciplina, você saberá o seu nome, e se você souber o número do professor, também

poderá obter o seu nome. Portanto, esta tabela deve ser decomposta em três outras tabelas

que são a seguir apresentadas.



80

Tabelas com apenas dois campos, como professores e disciplinas, são tabelas de

interpretação ou tradução de códigos. Elas contem, em geral, dados relativamente

estáveis, isto é, que raramente são alterados.

Tabela de Turmas não Normalizada

Sem. Matéria Nome Sala Hora Dias Prof. Nome

1/00 EAD-151 Proc.de Dados 2 9:00 3as e 6as 123 Vidal

2/00 EAD-274 Análise de Sistemas 4 7:30 Sábado 345 Hiroo

1/00 EAD-456 Sistemas Especialistas 9 7:30 4as e 6as 234 Ronaldo

1/01 EAD-151 Proc.de Dados 3 7:30 2as e 4as 023 Aloísio

2/01 EAD-274 Análise de Sistemas 6 8:30 Sexta 145 Nicolau

1/01 EAD-456 Sistemas Especialistas 7 8:30 3as e 6as 234 Ronaldo

2/01 EAD-556 Inteligência Artificial 1 9:00 Sábado 001 Einsten

2/01 EAD-455 Bancos de Dados 5 7:30 3as e 5as 354 Hiroo

Tabela de Turmas Normalizada

Sem. Disciplina Sala Horário Dias Professor

1/00 EAD-151 2 9:00 3as e 6as 123

2/00 EAD-274 4 7:30 Sábado 345

1/00 EAD-456 9 7:30 4as e 6as 234

1/01 EAD-151 3 7:30 2as e 4as 123

2/01 EAD-274 6 8:30 Sexta 345

1/01 EAD-456 7 8:30 3as e 6as 234

2/01 EAD-556 1 9:00 Sábado 001

2/01 EAD-455 5 7:30 3as e 5as 354

Tabela de Disciplinas

Disciplina Nome

EAD-151 Processamento de Dados

EAD-274 Análise de Sistemas

EAD-456 Sistemas Especialistas

EAD-556 Inteligência Artificial

EAD-455 Bancos de Dados



81

Tabela de Professores

Número Nome

123 Antonio Geraldo Vidal

345 Hiroo Takaoka

234 Ronaldo Zwicker

145 Nicolau Reinhard

023 Aloísio Pinto Alves

001 Albert Einsten da Silva

Utilização de Índices

A criação de um arquivo de índice acelera a recuperação dos dados da tabela, pois este

especifica onde, no disco, os registros desejados devem ser encontrados. Assim, em

princípio, qualquer registro de uma tabela de dados indexado pode ser encontrado por

apenas dois movimentos da cabeça de leitura disco (um para o índice, e outro para o

localização do registro na tabela), em vez de uma quantidade enorme de movimentos para

pesquisar a tabela inteira, linha por linha ou registro por registro.

Entretanto, esta velocidade de recuperação de dados em tabelas indexadas possui dois

custos:

1. O espaço em disco ocupado pelo arquivo de índice;

2. O tempo adicional necessário para cada atualização de dados, pois o arquivo de índice

precisa ser atualizado em conjunto com a tabela de dados.

Se houver espaço disponível em disco, o espaço adicional ocupado pelos arquivos de

índice poderá não ser problema, e a melhoria de desempenho será compensadora. Da

mesma forma, gastar um pouquinho mais de tempo para atualizar uma tabela devido à

atualização simultânea dos arquivos de índice associados, em geral, não é um fator crítico

para a maioria das aplicações. Entretanto, quanto mais arquivos de índices forem criados,

mais lenta será a atualização dos dados e mais espaço em disco será consumido. Portanto,

como regra geral, você deve criar o mínimo de índices necessários para fornecer um

desempenho adequado:

1. Para a chave identificadora ou primária de cada tabela de dados deve ser criado um

arquivo de índice exclusivo. Isto deve ser feito de qualquer modo para garantir a

unicidade do valor da chave (registros não duplicados), mas também é importante para

o desempenho, pois a chave será o argumento de pesquisa mais freqüentemente

utilizado para a atualização e recuperação de registros e provavelmente a chave

também será o campo (ou conjunto de campos) utilizado para interligar uma tabela a

outras.



82

2. Geralmente, as chaves estrangeiras de cada tabela também devem ser indexadas.

Chaves estrangeiras são campos ou concatenações de campos que possuem valores

que são chaves primárias em outras tabelas de dados relacionadas.

3. A seguir, cada campo que possa ser utilizado em uma consulta de resposta rápida, em

geral na tela, deve ser considerado candidato à indexação (chaves candidatas).

4. Finalmente, qualquer campo que for utilizado para ordenar uma tabela de dados é

candidato para ser chave de um arquivo de índice.

Desempenho do Sistema

Dois casos muito comuns de queda de desempenho são o excesso de relacionamento

entre tabelas e a totalização de dados.

No primeiro caso, mesmo que, independentemente dos índices que tiverem sido criados,

o tempo de resposta envolvendo o relacionamento de várias tabelas não for aceitável,

poderá ser necessário efetivar o relacionamento, isto é, combinar fisicamente duas ou

mais tabelas para fazer uma tabela interligada que seja mantida como um única tabela,

desrespeitando as regras de normalização. Se o sistema for corretamente implementado

para tratar as tabelas combinadas desta forma não haverá problema em desrespeitar as

regras de normalização.

No segundo caso, mesmo que as tabelas estejam indexadas e otimamente relacionados,

você ainda poderá verificar que levará muito tempo para o sistema responder a consultas

envolvendo totalizações. A solução será criar uma nova tabela, especialmente para a

totalização, que seja periodicamente processado, e as totalizações nela atualizadas. O

inconveniente aqui é que as atualizações dos totais não serão on-line e, conseqüentemente

os totais poderão estar desatualizados se a rotina de atualização ainda não tiver sido

processada.

Além destes casos, existem vários outros, que dependem de particularidades de cada

sistema, nos quais será válido desrespeitar as regras de normalização para melhorar o

desempenho e facilitar sua implementação física, obtendo-se uma base de dados

equilibrada. Cabe ao desenvolvedor decidir sobre quando e como será válido desrespeitá-

las. Entretanto, as melhores decisões virão apenas com a experiência.



83

Análise das Regras do Negócio

Introdução

Além de coletar, armazenar e fornecer informações, um sistema pode automatizar

determinadas regras que conduzem os negócios das organizações. Estas regras podem ser

traduzidas por parâmetros, decisões ou cálculos que são efetuados durante os processos

de negócio. Se estas regras forem repetitivas e puderem ser estruturadas e especificadas

de modo a poderem ser automatizadas, poderão ser embutidas nos programas de

computador que comporão o sistema de informação a ser desenvolvido.

Existem várias técnicas para modelar as regras de negócio que devem ser embutidas num

sistema de informação. Normalmente, na modelagem de regras de negócio de um sistema

são utilizadas várias delas, inclusive para modelar uma mesma regra ou conjunto de

regras. O objetivo é torná-las suficientemente claras, estruturadas e objetivas para

poderem ser implementadas através de uma linguagem de programação no sistema.

Lógica Estruturada

A técnica da Lógica Estruturada modela a lógica das regras de negócio utilizando

construtos da programação estruturada, são eles:

SE...ENTÃO

CASO1...CASO2...CASO3...OU ENTÃO

ENQUANTO...

ATÉ QUE...

DE 1 A N

Esta técnica é a que mais se aproxima de uma linguagem de programação de

computadores e por esse motivo, facilita o entendimento dos programadores. Ela modela

e descreve a execução de ações e define procedimentos de cálculo e de decisão através de

palavras-chave que equivalem aos comandos de uma linguagem de programação. Por

exemplo:

SE Tipo do Contribuinte = Fundação

ENTÃO Alíquota do ICMS = 0,00%

SE Tipo do Contribuinte = Comércio

ENTÃO Alíquota do ICMS = 18,00%

Ou alternativamente:



84

CASO Tipo do Contribuinte = Fundação

Alíquota = 0,00%

CASO Tipo do Contribuinte = Comércio

Alíquota = 18,00%

Tabelas de Decisão

A técnica das Tabelas de Decisão é particularmente útil quando o número de Condições

para aplicação de Regras, o número de Ações decorrentes da aplicação das Regras, e o

próprio número de Regras é muito grande.

As Tabelas de Decisão ajudam a estruturar todas as Condições, Regras e Ações

envolvidas no processo de negócio e, a partir daí, determinar em quais situações são

aplicáveis.

Exemplo de Tabela de Decisão

Condições / Ações Regra 1 Regra 2 Regra 3 Regra 4 Regra 5 Regra 6

Tipo de Funcionário

Horas Trabalhadas

Pague salário base

Pague horas extras

Para facilitar a construção de uma Tabela de Decisão pode ser seguidos os passos abaixo:

1. Identifique as condições e os valores que cada uma pode assumir;

2. Identifique todas as possíveis ações que podem ocorrer para cada condição;

3. Relacione todas as possíveis regras que podem ser aplicadas;

4. Defina as ações para cada regra;

5. Simplifique a tabela de decisão construída.

Árvores de Decisão

A técnica de Árvores de Decisão é muito utilizada para detalhar problemas de decisão,

ilustrando os diversos cursos de ação que podem ser seguidos, dependendo de decisões

tomadas a partir da verificação de determinados eventos.

Sua construção deve ser intuitiva, considerando que os eventos devem os nós da árvore,

as decisões ou cursos de ação os seus ramos e as ações as suas folhas, conforme ilustra a

figura a seguir.



85

Diagramas de Transição de Estados

A técnica dos Diagramas de Transição de Estados representa os diversos Estados que um

determinado processo de negócio pode assumir e as ações que levam de um Estado para

outro. Como ilustrado na figura a seguir, sua idéia é representar cada Estado e como as

mudanças ocorrem.

A construção de Diagramas de Transição de Estados deve ser intuitiva, podendo ser

utilizados os seguintes passos para facilitar o processo:

1. Identifique os possíveis estados ou o estado inicial;

2. Desenhe retângulos representando cada um dos estados identificados;

3. Conecte os estados com setas identificando as transições;

4. Cada estado deve levar a outro ou a vários outros estados;

5. Identifique as setas de transição com nomes que descrevem seus eventos;

6. Relacione as ações apropriadas sob cada retângulo de estado;

7. Considere reações a eventos inesperados;

8. Analise o diagrama para determinar se ele deve ser decomposto;

9. Discuta o diagrama com a equipe do projeto para assegurar consistência e

precisão.

1

2

Ação A

Ação B

Ação C

Ação D

Sim

Não

=1

=2

=3

Permitem melhor comunicação do que tabelas de decisão



86

Construção do Modelo do Sistema

Módulos do Sistema

Na grande maioria dos sistemas, o modelo de processos do negócio precisa ser

subdividido em partes contendo procedimentos automatizados e/ou manuais, para que o

sistema possa ser desenvolvido e executado em unidades menores, mais fáceis de serem

implementadas, testadas e operacionalizadas.

Estas partes do BPM, que denominaremos de módulos, poderão ser um programa, um

procedimento manual ou automatizado, uma relação de operações ou comandos, ou uma

combinação dos três. Um módulo sempre será invocado como uma unidade, normalmente

por uma opção de um menu, e constitui uma operação ou procedimento completo que o

sistema deve executar. Deve ser uma operação que possa ser vista pelos próprios usuários

do sistema como uma unidade.

Normalmente, os módulos estão relacionados com entradas e saídas de dados,

manutenção de tabelas, cálculos e outras operações especiais que o sistema deve efetuar.

As seguintes operações poderiam ser vistas como sendo módulos de um sistema:

Processamento de um pedido de compra;

Cálculo da folha de pagamento;

Ordem Aberta Validando OrdemCalculando

Ordem

ErroAtualizando

Dados

Gravando OrdemFechando Ordem

Aguardando

Ação Ação Ação

Ação

Ação

Ação Ação Ação

Ação

Ação

Ação

Ação

Ação

Ação



87

Emissão de relatórios;

Cadastro de novos produtos;

Alteração de dados de clientes;

Exclusão de um fornecedor;

Gravação do histórico de vendas;

Gravação de cópias de segurança das tabelas;

Etc.

A divisão de um sistema em módulos deve ser natural, ou seja, determinados

procedimentos ou operações, que guardem entre si uma mesma relação de contexto ou

função devem ser agrupados em um módulo. Os processos definidos pelo BPM e as

entidades e os eventos descritos no RDM podem ser agrupados ou categorizados para

definir os módulos do sistema.

Após este trabalho, uma relação de todos os módulos deve ser efetuada, e cada um deverá

receber números ou nomes que correspondam aos processos lógicos definidos no BPM,

que através deles serão implementados.

Diagrama Hierárquico do Sistema

Quanto maior for o sistema sendo projetado, maior será o número de módulos necessários

para implementar todos os processos e operações previstas no BPM.

Os módulos definidos, de acordo com o contexto e função no qual se encaixam,

normalmente guardam uma relação de hierarquia entre si, ou seja, existem níveis de

processos e operações que serão desempenhados pelo sistema, do mais abrangente para o

mais específico. Esta hierarquia de módulos dá origem ao que denominamos árvore do

sistema. A árvore do sistema é um diagrama, semelhante a um organograma, que

identifica cada um dos módulos e a hierarquia existente entre eles. Normalmente, a árvore

do sistema determina a estrutura de menus de operações do sistema, pois cada módulo, de

acordo com o seu nível, dará acesso ou executará uma determinada operação.

Recomendamos que a árvore do sistema sempre seja desenhada. Além de naturalmente

definir a hierarquia de operações e correspondentes menus de opções para o

desenvolvedor, ela fornece aos usuários uma idéia bastante clara da abrangência e da

estrutura de operação do sistema.



88

Especificação de Módulos do Sistema

Introdução

Tendo sido definidos os principais módulos e elaborada a árvore do sistema, como cada

um deles está relacionado com o modelo de processos do negócio e, conseqüentemente,

com as tabelas da base de dados do sistema, seu desenvolvimento e testes deverão ser

planejados.

Normalmente, é produzida e revista uma especificação escrita para cada módulo. Esta

especificação, em teoria, deverá conter toda informação necessária para que alguém que

conheça a ferramenta de software com a qual será desenvolvido o sistema possa produzir

o código ou programas necessários para cada um de seus módulos.

Entretanto, à medida que as ferramentas ficam mais potentes e forem construídas

bibliotecas de rotinas e/ou objetos, o código do sistema se assemelhará cada vez mais

com a própria especificação dos módulos, de modo que eventualmente a especificação

desaparecerá como um documento distinto, e cada módulo será gerado diretamente por

alguém que conheça a empresa.

Utilizando uma ferramenta moderna para desenvolver o sistema, normalmente há dois

tipos de divisão do trabalho de especificação e codificação de seus módulos:

Uma pessoa: implementação na qual o desenvolvedor, além da especificação dos

módulos, também é responsável pela sua codificação e testes;

Várias pessoas: implementação em que o desenvolvedor especifica os módulos, e

um ou mais programadores os codificam e testam, trabalhando em contato íntimo

com o desenvolvedor.

Implementação por Uma Pessoa

Através da implementação por "uma pessoa", os módulos do sistema precisam ser

especificados apenas até o ponto em que o desenvolvedor tenha um quadro mental claro

dos formatos de entrada e saída de dados, e da lógica interna, pois a área do modelo de

processos do negócio envolvida foi definida e as tabelas a serem acessadas também já

foram definidas.

Se as telas ou formulários do sistema forem gerados por um construtor automático, o

desenvolvedor deve saber que campos ou dados aparecerão em cada tela, mas poderá

utilizar o próprio construtor de telas para definir a posição exata dos campos. Se não for

utilizado um construtor de telas e cada formato de tela tiver que ser codificado

detalhadamente, será mais rápido produzir em papel um layout exato da tela, antes de

começar a codificar.

Se os relatórios forem gerados por um "construtor automático de relatórios", o

desenvolvedor deve saber que dados serão impressos em cada relatório, mas poderá

utilizar o próprio construtor de relatórios para definir a posição exata dos dados. Se não



89

for utilizado um construtor de relatórios e cada um tiver que ser codificado

detalhadamente, será mais rápido produzir em papel um layout exato de cada relatório,

antes de começar a codificá-los.

Se o menu de operações do sistema for gerado por um "construtor automático de menus",

o desenvolvedor deve utilizar diretamente a árvore do sistema para defini-lo, associando a

cada opção a tela, o relatório ou a operação a ser executada.

Implementação por Várias Pessoas

Através da implementação por "várias pessoas", o desenvolvedor precisa entregar:

1. O BPM do sistema como um todo;

2. O RDM do sistema;

3. O conteúdo das tabelas de dados com o detalhamento de cada dado;

4. As regras de negócio;

5. A árvore do sistema;

6. Os layouts de telas ou formulários e de relatórios que tiverem sido definidos até o

momento para cada módulo considerado;

7. Explicações e detalhes para os textos de diálogos sistema x usuário;

8. Explicações e detalhes para a lógica de programação ou regras de negócio de cada

processo de cada módulo.

Neste caso, os programadores precisam ser orientados sobre as características da empresa

e sobre os objetivos do sistema. A interseção entre a análise e a programação não será

distinguível no projeto por "várias pessoas". Os programadores poderão trabalhar em

contato com o usuário para refinar detalhes de formatos de tela, relatórios, diálogos

sistema x usuário e a própria lógica dos módulos.

Diálogo Sistema x Usuário

Além da especificação dos formatos de tela e relatórios e da própria lógica dos módulos,

é importante ter-se uma definição clara dos diálogos do sistema com o usuário ou

operador.

A representação dos diálogos pode ser feita como se fosse um roteiro de peça de teatro.

Um trecho de definição de diálogos sistema x usuário, seguindo o roteiro peça teatral é

ilustrado a seguir.

A especificação do diálogo sistema x usuário deve ser lógica, simples, clara e objetiva.

Detalhes devem ser omitidos, e apenas o fluxo lógico essencial deve ser especificado.

Tenha em mente que um desenvolvedor ou programador não gosta de ler muito papel, e

os detalhes de programação devem fazer parte de sua qualificação como tal.



90

Ator Ação

Sistema Solicita a senha de acesso.

Usuário Digita a senha.

Sistema Apresenta o menu principal se a senha estiver correta.

Sistema Apresenta uma mensagem de erro e finaliza se a senha estiver incorreta.

Usuário Escolhe a opção para inclusão de pedidos de venda.

Sistema Apresenta a tela de entrada de pedidos de venda e solicita o número do pedido.

Exemplo de Especificação de Módulo

Definição

Nome: Entrada de Pedidos de Vendas.

Descrição: Permite que o vendedor digite os produtos solicitados pelo cliente, bastando

digitar o número do pedido, o código do cliente, o código dos produtos e as

respectivas quantidades desejadas.

Processamento: Todo o tempo em que a empresa estiver aberta. Iniciado por entrada on-line.

Trecho do BPM



91

Trecho do RDM

Formulário de Entrada de Dados

PEDIDOS/INCLUSÃO SISTEMA SAO

PEDIDO Nº: 0001

CLIENTE: 012 AGV TREIN.DESENV.DE SISTEMAS LTDA.

VENDEDOR: 001 ROLANDO LERO

DATA: 30/10/2001

ICMS: 18,00%

Código Produto Preço Qtd. Total

1.1.001 Disquete 3 1/2" 1,00 20 20,00

2.2.002 Pacote Papel Carta 10,00 3 30,00

3.3.003 Cartucho para Impressora 25,00 4 100,00

. . . . .

. . . . .

. . . . .

Relatório de Saída de Dados

===========================================================

SISTEMA DE ADMINISTRAÇÃO DE OPERAÇÕES

AGV INFORMÁTICA LTDA.

===========================================================

CLIENTE: 012 AGV TREIN.DESENV.DE SISTEMAS LTDA.

VENDEDOR: 001 ROLANDO LERO

DATA: 30/10/2001

ICMS: 18,00%

-----------------------------------------------------------



92

Código Produto Preço Qtd. Total

1.1.001 Disquete 3 1/2" 1,00 20 20,00

2.2.002 Pacote Papel Carta 10,00 3 30,00

3.3.003 Cartucho Impressora 25,00 4 100,00

-----------------------------------------------------------

TOTAL 150,00

IMPOSTO 27,00

TOTAL GERAL 177,00

===========================================================

Detalhes do Processamento

Operador Sistema

Digita o número do pedido Verifica o pedido já está cadastrado. Se estiver, apresenta mensagem de erro e solicita

um novo número. Se não estiver, solicita a data do pedido.

Digita a data do pedido Não aceita enquanto a data não for válida.

Digita o código do cliente Verifica se o cliente existe. Se existir, apresenta o nome do cliente. Se não existir,

solicita novamente até que seja digitado um cliente válido, ou seja cancelado com

<Esc>.

Digita o código do vendedor Verifica se o vendedor existe. Se existir, apresenta o nome do vendedor. Se não existir,

solicita novamente até que seja digitado um vendedor válido, ou seja cancelado com

<Esc>.

Digita o código do produto Verifica se o produto existe. Se existir, apresenta o nome do produto e o preço de

venda. Se não existir, solicita novamente até que seja digitado um produto válido, ou

seja finalizado com <Esc>.

Digita a quantidade pedida Verifica se há saldo no estoque suficiente para atender o pedido. Se não houver,

apresentar mensagem recusando o produto e solicitar outro Se houver aceita o produto

e dá baixa no saldo do estoque.

Altera o preço de venda Registra o novo preço de venda.

Digita o código de outro

produto

Se o código do produto não for deixado em branco, solicita um novo produto e repete

as operações; em caso contrário, finaliza a entrada.

Finaliza a entrada Grava os dados nas respectivas tabelas.

Toda a informação supérflua deve ser eliminada do detalhamento do processamento.

Determinadas operações padronizadas, como por exemplo, seta para cima retorna para o

dado anterior e seta para baixo avança para o seguinte, não devem ser descritas. Como

desenvolvedor você deverá supor que os seus programadores são suficientemente

qualificados para compreenderem o processamento de um módulo sem que você tenha

que se perder em detalhes. Além de gerar uma quantidade muito grande e desnecessária

de papel, detalhes estão mais sujeitos a mudanças, enquanto que a essência do

processamento não.



93

Bibliografia

BIO, SÉRGIO RODRIGUES

Sistemas de Informação: Um Enfoque Gerencial

São Paulo, Atlas, 1985

HAMMER, MICHAEL, JAMES CHAMPY

Reengenharia: revolucionando a empresa em função dos clientes, da concorrência e

das grandes mudanças da gerência

1994, Editora Campus

O’BRIEN, JAMES A.

Sistemas de Informação e as Decisões Gerenciais na Era da Internet

2001, Editora Saraiva – São Paulo - SP

BARBARÁ, Saulo.

Gestão por processos. Qualitymark, 2006.

DAVENPORT, T. H.

Reengenharia de processos. Rio de Janeiro: Campus, 1994.

HAMMER, M.

Além da Reengenharia. Campus : Rio de Janeiro, 1997.

HOFFER, J. A.; VALACICH, J. S.; GEORGE, J.F.

Modern Systems analysis and design, 5th Ed. 2008, Prenctice Hall

LAURINDO, F. J. B. e ROTONDARO, R. G.;

Gestão Integrada de Processos e da Tecnologia da Informação. Atlas, 2006

LAUDON, K. e LAUDON, J.

Sistemas de Informações Gerenciais, 7ª. Edição. 2007, Editora Pearson

TURBAN, LEIDNER, MCLEAN & WETHERBE

Tecnologia da Informação para Gestão, 6ª. Edição. 2008, Editora Bookman

VALLE, R.; OLIVEIRA, S.B. (Org.)

Análise e Modelagem de Processos de Negócio: Foco na notação BPMN. Atlas, 2009

DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO · Sistemas de Informação Informação Empresarial...

Documents

Transcript of DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO · Sistemas de Informação Informação Empresarial...