DBMS_DCAT-Package

Das Package DBMS_DCAT bietet Funktionen und Prozeduren, mit denen Benutzer der autonomen KI-Datenbank das Daten-Discovery- und zentralisierte Metadatenmanagementsystem von OCI Data Catalog nutzen können.

Hinweis: Die Unterstützung für DBMS_DCAT ist ab Version 19.30 in Oracle AI Database 19c und ab Version 23.26.1 in Autonomous AI Database 26ai verfügbar.

Data Catalog sammelt Metadaten aus den Objektspeicherassets eines Data Lakes. Beim Harvesting-Prozess werden logische Entitys erstellt, die als Tabellen mit Spalten und zugehörigen Datentypen betrachtet werden können. DBMS_DCAT-Prozeduren und -Funktionen verbinden die autonome KI-Datenbank mit dem Datenkatalog und synchronisieren die Assets dann mit der Datenbank. Dadurch werden geschützte Schemas und externe Tabellen erstellt. Anschließend können Sie den Objektspeicher mit diesen externen Tabellen abfragen und ganz einfach externe Daten mit in der autonomen KI-Datenbank gespeicherten Daten verknüpfen. Dies vereinfacht den Managementprozess erheblich. Es gibt einen einzigen, zentral verwalteten Metadatenspeicher, der über mehrere OCI-Services (einschließlich Autonomous AI Databases) hinweg gemeinsam genutzt wird. Es gibt auch Autonomous AI Database Dictionary-Views, mit denen Sie den Inhalt von Data Catalog mit SQL prüfen und zeigen können, wie diese Data Catalog-Entitys Ihren Schemas und Tabellen der autonomen KI-Datenbank zugeordnet werden.

Data Catalog-Benutzer und -Rollen

Das DBMS_DCAT-Package unterstützt synchronisierte Benutzer/Schemas, dcat_admin-Benutzer und lokale Benutzer. Benutzer müssen über die Rolle dcat_sync verfügen, um dieses Package verwenden zu können.

Data Catalog-Benutzer

Datenkatalogrollen

Erforderliche Zugangsdaten und IAM-Policys

In diesem Thema werden die Oracle Cloud Infrastructure Identity and Access Management-(IAM-)Benutzerzugangsdaten und -Policys beschrieben, die erforderlich sind, um Benutzern der autonomen KI-Datenbank die Berechtigung zum Verwalten eines Datenkatalogs und zum Lesen aus dem Objektspeicher zu erteilen.

OCI Data Catalog-Zugangsdaten und -Policy-Anforderungen:

Zugangsdaten und Richtlinienanforderungen für AWS Glue Data Catalog

Die folgenden Benutzerzugangsdaten und Policys sind erforderlich, um Benutzern der autonomen KI-Datenbank die Berechtigung zum Zugriff auf Amazon Web Services (AWS) Glue Data Catalogs und zum Lesen aus dem S3-Objektspeicher zu erteilen:

Beispiel: OCI-natives Authentifizierungszugangsdatenobjekt erstellen

In diesem Beispiel erstellen wir native OCI-Authentifizierungszugangsdaten, die beim Erstellen eines Datenkatalogs oder eines Objektspeicher-Zugangsdatenobjekts verwendet werden können. Weitere Informationen finden Sie unter DBMS_DCAT. Prozedur SET_DATA_CATALOG_CREDENTIAL und Prozedur DBMS_DCAT.SET_OBJECT_STORE_CREDENTIAL.

Bei der nativen OCI-Authentifizierung enthält die Prozedur DBMS_CLOUD.CREATE_CREDENTIAL die folgenden Parameter: credential_name, user_ocid, tenancy_ocid, private_key und fingerprint. Eine vollständige Beschreibung dieser Prozedur finden Sie unter DBMS_CLOUD CREATE_CREDENTIAL Procedure.

credential_name ist der Name des Zugangsdatenobjekts. Die Parameter user_ocid und tenancy_ocid entsprechen den OCIDs des Benutzers bzw. Mandanten.

Der Parameter private_key gibt den generierten Private Key im PEM-Format an. Private Keys, die mit einer Passphrase erstellt wurden, werden nicht unterstützt. Daher müssen wir sicherstellen, dass wir einen Schlüssel ohne Passphrase generieren. Weitere Informationen zum Erstellen eines Private Keys ohne Passphrase finden Sie unter How to Generate an API Signing Key. Außerdem darf der PRIVATE KEY, den wir für diesen Parameter bereitstellen, nur den Schlüssel selbst ohne Header oder Footer enthalten (z.B. '—––BEGIN RSA PRIVATE KEY—', '––END RSA PRIVATE KEY—').

Der Parameter fingerprint gibt den Fingerprint an, der entweder nach dem Hochladen des Public Keys in die Konsole oder mit den OpenSSL-Befehlen abgerufen wird. Weitere Informationen zum Abrufen des Fingerprints finden Sie unter So laden Sie den Public Key hoch und So rufen Sie den Fingerprint des Schlüssels ab.

Nachdem alle erforderlichen Informationen erfasst und der Private Key generiert wurde, können Sie die folgende CREATE_CREDENTIAL-Prozedur ausführen:

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;
/

Nachdem Sie das Zugangsdatenobjekt erstellt haben, wird es in der Tabelle dba_credentials angezeigt:

SELECT owner, credential_name
FROM dba_credentials
WHERE credential_name LIKE '%NATIVE%';
OWNER CREDENTIAL_NAME
----- ---------------
ADMIN OCI_NATIVE_CRED

Beispiel: Verwenden von Benutzer-Principals

In diesem Beispiel ist user1 ein Mitglied der Gruppe adb-admins. Alle Mitglieder dieser Gruppe erhalten die Berechtigung, alle Datenkataloge in mycompartment zu verwalten und aus dem Objektspeicher in mycompartment zu lesen.

  1. Ermöglichen Sie Benutzern, die Mitglieder von adb-admins sind, die Verwaltung aller Datenkataloge in mycompartment.

     allow group adb-admins to manage data-catalog-family in compartment mycompartment

  2. Ermöglichen Sie Benutzern, die Mitglieder von adb-admins sind, das Lesen aller Objekte in einem beliebigen Bucket in mycompartment.

     allow group adb-admins to read objects in compartment mycompartment