Package DBMS_DCAT
Le package DBMS_DCAT fournit des fonctions et des procédures pour aider les utilisateurs d'Autonomous AI Database à tirer parti du système de repérage de données et de gestion centralisée des métadonnées d'OCI Data Catalog.
Remarque : la prise en charge de DBMS_DCAT est disponible dans Oracle AI Database 19c à partir de la version 19.30, et dans Autonomous AI Database 26ai à partir de la version 23.26.1.
Data Catalog collecte les métadonnées à partir des ressources de stockage d'objets d'un lac de données. Le processus de collecte crée des entités logiques, qui peuvent être considérées comme des tables avec des colonnes et des types de données associés. Les procédures et fonctions DBMS_DCAT connectent la base de données Autonomous AI à Data Catalog, puis synchronisent les ressources avec la base de données, créant ainsi des schémas protégés et des tables externes. Vous pouvez ensuite interroger la banque d'objets à l'aide de ces tables externes, en joignant facilement les données externes aux données stockées dans la base de données d'IA autonome. Cela simplifie considérablement le processus de gestion. Il existe une banque de métadonnées unique et gérée de manière centralisée qui est partagée entre plusieurs services OCI (y compris les bases de données d'IA autonomes). Il existe également des vues du dictionnaire de base de données Autonomous AI qui vous permettent d'inspecter le contenu de Data Catalog à l'aide de SQL et de vous montrer comment ces entités Data Catalog sont mises en correspondance avec vos tables et schémas de base de données Autonomous AI.
Utilisateurs et rôles Data Catalog
Le package DBMS_DCAT prend en charge les utilisateurs/schémas synchronisés, les utilisateurs dcat_admin et les utilisateurs locaux. Les utilisateurs doivent disposer du rôle dcat_sync pour pouvoir utiliser ce package.
Utilisateurs Data Catalog
-
Utilisateurs/schémas synchronisés
Les tables externes synchronisées sont organisées en schémas de base de données correspondant à des combinaisons ressource de données/bucket, ou en fonction des propriétés personnalisées définies par l'utilisateur. Les schémas synchronisés sont automatiquement créés/supprimés lors de la synchronisation de Data Catalog. Ils sont créés en tant qu'utilisateurs d'authentification sans le privilège
CREATE SESSION. Les schémas synchronisés sont également créés à l'aide de la clause protégée, de sorte qu'ils ne peuvent pas être modifiés par les utilisateurs locaux (pas même l'administrateur de base de données pluggable) et ne peuvent être modifiés que via la synchronisation. -
Utilisateur
dcat_adminL'utilisateur
dcat_adminest un utilisateur de base de données local qui peut exécuter une synchronisation et accorder le privilègeREADsur les tables synchronisées à d'autres utilisateurs ou rôles. L'utilisateur est créé en tant qu'utilisateur sans authentification sans le privilègeCREATE SESSION. -
Utilisateurs locaux
Les utilisateurs de base de données qui interrogent les tables externes doivent disposer explicitement de privilèges
READsur les tables externes synchronisées par les utilisateursdcat_adminou ADMIN. Par défaut, une fois la synchronisation terminée, seuls les utilisateursdcat_adminetADMINont accès aux tables externes synchronisées.
Rôles Data Catalog
-
dcat_syncLe rôle
dcat_syncdispose de tous les privilèges requis pour utiliser le packageDBMS_DCAT. Les utilisateurs doivent disposer de ce rôle pour pouvoir utiliser l'API pour naviguer dans le catalogue de données et exécuter la synchronisation.
Informations d'identification et stratégies IAM requises
Cette rubrique décrit les stratégies et les informations d'identification utilisateur Oracle Cloud Infrastructure Identity and Access Management (IAM) requises pour autoriser les utilisateurs de base de données Autonomous AI à gérer un catalogue de données et à lire à partir du stockage d'objets.
Exigences relatives aux informations d'identification et aux stratégies OCI Data Catalog :
-
Un objet d'informations d'identification avec droit d'accès permettant de gérer une instance Data Catalog est requis. Les objets d'informations d'identification contenant l'authentification native OCI sont pris en charge. Les objets d'informations d'identification basés sur les principaux d'utilisateur de jeton d'authentification et les informations d'identification de principal de ressource ne sont pas pris en charge.
Pour plus d'informations sur la gestion des informations d'identification, reportez-vous à DBMS_CLOUD for Access Management.
Pour obtenir des exemples d'authentification native OCI, reportez-vous à Exemple : création d'un objet d'informations d'identification d'authentification native OCI et à Autonomous AI Database prend désormais en charge l'accès à Object Storage avec l'authentification native OCI.
-
Le privilège Gérer le catalogue de données est requis pour que la base de données Autonomous AI ajoute des propriétés personnalisées à l'espace de noms Data Catalog. Ces privilèges vous permettent de remplacer les noms de schéma, les noms de table, les noms de colonne, etc.
Pour plus d'informations sur les droits d'accès Data Catalog, reportez-vous à Droits d'accès requis pour chaque opération d'API.
-
Le privilège de stockage d'objet en lecture sur les buckets est requis afin qu'Autonomous AI Database puisse interroger les fichiers de données.
Pour obtenir d'autres exemples de stratégie Oracle Object Storage, reportez-vous à Exemples de stratégie.
Configuration requise pour les informations d'identification et les stratégies AWS Glue Data Catalog
Les informations d'identification et stratégies utilisateur suivantes sont requises pour autoriser les utilisateurs de base de données Autonomous AI à accéder aux catalogues de données Amazon Web Services (AWS) Glue et à lire à partir du stockage d'objets S3 :
-
Un objet d'informations d'identification avec l'autorisation d'accéder à un catalogue de données AWS Glue est requis. Pour plus d'informations sur la gestion des informations d'identification, reportez-vous à DBMS_CLOUD for Access Management.
Pour accéder à un catalogue de données AWS Glue, les privilèges suivants sont requis : glue:GetDatabases , glue:GetTables et glue:GetTable.
En outre, le privilège s3:GetBucketLocation est nécessaire lors de la synchronisation pour générer des URL HTTPS pouvant être résolues pointant vers les objets S3 sous-jacents.
-
Un objet d'informations d'identification avec l'autorisation d'accéder aux fichiers stockés dans S3 est requis afin qu'Autonomous AI Database puisse interroger les fichiers de données.
-
Les informations d'identification AWS sont prises en charge. Les informations d'identification AWS Amazon Resource Names (ARN) ne sont pas prises en charge.
Exemple : création d'un objet d'informations d'identification d'authentification native OCI
Dans cet exemple, nous créons des informations d'identification d'authentification native OCI qui peuvent être utilisées lors de la création d'un catalogue de données ou d'un objet d'informations d'identification de banque d'objets. Pour plus d'informations, reportez-vous à DBMS_DCAT. Procédure SET_DATA_CATALOG_CREDENTIAL et procédure DBMS_DCAT.SET_OBJECT_STORE_CREDENTIAL respectivement.
Dans l'authentification native OCI, la procédure DBMS_CLOUD.CREATE_CREDENTIAL inclut les paramètres suivants : credential_name, user_ocid, tenancy_ocid, private_key et fingerprint. Pour obtenir une description complète de cette procédure, reportez-vous à Procédure DBMS_CLOUD CREATE_CREDENTIAL.
credential_name est le nom de l'objet d'informations d'identification. Les paramètres user_ocid et tenancy_ocid correspondent respectivement aux OCID de l'utilisateur et de la location.
Le paramètre private_key indique la clé privée générée au format PEM. Les clés privées créées avec une phrase de données ne sont pas prises en charge. Par conséquent, nous devons nous assurer de générer une clé sans phrase de passe. Pour plus d'informations sur la création d'une clé privée sans phrase de passe, reportez-vous à la section How to Generate an API Signing Key. En outre, la clé privée que nous fournissons pour ce paramètre ne doit contenir que la clé elle-même sans en-tête ni pied de page (par exemple "—–BEGIN RSA PRIVATE KEY—–", "––END RSA PRIVATE KEY—–").
Le paramètre fingerprint indique l'empreinte obtenue après le téléchargement de la clé publique vers la console ou à l'aide des commandes OpenSSL. Pour plus d'informations sur l'obtention de l'empreinte, reportez-vous aux sections Téléchargement de la clé publique et Obtention de l'empreinte de la clé.
Une fois toutes les informations nécessaires collectées et la clé privée générée, nous sommes prêts à exécuter la procédure CREATE_CREDENTIAL suivante :
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL (
credential_name => 'OCI_NATIVE_CRED',
user_ocid => 'ocid1.user.oc1..aaaaaaaatfn77fe3fxux3o5lego7glqjejrzjsqsrs64f4jsjrhbsk5qzndq',
tenancy_ocid => 'ocid1.tenancy.oc1..aaaaaaaapwkfqz3upqklvmelbm3j77nn3y7uqmlsod75rea5zmtmbl574ve6a',
private_key => 'MIIEogIBAAKCAQEA...t9SH7Zx7a5iV7QZJS5WeFLMUEv+YbYAjnXK+dOnPQtkhOblQwCEY3Hsblj7Xz7o=',
fingerprint => '4f:0c:d6:b7:f2:43:3c:08:df:62:e3:b2:27:2e:3c:7a');
END;
/
Une fois l'objet d'informations d'identification créé, il apparaît dans la table dba_credentials :
SELECT owner, credential_name
FROM dba_credentials
WHERE credential_name LIKE '%NATIVE%';
OWNER CREDENTIAL_NAME
----- ---------------
ADMIN OCI_NATIVE_CRED
Exemple : utilisation d'ID utilisateur
Dans cet exemple, user1 est membre du groupe adb-admins. Tous les membres de ce groupe sont autorisés à gérer tous les catalogues de données dans mycompartment et à lire à partir de la banque d'objets dans mycompartment.
-
Autorisez les utilisateurs membres de
adb-adminsà gérer tous les catalogues de données dansmycompartment.allow group adb-admins to manage data-catalog-family in compartment mycompartment -
Autorisez les utilisateurs membres de
adb-adminsà lire tous les objets de n'importe quel bucket dansmycompartment.allow group adb-admins to read objects in compartment mycompartment