IV.3. TRADUCTION DU MODELE DE DONNEES SOURCE VERS LE MODELE DE
DONNEES CIBLES
Pour passer d'un modèle relationnel vers un
modèle graphe, nous proposons les différentes étapes
suivantes :
IV.3.1. Traduction des types-entités (ou tables)
Il sied pour nous de rappeler que, la matérialisation
du modèle relationnel est le modèle physique de données
(MPD) si nous nous référons à la méthode Merise.
Alors dans ce cas, on parle des tables en lieu et place du type-entité.
De plus, le type-association du type many to many se transforme en table de
jointure, qui est évidement action très coûteux du point de
vue spatiotemporel.
Règle 4.1 : Lors de la migration du
relationnel vers le graphe, chaque table d'entité est
représentée par une étiquette sur des
noeuds
Exemple 4.3 :
En relationnelle, on a :
Matricule
Nom
Prenom
Personne
NumRegistre
Libelle
Status
Entreprise
Travailler _a
DateEmbauche
DureeContrat
1, n
1, n
Figure 4.6: Type-entité à traduire
: Personne
Matricule : valeur
Nom : valeur
Prenom : valeur
: Entreprise
NumRegistre: valeur
Libelle : valeur
Status : valeur
Travailler_a
DateEmbauche : valeur
DureeContrat: valeur
En graphe, on a :
Figure 4.7: Traduction du type-entité
IV.3.2. Traduction des enregistrements (lignes) d'une table
d'entité
Les enregistrements ou les lignes dans les bases de
données relationnelles sont les éléments qui font beaucoup
plus l'objet des requêtes. Ainsi, chacun de ses enregistrements se
transforment en noeud et les colonnes de ses enregistrements deviennent des
attributs du noeud correspondant. Les attributs à valeur nulle ne sont
pas répétés dans une base de données
orientées-graphe.
Règle 4.2: Lors de la migration du
relationnel vers le graphe, chaque enregistrement dévient un noeud, et
par conséquent chaque colonne sur ces tables devient attribut de
noeud.
IV.3.3. Traduction de la table de jointure
Une table de jointure (Join table ou jonction table) est une
table issue d'un type-association many to many. Cette table contient alors les
clés de chaque table qui agissent sur elle.
Règle 4.3 : Lors de la migration du
relationnel vers le graphe, chaque table de jointure devient une arête,
et ne comporte aucune clé comme attribut. Seuls les attributs du
type-association dont elle provenait sont maintenus comme attributs de
l'arête.
Exemple 4.4 :
En relationnelle, on a les tables suivantes:
|
Personne
|
|
Matricule
|
Nom
|
Prenom
|
|
001A
|
Kamingu
|
Gradi
|
|
002B
|
Pinshi
|
Jonathan
|
|
003C
|
Kadima
|
Gloire
|
|
004D
|
Lukelu
|
L'or
|
|
...
|
...
|
...
|
|
...
|
...
|
...
|
|
Travailler_a
|
|
Matricule
|
NumRegistre
|
DateEmbauche
|
DureeContrat
|
|
001A
|
1
|
1998
|
Ind.
|
|
002B
|
1
|
2003
|
20 ans
|
|
003C
|
2
|
2014
|
10 ans
|
|
004D
|
3
|
2015
|
4 ans
|
|
...
|
...
|
...
|
...
|
|
...
|
...
|
...
|
...
|
|
Entreprise
|
|
NumRegistre
|
Libelle
|
Status
|
|
1
|
Bcorp
|
SARL
|
|
2
|
Shibagu
|
SARL
|
|
3
|
Vodacom
|
SPRL
|
|
...
|
...
|
...
|
|
...
|
...
|
...
|
Figure 4.8: Tables à traduire
: Personne
Matricule : 001A
Nom : Kamingu
Prenom : Gradi
: Entreprise
NumRegistre : 1
Libelle : Bcorp
Statuts : SARL
Travailler_a
DateEmbauche : 1998
DureeContrat : Ind.
: Personne
Matricule : 002B
Nom : Pinshi
Prenom : Jonathan
Travailler_a
DateEmbauche : 2003
DureeContrat : 20 ans
: Personne
Matricule : 003C
Nom : Kadima
Prenom : Gloire
: Personne
Matricule : 004D
Nom : Lukelu
Prenom : L'or
: Entreprise
NumRegistre : 2
Libelle : Shibagu
Statuts : SARL
: Entreprise
NumRegistre : 3
Libelle : Vodacom
Statuts : SPRL
Travailler_a
DateEmbauche : 2014
DureeContrat : 10 ans
Travailler_a
DateEmbauche : 2015
DureeContrat : 4 ans
En graphe, on a :
Figure 4.9: Graphe issu des tables de la figure 4.8
| 
