APOSTILA BANCO DE DADOS

Prévia do material em texto

CENTRO DE CULTURA TÉCNICA DE IPATINGA LTDA 
Rua Potiguar, 150 – Bairro Iguaçu – Ipatinga – MG 
CEP 35162-110 – FONE: 3826-5198 
 
FACULDADE PEREIRA DE FREITAS 
Licenciatura em Matemática – Portaria MEC nº 4010 – D. O. U. 22/11/2005 
Licenciatura em Letras – Portaria MEC nº 4009 – D. O. U. 22/11/2005 
Bacharelado em Sistemas de Informação – Portaria MEC nº 2640 – D. O. U. 20/09/2002 
 
Banco de Dados 
 
 
Terceiro Período
 
Faculdades Doctum – Sistemas de Informação Página 2
Introdução 6 
Objetivos gerais 7 
Plano Geral do Curso 8 
APRESENTAÇÃO ...........................................................................................................................................................9 
Módulo 1: Conceitos básicos 10 
VISÃO GERAL ............................................................................................................................................................11 
O QUE É A ANÁLISE DE SISTEMAS ...............................................................................................................................12 
Análise ..................................................................................................................... 12 
Análise de Sistemas ................................................................................................. 12 
Conceito de Sistemas .............................................................................................. 12 
Tipos de Sistemas .................................................................................................... 13 
BREVE HISTÓRICO ......................................................................................................................................................15 
PROBLEMAS ENCONTRADOS NO DESENVOLVIMENTO DE SISTEMAS ...........................................................................15 
A Produtividade ...................................................................................................... 16 
A Confiabilidade ..................................................................................................... 16 
A Manutenibilidade ................................................................................................. 16 
A Eficiência ............................................................................................................. 16 
A Portabilidade ........................................................................................................ 16 
A Segurança ............................................................................................................ 16 
REVISÃO ....................................................................................................................................................................18 
Módulo 2: O ciclo de vida dos sistemas 19 
VISÃO GERAL ............................................................................................................................................................20 
DEFINIÇÃO DO CICLO DE VIDA DO SISTEMA ................................................................................................................21 
O Ciclo De Vida De Projeto Estruturado ................................................................ 22 
Levantamento .............................................................................................................................................................. 22 
Propósito da análise .................................................................................................................................................... 23 
Projeto ......................................................................................................................................................................... 23 
Construção .................................................................................................................................................................. 24 
Controle De Qualidade ................................................................................................................................................ 24 
Descrição Dos Procedimentos ..................................................................................................................................... 24 
Geração De Teste De Aceitação ................................................................................................................................. 24 
Implantação ................................................................................................................................................................. 25 
Manutenção ................................................................................................................................................................. 25 
FASES DO CICLO DE VIDA ...........................................................................................................................................27 
Levantamento (Estudo Preliminar) ......................................................................... 27 
Objetivos: .................................................................................................................................................................... 27 
Passos para Implementação: ........................................................................................................................................ 27 
Técnicas Utilizadas ..................................................................................................................................................... 27 
Produtos Gerados: ....................................................................................................................................................... 27 
ANÁLISE (REPRESENTAÇÃO DA SOLUÇÃO, PROJETO LÓGICO) .....................................................................................28 
Objetivos ................................................................................................................. 28 
Passos para Implementação..................................................................................... 28 
Técnicas Utilizadas ..................................................................................................................................................... 28 
Produtos Gerados ........................................................................................................................................................ 28 
REVISÃO ....................................................................................................................................................................29 
Módulo 3: Ferramentas para definição do ambiente 30 
VISÃO GERAL ............................................................................................................................................................31 
FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS ............................................................................32 
Declaração dos objetivos ........................................................................................ 32 
Diagrama de Contexto ............................................................................................. 32 
 
Faculdades Doctum – Sistemas de Informação Página 3
Lista De Eventos ..................................................................................................... 33 
Diagrama de entidade e relacionamento - DER ...................................................... 35 
Diagrama De Transição De Estados (Dte) .............................................................. 35 
Exemplo de DTE ......................................................................................................................................................... 36 
Elaboração Do Diagrama De Transição De Estados ...................................................................................................disponíveis, consultará, em outro arquivo, se o crédito do cliente é 
bom e fará com que o remédio solicitado seja encaminhado ao cliente com a 
respectiva fatura. 
Demostraremos isso de forma gráfica usando um diagrama de Fluxo de dados 
lógico. 
 
 
 
Analisando a figura, verificamos que, na verdade, ela nos diz muito pouco sobre o 
sistema. 
Os símbolos constantes da figura e os conceitos que representam encontram-se 
no nível lógico; um fluxo de dados pode estar fisicamente numa carta, numa fatura, 
numa ligação telefônica, etc., ou seja, em qualquer lugar em que o dado passe de 
uma entidade ou processo para outro. Um processo pode ser fisicamente um 
escritório repleto de pessoas verificando e recebendo pedidos, calculando 
descontos, ou um programa, ou ainda uma combinação de atividades manuais e 
automatizadas. Um depósito de dados pode ser um armário de aço com gavetas, 
um fichário de cartões, uma fita magnética, um disquete. Utilizando os quatro 
símbolos, podemos desenhar um quadro do sistema sem nos comprometermos 
com sua implementação. 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 40
Vamos expandir “processar pedidos” para mostrar as funções lógicas que compõe 
o processo. 
Observe o diagrama a seguir, onde representamos uma expansão do anterior, 
demostrando os processos “Verificar validade dos pedidos” e “Preparar requisição 
par o laboratório”, além de depósitos de dados para armazenar dados de clientes, 
dados de laboratórios e dados dos pedidos pendentes, ou seja, aqueles que ficam 
aguardando a quantidade ótima para endereçarmos o pedido ao laboratório 
obtendo o maior desconto. 
 
 
 
Até aqui, parece tudo bem. Mas será que vamos atender os pedidos e esperar 
pacientemente que o pagamento seja efetuado? E os laboratórios fornecedores 
não irão cobrar nunca os medicamentos remetidos? E se os medicamentos e 
quantidades remetidas pelos laboratórios não forem coerentes com as 
solicitações? 
Vamos tentar incluir o aspecto “Comparar remessa a pedidos”. 
 
Observe o próximo diagrama. 
 
 
 
 
Não demostraremos até aqui os movimentos dos remédios em si; para efeitos 
didáticos, os remédios são considerados dados e por isso não são representados 
no DFD. A relação entre um DFD e um diagrama de fluxo de materiais não será 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 41
abordada por enquanto. Atualmente só nos interessam os itens que representam 
dados sobre remédios. 
Até agora, ninguém recebeu nenhum pagamento. Devemos nos preocupar com a 
remessa de faturas para os clientes, tratamento a ser aplicado aos pagamentos 
efetuados pelos clientes, bem como cobranças efetuadas pelos laboratórios. 
Acreditamos que, com o que já foi visto até aqui, você seria capaz, sozinho, de 
expandir nosso DFD, contemplando esses processos. 
Não se esqueça que cada uma das caixas de processo pode ser expandida num 
diagrama de fluxo de dados de menor nível, assim sendo, procure, ao fazer o 
exercício proposto, não descer a detalhes muito minuciosos. Sua preocupação 
deve ser demonstrar em linhas gerais como seriam os processos de contas a 
receber e contas a pagar. 
Outro aspecto importante, não abordado nos DFD’s apresentados são as 
condições de erro. 
Não especificamos ainda o que acontece com o pedido de um cliente cuja situação 
de crédito seja ruim, ou o que acontece quando o laboratório nos manda uma 
remessa e não localizamos nenhum pedido correspondente. 
É evidente que tais situações precisam ser tratadas. Entretanto, se formos, desde 
logo, nos prender ao tratamento de erros e exceções, comprometeremos todo o 
nosso trabalho. O detalhamento dessas questões deve ser adiado para os 
diagramas de nível inferior, para que não interfiram no quadro geral do sistema. 
A conclusão dos DFD’s do sistema proposto, com toda a abrangência, fica a cargo 
de vocês, basta aplicar os recursos até aqui apresentados, observando entretanto 
as seguintes convenções simbólicas: 
 
Entidade 
 
Identificamos como entidade, na maioria das vezes, categorias lógicas de coisas 
ou pessoas que representam uma origem ou destino de transações (Clientes, 
Fornecedores, Empregados, Etc.). Também podemos identificar como Entidades 
fontes ou destinos específicos tais como Departamentos da empresa, Receita 
Federal, Almoxarifado. É comum adotarmos a terminologia Entidade Externa. 
Quando um sistema recebe dados resultantes de outro, ou gera informações que 
servirão como dados de entrada para outro, esse outro sistema também é 
identificado como uma Entidade Externa. 
O símbolo utilizado para representar já foi apresentado a você. 
Por convenção, a fim de simplificar as referências e o processo de “dicionarização” 
dos dados, adicionamos como identificador de uma entidade uma letra minúscula 
no canto superior esquerdo do desenho ou a letra E maiúscula e um número, 
conforme abaixo: 
 
Fluxo de Dados 
Podemos associar cada fluxo de dados com um tubo por onde passam pacotes de 
dados. Faremos referência ao Fluxo de Dados identificando os processos, 
entidades ou depósitos de dados das suas extremidades, anotando uma descrição 
do seu conteúdo ao longo de sua extensão. Lembre-se que a descrição deve ser 
mais clara possível, de modo a simplificar o trabalho do usuário que irá realizar a 
revisão do DFD. 
Observe um exemplo de referência e descrição de Fluxo de Dados: 
 
 
 
 
 
 
 
 
 
 
 
 c 
 
Gerência 
 
29 
Analisar 
Vendas 
Relatório de Vendas 
 Referência do Fluxo de dados 29 - C 
 Descrição do fluxo de dados: Relatório de Vendas 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 42
 
 
 
 
 
 
Processo 
Logicamente, é necessário descrever a função de cada processo, e, para facilitar 
atribuir uma identificação única para cada um, buscando, na medida do possível, 
associá-lo a um sistema físico. 
A identificação pode ser um número, inicialmente posicionado na posição média 
superior da figura, não tendo nenhum outro significado além de identificar o 
processo. Não há porque vincularmos a identificação com a descrição do 
processo, pois alguns deles serão subdivididos em dois ou mais nas fases de 
expansão - o que implicará no surgimento de novos números. Entretanto, a partir 
do instante que um processo recebe uma identificação, está não deve mais ser 
modificada, sob a pena de comprometer o trabalho de “dicionarização” dos dados, 
exceto nos casos de desmembramentos e agrupamentos. Para simplificar o 
entendimento da figura, podemos adicionar linhas divisórias, marcando claramente 
o espaço destinado à identificação do processo, sua descrição e o local físico onde 
será desempenhado. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Vale ressaltar que a descrição da função deve ser sempre imperativa, composta 
por um verbo ativo (verificar, extrair, recuperar, comparar), seguida de uma 
cláusula, simples e objetiva. 
A identificação do local físico onde a função será executa, opcional nos diagramas 
de nível mais abrangente, é extremamente útil a partir do instante em que a 
análise foi concluída e o projeto físico do sistema está sendo desenvolvido, pois 
denota o departamento ou programa que o desempenhará 
 
 
Depósito de Dados 
 
Convencionamos a identificação de um depósito de dados pela colocação de uma 
letra “D” maiúscula seguida de um número, na esquerda do desenho, separada da 
descrição por uma linha vertical. 
 
 
 
 
 
D1 Dados de Clientes 
 
Identificação do processo 
Local físico onde será 
desempenhado 
Descrição da função 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 43
 
 
 
Dicionários de Dados 
O dicionário de dados é um repositório de dados sobre os dados do software. Ele 
deveráconter a definição dos elementos que tornam o Modelo de Dados e o 
Diagrama de Fluxo de Dados precisos, quais sejam: 
- Fluxos de dados; 
- Depósitos de Dados/Entidades; 
- Atributos. 
 
Regras para Formação de Nomes 
- O nome deve ser formado por palavras separadas por sublinha até o máximo de 
32 caracteres; 
- Preferencialmente a nomeação deve ser feita de acordo com o usuário; 
- Devem ser eliminados proposições e conjunções; 
- Quando houver necessidade de abreviar uma palavra, observar que a abreviatura 
seja clara, ou inclui-la no dicionário. 
 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 44
Revisão 
 
1) O que é uma lista de eventos e quais os tipos de eventos existentes. 
 
2)Com as entidades bairros, alunos, cursos e notas monte um DER(Diagrama de 
Entidade e Relacionamento) relacionado-as. 
 
3)De acordo com a lista de eventos abaixo identifique o estímulo, a resposta, a 
saída e se o evento é temporal ou não temporal. 
 
Nº Evento Estímulo Resposta Saída Tipo 
01 Funcionário de estoque 
solicita compra do produto 
 
02 Fornecedor solicita pedido de 
cadastro 
 
03 Funcionário da loja solicita 
pedido produto 
 
04 Funcionário de estoque 
cadastra produto 
 
05 Fornecedor solicita 
encerramento ficha 
 
06 Funcionário Estoque exclui 
cadastro de produto 
 
 
 
Faculdades Doctum – Sistemas de Informação Página 45
 
Módulo 4: O Modelo de Dados 
Módulo IV - O modelo de dados 
Faculdades Doctum – Sistemas de Informação Página 46
���� Visão Geral 
 
 
 
� O que é o modelo de dados
� Componentes do modelo de dados
� Entidades
� Relacionamento
� Chaves
 
 
 
Módulo IV - O modelo de dados 
Faculdades Doctum – Sistemas de Informação Página 47
���� O que é Modelo de Dados? 
Também conhecido como Diagrama E-R (Entidade -Relacionamento ). É uma 
forma de representação gráfica do conhecimento que se tem sobre o ambiente 
(realidade) qualquer. Mostra uma visão estática das informações (entidades) de 
interesse e dos vínculos (relacionamentos) existentes entre elas. 
Modelo de DadosRealidade
Descrever
Define
 
 
O modelo de dados é uma nova forma de comunicação entre o técnico de 
processamento de dados e o usuário. 
Essa nova forma de comunicação assegurará que : 
• modelo de dados conterá todos os dados necessários para suportar os 
processos de responsabilidade do usuário. 
• modelo de dados conterá os dados para suportar processos que serão 
modificados ou introduzidos em um futuro próximo. 
Componentes do Modelo de Dados 
Entidade 
É algo, real ou abstrato, percebido no ambiente e sobre o qual nos interessa 
armazenar dados. 
Entidade são objetos(coisas) modeladas em função dos papéis que desempenham 
em um sistema específico. 
Uma única entidade pode desempenhar papéis diferentes em sistemas diferentes 
ou até em um mesmo sistema. 
 
PESSOA: Prefeitura -- Contribuinte 
 Banco -- Cliente 
 Escola -- Aluno 
 Escola -- Professor 
 Corretora -- Inquilino 
 
Coisas Tangíveis Avião, casa, etc. 
Funções Médico, paciente, inquilino, departamento,etc 
Incidentes Vôo, acidente, chamada serviços, ,etc(ocorrência ou fato) 
Interações Compra, casamento, etc (contrato) 
 
Exemplos: 
• Um objeto real (concreto)- Um equipamento, Material 
• Uma pessoa 
Módulo IV - O modelo de dados 
Faculdades Doctum – Sistemas de Informação Página 48
• Fornecedor Empregado 
• Um conceito abstrato 
• Órgão, Cargo, Curso 
• Um evento 
• Recebimento de Material 
• Um relacionamento 
• Casamento 
 
Representação Gráfica 
Um entidade é representada num modelo de dados através de um 
retângulo. 
 
Atributo 
É um dos itens de dados que armazenamos sobre uma entidade. 
Caracteriza ou qualifica uma determinada propriedade de uma entidade. 
Exemplo: 
São atributos da entidade EMPREGADO: 
 
- MATRICULA 
- NOME 
- ENDERECO 
- CPF 
- DATA NASCIMENTO 
 
Chave de Identificação 
 
A chave de identificação de uma entidade é definida por um atributo, ou conjunto 
de atributos, cujos valores individualizam uma única ocorrência dessa entidade. 
Exemplo: 
A chave de identificação da entidade EMPREGADO é o atributo MATRICULA. 
 
Lista de Entidades 
 
É uma relação de entidades com seus respectivos atributos, utilizada para 
documentar os trabalhos de análise de dados. 
Formada pelo nome da entidade seguida da relação de atributos que compõem 
entre parênteses, e seguindo a convenção abaixo: 
- Cada atributo é separado do outro pelo sinal de adição ( + ) ; 
- O(s) atributo(s) que identificam a entidade devem estar no início da 
relação e sublinhados; 
 
MATERIAL 
 
FATURA 
 
FORNECEDOR 
Módulo IV - O modelo de dados 
Faculdades Doctum – Sistemas de Informação Página 49
- O(s) atributo(s) que ocorrem mais de uma vez (repetitivos) são 
identificados por uma inclusão entre parênteses. 
Exemplo: 
FATURA(NUMERO_FATURA + CODIGO_FATURA + (NUMERO_ITEM_FATURA 
+ CODIGO_MATERIAL + QUANTIDADE_MATERIAL + PRECO_UNITARIO + 
PRECO_ITEM_FATURA) + PRECO_TOTAL_FATURA). 
Obs.: Podem haver múltiplos níveis de repetição. 
 
Domínio 
São os possíveis valores que um atributo pode assumir. 
Exemplo: 
SEXO = [ M | F ] 
Sexo pode assumir dos valores M (Masculino) ou F (Feminino) 
Ocorrência 
Representa o número vezes que determinado atributo aparece em outra entidade. 
Representação Gráfica 
 
Símbolos especiais colocados nas extremidades da linha que representa um 
relacionamento. 
Exemplo: 
 
• Uma ÁREA LOTAÇÃO tem obrigatoriamente pelo menos 1 empregado; 
• Um EMPREGADO está vinculado obrigatoriamente a uma área de LOTAÇÃO; 
• Um EMPREGADO pode ter vários, um ou nenhum DEPENDENTE; 
• Um DEPENDENTE (se existir) está obrigatoriamente vinculado a um 
EMPREGADO. 
• Um EMPREGADO pode ser GERENTE. 
• Um GERENTE é um EMPREGADO 
UMA OCORRÊNCIA OU 
NENHUMA 
UMA E SOMENTE UMA 
OCORRÊNCIA 
VÁRIAS, UMA OU 
NENHUMA OCORRÊNCIA 
PELO MENOS UMA 
OCORRÊNCIA 
DEPENDENT
E 
EMPREGADO 
AREA 
LOTACAO 
NIVEL 
SALARIAL EMPREGADO 
 
GERENTE 
Módulo IV - O modelo de dados 
Faculdades Doctum – Sistemas de Informação Página 50
• Um EMPREGADO tem obrigatoriamente um NÍVEL SALARIAL; 
• Em um mesmo NÍVEL SALARIAL podemos ter vários, um ou nenhum 
EMPREGADO. 
Tipos de Entidade 
Entidade Primária 
É aquela cuja chave de identificação é feita exclusivamente através de seus 
atributos. 
 
Entidade Dependente 
É aquela cuja existência depende de outra, ou seja, parte da chave de 
identificação da entidade está condicionada a da entidade da qual ela depende. 
 
Entidade Associativa 
É aquela cuja chave de identificação é obtida através da concatenação das chaves 
de identificação das entidades que ela associa. 
Tipos de Relacionamento 
Relacionamento é uma abstração de um conjunto de associações entre diferentes 
coisas do mundo real. 
Associações montadas entre duas ou mais entidades. 
Uma ocorrência de um relacionamento liga ocorrências específicas das entidades 
participantes. 
 
Entidade Relacionamento Entidade 
Pessoa vive em apartamento 
Inquilino aluga apartamento 
Satélite viaja em órbita 
 
Relacionamento de Dependência 
 
É aquele feito entre uma entidade e outra que dela seja dependente. 
 
Relacionamento Associativo 
 
É aquele que ocorre entre uma entidade associativa e a cada uma das entidades 
que participam da associação. 
 
Categoria 
 
Uma categoria é uma ligação entre uma entidade e suas espécies (tipos), sendo 
estas mutuamente excludentes.Partição 
 
É um caso particular de categoria, na qual as espécies (tipos) de uma entidade, 
não são mutuamente excludentes. 
 
Relacionamento Normal 
É aquele que não pode ser enquadrado em um dos tipos abaixo: 
-associativo 
-Dependência 
- Categoria 
- Partição 
Auto-Relacionamento 
 
Módulo IV - O modelo de dados 
Faculdades Doctum – Sistemas de Informação Página 51
É aquele que ocorre entre uma mesma entidade. 
 
Múltiplos Relacionamentos 
 
Casos em que ocorre mais de um relacionamento entre duas mesmas entidades. 
 
Relacionamento Mutuamente Exclusivo 
 
Ocorre quando temos um relacionamento, por exemplo, entre as entidades “A” e 
“C” e também entre as entidades “B” e “C”, porém nunca ao mesmo tempo. 
Tipos de Chave 
Chaves Candidatas 
 
São as possíveis chaves de identificação de uma única ocorrência de uma 
entidade. 
Exemplo 
EMPREGADO (MATRICULA + NOME + CPF + ENDERECO + SALARIO ) 
São chaves candidatas os atributos: 
- MATRICULA 
- CPF 
 
Chave Primária 
É uma das chaves candidatas, selecionada por melhor conveniência (facilidade de 
utilização, menor possibilidade de erros, etc. ...). 
Exemplo 
EMPREGADO (MATRICULA + NOME + CPF + ENDERECO + SALARIO ) 
Chaves candidatas: 
- MATRICULA 
- CPF 
Chave Primária escolhida - MATRICULA 
Chave Estrangeira 
Conjunto de um ou mais atributos de uma entidade que são chave primária em 
outra entidade. 
Exemplo: 
 
EMPREGADO ( MATRICULA + NOME + CPF + COD_DEPTO) 
DEPARTAMENTO (COD_DEPTO + NOME_DEPTO) 
a entidade EMPREGADO o atributo “COD_DEPTO” é chave estrangeira. 
EMPREGADO 
 
DEPARTAMENTO 
Módulo IV - O modelo de dados 
Faculdades Doctum – Sistemas de Informação Página 52
Exercícios 
 
1)Fazer um modelo de dados para o seguinte contexto: 
 
O clube Filadélfia oferece várias modalidades de esportes aos seus associados e 
tem um big restaurante, além de sauna, pedalinho, quadras cobertas, etc. 
 Um mesmo sócio pode ter vários dependentes e tanto os sócios quanto 
seus dependentes podem se inscrever nas várias modalidades de esportes que o 
clube oferece, podendo freqüentar vários simultaneamente. 
 É emitido um carnet para pagamento mensal. 
 O restaurante do Filadélfia também emite notas de cobrança de consumo 
para cada associado com os vários itens, cada item tem o produto consumido, 
data do consumo e valor. 
 
 
2)A Escola Técnica JK nos solicitou um sistema de controle acadêmico e nos 
foram passadas as seguintes informações: 
 
• Os alunos se inscrevem em cursos(o aluno só pode fazer um curso de cada 
vez) 
• Os cursos tem disciplinas (podendo um curso ter várias disciplinas e uma mesma 
disciplina estar em mais de um curso). 
• Os professores lecionam disciplinas.( uma mesma disciplina pode ser lecionada 
por vários professores) 
• Alguns professores coordenam cursos 
• Cada disciplina tem sua carga horária semanal. 
 
Faça o modelo de dados(DER) de acordo com as informações passadas acima. 
 
 
3)Faça o Modelo de Dados para a seguinte situação: 
 
A Escola Técnica JK se divide em departamentos e cada departamento 
desenvolve projetos próprios. Cada projeto pode ser orientado por um ou mais 
professores e às vezes têm vários alunos que se dedicam aos projetos, mas tanto 
os alunos como os professores não podem trabalhar em mais de um projeto ao 
mesmo tempo. Os projetos também são vinculados a disciplinas( uma ou mais). 
Os alunos se matriculam em um curso por vez, cursos estes que pertencem aos 
departamentos. As disciplinas fazem parte dos cursos, podendo uma disciplina 
estar em vários cursos. 
 Professores dirigem departamentos e sempre lecionam uma ou mais 
disciplinas, sendo que uma disciplina pode ser lecionada por mais de um 
professor. 
 
Faculdades Doctum – Sistemas de Informação Página 53
Módulo 5. Projeto de BD utilizando o 
modelo Entidade Relacionamento 
(ER) 
 
Faculdades Doctum – Sistemas de Informação Página 54
 
O modelo Entidade-Relacionamento é um modelo de dados conceitual de alto 
nível, cujos conceitos foram projetados para estar o mais próximo possível da 
visão que o usuário tem dos dados, não se preocupando em representar como estes 
dados estarão realmente armazenados. O modelo ER é utilizado principalmente 
durante o processo de projeto de banco de dados. 
���� Modelo de Dados Conceitual de Alto Nível 
A figura 4 faz uma descrição simplificada do processo de projeto de um banco de 
dados. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4: Fases do Projeto de um Banco de Dados 
Mini-Mundo 
Análise e Coleta de 
Requisitos 
Requisitos do Banco de 
Dados 
Projeto Conceitual 
Esquema Conceitual 
(Alto Nível) 
Mapeamento do 
Modelo de Dados 
Esquema Conceitual 
(Modelo do SGBD) 
Projeto Físico 
Catálogo do BD 
 
Faculdades Doctum – Sistemas de Informação Página 55
���� Entidades e Atributos 
O objeto básico tratado pelo modelo ER é a “entidade”, que pode ser definida 
como um objeto do mundo real, concreto ou abstrato e que possui existência 
independente. Cada entidade possui um conjunto particular de propriedades que a 
descreve chamado “atributos”. Um atributo pode ser dividido em diversas sub-
partes com significado independente entre si, recebendo o nome de “atributo 
composto”. Um atributo que não pode ser subdividido é chamado de “atributo 
simples” ou “atômico”. 
Os atributos que podem assumir apenas um determinado valor em uma 
determinada instância é denominado “atributo simplesmente valorado”, enquanto 
que um atributo que pode assumir diversos valores em uma mesma instância é 
denominado “multi valorado”. 
Um atributo que é gerado a partir de outro atributo é chamado de “atributo 
derivado”. 
���� Tipos e Instâncias de Relacionamento 
Além de conhecer detalhadamente os tipos entidade, é muito importante conhecer 
também os relacionamentos entre estes tipos entidades. 
Um “tipo relacionamento” R entre n entidades E1, E2, ..., En, é um conjunto de 
associações entre entidades deste tipo. Informalmente falando, cada instância de 
relacionamento r1 em R é uma associação de entidades, onde a associação inclui 
exatamente uma entidade de cada tipo entidade participante no tipo 
relacionamento. Isto significa que estas entidades estão relacionadas de alguma 
forma no mini-mundo. A figura 5 mostra um exemplo entre dois tipos entidade 
(empregado e departamento) e o relacionamento entre eles (trabalha para). Repare 
que para cada relacionamento, participam apenas uma entidade de cada tipo 
entidade, porém, uma entidade pode participar de mais do que um relacionamento. 
 
 
 
 
 
 
 
 
Figura 5: Exemplo de um Relacionamento 
���� Grau de um Relacionamento 
d3 
d2 
d1 
e7 
e6 
e5 
e4 
e3 
e2 
e1 
EMPREGADO 
Trabalha Para 
DEPARTAMENTO 
 
Faculdades Doctum – Sistemas de Informação Página 56
O “grau” de um tipo relacionamento é o número de tipos entidade que participam 
do tipo relacionamento. No exemplo da figura 5, temos um relacionamento 
binário. O grau de um relacionamento é ilimitado, porém, a partir do grau 3 
(ternário), a compreensão e a dificuldade de se desenvolver a relação corretamente 
se tornam extremamente complexas. 
���� Outras Características de um Relacionamento 
Relacionamentos como atributos 
Algumas vezes é conveniente pensar em um relacionamento como um atributo. 
Considere o exemplo da figura 5. Podemos pensar departamento como sendo um 
atributo da entidade empregado, ou empregado, como um atributo multivalorado 
da entidade departamento. Se uma entidade não possuir existência muito bem 
definida, talvez seja mais interessante para a coesividade do modelo lógico que ela 
seja representada como um atributo. 
Nomes de papéis e Relacionamentos Recursivos 
Cada tipo entidade que participa de um tipo relacionamento desempenha um papel 
particular norelacionamento. O nome do papel representa o papel que uma 
entidade de um tipo entidade participante desempenha no relacionamento. No 
exemplo da figura 5, nós temos o papel empregado ou trabalhador para o tipo 
entidade EMPREGADO e o papel departamento ou empregador para a entidade 
DEPARTAMENTO. Nomes de papéis não são necessariamente importantes 
quando todas as entidades participantes desempenham papéis diferentes. Algumas 
vezes, o papel torna-se essencial para distinguir o significado de cada participação. 
Isto é muito comum em “relacionamentos recursivos”.Um relacionamento 
recursivo é um relacionamento entre entidades do mesmo tipo entidade. Veja o 
exemplo da figura 6. 
 
 
 
 
 
 
 
 
 
 
Figura 6 - Um Relacionamento Recursivo 
e5 
e4 
e3 
e2 
e1 
EMPREGADO 
Supervisiona 
Supervisiona 
É Supervisionado 
 
Faculdades Doctum – Sistemas de Informação Página 57
No exemplo, temos um relacionamento entre o tipo entidade EMPREGADO, onde 
um empregado pode supervisionar outro empregado e um empregado pode ser 
supervisionado por outro empregado. 
Restrições em Tipos Relacionamentos 
Geralmente, os tipos relacionamentos sofrem certas restrições que limitam as 
possíveis combinações das entidades participantes. Estas restrições são derivadas 
de restrições impostas pelo estado destas entidades no mini-mundo. Veja o 
exemplo da figura 7. 
 
 
 
 
 
 
Figura 7 - Relacionamento EMPREGADO gerencia DEPARTAMENTO 
No exemplo da figura 7, temos a seguinte situação: um empregado pode gerenciar 
apenas um departamento, enquanto que um departamento, pode ser gerenciado por 
apenas um empregado. A este tipo de restrição, nós chamamos cardinalidade. A 
cardinalidade indica o número de relacionamentos dos quais uma entidade pode 
participar. A cardinalidade pode ser: 1:1, 1:N, M:N. No exemplo da figura 7, a 
cardinalidade é 1:1, pois cada entidade empregado pode gerenciar apenas um 
departamento e um departamento pode ser gerenciado por apenas um empregado. 
No exemplo da figura 5, no relacionamento EMPREGADO Trabalha Para 
DEPARTAMENTO, o relacionamento é 1:N, pois um empregado pode trabalhar 
em apenas um departamento, enquanto que um departamento pode possuir vários 
empregados. Na figura 8 temos um exemplo de um relacionamento com 
cardinalidade N:M. 
d3 
d2 
d1 
e7 
e6 
e5 
e4 
e3 
e2 
e1 
EMPREGADO 
Gerencia 
DEPARTAMENTO 
 
Faculdades Doctum – Sistemas de Informação Página 58
 
 
 
 
 
 
 
 
 
 
Figura 8 - Relacionamento N:M 
No exemplo da figura 8, nós temos que um empregado pode trabalhar em vários 
projetos enquanto que um projeto pode ter vários empregados trabalhando. 
Outra restrição muito importante é a participação. A participação define a 
existência de uma entidade através do relacionamento, podendo ser parcial ou 
total. Veja o exemplo da 
figura 7. A participação do empregado é parcial pois nem todo empregado gerencia 
um departamento, porém a participação do departamento neste relacionamento é 
total pois todo departamento precisa ser gerenciado por um empregado. Desta 
forma, todas as entidades do tipo entidade DEPARTAMENTO precisam participar 
do relacionamento, mas nem todas as entidade do tipo entidade EMPREGADO 
precisam participar do relacionamento. Já no exemplo da figura 5, ambas as 
participações são totais pois todo empregado precisa trabalhar em um 
departamento e todo departamento tem que ter empregados trabalhando nele. 
Estas restrições são chamadas de restrições estruturais. 
Algumas vezes, torna-se necessário armazenar um atributo no tipo relacionamento. 
Veja o exemplo da figura 7. Eu posso querer saber em que dia o empregado passou 
a gerenciar o departamento. É difícil estabelecer a qual tipo entidade pertence 
atributo, pois o mesmo é definido apenas pela existência do relacionamento. 
Quando temos relacionamentos com cardinalidade 1:1, podemos colocar o atributo 
em uma das entidades, de preferência, em uma cujo tipo entidade tenha 
participação total. No caso, o atributo poderia ir para o tipo entidade departamento. 
Isto porque nem todo empregado participará do relacionamento. Caso a 
cardinalidade seja 1:N, então podemos colocar o atributo no tipo entidade com 
participação N. Porém, se a cardinalidade for N:M, então o atributo deverá mesmo 
ficar no tipo relação. Veja o exemplo da figura 8. Caso queiramos armazenar 
quantas horas cada empregado trabalhou em cada projeto, então este deverá ser um 
atributo do relacionamento. 
Tipos Entidades Fracas 
p3 
p2 
p1 
e4 
e3 
e2 
e1 
EMPREGADO 
Trabalha Em 
PROJETO 
 
Faculdades Doctum – Sistemas de Informação Página 59
Alguns tipos entidade podem não ter um atributo chave por si só. Isto implica que 
não poderemos distinguir algumas entidades por que as combinações dos valores 
de seus atributos podem ser idênticas. Estes tipos entidade são chamados entidades 
fracas. As entidades deste tipo precisam estar relacionadas com uma entidade 
pertencente ao tipo entidade proprietária. Este relacionamento é chamado de 
relacionamento identificador. Veja o exemplo da figura 9. 
 
 
 
 
 
 
 
Figura 9 - Relacionamento com uma Entidade Fraca (Dependente) 
O tipo entidade DEPENDENTE é uma entidade fraca pois não possui um método 
de identificar uma entidade única. O EMPREGADO não é uma entidade fraca pois 
possui um atributo para identificação (atributo chave). O número do RG de um 
empregado identifica um único empregado. Porém, um dependente de 5 anos de 
idade não possui necessariamente um documento. Desta forma, esta entidade é um 
tipo entidade fraca. Um tipo entidade fraca possui uma chave parcial, que 
juntamente com a chave primária da entidade proprietária forma uma chave 
primária composta. Neste exemplo: a chave primária do EMPREGADO é o RG. A 
chave parcial do DEPENDENTE é o seu nome, pois dois irmãos não podem ter o 
mesmo nome. Desta forma, a chave primária desta entidade fica sendo o RG do pai 
ou mãe mais o nome do dependente. 
���� Diagrama Entidade Relacionamento 
O diagrama Entidade Relacionamento é composto por um conjunto de objetos 
gráficos que visa representar todos os objetos do modelo Entidade Relacionamento 
tais como entidades, atributos, atributos chaves, relacionamentos, restrições 
estruturais, etc. 
O diagrama ER fornece uma visão lógica do banco de dados, fornecendo um 
conceito mais generalizado de como estão estruturados os dados de um sistema. 
DEPENDENTE 
p3 
p2 
p1 
e2 
e1 
EMPREGADO 
Possui Dependentes 
 
Faculdades Doctum – Sistemas de Informação Página 60
Os objetos que compõem o diagrama ER estão listados a seguir, na figura 11. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 11- Objetos que Compõem o Diagrama ER 
���� Modelo Entidade Relacionamento Estendido 
Os conceitos do modelo Entidade Relacionamento discutidos anteriormente são 
suficientes para representar logicamente a maioria das aplicações de banco de 
dados. Porém, com o surgimento de novas aplicações, surgiu também a 
necessidade de novas semânticas para a modelagem de informações mais 
complexas. O modelo Entidade Relacionamento 
Estendido (ERE) visa fornecer esta semântica para permitir a representação de 
informações complexas. É importante frisar que embora o modelo ERE trate 
classes e subclasses, ele não possui a mesma semântica de um modelo orientado a 
objetos. 
O modelo ERE engloba todos os conceitos do modelo ER mais os conceitos de 
subclasse, superclasse, generalização e especialização e o conceito de herança de 
atributos. 
TIPO 
ENTIDADE 
TIPO ENTIDADE 
FRACA 
TIPO 
RELACIONAMENTO 
TIPO 
RELACIONAMENTO 
IDENTIFICADOR 
ATRIBUTO 
ATRIBUTO 
CHAVE 
ATRIBUTO 
MULTI 
VALORADO 
ATRIBUTO 
COMPOSTO 
ATRIBUTO 
DERIVADO 
E1 E2 R E1 E2 R 
1 N 
Participação Parcial de E1 em R, 
Participação Total de E2 em R 
Taxa de Cardinalidade 1:N 
para E1:E2em R 
R E1 
(min, max) 
Restrição Estrutural (min,max) na 
Participação de E1 em R 
 
Faculdades Doctum – Sistemas de Informação Página 61
Subclases, Superclases e Especializações 
O primeiro conceito do modelo ERE que será abordado é o de subclasse de um 
tipo entidade. Como visto anteriormente, um tipo entidade é utilizado para 
representar um conjunto de entidades do mesmo tipo. Em muitos casos, um tipo 
entidade possui diversos subgrupos adicionais de entidades que são significativas e 
precisam ser representadas explicitamente devido ao seu significado à aplicação de 
banco de dados. Leve em consideração o seguinte exemplo: 
Para um banco de dados de uma empresa temos o tipo entidade empregado, 
o qual possui as seguintes características: nome, rg, cic, número funcional, 
endereço completo (rua, número, complemento, cep, bairro, cidade), sexo, 
data de nascimento e telefone (ddd e número); caso o(a) funcionário(a) seja 
um(a) engenheiro(a), então deseja-se armazenar as seguintes informações: 
número do CREA e especialidade (Civil, Mecânico, Elétro/Eletrônico); caso 
o(a) funcionário(a) seja um(a) secretário(a), então deseja-se armazenar as 
seguinte informações: qualificação (bi ou tri língue) e os idiomas no qual 
possui fluência verbal e escrita. 
 Se as informações número do CREA, especialidade, tipo e idiomas forem 
representadas diretamente no tipo entidade empregado estaremos representando 
informações de um conjunto limitados de entidades empregado para os todos os 
funcionários da empresa. Neste caso, podemos criar duas subclasses do tipo 
entidade empregado: engenheiro e secretária, as quais irão conter as informações 
acima citadas. Além disto, engenheiro e secretária podem ter relacionamentos 
específicos. 
Uma entidade não pode existir meramente como componente de uma subclasse. 
Antes de ser componente de uma subclasse, uma entidade deve ser componente de 
uma superclasse. Isto leva ao conceito de herança de atributos; ou seja, a 
subclasse herda todos os atributos da superclasse. Isto porque a entidade de 
subclasse representa as mesmas características de uma mesma entidade da 
superclasse. Uma subclasse pode herdar atributos de superclasses diferentes. 
 
Faculdades Doctum – Sistemas de Informação Página 62
A figura 12 mostra a representação diagramática do exemplo acima. 
 
 
 
 
 
 
 
 
 
 
Figura 12 - Representação de Superclasse e Subclasses 
Especialização 
Especialização é o processo de definição de um conjunto de classes de um tipo 
entidade; este tipo entidade é chamado de superclasse da especialização. O 
conjunto de subclasses é formado baseado em alguma característica que distinga as 
entidades entre si. 
No exemplo da figura 12, temos uma especialização, a qual podemos chamar de 
função. Veja agora no exemplo da figura 13, temos a entidade empregado e duas 
especializações. 
 
 
 
 
 
 
 
 
 
Figura 13 - Duas Especializações para Empregado: Função e Categoria Salarial 
Engenheiro 
Empregado 
Secretária 
nome dt. nasc. 
no. funcional 
rg 
sexo 
endereço 
No registro 
especialização 
qualificação 
idiomas 
d 
Função 
Empregado 
Engenheiro Secretária Horista Mensalista 
d d 
Função Categoria Salarial 
 
Faculdades Doctum – Sistemas de Informação Página 63
Como visto anteriormente, uma subclasse pode ter relacionamentos específicos 
com outras entidades ou com a própria entidade que é a sua superclasse. Veja o 
exemplo da figura 14. 
 
 
 
 
 
 
 
 
 
Figura 14 - Relacionamentos Entre Subclasses e Entidades 
O processo de especialização nos permite: 
• definir um conjunto de subclasses de um tipo entidade; 
• associar atributos específicos adicionais para cada subclasse; 
• estabelecer tipos relacionamentos específicos entre subclasses e outros 
tipos entidades. 
Generalização 
A generalização pode ser pensada como um processo de abstração reverso ao da 
especialização, no qual são suprimidas as diferenças entre diversos tipos entidades, 
identificando suas características comuns e generalizando estas entidades em uma 
superclasse 
 
 
 
 
 
 
Figura 15 - Tipos Entidades Engenheiro e Secretária 
 
Engenheiro Secretária 
No registro 
especialização 
qualificação 
idiomas 
no. funcional 
nome nome rg rg 
no. funcional 
Engenheiro 
Empregado 
Secretária 
Projeto 
participa 
é desenvolvido 
por N 
N 
lidera 1 
é liderado 
N 
 d 
Função 
 
Faculdades Doctum – Sistemas de Informação Página 64
 
 
 
 
 
 
 
 
 
Figura 16 - Generalização Empregado para os Tipos Entidades Engenheiro e 
Secretária 
É importante destacar que existe diferença semântica entre a especialização e a 
generalização. Na especialização, podemos notar que a ligação entre a superclasse 
e as subclasses é feita através de um traço simples, indicando participação parcial 
por parte da superclasse. Analisando o exemplo da figura 12, é observado que um 
empregado não é obrigado a ser um engenheiro ou uma secretária. Na 
generalização, podemos notar que a ligação entre a superclasse e as subclasses é 
feita através de um traço duplo, indicando participação total por parte da 
superclasse. Analisando o exemplo da figura 16, é observado que um empregado é 
obrigado a ser um engenheiro ou uma secretária. 
A letra d dentro do círculo que especifica uma especialização ou uma 
generalização significa disjunção. Uma disjunção em uma especialização ou 
generalização indica que uma entidade do tipo entidade que representa a 
superclasse pode assumir apenas um papel dentro da mesma. Analisando o 
exemplo da figura 13. Temos duas especializações para a superclasse Empregado, 
as quais são restringidas através de uma disjunção. Neste caso, um empregado 
pode ser um engenheiro ou uma secretária e o mesmo pode ser horista ou 
mensalista. 
Além da disjunção podemos ter um “overlap”, representado pela letra o. No caso 
do “overlap”, uma entidade de uma superclasse pode ser membro de mais que uma 
subclasse em uma especialização ou generalização. Analise a generalização no 
exemplo da figura 17. Suponha que uma peça fabricada em uma tornearia pode ser 
manufaturada ou torneada ou ainda, pode ter sido manufaturada e torneada. 
 
 
 
 
Engenheiro 
Empregado 
Secretária 
nome 
no. funcional 
rg 
no registro 
especialização 
qualificação 
idiomas 
d 
Função 
 
Faculdades Doctum – Sistemas de Informação Página 65
 
 
 
 
 
 
 
 
 
Figura 17 - Uma Generalização com “Overlap” 
Manufaturada 
Peça 
Torneada 
Descrição 
no. da peça 
Data 
Ordem Serviço 
No. Projeto 
Preço 
 o 
 
Faculdades Doctum – Sistemas de Informação Página 66
“Lattice” ou Múltipla Herança 
Uma subclasse pode ser definida através de um “lattice”, ou múltipla herança, ou 
seja, ela pode ter diversas superclasses, herdando características de todas. Leve em 
consideração o seguinte exemplo: 
Uma construtora possui diversos funcionários, os quais podem ser 
engenheiros ou secretárias. Um funcionário pode também ser assalariado 
ou horista. Todo gerente de departamento da construtora deve ser um 
engenheiro e assalariado. 
O modelo lógico da expressão acima tem o seguinte formato: 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 18 - Um “Lattice” com a Subclasse Gerente Compartilhada 
Neste caso então, um gerente será um funcionário que além de possuir as 
características próprias de Gerente, herdará as características de Engenheiro e de 
Mensalista. 
Empregado 
Secretaria Engenheiro Mensalista Horista 
d d 
Função Categoria Salarial 
Gerente 
 
Faculdades Doctum – Sistemas de Informação Página 67
Revisão 
1)O que é Relacionameno Recursivo e dê exemplo de um. 
 
2)O que é um relacionamento Parcial e dê um exemplo. 
 
3)O queé Entidade Fraca. 
 
4)O que é Relacionamento Identificador 
 
5)Dê Exemplo de uma entidade se relacionando com mais outras duas 
entidades. 
 
6)Explique com suas palavras o que é uma subclasse. 
 
7)No Modelo ERE, qual a diferença entre Especialização e Generalização. 
O que representa a letra D e a letra O dentro do círculo que especifica uma 
Especialização ou uma Generalização. 
 
8)O que significa Múltipla Herança? 
 
 
Faculdades Doctum – Sistemas de Informação Página 68
Módulo 6: Normalização 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 69 
���� Visão Geral 
 
� O que é a normalização
� Visão geral da consolidação do
modelo de dados
 
 
 
 
 
 
 
 
 
 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 70 
���� O que é Normalização ? 
 
Normalização é o processo formal que consiste em substituir um conjunto de 
entidades por outro conjunto capaz de comportar melhor as mudanças futuras. 
Entidades normalizadas não possuem redundâncias (duplicação de dados) 
acidental. Cada atributo está relacionado com sua própria entidade e não se 
mistura com atributos relativos à entidades diferentes. 
A normalização corresponde na realidade à formalização de regras baseadas no 
fato que as entidades possuem anomalias de atualização. 
 
Anomalias de Atualização 
 
Dada a entidade abaixo: 
 
PEDIDO (NUMERO_PEDIDO + DATA_PEDIDO + NUMERO_CLIENTE + 
NOME_CLIENTE + ENDERECO_CLIENTE + ( NUMERO_PRODUTO + 
NOME_PRODUTO + QTDE_PEDIDA + PRECO_PRODUTO + 
TOTAL_PRODUTO) + TOTAL_PEDIDO) 
 
Quais as anomalias de atualização que acontecerão se: 
- Um produto for descontinuado por seu fornecedor? 
- O nome do produto for mudado? 
- O cliente mudar de endereço? 
- Os produtos ou as quantidades pedidas pelo cliente forem mudadas e o cliente 
esqueceu o número do pedido? 
 
Dependência Funcional 
Dados os atributos “A” e “B” de uma entidade, diz-se que “B” é funcionalmente 
dependente de “A” se e somente se, a cada valor de “A” está associado um único 
valor de “B”. 
Em outras palavras, se conhecermos o valor de “A” então podemos encontrar o 
valor de “B” associado a ele. 
 
DIAGRAMA DE DEPENDÊNCIA FUNCIONAL 
 
A 
B 
 
Nota - a seta parte de quem identifica. 
 
Exemplo: 
 
DEPARTAMENTO 
CODIGO_DEPARTAMENTO 
NOME_DEPARTAMENTO 
SIGLA_DEPARTAMENTO 
 
 
 
 
 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 71 
Nota - O exame das relações existentes entre os atributos de uma entidade deve 
ser feito a partir do conhecimento (conceitual) que se tem sobre o mundo real 
(ambiente modelado). 
 
Dependência Funcional Composta ou Completa 
 
Dado um atributo ou um conjunto de atributos “B” de uma entidade, sendo a chave 
primária composta por um conjunto de atributos “A”, diz-se que “B” é 
completamente dependente funcional da chave primária, se e somente se, a cada 
valor da chave (e não a parte dele), está associado um valor para cada atributo do 
conjunto “B”. 
 
DIAGRAMA DE DEPENDÊNCIA FUNCIONAL 
A1 
A2 
 
B1 
B2 
B3 
 
 
Exemplo: 
PRODUTO_FATURA 
 
NUMERO_PEDIDO 
CODIGO_PRODUTO 
QTDE_PEDIDA 
PRECO_TOTAL_PRODUTO 
 
Dependência Funcional Transitiva 
Dados os atributos “A”, “B” e “C” de uma entidade, sendo “A” a chave primária, 
diz-se que “B” e “C” são dependentes transitivos se e somente se, forem 
funcionalmente dependente de “A” além de existir uma dependência funcional 
entre eles. 
 
DIAGRAMA DE DEPENDÊNCIA FUNCIONAL 
A 
B 
C 
 
 
Exemplo: 
DEPARTAMENTO 
CODIGO_DEPARTAMENTO 
NOME_DEPARTAMENTO 
SIGLA_DEPARTAMENTO 
MATRICULA_GERENTE 
NOME_GERENTE 
Primeira Forma Normal (1FN) 
Uma entidade está na 1FN se ela não contém grupos de atributos repetitivos 
(multivalorados). 
Exemplo: 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 72 
Entidade não normalizada 
PEDIDO (NUMERO_PEDIDO + DATA_PEDIDO + NUMERO_CLIENTE + 
NOME_CLIENTE + ENDERECO_CLIENTE + ( NUMERO_PRODUTO + 
NOME_PRODUTO + QTDE_PEDIDA + PRECO_PRODUTO + 
TOTAL_PRODUTO) + TOTAL_PEDIDO) 
 
 Remoção dos grupos de atributos repetitivos (1FN): 
 
NUMERO_PEDIDO 
 
DATA_PEDIDO 
NUMERO_CLIENTE 
NOME_CLIENTE 
ENDERECO_CLIENTE 
NUMERO_PRODUTO 
NOME_PRODUTO 
QTDE_PEDIDA 
PRECO_PRODUTO 
TOTAL_PRODUTO 
TOTAL_PEDIDO 
 
 
Entidades da 1FN 
 
PEDIDO (NUMERO_PEDIDO + DATA_PEDIDO + NUMERO_CLIENTE + 
NOME_CLIENTE + ENDERECO_CLIENTE + TOTAL_PEDIDO) 
 
PRODUTO_PEDIDO (NUMERO_PEDIDO + NUMERO_PRODUTO + 
NOME_PRODUTO + QTDE_PEDIDA + PRECO_PRODUTO + 
TOTAL_PRODUTO) 
 Modelo de Dados 
 
 
Segunda Forma Normal (2FN) 
Uma entidade está na 2FN se ela está na 1FN e seus atributos são funcionalmente 
dependentes de sua chave (primária) completa. 
 
Exemplo: 
Entidades da 1FN 
 
PEDIDO 
 
PRODUTO_PEDIDO 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 73 
PEDIDO (NUMERO_PEDIDO + DATA_PEDIDO + NUMERO_CLIENTE + 
NOME_CLIENTE + ENDERECO_CLIENTE + TOTAL_PEDIDO) 
 
PRODUTO_PEDIDO (NUMERO_PEDIDO + NUMERO_PRODUTO + 
NOME_PRODUTO + QTDE_PEDIDA + PRECO_PRODUTO + 
TOTAL_PRODUTO) 
 
Remoção dos atributos não funcionalmente dependentes de toda uma chave 
primária 
(2FN): 
 
PEDIDO PRODUTO_PEDIDO 
NUMERO_PEDIDO NUMERO_PEDIDO 
DATA_PEDIDO NUMERO_PRODUTO 
NUMERO_CLIENTE NOME_PRODUTO 
NOME_CLIENTE QTDE_PEDIDA 
ENERECO_CLIENTE PRECO_PRODUTO 
TOTAL_PEDIDO TOTAL_PRODUTO 
 
Entidade na 2FN 
 
PEDIDO (NUMERO_PEDIDO + DATA_PEDIDO + NUMERO_CLIENTE + 
NOME_CLIENTE + ENDERECO_CLIENTE + TOTAL_PEDIDO) 
 
PRODUTO_PEDIDO (NUMERO_PEDIDO + NUMERO_PRODUTO+ 
QTDE_PEDIDA + TOTAL_PRODUTO) 
 
PRODUTO (NUMERO_PRODUTO + NOME_PRODUTO + PRECO_PRODUTO) 
 
 
 Modelo de Dados: 
 
Terceira Forma Normal (3FN) 
Uma entidade está na 3FN se ela está na 2FN e não possui dependências 
transitivas. 
Uma entidade que está na 2FN pode ter um atributo que não é uma chave mas 
que por si identifica outros atributos. Refere-se a isto como uma dependência 
transitiva. 
 
Exemplo: 
PRODUTO 
 
PEDIDO 
 
PRODUTO 
/PEDIDO 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 74 
 
- Entidade na 2FN: 
 
PEDIDO (NUMERO_PEDIDO + DATA_PEDIDO + NUMERO_CLIENTE + 
NOME_CLIENTE + ENDERECO_CLIENTE + TOTAL_PEDIDO) 
 
PRODUTO_PEDIDO (NUMERO_PEDIDO + NUMERO_PRODUTO+ 
QTDE_PEDIDA + TOTAL_PRODUTO) 
 
PRODUTO (NUMERO_PRODUTO + NOME_PRODUTO + PRECO_PRODUTO) 
 
- Remoção das dependências transitivas 
 
PEDIDO PRODUTO_PEDIDO 
 
NUMERO_PEDIDO NUMERO_PEDIDO 
DATA_PEDIDO NUMERO_PRODUTO 
NUMERO_CLIENTE QTDE_PEDIDA 
NOME_CLIENTE TOTAL_PRODUTO 
ENDERECO_ CLIENTE 
TOTAL_PEDIDO 
 
 
 
 
PRODUTO 
 
NUMERO_PRODUTO 
NOME_PRODUTO 
PRECO_PRODUTO 
 
Entidades na 3FN 
 
PEDIDO (NUMERO_PEDIDO + DATA_PEDIDO + TOTAL_PEDIDO) 
 
CLIENTE (NUMERO_CLIENTE + NOME_CLIENTE + ENDERECO_CLIENTE) 
 
PRODUTO_PEDIDO (NUMERO_PEDIDO + NUMERO_PRODUTO + 
QTDE_PEDIDA + TOTAL_PRODUTO) 
 
PRODUTO (NUMERO_PRODUTO + NOME_PRODUTO + PRECO_PRODUTO) 
 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 75 
Modelo de Dados 
 
Simplificação do Processo de Normalização 
A partir do diagrama de dependências funcionais podemos obter diretamente as 
entidades na terceira forma normal. Paraisso, devemos especificar uma entidade 
para cada conjunto de setas que o diagrama mostrar. A chave primária será 
formada pelos atributos dos quais partem as setas. 
 
Exemplo: 
NUMERO_PEDIDO 
DATA_PEDIDO 
NUMERO_CLIENTE 
NOME_CLIENTE 
ENDERECO_CLIENTE 
NUMERO_PRODUTO 
NOME_PRODUTO 
QTDE_PEDIDA 
PRECO_PRODUTO 
TOTAL_PRODUTO 
TOTAL_PEDIDO 
 
Regras Práticas 
 Se duas entidades possuírem a mesma chave de identificação: 
 
• Elas são a mesma entidade; 
• Seus atributos se complementam; 
• As suas ocorrências se complementam; 
• Quando um atributo ou um conjunto de atributos identificadores de uma 
determinada entidade, for(em) também atributo(s) de uma outra entidade, deve 
haver um relacionamento do tipo 1:N entre elas. 
• Atributos comuns a mais de uma entidade, devem ser, obrigatoriamente, 
chaves de identificação em uma das entidades; caso contrário será uma 
simples redundância. 
PRODUTO 
 
PEDIDO 
 
PRODUTO_PEDIDO 
CLIENTE 
 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 76 
• Nenhum atributo componente de uma chave primária deve poder assumir um 
valor nulo. Decorre do fato de que todos os objetos que se quer representar 
devam ser distinguíveis entre si. 
 
Um atributo que seja chave estrangeira só pode assumir: 
 - Valor nulo; 
- Valor para o qual exista uma ocorrência da entidade da qual ela é chave 
primária. 
 
���� Visão Geral Consolidação de Modelos de Dados 
O que é Consolidação? 
Termo utilizado para representar os trabalhos de integração de um modelo de 
dados a outro ou, integração de modelos parciais a um modelo global de dados 
(empresa, assunto ou sistema). 
Trabalhos Executados na Consolidação 
Os Trabalhos da consolidação basicamente são os seguintes: 
- Adição de entidades ainda inexistentes no modelo global de dados, relacionando-
as às demais; 
- Adição de novos atributos a entidades já existentes, desde que possuam chaves 
primárias idênticas; 
- Identificação das entidades já implementadas; 
- Eliminação de relacionamentos redundantes. 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 77 
Revisão 
1)O que é chave estrangeira? 
 
2)O que é chave primária? 
 
3)O que é chave candidata? 
 
4)O que é Dependência Funcional Composta e Dependência Funcional 
Transitiva? 
 
5)Explique com suas palavras quais são as exigências para que uma entidade 
esteja na 1ª FN(Forma Normal), 2ªFN e 3ªFN. 
 
- 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 78 
Exercícios 
 
1)Faça a normalização à partir das informações abaixo, identifique as chaves de 
cada entidade e desenhe o diagrama ER para cada um dos três casos. 
 
Estudo do caso 1 
 
ORDEM DE COMPRA 
Código_Ordem_Compra 
Data_Emissão 
Código_Fornecedor 
Nome_Fornecedor 
Endereço_Fornecedor 
%Materiais da ordem de compra( grupo multivalorado) 
código_item(n) 
 descrição_item(n) 
 valor_unitário_item(n) 
 quantidade_comprada_item(n) 
 valor_total_item(n) 
valor_total_compra 
 
 
Estudo do caso2 
 
DADOS FUNCIONÁRIOS 
Matricula_Funcionário 
Nome_Funcionário 
Endereço_Funcionário 
Data_Admissao_Funcionário 
Código_Cargo 
Descrição_Cargo 
Valor_Salário 
Numero_Total_Dependentes 
Código_Departamento 
%Habilidades (grupo multivalorado) 
Código_Habilidade(n) 
Descrição_Habilidade(n) 
Data_Formação_Habilidade(n) 
%Dependentes(grupo multivalorado) 
Código_Dependente(n) 
Nome_Dependente(n) 
Data_Nascimento_Dependente(n) 
 
DADOS DEPARTAMENTO 
Código_Departamento 
Nome_Departamento 
 Localização_Departamento 
 
Módulo V – Normalização 
 
 
Escola Técnica JK – Curso de Informática Página - 79 
Estudo do caso3 
 
CIDADES 
Código_Cidade 
Nome_Cidade 
População_Cidade 
Prefeito_Atual_Cidade 
Partido_Prefeito_Atual 
%Zonas (grupo multivalorado) 
Numero_Zona(n) 
Local_Zona(n) 
Numero_Eleitores_Zona(n) 
Cabo_Eleitoral_Principal(n) 
 
 
VEREADORES 
Código_Vereador 
Nome_Vereador 
Código_Cidade 
Nome_Cidade 
Partido_Vereador 
Voto_Ultima_Eleição 
Mandato_Vereador(período) 
 
DEPUTADOS 
Código_Deputado 
Nome_Deputado 
Código_Cidade 
Nome_Cidade 
Voto_Ultima_Eleição 
Partido_Deputado 
Mandato_Deputado(período) 
Categoria_Deputado(Estadual-Federal) 
 
PRINCIPAIS SOLICITAÇÕES CIDADES 
Código_Cidade 
Nome_Cidade 
%Solicitações(grupo multivalorado) 
 Numero_Solicitação(n) 
 Descrição_Solicitação(n) 
 Data_Solicitação(n) 
 Viabilidade_Atendimento(n) 
 Órgãos_Envolvidos(n) 
 
 
 
 
 
 
Escola Técnica JK – Curso de Informática Página - 80 
2)Fomos a uma clínica médica para montarmos uma base de dados e 
conseguimos, numa primeira visita e analisando uma ficha que cada cliente 
possui, levantar a seguinte estrutura de dados: 
 
Ficha Cliente = número_cliente + 
 nome_cliente + 
 endereço_cliente + 
 CPF_cliente + 
 telefone_cliente + 
 código_convênio_cliente + 
 descrição_convênio_cliente + 
 percentual_desconto_cliente + 
 { número_dependente + 
 nome_dependente + 
 código_parentesco_dependente + 
 descrição_parentesco_dependente } + 
 { data consulta_cliente + 
 código_medico_consulta + 
 nome_médico_consulta + 
 código_especialidade_médico + 
 descrição_especialidade_médico + 
 diagnóstico_consulta } + 
 { código_exame_consulta + 
 descrição_exame_consulta + 
 resultado_exame_consulta } + 
 { mês_referência_mensalidade + 
 data_pagamento_mensalidade } 
 
Normalizar a estrutura de dados apresentada até a 3FN e identificar a chave 
em todas as estruturas na 3FN 
 
 
 
 
Escola Técnica JK – Curso de Informática Página - 81 
 
 
Módulo 7: Projeto (especificação da 
Solução para o projeto Físico) 
 
 
 
Escola Técnica JK – Curso de Informática Página - 82 
���� Visão Geral 
 
 
 
 
� Objetivos do projeto físico
� Técnicas utilizadas na elaboração do
projeto
� A construção
� A implantação
�A manutenção
�A documentação
 
 
 
 
 
Escola Técnica JK – Curso de Informática Página - 83 
Objetivos do projeto físico 
Definir a parte física do projeto, tais como hardware, banco de dados, linguagem 
de programação, etc. 
Passos para Implementação 
Definição de ambiente. 
- Hardware: equipamento, meio de armazenamento, meio de 
transmissão, periféricos. 
- Software: linguagem de programação, banco de dados, etc. 
 
Projeto físico da base de dados. 
- Definição da estrutura e organização; 
- Construção das tabelas 
 
Detalhamento dos processos. 
- Identificação das funções a serem automatizadas; 
- Construção do diagrama de blocos do sistema; 
- Construção do projeto de formulários (I/O), telas e relatórios; 
 
Definição dos mecanismos de segurança e auditoria. 
- Backups; 
- Direitos de Acesso 
 
Validação da especificação da solução 
- Revisão; 
- Apresentação; 
- Avaliação. 
 
Técnicas Utilizadas 
- DFD; 
- Diagrama de Blocos; 
- Dicionário de dados; 
- Português estruturado; 
- Entrevistas e reuniões; 
 
Produtos Gerados 
- Diagrama de blocos; 
- Dicionário de dados; 
- Telas e relatórios; 
- Banco de dados criado; 
- Manual técnico. 
Construção 
Objetivos 
- Planejamento de como será a implantação; 
- Minimizar impactos; 
 
 
 
 
 
 
Escola Técnica JK – Curso de Informática Página - 84 
 
Passos para Implementação 
 
Programação 
- Especificação de programas, definindo o objetivo do programa (fazer o 
que), os dados de entrada (a partir de que), os dados de saída (para 
onde), detalhando a lógica (como fazer) e o contexto (onde e como 
será executado); 
- Codificação: utilização de métodos estruturados para desenvolver 
programas; 
- Documentação dos programas: autor, data, objetivo, nome da 
empresa, alterações e versões; 
 
Testes.- Descobrir erros no programa/sistema; 
- Utiliza-se do auxílio do usuário; 
- Elaborar massa de testes verdadeira. 
- Elaborar testes de desempenho 
- Elaborar testes de segurança 
 
Consolidação da documentação. 
- Manual técnico; 
- Help on line; 
 
Validação do produto. 
- Revisão; 
- Apresentação; 
- Avaliação. 
 
Planejamento da implantação. 
- Treinamento dos usuários; 
- Tipo adequado de implantação (direta ou paralela); 
- Corrigir distorções 
- Fazer teste piloto; 
 
Conversão e geração da base de dados 
- Gerar tabelas; 
- Gerar índice; 
- Carga dos dados 
 
Técnicas utilizadas 
 
- Listas De Eventos; 
- Diagrama de blocos; 
- Programação estruturada; 
- Reuniões. 
Produtos Gerados 
 
- Sistema pronto; 
- Manuais: Técnico 
- Help. 
 
 
Implantação 
 
 
 
Escola Técnica JK – Curso de Informática Página - 85 
 
Objetivos: 
- Instalação do sistema; 
- Mensurar resultados da instalação; 
- Verificar operação; 
- Realizar manutenção 
 
Passos para Implementação: 
 
1. Desenvolver programa de instalação 
2. Configurar parâmetros para a instalação (arquivo SETUP) 
3. Limpar banco de dados 
4. Treinamento Final com usuário e pessoas envolvidas 
5. Verificar equipamentos e instalar o sistema 
6. Acompanhamento dos resultados do sistema implantado em relação ao 
antigo 
7. Operação. 
- Execução de rotinas; 
- Contabilização de recursos; 
- Registro e tratamento da execução; 
- Auditoria do sistema. 
 
Produtos Gerados: 
- Sistema instalado. 
 
Manutenção 
 
1. Análise das Solicitações dos Usuários: Verificação do pedido de alteração 
ou implementação feita pelo usuário. 
 
 2. Análise do Uso do Sistema: Verificação periódica da utilização, performance 
e funcionalidades do sistema, visando a sua constante otimização. 
 
 3. Alterações da Base de Dados em Ambiente de Teste e Programação: 
Procedimento da alteração da base de dados e teste , do(s) programa(s), 
tela(s) ou relatório(s) de acordo com as que foi determinado pelas análises 
explícitas nos itens A e B acima. 
 
 4. Testes 
 
 5. Alterações da Base de Dados em Ambiente de Produção: Procedimento de 
alteração da base de dados da produção. 
 
 6. Atualização da Ajuda on-line: Modificação das descrições das funções 
alteradas dentro da documentação on-line. 
 
 7. Atualização do Manual Técnico: Modificação das decisões das estruturas 
das tabelas, procedimentos e das funções alteradas, dentro do manual 
técnico. 
 
 
 
Escola Técnica JK – Curso de Informática Página - 86 
Normas e padrões de construção da documentação 
Padrões de nomenclatura 
 
1. Banco de Dados 
 
 TTTSSS.MDB 
 
TTT – Abreviatura significando ambiente de produção (PRO) ou de 
desenvolvimento (DES) 
 SSS – Sigla do Sistema 
 
 Exemplo: DESSCA.mdb (Desenvolvimento, Sistema de Controle 
Acadêmico) 
 
2. Tabelas 
 
SSS_TB_XXXXXXXXXX 
SSS – Sigla do Sistema 
TAB – Fixo, descrição de tabela 
XXXXXXXXXX – Descrição da Tabela (poderá conter n 
caracteres) 
 
 Exemplo: SCA_TB_ALUNO(Tabela de Alunos do sistema SCA) 
 
3. Nomes de Campos 
 
TTT_XXXXXXXXXX 
TTT – Abreviatura da Tabela 
XXXXX – Descrição do campo (poderá conter n caracteres) 
 Exemplo: ALU_NOME , ALU_NOTA, ALU_MATRÍCULA 
 
4. Variáveis 
 
VTTT_XXXXXXXXX 
V – Fixo 
TTT – tipo da variável 
XXXXXXXXX – Descrição do conteúdo (poderá conter n 
caracteres) 
 
Exemplos: 
 
VDAT_XXXXXXXXXX – variáveis tipo data 
VSTR_XXXXXXXXXX – variáveis tipo string 
VNUM_XXXXXXXXXX – variáveis tipo numéricas 
VMEM_XXXXXXXXXX – variáveis tipo memo 
 
5. Telas 
 
SSS_FR_XXXXXXXXXX 
SSS – Sigla do Sistema 
FR – Fixo, abreviatura de tela/formulário 
XXXXXXXXXX – Descrição da Tela 
 
 
 Exemplo: SCA_TEL_ ALUNO, SCA_TEL_NOTAS 
6. Relatórios 
 
 
 
Escola Técnica JK – Curso de Informática Página - 87 
 
SSS_RL_XXXXXXXXXX 
 
SSS – Abreviatura do Sistema 
RL – Fixo, abreviatura de relatório; 
XXXXXXXXXX – Descrição do Relatório 
 
7. Rotinas 
 
VERBO_XXXXXXXXXX 
 
VERBO – verbo no infinitivo representando a ação da rotina 
XXXXXXXXXX – Descrição da rotina 
 
 Exemplo: CADASTRAR_ALUNOS 
 
Regras Gerais 
Área de Teste e Produção 
 
Durante a fase de codificação e de manutenção deve-se usar uma área 
em disco para testes de programação e um Banco de Dados para teste, 
somente após a validação dos programas e das bases eles devem passar 
para a área de produção. 
 
Funções Genéricas 
 
Funções consideradas genéricas deverão ser documentadas e anexadas 
ao manual técnico para facilitar a utilização das mesmas em outros 
sistemas. 
 
Arquivo de Configurações 
 
Todas os módulos devem consultar uma tabela que conterá as 
configurações básicas do sistema, como: nome da empresa, path das 
bases de dados, menus de acesso. 
• A exclusão dos registros das tabelas deve ser do tipo cascata. 
• Não deve ser permitida a alteração de campos-chave. 
 
Tabelas 
• Gravar informações de endereço em campos separados. Ex.: rua, 
bairro. 
• Campos do tipo Data devem ter o formato: dd/mm/aaaa. 
• Campos de conteúdo numérico mas que não sejam usados para 
cálculo podem ser do tipo string. 
• Utilizar campos booleanos para armazenar informações de .V. ou .F. 
• Para campos que contém apenas uma posição, esta deve ser 
maiúscula. 
• Não devem ser armazenados campos com máscara. 
 
 Telas 
• O nome do sistema deve constar na Barra de Título da tela principal do 
sistema, em letras maiúsculas e minúsculas; 
• A função principal de cada tela deve estar descrita na barra de título, 
em letras maiúsculas e minúsculas; 
 
 
 
Escola Técnica JK – Curso de Informática Página - 88 
• No canto inferior esquerdo deve constar a data e hora atuais do 
sistema, no formato: data - dd/mm/aaaa e a hora - hh:mm; 
• Sempre que possível, deve-se alinhar labels e caixas de entrada de 
forma justificada para que haja preenchimento uniforme da tela; 
• Labels devem estar sempre à esquerda das caixas de entrada; 
• As caixas de entrada devem ter, no máximo, tamanho igual ao 
tamanho do campo correspondente na tabela; 
• Só devem ser formatados campos em consultas, ou quando os 
mesmo já tenham formatação pré-definida. 
• A tela principal deverá ser maximizada; 
• As demais telas: funções do sistema, help, sobre o sistema, 
mensagens, etc; devem ser menores que a principal e só terão 
habilitado o botão de fechar. 
• Fonte: Usar Arial, tamanho 8. 
• Utilizar cores amenas na criação de ícones. 
 
Menu 
 
• Utilizar menus com todas as seguintes opções: Cadastros, 
Movimentações, Relatórios, Consultas, Utilitários, Ajuda e Saída 
Botões 
 
Botões como os de: pesquisa, confirmação e saída deve constar em 
cada tela interna 
 
Mensagens 
 
• As telas de mensagem deve ser popUp (só passar para outra depois de 
fechada); 
• Utilizar símbolos como ! ou ?, de acordo com o tipo da mensagem: 
aviso ou confirmação. 
• As mensagens devem ser o mais explicativas possível, porém bastante 
sucintas. 
• Mensagens de orientação de tela ou dicas de botões devem 
representar a função a que se destinam, usando verbo no infinitivo. Ex.: 
Cadastrar Cliente, Consultar Despesas por Cliente, etc. 
 
Relatórios 
• Usar fonte Arial; 
• Cabeçalho: Negrito – tamanho 12; 
• Quebra, totalizações e título das colunas: Negrito – tamanho 12; 
• Detalhe: Normal – tamanho 10; 
• Rodapé da página: Normal – tamanho 10; 
• O tamanho da fonte pode ser alterado de acordo com o volume de 
dados a ser mostrado no relatório. 
 
 Programas 
 
- Todas as críticas de validação dos dados no banco, sempre que 
possível, deverão ficar a cargo do banco de dados; 
- Os programas deverão capturar os erros do banco, trata-los e retornar 
alguma mensagem ao usuário. 
 
 
 
Escola Técnica JK – Curso de Informática Página - 89 
- As validações a nível de formulário, deverão ser tratadas pelo 
programa, noclick do botão salvar, retornando o cursor para o campo 
invalidado no formulário. 
Lógica 
- Usar apenas um comando por linha; 
- Escrever os comandos sem abreviação; 
- Identificar comandos de laço, de repetição, de opção, etc; 
- Dividir, sempre que possível, os programas grandes em rotinas 
menores; 
- Utilizar estrutura CASE sempre que possível. 
- Fazer sempre comentários nos programas, procedures, rotinas e 
funções do sistema; 
- Fazer comentário sempre que o programa chamar outro programa, 
rotina, procedure ou função. 
- Colocar comentários antes da chamada de qualquer rotina, 
procedimento ou função ; 
- Iniciar o programa sempre com comentários: Nome do programa, 
sistema, programador, programador que efetivou a alteração, data, 
data da alteração. 
 Padrões de documentação 
Ajuda on line 
 Esquematização dos Módulos do Sistema 
a. Esquematizar os Módulos do Sistema, de forma que cada uma de suas 
funções seja um Link 
 Descrição dos Módulos do Sistema e Esquematização de suas Funções 
a. Descrever, sucintamente, o objetivo do Módulo; 
b. Esquematizar as Funções e Operações do Módulo, de forma que cada 
uma de suas funções ou operações seja um Link 
Descrição das Funções ou Operações do Módulo do Sistema 
a. Descrever, o mais detalhadamentente possível, as instruções de uso e 
operacionalização da função ou operação, inclusive com a utilização de 
exemplos. 
b. Descrever as críticas básicas dos campos de entrada. Ex. (campo 
numérico; digitação obrigatória; digitação facultativa; etc.). 
Descrição dos Relatórios 
a. Descrever o objetivo e o conteúdo do Relatório. 
b. Descrever, o mais detalhadamentente possível, as instruções de uso e 
operacionalização para a chamada do relatório, explicitando seus 
parâmetros, inclusive com a utilização de exemplos. 
c. Anexar a Copia do Relatório 
Sobre o sistema 
 Descrição do Sistema 
Descrever , o mais detalhadamentente possível, o objetivo do Sistema, 
mencionando seus principais módulos. 
 
Equipe Envolvida 
 
 
 
Escola Técnica JK – Curso de Informática Página - 90 
Informar a equipe envolvida no Sistema, agrupando por tipo de atividade. 
(Ex. Análise, Desenvolvimento; Documentação; etc.) 
Créditos 
Informar os créditos do Sistema e das funcionalidades não desenvolvidas 
pela empresa responsável pela análise, programação e documentação. 
 
Manual Técnico 
O Manual Técnico deve ser elaborado de acordo com os seguintes conteúdos: 
 
Introdução 
a. Apresentação do Manual 
 Descrição dos objetivos do Manual e identificação dos órgãos usuários. 
b. Objetivos do Sistema 
 Descrição sucinta dos objetivos do Sistema. 
c. Considerações Gerais 
 Descrição dos módulos básicos do Sistema e demais observações a 
critério do analista. 
d. Configuração Básica 
 Configuração básica necessária para o processamento do Sistema: 
• Equipamento 
• Sistema Operacional 
• Programas Utilitários 
• Memória Principal e 
• Memória Auxiliar. 
e. Instruções de Instalação 
 Descrição das instruções de instalação e configuração inicial do Sistema. 
Diagrama de Contexto 
Diagrama de contexto do Sistema. Representa as entradas e saídas 
lógicas do Sistema, bem como, identifica os órgãos usuários envolvidos 
pelo Sistema. 
Diagrama de Fluxo de Dados 
a. Nível 1 - Sistema 
 Diagrama de fluxo de dados do Sistema no 1o nível. 
b. Nível 2 - Módulos 
 Diagrama de fluxo de dados do Sistema no 2o nível. Descreve com maior 
grau de detalhamento o fluxo apresentado no nível 1, apresentando os 
módulos do Sistema. 
c. Nível 3 - Expansão 
 Diagrama de fluxo de dados do Sistema no 3o nível. Representado pela 
expansão do diagrama de dados para os processos apresentados nos 
níveis 1 e 2. 
Diagrama de Entidades e Relacionamentos 
Diagrama que descreve o modelo de entidades e seus respectivos 
relacionamentos no Sistema. 
Diagrama de Blocos 
Contem a estrutura hierárquica do Sistema, de forma modular. 
Dicionário de Dados 
a. Depósito de Dados 
 Descrição das características dos Depósitos de Dados (Tabelas) do 
Sistema de acordo com os padrões estabelecidos nesta metodologia. 
b. Processos 
 Características dos processos 
 
 
 
Escola Técnica JK – Curso de Informática Página - 91 
Referência Cruzada 
Referencia cruzada do Sistema apresentando a relação Depósito de 
Dados (Tabela) X Tela (Form). 
Relatórios 
a. Objetivo do Relatório 
 Descrever o objetivo e o conteúdo do Relatório. 
b. Instruções de Uso e Parâmetros 
 Descrever, o mais detalhadamentente possível, as instruções de uso e 
operacionalização para a chamada do relatório, explicitando seus 
parâmetros, inclusive com a utilização de exemplos. 
C. Copia do Relatório 
 
 
 
Escola Técnica JK – Curso de Informática Página - 92 
Revisão 
 
1)Dê exemplo de pelo menos 4 tabelas que podem se relacionar. Monte um 
DER relacionando as tabelas, faça a lista de entidades. Defina em cada uma 
delas os campos que serão chave primária, chave estrangeira e chave 
candidata e escolha também em cada um delas um determinado campo e 
defina um Domínio para ele. 
 
2)Depois de feito o exercício acima, você precisará documentar os nomes do 
banco de dados, tabelas, campos, etc... De acordo com as normas e padrões 
de construção da documentação, crie um nome para o banco de dados, os 
nomes para as tabelas e os nomes dos campos. 
 
3)Quando desenvolvemos sistemas, é necessário se preocupar com Backups 
e direitos de acesso. Explique com suas palavras, o que são esses dois itens. 
 
4)Em um banco de dados, existe um tipo de exclusão dos registros das 
tabelas que é denominado tipo cascata. Explique o que quer dizer isto. 
 
5)Quanto se trata de relatórios, qual tipo de formatação mais adequada? 
 
6)Quais as opções básicas devem conter no Menu da tela Principal? 
 
7)Quais os passos para implementação na fase de implantação do sistema? 
 
8)Existe uma fase logo após a fase de implantação que é de grande 
importância para o usuário; que fase é esta e como os profissionais 
responsáveis pelo sistema devem agir nesta fase? 
 
 
 
 
Escola Técnica JK – Curso de Informática Página - 93 
 
Módulo 8: Ferramentas CASE
 
 
 
Escola Técnica JK – Curso de Informática Página - 94 
���� Ferramentas CASE 
 
As regras de transformação apresentadas anteriormente resolvem grande parte 
dos problemas de transformação de esquemas conceituais em esquemas 
relacionais. Como se pode notar, a base para escolha da regra a ser empregada é 
o tipo de cardinalidade do relacionamento. Portanto, o projetista deve reservar 
especial atenção à modelagem dos relacionamentos e suas cardinalidades. 
Estas regras também são empregadas pelos programas de apoio a projeto de BD, 
conhecidos por ferramentas CASE. A figura abaixo ilustra o esquema completo do 
sistema de cana-de-açucar elaborado através da ferramenta CASE ERWin. 
A figura ilustra o que na ferramenta ERWin é chamado de Nível Lógico, uma 
vez que o nível de detalhe apresentado está mais próximo do modelo 
relacional do que do modelo conceitual, mesmo embora a figura se assemelhe 
bastante com um esquema E-R. Alguns detalhes podem ser observados na 
figura acima. São eles: 
• As figuras representadas no formato retangular representam tabelas do modelo 
relacional e não entidades do modelo E-R. Observe a existência da tabela 
Plantação, que no modelo E-R corresponde a um relacionamento; 
• Existem dois tipos de representação gráfica para tabelas, retângulos com bordas 
retas e abaloadas. Retângulos com bordas abaloadas sinalizam tabelas 
resultantes da transformação de entidades fracas (ex.: Talhão) ou tabelas 
resultantes da transformação de relacionamentos (Plantação). Observe a presença 
de atributos que são chaves estrangeiras (FK – foreign key) fazendo parte da 
chave primária destas tabelas (ex.: idFaz (FK) em Talhão). 
•A linha tracejada representa um relacionamento 1:N entre duas entidades fortes, 
que é transformado pela inclusão de uma chave estrangeira na tabela do lado N 
(que não participa da chave primária). Por exemplo, o relacionamento Fazenda – 
Proprietário é representado por uma linha tracejada (com um diamante na ponta 
que não significa nada). Neste caso, a ferramenta inclui automaticamente na 
 
 
 
Escola Técnica JK – Curso de Informática Página - 95 
tabela Fazenda, o campo idProp, o qual foi renomeado para “dono”, assinalado 
como (FK). 
• A linha contínua indica a transformação de um relacionamento 1:N, envolvendo 
uma de entidade fraca, ou de um relacionamento M:N. Neste caso o sistema inclui 
automaticamente a chave estrangeira como chave primária da tabela resultante. 
A figura abaixo ilustra o mesmo esquema relacional do sistema de cana-de-
açucar, na visão chamada Modelo Lógico Detalhado, na qual cada atributo está 
associado a um domínio específico. 
 
Estas informações são suficientes para a geração automática do esquema do BD 
em um SGBD. A ferramenta CASE ERWin, por exemplo, gera código automático 
para diversos SGBD (ex.: Oracle, DB2, SQL Server). 
A seguir o mesmo esquema é apresentado na notação textual simplificada: 
Município (cod-mun, nomeMun, pop) 
Proprietário (idProp, nomeProp, ender, telProp) 
Fazenda (idFaz, nomeFaz, áreaFaz, codMun*, dono*) 
 *codMun referencia Município 
 *dono referencia Proprietário 
Talhão (idFaz*, idTalhão, áreaTalhão) 
 *idFaz referencia Fazenda 
Plantação (idFaz*, id-talhão*, tipoVar*, numColheita, dat-Plantio, dat-ult-colheita) 
 *idFaz,id-talhão referenciam Talhão 
 *tipoVar referencia Variedade 
Variedade (tipoVar, descrVar, prodMédia) 
 
 
 
Escola Técnica JK – Curso de Informática Página - 9636 
MODELO AMBIENTAL ................................................................................................................................................38 
Diagrama de Fluxo de Dados .................................................................................. 38 
Elaborando um DFD ................................................................................................................................................... 38 
Entidade ................................................................................................................... 41 
Fluxo de Dados ....................................................................................................... 41 
Processo ................................................................................................................... 42 
Depósito de Dados .................................................................................................. 42 
Dicionários de Dados .............................................................................................. 43 
Regras para Formação de Nomes ................................................................................................................................ 43 
REVISÃO ....................................................................................................................................................................44 
Módulo 4: O Modelo de Dados 45 
VISÃO GERAL ............................................................................................................................................................46 
O QUE É MODELO DE DADOS? ...................................................................................................................................47 
Componentes do Modelo de Dados ........................................................................ 47 
Entidade ................................................................................................................... 47 
Representação Gráfica ................................................................................................................................................ 48 
Atributo ....................................................................................................................................................................... 48 
Chave de Identificação ................................................................................................................................................ 48 
Lista de Entidades ....................................................................................................................................................... 48 
Representação Gráfica ................................................................................................................................................ 49 
Tipos de Entidade ....................................................................................................................................................... 50 
Tipos de Relacionamento ........................................................................................ 50 
Tipos de Chave ........................................................................................................ 51 
EXERCÍCIOS ...............................................................................................................................................................52 
Módulo 5. Projeto de BD utilizando o modelo Entidade Relacionamento (ER) 53 
MODELO DE DADOS CONCEITUAL DE ALTO NÍVEL ....................................................................................................54 
ENTIDADES E ATRIBUTOS...........................................................................................................................................55 
TIPOS E INSTÂNCIAS DE RELACIONAMENTO ...............................................................................................................55 
GRAU DE UM RELACIONAMENTO ...............................................................................................................................55 
OUTRAS CARACTERÍSTICAS DE UM RELACIONAMENTO ..............................................................................................56 
Relacionamentos como atributos ............................................................................ 56 
Nomes de papéis e Relacionamentos Recursivos ................................................... 56 
Restrições em Tipos Relacionamentos ................................................................... 57 
Tipos Entidades Fracas ........................................................................................... 58 
Subclases, Superclases e Especializações ............................................................... 61 
Especialização ......................................................................................................... 62 
Generalização .......................................................................................................... 63 
“Lattice” ou Múltipla Herança ................................................................................ 66 
REVISÃO ....................................................................................................................................................................67 
Módulo 6: Normalização 68 
VISÃO GERAL ............................................................................................................................................................69 
O QUE É NORMALIZAÇÃO ? ........................................................................................................................................70 
Anomalias de Atualização ...................................................................................... 70 
 
Faculdades Doctum – Sistemas de Informação Página 4
Dependência Funcional ........................................................................................... 70 
Dependência Funcional Composta ou Completa .................................................... 71 
Dependência Funcional Transitiva ......................................................................... 71 
Primeira Forma Normal (1FN) ................................................................................ 71 
Entidade não normalizada ........................................................................................................................................... 72 
Entidades da 1FN ........................................................................................................................................................ 72 
Segunda Forma Normal (2FN) ................................................................................ 72 
Entidade na 2FN.......................................................................................................................................................... 73 
Terceira Forma Normal (3FN) ................................................................................ 73 
Simplificação do Processo de Normalização .......................................................... 75 
Regras Práticas ........................................................................................................ 75 
VISÃO GERAL CONSOLIDAÇÃO DE MODELOS DE DADOS ...........................................................................................76 
O que é Consolidação? ............................................................................................ 76 
Trabalhos Executados na Consolidação ................................................................. 76 
REVISÃO ....................................................................................................................................................................77 
EXERCÍCIOS ...............................................................................................................................................................78Módulo 7: Projeto (especificação da Solução para o projeto Físico) 81 
VISÃO GERAL ............................................................................................................................................................82 
Objetivos do projeto físico ...................................................................................... 83 
Passos para Implementação..................................................................................... 83 
Definição de ambiente. ................................................................................................................................................ 83 
Projeto físico da base de dados. .................................................................................................................................. 83 
Detalhamento dos processos. ...................................................................................................................................... 83 
Definição dos mecanismos de segurança e auditoria. ................................................................................................. 83 
Validação da especificação da solução ....................................................................................................................... 83 
Técnicas Utilizadas ................................................................................................. 83 
Produtos Gerados .................................................................................................... 83 
Construção ............................................................................................................... 83 
Objetivos ..................................................................................................................................................................... 83 
Passos para Implementação ......................................................................................................................................... 84 
Técnicas utilizadas .................................................................................................. 84 
Implantação ............................................................................................................. 84 
Manutenção ............................................................................................................. 85 
Normas e padrões de construção da documentação ............................................... 86 
Padrões de nomenclatura ........................................................................................ 86 
Regras Gerais .......................................................................................................... 87 
Área de Teste e Produção............................................................................................................................................ 87 
Funções Genéricas ...................................................................................................................................................... 87 
Arquivo de Configurações .......................................................................................................................................... 87 
Tabelas ........................................................................................................................................................................ 87 
Telas ............................................................................................................................................................................ 87 
Menu ........................................................................................................................................................................... 88 
Botões ......................................................................................................................................................................... 88 
Mensagens ................................................................................................................................................................... 88 
Relatórios .................................................................................................................................................................... 88 
Programas ................................................................................................................................................................... 88 
Lógica ......................................................................................................................................................................... 89 
Padrões de documentação ....................................................................................... 89 
 
Faculdades Doctum – Sistemas de Informação Página 5
Ajuda on line ........................................................................................................... 89 
Esquematização dos Módulos do Sistema ................................................................................................................... 89 
Descrição dos Módulos do Sistema e Esquematização de suas Funções .................................................................... 89 
Descrição das Funções ou Operações do Módulo do Sistema .................................................................................... 89 
Descrição dos Relatórios ............................................................................................................................................. 89 
Sobre o sistema ........................................................................................................ 89 
Descrição do Sistema .................................................................................................................................................. 89 
Equipe Envolvida ........................................................................................................................................................ 89 
Créditos ....................................................................................................................................................................... 90 
Manual Técnico ....................................................................................................... 90 
Introdução ................................................................................................................................................................... 90 
Diagrama de Contexto ................................................................................................................................................. 90 
Diagrama de Fluxo de Dados ...................................................................................................................................... 90 
Diagrama de Entidades e Relacionamentos ................................................................................................................. 90 
Diagrama de Blocos .................................................................................................................................................... 90 
Dicionário de Dados.................................................................................................................................................... 90 
Referência Cruzada ..................................................................................................................................................... 91 
Relatórios .................................................................................................................................................................... 91 
REVISÃO ....................................................................................................................................................................92 
Módulo 8: Ferramentas CASE 93 
FERRAMENTAS CASE ................................................................................................................................................94Faculdades Doctum – Sistemas de Informação Página 6
Introdução 
Introdução 
 
Faculdades Doctum – Sistemas de Informação Página 7
 ���� Objetivos gerais 
 
 
 
� Preparar o aluno para o
desenvolvimento de sistemas de
qualidade
�Apresentar as principais ferramentas
utilizadas na construção do projeto
de sistemas
�Trabalhar as regras e técnicas da
modelagem de dados
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Introdução 
 
Faculdades Doctum – Sistemas de Informação Página 8
Plano Geral do Curso 
Apresentação do curso 
Faculdades Doctum – Sistemas de Informação Página 9
���� Apresentação 
 
 
 
 
� Módulo I - Conceitos básicos
�Módulo II - O ciclo de vida dos sistemas
�Módulo III - Ferramentas para definição
do ambiente
�Módulo IV - O modelo de dados
�Módulo V - Normalização
�Módulo VI - Características projeto
físico
 
 
 
Faculdades Doctum – Sistemas de Informação Página 10
Módulo 1: Conceitos básicos 
 
Módulo I – Conceitos básicos 
 
Faculdades Doctum – Sistemas de Informação Página 11
���� Visão Geral 
 
 
�Definição de Análise de Sistemas
�Conceito de sistemas e tipos de
sistemas
�Histórico da Análise de sistemas
�Principais problemas encontrados no
desenvolvimento de sistemas
 
 
Módulo I – Conceitos básicos 
 
Faculdades Doctum – Sistemas de Informação Página 12
���� O que é a Análise de sistemas 
 
O computador tem sido nos últimos anos, o principal catalisador da revolução 
administrativa por que vem passando a empresa no mundo inteiro. Poderíamos 
historiar a evolução do seu uso em três estágios que denominaríamos: aplicações 
isoladas, sistemas integrados e sistemas de informações. 
 No primeiro estágio, colocou-se um elemento dentro da empresa capaz de 
desenvolver cálculos, processando e imprimindo dados a alta velocidade. Nesta 
fase, as aplicações eram transpostas para o computador segundo processos 
similares aos manuais usados até então. Dessa forma, aplicações como folha de 
pagamento, controle de estoques, contabilidade, orçamentos, eram atendidas 
isoladamente, não se dando maior importância às duplicidades de processos e 
dados. 
Motivada pela evolução tecnológica e pela própria especialização da mão- de- obra 
existente, surgiu entre os homens de processamento de dados a tendência para o 
desenvolvimento de sistemas integrados. Nesse segundo estágio, despontou a 
preocupação em se evitar redundância de dados nos diversos arquivos e a 
utilização da capacidade de transferir informações, via computador, de uma 
aplicação para outra. 
 Aliando-se essa possibilidade de integração à Teoria de Sistemas, surgiu a 
tendência atual em processamento de dados - o enfoque sistêmico (terceiro 
estágio). A utilização de sistemas de informação veio dar ao computador uma nova 
dimensão, transformando-o de mero processador de dados em elemento 
preponderante na racionalização e na dinamização do trabalho na empresa, 
modificando, inclusive, o próprio conceito de Centro de Processamento de Dados. 
 Nos dois primeiros estágios o computador era considerado como um fim e 
sua filosofia de utilização era ditada pelos técnicos de computação. No estágio 
atual, ele passou a ser uma ferramenta a serviço da empresa. 
Análise 
 Derivado do grego analýein - desatar, soltar, significa dissolução de um 
conjunto em suas partes. Em sentido amplo, empregam-se os termos “análise” e 
“analisar” como sinônimos de exame e examinar, pesquisa e pesquisar, verificação 
e verificar. 
Análise de Sistemas 
 Representa o estudo detalhado de uma área de trabalho (processo), que 
antecede uma ação que, quase sempre, implica no desenvolvimento de um 
conjunto de programas integrados(sistema) destinado à execução controle e 
acompanhamento do processo. 
Conceito de Sistemas 
Sistema significa todo e qualquer conjunto de peças. Órgãos ou instruções 
com funções específicas, com atividades predeterminadas, que integradas, levam 
à consecução de um certo objetivo. 
 Poderíamos conceituar um sistema como sendo um conjunto de partes 
coordenadas, que concorrem para a realização de um conjunto de objetivos. 
 Os sistemas aparecem em nosso mundo sempre estruturados em 
hierarquias. Um sistema pode sempre ser decomposto em sistemas menores 
denominados subsistemas, e, por outro lado, é sempre possível associar 
determinado sistema a um sistema maior, do qual ele é parte integrante. O ser 
humano, por exemplo, que é composto de uma série de subsistemas, como 
sistema nervoso, o sistema muscular etc., está por sua vez, inserido em sistemas 
maiores, como a família, a organização a que pertence, etc. 
 Devemos ter em mente cinco considerações básicas quando pensamos 
em um determinado sistema: 
 
� Os objetivos totais do sistema; 
Módulo I – Conceitos básicos 
 
Faculdades Doctum – Sistemas de Informação Página 13
� O ambiente do sistema; 
� Os recursos do sistema; 
� Os componentes do sistema; 
� A administração do sistema. 
 
 Ao analisarmos os objetivos do sistema, devemos ter muita cautela, pois 
muitas vezes, os “objetivos reais” do sistema não correspondem aos “objetivos 
declarados” apregoados pelos elementos que compõem o sistema. Os objetivos 
declarados podem às vezes idealizar, racionalizar, distorcer, omitir, ou mesmo 
esconder aspectos essenciais do funcionamento do sistema. 
 Geralmente não há concordância, entre os elementos do sistema, com 
relação aos objetivos que eles atribuem ao sistema. O reitor de uma universidade, 
por exemplo, pode descrever o propósito de sua instituição como sendo o de 
formar líderes para o país; o vice-reitor acadêmico pode ver como objetivo a 
qualidade do ensino; um coordenador de pós-graduação pode objetivar o 
desenvolvimento de trabalhos de pesquisa e, finalmente, um professor de 
Engenharia, o treinamento técnico dos jovens, visando capacitá-los a obter um 
bom emprego. 
 O ambiente do sistema é o conjunto de elementos situados “fora” do 
sistema, que satisfaçam uma das condições: 
 
� uma mudança nos seus atributos afeta o sistema; 
� os seus atributos podem ser mudados pelo funcionamento do sistema. 
 
 Os agentes distribuidores de uma editora, por exemplo, embora situados 
nas mais diferentes partes do país, fazem parte do “sistema editora”. Os leitores 
dos livros publicados são parte do ambiente do sistema. 
 Os recursos do sistema são os meios de que o sistema necessita para 
desempenhar as suas funções. Os recursos, ao contrário do ambiente, estão sob 
controle do sistema. Os recursos necessários para operar uma empresa, por 
exemplo, poderiam ser classificados em: dinheiro, equipamento, instalações, 
pessoal, material, suprimentos e serviços. 
 Os componentes do sistema são os elementos responsáveis pelo 
cumprimento das diversas “missões” essenciais ao funcionamento do sistema. 
Poderíamos, por exemplo, classificar como componentes de uma empresa as 
funções de pesquisa, produção, marketing, finanças e pessoal. 
 A administração do sistema é responsável pela elaboração, implantação e 
acompanhamento dos planos que, em função do ambiente existente, alocarão aos 
diversos componentes os recursos disponíveis, de modo que os objetivos do 
sistema sejam alcançados com o máximo rendimento. 
Tipos de Sistemas 
 
 Sistemas Naturais 
 
 - Sistemas Estelares (galáxias, sistemas solares, etc.) 
 - Sistemas Geológicos (rios, cadeias de montanhas etc.) 
 - Sistemas Moleculares (organizações complexas de átomos) 
 
Sistemas feitos pelo Homem 
 
 - Sistemas Sociais(organizações de leis, doutrinas, costumes, etc.) 
- Sistemas de Transporte (redes rodoviárias, canais, linhas aéreas, 
petroleiros, e semelhantes). 
- Sistemas de Comunicação (Telefone, telex, sinaisde fumaça, sinais 
manuais, etc.) 
 - Sistemas de Manufatura (Fábricas, linhas de montagem, etc.) 
- Sistemas Financeiros (contabilidade, inventários, livros-razão, controle de 
estoque, entre outros) 
 
Módulo I – Conceitos básicos 
 
Faculdades Doctum – Sistemas de Informação Página 14
 Sistemas Automatizados 
 
- Hardware de computadores - UCP, terminais, impressoras, unidades de 
fita magnéticas, etc. 
- Software de computadores - programas de sistemas, como sistemas 
operacionais, sistemas de bancos de dados e programas de controle de 
telecomunicações, além dos programas aplicativos que executam as 
funções desejadas pelo usuário. 
- Pessoas - aquelas que operam o sistema, que fornecem as entradas e 
utilizam as saídas, e as que desempenham atividades de processamento 
manual em um sistema. 
- Dados - as informações que o sistema conserva por um período de 
tempo. 
Módulo I – Conceitos básicos 
 
Faculdades Doctum – Sistemas de Informação Página 15
���� Breve histórico 
Seqüência cronológica e evolução das técnicas estruturadas: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ���� Problemas encontrados no desenvolvimento de sistemas 
Início da década de 70 
 PROGRAMAÇÃO ESTRUTURADA 
 Convenções da Codificação Estruturada 
 Programação top-down 
 Parnas, Ocultação da Informação 
 Dijkstra, Níveis de Abstração 
 Wirth, Refinamento Gradual 
Meados da década de 70 
 PROJETO ESTRUTURADO 
 Yordon/Constantine, Projeto estruturado 
 Jackson, Metodologia de Projeto 
 Warnier-Orr, Metodologia de Projeto 
Fins da década de 70 
 ANÁLISE ESTRUTURADA 
 De Marco, Análise Estruturada 
 Gane e Sarson, Análise Estruturada 
 SADT 
 Linguagem para Especificação de projeto 
 TÉCNICAS DE BANCO DE DADOS 
 Codd, Terceira Forma Normal 
 Modelagem de Dados 
 
Início da década de 80 
 TÉCNICAS AUTOMATIZADAS 
 HOS, Verificação Axiomática 
 Modelagem Automática de Dados 
 Modelos Inteligentes de Dados 
 Linguagens Não-Procedimentais 
 Diagramas de Ação 
Fins da década de 80 
 TÉCNICAS CASE 
 Martin, Engenharia da Informação 
 Bancadas de Trabalho Gráficas para 
 Analistas de Sistemas 
 Editores de Diagramas de Ação para 
 Linguagens de Quarta Geração 
 Sistemas Baseados em Regras 
 Apoios a projeto com Checagem de 
 Verificação 
 Especificações a partir das quais o 
 Código é Gerado Automaticamente 
 
Módulo I – Conceitos básicos 
 
Faculdades Doctum – Sistemas de Informação Página 16
Atualmente os maiores problemas enfrentados pelas empresas, no tocante a 
desenvolvimento de sistemas, são: 
 
A Produtividade 
 Um dos maiores problemas em empresas de desenvolvimento de software 
o tempo necessário para o desenvolvimento dos projetos e o backlog que vai se 
formando com o tempo. Visando diminuir esses tempo e conseguir minimizar o 
backlog existente as empresas costumam usar algumas técnicas, como por 
exemplo: 
 
• Contratação de mais programadores e analistas de sistemas; 
• Contratação de mais programadores e analistas de sistemas mais 
talentosos, oferecendo-lhes melhores condições de trabalho; 
• Deixar os usuários desenvolver seus próprios sistemas; 
• Adotar melhores linguagens de programação; 
• Atacar os problemas da manutenção; 
• Controles de engenharia de software; 
• Ferramentas automatizadas para desenvolvimento de sistemas. 
 
A Confiabilidade 
 Um sistema concebido com erros demandará mais tempo para ser 
concluído, uma vez que o tempo que seria gasto com o desenvolvimento será 
destinado para a depuração dos erros. 
 
A Manutenibilidade 
 Em torno de 50 a 80% do trabalho de equipes de CPD´s de empresas é 
voltado para a manutenção de sistemas, como por exemplo: revisão, modificação, 
conversão, depuração ou qualquer outro de tipo de alteração. Os sistemas ainda 
não são suficientemente documentados o bastante ou as linguagens ainda não 
poderosas o bastante para se evitar essa perca de tempo tão grande em 
manutenções que não acabam mais. 
 
A Eficiência 
 Os sistemas devem ser desenvolvido visando a agilidade nas tarefas 
anteriormente executadas, ou seja, eles devem ser estruturados de forma a 
funcionar com uma considerável taxa de retorno. Esse tipo de problema é mais da 
competência dos programadores do que mesmo dos analistas. 
 
A Portabilidade 
 Um outro grande problema enfrentado atualmente é a plataforma de 
hardware dos sistemas. Os sistemas devem ser desenvolvimento de forma a 
suportarem mudanças do hardware, um sistema não pode ser desenvolvido para 
“rodar” apenas em um tipo de máquina, ele deve suportar esse tipo de mudança 
não gerando conflitos entre software e hardware. 
 
 
A Segurança 
 Com a crescente tendência de trabalhos em rede, etc, fica cada vez mais 
necessária a segurança nos softwares, então os Centros de Processamento de 
Dados das empresas estão cada vez mais preocupados com a invasão dos 
hackers ou até mesmo de pessoas que não tenham a intenção de prejudicar mas 
Módulo I – Conceitos básicos 
 
Faculdades Doctum – Sistemas de Informação Página 17
que sem querer consigam entrar nos sistemas dessas empresas e tenham 
acessos aos dados. 
 A Metodologia de Desenvolvimento de Sistemas (MDS) consiste na 
adoção de um ciclo de vida de sistemas formalmente, padronizando 
procedimentos/atividades e técnicas, utilizando ferramentas e gerando produtos. 
 A adoção de uma MDS é de vital importância para o desenvolvimento de 
sistemas, pois trata-se da organização do trabalho que está sendo desenvolvido. 
Além da geração de uma documentação rica, que auxiliará tanto no decorrer do 
desenvolvimento quanto nas futuras manutenções, a MDS proporciona, em 
qualquer fase do projeto, uma visão do estado atual; oferece subsídios para o 
acompanhamento produtivo de todo o desenvolvimento. Além de minimizar riscos 
de desenvolvimento de sistemas, a MDS também conduz à geração de um 
sistema de qualidade, adequado e dentro dos prazos e custos previstos, elevando 
o nível da produtividade das equipes técnicas pois formaliza a distribuição das 
tarefas entre os envolvidos, melhorando o relacionamento com a comunidade 
usuária. Através dessa organização que a MDS sugere, conseguiremos melhorar o 
controle de tarefas e recursos padronizando tarefas, documentação, técnicas e 
ferramentas, e em cada fase ela também introduz pontos de verificação 
(revisão/aprovação). 
 Concluímos então que a utilização de uma MDS é vital para a geração de 
sistemas, haja vista sua forma organizada e pela documentação que ela sugere. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Faculdades Doctum – Sistemas de Informação Página 18
Revisão 
 
1)O que significa Análise de Sistemas? 
 
2)O que é um sistema? Dê exemplo de 5 sistemas. 
 
3)Quais são os tipos de sistemas? Explique com suas palavras sobre cada um 
deles. 
 
4)Quais os problemas encontrados no desenvolvimento de sistemas e explique 
sobre cada um deles. 
 
 
Faculdades Doctum – Sistemas de Informação Página 19
 
Módulo 2: O ciclo de vida dos sistemas 
 
 
Faculdades Doctum – Sistemas de Informação Página 20
���� Visão Geral 
 
 
 
�Definição do ciclo de vida do sistema
�Fases do ciclo de vida
�Apresentação geral do Modelo lógico
 
 
 
 
Faculdades Doctum – Sistemas de Informação Página 21
���� Definição do ciclo de vida do sistema 
O ciclo de vida de um sistema tem como função principal a definição 
de atividades a serem executadas em um projeto de desenvolvimento de sistemas 
e a introdução de pontos de verificação para o controle gerencial. 
Todo analista deve possuir estas informações para poder iniciar, 
prosseguir e finalizar um ciclo de vida de um sistema. Lógico que quanto maior o 
projeto mais objetivos teremospara analisar, para colocarmos em observação. 
Em vista disso, todo ciclo de vida será um modo, uma maneira pela 
qual você junto com seu projeto serão responsáveis. 
Os ciclos de vida são divididos de várias maneiras, dependendo do 
autor. Alguns levam em consideração a existência de apenas dois ciclos de vida, 
outros levam em consideração três, quatro ou até mais ciclos. 
O ciclo de vida definido por nossa equipe tem como razão de escolha 
as seguintes visões: 
- Poder passar para a fase seguinte sem que a anterior esteja 
completa, não prejudicando o andamento do projeto; 
- Baseia-se em técnicas estruturadas de análise; 
- Provem de paralelismo/ simultaneidade de fases e 
- Liberdade de processamento. 
 
Faculdades Doctum – Sistemas de Informação Página 22
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
O Ciclo De Vida De Projeto Estruturado 
 
 Iremos apresentar as atividades e os terminais do ciclo de vida do 
projeto. Os terminais consistem em usuários, gerentes e pessoal da operação, 
eles são indivíduos ou grupos de indivíduos que fornecem entradas à equipe do 
projeto e que são os últimos receptores do sistema, eles interagem com as nove 
atividades sendo resumida logo abaixo: 
 
Levantamento 
 
Essa atividade é também conhecida como estudo de viabilidade ou 
estudo inicial das atividades Tipicamente, começa quando um usuário solicita que 
uma ou mais parte de sua atividade seja automatizadas. Os principais objetivos da 
atividade de levantamento são os seguintes: 
Identificar os usuários responsáveis e desenvolver um “escopo” inicial 
do sistema. Isso pode envolver a realização de uma série de entrevistas para ver 
quais usuários estão envolvidos no projeto proposto e quais não estão. Pode 
envolver, também, o desenvolvimento de um diagrama de contexto inicial e um 
simples diagrama de fluxo de dados. 
Identificar as atuais deficiências no ambiente do usuário. Consistirá, 
habitualmente, em uma lista narrativa simples das funções que estejam faltando 
ou que estejam atuando de modo insatisfatório no sistema atual. 
Estabelecer metas e objetivos para um novo sistema. Isso pode ser 
também uma lista narrativa simples constituída pelas funções existentes que 
CICLO DE VIDA ESTRUTURADO 
LEVANTAMENTO 
ANÁLISE 
PROJETO 
IMPLANTAÇÃO 
MANUTENÇÃO 
CONSTRUÇÃO 
 
Faculdades Doctum – Sistemas de Informação Página 23
necessitem ser reimplementadas , novas funções que necessitem ser 
acrescentadas, e critérios de desempenho para o novo sistema. 
Determinar se é possível automatizar o sistema e, se assim for, 
sugerir alguns esquemas aceitáveis. Isto envolverá algumas estimativas grosseiras 
e aproximadas do cronograma e do custo de construção de um novo sistema e 
dos benefícios a serem obtidos. Apesar da gerência e dos usuários, muitas vezes, 
desejarem uma estimativa detalhada, precisa neste ponto, o analista de sistema 
terá sorte se puder estimar o tempo, os recursos e os custos dentro dos limites de 
mais ou menos 50% neste estágio primitivo do projeto. 
Preparar uma previsão do projeto que será usada para conduzir o 
restante do projeto. A previsão do projeto incluirá toda a informação listada acima, 
bem como identificar o gerente responsável do projeto. Pode descrever, também, 
os detalhes do ciclo de vida que o resto do projeto seguirá. 
O levantamento ocupa, tipicamente, somente 50% a 10% do tempo e 
recursos de todo o projeto, e para os pequenos e simples pode não ser também 
uma atividade formal. Entretanto, mesmo que não venha a consumir muito do 
tempo ou dos recursos o levantamento é uma atividade crítica: ao fim, a gerência 
pode decidir cancelar o projeto se ele não parecer atrativo do ponto de vista 
custo/benefício. 
Como analista de sistemas, você pode ou não estar envolvido no 
levantamento. O usuário, juntamente com os elementos dos níveis apropriados de 
gerência, pode tê-lo feito antes mesmo de você Ter ouvido falar sobre o projeto. 
No entretanto, para projetos grandes e complexos, o levantamento envolve tanto 
trabalho detalhado que o usuário muitas vezes solicitará ao analista de sistemas 
que se envolva tão logo seja possível. 
 
Propósito da análise 
O principal propósito da atividade da análise é transformar as suas 
duas principais entradas, critério do usuário e previsão do projeto, em uma 
especificação estruturada. Isso envolve a modelagem do ambiente do usuário com 
diagramas de fluxo de dados, diagramas de entidades relacionamentos, diagramas 
de transições de estado e as outras ferramentas. 
O Processo passo a passo da análise de sistemas envolve o 
desenvolvimento de um modelo ambiental e o desenvolvimento de um modelo 
comportamental. Esses dois modelos se combinam na forma de modelo essencial 
que representa uma descrição formal do que o novo sistema deve fazer, 
independente da natureza da tecnologia que será usada para implementar aqueles 
requisitos. 
Em acréscimo ao modelo do sistema descrevendo os requisitos do 
usuário, um mais cuidadoso e detalhado conjunto de orçamento e cálculos de 
custo-benefício é preparado, geralmente, ao final da fase de análise. 
 
Projeto 
 
A atividade de projeto ocupa-se da alocação de partes da 
especificação aos processadores apropriados e para tarefas apropriadas no 
interior de cada processador. No interior de cada tarefa, atividade de projeto 
ocupa-se com desenvolvimento de uma hierarquia apropriada de módulos de 
programa e interfaces entre esses módulos para implementar a especificação 
criada na atividade de análise. Além disso, a atividade de entidades-
relacionamento em um projeto de banco de dados. 
O modelo de implementação do usuário descreve os problemas de 
implementação que o usuário se sente firme o suficiente para não deixá-los a 
critérios dos projetistas e programadores dos sistemas. Os principais problemas 
pelos quais o usuário normalmente está interessado são a especificação da 
fronteira homem-máquina e a especificação da interface homem-máquina. A 
fronteira homem-máquina separa as partes do modelo essencial que devem ser 
executadas por uma pessoa das partes que devem ser implementadas em um ou 
mais computadores. Similarmente, a interface homem-máquina é uma descrição 
do formato e da seqüência de entradas fornecidas pelos usuários humanos ao 
 
Faculdades Doctum – Sistemas de Informação Página 24
computador, bem como o formato e seqüência das saídas fornecidas pelo 
computador ao usuários. 
 
Construção 
 
Essa atividade inclui a codificação e a integração de módulos em um 
resumo progressivamente mais complexo do sistema final. Desse modo, essa 
atividade inclui a programação estruturada e a implantação top-down. 
Como podemos imaginar essa é uma atividade que tipicamente o 
analista não está envolvido, embora existam alguns projetos onde a análise de 
sistemas, o projeto e a implementação são feitos pela mesma pessoa. 
Nós também definimos como fase da implementação as seguintes 
fases: 
 
Controle De Qualidade 
 
O controle de qualidade é conhecido também como teste final ou 
teste de aceitação. Essa atividade exige como entrada os dados do teste de 
aceitação gerados na fase anterior e um sistema integrado produzido na fase de 
implementação. 
O analista de sistema pode estar envolvido na atividade de controle 
de qualidade, mas isto normalmente não acontece. Um ou mais membros da 
organização usuária pode assumir a responsabilidade, ou qualquer outro 
departamento da organização. 
Observe que é importante executar atividades de controle de 
qualidade em todas as fases iniciais para assegurar que elas estão sendo 
realizadas em um nível apropriado de qualidade. Desse modo, a atividade controle 
de qualidade deve ser realizada através das atividades de análise, projeto e 
programação para assegurar que o analista está desenvolvendo especificações de 
alta qualidade, o projetista está desenvolvendo umprojeto de alta qualidade e o 
programador está escrevendo códigos de alta qualidade. Portanto esta atividade 
identificada aqui é meramente, o teste final da qualidade do sistema. 
 
Descrição Dos Procedimentos 
 
O analista tem que se preocupar com o desenvolvimento de um 
sistema inteiro, como um todo e não somente, a parte automatizada. Desse modo, 
uma das atividades importantes a serem realizadas é a geração de uma descrição 
formal das partes do novo sistema que serão manuais, e de uma descrição de 
como os usuários realmente vão interagir com a parte automatizada do novo 
sistema. 
A saída desta fase ou atividade é o manual do usuário. 
 
 
Geração De Teste De Aceitação 
 
O processo de testes provavelmente ocupará cerca de metade do 
cronograma de desenvolvimento de seu sistema, dependendo do cuidado com que 
tenham sido executadas as atividades ou fases iniciais de análise, projeto e 
programação. Mesmo no caso de ter sido executada uma tarefa perfeita de análise 
de sistemas, projeto e programação, é preciso algum esforço para verificar se não 
há erros. Se, por outro lado, tiver sido feito um mau serviço, então os testes 
tornam-se interativos: a primeira rodada de testes denuncia a presença de erros e 
as rodadas subsequentes verificam se os programas corrigidos já estão 
funcionando corretamente. 
O processo de desenvolvimento de casos de testes de aceitação 
pode ser executado em paralelo com as atividades de implementação de projeto e 
programação, de modo que, quando os programadores tiverem terminado seus 
 
Faculdades Doctum – Sistemas de Informação Página 25
programas e executado seus próprios testes locais, a equipe usuário/analista 
estará pronta para seus próprios casos de testes. 
Além do conceito básico de que a descrição dos requisitos do usuário 
forma a base dos casos de teste finais, o analista deve conhecer os vários tipos de 
testes, bem como alguns conceitos relacionados a eles. 
 
Testes Funcionais: Forma mais conhecida de testes. O objetivo e 
verificar se o sistema executa corretamente suas funções. 
 
Testes de Recuperação: O objetivo deste tipo de teste é verificar se 
o sistema pode se recuperar-se adequadamente de vários tipos de 
falhas. 
 
Testes de Desempenho: Verifica se o sistema pode manipular o 
volume de dados e transações recebidas e especificadas no modelo 
de implementação do usuário, bem como se ele apresenta o tempo 
de resposta adequado. 
Teremos que estar preparados para um grande volume de testes. 
Para que estes testes sejam executados de maneira eficaz, a equipe 
de desenvolvimento de sistemas necessita de três coisas: planos de 
testes, descrições de testes e procedimentos de testes. 
Um plano de testes é um documento organizado que pode conter as 
seguintes informações: 
 
Objetivo do teste: qual o objetivo do teste e qual parte do sistema 
será testada; 
Localização e cronograma do teste: onde e quando o teste será 
realizado; 
 
Descrições de teste: descrição das entradas que serão introduzidas 
no sistema e as saídas e resultados antecipados; 
 
Procedimentos de testes: descrição de como os dados de testes 
devem ser preparados e submetidos ao sistema, como os resultados 
de saídas devem ser colhidos, como os resultados dos testes devem 
ser analisados e de qualquer outro procedimento operacional que 
deva ser observado. 
Implantação 
 
As entradas para esta atividade são: o manual do usuário, o banco de 
dados convertido se houver e o sistema aprovado. Em alguns casos, a instalação 
pode significar simplesmente, uma passagem noturna para o novo sistema, sem 
nenhuma comemoração ou fanfarra; em outros casos, a instalação poderá ser um 
processo gradual, com um grupo de usuários após o outro recebendo os manuais 
do usuário, do hardware e sendo treinado no uso do novo sistema e, realmente 
começando a usá-lo. 
 
Manutenção 
 
Não se pode conservar atualizado um sistema e a documentação a 
ele associada se essa documentação não estiver correta. Precisamos garantir que, 
quando um sistema entrar em operação, todos os documentos a ele relativos 
estejam completos, consistentes, corretos e atualizados. Para que a manutenção 
continuada tenha sucesso, essas diretrizes devem ser impostas e uma pessoa ou 
grupo independente deve verificar se a documentação está correta antes que o 
sistema seja posto em operação. 
Devemos ainda, nos assegurar que existe um mecanismo para 
executar modificações continuadas nesses documentos, ou seja a especificação 
 
Faculdades Doctum – Sistemas de Informação Página 26
deve ser vista como um documento vivo, sujeito a alterações constantes, apesar 
de controladas. 
A primeira regra da manutenção de sistemas é esta: qualquer 
modificação proposta do sistema operativo atual deve, em todos os casos, iniciar-
se por um exame dos impactos na especificação de requisitos deste sistema. 
Qualquer modificação deve ser ilustrada, documentada e verificada com o usuário, 
fazendo-se as adequadas modificações no modelo do sistema. Isso costuma ser 
feito pelo preenchimento de um formulário conhecido como solicitação de 
alteração de sistema. 
Qualquer modificação no sistema não será livre. É possível que 
algumas modificações sejam mínimas e só requeiram alguns minutos de trabalho 
para serem incorporadas. Entretanto, a pessoa ou grupo responsável pela 
alteração tem a obrigação de escrever a declaração de impacto: uma declaração 
precisa e detalhada das mudanças que terão de ser feitas na especificação do 
sistema para implementar a modificação proposta. Juntamente com isso, deve 
haver uma declaração do impacto econômico: uma declaração do custo da 
implementação da alteração e o benefício estimado que derivará daquela 
alteração. 
Qualquer modificação feita em um sistema, normalmente resulta em 
uma modificação no software e/ou hardware do sistema; pode também causar a 
alteração dos manuais, dos procedimentos de operação e de vários outros 
componentes do sistema. Porém o documento mais importante a ser mantido 
atualizado é a DECLARAÇÃO DE REQUISITOS DO USUÁRIO. Sem isso, as 
futuras modificações serão cada vez mais difíceis de serem feitas e a mudança 
para um novo sistema será infinitamente mais dispendiosa, mais consumidora de 
tempo e mais penosa do que normalmente seria. 
Não há qualquer dúvida, de que se conseguir isto descrito acima, é 
tarefa bastante difícil. 
 
 
Faculdades Doctum – Sistemas de Informação Página 27
���� Fases do ciclo de vida 
Levantamento (Estudo Preliminar) 
Objetivos: 
- Fazer levantamento de dados e requisitos; 
- Fazer estudo inicial do problema; 
- Realizar um estudo da viabilidade do problema. 
 
Passos para Implementação: 
 
1. Identificar as diretrizes e necessidades. 
- Determinar os usuários do sistema. 
- Levantar as principais necessidades; 
- Levantar os problemas globais. 
 
2. Detalhar os requisitos funcionais. 
- Determinar os principais objetivos, detalhar os requisitos, 
quantificando-os e qualificando-os; 
- Determinar a abrangência/amplitude, fronteiras e interligação com 
outros sistemas; 
- Relatar impactos e mudanças que o projeto causará à empresa; 
- Relatar problemas e limitações tais como: de legislação, de mercado, 
ambientais, etc; 
- Elaborar dicionário de termos próprios visando dirimir dúvidas e 
padronizar conceitos; 
 
3. Estudo da Viabilidade. 
- Definição de alternativas; 
- Análise dos riscos implementacionais para cada alternativa; 
- Análise custo x benefício. 
- Custos de construção, instalação, operação e manutenção do 
sistema 
- Benefícios: táticos e operacionais; 
 
4. Definir estratégia da análise do sistema atual. 
- Definir cronograma com pessoal envolvido e suas atribuições; 
- Sugestão da melhor solução. 
 
5. Aprovar estudo preliminar. 
- Avaliar a conformidade dos requisitos; 
- Elaborar diagrama de contexto da situação atual e da proposta; 
- Elaborar relatório de viabilidadetécnica, análise custo x benefício; 
- Reunir e apresentar. 
Técnicas Utilizadas 
- Entrevistas; 
- Reuniões; 
- Observação pessoal; 
- Diagrama de contexto. 
Produtos Gerados: 
- Relatório contendo todos os itens do levantamento 
 - Diagrama de contexto. 
 
Faculdades Doctum – Sistemas de Informação Página 28
���� Análise (Representação da solução, projeto lógico) 
 
Objetivos 
- Coletar informações do sistema atual; 
- Elaborar requisitos do novo sistema; 
- Modelar a solução. 
 
Passos para Implementação 
 
1. Estudo do problema. 
- Levantamento detalhado; 
- Especificação de requisitos 
 
2. Modelagem dos processos. 
- Construção do DFD; 
- Explosão do DFD em níveis. 
 
3. Modelagem de dados. 
- Construção do DER; 
- Normalização. 
 
4. Construção do dicionário de dados. 
- Descrição dos fluxos; 
- Descrição dos depósitos de dados; 
- Descrição da lógica dos processos externos. 
 
5. Reavaliação da estratégia de desenvolvimento. 
- Redefinição do grupo de trabalho; 
- Delimitação de tempo e recurso; 
- Revisão; 
- Apresentação; 
- Avaliação. 
 
Técnicas Utilizadas 
 
- Entrevistas; 
- Reuniões; 
- DFD; 
- DER; 
- Dicionário de dados. 
 
Produtos Gerados 
- DFD 
- DER 
- Dicionário de Dados 
 
Faculdades Doctum – Sistemas de Informação Página 29
Revisão 
 
1)Quais são as fases do ciclo de vida de um sistema e faça um resumo explicando 
sobre cada uma das fases. 
 
2)Descreva quais são os objetivos , técnicas utilizadas e produtos gerados na fase 
de Levantamento. 
 
3)Quais são os produtos gerados, objetivos e técnicas utilizadas na fase de 
Análise. 
 
Faculdades Doctum – Sistemas de Informação Página 30
 
Módulo 3: Ferramentas para definição do 
ambiente 
 
 
 
 
Módulo III – Ferramentas para definição do ambiente 
Faculdades Doctum – Sistemas de Informação Página 31
���� Visão Geral 
 
 
 
 
�Apresentação das ferramentas
utilizadas no desenvolvimento de
sistemas
�Exemplos práticos e a utilização das
ferramentasl
 
 
 
 
 
 
 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 32
���� Ferramentas utilizadas no desenvolvimento de sistemas 
As ferramentas utilizadas no processo de desenvolvimento de sistema poderão ser 
usadas e mescladas em diferentes metodologias, dependendo da complexidade 
do sistema, do tempo para o desenvolvimento, dentre outros fatores que deverão 
ser avaliados criteriosamente pela equipe de desenvolvimento. Utilizaremos a 
análise essencial para caracterizar a utilização das ferramentas mais utilizadas. 
 
O Modelo Ambiental consiste de quatro componentes: 
• Declaração de Objetivos 
• Diagrama de Contexto 
• Lista de Eventos 
• Dicionário de Dados Preliminar (opcional) 
 
Declaração dos objetivos 
 
Consiste de uma breve e concisa declaração dos objetivos do sistema. 
É dirigida para a alta gerência, gerência usuária ou outras pessoas não 
diretamente envolvidas no desenvolvimento do sistema. 
Pode ter uma, duas ou várias sentenças mas não deve ultrapassar um parágrafo. 
Não deve pretender dar uma descrição detalhada do sistema. 
 
EXEMPLOS: 
 
“O Objetivo do Sistema de Processamento de Livros ABC é manusear todos os 
detalhes de pedidos de compra de livros dos clientes, bem como a remessa, 
faturamento e cobrança de clientes em atraso. Informações sobre pedidos de 
livros devem ficar disponíveis para outros sistemas tais como: Marketing, Vendas 
e Contabilidade.” 
 
“O sistema AKD-MICO se propõe a manipular as informações sobre alunos 
matriculados, cursos oferecidos e períodos letivos, de modo a permitir a avaliação 
de cada aluno matriculado.” 
 
Diagrama de Contexto 
 
Apresenta uma visão geral das características importantes do sistema: 
• As pessoas, organizações ou sistemas com os quais o sistema se comunica 
(Entidades Externas). 
• Os dados que o sistema recebe do mundo exterior e que de alguma forma 
devem ser processados. 
• Os dados produzidos pelo sistema e enviados ao mundo exterior. 
• A fronteira entre o sistema e o resto do mundo. 
 
 
 
 
 
 
 
 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 33
 
 
Lista De Eventos 
É uma relação dos estímulos que ocorrendo no mundo exterior implicam que o 
sistema dê algum tipo de resposta. 
 
Ou, um evento pode ser definido informalmente como um acontecimento do 
mundo exterior que requer do sistema uma resposta. 
 
UM ESTÍMULO: É um ativador de uma função. É a forma como o evento age 
sobre o sistema. É a conseqüência do fato de ter ocorrido um evento externo. É a 
chegada de um estímulo que indica que o evento ocorreu e isto faz com que o 
sistema então ative uma função pré-determinada para produzir a resposta 
esperada. 
 
UMA RESPOSTA: É o resultado gerado pelo sistema devido à ocorrência de um 
evento. Uma resposta é sempre o resultado da execução de alguma função interna 
no sistema como conseqüência do reconhecimento pelo sistema de que um 
evento ocorreu: Pode ser: 
 
• Um fluxo de dados saindo do sistema p/ uma entidade externa. 
• Uma mudança de estado em algum depósito de dados (o que eqüivale a 
inclusão, exclusão ou modificação de algum registro de um arquivo). 
• Um fluxo de controle saindo de uma função para ativar outra função. 
Os eventos são classificados em 3 tipos: 
• Orientado à Fluxo (F) 
• Temporal (T) 
• Temporal Relativo (TR) 
 
 
EVENTO ORIENTADO A FLUXO 
 
É aquele associado a um fluxo de dados , ou seja, o sistema toma conhecimento 
da sua ocorrência quando um ou vários dados chegam a ele Corresponde aos 
fluxos de dados de entrada do Diagrama de Contexto. 
Nem sempre um fluxo de dados é necessariamente um evento orientado a fluxo. 
Isso ocorre quando o sistema solicita de uma entidade externa um dado. 
sujeito + verbo transitivo na voz ativa + complemento verbal 
EXEMPLO: CLIENTE EMITE COMPROVANTE 
EVENTO TEMPORAL 
 
É aquele gatilhado pela chegada a algum ponto no tempo. 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 34
Não é disparado por nenhum fluxo de dados. É como se o sistema dispusesse de 
um relógio interno que determinasse a passagem do tempo. 
Pode ocorrer que um evento temporal peça ao sistema que solicite dados de uma 
ou mais entidades externas. Nesse caso um ou mais fluxos de dados podem estar 
associados com um evento temporal, embora os fluxos de dados em si não 
representem o evento propriamente dito. 
 
EXEMPLO: 
1. Um relatório diário de todos os pedidos de livro é solicitado às 09:00 h. 
2. Fatura deve ser gerada às 15:00 h. 
3. Relatório gerencial deve ser gerado uma vez por hora. 
 
“É hora de” + verbo no infinitivo + complementos verbais 
EXEMPLO: É hora de emitir nota-fiscal 
 
EVENTO TEMPORAL RELATIVO 
 
É iniciado pelo passar do tempo, mas dependendo do valor de um dado da 
memória. 
É um caso especial de evento temporal no qual o estímulo externo ocorre em um 
ponto imprevisível no tempo. 
Diferentemente do evento temporal, não esta associado com a passagem regular 
do tempo de forma que o sistema o antecipe usando seu relógio interno. 
Diferentemente também do evento orientado a fluxo, não mostra sua presença 
através de um dado que chega. 
(1) sujeito + verbo transitivo na voz ativa + complemento verbais 
(2) sujeito + verbo na voz passiva + complemento verbais 
EXEMPLO 
(1) A Diretoria autoriza o pagamento de uma fatura 
(2) O nível de ressuprimento do estoque é atingido 
 
IMPORTANTE: O fluxo de controle é um fluxo de dados binário, só tem 2 valores 
possíveis que são ligado ou desligado. 
Cuidados devem ser tomados para distinguir os eventos dos fluxos relacionados a 
evento.Para evitar confundir os eventos com os fluxos relacionados aos eventos o 
observador deve se colocar na posição de quem está de fora do sistema olhando 
para ele. 
 
“O PEDIDO DO CLIENTE É RECEBIDO 
PELO SISTEMA” 
pedido do cliente é um fluxo de dados 
relacionado a um evento 
CLIENTE COLOCA PEDIDO 
é o evento associado 
 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 35
Cuidados também devem ser tomados no sentido de separar os eventos discretos 
dos que foram empacotados juntos como um único evento (ocorre freqüentemente 
em eventos orientados a fluxo). 
 
“CLIENTE COLOCA PEDIDO” 
Se em algumas ocorrências do evento aparecer o elemento de dados 
“Identificação do vendedor” e em outras não, separar em dois eventos. 
 
“CLIENTE COLOCA PEDIDO” 
e 
“VENDEDOR COLOCA PEDIDO” 
 
Diagrama de entidade e relacionamento - DER 
 
Não existe uma seqüência pré-definida para produção do Diagrama de Contexto e 
Lista de Eventos. Pode-se começar por qualquer um dos dois e no final verificar 
se estão consistentes um com o outro. A próxima etapa é a construção do DER. 
Exemplo de DER. 
O DER é a representação das associações entre entidades. Neste diagrama não 
se consegue visualizar como os dados são manipulados. 
Ele ilustra a organização dos dados a respeito do mundo real em termos de 
entidades e relacionamentos entre as informações, não representando a dinâmica 
de funcionamento do sistema. 
O DER representa, através da simbologia gráfica, o modelo conceitual de dados, 
correspondendo a uma “máquina de responder perguntas” do ambiente 
investigando, a partir da navegação através de entidades, relacionamentos e seus 
atributos. 
 
 
 
 
 
 
 
 
 
 
 
 
 Diagrama De Transição De Estados (Dte) 
 
DEFINIÇÃO 
 
Representa a perspectiva dos controles. Mostra as transformações de controle do 
sistema no tempo. 
 
CONCEITOS 
 
Venda 
TipoProduto Fornecedor 
Client
e 
Produto 
ItemVenda 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 36
Estado: Um estado de um sistema representa uma situação, um cenário ou um 
modo de comportamento em que encontramos um sistema ao observá-lo em 
determinado momento. 
 
Transição: Uma transição representa a passagem do sistema de um estado para 
outro. Assim ao acendermos ou ao apagarmos uma lâmpada, estaremos 
provocando uma transição de estado. 
 
Ação: Uma ação representa a atividade do sistema que efetua a transição do 
estado. 
 
Condição: Uma condição representa a causa necessária para que haja a 
transição de estado. Decorre da ocorrência de um evento ou circunstância que 
propicia a transição de estado. Assim ao apertarmos o interruptor, provocamos a 
condição para que seja executada a ação de acender ou de apagar a lâmpada, 
provocando desta forma uma transição de estado. 
 
 
 
Exemplo de DTE 
 
 
 
 
 
 INTERRUPTOR INTERRUPTOR 
 FOI LIGADO FOI DESLIGADO 
 
 ASCENDER APAGAR A 
 LÂMPADA LÂMPADA 
 
 
 
 
 
 
No diagrama acima podemos distinguir: 
 
• Dois estados; apagada e acesa 
• Há duas transições possíveis: de apagada para acesa e de acesa para 
apagada. 
• Há dois pares de condições/ações: 
• A condição interruptor foi ligado, que dispara a ação acender lâmpada, 
provocando a transição de estado de apagada para acesa 
• A condição interruptor foi desligado, que dispara a ação apagar lâmpada, 
provocando a transição de estado de acesa para apagada. 
 
Elaboração Do Diagrama De Transição De Estados 
 
• Construir a lista de eventos do sistema 
• Ordenar os eventos cronologicamente 
• Para cada evento, identificar a transição de estado correspondente 
• Para cada transição de estado: 
 
 Identificar o estado de partida e o estado de chegada 
 Identificar a condição que provoca a transição de estado 
 Identificar a ação ativada pela ocorrência da condição 
 
APAGADA 
ACESA 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 37
• Para cada estado: 
 
Verificar qual a transição para a qual ele é o estado de chegada 
 Verificar se há transição de saída dele em condições normais e anormais 
 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 38
���� Modelo Ambiental 
Ao terminar o modelo ambiental deve-se poder confirmar que: 
 
Cada fluxo do diagrama de contexto deve ser requerido pelo sistema para 
reconhecer: 
 
• a ocorrência de um evento, ou 
• a necessidade de resposta a um evento, ou 
• ambos os casos. 
 
Cada fluxo de saída deve ser uma resposta a um evento 
Cada evento não temporal deve ter uma entrada para o sistema que permita que 
este detecte que o evento ocorreu. 
 
Cada evento deve: 
 
• Produzir uma saída imediata em sua resposta, ou 
• Armazenar dado para saída posterior (como resposta ou parte de uma resposta 
de algum outro evento) 
• Causar uma mudança de estado no sistema (como indicado no diagrama de 
transição de estado). 
 
 
Diagrama de Fluxo de Dados 
 
DFD é uma representação em rede dos processos (funções) do sistema e dos 
dados que ligam esses processos. Ele mostra o que o sistema faz e não como é 
feito. É a ferramenta de demonstração central da análise estruturada. 
Um DFD apresenta as partes componentes de um sistema e as interfaces entre 
elas. É um conjunto integrado de procedimentos, sendo que as partes do 
computados poderão estar inseridos ou não. 
Na elaboração de um DFD, utilizaremos quatro símbolos que nos permitirão, 
debater e apresentar ao usuário todo o processo, sem assumir nenhum 
compromisso com implementações e demostrar a sua fluência, sem a 
preocupação com a hierarquização e tomadas de decisão. 
São os seguintes símbolos utilizados na elaboração de um DFD 
 
Elaborando um DFD 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Quadrado duplo = Entidade 
Externa/Origem ou destino de Dados. 
Retângulo com cantos arredondados = 
Processo que transforma o Fluxo dos 
Dados. 
Retângulo aberto = Depósito de 
Dados 
Seta ou vetor = Fluxo de Dados 
Módulo II – O ciclo de vida dos Sistemas 
Faculdades Doctum – Sistemas de Informação Página 39
 
 
 
 
 
Suponhamos que uma distribuidora de produtos farmacêuticos nos contratou para 
analisar seu processo atual e verificar como expandir suas operações e melhorar 
seu nível de serviço. 
A empresa em questão, RPC (Remédios Pelo Correio), fundada há cinco anos 
atua na distribuição de medicamentos, recebendo das farmácias os pedidos de 
medicamentos, fazendo encomenda aos laboratórios, com desconto, e atendendo 
ao pedido no ato do recebimento do dos remédios dos laboratórios. O processo é 
todo controlado manualmente através do preenchimento de formulários pré-
impressos. Atualmente o volume de negócios atinge 150 pedidos por dia, cada um 
com um média de 5 medicamentos, e um valor de R$ 500,00 em média. A 
administração pretende expandir as operações através da estocagem dos 100 
medicamentos mais solicitados e atendendo solicitações de clínicas e médicos 
diretamente. As encomendas poderão ser feitas de qualquer ponto do Estado via 
telefone ou pelo correio. 
O volume de negócios dependerá, logicamente, de fatores como divulgação do 
serviço, rapidez na entrega, confiabilidade, etc., mas a empresa espera aumentá-lo 
para 1000 negócios/dia, ou mais. 
No plano geral, podemos afirmar que, da mesma forma que o atual, o novo 
processo de trabalho da empresa acatará pedidos de remédios, fará a verificação 
no arquivo de