Por que precisamos de um banco de dados temporais?

StackOverflow https://stackoverflow.com/questions/800331

  •  03-07-2019
  •  | 
  •  

Pergunta

Eu estava lendo sobre bancos de dados temporais e parece que eles têm construído em aspectos temporais. Eu me pergunto por que precisamos de tal modelo um?

Quão diferente é a partir de um RDBMS normal? não podemos ter uma base de dados normal, ou seja, RDBMS e dizer tem um gatilho que associa um carimbo de tempo com cada transação que acontece? Pode estar lá seria um acerto de desempenho. Mas eu ainda sou cético em bancos de dados temporais que têm um caso forte no mercado.

Será que qualquer dos atuais bancos de dados suportam esse recurso?

Foi útil?

Solução

base de dados Um temporais eficientemente armazena uma série temporal de dados, tipicamente por ter alguns escala de tempo fixo (tal como segundos ou mesmo milisegundos) e, em seguida, apenas altera o armazenamento dos dados medidos. Um carimbo de hora em um RDBMS é um valor discreto armazenados para cada medição, o que é muito ineficiente. Um banco de dados temporal é frequentemente usado em aplicações de monitoramento em tempo real como SCADA. Um sistema bem estabelecido é o banco de dados PI a partir OSISoft ( http://www.osisoft.com/ ).

Outras dicas

Considere o seu diário de nomeação / jornal - que vai de 1º de janeiro-dezembro 31º. Agora podemos consultar o diário para as entradas de nomeações / jornal em qualquer dia. Esta ordenação é chamado de tempo válido . No entanto, consultas / entradas não são geralmente inseridos de forma.

Suponha que eu gostaria de saber o que as nomeações / entradas estavam em meu diário em 4 de abril. Ou seja, todos os registros que existiam no meu diário em 4 de abril. Este é o tempo de transação .

Dado que as nomeações / entradas podem ser criados e excluídos etc. Um registro típico tem um início e de término válido que abrange o período de entrada e um início e operação de fim de tempo que indica o período durante o qual a entrada apareceu no diário.

Este arranjo é necessário quando o diário pode sofrer revisão histórica . Suponha que em 5 de abril Eu percebo que a nomeação eu tinha em 14 de fevereiro, na verdade, ocorreu em 12 de fevereiro ou seja, eu descobrir um erro no meu diário - eu posso corrigir o erro para que a imagem de tempo válido for corrigido, mas agora, minha consulta do que era no diário em 4 de abril seria errado, a menos que, os tempos de transacção para os compromissos / entradas também são armazenados. Nesse caso, se eu consultar meu diário a partir de 04 de abril ele vai mostrar um compromisso existia em 14 de fevereiro, mas se consulta I a partir de 06 de abril ele iria mostrar um compromisso em 12 de fevereiro.

Este recurso de viagem no tempo de um banco de dados temporais torna possível gravar informações sobre como os erros são corrigidos em um banco de dados. Isso é necessário para uma imagem auditoria verdadeiro de dados que registros quando foram feitas revisões e permite consultas relativas à forma como os dados foram revistos ao longo tempo.

A maioria das informações de negócios deve ser armazenado neste esquema bitemporal, a fim de fornecer um registro de auditoria verdadeiro e para maximizar business intelligence - daí a necessidade de apoio em um banco de dados relacional. Observe que cada item de dados ocupa um quadrado (possivelmente ilimitado) no modelo de tempo bidimensional que é por isso que as pessoas costumam usar um índice de GIST para implementar a indexação bitemporal. O problema aqui é que um índice de GIST é realmente concebido para dados geográficos e os requisitos para dados temporais são um pouco diferentes.

PostgreSQL 9.0 restrições de exclusão deve fornecer novas formas de organizar dados temporais, por exemplo de transação e hora válida períodos não devem sobrepor-se para a mesma tupla.

Pelo que entendi (e over-simplificando enormemente), registros de banco de dados temporais fatos sobre quando os dados era válido, bem como os dados em si, e permite que você consulta sobre os aspectos temporais. Você acaba lidando com 'tempo válido' e tabelas 'tempo de transação', ou 'mesas bitemporais' envolvendo tanto 'tempo de validade' e 'transações de tempo' aspectos. Você deve considerar a ler qualquer um destes dois livros:

bancos de dados temporais são muitas vezes utilizados na indústria de serviços financeiros. Uma razão é que você é raramente (ou nunca) permissão para excluir todos os dados, de modo ValidFrom -. Campos de tipo ValidTo sobre registros são usados ??para fornecer uma indicação de quando um registro foi correta

Além de ler o Wikipedia artigo ? Um banco de dados que mantém um "log de auditoria" ou log de transações semelhante terá algumas propriedades de ser "temporais". Se você precisa de respostas a perguntas sobre quem fez o quê a quem e quando , então você tem um bom candidato para um banco de dados temporal.

Você pode imaginar um banco de dados temporais simples que apenas registra a sua localização GPS a cada poucos segundos. As oportunidades para comprimir esses dados é grande, uma base de dados normal, você precisa armazenar um timestamp para cada linha. Se você tem uma grande quantidade de taxa de transferência necessária, sabendo os dados é temporal e que atualizações e exclusões para uma linha nunca será necessário permite que o programa para deixar cair um monte de herdar complexidade em um RDBMS típico.

Apesar disso, dados temporais é geralmente apenas armazenado em um RDBMS normais. PostgreSQL, por exemplo, tem algum temporais extensões , o que torna este um pouco mais fácil.

Duas razões vêm à mente:

  1. Alguns são otimizados para inserção e somente leitura e pode oferecer melhorias dramáticas perf
  2. Alguns têm melhor entendimento de tempo do SQL tradicional - permitindo o agrupamento de operações por segundo, minuto, hora, etc

Apenas uma atualização, banco de dados Temporal está chegando ao SQL Server 2016.

Para limpar todas as suas dúvidas por que um precisa de um banco de dados temporal, em vez de configurar com métodos personalizados, e como forma eficiente e sem problemas SQL Server configura-lo para você, confira o vídeo em profundidade e demonstração na Channel9.msdn aqui: https://channel9.msdn.com/Shows/Data-Exposed / temporal-in-SQL-Server-2016

MSDN link: https: // MSDN. microsoft.com/en-us/library/dn935015(v=sql.130).aspx

Atualmente, com o lançamento CTP2 (beta 2) do SQL Server 2016, você pode brincar com ele.

Verifique este vídeo sobre como utilizar tabelas temporais no SQL Server 2016.

Além de "que coisas novas que posso fazer com ele", pode ser útil considerar "o que as coisas velhas não é unificar?". O banco de dados temporais representa uma generalização particular do banco de dados SQL "normal". Como tal, pode dar-lhe uma solução unificada para os problemas que apareciam anteriormente independentes. Por exemplo:

Por outro lado, o modelo tempo em si é meio caminho para o controle de revisão completa, que poderia inspirar outras aplicações. Por exemplo, suponha que você rolar o seu próprio facilidade temporais no topo de SQL e permitir ramificação, como nos sistemas de controle de revisão. Mesmo ramificação limitada poderia tornar mais fácil a oferta "sandboxing" - a capacidade de jogar com e modificar o banco de dados com abandono, sem causar quaisquer alterações visíveis a outros usuários. Isso torna mais fácil para fornecer treinamento de usuário altamente realista em um banco de dados complexo.

ramificação simples com uma instalação de fusão simples também poderia simplificar alguns problemas de fluxo de trabalho comuns. Por exemplo, uma organização sem fins lucrativos pode ter voluntários ou trabalhadores pagos baixos fazendo entrada de dados. Dando a cada trabalhador sua própria filial poderia tornar mais fácil para permitir que um supervisor para rever seu trabalho ou melhorá-lo (por exemplo, de-duplification) antes de fundir-lo para o ramo principal, onde se tornaria visível para os usuários "normais". Ramos também poderia simplificar permissões. Se um usuário só é concedida a permissão para uso / ver o seu único ramo, você não precisa se preocupar com a prevenção cada possível alteração indesejada; você só vai mesclar as alterações que fazem sentido mesmo.

O meu entendimento de bases de dados temporais se que são voltadas para armazenar certos tipos de informação temporal. Você poderia simular que, com um RDBMS padrão, mas usando um banco de dados que o suporta que você construiu-in idiomas para um monte de conceitos e a linguagem de consulta pode ser otimizado para este tipo de consultas.

Para mim, isso é um pouco como trabalhar com um banco de dados específico-GIS ao invés de um RDBMS. Enquanto você poderia empurrar coordenadas em um RDBMS run-of-the-mill, tendo as diligências adequadas (por exemplo, por meio de arquivos de rede) pode ser mais rápido, e tendo primitivas SQL para coisas como topologia é útil.

Existem bancos de dados acadêmicos e alguns comerciais. Timecenter tem algumas ligações.

Outro exemplo de onde um banco de dados temporal é útil é onde as mudanças de dados ao longo do tempo. Passei alguns anos trabalhando para um distribuidor de energia eléctrica onde nós armazenados leituras do medidor de blocos de 30 minutos de tempo. Essas leituras do medidor pode ser revista a qualquer momento, mas ainda precisava ser capaz de olhar para trás na história de mudanças para as leituras.

Por isso, teve a última leitura (o nosso "entendimento atual do consumo para os 30 minutos), mas poderia olhar para trás em nossa compreensão histórica do consumo. Quando você tem dados que pode ser ajustado de forma a bases de dados temporais funcionar bem.

(Dito isto, nós entalhadas à mão-lo em SQL, mas foi um justo tempo atrás. Será que não tomar essa decisão nos dias de hoje.)

Não afiliado a StackOverflow
scroll top