Master Data Management - Redundancia de datos

Question

Actualmente estoy desarrollando un sistema que contiene todos los datos maestros relevantes, como por ejemplo un cliente, o información sobre un sistema operacional que existe dentro de nuestro sistema. Los ID asignados a estas entidades son únicos dentro de la empresa. Cuando algún sistema almacena, p. datos relacionados con el cliente, también debe contener la ID de datos maestros del cliente. El sistema de datos maestros se basa en .Net y una MSSQL 2005.

1. Ahora mi pregunta es, al desarrollar otro sistema con sus propias asambleas, bases de datos, etc., que utiliza datos del sistema MDM, lo haría usted almacena esos datos de forma redundante en la otra base de datos de sistemas, crea sus propias entidades comerciales (como clientes) y codifica los datos maestros requeridos desde el MDM en la otra base de datos (o por ETL)? De esta forma, el otro sistema se separa del MDM pero solo almacena los ID de datos maestros globales.

2. ¿O integraría los conjuntos del MDM en otros sistemas (si .Net por supuesto) y usaría la capa de datos del MDM para cargar entidades globales (como un cliente)?

3. ¿O dejaría que el otro sistema cree sus propias entidades, pero para recuperar datos maestros utilizaría una interfaz SOAP proporcionada por el MDM.

Tiendo a utilizar el enfoque no. 1 porque creo que es mejor desconectar otros sistemas de la solución MDM (separación de preocupaciones). Dado que la solución MDM puede contener muchos más datos de una entidad cliente que los que necesitaría en algún otro sistema donde solo se requiere el nombre del cliente. La opción 3 sería posible, pero los servicios web podrían ralentizar mucho un sistema operativo. ¿Qué piensas?

Answer 1

1. Esto conlleva un alto riesgo de que los datos se desincronicen, seguido de un gran dolor de cabeza tratando de desentrañarlo.

2. Esta es una opción viable, pero tendrías que mantener un conjunto de ensamblajes decente para que las personas lo usen. Esta es una tarea no trivial, ya que necesitan ser robustos, estar bien documentados, tener una API utilizable más una gestión de versiones sensata, muy similar a la que esperaría de cualquier marco de terceros. Por lo general, este es un nivel de rigor por encima de las prácticas normales de desarrollo LOB en mi experiencia.

3. Tengo que ser el camino a seguir, diría yo. Una arquitectura orientada a servicios que permite a otras personas acceder a los datos, pero dándoles la flexibilidad de cómo acceder a ellos o consumirlos.

Como dices, el rendimiento puede ser el factor decisivo, en cuyo caso 1 combinado con 3 podría ser el mejor. es decir, las copias locales se ven y se tratan como datos almacenados en caché, en lugar de como copias actualizadas confiables. La aplicación podría hacer una verificación rápida con el DB maestro para ver si el caché local sigue siendo válido (muy parecido a una solicitud HEAD en tierra HTTP) y luego usar los datos locales o actualizarlos desde la base de datos maestra.

Answer 2

Los pros y los contras de una solución 1 son:

Pros: - Más rápido tiempo de respuesta (frente a tener que consultar al Maestro en cada operación, se puede almacenar en caché algo para aliviar este) - Su sistema de satélite puede funciona incluso si el maestro no está disponible temporalmente.

Contras: - corre el riesgo de trabajar con datos obsoletos (si tienes tu ETL actualiza a medianoche, no obtendrá ningún registro nuevo o actualizado hasta el próximo ciclo de la medianoche) - Por supuesto que no se puede permitir el satélite toca alguna copia local del MDM (alineaciones bidireccionales, especialmente con satélites diferentes múltiples se convierte en una pesadilla).

Dependiendo de las especificaciones, la Solución 1 puede estar bien. Prefiero ir a consultar al Maestro en todo momento (de nuevo, posiblemente almacenando en el caché las respuestas por un tiempo) pero es más una preferencia personal.