Data Ecology – Página 4 – Making Data Work

A Arte das Bases de Dados

8 Novembro 20128 Novembro, 2012Carlos Pampulim CaldeiraLeave a comment

O planeamento é a mãe de todo o sucesso.

Uma ideia tão simples que se expressa numa única linha, mas que no entanto não é habitualmente levada a sério.

Ao longo de cerca de um quarto de século dedicado ao ensino e investigação de matérias associadas com o mundo das bases de dados relacionais, tenho-me deparado com inúmeras situações em que a pressa e o desleixo na conceptualização destes sistemas têm conduzido a produtos imaturos, pouco rigorosos, e imediatamente desactualizados desde o seu primeiro dia de funcionamento.

Os resultados provocados nas organizações por esses maus produtos variam entre dois extremos: o completo desinteresse pelo conceito de «base de dados» até ao colapso organizativo e económico da entidade que encomendou uma base de dados e recebeu uma tulha de dados.

O «fazer» uma base de dados é mais do que construir meia dúzia de tabelas num modo ad hoc com a esperança de que a velocidade de desenvolvimento daí resultante consiga impressionar o utilizador final; a construção de uma base de dados é um processo sujeito a normas analíticas e técnicas precisas e bem conhecidas que devem ser seguidas em determinada ordem, desde a etapa de conceptualização até à fase de construção física da base de dados.

Assim como um cirurgião ortopedista segue um determinado procedimento para reparar uma fractura num osso, também o especialista em base de dados tem que obedecer a uma conduta tecnológica de modo a obter um produto final válido tecnicamente, e que devolva à organização um valor acrescentado.

O segredo no sucesso no desenvolvimento de Sistemas de Informação em geral e, em particular em Base de Dados Relacionais, é assim a organização.

O conteúdo deste livro destina-se a «meros mortais» como sejam, por exemplo, gestores ou investigadores e estudantes nas mais variadas áreas da ciência e tecnologia. Os temas são apresentados de uma forma simples, sem a complexidade desnecessária habitual em certos livros de informática, nem a superficialidade existente noutros.

Edições Sílabo

ISBN: 978-972-618-627-4

Trigger para validação de data | Oracle

8 Novembro 20128 Novembro, 2012Carlos Pampulim CaldeiraLeave a comment

Considerem-se as seguintes tabelas:

Curso

Disciplina

Disciplina no Curso

Pretende-se impedir que sejam introduzidas na tabela “Disciplina no Curso” datas de cessação inferiores à data actual. Como em Oracle não se pode validar datas comprando-as com o SYSDATE através de CHECK, então uma outra possibilidade será o da utilização de um trigger insert/update que faça essa verificação.

CREATE OR REPLACE TRIGGER trg_check_data_cessacao
     BEFORE INSERT OR UPDATE ON “Disciplina no Curso”
FOR EACH ROW
     BEGIN
       IF( :new.”Data de Cessação” > SYSDATE )
         THEN
       RAISE_APPLICATION_ERROR( -20001,
           ‘Data de Cessação inválida: esta data tem que ser maior que o valor actual da data.’);
       END IF;
     END;

SYSDATE numa restrição CHECK em Oracle

8 Novembro 20128 Novembro, 2012Carlos Pampulim CaldeiraLeave a comment

Como o valor de SYSDATE (data do sistema) é quase sempre diferente em cada momento de avaliação de uma cláusula CHECK então o Oracle não nos deixa fazer uma restrição desse tipo.

Imagine-se, por exemplo, que se quer inserir apenas valores que sejam maiores do que SYSDATE e considere-se que o valor de SYSDATE vai aumentado com o tempo:

[Data de Fim] > SYSDATE

30-JAN-2012 > 26-DEC-2011
………………………………………
30-JAN-2012 > 10-FEB-2013

O valor de SYSDATE vai aumentando até ultrapassar o valor inserido na coluna, tornando o CHECK inválido e, consequentemente, a base de dados inconsistente. Dai não ser possível utilizar este tipo de regra de (anti)-integridade.

A validação terá que ser feita por intermédio de um trigger do tipo BEFORE INSERT OR UPDATE.

DBA | Isolamento de transacções

8 Novembro 20128 Novembro, 2012Carlos Pampulim CaldeiraLeave a comment

As normas ANSI SQL determinam os seguintes três tipos de isolamento transaccional nos sistemas de gestão de bases de dados:

Dirty Read. A transacção T1 modifica um facto. Outra transacção T2 lê esse mesmo facto antes que T1 faça commit ou rollback. Se T1 desistir da transacção (rollback) então T2 leu um facto que nunca foi confirmado e, como tal, nunca existiu.
Non-Repeatable Reads. A transacção T1 lê um facto. Outra transacção T2 modifica ou apaga esse facto e faz commit. Se T1 renovar o pedido desse facto descobre que ele foi modificado ou que já não existe.
Phantom. A transacção T1 lê um conjunto de factos de acordo com uma determinada condição. A transacção T2 insere novos factos, que satisfazem a condição de T1, e confirma-os na base de dados. Se T1 voltar a fazer a mesma leitura-condição obtém um conjunto de factos distintos dos da leitura inicial.

DBA | Gestão de Transacções

8 Novembro 20128 Novembro, 2012Carlos Pampulim CaldeiraLeave a comment

O papel da gestão de transacções é o de assegurar que as transacções são gravadas correctamente na base de dados. O gestor de transacções é o componente do SGBDR que processa esses movimentos de dados. Uma transacção é um conjunto de acções ou movimentos de dados considerados de modo a que sejam todos gravados na base de dados ou rejeitados na sua totalidade. Uma transacção é uma unidade atómica de trabalho em que todos os seus elementos têm que ser processados, caso contrário a base de dados ficará inconsistente. O pagamento de uma propina escolar, por exemplo, é uma transacção que se subdivide, em grandes linhas, em dois elementos: a actualização do saldo da conta de propinas da escola, e a actualização dos montantes pagos por esse aluno. A base de dados ficaria inconsistente se se alterasse um único desses elementos: ou se faz tudo ou não se faz nada.

O princípio da atomicidade transaccional exige que todo o conteúdo transaccional seja processado segundo a regra do “tudo-ou-nada”, e que cada conjunto de transacções seja transmissível em série / realizável (serializable). Quando uma transacção é interrompida antes do seu termo o gestor de transacções têm que repor a base de dados no estado em que se encontrava antes do início da operação, desfazendo todas as acções entretanto efectuadas. As transacções, por uma questão de eficiência e de eficácia, não devem durar mais do que o necessário de modo a assegurar a integridade do sistema. No caso da liquidação de uma propina o pagamento do aluno e o crédito na contabilidade da escola é a unidade mínima de trabalho necessária para manter as contas em dia.

ODS vs. Data Warehousing

2 Novembro 20122 Novembro, 2012Carlos Pampulim CaldeiraLeave a comment

O ODS (Operational Data Store) é um elemento fundamental do data warehouse empresarial proposto por Bill Inmon, para muitos considerado o pai do Data Warehousing. O ODS é uma estrutura de dados normalizada, uma base de dados normal, construída com todas as regras de integridade inerentes ao modelo de dados relacional, e que serve de transição entre o sistema transaccional e os data marts segundo o pensamento de Inmon.

Na óptica do modelo dimensional – que é a perspectiva que sigo – o ODS é uma estrutura redundante dado que obriga a que seja desenvolvida de raiz mais uma base de dados completa (diferente do sistema transaccional e do DW) cuja única e exclusiva função é a de abastecer de dados o DW. Então ficaríamos com duas bases de dados transaccionais com a mesma função, e cuja duplicação poderia dar azo a enganos na transição para o DW.

Em questões de segurança da informação o ODS não tem nenhuma vantagem adicional pois como o seu conteúdo é reescrito diariamente – ou em que período seja – a partir dos dados transaccionais, qualquer erro – intencional ou por incompetência – no processo de carregamento do ODS resultará na sua corrupção.

De qualquer modo, importa ainda salientar que a informação contida no data warehouse é não-volátil, ou seja, só em casos de erro (por exemplo: nomes incorrectos de pessoas) é que há lugar a modificação dos dados armazenados.

A única forma de corromper um DW é utilizar uma metodologia errada de carregamento: apagar tudo o que já está no DW e carregar tudo de novo em cada momento de refrescamento, o denominado método da “força bruta”. Ora, como esse método não é casuístico e só se deve utilizar uma única vez (no carregamento inicial do DW) este problema não se coloca. É nessa primeira vez que deverão ser desencadeados mecanismos de auditoria que constatarão, ou não, da conformidade da informação do DW com os objectivos delineados no projecto da sua construção. A partir dai apenas é acrescentada informação ou corrigidos erros.

O próprio data warehouse devido à sua estrutura em forma de estrela tem as regras de integridade necessárias e suficientes para impedir que sejam carregados dados fora de contexto.

Em tudo o mais a segurança física do DW tem que ser assegurada de acordo com as políticas de Backup e Recovery em vigor no local de instalação do DW. Devido à importância funcional do DW na empresa (órgãos intermédios e superiores de decisão) é de muito bom senso que essas políticas de seguranças sejam devidamente certificadas.

Máquina do tempo…em Oracle

2 Novembro 20122 Novembro, 2012Carlos Pampulim CaldeiraLeave a comment

Acontece por vezes que alguns dados podem inadvertidamente ser apagados ou modificados e não há tempo para os restaurar a partir de um dispositivo de backup. O Oracle possui uma tecnologia bastante útil denominada Flashback que permite que se façam queries “a um passado recente”. O “quanto” é permitido recuar depende do espaço disponível em UNDO.

Suponha-se que na última hora se apagou qualquer linha da tabela Curso e que agora é imperioso saber que dados foram removidos:

SELECT * FROM “Curso” AS OF TIMESTAMP SYSDATE-1/24;

Através desta característica é possível fazer o seguinte:

Pesquisar dados que já não existem (“do passado”);
Analisar os metadados de modo a evidenciar o historial de alterações à base de dados;
Recuperar tabelas ou linhas para um determinado ponto do tempo;
Fazer rollback de transacções enquanto a base de dados de produção continua activa;
Fazer a gestão de transacções.

Tabela dual ou dummy

31 Outubro 201231 Outubro, 2012Carlos Pampulim CaldeiraLeave a comment

Este tipo especial de tabela, denominada em inglês de dummy, serve o propósito especial de fazer algumas operações sobre conjuntos sem aceder a tabelas de dados propriamente ditas. Isso alivia a carga do sistema e impede, por exemplo, que se façam utilizações indevidas a tabelas com muitas linhas.

Este tipo de tabelas pode ser utilizado para trabalhar com triggers ou, mais simplesmente, para obter uma marca temporal. Convém que a tabela dummy tenha uma única linha para evitar que o resultado se multiplique num output com o mesmo número de linhas da tabela.

Como fazer e utilizar?
Em primeiro lugar deve criar-se a tabela:
——————————————————–
– DDL para a tabela LAMY
——————————————————–
CREATE TABLE lamy (
lam varchar(2)
);
Em segundo lugar insere-se uma linha na tabela:
INSERT INTO lamy (lam) VALUES (‘a’);
Aplicações:

Obter a data actual do sistema:
- select SYSDATE from lamy;
- Resultado:
Fazer um cálculo:
- SELECT (2+4) / 2 FROM lamy;
Criar uma tabela com 100000 linhas com dados aleatórios:
- CREATE TABLE tabela_teste AS
  SELECT LEVEL id, SYSDATE+DBMS_RANDOM.VALUE(-1000, 1000) valor_data, DBMS_RANDOM.string(‘A’, 20) valor_texto
  FROM lamy
  CONNECT BY LEVEL <= 100000;
  - NOTA: O tempo necessário para inserir 100 000 linhas na tabela pode ser muito longo. Quem quiser pode experimentar com um número menor de linhas. O tempo de execução aumenta (quase) exponencialmente se a tabela lamy tiver mais do que uma linha.

DBA | Transacção

31 Outubro 201231 Outubro, 2012Carlos Pampulim CaldeiraLeave a comment

Uma transacção agrupa um conjunto de operações que transformam a base de dados de uma estado consistente n para outro estado consistente n+1. Pode considerar-se que há uma história – ou cronograma ou processo – que modela/transforma a execução em simultâneo (interleaved) de um conjunto de transacções numa série temporal de operações lienares sobre determinadas peças de informação.

Duas operações nesse cronograma entram em conflito quando pertencem a transacções distintas e, pelo menos, uma delas efectua uma operação de escrita sobre a mesma peça de informação. Uma peça de informação pode ser, por exemplo, uma linha de uma tabela, uma coluna de uma tabela, uma tabela inteira, ou um espaço de tabelas.

Uma história pode resumir-se num grafo de dependências que estabelece as marcas temporais no fluxo de dados entre transacções. Uma história é compreensível e é considerada realizável (serializable) quando é equivalente a um conjunto de eventos realizados em série, i.e., quando o seu grafo de dependências tem a mesma cronologia de uma história que execute sequencialmente (em série) as transacções.

O que não se deve fazer no desenvolvimento de um DW

19 Julho 200919 Julho, 2009Carlos Pampulim CaldeiraLeave a comment

O que não se deve fazer no desenvolvimento de um DW
Em seguida listam-se algumas das coisas que não se deve fazer no desenvolvimento de um DW. Os elementos não estão ordenados e a importância de cada um deles depende do projecto em causa.

Evitar a excessiva focalização na tecnologia em si mesma. O único aspecto que interessa é os requisitos dos processos de negócio e os objectivos das organizações;
Desenvolver o DW sem ter o apoio de elementos de alto nível da administração da organização, pois devido à sua natureza não transaccional os níveis intermédios e baixos da hierarquia não compreendem a importância do DW;
Nunca ter a veleidade de querer desenvolver todo o DW de uma só vez. O único caminho para o sucesso é a construção de data marts integrados que são disponibilizados ao cliente à medida que ficam prontos;
Despender tempo e trabalho na tarefa inútil de estruturar o DW como se fosse uma base de dados relacional. O objectivo é conseguir uma estrutura especialmente adaptada à análise da informação e que produza interfaces amigáveis;
Nunca ir pelo caminho da complexificação da informação, a simplicidade é o lema do bom profissional;
Evitar a construção de diferentes tabelas de dimensão sobre o mesmo assunto.