Tipo dos campos na criação das tabelas | ETL com Integration Services: modelo de dados

Giovane

O objetivo aqui não foi entrarem detalhes de performance e sim ser didático. O NVARCHAR ocupa mais espaço em disco pois permite armazenar caracteres não latinos. Mas não haveria nenhum problema em criar com VARCHAR.

Se fossemos pensar em performance uma dica seria de usar sempre caracteres numéricos como ID dos membros das dimensões. Isso porque JOINS entre números são muito mais rápido que entre caracteres.

O que costumamos fazer (Não entrei neste detalhe no curso, mas mencionei no curso de INTRODUÇÃO AO BI) é a técnica de LOOKUP que cria um sequencial numérico para cada membro novo da dimensão e usar este mesmo identificador numérico na fato.

Ex; Temos uma dimensão cliente:

DIMENSÃO CLIENTE:

CPF : 5636232 NOME: CLIENTE X

CPF :8329393 NOME: CLIENTE Y

CPF :5533525 NOME: CLIENTE Z

FATO:

CPF:5636232 DIA :1 VALOR:10

CPF:8329393 DIA :1 VALOR:11

CPF:5533525 DIA :1 VALOR:9

Uma coisa natural seria de usar o CPF como identificador da dimensão. Mas, se aplicarmos o LOOKUP teriamos:

DIMENSÃO CLIENTE:

ID_CPF:1 CPF : 5636232 NOME: CLIENTE X

ID_CPF:2 CPF :8329393 NOME: CLIENTE Y

ID_CPF:3 CPF :5533525 NOME: CLIENTE Z

FATO:

ID_CPF:1 DIA :1 VALOR:10

ID_CPF:2 DIA :1 VALOR:11

ID_CPF:3 DIA :1 VALOR:9

Onde ID_CPF, que é o novo identificador da dimensão, seria numérico (INTEGER) e não NVarchar (Ou Varchar)

Hoje, com o avanço das ferramentas, a técnica de LOOKUP se aplica se temos Bilhões de registros na fato, ou se minha ferramenta de OLAP será ROLAP (OLAP Relacional) pois vou fazer consultas na base relacional no momento das consultas e os JOINS serão muito requisitados.

Victorino Vila