Créer des tables fédérées à l'aide de liens hypertexte de table en définissant la portée

Une portée de création dans une base de données de fournisseur détermine les instances de base de données Autonomous AI de consommateur autorisées à créer des liens hypertexte de table à distance dans la base de données de fournisseur.

Vous pouvez gérer les portées de création à l'aide du package DBMS_DATA_ACCESS_SCOPE, qui fournit des procédures d'enregistrement, d'annulation d'enregistrement, de mise à jour et d'extraction des portées. Pour plus d'informations, reportez-vous à DBMS_DATA_ACCESS_SCOPE.

L'élément ADMIN (ou PDB_DBA) dans la base de données Autonomous AI du fournisseur utilise l'élément DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTER pour décider quels utilisateurs locaux sont autorisés à gérer les portées de création.

Seuls ces utilisateurs privilégiés peuvent enregistrer, mettre à jour ou annuler l'enregistrement des portées, ce qui empêche l'exposition incontrôlée des tables de fournisseurs.

Exemple

BEGIN
DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTER(
username => 'ANALYTICS_ADMIN',
scope => 'MY$COMPARTMENT'
);
END;
/

L'exemple ci-dessus accorde à l'utilisateur ANALYTICS_ADMIN le droit d'enregistrer des ensembles de données dans la portée MY$COMPARTMENT.

Reportez-vous à GRANT_REGISTER pour obtenir une référence de syntaxe.

Un fournisseur appelle DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE pour inscrire la portée autorisée pour des tables spécifiques ou des schémas entiers afin de créer des liens hypertexte de table dans ces objets.

BEGIN
DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'NULL',
scope => 'MY$COMPARTMENT'
);
END;
/

Cet exemple inscrit une portée d'accès aux données au niveau du schéma pour le schéma ANALYTICS, en l'associant au compartiment MY$COMPARTMENT.

Exemple : enregistrement d'une portée de niveau objet

BEGIN
DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'SALES_DATA',
scope => 'MY$TENANCY'
);
END;
/

Cet exemple enregistre une portée d'accès aux données plus ciblée pour un objet spécifique SALES_DATA dans le schéma ANALYTICS, en le liant à la location MY$TENANCY. Contrairement à la version de niveau schéma, schema_object_name limite l'application à cette table, ce qui permet un contrôle granulaire des droits de création.

BEGIN
DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_list => '["SALES_DATA", "CUSTOMER_DATA", "PRODUCT_DATA"]',
scope => 'MY$COMPARTMENT'
);
END;
/

Cette procédure associe les objets de schéma répertoriés (SALES_DATA, CUSTOMER_DATA et PRODUCT_DATA) à la portée MY$COMPARTMENT, ce qui limite leur création ou leur accès aux entités de ce compartiment.

Pour plus d'informations sur la syntaxe, reportez-vous à Portée de création d'enregistrement.

Si un fournisseur doit modifier l'accès, le même utilisateur ou un autre utilisateur autorisé appelle UPDATE_CREATION_SCOPE pour élargir, restreindre ou ajuster les bases de données Autonomous AI consommateur qui peuvent créer des liens hypertexte pour des objets de schéma particuliers.

BEGIN
DBMS_DATA_ACCESS_SCOPE.UPDATE_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'SALES_DATA',
scope => 'MY$COMPARTMENT'
);
END;
/

Cet exemple met à jour la portée de création de la table SALES_DATA dans le schéma ANALYTICS vers MY$COMPARTMENT.

Pour plus d'informations sur la syntaxe, reportez-vous à Portée de création de mises à jour.

Lorsqu'un fournisseur veut révoquer entièrement la fonctionnalité de création à distance (pour une table, une liste de tables ou un schéma), il appelle UNREGISTER_CREATION_SCOPE. Cela supprime la portée enregistrée et empêche la création de nouveaux liens hypertexte de table pour ces objets par les bases de données consommateur.

BEGIN
DBMS_DATA_ACCESS_SCOPE.UNREGISTER_CREATION_SCOPE(
schema_name => 'ANALYTICS',
schema_object_name => 'SALES_DATA'
);
END;
/

Cet exemple de bloc supprime une étendue de création enregistrée précédemment pour SALES_DATA dans le schéma ANALYTICS, de sorte que les objets créés sous cette étendue ne soient plus régis par l'accès aux données qui contrôle la portée appliquée.

Pour plus d'informations sur la syntaxe, reportez-vous à Annulation de l'enregistrement de la portée de création.

A tout moment, un utilisateur autorisé peut appeler LIST_CREATION_SCOPES pour extraire les définitions de portée en cours.

DECLARE
l_result CLOB;
BEGIN
DBMS_DATA_ACCESS_SCOPE.LIST_CREATION_SCOPES(
schema_name => 'ANALYTICS',
result => l_result
);
DBMS_OUTPUT.PUT_LINE(l_result);
END;
/

Reportez-vous à la section Extraire la portée de création pour obtenir une référence de syntaxe.

Dans la base de données Autonomous AI du consommateur, ADMIN (ou PDB_DBA) utilise DBMS_DATA_ACCESS_ADMIN.GRANT_READ pour accorder à des utilisateurs spécifiques le droit de créer des tables fédérées sur des schémas ou des objets de fournisseur distant.

Exemple : Accorder l'accès à un objet distant spécifique

BEGIN
DBMS_DATA_ACCESS_ADMIN.GRANT_READ(
username => 'BI_ANALYST',
remote_schema_name => 'ANALYTICS',
remote_schema_object_name => 'SALES_DATA'
);
END;
/

Cet exemple accorde à l'utilisateur BI_ANALYST un accès en lecture à l'objet SALES_DATA distant spécifique dans le schéma ANALYTICS d'un fournisseur de données externe.

Reportez-vous à Octroi d'une lecture pour obtenir une référence de syntaxe.

La procédure REVOKE_READ enlève le privilège d'un utilisateur de créer des tables fédérées sur un schéma distant ou un objet de schéma spécifié dans la base de données du fournisseur.

Si vous omettez le nom de l'objet distant, il révoque l'accès à la table fédérée de cet utilisateur pour tous les objets du schéma distant donné.

Exemple

BEGIN
DBMS_DATA_ACCESS_ADMIN.REVOKE_READ(
username => 'BI_ANALYST',
remote_schema_name => 'ANALYTICS',
remote_schema_object_name => 'SALES_DATA'
);
END;
/

Pour plus d'informations sur la syntaxe, reportez-vous à Révoquer la lecture.

Un utilisateur consommateur disposant de privilèges de lecture appelle DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE pour créer une table fédérée sur la vue ou la table de portée du fournisseur.

La procédure utilise les OCID de base de données et les informations de région pour établir des liens hypertexte de table afin que le consommateur puisse interroger des données distantes comme s'il s'agissait d'une table externe locale.

Conditions préalables

• L'utilisateur doit disposer de privilèges de lecture via la procédure GRANT_READ.
• L'utilisateur doit exister dans les bases de données consommateur et fournisseur avec les privilèges requis.
• La base de données du consommateur doit appartenir à la portée de création du fournisseur.
• Le fournisseur doit avoir une portée de création enregistrée pour les objets cible.
• Connectivité réseau établie entre les bases de données consommateur et fournisseur.

Exemple : fournisseur unique

BEGIN
DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE(
table_name => 'SALES_FED',
remote_schema_name => 'ANALYTICS',
remote_schema_object_name => 'SALES_DATA',
db_ocids => '[{"region": "IAD", "db_ocid": "OCID1.AUTONOMOUSDATABASE.OC1.IAD.EXAMPLE123"}]'
);
END;
/

Dans l'exemple ci-dessus, un destinataire appelle DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE pour créer une table fédérée locale qui connecte à la table ou à la vue d'un fournisseur distant (par exemple, SALES_DATA dans le schéma ANALYTICS), en utilisant JSON db_ocids pour indiquer la base de données de fournisseur OCIDs et les régions pour une interrogation transparente comme si elle était locale.

SELECT
REGION,
PRODUCT_ID,
SUM(SALES_AMOUNT) as total_sales,
COUNT(*) as transaction_count
FROM SALES_FED
GROUP BY REGION, PRODUCT_ID
ORDER BY total_sales DESC;

Reportez-vous à Création d'une table fédérée pour obtenir une référence de syntaxe.

Lorsque l'accès fédéré n'est plus requis, l'utilisateur destinataire appelle DBMS_DATA_ACCESS.DROP_FEDERATED_TABLE pour enlever la table fédérée.

Cette procédure nettoie l'objet côté consommateur et met fin à ce chemin d'accès fédéré particulier, tandis que les portées et privilèges du fournisseur sous-jacent restent sous le contrôle du fournisseur.

BEGIN
DBMS_DATA_ACCESS.DROP_FEDERATED_TABLE(
table_name => 'SALES_FED'
);
END;
/

L'exemple ci-dessus supprime la table SALES_FED.

Reportez-vous à Suppression de la table fédérée pour obtenir une référence de syntaxe.