Transformando la base de datos relacional OLTP en el modelo de almacenamiento de datos

Question

¿Cuáles son los enfoques de diseño comunes tomados al cargar datos de un modelo de base de datos Entidad-Relación OLTP en un esquema de estrella de Kimball Data Warehouse/modelo Marts?

• ¿Utiliza un área de preparación para realizar la transformación y luego cargar en el almacén?
• ¿Cómo se vinculan los datos entre el almacén y la base de datos OLTP?
• ¿Dónde/Cómo se gestiona el proceso de transformación - en la base de datos como sprocs, dts/ssis packages o SQL desde el código de la aplicación?

Answer 1

Personalmente, tiendo a trabajar de la siguiente manera:

1. diseño del almacén de datos de la primera. En particular, diseñe las tablas que se necesitan como parte del DW, ignorando las tablas de etapas.
2. Diseñe el ETL, utilizando SSIS, pero a veces con SSIS llamando procedimientos almacenados en las bases de datos involucradas.
3. Si se requieren tablas de etapas como parte del ETL, muy bien, pero al mismo tiempo, asegúrese de que se limpien. Una tabla de etapas utilizada solo como parte de una única serie de pasos de ETL se debe truncar después de completar los pasos, con o sin éxito.
4. Tengo los paquetes de SSIS que hacen referencia a la base de datos de OLTP al menos para extraer datos en las tablas de etapas. Dependiendo de la situación, pueden procesar las tablas OLTP directamente en el almacén de datos. Todas estas consultas se realizan CON (NOLOCK).
5. Documento, Documento, Documento. Deja en claro qué entradas usa cada paquete y a dónde va el resultado. Asegúrese de documentar los criterios por los que se ha seleccionado la entrada (últimas 24 horas? Desde el último éxito? Nuevos valores de identidad? Todas las filas?)

Esto ha funcionado bien para mí, aunque admito que no he hecho muchos de estos proyectos, ni ninguno realmente grande.

Answer 2

La explicación del proceso de John Saunders es buena.

Si está buscando implementar un proyecto de Datawarehouse en SQL Server, encontrará toda la información que necesita para la entrega de todo el proyecto dentro del excelente texto "The Microsoft Data Warehouse Toolkit".

Funilly suficiente, uno de los autores es Ralph Kimball :-)

Answer 3

Actualmente estoy trabajando en una casa pequeña de tamaño medio dataware /. Estamos adoptando algunos de los conceptos que Kimball propone, es decir, el esquema de estrella con tablas de hechos y dimensiones. Lo estructuramos de modo que los hechos solo se unan a dimensiones (no de hecho a hecho o de dimensión a dimensión, pero esta es nuestra elección, sin decir que es la forma en que debería hacerse), así que aplanamos todas las uniones de dimensión a la tabla de hechos.

Usamos SSIS para mover los datos del DB de producción -> DB de origen -> BD de depósito -> DB de informe (probablemente podríamos haber usado menos DB, pero así es como ha caído).

SSIS es muy agradable ya que le permite estructurar sus flujos de datos de manera muy lógica. Usamos una combinación de componentes SSIS y procesos almacenados, donde una buena característica de SSIS es la capacidad de proporcionar comandos SQL como una transformación entre un flujo de datos de origen/destino. Esto significa que podemos llamar procesos almacenados en cada fila si queremos, lo que puede ser útil (aunque un poco más lento).

También estamos utilizando una nueva característica de SQL Server 2008 llamada cambio de captura de datos (CDC) que le permite auditar todos los cambios en una tabla (puede especificar qué columnas desea ver en esas tablas), así que utilícelo en el DB de producción para ver qué ha cambiado, de modo que podamos trasladar esos registros a la base de datos fuente para su procesamiento.

Answer 4

Es posible que desee echar un vistazo a Data Vault Modeling. Afirma resolver algunos problemas a largo plazo, como el cambio de atributos.

Answer 5

Estoy de acuerdo con la respuesta de alta calificación, pero que me gustaría añadir lo siguiente:

carga

* Do you use a staging area to perform the transformation and then 

en el almacén?

Depende del tipo de transformación si requiere una puesta en escena. La organización por etapas ofrece beneficios de dividir el ETL en fragmentos más manejables, pero también proporciona un área de trabajo que permite manipulaciones en los datos sin afectar el almacén. Puede ayudar tener (al menos) algunas búsquedas de dimensión en un área de almacenamiento que almacena las claves del sistema OLTP y la clave del último registro atenuado, para usar como una búsqueda al cargar sus registros de hechos. La transformación ocurre en el proceso de ETL en sí, pero puede o no requerir alguna preparación para ayudarlo en el camino.

* How do you link data between the warehouse and the OLTP database? 

Es útil para cargar las llaves de negocio (o claves principales reales si está disponible) en el almacén de datos como una referencia de nuevo al sistema OLTP. Además, la auditoría en el proceso DW debe registrar el linaje de cada bit de datos al registrar el proceso de carga que lo ha cargado. base de datos de

* Where/How do you manage the transformation process - in the 

como sprocs, DTS/paquetes SSIS, o SQL de código de la aplicación?

Esto normalmente sería en paquetes SSIS, pero a menudo es más eficaz para transformar en la consulta de origen. Desafortunadamente, esto hace que la consulta de origen sea bastante complicada de comprender y, por lo tanto, de mantener, por lo que si el rendimiento no es un problema, es mejor transformar en el código de SSIS. Cuando haces esto, esta es otra razón para tener un área de preparación ya que puedes hacer más uniones en la consulta fuente entre diferentes tablas.