Oracle | Data aleatória

Pretende-se gerar uma data aleatória entre 2006-12-01 e 2006-12-20 (um intervalo de 20 dias). Para fazer o cálculo transforma-se a data para o dia juliano em número: TO_CHAR(TO_DATE('2006-12-01', 'YYYY-MM-DD'), 'J'):
SELECT TO_DATE(TRUNC(DBMS_RANDOM.VALUE(
       TO_CHAR(TO_DATE('2006-12-01', 'YYYY-MM-DD'), 'J'),
       TO_CHAR(TO_DATE('2006-12-01', 'YYYY-MM-DD'), 'J')+20)), 'J')
FROM DUAL;

DBA | Afinação da Aplicação

Estatísticas | Oracle

Custo de Execução de Queries | Oracle

Data Warehousing - Conceitos e Modelos - 2ª Edição

Já está disponível a 2ª edição revista e aumentada de "Data Warehousing: Conceitos e modelos".

Valores booleanos em bases de dados

Em bases de dados não é nada aconselhável a utilização de booleanos. "Dados" como 'Sim' ou 'Não' não tem grande significado e geram múltiplas interpretações pelo que é sempre melhor atribuir valores explícitos, ou seja, que sejam clara e univocamente compreensíveis pelos utilizadores.

Na presença de valores deste tipo é frequente que os utilizadores tentem interpretá-los à sua maneira ou, pior ainda, fazendo suposições que estão longe do que o pretendido pelo sistema de informação.

Quando, por exemplo, uma tabela contém um campo denominado "Persistente" onde se pretende armazenar o facto de esse produto ter um carácter persistente após ter sido aplicado é bem mais explícito, e livre de falsas interpretações, se os valores forem do género 'Muito persistente , 'Não persistente" em vez de 'Sim', 'Não' ou 'S', 'N'.

Big Data: o tamanho importa! (Parte I)

Tal como outras tecnlogias/técnicas que o antecederam (por exemplo o armazenamento Cloud, a virtualização ou mesmo o Data Warehousing) o Big Data, por enquanto, parece não ser mais do que um termo da moda. Será que passará a ser verdadeiramente útil? Quando, como e porquê?

Para começar pode dizer-se que o Big Data é um conceito que se refere à colecta e análise de toda e qualquer peça de informação proveniente de todos os tipos de fontes.

Se observarmos uma breve cronologia que comece nos centros de informática dos anos 70 e 80, passe pelos sistemas de informação executivos dos anos 90 e, mais recentemente, pelo data warehousing e business intelligence, pode considerar-se que o Big Data como a etapa em curso.

À medida que a sociedade actual vai gerando mais e mais montanhas de dados é necessário encontrar uma forma de ir escavando essas encostas à procura de dados preciosos.

Actualmente, as três maiores áreas de aplicação do Big Data são a análise financeira, o serviço e apoio ao cliente e estudos de marketing. A dimensão das empresas não é aqui relevante dado que o Big Data destina-se a todas as organizações nas quais os dados estão no seu centro de actividade. É minha convicção de que as PMEs poderão retirar vantagens acrescidas da utilização do Big Data nas suas actividades do dia-a-dia.

A Arte das Bases de Dados

 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

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

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

As normas ANSI SQL determinam os seguintes três tipos de isolamento transaccional nos sistemas de gestão de bases de dados:
  1. 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.
  2. 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.
  3. 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

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

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


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


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:
  1. Obter a data actual do sistema:
    • select SYSDATE from lamy;
    • Resultado:
  2. Fazer um cálculo:
    • SELECT (2+4) / 2 FROM lamy;
  3. 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


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.