¿Cómo crear una tabla histórica de hechos?

Question

Tengo algunas entidades en mi almacén de datos:

1. persona - con los atributos personId, dateFrom, dateTo, esos y otros se puede cambiar, por ejemplo, apellido, fecha de nacimiento y así sucesivamente - que cambia lentamente dimensión

2. Documento - documentId, número, tipo

3. Dirección - AddressID, ciudad, calle, casa, piso

Las relaciones entre (persona y documento) son de uno a muchos y (persona y dirección) es de muchos a muchos.

Mi objetivo es crear la historia tabla de hechos que nos pueden responder a las preguntas siguientes:

1. lo que las personas con lo que los documentos vivían en la dirección definida en la fecha definida?

2, ¿Qué historial de residentes tiene la dirección definida en un intervalo de tiempo definido?

Esto no es solo para lo que DW está diseñado, pero creo que es lo más difícil en el diseño de DW.

Por ejemplo, Miss Brown con personId = 1, los documentos con documentId = 1 y documentId = 2 se han vivido en la dirección con addressId = 1 desde 01/01/2005 al 02/02/2010 y luego se movieron a addressId = 2 donde se ha vivido desde el 02/03/2010 hasta la fecha actual (¿NULO?). Pero cambió su apellido a Mrs Green desde el 4/05/2006 y su primer documento con documentId = 1 a documentId = 3 desde el 06/07/2007. Mr Black con personId = 2, documentId = 4 se ha vivido en addressId = 1 desde 02/03/2010 hasta la fecha actual.

El resultado esperado en nuestra consulta para la pregunta 2, donde AddressID = 1, y el intervalo de tiempo es desde 01/01/2000 ahora, debe ser como:

Filas:

last_name="Brown", documentId=1, dateFrom=01/01/2005, dateTo=04/04/2006 

last_name="Brown", documentId=2, dateFrom=01/01/2005, dateTo=04/04/2006 

last_name="Green", documentId=1, dateFrom=04/05/2006, dateTo=06/06/2007 

last_name="Green", documentId=2, dateFrom=04/05/2006, dateTo=06/06/2007 

last_name="Green", documentId=2, dateFrom=06/07/2007, dateTo=02/01/2010 

last_name="Green", documentId=3, dateFrom=06/07/2007, dateTo=02/01/2010 

last_name="Black", documentId=4, dateFrom=02/03/2010, dateTo=NULL 

que tenía una idea para crear tabla de hechos con la clave compuesta (personId, documentId, addressId, dateFrom) pero no tengo idea de cómo cargar esta tabla y luego obtener ese resultado esperado con esta estructura.

Estaremos encantados de recibir ayuda.

Answer 1

Pregunta interesante @Argnist!

Así que para crear un lenguaje común para mi ejemplo, que desea una

• DimPerson (, clave suggorate PK = kcPerson para personas únicas = kPerson, tipo 2 tenue)
• DimDocument (PK = kcDocument, suggorate clave para los documentos únicos = kDocument, tipo 2 tenue)
• DimAddress (PK = kcAddress, suggorate clave para las direcciones únicas = kAddress, tipo 2 tenue)

un colega ha escrito un blog corto en t El uso de dos claves sustitutivas para explicar las dims anteriores 'Using Two Surrogate Keys on Dimensions'.

Siempre agregaría DimDate con PK en la forma aaaammdd a cualquier depósito de datos con columnas de atributos adicionales.

allí tendría que tener su tabla de hechos como

• FactHistory (FKs = kcPerson, kPerson, kcDocument, kDocument, kcPerson, kPerson, kDate) más cualesquiera medidas adicional.

Luego de unir en el "kc" s puede mostrar la información actual de la dimensión Persona/Documento/Dirección. Si se unió a la "k" s, puede mostrar la información histórica de la dimensión Person/Document/Address.

La desventaja de esto es que esta tabla de hechos necesita una fila para cada combinación persona/documento/dirección/fecha. Pero realmente es una tabla muy estrecha, ya que la tabla solo tiene una cantidad de claves externas.

La ventaja de esto es que es muy fácil consultar el tipo de preguntas que estaba haciendo.

Alternativamente, usted podría tener su tabla de hechos como

• FactHistory (FKs = kcPerson, kPerson, kcDocument, kDocument, kcPerson, kPerson, kDateFrom, kDateTo) más cualesquiera medidas adicional.

Esto es, obviamente, mucho más compacto, pero la consulta se vuelve más compleja. ¡También podría poner una vista sobre la tabla de hechos para que sea más fácil consultar!

La elección de la solución depende de la frecuencia del cambio de los datos. Sospecho que no cambiará tan rápido, por lo que el diseño alternativo de la tabla de hechos puede ser mejor.

Espero que ayude.