Modélisation de bases NoSQL

Ahlem Bouziri 2 ING 2023-2024

1
Introduction
➔ La notion de document est à la base de la représentation des
données dans les BD NoSQL.

➔ Cette notion couvre la large palette des situations rencontrées:

◆ une valeur atomique (un entier, une chaîne de caractères) est un document;
◆ une paire clé-valeur est un document;
◆ un tableau de valeurs est un document;
◆ un agrégat de paires clé-valeur est un document;
◆ et de manière générale, toute composition des possibilités précédentes (un
tableau d’agrégats de paires clé-valeur par exemple) est un document.

2
Introduction
➔ Les documents sont caractérisés par l’existence d’une structure, et
on parlera donc de documents structurés.
➔ Cette structure peut aller du très simple au très compliqué, ce qui
permet de représenter de manière autonome des informations
arbitrairement complexes.

3
Introduction
➔ Nous abordons une question très importante dans le cadre de la mise en
œuvre d’une grande base de données constituée de documents:
comment modéliser ces documents pour satisfaire les besoins de
l’application? Et plus précisément:
◆ quelle est la structure de ces documents?
◆ quelles sont les contraintes qui portent sur le contenu des documents?

➔ Cette question est bien connue dans le contexte des bases de données
relationnelles. Pour les bases NoSQL, il n’existe pas de méthodologie
équivalente.
◆ il n’existe pas de modèle normalisé,
◆ la modélisation doit s’adapter aux caractéristiques de chaque système.

4
Introduction

Certains considèrent que la question de modélisation ne se pose pas quand il

s’agit de BD NoSQL et qu’on peut entasser les données dans la base, n’importe
comment, et voir plus tard ce que l’on peut en faire. C’est un(e absence de) choix
porteur de redoutables conséquences pour la suite.

5
 Rappel : Conception d’une base
relationnelle - Ce qu’il faut retenir
➔ Un objectif de normalisation qui vise à éviter à la fois toute
redondance et toute perte d’information;
◆ la redondance est évitée en découpant les données avec une granularité
fine, et en les stockant indépendamment les unes des autres;
◆ la perte d’information est évitée en utilisant un système de référencement
basé sur les clés primaires et clés étrangères.
➔ Les données sont contraintes par un schéma qui impose des règles
sur le contenu de la base

6
 Rappel : Conception d’une base
relationnelle - Ce qu’il faut retenir
➔ Il n’y a aucune hiérarchie dans la représentation des entités:
une entité comme Pays, qui peut être considérée comme secondaire, a droit à sa
table dédiée, tout comme l’entité Film qui peut être considérée comme essentielle;
on ne pré-suppose pas en relationnel, l’importance respective des entités
représentées;
➔ La distribution des données dans plusieurs tables est compensée par la
capacité de SQL à effectuer des jointures qui exploitent le plus souvent le
système de référencement (clé primaire, clé étrangère) pour associer des
lignes stockées séparément.
➔ Plusieurs écritures transactionnelles peuvent être nécessaires pour créer
une seule entité.
7
Exemple 1

8
Dénormalisation du schéma
➔ Des données fréquemment interrogées conjointement.
◆ Par exemple, les requêtes demandent fréquemment le lieu d’habitation
d’une,personne. De fait, la jointure devient coûteuse.
◆ Cette information étant peu mise à jour, cela pose peu de problèmes.
◆ Résultat : l’entité ‘Habitation’ et l’association ‘habite’ sont intégrés à l’entité
Personne. Habitation devient un document imbriqué à l’intérieur de Personne,
représenté par : “{habite}”
➔ Toutes les données d’une entité sont indépendantes.
Prenons l’exemple des domaines d’expertise d’une personne, ils sont indépendants des
domaines d’une autre personne. De fait, rapatrier les données de cette entité n’impacte
aucune autre instance de Personne. Ainsi, la liste des domaines est importé dans
Personne et représenté par : “[domaines]”

9
Dénormalisation du schéma
➔ Une association avec des relations 1-n des deux côtés.
◆ C’est plus délicat pour l’entité Etablissement. Une personne peut avoir plusieurs
emplois et un employeur, plusieurs employés.
◆ Une imbrication de l’employeur dans Personne peut avoir de gros impacts sur les
mises à jour (tous les employés à mettre à jour !).
◆ Il est donc peu recommandé d’effectuer une fusion complète. Pour cela, seule
l’association est imbriquée sous forme d’une liste de documents, intégrant les attributs
(qualité et date), ainsi qu’une référence vers l’employeur. Ainsi : “[{emploie+ref}]”
➔ Même taux de mises à jour.
◆ Dans le cas des emplois d’une personne, là également nous pourrions effectuer une
fusion de l’association “emploie”.
◆ En effet, le taux de mises à jour des emplois est équivalent à celui de la Personne, de
fait, sans incidence sur les problèmes de cohérence de données. 10
 Exemple 1 : Dénormalisation du
schéma

➔ Les listes sont représentées par des crochets et les

imbrications par des accolades.
➔ Nous pourrons remarquer que les établissements sont
stockés dans une association à part, mais que la référence
est gardée dans une liste intégrée à l’entité "Personne".
11
 Exemple 1 : Exemple d’instance
➔ Voici un exemple d’instance de cette représentation de la collection Personne. On peut
remarquer que les établissements sont référencés et des informations peuvent ne pas être
renseignées.

12
Exemple 2 - schéma E/A

13
Exemple 2 : schéma de la BDR

14
 Exemple 2 : Modélisation par
des documents structurés
1. Proposez une modélisation par des documents structurés
permettant de stocker les données dans le base de données
MongoDB en privilégiant l'accès aux films.
2. Même question en privilégiant l'accès aux acteur

15
 Exemple 2 :
document structuré
Dans une modélisation relationnelle, nous avons dû séparer
les films et les artistes dans deux tables distinctes, et lier
chaque film à son metteur en scène par une clé étrangère.

Tout peut être représenté par un unique document structuré,

en tirant parti de l’imbrication d’objets dans des
tableaux.

➔ Nous obtenons une unité d’information autonome

représentant l’ensemble des informations
relatives à un film

16
 Exemple 2 : Avantages de la
modélidation choisie
Ce rassemblement offre des avantages forts dans une perspective de
performance pour des collections à très grande échelle.
➔ Plus besoin de jointure: il est inutile de faire des jointures pour reconstituer
l’information puisqu’elle n’est plus dispersée, comme en relationnel, dans
plusieurs tables.
➔ Plus besoin de transaction (?): une écriture (du document) suffit; pour créer
toutes les données du film « Pulp fiction » ci-dessus, il faudrait écrire 1 fois
dans la table Film, 3 fois dans la table Artiste; 3 fois dans la table Role.
➔ De même, une lecture suffit pour récupérer l’ensemble des informations.

17
Exemple 2 : Avantages de la
modélidation choisie
➔ Adaptation à la distribution. Si les documents sont autonomes, il est très
facile des les déplacer pour les répartir au mieux dans un système
distribué; l’absence de lien avec d’autres documents donne la possibilité
d’organiser librement la collection.
➔ De plus, les transactions et les jointures sont deux mécanismes assez
compliqués à mettre en œuvre dans un environnement distribué.
➔ Ne pas avoir à les implanter simplifie considérablement la création de
systèmes NoSQL, d’où la prolifération à laquelle nous assistons.

18
Exemple 2 : Inconvénients de la
modélidation choisie
En observant bien le document Film, on réalise rapidement qu’il introduit cependant deux
problèmes importants.
➔ Hiérarchisation des accès: la représentation des films et des artistes n’est pas
symétrique; les films apparaissent près de la racine des documents, les artistes sont
enfouis dans les profondeurs; l’accès aux films est donc privilégié (on ne peut pas
accéder aux artistes sans passer par eux) ce qui peut ou non convenir à l’application.
➔ Perte d’autonomie des entités. Il n’est plus possible de représenter les informations sur
un metteur en scène si on ne connaît pas au moins un film; inversement, en supprimant un
film (e.g., Pulp Fiction), on risque de supprimer définitivement les données sur un artiste
(e.g., Tarantino).
➔ Redondance: la même information doit être représentée plusieurs fois, ce qui est tout à
fait fâcheux. Quentin Tarantino est représenté deux fois, et en fait il sera représenté autant
de fois qu’il a tourné de films (ou fait l’acteur quelque part).

19
Exemple 2 : Inconvénients de la
modélidation choisie
➔ La contrepartie d’un document autonome contenant toutes les informations qui lui sont
liées est l’absence de partage de sous-parties potentiellement communes à plusieurs
documents (ici, les artistes). On aboutit donc à une redondance qui mène
immanquablement à des incohérences diverses.
➔ On privilégie, en modélisant les données comme des documents, une certaine
perspective de la base de données (ici, les films), ce qui n’est pas le cas en relationnel
où toutes les informations sont au même niveau. Avec cette représentation des films par
exemple, comment connaître tous les films tournés par Tarantino? Il n’y a pas vraiment
d’autre solution que de lire tous les documents, c’est compliqué et surtout coûteux.

Ce sont des inconvénients majeurs, qui risquent à terme de rendre la base de données
inexploitable. Il faut bien les prendre en compte avant de se lancer dans l’aventure du
NoSQL.

20
Conclusion

➔ Adaptation à la distribution. Si les documents sont autonomes, il est très

facile des les déplacer pour les répartir au mieux dans un système
distribué; l’absence de lien avec d’autres documents donne la possibilité
d’organiser librement la collection.
➔ De plus, les transactions et les jointures sont deux mécanismes assez
compliqués à mettre en œuvre dans un environnement distribué.
➔ Ne pas avoir à les implanter simplifie considérablement la création de
systèmes NoSQL, d’où la prolifération à laquelle nous assistons.

21