Lista de verificación BD (Especificación)

Transcripción

1 Lista de verificación BD (Especificación) Dirección de Centros de Competencia Tecnológica Área de Calidad y Seguridad de Aplicaciones y Sistemas Unidad de Calidad y Certificación

2 Código Descripción GEN 1 Nomenclatura objetos Todos los objetos de la base de datos tienen una nomenclatura estandar definida por el Área de Integración y Arquitectura de Aplicaciones. Sólo hay una excepción, los Sinónimos Remotos, que tienen una nomenclatura recomendada pero no obligatoria ( XXXX_<<NombreDescriptivo>>_LINK). 2 Diferencias entre modelo y esquema Los objetos incluidos en el modelo ERwin y los definidos en el esquema de la base de datos deben coincidir exactamente. La existencia de diferencia que no han sido aplicadas las modificaciones del modelo ERwin al esquema de la base de datos datos, o bien, el no tener al día el fichero ERwin con las actualizaciones de la base de datos. Cualquiera de las dos opciones es errónea e inadmisible. 3 Tablas sin clave primaria Por definición toda tabla debe tener una clave primaria, o indice primario. No nos referimos a tener definida la constraint de Primary Key, sino un identificado único de la fila. El no tenerlo es un error de diseño. En principio se puede admitir que alguna tabla no tenga, pero el que un gran número de tablas no tenga clave se considera un error. 4 Nombre de objetos > 30 caracteres No se permite crear objetos de longitud superior a 30 caracteres. ERwin debe tener definidos los límites de los objetos a nivel de opciones generales del modelo. 5 Errores sintácticos SQL Todos los errores SQL detectados en la instalación al crear o intentar crear objetos de base de datos deben ser adjuntados al informe de validación de la entrega. Estor errores se referiran a errores de escritura de sentencias de los comandos de SQL, así como errores de programación de paquetes, etc. 6 Tablas, Vistas y Secuencias con "post-script", "grant" y sinónimo La seguridad de las aplicaciones en ICM no se realiza con la aplicación de permisos específicos a los objetos de base de datos, mediante roles y grants. La seguridad se basa en el código de las aplicaciones, por tanto, se dan permisos totales sobre todos los objetos de base de datos. Por todo lo anterior, todos los objetos del modelo llevarán un post-script con la asignación de permisos y la definición de un sinónimo publico, según se indica en la documentación de ICM. 7 Versión de Oracle modelo es 9.x Por convenio todos los modelos estregados deben de tener configurado el gestor de base de datos a: Oracle Version 9.x 8 Uso catálogos ICM de carácter general Dado que ICM dispone de catálogos de carácter general (provincias, municipios, distritos, estados civiles, etc. ) deberán emplearse estos siempre que sea necesario, evitando duplicar innecesariamente datos ya existentes en ICM. Estamos a la espera de la publicación de los catálogos oficiales de ICM. 9 No se ha entregado un modelo de datos en formato ERwin. Para la creación de un esquema de base de datos en las instalaciones de ICM se requiere como requisito la presentación del modelo de datos en un archivo en formato ERwin Vistas definidas por el usuario Debemos comprobar que las vistas definidas por el usuario no "muestran" en el tapiz de diseño columnas. Las columnas sólo figurarán en el "interior", es decir, en el area de definición de la vista. Además, no debe incluirse un ';' al final de la definición de la vista, pues ERwin lo incluye automaticamente al generar el script. 11 Elementos no utilizados en el modelo Los elementos no utilizados en la confección del modelo deben ser eliminados para mayor claridad y Página: 2

3 para evitar confusiones. 12 Asignación "post-script" indebida Errores en la asignación de post-scripts a los objetos. Atendiendo a las normas de diseño ERwin se repasan la asignación de script controlando que no se haya hecho una asignación incongruente de post-script, como por ejemplo asignar un post-script de una secuencia a una tabla que no es o un post-script de un BLOB a una tabla que no tiene columnas BLOB. 13 Utilización objetos no permitidos Verificar que no se están utilizando objetos no permitidos y/o raros (p.e. VARRAY). 14 Existen tablas duplicadas en el modelo de datos. No se permite tener tablas duplicadas en el modelo de datos. Esta situación suele producirse por un desconocimiento de la herramienta ERwin por parte del diseñador, que en vez de incluir en un área de diseño una tabla, la copia de un área a otra. Sin saber que esa acción duplica el objeto, dentro del modelo de datos, lo que producira errores en la creación del esquema en ela base de datos. 15 Accesos no documentados a objetos otros esquemas. No se permite el acceso a esquemas diferentes al propio, a menos que se indique previamente en la ficha de entrega. En el caso de acceder a datos protegidos de otros esquemas, deberá declararse el uso del correspondiente fichero protegido. 16 Uso de procedimientos de carácter genérico de ICM. Dado que ICM dispone de procedimientos y funciones de carácter general (cálculo NIF, fecha de vencimiento, etc. ) que deberán emplearse siempre que sea necesario implementar estas funcionalidades generales, evitando duplicar inecesariamente procedimeintos o funciones ya existentes en ICM. Estamos a la espera de la publicación de la relación oficla de dichos procedimientos y funciones oficiales de ICM. 17 *MODELOS NUEVOS* Formato del nombre del archivo ERwin del modelo de datos. El formato del fichero ERwin de la aplicación debe ser: {PROY}-ERW-vv.rr-aaaammdd.{er1} 18 ***NO APLICAR*** Volumetria definida por cada tabla o vista materializada del modelo. Debe indicarse la volumetría aproximada o esperada de cada una de las tablas y vistas materializadas del modelo. Se indicará en el apartado especifico de ERWIN para este dato, en Tables --> Volumetrics --> Initial Rows y Max Rows. Se acepta que este sólo uno de los datos, es decir, el volumen inicial o el máximo. Preferentemente el inicial, que será tenido en cuenta para el paso a producción. Pendiente de la documentación. 19 *** NO APLICAR *** No deben existir índices redundantes asociados a las tablas. No debe permitirse la existencia de índices de redundantes asociados a una tabla. Se considera redundate a aquel índice que indexa columnas ya indexadas en ese mismo orden. 20 *** NO APLICAR *** Nomenclatura de los sinónimos "complementarios" o segundos sinónimos. Por cada objeto del modelo de datos se crea un sinónimo remoto. Además, siempre que se justifique adecuadamente, se puede crear otro sinónimo para uso complementario, por motivos de accesos externos, provision de información a terceros, etc. Si un objeto necesita de un segundo sinónimo que no se corresponde con el nombre del objeto a que hace referencia (sinónimo ajeno), se creará y asignará otro Post-Script con el 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; Página: 3

4 El nombre del sinónimo se crea a partir del nombre del script, por lo que hay que poner especial cuidado en nombrarlo adecuadamente. 21 Nomenclatura del fichero ERwin del modelo de datos. Formato: XXXX-ERW-vv.rr-aaaammdd.{er1 erwin} 22 Existencia de Integridad referencial (automática) en el modelo de datos. No se permite la creación de modelos de datos de nueva creación sin la definición de integridad referencial. Salvo autorización expresa. AD 1 Legibilidad del modelo Verificar que las tablas están dispuestas sobre el tapiz de diseño de forma clara, sin amontonarse y que las las lineas de las relaciones permiten apreciar las relaciones entre las diferentes tablas. 2 Relaciones entre las tablas - Si faltan algunas relaciones, indicar un aviso. - Si faltan todas, indicar error. 3 Notación IDEF1X Por convenio,se ha definido esta notación como la estándar de ICM. 4 Existe "subject area" del DBA Debe existir un área de diseño que contenga todos los objetos del esquema, para facilitar las labores de creación y mantenimiento del esquema de datos. El nombre de este área ha dido normalizado, y deberá contener el nombre del propietario del esquema "DBA_xxxx". 5 Objetos del DBA están en "subject area" específica Todos los Objetos del DBA susceptibles de ser situados sobre el tapiz de diseño, deben estár incluidos o dibujados en el"subject area" específica para la creación del esquema. 6 Utilización de "main Area" No se debe utilizar el área de diseño 'Main Subject Area' de ERwin para el diseño del modelo de datos. Deben trabajarse sobre otra/s área/s propia/s para evitar problemas con la herramienta. 7 Orden lógico y físico El orden lógico y físico no se corresponde en ERwin, es diferente en un modelo de datos. Cuando no se presta atención a este aspecto, la creación de las tablas puede presentar un desorden considerado en sus columnas. 8 Existencia de Áreas de Diseño de ERwin vacías, es decir, sin objetos asociados. Las áreas de diseño que no se utilizan, es decir, sin objetos asociados y que no tienen ninguna función dentro del modelo de datos erwin deben eliminarse, como cualquier otro objeto innecesario o no utilizado del modelo. 9 Modelos Multinstancia. Existencia de una Área de Diseño por cada Instancia de Instalación del Esquema. Cuando el esquema de datos debe ser instalado "repartiendose" en varias instancias diferentes, es decir, una parte del modelo va a una instancia, y otra parte a otra u otras. No es el caso de un modelo que se instala completamente en varias instancias. Debe definirse un área de diseño por cada una de esas instancias con los objetos a crear en cada instancia. Los procedimientos----> Pendiente de Soporte. Yo lo haría con UDP's 10 Modelos Multinstancia. Todos los elementos del modelo de datos deben estár asignados a un área de diseño de creación parcial del esquema. Cuando el esquema de datos debe ser instalado "repartiendose" en varias instancias diferentes, es decir, una parte del modelo va a una instancia, y otra parte a otra u otras. No es el caso de un modelo que se instala completamente en varias instancias. Debe definirse un área de diseño por cada una de esas instancias con los objetos a crear en cada instancia. Y TODOS los objetos o elementos deben Página: 4

5 estár asignados a alguna de esas áreas de creación parcial, para poder determinar donde se crea cada objeto. 11 *NO APLICAR ES PROPUESTA* Existe un área de diseño específica de contenedores de datos personales protegidos. Cuando existan datos personales protegidos en el modelo de datos, debe definirse un área de diseño especifica que contenga los objetos contenedores de dichos datos. Se recomienda el nombre de área de diseño: "APDCM - Datos Personales Protegidos". 12 GENObjetosMayuscula - Nomenclatura correcta de los Objetos definidos en el Modelo de Datos. Todos los nombres de los objetos del modelo deberán estar definidos en mayúscula, y sólo podrán estar compuestos por caracteres alfanuméricos (sin acentos) y guión bajo _. BLOB 1 Tablas BLOB con "post-script" Las tablas que contienen columnas BLOB están obligadas a especificar un tablespace de almacenamiento de esa columna BLOB. TD 1 Tipos de datos no válidos Para evitar problemas con las diversas versiones de Oracle instaladas en ICM, solo se permiten los tipos de datos siguientes: 'VARCHAR2', 'CLOB', 'NUMBER', 'BLOB', 'DATE', 'SDO_GEOMETRY'. 2 Tipos binarios no válidos No se permiten columnas del tipo RAW, LONG RAW, BINARY LARGER... Deben Unificarse a tipos binarios BLOB. IT 1 Índices y preferencias en "post script" de indices de tipo Intermedia Text La especificación de indices de tipo Intermedia Text requiere de la definición especifica en ERwin según se indica en la documentación al respecto. Cuando hay mas de una columna, ademas, debe definirse las preferencia de acceso a la tabla. SEC 1 Secuenciadores como tablas vacías La definición de Secuenciadores según el estándar definido por ICM se realizará mediante: 1º. Definir una tabla vacía (sin columnas) sobre el tapiz de diseño. 2º. Asociarle a esta tabla un post-script de creación de la secuencia, con los parámetros necesarios. En este mismo script se puede incluir la definición del sinónimo y sus permisos. Sino, habrá que asociar un sccript con ellos. 3º. Definir en el explorador de ERwin (árbol) el secuenciador. Este paso es sólo documental. 2 Secuenciadores con "post-script" La definición de Secuenciadores según el estándar definido por ICM se realizará mediante: 1º. Definir una tabla vacía (sin columnas) sobre el tapiz de diseño. 2º. Asociarle a esta tabla un post-script de creación de la secuencia, con los parámetros necesarios. En este mismo script se puede incluir la definición del sinónimo y sus permisos. Sino, habrá que asociar un sccript con ellos. 3º. Definir en el explorador de ERwin (árbol) el secuenciador. Este paso es sólo documental. 3 Secuenciadores definidos en el explorador (árbol) La definición de Secuenciadores según el estándar definido por ICM se realizará mediante: 1º. Definir una tabla vacía (sin columnas) sobre el tapiz de diseño. 2º. Asociarle a esta tabla un post-script de creación de la secuencia, con los parámetros necesarios. En este mismo script se puede incluir la definición del sinónimo y sus permisos. Sino, habrá que asociar un sccript con ellos. 3º. Definir en el explorador de ERwin (árbol) el secuenciador. Este paso es sólo documental. IR 1 "Triggers" de relación (padre/hijo) son los de plantillas - Sólo se realizará esta validación con modelos que tengan integridad referencial basada en triggers. 2 Relación PK / FK coinciden en tipo y longitud *** 3 Nomenclatura IR con PK/FK requiere patrón de constraints - La nomenclatura de la IR basada en Pk y Fk exige la definición de unos "patrones" para la definición Página: 5

6 de los índices del modelo. Deben definirse los patrones: Key Group to Index = "%KeyType%TableName". 4 Nomenclatura IR con PK/FK requiere patrón de índices - La nomenclatura de la IR basada en Pk y Fk exige la definición de unos "patrones" para la definición de los nombres de las constraints PK y FK. Deben definirse los patrones: Relationships = "FK%child". 5 FK referentes a tablas sin PK Sólo se pueden definir claves FK sobre tablas que tienen definidas PK. Si no existe esta PK en la tabla referenciada se produce un error sintáctico de Oracle en la creación de la FK. 6 FK con el mismo nombre No se pueden definir dos FK en una tabla con el mismo nombre, deben numerarse como esta espeficado en la documentación. El no renombrar las FK dará como resultado un error de ejecución en la creación de la segunda FK de "nombre ya existente". 7 El modelo de datos no tiene definida integridad referencial. Todo modelo de datos debe implementar integridad referencial (automática) para garantizar la coerecia de la información que contiene. Esta integridad referencial debe estar basada en PK's y FK's, para todos los nuevos modelos. No se admite ya la integridad referencial basada en triggers salvo en casos justificados. 8 El modelo de datos tendrá definida la integridad referencial basada en PK's y FK's y no en triggers. Los NUEVOS MODELOS DE DATOS deben implementar integridad referencial (automática) basada en PK's y FK's. Sólo se admite implementación basada en triggers cuando se justifique su uso y para modelos antiguos. PP 1 Código con "grant" y sinónimo Los paquetes, procedimientos y funciones de base de datos deben definir permisos y sinónimos como el resto de objetos del esquema. Estos deberan incluirse dentro del mismo script de creación del objeto, al final. 2 Paquetes y procedimientos incluidos en el modelo de datos ERwin. - Si el código tiene menos de 32Kb., debe ir en el modelo. - Deben incluirse en el apartado Stored Procedures / Model Level Procedures. 3 Cabecera de paquetes y procediemientos en el modelo - Si el código tiene más de 32Kb., en el modelo sólo se indica la cabecera. 4 Existe fichero SQL con paquetes y procedimientos - Si el código tiene más de 32Kb., comprobar que existe el fichero sql que contiene el código. 5 Funciones y procedimientos sueltos Los procedimientos y funciones de una aplicación deberán agruparse en paquetes de base de datos, salvo justificación. 6 Paquetes y procedimientos sólo del esquema No se deben incluir en el modelo ERwin procedimientos, funciones o paquetes que no sean del esquema propio. Si se permite la presencia de tablas de otros esquemas, para poder hacer integridad referencial, definir vistas del esquema propio o aportar información conceptual al modelo, pero no se permite incluir ningún objeto mas. 7 Paquetes y procedimientos ICM de carácter general No deben definirse procedimientos o funciones de caracter genérico que ICM ya tenga deffinidos. Por ejemplo: Validar un NIF. 8 Commit / Rollback en el código Comprobar que no existe commit o rollback en el código plsql del procedimiento/función. Hay excepciones a esta regla, que son: 1.- Recosntrucción de Indices Intermedia Text. Los indices de intermedia text necesitan hacer un "Rebuil" para "refrescarlo". Este "rebuild", a su vez, necesita un commit. Página: 6

7 2.- Aplicaciones con Microstrategy. parece ser que las aplicaciones basadas en esta tecnología requieren procedimientos con Commit. 3.- JOBs. Cuando únicamente se llama al procedimiento desde un job. 4.- Trabajos lanzados desde CONTROL-M. A veces, se pueden lanzar o implicar procedimientos de base de datos desde estas tareas. En estos casos se admite también, siempre que se indique en la ficha. 5.- Transacciones Autónomas (AUTONOMOUS_TRANSACTION). Se permite exclusivamente en los procedimientos, y SÓLO EN ESTOS, que incluyen la directiva : PRAGMA AUTONOMOUS_TRANSACTION. 9 Actualización tablas de catálogos generales - Verificar que no se están actualizando tablas de catálogos generales: > USU > USUI > CATA > SUCA 10 Utilización de objetos otros esquemas - Verificar si se están consultando objetos de otros esquemas. 11 Actualización de objetos otros esquemas - Verificar si se están actualizando objetos de otros esquemas. 12 Utilización de Comandos DDL (Create, Alter, Drop y Truncate) de SQL en Paquetes, Procedimientos ó Funciones. No se permite ejecutar sentencias DDL en el código de los procedimientos, salvo causa justificada. Se permiten realizar Alter Session de Segmentos de Rollback y para ordenación. También se permiten los Alter Index Rebuil en los casos de índices intermedia text, pues es necesario. EXCEPCIONES: - ALTER REBUILD SYNC (reindexación del índice intermedia) 13 Existencia de control de errores (exceptions) y su tratamiento en procediemientos, funciones y paquetes de base de datos. Comprobar que existen definición de "exceptions" en el código plsql del procedimiento/función. Se deberá tratar mínimamente el código y mensaje de error oracle, para no propagar los errores y mensajes en ingles de Oracle. 14 Utilización indebida de la tabla DUAL. No se permite la utilización de la tabla DUAL para hacer asignaciones simples, realizables con una asignación normal de PL/SQL. Por ejemplo, para hacer conversiones de fechas o números, que pueden ser realizables con asignación directa de SQL. Se permite en la asignación de: - Generación de valores de secuenciadores. Tipo select xxxxx.nextval from dual; - Creación de relaciones 'virtuales', es decir uniones de select de una sola fila para hacer una lista de selección. Tipo: select '1' from dual union select '2' from dual. - En algún otro caso que esté justificado su uso, y no se pueda sustituido por código PL/SQL. Página: 7

8 15 Los procedimientos, funciones y paquetes de base de datos deben crearse con "CREATE OR REPLACE". A petición del departamenteo de paso a aproducción se obliga a crear los objetos de base de datos incluyendo la cláusula "OR REPLACE" en las sentencias de creación. En este caso, los procedimientos, funciones, y paquetes deben incluir en su código de creación la clausula mencionada, es decir, debe definirse : CREATE OR REPLACE { PROCEDURE FUNCTION PACKAGE }... APD 1 Columnas con información de carácter personal Ficheros de Justicia. ========================================================== Los fichero de datos protegidos de justicia están exentos de la declaración individual de ficheros. Si han declarado unos "grupos de ficheros" que agrupan a los ficheros individuales. Por tanto las aplicaciones de justicia, deben declarar en la ficha de entrega a que grupo de ficheros se asocia el o los ficheros de esa aplicación. Los grupos de ficheros actuales de justicia son: Ficheros de "Asuntos Jurisdiccionales". Cuya finalidad sea la "Gestión, consulta de información y emisión de documentos procesales relativos a procedimientos tramitados ante los órganos judiciales", el "responsable del fichero" es el Órgano Judicial que conozca del procedimiento, quedando su funcionamiento bajo la dependencia directa del Secretario Judicial. En cambio, el "encargado del tratamiento", salvo en el Tribunal Supremo, es la Comunidad de Madrid, a través de ICM. Ficheros de "Registro de Asuntos". Cuya finalidad sea la "Gestión, consulta y emisión de documentos relativos a los asuntos registrados y la información sobre el órgano judicial que conoce de los mismos", el "responsable del fichero" es el Secretario Judicial. El "encargado del tratamiento", salvo en el Tribunal Supremo, es la Comunidad de Madrid, a través de ICM. Ficheros "Gubernativos". Cuya finalidad sea "Gestión, consulta y emisión de documentos gubernativos relativos a las plantillas de Jueces y Magistrados, Secretarios Judiciales, así como del resto del personal adscrito a la Oficina judicial", el "responsable del fichero" es el órgano gubernativo competente. El "encargado del tratamiento", salvo en el Tribunal Supremo, es la Comunidad de Madrid, a través de ICM. Fichero de "Usuarios". Cuya finalidad es la "Gestión, mantenimiento y control de las cuentas de usuarios habilitadas en los sistemas de Gestión Procesal y demás aplicaciones informáticas, aprobadas por el Consejo General del Poder Judicial". El "encargado del tratamiento", salvo en el Tribunal Supremo, es la Comunidad de Madrid, a través de ICM. Los ficheros de datos de carácter personal creados en este ámbito tienen un nivel de seguridad Alto, por lo que deben adoptarse las medidas referidas en el Real Decreto 994/1999, de 11 de junio. DOC 1 Tablas, vistas y secuenciadores comentados Los objetos Tablas, vistas y secuenciadores deben tener contenido en su apartado de comentario "Comment". Además estos comentarios deben ser, de verdad, explicativos. Muchas veces aparecen "trozos" de texto a modo de relleno del comentario para salvar este control. 2 Paquetes, funciones y procedimientos comentados Los objetos Procedimientos, funciones y paquetes deben tener contenido en su apartado de comentario "Comment". Además estos comentarios deben ser, de verdad, explicativos. Muchas veces aparecen "trozos" de texto a modo de relleno del comentario para salvar este control. 3 Columnas comentadas Las tablas deben tener comentadas (documentadas) todas sus columnas, es decir, deben tener Página: 8

9 contenido en su apartado de comentario "Comment". Además estos comentarios deben ser, de verdad, explicativos. Muchas veces aparecen "trozos" de texto a modo de relleno del comentario para salvar este control. 4 *** NO VALIDAR *** Modelo documentado a nivel general (a nivel de modelo). El modelo de datos debe estar documentado a nivel general en "Model Properties". Apartados: - Solapa GENERAL. Debe rellenarse el apartado NAME. - Solapa DEFINITION. Debe incluirse una descripción general, tipo de integridad referencial, si el modelo se debe instalar en mas de una instancia diferente, pasos especiales a seguir para crear el esquema, si tiene protección de datos, etc. *** pendiente de hacer una plantilla **** 5 *** NO VALIDAR *** Áreas de Diseño documentadas. El modelo de datos debe estar documentado a nivel de áreas de diseño. Es decir, debe incluirse un comentario descriptivo en: Subject Areas --> Definition. GTT 1 GTT como tablas vacías - Las tablas temporales (GTT) están recogidas en ERwin como tablas vacías y con formato "PROY_GTT_%". 2 GTT con "post script" - Las tablas vacías de las GTTS tienen en ERwin un post-script a nivel de tablas con drop, create. REM 1 Sinónimos remotos como tablas con columnas - Los sinónimos remotos están recogidos en ERwin como tablas normales, con un "post-script" que contendrán las sentencias de creación del sinónimo. 2 Sinónimos remotos con "post-script" - Las tablas de los sinónimos remotos tienen en ERwin un "post-script" a nivel de tablas con drop, create. 3 Sinónimos remotos no se generan. Opcion Generate NO CHEQUEADA. - La tabla que define un sinónimo remoto debe tener la opción Generate anulada. 4 Sinónimos remotos diferenciados en diseño - Deben identificarse claramente las tablas que define un sinónimo remoto mediante sus atributos visuales o/y con textos aclaratorios sobre el tapiz de diseño. CAR 1 Cargas iniciales en el modelo Todas las cargas iniciales deben estar incluidas en el modelo de datos. Hay una excepción, si la carga tiene más de 32Kb., en el modelo sólo se indica la cabecera. 2 Existe fichero SQL con la carga inicial Todas las cargas iniciales deben estar incluidas en el modelo de datos. Hay una excepción, si la carga tiene más de 32Kb., en el modelo sólo se indica la cabecera. En este caso, se indicará el nombre y ubicación del fichero de carga en formato SQL. Debe verificarse la existencia del fichero SQL referido en ERwin. 3 Sólo INSERT en carga - Los script de carga inicial sólo deben contener sentencias INSERT de SQL. - No se admiten: > Deletes. > Updates. > Truncates. > Commit. - Tampoco se deben incluir, sentencias de anulación/habilitación de triggers. - No se recomienda la realización de Cargas basadas en Insert - Select. De momento no se prohiben. 4 Carga con sinónimos - Las cargas deben hacer referencia a los nombres lógicos (sinónimos) de las tablas y no a los nombres fisicos. Página: 9

10 5 Cargas de datos reales - Las cargas en la base de datos de desarrollo no pueden incluir datos reales. - Hay que diferenciar las cargas para pruebas en desarrollo y las cargas para instalación en producción. - NO SE PERMITEN CARGAS DE DATOS PERSONALES REALES. Hay que comprobar que los datos referidos a personas son ficticios y no reales, en ningún caso. 6 Cargas masivas - No se pueden hacer cargas pesadas o excesivas para las pruebas de validación de los productos. - Hay que diferenciar las cargas para pruebas en desarrollo y las cargas para instalación en producción. Los entornos de desarrollo no están preaparados para almacenar cantidades grandes de información. 7 Orden de la carga inicial Se debe especificar el orden en el que se debe hacer la carga. Este orden se explicitará en el nombre del script de carga, con un prefijo numérico indicador del orden de carga. 8 Carga de diferentes esquemas SOLO SE PERMITEN CARGAS DE DATOS DE OTROS ESQUEMAS PARA LA CARGA DE TABLAS DE: USUARIOS,GRUPOS, PERMISOS, etc. - Las cargas iniciales de diferentes esquemas deben estar en ficheros SQL distintos. 9 Errores en la Carga Inicial del Esquema. La carga inicial del esquema realizada en la UIA debe haber terminado sin errores. Si no es así, deberá estar reflejado en el informe de instalación la relación de errores producidos al realizar dicha carga. 10 *** NO VALIDAR ***Carga inicial de datos binarios (plantillas, documentos, ect.) en formato EXPORT. * DEF 1 Reiteración de valores por defecto No se permite definir multiples valores por defecto del mismo valor en el modelo ERwin. Es decir, para definir el valor por defecto 'N', solo se debe definir un "Default Value" de Erwin CHK 1 Contador automático para nombre - No deben tener activado el contador automático para la confección de su nombre. 2 Reutilización de validaciones - Existen validaciones de columna (check) utilizadas para validar más de una columna del modelo. - No se puede utilizar la misma validación para más de una columna del modelo. - No se puede asignar múltiples veces. - Deben definirse varias validaciones con diferente nombre. TRAZ 1 Paquete de traza N3 Cuando existen datos personales protegidos de nivel 3, deben definirse el paquete de trazas según norma de ICM. Tendrá el nombre: "aplicacion"_pack_log. Elpaquete tendrá las dos funciones necesarias (ver paquete plantilla de DBA_TRAZ). 2 Triggers N3 Cuando existen datos personales protegidos de nivel 3, deben definirse triggers, para la creación de trazas, en cada una de las tablas con los datos protegidos, según norma de ICM. Los disparadores serán del tipo "A_DIU" y "B_DIU" en las tablas afectadas. El código llamará al paquete de traza. TRIG 1 Definición correcta de Triggers a nivel de Objeto ERwin. La definición de un trigger en el modelo ERwin debe ser coherente. Esto quiere decir, que las propiedades definidas a nivel de ERwin del trigger deben ser idénticas a las propiedades definidas en el código de dicho objeto (a nivel de script SQL). 2 Duplicidad de triggers en una tabla para los mismos parámetros de ejecución. No se pueden crear mas de un trigger en una tabla para los mismos parámetros de ejecución y alcance. Por ejemplo, dos triggers que se definan AFTER, ROW y para INSERT-UPDATE. Deben unificarse en uno sólo trigger el código de los dos, a menos que esté justificada esta duplicidad. Página: 10

11 3 Los triggers de base de datos deben crearse con "CREATE OR REPLACE". A petición del departamenteo de paso a producción se obliga a crear los objetos de base de datos incluyendo la cláusula "OR REPLACE" en las sentencias de creación. En este caso, los triggers deben incluir en su código de creación la clausula mencionada, es decir, debe definirse : CREATE OR REPLACE TRIGGER... JOB 1 Existencia de Job de Oracle en el modelo de datos ERwin. Los job de Oracle deben incluirse en el modelo de datos ERwin, para que queden documentados. 2 Definición correcta de Job de Oracle en el modelo de datos ERwin. Los job de Oracle deben definirse en el modelo de datos ERwin, para que queden documentados. No es necesario incluir el código de creación del propio JOB, sino indicar los parámetros de creación o características del mismo, como: nombre de objeto a ejecutar, perioridicad, etc. Se incluirán en Model Level Scripts (script a nivel de modelo) con la sintaxis JOB_[Nombre_Procedimiento_Ejecutado] y con el contenido: Ejemplo: /* Definición de JOB de base de datos Procedimiento : XXXX_Procedimiento Objeto del Proceso: <Breve descripción del Proceso ejecutado> Valor Parámetros : Indicar el valor de los parámetros, si los hubiera. Ejemplo: CódTributo = 25 CódEnvio = `ATR FechaActual = SYSDATE, etc. Periodicidad : Cada n {minutos/horas/días/semanas/años/ } Hora de Ejecución : Especificar hora concreta por necesidades del servicio o indicar Nocturna, para ejecución fuera de horas de servicio. Incidencias : Actuaciones a realizar en caso de incidencias o errores detectados en la ejecución del job. Responsable : Nombre del responsable. ( Rellenar cuando se realice el paso a producción ) */ ROL 1 Existencia de Roles de Oracle en el modelo de datos ERwin. Los Roles de Oracle deben incluirse en el modelo de datos ERwin, en los casos excepcionales que sean autorizados.. 2 Definición correcta de Rol de Oracle en el modelo de datos ERwin. Los roles de Oracle deben definirse en el modelo de datos ERwin. Éstos objetos serán incluidos previa autorización de ICM. Se incluirán en Model Level Scripts (script a nivel de modelo). El nombre del script llevará el prefijo ROLE y, además, deberá incluir el nombre del role que se crea en su interior. Dentro del script se incluirán las sentencias de creación del ROLE y sus características o permisos. Se recomienda documentar la utilidad o finalidad de cada role. Aunque no hay nomenclatura obligatoria se recomienda la siguiente: <<CódAplicación>>_<<CaracterísticaDelRole>> VIST 1 Vistas definidas por el usuario sin columnas en el tapiz de diseño. Debemos comprobar que las vistas definidas por el usuario no "muestran" en el tapiz de diseño columnas. 2 Inclusión de "CREATE OR REPLACE" en las vistas definidas por el usuario. Debemos comprobar que el código de creación de las vistas definidas por el usuario incluya la clausula "REPLACE". Es decir, la creación de la vista se hará con "CREATE OR REPLACE". Página: 11

12 Esta validación no es aplicable a las vistas definidas o creadas con ERWin (VERSIÓN 4), pues no permite inlcuir REPLACE en el código. 3 Vistas definidas por el usuario sin ";" final dentro del código SQL. Las vistas definidas por el usuario, es decir, que tienen el check "User-Defined SQL" marcado, no deben incluir un punto y coma al final de la sentencia de creación de las mismas. Erwin añade automáticamente este ";" con lo que se incluirían dos y produciría un error. VMAT 1 Vistas materializables incluidas en el modelo de datso ERwin. Las vistas materializables deben estar incluirdas en el modelo de dasto como cualquiera otro de los objetos que lo componen. Se deben incluir en el apartado específico de estos objetos existente en Erwin. 2 Definición de la vista materializada conforme a la normativa de ICM. Pending La vistas materializadas con el METODO de refresco igual a "COMPLETO" (COMPLETE). Sólo se permitie el metodo de refresco "COMPLETE". No se aceptan otras opciones salvo autorización expresa. 4 La vistas materializadas definidas de solo lectura. Sólo se permitie la definicón de vistas materializadas de SOLO LECTURA. No se aceptan otras opciones salvo autorización expresa. 5 La vistas materializadas con el TIPO de refresco igual a "BAJO DEMANDA" (DEMAND). Sólo se permitie el TIPO de refresco "BAJO DEMANDA" (DEMAND). No se aceptan otras opciones salvo autorización expresa. 6 Inclusión de "CREATE OR REPLACE" en las vistas materializadas. Debemos comprobar que el código de creación de las vistas materializadas incluya la clausula "REPLACE". Es decir, la creación de la vista se hará con "CREATE OR REPLACE". THES 1 *** NO VALIDAR *** Thesaurus definido segun norma de ICM * BUPR 1 Uso injustifcado de la tabla DUAL en código PL/SQL. Dentro de las buenas prácticas de codificación en SQL esta la de no usar la tabla DUAL cuando no es necesaria. No se permite la utilización de la tabla DUAL para hacer asignaciones simples, realizables con una asignación normal de PL/SQL. Por ejemplo, para hacer conversiones de fechas o números, que pueden ser realizables con asignación directa de SQL. Se permite en la asignación de: - Generación de valores de secuenciadores. Tipo select xxxxx.nextval from dual; - Creación de relaciones 'virtuales', es decir uniones de select de una sola fila para hacer una lista de selección. Tipo: select '1' from dual union select '2' from dual. - En algún otro caso que esté justificado su uso, y no se pueda sustituido por código PL/SQL. 2 Uso no permitido de Databaselink (@ ) en sentencias SQL. No está permitido el uso injustificado de los databaselink en sentencias SQL. Esto es, la utilización de: nombre_tabla@nonbre_de_enlace Se deben utilizar los sinónimos remotos. 3 Uso no permitido de "SELECT * ". No se considera una buena prática de programación la utilización de "SELECT * ". Dado que no se definen las columnas, en caso de cambios de estructuras de tablas esta instucción daría errores. Se deben inidicar EXPLÍCITAMENTE las columnas recuperadas de toda select. 4 Uso indebido de SELECT FOR UPDATE sin clausula "NO WAIT" en procesos concurrentes. Página: 12

13 La utilización de la sentencia SELECT FOR UPDATE sin la clausula "NO WAIT" puede probocar bloqueos inesperados en las aplicaciones. Debe utilizarse dicha cláusula siempre que los procesos sean o puedan ser concurrentes. BO 5 Nomenclatura del Esquema DataWhaterhouse: DBA_DW_XXXX REQ-BD-NombreDW: Suponiendo que el nombre del proyecto es XXXX, el nombre del esquema en el que se almacena el DataWarehouse del proyecto debe ser DBA_DW_XXXX. 6 Nomenclatura del Esquema del Data Services (ETL) : DBA_ETL_XXXX REQ-BD-RepositorioETL: Todo proyecto con Business Objects que utilice Data Services constará de su propio repositorio local. Suponiendo que el nombre del proyecto es XXXX, el nombre del esquema en el que se almacena el repositorio de Data Services debe ser DBA_ETL_XXXX. 7 Versión Oracle para Proyectos de Business REQ-BD-VersOracle: La base de datos a utilizar para DataWarehouse para proyectos que utilicen la plataforma Business Object tiene que ser Oracle10gR2 o superior SD 1 Error sin determinar *** 2 Aviso sin determinar *** 3 Informativo sin determinar *** Página: 13