Programação Em JAVA

Sumário

Introdução a Programação em Banco de Dados 3

ETAPA 1 - Atividade 1: Consultas SQL e DML 5

Passo 1.1: Consultas SQL e comandos DML 5

Passo 1.2: Construção do Banco de Dados SIG_DB 6

Passo 1.3: Consultas e DML 10

ETAPA 2 – Procedures e Triggers. 11

Passo 2.1 Criação Procedures e Triggers: 11

Passo 2.2 Procedures: 11

Passo 2.3 Triggers: 12

ETAPA 3 – Otimização de Consultas em SQL 12

Passo 3.1 - Gerenciamento e escolha dos índices 12

Passo 3.2 – Otimização das Consultas em Banco de Dados 14

Passo 3.3 – Gerenciamento de Transação 15

EATAPA 04: Banco de Dados Distribuídos e Data Warehouse 17

Passo 4.1 Bancos de Dados Distribuídos 17

Passo 4.2 Data Warehouse 18

Introdução a Programação em Banco de Dados

A linguagem SQL (Structured Query Language) é a base para utilização de bancos de dados relacionais. Com a utilização dos comandos básicos (INSERT, DELETE, UPDATE e SELECT) pode-se resolver a maior parte dos problemas relacionados a manutenção e extração de dados no banco de dados. Com o SQL é possível criar as estruturas básicas de armazenamento, como tabelas e índices. Também há comandos específicos da linguagem para o controle e segurança relacionado a um banco de dados. Em princípio, os comandos SQL são divididos em:

• DDL (Data Definition Language) ou Linguagem de definição de dados

• DML (Data Manipulation Language) ou Linguagem de manipulação de dados

• DQL (Data Query Language) ou Linguagem de recuperação de dados

• DCL (Data Control Language) ou Linguagem de controle de dados

O SQL tem sido aprimorado ao longo do tempo. Duas entidades (ANSI – American National Standards Institute e ISO – International Standards Organization) vêm, desde 1986, publicando padrões de especificação da linguagem SQL.

Vamos discutir como abordar e tirar o máximo de proveito desta linguagem que é extremamente importante para todos os profissionais de banco de dados. Os principais tópicos que serão de interesse envolvem:

• Fundamentos da linguagem SQL

• Extensões e particularidades de cada banco de dados

• Melhoria no desempenho de consultas

• Utilização de funções analíticas em banco de dados

• Tendências do uso da linguagem

Naturalmente a ideia é ter uma visão prática, com exemplos e com a abertura de uma discussão entre todos os leitores.

Programação de Banco de Dados

Os comandos da linguagem SQL são muito poderosos, mas normalmente consegue-se melhorar o desempenho das aplicações através da programação do banco de dados. Ao desenvolver módulos que sejam executados diretamente no servidor diminui-se o tráfego de informações na rede, esconde-se boa parte das estruturas das tabelas e agiliza-se o processamento e retorno das mensagens. Internamento o banco de dados possui mecanismos integrados que permitem unir as estruturas tradicionais de programação com os comandos SQL.

O banco de dados possui mecanismos próprios que podem ser utilizados em favor do desenvolvedor. Cada banco de dados possui um conjunto específico de comandos que definem a linguagem de programação do banco de dados. No caso do Oracle, a linguagem é o PL/SQL, o SQL Server possui o Transact-SQL, o DB2 possui sua própria linguagem de programação, o PostGreSQL possui diversas extensões que podem ser utilizadas como linguagem de programação e o MySQL lançou sua mais recente versão com a possibilidade de programar o servidor. Cada banco de dados é único sob este aspecto, mas todos trabalham sobre os mesmos conceitos. É possível criar módulos programáveis, como funções, procedimentos, objetos, pacotes, gatilhos, etc. Em todos os casos, há um engine responsável pela integração e execução dos módulos no servidor de banco de dados.

ETAPA 1 - Atividade 1: Consultas SQL e DML

Passo 1.1: Consultas SQL e comandos DML

Linguagem de Manipulação de Dados – São comandos que modificam o conteúdo das tabelas. Os comandos mais comuns são INSERT, UPDATE, SELECT e DELETE.

INSERT - Insere linhas de dados em uma uma coluna. Veja exemplo de utilização:

• INSERT INTO clientes VALUES (‘DADOS’)

Explicação (banco MYSQL)

• INSERT INTO - Comando para inserir os dados

• clientes - nome da tabela

• VALUES - Valores que serão inserido.

UPDATE - Atualiza os dados de uma tabela. Veja exemplo de utilização:

• UPDATE paciente SET nome=’EXEMPLO’ WHERE codigo=1 AND dado=30

Explicação (banco MYSQL)

Atualize (UPDATE) o campo nome para (SET) EXEMPLO quando (WHERE) o código for igual a 1 e (AND) a idade for igual a 30

• UPDATE - Comando para atualizar os dados

• SET - o que será alterado

• WHERE - condição

• AND - acrescenta outras condições

DELETE - Exclui dados de uma tabela. Veja exemplo de utilização:

• DELETE FROM paciente WHERE nome=’EXEMPLO’

Explicação (banco MYSQL)

• DELETE - comando para deletar

• FROM - em, indica a tabela

• WHERE - condição que indica o que será excluído

Note que em DELETE você ainda pode usar o AND caso deseja acrescentar mais condições.

Passo 1.2: Construção do Banco de Dados SIG_DB

Para desenvolvimento do Banco de dados e Tabelas abaixo foram usados os programas MySQL Workbench 6.1 e MySQL Command Line.

Criação das tabelas:

Banco de Dados ‘SIG_DB’

-- DATABESE SIG_DB

-- -----------------------------------------------------

CREATE DATABASE IF NOT EXISTS `SIG_DB`

USE `SIG_DB` ;

-- -----------------------------------------------------

Tabela `SIG_DB`.`PRODUTO`

CREATE TABLE IF NOT EXISTS `SIG_DB`.`PRODUTO` (

`IDPRODUTO` INT(11) NOT NULL AUTO_INCREMENT,

`DESCRICAO` VARCHAR(70) NOT NULL,

`PRECO_VENDA` DECIMAL(15,2) NOT NULL,

`PRECO_COMPRA` DECIMAL(15,2) NOT NULL,

`MARCA` INT(11) NOT NULL,

`TIPO` INT(11) NOT NULL,

PRIMARY KEY (`IDPRODUTO`),

-- -----------------------------------------------------

Tabela `SIG_DB`.`ITEMVENDA`

CREATE TABLE IF NOT EXISTS `SIG_DB`.`ITEMVENDA` (

`IDITEMVENDA` INT(11) NOT NULL AUTO_INCREMENT,

`VENDA_ITEMVENDA` INT(11) NOT NULL,

`PRODUTO_ITEMVENDA` INT(11) NOT NULL,

`QTDE` FLOAT(15,2) NOT NULL,

`VALOR_UNITARIO` DECIMAL(15,2) NOT NULL,

`VALOR_DESCONTO` DECIMAL(15,2) NOT NULL,

`VALOR_TOTAL` DECIMAL(15,2) NOT NULL,

`PRODUTO_IDPRODUTO` INT(11) NOT NULL,

PRIMARY KEY (`IDITEMVENDA`),

INDEX `fk_ITEMVENDA_PRODUTO1_idx` (`PRODUTO_IDPRODUTO` ASC),

CONSTRAINT `fk_ITEMVENDA_PRODUTO1`

FOREIGN KEY (`PRODUTO_IDPRODUTO`)

REFERENCES `SIG_DB`.`PRODUTO` (`IDPRODUTO`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

-- -----------------------------------------------------

-- Tabela `SIG_DB`.`VENDA`

CREATE TABLE IF NOT EXISTS `SIG_DB`.`VENDA` (

`IDVENDA` INT(11) NOT NULL AUTO_INCREMENT,

`CLIENTE_VENDA` INT(11) NOT NULL,

`DATA` DATE NOT NULL,

`HORA` TIME NOT NULL,

`VALORTOTAL` DECIMAL(15,2) NOT NULL,

`FUNCIONARIO_VENDA` INT(11) NOT NULL,

`ITEMVENDA_IDITEMVENDA` INT(11) NOT NULL,

PRIMARY KEY (`IDVENDA`),

INDEX `fk_VENDA_ITEMVENDA1_idx` (`ITEMVENDA_IDITEMVENDA` ASC),

CONSTRAINT `fk_VENDA_ITEMVENDA1`

FOREIGN KEY (`ITEMVENDA_IDITEMVENDA`)

REFERENCES `SIG_DB`.`ITEMVENDA` (`IDITEMVENDA`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

-- -----------------------------------------------------

-- Tabela `SIG_DB`.`CLIENTE`

CREATE TABLE IF NOT EXISTS `SIG_DB`.`CLIENTE` (

`IDCLIENTE` INT(11) NOT NULL AUTO_INCREMENT,

`NOME` VARCHAR(70) NOT NULL,

`CPF` VARCHAR(11) NOT NULL,

`RG` VARCHAR(20) NOT NULL,

`ENDERECO` VARCHAR(100) NOT NULL,

`CIDADE` VARCHAR(70) NOT NULL,

`UF` VARCHAR(2) NOT NULL,

`FONE` VARCHAR(15) NOT NULL,

`CELULAR` VARCHAR(16) NOT NULL,

`EMAIL` VARCHAR(100) NOT NULL,

`DATA_NASCIMENTO` DATE NOT NULL,

`GENERO` CHAR(2) NOT NULL COMMENT 'Tabela de registro de clientes',

`VENDA_IDVENDA` INT(11) NOT NULL,

PRIMARY KEY (`IDCLIENTE`),

INDEX `fk_CLIENTE_VENDA_idx` (`VENDA_IDVENDA` ASC),

UNIQUE INDEX `IDCLIENTE_UNIQUE` (`IDCLIENTE` ASC),

CONSTRAINT `fk_CLIENTE_VENDA`

FOREIGN KEY (`VENDA_IDVENDA`)

REFERENCES `SIG_DB`.`VENDA` (`IDVENDA`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

-- -----------------------------------------------------

-- Tabela `SIG_DB`.`FUNCIONARIO`

CREATE TABLE IF NOT EXISTS `SIG_DB`.`FUNCIONARIO` (

`IDFUNCIONARIO` INT(11) NOT NULL AUTO_INCREMENT,

`NOME` VARCHAR(70) NOT NULL,

`CPF` VARCHAR(11) NOT NULL,

`RG` VARCHAR(20) NOT NULL,

`CTPS` VARCHAR(20) NOT NULL,

`CARGO` VARCHAR(20) NOT NULL,

`DATA_NASCIMENTO` DATE NOT NULL,

`DATA_ADMISSAO` DATE NOT NULL,

`DATA_DESLIGAMENTO` DATE NOT NULL,

`ATIVO` TINYINT(1) NOT NULL,

`COMISSAO` DECIMAL(15,2) NOT NULL,

`VENDA_IDVENDA` INT(11) NOT NULL,

PRIMARY KEY (`IDFUNCIONARIO`),

INDEX `fk_FUNCIONARIO_VENDA1_idx` (`VENDA_IDVENDA` ASC),

CONSTRAINT `fk_FUNCIONARIO_VENDA1`

FOREIGN KEY (`VENDA_IDVENDA`)

REFERENCES `SIG_DB`.`VENDA` (`IDVENDA`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

Passo 1.3: Consultas e DML

Consulta Clientes:

SELECT * FROM CLIENTES;

Exibe todos os dados por coluna da tabela CLIENTE

Consulta Funcionários:

SELECT * FROM FUNCIONARIOS;

Exibe todos os dados por coluna da tabela FUNCIONARIOS

Consulta Vendas por Funcionário:

SELECT ‘IDVENDA, ‘IDFUNCIONARIO’ FROM VENDA;

Exibe a Venda X Funcionário com base no relacionamento da tabela VENDA.

Consulta Vendas por Produtos:

SELECT ‘IDVENDA, ‘IDPRODUTO’ FROM VENDA;

Exibe a Venda X Produto com base no relacionamento da tabela VENDA.

Consulta Vendas por Cliente:

SELECT ‘IDVENDA, ‘IDCLIENTE’ FROM VENDA;

Exibe a Venda X Cliente com base no relacionamento da tabela VENDA.

ACAO/TABELA DML

INSERT INSERT INTO `PRODURO` (`IDPRODUTO`,`DESCRICAO`,`PRECO_VENDA`,`PRECO_COMPRA`,`MARCA`,`TIPO`) VALUES (001,MOUSE,41.50,29.00,ZALMAN,"GAMER SERIES");

DELETE DELETE FROM 'PRODUTO' WHERE MARCA AOC;

UPDATE UPDATE 'PRODUTO' SET MARCA=CORSAIR WHERE MARCA=ZALMAN;

ETAPA 2 – Procedures e Triggers.

Passo 2.1 Criação Procedures e Triggers:

Uma Procedure é um programa escrito numa linguagem própria para Procedures no Firebird, sendo armazenada como parte do banco de dados. Podem ser acessadas através de aplicações clientes (sistemas externos), ou até mesmo por outras Stored Procedures ou Triggers.

Mas o que seria uma Trigger?

Uma Trigger é praticamente a mesma coisa que uma Stored Procedure, porém a única diferença é a forma como ela é chamada. Estas são chamadas sem a intervenção direta de um usuário, mas sim quando ocorre uma alteração em uma linha de uma tabela.

Passo 2.2 Procedures:

CREATE PROCEDURE ‘SIG_DB’.’ VENDA’_’FUNCIONARIO’ ret_comissao_funcionario,

Insert ON_VENDA AFTER INSERT ON VENDA FOR EACH ROW

INSERT INTO FUNCINARIO * ‘IDFUNCIONAIDO’. ‘IDVENDA’ (codigo_produto, descricao,unidade,categoria,valor_venda,IDFUNCIONARIO,)

VALUES (new.IDPRODUTO,new.DESCRICAO, new.QTDE, new.IDPRODUTO_MARCA, new.VLOR_VENDA, '0',COMISSAO(),now());

----------------------------------------------

CREATE PROCEDURE ‘SIG_DB’.’ VENDA’ inc_item_venda,

Insert ON_VENDA AFTER INSERT ON VENDA FOR EACH ROW

INSERT INTO VENDA * ‘IDVENDA’. ‘CLIENTE’ (codigo_produto, descricao,unidade,categoria,valor_venda,IDCLIENTE,)

VALUES (new.IDVENDA,new.DESCRICAO, new.QTDE, new.IDPRODUTO_MARCA, new.VLOR_VENDA, '0',COMISSAO(),now())

UPDATE IN ‘SIG_DB’. ‘VENDA’,

VALUES (new.IDVENDA=nem.IDVENDA+old.IDVENDA.fkIDPRODUTO);

------------------------------------------------

Passo 2.3 Triggers:

CREATE TRIGGER ‘SIG_DB’.’ VENDA’ atualiza_valor_venda,

AFETER UPDATE ON ‘VENDA’

INSERT INTO VENDA * ‘IDVENDA’. ‘CLIENTE’ (codigo_produto, descricao,unidade,categoria,valor_venda,IDCLIENTE,)

VALUES (new.IDVENDA,new.DESCRICAO, new.QTDE, new.IDPRODUTO_MARCA, new.VLOR_VENDA, '0',COMISSAO(),now())

UPDATE IN ‘SIG_DB’. ‘VENDA’,

VALUES (new.IDVENDA=nem.IDVENDA+old.IDVENDA.fkIDPRODUTO);

INSERT INTO ‘VENDA’.’ VENDA_TOTAL’,

VALUES (new.IDVENDA. fkIDPRODUTO);

ETAPA 3 – Otimização de Consultas em SQL

Passo 3.1 - Gerenciamento e escolha dos índices

Uma consulta mal projetada podem degradar bastante a performance de um banco de dados. Já vi processos imensos diminuírem drasticamente seu tempo de execução com apenas algumas alterações nas consultas que eram executadas.

É necessário, então, avaliar as consultas executadas no banco de dados, seja ele qual tipo ou plataforma for. Vou me ater nesse texto ao SQL Server que é o que tenho maior familiaridade,

O processamento de consultas, segundo SILBERSCHATZ et al. (1999), é uma atividade que permite extrair dados de um banco de dados. Esta atividade inclui a tradução de consultas expressas em linguagens de alto nível do banco de dados em expressões que podem ser implementadas no nível físico do sistema de arquivos, otimizações, traduções e avaliação das consultas.

O custo do processamento de uma consulta é determinado pelo acesso ao disco. Geralmente, há diversas estratégias possíveis para processar uma determinada consulta, principalmente se ela for complexa. A diferença entre uma estratégia boa e uma ruim, em termos do número de acessos de disco exigidos é frequentemente significativa e pode ser de grande magnitude. Consequentemente, vale a pena gastar uma quantia significativa de tempo na seleção de uma estratégia boa para processar uma consulta.

Para cada tabela envolvida na consulta SQL, o otimizado do SQL Server avalia os argumentos de pesquisa e avalia até que ponto o índice pode excluir linhas de uma seleção. Quanto mais linhas puderem ser excluídas, menor será o número de linhas a serem processadas.

Os índices são campos escolhidos arbitrariamente pelo construtor do banco de dados que permitem a busca a partir de tal campo a uma velocidade notavelmente superior. Entretanto, esta vantagem se vê contra arrestada pelo fato de ocupar muito mais memória (o dobro mais ou menos) e de requerer para sua inserção e atualização um tempo de processo superior.

Evidentemente, não podemos indexar todos os campos de uma tabela extensa já que dobramos o tamanho do banco de dados. Igualmente, tampouco serve muito indexar todos os campos em uma tabela pequena já que as seleções podem se efetuar rapidamente de qualquer forma.

Um caso em que os índices podem ser muito úteis é quando realizamos petições simultâneas sobre várias tabelas. Neste caso, o processo de seleção pode se acelerar sensivelmente se indexamos os campos que servem de nexo entre as duas tabelas.

Os índices podem ser contraproducentes se os introduzimos sobre campos triviais a partir dos quais não se realiza nenhum tipo de petição já que, além do problema de memória já mencionado, estamos lenificando outras tarefas do banco de dados como são a edição, inserção e eliminação. É por isso que vale a pena pensar duas vezes antes de indexar um campo que não serve de critério para buscas ou que é usado com muita frequência por razões de manutenção.

Passo 3.2 – Otimização das Consultas em Banco de Dados

Uma consulta SQL quando é solicitada ao banco de dados é tratada pelo SGBD, que ao encontrar o melhor caminho, mostra o resultado das informações descritas no comando. Este tratamento feito pelo SGBD, também conhecido como processamento de consultas, pesquisa uma expressão equivalente ao comando SQL com o objetivo de otimizar o tempo de execução da consulta.

Na aplicação da ATPS SIG_DB foram usados os princípios dos Indexes para auxílio na busca dos Banco dos Dados. Para exemplificar a otimização de consultas considere o seguinte comando:

SELECT c.nome FROM CLIENTE c, endereco e WHERE c.codend = e.codend AND e.cidade = “SÃO PAULO”;

• Expressão equivalente: a representação interna é convertida para uma expressão equivalente com o intuito de representar, de maneira mais eficiente, a consulta original. Ou seja, um mesmo comando pode ser representado de diferentes maneiras, mas gerará o mesmo resultado. Porém, cabe ao SGBD escolher a expressão que melhor representa e que tenha a melhor performance do que o comando original. Por exemplo, a condição WHERE cliente.nome = “JOAO” OR (cliente.idade > 10 AND cliente.idade < 30) também pode ser descrita como WHERE (cliente.nome OR cliente.idade > 10) AND (cliente.nome OR cliente.idade < 30). Assim, diante das diferentes formas, o SGBD deve escolher a melhor expressão e eliminar as demais do processo de execução de uma consulta SQL.

• Medição de custo: as expressões são consideradas como uma série de operações e para cada operação o SGBD avalia os procedimentos necessários para a implementação da operação e assim, calcula qual o custo da operação;

• Informações do catálogo do sistema: o SGBD verifica as informações referentes ao estado do banco de dados, como por exemplo, os índices referentes à consulta inicial, as tabelas relacionadas e suas cardinalidades.

• Planos de consulta: com as informações do catálogo e a medição dos custos, o otimizado gera os planos de consulta e em seguida, escolhe o melhor entre eles, ou seja, o de melhor desempenho (menor custo).

O tratamento que o SGBD realiza na execução de consultas em busca de otimização pode ser feito de duas maneiras: otimização heurística e otimização baseada em custos. Estas técnicas serão descritas nos próximos tópicos.

Passo 3.3 – Gerenciamento de Transação

O que é transação?

É uma unidade lógica de processamento que tem por objetivo preservar a integridade e a consistência dos dados. Esse processamento pode ser executado todo ou não garantindo a atomicidade das informações.

A sintaxe básica de uma transação é:

Begin Transaction

--Corpo de comando

Commit ou Rollback

Onde:

Begin Transaction: Tag inicial para o início de uma transação.

--Corpo de comando: Conjunto de comando a serem executados dentro de uma transação.

Commit ou Rollback: Comandos que finalizam a transação onde o ‘commit’ confirma o conjunto de comandos e o ‘rollback’ desfaz todo o processo executado pelo corpo de comandos caso tenha ocorrendo algum evento contrário ao desejado.

Verificando erros dentro de uma transação:

No SQL SERVE temos uma função de sistema que faz a identificação de um erro dentro de uma transação chamada de ‘@@ERROR’ função essa que por padrão recebe o valor 0 (zero) caso não ocorra nem um erro , no caso de algum erro ela assume o valor 1 (um).

A Microsoft criou duas classificações com relação aos tipos de transações, onde, podemos classificar as transações que iniciam com BEGIN TRANSACTION com transações explicitas, as transações implícitas são as transações que estão envolvidas algum processor de INSERT,UPDATE e DELETE onde o SQL SERVER trata cada um desse comandos com uma transação.

Caso ocorra a necessidade de deixa o SQL SERVER no modo implícito basta executar a seguinte linha de comando abaixo, feito isso todo processo executado pelo SQL será tratado com uma transação.

SET IMPLICIT_TRANSACTIONS ON

Assim como podemos definir que todos os processos que o SQL SERVER execute se transforme em alguma transação, pode automatizar o processo, caso ocorra algum erro não se farar necessidade executar o comando ‘rollback’ executando a linha de comando a baixo fazendo com que em caso de algum erro, seja desfeita a todos os processos que estão no corpo de comando de uma transação, sem a necessidade de usar a função @@ERROR para verificar a ocorrência de erros.

SET XACT_ABORT ON

Todo a transação é registrada no log do banco de dados, pois quando executamos alguma comando de INSERT, UPDATE E DELETE o mesmo não executa a operação na tabela para garantir atomicidade das informações, pois caso ocorra algum eventual problema durante a transação o engine do SQL SERVER possa confirmar as transações confirmadas ou desfazer as transações registradas.

Os saves points

O save point é o comando utilizado para confirma pequenas transações que estão dentro de uma maior garantindo a execução de uma parte da transação onde para utilizamos devemos atribuir um nome ao save point para identificá-lo.

EATAPA 04: Banco de Dados Distribuídos e Data Warehouse

Passo 4.1 Bancos de Dados Distribuídos

Ao contrário dos sistemas paralelos em que os processadores são fortemente acoplados e constituem um único sistema de banco de dados, um sistema de banco de dados distribuídos consiste em sítios fracamente acoplados, que não compartilham componentes físicos. Além do mais os sistemas de banco de dados que executam em cada sítio podem ter um grau de independência mútua substancial.

Cada sítio pode participar da execução de transações que acessam dados em um ou vários sítios. A diferença principal entre sistemas de banco de dados centralizados e distribuídos é que no primeiro os dados residem em único local, enquanto no segundo os dados residem em vários locais. Essa distribuição de dados é a causa de muitas dificuldades no processamento de transação e processamento de consulta.

As classificações do banco de dados distribuídos podem ser homogêneas ou heterogêneas.

Em um sistema de banco de dados distribuído homogêneo, todos os sítios possuem software de sistema de gerenciamento e banco de dados idêntico conhecem uns aos outros e concordam em cooperar nas solicitações dos usuários do processamento .Nesse tipo de sistema os sítios locais entregam uma parte de sua autonomia em termos de seu direito de mudar esquemas ou software de sistema de gerenciamento de banco de dados .Esse software também precisa cooperar com outros sítios na troca de informação sobre transações para tornar o processamento da transação possível entre vários sites.

Ao contrário em um banco de dados distribuído heterogêneo diferentes sítios podem usar diferentes esquemas e software de sistemas de gerenciamento de banco de dados .Os sítios podem não ser cientes uns dos outros e oferecer facilidade apenas limitadas para cooperação no processamento da transação .As diferenças nos esquemas normalmente são um problema importante para o processamento da consulta enquanto a divergência no software se torna um obstáculo para o processamento de transação que acessam múltiplos sítios

Passo 4.2 Data Warehouse

Um depósito de dados (data warehouse) é um repositório (ou arquivo) de informações colhidas de várias origens armazenadas sob um esquema unificado, em um único local. Uma vez reunidos os dados são armazenados por muito tempo, permitindo acesso a dados históricos. Assim os depósitos de dados oferecem ao usuário uma única interface consolidada para os dados, facilitando a escrita de consultas de apoio a decisão a partir de um depósito de dados quem toma decisões pode garantir que os sistemas de processamento de transação on-line não serão afetados pela carga de trabalho de apoio a decisão.

Arquitetura de Data Warehouse

As arquiteturas de duas e três camadas são comuns, mas às vezes, há apenas uma camada. Hoffer as distinguem dividindo o Data Warehousing em Três partes:

1. O próprio Data Warehouse, que contém os dados e o software associados;

2. Software de aquisição de dados (retaguarda), que extrai dados dos sistemas legados e fontes externas, os consolida e resume, e depois os carrega no Data Warehouse;

3. Software cliente (front-end), que permite aos usuários acessar e analisar dados a partir do Warehouse (um mecanismo de DSS/BI/Análise de Negócios[BA]).

Na Arquitetura de três camadas, os sistemas operacionais contêm dados e o software para aquisição em uma camada (o servidor), o Data Warehouse em outra camada, e a terceira camada inclui o mecanismo de DSS/BI/BA (servidor de aplicação e o cliente.

Exemplos de companhias que utilizam DW

Vantagens da utilização do DW – Os itens utilizados foram extraídos do estudo feito por Sakaguchi e Frolick (1997) sobre vários casos de empresas que já estavam utilizando ou estavam no processo inicial de construção de um DW. A intenção é conhecer, na percepção do CI, quais vantagens são consideradas mais importantes. Nas duas empresas, os CI “concordam em parte” com as vantagens do uso do DW. Na percepção dos CI dessas empresas, as maiores vantagens da utilização da ferramenta DW estão na infraestrutura computacional e na segurança. Outra vantagem apontada, esta pela Empresa B, foi o custo da operação. Este item é interessante, pois como se trata de uma organização coorporativa, existe preocupação quanto a custos.

Data Mining

O termo mineração de dados (ou data mining) refere-se em geral ao processo de analisar grandes bancos de dados de forma semiautomática para encontrar padrões úteis Assim como a descoberta de conhecimento na inteligência artificial (também chamado aprendizado de máquina) ou na análise estatística, a mineração de dados tenta descobrir regras e padrões a partir dos dados. Porem a mineração de dados difere do aprendizado de máquina e da estatística porque lida com grande volume de dados, armazenados principalmente no disco. Ou seja a miner