01_Modelagem_da_informação

Prévia do material em texto

Modelagem da 
Informação
Material Teórico
Responsável pelo Conteúdo:
Prof. Me. José Ahirton Batista Lopes Filho
Revisão Textual:
Prof.ª Dr.ª Luciene Oliveira da Costa Granadeiro
Conceitos Gerais em Modelagem da Informação
• Introdução;
• Conceitos Gerais.
• Capacitar os alunos quanto ao processo de modelagem de informações;
• Impulsionar o pensamento crítico quanto ao desenho e utilização de modelos diversos 
para resolução de problemas de negócios;
• Desmistifi car os termos e notações mais comuns na área;
• Qualifi car os alunos para lidarem com equipes ágeis e adotarem verdadeiramente uma 
cultura de dados em suas vidas profi ssionais.
OBJETIVOS DE APRENDIZADO
Conceitos Gerais em
Modelagem da Informação
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua 
interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e de 
aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Conceitos Gerais em 
Modelagem da Informação
Introdução
A modelagem de informações é o conjunto de práticas que determinam os re-
quisitos de estrutura, acessibilidade e ciclo de vida das informações no domínio 
de um negócio. Tal qual o processo de modelagem durante o desenvolvimento de 
software, em que arquitetos e engenheiros criam modelos de estrutura de classes, 
esquemas de bancos de dados e arquitetura de sistemas, desenvolverem modelos de 
informações que sejam flexíveis o suficiente para absorver mudanças futuras é es-
sencial. Nesse âmbito, o desenvolvimento exige equilíbrio quanto à funcionalidade, 
desempenho, resiliência, segurança e flexibilidade.
Para tanto, tem sido necessário que, cada vez mais, as empresas tenham total 
domínio quanto ao fluxo de informações em toda a organização; assim sendo, um 
modelo de informações é um auxiliar no desenho e construção de sistemas e pro-
cessos, bem como também um artefato a ser referenciado em todo o ciclo de vida 
das informações relacionadas a tal. Ou seja, modelos são representações, utilizados 
em determinados contextos, visando à geração de valor comercial.
“Um modelo é uma descrição abstrata que esconde certos detalhes enquanto ilumina outros.”
Ex
pl
or
Fonte: Semantic Web for the Working Ontologist: Effective Modeling In Rdfsand Owl
À medida que as empresas passam a criar valor a partir de seus ativos de infor-
mação, a modelagem de informações fornece então uma ferramenta importante 
para comunicar o desenho, padrões e demais aspectos-chave das entidades no 
contexto do domínio que está sendo representado para todos os envolvidos. 
A modelagem de informações é uma ferramenta para gerenciamento de infor-
mações a qual visa suportar a criação de dados confiáveis e de qualidade, mantendo 
a integridade dos dados, permitindo que as arquiteturas sejam robustas e escaláveis. 
A modelagem é um desafio particular quando os dados residem em fontes não 
estruturadas, como planilhas, documentos de texto, wikis, sites de colaboração em 
documentos, dentre outros.
Tendo em vista que as informações residem e são acessadas em muitos formatos 
e estruturas diferentes, tais como arquivos, bancos de dados relacionais e não re-
lacionais, serviços, cadeias de blocos, a necessidade de consultar, relacionar, orga-
nizar, formatar, relatar, armazenar, atualizar e alterar esquema de entidades requer 
coordenação e planejamento.
Assim sendo, o processo de modelagem da informação começa com a criação 
dos modelos, os quais são pensados principalmente durante a coleta de requisitos, 
bem como são refinados nas fases de desenho, referenciados durante a implemen-
tação e mantidos como um artefato a ser referenciado posteriormente.
8
9
É interessante ressaltar que, aos poucos, tem havido esforços significativos no 
desenvolvimento de tais modelos também para outros recursos de gerenciamento 
de informações, como nos processos de governança de dados, gerenciamento de 
dados-mestres, integração de informações e até mesmo análise em segurança da 
informação. Ou seja, a modelagem de informações tem se tornado cada vez mais 
uma etapa importante e essencial em qualquer projeto de desenvolvimento ou ma-
nutenção de software. 
Assim, estar atualizado quanto a esse assunto é importante para qualquer profis-
sional da área. O presente material visa ser um material de acompanhamento em 
que, nas próximas seções desta unidade, abrangeremos os seguintes tópicos: como 
se dá a modelagem de informações e a utilização de tais modelos, explanação sobre 
modelos conceituais e notações mais comuns, além de explanação-exemplo quanto 
a um processo de modelagem tradicional.
Conceitos Gerais
Como se dá a modelagem de informações
e como se utilizam modelos?
Agora que já sabemos que modelagem de informações é o nome dado ao con-
junto de práticas que determinam os requisitos de estrutura, acessibilidade e ciclo 
de vida das informações no domínio de um negócio, podemos perceber que, assim 
como outros artefatos de modelagem, modelos de informações podem ser utiliza-
dos para uma variedade de propósitos, desde a elaboração e utilização de modelos 
conceituais de alto nível até a de modelos físicos de dados.
Do ponto de vista de um desenvolvedor atuando no paradigma orientado a obje-
tos, modelagem de informações é, então, conceitualmente similar a ambas, mode-
lagem de dados e modelagem de classes. Porém, a modelagem de dados tradicional 
é diferente da modelagem de classes porque o seu foco acaba sendo totalmente nos 
dados, visto que modelos de classes permitem explorar os aspectos comportamen-
tais e de dados em um domínio de aplicação, já com o modelo de dados podemos 
apenas explorar o aspecto dado.
Dessa forma, modelagem de dados é o ato de explorar estruturas orientadas a 
dados e, com tal modelagem, conseguimos, então, identificar tipos de entidades, 
da mesma forma que na modelagem de classes identificamos classes. Atributos de 
dados são associados a tipos de entidades exatamente como são associados atribu-
tos e operações às classes. Logo, existem associações entre entidades, relaciona-
mentos, tais como herança e agregação, por exemplo, as quais são conceitos que 
se aplicam em modelagem de dados.
9
UNIDADE Conceitos Gerais em 
Modelagem da Informação
Logo, a modelagem de informações em arquitetura de sistemas de informação 
pode assumir várias formas, todas com representações de entidades e seus respec-
tivosrelacionamentos, como:
• Diagramas de classes: onde são modeladas as informações necessárias para 
se construir ou manter um sistema ou componente;
• Diagramas de entidade relacionamento: modelagem de dados específica 
para desenho e construção de banco de dados;
• Diagramas de fluxo de informações: costumam indicar a origem dos dados 
e seus usos (processo ou sistemas) em toda a empresa, linha de negócios ou 
sistema, dependendo do contexto;
• Modelos de dados: dependendo do nível de detalhamento, descrevem as en-
tidades e seus relacionamentos detalhando atributos, tipos e multiplicidade de 
uma entidade para outras entidades;
• Ciclos de vida dos dados: como os dados são criados, usados e retidos (ar-
quivados ou destruídos).
Os modelos variam dependendo de vários fatores, tais como uso (se analítico ou 
transacional), foco (se global, corporativo, linha de negócio ou sistema) e em nível 
de detalhe (se conceitual, lógico ou físico). Por exemplo, os dados do cliente de um 
aplicativo financeiro on-line serão diferentes dos dados usados para reunir estatís-
ticas sobre a localização do cliente em um aplicativo de mobilidade urbana, no que 
o modelo do primeiro teria uma estrutura normalizada e o segundo, um esquema 
de estrela (em inglês, star schema), ou floco de neve (em inglês, snowflakeschema).
“Modelos são usados para organizar o pensamento humano na forma de explicações.”
Ex
pl
or
Fonte: Semantic Web for the Working Ontologist: Effective Modeling In Rdfsand Owl
A modelagem também pode indicar limites os quais podem ser, por exemplo, 
limites do fluxo de informações necessários para uma conformidade regulatória ou 
restrições de acesso ao negócio, com trilhas de auditoria e segurança rígidas em 
torno da autenticação e autorização. Os modelos podem ser relevantes para apenas 
um pequeno grupo de indivíduos para uma necessidade em específico do processo 
de negócios, ou podem ser reconhecidos como um padrão global da indústria.
Um modelo fornece um formato formalizado que ajuda nas conversas entre ar-
quitetos e usuários, partes interessadas, ou mesmo arquitetos e analistas externos. 
As linguagens de modelagem padronizam as notações que transmitem os significados 
de entidades, atributos, transições, relacionamentos, identificadores, dentre outros.
“Modelos têm uma influência profunda sobre como um problema é resolvido e como uma 
solução toma forma.”Ex
pl
or
Fonte: The Unified Modeling Language User Guide
10
11
Uma sessão de modelagem com especialistas no assunto ajudará a traduzir con-
ceitos do mundo real (um cenário / processo de negócios) para as entidades e 
informações corretas para as necessidades do negócio. A notação ajuda a garantir 
que o significado não seja perdido durante as fases de projeto e implementação. 
Portanto, é importante que os participantes da sessão entendam as notações que 
estão sendo usadas. Análises e compreensão inadequadas do uso dos dados levarão 
a problemas de desempenho, confiabilidade, disponibilidade e escalabilidade.
Os modelos podem, então, ser classificados em:
• Modelos de dados conceituais: esses modelos, também chamados de mode-
los de domínio, são tipicamente utilizados para se explorar aspectos de negó-
cios do cliente, e não da tecnologia, com os envolvidos no projeto. Em equipes 
ágeis, modelos conceituais de alto nível são normalmente criados como parte 
do esforço inicial do entendimento dos requisitos do sistema já em equipes tra-
dicionais (não ágeis), modelos de dados conceituais são normalmente criados 
como precursores aos modelos lógicos de dados (MLD) ou suas alternativas.
O diagrama construído neste modelo é o diagrama de entidade e relaciona-
mento, onde deverão estar todas as entidades e os relacionamentos entre elas;
• Modelos Lógicos de Dados (MLDs): MLDs também são usados para explorar 
os conceitos de negócio e seus relacionados, entretanto, já levando em conta 
características tais como limitações e implementação de recursos como ade-
quação a padrões e nomenclatura, definindo-se chaves primárias e estrangei-
ras e aspectos como normalização, integridade referencial e mais. Isso pode 
ser feito para o escopo de um simples projeto ou para uma empresa inteira. 
MLDs descrevem os tipos de entidades lógicas, tipicamente referenciadas sim-
plesmente como tipos de entidades, os atributos de dados que descrevem essas 
entidades e os relacionamentos entre as entidades. MLDsestão mais presentes 
em projetos tradicionais;
• Modelos Físicos de Dados (MFDs): MFDs são usados para se projetar o es-
quema interno de um banco de dados, ou seja, a modelagem física do modelo 
de banco de dados. Neles, são descritas as tabelas de dados, as colunas de 
dados das tabelas e o relacionamento entre as tabelas. MFDs normalmente são 
bastante úteis em projetos tanto ágeis quanto tradicionais. Um modelo físico 
deve levar em conta as limitações impostas pelo serviço de gerenciamento de 
banco de dados (SGBD) e deve ser criado com base nos exemplos produzidos 
na modelagem lógica.
Modelagem de Dados – Modelos Conceitual, Lógico e Físico: https://youtu.be/ZX7EuRWRdZg
Ex
pl
or
Embora MLDs e MFDs pareçam similares, e eles de fato o são, o nível de detalhes que cada 
um deles modela pode ser significativamente diferente. Isso porque o próprio objetivo ao se 
utilizar de cada diagrama é diferente.
Ex
pl
or
11
UNIDADE Conceitos Gerais em 
Modelagem da Informação
As Figuras 1, 2 e 3 a seguir apresentam, respectivamente, diagramas de entidade 
relacionamento para um modelo conceitual, um MLD e um MFD simples, seguin-
do a notação de Barker, todos modelando o conceito de fotos, tags e comentários 
em uma foto em mídia social, assim como o relacionamento entre eles. Podemos 
notar como o MFD nos apresenta mais detalhes, incluindo uma tabela associativa 
necessária para implementar a associação, assim como as chaves necessárias para 
manter os relacionamentos.
Figura 1 – Exemplo de modelo conceitual de dados
Fonte: Reprodução
Figura 2 – Exemplo de modelo lógico de dados
Fonte: Reprodução
12
13
Figura 3 – Exemplo de modelo físico de dados
Fonte: Visual Paradigm User’s Guide
MFDs devem também refletir os padrões de nomenclatura de banco de dados da 
organização, bem como indicar os tipos de dados das colunas, tais como integer e 
varchar (255). Modelos de dados podem ser usados efetivamente tanto no nível da 
empresa como de projetos. Os arquitetos comumente criarão um ou mais MLDs de 
alto nível os quais descrevem as estruturas de dados que apoiam toda a empresa, 
normalmente chamados de modelos de dados da empresa ou modelos de informa-
ção da empresa.
Um modelo de dados da empresa é uma das várias visões que os arquitetos da 
empresa podem escolher para manter e apoiar – outras visões podem explorar a 
infraestrutura de rede e hardware, a própria estrutura da organização, infraestru-
tura de softwares, processo de negócios, dentre outros. Esses modelos provêm 
informações que uma equipe de projeto pode usar como conjunto de restrições e 
também como descrição da estrutura do sistema.
Equipes de projeto tipicamente criarão MLDs como um dos principais artefatos 
de análise quando seu ambiente de implementação é predominantemente procedu-
ral por natureza. MLDs também são boas escolhas quando um projeto é orientado 
a dados, como na construção de um data warehouse ou sistema de relatório.
No entanto, MLDs são normalmente escolhas ruins quando uma equipe de 
projeto está usando tecnologias orientadas a objeto ou baseadas em componentes. 
Nesses casos, a equipe de desenvolvedores pode trabalhar com diagramas UML.
Ainda, quando um banco de dados relacional é usado para armazenar dados, 
é boa prática que as equipes de projeto criem um MFD para modelar um esque-
ma interno. É importante salientar que um MFD normalmente é apenas um dos 
13
UNIDADE Conceitos Gerais em 
Modelagem da Informação
artefatos de projeto críticos quando do desenvolvimento de aplicações de negócio; 
é importante estarmos atentos à aplicaçãodos artefatos corretos para o trabalho a 
ser desenvolvido.
Muitos profissionais de dados também têm preferência por criar um ORM (do in-
glês, Object-Role Model), como o apresentado no exemplo da Figura 4 a seguir, ao 
invés de um MLD para a representação de modelo conceitual. A vantagem então 
fica por conta da notação simplificada, algo que aumenta a interpretabilidade para 
os envolvidos no projeto, apesar da desvantagem que é o fato de que os modelos 
se tornam demasiadamente grandes de maneira rápida. ORMs nos permitem, en-
tão, primeiramente explorar os exemplos de dados reais ao invés de simplesmente 
partirmos para uma abstração potencialmente incorreta – por exemplo, a Figura 4 
examina o relacionamento entre clientes e um endereço em detalhe. 
Para mais detalhes o site da ORM pode ser consultado. Em: http://bit.ly/2QEhFzj
Ex
pl
or
Cliente
(nome)
Endereço
(rua)
mora em
Claudio Dias
Juliana Campos
Juliana Campos
João Silva
Rua XXX, 123
Rua YYY, 897
Av. ZZZ, 8272
Rua DDD, 245
Figura 4 – Exemplo de ORM (Object-Role Model)
Notações mais comuns
A Figura 5 a seguir apresenta um comparativo de variadas formas de se repre-
sentar um modelo conceitual em seis diferentes notações as de Chen, IDEF1X, 
Bachman, Engenharia da Informação (na figura em inglês, abreviação IE de 
information engineering), Min-Max e UML. Além disso, na Figura 6, também a 
seguir, temos um resumo da sintaxe das quatro notações mais comuns para mo-
delagem de dados: Engenharia da Informação (EI), Notação de Barker, IDEF1X e 
UML (Unified Modeling Language). 
14
15
1
0..N
Nasceu em >
< Local de nascimento
<< Relacionamento >>UML
Min–Max / ISO
(1,1) Nasceu em
Nasceu em
Nasceu em
Local de nascimento
Local de nascimento (0,N)
Pessoa
Pessoa
Pessoa
Pessoa
Pessoa
Pessoa
Localização
Localização
Localização
Localização
Localização
1N
Chen
IDEF1X
Bachman
Martin / IE /
Crow’s Foot
Localização
Local de nascimento
Figura 5 – Comparativo da representação de modelo conceitual
Resumo de sintaxe em quatro diferentes notações: http://bit.ly/2rMTeW9
Ex
pl
or
Para mais detalhes é de interesse que se conheça mais a fundo os trabalhos de Chen, 
Bachman, Martin (EI) e Barker. Disponível em: http://bit.ly/2KIvCZ2Ex
pl
or
Em resumo, temos algumas características notáveis das notações mais utilizadas:
• EI: A notação EI é simples e fácil de ser lida, além de ser considerada abran-
gente para modelagem de dados de negócio e modelagem lógica de alto nível. 
Um ponto negativo desta notação fica por conta da falta de suporte a identifi-
cação de atributos de uma entidade. Assume-se que os atributos serão mode-
lados com outro diagrama ou simplesmente descritos em uma documentação 
de apoio posterior;
• Notação de Barker: Uma das mais utilizadas, sendo a notação nativa em fer-
ramentas como o Oracle toolset. Considerada abrangente para todos os tipos 
de modelos de dados, pode se tornar complicada por possuir hierarquias com 
vários níveis de profundidade;
• IDEF1X: Notação complexa, originalmente voltada para modelagem física, 
tem sido abandonada nos últimos anos;
• UML: Não é oficialmente uma notação de modelagem de dados, apesar de 
iniciativas para a criação de um perfil UML de modelagem de dados existirem, 
nenhum é completo e não são considerados oficiais pela UML.
15
UNIDADE Conceitos Gerais em 
Modelagem da Informação
Modelando Dados
É importante que um desenvolvedor de software tenha uma noção dos funda-
mentos de modelagem de dados, não apenas para ler os modelos de dados, mas 
também para trabalhar efetivamente lado a lado com os DBAs responsáveis pelos 
aspectos relacionados aos dados de um projeto. Das seções passadas, pode-se resu-
mir um processo de modelagem às seguintes tarefas, realizadas de forma iterativa:
• Identificação dos tipos de entidade;
• Identificação de atributos;
• Aplicação de convenção de nomes;
• Identificação de relacionamentos;
• Associação de chaves;
• Normalização para redução de redundância dos dados;
• Diversificação para melhoraria de desempenho.
Identificando tipos de entidade
Um tipo de entidade, ou simplesmente entidade, é conceitualmente similar ao 
conceito de orientação a objeto de uma classe – um tipo de entidade representa uma 
coleção de objetos similares. Um tipo de entidade pode representar uma coleção de 
pessoas, lugares, coisas, eventos ou conceitos.
Um modelo de dados contém diferentes tipos de entidades que são diferenciadas 
pelo formato dos identificadores. A classificação de cada uma dessas entidades pelo 
tipo ajudará você a definir quais perguntas devem ser feitas. Exemplos de entidades 
em um sistema de vendas incluem: cliente, endereço, venda, item e taxa. 
Se estivéssemos modelando classes, esperaríamos descobrir classes exatamente 
com esses nomes. No entanto, a diferença entre uma classe e um tipo de entidade 
é que classes possuem dados e comportamentos, e os tipos de entidade possuem 
apenas dados. Uma entidade normalmente descreve um conceito, tal como uma 
classe costuma modelar um conceito. Por exemplo, cliente e venda são dois concei-
tos diferentes, portanto, faz sentido modelá-los como entidades diferentes.
Para mais detalhes a respeito de tipos de entidades. Disponível em: http://bit.ly/2KLczgW
Ex
pl
or
Identificando atributos
Cada tipo de entidade será representado por um ou mais atributos de dados. 
Por exemplo, na Figura 1, pode-se observar que a entidade Foto possui atribu-
tos como ID, Título, Descrição etc. e, na Figura 2, que a tabela “Photo” possui 
16
17
colunas de dados correspondentes “ID”, “Title” e “Description” (uma coluna é a 
implementação de um atributo de dados em um banco de dados relacional).
Atributos devem ser coesos do ponto de vista do domínio da aplicação para com 
o negócio. Na Figura 1, decidimos que queríamos modelar o fato de fotos em mídia 
social comumente possuírem IDs, Títulos e Descrições diversas. Usar o nível de 
detalhe correto pode ter um impacto significativo no esforço de desenvolvimento, 
bem como em manutenção.
Aplicando convenções de nomes
As organizações devem dispor de normas e diretrizes específicas aplicáveis à 
modelagem de dados. Tais diretrizes devem incluir as convenções de nomenclatura 
para ambas, modelagem lógica e física. As convenções de nomenclatura lógica 
devem ser focadas na capacidade de leitura, e as convenções de nomenclatura fí-
sica refletirão considerações puramente técnicas. A ideia primordial aqui é que os 
desenvolvedores passem a seguir um conjunto comum de padrões de modelagem 
tendo em vista um projeto de software.
Identificando relacionamentos
No mundo real, entidades possuem relacionamentos entre elas. Por exemplo, 
usuários fazem upload de fotos em mídia social, interagem com conteúdos e são 
parte de um grupo de membros nesse serviço. Todos esses termos em letra mai-
úscula podem definir relacionamentos entre entidades. Sendo assim, os relaciona-
mentos entre entidades são conceitualmente idênticos aos relacionamentos (asso-
ciações) entre objetos.
A Figura 6, a seguir, descreve um MLD parcial para um sistema de compra on-line.
A primeira coisa que se nota são os vários estilos aplicados aos nomes dos relaciona-
mentos e papéis, em que diferentes relacionamentos requerem diferentes abordagens. 
mora
compra comprado por
cobrado em
endereço
de cobrança
endereço
de entrega
parte de descreve
é um
entregue em
Cliente
Venda
Item da
Venda
Serviço Produto
ItemEndereço
Figura 6 – Um modelo lógico de dados (notações Engenharia da Informação)
Para mais detalhes a respeito de tipos de atributos e relacionamentos.
Disponível em: http://bit.ly/2KLdDRYE
xp
lo
r
17
UNIDADE Conceitos Gerais em 
Modelagem da Informação
Precisamos também identificar a cardinalidade de um relacionamento, uma re-
presentação do conceito de “quantos” enquanto opcionalmente representa o con-
ceito de “se é obrigatória a existência da entidade”. Por exemplo, não é suficiente 
saber que usuários interagem com fotos. Mas também quantas interaçõesum usuá-
rio pode realizar, não? Quantas seriam? Nenhuma, uma ou várias? Além disso, os 
relacionamentos existem nos dois sentidos: não apenas usuários fazem interações, 
mas interações são realizadas por usuários. 
Para mais detalhes a respeito de cardinalidade. Disponível em: http://bit.ly/2OamJcS
Ex
pl
or
Isso nos leva a questões como: quantos usuários podem ser envolvidos em um determinado 
conteúdo e se é possível ter alguma interação com nenhum usuário envolvido?Ex
pl
or
Associando chaves
O conceito de chave é importante na modelagem de dados, pois implementa 
restrições que garantem a integridade referencial dos dados no banco de dados. 
Existem duas estratégias fundamentais para associar chaves às tabelas: em primeiro 
lugar, podemos associar uma chave natural, que é um ou mais atributos de dados 
existentes que são únicos para o conceito de negócio. Imaginemos, então, uma 
tabela Cliente. Tal tabela possui, de imediato, duas chaves candidatas, as colunas 
Número, Cliente e CPF. A segunda forma é introduzindo uma nova coluna, cha-
mada chave substituta, que é uma chave que não possui qualquer significado para 
o negócio. 
Para mais detalhes a respeito de chaves. Disponível em: http://bit.ly/34dEPAj
Ex
pl
or
Normalizando para reduzir redundância
A normalização é um método empregado para aumentar a qualidade do projeto 
de banco de dados. É também uma base teórica para a definição das propriedades 
das relações. Nesse processo, os atributos de dados em um modelo de dados são 
organizados para aumentar a coesão dos tipos de entidade. 
Em outras palavras, o objetivo da normalização de dados é reduzir e até eliminar 
redundância de dados, uma questão importante para desenvolvedores, pois é incri-
velmente difícil armazenar objetos em um banco de dados relacional que mantém a 
mesma informação em vários lugares (apresentando então redundância). A seguir, 
são resumidas as três principais regras de normalização, descrevendo como aumen-
tar os níveis de normalização em tipos de entidade.
18
19
Com relação à terminologia, um esquema de dados é considerado estar em um 
nível de normalização do seu tipo de entidade menos normalizado. Por exemplo, se 
todos os tipos de entidade estão na segunda forma normal (2NF), ou maior, então 
dizemos que o esquema de dados está na 2NF.
• Primeira Forma Normal (1NF): Quando uma entidade não contém grupos 
de dados repetidos;
• Segunda Forma Normal (2NF): Quando todos seus atributos que não são 
chaves primárias são completamente dependentes de sua chave primária;
• Terceira Forma Normal (3NF): Quando uma entidade está na 2NF e quando 
todos seus atributos são diretamente dependentes da chave primária.
Para mais detalhes a respeito de normalização. Disponível em: http://bit.ly/2XEnJJA
Ex
pl
or
Afinal, por que normalização de dados?
Ex
pl
or
A vantagem de ter um esquema de dados altamente normalizado é que a in-
formação é armazenada em um lugar apenas, reduzindo a possibilidade de dados 
inconsistentes. Além disso, esquemas de dados altamente normalizados em geral 
são conceitualmente mais próximos dos esquemas orientados a objeto, haja vista 
que os objetivos da orientação a objetos, de promoção de alta coesão e pouco aco-
plamento entre as classes, resulta em soluções similares. 
Isso geralmente torna mais simples mapear os objetos para o esquema de da-
dos. Infelizmente, a normalização normalmente traz um custo para o desempenho.
Por exemplo, todos os dados para uma interação de venda em um e-commerce 
estarão armazenados em uma só linha (assumindo que vendas poderão ter até dois 
itens), simplificando o acesso. Assim, podemos rapidamente determinar a quanti-
dade total de uma venda lendo uma única linha da tabela.
Diversificando para melhoria de desempenho
Esquemas de dados normalizados, quando colocados em produção, normalmen-
te sofrem problemas de desempenho. Isso faz sentido, visto que as regras de nor-
malização focam em reduzir redundância de dados, não em melhorar desempenho 
do acesso aos dados. Uma parte importante da modelagem de dados é diversificar 
porções do esquema de dados para melhorar tempo de acesso aos dados.
Tem-se de observar que, se o projeto inicial e normalizado dos dados atinge o 
desempenho necessário para a aplicação, nada precisa ser feito. A diversificação 
deve ser aplicada apenas quando os testes de desempenho mostram que há um 
problema com os objetos.
19
UNIDADE Conceitos Gerais em 
Modelagem da Informação
Modelando dados de forma evolucionária ou ágil
Modelagem de dados evolucionária é a modelagem de dados realizada de forma 
incremental. Já a modelagem de dados ágil é a modelagem de dados evolucionária 
feita de forma colaborativa. 
Os objetivos desta unidade foram capacitar você quanto ao processo de mo-
delagem de informações, de maneira resumida, e voltada para os mais variados 
perfis de ocupações em tecnologia da informação. Espera-se que os conceitos aqui 
apresentados lhe impulsionem a trabalhar cada vez mais com projetos orientados 
a dados para resolução de problemas de negócios complexos. Com certeza, com 
o tempo e prática necessários, este material pode servir como um guia de estudo 
para qualquer perfil que queira melhorar suas habilidades de modelagem.
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Leitura
Effective Practices for Modeling and Documentation
http://bit.ly/37mFS2W
An Association For All IT Architects
http://bit.ly/37vRLUa
Uma visão sintética e comentada do Data Management Body of Knowledge (DMBOK)
http://bit.ly/37sFVdv
O que é um diagrama entidade relacionamento?
http://bit.ly/2KIvCZ2
MER e DER: Modelagem de Bancos de Dados
http://bit.ly/35rau1v
Modelagem de dados: modelo conceitual, modelo lógico e físico
http://bit.ly/35r5Q3s
Tutorial Completo de Modelagem de Dados
http://bit.ly/37wbOSs
21
UNIDADE Conceitos Gerais em 
Modelagem da Informação
Referências
ALLEMANG, D.; HENDLER J. Semantic Web for the Working Ontologist: 
Effective Modeling in RDFS and OWL. Morgan Kaufmann Publishers Inc. San 
Francisco, CA, USA, 2008. 
BOOCH, G.; RUMBAUGH, J; JACOBSON, I. The Unified Modeling Language 
user guide. Addison-Wesley, 1997.
DAMA-DMBOK. The DAMA Guide to the Data Management Body of 
Knowledge. Bradley Beach, NJ: Technics Publications, 2010.
GODINEZ, M.; HECHLER, E. et al. The Art of Enterprise Information 
Architecture. A Systems-Based Approach for Unlocking Business Insight. EUA: 
IBM Press, 2010.
HAY, D. C. Data Model Patterns: Conventions of Thought. New York, NY. 
Dorset House Publishing, 2011.
NETO, A. C. D. Banco de Dados Relacionais. Tutorial Revista SQL Magazine. 
2011. Disponível em: <https://www.devmedia.com.br/modelagem-de-dados-
tutorial/20398>.
TEOREY, T. J. Database modeling and design: logical design. 5. ed. Burlington, 
Mass, Morgan Kaufmann Publishers, Amsterdam, Boston: Elsevier, 2011.
22