Mobility Overhead Over IEEE 802.15.4e LLDN

En todo buen diseño de una base de datos relacional se debe prestar especial atención a la definición de los identificadores o claves únicas que se van a usar en cada una de las tablas.

Una clave única debe ser precisamente eso, única e invariable. A veces nos encontramos con diseños de bases de datos en las que como identificador único se está usando un dato que en un principio se pensó que era invariable, pero que con el transcurso del tiempo ha aparecido algún proceso o funcionalidad que solicita su modificación. Ejemplo de este error es usar como identificador único un número de teléfono, en una tabla donde se almacenan clientes. Al final, cuando aparece la necesidad, o más bien, la posibilidad como proceso de negocio, de cambiarle el número de teléfono a un cliente, nos vemos obligados a cambiar la clave única de un registro de la base de datos, o bien, dependiendo de las restricciones que tenga, deberemos borrar el registro y crear uno nuevo (teniendo en cuenta de que se trata del mismo cliente).

Para evitar estos problemas sobre los identificadores únicos de las entidades modeladas, lo mejor es que dichos identificadores únicos representen valores que no tienen ningún sentido en el negocio de

la operadora. Es decir, por ejemplo, que sean secuencias numéricas sin ningún otro significado que tener un valor único para cada uno de los registros de la tabla en la que se encuentran.

Además, puesto que los datos comunes se comparten entre varios sistemas, es conveniente definir identificadores externos, que serían identificadores propios de cada uno de los sistemas que comparten una cierta información común. Estos identificadores externos estarían definidos como atributos secundarios, puesto que el identificador principal sería el identificador único inicial. Por ejemplo, en una tabla de clientes que estuviese compartida por dos sistemas de gestión diferentes A y B, podríamos tener:

un identificador único (ID) que sería un número secuencial,

un identificador externo propio del sistema A (ID_EXT_A), que podría ser un Código de Cliente que siguiera una cierta lógica en sus valores,

y un identificador externo propio del sistema B (ID_EXT_B), que podría tomar los valores del DNI del cliente.

El uso adicional de identificadores externos facilita el trasiego de datos unívoco entre sistemas. Cada registro de la tabla de clientes estaría unívocamente identificado con el ID. Cuando ese registro lo lee, lo consulta, o es volcado hacia el sistema A, este sistema podrá saber que ese registro es único fijándose en el campo ID (más allá de eso, este campo no tiene ningún otro significado para el sistema A), pero además podrá incorporarlo a sus procesos internos porque viaja unido al valor de ID_EXT_A, el cual sí que tiene significado dentro del sistema A.

Así, no existe ningún problema si en el sistema A aparece en algún momento la necesidad de un proceso que permita cambiar el valor del Código de Cliente de un registro. Puesto que éste simplemente es un identificador externo, en el modelo de datos comunes, el identificador único ID seguirá invariable para ese registro.

Una vez expuesta la problemática del tema de los identificadores, siguiendo en el escenario de replicación o compartición de datos comunes entre varios sistemas, nos encontraremos con el problema de traducciones o transformaciones de datos. Ya hemos hablado en parte de este tema, en el apartado de “idioma común”. Una vez reconocidos los campos o atributos, residentes en diferentes sistemas, pero que representan la misma información, es muy probable que sea necesario aplicar algún tipo de transformación del dato para poder volcarlo de un sistema a otro. Cuando trabajamos con sistemas que ya existían previamente, y pretendemos integrarlos entre sí, dentro del mismo mapa de sistemas, intercambiando datos entre ellos, será necesario resolver este problema de traducciones de datos.

A veces, la traducción será simplemente un cambio de formato. Podría ser por ejemplo, completar con ceros a la izquierda un determinado valor numérico, hasta completar una cierta cantidad de dígitos. O cambiar los valores de un dato que en un sistema se encuentra como “Sí”/ “No”, y en otro se encuentran como “S”/ “N”, o como “True”/ “False”. O cambiar el formato de un dato de tipo fecha u hora.

Otras veces la traducción puede ser más compleja. Podríamos tener casos en los que el valor de un cierto campo en el sistema destino, depende de la combinación de valores de varios campos del sistema origen. Por ejemplo, el sistema origen podría tener inventariado, en campos separados, por

un lado el Modelo de un equipo (valores posibles: DSLAM, Switch, etc.), y por otro lado el Fabricante (valores posibles: ALLU, Ericsson, etc.), mientras que el sistema destino podría tener ambas informaciones mezcladas en un solo campo, teniendo ese campo acrónimos como valores posibles (DS-ALLU, Sw-Eric, etc.). Aunque pueda parecer extraño, es muy normal encontrar situaciones de este tipo en los escenarios de integración de sistemas, ya que es muy habitual encontrar que, cuando se diseña un sistema, se piensa más en solucionar de la manera más fácil posible el problema para el que está destinado, que en facilitar la vida para una hipotética futura integración con otro sistema.

En definitiva, podríamos encontrarnos con reglas de traducción de valores bastante complejas, con la consiguiente carga computacional que añadirán a los volcados periódicos. Es necesario revisar al máximo dichas reglas, quedarse sólo con las que sean estrictamente necesarias, y optimizarlas para no comprometer el tiempo de ejecución de cada volcado de inventario.