modelado de base de datos temporal y la normalización

Question

En caso de fechas para una base de datos temporal almacenada en uno o 2 mesas? Si uno no violan esta normalización?

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

FECHA1 y Date2 columnas indican que INFO1 y INFO2 son verdaderos para el período comprendido entre FECHA1 y DATE2. Si FECHA

¿Debo dividir esta tabla? Debería almacenar el estado (en desuso o corriente) en la tabla?

Para aclarar la cuestión más aún, en desuso es el término utilizado por el negocio, si lo prefiere "no corriente", el problema no es semántica, no se trata de consultas SQL o bien, sólo quiero saber qué diseño viole o mejor las reglas de normalización se adapte (sé que la normalización no siempre es el camino a seguir, que no es mi pregunta tampoco).

Answer 1

"Quiero saber qué diseño viola las reglas de normalización"

depende de qué conjunto de reglas de normalización que desea pasar.

La primera y más probable violación de formas normales, y en libro de Fecha se trata de una violación de primera NF , es sus fechas límite en las filas que contienen información "actual" (haciendo abstracción de la posibilidad de la información hacia el futuro anticuado): usted viola 1NF si haces que anulable atributo

.

BCNF obviamente, puede ocurrir como consecuencia de la elección de claves (como es el caso en la base de datos no temporal diseños también - el aspecto temporal no hace ninguna diferencia en este caso). WRT "elección de claves": si se utiliza arranque independiente y-fechas finales (y SQL tipo de te deja ninguna otra opción), lo más probable es que usted debe declarar dos claves: una que incluye la fecha de inicio y una que incluye el fecha final.

Otra cuestión es el diseño de las múltiples columnas de datos. Este tema se discute bastante en general en "Temporal de datos y el modelo relacional": si INFO1 y INFO2 pueden cambiar independientemente el uno del otro, tal vez sería mejor para descomponer las tablas para contener sólo un atributo, con el fin de evitar una "explosión de filas cuentan" que de lo contrario se podrían producir si tiene que crear una nueva fila completa cada vez que uno solo atributo en la fila cambia. En ese caso, su diseño a medida que dio constituye una violación de la forma normal sexto lugar, en (que es la forma normal) se define en "Temporal de datos y el modelo relacional".

Answer 2

La normalización es un concepto relacional de bases de datos - no se aplica así a las bases de datos temporales. Eso no es para decir que no se puede almacenar datos temporales en una base de datos relacional. Que sin duda puede.

Sin embargo, si se va con el diseño de base de datos temporal, entonces los conceptos de normalización temporal se aplican en lugar de normalización relacional.

Answer 3

No ha indicado el significado de las fechas. ¿Se refieren a: (a) el período en que el hecho declarado era cierto en la vida real, o de (b) para el período en que el hecho declarado era cree que es cierto por el titular de la base de datos? Si (b), entonces yo nunca hacerlo de esta manera. Mover la línea actualizado a un tabla de archivo / log inmediatamente cuando se realiza la actualización. Si (a), entonces la siguiente afirmación es cuestionable:

"los hechos están en desuso y no deben mostrar más en la interfaz de usuario"

Si un hecho no "tiene que aparecer en la interfaz de usuario" más, entonces no necesita estar en la base de datos más bien. Mantener estos hechos no alcanza sólo una cosa: se deteriora el rendimiento general para todos los demás

.

Si realmente necesita estas declaraciones históricas de los hechos para satisfacer sus requisitos, entonces lo más probable es que sus llamados "hechos" obsoletas son todavía muy relevante para el negocio, y por lo tanto no "en desuso" en absoluto. Assumming que por esta razón, hay muy pocos hechos "realmente obsoletas" en su base de datos, el diseño es bueno. Hemos de tener el número de "hechos realmente obsoletas" pequeña eliminando periódicamente a partir de la base de datos operativa.

(PS) a decir que su diseño es bueno, no significa que no tendrás ningún problema. SQL es muy poco adecuado para manejar este tipo de información con elegancia. "Temporal de datos y el modelo relacional" es un excelente tratamiento del tema. Otro libro, el de Snodgrass, es a menudo elogiado también, aunque no por mí. Que uno es algo así como un libro de cocina con recetas para hacer frente a estos problemas en SQL, como lo demuestra el siguiente conversación sobre lo que alrededor de este libro:

(Q) "¿Por qué habría que leer?" (A) "Porque el gatillo que solicitó es en la página 135."