Lista de verificación BD

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
Lista de verificación BD
Código
GEN
v.14.01.2013
Descripción
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 4.1.4.
10 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
SGDTI
DSSR
UACCA
Página: 2
Lista de verificación BD
v.14.01.2013
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;
SGDTI
DSSR
UACCA
Página: 3
Lista de verificación BD
v.14.01.2013
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
SGDTI
DSSR
UACCA
Página: 4
Lista de verificación BD
v.14.01.2013
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.
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
IR
SGDTI
DSSR
UACCA
Página: 5
Lista de verificación BD
v.14.01.2013
de los índices del modelo. Deben definirse los patrones: Key Group to Index =
"%KeyType%TableName".
PP
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.
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.
SGDTI
DSSR
UACCA
Página: 6
Lista de verificación BD
v.14.01.2013
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.
SGDTI
DSSR
UACCA
Página: 7
Lista de verificación BD
v.14.01.2013
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
SGDTI
DSSR
UACCA
Página: 8
Lista de verificación BD
v.14.01.2013
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 ****
GTT
REM
CAR
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.
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.
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.
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.
SGDTI
DSSR
UACCA
Página: 9
Lista de verificación BD
v.14.01.2013
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.
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.
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.
TRAZ
TRIG
SGDTI
DSSR
UACCA
Página: 10
Lista de verificación BD
JOB
v.14.01.2013
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 ...
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".
SGDTI
DSSR
UACCA
Página: 11
Lista de verificación BD
v.14.01.2013
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.
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 ----
3
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.
VMAT
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.
SGDTI
DSSR
UACCA
Página: 12
Lista de verificación BD
v.14.01.2013
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
SD
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
1
Error sin determinar
***
2
Aviso sin determinar
***
3
Informativo sin determinar
***
SGDTI
DSSR
UACCA
Página: 13