Prof.

Marcio Hollweg
Conhecimentos Específicos - DATAPREV - Analista de Desenvolvimento - Intensivão
Aulas: 13 - 29

RELACIONAMENTO DO TIPO MUITOS PARA MUITOS:

Este tipo de relacionamento "aconteceria" em uma situação onde em ambos os lados do relacionamento os
valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos
quais aparece um determinado produto, além disso, vários Produtos podem aparecer no mesmo Pedido. Esta é
uma situação em que temos um Relacionamento do Tipo Vários para Vários.
Na prática não é possível implementar um relacionamento deste tipo, devido a uma série de problemas que
seriam introduzidos no modelo do banco de dados. Por exemplo, na tabela Pedidos teríamos que repetir o
Número do Pedido, Nome do Cliente, Nome do Funcionário, Data do Pedido, etc para cada item do Pedido.
Para evitar este tipo de problema é bastante comum "quebrarmos" um relacionamento do tipo Muitos para
Muitos em dois relacionamento do tipo Um para Muitos. Isso é feito através da criação de uma nova tabela, a
qual fica com o lado Muitos dos relacionamentos. No nosso exemplo vamos criar a tabela Detalhes do Pedido,
onde ficam armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de termos um
relacionamento do tipo Muitos para Muitos, teremos dois relacionamentos do tipo um para vários, conforme
descrito pela próxima tabela:
Tipo Lado Um Lado Muitos
Um para Vários CódigoDoProduto na tabela Produtos CódigoDoProduto na tabela Detalhes do Pedido
Um para Vários NúmeroDoPedido na tabela Pedidos NúmeroDoPedido na tabela Detalhes do Pedido
Na figura abaixo temos a representação dos dois relacionamentos Um para Muitos, resultantes da quebra do
relacionamento Muitos para Muitos:

Esta situação em que um relacionamento um para Muitos é "quebrado" em dois Relacionamentos do tipo Um
para Muitos é bastante comum. Diversas vezes utilizamos esta técnica para eliminar uma série de problemas
no Banco de Dados, tais como informação repetida e inconsistência de Dados.

Resumo
• Relação 1..1 (lê-se relação um para um) - indica que as tabelas têm relação unívoca entre si. Você escolhe
qual tabela vai receber a chave estrangeira;
• Relação 1..n (lê-se um para muitos) - a chave primária da tabela que tem o lado 1 vai para a tabela do lado
N. No lado N ela é chamada de chave estrangeira;
• Relação n..n (lê-se muitos para muitos) - quando tabelas têm entre si relação n..n, é necessário criar uma
nova tabela com as chaves primárias das tabelas envolvidas, ficando assim uma chave composta, ou seja,
formada por diversos campos-chave de outras tabelas. A relação então se reduz para uma relação 1..n.
Sempre que você relacionar duas tabelas de chaves primárias com tipos de dados diferentes, será necessário
criar uma tabela de associação entre elas. Por exemplo: uma tabela de fornecedores (Chave primária é o
código de fornecedor) e uma tabela de produtos (chave primária é o código do produto). Se você precisar saber
quais fornecedores vendem um produto ou quiser saber quais produtos são vendidos por um fornecedor, você
precisará criar uma tabela de associação cuja chave deverá ser, obrigatoriamente, o código do fornecedor mais
o código do produto. Essa chave composta da tabela associativa é chamada de chave estrangeira.

DATAWAREHOUSE
A modelagem multidimensional é a técnica de projeto lógico de banco de dados mais usada no
desenvolvimento de data warehouses, embora também possa ser aplicada ao projeto de sistemas de
informações operacionais. Na verdade, ela busca apresentar os dados em um formato que seja intuitivo e ao
mesmo atenda a acessos com um alto desempenho. Um modelo multidimensional é composto por uma tabela
com uma chave composta, denominada tabela de fatos, e um conjunto de tabelas menores conhecidas como
tabelas de dimensão, que possuem chaves simples (formadas por uma única coluna). Na verdade, a chave da
tabela de fatos é uma combinação das chaves das tabelas de dimensão.
A idéia fundamental da modelagem dimensional está baseada no fato de que quase todo tipo de dado do
negócio pode ser representado como uma espécie de cubo de dados, onde as células do cubo contêm os
valores medidos e os lados do cubo definem as dimensões naturais dos dados.

Prof. Marcio Hollweg www.aprovaconcursos.com.br Página 23 de 40

 Prof. Marcio Hollweg
Conhecimentos Específicos - DATAPREV - Analista de Desenvolvimento - Intensivão
Aulas: 13 - 29

O modelo dimensional é formado por uma tabela central (tabela de fatos) e várias outras a ela interligadas
(tabelas de dimensão), sempre por meio de chaves especiais, que associam o fato a uma dimensão do cubo.
• Dimensões: estabelecem a organização dos dados, determinando possíveis consultas/cruzamentos.
Por exemplo: região, tempo, canal de venda,... Cada dimensão pode ainda ter seus elementos,
chamados membros, organizados em diferentes níveis hierárquicos. A dimensão tempo, por exemplo,
pode possuir duas hierarquias: calendário gregoriano (com os níveis ano, mês e dia) e calendário
fiscal (com os níveis ano, semana e dia);
• Medidas: são os valores a serem analisados, como médias, totais e quantidades;
• Fatos: são os dados a serem agrupados, contendo os valores de cada medida para cada combinação
das dimensões existentes. O tamanho da tabela que contém os fatos merece atenção especial do
analista;
• Agregações: totalizações calculadas nos diversos níveis hierárquicos.

CONCEITOS E ESTRATÉGIAS DE IMPLANTAÇÃO DE DATA WAREHOUSE

O Data Warehouse é uma espécie de grande banco de dados contendo dados extraídos do ambiente de
produção da empresa, que foram selecionados e depurados, tendo sido otimizados para processamento de
consulta e não para processamento de transações. Em geral, um Data Warehouse requer a consolidação de
outros recursos de dados além dos armazenados em banco de dados relacionais, incluindo informações
provenientes de planilhas eletrônicas, documentos textuais, etc.
A definição clássica de Data Warehouse criada por Inmon (1997) é a seguinte:
“Data Warehouse é uma coleção de dados orientada por assuntos, integrada, variante no tempo, e não
volátil que tem por objetivo dar suporte aos processos de tomada de decisão.”

A função do Data Warehouse é tornar as informações corporativas acessíveis para o seu entendimento,
gerenciamento e uso. Como o Data Warehouse está separado dos Bancos de Dados operacionais, as
consultas dos usuários não impactam nestes sistemas, que ficam resguardados de alterações indevidas ou
perdas de dados. O Data Warehouse não deve ser tratado como um software, que pode ser comprado e
instalado em todos os computadores da empresa em algumas horas. Na realidade, sua implantação exige a
integração de vários produtos e processos.
Nos últimos anos o Data Warehouse vem oferecendo às organizações uma maneira flexível e eficiente de obter
as informações que os gestores necessitam, nos processos decisórios caracterizando-se como uma função de
apoio à decisão.
A extração, limpeza, transformação e migração de dados dos sistemas existentes na empresa para o Data
Warehouse constituem tarefas críticas para o seu funcionamento efetivo e eficiente. Diversas técnicas e
abordagens têm sido propostas, algumas bastante genéricas e outras especialmente voltadas para a
manutenção de integridade dos dados num ambiente caracterizado pela derivação e replicação de
informações.
Os produtos oferecidos no mercado procuram automatizar processos que teriam de ser feitos manualmente ou
utilizando ambientes de programação de mais baixo nível. De fato, não existe uma ferramenta única capaz de
oferecer suporte aos processos de extração, limpeza, transformação e migração dos dados, diferentes
ferramentas especializam-se em questões específicas.
O grande desafio por trás da alimentação de dados das fontes para o Data Warehouse não é técnico, mas
gerencial. Muitos dos processos envolvidos - como mapeamento, integração e avaliação de qualidade -
ocorrem de fato durante a fase de análise e projeto do Data Warehouse. Especialistas afirmam que identificar
fontes, definir regras de transformação e detectar e resolver questões de qualidade e integração consomem
cerca de 80% do tempo de projeto. Infelizmente, não é fácil automatizar estas tarefas. Embora algumas
ferramentas possam ajudar a detectar problemas na qualidade dos dados e gerar programas de extração, a

Prof. Marcio Hollweg www.aprovaconcursos.com.br Página 24 de 40

 Prof. Marcio Hollweg
Conhecimentos Específicos - DATAPREV - Analista de Desenvolvimento - Intensivão
Aulas: 13 - 29

maioria das informações necessária para desenvolver regras de mapeamento e transformação existe apenas
na cabeça dos analistas e usuários.
Fatores que certamente influem na estimativa de tempo para estas tarefas são o número de fontes e a
qualidade dos metadados mantidos sobre estas fontes. As regras de negócio associadas a cada fonte - tais
como validação de domínios, regras de derivação e dependências entre elementos de dados – são outra fonte
de preocupações. Se estas regras tiverem de ser extraídas do código fonte das aplicações, o tempo para
mapeamento e integração pode dobrar.

DATA MART
Podemos tratar o Data Mart como se fosse um pequeno data warehouse, abrangendo uma determinada área
de assunto e oferecendo informações mais detalhadas sobre o mercado (ou departamento) em questão.
Um Data Mart pode ser criado de duas maneiras:
1. Capturando dados diretamente de sistemas transacionais, cada Data Mart buscando as informações
relevantes para o seu mercado;
2. Capturando dados de todos os sistemas transacionais em um Data Warehouse central, que por sua
vez alimenta todos os Data Marts.
A primeira opção irá fornecer um Data Mart de forma mais rápida, porém sem levar em consideração o
cruzamento de informações entre as demais áreas de assunto. A segunda opção tende a ser mais eficiente,
porém demandará mais tempo para apresentar resultados.
ETL (EXTRACT TRANSFORM LOAD) - EXTRAÇÃO TRANSFORMAÇÃO CARGA
O ETL é conhecido como uma ferramentas de “Back End”, estas ferramentas são fundamentais para o
processo de Business Intelligence, e são responsáveis pela preparação dos dados a serem armazenados em
um Data Warehouse. O processo de ETL se resume basicamente em 5 passos:
• Identificação da origem dos dados a serem coletados, sendo que as fontes podem estar espalhadas
em diversos sistemas transacionais e banco de dados da organização;
• Realizar a limpeza dos dados para possibilitar posterior transformação, e nesta etapa ocorre os
ajustes nos dados, com o intuito de corrigir imperfeições com o objetivo de oferecer um melhor
resultado para o usuário final;
• A terceira etapa é de transformação dos dados e tem por objetivo fazer a padronização dos dados em
um único formato;
• A fase seguinte é de carga dos dados para o Data Warehouse;
• Por fim, existe a etapa de atualização dos dados no DW (refresh), realizada a partir das alterações
sofridas pelos dados nos sistemas operacionais da organização.
É importante salientar que a etapa de ETL é uma das mais críticas de um Data Warehouse, pois envolve a fase
de movimentação dos dados.

OLAP (ON-LINE ANALYTICAL PROCESSING) - PROCESSAMENTO ANALÍTICO ON-LINE

OLAP representa um conjunto de tecnologias projetadas para suportar análise e consultas ad hoc. Estes
processos ajudam analistas e executivos a sintetizarem informações sobre a empresa, através de
comparações, visões personalizadas, análise histórica e projeção de dados em vários cenários de "e se...".
Sistemas OLAP são implementados para ambientes multi-usuário, arquitetura cliente-servidor e oferecem
respostas rápidas e consistentes às consultas iterativas executadas pelos analistas, independente do tamanho
e complexidade do banco de dados.
A característica principal dos sistemas OLAP é permitir uma visão conceitual multi-dimensional dos dados de
uma empresa. A visão multi-dimensional é muito mais útil para os analistas do que a tradicional visão tabular
utilizada nos sistemas de processamento de transação. Ela é mais natural, fácil e intuitiva, permitindo a visão
em diferentes perspectivas dos negócios da empresa e desta maneira tornando o analista um explorador da
informação.
Nesta técnica os dados são modelados em uma estrutura dimensional conhecida por cubo. As dimensões do
cubo representam os componentes dos negócios da empresa tais como "cliente", "produto", "fornecedor" e
"tempo". A célula resultante da interseção das dimensões é chamada de medida e geralmente representa
dados numéricos tais como "unidades vendidas", "lucro" e "total de venda". Além dos componentes dimensão e
medida outro importante aspecto do modelo multidimensional é a consolidação dos dados uma vez que para a

Prof. Marcio Hollweg www.aprovaconcursos.com.br Página 25 de 40

 Prof. Marcio Hollweg
Conhecimentos Específicos - DATAPREV - Analista de Desenvolvimento - Intensivão
Aulas: 13 - 29

tarefa de análise são mais úteis e significativas as agregações (ou sumarização) dos valores indicativas dos
negócios.
O OLAP é uma interface com o usuário e não uma forma de armazenamento de dados, porém se utiliza do
armazenamento para poder apresentar as informações. Os métodos de armazenamento são:
• ROLAP (OLAP Relacional): Os dados são armazenados de forma relacional.
• MOLAP (OLAP Multidimensional): Os dados são armazenados de forma multidimensional.
• HOLAP (OLAP Híbrido): Uma combinação dos métodos ROLAP e MOLAP.
• DOLAP (OLAP Desktop): O conjunto de dados multidimensionais deve ser criado no servidor e
transferido para o desktop. Permite portabilidade aos usuários OLAP que não possuem acesso direto
ao servidor.

DATA MINING
Conhecido também como mineração de dados. Sua função principal é a varredura de grande quantidade de
dados a procura de padrões e detecção de relacionamentos entre informações gerando novos sub-grupos de
dados. Usado comumente em grandes bancos de dados. Por enquanto podemos pensar que Data Mining é
como um agregador e organizador de dados.
Data Mining pode ser utilizado com os seguintes objetivos:
• Explanatório: explicar algum evento ou medida observada, tal como porque a venda de sorvetes caiu
no Rio de Janeiro;
• Confirmatório: confirmar uma hipótese. Uma companhia de seguros , por exemplo, pode querer
examinar os registros de seus clientes para determinar se famílias de duas rendas tem mais
probabilidade de adquirir um plano de saúde do que famílias de uma renda;
• Exploratório: analisar os dados buscando relacionamentos novos e não previstos. Uma companhia
de cartão de crédito pode analisar seus registros históricos para determinar que fatores estejam
associados a pessoas que representam risco para créditos.
Quando determinados padrões de comportamento, como associação de produtos durante um processo de
compras, por exemplo, começam a se repetir com freqüência, as ferramentas Data Mining indicam a presença
de oportunidades e "insights" em relação àquele público consumidor. O diferencial do Data Mining está no fato
de que as descobertas de padrões de consumo se dão por uma lógica de algoritmos com base em uma rede
neural de raciocínios. São ferramentas de descobertas matemáticas feitas sobre os registros corporativos já
processados contra descobertas empíricas.

LINGUAGENS SQL E PL/SQL

PL/SQL
A linguagem PL/SQL (Procedural Language extensions to SQL) foi introduzida no ano de 1988 como parte do
conjunto de tecnologias que compunha a versão 6.0 do SGBD Oracle. Ela possibilita o desenvolvimento de
programas que são armazenados, compilados e executados dentro do servidor de banco de dados Oracle. É
tipicamente utilizada para a criação de aplicações de missão crítica, que requerem alto desempenho na
execução de suas tarefas.

O USO DA LINGUAGEM
Uma das principais vantagens de você criar programas em PL/SQL é, sem dúvida, o fato de a linguagem tornar
possível a construção de aplicações eficientes para a manipulação grandes volumes de dados (tabelas com
milhões ou bilhões de registros). Como o programa PL/SQL é executado dentro do Oracle, os dados
manipulados não precisam entrar ou sair do SGBD, ou seja, trafegar pela rede. A eficiência da PL/SQL também
é garantida através da sua forte integração com a linguagem SQL no ambiente Oracle. É possível executar
comandos SQL diretamente de um programa PL/SQL, sem a necessidade da utilização de API's intermediárias
(como ODBC ou JDBC).

Outra característica é que podemos dizer que a PL/SQL é significativamente mais confiável do que a maioria
das outras linguagens de programação. Normalmente, um programa escrito em PL/SQL apresentará um
comportamento previsível durante a sua execução. Ele rodará com o desempenho esperado pelo programador
e sem a ocorrência de “bugs inexplicáveis”.

A durabilidade de um código escrito em PL/SQL é outra característica a ser levada em conta, um código escrito
em PL/SQL costuma ser mais durável, no sentido de que não precisa sofrer manutenção mesmo quando a
versão do SGBD é atualizada (ex: mudança da versão Oracle 10g no Windows para Oracle 11g no Linux). É
comum encontrar programas PL/SQL que foram escritos há 10 ou mais anos em operação nas empresas. Isto
ocorre porque as diferentes versões do PL/SQL são, na maioria dos aspectos, compatíveis.

DIFERENÇA ENTRE SQL E PL/SQL.

SQL: É a linguagem padrão ANSI para a manipulação de bancos de dados relacionais. Por ser um padrão
aceito pela indústria, é suportada por todos os SGBD's relacionais - o que inclui produtos como Oracle,
Microsoft SQL Server, MySQL, PostgreSQL, SQLite e IBM DB2.

Prof. Marcio Hollweg www.aprovaconcursos.com.br Página 26 de 40