Get documents about "AN�LISE DE APLICA��O BASEADA EM DADOS HIST�RICOS: ESTUDO
Shared by: Z4LC6pQ
-
Stats
- views:
- 1
- posted:
- 5/27/2012
- language:
- pages:
- 72
Document Sample
UNIVERSIDADE CATÓLICA DO SALVADOR
WAGNER DE OLIVEIRA PORTO
ANÁLISE DE APLICAÇÃO BASEADA EM DADOS HISTÓRICOS:
ESTUDO COMPARATIVO NO SGBD ORACLE DO MODELO
RELACIONAL E TEMPORAL
SALVADOR
2005
UNIVERSIADE CATÓLICA DO SALVADOR
WAGNER DE OLIVEIRA PORTO
ANÁLISE DE APLICAÇÃO BASEADA EM DADOS HISTÓRICOS:
ESTUDO COMPARATIVO NO SGBD ORACLE DO MODELO
RELACIONAL E TEMPORAL
Monografia apresentada como exigência
parcial para obtenção de título de
bacharel em Informática, pela
Universidade Católica do Salvador, sob
orientação do Prof. Marco Antônio
Caldas de Figueirêdo Júnior.
SALVADOR
2005
CERTIFICADO
Certifico que a presente memória, ANÁLISE DE APLICAÇÃO BASEADA EM
DADOS HISTÓRICOS: ESTUDO COMPARATIVO NO SGBD ORACLE DO
MODELO RELACIONAL E TEMPORAL, foi realizada sob minha direção por
WAGNER DE OLIVEIRA PORTO, constituindo o Projeto Final do Curso de
Bacharelado em Informática da Universidade Católica do Salvador – UCSal.
Salvador, 03 de Novembro de 2005
------------------------------------------------------------------------------
MARCO ANTÔNIO CALDAS DE FIGUEIRÊDO JÚNIOR
Curso de Bacharelado em Informática
Universidade Católica do Salvador
AGRADECIMENTOS
Agradeço a minha família
por ter me dado força e acreditado em mim durante esses anos,
Agradeço a minha noiva
pela paciência e compreensão durante este momento,
Agradeço a meu orientador
por ter me ajudado a realizar esse projeto,
Agradeço a todos os meus colegas, professores e amigos
pelo companheirismo e por me ajudar a trilhar um caminho de sabedoria.
RESUMO
A necessidade de se armazenar e recuperar os vários estados de uma informação
geraram um novo elemento importante dentro dos bancos de dados (BD) convencionais:
o tempo. O aspecto tempo, presente em um banco de dados, é importante por
representar a evolução das informações permitindo uma melhor descrição da realidade.
Os bancos de dados temporais (BDT) são construídos para guardar informações antigas,
presentes e futuras, permitindo manter uma estrutura dinâmica dos dados, enquanto que
em bancos de dados relacionais (BDR) recursos adicionais são necessários para tal
implementação. Para representar as possíveis relações que ocorrem em um BD são
utilizados os modelos de dados, e possíveis decisões equivocadas de representação
podem aumentar a complexidade do projeto ou mesmo determinar problemas de
desempenho. Neste projeto, será avaliada a decisão quanto à implementação de uma
aplicação baseada em dados históricos nos moldes de um BDR e um BDT utilizando
como base o Sistema Gerenciador de Banco de Dados (SGBD) Oracle, avaliando os
benefícios e impactos de cada opção.
SUMÁRIO
1. INTRODUÇÃO ....................................................................................... 6
2. BANCO DE DADO RELACIONAL ..................................................... 8
2.1. Conceitos em Bancos de Dados Relacionais.......................................................... 8
2.2. O Modelo Entidade-Relacionamento ..................................................................... 9
2.3. A Implementação do Tempo em um Banco de Dados Relacional ....................... 10
3. BANCO DE DADOS TEMPORAL..................................................... 13
3.1. Conceitos de Representação Temporal ................................................................ 13
3.1.1. O Tempo ................................................................................................................................... 13
3.1.2. A Dimensão Temporal.............................................................................................................. 14
3.1.3. A Representação do Tempo em um Banco de Dados ............................................................... 15
3.1.4. Manipulação de Dados Temporais ........................................................................................... 17
3.2. Modelo de Dados Temporais ............................................................................... 19
3.2.1. O Modelo TempER .................................................................................................................. 21
3.3 Sistema de Banco de Dados Temporal .................................................................. 24
3.3.1. Questões no Desenvolvimento dos Modelos de Dados Temporais .......................................... 25
3.4. Consulta a Banco de Dados Temporal ................................................................. 26
3.4.1 Consultas Temporais ................................................................................................................. 27
3.5. Aplicabilidade ...................................................................................................... 29
4. IMPLEMENTAÇÃO ............................................................................ 32
4.1. A Aplicação .......................................................................................................... 32
4.2. Implementação de uma Base de Dados Temporal Utilizando o Oracle com o
Modelo Relacional. ..................................................................................................... 35
4.3. Implementação de uma Base de Dados Temporal utilizando o Oracle Time Series
com o Modelo Temporal. ............................................................................................ 38
5. ESTUDO COMPARATIVO ................................................................ 42
5.1 Análise Qualitativa ................................................................................................ 42
5.2. Análise Quantitativa ............................................................................................. 45
6. CONCLUSÃO ....................................................................................... 50
7. REFERÊNCIAS BIBLIOGRÁFICAS ................................................ 52
ANEXO A................................................................................................... 54
Código Fonte da Consulta na Base de Dados Relacional e Temporal ........................ 54
ANEXO B ................................................................................................... 60
Código Fonte da Geração dos objetos na Base de Dados Relacional ......................... 60
ANEXO C................................................................................................... 64
Código Fonte da Geração dos objetos na Base de Dados Temporal ........................... 64
ANEXO D................................................................................................... 69
Script de Criação do Calendário no BDT.................................................................... 69
1. INTRODUÇÃO
O armazenamento e a administração de dados são exigências consideráveis
no contexto das aplicações atuais. Devido a essas exigências, os sistemas devem ter
capacidades cada vez maiores e mais eficientes de armazenar e apresentar os dados de
uma forma organizada para possíveis interpretações. Para armazenar os dados de uma
aplicação, são utilizados com mais freqüência o BDR ou convencionais. Esses dados
são relacionáveis e acessíveis, e seu conteúdo reflete um instante da realidade. Com o
passar do tempo, os dados sofrem modificações à medida que o mundo real também
sofre alterações, isso faz com que o estado dos mesmos seja alterado.
Em alguns casos, o acompanhamento histórico da evolução da informação
se faz necessário e, com isso, dados considerados históricos não podem ser perdidos.
Dentre os exemplos de aplicações onde esses dados poderiam ser considerados
importantes, podem-se citar dados estatísticos de venda de um produto específico,
análise de índice pluviométrico e análise das condições da água das praias. Neste último
caso, a própria regra da aplicação exige o armazenamento de dados históricos para a
tomada de decisão, uma vez que a qualidade do trecho da praia é obtida a partir da
análise de amostras realizadas em semanas anteriores.
Neste contexto, o BDT surge para exercer funções que permitam tornar
históricos os dados e utilizá-los como propulsores para projeções. Esse tipo de banco de
dados “permite armazenar e recuperar todos os estados de um objeto, registrando sua
evolução ao longo do tempo” (EDELWEISS, 1994). Contudo, em que pese a utilização
de um BDT seja a decisão natural a tomar, um estudo detalhado deve ser realizado para
avaliar impactos e benefícios desta implementação.
Este projeto tem como objetivo comparar a implementação de uma
aplicação que avalia as condições da água das praias a partir de dados históricos em
uma base de dados temporal e uma base de dados relacional, avaliando critérios como
aspectos de projeto, alterações na forma de desenvolvimento e desempenho. Será
enfatizado o aspecto de tempo de transação de um BDT, que é o registro do momento
6
em que a informação é inserida no banco de dados (BD), uma vez que outros aspectos
como tempo de validade e versionamento de esquemas fogem ao escopo da aplicação.
A partir dos resultados obtidos com o estudo comparativo será possível
determinar quais as vantagens e desvantagens de se implementar uma base de dados
temporal com desenvolvimento próprio, ou seja, construir toda a base com
conhecimentos de BDR, ou através de objetos previamente desenvolvidos no SGBD
Oracle com o fim de dar suporte a BDT. O projeto poderá servir de base teórica e
prática para se iniciar um estudo mais detalhado na construção de uma base de dados
temporal.
O projeto está organizado da seguinte maneira: o capítulo 2 trata de
conceitos relacionados a BDR; já o capítulo 3 detalha os conceitos de BDT; o capítulo 4
especifica e descreve a implementação realizada; no capítulo 5, faz-se um estudo
comparativo com os resultados das implementações; e, por fim, no capítulo 6 é feita a
conclusão.
7
2. BANCO DE DADO RELACIONAL
2.1. Conceitos em Bancos de Dados Relacionais
Um sistema de banco de dados é basicamente apenas um sistema
computadorizado de manutenção de registros. O banco de dados, por si só, pode ser
considerado como o equivalente eletrônico de um armário de arquivamento; ou seja, ele
é um repositório ou recipiente para uma coleção de arquivos de dados
computadorizados (DATE, 2003).
Com a evolução dos bancos de dados, vários modelos de implementação têm
sido propostos, onde se destaca o modelo relacional. Um banco de dados relacional é
formado por uma coleção de tabelas que admite operações sobre elas. Dentre essas
operações, pode-se citar as de atualização, inserção, exclusão e seleção. As tabelas
armazenam os registros (tuplas) e implementam os relacionamentos entre os dados.
Modelo relacional de dados é a teoria formal em que se baseiam os sistemas
relacionais: ele trata apenas de questões lógicas, não de questões físicas. Este modelo
está relacionado com três aspectos principais dos dados: estrutura, integridade e
manipulação dos dados. O aspecto estrutural tem a ver com as relações propriamente
ditas; integridade está relacionada com o conceito de chaves primárias e estrangeiras,
entre outros pontos; e o aspecto manipulativo tem a ver com os operadores. Segundo
Date (2003), o Princípio da Representação Uniforme estabelece que todo o conteúdo de
informação de um BDR é representado de um e somente um modo, especificamente sob
a forma de valores explícitos em posições de colunas nas linhas das relações.
Além das tabelas e chaves, um BDR oferece outros objetos que facilitam a
manipulação dos dados. Dentre eles, podemos citar:
Procedimentos (procedures): Procedimentos realizados na base de dados
através de comandos SQL que podem ou não retornar algum valor.
8
Funções (functions): O mesmo que procedimentos, porém
obrigatoriamente retorna valores.
Gatilhos (triggers): Procedimentos executados automaticamente a partir
de um comando de atualização dos objetos da base de dados associado.
Cursor: Objeto do BD que é utilizado quando é necessário fazer algum
tratamento em cada linha de um resultado retornado pelo comando de seleção, resultset.
Dentre os modelos utilizados para representar um BDR, destaca-se o Modelo
Entidade-Relacionamento (E/R), que será detalhado a seguir.
2.2. O Modelo Entidade-Relacionamento
O modelo entidade/relacionamento (E/R) é uma das abordagens de
modelagem semântica mais conhecidas e mais usada, ela foi baseada no modelo de
entidades/relacionamentos introduzido por Chen em 1976 e desde então vem sendo
refinada pelos diversos autores. Segundo Chen (1976), uma entidade é uma coisa que
pode ser identificada distintamente e pode ser classificada como entidade regular e
fraca. Uma entidade fraca é uma entidade cuja existência depende de alguma outra
entidade, ou seja, ela não pode existir sem essa outra entidade. Ao contrário, uma
entidade regular não possui dependência quanto a outra entidade.
Outro aspecto importante do Modelo E/R são as propriedades, conhecidas
também como atributos, obrigatórios nas entidades e opcionais nos relacionamentos.
Como exemplo de propriedades podemos citar uma entidade EMPREGADO que possui
as propriedades nome, salário, cargo e assim por diante. As propriedades podem ser
classificadas em: simples ou compostas, chave, univaloradas ou multivaloradas, em
falta e básicas ou derivadas. Tal classificação foi bastante detalhada por Date (2003).
Chen (1976) define um relacionamento como uma associação entre
entidades. Para exemplificar, pode-se citar a relação entre um departamento e um
9
empregado, onde o departamento possui empregados. A cardinalidade de um
relacionamento E/R pode ser de um para um, de um para muitos ou de muitos para
muitos. A figura 1 exemplifica um diagrama E/R onde as entidades
DEPARTAMENTO, EMPREGADO e a entidade fraca DEPENDENTE são
representados por retângulos e os relacionamentos DEPTO-EMP e EMP-DEP,
representados pelos losangos junto às suas cardinalidades definindo que um
departamento possui um ou muitos empregados, e um empregado possui apenas um
departamento, por exemplo.
DEPARTAMENTO EMPREGADO
DPTO-
EMP
1..1 1..N 1..1
EMP-DEP
0..N
DEPENDENTE
Figura 1 – Exemplo de modelo E/R
Fonte: Date, 2003
2.3. A Implementação do Tempo em um Banco de Dados Relacional
Durante a fase de pesquisa bibliográfica, não foram encontradas referências
de um SGBD considerado totalmente temporal, ou seja, que atenda a todas as
necessidades que um BD desse tipo possui. Na realidade, o que temos são várias
experiências sob forma de protótipos, nos quais se baseiam estudos de problemas
encontrados (de armazenamento e recuperação de informações), e mapeamento de
10
modelos temporais para BD tradicionais, nos quais os rótulos temporais são
explicitamente representados e manipulados.
A utilização de um modelo de dados temporal na modelagem, com grande
poder de expressão, não implica que seja necessária a existência de um banco de dados
correspondente a este modelo. Podem ser utilizados BD’s relacionais, com todas as
características de robustez que apresentam, desde que seja possível mapear
adequadamente o modelo temporal para o modelo do BD utilizado.
O desenvolvimento de uma base de dados temporal a partir de uma base de
dados relacional pode ser realizada representando as características temporais como
atributos comuns nas tabelas e utilizando-se de objetos disponíveis no SGBD, como
gatilhos , procedimentos e funções. Dentre esses objetos, o que tem maior importância
na simulação de uma dimensão temporal em um BDR são os gatilhos, e por esse
motivo sua utilização será detalhada um pouco mais logo abaixo.
Os gatilhos são utilizados também como uma maneira prática de
implementar rotinas para garantir integridade de dados ou de operações. Gatilhos são
rotinas ou procedimentos que são utilizados quando um comando insert, update ou
delete é executado em uma tabela ou até mesmo visão (RAMALHO, 2001). Um gatilho
é disparado quando um dos comandos acima é executado, e essa execução é automática,
sem interferência do usuário.
Um gatilho pode ser do tipo BEFORE, que é disparado antes de executar o
comando que o disparou, AFTER, que é disparado após a execução do comando de
disparo, e INSTEAD OF, que é executado no lugar do comando que o disparou. No caso
do Oracle, este último tipo de gatilho só pode ser usado associado a visões.
Esse projeto, especificamente, foi desenvolvido a partir da implementação de
uma base de dados temporal para uma aplicação que utiliza a característica de tempo de
transação. A implementação do tempo em na base de dados relacional foi realizada
adicionando-se um atributo do tipo data (date) que é gerenciado através de um gatilho
responsável por armazenar nesse campo o momento em que a informação foi inserida
no BD.
11
Na implementação do conceito de temporalidade no BDR é necessária a utilização de
gatilhos que são responsáveis por armazenar a data do servidor no atributo onde ficam
registrados os instantes em que os dados são inseridos, mesmo que o usuário tente
inserir um valor o gatilho altera automaticamente de acordo com o servidor e caso a
operação seja de alteração (update) o gatilho não permite que essa data seja alterada.
12
3. BANCO DE DADOS TEMPORAL
3.1. Conceitos de Representação Temporal
3.1.1. O Tempo
O tempo é um aspecto importante de todo o evento do mundo real. Todo
bom modelo de BD deve utilizar mecanismos que capturem de maneira eficiente a
evolução temporal de seus objetos. Esse item tem grande importância no tratamento das
informações, representando a duração dos eventos, previsões e o tempo de vida de
documentos ou operações. O tempo, segundo Tansel (1990), é uma seqüência de
“pontos de tempo” eqüidistantes, ou seja, 0, 1, 2, ..., NOW, onde 0 representa o tempo
relativo inicial, e NOW é o tempo presente. A dimensão temporal é composta por uma
seqüência de pontos consecutivos no tempo, que recebe o nome de eixo temporal.
A definição de uma ordem a ser seguida no tempo é fundamental quando
utilizada alguma representação temporal. Há três opções de ordenação temporal
(ANTUNES, 1997):
Tempo linear: total ordenação entre quaisquer dois pontos no tempo.
Este é o mais comum.
Tempo ramificado: permite a possibilidade de dois pontos diferentes
serem sucessores (ramificação no futuro) ou antecessores (ramificação no passado)
imediatos de um mesmo ponto. Para ambos a restrição linear é abandonada.
Tempo circular: utilizado para modelar eventos e processos recorrentes.
A maior parte dos modelos temporais se baseia no tempo linearmente ordenado. A
ordenação total do tempo pode ser definida com mais precisão através da teoria dos
conjuntos.
13
3.1.2. A Dimensão Temporal
Os modelos de dados tradicionais apresentam duas dimensões, as linhas
(instâncias dos dados) e as colunas (atributos) de uma tabela. Cada atributo de uma
instância apresenta um só valor. Se for feita uma alteração deste valor, o anterior é
perdido. Os modelos temporais acrescentam mais uma dimensão aos modelos
tradicionais – a dimensão temporal. Esta dimensão associa alguma informação temporal
a cada valor. Caso o valor de um atributo seja alterado, o valor anterior não é removido
do banco de dados – o novo valor é acrescentado, associado a alguma informação que
define, por exemplo, seu tempo inicial de validade. Por exemplo, em um atributo que
representa o salário de um funcionário, todos os valores deste campo ficam
armazenados, cada valor associado ao seu tempo de validade. Deste modo, é possível
acessar toda a história dos atributos, sendo possível analisar sua evolução temporal.
Ainda neste contexto, pode-se definir duas maneiras distintas de variação
temporal: tempo contínuo e tempo discreto. Supõe-se que o tempo é contínuo por
natureza. Entretanto, sem grande perda de generalidade, o tempo pode ser considerado
como discreto. Esta segunda forma de representação simplifica consideravelmente a
implementação de modelos de dados. Modelos de dados que suportam uma noção
discreta de variação temporal são baseados em uma linha de tempo composta de uma
seqüência de intervalos temporais consecutivos, que não podem ser decompostos, de
idêntica duração. Estes intervalos são denominados chronons. A duração particular de
um chronon não é necessariamente fixada no modelo de dados, podendo ser definida em
implementações particulares do modelo de dados.
Outro conceito relevante quando analisamos a dimensão temporal é a
granularidade temporal. Em um sistema, este aspecto consiste na duração de um
chronon. Entretanto, dependendo da aplicação, podem ocorrer múltiplas possibilidades
de unidades. Isso acontece quando um único BD é formado pela integração de
diferentes BDT's, onde é possível que cada BD possua sua própria unidade de tempo,
por exemplo dias, semanas, horas e minutos, e o BD heterogêneo resultante possui todas
essas unidades de tempo.
14
Consideram-se vários domínios temporais divididos em níveis, onde cada
instante de um domínio de alto nível (dia, por exemplo) está associado a um conjunto de
instantes de um domínio de nível inferior (hora, por exemplo). Neste exemplo, cada
unidade dia corresponde a 24 unidades horas. Vale salientar, que é preciso definir se o
conceito utilizado na resolução do problema será o de tempo absoluto (definido por um
tempo específico) ou de tempo relativo (tem sua validade relacionada à validade de
outro fato).
3.1.3. A Representação do Tempo em um Banco de Dados
Os bancos de dados temporais são projetados de forma dinâmica, capturando
informações sobre o presente, passado e futuro, preservando assim, informações do
mundo real (SILVA 1992, SNODGRASS 1995, TANSEL 90). Os BDR podem ser
classificados de acordo com a forma utilizada de armazenamento de valores. Segundo
Edelweiss (1998), os BDR’s podem ser dos seguintes tipos:
Bancos de Dados Instantâneos: corresponde aos bancos de dados
tradicionais, onde são armazenados os valores presentes. A cada modificação no valor
de uma propriedade, o valor anteriormente armazenado é destruído e somente o último
valor está disponível. A manutenção de informações temporais neste tipo de banco de
dados somente pode ser realizada explicitamente, pela inclusão de atributos definidos
sobre o domínio tempo, e pela sua manipulação dos programas de aplicação. Exemplo:
Se um empregado do departamento de compras de uma empresa passa a trabalhar no
departamento de vendas, os dados do local de trabalho anterior não são mantidos, pode-
se armazenar o estado anterior, mas não se pode manipular os dados históricos.
Bancos de Dados de Tempo de Transação: as informações temporais
são associadas ao seu tempo de transação sob forma de rótulo temporal (timestamps).
Este instante é fornecido pelo SGBD, sendo esta operação transparente ao usuário. A
alteração do valor de uma informação não destrói o valor anteriormente definido,
ficando todos os valores armazenados no banco de dados. O estado atual do BD é
15
composto pelos últimos valores definidos para cada uma das informações. A data de
transação é associada às informações pelo SGBD, como demonstra a Tabela 1.
Tabela 1 - Banco de Dados de Tempo de Transação
Código Nome Cargo Salário Data
01 Carlos An. de sistemas 800,00 01/01/1996
01 Carlos An. de sistemas 900,00 01/06/1996
01 Carlos An. de sistemas 1.000,00 01/01/1997
01 Carlos An. de sistemas 2.000,00
Fonte: EDELWEISS, 1998
Se algum dado passado for alterado, o sistema considera como sendo uma
nova tupla na tabela, porque essa alteração considera a data atual do sistema e não a
data que aconteceu realmente. Se quisesse alterar o salário de Carlos em 01/01/1997 não
poderia, pois essa data foi colocada pelo sistema. Para alterar o salário na data atual,
última referência válida (data não preenchida) seria alterada com a data atual, e uma
nova linha seria adicionada na tabela com o novo valor.
Bancos de Dados de Tempo de Validade: associa a cada informação
somente o tempo de sua validade no tempo real, podendo representar o início de sua
validade (ponto no tempo, variação por degraus), a validade somente naquele ponto no
tempo (variação discreta), ou seu intervalo de validade. O tempo de validade deve
sempre ser fornecido pelo usuário. Em bancos de dados de tempo de validade não se
tem acesso ao tempo em que a informação foi definida, sendo armazenado somente o
tempo em que a mesma é válida. Este tipo de banco de dados permite que sejam
corrigidas informações do passado – se alguma das informações tiver sido registrada
incorretamente, é feita uma nova definição com a data de validade correspondente,
sendo que somente a versão atual dos dados está disponível, conforme ilustrado na
Tabela 2.
16
Tabela 2 - Banco de Dados de Tempo de Validade
Código Nome Cargo Salário Data
01 Carlos An. de sistemas 1.000,00 01/01/1996
01 Carlos An. de sistemas 900,00 01/06/1996
Fonte: EDELWEISS, 1998
Neste caso, pode-se armazenar e manipular informações passadas. Como
mostra o exemplo, o salário de Carlos em 01/01/1996 foi alterado de 800,00 para
1.000,00, permanecendo essa informação, sem que o sistema considerasse como uma
nova informação, não acrescentando, assim, uma nova tupla. Em banco de dados de
tempo de validade podem ser feitas alterações em informações passadas;
Bancos de Dados Bitemporais: é a forma mais completa de armazenar
informações temporais. Ambos os tempos, de transação e de validade, são associados a
cada informação.Toda a história do banco de dados fica armazenada. O estado atual do
banco de dados é constituído pelos valores atualmente válidos. 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.
3.1.4. Manipulação de Dados Temporais
Os BDTs possibilitam a gerência das informações através de operações
básicas: inserção, atualização, exclusão e seleção (HUBLER, 2001). A seguir, uma
análise do comportamento destas operações:
Inserção: quando uma determinada informação é inserida, deve-se criar
mecanismos capazes de fornecer os rótulos temporais necessários;
Atualização: deve considerar, em primeiro lugar, o tempo associado à
informação (passado, presente e/ou futuro). Dependendo deste tempo, mecanismos
diferentes devem ser criados para que se mantenha o estado consistente dos dados;
17
Exclusão: pode ser de duas formas: exclusão lógica e física. A lógica é
realizada encerrando-se a “vida” da informação. A física é utilizada quando se deseja
remover fisicamente uma informação que não é mais relevante (HUBLER, 2001);
Seleção: além das informações básicas de gerenciamento, os dados devem
ser consultados, uma vez que o sucesso de um sistema de banco de dados está bastante
relacionado com a facilidade de recuperação das informações armazenadas. As
consultas temporais que podem ser realizadas a um BDT dependem não só da
especificação da informação buscada, mas também do tipo de BD implementado pelo
modelo utilizado e da história considerada.
A seguir, são mostradas de acordo com (EDELWEISS, 98), as informações
que podem ser recuperadas para cada um dos tipos de BD temporais:
- Banco de dados instantâneos: como não possuem suporte à informações
temporais, não permitem tais consultas;
- Bancos de dados de tempo de transação: podem ser recuperados os
valores atuais das informações armazenadas e os valores das informações definidas em
algum instante no passado;
- Bancos de dados de tempo de validade: podem recuperar informações
válidas no presente, no passado, além de valores que serão válidos no futuro (todos de
acordo com a atual percepção dos dados).
- Bancos de dados bitemporais: podem recuperar tanto o tempo de
transação como o de validade. Isto permite que sejam feitas consultas a respeito de
valores atuais, passados e futuros.
A consulta pode ser realizada através de uma linguagem textual ou de uma
linguagem visual. A linguagem textual de consulta exige que o usuário tenha um grande
conhecimento de sintaxe e da forma como as informações estão organizadas no BD. Já a
linguagem visual de consulta apresenta um ambiente mais amigável para recuperação de
informações, permitindo que usuários não familiarizados com a sintaxe da linguagem de
consulta textual formulem suas consultas de forma intuitiva (DATE, 1990).
18
3.2. Modelo de Dados Temporais
O modelo de dados, segundo Korth (1995), é um conceito fundamental à
estrutura de um banco de dados, por corresponder a uma coleção de ferramentas
conceituais utilizadas para realizar a descrição dos dados, os relacionamentos, a
semântica dos dados e ainda as restrições de consistência. Edelweiss (1994) considera
que a modelagem temporal de um sistema de informação deve representar não só a
estrutura dos dados manipulados, mas também sua dinâmica – seu comportamento com
a passagem do tempo.
Os modelos de sistemas de informação são de grande importância por
demonstrarem como as informações devem estar situadas e relacionadas em seu
contexto. Eles devem representar o sistema o mais próximo possível da realidade do
usuário, buscando a melhor forma para o armazenamento de informações e agilidade de
respostas às consultas. Um modelo temporal representa informações associadas à
dimensão temporal. O banco de dados, para armazenar informações do sistema, deve,
portanto, ser um banco de dados temporal, que armazena tanto dados atuais como
valores anteriormente definidos, permitindo desta maneira que estados passados do
banco de dados possam ser reconstituídos. Também podem ser armazenadas
informações futuras permitindo previsões para eventos futuros.
De acordo com Edelweiss (1998), um modelo de dados deve apresentar uma
estrutura de objetos que podem ser manipulados por esta linguagem, uma linguagem
para atualizar estes objetos (update), uma linguagem de consulta, e algum mecanismo
para expressar restrições de integridade. Os modelos de dados temporais também devem
apresentar estas características, acrescentado a possibilidade de representar informações
temporais, efetuar consultas temporais, e permitir a definição de restrições de
integridade temporal.
Alguns aspectos devem ser considerados ao analisarmos um modelo de
dados, tais como identificar o tipo de rótulo temporal utilizado pelo modelo (ponto no
19
tempo, intervalo temporal, elemento temporal ou duração), analisar a forma de variação
temporal dos atributos (podem ou não variar com o tempo, todos ou alguns), verificar se
os rótulos temporais são implícitos ou explícitos, homogeneidade temporal e
apresentação e funcionalidade da linguagem de consulta.
A seguir, são apresentados os modelos de dados temporais estudados por
Posser (2001). Eles enfocam, principalmente, a forma de representação dos aspectos
temporais e, em alguns, há a existência de uma linguagem de consulta associada
(EDELWEISS, 1994). São eles:
- Historical Relational Data Model (HRMD), proposto por Clifford;
- Temporal Relational Model (TRM), proposto por Navathe;
- Historical Structured Query Language (HSQL), proposto por Sarda;
- Temporal Structured Query Language 2 (TSQL2), proposto por
Snodgrass;
- Temporal Enhanced Entity-Relationship (TEER), proposto por Elmasri;
- Temporal Entity-Relationship (TempER) proposto por Heuser;
- Entity-Relationship-Time (ERT), proposto por Loucopoulos;
- Temporal Functionality in Objects with Roles Model (TF-ORM), proposto
por Edelweiss.
Os modelos HRDM, TRM, HSQL e TSQL2 são modelos relacionais
estendidos, nos quais foi acrescida a dimensão temporal. Já o TEER e o TempER são
modelos Entidade-Relacionamento (ER) estendidos. O ERT utiliza a orientação a
objetos baseada no enfoque do modelo ER. Por último, o TF-ORM é um modelo
orientado a objetos no qual apenas foi incorporada a capacidade de representação dos
aspectos temporais. Dentre os modelos analisados, o modelo TempER foi escolhido
para se desenvolver o estudo de caso, sendo assim, será melhor explorado a seguir.
20
3.2.1. O Modelo TempER
O TempER é um modelo de dados do tipo Entidade-Relacionamento que
permite referenciar os objetos (entidades, relacionamentos ou valores de atributos) à
dimensão temporal. Desta forma, é possível representar o relacionamento entre as
entidades temporalizadas e as não-temporalizadas.
No caso das entidades temporalizadas, a validade temporal é o subconjunto
de pontos do eixo temporal, sendo assim denominada de entidade transitória. Com
relação às entidades não-temporalizadas, admite-se que a sua existência ocorre durante
todo o eixo temporal (validade temporal). Deste modo, foram classificadas como
entidades perenes (HEUSER, 1998).
O modelo foi concebido com base, principalmente, no modelo ER. As
principais diferenças entre as abordagens situam-se na simbologia e na primitiva
temporal adotada – o elemento temporal no lugar do intervalo de tempo. Em uma visão
geral, as principais características do modelo TempER são as seguintes:
• Oferece uma simbologia que diferencia elementos temporizados de
elementos não temporizados, semelhante à do modelo ERT;
• Permite que se associe em um mesmo diagrama entidades temporalizadas
com não temporalizadas. As entidades não temporalizadas passam a ser denominadas de
“perenes”, sendo assumido que estas também apresentam uma dimensão temporal
implícita, igual a todo o conjunto de pontos do eixo temporal. As entidades
temporalizadas passam a ser denominadas “transitórias”;
• Qualquer que seja a classificação das entidades em relação ao tempo,
sejam elas perenes ou transitórias, ortogonalmente sempre apresentam duas
perspectivas: uma não temporal e uma temporal. Quando se focaliza os conjuntos de
entidades pela perspectiva não temporal estes apresentam apenas duas dimensões
(tuplas x atributos não temporais).
Por outro lado, quando se focaliza estes mesmos conjuntos pela perspectiva
temporal, eles apresentam três dimensões (tuplas x atributos temporais x eixo temporal):
21
No tocante aos relacionamentos, ou as entidades se associam entre si na
perspectiva temporal (relacionamentos temporais) ou na perspectiva não temporal
(relacionamentos não temporais);
Possibilita que as restrições de cardinalidade levem em consideração os
momentos do tempo de validade de um relacionamento temporal;
Faz uso de um dicionário de dados para descrever os atributos, evitando
que estes sejam explicitados graficamente. Isto contribui para tornar os diagramas
mais administráveis visualmente.
Toda entidade, no TempER, é uma instância de um conjunto-entidade,
assim como todo o relacionamento é uma instância de um conjunto-relacionamento.
As figuras 2 e 3 referem-se à notação de conjuntos-entidade e conjuntos-
relacionamento. Os atributos são propriedades das entidades e dos relacionamentos, os
quais não são representados graficamente, e sim por meio de um dicionário de dados
associado ao diagrama ER, resultando em um modelo mais claro visualmente.
Tr Pe
FUNCIONARIO FUNÇÃO
Entidade Transitória Entidade Perene
Figura 2 - Notação de conjuntos-entidade
Fonte: HEUSER, 1998
T
Relacionamento Temporal Relacionamento Intemporal
Figura 3 - Notação de conjuntos-relacionameno
Fonte: HEUSER, 1998
22
As entidades cuja validade temporal é exatamente igual a todo o eixo
temporal são consideradas perenes. Toda vez que uma entidade desse tipo é incluída no
banco de dados do sistema, assume-se que sua validade temporal inicia no primeiro
ponto do eixo temporal e se estende até o último. Porém, o fato de uma entidade ser
perene não significa que esta entidade não possa ser excluída do banco de dados.
Conseqüentemente, enquanto uma entidade perene estiver presente no banco
de dados sua existência será constante e igual ao conjunto de pontos do eixo temporal,
não sendo permitido ampliar ou reduzir sua validade temporal (HEUSER, 1998). Ao
contrário da entidade perene, a entidade transitória é modelada para existir apenas por
curtos períodos de tempo, sendo possível aumentar ou reduzir a sua validade temporal.
A figura 4 apresenta um esquema ER convencional e seu correspondente
temporal no modelo TempER, e um exemplo de povoamento de entidades e de
relacionamentos para este esquema.
Figura 4 - Exemplo de esquema ER e o correspondente TempER
Fonte: HEUSER, 1998
23
3.3 Sistema de Banco de Dados Temporal
Enquanto a maioria das aplicações atuais necessita armazenar a variação
temporal dos dados, a realidade observada é que não há BDT comerciais usados
amplamente. Uma razão para a falta de transferência tecnológica da pesquisa para a
prática é a necessidade de consenso comum aceito de modelo de dados ou linguagens de
consultas que são a base da pesquisa e desenvolvimento: a terminologia é inconsistente.
Outro fator que limita a utilização de soluções em BDT é a forma de
definição da dimensão temporal. Como já citado e descrito por Snodgrass (1994), há
três tipos de tempos que podem ser usados:
1) Tempo definido pelo usuário: tem suporte garantido na maioria dos
SGBDs comerciais (e está presente no SQL padrão);
2) Tempo de Validade: suportado por alguns SGBDs;
3) Tempo de Transação: é suportado em alguns SGBDs Objeto-Relacional
e em um relacional.
A necessidade de suporte temporal requerido pelo BDT vai ser determinada
pela característica da aplicação, sendo necessário apenas um ou até mesmo os três tipos
descritos. Caberá ao analista avaliar se o BDT escolhido oferece os recursos adequados
para a implementação da solução.
Nos BD’s convencionais, os atributos são predefinidos, e isso poderia ser
feito de forma análoga em BDT. Se um atributo é definido como inteiro, não é possível
inserir caracteres. Analogamente, há a necessidade de testes de consistência para
justificar a definição de um atributo como temporal. Por exemplo, suponha-se que o
nome de uma função determina o salário. O SGBDT deve garantir que o mesmo nome
não esteja associado com dois salários diferentes ao mesmo tempo. Se o atributo
temporal é tratado simplesmente como outro atributo qualquer, parece não ser
necessário defini-lo especialmente como temporal.
24
Um problema poderia ser valores de tempo de muitas granularidades
diferentes, porém isso poderia ser solucionado com um suporte para realizar conversões
de valores de tempo entre as diferentes granularidades utilizando-se operações
apropriadas. Há a necessidade de uma operação de intercalação para tornar o trabalho
com dados vindos de diferentes BD ou relações definidas em diferentes níveis de
granularidade. Em BD científicos e BD de planejamento é essencial o suporte não
apenas a tempos baseados na linha do tempo (tempo absoluto), mas também a tempos
relativos.
3.3.1. Questões no Desenvolvimento dos Modelos de Dados Temporais
Entre os aspectos que devem ser avaliados para o desenvolvimento de
modelos temporais, pode-se citar:
Homogeneidade: em alguns modelos de dados, todos os atributos de
uma tupla são definidos sobre os mesmos intervalos de tempo. Outros permitem
atributos a serem definidos sobre diferentes intervalos de tempo, em parte para permitir
produto cartesiano;
Agrupamento: alguns modelos requerem que tuplas de valor equivalente
(aquelas com idênticos valores de atributos explícitos), sejam agrupadas se elas estão
sobrepostas no tempo, que é, combinadas em uma tupla. Outros modelos não permitem
o agrupamento de tuplas de valor equivalente;
Atributo-valor x rótulo-tupla: a comunidade de pesquisa está separada
neste aspecto, com metade dos modelos de dados adotando a primeira abordagem que é
vista por alguns como sendo próxima de orientação-objeto e a outra metade adotando a
segunda abordagem que vista por alguns como sendo mais eficiente;
Níveis de alinhamento: alguns modelos de atributo-valor podem ser
vistos como uma extensão dos modelos relacionais alinhados. Alguém pode perguntar
se o alinhamento deve ser restrito a um nível ou se múltiplos níveis de alinhamento
devem ser permitidos;
25
Vaccuming: quando tempo de transação é suportado, todas as alterações,
incluindo remoção lógica, são implementadas como inserções físicas, levando a um
crescimento do BD. No modelo relacional padrão, uma notação adicional de remoção é
necessária em ordem para controlar o tamanho e o conteúdo do BD. Vaccuming (gerar
vácuo) é esta notação e denota a flexibilidade, a remoção física, consistente com a
semântica do tempo de transação dos dados em uma BDT que suporta tempo de
transação. A eliminação física de dados temporais não relevantes é permitida, para os
quais o custo de armazenamento é significativo;
Tempo periódico: há modelos que suportam eventos periódicos, como,
por exemplo, um avião que voa todo dia um certo tempo;
Tempo “manufaturado”: alguns defendem a semântica de interseção,
onde o período de validade de uma tupla resultante do produto cartesiano é a interseção
do período de validade de duas tuplas básicas e caracteriza qualquer tempo de saída
como manufaturado e, em alguns casos, artificial.
Outros consideram que há aplicações para outras semânticas tal como união,
sendo totalmente natural. O modelo de dados temporal básico e a linguagem devem ser
projetados unicamente em termos de suas propriedades semânticas, com possivelmente
múltiplos modelos de dados distintos sendo empregados para representação e
apresentação.
3.4. Consulta a Banco de Dados Temporal
Uma linguagem de consulta temporal deve possibilitar a recuperação de
todas as informações armazenadas no banco de dados, de modo a que seja tirado real
proveito do acréscimo da dimensão temporal. Nos últimos anos várias linguagens de
consulta temporal foram propostas (MOREIRA, 1999).
O fator tempo pode estar envolvido de formas diferentes em consultas
temporais (OLIVEIRA, 1994):
26
Fornecer valores de propriedades cujo domínio é temporal. Exemplo:
fornecer o valor da propriedade que armazena a data de nascimento de uma pessoa;
Se referir a um determinado instante ou intervalo temporal. Exemplo:
qual o valor do salário no dia 01/01/2005;
Recuperar valores com base em restrições temporais. Exemplo: recuperar
todos os valores do salário antes do dia 01/01/2003;
Fornecer informações temporais (datas, intervalos). Exemplo: qual a data
em que foi alterado o salário de um funcionário.
A maioria dos modelos de dados temporais apresenta linguagens de consulta
textuais, geralmente derivadas do SQL. Dentre elas, a mais conhecida é TSQL2.
Vale salientar, contudo, que o processamento de consultas temporais
apresenta diversos problemas além daqueles usualmente enfrentados. Entre eles
podemos citar (EDELWEISS, 1998):
O grande volume de dados armazenados em um banco de dados temporal
implica na necessidade de novos métodos de indexação (estruturas e algoritmos de
busca);
Métodos tradicionais de indexação só podem ser utilizados para valores
com algum tipo de ordenação completa, com estruturas de acesso para intervalos;
Manipulação de informações incompletas, devido a valores incompletos
ou inexistentes, a partir dos quais devem ser inferidas informações. Podem ser devido à
incerteza quanto a existência de objetos em certos pontos no tempo ou à indeterminação
temporal causada por eventos cujo tempo de ocorrência não é conhecido.
3.4.1 Consultas Temporais
Abaixo, são analisadas as diferentes formas que podem apresentar as
consultas quando utilizados banco de dados temporais. Para maior abrangência serão
27
considerados somente banco de dados bitemporais por englobar os outros tipos de banco
de dados.
Uma consulta apresenta dois componentes ortogonais: um componente de
seleção e um de saída (projeção).
O componente de seleção normalmente é representado através de uma
condição lógica. Quando essa condição envolve valores temporais é utilizada lógica
temporal. Nesse caso, operadores para tratar valores temporais, tais como operadores
booleanos (antes, depois, durante) e operadores que retornam valores temporais (depois,
agora, início de intervalo, distância temporal) são necessários.
De acordo com os componentes de seleção, as consultas podem ser
classificadas em:
Consultas de seleção sobre dados – quando as condições são
estabelecidas somente sobre os valores de dados. Exemplo: selecionar o salário do
funcionário de nome Carlos. É importante ressaltar que quando forem utilizadas tipos de
dados temporais, tais como datas e horas, a utilização destes na condição de seleção
representa uma seleção sobre os dados e não uma seleção temporal. Exemplo deste
último caso: selecionar o nome dos empregados que apresentam data de nascimento
posterior a 01/01/1980.
Consultas de seleção temporal – são as consultas nas quais somente
informações temporais associadas aos dados (tempo de transação e/ou tempo de
validade) são analisadas pela condição de seleção. Exemplo: selecionar todos os
empregados da empresa durante o período de 01/01/1996 a 01/01/1997.
Consultas de seleção mista – a condição de seleção atua não somente
nos dados mas também nas informações temporais associadas a eles. Exemplo:
selecionar todos os empregados do departamento denominado entregas que estavam
habilitados para dirigir automóveis durante o período de 01/01/1995 a 01/07/1995.
28
Analisando agora o componente de saída, na consulta podem ser solicitados
valores de dados e/ou valores relativos às informações temporais associadas aos dados.
Podemos ter, portanto (EDELWEISS, 1998):
Consultas de saída de dados – nas quais as informações selecionadas
correspondem exclusivamente a valores de dados. Exemplo: selecionar o nome dos
funcionários do departamento entregas.
Consultas de saída temporal – recuperam informações abstraídas das
informações temporais associadas aos dados. Deste modo podem ser recuperados
pontos no tempo, intervalos temporais e durações temporais. Exemplo: selecionar todos
os períodos nos quais qualquer empregado do departamento de entregas estava
habilitado a dirigir automóveis.
Consultas de saída mista – recuperam simultaneamente valores de
dados e valores temporais associados a estes dados. Exemplo: selecionar os valores de
salário com os respectivos tempos de validade para o empregado chamado João entre
01/01/1995 e 01/01/1996.
Analisando as possíveis combinações entre os componentes de seleção e de
saída de uma consulta observamos que a única combinação que não pode ser utilizada é
a de seleção temporal com saída temporal – devemos ter algum dado envolvido em pelo
menos um dos componentes.
3.5. Aplicabilidade
Para algumas aplicações, tanto o estado passado das informações quanto o
estado presente são de extrema importância. Por exemplo, para um sistema bancário é
necessário que informações sobre todas as transações efetuadas em uma conta sejam
armazenadas. Conforme as necessidades do cliente ou do próprio banco, essas
informações poderão ser obtidas retratando o estado da conta em qualquer instante de
tempo desejado ou todos os eventos ocorridos durante um determinado período. Esse
29
fato então limita o uso de BD relacionais uma vez que estes não possuem recursos que
permitam acessar os estados passados da conta. Nesse contexto, surge então um novo
elemento na área de Banco de Dados: o tempo relacionado às informações.
Pode-se citar mais algumas aplicações cujas características temporais são
claras:
Para um médico, os dados passados de um paciente são essenciais para
conhecê-lo, fazer novos diagnósticos, acompanhar a evolução de uma doença que o
paciente possui, determinar novos tratamentos, etc;
A área comercial, dados estatísticos de venda de um produto específico
podem ser importantes para determinar a freqüência de compra deste produto, assim
como ajudar na tomada de decisão em vários aspectos;
O controle de tráfego aéreo, onde se controla os horários de decolagem e
pouso de aviões;
No meio acadêmico, onde informações curriculares sobre os alunos
precisam ser armazenadas e acessadas posteriormente;
Sistemas de informação geográfica (SIG) onde se percebe que o fator
tempo é um componente imprescindível para a análise, previsão e conhecimento dos
fenômenos geográficos encontrados na natureza e nas relações sócio-econômicas. Os
SIGs disponíveis atualmente consideram as entidades como se o mundo existisse
somente no presente. Informações geográficas são incluídas e alteradas ao longo do
tempo, mas o histórico destas transformações não é mantido na base de dados.
Aplicações de SIG deveriam ser capazes de lidar com dados espaço-temporais, que
refletem a natureza espaço-temporal dos fenômenos geográficos, como por exemplo, a
destruição feita pelo fogo em uma queimada na floresta, a erosão gradual dos solos, a
formação de tempestades, o estudo da poluição ambiental, entre outros.
Inserido no contexto de aplicações de SIG, pode-se citar o exemplo utilizado
como estudo de caso de aplicação temporal: um sistema de controle de qualidade de
água em trechos de praias. Neste exemplo, o responsável capta água a partir de uma um
30
ponto na orla marítima. O local de captação de água é pontual e a água captada vai ser
analisada em laboratório e periodicamente é feita coleta de amostra de água para
verificar a qualidade da água nas diversas praias. Estudos sobre qualidade da água são
desenvolvidos a partir desta amostragem e a qualidade do trecho é determinada pelo
conjunto das últimas amostras realizadas Para avaliar todas essas informações, é
necessário que as informações atuais estejam guardados no banco assim como todo o
histórico de mudanças, o que indicaria a utilização de um BDT.
31
4. IMPLEMENTAÇÃO
A implementação da base de dados utilizada no projeto foi realizada
utilizando-se o SGBD Oracle. Este SGBD foi escolhido para o desenvolvimento por
possuir uma extensão chamada de Oracle Time Series Cartridge, que provê
armazenamento e recuperação de dados temporais de tempo de transação através de um
conjunto de procedimentos, funções e objetos (ORACLE, 1999). Esta extensão foi
desenvolvida com o intuito de atender às exigências de aplicações específicas e tornar
mais conveniente e eficaz o tratamento de dados de tempo, do que formas tradicionais e
funções definidas por usuários. No Time Series o tempo é caracterizado através da
inserção de um rótulo temporal. Basicamente qualquer operação sobre qualquer dado
que envolva informação temporal é obtida através do rótulo temporal. Este tipo de
procedimento caracteriza o Time Series Cartridge como uma ferramenta de
gerenciamento de informações de tempo de transação.
A utilização do SGBD Oracle no estudo de caso se justifica pelo fato da
indisponibilidade de um banco essencialmente temporal. Esta abordagem está de acordo
com Hubler (2001) que define que bancos de dados tradicionais podem ser utilizados se
existir um mapeamento adequado entre o modelo temporal e o modelo do banco de
dados utilizado.
4.1. A Aplicação
A aplicação escolhida para o desenvolvimento do projeto é utilizada no
controle da qualidade da água das praias. Segundo o Conselho Nacional do Meio
Ambiente (CONAMA), o controle da qualidade é feito através da avaliação de
parâmetros e indicadores específicos, definidos com critérios detalhados que reduzem
os riscos de infecções aos banhistas (CONAMA, 2005). Esta aplicação foi projetada de
32
maneira simplificada, pois o objetivo é apenas obter características temporais para o
desenvolvimento de um BDT, oferecendo subsídios para uma análise comparativa.
Segundo as definições, a amostra da água retirada de um trecho de uma
determinada praia, é necessário informar como foi realizada a coleta dessa amostra para
se ter certeza que todas as amostras foram conseguidas diante das mesmas condições,
tendo em vista que o resultado é conseguido analisando-se as amostras das últimas
cinco semanas. Essa coleta possui um responsável, que também é representado sobre o
conceito temporal.
Em cada amostra podem ser analisados três diferentes componentes
infecciosos: coliformes fecais, bactérias tipo Escherihia Coli e tipo Enterococos. Para
subdividir as águas consideradas próprias, existem três categorias segundo o
CONAMA:
a) Excelente: quando em 80% ou mais de um conjunto de amostras obtidas
em cada uma das cinco semanas anteriores, colhidas no mesmo local, houver, no
máximo, 250 coliformes fecais (termotolerantes) ou 200 Escherichia Coli ou 25
Enterococos por l00 mililitros;
b) Muito Boa: quando em 80% ou mais de um conjunto de amostras obtidas
em cada uma das cinco semanas anteriores, colhidas no mesmo local, houver, no
máximo, 500 coliformes fecais (termotolerantes) ou 400 Escherichia Coli ou 50
Enterococos por 100 mililitros;
c) Satisfatória: quando em 80% ou mais de um conjunto de amostras
obtidas em cada uma das cinco semanas anteriores, colhidas no mesmo local, houver, no
máximo 1.000 coliformes fecais (termotolerantes) ou 800 Escherichia Coli ou 100
Enterococos por 100 mililitros.
Essas águas serão consideradas impróprias para o trecho avaliado, se for
verificada uma das seguintes ocorrências:
a) Não atendimento aos critérios estabelecidos para as águas próprias;
33
b) Valor obtido na última amostragem for superior a 2500 coliformes fecais
(termotolerantes) ou 2000 Escherichia coli ou 400 Enterococos por 100 mililitros;
c) Incidência elevada ou anormal, na região, de enfermidades transmissíveis
por via hídrica, indicada pelas autoridades sanitárias;
d) Presença de resíduos ou despejos, sólidos ou líquidos, inclusive esgotos
sanitários, óleos graxos e outras substâncias, capazes de oferecer riscos à saúde ou
tornar desagradável a recreação;
e) pH < 6,0 ou pH > 9,0 (águas doces), à exceção das condições naturais;
f) Floração de algas ou outros organismos, até que se comprove que não
oferecem riscos à saúde humana;
g) Outros fatores que contra-indiquem, temporária ou permanentemente, o
exercício da recreação de contato primário.
Dos itens citados acima, serão consideradas, para efeito de análise na
aplicação, as restrições descritas nos itens “a” e “b”, para determinação da qualidade da
água. A implementação a ser desenvolvida será a base de dados da aplicação
especificada. Essa aplicação possui característica temporal e essa característica será
implementada separadamente utilizando-se conceitos de BDR e BDT e tendo como
SGBD o ORACLE. Essas duas implementações serão necessárias para se chegar ao
objetivo do projeto que é a comparação entre essas duas formas de implementação sob
aspectos qualitativos e quantitativos.
Para um melhor entendimento de como vai ser formada a base de dados,
segue a descrição da lista dos eventos que são disparados durante a criação da base.
Inicialmente, deve-se fazer o cadastramento das praias e de todos os trechos
dessas praias que serão analisados. Deve-se, também, cadastrar os responsáveis pelas
coletas. O responsável retira uma amostra de um determinado trecho de uma praia e,
após a análise, essa amostra é inserida na base de dados com algumas informações, tais
como: local, responsável, uma observação qualquer sobre a amostra e o valores dos
resultados da análise físico-química.
34
Para obter o resultado da análise de qualidade, são retiradas quatro amostras
por semana, em dias diferentes. Por exemplo, se duas amostras são inseridas no banco,
as duas possuem o mesmo código e se diferem no momento em que os dados de cada
uma foram inseridos no banco. Ao final da análise da qualidade da praia, um
procedimento é executado pelo usuário na base de dados, onde é informado como
parâmetro a data atual. A partir da avaliação das amostras realizadas nas cinco últimas
semanas, o procedimento retorna a qualidade dos trechos baseados nas determinações
do CONAMA. Por exemplo, se em 95% das amostras foram encontrados menos de 250
Coliformes Fecais, em 80 % das amostras foram encontrados entre 200 e 400
Escherichia Coli e que em 85% das amostras foram encontrados entre 25 e 50
Enterococos, o trecho é considerado muito bom.
A figura 5, mostra a chamada do procedimento responsável por retornar as
condições dos trechos de uma praia com base no histórico das amostras coletadas.
Figura 5 – Resultado do procedimento responsável por determinar a qualidade do trecho da praia
O código fonte da implementação dessa consulta pode ser visto no ANEXO
A.
4.2. Implementação de uma Base de Dados Temporal Utilizando o Oracle com o
Modelo Relacional.
Esta fase consiste na implementação de uma BDT a partir do
desenvolvimento de um BD relacional onde as características temporais são
representadas através de atributos comuns e sem a utilização de objetos já
implementados pelo SGBD. O modelo ER da aplicação e o seu dicionário de dados
podem ser vistos na figura 6 e tabela 3, respectivamente.
35
Praia
1..1 Responsável
1..1
Amostra
Possui
0..N 0..N
Recolhe
1..N
Possui
Trecho
1..1
Figura 6 – Modelo ER da aplicação
O modelo apresentado na figura 6 pode ser descrito da seguinte maneira:
cada praia analisada possui um ou mais trechos e cada um desses trechos pertence a
uma praia; de um trecho podem ser retiradas nenhuma ou várias amostras; cada
responsável pode retirar nenhuma ou muitas amostras de trechos diferentes, porém cada
amostra só é retirada por um responsável.
Tabela 3: Dicionário de dados da implementação ER
Praia CdPraia Number
NmPraia Varchar
DsLocal Varchar
Chave:CdPraia
Amostra CdAmostra Number
CdTrecho Number
CdPraia Number
CdResponsavel Varchar(20)
NuColiformes Number
36
NuEscherichia Number
NuEnterococos Number
DsObservacao Varchar(255)
TempoTransacao Date
Chave: CdAmostra,
TempoTransacao
Responsavel CdResponsavel Varchar(20)
NmResponsavel Varchar(100)
DsCargo Varchar(100)
TempoTransacao Date
Chave: CdResponsavel, TempoTransacao
Trecho CdTrecho Number
CdPraia Number
NmTrecho Varchar
Chave Composta: CdTrecho, CdPraia
A tabela 3 apresenta o dicionário de dados da aplicação. No dicionário de
dados pode-se ter uma visão geral das tabelas que formam a base de dados, onde é
apresentado o nome de cada tabela junto ao nome e tipo de cada atributo. Pode-se notar
através da figura 5 que as tabelas tAmostra e tResponsavel possuem um atributo
chamado TempoTransacao do tipo data. Esse atributo é utilizado na implementação de
temporalidade.
O atributo TempoTransacao guarda o momento em que a informação foi
inserida na base de dados, caracterizando-se assim uma base de dados históricos por
tempo de transação. A integridade desse atributo é garantida através da implementação
de gatilhos. Para cada uma dessas tabelas foi criado um trigger do tipo AFTER que é
disparado pelo comando insert, garantindo que a data inserida no atributo
TempoTransacao é a data do sistema no momento da inserção, e pelo comando update,
garantindo que os atributos representando os códigos e as datas de inserção não sejam
alterados.
O código fonte de geração das tabelas e do gatilho em questão podem ser
encontrados no ANEXO B.
37
4.3. Implementação de uma Base de Dados Temporal utilizando o Oracle Time
Series com o Modelo Temporal.
A mesma aplicação descrita anteriormente pode ser implementada no
modelo temporal, utilizando-se recursos de uma extensão do SGBD Oracle chamada
Time Series, juntamente com uma modelagem de dados utilizando o modelo TempER já
definido anteriormente.
“O Time Series é uma extensão do Oracle que provê
armazenamento e recuperação de dados baseados em
tempo através de object data types (ODTs). Este
pacote oferece um conjunto básico de funções e tipos
de dados que acompanham a ferramenta. Estes tipos
de dados, juntamente com as funções, permitem
administrar e processar dados temporais de maneira
mais conveniente do que seria possível usando
unicamente tipos de dados e funções definidas pelo
usuário.” (ORACLE, 1999)
A figura 7 apresenta o modelo de dados temporal TempER da aplicação. Por
ser um modelo que tem como base o modelo E/R pode-se notar alguma semelhança,
porém no modelo temporal é possível visualizar quais os objetos, relacionamentos e
atributos temporais que formam a base de dados. Um atributo é considerado temporal
quando ele é responsável por armazenar os dados que serão trabalhados procedimentos
que realizaram pesquisas nesse banco.
38
Praia P
Responsável T
1 .. 1
Amostra T 1 .. 1
P 0..N
Possui 0..N
T
Recolhe
1..N
T
Trecho P
Possui
1 .. 1
Figura 7 - Modelo tempER da aplicação
Através do modelo apresentado na figura 7 é possível saber quais os objetos
que possuem características de temporalidade. Pode-se notar que as entidades Amostra e
Responsavel possuem características temporais: a entidade Amostra por possuir os
dados históricos da análise das amostras e a entidade Responsavel por possuir dados
históricos do responsável. A tabela 4 descreve o dicionário de dados do modelo
temporal. Através desse dicionário é possível saber quais os atributos considerados
temporais nas entidades.
Tabela 4 - Dicionário de Dados da base de dados temporal utilizando modelo TempER
Praia CdPraia Number Intemporal
NmPraia Varchar Intemporal
DsLocal Varchar Intemporal
Chave:CdPraia
Amostra CdAmostra Number Intemporal
CdTrecho Number Intemporal
CdPraia Number Intemporal
39
CdResponsavel Varchar(20) Intemporal
NuColiformes Number Temporal
NuEscherichia Number Temporal
NuEnterococos Number Temporal
DsObservacao Varchar(255) Intemporal
tsTamp Date Intemporal
Chave: CdAmostra, tsTamp
Responsável CdResponsavel Varchar(20) Intemporal
NmResponsavel Varchar(100) Intemporal
DsCargo Varchar(100) Temporal
tsTamp Date
Chave: CdResponsavel, tsTamp
Trecho CdTrecho Number Intemporal
CdPraia Number Intemporal
NmTrecho Varchar(100) Intemporal
Chave Composta: CdTrecho, CdPraia
Os scripts de criação dos objetos que não são considerados temporais, no
caso da aplicação em estudo as tabelas tPraia e tTrecho, são idênticos aos scripts da
implementação com o modelo relacional. Porém, a criação dos objetos com
características temporais são feitas através do Oracle Time Series. Esses scripts podem
ser vistos no ANEXO C.
Inicialmente é necessária a criação de um grupo a partir de procedimentos
para administração da criação do Time Series Group, onde são implementados todos os
objetos necessários ao esquema do Time Series. Durante a criação desses objetos pode-
se escolher por aceitar os valores padrões para o nome dos objetos.
Para cada entidade com aspecto temporal é necessário criar um grupo que é
composto por três tabelas, um gatilho e uma visão devido ao fato do oracle implementar
a temporalidade a partir de um BDR. Caso se assuma o valor padrão para o grupo, os
nomes das tabelas são compostos pelo nome do grupo mais o simbolo “_” e uma
terminação que pode ser TAB, MAP, CAL e RVW, responsáveis por identificar a
40
função da tabela. A definição das colunas da tabela que vão conter os dados é também
feita durante a criação do grupo.
A tabela com terminação TAB possui os dados da aplicação; a terminação
MAP associa uma série de tempo com um calendário; CAL é a tabela que possui a
definição dos calendários da aplicação; e, por fim, a terminação RVW identifica a visão
criada para manipular a tabela com terminação TAB, através de gatilho. Com isso, ao se
criar um grupo no Time Series são criados automaticamente os objetos GRUPO_TAB,
GRUPO_MAP, GRUPO_CAL, GRUPO_RVW e mais um gatilho responsável por
administrar o uso dos comandos de atualização insert, update e delete.
Outro objeto importante no Oracle Time Series é o calendário, a definição
desse objeto é inserida na tabela GRUPO_CAL. O calendário é utilizado quando se
utiliza um Time Series regular, ou seja, onde os dados chegam previsivelmente e em
intervalos pré-definidos. Maiores informações e o script de criação do calendário podem
ser encontradas no ANEXO D.
A implementação da base de dados da aplicação em questão foi feita sem um
calendário associado, porém a fim de se obter um melhor resultado no estudo
comparativo, a análise é feita nas duas situações: com um calendário associado e sem
um calendário associado.
41
5. ESTUDO COMPARATIVO
O estudo comparativo apresentado neste capítulo será realizado com base
nas implementações das bases de dados da aplicação estudada e com base no estudo e
pesquisa realizada sobre os assuntos comparados. A comparação será realizada fazendo-
se uma avaliação quantitativa, onde é analisado o desempenho das implementações, e
uma avaliação qualitativa.
O ambiente onde foram realizados os teste pode ser descrito da seguinte
forma: um microcomputador com processador ATHLON XP2000+, 1.67MHz de clock,
256 MB RAM, sistema operacional Windows XP Professional e o SGBD utilizado foi o
Oracle versão 8i, release 8.1.7.
No SGBD, foram criados dois esquemas, um deles com os objetos da
implementação no modelo relacional e o outro com os objetos da implementação no
modelo temporal. Para garantir a independência dos testes, cada esquema foi criado em
tablespaces e datafiles1 específicos, garantindo assim que os dados e tempos de consulta
de um modelo não interferissem no outro.
Vale salientar que a aplicação escolhida é representativa de um conjunto de
aplicações, cujas decisões são baseadas em dados históricos. Portanto, as conclusões
obtidas podem ser aplicadas neste contexto macro, sem perder a validade.
5.1 Análise Qualitativa
Seguindo o estudo comparativo, neste tópico é feita uma análise qualitativa
da implementação realizada. Essa análise faz-se necessária durante a fase de análise de
um projeto, pois nesse tópico são discutidas questões como custos, complexidade e
interferência no prazo de entrega do projeto. Com um estudo desse tipo, um
1
Tablespaces e Datafiles são objetos de organização de dados do SGBD Oracle (1999)
42
administrador de banco de dados (DBA) ou um gerente de projeto poderão decidir pela
adoção de um modelo ou de outro, a depender dos aspectos relevantes de cada caso.
Com relação aos custos do desenvolvimento de uma base de dados
temporal, pode-se notar que, devido ao fato do modelo relacional ser mais difundido
que o modelo temporal, há uma tendência que os custos utilizando o modelo relacional
sejam menores já que não haverá necessidade de se aprender um novo modelo de dados
e nem uma nova ferramenta de criação da base de dados, apenas é necessário adquirir o
conhecimento de como deverá funcionar essa base. Por outro lado, através do modelo
temporal seria necessário aprender a modelar os dados a partir de um novo modelo, no
caso da aplicação deste projeto o modelo TempER, e a utilização de uma ferramenta
nova para a criação da base além de adquirir o conhecimento de como funciona uma
base de dados temporal. A depender do caso, esse novo aprendizado poderia gerar
custos de treinamento de pessoal ou contratação de um novo recurso que já tivesse o
conhecimento necessário, onerando o projeto.
Adicionalmente, a partir das implementações realizadas é possível analisar a
complexidade na criação da base de dados com os modelos estudados. No caso do
modelo relacional, para se criar a base, levando-se em conta que o banco de dados já
estava com usuários, datafiles e tablespaces configurados, foi necessário a criação das
tabelas e de um gatilho em cada tabela com o recurso de tempo, responsável por garantir
a característica de tempo de transação nessas tabelas. No caso do modelo temporal, para
se garantir a característica de tempo de transação em uma tabela, é necessário se criar
um grupo que é composto por outras três tabelas, uma visão e um gatilho. Os comandos
de manipulação de dados de inserção, atualização e remoção possuem a mesma sintaxe
em ambos os modelos estudados, a exceção é o comando de seleção de dados. Neste
último caso, a sintaxe é diferente entre os dois modelos, a fim de utilizar as funções de
seleção de dados disponibilizadas pelo Time Series. Essa nova sintaxe no caso do
modelo temporal não é tão intuitiva a ponto de ser assimilada com rapidez por um
programador, por exemplo, o que acarreta um tempo maior de adaptação. Com isso,
nota-se que a complexidade é maior na criação da base de dados através do modelo
temporal.
43
Como conseqüência dos problemas de custo e complexidade da utilização
de um modelo temporal para criação de uma base de dados temporal temos um outro
problema que é a determinação do prazo de entrega de um projeto deste tipo. No caso
da aplicação estudada neste projeto, o tempo gasto para se treinar uma equipe para
utilizar o Oracle Time Series junto com o modelo de dados temporal poderia acarretar
problemas de prazo de entrega da aplicação. Caso se utilize o modelo relacional, a
aplicação poderia ser desenvolvida mais rapidamente, já que tais conhecimentos são de
domínio dos desenvolvedores. Contudo, em decorrência disso, não seria possível a
utilização de calendário e nenhuma das funções disponíveis no Time Series, limitando
as funcionalidades disponíveis.
Por outro lado, apesar de o modelo temporal ser mais complexo, ele
apresenta algumas vantagens sobre o modelo relacional. Através do modelo de dados
TempER é possível se determinar quais os objetos, tabelas e relacionamentos, que são
temporais, além dos atributos que são explicitamente definidos como temporal ou
intemporal o que torna a visualização do modelo mais específica. Com isso, além de o
problema ser representado de forma real, o entendimento da solução é mais efetivo.
Outra vantagem (talvez a que pode até justificar o uso do modelo temporal
junto com o Oracle Time Series) é o objeto Calendário (Calendar), responsável por
controlar a regularidade com que os dados são inseridos na base de dados. O Calendário
é utilizado para garantir que uma base de dados temporal seja considerada regular,
limitando os dados temporais armazenados. No caso da aplicação estudada, um
calendário com granularidade de dias poderia determinar quais os dias da semana em
que a base de dados aceitaria inserções de dados, implementando uma facilidade que
seria complexa na base relacional.
Não obstante, o Oracle Time Series disponibiliza uma série de funções
que podem ser utilizadas em comandos de seleção de dados que podem tornar a
pesquisa na base de dados mais prática do que se fosse feita através do modelo
relacional, o que poderia ser considerado como uma outra vantagem. Dentre essas
funções pode-se citar (ORACLE, 1999):
44
Cavg – utilizada para retornar a media de uma série de tempo, por
exemplo, retirar a média das vendas que ocorrerão todos os dias entre 01/06/2005 até
30/05/2005;
Cmax – utilizada para retornar o maior valor de uma série de tempo;
Cmin – retorna o menor valor de cada série de tempo;
Csum – retorna a soma dos valores de cada série de tempo;
Cprod – retorna o produto da multiplicação dos valores de cada série de
tempo.
Por fim, com base na análise qualitativa que foi realizada, pode-se concluir
que o uso do modelo temporal com o Oracle Time Series é justificado apenas se for
necessária a utilização do calendário e das funções de seleção de dados. No caso da
aplicação estudada, o uso do modelo temporal não é justificado, já que o uso do objeto
calendário não é obrigatório na aplicação e não é necessário o uso das funções do Time
Series. Neste caso, os impactos dessa implementação seriam mais representativos que
suas vantagens.
5.2. Análise Quantitativa
A análise quantitativa visa avaliar o desempenho das implementações. Para
se chegar aos resultados foram executados em um primeiro momento 1.000 (um mil),
em outro 2.000 (duas mil) e por último 4.000 (quatro mil) operações de cada tipo:
inserções, exclusões e atualizações. Foi registrado também o espaço ocupado com cada
implementação após 4.000 operações de inserção, a fim de se identificar qual a
implementação que requer mais recurso para ser utilizada. Foram realizados três testes
com cada quantidade de operações da seguinte maneira: os grupos de comandos foram
executados três vezes na base de dados no modelo relacional e seis vezes na base de
dados no modelo temporal, em momentos diferentes, sendo que três vezes os comandos
45
foram executados com a base de dados sem um calendário associado e três vezes com
um calendário associado.
Para garantir que não houvesse interferência de outros aspectos nos
resultados, os testes foram realizados no mesmo ambiente, e logo após a inicialização da
máquina, para restringir o impacto de outros processos executando. Apesar de ter
realizado três testes em momentos diferentes, as tabelas abaixo mostram apenas o
resultado de um dos testes, isso porque os resultados de todos os testes foram
semelhantes.
Tabela 5 – resultados após execução dos comandos de Insert, para todas as quantidades de dados,
em todas as implementações
Tabela 6 – resultados após execução dos comandos de Update, para todas as quantidades de dados,
em todas as implementações
46
Tabela 7 – resultados após execução dos comandos de Delete, para todas as quantidades de dados,
em todas as implementações
Figura 8 – Registro do espaço utilizado após 4000 inserções na tabela tAmostra no BDR
Figura 9 – Registro do espaço utilizado após 4000 inserções na tabela tsAmostra no BDT
Pode-se perceber nas figuras 8 e 9 que o espaço utilizado no modelo
relacional, 0,672 MB, é significativamente inferior em relação ao modelo temporal,
1,414 MB, chegando a ter quase metade do espaço ocupado.
Com base nas tabelas 5, 6 e 7 é possível montar os gráficos das figura 10, 11
e 12 com os valores dos tempos das operações em segundos por quantidade de
operações, para facilitar a visualização.
47
Tempo em Segundos - 1000 Registros
14
12
10
Modelo Relacional
8
Modelo Temporal Com
6 Calendário
Modelo Temporal Sem
4 Calendário
2
0
Inserir Alterar Apagar
Figura 10 – Resumo do estudo comparativo de desempenho com 1000 registros
Tempo em Segundos - 2000 Registros
25
20
Modelo Relacional
15
Modelo Temporal Com
Calendário
10
Modelo Temporal Sem
Calendário
5
0
Inserir Alterar Apagar
Figura 11 – Resumo do estudo comparativo de desempenho com 2000 registros
48
Tempo em Segundos - 4000 Registros
45
40
35
30 Modelo Relacional
25
Modelo Temporal Com
20 Calendário
15 Modelo Temporal Sem
Calendário
10
5
0
Inserir Alterar Apagar
Figura 12 – Resumo do estudo comparativo de desempenho com 4000 registros
Conforme observado nas figuras 10, 11 e 12 nota-se que as operações
realizadas no modelo temporal com calendário associado, independentemente da
quantidade de registros, são as que consomem mais tempo e as operações no modelo
relacional são as mais rápidas. Apesar de existir uma diferença entre os modelos, o
resultado não é grande o suficiente a ponto de afetar o desempenho da aplicação como
um todo, principalmente vislumbrando que o volume de transações esperado na dada
aplicação não é tão significativo.
De acordo com a análise quantitativa realizada, pode-se concluir que a
diferença de desempenho entre modelo relacional e do modelo temporal com o Time
Series, levando-se em conta o tempo de execução das operações, não precisa ser levado
em consideração no momento de decidir por um ou outro modelo, já que essa diferença
ínfima entre as operações nos modelos estudados não justifica a opção por um dos
modelos. Porém, levando-se em conta o espaço ocupado pelas implementações
comparadas, nota-se que há uma grande diferença a favor do modelo relacional e que
pode justificar o uso do modelo caso a variável espaço utilizado seja importante no
projeto.
49
6. CONCLUSÃO
Neste projeto, foi realizado um estudo comparativo da modelagem e
desenvolvimento de uma base de dados temporal utilizando o modelo de dados
relacional e o modelo de dados temporal, juntamente com uma extensão do SGBD
Oracle chamada Time Series. Essa comparação tem como objetivo determinar qual dos
modelos seria o mais indicado tendo como base de estudo uma aplicação desenvolvida
para esse projeto, que tem como fim determinar a qualidade da água das praias com
base em dados históricos.
Inicialmente, foi apresentada uma maneira de implementar uma base de
dados temporal com um modelo de dados relacional e foi visto que essa implementação
pode ser feita através de gatilhos, pois assim as verificações e restrições necessárias para
garantir a característica de tempo de transação seriam realizadas automaticamente. Em
um outro momento foram apresentados conceitos e exemplos de BDT, onde foi possível
entender suas definições e quais os tipos que podem ser implementados.
O estudo comparativo realizado neste projeto foi dividido em duas etapas:
na primeira foi feita uma análise qualitativa, que visa determinar as dificuldades de cada
implementação, e na segunda uma análise quantitativa, que visa analisar o desempenho
de cada implementação.
Com base nas análises realizadas e nos resultados obtidos, pode-se concluir
que a implementação de uma base de dados temporal, utilizando-se o modelo de dados
temporal juntamente com a extensão do SGBD Oracle, só é a mais indicada se for
conveniente a utilização de um calendário associado às séries de tempo da base de
dados e o espaço utilizado pelo BD não seja uma variável com muita importância, já
que os impactos no projeto são relevantes e não há diferenças de desempenho nos dois
modelos, exceto pelo espaço ocupado. Uma vez que a aplicação desenvolvida neste
projeto não precisa necessariamente de um calendário, a implementação mais indicada é
através do modelo de dados relacional, evitando os inconvenientes do uso de um BDT.
50
A partir dos estudos feitos, pode ser sugerido como trabalho futuro a
realização de um estudo comparativo utilizando a mesma metodologia que este trabalho,
porém em uma base de dados que utilize esquema de versões.
51
7. REFERÊNCIAS BIBLIOGRÁFICAS
ANTUNES, D.C. Modelagem temporal de sistemas: uma abordagem fundamentada em
redes de Petri. Porto Alegre, CPGCC da UFRGS, 1997. Dissertação de mestrado.
CONAMA, Conselho Nacional do Meio Ambiente - Resolução Nº 274 De 29 De
Novembro 2000, Disponível em:
http://www.mma.gov.br/port/conama/res/res00/res27400.html, Acesso em: 24/04/2005
CHEN, P. The entity-relationship model: Toward a unified view of data, 1976.
DATE, C.J. Introdução a sistemas de Bancos de Dados – tradução da 8ª edição
americana. Editora Campus. 2003
EDELWEISS, Nina. Modelagem de aspectos temporais de sistemas de informação.
Recife, IX Escola de Computação – UFPE, 1994.
EDELWEISS, Nina. Bancos de Dados Temporais: Teoria e Prática. XVII Jornada de
Atualização em Informática – JAI. XVIII SBC. Belo Horizonte, 1998.
HEUSER, A. Carlos. 1998. Uma proposta de modelagem de dados temporal.
Disponível em: http:
//www.pr.gov.br/celepar/celepar/batebyte/edicoes/1998/bb/5/dados.htm, Acesso em:
10/11/2004.
HUBLER, Patricia N. Definição de um Gerenciador para o Modelo de Dados Temporal
TF-ORM - Dissertação para obtenção do grau de Mestre. Porto Alegre: UFRGS. 2001.
Disponível em:
http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana99/Hubler/hubler.html, Acesso
em: 01/12/2004.
KORTH, Henry F.; SILBERSCHATZ, Abraham. 1995. Sistemas de bancos de dados.
2º ed. São Paulo: Makron Books.
52
MOREIRA, V.; EDELWEISS, N. Queries to Temporal Databases Supporting Schema
Versioning. In: SIMPÓSIO BRASILEIRO DE BANCO DE DADOS, SBBD, 14., 1999,
Florianópolis. Anais...Florianópolis: UFSC, 1999. p. 299-313.
OLIVEIRA, José Palazzo M., EDELWEISS, Nina. Modelagem de Aspectos Temporais
de Sistemas de Informação. IX Escola de Computação, Recife, 1994.
ORACLE 8i Time Series User’s Guide, Release 8.1.5 A67294-01, Disponível em
http://www.csee.umbc.edu/help/oracle8/inter.815/a67294.pdf. Acessado em 19/05/2005.
POSSER, Juliana de Morais. Temporalidade em Sistema de Informação - Trabalho
Final de Graduação, Santa Maria:Unifra, 2001
RAMALHO, José A. A., Série Ramalho Oracle 8i – 5ª edição, 2001.
SILVA, R.C.; TRAINA JR. C. Armazenagem e Gerenciamento de Informações
Temporais em um Modelo de Dados Orientado a Objetos. In: 7º Simpósio Brasileiro de
Banco de Dados. Anais... Porto Alegre: Instituto de Informática da UFRGS, 1992.
SNODGRASS, R.; et al. Towards an Infrastructure for Temporal Databases. Report of
an Invitational ARPA/NSF Workshop. March, 1994.
TANSEL, A.U. Modelling Temporal Data. Information and Software Technology. V.
32, n. 8, p.514-520, 1990.
53
ANEXO A
Código Fonte da Consulta na Base de Dados Relacional e Temporal
/*******************************************************************
Procedimento responsável por retornar a situação do trecho.
A situação pode ser excelente, muito boa, satisfatória e imprópria,
com base nos dados pesquisados na internet no site do CONAMA.
Parâmetro:pcdpraia do tipo number
Descrição: Código da praia
Parâmetro: pdataFim do tipo date
Descrição: Data a partir do qual serão feitos os cálculos para se chegar
às cinco semanas anteriores.
*******************************************************************/
create or replace procedure sp_qualidade (pcdpraia number, pdataFim date)
IS
-- Declaração
qtamostras Number;
C250 Number;
C500 Number;
C1000 Number;
C2500 Number;
NColiformes Number;
DsColiformes varchar2(200);
E200 Number;
E400 Number;
E800 Number;
E2000 Number;
Nescherichia Number;
Dsescherichia varchar2(200);
EN25 Number;
EN50 Number;
EN100 Number;
EN400 Number;
Nenterococos number;
Dsenterococos varchar2(200);
DsSituacao varchar2(200);
Cnucoliformes tsamostra.nucoliformes%type;
Cnuescherichia tsamostra.nuescherichia%type;
Cnuenterococos tsamostra.nuenterococos%type;
ptrecho tsamostra.cdtrecho%type;
pdataIni date;
54
--Declaração de cursor responsável por retornar os trechos da praia pesquisada.
CURSOR cur_praia(ppraia number)
IS
Select cdtrecho from ttrecho where cdpraia = ppraia;
--Declaração de cursor responsável por retornar a quantidade de nucoliformes,
--nuescherichia, nuenterococos das amostras realizadas.
/*******************************************************************
NESSE PONTO HÁ UMA DIFERENÇA ENTRE OS DOIS MODELOS
O COMANDO DE SELEÇÃO A BAIXO É PARA O MODELO TEMPORAL
CURSOR cur_qualidade(pcdtrecho number, pInicio date, pFim date)
IS
Select nucoliformes, nuescherichia, nuenterococos from tsamostra_rvw
where cdtrecho = pcdtrecho and tstamp between pInicio and pFim;
O COMANDO DE SELEÇÃO A BAIXO É PARA O MODELO RELACIONAL
*******************************************************************/
CURSOR cur_qualidade(pcdtrecho number, pInicio date, pFim date)
IS
Select nucoliformes, nuescherichia, nuenterococos from tsamostra
where cdtrecho = pcdtrecho and tempotransacao between pInicio and pFim;
begin
C250 := 0;
C500 := 0;
C1000 := 0;
C2500 := 0;
E200 := 0;
E400 := 0;
E800 := 0;
E2000 := 0;
EN25 := 0;
EN50 := 0;
EN100 := 0;
EN400 := 0;
DsSituacao := '';
qtamostras:=0;
--Cálculo da data de início das cinco semanas pesquisadas.
--Realizado a partir da data fornecida como parâmetro
select pdataFim - 28 into pdataIni from dual;
DBMS_OUTPUT.ENABLE;
Open cur_praia(pcdpraia);
--Loop responsável por informar os trechos da praia
LOOP
FETCH cur_praia INTO ptrecho;
EXIT When cur_praia%notFOUND;
55
Open cur_qualidade(ptrecho, pdataIni , pdataFim);
--No loop abaixo é feito o cálculo de quantas vezes aparece a
quantidade de
--nucoliformes, nuescherichia e nuenterococos em uma
determinada faixa de valores
--que é utilizado calcular a porcentagem em que aparecem.
LOOP
FETCH cur_qualidade INTO Cnucoliformes,
Cnuescherichia, Cnuenterococos;
EXIT When cur_qualidade%notFOUND;
qtamostras := qtamostras + 1;
if (Cnucoliformes <= 250) then
C250 := C250 + 1;
end if;
if (Cnucoliformes > 250) then
if (Cnucoliformes <= 500) then
C500 := C500 + 1;
end if;
end if;
if (Cnucoliformes > 500) then
if (Cnucoliformes <= 1000) then
C1000 := C1000 + 1;
end if;
end if;
if (Cnucoliformes > 2500) then
C2500 := C2500 + 1;
end if;
if (Cnuescherichia <= 200) then
E200 := E200 + 1;
end if;
if (Cnuescherichia > 200) then
if (Cnuescherichia <= 400) then
E400 := E400 + 1;
end if;
end if;
if (Cnuescherichia > 400) then
if (Cnuescherichia <= 800) then
E800 := E800 + 1;
end if;
end if;
if (Cnuescherichia > 2000) then
E2000 := E2000 + 1;
end if;
if (Cnuenterococos <= 25) then
EN25 := EN25 + 1;
end if;
if (Cnuenterococos > 25) then
56
if (Cnuenterococos <= 50) then
EN50 := EN50 + 1;
end if;
end if;
if (Cnuenterococos > 50) then
if (Cnuenterococos <= 100) then
EN100 := EN100 + 1;
end if;
end if;
if (Cnuenterococos > 400) then
EN400 := EN400 + 1;
end if;
END LOOP;
--Calculo da porcentagem em que aparecem as bactérias pesquisadas
--para se determinar a situação do trecho da praia.
if qtamostras <> 0 then
C250 := ROUND((C250 * 100)/qtamostras, 2);
C500 := ROUND((C500 * 100)/qtamostras, 2);
C1000 := ROUND((C1000 * 100)/qtamostras, 2);
C2500 := ROUND((C2500 * 100)/qtamostras, 2);
E200 := ROUND((E200 * 100)/qtamostras, 2);
E400 := ROUND((E400 * 100)/qtamostras, 2);
E800 := ROUND((E800 * 100)/qtamostras, 2);
E2000 := ROUND((E2000 * 100)/qtamostras, 2);
EN25 := ROUND((EN25 * 100)/qtamostras, 2);
EN50 := ROUND((EN50 * 100)/qtamostras, 2);
EN100 := ROUND((EN100 * 100)/qtamostras, 2);
EN400 := ROUND((EN400 * 100)/qtamostras, 2);
NColiformes := C250;
DsSituacao := 'Excelente';
if C500 >= NColiformes then
NColiformes := C500;
DsSituacao := 'Muito Bom';
end if;
if C1000 >= NColiformes then
NColiformes := C1000;
DsSituacao := 'Satisfatório';
end if;
if C2500 >= NColiformes then
NColiformes := C2500;
DsSituacao := 'Impróprio';
end if;
Nescherichia := E200;
Dsescherichia := '200';
if E400 >= Nescherichia then
Nescherichia := E400;
if DsSituacao = 'Excelente' then
DsSituacao := 'Muito Bom';
57
end if;
end if;
if E800 >= Nescherichia then
Nescherichia := E800;
if (DsSituacao = 'Excelente') or (DsSituacao = 'Muito
Boa') then
DsSituacao := 'Satisfatório';
end if;
end if;
if E2000 >= Nescherichia then
Nescherichia := E2000;
DsSituacao := 'Impróprio';
end if;
Nenterococos := EN25;
if EN50 >= Nenterococos then
Nenterococos := EN50;
if DsSituacao = 'Excelente' then
DsSituacao := 'Muito Bom';
end if;
end if;
if EN100 >= Nenterococos then
Nenterococos := EN100;
if (DsSituacao = 'Excelente') or (DsSituacao = 'Muito
Boa') then
DsSituacao := 'Satisfatório';
end if;
end if;
if EN400 >= Nenterococos then
Nenterococos := EN400;
DsSituacao := 'Impróprio';
end if;
--Retorno do procedimento
DBMS_OUTPUT.PUT_LINE('Classificação do trecho
'||ptrecho||': '||DsSituacao);
--DBMS_OUTPUT.PUT_LINE(Dsescherichia);
--DBMS_OUTPUT.PUT_LINE(Dsenterococos);
end if;
C250 := 0;
C500 := 0;
C1000 := 0;
C2500 := 0;
E200 := 0;
E400 := 0;
E800 := 0;
E2000 := 0;
EN25 := 0;
58
EN50 := 0;
EN100 := 0;
EN400 := 0;
DsSituacao := '';
qtamostras:=0;
Close cur_qualidade;
END LOOP;
Close cur_praia;
end;
59
ANEXO B
Código Fonte da Geração dos objetos na Base de Dados Relacional
-- Criação das TableSpaces no Modelo Relacional
Tablespace responsável por armazenar os índices
CREATE TABLESPACE "PROJETOIDX"
LOGGING
DATAFILE 'C:\ORACLE\ORADATA\PROJETO\PROJETOIDX.DBF' SIZE 5M
REUSE DEFAULT
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 )
Tablespace responsável por armazenar as tabelas
CREATE TABLESPACE "PROJETOTBL"
LOGGING
DATAFILE 'C:\ORACLE\ORADATA\PROJETO\PROJETOTBL.DBF' SIZE 5M
REUSE DEFAULT
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 )
Tablespace responsável por armazenar os objetos temporários
CREATE TABLESPACE "PROJETOTMP"
LOGGING
DATAFILE 'C:\ORACLE\ORADATA\PROJETO\PROJETOTMP.DBF' SIZE 5M
REUSE DEFAULT
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 )
Criação do Usuário que tem acesso à base relacional
CREATE USER "WAGNER" PROFILE "DEFAULT" IDENTIFIED BY "1234"
DEFAULT
TABLESPACE "PROJETOTBL" TEMPORARY
TABLESPACE "PROJETOTMP" ACCOUNT UNLOCK
Criação da tabela tpraia, responsável por armazenar as informações sobre as praias
CREATE TABLE "WAGNER"."TPRAIA"("CDPRAIA" NUMBER NOT NULL,
"NMPRAIA" VARCHAR2(100) NOT NULL, "DSLOCAL" VARCHAR2(100)
NOT
60
NULL,
CONSTRAINT "TPRAIA_PK_CDPRAIA" PRIMARY KEY("CDPRAIA") USING
INDEX
TABLESPACE "PROJETOIDX"
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10
INITRANS 2 MAXTRANS 255)
TABLESPACE "PROJETOTBL" PCTFREE 10 PCTUSED 40 INITRANS 1
MAXTRANS 255
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1)
LOGGING
Criação da tabela ttrecho, responsável por armazenar as informações sobre os trechos
das praias
CREATE TABLE "WAGNER"."TTRECHO"("CDTRECHO" NUMBER NOT NULL,
"CDPRAIA" NUMBER NOT NULL, "NMTRECHO" VARCHAR2(100) NOT
NULL,
CONSTRAINT "FK_TPRAIA_TTRECHO" FOREIGN KEY("CDPRAIA")
REFERENCES "WAGNER"."TPRAIA"("CDPRAIA"),
CONSTRAINT "TTRECHO_PK_CDTRECHO_CDPRAIA" PRIMARY
KEY("CDTRECHO",
"CDPRAIA") USING
INDEX
TABLESPACE "PROJETOIDX"
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10
INITRANS 2 MAXTRANS 255)
TABLESPACE "PROJETOTBL" PCTFREE 10 PCTUSED 40 INITRANS 1
MAXTRANS 255
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1)
LOGGING
Criação da tabela tresponsavel, responsável por armazenar as informações sobre os
responsáveis pela coleta da amostra
CREATE TABLE "WAGNER"."TRESPONSAVEL"("CDRESPONSAVEL"
VARCHAR2(
20) NOT NULL, "NMRESPONSAVEL" VARCHAR2(100) NOT NULL,
"DSCARGO"
VARCHAR2(100) NOT NULL, "TEMPOTRANSACAO" DATE DEFAULT
sysdate
NOT NULL,
CONSTRAINT "TRESPONSAVEL_PK" PRIMARY KEY("CDRESPONSAVEL")
USING
INDEX
TABLESPACE "PROJETOIDX"
61
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10
INITRANS 2 MAXTRANS 255)
TABLESPACE "PROJETOTBL" PCTFREE 10 PCTUSED 40 INITRANS 1
MAXTRANS 255
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1)
LOGGING
Criação da tabela tsamostra, responsável por armazenar as informações sobre as
amostras retiradas dos diversos trechos das praias.
CREATE TABLE "WAGNER"."TSAMOSTRA"("CDAMOSTRA" VARCHAR2(20)
NOT
NULL, "CDTRECHO" NUMBER, "CDPRAIA" NUMBER, "CDRESPONSAVEL"
VARCHAR2(20), "NUCOLIFORMES" NUMBER, "NUESCHERICHIA"
NUMBER,
"NUENTEROCOCOS" NUMBER, "DSOBSERVACAO" VARCHAR2(255),
"TEMPOTRANSACAO" DATE DEFAULT sysdate NOT NULL,
CONSTRAINT "FK_TAMOSTRA_TRESPONSAVEL" FOREIGN KEY(
"CDRESPONSAVEL")
REFERENCES "WAGNER"."TRESPONSAVEL"("CDRESPONSAVEL"),
CONSTRAINT "FK_TAMOSTRA_TTRECHO" FOREIGN KEY("CDTRECHO",
"CDPRAIA")
REFERENCES "WAGNER"."TTRECHO"("CDTRECHO", "CDPRAIA"),
CONSTRAINT "PK_TSAMOSTRA" PRIMARY KEY("CDAMOSTRA",
"TEMPOTRANSACAO") USING
INDEX
TABLESPACE "PROJETOTBL"
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10
INITRANS 2 MAXTRANS 255)
TABLESPACE "PROJETOTBL" PCTFREE 10 PCTUSED 40 INITRANS 1
MAXTRANS 255
STORAGE ( INITIAL 40K NEXT 96K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1)
LOGGING
Gatilho criado para implementar a temporalidade através do modelo relacional.
Associado as operações de insert e update na tabela tsamostra
CREATE OR REPLACE TRIGGER TSAMOSTRA_TRG BEFORE
INSERT OR
UPDATE
ON "TSAMOSTRA"
FOR EACH ROW
BEGIN
62
--se for insert o registro do momento da inserção é feita com base na data do servidor
IF INSERTING THEN
:NEW.TEMPOTRANSACAO := TO_DATE(SYSDATE,
‘DD/MM/YYYY’);
END IF;
--se for update não permite que a data e o código sejam alterados
IF UPDATING THEN
IF :NEW.TEMPOTRANSACAO <>:OLD.TEMPOTRANSACAO
THEN
raise_application_error(-20000, ‘Não é possível alterar o registro
do tempo de transação’);
END IF;
IF :NEW.CDAMOSTRA<>:OLD.CDAMOSTRA THEN
raise_application_error(-20000, ‘Não é possível alterar o Código
da amostra’);
END IF;
END IF;
END;
Gatilho criado para implementar a temporalidade através do modelo relacional.
Associado as operações de insert e update na tabela tresponsavel
CREATE OR REPLACE TRIGGER TSAMOSTRA_TRG BEFORE
INSERT OR
UPDATE
ON "TRESPONSAVEL"
FOR EACH ROW
BEGIN
--se for insert, o registro do momento da inserção é feita com base na data do servidor
IF INSERTING THEN
:NEW.TEMPOTRANSACAO := TO_DATE(SYSDATE,
‘DD/MM/YYYY’);
END IF;
--se for update não permite que a data e o código sejam alterados
IF UPDATING THEN
IF :NEW.TEMPOTRANSACAO <>:OLD.TEMPOTRANSACAO
THEN
raise_application_error(-20000, ‘Não é possível alterar o registro
do tempo de transação’);
END IF;
IF :NEW.CDRESPONSAVEL<>:OLD.CDRESPONSAVEL THEN
raise_application_error(-20000, ‘Não é possível alterar o Código
do responsável’);
END IF;
END IF;
END;
63
ANEXO C
Código Fonte da Geração dos objetos na Base de Dados Temporal
-- Criacao das TableSpaces no Modelo Temporal
Tablspace responsável por armazenar os indices
CREATE TABLESPACE "TEMPORALIDX"
LOGGING
DATAFILE 'C:\ORACLE\ORADATA\PROJETO\TEMPORALIDX.DBF' SIZE 5M
REUSE EXTENT MANAGEMENT LOCAL
Tablspace responsável por armazenar as tabelas
CREATE TABLESPACE "TEMPORALTBL"
LOGGING
DATAFILE 'C:\ORACLE\ORADATA\PROJETO\TEMPORALTBL.DBF' SIZE 5M
REUSE DEFAULT
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 )
Tablespace responsável por armazenar os objetos temporários
CREATE TABLESPACE "TEMPORALTMP"
LOGGING
DATAFILE 'C:\ORACLE\ORADATA\PROJETO\TEMPORALTMP.DBF' SIZE 5M
REUSE DEFAULT
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 )
Criação do Usuário que tem acesso à base temporal
CREATE USER "TEMPORAL" PROFILE "DEFAULT" IDENTIFIED BY
"1234" DEFAULT
TABLESPACE "TEMPORALTBL" TEMPORARY
TABLESPACE "TEMPORALTMP" ACCOUNT UNLOCK
Criação da tabela tpraia, responsável por armazenar as informações sobre as praias
Criação idêntica ao do modelo relacional. com alterações apenas de tablespace e usuário
dono do objeto
CREATE TABLE "TEMPORAL"."TPRAIA"("CDPRAIA" NUMBER NOT NULL,
"NMPRAIA" VARCHAR2(100) NOT NULL, "DSLOCAL" VARCHAR2(100)
NOT
NULL,
CONSTRAINT "TPRAIA_PK_CDPRAIA" PRIMARY KEY("CDPRAIA") USING
INDEX
TABLESPACE "TEMPORALIDX"
64
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10
INITRANS 2 MAXTRANS 255)
TABLESPACE "TEMPORALTBL" PCTFREE 10 PCTUSED 40 INITRANS 1
MAXTRANS 255
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1)
LOGGING
Criação da tabela ttrecho, responsável por armazenar as informações sobre os trechos
das praias
Criação idêntica ao do relacional com alterações apenas de tablespace e usuário dono do
objeto
CREATE TABLE "TEMPORAL"."TTRECHO"("CDTRECHO" NUMBER NOT
NULL,
"CDPRAIA" NUMBER NOT NULL, "NMTRECHO" VARCHAR2(100) NOT
NULL,
CONSTRAINT "FK_TPRAIA_TTRECHO" FOREIGN KEY("CDPRAIA")
REFERENCES "TEMPORAL"."TPRAIA"("CDPRAIA"),
CONSTRAINT "TTRECHO_PK_CDTRECHO_CDPRAIA" PRIMARY
KEY("CDTRECHO",
"CDPRAIA") USING
INDEX
TABLESPACE "PROJETOIDX"
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10
INITRANS 2 MAXTRANS 255)
TABLESPACE "PROJETOTBL" PCTFREE 10 PCTUSED 40 INITRANS 1
MAXTRANS 255
STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505
PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1)
LOGGING
Grupo TSAMOSTRA
DECLARE
BEGIN
-- A função Begin_Create_TS_Group inicializa o contexto para criação de um sistema
time series,
-- 'tsamostra' é o nome usado nos procedimentos da ferramenta administrativa do pacote
time series.
-- Parâmetros para a função:
-- name - nome do grupo time series a ser criado;
-- storage_model - armazenamento do time series (modelo de armazenamento).
65
ORDSYS.TSTools.Begin_Create_Ts_Group('tsamostra','flat');
ORDSYS.TSTools.Set_Flat_Attributes(tsname_colname =>
'CdAmostra',tsname_length => 10);
-- definição explícita dos atributos
ORDSYS.TSTools.Add_Number_Column('CdTrecho');
ORDSYS.TSTools.Add_Number_Column('CdPraia');
ORDSYS.TSTools.Add_VARCHAR2_Column('CdResponsavel', 20);
ORDSYS.TSTools.Add_Number_Column('NuColiformes');
ORDSYS.TSTools.Add_Number_Column('NuEscherichia');
ORDSYS.TSTools.Add_Number_Column('NuEnterococos');
ORDSYS.TSTools.Add_VARCHAR2_Column('DsObservacao', 100);
ORDSYS.TSTools.End_Create_Ts_Group;
exception
when others then
begin
ORDSYS.TSTools.Cancel_Create_Ts_Group;
raise;
end;
END;
/
--
-- Com a chamada de End_Create_Ts_Group são criados automaticamente
-- o esquema dos seguintes objetos:
--
-- TSAMOSTRA – Visão de objeto. Usada quando se usa as funções do time series.
-- TSAMOSTRA_RVW – Visão da tabela TSAMOSTRA_TAB. View utilizada
quando é necessário atualizar os dados na base de dados através dos comandos de
inserir, apagar e alterar. Possui um gatilho do tipo Instead Of gerado automaticamente
após a criação do grupo.
-- TSAMOSTRA_TAB – Tabela criada com os atributos especificados e que possui
os dados da base. Apenas é alterada através de uma visão.
-- TSAMOSTRA_MAP – tabela de mapeamento. Utilizada quando se deseja associar
um calendário a uma série de tempo. Toda série de tempo deve ser cadastrada nessa
tabela antes de ser inserida na tabela que possui os dados. É composta pelo atributo
correspondente a série de tempo e o atributo do nome do calendário, caso não haja um
calendário associado esse atributo possui o valor nulo.
-- TSAMOSTRA_CAL – tabela que possui a definição dos calendários.
Grupo TSRESPONSAVEL
66
DECLARE
BEGIN
-- A função Begin_Create_TS_Group inicializa o contexto para criação de um sistema
time series,
-- 'tsresponsável' é o nome usado nos procedimentos da ferramenta administrativa do
pacote time series.
-- Parâmetros para a função:
-- name - nome do grupo time series a ser criado;
-- storage_model - armazenamento do time series (modelo de armazenamento).
ORDSYS.TSTools.Begin_Create_Ts_Group('tsresponsavel','flat');
ORDSYS.TSTools.Set_Flat_Attributes(tsname_colname =>
'CdResponsavel',tsname_length => 10);
-- definição explícita dos atributos
ORDSYS.TSTools.Add_VARCHAR2_Column('NmResponsavel', 100);
ORDSYS.TSTools.Add_VARCHAR2_Column('DsCargo', 100);
ORDSYS.TSTools.End_Create_Ts_Group;
exception
when others then
begin
ORDSYS.TSTools.Cancel_Create_Ts_Group;
raise;
end;
END;
/
--
-- Com a chamada de End_Create_Ts_Group são criados automaticamente
-- o esquema dos seguintes objetos:
--
-- TSRESPONSAVEL – Visão de objeto. Usada quando se usa as funções do time
series.
-- TSRESPONSAVEL_RVW – Visão da tabela TSAMOSTRA_TAB. View utilizada
quando é necessário atualizar os dados na base de dados através dos comandos de
inserir, apagar e alterar. Possui um gatilho do tipo Instead Of gerado automaticamente
após a criação do grupo.
-- TSRESPONSAVEL_TAB – Tabela criada com os atributos especificados e que
possui os dados da base. Apenas é alterada através de uma visão.
-- TSRESPONSAVEL_MAP – tabela de mapeamento. Utilizada quando se deseja
associar um calendário a uma série de tempo. Toda série de tempo deve ser cadastrada
nessa tabela antes de ser inserida na tabela que possui os dados. É composta pelo
67
atributo correspondente a série de tempo e o atributo do nome do calendário, caso não
haja um calendário associado esse atributo possui o valor nulo.
-- TSRESPONSAVEL_CAL – tabela que possui a definição dos calendários.
68
ANEXO D
Script de Criação do Calendário no BDT
A definição do calendário é realizada em uma das tabelas criadas
automaticamente na criação do grupo time series, caso não seja especificado um nome
este será formado por nome_do_grupo_CAL e o atributo reponsável por armazenar a
definição do calendário será do tipo de dado ORDTCalendar, que é um tipo de dado já
definido pelo sistema time series, como descrito (ORACLE, 1999):
CREATE TYPE ORDYS.ORDTCalendar AS OBJECT (
caltype INTEGER, --indica o tipo do calendário(0 = padrão)
name VARCHAR2(256), --nome para o calendário
frequency INTEGER, -- dia, mês, semestre, ano, etc.
pattern ORDSYS.ORDTPattern, --modelo de repetição dos time
--series
minDate DATE, -- o calendário começa com esta data. Ex:
-- data_matrícula do aluno
maxDate DATE -- o calendário finaliza com esta data. Ex:
-- data_colação_grau
offExceptions ORDSYS.ORDTExceptions,
onException ORDSYS.ORDTExpections);
Para a aplicação implementada neste projeto o seguinte calendário foi definido:
INSERT INTO tsamostra_cal VALUES
( ORDSYS.ORDTCalendar(
0, --Tipo de calendário padrão
'Diario', --nome do calendário
4, --frequência do tipo dia
ORDSYS.ORDTPattern(ORDSYS.ORDTPatternBits(1,1,0,0,0,1,1),
to_date('02/01/2002', 'DD-MM-YYYY')), -- data base
to_date('02/01/2002', 'DD-MM-YYYY'), -- data inicial do intervalo que determina as
-- datas mínima e máxima para inserção de
-- dados
to_date('02/01/2006', 'DD-MM-YYYY'), --data final
null, --sem exceção
null)) --sem exceção
Abaixo segue o script de validação do calendário.
69
DECLARE
tstCal ordsys.ordtcalendar;
temp integer;
validFlag integer;
BEGIN
select value(cal) into tstCal
from tsamostra_cal cal
where cal.name = 'Diario';
-- Mostra o calendário
select ordsys.timeseries.display(tstCal) into temp from dual;
dbms_output.new_line;
validFlag := ORDSYS.CALENDAR.IsValidCal(tstCal);
if (validFlag = 1) then
dbms_output.put_line('O calendário diario está valido.');
else
dbms_output.put_line('O calendário diario não está
valido.');
dbms_output.put_line('Use ValidateCal para determinar a
inconsistência.');
end if;
END;
Em ORACLE (1999), podem ser consultados maiores detalhes a respeito da
implementação de calendários
70
