CHAPITRE4
APPLICATION
L
es bases de données relationnelles sont encore de plus
en plus utilisées dans la plupart des entreprises tant publiques que
privées, alors que beaucoup de ces entreprises ne savent pas encore rien
de l'importance et des cas d'usage des bases de données
orientées-graphe. Dans la plupart des cas, ces entreprises n'ont
même pas entendu parler de ces types de bases de données. Les
entreprises ou en général les organisations ayant entendu parler
de ces types des bases de données désirent ainsi migrer de leurs
bases des données pour rejoindre les grandes familles des bases
graphes.
Ainsi, dans ce chapitre, il sera question de montrer comment
peut-on passer des bases de données relationnelles vers les bases de
données orientées-graphe. On se propose une approche qui permet
de prendre une base de données existante comme entrée, en
utilisant évidemment son Modèle Entité-Association, plus
particulièrement le modèle conceptuelle des données et/ou
son modèle physique des données de la méthode Merise et
ensuite générer un Modèle de Graphe Attribué. Pour
rendre les choses plus claires, nous allons montrer à l'aide d'un
algorithme comment se fait cette migration.
Enfin du chapitre, on validera l'approche par une étude
de cas consistant à faire migrer une base de données conçu
par l'approche modèle relationnel vers l'approche modèle
graphe ; et valider l'approche par une étude de cas.
IV.1. PRESENTATION DE L'APPROCHE
IV.1.1. Introduction
Dans ce paragraphe, nous allons présenter l'approche de
migration que nous proposons pour quitter des bases des données
relationnelles vers les bases des données orientées-graphe. Les
types de bases des données étant différents ; les
exigences ainsi que les performances étant aussi différentes, il
ressort de savoir que le processus de migration d'une base des données
vers une autre est très complexe, et généralement pas
très direct.
De ce fait, quelques transformations à tous les niveaux
sont alors nécessaires pour avoir un modèle cohérent et
sans perte d'informations. Car, il suffit de voir d'une manière triviale
que les types de conception des bases de données sont différents
et on ne peut pas seulement faire des correspondances, mais il faut aussi
adjonction ou omission des certaines choses. Ainsi, il faut avoir la maitrise
du modèle de données source et du modèle de données
cible.
IV.1.2. Modèle de données source
Le modèle de données source que nous devons
parler ici est le modèle relationnelle. La conception d'une base de
données relationnelle, en utilisant la méthode Merise s'effectue
en quatre niveaux (conceptuel, organisationnel, logique et physique). Comme la
méthode Merise utilise le modèle Entité-Association, nous
allons alors utiliser le Modèle Entité-Association comme notre
modèle source.
On pouvait utiliser normalement comme schéma de
données source le modèle physique de données (MPD),
c'est-à-dire le scripte de la base de données relationnelle. Mais
l'inconvénient est que ce dernier peut varier d'un SGBD à l'autre
même si le langage standard reste le SQL. Par ailleurs, le modèle
de données relationnel, introduit par Codd représente une base de
données comme une collection de relations d'où le nom de base de
données relationnelle. [KO12] C'est la raison pour laquelle, on prend un
modèle plus général qu'est le modèle
Entité-Association, le Modèle conceptuel des données (MCD)
et le MPD seront utilisé d'une manière particulière et
pourront aussi nous aider.
Le modèle Entité-Association (qu'on note EA) est
aussi fréquemment nommé Entité-Relation et parfois
Entité-Relation-Attribut. Le modèle EA propose des concepts
(principalement les entités, les associations et les attributs)
permettant de décrire un ensemble de données relatives à
un domaine défini afin de les intégrer ensuite dans une base de
données. Le modèle EA a été inventé par
Peter Chen en 1975 ; il est destiné à clarifier
l'organisation des données dans les bases de données. Ce
modèle est à la base de plusieurs méthodes de
modélisation d'analyse/conception comme OMT, CASE, MERISE, etc. [KA13]
Les concepts clés de ce modèle sont :
· typeEntité
Une entité est un objet, une chose
concrète ou abstraite qui peut être reconnue distinctement. Un
type-entité est un ensemble d'entités qui
possèdent les mêmes caractéristiques.
Figure 4.1 : Représentation du diagramme type
entité
· Une association (ou une
relation) est un lien entre plusieurs entités. Un
type-association (ou un type-relation) est un
ensemble de relations qui possèdent les mêmes
caractéristiques ; c'est un lien existant entre plusieurs
types-entités.
· Un attribut (ou une
propriété) est une caractéristique
associée à une entité ou une association.
Attribut 1
Attribut 2
...
typeEntité 1
Attribut 1
Attribut 2
...
typeEntité 2
typeAssociation
Attribut 1
Attribut 2 ...
Figure 4.2 : Représentation des
types-entités et type-association avec les attributs
· Un identifiant d'un type-entité
ou d'un type-association est constitué par un ou plusieurs de ses
attributs qui doivent avoir une valeur unique pour chaque type-entité ou
type-association de ce type ;
· La cardinalité d'une
association est le nombre de fois minimal et maximal qu'une entité peut
intervenir dans une association de ce type.
L'expression de la cardinalité est obligatoire pour
chaque patte d'un type-association.
La cardinalité minimale peut-être :
§ 0 Cela signifie qu'une entité peut
exister tout en étant impliquée dans aucune
association ;
§ 1 Cela signifie qu'une entité ne peut
exister que si elle est impliquée dans au moins une
association ;
§ n Cela signifie qu'une entité ne peut
exister que si elle est impliquée dans plusieurs
associations.
De ce fait, on distingue trois types de
types-associations :
Ø Type-association du plusieurs à
plusieurs (many to many) : ici, deux types-entités 1 et 2
sont reliées et on peut correspondre plusieurs instances du
type-entité 2 et inversement.
Attribut 1
Attribut 2
...
Entité 1
Attribut 1
Attribut 2
...
Entité 2
typeAssociation
Attribut 1
Attribut 2 ...
1, n
1, n
Figure 4.2: Association many to many
Ø Type-association du plusieurs à un ou
un à plusieurs (many to one ou one to many) : ici, deux
types-entités 1 et 2 sont reliées et pour une instance
donnée du type-entité 1, peut correspondre plusieurs instances de
du type-entité 2. Et chaque entité de 2 correspond une et une
seule instance du type-entité 1.
Attribut 1
Attribut 2
...
typeEntité 1
Attribut 1
Attribut 2
...
typeEntité 2
typeAssociation
Attribut 1
Attribut 2 ...
1, 1
1, n
Figure 4.3: Association many to one
Ø Type-association du un à un (one to
one) : ici, deux types-entités sont reliées et
lorsque pour une instance donnée de du type-entité 1, correspond
une et une seule instance du type-entité 2 et inversement.
Attribut 1
Attribut 2
...
typeEntité 1
Attribut 1
Attribut 2
...
typeEntité 2
typeAssociation
Attribut 1
Attribut 2 ...
1, 1
1, 1
Figure 4.4: Association one to one
Nota : Par abus de langage, on
utilise souvent le mot entité en lieu et place du mot
type-entité, et on utilise souvent le mot association en lieu et place
du mot type-association, il faut cependant prendre garde à ne pas
confondre ces différents concepts.
Exemple 4.1 : Personne, Automobile,
Région, ... sont des types-entité tandis que Glodi Kamingu,
maVoiture, Kinshasa, ... sont des entités.
Exemple 4.2 : Le mariage de deux
personnes, le transport d'un produit vers un entrepôt, l'affectation d'un
employé à un service sont des types-association tandis que
mariage de Ronny et Marielle, le transport de la Clio 3333 XR 06 vers le
dépôt de Matete, le fait que Pupa travaille au service
Informatique sont des associations.
Ce que nous pouvons dire d'une manière très
simple, en terme de programmation orientée-objet, un type-entité
est vu comme une classe et une entité est vu comme un objet, ou instance
du type-entité.
| 
