5. Intégration et migration des bases de données
177
Assurer la
conformité du
système cible à
l’architecture de
données
Affiner l’architecture de données globale de l'entreprise : tous
les ensembles d'entités et de liens qui font l'objet de l’intégration
ou de la migration doivent être affinés par rapport à
l’architecture de données globale de l'entreprise, puis
transformés en un schéma de base de données relationnelle.
Sélectionner les
types de mise en
correspondance
Fixer les règles de mise en correspondance des système source et
cible : le schéma de base de données relationnelle du système
cible, dérivé de l’architecture de données globale de l'entreprise,
est comparé aux bases de données existantes du système source.
À chaque divergence, il faut déterminer parmi les types de
transformation disponibles, celui qui mène au schéma de base de
données relationnelle du système cible désiré.
Il est possible de
combiner les
variantes
d’intégration et de
migration
Choisir les variantes d’intégration et de migration : il faut
décider d'une stratégie d’intégration et de migration adaptée à
chaque situation particulière. Elle peut être une combinaison de
plusieurs variantes. En outre, dans la solution de coexistence, il
faut opter pour l'un des deux modes de duplication, synchrone ou
asynchrone. Avec la duplication synchrone, les données seront
toujours actualisées et cohérentes dans les deux bases de
données, relationnelle et non relationnelle. La duplication
asynchrone est concevable si la propagation périodique des
modifications vers la base de données relationnelle du système
cible s'avère suffisante.
Corriger le système
source en cas de
besoin
Résoudre les problèmes de mise en correspondance : si aucune
règle de conversion ne peut s'appliquer à certains types
d'enregistrements particuliers, deux solutions sont possibles. La
première consiste à rénover la base de données non relationnelle
(ce qui entraîne l'adaptation éventuelle de certaines
applications). La seconde consiste à développer des règles de
conversion spécialement destinées aux types d'enregistrements
en question. Dans le système cible nous devons aussi spécifier
des contraintes d'intégrité référentielle qui correspondent aux
règles de traitement définies dans les bases de données du
système source.
177
Assurer la
conformité du
système cible à
l’architecture de
données
Affiner l’architecture de données globale de l'entreprise : tous
les ensembles d'entités et de liens qui font l'objet de l’intégration
ou de la migration doivent être affinés par rapport à
l’architecture de données globale de l'entreprise, puis
transformés en un schéma de base de données relationnelle.
Sélectionner les
types de mise en
correspondance
Fixer les règles de mise en correspondance des système source et
cible : le schéma de base de données relationnelle du système
cible, dérivé de l’architecture de données globale de l'entreprise,
est comparé aux bases de données existantes du système source.
À chaque divergence, il faut déterminer parmi les types de
transformation disponibles, celui qui mène au schéma de base de
données relationnelle du système cible désiré.
Il est possible de
combiner les
variantes
d’intégration et de
migration
Choisir les variantes d’intégration et de migration : il faut
décider d'une stratégie d’intégration et de migration adaptée à
chaque situation particulière. Elle peut être une combinaison de
plusieurs variantes. En outre, dans la solution de coexistence, il
faut opter pour l'un des deux modes de duplication, synchrone ou
asynchrone. Avec la duplication synchrone, les données seront
toujours actualisées et cohérentes dans les deux bases de
données, relationnelle et non relationnelle. La duplication
asynchrone est concevable si la propagation périodique des
modifications vers la base de données relationnelle du système
cible s'avère suffisante.
Corriger le système
source en cas de
besoin
Résoudre les problèmes de mise en correspondance : si aucune
règle de conversion ne peut s'appliquer à certains types
d'enregistrements particuliers, deux solutions sont possibles. La
première consiste à rénover la base de données non relationnelle
(ce qui entraîne l'adaptation éventuelle de certaines
applications). La seconde consiste à développer des règles de
conversion spécialement destinées aux types d'enregistrements
en question. Dans le système cible nous devons aussi spécifier
des contraintes d'intégrité référentielle qui correspondent aux
règles de traitement définies dans les bases de données du
système source.