Manualufcd 781 Anlisedesistemasdeinformao

Manual
UFCD 0781
Análise de Sistemas de Informação
Curso Técnico/a de Informática - Sistemas
Formador
Vítor Ferreira
vitor.ferreira@olhares.org
UFCD 0781 - Análise de Sistemas de Informação
Vítor Ferreira
2
Conteúdo
0.- Introdução ..................................................................................................................................... 6
0.1.- Objectivo ................................................................................................................................ 6
0.2.- Conteúdos Programáticos ...................................................................................................... 6
1.- Análise de Sistemas - Conceitos Gerais......................................................................................... 7
1.1.- Definição ................................................................................................................................ 7
1.1.1.- As Diferenças - Dados vs Informação ............................................................................. 7
1.1.2.- As Diferenças – Conhecimento vs Sabedoria .................................................................. 8
1.1.3.- Conceitos Fundamentais em Sistemas............................................................................ 8
1.1.4.- Actividades no Sistema de Informação ........................................................................... 8
1.1.5.- Sistemas de Informação vs Sistemas de Informação Gerenciais .................................... 9
1.1.6.- Dimensões do Sistema Informação ................................................................................ 9
1.2.- Classificação ......................................................................................................................... 10
1.2.1.- Sistema de Apoio às Operações .................................................................................... 11
1.2.2.- Sistemas de Apoio Gerencial......................................................................................... 11
1.2.3.- Sistemas Transacionais (ST) .......................................................................................... 12
1.2.4.- Sistema de Informações Gerenciais (SIG) ..................................................................... 13
1.2.5.- Sistema de Apoio à Decisão (SAD) ................................................................................ 14
1.2.6.- Sistemas de Informação Executivo (SIE) ....................................................................... 15
3
1.3.- Objetivos organizacionais dos Sistemas de Informação ...................................................... 16
1.4.- Em resumo ........................................................................................................................... 18
1.4.1.- Análise de Sistema de Informação ................................................................................ 18
1.4.2.- Papel do Analista de Sistema de Informação................................................................ 19
2.- Metodologias de Análise de Sistemas......................................................................................... 21
2.1./2.2- Classificação e Objectivos.............................................................................................. 21
2.(1/2).1.- Metodologia de Desenho Estruturado de Yourdon ................................................ 22
2.(1/2).2.- Metodologia de Desenho de Jackson ..................................................................... 22
2.(1/2).3.- Metodologia de Desenho de Warnier-Orr .............................................................. 24
2.(1/2).4.- Engenharia de Informação ...................................................................................... 25
3.- Ferramentas de análise estruturada ........................................................................................... 27
3.1.- Diagrama de fluxo de dados (DFD) ...................................................................................... 27
3.1.2.- Vantagens Diagramas de fluxo de dados (DFD) ............................................................ 27
3.1.2.- Características Diagramas de fluxo de dados (DFD) ..................................................... 27
3.1.3.- Desvantagens ou Limitações Diagramas de fluxo de dados (DFD) ............................... 28
3.1.4.- Convenções a usar na construção de Diagrama de Fluxo de Dados............................. 28
3.1.5.- Metodologia de elaboração Diagrama de fluxo de dados (DFD) .................................. 29
3.1.6.- Diretrizes para a elaboração do diagrama de fluxo de dados (DFD): ........................... 30
3.1.7.- Regras a ter em conta na construção de Diagrama de fluxo de dados (DFD) .............. 31
Vítor Ferreira
3.1.7.- Exemplos de Diagramas de Fluxo de Dados ................................................................. 31

3.2.- Diagrama de Contexto ......................................................................................................... 32
3.3.- Exemplo de Diagrama de Fluxo de Dados Nível 0................................................................ 33
4.- Dicionário de dados .................................................................................................................... 35
4.1.- Utilidade e regras de definição ............................................................................................ 35
4.2.- Conjunto de Elementos do Dicionário de Dados ................................................................. 36
4.3.- Notação Típica do Dicionário de Dados ............................................................................... 37
4.4.- Relação com o Diagrama de Fluxo de Dados ....................................................................... 38
4.4.1.-Validação do Dicionário de Dados: ................................................................................ 38
5.- Diagramas de entidade - associação (DEA) ................................................................................. 39
5.1.- Conceito e Origem ............................................................................................................... 39
5.1.1.- Características e Regras de utilização: .......................................................................... 39
5.1.2.- Construção e Refinação do Diagrama Entidade-Associação (DEA)............................... 39
5.2.- Componentes dum DEA ....................................................................................................... 40
5.3.- Propriedades das Entidades ................................................................................................. 41
5.4.- Propriedades dos Atributos ................................................................................................. 41
5.5.- Propriedades das Relações .................................................................................................. 41
5.5.1.- Propriedades das Relações - Representações .............................................................. 42
5.5.2.- Propriedades das Relações - Grau do Relacionamento ................................................ 42
4
5.6.- Caracterização e Regras de utilização: ................................................................................. 43
5.7.- Construção e Refinação do Diagrama Entidade-Associação................................................ 44
5.8.- Notação dos Elementos de um Diagrama Entidade-Associação ......................................... 44
5.8.1.- Tipos de Atributos ......................................................................................................... 45
5.9.- Exemplos .............................................................................................................................. 46
5.9.1. Exemplo Propriedades ................................................................................................... 46
5.9.2.- Exemplo Representação dos Atributos ......................................................................... 46
5.9.3.- Exemplo Diagrama de Entidade-Associação ................................................................. 47
6.- Definição detalhada de dados..................................................................................................... 47
6.1.- Nome e descrição de dados ................................................................................................. 48
6.1.1.- Regras para Nomes de Tabelas: .................................................................................... 48
6.2.- Campos chave ...................................................................................................................... 48
6.2.1.- Chave primária .............................................................................................................. 49
6.2.2.- Regras de Integridade numa Base de Dados ................................................................ 49
6.3.- Simplificação das tabelas através de normalização ............................................................. 49
6.3.1.- Primeira Forma Normal (1FN) ....................................................................................... 51
6.3.2.- Segunda Forma Normal (2FN)....................................................................................... 52
6.3.3.- Terceira Forma Normal (3FN) ....................................................................................... 53
6.3.4.- Outras Formas Normais (BCFN; 4FN; 5FN) ................................................................... 54
6.4.- Tabelas de descrição de códigos ...................................................................................... 55
6.4.1.- Registos ......................................................................................................................... 56
6.5.- Modelos de dados ................................................................................................................ 57
7.- Modelos ...................................................................................................................................... 57
7.1.- Tipos de Modelos ................................................................................................................. 57
7.2.- Modelos Físicos .................................................................................................................... 58
7.2.1.- Modelo Relacional ........................................................................................................ 58
7.2.2.- Modelos Hierárquicos & Rede ...................................................................................... 59
7.2.3.- Modelo Hierárquico ...................................................................................................... 60
7.2.4.- Modelo em Rede ........................................................................................................... 60
7.3.- Modelos Lógicos................................................................................................................... 61
7.3.1.- Entidade-Associação ..................................................................................................... 62
7.3.2.- Modelos Semânticos ..................................................................................................... 63
8.- Organização de Ficheiros vs Bases de Dados .............................................................................. 64
8.1.- Organização de Ficheiros e modo de acesso ....................................................................... 64
8.1.1.- Distinção entre Dados e Informação ............................................................................ 64
8.1.2.- Base de Dados, Sistema de Base de Dados e Sistema de Gestão de Base de Dados.... 65
8.1.3.- Evolução - Do processamento básico às Gestão da Base de Dados ............................. 65
8.1.4.- Arquitetura de um Sistema de Gestão de Base de Dados (SGDB) ................................ 66
5
8.1.5.- Características de Sistema de Gestão de Base de Dados (SGBD) ................................. 67
8.1.6.- Relação entre ficheiros e bases de dados ..................................................................... 68
8.1.7.- Sistemas de Ficheiros vs Sistemas de Bases de Dados ................................................. 69
8.1.8.- Vantagens das Bases de Dados ..................................................................................... 69
8.1.9.- Objectivos das Bases de Dados ..................................................................................... 70
8.1.10.- Limitações dos Ficheiros ............................................................................................. 70
9.- Ambiente de acesso a bases de dados........................................................................................ 70
9.1.- Independência dos Dados .................................................................................................... 70
9.2.- Inter-relação entre Dados .................................................................................................... 71
9.3.- Partilha na utilização dos Dados .......................................................................................... 71
9.4.- Integridade dos Dados ......................................................................................................... 71
9.4.1.- Controlo de Acesso - Segurança ................................................................................... 71
9.4.2.- Controlo de Acesso - Integridade ................................................................................. 71
9.5.- Redundância da Informação - Tolerância a Falhas .............................................................. 72
10.- Bibliografia ................................................................................................................................ 72
Vítor Ferreira
0.- Introdução
0.1.- Objectivo
Reconhecer e utilizar as diferentes
metodologias de análise de sistemas de
informação, no âmbito do processo de
informatização de uma organização.
0.2.- Conteúdos Programáticos

1.- Análise de sistemas – conceitos gerais 6.3.- Simplificação das tabelas através de
1.1.- Definição normalização
1.2.- Classificação 6.4.- Tabelas de descrição de códigos
1.3.- Objectivos 6.5.- Modelos de dados
2.- Metodologias de análise de sistemas 7.- Modelos Físicos

2.1.- Classificação 7.1.- Relacional
2.2.- Objectivos 7.2.- Rede
7.3.- Hierárquico
3.- Ferramentas de análise estruturada
3.1.- Diagrama de fluxo de dados (DFD) 8.- Modelos Lógicos
3.2.- Diagrama de contexto 8.1.- Entidade-Associação
8.2.- Semântico 6
4.- Dicionário de dados
4.1.- Utilidade e regras de definição 9.- Organização de ficheiros versus bases de
4.2.- Relação com o DFD dados
9.1.- Org. de ficheiros e modo de acesso
5.- Diagramas de Entidade-Associação (DEA) 9.2.- Rel. entre ficheiros e bases de dados
5.1.- Componentes dum DEA
10.- Ambiente de acesso a bases de dados
6.- Definição detalhada de dados 10.1.- Independência dos dados
6.1.- Nome e descrição de dados 10.2.- Inter-relação entre dados
6.2.- Campos chave 10.3.- Partilha na utilização dos dados
1.- Análise de Sistemas - Conceitos Gerais
1.1.- Definição
Um sistema de informação (SI) pode ser definido tecnicamente como um conjunto de
componentes inter-relacionados que colecionam (ou recuperam), processam, armazenam e
distribuem informações destinadas a apoiar a tomada de decisões, a coordenação e o controle de
uma organização.
Além de dar apoio à tomada de decisões, à coordenação e ao controle, os sistemas de
informação também auxiliam os gerentes e trabalhadores a analisar problemas, visualizar assuntos
complexos e criar novos produtos (Laudon & Laudon, 2011).
Os sistemas de informação contêm informações sobre pessoas, locais e itens significativos para
a organização ou para o ambiente que a cerca. No caso, informação quer dizer dados apresentados
em uma forma significativa e útil para os seres humanos.
Os Dados, ao contrário, são sequências de factos ainda não analisados, representativos de

eventos que ocorrem nas organizações ou no ambiente físico, antes de terem sido organizados e
arranjados de uma forma que as pessoas possam entendê-los e usá-los.
1.1.1.- As Diferenças - Dados vs Informação

As caixas dos supermercados registam milhões de dados, tais como códigos de barras que
descrevem cada produto. Esses dados podem ser somados e analisados, a fim de fornecer
informações significativas, como o número total de detergentes vendidos em determinada loja, as
marcas que são vendidas mais rapidamente ou a quantidade total gasta naquela loja ou ainda
vendas por região.
Vítor Ferreira
1.1.2.- As Diferenças – Conhecimento vs Sabedoria

Por Conhecimento entendemos a aplicação de padrões, que nos permitam compreender
causas, modelar o sistema, no fundo a informação trabalhada que nos leva a Sistemas Especialistas.
Por seu turno a Sabedoria, é a Optimização do Negócios, através das Tomadas de Decisões que
conferem de algum modo Vantagem Competitiva à organização, na medida em que soube ou
conseguiu Assimilar Competências.
1.1.3.- Conceitos Fundamentais em Sistemas
1.1.4.- Actividades no Sistema de Informação

Há três actividades num sistema de informação que geram as conclusões que as organizações
necessitam para tomar as decisões, controlar operações, analisar problemas e criar novos
produtos ou serviços.
- Entrada
- Processamento
- Saída
A entrada captura ou colecta os dados brutos de dentro da organização ou de seu ambiente
externo.
O processamento converte esses dados brutos em uma forma mais significativa.
A saída transfere as informações processadas às pessoas que as utilizarão ou às atividades nas quais
elas serão empregadas. Os sistemas de informação também requerem um feedback, que é uma
resposta à ação adotada a determinados membros da organização para ajudá-los a avaliar ou
corrigir o estágio de entrada
1.1.5.- Sistemas de Informação vs Sistemas de Informação Gerenciais

Para compreender totalmente os sistemas de informação, é necessário conhecer as suas dimensões
mais amplas - a organizacional, a humana e a tecnológica, bem como o seu poder de fornecer
soluções para os desafios e problemas no ambiente empresarial.
Chamamos essa compreensão mais ampla de sistemas de informação, que abrange um
entendimento das dimensões organizacional e humana dos sistemas, bem como de suas dimensões
técnicas, de capacitação em sistemas de informação.
1.1.6.- Dimensões do Sistema Informação
9 - Organização
A fim de entender como uma organização específica usa sistemas de informação, é necessário saber
algo sobre a estrutura, história e cultura da mesma. As organizações têm uma estrutura composta
por diferentes níveis e especializações. Essa estrutura revela uma clara divisão de trabalho. A
autoridade e a responsabilidade numa empresa são organizadas na forma de uma hierarquia, ou
uma estrutura piramidal, de responsabilidade e autoridade crescentes.
- Pessoas
Uma empresa é tão boa quanto as pessoas que a formam. O mesmo se aplica aos sistemas de
informação: eles são inúteis sem pessoas capacitadas para os desenvolver e manter e sem quem
saiba usar as informações de um sistema para atingir os objetivos organizacionais. Por exemplo, um
call center equipado com um avançado sistema de relacionamento com os clientes será inútil se os
funcionários não forem adequadamente treinados para lidar com pessoas, encontrar soluções para
os seus problemas e dar-lhes a sensação de que a empresa se importa com eles.
- Tecnologia
A tecnologia da informação é uma das muitas ferramentas que decisores utilizam para enfrentar
mudanças. Hardware é o equipamento físico usado para atividades de entrada, processamento e
saída de um sistema de informação. Consiste em computadores de vários tipos e formatos; diversos
Vítor Ferreira
dispositivos de entrada, saída e armazenagem; e os dispositivos de telecomunicação que interliga

todos esses elementos.
O software consiste em instruções detalhadas e pré-programadas que controlam e coordenam os

componentes do hardware de um sistema de informação. A tecnologia de armazenamento de
dados o softwares que comanda a organização de dados em meios físicos de armazenamento.
A tecnologia de comunicações e de redes, composta por dispositivos físicos e softwares, interliga
os diversos equipamentos de computação e transfere dados de uma localização física para outra.
Internet (Intranet; Extranet); A World Wide Web é um serviço proporcionado pela Internet que
usa padrões universalmente aceitos para armazenar, recuperar, formatar e mostrar informações
no formato de uma página da Internet.
1.2.- Classificação
Os sistemas, do ponto de vista empresarial, podem ser classificados de acordo com a sua forma
de utilização e o tipo de retorno dado ao processo de tomada de decisões.
Os sistemas podem ser de contexto operacional ou Gerencial, ou seja, Sistemas de Apoio às
Operações e Sistema de Apoio Gerencial.
10
Os sistemas de informação podem ser classificados de diferentes formas consoante:

- Número de indivíduos que os usam (tipo de utilização): Individuais ou pessoais, grupos de
trabalho, organizacionais, inter−organizacionais;
- Funções ou actividades que apoiam: Marketing, finanças, contabilidade, produção e serviços,
logística, engenharia, entre outras;
- Nível de decisão: Operacionais, tácticos, estratégicos;
1.2.1.- Sistema de Apoio às Operações
Os Sistemas de Apoio às Operações de uma empresa
têm por principais metas processar transações, controlar
processos industriais e actualizar as bases de dados,
fornecendo informações de âmbito interno e externo.
Apesar da sua importância para o desenvolvimento
normal das atividades da empresa, não consegue
desenvolver informações específicas, necessitando do
apoio do sistema de informação gerencial.
Entre os vários tipos de sistemas de apoio operacional, podemos ter: Sistemas de
Processamento de Transacções (SPT), Sistemas de Controle de Processos (SCP) e Sistemas
Colaborativos (SC).
Os Sistemas de Processamento de Transacções (SPT) dedicam-se ao processamento de
transações, os Sistemas de Controle de Processos (SCP) ao controle dos processos industriais e os
Sistemas Colaborativos (SC) à gestão da colaboração entre equipas e grupos de trabalho.
1.2.2.- Sistemas de Apoio Gerencial

Quando se fala em fornecer informações para a
11
tomada de decisão, toda a empresa deve estar
envolvida nesse processo. A complexa relação entre
os diversos decisores de uma organização deve ser
facilitada pelos sistemas de apoio gerencial.
Quando os sistemas de informação se concentram
em fornecer informação e apoio à tomada de decisão
eficaz pelos gerentes, eles são chamados sistemas de apoio gerencial.
Entre os vários tipos de sistemas de apoio gerencial, podemos ter: Sistema de Suporte da
Decisão (SSD), Sistema de Suporte Executivo (SSE) e Sistema de Informação Gerencial (SIG).
Os Sistemas de Informação Gerencial (SIG) produzem os relatórios padroni zados para Gerentes,
sendo que os Sistemas de Apoio à Decisão (SAD), são aqueles que dão apoio Interactivo à decisão
por parte dos administradores, e por último os Sistema Informação Executiva (SIE), responsáveis
pela elaboração e manipulação da Informação especificamente destinadas aos Executivos.
Vítor Ferreira
1.2.3.- Sistemas Transacionais (ST)

Refere-se às Transações, ou seja, a qualquer troca de valor ou movimento de mercadorias que
afete a lucratividade de uma organização ou seu ganho global, inclusive a realização de metas
12
organizacionais.
As suas principais Características são a recolha de dados através de mecanismos de entrada; a
Realização de cálculos; o Armazenamento de informações e ordenação dos dados, facilitando o
acesso a eles; O facto de permitir consultas dos dados, em diversas formatações;
a Produção de documentos e relatórios operacionais.
Tem como principais Objetivos:

- Processar dados gerados por e sobre as transações: é capturar, processar e armazenar transações
e produzir documentos relacionados as atividades comerciais rotineiras
- Manter um alto grau de precisão e confiabilidade: qualquer ST é a entrada e o processamento de
dados sem erros. Alto potencial de problemas relacionados com a segurança.
- Assegurar a integridade dos dados e da informação: assegurar que todos os dados e informações
armazenados na base de dados estejam exatos, actuais e apropriados.
- Produzir documentos e relatórios em tempo: uma das grandes vantagens de um ST
computadorizado sobre um ST manual (uso da Tecnologia).
- Aumento da eficiência do trabalho: redução substancial das exigências de trabalho de
funcionários e outros.
- Auxiliar no fornecimento de mais e melhores serviços: tanto grandes como pequenas empresas
percebem cada vez mais a importância de prestação de serviços superiores aos seus clientes.
Exemplos:
Pagamento de empregados, envio de faturas a clientes, preenchimento de formulários de gestão
(fins lucrativos); recebimento de doações, financiamento pesquisas (s/fins lucrativos).
São o coração da maior parte das organizações empresariais, pois dão apoio à monitorização e à
realização das negociações, armazenando os dados sobre as mesmas.
1.2.4.- Sistema de Informações Gerenciais (SIG)

O sistema de informações gerenciais é um conjunto organizado de pessoas, procedimentos,
base de dados e dispositivos que fornecem aos administradores e tomadores de decisões as
informações para ajudá-los a atingirem suas metas.
O Sistema de Informações Gerenciais é uma coleção integrada de subsistemas normalmente
organizados em linhas funcionais dentro da organização
Também são conhecidos como Management Information Systems (MIS) ou Sistemas de
Informações Gerenciais (SIG), que nada mais são do que sistemas que forneçam informações
integradas provenientes de diversos sistemas transacionais.
13
As suas principais Características são:
- Gerar relatórios de saída com formatos fixos e programados; produzem relatórios impressos e em
ecrãs de computador, usando os dados internos armazenados no sistema;
- Necessitar de solicitações formais do utilizador;
Tem como principais Objetivos:

- Tratar os dados armazenados pelos Sistemas Transacionais (os dados de entrada) sendo que os
dados obtidos dessas fontes são processados em informações mais úteis para os administradores
e apresentados através de relatórios pré-determinados.
As Saídas podem ser:
- Relatórios Programados: produzidos periodicamente ou de forma programada, diária,
semanal, mensal.
- Relatórios sob Solicitação: desenvolvidos para dar certas informações a pedido de um
administrador.
- Relatórios de Excepção: são produzidos automaticamente quando uma situação é incomum
ou requer uma atitude de um administrador
Vítor Ferreira
Exemplos:
Um relatório industrial produzido uma vez por dia para monitorizar a produção de um novo
produto; Horas trabalhadas por um empregado em especial; Produtos com menos de 50 peças em
stock, funcionários que tiveram horas extras na semana;
1.2.5.- Sistema de Apoio à Decisão (SAD)

Os Sistemas de Apoio à Decisão são sistemas que não só fornecem informação para apoio à
tomada de decisões, mas que ajudam no processo de tomada de decisão, através da análise das
informações e de tendências, podendo ter funções específicas que fazem parte do ambiente de
apoio à decisão. Também conhecido como “Decision Support Systems (DDS). Tratam de assuntos
específicos, estatísticas, projeções, comparações de dados referentes ao desempenho da empresa.
O propósito é apoiar vários processos decisórios em diversos níveis gerenciais, pelo que a
integração é necessária.
As suas principais características são:

- Utilizados para resolução de problemas mais complexos e menos estruturados;
- Tentam combinar modelos ou técnicas analíticas com as funções tradicionais de processamento
de dados, como acesso e a recuperação de informações;
- Devem ser interativos, fáceis de usar e ter interface extremamente amigável; Os sistemas de apoio 14
à decisão devem acompanhar as tendências, sendo mais flexíveis e adaptáveis a mudanças;

- Devem fornecer contributos para um rápido encaminhamento e implementação dos resultados
obtidos a partir da tomada de decisão;
- O suporte à decisão é necessário em todos os níveis de gerenciamento da empresa.
É preciso ter presente que a principal consequência da integração de sistemas é a

descentralização da informação, que fluindo por toda a empresa, permite alcançar quem precisar
dela, na hora em que for precisa.
Como Objectivos e Factores de Necessidade podemos apontar:

- A Competitividade entre as empresas;
- A Necessidade de informações rápidas;
- ADisponibilidade de recursos tecnológicos;
- O facto de Oferecer vários recursos computacionais;
- A Possibilidade de armazenar o conhecimento de especialistas em bases de conhecimento.
Exemplos
Um exemplo pode ser um Sistema Transacional de cobranças que envia contas mensais aos clientes;
Um Sistema de Informações Gerenciais de cobranças que produz para a organização relatórios
semanais sobre contas vencidas; Um Sistema de Apoio à Decisão de cobranças que executa análises
e simulações para determinar o impacto dos pagamentos atrasados no fluxo de caixas, na
facturação e/ou nos níveis de lucro global;
1.2.6.- Sistemas de Informação Executivo (SIE)

Também chamados de Executive Information Sistem (EIS), este sistema é destinado ao nível de
Gerentes Seniores, que também auxilia os executivos na tomada de decisões, no controle dos
fatores críticos de sucesso e do progresso da organização.
Para que as organizações continuem competitivas, as informações são necessárias para apoiar
decisões e, através dos Sistemas de Informação Executiva, grandes quantidades de informação são
apresentadas aos executivos de forma compacta e maneável.
Tem como principal Objectivo:

- Prover informações de forma acessível e em formato interactivo, sem forçar os executivos à
especialização em análise e modelação de dados.
As suas principais características são

15 - Fornecer informações do passado, presente e tendências futuras; Permite análise profunda das
informações;
- Dar suporte a todos os aspectos de tomada de decisões;
- Oferecem vários recursos computacionais, permitindo a Comunicação com o mundo interno e
externo que se adaptem ao seu estilo;
- Permitem adequação à cultura da empresa e ao seu modo de tomar as decisão;
- Proporcionam um acesso rápido às informações correntes;
Esta divisão e classificação dos Sistema de Informação não é única e podem ser encontradas
outras classificações similares. Recapitulando no prisma organizacional, os sistemas de informação
podem classificar-se de diversas formas:
-Sistemas de Informação Operacional ou de Processamento de Transações: estes gerem a
informação referente às transações que têm lugar numa empresa;
-Sistemas de Informação de Gestão: permitem solucionar problemas empresariais em
geral;
-Sistemas de Informação Estratégicos ou de Apoio à Decisão: analisam as variáveis de
negócio que permitem a tomada de decisões;
-Sistemas de Informação Executiva: para diretores, gerentes e administradores;
Vítor Ferreira
-Sistemas de Automatização de Escritórios: aplicações que ajudam no trabalho

administrativo;
-Sistemas Especializados: estimulam o comportamento de um especialista numa área
concreta.
“Um sistema de informação é o conjunto de hardware e software, procedimentos, documentação,

formas, e pessoas responsáveis pela captura, movimento, gestão e distribuição de dados e
16
informação” (Martin et al. 1994 in Fernandes, 2005).
1.3.- Objetivos organizacionais dos Sistemas de Informação
- Excelência Operacional
As empresas estão sempre a tentar melhorar a sua eficiência de suas operações a fim de conseguir
mais lucratividade. Das ferramentas de que os administradores dispõem, as tecnologias e os
sistemas de informação estão entre as mais importantes para atingir altos níveis de eficiência e
produtividade nas operações, especialmente quando combinadas com mudanças no
comportamento da administração e nas práticas de negócio.
- Novos Produtos Serviços e Modelos de Negócio

As tecnologias e os sistemas de informação são a principal ferramenta de que as empresas dispõem
para criar novos produtos e serviços, assim como modelos de negócio inteiramente novos. Um
modelo de negócio descreve como a empresa produz, entrega e vende um produto ou serviço a fim
de criar valor.
- Relacionamentos mais estreitos com Cliente e Fornecedores
Quando uma empresa conhece de verdade seus clientes e os atende bem, da forma que eles
querem ser atendidos, a reação típica deles é voltar a essas empresas e comprar mais. Isso aumenta
as receitas e os lucros. O mesmo se aplica aos fornecedores: quanto mais os fornecedores de uma
empresa estiverem envolvidos com ela, mais poderão lhe fornecer insumos vitais. Isso reduzirá os
custos. Mas como empresas com milhões de consumidores on-line e offline podem conhecer de
verdade seus clientes e fornecedores?
- Melhor Tomada de Decisões

Muitos administradores trabalham às cegas, sem nunca poder contar com a informação certa na
hora certa para tomar uma decisão abalizada. Também há aqueles administradores que se apoiam
em previsões, palpites ou na sorte. O resultado é a produção insuficiente ou excessiva de bens e
serviços, a má alocação de recursos e tempos de resposta ineficientes. Essas deficiências elevam os
custos e geram perda de clientes. Nos ultimas dez anos, as tecnologias e os sistemas de informação
têm permitido que, ao tomar uma decisão, os administradores façam uso de dados em tempo real,
oriundos do próprio mercado.
- Vantagem Competitiva
Se uma empresa atingir um ou mais dos objetivos organizacionais tratados até aqui excelência
operacional; novos produtos, serviços e n1odelos de negócio; relacionamento mais estreito com
consumidores e fornecedores; e melhor tomada de decisão-, provavelmente já terá conseguido
17 certa vantagem competitiva. E, se fizer essas coisas melhor que seus concorrentes, gastando menos
para obter produtos superiores e respondendo a clientes e fornecedores em tempo real, aumentará
as vendas e os lucros até um nível que os concorrentes não conseguirão igualar.
- Sobrevivência
Outro motivo para as empresas investirem em sistemas e tecnologias de informação está no filtro
de que eles se tornaram imprescindíveis à prática de negócios. Muitas vezes, essa
imprescindibilidade é foi determinada por mudanças no sector.
Uma série de regulamentações europeias, nacionais e locais obrigam as empresas e seus
funcionários a manter determinados registros, inclusive registros digitais.
Em jeito de conclusão um Sistema de Informação (SI) tem como objetivos centrais:

- Fornecer dados organizados, permitindo ajudar quem manipula o sistema, de forma rápida e com
um mínimo de risco possível;
Vítor Ferreira
- Ajudar a empresa a reduzir custos, a aumentar a

oferta, a melhorar a satisfação dos seus clientes e a
qualidade dos seus serviços.
Um bom Sistema de Informação pode inclusive ter

um papel determinante na expansão da empresa,
uma vez que é uma excelente forma de detetar
nichos de mercado.
1.4.- Em resumo
1.4.1.- Análise de Sistema de Informação
A análise de sistemas é um processo de estudo de uma organização (na sua totalidade ou em
parte), em que se procura realizar o levantamento exaustivo de como funciona e desta forma
descrever os processos de resolução seguidos para suas necessidades (que garantam o atingir do(s)
objectivo(s) da organização).
Define-se análise de sistemas como uma técnica de resolução de problemas que decompõe um
sistema nos seus componentes, de forma a perceber como estes trabalham e interagem entre si,
18
permitindo atingir o seu propósito.
Pode ser compreendida como o processo de classificação e interpretação de factos, que
permitem identificar problemas, utilizando a informação recolhida, de forma a recomendar
melhorias no sistema ou suportar o desenvolvimento de um novo sistema.
A análise de sistemas de informação é definida como a fase de desenvolvimento, num projeto
que se destaca numa primeira etapa no problema apresentado, independentemente da tecnologia
que irá ser utilizada na implementação da sua solução. A análise de sistemas de informação procura
perceber como estes funcionam para verificar se são necessárias melhorias.
Os principais objectivos da análise de sistemas são:

- conhecer os objectivos do sistema;
- decompô-lo em componentes;
- conhecer os componentes e as relações entre si;
- diagnosticar problemas;
- juntar as partes de forma a determinar o seu funcionamento geral;
A análise de sistemas obriga, em primeiro lugar, ao estudo dos requisitos de informação e dos
utilizadores finais. Mas uma perceção adequada das necessidades das organizações requer
igualmente o estudo das atividades, dos recursos e dos sistemas de informação existentes, de
forma a identificar o que é ou não pertinente para as organizações.
1.4.2.- Papel do Analista de Sistema de Informação

Os profissionais responsáveis por esta conjunto de tarefas são designados de Analistas de
Sistemas.
O papel do Analista de Sistemas passa pelo:

-Desenvolvimento dos Sistemas de Informação.
-Diálogo com gestores e outros profissionais das empresas, interpretando as suas especificações.
-Efectuar investigações preliminares: colher, registar dados, determinar objectivos.
-Desenvolver protótipos, o projecto do sistema, o desenvolvimento do software, o teste do sistema
e efectuar a sua implementação.
O Analista de Sistemas deve fazer reuniões regulares com os utilizadores (clientes/proprietários).

O ideal seria ter utilizadores dedicados integralmente ao projecto. Alguns defendem que os
próprios utilizadores deveriam fazer o projecto.
19 Classificação por tipo de função do Analista de Sistema:

- Operativos: têm visão local, isto é, não conhecem o processo de forma global. São responsáveis
por executar as funções do sistema. Têm uma visão física do sistema, ou seja, imaginam o
funcionamento do sistema considerando a tecnologia de implementação.
- Supervisores: podem ou não ter uma visão local. Geralmente conhecem as operações pois muitos
já foram utilizadores operativos. Além disso, têm que supervisionar os utilizadores operativos. São
orientados por considerações orçamentais (reduzir o quadro de funcionários ou aproveitá-los
melhor)
- Executivos: não têm experiência operativa. Têm a iniciativa do projecto e possuem uma visão
global. Têm preocupações estratégicas e são capazes de lidar com modelos abstractos
Outras Funções do Analista de Sistema:

- Gestor do projecto: as principais funções de uma gestão de projecto são - Gerir e alocar recursos
de toda a equipa técnica - Prestar contas junto da administração superior - Encaminhar problemas
identificados no decorrer do projecto
- Auditores, Controlo de qualidade e normalização: responsáveis por garantir que o sistema seja
desenvolvido de acordo com os vários padrões interno e externos da organização, especialmente
aqueles focados na segurança e no controlo de qualidade do produto final.
Vítor Ferreira
O Analista de Sistemas desempenha as seguintes funções:

- Arqueólogo e Escriba: deve trazer à luz os detalhes e documentar as actividades cujos detalhes
passam de geração em geração de utilizadores.
- Inovador: não se limitar apenas a implementar as funções actuais do sistema, mas ajudar a
encontrar produtos e mercados novos.
- Mediador: como os utilizadores dificilmente chegam a um consenso, o analista deve usar a arte
da diplomacia e da negociação. O sistema deve ser feito da forma como os utilizadores solicitaram.
- Líder de projecto: como o analista entrou antes no projecto, frequentemente também é o
projectista e normalmente é uma pessoa mais experiente, existe uma tendência natural que ele
assuma o papel de gestor de projecto.
Outras Funções e Características

- Projectista de sistemas: tem a função de transformar os requisitos dos utilizadores, modelados
pelos analistas de sistemas, num projecto implementável em computador. Normalmente o analista
e o projectista são a mesma pessoa, ou membros do mesmo grupo de pessoas. O analista de
sistemas deve fornecer informações suficientemente detalhadas para que o projectista elabore um
projecto tecnologicamente forte e o projectista deve fornecer informações suficientes para que o
analista possa dizer se os requisitos dos utilizadores podem ser completamente atendidos ou 20
devem ser modificados.
- Programador: responsável por codificar e testar (usando uma linguagem de programação) os

módulos dos sistemas modelados pelos projectistas. Num cenário ideal, o programador não deveria
ter contacto com o analista já que se baseia apenas no trabalho feito pelo projectista. Há
programadores que são responsáveis apenas por realizar a manutenção de um sistema.
- Operador: é a pessoa encarregada de operar os computadores, da rede, da segurança do

hardware e das bases de dados, da execução dos programas e da saída das impressoras.
Principais Problemas no desenvolvimento de sistemas:

- Produtividade;
- Confiabilidade;
- Manutenibilidade;
2.- Metodologias de Análise de Sistemas
2.1./2.2- Classificação e Objectivos
A análise de sistemas teve a sua origem em 1940, aquando da criação de uma organização
americana sem fins lucrativos, a RAND Corporation, de forma a encontrar soluções para problemas
de planeamento de operações militares.
O sucesso desse projeto na Segunda Guerra Mundial estimulou o desenvolvimento da Pesquisa
Operacional (PO). A forma de abordagem na solução de problemas dessa natureza deu à pesquisa
operacional o status de um processo científico.
No período pós-guerra, alguns trabalhos de consultoria prestados pela RAND, fizeram com que
surgisse uma área, considerada por muitos, similar à pesquisa operacional: a análise de sistemas.
Após 1948, a ênfase das pesquisas conduzidas pela RAND focava-se na análise de custos e no
planeamento operacional, tático e estratégico. Fazer avaliações de alternativas de negócios em
termos de lucro e gastos era o objetivo da empresa. A RAND Corporation dispunha de uma
metodologia para conduzir os seus projetos de pesquisa.
Considerada uma das primeiras metodologias de análise de sistemas, ela era descrita pelos
21
seguintes passos:
1) identificar os objetivos a serem alcançados;
2) procurar técnicas alternativas, pelas quais, os objetivos pudessem ser alcançados;
3) identificar os custos e os recursos necessários a cada alternativa;
4) desenvolver um ou vários modelos matemáticos, mostrando a interdependência dos objetivos,
recursos, ambiente, técnicas e instrumentos;
5) definir critérios, relacionando objetivos, custos e recursos, para a escolha de uma alternativa
preferencial.
No desenvolvimento de sistemas, podemos seguir

várias metodologias para cumprirmos com o ciclo de
desenvolvimento de software.
Algumas dessas metodologias são:

- Metodologia de Desenho Estruturado de Yourdon
- Metodologia de Desenho de Jackson
- Metodologia de Desenho de Warnier-Orr
Vítor Ferreira
- Engenharia de Informação
2.(1/2).1.- Metodologia de Desenho Estruturado de Yourdon

A metodologia estruturada moderna (Yourdon, 1989) era originariamente caracterizada pela
utilização de duas técnicas de modelagem gráficas: diagramas de fluxo de dados e diagramas
estruturais, que enfatizavam as funções executadas pelo sistema.
Posteriormente foram adicionados a esta metodologia o dicionário de dados e especificações
de processos.
Recentemente, na Metodologia de Yourdon, também conhecida como YSM - Yourdon Systems
Method foram incorporadas os diagramas entidade-associação e diagramas de transição de
estado para ajudar o engenheiro de software a modelar os dados e o comportamento dependente
de tempo de um sistema.
A ferramenta básica dessas metodologias é o Diagrama de Fluxo de Dados (DFD). Embora essa
forma de representação seja extraordinariamente mais simples e compreensível do que a descrição
de processos em linguagem natural, ela ainda tem muitas limitações. Por exemplo, não há como
representar alinhamentos lógicos ou informações de controlo. Apesar do nome da ferramenta estar
relacionado a dados, na verdade a ênfase está nos processos. Também não há regras claras de até
onde detalhar o diagramas de fluxo de dados. Dependendo da experiência do programador e do
22
seu conhecimento do problema, essas especificações podem ser insuficientes e em outros casos,
excessivas.
É uma composição de estratégias de desenho, objectivos de avaliação e técnicas de
documentação gráfica. O desenho estruturado é um refinamento do método de desenho top-
down. Este método não é nem um puro top-down nem bottom-up mas chamado de middle-out. O
analista começa desenhando um diagrama de contexto de alto-nível que indica as fronteiras do
sistema.
Para além disso, adiciona guias de desenho para sistematizar o processo de desenho e para
medir a qualidade do desenho.
A metodologia Yourdon cobre tanto as atividades da organização como os requerimentos do
sistema. A Ênfase é colocada na modelagem de ambos: organização e sistema.
2.(1/2).2.- Metodologia de Desenho de Jackson

Esta metodologia é também um refinamento do método de desenho top-down. A maior
diferença com a anterior, é que esta é a técnica de desenho conduzida pelos dados, ao passo que a
anterior é conduzida pelos processos.
Esta metodologia começa com o desenho das estruturas de dados, derivando daqui a estrutura
do programa. Assume que o problema foi plenamente especificado e a análise do sistema e a
implementação, caem fora do processo de desenho.
Para Jackson, o processo de desenho consiste em quatro passos sequenciais: Dados; Programa;
Operações; Texto;
Dados - Descreve cada input como uma estrutura hierárquica.

Programa - Combina todas as estruturas de dados produzidas no passo anterior, num programa
com uma estrutura hierárquica.
Operações - Executa uma lista de operações, necessárias para produzir outputs a partir de inputs.
Texto - Transcreve a estrutura do programa em texto estruturado, adicionando a lógica condicional
que gere a execução de ciclos e a selecção de estruturas.
Em vez da decomposição funcional, ou da abstração de procedimentos, que são características

predominantes das técnicas estruturadas, as metodologias orientadas a objetos enfatizam a
abstração de dados.
23 Desta abstração decorre o conceito de objeto que, segundo Shlaer e Mellor (1990), é uma abstração
de um conjunto de coisas do mundo real, de forma que:
a) Todas as coisas do mundo real deste conjunto - as instâncias - tenham as mesmas características;
b) Todas as instâncias estejam sujeitas, e em conformidade com, as mesmas normas.
Porque é orientada a objectos eles podem-se enquadrar dentro de uma das cinco categorias
seguintes:
- Coisas tangíveis (avião, veículo, livro, etc);
- Funções (médico, paciente, cliente, etc);
- Interações (compra, casamento, etc)
-Incidentes (vôo, acidente, evento, etc);
-Especificações ( modelo 172, etc).
Usa três diagramas para descrever o desenho do programa:

Diagramas de Fluxos de Dados - que representa os fluxos de dados entre programas
Árvores de Decisão - representação hierárquica do programa e das estruturas de dados
Linguagem estruturada - Pseudocódigo
Vítor Ferreira
Não é directamente aplicável à maior parte dos problemas do mundo real, porque: -Assume a
existência de uma especificação correcta e completa; -O processo de desenho é limitado a
programas simples.
O ponto mais forte da metodologia de Jackson seja a sua orientação para a estrutura de dados.
Na maior parte dos projectos, os processos são razoavelmente simples, enquanto as estruturas de
dados podem ser muito mais complexas. Por outro lado, Jackson não dá importância ao projecto
da lógica de controlo, desde que seja imposta pelas estruturas de dados. Orienta sua metodologia
para programas simples (ou programas complexos decompostos até que possa ser vista como um
programa simples). Também pressupõe que existe previamente um certo nível de especificação, o
que nem sempre é verdade. Além disso a metodologia está mais voltada para uma visão hierárquica
das estruturas de dados, nem sempre real (e cada vez menos comum nos sistemas on-line,
baseados em bancos de dados).
2.(1/2).3.- Metodologia de Desenho de Warnier-Orr

Esta metodologia é também um método top-down conduzida pelos dados, no entanto o seu
enfoque é no output do sistema. Este enfoque determina a estrutura dos dados, e a estrutura do
programa.
24
Passos Essenciais na Metodologia de Desenho de Warnier-Orr
1- Definição dos processos de output.
2- Definição da base de dados lógica: são definidos todos os elementos necessários para produzir
o output do programa.
3- Análise dos eventos: são definidos todos os eventos que podem afectar os dados na base de
dados física.
4- Desenvolvimento da base de dados física.
5- Desenho do processo da lógica dos processos.
6- Desenho do processo físico: adiciona a lógica de controlo e os procedimentos para completar o
desenho do programa.
A metodologia Warnier-Orr é bastante inovadora em relação às demais, tendo sua base na lógica
de conjuntos da matemática. Ela parte da especificação das saídas do sistema, para deduzir
processos e dados de entrada, e seu diagrama, que separa adequadamente aspectos lógicos e
físicos do sistema. Entretanto, como esse diagrama se estende do geral para o particular de uma
forma praticamente linear (da direita para a esquerda), fica realmente difícil representar sistemas
de algum porte. Nesse caso o diagrama pode ocupar várias folhas, difíceis de serem visualizadas em
conjunto. Mas a principal limitação dessa metodologia é a sua inadequação para representar
estruturas de dados que não sejam hierárquicas, como as de vários dos actuais sistemas de bancos
de dados. Outra questão é a extrema orientação para as saídas do sistema. Isso provavelmente
favorece a construção de sistemas voltados para a emissão de relatórios ou consultas, mas parece
inadequado para sistemas mais complexos.
2.(1/2).4.- Engenharia de Informação

A aplicação de um conjunto interligado de técnicas formais de planeamento, análise, projeto e
construção de um sistema sobre uma organização como um todo ou em um dos seus principais
setores.
Assenta em modelos de dados perfeitamente normalizados, guardados em formas
computorizadas (mainframes) e as estações de trabalho usam ferramentas computorizadas para
25
construir aplicações que utilizam os dados. É um conjunto de metodologias desenhada para criar e
operar num ambiente corporativo de uma empresa.
-Consiste num conjunto de ferramentas totalmente integradas que permitem capturar as
necessidades de informação ao nível da abstração mais elevada, e transformá-las com êxito em
aplicações executáveis por meio de uma tecnologia.
Martin (1991) definiu engenharia da informação como "o conjunto interligado de técnicas
automatizadas no qual são construídos modelos de organização, modelos de dados e modelos de
processos em uma abrangente base de conhecimentos, a fim de serem usados para criarem e
manterem sistemas de informação".
São características básicas desta classe de metodologia:

-Buscar identificar as formas como a informação pode melhorar o alcance dos objetivos
estratégicos da organização;
-Buscar, no desenvolvimento de sistemas de informação, trabalhar na direção de cima para baixo
(top-down), através das seguintes etapas:
a) Planeamento dos sistemas estratégicos da organização;
b) Análise da área de negócio;
Vítor Ferreira
c) Projeto do sistema;
e) Construção;
c) Corte;
Resumo dos benefícios da Engenharia da Informação:

- Identificação das oportunidades de sistemas estratégicos para atingir posição favorável no
mercado, construindo estes sistemas antes da concorrência.
- Focalização do processamento de dados nos objetivos da empresa.
- A organização passa a funcionar como uma unidade, os mesmos dados estão representados da
mesma forma em sistemas diferentes, que interagem quando necessário.
- As informações são controladas de tal forma, que os responsáveis pela tomada de decisão as tem
disponíveis na sua melhor forma.
- Novos sistemas podem ser construídos com relativa rapidez.
- Possibilidade de modificar procedimentos computadorizados rapidamente.
- Facilita a construção de sistemas de maior complexidade e a compreensão e controle dos vínculos
complexos entre os sistemas.
- Permite a evolução a longo prazo dos sistemas, à medida que os sistemas crescem.
- Possibilita economia através do uso de projetos e programas re-aproveitáveis. 26
3.- Ferramentas de análise estruturada
3.1.- Diagrama de fluxo de dados (DFD)
É uma descrição gráfica de
um sistema de informação ou de
uma parte deste. Consistem na
representação do fluxo de dados,
dos processos, de origens e
destinos e dos arquivos de dados;
todos descritos através de
símbolos simples, obtendo-se
uma representação de fácil
percepção.
Proporcionam uma imagem
simples e inteligível dos processos
e dados que permitem o funcionamento da organização, facilitando a comunicação entre os
utilizadores e responsáveis pelas instituições com os analistas.
Prestam-se à descrição gráfica do sistema lógico de uma maneira compreensiva, especificando
27
concretamente o que o sistema faz e representam níveis sucessivos da hierarquia de funções e
processos.
3.1.2.- Vantagens Diagramas de fluxo de dados (DFD)

- Permitem fácil e rápida construção, actualização, modificação, leitura e compreensão dos modelos
influenciada pelo n.º limitado de símbolos;
- Fornecem uma visão detalhada das partes do sistema sem perder a sua visão global motivada pela
abordagem top-down;
- Permitem a gestão da complexidade devido à representação particionada do sistema;
- São bons instrumentos de comunicação devido, quer à representação gráfica, quer à
representação particionada do sistema;
- Apresentam uma baixa redundância;
- Focam a dinâmica (fluxos de dados) e a funcionalidade (processos) do sistema.
3.1.2.- Características Diagramas de fluxo de dados (DFD)

- Mostram a fronteira entre o (sub)sistema e o seu ambiente exterior;
- Mostram os processos relevantes e depósitos de dados do sistema;
- Mostram as entidades externas com as quais o sistema comunica;
Vítor Ferreira
- Mostram os fluxos de dados através do sistema e deste com o exterior.
3.1.3.- Desvantagens ou Limitações Diagramas de fluxo de dados (DFD)

-Não mostram as estruturas de dados;
- Não mostram as necessidades de acesso aos dados;
- Não mostram as tomadas de decisão;
- Não mostram os ciclos (loops) e cálculos;
- Não mostram os volumes de dados ou de informação.
Os Diagramas de fluxo de dados não mostram os aspectos acima referidos, mas não se pretende
que mostrem, pois isso anularia as suas próprias vantagens.
3.1.4.- Convenções a usar na construção de Diagrama de Fluxo de Dados

(DeMarco & Yourden vs Gane & Sarson)
Os Diagrama de Fluxo de Dados (DFD) são uma das ferramentas de análise de dados mais
utilizadas, devido à facilidade linguística e às poucas alternativas referentes aos símbolos. Estes
fatores tornam-no numa ferramenta fácil de utilizar, de elaborar, de ser lida e compreendida. O
DFD abrange quatro elementos gráficos: os processos, o fluxo de dados, os arquivos e a entidade
28
de origem/destino:
Fluxo de Dados: têm unicamente a função de recolha de dados num determinado ponto e
transmissão desses mesmos dados para um determinado output. É uma única parte de dados ou
conjunto lógico de informações (Ex. Factura). É graficamente representado por uma seta que entra
ou sai de um processo e é utilizado para mostrar o movimento de pacotes de informação de um
ponto a outro do sistema. O fluxo de dados representa dados em movimento. Cada fluxo de dados
tem de ter um nome apropriado e o mais preciso possível.
Processos: permitem transformar inputs provenientes de fluxos de dados, em determinados

outputs. É uma atividade ou uma função que é realizada por algum motivo específico, que pode ser
manual ou informatizado, sendo que em última análise, cada processo deve realizar apenas uma
atividade. Designa a parte do sistema que transforma entradas em saídas, ou seja, indica como uma
ou mais entradas são convertidas em saídas. A atribuição adequada dos nomes é muito importante,
uma vez que tem que refletir, de forma clara, a atividade que o processo engloba. O mesmo
processo pode ser desdobrado em vários (novos números serão incluídos).
Arquivos: são repositórios de dados, possivelmente temporários, nos quais os fluxos podem
depositar dados ou lê-los repetidamente sem os destruírem. Onde a recolha de dados é
armazenada permanentemente. Cada arquivo possui um nome exclusivo que se encontra no plural.
O arquivo contém um conjunto de informações que pode ser acedido e/ou atualizado por um
processo.
29
Entidades: pontos de origem ou de fim de fluxos de dados, exteriores ao sistema, acerca dos quais
só se sabe os protocolos a utilizar e a informação por eles descrita. Uma pessoa, organização ou
sistema que é externo ao sistema, mas interage com ele. São categorias lógicas de coisas ou pessoas
que representam a origem ou o destino para as transações. A identificação e definição das
entidades externas definirão as fronteiras ou limites do sistema. Mostram, respetivamente, de
onde o dado requerido pelo sistema vem e para onde o dado produzido pelo sistema vai. Uma
origem é um provedor de fluxo de dados para o sistema, e o destino é um recebedor de fluxo de
dados do sistema.
3.1.5.- Metodologia de elaboração Diagrama de fluxo de dados (DFD)

1- Identificar as Entidades externas
2- Identificar os processos
3- Produzir um primeiro Diagrama de fluxo de dados (DFD)
4- Verificar se os processos são coerentes com as entidades externas identificadas
5- Verificar como são recebidos e emitidos os dados, de forma a identificar os arquivos
6- Produzir um Diagrama de fluxo de dados (DFD) final
7- Passar ao nível inferior e detalhar
8- Rever tudo
Vítor Ferreira
3.1.6.- Diretrizes para a elaboração do diagrama de fluxo de dados (DFD):

- Escolher nomes significativos para os processos, fluxos, arquivos e entidades externas: deve ser
evitado o uso de nomes de pessoas ou grupos. Apenas deve estar rotulado o processo de modo a
identificar as funções que o sistema executa; 30
- Numerar os processos: método prático de referenciação de processos. O esquema de numeração
pode não implicar uma determinada sequência de execução, porque o DFD é uma rede de
processos assíncronos que comunicam entre si, dando uma representação do modo como funciona
a maioria dos sistemas;
- Refazer o Diagrama de fluxo de dados consecutivamente até obter uma boa estética: um projeto
de análise de sistemas, para que esteja tecnicamente correto, aceitável pelo utilizador e percetível
por todos, terá de ser feito e refeito até um estado de otimização;
- Evitar Diagrama de fluxo de dados demasiado complexos: deve-se modelar as funções que o
sistema executa e as interações entre elas, de modo a que ao ser lido seja compreendido, não só
pelo analista que o elaborou, mas também pelos utilizadores. Deve-se modelar em níveis, para que
cada nível ofereça sucessivamente mais detalhes;
- Estipular número máximo de objetos: um DFD não deve ter mais do que 7 (+/- 2) processos
(número de objetos que a mente humana é capaz de abarcar simultaneamente);
- Consistência do Diagrama de fluxo de dados: Certificar-se de que o DFD tenha consistência
interna. Além do relacionamento com outros modelos do sistema, existem algumas diretrizes
consideradas principais: evitar os processos que tenham entradas, mas que não tenham saída,
assim como, evitar processos que tenham saídas, mas que não tenham entradas;
- Identificar as componentes estáticas: Entidades externas; identificar os principais depósitos de
dados;
- Identificar os principais processos e fluxos de dados: identificar os fluxos que partem das fontes
e convergem para as entidades e ainda os principais processos que surgem nesses percursos. Deve-
se garantir que cada fluxo é rotulado e que o nome deste se refere a todos os dados transportados
pelo mesmo. Deve-se evitar nomes vagos.
-Convenções de expansão: um processo de nível superior pode ser expandido em novos processos
de nível inferior; Exemplo: 2 --------> 2.1 e 2.2
3.1.7.- Regras a ter em conta na construção de Diagrama de fluxo de dados (DFD)

A forma como estes elementos se conjugam deve respeitar determinadas regras:
ENTIDADES PROCESSOS ARQUIVOS
ENTIDADES NÃO SIM NÃO

PROCESSOS SIM SIM SIM
ARQUIVOS NÃO SIM NÃO
3.1.7.- Exemplos de Diagramas de Fluxo de Dados

Cada vez que um cliente emite um pedido, há sempre uma confirmação do pedido e é criada uma
31
factura. Neste caso, um evento pode causar mais do que uma resposta.
Sempre que um cliente efectue um pagamento com cheque ou com dinheiro, é emitido um
recibo. Neste caso, vários eventos podem dar origem à mesma resposta.
Vítor Ferreira
3.2.- Diagrama de Contexto

O Diagrama de Contexto é o diagrama de fluxo de dados de mais alto nível.
- Representa todo o sistema como um único processo
- É composto por fluxos de dados que mostram as interfaces entre o sistema e as entidades
externas.
- É uma forma de representar o projecto em causa e sua relação com o ambiente.
Um diagrama de contexto permite identificar os limites dos processos, as áreas envolvidas com
o processo e os relacionamentos com outros processos e elementos externos à empresa
32
(Exemplo: Clientes, Fornecedores).
Aponta as características do sistema:

- Organizações/sistemas/pessoas que comunicam com o sistema; - Dados que o sistema absorve e
deve processar; - Dados que o sistema gera para o ambiente; -Fronteira do sistema com o ambiente.
O Diagrama de Contexto representa todo o sistema como um único processo. É composto por
fluxos de dados que mostram as interfaces entre o sistema e as entidades externas.
O diagrama é uma forma de representar o objeto do estudo, o projeto, e sua relação com o
ambiente. Um diagrama de contexto permite identificar os limites dos processos, as áreas
envolvidas com o processo e os relacionamentos com outros processos e elementos externos à
empresa (ex.: clientes, fornecedores) demonstrando as caraterísticas do sistema, tais como:
- Organizações/sistemas/pessoas que se interrelacionam com o sistema;
- Dados que o sistema absorve e deve processar;
- Dados que o sistema gera para o ambiente;
- Fronteira do sistema com o ambiente.
Este é um exemplo de um processo “Encomendar Comida” (forma) representado através de um

Diagrama de Contexto. Ele mostra os participantes que irão interagir com o sistema, chamados de
Entidades Externas. Neste exemplo, Fornecedor, Cozinha, Gerente e Cliente são as entidades que
irão interagir com o sistema. Entre o processo e as entidades externas, existem dados de fluxo
(conectores) que indicam a existência de troca de informações entre as entidades e do sistema.
3.3.- Exemplo de Diagrama de Fluxo de Dados Nível 0
33
Vítor Ferreira
No exemplo temos Diagrama de Fluxo de Dados de “Encomendar Comida” (Food Order System)
que contém três Processos, quatro Entidades externas e dois Arquivos de dados.
Com base no diagrama, sabemos que um cliente pode fazer um pedido. O processo Encomendar
Comida recebe a Encomenda que encaminha para o Cozinha, a Encomenda é arquivada no Arquivo
Encomendas, actualizando o inventário no Arquivo Inventário. O processo também gerará uma
Factura para o Cliente.
O Gerente pode receber relatórios através do Processo Gerar Relatórios, este irá buscar os
detalhes (inputs) Arquivo Inventário e ao Arquivo Encomendas
O Gerente pode igualmente iniciar o Processo Encomendas de Inventário, dando uma ordem
Encomenda Inventário. O Processo encaminha a Encomenda Inventário ao Fornecedor e armazena
os detalhes de inventário atualizado no Arquivo Inventário.
Num Diagrama de fluxo de dados (DFD), concentramo-nos nas interacções entre o Sistema e as
Entidades Externas, em vez de ser nas Comunicações Internas entre interfaces. Portanto, os Fluxos
de Dados entre as interfaces e os Arquivos de Dados usados são considerados fora do escopo e não
deve ser mostrado no diagrama. É importante misturar o Fluxo de Dados com o Fluxo de Processo
Alguns designers podem se sentir desconfortáveis ao ver um conector de ligação a partir de um
Arquivo para um Processo, sem ver a etapa de solicitação de dados que está sendo mostrado no 34
diagrama de alguma forma. Alguns deles irão tentar representar um pedido, adicionando um
conector entre um Processo e um Arquivo, rotulando-o "um pedido" ou "pedido de alguma coisa",
o que é errado.
Tenha em mente que dados Diagrama de Fluxo de Dados são projetados para representar a
troca de informações. Conectores num Diagrama de Fluxo de Dados são para a representação de
dados, não para representar o Fluxo do Processo, Passo ou qualquer outra coisa. Quando rotular
um Fluxo de Dados que termina num Arquivo "um pedido", isso significa, literalmente, estamos a
passar um pedido em Dados a um Arquivo de dados.
4.- Dicionário de dados
4.1.- Utilidade e regras de definição
O Dicionário de Dados pode ser visto como um depósito central que descreve e define o
significado de toda a informação usada na construção de um sistema. O Dicionário de Dados é uma
ferramenta de modelação textual, que permite descrever, com algum rigor, os elementos de dados
do sistema.
A definição de um elemento de dados inclui: a composição do elemento, caso seja composto
por outros elementos, ou os valores que esse elemento pode tomar, caso seja atómico; o
significado do elemento, apresentado em comentários. Permite fazer a verificação de consistência
entre os vários modelos.
O Dicionário de Dados permite:

- a clarificação de significados e referentes;
- a quantificação de conceitos;
- a definição e detalhe de procedimentos alternativos;
- uma melhor representação do sistema.
O uso do dicionário de dados permite descobrir:

- falhas de fluxo de dados (omissões);
- deteção de definições em duplicado;
35 - dados não descritos ou não utilizados.
Com base no processamento do dicionário de dados é possível obter:

- listagens de elementos de dados e estruturas de dados;
- listagens de processos;
- verificações por referência cruzada de entradas;
- deteção de erros.
Os elementos de dados são o nível mais elementar (atómico) de dados, que permite a
representação de atributos do sistema. A estrutura de dados é um conjunto de elementos de dados
relacionados que colectivamente descrevem um componente/objecto do sistema.
O Dicionário de Dados é uma ferramenta textual de apoio à análise e desenho. Este constitui
uma listagem organizada dos elementos de dados que são considerados pertinentes para o sistema.
Um elemento atómico é aquele, cuja
decomposição, não faz sentido no contexto do
sistema. Em certos casos é necessário acordar
com o utilizador se um elemento de informação
é atómico ou necessita de uma maior
decomposição.
Vítor Ferreira
Por exemplo, o termo nome pode ser decomposto em nome_próprio e apelido. Mas em
determinados sistemas essa decomposição pode não ser necessária. Muitas vezes o significado dos
elementos atómicos é óbvio.
4.2.- Conjunto de Elementos do Dicionário de Dados
Cada referência no Dicionário de Dados possui um conjunto de elementos de dados, de acordo

com o tipo de entrada. Cada ocorrência deve contemplar, pelo menos, os seguintes aspectos:
Por componentes do sistema o conjunto de elementos do Dicionário de Dados pode ser:

36
Definição de Fluxo de Dados Definição de Processo
- nome - nome
- descrição - descrição
- processos origem - entrada de dados
- processos destino - saída de dados
- estrutura de dados - resumo do funcionamento (lógica)
Definição de Arquivo Definição de Entidade

- nome - nome
- descrição - descrição
- fluxo de dados recebidos - entrada de dados
- fluxo de dados fornecidos - saída de dados
- descrição dos dados
- volume/carga de utilização
- acesso (características de acesso)
Elementos que podem estar presentes na descrição de um item de um Dicionário de Dados:

4.3.- Notação Típica do Dicionário de Dados
37
O Dicionário de Dados é criado pelo analista durante o processo de desenvolvimento do modelo

do sistema, de modo a que o utilizador seja capaz de o compreender para conferir o modelo.
Algumas das regras para a construção do Dicionário de Dados são:
- Identificar no diagrama de contexto as entidades externas e os dados que emitem ou recebem
relativamente ao sistema;
- Associar, nos outros níveis, processos aos fluxos de dados que entram ou saem do sistema;
- Construir um processo sempre que exista uma alteração num fluxo de dados;
- Seguir os fluxos de dados enviados/recebidos, associando-lhes processos que tratam esses dados;
- Identificar/construir os depósitos de dados que o sistema modifica, cria ou utiliza em instantes
diferentes.
É preciso ter em conta alterações nos modelos sem a manutenção adequada no Dicionário de
Dados, fazem com que seja necessário o Despiste de Inconsistências, senão for efectuado, pode
dar origem a:
- Pseudónimos - Nomes diferentes para a mesma especificação de dados.
- Impostores - Dados com o mesmo nome mas com especificações diferentes.
Vítor Ferreira
- Orfãos - Dados que não pertencem a nenhum componente do sistema; desconhece-se a sua
origem e o seu destino.
4.4.- Relação com o Diagrama de Fluxo de Dados

Um dicionário de dados é uma lista onde é incluída uma descrição de todos os elementos
representados num Diagrama de fluxo de dados: fluxo de dados, arquivos, processos e entidades.
Além de listar, descreve e detalha os elementos dos Diagramas de fluxo de dados. O dicionário
de dados deve ser criado e actualizado em simultâneo com o desenho dos Diagramas.
O dicionário de dados complementa os Diagrama de fluxo de dados na descrição da realidade a
representar, adicionando mais informação. O seu conteúdo deve ser preciso, conciso e não
redundante.
Relativamente ao Diagramas de Fluxo de Dados, o conteúdo de um dicionário de dados é composto
pela:
- Especificação dos fluxos de dados;
- Especificação de arquivos;
- Especificação de processos;
- Especificação da entidade;
4.4.1.-Validação do Dicionário de Dados: 38

A exatidão do dicionário de dados é verificada em combinação com o Diagrama de Fluxo de
Dados (DFD), com a Diagrama Entidade-Associação (DEA), com o Diagrama de Transição de Estados
(DTE) ou com as especificações de processos.
Em termos práticos o que se pretende é que o dicionário de dados esteja completo, consistente
e sem contradições.
A implementação do dicionário de dados é feita habitualmente com o recurso a meios
automatizados que facilitem a tarefa de introdução de centenas e mesmo milhares de entradas em
sistemas relativamente simples, sendo por isso essencial compreender o processo básico em que
se suporta a sua definição, evitando-se assim repetir as entradas.
5.- Diagramas de entidade - associação (DEA)
5.1.- Conceito e Origem
Autores como Peter Chen ou Bachman sugerem um modelo que facilite a criação do modelo
conceptual. Este modelo Entidade-Relação, ou abreviadamente E-R, é acompanhado de uma
técnica de representação gráfica que auxilia vivamente a visualização das relações entre as
entidades e por isso mesmo se aproxima do modelo teórico relacional.
Este modelo é também facilmente convertível no modelo de rede, sendo, contudo, muito
adoptado na análise e concepção de sistemas assentes no modelo relacional com o
desenvolvimento sobre Base de Dados
O diagrama E-R é um modelo conceptual com um elevado nível de concentração. É importante
no desenho e concepção de uma Base de Dados. É “terreno” comum a gestores, analistas e
utilizadores.
5.1.1.- Características e Regras de utilização:

O primeiro Diagrama Entidade-Associação (DEA) construído estará certamente longe da versão
final pois, tal como acontece com os Diagramas de Fluxos de Dados (DFD) ou outras ferramentas
de modelação de sistemas, torna-se necessário proceder à sua revisão e ao consequente
39 aperfeiçoamento contínuo.
Deste modo na construção de um Diagrama Entidade-Associação (DEA) devem ter-se em conta os
seguintes parâmetros:
- Identificar as entidades e as suas associações;
- Definir os atributos das entidades e os atributos identificadores;
- Atribuir cardinalidades e a participação nas relações;
- Completar os graus máximos e mínimos das associações;
- Inserir a descrição das entidades e associações no dicionário de dados.
5.1.2.- Construção e Refinação do Diagrama Entidade-Associação (DEA)

Na construção de um Diagrama Entidade-Associação (DEA) verifica-se que os três primeiros
passos identificados correspondem à construção do modelo conceptual dos dados.
Deve, no entanto, notar-se que o Diagrama Entidade-Associação (DEA) obtido inicialmente no
processo de análise poderá não coincidir com o resultado final das atividades, em particular pela
necessidade frequente de propiciar a sua adequação aos requisitos da organização e dos
utilizadores.
Vítor Ferreira
5.2.- Componentes dum DEA

O diagrama E-R é baseado na percepção do mundo real, que consiste em um conjunto de
objetos, que são chamados de entidades, e nos relacionamentos entre esses objetos. O objetivo
do diagrama E-R é facilitar o projecto de base de dados, possibilitando a construção da estrutura
lógica geral da base de dados. O diagrama E-R utiliza uma representação gráfica para exprimir os
principais conceitos presentes numa determinada Base de Dados: Entidades; Atributos;
Relacionamentos.
Aluno avalia Discilplina
Professor
Nesta análise, identificam-se os seguintes objectos:

Entidades: é uma representação abstrata de um objeto do mundo real; são concretizadas sobre a
forma de ocorrências e representam algo de relevante para a empresa. Ex. cliente; funcionário;
aluno; departamento. 40
Atributos: dado que contém informação que descreve uma entidade; são concretizados sobre a
forma de valores, sendo um descritor cujo valor está associado com as ocorrências de uma
determinada entidade. Ex.: Nome_do_cliente; Id_produto.
Relações: são concretizadas sobre a forma de pares entre ocorrências de duas entidades, sendo
uma razão relevante para a empresa associar duas entidades. Ex.: Cliente COMPRA Produto
Reparação faz Carro
Mecânico
É necessário ter em atenção que não são entidades: Entidade com apenas 1 elemento; Operações
do sistema; Saídas do sistema; Pessoas que realizam trabalhos (utilizadores do sistema); Cargos
de Direção.
Algumas Pistas de Leitura de um diagrama E-R:
A presença de um substantivo usualmente indica uma entidade;
A presença de um verbo é uma forte indicação de um relacionamento;
Um adjetivo, que é uma qualidade, é uma forte indicação de um atributo;
Um advérbio temporal, qualificando o verbo, é uma indicação de um atributo de Relacções.
5.3.- Propriedades das Entidades

Nome: breve classificação do tipo de entidade que descreve. Deve ser um nome no singular (Cliente
e não cliente) e deve ser único na empresa.
Descrição: breve texto explicativo do significado da entidade. Número máximo e mínimo de
ocorrências.
Atributos: são os predicados que caracterizam a entidade.
Identificador: predicado que identifica uma e apenas uma ocorrência dessa entidade.
5.4.- Propriedades dos Atributos

Domínio: refere-se ao leque de possíveis valores que um atributo pode assumir ou armazenar
(Texto, Numérico, Data e Hora);
41
Comprimento: indica o número máximo de caracteres ou dígitos que um valor pode assumir.
Valores permitidos - usado para restringir o domínio de certos tipos de atributos. Descreve os
valores potenciais de um atributo.
Exemplos no domínio dos Atributos: Sexo do funcionário: M ou F; Nome do aluno: 40 caracteres
alfanumérico; Salário: inteiro maior que 5000; Relacionamento: Estrutura que indica a associação
entre duas ou mais entidades Paciente - Receita.
5.5.- Propriedades das Relações

Cardinalidade: representa o número de pares que podem ocorrer entre as entidades
relacionadas.
1:1 Ex.: PESSOA casada com PESSOA, onde uma pessoa pode ser casada com 1 e só 1 pessoa e vice-
versa.
1:N Ex.: LIVRO impresso como EDIÇÃO, onde cada livro pode ser impresso em várias edições, mas
cada edição corresponde a um único livro.
N:N Ex.: AUTOR escreve LIVRO, onde cada autor pode escrever muitos livros e cada livro pode ser
escrito por muitos autores.
Vítor Ferreira
5.5.1.- Propriedades das Relações - Representações

Em termos de representação quer a cardinalidade quer a opcionalidade assumem os seguintes
esquemas:
Um-para-um (1 : 1) : uma entidade A (nesse caso, paciente) está associada no máximo a uma
entidade em B (prontuário) e uma entidade em B está associada no máximo a uma entidade em A.
Neste exemplo, um paciente só pode ter um prontuário e um prontuário só pode pertencer a um
paciente.
Um-para-muitos (1 : N): uma entidade em A (nesse caso, venda) está associada a qualquer número
de entidades em B (cliente), enquanto uma entidade em B está associada no máximo a uma
entidade em A. Neste exemplo, um cliente pode participar de várias vendas, e uma venda só pode
ser realizada para um cliente.
42
Muitos-para-um (N : 1): uma entidade em A (nesse caso, venda) está associada no máximo uma
entidade em B (cliente), enquanto uma entidade em B está associada a qualquer número de
entidades em B. Neste exemplo, uma venda só pode ser realizada para um único cliente, mas um
cliente pode participar de várias vendas.
Muitos-para-muitos (N : N): Uma entidade em A está associada a qualquer número de entidades

em B, e uma entidade em B está associada a qualquer número de entidades em A.
5.5.2.- Propriedades das Relações - Grau do Relacionamento

Uma associação entre duas entidades pode ser caracterizada de três formas distintas: unária
(relação entre uma entidade e ela própria); binária (relação entre duas entidades); complexa
(relação entre 3 ou mais entidades). Uma associação complexa pode reduzir-se a várias associações
binárias.
Relação Binária: quando existe o relacionamento entre apenas duas entidades. Exemplo:
Relação Ternária: quando existe o relacionamento entre três ou mais entidades. Exemplo:
43 A associação é caraterizada pela conjunção dos atributos identificadores das entidades

envolvidas. Cada associação é identificada por: verbo + substantivo. Por defeito, todas as
associações são bidirecionais.
5.6.- Caracterização e Regras de utilização:

O primeiro Diagrama Entidade-Associação (DEA) construído estará certamente longe da versão
final pois, tal como acontece com os Diagramas de Fluxos de Dados (DFD) ou outras ferramentas
de modelação de sistemas, torna-se necessário proceder à sua revisão e ao consequente
aperfeiçoamento contínuo.
Deste modo, para a construção de um DEA dever-se-á ter em conta os seguintes parâmetros:
- Identificar as entidades e as suas associações;
- Atribuir cardinalidades e a participação nas relações;
- Definir os atributos das entidades e os atributos identificadores;
- Completar os graus máximos e mínimos das associações;
- Inserir a descrição das entidades e associações no dicionário de dados.
Vítor Ferreira
5.7.- Construção e Refinação do Diagrama Entidade-Associação

Na construção de um DEA verifica-se que os três primeiros passos identificados correspondem
à construção do modelo conceptual dos dados.
Deve, no entanto, notar-se que o DEA obtido inicialmente no processo de análise poderá não
coincidir com o resultado final das atividades, em particular pela necessidade frequente de
propiciar a sua adequação aos requisitos da organização e dos utilizadores.
5.8.- Notação dos Elementos de um Diagrama Entidade-Associação
Os Atributos representam o conjunto das

representam o conjunto das
características dos objetos, descrevendo
ocorrências de uma entidade, ou seja, são
as características comuns a todas as
instâncias de uma entidade. Os atributos
podem ser de diferentes tipos sendo que
através do Identificador vemos qual o
Atributo (ou combinação de atributos)
44
identificado e as suas características. Os
que são identificados univocamente (são
chaves) de uma ocorrência de uma
determinada entidade e nesse caso os seus nomes são sublinhados.
Relações/Associações: representadas pelos losangos, seguindo as regras que já vimos consoante a

sua disposição.
Uma Restrição chave é a exigência que cada elemento de um conjunto de entidades pode aparecer
no máximo uma vez num relacionamento particular. Por exemplo, a exigência de que a um módulo
de formação não seja alocada mais do que uma sala de um curso mesmo se ele durar mais de um
dia.
A Chave é um conjunto mínimo de atributos cujos valores identificam exclusivamente um item num
um conjunto de entidades.
Por exemplo, o endereço de email (número de matricula/estudante) de um participante num curso
é uma chave para o conjunto da entidade correspondente.
A Chave Composta é uma chave que inclui mais de um atributo. Por exemplo, o piso e número da
sala de um módulo de um curso.
A Participação total é uma exigência que cada elemento de um conjunto da entidade deve aparecer
pelo menos uma vez num relacionamento particular. Por exemplo, a exigência de que cada módulo
deva acontecer em pelo menos em uma data e em uma sala.
5.8.1.- Tipos de Atributos
Atributo Simples
Não possui qualquer característica especial. A maioria dos atributos serão simples. Quando um
atributo não é composto e recebe um valor único como um nome, por exemplo e não é um atributo
chave, então ele será atributo simples. A maioria dos atributos são considerados simples.
Atributo Composto
O seu conteúdo é formado por vários itens menores. Exemplo: Endereço. Podemos decompor o
mesmo em vários outros atributos, como: Rua, Número, Andar, Localidade, Código Postal, Cidade
e Pais, entre outros.
É importante considerar que nas bases de dados um atributo composto geralmente é
desmembrado, ou seja, para o caso do endereço, podemos desmembrá-lo em vários atributos
simples. Conceptualmente o endereço é aceite como um único atributo, mas na prática geralmente
é feito este desmembramento para permitir a organização dos dados, facilitar a procura e a
45
indexação dos mesmos.
Atributo Multivalor
O seu conteúdo é formado por mais de um valor. Por exemplo, Telefone, uma pessoa pode ter mais
do que um número de telefone. Este tipo de atributo é aceite conceptualmente, mas este pode
criar um problema na base de dados. Há duas formas de lidar com este problema, a primeira é
manter o atributo multivalor e permitir que existam sejam inseridos mais do que um dado no
mesmo campo, como por exemplo: dois números de telefone. A segunda alternativa passa por
aplicar o processo de normalização de dados e em que o mesmo é transformado numa nova
entidade na base de dados estando relacionada com a tabela principal.
A primeira alternativa é a mais simples, no entanto teríamos problemas na consulta dos dados, caso
a efetuássemos pelo número de um dos telefones apenas. A segunda exige mais trabalho, no
entanto é mais eficaz.
Atributo Derivado
Alguns atributos podem ter uma relação entre si. Por exemplo, a idade e a data-nascimento de uma
pessoa. Para uma pessoa em particular, podemos determinar o valor da idade através do atributo
data-nascimento. Então a idade é considerada um atributo derivado e é derivada do atributo data-
Vítor Ferreira
nascimento. Alguns atributos podem ser derivados de entidades relacionadas. Por exemplo, um
atributo número-empregados de uma entidade departamento pode ser derivado da contagem do
número de empregados que trabalha para um departamento.
Leitura das Relações/Associações

Os exemplos da figura apresentam três
Pedidos Gestor Gestor
pontos de vista distintos sobre quem
despoleta a acção: no caso (a) a leitura será são atribuídos
'cliente efetua pedidos‘, já no caso (b) a efectua
atribui
leitura é 'gestor atribui descontos', enquanto
no caso (c) a leitura é 'descontos são
Cliente Descontos Descontos
atribuídos pelo gestor‘.
5.9.- Exemplos
5.9.1. Exemplo Propriedades
Nas tabelas podemos verificar que:
46
- Um professor pode ter várias faltas.

- Grupos disciplinares têm mais do que um professor.
- Uma área científica tem vários grupos disciplinares
5.9.2.- Exemplo Representação dos Atributos

5.9.3.- Exemplo Diagrama de Entidade-Associação
47
6.- Definição detalhada de dados

Fases da Criação Base de Dados
- Definir a área de aplicação;
- Determinar as entidades necessárias;
- Desenhar o diagrama de Entidade-Relacionamento (simplificado);
- Desenhar o diagrama de ocorrências;
- Determinar o grau (tipo) dos relacionamentos;
- Determinar as participações obrigatórias;
- Desenhar o diagrama de Entidade-Relacionamento completo;
- Determinar as tabelas necessárias;
- Para cada relação/tabela determinar as chaves candidatas;
- Determinar as chaves primárias;
- Definir as relações finais;
- Definir o domínio dos atributos;
- Desenhar as tabelas correspondentes às relações encontradas;
Vítor Ferreira
6.1.- Nome e descrição de dados
Uma Entidade é representada por uma tabela;

Os campos são as colunas dessa tabela;
Às linhas da tabela dá-se o nome de registos.
A nomenclatura dos campos ou das colunas das tabelas nem sempre são legíveis ou facilmente
entendíveis. Como raramente é necessário mostrar uma tabela nua e crua, sem filtragem ou
formatação a um utilizador, não existe a preocupação de usar nomes “apresentáveis” ou que
sejam autoexplicativos a qualquer um que aceda. A escolha dos nomes dos campos de uma
tabela, numa base de dados, obedece a outros critérios e regras. Normalmente, o programador
usa nomes que façam sentido para si.
48
6.1.1.- Regras para Nomes de Tabelas:

- Para siglas utilizar todas as letras em maiúsculo;
- Usar palavras no singular e sem acentuação;
- Usar nome que identifique e individualize os dados dentro da tabela;
- Dar nomes distintos para dados distintos;
- Utilizar o nome sempre no singular;
- Acrescentar sempre comentário sobre a informação da coluna
Exemplos:
cd_pessoa - código da pessoa; nm_pessoa - nome da pessoa; dt_nascimento - data de nascimento;
vl_salario - valor do salário
6.2.- Campos chave

Temos três tipos de chaves:
Chave primária: (PK - Primary Key) é um identificador exclusivo de todas as informações de cada
registro dando-lhe unicidade. A chave primária nunca se repetirá.
Chave secundária: (SK – Secondary Key) é aquela chave candidata que não é primária. Às vezes
pode ser conveniente identificar entidades por atributos (Ex. Ref. Original; Nome) que não são
únicos dentre todas as instâncias.
Chave Estrangeira: (FK - Foreign Key) são atributos de uma entidade cujos valores aparecem como
chave primária em outra entidade. Define um relacionamento entre as tabelas e pode ocorrer
repetidas vezes. A presença de uma chave estrangeira numa entidade ocorre por força das regras
de integridade referencial.
Um campo chave é um atributo ou um conjunto de atributos que permite identificar de modo
unívoco os registos (entidades ou ocorrências) de uma tabela.
Uma chave primária é um atributo ou conjunto de atributos que assume a função de identificar de
modo unívoco as entidades ou registos de uma tabela.
6.2.1.- Chave primária

- ser unívoca - o ou os atributos que desempenham o papel de chave primária, por definição, tem
de ter um valor único para cada entidade concreta;
- não nula - nenhum dos atributos que formam uma chave primária poderá conter um valor nulo
em nenhum registo;
- não redundante - no caso de uma chave primária ser composta, não devem ser incluídos mais
atributos do que os mínimos necessários para identificar os registos de modo unívoco;
6.2.2.- Regras de Integridade numa Base de Dados

49
As regras de integridade numa Base de Dados relacional são:
1ª Regra - Integridade de Entidade: nenhum valor de uma chave primária pode
ser nulo. Em termos de Diagrama Entidade-Associação, o atributo chave primária deve ser sempre
obrigatório, nunca opcional.
2ª Regra - Integridade Referencial: numa entidade que possui uma chave estrangeira, cada valor
desta chave só pode ser nulo ou igual a algum valor da chave primária correspondente no
relacionamento. A alteração dos valores constituintes da chave primária ou a remoção de uma
instância que contenha uma chave primária com uma chave estrangeira associada noutra entidade
pode causar problemas de integridade referencial.
6.3.- Simplificação das tabelas através de normalização

Normalização de dados é o processo formal e passo a passo que examina os atributos de uma
entidade, com o objetivo de evitar anomalias observadas na inclusão, exclusão e alteração de
registros.
A regra de ouro que devemos observar no projeto de um base de dados é a de "não misturar
assuntos em uma mesma Tabela".
Vítor Ferreira
O conceito de entidade é muito importante neste processo, ou seja, devemos identificar quais
são as entidades que farão parte do projeto de base de dados. Entidade como já vimos é qualquer
coisa, pessoa ou objeto que abstraído do mundo real torna-se uma tabela para armazenamento de
dados. Normalmente usa-se o Modelo de Entidade e Relacionamento para criar o modelo da base
de dados.
Exemplo:
Na Tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes. Não
devemos misturar campos relacionados com outros assuntos, tais como Pedidos, Produtos,
Armazéns. Essa “mistura de assuntos" em uma mesma tabela acaba por gerar repetição
desnecessária dos dados, bem como, inconsistência dos dados.
Tabela 3 - Entidade Filmes (tabela

normalizada)
Normalmente após a aplicação das
Tabela 1 - Entidade Filmes Exemplo (tabela não normalizada) regras de normalização de dados, 50
algumas tabelas acabam divididas em
duas ou mais tabelas, o que no final gera
um número maior de tabelas do que o
originalmente previsto. Este processo
causa a simplificação dos atributos de
uma tabela, colaborando
Tabela 2 - Entidade Mídias com uma tabela normalizada

significativamente para a estabilidade do
modelo de dados, reduzindo-se
consideravelmente as necessidades de manutenção.
Os objetivos da normalização são muitos, de destacar:

- Minimização de redundâncias e inconsistências;
- Facilidade de manipulações do banco de dados;
- Ganho de performance no SGBD;
- Facilidade de manutenção do sistema de Informação;
- Entre outros.
6.3.1.- Primeira Forma Normal (1FN)
A normalização de dados é um processo importante no processo de modelagem de dados. A
primeira parte da normalização é chamada de Primeira Forma Normal (1FN).
Uma relação estará na primeira forma normal (1FN), se não houver grupos de dados repetidos,
isto é, se todos os valores forem únicos. Em outras palavras podemos definir que a primeira forma
normal não admite repetições ou campos que tenha mais que um valor.
Os procedimentos mais recomendados para aplicar a Primeira Forma Normal (1FN) são os
seguintes:
- Identificar a chave primária da entidade;
- Identificar o grupo repetido e removê-lo da entidade;
- Criar uma nova entidade com a chave primária da entidade anterior e o grupo repetido.
51
Todos os Clientes possuem, por um lado Primeiro Nome e Apelidos, e por outro lado no
Endereço surgem Rua, Cidade e Código Postal, e estas informações estão nas mesmas células da
tabela, logo ela não está na Primeira Forma Normal.
Para normalizar será necessário criar uma nova tabela que armazene os números de telefone e
o campo-chave da tabela Clientes.
Vítor Ferreira
Mesmo com o ajustamento efectuado, a tabela ainda não está na Primeira Forma Normal, pois
há clientes com mais de um telefone e os valores estão em uma mesma célula. Para normalizar será
necessário criar uma nova tabela que armazene os números de telefone e o campo-chave da tabela
cliente.
Na Tabela 4 a chave primária está implícita

(codigo_cliente). Neste exemplo foi gerada uma segunda
entidade para que a Primeira Forma Normal fosse satisfeita,
contudo é importante ressalvar que nem sempre
encontramos uma base de dados com tabelas normalizadas.
Existem casos onde as repetições são poucas ou o cenário permite administrar as repetições sem
que estas tenham grandes consequências.
Em resumo a Primeira Forma Normal (1FN) decompõem a estrutura inicial em tantas relações
quantos os grupos de atributos que se repetem, identificando as chaves de cada uma dessas 52
relações e eliminando a redundância existente na versão não normalizada.
6.3.2.- Segunda Forma Normal (2FN)

Uma tabela está na Segunda Forma Normal (2FN) se ela estiver na 1FN e todos os atributos não
chave forem totalmente dependentes da chave primária (dependente de toda a chave e não apenas
de parte dela). Se o nome do produto já existe na tabela Produtos, então não é necessário que ele
exista na tabela de Vendas. A Segunda Forma Normal (2FN) trata destas anomalias e evita que
existam valores redundantes na base de dados.
Os procedimentos mais recomendados para aplicar a Segunda Forma Normal (2FN) são os
seguintes:
- Identificar os atributos que não são funcionalmente dependentes de toda a chave primária;
- Remover da Entidade todos os atributos identificados e criar uma nova entidade com eles.
A chave primária da nova entidade será o atributo do qual os atributos removidos são
funcionalmente dependentes.
Para normalizar esta tabela teremos de criar a tabela Produto que ficará com os atributos
c_produto e produto e na tabela Vendas manteremos somente os atributos n_pedido, c_produto,
quant, valor_unit e subtotal. Conforme verificamos na Primeira Forma Normal, quando aplicamos
normalização é normal que se gerem novas tabelas a fim de satisfazer as formas normais que
estamos a aplicar.
53
Resumindo está na Segunda Forma Normal (2FN) quando está na 1FN e não existem
dependências funcionais entre os atributos não chave, ou seja, cada atributo deve depender apenas
da chave primária da relação. A solução é decompor a relação em duas relações de acordo com
as dependências funcionais existentes
6.3.3.- Terceira Forma Normal (3FN)

Uma tabela está na Terceira Forma Normal (3FN) se ela estiver na 2FN e se nenhuma coluna
não-chave depender de outra coluna não-chave. Na terceira forma normal temos de eliminar todos
aqueles campos que podem ser obtidos pela equação de outros campos da mesma tabela.
Os procedimentos mais recomendados para aplicar a Terceira Forma Normal (3FN):
- Identificar todos os atributos que são funcionalmente dependentes de outros atributos não chave;
Vítor Ferreira
- Removê-los.
A chave primária da nova entidade será o atributo do qual os atributos removidos são
funcionalmente dependentes.
Considerando ainda a tabela Vendas, vemos que a mesma não está na Terceira Forma Normal
(3FN), pois o subtotal é o resultado da multiplicação quant X valor_unitario, desta forma a coluna
subtotal depende de outras colunas não-chave.
Para normalizar esta tabela na Terceira Forma Normal (3FN) teremos de eliminar a coluna subtotal:
54
Resumindo uma tabela na Terceira Forma Normal (3FN) é uma tabela em que as relações, além de
estar na 2FN, não existem dependências funcionais entre os atributos não chave. Ou seja, cada
atributo deve depender apenas da chave primária da relação. A solução é decompor a relação em
duas relações de acordo com as dependências funcionais existentes.
6.3.4.- Outras Formas Normais (BCFN; 4FN; 5FN)

Na prática, a normalização não deve ser levada às últimas consequências, pois a proliferação de
relações pode ter consequências ao nível do desempenho global do sistema.
Como é evidente, quanto mais “espalhados” estiverem os dados por várias relações, mais
junções entre relações vão ser necessárias para obter a mesma informação. Ou seja, a obtenção de
informação pode, em algumas situações, torna-se um processo demorado, dado o número de
junções que é necessário efectuar entre relações.
Deparamo-nos então com dois objectivos frequentemente conflituosos: por um lado
pretendem-se sistemas flexíveis, sem problemas de redundância; por outro lado exigem-se
sistemas com alto desempenho.
É, pois, necessário estabelecer um compromisso. Pretende-se um esquema equilibrado que

nunca ponha em risco integridade da base de dados, mas que, simultaneamente, tenha um
desempenho razoável, pois só assim será utilizado. Por essa razão, na maioria dos casos o processo
de normalização para na 3FN ou na BCFN.
6.3.4.1.- Boyce-Codd Normal Form (BCFN)

Cada determinante é uma chave candidata, por exemplo no cado do nº formando, coordenador e
área. Se somente o no de estudante fosse chave, ao eliminar um estudante poderíamos estar a
eliminar um coordenador e uma área. Se o no de estudante e o coordenador forem chaves, já não
55
se verifica esse risco. Por definição uma relação está na BCNF se todos os atributos são
funcionalmente dependentes da chave, de toda a chave e nada mais do que a chave
6.3.4.2.- 4 Forma Normal

Diz-se que uma relação está na 4FN se está na BCFN e não existem dependências multivaloradas.
Se numa relação ainda existem dependências multivaloradas, esta relação deve ser decomposta.
6.3.4.3.- 5 Forma Normal

Uma relação estará na 5FN se não puder ser mais decomposta sem perda de informação. Se puder
ser reconstruída sem perda de informação a partir de algumas das suas projeções, então existe uma
dependência de junção e, portanto, a relação não se encontra na 5FN, devendo ser decomposta
segundo essa dependência.
6.4.- Tabelas de descrição de códigos

Os elementos fundamentais de uma base de dados são as tabelas – em que a informação é
estruturada em campos e registos.
Cada tabela é designada por um nome único dentro de uma base de dados e corresponde a uma
classe de entidades ou a um relacionamento entre entidades.
Vítor Ferreira
Uma tabela é definida por um conjunto de colunas, correspondentes aos campos ou atributos
de uma entidade ou classes de entidades.
Cada coluna ou campo da tabela tem um nome único dentro da tabela; mas podem existir
campos com o mesmo nome em tabelas distintas. As linhas de uma tabela correspondem aos
registos ou ocorrências de entidades
Para que uma tabela esteja correctamente constituída, deve respeitar as seguintes regras:
- Não pode haver duas colunas (campos ou atributos) com o mesmo nome; cada coluna é
identificada de modo único;
- Não deve haver campos vazios;
- O domínio de todos os atributos deve ser constituído por valores atómicos; não é permitido incluir
mais do que um valor em cada campo de cada registo;
- Cada linha da tabela representa uma entidade ou ocorrência única; por isso não pode haver
registos duplicados.
6.4.1.- Registos
Resumidamente, um registo é uma instância de uma tabela, ou entidade. A construção da base
de dados dá-se a partir das Entidades. Uma entidade como vimos é uma representação de um
56
conjunto de informações sobre determinado conceito do sistema de informação. As entidades
possuem Atributos, que são as informações que referenciam a entidade. Para exemplificar no
sistema de controle de Biblioteca, partimos do conceito principal que é o empréstimo de obras por
utilizadores da biblioteca. A partir deste conceito inicial, vamos ramificando e descobrindo novos
conceitos.
Para identificar se um conceito pode ser uma entidade deve colocar-se a questão: "Quais as
informações que desejo armazenar sobre este conceito (Entidade)?" Se houver informações para
armazenar estamos perante uma Entidade. Exemplificando: Desejo armazenar os seguintes dados
do livro: Título, Autor, Editora, Ano, Edição e Volume. Temos então a Entidade Livro.
Cada linha formada por uma lista ordenada de colunas representa um registo. Os registos não
precisam de ter informações em todas as colunas, podendo assumir valores nulos (NULL) quando
isso fizer sentido.
Podemos iniciar nosso raciocínio da seguinte forma:

"Uma biblioteca possui Obras literárias que podem ser tomadas em empréstimos pelos usuários
credenciados."
Podemos rapidamente perceber que existirá um cadastro de livros, um cadastro de utilizadores
e um registo de empréstimos! É essa visão que temos que ter ao modelarmos uma base, isto é,
devemos detectar as informações que devemos armazenar.
6.5.- Modelos de dados

O Esquema de uma base de dados consiste no desenho, ou estrutura lógica, com que a mesma
é definida. O desenvolvimento de uma base de dados pode ser realizado segundo diferentes
modelos conceptuais. Os modelos conceptuais são conjuntos de ferramentas que descrevem os
dados, a sua semântica e as restrições.
Existem muitos modelos de bases de dados, entre eles os Modelos Físicos (Relacional;
Hierárquico; Rede) e os Modelos Lógicos (Entidade-Associação; Semântico). O mais conhecido e
mais utilizado, é o modelo Entidade-Associação, também conhecido por Entidade -
Relacionamento ou, simplesmente, modelo ER.
7.- Modelos
Um Modelo é uma abstração, uma representação gráfica, de uma determinada realidade ou
visão. Tem como intuito descrever sistemas e é um poderoso instrumento auxiliar para a sua
57 compreensão.
Desta forma, um modelo é algo que se tem a esperança de compreender em função de
qualquer coisa, do qual se julga ter a completa compreensão.
Os modelos desempenham um importante papel na aquisição de novos conhecimentos, e no
desenvolvimento de novas aplicações.
7.1.- Tipos de Modelos

Os modelos podem ser classificados de duas maneiras:
Físicos - são de compreensão imediata, pois são, normalmente réplicas a uma escala reduzida de
um determinado sistema. O modelo físico mostra não só o que o sistema é ou faz, mas também a
forma como o sistema é, física e tecnicamente, implementado. Os modelos físicos estáticos
facilitam a visualização das relações espaciais. Outros modelos físicos dinâmicos usam-se, por
exemplo, em túneis de vento para estudar o comportamento aerodinâmico de protótipos de
máquinas agrícolas;
Lógicos - Um modelo lógico é aquele em que símbolos constituem o modelo. Estes, apesar de serem
mais difíceis de compreender do que os físicos, são os mais frequentes. O simbolismo usado pode
Vítor Ferreira
ser uma linguagem escrita. Uma imagem, ou uma descrição verbal, podem formar um modelo dum
sistema. Os modelos matemáticos são um tipo especial deste tipo de modelos.
7.2.- Modelos Físicos

7.2.1.- Modelo Relacional
Em 1970 Edgar Frank Codd propõe o modelo de dados relacional. A estrutura básica é a tabela.
Uma base de dados relacional é formada por um conjunto de tabelas que se relacionam através
da partilha de atributos comuns.
Oracle Server da Oracle Corp .; Informix SE e RDS e DB2 da IBM, SQL Server da Microsoft, Sybase
SQL da Sybase Inc. entre outros, são os mais vendidos dos grandes fabricantes que aderiram aos
Sistemas de Gestão de Bases de Dados seguindo o modelo relacional.
Os dados são registados em quadros a duas dimensões (linhas e colunas). A manipulação destes
dados faz-se de acordo com a teoria matemática das relações. 58
O modelo relacional apareceu devido às seguintes necessidades: aumentar a independência de

dados nos sistemas gerenciadores de banco de dados; prover um conjunto de funções apoiadas em
álgebra relacional para armazenamento e recuperação de dados;
A estrutura fundamental do modelo relacional é a relação (tabela). Uma relação é constituída
por um ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Cada instância do
esquema (linha) é chamada de tupla (registro). O modelo relacional não tem caminhos pré-
definidos para se fazer acesso aos dados como nos modelos que o precederam.
O modelo relacional não tem caminhos pré-definidos para se fazer acesso aos dados como nos
modelos que o precederam. O modelo relacional implementa estruturas de dados organizadas em
relações. Porém, para trabalhar com essas tabelas, algumas restrições precisaram ser impostas para
evitar aspectos indesejáveis, como: Repetição de informação, Incapacidade de representar parte
da informação e Perda de informação. Essas restrições são: integridade referencial, chaves e
integridade de junções de relações.
Exemplo:
O Modelo Relacional usa uma coleção de tabelas para representar dados e relações entre eles.
Cada tabela possui diversas colunas; cada coluna corresponde a um atributo de um dado tipo; cada
linha da tabela corresponde a um registo (conjunto de valores dos diversos atributos); cada registo
é identificado por um atributo (ou conjunto de atributos) único.
O modelo de dados relacional é uma ferramenta de modelação importante porque os seus
conceitos básicos são simples e gerais, não dependendo de nenhum tipo de programa informático.
O objeto fundamental do modelo relacional é a relação. Este apresenta os dados como um
59
conjunto de relações e tem um sólido fundamento teórico, com base na Teoria Matemática dos
Conjuntos e na Álgebra Relacional.
O modelo de dados relacional tem ainda as seguintes vantagens:

- É independente das linguagens de programação;
- É independente dos sistemas de gestão de bases de dados;
- É independente dos sistemas operativos.
7.2.2.- Modelos Hierárquicos & Rede

Na década de 60, os computadores tornaram-se importantes nas empresas e organizações,
assim como os dados.
Foram desenvolvidos dois principais modelos de dados:
- Modelo em rede (CODASYL - Comitee for Data Systems Language)
- Modelo hierárquico (IMS – Information Management System)
Vítor Ferreira
7.2.3.- Modelo Hierárquico

As duas estruturas básicas do modelo hierárquico são os
registos e os relacionamentos pai-filho. Um registo é uma colecção
de valores de campos que fornece informação sobre uma entidade
ou instância de um relacionamento.
Os dados são classificados hierarquicamente, de acordo com
uma “arborescência” descendente. Este modelo utiliza
apontadores entre os diferentes registos. Trata-se do primeiro modelo de Sistema de Gestão de
Base de Dados.
Exemplo:
O conjunto de todos os registos de clientes e de contas são organizados na forma de uma árvore
com raiz, em que a raiz da árvore é um registro falso.
Uma ligação é uma associação entre dois registros. O relacionamento entre um registro-pai e
vários registros-filhos possui cardinalidade 1:N. Os dados organizados segundo este modelo podem
ser acedidos segundo uma sequência hierárquica com uma navegação do topo para as folhas e da
esquerda para a direita (Date, 2000).
60
Um registo pode estar associado a vários registros diferentes, desde que seja replicado. A
replicação possui duas grandes desvantagens: pode causar inconsistência de dados quando houver
atualização e o desperdício de espaço é inevitável.
7.2.4.- Modelo em Rede

Este modelo utiliza apontadores para os registos. Os dados
são classificados hierarquicamente, de acordo com uma
“arborescência”, sendo que a estrutura já não é
necessariamente arborescente no sentido descendente.
Os primeiros trabalhos foram realizados em 1964 por Charles Bachman; é representado por um
diagrama constituído por caixas e linhas; são usados apenas relacionamentos muitos-para muitos
(N-N).
Um relacionamento neste modelo é conhecido por Set e é-lhe atribuído um nome. O registo pai
chama-se owner e o registo filho chama-se member.
No modelo em rede, os registos são organizados em marcações onde aparece um único tipo de
associação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário e membro.
Exemplo:
61
Ao contrário do Modelo Hierárquico, em que qualquer acesso aos dados passa pela raiz, o
modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz. O diagrama para
representar os conceitos do modelo em redes consiste em dois componentes básicos: Caixas, que
correspondem aos registos e Linhas, que correspondem às associações.
Estes dois modelos: Hierárquico e Rede são orientados a Registos, isto é, qualquer acesso à base
de dados – inserção, consulta, alteração ou remoção – é feito em um registo de cada vez.
7.3.- Modelos Lógicos

O modelo conceptual – lógico descreve os dados em termos do modelo; baseia-se nas
funcionalidades e restrições dos dados:
- Descrição das relações existentes no banco de dados;
- Estruturas simples ≥ estruturas complexas no nível físico;
- Nível usado pelos administradores do base de dados.
O modelo Entidade – Associação permite desenvolver uma descrição de alto nível dos dados e
das restrições conhecidas sobre os mesmos.
Vítor Ferreira
7.3.1.- Entidade-Associação
Em 1976, Peter Chen propõe o modelo Entidade Relacionamento (ER) para projectos de bases
de dados dando uma nova e importante percepção dos conceitos de modelos de dados.
Assim como as linguagens de alto nível, a modelagem ER possibilita ao projectista concentrar-
se apenas na utilização dos dados, sem se preocupar com estrutura lógica de tabelas.
O modelo de dados precursor da modelação semântica surge por proposta de Chen [1976] com
a designação de Modelo Entidade-Relacionamento (Modelo Entidade-Associação) ou E-R.
Uma outra abordagem, igualmente considerada fundadora
deste tipo de modelação, deve-se a Codd e teve em vista a
introdução no modelo relacional tradicional “de um maior
significado”, sendo conhecido pela sigla RM/T1.
O modelo resultante destas duas abordagens é
suficientemente prático para permitir descrever de forma gráfica
a estrutura de uma Base de Dados, possibilitando uma apreensão
mais rápida da complexidade desta.
Assim, é utilizado – ainda que de forma incompleta – por
muitas ferramentas gráficas de desenho de Base de Dados que acompanham alguns dos Sistemas
de Gestão de Bases de Dados mais conhecidos. 62
Observa-se o seguinte:
-São duas as entidades: Empregado e Tarefa
-Atributos da entidade Empregado:
Cod_Emp (determinante - está sublinhado); Nome (monovalorado); Dependentes (multivalorado);
Endereço (composto); Rua (monovalorado); Cidade (monovalorado); UF (monovalorado)
-Atributos da entidade Tarefa:
Cod_Tar (determinante - está sublinhado); Descrição (monovalorado)
-O relacionamento entre Empregado e Tarefa possui cardinalidade 1:N.
7.3.1.1.- Tipos de Atributos

Atributo simples ou atômico: assume um único valor, num certo instante de tempo, para cada
instância. Exemplo: Nome, de Empregado
Atributo composto: formado por um ou mais sub-atributos. Exemplo: Cidade, de Empregado.
Cidade pode ser composto pelo nome da cidade e o estado.
Atributo multivalor: assume diversos valores. Seu nome, normalmente, é no plural. Exemplo:
Dependentes, de Empregado
Mais informação sobre os diferentes tipos de atributos ver ponto 5.8.1.- Tipos de Atributos.
7.3.2.- Modelos Semânticos

Existem ainda outros estilos de diagramas. Os mais comuns são:
- Rein85, desenvolvido por D. Reiner em 1985;
- Pé-de-galinha, desenvolvido por C.W.Bachman;
- IDEF1X, derivado de estudos do ICAM (Integrated Computer-Aided Manufacturing), conduzidos
no final de 1970.
63
Vítor Ferreira
8.- Organização de Ficheiros vs Bases de Dados

64
8.1.- Organização de Ficheiros e modo de acesso
8.1.1.- Distinção entre Dados e Informação
Fazendo um breve resumo das definições teóricas implementadas, pode-se considerar que:
- Dados, são factos crus, símbolos, que representam objetos, ações e acontecimentos. Os
símbolos podem ser gerados, modificados, copiados, ou eliminados, mas não têm um valor direto
no processo de tomada de decisão.
Os dados representam o conjunto de tudo o que é necessário à resolução de um problema.
Exibem o que é notório e dessa forma servem de ponto de partida ao raciocínio.
Estes podem ser pensados como um reservatório de observações (dados registados numa
estação meteorológica, por exemplo). Pertencem a uma coleção de medidas sobre um
determinado aspeto ou fator. Como a informação é gerada a partir dos dados, ela pode,
eventualmente, passar a fazer parte do conjunto de dados.
Os dados podem ser considerados como uma coleção de factos desorganizados, ainda não
processados em informação. Representam factos, em bruto, a partir dos quais se pode retirar
conclusões. Estes permitem descrever os mais variados conceitos, lugares, coisas, processos ou
acontecimentos. (Fernandes, 2005).
- Informação, são dados que foram processados/estruturados numa forma que os torna
imprescindíveis ao processo de tomada de decisão.
A informação possui diversos atributos: tempo, forma, lugar, relevância coerência. Estas
características contribuem diretamente para o valor intrínseco da informação. A informação
também pode ser considerada a entidade que avalia a diferença entre saber/não saber; entre
conhecer/não conhecer.
8.1.2.- Base de Dados, Sistema de Base de Dados e Sistema de Gestão de Base de Dados
Base de Dados (DB) é uma coleção de dados interligados, representando informações sobre um
domínio específico. Exemplos: lista telefônica, acervo de uma biblioteca.
Sistema de Base de Dados (SDB) é um sistema de manutenção de registos por computador
envolvendo quatro componentes principais: dados, hardware, software e usuários. Um SBD possui
como objetivos isolar o usuário de detalhes mais internos do BD (abstração de dados) e prover
independência de dados às aplicações (estrutura física de armazenamento e estratégia de acesso).
Sistema Gestão de Base de Dados (SGBD) é um software com recursos específicos para facilitar a
manipulação das informações de um BD e o desenvolvimento de programas aplicativos. Exemplos:
Oracle, Paradox, MySQL, Access, Interbase, Sybase
65
Vantagens da utilização de um Sistema de Base de Dados (SBD) em relação aos sistemas
tradicionais de gestão de arquivos são:
- Rapidez na manipulação e no acesso à informação;
- Redução do esforço humano no desenvolvimento e utilização das aplicações;
- Disponibilização da informação no tempo necessário;
- Controle integrado de informações distribuídas fisicamente;
- Redução da redundância e de inconsistência de informações;
- Compartilhamento de dados;
- Aplicação automática de restrições de segurança;
- Redução de problemas de integridade
8.1.3.- Evolução - Do processamento básico às Gestão da Base de Dados

O Processamento Básico (ficheiros elementares, anos 50/60) caracterizou-se por trabalhos
isolados de programação; cada programa tinha os seus ficheiros. A manipulação dos dados estava
reduzida à simplicidade das suas funções: ordenação, classificação e realização de somatórios. O
software pouco mais fazia do que o input/output sobre o mecanismo de armazenamento,
Vítor Ferreira
normalmente numa banda magnética. Qualquer alteração à forma como os dados deveriam estar
armazenados, implicava modificações nos programas, a sua recompilação e teste.
A alteração num dado conduzia à criação de um novo ficheiro. O antigo continuava a existir e
assim sucessivamente. A grande maioria dos ficheiros era utilizada numa só aplicação. Havia,
portanto, um alto nível de redundância, com os mesmos dados multiplicados por n ficheiros.
A Gestão de Ficheiros (anos 60/70) caracteriza-se por procedimentos isolados de programação
que foram integrados em funções. Começaram a aparecer os primeiros casos de partilha de
ficheiros entre programas diferentes. Ainda não era possível o acesso aos campos, só aos registos
no seu todo. Por esta altura deram-se os primeiros passos, no sentido de isolar as aplicações dos
efeitos perversos das alterações de hardware.
Tal como no caso anterior também aqui os ficheiros eram, de uma forma geral, desenvolvidos
com um único propósito. Muita da informação estava repetida e era incoerente entre os ficheiros,
tendo que haver vários programas com finalidades idênticas.
A Gestão de Base de Dados (a partir dos anos 80) marca o nascimento dos sistemas de gestão
de base de dados que gerem os dados independentemente dos programas. As tabelas podem ser
alteradas, não obrigando à recompilação dos programas. A noção de modelo de dados tornou-se
essencial para o desenvolvimento de bases de dados. Aos dados passaram a ser aplicados dois
níveis de independência, a lógica e a física. 66
O primeiro sistema de armazenamento automático de dados foi o sistema de ficheiros que usou
o mesmo modelo que os sistemas de ficheiros manuais existentes. (Ex. fichas dos pacientes num
consultório médico).
Entende-se por Sistema de Gestão e Base de Dados (SGBD), o programa ou conjunto de
programas que possibilitam a criação e manipulação de base dados (inserção, eliminação, alteração
e consulta dos dados).
Os dados são independentes dos programas que os manipulam. Assim, o seu objectivo é registar
e manter a informação que for considerada necessária à organização/pessoa que gere o sistema,
disponibilizando-a automaticamente para os mais diversos fins.
8.1.4.- Arquitetura de um Sistema de Gestão de Base de Dados (SGDB)

A arquitetura de um Sistema de Gestão de Base de Dados (SGDB) têm como principal objectivo,
separar aplicações do utilizador dos dados físico e está dividida em três níveis:
Nível Interno ou Esquema Interno - usa um modelo de dados que mostra a estrutura de
armazenamento físico do banco de dados, os detalhes dos dados guardados e os caminhos de
acesso. Descreve como os dados estão realmente armazenados, englobando estruturas complexas
de baixo nível.
Nível Conceptual ou Esquema Conceptual -
efectua uma descrição total da estrutura da base de
dados, mas não oferece detalhes dos dados
guardados na base de dados. Descreve quais os
dados estão armazenados e seus relacionamentos.
Nível Externo ou Esquema de Visão - descreve as
visões da Base de Dados para um grupo de
utilizadores que mostra quais utilizadores terão
acesso à Base de Dados e a que Dados. Descrevendo
partes da Base de Dados que serão visualizadas pelos
utilizadores de acordo com suas necessidades, estamos perante uma visão que é um subconjunto
de dados da Base de Dados.
Vantagens - Esta arquitectura de três níveis, além de prever a abstração de dados, garante
também a independência lógica e física dos dados. Uma independência lógica possui a capacidade
de mudar o esquema conceptual sem a necessidade de modificar programas da aplicação e
esquemas externos, enquanto que a independência física tem a capacidade de mudar o esquema
interno sem a necessidade de alterar os esquemas conceptual e externo.
67 Exemplos - O acréscimo de uma informação num esquema conceptual é um exemplo da
independência lógica e a reorganização física dos arquivos e a criação de estruturas de acesso
adicionais são exemplos de independência física.
8.1.5.- Características de Sistema de Gestão de Base de Dados (SGBD)

Um Sistema de Gestão de Base de Dados (SGBD) é um sistema de gestão e armazenamento de
dados, capaz de aceder eficientemente a grandes quantidades de dados. Serve de intermediário
como vimos entre o nível aplicacional e a base de dados, evitando a manipulação directa por parte
de cada aplicação por parte do utilizador. É a única entidade responsável pela segurança,
integridade e validade dos dados armazenados.
Através de um Sistema de Gestão de Base de Dados (SGBD), podem realizar-se um vasto conjunto
de operações, das quais é possível destacar:
- Inserção, edição e apagamento de registos;
- Critérios de visualização de registos;
- Indexação e ordenação da informação contida nos registos;
- Operações estatísticas sobre os dados;
- Criação de ecrãs de apresentação;
Vítor Ferreira
- Acesso à informação através das tecnologias Internet;

- Impressão de relatórios;
- Automatização de funções;
- Programação;
A maioria dos Sistema de Gestão de Bases de Dados possui:

- Suporte para pelo menos um modelo de dados através do qual o utilizador possa visualizar os
dados.
- Suporte para linguagens de alto nível que permitam ao utilizador definir a estrutura de dados e
manipular os dados.
- Gestão de transações - Possibilitar o acesso à base de dados de vários utilizadores em simultâneo
(acesso concorrente)
- Controlo de acesso – Capacidade para impedir o acesso aos dados a utilizadores não autorizados
e verificar a validade dos dados
- Capacidade de recuperação de falhas sem perda de dados.
8.1.6.- Relação entre ficheiros e bases de dados

O termo base de dados refere-se a um conjunto estruturado de informação. Uma base de dados é 68
uma coleção de dados formalmente definida, informatizada, partilhável e sujeita a um controlo

central.
Uma base de dados é uma coleção de dados que se relacionam entre si com múltiplas utilizações.
Uma base de dados é um sistema de gestão de informação relativamente complexo.
Dado que a base de dados é a componente central do sistema, uma boa técnica de desenho é crucial
para a eficácia do sistema.
Se a função duma base de dados fosse simplesmente a de armazenar dados, a sua organização seria
relativamente simples. A complexidade estrutural das bases de dados resulta do facto de que ela
deve especificar as relações que existem entre os dados.
Uma base de dados é composta por um conjunto de tabelas e sucessivas associações.
A associação entre os dados é o ponto forte dos sistemas relacionais. As tabelas são formadas por
linhas e colunas onde figuram os dados. Numa base de dados relacional os dados estão todos
representados como valores nas colunas das tabelas.
Neste tipo de aplicação, os dados e os programas estão completamente separados. Já o mesmo
não se passa, por exemplo, nas folhas de cálculo em que os dados e procedimentos estão
frequentemente misturados.
Uma vantagem importante da tabela resulta do facto desta poder ter mais do que uma finalidade
e dos seus dados poderem ser vistos com diferentes formas e formatos, ao contrário de um ficheiro.
Os sistemas de gestão de bases de dados relacionais (SGBDR) são aplicações informáticas
complexas, mas essenciais em muitas áreas científicas, onde grandes quantidades de informação
necessitam de ser combinadas ou exploradas, de diversas formas, nem todas fáceis de prever.
8.1.7.- Sistemas de Ficheiros vs Sistemas de Bases de Dados

Num sistema de ficheiros cada aplicação cria e mantém os ficheiros com todos os dados
necessários para a sua execução. Quando surge uma nova aplicação, na maioria dos casos, é
necessário criar novos ficheiros, com campos que provavelmente já existem noutros ficheiros.
Já um sistema de base de dados tenta baixar os custos de manutenção através da separação
entre a forma como os dados são percebidos pelo programador e a forma como esses dados são
armazenados fisicamente. Se um programador altera uma estrutura de dados, essa nova estrutura
é criada a partir da Base de Dados através do software de Gestão da Base de Dados e não tem que
se reflectir nos outros programas.
Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para
múltiplos objectivos. O conceito de base de dados faz hoje parte do nosso dia a dia mesmo que por
69 vezes de forma não explícita.
Exemplos:
- quando fazemos compras num hipermercado.
- quando usamos um cartão de crédito (ou de débito)
- quando procuramos um livro na biblioteca.
- quando procuramos um programa de férias numa agência de viagens
- quando acedemos à página dos serviços académicos
8.1.8.- Vantagens das Bases de Dados

Algumas vantagens na utilização duma base de dados:
- Diminuição de espaço físico ocupado;
- Maior integridade dos dados;
- Menos redundância;
- Mais facilidade na partilha de dados;
- Maior facilidade de manutenção;
- Isolamento entre objectos de dados (protege a integridade da origem dos dados);
- Facilidade de mudança na criação de diferentes mapas com diferentes objectivos;
Vítor Ferreira
8.1.9.- Objectivos das Bases de Dados

Os principais objectivos a atingir com a utilização de uma base de dados são:
- Incluir toda a informação relevante;
- Evitar redundância de informação;
- Assegurar a consciência e a integridade da informação na utilização da BD;
- Elaborar aplicações de fácil utilização e compreensão;
8.1.10.- Limitações dos Ficheiros

A definição dos dados ao estar integrada na própria estrutura dos programas em vez de estar
guardada separadamente e de forma independente é uma limitação.
Não existem mecanismos de controle no acesso e na manipulação de dados além daquele que
é imposto pelos programas aplicacionais.
Entre as principais limitações do sistema de ficheiros podemos encontrar:
- Separação e isolamento dos dados.
- Duplicação de dados.
- Dependência dos dados.
- Formatos dos ficheiros incompatíveis.
- Sistemas de interrogações (queries) fixos.
70
- Grande dependência do programador das aplicações.
- Proliferação das aplicações.
9.- Ambiente de acesso a bases de dados

9.1.- Independência dos Dados
Como vimos em sistemas de ficheiros os dados encontram-se em diferentes ficheiros cada um
com a estrutura e a organização que interessa à aplicação que o criou. Uma vez que o
relacionamento entre os dados é feito ao nível das aplicações, estes permanecem “isolados” em
cada componente (ficheiro). A eliminação ou alteração de parte destes dados por alguma outra
aplicação pode facilmente conduzir à perda de integridade da informação.
Um sistema de base de dados tenta baixar os custos de manutenção através da separação entre
a forma como os dados são percebidos pelo programador e a forma como esses dados são
armazenados fisicamente.
Se um programador altera uma estrutura de dados, essa nova estrutura é criada a partir da Base
de Dados através do software de gestão da Base de Dados e não tem que se reflectir nos outros
programas.
Exemplo: Necessidade de registo de informação acerca de um novo atributo de uma qualquer
entidade. Registo do “Cartão do Cidadão” de todas as “Pessoas”? As alterações podem ser feitas
sem afectar vistas (“views”) já realizados
9.2.- Inter-relação entre Dados

Devido a questões de Optimização do desempenho ou de segurança, é possível alterar aspectos
relativos à implementação física da base de dados, sem que se altere o seu esquema conceptual,
isto é, manter os dados e as associações entre eles inalterado. Qualquer alteração no modelo físico
não implicará alterações ou ajustamentos no modelo conceptual.
Exemplos: - Alteração das estruturas de armazenamento de informação (ficheiros) - Criação de

índices para optimizar o acesso à informação.
9.3.- Partilha na utilização dos Dados

Numa base de dados distribuída, esta surge ao utilizador como uma única base de dados, sendo
na realidade constituída por diversas bases de dados (i. é, diversos SGBD’s) distribuídos por
diferentes computadores.
Tipicamente as aplicações de bases de dado seguem um modelo cliente-servidor:
- Um servidor contém os dados e executa o Sistema de Gestão de Base de Dados.
71
- Os Clientes ligados por uma rede de comunicações executam os programas de aplicação, que
fazem a interface com o utilizador e o acesso remoto à base de dados.
9.4.- Integridade dos Dados

9.4.1.- Controlo de Acesso - Segurança
É um dos requisitos básicos exigidos a um Sistema de Gestão de Base de Dados. Consiste em
proteger os dados armazenados dos acessos não autorizados e garantir que todas as operações
executadas sobre a base de dados o são por utilizadores (aplicações) devidamente credenciados.
9.4.2.- Controlo de Acesso - Integridade

Por definição, uma base de dados está num estado de integridade se todos os dados que contém
são válidos, isto é, não contradizem a realidade que estão a representar nem se contradizem entre
si.
Exemplo: Elevados Custos de Manutenção (sistema ficheiros) - cada aplicação que acede a um
determinado ficheiro tem que conter uma especificação do respectivo modelo físico e do seu
protocolo de acesso. Uma simples alteração nesse ficheiro pode propagar a necessidade de
alteração de todas as aplicações que acedem ou registam informação nesse ficheiro.
Vítor Ferreira
Um dos principais objectivos de um sistema de base de dados é que um programa possa ser
modificado, alterando a forma de utilização dos dados, sem que isso implique alterações nos
restantes programas que utilizam os mesmos dados.
9.5.- Redundância da Informação - Tolerância a Falhas

Devido à potencial importância dos dados armazenados numa base de dados, é essencial a
implementação de mecanismos de tolerância a falhas (hardware / software), que garantam a
reposição da informação para um estado anterior válido.
Para tal são utilizados basicamente dois mecanismos:
- Implementação de cópias de segurança com estados válidos da base de dados (Backups)
- Registos de actividade (Logging). Registo de todas as operações efectuadas sobre a base de dados
a partir do último ponto de cópia Se ocorre uma anomalia, o procedimento de recuperação permite
a partir da última cópia e do registo de actividades, restaurar a base de dados para um estado
consistente e detectar a origem da anomalia.
10.- Bibliografia
Beureh, H. (2000). Gerenciamento de Informação: um recurso estratégico no processo de Gestão
Empresarial. 2.ed. São Paulo: Atlas.
72
Bio, S. (1985). Sistemas de Informação: um enfoque Gerencial. 1.ed. São Paulo: Atlas.
Boaventura, E. (2009). Como ordenar as ideias. 9. ed. São Paulo: Ática
Caldeira, C. (2011). Introdução aos Sistemas de Gestão da Informação. Universidade de Évora:

Departamento de Informática.
Connolly, T., & Begg, C., (2002). Database Systems - A Practical Approach to Design,
Implementation, and Management. III Edição. New York:Addison-Wesley.
Date, C. (2000) Introdução a Sistema de Banco de Dados. São Paulo: Editora Campus
Domingos, E. & Patriarca, T. A. (2005). Tópicos de análise de sistemas. Lisboa: Fundação para a
Divulgação das Tecnologias de Informação.
Fernandes, N. (2005). Qualidade no desenvolvimento de sistemas de informação: análise de

sistemas de informação. Dissertação de Mestrado em Gestão dos Sistemas de Informação.
Universidade Técnica de Lisboa: Instituto Superior de Economia e Gestão.
Laudon, K. & Laudon, J. (2011). Sistemas de Informação Gerenciais. 9a edição. São Paulo: Pearson
Ramakrishman, R. (1998). Database Management Systems. Columbus: McGraw-Hill International

Editions.
Teorey, T. (1994) Database Modeling and Design: The Fundamental Principles, II Ediçao. San
Francisco: Morgan Kaufmann.

Manualufcd 781 Anlisedesistemasdeinformao

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manualufcd 781 Anlisedesistemasdeinformao

Enviado por

Direitos autorais:

Formatos disponíveis

Manual

3.1.7.- Exemplos de Diagramas de Fluxo de Dados ................................................................. 31

0.2.- Conteúdos Programáticos

2.- Metodologias de análise de sistemas 7.- Modelos Físicos

Os Dados, ao contrário, são sequências de factos ainda não analisados, representativos de

1.1.1.- As Diferenças - Dados vs Informação

1.1.2.- As Diferenças – Conhecimento vs Sabedoria

1.1.3.- Conceitos Fundamentais em Sistemas

1.1.4.- Actividades no Sistema de Informação

1.1.5.- Sistemas de Informação vs Sistemas de Informação Gerenciais

1.1.6.- Dimensões do Sistema Informação

dispositivos de entrada, saída e armazenagem; e os dispositivos de telecomunicação que interliga

O software consiste em instruções detalhadas e pré-programadas que controlam e coordenam os

Os sistemas de informação podem ser classificados de diferentes formas consoante:

1.2.2.- Sistemas de Apoio Gerencial

1.2.3.- Sistemas Transacionais (ST)

Tem como principais Objetivos:

1.2.4.- Sistema de Informações Gerenciais (SIG)

Tem como principais Objetivos:

1.2.5.- Sistema de Apoio à Decisão (SAD)

As suas principais características são:

à decisão devem acompanhar as tendências, sendo mais flexíveis e adaptáveis a mudanças;

É preciso ter presente que a principal consequência da integração de sistemas é a

Como Objectivos e Factores de Necessidade podemos apontar:

1.2.6.- Sistemas de Informação Executivo (SIE)

Tem como principal Objectivo:

As suas principais características são

-Sistemas de Automatização de Escritórios: aplicações que ajudam no trabalho

“Um sistema de informação é o conjunto de hardware e software, procedimentos, documentação,

1.3.- Objetivos organizacionais dos Sistemas de Informação

- Novos Produtos Serviços e Modelos de Negócio

- Melhor Tomada de Decisões

Em jeito de conclusão um Sistema de Informação (SI) tem como objetivos centrais:

- Ajudar a empresa a reduzir custos, a aumentar a

Um bom Sistema de Informação pode inclusive ter

Os principais objectivos da análise de sistemas são:

1.4.2.- Papel do Analista de Sistema de Informação

O papel do Analista de Sistemas passa pelo:

O Analista de Sistemas deve fazer reuniões regulares com os utilizadores (clientes/proprietários).

19 Classificação por tipo de função do Analista de Sistema:

Outras Funções do Analista de Sistema:

O Analista de Sistemas desempenha as seguintes funções:

Outras Funções e Características

devem ser modificados.

- Programador: responsável por codificar e testar (usando uma linguagem de programação) os

- Operador: é a pessoa encarregada de operar os computadores, da rede, da segurança do

Principais Problemas no desenvolvimento de sistemas:

No desenvolvimento de sistemas, podemos seguir

Algumas dessas metodologias são:

2.(1/2).1.- Metodologia de Desenho Estruturado de Yourdon

2.(1/2).2.- Metodologia de Desenho de Jackson

Dados - Descreve cada input como uma estrutura hierárquica.

Em vez da decomposição funcional, ou da abstração de procedimentos, que são características

Usa três diagramas para descrever o desenho do programa:

2.(1/2).3.- Metodologia de Desenho de Warnier-Orr

2.(1/2).4.- Engenharia de Informação

São características básicas desta classe de metodologia:

Resumo dos benefícios da Engenharia da Informação:

3.1.2.- Vantagens Diagramas de fluxo de dados (DFD)

3.1.2.- Características Diagramas de fluxo de dados (DFD)

- Mostram os fluxos de dados através do sistema e deste com o exterior.

3.1.3.- Desvantagens ou Limitações Diagramas de fluxo de dados (DFD)

3.1.4.- Convenções a usar na construção de Diagrama de Fluxo de Dados