Lorsque le problème paraît

niveau schéma Ce type de comparaison établit une correspondance entre les noms de tables d’une base de données et ceux de l’autre. Les tables concordantes sont contrôlées afin de s’assurer que leur schéma est identique, autrement dit qu’elles contiennent le même nombre de colonnes et que les noms de celles-ci et les domaines correspondent. Ce processus compare également les contraintes sur les bases de données. Le résultat de la comparaison au niveau schéma indique au DBA les différences existant au niveau structurel entre les bases de données rapprochées. Par exemple, il peut faire apparaître qu’une table spécifique présente dans deux bases de données inclut une colonne située dans l’une seulement des bases de données, comme l’illustre la figure 2, ou que le type de données d’une colonne particulière a changé. Vous pouvez employer ces différences de schéma pour synchroniser les schémas des deux bases de données.

Des outils de comparaison, notamment Change Manager d’Embarcadero, SQL Compare de Red Gate Software, DB SynchroComp de E-Dule ou Diff d’AdeptSQL, sont capables d’identifier rapidement les tables dont certains équivalents manquent dans l’une des bases de données à examiner. Toutefois, les outils de comparaison considèrent généralement uniquement le nom de la table et peuvent donc passer à côté de tables renommées. Ils n’essaient pas d’établir automatiquement une correspondance entre les tables pour la raison suivante : bien qu’il soit possible de deviner le nom de la table équivalente dans certaines circonstances, cette opération peut manquer de fiabilité. Ainsi, des tables identiques d’un point de vue structurel, mais représentant des concepts différents peuvent être synchronisées, aboutissant ainsi à des données corrompues. La synchronisation automatique des données entre deux tables aléatoires dont les schémas semblent extrêmement similaires constitue la dernière chose qu’un DBA aura envie de faire.

Pendant la comparaison au niveau schéma, l’outil employé peut identifier de nombreux problèmes d’hétérogénéité sémantique relevant des types conflits de noms, conflits de métadonnées et conflits structurels. En revanche, la majorité des conflits de domaines peuvent rester non détectés. Vous pourrez résoudre ces derniers avec le niveau suivant de comparaison de base de données.

Comparaison au niveau données Ce type de comparaison pour une table dans chaque base de données classe les lignes dans l’une des trois catégories suivantes :

1. La ligne existe dans la première base de données et n’a pas d’équivalent dans la deuxième.

2. La ligne existe uniquement dans la deuxième base de données.

3. La ligne existe dans les deux bases de données et soit elle est identique, soit des parties de celle-ci diffèrent (à savoir, certaines colonnes contiennent des valeurs différentes). Vous noterez que cette troisième classification part de l’hypothèse que les lignes comparées peuvent être identifiées de manière univoque au sein de la table, généralement au moyen d’une clé primaire. En règle générale, les outils de comparaison de données du commerce requièrent la présence d’une clé primaire sur les tables dont les données doivent être comparées.

Vous pouvez exploiter les différences identifiées par les outils de comparaison pour synchroniser les bases de données au niveau des données. La figure 3 illustre un exemple de ce type de différences identifiées. Mais les données ou les schémas de bases de données sont-ils corrects après une telle synchronisation ?

Vous pouvez représenter les valeurs de données de deux manières distinctes. La première est une différence structurelle. Par exemple, il est possible de représenter un nom sous la forme d’une chaîne ou de deux chaînes (contenant les prénom et nom). Heureusement, les outils de comparaison sont capables d’identifier bon nombre des différences de représentation structurelle au cours de la comparaison au niveau schéma. La fusion de telles données impose au DBA de spécifier des routines de conversion ad hoc, par exemple une qui fractionne les noms complets en deux parties (prénom et nom) ou joint les prénom et nom afin de former un nom complet.

Le deuxième type de différence survient lorsque l’interprétation des valeurs diffère, comme c’est le cas pour les degrés Celsius et Fahrenheit. Vous pouvez stocker une telle valeur en utilisant un type de données en virgule flottante tel que real. Dans ce cas, les outils de comparaison automatique ne peuvent pas détecter les différences entre les schémas des deux tables contenant ce type de données. Si vous identifiez manuellement cette différence, vous devez fournir une fonction de conversion qui change la valeur de température d’une interprétation dans l’autre. Comme les outils de comparaison automatique ne peuvent pas détecter les problèmes d’hétérogénéité sémantique, vous devez créer manuellement ces fonctions de conversion et les ajouter aux scripts de synchronisation ou de migration.

Malheureusement, il n’est pas toujours possible de créer une fonction de conversion travaillant dans les deux sens sans perdre de données. Si, par exemple, votre base de données stocke les valeurs de température sous forme d’entiers, la conversion en degrés Celsius d’une valeur exprimée en degrés Fahrenheit et inversement peut aboutir à une valeur finale différente de la valeur d’origine. Par exemple 101 °F = 38,3333 °C, ce qui donne 38 °C une fois arrondi ; toutefois 38 °C = 100,4 °F, ce qui en arrondissant donne 100 °F et non pas 101 °F.

Dans certains cas, il est impossible de fournir de telles fonctions de conversion. Une concaténation de chaîne avec des limites inconnues n’a pas d’inverse. Vous pouvez joindre deux chaînes « ab » et « cdef » pour former « abcdef », mais vous ne pouvez pas procéder dans l’autre sens pour obtenir la valeur des deux chaînes d’origine si vous n’avez aucune information sur le point de fractionnement de « abcdef ».