Modelagem de Dados

Modelar significa criar um modelo que explique as características de funcionamento e comportamento de

um software a partir do qual ele será criado, facilitando seu entendimento e seu projeto, através das
características principais que evitarão erros de programação, projeto e funcionamento. É uma parte importante
do desenho de um sistema de informação.

Os modelos de dados são ferramentas que permitem demonstrar como serão construídas as estruturas
de dados que darão suporte aos processos de negócio, como esses dados estarão organizados e quais os
relacionamentos que pretendemos estabelecer entre eles.[1]
A abordagem que se dispensa ao assunto normalmente atende a três perspectivas:

 Modelagem Conceitual: é usada como representação de alto nível e considera exclusivamente o ponto de
vista do usuário criador dos dados;
 Modelagem Lógica: agrega mais alguns detalhes de implementação.
 Modelagem Física: demonstra como os dados são fisicamente armazenados.

Quanto ao objetivo, podemos identificar as seguintes variações:

 modelagem de dados entidade-relacionamento (leitura, construção e validação dos modelos);

 modelagem de relacionamentos complexos, grupos de dados lógicos e ciclo de vida das entidades;
 modelagem de dados corporativa;
 modelagem de dados distribuídos (cliente/servidor);
 modelagem e reengenharia de dados legados e
 modelagem de dados para Data Warehouse.
 O banco de dados é utilizado para guardar informações.

Modelagem Dimensional

DADOS NORMALIZADOS X DADOS DESNORMALIZADOS

Os dados normalizados estão na terceira forma normal, utilizada em banco de dados relacional. Se você
fez alguma faculdade em TI, provavelmente aprendeu sobre esse tipo de modelagem.
Eles permitem um armazenamento consistente e acesso eficiente aos dados. Essa forma reduz a
redundância de dados e as chances de inconsistência. Esse estilo de banco tem como foco inserir, alterar e
deletar os dados.

Já os desnormalizados, que é com o que nós trabalhamos, têm foco na consulta.

As consultas feitas em bancos de dados totalmente normalizados têm um mau desempenho, e para isso se usa
a desnormalização: para melhorar o desempenho das consultas.
Mas claro, com um custo: com ela não temos a garantia de consistências dos dados, além de termos um
banco muito maior.
O objetivo dos dados desnormalizados é entregar informação, é um sistema informacional, feito para ter uma
consulta rápida. Vai ter redundância de dados, mas vai ser mais rápido.

MAS COMO FUNCIONA ISSO?

Em um banco normalizado, ou relacional, temos diversas tabelas, cada uma com sua chave primária e
informações. Por exemplo, temos uma tabela “cidade” com o ID da cidade e o nome dela, e outra tabela “cliente”
com o ID do cliente, o nome dele e a cidade onde mora. Mas nesse último item, ao invés de termos o nome da
cidade registrado, temos o ID referente àquela cidade na tabela “cidade”.

Isso serve para evitar a redundância, evitando a repetição do mesmo nome diversas vezes e garantindo
que o nome da cidade estará escrito sempre da mesma forma para todos os clientes.
 No caso dos dados desnormalizados, nós temos o nome da cidade registrado na tabela de clientes, uma
vez para cada cliente que morar naquela mesma cidade, o que aumenta muito o tamanho do banco e não garante
tanta consistência dos dados.
Num modelo transacional, ou sistema operacional, você tem que ter integridade dos dados, eles não
podem se repetir. Já no modelo dimensional, eles podem. Na verdade, eles devem.
Os mesmos dados se repetem em vários lugares, porque nesse caso ele é desenhado para melhorar o
desempenho das consultas, porque o Data Warehouse é feito para consulta, enquanto o operacional é feito para
transação.

ENTENDI. MAS E A MODELAGEM DIMENSIONAL?

O modelo dimensional existe há muito mais tempo que você imagina, e provavelmente, você que não
conhece modelo dimensional, já até usou e não sabe.
Até para utilizar ferramentas, na parte de modelar os metadados ou cubos OLAP, você vai precisar
entender de modelagem dimensional, a não ser que você utilize outro tipo de arquitetura de modelo de dados.
Existem dois tipos de metodologias de modelagem de dados usadas no Data Warehouse, a Snowflake e
a Star Schema, que é a mais utilizada.

DATA WAREHOUSE – O QUE É STAR SCHEMA?

Star schema ou esquema estrela, idealizado por Ralph Kimball, é o modelo mais utilizado
na modelagem dimensional para dar suporte à tomada de decisão e melhorar a performance de
sistemas voltados para consulta.
O esquema estrela é composto no centro por uma tabela fato, rodeada por tabelas de dimensão,
ficando parecido com a forma de uma estrela. A ideia é propor uma visão para modelagem de base
de dados para sistemas de apoio à decisão, que é o caso do Data Warehouse.
As metodologias usadas para criação de Data Warehouse são Star Schema e Snowflake, que é
defendido pelo Bill Inmon.
O Snowflake também é projetado para suportar tomada de decisão, mas economizando espaço
em disco. Para o Star Schema, o Snowflake é apenas mais um tipo de dimensão.
Embora o Star Schema ocupe mais espaço em disco, ele é mais fácil de implementar e acabou
sendo mais utilizado porque além de hoje em dia o espaço ser muito barato, ele permite entregar
projetos por pedacinhos. Você pode criar um assunto ou departamento em uma estrela para só depois
projetar outro, e assim por diante.
Na maioria esmagadora dos projetos, Star Schema é uma excelente escolha.

ONDE ISSO ENTRA NO DATA WAREHOUSE?

O Data Warehouse é um conjunto de modelos, vários modelos estrelas.

Embora os Star Schemas sejam feitos pensando em um modelo de entrega rápido, o foco é sempre no
Data Warehouse, para depois conectar as dimensões, porque você não pode ter dimensões iguais.
No modelo de Star Schema você pode entender que o Data Mart é uma coisa mais processual, focado
em um assunto só.

E O QUE VAI EM UM STAR SCHEMA?

Tabela Fato
A tabela fato armazena o que ocorreu, é o fato propriamente dito, por isso ela tem esse
nome, porque é o fato ocorrido. A tabela fato está sempre ligada a duas ou mais dimensões, não existe
tabela fato com menos de duas dimensões.
A fato é a principal tabela do Data Warehouse, e você pode ter uma ou mais tabelas fato.
 Essa tabela armazena 2 coisas:
 Os fatos ocorridos, ou seja, as métricas
 As chaves para as dimensões
Ou seja, a fato é composta por alguma métrica e os códigos das dimensões.

E o que é métrica?

Métrica é também chamada de quantificador ou medida. Alguns chamam de KPI, mas KPI
também pode ser considerado um cálculo entre duas métricas.

Elas são utilizadas para metrificar algo e sempre são números, porque precisam ser
contáveis. Esses números são provenientes de transações da empresa.

Por exemplo:
Hoje eu tomei 5 cafés

Métrica: quantidade de cafés bebidos (5 nesse caso)

Dá para fazer uma análise com ela, por exemplo, no tempo: nos últimos 30 dias, que dias eu tomei
mais café?

Tudo que a empresa for mensurar é uma métrica. Na maioria das vezes, a métrica vai ser o que o
usuário quer medir.

Pergunta para o usuário: o que tu quer medir, que informação quer ver na tela?
Normalmente o cara vai responder: quero ver as vendas, meus seguidores no twitter, quanto que a
gente tem de fluxo de caixa etc…
Você identifica muito fácil quais são as métricas só com essas perguntas.

Então qual que é a diferença de uma métrica para um KPI?

O KPI na sua essência são duas métricas relacionadas entre si, pode ter sido uma dividida
ou multiplicada pela outra, e geralmente precisa ter meta.
 Por exemplo:
a quantidade de café que eu tomo por dia dividido pela quantidade de horas que eu durmo.
Porque quanto mais café eu tomo, menos eu durmo.
Dá para criar um KPI do meu sono de acordo com a quantidade de café que eu tomo.

Tabela dimensão
Dimensão, também chamado de qualificador, descreve o fato ocorrido, ela contém as características
do evento.
Por exemplo, quando eu faço uma venda, quero saber por onde a venda foi feita, que produto foi
vendido ou para quem.

Elas vão qualificar, classificar ou descrever os dados que estão nas fatos, ou seja, as métricas.
Para identificar as dimensões, normalmente perguntamos pelo que o usuário quer mensurar uma
informação. Elas vão ser todas e qualquer informação que qualifique uma métrica ou medida.

Por exemplo:
Preciso medir as vendas.
Ótimo, mas pelo quê?
Pela empresa / pelo produto / pelas filiais / por dia

Você também pode usar a pergunta de quais filtros o usuário gostaria de ter naquela visão.
Por que filtros?
Imagina que você tem uma tela com um menuzinho e o usuário pode escolher: eu quero um relatório
por produto.
Aí ele clica naquela setinha e tem a lista de todos os produtos. Ele seleciona um deles e mostra um
gráfico com as vendas só de tênis, por exemplo.
Esses filtros na maioria dos casos vão ser as dimensões. E embora nem todo filtro seja uma dimensão,
podem ser dimensões candidatas, que ainda não foram colocadas no modelo mas são candidatas a se
tornar dimensões.

As dimensões armazenam 3 coisas:

 A Surrogate Key
 A Natural Key
 Os atributos

O quê?
Para ser rápida, a fato só armazena os número brutos. O atributo é o que qualifica as métricas, porque
elas jogadas lá na fato sozinhas não servem de nada, não dá para tomar decisão nenhuma.
Os atributos podem ser campos como cidade, estado, país etc.
Quanto às chaves, a Surrogate Key é uma Primary Key na dimensão. É uma chave artificial auto
incremental, ou seja, toda vez que ela é chamada, adiciona um número e vai somando.
Já a Natural Key é a Primary Key daquele dado na origem ou legado, é o que você vai usar para
identificar de onde aquele dado veio.

E o que você precisa saber antes de poder criar essas tabelas

Hierarquia

Hierarquia é o conjunto de atributos que possui uma ordem lógica do maior ao menor nível.
A hierarquia balanceada, que é a mais utilizada, é qualquer classificação que tenha como base as
relações entre superiores e dependentes.
Por exemplo, do avô ao neto ou do general ao soldado.
Ela requer sempre uma relação de pai-filho, onde o superior pode ter zero, um ou muitos dependentes,
mas os dependentes devem ter um e um único superior.
A hierarquia existe apenas nas dimensões, porque a métrica é só um valor, e quem vai dizer se esse
valor está correspondendo a um determinado nível da hierarquia é o atributo.
O comum é existir apenas uma hierarquia por dimensão, mas pode existir múltiplas se for necessário.

Grão
O grão, também chamado de detalhe, é o menor nível da hierarquia da dimensão. É a informação
base, o menor detalhe da informação.
É extremamente importante entender o que é o grão e como definir ele, porque se for mal planejado,
vai acabar com todo o projeto.
Mas o que é esse grão?
Em uma dimensão de tempo, nós podemos ter uma hierarquia com ano, mês e dia. O dia é o menor
nível, isso é o grão.
Em uma dimensão com diretoria, gerência, departamento e pessoa, a pessoa é o menor nível de
detalhamento.
E por que é tão importante?
Ele é o nível mais atômico, o mais detalhado, e é no nível mais atômico em que será armazenada a
informação, sem a oportunidade de “descer” mais um nível.
Imagina que o mês seja meu grão. Nesse caso, só posso contemplar ano e mês. Se depois lá na frente
perceber que preciso descer para dia, não vai dar.
Aí precisa mexer em tudo, refazer as cargas e rever todo o modelo, porque o grão parou no mês.
Você precisa identificar qual o menor dado necessário, porque quanto menor for o nível do grão, mais
ETL terá para fazer e mais demorado será, então não adianta colocar sempre o menor possível para
tentar evitar o erro.

E COMO ISSO TUDO SE ENCONTRA?

Depois que você definiu suas dimensões, vai fazer um join com a tabela fato. É nesse momento
que a Foreign Key da fato vai lá e conecta na Surrogate Key da dimensão.
 Fica assim:

Agora você sabe que aquele “200,00”, que é a métrica, pertence ao produto de chave “2” na dimensão
de produto.
E assim você vai pegando as Surrogate Keys de todas as dimensões e dando sentido àquela métrica
na tabela fato.
É importante você entender todos esses conceitos antes de começar a pôr a mão na massa, pois mesmo
utilizando ferramentas, você ainda vai precisar entender a teoria para modelar o Star Schema.
Então primeiro entende bem essa parte que no próximo post vou aprofundar um pouco mais no
assunto e trazer um passo a passo para a criação do Data Warehouse.

Data Warehouse – Passo a Passo para Modelar um

Data Warehouse
Quer saber o segredo para, ao invés de demorar 6 meses na entrega de um Data
Warehouse, levar 1 mês só?

O Agile Data Warehouse Design é uma metodologia de desenvolvimento ágil para criação
de Data Warehouse.
A ideia é diminuir as horas e horas de reuniões improdutivas e focar no que realmente
precisamos levantar para desenhar o Data Warehouse.
Mas vamos por partes.
Hoje em dia mais ninguém tem tempo para esperar. E se para nós é assim, imagina para o
cliente que precisa tomar uma decisão e não tem os benditos dados que precisa?

Isso nos deixa com 2 problemas:

1. O cara não está disposto a esperar 1 ano até o Data Warehouse estar pronto
2. Ele não vai ter tempo para fazer todas as milhares de reuniões que você precisa

E COMO EU RESOLVO ISSO?

Vou apresentar aqui o 5W3H. Se você teve algum contato com a área de administração,
já deve ter ouvido falar no 5W2H. A ideia é parecida, mas fiz uma adaptação nela para
metodologias ágeis de desenvolvimento de Data Warehouse.
Para isso eu monto um mapa mental. Obviamente, você pode utilizar outro tipo de
ferramenta. Eu utilizo o mapa mental porque fica organizado e fácil de visualizar, o que é
bom tanto pra você como para o cliente.

Fica assim:

A aparência é amigável e com perguntas que os Key Users estão acostumados a ver no dia
a dia.
Lembra sempre que a obrigação da tomada de decisão correta é sua. Embora o cliente deva
saber o que ele quer, você, como consultor, tem que saber extrair as melhores respostas.
Por mais que a criação de um Data Warehouse pareça simples ou cotidiana para você, para
o cliente não é, então ele nem sempre vai saber te dar as melhores respostas.

TÁ, MAS COMO EU USO ISSO?

Eu sempre compartilho o próprio mapa mental online com o cliente, assim não precisa estar
todo mundo junto naquelas benditas reuniões que é sempre difícil de colocar todo mundo
no mesmo lugar no mesmo horário.
A sacada é que as pessoas recebam esse mapa primeiro, antes da reunião, para começar a
entender o que você precisa. Assim, elas mesmas já podem começar a preencher algumas
informações direto no mapa mental.
Vai tentar pegar o tempo do VP, diretor financeiro ou gerentes, os caras estão sempre
correndo. Aí você compartilha uma ferramenta assim, bem simples. Já peguei vários clientes
que entre uma reunião e outra abriam o aplicativo, davam uma olhada, comentavam alguma
coisa e viam o que o resto do time já tinha colocado.

Então todo mundo estava olhando a mesma coisa e sem nenhuma reunião até agora.
Quando você finalmente for fazer a reunião, pode abrir esse mesmo mapa mental que já
está com as respostas do pessoal e começar a bater as perguntas. E mesmo que não dê
tempo de todos preencherem tudo, pelo menos já vão saber do que se trata, não vão estar
tão confusos na reunião. A gente trabalha com pessoas, precisamos entender isso. Aí na
reunião você começa a passar as perguntas uma a uma.

Eu coloquei as perguntas na ordem que eu prefiro fazer, porque foi a ordem que identifiquei
ser a melhor nos projetos que usei essa estratégia. Mas é claro, você pode trocar para como
fizer mais sentido no seu projeto.

Algumas perguntas não fazem sentido para determinados tipos de negócio e vai ter outras
que o cliente realmente não quer porque não interessa para ele, então tem coisas que você
pode pular sem problema nenhum.

AGORA, O PASSO A PASSO

A primeira pergunta que você deve fazer é a do centro.

Qual fato aconteceu?

Vou usar um exemplo aqui de venda.

Qual é o fato que aconteceu? Uma venda

E aí isso já é a tabela fato? Pois é, a tabela fato se chama fato porque aconteceu um fato.
Depois, você vai seguindo de acordo com os números.

#1 – What – o quê / do quê?

Aqui você pode usar um template para completar e deixar mais fácil de entender a frase:
Template: Aconteceu _________. Do quê?
Vai ficar como?
Aconteceu uma venda. Do quê? De Coca-cola

Aí já respondemos a primeira pergunta.

É só isso? É só isso.
Depois é só ir aplicando o mesmo estilo de template para todas as perguntas.

#2 When – quando?
Template: Aconteceu _________. Quando?
Aconteceu uma venda. Quando? 31/02/2017
#3 Where – onde?
Template: Aconteceu _________. Onde?
Aconteceu uma venda. Onde? Na loja de São Paulo

#4 Who – quem?
Nesse podemos ter várias interpretações. Você precisa entender o conceito e então ir
colocando de acordo com o negócio em questão. “Quem” é a pessoa envolvida, e ela
pode estar envolvida com o fato em papéis diferentes.
Alguns exemplos:

Template:
Aconteceu _________. Para quem?
Aconteceu _________. Quem fez?
Aconteceu _________. Quem entregou?
Para quem foi a venda? Pro Piton
Quem fez a venda? Vendedora Joana
Quem entregou? TNT Transportadora Mercúrio

#5 How – como?

Template: Aconteceu _________. Como?

Aconteceu uma venda. Como? Através do site
#6 Why – por quê?
Template: Aconteceu _________. Por quê?
Aconteceu uma venda. Por quê? Por causa de uma promoção de natal

#7 How often – com que frequência?

Template: Aconteceu _________. Com que frequência?

Aconteceu uma venda. Com que frequência? 2x por mês

Aqui a frequência é diferente da data, porque a data é quando cada uma das vendas
aconteceu, e a frequência mostra o espaço de tempo entre elas.
Com a frequência, a gente consegue saber qual a periodicidade da carga, com que
frequência vai precisar carregar os dados.

#8 How many – quanto / quantas vezes?

Aqui é onde você vai identificar as métricas.

Template: Aconteceu _________. Quantas Vezes?
Aconteceu uma venda. Quantas Vezes? 200 (vendas)
 Só com essas perguntas você já tem uns 80% do seu modelo dimensional pronto.

E OS OUTROS 20%?
Agora você precisa definir as dimensões e seus atributos.
Mas é muito simples fazer isso já tendo o mapa preenchido dessa forma. É diferente de
quando você começa um projeto e vai pensando em dimensão por dimensão e perdendo
um baita tempo em entrevistas.
Agora imagina que você já tem todas essas informações e os envolvidos do fato que
aconteceu presentes.
Quando aconteceu uma venda, quem são os envolvidos na venda? O time de
marketing, time de vendas, talvez o time financeiro também faça alguma parte.
Agora, sua missão é: depois que toda essa galera estiver reunida e entender o conceito
desse mapa mental, cada um pode colocar o que entende disso para então chegar em um
consenso.

MAS NA PRÁTICA COMO É?

Aqui você começa a fazer as perguntas para saber o que os Key User esperam de uma
dimensão, por exemplo, de produtos (que você identificou lá na pergunta #1).
Você nem precisa falar em dimensão para não complicar a conversa.
Pergunta assim: Nessa primeira pergunta você respondeu “Coca-cola”, que é um produto.
O que você gostaria de analisar do produto?
Você vai pegar informações como:
 Coca-cola é o nome do produto
 Você vai precisar também do código daquele produto para fazer algum relatório
 Aí vem o cara lá do marketing e diz que eles precisam saber a marca desse produto
 O cara da logística vai dizer que precisa saber qual o peso do produto para planejar o
caminhão, para saber se tem espaço em armazenagem, e inclusive precisa ter a unidade de
medida daquele produto
 Depois vem o financeiro, que quer saber qual o preço unitário do produto
 Fazendo as perguntas certas fica fácil de entender o que o negócio precisa. É claro que você
sabe que essa dimensão depois vai ter uma Surrogate Key e uma Natural Key, mas não é o
momento de pensar nisso, por enquanto você está falando com o Key User, que é o cara
de negócio, e essa é a abordagem mais simples e rápida possível.

ALERTAS: 2 COISAS QUE PODEM ESTRAGAR SEU PROJETO

1. Às vezes algum diretor ou gerente não vai poder estar na reunião ou participar do
levantamento de requisitos e vai mandar alguém para representar ele. Esse diretor ou
gerente que não foi é um Key User, e é muito importante que a pessoa que estiver no lugar
dele tenha conhecimento o suficiente do negócio para responder essas perguntas. Se não,
você vai acabar com informações capengas.
2. Projeto de Data Warehouse não é projeto de TI. Projeto de Data Warehouse é
projeto de negócio. Já to careca de ver projeto de Data Warehouse/BI em que a equipe
fica socada junto com a TI dentro de um porão achando que é só pegar dados e jogar em
um banco de dados. Cagada total.
Esse planejamento é extremamente importante. Empresas grandes e mais maduras
já entendem o poder disso. Várias das empresas grandes pelas quais eu passei têm essa
ideia de business first, então é sempre o negócio que está em foco, e não a TI. O importante
agora não é saber se o cara já tem o dado coletado, se o banco aceita select ou se é MDX,
isso é para outra hora.
Eu usei o mapa mental como exemplo porque é como eu gosto de usar, mas você precisa
entender mesmo é a ideia para poder aplicar da forma que for melhor para você e o cliente.
Se entender a estratégia, vai poder aplicar ela da forma que for, porque é muito simples,
basta seguir esse passo a passo e você vai conseguir entregar um Data Warehouse muito
mais rápido e menos suscetível a falhas do que está acostumado.

Data Warehouse – Tipos de Métricas

udo que a empresa for mensurar é uma métrica. Na maioria das vezes, a métrica vai ser o que o
usuário quer medir. Pode ser também chamada de quantificador ou medida. Existem 4 tipos de
métricas que você pode usar no seu Data Warehouse.
Se você tiver alguma dúvida sobre o que é uma métrica, aconselho primeiro ler o post sobre Star
Schema, onde explico o que é métrica e qual o papel dela na modelagem.
Os 4 tipos de métricas são:
 Aditivas
 Derivadas
 Semi-aditivas
 Não-aditivas
E para que serve isso?
Para você saber que tipo de cálculos e cruzamentos pode fazer com cada uma delas. Por mais que
todas as métricas sejam numéricas, elas tem significados e interpretações diferentes, e é para
identificar isso que servem os tipos.
Mas vamos para cada um deles…

MÉTRICA ADITIVA
São as métricas que permitem operações matemáticas como soma e subtração por todas as dimensões.
 Dentro da fato há diversas linhas, e as métricas aditivas devem poder somar todas elas. É obvio,
todas podem ser somadas se eu quiser, mas ela precisa fazer sentido.

Um exemplo: Nessa tabela eu

tenho a quantidade da venda, ou seja, a quantidade de coisas que foram vendidas.
E essas são as dimensões nas quais ela conecta:

Olhando a primeira linha da fato,

pelas chaves você pode ver nas dimensões que aquele 200 é do produto Coca-Cola e da data
10/12/2016.
Nas métricas aditivas, o valor da métrica é representativo em todos os cruzamentos:
Quanto foi vendido no dia 10/12/2016? 200.
Quanto foi vendido de Coca-Cola? 200.
Nesse caso, se você somar as 3 linhas da fato, vai ter 700. Então se quiser saber quanto foi vendido
no total em que há registros, você sabe, foi 700. E se quiser saber quantas Coca-Colas foram vendidas
nesse mês, 700 também.
Alguns exemplos de métricas aditivas:
 Quantidade de vendas
 Valor da venda (se não for calculado)
 Quantidade de colaboradores
 Quantidade de demissões
 Quantidade de admissões
Todas essas métricas que podem ser somadas independentemente de onde estiverem cruzando. Ela
tem que fazer um cruzamento completo e perfeito na linha da fato, então a métrica precisa fazer
sentido com cada uma das dimensões sozinhas.
É a métrica mais simples que conhecemos.

MÉTRICA DERIVADA
É uma métrica calculada, uma métrica que você calcula para ter um segundo número. Esse cálculo é
sempre em cima de métricas que já estão na fato, não no que está no legado.
São métricas que já estavam na fato e que são calculadas, criando uma nova métrica, que chamamos
de derivada.
Exemplo de métrica derivada:

Nesse exemplo, a métrica derivada é a multiplicação da quantidade da venda com o preço unitário da
dimensão de produto.
Ela pode ser armazenada diretamente na fato ou calculada em tempo de execução nos cubos, que
também vou fazer um post explicando o que são.
A diferença básica entre armazenar no Data Warehouse ou deixar para ser calculada em tempo de
execução, é o seguinte:
No Data Warehouse quem fará esse cálculo é o time de ETL, ou seja, na hora da integração, se
aquela métrica for derivada, já vai ser calculada antes de ser armazenada.
Quando você salva as métricas base, na hora de fazer as análises, o cálculo é feito em tempo de
execução.
Qual a diferença na prática?
O cálculo vai utilizar recursos computacionais, de servidores e tudo mais. O cubo vai ter que calcular
isso para você. Quando está armazenada no Data Warehouse, esse procedimento já foi realizado.
E qual o melhor?
Não tem resposta certa, porque vai da estratégia de como você quer ver a informação e de como
chegar nela.
Por exemplo, eu já peguei casos que estava muito difícil para a ferramenta calcular em tempo de
execução, demorava muito porque era um cálculo bem complexo.
O que eu fiz? Fiz o cálculo no ETL. Antes de dar a carga final da fato, peguei a métrica que já tinha
sido carregada, que era uma aditiva, fiz o cálculo que tinha que ser feito e inseri de novo, aí ela virou
uma métrica derivada e aumentou muito a velocidade das consultas.
Uma coisa é você esperar 5 minutos no ETL e outra coisa é o usuário clicar no relatório e ele levar 5
minutos para abrir. Esse tipo de coisa você não pode deixar acontecer.
Então coloco tudo no Data Warehouse? Não.
Depende da estratégia, por isso que eu explico sempre o conceito, para você saber o que fazer. Nesse
caso que eu citei foi muito bom ter colocado no ETL, mas houveram casos que precisei deixar as
métricas para serem calculadas direto na ferramenta.
Por quê?
Métricas de negócio. Eram diversas, e tudo com base em métricas aditivas da fato venda. Na fato, eu
tinha quantidade de vendas, valor da venda, e acabou por aí.
As métricas derivadas que o negócio demandava eram mais de 30, então deixei que elas fossem
calculadas na ferramenta, porque a forma como o cliente queria analisar mudava, uma hora ele queria
analisar por tempo, outra hora por produto e outra por vendedor.
Quando você chumba uma métrica no Data Warehouse, precisa entender que também está chumbando
aquele cruzamento. Quando precisar de um novo valor em cima daquela métrica para um novo
cruzamento, vai ter que recalcular toda a fato no ETL.
Então quando são projetos muito complexos, a gente opta sempre por deixar as métricas derivadas
para as ferramentas do BI fazer.
Uma coisa muito importante que sempre faz a gente optar por colocar as métricas derivadas na
ferramenta de BI é que quando todas as métricas estão disponíveis limpinhas lá no cubo, o usuário de
negócio pode fazer um self-service BI e o gráfico em que ele está trabalhando vai se movendo
conforme ele faz as análises.
Essa possibilidade de ficar se movendo e mostrar os cálculos que estão acontecendo em tempo real é
porque a métrica derivada é calculada nas análises, ou seja, ficam prontas no cubo.

MÉTRICA SEMI-ADITIVA
Para exemplificar, fiz essa tabela de uma fato com saldo de conta corrente.

Uma visão geral sobre essa fato: temos a dimensão de tempo, de cliente e de agência. Também temos
algumas métricas: entrada, saída, saldo e a diferença percentual entre as entradas e saídas.
A entrada é uma métrica aditiva, ela pode somar todas as linhas, aí temos 14.620,00 de entradas. E
podemos cruzar esse dado com todas as dimensões. A saída é a mesma coisa, ela pode ser somada e
cruzada com todas as dimensões. E a métrica de saldo, que nesse caso é a entrada menos a saída.
Por exemplo:
No dia 1° de março, na conta do Piton, na agência ITAU-SP01, entrou R$1.500,00 e saiu R$300,00,
ficando com um saldo de R$1.200,00.
Nesse mesmo dia, na mesma conta, não entrou nada e saiu R$400,00. O saldo ficou R$800,00.
De novo no mesmo dia, saiu mais R$200,00 sem entrar nada, ficando com o saldo de R$600,00. Nesse
mesmo dia também aconteceram transações de outras pessoas. Na conta do Robson, entrou
R$2.500,00 e saiu R$700,00, ficando com o saldo de R$1.600,00.
Se somarmos todas as linhas, vamos ter um resultado de 14.420,00, mas isso não faz sentido, porque
no mesmo dia, tivemos várias transações em uma mesma conta, e o saldo do Piton não é a soma de
todos os valores. Se somarmos 1.200 + 800 + 600, vamos ter 2.400, enquanto o saldo real é 600.
Então o que faz sentido somar? A última movimentação de cada conta naquele dia, aí vou ter
12.420,00.
Resumidamente, o que isso quer dizer? Que métrica semi-aditiva pode ser somada por todas as
dimensões exceto a tempo.
Você só vai conseguir somar pela tempo se colocar um filtro que diga que ele só pegue o último
registro.
Saldo de estoque e saldo bancário, quando representado de forma monetária, são métricas semi-
aditivas bem comuns, porque são aditivas em todas as dimensões, exceto na tempo.
MÉTRICA NÃO-ADITIVA
São métricas tipo percentual, algum cálculo feito em tempo de execução, que não podem ser somadas
por nenhuma dimensão. O ideal é salvar as métricas que levam àquela não-aditiva e deixar para que
ela seja calculada na ferramenta de BI.
No exemplo lá de cima: No exemplo lá de cima:
Enquanto no saldo temos a diferença numérica, nessa temos a percentual. E qual a conta? A entrada
dividido pela saída.
Que leitura fazemos aqui? A entrada passou 500% da saída. Ou seja, tivemos 500% a mais de entrada
que de saída.

Normalização de dados

Normalização de banco de dados é um conjunto de regras que visa, principalmente, a organização de um

projeto de banco de dados para reduzir a redundância de dados, aumentar a integridade de dados e o desempenho.
Para normalizar o banco de dados, deve-se examinar as colunas (atributos) de uma entidade e as relações entre
entidades (tabelas), com o objetivo de se evitar anomalias observadas na inclusão, exclusão e alteração de registros.
Atualmente, muitos sistemas de informação ainda não utilizam banco de dados relacionais, sendo esses
chamados de sistemas legados. Os dados desses sistemas são armazenados em arquivos de linguagens de terceira
geração, como COBOL ou BASIC, ou então, em banco de dados da era pré-relacional.
Para adequar o banco de dados, é necessário avaliar com base em cinco regras, que recebem o nome
de formas normais. Essas correspondem a um conjunto de regras de simplificação e adequação de tabelas. Diz-
se que a tabela do banco de dados relacional está numa certa forma normal quando satisfaz as condições
exigentes. O trabalho original de Edgar F. Codd, definiu três dessas formas, mas existem hoje outras formas
normais geralmente aceitas. Damos aqui uma curta panorâmica informal das mais comuns. Cada forma normal
listada abaixo representa uma condição mais forte das que a precedem na lista. Para a maioria dos efeitos
práticos, considera-se que as bases de dados estão normalizadas se aderirem à terceira forma normal.
Inicialmente, são definidos todos os atributos do documento, que estão relacionados a uma entidade
principal, atribuindo uma chave primária. Feito isso, partimos para a análise do documento de acordo com as
formas normais a seguir:

 Primeira Forma Normal (ou 1FN). Nesta forma os atributos precisam ser atômicos, o que significa que as
tabelas não podem ter valores repetidos e nem atributos possuindo mais de um valor.

Exemplo:

CLIENTE = {ID + ENDEREÇO + TELEFONES}. Porém, uma pessoa poderá ter mais de um número
de telefone, sendo assim o atributo "TELEFONES" é multivalorado. Para normalizar, é necessário:

1. Identificar a chave primária e também a coluna que possui dados repetidos (nesse exemplo
"TELEFONES") e removê-los;
2. Construir uma outra tabela com o atributo em questão, no caso "TELEFONES". Mas não se
esquecendo de fazer uma relação entre as duas tabelas: CLIENTE = {ID + ENDEREÇO} e
TELEFONE (nova tabela) = {CLIENTE_ID (chave estrangeira) + TELEFONE}.

 Segunda Forma Normal (ou 2FN). Primeiramente, para estar na 2FN é preciso estar também na 1FN. 2FN
define que os atributos normais, ou seja, os não chave, devem depender unicamente da chave primária da
tabela. Assim como as colunas da tabela que não são dependentes dessa chave devem ser removidas da
tabela principal e cria-se uma nova tabela utilizando esses dados.

Exemplo:
 PROFESSOR_CURSO = {ID_PROF + ID_CURSO + SALARIO + DESCRICAO_CURSO} Como
podemos observar, o atributo "DESCRICAO_CURSO" não depende unicamente da chave primária
"ID_PROF", mas sim somente da chave "ID_CURSO". Para normalizar, é necessário:

1. Identificar os dados não dependentes da chave primária (nesse exemplo "DESCRICAO_CURSO") e

removê-los;
2. Construir uma nova tabela com os dados em questão: PROFESSOR_CURSO = {ID_PROF +
ID_CURSO + SALARIO} e CURSOS (nova tabela) = {ID_CURSO + DESCRICAO_CURSO}.

 Terceira Forma Normal (ou 3FN). Assim como para estar na 2FN é preciso estar na 1FN, para estar
na 3FN é preciso estar também na 2FN. 3FN define que todos os atributos dessa tabela devem ser
funcionalmente independentes uns dos outros, ao mesmo tempo que devem ser dependentes
exclusivamente da chave primária da tabela. 3NF foi projetada para melhorar o desempenho de
processamento dos bancos de dados e minimizar os custos de armazenamento.

Exemplo:

FUNCIONARIO = {ID + NOME + VALOR_SALARIO + VALOR_FGTS}. Como sabemos o valor do FGTS é

proporcional ao salário, logo o atributo normal "VALOR_FGTS" é dependente do também atributo normal
"VALOR_SALARIO". Para normalizar, é necessário:

1. Identificar os dados dependentes de outros (nesse exemplo: "VALOR_FGTS");

2. Removê-los da tabela. Esses atributos poderiam ser definitivamente excluídos -- e deixando para a
camada de negócio a responsabilidade pelo seu cálculo -- ou até ser movidos para uma nova tabela
e referenciar a principal ("FUNCIONARIO").

Forma Normal de Boyce-Codd (ou BCNF) requer que não exista nenhuma dependência funcional não trivial
de atributos em algo mais do que um superconjunto de uma chave candidata. Neste estágio, todos os
atributos são dependentes de uma chave, de uma chave inteira e de nada mais que uma chave (excluindo
dependências triviais, como A → A);

 Quarta Forma Normal (ou 4FN) requer que não exista nenhuma dependência multi-valorada não trivial de
conjuntos de atributo em algo mais de que um superconjunto de uma chave candidata;
 Quinta Forma Normal (ou 5FN ou PJ/NF) requer que não exista dependências de joins (associações) não
triviais que não venham de restrições chave;
 Domain-Key Normal Form (ou DK/NF) requer que todas as restrições sigam os domínios e restrições chave.

Antes de falar sobre normalização, é necessário utilizar alguns termos a partir do modelo relacional e defini-
los na teoria de conjuntos. Estas definições muitas vezes serão simplificações de seus significados originais, uma
vez que somente alguns aspectos do modelo relacional são levados em consideração na normalização.
As notações básicas utilizadas no modelo relacional são nomes de relacionamentos e nomes de atributos,
representados por cadeias de caracteres tais como Pessoas e Nomes; geralmente são utilizadas variáveis
como r, s, t,… e a, b, c para o conjunto dados definido sobre eles. Outra notação básica é o conjunto de valores
atômicos que contém valores tais como números e cadeias de caracteres.
A primeira definição de interesse é a noção de tupla, que formaliza a noção de linha ou registro em uma
tabela:
Def. Uma tupla é uma função parcial de nomes de atributos para valores atômicos.
Def. Um cabeçalho é um conjunto finito de nomes de atributos.
Def. A projeção de uma tupla t em um conjunto finito de atributos A é t[A] = {(a, v): (a, v) ∈ t, a ∈ A}.

A próxima definição é a de relação na qual formaliza-se o teor de uma tabela como ele é definido no
modelo relacional.
 Def. Uma relação é uma tupla (H, B) sendo H um cabeçalho e B o corpo, um conjunto de tuplas em que
possuem todas o domínio H.
Como uma relação corresponde definitivamente com aquela que é usualmente chamada de extensão de
um predicado em lógica de primeira ordem exceto que aqui nós identificamos os locais no predicado com nomes
de atributos. Geralmente no modelo relacional um esquema de banco de dados é dito consistir-se de um conjunto
de nomes relação, os cabeçalhos que são associados com esses nomes e as restrições que devem manter toda
instância do esquema de banco de dados. Para normalização nós nos concentraremos nas restrições que
indicam relações individuais, isto é, as restrições relacionais. O propósito destas restrições é descrever
o universo relacional, ou seja, o conjunto de todas as relações que são permitidas para serem associadas com
certos nomes de relação.
Def. Um universo relacional U sobre um cabeçalho H é um conjunto não vazio de relações com o
cabeçalho H.
Def. Um esquema relacional (H, C) consiste de um cabeçalho H e um predicado C(R) que é definido por
todas as relações R com o cabeçalho H.
Def. Uma relação satisfaz o esquema relacional (H, C) se possuir o cabeçalho H e satisfizer C.

Restrições Chave e Dependências Funcionais

A restrição relacional mais importante é a restrição de Chave.
Ela relaciona cada registro (tupla) a um (ou mais) valor índice.
Def. Uma Chave é um atributo que identifica um registro (tupla).

Objetivos de normalização

Um objetivo básico da primeira forma normal, definida por Codd em 1970, era permitir dados serem
questionados e manipulados usando uma "sub-linguagem de dados universal" atrelada à lógica de primeira
ordem. Questionando e manipulando dados em uma estrutura de dados não normalizada, como a seguinte
representação não-1NF de transações de clientes de cartão de crédito, envolve mais complexidade do que seria
realmente necessário:

Transações de clientes de cartão de crédito, não normalizada

Cliente Cliente ID Transação

Tr. ID Data Valor

João 1 12890 14/out/2003 -87

12904 15/out/2003 -50

Tr. ID Data Valor

Wilson 2

12898 14/out/2003 -21

 Tr. ID Data Valor

12907 15/out/2003 -18

Márcio 3

14920 20/nov/2003 -70

15003 27/nov/2003 -60

Note que a tabela é composta pelas colunas cliente e transação, sendo que essa última contém 3 informações:
identificador, data e valor.
Para cada cliente corresponde um grupo repetitivo de transações.

A análise automatizada de transação envolve dois estágios:

1. Desempacotar um ou mais grupos de clientes de transações permitindo transações individuais serem

agrupadas para exame, e
2. Derivar o resultado de uma consulta em resultados do primeiro estágio.
Por exemplo, para encontrar a soma monetária de todas as transações que ocorreram em outubro de 2003 para
todos os clientes, o sistema necessitaria saber primeiro que precisa desempacotar o grupo de transações para
cada cliente, então somar a quantidade de todas as transações de outubro de 2003.
Um das visões mais importantes de Codd foi que a complexidade desta estrutura poderia ser removida
completamente, levando a um poder e flexibilidade muito maior na forma de efetuar consultas. A normalização
equivalente da estrutura acima seria assim:

Tabela dos clientes

Cliente Cliente ID

João 1

Wilson 2

Márcio 3

Tabela das transações

Cliente ID Tr. ID Data Valor

1 12890 14/out/2003 -87

 1 12904 15/out/2003 -50

2 12898 14/out//2003 -21

3 12907 15/out/2003 -18

3 14920 20/nov/2003 -70

3 15003 27/nov/2003 -60

Nessa nova estrutura, as chaves são {Cliente} e {Cliente ID} na primeira tabela e {Cliente ID, Tr. ID} na segunda.
Agora cada linha representa uma transação individual, e um SGBD pode obter a resposta, simplesmente
encontrando todas as linhas com data de outubro, somando então os valores.

Formas Normais
Primeira Forma Normal
Definição pelo Osório
'Uma tabela está na 1FN, se e somente se, todos os valores das colunas da tabela forem atômicos'
Assim, podemos dizer que os relacionamentos, como definidos acima, estão necessariamente na 1FN. Uma
relação está na 1FN quando todos os atributos da relação estiverem baseados em um domínio simples, não
contendo grupos ou valores repetidos.
Passagem à 1FN

1. Encontre a chave primária da tabela;

2. Fique ciente de quais são as colunas da tabela que apresentam dados repetidos para que sejam
removidas;
3. Crie uma tabela para esses dados repetidos, com a chave primária da anterior;
4. Por fim, estabeleça relação entre a nova tabela e a principal.
Outra forma de identificar se a tabela não está na 1FN é verificando se existe tabela aninhadas, ou seja, mais de
um registro para uma chave primária.
Exemplo
Observe a seguinte tabela:
PEDIDOS = {COD_PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT +
VALOR}
Considere um pedido como o número 00001, para este se observarmos o formulário em papel teremos
muitos campos a considerar, contudo usaremos apenas alguns para facilitar o entendimento.
Neste momento devemos idealizar o pedido número 00001 e efetuar os seguintes testes:
{COD_PEDIDO | CLIENTE | VENDEDOR | ATENDENTE | PRODUTO | QUANT | VALOR}
{00001 | "ANDRÉ" | "MARCO" | "JOAO" | "TENIS " | "1" | "50.00"}
{00001 | "ANDRÉ" | "MARCO" | "JOAO" | "SANDALIA" | "2" | "80.00"}
{00001 | "ANDRÉ" | "MARCO" | "JOAO" | "CARTEIRA" | "1" | "35.00"}
Observe que para os dados do pedido 00001 lançados acima, apenas os atributos que estão em negrito SÃO
ÚNICOS, pois não se diferem. Os demais atributos mudam, não cumprindo a 1FN onde os atributos devem ser
atômicos, quer dizer únicos.
Para testarmos um dos atributos e ter certeza que este é atômico, podemos efetuar uma pergunta conforme o
exemplo abaixo:
Podemos ter outro cliente para o pedido 00001? Não. Podemos ter apenas 1 cliente por pedido, sendo assim
este atributo é atômico único para 1 pedido.
Podemos ter outro vendedor para o pedido 00001? Não. Podemos ter apenas 1 vendedor por pedido.
Podemos ter outro produto para o pedido 00001? Sim. Podemos ter vários produtos para um pedido, sendo assim,
os campos aninhados devem ser extraídos para outra tabela.
Problemas

 Redundância;
 Anomalias de Atual.

Segunda Forma Normal

Definição pelo Osório
Uma relação está na 2FN se, e somente se, estiver na 1FN e cada atributo não-chave for dependente da
chave primária inteira, isto é, cada atributo não-chave não poderá ser dependente de apenas parte da
chave.
No caso de tabelas com chave primária composta, se um atributo depende apenas de uma parte da chave
primária, então esse atributo deve ser colocado em outra tabela.
Passagem à 2FN

1. Geração de novas tabelas com DFs (Dependências Funcionais) completas.

2. Análise de dependências funcionais:
 tipo e descrição dependem de codp;
 nome, categ e salário dependem de code;
 data_início e tempo_aloc dependem de toda a chave.

Conclusões

 Maior independência de dados;

 Redundâncias e anomalias: dependências funcionais indirectas.

Terceira Forma Normal

Definição pelo Osório

Uma relação R está na 3FN se ela estiver na 2FN e cada atributo não-chave de R não possuir
dependência transitiva, para cada chave candidata de R. Todos os atributos dessa tabela devem
ser independentes uns dos outros, ao mesmo tempo que devem ser dependentes exclusivamente da chave
primária da tabela.

Exemplo ilustrativo
A tabela a seguir não está na Terceira Forma Normal porque a coluna Total é dependente, ou é
resultado, da multiplicação das colunas Preço e Quantidade, ou seja, a coluna total tem dependência transitiva
de colunas que não fazem parte da chave primária, ou mesmo candidata da tabela. Para que essa tabela passe
à Terceira FN o campo Total deverá ser eliminado, a fim de que nenhuma coluna tenha dependência de qualquer
outra que não seja exclusivamente chave.
Aqui, após o atributo/coluna Total ser excluído da tabela, ela já na 3ª Forma Normal. Esse atributo pode ser
movido para outra tabela referenciando a antiga.

Itens do pedido

Pedido Item Preço Quantidade

15 102 9,25 2

15 132 1,3 5

Passagem à 3FN

 Para estar na 3FN precisa estar na 2FN;

 Geração de novas tabelas com DF diretas;
 Análise de dependências funcionais entre atributos não chave;
 Verificar a dependência exclusiva da chave primária;
 Entidades na 3FN também não podem conter atributos que sejam resultados de algum cálculo de outro
atributo.

Conclusões

 Maior independência de dados;

 3FN gera representações lógicas finais na maioria das vezes;
 Redundâncias e anomalias: dependências funcionais.

Quarta Forma Normal

Definição
Uma tabela está na 4FN, se e somente se, estiver na 3FN e não existirem dependências multivaloradas.
Exemplo (base de dados sobre livros)

Relação não normalizada:

Livros (nrol, autor, título, assunto, editora, id_edit, ano_public)

1FN: Livros (nrol, autor, assunto, título, editora, cid_edit, ano_public)

2FN: Livros (nrol, título, editora, id_edit, ano_public)

 AutAssLiv (nrol, autor, assunto)

3FN: Livros(nrol, título, editora, ano_public)

Editoras(editora, id_edit)
AutAssLiv(nrol, autor, assunto)

Na 3FN, a base de dados ainda apresenta os seguintes problemas:

 Redundância para representar todas as informações;

 Representação não-uniforme (repete alguns elementos ou posições nulas).

Passagem à 4FN

 Geração de novas tabelas, eliminando dependências multivaloradas;

 Análise de dependências multivaloradas entre atributos:
 autor, assunto → Dependência multivalorada de nrol.

Resultado

Livros(nrol, título, editora, ano_public)

Editoras(editora, id_edit)
AutLiv(nrol, autor)
AssLiv(nrol, assunto)

Quinta Forma Normal

Está ligada à noção de dependência de junção.

 Se uma relação é decomposta em várias relações e a reconstrução não é possível pela junção das outras
relações, dizemos que existe uma dependência de junção.
 Existem tabelas na 4FN que não podem ser divididas em duas relações sem que se altere os dados originais.

Exemplo:
Sejam as relações R1(CodEmp, CodPrj) e R2(CodEmp, Papel) a decomposição da relação
ProjetoRecurso(CodEmp, CodPrj, Papel).

Exemplo

 Da 4FN para a 5NF

 Explanação de que a última forma normal pode ser alcançada com projeções

Forma Normal De Boyce-Codd

Definição
Uma tabela está na BCNF se e somente se todo atributo não chave depender funcionalmente diretamente
da chave primária, ou seja, não há dependências entre atributos não chave. Porem nem toda tabela que
está na 3FN é uma tabela BCNF.

Exemplo:

 Como transformar da 3NF para BCNF

 Nem sempre pode ser alcançada preservando a dependência.

Sexta Forma Normal ou Forma Normal Chave-Domínio

Definição

De acordo com [1]Forma Normal Chave-Domínio é uma forma atualizada na normalização de banco de
dados que necessita que não haja restrições de domínio e chave dentro do banco de dados.
Esta forma[2] evita as restrições de dados que não são do domínio ou chaves com restrição. Muitos dos
Banco de dados podem fazer os teste com seus domínios e chaves restritas com os seus atributos.
Contudo a restrições necessitam da programação nesses bancos de dados.
Outras dependências[editar | editar código-fonte]
 dependências encapsuladas;
 dependências como blocos em lógica de primeira ordem.

Desnormalização[editar | editar código-fonte]

A criação de novas entidades e relacionamentos podem trazer prejuízos ao serem implementados em um SGBD.
Devido a algumas relações excessivamente normalizadas, simples alterações no bancos de dados podem
ocasionar uma profunda mudança na coerência de dados, assim entidades e relacionamentos devem ser
desnormalizados para que o SGBD apresente um melhor desempenho.
Além disso, entidades podem conter ocorrências de mudanças de informações ao longo do tempo e a
desnormalização pode contribuir com a manutenção de dados sem afetá-los drasticamente.
Para ilustrar o conceito podemos tomar como exemplo uma entidade denominada Vendedor com os seguintes
atributos:

 Código do Vendedor;
 Nome do Vendedor;
 Região de Vendas.
Um vendedor cadastrado pode mudar sua área de vendas mas os dados de vendas antigas, realizadas em
regiões por onde trabalhou, devem ser mantidos no banco sem incoerência de dados. Assim, a
entidade Vendedor deve ser mantida desnormalizada para que os dados não se tornem inconsistentes.

Entidade Vendedor

Chave primaria Codigo Vendedor Nome Regiao

001 132 Maria Auxiliadora Natal

002 132 Maria Auxiliadora Nova York

Nesse caso fomos obrigados a utilizar uma chave primária para manter a integridade de dados de Vendedor, o
que mantém a entidade desnormalizada. Mas, ao optar pela desnomalização de dados devemos levar em conta
o custo da redundância de dados e o uso das anomalias de atualização, o que não é interessante para grandes
bancos de dados.

Ver também[editar | editar código-fonte]

 Arquitetura de dados
 Administração de dados
 Modelagem de dados
 Banco de Dados