Compréhension des documents - Amazon DocumentDB

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Compréhension des documents

Les bases de données de documents sont utilisées pour stocker des données semi-structurées sous la forme d'un document au lieu de normaliser les données sur plusieurs tables, chacune avec une structure propre et fixe, comme dans une base de données relationnelle. Les documents stockés dans une base de données de documents utilisent des paires clé-valeur imbriquées pour fournir la structure ou le schéma du document. Cependant, différents types de documents peuvent être stockés dans une même base de données de documents, pour satisfaire ainsi à l'exigence de traitement des données similaires dans des formats différents. Par exemple, chaque document étant auto-descriptif, les documents codés au format JSON pour une boutique en ligne qui sont décrits dans la rubrique Exemple de documents dans une base de données de documents peuvent être stockés dans la même base de données de documents.

Terminologie non relationnelle et SQL et

Le tableau suivant compare la terminologie utilisée par certaines bases de données de documents (MongoDB) avec la terminologie utilisée par les bases de données SQL.

SQL MongoDB

Tableau

Collection

Rangée

Document

Colonne

Champ

Clé primaire

ObjectId

Index

Index

Vue

Vue

Table ou objet imbriqué

Document intégré

Tableau

Tableau

Documents simples

Tous les documents d'une base de données de documents sont auto-descriptifs. Cette documentation utilise des documents au format JSON, mais vous pouvez utiliser d'autres moyens de codage.

Un document simple possède un ou plusieurs champs qui se trouvent tous au même niveau dans le document. Dans l'exemple suivant, les champs SSN, LName, FName, DOB, Street, City, State-Province, PostalCode, et Country sont tous des parents dans le document.

{ "SSN": "123-45-6789", "LName": "Rivera", "FName": "Martha", "DOB": "1992-11-16", "Street": "125 Main St.", "City": "Anytown", "State-Province": "WA", "PostalCode": "98117", "Country": "USA" }

Lorsque les informations sont organisées dans un document simple, chaque champ est gérée de manière individuelle. Pour récupérer l'adresse d'une personne, vous devez extraire Street, City, State-Province, PostalCode, et Country comme des éléments de données individuels.

Documents intégrés

Un document complexe organise ses données en créant des documents intégrés dans le document. Les documents intégrés permettent de gérer les données au sein de regroupements et en tant qu'éléments de données individuels, selon ce qui est le plus efficace dans un cas donné. En utilisant l'exemple précédent, vous pouvez intégrer un document Address dans le document principal. Cette action se traduit par la structure de document suivante :

{ "SSN": "123-45-6789", "LName": "Rivera", "FName": "Martha", "DOB": "1992-11-16", "Address": { "Street": "125 Main St.", "City": "Anytown", "State-Province": "WA", "PostalCode": "98117", "Country": "USA" } }

Vous pouvez désormais accéder aux données dans le document sous la forme de champs individuels ("SSN":), en tant que document intégré ("Address":), ou en tant que membre d'un document incorporé ("Address":{"Street":}).

Exemple de documents dans une base de données de documents

Comme indiqué précédemment, chaque document d'une base de données documents est auto-descriptif, par conséquent la structure des documents au sein d'une base de données de documents peut être différente de l'un à l'autre. Les deux documents suivants, l'un pour un livre et l'autre pour une revue, ont des structures différentes. Cependant, tous les deux peuvent se trouver dans la même base de données de documents.

Voici un exemple de document de livre :

{ "_id" : "9876543210123", "Type": "book", "ISBN": "987-6-543-21012-3", "Author": { "LName":"Roe", "MI": "T", "FName": "Richard" }, "Title": "Understanding Document Databases" }

Voici un exemple de document de revue avec deux articles :

{ "_id" : "0123456789012", "Publication": "Programming Today", "Issue": { "Volume": "14", "Number": "09" }, "Articles" : [ { "Title": "Is a Document Database Your Best Solution?", "Author": { "LName": "Major", "FName": "Mary" } }, { "Title": "Databases for Online Solutions", "Author": { "LName": "Stiles", "FName": "John" } } ], "Type": "periodical" }

Comparez la structure de ces deux documents. Avec une base de données relationnelle, vous devez soit séparer les tables « périodique » et « livres », soit avoir une seule table avec des champs non utilisés, par exemple « Publication », « Numéro », « Articles » et « MI », en tant que valeurs null. Les bases de données de documents sont semi-structurées, chaque document définit sa propre structure, par conséquent ces deux documents peuvent coexister dans la même base de données de documents sans champs null. Les bases de données de documents facilitent le traitement de données fragmentées.

Le développement à partir d'une base de données de documents permet un développement rapide et itératif. En effet, vous pouvez modifier la structure des données d'un document de manière dynamique, sans devoir modifier le schéma pour la totalité de la collection. Les bases de données de documents sont idéales pour le développement souple et les environnements dynamiques et évolutifs.

Compréhension de la normalisation dans une base de données de documents

Les bases de données de documents ne sont pas normalisées. Les données trouvées dans un document peut être répétées dans un autre document. De plus, il peut exister certaines divergences de données entre les documents. Par exemple, prenez le scénario dans lequel vous effectuez un achat dans une boutique en ligne et tous les détails de vos achats sont stockés dans un seul document. Le document peut ressembler au document JSON suivant :

{ "DateTime": "2018-08-15T12:13:10Z", "LName" : "Santos", "FName" : "Paul", "Cart" : [ { "ItemId" : "9876543210123", "Description" : "Understanding Document Databases", "Price" : "29.95" }, { "ItemId" : "0123456789012", "Description" : "Programming Today", "Issue": { "Volume": "14", "Number": "09" }, "Price" : "8.95" }, { "ItemId": "234567890-K", "Description": "Gel Pen (black)", "Price": "2.49" } ], "PaymentMethod" : { "Issuer" : "MasterCard", "Number" : "1234-5678-9012-3456" }, "ShopperId" : "1234567890" }

Toutes ces informations sont stockées en tant que document dans une collection de transactions. Par la suite, vous vous rendez compte que vous avez oublié d'acheter un élément. Par conséquent, vous vous connectez à la même boutique et vous effectuez un autre achat, lequel est également stocké en tant qu'un autre document dans la collection de transactions.

{ "DateTime": "2018-08-15T14:49:00Z", "LName" : "Santos", "FName" : "Paul", "Cart" : [ { "ItemId" : "2109876543210", "Description" : "Document Databases for Fun and Profit", "Price" : "45.95" } ], "PaymentMethod" : { "Issuer" : "Visa", "Number" : "0987-6543-2109-8765" }, "ShopperId" : "1234567890" }

Il convient de noter la redondance entre ces deux documents : votre nom et votre ID d'acheteur (et, si vous avez utilisé la même carte de paiement, les informations relative à votre carte de paiement). C'est acceptable, car le stockage est peu coûteux, et chaque document enregistre complètement une seule transaction que l'on peut récupérer rapidement avec une simple requête clé-valeur qui ne nécessite pas de jonctions.

Il existe également une différence apparente entre les deux documents : les informations relatives à votre carte de paiement. Il s'agit uniquement d'une différence apparente, car vous avez probablement utilisé une autre carte de paiement différente pour chaque achat. Chaque document est approprié pour la transaction qu'il documente.