0

UNIVERSIDADE DE CAXIAS DO SUL

MARILIA VITOR PEREIRA

IMPLEMENTAÇÃO DE ASPECTOS TEMPORAIS EM UM SISTEMA

GERENCIADOR DE BANCO DE DADOS CONVENCIONAL

Vacaria
2008
 1

MARILIA VITOR PEREIRA

IMPLEMENTAÇÃO DE ASPECTOS TEMPORAIS EM UM SISTEMA

GERENCIADOR DE BANCO DE DADOS CONVENCIONAL

Trabalho de Conclusão de Curso

apresentado para a disciplina de TCC II à
Universidade de Caxias do Sul, no curso
de Sistemas de Informação.

Orientador: Prof. José Maurício Carré Maciel

Vacaria
2008
 2

AGRADECIMENTO

Agradeço primeiramente a Deus que me deu a vida e me

iluminou durante esta caminhada. Aos meus pais, Mario e
Usilia, que me apoiaram em todas as etapas e de todas as formas
possíveis, com muita dedicação, compreensão e incentivo.
À minha irmã, Mônica, e meu cunhado Vinícius que eu
sempre posso contar.
Ao meu noivo, Éverton, que de forma especial, carinhosa
e principalmente amorosa me deu forças e coragem, me
apoiando nos momentos difíceis
Ao meu orientador, José Maurício, modelo de ética e
profissionalismo, obrigada pela atenção e confiança. Agradeço a
todos que passaram pela minha vida nesses cinco anos e meio de
faculdade e que, mesmo sem saber, me ensinaram mais do que
posso dizer em palavras.
 3

RESUMO

Sistemas de Bancos de Dados convencionais permitem apenas o armazenamento do

estado atual de um ou mais objetos. Para muitos sistemas, no entanto, é desejável que se possa

armazenar e recuperar todos os estados do ciclo de vida dos mesmos. Esta constatação

motivou a realização de diversos estudos sobre a criação de sistemas de bancos de dados

temporais ou mesmo a incorporação de características destes nos sistemas convencionais.

Embora muitas propostas efetivas tenham sido elaborados, nenhuma foi adotada como padrão

pela indústria.

Este trabalho apresenta uma investigação acerca do estado da arte no que se refere a

bancos de dados temporais, seus conceitos, recuperação de dados com a linguagem TSQL2 e

implementação de alguns de seus aspectos sobre um sistema gerenciador de banco de dados

convencional. Por fim é apresentada a ferramenta pgTemporal, que simplifica a recuperação

de dados históricos dos objetos armazenados.

 4

LISTA DE FIGURAS

Figura 1: Diagrama de Atividades da Inserção de Dados ................................................. 36

Figura 2: Diagrama de Atividades da Alteração de Dados ............................................... 38
Figura 3: Diagrama de Atividades da Exclusão de Dados ................................................ 39
Figura 4: Snapshot ............................................................................................................ 42
Figura 5: Consultas Temporais ......................................................................................... 43
Figura 6: Manipulação de Dados ...................................................................................... 44
Figura 7: Modelo E-R ....................................................................................................... 45
 5

LISTAGEM DE QUADROS

Quadro 1: Visualização da Tabela .................................................................................... 34

 6

LISTAGEM DE TABELAS

Tabela 1: Representação do Tempo de Validade na TSQL2 ............................................ 19

Tabela 2: Representação do Tempo de Transação na TSQL2 .......................................... 19
Tabela 3: Representação do Tempo de Transação e Validade (bitemporal) na TSQL2 ... 20
 7

LISTAGEM DE SIGLAS E ABREVIATURAS

TSQL2 Temporal Structured Query Language 2

ISO International Standards Organization
ANSI American National Standards Institute
SQL Structured Query Language
SGBD Sistema Gerenciador de Banco de Dados
 8

SUMÁRIO

INTRODUÇÃO ................................................................................................................ 9

1 OBJETIVOS .................................................................................................................. 11
1.1 OBJETIVO GERAL ................................................................................................... 11
1.2 OBJETIVOS ESPECÍFICOS ..................................................................................... 11

2 O ASPECTO TEMPO EM BANCO DE DADOS ........................................................ 12

3 LINGUAGEM DE CONSULTA TEMPORAL ............................................................ 15

3.1 TSQL2 ........................................................................................................................ 16
3.1.1 Tipos de dados suportados por TSQL2 .................................................................... 18
3.1.2 Tipos de Tempo ....................................................................................................... 18
3.1.3 Ordem no Tempo ..................................................................................................... 20
3.1.4 Granularidade ........................................................................................................... 20
3.1.5 Rótulos Temporais ................................................................................................... 21
3.1.6 Sintaxe ..................................................................................................................... 22

4 METODOLOGIA ..................................................................................................... 27

5 SELEÇÃO DE UM SGBD PARA PROTOTIPAÇÃO ................................................ 29

6 IMPLEMENTAÇÃO DA QUESTÃO TEMPORAL SOB O BANCO DA DADOS 32

CONVENCIONAL ...........................................................................................................
6.1 Definição das Linguagens ........................................................................................... 32
6.2 Definição de Tabelas .................................................................................................. 33
6.3 Adição da Dimensão Temporal .................................................................................. 33
6.4 Gerenciamento do Armazenamento dos Dados Temporais ........................................ 34

7 UMA INTERFACE PARA GERÊNCIA DE BANCO DE DADOS 41

CONVENCIONAIS ACRESCIDOS DE DIMENSÃO TEMPORAL – pgTemporal .....
7.1 Snapshot ...................................................................................................................... 41
7.2 Consultas Temporais ................................................................................................... 42
7.3 Manipulação de Dados ................................................................................................ 43
7.4 Estudo de Caso ............................................................................................................ 44

CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS ............................................ 47

REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................. 49

 9

INTRODUÇÃO

Sistemas gerenciadores de bancos de dados constituem-se no padrão de

armazenamento de dados e oferecem a infra-estrutura necessária para construção de sistemas

de informação. Quando da utilização de um banco de dados, torna-se também necessária a

utilização de uma linguagem de consulta que ofereça suporte adequado aos tipos e critérios de

seleção de dados temporais. Embora a linguagem SQL (Structured Query Language)

constitua o padrão vigente para recuperação de dados em banco de dados relacionais, esta

ainda não oferece o suporte necessário para suprir estas necessidades.

Sistemas de Bancos de Dados convencionais armazenam o estado atual de um dado.

Entretanto, este dado pode assumir diversos valores ao longo do tempo e, em muitos casos, é

extremamente importante que todos os estados deste dado sejam armazenados e

possivelmente recuperados. Como exemplos, podem ser citados o caso de um banco de dados

de pacientes que precisa armazenar informações sobre o histórico médico dos mesmos ou um

sistema de monitoramento de máquinas de uma fábrica que armazena informações sobre as

leituras atuais e passadas destas máquinas para análise.

A constatação de que os dados evoluem com o passar do tempo e que todos estes

valores não devem ser perdidos, levou à criação dos bancos de dados temporais, onde todos

os estados (passado, presente e futuro) dos dados ficam armazenados, bem como a

possibilidade de recuperação.

Segundo Silberschatz (2006), muitas propostas foram feitas para a extensão da SQL a

fim de melhorar seu suporte de dados temporais, mas, pelo menos até o padrão ISO (2003), a

SQL não fornecia qualquer suporte especial para estes dados.

Este trabalho está organizado como descrito a seguir: o capítulo 1 apresenta os

objetivos deste trabalho, o capítulo 2 apresenta uma investigação acerca do estado da arte de
 10

banco de dados temporais e seus conceitos, seguida pelo capítulo 3, que é destinada à

recuperação de dados através da linguagem de consulta TSQL2. O capítulo 4 apresenta a

metodologia científica do trabalho, seguido pelo capítulo 5 que apresenta o método de escolha

do sistema gerenciador de banco de dados para prototipação, juntamente com as

características e funcionalidades do banco efetivamente escolhido. A seguir, no capítulo 6, é

apresentada a implementação da dimensão temporal sob o banco de dados convencional, a

definição das linguagens, tabelas, armazenamento e consulta de dados. O capítulo 7 mostra

uma interface para gerência de banco de dados convencionais acrescidos de dimensão

temporal, o pgTemporal, suas características, funcionalidades e um estudo de caso. Por fim,

são apresentadas as considerações finais e trabalhos futuros.

 11

1 OBJETIVOS

1.1 OBJETIVO GERAL

Demonstrar a aplicabilidade dos conceitos de bancos de dados temporais em sistemas

gerenciadores de bancos de dados convencionais, visando sua utilização em sistemas de

informação.

1.2 OBJETIVOS ESPECÍFICOS

a) Investigar o estado da arte de bancos de dados temporais no que se refere à

implementação de seus conceitos e características em bancos de dados convencionais;

b) Desenvolver suporte a características de sistemas de bancos de dados temporais em

um sistema gerenciador de banco de dados convencional através de procedimentos

armazenados e gatilhos;

c) Validar a solução apresentada com a prototipação de um experimento que simule

situações usuais de sistemas de informação.

 12

2 O ASPECTO TEMPO EM BANCO DE DADOS

Em conformidade com Souza e Santos (2002), sistemas de banco de dados são

utilizados para armazenar informações do mundo real. Os bancos de dados convencionais

armazenam apenas um estado dos dados, o estado atual. Porém, os atributos de um objeto

podem assumir diferentes valores ao longo do tempo e o conjunto destes valores constitui a

história desse objeto. A constatação de que os dados evoluem com o passar do tempo e que os

valores antigos da informação não devem ser perdidos, levou à criação dos bancos de dados

temporais, onde podem ser conservados todos os valores de dados definidos (passado,

presente e futuro).

Em muitas aplicações, é importante armazenar e recuperar informações sobre estados

passados. Para citar alguns exemplos, pode ser referenciado o caso de um banco de dados de

pacientes que precisa armazenar informações sobre o histórico médico dos mesmos. Outro

exemplo é o de um sistema de monitoramento das máquinas de uma fábrica que armazena

informações sobre as leituras atuais e passadas das mesmas para análises.

Informações temporais são representadas em banco de dados através de datas,

períodos, intervalos temporais e duração da validade de informações. A associação entre as

informações temporais e os dados, ou simplesmente a inserção de tempo a um dado, é

possível através do acréscimo de uma dimensão temporal ao banco de dados. Com esta

dimensão é possível identificar quando uma informação foi definida e qual o tempo em que

ela é válida (PINHEIRO apud EDELWEISS, 1998). Esta dimensão temporal associa um

tempo a um atributo de forma que se o valor do atributo for alterado, o valor anterior não é

perdido.
 13

No entanto, para utilizar esta abordagem em sistemas de informação, torna-se

necessário ou conveniente que haja suporte à regras ativas, como gatilhos, no sistema

gerenciador de banco de dados utilizado.

Simonetto (1999), classifica a forma utilizada para armazenar valores temporais como

a seguir:

a) Banco de Dados Instantâneos: nesse tipo de banco de dados, os únicos valores

perceptíveis são os valores presentes. Cada modificação no valor de uma

propriedade pode ser percebida como uma transição do banco de dados. Em uma

transição o valor anteriormente armazenado é destruído e somente o último valor

está disponível. O estado atual do banco de dados, composto pelos valores atuais

de todas as propriedades, é o único existente. São os bancos de dados

convencionais.

b) Banco de Dados de Tempo de Transação: onde o valor definido é associado ao

instante temporal em que foi realizada a transação, sob forma de um rótulo

temporal. Uma relação que utilize essa abordagem pode ser vista como tendo três

dimensões (tuplas, atributos, tempo de transação). Os bancos de dados de tempo de

transação permitem a recuperação de informações definidas em algum instante do

passado, pois todos os dados passados estão armazenados associados ao seu

instante de definição (tempo de transação). Uma tupla passa a ser válida no

momento em que é inserida na base de dados. Alterações retroativas não podem

ser executadas, bem como erros em tuplas passadas não podem ser corrigidos.

c) Banco de Dados de Tempo de Validade: corresponde ao tempo que uma

informação é verdadeira no mundo real. A cada informação é associado o seu

tempo de validade, e este tempo deve ser fornecido pelo usuário. Este tipo de

banco de dados registra a história relativa aos dados e não às transações, e permite
 14

a correção de erros através da modificação de dados. Os bancos de dados de tempo

de validade admitem, no seu contexto, intervalos de tempo não válidos, e

permitem a recuperação de informações válidas em momentos passados, presente e

futuros.

d) Banco de Dados Bitemporais: o banco de dados combina as propriedades dos

bancos de dados de tempo de transação e de tempo de validade, ou seja, ele trata as

duas dimensões de tempo. Toda a história do banco de dados é armazenada; assim

é possível ter acesso a todos os estados passados do banco de dados, tanto a

história das transações realizadas como a história da validade dos dados. O estado

atual do banco de dados é constituído pelos valores atualmente válidos, e os

valores futuros podem ser definidos através do tempo de validade, sendo possível

recuperar o momento em que estes valores foram definidos para eventuais

alterações.

Este capítulo apresentou o aspecto tempo em Banco de Dados, sua importância,

suportes, dimensões, representações, classificações entre outros. No capítulo 3 serão

apresentadas algumas questões a respeito das linguagens de consulta temporal.

 15

3 LINGUAGEM DE CONSULTA TEMPORAL

Edelweiss (1997) afirma que quando um banco de dados temporal é utilizado, é

importante também que esteja disponível uma linguagem de consulta temporal. Esta

linguagem deve possibilitar a recuperação de todas as informações armazenadas no banco de

dados (temporais ou não), de modo que seja tirado real proveito do acréscimo da dimensão

temporal. Consultas temporais permitem:

a) Obter valores de propriedades cujo domínio é temporal. Exemplo: obter o valor da

propriedade que armazena a data de nascimento de uma pessoa;

b) Referir-se a um determinado instante ou intervalo temporal. Exemplo: qual o valor do

salário do João no dia 01/01/94;

c) Recuperar valores com base em restrições temporais. Exemplo: recuperar todos os

valores do salário do João antes do dia 01/01/94;

d) Fornecer informações temporais (datas, intervalos). Exemplo: qual a data em que foi

alterado o salário de um funcionário.

Para que isto seja possível, as linguagens de consultas convencionais devem ser

estendidas para manipular a dimensão temporal, e ter capacidade de dedução sobre tempo

com base nas informações temporais armazenadas. Isto é possibilitado através da utilização de

lógica temporal, a qual permite inferências de valores não explicitamente armazenados.

Carvalho (1997) cita cinco diferentes tipos de interpretações dos dados armazenados:

a) Dados Instantâneos atuais: representado por todas as informações válidas no momento

presente; Exemplo: Qual é o salário de João?

b) Dados Instantâneos Passados: representados pelos dados válidos em um determinado

instante do passado, de acordo com a atual percepção; Exemplo: Qual era o salário de

João em 01/01/01?
 16

c) Dados Instantâneos de história passada: considerando todas as informações de um

determinado momento do passado, de acordo com a história válida naquele momento;

Exemplo: Qual era o salário de João, considerando o que se acreditava como

verdadeiro em 20/05/01?

d) Dados Históricos: considera todas as informações armazenadas (presente, passado e

futuro) de acordo com a presente história de dados válidos; Exemplo: Qual será a

média salarial de João em 2010, considerando a evolução do mesmo desde sua

admissão?

e) Dados Históricos de história passada: análogo ao anterior porém considerando uma

história anterior à atual, definida por um determinado tempo de transação; Exemplo:

Qual era o salário de João em 01/01/01, considerando que se acreditava como

verdadeiro em 20/05/01?

É de extrema importância a abordagem de recuperação das informações temporais

através de extensões em consultas convencionais que manipulam a dimensão temporal. No

tópico seguinte será apresentada a TSQL2, que sugere especificações para uma linguagem de

consulta temporal baseando-se na especificação SQL-92.

3.1 TSQL2

Segundo TSQL2 Temporal Query Language (2007), a TSQL2 (Temporal Structured

Query Language 2) é uma extensão temporal do padrão da linguagem SQL-92. O comitê da

TSQL2 foi formado em julho de 1993 após um convite geral enviado à comunidade. Tal

comitê foi formado por pesquisadores da área que produziram uma especificação preliminar

da linguagem no decorrer de janeiro, a qual foi tornada pública à comunidade científica em

Março de 1994. Baseados em respostas destas especificações, mudanças foram efetuadas na

 17

linguagem, e a versão definitiva da especificação da linguagem TSQL2 foi publicada em

setembro de 1994.

A associação com a especificação da linguagem é uma coleção de comentários, a qual

discute decisões do projeto, fornece exemplos, e considera como a linguagem pode ser

implementada. Esses comentários foram propostos originalmente pelo comitê do projeto da

linguagem TSQL2, agora eles têm uma finalidade diferente: fornecer exemplos de

construções, motivar tomada de decisões durante o projeto da linguagem e comparar a TSQL2

com outras linguagens que têm sido propostas nos últimos 15 anos. Deve-se enfatizar que

esses comentários não fazem parte da especificação da linguagem TSQL2, mas suplementam

certamente uma elaboração acima disso. A especificação apropriada da linguagem é a palavra

final no TSQL2.

As construções e as introspecções da TSQL2 têm sido propostas para incorporação

dentro da linguagem SQL3. A linguagem TSQL2 foi a primeira a especificar um padrão para

uma linguagem de consulta temporal. Muitos pesquisadores da área de banco de dados

temporais contribuíram no desenvolvimento dessa linguagem, que é uma extensão da SQL. O

foco da TSQL2 é consolidar diferentes abordagens de modelos de dados temporais, com o

objetivo de criar uma linguagem de consulta temporal que, associada a um modelo de dados,

venha a ser um consenso entre os pesquisadores, para que futuros trabalhos possam ser

desenvolvidos, (CARVALHO, 2000).

Nas subseções seguintes, Simonetto (1998) faz considerações sobre alguns aspectos

relacionados a TSQL2.
 18

3.1.1 Tipos de dados suportados por TSQL2

Os tipos de dados datetime e interval do SQL-92 são substituídos com maior precisão

pelos tipos instants, intervals, e spans de tamanho e precisão especificáveis. Além disso, o

tipo de dado surrogate1 é utilizado no TSQL2.

3.1.2 Tipos de Tempo

O TSQL2 suporta três tipos de tempo: definido pelo usuário, válido e de transação. O

tempo de transação é limitado por inception, quando o banco de dados é criado, e until

changed, quando ocorre uma alteração na base de dados. Além disso, o tempo válido e o

tempo definido pelo usuário possuem dois valores especiais: beginning e forever (início e fim

da relação), que são o menor e o maior valor na ordem. O tempo de transação possui o valor

especial until changed.

3.1.2.1 Tabelas de Tempo Válido

Em cada tabela, cada tupla é rotulada temporalmente com um elemento temporal (ver

tabela 1), o qual é composto por todos os intervalos temporais.

Exemplo: a tabela empregados, com os atributos nome, salário e gerente, contendo a

seguinte tupla (Paulo, 10000, João). O elemento temporal rotulado neste registro será o

conjunto de intervalos que Paulo irá receber R$10.000, e terá João como seu gerente.

Informações sobre outros salários e outros gerentes de Paulo serão armazenadas em outras

1
Um surrogate representa um objeto no banco de dados por si só. O surrogate é inteiramente gerado
pelo sistema e invisível ao usuário ou aplicação.
 19

tuplas. O rótulo temporal é implicitamente associado com cada tupla. A linguagem TSQL2

permite ainda que tabelas do tipo evento sejam especificadas.

Tabela 1
Representação do tempo de validade na TSQL2
Id Nome Beggining Forever
1 João 01/01/96 -
2 Maria 01/01/94 31/12/96
2 Ana Maria 01/01/97 -
Fonte: Simonetto (1998)

3.1.2.2 Tabelas de Tempo de Transação

Ortogonalmente para tempo válido, o tempo de transação pode ser associado com

tabelas. O tempo de transação de uma tupla, a qual é um elemento temporal, especifica

quando a tupla foi considerada para ser logicamente armazenada no banco de dados. Se a

tupla (Paulo,10000,João) foi armazenada no banco de dados em 15 de Março de 1992 (com

uma sentença append) e removida deste banco de dados no dia 15 de Junho de 1992 (com

uma sentença delete), então o tempo de transação desta tupla é o intervalo compreendido entre

os dias 15 de Março de 1992 e 15 de Junho de 1992. O rótulo temporal de transação tem

tamanho e precisão dependentes de implementação e são determinados (ver tabela 2).

Tabela 2
Representação do tempo de transação na TSQL2
Id Nome Inception Until Changed
1 João 31/12/96 -
2 Maria 12/12/93 31/12/96
2 Ana Maria 30/12/96 -
Fonte: Simonetto (1998)

3.1.2.3 Tabelas Bitemporais

Neste caso ocorre a manutenção conjunta do tempo de transação e do tempo de

validade, mas não necessariamente ambos coincidem. Na tabela 3 é apresentada uma

 20

classificação bitemporal, onde as linhas de tempo válido e tempo de transação são

representadas em uma mesma tabela.

Tabela 3
Representação do tempo de transação e de validade (bitemporal) na TSQL2
Id Nome Beggining Forever Inception Until Changed
1 João 01/01/97 - 31/12/96 -
2 Maria 01/01/94 31/12/96 12/12/93 30/12/96
2 Ana Maria 01/01/97 - 30/12/96 -
(fonte: SIMONETTO, 1998)

3.1.3 Ordem no Tempo

Segundo Mello (2007) existem três tipos de ordem no tempo:

a) Ordem Linear: significa que o dado terá apenas um sucessor e um predecessor, sendo

esta a forma mais utilizada de ordenação temporal. Exemplo: evolução do salário de

um empregado.

b) Ordem Ramificada: onde um dado pode ter vários sucessores e/ou predecessores.

Exemplo: Alternativas de final de um filme (futuro ramificado).

c) Ordem Circular: é um conjunto de dados que se repete periodicamente em certa

ordem. Exemplo: período de promoção de natal de uma loja.

3.1.4 Granularidade

Mello (2007) cita dois aspectos a considerar em modelagens:

a) Granularidade Temporal (discretização): duração do período do tempo (chronon) que

pode variar de dado para dado. Ex: ano, mês, dia, hora...

b) Granularidade do fato do mundo real: para qual porção do fato deve-se registrar

evolução temporal. Ex: fato completo, alguns atributos, alguns dos seus

relacionamentos,...
 21

3.1.5 Rótulos Temporais

Edelweiss (1997) cita alguns operadores de seleção, pois na linguagem TSQL2 a

seleção e a projeção são feitas sobre o rótulo temporal, envolvendo, portanto, tempo de

transação e de validade.

O primeiro tipo de operador citado refere-se aos extratores que tem por objetivo

extrair alguma informação temporal do rótulo, como o operador begin que extrai o início de

validade de um atributo. Há também operadores construtores, como por exemplo, o intersect,

que retorna o conjunto de intervalos temporais resultante da interseção de dois intervalos

considerados. Já os operadores de comparação são operadores lógicos que comparam

intervalos temporais. Neste contexto encontramos o overlaps que verifica se dois intervalos

têm intervalos temporais em comum. Assim, um exemplo de consulta para obter estas

informações poderia ser expressa da seguinte forma:

Exemplo: "Listar o nome dos funcionários que estiveram empregados em janeiro de

1992"

SELECT Name
FROM Employee
WHERE VALID(Employee)
OVERLAPS PERIOD '[01/01/1992,01/31/1992]'

Mello (2007) cita mais alguns operadores como o Includes (Contém), Preceds/before

(precede no tempo), Follows/after (sucede no tempo) e Meets (casa, encontro no tempo).

 22

3.1.6 Sintaxe

Baseado em Mello (2007) e Snodgrass (1994) as subseções seguintes mostram como

criar estruturas de banco de dados temporais que armazenam os dados. Inicialmente será

apresentada a sintaxe TSQL2 para criação das tabelas, inclusão de dados, alteração e exclusão

dos mesmos. Por fim, como é apresentada a sintaxe para recuperação de informações

armazenadas através de consultas.

3.1.6.1 Definição de Tabelas

Para criar uma tabela utiliza-se o mesmo formato de comando usado nos bancos de

dados convencionais, o create table. Neste comando são especificados o nome da nova tabela,

os nomes das colunas, e o tipo de dado de cada coluna. No caso de banco de dados temporais,

as tabelas necessitam ter meios de tratar a questão temporal. No exemplo abaixo, que grava os

custos de comerciais, as sentenças diferem da SQL-92 na cláusula as valid. Essa construção

identifica a tabela NBCShows como uma tabela de estado de tempo válido. Tais tabelas

contêm registros de datas e horas válidos, as quais são indicadas por períodos e suportadas por

suas durações de tempo. Second e years são granularidades.

Exemplo:

CREATE TABLE NBShows

(ShowName CHARACTER (30) NOT NULL,
InsertionLenght INTERVAL SECOND,
Cost INTEGER)
AS VALID STATE YEARS (2) TO NBCSeason

Onde:
ShowName é o nome do programa exibido na NBC (NBC é uma rede de televisão);
InsertionLenght é a duração do comercial;
Cost é o preço em dólares pago pela propaganda;
 23

3.1.6.2 Inclusão de Dados

Assim como o comando de criação de tabelas, a inclusão dos dados se assemelha ao

comando do padrão da SQL-92, mas com a adição de cláusula que trata a dimensão do tempo

associada ao registro que está sendo inserido. O exemplo abaixo mostra uma inserção de

valores na tabela NBShows, onde o valor de InsertionLenght é de 30 segundos.

INSERT INTO NBShows

VALUES (‘Roaseane’, INTERVAL ‘30’ SECOND, 251000)
VALID TIMESTAMP ‘Spring Season 1994’;

3.1.6.3 Exclusão de Dados

O comando padrão da SQL-92 para exclusão dos dados efetua a remoção física dos

mesmos. Quando a questão de dimensão do tempo é associada ao registro que está sendo

excluído, pode-se verificar que esta exclusão não irá remover fisicamente este dado,

significando apenas o fim da sua validade. No exemplo abaixo a cláusula valid é utilizada

visando o fim da validade de dados históricos que se encontram dentro do período ou casam

com o instante de tempo declarado.

Ex:
DELETE FROM nome_tabela
[WHERE condição]
[VALID {PERIOD | INSTANT} constante_tempo]

Exemplo de fim de validade de dados correntes:

DELETE FROM Departamentos WHERE nome = ‘marketing’

Quando a história de um dado não é mais relevante para uma aplicação e deseja-se

diminuir o volume de dados, pode-se executar a exclusão física do dado através do comando

vaccuming. Logo abaixo á apresentado um exemplo de exclusão física a partir deste comando:
 24

Ex:

VACCUM Empregados E
WHERE BEGIN (TRANSACTION(E))
PROCEDS DATE ’01-01-90’

3.1.6.4 Atualização de Dados

O comando update utilizado para atualizar dados, também se assemelha muito ao

comando do padrão da SQL-92, com a adição da cláusula valid utilizada para as modificações

da validade do tempo. Abaixo pode-se ver um exemplo.

Ex:

UPDATE nome_tabela
SET alterações
[VALID {PERIOD | INSTANT} constante_tempo]
[WHERE condição]

3.1.6.5 Consultas

Conforme abordado no início deste capítulo, a consulta é imprescindível no aspecto de

banco de dados temporais, sendo que esta deve possibilitar que todas as informações

armazenadas no banco de dados (temporais ou não) sejam recuperadas de modo que seja

tirado real proveito do acréscimo da dimensão temporal. Vários tipos de consultas podem ser

executadas como será apresentado nos exemplos a seguir:

Exemplo 1: Consultas Convencionais sobre dados correntes, válidos no presente

SELECT * ß exibe atributos temporais por default

FROM empregados
 25

SELECT SNAPSHOT RG, nome ß snapshot2

FROM empregados
WHERE salário >= 2000.00

Exemplo 2: Busca de Atributos Temporais

SELECT INSTANT(P)
FROM ParticipaçõesEventos P
WHERE P.RG = 10100

SELECT SNAPSHOT E.salario, BEGIN(PERIOD(E))

FROM Empregados E
WHERE E.nome = ‘Joao da Silva’

Exemplo 3: Nome de empregados que trabalham na empresa no ano de 2001, utilizando

predicados temporais: includes (contém), overlaps (sobrepõe (intersecção)), preceds/before

(precede no tempo), follows/after (sucede no tempo), meets (“casa” encontro no tempo).

SELECT SNAPSHOT E.nome

FROM Empregados E
WHERE VALID(E) OVERLAPS PERIOD ‘[01-01-2001 – 12-31-2001]’

Exemplo 4: qual era o salário de João da Silva que se acreditava como válido em 20/05/95?

Retorno a Histórias passadas – consultas evolvendo tempo de transação.

SELECT SNAPSHOT salário

FROM Empregados E
WHERE E.nome = ‘João da Silva’
AND TRANSACTION(E) OVERLAPS DATR ’05-20-95’
AND VALID(E) OVERLAPS DATE ’05-20-95

2
Exibe o estado mais atual dos dados, não exibindo nenhum atributo temporal
 26

Este capítulo apresentou uma abordagem referente à linguagens de Consultas

Temporais, mais especificamente a TSQL2, suas especificações, tipos de dados, tipos de

tempos, ordens, granularidades, rótulos temporais e suas sintaxes.

Segundo Silberschatz (2006) muitas propostas foram feitas para a extensão da SQL a

fim de melhorar seu suporte de dados temporais, porém até a última versão do padrão ISO

(2003), nenhum suporte adicional havia sido acrescentado. Nem mesmo a TSQL2 foi aceita

pelo comitê de padronização devido a divergências existentes entre os participantes.

No capítulo 4 será apresentada a metodologia científica utilizada neste trabalho.

 27

4 METODOLOGIA

A metodologia descreve os procedimentos e regras utilizadas por um determinado

método, sendo também definida como a descrição, análise e avaliação dos métodos a serem

investigados. Segundo Richardson (1999), a pesquisa científica define a escolha dos

procedimentos para a descrição e explicação do problema.

Conforme Gil (1999): “Pesquisa é um procedimento racional e sistemático que tem

como objetivo proporcionar respostas aos problemas que são propostos”. Assim, a elaboração

de uma pesquisa é feita mediante a consideração das etapas necessárias ao seu

desenvolvimento. Estas etapas podem ser simplificadas ou modificadas para melhor que se

adaptem à situação da organização, onde o trabalho de pesquisa está sendo desenvolvido.

Esta pesquisa, do ponto de vista de sua natureza, é aplicada, pois, segundo Silva e

Menezes (2005) “objetiva gerar conhecimentos para aplicação prática, dirigidos à solução de

problemas específicos, ou seja, é uma pesquisa aplicada quantitativa que tem como objetivo

gerar conhecimentos para aplicação prática dirigida à solução de problemas específicos com o

uso de recursos e técnicas quantitativas, que no caso é de demonstrar a aplicabilidade dos

conceitos de bancos de dados temporais em sistemas gerenciadores de bancos de dados

convencionais, visando sua utilização em sistemas de informação.

Do ponto de vista de seus objetivos, este estudo pode ser considerado como pesquisa

exploratória, pois de acordo com Gil (2002), a exploratória envolve levantamento

bibliográfico com base em materiais como livros, artigos de períodicos, base de dados,

internet e outros disponíveis o qual já foi citado, assumindo geralmente as formas de

pesquisas bibliográficas e estudos de caso.

Quanto aos procedimentos técnicos o presente trabalho de pesquisa utilizou o estudo

de caso, procedimento justificável pelo caráter exploratório, e quantitativo da pesquisa, que

 28

no caso em estudo é a modelagem de dados para um controle de grãos, para o qual foi

utilizado no sentido de demonstrar a aplicabilidade da solução proposta (TRIPODI et al,.

1975).

De acordo com Yin (2001), a opção de estudo de caso como estratégia de pesquisa se

justifica quando o estudo focaliza o âmbito das decisões, isto é, tentam esclarecer o motivo

pelo qual as decisões foram tomadas, como foram implementadas e quais os resultados

encontrados.

No capítulo 5 será apresentado o método de escolha do sistema gerenciador de banco

de dados para prototipação, juntamente com as características e funcionalidades do banco

efetivamente escolhido.
 29

5 SELEÇÃO DE UM SGBD PARA PROTOTIPAÇÃO

Após algumas pesquisas com os bancos MySQL, Firebird, PostgreSQL entre outros, o

SGBD (sistema gerenciador de banco de dados) escolhido para o desenvolvimento deste

estudo foi o PostgreSQL. Nesse capítulo será apresentado um breve histórico acerca deste

banco de dados, suas características e funcionalidades, de forma a justificar esta escolha.

Segundo Alecrin (2008) o sistema gerenciador de banco de dados PostgreSQL teve

seu início na Universidade de Berkeley, na Califórnia, em 1986. Na época, um programador

chamado Michael Stonebraker liderou um projeto para a criação de um servidor de banco de

dados relacionais chamado Postgres, oriundo de um outro projeto da mesma instituição

denominado Ingres. Essa tecnologia foi então comprada pela Illustra, que compatibilizou o

Postgres à linguagem SQL. Este projeto recebeu o nome de Postgres95, e em 1996, quando o

projeto estava estável, o banco de dados recebeu o nome de PostgreSQL.

Cruz (2008) comenta que o PostgreSQL é um SGBD objeto-relacional por

implementar, além das características de um SGBD relacional, algumas características de

orientação a objetos, como herança e tipos personalizados. É extremamente robusto,

confiável, flexível e rico em recursos. Além disso, trata-se de um banco de dados gratuito e de

código fonte aberto.

Entre suas características, tem-se:

a) Compatibilidade multi-plataforma: executa em vários sistema operacionais, como

Windows, Mac OS X, Linux e outras variantes de Unix;

b) Compatibilidade com várias linguagens: Java, PHP, Python, Ruby, e C/C++;

c) Base de dados de tamanho ilimitado;

 30

d) Suporte a SQL: O PostgreSQL oferece suporte a SQL/ANSI e todos os seus

recursos como o argumento EXISTS e outros argumentos utilizados na elaboração

de sub-consultas;

e) Funções armazenadas (Stored Procedures): bloco de comandos nomeados,

armazenados e que podem ser parametrizados e reutilizados, podendo ser escritos

em várias linguagens de programação (PL/PgSQL, PL/Perl, Python, Ruby, e

outras), linguagens estas que são carregadas como módulos dinâmicos;

f) Gatilhos (Triggers): O gatilho pode ser definido para executar antes ou depois de

uma operação de insert, update ou delete. Quando ocorre o evento do gatilho, a

função de gatilho é chamada e uma sequência de comandos é executada.

g) Tipos definidos pelo usuário: o PostgreSQL pode ser estendido para dar suporte a

novos tipos de dados. A criação de um novo tipo base requer a implementação de

funções para operar o tipo em uma linguagem de baixo nível, geralmente a

linguagem C;

h) Operadores definidos pelo usuário: Todo operador é uma "suavização sintática"

para a chamada a uma função subjacente que realiza o trabalho real; portanto,

primeiro deve ser criada a função subjacente para depois ser criado o operador;

i) Views: as views consistem em um tipo de tabela virtual formada por campos

extraídos de uma tabela “verdadeira”, facilitando o controle sob os dados

acessados.

Este capítulo apresentou um breve histórico, características e funcionalidades

do banco de dados PostgreSQL. A escolha desse sistema deve-se ao conjunto de

características gerais apresentadas anteriormente, mas principalmente devido ao suporte à

incorporação de linguagens para definição de Stored Procedures.

 31

No capítulo 6 será apresentada a implementação da dimensão temporal sob o banco de

dados convencional, a definição das linguagens, tabelas, armazenamento e consulta de dados.

 32

6 IMPLEMENTAÇÃO DA DIMENSÃO TEMPORAL SOB O BANCO DE DADOS

CONVENCIONAL

Este trabalho está inserido no âmbito de banco de dados de tempo de transação, no que

se refere ao aspecto tempo, onde o tempo de definição de um dado por uma transação é

fornecido pelo SGBD. Dessa forma, a ordem no tempo utilizada foi a Ordem Linear, onde o

dado possui apenas um sucessor e um predecessor, utilizando como rótulo temporal o tipo de

dados Timestamp3.

6.1 DEFINIÇÃO DAS LINGUAGENS

Para que a criação de triggers apresentassem a funcionalidade esperada, foram

utilizadas duas linguagens, a PL/Pgsql e a PL/Perl. A linguagem PL/Perl foi utilizada para

definição de flags ou sinalizadores de ocorrência em determinada situação, que serão

detalhadas posteriormente. A linguagem PL/Pgsql foi utilizada para fazer as manipulações

necessárias com os dados para adicionar a eles o aspecto temporal. Abaixo será visualizada a

sintaxe para carregar esses módulos de linguagens.

CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql'

HANDLER plpgsql_call_handler
VALIDATOR plpgsql_validator;

CREATE TRUSTED PROCEDURAL LANGUAGE 'plperl'

HANDLER plperl_call_handler
VALIDATOR plperl_validator;

3
Timestamp: tipo de dado que combina data (dia/mês/ano) + tempo (hh:mm:ss:ms);
 33

6.2 DEFINIÇÃO DE TABELAS

Conforme descrito no item sintaxe do capítulo 2, para criar uma tabela utiliza-se o

mesmo formato de comando usado nos bancos de dados convencionais, o create table e as

especificações correspondentes à nova tabela (nome da tabela, nomes das colunas e tipo de

dado das colunas).

Exemplo:

CREATE TABLE "pessoas"(

"codigo" integer NOT NULL,
"nome" character(100),
"endereco" character(100),
"cidade" character(100),
"profissao" character(100),

CONSTRAINT "pessoas_pkey" PRIMARY KEY ("codigo"))

6.3 ADIÇÃO DA DIMENSÃO TEMPORAL

De forma a associar o tempo de transação aos registros armazenados deve-se adicionar

duas colunas (Tinicial e Tfinal) à estrutura das tabelas nas quais deseja-se manter a história de

seus estados, ambas com o tipo de dado Timestamp.

Para que o controle por tempo de transação possa ser efetivo é necessário alterarmos a

chave primária dessa tabela, para que ela passe a ser uma chave primária composta (codigo,

tinicial). A razão pela escolha da coluna tinicial para compor a chave deve-se ao fato de que

ao inserirmos um registro, a coluna tfinal terá um valor nulo inicialmente, e chaves não

podem conter valores nulos. Abaixo se pode visualizar um exemplo da alteração da tabela:

AddTIni - (ALTER TABLE "pessoas" ADD COLUMN "tinicial" timestamp NOT NULL;)
AddTFim- (ALTER TABLE "pessoas" ADD COLUMN "tfinal" timestamp;)

Del# - (ALTER TABLE "pessoas" DROP CONSTRAINT "pessoas_pkey";)

Add# -(ALTER TABLE "pessoas" ADD PRIMARY KEY ("codigo", "tinicial");)
 34

Onde:
AddTIni : Adição da coluna tinicial, ou seja, data inicial da validade do registro;
AddTFim: Adição da coluna tfinal, ou seja, data final da validade do registro;
Del#: Exclui-se a chave simples;
Add#: Adiciona-se a nova chave agora composta;

Após a adição das colunas que irão tratar a questão temporal, a tabela ficará como
demonstrada no Quadro1.

# codigo nome endereco cidade profissao # tinicial tfinal

01/03/03 09/07/07
1 Marilia Bencio M. Borges, 384 Vacaria Estudante 19:40:45 08:00:00
09/07/07
1 Marilia Bencio M. Borges, 384 Vacaria Programadora 08:00:00
15/12/98 01/05/08
2 Everton Costa e Silva, 675 Vacaria Insp.Qualidade 19:56:08 13:59:45

Rótulo Temporal
Quadro 1: Visualização da Tabela

6.4 GERENCIAMENTO DO ARMAZENAMENTO DOS DADOS TEMPORAIS

Para que o gerenciamento da questão temporal fosse possível foi necessário utilizar

variáveis globais e a criação de funções utilizando a linguagem PL/Perl. Portanto, foi

necessária a utilização de duas linguagens e uma interação entre as mesmas, pois a linguagem

PL/PgSql não permite a criação de variáveis globais, recurso este presente na linguagem

PL/Perl..

Abaixo podemos ver como foram criadas as função getvar e setvar na linguagem

PL/Perl para armazenar e setar as variáveis globais que posteriormente serão utilizadas:

CREATE OR REPLACE FUNCTION setvar(nome text, valor boolean) RETURNS void AS

$setvar$
$_SHARED{$_[0]} = $_[1];
$setvar$ LANGUAGE plperl;

CREATE OR REPLACE FUNCTION getvar(nome text) RETURNS boolean AS $getvar$

return $_SHARED{$_[0]};
$getvar$ LANGUAGE plperl;
 35

A seguir, será demonstrada a criação de funções que gerenciam os rótulos de tempo

dos dados inseridos, atualizados e excluídos do banco de dados.

6.4.1 Inserção de Dados

Para gerenciar os rótulos de tempo dos dados inseridos de forma automática, tornou-se

necessária a definição de uma trigger que intercede aos eventos de inserção para todas as

tabelas acrescidas da dimensão temporal, definindo o tempo inicial de transação para os dados

inseridos. Esta forma de implementação permite que o banco de dados seja manipulado de

forma convencional sem que usuários ou sistemas tenham de ser adaptados às questões

temporais.

Abaixo, é apresentado um exemplo da função que rotula temporalmente os dados

inseridos. Inicialmente o usuário efetua a solicitação de inserção, onde verifica-se a origem do

registro (insert ou delete), a qual é verificada através de consulta a variável ‘deletar’ da

função setvar descrita na seção 5.4. Se o registro é realmente originário de um insert, a função

passa o valor data e tempo atual para a validade inicial do registro. Caso o registro seja

originário de um delete a validade inicial não será atribuída ao registro. No final da função a

variável global é atualizada sempre. Tal rotina é representada no diagrama de atividades da

Figura 1.

Exemplo:
CREATE OR REPLACE FUNCTION inserepessoas() RETURNS trigger AS
$inserepessoas$
BEGIN
if (select getvar('deletar') = true) then
return NEW;
else
NEW.tinicial := current_timestamp;
end if;
EXECUTE setvar('deletar',false);
return NEW;
END;
$inserepessoas$ LANGUAGE plpgsql;
 36

CREATE TRIGGER inserepessoas BEFORE INSERT ON pessoas

FOR EACH ROW EXECUTE PROCEDURE inserepessoas()

[Inicio]

INSERT Comando solicitado pelo usuário

[if operação = deletar]

Efetua a inserção
GET VAR exatamente como foi
solicitada

[else]

Efetua a inserção e
atribui um valor para
tempo inicial

Seta valor false à

variável 'deletar'

[Fim]

Figura 1: Diagrama de Atividades da Inserção de Dados

 37

6.4.2 Alteração de Dados

Para gerenciar os rótulos de tempo dos dados alterados de forma automática, tornou-se

necessária a definição de uma trigger que intercede aos eventos de alteração para todas as

tabelas acrescidas da dimensão temporal.

Abaixo, é apresentado um exemplo da função que rotula temporalmente os dados

alterados, inserindo um novo registro com informações alteradas e tempo inicial de transação

para este, juntamente com uma validade de tempo final para o registro anterior. Tal rotina é

representada no diagrama de atividades da Figura 2.

Exemplo:
CREATE OR REPLACE FUNCTION alterapessoas() RETURNS trigger AS
$alterapessoas$
BEGIN
INSERT INTO pessoas VALUES (NEW.codigo, NEW.nome, NEW.endereco,
NEW.cidade,NEW.profissao, default, default);

NEW.nome := OLD.nome;
NEW.endereco := OLD.endereco;
NEW.cidade := OLD.cidade;
NEW.profissao := OLD.profissao;
NEW.tfinal := current_timestamp;

RETURN NEW;
END;
$alterapessoas$ LANGUAGE plpgsql;

CREATE TRIGGER alterapessoas BEFORE UPDATE ON "pessoas"

FOR EACH ROW EXECUTE PROCEDURE alterapessoas()
 38

[Inicio]

UPDATE Comando solicitado pelo usuário

[Este comando fará com que o gatilho de inserção

seja disparado e então, o tempo inicial inserido ]
Insert - Valores [In icio ]

com alterações
INSERT Comando solicit ado pelo usuário

[if op eração = deletar]

Efetu a a ins erção
GET VAR exatamen te como fo i
s olicit ad a

[e ls e]

Mantêm valores que já existiam

antes da alteração e coloca Efetua a in s erçã o e
atrib ui um valor p ara
uma validade final ao registro t empo inicial

Seta valor fa ls e à
variável 'delet ar'

[Fim] [Fim]

Figura 2: Diagrama de Atividades da Alteração de Dados

6.4.3 Delete

Para gerenciar os rótulos de tempo dos dados excluídos de forma automática, tornou-

se necessária a definição de uma trigger que intercede aos eventos de exclusão para todas as

tabelas acrescidas da dimensão temporal, definindo o tempo final de transação para os dados

excluídos.

Abaixo é apresentado um exemplo da função que rotula temporalmente os dados

excluídos, onde o registro é efetivamente excluído da base de dados, mas logo após é inserido

novamente com os mesmos valores e um tempo de validade final. No momento desta

inserção, a variável ‘deletar’ possuirá valor verdadeiro (‘deletar’=true), demonstrando assim

que este é um registro originário de um delete, e então a validade inicial deverá ser

preservada, caso contrário a função terá a informação de que realmente se trata de uma
 39

operação originária de inserção e rotulará o tempo inicial normalmente. Tal rotina é

representada no diagrama de atividades da Figura 3.

Exemplo:

CREATE OR REPLACE FUNCTION deletepessoas()RETURNS "trigger" AS

$deletepessoas$
BEGIN
EXECUTE setvar('deletar',true);
INSERT INTO pessoas VALUES (OLD.codigo, OLD.nome, OLD.endereco,
OLD.cidade,OLD.profissao, OLD.tinicial, current_timestamp);

RETURN OLD;

END;
$deletepessoas$ LANGUAGE 'plpgsql';

CREATE TRIGGER deletepessoas AFTER DELETE ON "pessoas"

FOR EACH ROW EXECUTE PROCEDURE deletepessoas()

DELETAR Comando solicitado pelo usuário

[Registro é inserido novamente com os dados

excluídos e com um tempo de validade final]
[Inicio ]

Registro é excluído pelo

Banco de Dados INSERT Comando solicit ado pelo usuário

[if operação = deletar]

Efetua a inserção
GET VAR exatamente como foi
solicitada

Seta valor true a

[e lse]
variavel 'deletar'

Efetua a inserçã o e
atribui um valor para
tempo inicial

Insert - Valores Seta valor fa lse à

variável 'deletar'
excluídos

[Fim]

[Fim]

Figura 3: Diagrama de Atividades da Exclusão de Dados

 40

Este capítulo apresentou questões referentes à implementação da dimensão temporal

sob o banco de dados convencional (PostgreSQL), a definição das linguagens, tabelas,

armazenamento e consulta de dados.

As linguagens utilizadas foram a PL/Pgsql e a PL/Perl. Na definição de tabelas foram

utilizados os mesmos formatos de comandos dos bancos de dados convencionais, porém duas

colunas (tinicial e tfinal) foram adicionadas às tabelas com características temporais, sendo a

tinicial parte da chave primária. No que se refere a inserção, alterações e exclusão de dados,

gatilhos e funções foram criadas para o gerenciamento da questão temporal.

O próximo capítulo irá apresentar uma interface para gerência de banco de dados

convencionais acrescidos de dimensão temporal, o pgTemporal, suas características,

funcionalidades e um exemplo de aplicabilidade.

 41

7 pgTemporal, UMA INTERFACE PARA GERÊNCIA DE BANCO DE DADOS

CONVENCIONAIS ACRESCIDOS DE DIMENSÃO TEMPORAL

De forma a simplificar a utilização do banco de dados convencional com o acréscimo

de um suporte à dimensão temporal, foi desenvolvida uma interface chamada pgTemporal,

que torna mais fácil a consulta de Snapshot, consultas temporais e a manipulação do Banco de

Dados. Nos tópicos seguintes será apresentada a interface pgTemporal, sua funcionalidade,

características, e um exemplo de aplicabilidade da mesma, através da modelagem do banco de

dados e consultas (Snapshot e temporais).

7.1 SNAPSHOT

Ao executar a ferramenta, uma lista de tabelas será apresentada a esquerda da tela, e a

direita um grid sem dados. Essa lista é resultado de um SQL, que busca automaticamente

todas as tabelas da base de dados conectada a ferramenta. No momento em que o usuário

seleciona uma tabela, todos os campos referentes a ela aparecem numa listagem logo abaixo,

omitindo as colunas que contém os rótulos temporais. A interface dispõe também de uma área

de visualização que permite observar os dados armazenados no banco de dados. Caso a aba

selecionada seja a Snapshot, os dados apresentados serão os atuais da tabela, através de views.

Um exemplo pode ser visualizado abaixo, na figura 4.

 42

Figura 4: Snapshot

7.2 CONSULTAS TEMPORAIS

A interface permite a execução de consultas, e tal funcionalidade é disponibilizada na

segunda aba da interface, chamada Consultas Temporais, que pode ser visualizada na Figura

5. Esta disponibiliza uma área para que o usuário possa digitar a consulta SQL desejada, um

botão para que essa consulta possa ser executada e logo abaixo uma área de visualização que

permite observar os dados solicitados.

A interface fornece suporte parcial à TSQL2, através de dois operadores, instant e

period. O instant é utilizado para a visualização dos dados válidos em uma data específica e o

operador period permite a visualização dos dados válidos em um período específico. A

sintaxe destes operadores é visível ao usuário através de um help disponibilizado a esquerda

 43

inferior da tela, sendo as seguintes: INSTANT [mm/dd/aaaa] e PERIOD

[mm/dd/aaaa,mm/dd/aaaa].

Figura 5: Consultas Temporais

7.3 MANIPULAÇÃO DE DADOS

A manipulação dos dados também é disponibilizada e pode ser efetuada acessando a

terceira aba da interface, chamada Manipulação de Dados. Esta disponibiliza uma área para

que o usuário possa digitar a instrução SQL desejada e um botão para execução da mesma.

Um exemplo pode ser visualizado na figura 6.

A interface fornece suporte às instruções insert/update/delete com a mesma sintaxe

utilizada pela linguagem padrão SQL.

 44

Figura 6: Manipulação de Dados

7.4 ESTUDO DE CASO

A modelagem de dados escolhida é referente a um controle de grãos, a qual não

reproduz uma modelagem completa que normalmente seria utilizada num sistema deste porte,

mas parte dela. Assim, alguns relacionamentos de chave estrangeira não foram levados em

consideração, com o objetivo de tornar mais claro o exemplo, e visto que isso não seria

necessário para a demonstração da funcionalidade da interface. Tal modelagem pode ser

visualizada na figura 7 através do modelo E-R

 45

lavoura
codigo I <M>
cultura LA20
lavoura_produtor areaplantio LA20 lavoura_silo
tinicial TS
tfinal TS <M>

produtor
silo
codigo I <M> entrada
nome LA40 codigo I <M>
endereco LA40 entrada_produtor numero I <M> entrada_silo capacidade DC
cidade LA20 dataentrada D estoque DC
telefone LA20 peso DC tinicial TS <M>
profissao LA20 tfinal TS

saida
numero I <M>
datasaida D
saida_produtor peso DC saida_silo

Figura 7: Modelo E-R

Abaixo podem ser visualizadas algumas situações onde as Consultas Temporais são

importantes:

ü Controle de Estoque: Qual era o estoque do silo cujo o código é igual a 1 na data de

17/06/2009?

SELECT * FROM silo WHERE codigo = 1

AND INSTANT [06/07/2008]

ü Controle de Estoque: Quais foram os estoques do silo cujo código é igual a 1 na

período de 01/06/2008 a 18/06/2008?

SELECT * FROM silo WHERE codigo = 1

AND PERIOD [06/01/2008,06/18/2008]
 46

ü Obter produtividade do Produtor. Ex: Quanto foi comprado de cada produtor na data

de 14/06/2008

SELECT SUM(peso), nome

FROM entradagrao, produtor
WHERE codigo = produtor
AND INSTANT [06/14/2008]
GROUP BY nome
 47

CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS

A constatação de que os dados evoluem com o passar do tempo e que todos

estes valores não devem ser perdidos, levou a criação dos bancos de dados temporais, onde

todos os estados (passado, presente e futuro) dos dados ficam armazenados, e com a

possibilidade de estes serem recuperados. Partindo deste pressuposto, este trabalho apresentou

primeiramente um embasamento teórico acerca do estado da arte em banco de dados

temporais.

Primeiramente, foram estudados alguns conceitos do aspecto tempo em banco de

dados, onde as informações temporais têm sua representação em banco de dados, e as

associações entre essas informações e os dados ocorrem através do acréscimo de uma

dimensão temporal ao banco de dados. Através desta dimensão podemos identificar quando

uma informação foi definida e qual o tempo em que ela é válida, de forma que se o valor do

atributo for alterado, o valor anterior não é perdido.

No que se refere à linguagem de consulta temporal, verificou-se que para uma

adequada recuperação de dados temporais, é necessária a utilização de uma linguagem de

consulta que ofereça suporte à critérios de seleção temporal. Nesse sentido, muitas propostas

foram feitas para à extensão da linguagem SQL, porém até a última versão do padrão para a

linguagem de consulta aprovado por ISO/ANSI (ANSI,1999) e ISO (2003), nenhum suporte

adicional havia sido acrescentado.

Dentre as propostas apresentadas aos comitês, destaca-se a TSQL2 (Temporal

Structured Query Language 2) que sugere especificações para uma linguagem de consulta

temporal baseando-se na especificação SQL-92. Os aspectos tipos de dados suportados por

TSQL2, tipos de tempo, ordem no tempo e sintaxe também foram abordados e exemplificados

neste trabalho.
 48

Partindo dos pressupostos já descritos, a dimensão temporal foi implementada sob o

banco de dados convencional, onde o banco de dados escolhido foi o PostgreSQL, devido

principalmente ao suporte à incorporação de linguagens para definição de Stored Procedures.

Após a escolha do banco de dados, foram definidas as duas linguagens que seriam utilizadas,

a forma de tratamento da temporalidade com relação às tabelas através da adição de duas

colunas, e posteriormente o gerenciamento do armazenamento dos dados através de gatilhos e

funções.

De forma a simplificar a utilização do banco de dados convencional com o acréscimo

de um suporte à dimensão temporal, foi desenvolvido uma interface chamada pgTemporal,

que torna mais fácil a consulta de Snapshot, consultas temporais e a manipulação do Banco de

Dados.

Como trabalhos futuros, sugere-se uma ampliação do suporte à linguagem TSQL, com

adição de mais operadores, ampliando também a funcionalidade da interface já desenvolvida

com a adição de um módulo que faça a inserção automática dos gatilhos/funções, colunas nas

tabelas, etc; o que acrescentaria temporalidade na tabela solicitada pelo usuário. Também

seria interessante uma ampliação do estudo com implementação em outros SGBDs.

 49

REFERÊNCIAS BIBLIOGRÁFICAS

ALECRIN, Emerson; Banco de dados MySQL e PostgreSQL. Disponível em:

http://www.infowester.com/postgremysql.php Acessado em: 11/05/2008 às 18:00hs

ANSI/ISO/IEC International Standard (IS). Database Language SQL—Part 2: Foundation

(SQL/Foundation). 1999. Disponível em: http://www.cse.iitb.ac.in/dbms/Data/Papers-

Other/SQL1999/ansi-iso-9075-2-1999.pdf. Acessado em 19/11/2007 às 20:33hs

CARVALHO, Henry Gomes de; HEUSER, Carlos Alberto; EDELWEISS, Nina. Linguagem

de Consulta Temporal: Definição e Implementação. Disponível em:

http://www.inf.ufrgs.br/pos/ SemanaAcademica/Semana2000/HenryCarvalho/. Acessado em

11/09/2007 às 17:00hs.

CARVALHO, Tanisi Pereira de; Implementação de Consultas para um modelo de dados

temporal orientado a objetos. Porto Alegre: UFRGS, 1997.

CRUZ, Walter; PostgreSQLBR: Introdução e histórico. Disponível em:

http://www.postgresql.org.br/Introdu%C3%A7%C3%A3o_e_hist%C3%B3rico. Acessado em

10/05/2008 às 21:22hs

EDELWEISS, Nina; et al. A Temporal Database Management System Implemented on Top of

a Conventional Database. Porto Alegre: UFRGS, 2000.

 50

EDELWEISS, Nina. Bancos de Dados Temporais: Teoria e Prática. Recife, 1998. In: XVII

Jornada de Atualização em Informática, do XVIII Congresso Nacional da Sociedade

Brasileira de Computação, v.2 Ed: H.P.MOURA. Anais. P.255-282

EDELWEISS, Nina. Bancos de Dados Temporais: Teoria e Prática. Porto Alegre: UFRGS,

1997.

FURASTÉ, Pedro Augusto. Normas Técnicas para o Trabalho Científico: Elaboração e

Formatação. Explicitação das Normas da ABNT. – 14. Ed. – Porto Alegre: s.n, 2006.

GIL, A.C. Como elaborar projetos de pesquisa. São Paulo: Atlas. 4ª Ed. 2002.

GIL, Antonio C. Métodos e técnicas de pesquisa social. 5ª ed. São Paulo: Atlas, 1999.

ISO/IEC 9075-11:2003: Information and Definition Schemas (SQL/Schemata), 2003.

MELLO, Ronaldo dos Santos; Material de aula da disciplina de Bancos de Dados Não-

Convencionais. Florianópolis: UFSC, 2007. Disponível em: http://www.inf.ufsc.br/~ronaldo/

bdnc/6-bdt.pdf e http://www.inf.ufsc.br/~ronaldo/bdnc/7-bdt.pdf. Acessado em: 22/10/2007

às 10:13 hs.

PINHEIRO, Sandro Favin; FORNARI, Miguel Rodrigues. Implementação de um Modelo

conceitual Temporal e Espacial Utilizando o SGBD Oracle. Porto Alegre: ULBRA, 2002
 51

POSTGRESQL; Sítio da comunidade PostgreSQL brasileira. Brasil, 2007. Disponível em:

http://www.postgresql.org.br/. Acessado em: 06/11/2007 às 22:26hs

RICHARDSON, Roberto Jarry. Pesquisa Social: Métodos e Técnicas. 3. ed. São Paulo: Atlas,
1999.

SILBERSCHATZ, Abraham. Sistema de Banco de Dados. Rio de Janeiro: Elsevier, 2006. 5º

edição. P 609-611

SILVA, E. L. da; MENEZES, E. M. Metodologia da pesquisa e elaboração de dissertação. 4.

ed. Florianópolis: UFSC, 2005. 138 p. Disponível em:

www.posarq.ufsc.br/download/metPesq.pdf>. Acesso em: 04 Junho. 2008.

SIMONETTO, Eugênio de Oliveira; Uma proposta para a incorporação de aspectos

temporais, no projeto lógico de bancos de dados, em SGBDs relacionais. Porto Alegre, PUC

RS, 1998.

SIMONETTO, Eugênio de Oliveira; RUIZ, Duncan Dubugras Alcoba. Revista do

CCEI(Centro de Ciências da Economia e Informática). Bagé: Ediurcamp, Volume 3, 1999

SNODGRASS, R. T. ET al. A TSQL2 Tutorial. Pittsburgh, PA – USA, 1994.

SOUZA, Fernanda Lima de; SANTOS, Kellyne Marques. Implementando a Dimensão Tempo

em Banco de Dados Convencionais: Um estudo de caso. Aracaju: Universidade Tiradentes,

2002
 52

The PostgreSQL Global Development Group; Documentação do PostgreSQL 8.0.0.

Disponível em: http://pgdocptbr.sourceforge.net/pg80/. Acessado em: 12/05/2008.

TRIPODI, Tony et al. Análise da pesquisa social: diretrizes para o uso de pesquisa em

serviço social e em ciências sociais. Rio de Janeiro: Francisco Alves, 1975.

TSQL2 Temporal Query Language. The University of Arizona. Disponível em:

http://www.cs. arizona.edu/~rts/tsql2.html. Acessado em 11/09/2007 às 21:07hs

YIN, R. K. Estudo de caso: Planejamento e Métodos. 2. ed. Porto Alegre: Bookman. 2001.