En esta ocasión hablaremos de cómo crear tablas y adicionar las columnas necesarias.
Uso del Optimizador Cost-Based de Oracle
Oracle E-Business Suite utiliza la Optimización Base-Costo (CBO) en lugar de la de optimización basada en reglas (RBO) utilizada en versiones anteriores. Todo nuevo código debe ser escrito para tomar ventaja de la optimización.
Seguimiento de los cambios con registros históricos (OMS)
La función Historial Record (OMS) reporta información sobre quién creó o actualizo filas en las tablas de Oracle E-Business Suite.
Si agrega columnas especiales de la OMS a las tablas y la lógica de la OMS a los formularios y procedimientos almacenados, los usuarios pueden realizar un seguimiento de los cambios realizados en sus datos. Al observar columnas de la OMS, los usuarios pueden diferenciar entre los cambios realizados por las formas y los cambios realizados por los programas concurrentes.
Usted puede representar cada una de las columnas de OMS como campos ocultos en cada bloque de sus formularios (que corresponden a las columnas de la OMS en cada tabla subyacente). Estos campos son llenados invocando a FND_STANDARD.SET_WHO en los eventos PRE-UPDATE y PRE-INSERT.
Cómo añadir columnas Histórico de Registro
La siguiente tabla muestra las columnas estándar utilizados para Historial (OMS), los atributos de la columna y descripciones, las fuentes de los valores de esas columnas. Establezca las columnas CREATED_BY y CREATION_DATE sólo cuando se inserta una fila (utilizando FND_STANDARD.SET_WHO de un formulario).
| Nombre de Columna | Tipo | Null? | Foreign Key? | Descripcion | Valor |
| CREATED_BY | NUMBER(15) | NOT NULL | FND_ USER | Usuario que creo el registro | TO_NUMBER (FND_ PROFILE. VALUE ('USER_ID')) |
| CREATION_ DATE | DATE | NOT NULL | Fecha de creación de la fila | SYSDATE | |
| LAST_ UPDATED_BY | NUMBER(15) | NOT NULL | FND_ USER | Usuario que actualizo el registro | TO_NUMBER (FND_ PROFILE. VALUE ('USER_ID')) |
| LAST_UPDATE_ DATE | DATE | NOT NULL | Fecha de la Ultima actualización | SYSDATE | |
| LAST_UPDATE_ LOGIN | NUMBER(15) | FND_ LOGINS | Proporciona acceso a la información sobre el sistema operativo de inicio de sesión del usuario que la última actualización de cada fila | TO_NUMBER (FND_ PROFILE. VALUE ('LOGIN_ ID')) |
Cualquier tabla que pueda ser actualizada por un programa concurrente también necesita columnas adicionales. La siguiente tabla muestra las columnas, los atributos de columna, descripciones, y las fuentes de los valores de esas columnas.
| Nombre de Comuna | Tipo | Null? | Foreign Key to Table? | Descripción |
| REQUEST_ID | NUMBER(15) | FND_ CONCURRENT_ REQUESTS | ID del concurrente con el cual el registro fue credo o actualizado | |
| PROGRAM_ APPLICATION_ ID | NUMBER(15) | FND_ CONCURRENT_ PROGRAMS | Id de programa con el cual el registro fue cread o actualizado | |
| PROGRAM_ID | NUMBER(15) | FND_ CONCURRENT_ PROGRAMS | Id de programa con el cual el registro fue cread o actualizado | |
| PROGRAM_ UPDATE_DATE | DATE | PROGRAM_ UPDATE_ DATE | Fecha de creación o actualización |
Utilizar controladores de eventos con el Código de Registro de Historial en los formularios
Algunas operaciones que se deben realizar en el momento de realizar el commit no parecen estar diseñadas para un manejador de tabla. Por ejemplo, los controladores de eventos son preferibles a los manejadores de tablas para establecer información histórica de un registro, o la determinación de un número secuencial. La lógica de estas operaciones se puede almacenar en un PRE_INSERT y / o controlador de eventos PRE_UPDATE, PRE-INSERT y PRE_UPDATE son llamados a nivel de bloque cuando se disparan las inserciones o actualizaciones.
Clases de propiedad para los campos de la OMS
Aplicar la clase de propiedad CREATION_OR_LAST_UPDATE_DATE al campo CREATION_DATE en el formulario y LAST_UPDATE_DATE respectivamente. Estas clases de propiedad establecen los atributos correctos para estos campos, incluyendo el tipo de datos y el
ancho.
Tablas sin Información Histórica
Para los bloques que están basados en una tabla que no tienen columnas de información Historia, se debe deshabilitar el menú> ABOUT_THIS_RECORD (todos los demás casos se tratan mediante el control de menú por defecto), para ello se debe colcar en el evento WHEN-NEW-BLOQUE-INSTANCIA a nivel de bloque las siguientes líneas:
app_standard.event('WHEN-NEW-BLOCK-INSTANCE');
app_special.enable('ABOUT', PROPERTY_OFF);
Declaración de Restricciones en Oracle
En esta sección trataremos sobre las restricciones y permisos de base de datos y cuando utilizar cada función con las tablas personalizadas dentro de Oracle E-Business Suite.
Cualquier restricción que se asocia con una tabla debe ser duplicada en un formulario para que el usuario recibe retroalimentación inmediata si la restricción es viola.
Advertencia: No debe crear restricciones adicionales sobre las tablas de Oracle E-Business Suite, ya que puede afectar negativamente en las actualizaciones de Oracle E-Business Suite. Si crea limitaciones adicionales, es posible que necesite desactivarlas antes de actualizar Oracle E-Business Suite.
NOT NULL
Utilice siempre que sea apropiado. Declarar los campos correspondientes dentro de las formas de Oracle como "Requerido" = True.
DEFAULT
En general, no use esta función debido a problemas de bloqueo potenciales con Oracle Forms. Es posible que pueda utilizar esta función con las tablas que no son utilizados por las formas (por ejemplo, los utilizados por programas por lotes).
UNIQUE
La restricción "unique" impide la duplicación de claves alternas (no primarias), es decir, especifica que dos registros no puedan tener el mismo valor en un campo. Se permiten valores nulos.
Se pueden aplicar varias restricciones de este tipo a una misma tabla, y pueden aplicarse a uno o varios campos que no sean clave primaria.
Se emplea cuando ya se estableció una clave primaria (como un número de legajo) pero se necesita asegurar que otros datos también sean únicos y no se repitan (como número de documento).
La sintaxis general es la siguiente:
alter table NOMBRETABLA
add constraint NOMBRERESTRICCION
unique (CAMPO);
CHEQUE
La restricción "check" especifica los valores que acepta un campo, evitando que se ingresen valores inapropiados.
La sintaxis básica es la siguiente:
alter table NOMBRETABLA
add constraint NOMBRECONSTRAINT
check CONDICION;
Esto no suele ser un problema, ya que los factores desencadenantes de bases de datos Oracle E-Business Suite raramente deben ser desactivados. Algunos factores desencadenantes (como eventos de alerta) se desactivan antes de una actualización y re-activados al final de la actualización.
Se desaconseja el uso de triggers de base de datos.
PRIMARY KEY
Definir una clave principal para todas las tablas.
Cascade Delete and Foreign Key Constraint
No utilice el declarativa Cascade Delete or the Foreign Key Constraint en la definición de las tablas. Eliminar en cascada no funciona a través de bases de datos distribuidas, por lo que debe programar la lógica de eliminación en cascada.
Para llevar a cabo una verificación de la integridad referencial, cree un / SQL procedimiento almacenado PL que cuyo argumento sea la clave primaria y que lance una excepción si la supresión de la fila podría causar un error de integridad referencial.
LONG, LONG RAW y RAW Datatypes
No utilice estos tipos de datos en su lugar utilice : VARCHAR2(2000) en la declaración de las columnas
Uso de palabras Reservas en Columnas
Si una tabla contiene como nombre de columna una palabra reservada de PL/SQL o de Oracle Forms, se deberá crear una vista sobre esta tabla en la cual se pondrá un alias a estas columnas.
Views
En general, los bloques complejos se basan en las Vistas mientras que los bloques de configuración simples se basan en tablas. Las ventajas de utilizar vistas son:
- El tráfico de red se reduce al mínimo, porque todas las claves externas se des normalizan en el servidor
- No es necesario codificar ninguna lógica en POST-QUERY para rellenar los campos que no son de Base de datos
- No es necesario codificar ninguna lógica en PRE-QUERY para implementar consulta por ejemplo para los campos que no son de base de datos
Definir vistas para mejorar el rendimiento
Siempre que el rendimiento es un problema y su Tabla tiene las claves externas, debe definir una Vista con el objetivo de mejorar el rendimiento. Las vistas permiten una única sentencia SQL procesar las claves externas, reduciendo análisis sintácticos por el servidor, y reduciendo el tráfico de red.
Definir vistas para Impulsa la modularidad
Cualquier objeto disponible en la base de datos promueve la modularidad y reutilización, porque todo código del lado del cliente o del servidor puede acceder a él.
Las vistas son muy deseables porque:
- Aceleran el desarrollo, ya que los desarrolladores pueden construir en ella lógica encapsulada
- Ellas modula rizan código, a menudo lo que significa que una corrección o mejora pueden realizarse en una sola ubicación
- Reducen el tráfico de red
- A menudo son útiles para la presentación de informes u otras actividades
- Pueden ser parcheado con facilidad y de forma centralizada en un sitio de cliente
Si la vista contiene una sola sentencia SQL NO se debería crear una vista.
Si la vista será utilizada por un solo procedimiento almacenado NO se debería crear, ya que esto aumenta la carga de mantenimiento debido a que tanto el código que contiene la sentencia de SQL y la vista debe ser mantenida.
ROW_ID primera columna
La primera columna de la vista debe ser la pseudo-columna ROWID de la tabla raíz, y la vista debe crear un alias a ROW_ID. Su vista, entonces debe incluir todas las columnas de la tabla raíz, incluyendo las columnas de la OMS, y debe des normalizar la información de las claves externas.
Consejo: Sólo tiene que incluir la columna ROWID si la vista es utilizada en un bloque de Oracle Forms. El campo de Oracle Forms correspondiente a la pseudo-columna ROW_ID debe utilizar la clase de propiedad ROW_ID.
Cambiar el Modo Clave (Block Key Mode)
En Oracle Forms, es necesario cambiar la propiedad Modo Clave (Block Key Mode) a "No Actualizable (Non-Updatable)" que no pueden actualizarse y asi de esta forma Fomrs no hara referencia por defecto a ROWID para bloques basados en vista. Especifique a nivel de ITEM la propiedad Clave Primaria (Primary Key) en True.
Por ejemplo, un punto de vista basado en la tabla EMP tiene las columnas row_id, EMPNO, Ename, deptno y DNAME. Establezca la propiedad Tecla de modo de bloque EMP_V a que no pueden actualizarse, y establezca la propiedad de clave principal de EMPNO en True.
Si el bloque se basa en una tabla, el Modo Clave (Block Key Mode) debe ser único.
Código desencadenantes de Inserción, Actualización, eliminación y bloqueo
Si el bloque se basa en una vista, se debe codificar los eventos ON-INSERT, ON-UPDATE ON-DELETE y ON-LOCK para insertar, actualizar, eliminar y bloquear la tabla raíz en lugar de la vista.
Vistas de una sola Tabla
Las Vistas individuales de una sola Tabla no necesitas los factores desencadenantes de inserción, actualización, supresión y bloqueo. El ajuste Modo Clave debe estar en "Unico". Las vistas de una sola tabla no requieren una columna ROW_ID.
Caracteres especiales
No utilice la función CHR () (se utiliza para definir un carácter por su número ASCII) en el lado del servidor. Esto causa problemas con las plataformas de servidor que utilizan EBCDIC, como MVS.
Secuencias
En esta sección trataremos sobre las normas para la creación y el uso de secuencias.
Crear Secuencias de Uso Individual
Use cada secuencia para suministrar valores de identificación únicos para una columna de una tabla.
No limite el alcance de su Secuencias
No debe crear secuencias que se envuelven con la opción CICLO o que tienen un MAXVALUE especificado. El rango total de la secuencia es tan grande que los límites superiores realista nunca se encuentran.
En general, no diseñar secuencias que se envuelven o tengan rangos limitados.
Tipo de Datos Para Almacenar Secuencias
Utilice un tipo de datos NUMBER para almacenar valores de secuencia dentro de PL / SQL.
No utilice la Tabla FND_UNIQUE_IDENTIFIER_CONTROL
No confíe en la tabla FND_UNIQUE_IDENTIFIER_CONTROL para suministrar valores secuenciales. Utilice una secuencia o en su lugar el paquete de numeración secuencial. La tabla FND_UNIQUE_IDENTIFIER_CONTROL es obsoleta y no debe tener ninguna fila para los objetos de su producto.
Además, no cree versiones específicas de la aplicación de la tabla FND para reemplazar la tabla FND_UNIQUE_IDENTIFIER_CONTROL.
API para el Registro de Tablas
Usted puede registrar sus tablas de aplicaciones personalizadas mediante una rutina de PL / SQL utilizando el paquete AD_DD.
Flexfields y Alerta Oracle son las únicas características o productos que dependen de esta información. Por lo tanto, sólo es necesario registrar esas tablas (y todas sus columnas) que se utilizarán con flexfields o Alerta Oracle.
También puede utilizar la API AD_DD para eliminar el registro de la tablas y columnas de Oracle Application Object Library , en caso de que más tarde tenga que modificar las tablas.
Si altera la tabla más adelante, entonces tiene que modificar el registro de la tabla dentro del EBS. Para modificar un registro primero debe eliminar el registro, a continuación volver a registrar la tabla o columna. Primero de debe eliminar el registro columna, luego el registro de la tabla.
Debe incluir las llamadas a las rutinas de registro de tabla en una secuencia de comandos PL / SQL. Aunque creamos nuestras tablas en nuestro propio esquema de aplicación, debemos ejecutar los procedimientos AD_DD contra el esquema APPS. Se debe confirmar los cambios para que tomen efecto.
El API AD_DD no comprueba la existencia de la tabla registrada o columna en el esquema de base de datos, pero sólo actualiza las tablas de AOL requeridos. Debe asegurarse de que existen las tablas y columnas registradas en realidad y tienen el mismo formato que el definido mediante la API AD_DD.
Procedimientos en el paquete AD_DD
procedure register_table (
p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_tab_type in varchar2,
p_next_extent in number default 512,
p_pct_free in number default 10,
p_pct_used in number default 70);
procedure register_column(
p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2,
p_col_seq in number,
p_col_type in varchar2,
p_col_width in number,
p_nullable in varchar2,
p_translate in varchar2,
p_precision in number default null,
p_scale in number default null);
procedure register_primary_key(
p_appl_short_name in varchar2,
p_key_name in varchar2,
p_tab_name in varchar2,
p_description in varchar2,
p_key_type in varchar2,
p_audit_flag in varchar2,
p_enabled_flag in varchar2);
procedure update_primary_key(
p_appl_short_name in varchar2,
p_key_name in varchar2,
p_tab_name in varchar2,
p_description in varchar2 default null,
p_key_type in varchar2 default null,
p_audit_flag in varchar2 default null,
p_enabled_flag in varchar2 default null);
procedure register_primary_key_column(
p_appl_short_name in varchar2,
p_key_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2,
p_col_sequence in number);
procedure delete_primary_key_column(
p_appl_short_name in varchar2,
p_key_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2 default null);
procedure delete_table(
p_appl_short_name in varchar2,
p_tab_name in varchar2);
procedure delete_column(
p_appl_short_name in varchar2,
p_tab_name in varchar2,
p_col_name in varchar2);
| Variable | Description |
| p_appl_short_ name | El nombre corto de la aplicación propietaria de la tabla(por lo general la aplicación personalizada). |
| p_tab_name | El nombre de la tabla (en letras mayúsculas). |
| p_tab_type | Use 'T' si es una tabla de transacciones (casi todas las tablas de aplicación), o 'S' para una tabla "datos semilla" (utilizado sólo por Oracle productos E-Business Suite). |
| p_pct_free | El porcentaje de espacio de cada uno de los elementos de la tabla, reservada para futuras actualizaciones de la tabla (1-99). La suma de p_pct_free y p_pct_used debe ser inferior a 100. |
| p_pct_used | Porcentaje mínimo de espacio utilizado en cada uno de los elementos de la tabla (1-99). La suma de p_pct_free y p_pct_used debe ser inferior a 100. |
| p_col_name | El nombre de la columna (en letras mayúsculas). |
| p_col_seq | El número de secuencia de la columna en la tabla (el orden en que la columna aparece en la definición de la tabla). |
| p_col_type | El tipo de columna ('NUMBER', 'VARCHAR2', 'DATE', etc.). |
| p_col_width | El tamaño de la columna (un número). Utilice 9 de columnas de tipo DATE, 38 para las columnas numéricas (a menos que tenga un ancho específico). |
| p_nullable | Utilice 'N' si la columna es obligatorio o 'Y' si la columna permite valores nulos. |
| p_translate | Use 'Y' si los valores de las columnas serán traducidos para un lanzamiento de productos de Oracle E-Business Suite (utilizado sólo por Oracle productos E-Business Suite) o 'N' si los valores no están traducidos (la mayoría de las columnas de la aplicación). |
| p_next_extent | El siguiente tamaño de extensión, en kilobytes. No incluya la 'K'. |
| p_precision | El número total de dígitos de un número. |
| p_scale | El número de dígitos a la derecha del punto decimal en un número. |
Ejemplo del uso del paquete AD_DD
He aquí un ejemplo de cómo utilizar el paquete AD_DD para registrar una Tabla flexfield y sus columnas:
--REGISTRAMOS LA TABLA
execute ad_dd.register_table('FND','CUST_FLEX_TEST','T',8,10,90);
--REGISTRAMOS SUS COLUMNAS
execute ad_dd.register_column('FND','CUST_FLEX_TEST','APPLICATION_ID',1,'NUMBER',38,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','ID_FLEX_CODE',2,'VARCHAR2',30,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','LAST_UPDATE_DATE',3,'DATE',9,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','LAST_UPDATED_BY',4,'NUMBER',38,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','UNIQUE_ID_COLUMN',5,'NUMBER',38,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','UNIQUE_ID_COLUMN2',6,'NUMBER',38,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','SET_DEFINING_COLUMN',7,'NUMBER',38,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','SUMMARY_FLAG',8,'VARCHAR2',1,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','ENABLED_FLAG',9,'VARCHAR2',1,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','ENABLED_FLAG',9,'VARCHAR2',1,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','START_DATE_ACTIVE',10,'DATE',9,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','END_DATE_ACTIVE',11,'DATE',9,'N','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT1',12,'VARCHAR2',60,'Y','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT2',13,'VARCHAR2',60,'Y','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT3',14,'VARCHAR2',60,'Y','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT4',15,'VARCHAR2',60,'Y','N');
execute ad_dd.register_column('FND','CUST_FLEX_TEST','SEGMENT5',16,'VARCHAR2',60,'Y','N');
Bueno amigos eso es todo, gracias.
No hay comentarios:
Publicar un comentario