Varios propietarios en una sola base de datos

La validación siempre utiliza datos de control de producción

Cuando se ejecutan los procesos por lotes de validación para los datos temporales, estos últimos se validan respecto a las tablas de control de producción (y los errores se insertan en la tabla de errores temporal). Esto implica que las sentencias SQL que acceden a entidades o las actualizan, deben utilizar el propietario temporal, mientras que las que acceden a la tabla de control deben utilizar el propietario de producción. Sin embargo, debe tenerse en cuenta que, cuando estos mismos procesos por lotes de validación se ejecutan en producción, las sentencias SQL nunca accederán al propietario temporal. En su lugar, se dirigirán al propietario de producción.

Esto se consigue del modo siguiente:

• Debe haber un servidor de aplicaciones independiente para cada propietario. Cada servidor de aplicaciones señala a un identificador de usuario de base de datos específico.
  Nota: en una instalación en la nube, el servidor de aplicaciones solo puede señalar a un ID de usuario de base de datos específico en cualquier momento. Para obtener más información sobre el cambio de propietarios, consulte el apartado sobre “soporte de conversión de datos para implantaciones en la nube”.
• El ID de usuario de base de datos asociado al propietario temporal utiliza CISSTG como propietario de las tablas maestras y de transacciones, pero utilizará CISADM como propietario de las tablas de control de producción.
• El ID de usuario de base de datos asociado al propietario de producción utiliza CISADM como propietario de todas las tablas.

Quizás se pregunte cuál es el origen del problema. Los motivos son diversos:

• Deseábamos reutilizar la lógica de validación existente en los programas que validan los datos de producción. Para ello, estos programas a veces tienen que señalar al propietario temporal y, en otras ocasiones, deben señalar al propietario de producción (y se debe llevar a cabo de forma transparente para los programas; de lo contrario, se necesitarían dos juegos de SQL).
• Deseábamos permitirle utilizar la aplicación para consultar y corregir los datos temporales. Para ello, se puede crear un servidor de aplicaciones que señale a la base de datos temporal con las características de propiedad antes descritas.
• Deseábamos que los programas de validación pudiesen validar los datos de producción (además de los datos temporales). ¿Por qué se querrían validar los datos de producción si solamente se pueden añadir datos limpios a producción? Tenga en cuenta las siguientes situaciones posibles:
  • Después de una actualización, puede que se considere conveniente validar los datos de producción para garantizar que todavía funciona la lógica de salida de usuario existente.
  • Quizás desee realizar un experimento con los posibles resultados de modificar la lógica de validación. Para ello, podría realizar un cambio temporal en la lógica de salida de usuario (en producción) y, a continuación, ejecutar los trabajos de validación sobre una base de muestra aleatoria.
  • Ha olvidado ejecutar un programa de validación antes de rellenar los datos de producción y desea ver las consecuencias. Si sigue las instrucciones de este documento, nunca debería suceder. No obstante, siempre pueden producirse accidentes. En ese caso, al menos dispondrá de una forma de determinar las distintas consecuencias.

Solo la validación puede funcionar con ambos propietarios

Aunque la redirección de un ID de propietario representa una técnica útil para los procesos por lotes de validación, no se puede utilizar en los procesos por lotes de asignación de claves e inserción de producción. El motivo es que estos procesos tienen que acceder a las mismas tablas con distintos propietarios al mismo tiempo. También debe hacer referencia a tablas de conversión específicas que no existen en producción. Por ejemplo, el proceso por lotes que inserta las filas en una tabla de producción debe seleccionar estas filas desde la versión temporal de la tabla, resolver las claves a partir de la conversión de las tablas de asignación de claves antiguas/claves nuevas e insertar los registros resueltos en la versión de producción de la misma tabla.

Esto se consigue del modo siguiente:

• En el registro temporal, existe una vista para producción para cada elemento elegible para la tabla de conversión. Estas vistas incluyen en el código fijo al propietario de la base de datos para señalar a producción. Por ejemplo, hay una vista denominada CX_​PER que hace referencia a la tabla de persona de producción.
• Los programas de asignación de claves e inserción utilizan estas vistas siempre que necesitan tener acceso a los datos de producción.