6NF e historial de datos de atributos

Question

Al utilizar una base de datos normalizada según los principios de 6NF, ¿cómo se almacenan los datos de atributos históricos?

Digamos, por ejemplo, tomamos this example de @PerformanceDBA pero con el siguiente requisito adicional:

Necesitamos almacenar datos históricos para todos nuestros productos, debemos ser capaces de , introduce una fecha y obtener una instantánea de los atributos del producto en ese momento en particular.

Un ejemplo más práctico:
Supongamos que los discos y la CPU del del ejemplo anterior son virtuales y un usuario puede cambiar la capacidad del disco a voluntad. ¿Cómo podemos modificar la base de datos para que podamos recuperar los atributos de un disco dado en el pasado (por supuesto, después de la fecha de creación) mientras mantenemos la vista de 5NF lo suficientemente rápido?

cosas que estoy considerando

• Añadir una columna de marca de tiempo 'changedate' a cada tabla de atributos (esto daría lugar a una consulta bastante compleja con una subconsulta y unirse para cada tabla de atributos)
• Crear una tabla de historial * separada para cada tabla de atributos (podría dar como resultado una gran cantidad de tablas, ya que tenemos alrededor de 70 atributos distribuidos en 20 tipos de productos)
• Además: añadir un ' actual' columna indexada a cada tabla de atributos para acelerar la vista 5NF

Cualquier ayuda se agradece!

---

Editar: sé que el concepto de base de datos temporal, sin embargo, el problema es que para el motor de base de datos con los que trabajo (PostgreSQL) la extensión temporal no se aplique plenamente todavía. ¿Algún consejo sobre cómo lograr esto sin bases de datos temporales?

Answer 1

El estándar SQL: 2011 recientemente aprobado incorpora características que le permiten lidiar mejor con este tipo de problema que nunca antes.

No es que puedas hacer todo lo que quieras en el ámbito temporal, pero lo que sí se introdujo es una mejora bastante significativa.

Una buena presentación al respecto está en http://metadata-standards.org/Document-library/Documents-by-number/WG2-N1501-N1550/WG2_N1536_koa046-Temporal-features-in-SQL-standard.pdf.

Tenga en cuenta que solo hay un único proveedor con soporte razonable para estas características en su producto SQL, otro quizás esté trabajando en ello, y un tercero ha abierto el canal de votación para sus clientes.

También hay un grupo de discusión "Datos temporales" en www.linkedin.com dedicado precisamente a su tema en cuestión.

EDIT tratando de abordar "¿Algún consejo sobre cómo lograr esto sin bases de datos temporales?"

No agregue solo una columna de tipo de fecha/hora a sus modelos. La primera razón es la que dio, la segunda es que esta solución también es la promovida por el nuevo estándar, y que facilitará transición a motores que sí admiten las nuevas características una vez que estén disponibles.

Así que agregue AMBAS columnas de inicio/fin de fecha/hora. NO HAGA NINGUNO DE ELLAS NULLABLE. El nuevo estándar requiere esto para sus características temporales Si todavía se desconoce el MIT final (momento en el tiempo), use el valor más alto del tipo de hora aplicable, por ejemplo, 9999-12-31.

No NECESITA "crear tablas de historial separadas para cada atributo ". Es igualmente posible tener una "tabla de entidad única" que mantiene "el historial de una entidad completa". La desventaja es que será difícil consultar cuando se produjo un cambio ACTUAL en algún atributo particular (porque se obtienen nuevas filas históricas para cualquier cambio en cualquier atributo, posiblemente copiando sobre el mismo valor de atributo para la mayoría de los atributos). Es probable que la 'tabla única' sea un consumidor entusiasta de espacio, el 'historial separado para cada atributo' puede ser un consumidor ansioso de consultar el tiempo de la CPU. Será un acto de equilibrio, y donde el equilibrio es precisamente, depende de su situación particular.

No "agregue una columna 'actual' indexada" a sus tablas. En primer lugar, no lo ayudarán a realizar la transición a las nuevas funciones cuando su motor las tenga, y segundo, las columnas Y/N son discriminadores muy malos y, por lo tanto, son candidatos muy pobres para la indexación. Prefiero agregar su inicio o finalización al índice, se puede esperar que obtengan las mismas ganancias para las filas 'actuales' y una mejor ganancia para las filas no actuales, siempre que necesite consultarlas .

En cuanto a la aplicación de las restricciones de la base de datos, como la no superposición en periodos de tiempo en claves temporales y la inclusión de períodos de tiempo en RI temporal, está completamente solo. Escriba el código que necesita en desencadenantes o SPROC o código de aplicación, en orden decreciente de preferencia.

¿Fue esto más útil?