quinta-feira, 8 de novembro de 2012

Real Time BI e Change Data Capture


Real-time business intelligence (RTBI) é o processo de fornecer informações sobre as operações de negócios assim que elas ocorrem.

As operações de negócio assim que ocorrem são alimentadas no sistema RTBI em tempo real (Ou Near real time) que demonstra o estado atual da empresa; permitindo assim não somente as clássicas visões do passado do sistema de DW. Fornecendo suporte tático em tempo real para impulsionar ações de empresas para que reajam imediatamente aos eventos que ocorrerem.

Uma das tecnologias que melhor fornece a habilidade de carga de dados Real Time e o CDC (Change Data Capture).

CDC é um conjunto de padrões de software usados ​​para determinar (e rastrear) os dados que foram alterados de modo que uma ação pode ser tomada utilizando os dados alterados. Além disso, Change Data Capture (CDC) é uma abordagem para a integração de dados que se baseia na identificação, captura e entrega das modificações realizadas nas fontes de dados corporativas.

Exemplo de como ativar o CDC no SQL Server 2008:

1- O Serviço Agent do SQL Server 2008 precisa estar ativo.

2- Código para habilitar o CDC.

/*Habilita o Banco para uso do CDC*/
USE DB_NAME
GO
exec sys.sp_cdc_enable_db


-- Mostra os BDs com CDC ativo
select name, is_cdc_enabled from sys.databases


/*Habilita a tabela para o CDC*/
exec sys.sp_cdc_enable_table
    @source_schema = 'dbo',
    @source_name = 'TABLE_NAME' ,
    @role_name = 'CDCRole',
    @supports_net_changes = 1

/*Esse exemplo habilita as colunas a serem rastreadas*/
EXEC sys.sp_cdc_enable_table
@source_schema = N'dbo',
@source_name   = N'TABLE_NAME',
@role_name     = NULL,
@captured_column_list = '[COLUMN_NAME1],[ COLUMN_NAME2]'

   
/*Lista Tabelas rastreadas pelo CDC*/
select name, type, type_desc, is_tracked_by_cdc from sys.tables
where is_tracked_by_cdc = 1

-- ou

EXEC sys.sp_cdc_help_change_data_capture

Real Time BI and Change Data Capture (English Version)


Real-time business intelligence (RTBI) is the process of delivering information about business operations as they occur.

Business operations as they occur are fed into the RTBI system in real time (Or Near real time) which shows the current state of the company; allowing not only the classical visions of the past of classical DW system. Providing real-time tactical support to boost shares of companies to immediately respond to events as they occur.

One of the technologies that best provides the ability to load data and Real Time CDC (Change Data Capture).

CDC is a set of software design patterns used to determine (and track) the data that has changed so that action can be taken using the changed data. Also, Change data capture (CDC) is an approach to data integration that is based on the identification, capture and delivery of the changes made to enterprise data sources.

Example of how to enable CDC in SQL Server 2008:

1 - The SQL Server Agent service needs to be active.

2 - Code to enable the CDC.

/* Enables the database to use the CDC*/
USE DB_NAME
GO
exec sys.sp_cdc_enable_db


-- Shows DBs with active CDC
select name, is_cdc_enabled from sys.databases


/* Enables the table for use CDC */
exec sys.sp_cdc_enable_table
    @source_schema = 'dbo',
    @source_name = 'TABLE_NAME' ,
    @role_name = 'CDCRole',
    @supports_net_changes = 1

/* This example enables the columns to be tracked*/
EXEC sys.sp_cdc_enable_table
@source_schema = N'dbo',
@source_name   = N'TABLE_NAME',
@role_name     = NULL,
@captured_column_list = '[COLUMN_NAME1],[ COLUMN_NAME2]'

   
/* Tables listed to be tracked by CDC*/
select name, type, type_desc, is_tracked_by_cdc from sys.tables
where is_tracked_by_cdc = 1

-- or

EXEC sys.sp_cdc_help_change_data_capture

quarta-feira, 7 de novembro de 2012

Surrogate Key (English Version)


Surrogate Key

The Surrogate word can be interpreted as an artificial synthetic product that is used to replace a natural product; Surrogate = Substitute; Applying this definition to dimensional modeling can say that a synthetic key is an artificial key that is used to replace a natural key the transactional environment.

The Surrogate Key (numeric, incremental and meaningless) arises from a concern not to have an informational database, linked and dependent on a transactional database. That is, has the benefit of immunize the DW  of the environmental changes and operational changes. Having the key independent of all other columns insulates possible changes in relationships of values ​​from the database or database design (making the database faster) ensuring the singularities.

Usually generate the surrogate key column based on a numeric data type which varies storing bytes according to the value stored. That is, if a field NUMERIC (10) is used in the definition of a Surrogate Key value will not be stored ten positions indicated in the definition of the field, but the actual value stored with the limit of ten positions. In Oracle this characteristic can be observed using the function VSIZE.

ETL tools have several tasks for the generation of Surrogates Key's as SAS Data Integration Studio, SAP Data Services, IBM Data Stage and etc..

DBMS solutions can also provide the generation of these keys as the data type  IDENTITY of SQL Server and  Oracle SEQUENCE function.

Why use Surrogate Key:

•        Keys transactional can be reused;
•        Treatment of historic dimensions;
•        Saving space;
•        Enable the integration of databases that have not integrated codes matching in transactional databases;
•        Enable the creation of control values ​​without including in transactional environment. Example: Client not registered, open date, etc..;
•        Improved performance in joins between tables.

How should be a Surrogate Key:

•        Must be an integer;
•        Sequential numbering increasing;
•        Must start at 1 until the required number;
•        There must have implicit meaning;
•        Shouldn't be a composite of transactional key.

Surrogate Key


Surrogate Key

A palavra Surrogate pode ser vista como um produto artificial sintético que é utilizado para substituir um produto natural; Surrogate = Substituta; Aplicando essa definição à modelagem dimensional pode-se dizer que uma chave sintética é uma chave artificial que é utilizada para substituir uma chave natural do ambiente transacional.

A Surrogate Key (campo numérico, incremental e sem significado) nasce da preocupação de não se ter uma base de dados informacional, vinculada e dependente de uma base transacional. Ou seja, possui como benefício imunizar o DW de mudanças de ambiente e de alterações operacionais. Ter a chave independente de todas as outras colunas isola possíveis mudanças de valores nos relacionamentos do banco de dados ou projeto do banco de dados (tornando a base de dados mais ágil) garantindo as singularidades.

Costumamos gerar a Surrogate Key baseada em uma coluna do tipo de dados numérico o qual varia o armazenamento de bytes de acordo com o valor armazenado. Ou seja, se um campo NUMERIC(10) for utilizado na definição de uma Surrogate Key o valor armazenado não será das dez posições indicadas na definição do campo, mas sim a do valor real armazenado com o limite de dez posições. No Oracle essa característica pode ser observada utilizando-se a função VSIZE.

Várias ferramentas de ETL possuem tarefas para a geração de Surrogates Key's , como SAS Data Integration Studio, SAP Data Services, IBM Data Stage e etc.

Soluções de BD's também podem prover a geração destas chaves como o tipo de Dados IDENTITY do SQL Server e a função SEQUENCE do Oracle.

Porque utilizar as Surrogate Key's:

·         Chaves transacionais podem ser reutilizadas;
·         Tratamento de histórico nas dimensões;
·         Economia de espaço;
·         Possibilitar a integração de bases de dados não integradas que possuam códigos transacionais coincidentes;
·         Possibilitar a criação de valores de “controle” sem implicar na sua inclusão no ambiente transacional. Exemplo: Cliente não cadastrado, Data em aberto, etc.;
·         Melhoria de performance nos joins entre tabelas.

Como deve ser uma Surrogate Key:

·         Deve ser um número inteiro;
·         Numeração seqüencial crescente;
·         Deve iniciar em 1 até o número necessário;
·         Não deve ter Significado implícito;
·         Não deve ser uma composição de chaves do transacional.

quarta-feira, 3 de outubro de 2012

Particionamento Dinâmico - Dynamic Partitioning



A Stored Procedure (SQL Server) a seguir realiza o particionamento de uma tabela de nome "FACT_TABLE", o particionamento também tem a função de realizar a manutenção de expurgo da tabela. O código abaixo armazena os últimos 30 dias carregados na tabela "FACT_TABLE", e mantém o histórico dos meses fechados armazenando somente o último dia de cada mês já fechado.
Muito útil para processos que acompanham vendas diárias, mas precisam manter a última posição fechada; posições de Carteiras e etc.

The Stored Procedure (SQL Server) performs the partitioning of a table named "FACT_TABLE" this partitioning also has the function to perform the purge o the table. The code below stores the last 30 days in the loaded table "FACT_TABLE" and keeps track of the months closed storing only the last day of each month closed.
Very useful for processes like daily sales, but need to keep the last closed position; positions and etc.


Código abaixo (Code below)

--Cria função de partição da tabela de fato. (Create the partition function of the fact table)
------------------------------------------------------------------------------------------------------------
DECLARE @DATA SMALLDATETIME

SET @DATA = '1900-01-01'


CREATE PARTITION FUNCTION PFDataRef (SMALLDATETIME)
AS RANGE RIGHT FOR VALUES (@DATA)

GO

-- Cria função de partição da tabela auxiliar. (Creates the partition function of the auxiliary table)
------------------------------------------------------------------------------------------------------------
DECLARE @DATA SMALLDATETIME

SET @DATA = '1900-01-01'

CREATE PARTITION FUNCTION PFDataRefAUX (SMALLDATETIME)
AS RANGE RIGHT FOR VALUES (@DATA)

GO

-- Cria a partição da tabela de fato. (Create the partition of the fact table)
------------------------------------------------------------------------------------------------------------
CREATE PARTITION SCHEME PSDataRef1
AS PARTITION PFDataRef
ALL TO ([PRIMARY])

GO

-- Cria a partição da tabela dauxiliar. (Creates the partition of the auxiliary table)
------------------------------------------------------------------------------------------------------------
CREATE PARTITION SCHEME PSDataRefAUX1
AS PARTITION PFDataRefAUX
ALL TO ([PRIMARY])

GO

-- Cria a tabela de Fato. (Creates the Fact Table)
------------------------------------------------------------------------------------------------------------
CREATE TABLE FACT_TABLE( C1 SMALLDATETIME NOT NULL,
C2 INT NOT NULL) ON PSDataRefCNG1 (C1)

GO

-- Cria a tabela auxiliar. (Creates the Auxiliary Table)
------------------------------------------------------------------------------------------------------------
CREATE TABLE FACT_TABLE_AUX( C1 SMALLDATETIME NOT NULL,
C2 INT NOT NULL) ON PSDataRefCNGAUX1 (C1)

GO

-- Stored Procedure para Particionamento. (Stored Procedure for Partitioning.)
------------------------------------------------------------------------------------------------------------
CREATE PROCEDURE SP_ParticaoExpurgo @DATA SMALLDATETIME
AS

DECLARE @DataPart SMALLDATETIME,
@DataSplit SMALLDATETIME,
@DataRange SMALLDATETIME,
@Cont INT


SET @DataRange =  cast((select top 1 [value] from sys.partition_range_values
where function_id = (select function_id
from sys.partition_functions
where name = 'PFDataRef')
order by boundary_id ASC) as smalldatetime)

IF @DataRange = @DATA
RETURN

ALTER PARTITION SCHEME PSDataRef1 NEXT USED [PRIMARY]
ALTER PARTITION FUNCTION PFDataRef() SPLIT RANGE (@DATA)

DECLARE Part_cursor CURSOR
FOR SELECT CAST( [value]  AS SMALLDATETIME) AS DATA
FROM sys.partition_range_values
WHERE function_id = (SELECT function_id
FROM sys.partition_functions
WHERE name = 'PFDataRef')
ORDER BY boundary_id DESC

OPEN Part_cursor

FETCH NEXT FROM Part_cursor INTO @DataPart

SET @Cont = 1

CREATE TABLE ##Part (DataPart SMALLDATETIME, Cont INT)

WHILE (@@fetch_status <> -1)
BEGIN

If @Cont <= 30
BEGIN
INSERT INTO ##Part VALUES (@DataPart, @Cont)
END

SET @Cont = @Cont + 1

FETCH NEXT FROM Part_cursor INTO @DataPart
END

CLOSE Part_cursor

DEALLOCATE Part_cursor

DECLARE Split_cursor CURSOR
FOR SELECT CAST( [value] AS SMALLDATETIME) AS DATA
FROM sys.partition_range_values
WHERE function_id = (SELECT function_id
FROM sys.partition_functions
WHERE name = 'PFDataRef')
AND CAST( [value] AS SMALLDATETIME) NOT IN (SELECT DataPart
FROM ##Part
WHERE Cont <= 30
UNION
SELECT MAX(CAST( [value]  AS SMALLDATETIME)) AS DATA
FROM sys.partition_range_values
WHERE function_id = ( select function_id
from sys.partition_functions
where name = 'PFDataRef')
GROUP BY YEAR(CAST( [value]  AS SMALLDATETIME)) * 100 + MONTH(CAST( [value]  AS SMALLDATETIME)) )
ORDER BY boundary_id ASC


OPEN Split_cursor

FETCH NEXT FROM Split_cursor INTO @DataSplit

WHILE (@@fetch_status <> -1)
BEGIN

ALTER PARTITION SCHEME PSDataRefAUX1 NEXT USED [PRIMARY]
ALTER PARTITION FUNCTION PFDataRefAUX() SPLIT RANGE (@DataSplit)
ALTER TABLE dbo.UFACT_TABLE SWITCH PARTITION $PARTITION.PFDataRef(@DataSplit) TO dbo.FACT_TABLE_AUX PARTITION $PARTITION.PFDataRefAUX(@DataSplit)
TRUNCATE TABLE dbo.FACT_TABLE_AUX
ALTER PARTITION FUNCTION PFDataRefAUX() MERGE RANGE (@DataSplit)
ALTER PARTITION FUNCTION PFDataRef() MERGE RANGE (@DataSplit)

FETCH NEXT FROM Split_cursor INTO @DataSplit
END

CLOSE Split_cursor

DEALLOCATE Split_cursor

DROP TABLE ##Part


-- Teste: (Test)
------------------------------------------------------------------------------------------------------------
exec SP_ParticaoExpurgo '2008-01-01'
INSERT INTO FACT_TABLE VALUES ( '2008-01-01' , 1 )

exec SP_ParticaoExpurgo '2008-01-02'
INSERT INTO FACT_TABLE VALUES ( '2008-01-02' , 2 )

exec SP_ParticaoExpurgo '2008-01-03'
INSERT INTO FACT_TABLE VALUES ( '2008-01-03' , 3 )

/* ... Continue até gerar a quantidade de registros necessários ao teste. Você também pode mudar o valor da procedure de 30 para outro para testar com um volume menor. */
/* ... Continue to generate the quantity of records needed to test. You can also change the value of the quantity of records (less then 30) to test with a smaller volume.*/

-- Consultas para apurar o funcionamento do particionamento. (Queries to test the partitioning operation.)
------------------------------------------------------------------------------------------------------------
SELECT * FROM FACT_TABLE

SELECT *
FROM sys.partition_range_values
WHERE function_id = (SELECT function_id
FROM sys.partition_functions
WHERE name = 'PFDataRef')
ORDER BY boundary_id DESC

SELECT * FROM FACT_TABLE_AUX

SELECT *
FROM sys.partition_range_values
WHERE function_id = (SELECT function_id
FROM sys.partition_functions
WHERE name = 'PFDataRefAux')
ORDER BY boundary_id DESC

terça-feira, 2 de outubro de 2012

SCD (Slowly Changing Dimensions) - English Version


SCD (Slowly Changing Dimensions)

Slowly Changing Dimensions means that data changes without a temporal basis. There isn't a planned change by time. There are various types of SCD (Type 0, 1, 2, 3, 4, 6-hybrid-). The most common are type 1, 2 and 3.

Below an example of each type:

Type I:

Suppose we have a Customer dimension with the following attributes: social security number, name and state, as shown below:


Where SK is the Surrogate Key (sequential, numerical and meaningless), the social security number is the business key, name a descriptive attribute and state an attribute that we are looking to update.

In SCD type I, when there is a change in a given data this value is updated. No version is generated.
In the case below, the customer Erick Furst changed from the state of MG for the state of RJ (Brazilian States).

  
Note that SK remains the same and we have only one instance of customer Erick Furst.


Type II:

The SCD type II allows versioning the registry.




In this scenario the SCD Type II makes use of two new fields, Start Date and End Date that will allow the recording of the client's situation (This technique can also be used with the field "Current Record Indicator" or the "Version Number" ).

Note that the client Erick Furst was added on September 24, 2012 (Start Date field) and End Date field with empty value or a date that means null (eg 12/31/1800 or 12/31/9999) indicates that this record is valid, ie is the current record.

Suppose the client Erick Furst moved to the RJ on September 25, 2012. The new version will be included with a new SK (Value 2). And the older version will receive an End Date equivalent to the entry of the new record and the newest version will have the end date open (Null).




Type III:

The SCD type III allows versioning by column.
Assume the same position above in the SCD type II, instead of the versioned record the new version will be included in columns. The disadvantage of this technique is that the versioning is limited to the number of columns provided for this purpose.

Eg:


segunda-feira, 24 de setembro de 2012

SCD (Slowly Changing Dimensions)



Slowly Changing Dimensions (Dimensões de modificação lenta) significa que os dados mudam sem uma base temporal. Não é uma mudança prevista por tempo.
Existem vários tipos de SCD (Tipo 0, 1, 2, 3, 4, 6 -híbridos-). Os mais comuns -Por mais comuns entenda também que são utilizados em ferramentas ETL- são o tipo 1, 2 e 3.

Abaixo um exemplo de cada tipo:

Tipo I:
Suponha que tenhamos uma dimensão Cliente com os seguintes atributos: CPF, Nome e UF, conforme tabela abaixo:


Onde SK é a Surrogate Key (Chave numérica seqüencial e sem significado de negócio), o CPF é a chave de negócio, nome atributo descritivo e UF um atributo que se deseja atualizar.

No SCD tipo I, quando há a mudança de um dado este valor é atualizado. Ou seja não é gerada nenhuma versão.

No caso abaixo o cliente Erick Furst mudou do estado de MG para o estado do RJ.


Observe que a SK permanece a mesma e possuímos somente uma ocorrência do cliente Erick Furst.

Tipo II:
O SCD tipo II permite o versionamento do registro.



Nesse cenário o SCD Tipo II faz uso de dois novos campos Data Início Vigência e Data Fim Vigência que irão permitir o registro da situação do cliente (Essa técnica também pode ser utilizada com o campo “Indicador de Registro Corrente” ou com o “Número da Versão”).

Observe que o cliente Erick Furst foi adicionado no dia 24/09/2012 (campo Data Início Vigência) e o campo Data Fim Vigência vazio ou com uma data que representa nulo (ex.: 31/12/1800 ou 31/12/9999) indica que este registro está vigente, ou seja é o registro corrente.

Suponhamos que o cliente Erick Furst mudou-se para o RJ no dia 25/09/2012. A nova versão será incluída com uma nova SK (Valor 2). E a versão mais antiga receberá uma Data Fim Vigência equivalente à entrada do novo registro e a versão mais nova ficará com a Data fim Vigência em aberto.


Tipo III:
O SCD tipo III permite o versionamento por coluna.
Exemplo, suponha a mesma situação acima do SCD tipo II, ao invés de versionar o registro a nova versão será incluída em colunas. A desvantagem desta técnica é que o versionamento é limitado à quantidade de colunas previstas para tal.

Ex.: