Apostila Banco de Dados

CENTRO DE CULTURA TCNICA DE IPATINGA LTDA
Rua Potiguar, 150 Bairro Iguau Ipatinga MG

CEP 35162-110 FONE: 3826-5198

FACULDADE PEREIRA DE FREITAS
Licenciatura em Matemtica 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 Informao Portaria MEC n 2640 D. O. U. 20/09/2002

Banco de Dados

Terceiro Perodo

Faculdades Doctum Sistemas de Informao Pgina
2
Introduo 6
Objetivos gerais 7
Plano Geral do Curso 8
APRESENTAO ...........................................................................................................................................................9
Mdulo 1: Conceitos bsicos 10
VISO GERAL ............................................................................................................................................................11
O QUE A ANLISE DE SISTEMAS ...............................................................................................................................12
Anlise ..................................................................................................................... 12
Anlise de Sistemas ................................................................................................. 12
Conceito de Sistemas .............................................................................................. 12
Tipos de Sistemas .................................................................................................... 13
BREVE HISTRICO ......................................................................................................................................................15
PROBLEMAS ENCONTRADOS NO DESENVOLVIMENTO DE SISTEMAS ...........................................................................15
A Produtividade ...................................................................................................... 16
A Confiabilidade ..................................................................................................... 16
A Manutenibilidade ................................................................................................. 16
A Eficincia ............................................................................................................. 16
A Portabilidade ........................................................................................................ 16
A Segurana ............................................................................................................ 16
REVISO ....................................................................................................................................................................18
Mdulo 2: O ciclo de vida dos sistemas 19
VISO GERAL ............................................................................................................................................................20
DEFINIO DO CICLO DE VIDA DO SISTEMA ................................................................................................................21
O Ciclo De Vida De Projeto Estruturado ................................................................ 22
Levantamento .............................................................................................................................................................. 22
Propsito da anlise .................................................................................................................................................... 23
Projeto ......................................................................................................................................................................... 23
Construo .................................................................................................................................................................. 24
Controle De Qualidade ................................................................................................................................................ 24
Descrio Dos Procedimentos ..................................................................................................................................... 24
Gerao De Teste De Aceitao ................................................................................................................................. 24
Implantao ................................................................................................................................................................. 25
Manuteno ................................................................................................................................................................. 25
FASES DO CICLO DE VIDA ...........................................................................................................................................27
Levantamento (Estudo Preliminar) ......................................................................... 27
Objetivos: .................................................................................................................................................................... 27
Passos para Implementao: ........................................................................................................................................ 27
Tcnicas Utilizadas ..................................................................................................................................................... 27
Produtos Gerados: ....................................................................................................................................................... 27
ANLISE (REPRESENTAO DA SOLUO, PROJETO LGICO) .....................................................................................28
Objetivos ................................................................................................................. 28
Passos para Implementao..................................................................................... 28
Tcnicas Utilizadas ..................................................................................................................................................... 28
Produtos Gerados ........................................................................................................................................................ 28
REVISO ....................................................................................................................................................................29
Mdulo 3: Ferramentas para definio do ambiente 30
VISO GERAL ............................................................................................................................................................31
FERRAMENTAS UTILIZADAS NO DESENVOLVIMENTO DE SISTEMAS ............................................................................32
Declarao dos objetivos ........................................................................................ 32
Diagrama de Contexto ............................................................................................. 32

3
Lista De Eventos ..................................................................................................... 33
Diagrama de entidade e relacionamento - DER ...................................................... 35
Diagrama De Transio De Estados (Dte) .............................................................. 35
Exemplo de DTE ......................................................................................................................................................... 36
Elaborao Do Diagrama De Transio De Estados ................................................................................................... 36
MODELO AMBIENTAL ................................................................................................................................................38
Diagrama de Fluxo de Dados .................................................................................. 38
Elaborando um DFD ................................................................................................................................................... 38
Entidade ................................................................................................................... 41
Fluxo de Dados ....................................................................................................... 41
Processo ................................................................................................................... 42
Depsito de Dados .................................................................................................. 42
Dicionrios de Dados .............................................................................................. 43
Regras para Formao de Nomes ................................................................................................................................ 43
REVISO ....................................................................................................................................................................44
Mdulo 4: O Modelo de Dados 45
VISO GERAL ............................................................................................................................................................46
O QUE MODELO DE DADOS? ...................................................................................................................................47
Componentes do Modelo de Dados ........................................................................ 47
Entidade ................................................................................................................... 47
Representao Grfica ................................................................................................................................................ 48
Atributo ....................................................................................................................................................................... 48
Chave de Identificao ................................................................................................................................................ 48
Lista de Entidades ....................................................................................................................................................... 48
Representao Grfica ................................................................................................................................................ 49
Tipos de Entidade ....................................................................................................................................................... 50
Tipos de Relacionamento ........................................................................................ 50
Tipos de Chave ........................................................................................................ 51
EXERCCIOS ...............................................................................................................................................................52
Mdulo 5. Projeto de BD utilizando o modelo Entidade Relacionamento (ER) 53
MODELO DE DADOS CONCEITUAL DE ALTO NVEL ....................................................................................................54
ENTIDADES E ATRIBUTOS...........................................................................................................................................55
TIPOS E INSTNCIAS DE RELACIONAMENTO ...............................................................................................................55
GRAU DE UM RELACIONAMENTO ...............................................................................................................................55
OUTRAS CARACTERSTICAS DE UM RELACIONAMENTO ..............................................................................................56
Relacionamentos como atributos ............................................................................ 56
Nomes de papis e Relacionamentos Recursivos ................................................... 56
Restries em Tipos Relacionamentos ................................................................... 57
Tipos Entidades Fracas ........................................................................................... 58
Subclases, Superclases e Especializaes ............................................................... 61
Especializao ......................................................................................................... 62
Generalizao .......................................................................................................... 63
Lattice ou Mltipla Herana ................................................................................ 66
REVISO ....................................................................................................................................................................67
Mdulo 6: Normalizao 68
VISO GERAL ............................................................................................................................................................69
O QUE NORMALIZAO ? ........................................................................................................................................70
Anomalias de Atualizao ...................................................................................... 70

4
Dependncia Funcional ........................................................................................... 70
Dependncia Funcional Composta ou Completa .................................................... 71
Dependncia Funcional Transitiva ......................................................................... 71
Primeira Forma Normal (1FN) ................................................................................ 71
Entidade no normalizada ........................................................................................................................................... 72
Entidades da 1FN ........................................................................................................................................................ 72
Segunda Forma Normal (2FN) ................................................................................ 72
Entidade na 2FN.......................................................................................................................................................... 73
Terceira Forma Normal (3FN) ................................................................................ 73
Simplificao do Processo de Normalizao .......................................................... 75
Regras Prticas ........................................................................................................ 75
VISO GERAL CONSOLIDAO DE MODELOS DE DADOS ...........................................................................................76
O que Consolidao? ............................................................................................ 76
Trabalhos Executados na Consolidao ................................................................. 76
REVISO ....................................................................................................................................................................77
EXERCCIOS ...............................................................................................................................................................78
Mdulo 7: Projeto (especificao da Soluo para o projeto Fsico) 81
VISO GERAL ............................................................................................................................................................82
Objetivos do projeto fsico ...................................................................................... 83
Passos para Implementao..................................................................................... 83
Definio de ambiente. ................................................................................................................................................ 83
Projeto fsico da base de dados. .................................................................................................................................. 83
Detalhamento dos processos. ...................................................................................................................................... 83
Definio dos mecanismos de segurana e auditoria. ................................................................................................. 83
Validao da especificao da soluo ....................................................................................................................... 83
Tcnicas Utilizadas ................................................................................................. 83
Produtos Gerados .................................................................................................... 83
Construo ............................................................................................................... 83
Objetivos ..................................................................................................................................................................... 83
Passos para Implementao ......................................................................................................................................... 84
Tcnicas utilizadas .................................................................................................. 84
Implantao ............................................................................................................. 84
Manuteno ............................................................................................................. 85
Normas e padres de construo da documentao ............................................... 86
Padres de nomenclatura ........................................................................................ 86
Regras Gerais .......................................................................................................... 87
rea de Teste e Produo............................................................................................................................................ 87
Funes Genricas ...................................................................................................................................................... 87
Arquivo de Configuraes .......................................................................................................................................... 87
Tabelas ........................................................................................................................................................................ 87
Telas ............................................................................................................................................................................ 87
Menu ........................................................................................................................................................................... 88
Botes ......................................................................................................................................................................... 88
Mensagens ................................................................................................................................................................... 88
Relatrios .................................................................................................................................................................... 88
Programas ................................................................................................................................................................... 88
Lgica ......................................................................................................................................................................... 89
Padres de documentao ....................................................................................... 89

5
Ajuda on line ........................................................................................................... 89
Esquematizao dos Mdulos do Sistema ................................................................................................................... 89
Descrio dos Mdulos do Sistema e Esquematizao de suas Funes .................................................................... 89
Descrio das Funes ou Operaes do Mdulo do Sistema .................................................................................... 89
Descrio dos Relatrios ............................................................................................................................................. 89
Sobre o sistema ........................................................................................................ 89
Descrio do Sistema .................................................................................................................................................. 89
Equipe Envolvida ........................................................................................................................................................ 89
Crditos ....................................................................................................................................................................... 90
Manual Tcnico ....................................................................................................... 90
Introduo ................................................................................................................................................................... 90
Diagrama de Contexto ................................................................................................................................................. 90
Diagrama de Fluxo de Dados ...................................................................................................................................... 90
Diagrama de Entidades e Relacionamentos ................................................................................................................. 90
Diagrama de Blocos .................................................................................................................................................... 90
Dicionrio de Dados.................................................................................................................................................... 90
Referncia Cruzada ..................................................................................................................................................... 91
Relatrios .................................................................................................................................................................... 91
REVISO ....................................................................................................................................................................92
Mdulo 8: Ferramentas CASE 93
FERRAMENTAS CASE ................................................................................................................................................94

6
Introduo
Introduo

7
Objetivos gerais

Preparar o aluno para o
desenvolvimento de sistemas de
qualidade
Apresentar as principais ferramentas
utilizadas na construo do projeto
de sistemas
Trabalhar as regras e tcnicas da
modelagem de dados

Introduo

8
Plano Geral do Curso
Apresentao do curso
9
Apresentao

Mdulo I - Conceitos bsicos
Mdulo II - O ciclo de vida dos sistemas
Mdulo III - Ferramentas para definio
do ambiente
Mdulo IV - O modelo de dados
Mdulo V - Normalizao
Mdulo VI - Caractersticas projeto
fsico

10
Mdulo 1: Conceitos bsicos

Mdulo I Conceitos bsicos

11
Viso Geral

Definio de Anlise de Sistemas
Conceito de sistemas e tipos de
sistemas
Histrico da Anlise de sistemas
Principais problemas encontrados no
desenvolvimento de sistemas


12
O que a Anlise de sistemas

O computador tem sido nos ltimos anos, o principal catalisador da revoluo
administrativa por que vem passando a empresa no mundo inteiro. Poderamos
historiar a evoluo do seu uso em trs estgios que denominaramos: aplicaes
isoladas, sistemas integrados e sistemas de informaes.
No primeiro estgio, colocou-se um elemento dentro da empresa capaz de
desenvolver clculos, processando e imprimindo dados a alta velocidade. Nesta
fase, as aplicaes eram transpostas para o computador segundo processos
similares aos manuais usados at ento. Dessa forma, aplicaes como folha de
pagamento, controle de estoques, contabilidade, oramentos, eram atendidas
isoladamente, no se dando maior importncia s duplicidades de processos e
dados.
Motivada pela evoluo tecnolgica e pela prpria especializao da mo- de- obra
existente, surgiu entre os homens de processamento de dados a tendncia para o
desenvolvimento de sistemas integrados. Nesse segundo estgio, despontou a
preocupao em se evitar redundncia de dados nos diversos arquivos e a
utilizao da capacidade de transferir informaes, via computador, de uma
aplicao para outra.
Aliando-se essa possibilidade de integrao Teoria de Sistemas, surgiu a
tendncia atual em processamento de dados - o enfoque sistmico (terceiro
estgio). A utilizao de sistemas de informao veio dar ao computador uma nova
dimenso, transformando-o de mero processador de dados em elemento
preponderante na racionalizao e na dinamizao do trabalho na empresa,
modificando, inclusive, o prprio conceito de Centro de Processamento de Dados.
Nos dois primeiros estgios o computador era considerado como um fim e
sua filosofia de utilizao era ditada pelos tcnicos de computao. No estgio
atual, ele passou a ser uma ferramenta a servio da empresa.
Anlise
Derivado do grego analein - desatar, soltar, significa dissoluo de um
conjunto em suas partes. Em sentido amplo, empregam-se os termos anlise e
analisar como sinnimos de exame e examinar, pesquisa e pesquisar, verificao
e verificar.
Anlise de Sistemas
Representa o estudo detalhado de uma rea de trabalho (processo), que
antecede uma ao que, quase sempre, implica no desenvolvimento de um
conjunto de programas integrados(sistema) destinado execuo controle e
acompanhamento do processo.
Conceito de Sistemas
Sistema significa todo e qualquer conjunto de peas. rgos ou instrues
com funes especficas, com atividades predeterminadas, que integradas, levam
consecuo de um certo objetivo.
Poderamos conceituar um sistema como sendo um conjunto de partes
coordenadas, que concorrem para a realizao 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 possvel associar
determinado sistema a um sistema maior, do qual ele parte integrante. O ser
humano, por exemplo, que composto de uma srie de subsistemas, como
sistema nervoso, o sistema muscular etc., est por sua vez, inserido em sistemas
maiores, como a famlia, a organizao a que pertence, etc.
Devemos ter em mente cinco consideraes bsicas quando pensamos
em um determinado sistema:

Os objetivos totais do sistema;

13
O ambiente do sistema;
Os recursos do sistema;
Os componentes do sistema;
A administrao do sistema.

Ao analisarmos os objetivos do sistema, devemos ter muita cautela, pois
muitas vezes, os objetivos reais do sistema no correspondem aos objetivos
declarados apregoados pelos elementos que compem o sistema. Os objetivos
declarados podem s vezes idealizar, racionalizar, distorcer, omitir, ou mesmo
esconder aspectos essenciais do funcionamento do sistema.
Geralmente no h concordncia, entre os elementos do sistema, com
relao aos objetivos que eles atribuem ao sistema. O reitor de uma universidade,
por exemplo, pode descrever o propsito de sua instituio como sendo o de
formar lderes para o pas; o vice-reitor acadmico pode ver como objetivo a
qualidade do ensino; um coordenador de ps-graduao pode objetivar o
desenvolvimento de trabalhos de pesquisa e, finalmente, um professor de
Engenharia, o treinamento tcnico dos jovens, visando capacit-los a obter um
bom emprego.
O ambiente do sistema o conjunto de elementos situados fora do
sistema, que satisfaam uma das condies:

uma mudana 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 pas, fazem parte do sistema editora. Os leitores
dos livros publicados so parte do ambiente do sistema.
Os recursos do sistema so os meios de que o sistema necessita para
desempenhar as suas funes. Os recursos, ao contrrio do ambiente, esto sob
controle do sistema. Os recursos necessrios para operar uma empresa, por
exemplo, poderiam ser classificados em: dinheiro, equipamento, instalaes,
pessoal, material, suprimentos e servios.
Os componentes do sistema so os elementos responsveis pelo
cumprimento das diversas misses essenciais ao funcionamento do sistema.
Poderamos, por exemplo, classificar como componentes de uma empresa as
funes de pesquisa, produo, marketing, finanas e pessoal.
A administrao do sistema responsvel pela elaborao, implantao e
acompanhamento dos planos que, em funo do ambiente existente, alocaro aos
diversos componentes os recursos disponveis, de modo que os objetivos do
sistema sejam alcanados com o mximo rendimento.
Tipos de Sistemas

Sistemas Naturais

- Sistemas Estelares (galxias, sistemas solares, etc.)
- Sistemas Geolgicos (rios, cadeias de montanhas etc.)
- Sistemas Moleculares (organizaes complexas de tomos)

Sistemas feitos pelo Homem

- Sistemas Sociais(organizaes de leis, doutrinas, costumes, etc.)
- Sistemas de Transporte (redes rodovirias, canais, linhas areas,
petroleiros, e semelhantes).
- Sistemas de Comunicao (Telefone, telex, sinais de fumaa, sinais
manuais, etc.)
- Sistemas de Manufatura (Fbricas, linhas de montagem, etc.)
- Sistemas Financeiros (contabilidade, inventrios, livros-razo, controle de
estoque, entre outros)


14
Sistemas Automatizados

- Hardware de computadores - UCP, terminais, impressoras, unidades de
fita magnticas, etc.
- Software de computadores - programas de sistemas, como sistemas
operacionais, sistemas de bancos de dados e programas de controle de
telecomunicaes, alm dos programas aplicativos que executam as
funes desejadas pelo usurio.
- Pessoas - aquelas que operam o sistema, que fornecem as entradas e
utilizam as sadas, e as que desempenham atividades de processamento
manual em um sistema.
- Dados - as informaes que o sistema conserva por um perodo de
tempo.

15
Breve histrico
Seqncia cronolgica e evoluo das tcnicas estruturadas:

Problemas encontrados no desenvolvimento de sistemas
Incio da dcada de 70
PROGRAMAO ESTRUTURADA
Convenes da Codificao Estruturada
Programao top-down
Parnas, Ocultao da Informao
Dijkstra, Nveis de Abstrao
Wirth, Refinamento Gradual
Meados da dcada de 70
PROJETO ESTRUTURADO
Yordon/Constantine, Projeto estruturado
Jackson, Metodologia de Projeto
Warnier-Orr, Metodologia de Projeto
Fins da dcada de 70
ANLISE ESTRUTURADA
De Marco, Anlise Estruturada
Gane e Sarson, Anlise Estruturada
SADT
Linguagem para Especificao de projeto
TCNICAS DE BANCO DE DADOS
Codd, Terceira Forma Normal
Modelagem de Dados

Incio da dcada de 80
TCNICAS AUTOMATIZADAS
HOS, Verificao Axiomtica
Modelagem Automtica de Dados
Modelos Inteligentes de Dados
Linguagens No-Procedimentais
Diagramas de Ao
Fins da dcada de 80
TCNICAS CASE
Martin, Engenharia da Informao
Bancadas de Trabalho Grficas para
Analistas de Sistemas
Editores de Diagramas de Ao para
Linguagens de Quarta Gerao
Sistemas Baseados em Regras
Apoios a projeto com Checagem de
Verificao
Especificaes a partir das quais o
Cdigo Gerado Automaticamente


16
Atualmente os maiores problemas enfrentados pelas empresas, no tocante a
desenvolvimento de sistemas, so:

A Produtividade
Um dos maiores problemas em empresas de desenvolvimento de software
o tempo necessrio 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 tcnicas, como por
exemplo:

Contratao de mais programadores e analistas de sistemas;
Contratao de mais programadores e analistas de sistemas mais
talentosos, oferecendo-lhes melhores condies de trabalho;
Deixar os usurios desenvolver seus prprios sistemas;
Adotar melhores linguagens de programao;
Atacar os problemas da manuteno;
Controles de engenharia de software;
Ferramentas automatizadas para desenvolvimento de sistemas.

A Confiabilidade
Um sistema concebido com erros demandar mais tempo para ser
concludo, uma vez que o tempo que seria gasto com o desenvolvimento ser
destinado para a depurao dos erros.

A Manutenibilidade
Em torno de 50 a 80% do trabalho de equipes de CPDs de empresas
voltado para a manuteno de sistemas, como por exemplo: reviso, modificao,
converso, depurao ou qualquer outro de tipo de alterao. Os sistemas ainda
no so suficientemente documentados o bastante ou as linguagens ainda no
poderosas o bastante para se evitar essa perca de tempo to grande em
manutenes que no acabam mais.

A Eficincia
Os sistemas devem ser desenvolvido visando a agilidade nas tarefas
anteriormente executadas, ou seja, eles devem ser estruturados de forma a
funcionar com uma considervel taxa de retorno. Esse tipo de problema mais da
competncia 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 mudanas do hardware, um sistema no pode ser desenvolvido para
rodar apenas em um tipo de mquina, ele deve suportar esse tipo de mudana
no gerando conflitos entre software e hardware.

A Segurana
Com a crescente tendncia de trabalhos em rede, etc, fica cada vez mais
necessria a segurana nos softwares, ento os Centros de Processamento de
Dados das empresas esto cada vez mais preocupados com a invaso dos
hackers ou at mesmo de pessoas que no tenham a inteno de prejudicar mas

17
que sem querer consigam entrar nos sistemas dessas empresas e tenham
acessos aos dados.
A Metodologia de Desenvolvimento de Sistemas (MDS) consiste na
adoo de um ciclo de vida de sistemas formalmente, padronizando
procedimentos/atividades e tcnicas, utilizando ferramentas e gerando produtos.
A adoo de uma MDS de vital importncia para o desenvolvimento de
sistemas, pois trata-se da organizao do trabalho que est sendo desenvolvido.
Alm da gerao de uma documentao rica, que auxiliar tanto no decorrer do
desenvolvimento quanto nas futuras manutenes, a MDS proporciona, em
qualquer fase do projeto, uma viso do estado atual; oferece subsdios para o
acompanhamento produtivo de todo o desenvolvimento. Alm de minimizar riscos
de desenvolvimento de sistemas, a MDS tambm conduz gerao de um
sistema de qualidade, adequado e dentro dos prazos e custos previstos, elevando
o nvel da produtividade das equipes tcnicas pois formaliza a distribuio das
tarefas entre os envolvidos, melhorando o relacionamento com a comunidade
usuria. Atravs dessa organizao que a MDS sugere, conseguiremos melhorar o
controle de tarefas e recursos padronizando tarefas, documentao, tcnicas e
ferramentas, e em cada fase ela tambm introduz pontos de verificao
(reviso/aprovao).
Conclumos ento que a utilizao de uma MDS vital para a gerao de
sistemas, haja vista sua forma organizada e pela documentao que ela sugere.

18
Reviso

1)O que significa Anlise de Sistemas?

2)O que um sistema? D exemplo de 5 sistemas.

3)Quais so 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.

19

Mdulo 2: O ciclo de vida dos sistemas

20
Viso Geral

Definio do ciclo de vida do sistema
Fases do ciclo de vida
Apresentao geral do Modelo lgico

21
Definio do ciclo de vida do sistema
O ciclo de vida de um sistema tem como funo principal a definio
de atividades a serem executadas em um projeto de desenvolvimento de sistemas
e a introduo de pontos de verificao para o controle gerencial.
Todo analista deve possuir estas informaes para poder iniciar,
prosseguir e finalizar um ciclo de vida de um sistema. Lgico que quanto maior o
projeto mais objetivos teremos para analisar, para colocarmos em observao.
Em vista disso, todo ciclo de vida ser um modo, uma maneira pela
qual voc junto com seu projeto sero responsveis.
Os ciclos de vida so divididos de vrias maneiras, dependendo do
autor. Alguns levam em considerao a existncia de apenas dois ciclos de vida,
outros levam em considerao trs, quatro ou at mais ciclos.
O ciclo de vida definido por nossa equipe tem como razo de escolha
as seguintes vises:
- Poder passar para a fase seguinte sem que a anterior esteja
completa, no prejudicando o andamento do projeto;
- Baseia-se em tcnicas estruturadas de anlise;
- Provem de paralelismo/ simultaneidade de fases e
- Liberdade de processamento.

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 usurios, gerentes e pessoal da operao,
eles so indivduos ou grupos de indivduos que fornecem entradas equipe do
projeto e que so os ltimos receptores do sistema, eles interagem com as nove
atividades sendo resumida logo abaixo:

Levantamento

Essa atividade tambm conhecida como estudo de viabilidade ou
estudo inicial das atividades Tipicamente, comea quando um usurio solicita que
uma ou mais parte de sua atividade seja automatizadas. Os principais objetivos da
atividade de levantamento so os seguintes:
Identificar os usurios responsveis e desenvolver um escopo inicial
do sistema. Isso pode envolver a realizao de uma srie de entrevistas para ver
quais usurios esto envolvidos no projeto proposto e quais no esto. Pode
envolver, tambm, o desenvolvimento de um diagrama de contexto inicial e um
simples diagrama de fluxo de dados.
Identificar as atuais deficincias no ambiente do usurio. Consistir,
habitualmente, em uma lista narrativa simples das funes que estejam faltando
ou que estejam atuando de modo insatisfatrio no sistema atual.
Estabelecer metas e objetivos para um novo sistema. Isso pode ser
tambm uma lista narrativa simples constituda pelas funes existentes que
CICLO DE VIDA ESTRUTURADO
LEVANTAMENTO
ANLISE
PROJETO
IMPLANTAO
MANUTENO
CONSTRUO

23
necessitem ser reimplementadas , novas funes que necessitem ser
acrescentadas, e critrios de desempenho para o novo sistema.
Determinar se possvel automatizar o sistema e, se assim for,
sugerir alguns esquemas aceitveis. Isto envolver algumas estimativas grosseiras
e aproximadas do cronograma e do custo de construo de um novo sistema e
dos benefcios a serem obtidos. Apesar da gerncia e dos usurios, 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 estgio primitivo do projeto.
Preparar uma previso do projeto que ser usada para conduzir o
restante do projeto. A previso do projeto incluir toda a informao listada acima,
bem como identificar o gerente responsvel do projeto. Pode descrever, tambm,
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 no ser tambm
uma atividade formal. Entretanto, mesmo que no venha a consumir muito do
tempo ou dos recursos o levantamento uma atividade crtica: ao fim, a gerncia
pode decidir cancelar o projeto se ele no parecer atrativo do ponto de vista
custo/benefcio.
Como analista de sistemas, voc pode ou no estar envolvido no
levantamento. O usurio, juntamente com os elementos dos nveis apropriados de
gerncia, 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 usurio muitas vezes solicitar ao analista de sistemas
que se envolva to logo seja possvel.

Propsito da anlise
O principal propsito da atividade da anlise transformar as suas
duas principais entradas, critrio do usurio e previso do projeto, em uma
especificao estruturada. Isso envolve a modelagem do ambiente do usurio com
diagramas de fluxo de dados, diagramas de entidades relacionamentos, diagramas
de transies de estado e as outras ferramentas.
O Processo passo a passo da anlise 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 descrio formal do que o novo sistema deve fazer,
independente da natureza da tecnologia que ser usada para implementar aqueles
requisitos.
Em acrscimo ao modelo do sistema descrevendo os requisitos do
usurio, um mais cuidadoso e detalhado conjunto de oramento e clculos de
custo-benefcio preparado, geralmente, ao final da fase de anlise.

Projeto

A atividade de projeto ocupa-se da alocao de partes da
especificao 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 mdulos de
programa e interfaces entre esses mdulos para implementar a especificao
criada na atividade de anlise. Alm disso, a atividade de entidades-
relacionamento em um projeto de banco de dados.
O modelo de implementao do usurio descreve os problemas de
implementao que o usurio se sente firme o suficiente para no deix-los a
critrios dos projetistas e programadores dos sistemas. Os principais problemas
pelos quais o usurio normalmente est interessado so a especificao da
fronteira homem-mquina e a especificao da interface homem-mquina. A
fronteira homem-mquina 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-mquina uma descrio
do formato e da seqncia de entradas fornecidas pelos usurios humanos ao

24
computador, bem como o formato e seqncia das sadas fornecidas pelo
computador ao usurios.

Construo

Essa atividade inclui a codificao e a integrao de mdulos em um
resumo progressivamente mais complexo do sistema final. Desse modo, essa
atividade inclui a programao estruturada e a implantao top-down.
Como podemos imaginar essa uma atividade que tipicamente o
analista no est envolvido, embora existam alguns projetos onde a anlise de
sistemas, o projeto e a implementao so feitos pela mesma pessoa.
Ns tambm definimos como fase da implementao as seguintes
fases:

Controle De Qualidade

O controle de qualidade conhecido tambm como teste final ou
teste de aceitao. Essa atividade exige como entrada os dados do teste de
aceitao gerados na fase anterior e um sistema integrado produzido na fase de
implementao.
O analista de sistema pode estar envolvido na atividade de controle
de qualidade, mas isto normalmente no acontece. Um ou mais membros da
organizao usuria pode assumir a responsabilidade, ou qualquer outro
departamento da organizao.
Observe que importante executar atividades de controle de
qualidade em todas as fases iniciais para assegurar que elas esto sendo
realizadas em um nvel apropriado de qualidade. Desse modo, a atividade controle
de qualidade deve ser realizada atravs das atividades de anlise, projeto e
programao para assegurar que o analista est desenvolvendo especificaes de
alta qualidade, o projetista est desenvolvendo um projeto de alta qualidade e o
programador est escrevendo cdigos de alta qualidade. Portanto esta atividade
identificada aqui meramente, o teste final da qualidade do sistema.

Descrio Dos Procedimentos

O analista tem que se preocupar com o desenvolvimento de um
sistema inteiro, como um todo e no somente, a parte automatizada. Desse modo,
uma das atividades importantes a serem realizadas a gerao de uma descrio
formal das partes do novo sistema que sero manuais, e de uma descrio de
como os usurios realmente vo interagir com a parte automatizada do novo
sistema.
A sada desta fase ou atividade o manual do usurio.

Gerao De Teste De Aceitao

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 anlise, projeto e
programao. Mesmo no caso de ter sido executada uma tarefa perfeita de anlise
de sistemas, projeto e programao, preciso algum esforo para verificar se no
h erros. Se, por outro lado, tiver sido feito um mau servio, ento os testes
tornam-se interativos: a primeira rodada de testes denuncia a presena de erros e
as rodadas subsequentes verificam se os programas corrigidos j esto
funcionando corretamente.
O processo de desenvolvimento de casos de testes de aceitao
pode ser executado em paralelo com as atividades de implementao de projeto e
programao, de modo que, quando os programadores tiverem terminado seus

25
programas e executado seus prprios testes locais, a equipe usurio/analista
estar pronta para seus prprios casos de testes.
Alm do conceito bsico de que a descrio dos requisitos do usurio
forma a base dos casos de teste finais, o analista deve conhecer os vrios 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 funes.

Testes de Recuperao: O objetivo deste tipo de teste verificar se
o sistema pode se recuperar-se adequadamente de vrios tipos de
falhas.

Testes de Desempenho: Verifica se o sistema pode manipular o
volume de dados e transaes recebidas e especificadas no modelo
de implementao do usurio, 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 trs coisas: planos de
testes, descries de testes e procedimentos de testes.
Um plano de testes um documento organizado que pode conter as
seguintes informaes:

Objetivo do teste: qual o objetivo do teste e qual parte do sistema
ser testada;
Localizao e cronograma do teste: onde e quando o teste ser
realizado;

Descries de teste: descrio das entradas que sero introduzidas
no sistema e as sadas e resultados antecipados;

Procedimentos de testes: descrio de como os dados de testes
devem ser preparados e submetidos ao sistema, como os resultados
de sadas devem ser colhidos, como os resultados dos testes devem
ser analisados e de qualquer outro procedimento operacional que
deva ser observado.
Implantao

As entradas para esta atividade so: o manual do usurio, o banco de
dados convertido se houver e o sistema aprovado. Em alguns casos, a instalao
pode significar simplesmente, uma passagem noturna para o novo sistema, sem
nenhuma comemorao ou fanfarra; em outros casos, a instalao poder ser um
processo gradual, com um grupo de usurios aps o outro recebendo os manuais
do usurio, do hardware e sendo treinado no uso do novo sistema e, realmente
comeando a us-lo.

Manuteno

No se pode conservar atualizado um sistema e a documentao a
ele associada se essa documentao no estiver correta. Precisamos garantir que,
quando um sistema entrar em operao, todos os documentos a ele relativos
estejam completos, consistentes, corretos e atualizados. Para que a manuteno
continuada tenha sucesso, essas diretrizes devem ser impostas e uma pessoa ou
grupo independente deve verificar se a documentao est correta antes que o
sistema seja posto em operao.
Devemos ainda, nos assegurar que existe um mecanismo para
executar modificaes continuadas nesses documentos, ou seja a especificao

26
deve ser vista como um documento vivo, sujeito a alteraes constantes, apesar
de controladas.
A primeira regra da manuteno de sistemas esta: qualquer
modificao proposta do sistema operativo atual deve, em todos os casos, iniciar-
se por um exame dos impactos na especificao de requisitos deste sistema.
Qualquer modificao deve ser ilustrada, documentada e verificada com o usurio,
fazendo-se as adequadas modificaes no modelo do sistema. Isso costuma ser
feito pelo preenchimento de um formulrio conhecido como solicitao de
alterao de sistema.
Qualquer modificao no sistema no ser livre. possvel que
algumas modificaes sejam mnimas e s requeiram alguns minutos de trabalho
para serem incorporadas. Entretanto, a pessoa ou grupo responsvel pela
alterao tem a obrigao de escrever a declarao de impacto: uma declarao
precisa e detalhada das mudanas que tero de ser feitas na especificao do
sistema para implementar a modificao proposta. Juntamente com isso, deve
haver uma declarao do impacto econmico: uma declarao do custo da
implementao da alterao e o benefcio estimado que derivar daquela
alterao.
Qualquer modificao feita em um sistema, normalmente resulta em
uma modificao no software e/ou hardware do sistema; pode tambm causar a
alterao dos manuais, dos procedimentos de operao e de vrios outros
componentes do sistema. Porm o documento mais importante a ser mantido
atualizado a DECLARAO DE REQUISITOS DO USURIO. Sem isso, as
futuras modificaes sero cada vez mais difceis de serem feitas e a mudana
para um novo sistema ser infinitamente mais dispendiosa, mais consumidora de
tempo e mais penosa do que normalmente seria.
No h qualquer dvida, de que se conseguir isto descrito acima,
tarefa bastante difcil.

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 Implementao:

1. Identificar as diretrizes e necessidades.
- Determinar os usurios 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 abrangncia/amplitude, fronteiras e interligao com
outros sistemas;
- Relatar impactos e mudanas que o projeto causar empresa;
- Relatar problemas e limitaes tais como: de legislao, de mercado,
ambientais, etc;
- Elaborar dicionrio de termos prprios visando dirimir dvidas e
padronizar conceitos;

3. Estudo da Viabilidade.
- Definio de alternativas;
- Anlise dos riscos implementacionais para cada alternativa;
- Anlise custo x benefcio.
- Custos de construo, instalao, operao e manuteno do
sistema
- Benefcios: tticos e operacionais;

4. Definir estratgia da anlise do sistema atual.
- Definir cronograma com pessoal envolvido e suas atribuies;
- Sugesto da melhor soluo.

5. Aprovar estudo preliminar.
- Avaliar a conformidade dos requisitos;
- Elaborar diagrama de contexto da situao atual e da proposta;
- Elaborar relatrio de viabilidade tcnica, anlise custo x benefcio;
- Reunir e apresentar.
Tcnicas Utilizadas
- Entrevistas;
- Reunies;
- Observao pessoal;
- Diagrama de contexto.
Produtos Gerados:
- Relatrio contendo todos os itens do levantamento
- Diagrama de contexto.

28
Anlise (Representao da soluo, projeto lgico)

Objetivos
- Coletar informaes do sistema atual;
- Elaborar requisitos do novo sistema;
- Modelar a soluo.

Passos para Implementao

1. Estudo do problema.
- Levantamento detalhado;
- Especificao de requisitos

2. Modelagem dos processos.
- Construo do DFD;
- Exploso do DFD em nveis.

3. Modelagem de dados.
- Construo do DER;
- Normalizao.

4. Construo do dicionrio de dados.
- Descrio dos fluxos;
- Descrio dos depsitos de dados;
- Descrio da lgica dos processos externos.

5. Reavaliao da estratgia de desenvolvimento.
- Redefinio do grupo de trabalho;
- Delimitao de tempo e recurso;
- Reviso;
- Apresentao;
- Avaliao.

Tcnicas Utilizadas

- Entrevistas;
- Reunies;
- DFD;
- DER;
- Dicionrio de dados.

Produtos Gerados
- DFD
- DER
- Dicionrio de Dados

29
Reviso

1)Quais so as fases do ciclo de vida de um sistema e faa um resumo explicando
sobre cada uma das fases.

2)Descreva quais so os objetivos , tcnicas utilizadas e produtos gerados na fase
de Levantamento.

3)Quais so os produtos gerados, objetivos e tcnicas utilizadas na fase de
Anlise.

30

Mdulo 3: Ferramentas para definio do
ambiente

Mdulo III Ferramentas para definio do ambiente
31
Viso Geral

Apresentao das ferramentas
utilizadas no desenvolvimento de
sistemas
Exemplos prticos e a utilizao das
ferramentasl

Mdulo II O ciclo de vida dos Sistemas
32
Ferramentas utilizadas no desenvolvimento de sistemas
As ferramentas utilizadas no processo de desenvolvimento de sistema podero ser
usadas e mescladas em diferentes metodologias, dependendo da complexidade
do sistema, do tempo para o desenvolvimento, dentre outros fatores que devero
ser avaliados criteriosamente pela equipe de desenvolvimento. Utilizaremos a
anlise essencial para caracterizar a utilizao das ferramentas mais utilizadas.

O Modelo Ambiental consiste de quatro componentes:
Declarao de Objetivos
Diagrama de Contexto
Lista de Eventos
Dicionrio de Dados Preliminar (opcional)

Declarao dos objetivos

Consiste de uma breve e concisa declarao dos objetivos do sistema.
dirigida para a alta gerncia, gerncia usuria ou outras pessoas no
diretamente envolvidas no desenvolvimento do sistema.
Pode ter uma, duas ou vrias sentenas mas no deve ultrapassar um pargrafo.
No deve pretender dar uma descrio 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 cobrana de clientes em atraso. Informaes sobre pedidos de
livros devem ficar disponveis para outros sistemas tais como: Marketing, Vendas
e Contabilidade.

O sistema AKD-MICO se prope a manipular as informaes sobre alunos
matriculados, cursos oferecidos e perodos letivos, de modo a permitir a avaliao
de cada aluno matriculado.


Apresenta uma viso geral das caractersticas importantes do sistema:
As pessoas, organizaes 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.

33

Lista De Eventos
uma relao dos estmulos 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 ESTMULO: um ativador de uma funo. a forma como o evento age
sobre o sistema. a conseqncia do fato de ter ocorrido um evento externo. a
chegada de um estmulo que indica que o evento ocorreu e isto faz com que o
sistema ento ative uma funo pr-determinada para produzir a resposta
esperada.

UMA RESPOSTA: o resultado gerado pelo sistema devido ocorrncia de um
evento. Uma resposta sempre o resultado da execuo de alguma funo interna
no sistema como conseqncia do reconhecimento pelo sistema de que um
evento ocorreu: Pode ser:

Um fluxo de dados saindo do sistema p/ uma entidade externa.
Uma mudana de estado em algum depsito de dados (o que eqivale a
incluso, excluso ou modificao de algum registro de um arquivo).
Um fluxo de controle saindo de uma funo para ativar outra funo.
Os eventos so 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 ocorrncia quando um ou vrios 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.
34
No disparado por nenhum fluxo de dados. como se o sistema dispusesse de
um relgio interno que determinasse a passagem do tempo.
Pode ocorrer que um evento temporal pea 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 no
representem o evento propriamente dito.

EXEMPLO:
1. Um relatrio dirio de todos os pedidos de livro solicitado s 09:00 h.
2. Fatura deve ser gerada s 15:00 h.
3. Relatrio 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
memria.
um caso especial de evento temporal no qual o estmulo externo ocorre em um
ponto imprevisvel no tempo.
Diferentemente do evento temporal, no esta associado com a passagem regular
do tempo de forma que o sistema o antecipe usando seu relgio interno.
Diferentemente tambm do evento orientado a fluxo, no mostra sua presena
atravs 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 nvel de ressuprimento do estoque atingido

IMPORTANTE: O fluxo de controle um fluxo de dados binrio, s tem 2 valores
possveis que so 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 posio 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

35
Cuidados tambm devem ser tomados no sentido de separar os eventos discretos
dos que foram empacotados juntos como um nico evento (ocorre freqentemente
em eventos orientados a fluxo).

Se em algumas ocorrncias do evento aparecer o elemento de dados
Identificao do vendedor e em outras no, separar em dois eventos.

e
VENDEDOR COLOCA PEDIDO

Diagrama de entidade e relacionamento - DER

No existe uma seqncia pr-definida para produo do Diagrama de Contexto e
Lista de Eventos. Pode-se comear por qualquer um dos dois e no final verificar
se esto consistentes um com o outro. A prxima etapa a construo do DER.
Exemplo de DER.
O DER a representao das associaes entre entidades. Neste diagrama no
se consegue visualizar como os dados so manipulados.
Ele ilustra a organizao dos dados a respeito do mundo real em termos de
entidades e relacionamentos entre as informaes, no representando a dinmica
de funcionamento do sistema.
O DER representa, atravs da simbologia grfica, o modelo conceitual de dados,
correspondendo a uma mquina de responder perguntas do ambiente
investigando, a partir da navegao atravs de entidades, relacionamentos e seus
atributos.

Diagrama De Transio De Estados (Dte)

DEFINIO

Representa a perspectiva dos controles. Mostra as transformaes de controle do
sistema no tempo.

CONCEITOS

Venda
TipoProduto Fornecedor
Client
e
Produto
ItemVenda
36
Estado: Um estado de um sistema representa uma situao, um cenrio ou um
modo de comportamento em que encontramos um sistema ao observ-lo em
determinado momento.

Transio: Uma transio representa a passagem do sistema de um estado para
outro. Assim ao acendermos ou ao apagarmos uma lmpada, estaremos
provocando uma transio de estado.

Ao: Uma ao representa a atividade do sistema que efetua a transio do
estado.

Condio: Uma condio representa a causa necessria para que haja a
transio de estado. Decorre da ocorrncia de um evento ou circunstncia que
propicia a transio de estado. Assim ao apertarmos o interruptor, provocamos a
condio para que seja executada a ao de acender ou de apagar a lmpada,
provocando desta forma uma transio de estado.

Exemplo de DTE

INTERRUPTOR INTERRUPTOR
FOI LIGADO FOI DESLIGADO

ASCENDER APAGAR A
LMPADA LMPADA

No diagrama acima podemos distinguir:

Dois estados; apagada e acesa
H duas transies possveis: de apagada para acesa e de acesa para
apagada.
H dois pares de condies/aes:
A condio interruptor foi ligado, que dispara a ao acender lmpada,
provocando a transio de estado de apagada para acesa
A condio interruptor foi desligado, que dispara a ao apagar lmpada,
provocando a transio de estado de acesa para apagada.

Elaborao Do Diagrama De Transio De Estados

Construir a lista de eventos do sistema
Ordenar os eventos cronologicamente
Para cada evento, identificar a transio de estado correspondente
Para cada transio de estado:

Identificar o estado de partida e o estado de chegada
Identificar a condio que provoca a transio de estado
Identificar a ao ativada pela ocorrncia da condio

APAGADA
ACESA
37
Para cada estado:

Verificar qual a transio para a qual ele o estado de chegada
Verificar se h transio de sada dele em condies normais e anormais

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 ocorrncia de um evento, ou
a necessidade de resposta a um evento, ou
ambos os casos.

Cada fluxo de sada deve ser uma resposta a um evento
Cada evento no temporal deve ter uma entrada para o sistema que permita que
este detecte que o evento ocorreu.

Cada evento deve:

Produzir uma sada imediata em sua resposta, ou
Armazenar dado para sada posterior (como resposta ou parte de uma resposta
de algum outro evento)
Causar uma mudana de estado no sistema (como indicado no diagrama de
transio de estado).

Diagrama de Fluxo de Dados

DFD uma representao em rede dos processos (funes) do sistema e dos
dados que ligam esses processos. Ele mostra o que o sistema faz e no como
feito. a ferramenta de demonstrao central da anlise 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 podero estar inseridos ou no.
Na elaborao de um DFD, utilizaremos quatro smbolos que nos permitiro,
debater e apresentar ao usurio todo o processo, sem assumir nenhum
compromisso com implementaes e demostrar a sua fluncia, sem a
preocupao com a hierarquizao e tomadas de deciso.
So os seguintes smbolos utilizados na elaborao de um DFD

Elaborando um DFD

Quadrado duplo = Entidade
Externa/Origem ou destino de Dados.
Retngulo com cantos arredondados =
Processo que transforma o Fluxo dos
Dados.
Retngulo aberto = Depsito de
Dados
Seta ou vetor = Fluxo de Dados
39

Suponhamos que uma distribuidora de produtos farmacuticos nos contratou para
analisar seu processo atual e verificar como expandir suas operaes e melhorar
seu nvel de servio.
A empresa em questo, RPC (Remdios Pelo Correio), fundada h cinco anos
atua na distribuio de medicamentos, recebendo das farmcias os pedidos de
medicamentos, fazendo encomenda aos laboratrios, com desconto, e atendendo
ao pedido no ato do recebimento do dos remdios dos laboratrios. O processo
todo controlado manualmente atravs do preenchimento de formulrios pr-
impressos. Atualmente o volume de negcios atinge 150 pedidos por dia, cada um
com um mdia de 5 medicamentos, e um valor de R$ 500,00 em mdia. A
administrao pretende expandir as operaes atravs da estocagem dos 100
medicamentos mais solicitados e atendendo solicitaes de clnicas e mdicos
diretamente. As encomendas podero ser feitas de qualquer ponto do Estado via
telefone ou pelo correio.
O volume de negcios depender, logicamente, de fatores como divulgao do
servio, rapidez na entrega, confiabilidade, etc., mas a empresa espera aument-lo
para 1000 negcios/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 remdios, far a verificao
no arquivo de disponveis, consultar, em outro arquivo, se o crdito do cliente
bom e far com que o remdio solicitado seja encaminhado ao cliente com a
respectiva fatura.
Demostraremos isso de forma grfica usando um diagrama de Fluxo de dados
lgico.

Analisando a figura, verificamos que, na verdade, ela nos diz muito pouco sobre o
sistema.
Os smbolos constantes da figura e os conceitos que representam encontram-se
no nvel lgico; um fluxo de dados pode estar fisicamente numa carta, numa fatura,
numa ligao telefnica, etc., ou seja, em qualquer lugar em que o dado passe de
uma entidade ou processo para outro. Um processo pode ser fisicamente um
escritrio repleto de pessoas verificando e recebendo pedidos, calculando
descontos, ou um programa, ou ainda uma combinao de atividades manuais e
automatizadas. Um depsito de dados pode ser um armrio de ao com gavetas,
um fichrio de cartes, uma fita magntica, um disquete. Utilizando os quatro
smbolos, podemos desenhar um quadro do sistema sem nos comprometermos
com sua implementao.
40
Vamos expandir processar pedidos para mostrar as funes lgicas que compe
o processo.
Observe o diagrama a seguir, onde representamos uma expanso do anterior,
demostrando os processos Verificar validade dos pedidos e Preparar requisio
par o laboratrio, alm de depsitos de dados para armazenar dados de clientes,
dados de laboratrios e dados dos pedidos pendentes, ou seja, aqueles que ficam
aguardando a quantidade tima para enderearmos o pedido ao laboratrio
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 laboratrios fornecedores
no iro cobrar nunca os medicamentos remetidos? E se os medicamentos e
quantidades remetidas pelos laboratrios no forem coerentes com as
solicitaes?
Vamos tentar incluir o aspecto Comparar remessa a pedidos.

Observe o prximo diagrama.

No demostraremos at aqui os movimentos dos remdios em si; para efeitos
didticos, os remdios so considerados dados e por isso no so representados
no DFD. A relao entre um DFD e um diagrama de fluxo de materiais no ser
41
abordada por enquanto. Atualmente s nos interessam os itens que representam
dados sobre remdios.
At agora, ningum 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 cobranas efetuadas pelos laboratrios.
Acreditamos que, com o que j foi visto at aqui, voc seria capaz, sozinho, de
expandir nosso DFD, contemplando esses processos.
No se esquea que cada uma das caixas de processo pode ser expandida num
diagrama de fluxo de dados de menor nvel, assim sendo, procure, ao fazer o
exerccio proposto, no descer a detalhes muito minuciosos. Sua preocupao
deve ser demonstrar em linhas gerais como seriam os processos de contas a
receber e contas a pagar.
Outro aspecto importante, no abordado nos DFDs apresentados so as
condies de erro.
No especificamos ainda o que acontece com o pedido de um cliente cuja situao
de crdito seja ruim, ou o que acontece quando o laboratrio nos manda uma
remessa e no localizamos nenhum pedido correspondente.
evidente que tais situaes precisam ser tratadas. Entretanto, se formos, desde
logo, nos prender ao tratamento de erros e excees, comprometeremos todo o
nosso trabalho. O detalhamento dessas questes deve ser adiado para os
diagramas de nvel inferior, para que no interfiram no quadro geral do sistema.
A concluso dos DFDs do sistema proposto, com toda a abrangncia, fica a cargo
de vocs, basta aplicar os recursos at aqui apresentados, observando entretanto
as seguintes convenes simblicas:

Entidade

Identificamos como entidade, na maioria das vezes, categorias lgicas de coisas
ou pessoas que representam uma origem ou destino de transaes (Clientes,
Fornecedores, Empregados, Etc.). Tambm podemos identificar como Entidades
fontes ou destinos especficos tais como Departamentos da empresa, Receita
Federal, Almoxarifado. comum adotarmos a terminologia Entidade Externa.
Quando um sistema recebe dados resultantes de outro, ou gera informaes que
serviro como dados de entrada para outro, esse outro sistema tambm
identificado como uma Entidade Externa.
O smbolo utilizado para representar j foi apresentado a voc.
Por conveno, a fim de simplificar as referncias e o processo de dicionarizao
dos dados, adicionamos como identificador de uma entidade uma letra minscula
no canto superior esquerdo do desenho ou a letra E maiscula e um nmero,
conforme abaixo:

Fluxo de Dados
Podemos associar cada fluxo de dados com um tubo por onde passam pacotes de
dados. Faremos referncia ao Fluxo de Dados identificando os processos,
entidades ou depsitos de dados das suas extremidades, anotando uma descrio
do seu contedo ao longo de sua extenso. Lembre-se que a descrio deve ser
mais clara possvel, de modo a simplificar o trabalho do usurio que ir realizar a
reviso do DFD.
Observe um exemplo de referncia e descrio de Fluxo de Dados:

c

Gerncia

29
Analisar
Vendas
Relatrio de Vendas
Referncia do Fluxo de dados 29 - C
Descrio do fluxo de dados: Relatrio de Vendas
42

Processo
Logicamente, necessrio descrever a funo de cada processo, e, para facilitar
atribuir uma identificao nica para cada um, buscando, na medida do possvel,
associ-lo a um sistema fsico.
A identificao pode ser um nmero, inicialmente posicionado na posio mdia
superior da figura, no tendo nenhum outro significado alm de identificar o
processo. No h porque vincularmos a identificao com a descrio do
processo, pois alguns deles sero subdivididos em dois ou mais nas fases de
expanso - o que implicar no surgimento de novos nmeros. Entretanto, a partir
do instante que um processo recebe uma identificao, est no deve mais ser
modificada, sob a pena de comprometer o trabalho de dicionarizao dos dados,
exceto nos casos de desmembramentos e agrupamentos. Para simplificar o
entendimento da figura, podemos adicionar linhas divisrias, marcando claramente
o espao destinado identificao do processo, sua descrio e o local fsico onde
ser desempenhado.

Vale ressaltar que a descrio da funo deve ser sempre imperativa, composta
por um verbo ativo (verificar, extrair, recuperar, comparar), seguida de uma
clusula, simples e objetiva.
A identificao do local fsico onde a funo ser executa, opcional nos diagramas
de nvel mais abrangente, extremamente til a partir do instante em que a
anlise foi concluda e o projeto fsico do sistema est sendo desenvolvido, pois
denota o departamento ou programa que o desempenhar

Depsito de Dados

Convencionamos a identificao de um depsito de dados pela colocao de uma
letra D maiscula seguida de um nmero, na esquerda do desenho, separada da
descrio por uma linha vertical.

D1 Dados de Clientes

Identificao do processo
Local fsico onde ser
desempenhado
Descrio da funo
43

Dicionrios de Dados
O dicionrio de dados um repositrio de dados sobre os dados do software. Ele
dever conter a definio dos elementos que tornam o Modelo de Dados e o
Diagrama de Fluxo de Dados precisos, quais sejam:
- Fluxos de dados;
- Depsitos de Dados/Entidades;
- Atributos.

Regras para Formao de Nomes
- O nome deve ser formado por palavras separadas por sublinha at o mximo de
32 caracteres;
- Preferencialmente a nomeao deve ser feita de acordo com o usurio;
- Devem ser eliminados proposies e conjunes;
- Quando houver necessidade de abreviar uma palavra, observar que a abreviatura
seja clara, ou inclui-la no dicionrio.

44
Reviso

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 estmulo, a resposta, a
sada e se o evento temporal ou no temporal.

N Evento Estmulo Resposta Sada Tipo
01 Funcionrio de estoque
solicita compra do produto

02 Fornecedor solicita pedido de
cadastro

03 Funcionrio da loja solicita
pedido produto

04 Funcionrio de estoque
cadastra produto

05 Fornecedor solicita
encerramento ficha

06 Funcionrio Estoque exclui
cadastro de produto

45

Mdulo 4: O Modelo de Dados
46
Viso Geral

O que o modelo de dados
Componentes do modelo de dados
Entidades
Relacionamento
Chaves

47
O que Modelo de Dados?
Tambm conhecido como Diagrama E-R (Entidade -Relacionamento ). uma
forma de representao grfica do conhecimento que se tem sobre o ambiente
(realidade) qualquer. Mostra uma viso esttica das informaes (entidades) de
interesse e dos vnculos (relacionamentos) existentes entre elas.
Modelo de Dados Realidade
Descrever
Define

O modelo de dados uma nova forma de comunicao entre o tcnico de
processamento de dados e o usurio.
Essa nova forma de comunicao assegurar que :
modelo de dados conter todos os dados necessrios para suportar os
processos de responsabilidade do usurio.
modelo de dados conter os dados para suportar processos que sero
modificados ou introduzidos em um futuro prximo.
Componentes do Modelo de Dados
Entidade
algo, real ou abstrato, percebido no ambiente e sobre o qual nos interessa
armazenar dados.
Entidade so objetos(coisas) modeladas em funo dos papis que desempenham
em um sistema especfico.
Uma nica entidade pode desempenhar papis diferentes em sistemas diferentes
ou at em um mesmo sistema.

PESSOA: Prefeitura -- Contribuinte
Banco -- Cliente
Escola -- Aluno
Escola -- Professor
Corretora -- Inquilino

Coisas Tangveis Avio, casa, etc.
Funes Mdico, paciente, inquilino, departamento,etc
Incidentes Vo, acidente, chamada servios, ,etc(ocorrncia ou fato)
Interaes Compra, casamento, etc (contrato)

Exemplos:
Um objeto real (concreto)- Um equipamento, Material
Uma pessoa
48
Fornecedor Empregado
Um conceito abstrato
rgo, Cargo, Curso
Um evento
Recebimento de Material
Um relacionamento
Casamento

Representao Grfica
Um entidade representada num modelo de dados atravs de um
retngulo.

Atributo
um dos itens de dados que armazenamos sobre uma entidade.
Caracteriza ou qualifica uma determinada propriedade de uma entidade.
Exemplo:
So atributos da entidade EMPREGADO:

- MATRICULA
- NOME
- ENDERECO
- CPF
- DATA NASCIMENTO

Chave de Identificao

A chave de identificao de uma entidade definida por um atributo, ou conjunto
de atributos, cujos valores individualizam uma nica ocorrncia dessa entidade.
Exemplo:
A chave de identificao da entidade EMPREGADO o atributo MATRICULA.

Lista de Entidades

uma relao de entidades com seus respectivos atributos, utilizada para
documentar os trabalhos de anlise de dados.
Formada pelo nome da entidade seguida da relao de atributos que compem
entre parnteses, e seguindo a conveno abaixo:
- Cada atributo separado do outro pelo sinal de adio ( + ) ;
- O(s) atributo(s) que identificam a entidade devem estar no incio da
relao e sublinhados;

MATERIAL

FATURA

FORNECEDOR
49
- O(s) atributo(s) que ocorrem mais de uma vez (repetitivos) so
identificados por uma incluso entre parnteses.
Exemplo:
FATURA(NUMERO_FATURA + CODIGO_FATURA + (NUMERO_ITEM_FATURA
+ CODIGO_MATERIAL + QUANTIDADE_MATERIAL + PRECO_UNITARIO +
PRECO_ITEM_FATURA) + PRECO_TOTAL_FATURA).
Obs.: Podem haver mltiplos nveis de repetio.

Domnio
So os possveis valores que um atributo pode assumir.
Exemplo:
SEXO = [ M | F ]
Sexo pode assumir dos valores M (Masculino) ou F (Feminino)
Ocorrncia
Representa o nmero vezes que determinado atributo aparece em outra entidade.
Representao Grfica

Smbolos especiais colocados nas extremidades da linha que representa um
relacionamento.
Exemplo:

Uma REA LOTAO tem obrigatoriamente pelo menos 1 empregado;
Um EMPREGADO est vinculado obrigatoriamente a uma rea de LOTAO;
Um EMPREGADO pode ter vrios, um ou nenhum DEPENDENTE;
Um DEPENDENTE (se existir) est obrigatoriamente vinculado a um
EMPREGADO.
Um EMPREGADO pode ser GERENTE.
Um GERENTE um EMPREGADO
UMA OCORRNCIA OU
NENHUMA
UMA E SOMENTE UMA
OCORRNCIA
VRIAS, UMA OU
NENHUMA OCORRNCIA
PELO MENOS UMA
OCORRNCIA
DEPENDENT
E
EMPREGADO
AREA
LOTACAO
NIVEL
SALARIAL
EMPREGADO

GERENTE
50
Um EMPREGADO tem obrigatoriamente um NVEL SALARIAL;
Em um mesmo NVEL SALARIAL podemos ter vrios, um ou nenhum
EMPREGADO.
Tipos de Entidade
Entidade Primria
aquela cuja chave de identificao feita exclusivamente atravs de seus
atributos.

Entidade Dependente
aquela cuja existncia depende de outra, ou seja, parte da chave de
identificao da entidade est condicionada a da entidade da qual ela depende.

Entidade Associativa
aquela cuja chave de identificao obtida atravs da concatenao das chaves
de identificao das entidades que ela associa.
Tipos de Relacionamento
Relacionamento uma abstrao de um conjunto de associaes entre diferentes
coisas do mundo real.
Associaes montadas entre duas ou mais entidades.
Uma ocorrncia de um relacionamento liga ocorrncias especficas das entidades
participantes.

Entidade Relacionamento Entidade
Pessoa vive em apartamento
Inquilino aluga apartamento
Satlite viaja em rbita

Relacionamento de Dependncia

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

Categoria

Uma categoria uma ligao entre uma entidade e suas espcies (tipos), sendo
estas mutuamente excludentes.

Partio

um caso particular de categoria, na qual as espcies (tipos) de uma entidade,
no so mutuamente excludentes.

Relacionamento Normal
aquele que no pode ser enquadrado em um dos tipos abaixo:
-associativo
-Dependncia
- Categoria
- Partio
Auto-Relacionamento

51
aquele que ocorre entre uma mesma entidade.

Mltiplos 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 tambm entre as entidades B e C, porm nunca ao mesmo tempo.
Tipos de Chave
Chaves Candidatas

So as possveis chaves de identificao de uma nica ocorrncia de uma
entidade.
Exemplo
EMPREGADO (MATRICULA + NOME + CPF + ENDERECO + SALARIO )
So chaves candidatas os atributos:
- MATRICULA
- CPF

Chave Primria
uma das chaves candidatas, selecionada por melhor convenincia (facilidade de
utilizao, menor possibilidade de erros, etc. ...).
Exemplo
EMPREGADO (MATRICULA + NOME + CPF + ENDERECO + SALARIO )
Chaves candidatas:
- MATRICULA
- CPF
Chave Primria escolhida - MATRICULA
Chave Estrangeira
Conjunto de um ou mais atributos de uma entidade que so chave primria 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
52
Exerccios

1)Fazer um modelo de dados para o seguinte contexto:

O clube Filadlfia oferece vrias modalidades de esportes aos seus associados e
tem um big restaurante, alm de sauna, pedalinho, quadras cobertas, etc.
Um mesmo scio pode ter vrios dependentes e tanto os scios quanto
seus dependentes podem se inscrever nas vrias modalidades de esportes que o
clube oferece, podendo freqentar vrios simultaneamente.
emitido um carnet para pagamento mensal.
O restaurante do Filadlfia tambm emite notas de cobrana de consumo
para cada associado com os vrios itens, cada item tem o produto consumido,
data do consumo e valor.

2)A Escola Tcnica JK nos solicitou um sistema de controle acadmico e nos
foram passadas as seguintes informaes:

Os alunos se inscrevem em cursos(o aluno s pode fazer um curso de cada
vez)
Os cursos tem disciplinas (podendo um curso ter vrias disciplinas e uma mesma
disciplina estar em mais de um curso).
Os professores lecionam disciplinas.( uma mesma disciplina pode ser lecionada
por vrios professores)
Alguns professores coordenam cursos
Cada disciplina tem sua carga horria semanal.

Faa o modelo de dados(DER) de acordo com as informaes passadas acima.

3)Faa o Modelo de Dados para a seguinte situao:

A Escola Tcnica JK se divide em departamentos e cada departamento
desenvolve projetos prprios. Cada projeto pode ser orientado por um ou mais
professores e s vezes tm vrios alunos que se dedicam aos projetos, mas tanto
os alunos como os professores no podem trabalhar em mais de um projeto ao
mesmo tempo. Os projetos tambm so 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 vrios cursos.
Professores dirigem departamentos e sempre lecionam uma ou mais
disciplinas, sendo que uma disciplina pode ser lecionada por mais de um
professor.

53
Mdulo 5. Projeto de BD utilizando o
modelo Entidade Relacionamento
(ER)

54

O modelo Entidade-Relacionamento um modelo de dados conceitual de alto
nvel, cujos conceitos foram projetados para estar o mais prximo possvel da
viso que o usurio tem dos dados, no se preocupando em representar como estes
dados estaro realmente armazenados. O modelo ER utilizado principalmente
durante o processo de projeto de banco de dados.
Modelo de Dados Conceitual de Alto Nvel
A figura 4 faz uma descrio simplificada do processo de projeto de um banco de
dados.

Figura 4: Fases do Projeto de um Banco de Dados
Mini-Mundo
Anlise e Coleta de
Requisitos
Requisitos do Banco de
Dados
Projeto Conceitual
Esquema Conceitual
(Alto Nvel)
Mapeamento do
Modelo de Dados
Esquema Conceitual
(Modelo do SGBD)
Projeto Fsico
Catlogo do BD

55
Entidades e Atributos
O objeto bsico tratado pelo modelo ER a entidade, que pode ser definida
como um objeto do mundo real, concreto ou abstrato e que possui existncia
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 no pode ser subdividido chamado de atributo
simples ou atmico.
Os atributos que podem assumir apenas um determinado valor em uma
determinada instncia denominado atributo simplesmente valorado, enquanto
que um atributo que pode assumir diversos valores em uma mesma instncia
denominado multi valorado.
Um atributo que gerado a partir de outro atributo chamado de atributo
derivado.
Tipos e Instncias de Relacionamento
Alm de conhecer detalhadamente os tipos entidade, muito importante conhecer
tambm os relacionamentos entre estes tipos entidades.
Um tipo relacionamento R entre n entidades E1, E2, ..., En, um conjunto de
associaes entre entidades deste tipo. Informalmente falando, cada instncia de
relacionamento r1 em R uma associao de entidades, onde a associao inclui
exatamente uma entidade de cada tipo entidade participante no tipo
relacionamento. Isto significa que estas entidades esto 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, porm, 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

56
O grau de um tipo relacionamento o nmero de tipos entidade que participam
do tipo relacionamento. No exemplo da figura 5, temos um relacionamento
binrio. O grau de um relacionamento ilimitado, porm, a partir do grau 3
(ternrio), a compreenso e a dificuldade de se desenvolver a relao corretamente
se tornam extremamente complexas.
Outras Caractersticas 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 no possuir existncia muito bem
definida, talvez seja mais interessante para a coesividade do modelo lgico que ela
seja representada como um atributo.
Nomes de papis e Relacionamentos Recursivos
Cada tipo entidade que participa de um tipo relacionamento desempenha um papel
particular no relacionamento. O nome do papel representa o papel que uma
entidade de um tipo entidade participante desempenha no relacionamento. No
exemplo da figura 5, ns temos o papel empregado ou trabalhador para o tipo
entidade EMPREGADO e o papel departamento ou empregador para a entidade
DEPARTAMENTO. Nomes de papis no so necessariamente importantes
quando todas as entidades participantes desempenham papis diferentes. Algumas
vezes, o papel torna-se essencial para distinguir o significado de cada participao.
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

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.
Restries em Tipos Relacionamentos
Geralmente, os tipos relacionamentos sofrem certas restries que limitam as
possveis combinaes das entidades participantes. Estas restries so derivadas
de restries impostas pelo estado destas entidades no mini-mundo. Veja o

Figura 7 - Relacionamento EMPREGADO gerencia DEPARTAMENTO
No exemplo da figura 7, temos a seguinte situao: um empregado pode gerenciar
apenas um departamento, enquanto que um departamento, pode ser gerenciado por
apenas um empregado. A este tipo de restrio, ns chamamos cardinalidade. A
cardinalidade indica o nmero 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 vrios
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

58

Figura 8 - Relacionamento N:M
No exemplo da figura 8, ns temos que um empregado pode trabalhar em vrios
projetos enquanto que um projeto pode ter vrios empregados trabalhando.
Outra restrio muito importante a participao. A participao define a
existncia de uma entidade atravs do relacionamento, podendo ser parcial ou
total. Veja o exemplo da
figura 7. A participao do empregado parcial pois nem todo empregado gerencia
um departamento, porm a participao 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
participaes so totais pois todo empregado precisa trabalhar em um
departamento e todo departamento tem que ter empregados trabalhando nele.
Estas restries so chamadas de restries estruturais.
Algumas vezes, torna-se necessrio 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. difcil estabelecer a qual tipo entidade pertence
atributo, pois o mesmo definido apenas pela existncia do relacionamento.
Quando temos relacionamentos com cardinalidade 1:1, podemos colocar o atributo
em uma das entidades, de preferncia, em uma cujo tipo entidade tenha
participao 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, ento podemos colocar o atributo no tipo entidade com
participao N. Porm, se a cardinalidade for N:M, ento o atributo dever mesmo
ficar no tipo relao. Veja o exemplo da figura 8. Caso queiramos armazenar
quantas horas cada empregado trabalhou em cada projeto, ento este dever ser um
atributo do relacionamento.
Tipos Entidades Fracas
p3
p2
p1
e4
e3
e2
e1
EMPREGADO
Trabalha Em
PROJETO

59
Alguns tipos entidade podem no ter um atributo chave por si s. Isto implica que
no poderemos distinguir algumas entidades por que as combinaes dos valores
de seus atributos podem ser idnticas. Estes tipos entidade so chamados entidades
fracas. As entidades deste tipo precisam estar relacionadas com uma entidade
pertencente ao tipo entidade proprietria. 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 no possui um mtodo
de identificar uma entidade nica. O EMPREGADO no uma entidade fraca pois
possui um atributo para identificao (atributo chave). O nmero do RG de um
empregado identifica um nico empregado. Porm, um dependente de 5 anos de
idade no 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 primria da entidade proprietria forma uma chave
primria composta. Neste exemplo: a chave primria do EMPREGADO o RG. A
chave parcial do DEPENDENTE o seu nome, pois dois irmos no podem ter o
mesmo nome. Desta forma, a chave primria desta entidade fica sendo o RG do pai
ou me mais o nome do dependente.
Diagrama Entidade Relacionamento
O diagrama Entidade Relacionamento composto por um conjunto de objetos
grficos que visa representar todos os objetos do modelo Entidade Relacionamento
tais como entidades, atributos, atributos chaves, relacionamentos, restries
estruturais, etc.
O diagrama ER fornece uma viso lgica do banco de dados, fornecendo um
conceito mais generalizado de como esto estruturados os dados de um sistema.
DEPENDENTE
p3
p2
p1
e2
e1
EMPREGADO
Possui Dependentes

60
Os objetos que compem o diagrama ER esto listados a seguir, na figura 11.

Figura 11- Objetos que Compem o Diagrama ER
Modelo Entidade Relacionamento Estendido
Os conceitos do modelo Entidade Relacionamento discutidos anteriormente so
suficientes para representar logicamente a maioria das aplicaes de banco de
dados. Porm, com o surgimento de novas aplicaes, surgiu tambm a
necessidade de novas semnticas para a modelagem de informaes mais
complexas. O modelo Entidade Relacionamento
Estendido (ERE) visa fornecer esta semntica para permitir a representao de
informaes complexas. importante frisar que embora o modelo ERE trate
classes e subclasses, ele no possui a mesma semntica de um modelo orientado a
objetos.
O modelo ERE engloba todos os conceitos do modelo ER mais os conceitos de
subclasse, superclasse, generalizao e especializao e o conceito de herana 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
Participao Parcial de E1 em R,
Participao Total de E2 em R
Taxa de Cardinalidade 1:N
para E1:E2 em R
R E1
(min, max)
Restrio Estrutural (min,max) na
Participao de E1 em R

61
Subclases, Superclases e Especializaes
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 so significativas e
precisam ser representadas explicitamente devido ao seu significado aplicao de
banco de dados. Leve em considerao o seguinte exemplo:
Para um banco de dados de uma empresa temos o tipo entidade empregado,
o qual possui as seguintes caractersticas: nome, rg, cic, nmero funcional,
endereo completo (rua, nmero, complemento, cep, bairro, cidade), sexo,
data de nascimento e telefone (ddd e nmero); caso o(a) funcionrio(a) seja
um(a) engenheiro(a), ento deseja-se armazenar as seguintes informaes:
nmero do CREA e especialidade (Civil, Mecnico, Eltro/Eletrnico); caso
o(a) funcionrio(a) seja um(a) secretrio(a), ento deseja-se armazenar as
seguinte informaes: qualificao (bi ou tri lngue) e os idiomas no qual
possui fluncia verbal e escrita.
Se as informaes nmero do CREA, especialidade, tipo e idiomas forem
representadas diretamente no tipo entidade empregado estaremos representando
informaes de um conjunto limitados de entidades empregado para os todos os
funcionrios da empresa. Neste caso, podemos criar duas subclasses do tipo
entidade empregado: engenheiro e secretria, as quais iro conter as informaes
acima citadas. Alm disto, engenheiro e secretria podem ter relacionamentos
especficos.
Uma entidade no 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 herana de atributos; ou seja, a
subclasse herda todos os atributos da superclasse. Isto porque a entidade de
subclasse representa as mesmas caractersticas de uma mesma entidade da
superclasse. Uma subclasse pode herdar atributos de superclasses diferentes.

62
A figura 12 mostra a representao diagramtica do exemplo acima.

Figura 12 - Representao de Superclasse e Subclasses
Especializao
Especializao o processo de definio de um conjunto de classes de um tipo
entidade; este tipo entidade chamado de superclasse da especializao. O
conjunto de subclasses formado baseado em alguma caracterstica que distinga as
entidades entre si.
No exemplo da figura 12, temos uma especializao, a qual podemos chamar de
funo. Veja agora no exemplo da figura 13, temos a entidade empregado e duas
especializaes.

Figura 13 - Duas Especializaes para Empregado: Funo e Categoria Salarial
Engenheiro
Empregado
Secretria
nome
dt. nasc.
no. funcional
rg
sexo
endereo
No registro
especializao
qualificao
idiomas
d
Funo
Empregado
Engenheiro Secretria Horista Mensalista
d d
Funo
Categoria Salarial

63
Como visto anteriormente, uma subclasse pode ter relacionamentos especficos
com outras entidades ou com a prpria entidade que a sua superclasse. Veja o

Figura 14 - Relacionamentos Entre Subclasses e Entidades
O processo de especializao nos permite:
definir um conjunto de subclasses de um tipo entidade;
associar atributos especficos adicionais para cada subclasse;
estabelecer tipos relacionamentos especficos entre subclasses e outros
tipos entidades.
Generalizao
A generalizao pode ser pensada como um processo de abstrao reverso ao da
especializao, no qual so suprimidas as diferenas entre diversos tipos entidades,
identificando suas caractersticas comuns e generalizando estas entidades em uma
superclasse

Figura 15 - Tipos Entidades Engenheiro e Secretria

Engenheiro Secretria
No registro
especializao
qualificao
idiomas
no. funcional
nome nome rg
rg
no. funcional
Engenheiro
Empregado
Secretria
Projeto
participa
desenvolvido
por
N
N
lidera 1
liderado
N
d
Funo

64

Figura 16 - Generalizao Empregado para os Tipos Entidades Engenheiro e
Secretria
importante destacar que existe diferena semntica entre a especializao e a
generalizao. Na especializao, podemos notar que a ligao entre a superclasse
e as subclasses feita atravs de um trao simples, indicando participao parcial
por parte da superclasse. Analisando o exemplo da figura 12, observado que um
empregado no obrigado a ser um engenheiro ou uma secretria. Na
generalizao, podemos notar que a ligao entre a superclasse e as subclasses
feita atravs de um trao duplo, indicando participao total por parte da
superclasse. Analisando o exemplo da figura 16, observado que um empregado
obrigado a ser um engenheiro ou uma secretria.
A letra d dentro do crculo que especifica uma especializao ou uma
generalizao significa disjuno. Uma disjuno em uma especializao ou
generalizao 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 especializaes para a superclasse Empregado,
as quais so restringidas atravs de uma disjuno. Neste caso, um empregado
pode ser um engenheiro ou uma secretria e o mesmo pode ser horista ou
mensalista.
Alm da disjuno 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 especializao ou generalizao. Analise a generalizao no
exemplo da figura 17. Suponha que uma pea fabricada em uma tornearia pode ser
manufaturada ou torneada ou ainda, pode ter sido manufaturada e torneada.

Engenheiro
Empregado
Secretria
nome
no. funcional
rg
n
o
registro
especializao
qualificao
idiomas
d
Funo

65

Figura 17 - Uma Generalizao com Overlap
Manufaturada
Pea
Torneada
Descrio
no. da pea
Data
Ordem Servio
No. Projeto
Preo
o

66
Lattice ou Mltipla Herana
Uma subclasse pode ser definida atravs de um lattice, ou mltipla herana, ou
seja, ela pode ter diversas superclasses, herdando caractersticas de todas. Leve em
considerao o seguinte exemplo:
Uma construtora possui diversos funcionrios, os quais podem ser
engenheiros ou secretrias. Um funcionrio pode tambm ser assalariado
ou horista. Todo gerente de departamento da construtora deve ser um
engenheiro e assalariado.
O modelo lgico da expresso acima tem o seguinte formato:

Figura 18 - Um Lattice com a Subclasse Gerente Compartilhada
Neste caso ento, um gerente ser um funcionrio que alm de possuir as
caractersticas prprias de Gerente, herdar as caractersticas de Engenheiro e de
Mensalista.
Empregado
Secretaria Engenheiro Mensalista Horista
d d
Funo
Categoria Salarial
Gerente

67
Reviso
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 diferena entre Especializao e Generalizao.
O que representa a letra D e a letra O dentro do crculo que especifica uma
Especializao ou uma Generalizao.

8)O que significa Mltipla Herana?

68
Mdulo 6: Normalizao
Mdulo V Normalizao

Escola Tcnica JK Curso de Informtica Pgina - 69
Viso Geral

O que a normalizao
Viso geral da consolidao do
modelo de dados

Mdulo V Normalizao

O que Normalizao ?

Normalizao o processo formal que consiste em substituir um conjunto de
entidades por outro conjunto capaz de comportar melhor as mudanas futuras.
Entidades normalizadas no possuem redundncias (duplicao de dados)
acidental. Cada atributo est relacionado com sua prpria entidade e no se
mistura com atributos relativos entidades diferentes.
A normalizao corresponde na realidade formalizao de regras baseadas no
fato que as entidades possuem anomalias de atualizao.

Anomalias de Atualizao

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 atualizao que acontecero se:
- Um produto for descontinuado por seu fornecedor?
- O nome do produto for mudado?
- O cliente mudar de endereo?
- Os produtos ou as quantidades pedidas pelo cliente forem mudadas e o cliente
esqueceu o nmero do pedido?

Dependncia 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 ento podemos encontrar o
valor de B associado a ele.

DIAGRAMA DE DEPENDNCIA FUNCIONAL

A
B

Nota - a seta parte de quem identifica.

Exemplo:

DEPARTAMENTO
CODIGO_DEPARTAMENTO
NOME_DEPARTAMENTO
SIGLA_DEPARTAMENTO

Mdulo V Normalizao

Nota - O exame das relaes existentes entre os atributos de uma entidade deve
ser feito a partir do conhecimento (conceitual) que se tem sobre o mundo real
(ambiente modelado).

Dependncia Funcional Composta ou Completa

Dado um atributo ou um conjunto de atributos B de uma entidade, sendo a chave
primria composta por um conjunto de atributos A, diz-se que B
completamente dependente funcional da chave primria, se e somente se, a cada
valor da chave (e no a parte dele), est associado um valor para cada atributo do
conjunto B.

A1
A2

B1
B2
B3

Exemplo:
PRODUTO_FATURA

NUMERO_PEDIDO
CODIGO_PRODUTO
QTDE_PEDIDA
PRECO_TOTAL_PRODUTO

Dependncia Funcional Transitiva
Dados os atributos A, B e C de uma entidade, sendo A a chave primria,
diz-se que B e C so dependentes transitivos se e somente se, forem
funcionalmente dependente de A alm de existir uma dependncia funcional
entre eles.

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 no contm grupos de atributos repetitivos
(multivalorados).
Exemplo:
Mdulo V Normalizao

Entidade no normalizada
NOME_CLIENTE + ENDERECO_CLIENTE + ( NUMERO_PRODUTO +
TOTAL_PRODUTO) + TOTAL_PEDIDO)

Remoo 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

NOME_CLIENTE + ENDERECO_CLIENTE + TOTAL_PEDIDO)

PRODUTO_PEDIDO (NUMERO_PEDIDO + NUMERO_PRODUTO +
TOTAL_PRODUTO)
Modelo de Dados

Segunda Forma Normal (2FN)
Uma entidade est na 2FN se ela est na 1FN e seus atributos so funcionalmente
dependentes de sua chave (primria) completa.

Exemplo:
Entidades da 1FN

PEDIDO

PRODUTO_PEDIDO
Mdulo V Normalizao


TOTAL_PRODUTO)

Remoo dos atributos no funcionalmente dependentes de toda uma chave
primria
(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


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 no possui dependncias
transitivas.
Uma entidade que est na 2FN pode ter um atributo que no uma chave mas
que por si identifica outros atributos. Refere-se a isto como uma dependncia
transitiva.

Exemplo:
PRODUTO

PEDIDO

PRODUTO
/PEDIDO
Mdulo V Normalizao


- Entidade na 2FN:


PRODUTO_PEDIDO (NUMERO_PEDIDO + NUMERO_PRODUTO+


- Remoo das dependncias 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)



Mdulo V Normalizao

Modelo de Dados

Simplificao do Processo de Normalizao
A partir do diagrama de dependncias funcionais podemos obter diretamente as
entidades na terceira forma normal. Para isso, devemos especificar uma entidade
para cada conjunto de setas que o diagrama mostrar. A chave primria 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 Prticas
Se duas entidades possurem a mesma chave de identificao:

Elas so a mesma entidade;
Seus atributos se complementam;
As suas ocorrncias se complementam;
Quando um atributo ou um conjunto de atributos identificadores de uma
determinada entidade, for(em) tambm 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 identificao em uma das entidades; caso contrrio ser uma
simples redundncia.
PRODUTO

PEDIDO

PRODUTO_PEDIDO
CLIENTE

Mdulo V Normalizao

Nenhum atributo componente de uma chave primria deve poder assumir um
valor nulo. Decorre do fato de que todos os objetos que se quer representar
devam ser distinguveis entre si.

Um atributo que seja chave estrangeira s pode assumir:
- Valor nulo;
- Valor para o qual exista uma ocorrncia da entidade da qual ela chave
primria.

Viso Geral Consolidao de Modelos de Dados
O que Consolidao?
Termo utilizado para representar os trabalhos de integrao de um modelo de
dados a outro ou, integrao de modelos parciais a um modelo global de dados
(empresa, assunto ou sistema).
Trabalhos Executados na Consolidao
Os Trabalhos da consolidao basicamente so os seguintes:
- Adio de entidades ainda inexistentes no modelo global de dados, relacionando-
as s demais;
- Adio de novos atributos a entidades j existentes, desde que possuam chaves
primrias idnticas;
- Identificao das entidades j implementadas;
- Eliminao de relacionamentos redundantes.
Mdulo V Normalizao

Reviso
1)O que chave estrangeira?

2)O que chave primria?

3)O que chave candidata?

4)O que Dependncia Funcional Composta e Dependncia Funcional
Transitiva?

5)Explique com suas palavras quais so as exigncias para que uma entidade
esteja na 1 FN(Forma Normal), 2FN e 3FN.

-
Mdulo V Normalizao

Exerccios

1)Faa a normalizao partir das informaes abaixo, identifique as chaves de
cada entidade e desenhe o diagrama ER para cada um dos trs casos.

Estudo do caso 1

ORDEM DE COMPRA
Cdigo_Ordem_Compra
Data_Emisso
Cdigo_Fornecedor
Nome_Fornecedor
Endereo_Fornecedor
%Materiais da ordem de compra( grupo multivalorado)
cdigo_item(n)
descrio_item(n)
valor_unitrio_item(n)
quantidade_comprada_item(n)
valor_total_item(n)
valor_total_compra

Estudo do caso2

DADOS FUNCIONRIOS
Matricula_Funcionrio
Nome_Funcionrio
Endereo_Funcionrio
Data_Admissao_Funcionrio
Cdigo_Cargo
Descrio_Cargo
Valor_Salrio
Numero_Total_Dependentes
Cdigo_Departamento
%Habilidades (grupo multivalorado)
Cdigo_Habilidade(n)
Descrio_Habilidade(n)
Data_Formao_Habilidade(n)
%Dependentes(grupo multivalorado)
Cdigo_Dependente(n)
Nome_Dependente(n)
Data_Nascimento_Dependente(n)

DADOS DEPARTAMENTO
Cdigo_Departamento
Nome_Departamento
Localizao_Departamento

Mdulo V Normalizao

Estudo do caso3

CIDADES
Cdigo_Cidade
Nome_Cidade
Populao_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
Cdigo_Vereador
Nome_Vereador
Cdigo_Cidade
Nome_Cidade
Partido_Vereador
Voto_Ultima_Eleio
Mandato_Vereador(perodo)

DEPUTADOS
Cdigo_Deputado
Nome_Deputado
Cdigo_Cidade
Nome_Cidade
Voto_Ultima_Eleio
Partido_Deputado
Mandato_Deputado(perodo)
Categoria_Deputado(Estadual-Federal)

PRINCIPAIS SOLICITAES CIDADES
Cdigo_Cidade
Nome_Cidade
%Solicitaes(grupo multivalorado)
Numero_Solicitao(n)
Descrio_Solicitao(n)
Data_Solicitao(n)
Viabilidade_Atendimento(n)
rgos_Envolvidos(n)

2)Fomos a uma clnica mdica 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 = nmero_cliente +
nome_cliente +
endereo_cliente +
CPF_cliente +
telefone_cliente +
cdigo_convnio_cliente +
descrio_convnio_cliente +
percentual_desconto_cliente +
{ nmero_dependente +
nome_dependente +
cdigo_parentesco_dependente +
descrio_parentesco_dependente } +
{ data consulta_cliente +
cdigo_medico_consulta +
nome_mdico_consulta +
cdigo_especialidade_mdico +
descrio_especialidade_mdico +
diagnstico_consulta } +
{ cdigo_exame_consulta +
descrio_exame_consulta +
resultado_exame_consulta } +
{ ms_referncia_mensalidade +
data_pagamento_mensalidade }

Normalizar a estrutura de dados apresentada at a 3FN e identificar a chave
em todas as estruturas na 3FN


Mdulo 7: Projeto (especificao da
Soluo para o projeto Fsico)

Viso Geral

Objetivos do projeto fsico
Tcnicas utilizadas na elaborao do
projeto
A construo
A implantao
A manuteno
A documentao

Objetivos do projeto fsico
Definir a parte fsica do projeto, tais como hardware, banco de dados, linguagem
de programao, etc.
Definio de ambiente.
- Hardware: equipamento, meio de armazenamento, meio de
transmisso, perifricos.
- Software: linguagem de programao, banco de dados, etc.

Projeto fsico da base de dados.
- Definio da estrutura e organizao;
- Construo das tabelas

Detalhamento dos processos.
- Identificao das funes a serem automatizadas;
- Construo do diagrama de blocos do sistema;
- Construo do projeto de formulrios (I/O), telas e relatrios;

Definio dos mecanismos de segurana e auditoria.
- Backups;
- Direitos de Acesso

Validao da especificao da soluo
- Reviso;
- Apresentao;
- Avaliao.

Tcnicas Utilizadas
- DFD;
- Diagrama de Blocos;
- Dicionrio de dados;
- Portugus estruturado;
- Entrevistas e reunies;

Produtos Gerados
- Diagrama de blocos;
- Dicionrio de dados;
- Telas e relatrios;
- Banco de dados criado;
- Manual tcnico.
Construo
Objetivos
- Planejamento de como ser a implantao;
- Minimizar impactos;



Programao
- Especificao de programas, definindo o objetivo do programa (fazer o
que), os dados de entrada (a partir de que), os dados de sada (para
onde), detalhando a lgica (como fazer) e o contexto (onde e como
ser executado);
- Codificao: utilizao de mtodos estruturados para desenvolver
programas;
- Documentao dos programas: autor, data, objetivo, nome da
empresa, alteraes e verses;

Testes.
- Descobrir erros no programa/sistema;
- Utiliza-se do auxlio do usurio;
- Elaborar massa de testes verdadeira.
- Elaborar testes de desempenho
- Elaborar testes de segurana

Consolidao da documentao.
- Manual tcnico;
- Help on line;

Validao do produto.
- Reviso;
- Apresentao;
- Avaliao.

Planejamento da implantao.
- Treinamento dos usurios;
- Tipo adequado de implantao (direta ou paralela);
- Corrigir distores
- Fazer teste piloto;

Converso e gerao da base de dados
- Gerar tabelas;
- Gerar ndice;
- Carga dos dados

Tcnicas utilizadas

- Listas De Eventos;
- Diagrama de blocos;
- Programao estruturada;
- Reunies.
Produtos Gerados

- Sistema pronto;
- Manuais: Tcnico
- Help.

Implantao


Objetivos:
- Instalao do sistema;
- Mensurar resultados da instalao;
- Verificar operao;
- Realizar manuteno

Passos para Implementao:

1. Desenvolver programa de instalao
2. Configurar parmetros para a instalao (arquivo SETUP)
3. Limpar banco de dados
4. Treinamento Final com usurio e pessoas envolvidas
5. Verificar equipamentos e instalar o sistema
6. Acompanhamento dos resultados do sistema implantado em relao ao
antigo
7. Operao.
- Execuo de rotinas;
- Contabilizao de recursos;
- Registro e tratamento da execuo;
- Auditoria do sistema.

Produtos Gerados:
- Sistema instalado.

Manuteno

1. Anlise das Solicitaes dos Usurios: Verificao do pedido de alterao
ou implementao feita pelo usurio.

2. Anlise do Uso do Sistema: Verificao peridica da utilizao, performance
e funcionalidades do sistema, visando a sua constante otimizao.

3. Alteraes da Base de Dados em Ambiente de Teste e Programao:
Procedimento da alterao da base de dados e teste , do(s) programa(s),
tela(s) ou relatrio(s) de acordo com as que foi determinado pelas anlises
explcitas nos itens A e B acima.

4. Testes

5. Alteraes da Base de Dados em Ambiente de Produo: Procedimento de
alterao da base de dados da produo.

6. Atualizao da Ajuda on-line: Modificao das descries das funes
alteradas dentro da documentao on-line.

7. Atualizao do Manual Tcnico: Modificao das decises das estruturas
das tabelas, procedimentos e das funes alteradas, dentro do manual
tcnico.

Normas e padres de construo da documentao
Padres de nomenclatura

1. Banco de Dados

TTTSSS.MDB

TTT Abreviatura significando ambiente de produo (PRO) ou de
desenvolvimento (DES)
SSS Sigla do Sistema

Exemplo: DESSCA.mdb (Desenvolvimento, Sistema de Controle
Acadmico)

2. Tabelas

SSS_TB_XXXXXXXXXX
TAB Fixo, descrio de tabela
XXXXXXXXXX Descrio 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 Descrio do campo (poder conter n caracteres)
Exemplo: ALU_NOME , ALU_NOTA, ALU_MATRCULA

4. Variveis

VTTT_XXXXXXXXX
V Fixo
TTT tipo da varivel
XXXXXXXXX Descrio do contedo (poder conter n
caracteres)

Exemplos:

VDAT_XXXXXXXXXX variveis tipo data
VSTR_XXXXXXXXXX variveis tipo string
VNUM_XXXXXXXXXX variveis tipo numricas
VMEM_XXXXXXXXXX variveis tipo memo

5. Telas

SSS_FR_XXXXXXXXXX
FR Fixo, abreviatura de tela/formulrio
XXXXXXXXXX Descrio da Tela

Exemplo: SCA_TEL_ ALUNO, SCA_TEL_NOTAS
6. Relatrios


SSS_RL_XXXXXXXXXX

SSS Abreviatura do Sistema
RL Fixo, abreviatura de relatrio;
XXXXXXXXXX Descrio do Relatrio

7. Rotinas

VERBO_XXXXXXXXXX

VERBO verbo no infinitivo representando a ao da rotina
XXXXXXXXXX Descrio da rotina

Exemplo: CADASTRAR_ALUNOS

Regras Gerais
rea de Teste e Produo

Durante a fase de codificao e de manuteno deve-se usar uma rea
em disco para testes de programao e um Banco de Dados para teste,
somente aps a validao dos programas e das bases eles devem passar
para a rea de produo.

Funes Genricas

Funes consideradas genricas devero ser documentadas e anexadas
ao manual tcnico para facilitar a utilizao das mesmas em outros
sistemas.

Arquivo de Configuraes

Todas os mdulos devem consultar uma tabela que conter as
configuraes bsicas do sistema, como: nome da empresa, path das
bases de dados, menus de acesso.
A excluso dos registros das tabelas deve ser do tipo cascata.
No deve ser permitida a alterao de campos-chave.

Tabelas
Gravar informaes de endereo em campos separados. Ex.: rua,
bairro.
Campos do tipo Data devem ter o formato: dd/mm/aaaa.
Campos de contedo numrico mas que no sejam usados para
clculo podem ser do tipo string.
Utilizar campos booleanos para armazenar informaes de .V. ou .F.
Para campos que contm apenas uma posio, esta deve ser
maiscula.
No devem ser armazenados campos com mscara.

Telas
O nome do sistema deve constar na Barra de Ttulo da tela principal do
sistema, em letras maisculas e minsculas;
A funo principal de cada tela deve estar descrita na barra de ttulo,
em letras maisculas e minsculas;

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 possvel, 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 mximo, tamanho igual ao
tamanho do campo correspondente na tabela;
S devem ser formatados campos em consultas, ou quando os
mesmo j tenham formatao pr-definida.
A tela principal dever ser maximizada;
As demais telas: funes do sistema, help, sobre o sistema,
mensagens, etc; devem ser menores que a principal e s tero
habilitado o boto de fechar.
Fonte: Usar Arial, tamanho 8.
Utilizar cores amenas na criao de cones.

Menu

Utilizar menus com todas as seguintes opes: Cadastros,
Movimentaes, Relatrios, Consultas, Utilitrios, Ajuda e Sada
Botes

Botes como os de: pesquisa, confirmao e sada deve constar em
cada tela interna

Mensagens

As telas de mensagem deve ser popUp (s passar para outra depois de
fechada);
Utilizar smbolos como ! ou ?, de acordo com o tipo da mensagem:
aviso ou confirmao.
As mensagens devem ser o mais explicativas possvel, porm bastante
sucintas.
Mensagens de orientao de tela ou dicas de botes devem
representar a funo a que se destinam, usando verbo no infinitivo. Ex.:
Cadastrar Cliente, Consultar Despesas por Cliente, etc.

Relatrios
Usar fonte Arial;
Cabealho: Negrito tamanho 12;
Quebra, totalizaes e ttulo das colunas: Negrito tamanho 12;
Detalhe: Normal tamanho 10;
Rodap da pgina: Normal tamanho 10;
O tamanho da fonte pode ser alterado de acordo com o volume de
dados a ser mostrado no relatrio.

Programas

- Todas as crticas de validao dos dados no banco, sempre que
possvel, devero ficar a cargo do banco de dados;
- Os programas devero capturar os erros do banco, trata-los e retornar
alguma mensagem ao usurio.

- As validaes a nvel de formulrio, devero ser tratadas pelo
programa, no click do boto salvar, retornando o cursor para o campo
invalidado no formulrio.
Lgica
- Usar apenas um comando por linha;
- Escrever os comandos sem abreviao;
- Identificar comandos de lao, de repetio, de opo, etc;
- Dividir, sempre que possvel, os programas grandes em rotinas
menores;
- Utilizar estrutura CASE sempre que possvel.
- Fazer sempre comentrios nos programas, procedures, rotinas e
funes do sistema;
- Fazer comentrio sempre que o programa chamar outro programa,
rotina, procedure ou funo.
- Colocar comentrios antes da chamada de qualquer rotina,
procedimento ou funo ;
- Iniciar o programa sempre com comentrios: Nome do programa,
sistema, programador, programador que efetivou a alterao, data,
data da alterao.
Padres de documentao
Ajuda on line
Esquematizao dos Mdulos do Sistema
a. Esquematizar os Mdulos do Sistema, de forma que cada uma de suas
funes seja um Link
Descrio dos Mdulos do Sistema e Esquematizao de suas Funes
a. Descrever, sucintamente, o objetivo do Mdulo;
b. Esquematizar as Funes e Operaes do Mdulo, de forma que cada
uma de suas funes ou operaes seja um Link
Descrio das Funes ou Operaes do Mdulo do Sistema
a. Descrever, o mais detalhadamentente possvel, as instrues de uso e
operacionalizao da funo ou operao, inclusive com a utilizao de
exemplos.
b. Descrever as crticas bsicas dos campos de entrada. Ex. (campo
numrico; digitao obrigatria; digitao facultativa; etc.).
Descrio dos Relatrios
a. Descrever o objetivo e o contedo do Relatrio.
b. Descrever, o mais detalhadamentente possvel, as instrues de uso e
operacionalizao para a chamada do relatrio, explicitando seus
parmetros, inclusive com a utilizao de exemplos.
c. Anexar a Copia do Relatrio
Sobre o sistema
Descrio do Sistema
Descrever , o mais detalhadamentente possvel, o objetivo do Sistema,
mencionando seus principais mdulos.

Equipe Envolvida

Informar a equipe envolvida no Sistema, agrupando por tipo de atividade.
(Ex. Anlise, Desenvolvimento; Documentao; etc.)
Crditos
Informar os crditos do Sistema e das funcionalidades no desenvolvidas
pela empresa responsvel pela anlise, programao e documentao.

Manual Tcnico
O Manual Tcnico deve ser elaborado de acordo com os seguintes contedos:

Introduo
a. Apresentao do Manual
Descrio dos objetivos do Manual e identificao dos rgos usurios.
b. Objetivos do Sistema
Descrio sucinta dos objetivos do Sistema.
c. Consideraes Gerais
Descrio dos mdulos bsicos do Sistema e demais observaes a
critrio do analista.
d. Configurao Bsica
Configurao bsica necessria para o processamento do Sistema:
Equipamento
Sistema Operacional
Programas Utilitrios
Memria Principal e
Memria Auxiliar.
e. Instrues de Instalao
Descrio das instrues de instalao e configurao inicial do Sistema.
Diagrama de contexto do Sistema. Representa as entradas e sadas
lgicas do Sistema, bem como, identifica os rgos usurios envolvidos
pelo Sistema.
Diagrama de Fluxo de Dados
a. Nvel 1 - Sistema
Diagrama de fluxo de dados do Sistema no 1
o
nvel.
b. Nvel 2 - Mdulos
o
nvel. Descreve com maior
grau de detalhamento o fluxo apresentado no nvel 1, apresentando os
mdulos do Sistema.
c. Nvel 3 - Expanso
o
nvel. Representado pela
expanso do diagrama de dados para os processos apresentados nos
nveis 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 hierrquica do Sistema, de forma modular.
Dicionrio de Dados
a. Depsito de Dados
Descrio das caractersticas dos Depsitos de Dados (Tabelas) do
Sistema de acordo com os padres estabelecidos nesta metodologia.
b. Processos
Caractersticas dos processos

Referncia Cruzada
Referencia cruzada do Sistema apresentando a relao Depsito de
Dados (Tabela) X Tela (Form).
Relatrios
a. Objetivo do Relatrio
Descrever o objetivo e o contedo do Relatrio.
b. Instrues de Uso e Parmetros
Descrever, o mais detalhadamentente possvel, as instrues de uso e
operacionalizao para a chamada do relatrio, explicitando seus
parmetros, inclusive com a utilizao de exemplos.
C. Copia do Relatrio

Reviso

1)D exemplo de pelo menos 4 tabelas que podem se relacionar. Monte um
DER relacionando as tabelas, faa a lista de entidades. Defina em cada uma
delas os campos que sero chave primria, chave estrangeira e chave
candidata e escolha tambm em cada um delas um determinado campo e
defina um Domnio para ele.

2)Depois de feito o exerccio acima, voc precisar documentar os nomes do
banco de dados, tabelas, campos, etc... De acordo com as normas e padres
de construo da documentao, crie um nome para o banco de dados, os
nomes para as tabelas e os nomes dos campos.

3)Quando desenvolvemos sistemas, necessrio se preocupar com Backups
e direitos de acesso. Explique com suas palavras, o que so esses dois itens.

4)Em um banco de dados, existe um tipo de excluso dos registros das
tabelas que denominado tipo cascata. Explique o que quer dizer isto.

5)Quanto se trata de relatrios, qual tipo de formatao mais adequada?

6)Quais as opes bsicas devem conter no Menu da tela Principal?

7)Quais os passos para implementao na fase de implantao do sistema?

8)Existe uma fase logo aps a fase de implantao que de grande
importncia para o usurio; que fase esta e como os profissionais
responsveis pelo sistema devem agir nesta fase?


Mdulo 8: Ferramentas CASE

Ferramentas CASE

As regras de transformao apresentadas anteriormente resolvem grande parte
dos problemas de transformao 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 ateno modelagem dos relacionamentos e suas cardinalidades.
Estas regras tambm so 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-aucar elaborado atravs da ferramenta CASE ERWin.
A figura ilustra o que na ferramenta ERWin chamado de Nvel Lgico, uma
vez que o nvel de detalhe apresentado est mais prximo 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. So eles:
As figuras representadas no formato retangular representam tabelas do modelo
relacional e no entidades do modelo E-R. Observe a existncia da tabela
Plantao, que no modelo E-R corresponde a um relacionamento;
Existem dois tipos de representao grfica para tabelas, retngulos com bordas
retas e abaloadas. Retngulos com bordas abaloadas sinalizam tabelas
resultantes da transformao de entidades fracas (ex.: Talho) ou tabelas
resultantes da transformao de relacionamentos (Plantao). Observe a presena
de atributos que so chaves estrangeiras (FK foreign key) fazendo parte da
chave primria destas tabelas (ex.: idFaz (FK) em Talho).
A linha tracejada representa um relacionamento 1:N entre duas entidades fortes,
que transformado pela incluso de uma chave estrangeira na tabela do lado N
(que no participa da chave primria). Por exemplo, o relacionamento Fazenda
Proprietrio representado por uma linha tracejada (com um diamante na ponta
que no significa nada). Neste caso, a ferramenta inclui automaticamente na

tabela Fazenda, o campo idProp, o qual foi renomeado para dono, assinalado
como (FK).
A linha contnua indica a transformao 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 primria da tabela resultante.
A figura abaixo ilustra o mesmo esquema relacional do sistema de cana-de-
aucar, na viso chamada Modelo Lgico Detalhado, na qual cada atributo est
associado a um domnio especfico.

Estas informaes so suficientes para a gerao automtica do esquema do BD
em um SGBD. A ferramenta CASE ERWin, por exemplo, gera cdigo automtico
para diversos SGBD (ex.: Oracle, DB2, SQL Server).
A seguir o mesmo esquema apresentado na notao textual simplificada:
Municpio (cod-mun, nomeMun, pop)
Proprietrio (idProp, nomeProp, ender, telProp)
Fazenda (idFaz, nomeFaz, reaFaz, codMun*, dono*)
*codMun referencia Municpio
*dono referencia Proprietrio
Talho (idFaz*, idTalho, reaTalho)
*idFaz referencia Fazenda
Plantao (idFaz*, id-talho*, tipoVar*, numColheita, dat-Plantio, dat-ult-colheita)
*idFaz,id-talho referenciam Talho
*tipoVar referencia Variedade
Variedade (tipoVar, descrVar, prodMdia)


Apostila Banco de Dados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO DE CULTURA TCNICA DE IPATINGA LTDA

Rua Potiguar, 150 Bairro Iguau Ipatinga MG

Você também pode gostar