Caderno Do Participante - 22-09-14 PDF

Modelagem de Dados
Caderno do Participante
Educando para a Sustentabilidade
Papel
Desenvolver competncias profissionais, por meio da sistematizao de

aes educacionais, que contribuem para a melhoria do desempenho
organizacional e para o fortalecimento da imagem do Banco.
O Profissional
O atual contexto empresarial, altamente dinmico, exige profissionais igualmente

dinmicos que possam situar-se como protagonistas de sua trajetria pessoal e
profissional. Que sejam capazes de se manter atualizados com os
acontecimentos do mundo e, a partir de seus valores e relacionamentos, refletir
sobre a influncia desses fatos na organizao do trabalho e na sociedade. Que
elaborem, por fim, respostas novas aos novos problemas.
Essa atitude exige do profissional o comprometimento tico, assim como exige
do Banco a oferta de condies de desenvolvimento e de trabalho para que
sejam firmados compromissos nas seguintes dimenses:
Compromissos consigo mesmo: autodesenvolvimento, autonomia,

autoconhecimento, qualidade de vida, construo de projeto de vida
(pessoal e profissional) e coerncia entre sua prtica e seus valores.
Compromissos com os outros sujeitos: apoio mtuo, aprendizagem
coletiva, cooperao, solidariedade, empatia, reciprocidade, transparncia,
atitude dialgica, tolerncia, aceitao e valorizao da diversidade humana.
Compromissos com o trabalho: reflexo sobre a natureza e o sentido do
trabalho, aprimoramento permanente da sua qualificao por meio do
acompanhamento das cincias e tecnologias e de sua atuao profissional
por meio da sua participao na construo e reconstruo da realidade.
Compromissos com a Organizao: conhecimento e realizao das
estratgias e dos objetivos organizacionais, seja no mbito mercadolgico
ou no tocante s suas funes sociais, gerindo as possveis tenses entre
esses dois papis.
Compromissos com a sociedade: atuao crtica, democrtica e
transformadora nas redes sociais em que se insere, para fortalecer os
princpios de solidariedade, justia social, cidadania e sustentabilidade
ambiental.
Extrado da Proposta Poltico-Pedaggica para

Atuao em Gesto de Pessoas
Universidade Corporativa Banco do Brasil 1

Modelagem de Dados
2
Modelagem de Dados
MODELAGEM DE DADOS
OBJETIVO GERAL DE APRENDIZAGEM
Elaborar modelo de dados, em conformidade com as normas tcnicas e

padres estabelecidos pelo BB.
Realizao:
Diretoria de Tecnologia Ditec
Gepes Braslia DF
Maio/2008

Modelagem de Dados
4
Modelagem de Dados
INDICE
APRESENTAO ..................................................................................................................................... 7
CARACTERSTICAS DO CURSO.......................................................................................................... 8
1. INTRODUO ................................................................................................................................. 9
1.1. MODELAGEM ............................................................................................................................ 9
1.1.1 O que modelagem? ............................................................................................................ 9
1.2. MODELAGEM DE SISTEMAS.................................................................................................... 11
1.2.1 Para que modelamos? ........................................................................................................ 11
1.2.2 Por que modelamos? .......................................................................................................... 12
1.2.3 Escopo, prazo e recurso. .................................................................................................... 14
1.2.4 Como modelamos? ............................................................................................................. 15
1.3. MODELAGEM DE DADOS ........................................................................................................ 15
1.3.1 Viso Geral ......................................................................................................................... 15
1.3.2 A evoluo da modelagem de dados ................................................................................... 18
1.3.3 Modelo Hierrquico ........................................................................................................... 19
1.3.4 Modelo de rede ................................................................................................................... 21
1.3.5 Teoria Relacional ............................................................................................................... 22
1.3.6 Modelo Entidade Relacionamento (MER) ....................................................................... 23
1.3.7 Modelo Relacional .............................................................................................................. 23
1.3.8 Modelagem de Dados no Banco do Brasil ......................................................................... 24
2. MODELAGEM DE DADOS CONCEITUAL .............................................................................. 26
2.1 DISPOSIES GERAIS ............................................................................................................. 26
2.2 ESTRUTURAS ........................................................................................................................... 28
2.2.1 Entidades ............................................................................................................................ 28
2.2.2 Atributos ............................................................................................................................. 30
2.2.3 Relacionamentos................................................................................................................. 34
2.2.4 Generalizao/Especializao ........................................................................................... 39
2.3 TCNICA DE IDENTIFICAO DOS OBJETOS DE DADOS CONCEITUAIS ................................ 42
2.4 SITUAES EM MODELAGEM DE DADOS QUE INDICAM A OCORRNCIA DE ERROS ............. 48
3. MODELAGEM DE DADOS LGICA ........................................................................................ 49
3.1 DISPOSIES GERAIS ............................................................................................................. 49
3.2 CARACTERSTICAS DO MODELO DE DADOS LGICO ............................................................ 50
3.3 OBJETOS DO MODELO DE DADOS LGICO ............................................................................ 50
3.3.1 Entidade.............................................................................................................................. 50
3.3.2 Atributo ............................................................................................................................... 52
3.3.3 Chaves ................................................................................................................................ 53
3.3.4 Relacionamentos................................................................................................................. 54
3.3.5 Supertipo / Subtipo (Generalizao / Especializao) ....................................................... 59
3.4 DESLOCAMENTO DA CHAVE ESTRANGEIRA .......................................................................... 60
3.5 CONVENES POSICIONAIS EM MODELOS DE DADOS .......................................................... 62
3.6 DERIVAO DO MODELO LGICO A PARTIR DO MODELO CONCEITUAL ............................ 63
3.7 SITUAES EM MODELAGEM DE DADOS QUE INDICAM A OCORRNCIA DE ERROS ............. 66
3.8 NORMALIZAO ..................................................................................................................... 67
3.8.1 Normalizao at a 3 FORMA NORMAL ......................................................................... 67
3.8.2 Outras Formas Normais ..................................................................................................... 71
3.9 RESTRIO DE INTEGRIDADE ................................................................................................ 71
3.10 VALIDAO DO MODELO DE DADOS LGICO ....................................................................... 72
3.11 PADRES DE MODELAGEM NO BB ......................................................................................... 73
3.11.1 Padronizao de Nomes ................................................................................................ 73
3.12 GLOSSRIO DA TECNOLOGIA OU GLOSSRIO DE TERMOS .................................................. 74
3.13 PADRONIZAO DE CORES .................................................................................................... 74
3.14 FERRAMENTAS DE MODELAGEM ........................................................................................... 74
3.14.1 Verificador & Conversor ............................................................................................... 74
3.14.2 Ferramenta de Modelagem de Dados ............................................................................ 74

Modelagem de Dados
3.15 O "MODELO DE DADOS CORPORATIVO" .............................................................................. 75

3.16 MODELO CONCEITUAL X MODELO LGICO......................................................................... 76
4. MODELAGEM DE DADOS FSICO ........................................................................................... 78
4.1 DESENVOLVIMENTO DO MODELO DE DADOS FSICO............................................................ 78
4.2 ERWIN DATA MODELER ........................................................................................................ 78
4.3 VERIFICAO DE PADRES DE MODELAGEM CONVERSO DE NOMES ............................... 79
4.4 SGBDR (SISTEMA GERENCIADOR DE BANCOS DE DADOS RELACIONAIS) .......................... 82
4.5 OBJETOS DO MODELO DE DADOS FSICO .............................................................................. 83
4.5.1 Tabelas ............................................................................................................................... 83
4.5.2 Colunas ............................................................................................................................... 84
4.5.3 Supertipo / Subtipo (Especializao) .................................................................................. 86
4.5.4 Implementao de Chaves .................................................................................................. 89
4.5.5 Implementao de Restries de Integridade ..................................................................... 90
4.5.6 ndices ................................................................................................................................ 92
4.5.7 Particionamento da Tabela ................................................................................................ 95
4.6 ANLISE DE ACESSO AOS DADOS ........................................................................................... 96
4.7 TABELAS EM SITUAES ESPECIAIS (TABELAS-FOCO) .......................................................... 96
4.8 SISTEMA MOD MANUTENO DE OBJETOS DE DADOS ................................................... 101
4.8.1 Criao de Objetos de Banco de Dados ........................................................................... 103
4.8.2 Implantao em Produo ................................................................................................ 108
GLOSSRIO .......................................................................................................................................... 111
REFERNCIAS ..................................................................................................................................... 112
6
Modelagem de Dados
APRESENTAO
Bem vindo ao curso Modelagem de Dados no BB!
O principal objetivo deste curso que possamos elaborar modelos de dados,

de acordo com as normas, tcnicas e padres estabelecidos pelo BB. Outro
importante objetivo reconhecer a modelagem de dados como fase essencial
no processo de desenvolvimento de sistemas de informao.
O plano de curso desenvolvido apresenta atividades que visam o alcance dos
objetivos de aprendizagem propostos e prevem a interao entre os
participantes e o educador. Portanto, o conhecimento e as experincias de
cada um contribuiro para o enriquecimento da aprendizagem do grupo,
resultando em um conhecimento novo.
Bom estudo!

Modelagem de Dados
CARACTERSTICAS DO CURSO
Denominao completa: Modelagem de dados no BB

Denominao reduzida: Modelagem de Dados
Cdigo: 1539 08h/dia e 5275 06h/dia
Direcionamento estratgico: Ser o banco referncia em tecnologia, logstica e
segurana bancria.
rea de conhecimento: Tecnologia da Informao.
Pblico: Funcionrios da Diretoria de Tecnologia - Ditec
Desempenhos esperados:
Elaborar modelos de dados, com a conscincia de que modelagem fase

essencial no processo de desenvolvimento de sistemas de informao.
Produzir modelos de dados, com qualidade, de acordo com as normas, as

tcnicas e os padres estabelecidos pelo BB.
Colaborar para a disseminao da modelagem de dados, como fase essencial no

processo de desenvolvimento de sistemas de informao.
Objetivo geral de aprendizagem: Elaborar modelos de dados, em conformidade com
as normas, tcnicas e padres estabelecidos pelo BB.
Enfoque de aprendizagem: Instrumental
Contedo programtico:
1. Introduo
2. Modelagem de Dados Conceitual
3. Modelagem de Dados Lgica
4. Modelagem de Dados Fsica
Requisitos:
Modalidade: Presencial
Mdia: diversas
Carga horria: 40 horas (08h/dia) e 36 horas (06h/dia)
8
Modelagem de Dados
1. INTRODUO
1.1. Modelagem
Modelar uma atividade inerente capacidade de raciocinar do ser humano e
mostra-se presente desde os primrdios da humanidade.
Podemos viajar no tempo e imaginar o homem na Idade da Pedra quando

esculpia seus artefatos e efetuava pinturas em paredes de cavernas. Podemos
imaginar, ainda, gregos ou romanos arquitetando a construo de seus
templos, egpcios coordenando a construo das pirmides, escultores
concebendo suas obras a partir de miniaturas ou Ford esboando a linha de
produo do seu modelo T.
O que vemos de comum nesses exemplos que todos, de uma maneira ou de

outra, utilizavam representaes simplificadas da realidade, com o mesmo
objetivo: proporcionar melhor anlise, entendimento, concepo ou o registro
dessa realidade.
medida que o homem desenvolvia sua capacidade intelectual, percebia que o

sucesso de suas empreitadas muitas vezes estava diretamente relacionado ao
fato de planej-las antes de execut-las.
Assim, ele descobria, ainda que intuitivamente, que a modelagem, como parte
de um processo de conhecimento, estava intimamente associada etapa de
planejamento de qualquer atividade mais complexa. Por intermdio de um
modelo, era possvel melhor observar a realidade que se desejava conhecer e,
ento, estud-la, experiment-la, assimil-la.
1.1.1 O que modelagem?
Inicialmente, precisamos entender o que um modelo. Para isso, destacamos

algumas definies conhecidas, de acordo com diferentes autores:
Modelo uma representao da realidade, porm muito mais simples (Ackoff

e Sasieni, 1971).
Modelo uma representao do mundo real com o objetivo de permitir a

gerao e anlise de alternativas (Andrade, 1989).
Um modelo, alm de imitar a realidade, deve ter algum propsito definido

(Pidd 1998).
Modelo uma representao simplificada e abstrata de fenmeno ou situao

concreta, e que serve de referncia para a observao, estudo ou anlise
(Dicionrio Aurlio).

Modelagem de Dados
Como exemplos de modelos frequentemente observados em nosso cotidiano,

podemos citar:
a planta hidrulica de uma residncia;
um aeromodelo utilizado em teste de aerodinmica;
um manequim na vitrine;
o molde de uma roupa obtido em uma revista;
o memorial descritivo de um apartamento.
Representao de uma planta hidrulica
Nesses exemplos, constatamos que, por meio de um modelo, podemos

antecipar ou substituir a existncia de uma realidade qualquer, seja ela
concreta ou no. No caso de um arquiteto que desenha a planta baixa de uma
residncia, temos uma realidade que, a princpio, s existe em sua imaginao.
J no caso de uma planta baixa da mesma residncia, elaborada aps uma
vistoria, temos um modelo de uma realidade concreta.
Em qualquer caso, a realidade (objeto) em foco sempre o ponto de partida da

modelagem. Portanto, para seu sucesso, de suma importncia que a
investigao, levantamento e anlise das informaes que caracterizam o
objeto a ser modelado sejam efetuados de forma criteriosa.
Visto isso, podemos definir modelagem como o processo de representar uma

realidade (objeto ou sistema) de uma maneira simplificada e a partir de
determinada viso, de modo a permitir a anlise, compreenso, assimilao,
teste de comportamento ou projeo de alternativas para aquela realidade.
A necessidade da modelagem cresce conforme a complexidade da realidade

que se pretende modelar. Um canil pode ser construdo sem um projeto. No
entanto, medida que evolumos para a construo de casas e, em seguida,
para arranha-cus, a necessidade de um projeto torna-se evidente.
10
Modelagem de Dados
De maneira semelhante, um aplicativo pequeno, criado por uma nica pessoa

em alguns dias, pode at ser facilmente compreendido em sua totalidade sem
o auxlio de um modelo. No entanto, um sistema de comrcio eletrnico, um
sistema de controle de trfego areo, ou um sistema meteo-oceanogrfico no
podem mais ser facilmente entendidos e construdos sem planejamento e
documentao adequados.
Representao de um sistema meteo-oceanogrfico
No mbito corporativo, encontramos diversos tipos de modelos nossa volta.

Em uma empresa, h modelos de negcios, processos, informao,
econmicos, estruturais, bem como os modelos de sistemas de informao.
No ambiente computacional, os sistemas de informao devem tambm passar

por alguma espcie de modelagem, gerando tipos de artefatos diversos, como:
modelos de arquitetura, comunicao, software, hardware, funes, assim
como os modelos de dados, que o objeto de nosso curso.
1.2. Modelagem de Sistemas
1.2.1 Para que modelamos?
Como viso simplificada de uma realidade, o modelo de um sistema, em

funo do grau de abstrao utilizado, exibe os elementos essenciais e oculta
os detalhes no essenciais dessa realidade. til para auxiliar na
compreenso do sistema, capturar requisitos com preciso, permitir a
explorao e comparao de alternativas de projeto a um baixo custo,
comunicar decises sem ambiguidade, formar uma base para implementao.
Alm disso, o modelo de sistema:

Modelagem de Dados
representa um ambiente (negcio) observado: organizacional, funcional, de

comunicao, de software, de hardware, de dados;
Representao de um ambiente observado Imagem de Cheque

Fonte: Arquitetura de Imagem de Cheque DITEC/GEARQ
serve de instrumento de comunicao: os modelos so utilizados para o

entendimento e a transmisso de requisitos, conceitos, especificaes e
regras, tanto entre a rea negocial e a tecnolgica, como entre os diversos
segmentos tecnolgicos;
uniformiza conceitos a partir de vises distintas do mesmo ambiente
observado;
serve como referencial para a gerao de estruturas a serem
implementadas (redes, funes, dados, etc.);
serve como documentao do sistema.
1.2.2 Por que modelamos?
Devemos lembrar que os sistemas esto em constante evoluo e, portanto,

sempre haver demandas por novas funcionalidades. A modelagem adequada
permitir o atendimento dessas demandas de forma eficiente, mantendo a
consistncia com as funcionalidades j implementadas e contribuindo para o
compartilhamento do conhecimento.
12
Modelagem de Dados
Nesse contexto, um ponto importante a ser considerado que cerca de 65%

dos custos de um sistema esto associados s manutenes que ele ir sofrer
ao longo de sua utilizao, tanto corretivas como evolutivas.
Custos de um Sistema
Requisitos
5% Projeto
25%
Codificao Modelagem
Manuteno 5%
65%
Uma vez que as manutenes de um sistema so inevitveis e caras, o

analista deve se preocupar em projetar um sistema de forma a minimizar os
custos de sua manuteno. Um sistema com um planejamento cuidadoso,
embora com custo inicial mais alto, ter sua evoluo facilitada e seu custo
total diminudo. Dessa maneira, a manutenibilidade adequada do sistema deve
ser um dos principais motivadores de uma boa modelagem.
Sob outra anlise, conforme a figura abaixo, podemos perceber que,

estatisticamente, alto o percentual de erros no desenvolvimento de um
sistema de informao devido execuo inadequada da fase de modelagem.
Origem dos Erros
Outros
Cdigo
10%
7%
Requisitos
Modelagem
56%
27%
Ainda hoje, no h muitos profissionais que reconheam a modelagem como

atividade vital no desenvolvimento de sistemas de informao. H poucos que

Modelagem de Dados
despendem tempo e energia com tal atividade e, menos ainda, os que

conseguem fazer um bom trabalho de modelagem.
Profissionais de Desenvolvimento
Modelagem como Atividade Vital
Consomem Tempo com Modelagem
Bom Trabalho de Modelagem
Percepo atual da importncia da modelagem de sistemas
1.2.3 Escopo, prazo e recurso.
A probabilidade de xito da fase de modelagem pode ser definida em funo

de trs fatores crticos de sucesso: escopo, prazo e recursos humanos
disponveis. No possvel a alterao de um desses parmetros sem
impactar os outros dois, sob pena de comprometer a qualidade do modelo ou
inviabilizar o processo. Vejamos o que significa esse trip:
Escopo: imprescindvel a definio da abrangncia do que se pretende
modelar (toda uma paisagem, ou s uma rvore?, uma casa ou somente
um quarto?, todo um segmento negocial ou apenas determinado
produto?).
Prazo: o cronograma da tarefa de modelagem deve ser condizente com a
sua complexidade. Os prejuzos que podem advir de uma anlise mal
efetuada ou efetuada s pressas podem ser difceis de reparar, alm de
aumentar o custo desta fase do projeto.
Recursos humanos: essencial que os profissionais que dominem as
tcnicas de modelagem assim como os especialistas no negcio/sistema a
ser modelado estejam disponveis.
14
Modelagem de Dados
Custo e qualidade
1.2.4 Como modelamos?
Para que um processo de modelagem de sistemas seja bem executado,

algumas etapas devem ser cumpridas:
Observao: utilizao de tcnicas de levantamento de dados (entrevistas,
reunies, questionrios, anlise de documentos e de outros dados j
existentes), a fim de conhecermos o objeto a ser modelado. Tambm
contribuir, para esta etapa, a experincia do modelador em situaes
similares;
Entendimento: processo mental em que o objeto observado devidamente
identificado, conceituado, entendido e assimilado;
Representao: utilizao das tcnicas de modelagem para representar o
objeto;
Verificao: comprovao de que o objeto se integre a outros objetos
previamente modelados, mantendo a coerncia do modelo como um todo e
a fidelidade aos conceitos estabelecidos;
Validao: aprovao do modelo ou indicao de seus pontos falhos. Em
funo do envolvimento do modelador com o artefato gerado, o modelo
deve ser validado perante terceiros com conhecimento tanto tcnico como
do negcio (objeto), e resistir aos questionamentos e crticas apresentadas.
1.3. Modelagem de Dados
1.3.1 Viso Geral
Agora que j abordamos diversos aspectos sobre a modelagem, tanto no caso

geral como no universo computacional, vamos adentrar o tema de nosso curso:
a modelagem de dados em sistemas de informao.

Modelagem de Dados
Antes de falarmos de modelagem de dados, precisamos saber o que dado. O

conceito de dado, apesar de frequentemente confundido com o de informao
ou o de conhecimento, tem uma abordagem muito mais simples no mbito dos
sistemas de informao: dado uma seqncia de smbolos quantitativos ou
quantificveis, como textos, nmeros, imagens, sons, etc. que caracterizam,
traduzem, integram uma realidade ou parte dela.
Eis algumas consideraes e definies a respeito de dado, informao,

conhecimento e sabedoria:
Dado:
sequncia de smbolos quantificados ou quantificveis (Valdemar
Setzer);
nmeros, textos, imagens sem significado;
sinttico;
Informao:
abstrao informal (no pode ser formalizada atravs de uma teoria
lgica ou matemtica) e mental que representa algo significativo para
algum (Valdemar Setzer);
semntico;
dado contextualizado (Keith Devlin );
dado associado a um significado;
conjunto de dados aplicveis a determinada situao;
nmeros, textos, imagens com significado;
dados com utilidade; (quem, o que, onde, quanto, quando).
Conhecimento:
abstrao interior, pessoal de algo que foi experimentado, que foi vivido
por algum (Valdemar Setzer);
informao internalizada e que pode ser utilizada (Keith Devlin);
combinao de instintos, idias, regras e procedimentos que dirigem
pensamentos e aes;
entendimento de uma informao que nos permite ter opinies, tomar
decises, formar julgamentos ou fazer previses;
aplicao de dados e informaes.
Sabedoria:
cincia;
conjunto de conhecimentos socialmente adquiridos ou produzidos,
historicamente acumulados, dotados de universalidade e objetividade
que permitem sua transmisso, e estruturados com mtodos, teorias e
linguagens prprias, que visam compreender e orientar as atividades
humanas.
16
Modelagem de Dados
Dos dados sabedoria
... dados so puramente sintticos, enquanto informao contm, necessariamente,

semntica. Conhecimento uma abstrao interior (...) relacionada a alguma coisa existente no
mundo real e do qual temos uma experincia direta.
Valdemar Setzer, Instituto de Matemtica e Estatstica - USP.
Voltando ao foco do curso, tomemos como exemplo os dados de uma pessoa

(objeto observado):
seu nome;
seu CPF;
sua imagem (foto);
sua profisso;
sua renda mensal,
seu endereo.
Nome Jos da Silva

CPF 111.111.111-11
Foto (imagem do Jos)
Profisso Bancrio
Renda Mensal 3.000,00
Endereo Rua dos Arcos, s/n
Indicador de residncia Sim
prpria
Na coluna da direita, temos os dados propriamente ditos, enquanto na da

esquerda, temos as estruturas necessrias para armazenar os dados que
desejamos conhecer a respeito do objeto Pessoa, no caso, Jos da Silva.

Modelagem de Dados
Definimos Modelagem de Dados como a atividade de especificao das

estruturas de dados e regras de negcio tratados em um sistema de
informao.
A princpio, em um modelo de dados, teremos estruturas organizadas que nos

permitiro:
em uma viso com maior abstrao, compreender e representar de uma
maneira simplificada, que tambm possa ser entendida pelo usurio final,
os objetos que compem uma realidade, suas caractersticas, conceitos,
como se relacionam e a que regras de negcio devem obedecer;
em uma viso com menor abstrao, representar, de uma maneira
suficientemente detalhada para que possam ser criadas em bancos de
dados, as estruturas de dados, como se comporo, como se relacionaro e
que aspectos tecnolgicos devero observar.
Mais frente, veremos com detalhes o que so, como so utilizados, para que
servem e como se relacionam os componentes de um Modelo de Dados.
1.3.2 A evoluo da modelagem de dados
No incio da era da informtica, desenvolviam-se sistemas com nenhuma ou

pouca necessidade de armazenamento de dados. Eles basicamente se
prestavam automao de tarefas, como no caso de mquinas operatrizes em
linhas de produo fabris.
A complexidade era gerenciada de modo informal. Optava-se pelo "ir direto

para a implementao", sem muito se preocupar com o planejar. Muitas vezes,
o demandante do sistema sentava-se ao lado do programador que j iniciava o
desenvolvimento da aplicao (ainda hoje essa tendncia persiste). Porm, tal
fato torna-se invivel para os sistemas atuais, muito mais complexos.
A necessidade de sistematizao/automatizao de processos ocorrida nos

ltimos 40 anos provocou um boom na indstria de software. Com a evoluo e
concorrncia dessa indstria, no mais seria suficiente possuir um software
que pudesse automatizar um processo, mas um software que o fizesse com
altos nveis de confiabilidade, segurana, agilidade, em curtos espaos de
tempo, escalonvel e integrado com outras solues, enfim, um software de
qualidade.
Sistemas passaram a ser desenvolvidos por equipes muitas vezes distribudas

geograficamente ao redor do planeta, e com a necessidade de se integrarem a
outros sistemas.
Alm disso, a necessidade de armazenamento e gerenciamento dos dados

produzidos cresceu vertiginosamente. Diversas metodologias de
desenvolvimento de software se sucederam, assim como os SGBD - Sistemas
Gerenciadores de Bancos de Dados, cada vez mais poderosos e com mais
funcionalidades.
18
Modelagem de Dados
Em tais metodologias, um fato ficou caracterizado: para obter-se um software

de qualidade seria necessrio trilhar etapas. Uma delas, provavelmente a
principal, seria a do planejamento desse software.
Assim como na abordagem geral, a modelagem surge no contexto da

informtica como ferramenta essencial na fase de planejamento, tanto na etapa
de anlise como na de projeto.
Ao longo dos anos, vrias metodologias de modelagem de dados foram

desenvolvidas, acompanhando a evoluo dos tipos de banco de dados.
Considerando-se a metodologia empregada, podemos classificar os modelos
de dados em trs grupos:
Modelos Baseados em Registros:
Modelo Hierrquico;
Modelo de rede;
Modelo Relacional.
Modelos Baseados em Objetos:

Modelo Entidade-Relacionamento;
Modelo Orientado a Objetos.
Modelos Fsicos:
Modelo Unificador (unifying model):
Estrutura de Memria (frame memory).
Por outro lado, a partir de uma abordagem cronolgica e tendo como

referencial o surgimento da Teoria Relacional, podemos classific-los em:
1 Gerao Modelagem Pr-Relacional:

Modelo Hierrquico;
Modelo de rede.
2 Gerao Modelagem Relacional:

Modelo Entidade-Relacionamento;
Modelo Relacional.
3 Gerao Modelagem Ps-Relacional:

Modelo Orientado a Objetos;
Modelo Objeto-Relacional;
Modelo Geogrfico.
Veremos a seguir as caractersticas de alguns desses tipos de modelos.
1.3.3 Modelo Hierrquico
Entre os pr-relacionais, o Modelo Hierrquico representa uma coleo de

registros conectados uns aos outros por meio de links. Um link uma
associao entre exatamente dois registros.

Modelagem de Dados
Neste modelo, os registros so organizados como colees de rvores em vez

de grficos arbitrrios e cada registro uma coleo de campos (atributos),
cada qual contendo somente um valor.
Um Modelo Hierrquico consiste de dois componentes bsicos:
caixas: que correspondem aos tipos de registro;

linhas: que correspondem aos links.
Estrutura Hierrquica de Dados

MDICO Cd_Med Nome_Med Especialidade
PACIENTE Cd_Pac Nome_Pac Data Hora
M1 LEON PEDIATRA M2 CARLOS CARDIOLOGIA
P2 GERSON 2/1 14 P3 MATHIAS 10/1 14

P3 MATHIAS 17/1 15
M3 MARIA NEUROLOGIA
Abaixo, exemplo esquemtico de um Modelo Hierrquico com estrutura em

rvore:
20
Modelagem de Dados
Note que, nesta estrutura, a rvore se inicia com apenas um pai (tambm
chamado de root) que pode ou no se relacionar com um ou mais filhos,
mas um filho s pode se relacionar com um nico pai.
1.3.4 Modelo de rede
Em sequncia, surgem os modelos de rede que se caracterizam por

representar os dados como uma coleo de registros e os relacionamentos
entre os dados como links. Dessa forma, um registro pode ter uma construo
hierrquica. Os registros com a mesma estrutura formam um tipo de registro.
A principal caracterstica do modelo de rede permitir a navegao entre os

registros por meio de Conjunto de Dados, que possui um registro proprietrio e
registros membros, cujos relacionamentos so implementados por meio de
ponteiros. Como no h limitao na topologia criada pelos registros e
conjuntos, o modelo permite a criao de redes, de onde ganhou o nome.
Estrutura de Dados em Rede

MDICO PACIENTE
Cd_Med Nome_Med Especialidade Cd_Pac Nome_Pac
Med_cons Pac_cons
CONSULTA Data Hora
M1 LEON PEDIATRA 2/1 14 P1 LISANDRA
10/1 14
M2 CARLOS CARDIOLOGIA P2 GERSON
14/1 15
M3 MARIA NEUROLOGIA 10/1 14 P3 MATHIAS

8/1 15
O Modelo Hierrquico e o Modelo de Rede sofrem dos mesmos problemas:

complexidade dos diagramas de estrutura de rvore (ou estrutura de dados
no caso de modelo de rede);
restries cardinalidade dos links;
ausncia da facilidade de consultas declarativas;
necessidade de navegao por ponteiros para acesso s informaes;
consultas complexas;
modelos fortemente influenciados pelas caractersticas fsicas do banco de
dados.

Modelagem de Dados
1.3.5 Teoria Relacional
Em 1970, Edgar F. Codd revolucionou a rea de banco de dados ao formular

sua Teoria Relacional, que consistia em descrever os bancos de dados atravs
de um conceito matemtico simples: a teoria dos conjuntos.
Assim, um banco de dados passaria a ser enxergado pelos usurios como um

conjunto de tabelas bidimensionais, compostas de linhas e colunas. Cada
tabela possuiria informaes sobre determinado assunto de forma estruturada
e organizada e se relacionaria com as outras tabelas do banco de dados.
Para tanto, algumas premissas foram estabelecidas:

cada uma das tabelas uma relao (termo matemtico);
o conjunto de uma linha e suas colunas chamado de tupla;
cada coluna dessa tabela tem um nome e representa um domnio da
tabela;
no h duas linhas iguais na tabela;
toda tabela possui uma chave primria que identifica univocamente uma
linha;
as colunas possuem nomes;
a ordem das linhas e das colunas irrelevante;
cada tabela tem um nome prprio, distinto de qualquer outra tabela do
banco de dados.
Estrutura Relacional de Dados

MDICO Cd_Med Nome_Med Especialidade
PACIENTE Cd_Pac Nome_Pac
CONSULTA Cd_Med Cod_Pac Dia Hora
MDICO PACIENTE
Cd_Med Nome_Med Especialidade Cd_Pac Nome_Pac
M1 Leon Pediatria P1 Lisandra
M2 Carlos Cardiologia P2 Gerson
M3 Maria Neurologia P3 Matias
CONSULTA
Cd_Med Cd_Pac Dia Hora
M1 P1 2/1 14
M2 P3 7/2 10
M3 P3 10/1 11
22
Modelagem de Dados
1.3.6 Modelo Entidade Relacionamento (MER)
Baseado na Teoria Relacional, em 1976, Peter Chen publicou um trabalho

intitulado "The Entity-Relationship Model: Toward the unified view of data" que
passou a ser considerado como um referencial definitivo para o processo de
modelagem de dados.
O modelo Entidade-Relacionamento tinha por base a percepo de que o

mundo real era formado por um conjunto de objetos chamados de entidades e
pelo conjunto de relacionamentos entre esses objetos. Foi desenvolvido para
facilitar o projeto do banco de dados, permitindo a representao de toda a
estrutura conceitual. Tal tipo de modelo, ainda hoje, um dos que possui maior
capacidade semntica na representao dos dados.
A tcnica, bastante simples, utiliza basicamente retngulos para representar as

entidades, losangos para representar os relacionamentos e bales para alocar
os atributos, que formam as caractersticas de cada entidade.
Matrcula Cdigo
Nome Sala
Endereo Perodo
(1,n) (1,1)
ALUNO Compe TURMA
Modelo de Peter Chen
1.3.7 Modelo Relacional
Com o passar dos anos, a metodologia proposta por Peter Chen passou por
transformaes efetuadas no s pelo prprio autor, como por estudiosos
(James Martin, Chris Date, James Rumbaugh, a Fora Area Americana) dela
derivando-se outras metodologias e notaes.
idia original de uma representao pura e fiel da realidade, incorporaram-se

aspectos ditos lgicos, como representao das chaves primrias e chaves
estrangeiras, normalizao e decomposio de agregaes em novas
entidades (conceitos que sero explorados mais adiante), o que j espelhava a
interferncia da metodologia de desenvolvimento naquela representao pura.
Com o propsito tambm de definir as estruturas a serem implementadas em

bancos de dados, no que se convencionou chamar de nvel fsico, foram
acrescidos novos tipos de objetos modelagem original, como ndices,
histricos de tabelas, etc.
Uma das tcnicas de modelagem que se sucederam foi a da Modelagem

Relacional, desenvolvida pelo pai da Teoria Relacional, Codd, e tambm

Modelagem de Dados
aperfeioada mais tarde por outros estudiosos, como Chris Date. Ainda que a
Teoria Relacional tenha sido proposta no incio da dcada de 70, somente na
dcada seguinte que se firmou, concomitantemente ao uso da modelagem
relacional em projetos de bancos de dados.
Neste momento do curso importante esclarecer uma espcie de confuso de

conceitos que se estabeleceu em funo da semelhana dos termos
Relacionamento e Relacional.
O termo "Relacional", tanto da Teoria Relacional como da Modelagem

Relacional, diz respeito exclusivamente abordagem matemtica da teoria dos
conjuntos utilizada por Codd, em que cada tabela considerada uma relao.
Nada tem a ver com o "Relacionamento" utilizado por Chen como forma de
representar as interaes entre as diversas entidades que compem uma
realidade.
Como na Modelagem Relacional a representao utilizada para ligar as

entidades tambm uma linha conhecida como Relacionamento, muito
frequente e equivocadamente o Modelo Relacional chamado de Modelo
Entidade-Relacionamento (MER).
Lembremo-nos de que o MER trata-se de uma representao de alto nvel de

abstrao, enquanto que, no Modelo Relacional, h abordagens com menor
grau de abstrao, em que so tratados aspectos lgicos e fsicos.
No Modelo Relacional, encontramos as mesmas estruturas utilizadas no MER

(entidades, relacionamentos e atributos), ao tempo em que so introduzidos
novos objetos e conceitos.
1.3.8 Modelagem de Dados no Banco do Brasil
Com essa abordagem inicial, pudemos conhecer a origem e importncia da

modelagem de dados, a evoluo das diversas tcnicas e comear a entender
um pouco melhor a Modelagem Relacional, hoje amplamente utilizada para
sistemas suportados por bancos de dados relacionais.
A partir deste ponto, vamos nos referir ao processo em estudo simplesmente

como Modelagem de Dados que, por sua vez, gerar um artefato conhecido
como Modelo de Dados, que contemplar os trs nveis de abstrao
(conceitual, lgico e fsico).
24
Modelagem de Dados
Dessa forma, nos captulos seguintes, aprenderemos a produzir um modelo de

dados que contemple esses trs nveis:
Modelo de Dados Conceitual: representa as entidades do negcio, seus

relacionamentos e principais atributos, em um alto grau de abstrao. Os
objetos nele observados representam fielmente o ambiente negocial,
desconsiderando qualquer limitao imposta por metodologias de
desenvolvimento de sistemas;
Modelo de Dados Lgico: representa os objetos em um grau mais baixo de

abstrao, de acordo com regras de implementao e limitantes impostos
por algum tipo de tecnologia, porm parte de qualquer exigncia dos
dispositivos de armazenamento de dados;
Modelo de Dados Fsico: representa os objetos no menor grau de

abstrao possvel, com o foco no nvel da implementao fsica das
tabelas, colunas e relacionamentos e totalmente aderente s caractersticas
do SGBD utilizado.
No que diz respeito padronizao da modelagem de dados no Banco do

Brasil optou-se por utilizar a notao preconizada por James Martin, presente
na metodologia por ele desenvolvida, conhecida como Engenharia da
Informao. Tal notao suportada pela ferramenta de modelagem de dados
atualmente utilizada (ERwin).

Modelagem de Dados
2. MODELAGEM DE DADOS CONCEITUAL
2.1 Disposies Gerais
A depender do grau de abstrao utilizado, o processo de modelagem de

dados produzir artefatos em trs diferentes nveis: Conceitual, Lgico e Fsico.
Neste captulo aprenderemos a produzir um modelo de dados em seu nvel de

maior abstrao, o Conceitual. Veremos como se d o processo de abstrao,
como identificar os objetos a serem representados, suas caractersticas e
relacionamentos e, ao final, estaremos aptos a produzir o Modelo de Dados
Conceitual do caso que adotaremos para estudo em nosso curso.
O Modelo de Dados Conceitual (MDC) o artefato resultante do processo de

modelagem que representa o ambiente observado com o mximo de fidelidade
possvel. No MDC, todos os objetos (coisas) existentes no mundo real so
traduzidos em entidades, caracterizados por atributos e interagem por
relacionamentos.
Atributo 1
Atributo 2
ENTIDADE 1 Relacionamento ENTIDADE 2
O MDC desenvolvido a fim de possibilitar o entendimento e captura do

conhecimento do negcio, a partir da perspectiva dos dados (no dos
processos).
26
Modelagem de Dados
A modelagem conceitual de dados uma atividade que tem como ponto de

partida os Requisitos de Informao e as Regras de Negcio inerentes a um
determinado Domnio de Conhecimento (Parcela do Mundo Real, Mini-Mundo
ou Domnio de Problema).
Junto s metodologias de desenvolvimento de sistemas, o MDC sempre

aparecer associado s fases de anlise e nunca s de projeto, visto que
nesse nvel de modelagem no devemos ter em mente os modos de
implementao ou outras caractersticas de construo. Assim, ele pode ser
construdo tanto nos casos de anlise de projetos que utilizem uma abordagem
relacional ou aqueles apoiados nas tcnicas de orientao a objetos.
Apesar de muitas vezes o MDC ser iniciado aps a etapa de levantamento de

requisitos, a boa prtica, recomendada pelos estudiosos de modelagem,
sugere que o modelo conceitual seja desenvolvido concomitantemente ao
levantamento dos requisitos, como ferramenta auxiliar. A representao grfica
efetuada em um MDC facilita o entendimento do negcio e serve de ponto de
convergncia entre desenvolvedores da rea de sistemas de informao e
gestores da rea negocial.
Alm de sua funo principal de retratar o ambiente a ser modelado, o MDC

serve como ponto de partida para o planejamento das estruturas fsicas a
serem implementadas em bancos de dados relacionais. Nesse caso, dele ser
derivado o Modelo de Dados Lgico - MDL, que por sua vez dar origem ao
Modelo de Dados Fsico - MDF.
O fato de elaborarmos o MDC, discuti-lo e valid-lo com o gestor para obter a

sua aprovao, ainda na fase de levantamento de requisitos, pode trazer tona
regras de negcio que no foram percebidas previamente. Ao desenvolver o
modelo conceitual, devemos agir como um detetive e colocar prova o negcio
representado, bem como pensar em possveis excees s regras negociais.
O foco de um MDC o contexto em que os dados esto inseridos. Entender

esse contexto e como os dados se relacionam uns com os outros
fundamental para o futuro desenvolvimento da soluo tecnolgica.
Imagine um quebra cabeas, onde voc no tem a figura que o orientar na

montagem. Voc pode at forar as conexes entre as peas (entidades) e
conseguir os encaixes (relacionamentos) entre elas e, dessa forma, montar o
quebra-cabeas. Porm, nada garante que ele estar realmente representando
o contexto sob anlise. O MDC a figura na caixa do quebra-cabea que lhe
prov a informao de com que o quebra-cabea dever se parecer ao final da
montagem.
Veremos agora algumas caractersticas de um Modelo de Dados Conceitual:

um modelo simples;
tem seu foco nos conceitos e relacionamentos entre eles;
independe de detalhes de implementao em um SGBD;

Modelagem de Dados
o primeiro estgio no processo top-down de design de banco de dados;

efetua a representao grfica do negcio;
facilita a definio da semntica dos dados de um domnio;
facilita a compreenso do negcio por todos os nveis de usurios;
facilita a manuteno dos dados;
facilita a migrao de SGBD;
auxilia na previso de esforo (prazo e custo).
2.2 Estruturas
Como visto anteriormente, Peter Chen publicou, em 1976, um artigo onde
props um novo artefato para modelar dados: o Modelo Entidade-
Relacionamento, tambm conhecido como MER.
O MER, que uma representao dos dados em alto nvel de abstrao, ainda
hoje o artefato mais utilizado para a elaborao de um Modelo de Dados
Conceitual.
Iniciaremos nossos estudos sobre modelagem conceitual a partir da elaborao

do Modelo Entidade-Relacionamento.
Existem trs tipos de estruturas bsicas empregadas em um MER: entidades,

relacionamentos e atributos.
2.2.1 Entidades
Uma entidade pode representar qualquer coisa do mundo real, abstrata ou

concreta, sobre a qual se deseja guardar informaes, num determinado
contexto. A entidade deve ter um conceito muito bem definido, distinta de
qualquer outra coisa. Alguns autores a denominam de tipo de entidade. Em
nosso curso, optamos pela forma mais comum de denominao: entidade.
A fim de ajudar no processo de identificao das entidades, foi criado um

sistema de classificao (Shlaer & Mellor) que agrupa as entidades em:
coisas tangveis que tm existncia concreta, como: Cliente, Produto,
Dependncia;
funes exercidas por elementos, como papis, atribuies e
classificaes: Gerente, Departamento de Compras, Funcionrio;
eventos ou ocorrncias que so percebidos quando uma ao se
desenrola, como: Pagamento de Fatura de Carto;
interaes resultantes da associao de objetos em funo de um processo
executado, como: Jurisdio de Dependncia, Contrato de Compra;
28
Modelagem de Dados
especificaes que representam elementos que caracterizam outros

objetos, como: Tipo de Pessoa, Modelo de Automvel.
A cada objeto do conjunto representado por uma entidade, individualizado por

suas caractersticas prprias, d-se o nome de ocorrncia ou instncia da
entidade. No exemplo abaixo, Tarso uma instncia da entidade Pessoa, Porto
Alegre uma instncia da entidade Cidade.
PESSOA CIDADE Entidades
PESSOA CIDADE
Tarso Porto Alegre

Alberto So Paulo Ocorrncias
Ana Belo Horizonte da Entidade
A entidade representada no diagrama original de Chen por um retngulo

contendo o nome da entidade (substantivo, no singular).
MDICO
Dicionarizao da Entidade
Cada uma das entidades identificadas e representadas no MDC dever ser

definida claramente para que, associando-se ao seu nome, sua representao
e sua definio, sejamos capazes de ter o completo entendimento do que se
procura transmitir.
O nome de uma entidade deve ser claro e objetivo, designando exatamente o

que ela representa e grafado no singular.
Assim, se em uma caixa colocamos clipes, essa caixa pode ser chamada de
repositrio de clipes. Porm se colocarmos, alm dos clipes, lpis, borracha,
caneta e cola, ela no dever se chamar mais de repositrio de clipes e sim
repositrio de material de expediente. Se assim no for, poderemos incorrer
em uma anomalia de modelagem de dados conhecida como ambiguidade, em
que duas ou mais interpretaes so possveis para o mesmo objeto.
Com relao aos termos a serem utilizados na composio dos nomes,

verificar o LIC 139.03.51.01.
Algumas regras devem ser seguidas a fim de facilitar a interpretao do

modelo:

Modelagem de Dados
nenhum modelo suficientemente claro se no for acompanhado de uma

definio formal dos seus elementos (Dicionrio de Dados);
clareza, preciso e especificidade so necessrias nas definies, que
devero conter conceitos (o que , o que faz, para que serve, regras,
excees) e exemplos ilustrativos;
os conceitos que possam parecer triviais a quem est modelando no
sero do mesmo modo triviais a outras pessoas que no tenham
conhecimento prvio do assunto tratado.
Para a dicionarizao de uma entidade, deveremos ter em mente algo que

satisfaa grande parte das seguintes perguntas (seno todas):
O que a entidade?
O que faz a entidade?
Para que serve?
O que engloba essa categoria de elementos?
O que est excludo dessa categoria?
Quando algum ou alguma coisa passa a ser ou deixa de ser um elemento
desse tipo?
Sua permanncia nessa categoria imutvel?
2.2.2 Atributos
Ao observarmos os objetos em uma realidade, na verdade estaremos

reconhecendo-os pela identificao das caractersticas inerentes a cada tipo de
objeto.
Os atributos so informaes sobre uma entidade que necessitam ser

conhecidas ou mantidas. Eles descrevem uma entidade pela qualificao,
identificao, classificao, quantidade ou expressando o estado da entidade.
So as propriedades elementares da entidade.
Um ou mais atributos descrevem uma entidade, e os valores desses atributos

descrevem as instncias da entidade. Se uma entidade algo de significado
sobre o qual queremos guardar dados, ento o atributo define cada um dos
dados armazenados.
O nome conferido ao atributo deve oferecer a melhor compreenso do seu
significado.
Cada atributo apresentar um domnio prprio, ou seja, um conjunto de valores

permitidos que ele poder assumir em cada instncia da entidade.
importante frisar que toda entidade deve possuir atributos.
30
Modelagem de Dados
Exemplo:
NOME DO PRODUTO e TEXTO DO PRODUTO so atributos da entidade
PRODUTO.
NOME DA MODALIDADE DE PRODUTO, NOME FANTASIA DA
MODALIDADE DE PRODUTO, so atributos da entidade MODALIDADE DE
PRODUTO.
Os atributos so representados no diagrama original de Chen por uma elipse
contendo o nome do atributo e conectada entidade qual pertena.
Telefone
MDICO
Nome
Cdigo
O modelo acima no informa se determinado mdico pode ter vrios telefones,

ou mesmo se algum mdico pode no ter telefones. Para deixar o modelo mais
preciso, alguns autores costumam expressar cardinalidade para os atributos,
como no modelo abaixo
Telefone (0,N)
MDICO
Nome
Cdigo
Dessa forma, podemos concluir que determinado mdico pode no ter telefone
(cardinalidade mnima zero) ou pode ter vrios (cardinalidade mxima N).
A cardinalidade dos atributos CDIGO e NOME (1,1). Por conveno, ela foi
omitida do diagrama.
No caso de atributos, a cardinalidade mnima 1 indica que o atributo

obrigatrio e a cardinalidade mxima 1 indica que o atributo monovalorado.
Para o atributo telefone, a cardinalidade mnima 0 indica que o mesmo
opcional e a cardinalidade mxima N informa que ele multivalorado. Para
cada atributo, h um conjunto de valores admissveis, conhecido como domnio
do atributo.
O atributo pode ser classificado em:

simples ou atmico: no divisvel (Sexo, Tipo Sanguneo);
composto: divisvel em atributos simples com significado independente:
o atributo Endereo pode ser decomposto em (Rua, Nmero,
Complemento, Cidade, etc.);

Modelagem de Dados
a composio de atributos pode ser hierrquica (o atributo Endereo

decomposto faz com que ele seja visto como ((Rua, Nmero,
Complemento), Cidade, Cdigo Postal).
monovalorado: s pode ter um nico valor para cada entidade;
multivalorado: pode tomar um ou mais valores para cada entidade (Atributo
Grau Acadmico: licenciado, mestre, doutor, etc.);
complexo: formado por atributos compostos e multivalorados combinados
arbitrariamente (o atributo Grau Acadmico pode ser decomposto em
Instituio, Ano, Grau, rea);
derivado: pode ser determinado a partir de outros atributos (o atributo Idade
pode ser calculado a partir do atributo Data Nascimento);
valor nulo (NULL): quando o atributo pode no ser aplicvel a todas as
instncias da entidade (o atributo Grau Acadmico s se aplica a pessoas
com curso superior). O valor nulo pode ser igualmente utilizado noutras
situaes, como quando o valor do atributo no conhecido ou quando o
valor do atributo est em falta.
Entidade Atributos
CLIENTE
Identidade Nome Endereo Telefone Altura Peso
123567-PB Ezequiel S Rua Felix,45 3223.1111 1,87 84
675432-CE Jane Sales Beira Mar,24 3224.2222 1,65 60
757575-PE Caio Graco Dias S,42 3226.4444 1,72 70
Domnios
Vemos abaixo, a representao da situao acima, utilizando o MER:

Identidade
Nome
Endereo
CLIENTE Telefone
Altura
Peso
Os atributos podem ser enquadrados em trs grandes grupos: descritivo,

nominativo e referencial. Tal classificao tem sua relevncia apenas para um
32
Modelagem de Dados
melhor entendimento dos atributos, no contribuindo para o aspecto semntico

da modelagem conceitual.
Os Atributos Descritivos representam as caractersticas intrnsecas dos objetos.

Em princpio todo atributo descritivo, porm alguns podem ser tambm
classificados como nominativos ou referenciais. Ex.: data de nascimento,
quantidade de cilindros, ndice de reajuste.
Os Atributos Nominativos identificam o objeto a que pertencem, ainda que no

de maneira unvoca. Ex.: NOME DO CLIENTE, CDIGO DO MDICO, SIGLA
DA UF.
Os Atributos Referenciais no pertencem propriamente ao objeto onde esto

alocados, mas explicitam um relacionamento com outro objeto. Ex.: local de
trabalho, local de nascimento (FUNCIONRIO), nome do proprietrio
(IMVEL).
Em funo do nvel de abstrao desejado, apenas os atributos mais

significativos so representados no MER.
Dicionarizao do Atributo
O nome do atributo deve ser definido de modo a proporcionar uma melhor

exatido e compreenso de seu significado. Com relao aos termos a serem
utilizados na composio dos nomes dos atributos, verificar, tambm, o LIC
139.03.51.01.
Com relao descrio dos atributos, o que frequentemente se v que os

dicionrios de dados acabam por se transformar em tradutores de
mnemnicos. Assim como nas entidades, na definio de um atributo, deve-se
deixar clara toda e qualquer informao que seja de valia para o processo de
compreenso e unificao de conceitos:
Qual a finalidade do atributo?
O que significa o atributo?
Quando esse atributo designado entidade?
Depois de caracterizado, como este atributo pode ter seu valor modificado?
Quando esse atributo recebe um valor?
Quais so os valores possveis para o atributo?
O atributo tem um domnio discreto? Qual esse domnio?
Sempre que possvel, informar tambm exemplos dos domnios que o atributo
pode assumir.
Exemplo de definio de atributo:

Modelagem de Dados
Sigla da Unidade da Federao: Sigla composta de duas letras, representativa

de cada um dos estados que compem a Repblica Federativa do Brasil.
Exemplos dos domnios para Sigla da Unidade da Federao: SP, RJ, DF, etc.
2.2.3 Relacionamentos
Relacionamento uma associao entre as ocorrncias de uma, duas ou mais

entidades. O relacionamento entre as ocorrncias das entidades identifica um
fato ou acontecimento que liga dois ou mais objetos existentes no mundo real.
Essa ligao possui um significado dentro de um contexto e identificado de
forma nica.
Por meio dos relacionamentos, somos capazes de demonstrar como um objeto

se comporta em relao aos demais, seu grau de dependncia de outros, qual
a associao existente entre eles, como se subdividem, etc.
So representados no diagrama original de Chen por um losango contendo o

nome do relacionamento (verbo flexionado). Tal losango ligado por linhas s
entidades participantes do relacionamento.
MDICO Consulta PACIENTE
O modelo acima informa que se deseja manter informaes sobre mdicos,

pacientes, alm de um conjunto de associaes (consulta), cada uma ligando
um mdico a um paciente.
Um relacionamento, ainda que interligue entidades do modelo conceitual, na

verdade a representao do vnculo entre as instncias dessas entidades.
Essa caracterstica a principal fora do modelo de entidades e
relacionamentos, pois permite que, de certa forma, naveguemos pelo modelo.
Segundo o grau da relao, os relacionamentos podem ser classificados nos

seguintes tipos:
relacionamento entre duas entidades distintas (grau = 2);
PESSOA Reside ENDEREO
relacionamento entre trs ou mais entidades distintas, ternrio, quaternrio,

"n-rio" (graus = 3, 4, "n"). Algumas observaes se fazem necessrias
para esses relacionamentos:
34
Modelagem de Dados
algumas notaes de modelagem fazem com que um relacionamento

entre mais de dois objetos seja mapeado como uma entidade no
modelo. A notao original de Peter Chen resolve essa questo de
forma simples, permitindo o relacionamento direto entre os trs objetos;
por vezes, a realidade nos apresenta situaes em que trs ou mais
objetos se relacionam entre si. No modelo conceitual, tal situao no
frequente, muitas vezes ocultando a existncia de outro objeto que
representa essa conjuno de relacionamentos;
a depender das regras de negcio, outras vezes, ao analisarmos
melhor um possvel relacionamento ternrio, percebemos que existe um
relacionamento binrio entre dois dos objetos e, desse relacionamento
resulta uma ligao com o terceiro objeto.
Tomemos como exemplo a seguinte situao: um aluno s poder se

matricular em uma turma de uma matria que esteja prevista para seu curso.
Neste caso, deve haver um relacionamento prvio entre as entidades "Aluno" e
"Curso" e outro entre as entidades "Matria" e "Curso", para que seja composta
a entidade "Turma", que fruto do relacionamento entre esses dois
relacionamentos anteriores
Cdigo do Aluno
Nome do Aluno
ALUNO
(1,1)
Compe
Cdigo do Curso Cdigo do Curso
Nome do Curso Cdigo do Aluno
(0,N)
(1,1) (0,N)
Opta
ALUNO DO
CURSO CURSO
(1,1) (1,1)
Compe Contm
(0,N) (0,N)
(1,1) (0,N) (1,1) (0,N)
MATRIA Contm
GRADE
CURRICULAR Forma TURMA
Cdigo da Matria Cdigo do Curso

Nome da Matria Cdigo Do Curso
Cdigo da Matria
Cdigo do Aluno
Cdigo da Matria
relacionamento recursivo (autorrelacionamento);

ocorre quando a entidade de origem e a entidade de destino so as
mesmas (ocorrncias distintas de uma mesma entidade que se
relacionam).

Modelagem de Dados
(1,1) Esposo
PESSOA CASA
(1,1) Esposa
Assim como as entidades, os relacionamentos tambm podem possuir

atributos. So os chamados atributos de relacionamento ou, como dissemos
anteriormente, referenciais. Se tomarmos como exemplo as entidades
FUNCIONRIO e PROJETO, podemos dizer que FUNO o atributo do
relacionamento entre as entidades citadas.
EMPREGADO Atua PROJETO
Funo
Algumas tcnicas de representao grfica nos obrigam a transformar todo

relacionamento com atributo em uma nova entidade, o que j uma forte
influncia da modelagem lgica que veremos no prximo captulo. Tal fato
acontece por, simplesmente, no existirem elementos grficos que possibilitem
a representao dos atributos dos relacionamentos. Mais uma vez, a
representao de Peter Chen nos permite inserir os atributos no prprio
relacionamento.
Dicionarizao do Relacionamento
No MER, recomenda-se que os relacionamentos sejam nomeados, a fim de se

proporcionar o melhor entendimento possvel da realidade modelada.
Para tanto, utilizaremos verbos flexionados na terceira pessoa do singular do

presente do indicativo, na voz ativa ou passiva, considerando-se o sentido de
leitura do relacionamento da esquerda para a direita.
Cardinalidade de Relacionamento
No processo de reconhecimento e entendimento de um relacionamento,

existem regras que so extradas do prprio ambiente observado, que
determinam o tipo de associao entre as entidades.
Os Modelos de Entidades e Relacionamentos para serem completos, exigem

tambm a definio de um conjunto de restries como a cardinalidade dos
relacionamentos.
A cardinalidade de um relacionamento indica quantas ocorrncias de uma

entidade participam no mnimo (cardinalidade mnima) e no mximo
(cardinalidade mxima) do relacionamento com as ocorrncias de outra
entidade.
36
Modelagem de Dados
Cardinalidade mnima
A cardinalidade mnima o nmero que expressa a quantidade mnima de
ocorrncias da entidade que podem participar do relacionamento com outra
entidade. A cardinalidade mnima pode ser igual a zero (significando que no
obrigatria a ocorrncia da entidade no relacionamento) ou um (neste caso,
indicando a obrigatoriedade da ocorrncia da entidade no relacionamento).
Uma boa dica para identificar a cardinalidade mnima perguntar se pode no
existir a relao.
Cardinalidade mxima
A cardinalidade mxima expressa o nmero mximo de ocorrncias de uma

entidade que podem participar do relacionamento com uma ocorrncia de outra
entidade. Este nmero deve ser maior que zero e igual ou maior que a
cardinalidade mnima. Uma boa opo para identificao da cardinalidade
mxima perguntar sempre se pode haver mais de uma vez a relao.
Continuando com o exemplo anterior:

Pergunta: Um determinado EMPREGADO pode pertencer a mais de um
DEPARTAMENTO?
Resposta: No
A cardinalidade mxima do EMPREGADO, ento, de UM DEPARTAMENTO.
Pergunta: Um determinado DEPARTAMENTO pode possuir mais de um

EMPREGADO?
Resposta: Sim
Juntando a cardinalidade mnima com a mxima, temos:
(1,1) (1, N)
DEPARTAMENTO Lotado EMPREGADO
Um empregado deve estar lotado em um departamento.

Um departamento tem at N empregados lotados nele.
Outros exemplos de cardinalidades completas:
(0,1) (0,1)
DEPARTAMENTO Gerencia EMPREGADO
(0, N) (1,N)
PROJETOS Participa EMPREGADO
(1,1) (0,2)
PROJETOS Coordena EMPREGADO

Modelagem de Dados
Observemos as cardinalidades mnima e mxima representadas no modelo

abaixo:
(1,1) (0,N)
EMPREGADO Possui DEPENDENTE
Para fazermos a leitura do modelo, partimos de determinada entidade e a

cardinalidade correspondente a essa entidade representada no lado oposto.
Em nosso exemplo, a cardinalidade (0:N) faz referncia a EMPREGADO, j a
cardinalidade (1:1), faz referncia a DEPENDENTE. Isso significa que:
uma ocorrncia de empregado pode no estar associada a uma ocorrncia
de dependente ou pode estar associada a uma ou mais ocorrncias dele;
uma ocorrncia de dependente deve estar obrigatoriamente associada a
uma, e apenas uma, ocorrncia de empregado.
O mapeamento de cardinalidade para um relacionamento em particular

obviamente dependente das situaes reais que esto sendo modeladas. A
determinao de cardinalidades de um relacionamento pode afetar a colocao
de seus atributos.
Relacionamentos um para um, ou um para muitos devem associar os atributos

a uma das entidades participantes. Considere o caso das entidades CLIENTE e
CONTA, e o relacionamento Abre. O atributo Data de Abertura dever estar
associado entidade CONTA.
(1,1) (0,N)
CLIENTE Abre CONTA
Data de abertura
Cardinalidade 1 para 1
Indica que cada elemento de uma entidade A relaciona-se apenas com um

elemento da entidade B e vice-versa:
Exemplo:
(1,1) (0,1)
PESSOA CLIENTE
cada ocorrncia da entidade Pessoa pode se relacionar, no mximo, com

uma nica ocorrncia de Cliente;
cada ocorrncia da entidade Cliente sempre se relaciona com uma nica
ocorrncia de Pessoa.
38
Modelagem de Dados
Cardinalidade 1 para N
Indica que um elemento de uma entidade A relaciona-se com muitos elementos

de B e que um elemento da entidade B se relaciona com apenas um elemento
da entidade A.
(1,1) (0,N)
Possui MODALIDADE
PRODUTO DO PRODUTO
Exemplo:
cada ocorrncia da entidade Produto pode se relacionar com vrias
ocorrncias da entidade Modalidade de Produto;
cada ocorrncia da entidade Modalidade de Produto sempre se relaciona
com uma nica ocorrncia da entidade Produto.
Cardinalidade N para N
Indica que um elemento da Entidade A se relaciona com muitos elementos da

entidade B e vice-versa.
Exemplo:
(1,N) (0,N)
Celebra CONTRATO DE
CLIENTE OPERAO
cada ocorrncia da entidade Cliente pode se relacionar com vrias

ocorrncias da entidade Contrato de Operao;
cada ocorrncia da entidade Contrato de Operao pode se relacionar com
vrias ocorrncias da entidade Cliente.
2.2.4 Generalizao/Especializao
A estrutura de especializao de entidades, na qual uma entidade (supertipo)

se subdivide em outras (subtipos), recomendada quando houver atributos ou
relacionamentos especficos para um ou outro subtipo da entidade,
observando-se que:
essa estrutura envolve o uso de uma entidade supertipo e mais de uma
subtipo;
um atributo deve tipificar a entidade supertipo;
o mesmo atributo dever ser utilizado para identificar univocamente cada
instncia das entidades supertipo e subtipos;
os atributos comuns a todas as entidades subtipo devem permanecer na
entidade supertipo;

Modelagem de Dados
cada ocorrncia de uma especializao tambm faz parte da

generalizao;
as entidades especializadas geralmente apresentam atributos e/ou
relacionamentos adicionais.
No exemplo a seguir, a estrutura de Pessoa possui os atributos e

relacionamentos genricos, ou seja, aqueles que se aplicam tanto a Pessoa
Fsica quanto a Pessoa Jurdica. O relacionamento com a entidade Endereo
de Pessoa genrico, estando, portanto, ligado ao supertipo, bem como o
atributo Nome da Pessoa. J a entidade Tipo de Pessoa define os subtipos.
Por outro lado, o relacionamento com Formao da Pessoa Fsica especfico
do subtipo Pessoa Fsica, assim como o atributo Valor da Receita Bruta
especfico de Pessoa Jurdica.
Tipo de Pessoa
Nome da Pessoa
Endereo (M)
PESSOA
Nmero do CPF Nmero do CNPJ
PESSOA PESSOA
FSICA JURDICA
(0,N)
Possui
(0,N) FORMAO
ESCOLAR
A denominao generalizao ou especializao diz respeito ao enfoque

efetuado na anlise do modelo. Numa abordagem top-down, temos a
especializao em que uma entidade supertipo se subdivide em duas ou mais
subtipos. J na abordagem bottom-up, verifica-se a generalizao em que
atributos comuns a entidades de mais baixo nvel so representados uma nica
vez na entidade de mais alto nvel. Utilizaremos o termo especializao daqui
para frente.
As especializaes podem ser categorizadas em Total ou Parcial e

Mutuamente Exclusiva ou No Mutuamente Exclusiva.
Total (T): para cada ocorrncia da entidade genrica (supertipo) existe
sempre ocorrncia em uma das entidades especializadas (subtipos);
40
Modelagem de Dados
Cdigo do Cliente
CLIENTE Nome do Cliente
CPF T CNPJ
Sexo Tipo de Organizao
PESSOA PESSOA
FSICA JURDICA
Parcial (P): nem toda ocorrncia da entidade genrica corresponde a uma

entidade especializada.
Cdigo do Funcionrio
FUNCIONRIO Nome do Funcionrio
P CRM
CREA Especialidade
ENGENHEIRO MDICO
Mutuamente exclusivas: dada uma instncia do supertipo, ela s pode

pertencer a um dos subtipos;
Cdigo da Pessoa
PESSOA Nome da Pessoa
CPF CNPJ
PESSOA PESSOA
FSICA JURDICA
No mutuamente exclusivas: dada uma instncia do supertipo, ela pode

pertencer a mais de um dos subtipos.
Cdigo da Pessoa
PESSOA Nome da Pessoa
Cdigo da Pessoa Cdigo da Pessoa

Nmero da Matrcula
CLIENTE FUNCIONRIO

Modelagem de Dados
Apesar de sua evidente utilidade, h casos em que o uso dessas estruturas

pode poluir o modelo conceitual, dificultando o entendimento do negcio.
Podemos adotar as seguintes regras prticas para definirmos se uma

especializao deve ou no ser explicitada no modelo:
caso existam atributos ou relacionamentos aplicveis somente a uma das
entidades subtipo, ento a especializao deve ser explicitada;
ainda que no se verifique a situao anterior, para que a compreenso do
modelo no dependa da anlise de documentos complementares como
dicionrio de dados ou documentos anexos, e desde que no estejamos
poluindo o modelo com detalhes desnecessrios, a especializao pode ser
explicitada;
se os identificadores das entidades supertipo e subtipos no forem os
mesmos, a especializao no deve ser utilizada;
a especializao tambm deve ser evitada quando a mesma no adicionar
clareza nem riqueza semntica ao modelo.
2.3 Tcnica de Identificao dos Objetos de Dados

Conceituais
Entender determinado problema nem sempre uma tarefa fcil, principalmente
se voc no est familiarizado com a rea de atuao de seu cliente. O
profissional de informtica precisa dominar a tecnologia e, alm disso, ter
habilidade para saber ouvir o cliente e ao mesmo tempo abstrair o que
realmente necessrio para a implementao de alguma soluo utilizando a
tecnologia disponvel.
As caractersticas de um bom modelador no esto fundamentadas na

capacidade de programao ou no domnio de um determinado SGBD, mas na
sua capacidade de pensamento abstrato, de traduo e inter-relacionamento
de mltiplos conceitos de um negcio, de comunicao clara e investigao
aguada.
Para facilitar essa tarefa de abstrao e identificao dos objetos que

comporo o modelo conceitual de dados, vamos trabalhar sobre um pequeno
roteiro e aplic-lo de imediato a um exemplo.
Primeiramente, importante frisar que todo projeto de modelagem de dados

deve comear sempre com requisitos bem descritos, que traduzam de forma
adequada as necessidades e medidas de qualidade esperadas pelo cliente.
A partir do texto descritivo desses requisitos, vamos aplicar nossa tcnica,

procurando identificar os objetos que comporo o modelo conceitual. Para isso
procuraremos por:
42
Modelagem de Dados
substantivos: designam algum (fornecedor, cliente, funcionrio, aluno);

documentos (nota fiscal, pedido, conta corrente, estoque) ou ainda coisas
(pea, produto) e representam objetos do mundo real, ainda que abstratos,
que podem vir a fazer parte do modelo conceitual. Vale ressaltar que nem
todos os objetos citados nos requisitos faro parte do modelo e, para
separ-los, podemos utilizar algumas regras simples das quais falaremos
mais adiante;
verbos e preposies: identificam o relacionamento entre as entidades, pois
demonstram as ligaes existentes entre elas. Por exemplo, quando lemos
em um texto a frase Listar Empregados por Departamento, conclumos
que a entidade Empregado tem um tipo de relacionamento que podemos
chamar de trabalha no com a entidade Departamento.
Para elaborao do modelo de dados conceitual, propomos o seguinte roteiro:

identifique todos os substantivos que designem objetos;
descarte substantivos que, mesmo com denominaes diferentes,
representem o mesmo objeto;
descarte substantivos que, como entidade, teriam apenas uma ocorrncia;
desconsidere substantivos que servem apenas para entendimento do
problema;
deixe de lado objetos que so referncia a uma futura aplicao;
descarte substantivos que, se transformados em entidade, teriam apenas
um atributo;
liste os substantivos que se tornaro entidades;
identifique os relacionamentos por meio de verbos e/ou preposies que
demonstrem relaes de dependncia ou existncia entre as entidades;
estabelea o grau de relacionamento entre as entidades;
efetue o mapeamento das cardinalidades dos relacionamentos entre as
entidades;
especifique os atributos de cada entidade.
Agora vamos aplicar o roteiro acima ao seguinte caso:
Um pequeno pas resolveu informatizar sua nica delegacia de polcia para

criar um banco de dados onde criminosos sero fichados, as vtimas tambm
sero cadastradas e todas as armas apreendidas com os criminosos devero
ser fichadas para que no sejam reutilizadas. Mesmo as chamadas armas
brancas tais como facas, porretes, etc., recebero um nmero de identificao.
As armas, quando for o caso, ficaro relacionadas ao crime cometido para
possvel utilizao no julgamento do criminoso. O banco de dados alm de
fornecer dados pessoais de criminosos, de vitimas e de armas, tambm deve
possibilitar saber quais crimes determinado criminoso cometeu, que crimes

Modelagem de Dados
determinada vtima sofreu e quais criminosos a atacaram em cada crime.

Mensalmente sero emitidos relatrios e estatsticas de acordo com a
solicitao do chefe da delegacia. Todo registro de crime dever ter o visto do
chefe da delegacia.
Roteiro:
identificar todos os substantivos que designem objetos:
leia o texto e grife todos os substantivos que designem objetos do
mundo real, concretos ou no tais como pessoas, coisas, documentos,
controles, sistemas, etc.;
considere o substantivo apenas uma vez, mesmo que ele aparea
vrias vezes no texto. Elimine tambm aqueles substantivos que,
mesmo com denominaes diferentes, representem o mesmo objeto;
faa uma lista dos objetos grifados, pois ser atravs deles que sero
identificadas as entidades que faro parte do modelo conceitual.
Resultado: pas, habitante, crime, delegacia de polcia, banco de dados,
criminoso, vitima, arma, relatrio, chefe da delegacia, visto do chefe,
julgamento, numero de identificao e banco de dados.
Obs: registro de crime no foi listado, pois equivalente a crime.
descartar substantivos que como entidade teriam apenas uma ocorrncia:
faa a pergunta: se esse substantivo for transformado em entidade,
ser um conjunto de apenas uma ocorrncia?. Se a resposta for "sim",
descarte este substantivo.
Resultado: descarte de delegacia de polcia.
descartar substantivos que servem apenas para entendimento do
problema:
faa a pergunta: preciso guardar informaes sobre este objeto? Se a
resposta for "no", descarte este substantivo.
Resultado: descarte do banco de dados, pas, chefe da delegacia.
descartar objetos que so referncia a uma futura aplicao:
no modelo conceitual no deve haver preocupaes com os programas
que acessaro ou manipularo os dados. Assim, citaes a telas,
relatrios, estatsticas, clculos e tudo aquilo que signifique
manipulao dos dados no deve ser considerado entidade.
Resultado: descarte de relatrio e estatsticas.
descartar substantivos que se transformados em entidade teriam apenas
um atributo:
faa a pergunta: quantos atributos tem esta entidade? Se a resposta
for apenas um, verifique a qual outra entidade esse atributo dever
pertencer.
Resultado: descarte de visto do chefe, numero de identificao.
44
Modelagem de Dados
Obs: este substantivo na realidade dever ser um atributo de uma

possvel entidade crime, mas no uma entidade independente.
listar os substantivos que se tornaro entidades:
depois destas etapas, temos a lista de substantivos que se tornaro as
entidades do nosso modelo conceitual.
Resultado: crime, criminoso, vtima, arma.
identificar os relacionamentos por meio de verbos ou preposies que
demonstrem relaes de dependncia ou existncia entre as entidades:
normalmente, no prprio texto identificamos as relaes de
dependncia ou existncia entre as entidades atravs de verbos ou
preposies. Algumas poucas vezes essas relaes esto ocultas e
precisaremos fazer uma anlise mais apurada do texto, porm isso no
a regra.
Resultado: arma usada crime, criminoso comete crime, criminoso ataca
vtima, vtima sofre crime.
estabelecer o tipo de relacionamento (grau) entre as entidades:
o grau de relacionamento entre entidades demonstra o tipo de ligao
entre elas;
nesse momento definiremos se o relacionamento entre entidades ser
binrio, n-rio ou ainda se existe um autorrelacionamento.
Resultado:
Modelo conceitual demonstrando os relacionamentos entre as Entidades

Modelagem de Dados
efetuar o mapeamento das cardinalidades dos relacionamentos entre as

entidades e definir as cardinalidades mxima e mnima;
Sugerimos visualizar sempre os dois lados do relacionamento. Exemplo: se
observarmos que um criminoso ataca muitas vtimas, tambm devemos
observar que uma vtima pode ser atacada por muitos criminosos.
Vamos destacar esta anlise entre criminosos e vtimas organizando-a da
seguinte forma:
(Um Criminoso ATACA Muitas Vtimas).
Um determinado Criminoso pode atacar mais de uma Vtima?
Sim, ento cardinalidade mxima = N.
Um determinado Criminoso sempre tem que atacar alguma Vtima?
No, ento cardinalidade mnima = 0.
Passamos a seguir para o outro lado do relacionamento e encontramos:
(Uma Vtima pode ser ATACADA por Muitos Criminosos).
Uma determinada Vtima pode ser atacada por mais de um Criminoso?
Sim, ento cardinalidade mxima = N.
Uma determinada Vtima sempre atacada por algum Criminoso?
Sim, ento cardinalidade mnima = 1.
Consideramos ento s as duas ltimas palavras das duas frases e
encontramos:
Muitas Vtimas - Muitos Criminosos.
A seguir temos a anlise completa do nosso problema exemplo:
Uma Arma PODE SER USADA em Muitos Crimes;
Um Crime PODE TER Muitas Armas.
Ento: Muitos Crimes Muitas Armas.
Um Criminoso PODE COMETER Muitos Crimes
Um Crime PODE SER COMETIDO POR Muitos Criminosos
Ento: Muitos Criminosos Muitos Crimes
Um Criminoso ATACA Muitas Vtimas
Uma Vtima PODE SER ATACADA POR Muitos Criminosos
Ento: Muitos Criminosos Muitas Vtimas
Uma Vtima PODE SOFRER Muitos Crimes
Um Crime PODE TER Muitas Vtimas
Ento: Muitos Crimes Muitas Vtimas
46
Modelagem de Dados
Resultado:
Modelo conceitual incorporando a cardinalidade entre as entidades
identificar os atributos de cada entidade:

Todo objeto tem suas propriedades (atributos) e h a necessidade de
considerar aquelas mais importantes na definio do modelo conceitual.
Propriedades equivalem a caractersticas do objeto. Assim:
o Criminoso:
rg_criminoso,
nome_criminoso,
endereo_criminoso.
o Vitima:
rg_vitima,
nome_vitima,
endereo_vitima.
o Crime:
nmero_bo,

Modelagem de Dados
descrio_crime,
local_crime,
data_crime,
visto_chefe.
o Arma:
nmero_arma,
descrio_arma.
Resultado:
nome_criminoso nome_vtima
endereo_criminoso endereo_vtima
rg_criminoso rg_vtima
M N
CRIMINOSO Ataca VTIMA
M M
nmero BO
data_crime
local_crime
N N
Comete CRIME Sofre
N descrio_crime
visto_chefe
Usada
nmero_arma
descrio_arma
M
ARMA
Modelo conceitual final contendo os atributos de cada entidade
2.4 Situaes em Modelagem de Dados que indicam a

ocorrncia de erros
definio de entidade qual podem ser atribudos dois ou mais conceitos;

definio desnecessria de relacionamentos;
uso inadequado da especializao;
atributo de relacionamento indevidamente atribudo a uma entidade.
48
Modelagem de Dados
3. MODELAGEM DE DADOS LGICA
3.1 Disposies Gerais

O Modelo de Dados Lgico (MDL) o retrato de todas as informaes
necessrias para a realizao dos negcios. Alm de propiciar uma viso mais
detalhada do que o Modelo de Dados Conceitual, ele tambm prov uma viso
mais prxima da implementao em banco de dados, de acordo com regras de
implementao e limitantes impostos por algum tipo de tecnologia, porm
parte de qualquer exigncia dos dispositivos de armazenamento de dados;
altamente recomendvel que o MDL seja obtido por derivao do Modelo de

Dados Conceitual. Como dito anteriormente, o foco do curso ser dado ao
Modelo Relacional, por ser uma tcnica de modelagem amplamente utilizada e
adotada como padro no Banco do Brasil. O Modelo Relacional uma potente
ferramenta de comunicao entre os profissionais do negcio e os
desenvolvedores. Ele representa a diagramao dos dados necessrios para
as regras de negcio.
A notao adotada ser a da engenharia da informao, implementada pela

ferramenta de modelagem de dados adotada pelo Banco.
Aspectos da notao I.E.

Modelagem de Dados
3.2 Caractersticas do Modelo de Dados Lgico

O Modelo de Dados Lgico deve:
resultar da aplicao de regras de derivao sobre um Modelo de Dados
Conceitual, visando representao do negcio;
conter entidades, atributos e respectivas descries, assim como
relacionamentos, que representem o negcio a ser modelado;
representar cada entidade somente uma vez, evitando entidades
redundantes, ainda que com nomes diferentes;
representar relacionamentos n:m por meio de entidades associativas;
representar as chaves primrias das entidades;
representar o negcio e no a base de dados desejada, a qual ser
projetada posteriormente, por ocasio da elaborao do Modelo de Dados
Fsico;
ser normalizado at a Terceira Forma Normal;
adequar-se aos padres de notao e nomenclatura;
descrever as restries de integridade.
O MDL no deve conter entidades que representem tabelas que sejam tpicas
apenas do Modelo Fsico (Lderes, Parmetros, Logs, Histricos), bem como
entidades derivadas (Totalizaes ou Estatsticas), visto que tais objetos no
representam aspectos negociais.
3.3 Objetos do Modelo de Dados Lgico

Assim como no Modelo de Dados Conceitual, os objetos do Modelo de Dados
Lgico tambm so entidades, atributos e relacionamentos. Porm, o nvel de
abstrao adotado determinar diferenas relevantes. Com a necessidade de
um detalhamento maior, outras entidades podero surgir. Conforme a notao
utilizada, a representao desses objetos no MDL poder ser diferente do
MDC.
3.3.1 Entidade
A notao de uma entidade no MDL um retngulo.
Convenes para a representao da entidade:

box de qualquer tamanho;
o nome da entidade deve ser singular e nico;
nome da entidade no topo do retngulo;
os nomes dos atributos logo abaixo, dentro do retngulo.
50
Modelagem de Dados
MOEDA
CDIGO DA MOEDA
NOME DA MOEDA
SMBOLO DA MOEDA
CDIGO DO PAIS EMISSOR DA MOEDA (FK)
CDIGO DA MOEDA NO BANCO CENTRAL DO BRASIL
Exemplo de entidade e seus atributos
As regras de nomenclatura de entidades, mencionadas anteriormente para o

MDC, continuam valendo para o MDL.
Cada ocorrncia da entidade uma instncia da entidade, ou seja, Joo uma
instncia da entidade PESSOA, assim como Maria outra instncia.
Fisicamente, as instncias para Joo e Maria sero denominadas registros,
linhas ou tuplas.
PESSOA
Cdigo Nome
37 Joo
245 Maria
Tipos de Entidade
Entidade Forte: em uma entidade forte, as ocorrncias existem

independentemente de haver ocorrncias em outras entidades.
Entidade Fraca ou Subordinada: uma entidade fraca uma entidade cuja

existncia depende de outra entidade. Este tipo de entidade no pode existir se
no estiver relacionada a outra entidade.
Um bom exemplo de entidade fraca MODALIDADE DO PRODUTO, cujas

instncias dependem da existncia prvia de instncias correspondentes na
entidade forte PRODUTO. Outro exemplo de entidade fraca UNIDADE DA
FEDERAO em relao entidade PAS.

Modelagem de Dados
3.3.2 Atributo
No MDL, no deve haver replicao de atributos, ou seja, o atributo somente

deve ser representado na entidade qual ele pertena. Da mesma forma,
tambm no sero representados atributos derivados de outros atributos, tais
como totais ou percentuais, ou atributos repetitivos, como TELEFONE-1 e
TELEFONE-2.
Tambm possvel que o que, inicialmente, parea um atributo seja, na
verdade, uma entidade ( o caso do atributo TELEFONE do pargrafo anterior).
Outro exemplo: a entidade PESSOA pode apresentar um atributo chamado

Endereo, mas na realidade este atributo uma entidade com seus prprios
atributos (Texto do Endereo, CEP, UF).
Esse assunto ser retomado no captulo NORMALIZAO.
Um atributo pode ser classificado como:

obrigatrio ou opcional;
identificador ou no identificador;
fruto de um relacionamento ou autctone.
Um atributo obrigatrio aquele para o qual deve existir um valor vlido, no

nulo, em cada instncia da entidade. J para o atributo opcional tal
obrigatoriedade no observada.
O atributo, ou grupo de atributos, identificadores so aqueles capazes de

identificar unvoca e inequivocamente cada ocorrncia de uma entidade e no
podem conter valores nulos.
52
Modelagem de Dados
Nesta apostila, os atributos identificadores so indicados pelos smbolos # ou

, seguindo a notao da ferramenta de modelagem de dados adotada pelo
BB, o Erwin (da qual falaremos adiante), e separados dos demais atributos por
uma linha horizontal.
O atributo, ou grupo de atributos, identificador tambm chamado de chave

primria, primary key ou PK.
O atributo, ou grupo de atributos, fruto de um relacionamento aquele que

aparece na entidade como herana de outra entidade por causa de um
relacionamento entre as duas. O atributo autctone aquele que pertence
entidade onde foi definido.
Em uma entidade fraca sempre teremos como atributo obrigatrio os atributos

que fizerem parte da chave da entidade forte. A razo para isso que uma
instncia da entidade dependente no existe sem existir previamente a
instncia correspondente na entidade de origem.
Na definio do nome do atributo, tambm devemos seguir as mesmas regras

citadas no captulo referente a Modelo de Dados Conceitual.
3.3.3 Chaves
Chave Candidata
o atributo ou grupamento de atributos que tem a propriedade de identificar

unicamente uma ocorrncia da entidade. Uma Chave Candidata pode se tornar
a Chave Primria.
Chave Primria (Primary Key - PK)
Define-se como Chave Primria o atributo, ou conjunto de atributos, que

identifica, de forma unvoca, uma instncia da entidade.
O princpio da minimalidade prescreve que a chave primria de uma entidade

deve ser composta por um conjunto mnimo de atributos necessrios
identificao unvoca de uma instncia da entidade.
A chave primria pode ser natural ou artificial. Uma chave primria natural
formada por um ou mais atributos que fazem parte do negcio que est sendo
modelado. Por outro lado, uma chave primria artificial composta por um
atributo que no representa nenhuma propriedade do negcio, geralmente um
nmero seqencial criado unicamente com a finalidade de identificar a
instncia da entidade.
Seguindo-se o princpio da minimalidade, o recurso de chave primria artificial

usado, tambm, quando o conjunto de atributos naturais se mostra
excessivamente grande.

Modelagem de Dados
Exemplos:
Nmero do chassi (VECULO) um exemplo de identificador natural.
Cdigo do Cliente (CLIENTE) e Cdigo do Produto (PRODUTO) so
exemplos de identificadores artificiais.
PESSOA PESSOA
Nome da Pessoa Cdigo da Pessoa
Data de Nascimento Nome da Pessoa
Nmero do CPF Data de Nascimento
Nmero do RG Nmero do CPF
Nmero do RG
Chave Natural
Chave Artificial
Chave Estrangeira (Foreign Key - FK)
Define-se como Chave Estrangeira o atributo, ou conjunto de atributos, de uma

entidade que herdado de outra entidade em virtude do relacionamento
existente entre elas. A chave estrangeira, tambm conhecida por foreign key,
sempre a chave primria da entidade de origem do relacionamento. Nesta
apostila, os atributos que definem chaves estrangeiras sero identificados pelo
smbolo (FK).
3.3.4 Relacionamentos
Alm de tudo o que foi dito sobre relacionamentos no captulo referente a

Modelagem de Dados Conceitual, acrescentaremos mais algumas informaes
referentes ao Modelo de Dados Lgico ou maneira como suas estruturas
devem ser representadas.
Denominao dos Relacionamentos no MDL
No processo de reconhecimento e identificao dos relacionamentos existentes

entre entidades, devemos buscar uma denominao que represente o conceito
observado. O nome do relacionamento recomendvel, principalmente, nas
seguintes situaes:
por questo de clareza, evitando ambiguidade;
no caso de autorrelacionamento (relacionamento recursivo);
caso ocorra mais de um relacionamento entre o par de entidades.
54
Modelagem de Dados
Localiza Lota
/ Est localizado / Est Lotado
Os atributos migrados para a entidade de destino devero receber nomes

diferenciados (rolename).
Os relacionamentos podero ser de dois tipos:

relacionamentos identificadores, nos quais os atributos que migraro de
uma entidade para a outra faro parte da chave primria da entidade de
destino do relacionamento. Sero representados por uma linha cheia no
modelo de dados.
relacionamentos no identificadores, nos quais os atributos que migraro

de uma entidade para a outra no faro parte da chave primria da
entidade de destino do relacionamento. Sero representados por uma linha
tracejada no modelo de dados.

Modelagem de Dados
Relacionamento n:m
As associaes ou relacionamentos do tipo n:m (muitos para muitos) no

Modelo de Dados Conceitual sero representados, no Modelo de Dados
Lgico, como entidades conhecidas como associativas.
Uma entidade associativa aquela cuja existncia est condicionada

existncia de duas ou mais entidades a partir das quais ela concebida. Surge
no momento da derivao do modelo lgico a partir do modelo conceitual.
Relacionamento Ternrio, Quaternrio ou N-rio
Embora a maioria dos relacionamentos ocorra entre duas entidades

(relacionamentos binrios), podemos definir relacionamentos entre qualquer
nmero de entidades. A ocorrncia de relacionamentos ternrios, quaternrios
ou n-rios, muitas vezes, exige a presena de uma estrutura adicional
56
Modelagem de Dados
conhecida como AGREGAO. A entidade originada de uma agregao pode

tambm ser definida como uma entidade associativa.
Neste exemplo possvel demonstrar a utilizao de um relacionamento

ternrio. Para que ocorra a Alocao do Funcionrio, necessrio que esteja
disponvel uma vaga para determinada funo no Projeto e que exista um
funcionrio com a funo desejada para esse Projeto.
Se o relacionamento que ocorrer no for ternrio, poder haver uma

inconsistncia.
Podemos, por outro lado, representar esta realidade fazendo associaes entre
essas entidades 2 a 2 (FUNCIONRIO PROJETO e PROJETO FUNO).
Desta forma, podemos identificar em quais projetos um funcionrio est
trabalhando. Sabemos tambm que nesses projetos existem algumas funes.
Porm, para termos uma viso de quais funes so desempenhadas por cada
funcionrio, deve-se efetuar o relacionamento entre as duas associativas que
surgem neste tipo de estrutura relacional e que dar origem entidade que
representa a FUNO DO FUNCIONRIO NO PROJETO.

Modelagem de Dados
Como regra geral, deve-se criar um relacionamento ternrio apenas quando

no for possvel representar a regra de negcio em um ou mais
relacionamentos binrios.
Autorrelacionamento (Relacionamento Recursivo)
O autorrelacionamento acontece entre ocorrncias da mesma entidade. Nestes

casos, para facilitar o entendimento, em geral costumamos identificar o papel
de cada entidade no relacionamento (no exemplo abaixo, pessoa e cnjuge).
Autorrelacionamento 1 para 1:
Autorrelacionamento 1 para N:
58
Modelagem de Dados
Autorrelacionamento N para M:
Na ocorrncia de autorrelacionamentos N para M, ser necessrio criar uma

nova entidade, uma vez que o relacionamento vai se transformar em uma
entidade associativa.
3.3.5 Supertipo / Subtipo (Generalizao / Especializao)
Expressam a existncia de subconjuntos de instncias de uma Entidade com

atributos e/ou relacionamentos especficos.
Na ocorrncia de uma especializao, a chave do Subtipo sempre a mesma

do Supertipo, pois o Subtipo um subconjunto do Supertipo.
No Supertipo importante identificar um atributo que faa a tipificao.

A classificao da instncia do supertipo, atravs do atributo de tipificao,
elimina a necessidade de fazer leitura em todas as instncias de todos os
subtipos para descobrir qual o subconjunto da instncia.
O Subtipo pode ser:

Inclusivo: quando o Supertipo permite mais de uma ocorrncia de Subtipo
Exclusivo: quando o Supertipo permite apenas uma ocorrncia de Subtipo
Deve-se utilizar a Generalizao/Especializao quando:

houver atributo aplicvel apenas a um subconjunto da Entidade;
houver relacionamento aplicvel apenas a um subconjunto da Entidade.

Modelagem de Dados
3.4 Deslocamento da Chave Estrangeira

A chave estrangeira, num relacionamento 1 para N, sempre se desloca no
sentido 1 para N, independentemente da opcionalidade.
Quando o relacionamento entre as entidades 1 para 1, a chave estrangeira

desloca-se sempre da entidade obrigatria em direo entidade opcional.
60
Modelagem de Dados
Caso as duas entidades sejam opcionais e tenham relacionamento 1 para 1,

pode-se optar (mas normalmente existe um lado melhor).
A opo acima a melhor, j que podemos garantir que quase todos os pases
possuem capital. Outra alternativa seria:
Nesse caso, poucas cidades do mundo teriam o campo CDIGO DO PAS

preenchido, pois poucas cidades so capitais de um pas.
Obs.: Entre PAS e CIDADE pode existir mais de um relacionamento.

Modelagem de Dados
3.5 Convenes Posicionais em Modelos de Dados

Um assunto ao qual, frequentemente, se dispensa pouca importncia, e, por
vezes, passa despercebido em tcnicas e padronizaes de modelagem de
dados a disposio ou distribuio ordenada dos objetos no modelo. Assunto
este que pode contribuir profundamente para o entendimento do modelo e a
comunicao entre os usurios.
Quando da elaborao dos modelos de dados, o posicionamento das entidades

e de seus relacionamentos obedecer aos seguintes padres:
deve-se adotar uma das convenes de posicionamento de objetos,
conforme descrito no pargrafo seguinte;
as linhas que representam os relacionamentos entre entidades devem, na
medida do possvel, ser retas, evitando os "cotovelos";
deve-se evitar o cruzamento dessas linhas, mas no em detrimento s
regras anteriores.
A fim de implementar uma melhor visualizao do negcio e das estruturas

representados nos modelos de dados, as entidades devem ser exclusivamente
dispostas de acordo com um dos padres a seguir:
62
Modelagem de Dados
Relacionamentos sempre apontando para a parte superior e para a esquerda

do diagrama, e atingindo as entidades de destino pela direita ou pela parte
inferior.
3.6 Derivao do Modelo Lgico a partir do Modelo

Conceitual
Esta seo apresenta, em linhas gerais, as regras mais comuns e elementares
de mapeamento do Modelo de Dados Conceitual para o Modelo de Dados
Lgico.
1. Entidades: o principal consenso que entidades do MER tornam-se

relaes do modelo relacional. Tal regra apresenta duas excees
(entidades fracas e hierarquias de generalizao), as quais sero tratadas

Modelagem de Dados
mais adiante. Atributos monovalorados transformam-se em atributos das

relaes. Atributos multivalorados sero vistos mais adiante. Os nomes das
entidades e de seus atributos devem ser preservados nessa transformao
assim como as restries de integridade em nvel de entidade e de atributo.
2. Definio de Identificadores: Identificar as chaves primrias das entidades

para garantir que cada uma de suas instncias seja nica. Isso deve ser
feito para todas as entidades e relacionamentos com atributos.
3. Atributos Compostos: para a derivao de atributos compostos, trs opes

esto disponveis:
a) implementar somente os elementares e desprezar o agregador;
b) implementar somente o agregador como um atributo elementar;
c) implementar o atributo como uma entidade.
Observamos que as propostas de derivao dos itens a e b causariam
uma desnormalizao e devem ser utilizadas em situaes em que, aps
anlise, a implementao do item c no seja possvel.
4. Atributos Multivalorados: para derivar atributos multivalorados, considere as

seguintes alternativas:
a) transformar o atributo multivalorado em um conjunto de atributos
atmicos;
b) implementar o atributo como uma entidade.
Observamos que a proposta de derivao do item a causaria uma
desnormalizao e deve ser utilizada em situaes em que, aps anlise, a
implementao do item b no seja possvel.
5. Hierarquias Generalizao / Especializao:

a) implementar apenas a generalizao, incluindo as propriedades das
especializaes nela e, eventualmente, um novo atributo que defina seu
tipo;
b) implementar cada entidade como uma relao;
c) implementar somente as especializaes e criar uma relao para a
generalizao se a hierarquia for parcial.
Observamos que, apesar das possibilidades de implementao de
generalizao/especializao apresentadas, quando a especializao existe
64
Modelagem de Dados
no modelo conceitual por representar as regras de negcio, importante

que no modelo de dados lgico essa especializao seja representada da
mesma forma, podendo ser implementada de forma diferente no modelo de
dados fsico.
6. Relacionamentos com Atributos (Entidades Associativas): so

transformados em relaes com associaes de
composio/relacionamentos identificadores para manter os vnculos
originais.
7. Associaes de Composio/Relacionamentos Identificadores (ou

derivao de entidades fracas): so sempre associaes/relacionamentos
com cardinalidades 1-1 ou 1-N. As entidades fracas so transformadas em
relaes, sendo que todos os seus atributos se transformam em atributos
da relao e o identificador da entidade fraca (formado pelo identificador da
entidade forte e um ou mais dos seus atributos) em chave-primria da
relao. O nome da entidade "fraca" e de seus atributos devem ser
preservados nessa transformao, assim como as restries de integridade
da entidade e seus atributos.
8. Associaes, Agregaes e Relacionamentos (regra geral): criao de

relao prpria, capturando as chaves primrias das relaes associadas e
mantendo a integridade referencial com as mesmas; eventualmente,
atributos do relacionamento que faam parte de sua identificao passam a
fazer parte de sua chave primria. Importante: relacionamentos com
atributos que faam parte da identificao so sempre mapeados para
relao prpria.
9. Associaes, Agregaes e Relacionamentos (casos especiais):

a) associaes (relacionamentos) com cardinalidades 1-N podem ser
implementados adicionando a chave primria do lado 1 no lado N, e
mantendo a integridade referencial;

Modelagem de Dados
b) associaes (relacionamentos) com cardinalidades 1-1 podem permitir

a fuso das entidades relacionadas. Se for possvel, definir uma chave
primria para a relao resultante a partir dos atributos das entidades
originais.
10. Relacionamentos Recursivos (Autorrelacionamentos): se um
relacionamento recursivo apresentar cardinalidades M-N, devemos criar
uma nova entidade que servir de associativa para transformar esse
relacionamento em dois relacionamentos 1-N. Se o relacionamento original
for 1-N, ento a chave primria da entidade ser exportada para si prpria,
formando uma chave estrangeira no pertencente chave primria da
entidade.
Ao derivar o MDL a partir do MDC, devemos ter as seguintes preocupaes:

evitar campos opcionais, visando representar as regras de negcio de
forma mais consistente;
implementao eficiente de chaves primrias, seguindo o princpio da
minimalidade.
3.7 Situaes em Modelagem de Dados que indicam a

ocorrncia de erros
redundncia de dados: segundo Kipper, uma informao registrada em dois

lugares so duas informaes;
decises de modelagem considerando-se apenas problemas de
implementao;
entidades que "sobram" no modelo, sem nenhum relacionamento: uma
entidade que se encontre isolada no MDC ou no MDL, em regra, no
representa um aspecto negocial, mas um aspecto de implementao do
aplicativo que trata desse negcio e, portanto, deve constar apenas do
MDF;
ocorrncia de ciclos fechados" de relacionamentos: por exemplo, Usurio
relaciona-se com Emprstimo que se relaciona com Livro que se relaciona
com Usurio que se relaciona com Emprstimo;
USURIO EMPRSTIMO
Cdigo do Usurio Cdigo do Emprstimo
Cgido do Livro (FK) Cdigo do Usurio (FK)
LIVRO
Cgido do Livro
Cdigo do Emprstimo (FK)
66
Modelagem de Dados
A identificao incompleta de entidades, como entidades sem atributos,

entidades com grande quantidade de atributos ou com atributos somente do
tipo CDIGO, so situaes que podem indicar ocorrncia de erros.
3.8 Normalizao
A normalizao dos dados um processo no qual os atributos de um modelo
de dados so organizados para aumentar a coeso entre as entidades. Em
outras palavras, o objetivo da normalizao reduzir e at mesmo evitar a
redundncia dos dados, um ponto que merece considerao especial por parte
dos desenvolvedores de aplicaes, devido incrvel dificuldade em armazenar
objetos em um banco de dados relacional que mantm a mesma informao
em diferentes lugares.
A normalizao prope um conjunto de regras que visa minimizar as anomalias

de modificao dos dados, dar maior flexibilidade sua utilizao, reduzir a
dependncia funcional entre os atributos de uma entidade e garantir a
integridade e confiabilidade das informaes, alm de potencializar a
estabilidade do modelo lgico relacional, ao aumentar a capacidade de um
modelo se manter inalterado em face a mudanas que venham a ser
percebidas ou introduzidas no ambiente que tenha sido modelado.
Por que Normalizar?
A transformao direta do MER (Modelo Entidade e Relacionamento) para um

modelo relacional pode levar, em alguns casos, a relaes imperfeitas,
chamadas ANOMALIAS DE MODIFICAES. Desta forma, as anomalias
foram estudadas e teoremas foram criados a fim de resolv-las, dando como
resultado a Normalizao das relaes.
3.8.1 Normalizao at a 3 FORMA NORMAL
1 FORMA NORMAL (1 FN)
A primeira forma normal enuncia que cada atributo de uma entidade pode
armazenar apenas um valor. Relaes com atributos multivalorados no so
consideradas em 1 FN.
Uma soluo para atributos que necessitem de valores mltiplos defini-los em

entidades diferentes, associando-as com a chave primria da entidade de
origem.
Alm disso, a primeira forma normal no admite que a relao contenha

informaes repetitivas. Tais dados tambm devero ser migrados para
relaes diferentes que herdaro a chave primria da relao de origem,
atravs do relacionamento definido entre elas.

Modelagem de Dados
Ex. E (#A, B, C, (D1, D2, D3), G, H); onde (D1, D2, D3) so grupos de
repetio.
Entendemos, ento, que a entidade E no est normalizada.
Anomalias do exemplo dado:

a incluso de mais de trs endereos implica um novo cadastro de pessoa;
a excluso de endereo acarreta a excluso de Pessoa;
qualquer atualizao em endereo deve ser feita pesquisando vrias linhas
da relao.
Para ficar na 1 FN necessrio que se faa o desmembramento das relaes

em uma ou mais relaes sem grupos de repetio:
E (#A, B, C, G, H);
E1 (#A, #N, D), onde N um novo campo, normalmente um sequencial,

utilizado para no repetir a chave primria.
Uma relao est na 2 FN se estiver na 1 FN e se todos os atributos que no

compem sua chave primria so dependentes de toda a chave primria e no
de apenas parte dela, ou seja, no h dependncia parcial em relao chave
primria.
Ex. E (#A, #B, C, D, (E, F)); onde C e D dependem de A e B, enquanto E e F

dependem apenas de A
Conclumos, tambm, que a entidade E no est normalizada.
68
Modelagem de Dados
Anomalias do exemplo dado:

no se poder incluir um valor de Receita Anual Bruta sem que haja uma
associao de Pessoa Fsica com Pessoa Jurdica;
a excluso de valor da Receita Anual Bruta implicaria a excluso da
associao entre Pessoa Fsica e Pessoa Jurdica.
Para ficar na 2 FN necessrio que se faa o desmembramento de modo que

no haja atributo dependente de apenas parte da chave:
E (#A, #B, C, D);
E1 (#A, E, F);

Modelagem de Dados
Uma relao est na 3 FN se estiver na 2 FN e se todos os atributos no

identificadores forem independentes entre si, ou seja, no h dependncia
transitiva.
Ex. E (#A, B, C, (D), E, (F))
D, F so atributos no chave que dependem de C.
Aqui, tambm, a entidade E no est normalizada.
70
Modelagem de Dados
Para ficar na 3 FN necessrio que se faa o desmembramento das relaes,

de modo que todos os atributos no chave sejam dependentes exclusivamente
da chave:
E (#A, B, C, E);
E1 (#C, D, F);
Resumindo:
3.8.2 Outras Formas Normais
Adicionalmente, outras formas normais foram definidas, mas geralmente so

menos utilizadas. Entre estas avanadas formas normais esto includas a
Forma Normal de Boyce / Codd (BCNF), Forma Normal de Chave Elementar
(EKNF), Quarta Forma Normal (4NF) e Quinta Forma Normal (5NF). Na prtica,
usa-se a normalizao at a 3 FN.
3.9 Restrio de Integridade

As regras de restrio de integridade foram criadas para garantir a
consistncia, a identificao e o acesso a todos os dados sem ambiguidade.
As restries de integridade mais frequentemente encontradas so as

restries de integridade definidas em relao aos atributos, aquelas definidas
em relao entidade e as definidas em relao aos relacionamentos entre as
entidades.
As restries de integridade bsicas so:

restrio de domnio: especifica que, para um certo atributo A de uma
entidade, todo valor associado a A deve ser atmico e pertencente ao
domnio deste atributo;

Modelagem de Dados
restrio de nulo: define se ser possvel a atribuio de nulo para um

determinado atributo;
restrio de integridade de chave primria: especifica que no pode haver
dois registros na entidade com a mesma chave primria;
restrio de integridade de entidade: especifica que nenhum dos atributos
que formam sua chave primria pode possuir valor nulo;
restrio de integridade referencial: especifica que um valor de chave
estrangeira de uma entidade sempre aponta para um valor vlido de chave
primria previamente definida para outra entidade.
3.10 Validao do Modelo de Dados Lgico

A reviso do Modelo de Dados Lgico, resultante da derivao do Modelo de
Dados Conceitual, realizada para verificar se a soluo est coerente e se
no ocorreu uma fatorao excessiva das entidades em um nmero grande de
relaes. Isso pode influenciar no desempenho da aplicao, dependendo das
populaes esperadas das relaes e dos tipos de acesso e de atualizao
que elas tero. O uso do bom senso recomendvel e bem-vindo!
A aprovao do MDL pelos gestores e usurios tambm necessria, visto

que os modelos (MDC e MDL) so a base para tudo que for construdo no
projeto. Uma correo nos modelos, nesta altura, implica custos menores que
nas fases seguintes e os intervenientes devem estar conscientes do seu papel
e da importncia dessa validao.
Neste momento, a verificao do MDL dever encaminhar as seguintes

questes:
verificar a completeza do modelo, ou seja, garantir que os dados
contemplados no modelo representam, de forma consistente, todas as
regras do negcio e que respondem a todas as necessidades elencadas
pelos usurios;
confirmar as cardinalidades que no so evidentes, principalmente as
mnimas;
confirmar as chaves primrias e os conceitos das entidades;
confirmar os relacionamentos prprios das generalizaes e
especializaes de entidades.
Em seguida, o Modelo de Dados Lgico dever ser apresentado para validao

pela Gerncia de Arquitetura de Informaes. Para isso, o MDL deve atender
s seguintes premissas:
estar normalizado at a 3 Forma Normal;
ser elaborado com o auxlio da ferramenta CASE (Computer-Aided
Software Engineering) adotada pelo BB (atualmente, o ERwin);
72
Modelagem de Dados
o modelo deve atender conveno posicional j apresentada;

representar fielmente o negcio e no a base de dados desejada, que ser
construda posteriormente, com o suporte do DBA (Database
Administrator), por ocasio da construo do Modelo de Dados Fsico;
conter a descrio suficiente das entidades, atributos;
conter os nomes de entidades e atributos, extensos e abreviados,
atribudos de acordo com os padres de nomenclatura adotados e
formados por termos existentes no Glossrio de Termos da Arquitetura de
Informaes, seguindo os preceitos do LIC 139.03.51.01;
seguir o padro de cores de objetos determinado na "Conveno de Cores
para Objetos de Modelos de Dados", segundo LIC 139.03.51.01;
contemplar, para cada um dos atributos, o tipo de dado, tamanho e
opcionalidade, seguindo os padres adotados pelo BB (LIC 139.03.51.01 ).
3.11 Padres de Modelagem no BB

No BB, a Gerncia de Arquitetura de Informaes (GEARQ) responsvel pelo
suporte e apoio na elaborao de Modelos de Dados, alm de definir diretrizes
e orientaes que subsidiem a construo desses modelos. Para auxiliar na
execuo dessas tarefas, foram adotados, alm das tcnicas sobre as quais
discorremos neste curso, regras e padres, que esto disponveis, com muito
mais detalhes, na Intranet (no stio da Arquitetura de Informaes) e nos Livros
de Instruo Codificada (LIC 139-3). Esses padres e regras dizem respeito
formao dos nomes, cores e posicionamento dos objetos no modelo de
dados.
3.11.1 Padronizao de Nomes
Por que padronizar?
Os nomes padronizados abrangem aqueles aplicveis a dados de sistemas

(fsicos) e de modelos (conceituais e lgicos). Nesse escopo, imperativo que
um termo possa identificar um (e apenas um) contedo de forma consistente e
que regras sejam utilizadas para a construo desses nomes de forma a evitar
interpretaes dbias. uma escolha inteligente adotar um sistema de
classificao que possibilite o armazenamento e recuperao desses termos e
seus contedos. A vantagem que, uma vez que regras formais e nomes
possam ser armazenados e consultados em um repositrio central, ou at
mesmo aprendidos, os contedos sero descritos de maneira consistente para
todos aqueles que utilizarem o sistema.
Objetivos da Padronizao
Simplificao: reduo da crescente variedade de entendimentos de conceitos.

Modelagem de Dados
Comunicao: proporcionar meios eficientes para troca de informaes de

maneira confivel.
Qualidade: a padronizao traz a possibilidade de se aferir a qualidade da
informao.
Eliminao das barreiras de entendimento: evita a existncia de conceitos
conflitantes sobre a mesma informao entre as diferentes reas, facilitando
assim o intercmbio entre elas.
3.12 Glossrio da Tecnologia ou Glossrio de Termos
O Glossrio de Termos um catlogo que contm as palavras a serem

utilizadas para dar nomes aos objetos de dados no ambiente da Tecnologia do
Banco do Brasil. Essa ferramenta contempla palavras, suas abreviaturas,
descries e remisses para o uso de sinnimos.
Os objetos de dados so todos os objetos que visam armazenar informaes

para efeito de utilizao futura, enquadrando-se como tais as entidades e seus
atributos, os arquivos e seus campos, as tabelas e suas respectivas colunas.
O Glossrio da Tecnologia pode ser consultado no SISBB no Sitio da

Arquitetura da Informao e no Conversor.
3.13 Padronizao de Cores
O padro de cores dos objetos dos modelos de dados (entidades, atributos,

relacionamentos e respectivos nomes) pode ser consultado em detalhes na
pgina da GEARQ, na Intranet, bem como no prprio LIC 139.03.51.01.
3.14 Ferramentas de Modelagem
3.14.1 Verificador & Conversor
A ferramenta denominada Verificador & Conversor tem como objetivo garantir o

atendimento dos padres de nomenclatura e regras de modelagem de dados e
converter nomes de objetos de modelos de dados, segundo esses mesmos
padres e regras.
3.14.2 Ferramenta de Modelagem de Dados
A ferramenta CASE adotada para auxlio nas atividades de modelagem de

dados no Banco do Brasil o ERwin, produzido pela Computer Associates e
distribudo no Brasil pela Intercorp Informtica Ltda.
74
Modelagem de Dados
O software pode ser utilizado nas estaes de trabalho da rea de

desenvolvimento tecnolgico do Banco do Brasil (Edifcios Sede I, II, III e IV;
214 Norte; e 513 Norte). Para quaisquer dificuldades, sugerimos consultar o
Guia de Utilizao da Ferramenta ERwin e, se necessrio, entrar em contato
com a GEARQ para elucidar dvidas.
3.15 O "Modelo de Dados Corporativo"
O "Modelo de Dados Corporativo" representa as bases de dados corporativas e

contm as informaes sobre os mais importantes objetos de sistemas
componentes do Ambiente Banco do Brasil e os relacionamentos entre eles.
O objetivo desse modelo fornecer uma viso global desses objetos

(representados por entidades e respectivos atributos), que oferece subsdio
para as estratgias de reutilizao, uniformizao e integrao de suas
informaes como apoio s atividades de Desenvolvimento de Aplicativos,
Administrao de Dados, Administrao de Bancos de Dados e Controle de
Qualidade de Sistemas.
Lembre-se que o Modelo de Dados Conceitual deve ser um pouco mais

abrangente do que o escopo do sistema que est sendo desenvolvido,
explorando-se, principalmente, as fronteiras desse sistema com outros que
manipulam informaes comuns. Isso, muitas vezes, confere maior
estabilidade soluo desenvolvida, pois mostra sua interao e os elos de
informao que existem com outros sistemas.
O fato de uma entidade ou um relacionamento estar no MDC de um projeto no

significa, obrigatoriamente, que esses objetos sejam implementados nesse
projeto. Quando se tratar de entidades corporativas, essas entidades constaro
do MDL somente para a representao do acesso a entidades de sistemas
corporativos.
A gesto das Bases Corporativas compreende atividades que coordenam o

processo de criao e alterao dessas bases, garantindo uma viso nica de
dados, padres e relacionamentos, e levando obteno de informaes
corporativas mais confiveis.
O Modelo de Dados Lgico deve ser comparado com o Modelo de Dados

Corporativo j existente, evitando-se indesejveis redundncias e garantindo a
consistncia dos dados. Essa atividade fundamental para a obteno da base
de conhecimento da empresa e para a construo das bases de dados que a
representam. Como consequncia viro a qualidade, flexibilidade, estabilidade
e maior disponibilidade das informaes, bem como a reduo das
necessidades de manutenes nos sistemas.
O Modelo de Dados Corporativo pode ser consultado no stio da Arquitetura de

Informaes, conforme figura abaixo:

Modelagem de Dados
Aspecto do acesso ao Modelo de Dados Corporativo.
3.16 Modelo Conceitual X Modelo Lgico

Mesmo j decorridos mais de 30 anos desde que Peter Chen props a tcnica
pioneira de desenvolvimento do Modelo de Dados Conceitual - a Modelagem
Entidade-Relacionamento - ainda hoje o MDC muito confundido com o
Modelo Lgico elaborado na tcnica conhecida como Modelagem Relacional,
proposta por Codd.
Como j dissemos, o MDL deriva do MDC. Porm, por causa da influncia das
ferramentas de modelagem, que em sua maioria no suportam a modelagem
conceitual, h uma confuso generalizada na utilizao de um e de outro tipo
de artefato. Devemos estar atentos para no construirmos nossos modelos j
como modelos lgicos de dados, apesar de isso ser tambm possvel.
76
Modelagem de Dados
Mundo Real Modelo Conceitual Modelo Lgico Modelo Fsico

(relaes)

Modelagem de Dados
4. MODELAGEM DE DADOS FSICO
4.1 Desenvolvimento do Modelo de Dados Fsico

No Modelo de Dados Fsico encontram-se representados os objetos de Banco
de Dados (Tabelas e Colunas), definidos no Modelo Lgico como Entidades e
Atributos, para o Sistema de Informao que ser implementado.
O modelo de Dados Fsico deve ser aderente ao Modelo de Dados Lgico e

atender aos requisitos de acesso aos dados. Assim, para um bom resultado no
projeto fsico de banco de dados, necessrio que os insumos sejam de boa
qualidade, isto , um modelo lgico que represente as regras de negcio de
forma consistente e uma boa anlise de acesso aos dados.
Um Modelo de Dados Fsico deve conter:

tabelas, colunas, chaves primrias e estrangeiras e, opcionalmente,
ndices;
as descries das tabelas e colunas, que, a princpio, herdaro o contedo
das respectivas entidades e atributos;
os nomes das tabelas e colunas, obtidos por abreviao dos nomes por
extenso, atribudos de acordo com os padres de nomenclatura institudos
no BB e formados por termos previamente convencionados no Glossrio da
Tecnologia;
para cada uma das colunas, o tipo de dado, tamanho, valor "default",
opes de nulidade e constraints para domnios discretos.
4.2 ERwin Data Modeler

A ferramenta do tipo CASE (Computer-Aided Software Engineering) de
auxlio Modelagem de Dados adotada pelo BB denominada ERwin Data
Modeler, fabricada pela CA Computer Associates, e que pode ser instalada a
partir de um programa disponvel em drive pblico, da rede Intranet, para toda
a rea de desenvolvimento de sistemas aplicativos.
por meio dessa ferramenta que os Modelos de Dados (Lgico e Fsico) so

elaborados.
Abaixo, figura que mostra alguns aspectos da rea de trabalho da ferramenta

ERwin:
78
Modelagem de Dados
Aspectos da rea de trabalho da ferramenta ERwin.
4.3 Verificao de Padres de Modelagem Converso de

Nomes
A converso dos nomes das Entidades e Atributos do Modelo Lgico para as

abreviaturas das Tabelas e Colunas, no Modelo Fsico, assim como a
verificao das normas de modelagem de dados institudas no BB, feita
utilizando-se uma ferramenta, desenvolvida pela GEARQ, chamada
VERIFICADOR / CONVERSOR. Essa ferramenta deve ser instalada na
estao de trabalho a partir do stio da Arquitetura de Informaes.
O acesso ao stio da Arquitetura de Informaes feito pela Intranet ao se

digitar AD no campo de endereo http.
Abaixo, figura mostra aspectos da rea de trabalho da ferramenta

VERIFICADOR / CONVERSOR:

Modelagem de Dados
Aspectos da rea de trabalho da ferramenta VERIFICADOR / CONVERSOR.
80
Modelagem de Dados
Para a execuo dos processos de elaborao, verificao e converso de um

Modelo de Dados, os passos abaixo devem ser seguidos:
01. Instalar a ferramenta ERwin na estao de trabalho;
02. Instalar a ferramenta VERIFICADOR / CONVERSOR na estao de

trabalho;
03. Para modelos de dados de sistemas novos (primeira verso do modelo):

a) Elaborar o Modelo de Dados de acordo com os Requisitos e Regras de
Negcio definidas para o sistema aplicativo, usando a ferramenta
ERwin;
b) No momento em que o Modelo de Dados estiver com a primeira verso
em condies de anlise, salvar o modelo como arquivo XML;
c) Iniciar a ferramenta VERIFICADOR / CONVERSOR;
d) Abrir o arquivo XML, citado no item 3.2, usando o boto Localizar;
e) Solicitar o servio Converter Nomes & Verificar;
f) Indicar o nome do arquivo para converso no campo Arquivo XML
Convertido ou aceitar o nome default sugerido pela ferramenta;
g) Aps o trmino do processo de verificao, selecionar a aba
Relatrios para acesso s ocorrncias que, eventualmente, tenham
sido apontadas;
h) Abrir o modelo de dados pela ferramenta ERwin, indicando o arquivo
XML j convertido pelo VERIFICADOR / CONVERSOR, e corrigir as
causas de erros apontados na aba Relatrios da ferramenta de
verificao;
i) Salvar, como arquivo XML, o modelo corrigido (pode ser sobre o
arquivo anterior);
j) Executar, novamente, a verificao do modelo;
k) Aps certificar-se de que no mais existam ocorrncias, enviar o
arquivo XML, convertido e corrigido, para validao, usando o stio da
Arquitetura de Informaes.
04. Para atualizao de modelos de dados j existentes (versionamento):

a) A partir do stio da Arquitetura de Informaes, baixar para a estao de
trabalho a ltima verso validada do Modelo de Dados;
b) Promover as atualizaes no Modelo de Dados (Lgico e Fsico) de
acordo com os Requisitos e Regras de Negcio que motivaram o
versionamento, usando a ferramenta ERwin;
c) No momento em que o Modelo de Dados estiver com as atualizaes
em condies de anlise, salvar o modelo como arquivo XML;
d) Iniciar a ferramenta VERIFICADOR / CONVERSOR;
e) Abrir o arquivo XML, citado no item 4.3, usando o boto Localizar;

Modelagem de Dados
f) Em Seleo de Objetos clicar em Habilitar;

g) No quadro que aparece abaixo de Seleo de Objetos clicar sobre o
nome do modelo de dados para permitir a visualizao de todas as
entidades do modelo;
h) Selecionar apenas as entidades e os respectivos atributos que fazem
parte da atualizao do modelo;
i) Solicitar o servio Converter Nomes & Verificar;
j) Indicar nome do arquivo para converso no campo Arquivo XML
Convertido ou aceitar o nome default sugerido pela ferramenta;
k) Aps o trmino do processo de verificao, selecionar a aba
Relatrios para acesso s ocorrncias que, eventualmente, tenham
sido apontadas;
l) 4.12 Abrir o modelo de dados pela ferramenta ERwin, indicando o
arquivo XML j convertido pelo VERIFICADOR / CONVERSOR, e
corrigir as causas de erros apontados na aba Relatrios da ferramenta
de verificao;
m) Salvar, como arquivo XML, o modelo corrigido (pode ser sobre o
arquivo anterior);
n) Executar, novamente, a verificao das entidades que fazem parte da
atualizao do modelo;
o) Aps certificar-se de que no mais existam ocorrncias, enviar o
arquivo XML, convertido e corrigido, para validao, usando o stio da
Arquitetura de Informaes.
4.4 SGBDR (Sistema Gerenciador de Bancos de Dados

Relacionais)
Os Modelos Relacionais (Lgicos / Fsicos) so desenvolvidos objetivando sua
implementao em bancos de dados relacionais. Esses bancos de dados so
gerenciados por complexos softwares que so denominados Sistemas
Gerenciadores de Bancos de Dados Relacionais.
O Sistema Gerenciador de Bancos de Dados Relacionais mais usado para

implementaes de sistemas aplicativos no BB o DB2, fabricado pela IBM.
Os bancos de dados implantados em DB2 esto, em sua grande maioria,

instalados no ambiente mainframe, razo pela qual as informaes deste
captulo so baseadas nesse SGBD, principalmente as relativas a projeto de
banco de dados.
Porm, temos vrias bases de dados em DB2 de plataforma distribuda.
82
Modelagem de Dados
O SGBDR ORACLE, em plataforma distribuda, tambm usado para

implementaes de sistemas aplicativos do BB, porm, com nfase para
informaes gerenciais (Data Mart e Data Warehouse).
4.5 Objetos do Modelo de Dados fsico

4.5.1 Tabelas
As tabelas so implementaes, em bancos de dados, das entidades do

modelo lgico.
Quando se pensa na implementao de uma tabela, importante saber:

qual o volume de dados que ela conter;
de que forma os dados dessa tabela sero inseridos, atualizados ou
excludos (em processos on-line ou batch);
com que frequncia os dados sero atualizados;
de que forma os dados dessa tabela sero acessados;
com que frequncia os dados sero acessados,
qual a disponibilidade esperada para essa tabela, etc.
De acordo com as respostas a esses questionamentos, podemos determinar a

presena de processos crticos no acesso tabela.
E o que so processos crticos?
Processos Crticos
Processo ao continuada de uma atividade, modo de fazer alguma coisa,

mtodo, procedimento.
Crtico que causa crise, que implica perigo ou risco, que vital.
Com base na definio acadmica para os termos acima, podemos chegar ao

seguinte conceito em relao ao desenvolvimento de sistemas:
Processos crticos
Desempenham funes essenciais para o sistema;
Podem representar riscos para a empresa;
Acontecem constantemente ou ininterruptamente.
Em relao ao tratamento dos dados, dois grupos de processos podem ser

definidos:
Processos Batch
Tratam, geralmente, grande volume de dados;

Modelagem de Dados
Tm processamento pesado;
No priorizam tempo de resposta;
Necessitam cuidados especiais com restaurao.
Processos On-Line
Devem recuperar pouco volume de dados;
Priorizam tempo de resposta;
Priorizam disponibilidade de acesso;
Determinam cuidados especiais com segurana de acesso e
concorrncia.
Na implementao fsica dos modelos de dados podemos definir como tabelas

em situaes especiais, tambm conhecidas como tabelas-foco, aquelas:
Que so acessadas por processos crticos;
Com previso de grande quantidade de dados e/ou alta disponibilidade;
Com previso de grande quantidade de acessos simultneos, ou seja,
vrios processos, on-line e/ou batch, acessando a tabela ao mesmo tempo.
Mais frente, falaremos sobre tabelas em situaes especiais em captulo

que abordar especificamente esse tema.
Excepcionalmente, ser necessrio criar tabelas que no implementem

entidades representadas no modelo de dados lgico. Tais tabelas no fazem
parte do negcio e so criadas devido a especificidades de alguns processos
do sistema aplicativo, servindo para melhor utilizao de recursos
computacionais (ex: tabela lder, tabelas de histrico, tabelas de controle,
tabelas de LOG, tabelas de sumarizao, etc.).
4.5.2 Colunas
As colunas implementam os atributos das entidades do modelo lgico. O tipo

de dado da coluna, seu tamanho, aceitao de valores nulos ou valor default
e constraints para domnios discretos so especificados no modelo fsico.
Para a criao das colunas, seguem, abaixo, os tipos de Dados (Datatypes)

admissveis, os seus respectivos limites e os padres adotados no BB:
DATE
Limites: de 01.01.0001 a 31.12.9999
TIME
Limites: de 00.00.00 a 24.00.00
TIMESTAMP (Confirmar necessidade de preciso quando do seu uso)

Limites: de 0001-01-01-00.00.00.000000 a 9999-12-31-24.00.00.000000
Numricos: (padres adotados para o BB).
SMALLINT - numricos sem casas decimais de 02 a 04 posies
84
Modelagem de Dados
INTEGER - numricos sem casas decimais de 05 a 09 posies

DECIMAL(N) - numricos sem casas decimais
Onde N = 1 (uma) posio ou N >= 10 (dez) posies
DECIMAL(X,Y) - numricos com casas decimais (ex.: valores
monetrios)
X posies, sendo (X - Y) inteiras e Y decimais
Exemplo: DECIMAL(4,2) = 99,99
Alfanumricos:
CHAR - Para plataforma alta (mainframe) - at 255 bytes
Para plataforma baixa - at 254 bytes
VARCHAR - Para plataforma alta - de 256 at 32700 bytes
Para plataforma baixa - de 255 at 32700 bytes
Os defaults do SGBD DB2 so os seguintes:

o Para Tipos numricos (decimal, smallint, integer) = 0 (zero)
o Para Tipo alfanumrico (CHAR) = brancos
o Para DATE = data do dia da insero do dado (CURRENT DATE)
o Para TIME = hora/segundo do momento de insero do dado
(CURRENT TIME)
o Para TIMESTAMP = TIMESTAMP do momento da insero do
dado
Obs: Dependendo das exigncias do negcio, o desenvolvedor poder

definir o seu prprio default no momento de criao da coluna na
tabela.
Opes de Nulidade:
o Null - aceita valores nulos
o Not Null - no aceita valores nulos
o Not Null with Default - no aceita nulos, mas, se no informado,
insere valor default.
O SGBD DB2 ao buscar os dados de uma linha da tabela o faz por meio do
processo de varredura de suas colunas, da primeira para a ltima. As colunas
que aceitam valores nulos, ou que so criadas com tamanho varivel
(VARCHAR, LONGVARCHAR, etc.), tm um byte de controle que contm,
entre outras informaes, o tamanho do contedo da coluna, e que deve ser
lido pelo DB2 para que ele possa determinar o incio do prximo campo. Na
criao da tabela, a ordem fsica das colunas pode evitar que o DB2 tenha que
passar por colunas que no sejam frequentemente solicitadas.
Na implementao fsica das colunas, algumas consideraes, visando

desempenho, devem ser feitas:
colunas mais acessadas para leitura (clusula SELECT) e gravao
(clusula UPDATE) devem estar agrupadas e mais prximas do incio da
tabela;

Modelagem de Dados
colunas que raramente so lidas, mas que so usadas como critrio de

consulta (clusula WHERE da SQL), devem ser indexadas e colocadas
mais prximas ao final da tabela. Neste caso, como as colunas fazem parte
de um ndice, o DB2 no precisar buscar o contedo da coluna na
tabela, pois esse contedo j estar na rea de ndice;
colunas que possam assumir valores nulos, sempre que possvel, devem
ser agrupadas o mais prximo do final da tabela, para que o trabalho de
leitura dos bytes de controle s seja feito quando o contedo da coluna for
efetivamente solicitado;
colunas de tamanho varivel devem ser colocadas ao final da tabela, aps
as colunas de tamanho fixo;
para colunas de tamanho muito grande que no sejam sempre acessadas
junto com as demais, conveniente a criao de uma tabela somente fsica
para acomod-las, estabelecendo-se um relacionamento com a tabela de
origem.
Toda incluso de nova coluna (no caso de versionamento do modelo, por

exemplo) feita, fisicamente, no final da tabela (aps todas as colunas j
existentes), mesmo que no modelo de dados o atributo correspondente no
aparea como o ltimo da entidade.
No Banco de Dados, em se tratando de tabela j implementada, quando se

quer inserir uma coluna entre as j existentes faz-se necessrio o DROP da
tabela e a sua recriao, com a nova ordem de colunas desejada.
A nova coluna deve aceitar nulos ou ser criada com a clusula

NOT NULL WITH DEFAULT.
Domnio de uma coluna
o universo de valores que a coluna pode receber.
Por exemplo: uma coluna que represente o tipo de sexo na tabela Pessoa
Fsica ter como domnio os valores masculino e feminino.
Cardinalidade de uma coluna
a quantidade de valores distintos prevista para a coluna.
Ainda considerando o exemplo do tipo de sexo na tabela Pessoa Fsica, a

cardinalidade (quantidade de valores distintos) da coluna ser: 2 (dois).
4.5.3 Supertipo / Subtipo (Especializao)
A implementao fsica de estruturas supertipo/subtipo, tambm chamadas de

generalizao/especializao, pode se dar de trs modos:
86
Modelagem de Dados
implementar exatamente como no modelo lgico, isto , criar uma tabela

para o supertipo e uma tabela para cada subtipo;
criar somente uma tabela para o supertipo e migrar para ela os atributos
dos subtipos, sendo que as colunas que implementam tais atributos devem
aceitar nulos;
criar somente as tabelas para os subtipos, migrando os atributos gerais do
supertipo para cada subtipo;
Supertipo/Subtipo Modelo Lgico
Supertipo/Subtipo Modelo Fsico (opo a)

Modelagem de Dados
Supertipo/Subtipo Modelo Fsico (opo b)
Supertipo/Subtipo Modelo Fsico (opo c)
A opo a pode ser usada quando os processos que acessam os dados no

tm requisitos especiais. Por estar totalmente aderente ao modelo lgico, no
acarreta redundncia nem a necessidade de se trabalhar com valores nulos,
mas, exige a execuo de join quando se quer acessar todas as informaes
para uma instncia.
A opo b evita a necessidade de join, colocando todos os registros em uma

nica tabela, e pode ser mais adequada quando os dados so sempre
acessados levando-se em conta o total de instncias do supertipo, porm, gera
a necessidade de se trabalhar com colunas que aceitem valores nulos.
88
Modelagem de Dados
A opo c tambm evita join e pode ser a indicada quando os acessos se

do por subtipo, visto que gera tabelas especializadas e menores que a tabela
da opo anterior, mas, acarreta redundncia, com colunas semelhantes (alm
da chave primria) em todas as tabelas implementadas.
Cada uma das opes tem vantagens e desvantagens, sendo necessria a

anlise do tipo de acesso aos dados para determinar qual a opo mais
adequada.
4.5.4 Implementao de Chaves
Chave Candidata
o atributo ou grupamento de atributos que tem a propriedade de identificar

unicamente uma ocorrncia da entidade. Uma Chave Candidata pode se tornar
a Chave Primria.
Chave Primria (PK Primary Key)
a chave que, escolhida entre as chaves candidatas, garante univocamente

um registro dentro da tabela. definida no modelo lgico e depende das regras
do negcio.
A chave primria s pode ser implementada fisicamente por meio de um ndice

nico (o que o determina como um ndice primrio). Esse ndice nico criado
sobre as colunas da chave primria escolhida.
Chave Secundria (AK Alternate Key)
Chave Secundria aquela chave candidata que no foi escolhida como chave
primria.
Caso a tabela tenha mais de uma chave candidata, as chaves secundrias,

assim como a PK, devem, tambm, ter ndices nicos criados sobre as suas
colunas.
Chave Estrangeira (FK Foreign Key)
As chaves estrangeiras so a implementao fsica dos relacionamentos

lgicos e devem ser criadas para que as regras de negcio fiquem sob
controle do SGBD, e no dos programas aplicativos.
Tabelas pequenas (com poucas linhas) e estveis (que no sofram atualizao

frequente), e que enviam chaves para outras tabelas, podem no ser
implementadas fisicamente, por opo do desenvolvedor do sistema. Neste
caso, recomenda-se que as colunas das tabelas que recebam as chaves
estrangeiras (destino do relacionamento) tenham restries de
domnio (implementadas via check constraint).

Modelagem de Dados
4.5.5 Implementao de Restries de Integridade
Quando implementamos relacionamentos entre as entidades, estamos

exprimindo as regras de negcio. Para os relacionamentos documentados,
declaramos ento as restries de integridade referencial, que so expressas
para garantir a consistncia dos dados para as operaes de incluso,
excluso e alterao. Estas regras podem ou no ser implementadas atravs
do SGBD ou podem, ainda, ser implementadas parcialmente pelo SGBD e
parcialmente pelos programas do aplicativo de negcio.
Integridade Referencial na Incluso: esta regra garantida a partir da

verificao prvia de valores vlidos para os atributos que so chaves
estrangeiras nas entidades dos quais eles so as chaves primrias. Caso
contrrio, a operao de incluso deve ser rejeitada ou dever ser includa uma
nova ocorrncia com um valor vlido da chave estrangeira na entidade "me".
Integridade Referencial na Excluso: pode ser garantida atravs de aes

alternativas:
quando uma ocorrncia em uma entidade excluda, ento todas as
ocorrncias de chaves estrangeiras desta chave primria tambm devem
ser excludas (cascade);
quando uma ocorrncia em uma entidade excluda, ento todas as
ocorrncias de chaves estrangeiras desta chave primria devem ser
alteradas para nulos (set null); ou
a operao de excluso pode ser rejeitada se existir uma ocorrncia de
chave estrangeira da chave primria a ser excluda (restrict)
Integridade Referencial na Alterao: esta regra tambm garantida por

aes alternativas:
atualizar para nulo todas as ocorrncias de chave estrangeira com o valor
antigo da chave primria que est sendo alterada (set null);
atualizar para o novo valor todas as ocorrncias de chave estrangeira com
o valor antigo da chave primria que est sendo alterada (cascade);
rejeitar a atualizao se existirem ocorrncias de chave estrangeira com o
valor antigo da chave primria que est sendo alterada (restrict); ou
em uma operao de atualizao de uma chave estrangeira o
procedimento anlogo ao da operao de incluso, ou seja, se a chave
estrangeira alterada, o novo valor deve ser um valor vlido de chave
primria na entidade me.
H ainda outras restries de integridade que no se encaixam nas categorias

bsicas indicadas acima. Estas restries so chamadas de restries de
integridade semnticas, ou seja, so regras de negcio que no podem ser
definidas formalmente dentro das categorias citadas. Abaixo, alguns exemplos
de restries semnticas:
90
Modelagem de Dados
um empregado do departamento denominado Finanas no pode ter a

categoria funcional Engenheiro; ou
um empregado no pode ter um salrio maior que seu superior imediato.
Representao de Entidades/Atributos e suas respectivas Tabelas/Colunas.

Modelagem de Dados
4.5.6 ndices
Um ndice deve ser criado com os seguintes objetivos:

garantir que o valor de uma coluna (ou da combinao de colunas) seja
nico para cada linha de sua respectiva tabela;
melhorar o desempenho das aplicaes que acessam a tabela;
determinar a ordem fsica das linhas da tabela;
determinar o particionamento da tabela (vide captulo sobre
Particionamento de Tabela);
ndice nico
Garante que a chave seja nica (sem valores duplicados).
definido por meio da incluso do parmetro UNIQUE na DDL

(Data Definition Language) de criao do ndice. Pode, tambm, servir para
melhorar o desempenho no acesso aos dados, embora no seja sua principal
caracterstica.
ndice no nico
criado para melhorar o desempenho dos programas que acessam a tabela.
Para definir quais ndices so necessrios, e qual a melhor ordem das colunas
de suas chaves, necessria uma anlise dos tipos de consulta aos dados da
tabela, pela anlise dos requisitos do sistema, das regras de negcio e/ou das
instrues SQL Structured Query Language - embutidas nos programas
aplicativos.
Se uma tabela for eminentemente de leitura, possuir vrios ndices pode

melhorar o desempenho das aplicaes de consulta.
Entretanto, a criao de muitos ndices em uma tabela pode prejudicar as

operaes de insero. Tambm as operaes de atualizao em colunas que
faam parte de ndices podem ficar significativamente prejudicadas. Portanto,
qualquer criao de ndice, exceto os de chave primria (que so obrigatrios),
deve ser cercada de anlise criteriosa.
A distribuio dos valores nas colunas do ndice deve ser tal que apenas uma
pequena parte do nmero total de linhas de uma tabela seja selecionada
(capacidade de filtragem dos dados).
Em uma consulta, ndices definidos com mais de uma coluna podem ser
usados acessando todas ou algumas dessas colunas, seguindo a ordem das
colunas da chave do ndice. Portanto, tal ordem deve ser estudada de forma
que um mesmo ndice possa otimizar o acesso de vrios tipos de consulta.
92
Modelagem de Dados
Por exemplo, um ndice com trs colunas pode ser usado por consultas que se
refiram somente sua primeira coluna, por consultas que se refiram s suas
duas primeiras colunas, alm de consultas que se refiram, exatamente, s trs
colunas da chave. Logo, caso exista um ndice (no nico) cuja chave
composta pelas colunas X e Y e seja necessrio criar um ndice com as
colunas X, Y e Z (mantendo-se a ordem das duas primeiras colunas do ndice
j existente), o ndice anterior pode ser eliminado.
Colunas com alto grau de atualizao no devem ser usadas como

ndice. Do mesmo modo, colunas com baixa cardinalidade (poucos valores
distintos) devem ser evitadas para ndices, a no ser quando em conjunto com
outras colunas de alta cardinalidade.
ndice Cluster
A incluso do parmetro CLUSTER na DDL de criao de um ndice determina

que a ordem fsica das linhas da tabela ser estabelecida pela chave deste
ndice. O SGBD DB2 o usa como base para os processos de REORG, de
modo que as linhas da tabela fiquem na ordem da chave desse ndice aps o
processo de reorganizao, e tentar, sempre que possvel, manter a ordem
determinada pelo ndice CLUSTER nas inseres de novos valores (a linha
inserida ficar no lugar certo se houver espao livre na pgina da tabela).
Caso nenhum ndice seja designado como CLUSTER, o ndice com data de
criao mais antiga ser utilizado para essa funo, mas, apenas para a
insero de novos valores na tabela (instruo INSERT).
No DB2, uma tabela pode ter apenas um ndice designado como CLUSTER.
Na performance de um processo, a influncia da clusterizao (organizao

fsica dos dados de uma tabela) proporcional quantidade de linhas
pesquisadas. Os dados desejados podem estar agrupados e ordenados, ou
podem estar pulverizados, caso no exista um ndice CLUSTER ou ele exista,
mas, determine uma ordem diferente da que o processo necessita, degradando
a performance. Alm disso, se a tabela sofre muitos acessos on-line
simultneos e um determinado processo envia para o buffer de memria mais
pginas da tabela do que o mnimo necessrio, esse processo pode estar
enfileirando outros processos, a ponto de causar problemas de conteno,
como timeout ou deadlock.
A figura abaixo mostra a diferena entre um ndice no clusterizado, em

relao ordem fsica dos registros da tabela, e um ndice clusterizado, com
suas chaves ordenadas de acordo com a ordem fsica dos registros dessa
mesma tabela.

Modelagem de Dados
Com os dados clusterizados, processo encontra as linhas agrupadas e ordenadas.
A escolha do ndice CLUSTER envolve a anlise de todos os processos de

consulta e atualizao que o sistema aplicativo far na tabela. Mais uma vez, a
anlise deve se basear nos requisitos do sistema, nas regras de negcio e nas
instrues SQL (Structured Query Language) embutidas nos programas
aplicativos.
No h obrigatoriedade de que o ndice da chave primria (PK) seja

CLUSTER. A determinao da ordem fsica dos registros pela chave primria
depender, tambm, da anlise dos processos que acessam a tabela. Porm,
no havendo a possibilidade de determinar, claramente, um ndice CLUSTER
que no seja o da PK, ento, deve-se criar o ndice de chave primria (PK)
como CLUSTER.
94
Modelagem de Dados
4.5.7 Particionamento da Tabela
O particionamento usado, normalmente, para tabelas com grande quantidade

de registros, mas pode, eventualmente, ser usado para outras situaes.
Citando um exemplo: suponha uma aplicao que necessite, para uma

determinada tabela, de uma organizao especfica por meses do ano e que
essa tabela tenha uma grande concorrncia de acesso. Ento, poderamos
particionar a tabela em 12 parties, independente da quantidade de registros,
uma para cada ms do ano. Esse particionamento seria usado apenas para
organizar os dados de forma adequada para esta situao hipottica. Isso
contribuiria para minimizar os problemas gerados pela grande concorrncia por
permitir acesso paralelo, alm da possibilidade de orientao de cada partio
para buffer de memria distinto.
Para auxiliar na definio do nmero de parties baseando-se na rea

alocada, o desenvolvedor poder se utilizar da seguinte equao:
Nmero de parties = rea total / 1 Gb
Onde:
rea total = (quantidade de registros) * (total da soma dos bytes das
colunas)
1 Gb = 1.073.741.824 bytes
O particionamento de tabelas permite que o Gerenciador de Banco de Dados

trabalhe com arquivos menores, j que a tabela dividida, fisicamente, pelo
nmero de parties definido.
Para o particionamento de uma tabela deve-se, primeiramente, criar um

tablespace (objeto de banco de dados onde so definidas as tabelas) com o
mesmo nmero de parties previsto para ela. A tabela particionada ser
criada sobre esse tablespace.
No DB2, quando se cria um tablespace no particionado, apenas um arquivo

alocado para armazenamento dos dados.
Na criao de um tablespace particionado so alocados, fisicamente, tantos

arquivos quanto o nmero de parties definido.
At a verso 7 do DB2 (ou a verso 8 compatibility mode), para o

particionamento de uma tabela necessria a criao de um ndice CLUSTER
que estabelecer, alm da ordem fsica dos registros, o valor mximo da chave
para cada partio, ou seja, a faixa de registros que cada partio da tabela
conter.
O ndice CLUSTER de particionamento ter o mesmo nmero de parties do

TABLESPACE e, consequentemente, o mesmo nmero de arquivos alocados.

Modelagem de Dados
A partir da verso 8 do DB2 (full mode), o particionamento da tabela pode ser

feito tanto por meio de um ndice de particionamento, como por meio de uma
nova instruo SQL para a criao da tabela. Nela j se determina quantas
sero as parties, qual a chave de particionamento e qual o valor mximo
para cada partio, tudo dentro de uma nica DDL. Isso sem a necessidade de
um ndice CLUSTER de particionamento. Consequentemente, a clusterizao
da tabela (ordem fsica dos registros), agora, pode ser feita por outra chave
diferente da usada para determinar o particionamento da tabela.
Independente da verso do DB2, a escolha da chave de particionamento deve

buscar uma distribuio homognea dos dados e, ao mesmo tempo, no caso
de particionamento por ndice, ordenar os registros de forma a atender aos
processos que acessam a tabela.
Para o particionamento, verifica-se se algum conjunto de atributos naturais da

entidade (inclusive a chave primria) pode ser usado. Caso contrrio, deve-se
incluir na tabela uma coluna somente fsica (atributo artificial com valor definido
por programao), que ser usada exclusivamente para essa finalidade.
Um ndice CLUSTER que tenha como primeira coluna da chave um atributo

artificial dificilmente ser usado pelo DB2 para melhorar o acesso, apenas para
a organizao dos dados. Isso acontece porque a primeira coluna da chave,
neste caso, no faz parte do negcio.
4.6 Anlise de Acesso aos Dados

A anlise de acesso aos dados deve identificar os processos que sejam crticos
(vide captulo sobre Processos Crticos), pois sistemas que tenham processos
com aquelas caractersticas podem eventualmente necessitar implementaes
fsicas diferentes do modelo lgico. Nesses casos, o modelo fsico pode
apresentar redundncias ou desnormalizaes visando melhorar o
desempenho no acesso aos dados. Esses expedientes devem ser bem
avaliados e testados porque nem sempre proporcionam vantagens (como
ganho de performance), porm, sempre apresentam alguma desvantagem
(riscos maiores de inconsistncia, perda de flexibilidade, maior consumo de
recursos, etc).
No Banco do Brasil, com os recursos computacionais existentes e o perfil dos

aplicativos bancrios, a maioria dos processos no necessita tratamento
diferenciado, possibilitando que o modelo fsico seja desenvolvido de forma
bem prxima ao modelo lgico. Porm, a necessidade de desnormalizao
ser definida com base em informaes complementares, analisadas pelo DBA
(Database Administrator) durante o desenvolvimento do Projeto de Banco de
Dados, como veremos mais adiante.
4.7 Tabelas em situaes especiais (tabelas-foco)

Antes de qualquer coisa, deve-se ter em mente a necessidade de desenvolver
o modelo fsico de banco de dados levando em considerao, alm do modelo
96
Modelagem de Dados
de dados lgico, informaes sobre volumes, acessos e necessidade de

disponibilidade, visando garantir uma implementao com a melhor
performance, e assegurando aspectos como padronizao, portabilidade,
disponibilidade e capacidade de recuperao tempestiva dos dados.
O MAL - Mapa de Acesso Lgico - um instrumento onde o desenvolvedor

deve especificar como as funes do sistema iro bombardear o modelo de
dados. Alm de registrar informaes sobre acessos, tambm pode apresentar
dados sobre a periodicidade com que determinada funo ser executada, o
tipo de processamento (batch ou on-line), entre outros.
Alguns MAL representam os acessos aos dados no nvel de funes, outros no

nvel de transaes e programas. A prtica nos mostra que melhor trabalhar
no nvel de macroespecificao de programas, j com a apresentao das
instrues SQL que iro acessar o banco de dados.
Neste ponto cabe uma pergunta: preciso preencher o MAL para todos os
programas do sistema? A resposta : No;
Recomenda-se o estabelecimento de critrios para selecionar somente aqueles

programas considerados mais crticos em relao performance, requisitos do
negcio, entre outros aspectos.
Abaixo, dois momentos em que o MAL pode ser de grande utilidade para o
Projeto final de Banco de Dados:
a) Na fase de Levantamento de Requisitos, por meio dos Casos de Uso que

iro acessar os dados das Entidades previstas para o Modelo de Dados
Lgico:
Tipo de Acesso:
1 Seleo (SELECT)
2 Pesquisa (WHERE)
3 Ordenao (ORDER BY)
4 Agrupamento (GROUP BY)
5 Juno (JOIN)

Modelagem de Dados
b) Na fase de validao do Modelo de Dados e do Projeto de Banco de Dados,

onde as informaes, agora, se do com foco nas instrues SQL das
transaes que acessaro as tabelas da base de dados a ser
implementada:
LEGENDA:
TIPO DE CLUSULA SQL: TIPO DE OPERANDO:

1 de seleo (SELECT) 0 no se aplica
2 de pesquisa (WHERE) 1 igualdade
3 de ordenao (ORDER BY) 2 lista (clusula IN)
4 de agrupamento (GROUP BY) 3 intervalo
5 de juno (JOIN) 4 negao (clusula NOT / NOT IN)
5 desigualdade
TIPO DE LIGAO DE CLUSULA:
0 no de aplica
1 AND
2 OR
Qtde de linhas pesquisadas = Qtde de linhas da Tabela * Fator de Filtro Total da SQL
Sendo:
Fator de Filtro Total da SQL = Fator de Filtro Coluna1 * Fator de Filtro Coluna2 * Fator de Filtro ColunaN
Fator de Filtro Coluna = 1 / Cardinalidade da Coluna
Obs1: Fator de Filtro Coluna com Tipo de Clusula SQL pesquisa, Tipo de Operando
igualdade, Tipo de Ligao de Clusula AND e distribuio homognea para os valores de
domnio da coluna.
Obs2: Para Tipo de Ligao de Clusula OR (mantidas as demais informaes da Obs1)

devemos alterar o clculo para:
98
Modelagem de Dados
Qtde de linhas pesquisadas = (Qtde de linhas da Tabela * Fator de Filtro Coluna1) + (Qtde de linhas da
Tabela * Fator de Filtro Coluna2) + (Qtde de linhas da Tabela * Fator de Filtro ColunaN)
Com base nos volumes e no perfil de acesso, analisados por meio do Modelo
de Dados e pelo MAL, deve-se elaborar o relatrio de apoio, que definir os
procedimentos a serem observados por tabela-foco.
Alguns dados adicionais que o relatrio de apoio pode conter:

necessidade de backup por perodo;
necessidade de janelas para execuo de utilitrios (como REORG, por
exemplo);
concorrncia entre processos batch e processos on-line;
quantidade de usurios concorrentes;
necessidade de expurgo (descarte dos dados).
Algumas dessas informaes so aferidas por estimativa, com base nos

levantamentos executados pela equipe de anlise.
As informaes contidas no MAL so fundamentais e devero ser preenchidas

pela equipe de desenvolvimento.
Aps analisar o modelo de dados lgico, o MAL e o relatrio de apoio para o

levantamento de tabelas-foco, o DBA:
define os ndices a serem criados;
define tipos de colunas adequados;
define o particionamento para tabelas com grande volume de dados;
define o tipo de implementao para generalizao/especializao
(entidades supertipos e subtipos), decidindo sobre a quantidade de tabelas
a ser criada no Banco de Dados;
implementa constraints para domnios discretos;
decide se a integridade referencial ser garantida pelo SGBD ou pela
aplicao;
define parmetros para garantir a disponibilidade dos dados conforme
requisitos (nvel de lock, acessos concorrentes, etc.).
A seguir, figura que mostra o trabalho do DBA na definio do Projeto de

Banco de Dados, com base nas informaes recebidas do Modelo de Dados e
do MAL Mapa de Acesso Lgico:

Modelagem de Dados
Anlise do DBA na definio do Projeto de Banco de Dados.
A tabela a seguir mostra alguns aspectos do que se pode considerar como

situaes especiais e suas possveis solues:
100
Modelagem de Dados
SITUAO ESPECIAL PARA A POSSVEL SOLUO:

TABELA:
1. Grande volume (quantidade) Particionamento;
Tabelas de Histrico (ou Tabelas
de Apoio);
Descarte de dados;
2. Alta disponibilidade (do tipo 24x7) Espelhamento;
Particionamento;
3. Alta concorrncia (muitos acessos Criao de ndices no nicos;
simultneos (on-line e/ou batch) em Particionamento;
curto espao de tempo) Clusterizao;
4. Grande volume de atualizao via Uso de utilitrios do SGBD
processo batch (UNLOAD / LOAD);
Particionamento;
Descarte de dados;
Integridade implementada pela
aplicao;
5. Consultas gerenciais (processa- Clusterizao;
mento de grande volume de Particionamento;
informao via on-line) Tabelas de sumarizao;
Tabelas de Histrico;
Possibilidade de consultas batch
com a disponibilizao de arquivos
e/ou relatrios;
6. Grande volume de consulta via Clusterizao;
processo batch (gerao de Particionamento;
relatrios) Descarte de dados;
7. Falta de janela batch para Particionamento (execuo por
execuo de utilitrios de partio);
manuteno para toda a tabela
Aspectos de situaes especiais no acesso a tabelas do banco de dados
4.8 Sistema MOD Manuteno de Objetos de Dados

O sistema MOD um aplicativo, tambm desenvolvido pela GEARQ, que cria,
automaticamente, todos os objetos de bancos de dados com base na ltima
verso do modelo de dados fsico validado.
Atualmente, o sistema MOD cria os objetos de bancos de dados somente no

SGBD DB2 do ambiente mainframe, onde esto implementadas cerca de 90%
das bases de dados de sistemas aplicativos do BB. H previso para sua
extenso, tambm, aos SGBD de plataforma distribuda.
Aps o processo de Desenvolvimento, Verificao e Converso do Modelo de

Dados, executado com o auxlio das ferramentas ERWIN e VERIFICADOR /
CONVERSOR, j abordadas em captulos anteriores, e aps a validao do
modelo de dados lgico / fsico, chega-se fase de criao dos objetos de
banco de dados.
Universidade Corporativa Banco do Brasil
101
Modelagem de Dados
Acesso ao Sistema MOD
Para as bases de dados que sero implementadas em DB2 do ambiente

mainframe, deve-se acessar o sistema MOD por meio da opo 29 do
aplicativo PRODUCAO, conforme figura abaixo:
Tela do aplicativo PRODUCAO.
A seguir, deve-se escolher o banco de dados DB2, conforme figura abaixo:
Escolha do banco de dados para a criao de tabelas.
102
Modelagem de Dados
4.8.1 Criao de Objetos de Banco de Dados
Na tela seguinte, deve-se informar a sigla do sistema aplicativo, de cujo modelo

de dados fsico sero extrados os objetos de banco de dados, e, tambm, uma
das opes apresentadas. No exemplo abaixo, solicita-se a criao de uma
tabela do sistema MMD:
Tela de solicitao de servios do sistema MOD.
Na tela a seguir, pode-se escolher qual a tabela, entre as existentes no modelo

de dados fsico, se quer criar. Percebe-se que o MOD j apresenta um nome
para o tablespace, baseado nos padres de nomenclatura adotados no BB e
no seqencial do ltimo tablespace criado para o sistema aplicativo. Se ainda
no houver tabela criada para o sistema aplicativo, o nmero sequencial
desse tablespace ser 001.

103
Modelagem de Dados
Tela para a solicitao de criao de Tabela
Posicionando-se o cursor no campo Tabela e pressionando-se a tecla F4, o

MOD abrir uma janela contendo todos os nomes das tabelas do modelo de
dados fsico.
Escolhe-se a tabela a ser criada colocando-se um X ao lado do nome, como

mostra a prxima figura:
Sistema MOD lista as tabelas do modelo de dados fsico.
104
Modelagem de Dados
A seguir, o MOD trar as informaes sobre todas as colunas da tabela

escolhida, para que o desenvolvedor possa confirmar esses dados antes de
sua criao:
Sistema MOD traz informaes sobre as colunas da tabela escolhida.
Nesta tela, ao se teclar ENTER, o MOD abre uma janela solicitando a

confirmao para a criao da tabela. Para confirmar a criao, responder
SIM pergunta.
Para criar, efetivamente, a tabela e demais objetos de banco de dados, deve-

se escolher a opo 23 Executar/Verificar slct. no SGBD (na tela inicial do
MOD) - e colocar a letra E (Executar) ao lado do nome do objeto de banco de
dados, que dever estar na situao REC (atentar para o tipo de servio
DROP, CREATE ou ALTER).
Os comandos para a criao do tablespace e do ndice da chave primria

tambm sero gerados e enviados para a tela de execuo, conforme se pode
verificar na figura abaixo:

105
Modelagem de Dados
Tela para a execuo dos comandos solicitados.
Antes da efetiva execuo, o desenvolvedor ainda poder ver a DDL gerada

colocando a letra V (visualizar) na linha de comando.
Opcionalmente, pode-se solicitar a criao, em bloco, de todos os objetos de

banco de dados de um sistema aplicativo. Essa opo particularmente til
para sistemas novos e quando se quer implementar todo o modelo de dados de
uma nica vez.
Para tanto, deve-se escolher a opo 25 Servios de Manuteno, colocando

a sigla do sistema aplicativo, como mostra a figura abaixo:
106
Modelagem de Dados
Tela inicial do MOD com a escolha da opo 25.
Na tela seguinte, escolher a opo 3, de acordo com a figura abaixo:
Solicitao de criao de objetos de banco de dados em lote.

107
Modelagem de Dados
Em seguida, aparecer uma janela solicitando a confirmao da solicitao em

lote, conforme mostra a figura abaixo. Confirmar a solicitao respondendo S
pergunta da caixa de dilogo.
Confirmao da solicitao de criao de objetos em lote.
Aps confirmao, deve-se entrar na opo 23 - Executar/Verificar slct. no

SGBD, e solicitar a execuo de todos os objetos, que j devero estar no
estado REC na coluna referente a Situao.
Deve-se esclarecer que, para o ambiente de Desenvolvimento - D0G1, o

prprio desenvolvedor poder comandar a execuo de criao dos objetos de
banco de dados. Porm, para os ambientes de Homologao e Produo deve-
se usar a opo 22 - Enviar solicitao para SGBD, escolhendo qual o
ambiente de origem (Desenvolvimento ou Homologao) e o ambiente de
destino (Homologao ou Produo), e aguardar que a GEPRO (Gerncia de
Produo) efetue os comandos de execuo. Somente esta gerncia tem
autoridade para criao de objetos de bancos de dados nos ambientes de
Homologao e de Produo.
4.8.2 Implantao em Produo
A criao dos objetos de banco de dados em Homologao ou Produo deve

ser feita por meio da transferncia dos comandos SQL para esses ambientes.
Para tanto, deve-se utilizar a opo 22 Enviar solicitao para SGBD.

108
Modelagem de Dados
A figura abaixo mostra a tela da opo 22 do sistema MOD com a janela que
aparece ao se pressionar a tecla F4 e que mostra os nomes de todas as
tabelas do modelo de dados fsico. Deve-se colocar um X ao lado do nome da
tabela que se quer transferir para o ambiente de Homologao ou de
Produo:
Janela apresenta os nomes de tabelas do modelo fsico
Em seguida, indicar qual o ambiente de origem e qual o ambiente de destino da

transferncia:

109
Modelagem de Dados
Tela que apresenta o nome da tabela para transferncia
Na tela seguinte, colocar a letra T (Transferir) na linha do comando que se

deseja transferir, conforme figura abaixo (atentar para o tipo de servio, o tipo
de objeto e a data e hora de criao no desenvolvimento):
Tela que mostra todos os objetos relacionados tabela que se quer transferir.
Ao final, verificar as mensagens de sucesso da transferncia ou as mensagens

de erros que porventura aconteam.
110
Modelagem de Dados
GLOSSRIO
TERMO DESCRIO
ABSTRAO o processo de isolar aspectos de uma situao que

sejam importantes para algum propsito e suprimir os
que no forem
ARTEFATO o produto de uma ou mais atividades dentro do
contexto do desenvolvimento de um sistema
DADO uma seqncia de smbolos quantitativos ou
quantificveis, como textos, nmeros, imagens, sons,
etc. que caracterizam, traduzem, integram uma
realidade ou parte dela
ESTRUTURA DE Forma coerente de organizao de dados a fim de
DADOS atender os requisitos de um processo. No ambiente
computacional designa de que maneira os dados sero
armazenados fisicamente em um banco de dados
FORMA NORMAL cada uma das condies que uma tabela deve observar
para constar de um banco de dados relacional de uma
forma otimizada, segundo a tcnica conhecida como
Normalizao
MODELO uma representao simplificada e abstrata de
fenmeno ou situao concreta, e que serve de
referncia para a observao, estudo ou anlise
MODELO DE DADOS modelo abstrato que descreve como os dados que
compem uma realidade so representados e utilizados
SISTEMA DE expresso utilizada para descrever um sistema
INFORMAO automatizado, ou mesmo manual, que abrange
pessoas, mquinas, e/ou mtodos organizados para
coletar, processar, transmitir e disseminar dados que
representam informao para o usurio.
SOFTWARE termo genrico que descreve uma coleo de
programas de computador, procedures e
documentao que executam alguma tarefa em
sistema de informao
CARDINALIDADE
CONVENO
POSICIONAL
DEPENDNCIA Quando o valor de um determinado atributo denuncia o
FUNCIONAL valor de outro atributo
DEPENDNCIA Quando um atributo depende de um segundo, e este
FUNCIONAL depende de um terceiro.
TRANSITIVA
SGBD Sistema Gerenciador de Banco de Dados

111
Modelagem de Dados
REFERNCIAS
PAULO COUGO - Modelagem Conceitual e Projeto de Bancos de Dados - Ed.
Campus, 1977.
FELIPE NERY RODRIGUES MACHADO - Banco de Dados - Projeto e

Implementao - Ed. rica.
FELIPE NERY RODRIGUES MACHADO - Banco de Dados - Projeto e

Implementao.
LUCIANO ROSSONI - Modelagem e Simulao Soft em Estratgia -

Universidade Federal do Paran - 2005 -
http://www.inf.pucrs.br/~gilberto/tgs/mapas%20cognitivos2.pdf
MIGUEL ARGOLLO JR - Anlise e projeto de sistemas orientados a Objeto -

2007 -
http://hortolandia.hoyler.edu.br/documentos/modelagem_processos_sw.pdf
SCOTT MITCHELL - The importance of data modeling - 1999 -

http:\\www.4guysfromrolla.com/webtech/datamodeling.shtml
SCOTT W AMBLER - Data Modeling 101 - 2006 -

http://www.agiledata.org/essays/dataModeling101.html
WARREN KEUFFEL - Battle of the Modeling Techniques - 1996 - DBMS

Magazine - http://www.dbmsmag.com/9608d14.html
CEFET - PB - Projeto de Banco de Dados - Modelagem ER

http://arquivos.coinfo.cefetpb.edu.br/~crishane/BD_Tecnico/Aulas/2-
modelagemER_Tec.ppt
DARIUS SILINGAS e SAULIUS KAUKENAS - Applying uml for relational data

modeling - Magic Draw - setembro/2004
http://www.magicdraw.com/files/articles/Sep04%20Applying%20UML%20for%2
0Relational%20Data%20Modeling.htm?NMSESSID=73da501d278be238780d4
bfa8c0c3746
JOO MARCELO BOROVINA JOSKO - Desmistificando a modelagem

conceitual - SQL Magazine, n 80, 23.10.2007
http://www.devmedia.com.br/articles/viewcomp.asp?comp=7072
JOS FERREIRA PRATA - 10 Passos para a Criao de um Modelo

Conceitual de Banco de Dados - SQL Magazine n 16 e 18
PETE STIGLICH - Necessity of Conceptual Data Modeling for Information

Quality
http://www.infoadvisors.com/ArticlesVideos/ConceptualDataModelingforInformat
ionQuality.aspx
112
Modelagem de Dados
PETE STIGLICH - What are the benefits of a conceptual data model -

http://searchdatamanagement.techtarget.com/expert/KnowledgebaseAnswer/0,
289625,sid91_gci1278422,00.html
REINALDO VIANA ALVARES - Tecnologias de banco de dados e modelagem

de dados - SQL Magazine, 17.04.2006, 18.05.2006, 19.06.2006
RONALDO DO SANTOS MELLO - Modelagem Conceitual - Universidade

Federal de Santa Catarina
http://www.inf.ufsc.br/~ronaldo/bdnc/2-modelagemConceitual.pdf
RONALDO DO SANTOS MELLO - Projeto de Banco de Dados - Universidade

Federal de Santa Catarina
http://www.inf.ufsc.br/~ronaldo/ine5613/12-ER.pdf
ULBRA - Universidade Luterana Brasileira - Tcnicas de Modelagem

Conceitual
WIKIPEDIA - Modelo de Entidades de Relacionamentos -

http://pt.wikipedia.org/wiki/Modelo_de_Entidades_e_Relacionamentos
Internet pesquisa em 17/04/2008:
Modelagem de dados
http://paginas.unisul.br/ethizon/PDF/aula2_modelo_dados_6porPag.pdf
What is Data Modeling? - http://infogoal.com/dmc/dmcdmd.htm
Banco de Dados Notaes Grficas Utilizadas na Modelagem Conceitual
e/ou Lgica
Nota%E7%F5es_Tec.ppt
Data modeling 101 - http://www.agiledata.org/essays/dataModeling101.html
Bancos de Dados Projeto de Banco de Dados e Modelagem E-R -
modelagemER_Tec.ppt
Data Schema Normalization -
http://www.orthogonalsoftware.com/articles/DataSchemaNormalization.html
Modelo de Dados - http://www.inf.ufsc.br/~ronaldo/ine5613/3-
modeloRelacional.pdf
Transformao de modelos conceituais em modelos de implementao de

bancos de dados (www.sbbd-
sbes2005.ufu.br/arquivos/MiniCursoSBBD2005_Mapeamento.pps)
Workshop de modelagem de dados - Jorge Costa Mtodo para converso do
Modelo Conceitual de Dados para o Modelo Lgico de Dados (documento 61
do material de suporte no localizei endereo internet)
Cristina Paludo - Modelagem_ER

113
Modelagem de Dados
42 - aula2_modelo_dados_6porPag
14 - Notao na engenharia de informao
21 - Agile data 01 - Data Modeling 101
62 - Modelo Relacional
Site da AD
Apostila do curso anterior do BB de Modelagem de Dados
Modelagem de Dados - Data : 10 de Fevereiro de 2003 - 17:37 -
http://www.guiadodelphi.com.br/ler.php?codigo=1084 /
Wikipedia
Carlos Alberto Caldo Jnior Projeto Fsico de Banco de Dados 07/10/2007
www.devmedia.com.br
114

Caderno Do Participante - 22-09-14 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Caderno Do Participante - 22-09-14 PDF

Uploaded by

Copyright:

Available Formats

Modelagem de Dados

Educando para a Sustentabilidade

Desenvolver competncias profissionais, por meio da sistematizao de

O atual contexto empresarial, altamente dinmico, exige profissionais igualmente

Compromissos consigo mesmo: autodesenvolvimento, autonomia,

Extrado da Proposta Poltico-Pedaggica para

Universidade Corporativa Banco do Brasil 1

OBJETIVO GERAL DE APRENDIZAGEM

Elaborar modelo de dados, em conformidade com as normas tcnicas e

Universidade Corporativa Banco do Brasil 3

Universidade Corporativa Banco do Brasil 5

3.15 O "MODELO DE DADOS CORPORATIVO" .............................................................................. 75

Bem vindo ao curso Modelagem de Dados no BB!

O principal objetivo deste curso que possamos elaborar modelos de dados,

Universidade Corporativa Banco do Brasil 7

Denominao completa: Modelagem de dados no BB

Elaborar modelos de dados, com a conscincia de que modelagem fase

Produzir modelos de dados, com qualidade, de acordo com as normas, as

Colaborar para a disseminao da modelagem de dados, como fase essencial no

Podemos viajar no tempo e imaginar o homem na Idade da Pedra quando

O que vemos de comum nesses exemplos que todos, de uma maneira ou de

medida que o homem desenvolvia sua capacidade intelectual, percebia que o

1.1.1 O que modelagem?

Inicialmente, precisamos entender o que um modelo. Para isso, destacamos

Modelo uma representao da realidade, porm muito mais simples (Ackoff

Modelo uma representao do mundo real com o objetivo de permitir a

Um modelo, alm de imitar a realidade, deve ter algum propsito definido

Modelo uma representao simplificada e abstrata de fenmeno ou situao

Universidade Corporativa Banco do Brasil 9

Como exemplos de modelos frequentemente observados em nosso cotidiano,

Representao de uma planta hidrulica

Nesses exemplos, constatamos que, por meio de um modelo, podemos

Em qualquer caso, a realidade (objeto) em foco sempre o ponto de partida da

Visto isso, podemos definir modelagem como o processo de representar uma

A necessidade da modelagem cresce conforme a complexidade da realidade

De maneira semelhante, um aplicativo pequeno, criado por uma nica pessoa

Representao de um sistema meteo-oceanogrfico

No mbito corporativo, encontramos diversos tipos de modelos nossa volta.

No ambiente computacional, os sistemas de informao devem tambm passar

1.2. Modelagem de Sistemas

1.2.1 Para que modelamos?

Como viso simplificada de uma realidade, o modelo de um sistema, em

Alm disso, o modelo de sistema:

Universidade Corporativa Banco do Brasil 11

representa um ambiente (negcio) observado: organizacional, funcional, de

Representao de um ambiente observado Imagem de Cheque

serve de instrumento de comunicao: os modelos so utilizados para o

1.2.2 Por que modelamos?

Devemos lembrar que os sistemas esto em constante evoluo e, portanto,

Nesse contexto, um ponto importante a ser considerado que cerca de 65%

Uma vez que as manutenes de um sistema so inevitveis e caras, o

Sob outra anlise, conforme a figura abaixo, podemos perceber que,

Origem dos Erros

Ainda hoje, no h muitos profissionais que reconheam a modelagem como

Universidade Corporativa Banco do Brasil 13

despendem tempo e energia com tal atividade e, menos ainda, os que

Modelagem como Atividade Vital

Consomem Tempo com Modelagem

Bom Trabalho de Modelagem

Percepo atual da importncia da modelagem de sistemas

1.2.3 Escopo, prazo e recurso.

A probabilidade de xito da fase de modelagem pode ser definida em funo

1.2.4 Como modelamos?