Está en la página 1de 59

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

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


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

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

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


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

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

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


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

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

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


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

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:

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


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

 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;

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


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

CREATE SEQUENCE %TableName;

DROP PUBLIC SYNONYM %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

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


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

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

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


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

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.

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


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

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

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


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

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.

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


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

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*.

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


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

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

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


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

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>> ' );

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


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

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.

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


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

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:

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


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

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:

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


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

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


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

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.

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


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

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:

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


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

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

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


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

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:

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


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

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:

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


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

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:

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


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

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.

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


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

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.

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


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

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.

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


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

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.

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


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

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:

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


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

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..

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


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

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] ;

DROP PUBLIC SYNONYM %TableName;


GRANT ALL ON %TableName TO PUBLIC WITH GRANT
OPTION;
CREATE PUBLIC SYNONYM %TableName FOR %TableName;

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


nivel de tabla. Ejemplo:

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


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

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

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


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

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

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


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

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.

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


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

 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.

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


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

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>

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


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

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.

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


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

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.

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


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

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')),

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


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

PARTITION sale_pa2 VALUES LESS THAN (2000)


(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 sal_max VALUES LESS THAN (MAXVALUE)
(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')));

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
VALUES LESS THAN (TO_DATE('01/01/2008', 'DD/MM/YYYY')),
PARTITION XXXX_EXPTE_PAR_2008
VALUES LESS THAN (TO_DATE('01/01/2009', 'DD/MM/YYYY')),
PARTITION XXXX_EXPTE_PAR_MAX
VALUES LESS THAN (MAXVALUE));

DROP PUBLIC SYNONYM %TableName;


GRANT ALL ON %TableName TO PUBLIC WITH GRANT OPTION;
CREATE PUBLIC SYNONYM %TableName FOR %TableName;

Las tablas particionadas los comentarios se añadirán a nivel de tabla.

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


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

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

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


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

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

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


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

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:

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


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

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


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

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:

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


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

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


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

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.

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


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

Ejemplo con sentencias de creación de trigger:

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


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

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.

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


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

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.

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


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

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

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


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

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

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


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

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

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


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

INVERSION ENTRY
OVERRIDE OWNER

REFERENCIAL INTEGRITY
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

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


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

DROP INDEX
PRIMARY KEY
ALTERNATE KEY
FOREIGN KEY
INVERSION ENTRY
OVERRIDE OWNER

REFERENCIAL INTEGRITY
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

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


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

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.

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


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

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

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


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

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


Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales
Subdirección General de Desarrollo, Tecnología e Infraestructuras