Modelagem da

Informação
 Material Teórico
Conceitos Gerais em Modelagem da Informação

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.

OBJETIVOS DE APRENDIZADO
• 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;
• Desmistificar os termos e notações mais comuns na área;
• Qualificar os alunos para lidarem com equipes ágeis e adotarem verdadeiramente uma
cultura de dados em suas vidas profissionais.
 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:
Conserve seu
material e local de
estudos sempre
organizados.
Aproveite as
Procure manter indicações
contato com seus de Material
colegas e tutores Complementar.
para trocar ideias!
Determine um Isso amplia a
horário fixo aprendizagem.
para estudar.

Mantenha o foco!
Evite se distrair com
as redes sociais.

Seja original!
Nunca plagie
trabalhos.

Não se esqueça
de se alimentar
Assim: e de se manter
Organize seus estudos de maneira que passem a fazer parte hidratado.
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.
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.
Explor

“Um modelo é uma descrição abstrata que esconde certos detalhes enquanto ilumina outros.”

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
 É 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
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-
tivos relacionamentos, 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).
Explor

“Modelos são usados para organizar o pensamento humano na forma de explicações.”

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
Explor

solução toma forma.”

Fonte: The Unified Modeling Language User Guide

10
 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.
Explor

Modelagem de Dados – Modelos Conceitual, Lógico e Físico: https://youtu.be/ZX7EuRWRdZg

Embora MLDs e MFDs pareçam similares, e eles de fato o são, o nível de detalhes que cada
Explor

um deles modela pode ser significativamente diferente. Isso porque o próprio objetivo ao se
utilizar de cada diagrama é diferente.

11
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
 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
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ção dos 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.
Explor

Para mais detalhes o site da ORM pode ser consultado. Em: http://bit.ly/2QEhFzj

Cliente mora em Endereço

(nome) (rua)

Claudio Dias Rua XXX, 123

Juliana Campos Rua YYY, 897
Juliana Campos Av. ZZZ, 8272
João Silva 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
 Chen
N 1
Pessoa Localização

IDEF1X Pessoa Localização

Bachman
Nasceu em
Pessoa Localização
Local de nascimento

Martin / IE /
Crow’s Foot Nasceu em
Pessoa Localização
Local de nascimento

Min–Max / ISO
(1,1) Nasceu em
Pessoa Localização
Local de nascimento (0,N)

UML << Relacionamento >>

Nasceu em >
0..N < Local de nascimento
Pessoa Localização
1

Figura 5 – Comparativo da representação de modelo conceitual

Explor

Resumo de sintaxe em quatro diferentes notações: http://bit.ly/2rMTeW9

Para mais detalhes é de interesse que se conheça mais a fundo os trabalhos de Chen,
Explor

Bachman, Martin (EI) e Barker. Disponível em: http://bit.ly/2KIvCZ2

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

Para mais detalhes a respeito de tipos de entidades. Disponível em: http://bit.ly/2KLczgW

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
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 Cliente Serviço Produto

compra comprado por

é um
cobrado em Item da
Endereço Venda Item
endereço parte de Venda descreve
de cobrança
endereço entregue em
de entrega

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.

Explor

Disponível em: http://bit.ly/2KLdDRY

17
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ções um 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.
Explor

Para mais detalhes a respeito de cardinalidade. Disponível em: http://bit.ly/2OamJcS

Isso nos leva a questões como: quantos usuários podem ser envolvidos em um determinado
Explor

conteúdo e se é possível ter alguma interação com nenhum usuário envolvido?

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

Para mais detalhes a respeito de chaves. Disponível em: http://bit.ly/34dEPAj

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

Para mais detalhes a respeito de normalização. Disponível em: http://bit.ly/2XEnJJA

Explor

Afinal, por que normalização de dados?

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
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
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
Conceito de Banco de Dados
http://bit.ly/35p2aiQ
Tutorial Completo de Modelagem de Dados
http://bit.ly/37wbOSs

21
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