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;

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.