MANUAL de MIGRACIÓN DE MODELOS DE DATOS ERWIN 4.1 a ERWIN 7

Transcripción

1 MANUAL de MIGRACIÓN DE MODELOS DE DATOS ERWIN 4.1 a ERWIN 7 Versión 1.0 Área de Integración y Arquitectura de Aplicaciones

2 Hoja de Control Título Documento de Referencia Responsable Área de Integración y Arquitectura de Aplicaciones Versión 1.0 Fecha Versión 08/11/2012 Registro de Cambios Versión Causa del Cambio 1.0 Versión inicial del documento Responsable del Cambio Área de Integración y Arquitectura de Aplicaciones Fecha del Cambio 24/04/ de 65

3 Índice 1. INTRODUCCIÓN CUMPLIMIENTO DE LA NORMATIVA DE LOS MODELOS MIGRADOS AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS CREACIÓN DEL MODELO DE DATOS ERWIN 7 NORMALIZADO MIGRACIÓN DE LAS TABLAS Y VISTAS ACTUACIONES PREVIAS SECUENCIAS TABLAS TEMPORALES TABLAS INDICES VISTAS OBJETOS EXTERNOS TABLAS Y VISTAS EXTERNAS SINÓNIMOS REMOTOS PÚBLICOS SINÓNIMOS REMOTOS DE MODELOS DE DATOS PARA DOCUMENTUM (PRIVADOS) CARGAS DE DATOS ÁREAS DE DISEÑO MIGRACIÓN DE PROCEDIMIENTOS, FUNCIONES Y PAQUETES MIGRACIÓN DE TRIGGERS TRIGGERS DE DOCUMENTUM REVISIONES ADICIONALES REVISIÓN Y MODIFICACIÓN DE RELATIONSHIPS E INDICES REVISAR EN CAMPOS DE TABLAS LA PROPIEDAD NULL OPTION REVISAR NOMBRE DE INDICES REALIZAR COMPARACION DEL MODELO DE DATOS ERWIN CONTRA BASE DE DATOS de 65

4 1. INTRODUCCIÓN El presente documento tiene por objeto servir como guía para realizar la migración de los modelos de datos realizados con la herramienta Erwin V4, a la nueva versión de la normativa de Base de Datos de ICM que utiliza la herramienta Erwin V7. La migración no sólo contempla la actualización de la versión de la herramienta, sino una reestructuración del modelo que permita cumplir la nueva normativa de base de datos, salvo algunas normas muy concretas. Migrando los modelos a esta nueva versión de la normativa se consiguen, entre otros, los siguientes beneficios: - Posibilidad de comparar el modelo con la base de datos real: La nueva normativa establece un procedimiento de comparación del modelo Erwin V7 con la base de datos real, para ver que dicho modelo representa la realidad. - Posibilidad de solicitar instalaciones entregando el modelo Erwin V7: Con la anterior normativa y Erwin V4, la solicitud de instalación de los modelos de datos en los distintos entornos de ICM (desarrollo, validación, producción, etc.) se realizaba entregando Scripts SQL. Con la nueva versión, se entrega directamente el modelo Erwin V7. Gracias a que la nueva versión permite la comparación del modelo con la base de datos real, al final de la migración de un modelo podemos estar seguros de que el modelo representa la realidad. Así, durante la migración se pueden ir realizando sucesivas comparaciones con la base de datos para ir viendo cómo va el proceso de migración, y si se observan diferencias con la base de datos CUMPLIMIENTO DE LA NORMATIVA DE LOS MODELOS MIGRADOS La migración de un modelo en ningún caso supone modicar el modelo de datos real, lo único que se migra es el fichero ERWIN que representa dicho modelo. Si se migra un modelo siguiendo esta guía correctamente, el nuevo modelo ya cumple con la normativa actual de Base de Datos, salvo las siguientes normas, cuyo cumplimiento no se exige si se trata de modelos migrados: - GENIntReferencial: Los modelos de datos migrados no tienen que cumplir necesariamente esta norma que obliga a que los modelos se desarrollen utilizando integridad referencial. - TABObligaPK: Los modelos de datos migrados no tienen que cumplir necesariamente esta norma que obliga a que toda tabla tenga una PK única y numérica que se extrae de una secuencia. - TABNombrePK: Los modelos de datos migrados no tienen que cumplir necesariamente esta norma que define el nombre de la PK. - TABNombreIndices: Los modelos de datos migrados no tienen que cumplir necesariamente esta norma que indica la nomenclatura que deben seguir los índices del modelo AUDIENCIA OBJETIVO Este documento va dirigido a desarrolladores de modelos de datos de aplicaciones de ICM que cuentan con un modelo antiguo realizado con la versión de Erwin 4, y desean actualizarlo a la versión 7, además de cumplir la 4 de 65

5 nueva normativa de base de datos CONOCIMIENTOS PREVIOS Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre Bases de Datos, Erwin 7 y conocer perfectamente la nueva Normativa de Base de Datos. La nueva normativa de base de datos se encuentra disponible en el portal de ArquitecturaSW a través de la siguiente URL: 5 de 65

6 2. CREACIÓN DEL MODELO DE DATOS ERWIN 7 NORMALIZADO Para comenzar con la migración del modelo de ERWIN V4.1 a ERWIN 7, lo primero a realizar es crear el modelo partiendo de la plantilla disponible, y modificar dicha plantilla para adaptarla a nuestro proyecto. En los siguiente pasos se muestra cómo realizarlo. Paso 1. Obtener la plantilla de partida y copiarla a un directorio local: En el navegador ir la URL y pulsar sobre Plantilla de Partida para bajarnos a nuestro directorio de trabajo la plantilla de partida Erwin 7 Paso 2. Cambiar el nombre al fichero: Renombraremos la plantilla Erwin 7 con el siguiente formato XXXX-ERW.erwin, donde XXXX es el nombre del proyecto, según se indica en la normativa. En el ejemplo utilizado en este documento, trabajaremos con un nombre de proyecto denominado USU: Paso 3. Indicar el Nombre del Modelo de datos y el Author: 6 de 65

7 Ir a la opción de menú Model -> Model Properties, en la pestaña General, modificar los datos del recuadro Model Info para indicar: Name: Model de datos de la aplicación XXXX (sustituir XXXX por el código de Aplicación) Author: Autor del modelo Paso 4. Renombrar los tablespaces: Ir a la opción de menú Database -> Tablespaces Debemos renombrar con el botón Rename los tablespaces sustituyendo XXXX por nuestro código de Aplicación 7 de 65

8 NOTA: Sólo para Business Objects Recordar que según la normativa, los tablespaces para modelos de datos de Business Objects los tablespaces deben nombrarse de la siguiente forma: - TBSBLOB_DW_XXXX_100: Tablespace que se asignará a las columnas de tipo BLOB o CLOB - TBSDAT_DW_XXXX_100: Tablespace para las tablas - TBSIND_DW_XXXX_100: Tablespace para los índices Paso 5. Renombrar el Subject Area 90 - Área de Creación del Esquema DBA_XXXX Ir a la opción de menú Model -> Subject Areas, y renombrar el Subject Area 90 - Área de Creación del Esquema DBA_XXXX, sustityendo XXXX por el código de Aplicación. NOTA: Sólo para Business Objects Según la normativa de modelos de datos para business objects, el esquema debe denominarse DBA_DW_XXXX, por lo tanto para modelos de datos de esta tecnología se sustituirá DBA_XXXX por DBA_DW_XXXX, siendo XXXX el código de aplicación. Paso 6. (Sólo para modelos de Business Objects): Cambiar el valor de la UDP DESTINO GRANT: NOTA Este paso sólo se realizará para modelos de datos que utilicen la tecnología Business Objects. Para el resto de modelos se saltará este paso y se procederá con el siguiente Recordar que según la normativa la modificación de UDPs se debe realizar dos veces, en la petaña UDPs de Model Properties, y en UDP Dictionary. Si no se hace, se producirán comportamientos inexperados. 8 de 65

9 En el valor de la UDP DESTINO GRANT escribiremos el nombre del ROL según se indica en la normativa (XXXX_DW_ALL, donde XXXX es el código de aplicación): Paso 7. (Sólo para modelos de Business Objects): Crear el Script de creación del ROL: En los proyectos de Business Objects no se realiza un GRANT TO PUBLIC para todos los objetos del modelo. En lugar de esto, se utiliza un fichero SQL que crea un rol denominado XXXX_ALL_BO que permite el acceso a todos los objetos del esquema DBA_DW_XXXX, y se realiza un GRANT de cada objeto al rol. El script SQL tiene que incluirse en la carpeta carga_inicial de la entrega, en un fichero denominado 00_PRE_CREACION.SQL. En la plantilla de partida viene un Script de ejemplo para creación de este rol. Por tanto, si se trata de un modelo en esta tecnología, se deberá de abrir dicho fichero, y dejar el siguiente contenido (sustituir XXXX por el código de aplicación): DROP ROLE XXXX_DW_ALL; CREATE ROLE XXXX_DW_ALL; A continuación se muestran las normas a aplicar para la creación y asignación de roles en los proyectos de Business Objects. 9 de 65

10 3. MIGRACIÓN DE LAS TABLAS Y VISTAS 3.1. ACTUACIONES PREVIAS Una vez que tenemos el fichero modificado para adaptarlo a nuestro proyecto, lo primero que debemos hacer es migrar las tablas y vistas desde el modelo de ERWIN 4 al modelo de ERWIN 7. Para ello, trabajaremos con los dos modelos abiertos simultáneamente desde ERWIN 7, según se indica en los siguientes pasos: Paso 8. Arrancar la herramienta ERWIN 7: Arrancar la herramienta Erwin 7 en: Inicio -> Todos los programas Erwin Erwin Data Modeler 7.3 Paso 9. Abrir el modelo de Erwin 7 XXXX-ERW.erwin (en adelante MODELO NUEVO): Ir a la opción de menú File -> Open y seleccionar el Modelo NUEVO (fichero Erwin 7 Erwin 7 XXXX-ERW.erwin) 10 de 65

11 En la parte infierior izquierda de de la herramietna Erwin 7 pulsar sobre la pestaña Subject Area y en la parte superior izquierda en la listade valores Seleccionar Subect Area: 01 - Área General del Modelo de Datos : 11 de 65

12 Paso 10. Abrimos desde Erwin 7 el modelo de datos Erwin 4.1 que queremos migrar (en adelante MODELO ANTIGUO): Ir a la opción de menú File -> Open y seleccionar el Modelo ANTIGUO (fichero Erwin 4.1 XXXX.er1) En la lista de valores Tipo seleccionar CA ERwin 4.1 x (*.er1) para poder visualizar el Modelo Antiguo 12 de 65

13 Al abrir el modelo de datos Erwin 4.1, aparece un mensaje que nos indica que el erwin que estamos abriendo no pertenece a la versión 7 y si queremos cambiar de Versión (en el ejemplo mostrado el fichero con el MODELO ANTIGUO se llama USU.er1): Pulsar sobre SI, y aparece una ventana con el resultado del cambio a versión 7 13 de 65

14 Pulsamos sobre Close y aparece la siguiente ventana indicándonos que ya tenemos abierto y disponible en versión 7 el fichero USU.erwin, además nos indica que el fichero erwin 4.1 USU.er1 no ha sido modificado: Pulsamos sobre Aceptar. Paso 11. Guardar el fichero USU.erwin: Pulsar la opción de menú: File -> Save as Guardamos en la carpeta en la que estamos realizando la migración el fichero USU.erwin, éste fichero (ahora en erwin 7) contiene los objetos que pasaremos posteriormente a nuestro modelo de datos Erwin 7 normalizado USU- ERW.erwin 14 de 65

15 NOTA Notar que existen en este momento tres ficheros, de los cuáles sólo trabajaremos con los dos últimos: 1) USU.er1: Fichero original, que contiene el modelo en ERWIN V4.1. No lo usaremos más de aquí en adelante, salvo para alguna consulta concreta. 2) USU.erwin: Fichero que contiene el modelo en ERWIN V4.1 automáticamente convertido a ERWIN 7. Utilizaremos este fichero como punto de partida para la migración. 3) USU-ERW.erwin: Fichero que contendrá el modelo final, y que hemos creado partiendo de la plantilla de ERWIN 7. De ahora en adelante mantendremos los dos modelos (USU.erwin y USU-ERW.erwin) abiertos en la herramienta ERWIN 7, e iremos migrando objetos de uno al otro. Paso 12. Copiar todos los objetos visuales del modelo USU.erwin al USU-ERW.erwin: En este momento, disponemos en una única sesión de la herramienta Erwin 7 de los dos modelos abiertos (el modelo Antiguo y el Modelo Nuevo). Posicionarse en el Modelo Antiguo, para ello seleccionar la opción del menú Window -> XXXX.erwin Ejecutar la opción de menú Edit -> Select All Ejecutar la opción de menú Edit -> Copy Group 15 de 65

16 Posicionarse en el Modelo Nuevo, para ello seleccionar la opción del menú Window -> XXXX-ERW.erwin Ejecutar la opción de menú Edit -> Paste Si tenemos en nuestro Modelo de datos campos de diferentes tablas con el mismo nombre nos aparecerán varios mensajes como el siguiente: 16 de 65

17 Para todos los mensajes que aparezcan de éste tipo, Pulsar sobre el botón OK. Ahora tenemos en nuestro Modelo Nuevo todas las Tablas y Vistas que hemos copiado y pegado desde el Modelo Antiguo: A partir de este momento trabajaremos la mayor parte del tiempo con el Modelo Nuevo, por lo que procederemos a cerrar el Modelo Antiguo para que no se produzcan confusiones. Para ello ejecutar la opción de menú Window -> XXXX.erwin para activar el modelo antiguo: Cerrar el Modelo Antiguo, ejecutando la opción de menú: File -> Close NOTA Para evitar posibles pérdidas de datos, se recomienda grabar frecuentemente el Modelo Nuevo con todas las modificaciones que se van realizando SECUENCIAS Paso 13. Migración de Secuencias 17 de 65

18 Debido a que en Erwni V4 no existía el objeto Sequence, la forma de dar de alta las secuencias era crear un objeto tabla vacío (sin campos) y con un Script Template asociado que es el que llevaba la definición de la secuencia. Se pueden reconocer estas tablas porque no tienen campos, y siguen la nomenclatura XXXX_SEC_[NOMBRE]: En la nueva normativa de base de datos ya se utilizan los objetos Sequence de Erwin V7. Por tanto, el proceso de migración de Secuencias va a consister en dar de alta las Secuencias como nuevos objetos de tipo Sequence, utilizando la definición de la secuencia que proviene del modelo anterior. Para cada secuencia que exista en nuestro Modelo Antiguo realizar las siguientes acciones: Abrir el script template que contenía la secuencia antigua, y anotar la información de la secuencia: 18 de 65

19 Pulsar la opción de menú: Database -> Sequences Y Pulsar sobre el botón New, para dar de alta el nombre de la Secuencia. Rellenar el campo Owner: indicar el esquema de base de datos Propietario del objeto En la pestaña General configurar los diferentes campos con los valores correspondientes de la secuencia, éstos valores podemos localizarlos en el objeto tabla (original) de la Secuencia en el Script Template asociado. 19 de 65

20 En la pestaña Comment añadir los Comentarios que debe tener la secuencia. Nota: Si la tabla vacía que representaba la secuencia en el modelo original ya tenía comentarios, podemos obtenerlos de ella. En la pestaña Synonym pulsar sobre el botón NEW e indicar el nombre del Sinónimo de la Secuencia (que normalmente coincidirá con el nombre de la Secuencia). Pulsar sobre el botón OK 20 de 65

21 NOTA: Sólo para Documentum Según la normativa de modelos de datos para documentum, no se deben asignar sinónimos públicos a las secuencias de modelos en esta tecnología. Por tanto este punto se omitirá si se trata de un modelo de Documentum. Seleccionar (pulsar) el nombre del Sinónimo y chequear los check: Create or Replace y Public. 21 de 65

22 Ya hemos definido la Secuencia, pulsar sobre el botón Close Como ya hemos creado la secuencia, la tabla vacía original que representaba la sencuencia debe ser borrada del Modelo de Datos. Para ello seleccionar la tabla de la Secuencia, pulsar la tecla Supr, a continuación aparecerá una pantalla indicándonos, si borramos el objeto solamente del Subjec Area o del Modelo de datos Pulsar sobe la opción Delete them from the entire model y pulsar sobre el botón OK Nota: Más adelante borraremos los Script Templates antiguos que ya no utilizaremos. 22 de 65

23 3.3. TABLAS TEMPORALES Paso 14. Migración de Tablas Temporales Debido a que en Erwni V4 no existía el objeto Tabla Temporal, la forma de dar de alta las tablas temporales era crear un objeto tabla vacío (sin campos) con un Script Template asociado que es el que lleva la definición de la tabla temporal. El proceso de migración de tablas temporales va a consistir en dar de alta las tablas temporales como un objeto Tabla Temporal, partiendo de la definición del modelo antiguo. Para cada tabla temporal que exista en nuestro modelo realizar las siguientes acciones: Abrir el Script Template asociado a la tabla antigua. Crear una tabla nueva, en la botonera superior Pulsar el botón de creación Independent table, A continuación pulsar en la zona del subject area donde se desea crear la tabla 23 de 65

24 Pulsar sobre la nueva tabla con el botón derecho del ratón y Pulsar la opción Tables Rellenar el campo Name con el nombre de la tabla temporal, así como el Owner: 24 de 65

25 En la pestaña Comment añadir los Comentarios que debe tener la tabla temporal. Nota: Si la tabla vacía que representaba la tabla temporal en el modelo original ya tenía comentarios, podemos obtenerlos de ella. En la pestaña General chequear chequear Global Temporary y chequear las opciones correspondientes a la tabla temporal (recordar que la definición de la tabla temporal la teníamos anotada, se encontraba en el Script Template que abrimos anteriormente). 25 de 65

26 Pulsar sobre Close para cerrar la definición de la tabla y poder proceder a crear las columnas, índices, etc. Pulsar sobre la nueva tabla temporal con el botón derecho del ratón y: 1) Pulsar la opción Columns y definir los campos de la tabla 2) Pulsar la opción Indexes y definir los índices. 3) Pulsar la opción Triggers para definir triggers En este momento ya habremos creado la tabla temporal, por lo que el objeto tabla original antiguo debe ser borrado totalmente del Modelo de datos. Para ello seleccionar el objteo tabla original antiguo de la tabla temporal, pulsar la tecla Supr, a continuación aparecerá una pantalla indicándonos, si borramos el objeto solamente del Subjec Area o del Modelo de datos: 26 de 65

27 Pulsar sobe la opción Delete them from the entire model y pulsar sobre el botón OK 3.4. TABLAS Paso 15. Asignar a las tablas el Owner, el Sinónimo Público y los Tablespaces de Datos y Lob Pulsar la opción de menú Model -> Tables Para cada tabla que exista en nuestro modelo realizar las siguientes acciones: Seleccionar tabla de la lista desplegable 27 de 65

28 Escribir el esquema propietario del objeto en el campo Owner En la pestaña Synonym pulsar sobre el botón NEW e indicar el nombre del Sinónimo de la Tabla (normalmente coincidirá con el nombre de la Tabla). Pulsar sobre el botón OK. Seleccionar (pulsar) el nombre del Sinónimo y chequear los check: Create or Replace y Public 28 de 65

29 Pulsar la pestaña General y Pulsar el check Physical Properties Pulsar el botón Storage Properties y seleccionar el tablespace de datos correspondiente TBSDAT_XXXX_ de 65

30 Pulsar el botón OK Si la tabla contiene campos CLOB o BLOB: Los contenidos de las columnas de tipo LOB (BLOB y CLOB) se almacenan en Tablespaces específicos para estas columnas, separados del resto de los datos de la tabla. Si la tabla incluye columnas de tipo LOB (excepto campos lob de tablas temporales que no se definen tablespace lob), se debe modificar la pestaña LOB Storage según se muestra en la siguiente figura: 1) Seleccionar en Column la columna Lob 30 de 65

31 2) Pulsar sobre la opción Parameters de la columna de tipo LOB, y ahí seleccionar el tablespace específico para campos LOB (TBSBLOB_XXXX_100), y marcando las opciones que se muestran a continuación: CHUNK: 4096 Retain old versión type -> PCTVERSION -> 10 Cache -> NO-CACHE -> Logging -> LOGGING 3) Pulsar el botón Close 3.5. INDICES Paso 16. Comprobar si está activada la casilla Show Fk Indexes Si no está activada la casilla Show Fk Indexes, Activarla para que aparezcan los índices asociados a RelationShips 31 de 65

32 Paso 17. Asignar a todos los índices de tablas de nuestro modelo el tablespaces de índices Pulsar la opción de menú Model -> Indexes -> Table Para cada tabla que exista en nuestro modelo realizar las siguientes acciones: Seleccionar la tabla de la lista desplegable 32 de 65

33 Seleccionar tabla de la lista desplegable Una vez seleccionada la tabla realizaremos las siguientes acciones para cada índice de la tabla: o Seleccionar el índice y pulsar la pestaña Physical o Pulsar el botón Storage Properties y seleccionar en la lista desplegable TABLESPACE el tablespace de índices TBSIND_XXXX_ de 65

34 o Pulsar el botón Close 3.6. VISTAS Paso 18. Asignar a todas las vistas de nuestro modelo el Owner, el sinónimo público y comprobar sintaxis Pulsar la opción de menú Model -> Database Views Para cada vista que exista en nuestro modelo realizar las siguientes acciones: Seleccionar la vista de la lista desplegable Escribir el esquema propietario del objeto en el campo Owner Checkear la opción Create Or Replace 34 de 65

35 En la pestaña Synonym pulsar sobre el botón NEW e indicar el nombre del Sinónimo de la Vista (normalmente coincidirá con el nombre de la Vista). Pulsar sobre el botón OK. Seleccionar (pulsar) el nombre del Sinónimo y chequear los check: Create or Replace y Public 35 de 65

36 Pulsar en la pestataña User Defined SQL Si está chequeado el check User-Defined SQL, comprobar, como se indica en la normativa que no se debe incluir el ; al final de la definición de la vista. 36 de 65

37 Pulsar sobre el botón Close 37 de 65

38 4. OBJETOS EXTERNOS 4.1. TABLAS Y VISTAS EXTERNAS Si existen tablas o vistas externas, que no pertenezcan al esquema principal del proyecto, deberemos mostrar el objeto en color amarillo. Para ello, en la opción Object Font Color - Fill Color indicaremos el color amarillo, según se muestra en la siguiente figura: Recordar que las tablas o vistas externas siempre llevan el check Generate desactivado SINÓNIMOS REMOTOS PÚBLICOS Debido a que en Erwni V4 no existía el objeto Synonym, la forma de dar de alta los sinónimos remotos era crear una tabla o vista que tiene el nombre del sinónimo remoto (con la opción Generate desactivada) y que tiene asignado un Script template con la definición del sinónimo remoto. Si se trataba de un sinónimo remoto para un objeto de otro tipo (procedure, function, package) se creaba un Script template a nivel de modelo con la definición del sinónimo remoto. En la nueva normativa de base de datos ya se pueden crear sinónimos remotos. Por tanto, el proceso de migración va a consistir en dar de alta los sinónimos remotos partiendo de la definición de los Script Templates en el modelo original. Para ello, para cada sinónimo remoto que exista en nuestro Modelo Antiguo realizar las siguientes acciones: (Sólo para tablas y vistas): si el objeto remoto es un objeto tipo tabla o vista que representará el objeto destino del Sinónimo, realizar las siguientes acciones: 1) Desactivar la casilla Generate del objeto, para que no se trate de crear este objeto remoto. 2) Activar la casilla de Create or Replace 3) En la opción Object Font Color - Fill Color indicar el color rojo, para poder identificar en el modelo de forma visual el sinónimo remoto, según se muestra en la siguiente figura: Abrir el script template que contenía el sinónimo remoto antiguo, y anotar la información del sinónimo remoto: 38 de 65

39 Pulsar la opción de menú: Database -> Synonyms Y Pulsar sobre el botón New, para dar de alta el nombre del sinónimo. Pulsar el botón OK 39 de 65

40 Activar el check Create or Replace, Pulsar la pestaña General y: Rellenar el campo Object Name: Indicar el nombre del objeto Rellenar el campo Object Owner: Indicar el esquema propietario del objeto Rellenar el campo DB Link: Seleccionar un dblink de la lista. Si el sinónimo apunta a un db-link que no está definido en el modelo ERWIN, deberá pulsarse sobre el recuadro a la derecha de la selección del db-link para definir el dblink que se utilizará. En la pestaña Comment añadir los Comentarios que debe tener el sinónimo remoto: Si la tabla vacía que representaba la secuencia en el modelo original ya tenía comentarios, podemos obtenerlos de ella. 40 de 65

41 Ya hemos definido el sinónimo remoto, pulsar sobre el botón Close Paso 19. Borrar Todos los Script Template Todos los Script Template del modelo deben borrarse, ya que no serán necesarios con la nueva normativa de base de datos. Para ello, seleccionamos los Script Template con el botón derecho y pulsamos sobre Delete : Una vez borrados, no debe haber ningún Script Template en el modelo: 4.3. SINÓNIMOS REMOTOS DE MODELOS DE DATOS PARA DOCUMENTUM (PRIVADOS) En modelos de datos de Documentum, 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. Su creación se realizará según la normativa para Sinónimos Remotos, pero creando sinónimos privados y rellenando el Object Owner. Para cada tabla externa en modelos de Documentum, verificaremos que la tabla tiene la opción de generate a 41 de 65

42 false, y la creación en la pantalla de synonyms del sinonimo remoto Privado con el Object Owner relleno: 42 de 65

43 5. CARGAS DE DATOS En Erwin V7 Las cargas de datos iniciales no se incluyen dentro del modelo ERWIN, se incluyen como ficheros SQL dentro del directorio carga_inicial de la entrega. En modelos antiguos, pueden encontrarse cargas de datos en ficheros (igual que en los nuevos), pero también es posible que aparezcan como Script Templates dentro del propio modelo. Al copiar los objetos del modelo de datos antiguo al nuevo, no se han copiado los Script Template de cargas de datos. Debemos abrir el Modelo Erwin antiguo, y para cada uno de los Script Templates de carga de datos que aparecen crear un fichero con extensión.sql en el directorio carga_inicial del nuevo modelo. Nota: Para crear un script de carga de datos iniciales, se debe realizar conforme a las normas de carga de datos de la Normativa de Erwin 7 (nomenclatura, contenido, etc.). 43 de 65

44 6. ÁREAS DE DISEÑO Para visualizar las Áreas de diseño, pulsar sobre la opción de menú Model -> Subject Areas En el área de diseño 01 - Área General del Modelo de Datos ya tenemos todas las tablas y vistas de nuestro proyecto (incluyendo objetos externos pertenecientes a otros esquemas de bases de datos). Paso 20. Subject Área 90 - Área de Creación del Esquema DBA_XXXX En este subject área hay que incluir uno a uno todos los objetos del esquema de nuestro proyecto DBA_XXXX. No se incluirán tablas externas de otros esquemas. Para incluir los objetos: Abrir el Subject Área seleccionándolo en el menú desplegable: Pulsar en la pestaña inferior Model para ver todos los objetos del modelo: 44 de 65

45 Arrastrar UNA A UNA las tablas y vistas que deseamos incluir en el Subject Área: Paso 21. Subject Área 02 - Área de Definición de Jobs Si existieran jobs de bases de datos en nuestro proyecto debemos incorporarlos en ésta área de diseño tal como se indica en la normativa. Si no existen jobs de bases de datos eliminaremos éste subjectarea, pulsando en el nombre del Subject Área y seleccionando la opción Delete. Paso 22. Subject Área DOCUMENTUM Recordar que en modelos de datos para aplicaciones de Documentum, además de las normas comunes sobre áreas de diseño, se debe añadir un nuevo área de diseño con el nombre de DOCUMENTUM, que contendrá aquellos objetos oracle que deben crearse en la base de datos de documentum. Este Subject Área sólo debe existir un Subject Área en proyectos Documentum. Para el resto de proyectos éste área de diseño debe borrarse, pulsando en el nombre del Subject Área y seleccionando la opción Delete. Paso 23. Subject Área Área de diseño LOPD 45 de 65

46 Si el modelo incluye tablas que contengan datos personales susceptibles de ser tratados de forma especial según la LOPD, se incluirá un área de diseño específica que contenga todos los objetos afectados. El nombre de esta área será: 80 Área de Datos Personales Protegidos. Se incluirán en este Subject Área los objetos uno a uno según se ha indicado en apartados anteriores. Paso 24. Otras Áreas de diseño parciales existentes Si en nuestro modelo de datos erwin 4 existían áreas de diseño parciales conceptuales con algunos de los objetos del esquema, debemos crear éstas áreas de diseño parciales conceptuales con un nombre con el siguiente formato: XX Descripción del área de diseño conceptual. Si no es necesario el uso de areas de diseño parciales, se eliminarán los dos ejemplos que vienen en la plantilla: 06 - Área de Diseño Parcial 2 y 15 - Área de Diseño Parcial n Para Crear otra área de diseño ya existente Pulsar sobre el botón New e incluir el nombre del área de diseño Pulsar el botón OK. Una vez creadas éstas áreas de diseño conceptuales iremos añadiendo uno a uno los objetos que deban estar incluidos en ellas. Se incluirán en este Subject Área los objetos uno a uno según se ha indicado en apartados anteriores. 7. MIGRACIÓN DE PROCEDIMIENTOS, FUNCIONES Y PAQUETES Se deben dar de alta en el modelo de datos erwin todos los procedimientos, funciones y paquetes que existen en el modelo de datos erwin 4.1, asi como aquellos que no encontrándose en el modelo de datos erwin 4.1, están en ficheros sql, se copiará a nuestro modelo de datos normalizado erwin 7 Paso 25. Añadir Procedimientos Realizar las siguientes acciones para cada procedimiento: 46 de 65

47 Pulsar la opción de menú Database -> Stored Procedures -> Model Level Pulsar el botón New... dar de alta el nombre del procedimiento Pulsar el botón OK Escribir el esquema propietario del objeto en el campo Owner Chequear la opción Create or Replace En la pestaña Comment añadir los Comentarios que debe tener el procedimiento 47 de 65

48 En la pestaña Code añadir el código del procedimiento realizando copy/paste desde el modelo anterior (o en el fichero SQL si estaba en uno). Si existe al final del código el carácter / de finalización de script sql se debe borrar. Si existen al final del código sentencias de creación de sinónimo público y grant a este sinónimo, se deben borrar. En la primera línea del código de la cabecera debe sustiuirse lo siguiente: o Antes: CREATE OR REPLACE PROCEDURE NOMBRE_PROCEDIMIENTO o Después: CREATE %CreateOrReplace PROCEDURE %ProcedureOwner(.)%TemplateName 48 de 65

49 En la pestaña Synonym pulsar sobre el botón New e indicar el nombre del Sinónimo del procedimiento (normalmente coincidirá con el nombre del procedimiento). Pulsar OK. Seleccionar (pulsar) el nombre del Sinónimo y chequear los check: Create or Replace y Public Pulsar sobre el botón Close. Paso 26. Añadir Funciones Realizar las siguientes acciones para cada función: 49 de 65

50 Pulsar la opción de menú Database -> Functions -> Model Level Pulsar el botón New.. dar de alta el nombre de la función Pulsar el botón OK Escribir el esquema propietario del objeto en el campo Owner Chequear la opción Create or Replace En la pestaña Comment añadir los Comentarios que debe tener la función 50 de 65

51 En la pestaña Code añadir el código de la función realizando copy/paste desde el modelo anterior (o en el fichero SQL si estaba en uno). Si existe al final del código el carácter / de finalización de script sql se debe borrar. Si existen al final del código sentencias de creación de sinónimo público y grant a este sinónimo, se deben borrar. En la primera línea del código de la cabecera debe sustiuirse lo siguiente: o Antes: CREATE OR REPLACE FUNCTION NOMBRE_FUNCION o Después: CREATE %CreateOrReplace FUNCTION %ProcedureOwner(.)%TemplateName 51 de 65

52 En la pestaña Synonym pulsar sobre el botón NEW e indicar el nombre del Sinónimo de la función (normalmente coincidirá con el nombre de la función). Pulsar sobre el botón OK Seleccionar (pulsar) el nombre del Sinónimo y chequear los check: Create or Replace y Public Pulsar sobre el botón Close. 52 de 65

53 Paso 27. Añadir paquetes Realizar las siguientes acciones para cada paquete: Pulsar la opción de menú Database -> Package Pulsar el botón New.. dar de alta el nombre del package Pulsar el botón OK Escribir el esquema propietario del objeto en el campo Owner Chequear la opción Create or Replace En la pestaña Comment añadir los Comentarios que debe tener el package 53 de 65

54 En la pestaña Specification añadir la cabecera del package realizando copy/paste Si existe al final del código el carácter / de finalización de script sql se debe borrar Si existen al final del código sentencias de creación de sinónimo público y grant a este sinónimo, se deben borrar. En la primera línea del código de la cabecera debe sustiuirse lo siguiente: o Antes: CREATE OR REPLACE PACKAGE NOMBRE_PAQUETE o Después: CREATE %CreateOrReplace PACKAGE %ProcedureOwner(.)%TemplateName En la pestaña Body añadir el cuerpo del package realizando copy/paste Si existe al final del código el carácter / de finalización de script sql se debe borrar Si existen al final del código sentencias de creación de sinónimo público y grant a este sinónimo, se deben borrar. En la primera línea del código de la cabecera debe sustiuirse: o Antes: CREATE OR REPLACE PACKAGE BODY NOMBRE_PAQUETE o Después: CREATE %CreateOrReplace PACKAGE BODY %ProcedureOwner(.)%TemplateName 54 de 65

55 En la pestaña Synonym pulsar sobre el botón NEW e indicar el nombre del Sinónimo del package, normalmente coincidirá con el nombre del package. Pulsar sobre el botón OK Seleccionar (pulsar) el nombre del Sinónimo y chequear los check: Create or Replace y Public 55 de 65

56 Pulsar sobre el botón Close. Paso 28. Comprobar el orden de procedimientos, funciones y paquetes Pulsar en cualquiera de éstas tres opciones de menú: Database -> Stored Procedures -> Model Level Database -> Functions -> Model Level Database -> Packages Pulsar la pestaña Object Creatior Order Comprobar y modificar si es necesario, el orden de creación de procedimientos, funciones y paquetes para su correcta compilación. 56 de 65

57 57 de 65

58 8. MIGRACIÓN DE TRIGGERS Al pegar los objetos del modelo original al migrado, ya se han traspasado los triggers. Sin embargo es necesario realizar una serie de pasos adicionales para normalizarlos. La migración de triggers normalizados consiste en rellenar el campo Owner y activar la opción Create or Replace, así como incluir la variable %TriggerName en la pestaña Code. Recordar que el nombre del objeto trigger debe coincidir con el nombre del trigger existente en base de datos y que las opciones de la pestaña General deben corresponder con la realidad Para cada trigger que exista en nuestro Modelo realizar las siguientes acciones: Rellenar el campo Object Owner: Indicar el esquema propietario del objeto Chequear el check Create or Replace Pulsar la pestaña Code. Si el nombre del Trigger aparece con un nombre fijo o con una variable distinta a %TriggerName sustituirlo por ésta variable y si no están incluidas las Variables de definición del trigger correpondientes a la pestaña General incluirlas. El código del comienzo del trigger debe quedar así: create or replace trigger %TriggerName %Fire %Actions(" or ") on %TableName %RefClause %Scope 58 de 65

59 Pulsar el botón Close 8.1. TRIGGERS DE DOCUMENTUM Para definir triggers en modelos de datos para aplicaciones de Documentum, debe crearse una tabla sin campos y, sin sinónimo público cuyo nombre debe seguir la siguiente nomenclatura: [XXXX]_TD_[DESCRIPCIÓN]_S Donde [XXXX]_TD_[DESCRIPCIÓN]_S es el nombre del tipo documental sobre el que se va a definir el trigger. 59 de 65

60 9. REVISIONES ADICIONALES 9.1. REVISIÓN Y MODIFICACIÓN DE RELATIONSHIPS E INDICES NOTA Este paso sólo se realizará para modelos de datos que NO tengan integridad referencial (Primary Keys y Foreign Keys) física en base de datos, sólo en el modelo ERWIN. Revisión y modificación de RelationShips e índices SOLO Para modelos de datos que no tienen Foreign keys y Primary Keys físicas creadas en base de datos, se debe: Desactivar (Deschequear) el check generate en todas las RelationShips Desactivar (deschequear) en índices de tipo pk el check Generate as Constraint Para ello seguiremos los siguientes pasos: Paso 29. Desactivar RelationShips Pulsar docle click sobre cualquier RelationShip del modelo de datos par abrir el cuadro de diálogo de RelationShips Realizar las siguientes acciones para todas las relationships del modelo de datos: Seleccionar una RelationShip de la lista desplegable Deschequear el check Generate 60 de 65

61 Paso 30. Desactivar en índices de tipo pk el check Generate as Constraint Pulsar la opción de menú Model -> Indexes > Table Realizaremos las siguientes acciones para cada tabla: Seleccionar la tabla en la lista desplegable Tables Pulsar sobre el índice de tipo pk y deschequear el check Generate as Constraint (situado en la parte inferior): 61 de 65

62 9.2. REVISAR EN CAMPOS DE TABLAS LA PROPIEDAD NULL OPTION Al realizar la operación de Copy Group / Paste de los objetos visuales (tablas y vistas) se ha comprobado que en en los campos de tabla la propiedad Null Option a veces se pierde, no la copia correctamente. Se deberá revisar la propiedad Null Option de los campos de todas las tablas REVISAR NOMBRE DE INDICES Si existen índices de tablas en el modelo de datos erwin 4.1 que tenian el nombre correspondiente a la normativa de erwin 4.1, es decir comienzan por X, (Ejemplo: XPK[Nombre_de_tabla], XAKnn[NombreTabla], XIEnn[NombreTabla], XGRnn[NombreTabla], ), en erwin 7 al realizar la operación de Copy Group / Paste de los objetos visuales (tablas y vistas) son renombrados automáticamente suprimiendo la X. Es necesario comprobar aquellos índices que se han renombrado automáticamente en la operación de Copy Group / Paste para renombrarlos y que coincidan con el nombre de índice original del modelo de datos Erwin 4.1. Paso 31. Renombrar nombre de índices que han sido cambiados en la operación de Copy Group / Paste Realizaremos las siguientes acciones para todos los índices de cada tabla que se han renombrado automáticamente en la operación Copy Group / Paste. Primero pulsaremos la opción de menú Model -> Indexes > Table. Y ahí, para cada tabla y cada índice: Seleccionar la tabla en la lista desplegable Tables 62 de 65

63 Pulsar sobre el índice a renombrar Pulsar el botón Rename y Renombrar añadiendo una X en el inicio del nombre (o como sea necesario para que corresponda al nombre original). 63 de 65

64 Pulsar el botón OK 64 de 65

65 10. REALIZAR COMPARACION DEL MODELO DE DATOS ERWIN CONTRA BASE DE DATOS Recordar que según se va migrando el modelo de datos, se deben ir realizando comparaciones con la base de datos real para ver que no se esté omitiendo ningún objeto. Para comparar el modelo contra la base de datos real debe seguirse el apartado de la normativa de base de datos COMPARACIÓN DEL MODELO CON LA BASE DE DATOS REAL. Al final de la migración de un modelo, la comparación no debe dar ninguna diferencia. 65 de 65