Acerca de la aplicación

El contenido del script de esta página es sólo para fines de navegación y no modifica el contenido de ninguna forma.

La aplicación tiene la siguiente finalidad, estructura y convenciones de nomenclatura.

Finalidad de la aplicación

La aplicación está destinada a dos tipos de usuarios en una compañía.

• Usuarios típicos (mánager de empleados)

• administradores de la aplicación

Los usuarios habituales pueden realizar las siguientes tareas:

• Obtener empleados en un departamento determinado

• Obtener el historial de trabajos de un empleado determinado

• Mostrar información general de un empleado determinado (nombre, departamento, puesto, mánager, salario, etc.)

• Cambiar el salario de un empleado determinado

• Cambiar el trabajo de un empleado determinado

Los administradores de aplicaciones pueden realizar las siguientes tareas:

• Cambiar el ID, el cargo o el rango salarial de un puesto existente

• Agregar un nuevo trabajo

• Cambiar el ID, el nombre o el mánager de un departamento existente

• Agregar un nuevo departamento

Estructura de la aplicación

La aplicación utiliza los siguientes objetos y esquemas de esquema.

Objetos de Esquema de la Aplicación

La aplicación se compone de los siguientes objetos de esquema:

• Cuatro tablas, que almacenan datos sobre los siguientes elementos:

  • Trabajos

  • Departments

  • Empleados

  • Historial de puestos de empleados

• Cuatro vistas de edición, que abarcan las tablas, lo que permite utilizar la redefinición basada en edición (EBR) para actualizar la aplicación terminada cuando está en uso

• Dos disparadores, que aplican reglas de negocio

• Dos secuencias que generan claves primarias únicas para nuevos departamentos y empleados

• Dos paquetes.

  • employees_pkg, la interfaz de programa de aplicación (API) para usuarios típicos

  • admin_pkg, la API para administradores de aplicaciones

  Los usuarios y administradores de aplicaciones típicos acceden a la aplicación solo a través de sus API. Por lo tanto, solo pueden cambiar los datos llamando a subprogramas de paquetes.

Consulte además:

• "Acerca de Oracle AI Database" para obtener información sobre los objetos de esquema

• Guía de desarrollo de Oracle AI Database para obtener información sobre EBR

Esquemas para la aplicación

Por motivos de seguridad, la aplicación utiliza los siguientes cinco esquemas (o usuarios), cada uno de los cuales solo tiene los privilegios que necesita.

• Esquema app_data, que posee todos los objetos de esquema excepto los paquetes y carga sus tablas con datos de tablas en el esquema de ejemplo hr.

  Los desarrolladores que crean los paquetes nunca funcionan en este esquema. Por lo tanto, no pueden modificar ni borrar accidentalmente los objetos de esquema de la aplicación.

• Esquema app_code, que solo posee el paquete employees_pkg.

  Los desarrolladores del paquete employees_pkg funcionan en este esquema.

• Esquema app_admin, que solo posee el paquete admin_pkg.

  Los desarrolladores del paquete admin_pkg funcionan en este esquema.

• El usuario app_user, el usuario de aplicación típico, que no posee nada y solo puede ejecutar el paquete employees_pkg.

  El servidor de aplicaciones de capa media se conecta a la base de datos del pool de conexiones como usuario app_user. Si este esquema se ve comprometido, por ejemplo, por un bug de inyección SQL, el atacante solo puede ver y cambiar lo que los subprogramas del paquete employees_pkg le permiten ver y cambiar. El atacante no puede borrar tablas, escalar privilegios, crear o modificar objetos de esquema ni nada más.

• El usuario app_admin_user, un administrador de aplicaciones, que no posee nada y solo puede ejecutar los paquetes admin_pkg y employees_pkg.

  El pool de conexiones para este esquema es muy pequeño y solo pueden acceder a él los usuarios con privilegios. Si este esquema se ve comprometido, el atacante solo puede ver y cambiar lo que los subprogramas de paquete admin_pkg y employees_pkg le permiten ver y cambiar.

Supongamos que, en lugar de los usuarios app_user y app_admin_user, la aplicación solo tenía un esquema que no poseía nada y podía ejecutar tanto paquetes employees_pkg como admin_pkg. El pool de conexiones de este esquema tendría que ser lo suficientemente grande para los usuarios típicos y los administradores de la aplicación. Si hubiera un bug de inyección SQL en el paquete employees_pkg, un usuario típico que aprovechara ese bug podría acceder al paquete admin_pkg.

Supongamos que, en lugar de los esquemas app_data, app_code y app_admin, la aplicación solo tenía un esquema que era propietario de todos los objetos de esquema, incluidos los paquetes. Los paquetes tendrían entonces todos los privilegios en las tablas, lo que sería innecesario e indeseable.

Por ejemplo, supongamos que tiene una tabla de pista de auditoría, AUDIT_TRAIL. Desea que los desarrolladores del paquete employees_pkg puedan escribir en la tabla AUDIT_TRAIL, pero no leerla ni cambiarla. Desea que los desarrolladores del paquete admin_pkg puedan leer la tabla AUDIT_TRAIL y escribir en ella, pero no cambiarla. Si la tabla AUDIT_TRAIL y los paquetes employees_pkg y admin_pkg pertenecen al mismo esquema, los desarrolladores de los dos paquetes tienen todos los privilegios en la tabla AUDIT_TRAIL. Sin embargo, si la tabla AUDIT_TRAIL pertenece al esquema app_data, el paquete employees_pkg pertenece al esquema app_code y el paquete admin_pkg pertenece al esquema app_admin, puede conectarse a la base de datos como esquema app_data y ejecutar los siguientes comandos:

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

Consulte además:

• Acerca de Oracle AI Database para obtener información sobre los esquemas
• Acerca de HR de Esquema de Ejemplo para obtener información sobre el esquema de ejemplo HR
• Prácticas de seguridad recomendadas

Reglas de nomenclatura en la aplicación

La aplicación utiliza estas convenciones de nomenclatura.

Elemento	Nombre
Tabla	tabla#
Vista de edición para tabla#	tabla
Disparador en la vista de edición tabla	table_{a|b}evento[_fer] donde: a identifica un disparador AFTER. b identifica un disparador BEFORE. fer identifica un disparador FOR EACH ROW. event identifica el evento que dispara el disparador. Por ejemplo: i para INSERT, iu para INSERT o UPDATE, d para DELETE.
La restricción PRIMARY KEY en tabla#	tabla_pk
Restricción NOT NULL en tabla#.columna	table_column_not_null1
Restricción UNIQUE en table#.column	tabla_columna_única1
Restricción CHECK en table#.column	table_column_check1
Restricción de referencia en table1#.column a table2#.column	tabla1_to_tabla2_fk1
Restricción de referencia en table1#.column1 a table2#.column2	table1_col1atable2_col2_fk1 2
Secuencia para table#	tabla_secuencia
Nombre del parámetro	p_nombre
Nombre de variable local	l_nombre

1. tabla, tabla1 y tabla2 se abrevian para emp para empleados, departamento para departamentos e historial de trabajos para historial de trabajos. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. col1 y col2 son abreviaturas de los nombres de columna column1 y column2. Un nombre de restricción no puede tener más de 30 caracteres. ↩