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.
Modèle de piscine pour RDF
Le Resource Description Framework (RDF) repose sur un concept de graphes nommés, qui fournit un moyen logique de séparer les données. Dans Amazon Neptune, vous disposez d'un graphe nommé par défaut et de graphes nommés définis par l'utilisateur. Vous pouvez créer autant de graphes nommés que vous le souhaitez. Collectivement, ils sont appelés ensemble de données RDF. Tous les graphes nommés, par défaut ou définis par l'utilisateur, sont définis par un identifiant de ressource internationalisé (IRI) dans le jeu de données RDF. Dans Neptune, à moins qu'un utilisateur n'ait déclaré un graphe nommé lors de l'écriture de données, tous les triplets
Il existe plusieurs cas d'utilisation pour les graphes nommés :
-
Partitionnement et isolation des données
-
Provenance des données
-
Gestion des versions
-
Inférence
Ce guide se concentre sur le cas d'utilisation du partitionnement des données. Nous recommandons de créer un graphe nommé défini par l'utilisateur pour chaque locataire.
Options de requête SPARQL utilisant le protocole HTTP Graph Store
Les exemples de requêtes suivants utilisent le protocole SPARQL, le langage de requête RDF (SPARQL) et le protocole HTTP Graph Store pour interroger ou créer un graphe nommé pour un locataire.
-
HTTP GET‒ Pour récupérer un graphique spécifique d'un locataire :curl --request GET 'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1' -
HTTP PUT‒ Pour créer ou remplacer un graphe nommé spécifique par une charge utile spécifiée dans la demande :curl --request PUT -H "Content-Type: text/turtle" \ --data-raw "@prefix ex: http://example.com/ . ex:subject ex:predicate ex:object ." \ 'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'En RDF, un objet est un triple.
-
HTTP POST‒ Pour créer un nouveau graphe nommé s'il n'en existe pas, ou pour le fusionner avec un graphique existant :curl --request POST -H "Content-Type: text/turtle" \ --data-raw "@prefix ex: http://example.com/ . ex:subject ex:predicate ex:object ." \ 'https://your-neptune-endpoint:port/sparql/gsp/?graph=http%3A//www.example.com/named/tenant1'
Isolation des locataires pour RDF
Pour une isolation logique des données avec les garde-fous nécessaires en place au niveau de la couche application, créez un mappage entre le locataire et les graphes nommés définis par l'utilisateur. Lorsque vous concevez la mutualisation pour un jeu de données RDF, tenez compte des aspects suivants de RDF et de SPARQL :
-
Dans Neptune, lorsque vous effectuez une requête sans spécifier de graphe nommé, il récupère tous les triplets correspondant au modèle dans tous les graphes nommés de la base de données.
-
En RDF, il n'existe aucune contrainte concernant les connexions entre les nœuds de graphes nommés différents. Par exemple, dans le schéma précédent, un nœud en entrée
:G1peut être connecté à un nœud en :G2via une arête.
Par exemple, si l'utilisateur final d'un locataire particulier soumet une requête à l'API, celle-ci doit valider les exigences suivantes avant de soumettre la requête à la base de données Neptune :
-
Toute requête étendue à un seul locataire doit spécifier un graphe nommé. Dans le cas contraire, vous risquez de divulguer des données entre locataires.
-
Les requêtes de mise à jour ou de suppression doivent toujours spécifier un graphe nommé.
-
Les nœuds situés de part et d'autre d'une arête ou d'une relation doivent toujours appartenir au graphe nommé correctement.
Pour plus d'informations sur les meilleures pratiques, consultez la documentation Neptune.
