IV.4. ALGORITHME DE MIGRATION DES DONNEES
Pour rappel, un algorithme est une suite finie
d'opérations permettant de résoudre un problème
donné. Pour ce faire, nous proposons alors l'algorithme suivant
permettant de faire la migration des bases de données relationnelles
vers les bases des données NoSQL du type graphe.
Algorithme 4.1
1. Début
2. Repérer le Modèle EA
3. Pour tout Type-association
3.1. Chaque type-association dévient une arête
3.2. Les types-associations réflexive engendrent deux
noeuds ayant le même étiquette
FinPour
4. Repérer le Modèle physique des données
4.1. Pour Toute Table
4.1.1. Si la Table est une table de jointure
Alors
4.1.1.1. La table dévient une arête (cela se
justifie parce que ladite table était une relation dans le Modèle
EA)
Sinon
4.1.1.2. Chaque ligne de table dévient un noeud dont
l'étiquette est le nom de la table ;
4.1.1.3. Chaque colonne de la table dévient un attribut
du noeud ;
4.1.1.4. Enlever toutes les clés techniques des tables,
ne garder que les clés faisant l'affaire ;
4.1.1.5. Ajouter les index ayant les attributs les plus
fréquents ;
4.1.1.6. Supprimer tous les attributs ayant des valeurs par
défaut, il n'est pas important d'avoir des valeurs comme NULL dans une
base de données graphe.
FinSi
FinPour
5. Ajouter les différentes relations non prises en
charge par le modèle relationnel
6. Fin
IV.5. VALIDATION DE L'APPROCHE PAR ETUDE DE CAS
Notre étude se basera sur l'étude d'un
réseau des entreprises. Ainsi, ce réseau nous permettra :
· De voir les différentes relations
existantes entre les entreprises, les dirigeants des entreprises et les
différentes agents des entreprises ;
· de voir toutes les entreprises remplissant une certaine
condition ;
IV.5.1. Modélisation relationnelle de la base des
données avec le modèle entité-association
L'algorithme commence par le repère du modèle
entité-association. Dans le cas de notre modélisation, le
modèle entité-association sera alors le suivant :
Figure 4.10: Modèle Entité-Association de
l'étude de cas
IV.5.2. Modélisation physique des données
Pour représenter physiquement notre base de
données relationnelle, nous avons utilisé le SGBD Microsoft
Access, dans sa version 2010 pour sa disponibilité dans l'ordinateur et
sa souplesse dans le stockage des données relationnelles. Nous avons
donc cinq tables qui sont :
· Table Entreprise
En mode feuille des données, on a :
· Table Relation
· Table Service
· Table Personne
· Table Etre_en_relation
IV.5.3. Migration des donnéesrelationnelles vers
données orientées-graphe
Pour quitter du modèle relationnel vers le
modèle graphe de notre base de données, nous allons appliquer
l'algorithme 4.1. proposé un peu plus haut. Voici alors la trace pour
notre application :
1. Début
2. On repère le modèle EA, voir la figure
4.10
3. 3.1. Les relations Relation,
Diriger, Travailler, Offrir,
Etre_en_relation deviennent des arêtes.
3.2. Les relations réflexives comme Relation
et Etre_en_relation vont engendrer respectivement
deux noeuds. Pour l'arête Relation, on aura deux noeuds ayant tous les
deux comme étiquette Entreprise. Pour l'arête
Etre_En_Relation, on aura deux noeuds ayant tous les deux comme
étiquette Personne.
4. On repère le MPD explicité au point
IV.5.2.
4.1. Relation est une table de jointure, elle ne fera pas
objet de devenir un noeud, elle était déjà
transformée en arête.
Tous les enregistrements (ou toutes les lignes) deviennent des
noeuds. Pour la table Entreprise (en mode feuille des données), les
lignes de Denomination BCorp, Vodacom, ..., PariFoot
deviennent les noeuds dans notre modèle graphe.
5. On crée un nouvel étiquette
Dirigeant qui aura les mêmes attributs que le noeud
Personne.
D'où le modèle de graphe attribué se
présente alors de la manière suivante :
Est_en_relation
Age
Type_Relation
Travailler
Ancienneté
Type_Contrat
Diriger
Ancienneté
Offrir
Type_Offre
Relation
Type_Relation
Figure 4.11: Modèle de graphe
attribué
| 
