Código Uni y caracteres japoneses
Las codificaciones incompatibles complican la migración de datos desde sistemas distintos
Las diferentes codificaciones son una fuente importante de problemas durante la migración de datos. Entre ellas figuran códigos de caracteres como UTF-8 y ASCII, así como alfabetos diferentes como los utilizados en japonés. Si se fusionan registros de datos de sistemas diferentes, hay que limpiarlos y recodificarlos antes de la migración. Las herramientas de calidad de datos de TOLERANT Software, especialista en software con sede en Stuttgart, pueden servir de ayuda en este caso, ya que son capaces de leer y analizar textos de distintos sistemas de escritura.
Los datos pueden codificarse en distintos códigos de caracteres. Un código de caracteres internacional común es el Uni-Code UTF-8 codificado en 8 bits. En este estándar se define un código específico para cada elemento de texto de todas las culturas de escritura y sistemas de caracteres conocidos. El número total de caracteres definidos en UTF-8 es de 28 = 256 caracteres. Un código de caracteres predecesor y aún muy utilizado es el código ASCII de 7 bits, que puede representar 27 = 128 caracteres. Los problemas surgen cuando los registros de datos codificados en UTF-8 se integran en una base de datos codificada en ASCII. El código ASCII no puede leer los registros de datos integrados y, por tanto, no puede reconocer los duplicados.
¿Se han registrado dos veces?
Los duplicados son registros de datos que aparecen dos veces en una base de datos. El reconocimiento de duplicados es un componente esencial que debe tenerse en cuenta a la hora de fusionar datos, ya que es la única forma de evitar problemas de calidad de los datos, como la introducción duplicada de clientes. Los clientes duplicados que reciben una factura más de una vez, por ejemplo, se molestan rápidamente y amenazan con darse de baja. Para evitarlo, antes de migrar los datos hay que asegurarse de que las codificaciones sean compatibles. En caso contrario, habrá que recodificarlos antes de la migración.
Cómo se preparan los datos
En un proceso ETL, los datos brutos se preparan antes de la migración y se convierten en un archivo ASCII o UTF. La abreviatura ETL hace referencia a los tres procesos de migración de datos: extracción (E), transformación (T) y carga (L), que suelen ejecutarse cuando se transfieren datos de un sistema a otro. Los procesos ETL están orientados a lotes, es decir, sólo se ejecutan en un periodo de tiempo predefinido y preparan una cantidad limitada de registros de datos. La actualidad de los datos de los procesos ETL es, por tanto, limitada.
Durante el proceso de preparación, los datos se extraen (E), se transforman (T) y se cargan (L). Ilustración: © TOLERANT Software
Duplicados japoneses
Sin embargo, los duplicados no sólo se deben a codificaciones diferentes; también pueden estar determinados culturalmente. En japonés, por ejemplo, hay tres alfabetos y los tres se utilizan combinados en los textos japoneses. Las palabras de origen chino suelen escribirse en el alfabeto de símbolos kanji, las palabras gramaticales como preposiciones o terminaciones verbales se escriben en el alfabeto hiragana y los japoneses utilizan el alfabeto katakana para las palabras extranjeras procedentes del inglés. Como la pronunciación de los caracteres kanji no siempre es clara ni siquiera para los hablantes nativos, los nombres escritos en kanji suelen transcribirse también en los alfabetos silábicos hiragana o katakana. Al igual que ocurre con el Uni-Code, se producen duplicados en los registros de datos japoneses cuando los nombres transcritos no se asignan a sus equivalentes en kanji. A partir de tres ejemplos, presentamos los retos que plantea la lengua japonesa para la migración de datos y cómo pueden surgir duplicados.
Cinco grafías para un mismo nombre
Un ejemplo es el nombre 髙橋 眞國 (Takahashi Makuni). En este ejemplo, el primer carácter kanji 髙 está escrito en una variante de kanji tradicional, como la que se utiliza en el registro familiar. Dependiendo de la máquina, el carácter kanji también puede escribirse de una forma ligeramente diferente 高. También existe un equivalente moderno para los caracteres kanji tradicionales 眞國 en la segunda parte del nombre, que tiene este aspecto 真国. En el alfabeto silábico Katakana, el nombre completo se transcribiría como タカハシ マサクニ, y en el alfabeto silábico Hiragana quedaría como soたかはし まくに. Durante la migración de datos, ahora es importante vincular los 5 conjuntos de datos diferentes del mismo nombre (es decir, kanji tradicional, kanji moderno, katakana, hiragana y, por último, la variante escrita en letras latinas) de tal manera que siempre se puedan encontrar y asignar correctamente, independientemente de la entrada de datos. La consecuencia de un eslabón perdido serían cinco duplicados.
Reconocimiento de duplicados tolerante a errores
Otro reto que plantea la escritura japonesa es el reconocimiento de duplicados difuso o tolerante a errores. Una búsqueda es difusa o tolerante a errores si se encuentran duplicados incluso en caso de introducción incorrecta de datos (por ejemplo, letras mal escritas, errores tipográficos o diferencias ortográficas mínimas). Además de tres alfabetos diferentes, la escritura japonesa también distingue entre mayúsculas y minúsculas. Cuando los sonidos hiragana よ(yo)、や (ya) yゆ (yu), así como los sonidos katakanaヨ (yo)、ヤ (ya) y ユ(yu) se funden con una consonante, se escriben con un tamaño de letra ligeramente menor. Un ejemplo es el nombre 中島 京子 (Nakashima Kyoko), que se transcribe en hiragana como なかしま きょこ y en katakana como ナカシマ キョウコ. Los caracteres ょ y ョ siguen a きy キ respectivamente, por lo que se escriben ligeramente más pequeños. Si estos caracteres se escriben en mayúsculas, el nombre del ejemplo anterior se transcribiría incorrectamente como «Nakashima Kiyoko». El reto a la hora de migrar registros de datos japoneses es, por tanto, reconocer duplicados incluso con ligeras diferencias ortográficas (como mayúsculas y minúsculas) y seguir asignándolos a los caracteres kanji correctos.
Diferentes lecturas de kanji
Por último, las diferentes lecturas de los caracteres kanji suponen un reto especial para el reconocimiento de duplicados en japonés. Por ejemplo, el nombre 東海林太郎 puede leerse y pronunciarse como Shouji Tarō o como Taorin Tarō. Para dominar con éxito la tarea de migración de datos, las herramientas de calidad de datos deben ser capaces de identificar la transcripción katakana ショウジ タロウ (Shouji Tarō) y la variante トウカイリン タロウ(Taorin Tarō) como lecturas diferentes del mismo carácter kanji y reconocerlas como duplicados..
Conclusión
Los problemas con la migración de datos pueden evitarse comprobando los registros de datos de diferentes bases de datos antes de fusionarlos. Los códigos de caracteres incompatibles deben limpiarse mediante procesos ETL antes de la migración de datos y recodificarse si es necesario. Las herramientas de calidad de datos que pueden manejar y leer los tres sistemas de escritura japoneses ayudan a evitar errores durante la migración de datos. El especialista en calidad de datos TOLERANT Software está especializado en diferentes sistemas de escritura y codificaciones de muchos países y culturas. Las herramientas de calidad de datos de TOLERANT Software eliminan los problemas lingüísticos específicos de las codificaciones incompatibles en muchos países y culturas diferentes.
