Codes unis et caractères japonais
Les codages non compatibles compliquent la migration des données de différents systèmes
Les différents codages sont des sources d’erreurs importantes de problèmes lors de la migration des données. Il s’agit de codes de caractères tels que UTF-8 et ASCII, mais aussi d’alphabets différents comme ceux utilisés en japonais par exemple. Si des jeux de données provenant de différents systèmes sont réunis, ils doivent donc être nettoyés et recodés avant la migration. Les outils de qualité des données de TOLERANT Software, spécialiste en logiciels basé à Stuttgart, peuvent aider dans cette tâche, car ils peuvent lire et évaluer des textes issus de différents systèmes d’écriture.
Les données peuvent être encodées dans différents codes de caractères. L’un des codes de caractères les plus courants au niveau international est le code universel UTF-8 codé sur 8 bits. Dans cette norme, un code spécifique est défini pour chaque élément de texte de toutes les cultures d’écriture et systèmes de caractères connus. Le nombre total de caractères définis dans l’UTF-8 est de 28 = 256 caractères. Le code ASCII codé sur 7 bits, qui peut représenter 27 = 128 caractères, est un prédécesseur et un code de caractères encore très répandu. Des problèmes surviennent lorsque des enregistrements codés en UTF-8 sont intégrés dans une base de données codée en ASCII. Le code ASCII ne peut pas lire les enregistrements intégrés et ne peut donc pas reconnaître les doublons.
Saisi en double ?
Les doublons ou les doublons sont des enregistrements qui apparaissent deux fois dans une base de données. La détection des doublons est un élément indispensable à prendre en compte lors de la fusion des données, car c’est la seule façon d’éviter les problèmes de qualité des données tels que la double saisie des clients. Les clients gérés à double, qui reçoivent par exemple plusieurs fois une facture, sont sinon rapidement irrités et risquent de partir. Pour éviter cela, il faut veiller, avant même la migration des données, à ce que les encodages de données soient compatibles. Dans le cas contraire, elles doivent être recodées avant la migration.
Comment les données sont préparées
Dans un processus appelé ETL, les données brutes sont préparées avant la migration et transférées au choix dans un fichier ASCII ou dans un fichier UTF. L’abréviation ETL désigne les trois processus de migration de données, à savoir l’extraction (E), la transformation (T) et le chargement (L), qui sont généralement suivis lorsque des données sont transférées d’un système à un autre. Les processus ETL sont orientés vers le traitement par lots, c’est-à-dire qu’ils ne se déroulent que dans un laps de temps défini au préalable et préparent un volume limité de jeux de données. L’actualité des données des processus ETL est donc limitée.
Pendant le processus de préparation, les données sont extraites (E), transformées (L) et chargées (L). Illustration : © TOLERANT Software
Doublons japonais
Les doublons ne sont pas uniquement dus à des codages différents ; ils peuvent également être dus à la culture. En japonais, par exemple, il existe trois alphabets et tous trois sont utilisés de manière combinée dans les textes japonais. Les mots d’origine chinoise sont généralement écrits dans l’alphabet symbolique kanji, les mots grammaticaux tels que les prépositions ou les terminaisons de verbes sont notés dans l’alphabet hiragana et les Japonais utilisent l’alphabet katakana pour les mots étrangers provenant de l’anglais. Comme la prononciation des caractères kanji n’est pas toujours évidente, même pour les locuteurs natifs, les noms notés en kanji sont souvent transcrits en plus dans les alphabets syllabiques hiragana ou katakana. Comme pour l’uni-code, des doublons apparaissent dans les enregistrements japonais lorsque les noms transcrits ne sont pas associés à leurs équivalents en kanji. A l’aide de trois exemples, nous présentons les défis que pose la langue japonaise pour la migration de données et comment des doublons peuvent apparaître.
Cinq orthographes pour un seul et même nom
Prenons l’exemple du nom 髙橋 眞國 (Takahashi Makuni). Dans cet exemple, le premier caractère kanji 髙 est noté dans une variante traditionnelle du kanji, telle qu’elle est utilisée par exemple dans le registre des familles. En fonction de la machine, le caractère kanji, légèrement différent, peut également être écrit de la manière suivante 高. Il existe également un équivalent moderne pour le caractère kanji traditionnel 眞國 dans la deuxième partie du nom, qui se présente ainsi 真国. Dans l’alphabet syllabique katakana, le nom complet serait transcrit comme タカハシ マサクニ, et dans l’alphabet syllabique hiragana, il ressemblerait à soたかはし まくに. Lors de la migration des données, il s’agit maintenant de relier les 5 jeux de données différents au total du même nom (c’est-à-dire le kanji traditionnel, le kanji moderne, le katakana, l’hiragana et finalement la variante écrite en caractères latins) de manière à ce qu’ils soient toujours retrouvés et correctement attribués – indépendamment de la saisie des données. La conséquence d’une absence de lien serait cinq doublons.
Détection des doublons à tolérance de fautes
Un autre défi de l’écriture japonaise est la détection floue ou tolérante aux erreurs des doublons. Une recherche est floue ou tolérante aux erreurs lorsque des doublons sont trouvés même en cas d’erreur de saisie des données (comme par exemple des erreurs de lettres, des fautes de frappe ou des différences minimes dans l’orthographe). L’écriture japonaise distingue en partie, outre trois alphabets différents, les majuscules et les minuscules. Lorsque les sons hiragana よ(yo)、や (ya) etゆ (yu) ainsi que les sons katakanaヨ (yo)、ヤ (ya) et ユ(yu) se fondent dans une consonne, ils s’écrivent en caractères légèrement plus petits. Un exemple est le nom 中島 京子 (Nakashima Kyoko), qui est transcrit en hiragana comme なかしま きょこ et en katakana comme ナカシマ キョウコ. Les caractères ょ et ョ suivent respectivement きet キet sont donc écrits en caractères légèrement plus petits. Si ces caractères sont écrits en majuscules, le nom de l’exemple ci-dessus serait transcrit de manière erronée en « Nakashima Kiyoko ». Le défi lors de la migration de données japonaises consiste donc à reconnaître les doublons même en cas de légères différences dans l’orthographe (comme par exemple les majuscules et les minuscules) et à les attribuer malgré tout aux caractères Kanji corrects.
Différents types de lecture des kanjis
Enfin, les différents modes de lecture des caractères kanji constituent un défi particulièrement difficile à relever pour la détection des doublons en japonais. Par exemple, le nom 東海林太郎 peut être lu et prononcé soit comme Shouji Tarō, soit comme Taorin Tarō. Pour réussir la tâche de migration des données, les outils de qualité des données doivent être capables d’identifier la transcription en katakana ショウジ タロウ (Shouji Tarō) et la variante トウカイリン タロウ(Taorin Tarō) comme des lectures différentes du même caractère kanji et de les reconnaître comme des doublons.
Conclusion
Les problèmes de migration de données peuvent être évités en vérifiant les enregistrements de différentes bases de données avant de les fusionner. Les codes de caractères incompatibles doivent être nettoyés et, le cas échéant, recodés avant la migration des données à l’aide de processus ETL. Les outils de qualité des données qui maîtrisent et peuvent lire les trois systèmes d’écriture japonais permettent d’éviter les erreurs lors de la migration des données. Le spécialiste de la qualité des données TOLERANT Software est spécialisé dans différents systèmes d’écriture et codages dans de nombreux pays et cultures. Les outils de qualité des données de TOLERANT Software éliminent les problèmes spécifiques liés à la langue et aux codages incompatibles dans de nombreux pays et cultures différents.
