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 concluir 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 concluir 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 destes objetos de esquema:

• Quatro tabelas que armazenam os seguintes dados:

  • 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 Database" para obter informações sobre objetos de esquema

• Oracle Database Development Guide 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.

• app_data 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 do esquema do aplicativo.

• app_code possui apenas o pacote employees_pkg

  Os desenvolvedores de employees_pkg trabalham neste esquema.

• app_admin possui apenas o pacote admin_pkg

  Os desenvolvedores de admin_pkg trabalham neste esquema.

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

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

• app_admin_user, um administrador de aplicativos, não possui nada e só pode executar admin_pkg e employees_pkg

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

Suponha que, em vez de app_user e app_admin_user, o aplicativo tivesse apenas um esquema que não possuísse nada e pudesse executar 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 em employees_pkg, um usuário típico que explorou esse bug poderia acessar admin_pkg.

Suponha que, em vez de 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, suponhamos que você tenha uma tabela de trilha de auditoria, AUDIT_TRAIL. Você quer que os desenvolvedores de employees_pkg possam escrever para AUDIT_TRAIL, mas não ler ou alterar. Você quer que os desenvolvedores de admin_pkg possam ler AUDIT_TRAIL e escrevê-lo, mas não alterá-lo. Se AUDIT_TRAIL, employees_pkg e admin_pkg pertencerem ao mesmo esquema, os desenvolvedores dos dois pacotes terão todos os privilégios em AUDIT_TRAIL. No entanto, se AUDIT_TRAIL pertencer a app_data, employees_pkg pertencer a app_code e admin_pkg pertencer a app_admin, você poderá se conectar ao banco de dados como app_data e fazer isso:

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

Consulte também:

• "Sobre o Oracle 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	table_column_not_null (Nota de rodapé 1)
Restrição EXCLUSIVA em table#.coluna	table_column_unique (Nota de Rodapé 1)
Constraint CHECK em table#.column	table_column_check (Nota de Rodapé 1)
Restrição REF em table1#.coluna em table2#.coluna	table1_to_table2_fk (Nota de Rodapé 1)
Restrição REF em table1#.column1 para table2#.column2	table1_col1paratable2_col2_fk (Nota de Rodapé 1) (Nota de Rodapé 2)
Sequência para o Nº da tabela	sequência_tabela
Nome do parâmetro	p_nome
Nome da variável local	nome

Rodapé 1: table, table1 e table2 são abreviadas para emp para funcionários, depto para departamentos e job_hist para job_history.

Nota de Rodapé 2: col1 e col2 são abreviações de nomes de coluna coluna1 e coluna2. O nome de uma restrição não pode ter mais de 30 caracteres.