Desenvolvimento de Sistemas de Informação

DESENVOLVIMENTO DE SISTEMAS DE
INFORMAÇÃO
FEA/USP – EAD-0658
Prof. ANTONIO GERALDO DA ROCHA VIDAL
vidal@usp.br
2012
FEA/USP – EAD-0658 – Desenvolvimento de Sistemas de Informação 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 ......................................................................................... 23
MODELAGEM DE PROCESSOS DE NEGÓCIO ........................................................................................... 24
Introdução..................................................................................................................................... 24
O BPMN ....................................................................................................................................... 24
Símbolos do BPMN........................................................................................................................ 34
Objetos de Conexão ....................................................................................................................... 37
Artefatos........................................................................................................................................ 38
Atividades ..................................................................................................................................... 38
Decisões (Divergência e Convergência de Fluxos) ......................................................................... 41
ANÁLISE DE INFORMAÇÕES.......................................................................................................... 42
INTRODUÇÃO ...................................................................................................................................... 42
NECESSIDADES DE INFORMAÇÃO ......................................................................................................... 43
Prof. Antonio Geraldo da Rocha Vidal

FEA/USP – EAD-0658 – Desenvolvimento de Sistemas de Informação III
Introdução..................................................................................................................................... 43
Definição de Classes de Dados ...................................................................................................... 47
Definição dos Requisitos de um Sistema de Informação.................................................................. 49
BANCOS DE DADOS ............................................................................................................................. 51
Introdução..................................................................................................................................... 51
Estrutura de uma Base de Dados ................................................................................................... 53
Projeto de Bancos de Dados .......................................................................................................... 57
MODELAGEM DE DADOS ..................................................................................................................... 58
Introdução..................................................................................................................................... 58
Relacionamentos Um-para-Um ...................................................................................................... 61
Relacionamentos Um-para-Muitos ................................................................................................. 63
Relacionamentos Muitos-para-Muitos............................................................................................ 64
Conjuntos de Relacionamentos ...................................................................................................... 65
Variação no Tempo ....................................................................................................................... 68
O Modelo Relacional de Dados (RDM - Relational Data Model) .................................................... 69
DICIONÁRIO DE DADOS ....................................................................................................................... 69
Introdução..................................................................................................................................... 69
Nome dos Dados............................................................................................................................ 70
Sinônimos...................................................................................................................................... 71
Homônimos ................................................................................................................................... 71
Domínio ........................................................................................................................................ 71
Características dos Dados ............................................................................................................. 72
Dados-chave ................................................................................................................................. 74
NORMALIZAÇÃO DE T ABELAS DE DADOS ............................................................................................. 75
Introdução..................................................................................................................................... 75
Primeira Forma Normal (1FN) ...................................................................................................... 76
Segunda Forma Normal (2FN) ...................................................................................................... 77
Terceira Forma Normal (3FN) ...................................................................................................... 79
Resultado da Normalização de Tabelas.......................................................................................... 80
Utilização de Índices ..................................................................................................................... 82
Desempenho do Sistema ................................................................................................................ 83
ANÁLISE DAS REGRAS DO NEGÓCIO........................................................................................... 84
INTRODUÇÃO ...................................................................................................................................... 84
LÓGICA ESTRUTURADA ....................................................................................................................... 84
TABELAS DE DECISÃO ......................................................................................................................... 85
ÁRVORES DE DECISÃO ........................................................................................................................ 85
DIAGRAMAS DE TRANSIÇÃO DE ESTADOS ............................................................................................ 86
CONSTRUÇÃO DO MODELO DO SISTEMA .................................................................................. 87
MÓDULOS DO SISTEMA ....................................................................................................................... 87
DIAGRAMA HIERÁRQUICO DO SISTEMA ............................................................................................... 88
ESPECIFICAÇÃO DE MÓDULOS DO SISTEMA .......................................................................................... 89
Introdução..................................................................................................................................... 89
Implementação por Uma Pessoa .................................................................................................... 89
Implementação por Várias Pessoas ................................................................................................ 90
Diálogo Sistema x Usuário ............................................................................................................ 90
Exemplo de Especificação de Módulo ............................................................................................ 91
BIBLIOGRAFIA .................................................................................................................................. 94

FEA/USP – EAD-658 – Desenvolvimento de Sistemas de Informação 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 para sobreviver o seu corpo depende de ar, água e alimentos, você depende
de informação. E não apenas para sobreviver, mas para alcançar seus objetivos: aprender,
divertir-se, relacionar-se com 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.

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 resultam produtos e 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).

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.

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.

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 empresariais 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:
1. Conseguir excelência operacional;
2. Desenvolver novos produtos, serviços e modelos de negócios;
3. Obter relacionamento mais estreito com clientes e fornecedores;
4. Melhorar a tomada de decisão;
5. Obter vantagem competitiva;

6. Garantir sua 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,
auxiliando a tomada de decisão, a comunicação, a coordenação, o planejamento, o e
controle da organizaçã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
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, armazenar 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 da empresa. 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
vendas, produção, custos, qualidade e contabilidade.
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.
 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,
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 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,
desenvolvimento e implantação de sistemas de informação.
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 objetos de 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?
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 apoio das
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, quase impossível.
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 implantados 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 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 dados de interesse para a organização, que devem ser armazenados e
relacionados através das tabelas que formarão o banco de dados do sistema de informação
a ser desenvolvido.

Para modelar a estrutura dos dados do sistema, é construído um diagrama contendo cada
objeto de dado (entidade ou evento) identificado e linhas interligando-os, representando o
relacionamento entre eles. Uma das principais vantagens obtidas com a construção deste
diagrama, 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 o banco 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
dos objetos de dados ou tabelas envolvidas no sistema de informação e ajuda a descobrir
os objetos de dados que não foram detectados pelo BPM. Além disso, através do RDM
são definidas as chaves identificadoras ou primárias (PK de primary-key) de cada tabela
de dados, bem como suas chaves estrangeiras (FK de foreign-key), necessárias para
estabelecer o relacionamento entre as tabelas de dados que representam os objetos de
dados de interesse do negócio.
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 os dados
necessários para a descrição de entidades e eventos de interesse do negócio. 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 listas na tela ou
relatórios contendo relações de dados contextualizados que atendem suas necessidades de
informação.
As consultas e os modelos de formulários e 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 permissões de
acesso, 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

as regras do negócio através do sistema de informação geralmente aumenta o

desempenho e a qualidade do processo de negócio.
As regras que definem a condução dos processos de negócio podem ser modeladas
através de várias técnicas. Neste curso estudaremos apenas as mais utilizadas: Lógica
Estruturada, Tabela de Decisão, Árvore de Decisão e Diagrama de Transição de Estados.
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 desenvolvidas e implantadas 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 ou interação do sistema com o usuário.

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,

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 um de seus 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.

 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 processos
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
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 subprocessos.
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);

 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
tarefa, atividade ou subprocesso sempre possui clientes e fornecedores:
 Fornecedor: responsável pelas entradas (recursos e/ou insumos) do processo;
pode ser interno ou externo à organização.
 Cliente: recebe as saídas (resultados, produtos e/ou serviços) do processo; 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.
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
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 (Marketing).
2. Desenvolver visão e estratégia de negócios (Planejamento Estratégico).
3. Projetar e desenvolver produtos e serviços (Marketing & Produção).
4. Elaborar plano de vendas e vender produtos e serviços (Marketing).
5. Produzir e entregar produtos e serviços (Produção).
6. Gerenciar serviços aos clientes (Produção).
7. Faturar e assistir clientes (Finanças, Marketing & Produção).
8. Desenvolver e gerenciar atividades de recursos humanos (Recursos Humanos).
9. Gerenciar recursos de informações (Sistemas de Informação ou TI).
10. Gerenciar recursos físicos e financeiros (Contabilidade & Finanças).
11. Gerenciar meio ambiente, saúde e segurança (Segurança & Ambiente).
12. Gerenciar relacionamentos externos (Todos).
13. Gerenciar conhecimento, melhorias e mudança (Todos).
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.
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 e 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.
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
atividade do processo.

c. Detalha as responsabilidades envolvidas em cada processo.

3. Modelo do Processo de Negócio (BPM)
a. Modelo do Processo: define o fluxo de atividades, participantes (unidades
organizacionais), tarefas, tempos, pessoas e interfaces que compõe o processo.
b. Modelo de Informações: define o fluxo de informações sobre entidades
utilizadas em cada atividade do 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 controle.
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.
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 atividades 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 de negócios e sistemas de informação.
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.
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 instituição 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 instituição 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. 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, 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 instituições financeiras que
oferecem créditos realizam várias análises do solicitante, por exemplo, verificam se o
solicitante já é um cliente da instituição, se é um bom pagador ou pelo contrario, se 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.
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:

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

notamos 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.

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 quais atividades são automáticas (tarefas
automáticas), quais atividades são realizadas com ajuda de um sistema (tarefas de
usuário) e quais 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” é
realizada com ajuda de um sistema de informação, portanto é utilizada uma tarefa de
usuário.

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 no 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
instituição financeira. Para isto é possível utilizar um evento intermediário simples.

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.
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 negócio normalmente utilizam separadores

visuais indicando os papéis dos responsáveis pelas atividades de um processo. O BPMN
permite diagramar as diferentes áreas de negócio dos participantes que intervierem dentro
do processo, para isto vamos a utilizar faixas, e o processo ficaria da seguinte forma:
Como vimos através dos exemplos anteriores temos utilizado alguns elementos gráficos
do BPMN. Estes elementos se encontram classificados dentro de quatro 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
conforme apresentados adiante.
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 subprocessos (compostas). Como
podemos ver dentro do exemplo existem diferentes tipos de tarefas (simples,
automáticas, manuais, de usuário, entre outras) e de subprocessos (embutido,
reutilizável, etc.) que nos permitem diagramar com mais profundidade os processos
de negócio fornecendo mais informação e esclarecendo o leitor, conforme detalhados
adiante.
3. Desvio: são elementos do modelo que são utilizados para controlar a divergência e a
convergência do fluxo de atividades do processo. Existem cinco tipos de desvios
dentro do exemplo apresentado neste texto: desvio exclusivo, desvio inclusivo, desvio
baseado em eventos, desvio paralelo e desvio complexo, conforme detalhados a
seguir.
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 três 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 quatro tipos: Objetos de Dados, Bancos
de Dados, Grupos e Anotações.

Símbolos do BPMN
Eventos
Os eventos representam algo que acontece ou que 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
Indicam 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.
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.
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 "enviar" 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 (ou uma alternativa) é necessária.
Quando usado anexado a uma atividade indica que esta atividade será
compensada por outra quando o evento for acionado.
Eventos de 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 fornecidos com o final do processo.
Todos os resultados devem ocorrer.
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.
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 realizadas 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. Deve ser utilizado sempre que forem
necessários esclarecimentos adicionais para melhor entendimento do
processo pelo leitor.
Grupo
É um mecanismo visual que permite o agrupamento de
atividades para fins de documentação ou análise. Deve ser
utilizado para agrupar conjuntos de atividades e eventos de um
processo que compartilham um mesmo contexto de negócio ou
responsabilidade.
Objeto de Dados
Descreve através de dados um recurso (entidade) ou operação (evento)
utilizado ou gerado por uma atividade. Ou seja, documentos, relatórios e
outros dados usados ou gerados durante a execução das atividades do
processo. Os objetos de dados descrevem entidades, recursos, operações ou
eventos utilizados ou gerados pelas atividades do processo. São
fundamentais para a integração do processo com sistemas de informação.
Banco de Dados
Armazena e fornece informações sobre entidades e eventos de

interesse de atividades do processo. Ou seja, através de um sistema de
informação permite registrar e/ou obter informações sobre recursos e
operações utilizados e/ou executados pelas atividades 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 subprocesso
incorporado ao processo principal.
Tarefa
Uma tarefa é uma atividade simples (atômica) que representa o

trabalho executado dentro do processo, não sendo definida em um
nível mais 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 nível mais detalhado.
Tarefa Manual
É uma atividade simples que representa o trabalho executado

manualmente dentro do processo, não sendo definida em um nível
mais detalhado.
Tarefa Serviço
É uma atividade simples que representa o trabalho executado
automaticamente dentro do processo, normalmente por um sistema de
informação ou equipamento, não sendo definida em um nível mais
detalhado.
Tarefa Envio
É uma atividade simples que representa o envio automatizado de

resultados (informações) do processo para outro processo, não sendo
definida em um nível mais detalhado.

Tarefa Recebimento
É uma atividade simples que representa o recebimento automatizado

de resultados (informações) do outro processo, não sendo definida em
um nível mais detalhado.
Tarefa de Script
É uma atividade simples que representa o processamento de instruções

(script) dentro do processo, não sendo definida em um nível mais
detalhado.
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.
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.

Desvios (Divergência e Convergência de Fluxos)

As decisões ou desvios 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 uma 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.
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
As organizações de todos os portes e naturezas gastam seu tempo e recursos executando
processos de negócios complexos. Um processo de negócio consiste na execução de
muitas atividades e regras de negócio no decorrer do tempo. Quem atualmente mantém
esses processos funcionando nas organizações modernas são os 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, especialmente as
relacionadas a cálculo de preços e impostos.
 Todas as regras para a produção de um produto ou serviço, especialmente as
relacionadas às quantidades de insumos a serem utilizados e de resultados a serem
produzidos.
 Todas as regras da contabilidade, especialmente as relacionadas à apuração de
saldos e resultados das contas.
 Todas as regras para cálculo de salários dos funcionários, especialmente as
relacionadas aos rendimentos e descontos a serem efetuados e o valor líquido a ser
pago.
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 com segurança 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 andamento do negócio. Na modelagem de um 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 para aumentar a eficiência dos processos.
Os sistemas de informação fazem a sua parte, automatizando atividades e decisões mais
simples e mecânicas (operacionais) e fornecendo informações necessárias à execução das

atividades dos processos, 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 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 que está sendo praticada e a tecnologia que está
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, pode 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 (informações sobre os trabalhadores).
 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 e redes sociais, as empresas são solicitadas a fornecer
informações sobre suas atividades, produtos e serviços, principalmente aquelas que
atuam em setores sensíveis.
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.
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 todos os 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 em 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 Apuração e Controle de Custos
01.9 Elaboração de 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 de pessoas
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 Vendas e Faturamento
03.4 Estatísticas de vendas
03.5 Expedição de Produtos
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

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 de fabricação

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.

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 ou operaçõ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

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 somente deve ocorrer após a definição
das necessidades de informação da organização e 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, envolvido 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.
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 todos 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é 60 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.

Bancos de Dados
Introdução
Um banco de dados (ou base de dados) pode ser definido como um conjunto unificado de
informação que vai ser compartilhado pelas pessoas autorizadas de uma organização. A
função básica de um banco de dados é permitir o armazenamento e a recuperação da
informação necessária para que as pessoas da organização possam 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 um banco de dados
corretamente projetado 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 objetos de 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 objeto de dados ou 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 atributos que descreve determinada entidade ou evento de interesse da
organização.
A figura apresentada a seguir ilustra estes conceitos e mostra que o armazenamento de
dados em um banco de dados é realizado através de uma estrutura de tabelas de dados.

BANCO DE
DADOS
ARQUIVO ARQUIVO ARQUIVO ARQUIVO ARQUIVO

CLIENTE PRODUTO VENDA COMPRA ...... ....
Registro Cliente Identificação (1) Nome do Cliente Endereço Cidade Estado
Registro Cliente Identificação (N) Nome do Cliente Endereço Cidade Estado
Chave Primária Dados (atributos) do Cliente
Estrutura de um Banco de Dados

Como ilustra a figura, 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
objetos de dados ou registros do arquivo e as colunas correspondem aos atributos ou
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.
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 tabelas
relacionadas. 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.

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 software 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
Como já vimos, 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
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
. . .
. . .
. . .

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

(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.

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

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.

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.

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).
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

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.

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.

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.

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

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.

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”

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

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

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:
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 devem 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",
"servidor" ou “colaborador” 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.
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
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.

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.

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:

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:

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

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

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.


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.

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

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.

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.

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:

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.

Ação A
=
2
1 =
2 Ação B
=
Sim
3
1 Ação C
Não
Ação D
Permitem melhor comunicação do que tabelas de decisão
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.

Ordem Aberta Ação Validando Ordem Ação Calculando Ação

Ordem
Ação
Ação Ação
Ação
Aguardando Ação Erro Ação Atualizando

Dados
Ação
Ação
Ação
Ação Fechando Ordem Ação Gravando Ordem
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;

 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.

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

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.

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

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%
-----------------------------------------------------------

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 Se o código do produto não for deixado em branco, solicita um novo produto e repete
produto 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.

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

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento de Sistemas de Informação

Enviado por

Direitos autorais:

Formatos disponíveis

DESENVOLVIMENTO DE SISTEMAS DE

Prof. ANTONIO GERALDO DA ROCHA VIDAL

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

Prof. Antonio Geraldo da Rocha Vidal

Prof. Antonio Geraldo da Rocha Vidal

Prof. Antonio Geraldo da Rocha Vidal

Elementos do Sistema Empresa

Prof. Antonio Geraldo da Rocha Vidal

Elementos do Subsistema de Produção

Prof. Antonio Geraldo da Rocha Vidal

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

A Empresa como um Sistema

Prof. Antonio Geraldo da Rocha Vidal

Prof. Antonio Geraldo da Rocha Vidal

6. Garantir sua sobrevivência diária.

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

Prof. Antonio Geraldo da Rocha Vidal

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

Tipos de Sistema de Informação

Prof. Antonio Geraldo da Rocha Vidal

e a pagar). Os sistemas que se voltam para decisões referentes às operações envolvem o

Requisitos de um Sistema de Informação

Prof. Antonio Geraldo da Rocha Vidal

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

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

Prof. Antonio Geraldo da Rocha Vidal

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

Componentes de um Sistema de Informação

Problemas Organizacionais e Sistemas de Informação

Prof. Antonio Geraldo da Rocha Vidal

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