Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 GUIA DE DISEÑO CON ERWIN 1.4 Fecha 01/09/2008 02/02/2009 13/03/2009 22/04/2009 23/11/2009 06/02/2012 14/02/2012 Versión 1.0 1.1 1.2 1.3 1.4 1.5 1.6 Cambios Versión Inicial Normativa para roles gis Normativa BO y Particionamiento Normativa Documentum Modificación normativa BO Almacenamiento de clob Triggers que no caben en erwin se almacenan en fichero Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 1 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 y CLOB ....................................... 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 12.2.2 12.2.3 12.2.4 12.2.5 Generales .......................................................................................................... 11 Forms 4.5 .......................................................................................................... 11 Forms 10g ......................................................................................................... 12 Delphi y Java Intranet........................................................................................ 12 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 15 Con integridad referencial basada en Primary Key y Foreign Key ........ 14 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 2 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) ............... 32 26 VISTAS.................................................................................................. 35 27 VISTAS MATERIALIZADAS ................................................................. 36 27.1 Introducción............................................................................................... 36 27.2 Normativa ICM ........................................................................................... 36 27.2.1 27.2.2 Tipos de vistas y configuración refresco .......................................................... 36 Datos necesarios para la puesta en producción ............................................... 37 27.3 Datos necesarios para mantenimiento .................................................... 38 27.4 Nomenclatura ............................................................................................ 38 27.4.1 27.4.2 28 Creación de vistas materializadas .................................................................... 38 Creación de logs de vistas materializadas ........................................................ 38 PARTICIONES Y SUBPARTICIONES DE TABLAS ............................ 39 28.1 METODOS DE PARTICIONAMIENTO........................................................ 39 28.1.1 28.1.2 28.1.3 28.1.4 28.1.5 28.2 29 Particionamiento por RANGO ........................................................................... 39 Particionamiento por HASH .............................................................................. 39 Particionamiento por LISTA .............................................................................. 40 Particionamiento compuesto RANGO - HASH ................................................. 40 Particionamiento compuesto RANGO - LISTA ................................................. 41 Post-Script específico para tabla con particiones .................................. 42 APLICACIONES GIS ............................................................................ 43 29.1 Subáreas .................................................................................................... 43 29.2 Roles .......................................................................................................... 43 29.3 Post Scripts a nivel de Tabla específicos para GIS ................................ 44 Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 3 Nombre del manual 30 GUIA DE DISEÑO CON ERWIN 4.1 APLICACIONES BUSINESS OBJECTS .............................................. 44 30.1 Subáreas .................................................................................................... 44 30.2 Roles .......................................................................................................... 44 30.3 Opciones de Generación específicas para B.O....................................... 45 30.4 Post Scripts a nivel de Tabla específicos para BO ................................. 45 31 APLICACIONES DOCUMENTUM ........................................................ 45 31.1 Subáreas .................................................................................................... 45 31.2 Sinónimos Remotos Privados .................................................................. 45 31.3 Secuencias ................................................................................................ 47 31.4 Triggers ...................................................................................................... 49 31.5 Opciones de Generación Específicas para DOCUMENTUM ................... 51 31.6 Post Scripts a nivel de Tabla específicos para DOCUMENTUM............. 51 32 32.1 OPCIONES DE GENERACIÓN DEL ESQUEMA DE DATOS .............. 52 Opciones de generación comunes a cualquier modelo ......................... 52 32.2 Opciones de generación específicas para Integridad Referencial Basada en PK y FK ............................................................................................... 54 32.3 Opciones de generación específicas para Integridad Referencial Basada en Triggers ............................................................................................... 55 32.4 Opciones de Generación Específicas para Integridad Referencial No Definida ................................................................................................................. 56 32.5 Opciones de Generación Específicas para B.O. ..................................... 57 32.6 Opciones de Generación Específicas para DOCUMENTUM ................... 57 33 OBJETOS NO PERMITIDOS ................................................................ 58 34 RECOMENDACIONES GENERALES DE DISEÑO DEL MODELO ..... 59 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 4 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 5 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 6 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 7 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 8 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 y CLOB Los contenidos de las columnas de tipo BLOB y CLOB 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 y CLOB, 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 o CLOB 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 9 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 10 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 11 Nombre del manual 12.2.3 GUIA DE DISEÑO CON ERWIN 4.1 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 12 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>>] . primaria. XAKnn[<<NombreTabla>>] . alternativa (únicos). XIEnn[<<NombreTabla>>] . duplicados). XGRnn[<<NombreTabla>>] . (Oracle Spatial). Para los índices de clave Para los índices de clave Para los índices alternativos (con Para los índices Geográficos 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 13 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>>] . primaria. AKnn[<<NombreTabla>>] . alternativa (únicos). IEnn[<<NombreTabla>>] . duplicados). IFnn[<<NombreTabla>>] . foránea. GRnn[<<NombreTabla>>] . (Oracle Spatial). Para los índices de clave Para los índices de clave Para los índices alternativos (con Para los índices de clave Para los índices Geográficos 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 14 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 15 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 16 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 17 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 18 Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 19 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 20 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 21 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 22 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 23 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 24 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 25 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 el nombre de la columna. à Misma validación utilizando 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 26 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 27 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 28 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 29 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 30 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 ERwin no permite almacenar, en este apartado, textos superiores a 32K de tamaño, lo que ha provocados problemas para almacenar algunos triggers en los modelo de datos. Para solucionar éste problema En ERwin, se incluirá un aviso indicando esta situación con el siguiente formato: /* A V I S O. -------------------------------------------------------------------------------------------------------- Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 31 Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 La longitud de este trigger 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 del trigger : CERT_EJEMPLO3_TRIG_A_U Nombre Fichero Externo SQL: CERT_EJEMPLO3_TRIG_A_U.sql Ubicación: BASE DATOS/ERWIN ---------------------------------------------------------------------------------------------------------*/ El trigger estará almacenado en un archivo adjunto al modelo, como un documento de tipo SQL. Se muestra un ejemplo a continuación: 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 32 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 33 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 34 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 35 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 UserDefined 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 36 Nombre del manual · 27.2.2 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. 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 37 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 as select <campos_select>|* from <tabla_origen> [where <condiciones>]; <NOMBRE_VISTA_MATERIALIZADA> Notas: - - - 27.4.2 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. 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 38 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 39 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 40 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 41 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 42 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 43 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 Post_SecuenciaTabla_GIS Post_TablaTemporal_GIS Post_ROLE_Select_GIS Post_ROLE_Update_GIS Crea el sinónimo público de la tabla Crea el sinónimo publico del secuenciador Crea el sinónimo publico de la tabla temporal Asigna permisos del objeto al rol 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 44 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 Post_SecuenciaTabla_BO Post_TablaTemporal_BO Post_ROLE_DW_ALL_BO Crea el sinónimo público de la tabla Crea el sinónimo publico del secuenciador Crea el sinónimo publico de la tabla temporal 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 45 Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 46 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 47 Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 48 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 49 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 50 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 Post_SinonimoRemoto_DOCU Crea la secuencia Crea el sinónimo privado remoto de la tabla. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 51 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. los modelos de datos. Son de aplicación a todos ü 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 PRE-SCRIPT X POST-SCRIPT X CREATE PROCEDURE X * Si es un proyecto Business Objects debe estar chequeada * Si hay cargas de datos iniciales. * Si hay funciones, procedimientos o paquetes de B.D. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 52 Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 DROP PROCEDURE TABLESPACE ROLLBACK SEGMENT DATABASE SEQUENCE DROP SECUENCE VIEW CREATE VIEW DROP VIEW CREATE PROCEDURE DROP PROCEDURE PRE-SCRIPT POST-SCRIPT MATERIALIZED VIEW CREATE MATERIALIZED VIEW DROP MATERIALIZED VIEW CREATE PROCEDURE DROP PROCEDURE PRE-SCRIPT POST-SCRIPT TABLE CREATE TABLE DROP TABLE TABLE CHECK PARTITIONS PHYSICAL STORAGE PRE-SCRIPT POST-SCRIPT CREATE PROCEDURE X X X X X X X X Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 53 Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 DROP PROCEDURE CREATE SYNONYM DROP SYNONYM OVERRIDE OWNER COLUMN CHECK CONSTRAINT PHYSICAL ORDER DEFAULT VALUE OTHER OPTIONS CONSTRAINT COMMENTS QUOTE NAMES OWNER X X X X 32.2 Opciones de generación específicas para Integridad Referencial Basada en PK y FK INDEX CREATE INDEX PRIMARY KEY ALTERNATE KEY FOREIGN KEY INVERSION ENTRY PHYSICAL STORAGE PARTITIONS DROP INDEX PRIMARY KEY ALTERNATE KEY FOREIGN KEY INVERSION ENTRY OVERRIDE OWNER Se crea implícitamente con la PK X X Se deben “anular” los no deseados mediante la opción “Generate” de cada índice. X REFERENCIAL INTEGRITY Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 54 Nombre del manual 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 RI TYPE OVERRIDE RELATIONSHIP OVERRIDE GUIA DE DISEÑO CON ERWIN 4.1 X X X X X X X X 32.3 Opciones de generación específicas para Integridad Referencial Basada en Triggers INDEX CREATE INDEX PRIMARY KEY ALTERNATE KEY FOREIGN KEY INVERSION ENTRY PHYSICAL STORAGE PARTITIONS DROP INDEX PRIMARY KEY ALTERNATE KEY FOREIGN KEY X X X Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 55 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 RI TYPE OVERRIDE RELATIONSHIP OVERRIDE USER DEFINED RI TYPE OVERRIDE RELATIONSHIP OVERRIDE X X X X X X 32.4 Opciones de Generación Específicas para Integridad Referencial No Definida INDEX CREATE INDEX PRIMARY KEY ALTERNATE KEY FOREIGN KEY INVERSION ENTRY PHYSICAL STORAGE PARTITIONS X X X Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 56 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 RI TYPE OVERRIDE RELATIONSHIP OVERRIDE X X 32.5 Opciones de Generación Específicas para B.O. SCHEMA PRE-SCRIPT X * Si es un proyecto Business Objects debe estar chequeada 32.6 Opciones de Generación Específicas para DOCUMENTUM Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 57 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 RI TYPE OVERRIDE RELATIONSHIP OVERRIDE X X X TABLE CREATE TABLE DROP TABLE TABLE CHECK PARTITIONS PHYSICAL STORAGE PRE-SCRIPT POST-SCRIPT CREATE PROCEDURE DROP PROCEDURE CREATE SYNONYM DROP SYNONYM OVERRIDE OWNER X X X 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 58 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 Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 59 Nombre del manual GUIA DE DISEÑO CON ERWIN 4.1 Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 60