Operational Data Store – ODS – Desenho

Bill Immon nos dá a sua visão, bem ampla, de uma arquitetura ODS. Um artigo interessante!! 

Recentemente houve controvérsia sobre a validade e construção da estrutura arquitetônica conhecida como Operational Data Store – ODS (algo como Armazenagem dos Dados Operacionais). Alguns céticos questionam a existência do ODS. Este argumento é bastante estranho porque o ODS é uma das estruturas mais encontradas, hoje em dia, nos sistemas de informação. A noção que o ODS não é uma estrutura legítima é novidade, principalmente para o SAP, o Oracle Financials e PeopleSoft, três dos softwares mais implementados no mundo e que, por acaso, têm importantes componentes com estruturas tipicamente ODS. Enquanto alguns aspectos destes pacotes de software estão além da fronteira de um ODS, muitas das características destes pacotes de software cabem no paradigma de um ODS.

Como evidência adicional da saúde do ODS, em uma conferência privada recente, sete diretores de sistemas de informações de grandes e famosas empresas, perderam algum tempo descrevendo seus ambientes.  O ODS era uma característica proeminente de cada uma das arquiteturas de sistemas de informações destas empresas. Assim sendo, é peculiar que peritos da industria estejam questionando a validade do ODS. Talvez estes peritos simplesmente não entendam o que é um ODS e como ele funciona.

A Arquitetura

Para iniciarmos a discussão sobre ODS, nada melhor do que apresentarmos um esquema mostrando como é uma arquitetura de ODS, e onde ela se posiciona.

A Figura 1 mostra o posicionamento clássico de um ODS:

Na figura 1, o ODS é visto como uma arquitetura que é alimentada por programas de transformação e integração (i/t). Estes programas de transformação e integração podem ser os mesmos programas que alimentam um DW ou programas separados. O ODS, por sua vez, alimenta um DW.

 Alguns dados operacionais podem ir direto para o DW, através da camada de programas de ETL, enquanto outros dados operacionais são enviados para o ODS e depois, do ODS para o Data Warehouse.

Um ODS é integrado, orientado a assunto, volátil e estrutura tipo current-valued (valores atuais), desenhada para atender aos usuários operacionais, em grandes processos de integração, permitindo uma melhor performance.

A essência de um ODS é a de possibilitar um processo on-line de integração coletiva. Um ODS resulta em uma performance consistente em grandes transações – de dois a três segundos. Um ODS suporta atualizações on-line. Um ODS é integrado com várias aplicações. Um ODS fornece a fundação  para visões coletivas e  atualizadas do negócio. E, ao mesmo tempo, o ODS suporta os processos de apoio à decisão.

Devido aos muitos grupos que o ODS preenche, sua estrutura é complexa. Sua tecnologia subjacente é complexa.  Seu desenho é complexo. Monitorar e manter um ODS é complexo.

Um ODS leva muito tempo para ser implementado. Um ODS exige uma mudança ou troca dos antigos sistemas legados que não podem ser integrados.

O duplo papel do ODS

O ODS atua em um papel duplo. De um lado, o ODS é, resolutamente, operacional. O ODS permite um alto tempo de resposta e uma alta disponibilidade, sendo, certamente, qualificado para atuar como base de um sistema de missão crítica. Por outro lado, o ODS tem, claramente, características de um DSS – Decision Suport System ou Sistema de Suporte à Decisão. O ODS é integrado, orientado a assunto, alguns dos mais importantes quesitos para o suporte à decisão.

Os usuários – Fazendeiros e Exploradores

Este artigo irá focar um dos aspectos mais mal compreendidos do ODS – Os fundamentos de seu desenho. Para podermos entender os fundamentos do desenho de um ODS, necessitamos, primeiramente, entender os dois diferentes tipos de usuários que são atraídos pelo ODSFazendeiros e Exploradores.

O primeiro usuário de um ODS pode ser chamado de ‘fazendeiro’. Fazendeiros são pessoas que fazem, repetidamente, as mesmas tarefas. Os fazendeiros sabem o que querem quando saem em busca de algo. Fazendeiros olham, em cada transação, pequenas quantidades de dados. Os fazendeiros, quase sempre, acham o que querem.  Os fazendeiros, usualmente, acham pequenos flocos de ouro, não grande pepitas, ao completarem suas transações. Fazendeiros operam em um mundo de estrutura de dados estruturados, processos estruturados, procedimentos estruturados, e assim por diante.

O outro tipo de usuário atendido pelo ODS é o ‘explorador’. O explorador é a antítese do fazendeiro. Os exploradores operam de uma forma randômica. O explorador não sabe o que esta procurando em sua análise.  Exploradores operam em um modo heurístico. Exploradores olham em grandes conjuntos de dados. Os exploradores procuram por associações entre tipos de dados, padrões e relacionamentos que nunca foram descobertos antes. O explorador, freqüentemente, não acha nada como resultado de uma análise, mas, ocasionalmente, o explorador acha grandes pepitas de ouro. Exploradores operam em um padrão que desafia as previsões. O explorador opera de uma maneira quase que totalmente desestruturada.

O ODS e os Fazendeiros e Exploradores

O ODS deve satisfazer as necessidades de ambos os tipos de usuários, e, por causa deste paradoxo, o desenho do ODS é, na melhor das circunstancias, uma tarefa difícil.

A Base do Desenho de um DSS

O desenho clássico e fundamental de um ambiente DSS começa com um modelo de dados que reflita as necessidades de informação da empresa. A figura 2 mostra os passos principais de um desenho DSS.

Tabelas normalizadas são definidas na modelagem de dados. Estas tabelas constituem o que pode ser chamado de desenho lógico. Muitas tabelas normalizadas são combinadas no desenho físico, o que podemos chamar de ‘normalização suave’ ou ‘normalização leve’ (do inglês lightly normalized design). Em um desenho com ‘normalização leve’, as tabelas são combinadas com base nos conteúdos, como chaves comuns e uso geral comum.

A técnica de desenho que cria tabelas com estruturas de normalização/normalização leve, baseadas num modelo de dados como o aqui descrito, se ajusta perfeitamente a muitas instancias do desenho DSS. Mas, existe um ponto de atenção nesta abordagem. Problemas de performance quando juntamos muitas tabelas, quando existirem muitas ocorrências de dados que povoarão o projeto, e quando os usuários acharem antinatural juntar muitas tabelas para representar os dados toda vez que uma transação for executada. A técnica de desenho com normalização suave tende a ser marginalizada.

Uma abordagem alternativa é se levar em consideração o volume e o uso dos dados. Quando o volume e o uso dos dados são fatorados no projeto, uma forma mutante de normalização é usada. A normalização leve se transforma em normalização pesada, e uma estrutura conhecida como junção estrela (star join) é criada. (Veja Figura 3.)

Existem duas partes essenciais em um star join: Tabelas Fato e Tabelas Dimensão. A tabela fato representa a estrutura que mantém a maioria das ocorrências do dado. Tipicamente, combinam dados e chaves de referencia cruzada de uma série de outras tabelas.

Já a Tabela Dimensão, contém dados não muito volumosos, e são relacionadas com as tabelas fato via relacionamentos usando foreign Key (chaves estrangeiras). Dizemos que as tabelas dimensão possuem as características dos dados apresentados na tabela fato.

Tabelas fato têm um acesso extremamente eficiente, pois os dados já estão, de certa forma, pré-unidos na tabela, já no momento da carga.  O usuário final esta habilitado a acessar tabelas fatos de forma igualmente eficaz porque as tabelas fato são extremamente ‘aerodinâmicas’ em seu desenho. Em adição, as tabelas fato são familiares ao usuário final, por estarem estruturadas baseadas no seu trabalho diário com os dados.

Construindo Star Joins, o arquiteto cria uma estrutura que busca o acesso eficiente dos dados, o uso de grandes volumes de dados e uma visualização natural dos dados pelos usuários finais. Contudo, existe um problema com o star join. Para poder saber como criar a estrutura star join, o arquiteto deve fazer uma série de suposições sobre como o dado será utilizado. Se assim não o fizer, se não souber qual será o padrão predominante de acesso e uso dos dados, não será possível criar um star join. No coração do desenho de qualquer star join estará implícito o entendimento de como o dado será usado. Infelizmente,  um departamento irá olhar o dado de forma muito diferente da de outro departamento. Por exemplo, um star join de finanças será diferente do de um star join de produção.

Existe ainda, um segundo problema com as estruturas star join, que é o problema da atualização on-line, que não é performática em uma estrutura de gerenciamento star join. Em um mundo DSS, não não existem atualizações on-line de dados, isto não é nenhum problema. Mas em um mundo ODS, onde atualizações são eventos normais, a incapacidade de uma estrutura star join lidar com isso, é um especial desafio.

Um dilema

Deste modo, o arquiteto de ODS tem um dilema. Por um lado, o arquiteto deseja ter eficiência de acesso e a habilidade de lidar com grandes volumes de dados. Por outro lado, o arquiteto de ODS deve projetar o sistema para poder acomodar uma variedade ampla de usuários. A figura seguinte ilustra o dilema do arquiteto de banco de dados de ODS: 

O arquiteto no ambiente ODS da de cara com a chamada escolha de Hobson.  Nenhum projeto de abordagem normalizada ou star join  é favorável para um ODS. Ambas as abordagens têm suas forças e debilidades.

O modo como um arquiteto sofisticado agirá para resolver esta aparente contradição é o de se voltar para os usuários do sistema. Para aquelas partes do sistema usado principalmente por exploradores, um projeto normalizado é favorável.  Os exploradores não sabem como  vão usar o sistema, então normalização se adapta de forma justa. Para aquelas partes do sistema usado principalmente por fazendeiros, uma abordagem star join é favorável. Como fazendeiros têm um padrão de uso previsível e repetitivo, um star join pode ser criado para permitir acesso favorável. A figura 4 mostra este projeto de  abordagem dupla para o ODS.

O próximo fator que deve ser respondido  é o assunto da atualização ou processo puro de DSS. Alguns fazendeiros não fazem nenhuma atualização. Eles são os “processadores de DSS puro. Outros fazendeiros fazem atualizações como uma parte regular de seu processo de ODS.

Exploradores, porém, raramente fazem atualização on-line.  Se exploradores necessitam atualizar dados, o fazem através do uso de programas que varrem uma tabela inteira e fazem atualizações volumosas. Mas exploradores não são conhecidos por fazerem mudanças, certamente não mudanças on-line. A figura  5 mostra que a base adequada de projeto para um ODS é completamente dependente de quem a estará usando e que tipo de trabalho estarão fazendo.

Se o ODS será usado somente por fazendeiros fazendo processo de DSS, uma abordagem exclusivamente star join  será  usada em todo o ODS. Mas se o processo de atualização está sendo feito por fazendeiros ou se existe uso do ODS por exploradores para qualquer extensão, podemos usar qualquer uma das duas abordagens. Se o ODS será usado somente por exploradores, uma abordagem exclusivamente normalizada será usada para todo o ODS.

Este artigo tratou da estrutura arquitetônica de um ODS e como esta arquitetura esta posicionada. O ODS tem um objetivo de projeto duplo, que é bastante diferente de outras estruturas de banco de dados encontradas no mundo de DSS e sistemas operacionais.

 Até a Próxima!!

8 Respostas to “Operational Data Store – ODS – Desenho”

  1. Rodrigo Magalhães Says:

    Lito, belo post!
    Rodrigo

  2. Grimaldo Says:

    Lito encaminhei aos meus alunos este post, parab´nes, ótimo!!!.

  3. Moises Silva Rocha dos Santos Says:

    Ótima aula, se tinha alguma dúvida sobre ODS agora é passado.

  4. Cristian Says:

    Muito interessante.
    Você poderia sugerir algum bibliografia para se aprofundar no assunto?
    Obrigado!

  5. raimundo miranda Says:

    “O ODS atua em um papel duplo. De um lado, oODS é, resolutamente, operacional. O ODSpermite um alto tempo de resposta e uma alta disponibilidade, sendo..”
    alto ou baixo tempo de responta???

    • Carlos Alberto Lorenzi Lima Says:

      Raimundo, tudo bem?
      Imaginemos um projeto com 4 sistemas de origem… Na nossa ODS, iremos ‘transformar’ esses 4 sistemas em UM único sistema, obedecendo os conceitos de modelagem relacional e as regras do negócio. Assim sendo, eu diria que, via de regra, o tempo de resposta para transações OLTP pode ser considerado ALTO e para transações OLAP pode ser considerado BAIXO. Concorda?
      Abs.
      Lito


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: