M115 - Chapitre 2 : Modélisation des données pour applications mobiles et IoT

Flashcards de révision couvrant les concepts de modélisation NoSQL documentaire, JSON/BSON, architecture des collections IoT, requêtes CRUD et agrégations MongoDB, ainsi que les stratégies de synchronisation local-cloud.

Quels sont les objectifs majeurs de la modélisation de données abordés dans ce cours ?

Représenter une donnée métier en JSON et définir le rôle de BSON, concevoir des collections avec documents imbriqués ou références, modéliser des séries de mesures IoT horodatées, élaborer une stratégie de synchronisation local ↔ cloud et écrire des requêtes CRUD avancées avec MongoDB.

Qu'est-ce que le format JSON et comment structure-t-il l'information ?

JSON est un format textuel structuré en paires clé/valeur, utilisant des accolades { } pour délimiter les objets et des crochets [ ] pour organiser des listes ordonnées (tableaux).

Quels sont les différents types de données usuels pris en charge par JSON ?

Les chaînes de caractères, les nombres, les booléens (true, false), la valeur null, les objets et les tableaux.

Quelle est la différence fondamentale de rôle entre un objet { } et un tableau [ ] en JSON ?

L'objet { } regroupe des propriétés pour décrire une entité spécifique, tandis que le tableau [ ] regroupe une liste ordonnée de plusieurs éléments.

Que signifie l'acronyme BSON et quelles sont ses caractéristiques par rapport au JSON ?

BSON signifie Binary JSON. Il s'agit d'une représentation binaire des documents utilisée par MongoDB. Ce n'est ni du JSON compressé, ni un format nécessairement plus compact en taille.

Quelles sont les distinctions clés entre JSON et BSON en termes de lisibilité, types et cas d'usage ?

JSON est un format texte directement lisible par l'humain, limité aux types standards et employé pour les échanges/API. BSON est binaire, nécessite un décodage, prend en charge des types supplémentaires (comme ObjectId ou Date) et sert au stockage interne dans MongoDB.

À quoi correspondent les types BSON ObjectId et Date dans mongosh ?

ObjectId est un identifiant BSON unique souvent attribué au champ _id, tandis que Date représente une valeur temporelle horodatée exprimée via ISODate("…").

Comment s'articule la hiérarchie de stockage dans MongoDB (base, collection, document) ?

Une base de données (ex. smartBuilding) regroupe des collections (ex. measurements), qui contiennent des documents BSON dotés chacun d'un champ _id unique.

Que désigne la notion de « schéma flexible » dans MongoDB ?

Elle désigne le fait que des documents appartenant à une même collection peuvent comporter des ensembles de champs différents, sans structure rigide imposée a priori.

Dans quelles conditions est-il préconisé d'utiliser des documents imbriqués (embarqués) ?

Lorsque les données sont consultées ensemble, que leur volume reste limité et prévisible, et que leur cycle de vie est directement lié à celui du document parent (ex. l'emplacement d'une salle).

Pour quelles raisons doit-on privilégier l'usage de références (collections distinctes) ?

Pour gérer des données volumineuses ou en croissance continue, pour permettre des mises à jour indépendantes ou pour partager une entité entre plusieurs documents (ex. l'historique des mesures d'un capteur).

Pour un capteur générant $1$ mesure par minute, quel est le volume de données produit par jour et sur $30$ jours, et quel choix d'architecture cela impose-t-il ?

Le capteur produit $1\,440$ mesures par jour et $43\,200$ mesures en $30$ jours. Cette volumétrie croissante impose de dissocier la fiche descriptive du capteur de ses mesures dans des collections séparées.

Quelles informations distinctes contiennent respectivement les collections sensors et measurements ?

sensors regroupe les métadonnées stables de l'appareil (_id, roomId, type, unit, status, installedAt), alors que measurements stocke chaque observation horodatée (sensorId, roomId, measuredAt, value, unit).

Comment et pourquoi définit-on un index composé sur la collection measurements ?

On exécute db.measurements.createIndex({ sensorId: 1, measuredAt: -1 }) afin d'accélérer les requêtes fréquentes filtrant par capteur et triant les mesures par date décroissante, évitant ainsi le parcours complet de la collection.

À quel moment une base de données est-elle réellement matérialisée dans MongoDB ?

La base n'est matérialisée qu'après la première création de données ou l'insertion explicite d'une collection.

Quelle est la différence entre insertOne() et insertMany() dans MongoDB ?

insertOne() insère un document unique dans une collection, alors que insertMany() insère une liste de plusieurs documents en une seule opération.

Que signifient les opérateurs de comparaison $gt et $gte dans une requête MongoDB find() ?

$gt correspond à « strictement supérieur » (greater than) et $gte correspond à « supérieur ou égal » (greater than or equal).

Quels sont les rôles respectifs de la projection, de .sort() et de .limit() lors d'une lecture ?

La projection sélectionne les champs à inclure ou exclure du résultat, .sort() ordonne les documents (croissant ou décroissant), et .limit() restreint le nombre maximum de résultats renvoyés.

Pourquoi emploie-t-on l'opérateur $set dans une méthode updateOne() ?

Pour modifier ou créer uniquement les champs spécifiés sans écraser ou remplacer l'intégralité du document cible.

Comment fonctionnent l'option upsert: true et l'opérateur $setOnInsert lors d'une mise à jour ?

upsert: true met à jour le document s'il existe ou l'insère s'il est manquant. L'opérateur $setOnInsert définit des valeurs appliquées exclusivement au moment de l'insertion.

Quelle vérification préalable est recommandée avant toute opération deleteMany() ?

Exécuter une requête find() avec les mêmes critères de filtrage pour s'assurer précisément des documents ciblés avant de procéder à la suppression.

Quelles étapes composent un pipeline d'agrégation calculant la moyenne des températures d'une salle par capteur ?

L'étape $match filtre les documents selon la salle et l'unité de mesure, puis $group rassemble les enregistrements par capteur (_id: "$sensorId") en calculant la moyenne via $avg: "$value".

Quelles sont les $4$ étapes du cycle de synchronisation d'une donnée saisie hors ligne vers le cloud ?

$1$. Créer localement ; $2$. Marquer comme pending ; $3$. Envoyer au cloud ; $4$. Confirmer la réception et marquer comme synced.

Comment garantit-on l'idempotence et l'absence de doublons lors de réémissions de mesures vers le cloud ?

En associant à chaque événement un identifiant unique stable (ex. eventId), couplé à un index d'unicité côté base et à des opérations d'écriture idempotentes (upsert).

Quelles approches permettent de résoudre les conflits d'édition hors ligne, et que préconise-t-on pour les mesures IoT ?

On applique une règle explicite basée sur le numéro de version, une règle métier ou un arbitrage humain. Pour les séries de mesures IoT, la recommandation est d'ajouter de nouveaux événements horodatés plutôt que d'écraser l'existant.