Nombre Del Manual

Nombre del manual GUIA DE DISEÑO CON ERWIN 4.
GUIA DE DISEÑO CON ERWIN

1.4
Fecha Versión Cambios

01/09/2008 1.0 Versión Inicial
02/02/2009 1.1 Normativa para roles gis
13/03/2009 1.2 Normativa BO y Particionamiento
22/04/2009 1.3 Normativa Documentum
23/11/2009 1.4 Modificación normativa BO
Área de Integración y Arquitectura de Aplicaciones Página: 1

Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales
Subdirección General de Desarrollo, Tecnología e Infraestructuras
Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1
1 TABLA DE CONTENIDO
1 TABLA DE CONTENIDO............................................................................ 2
2 INTRODUCCIÓN ........................................................................................ 4
3 COMENTARIOS ......................................................................................... 5
4 NORMATIVA del NOMBRE DEL FICHERO ERWIN ................................. 5
5 INTEGRIDAD REFERENCIAL ................................................................... 5
6 ÁREAS DE DISEÑO ................................................................................... 5
6.1 <Main SubjectArea> .................................................................................... 5
6.2 <Área Principal o General del Esquema> .................................................. 6
6.3 <Área de Creación del esquema DBA_XXXX> .......................................... 6
6.4 <Área de Diseño Parcial 1>......................................................................... 6
6.5 Por cada Instancia de base de datos se incorporará un Área de Diseño 6
6.6 <Área de Trabajo> ....................................................................................... 6
7 FORMATO DE ENTREGA PARA CARGA MASIVA DE PLANTILLAS .... 6
8 ALTER SESSION ....................................................................................... 6
9 PERMISOS Y SINÓNIMOS DE OBJETOS DE BASE DE DATOS ............ 7
10 DEFINICIÓN DE SECUENCIADORES ................................................... 7
11 DEFINICIÓN DE COLUMNAS BLOB ..................................................... 9
12 DEFINICIÓN DE CARGAS DE DATOS ................................................ 10
12.1 Cargas de datos Iniciales......................................................................... 10
12.2 Cargas de Datos de Entorno .................................................................... 11
12.2.1 Generales .......................................................................................................... 11
12.2.2 Forms 4.5 .......................................................................................................... 11
12.2.3 Forms 10g ......................................................................................................... 12
12.2.4 Delphi y Java Intranet........................................................................................ 12
12.2.5 Internet .............................................................................................................. 12
13 DESBORDAMIENTO EN NOMBRES DE ÍNDICES, PK, FK y
TRIGGERS....................................................................................................... 12
14 DEFINICIÓN DE INDICES .................................................................... 13
14.1 Con integridad referencial basada en Triggers ó sin integridad
referencial.............................................................................................................. 13
14.2 Con integridad referencial basada en Primary Key y Foreign Key ........ 14
15 DEFINICIÓN DE INDICES INTERMEDIA TEXT ................................... 14
Con integridad referencial basada en Triggers ó sin integridad referencial .... 15

Con integridad referencial basada en Primary Key y Foreign Key.................... 15

16 THESAURUS DE INTERMEDIA TEXT ................................................. 16
17 DEFINICIÓN DE PAQUETES, PROCEDIMIENTOS Y FUNCIONES DE
BASE DE DATOS............................................................................................ 16
18 ROLES .................................................................................................. 18
19 JOBS..................................................................................................... 18
20 DEFINICIÓN DE INTEGRIDAD REFERENCIAL .................................. 20
20.1 Definición de Integridad Referencial Basada en Disparadores de Base
de Datos (Triggers). .............................................................................................. 20
20.2 Definición de Integridad Referencial Basada en Primary Key................ 21
21 DEFINICIÓN DE CHEQUEOS Y VALORES POR DEFECTO A NIVEL
DE COLUMNA ................................................................................................. 24
22 DEFINIR ACCIONES DE TRIGGER DE INTEGRIDAD REFERENCIAL
EN LAS RELACIONES ENTRE TABLAS ....................................................... 26
23 DEFINICIÓN DE SINÓNIMOS REMOTOS ........................................... 28
24 TRIGGERS............................................................................................ 29
25 TABLAS TEMPORALES (GLOBAL TEMPORARY TABLE) ............... 31
26 VISTAS.................................................................................................. 34
27 VISTAS MATERIALIZADAS................................................................. 35
27.1 Introducción............................................................................................... 35
27.2 Normativa ICM ........................................................................................... 35
27.2.1 Tipos de vistas y configuración refresco .......................................................... 35
27.2.2 Datos necesarios para la puesta en producción............................................... 36
27.3 Datos necesarios para mantenimiento .................................................... 37
27.4 Nomenclatura ............................................................................................ 37
27.4.1 Creación de vistas materializadas .................................................................... 37
27.4.2 Creación de logs de vistas materializadas........................................................ 37
28 PARTICIONES Y SUBPARTICIONES DE TABLAS ............................ 38
28.1 METODOS DE PARTICIONAMIENTO........................................................ 38
28.1.1 Particionamiento por RANGO ........................................................................... 38
28.1.2 Particionamiento por HASH .............................................................................. 38
28.1.3 Particionamiento por LISTA .............................................................................. 39
28.1.4 Particionamiento compuesto RANGO - HASH ................................................. 39
28.1.5 Particionamiento compuesto RANGO - LISTA ................................................. 40
28.2 Post-Script específico para tabla con particiones .................................. 41
29 APLICACIONES GIS ............................................................................ 42
29.1 Subáreas .................................................................................................... 42
29.2 Roles .......................................................................................................... 42
29.3 Post Scripts a nivel de Tabla específicos para GIS ................................ 43

30 APLICACIONES BUSINESS OBJECTS .............................................. 43

30.1 Subáreas .................................................................................................... 43
30.2 Roles .......................................................................................................... 43
30.3 Opciones de Generación específicas para B.O....................................... 44
30.4 Post Scripts a nivel de Tabla específicos para BO ................................. 44
31 APLICACIONES DOCUMENTUM ........................................................ 44
31.1 Subáreas .................................................................................................... 44
31.2 Sinónimos Remotos Privados .................................................................. 44
31.3 Secuencias ................................................................................................ 46
31.4 Triggers...................................................................................................... 48
31.5 Opciones de Generación Específicas para DOCUMENTUM................... 50
31.6 Post Scripts a nivel de Tabla específicos para DOCUMENTUM............. 50
32 OPCIONES DE GENERACIÓN DEL ESQUEMA DE DATOS.............. 51
32.1 Opciones de generación comunes a cualquier modelo ......................... 51
32.2 Opciones de generación específicas para Integridad Referencial
Basada en PK y FK ............................................................................................... 53
32.3 Opciones de generación específicas para Integridad Referencial
Basada en Triggers............................................................................................... 54
32.4 Opciones de Generación Específicas para Integridad Referencial No
Definida ................................................................................................................. 55
32.5 Opciones de Generación Específicas para B.O. ..................................... 56
32.6 Opciones de Generación Específicas para DOCUMENTUM................... 56
33 OBJETOS NO PERMITIDOS................................................................ 57
34 RECOMENDACIONES GENERALES DE DISEÑO DEL MODELO..... 58
2 INTRODUCCIÓN
El presente documento pretende orientar en la definición de objetos de

un modelo de datos creado con la herramienta ERwin 4.1 o superiores. Este
documento define las normas de ICM en el uso de la herramienta, así como
recomendaciones que puedan ser de interés.
Esta guía no pretende enseñar el manejo de la herramienta, sino orientar
su uso hacia los estándares definidos por ICM, en cuanto a los modelo de
datos diseñados con ERwin.
La versión actual de ERwin que maneja ICM es 4.1.4.3907

Debe consultarse también la documentación de ICM relativa a la

nomenclatura estándar de objetos de base de datos.
Debe consultarse el fichero erwin ejemplo

ICM_ERWIN_Ejemplo_V2.ER1
La realización del Modelo de datos Erwin se debe construir a partir

de la plantilla ICM_ERWIN_Plantilla_V2.ER1
3 COMENTARIOS
En los objetos que aparezcan en el modelo de datos se deben añadir
comentarios con la información necesaria
Por ejemplo, se deben añadir comentario a nivel de tabla, y a nivel de
campos de la tabla.
Los comentarios no se reflejarán a la hora de generar script de sql, de
hecho la Opción de Generación de Script Comments no debe estar
chequeada
En las tablas temporales (global temporary ) los comentarios se añadirán a

nivel de tabla. Ejemplo:
4 NORMATIVA del NOMBRE DEL FICHERO ERWIN
 Nomenclatura: XXXX-ERW-vv.rr-aaaammdd.er1
 XXXX: Nombre del proyecto
 vv.rr: Versión y revisión del proyecto (por ejemplo 1.0)
 aaaammdd: Fecha (por ejemplo 20092506).
5 INTEGRIDAD REFERENCIAL
Se recomienda la utilización de Primary key y Foreign key.
6 ÁREAS DE DISEÑO
Trabajaremos con un solo fichero erwin.
El fichero erwin podrá contener las siguientes Áreas de Diseño
6.1 <Main SubjectArea>

No se debe tocar. Éste área de diseño es exclusivo de erwin

6.2 <Área Principal o General del Esquema>

Área de Diseño Obligatoria. Aquí deben aparecer todos los objetos que
interviene del Proyecto.
6.3 <Área de Creación del esquema DBA_XXXX>

Área de Diseño Obligatoria. Área creada para aglutinar todas las tablas
propias del Esquema (No incorporar ninguna tabla catálogo o propiedad
de otro usuario DBA)
6.4 <Área de Diseño Parcial 1>

Podemos crearla para realizar agrupaciones de objetos.
Podemos crear tantas Áreas de Diseño Parcial como necesitemos:
- Área de Diseño Parcial 1
- Área de Diseño Parcial 2
- …….
- Área de Diseño Parcial (n)
6.5 Por cada Instancia de base de datos se incorporará un

Área de Diseño
Por ejemplo si nuestro proyecto incorpora objetos de b.d. Centralizada y

b.d. departamental , los objetos de la base de datos centralizada se
colocarían wn un área de diseño denominada:
‘DBA_XXXX CENTRALIZADA’
y los objetos de la base de datos departamental se ubicarían en un área
de diseño denonimada:
‘DBA_XXXX DEPARTAMENTAL’
6.6 <Área de Trabajo>

Éste área de diseño se utilizará para realizar pruebas.
No debe venir en la entrega.
7 FORMATO DE ENTREGA PARA CARGA MASIVA DE

PLANTILLAS
El formato de la entrega de plantillas(campos Blob) para carga masiva
en base de datos será un export por cada tabla afectada. Lógicamente
se debe tener en cuenta la versión de Oracle.
8 ALTER SESSION
En principio no se permiten, salvo autorización de ICM
En los siguientes casos si se permite:

 Alter Session para asignar un segmento de rollback a una

transacción
 Alter Session para ORDER BY
9 PERMISOS Y SINÓNIMOS DE OBJETOS DE BASE DE

DATOS
A los objetos de base de datos creados en ICM se les asocian unos
permisos de acceso y un sinónimo. Dependiendo del tipo de objeto esta
asociación se hará de forma diferente.
Para los paquetes, procedimiento y funciones de base de datos, los

permisos y sinónimos se definen dentro del mismo script de creación del
objeto, al final.
Para tablas, vistas y secuenciadores se hace mediante asignación de

un Post-Script genérico que estará disponible en el modelo con las siguientes
sentencias:
DROP PUBLIC SYNONYM %TableName;

GRANT ALL ON %TableName TO PUBLIC WITH GRANT OPTION;
CREATE PUBLIC SYNONYM %TableName FOR %TableName;
Si un objeto tuviera dos Sinónimos además de lo anterior, se creará y

asignará un Post-Script del sinónimo ajeno a la tabla con la siguiente
nomenclatura:
Nombre del post_script: POST_[Nombre_SinónimoAjeno]
Contenido del post_script:
DROP PUBLIC SYNONYM %Substr(%TemplateName,6);
CREATE PUBLIC SYNONYM %Substr(%TemplateName,6) FOR

%TableName;
10 DEFINICIÓN DE SECUENCIADORES
Los secuenciadores se definirán en ERwin realizando tres pasos:
1. Definir una tabla vacía (sin columnas) con el nombre del

secuenciador (figura 1).
2. Asignarle un ‘Post-Script’, a la tabla definida en el punto 1, que
cree el secuenciador y le asigne los permisos pertinentes, como
se indica a continuación:
DROP SEQUENCE %TableName;

CREATE SEQUENCE %TableName;

GRANT ALL ON %TableName TO PUBLIC WITH GRANT
OPTION;
CREATE PUBLIC SYNONYM %TableName FOR %TableName
;
Nota: Este ejemplo crea un secuenciador con las opciones por

defecto, si es necesario, se definirán las opciones específicas en
cada caso.
3. Definir en el explorador del modelo el secuenciador. Como se

muestra a continuación en la figura 2:
Figura 2. Definición del Secuenciador en el explorador.
Aunque se incorpore la definición del secuenciador, como tal, en el modelo, la

creación de los secuenciadores se realizará con la ejecución del script definido

en el punto 2, y no con la opción de creación de secuenciadores de ERwin, en

la generación de esquemas.
Figura 1.
Definición de la Tabla sin Columnas y con su Post-Script de creación del

secuenciador.
11 DEFINICIÓN DE COLUMNAS BLOB
Los contenidos de las columnas de tipo BLOB se almacenan en

‘Tablespaces’ específicos para estas columnas, separados del resto de los
datos de la tabla. Para cada columna del modelo de tipo BLOB, asociaremos
un Post-Script a nivel de tabla que contenga la definición del almacenamiento
de dicha columna. El texto del mencionado Script será:
ALTER TABLE %TableName

MOVE LOB ( <<NombreColumna>> )
STORE AS ( CHUNK 4096
PCTVERSION 10
NOCACHE LOGGING
TABLESPACE <<NombreTablespace>> );
Siendo <<NombreColumna>> , el nombre de la columna BLOB y

<<NombreTablespace>> el nombre del tablespace destino para el
almacenamiento del campo Blob.
El nombre del tablespace no es conocido a priori por el diseñador, por
tanto se puede indicar con un nombre provisional como el siguiente:
“TBSBLOB_” + <<SiglasProyecto>> + “_100”.
El nombre definitivo del tablespace se fijará en ICM.
NOTA: No se permite la utilización de campos de tipo LONG, en su lugar se

debe utilizar campos de tipo LOB

NOTA: Las tablas temporales (GLOBAL TEMPORARY TABLE) NO deben

llevar cláusula ALTER para especificar tablespace.
12 DEFINICIÓN DE CARGAS DE DATOS
12.1 Cargas de datos Iniciales
Las cargas de datos iniciales deberán incluirse en el modelo de datos en

el apartado de “Script Templates” y dentro de este, a nivel de modelo de datos
y no de tabla. En este punto se incluirá el Script SQL de inserción de datos.
Los pasos a seguir serán:
1. Incluir a nivel de modelo el Script de carga inicial. No se debe asociar

a la tabla afectada por la carga.
2. Codificar, en lenguaje SQL, las inserciones necesarias para cargar los

datos iniciales en la tabla.
3. No incluir “commit” en el script de carga.
4. No incluir sentencias de inhabilitación de constraints dentro del script

de carga, ni de cualquier otro tipo, como: “updates”, “deletes”, etc. Sólo deben
incluirse sentencias “Insert”.
5. Las cargas se realizarán sobre tablas con el nombre lógico, y no

físico, cuando estos dos nombres difieran.
Preferentemente, se debe definir un script por cada tabla a cargar.

En el caso de cargas de gran tamaño, que no permitan incluir todas las
sentencias SQL dentro de ERwin, se creará una referencia indicando nombre y
ubicación del fichero de carga, así como cualquier indicación que se considere
oportuna.

Ejemplo de referencia a una carga inicial no incluida en ERwin por su

tamaño.
En las entregas para certificación de productos, los datos a cargar deben

ser los suficientes para poder realizar pruebas, pero no deben cargarse datos
masivamente, ni cargarse datos reales.
Deben diferenciarse claramente, las cargas iniciales para pruebas en el
entorno de desarrollo y las cargas a realizar en el entorno de producción.
12.2 Cargas de Datos de Entorno

Éstos datos se corresponden con las tablas utilizadas para la gestión de
perfiles de acceso de los usuarios a la aplicación.
Las aplicaciones de acceso público no contienen éste tipo de información.
Dependiendo del Entorno de la Aplicación (Forms, Java Intranet, java
Internet, ..), serán datos de las siguientes tablas:
12.2.1 Generales
Aplicación
Grupo
12.2.2 Forms 4.5

Grupo_Autorizacion
Menu

12.2.3 Forms 10g

F60_Menu
F60_Grupo_Menu
F60_Programas
F60_Acciones_Programa
F60_Grupo_Acciones
12.2.4 Delphi y Java Intranet

Accion
GrupAuto
12.2.5 Internet
Usui_Aplicacion
Usui_Grupo
Usui_Accion
Usui_GrupAuto
13 DESBORDAMIENTO EN NOMBRES DE ÍNDICES, PK, FK y

TRIGGERS
Se puede producir el caso, que con nombres de tabla muy largos, erwin
cuando compone los nombres de pk, fk, índices y triggers se produzca
desbordamiento.
Si se produce ésta situación, en el objeto que se produce el
desbordamiento se debe acortar el [<<NombreTabla>>] sin quitar aquellos
caracteres necesarios (aparecen en negrita).
Por ejemplo:
Primary Key: PK[<<NombreTabla>>]
Foreign Key: FK[<<NombreTabla>>]nn
Índices: AKnn[<<NombreTabla>>]
IEnn[<<NombreTabla>>]
IFnn[<<NombreTabla>>]
GRnn[<<NombreTabla>>]
Triggers: [<<NombreTabla>>]_TRIG_[T]_[A]
o cualquier otro objeto en el que se produzca el desbordamiento
Para solucionar el problema, se deberá acortar manualmente el nombre

de los objetos mencionados, que están asociados a una tabla, evitando así,
posibles errores en la creación de los objetos o su creación con nombres
ambiguos o incluso duplicados.
Se debe reducir el nombre del objeto quitando caracteres y conservando

cada una de las partes descriptivas del nombre. También, sería posible,
truncar el nombre por el final, si en este caso no se pierde “información”
descriptiva del nombre del objeto, y no se produce duplicidad con los
nombres de objetos resultantes.

En resumen, la abreviación del nombre debe hacerse de tal forma, que el

nombre resultante permita identificar a la tabla asociada a dicho objeto y no
se produzcan duplicados de nombres.
Ejemplos:
Tablas con nombres largos
CERT_PRODUCTOS_MANUF_FINALES
CERT_PRODUCTOS_MANUF_INICIALES
CERT_PRODUCCIONAGRARIANACIONAL
CERT_ASOCIACIONESPROFESIONALES
Nombres de los objetos acortados
CERT_PRODUC_MANU_FINA_TRIG_A_I
CERT_PRODUC_MANU_INIC_TRIG_A_I
CERT_PRODUCCAGRARINAC_TRIG_A_I
CERT_ASOCIACIONESPROF_TRIG_A_I
IF01CERT_PRODUCTOS_MANUF_FINAL
FK_CERT_PRODUCT_MANUF_FINAL_02
F03CERT_PRODUCCIONAGRARIANACI
FK_CERT_PRODUCCIAGRARIANACI_03
14 DEFINICIÓN DE INDICES
Dependiendo de la forma de definir la integridad referencial del modelo los índices
serán:
14.1 Con integridad referencial basada en Triggers ó sin

integridad referencial
 XPK[<<NombreTabla>>] . Para los índices de clave

primaria.
 XAKnn[<<NombreTabla>>] . Para los índices de clave
alternativa (únicos).
 XIEnn[<<NombreTabla>>] . Para los índices alternativos (con
duplicados).
 XGRnn[<<NombreTabla>>] . Para los índices Geográficos
(Oracle Spatial).
En este apartado no se permite el uso de índices XIF* (índices de

clave ajena ó foránea), generados automáticamente por ERwin.
Deberán crearse manualmente, bien como XAK* o como XIE*.

14.2 Con integridad referencial basada en Primary Key y

Foreign Key
 PK[<<NombreTabla>>] . Para los índices de clave

primaria.
 AKnn[<<NombreTabla>>] . Para los índices de clave
alternativa (únicos).
 IEnn[<<NombreTabla>>] . Para los índices alternativos (con
duplicados).
 IFnn[<<NombreTabla>>] . Para los índices de clave
foránea.
 GRnn[<<NombreTabla>>] . Para los índices Geográficos
(Oracle Spatial).
Para crear los índices en una tabla, se selecciona esta, y se abre la

opción de índices asociados. La ventana permite el mantenimiento de los
índices, y la definición de las columnas que lo integran. A continuación se
muestra dicha ventana.
Ventana de tratamiento de índices de una tabla.
15 DEFINICIÓN DE INDICES INTERMEDIA TEXT

Los índices tipo Intermedia Text tienen la nomenclatura obligatoria de :
Con integridad referencial basada en Triggers ó sin integridad referencial

XDTS[<<NombreTabla>>].
Con integridad referencial basada en Primary Key y Foreign Key

DTS[<<NombreTabla>>].
Estos índices se definen mediante Post-Script asociados a su tabla.

Dependiendo del número de columnas que componen el índice, varía su
definición. Cuando el índice lo integra mas de una columna deben definirse,
adicionalmente, ‘preferencias de acceso’.
Para un índice de una columna (sólo un post-script) :
drop index xdts%TableName;
create index xdts%TableName

on %TableName ( <<Nombre_Columna>> )
indextype is ctxsys.context;
Para un índice con mas de una columna (dos post-script) :
Script 1.
drop index xdts%TableName;
create index xdts%TableName

on %TableName ( <<Nombre_Columna1>>,
<<Nombre_Columna2>>, …. <<Nombre_ColumnaN>> )
indextype is ctxsys.context
parameters ('datastore %TableName_dts
section group ctxsys.AUTO_SECTION_GROUP');
Script 2.
ctx_ddl.drop_preference
('DBA_%Substr(%TableName,1,4).%TableName');
ctx_ddl.create_preference('DBA_%Substr(%TableName,1,4).%
TableName',
'MULTI_COLUMN_DATASTORE');
ctx_ddl.set_attribute
('DBA_%Substr(%TableName,1,4).%TableName',
'COLUMNS', '<<Nombre_Columna1>>,
<<Nombre_Columna2>>, …. <<Nombre_ColumnaN>> ' );

16 THESAURUS DE INTERMEDIA TEXT
 El script se debe crear con el usuario ctxsys.
 El formato de entrega debería ser mediante un script sql.

El nombre del fichero de script debe coincidir con el nombre del
thesaurus que contenga
 Ejemplo:
exec ctx_thes.drop_thesaurus('XXXX_THESA_EJEMPLO');
begin
ctx_thes.create_thesaurus(' XXXX_THESA_EJEMPLO ');
ctx_thes.create_relation('XXXX_THESA_EJEMPLO','PRODUCTO
INTERIOR BRUTO','SYN','PIB');
ctx_thes.create_relation('XXXX_THESA_EJEMPLO','INDICE DE PRECIOS
AL CONSUMO','SYN','IPC');
ctx_thes.create_relation('XXXX_THESA_EJEMPLO','IMPUESTO SOBRE EL
VALOR AÑADIDO','SYN','IVA');
end;
/
17 DEFINICIÓN DE PAQUETES, PROCEDIMIENTOS Y

FUNCIONES DE BASE DE DATOS
Los Paquetes, funciones y procedimientos del modelo deberán definirse

en el apartado ‘Stored Procedures’ de ERwin a nivel de Modelo (‘Model Level
Procedure’).
Los paquetes, funciones y procedimientos deberán crearse siempre con
la opción CREATE OR REPLACE
Cuando se vayan a definir múltiples procedimientos y funciones se

deberán aglutinar en un paquete.

La forma de definir un paquete, una función o un procedimiento es

idéntica. Mediante la ventana de Stored Procedures se realiza el
mantenimiento de estos objetos, debiéndose incluir al final de su código
las sentencias de asignación de permisos y del sinónimo
correspondientes, es decir :
DROP PUBLIC SYNONYM <<NombreObjeto>>;
GRANT ALL ON <<NombreObjeto>> TO PUBLIC WITH GRANT

OPTION;
CREATE PUBLIC SYNONYM <<NombreObjeto>>FOR

<NombreObjeto>;
ERwin no permite almacenar, en este apartado, textos superiores a

32K de tamaño, lo que ha provocados problemas para almacenar algunos
paquetes en los modelo de datos. La solución que se propone, cuando se dé
esta circunstancia, consiste en definir en el modelo ERwin solamente la
cabecera del paquete, y el cuerpo almacenarlo en archivo adjunto al
modelo, como un documento de tipo SQL. En la cabecera definida en ERwin,
se incluirá un aviso indicando esta situación con el siguiente formato:
/*
A V I S O.
--------------------------------------------------------------------------------------------------------
La longitud de este {Paquete|Procedimiento|Función} excede la capacidad de ERwin
de Almacenarlo (32 K), por tanto se adjunta en fichero a parte, según se indica a
continuación:
Nombre {Paquete|Procedimiento|Función} : CERT_PACK_QUE_NO_CABE

Nombre Fichero Externo SQL: CERT_PACK_QUE_NO_CABE.sql
Ubicación: BASE DATOS/ERWIN
----------------------------------------------------------------------------------------------------------
*/
Se muestra un ejemplo a continuación:

18 ROLES
Éstos objetos serán incluidos previa autorizacion de ICM
Se incluirán en Model Level Scripts (script a nivel de modelo)
19 JOBS
Éstos objetos serán incluidos previa autorizacion de ICM
Se incluirán en Model Level Scripts (script a nivel de modelo)
con la sintaxis JOB_[Nombre_Procedimiento_Ejecutado] .
y con el contenido:
/*
Definición de job de base de datos
Procedimiento: XXXX_Procedimiento
Periodicidad: Cada n {minutos/horas/dias/semanas/años/…}
Objeto del Proceso: Breve descripción del Proceso ejecutado
*/
Ejemplo:


20 DEFINICIÓN DE INTEGRIDAD REFERENCIAL

La integridad referencial de un modelo se puede definir de dos formas
diferentes, mediante la utilización de disparadores de base de datos (triggers),
o bien, mediante el uso de cláusulas Primary Key y Foreign Key. ICM
recomienda el uso de Primary Key y Foreign Key
Sólo en casos especiales y justificados podrá aceptarse un modelo de
datos sin integridad referencial.
20.1 Definición de Integridad Referencial Basada en

Disparadores de Base de Datos (Triggers).
Existen dos tipos de disparadores de tabla: los de usuario y los de

integridad referencial.
Los dispara de usuario, solo deben cumplir la norma de ICM sobre su
nomenclatura.
Los disparadores de Integridad referencial por defecto están definidos

en ERwin en:
“DATABASE  RI Triggers  Global Triggers Templates”.
ICM ha definido unas plantillas estándar con la definición de los

triggers de IR, que deberán ser empleadas en los modelos. Estas
plantillas han sido incluidas en los modelos de ejemplo suministrados.
Para definirlos o verificar su existencia en el modelo de datos

utilizamos la opción de “Global Triggers Templates” de ERwin, como se
indicaba con anterioridad.

Debe apreciarse en los nombres de los “templates” la inclusión de “ICM”,

así, como la traducción de mensajes de error y las mejoras en el código.
Cuando se defina la integridad referencial con triggers la ventana de

“Model Naming Options” debe tener definidas las siguientes opciones:
20.2 Definición de Integridad Referencial Basada en Primary

Key
Cuando se defina la integridad referencial con PK y FK se deben

verificar las macros definidas para la construcción de los nombres de los
índices y claves foráneas. Esto evitará tener que definir los nombres
manualmente para que se ajusten a las nomenclaturas estándar.
Podemos verificar la correcta definición de los nombres por defecto,
accediendo a la ventana de “Model Naming Options”, que deberá tener
definidas las siguientes opciones:

Para que aparezca esta pestaña en el modelo, este debe haberse

creado como modelo Lógico/Físico y no sólo como modelo Físico.
Las constraints Primary Key y Foreign Key deben cumplir con la
nomenclatura estándar establecida.
Primary Key: “PK”+ <<NombreTabla>>

Foreign Key: “FK”+ <<NombreTabla>>+”_nn”
Deberán renombrase numerando las constraints con un numero

secuencial al final del nombre, como se muestra en el siguiente ejemplo.
NOTA: Deben numerarse las FK’s aunque sólo haya una por tabla

La constraint se renombra manualmente mediante la ventana de

relaciones (relationships), como se muestra a continuación.
Por defecto erwin creará todos los índices FK existentes en el modelo,

por tanto deben eliminarse todos los índices no deseados por el
diseñador. Se deberá estudiar la necesidad o justificación de estos
índices y no permitir, por dejadez o comodidad, que se creen por
defecto.
Cuando tengamos incluidos en nuestro modelo de datos tablas de

otros esquemas, que no tienen definida la Primary Key, deberemos
anular (ajustar a “none”) las acciones de integridad referencial asociadas
a la relación, para evitar que se genere la correspondiente Foreign Key.
Ejemplo:

Ahora no se genera la clave foránea FKCERT_TABLA20_03.
21 DEFINICIÓN DE CHEQUEOS Y VALORES POR DEFECTO A

NIVEL DE COLUMNA
Para definir chequeos ó validaciones (‘Validaction Rules’) y valores por
defecto ( ‘Default Values’ ) sobre columnas seguiremos los siguientes pasos:
1. Definir a nivel de modelo los chequeos o reglas de validación genéricas
y valores por defecto genéricos.
Las validaciones genéricas deben definirse según la nomenclatura

estándar:

PROY_CHECK_<<DescripciónValidación>>
Los nombres, tanto de validaciones como de los valores por defecto,

deberán ser lo mas descriptivos posibles.
2. Asignar a las columnas deseadas las validaciones y valores por defecto

que se precisen.
Esto se realiza en el apartado de definición de columnas, seleccionando
una validación o valor por defecto de los disponibles en las listas
desplegables.
Las validaciones no podrán tener activado el contador que se utiliza, por

defecto, para la construcción del nombre de la constraint. Por tanto, cuando
se desee aplicar una misma validación a varias columnas, deberán definirse
validaciones diferentes asociándose cada una de ellas a una columna
diferente.
Ejemplo:

Para eliminar la duplicidad de nombre de las validaciones podemos

emplear una numeración, que se asignará manualmente, o incluir en el
nombre de la constraint el nombre de la columna con los valores validados.
Ejemplo de nombres de reglas de validación que chequean los valores ‘S’
ó ‘N’ en múltiples columnas del modelo:
 PROY_CHECK_S_N_01
 PROY_CHECK_S_N_02
 PROY_CHECK_S_N_03  Misma validación con diferente
nombre. Se utiliza una numeración.
 PROY_CHECK_ITVALIDO_S_N
 PROY_CHECK_ITENVIADO_S_N  Misma validación utilizando
el nombre de la columna.
22 DEFINIR ACCIONES DE TRIGGER DE INTEGRIDAD

REFERENCIAL EN LAS RELACIONES ENTRE TABLAS
Erwin permite definir Acciones de Integridad Referencial en las relaciones entre

tablas, como consecuencia de las acciones que se definan generará una serie
de triggers.
En el Menú de Erwin podemos visualizar en la pantalla Model Properties la

pestaña RI Defaults las Acciones por defecto. Éstas acciones por defecto ya
están establecidas y NO se deben cambiar, lógicamente ya están incorporadas
en la plantilla erwin que se suministra.

Si se desea incorporar otras acciones diferentes la forma de hacerlo es entrar

en la pantalla de Relationship en la pestaña RI Actions de la relación que
queramos y cambiar las acciones. Lógicamente cualquier cambio de éste tipo
debe estar perfectamente controlado su alcance.
La recomendación es trabajar siempre con los valores por defecto y no realizar

cambios en las acciones de las relaciones.

23 DEFINICIÓN DE SINÓNIMOS REMOTOS
Para definir un sinónimo remoto, cuando sea necesario, seguiremos los

siguientes pasos:
1. Definir la tabla con las columnas que tiene la tabla destino del Sinónimo.
2. Eliminar la generación de la tabla, pues no forma parte del esquema de
datos.

3. Asignarle un ‘Post-Script’, a la tabla definida en el punto 1, que contenga

las sentencias de creación del sinónimo remoto, como se indica a
continuación:
DROP PUBLIC SYNONYM %TableName ;

CREATE PUBLIC SYNONYM %TableName
FOR
<<PropietarioTablaEnlazada>>.<<NombreTablaEnlazada>>@<
<NombreEnlaceBaseDatosICM>>;
EL nombre del enlace de base de datos lo define ICM. En caso de no

conocerse, puede ponerse un nombre de enlace provisional, que será
sustituido en el momento de la ejecución de la sentencia.
Esta sentencia tiene como objeto conocer la necesidad de creación del

sinónimo, así como, informar de la tabla sobre la cual queremos definir el
sinónimo remoto.
Dada la singularidad de este objeto, deberá dibujarse en el tapiz de
diseño con otro color que permita fácilmente identificarle y diferenciarle del
resto de objetos del esquema.
NOTA: Si se desea el nombre del sinónimo_remoto pude incluir al final

_LINK . Ejemplo: CERT_SINONIMO_REMOTO_LINK
24 TRIGGERS
No se permiten 2 triggers de una tabla con el mismo evento. Debe
haber un trigger por evento.
En caso contrario se debería justificar éste tipo de uso.

La construcción del trigger debe seguir los siguientes pasos:

1.- Crear el nuevo trigger sobre la tabla seleccionada con el nombre de
trigger correpondiente a lo que se indica en la documentación de
Nomenclatura de Objetos Oracle.
Rellenar en la pestaña general las Opciones de:
Trigger On
Fire
Scope
2,- A continuación en la pestaña Code incluir el código correspondiente del

trigger:

Las opciones indicadas en la pestaña General deben corresponderese con

las opciones indicadas en el Código
25 TABLAS TEMPORALES (GLOBAL TEMPORARY TABLE)

Para definir una tabla temporal, cuando sea necesario, seguiremos los
siguientes pasos:
1.- Definir una tabla vacía (sin columnas) con el nombre de la tabla
temporal..

2.- Asignarle un ‘Post-Script’, a la tabla definida en el punto 1, que cree

la tabla temporal con todas sus columnas y opciones. Además, si se
desea, se le pueden asignar dentro de este script la definición del
sinónimo y los permisos pertinentes, como se indica a continuación:
CREATE GLOBAL TEMPORARY TABLE %TableName

(
COLUMNA1 VARCHAR2(10),
COLUMNA2 NUMBER
.
.
)
[ON COMMIT { DELETE | PRESERVE } ROWS] ;

GRANT ALL ON %TableName TO PUBLIC WITH GRANT
OPTION;
En las tablas temporales (global temporary ) los comentarios se añadirán a

nivel de tabla. Ejemplo:

Las Tablas temporales pueden llevar índices, primary key, foreign key
Ejemplo:

26 VISTAS
La definición de las vistas se realizará con la opción User-Defined SQL.

En este caso no debe finalizarse la definición de la vista con “;”.
En cualquier caso deben asociarse, igual que en caso de las tablas, la

definición de un sinónimo y de los permisos de acceso correspondientes. Se
puede asignar el mismo post-script de las tablas.
Las vistas deberán crearse siempre con la opción CREATE OR

REPLACE . Además no debe aparecer la sentencia DROP VIEW

27 VISTAS MATERIALIZADAS
La definición de las vistas materializadas se realizará con la opción User-
Defined SQL. En este caso no debe finalizarse la definición de la vista con “;”.
En cualquier caso deben asociarse, igual que en caso de las tablas, la

definición de un sinónimo y de los permisos de acceso correspondientes. Se
puede asignar el mismo post-script de las tablas.
27.1 Introducción
Este documento detalla las normas básicas a tener en cuenta a la hora de
crear vistas materializadas en bases de datos de ICM.
Estas normas están orientadas a conseguir la implementación que impacte
menos al rendimiento de las bases de datos y a facilitar la administración y el
mantenimiento de las mismas.
Por último se incluye un apartado con los conceptos generales de vistas
materializadas en Oracle para su consulta en caso necesario.
27.2 Normativa ICM

27.2.1 Tipos de vistas y configuración refresco
La creación de vistas materializadas en bases de datos de ICM deberá tener en
cuenta los siguientes principios:
 Todas las vistas materializadas utilizadas serán de sólo lectura.
 En el caso de que se creen tablas con muchas columnas de las que en
la vista materializada sólo se usan unos pocos, se intentará minimizar el
número de columnas de la vista materializada para minimizar el tráfico
de red.
 Se crearán los índices necesarios para que las consultas sobre las
vistas materializadas sean rápidas.
 Como norma general, se utilizará el refresco completo para afectar lo
menos posible al rendimiento de la base de datos en la que resida la
tabla original.
 Cuando se refresquen varias tablas mediante refresco completo, se
refrescarán de forma individual, siempre que por consistencia de datos
esto sea posible. De esta forma, el refresco es más rápido y se evitan
bloqueos en las tablas refrescadas.
 La frecuencia del refresco será diaria o inferior (semanal, mensual…). El
refresco se programará a lo largo de la noche teniendo en cuenta el
tiempo que lleva y los horarios de backup de las bases de datos
implicadas.
 En casos en los que se requiera una mayor frecuencia de refresco y
siempre que se justifique esta necesidad, se estudiará la viabilidad de la
frecuencia requerida en función de los tiempos de refresco e impacto en
rendimiento.

 En casos excepcionales, debidamente justificados, puede permitirse la

utilización de refresco incremental teniendo en cuenta las siguientes
consideraciones:
o En ningún caso se permitirá el refresco incremental por ROWID.
Por tanto, si la tabla sobre la que se crea la vista debe tener
primary key. En caso contrario, el refresco será forzosamente
completo.
o Únicamente se estudiará la posibilidad de refresco incremental en
caso de que los tiempos del refresco completo sean inviables
para el funcionamiento de la aplicación. Esto puede ocurrir por
varias razones, entre otras:
 Las tablas originales muy grandes1.
 Línea de comunicación lentas entre las dos bases de datos
 Se requieren actualizaciones frecuentes
o Dado que el refresco incremental supone la creación y
mantenimiento en la base de datos donde reside la tabla origen
de un log de vista materializada, la autorización de este tipo de
refresco estará siempre condicionada a que el impacto en el
rendimiento de la base de datos origen sea asumible por las
aplicaciones que se ejecutan en ella. Esto puede presentar
problemas especialmente en tablas con muchas actualizaciones.
27.2.2 Datos necesarios para la puesta en producción

Para la puesta en producción de las vistas materializadas, se deben
proporcionar los siguientes datos:
 Tabla y base de datos sobre la que se crea.
 Volumetría estimada de la vista materializada y, en su caso, del log de
vista materializada.
 Datos de refresco:
o Tipo (completo/incremental)
o Frecuencia (diario, semanal …)
o Si debe actualizarse junto con otras vistas materializadas o puede
hacerse de manera individual.
 Sentencias de creación de la vista materializada, incluyendo los índices
que deban crearse sobre la misma, permisos que haya que conceder y
sinónimos, en caso necesario.
1
Como referencia de tiempos, en EDUCAFDI una vista materializada con
500.000 filas que ocupa 120Mb y 3 índices creados, se refresca de forma
individual en menos de media hora, lo que para un refresco nocturno es
aceptable.

27.3 Datos necesarios para mantenimiento

Para el correcto mantenimiento de las vistas, hay que tener en cuenta que
cualquier cambio en la estructura de la tabla origen (añadir o cambiar de tipo de
una columna…) puede hacer que el refresco de las vistas materializadas
creadas sobre ella dejen de funcionar con lo que debería comunicarse a los
departamentos encargados del mantenimiento de las mismas.
27.4 Nomenclatura
27.4.1 Creación de vistas materializadas
El nombre de las vistas materializadas se ajustará al siguiente esquema

XXXX_MV_<nombre_vista_materializada >
Dónde XXXX es el Cod. Aplicación.
La sintaxis de las sentencias de creación será la siguiente:
create materialized view <NOMBRE_VISTA_MATERIALIZADA>

as
select <campos_select>|*
from <tabla_origen>
[where <condiciones>];
Notas:
- No se especificarán parámetros de refresco en la sentencia de
creación de las vistas. Por defecto, se utiliza la opción FORCE, que
realiza un refresco incremental si puede y completo si no. El tipo de
refresco vendrá marcado por la existencia o no del log de vista
materializada sobre la tabla origen, si existe log se refrescará en
modo incremental, si no existe se refrescará en modo completo.
- La programación del refresco tampoco se especificará en la
sentencia de creación de las vistas ya que se programará mediante
un job aparte. De esta forma se separa la programación del refresco
de la creación de la vista. Por defecto la vista se crea con refresco
bajo demanda, es decir si no se ejecuta el job nunca se ejecutaría el
refresco.
- De manera adicional, se proporcionarán las sentencias de creación
de índices, sinónimos y permisos necesarios. Estas sentencias
seguirán los estándares habituales en ICM.
27.4.2 Creación de logs de vistas materializadas

La sintaxis de creación de logs de vistas materializadas que se usará será el
siguiente:
create materialized view log on <tabla_origen>

with primary key;
28 PARTICIONES Y SUBPARTICIONES DE TABLAS
28.1 METODOS DE PARTICIONAMIENTO
28.1.1 Particionamiento por RANGO
Utilizado cuando los datos a particionar tiene rangos claramente definidos,

como por ejemplo Salarios, Fechas,..
Ejemplo: Tabla particionada por campo tipo FECHA

CREATE TABLE xxxx_price_value(
current_dat date,
cost number(23))
partition by range(current_dat)
(PARTITION XXXX_PRICES_PAR_2007
VALUES LESS THAN (TO_DATE('01-/01/2008', 'DD/MM/YYYY')),
PARTITION XXXX_PRICES_PAR_2008
VALUES LESS THAN (TO_DATE('01/01/2009', 'DD/MM/YYYY')),
PARTITION XXXX_PRICES_PAR_MAX
VALUES LESS THAN (MAXVALUE));
En la partición XXXX_PRICES_PAR_2007 estarán todos los registros

anteriores al año 2008, en XXXX_PRICES_PAR_2008 aquellos anteriores a
2009 y en XXXX_PRICES_PAR_MAX aquellosmayores o iguales al 2009.
En este ejemplo el rango de particionamiento es abierto, dejando la última

partición sin valor en el rango para recoger todos los registros que no cumplan
las condiciones de las otras dos particiones.
También se podría haber cerrado el rango, lo cual implicaría a una

mantenimiento anual que cree la partición correspondiente, con el fin de no
obtener errores por inserción de registros no mapeados en las particiones.
28.1.2 Particionamiento por HASH
Utilizado cuando los datos no tiene definidos rangos lógicos, se usa para
mejorar rendiminetos y manejabilidad, debido a la disperisón de datos, evitando
bloques caleintes.

El cálculo de particionamiento se basa en la aplicación de una función HASH

sobre la columna clave, ubicando los datos en cada una de las particiones que
le correspondan.
En este tipo el usuario no tiene control sobre el reparto de los datos en las
particiones.
Ejemplo: Particionamiento de tabla en 4.

CREATE TABLE XXXX_PRODUCT
(product_id NUMBER,
name VARCHAR2 (60))
PARTITION BY HASH (product_id)
PARTITIONS 4;
En este caso el sistema asignará automáticamente el nombre de cada

partición, tipo: "SYS_P23"
28.1.3 Particionamiento por LISTA
Utilizado cuando el campo a particionar no se compone de rangos lógicos, sino

esta compuesto de valores desordenados o sin relación.
Un ejemplo de este tipo de particionamiento sería agrupaciones de

comunidades autonomas por codigo de provincia.
Ejemplo: Agrupamos por CCAA, segun codigo matricula antiguo

CREATE TABLE XXXX_sales_region
(deptno number,
deptname varchar2(20),
quarterly_sales number(10, 2),
provincia varchar2(2))
PARTITION BY LIST (state)
(PARTITION XXXX_SALES_REGION_PAR_MADRID VALUES ('M'),
PARTITION XXXX_SALES_REGION_PAR_GALICIA VALUES ('C', 'OR', 'LU',
'P'),
PARTITION XXXX_SALES_REGION_PAR_CATAL VALUES ('B', 'T', 'LE','GE'),
....
PARTITION XXXX_SALES_REGION_PAR_CANAR VALUES ('GC', 'TF'));
28.1.4 Particionamiento compuesto RANGO - HASH
Idoneo para datos historicos y realizar "striping". Saca partido del paralelismo
asi como mejorar rendiminetos y manejabilidad debido al uso del HASH.

Consiste en dos niveles, el primero basado en RANGO y el segundo basado en

HASH.
Ejemplo: tres particiones divididas cada una en 4 subparticiones

CREATE TABLE XXXX_SALES_PRODUCT
(prod_id number,
prod_name varchar2(20),
price number)
PARTITION BY RANGE(prod_id) SUBPARTITION BY HASH(prod_name)
SUBPARTITION TEMPLATE(
SUBPARTITION sp1,
SUBPARTITION sp2,
SUBPARTITION sp3,
SUBPARTITION sp4 )
(PARTITION sale_pa1 VALUES LESS THAN (1000),
PARTITION sale_pa2 VALUES LESS THAN (2000),
PARTITION sal_pa3 VALUES LESS THAN (MAXVALUE));
Al usar el formato de TEMPLATE para las subparticiones, el sistema asigna

como nombre la concatenación del nombre de la particion y de la subpartición
("sale_pa1_sp1")
28.1.5 Particionamiento compuesto RANGO - LISTA
Utilizado para particionamiento de datos historicos con posibilidad de

subparticionar por listas de datos, es decir por valores desordenados o sin
relación.
Consiste en dos niveles, el primero basado en RANGO y el segundo basado en

LISTA.
Ejemplo: Tres particiones por RAngo subdivididas en otras tres por listas
CREATE TABLE XXXX_sales_product1
(prod_id number,
prod_name varchar2(20),
price number)
PARTITION BY RANGE(prod_id)
SUBPARTITION BY LIST (prod_name)
SUBPARTITION TEMPLATE(
(PARTITION XXXX_sales_product1_PAR_pa1 VALUES LESS THAN (1000)
(SUBPARTITION XXXX_sales_product1_SPAR_Prod1 VALUES('SK', 'LM',
'TG'),
SUBPARTITION XXXX_sales_product1_SPAR_prod2 VALUES('CF', 'AR', 'HI'),
SUBPARTITION XXXX_sales_product1_SPAR_prod3 VALUES('IL', 'OK',
'FG')),

PARTITION sale_pa2 VALUES LESS THAN (2000)

'TG'),
'FG')),
PARTITION sal_max VALUES LESS THAN (MAXVALUE)
'TG'),
'FG')));
28.2 Post-Script específico para tabla con particiones

Por cada tabla plarticionada se creará un objeto tabla con el nombre de la tabla
y se creará un Post_Script con la siguiente nomenclatura:
Post_PAR_[Nombre_de_tabla]
Éste post-script incluirá todas las sentencias necesarias de la tabla incluyendo
las particiones.
Ejemplo: Post_Script: Post_PAR_XXXX_EXPTE
DROP TABLE %TableName CASCADE CONSTRAINTS;
CREATE TABLE %TableName

(
CD_EXPTE NUMBER,
FC_REGISTRO DATE
)
PARTITION BY RANGE (FC_REGISTRO)
(PARTITION XXXX_EXPTE_PAR_2007
PARTITION XXXX_EXPTE_PAR_2008
PARTITION XXXX_EXPTE_PAR_MAX
VALUES LESS THAN (MAXVALUE));

GRANT ALL ON %TableName TO PUBLIC WITH GRANT OPTION;
Las tablas particionadas los comentarios se añadirán a nivel de tabla.

Las tablas temporales pueden llevar índices, primary key, foreign key
29 APLICACIONES GIS
29.1 Subáreas
Los objetos alfanumericos irán en un subárea y los objetos Gis irán en

otro subárea (aunque convivan o no en la misma base de datos).Con la
siguiente nomenclatura:
‘DBA_XXXX_GIS’
‘DBA_XXXX_ALFANUMERICA’
NOTA: En éste tipo de Módulos es necesario incorporar el SubÁrea

DBA_XXXX
29.2 Roles
Se creara un Model-Level-Script Erwin por cada Rol que exista en la
Aplicación, con la siguiente nomenclatura Script Erwin:
ROLE_[Nombre_del_Rol]_[GIS]
Ejemplo:
En el General Properties activar Generation Option: Pre-Creation

En el Code Properties debe aparecer :
- la creación del Rol
- Asignación de ROL_GEN al Rol (Necesario para trabajar con
GIS)
CREATE ROLE XXXX_SELECT;

GRANT ROL_GEN TO XXXX_SELECT; -- Necesario para trabajar con
GIS
Al ser un Pre-Script se creará al principio en el Modelo de datos

29.3 Post Scripts a nivel de Tabla específicos para GIS
 Post_TablaVistaPermisos_GIS Crea el sinónimo público de la tabla

 Post_SecuenciaTabla_GIS Crea el sinónimo publico del secuenciador
 Post_TablaTemporal_GIS Crea el sinónimo publico de la tabla temporal
 Post_ROLE_Select_GIS Asigna permisos del objeto al rol
 Post_ROLE_Update_GIS Asigba permisos del objeto al rol
30 APLICACIONES BUSINESS OBJECTS

30.1 Subáreas
Se debe añadir un subárea con la siguiente nomenclatura

‘DBA_DW_XXXX’
que debe contener todos los objetos DataWareHouse de Business
Objects.
En el SubÁrea DBA_XXXX no se deben incorporar los objetos de

Business Objects, y debe eliminarse ya que queda vacío
30.2 Roles
Se creará un Model-Level-Script Erwin para un rol que permitirá el
acceso a todos los objetos del esquema DBA_DW_XXXX.
El nombre del script será ROLE_DW_ALL_BO:
En el Code Properties debe aparecer la creación del Rol, cuyo nombre

debe ser XXXX_DW_ALL.
Ejemplo:
CREATE ROLE XXXX_DW_ALL;
Al ser un Pre-Script se creará al principio en el Modelo de datos
En el General Properties activar Generation Option: Pre-Creation

30.3 Opciones de Generación específicas para B.O
Consultar las Opciones específicas de Generación del esquema de

objetos para B.O.
30.4 Post Scripts a nivel de Tabla específicos para BO
 Post_TablaVistaPermisos_BO Crea el sinónimo público de la tabla

 Post_SecuenciaTabla_BO Crea el sinónimo publico del secuenciador
 Post_TablaTemporal_BO Crea el sinónimo publico de la tabla temporal
 Post_ROLE_DW_ALL_BO Asigna permisos del objeto al rol
31 APLICACIONES DOCUMENTUM
31.1 Subáreas
Se debe añadir una subárea con el nombre de DOCUMENTUM
que va a contener aquellos objetos oracle que deben crearse en la base
de datos de documentum. Los objetos oracle que se perminten crear en esta
subárea son: Sinóminimos Remotos Privados, Secuencias y Trigger.
31.2 Sinónimos Remotos Privados

Para cada una de las tablas externas registradas en documentum, se
creará un sinónimo privado remoto, cuyo nombre debe de coincidir con el
nombre con el que se ha registrado la tabla en documentum. Seguirá la
siguiente nomenclatura:
<CODIGO_APLICACION>_EXT_<DESCRIPCIÓN>
Su creación se realizará según la normativa de ésta guía indicada en el

punto de Sinónimos Remotos. En esta apartado se hace referencia a sinónimos
públicos, en el caso de Documentum se crearán sinónimos privados
Ejemplo de Tabla con la opción de generate a false, a la que se le ha

asignado un Post_Script con las sentencias de creación del sinónimo:


31.3 Secuencias
Su creación se realizará según la normativa de ésta guía indicada en el
punto de definición de secuenciadores. En el caso de documentum, no deben
llevar sentencias de asignación de Permisos (Grant) ni creación de Sinónimos.
Ejemplo de Tabla vacía , a la que se le ha asignado un Post_Script con

las sentencias de creación de la secuencia:


31.4 Triggers
Su creación se realizará según la normativa de esta guía indicada en el

apartdo de Trigger. Para el caso de Documetum debe crearse una tabla sin
campos, cuyo nombre debe seguir la siguiente nomenclatura:
<CODIGO_APLICACIÓN>_TD_<DESCRIPCIÓN>_S, siendo
<CODIGO_APLICACIÓN>_TD_<DESCRIPCIÓN> el nombre del tipo
documental sobre el que se va a definir el trigger.
Ejemplo Tabla, con la opción de generate a false.

Ejemplo con sentencias de creación de trigger:

31.5 Opciones de Generación Específicas para DOCUMENTUM

Consultar las Opciones específicas de Generación del esquema de
objetos para DOCUMENTUM.
31.6 Post Scripts a nivel de Tabla específicos para

DOCUMENTUM.
 Post_Secuencia_DOCU Crea la secuencia

 Post_SinonimoRemoto_BO Crea el sinónimo privado remoto de la tabla.

32 OPCIONES DE GENERACIÓN DEL ESQUEMA DE DATOS
ICM realiza la creación o generación de esquemas de una forma estándar,

partiendo del modelo de datos ERwin. Esta generación se realiza mediante la
propia herramienta ERWin, para lo que se han definido unas opciones estándar
de generación del esquema.
Estas opciones se pueden dividir en dos tipos:
 Opciones comunes ó generales. Son de aplicación a todos

los modelos de datos.
 Opciones Específicas. Son aquellas que se aplican

opcionalmente dependiendo de la forma de definir la integridad
referencial del modelo.
Podemos encontrar tres casos posibles:
 Integridad Referencial basada en Pk y Fk.

 Integridad Referencial basada en Triggers.
 No se mantiene Integridad Referencial (sólo casos
especiales).
Opciones Específicas para Business Objects
Opciones Específicas para Documentum
A continuación se describen esquemáticamente las opciones de

generación de esquemas mediante ERwin. Se han separado según los tipos
definidos con anterioridad. A todo modelo se les aplicarán las opciones
comunes (apartado a) y, además, una de las opciones definidas
específicamente (b, c ó d) para cada una de las soluciones o estrategias de
definición de IR.
32.1 Opciones de generación comunes a cualquier modelo
SCHEMA
* Si es un proyecto Business Objects debe
PRE-SCRIPT X
estar chequeada
POST-SCRIPT X * Si hay cargas de datos iniciales.
* Si hay funciones, procedimientos o
CREATE PROCEDURE X
paquetes de B.D.

DROP PROCEDURE
TABLESPACE
ROLLBACK SEGMENT
DATABASE
SEQUENCE
DROP SECUENCE
VIEW
CREATE VIEW X
DROP VIEW
CREATE PROCEDURE
DROP PROCEDURE
PRE-SCRIPT
POST-SCRIPT X
MATERIALIZED VIEW
CREATE MATERIALIZED
X
VIEW
DROP MATERIALIZED
X
VIEW
CREATE PROCEDURE
DROP PROCEDURE
PRE-SCRIPT
POST-SCRIPT X
TABLE
CREATE TABLE X
DROP TABLE X
TABLE CHECK
PARTITIONS
PHYSICAL STORAGE
PRE-SCRIPT
POST-SCRIPT X
CREATE PROCEDURE

DROP PROCEDURE
CREATE SYNONYM
DROP SYNONYM
OVERRIDE OWNER
COLUMN
CHECK CONSTRAINT X
PHYSICAL ORDER X
DEFAULT VALUE X
OTHER OPTIONS
CONSTRAINT X
COMMENTS
QUOTE NAMES
OWNER
32.2 Opciones de generación específicas para Integridad

Referencial Basada en PK y FK
INDEX
CREATE INDEX
PRIMARY KEY Se crea implícitamente con la PK
ALTERNATE KEY X
Se deben “anular” los no deseados
FOREIGN KEY X mediante la opción “Generate” de cada
índice.
INVERSION ENTRY X
PHYSICAL
STORAGE
PARTITIONS
DROP INDEX
PRIMARY KEY
ALTERNATE KEY
FOREIGN KEY
INVERSION ENTRY
OVERRIDE OWNER
REFERENCIAL INTEGRITY

PRIMARY KEY X
CREATE
ALTER X
FOREIGN KEY X
ON DELETE X
ON UPDATE X
STATEMENT
FORMAT
CREATE
ALTER X
UNIQUE
TRIGGER
ERWIN GENERATED
RI TYPE OVERRIDE
RELATIONSHIP
OVERRIDE
USER DEFINED X
RI TYPE OVERRIDE
RELATIONSHIP
X
OVERRIDE
32.3 Opciones de generación específicas para Integridad

Referencial Basada en Triggers
INDEX
CREATE INDEX
PRIMARY KEY X
ALTERNATE KEY X
FOREIGN KEY
INVERSION ENTRY X
PHYSICAL
STORAGE
PARTITIONS
DROP INDEX
PRIMARY KEY
ALTERNATE KEY
FOREIGN KEY

INVERSION ENTRY
OVERRIDE OWNER
PRIMARY KEY
CREATE
ALTER
FOREIGN KEY
ON DELETE
ON UPDATE
STATEMENT
FORMAT
CREATE
ALTER
UNIQUE
TRIGGER
ERWIN GENERATED X
RI TYPE OVERRIDE X
RELATIONSHIP
X
OVERRIDE
USER DEFINED X
RI TYPE OVERRIDE X
RELATIONSHIP
X
OVERRIDE
32.4 Opciones de Generación Específicas para Integridad

Referencial No Definida
INDEX
CREATE INDEX
PRIMARY KEY X
ALTERNATE KEY X
FOREIGN KEY
INVERSION ENTRY X
PHYSICAL
STORAGE
PARTITIONS

DROP INDEX
PRIMARY KEY
ALTERNATE KEY
FOREIGN KEY
INVERSION ENTRY
OVERRIDE OWNER
PRIMARY KEY
CREATE
ALTER
FOREIGN KEY
ON DELETE
ON UPDATE
STATEMENT
FORMAT
CREATE
ALTER
UNIQUE
TRIGGER
ERWIN GENERATED
RI TYPE OVERRIDE
RELATIONSHIP
OVERRIDE
USER DEFINED X
RI TYPE OVERRIDE
RELATIONSHIP
X
OVERRIDE
32.5 Opciones de Generación Específicas para B.O.

SCHEMA
* Si es un proyecto Business Objects debe
PRE-SCRIPT X
estar chequeada
32.6 Opciones de Generación Específicas para DOCUMENTUM

Las opciones de Generación específicas de Documentum son las detalladas a

continuación.
El resto de las opciones deben estar anuladas.
TRIGGER
ERWIN GENERATED
RI TYPE OVERRIDE
RELATIONSHIP
OVERRIDE
USER DEFINED X
RI TYPE OVERRIDE X
RELATIONSHIP
X
OVERRIDE
TABLE
CREATE TABLE X
DROP TABLE X
TABLE CHECK
PARTITIONS
PHYSICAL STORAGE
PRE-SCRIPT
POST-SCRIPT X
CREATE PROCEDURE
DROP PROCEDURE
CREATE SYNONYM
DROP SYNONYM
OVERRIDE OWNER
33 OBJETOS NO PERMITIDOS
Cualquier Objeto No contemplado deberá ser consultado con ICM para
obtener Autorización.

34 RECOMENDACIONES GENERALES DE DISEÑO DEL

MODELO
 Cuando definimos IR basada en PK y FK el modelo debe crearse como

Lógico y Físico, no solamente como Físico, para automatizar la
nomenclatura de índices claves ajenas.
 Crearse un área exclusiva para generar los script de creación del

modelo de datos, que contenga todos los objetos del esquema (DBA).
Sobre todo, si se incluyen objetos de otros esquemas o propietarios.
 Los diseños deben ser ilustrativos y fáciles de entender, para lo cual, se

recomienda el uso de: textos aclarativos ó descriptivos en las áreas de
diseño, atributos visuales (colores, fuentes, etc.) diferenciadores de
objetos, etc.
 Se recomienda el uso de PRIMARY KEY y FOREIGN KEY para

mantener la integridad referencial.
 Utilizar los catálogos de datos y procedimientos o funciones de carácter

general existentes en ICM. En caso de duda, consultar con el Área de
Integración y Arquitectura de Aplicaciones.
 Dado que el modelo físico se creará en la base de datos atendiendo al

orden físico, se recomienda utilizar el modo de visualización del tapiz de
diseño: “Display Level  Physical Order”. Esto evitará sorpresas en la
disposición final de las columnas de una tabla en la base de datos.
 El modelo ERwin entregado a ICM es un documento final, no de de

trabajo. Por tanto, deben eliminarse todos aquellos elemento no
utilizados, bien sean los ejemplos de la plantilla, u objetos creados
temporalmente que ya no son de utilidad.
 El modelo ERwin no tiene como única función la de crear el esquema de

datos. El modelo de datos debe cumplir, inexcusablemente, la función de
aportar conocimiento sobre la estructura física de los datos del sistema
de información. Deberán crearse las áreas de diseño necesarias para
poder describir perfectamente el modelo de datos.
 Se recomienda usar el generador de informes “Data Browser” de ERwin,

para revisar el modelo de datos antes de ser entregado a ICM para su
validación. De una forma muy sencilla, se puede repasar el modelo en
busca de defectos y errores, que se pueden solventar rápidamente.
 Ante cualquier duda con respecto al método de diseño o normativa

consultar con el Área de Arquitectura e Integración de Aplicaciones



Nombre Del Manual

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Nombre Del Manual

Hochgeladen von

Copyright:

Verfügbare Formate

Nombre del manual GUIA DE DISEÑO CON ERWIN 4.

GUIA DE DISEÑO CON ERWIN

Fecha Versión Cambios

Área de Integración y Arquitectura de Aplicaciones Página: 1

Área de Integración y Arquitectura de Aplicaciones Página: 2

Con integridad referencial basada en Primary Key y Foreign Key.................... 15

Área de Integración y Arquitectura de Aplicaciones Página: 3

30 APLICACIONES BUSINESS OBJECTS .............................................. 43

El presente documento pretende orientar en la definición de objetos de

La versión actual de ERwin que maneja ICM es 4.1.4.3907

Área de Integración y Arquitectura de Aplicaciones Página: 4

Debe consultarse también la documentación de ICM relativa a la

Debe consultarse el fichero erwin ejemplo

La realización del Modelo de datos Erwin se debe construir a partir

En las tablas temporales (global temporary ) los comentarios se añadirán a

4 NORMATIVA del NOMBRE DEL FICHERO ERWIN

 vv.rr: Versión y revisión del proyecto (por ejemplo 1.0)

 aaaammdd: Fecha (por ejemplo 20092506).

6.1 <Main SubjectArea>

Área de Integración y Arquitectura de Aplicaciones Página: 5

6.2 <Área Principal o General del Esquema>

6.3 <Área de Creación del esquema DBA_XXXX>

6.4 <Área de Diseño Parcial 1>

6.5 Por cada Instancia de base de datos se incorporará un

Por ejemplo si nuestro proyecto incorpora objetos de b.d. Centralizada y

6.6 <Área de Trabajo>

7 FORMATO DE ENTREGA PARA CARGA MASIVA DE

Área de Integración y Arquitectura de Aplicaciones Página: 6

 Alter Session para asignar un segmento de rollback a una

9 PERMISOS Y SINÓNIMOS DE OBJETOS DE BASE DE

Para los paquetes, procedimiento y funciones de base de datos, los

Para tablas, vistas y secuenciadores se hace mediante asignación de

DROP PUBLIC SYNONYM %TableName;

Si un objeto tuviera dos Sinónimos además de lo anterior, se creará y

DROP PUBLIC SYNONYM %Substr(%TemplateName,6);

CREATE PUBLIC SYNONYM %Substr(%TemplateName,6) FOR

1. Definir una tabla vacía (sin columnas) con el nombre del

DROP SEQUENCE %TableName;

Área de Integración y Arquitectura de Aplicaciones Página: 7

CREATE SEQUENCE %TableName;

DROP PUBLIC SYNONYM %TableName;

Nota: Este ejemplo crea un secuenciador con las opciones por

3. Definir en el explorador del modelo el secuenciador. Como se

Figura 2. Definición del Secuenciador en el explorador.

Aunque se incorpore la definición del secuenciador, como tal, en el modelo, la

Área de Integración y Arquitectura de Aplicaciones Página: 8

en el punto 2, y no con la opción de creación de secuenciadores de ERwin, en

Definición de la Tabla sin Columnas y con su Post-Script de creación del

11 DEFINICIÓN DE COLUMNAS BLOB

Los contenidos de las columnas de tipo BLOB se almacenan en

ALTER TABLE %TableName

Siendo <<NombreColumna>> , el nombre de la columna BLOB y

“TBSBLOB_” + <<SiglasProyecto>> + “_100”.

El nombre definitivo del tablespace se fijará en ICM.

NOTA: No se permite la utilización de campos de tipo LONG, en su lugar se

Área de Integración y Arquitectura de Aplicaciones Página: 9

NOTA: Las tablas temporales (GLOBAL TEMPORARY TABLE) NO deben

12 DEFINICIÓN DE CARGAS DE DATOS

12.1 Cargas de datos Iniciales

Las cargas de datos iniciales deberán incluirse en el modelo de datos en

Los pasos a seguir serán:

1. Incluir a nivel de modelo el Script de carga inicial. No se debe asociar

2. Codificar, en lenguaje SQL, las inserciones necesarias para cargar los

3. No incluir “commit” en el script de carga.