Criar Tabelas Federadas usando Hiperlinks de Tabela Definindo Escopo

Um escopo de criação em um banco de dados do provedor determina quais instâncias do Autonomous AI Database do consumidor têm permissão para criar remotamente Hiperlinks de Tabela no banco de dados do provedor.

Você pode gerenciar escopos de criação usando o pacote DBMS_DATA_ACCESS_SCOPE, que fornece procedimentos para registrar, cancelar o registro, atualizar e recuperar escopos. Consulte DBMS_DATA_ACCESS_SCOPE para obter mais informações.

O ADMIN (ou PDB_DBA) no Autonomous AI Database do provedor usa o DBMS_DATA_ACCESS_ADMIN.GRANT_REGISTER para decidir quais usuários locais têm permissão para gerenciar escopos de criação.

Somente esses usuários privilegiados podem registrar, atualizar ou cancelar o registro de escopos, evitando a exposição não controlada das tabelas do provedor.

Exemplo

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

O exemplo acima concede ao usuário ANALYTICS_ADMIN permissão para registrar conjuntos de dados no escopo MY$COMPARTMENT.

Consulte GRANT_REGISTER para obter referência de sintaxe.

Um provedor chama o DBMS_DATA_ACCESS_SCOPE.REGISTER_CREATION_SCOPE para registrar o escopo permitido para tabelas específicas ou esquemas inteiros para criar Hiperlinks de Tabela nesses objetos.

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

Este exemplo registra um escopo de acesso a dados no nível do esquema para o esquema ANALYTICS, associando-o ao compartimento MY$COMPARTMENT.

Exemplo: Registrar Escopo no Nível do Objeto

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

Este exemplo registra um escopo de acesso a dados mais direcionado para um objeto específico SALES_DATA no esquema ANALYTICS, vinculando-o à tenancy MY$TENANCY. Ao contrário da versão no nível do esquema, o schema_object_name limita a aplicação a apenas esta tabela, ativando o controle granular sobre as permissões de criação.

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

Este procedimento associa os objetos de esquema listados—SALES_DATA, CUSTOMER_DATA e PRODUCT_DATA ao escopo MY$COMPARTMENT, restringindo sua criação ou acesso a entidades dentro desse compartimento.

Consulte Escopo de Criação do Registro para obter referência de sintaxe.

Se um provedor precisar alterar o acesso, o mesmo usuário autorizado ou outro chamará UPDATE_CREATION_SCOPE para ampliar, restringir ou ajustar quais Autonomous AI Databases do consumidor podem criar hiperlinks para objetos de esquema específicos.

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

Este exemplo atualiza o escopo de criação da tabela SALES_DATA no esquema ANALYTICS para MY$COMPARTMENT.

Consulte Atualizar Escopo de Criação para obter referência de sintaxe.

Quando um provedor deseja revogar totalmente o recurso de criação remota (para uma tabela, lista de tabelas ou um esquema), o provedor chama UNREGISTER_CREATION_SCOPE. Isso remove o escopo registrado e impede que novos Hiperlinks de Tabela sejam criados para esses objetos pelos bancos de dados do consumidor.

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

Este bloco de exemplo remove um escopo de criação registrado anteriormente para SALES_DATA no esquema ANALYTICS, de modo que novos objetos criados sob esse escopo não sejam mais controlados pelo acesso a dados que controla o escopo imposto.

Consulte Cancelar Registro do Escopo de Criação para obter referência de sintaxe.

A qualquer momento, um usuário autorizado pode chamar LIST_CREATION_SCOPES para recuperar as definições de escopo atuais.

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

Consulte Recuperar Escopo de Criação para obter referência de sintaxe.

No Autonomous AI Database do consumidor, o ADMIN (ou PDB_DBA) usa o DBMS_DATA_ACCESS_ADMIN.GRANT_READ para conceder a usuários específicos o direito de criar tabelas federadas em esquemas ou objetos do provedor remoto.

Exemplo: Conceder Acesso a Objeto Remoto Específico

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

Este exemplo concede ao usuário BI_ANALYST acesso de leitura ao objeto SALES_DATA remoto específico no esquema ANALYTICS de um provedor de dados externo.

Consulte Conceder Leitura para obter referência de sintaxe.

O procedimento REVOKE_READ remove o privilégio de um usuário para criar tabelas federadas em um esquema remoto especificado ou objeto de esquema no banco de dados do provedor.

Se você omitir o nome do objeto remoto, ele revogará o acesso à tabela federada desse usuário para todos os objetos no esquema remoto fornecido.

Exemplo

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

Consulte Revogar Leitura para obter referência de sintaxe.

Um usuário consumidor que recebeu privilégios de leitura chama DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE para criar uma tabela federada sobre a tabela ou view no escopo do provedor.

O procedimento usa OCIDs de banco de dados e informações de região para estabelecer Hiperlinks de Tabela para que o consumidor possa consultar dados remotos como se fossem uma tabela externa local.

Pré-requisitos

• O usuário deve receber privilégios de leitura através do procedimento GRANT_READ.
• O usuário deve existir nos bancos de dados do consumidor e do provedor com os privilégios necessários.
• O banco de dados do consumidor deve pertencer ao escopo de criação do provedor.
• O provedor deve ter o escopo de criação registrado para objetos de destino.
• Conectividade de rede estabelecida entre bancos de dados de consumidores e provedores.

Exemplo: Provedor Único

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

No exemplo acima, um consumidor chama DBMS_DATA_ACCESS.CREATE_FEDERATED_TABLE para criar uma tabela federada local que se vincula à tabela ou view de um provedor remoto (por exemplo, SALES_DATA no esquema ANALYTICS), usando JSON db_ocids para especificar o banco de dados do provedor OCIDs e as regiões para consulta perfeita como se fossem locais.

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;

Consulte Criar Tabela Federada para obter referência de sintaxe.

Quando o acesso federado não é mais necessário, o usuário consumidor chama o DBMS_DATA_ACCESS.DROP_FEDERATED_TABLE para remover a tabela federada.

Este procedimento limpa o objeto do lado do consumidor e efetivamente encerra esse caminho de acesso federado específico, enquanto os escopos e privilégios do provedor subjacente permanecem sob controle do provedor.

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

O exemplo acima elimina a tabela SALES_FED.

Consulte Eliminar Tabela Federada para obter referência de sintaxe.