Systèmes de Gestion de documents Master Informatique...

11/11/2019

1

Systèmes de Gestion de DocumentsMaster Informatique – 1ère année

Nadine CULLOT – [email protected] (CM,TD et TP)

Richard GENESTIER – [email protected] (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


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


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



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



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


mailto:[email protected]

mailto:[email protected]

11/11/2019

2


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


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


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


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



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


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)


11/11/2019

3


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


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)



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



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)



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)


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


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


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


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


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" }]



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



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)


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


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.


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;


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



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" }

}



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


11/11/2019

6


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"



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


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


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)


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


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


11/11/2019

7


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")

}



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 }



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")

]}



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" }



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)



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" }


11/11/2019

8


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.



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" }



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"})



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" }}}

}

])


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


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


11/11/2019

9


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 ?



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.



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 ?


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"}


Contact_idNomPrénom

NuméroLibelléNuméro

0..*

1


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



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});


11/11/2019

10


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"}


Post_idAuteurTexte

CommentAuteurTexte

0..*

1


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"



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



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


Produit_idnom

Categorie_idTexte

0..*

0..*


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



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


11/11/2019

11


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


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.


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


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]})


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


Date post:	03-Oct-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times