11/11/2019

Module Systèmes de gestion de documents

 Objectifs
Systèmes de Gestion de Documents  Les bases de données NoSQL
 Les systèmes de gestion de bases de données NoSQL orientées documents
Master Informatique – 1ère année  Le système MongoDB

 Organisation
 6h CM, 8h TD et 8h TP
Nadine CULLOT – [Link]@[Link] (CM,TD et TP)
Richard GENESTIER – [Link]@[Link] (TD, TP)
 Contrôle des connaissances
 Note de TP (projet)
 Note de CT (Contrôle Terminal)
 Documents autorisés (Polycopiés de CM, TD et TP)
 Note du module : (note TP + 2*note CT) /3

M1 Informatique - SGD - N. Cullot 1 M1 Informatique - SGD - N. Cullot 2

Module Systèmes de gestion de documents SGD – CM1 – Introduction

 CM1 : Bases de données relationnelles et bases NoSQL (Not Only SQL)
 Introduction  Le modèle relationnel
 Modèle relationnel, modèle transactionnel (OLTP)
 Modèle analytique (OLAP), Schéma en étoile, Entrepôts de données, ETL
 Modèle qui s’est imposé à partir des années 1980 avec des SGBDR comme
 L’émergence des bases de données NoSQL Oracle
 Classements des moteurs NoSQL
 Par schémas de données, par usage  Caractéristiques agréées par la communauté
 Les techniques mises en œuvre en NoSQL
 Architecture distribuée et analytique  Structuration forte des données
 Les bases NoSQL orientées Documents  Représentation à l’aide de tables
 Représentation de documents : Le format JSON
 Modélisation  Langage déclaratif
 Conception d'une base de données relationnelle
 Conception NoSQL avec des documents structurés
 Séparation du modèle logique du modèle physique
 Relationnel et NoSQL  Contraintes implémentées au niveau du SGBD
 La base de données orientée documents : MongoDB
 Caractéristiques  Cohérence transactionnelle forte
 Les opérations CRUD en MongoDB  Etc.
 Patrons de conception appliqués pour MongoDB
 Imbrication ou références  Ces règles constituent « Les douze règles de CODD » parues dans en 1985
 Schémas polymorphiques
dans deux articles (par Edgard Codd).

M1 Informatique - SGD - N. Cullot 3 M1 Informatique - SGD - N. Cullot 4

SGD – CM1 – Introduction SGD – CM1 – Introduction

 Modèle relationnel performant pour une utilisation transactionnelle  Le modèle OLAP (Online Analitycal Processing)
 OLTP : Online Transactional Processing  Est apparu en raison
 de l’augmentation du stockage de données agrégées et historiques
 Adapté pour des traitements de consultation et de mise à jour fréquents mais  des besoins analytiques dans les domaines métiers des entreprises
avec des résultats de taille plutôt petite  Pour
 Exemple : Gestion de factures, de stocks, etc.  Permettre des requêtes globales sur des grands volumes de données
 y compris pour des tables dont les cardinalités peuvent être importantes  Adaptation de la structuration des données : le schéma en étoile
 Requêtes optimisées avec des index  La table au « centre » de l’étoile comporte le détail (mesures, faits, ..)
 Ex: détail d’une commande
 Autres besoins : l’informatique décisionnelle  Les tables des « extrémités » sont les axes d’analyse (dimensions)
 Extraction de données pour leur analyse, et leur visualisation adaptée à des  Ex: Client, Produit, Vendeur, Date, etc.
fins décisionnelles  Analyse multi-dimensionnelle (MOLAP)
 Analyses historiques de données, analyses prédictives, etc.
 Visualisation adaptée : tableaux de bord  Le modèle OLAP a aussi été formalisé par E. Codd
 OLAP : Online Analytical Processing  Le modèle OLAP s’appuie sur la construction d’entrepôt de données

M1 Informatique - SGD - N. Cullot 5 M1 Informatique - SGD - N. Cullot 6

1
 11/11/2019

SGD – CM1 – Introduction

SGD – CM1 – Introduction L’émergence du NoSQL
 Un entrepôt de données (aussi appelé base de données décisionnelle)
 Les évolutions matérielles
 Est une base de données adaptée pour
 Interconnexions des réseaux, augmentation des bandes passantes,
 La collecte, l’ordonnancement, la journalisation et le stockage d’informations provenant
d’une base de données opérationnelle ou d’autres sources  Diminution des coûts, optimisations des techniques de stockage,
 Etc.
 Vise à fournir une base pour l’aide à la décision
 Ont ouvert des possibilités de gestion et de traitements de données de très
 Apparition d’outils performants : les ETL grands volumes (en pétaoctets - 1015 octets)
 ETL : Extract – Transform – Load  Emergence du « Big Data »
 Extract : logiciel qui facilite l’extraction de données multi-sources
 Les évolutions logicielles visent à s’adapter à ces nouvelles capacités
 Transform : Logiciel qui permet le filtrage et la mise en forme des données
 Load : Logiciel de chargement dans l’entrepôt
 Pour la représentation des données : modélisation, langage de manipulation
 Pour la recherche et l’analyse : moteurs de recherche, index, algorithmes
 Interrogation des données avec une vision dite « cube » ou  Pour le stockage distribué : systèmes distribués NoSQL
« hypercube » intégrée dans des outils d’analyse  Pour le traitement massif et distribué (MapReduce, etc.)

M1 Informatique - SGD - N. Cullot 7 M1 Informatique - SGD - N. Cullot 8

SGD – CM1 – Introduction SGD – CM1 - Classement des moteurs NoSQL

L’émergence du NoSQL Par schémas de données
 Certaines entreprises ont développé des solutions propriétaires de SGBD  On peut classer les moteurs NoSQL selon leur usage ou leur schéma
pouvant fonctionner de données.
 Sur des architectures distribuées
 Pour traiter des volumes importants de données  Pour les schémas de données, on peut distinguer 5 modèles
 On peut citer :  Les moteurs qui manipulent des paires clé-valeur
 Google -> BigTable (« A Distributed Storage System for Structured Data » – 2006)  Les moteurs orientés documents
 Amazon -> Dynamo (Entrepôt de paires clé-valeur – architecture distribuée - 2007)  Les moteurs orientés colonnes
 Facebook -> Cassandra puis HBase (projet Apache Cassandra en 2009)  Les moteurs orientés graphes
 Etc.
 Autres moteurs spécifiques
 A partir de 2009, le terme « NoSQL » est retenu (Not Only SQL)
 En 2011, la spécification d’un langage de manipulation standardisé
(appelé « UnSQL ») a également débuté
 pour formaliser les requêtes sur les collections des bases NoSQL

M1 Informatique - SGD - N. Cullot 9 M1 Informatique - SGD - N. Cullot 10

SGD – CM1 - Classement des moteurs NoSQL

Par schémas de données
SGD – CM1 - Classement des moteurs NoSQL
 Les moteurs NoSQL : clé-valeur  Les moteurs NoSQL : clé-valeur
 Les données sont représentées par un couple clé-valeur.  Ces moteurs offrent peu de fonctionnalités mais d’excellentes
 La valeur peut être simple ou un objet sérialisé performances grâce au modèle d’accès simplifié
 Le modèle est similaire à une table de hashage distribuée  Mais la complexité du requêtage est reportée au niveau de
l’applicatif qui interroge la BD
 Qui a la connaissance « sémantique » des données
 Implémentations existantes
 Amazon Dynamo (Riak en implémentation Open Source)
 Redis (projet sponsorisé par VMWare)
 Voldemort (développé par LinkedIn en interne, puis passage en open source)

M1 Informatique - SGD - N. Cullot 11 M1 Informatique - SGD - N. Cullot 12

2
 11/11/2019

SGD – CM1 - Classement des moteurs NoSQL SGD – CM1 - Classement des moteurs NoSQL
Par schémas de données Par schémas de données
 Les moteurs orientés documents  Les moteurs orientés documents
 Ils reposent sur le paradigme clé-valeur mais la valeur est remplacée par un  Ils permettent de manipuler des documents structurés ou semi-
document
structurés avec
 Le format des documents le plus populaire est le JSON (JavaScript Object Notation)
 Des types simples, des listes, des paires clé-valeur
 Sous une forme hiérarchique
 Ils permettent d’effectuer des requêtes sur le contenu des
documents
Document
 Implémentations existantes
 CouchDB (fondation Apache)
 RavenDB (pour plateformes .NET/Windows – LINQ)
 MongoDB (1ère version en 2009 – [Link])
Document
M1 Informatique - SGD - N. Cullot 13 M1 Informatique - SGD - N. Cullot 14

SGD – CM1 - Classement des moteurs NoSQL SGD – CM1 - Classement des moteurs NoSQL
Par schémas de données Par schémas de données
 Les moteurs orientés  Les moteurs orientés colonnes
colonnes  offrent une plus grande structuration des données
 Chaque colonne est définie  que les modèles clé-valeur ou orientés documents
par un couple clé-valeur

 Une super-colonne est un  Implémentations existantes

couple clé-valeur dont la
valeur est une colonne  HBase (Open Source de BigTable de Google)
 Cassandra (fondation Apache)
 Une famille de colonnes  SimpleDB (Amazon)
permet de regrouper
plusieurs colonnes ou super-
colonnes

M1 Informatique - SGD - N. Cullot 15 M1 Informatique - SGD - N. Cullot 16

SGD – CM1 - Classement des moteurs NoSQL SGD – CM1 - Classement des moteurs NoSQL
Par schémas de données Par usage
 Les moteurs orientés graphe  Il est aussi possible de distinguer les différents moteurs NoSQL
 selon certains critères pour leur usage comme :
 Le modèle de données est basé sur un graphe  La performance, l'assouplissement des structures ou la volumétrie
avec les notions de nœuds, de relations entre
les nœuds et de propriétés  Améliorations des performances
 Simplification du modèle en clé-valeur, utilisation de la mémoire RAM,
distribution des traitements sur les différents nœuds d'un cluster
 Représentation adaptée pour certaines
données comme celles issues des réseaux  Assouplissement des structures
sociaux par exemple  Usage de schémas souples (comme JSON), relâchement de certaines
contraintes, pas de contrôle d'intégrité référentielle, pas de schéma explicite
 Implémentation existantes
 Neo4j ([Link])  Volumétrie
 OrientDB (fondation Apache)  Capacité à monter en charge qui passe par une distribution du stockage et
des traitements

M1 Informatique - SGD - N. Cullot 17 M1 Informatique - SGD - N. Cullot 18

3
 11/11/2019

SGD – CM1 – Les techniques mises en œuvre en NoSQL Report "NoSQL, NewSQL and Beyond: The answer to SPRAINed
Architecture distribuée et Analytique relational databases", 451 Group, April 15th, 2011
 Le NoSQL est né du besoin de gérer des données volumineuses voire très SPRAIN :
volumineuses (Big-Data). Scalability
 La distribution des données sur plusieurs machines est une technique pour Performance
répondre à ce besoin. Relaxed Consistency
Agility
 Distribution des données et distribution des traitements Intricacy
 Avec deux possibilités avec ou sans maître Necessity
 La distribution avec maître s'appuie sur la présence d'une machine maître
 Qui gère la configuration du systèmes, reçoit les requêtes et les répartit vers les machines BD alternatives pour
ayant les données gérer de grands
 La distribution sans maître volumes de données
 Toutes les machines jouent le même rôle. Nécessité de trouver des solutions pour diriger les avec des applications
requêtes vers les machines ayant les données distribuées
 Le Big-Data analytique : le paradigme de MapReduce
 Distribution des traitements avec 2 étapes : SGBDR avec des
 Map : attribution des opérations sur chaque machine nouvelles
technologies pour
 Reduce : rassemblement des résultats après traitement évoluer vers les
Systèmes NoSQL
M1 Informatique - SGD - N. Cullot 19 M1 Informatique - SGD - N. Cullot 20

SGD – CM1 – Les bases NoSQL orientées documents SGD – CM1 – Les bases NoSQL orientées documents
Représentation des documents - JSON Représentation des documents - JSON
 Les documents structurés sont à la base des systèmes NoSQL  Exemples de documents JSON
 Pour des traitements à grande échelle  Document 1 : Objet composé de couples nom/valeur
{ "nom": "Dupont",
 Le format de données JSON (JavaScript Object Notation) est un format "prenom": "Jean",
"ville": "Paris",
pour l’échange de données }
 Facile à lire et écrire pour un humain, à la différence de XML par exemple  Document 2 : avec un tableau de numéros de téléphone sous forme de chaînes de caractères
 JSON se base sur deux structures { "nom": "Dupont",
"prenom": "Jean",
 Les collections de couples (paires) nom/valeur (clé/valeur) "ville": "Paris",
"telephone": [ "0612345678" , "0312345678" ]
 Les listes de valeurs ordonnées (tableau) }
 En JSON,  Document 3 : avec un tableau de numéros de téléphone sous forme de couples nom/valeur
{ "nom": "Dupont",
 Un objet est un ensemble non ordonné de couples nom/valeur. "prenom": "Jean",
 Un tableau est une collection ordonnée de valeurs "ville": "Paris",
"telephone": [{"mobile" : "0612345678"} , {"fax" : "0312345678" }]
 Une valeur peut être une chaîne de caractères (entre guillemets), un nombre, un
booléen : true, false, la valeur : null, un objet ou un tableau

M1 Informatique - SGD - N. Cullot 21 M1 Informatique - SGD - N. Cullot 22

SGD – CM1 – Les bases NoSQL orientées documents SGD – CM1 – Les bases NoSQL orientées documents
Représentation des documents - JSON Représentation des documents - JSON
 Document 4 : collection de couples nom/valeur, avec tableau  Les documents structurés JSON peuvent être vus comme des
{
{ "Auteur" : { "Nom": "Dupont",
structures arborescentes
"Prénom": "Jean", }
}
"Titre" : "Le livre secret", Arbre représentant un
"Mots-clés" : ["Roman", "Policier"] objet avec une
}
Le Livre secret [Roman, Policier] composition
 Les documents structurés sont relativement riches en terme de représentation d'agrégats et un
 Structures complexes pouvant être imbriquées avec des agrégats, des listes et des tableaux
tableau de valeurs
 Ils sont flexibles, par exemple on peut avoir ou non des mots-clés pour un livre, (simples)
Dupont Jean
des notes, etc.
 Ils s'auto-décrivent avec la gestion des couples nom/valeur.
 Ils sont sérialisables pour leur échange (suite d'octets).

M1 Informatique - SGD - N. Cullot 23 M1 Informatique - SGD - N. Cullot 24

4
 11/11/2019

SGD – CM1 – Modélisation SGD – CM1 – Modélisation

Conception d'une base de données relationnelle Conception d'une base de données relationnelle
 Principe de conception d'une base de données relationnelle  Exemple : Extrait d'un modèle UML modélisant des réservations de
 Modélisation des informations voiture dans des agences
 Modèle conceptuel de données
 Modèle Entités-Associations, Modèle UML
 Modèle logique
 Spécification du schéma de la base – Définition des tables
Une société comporte une à plusieurs agences.
 Modèle physique Une agence appartient à une société.
 Implémentation de la base
 Caractéristiques du modèle relationnel Une réservation concerne une voiture et a :
 Les données sont contraintes par un schéma une agence de départ, une agence de d'arrivée,
 La normalisation du schéma vise à éviter la redondance des données une date de début et une date de fin.
 Toutes les entités sont considérées de façon similaire
 Le regroupement des données réparties dans les tables (qui comportent des clés
primaires et des clés étrangères) se fait en SQL à l'aide de jointure

M1 Informatique - SGD - N. Cullot 25 M1 Informatique - SGD - N. Cullot 26

SGD – CM1 – Modélisation SGD – CM1 – Modélisation

Conception d'une base de données relationnelle Conception NoSQL avec documents structurés
 Le schéma relationnel  Les bases de données orientées documents gèrent
 Tables pour l'extrait de diagramme présenté
 des documents structurés et des collections de documents
 Société (idS, nom)
 Voiture (numV, capacité, modèle, prix)  Modélisation possible des données
 Agence (numA, nom, adresse, numSociété)
 Réservation(numéro, nom, dateDébut, dateFin, numAD, numAA, numV)  de façon arborescente, plus puissante que la modélisation tabulaire du
modèle relationnel
 Insertion des données dans les tables
 En respect des contraintes d'intégrité  Avec une représentation possible de liste de valeurs pour certaines
caractéristiques
 Requêtes avec jointure : toutes les réservations avec les modèles de voiture et
le nom des agences  En reprenant l'exemple présenté, des réservations de voiture, il est
select [Link]éro, [Link], [Link]èle, [Link], [Link] possible de structurer les informations
from réservation r, agence ad, agence aa, voiture v
where [Link]=[Link]  Avec des documents qui décrivent l'ensemble des données d'une réservation
and [Link]=[Link] and [Link]=[Link];

M1 Informatique - SGD - N. Cullot 27 M1 Informatique - SGD - N. Cullot 28

SGD – CM1 – Modélisation SGD – CM1 – Modélisation

Conception NoSQL avec documents structurés Conception NoSQL avec documents structurés
 Description d'un document pour une réservation  L'ensemble des informations concernant une réservation
{ "numéro" : "123",  sont "regroupées"
"nom":"resa123",
 Et constitue une auto-description d'une réservation
"dateD" : "12/10/2017,
"dateF" : "17/10/2017"  La manipulation de documents autonomes permet une gestion des
"agenceD" : { " numA" : "211",
informations plus aisée dans un environnement distribué.
"nom" : "DijonCentre",
"adresse" : "Dijon" },  Ces regroupements peuvent améliorer les performances pour des
"agenceA" : { " numA" : "331", collections de données massives.
"nom" : "BordeauxCentre",
"adresse" : "Bordeaux" };
 Mais pas de façon homogène selon les requêtes qui sont évaluées
"voiture" : { "numV" : "666AA21",  Par exemple, la représentation proposée en centrée sur les réservations,
"capacité : "5",
"modèle" : "Renault", "
qui sont décrites au niveau de la racine de l'arborescence
prix : "200" }  Les informations sur les agences concernées par les réservations sont imbriquées
}

M1 Informatique - SGD - N. Cullot 29 M1 Informatique - SGD - N. Cullot 30

5
 11/11/2019

SGD – CM1 – Modélisation SGD – CM1 – Modélisation

Conception NoSQL avec documents structurés Conception NoSQL avec documents structurés
 Les inconvénients liés à la modélisation avec des documents  Principe de conception d'une BD NoSQL orientée documents
structurés  Analyser informellement les informations/données à modéliser
 Absence de vue "simple" des entités  Spécifier un modèle conceptuel (UML par exemple)
 Ici les agences sont dans les réservations  Pour aider à répertorier l'ensemble de informations à modéliser
 Ou nécessité de travailler avec d'autres documents pour avoir une connaissance des  Spécifier les types de requêtes qui devront être prises en charge, et les modèles
agences
 Par exemple avec les société
d'accès spécifiques de l'application
 Pour aider à spécifier les documents à construire
 La non redondance des informations n'est plus assurée
 La description d'une même agence apparaît dans toutes les réservations concernées par  Spécifier le modèle de documents
cette agence  En "dénormalisant" le modèle usuel de BD (relationnel)
 La structuration retenue dans les documents privilégie un certain  Pour privilégier l'accès aux données pour les requêtes envisagées
usage de la base de données  Favoriser l'optimisation et la performance au détriment de la "neutralité"
 Avec une connaissance "a priori" de la modélisation comme en relationnel
 Et permettre des systèmes distribués avec des données décrites de façon autonome

M1 Informatique - SGD - N. Cullot 31 M1 Informatique - SGD - N. Cullot 32

SGD – CM1 – Modélisation SGD – CM1 – La base de données orientée documents: MongoDB
NoSQL et relationnel Caractéristiques
 Les systèmes NoSQL ne comportent en général pas de schéma des données  MongoDB est un système de gestion de données NoSQL
 Ou pas de façon similaire au schéma d'une BD relationnel
 Les systèmes NoSQL reportent un ensemble de contrôles au niveau des applicatifs  Orienté document, très populaire
 Pas de schéma, pas de contrôle d'intégrité sur les données  Développé par la société américaine MongoDB Inc.
 Pas de gestion des transactions
 Disponible depuis 2009
 Les systèmes NoSQL sont plutôt adaptés pour des données
 peu structurées, comme des données graphe (ex : réseaux sociaux) , des séries temporelles (ex:
données de capteurs horadatées) , ou certaines données textuelles (analyse de fichiers de log ou
de messages d'erreur, etc.)  MongoDB est codé en C++
 qui nécessitent peu de mises à jour,
 mais des lectures avec des gros volumes
 nécessitant des traitements en temps réel (optimisation des temps de réponse)  Les documents sont codés en interne dans le format BSON (Binary
 Les BD relationnelles et les Bases de données NoSQL sont complémentaires et n'ont Serialized dOcument Notation ou Binary JSON).
pas les mêmes objectifs
 Importance de réfléchir à la BD à utiliser selon les fonctionnalités des applicatifs à développer et le
type des données à traiter
 Pour l'utilisateur les documents sont en format JSON (JavaScript
Object Notation)
M1 Informatique - SGD - N. Cullot 33 M1 Informatique - SGD - N. Cullot 34

SGD – CM1 – La base de données orientée documents: MongoDB SGD – CM1 – La base de données orientée documents : MongoDB
Caractéristiques Les opérations CRUD en MongoDB
 Les documents sont gérés dans des collections.  En salle TP, la base de données MongoDB est installée sur le serveur
 Tous les documents d'une collection ne sont pas nécessairement identiques mongo.
 Chaque document est identifié par une clé unique dans une collection  Accès au serveur mongo
 Qui peut être comparée à la notion de clé primaire d'une table relationnel  ssh nomLogin@mongo
 La clé d'un document porte un nom fixe : _id.
 Elle peut être fournie ou générée automatiquement (génération d'un UUID de type ObjectId
 Chaque utilisateur a une base de données
d'une taille de 96 octets)  mongo –u nomLogin –p
 Les collections peuvent être regroupées dans des espaces de noms et  Enter password : // taper le mot de passe pour le compte MongoDB
sont stockées dans des bases de données  Connecting to : test
 Une BD est une collection de collections  >use nomLogin // le nom de la base est identique au nom de login
 Les bases de données sont créées "à la demande" lorsqu'elles sont mentionnées  Switched to db nomLogin
dans une commande  > // instructions
 MongoDB autorise aussi le stockage d'objets larges ou de documents
binaires (avec BSON, ou GridFS pour les documents de plus grande taille).
M1 Informatique - SGD - N. Cullot 35 M1 Informatique - SGD - N. Cullot 36

6
 11/11/2019

SGD – CM1 – La base de données orientée documents : MongoDB SGD – CM1 – La base de données orientée documents : MongoDB
Les opérations CRUD en MongoDB Les opérations CRUD en MongoDB
 Opération de création d'un document dans une collection  Opération de création d'un document dans une collection
 Insertion d'une agence dans une collection nommée agences  Insertion d'une agence dans une collection nommée agences
 Avec une génération automatique de l'identifiant  Avec un identifiant fourni
[Link]( [Link](
{ "numAgence" : "123",
{ _id : 100,
"nom" : "Agence Dijon centre",
"adresse" : "Dijon" "numAgence" : "123",
}) "nom" : "Agence Dijon centre",
Résultat à l'exécution (valeur de l'identifiant du document créé) "adresse" : "Dijon"
{ })
"acknowledged" : true, Résultat à l'exécution (valeur de l'identifiant du document créé)
"insertedId" : ObjectId("5a088e5e8f32bee62a2b6438") { "acknowledged" : true, "insertedId" : 100 }
}

M1 Informatique - SGD - N. Cullot 37 M1 Informatique - SGD - N. Cullot 38

SGD – CM1 – La base de données orientée documents : MongoDB SGD – CM1 – La base de données orientée documents : MongoDB
Les opérations CRUD en MongoDB Les opérations CRUD en MongoDB
 Opération de création d'un document dans une collection  Opération de lecture (read) de documents dans une collection
 Insertion de plusieurs agences dans une collection nommée agences  Lecture de tous les documents
 Avec la génération des identifiants

[Link](
[Link]()
[ {"numAgence" : "658",
"nom" : "Agence Dijon Mansard", { "_id" : ObjectId("5a088e5e8f32bee62a2b6438"), "numAgence" : "123",
"adresse" : "Dijon" "nom" : "Agence Dijon centre", "adresse" : "Dijon" }
},
{"numAgence" : "245",
{ "_id" : 110, "numAgence" : "234", "nom" : "Agence Dijon Valmy", "adresse"
"nom" : "Agence Dijon Université",
: "Dijon" }
"adresse" : "Dijon" { "_id" : ObjectId("5a08941ca9c3d4982f5b3039"), "numAgence" : "555",
}]) "nom" : "Agence Dijon Mansard", "adresse" : "Dijon" }
Résultat à l'exécution { "_id" : ObjectId("5a08941ca9c3d4982f5b303a"), "numAgence" : "555",
{ "nom" : "Agence Dijon Universite", "adresse" : "Dijon" }
"acknowledged" : true,
"insertedIds" : [
ObjectId("5a08941ca9c3d4982f5b3039"),
ObjectId("5a08941ca9c3d4982f5b303a")
]
}
M1 Informatique - SGD - N. Cullot 39 M1 Informatique - SGD - N. Cullot 40

SGD – CM1 – La base de données orientée documents : MongoDB SGD – CM1 – La base de données orientée documents : MongoDB
Les opérations CRUD en MongoDB Les opérations CRUD en MongoDB
 Opération de lecture (read) de documents dans une collection  Opération de mise à jour (update) d'un document dans une collection
 Lecture de documents avec un filtre (critère de sélection)
 Mise à jour d'un document : modification du nom de l'agence de numéro 234
[Link]({ "numAgence" : "234"}, {$set: {"nom" : "Agence Valmy" }})
[Link]({ "numAgence" : "234"})
 Valeur avant la mise à jour
{ "_id" : 110, "numAgence" : "234", "nom" : "Agence Dijon Valmy", { "_id" : 110, "numAgence" : "234", "nom" : "Agence Dijon Valmy", "adresse" :
"Dijon" }
"adresse" : "Dijon" }
 A l'exécution
 { "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }
 Etude des requêtes (CM2)
 Valeur après la mise à jour
 { "_id" : 110, "numAgence" : "234", "nom" : "Agence Valmy", "adresse" : "Dijon" }

M1 Informatique - SGD - N. Cullot 41 M1 Informatique - SGD - N. Cullot 42

7
 11/11/2019

SGD – CM1 – La base de données orientée documents : MongoDB SGD – CM1 – La base de données orientée documents : MongoDB
Les opérations CRUD en MongoDB Les opérations CRUD en MongoDB
 Opération de mise à jour (update) de plusieurs documents dans  Opération de mise à jour avec remplacement d'un document dans
une collection une collection
 Mise à jour des documents ayant l'adresse "Dijon"  [Link]({ "numAgence" : "234"}, { "numAgence" : "464",
[Link]({ "adresse" : "Dijon"}, {$set: {"adresse" : "nom" : "Agence Gare", "adresse" : "Dijon" })
"Dijon Centre" }})
 A l'exécution
 A l'exécution { "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }
{ "acknowledged" : true, "matchedCount" : 4, "modifiedCount" : 4 }
 L'identifiant de l'objet est conservé.
 Les 4 agences ont été mises à jour. { "_id" : 110, "numAgence" : "464", "nom" : "Agence Gare", "adresse" :
"Dijon" }

M1 Informatique - SGD - N. Cullot 43 M1 Informatique - SGD - N. Cullot 44

SGD – CM1 – La base de données orientée documents : MongoDB SGD – CM1 – La base de données orientée documents : MongoDB
Les opérations CRUD en MongoDB Les opérations CRUD en MongoDB
 Opération de suppression d'un ou plusieurs documents dans une  La méthode "bulkWrite" permet l'exécution de plusieurs opérations
collection décrites dans une collection.
 Suppression de l'agence dont l'identifiant vaut 110  [Link](
[Link]({ "_id" : 110})  [ { insertOne : {"document" :
 { "numAgence" : "444", "nom" : "Agence Valmy", "adresse" : "Dijon"}
 Suppression de l'agence dont l'identifiant a été généré  }
[Link]({ "_id" :  },
ObjectId("5a08941ca9c3d4982f5b303a")})
 {updateOne : { "filter" :{ "numAgence" : "444"}, "update" : {$set: {"nom" :
 Suppression de tous les documents ayant une certaine adresse "Agence Dijon Valmy" }}}
[Link] ({"adresse" : "Dijon Centre"})  }
 ])

M1 Informatique - SGD - N. Cullot 45 M1 Informatique - SGD - N. Cullot 46

SGD – CM1 – NoSQL et BD relationnelles CM1 : Patrons de conception appliqués en MongoDB

 Emergence des modèles NoSQL  MongoDB permet de gérer des documents structurés (en JSON) qui
 Pour gérer des données massives de façon optimisée supportent des structures de données complexes comme
 Pour répondre à des besoins d’analyses sur des données historiques ou à des  Les documents composés avec des structures imbriquées
fins décisionnelles prédictives
 Des tableaux de valeurs simples ou de structures, avec des imbrications
 Mise en œuvre de technologies spécifiques possibles
 Abandon de contraintes pour la modélisation  Etc.
 Modèles adaptés à la gestion de gros volumes de données
 Distribution du stockage  Le choix d’un modèle de données pour le développement d’une
 Distribution des traitements application est un enjeu important pour permettre
 NoSQL et BD relationnelles ne répondent pas aux mêmes besoins  Une interrogation aisée des données
 Des initiatives comme NewSQL pour faire évoluer SQL vers des technologies  Un passage à l’échelle pour des données volumineuses distribuées
NoSQL

M1 Informatique - SGD - N. Cullot 47 M1 Informatique - SGD - N. Cullot 48

8
 11/11/2019

CM1 : Patrons de conception appliqués en MongoDB CM1 : Patrons de conception appliqués en MongoDB
 Le modèle relationnel s’appuie sur des règles de normalisation qui  La normalisation des données comme dans le modèle relationnel
de façon simplifiée présente
 Permet la représentation des données de façon homogène dans des tables  des avantages importants comme la facilité de mise à jour des données, et
 S’assure que chaque valeur d’une table est une valeur simple leur non-redondance
 Évite la redondance des données; ce qui facilite leur mise à jour  mais aussi des inconvénients comme
 Se base sur les notions de clés primaires et clés étrangères pour lier des données entre-elles  le coût d’accès aux données qui ne sont pas stockées de façon contiguë,
 Le modèle de documents structurés et les objectifs des applications  le coût de la réalisation de jointures (avec de nombreux accès aux données des
différentes tables)
développées en MongoDB, notamment pour des données massives
 remettent en cause la normalisation pour des raisons de performance  Le modèle relationnel applique parfois des techniques de
« dénormalisation » pour optimiser les requêtes.
 La question que l’on peut alors se poser est
 Doit-on utiliser des structures d’objets imbriqués ou des références entre des  On peut cependant s’interroger sur la nécessité de normaliser les
objets à l’aide d’identifiant ? données dans des modèles de documents comme MongoDB.
M1 Informatique - SGD - N. Cullot 49 M1 Informatique - SGD - N. Cullot 50

CM1 : Patrons de conception appliqués en MongoDB

CM1 : Patrons de conception appliqués en MongoDB Imbrication ou références
 MongoDB offre nativement un modèle qui permet de gérer des  Relations de cardinalité 1-n. Contact
données structurées multivaluées  Un contact (_id, nom, prénom) possède plusieurs numéros (libellé, numéro) _id
Nom
 Ce qui est un avantage pour les performances  Modèle imbriqué (JSON) Prénom
 Mais pose le problème de la redondance possible des données dans les  { "_id" : 10, "nom" : "Dupont", "prenom" : "Paul", 1
"numeros" : [ {"libelle" : "mobile", "numero" : "06123456"},
documents {"libelle" : "fixe", "numero" : "03123456"}]
 Il n’y a pas de réponse générale sur la façon de construire de }
0..*
modèles de données en MongoDB mais cela dépend de l’application  Modèle avec références (JSON)
Numéro
à développer  Collection des contacts Libellé
 { "_id" : 10, "nom" : "Dupont", "prenom" : "Paul"}
 Quelles sont les données à modéliser ? Numéro
 Collection des numéros (valeur _id générée)
 Quel usage veut-on en faire ?  { "contact_id" : 10, "libelle" : "mobile", "numero" : "06123456"}
 Imbrication ou références ? Dans quels cas ?  { "contact_id" : 10, "libelle" : "fixe", "numero" : "03324144"}

M1 Informatique - SGD - N. Cullot 51 M1 Informatique - SGD - N. Cullot 52

CM1 : Patrons de conception appliqués en MongoDB CM1 : Patrons de conception appliqués en MongoDB
Imbrication ou références Imbrication ou références
 Imbrication des relations 1-n pour des raisons de proximité  Imbrication des relations 1-n pour des raisons d'atomicité
 MongoDB ne supporte pas le mécanisme de gestion des transactions du
 Le coût d'accès aux données est plus optimisé si elles sont stockées modèle relationnel
de façon contiguë,  Qui assure qu'une suite de requêtes sera faite correctement complètement ou ne sera
 MongoDB stocke les données d'un objet de façon séquentielle pas faite

 La recherche des informations d'un contact avec la structure  La suppression d'un contact avec les références peut conduire à un
état "incorrect" des données
imbriquée est plus aisée  [Link]({"_id":10});
 [Link] ("_id":10)  [Link]({"contact_id" : 10});
 La recherche avec les références est coûteuse  Si les deux requêtes ne s'exécutent pas complètement
 [Link]({"_id":10}); [Link]({"contact_id" : 10});  La suppression d'un contact avec l'imbrication ne nécessite que la
 Plus coûteuse qu'une jointure en relationnel, pour les accès disque suppression d'un document
 [Link]({"_id":10});

M1 Informatique - SGD - N. Cullot 53 M1 Informatique - SGD - N. Cullot 54

9
 11/11/2019

CM1 : Patrons de conception appliqués en MongoDB CM1 : Patrons de conception appliqués en MongoDB
Imbrication ou références Imbrication ou références
 Le référencement pour plus de flexibilité  La recherche des commentaires (uniquement) pour un auteur
Post donné, avec l'imbrication
 Modèle imbriqué (JSON) _id  [Link]({"[Link]":"Pierre"},{"comments":1})
 { "_id" : "Post10", "auteur" : "Paul", "texte" : "SNCF" Auteur
 Va afficher tous les posts au complet (avec tous les commentaires) pour
Texte
"comments" : [ {"auteur" : "Pierre", "texte" : "Retard"}, lesquels l'auteur (ici "Pierre") a laissé un commentaire.
1
{"auteur" : "Jules", "texte" : "inOui"}]
}
 Cette recherche produit plus d'informations que nécessaires.
 Modèle avec références (JSON)  Il est possible de filtrer davantage en utilisant un script (ou une
0..* agrégation dans ce cas)
 // Collection des posts Comment  Par exemple, script écrit en python
 { "_id" : "Post10", "auteur" : "Paul", "texte" : "SNCF"} Auteur  def get_comments_by(auteur) :
 //Collection des commentaires Texte  for post in [Link]({"[Link]":"Pierre"},{"comments":1})
 { "post_id" : "Post10", "auteur" : "Pierre", "texte" : "Retard"}  for comment in post["comments"]
 If comment["auteur"]==auteur : yield post["_id], "comment"
{ "post_id" : "Post10" ,"auteur" : "Jules", "texte" : "inOui"}

M1 Informatique - SGD - N. Cullot 55 M1 Informatique - SGD - N. Cullot 56

CM1 : Patrons de conception appliqués en MongoDB CM1 : Patrons de conception appliqués en MongoDB
Imbrication ou références Imbrication ou références
 La recherche des commentaires (uniquement) pour un auteur donné,  Relations de cardinalité n-n
avec les références peut être faite en filtrant les documents de  Solutions avec imbrication
Produit
_id
commentaires  Soit construction d'un document pour chaque produit, avec un nom
 [Link]({"auteur":"Pierre"}) tableau de catégories
0..*
 Soit construction d'un document pour chaque catégorie, avec
 D'une façon générale, un tableau de produits
 Si le type de requêtes à traiter est bien identifié  Solution avec référencement 0..*
 Une structuration avec imbrication est préférable  Construction d'un document produit (sans les catégories) Categorie
 Si plusieurs types de requêtes peuvent être faites, ou si on ne connaît pas a priori  et construction d'un document categorie (sans les produits) _id
quelles sont les requêtes à traiter Texte
 et construction d'un document de liaison avec les références
 Une structuration avec des références plus "neutre" peut être préférable  Façon modèle relationnel

M1 Informatique - SGD - N. Cullot 57 M1 Informatique - SGD - N. Cullot 58

CM1 : Patrons de conception appliqués en MongoDB CM1 : Patrons de conception appliqués en MongoDB
Imbrication ou références Imbrication ou références
 La solution avec références  Une solution alternative hybride consiste,
 Nécessitent des jointures coûteuses, quelle que soit la requête posée  à inclure uniquement les identifiants des catégories dans les produits
 Produit avec catégories , Catégorie avec produits  (si la modélisation est centrée produit)
 La solution avec imbrication des catégories  Et gérer des documents pour les catégories
 {"_id": ….. "categories" : [ … ]}  Les requêtes sont plus complexes mais les mises à jour, par
 Facilite la recherche des produits avec description complète exemple des catégories sont plus simples et "sûres"
 Mais peut complexifier les mises à jour  Exemple de requête/script en python, pour avoir un produit et ses
catégories
 Par exemple, la mise à jour des informations d'une catégorie, doit être def getProduit_by(prodId)
répercutée pour tous les produits de cette catégorie prod= [Link]({"_id": prodId})
categories = list([Link]({"_id": {$in : produits["categorie_id]}))
return prod, categories
M1 Informatique - SGD - N. Cullot 59 M1 Informatique - SGD - N. Cullot 60

10
 11/11/2019

CM1 : Patrons de conception appliqués en MongoDB CM1 : Patrons de conception appliqués en MongoDB
Imbrication ou références Schéma polymorphique et Programmation Orientée Objet
 La conception de "schémas" en MongoDB n'obéit pas à des règles  MongoDB est identifié comme une Base de données sans "schéma"
strictes  Cependant la plupart du temps, une application "bien construite"
 Mais la décision de choisir des imbrications ou des références dans les
documents
 s'appuie sur des collections de documents qui contiennent
 Impacte la complexité des requêtes et des mises à jour.  des documents identiques ou "proches".

 Les "actions" prioritaires en termes de performances pour les  En POO, le principe d'héritage des classes et le polymorphisme
recherches ou pour les mises à jour permettent de gérer de façon homogène, des ensembles d'objets
 Doivent être définies en amont de la modélisation
d'une même hiérarchie.
 Pour choisir des modèles de données adaptés  Le modèle relationnel ne supporte pas directement ces
mécanismes.

M1 Informatique - SGD - N. Cullot 61 M1 Informatique - SGD - N. Cullot 62

CM1 : Patrons de conception appliqués en MongoDB CM1 : Patrons de conception appliqués en MongoDB
Schéma polymorphique et Programmation Orientée Ojbet Schéma polymorphique et données semi-structurées
 Tous les médias peuvent être gérés dans une même  Certaines applications nécessitent de gérer des données semi-structurées
collection,  Avec des caractéristiques fixes
 Les attributs spécifiques de Livre ou de AlbumCD ne sont Media  Et des caractéristiques variables qui peuvent être regroupées dans un objet
décrits que s'ils sont pertinents, _id structuré
Titre  [Link]({_id:100, "libelle" : "produit", "prix" : 99.90, "carateristiques" : {
 On peut ajouter un attribut de type pour le média Description
 [Link]( { _id: 100, "Type" : "Livre", "Titre": "NoSQL",  "capacité": 10, "largeur" : 25}})
"Description" : "BD", "Auteurs" : [ "Dupont", "Durant"]})  Cependant l'interrogation, ou l'indexation de ces champs spécifiques peut être
 [Link]( { _id: 110, "Type" : "AlbumCD", "Titre": Livre Album CD délicate s'ils ne sont pas bien "identifiés" pour la description des documents
"Musique", "Description" : "Classique", "Chanteur" : "Martin"})
Auteurs Chanteur  Une solution consiste à gérer un tableau avec le nom du champ et sa valeur
 La recherche peut se faire simplement sur les  [Link]({_id:100, "libelle" : "produit", "prix" : 99.90, carateristiques :
caractéristiques communes comme Titre ou Description [["capacité", 10], [largeur, 25]]})
 Mais également sur les attributs spécifiques
 Un index peut être créé, sur le champ "caracteristiques"
 [Link]({"Chanteur" : "Martin"})
 [Link]({"carateristiques":1})
 Les schémas polymorphiques facilite également l'évolution  [Link]({"carateristiques" : ["capacite", 10]})
des schémas
M1 Informatique - SGD - N. Cullot 63 M1 Informatique - SGD - N. Cullot 64

CM1 : Patrons de conception appliqués en MongoDB

Schéma polymorphique
 La flexibilité offerte par MongoDB
 qui n'impose pas la gestion de documents strictement similaires,
 mais supporte la gestion de documents proches,
 permet
 D'avoir des mécanismes proches de l'héritage de la POO
 De simplifier les évolutions ou les migrations de schémas
 Fournir un bon support pour modéliser des données semi-structurées

M1 Informatique - SGD - N. Cullot 65

11