modelagem de banco de dados temporal e normalização

Question

As datas devem para um banco de dados temporais armazenado em um ou 2 mesas? Se a pessoa não faz isso viola a normalização?

PERSON1 DATE11 DATE21 INFO11 INFO21 DEPRECATED
PERSON2 DATE21 DATE22 INFO21 INFO22 CURRENT
PERSON1 DATE31 DATE32 INFO31 INFO32 CURRENT

data1 e data2 Colunas indicam que INFO1 e INFO2 são verdadeiras para o período entre data1 e data2. Se DATA

Eu deveria dividir a tabela? Devo armazenar o estado (obsoleto ou corrente) na tabela?

Para esclarecer mais a questão, Deprecated é o termo usado pelo negócio, se você preferir "não corrente", o problema não é semântica, não se trata de consultas SQL quer, eu só quero saber que o projeto viola ou melhor ternos regras de normalização (eu sei normalização nem sempre é o caminho a percorrer, que não é a minha pergunta qualquer um).

Answer 1

"Eu quero saber o que o projeto viola as regras de normalização"

depende de qual conjunto de regras de normalização que você quer passar.

A primeira e mais provável violação das formas normais, e em livro de Data é uma violação de primeira NF , é seu fim-datas nas linhas que espera informações "corrente" (fazendo abstração da possibilidade de informações futuras do prazo de validade): você violar 1NF se você fizer que anulável atributo

.

As violações dos BCNF pode, obviamente, ocorrer como conseqüência de sua escolha de chaves (como é o caso na base de dados nontemporal projetos também - o aspecto temporal não faz diferença aqui). WRT "escolha de chaves": se você usar o arranque separado e-datas finais (e SQL tipo de te deixa nenhuma outra escolha), então provavelmente você deve declarar duas chaves: uma que inclui a data de início, e que inclui a data final.

Outra questão design é as múltiplas colunas de dados. Esta questão é discutida muito em geral em "Temporal de dados e o modelo relacional": se INFO1 e INFO2 pode mudar independentemente um do outro, talvez seja melhor para se decompor suas tabelas para manter apenas um atributo, a fim de evitar uma "explosão de linhas contar" que poderiam ocorrer se você tem que criar uma nova linha completa cada vez que um único atributo nas mudanças de linha. Nesse caso, o seu projeto como você deu constitui uma violação da forma normal SEXTO, como (de que forma normal é) definida em "Temporal de dados e o modelo relacional".

Answer 2

A normalização é um conceito de banco de dados relacional - não se aplica bem às bases de dados temporais. Isso não quer dizer que você não pode armazenar dados temporal em um banco de dados relacional. Você definitivamente pode.

Mas se você está indo com Temporal banco de dados design, em seguida, os conceitos de Temporal Normalização aplicar em vez de Relacional normalização.

Answer 3

Você não indicaram o significado das datas. Eles referem-se a (a) o período em que o fato afirmado era verdade na vida real, ou (b) para o período em que o fato declarado era acreditava ser verdade pelo titular da base de dados? Se (b), então eu nunca fazê-lo desta forma. Mova a linha atualizada para uma tabela de arquivo / log imediatamente quando a atualização for feita. Se (a), então a seguinte declaração é questionável:

"Os fatos estão obsoletos e não devem mostrar mais na interface do usuário"

Se um fato não "necessidade de aparecer na interface do usuário" mais, então ele não precisa estar no banco de dados mais quer. Manter tais fatos não atinge apenas uma coisa:. Deteriorar o desempenho geral para todo o resto

Se você realmente precisa dessas demonstrações históricas de fato para atender suas necessidades, então as chances são de que seus chamados "fatos obsoleto" ainda são muito relevantes para o negócio e, portanto, não "obsoleta" em tudo. Assumming que, por essa razão, há muito pouco "realmente obsoleto" fatos em seu banco de dados, o seu design é bom. Basta manter o número de "fatos realmente obsoleto" pequena, removendo-os periodicamente a partir do banco de dados operacional.

(PS) Para dizer que seu projeto é bom, não significa que você não vai correr em quaisquer problemas. SQL é extremamente mal adequado para lidar com este tipo de informação elegantemente. "Temporal de dados e o modelo relacional" é um excelente tratamento do assunto. Outro livro, o de Snodgrass, é frequentemente elogiado também, embora não por mim. Aquele é algo de um livro com receitas para lidar com esses problemas em SQL, como comprovado pelo seguinte conversa sobre SO sobre este livro:

(Q) "Por que eu iria ler isso?" (A) "Porque o gatilho que você pediu está na página 135".