Sobre o Aplicativo

O conteúdo do script nesta página é para navegação apenas e não altera o conteúdo de nenhuma forma.

O aplicativo tem a seguinte finalidade, estrutura e convenções de nomenclatura.

Finalidade da Aplicação

O aplicativo é destinado a dois tipos de usuários em uma empresa.

• Usuários típicos (gerentes de funcionários)

• Administradores do aplicativo

Os usuários comuns podem executar as seguintes tarefas:

• Obter os funcionários em um determinado departamento

• Obter o histórico de cargos de um determinado funcionário

• Mostrar informações gerais de um determinado funcionário (nome, departamento, cargo, gerente, salário etc.)

• Alterar o salário de um determinado funcionário

• Alterar o cargo de um determinado funcionário

Os administradores de aplicativos podem executar as seguintes tarefas:

• Alterar o ID, o título ou a faixa salarial de um cargo existente

• Adicionar um novo job

• Alterar o ID, o nome ou o gerente de um departamento existente

• Adicionar um novo departamento

Estrutura do aplicativo

O aplicativo usa os seguintes objetos de esquema e esquemas.

Objetos de Esquema do Aplicativo

O aplicativo é composto pelos seguintes objetos de esquema:

• Quatro tabelas, que armazenam dados sobre os seguintes itens:

  • Jobs

  • Departamentos

  • Funcionários

  • Histórico de cargos de funcionários

• Quatro views de edição, que cobrem as tabelas, permitindo que você use a redefinição baseada em edição (EBR) para atualizar o aplicativo finalizado quando ele estiver em uso

• Dois triggers, que impõem regras de negócios

• Duas sequências que geram chaves primárias exclusivas para novos departamentos e novos funcionários

• Dois pacotes.

  • employees_pkg, a API (Application Program Interface) para usuários comuns

  • admin_pkg, a API para administradores de aplicativos

  Os usuários e administradores de aplicativos típicos acessam o aplicativo apenas por meio de suas APIs. Portanto, eles só podem alterar os dados chamando subprogramas de pacote.

Consulte também:

• "Sobre o Oracle AI Database" para obter informações sobre objetos de esquema

• Guia de Desenvolvimento do Oracle AI Database para obter informações sobre o EBR

Esquemas do Aplicativo

Por motivos de segurança, o aplicativo usa os cinco esquemas (ou usuários) a seguir, cada um com somente os privilégios necessários.

• O esquema app_data, que possui todos os objetos de esquema, exceto os pacotes, e carrega suas tabelas com dados de tabelas no esquema de amostra hr.

  Os desenvolvedores que criam os pacotes nunca funcionam neste esquema. Portanto, eles não podem alterar ou eliminar acidentalmente objetos de esquema do aplicativo.

• O esquema app_code, que possui apenas o pacote employees_pkg.

  Os desenvolvedores do pacote employees_pkg trabalham neste esquema.

• O esquema app_admin, que possui apenas o pacote admin_pkg.

  Os desenvolvedores do pacote admin_pkg trabalham neste esquema.

• O usuário app_user, o usuário típico do aplicativo, que não possui nada e só pode executar o pacote employees_pkg.

  O servidor de aplicativos de camada intermediária se conecta ao banco de dados no pool de conexões como usuário app_user. Se esse esquema for comprometido — por um bug de injeção de SQL, por exemplo — o invasor poderá ver e alterar apenas o que os subprogramas do pacote employees_pkg permitem que ele veja e altere. O invasor não pode eliminar tabelas, escalar privilégios, criar ou alterar objetos de esquema ou qualquer outra coisa.

• O usuário app_admin_user, um administrador de aplicativo, que não possui nada e só pode executar os pacotes admin_pkg e employees_pkg.

  O pool de conexões deste esquema é muito pequeno e somente usuários privilegiados podem acessá-lo. Se esse esquema for comprometido, o invasor poderá ver e alterar apenas o que os subprogramas do pacote admin_pkg e employees_pkg permitem que ele veja e altere.

Suponha que, em vez dos usuários app_user e app_admin_user, a aplicação tivesse apenas um esquema que não possuísse nada e pudesse executar os pacotes employees_pkg e admin_pkg. O pool de conexões desse esquema teria que ser grande o suficiente para os usuários típicos e para os administradores de aplicativos. Se houvesse um bug de injeção de SQL no pacote employees_pkg, um usuário típico que explorasse esse bug poderia acessar o pacote admin_pkg.

Suponha que, em vez dos esquemas app_data, app_code e app_admin, o aplicativo tivesse apenas um esquema que possuísse todos os objetos de esquema, incluindo os pacotes. Os pacotes teriam todos os privilégios nas tabelas, o que seria desnecessário e indesejável.

Por exemplo, suponha que você tenha uma tabela de trilha de auditoria, AUDIT_TRAIL. Você deseja que os desenvolvedores do pacote employees_pkg possam gravar na tabela AUDIT_TRAIL, mas não a leiam ou alterem. Você deseja que os desenvolvedores do pacote admin_pkg possam ler a tabela AUDIT_TRAIL e gravá-la, mas não alterá-la. Se a tabela AUDIT_TRAIL e os pacotes employees_pkg e admin_pkg pertencerem ao mesmo esquema, os desenvolvedores dos dois pacotes terão todos os privilégios na tabela AUDIT_TRAIL. No entanto, se a tabela AUDIT_TRAIL pertencer ao esquema app_data, o pacote employees_pkg pertencer ao esquema app_code e o pacote admin_pkg pertencer ao esquema app_admin, você poderá se conectar ao banco de dados como o esquema app_data e executar os seguintes comandos:

GRANT INSERT ON AUDIT_TRAIL TO app_code;
GRANT INSERT, SELECT ON AUDIT_TRAIL TO app_admin;

Consulte também:

• Sobre o Oracle AI Database para obter informações sobre esquemas
• Sobre o Esquema de Amostra HR para obter informações sobre o esquema de amostra HR
• Práticas de Segurança Recomendadas

Convenções de Nomenclatura no Aplicativo

O aplicativo usa essas convenções de nomenclatura.

Item	Nome
Tabela	nº da tabela
Exibição de edição para table#	tabela
Disparar na tabela de exibição de edição	table_{a|b}event[_fer] em que: a identifica um gatilho APÓS. b identifica um gatilho ANTES. fer identifica um acionador FOR EACH ROW. event identifica o evento que aciona o trigger. Por exemplo: i para INSERT, iu para INSERT ou UPDATE, d para DELETE.
Constraint PRIMARY KEY em table#	table_pk
Constraint NOT NULL em table#.coluna	coluna_tabela_não_nula1
Restrição EXCLUSIVA em table#.coluna	coluna_tabela_exclusiva1
Constraint CHECK em table#.column	coluna_tabela_verificação1
Restrição REF em table1#.coluna em table2#.coluna	tabela1_to_tabela2_fk1
Restrição REF em table1#.column1 para table2#.column2	table1_col1paratable2_col2_fk1 2
Sequência para Nº da tabela	sequência_tabela
Nome do parâmetro	p_nome
Nome da variável local	nome

1. table, table1 e table2 são abreviadas para emp for employees, dept for departments, e job_hist for job_history. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. col1 e col2 são abreviações de nomes de colunas column1 e column2. O nome de uma restrição não pode ter mais de 30 caracteres. ↩