systèmes de gestion de documents master informatique...
Post on 03-Oct-2020
0 Views
Preview:
TRANSCRIPT
11/11/2019
1
Systèmes de Gestion de DocumentsMaster Informatique – 1ère année
Nadine CULLOT – nadine.cullot@u-bourgogne.fr (CM,TD et TP)
Richard GENESTIER – richard.genestier@u-bourgogne.fr (TD, TP)
M1 Informatique - SGD - N. Cullot 1
Module Systèmes de gestion de documents
Objectifs Les bases de données NoSQL
Les systèmes de gestion de bases de données NoSQL orientées documents
Le système MongoDB
Organisation 6h CM, 8h TD et 8h 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 2
Module Systèmes de gestion de documents
CM1 : Bases de données relationnelles et bases NoSQL (Not Only SQL) Introduction
Modèle relationnel, modèle transactionnel (OLTP) Modèle analytique (OLAP), Schéma en étoile, Entrepôts de données, ETL L’émergence des bases de données NoSQL
Classements des moteurs NoSQL Par schémas de données, par usage
Les techniques mises en œuvre en NoSQL Architecture distribuée et analytique
Les bases NoSQL orientées Documents Représentation de documents : Le format JSON
Modélisation Conception d'une base de données relationnelle Conception NoSQL avec des documents structurés Relationnel et NoSQL
La base de données orientée documents : MongoDB Caractéristiques Les opérations CRUD en MongoDB
Patrons de conception appliqués pour MongoDB Imbrication ou références Schémas polymorphiques
M1 Informatique - SGD - N. Cullot 3
SGD – CM1 – Introduction
Le modèle relationnel Modèle qui s’est imposé à partir des années 1980 avec des SGBDR comme
Oracle
Caractéristiques agréées par la communauté Structuration forte des données
Représentation à l’aide de tables
Langage déclaratif
Séparation du modèle logique du modèle physique
Contraintes implémentées au niveau du SGBD
Cohérence transactionnelle forte
Etc.
Ces règles constituent « Les douze règles de CODD » parues dans en 1985 dans deux articles (par Edgard Codd).
M1 Informatique - SGD - N. Cullot 4
SGD – CM1 – Introduction
Modèle relationnel performant pour une utilisation transactionnelle OLTP : Online Transactional Processing Adapté pour des traitements de consultation et de mise à jour fréquents mais
avec des résultats de taille plutôt petite Exemple : Gestion de factures, de stocks, etc.
y compris pour des tables dont les cardinalités peuvent être importantes Requêtes optimisées avec des index
Autres besoins : l’informatique décisionnelle Extraction de données pour leur analyse, et leur visualisation adaptée à des
fins décisionnelles Analyses historiques de données, analyses prédictives, etc. Visualisation adaptée : tableaux de bord
OLAP : Online Analytical Processing
M1 Informatique - SGD - N. Cullot 5
SGD – CM1 – Introduction
Le modèle OLAP (Online Analitycal Processing) Est apparu en raison
de l’augmentation du stockage de données agrégées et historiques des besoins analytiques dans les domaines métiers des entreprises
Pour Permettre des requêtes globales sur des grands volumes de données
Adaptation de la structuration des données : le schéma en étoile La table au « centre » de l’étoile comporte le détail (mesures, faits, ..)
Ex: détail d’une commande Les tables des « extrémités » sont les axes d’analyse (dimensions)
Ex: Client, Produit, Vendeur, Date, etc.
Analyse multi-dimensionnelle (MOLAP) Le modèle OLAP a aussi été formalisé par E. Codd Le modèle OLAP s’appuie sur la construction d’entrepôt de données
M1 Informatique - SGD - N. Cullot 6
11/11/2019
2
SGD – CM1 – Introduction
Un entrepôt de données (aussi appelé base de données décisionnelle) Est une base de données adaptée pour
La collecte, l’ordonnancement, la journalisation et le stockage d’informations provenant d’une base de données opérationnelle ou d’autres sources
Vise à fournir une base pour l’aide à la décision
Apparition d’outils performants : les ETL ETL : Extract – Transform – Load
Extract : logiciel qui facilite l’extraction de données multi-sources
Transform : Logiciel qui permet le filtrage et la mise en forme des données
Load : Logiciel de chargement dans l’entrepôt
Interrogation des données avec une vision dite « cube » ou « hypercube » intégrée dans des outils d’analyse
M1 Informatique - SGD - N. Cullot 7
SGD – CM1 – IntroductionL’émergence du NoSQL
Les évolutions matérielles Interconnexions des réseaux, augmentation des bandes passantes,
Diminution des coûts, optimisations des techniques de stockage,
Etc.
Ont ouvert des possibilités de gestion et de traitements de données de très grands volumes (en pétaoctets - 1015 octets) Emergence du « Big Data »
Les évolutions logicielles visent à s’adapter à ces nouvelles capacités Pour la représentation des données : modélisation, langage de manipulation
Pour la recherche et l’analyse : moteurs de recherche, index, algorithmes
Pour le stockage distribué : systèmes distribués NoSQL
Pour le traitement massif et distribué (MapReduce, etc.)
M1 Informatique - SGD - N. Cullot 8
SGD – CM1 – IntroductionL’émergence du NoSQL
Certaines entreprises ont développé des solutions propriétaires de SGBD pouvant fonctionner Sur des architectures distribuées Pour traiter des volumes importants de données
On peut citer : Google -> BigTable (« A Distributed Storage System for Structured Data » – 2006)
Amazon -> Dynamo (Entrepôt de paires clé-valeur – architecture distribuée - 2007)
Facebook -> Cassandra puis HBase (projet Apache Cassandra en 2009)
Etc.
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
SGD – CM1 - Classement des moteurs NoSQLPar schémas de données
On peut classer les moteurs NoSQL selon leur usage ou leur schéma de données.
Pour les schémas de données, on peut distinguer 5 modèles Les moteurs qui manipulent des paires clé-valeur
Les moteurs orientés documents
Les moteurs orientés colonnes
Les moteurs orientés graphes
Autres moteurs spécifiques
M1 Informatique - SGD - N. Cullot 10
SGD – CM1 - Classement des moteurs NoSQLPar schémas de données
Les moteurs NoSQL : clé-valeur
Les données sont représentées par un couple clé-valeur.
La valeur peut être simple ou un objet sérialisé
Le modèle est similaire à une table de hashage distribuée
M1 Informatique - SGD - N. Cullot 11
SGD – CM1 - Classement des moteurs NoSQL
Les moteurs NoSQL : clé-valeur
Ces moteurs offrent peu de fonctionnalités mais d’excellentes performances grâce au modèle d’accès simplifié
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 12
11/11/2019
3
SGD – CM1 - Classement des moteurs NoSQLPar schémas de données
Les moteurs orientés documents Ils reposent sur le paradigme clé-valeur mais la valeur est remplacée par un
document Le format des documents le plus populaire est le JSON (JavaScript Object Notation)
Document
DocumentM1 Informatique - SGD - N. Cullot 13
SGD – CM1 - Classement des moteurs NoSQLPar schémas de données
Les moteurs orientés documents
Ils permettent de manipuler des documents structurés ou semi-structurés avec
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
Implémentations existantes CouchDB (fondation Apache)
RavenDB (pour plateformes .NET/Windows – LINQ)
MongoDB (1ère version en 2009 – www.mongodb.com)
M1 Informatique - SGD - N. Cullot 14
SGD – CM1 - Classement des moteurs NoSQLPar schémas de données
Les moteurs orientés colonnes
Chaque colonne est définie par un couple clé-valeur
Une super-colonne est un couple clé-valeur dont la valeur est une colonne
Une famille de colonnes permet de regrouper plusieurs colonnes ou super-colonnes
M1 Informatique - SGD - N. Cullot 15
SGD – CM1 - Classement des moteurs NoSQLPar schémas de données
Les moteurs orientés colonnes offrent une plus grande structuration des données
que les modèles clé-valeur ou orientés documents
Implémentations existantes HBase (Open Source de BigTable de Google)
Cassandra (fondation Apache) SimpleDB (Amazon)
M1 Informatique - SGD - N. Cullot 16
SGD – CM1 - Classement des moteurs NoSQLPar schémas de données
Les moteurs orientés graphe
Le modèle de données est basé sur un graphe avec les notions de nœuds, de relations entre les nœuds et de propriétés
Représentation adaptée pour certaines données comme celles issues des réseaux sociaux par exemple
Implémentation existantes Neo4j (neo4j.com) OrientDB (fondation Apache)
M1 Informatique - SGD - N. Cullot 17
SGD – CM1 - Classement des moteurs NoSQLPar usage
Il est aussi possible de distinguer les différents moteurs NoSQL selon certains critères pour leur usage comme :
La performance, l'assouplissement des structures ou la volumétrie
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
Assouplissement des structures 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
Volumétrie Capacité à monter en charge qui passe par une distribution du stockage et
des traitements
M1 Informatique - SGD - N. Cullot 18
11/11/2019
4
SGD – CM1 – Les techniques mises en œuvre en NoSQLArchitecture distribuée et Analytique
Le NoSQL est né du besoin de gérer des données volumineuses voire très volumineuses (Big-Data). La distribution des données sur plusieurs machines est une technique pour
répondre à ce besoin. Distribution des données et distribution des traitements
Avec deux possibilités avec ou sans maître
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
ayant les données
La distribution sans maître Toutes les machines jouent le même rôle. Nécessité de trouver des solutions pour diriger les
requêtes vers les machines ayant les données
Le Big-Data analytique : le paradigme de MapReduce Distribution des traitements avec 2 étapes :
Map : attribution des opérations sur chaque machine Reduce : rassemblement des résultats après traitement
M1 Informatique - SGD - N. Cullot 19
Report "NoSQL, NewSQL and Beyond: The answer to SPRAINedrelational databases", 451 Group, April 15th, 2011
SGBDR avec des nouvelles technologies pour évoluer vers les Systèmes NoSQL
BD alternatives pour gérer de grands volumes de données avec des applications distribuées
SPRAIN :ScalabilityPerformanceRelaxed ConsistencyAgilityIntricacyNecessity
M1 Informatique - SGD - N. Cullot 20
SGD – CM1 – Les bases NoSQL orientées documentsReprésentation des documents - JSON
Les documents structurés sont à la base des systèmes NoSQL Pour des traitements à grande échelle
Le format de données JSON (JavaScript Object Notation) est un format pour l’échange de données Facile à lire et écrire pour un humain, à la différence de XML par exemple
JSON se base sur deux structures Les collections de couples (paires) nom/valeur (clé/valeur) Les listes de valeurs ordonnées (tableau)
En JSON, Un objet est un ensemble non ordonné de couples nom/valeur. Un tableau est une collection ordonnée de valeurs 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
SGD – CM1 – Les bases NoSQL orientées documentsReprésentation des documents - JSON Exemples de documents JSON
Document 1 : Objet composé de couples nom/valeur{ "nom": "Dupont","prenom": "Jean","ville": "Paris",}
Document 2 : avec un tableau de numéros de téléphone sous forme de chaînes de caractères{ "nom": "Dupont","prenom": "Jean","ville": "Paris","telephone": [ "0612345678" , "0312345678" ]}
Document 3 : avec un tableau de numéros de téléphone sous forme de couples nom/valeur{ "nom": "Dupont","prenom": "Jean","ville": "Paris","telephone": [{"mobile" : "0612345678"} , {"fax" : "0312345678" }]
M1 Informatique - SGD - N. Cullot 22
SGD – CM1 – Les bases NoSQL orientées documentsReprésentation des documents - JSON
Document 4 : collection de couples nom/valeur, avec tableau{{ "Auteur" : { "Nom": "Dupont",
"Prénom": "Jean", }}
"Titre" : "Le livre secret","Mots-clés" : ["Roman", "Policier"]}
Les documents structurés sont relativement riches en terme de représentation Structures complexes pouvant être imbriquées avec des agrégats, des listes et des tableaux
Ils sont flexibles, par exemple on peut avoir ou non des mots-clés pour un livre, 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
SGD – CM1 – Les bases NoSQL orientées documentsReprésentation des documents - JSON
Les documents structurés JSON peuvent être vus comme des structures arborescentes
Le Livre secret [Roman, Policier]
JeanDupont
Arbre représentant un objet avec une composition d'agrégats et un tableau de valeurs (simples)
M1 Informatique - SGD - N. Cullot 24
11/11/2019
5
SGD – CM1 – ModélisationConception d'une base de données relationnelle
Principe de conception d'une base de données relationnelle Modélisation des informations
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
Modèle physique Implémentation de la base
Caractéristiques du modèle relationnel Les données sont contraintes par un schéma La normalisation du schéma vise à éviter la redondance des données 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
SGD – CM1 – ModélisationConception d'une base de données relationnelle
Exemple : Extrait d'un modèle UML modélisant des réservations de voiture dans des agences
Une société comporte une à plusieurs agences.Une agence appartient à une société.
Une réservation concerne une voiture et a : une agence de départ, une agence de d'arrivée,une date de début et une date de fin.
M1 Informatique - SGD - N. Cullot 26
SGD – CM1 – ModélisationConception d'une base de données relationnelle Le schéma relationnel
Tables pour l'extrait de diagramme présenté
Société (idS, nom) Voiture (numV, capacité, modèle, prix) Agence (numA, nom, adresse, numSociété) Réservation(numéro, nom, dateDébut, dateFin, numAD, numAA, numV)
Insertion des données dans les tables En respect des contraintes d'intégrité
Requêtes avec jointure : toutes les réservations avec les modèles de voiture et le nom des agences
select r.numéro, r.nom, v.modèle, ad.nom, aa.nomfrom réservation r, agence ad, agence aa, voiture vwhere r.numV=v.numV
and r.numAA=aa.numA and r.numAD=ad.numA;
M1 Informatique - SGD - N. Cullot 27
SGD – CM1 – ModélisationConception NoSQL avec documents structurés
Les bases de données orientées documents gèrent des documents structurés et des collections de documents
Modélisation possible des données de façon arborescente, plus puissante que la modélisation tabulaire du
modèle relationnel
Avec une représentation possible de liste de valeurs pour certaines caractéristiques
En reprenant l'exemple présenté, des réservations de voiture, il est possible de structurer les informations Avec des documents qui décrivent l'ensemble des données d'une réservation
M1 Informatique - SGD - N. Cullot 28
SGD – CM1 – ModélisationConception NoSQL avec documents structurés
Description d'un document pour une réservation{ "numéro" : "123",
"nom":"resa123",
"dateD" : "12/10/2017,
"dateF" : "17/10/2017"
"agenceD" : { " numA" : "211",
"nom" : "DijonCentre",
"adresse" : "Dijon" },
"agenceA" : { " numA" : "331",
"nom" : "BordeauxCentre",
"adresse" : "Bordeaux" };
"voiture" : { "numV" : "666AA21",
"capacité : "5",
"modèle" : "Renault", "
prix : "200" }
}
M1 Informatique - SGD - N. Cullot 29
SGD – CM1 – ModélisationConception NoSQL avec documents structurés
L'ensemble des informations concernant une réservation sont "regroupées"
Et constitue une auto-description d'une réservation
La manipulation de documents autonomes permet une gestion des informations plus aisée dans un environnement distribué.
Ces regroupements peuvent améliorer les performances pour des collections de données massives. Mais pas de façon homogène selon les requêtes qui sont évaluées
Par exemple, la représentation proposée en centrée sur les réservations, qui sont décrites au niveau de la racine de l'arborescence Les informations sur les agences concernées par les réservations sont imbriquées
M1 Informatique - SGD - N. Cullot 30
11/11/2019
6
SGD – CM1 – ModélisationConception NoSQL avec documents structurés
Les inconvénients liés à la modélisation avec des documents structurés Absence de vue "simple" des entités
Ici les agences sont dans les réservations Ou nécessité de travailler avec d'autres documents pour avoir une connaissance des
agences Par exemple avec les société
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
cette agence
La structuration retenue dans les documents privilégie un certain usage de la base de données Avec une connaissance "a priori"
M1 Informatique - SGD - N. Cullot 31
SGD – CM1 – ModélisationConception NoSQL avec documents structurés
Principe de conception d'une BD NoSQL orientée documents Analyser informellement les informations/données à modéliser
Spécifier un modèle conceptuel (UML par exemple) Pour aider à répertorier l'ensemble de informations à modéliser
Spécifier les types de requêtes qui devront être prises en charge, et les modèles d'accès spécifiques de l'application Pour aider à spécifier les documents à construire
Spécifier le modèle de documents En "dénormalisant" le modèle usuel de BD (relationnel)
Pour privilégier l'accès aux données pour les requêtes envisagées
Favoriser l'optimisation et la performance au détriment de la "neutralité" 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 32
SGD – CM1 – ModélisationNoSQL et relationnel Les systèmes NoSQL ne comportent en général pas de schéma des données
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 Pas de schéma, pas de contrôle d'intégrité sur les données Pas de gestion des transactions
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.)
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 BD relationnelles et les Bases de données NoSQL sont complémentaires et n'ont 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
M1 Informatique - SGD - N. Cullot 33
SGD – CM1 – La base de données orientée documents: MongoDBCaractéristiques
MongoDB est un système de gestion de données NoSQL Orienté document, très populaire
Développé par la société américaine MongoDB Inc.
Disponible depuis 2009
MongoDB est codé en C++
Les documents sont codés en interne dans le format BSON (BinarySerialized dOcument Notation ou Binary JSON).
Pour l'utilisateur les documents sont en format JSON (JavaScript Object Notation)
M1 Informatique - SGD - N. Cullot 34
SGD – CM1 – La base de données orientée documents: MongoDBCaractéristiques
Les documents sont gérés dans des collections. Tous les documents d'une collection ne sont pas nécessairement identiques
Chaque document est identifié par une clé unique dans une collection Qui peut être comparée à la notion de clé primaire d'une table relationnel
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
d'une taille de 96 octets)
Les collections peuvent être regroupées dans des espaces de noms et sont stockées dans des bases de données
Une BD est une collection de collections
Les bases de données sont créées "à la demande" lorsqu'elles sont mentionnées dans une commande
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
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
En salle TP, la base de données MongoDB est installée sur le serveur mongo. Accès au serveur mongo
ssh nomLogin@mongo
Chaque utilisateur a une base de données mongo –u nomLogin –p
Enter password : // taper le mot de passe pour le compte MongoDB
Connecting to : test
>use nomLogin // le nom de la base est identique au nom de login
Switched to db nomLogin
> // instructions
M1 Informatique - SGD - N. Cullot 36
11/11/2019
7
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de création d'un document dans une collection Insertion d'une agence dans une collection nommée agences
Avec une génération automatique de l'identifiant
db.agences.insertOne({ "numAgence" : "123",
"nom" : "Agence Dijon centre","adresse" : "Dijon"
} )Résultat à l'exécution (valeur de l'identifiant du document créé){
"acknowledged" : true,"insertedId" : ObjectId("5a088e5e8f32bee62a2b6438")
}
M1 Informatique - SGD - N. Cullot 37
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de création d'un document dans une collection Insertion d'une agence dans une collection nommée agences
Avec un identifiant fourni
db.agences.insertOne(
{ _id : 100,
"numAgence" : "123",
"nom" : "Agence Dijon centre",
"adresse" : "Dijon"
} )
Résultat à l'exécution (valeur de l'identifiant du document créé)
{ "acknowledged" : true, "insertedId" : 100 }
M1 Informatique - SGD - N. Cullot 38
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de création d'un document dans une collection Insertion de plusieurs agences dans une collection nommée agences
Avec la génération des identifiants
db.agences.insertMany([ {"numAgence" : "658",
"nom" : "Agence Dijon Mansard","adresse" : "Dijon"
} ,{"numAgence" : "245",
"nom" : "Agence Dijon Université","adresse" : "Dijon"
} ] )Résultat à l'exécution {
"acknowledged" : true,"insertedIds" : [
ObjectId("5a08941ca9c3d4982f5b3039"),ObjectId("5a08941ca9c3d4982f5b303a")
]}
M1 Informatique - SGD - N. Cullot 39
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de lecture (read) de documents dans une collection Lecture de tous les documents
db.agences.find()
{ "_id" : ObjectId("5a088e5e8f32bee62a2b6438"), "numAgence" : "123", "nom" : "Agence Dijon centre", "adresse" : "Dijon" }{ "_id" : 110, "numAgence" : "234", "nom" : "Agence Dijon Valmy", "adresse" : "Dijon" }{ "_id" : ObjectId("5a08941ca9c3d4982f5b3039"), "numAgence" : "555", "nom" : "Agence Dijon Mansard", "adresse" : "Dijon" }{ "_id" : ObjectId("5a08941ca9c3d4982f5b303a"), "numAgence" : "555", "nom" : "Agence Dijon Universite", "adresse" : "Dijon" }
M1 Informatique - SGD - N. Cullot 40
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de lecture (read) de documents dans une collection Lecture de documents avec un filtre (critère de sélection)
db.agences.find({ "numAgence" : "234"})
{ "_id" : 110, "numAgence" : "234", "nom" : "Agence Dijon Valmy", "adresse" : "Dijon" }
Etude des requêtes (CM2)
M1 Informatique - SGD - N. Cullot 41
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de mise à jour (update) d'un document dans une collection
Mise à jour d'un document : modification du nom de l'agence de numéro 234db.agences.updateOne({ "numAgence" : "234"}, {$set: {"nom" : "Agence Valmy" }})
Valeur avant la mise à jour{ "_id" : 110, "numAgence" : "234", "nom" : "Agence Dijon Valmy", "adresse" : "Dijon" }
A l'exécution { "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }
Valeur après la mise à jour { "_id" : 110, "numAgence" : "234", "nom" : "Agence Valmy", "adresse" : "Dijon" }
M1 Informatique - SGD - N. Cullot 42
11/11/2019
8
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de mise à jour (update) de plusieurs documents dans une collection Mise à jour des documents ayant l'adresse "Dijon"
db.agences.updateMany({ "adresse" : "Dijon"}, {$set: {"adresse" : "Dijon Centre" }})
A l'exécution
{ "acknowledged" : true, "matchedCount" : 4, "modifiedCount" : 4 }
Les 4 agences ont été mises à jour.
M1 Informatique - SGD - N. Cullot 43
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de mise à jour avec remplacement d'un document dans une collection db.agences.replaceOne({ "numAgence" : "234"}, { "numAgence" : "464",
"nom" : "Agence Gare", "adresse" : "Dijon" })
A l'exécution
{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }
L'identifiant de l'objet est conservé.
{ "_id" : 110, "numAgence" : "464", "nom" : "Agence Gare", "adresse" : "Dijon" }
M1 Informatique - SGD - N. Cullot 44
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
Opération de suppression d'un ou plusieurs documents dans une collection
Suppression de l'agence dont l'identifiant vaut 110db.agences.deleteOne({ "_id" : 110})
Suppression de l'agence dont l'identifiant a été générédb.agences.deleteOne({ "_id" : ObjectId("5a08941ca9c3d4982f5b303a")})
Suppression de tous les documents ayant une certaine adresse
db.agences.deleteMany ({"adresse" : "Dijon Centre"})
M1 Informatique - SGD - N. Cullot 45
SGD – CM1 – La base de données orientée documents : MongoDBLes opérations CRUD en MongoDB
La méthode "bulkWrite" permet l'exécution de plusieurs opérations décrites dans une collection. db.agences.bulkWrite(
[ { insertOne : {"document" :
{ "numAgence" : "444", "nom" : "Agence Valmy", "adresse" : "Dijon"}
}
},
{updateOne : { "filter" :{ "numAgence" : "444"}, "update" : {$set: {"nom" : "Agence Dijon Valmy" }}}
}
])
M1 Informatique - SGD - N. Cullot 46
SGD – CM1 – NoSQL et BD relationnelles
Emergence des modèles NoSQL Pour gérer des données massives de façon optimisée Pour répondre à des besoins d’analyses sur des données historiques ou à des
fins décisionnelles prédictives
Mise en œuvre de technologies spécifiques Abandon de contraintes pour la modélisation
Modèles adaptés à la gestion de gros volumes de données
Distribution du stockage Distribution des traitements
NoSQL et BD relationnelles ne répondent pas aux mêmes besoins Des initiatives comme NewSQL pour faire évoluer SQL vers des technologies
NoSQL
M1 Informatique - SGD - N. Cullot 47
CM1 : Patrons de conception appliqués en MongoDB
MongoDB permet de gérer des documents structurés (en JSON) qui supportent des structures de données complexes comme Les documents composés avec des structures imbriquées
Des tableaux de valeurs simples ou de structures, avec des imbrications possibles
Etc.
Le choix d’un modèle de données pour le développement d’une application est un enjeu important pour permettre Une interrogation aisée des données
Un passage à l’échelle pour des données volumineuses distribuées
M1 Informatique - SGD - N. Cullot 48
11/11/2019
9
CM1 : Patrons de conception appliqués en MongoDB
Le modèle relationnel s’appuie sur des règles de normalisation qui de façon simplifiée Permet la représentation des données de façon homogène dans des tables
S’assure que chaque valeur d’une table est une valeur simple
Évite la redondance des données; ce qui facilite leur mise à jour
Se base sur les notions de clés primaires et clés étrangères pour lier des données entre-elles
Le modèle de documents structurés et les objectifs des applications développées en MongoDB, notamment pour des données massives remettent en cause la normalisation pour des raisons de performance
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
objets à l’aide d’identifiant ?
M1 Informatique - SGD - N. Cullot 49
CM1 : Patrons de conception appliqués en MongoDB
La normalisation des données comme dans le modèle relationnel présente des avantages importants comme la facilité de mise à jour des données, et
leur non-redondance
mais aussi des inconvénients comme le coût d’accès aux données qui ne sont pas stockées de façon contiguë,
le coût de la réalisation de jointures (avec de nombreux accès aux données des différentes tables)
Le modèle relationnel applique parfois des techniques de « dénormalisation » pour optimiser les requêtes.
On peut cependant s’interroger sur la nécessité de normaliser les données dans des modèles de documents comme MongoDB.
M1 Informatique - SGD - N. Cullot 50
CM1 : Patrons de conception appliqués en MongoDB
MongoDB offre nativement un modèle qui permet de gérer des données structurées multivaluées Ce qui est un avantage pour les performances
Mais pose le problème de la redondance possible des données dans les documents
Il n’y a pas de réponse générale sur la façon de construire de modèles de données en MongoDB mais cela dépend de l’application à développer Quelles sont les données à modéliser ?
Quel usage veut-on en faire ?
Imbrication ou références ? Dans quels cas ?
M1 Informatique - SGD - N. Cullot 51
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
Relations de cardinalité 1-n. Un contact (_id, nom, prénom) possède plusieurs numéros (libellé, numéro)
Modèle imbriqué (JSON) { "_id" : 10, "nom" : "Dupont", "prenom" : "Paul",
"numeros" : [ {"libelle" : "mobile", "numero" : "06123456"},{"libelle" : "fixe", "numero" : "03123456"}]
}
Modèle avec références (JSON) Collection des contacts
{ "_id" : 10, "nom" : "Dupont", "prenom" : "Paul"}
Collection des numéros (valeur _id générée) { "contact_id" : 10, "libelle" : "mobile", "numero" : "06123456"} { "contact_id" : 10, "libelle" : "fixe", "numero" : "03324144"}
M1 Informatique - SGD - N. Cullot 52
Contact_idNomPrénom
NuméroLibelléNuméro
0..*
1
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
Imbrication des relations 1-n pour des raisons de proximité
Le coût d'accès aux données est plus optimisé si elles sont stockées de façon contiguë, MongoDB stocke les données d'un objet de façon séquentielle
La recherche des informations d'un contact avec la structure imbriquée est plus aisée db.contacts.find ("_id":10)
La recherche avec les références est coûteuse db.contacts.find({"_id":10}); db.numeros.find({"contact_id" : 10});
Plus coûteuse qu'une jointure en relationnel, pour les accès disque
M1 Informatique - SGD - N. Cullot 53
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
Imbrication des relations 1-n pour des raisons d'atomicité MongoDB ne supporte pas le mécanisme de gestion des transactions du
modèle relationnel Qui assure qu'une suite de requêtes sera faite correctement complètement ou ne sera
pas faite
La suppression d'un contact avec les références peut conduire à un état "incorrect" des données db.contacts.deleteOne({"_id":10}); db.numeros.deleteMany({"contact_id" : 10});
Si les deux requêtes ne s'exécutent pas complètement
La suppression d'un contact avec l'imbrication ne nécessite que la suppression d'un document db.contacts.deleteOne({"_id":10});
M1 Informatique - SGD - N. Cullot 54
11/11/2019
10
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
Le référencement pour plus de flexibilité
Modèle imbriqué (JSON) { "_id" : "Post10", "auteur" : "Paul", "texte" : "SNCF"
"comments" : [ {"auteur" : "Pierre", "texte" : "Retard"},
{"auteur" : "Jules", "texte" : "inOui"}]
}
Modèle avec références (JSON) // Collection des posts
{ "_id" : "Post10", "auteur" : "Paul", "texte" : "SNCF"}
//Collection des commentaires { "post_id" : "Post10", "auteur" : "Pierre", "texte" : "Retard"}
{ "post_id" : "Post10" ,"auteur" : "Jules", "texte" : "inOui"}
M1 Informatique - SGD - N. Cullot 55
Post_idAuteurTexte
CommentAuteurTexte
0..*
1
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
La recherche des commentaires (uniquement) pour un auteur donné, avec l'imbrication db.posts.find({"comments.auteur":"Pierre"},{"comments":1}) Va afficher tous les posts au complet (avec tous les commentaires) pour
lesquels l'auteur (ici "Pierre") a laissé un commentaire.
Cette recherche produit plus d'informations que nécessaires.
Il est possible de filtrer davantage en utilisant un script (ou une agrégation dans ce cas) Par exemple, script écrit en python def get_comments_by(auteur) :
for post in db.posts.find({"comments.auteur":"Pierre"},{"comments":1}) for comment in post["comments"] If comment["auteur"]==auteur : yield post["_id], "comment"
M1 Informatique - SGD - N. Cullot 56
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
La recherche des commentaires (uniquement) pour un auteur donné, avec les références peut être faite en filtrant les documents de commentaires db.comments.find({"auteur":"Pierre"})
D'une façon générale, Si le type de requêtes à traiter est bien identifié
Une structuration avec imbrication est préférable
Si plusieurs types de requêtes peuvent être faites, ou si on ne connaît pas a priori quelles sont les requêtes à traiter
Une structuration avec des références plus "neutre" peut être préférable
M1 Informatique - SGD - N. Cullot 57
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
Relations de cardinalité n-n
Solutions avec imbrication Soit construction d'un document pour chaque produit, avec un
tableau de catégories
Soit construction d'un document pour chaque catégorie, avec un tableau de produits
Solution avec référencement Construction d'un document produit (sans les catégories)
et construction d'un document categorie (sans les produits)
et construction d'un document de liaison avec les références Façon modèle relationnel
M1 Informatique - SGD - N. Cullot 58
Produit_idnom
Categorie_idTexte
0..*
0..*
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
La solution avec références Nécessitent des jointures coûteuses, quelle que soit la requête posée
Produit avec catégories , Catégorie avec produits
La solution avec imbrication des catégories {"_id": ….. "categories" : [ … ]}
Facilite la recherche des produits avec description complète
Mais peut complexifier les mises à jour
Par exemple, la mise à jour des informations d'une catégorie, doit être répercutée pour tous les produits de cette catégorie
M1 Informatique - SGD - N. Cullot 59
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
Une solution alternative hybride consiste, à inclure uniquement les identifiants des catégories dans les produits
(si la modélisation est centrée produit)
Et gérer des documents pour les catégories
Les requêtes sont plus complexes mais les mises à jour, par exemple des catégories sont plus simples et "sûres"
Exemple de requête/script en python, pour avoir un produit et ses catégories
def getProduit_by(prodId)prod= db.produits.findOne({"_id": prodId})categories = list(db.categories.find({"_id": {$in : produits["categorie_id]}))return prod, categories
M1 Informatique - SGD - N. Cullot 60
11/11/2019
11
CM1 : Patrons de conception appliqués en MongoDBImbrication ou références
La conception de "schémas" en MongoDB n'obéit pas à des règles strictes Mais la décision de choisir des imbrications ou des références dans les
documents
Impacte la complexité des requêtes et des mises à jour.
Les "actions" prioritaires en termes de performances pour les recherches ou pour les mises à jour Doivent être définies en amont de la modélisation
Pour choisir des modèles de données adaptés
M1 Informatique - SGD - N. Cullot 61
CM1 : Patrons de conception appliqués en MongoDBSchéma polymorphique et Programmation Orientée Objet
MongoDB est identifié comme une Base de données sans "schéma"
Cependant la plupart du temps, une application "bien construite" s'appuie sur des collections de documents qui contiennent
des documents identiques ou "proches".
En POO, le principe d'héritage des classes et le polymorphisme permettent de gérer de façon homogène, des ensembles d'objets d'une même hiérarchie.
Le modèle relationnel ne supporte pas directement ces mécanismes.
M1 Informatique - SGD - N. Cullot 62
CM1 : Patrons de conception appliqués en MongoDBSchéma polymorphique et Programmation Orientée Ojbet
Tous les médias peuvent être gérés dans une même collection, Les attributs spécifiques de Livre ou de AlbumCD ne sont
décrits que s'ils sont pertinents, On peut ajouter un attribut de type pour le média
db.medias.insertOne( { _id: 100, "Type" : "Livre", "Titre": "NoSQL", "Description" : "BD", "Auteurs" : [ "Dupont", "Durant"]})
db.medias.insertOne( { _id: 110, "Type" : "AlbumCD", "Titre": "Musique", "Description" : "Classique", "Chanteur" : "Martin"})
La recherche peut se faire simplement sur les caractéristiques communes comme Titre ou Description Mais également sur les attributs spécifiques
db.medias.find({"Chanteur" : "Martin"})
Les schémas polymorphiques facilite également l'évolution des schémas
M1 Informatique - SGD - N. Cullot 63
Media_id
TitreDescription
LivreAuteurs
Album CDChanteur
CM1 : Patrons de conception appliqués en MongoDBSchéma polymorphique et données semi-structurées
Certaines applications nécessitent de gérer des données semi-structurées Avec des caractéristiques fixes Et des caractéristiques variables qui peuvent être regroupées dans un objet
structuré db.produits.insertOne({_id:100, "libelle" : "produit", "prix" : 99.90, "carateristiques" : { "capacité": 10, "largeur" : 25}})
Cependant l'interrogation, ou l'indexation de ces champs spécifiques peut être délicate s'ils ne sont pas bien "identifiés" pour la description des documents Une solution consiste à gérer un tableau avec le nom du champ et sa valeur
db.produits.insertOne({_id:100, "libelle" : "produit", "prix" : 99.90, carateristiques : [["capacité", 10], [largeur, 25]]})
Un index peut être créé, sur le champ "caracteristiques" db.produits.createIndex({"carateristiques":1}) db.produits.find({"carateristiques" : ["capacite", 10]})
M1 Informatique - SGD - N. Cullot 64
CM1 : Patrons de conception appliqués en MongoDBSché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
top related