Sei sulla pagina 1di 86

INTRODUÇÃO AO PROJETO E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO

FEA/USP

Prof. ANTONIO GERALDO DA ROCHA VIDAL

Julho/1998

FEA/USP - EAD-451 Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

SUMÁRIO

O CONCEITO DE SISTEMA DE INFORMAÇÃO

1

Introdução

 

1

A

Necessidade de Informação

1

O

Conceito de Sistema

1

A

Empresa como um Sistema

3

Sistemas de Informação

4

Componentes de um Sistema de Informação Automatizado

8

NECESSIDADES DE INFORMAÇÃO

8

Tipos de Informação

8

Informações Externas

8

Informações Internas

9

METODOLOGIA PARA IDENTIFICAÇÃO DAS NECESSIDADES DE INFORMAÇÃO

13

Etapa 1

Identificação dos Objetivos e dos Fatores Críticos de Sucesso

13

Etapa 2

Levantamento das Áreas de Aplicação da Informática

15

Etapa 3

Consolidação das Aplicações Identificadas

16

Etapa 4

Definição das Classes de Dados

16

Etapa 5

Priorização das Aplicações a serem Informatizadas

19

Resultado da Metodologia

21

DEFINIÇÃO DOS REQUISITOS DE UM SISTEMA DE INFORMAÇÃO

23

Introdução

23

Relação de Requisitos do Sistema

23

Grupo para Especificação do Sistema

24

BASES DE DADOS

 

24

Introdução

24

Estrutura de uma Base de Dados

25

Chave Primária ou Identificadora

27

Índices de Acesso

27

Projeto de Bases de Dados

29

ETAPAS DO PROJETO DE SISTEMAS

31

Introdução

 

31

Etapa 1

Modelagem de Processos

31

Etapa 2

Modelagem de Dados

31

Etapa

3

Normalização

32

Etapa 4

Reconstrução do BPM e do RDM

33

Etapa 5

Definição dos Módulos do Sistema

33

IMPLEMENTAÇÃO DO SISTEMA

34

Introdução

34

Prototipação

34

Prototipação de Descoberta

35

Prototipação de Refinamento

35

MODELO DE PROCESSOS DO NEGÓCIO (BPM)

37

Introdução

37

Símbolos do Modelo de Processos do Negócio

37

Entidades Externas

37

Fluxos de Dados

39

II

FEA/USP - EAD-451 Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Processos

40

Arquivos de Dados

41

Construção do Modelo de Processos do Negócio

42

Lista de Verificação para o BPM

43

Lista de Recomendações para o BPM

44

MODELO RELACIONAL DE DADOS (RDM)

46

Introdução

46

Relacionamentos

Um-para-Um

48

Relacionamentos

Um-para-Muitos

50

Relacionamentos

Muitos-para-Muitos

51

Conjuntos de Relacionamentos

52

Variação no Tempo

55

Tipos de Objeto

56

O

Modelo Relacional de Dados (RDM - Relational Data Model)

57

Modelagem dos Dados

 

58

Dados-chave

64

Estruturas Embutidas

64

Múltiplas Chaves

66

NORMALIZAÇÃO

66

Introdução

66

Primeira Forma Normal (1FN)

67

Segunda Forma Normal (2FN)

69

Terceira Forma Normal (3FN)

71

Resultado da Normalização de Arquivos

72

RECONSTRUÇÃO DO BPM E DO RDM

73

DESEMPENHO DO SISTEMA

74

Utilização de Índices

74

Melhorando o Desempenho

75

DEFINIÇÃO DOS MÓDULOS DO SISTEMA

76

Introdução

76

A

Árvore do Sistema

77

ESPECIFICAÇÃO DOS MÓDULOS DO SISTEMA

78

Introdução

78

Implementação por Uma Pessoa

78

Implementação por Várias Pessoas

79

Diálogo Sistema x Usuário

79

Exemplo de Especificação de Módulo

80

BIBLIOGRAFIA

83

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

O Conceito de Sistema de Informação

Introdução

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

cuidar da velocidade do seu carro etc., você está processando dados.

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

para dirigir 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 geração de informações tão importante nas empresas:

å A complexidade crescente da sociedade moderna. ç A introdução da administração científica. é A tecnologia da informação.

A globalização da economia, a competição e o constante crescimento das empresas, 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, consequentemente torna necessário o processamento eletrônico dos dados.

A Necessidade de Informação

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, cheirar, sentir o seu lugar.

Assim como o seu corpo depende de ar, água e alimento para sobreviver, você depende de informação. E não apenas para sobreviver, mas para alcançar seus objetivos: aprender, divertir-se, ajudar os outros, amar, se afirmar na sociedade e administrar empresas.

A informação, portanto, possui importância fundamental para todos nós, individual e coletivamente, isto é, para as famílias, clubes, comércio, escolas, indústrias, governo etc.

A sobrevivência

homem dependem

fundamentalmente da informação. Sem ela estarão a esmo no escuro.

e

o

sucesso

das

organizações

criadas

pelo

O Conceito de Sistema

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

por cadeias de relações de modo a constituir um todo organizado" (J.Maciel).

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 econômicos, sistemas

de processamento de dados 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 bens e/ou serviços a serem fornecidos ao mercado.

resultam bens e/ou serviços a serem fornecidos ao mercado. Fig. 01 Sistema empresa Cada um destes

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

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

Fig. 02 O subsistema de produção

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 os objetivos.

Estrutura:

a relação existente entre os componentes, definindo a fronteira entre o sistema e seu ambiente.

Comportamento: a maneira do sistema reagir ao seu ambiente.

Ciclo Vital:

nascimento, evolução, desgaste, obsoletismo, 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 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, a empresa não pode ignorar as suas interações com estes elementos.

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 do fenômeno.

Assim, podemos identificar nas empresas um subsistema denominado processo, cujas operações resultam nos objetivos da empresa (produção de bens ou serviços), um subsistema denominado administrativo, cuja função é assegurar o eficaz funcionamento do processo 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.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 a longo prazo, e estratégico em

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

vendas de um certo 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 das funções encontradas com maior freqüência incluem vendas, compras, finanças, contabilidade, produção, recursos humanos, processamento de dados

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

O comportamento das empresas é determinado por seus procedimentos, 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 procedimentos orientam os funcionários em como efetuar as tarefas que cada componente da empresa requer.

Finalmente, o ciclo vital é facilmente percebido através do aparecimento de novas empresas, sua evolução e crescimento, suas mudanças, e através do desaparecimento de antigas e obsoletas empresas.

Sistemas de Informação

Conceitos Básicos

Há muitas formas de se conceituar informação, dependendo do ângulo de observação e do campo de conhecimento em estudo. Do ponto de vista mais específico de sistemas de informação pode-se examiná-lo a partir do entendimento da informação como o resultado do tratamento de dados. Entende-se neste caso um dado como um item elementar de informação (um conjunto de idéias ou fatos expressos através de letras, dígitos ou outros símbolos) que, tomado isoladamente, não transmite nenhum conhecimento, ou seja, não possui significado intrínseco.

Partindo-se do conceito acima, pode-se definir informação como o resultado de fatos e idéias relevantes, ou seja dados, que foram transformados (processados) numa forma

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

inteligível para quem os recebe, e tem valor (utilidade) real ou aparente para a tomada de decisões presentes 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 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.

Os sistemas de informação, em geral, são utilizados para orientar a tomada de decisão 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 lhe 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

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

outro. E ainda outras informações e ações criam fluxos entre as partes individuais dentro dos componentes da empresa.

Qualquer sistema de informação empresarial, como o de contabilidade ou o de recursos humanos, possui o mesmo comportamento: captar e transportar os dados ao longo da estrutura da empresa (componentes da empresa) até o processamento 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, as 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

Sistemas de Informação Operacionais

No nível operacional (do processo), os sistemas de informação são em geral condicionados pela tecnologia da empresa e pela organização do seu processo produtivo. Os sistemas de apoio às operações são tipicamente sistemas armazenadores de dados e processadores de transações, ou seja, são redes de procedimentos rotineiros que servem para o registro e processamento das transações correntes. Dentro desta categoria podemos identificar como sendo os mais típicos o de contabilidade, o de folha de pagamento, o de controle de estoques, o de faturamento e o de contas a receber e a pagar. Os sistemas que se voltam para decisões referentes às operações envolvem o registro de muitos dados e a integração e agregação de muitas transações, tais como planejamento e controle da produção, custos e contabilidade.

Sistemas de Informação Gerenciais

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 especificamente para auxiliar processos decisórios. Por essa razão, tais sistemas devem ser flexíveis e podem ter uma assistemática freqüência de processamento. Incluem sistemas de previsão de vendas, de análises financeiras, orçamentos e os sistemas voltados, de modo geral, ao planejamento e controle das operações. 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.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Requisitos de um Sistema de Informação

Um sistema de informações eficaz deve satisfazer os seguintes requisitos básicos:

Produzir as informações realmente necessárias, confiáveis, em tempo hábil e com custo condizente, atendendo aos requisitos operacionais e gerenciais de tomada de decisões a que tais informações devem suprir.

Ter por base diretrizes capazes de assegurar o atendimento dos objetivos da organização, de maneira direta, simples e eficiente.

Integrar-se à estrutura da organização e auxiliar na coordenação entre as diferentes unidades organizacionais (departamentos, divisões, e diretorias) por ele interligadas.

Ter um fluxo de procedimentos (internos e externos ao processamento) 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.

O computador, 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, é uma ferramenta adequada para a implementação de sistemas de informação de alta qualidade. Porém, a simples introdução de recursos de informática nos sistemas de informação de uma empresa, não representa uma garantia de solução de seus problemas. Por si só, o computador 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 podem não ser factíveis, e até mesmo pode não ser possível encontrar soluções viáveis para determinados problemas.

O constante crescimento das empresas, 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, consequentemente, necessário o processamento eletrônico de dados, ou seja, a utilização da tecnologia da informação.

No contexto atual, é imprescindível que as empresas automatizem 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. Nesse sentido, como veremos a seguir, o primeiro passo para iniciar-se um processo de informatização é a identificação das necessidades de informação e das aplicações a serem informatizadas.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Componentes de um Sistema de Informação Automatizado

Em um sistema de informação automatizado, isto é, que utiliza os recursos da tecnologia de informação, existem quatro componentes essenciais: hardware, software, dados e usuários. Estes, por sua vez, estão inseridos num contexto mais amplo, de aplicação numa empresa, com o objetivo de produzir determinados bens ou serviços.

q

Hardware: é composto pelos equipamentos de informática utilizados pelo sistema, como computadores, impressoras, leitores óticos, mouse etc., e pelos recursos de comunicação que os conectam entre si, como modems, linhas, cabos, concentradores, roteadores etc.

q

Software: é composto pelos sistemas operacionais e diversos programas de computador que fornecem instruções específicas sobre as tarefas que o hardware deve executar para gerar a informação desejada.

q

Dados: são compostos por fatos e idéias relevantes que registrados e processados de forma adequada permitem gerar a informação desejada.

q

Usuários: são compostos pelas pessoas que realizam as tarefas necessárias para o adequado funcionamento dos demais componentes do sistema de informação e pelas pessoas que solicitam e utilizam as informações por ele geradas.

Necessidades de Informação

Tipos de Informação

Para a definição dos sistemas de informação a serem automatizados numa empresa, é 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 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.

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

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

q

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 adquiridos, pagamentos efetuados/a efetuar, pagamentos em atraso, pedidos efetuados/pendentes, nome do comprador e nome do vendedor.

q

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

q

Concorrentes: são as empresas que atuam no mesmo ramo de atividade, disputando o mesmo mercado. A empresa precisa obter informações sobre seus concorrentes, pois somente assim poderá se situar no mercado (volume de vendas e tipos de produtos), verificar os lançamentos de novos produtos ou serviços, os pontos de venda que estão sendo atingidos, a política de preços está sendo praticada e a tecnologia que está 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.

q

Sócios/Acionistas: são as pessoas que investiram seu capital na empresa, e esperam um retorno compensatório. Mesmo sendo de capital fechado, como é o caso da maioria das pequenas e médias empresas, poderão haver vários acionistas ou sócios que deverão ser periodicamente informados sobre a situação da empresa e sobre a divisão dos lucros.

q

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.

q

Público em Geral: apesar de não ter um relacionamento direto com o público, cada vez mais, devido a movimentos ecológicos, controle de poluição e urbanização e código do consumidor, as empresas são solicitadas a fornecer informações sobre suas atividades, produtos e serviços, principalmente aquelas que atuam em setores sensíveis a estes problemas.

Informações Internas

Qualquer empresa, na medida em que se desenvolve, é dividida em áreas funcionais ou departamentos, para que consiga executar suas atividades de forma mais eficiente. Além disso, há uma hierarquia de decisões na empresa, que vai dos níveis operacionais (inferiores) aos gerenciais e estratégicos (superiores). O conceito de níveis de hierarquias,

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

nos quais o superior determina as ações dos inferiores, não se limita à coordenação de pessoas, mas estende-se às demais funções da empresa e até para outros tipos de sistemas.

Para as decisões operacionais são necessárias informações sobre as rotinas e tarefas 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 que permitam o planejamento e o controle das operações da empresa, como estatísticas de vendas, 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 oportunidades de investimento e novas tecnologias. O conceito de nível decisório é importante, pois as tarefas em cada nível, operacional, gerencial e estratégico, são diferentes, e consequentemente 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 tarefas específicas ligadas à cada uma das funções necessárias à atividade global 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 área e entre elas, pois a atividade global é a integração da atividade de cada função e umas dependem das outras.

A seguir, apresentamos uma lista de funções e atividades, tanto a nível operacional como gerencial, que inclui a maioria dos sistemas de informação de uma típica empresa industrial:

01. Administração Financeira e Contábil

01.1 Contabilidade Geral

01.2 Contabilidade Fiscal

01.3 Contas a Pagar

01.4 Contas a Receber

01.5 Tesouraria

01.6 Controle de importações

01.7 Controle de exportações

01.8 Custos

01.9 Orçamentos

02. Administração de Recursos Humanos

02.1 Folha de pagamentos

02.2 Controle de Férias

02.3 Controle de ponto

02.4 Controle financeiro de pessoal

02.5 Assistência médica

10

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

02.6 Administração de salários

02.7 Administração de cargos/funções

02.8 Desenvolvimento/treinamento

02.9 Higiene e segurança do trabalho

02.10 Apoio à assistência social

03. Administração Comercial

03.1 Cotações de preços para clientes

03.2 Administração da carteira de pedidos

03.3 Faturamento

03.4 Estatísticas de vendas

03.5 Expedição

03.6 Cálculo de comissões de vendas

03.7 Administração de transportes

03.8 Informações para clientes

03.9 Assistência técnica

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

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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

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

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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, faturamento deve também fazer o controle do ICMS, assim como a 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.

Supondo que uma empresa planeja adquirir um sistema de computação para dele obter o maior benefício possível, a metodologia que apresenta-se a seguir procura identificar, através de cinco etapas, as necessidades de informação e as correspondentes aplicações cuja informatização trarão maior impacto nos negócios da empresa, através da melhoria de seus sistemas de informação.

Metodologia para Identificação das Necessidades de Informação

Etapa 1 Identificação dos Objetivos e dos Fatores Críticos de Sucesso

A meta desta etapa é definir claramente os objetivos da empresa e os problemas existentes para alcançar tais objetivos. Se deve considerar, entretanto, os problemas que podem ou devem ser resolvidos de outra forma que não através da informática. Se há problemas para

a manipulação do volume de dados e papéis com o pessoal existente, se a informação que

é importante para o funcionamento do negócio não está disponível, é razoável presumir

que melhores informações conduzirão a uma maior eficácia no controle de estoques, na cobrança dos devedores ou em algum aspecto da produção. A informatização desses processos através de um computador pode, então, ser justificada.

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 básicos 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 nas suas diversas

13

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

áreas operacionais, se ela estiver vulnerável em fatores críticos de sucesso, é muito provável que não consiga ter a competitividade necessária para garantir sua sobrevivência.

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

Localização.

Variedade de produtos e marcas.

Preços e crédito para os clientes.

Conforto do cliente para realizar suas compras.

As seguintes características fundamentais são típicas para os fatores críticos de sucesso (FCS) de uma empresa:

São poucos.

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

São diferenciadores entre organizações.

Têm grande influência sobre as relações da empresa com o ambiente, principalmente com os mercados atingidos ou pretendidos.

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

Podem estar distribuídos pelas diversas atividades operacionais da empresa, principalmente por aquelas que representam as partes mais significativas de seus processos operacionais.

Muitos dos FCS são relacionados às características da categoria de produtos em face das necessidades básicas dos consumidores ou clientes e às utilidades por eles percebidas. Os principais pontos de pesquisa para encontrar e identificar os fatores críticos de sucesso são:

Necessidades básicas para atender as utilidades fundamentais percebidas pelos consumidores ou clientes.

Relações da empresa com o mercado.

Processos, tecnologias e custos.

Análise dos insumos vitais.

Capacidade de produção.

Capacidade financeira.

Porte e estrutura organizacional.

Relacionamento empresa x ambiente.

Como primeiro passo, a empresa deve, portanto, identificar claramente os seus objetivos, os fatores críticos de sucesso para alcançá-los e os problemas existentes nos procedimentos atuais.

14

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Etapa 2 Levantamento das Áreas de Aplicação da Informática

Identificados os objetivos, os fatores críticos de sucesso e os problemas atuais da empresa, a próxima etapa é empreender uma busca das possíveis áreas de aplicação da tecnologia da informação, questionando como esta poderia ser utilizada na automatização de sistemas de informação, para tornar a empresa mais competitiva e eficiente. Complementarmente, pode-se questionar cada uma das principais áreas funcionais da empresa, no sentido de serem identificadas suas contribuições específicas para cada um dos fatores críticos de sucesso apontados e, então, identificar outras possíveis aplicações da informática que dêem apoio a essas contribuições. Dessa forma, tem-se uma análise profunda das possibilidades de uso da informática orientada para os objetivos da empresa através de seus fatores críticos de sucesso.

Esta etapa consiste, portanto, em realizar levantamentos junto a cada uma das áreas funcionais da empresa, bem como identificar, a partir dos próprios ocupantes dessas funções, os usos atuais e potenciais (ou aplicações) da informática que possam servir de apoio a elas. Esses levantamentos devem avaliar:

Contribuições de cada função para com os objetivos básicos e estratégicos da empresa.

Contribuições de cada função para com os fatores críticos de sucesso apontados.

Identificação dos fatores críticos de sucesso para cada função.

Processos e decisões inerentes às funções.

Tipos de atividades relacionadas à organização do trabalho.

Informações utilizadas e geradas por cada função.

Além da identificação e análise de cada um dos aspectos citados, ao nível de cada função, também deverão ser questionados, do ponto de vista do usuário e dos usos potenciais da informática, as necessidades individuais existentes, seja em termos de novas aplicações ou em modificações daquelas já implantadas.

Esta etapa do processo é uma das mais trabalhosas porque implica na execução de levantamentos junto às diversas áreas, departamentos, chefias ou funções da empresa, de forma a serem identificadas, claramente, as principais necessidades de informação e, consequentemente, possíveis aplicações da informática.

Recomenda-se que a relação das áreas de aplicação seja ampla, não implicando, contudo, que os passos posteriores devam abordar todas as áreas em detalhe. A menos que se listem todas as áreas de aplicação possíveis, pode-se omitir a visão futura de crescimento da empresa e tomar decisões que não levem em consideração áreas que serão importantes.

Após tomarem-se decisões a respeito das prováveis áreas de aplicação, deve ser elaborada uma lista de necessidades. Esta lista não deve ser um documento técnico, mas simplesmente uma descrição da empresa e de suas principais necessidades de informação. Uma lista de necessidades deve constar de:

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Uma descrição breve da empresa, indicando suas atividades, o número de funcionários, sua localização e filiais (se for o caso) e os processos pouco usuais referentes à sua forma de operar.

Uma lista das aplicações automatizadas ou a serem automatizadas.

Descrição relativa a cada aplicação, incluindo os dados necessários e as informações

desejadas. Obtidas as áreas de aplicação da informática, ou apenas aplicações, e as necessidades de informação, pode-se passar para a etapa seguinte.

Etapa 3 Consolidação das Aplicações Identificadas

Visando a obtenção de uma relação geral das necessidades de informação e dos sistemas

de informação a serem automatizados, deve ser realizada uma sumarização e agrupamento

de todas as proposições obtidas na etapa anterior, de forma que se apresentem organizadas por fator crítico de sucesso e área de aplicação. No levantamento funcional da etapa anterior são, em geral, identificados problemas e necessidades de informação que extrapolam a função analisada, interagindo com outras, sendo, portanto, fundamental que um trabalho de classificação, organização e consolidação das aplicações seja conduzido.

Por outro lado, cada área funcional da empresa é responsável por processos, que podem ser definidos como um grupo de decisões e atividades logicamente relacionadas, necessárias para administrar os recursos e operações sob sua responsabilidade. A disponibilidade de informações é um dos pré-requisitos básicos para a execução dos processos. Tais necessidades de informações são supridas com informações geradas por outros processos. O que se tem, portanto, é uma grande interdependência entre os vários processos, sendo essa interdependência maior para processos de um mesmo grupo.

O resultado desta etapa deve ser, portanto, uma relação de aplicações da tecnologia da

informação, consolidada e integrada, resultante da análise das funções e processos a que darão apoio e das necessidades de informação (dados a serem processados e informações

a serem geradas) da empresa como um todo.

Com base nesse resultado, é indispensável identificar, de forma precisa, quais são as informações necessárias à execução de cada processo. A função primordial do sistema de informação será fornecer essas informações (na quantidade certa, no prazo oportuno, a um custo razoável e na exatidão requerida) aos participantes da execução de cada processo. É necessário, portanto, identificar e classificar os dados criados, controlados e utilizados pelos processos, podendo para isso ser utilizado o conceito de classe de dados.

Etapa 4 Definição das Classes de Dados

Uma classe de dados é uma categoria de dados logicamente relacionados que são

necessários para dar apoio aos negócios da empresa. Estes dados devem ser identificados

e classificados com o objetivo de determinar:

16

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Exatidão, oportunidade e disponibilidade dos dados que são normalmente utilizados nos processos.

Classes de dados utilizadas nos sistemas de informações existentes ou a implantar.

Dados atuais e potenciais compartilhados pelos processos.

Dados criados, controlados e utilizados por cada processo.

Informações que são necessárias mas que não estão disponíveis.

Quais são, tendo em vista os fatores críticos de sucesso, os sistemas de informação

mais necessá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 e funcionários, produtos.

Dados Transacionais

São os dados referentes a todas as transações efetuadas pela 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 de controle dos negócios; por exemplo, volumes de vendas por produto, vendedor ou cliente.

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, vendedor ou cliente.

Dados Cadastrais e Transacionais em uma Empresa Industrial

DADOS CADASTRAIS

DADOS TRANSACIONAIS

01. Contas contábeis

01. Lançamentos contábeis

02. Bancos

02. Custos

03. Centros de custos

03. Notas Fiscais/Faturas

04. Funcionários

04. Duplicatas a receber

05. Clientes

05. Processos de exportações

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

DADOS CADASTRAIS

DADOS TRANSACIONAIS

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

13. Matérias-primas

13. Requisições de mat.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

 

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

As necessidades de informação, ou seja, dados a serem processados e informações a serem geradas, referentes às aplicações obtidas na etapa anterior, devem nesta etapa ser consolidadas e classificadas, de acordo com os processos a que darão apoio e com a classe de dados de que fazem parte.

Nesta etapa também 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 computação (hardware, software e usuários) necessário para a informatização da empresa.

As rotinas e sistemas transacionais são relativamente comuns entre as empresas, o mesmo acontecendo com os dados cadastrais e transações principais. Desta forma, pode-se utilizar uma tabela de referência para consulta quanto aos volumes a serem levantados.

Etapa 5 Priorização das Aplicações a serem Informatizadas

Há basicamente dois caminhos que podem ser seguidos na determinação de aplicações que devem ser prioritariamente informatizadas. Em alguns negócios certas atividades tomam muito mais tempo que outras e causam a maioria dos problemas e erros. Outras atividades diárias são fáceis de serem executadas e estão sujeitas a poucos erros. As opções são portanto duas: podem ser informatizadas inicialmente as áreas administrativas mais difíceis do negócio ou podem ser informatizadas as atividades mais simples. Adotando a primeira opção, será possível obter resultados rapidamente no sentido de redução de tempo, problemas e erros na execução das atividades. Por outro lado, adotando a segunda opção, haverá menos chance de fracasso e, informatizando as atividades mais simples primeiro, a empresa terá mais facilidade para informatizar posteriormente as atividades mais complexas. A opção ideal, contudo, talvez seja iniciar a informatização da empresa por aplicações que constituam um meio-termo, ou seja, nem tão complexas nem tão simples.

Tendo-se a lista de aplicações a serem informatizadas, cada uma delas deverá, então, passar por um processo de priorização através de uma análise de custos e benefícios específicos, em que deverão ser levadas em consideração várias dimensões de importância. As seguintes dimensões de importância podem ser consideradas na avaliação das aplicações:

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Importância Estratégica

Relacionada aos impactos que a aplicação proposta traria à competitividade e proteção da empresa, principalmente face a concorrentes, mercados e fornecedores. Os principais critérios a serem considerados nesta dimensão são: aumento da competitividade da empresa, redução da dependência em relação a terceiros, aumento da dependência de clientes em relação à empresa, melhor qualidade de produtos e serviços, melhoria da imagem institucional, aumento da agilidade e flexibilidade operacional.

Importância Funcional

Relacionada à melhoria que a aplicação ou sistema proposto traria sobre a eficiência e performance no trabalho da área afetada, inclusive ao nível de desempenho de gerentes e profissionais administrativos. Os principais critérios a serem considerados nesta dimensão são: melhores informações funcionais, melhor performance de pessoal, melhores comunicações e base de integração para outras aplicações.

Importância Organizacional

Relacionada à melhoria que a aplicação ou sistema proposto trará para a organização como um todo, em aspectos como comunicações, capacitação, integração, agilização de decisões e segurança. Os principais critérios a serem considerados nesta dimensão são:

melhores comunicações, demandas impostas pela necessidade de segurança de dados, melhor controle e funcionamento da empresa, menor número de problemas operacionais e gerenciais, base para capacitação futura (aquisição de experiência), base para acompanhamento tecnológico e base para estímulo à capacitação e aperfeiçoamento profissional.

Importância Devida a Demandas Externas

Relacionada ao fato de a aplicação ou sistema proposto se justificar por existir uma imposição externa à empresa, obrigando-a a manter informações de interesse de agentes externos (governos), como é o caso da escrituração fiscal, de informações aos acionistas e informações ao público em geral. Os principais critérios a serem considerados nesta dimensão são: obrigatoriedade de fornecimento de informações aos agentes externos, periodicidade, nível de exigência e divulgação institucional.

Importância Econômica

Decorrente, principalmente, de economias de custos ou ganhos financeiros, como é o caso da redução nos prazos de recebimentos de vendas, com a implantação de um sistema de contas a receber; redução do prazo de entrega de mercadorias, com a implantação de um sistema de controle da produção. Os principais critérios a serem considerados nesta dimensão são: reduções de custos, aumento da produtividade e eficiência, ganhos de tempo, ganhos econômicos em termos de fluxo de caixa e aumento do nível de atividade.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Através destas dimensões gerais, praticamente todos os possíveis fatores relevantes na avaliação do interesse em automatizar determinada função, processo ou sistema de informação estarão sendo considerados. É também uma avaliação muito mais abrangente e subjetiva que os processos tradicionais em que praticamente só a dimensão econômica é considerada. Por esse motivo, é importante que os dirigentes da empresa participem e mantenham controle sobre o processo de informatização. Esta responsabilidade não deve ser delegada a um consultor externo ou a um funcionário, e muito menos a um fornecedor.

Resultado da Metodologia

O resultado final da metodologia descrita pode ser apresentado em um quadro, onde são relacionadas todas as necessidades de informação, as respectivas aplicações que as fornecerão, as áreas funcionais envolvidas, os dados cadastrais e transacionais necessários

e os respectivos volumes. A partir desse quadro, pode ser definido um fator de prioridade para os sistemas de informação a serem implantados.

Para a obtenção do fator de prioridade sugere-se que cada aplicação ou sistema proposto seja avaliado segundo as cinco dimensões de importância citadas, atribuindo-se notas variando de B (baixa, nota 1), M (média, nota 5), a A (alta, nota 10). Estabelecendo-se

pesos para cada uma das dimensões apontadas (sugerindo-se 10 para a estratégica, 5 para

a funcional e organizacional, 1 para a externa e 9 para a econômica), todas as aplicações ou sistemas devem ter suas notas ponderadas, obtendo-se um total de pontos correspondente ao fator de prioridade. Dessa forma, as aplicações ou sistemas de informação com maior número de pontos devem ser consideradas como mais importantes

e prioritários.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Informação

Aplicação

Área

Dados

Dados

Cadastrais

Transacionais

Clientes

 

Vendas

Nome do cliente CGC/CPF Endereço Telefone Fax Crédito etc.

 

Faturamento Contas a Receber

Financeiro

Vendas

Faturamento

Vendas

Nome do Cliente CGC/CPF Inscrição Endereço Vendedor

Nº da Nota Fiscal Data da Emissão Valor Comissão Venda Impostos Produto/Serviço Quantidade Preço Unitário Desconto etc.

Financeiro

Contabilidade

Fornecedores

Estoque

Compras Almoxarifado Contas a Pagar

Nome

 

CGC/CPF

Endereço

 

Telefone

Fax.

Cidade

Estado

CEP

etc.

Etc.

Etc.

Etc.

Etc.

Etc.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Definição dos Requisitos de um Sistema de Informação

Introdução

O projeto detalhado de um sistema de informação a ser desenvolvido somente deve

ocorrer após a definição das necessidades de informação da organização ou do usuário que irá utilizá-lo.

Tradicionalmente, para a obtenção das definições necessárias para o desenvolvimento de um sistema de informação automatizado, o desenvolvedor deve entrevistar cada usuário

da informação, ou gerente da organização, envolvidos nas á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 a ser desenvolvido.

Relação de Requisitos do Sistema

Um documento com a definição dos requisitos de um sistema de informação deve constar basicamente de:

Dados a serem processados

Informações a serem geradas

Recursos especiais

Dados a Serem Processados

Devem ser relacionados os dados a serem captados, armazenados e processados pelo sistema. Assim, por exemplo, para o faturamento, 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. Como comprovação, deve-se analisar os documentos do sistema de informação atual (manual ou não), para verificar se todos os dados necessários foram incluídos. Também é interessante anotar-se o número de posições necessário para cada dado, por exemplo, o nome do

cliente pode ter até 40 letras ou posições e as regras necessárias para verificar a validade

de cada dado, por exemplo, o sexo do funcionário só deve aceitar as letras M ou F.

Informações a Serem Geradas (consultas e relatórios)

Deve-se relacionar as consultas desejadas na tela do computador e os relatórios impressos

a serem fornecidos pelo sistema para satisfazer as necessidades de informação dos

usuários, 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.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Recursos Especiais

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.

Grupo para Especificação do Sistema

Como forma de reduzir o tempo gasto no levantamento das informações necessárias para definir os requisitos do sistema, os representantes dos usuários mais relevantes poderão ser reunidos em um grupo, juntamente com a equipe de desenvolvimento, numa sessão de trabalho contínua, que poderá durar de um a três dias, para especificar as características e funções do sistema. Quando bem conduzidas por alguém com grande interesse no sucesso do sistema, essas reuniões de trabalho vão além da mera função de coleta de informações.

Os usuários acabam envolvidos com o processo de desenvolvimento do sistema, tomam decisões a respeito da sua abrangência e características e saem com o positivo sentimento de que o sistema será feito por eles próprios, e que o "desenvolvedor" está apenas ajudando.

Bases de Dados

Introdução

Uma base de dados (ou banco de dados) pode ser definida como um conjunto unificado de informação que vai ser compartilhado pelas pessoas autorizadas de uma organização. A função básica de uma base de dados é permitir o armazenamento e a recuperação da informação necessária para as pessoas da organização tomarem decisões, eliminando redundâncias. Quando coexistem várias cópias de uma mesma informação, é comum ocorrer discrepâncias entre elas, podendo-se chegar ao extremo de se tornar impossível determinar qual das diferentes versões é a correta. Em uma base de dados corretamente projetada não deve existir informação redundante e, portanto, a possibilidade de que se produzam inconsistências entre os dados é minimizada.

Normalmente, nos microcomputadores, as informações necessárias à uma organização se distribui em um conjunto de bases de dados. 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.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Por outro lado, em computadores de maior porte, as informações necessárias à 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.

Independentemente da base de dados que será implantada, a função de um Sistema de Gerenciamento de Base de Dados (SGBD) é a mesma. O SGBD pode ser definido como sendo o conjunto de hardware e 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 meios de pesquisar e obter informações, introduzir novas informações e atualizar as existentes.

Estrutura de uma Base de Dados

Uma base de dados é formada por um conjunto de arquivos de dados, também chamados de tabelas, que contém a informação nela armazenada. O conjunto de tabelas ou arquivos ilustrados a seguir pode ser considerado como pertencente à uma base de dados de compras.

ARQUIVO DE PRODUTOS

Código

Nome

Unidade

1.01.001

CD-ROM Regravável 5 1/4"

Unidade Caixa com 10 Caixa com 10 Unidade

1.01.002

Disco Flexível de 5 1/4" 1,2 Mbytes

1.02.001

Disco Flexível de 3 1/2" 1,44 Mbytes

2.01.001

Cartucho de Tinta para Impressora

3.01.001

Papel carta para impressora.

Pacote com 1000 folhas Unidade Unidade Unidade Unidade Unidade

4.01.001

Microcomputador Pentium 200 Mhz

4.01.002

Microcomputador Pentium 233 Mhz

4.02.001

Microcomputador Pentium II 266 Mhz

4.02.002

Microcomputador Pentium II 300 Mhz

4.02.003

Microcomputador Notebook 233 Mhz

.

.

.

.

.

.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

ARQUIVO DE FORNECEDORES

Código

 

Nome

Endereço

 

Telefone

0001

Arapuca Suprimentos Ltda.

 

Rua Intel, 486 Rua FoxPro, 25 Rua Delphi, 30

666-6666

 

0002

Infosup Ltda.

680-6868

0003

AGV Suprimentos Ltda.

343-5643

.

.

.

 

.

.

.

.

.

 

ARQUIVO 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

.

.

.

.

.

.

Esta base de dados contém informações de três tipos, ou melhor, sobre três entidades:

Dados sobre produtos (entidade produto), armazenados no arquivo de produtos;

Dados

sobre

fornecedores

(entidade

fornecedor),

armazenados

no

arquivo

fornecedores e;

de

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 no arquivo de origem dos produtos.

As informações relativas a cada uma das entidades de interesse da organização são armazenadas numa tabela ou arquivo de dados individual. Por sua vez, cada um destes arquivos é formado por um conjunto de registros que descreve, através de atributos ou dados, cada entidade nele armazenada.

Todos os registros de um arquivo, identificados pelas linhas de cada tabela, possui o mesmo formato, ou seja, o mesmo conjunto de dados ou atributos que descrevem as entidades.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Os registros 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 arquivo 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 é conhecido como chave primária ou chave identificadora do arquivo. A chave primária é, portanto, aquele atributo, ou conjunto de atributos, utilizado para distinguir ou identificar de forma única cada registro dentro de um arquivo de dados.

Uma chave primária não deve possuir atributos desnecessários para a identificação dos registros. Se considera 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 do arquivo de dados.

No caso da base de dados de compras, exemplificada anteriormente, as chaves primárias de cada arquivo são:

Arquivo dos Produtos:

código do produto.

Arquivo dos Fornecedores:

código do fornecedor.

Arquivo Origem dos Produtos:

código do fornecedor + código do produto.

Cada chave primária é suficiente para identificar univocamente cada um dos registros dos arquivos da base de dados. Em conseqüência, em cada arquivo não deverá haver mais do que um registro 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 no arquivo. Contudo, em muitos casos, principalmente em SGBDs mais simples para microcomputadores, ainda é possível incluir vários registros com chaves primárias idênticas, sem que seja gerado um erro, o que causará sérios problemas para a utilização da informação armazenada na base de dados.

Índices de Acesso

Um índice de acesso é um arquivo auxiliar utilizado internamente pelo SGBD para acessar diretamente cada registro do arquivo de dados a ele associado. A operação de indexação (criação do arquivo de índice pelo SGBD) ordena os registros de um arquivo de dados de acordo com os campos utilizados como chave e incrementa sensivelmente a velocidade de execução de algumas operações sobre o arquivo de dados, principalmente as relacionadas

27

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

com a localização de registros. Normalmente, para cada arquivo 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 um arquivo 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 um arquivo ou para classificar os registros do arquivo

de acordo com ordem necessária para a obtenção da informação desejada.

Na figura 03 é ilustrado um exemplo didático simplificado do funcionamento de um arquivo de índice associado à um arquivo de dados. Normalmente, os registros de um arquivo de dados não estão ordenados, mas contém todos os dados que descrevem a entidade nele armazenada. Para acessá-los de forma ordenada é criado e mantido um arquivo ordenado (arquivo de índice) que contém apenas a chave de ordenação (ou acesso) e o número do registro do arquivo de dados que a possui. Assim, localizando-se uma determinada chave no arquivo de índice, torna-se possível o acesso direto ao registro do arquivo de dados por ela identificado.

Comparando um arquivo 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 03. 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 do arquivo 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 no arquivo de dados praticamente independe da quantidade de registros que o mesmo possui.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Aplicada à Administração - Prof. Antonio Geraldo Vidal Fig. 03 Esquema de arquivos de índice e

Fig. 03 Esquema de arquivos de índice e da busca binária

Projeto de Bases de Dados

Antes de começarmos a examinar as técnicas para o projeto e desenvolvimento de sistemas aplicativos (sistemas de informação automatizados), vamos fixar alguns dos objetivos que se deve alcançar no projeto e determinar, em particular, qual é o resultado final que se deseja obter do processo de projeto de uma base de dados para um sistema aplicativo. Os principais objetivos do projeto de uma base de dados são:

A base de dados deve ser capaz de armazenar toda a informação pertinente ao sistema:

Ao se desenvolver um sistema aplicativo, 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, que deverão ser armazenados na base de dados. Apenas após estas terem sido identificadas poderemos determinar o número de arquivos de dados necessários e quais campos comporão os registros de cada um deles. 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ó.

A 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 arquivos diferentes para que se possa obter a informação necessária. Isso é especialmente necessário quanto forem estabelecidos relacionamentos (ligações) entre arquivos 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 é

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

duplicada mas 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, 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 ajudaram a definir a informação que deverá estar contida em cada arquivo que formará a base de dados do sistema.

O número de arquivos que deve compor a base de dados deve ser reduzido ao mínimo:

Este objetivo contempla o fato de que, se a divisão dos arquivos de dados em outros menores pode ser interessante para eliminar certos problemas de atualização e armazenamento, a existência de um número muito elevado de arquivos na base de dados de um mesmo sistema aplicativo pode tornar incomoda e trabalhosa a manutenção de todos eles. Poderíamos resumir dizendo que não é conveniente que o número de arquivos de uma base de dados cresça incontrolavelmente.

Os arquivos obtidos devem estar normalizados, a fim de minimizar os problemas de atualização de dados:

Certos tipos de arquivos são mais propensos do que outros a problemas de atualização

e manutenção. O desenvolvedor que está projetando uma base de dados deve saber

detectar os arquivos que são potencialmente problemáticos para poder normalizá-los.

A normalização de arquivos é basicamente uma técnica de decomposição ou subdivisão

de um arquivo de dados em dois ou mais arquivos menores, através de um procedimento específico para determinar a melhor maneira de efetuar a decomposição, de forma a evitar problemas de atualização de dados nos arquivos. A técnica de normalização será estudada mais adiante nesta apostila.

Você provavelmente deve ter percebido que os dois últimos objetivos perseguem propósitos opostos. Normalmente, o projeto da base de dados de um sistema aplicativo é o resultado de um compromisso equilibrado entre ambos, de acordo com as características do sistema que estiver sendo desenvolvido.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Etapas do Projeto de Sistemas

Introdução

A partir da especificação dos requisitos, obtida na fase de levantamento, o projeto de um

sistema de informação computadorizado pode ser dividido em cinco etapas, normalmente conhecidas como modelagem do sistema.

Etapa 1 Modelagem de Processos

A primeira etapa do projeto de um sistema aplicativo é o desenvolvimento de um esquema

gráfico denominado modelo de processos do negócio ou BPM (Business Process Model) que abrange o sistema como um todo. O modelo de processos do negócio descreve graficamente e de maneira simples o contexto do sistema, determinando o que ocorrerá em cada área ou função da empresa que será afetada ou envolvida, as operações ou processos a serem desempenhados, os arquivos de dados necessários e o fluxo de dados entre eles. A simplicidade do modelo de processos do negócio deve-se ao fato de que apenas quatro símbolos são utilizados para produzir um esquema que representa os usuários externos, os processos e os dados de qualquer sistema de informação, no nível de detalhamento desejado. As técnicas para construção de modelos de processos do negócio são discutidas mais adiante, mas basicamente sua utilização permite:

1. Fixar a fronteira entre o sistema e a área da empresa/organização por ele abrangida, ou seja, o que não estiver representado pelo modelo de processos do negócio não faz parte do sistema que está sendo projetado.

2. Mostrar a pessoas sem qualquer conhecimento de informática, mas familiarizadas com a administração da empresa, a estrutura de funcionamento do sistema e como os dados serão processados, pois a compreensão do modelo de processos do negócio é simples.

3. Interrelacionar tanto os dados armazenados no sistema como os processos que transformam estes dados, representando de forma completa o sistema.

De acordo o autor ou metodologia adotada, há várias denominações e formas para se representar o modelo de processos do negócio. Uma das mais tradicionais, e que adotaremos nesta apostila é a proposta por Gane & Sarson, que originalmente o denominaram de Diagrama de Fluxo de Dados (DFD).

Etapa 2 Modelagem de Dados

A partir do modelo de processos do negócio, a segunda etapa consiste na elaboração de

uma análise de entidades e relacionamentos, ou seja, na definição dos objetos de informação ou entidades de interesse para os usuários, cujos dados devem ser armazenados e relacionados através dos arquivos que formarão a base de dados do sistema. Para ilustrar a estrutura dos dados do sistema, é construído um diagrama

31

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

contendo cada entidade identificada e linhas interligando-as, representando o relacionamento entre elas. 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 objetos que comporão a base de dados do sistema: um-para-um, um-para-muitos ou muitos-para- muitos. Através do RDM, um relacionamento do tipo muitos-para-muitos deve ser subdividido em dois relacionamentos um-para-muitos, criando-se um objeto ou entidade especial denominada "entidade intersectora ou associativa". Além disso, para cada relacionamento um-para-um, verifica-se se cada entidade é verdadeiramente única ou pode ser formada por um conjunto de entidades de menor nível.

A construção do RDM, que será discutida mais adiante, fornece uma visão de alto nível dos arquivos de dados envolvidos no sistema, ajuda a descobrir os objetos de informação ou entidades que não foram detectados pelo BPM e a simplificar a estrutura de dados do sistema. Além disso, através do RDM são definidas as chaves identificadoras ou primárias de cada arquivo de dados, bem como suas chaves estrangeiras, necessárias para estabelecer o relacionamentos entre as entidades. Através destas chaves os registros dos arquivos de dados poderão ser acessados e processados para fornecer as informações necessárias.

Após a construção do RDM, nesta etapa também é elaborada uma lista detalhada com as características de todos os dados que serão armazenados em cada arquivo que formará a base de dados do sistema. 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 implementação física da base de dados através do SGBD escolhido.

Etapa 3 Normalização

Utilizando todas as informações disponíveis até agora para descrever a estrutura de dados do sistema, na terceira etapa devemos adequar os arquivos de dados que formarão a base de dados do sistema ao processamento pelo computador. Como será descrito mais adiante, os arquivos de dados ou tabelas do sistema deverão ser simplificadas ou normalizadas, para que possam ser fisicamente criadas no disco do computador e atualizadas com segurança e consistência pelo sistema. Através da técnica de normalização se garante que todas as tabelas necessárias serão criadas, todos os dados de todas as entidades estarão nelas armazenadas e haverá um mínimo de duplicação de dados para interligá-las, eliminando-se a redundância.

As regras a serem seguidas para a normalização de arquivos de dados fundamentalmente determinam que num arquivo ou tabela adequadamente simplificada, cada campo não- chave deve depender da chave inteira (chave primária), e apenas desta chave. A aplicação desta regra aos dados que deverão ser armazenados, de acordo RDM, fornecerá um conjunto de arquivos mais simplificados e mais adequados para a implementação da base

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

de dados do sistema. Neste conjunto de arquivos deveremos ainda rever os dados que especificarmos para evitar a criação de sinônimos (nomes diferentes denotando a mesma coisa) e homônimos (nomes iguais denotando coisas diferentes). Nomes exclusivos e únicos, definidos através de uma convenção consistente, deverão ser utilizados para denotar cada dado a ser armazenado nos arquivos do sistema.

Etapa 4 Reconstrução do BPM e do RDM

Como resultado da análise de entidades e relacionamentos e do processo de normalização dos arquivos de dados, nesta etapa deve ser reconstruído o BPM, para refletir uma visão mais precisa dos processos e dados que irão compor o sistema.

Como resultado do processo de normalização dos arquivos de dados, nesta etapa também deve também ser reconstruído o RDM, para refletir uma visão mais precisa dos dados e relacionamentos que irão compor a base de dados do sistema.

Na verdade, o processo de projeto de um sistema de informação é interativo e convergente, ou seja, cada etapa subsequente pode afetar as anteriores que, portanto, devem ser reconstruídas até que estejam todas coerentes e consistentes.

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

Na quinta e última etapa do projeto para o desenvolvimento de um sistema de informação automatizado, dividimos o BPM reconstruído na quarta etapa em módulos menores, ou seja, em partes ou subsistemas que serão desenvolvidos como unidades ou módulos individuais. É conveniente representar a definição dos módulos do sistema em forma de uma árvore que traduza a hierarquia de operação ou execução do sistema. Normalmente, cada módulo, submódulo e suas correspondentes operações serão executadas através de listas ou "menus de opções". A árvore do sistema deve representar a divisão e a hierarquia dos módulos e submódulos que comporão o sistema e a forma como suas operações serão desencadeadas.

Após a definição da árvore ou diagrama hierárquico do sistema, deve ser elaborada a especificação detalhada de cada módulo definido, necessária para se implementar o sistema. Como veremos 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 da árvore do sistema através da qual o módulo poderá ser acessado e suas operações executadas;

Um trecho detalhado do RDM com os arquivos de dados acessados pelo módulo;

A definição dos formatos das telas ou formulários e relatórios envolvidos na execução do módulo;

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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;

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

Implementação do Sistema

Introdução

Uma vez especificados os módulos que comporão o sistema, passa-se para a sua implementação através de uma linguagem de programação ou ferramenta de desenvolvimento adequada. Contudo, convém ressaltar, que as técnicas de especificação que utilizamos até agora são todas estáticas, no sentido de que podem ser interpretadas como se fossem plantas arquitetônicas do projeto de uma casa.

Prototipação

Antes de atingir o desenho do formato das telas do sistema, teremos produzido apenas quadros abstratos (BPM, RDM etc.) que representam a estrutura do sistema através de um modelo conceitual, mas não mostram nada de concreto aos usuários. Por este motivo, quanto maior o projeto, para reduzir os riscos de incompreensão dos usuários, atrasos e fracassos, deve-se adotar a técnica de implementação de cima para baixo (top-down). Essencialmente, ela envolve primeiro a criação de um esqueleto ou protótipo do sistema, apenas o suficiente para testar a integração de seus diversos módulos, antes de desenvolver os seus programas de forma completa e detalhada.

Adotando a implementação de cima para baixo é possível testar a integração dos módulos

e submódulos no início da codificação dos programas, antes que um grande investimento

tenha sido feito. A implementação deverá ser planejada como uma série de versões, cada uma testando determinadas partes do sistema (módulos ou conjuntos de módulos), sucessivamente tratando os dados mais complexos e/ou realizando mais operações, até que todo o sistema tenha sido implementado de forma completa, atendendo todas as necessidades dos usuários.

Para os usuários, os formulários, os relatórios, os processos de cálculo e outras entradas/saídas são o sistema. Porém, mesmo já tendo desenhado o formato das telas e dos relatórios, o diálogo com o usuário não é estático; ele depende de cada ação do operador, e muitas vezes é difícil descrever e visualizar o que o sistema fará no papel.

Devido à facilidade de desenvolvimento que hoje oferecem determinadas ferramentas, a

partir da especificação detalhada dos módulos do sistema, é relativamente rápido criar uma versão prototipada de um módulo específico, que efetivamente apresente formulários/telas

e aceite entradas, de modo que os usuários possam em curto espaço de tempo obter

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

experiência direta e concreta de como poderão trabalhar com o sistema, até que ele seja entregue por completo. Se por acaso os usuários precisarem efetivamente 20 dados para descrever uma determinada entidade, e apenas 18 tiverem sido identificados na fase de projeto, então o trabalho com o protótipo rapidamente permitirá a identificação dos dados faltantes. Além disso, os usuários já poderão iniciar a alimentação dos dados cadastrais do sistema, para que, quando os demais módulos já estiverem finalizados, já possam ser utilizados.

Infelizmente, a velocidade com que um protótipo pode ser produzido através das ferramentas modernas, estimulou certas pessoas a minimizarem o esforço que deve ser investido em definir detalhadamente o projeto do sistema, antes de começar a desenvolver

o

protótipo. Nesse sentido, pode-se distinguir dois tipos de prototipação: a de descoberta

e

a de refinamento.

Prototipação de Descoberta

Neste caso, antes de ser produzido um protótipo, é realizada apenas a análise informal das necessidades, para refletir o que é compreendido como aquilo que os usuários desejam. A experiência de utilizar o protótipo motiva os usuários a pensarem mais concretamente a respeito de suas necessidades, e o protótipo é rapidamente revisto diversas vezes, à medida que os usuários descobrem, especificam e detalham mais suas necessidades.

Quando este método é bem sucedido podem haver consideráveis vantagens, pois sistemas inteiros podem ser entregues a partir do zero em algumas semanas. Entretanto, o risco de fracasso é elevado, principalmente quando o desenvolvedor não possui experiência prévia com o tipo de sistema que está sendo desenvolvido. Os dois maiores perigos com os quais podemos nos defrontar neste tipo de prototipação são:

1. O sistema pode ficar tão grande que tanto os usuários como o desenvolvedor não conseguirá manter todas as funções e dados na memória, perdendo completamente o controle do projeto. Ninguém mais conseguirá definir a abrangência do sistema ou terá certeza de como suas partes se encaixam.

2. O sistema pode entrar numa iteração aparentemente interminável de tentativas e revisões, geralmente porque os usuários e o desenvolvedor são levados a se concentrar nos detalhes físicos do sistema, ao invés de na finalidade do sistema para a empresa.

A prototipação por descoberta é uma abordagem arriscada, sendo recomendável apenas

para aqueles casos, não muito raros, em que os próprios usuários não conseguem ou não podem, a princípio, definir suas necessidades, pois ainda as estão descobrindo. Essa situação é muito comum no desenvolvimento de sistemas de apoio a decisão.

Prototipação de Refinamento

A prototipação de refinamento começa a partir da especificação detalhada dos módulos do

sistema, sendo mais significativa para aqueles módulos em que haverá um intenso diálogo

35

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

interativo entre o usuário e o sistema, cujo funcionamento não pode ser facilmente definido apenas a partir do formato de telas ou relatórios. Utilizando uma ferramenta de desenvolvimento moderna, que possua um gerador automático de programas, pode ser produzido e refinado um protótipo de cada módulo até que o sistema todo esteja completo.

A prototipação de refinamento permite descobrir pequenas falhas no projeto, tais como não incluir um determinado dado numa tela ou relatório, pois, afinal, o usuário sempre conhecerá seu serviço melhor do que o desenvolvedor. Por outro lado, poderá também mostrar a inviabilidade de se colocar uma quantidade muito grande de dados numa única tela ou num único relatório, e assim por diante, até que, tanto os usuários como o desenvolvedor estejam satisfeitos com o funcionamento do sistema.

Via de regra, os desenvolvedores de sistemas devem apresentar aos usuários apropriados um protótipo de cada módulo do sistema o mais cedo possível, para que, através da prototipação de refinamento, com o efetivo envolvimento dos usuários no desenvolvimento, o sistema possa ser concluído rapidamente, com a certeza de sucesso. Entretanto, mesmo utilizando a prototipação de refinamento, está-se sujeito a enfrentar um ciclo interminável de revisões, o que determina que a mesma deve ser cuidadosamente controlada, para que as revisões convirjam para o formato final do sistema. Quando as revisões começarem a divergir deve-se interromper o processo e, através de uma reunião de consenso com os usuários, avaliar o estado atual do sistema e tomar decisões que rapidamente determinem sua convergência para um formato final.

Na maioria dos casos a prototipação por refinamento é a melhor alternativa, suas principais vantagens são:

É elaborado um projeto detalhado do sistema que automaticamente fará parte de sua documentação final;

Em curso espaço de tempo (algumas semanas) os usuários já começam a utilizar e testar o sistema, fornecendo sugestões para o seu refinamento, participando, desta forma, efetivamente do desenvolvimento;

Enquanto os módulos mais complexos vão sendo desenvolvidos, os usuários já iniciam o cadastro de dados no sistema, permitindo, posteriormente, os testes dos módulos mais complexos com dados reais;

Ao final do desenvolvimento, o sistema estará exatamente de acordo com as necessidades dos usuários e estes o compreenderão completamente, além de já estarem treinados para sua operação;

O sucesso do sistema estará praticamente garantido, pois os usuários desenvolvem o sistema em conjunto, percebendo todas as vantagens, desvantagens, dificuldades e facilidades de cada detalhe de implementação. Além disso, passam a ter uma boa noção das implicações e do tempo necessário para qualquer modificação.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Modelo de Processos do Negócio (BPM)

Introdução

O modelo de processos do negócio ou business process model (BPM) é uma das

principais técnicas utilizadas no projeto de sistemas de informação. O BPM é um diagrama gráfico baseado apenas em quatro símbolos que mostra a estrutura do sistema e sua fronteira, ou seja, todas as relações entre os dados (arquivos e fluxos de dados), os processos e funções que transformam estes dados e o limite entre o que pertence ao sistema e que está fora do sistema.

Os símbolos utilizados para construir o BPM são muito simples, sendo muito fácil seu entendimento, quer seja por pessoal especializado em informática, quer seja por pessoal não especializado, mas conhecedor da empresa. Após uma rápida explicação, qualquer pessoa pode ler um BPM e entender a estrutura e a fronteira de um sistema de informação automatizado.

Símbolos do Modelo de Processos do Negócio

Para a construção de um BPM são utilizados apenas quadro símbolos: entidade externa, fluxo de dados, processo e arquivo de dados. Além deles, são também utilizadas algumas convenções, que a seguir descreveremos.

Entidades Externas

Entidades externas representam as origens e/ou destinos de fluxos de dados para dentro e para fora do sistema. Elas, por definição, estão fora do sistema em consideração, e são representadas por um quadrado que recebe um sombreamento em dois dos seus lados para dar um certo relevo. No centro do quadrado é escrito o nome da entidade externa que está sendo representada, como ilustrado na Fig. 04.

As entidades externas correspondem à fronteira do sistema, ou seja, o que ocorre dentro

de uma entidade externa não faz mais parte do sistema. Entretanto, se você precisar

descrever o que ocorre numa entidade externa para entender o sistema, significa que a fronteira do sistema é mais ampla do que está sendo considerada e que, portanto, a entidade externa em questão deve fazer parte do seu sistema.

Uma entidade externa pode representar um grupo de pessoas, como clientes ou fornecedores, um outro sistema, como um sistema de folha de pagamento, ou uma única pessoa, como um diretor ou o presidente da empresa. Elas recebem ou fornecem dados ao sistema, mas não fazem parte dele.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Aplicada à Administração - Prof. Antonio Geraldo Vidal Fig. 04 Entidades externas Quando uma entidade externa

Fig. 04 Entidades externas

Quando uma entidade externa fornece dados para o sistema, deve haver um fluxo de dados saindo da entidade externa em direção ao sistema. Quando uma entidade externa recebe dados do sistema, deve haver um fluxo de dados do sistema para a entidade externa, como ilustrado pela Fig. 05.

para a entidade externa, como ilustrado pela Fig. 05. Fig. 05 Fluxo de dados de e

Fig. 05 Fluxo de dados de e para uma entidade externa

Muitas vezes, por questões de clareza ao se desenhar o BPM, é necessário duplicar as entidades externas para evitar que longas setas de fluxos de dados saiam de um lado do diagrama para o outro, congestionando demasiadamente o desenho. Neste caso, por convenção, coloca-se um par de números entre parênteses num canto do símbolo da entidade externa. O segundo número informa ao leitor do BPM quantas ocorrências da mesma entidade externa estão representadas no diagrama, enquanto que o primeiro indica qual é ocorrência em questão, como ilustra a Fig. 06.

Portanto, em BPMs muito complexos, nos quais poderão existir muitas repetições da mesma entidade externa, é conveniente colocar números entre parênteses, como ilustrado

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

na figura a seguir, para mostrar quantas ocorrências da mesma entidade externa estão representadas e qual é o número de cada entidade externa repetida.

e qual é o número de cada entidade externa repetida. Fig. 06 Duplicação de entidades externas

Fig. 06 Duplicação de entidades externas no BPM

Fluxos de Dados

O caminho através do qual uma ou mais estruturas ou conjuntos de dados fluem de um elemento do BPM para outro é representado por uma seta indicando um fluxo de dados.

Normalmente, cada seta de fluxo de dados deve possuir um nome que descreve a estrutura ou conjunto de dados que está fluindo de um elemento para o outro. Eventualmente, diversas estruturas de dados poderão ser representadas passando pelo mesmo fluxo de dados. Além disso, muitas vezes, para simplificar o diagrama, é conveniente ter setas com duas pontas, indicando fluxos de dados que entram e saem de um determinado elemento.

Como regra geral, as setas representando os fluxos de dados são sempre desenhadas horizontal ou verticalmente. Setas diagonais ou poligonais não devem ser utilizadas. Apenas quando o conteúdo de um fluxo de dados for realmente óbvio, ele não precisa necessariamente receber nomes. A Fig. 07 ilustra representações de fluxos de dados.

Os fluxos de dados indicam movimentos de dados de um elemento do BPM para outro, mas não representam nenhuma consideração temporal, ou seja, não indicam a freqüência e nem quando uma estrutura de dados segue de um lugar para outro. Neste caso, se dependências temporais forem importantes para a análise, deve ser desenvolvido um quadro de tempo especial, fora do BPM.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Aplicada à Administração - Prof. Antonio Geraldo Vidal Fig. 07 Fluxos de dados Processos Um processo

Fig. 07 Fluxos de dados

Processos

Um processo ou uma função, que capta, envia, grava ou transforma os dados de alguma

maneira, é representado por um retângulo com cantos arredondados, como ilustra a Fig.

08.

retângulo com cantos arredondados, como ilustra a Fig. 08. Fig. 08 Um processo Normalmente, na sua

Fig. 08 Um processo

Normalmente, na sua parte superior, o símbolo de um processo recebe um número seqüencial identificador. No seu corpo deve haver uma descrição bem resumida da função ou processo que está sendo representado; via de regra através de um verbo no infinitivo com o objeto sobre o qual a ação está sendo realizada. Opcionalmente, na parte inferior do símbolo do processo, poderá estar escrito o nome do departamento, do programa ou de algum outro agente que realize fisicamente tal processo ou função para o sistema.

Os processos não devem ser duplicados num BPM, entretanto, quando os processos forem realmente idênticos e a duplicação for inevitável, deve ser utilizada a mesma convenção das entidades externas, isto é, um par de números entre parênteses num dos cantos do processo.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Como regra geral, os tratamentos de erro e de exceções não devem ser representados em um BPM, a menos que sejam muito relevantes para os usuários do sistema. O BPM deve ser visto como uma ferramenta de planejamento do sistema, e não como sua especificação detalhada. Sua finalidade é mostrar o fluxo normal de dados entre os principais elementos, e não os detalhes de implementação do sistema.

Arquivos de Dados

Um retângulo alongado com o lado direito aberto é utilizado para representar um ou mais arquivos de dados ou tabelas que comporão a base de dados do sistema.

Por princípio, cada arquivo de dados deve ser representado individualmente no BPM. Contudo, quando dois ou mais arquivos contiverem dados a respeito da mesma entidade, e normalmente forem acessados juntos, pode-se representá-los por um único símbolo, separando seus nomes por uma barra.

por um único símbolo, separando seus nomes por uma barra. Fig. 09 Representação de arquivos de

Fig. 09 Representação de arquivos de dados

Na extremidade do lado esquerdo do símbolo de arquivo de dados, separado por um traço vertical, é normalmente colocado um número seqüencial ou um código para identificar o arquivo de dados que está sendo representado.

Da mesma forma que com os outros elementos, os arquivos de dados também poderão ser repetidos para evitar um emaranhado de fluxos de dados de um canto a outro do BPM. Um par de números entre parênteses deve ser colocado na extremidade esquerda do símbolo de arquivo de dados para indicar sua repetição. O primeiro número deve identificar o número de cada ocorrência e o segundo a quantidade total de ocorrências do mesmo arquivo de dados no BPM, como ilustra a Fig. 10.

do mesmo arquivo de dados no BPM, como ilustra a Fig. 10. Fig. 10 Duplicações de

Fig. 10 Duplicações de arquivos de dados

Quando um arquivo de dados estiver armazenando dados sobre um objeto, como um produto ou um cliente, ele estará sujeito a um volume relativamente baixo de transações rotineiras de manutenção (inclusões, alterações e exclusões de dados). Normalmente,

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

esses fluxos rotineiros de manutenção são representados por uma entidade externa alimentando dados para dentro de um processo que atualiza o arquivo de dados, como é ilustrado pelo trecho de diagrama da Fig. 11.

dados, como é ilustrado pelo trecho de diagrama da Fig. 11. Fig. 11 Manutenção de um

Fig. 11 Manutenção de um arquivo de dados

Quando diversos sistemas compartilharem um mesmo arquivo de dados, o sistema que estiver sendo projetado poderá acessar e atualizar arquivos de dados que também são acessados e atualizados por outros sistemas relacionados. Neste caso, é conveniente mostrar este fato explicitamente no BPM, através da notação ilustrada na Fig. 12.

Esta notação é uma exceção à regra de que os dados não devem ir diretamente de uma entidade externa para um arquivo de dados, sem passar por um processo responsável pela transferência dos dados.

por um processo responsável pela transferência dos dados. Fig. 12 - Atualização de arquivos de dados

Fig. 12 - Atualização de arquivos de dados por sistemas diferentes

Construção do Modelo de Processos do Negócio

De acordo com a complexidade do sistema a ser desenvolvido, o modelo de processos do negócio pode assumir um tamanho considerável. Por este motivo, recomenda-se manter os processos dos BPMs dentro de um "tamanho administrável". Este tamanho administrável é totalmente subjetivo mas, em geral, nenhum processo deve necessitar mais do que duas ou três páginas escritas para ser descrito.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Entretanto, se um BPM contiver um processo que o analista julgue ser superior ao "tamanho administrável", há duas alternativas: fissão e explosão.

Com a fissão, o processo original é substituído no BPM por um conjunto de subprocessos, mais simples, que a ele são equivalentes, mas que tornam mais fácil o entendimento do sistema.

Com a explosão, o processo original é mantido no BPM a nível do sistema como um todo, mas cria-se um novo BPM, de nível inferior, formado por processos mais simples e pelos arquivos de dados que vierem a ser necessários, mas que não foram explicitados no desenvolvimento do BPM a nível do sistema como um todo.

Recomenda-se que se evite a explosão do BPM, e que um sistema de informação seja representado por um único modelo de processos do negócio. Cada processo contido no BPM não deve necessitar mais do que quatro páginas para ser descrito, para que não ultrapasse um "tamanho administrável" e seja fácil de ser explicado.

Finalmente, após haver desenhado uma primeira versão do BPM do sistema, é recomendável utilizar a relação de verificação apresentada a seguir para corrigir os erros e deficiências mais comuns que podem ocorrer e para se aprimorar o BPM.

Lista de Verificação para o BPM

1. Todos os processos possuem uma descrição sucinta do tipo "verbo e objeto"?

2. Todos os arquivos de dados representam objetos de informação de interesse do sistema?

3. Todos os processos e arquivos de dados possuem pelo menos um fluxo de dados de entrada e um fluxo de dados de saída?

4. Os fluxos de dados sem identificação podem ser facilmente identificados?

5. Todos os fluxos de dados começam ou terminam em um processo?

6. Todos os fluxos de dados possuem pelo menos uma seta de direção?

7. Há algum arquivo de dados com apenas um fluxo de entrada e um fluxo de saída que não sejam arquivos intermediários ou temporários?

8. Todos os processos foram representados dentro de um "tamanho administrável" e facilmente compreensível?

9. Todos os arquivos de dados foram representados?

10.Não há nenhum fluxo de dados faltando?

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Lista de Recomendações para o BPM

1.

Os BPMs são mais legíveis se as entidades externas forem dispostas nas bordas do diagrama, de forma que a fronteira do sistema (ou contexto) se situe dentro do contorno de entidades externas. Uma linha de contexto pode ser desenhado para ressaltar este fato.

2.

Se os fluxos de dados principais ocorrerem do lado esquerdo para o lado direito do diagrama, a leitura se tornará mais fácil e rápida.

3.

As duplicações de símbolos devem ser mantidas ao mínimo, e consistir de um número aceitável de linhas de fluxo de dados cruzando umas com as outras.

4.

Inicie a construção do BPM pelas entidades externas, em seguida pelas entradas que delas são originadas, juntamente com as saídas que irão para elas.

5.

O primeiro desenho de um BPM sempre terá um papel de rascunho. Sua finalidade é a identificação de todas as entidades externas, processos e arquivos de dados que formarão o sistema, além de se colocar as ligações ou fluxo de dados entre eles. Versões posteriores aprimorarão as definições e o desenho.

6.

Ao desenhar um primeiro rascunho do BPM, pense em como o sistema funciona realmente, qual é a entrada ou processo que o inicia, e comece o desenho por aí.

7.

A ordem mais lógica para se desenhar o BPM é definir a entidade externa ou processo que gera uma entrada de dados, depois o processo que trata essa entrada, em seguida os arquivos de dados que são utilizados para armazená-la e para garantir o funcionamento dos processos afetados e, finalmente, definir as saídas que são geradas pelo processo.

O

primeiro rascunho do BPM deve ser feito a mão livre, escrevendo os símbolos e as

linhas dos fluxos de dados muito levemente, a lápis. Procure ser abrangente, mesmo que o diagrama inicialmente tenha uma forma desajeitada, deixe-o assim. O segundo rascunho e

os posteriores podem ser produzidos utilizando uma ferramenta de software automatizada.

Embora uma ferramenta gráfica genérica possa ser utilizada, há várias ferramentas de software especificamente projetadas para a modelagem ou projeto lógico de sistemas de informação. A maioria delas também está integrada com um recurso de dicionário de dados, que pode armazenar os detalhes do modelo lógico do sistema. Algumas até possuem recursos de desenho de telas que podem ser utilizados na prototipação do sistema. Essas ferramentas de software passaram a ser conhecidas como ferramentas CASE (Computer Assisted Software Engineering - Engenharia de Software Apoiada por

Computador) e um bom exemplo é o Silverrun, que utilizaremos no curso.

A Fig. 13 na página seguinte apresenta um exemplo simplificado de um modelo de

processos do negócio completo, a nível de sistema como um todo.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Modelo Relacional de Dados (RDM)

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 satisfazer os objetivos do sistema precisamos armazenar dados a respeito deles.

Os objetos de informação são geralmente entidades ou eventos, por exemplo: clientes, fornecedores, produtos, vendas, compras e cobranças. As entidades são objetos que existem durante um determinado tempo (produtos, clientes, fornecedores etc.). Os eventos são objetos que ocorrem num determinado momento específico (vendas, compras, cobranças, produções etc.). Uma entidade poderá ter um ou mais eventos a ela associados (uma ou mais vendas, uma ou mais cobranças etc.). Por outro lado, um evento pode representar a associação de uma ou mais entidades (uma venda de diversos produtos para um cliente, ou uma compra de diversos produtos de um fornecedor).

Cada entidade ou evento deve ser representado pelo menos por um arquivo de dados. Consequentemente, 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, como por exemplo a "data de admissão" da entidade funcionário, ou um dado de um evento, como por exemplo a "data da compra" de um evento compra.

Como regra geral, cada arquivo de dados, definido pelo modelo de processos do negócio, armazena os dados que descrevem entidades e eventos de interesse do sistema de informação. Normalmente, cada entidade que compõe a base de dados de um sistema aplicativo poderá estar relacionada com outras. Assim, por exemplo, um cliente poderá estar relacionado com várias vendas, uma venda com vários produtos, um vendedor com várias vendas, e assim por diante.

Portanto, tendo em vista que as entidades de uma base de dados estão relacionadas, e que, através desse relacionamento são geradas informações, como por exemplo, todos os produtos vendidos a um cliente, é importante definir todos os relacionamentos entre as entidades e o seu correspondente tipo.

Por identificar todas as entidades que formarão a base de dados, por definir todos os relacionamentos entre elas e por descrever o tipo de cada relacionamento, o modelo relacional de dados (RDM) é fundamental para o projeto de qualquer base de dados.

O

RDM mostra os três tipos de relacionamento possíveis entre as entidades e os eventos

de

um BPM: um-para-um (1,1), um-para-muitos (1,N) e muitos-para-muitos (N,N).

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Cada entidade é representada por um retângulo, e o relacionamento entre elas por uma linha unindo os retângulos. O tipo do relacionamento é representado por um par de números na extremidade da linha de relacionamento: 1 identifica um relacionamento com uma única entidade e N identifica um relacionamento com muitas entidades e 0 identifica o relacionamento com nenhuma entidade. A descrição do relacionamento deve ser feita ao longo das linhas que interligam as entidades relacionadas.

Na Fig. 14 é representado o relacionamento entre PESSOA e DEPARTAMENTO. O par de números 1,1 indica que uma pessoa trabalha em um único departamento. Por outro lado, o par de números 0,N indica que num departamento podem trabalhar nenhuma ( 0 ) ou várias pessoas ( N ).

podem trabalhar nenhuma ( 0 ) ou várias pessoas ( N ). Fig. 14 Relacionamento 0:N

Fig. 14 Relacionamento 0:N entre PESSOA e DEPARTAMENTO

Portanto, uma pessoa está relacionada a um departamento (1,1), e um departamento está relacionado a nenhuma ou várias pessoas (0,N).

está relacionado a nenhuma ou várias pessoas (0,N). Fig. 15 - Relacionamento 1:N entre VENDA E

Fig. 15 - Relacionamento 1:N entre VENDA E ITENS DA VENDA

No exemplo da Fig. 15 cada VENDA envolve um ou mais ITENS ou produtos vendidos (1,N), mas um ITEM ou produto é parte de apenas uma venda (1,1).

), mas um ITEM ou produto é parte de apenas uma venda ( 1,1 ). Fig.

Fig. 16 Relacionamento N:N entre FORNECEDOR e PRODUTO

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

No exemplo da Fig. 16 cada FORNECEDOR fornece um ou mais produtos (1,N) e cada PRODUTO pode ser fornecido por um ou mais fornecedores (1,N).

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,N)" ou "um produto é fornecido por um ou vários fornecedores (1,N)".

Quando um relacionamento for suficientemente óbvio, não será necessário indentificá-lo através de uma palavra descritiva, como ilustrado na Fig. 17.

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:

único. Por exemplo, tomemos as entidades PRODUTO e ESTOQUE: Fig. 17 - Relacionamento 1:1 entre PRODUTO

Fig. 17 - Relacionamento 1:1 entre PRODUTO e ESTOQUE

Como cada PRODUTO é armazenado no ESTOQUE, podemos considerar apenas uma entidade PRODUTO ESTOCADO:

podemos considerar apenas uma entidade PRODUTO ESTOCADO: Fig. 18 - Entidade PRODUTO ESTOCADO Neste caso, as

Fig. 18 - Entidade PRODUTO ESTOCADO

Neste caso, as entidades PRODUTO e ESTOQUE não são realmente distintas e, por esse motivo, devemos armazená-las num único arquivo 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 é denominado chave primária do objeto, e é sublinhado no diagrama do RDM, como ilustrado na Fig.

19.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

O relacionamento entre os dois objetos deverá ser realizado através de uma chave de relacionamento, denominada chave estrangeira. A chave estrangeira deverá estar indicada no objeto relacionado, como ilustrado na Fig. 19. 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.

é a chave primária do objeto ao qual este se relaciona. Fig. 19 Relacionamento um-para-um e

Fig. 19 Relacionamento um-para-um e suas chaves

No caso do relacionamento um-para-um (1,1) entre uma disciplina e um 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 a uma única DISCIPLINA, então a chave estrangeira, que realiza o relacionamento (código da disciplina) deve ser armazenada no arquivo que descreve o professor, e aponta ou determina a disciplina por ele lecionada., como ilustrado na Fig. 19.

Portanto, no arquivo PROFESSOR, o dado "código da disciplina" é uma chave estrangeira, significando que se trata de um dado do arquivo DISCIPLINA, mas que precisa existir no arquivo PROFESSOR para permitir o relacionamento entre ambos. Note que neste relacionamento entre DISCIPLINA e PROFESSOR, um professor pode apenas lecionar uma disciplina.

Uma outra forma alternativa de relacionar professores e disciplinas seria admitir que uma disciplina somente é ministrada por um professor. Isto significa incluir a chave estrangeira "número do professor" no arquivo DISCIPLINA.

estrangeira "número do professor" no arquivo DISCIPLINA. Fig. 20 - Chave estrangeira PROFESSOR x DISCIPLINA 49

Fig. 20 - Chave estrangeira PROFESSOR x DISCIPLINA

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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), mas pelo menos um-para-muitos (1,N).

Estes exemplos servem para apresentar a análise que deve ser feita ao se projetar um relacionamento um-para-um:

O relacionamento sempre será um-para-um?

Há alguma possibilidade de no futuro ele se tornar um-para-muitos?

Qual forma poderá se adaptar a uma possível mudança futura do sistema?

Em que arquivo deverá ser incluída a "chave estrangeira" para ser utilizada como apontadora do relacionamento?

Relacionamentos Um-para-Muitos

Um relacionamento um-para-muitos (1,N) ocorre quando um único objeto (entidade) está relacionado com vários outros objetos. Como cada objeto de informação sempre possui um arquivo de dados contendo seus atributos, a chave primária do "objeto um" deve ser uma "chave estrangeira" no arquivo que descreve o "objeto muitos", podendo ser parte de sua chave primária ou não.

No exemplo ilustrado pela Fig. 21, 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.

da disciplina" é a chave estrangeira de PROFESSOR. Fig. 21 - Relacionamento um-para-muitos entre DISCIPLINA e

Fig. 21 - Relacionamento um-para-muitos entre DISCIPLINA e PROFESSOR

Neste caso, uma disciplina pode ser ministrada por vários professores (1,N), mas um professor somente pode lecionar uma única disciplina (1,1).

Já no exemplo ilustrado pela Fig. 22, 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.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Aplicada à Administração - Prof. Antonio Geraldo Vidal Fig. 22 - Relacionamento um-para-muitos entre PROFESSOR e

Fig. 22 - Relacionamento um-para-muitos entre PROFESSOR e DISCIPLINA

Neste caso, um professor pode ser lecionar várias disciplinas (1,N), 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,N), 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 N,N 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.

No exemplo ilustrado pela Fig. 23, em que um professor leciona várias disciplinas (1,N) e uma disciplina pode ser ministrada por vários professores. A única linha do relacionamento muitos-para-muitos (N,N) pode ser considerada como sendo a combinação de dois relacionamentos um-para-muitos (1,N), ambos com um objeto de interseção.

um-para-muitos (1,N), ambos com um objeto de interseção. Fig. 21 - Relacionamento muitos-para-muitos (N,N) entre

Fig. 21 - Relacionamento muitos-para-muitos (N,N) entre DISCIPLINA e PROFESSOR

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?

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 Fig. 24 ilustra o relacionamento muitos-para-muitos (N,N) entre DISCIPLINA e PROFESSOR resolvido por um relacionamento um-para-muitos (1,N) entre DISCIPLINA e TURMA e um relacionamento um-para-muitos (1,N) entre PROFESSOR e TURMA.

relacionamento um-para-muitos (1,N) entre PROFESSOR e TURMA. Fig. 22 - Relacionamento muitos-para-muitos resolvido Neste

Fig. 22 - Relacionamento muitos-para-muitos resolvido

Neste caso, a chave primária de TURMA é composta por duas chaves estrangeiras. Ou seja, 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 e concatenados formam a sua chave primária, pois a identificam.

Conjuntos de Relacionamentos

Consideremos agora um 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,N), como indica a Fig. 23.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Aplicada à Administração - Prof. Antonio Geraldo Vidal Fig. 23 - Relacionamento entre VENDA e ITEM

Fig. 23 - 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,N), ou seja, um produto pode estar relacionado a vários itens vendidos, como ilustra a Fig. 24.

a vários itens vendidos, como ilustra a Fig. 24. Fig. 24 - Relacionamento entre ITEM VENDIDO

Fig. 24 - Relacionamento entre ITEM VENDIDO e PRODUTO

Se agora considerarmos pelo lado dos clientes, verificaremos que para um mesmo cliente poderão haver várias vendas e, portanto, o "código do cliente", identificador do cliente, deverá ser parte do arquivo 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 Fig. 25.

para identificar unicamente cada venda, como ilustrado na Fig. 25. Fig. 25 - Relacionamento entre CLIENTE

Fig. 25 - Relacionamento entre CLIENTE e VENDA

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

É 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, surge, então, um conjunto de relacionamentos um-para-muitos, como ilustrado pela Fig. 26.

relacionamentos um-para-muitos, como ilustrado pela Fig. 26. Fig. 26 - Relacionamento CLIENTE - VENDA - ITEM

Fig. 26 - Relacionamento CLIENTE - VENDA - ITEM VENDIDO - PRODUTO

Não é necessário incluir o "código do cliente" também no arquivo ITEM VENDIDO, pois se desejarmos produzir um relatório que informe a quais clientes foram vendidos quais produtos, é possível pesquisar todos os "números de notas fiscais" no arquivo ITEM VENDIDO à procura dos produtos do arquivo PRODUTO e depois, usando estes números, pesquisar todos os clientes nos arquivos VENDA e CLIENTE. Entretanto, poderíamos opcionalmente simplificar este processo e obter diretamente a informação desejada incluindo a chave estrangeira "código do cliente" do arquivo CLIENTE no arquivo ITEM VENDIDO.

Muitas vezes, no projeto da base de dados de um sistema aplicativo, podemos incluir diversos dados ou chaves estrangeiras nos arquivos relacionados, com o objetivo de simplificar a programação necessária para a obtenção das informações que deverão ser fornecidas aos usuários. A análise dos relacionamentos e chaves estrangeiras que deverão ser incluídas em cada arquivo de dados deve ser feita nesta fase, com a ajuda do modelo de relacionamento de dados (RDM - Relational Data Model).

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 dos arquivos de dados que comporão o 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 um arquivo 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 no arquivo 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 de determinadas entidades, como os produtos, devemos considerar também 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 no arquivo 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. O arquivo original poderá ser, então, totalmente limpo para iniciar um novo período. Posteriormente, os dados históricos deverão poder ser recuperados dos arquivos históricos caso sejam necessários.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Tipos de Objeto

Muitas vezes, diversos objetos de informação identificados pela análise de entidades e relacionamentos são, na verdade, tipos diferentes do mesmo objeto. Podemos citar, por exemplo, com respeito à entidade empregado, os ativos, os ex-empregados e os aposentados; ou os pagos por hora, os pagos por semana e os pagos por mês. São todos subtipos ou classificações diferentes da mesma entidade empregado. A questão crucial é a similaridade ou a diferença entre os dados que descrevem os diversos subtipos ou subgrupos de empregados. Poderá haver apenas um arquivo de dados para armazenar todos os tipos, com um determinado dado (código) que os distinga, ou poderá haver um arquivo de dados para cada subtipo. Esta decisão requer um estudo detalhado do sistema e do software através do qual ele será implementado, com uma avaliação das vantagens e das desvantagens em cada caso.

Um outro exemplo pode ser considerado tomando-se o evento venda. Podemos ter vendas a vista, vendas a prazo, vendas através de cartão de crédito e vendas com cheques pré- datados. Todas elas têm uma data, um cliente e um valor total em comum. O tipo de venda pode ser armazenado num dado denominado "especificação", contendo códigos que identifiquem o tipo da venda efetuada: VI a vista, CC cartão de crédito, CP cheque pré e VP a prazo.

No modelo relacional de dados os subtipos ou especificações existentes dentro de uma entidade ou evento devem ser representados como ilustra a Fig. 27, na qual estão destacados os diferentes subtipos que podem existir. Note que para cada subtipo de venda podem existir outros arquivos relacionados ao arquivo de vendas, para o armazenamento dos dados específicos destes subtipos.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Aplicada à Administração - Prof. Antonio Geraldo Vidal Fig. 27 - Representação de subtipos de entidades

Fig. 27 - Representação de subtipos de entidades

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 um arquivo na base de dados do sistema. Sua finalidade é esclarecer a natureza dos arquivos de dados do BPM. 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) deve aparecer explicitamente, pois todos já deverão ter sido resolvidos em relacionamentos um-para- muitos (1,N) através da utilização de arquivos de interseção.

Na página seguinte, a Fig. 28 apresenta o modelo relacional de dados (RDM) de um sistema para controle do aluguel de filmes de vídeo locadoras.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Modelagem dos Dados

Introdução

Após a construção do RDM, deve ser definido o conteúdo exato de cada arquivo 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 arquivo que descreve os atributos das entidades e eventos definidos pelo modelo relacional de dados.

Para detalhar os dados que deverão estar contidos nos arquivos de dados ou tabelas do sistema, 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 arquivo. O objetivo é obter o menor número possível de dados em cada arquivo, 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 imaginarem, com antecipação, 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 arquivo, 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.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Normalmente, toda entidade, como por exemplo um produto, possui 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 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 arquivo 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 tenha 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

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

dentro dos arquivos 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 nos arquivos de dados de alguns softwares e para economizar digitação e simplificar a programação, recomendamos que os nomes abreviados dos dados tenham no máximo 10 posições. Além disso, pode ser utilizado o sublinhado ( _ ) para separar nomes compostos, pois os nomes abreviados não poderão conter espaços em branco. Por exemplo: cod_prod, cod_cli, num_vend etc.

Sinônimos

Muitas vezes, nomes diferentes são utilizados para identificar uma mesma entidade ou evento em locais diferentes de uma organização. Os termos "empregado", "funcionário" ou "servidor" poderão ser utilizados em diferentes áreas para significar uma pessoa que trabalha na organização. Eles são sinônimos e, embora seja melhor evitar a utilização de sinônimos num sistema, eles podem ser tratados escolhendo-se um dos nomes como sendo o principal e descrevendo os demais como sinônimos do nome principal. O mesmo ocorre com os nomes de dados, por exemplo, "estado" e "uf" ou "cidade" e "município", ou ainda, em alguns casos, "custo" e "preço".

Homônimos

A situação inversa também existe, ou seja, um determinado nome poderá ter significados

diferentes para entidades ou eventos distintos em diversas áreas da organização. Por exemplo, o nome "preço", poderá significar o "preço unitário de venda" para o departamento de vendas, o "preço unitário de custo" para o departamento de compras e o "preço total de venda ou de compra" para o departamento de contabilidade.

Deve ficar suficientemente claro, dentro do contexto no qual o homônimo é utilizado, que significado, dentre os diversos possíveis, ele terá. Se não se conseguir determinar com clareza um significado único, então cada dado deverá receber um nome diferente.

Domínio

O domínio de um dado é o conjunto de valores válidos para ser seu conteúdo. Assim, o

domínio de uma data pode ser qualquer data válida posterior a 01/01/1900; o domínio do preço de um produto pode ser um valor entre R$ 100,00 e R$ 2.000,00; o domínio da

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 um arquivo 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. Comprimento do dado: refere-se ao tamanho ou 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 nos arquivos 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 editados ou apresentados, definindo as posições de determinados símbolos, como pontinhos, tracinhos e barras, geralmente contidos em códigos, ou a presença de pontos separando os milhares em valores numéricos. O formato do dado é geralmente definido pela cláusula PICTURE ou MÁSCARA dos comandos e funções do software utilizado para o desenvolvimento do sistema. Para definir o formato dos dados são utilizadas máscaras de formatação, nas quais normalmente o dígito "9" representa posições onde somente devem ser aceitos dígitos numéricos; a letra "A", posições onde devem ser aceitas letras alfabéticas; e a letra "X", posições onde podem ser aceitos quaisquer valores de dados. Por exemplo, o formato do dado CPF deve ser assim representado como "999.999.999/99", e o formato do dado salário deve ser representado como

"999.999,99".

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

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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.

5. 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 no arquivo 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.

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

7. Responsabilidade pelo dado: revela a pessoa ou a unidade da empresa responsáveis 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.

Exemplo: ESTADO CIVIL

Nome do Dado:

Estado Civil.

Descrição:

Estado civil do funcionário para efeitos legais.

Nome Abreviado:

EST_CIV

Tipo:

Caractere (C ou CHAR)

Comprimento:

1 posição

Formato:

Uma letra maiúscula: A

Domínio:

S = Solteiro, C = Casado, V = Viúvo, J = Separado judicialmente, O = outros.

Origem:

Entrada de dados através da ficha cadastral de funcionário.

Responsabilidade:

Chefe de pessoal.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Dados-chave

Tendo já definido os dados que constituirão os campos de um arquivo 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 do arquivo, ou seja, a chave que identifica cada registro armazenado num arquivo de dados. Todo arquivo 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 do arquivo 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 arquivos 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 ao arquivo de dados, permitindo, desta forma, a localização instantânea dos registros que as possuem.

Estruturas Embutidas

Muitas vezes é interessante subdividir um dado chave em partes que possuam significados especiais. Por exemplo, o código de um produto pode ser formado por três partes, no formato 99.99.999, cada uma com um significado diferente. Desta forma, como ilustra a tabela apresentada a seguir, o código do Leite tipo A é 02.01.001, do Leite tipo B é 02.01.002, e assim por diante. Com esta estrutura de classificação embutida no código dos produtos torna-se mais simples identificar os produtos de um determinado tipo ou de uma determinada categoria, facilitando a geração de relatórios e informações sobre grupos específicos de produtos.

Um exemplo clássico de estruturas embutidas em dados chave é o das contas contábeis. Em um sistema de contabilidade, as contas são classificadas por tipo em ativo, passivo, receita e despesa. Dentro de cada tipo podem ser abertas contas, subcontas e subsubcontas, formando uma hierarquia de totalização. Desta forma, o processamento do balanço e do demonstrativo de resultados fica facilitado, ou seja, as subsubcontas são

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

totalizadas nas subcontas, as subcontas nas contas e por fim, as contas nos respectivos totais de ativo, passivo, receita e despesa.

Sempre que as entidades ou eventos de interesse do sistema puderem ser classificados, é conveniente utilizar estruturas hierárquicas embutidas nos dados chave, pois o acesso e o processamento dos registros será facilitado. Entretanto, a construção das estruturas embutidas deve ser muito bem estudada, para que a necessidade de classificação seja esgotada, isto é, cada entidade ou evento deve receber o código adequado, de acordo com suas características. Se um deles não puder ser adequadamente classificado dentro da estrutura prevista, todos os códigos eventualmente já atribuídos deverão ser revistos e a estrutura de classificação alterada, o que representará um trabalho considerável.

99

= Tipo de produto:

01

= Bebidas

02

= Laticínios

03

= Farináceos

04

= etc.

01.99

= Categoria:

01

= Alcoólicas

02

= Não-alcoólicas

03

= Dietéticas

04

= etc.

02.99

= Categoria:

01

= Leite

02

= Queijo

03

= Iogurte

04

= etc.

01.01.999

= Produto:

001

= Whisky

002

= Vodka

003

= Pinga

004

= etc.

02.01.999

= Produto:

001

= Leite Tipo A

002

= Leite Tipo B

003

= Leite Tipo C

004

= Leite Desnatado

005

= etc.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 num arquivo de dados. Neste caso, deveremos certificar-nos de que todas 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

Introdução

Um sistema de informação utiliza um conjunto de arquivos de dados relacionados, 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 arquivos de dados vinculados ou relacionados, dentro de um determinado contexto, definido pelos objetivos do sistema em questão.

Definidos os arquivos e os respectivos dados que formarã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 arquivos de dados que compõem uma base de dados é denominado normalização.

Os conceitos e as técnicas de normalização de arquivos 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 um arquivo é um conjunto de registros, na teoria nenhum registro, num arquivo de dados, pode ser uma duplicata de qualquer outro. Além disso, de acordo com a teoria dos conjuntos, foram estabelecidos cinco tipos de arquivos normalizados, 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).

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Através da normalização, os arquivos de dados tornam-se mais adequados 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 os arquivos 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 os arquivos 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 campos repetitivos;

2. Eliminar dados redundantes;

3. Eliminar atributos não dependentes.

Primeira Forma Normal (1FN)

Refere-se a qualquer arquivo que possua apenas um valor por campo, ou interseção linha/coluna. O relacionamento entre a chave primária de um arquivo 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 fazem parte da chave primária são chamados "funcionalmente dependentes" desta chave. Arquivos de dados que obedecem esta regra estã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.

O arquivo de dados exemplificado a seguir não está sob qualquer forma normal; entre

outras coisas, há mais de um valor ou supermercado no campo loja.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

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 deste arquivo 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 este arquivo deve ser revisado para que sejam eliminados os grupos repetidos, ou seja, no campo loja deve haver o nome de apenas um supermercado. Isso implicará, a criação de um número maior de linhas ou registros no arquivo, 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, o arquivo 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

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

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

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Segunda Forma Normal (2FN)

Um arquivo 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 um arquivo 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 do arquivo? 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?

No arquivo 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, o arquivo exemplificado anteriormente não está na segunda forma normal, pois ele não passou pelo teste.

Quando um arquivo de dados não está na segunda forma normal, a base de dados não estará correta pelas seguintes razões:

1. O arquivo 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 no mesmo arquivo;

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, o arquivo anterior deverá ser dividido em dois, como ilustrado a seguir.

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

Produtos em Estoque na 2FN

Produto

Loja

Quantidade

Preço

Total

Arroz

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

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

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 os dois arquivos estão na segunda forma normal. O arquivo 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.

O segundo arquivo, 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 o arquivo anterior, apesar de estar na primeira forma normal, contém dados descrevendo duas coisas distintas: produtos e lojas. Como regra geral e importante, um arquivo de dados numa base de dados deve armazenar

FEA/USP / EAD-451- Informática Aplicada à Administração - Prof. Antonio Geraldo Vidal

dados que descrevam apenas uma entidade ou evento. Portanto, um arquivo 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, o primeiro arquivo agora contém apenas dados sobre produtos em estoque e o segundo sobre lojas.

Terceira Forma Normal (3FN)

Um arquivo 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 um arquivo 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?

O arquivo 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, então, que arquivo de produtos em estoque não está sob a terceira forma normal.

Se o campo "valor total" for eliminado, o arquivo de produtos em estoque passa a estar na

terceira forma normal, ocupando menos espaço no disco, sem qualquer perda de informação.

Produtos em Estoque na 3FN

Produto

Loja

Quantidade

Preço

Arroz

200

10,00

Arroz

Eldorado

500

9,00

Arroz

Jumbo

700

11,00

Arroz

Carrefour

1000

8,00

Feijão

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

<