Introdução ao Oracle

A Família de Bases de Dados Oracle

A base de dados Oracle 11g é a versão mais recente da família de Sistemas de Gerenciamento de Bases de Dados Relacionais Oracle, produtos que compartilham código fonte comum. Essa família de produtos inclui: 

Oracle Edição Empresarial (Enterprise Edition)

 

Produto mais importante, é a nau capitânia da empresa, destinada a implementações de larga escala que requeiram o conjunto completo de características e opções da base de dados Oracle. Para segurança avançada, apenas esta edição inclui suporte para Bases de Dados Privadas Virtuais, auditoria detalhada, e opções que incluem o Átrio de base de dados, segurança avançada e Segurança por Rótulo.

As características para Data Warehousing incluídas apenas nesta edição incluem a compactação de valores armazenados repetidamente, os espaços transportáveis de tabelas entre múltiplas plataformas, o Gerenciamento de Tempo de Vida de Informação, a reescrita de consulta de visualizações materializadas, as opções de particionamento, o OLAP, e o aplicativo de mineração de dados.

As características para criar ambientes de alta disponibilidade exclusivas dessa versão incluem a Guarda de Dados e as base de dados, tabelas e consultas transacionais Flashback.

Como inovações nessa versão, temos uma Opção de Compactação Avançada para todas as cargas de trabalho esperadas, incluindo o processamento de transações, o armazenamento de Objetos Grandes e as cópias de segurança.

Uma Opção de Teste Real de Aplicativos inclui o Reprodutor de Base de Dados e o Analisador de Performance SQL, e uma Opção de Relembrar Completamente usada para permitir o Arquivo de Dados Fashback que mantém dados para consultas históricas.

Oracle Edição Padrão (Standard Edition)

Destinada a pequenas e médias implementações, ela pode ser utilizada em configurações de servidores contendo até 4 CPUs num único sistema ou num agrupamento de computadores usando Agrupamentos Reais de Aplicativos.

Oracle Edição Padrão Um (Standard Edition One)

Destinada a implementações pequenas, essa base de dados pode suportar até 2 CPUs e não inclui o RAC. A lista de características, exceto essa, é semelhante à da Edição Padrão.

Oracle Edição Pessoal (Personal Edition)

Base de dados usada por desenvolvedores individuais para criar código para implementações em bases multiusuário Oracle. Exige uma licença, diferente da Edição Expressa, mas possui todas as funcionalidades da Edição Empresarial.

Oracle Edição Expressa (Express Edition)

Base de dados que serve de introdução para o Oracle disponível gratuitamente para Windows e Linux. Essa base é limitada a 1GB de memória e 4GB no disco. Ela contém um subconjunto das funcionalidades da Edição Padrão Um e não possui características como a Máquina Virtual Java, as cópias de segurança e recuperação baseadas em servidor e o Gerenciamento Automático de Armazenamento. Embora essa edição não possa ser gerenciada pelo Gerenciador Empresarial Oracle, pode-se usar a interface de administração dos Aplicativos Expressos Oracle.

Resumo das Características da Base de Dados Oracle

A base de dados Oracle é um produto amplo. Para dar alguma perspectiva inicial, começaremos descrevendo o Oracle de um ponto de vista de alto nível das áreas básicas de funcionalidade.

Características de Desenvolvimento de Aplicativos para Bases de Dados

A base de dados Oracle é tipicamente usada para armazenar e recuperar dados através de aplicativos. As características dessa base de dados e dos produtos descritos neste texto são usadas para criar aplicativos.

Programação para Bases de Dados

Todas as implementações da base de dados Oracle incluem linguagens e interfaces que permitem que programadores acessem e manipulem os dados. Características de programação para bases de dados geralmente interessam aos desenvolvedores que estão criando aplicativos baseados em Oracle para serem comercializados ou àqueles em departamentos de TI programando aplicativos para atender necessidades exclusivas de suas empresas. Os dados em Oracle podem ser acessados usando SQL, ODBC, JDBC, SQLJ, OLE DB, ODP.NET, SQL/XML, Xquery e WebDav. Programas instalados dentro da base de dados podem ser escritos em PL/SQL e Java.

SQL

O padrão ANSI para a SQL possui funções básicas para manipulação de dados, controle de transações e recuperação de registros na base de dados. A maior parte dos usuários empresariais de bases de dados interage com o Oracle através de aplicativos ou ferramentas de inteligência de negócios que disponibilizam interfaces que escondem o SQL subjacente e sua complexidade. 

PL/SQL

Essa linguagem da Oracle, uma extensão procedural ao SQL, é muito usada para implementar módulos de programação lógica para aplicativos. Ela pode ser usada para criar procedimentos armazenados e gatilhos, controles em laço, consultas condicionais e tratamento de erros. Pode-se compilar e armazenar procedimentos PL/SQL na base de dados. Pode-se também executar blocos PL/SQL usando o SQL Plus, uma ferramenta interativa incluída em todas as versões do Oracle. As unidades de programas PL/SQL podem ser pré-compiladas.

Java

O Oracle 8i introduziu o uso de Java como linguagem procedural e uma máquina virtual java na base de dados. A JVM disponibiliza suporte para procedimentos armazenados, métodos e gatilhos em Java, para os JavaBeans Empresariais para o CORBA, o IIOP e o HTTP. A inclusão de Java dentro da base permitiu que desenvolvedores dessa linguagem utilizassem seus conhecimentos para criar aplicativos Oracle. Estes podem ser distribuídos nos clientes, no Servidor de Aplicativos ou na base de dados, o que for mais apropriado. A base Oracle 11g inclui um compilador Java JIT ativado por padrão.

Oracle e Serviços Web

A partir da versão 11g, a base de dados pode ser usada como servidora de serviços web implementados usando XML DB. Serviços Web permitem que SQL ou XQuery sejam usados para efetuar consultas e receber os resultados como XML, ou invocar funções PL/SQL ou de compactação e receber os resultados. XQuery na base Oracle 11g dá suporte para o padrão emergente JSR-225 e inclui uma boa quantidade de melhorias de performance. 

Objetos Grandes

O interesse no uso de Objetos Grandes está crescendo, particularmente para o armazenamento de tipos de dados não tradicionais, como por exemplo: imagens. A base Oracle é capaz de armazenar objetos grandes já faz algum tempo. O Oracle 8 introduziu a capacidade de usar múltiplas colunas LOB numa mesma tabela. Já o Oracle 10g essencialmente eliminou a limitação de tamanho para esses objetos. E a versão 11g melhorou muito a performance de consultas e operações de inserção usadas com LOBs ao introduzir os SecureFiles. Criptografia de dados transparente está disponível para dados LOB em SecureFiles.

Programação Orientada a Objetos

Suporte para estruturas de objetos existe desde o Oracle 8i para permitir o uso de uma abordagem orientada a objetos para a programação. Por exemplo, desenvolvedores podem criar tipos de dados personalizados, completos com seus próprios métodos e atributos. O suporte para objetos no Oracle inclui uma característica chamada Visualização de Objetos através da qual programas orientados a objeto podem fazer uso de dados relacionais já armazenados na base. Pode-se também armazenar objetos na base de dados como matrizes variantes, tabelas aninhadas ou tabelas organizadas por índices.

Linguagens de Terceira Geração (3GLs)

Programadores podem interagir com a base de dados Oracle em C, C++, Java ou COBOL, ao incluir SQL nos aplicativos. Antes de compilá-los usando ferramentas nativas de plataformas específicas, deve-se executar o código SQL incluído usando-se um pré-compilador. Ele substitui os comandos SQL com chamadas para bibliotecas de código que o compilador pode aceitar. O Oracle dá suporte para essas características através de pré-compiladores “programadores” para C e C++ usando Pro C e, para COBOL, usando Pro COBOL. Em versões recentes do Oracle, foi incluído o SQLJ, um pré-compilador para Java que substitui comandos SQL incluídos em código nessa linguagem com chamadas para a biblioteca SQLJ de tempo de execução, também escrita em Java.

Acesso a Dados

Todas as versões do Oracle incluem drivers para a base de dados que permitem que aplicativos efetuem acesso usando ODBC ou JDBC. Também disponíveis estão fornecedores de dados para OLE DB e .NET.

A Interface de Chamada Oracle

Se você é um programador experiente que procura otimizar performance, pode escolher definir seus comandos SQL dentro de sequências de caracteres contidas em linguagens de programação e então explicitamente forçar a análise dessas sequências, vincular variáveis ao resultado e, então, executar a consulta usando a Interface de Chamada Oracle. A OCI é uma interface muito mais detalhada que exige mais tempo e esforço de programação para criação e depuração. Desenvolver um aplicativo que use a OCI pode consumir muito tempo, mas a funcionalidade adicional e o ganho incremental de performance conseguidos em alguns cenários podem fazer valer a pena empregar esse tempo extra. Em outros cenários, pode-se conseguir somente uma vantagem ou outra. Por exemplo, numa implementação de ambiente que exija alta disponibilidade em que múltiplos sistemas compartilhem discos usando os Agrupamentos Reais de Aplicativos, poderia-se escrever programas usando a OCI para permitir que usuários sejam conectados de forma transparente num segundo servidor se a primeira conexão falhar.

Suporte para Linguagens Nacionais

O Suporte para Linguagens Nacionais providencia conjuntos de caracteres e funcionalidades associadas, como formatos de data e hora, para uma série de linguagens. A base de dados Oracle 11g dá suporte para o Unicode 5.0. Todos os dados podem ser armazenados em Unicode, ou colunas selecionadas podem ser incrementalmente armazenadas dessa forma. A codificação UTF-8 e UTF-16 dão suporte a mais de 57 linguagens e 200 conjuntos de caracteres. Capacidade de localização extensiva está disponível, e locais personalizados podem ser adicionados através de Construtor de Locais Oracle. Também está incluso um Kit de Ferramentas de Globalização para criar aplicativos que serão usados em múltiplas linguagens.

Extensão de Base de Dados

A Internet e as intranets corporativas criaram uma crescente demanda por armazenamento e manipulação de tipos de dados não tradicionais dentro das bases de dados. Existe uma necessidade de adicionar extensões à funcionalidade padrão de uma base de dados para armazenar e manipular imagens, áudio, video e uma série de informações espaciais e de tempo. Essas capacidades são possibilitadas através de extensões ao SQL tradicional.

Multimídia Oracle

A Multimídia Oracle permite manipulação de texto e adiciona funções para imagens, áudio, vídeo e de localização na base de dados. As seguintes principais funções ficam disponíveis:
     - a porção de texto da Multimídia pode identificar a essência de um documento ao pesquisar por temas e frases chave dentro dele;
     - a porção de imagem da Multimídia pode armazenar e recuperar imagens em vários formatos. A partir da versão 11g, o tipo de imagem média DICOM foi incluído;
     - as partes de áudio e vídeo da Multimídia podem armazenar e recuperar trechos desses tipos de mídia;
     - a porção de localização da Multimídia pode recuperar dados que incluem informações sobre coordenadas espaciais. 

Gerenciamento de Conteúdo Oracle

As soluções de gerenciamento de conteúdo incluem uma Opção de Base de Dados de Conteúdo usada para armazenar e gerenciar documentos na base de dados e aplicativos de gerenciamento de conteúdo da Stellent, que foi comprada pela Oracle em 2007. Esses aplicativos incluem Gerenciamento de Conteúdo Universal, Gerenciamento Universal de Registros e Gerenciamento de Direitos Autorais.

Capacidade de Pesquisa do Oracle

O Servidor de Aplicativos e de Base de Dados Oracle inclui uma ferramenta de pesquisa chamada Ultra Search. A Ultra Search é tipicamente usada para pesquisar e recolher informações de localização para dados de texto armazenados dentro da rede de uma empresa. Recuperação de documentos é baseada em direitos de acesso de usuários. Adicionalmente, o Oracle oferece a Pesquisa Empresarial Segura como alternativa, e esta é mais flexível em ambientes externos ao Oracle.

Opção Espacial Oracle

A Opção Espacial está disponível na Edição Empresarial do Oracle. Ela pode otimizar a exibição de recuperação de dados associados a coordenadas e é usada no desenvolvimento de sistemas espaciais de informações. Muitos produtos de vendedores de Sistemas de Informações Geográficas agora incluem essa opção e a utilizam como seu sistema primário de pesquisa e recuperação.

XML DB

O Oracle adicionou suporte nativo para tipos de dados XML na base de dados 9i e interoperação entre XML e SQL para pesquisa. O objeto XML estruturado é mantido nativamente no armazenamento de objetos relacionais, o que atende os requisitos para a DOM da W3C. A sintaxe do Xpath para pesquisar em SQL é baseada nas especificações do grupo SQLX, e XQuery também é aceita.

Características de Conexão com Bases de Dados

A conexão entre o cliente e o servidor de base de dados é um componente chave da arquitetura geral. Ela é responsável por todas as comunicações entre um aplicativo e os dados usados. O Oracle possui várias características para estabelecer e ajustar conexões com bases de dados.

Bancos de Dados em Rede

O Oracle disponibiliza uma série de características para estabelecer conexões entre usuários e bases de dados e/ou entre servidores, conforme descrito a seguir.

Rede Oracle: Pode-se utilizar a Rede Oracle sobre diversos protocolos de rede, embora TCP/IP seja de longe o mais comum em uso atualmente. Características associadas com a Rede Oracle, como por exemplo, os servidores compartilhados, são conhecidas como Serviços de Rede Oracle.

Diretório de Internet Oracle:  O Diretório de Internet Oracle dá aos usuários uma forma de se conectar com um servidor oracle sem a necessidade de um arquivo de configuração no lado do cliente. O OID é um diretório LDAP e suporta a Rede Oracle e outros protocolos que aceitam LDAPs.

Gerenciador de Conexões Oracle: O Gerenciador de Conexões Oracle, ilustrado na figura a seguir, reduz o número de conexões para clientes de Rede Oracle através do uso de concentradores, que permitem multiplexação de conexões com bases de dados, implementando múltiplas delas usando apenas uma única conexão de rede. Multiplexação de conexões é mais benéfica quando existe um grande número de usuários ativos.

Concentradores com Gerenciadores de Conexões para grande número de usuários

Pode-se também usar o Gerenciador de Conexões para conseguir conectividade entre vários protocolos se, por exemplo, existirem clientes e servidores que não estejam usando TCP/IP e outros que estejam.

Servidor de Aplicativo Oracle

A popularidade de aplicativos para Internet e intranet conduziu a uma mudança nos modelos de distribuição de cliente/servidor para uma arquitetura de três camadas. O Servidor de Aplicativos Oracle permite distribuir a camada intermediária em soluções de três camadas para aplicativos baseados na web, para os baseados em componentes, e também permite a integração de aplicativos empresariais. É um componente chave do Middleware Fusion e pode ser empregado através de múltiplos servidores de camada intermediária.

O produto inclui um listener baseado no popular listener Apache, e também servlets e JavaServer Pages, lógica de negócios, e/ou componentes de acesso a dados. A lógica de negócios frequentemente é distribuída como Enterprise JavaBeans. Componentes de acesso a dados podem incluir JDBC, SQLJ, e EJBs. Uma ferramenta, TopLink, permite mapeamento que associa objetos Java com a base de dados via JDBC de forma que o desenvolvedor Java não precisa usar chamadas SQL nem ter que enfrentar aplicativos Java que falham depois que um esquema de base de dados é alterado.

O Servidor de Aplicativos Oracle oferece soluções adicionais nas áreas de cache, portal, inteligência de negócios e conexão sem fio:

     Cache - O Web Cache do Servidor de Aplicativo Oracle introduz uma camada intermediária para cache de páginas ou de parte delas.

     Portal - O Application Server Portal é também parte do Ferramental do Desenvolvedor Oracle e é usado para criar painéis de controle empresariais fáceis de usar. O portal desenvolvido é distribuído pelo Servidor de Aplicativos.

     Inteligência de Negócios - Componentes da Application Server Business Intelligence incluem o Portal, bem como as ferramentas de inteligência de negócios originais do Oracle:
          - relatórios Oracle, que servem como uma camada intermediária escalonável para relatar os resultados de consultas construídas previamente;
          - o Descobridor Oracle, para consultas instantâneas e análise;
          - uma plataforma de distribuição para OLAP JDeveloper personalizado e para aplicativos de mineração de dados.

     Comunicação Sem Fio Oracle - A Comunicação Sem Fio Oracle inclui:
          - adaptadores para transformar conteúdo em XML;
          - transformadores de dispositivo para converter XML para linguagens de marcação específicas de certos aparelhos;
          - portais de personalização para configuração pessoal de serviços de alerta, de endereços de alerta, marcas de posição e perfis. O portal de personalização sem fio é também usado para criar, servir, testar e publicar serviços de URL e para gerenciamento de usuários.

O Servidor de Aplicativos Oracle está disponível em diversas edições: na Empresarial, Padrão, Padrão Um e edição Java, e esta inclui componentes chave para desenvolvedores Java. Incluídos na Edição Padrão e na Padrão Um estão o Portal, o TopLink com o Framework de Devenvolvimento de Aplicativos e o WebCache. A edição empresarial acrescenta as seguintes capacidades: Serviços de Formulário, Serviços de Relatórios, Visualizador de Descobridor, Diretórios de Internet Oracle, Interconexão de Aplicativos Oracle, Opção Sem Fio e integração com o Barramento de Serviços Empresariais. A edição Java inclui um servidor HTTP, OC4J e o TopLink com o Framework de Desenvolvimento de Aplicativos.

A edição Empresarial do Servidor de Aplicativos Oracle tem muitas opções disponíveis incluindo:

     Opção BPEL de Gerenciador de Processos:  A Linguagem de Execução de Processos Empresariais da Oracle é uma ferramenta projetada para embientes utilizando a Arquitetura Orientada a Serviços e é usada para criar, gerenciar e distribuir processos empresariais usados através da fronteira de aplicativos. Ela suporta padrões como Serviços Web, XML, XSLT, Xpath, JMS e JCA.

     Monitoramento de Atividades de Negócios: O Monitoramento de Atividades de Negócios é usado para criar painéis de controle em tempo real que exibem indicadores chave de performance e que sejam povoados com dados retirados de alertas monitorados via Internet.

     Publicador BI: Uma ferramenta de criação e publicação de relatórios usada para gerar informes de alta fidelidade a partir de dados XML.

     Registro de Serviços: O Registro de Serviços Oracle permite publicar e informar a respeito de serviços e fornece um Sistema de Registro para serviços SOA.

     Ferramental SOA para o Middleware Oracle: Agrupa os itens do Middleware Fusion da Oracle, os de SOA incluindo BPEL, BAM, sistema de regras de negócios, Barramento de Serviços Empresariais, Gerenciamento de Serviços Web, Registro de Serviços Web e adaptadores de aplicativos e tecnologias.

     Servidor de Comunicação e Mobilidade: Esse pacote inclui o TimesTen, e também um Contêiner de Servlets SIP, framework para instâncias de habilitadores, acessos via voz e móvel.

     WebCenter: O WebCenter é o framework de portal mais recente da Oracle usado para desenvolver portlets e componentes baseados em Ajax, especialmente em ambientes Web 2.0. Ele inclui fóruns de discussão, servidores de presença, clientes de mensagens instantâneas, Wiki, configuração e finalização de chamadas VOIP, Contêiner de Servlets SIP, APIs para Serviços Web e Java, integração Click-2-dial e cliente com reconhecimento de voz.

     Adaptadores para o Middleware Fusion: Incluem Aplicativos, Monitores de Processamento de Transações, EDI e outros.

O Ferramental SOA do Middleware Fusion serve como base para a Arquitetura de Integração de Aplicativos Oracle. A AIA também possui objetos de negócios e processos empresariais conhecidos como Pacotes de Integração de Processos e fornece alicerces chave usados para integrar aplicativos atuais e futuros da Oracle.

Características de Bases de Dados Distribuídas

A base de dados Oracle é conhecida por sua capacidade de lidar com volumes de dados e número de usuários extremamente altos. O Oracle não apenas se escalona através da distribuição de plataformas unitárias cada vez mais poderosas, mas também pode ser usado em configurações distribuídas. O Oracle distribuído em múltiplas plataformas pode ser combinado para agir como uma única base de dados lógica.

Transações e Consultas Distribuídas

Consultas distribuídas podem recuperar dados de múltiplas bases. Transações distribuídas podem inserir, atualizar ou apagar dados em bases de dados distribuídas. O mecanismo de efetivação de duas fases da Oracle garante que todos os servidores de bases de dados, que façam parte de uma transação, ou efetivem ou voltem atrás e desfaçam a transação. Processos de recuperação executando ao fundo garantem consistência nas bases de dados caso algum sistema seja interrompido durante uma transação distribuída. Assim que o sistema que falhou retornar, o mesmo processo vai completar a transação.

Transações distribuídas podem também ser implementadas usando os populares monitores de transações que interagem com o Oracle via XA, um padrão empresarial de interface. Pode-se também implementar uma transação coordenada iniciada sob controle do MTS através de uma base de dados Oracle.

Serviços Heterogêneos

Serviços Heterogêneos permitem que serviços e dados externos ao Oracle sejam acessados a partir de uma base de dados Oracle usando formas de conectividade genéricas como ODBC e OLE DB.

Portais Opcionais Transparentes usam agentes especificamente criados para uma variedade de sistemas alvos. Eles permitem que usuários executem comandos SQL do Oracle para fontes de bases de dados distribuídas que não sejam da Oracle, fazendo com que eles sejam automaticamente traduzidos para o dialeto SQL dos sistemas alvos, o que é transparente para o usuário. Os Serviços Heterogêneos também funcionam de maneira similar ao prestar serviços relativos a transações utilizando a efetivação de duas fases do Oracle para outras bases de dados e também serviços procedurais que chamam rotinas em linguagens de terceira geração em sistemas que não sejam da Oracle. Os usuários interagem com a base Oracle como se todos os objetos estivessem armazenados nela, e os Serviços Heterogêneos permitem, para benefício desses usuários, interação transparente com bases externas. 

Características de Deslocamento de Dados

Mover dados de uma base Oracle para outra é frequentemente uma necessidade quando usando bases distribuídas, ou quando um usuário quer implementar múltiplas cópias da mesma base em vários locais para reduzir o tráfego de rede ou aumentar a disponibilidade dos dados. Pode-se exportar dados e metadados de uma base e importá-los em outra.

O Oracle também oferece muitas outras características avançadas nesta categoria, incluindo espaços transportáveis de tabelas, Enfileiramento Avançado/Fluxos Oracle e soluções de Extração, Transformação e Carga.

Espaços Transportáveis de Tabelas

Pode-se colocar um espaço de tabela em modo apenas leitura, movê-lo ou copiá-lo de uma base de dados para outra, e então reativá-lo. O mesmo dicionário de dados descrevendo o espaço de tabelas deve existir na fonte e no destino. Essa característica pode poupar muito tempo uma vez que simplifica a movimentação de grandes quantidades de dados.

Pode-se mover dados com os espaços transportáveis de tabelas entre plataformas ou sistemas operacionais heterogêneos.

Enfileiramento Avançado e Fluxos Oracle

O Enfileiramento Avançado, fornece os meios para enviar mensagens assíncronas de uma base Oracle para outra. Já que as mensagens são armazenadas numa fila de uma base e enviadas assincronamente quando uma conexão é estabelecida, a quantidade de trabalho computacional e de tráfego de rede é muito menor do que seria usando métodos de entrega garantida através do protocolo de efetivação de duas fases entre a fonte e o destino. Ao armazenar as mensagens na base de dados, o AQ oferece uma solução com grande capacidade de recuperação no caso de erros do que qualquer outra solução de enfileiramento de mensagens que armazenam seus dados nos sistemas de arquivos.

O sistema de mensagens do Oracle ainda oferece a capacidade de desenvolver e distribuir soluções de inscrição e publicação baseadas em conteúdo usando um sistema de regras para determinar aplicativos relevantes para inscrição. Conforme novos conteúdos são publicados para uma lista de inscritos, as regras dessa lista determinam quais dos inscritos devem receber esse conteúdo. Essa abordagem implica que uma única lista pode atender eficientemente as necessidades de diferentes comunidades de assinantes.

O AQ se tornou parte dos Fluxos Oracle. Estes tem três componentes principais: replicação baseada em logs para captura de dados, enfileiramento para staging de dados, e regras definidas pelo usuário para consumo de dados. Os Fluxos também apresentam suporte para captura de alteração de dados e soluções de transferência de arquivos. Os Fluxos são gerenciados usando o Gerenciador Empresarial.

Extração, Transformação e Carga

O Criador de Centros de Dados Oracle é uma ferramenta usada na criação de bases de dados, especialmente de armazenamento de dados empresariais de análise, e fornece um repositório de metadados. Entretanto, é mais conhecido como uma ferramenta baseada em GUI usada para criar mapeamentos entre fonte e destino e gerar scripts de extração, transformação e carga. O OWB se utiliza de características nativas chave de ETL na base de dados Oracle.

Opcionalmente, a Oracle também oferece uma ferramenta de integração de dados, o Integrador de Dados Oracle, que não é tão centrada em dados de bases Oracle como é o OWB. O Integrador de Dados Oracle é baseado num produto chamado Sunopsis. Além de acrescentar capacidades de ETL, o ODI pode gerar código como serviço web para distribuição SOA e é uma parte chave da estratégia de integração SOA da Oracle.

Características de Performance de Base de Dados

O Oracle inclui muitas características especialmente projetadas para melhorar a performance em certas situações. Dividimos a discussão nas seguintes subseções em duas categorias: paralelismo de base de dados e centros de dados.

Paralelismo de Base de Dados

Tarefas de bases de dados implementadas em paralelo aumentam a velocidade de enfileiramento, ajuste e manutenção da base. Ao dividir uma tarefa única em partes menores e atribuindo cada subtarefa para um processo independente, pode-se melhorar dramaticamente a performance de certos tipos de operações de base de dados. Exemplos de características de consulta implementadas em paralelo incluem:

     - escaneamento de tabelas;
     - laços aninhados;
     - ordenação de junções de dados;
     - agrupamento usando GROUP BY;
     - sub-consultas do tipo NOT IN;
     - funções definidas pelo usuário;
     - escaneamento de índices;
     - uso de select distinct UNION e UNION ALL;
     - junções de hash;
     - uso de ORDER BY e agrupamento;
     - junções de mapas de bits em consultas estrela;
     - junções em nível de partição;
     - procedimentos armazenados.

Além de consultas em paralelo, muitas outras características do Oracle apresentam paralelismo. 

Centros de Dados e Inteligência de Negócios

Características paralelas melhoram a performance geral da base de dados Oracle, mas melhorias particulares de performance para inteligência de negócios e centros de dados também existem na base.

Mapas de Bits Índices

O Oracle tem um suporte para mapas de bits índices armazenados como uma maneira de providenciar uma forma rápida de selecionar e recuperar alguns tipos de dados. Os mapas de bits índices tipicamente funcionam melhor para colunas que tenham poucos valores diferentes com relação ao número geral de linhas numa tabela.

Em vez de armazenar o valor em si, um índice mapa de bits usa um bit individual para cada valor em potencial, e ele pode estar ativo indicando que a linha contém um valor, ou desligado, para mostrar que a linha não contém um valor.

Otimização de Consultas Estrela

Consultas típicas em centros de dados ocorrem contra uma grande tabela de fatos com chaves estrangeiras para tabelas de dimensão muito menores. O Oracle utiliza um mecanismo chamado junção estrela paralela de mapa de bits, que usa bits índices nas chaves estrangeiras para as tabelas de dimensão para acelerar as junções estrela envolvendo um grande número de tabelas de dimensão.

Visualizações Materializadas

Visualizações materializadas são outra forma de conseguir um aumento significativo de velocidade de consulta. Informação sumarizada derivada de uma tabela de fatos e agrupada ao longo de valores de dimensão é mantida como uma visualização materializada. Consultas que podem usar essa visualização são redirecionadas para ela, de forma transparente para o usuário e para o SQL da consulta inicial.

Funções Analíticas

Uma tendência crescente no Oracle e em outras bases de dados é a inclusão de funções estatísticas e analíticas acessíveis via SQL. O Oracle apresenta as funções CUBE, ROLLUP, classificação, agrupamento por janelas, análise de resultado/desempenho, agrupamento de relatórios, agrupamento estatístico, regressão linear, estatística descritiva, correlação, tabulação cruzada, teste de hipótese, enquadramento em distribuições e análises Pareto.

Opção OLAP

A Opção OLAP fisicamente armazena cubos cientes de dimensão na base de dados relacional Oracle. Esses cubos são mais frequentemente acessados usando SQL, embora uma API Java também exista. O otimizador do Oracle reconhece os níveis dentro desses cubos. Como resultado, qualquer ferramenta de inteligência de negócios que envie SQL para uma base de dados Oracle pode se aproveitar de forma transparente da melhoria de performance oferecida por essa opção. A atualização dos valores nesses cubos são mantidos de forma similar à atualização das visualizações materializadas.

Opção de Mineração de Dados

Algoritmos populares de mineração de dados tem sido incluídos na base de dados através da Opção de Mineração de Dados e são expostos através do PL/SQL ou da API de mineração de dados Java. Aplicativos de mineração de dados que usem esses algoritmos são frequentemente feitos usando o Minerador de Dados Oracle ou outras ferramentas para isso de parceiros da Oracle como InforSense ou SPSS. Algoritmos disponíveis nessa opção da versão 11g incluem análise de Associações Bayesianas ingênuas, Redes Bayesianas Adaptivas, Agrupamento, Máquinas de Vetor de Suporte, Fatoração Não Negativa de Matrizes, Árvores de Decisão e Modelos Lineares Generalizados.

Ferramentas de Inteligência de Negócios

O produto principal da Oracle nessa área é o Ferramental Edição Empresarial de Inteligência de Negócios Oracle, que inclue Respostas Oracle, Painéis de Controle, Entregas, Publicador de BI, componentes para o Office, Serviços Fundamentais, Relatórios Interativos, relatórios de produção SQR, Relatórios Financeiros, SmartView para o Office e Web Analysis.

Como uma opção para providenciar um cubo OLAP e funcionalidade independente das capacidades para centros de dados da base temos a Essbase. Um subconjunto do OBI EE faz parte do Inteligência de Negócios Edição Padrão Um, junto com a base de dados Oracle Edição Padrão Um e o Criador de Centros de Dados Oracle.

A Oracle também oferece aplicativos de inteligência de negócios que incluem modelos de dados e relatórios e análises com metadados de negócios pré-criados. Aplicativos importantes que podem ser citados são os Aplicativos de Inteligência de Negócios Oracle e os aplicativos de Gerenciamento de Performance Financeira Hyperion.

Características de Gerenciamento de Base de Dados

O Oracle inclui muitas características que fazem a base de dados mais fácil de gerenciar.

As estatísticas são automaticamente reunidas num Repositório Automático de Carga de Trabalho dentro da base de dados. O Monitor Automático de Diagnóstico de Base de Dados da Oracle faz avaliações das estatísticas em intervalos regulares e envia alertas de potenciais condições problemáticas para o Gerenciador Empresarial Oracle, onde a condição pode ser analisada em mais detalhes e ações corretivas podem ser adotadas. Algumas das características novas totalmente automáticas, como o Gerenciamento Automático de Memória também se aproveitam de dados do AWR.

O Oracle apresenta uma visualização atualizada quase em tempo real das condições atuais da base de dados conforme vai fazendo recomendações automáticas.

Gerenciador Empresarial Oracle

O Gerenciador Empresarial Oracle serve como um ferramental de gerenciamento de base de dados e uma interface baseada em HMTL usada para gerenciar usuários, instâncias e características de bases de dados. O EM pode também gerenciar o Servidor de Aplicativos Oracle, os Aplicativos Oracle, a versão do Oracle para Linux, e produtos de software de outros fabricantes.

O console de base de dados na versão atual do Oracle fornece informações sobre o estado da base de dados, sua disponibilidade, esquema, configuração de movimentações de dados e manutenção de software. O Balcão de Atendimento e a infra-estrutura de diagnósticos servem para relatar problemas para o Suporte Oracle. Vários administradores de bases de dados podem acessar o repositório do EM todos ao mesmo tempo.

O EM pode ser distribuído de muitas formas: como um console central para monitorar múltiplos agentes de suporte de base de dados, como um “console de produtos”, ou através de acesso remoto, também conhecido como “modo estúdio”. Quando distribuído como um console central, o Gerenciador Empresarial é chamado de “Controle de Grade”, e pode ser usado para instalação rápida de programas da Oracle, para provisionamento e instalação automática de atualizações de correção de softwares ativos.

Um subconjunto da funcionalidade do Gerenciador Empresarial é acessível através do Internet Explorer para Computadores de Bolso da Microsoft em PDAs sem fio usando o EM2Go. O EM2Go pode monitorar o estado da base de dados Oracle e do Servidor de Aplicativos.

Gerenciamento de Tempo de Vida de Informação e Assistente ILM

O Gerenciamento de Tempo de Vida de Informação fornece os meios para definir classes de dados e armazená-las em camadas e mover os dados para essas camadas que providenciam a combinação correta de performance e custo.

Cópias de Segurança e sua Recuperação

Como todo administrador de base de dados sabe, fazer cópias de segurança de bases de dados é uma tarefa comum e necessária. Uma cópia mal feita torna a recuperação difícil, se não impossível. Infelizmente, frequentemente se percebe a importância dessa tarefa diária apenas depois de perder dados críticos para negócios ao experimentar falhas de sistemas relacionados.

A seção seguinte descreve algumas das características usadas para realizar operações de cópia de segurança em bases de dados.

Gerenciador de Recuperação

Opções típicas de cópias de segurança incluem copiar a base inteira, cópias de espaços de tabelas, de arquivos de dados, de arquivos de controle e de arquivos de log. O Oracle dispõe do Gerenciador de Recuperação para cópias de segurança e recuperação de bases de dados baseadas em servidores, que pode automaticamente localizar, copiar, recuperar dados e restaurar arquivos de dados, de controle e de logs de repetição. O RMAN pode reiniciar cópias de segurança e implementar políticas de janelas de recuperação quando as cópias expiram. O Gerenciador Empresarial providencia uma interface gráfica para o RMAN. O agendador de tarefas do EM pode ser usado em conjunto com o RMAN para gerenciar cópias de segurança automáticas para o disco.

Cópias de segurança incrementais e sua recuperação

O RMAN pode fazer cópias de segurança incrementais nas bases de dados da Edição Empresarial. Esse tipo de cópia salva somente os blocos modificados desde a última vez que a operação foi efetuada em bases de dados, espaços de tabela ou arquivos. Dessa forma, as cópias serão menores e mais rápidas do que cópias completas. O RMAN pode também executar recuperações de pontos no tempo, o que permite que dados sejam recuperados até exatamente antes de um evento indesejado.

Cópia Segura Oracle

Muitos vendedores de programas de gerenciamento de mídia se apóiam no RMAN da Oracle, mas a a base de dados também inclui uma solução extra de gerenciamento de armazenamento em nível de entrada em fita totalmente independente conhecida como Cópia Segura Oracle XE. Opcionalmente, a Oracle oferece uma solução empresarial simples para cópias de segurança chamada Cópia Segura Oracle.

Disponibilidade de Base de Dados

A disponibilidade de bases de dados depende da confiança e do gerenciamento da base, do sistema operacional e de componentes de hardware específicos do sistema físico. O Oracle tem melhorado a disponibilidade reduzindo o tempo de cópia de segurança e sua restauração ao:
     - providenciar cópias e recuperação online em paralelo;
     - melhorando o gerenciamento de dados online através de faixas de particionamento;
     - se aproveitando de capacidades de hardware para melhorias de monitoramento e de recuperação de falhas.

Opção de Particionamento

A Oracle tem o particionamento como opção para providenciar um alto grau de capacidade de gerenciamento e disponibilidade. Pode-se deixar partições específicas desativadas para manutenção enquanto outras permanecem ativas para acesso pelos usuários. Em implementações de centros de dados, particionamento é algumas vezes usado para implementar janelas móveis baseadas em faixas de datas. Outros tipos de particionamento incluem particionamento de hash e particionamento de listas. Intervalos de particionamento podem também ser usados para automaticamente criar novas faixas fixas conforme elas forem se tornando necessárias durante inserções de dados.

Muitos desses tipos de particionamento podem ser usados em combinação em partições “compostas”. Exemplos incluem faixa-faixa, faixa-hash, faixa-lista, lista-faixa, lista-hash e lista-lista.

Guarda de Dados

A base de dados de salva-guarda é uma cópia da base de produção que pode ser usada se a base de dados primária for perdida. Bases primárias e de salva-guarda podem estar separadas geograficamente. A base de dados de salva-guarda é criada a partir de uma cópia da de produção e é atualizada através do aplicativo de arquivamento de logs de repetição também gerados pela cópia de produção. A Guarda de Dados automatiza completamente esse processo. Antes dela, era preciso copiar e aplicar os logs manualmente. Agentes são distribuídos tanto na base de produção quanto na de salva-guarda, e um Coordenador de Guarda de Dados coordena os comandos. Um comando único da Guarda de Dados invoca os oito passos necessários para recuperação de falhas.

Além de providenciar suporte físico para a base de salva-guarda, a Guarda de Dados pode criar uma base desse tipo, mas lógica. Nesse cenário, os logs de arquivo do Oracle são transformados em transações SQL e aplicados numa base de dados de salva-guarda aberta.

A Guarda de Dados suporta também aplicação de dados de repetição em tempo real, integração com a característica de base de dados conhecida como Flashback, compactação de arquivos de log, atualizações em softwares ativos, consultas, ordenação e relatórios mesmo quando alterações na base de dados de produção estão em curso.

Recuperação de Falhas

A característica de Recuperação de Falhas dá um alto grau de confiabilidade para uma base de dados Oracle. A recuperação é implementada através de um segundo sistema ou nó que permite acesso aos dados contidos num disco compartilhado quando o primeiro sistema ou nó falha. A Recuperação de Falhas Oracle para Windows, em combinação com o Sistema de Agrupamentos Microsoft, constituem uma solução para a ocorrência de problemas no evento de uma falha de sistema.

A Recuperação de Falhas é principalmente uma ferramenta para recuperação de desastres, então o sistema é desativado como parte de uma operação de recuperação. A solução recomendada para disponibilidade de servidor é o Agrupamento Real de Aplicativos.

Agrupamento Real Oracle de Aplicativos

O Agrupamento Real de Aplicativos pode disponibilizar suporte para recuperação de falhas bem como aumentar a escalabilidade em agrupamentos de máquinas Unix, Linux e Windows. A chave para a melhoria de escalabilidade foi a introdução do Cache Fusion, que diminui muito a quantidade de operações de escrita em disco que era usada anteriormente para controlar travamentos de dados.

Com o Agrupamento Real de Aplicativos, pode-se distribuir múltiplas instâncias do Oracle em diversos nós de uma solução em agrupamentos de máquinas ou numa configuração de grade. O RAC coordena o tráfego entre os sistemas ou nós, permitindo que as instâncias funcionem como se fossem uma única base de dados. Como resultados, a base se provou capaz de aumentar de escala por até dezenas de nós. Uma vez que os agrupamentos de computadores funcionam como um meio onde múltiplas instâncias podem acessar os mesmos dados, a falha de uma instância em particular não causa demasiada demora enquanto o sistema se recupera. Pode-se simplesmente redirecionar os usuários para outra instância que ainda esteja operando. Aplicativos podem se aproveitar da Interface de Chamadas Oracle para se recuperar de falhas e redirecionar usuários para outras instâncias de forma transparente.

Guarda de Dados e o RAC

A Guarda permite correção automática com tempo de recuperação determinado em conjunto com o Agrupamento Real Oracle de Aplicativos. Adicionalmente, permite redirecionar clientes para fora das instâncias com falha para outras que estejam disponíveis com reconexão rápida e captura automática de dados de diagnóstico.

Gerenciamento Automático de Armazenamento

O Gerenciamento Automático de Armazenamento permite taxas ótimas de divisão e repetição de dados em função da performance e disponibilidade. Já que o ASM é gerenciado através do Gerenciador Empresarial, o administrador de base de dados agora pode controlar essa tarefa crítica de gerenciamento. A necessidade de coordenar essa atividade com um administrador de sistema é, portanto, mínima.

Opção de Teste Real de Aplicativos

Essa opção inclui um Reprodutor de Base de Dados e o Analisador de Performance de SQL. O Repetidor captura informações de carga de trabalho da base de dados, incluindo acessos simultâneos, dependências e tempos de resposta. Ele transforma os arquivos de dados de informações capturadas em arquivos de repetição, disponibiliza um Cliente de Repetição para processar esses arquivos, e fornece os meios para relatar estatísticas de performance e qualquer erro encontrado. O Analisador de Performance de SQL captura uma carga de trabalho de SQL para ser analisada, mede a performance antes e depois de alterações na base de dados e identifica alterações de performance com relação a comandos SQL.

Características de Segurança de Base de Dados

O Oracle possui segurança básica para gerenciar acesso de usuários através de competências e privilégios. Eles podem ser gerenciados usando o Gerenciador Empresarial de forma local ou global se aproveitando da segurança empresarial do Oracle, uma característica da Opção de Segurança Avançada.

As características de segurança de base de dados permitem que se implementem Bases de Dados Privadas Virtuais usando o Oracle para criar e associar políticas para tabelas, visualizações ou sinônimos. Essas políticas são mantidas colocando-se uma cláusula predicativa WHERE em comandos SELECT, INSERT, UPDATE, DELETE e INDEX.

Muitas empresas enfrentam a necessidade de empregar esquemas mais restritivos para melhorar a proteção de dados, ainda mais que o uso das bases de dados atualmente pode se estender além dos limites da empresa. A Oracle adicionou muitas opções nas bases para permitir distribuição segura em tais ambientes desafiadores. Essas opções incluem a Opção de Segurança Avançada, a de Segurança por Rótulo, o Átrio de Base de Dados e o Átrio de Auditoria.

Opção de Segurança Avançada

As características chave para permitir uma Rede Oracle mais segura incluem o uso de serviços de criptografia como Segurança de Dados RC4 da RSA, o DES, o DES Triplo e o AES. A autenticação pode ser através do Kerberos, RADIUS ou do Ambiente de Computação Distribuída. Checagens de integridade de dados em redes usam o MD5 ou o SHA-1.

Opção de Segurança de Rótulo

A Segurança de Rótulo Oracle controla acesso a dados ao comparar rótulos associados com linhas de dados com autorizações que também usam rótulos atribuídos aos usuários através de seus privilégios. Múltiplos níveis de autorização são possíveis dentro de uma mesma base de dados. Autorizações de segurança de rótulo são gerenciadas através de um Gerenciador de Políticas. Políticas são mantidas diretamente na base de dados em vez de através de visualizações, dessa forma simplificando muito o gerenciamento de acesso a dados e permitindo uma implementação mais segura.

Opção de Átrio de Base de Dados

A Opção de Átrio de Base de Dados Oracle permite controle refinado de acesso a dados para todos que possam interagir com a base, incluindo os administradores. O administrador de segurança pode criar fatores para definir capacidade de acesso à base e auditar dimensões específicas de segurança. Num nível ainda mais detalhista, domínios de dados podem ser definidos para limitar o acesso para esquemas e competências específicos.

Servidor de Átrio de Auditoria

O Servidor de Átrio de Auditoria Oracle monitora as tabelas de auditoria da base de dados, os logs de repetição de dados e os arquivos de auditoria do sistema operacional à procura de atividades suspeitas. Ele pode gerar relatórios ou enviar alertas quando essas atividades incomuns ocorrerem.

Ferramentas de Desenvolvimento Oracle

Muitas ferramentas da Oracle estão disponíveis para desenvolvedores para ajudar a apresentar dados e desenvolver aplicativos Oracle mais sofisticados.

JDeveloper Oracle

O JDeveloper permite o desenvolvimento de aplicativos Java básicos sem a necessidade de escrever o código. Ele inclui um assistente de Formulário de Dados, um assistente rápido para Beans para criar JavaBeans e classes BeanInfo e um assistente de Distribuição. Inclui também características de desenvolvimento de bases de dados como os diversos drivers Oracle, um Editor de Conexões para ocultar a complexidade da API JDBC, componentes de dados para vincular a controles visuais e um pré-compilador SQLJ para embutir SQL no código Java de forma a possibilitar seu uso com as bases Oracle. Pode-se também distribuir aplicativos desenvolvidos usando o JDeveloper usando o Servidor de Aplicativos Oracle. Embora o JDeveloper use assistentes para permitir que programadores criem objetos Java sem escrever o código, o resultado final é gerado através de código desse tipo.

Desenvolvedor de SQL Oracle

O Desenvolvedor de SQL Oracle pode ser usado para conectar qualquer base de dados Oracle. Ele pode criar conexões para as bases, navegar pelos objetos nelas, criar e modificar objetos, consultar e atualizar dados, exportar dados e comandos de definição de dados, importar dados, processar comandos e criar e executar relatórios. As ferramentas do produto suportam edição, depuração e execução de scripts PL/SQL. Além disso, o Desenvolvedor SQL pode ser apontado para bases que não sejam da Oracle para visualizar seus objetos particulares e dados e tem a capacidade de iniciar uma migração para uma base de dados Oracle.

Desenvolvedor de Formulários Oracle

O Desenvolvedor de Formulários Oracle é uma ferramenta para criar aplicativos baseados em formulários e gráficos para distribuição no padrão tradicional cliente/servidor ou como programas em arquiteturas de três camadas baseados em navegadores, tudo através do Servidor de Aplicativos. Ele é uma linguagem de desenvolvimento de quarta geração. Com uma 4GL, define-se aplicativos ao atribuir valores para propriedades, em vez de escrever código procedural. O produto suporta uma ampla variedade de clientes, incluindo programas comuns do padrão cliente/servidor e baseados em Java. Ele também inclui uma JVM embutida para executar previamente aplicativos destinados à Internet.

Desenvolvedor de Relatórios Oracle

O Desenvolvedor de Relatórios Oracle fornece um ambiente para desenvolvimento e distribuição rápidos de relatórios baseados na Internet usando o Relatórios para o Servidor de Aplicativos Oracle. Os dados podem ser formatados em tabelas, matrizes, relatórios de grupos, gráficos e em combinações destes. Apresentação de alta qualidade é possível usando CSS.

Designer Oracle

O Oracle Designer fornece uma interface gráfica para Desenvolvimento Rápido de Aplicativos para todo o processo de desenvolvimento de bases de dados. Projetos e alterações são mantidos num repositório multiusuário. Essa ferramenta pode fazer engenharia reversa em tabelas e esquemas de bases de dados existentes para reutilização e re-projeto com bases da Oracle e de outras empresas.

O Designer também inclui geradores para criar aplicativos para o Desenvolvedor Oracle, clientes HTML que usam o Servidor de Aplicativos, e em C++. O Designer pode gerar aplicativos ou fazer engenharia reversa em programas existentes ou outros que tenham sido alterados por desenvolvedores. Essa capacidade permite um processo chamado engenharia em ciclos, no qual um desenvolvedor gera um aplicativo, modifica-o, e então faz a engenharia reversa dessas alterações e as armazena no repositório do Designer.

Edição de Administração do Descobridor Oracle

A Edição de Administração do Descobridor Oracle permite que administradores configurem e mantenham a Camada de Usuário Final do Descobridor para as gerações anteriores de ferramentas de inteligência de negócios da Oracle. Essa camada serve para proteger da complexidade do SQL as análises de negócios que usam o Descobridor como uma ferramenta de análise de consultas instantâneas. Assistentes guiam o administrador através do processo de criar um EUL. Além disso, os administradores podem estabelecer limites para os recursos disponíveis para analistas, o que é monitorado pelo controlador de consultas Descobridor.

Portal Oracle

O Portal Oracle é uma ferramenta baseada em HTML para desenvolver aplicativos que se aproveitam da Internet e para páginas de Internet baseadas em conteúdo. Sistemas de aplicativos Portal são desenvolvidos e distribuídos num ambiente simples de navegador. O Portal inclui assistentes para desenvolver componentes de aplicativos incorporando “servlets” e acesso a outros sites HTTP. O Portal pode ser programado para ser personalizável pelos usuários e é distribuído como camada intermediária do Servidor de Aplicativos Oracle.

Bases de Dados Embutidas

Embora a família de bases de dados Oracle possa ser distribuída para aplicativos embutidos, seu tamanho e funcionalidade podem ser mais do que é necessário. Hoje em dia, a Oracle oferece outras bases de dados embutidas incluindo a TimesTen, a BD Berkeley e a Base de Dados Leve Oracle. Esses sistemas de base de dados tem código-fonte exclusivo feito para diminuir seu tamanho e servir a diferentes propósitos.

TimesTen Oracle

O TimesTen da Oracle é uma base de dados relacional que é armazenada na memória física e é tipicamente usada quando cargas de trabalho muito altas de processamento de transações de alta performance são necessárias. Acesso para a base de dados TimesTen é possível via SQL, JDBC, JMS e ODBC. Essas bases podem ser distribuídas como exclusivas ou compartilhadas e podem ser criadas como permanentes ou temporárias.

A base é atualizada recolhendo dados usando as bibliotecas TimesTen distribuídas em aplicativos ou através do uso de uma opção de Conexão de Cache a uma base de dados Oracle. Porque os dados são lidos e atualizados na memória, o tempo de resposta médio de atualização ou leitura é tipicamente medido em milionésimos de segundo. A opção de Conexão de Cache suporta cache tanto de leitura quanto de escrita para dados das bases Oracle. As atualizações podem ser bidirecionais entre o TimesTen e o Oracle.

Como é comum para bases de dados embutidas, o TimesTen exige quase nenhuma administração à medida que executa. Replicação é possível entre uma base TimesTen e outra através de uma opção e ela é feita, por padrão, de forma assíncrona.

BD Berkeley da Oracle

O Berkeley DB da Oracle é uma base de dados embutida extremamente pequena que permite travamento de dados em nível de registro. Ela vem em versões Java e XML. É projetada para ser distribuída com e executar no mesmo processo que um aplicativo. Quando essa base é distribuída dessa forma, nenhuma administração de base de dados em separado é necessária. O tamanho dessa base quando vazia pode ser tão pequeno quanto 400KB.

A edição Java da base suporta a API de Transações Java, a Arquitetura de Conexão J2EE, e as Extensões de Gerenciamento Java. A base de dados é um único arquivo JAR que tem 820KB e executa na mesma Máquina Virtual Java que o aplicativo. Uma Camada de Persistência Direta é suportada para acessar objetos Java.

A Edição XML da BD Berkeley é usada com mais frequência em aplicativos baseados em rede onde o conteúdo é gerenciado. XQuery e Xpath são suportados.

Ambas as edições podem ser configuradas para alta disponibilidade usando replicação. Recuperação automática é também suportada. Decisões de distribuição como essas são feitas pelo desenvolvedor do aplicativo durante o tempo de projeto do programa.

Oracle Lite

O Oracle Lite é um conjunto de produtos que permite o uso em dispositivos portáteis de aplicativos centrados em bases de dados. Componentes chave do Oracle Lite incluem a Base de Dados Oracle Lite, o Kit de Desenvolvimento Portátil e o Servidor Portátil.

A base de dados Oracle Lite tem de 50KB a 1MB dependendo da plataforma. Aplicativos escritos usando SQL Portátil, C++ e Java podem ser usadas com essa base. ODBC também é suportado. O suporte a Java inclui procedimentos armazenados Java e JDBC. A base Lite é também projetada para ser auto-ajustável e auto-administrável e é suportada em dispositivos portáteis que executem Windows CE, Symbian, Windows e Linux.

Num uso típico do Oracle Lite, o usuário vai conectar seu dispositivo portátil executando a base Lite num servidor de base de dados Oracle muito maior. Os dados são então automaticamente sincronizados entre os dois sistemas. O usuário então encerrará a conexão e trabalhará desconectado. Depois de ter efetuado suas tarefas, ele vai conectar e sincronizar novamente os dados com o servidor da base maior.

O Oracle Lite suporta uma variedade de capacidades de sincronização, incluindo as seguintes:
     - sincronização bidirecional entre o dispositivo portátil e as bases de dados maiores;
     - modelos baseados em Publicação/Inscrição;
     - suporte para protocolos como TCP/IP, HTTP, CDPD, 802.1 e HotSync.

Pode-se definir replicação baseada em prioridades para subconjuntos de dados. Porque dados distribuídos em vários locais podem levar a conflitos a resolução automática de conflitos foi disponibilizada. Pode-se também personalizar isso.

O Servidor Portátil serve como plataforma única para publicar, distribuir, sincronizar e gerenciar os aplicativos de dispositivos portáteis. O centro de controle baseado na Internet pode ser usado para controlar o acesso para aplicativos de dispositivos portáteis. O antigo produto “Web-to-Go” da Oracle faz também parte do Servidor Portátil e serve como uma forma centralizada baseada em assistentes de desenvolvimento e distribuição de aplicativos.

Ligue a vontade para qualquer celular ou fixo em todo o Brasil, EUA e Canadá, através do 99TelexFREE. Teste nosso serviço por 1 hora gratuitamente: http://www.telexfree.com/ad/marcelmesmo 

Metodologia para implementação de projetos de data warehouse

1. Introdução

Com o advento da computação, surgiram os primeiros programas para transformação de dados em informação. Junto vieram alguns complicadores, como: tempo de processamento, volume de dados, formas de acesso, meios físicos etc. As tecnologias evoluíram, porém o conceito permanece. Transformar dados em informação é a principal razão da existência da informática.

Os primeiros programas comerciais foram criados para auxiliar os processos organizacionais, tais como folhas de pagamento, contabilização e controles de estoque. Apesar da evolução das tecnologias estes aplicativos ainda são tão essenciais quanto os sistemas especialistas.

Com o passar do tempo muitos aplicativos foram desenvolvidos para automatizar os processos. Como conseqüência o volume de dados crescia ainda mais, dificultando a obtenção de informações para análise e tomada de decisão.

Na década de 80 surgiram os primeiros sistemas comerciais para auxílio à tomada de decisão. Tinham como objetivo resumir os dados essências e organizá-los. O crescente volume e a complexidade para obter os dados, de diferentes fontes, tornaram estes aplicativos ineficientes à medida que não disponibilizavam as informações necessárias para tomada de decisão em tempo hábil. Observa-se que não importa ter apenas os dados se a informação não está disponibilizada em momentos decisivos.

Surgiram na década seguinte os sistemas integrados (ERP) que agilizaram processos, otimizando recursos. Como promessa destes mega-sistemas, todas as informações necessárias seriam obtidas a partir deles. Porém, outros sistemas especialistas ainda permaneciam por serem estratégicos e mais eficientes. Permanecia também o problema da disponibilização da informação no momento certo. A concorrência de transações da operação das empresas com busca de informações em altos volumes de dados começaram a comprometer o ambiente. Ficando bem caracterizado a que se destinavam os sistemas integrados: otimizar as transações das empresas.

A evolução das tecnologias de busca de informação para tomada de decisão e a necessidade de organizar os dados motivaram o estudo científico do problema. Um data warehouse é um conjunto de dados baseado em assuntos, integrado, não volátil e variável em relação ao tempo, de apoio às decisões.

A integração dos dados, associadas a técnicas e ferramentas, no data warehouse proporcionam um ambiente de dados organizados por assuntos para obtenção de informações para tomada de decisão. Imagina-se então que o DW seja um ambiente onde todas as informações, para tomada de decisão, são obtidas.

Construir um DW está longe de ser uma tarefa fácil. As técnicas e as ferramentas não são suficientes para garantir o êxito na construção. É necessária uma metodologia capaz de levar à sua implementação. A tentativa de aplicar ferramentas e técnicas de desenvolvimento inadequadas conduz apenas a desperdício e confusão. Por exemplo, no mundo CASE predomina a análise baseada em requisitos. Tentar aplicar as ferramentas e técnicas CASE ao mundo do Data warehouse não é aconselhável e vice-versa. No ciclo de vida do DW predominam os dados e a informação resultante da organização da base de dados.

Mesmo considerando seu desenvolvimento em partes (Data Marts) deve-se ter a visão do todo para garantir a integração das informações. O armazém de dados (DW) não pode ser apenas um repositório, onde os dados de diferentes aplicações estão na mesma base de dados centralizada. Os dados devem estar organizados para refletir a visão do negócio de forma integrada.

A metodologia descrita a seguir tem como objetivo uma orientação para desenvolvimento evolutivo do data warehouse. Dividida em fases bem caracterizadas pelo agrupamento das principais técnicas relacionadas. Ela descreve a finalidade de cada fase, identificando os pontos críticos e descrevendo sucintamente as principais técnicas.

As fases do projeto de implementação do data warehouse, por assunto, são: levantamento de dados, modelagem de dados, extração de dados, modelagem multidimensional, análise de resultados, visões pré-definidas e segurança da informação. Além da descrição das fases do projeto também são abordadas neste trabalho as tecnologias relacionadas ao data warehouse, a infra-estrutura necessária e administração do data warehouse.

Numa definição singular, para este trabalho, o data warehouse é considerado como: o repositório de dados para tomada de decisão. 

2. Tecnologias

Em parte o data warehouse é a evolução de algumas tecnologias. Outras que surgiram em paralelo ao conceito de DW também evoluíram e possuem grandes benefícios se estiverem integradas. Também existe um grupo de tecnologias mais recente que foram influenciadas pela deficiência ou amadurecimento do conceito. A seguir são definidas algumas das técnicas e ferramentas relacionadas com o data warehouse.

Os Sistemas de Informações Gerenciais (SIGs) foram uma das primeiras tentativas de criação de um ambiente único de informações para tomada de decisão. Eles foram desenvolvidos para disponibilizar relatórios que atendessem ao corpo gerencial das organizações. Porém, estes sistemas ainda não utilizavam técnicas de organização de dados específicas que suportassem um ambiente com crescimento escalar.

Como evolução dos SIGs os Executive Information Systems (EIS) foram desenvolvidos para melhorar a interface com os executivos e solucionar alguns problemas de performance. Por meio dos EIS o analista executivo pode localizar problemas com precisão e detectar tendências que são de vital importância para a gerência. Estes sistemas também eram suportados pela tecnologia OLAP.

A tecnologia OLAP (On-Line Analytical Process) constitui um sistema de armazenamento de dados agregados. Determinadas informações são obtidas a partir de dados pré-calculados disponíveis para consulta direta, sem a necessidade da pesquisa dos dados elementares e consolidação em tempo de execução, otimizando assim o processo de consulta de dados. Estes sistemas também são conhecidos como multidimensionais ou cubos, por permitirem a consulta de informações por múltiplas visões.

O armazém de dados (DW), em si, é suportado por um Sistema Gerenciador de Banco de Dados (SGBD), onde os dados extraídos dos sistemas transacionais são armazenados. O DW também utiliza a tecnologia OLAP para permitir as consultas analíticas On-Line.

É importante contextualizar algumas tecnologias que são influenciadas ou dependentes do DW para preparação de um ambiente que suporte de forma eficaz tais tecnologias.

Atualmente os EISs, associados com o data warehouse, podem ser considerados como sistemas de BI (Business Intelligence). Outras tecnologias como Data Mining também influenciam o BI, na descoberta de conhecimento.

Obter informação de uma grande base de informações (DW) pode se tornar uma tarefa difícil, mesmo que organizada por assuntos. Explorar as informações, por meio de ferramentas analíticas, pode não ser eficaz quando não se tem a certeza do que se está procurando. A tecnologia de Data Mining, com seus algoritmos e técnicas pode ser facilitada se existir uma fonte de dados organizada. Em uma empresa que deseja analisar o conteúdo da massa de dados criada por suas atividades, um processo de unificação precisa ser efetuado de forma a possibilitar o acesso de um indivíduo (analista) às múltiplas faces desta informação. Para que o data mining seja realizado, é necessário o acesso a uma massa de dados limpa, consistente e unificada em sua linguagem e lógica. Certamente que analistas vêm realizando data mining há muitos anos, utilizando ferramentas simples e bancos de dados separados, porém a construção de um data warehouse em muito facilita o processo de mineração de dados e de decisão.

CRM é totalmente dependente de um local centralizado de dados detalhados sobre clientes, seus comportamentos e suas preferências, incluindo detalhes específicos sobre privacidade de dados: o data warehouse.

Analisar as informações contidas no data warehouse, com crescente volume de dados, pode não ser eficiente com relatórios, books, gráficos etc. São muitas informações a serem analisadas. Algumas corporações estão adotando o Balanced Scorecard (BSC) como uma metodologia de gestão, onde são definidos indicadores de performance. Para estes indicadores são definidas metas e ações dentro da organização. Sistemas de BSC disponíveis no mercado têm maior eficiência se integrados ao data warehouse, caso contrário terão que buscar os dados para os indicadores diretamente nos sistemas transacionais.

Outro sistema relacionado ao BSC é o de Performance Management (PM), também conhecido como Business (BPM), Corporate (CPM) ou Enterprise Performance Management (EPM), que definem as metas dos indicadores. Estes sistemas, muitas vezes, utilizam o histórico dos indicadores como fonte para cálculo das metas.

Fica evidente assim que a construção do data warehouse deve levar em consideração como as informações serão utilizadas e integradas a outros sistemas e processos das instituições.

A metodologia de implementação de data warehouse, por assuntos, é descrita neste trabalho pelas fases de:

     - Definição da infra-estrutura;

     - Levantamento de dados;

     - Modelagem de dados;

     - Extração de dados;

     - Modelagem multidimensional;

     - Análise de resultados;

     - Visões pré-definidas;

     - Segurança da informação;

     - Administração.

3. Infra-estrutura

A infra-estrutura deverá suportar o ambiente projetado, com alto crescimento de dados, consultas complexas e não previstas (ad-hoc), diversidade de integração, diferentes tipos de tecnologias etc. O produto final do DW serão os dados, organizados e de fácil entendimento.

As ferramentas a serem utilizadas para a construção do data warehouse sejam, talvez, uma das menores preocupações que o arquiteto tenha. Integrar os sistemas, organizar os dados e disponibilizar as informações serão preocupações constantes. Desta forma, não importa muito qual o fornecedor ou marca devemos escolher, porém algumas características devem ser levadas em consideração.

Como dito anteriormente, a principal ferramenta de um data warehouse é o Banco de dados (SGBD), onde os dados extraídos dos sistemas transacionais ficarão armazenados. Ele deverá suportar: grandes volumes de dados, alta performance para carga de dados e consulta de informações, flexibilidade para alteração de estruturas, fácil administração e operação, baixo custo por usuário, integração com diferentes plataformas e sistemas, etc. Devem-se evitar utilizar características que dificultem a migração para outra plataforma. Em longo prazo, por questões de custo, pode ser necessária uma mudança de plataforma. Com tanta integração e a utilização do DW por toda organização o custo de licença de uso, por usuário, deve ser considerado desde o início como um fator crítico. Sendo os dados o mais importante, a estrutura de organização dos dados deve ser muito bem conhecida, documentada e de fácil acesso.

Para suportar consultas complexas e não previstas (ad-hoc) é necessário que tanto dados detalhados quanto totalizadores, fórmulas e conjuntos de dados possam ser consultados com o menor tempo de resposta possível. A infra-estrutura do data warehouse deve possuir uma ferramenta que suporte este tipo de consulta. As ferramentas OLAP possuem tais características, simplificando assim o trabalho de agregação e visualização das informações.

Os conceitos de OLAP incluem a noção ou idéia de múltiplas dimensões hierárquicas e podem ser usados por qualquer um para que se pense mais claramente a respeito do mundo, seja o mundo material da escala atômica à escala galáctica, o mundo econômico dos micros agentes à macro economias, ou o mundo social dos relacionamentos interpessoais aos internacionais. Em outras palavras, mesmo sem qualquer tipo de linguagem formal, é útil apenas sermos capazes de pensar em termos de um mundo multidimensional e com múltiplos níveis, independentes da sua posição na vida.

Outras linguagens formais, incluindo Data Definition Language (DDL), Data Manipulation Language (DML), Data Representation Language (DRL) e seus analisadores associados (e compiladores opcionais), poderia ser usada para qualquer modelagem descritiva, seja ela transacional ou de suporte à tomada de decisão. Em outras palavras, a associação de OLAP com suporte à tomada de decisão é mais uma função das características físicas de otimização dos produtos OLAP do que quaisquer características inerentes das construções de linguagem do OLAP.

As camadas de produto do OLAP normalmente residem em cima dos bancos de dados relacionais e geram SQL como saída da combinação. O armazenamento e o acesso aos dados são tratados pelo banco de dados.

Produtos OLAP completos, que precisam incluir um compilador e métodos de armazenamento e acesso, são otimizados para acesso a dados e cálculos rápidos, sendo usados para a modelagem descritiva de dados, derivada de sistemas de suporte à tomada de decisão (DSS – Decision Support Systems). A fronteira entre linguagens e produtos OLAP não é demarcada com clareza.

Resumidamente, as ferramentas OLAP fazem parte da infra-estrutura do Data Warehouse para consolidação de dados (agregação), aplicação de regras de negócio, cálculos (fórmulas) e disponibilizar a visão multidimensional.

Para obter os dados do ambiente operacional para o data warehouse, podem ser utilizadas várias linguagens, formas de acesso, conectores de dados e meios físicos diferentes (discos, fitas, rede etc). À primeira vista, quando os dados são movidos do ambiente herdado para o ambiente do data warehouse, parece que nada além de simples extrações de dados de um local para o próximo está ocorrendo. Em virtude dessa enganosa simplicidade, muitas empresas começaram a construir seus data warehouses manualmente. O programador olha para a movimentação de dados do antigo ambiente operacional para o novo data warehouse e declara: "Eu posso fazer isso!" Munido de lápis e formulário de codificação, nos três primeiros minutos do projeto e desenvolvimento do data warehouse, o programador ansiosamente mergulha na criação do código.

Contudo, primeiras impressões podem ser muito enganadoras. O que em um primeiro momento parece ser nada mais do que a movimentação de dados de um local para outro transforma-se, rapidamente, em uma grande e complexa tarefa – muito maior e mais complexa do que o programador negociou.

Como veremos adiante, em detalhes, no tópico de extração de dados, são necessárias algumas técnicas para esta tarefa. É verdade que, por meio de programação, a extração de dados possa ser feita. Sendo assim a extração de dados é uma das camadas da arquitetura do data warehouse. O fato da extração de dados poder ser executada por programação não significa que seja a mais eficiente. O alto volume de dados, a diversidade de tecnologias envolvidas e a complexidade de transformações podem dificultar a manutenção dos extratores e o tempo de desenvolvimento comprometido.

Para atender a esta camada algumas empresas fornecedoras de software desenvolveram ferramentas de ETL (Extract Transform and Load), facilitando em muito a integração e operacionalização. Considerando que a fase de extração pode consumir cerca de 70% do tempo de desenvolvimento do projeto. Abrir mão de uma ferramenta de ETL pode ser um grande risco para o projeto e comprometê-lo. Investir numa ferramenta, que garanta a integração e atenda aos requisitos da extração de dados, é no mínimo aconselhável. Além disso, usualmente os fornecedores não cobram por conectores ou pontos de integração e sim como um pacote, portanto investir mais nestas ferramentas não irá aumentar os custos à medida que o data warehouse se expandir.

Para que a arquitetura do data warehouse esteja completa é necessário uma última camada. A consulta, análise e visualização das informações compõem esta camada. Apesar dos bancos de dados possuírem formas de acesso e as ferramentas OLAP visões multidimensionais, é necessário que os usuários possam acessar as informações de forma integrada ao seu ambiente de trabalho. Como requisito mínimo para a arquitetura do data warehouse deve-se considerar uma ferramenta que acesse os dados armazenados e de forma exploratória possam analisar os dados. Outra forma de acesso, de forma orientada, são os portais de informação, que são constituídos por visões pré-definidas, consultas e relatórios pré-formatados.

Nas quatro camadas descritas acima (armazenamento, extração, consolidação e análise) devemos considerar o alto volume de dados, múltiplos acessos simultâneos e alta disponibilidade. Esta preocupação garantirá a escalabilidade do ambiente do data warehouse.

Outro fator muito importante está na flexibilidade que o ambiente deve possuir para atender as constantes mudanças de visão do negócio. Uma empresa que opera com apenas um produto pode passar a comercializar outros, assim como uma empresa pode se tornar uma grande organização composta por diferentes unidades de negócio. Não é necessário que estas mudanças estejam previstas no data warehouse, porém a implementação delas não pode ser inviabilizada pela arquitetura utilizada.

Outra importante diferença entre os ambientes operacionais e de data warehouse são os padrões de utilização de hardware que ocorrem em cada ambiente. No processamento operacional há picos e platôs no processamento, mas há uma constante de utilização elevada e estável. No DW há uma utilização binária, ou seja, totalmente utilizado ou simplesmente não está. Esta diferença fundamental consiste em mais uma razão para o fato de que tentar combinar os dois ambientes na mesma máquina e ao mesmo tempo não funciona. Você pode otimizar sua máquina para o processamento operacional ou pode otimizar sua máquina para o processamento do data warehouse, mas não é possível ter ambas as situações ao mesmo tempo e no mesmo equipamento.

Esta característica de utilização determina que o ambiente deve ser completamente separado do operacional, sendo assim, todos os equipamentos devem ser separados, sem nenhum tipo de compartilhamento. Isto nos leva a crer que a utilização de rede também terá algum impacto e deve ser levada em consideração na arquitetura. O armazenamento de dados em discos externos também não deve ser compartilhado.

Considerando que os dados são históricos e não voláteis no data warehouse, podemos chegar à conclusão que as contingências podem ser reduzidas, ou seja, sem redundância de disco por exemplo. Porém, a disponibilidade do DW para tomada de decisão tende a aumentar e correr o risco de não ter a informação em tempo hábil não é compatível com este ambiente.

4. Metodologia
 

4.1. Levantamento

Sendo o data warehouse um grande repositório de dados e possuindo como origem os dados dos sistemas transacionais, podemos concluir que a principal análise deve ser feita com base no dados e não nas funções e requisitos. O sistema clássico é baseado em requisitos. Para desenvolver sistemas, primeiro é necessário entender as necessidades. Depois disso, vêm às fases de projeto e desenvolvimento. O ciclo do DW é o inverso. No DW começa pelos dados. Uma vez que os dados estejam sob controle, eles são integrados e, em seguida, testados para que se verifiquem quais distorções há neles, se houver alguma. Então, é feita a codificação de programas para os dados. Os resultados dos programas são analisados e, finalmente, os requisitos do sistema são compreendidos.

Analisar as bases de dados de grandes corporações pode não ser uma tarefa eficiente, pois nem todas possuem documentação e nem mesmo seguem os padrões de normalização de dados. Sendo assim, vasculhar as bases de dados dos sistemas transacionais sem um direcionamento prévio exigirá um esforço grande dos arquitetos do data warehouse.

A principal abordagem para construção do DW é pela implementação de Data Marts, que são assuntos específicos das áreas das empresas. Os Data Marts têm sua origem na construção de cubos, pela utilização da tecnologia OLAP. Esta abordagem é considerada por alguns autores como ineficiente por não considerar a integração com outras bases de dados dentro do data warehouse. Outra característica dos Data Marts, a ser considerada, é a implementação em partes para se chegar ao todo (Bottom-Up).

Mesmo considerando a construção do DW por partes, alguns Data Marts podem ser muito complexos. Os Data Marts podem ter como origem mais de uma base de dados e cada uma com dezenas ou centenas de tabelas. Como orientação para o trabalho de levantamento de dados outras fontes devem ser analisadas.

Analisando as principais questões, referentes ao assunto, pode-se observar que existirá a carência por algum tipo de informação específica ou que a informação atual não é confiável, conflitante com dados de outra área da empresa ou fora do tempo para tomada de decisão. Desta forma são identificados problemas analíticos que não são solucionados pelos sistemas transacionais, como exemplo a análise de comportamento dos clientes ao longo do tempo. Caso o sistema transacional tente solucionar este tipo de questão ele pode se tornar ineficaz para as transações ou gerar a informação fora do tempo.

O direcionamento para as principais questões pode ser dado pelos gestores e executivos da organização, desta forma é possível traçar um alinhamento com a visão estratégica da empresa. A equipe coordenadora do Data Warehouse deve ter acesso ao plano estratégico da empresa, bem como ter o pleno entendimento da visão da empresa.

Numa análise mais ampla devem-se revisar os processos das áreas relacionadas com o assunto, onde são observadas as regras de negócio. Estas regras podem dar origem às transformações na fase de extração de dados. Em geral as transformações podem ocorrer por questões técnicas, mudanças de formatos ou uma visão de negócio. As transformações por visão de negócio acontecem em geral por adaptação dos processos das empresas aos sistemas, normalmente em casos de implantação de ERPs.

Outra fonte que pode auxiliar nesta fase de levantamento de dados são relatórios gerenciais, que muitas vezes são improvisados em planilhas eletrônicas a partir da coleta de dados de várias fontes. É comum encontrar nestes relatórios os principais indicadores monetários e físicos (quantitativos).

A análise das bases de dados dos sistemas transacionais pode ser iniciada pela pesquisa das tabelas com maior volume de dados. Estas tabelas normalmente são referentes a eventos ou fatos que ocorrem com freqüência, indicados por campos de data ou período. Comumente estas tabelas são definidas como ordens, itens, detalhamento etc. Os atributos destas tabelas são compostos, em grande parte, por chaves estrangeiras (foreign key) e indicadores. Os indicadores são dados quantitativos, monetários, taxas e medidas. As tabelas relacionadas com a tabela de eventos (ou fatos) podem dar origem às dimensões, que são as diferentes visões que se poderá ter do assunto.

Após a análise das bases de dados, dos relatórios e reuniões de levantamento deve ser produzida uma especificação com a definição do assunto, os objetivos da análise do assunto, as principais questões, a definição das regras de negócio, os indicadores, as múltiplas visões do assunto, o mapeamento dos dados das bases de origem e a periodicidade para extração dos dados.

O mapeamento dos dados deve ser bastante detalhado para facilitar o trabalho na fase de extração de dados. Neste mapeamento de dados devem ser indicados as bases de dados, arquivos, tabelas, campos, atributos, formatos etc.

Esta especificação será utilizada durante todo o projeto do Data Mart como orientação para que os objetivos sejam atingidos. 

4.2. Modelagem

Identificados os dados que deverão ser extraídos dos sistemas transacionais pode-se iniciar a modelagem para armazenamento no data warehouse.

A modelagem para o DW tem grande influência das ferramentas OLAP que, por questões de performance e visualização das informações, dependem de um modelo estrela. Este modelo, de forma resumida apresenta os fatos ao centro e todas as dimensões relacionadas aos fatos. Existem algumas variações desse modelo como o modelo em cascata (snowflake), que para algumas tabelas de dimensões estarão relacionadas com outras tabelas. Estas tabelas relacionadas às dimensões darão origem, em grande parte, a níveis de consolidação da dimensão no modelo multidimensional, como será discutido mais adiante.

O modelo lógico para um Data Mart é bastante simples, com algumas restrições. O relacionamento dos fatos com as dimensões não poderão ter cardinalidade N para N, ou seja, um fato não pode estar relacionado com mais de um elemento de uma tabela de dimensão. Os elementos das tabelas de dimensão estarão relacionados com vários itens da tabela de fatos, caracterizando assim a necessidade de agregação.

A desnormalização de dados no data warehouse é aceita e em muitos casos indicada para solucionar problemas de performance e espaço em disco, combinando dados de várias tabelas do modelo de dados dos sistemas transacionais em uma tabela de fatos ou dimensão. É interessante observar que, no data warehouse, essas circunstâncias ocorrem regularmente em função de os dados serem baseados em parâmetros de tempo. Os dados do data warehouse sempre apresentam relevância em relação a um determinado momento, e unidades de tempo ocorrem com grande regularidade. Em um data warehouse, a criação de um array por mês, por exemplo, é algo muito natural. Outra importante técnica de projeto especialmente relevante para o ambiente de data warehouse consiste na introdução intencional de dados redundantes. Contudo, algumas ferramentas de mercado estão cada vez mais adaptadas aos conceitos de data warehouse. Tirando grande proveito do ambiente relacional, sem perder o conceito, para construir bases multidimensionais (OLAP) com maior eficiência. Sendo assim, não devemos abrir mão da desnormalização para tudo, mas sempre que necessário.

Um dos aspectos mais importante na modelagem é definir a granularidade dos dados. As bases de dados transacionais possuem muitos dados de controle das transações que talvez não sejam relevantes para tomada de decisão. A razão pela qual a granularidade é a principal questão de projeto consiste no fato de que ela afeta profundamente o volume de dados que residem no data warehouse e, ao mesmo tempo, afeta o tipo de consulta que pode ser atendida. O volume de dados contidos no data warehouse é balanceado de acordo com o nível de detalhe de uma consulta.

Outro paradigma a ser rompido em relação aos sistemas transacionais é referente à representação de acontecimentos passados. Os sistemas OLTP e data warehouse tratam o tempo de forma diferente. O melhor sistema OLTP é um status instantâneo dos negócios de uma organização, atualizado constantemente à medida que as transações são concretizadas. Os valores-chave do negócio devem mudar a cada minuto ou segundo. O status muda continuamente e os relacionamentos entre as entidades são alterados. No DW estes instantâneos serão armazenados e identificados com uma marca de tempo, onde poderemos observar as mudanças de comportamento, seja de clientes ou produtos.

Algumas dimensões no data warehouse devem ser observadas com mais atenção, pois possuem grande relevância para a integração dos dados. Quando importamos os fatos dos sistemas transacionais para o DW observamos sempre que possuem o atributo de tempo. Portanto, a dimensão de tempo terá grande importância para o modelo de dados do data warehouse. Outra característica importante é podermos definir atributos comuns para os fatos, através do tempo, como: feriados, acontecimento importante (externos ou internos da organização), dia da semana etc.

Fatos diferentes podem dar origem à outra dimensão que deve ser observada com atenção. A relação de fatos realizados com previstos ou calculados é o conceito de versão, que é representado usualmente nos data warehouses como uma dimensão de versão.

Mais recentemente, com a evolução dos conceitos de marketing, e mais especificamente do marketing de relacionamento, o cliente tem ganhado maior atenção dos analistas de data warehouse, com o intuito de atender as necessidades dos sistemas de CRM (Customer Relationship Management). Modelar os dados dos clientes de forma que seja possível observar as mudanças do mesmo, ao longo do tempo, é fundamental para atender a esta finalidade.

Diferentemente da modelagem de dados dos sistemas transacionais, com os modelos de entidade e relacionamento (MER), no data warehouse o modelo de dados físico se apresenta muito semelhante ao lógico, seguindo o conceito estrela e suas variações. Porém, a preocupação será no armazenamento, objetivando maior performance e menor custo de espaço para o armazenamento de dados.

Devemos ter maior atenção para as tabelas de fatos, pois noventa por cento dos dados de cada Data Mart serão armazenados nestas tabelas. As tabelas de fatos serão compostas por dois grupos de atributos chaves estrangeiras e indicadores. O dimensionamento correto dos tipos de dados das chaves das dimensões e dos indicadores determinará o espaço necessário para o armazenamento.

A granularidade das tabelas de fatos poderá ser reavaliada após alguns anos de dados armazenados. Na maior parte do tempo, há uma grande demanda por eficiência no armazenamento de dados e no acesso a eles bem como pela possibilidade de analisar dados em maior detalhe. (Em outras palavras, a organização quer fazer o gol e defender ao mesmo tempo!) Quando uma organização possui grandes quantidades de dados no data warehouse, faz sentido pensar em dois (ou mais) níveis de granularidade na parte detalhada do data warehouse. Deve ser observado que, efetuando este tipo de modelagem, alguma informação será perdida ao longo do tempo.

Outro aspecto a ser considerado no modelo físico é o particionamento dos dados. O particionamento permitirá o gerenciamento flexível dos dados e a distribuição de bases de dados por unidades de negócio de forma descentralizada.

Resumidamente o modelo de dados do data warehouse refletirá a organização dos fatos e dimensões na base de dados.

4.3. Extração de dados

O data warehouse é dependente dos sistemas transacionais internos ou externos das instituições. Os sistemas transacionais são a fonte de dados para o data warehouse, como a matéria-prima para a fabricação de um produto. Interligar estes ambientes tão heterogêneos, com: tecnologias diversificadas, diferentes bases de dados, formatos diferentes, conexões e distâncias; torna a fase de extração de dados a mais trabalhosa, consumindo cerca de 70% do tempo da equipe do data warehouse.

Quando a integração entre os sistemas transacionais e o DW não possui um suporte tecnológico ideal, é possível subdividir esta fase em: extração e importação dos dados. As transformações serão tratadas no momento da importação.

É possível extrair os dados dos sistemas transacionais no formato adequado para simples importação no data warehouse. Porém, esta pode não ser a estratégia mais adequada, pois as transformações possivelmente ficariam nos ambientes transacionais, tornando-os mais complexos. Outro fator é a manutenibilidade das regras de negócio que, desta forma, de nada agregará aos sistemas transacionais implementar as regras de transformação. Esta situação ainda poderá trazer problemas de performance para o ambiente transacional, com processos concorrentes entre extratores e transações ou processos operacionais.

Deve-se manter a integração entre estes ambientes a mais automática possível, evitando a manipulação de dados pelos usuários e reduzindo risco a falhas. As ferramentas de ETL (Extract Transform and Load) são de suma importância para a integração dos ambientes transacionais e o data warehouse.

Com base na especificação definida no levantamento de dados serão produzidas novas especificações de desenvolvimento: definição dos extratores e especificação das importações dos dados. Tendo estas especificações bem definidas é possível executá-las em paralelo.

As especificações dos extratores conterão a definição da seleção dos dados, critérios de seleção, formato de saída, objetos que devem ser criados, parâmetros da interface, script de teste e controles de erro.

A seleção dos dados e os critérios de seleção definirão quais os objetos, campos e tabelas, dos sistemas transacionais serão manipulados e qual a relação entre eles. Os critérios de seleção também poderão conter restrições fixas da seleção dos dados, que sejam exclusivamente referentes à complexidade de busca dos dados do sistema transacional específico, não sendo assim nenhuma transformação de dados.

O formato de saída basicamente define a ordem dos campos, largura de colunas e conversões elementares, tais como formato de data.

Os parâmetros da interface são os critérios de seleção enviados pelo processo principal de carga de dados que coordena as interfaces.

Os controles de erro são fundamentais para a integração com o ambiente do data warehouse, onde poderão ser monitoradas as falhas no processo para comunicação aos administradores dos sistemas.

O script de teste é a descrição de como a extração pode ser executada e qual o resultado esperado. Este teste permite a validação do processo independentemente da integração com o data warehouse.

Como produto das especificações de extração são produzidos alguns objetos, tais como: programas, arquivos, conectores etc. A especificação deverá conter também o local de armazenamento dos objetos.

Observa-se que as interfaces dos extratores devem ser flexíveis, permitindo assim a re-execução dos processos para correção de erros. Deve-se ter como objetivo primário na definição dos extratores que qualquer processo possa ser executado a qualquer tempo. Mesmo considerando que a definição da periodicidade de extração definida na especificação de levantamento de dados e alinhada com a necessidade da área de negócio, os extratores devem possuir a capacidade de serem executados a qualquer tempo para correção de problemas adversos.

Com a periodicidade definida, deve-se buscar o menor volume de dados possível dos sistemas transacionais. Outro importante problema diz respeito ao acesso eficiente aos dados dos sistemas existentes. Como pode o programa que varre os sistemas existentes saber se um arquivo já foi varrido anteriormente? Há uma enorme quantidade de dados no ambiente de sistemas existentes e a tentativa de efetuar varreduras completas toda vez que é feita uma varredura para o data warehouse é antieconômica e pouco realista. Há três tipos de carga que podem ser feitos do ambiente operacional para o data warehouse: o carregamento de dados históricos, o carregamento de dados de valor corrente no ambiente operacional e o carregamento de alterações do data warehouse a partir de alterações (atualizações) que tenham ocorrido no ambiente operacional desde a última atualização do data warehouse.

Para solucionar o problema do corte dos dados podem ser empregadas algumas técnicas: marcar de tempo, arquivo de log ou auditoria, arquivo delta, imagem anterior / posterior e alteração da aplicação do sistema transacional.

A performance de carga de dados estará relacionada diretamente com o volume de dados extraído do sistema transacional. Podem-se empregar técnicas de segmentação, principalmente dos fatos, para carregá-los em paralelo.

As especificações de importação de dados devem tratar de como os dados devem ser carregados no data warehouse. Este processo também contempla a coordenação dos sub-processos para carga de cada uma das interfaces das tabelas de dimensões e fatos. Esta especificação deve conter as definições do: mapeamento técnico dos dados da origem para as tabelas do data warehouse, as transformações de tipos de dados, as transformações de substituição de chaves, transformações das regras de negócio e verificação dos possíveis erros no processo de extração.

As interfaces com alto grau de acoplamento, ou seja, com tecnologias similares ao data warehouse, podem ser tratadas em apenas uma especificação.

Uma particularidade da extração dos dados é a conversão inicial dos dados dos sistemas transacionais para o data warehouse. Após o desenvolvimento dos extratores é possível iniciar a carga de dados para o data warehouse. Porém, vale avançar para as próximas fases do projeto até a análise de resultados, onde algumas validações podem ser executadas e possivelmente trará modificações para os extratores de dados. Por fim, após as modificações, os dados devem ser convertidos por períodos. Tentar trazer todos os dados de uma só vez não é recomendado, podendo causar grande impacto nos sistemas transacionais, que já estão em ambiente produtivo.

É comum verificarmos que, após a carga dos dados dos sistemas transacionais para o data warehouse, muitas informações não possuem o valor esperado. Após as primeiras cargas de dados, é necessário fazer uma análise criteriosa das informações. Muitos dados podem não estar qualificados, ou seja, os dados contidos nos sistemas transacionais não estão consistentes. Este problema de qualificação e análise dos dados é abordado com mais detalhes na fase de análise de resultados, onde o analista de suporte a decisão tem grande participação no processo.

4.4. Modelagem multidimensional

Após a carga de dados poderíamos considerar que o data warehouse está concluído. Porém, como todo sistema pressupõe a entrada, processamento e saída, devemos considerar a análise dos dados como saída primária do data warehouse.

O modelo de dados lógico e físico, descrito anteriormente, do data warehouse é constituído por uma visão multidimensional, em estrela. Porém, eles representam, respectivamente, uma visão de entendimento do negócio e como os dados estarão armazenados no DW. A modelagem multidimensional formará uma camada intermediária entre a base de dados e as ferramentas de consulta de dados, que serão definidas mais à frente.

Especificamente nesta fase será tratada a questão da utilização das ferramentas OLAP. Os principais conceitos da tecnologia OLAP são: visão multidimensional, agregação de dados, análise exploratória e cálculos. Os requisitos funcionais para OLAP possuem um formato central e periférico. Os requisitos centrais, raiz, necessários ou mínimos no lado lógico incluem suporte para múltiplas dimensões, hierarquias, fórmulas dimensionais e separação de estrutura de dados e representação. Fisicamente, o principal requisito é velocidade suficiente para oferecer suporte à análise ocasional. Qualquer linguagem ou produto que não aceite pelo menos esses requisitos não pode, com seriedade, ser classificado como oferecendo suporte a OLAP.

A característica de ser multidimensional, das ferramentas OLAP, permite que os assuntos (Data Marts) sejam analisados por diferentes visões (prismas, ângulos etc). Esta característica está intimamente ligada a análise exploratória que permite ao analista de suporte a decisão investigar os dados, adquirindo conhecimento, validando suposições, análise de tendências e confrontando diferentes aspectos do assunto, entre outras análises possíveis.

Se considerássemos uma base de dados ideal que, para qualquer consulta executada, o tempo de resposta fosse sempre imediato, uma das questões mais importantes tratadas pelas ferramentas OLAP não seria necessária. A agregação das informações, executada pelo processamento das ferramentas OLAP, disponibilizará imediatamente as informações, independente da complexidade da consulta. Se as agregações foram feitas por demanda deve ser de forma imperceptível para os analistas de suporte à decisão. De forma simplista as ferramentas OLAP devem calcular (agregar) todas as combinações e totais possíveis para que as informações sejam consultadas em tempo hábil para tomada de decisão, independente da quantidade de dados armazenada na base de dados do data warehouse.

Tecnicamente a fase de modelagem multidimensional é onde são desenvolvidos os cubos, definindo as visões multidimensionais nas ferramentas OLAP. Grande parte do trabalho, para esta fase, já foi executado na fase de modelagem, com a definição das tabelas de fatos e dimensões. Contudo, é necessário configurar a ferramenta OLAP para definir a origem dos dados para consolidação das informações. Algumas das regras de negócio, identificadas no levantamento de dados, estarão explicitadas por meio de fórmulas na estrutura dos cubos, como membros calculados.

Nesta interface entre a base de dados do data warehouse e a ferramenta OLAP é importante que ela seja flexível, permitindo a adaptação de novas regras de negócio do constante amadurecimento das organizações. Como importante recurso para comportar estas adequações os SGBDs visões (view), ou seja, consultas predefinidas que são armazenadas na estrutura do banco de dados, reduzindo assim o esforço para manutenção dos cubos.

Portanto, o modelo multidimensional deverá refletir as possíveis visões e responder a maioria das questões identificadas na fase de levantamento de dados. Permitindo assim que os analistas de suporte a decisão executem consultas analistas On-Line.

4.5. Análise de resultados

Esta fase pressupõe que as informações já estão disponíveis para análise. Não é necessário que todos os dados já tenham sido carregados para o data warehouse, mas uma parte significativa que permita a avaliação dos resultados. Neste ponto do projeto o analista de suporte a decisão tem a responsabilidade de validar as informações contidas no data warehouse. O analista deverá observar a conformidade das informações disponibilizadas com a especificação produzida na fase de levantamento de dados.

Este trabalho deverá ser o mais rigoroso possível, pois a partir das informações contidas no data warehouse e disponibilizadas elas serão usadas para a tomada de decisão. Uma informação errada pode causar mais prejuízos que a falta delas.

Neste ponto o analista de suporte a decisão, com o apoio do arquiteto do data warehouse, poderão identificar falhas no processo de extração. Também será possível qualificar as informações obtidas a partir das bases de dados dos sistemas transacionais, identificando campos que não foram preenchidos corretamente ao longo dos anos de produtividade desses sistemas. A visão macro das informações, disponibilizada pelas ferramentas OLAP, permitirá aos analistas descobrir fatos não identificáveis no ambiente transacional. Eventualmente estas análises servirão para definição de novas regras de negócios e requisitos para os sistemas transacionais, tais como a obrigatoriedade do preenchimento de determinados dados ou novas regras de integridade.

O trabalho da análise de resultados inicia um novo ciclo no desenvolvimento do Data Mart, obrigando ao arquiteto do data warehouse reavaliar os dados dos sistemas de origem, ajustar a especificação e passar pelas fases de modelagem, extração e modelagem multidimensional para que as informações sejam novamente analisados.

Garantir a confiabilidade das informações do data warehouse é uma tarefa constante, mesmo após a implementação do Data Mart. Fatos externos, adequações a legislação e mudanças organizacionais podem afetar de forma direta ou indiretamente o data warehouse. A confiabilidade das informações do data warehouse deve ser mantida realizado validações periódicas e ajustando os dados da base de dados constantemente. Caso as validações não ocorram com freqüência é comum acontecer dos usuários deixarem de consultar as informações, tomarem decisões baseadas em dados errados ou fazer com que os executivos percam a confiança nas informações de tal modo que se determine a descontinuidade do projeto todo.

O comprometimento dos executivos e analistas de suporte a decisão é fundamental para o sucesso do projeto, garantindo confiança nas informações e continuidade. 

4.6. Visões pré-definidas

Grande parte das informações já foi disponibilizada para os usuários de suporte a decisão, através da utilização das ferramentas OLAP. Porém nem todas as consultas devem ser feitas de forma exploratória, obrigando aos usuários a pesquisa desde o início.

Esta fase do projeto tratará da disponibilização de visões direcionadas e freqüentemente extraídas do DW, através de relatórios. Existem alguns grupos de relatórios que serão disponibilizados: relatórios gerenciais, consultas complexas, indicadores, consultas direcionadas etc.

Em muitos casos estes relatórios são disponibilizados por meio de portais de informação. Onde os gestores, que não dispõe de muito tempo para explorar as informações e em grande parte dependentes do trabalho dos analistas de suporte a decisão, poderão consultar as informações periodicamente e norteando sua equipe, de acordo com o alinhamento estratégico da organização.

Os relatórios gerenciais, agora obtendo os dados pelo data warehouse, com a garantia de que a informação estará disponível para tomada de decisão em tempo hábil, integrada a outras visões da empresa e a versão única da verdade. A unicidade da informação garantirá que nenhum relatório conflitante seja apresentado aos gestores.

Num ambiente integrado algumas análises podem ser feitas de forma orientada, onde os analistas de suporte a decisão e os gestores podem “navegar” entre relatórios obtendo o detalhe necessário para suas conclusões e observação de comportamento de vendas, clientes, produtos etc.

Mesmo num ambiente proporcionado pelas ferramentas OLAP algumas consultas serão muito complexas para que os analistas de suporte a decisão possam desenvolver seus relatórios sem o auxílio do arquiteto do data warehouse. Estes relatórios necessitam de profissionais tecnicamente preparados para utilização de funções específicas das linguagens de consulta de dados das ferramentas OLAP ou da utilização de ferramentas de Data Mining.

Algumas das principais questões, documentadas na especificação do levantamento de dados, poderão ser respondidas com a criação de visões pré-definidas, já que as informações estão disponíveis.

Os indicadores da empresa poderão estar disponibilizados como visões predefinidas e possivelmente alinhados com conceitos de gestão organizacionais, como Balanced Scorecard (BSC).

A camada de visões pré-definidas poderá obter as informações diretamente da base de dados do data warehouse ou pela configuração de consultas aos cubos.

4.7. Segurança da informação

Grande parte das informações disponibilizadas no data warehouse refletem as visões táticas e estratégicas das organizações, portanto nem todos poderão ter acesso a estas informações. Esta fase deve tratar de quem pode, quem deve, como pode e por onde as informações devem ser consultadas.

A política de segurança para o ambiente do data warehouse deve ser muito flexível, permitindo que pessoas com perfis macro ou mais específicos possam acessar as informações de sua responsabilidade ou interesse empresarial.

Cada um ao seu nível de decisão ou de análise deve acessar a informação, porém existirão alguns grupos específicos da organização que deverão ter acesso quase irrestrito ao data warehouse, são as áreas de: planejamento estratégico, controladoria e inteligência de marketing.

Deve-se ter muito cuidado ao disponibilizar canais externos, tais como Extranets, para consultas ao data warehouse. Estes canais, se existirem, devem ser monitorados constantemente e com altos requisitos de segurança.

Outra questão crucial para este ambiente, em relação à segurança, é garantir que as informações contidas no data warehouse caiam em mãos erradas, os concorrentes. É necessário uma política de segurança rígida para a equipe de administração e operação do data warehouse.

Por outro lado, de que adiantaria todo o esforço para construir o data warehouse se as informações ficarem confinadas no repositório de dados. Alguns analistas podem desenvolver uma visão analítica, crítica e consciente, com o acesso as informações do data warehouse. 

5. Administração

Na maior parte do tempo a administração do data warehouse estará voltada para o banco de dados, verificando a integridade, a performance e o volume de dados. Também se deve ter atenção especial para os cubos, das ferramentas OLAP. Os critérios de agregação dos dados devem ser re-analisadas de acordo com a utilização das informações pelos usuários, assim como os índices do banco de dados.

É possível utilizar a infra-estrutura do próprio data warehouse para criação de Data Marts para monitoramento do ambiente, tais como: análise de espaço em disco, tempo de carga de dados, análise de acessos dos usuários.

Nas organizações em que a informação para tomada de decisão for muito crítica para o negócio, deve-se ter grande atenção aos extratores de dados. Os processos de extração de dados devem ser monitorados continuamente, com implementação de controles de falhas. Caso ocorra algum erro nesses processos o administrador do data warehouse deve ser comunicado imediatamente para analisar o problema.

Em alguns casos, novas regras negócio podem ter sido implementadas nos sistemas transacionais, sem a comunicação para aos administradores do data warehouse. Nestes casos o administrador deverá recorrer aos analistas de suporte à decisão para reavaliação das transformações dos extratores de dados.

Todas as falhas ocorridas no ambiente do data warehouse devem ser comunicadas aos responsáveis para que nenhum informação errada seja utilizada para tomada de decisão. É válido manter uma política de comunicação para avaliação constante da equipe de administração do data warehouse.

É fundamental que o ambiente do data warehouse seja altamente padronizado, com políticas rígidas de verificação. Como o ambiente do DW tende a ser complexo, com muitas regras de negócio, objetos, ferramentas e conectores com sistemas heterogêneos, a padronização do ambiente permitirá que a manutenção seja mais eficiente.

Em alguns casos manter os padrões de desenvolvimento podem ser mais interessante que obter a melhor performance possível. Utilizar linguagens de pouco conhecimento da equipe, ou de profissionais do mercado, pode não ser uma estratégia segura para a administração do data warehouse.

O data warehouse deve possuir ao menos dois ambientes similares, um de produção e outro de desenvolvimento. Para implementações críticas é aconselhável um ambiente de validação dos desenvolvimentos e de performance. Os ambientes de validação e desenvolvimento devem ter características próximas ao de produção pois tratarão do mesmo volume de dados. Outra vantagem de possuir os ambientes similares é criar uma contingência para o ambiente de produção.

A “janela” de extração de dados dos sistemas transacionais deve ter atenção especial dos administradores. Eles devem observar a concorrência com os ambientes transacionais e garantindo que as informações sejam disponibilizadas no prazo previsto e com a periodicidade correta.

Outro aspecto importante da administração do data warehouse é a continuidade do projeto, verificando se as regras de negócio estão em constante validação pelos usuários e a documentação do projeto atualizada. A questão da revisão das regras de negócio é tão importante que outra característica dos data warehouses é possuir uma base de metadados.

Alguns papéis devem estar bem definidos para a equipe de manutenção do data warehouse. Alguns deles são: arquiteto de soluções, administrador de dados, analista de suporte a decisão, analista de negócio, administrador de banco de dados, desenvolvedores, patrocinadores do projeto. Talvez o arquiteto de soluções seja a peça fundamental para a construção e manutenção do data warehouse. Ele deverá ter a visão do todo, desde integrar os diferentes sistemas transacionais ao data warehouse a disponibilização dos dados para os analistas. O administrador de dados (AD) deve ser responsável pelos metadados, pela integração das bases de dados e organização dos dados. O AD deverá ter profundo conhecimento da modelagem, tanto lógica, física e multidimensional. O analista de suporte a decisão deverá garantir continuamente que as informações estão corretas, comunicando as mudanças das regras de negócio e a visão do negócio. Seu alinhamento com a equipe de administração do data warehouse deve ser o mais fiel possível. O administrador de banco de dados (DBA) poderá ser o mesmo do ambiente transacional, contanto que tenha disponibilidade para solucionar os problemas emergenciais e entenda perfeitamente as características dos dois ambientes. Os desenvolvedores serão responsáveis pela codificação dos extratores de dados, exigindo deles conhecimento de diferentes tecnologias para integração com sistemas transacionais, e pela programação dos relatórios e visões pré-definidas. Os patrocinadores do projeto deverão definir as prioridades, acompanhar o projeto e garantir a continuidade.

6. Conclusão

Fundamentalmente as técnicas foram essenciais para a definição da metodologia. A experiência da aplicação da metodologia também foi essencial para que ela realmente se mostrasse eficiente na implementação e na expansão de projetos de data warehouse.

Fica evidente também que os dados e, conseqüentemente, as informações devem ser armazenados e organizados de forma independente das ferramentas utilizadas. Sendo assim a metodologia se enquadra a este requisito básico do conceito de data warehouse.

Uma das questões polêmicas do conceito de data warehouse é por se tratar de um projeto utópico, pois criar uma fonte de dados única para tomada de decisão pode não se aplicar às condições da realidade. As instituições estão em constante mudança, com novas implementações de sistemas transacionais, mudanças de plataforma, métodos de trabalho diferentes e mudanças de estrutura organizacional. Porém os benefícios da implementação do data warehouse são, comprovadamente pelo mercado, inegáveis. Diz-se que um projeto de data warehouse não tem fim, pois ele está em constante evolução para acompanhar as mudanças.

Contudo a metodologia ainda requer um aperfeiçoamento, com definições mais rígidas das documentações e especificações. 

7. Lista de abreviações e siglas

BI – Business Intelligence

BSC – Balanced Scorecard

BMP – Business Performance Management

CASE – Computer Aided Sotware Engineering

CLDS – Ciclo de vida baseado em dados

CPM – Corporate Performance Management

CRM – Customer Relationshio Management

DBA – Data Base Administrator

DDL – Data Definition Language

DML – Data Manipulation Language

DRL – Data Representation Language

DSS – Decision Support Systems

EIS – Executive Information System

EPM – Enterprise Performance Management

ERP – Enterprise Resource Planning

ETL – Extract Transform and Load

MER – Modelo Entidade-Relacionamento

OLAP – On-Line Analytical Processing

OLTP – On-Line Transaction Processing

SDLC – Ciclo de vida do desenvolvimento de sistemas clássicos

SGBD – Sistema Gerenciador de Bando de Dados

SQL – Structured Query Language