WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Base des données orientées-graphe: migration du relationnel vers le noSQL

( Télécharger le fichier original )
par Lubwele Kamingu
Université de Kinshasa - Licence (Bac + 5) 2014
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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é.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Le don sans la technique n'est qu'une maladie"