Validez temporal y relaciones clave primarias / extranjeras

He leído varios de los tutoriales de Oracle que muestran la validez temporal y las características de tiempo. Sin embargo, en los ejemplos que he leído, no hay clave principal utilizada en las tablas de demostración.

http://docs.oracle.com/cd/E16655_01/appdev.121/e17620/adfns_design.htm#ADFNS1005 http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/ilm /temporal/temporal.html

¿Se deben agregar claves primarias a estas tablas? Pregunto porque me pregunto cómo una de estas tablas temporales debería ser referenciada por otra tabla. ¿Puedo agregar una clave foránea de una tabla temporal a otra?

Si agrego una relación pk / clave externa, y luego actualizo la referenciada en la tabla con la pk, la tabla con la fk apunta a un registro que ya no es relevante ... los datos temporales rompen la clave primaria normal - clave externa relaciones? Y si es así, ¿cómo afecta esto al rendimiento? ¿Solo uso una columna normal como 'clave externa' y selecciono la correcta para un período de tiempo referenciado en una consulta?

¿Alguien sabe o tiene a mano ejemplos o tutoriales que muestren datos temporales con uso normal o pseudo-normal de pk / fk?

Gracias

Desafortunadamente, el presente SQL o sus implementaciones en todos los productos RDBMS no soportan completamente las relaciones temporales.

Solo Teradata y DB2 tienen algunas características que implementan restricciones que tienen tiempo en las dos o más columnas.

Mi ejemplo:

CONFIGURAR PRUEBA DE ESQUEMA;

CREATE TABLE PRODUCT (
product_ID INT NOT NULL,
suplier NVARCHAR (50),
PRIMARY KEY (product_ID)
);

CREATE TABLE CAMPAIGN (
campaign_ID INT NOT NULL,
product_ID INT NOT NULL,
price DECIMAL,
PRIMARY KEY (campaign_ID)
)
;

ALTERAR
LA CAMPAÑA DE LA MESA AÑADIR RESTRICCIÓN XFK_campaign_productid
LLAVE EXTRANJERA (ID_producto) REFERENCIAS PRODUCTO (ID_producto)
AL BORRAR SIN ACCIÓN;

Si agrega columnas temporales business_startdate y business_enddate y, opcionalmente,
transaction_starttime y transaction_endtime, ya no podrá exigir la integridad referencial.

Es posible que deba implementar desencadenantes o procedimientos almacenados o codificación a nivel de aplicación si desea implementar una restricción como esta:

CREATE TABLE CAMPAIGN (
campaign_ID INT NOT NULL,
product_ID INT NOT NULL,
business_startdate DATE NOT NULL,
business_enddate DATE NOT NULL,
transacción_starttime TIMESTAMP NOT NULL,
transacción_endtime TIMESTAMP NOT NULL,
price DECIMAL,
PRIMARY KEY (campaign_ID, business_startdate), transaction_starttime
)
;

Para DB2 existe una constante de clave primaria temporal en la siguiente sintaxis:

CREATE TABLE CAMPAIGN (
campaign_ID INT NOT NULL,
product_ID INT NOT NULL,
business_startdate DATE NOT NULL,
business_enddate DATE NOT NULL,
price DECIMAL,
PERIOD BUSINESS_TIME (business_startdate, business_enddate),
PRIMARY KEY (campaign_TIrt, BUSINESS_TIME SIN OVERLAPS)
)
;