SGBD relacionais orientados a coluna: uma nova roupagem ao Data Warehousing – Parte 01

por João Marcelo Borovina Josko

A necessidade por informações de qualidade e com baixa latência – Real-Time Business Intelligence – é condição cada vez mais premente na condução dos negócios dentro de organizações de vários segmentos. Responsável por atender a essa necessidade, os ambientes de suporte à decisão tornaram-se cada vez mais críticos concomitante ao desafio de TI retirar mais valor desses servindo-se de menos recursos.

A pressão para responder a esse cenário, no caso das tecnologias de Sistemas de Bancos de Dados – SGBD –, levou ao aparecimento de uma nova abordagem que oferece melhor eficiência de armazenamento atrelado a um melhor tempo de resposta nas consultas analíticas; os SGBD Orientado a Coluna – referenciados como Column Oriented ou Column Store.

SGBD e seu público no tempo

Na década de 70, os SGBD foram massivamente utilizados na automatização de processos operacionais crítico – Folha de Pagamento, Contabilidade, Conta Corrente, para citar alguns – que se caracterizam pela realização de transações com curta duração e pequeno volume de dados manipulados; as transações OLTP.

A partir da década de 90, as organizações perceberam o valor dos SGBD – e do grande volume de dados disponíveis – como instrumento de apoio a tomada de decisões, ao planejamento do seu negócio e ao entendimento de seus Clientes, culminando no fortalecimento dos segmentos de Data Warehousing e Customer Relationship Management – CRM.

Esses dois públicos – transacional e analítico –, porém, apresentam características e requisitos fundamentalmente diferentes quanto ao uso do SGBD – ver quadro a seguir –, levando os fornecedores e pesquisadores a buscarem propostas para atender aos públicos divergentes. Desta necessidade surge a abordagem Orientada a Coluna.

Quadro 1 – Contraposição das principais características do mundo transacional e analítico

Distinções entre as abordagens

Muitas implantações de Data Warehouse/Data Marts foram – e estão sendo – concebidas com SGBD tradicionais – Oracle, Teradata, DB2, etc. – cujos núcleos focam no tratamento de linhas. Não obstante esta característica ser adequada a sistemas OLTP, muitos dos seus representantes receberam vultosos investimentos para incrementar sua capacidade de apoio as necessidades analíticas, como incorporação de índice Bit Map, visões Materializadas e capacidade de configuração.

Os SGBD com orientação a coluna – Vertica, Sybase IQ, BigTable, Exasol, ParAccel, entre outras opções comerciais e open-source –, por sua vez, apoiaram a construção do seu núcleo sobre a constatação cujo Data Warehouse/Data Mart apresenta uma freqüência de leitura muito superior a de operações de modificação – insert, update e delete. Tal fato determina seu desempenho ótimo para leituras seletivas – pequeno conjunto de colunas – sobre extenso volume de dados.

SGBD relacionais orientados a coluna: uma nova roupagem ao Data Warehousing – Parte 02

Desempenho das Operações de Leituras

As modificações propostas pelos SGBD Orientado a Coluna, como já fora mencionado, incidem no desempenho deste em relação ao seu co-irmão orientado a linha. Analisando os resultados do benchmark TPC-H, observa-se que os representantes daquele obtiveram desempenho superior a esse para bases de dados com volumes representativos.

Conforme ilustrado no quadro abaixo, considerando bases de dados de até 3 Terabytes – Tb –, os SGBD Orientado a Coluna, para as operações de consultas, atingiram um desempenho 14 vezes maior que os tradicionais e com custos 5 vezes menor. Para volumes na casa dos 10 Tb somente foram identificados métricas para os SGBD tradicionais.

Quadro 2 – Benchmark entre soluções baseadas em SGBD Orientado a Coluna e Linha (adaptado TPC-H)

Onde:

QphH – Query-per-Hour Performance Metric

P/Q     – Representa o custo do Hardware/Software/Manutenção por QphH

O TPC-H é uma métrica de referência de desempenho, padrão de mercado, que  mensura o comportamento de sistemas de suporte à decisão frente à aplicação de um grupo de consultas ad-hoc de alta complexidade e operações de modificação sobre os dados – relevantes a algum segmento do mercado – concorrentemente.

Conclusão

A ênfase dada na manipulação das colunas em detrimento das linhas, por parte dos SGBD Orientado a Coluna, revela uma interessante interpretaç

Adequando a perspectiva temporal aos modelos de dados relacionais

por João Marcelo Borovina Josko

Os objetos do negócio – Nota Fiscal, Apólice de Seguro, Contrato Imobiliário, para citar alguns – sofrem inúmeras modificações ao longo de sua vida, formando um conjunto de posições ou versões que constituem seu histórico. Durante bom tempo, a persistência desses objetos ocorreu em bancos de dados convencionais – ou instantâneos – em que somente a versão corrente – a última modificação – era de interesse.

O fim da distinção entre dados históricos e correntes – analíticos e operacionais, respectivamente –, advindo da nova visão de acompanhamento do negócio por parte das organizações, aumentou a demanda pelo encapsulamento da gestão do tempo nas bases de dados com o intuito de prover serviços temporais robustos, confiáveis e transparentes.

Concernente à estruturação dos dados, padrões de modelagem permitem a gestão do tempo dentro das restrições dos Sistemas Gerenciadores de Banco de Dados Relacionais – SGBDR – que, por sua vez, oferecem funcionalidades e linguagem de manipulação pouco adequada ao tratamento do aspecto temporal.

Conceitos básicos de Bancos de Dados Temporais

Um banco de dados é dito temporal quando é capaz de armazenar dados passados, presentes e futuros sobre os objetos de interesse para um negócio. Nessa categoria, por exemplo, temos os Sistemas de Apoio a Decisão, de Informação Geográfica, de Informação para a área médica, entre outros. O tratamento do aspecto temporal ocorre nos processos de modelagem de dados – da Conceitual a Física – e desenvolvimento das instruções de recuperação e manipulação.

O modelo de dados tradicional tem duas dimensões; uma representando as instâncias ou linhas de um objeto do negócio e outra os seus atributos. No modelo de dados com propriedades temporais, surge uma terceira dimensão cujo propósito é associar o elemento tempo ao valor de cada atributo, conforme ilustrado na figura 1 (EDELWEISS, 1998). Assim, enquanto que no primeiro modelo cada atributo de uma instância possui um único valor – o último –, o segundo é capaz de armazenar as transições dos valores da mesma instância.



A figura abaixo ilustra como um objeto de negócio evolui ao longo do tempo; da versão original a corrente. Essa também reflete a nomenclatura empregada neste trabalho – próxima a Orientação a Objeto – que difere daquela empregada na visão acadêmica do tema de banco de dados temporais.


Figura 2 – Estrutura de Classes e Instâncias no tempo

Padrões de tratamento do aspecto temporal

Um padrão é composto por uma proposta de modelo e um conjunto de regras necessárias ao tratamento da perspectiva tempo de forma a garantir a veracidade e a consistência dos dados durante as operações de manutenção. Cumpre lembrar que, pela falta de melhor suporte dos SGBDR, essas regras devem ser construídas, seja na camada do banco de dados ou da aplicação.

Assim, os padrões elencados abaixo serão descritos e exemplificados quanto à semântica no trato do tempo, enfocando a modelagem de dados lógica para SGBDR. São eles:

§  Sobreposição de Objeto do Negócio com Eliminação Lógica

§  Versionamento Simples de Objeto do Negócio

§  Versionamento Bitemporal de Objeto do Negócio

§  Versionamento Recorrente de Objetos do Negócio

Sobreposição de Objeto do Negócio com Eliminação Lógica

Representando o histórico menos expressivo, nesse padrão um objeto do negócio somente apresenta sua última posição e sua invalidade ocorre pelo assinalamento de uma data – “dat_fim_validade” – que, simultaneamente, representa a eliminação lógica. A ausência de versões implica que os estados anteriores do objeto são perdidos à medida que os valores anteriores são sobrepostos por operações de modificação, conforme exemplificado na figura 3.

Dentre as regras deste padrão, a principal obriga que a data de final de validade, quando preenchida, reflita o momento presente ou futuro do negócio e, daí em diante, não seja mais modificada. Utilizar datas retroativas ou modificar seu conteúdo após preenchimento é semanticamente incorreto, visto que altera as respostas obtidas sobre o passado o que, para muitas situações do negócio, não é aplicável. 



Figura 3 – Evolução histórica da opção de Sobreposição com Eliminação Lógica

Versionamento simples de Objeto do Negócio

Nesse padrão, as modificações sofridas por um objeto do negócio são preservadas, resultando em uma série de versões ordenadas cronologicamente e sem brechas – a validade de uma versão termina um instante de tempo anterior à data de início de validade da versão subseqüente. Essa composição, então, propicia a geração de resp

Uma introdução ao real-time business intelligence

por João Marcelo Borovina Josko

A solução de Business Intelligence – BI – tradicional é caracterizada por auxiliar os analistas de negócio a identificar as respostas – uma semana ou um mês após o acontecimento dos fatos de negócio – de Onde e Como o valor é criado para a organização, empregando análises dimensionais ou exploratórias.

A competição e a inovação tecnológica, porém, vem ampliando o interesse das organizações em responder mais rapidamente às mudanças do mercado e do negócio. Para tanto, demandam uma solução capaz de disponibilizar indicadores críticos e recomendações sobre a execução operacional do negócio de maneira rápida. A solução que apóia esse novo cenário é denominada Real-Time BI – doravante RTBI.

Compreendendo o RTBI

O propósito do RTBI é entregar informações adequadas em formato, local e latência – segundos, minutos ou horas – para um público consumidor cujo foco de decisão é restrito aos processos operacionais de uma organização. O objetivo é minorar o tempo de ação sobre o negócio que compreende o momento entre a geração do evento no negócio e a subseqüente tomada de ação, conforme figura a seguir.


Figura 1 – Elementos do Tempo de Ação

A princípio, a proposta não constitui uma idéia inédita haja vista que algumas organizações já apresentam um conjunto de informações com baixa latência – por exemplo, informações sobre campanhas de vendas. Essas iniciativas, geralmente, são tratadas isoladamente do ambiente de BI e não endereçam os requisitos e a abordagem de uma solução RTBI – maiores detalhes, ver próxima seção.

Cumpre lembrar que o RTBI não substitui o BI tradicional, mas sim estender o ambiente de BI de forma a atender desde o nível operacional ao estratégico. Além disso, a base de baixa latência promove uma camada informacional sobre a execução do negócio que pode ser utilizada pelos sistemas transacionais como insumo na execução de regras de negócio ou para a apreciação de um operador humano.

A literatura especializada aponta três tipos ou classes de solução de BI de baixa latência, ilustradas na figura 2. São elas:

§  Real-Time Data-on-Demand

Solução que prove informações consistentes e integradas em uma base de baixa latência.

§  Real-Time Performance Management

Solução que prove indicadores e alertas com base no monitoramento do negócio e que, devido à evolução dos produtos de BI, apresenta certa sobreposição com a proposição da solução de BAM – Business Activity Monitoring. Essa última, contudo, detém capacidades extensas de captura de eventos – hardware, chamadas de componentes e transações de aplicações, além de dados –, bem como ferramentas criadas especificamente para o trato de processos de negócio.

§  Real-Time Predictive Analysis

Solução que envolve a predição de um evento de negócio – por exemplo, uma transação fraudulenta de cartão de crédito – com base nos eventos encaminhados pelos sistemas transacionais.

Figuras 2 – Tipos de soluções de RTBI

Fatores de risco para o sucesso de soluções de RTBI

Ludibriados pela idéia do ambiente “turbinado”, um dos primeiros risco de insucesso a um projeto de RTBI recai na adoção de uma freqüência de disponibilização das informações que somente considera o tempo nominal, calcado na idéia de quanto mais rápido, melhor.

Como é dirigido a eventos dos processos de negócio, tal caminho gera problemas de inconsistência de dados, de reação dos próprios usuários de negócio e custos. Em um ambiente de tempo real, o tempo de reação depende muito da habilidade do negócio em modificar suas práticas para atuar no negócio em pequenas “janelas” de tempo, período cujas informações devem permanecer inalteradas de forma a propiciar as análises. Finalmente, o custo de TI cresce expressivamente à medida que a latência dos dados é reduzida, questão que deve ser balanceada aos desejos e os benefícios do negócio.

O sucesso começa pela capacidade da organização em compreender seus processos de negócio e respectivos requisitos informacionais, pois esse conhecimento permite a determinação do nível de serviço – l

Estabelecendo uma estratégia para o uso efetivo de índices

por João Marcelo Borovina Josko

Os Sistemas Gerenciadores de Banco de Dados - SGBD - possuem estruturas que propiciam a localização e o acesso mais rápido a dados específicos dentro de uma tabela e, adicionalmente, contribuem nas consultas envolvendo ordenações, agrupamentos e junções. Essas estruturas são notoriamente conhecidas por índices.

Em contrapartida aos benefícios proporcionados nas buscas de dados, essas estruturas consomem espaço de armazenamento e geram impactos negativos em termos de desempenho e concorrência nas operações de atualização - update, delete e insert - das tabelas a qual estão associados.

Assim, os índices não podem ser criados aleatoriamente, sendo suas características e quantidade dependentes das expectativas dos usuários, do espaço de armazenamento disponível, do overhead da manutenção e administração e, principalmente, da finalidade do banco de dados; apoio a processos operacionais ou a processos de Business Intelligence. Tais pontos são considerados pela estratégia de indexação.

A Estratégia

Uma estratégia de indexação é um método de determinação das características de um índice de forma que esse possa incrementar o desempenho das consultas – escolhidas por sua criticidade ou volume de execuções –, mantendo o equilíbrio como outras operações realizadas sobre um banco de dados. A estratégia é formada a partir de componentes representados a seguir.


Figura 1 – Componentes da Estratégia de Indexação.

Existem duas abordagens para a criação de índices que são utilizados de maneira iterativa e conjunta; a abordagem proativa e a reativa. Na primeira, a coluna – ou colunas –candidata a formarem um índice é identificada por meio da análise prévia das consultas a serem aplicadas sobre um banco de dados, análise essa que pode utilizar a técnica de Análise de Caminhos de Acessos. Já a abordagem reativa, presente nos procedimentos de monitoração do banco de dados, consiste em observar os índices em operação no ambiente produtivo para, baseado no comportamento, optar por ajustes que incrementem sua eficiência ou eliminação definitiva.

A abordagem possibilita o delineamento das características do índice a ser criado pelo entendimento de como o banco de dado será exercitado. Como isso pode ocorrer de diferentes maneiras, os SGBD disponibilizam tipos de índices com capacidades distintas e o conheci

Examinando o Database Refactoring

por João Marcelo Borovina Josko

Disponibilizar sistemas de informação com qualidade em ciclos cada vez menores para suportar o negócio, representa um sonho almejado por muitas áreas de negócio e de desenvolvimento também. Essa realidade impulsionou muitas organizações – principalmente aquelas fornecedoras de software – a buscar processos de desenvolvimento capazes de atender a essa demanda concomitante a manutenção da lucratividade.

Em resposta, o mercado presenciou o aparecimento de modelos de qualidade ou metodologias que, apesar de focarem nas questões citadas acima, o fizeram sob óticas de atuação distintas. Uma dessas está ligada às metodologias ágeis de desenvolvimento – como o SCRUM ou Dynamic System Development Method, DSDM – que defendem a construção do software de maneira incremental e iterativa cujas características são conhecidas pouco antes da entrega.

Essa nova perspectiva de desenvolvimento também implica o emprego de novas técnicas e métodos de atuação sobre a porção de dados, uma vez que o projeto de todo o modelo de banco de dados antes do uso – visão tradicional –, naturalmente diverge dos princípios de agilidade presentes nessa perspectiva. Não obstante a pouca discussão desse tema dentro do círculo dos desenvolvedores ágeis, alguns métodos e técnicas aplicados sobre os dados foram propostos, dentre eles o Database Refactoring.

Desvelando a Técnica

Refactoring ou Code Refactoring é uma técnica de reestruturação de um código, de forma disciplinada e evolutiva em pequenos passos, empregada no processo proposto pelo Extreme Programming – XP –, por exemplo. Nessa reestruturação, contudo, o comportamento semântico do código – garantia de que todos os códigos afetados pela modificação continuem funcionando – é preservado, não havendo a introdução de novas funcionalidades.

De maneira análoga, a técnica Database Refactoring aprimora os aspectos estruturais –  modelo de dados físico – e funcionais – objetos programados como stored procedures e triggers – de um banco de dados, preservando não só o comportamental semântico como também o informacional – garantia de que os dados permaneçam íntegros e com o conceito adequado. Contudo, para que funcione na prática, essa técnica requer sofisticada infra-estrutura e processos de testes – como testes de regressão – para garantir que as modificações não acrescentem defeitos no banco de dados em si ou nas interfaces entre este e os sistemas de informação.

O processo de refactoring de um banco de dados apresenta um conjunto de atividades cujo  tipo de mudança determina quais delas serão opcionais ou dispensáveis. São elas:

1.    Identificar a modificação a ser realizada;

2.    Identificar a estratégia de refactoring apropriada;

3.    Executar o refactoring do banco de dados

4.    Escrever e aplicar os testes unitários apropriados;

Maximizando o retorno do investimento da solução de Business Intelligence

por João Marcelo Borovina Josko

Organizações vêem rendendo-se ao fato que a informação, disponibilizada no momento certo e no formato adequado, tornou-se um ativo de extrema importância para seu capital humano intervir, com maior propriedade, sob a condução de seus negócios abarcados em um ambiente cada vez mais competitivo.

Neste contexto, as soluções de Business Intelligence – BI – provêem benefícios na reorganização e disseminação de informações internas e externas, promovendo a alavancagem dos processos decisórios. Esta, diferentemente das soluções de ERP e CRM facilmente copiadas pelo mercado concorrente, são concebidas sob medida a partir das necessidades informacionais da organização e, por isso, apresentam elevado valor estratégico ao negócio.

Não obstante a quantidade de literatura sobre esse assunto, ainda é notório deparar-se com casos de organizações frustradas com sua solução de BI que não alcançam o patamar de diferencial competitivo. Tal estado é decorrente de uma miríade de fatores que, sob diferentes aspectos, comprometem a qualidade da solução e desencadeiam um movimento de descrédito e desconfiança desta por parte das áreas de negócio que, no extremo, podem abandoná-la.

A falta de planejamento, a inexistência de processo de desenvolvimento, o envolvimento inadequado das áreas de negócio, o desconhecimento da qualidade e dos conceitos dos dados organizacionais, o conceito fragmentado ou distorcido do conceito de BI, o foco excessivo em tecnologias, constituem uma pequena parcela dos fatores que solapam essas soluções.

Há, porém, um fator repetidamente relegado ao segundo plano por muitas organizações, cuja relevância emerge quando essas se deparam com a grande dificuldade de suas soluções de BI em responder às novas necessidades de seu negócio. Este fator é conhecido como a Arquitetura de Data Warehousing – DW – ou Arquitetura de Business Intelligence.

Arquitetura de Data Warehousing: Conceito e Tipos

Parafraseando a idéia de qualidade de Crosby, o pior não é o que as pessoas desconhecem sobre esse tópico, mas sim o que elas pensam que é. A arquitetura apresenta como será o ambiente pela quais as informações das origens – sistemas transacionais ou fontes externas – serão transformadas em informações e, então, disponibilizadas aos tomadores de decisão. Além disso, delineia seus componentes, caracterizando-os quanto suas respectivas atribuições e inter-relacionamentos.

A literatura sobre Data Warehousing prove a discussão de algumas arquiteturas. Para o propósito deste artigo, selecionamos as principais. São elas:

§  Data Marts Independentes (Independent Data Marts)

§  Fábrica Corporativa de Informações (Corporate Information Factory)

§  Data Marts Relacionados (Linked Data Marts)

§  Data Warehouse Virtual

Data Marts Independentes

Esta arquitetura caracteriza-se pela presença de uma coleção de Data Marts – DM – construídos para atender necessidades específicas do negócio sem, contudo, a preocupação de conceituação corporativa dos dados. Desse modo, cada DM apresenta seu próprios dados, refinados e organizados pelo seus próprios procedimentos de ETL – Extração, Transformação e Carga – que partem diretamente das bases de dados transacionais, culminando o estabelecimento de silos de informação independentes, como mostrado na figura 1.

Enquanto essa abordagem alcança seu objetivo de disponibilizar informações às áreas de negócio de maneira rápida, o insulamento dos DM acarreta adversidades que se acumulam à medida que o número de membros cresce. Ademais a incapacidade de cruzamento das informações entre os DM, o grande número de procedimentos de ETL torna complexo o gerenciamento de códigos redundantes que, fatalmente, levam a um estado de informações inconsistentes


Figura 1 – Esquema geral da Arquitetura de Data Marts Independentes

As características dessa arquitetura, então, não a qualificam como a escolha de organizações que desejam analisar seus dados históricos sob uma perspectiva interdepartamental, mesmo àquelas que este represente um desejo de longo prazo. O emprego desta seria cabível – com muitas ressalvas – para uma organização que, após avaliação cuidadosa dos riscos, decida valer-se da sua rapidez de entrega para atender suas unidades organizacionais em detrimento de uma visão corporativa dos dados e dos custos envolvidos.

Fábrica Corporativa de Informações

Também conhecida como Hub-and-spoke ou CIF, esta arquitetura apresenta uma estruturação em camadas onde o elemento centr

Metadados – O significado da informação no ambiente de Business Intelligence

por João Marcelo Borovina Josko

Metadados não figuram como um novo conceito. Na verdade, estes sempre foram componentes integrantes da documentação dos sistemas automatizados, mas que nunca receberam o foco adequado. Posto isso, para muitas organizações, os conhecimentos relativos a esses sistemas e os respectivos processos de negócio suportados concentram-se sobre suas pessoas, pelo menos, enquanto elas não se vão.

Com o advento do Ambiente de Business Intelligence – BI – e a necessidade de conhecer e interpretar suas informações reforça a criticidade dos metadados para seu sucesso. A ausência ou fragmentação da significação dessas informações comprometem, perigosamente, a confiabilidade e o investimento – que não é pequeno – realizado nesse ambiente.

Apesar dessa importância, o cenário do mercado mostra que muitas organizações ainda relutam em atuar sobre a questão dos metadados, postergando as ações necessárias para um momento futuro mais “adequado” onde, finalmente, são esquecidos.

Conceito e Tipos de Metadados

Os metadados representam informações que caracterizam a informação documentada. Em essência, estes respondem o que, quem, quando, onde, e como sobre cada faceta da informação, auxiliando a organização na sua publicação e suporte.

Além disso, em um ambiente marcado pela complexidade e distribuição das informações dentre os diversos componentes da Arquitetura de Data Warehousing – ver esquema geral na figura 1 –, os metadados provêem o relacionamento entre desses componentes e as respectivas informações que armazenam.



Figura 1 – Componentes da Arquitetura de Data Warehousing, segundo a Corporate Information Factory

De maneira geral, os metadados são segmentados em dois tipos ou classificações, conforme elencado a seguir. Tal fato deve-se, principalmente, ao uso e o público final a qual se destina – ver resumo na Tabela 1.

§ 

Particionamento de Dados: Uma introdução aos conceitos e aplicação
 

por João Marcelo Borovina Josko

É notória a necessidade de acesso eficiente e rápido aos bancos de dados, independente do volume armazenado. Na realidade, muitas organizações dependem dessa agilidade para transacionar com seus clientes e fornecedores ou mesmo para tomar decisões corretivas sobre sua operação.

Essa questão representa o elemento central abordado no processo de modelagem física de dados que avalia, dentre um conjunto de recursos, aqueles mais adequados às expectativas de desempenho e alinhados as características do ambiente computacional da organização.

O Particionamento de Dados, mecanismo oferecido por parte dos Sistemas Gerenciadores de Banco de Dados – doravante SGBD – do mercado, apresenta-se como um desses recursos cuja contribuição para o desempenho e administração de um banco de dados se dá pela segmentação de seus objetos de dados – como tabelas e índices – em porções menores.

Características do Particionamento de Dados

O mecanismo de particionamento determina a divisão dos dados dentre as partições com base no critério estabelecido sobre os valores de uma ou mais colunas de um objeto, conjuntamente denominadas de chave de partição – ver figura 1. Seu uso é aconselhado para objetos cujo volume supera a casa dos Gigabytes – a Oracle, por exemplo, sugere o parâmetro inicial de 2GB.


Figura 1 – Particionamento de Dados em ação

Objetos particionados são totalmente transparentes para os sistemas de informação e instruções DML padrão, uma vez que as características lógicas permanecem preservadas – definição de colunas e constraints, por exemplo – enquanto as físicas podem apresentar variações – local de armazenamento, por exemplo. Contudo, para o SGBD, a presença desses objetos leva-o a operar no nível de partição.

Quando uma operação de consulta é efetuada sobre uma tabela particionada, o otimizador determina a partição envolvida – característica denominada de Partition Pruning –, desde que a operação esteja condicionada pela chave de partição. Ainda, caso a operação envolva tabelas particionadas pelo mesmo critério e método, a junção ocorre entre as próprias partições, como ilustrado abaixo.


Figura 2 – Junção de partições com mesmo critério e método

Além de atuar sobre a questão desempenho, o particionamento de dados também contribui para as tarefas ligadas à administração do banco de dados. Carga de dados, construção de índices, transporte de dados, eliminação de dados, backup e recovery, entre outras tarefas, ocorrem nas partições de forma independente; enquanto algumas ficam bloqueadas por tarefas administrativas, as demais permanecem disponíveis.

Métodos de Particionamento

Na sua versão 10g, o SGBD Oracle disponibiliza um conjunto variado de métodos para particionamento dos dados, sendo eles:

§

Desmistificando a modelagem conceitual de dados

A Modelagem de Dados, apresentada por Peter Chen na década de 70, foi um marco no desenvolvimento de sistemas de informação; pela mudança de paradigma – da orientação ao processo para ao negócio – e por introduzir a capacidade de reutilização do dado. Denominada de Modelagem Entidade-Relacionamento ou MER, essa técnica é empregada na descrição do mundo real, em termos dos objetos de interesse – entidades – e suas características – inter-relacionamentos e atributos –, com alto nível de abstração.

O levantamento e a documentação gerados pelo processo de modelagem explicitam as necessidades informacionais de um negócio e, desta forma, possibilita a estruturação adequada das bases de dados de uma organização com vistas no compartilhamento desses dados entre seus vários sistemas de informação – doravante sistemas – que, construídos dentro dessa realidade, caracterizam-se pela elevada estabilidade e flexibilidade de manutenção.

Embora esse conhecimento seja notório, não é incomum defrontar-se no mercado com organizações, de segmentos e tamanhos distintos, que se valem da modelagem de dados de forma fragmentada, desvelando o desconhecimento dos seus benefícios e, mais grave, dos impactos negativos da sua não utilização.

Bases de dados mal concebidas – incompatíveis à realidade e flexibilidade exigidas pelo negócio – vêm fazendo organizações experimentarem baixo retorno dos seus sistemas cuja criticidade estratégica pode, inclusive, levar a perda de oportunidades de negócio. Em um mercado impregnado pela forte competição e restrição dos gastos, esse “descuido” deve ser evitado.

Os propósitos da Modelagem de Dados

Em grande parte dos casos, a modelagem de dados é associada a uma atividade meramente descritiva, ou seja, produto da mera observação de uma realidade e transcrição para uma linguagem gráfica e escrita. Representa, então, uma documentação enfadonha, burocrática – no sentido negativo da palavra – e que pouco contribui para dirimir o cenário de mercado supracitado. Logo, dispensável do cronograma de qualquer sistema.

Essa percepção, reflexo de uma visão obtusa, dissimula os verdadeiros propósitos da modelagem de dados. De certo esta técnica possui uma porção descritiva. Contudo, essa somente tem efeito após um intenso trabalho de caracterização, totalmente isento do apelo tecnológico, dos objetos de dados significativos que fluem dentro do contexto do negócio estudado.

As principais contribuições no uso da técnica de modelagem de dados são:

Pensando o desempenho no data warehouse

O mercado competitivo levou, nas últimas décadas, o investimento de muitas organizações em soluções capazes de transformar seus dados em um ativo capaz de prover inteligência ao seu negócio; as soluções de Business Intelligence – doravante BI.

Neste cenário, com o aprimoramento das ferramentas e a evolução na capacidade analítica dos gestores, tornaram essas soluções populares dentro das organizações. Essa situação, entretanto, pressiona as mesmas organizações por um melhor desempenho de suas soluções de BI que se dilatam em volume de dados para atender a um público igualmente crescente e, em algumas situações, de perfil antagônico.

Como componente principal dessas soluções, o Data Warehouse – doravante DW – tem recebido vultosos investimentos, na forma de monitores de desempenho e mão-de-obra especializada, na busca do “elixir” capaz de incrementar seu o desempenho. Contudo, esses e outros recursos, aplicados pontualmente com base em um mosaico de conhecimentos sobre a organização, conduzem a resultados de curto prazo, mas não perenes e que podem ainda exaurir seu ambiente computacional.

Tal fato reflete o desconhecimento, por parte de muitas organizações, da dimensão que envolve o desempenho do DW. A seguir, discute-se essa questão cujo sucesso – enquanto quesito de qualidade – depende de uma preocupação e atuação contínuas e ordenadas, pautadas em insumos mutáveis ao longo do tempo.

Desempenho: uma questão de ação constante

Pensar no desempenho do DW tem início na modelagem física e perdura durante toda a sua operação dentro de uma organização. Desta maneira, faz-se necessário um conjunto de ações coordenadas e institucionalizadas cujo objetivo é sustentar um patamar de desempenho adequado para a organização suportar seus os processos de tomada de decisão.

Por envolver diferentes conhecimentos técnicos e do negócio, essas ações devem ser devotadas a uma equipe multidisciplinar – projetistas do DW, responsáveis pelo Capacity Planning da infra-estrutura que suporta o DW, entre outros –, que, inclusive, propicia sua institucionalização – suporte econômico – e facilita seu gerenciamento por parte da organização.

A atuação dessa equipe perpassa os processos de Desenvolvimento, de Manutenção e de Administração necessários para uma organização assegurar a efetividade da evolução de seu DW. Neste último processo, foca-se o monitoramento da utilização, enquanto nos demais, têm-se o acompanhamento da modelagem física.

Os insumos para o pensar em Desempenho

As ações supracitadas devem ser balizadas por um conjunto de informações, conforme apresentado na figura 1.

O DW, além dos dados estruturados, evoluiu para acomodar também dados semi-estruturados e textuais. Disponibilizá-los com um ponto de vista histórico e integrado, bem como estruturados de forma a propiciar sua evolução incremental, o projeto do DW requer a aplicação das técnicas de Modelagens Conceitual, Lógica e Física.

As duas primeiras preocupam-se com a compreensão do negócio e sua representação implementável em um SGBD, respectivamente. Já modelagem física, por sua vez, parte desse conhecimento para, aplicando recursos de otimização e limitações de ordem prática, conceber um modelo final que atenda a expectativa de desempenho.

Figura 1 – Insumos utilizados na Otimização do DW

A expectativa de desempenho descreve o nível de serviço formalmente definido pelas áreas usuárias quanto a tempo de resposta e disponibilidade de informações. Complementam-na as descrições das transações ou consultas a serem realizadas, estudos de crescimento volumétrico de dados e usuários e a própria estratégia de BI traçada pela organização.

Os vários recursos empregados na otimização – ver Tabela 1 – apresentam especificidades que impactam o DW de modo desigual. Posto isso, conhecer essas particularidades torna-se essencial à medida que possibilita à equipe, com foco em desempenho,  ponderar os prós e contras de cada recurso – inclusive no quesito financeiro – frente à expectativa do desempenho delineada.

Tabela 1 – Visão geral dos recursos aplicados na Otimização do DW