M.

AZZOUZ

Bases de Données Avancées

Révision : Modélisation NoSQL

– USTHB Master 01 IL–

M. AZZOUZ
Dernière mis à jour :Septembre 2020
1
Enoncé «Exercice 04 »
 Enoncé «Exercice 04 »

Diagramme de classes:

Produit Magasin
Vente
-NumP 1 -NumM
1 * -Date *
-NomP -CodeWilaya
-Qte
-Type
-Fournisseur
 1. Proposer une modélisation orientée clé
valeur de ce schéma.
On considère le cas d’usage suivant: savoir pour chaque
Magasin donné tous ses détails.

Clé(NumM) Valeur(document JSON sauvegardé autant que BLOB)

{"codewilaya":16,
"ventes":[{"Produit":{"NumP":106,
"NomP":"Sonoflore",
616 "Type":"Beauté",
"Fournisseur":"F100"
},
"Date":"25/02/2020",
"Qté":5
},
{"Produit":{"NumP":104,
"NomP":"WebCam",
"Type":"Multimédia",
"Fournisseur":"F200"
},
"Date":"05/05/2020",
"Qté":10
},
{"Produit":{"NumP":104,
"NomP":"WebCam",
"Type":"Multimédia",
"Fournisseur":"F200"
},
"Date":"02/07/2020",
"Qté":5
}
]
}
 2. Proposer une modélisation orientée
colonne de ce schéma.
On considère le cas d’usage suivant: Accéder aux ventes d’un
produit donné (recherche à partir d’un nom produit donné) et
connaitre les ventes d’une wilaya.

Modélisation sous Cassandra

 2. Proposer une modélisation orientée
colonne de ce schéma.
On considère le cas d’usage suivant: Accéder aux ventes d’un
produit donné (recherche à partir d’un nom donné) et connaitre
les ventes d’une wilaya.

Le nom de produit et la wilaya de magasin seront stockés dans la

table Ventes. On évite ainsi les jointures!

Ventes
-Date
-Qte
-NumP
-NumM
-NomP
-CodeWilaya
 2. Proposer une modélisation orientée
colonne de ce schéma.

ColumnFamily
Key Value
SuperColumns
Key (clé composée de Value (de la ligne)
NumP, NumM, Date)
Column
Name Value

Ventes Date 25/02/2020

Qté 5
616, 106, 25/02/2020
NumM 616
NumP 106
NomP Sonoflore
CodeWilaya 16
 3.Proposer une modélisation orientée
document de ce schéma en utilisant
a. Une seule collection: « centrée sur les magasins » basé sur
l’imbrication
{"NomM":616,
"codewilaya":16,
"ventes":[{"Produit":{"NumP":106,
"NomP":"Sonoflore",
"Type":"Beauté",
"Fournisseur":"F100"
},
"Date":"25/02/2020",
"Qté":5
},
{"Produit":{"NumP":104,
"NomP":"WebCam",
"Type":"Multimédia",
"Fournisseur":"F200"
},
"Date":"05/05/2020",
"Qté":10
},
{"Produit":{"NumP":104,
"NomP":"WebCam",
"Type":"Multimédia",
"Fournisseur":"F200"
},
"Date":"02/07/2020",
"Qté":5
}
]
}
 3.Proposer une modélisation orientée
document de ce schéma en utilisant
a. Plusieurs collections en utilisant les références
Collection Magasin:
{" _id":"id_M1"
"codewilaya":16,
"ventes":["id_V1", "id_V2",…]
}
Collection Ventes:
{" _id":"id_V1"
"Date":"25/02/2020",
"Qté":5,
"Produit": " id_P1"
}
Collection produit:
{" _id":"id_P1"
"NumP":104,
"NomP":"WebCam",
"Type":"Multimédia",
"Fournisseur":"F200"
}
 4.Discuter l'impact de la dénormalisation sur
l'exécution des requêtes dans le cas d'une modélisation
orientée document.»

 Qu'est-ce que la dénormalisation ?

 Dans une relation entre deux tables A et B, la

dénormalisation consiste à dupliquer certaines
données de la table B dans la table A afin d'optimiser
les requêtes qui pourront se contenter d'interroger la
table A sans avoir à faire de jointures entre A et B.

 Il existe trois grandes stratégies de dénormalisation

des données.
 Les stratégies de dénormalisation des données

 Imbrication de documents:
 Pour une relation entre deux documents A et B, cela
consiste à avoir le document B imbriqué dans le
document A. Il existe deux cas d'utilisation pour cette
stratégie.
 Avec une lecture de la collection des documents
imbriqués on aura toutes les données qui concernent
le document parent et les données du document
imbriqué (ex. imbrication de l'adresse dans le
document du client).
 On veut pouvoir modifier des documents parents et
enfants d'une manière atomique.
 Les stratégies de dénormalisation des données

 Duplication d'un sous ensemble de champs

 L'idée est de dupliquer le minimum de données du
document B dans A et de préférence, celles qui ne
changent pas souvent, car lors de leur mise à jour,
nous devrions faire un update sur l'ensemble des
documents qui les contiennent. Ces modifications
augmenteront le temps d'écriture.
 Exemple : en visitant la page d'un de ses amis, un
utilisateur Facebook n'a souvent besoin que de voir
s'afficher dans un premier temps son pseudonyme et
sa photographie. C'est seulement en cliquant sur son
profil qu'il accédera à des informations
complémentaires.
 Les stratégies de dénormalisation des données

 Duplication de la clé primaire

 Cette fois, on ne duplique que la clé primaire du
document B dans le document A. Pour récupérer les
données, l'application doit faire deux requêtes :
- une première requête pour récupérer la clé
primaire ;
- puis une seconde pour récupérer les données de
l'autre côté de la relation.
- Exemple : prenons la relation N-N entre livres et
auteurs. Le document de l'auteur contient la liste des
clés primaires de ses livres et le livre contient les clés
primaires de ses auteurs. On commence par récupérer
les identifiants des auteurs, puis on interroge la
collection des livres pour récupérer le reste des
données.
 Conclusion

 Nous venons d'aborder le changement de

paradigme qu'il faut opérer lors de la modélisation du
schéma d'une base de données NoSQL orientée
documents. La norme n'est plus de démarrer des
structures de données qu'on normalise (pour éviter les
duplications de l'information) puis de construire les
requêtes. Désormais, c'est plutôt l'inverse : ce sont les
requêtes, les cas d'utilisation et les besoins en temps
de réponse qui nous dictent la construction des
structures de données.