martes, junio 23, 2015

Registros con datos validados de otras bases

Las aplicaciones cada vez están más relacionadas, tienen mas interdependencias, y se requiere cada vez más que nos permitan relacionar información entre sistemas, tanto a nivel de datos como a nivel funcional. Nos vamos a centrar en uno de los casos más sencillos y habituales: datos de nuestra base de datos que estén validados o relacionados con datos cuya gestión depende de otros.

Por ejemplo, en las bases documentales es muy habitual manejar el dato "proveedor" o "cliente", como un simple dato asociado a nuestra documentación, pero que queremos que este bien asociado al mismo proveedor o cliente que lleva el resto de la empresa. Por ejemplo, no se podría dar de alta un contrato, sin haberse dado de alta la empresa como proveedor. Pero dicha creación, ¿cuando se verá en el sistema de los contratos? ¿al momento, al rato, al día siguiente, a la semana siguiente?

Cuando me mudé de casa tuve que dar mis nuevos datos a proveedores, bancos,... y en todos ellos, al final la dirección se introduce en una aplicación. Algo sencillo e inmediato, a priori, se convirtió en toda una lotería, ya que hacia poco que habían asignado el código postal a mi nuevo barrio, con lo que muchos sistemas daban por erróneo el código correcto. Años después sigue pasando.
Código postal de la dirección
Código postal de la dirección

Hoy en día uno puede pensar que, nada mas matricular un coche, ya tiene todos los derechos y deberes por tener dicho vehículo, pero resulta que, dependiendo del tramite, ventanilla, impuesto, privilegio,... puede ser instantáneo, tardar un día o  una semana su regularización. ¿Que pasa si no podemos aparcar en nuestro barrio en la zona de aparcamiento restringido (SER, ORA,...) o porque el sistema no reconoce nuestra matricula para saber lo que nos tiene que cobrar?
Matrícula del coche
Matrícula del coche

Pero este problema no es solo del mundo digital. Se ha agrabado por la confianza y automatización cada vez mayor de las empresas, pero también puede pasar con el papel. Hace varios años, cuando tuve que hacer una transferencia al extranjero, quedé sorprendido al ver que de poco valían los datos que daba en la sucursal. Tuvieron que echar mano de un libro aun mas gordo que el de Petete, para localizar un código SWIFT de la sucursal destino en cuestión. ¿Que pasa con todas las sucursales que se crearan entre actualizaciones de dicho libro?

En el fondo es siempre el mismo problema, queremos tener los datos bien, para lo cual muchos campos los definimos como paramétricos o contra tablas, pero algunos de dichos  datos son cambiables y gestionados por otra aplicación. ¿Como aseguramos una base limpia, y bien relacionada con otros sistemas?
En el fondo, dependiendo del caso, hay 2 soluciones:
 1. En linea: siempre que se introduzca un dato, se lanza una validación contra el sistema gestor original
 2. réplica: se mantiene una copia actualizada de los valores válidos, respecto del sistema gestor original

Diferentes soluciones arquitectónicas
Diferentes soluciones arquitectónicas

Dependiendo del caso de uso o arquitectura, la solución mas adecuada puede ser una u otra.

Bases enlazadas
Un caso muy común es que ambos sistemas de datos estén bien comunicados, ya sea por estar en la misma máquina, mismo CPD, mismas instalaciones o compartir algún otro tipo de infraestructura. En tal caso, si la confianza entre ambos sistemas es alta, así como la relación de negocio es también alta, y se emplea el mismo sistema gestor de base de datos, se puede optar por emplear tablas enlazadas a nivel de Base de Datos.

En Oracle este concepto esta bastante evolucionado, permitiendo, desde un motor de base de datos tratar una tabla que se encuentra en otro motor como si fuera interna. Este DBLink se configura y se accede como si fuera otro espacio de tablas mas. Permitiendo numerosas configuraciones y optimizaciones. El mismo concepto existe para MS SQL Server, DB2, o PostgreSQL.

En MySQL, habría que optar por un concepto algo más general, las tablas federadas. En ese caso, el motor de la base de datos no almacenaría información, sino que haría de mero proxy y TODAS las tablas que mostrara estarían gestionadas por otros motores.

Además, si los motores de base de datos no son iguales, pero hay confianza, todavía se podrían enlazar las tablas a nivel de motor de base de datos. Por ejemplo, para ver desde MS SQL Server tablas de un motor Oracle o DB2 habría que instalar un proveedor de OLEDB de dichas tablas. Desde Oracle se pueden enlazar tablas accesibles mediante ODBC,... y así otras múltiples opciones.

En 2003, se definió una extensión al estándar SQL, SQL/MED, para la gestión de datos externos desde nuestro motor de base de datos. Ya ha sido implementado por varios motores, tanto relacionales como no relacionales.

Pero, aunque se haya decido por esta opción, no esta todo cerrado. Puede que la comunicación o que la tasa de actualizaciones sea muy alta / baja y en tal caso, en lugar de un enlace vivo que continuamente muestra o copia datos, sea mejor realizar una copia de los datos. En este caso, si obviamos las opciones automáticas de caché de los motores, se puede hacer uso de disparadores que, ante cualquier cambio en una tabla enlazada, traerían / enviarían información para actualizar la copia local, la cual sería la accedida por las aplicaciones de esta base.
En este caso, podría ser:
  • push, la iniciativa de copiar un dato es del gestor de la tabla original. Sólo cuando cambie un dato de la tabla, conectará con el / los otros sistemas y les enviará el cambio realizado. Esta opción es muy buena para cuando la tasa de cambios es muy baja y no merece la pena ir preguntando continuamente por las novedades.
  • pull, cada uno de los sistemas que quiere copiar la tabla se conectará al sistema y comprobará si ha habido cambios. Esta opción sólo es apta si la tasa de cambios es alta, con lo que no hay tanto desperdicio en las conexiones. También permite que no haga falta registrarse como usuario de un dato, con lo que es más rápido el despliegue, pero por el contrario, por vagos puede que esta laxitud haga que nuestra base de datos de dependencias de los sistemas en el departamento de informática no esté actualizada.
Consulta periódica
Consulta periódica

Pero no todo es perfecto. Esta solución trae consigo un ALTO ACOPLAMIENTO, ya que cambios en el modelo de datos de un sistema pueden implicar cambios en el otro, el cual puede tener otro ciclo de desarrollo. Se pueden minimizar mediante vistas. También puede complicar los mantenimientos de ambos sistemas.

Disminuyendo acoplamiento
Si la conectividad entre ambos sistemas no es buena por lenta, por seguridad, por fiabilidad,... en dicho caso, la única solución es la RÉPLICA. Sería un caso más general que una tabla enlazada a nivel de motor de base de datos. En este caso, ya sea por un evento o periódicamente, se copiarían total o parcialmente los datos.
Habría que hacer un análisis de, tanto la importancia de una sincronización total como de la frecuencia de cambios en los datos origen. Si los datos cambian mucho, o el total de la tabla es pequeña, se podrían realizar copias limpias completas cada vez. Pero si es muy importante que no se cuele ningún caso en nuestro negocio en el que el dato ya no sea válido, o que no se bloquee una operativa importante porque le falta llegar un dato, la sincronización debería ser inmediata.
Para los demás casos, una sincronización diaria, semanal,... dependiendo del volumen y la importancia de los datos. Que podrá ser diferencial o completa.
Dado que los sistemas no son perfectos, y puede haber labores nocturnas de mantenimiento, imprevistos,... :
  • es aún más importante de lo normal mantener un registro e histórico de los últimos intercambios de valores, ya que entre actualizaciones puede detectarse algún caso de falta / error de valores, y se achaque a la propia sincronización.
  • También resulta muy útil permitir que el sistema sea "repetible", esto es, que se pueda volver a cargar el mismo fichero de sincronización tantas veces como haga falta, obteniendo el mismo resultado, si todo fuera bien. De este modo, en caso de algún error temporal se puede volver a lanzar la operación entera en el Gestor de operaciones repetitivas batch, y también nos sirve para, en caso de que se necesite una sincronización intermedia, que se pueda realizar, y luego que se puedan ejecutar los procesos programados.
Estas réplicas implican a los 2 equipos de mantenimiento de ambos sistemas. Uno para generar los datos de exportación a partir de su sistema origen, y otro para cargar y actualizar los datos de su sistema destino.

Dado que los sistemas cada vez colaboran más entre sí, y hay más campos o funcionalidad relacionada, es lógico que en un departamento de informática se hayan disparado el número de procesos de réplica. Por ello se recomienda, tanto una sencilla, precisa y actualizada gestión de dependencias, como que los procesos sean todos gestionados por un mismo sistema. Hoy en día hay multitud de "programadores" de tareas que podrían realizar esta función.

Nada de copias
Pero puede darse el caso de que los datos cambien mucho, o sean de un gran volumen en origen, pero que no todos acaben afectando a nuestro sistema, y no se puedan discernir a priori. En tal caso, mucho mejor es no copiar ni actualizar nada, sino emplear búsquedas y validaciones.
Consulta y validación en el momento
Por ejemplo, a la hora de editar un documento que tenga un campo validado contra tabla, se permitirá al usuario buscar en la tabla, que la aplicación traducirá en llamadas al sistema "remoto". Una vez introducido el valor, este se debería guardar tanto como "índice" interno (el índice único que permite enlazarlo con el sistema remoto), como el literal que ve el usuario. De este modo, si luego cambiara el literal en el lugar de origen, se seguiría manteniendo la integridad.

Otras consideraciones
Como consideración lateral, hay que tener en cuenta un detalle: ¿Qué hacer si en el sistema origen eliminan un valor que antes era válido?
Si todas las tablas formaran parte de nuestro sistema, para cada posible tipo de valor a borrar, habría una posible gestión, la que más se adecue a nosotros, evitando dejar claves sin enlazar,... Pero resulta que ahora hemos enlazado con datos que gestionan otros sistemas, independientes.
Tratamiento general:
  • Copia de tabla. Es el caso en el que más nos hemos centrado. Este es el caso mejor para cuando se van a reutilizar varias veces los mismos datos. Este tabla pasaría a ser una copia de la original salvo por los borrados que, en nuestra tabla sólo se borrarían si no tuvieran dependencias. Tiene el defecto que podría crecer mucho, y convertirse en un histórico de la tabla original
  • Copia literal de los datos. Si no se van a reutilizar muchos datos, o no se quiere gestionar altas / bajas,... se copia directamente el dato que nos interesa, sin dejar enlazado con datos de otros sistemas.
Hay un caso mas: la posible conversión de datos. Por ejemplo,  cuando se crean nuevos códigos postales, es posible que sean un desglose de alguno anterior. Pudiera hacer falta una conversión de valores antiguos a nuevos. Cada posible caso es un mundo y suele hacer falta involucrar a alguien del equipo externo.


Conclusión
Como hemos podido ver, siendo este un caso sencillo de integración de aplicaciones, el tema debe dar para todo un análisis de las necesidades y relaciones de nuestros usuarios y sistemas. Una mala decisión puede llevar a problemas inesperados, tanto técnicos como de negocio.

No hay comentarios: