bbdd_normativa

Normativa de Modelado de Bases de Datos y Uso de la Herramienta ERWIN

Versin 1.15

rea de Integracin y Arquitectura de Aplicaciones

Normativa de Modelado de Bases de Datos y Uso de la herramienta ERWIN

2 de 112

Hoja de Control

Ttulo Normativa de Modelado de Bases de Datos y Uso de la herramienta ERWIN

Documento de

Referencia

Responsable rea de Integracin y Arquitectura de Aplicaciones

Versin 1.15 Fecha Versin 26/11/2014

Registro de Cambios

Versin Causa del Cambio Responsable del

Cambio Fecha

1.0 Versin inicial del documento, se parte de la normativa para una versin anterior de la herramienta ERWIN

rea de Integracin y

Arquitectura de

Aplicaciones

15/09/2011

1.1

- Cambiada RolNombreRoles, estaba repetida, se renombra una a RolNoUsuarios - Eliminada la regla CarLOBS, estaba duplicada con la regla CarScriptLOB. Modificado el texto de CarScriptLOB para que se incluya un fichero independiente por cada tabla

rea de Integracin y

Arquitectura de

Aplicaciones

16/09/2011

1.2

- PLANTILLAS XML: Cambio de plantillas de generacin de scripts para valores default de columnas - PLANTILLAS FET: Cambio de plantillas ".fet", no generaba saltos de lnea en los paquetes. - TABObligaPK: Las tablas que representan relaciones muchos a muchos no tienen que llevar PK nica, independientemente de que tengan ms campos. - GENObjetosMayuscula: Los objetos no pueden contener la letra ee. - BOPostRole: Modificado nombre del rol a XXXX_DW_ALL - BOGrantsOtros: Modificado nombre del rol a XXXX_DW_ALL - JOBNombreJobs: Los jobs ya no se meten como post-scripts sino como comentarios en un subject rea especfica. - CARScriptTemplates: No se permite ningn script template a nivel de modelo. - BOBNombreRol: El rol para BO se crea en un fichero SQL, no en un script template. - BOBNombreRol, BOPostRole, BOGrantsOtros: Reglas no aplicables a proyectos BO de Nexus. - ROLScriptRoles: Nueva regla - Versionado de los archivos .fet y .xml

rea de Integracin y

Arquitectura de

Aplicaciones

13/10/2011

1.3

- PLANTILLAS XML: Cambio de plantillas de generacin de scripts - PLANTILLAS FET: Cambio de plantillas ".fet", incorporada una barra al final de los Packages. - PLANTILLA DE PARTIDA: Modificado custom

rea de Integracin y

Arquitectura de

Aplicaciones

13/10/2011


3 de 112


Cambio Fecha

trigger template ICM para no incluir la barra al final de los triggers. - Apartado 5: Includo apartado para comparar con modelo real de base de datos. - TBSDefTablespaces: Los tablespaces tienen que tener activado el check de Generate. - TRINombreTrigger: Corregida errata befote - GENHerramienta: Corregida errata, sobraba un punto en el nmero de versin.

1.4

- PLANTILLAS XML: Cambio de la plantilla ICM_OPCIONES_GENERACION_SCRIPTS_V1_4.xml y ICM_TYPE_SELECTION_V1_3.xml para que se generen default values en comparaciones con modelo reales. - Al comparar con modelo de datos real, ignorar las diferencias que aparezcan en zona Default Values. - JOBNombreJobs: Modificada etiqueta de Jobs e indicado que se incluir una por cada Job. - En la plantilla de partida el tipo del Domain ICM_IDPK es NUMBER(10) - GENPlantillaFich y GENNombreFich: Quitada la versin del modelo del nombre del fichero. - GENUDPs: Nueva UDP a nivel del modelo para indicar la versin. - GENVersion: Nueva norma, cada vez que se hace una entrega hay que incrementar la versin del modelo. - Business Objects: Incorporado a este documento toda la normativa de base de datos en BO, y quitada de la normativa de BO (nueva norma BOBNombreTablas). - BOUDP: Ya no es necesario el post-script para Business Objects, basta con modificar la UDP DESTINO GRANT. - BOPostRole: Desaparece. - BOGrantsOtros: Desaparece. - En el apartado de entrega, se hace referencia a la ficha de entrega de mdulo de base de datos. - Templates: Unificados los dos templates anteriores en uno slo: ICM_TEMPLATE_COMUN_V1_4.fet - CARScriptTemplates renombrada y movida de sitio, ahora se llama GENScriptTemplates - ROLNoRoles: En caso de autorizarse roles, se hacen en un fichero SQL no en un script template. - DOCNombreTriggers: Cambiado el nombre a DOCTriggers.

rea de Integracin y

Arquitectura de

Aplicaciones

15/03/2012

1.5

- Apartado USER DEFINED PROPERTIES: Especificado que cuando se modifica una UDP se ha de hacer en dos sitios distintos. - TBSDefTablespaces: Excludos los tablespaces de modelos de Business Objects de esta norma. - BOBDefTablespaces: Nueva norma.

rea de Integracin y

Arquitectura de

Aplicaciones

12/11/2012


4 de 112


Cambio Fecha

1.6

- Apartado 5: Antes de entregar, si el modelo ya se encuentra instalado en produccin, comparar con la base de datos de preproduccin. - VISUserDefinedFrom: En las vistas definidas como User Defined SQL, si en la clasula FROM aparecen otras vistas del Modelo de datos, stas vistas deben indicarse en la pestaa FROM para que en la ejecucin del script se generen en el orden correcto

rea de Integracin y

Arquitectura de

Aplicaciones

16/01/2013

1.7

- Apartado 2.1.3: En Buena Prctica GENEjemplo

actualizado formato de fichero erwin: AGCC-ERW.erwin - Apartado 5: En el Paso1 actualizado formato de fichero erwin : XXXX-ERW.erwin - Apartado 5: En NOTA IMPORTANTE actualizado nombre de fichero script para comparaciones: Para esta comparacin, se utilizar el script proporcionado : ICM_TYPE_SELECTION_VX_Y.xml - Apartado 5: borrado: (Si se est comparando contra la base de datos de preproduccin de ICM, se utilizar ICM_TYPE_SELECTION_PPRO_VX_Y.xml)

rea de Integracin y

Arquitectura de

Aplicaciones

29/07/2013

1.8

- Includo nuevo Apartado 3.4 para Modelos muy grandes que se dividen envarios ficheros ERWIN y varios DBAs.

rea de Integracin y

Arquitectura de

Aplicaciones

13/06/2014

1.9

- Apartado 2.4.8: Se modifica ste apartado para que haya un check (validation rule) para cada columna y se prohbe en el contenido del check la variable %ColumnName, esto permite que al realizar el complate compare de stos objetos se realice correctamente. - Desaparece la buena prctica TABReutilizarCheck desaparece - Se aaden las normas: TABMaxCheck y TABColNameCheck

rea de Integracin y

Arquitectura de

Aplicaciones

29/07/204

1.10 - En el apartado 2.7 Se incorpora una nueva norma PFPOutput

rea de Integracin y

Arquitectura de

Aplicaciones

26/09/2014

1.11

- En el apartado 2.4.6 se incorpora un nuevo tipo de ndices: PRn[NOMBRE_TABLA] Para los ndices Locales de tablas Particionadas

rea de Integracin y

Arquitectura de

Aplicaciones

02/10/2014

1.12 - En el apartado 3.3 se adapta la normativa documentum a erwin 7

rea de Integracin y

Arquitectura de

Aplicaciones

07/10/2014

1.13 - En el apartado 2.4.6 se incorpora un nuevo tipo de ndices: PGn[NOMBRE_TABLA] Para los

rea de Integracin y

Arquitectura de 14/10/2014


5 de 112


Cambio Fecha

ndices Locales de tablas Particionadas - En el apartado 2.4.10 se incorporan nuevas normas y recomendaciones de uso de ndices en tablas particionadas

Aplicaciones

1.14 - En el apartado 2.4.10 se ha aadido la norma TABPartPasoProduccion

17/10/2014

1.15

- En el apartado 2.4.1 se aade excepcin en la norma TABAsignarTablespace para las tablas GLOBAL

TEMPORARY

- En el Apartado 2.7 se modifican las normas

PFPNombreProc y PFPNombreFunc (diferenciando

si se crean dentro de un Paquete o sueltos con

Autorizacin Excepcional)

rea de Integracin y

Arquitectura de

Aplicaciones

26/11/2014


6 de 112

ndice

1 INTRODUCCION ................................................................................................................................................... 8

1.1 AUDIENCIA OBJETIVO ................................................................................................................................. 8 1.2 CONOCIMIENTOS PREVIOS ........................................................................................................................ 8

2 NORMATIVA ......................................................................................................................................................... 9

2.1 NORMATIVA GENERAL ............................................................................................................................... 9 2.1.1 HERRAMIENTA ....................................................................................................................................................... 9 2.1.2 PROYECTO Y MDULOS ...................................................................................................................................... 9 2.1.3 PLANTILLA DE PARTIDA...................................................................................................................................... 9 2.1.4 PROTECCIN DE DATOS .................................................................................................................................... 12 2.1.5 USER DEFINED PROPERTIES ............................................................................................................................. 12 2.1.6 DOCUMENTACIN DEL MODELO .................................................................................................................... 15 2.1.7 INTEGRIDAD REFERENCIAL ............................................................................................................................. 17 2.1.8 SEGURIDAD DE OBJETOS (PERMISOS Y SINONIMOS) ................................................................................. 18 2.1.9 SCRIPT TEMPLATES ............................................................................................................................................ 20 2.1.10 PROPIETARIO DE LOS OBJETOS ................................................................................................................... 20 2.1.11 OBJETOS DUPLICADOS .................................................................................................................................. 21 2.1.12 NOMENCLATURA GENERAL DE OBJETOS................................................................................................. 22

2.2 ESTRUCTURA DEL MODELO Y REAS DE DISEO ............................................................................. 22 2.3 TABLESPACES ............................................................................................................................................. 25 2.4 TABLAS ......................................................................................................................................................... 26

2.4.1 TABLAS .................................................................................................................................................................. 26 2.4.2 TABLAS GLOBAL TEMPORARY ........................................................................................................................ 30 2.4.3 PRIMARY KEYS .................................................................................................................................................... 31 2.4.4 FOREIGN KEYS ..................................................................................................................................................... 33 2.4.5 ALTERNATE KEYS ............................................................................................................................................... 34 2.4.6 INDICES .................................................................................................................................................................. 35 2.4.7 COLUMNAS LOB (BLOB y CLOB) ...................................................................................................................... 38 2.4.8 CHECKS Y VALORES POR DEFECTO A NIVEL DE COLUMNA .................................................................... 39 2.4.9 TRIGGERS .............................................................................................................................................................. 42 2.4.9.1 TRIGGERS ESPECIALES PARA TRAZABILIDAD DE ACCESO ................................................................. 45 2.4.10 PARTICIONES Y SUBPARTICIONES DE TABLA ......................................................................................... 45 2.4.10.1 ASIGNACION DE TABLESPACES A PARTICIONES DE TABLAS Y A INDICES LOCALES PARTICIONADOS Y GLOBALES PARTICIONADOS .................................................................................................... 47 2.4.10.1.1 INDICES LOCALES PARTICIONADOS ...................................................................................................... 48 2.4.10.1.2 INDICES GLOBALES .................................................................................................................................... 49 2.4.10.1.3 INDICES GLOBALES PARTICIONADOS ................................................................................................... 50

2.5 VISTAS ........................................................................................................................................................... 52 2.5.1 VISTAS .................................................................................................................................................................... 52 2.5.2 VISTAS MATERIALIZADAS ................................................................................................................................ 56 2.5.2.1 REFRESCO DE VISTAS MATERIALIZADAS ................................................................................................ 58

2.6 SECUENCIADORES ..................................................................................................................................... 61 2.7 PROCEDIMIENTOS, FUNCIONES Y PACKAGES ..................................................................................... 62

2.7.1 PAQUETES ESPECIALES (TRAZAS Y SERVICIOS WEB) ............................................................................... 66 2.8 OTROS OBJETOS .......................................................................................................................................... 67

2.8.1 SINONIMOS REMOTOS ........................................................................................................................................ 67 2.8.2 ROLES ..................................................................................................................................................................... 69 2.8.3 JOBS ........................................................................................................................................................................ 70

2.9 CARGAS DE DATOS .................................................................................................................................... 71 2.9.1 CARGAS DE DATOS INICIALES ......................................................................................................................... 72 2.9.2 CARGAS DE DATOS DE ENTORNO ................................................................................................................... 73 2.9.3 CARGA DE FICHEROS LOB (CLOB y BLOB) .................................................................................................... 75

3 NORMATIVA ADICIONAL PARA ENTORNOS ESPECIFICOS ................................................................ 75

3.1 APLICACIONES GIS ..................................................................................................................................... 75 3.2 APLICACIONES BUSINESS OBJECTS ....................................................................................................... 75

3.2.1 TABLESPACES ...................................................................................................................................................... 75 3.2.2 SUBREAS ............................................................................................................................................................. 76 3.2.3 NOMENCLATURA DE OBJETOS ........................................................................................................................ 76 3.2.4 ROLES ..................................................................................................................................................................... 77


7 de 112

3.3 APLICACIONES DOCUMENTUM .............................................................................................................. 79 3.3.1 SUBREAS ............................................................................................................................................................. 79 3.3.2 SINNIMOS REMOTOS PRIVADOS ................................................................................................................... 79 3.3.3 SECUENCIAS ......................................................................................................................................................... 80 3.3.4 TRIGGERS .............................................................................................................................................................. 82

3.4 MODELOS DE DATOS DIVIDIDOS EN VARIOS FICHEROS Y DBAS .................................................. 85

4 OTRAS CONSIDERACIONES ........................................................................................................................... 88

4.1 USO DE CATLOGOS COMUNES Y ACCESO A OTROS ESQUEMAS .................................................. 88 4.2 GENERACIN DE SCRIPTS ........................................................................................................................ 88 4.3 DESBORDAMIENTO EN NOMBRES DE NDICES, PK, FK Y TRIGGERS .............................................. 90 4.4 SENTENCIAS SQL PERMITIDAS, Y BUENAS PRCTICAS.................................................................... 91 4.5 BSQUEDAS TEXTUALES (INTERMEDIA TEXT) .................................................................................. 92

4.5.1 DEFINICIN DE INDICES DE INTERMEDIA TEXT ......................................................................................... 92 4.5.2 THESAURUS DE INTERMEDIA TEXT ............................................................................................................... 93

5 ANTES DE ENTREGAR: COMPARACIN DEL MODELO CONTRA BASE DE DATOS ..................... 95

6 FORMATO DE ENTREGA ............................................................................................................................... 107

A1.1 NORMAS ..................................................................................................................................................... 108

A1.2 BUENAS PRACTICAS .............................................................................................................................. 112


8 de 112

1 INTRODUCCION

La presente gua presenta la normativa de modelado de Bases de Datos y uso de la herramienta ERWIN

para las aplicaciones desarrolladas para Informtica de la Comunidad de Madrid (ICM en adelante). En ella

se recogen tanto las normas que debe cumplir el modelo de datos como el fichero en formato ERWIN que

contiene toda la definicin de ste.

En esta normativa se incluyen dos tipos de indicaciones para el correcto desarrollo de aplicaciones:

o Normas: Son requisitos de obligado cumplimiento, y se encuentran definidas dentro de una caja

de color azul:

NO

RM

A

NombreDeNorma

Contenido de la norma.

o Buenas prcticas: Son recomendaciones. No son de obligado cumplimiento aunque para un

correcto funcionamiento se recomienda cumplirlas siempre que sea posible. Se encuentran

definidas dentro de una caja de color amarillo:

BU

EN

A

PR

AC

TIC

A

NombreDeBuenaPractica

Contenido de la Buena Prctica.

1.1 AUDIENCIA OBJETIVO

Este documento va dirigido a jefes de proyecto, analistas y desarrolladores de proyectos que requieran

definir y/o modificar modelos de datos para aplicaciones de ICM.

1.2 CONOCIMIENTOS PREVIOS

Para un completo entendimiento del documento, el lector deber tener conocimientos previos sobre SQL,

bases de datos Oracle, diseo de modelos de datos relacionales y la herramienta de diseo y modelado

ERWIN.


9 de 112

2 NORMATIVA

2.1 NORMATIVA GENERAL

En este apartado se incluye la normativa general a aplicar a todos los modelados de Base de Datos

realizados para la Comunidad de Madrid.

2.1.1 HERRAMIENTA

En ICM todo modelo de datos tiene que estar desarrollado con la herramienta ERWIN Versin 7. Esto

asegura homogeneidad en todos los proyectos, y documentacin del modelo de datos centralizada.

NO

RM

A

GENHerramienta

Todo modelo de datos debe estar realizado con la herramienta ERWIN 7.3.8.2235 (Service Pack

2).

2.1.2 PROYECTO Y MDULOS

Un proyecto en ICM puede contener varios mdulos, entre ellos el que contiene la definicin del modelo de

datos. El mdulo de base de datos se incluye dentro de la entrega segn la nomenclatura y estructura de

ficheros definidas en el apartado FORMATO DE ENTREGA.

2.1.3 PLANTILLA DE PARTIDA ICM establece una serie de estndares para la realizacin de modelos de datos, adems de una plantilla

de partida que debe utilizarse como base para su realizacin (Fichero XXXX-ERW.erwin).

NO

RM

A

GENPlantillaFich

El Modelo de datos Erwin se debe construir a partir de la plantilla XXXX-ERW.erwin.

NO

RM

A GENNombreFich

La Nomenclatura del fichero erwin debe ser: XXXX-ERW.erwin donde:

XXXX: Nombre del proyecto (Ejemplo: AGCC)

BU

EN

A

PR

AC

TIC

A GENEjemplo

Para ver un ejemplo de fichero de ERWIN bien formado, se recomienda consultar el archivo

publicado en la web de SOJA denominado AGCC-ERW.erwin


10 de 112

En la plantilla de partida viene configurado el tipo de base de datos por defecto (Oracle V9.X), segn se

muestra en la siguiente figura:

No se puede modificar esta configuracin, debiendo siempre estar configurada esta base de datos, segn

se muestra en la siguiente norma:

NO

RM

A

GENVersionOracle

Todo modelo de datos estar configurado para la base de datos Oracle Versin 9.x

En la plantilla de partida tambin viene configurada la notacin que utiliza el modelo. Dicha notacin no se

podr modificar, segn se muestra en la siguiente figura:


11 de 112

NO

RM

A

GENNotacionIDEF1X

Todo modelo de datos estar configurado con la notacin IDEF1X (Integration DEFinition for

Information Modeling).

En la plantilla de partida vienen definidos los patrones por defecto que se van a utilizar a la hora de crear

distintos tipos de objeto. Podemos consultarlos accediendo a la opcin de men Tools -> Names -> Model

Naming Options:


12 de 112

B

UE

NA

PR

AC

TIC

A GENNamingOptions

Se recomienda no modificar las opciones Naming Options que vienen definidas en la plantilla,

para que tanto las relaciones como los ndices se creen por defecto con el nombre adecuado.

2.1.4 PROTECCIN DE DATOS Si el modelo incluye tablas que contengan datos personales susceptibles de ser tratados de forma especial

segn la LOPD, se tendr en cuenta el tratamiento especial de estas tablas segn la ley aplicable

(consultar documento especfico sobre proteccin de datos).

NO

RM

A

GENTratarLOPD

Si los datos contenidos en el modelo son de nivel de proteccin alto (nivel 3), se tendr que

implementar la auditora de acceso a los datos con los mecanismos disponibles.

Asimismo se crear un rea de diseo especfica que contenga los objetos afectados, y en la

descripcin del modelo se incluir un listado de las tablas que contengan datos personales de

nivel alto.

NO

RM

A

GENAltaFicheroLOPD

Si el modelo incluye tablas que contengan datos personales, se tendr que gestionar el alta del

fichero en la Agencia de Proteccin de Datos de la Comunidad de Madrid, declarando el uso y

destino que se va a dar a dichos datos.

El alta del fichero en la APDCM es imprescindible para la puesta en produccin del modelo de

datos.

2.1.5 USER DEFINED PROPERTIES En la plantilla de partida se encuentran definidas a nivel de modelo varias UDPs (User Defined Properties),

que incluyen informacin sobre la versin de la plantilla, la versin de la normativa de Base de Datos a la

que afecta, y la versin del modelo que estamos tratando:


13 de 112

En la siguiente norma se describen las UDPs que deben estar presentes en todo modelo.

NO

RM

A

GENUDPs

Todo modelo debe contener al menos las siguientes UDPs (User Defined Properties), vienen

includas en la plantilla de partida:

- VERSION PLANTILLA: Indica la versin de la plantilla que se ha utilizado como punto de

partida para el modelo.

- VERSION NORMATIVA: Indica la versin de la normativa de base de datos que debe

cumplir el modelo.

- VERSION MODELO: Indica la versin actual del modelo ERWIN.

- DESTINO GRANT: Indica el usuario al que se har GRANT cada vez que se cree un

sinnimo pblico. Su valor deber ser PUBLIC excepto en modelos de datos de

Business Objects.

NO

RM

A

GENVersion

Cada vez que se introduzca una modificacin al modelo ERWIN y se pretenda instalar esta nueva

versin en alguno de los entornos de ICM, deber modificarse el valor de la UDP cuyo nombre es

VERSION MODELO, para incrementar la versin.

Las Unidades de Recepcin de Aplicacin y de Paso a Produccin no instalarn un modelo si no

se ha modificado dicha versin.


14 de 112

Cuando se modifica el valor de una UDP, es importante modificarlo en la pantalla de propiedades del

modelo, as como en el diccionario de UDPs. Para asegurarnos de ello, para modificar una UDP tenemos

que asegurarnos de acceder a la modificacin de la UDP de la siguiente manera:

1. Pulsar opcin de men: Model -> Model Properties .

2. Pulsar la pestaa UDP .

En esta pestaa tenemos que modificar el valor, pero no es suficiente con ello, tambin

tenemos que hacerlo en el diccionario de UDPs, siguiendo el paso 3.

3. Pulsar el botn de edicin de Udps

Es necesario tambin modificar el valor en esta nueva pantalla:


15 de 112

2.1.6 DOCUMENTACIN DEL MODELO En todo modelo de datos, cada uno de los objetos generados debe tener rellena la pestaa Comentario,

indicando una descripcin del objeto al que hace referencia.

NO

RM

A

GENComentarios

Todos los objetos del modelo deben tener rellena la pestaa Comentario con una descripcin del

objeto en cuestin, y la documentacin necesaria asociada al objeto.

Adems, el modelo a nivel general debe tener tambin comentarios indicando la informacin sobre el

modelo, segn se muestra en la siguiente pantalla:


16 de 112

NO

RM

A GENComentariosModelo

Se debe rellenar la pestaa Definition de las propiedades del modelo, con la descripcin general

del modelo, as como un listado de las tablas que contengan datos personales sensibles para la

Ley de Proteccin de Datos de nivel alto.

Asimismo, cada rea de diseo del modelo tambin debe tener una descripcin general, rellena en la

pestaa Definition segn se muestra en la siguiente pantalla:


17 de 112

NO

RM

A

GENComentariosAreas

Se debe rellenar la pestaa Definition de las propiedades de cada una de las reas del modelo,

con la descripcin general del rea.

2.1.7 INTEGRIDAD REFERENCIAL En este apartado se incluye la normativa relativa a la integridad referencial de los modelos de datos, as

como su definicin dentro de la herramienta ERWIN.

En los modelos de datos desarrollados para ICM, salvo autorizacin expresa, se debe utilizar integridad

referencial basada en Primary Keys y Foreign Keys. Adems se debe seguir una nomenclatura

especfica para estas claves (la plantilla de partida ya est configurada para seguir esta nomenclatura).

Para consultar la nomenclatura de las PKs y FKs pueden consultarse los apartados concretos que hablan

de este tipo de objetos.


18 de 112

NO

RM

A

GENIntReferencial

En los modelos de datos desarrollados para ICM, salvo autorizacin expresa por parte del rea de

Integracin y Arquitectura de Aplicaciones, se debe utilizar integridad referencial basada en

Primary Keys y Foreign Keys.

Toda tabla relacionada con otra deber contener su Foreign Key correspondiente a esa

relacin. Se evitar salvo casos excepcionales la existencia de tablas aisladas no relacionadas.

* Nota: Si se utilizan modelos de datos antiguos es posible que se encuentren tablas definidas sin

integridad referencia, o con integridad referencial basada en triggers.

2.1.8 SEGURIDAD DE OBJETOS (PERMISOS Y SINONIMOS) En los modelos de datos de ICM todos los objetos tienen un sinnimo pblico asociado, as como un

GRANT que concede permisos sobre ese sinnimo a todos los usuarios (PUBLIC). Mientras que el

sinnimo se asigna con un check en la definicin del objeto, para realizar el GRANT se hace

automticamente durante la generacin del script asociado (para eso se utilizan plantillas de generacin

propias de ICM los .fet).

A continuacin se muestra un ejemplo de tabla con un sinnimo creado (el nombre debe ser igual al

nombre de la tabla), y con el check de creacin del sinnimo pblico y create or replace activados:


19 de 112

Adems del sinnimo pblico que todo objeto lleva asociado, desde esta pantalla se pueden crear otros

sinnimos para el objeto si son necesarios.

A continuacin se listan una serie de normas que garantizan que la creacin de sinnimos sea correcta:

NO

RM

A

GENAsignarSinonimo

Para modelos de datos, todos los objetos de base de datos creados de tipo tabla, secuencia,

vista, procedimiento, funcin y paquete deben llevar asociado un sinnimo pblico que se llamar

igual que el objeto.

El sinnimo siempre se crear en las propiedades del objeto en la pestaa Sinnimo como

pblico, y tendr activados los checks de Generate y Create or Replace.

* Para modelos de datos de Documentum consultar la documentacin especfica de esta

tecnologa.


20 de 112

NO

RM

A

GENSinonimoAdicional

En ocasiones excepcionales, adems del sinnimo pblico que todo objeto debe llevar asociado,

se pueden crear otros sinnimos adicionales (que por tanto no se llaman igual que el nombre del

objeto que representan).

En ese caso, el nombre de estos sinnimos debe ser identificativo del uso que se quiera dar al

sinnimo.

En todos los modelos de datos fsicos, a los objetos de base de datos con sinnimo pblico no remoto se

les asigna automticamente un GRANT ON NombreObjeto TO PUBLIC WITH GRANT OPTION.

Esto se realiza automticamente al utilizar la plantilla ICM_TEMPLATE_COMUN_VX_Y.fet durante la

generacin del script SQL, por lo que no es necesario realizar nada adicional en el modelo ERWIN.

NO

RM

A

GENNoGrants

No se debern asignar GRANTS manualmente a los sinnimos pblicos de los objetos, ya que

esto se hace automticamente al generar los scripts.

* Excepcionalmente, para los modelos de aplicaciones Documentum, GIS Business Objects

consultar las normas especficas para estas tecnologas.

2.1.9 SCRIPT TEMPLATES

NO

RM

A

GENScriptTemplates

No se permite la inclusin de Script Templates a nivel de modelo (Model Level), salvo

autorizacin excepcional por parte de ICM.

2.1.10 PROPIETARIO DE LOS OBJETOS En todo modelo de datos, todos los objetos que permitan la opcin de definir el Owner deben tenerlo

definido correctamente, segn se muestra en la siguiente figura:


21 de 112

NO

RM

A

GENOwner

Todos los objetos del modelo que lo permitan deben tener relleno el campo Owner con el

esquema correspondiente (el esquema propietario del objeto).

2.1.11 OBJETOS DUPLICADOS

No se permite tener objetos duplicados en el modelo de datos (tablas, vistas, etc.). Esta situacin suele

producirse por un desconocimiento de la herramienta ERwin por parte del diseador, que en lugar de

incluir en un rea de diseo una tabla, la copia de un rea a otra. Sin saber que esa accin duplica el

objeto, dentro del modelo de datos, lo que producira errores en la creacin del esquema en la base de

datos.


22 de 112

NO

RM

A GENObjetosDuplicados

No se pueden incluir objetos duplicados en el modelo de datos.

Si se tienen varios objetos con el mismo nombre en el modelo, al generar el script de creacin se

intenta crear dos veces el objeto y falla su ejecucin.

2.1.12 NOMENCLATURA GENERAL DE OBJETOS

Adicionalmente a la nomenclatura especfica de cada tipo de objeto, a continuacin se incluye una norma

general que aplica a los objetos de todos los tipos:

NO

RM

A GENNombreObjetos

Los nombres de todos los objetos de base de datos (tablas, columnas, vistas, procedimientos,

etc.) deben estar en MAYSCULA, y slo pueden contener caracteres alfanumricos no

acentuados y guiones bajos. No pueden contener la letra ee ()

2.2 ESTRUCTURA DEL MODELO Y REAS DE DISEO

En este apartado se incluye toda la normativa referente a las distintas reas de diseo que pueden

definirse dentro del fichero ERWIN. Existen otras normas especficas para reas de diseo en tecnologas

Documentum, BO y GIS, que debern consultarse en el apartado especfico de estas tecnologas.

A continuacin se enumeran las normas que han de seguirse con respecto a las reas de diseo:

NO

RM

A AREMainSub

No se permite utilizar el rea de diseo de ERWIN Main Subarea como rea de diseo principal

del modelo. Esta rea no se modificar manualmente, se utilizarn el resto de reas de diseo

para crear los objetos oportunos.

NO

RM

A

AREGeneral

El rea de diseo de ERWIN Principal o General del Esquema es obligatoria y debe denominarse

segn la plantilla de partida: 01 rea General del Modelo de Datos.

En este rea deben aparecer todos los objetos que intervienen en el proyecto, incluidos los

objetos externos al esquema propio del proyecto si los hubiese (includos sinnimos remotos). No

se incluirn objetos que por su naturaleza no tienen representacin visual, como las secuencias,

procedimientos, etc.


23 de 112

NO

RM

A

AREPropietario

El rea de diseo de ERWIN del esquema propio del proyecto es obligatoria y debe denominarse

90 rea de Creacin del Esquema NOMBRE_PROPIETARIO, donde

NOMBRE_PROPIETARIO deber sustituirse por el nombre del propietario del esquema (por

ejemplo: DBA_EJPL). En este rea deben aparecer todos los objetos visuales propios del

esquema de base de datos, y no los externos (no se incluir ningn objeto propiedad de otro

usuario). No se incluirn objetos que por su naturaleza no tienen representacin visual, como las

secuencias, procedimientos, etc.

NO

RM

A

AREVariasBBDD

Si en un modelo aparece el mismo esquema en diferentes tipos de instancias de base de datos

(por ejemplo Centralizada y Departamental), deber existir un subrea especfica para cada tipo,

que incluir los objetos especficos de ese tipo de instancia.

La nomenclatura de los reas ser: 9n rea de Creacin del Esquema DBA_XXXX

INSTANCIA, donde n es un nmero consecutivo, XXXX es el nombre del proyecto, e INSTANCIA

es un identificador de la instancia de base de datos. Ejemplo:

91 rea de Creacin del Esquema DBA_AGCC CENTRALIZADA

92 rea de Creacin del Esquema DBA_AGCC DEPARTAMENTAL

NO

RM

A

AREVacia

En la entrega del fichero ERWIN no se incluir ningn rea de trabajo vaca que no est

contemplado en la normativa.

NO

RM

A ARELOPD

Si el modelo incluye tablas que contengan datos personales susceptibles de ser tratados de forma

especial segn la LOPD, se incluir un rea especfica que contenga todos los objetos afectados.

El nombre de esta rea ser: 80 rea de Datos Personales Protegidos.

BU

EN

A

PR

AC

TIC

A

AREParcial

Se pueden generar reas de trabajo parciales con algunos de los objetos del esquema. Estas

reas son meramente informativas (para organizar visualmente los objetos) y no sern tenidas

en cuenta para la generacin de los scripts de base de datos.

Si el modelo de datos es grande, se recomienda crear reas parciales conceptuales que

separen diferentes conceptos/funcionalidades dentro del modelo, as como reas fsicas que

contengan todos los objetos del mismo tipo (Ej: Subrea que contiene todas las vistas del

modelo).

A continuacin se muestra un ejemplo de definicin de las reas de un proyecto:


24 de 112

Cuando estamos diseando un modelo de datos, se puede elegir el Display Level pulsando sobre el tapiz

con el botn derecho. Para asegurarnos que el orden de visualizacin coincide con el orden fsico de

creacin de las columnas de las tablas, se recomienda utilizar el Display Level Physical Order durante el

diseo del modelo:

BU

EN

A

PR

AC

TIC

A

AREDisplayLevel

Se recomienda utilizar el Display Level Physical Order durante el diseo del modelo, para

asegurarnos que el orden de visualizacin coincide con el orden fsico de creacin de las

columnas de las tablas.

A la hora de crear un nuevo modelo ERWIN, deber tenerse en cuenta la colocacin de los objetos para

que estn dispuestos de una forma que resulte legible, pudindose apreciar de forma visual los objetos del

modelo as como sus relaciones.

NO

RM

A GENModeloLegible

Los objetos de un modelo debern estar dispuestos sobre el tapiz de diseo de forma clara, sin

superponer unos a otros, de forma que puedan apreciarse visualmente todos los objetos del

modelo as como sus relaciones.

NO

RM

A GENObjetosMayuscula

Todos los nombres de los objetos del modelo debern estar definidos en mayscula, y slo

podrn estar compuestos por caracteres alfanumricos (sin acentos) y guin bajo _. No pueden

contener la letra ee ().


25 de 112

Si en un subrea del proyecto queremos incluir objetos, que no pertenezcan al esquema principal del

proyecto, deberemos mostrar el objeto en color amarillo. Para ello, en la opcin Object Font Color - Fill

Color indicaremos el color amarillo, segn se muestra en la siguiente figura:

NO

RM

A

AREObjExternos

En cualquier subrea del modelo, los objetos externos al esquema propio del proyecto si los

hubiese se mostrarn siempre en color amarillo para diferenciarlos del resto.

2.3 TABLESPACES

En este apartado se incluye toda la normativa referente a los tablespaces de base de datos en los que se

almacenan los distintos objetos del modelo. En la plantilla de partida, vienen definidos los tres tablespaces

que todo modelo debe tener:


26 de 112

Cada vez que se cree un nuevo objeto de base de datos, se debe asignar al tablespace correcto, segn el

tipo de objeto.

En las siguientes normas se incluye la normativa relativa a definicin y asignacin de tablespaces:

NO

RM

A

TBSDefTablespaces

Todo modelo de datos (excepto modelos de datos Business Objects) debe tener definidos los

siguientes tablespaces (en estos tablespaces deber sustituirse XXXX por el nombre del

proyecto):

- TBSBLOB_XXXX_100: Tablespace que se asignar a las columnas de tipo BLOB o CLOB

- TBSDAT_XXXX_100: Tablespace para las tablas

- TBSIND_XXXX_100: Tablespace para los ndices

Los tres tablespaces deben tener activado el check de Generate.

En cada tabla, vista materializada (actua como una tabla), ndice o columna BLOB del modelo, se asignar

el tablespace correspondiente.

2.4 TABLAS

En este apartado se incluye toda la normativa referente a las tablas de base de datos y todos sus objetos

asociados (claves, ndices, etc.).

2.4.1 TABLAS .

NO

RM

A

TABNombreTabla

La nomenclatura de las tablas debe ser [XXXX]_[NOMBRE_TABLA], donde:


NOMBRE_TABLA: Nombre de la tabla, en maysculas. Si contiene varias palabras

pueden separarse por guiones bajos (Ejemplo: ARTICULOS_CLIENTE).

Ejemplos de nombres de tablas correctos seran: AGCC_ARTICULOS_CLIENTE,

AGCC_ART_PROVEEDOR_PRINCIP


27 de 112

NO

RM

A

TABTiposColumna

En las tablas, slo se permite crear columnas de los siguientes tipos:

VARCHAR2

CLOB

BLOB

DATE

NUMBER

SDO_GEOMETRY

En los campos de tipo NUMBER se puede, opcionalmente, definir la precisin.

El resto de tipos de datos (CHAR, VARCHAR, INTEGER, DECIMAL , LONG, RAW, LONG RAW,

BINARY LARGER, etc.) no estn permitidos.

Para garantizar la homogeneidad de los modelos de datos, al crear tablas con columnas de tipo

VARCHAR2, NO se tiene siempre que activar, en la pestaa Oracle, ninguna opcin en el desplegable

Character, segn se muestra en la siguiente figura:

NO

RM

A

TABVarchar2

Las columnas del tipo VARCHAR2 de cualquier tabla, nunca tendrn ninguna opcin seleccionada

en el desplegable Type de la pestaa Oracle.


28 de 112

B

UE

NA

PR

AC

TIC

A

TABNombreColumnas

A la hora de crear columnas en las tablas del modelo, se recomienda utilizar la siguiente

nomenclatura segn el tipo de dato que representa la columna:

ID_: Para identificador numrico de elemento (normalmente la PK, Ej: ID_USUARIO).

CD_ : Para cdigos alfanumricos (Ej: CD_DNI, CD_EXPEDIENTE, etc.)

DS_: Para descripciones alfanumricas (Ej: DS_EXPEDIENTE_ECONOMICO)

FC_: Para fechas (Ej: FC_ALTA_INVENTARIO)

IT_: Para marcas, indicadores (Ej: IT_MASCULINO -> Flag que indica S N).

NM_: Valor numrico o contador (Ej: NM_PERSONAS_FISICAS).

TL_: Texto libre, observaciones, comentarios, etc. (Ej: TL_MOTIVO_RECURSO)

BL_: Para campos BLOB

CL_: Para campos CLOB

HR_: Para tiempo sin fecha (hora, minuto y segundo)

AN_: Para aos

EU_: Importe en euros

Si el nombre del campo contiene varias palabras pueden separarse por guiones bajos.

En la plantilla de partida se entregan una serie de Domains definidos para cada uno de estos tipos de

datos (cuyo nombre empieza por ICM_ ), que pueden utilizarse a la hora de aadir columnas a una tabla.

Adems de estos domains, se incluyen otros de uso comn para los campos tpicos de auditora de alta,

modificacin y eliminacin de filas (cuyo nombre empieza por ICM_AUDI_).

BU

EN

A

PR

AC

TIC

A

TABUsoDomains

A la hora de crear columnas en una tabla, pueden utilizarse los Domains que vienen definidos

por defecto en la plantilla de partida, para asegurarse de que se estn utilizando los tipos de

columna de Oracle validados por la normativa.

Asimismo, se pueden utilizar domains especficos includos en la plantilla para campos

comnmente utilizados en auditora de alta, modificacin y eliminacin de filas.

A continuacin se muestran los domains definidos por defecto en la plantilla de partida:


29 de 112

Siempre que creemos una tabla en el modelo, debemos activar la opcin Physical Properties de la

pestaa General, y en el cuadro de dilogo Storage Properties asignar el tablespace de datos

(TBSDAT_XXXX_100), segn se muestra en la siguiente figura:


30 de 112

NO

RM

A TABAsignarTablespace

Todas las tablas del modelo (excepto las tablas temporales GLOBAL TEMPORARY) debern

obligatoriamente tener activada la opcin Physical Properties, y tener asignado el tablespace de

datos (TBSDAT_XXXX_100).

2.4.2 TABLAS GLOBAL TEMPORARY

Las tablas temporales se crean como una tabla normal, y en la pestaa General se debe chequear la

opcin Global Temporary con las opciones que corresponda, segn se muestra en la siguiente figura:


31 de 112

Al igual que el resto, las tablas GLOBAL TEMPORARY deben cumplir las normas de integridad referencial

(PKs, ndices, etc.).

NO

RM

A

TABGlobalTemp

La nomenclatura de las tablas temporales debe ser [XXXX]_GTT_[NOMBRE_TABLA], donde:


NOMBRETABLA: Nombre de la tabla, en maysculas. Si contiene varias palabras pueden

separarse por guiones bajos (Ejemplo: ARTICULOS_CLIENTE).

Un ejemplo de nombre de tabla correcto sera: AGCC_GTT_ARTICULOS_CLIENTE.

2.4.3 PRIMARY KEYS


32 de 112

En los modelos de datos, cada tabla deber tener obligatoriamente una (y slo una) Primary Key que

cumpla con la nomenclatura. Esta primary key estar formado por un solo campo de tipo numrico, y

su valor deber sacarse obligatoriamente de una secuencia.

Existe una excepcin a esta regla, en la cul una primary key deber estar compuesta por ms de un

campo, y es en aquellas tablas que slo sirven para representar relaciones muchos a muchos entre otras

tablas.

Ejemplo: Supongamos que tenemos una tabla EXPEDIENTE y una tabla INTERESADO, y que un

expediente puede tener varios interesados, y un intersado puede tener varios expedientes. La tabla

EXPEDIENTE_INTERESADO que relaciona las dos (y que representa la relacin muchos-a-

muchos entre EXPEDIENTE e INTERESADO) tendra como primary key los campos

ID_EXPEDIENTE e ID_INTERESADO:

A continuacin se muestran las normas relativas a Primary Keys:

NO

RM

A

TABObligaPK

Toda tabla del modelo de datos debe tener obligatoriamente una y slo una Primary Key. Esta

Primary Key deber ser numrica, obtenerse de un secuenciador, y estar formada por un

slo campo de la tabla.

Slo existe una excepcin en la cul una primary key deber estar compuesta por ms de un

campo, y es en aquellas tablas que sirven para representar relaciones muchos a muchos

entre otras tablas.

Se considerar otorgar autorizaciones excepcionales a esta norma para proyectos antiguos en

tecnologa Forms o modelos de datos heredados con otro sistema de integridad referencial.

BU

EN

A

PR

AC

TI

CA

TABAKRelaciones

Si en una tabla que sirve para representar relaciones muchos a muchos entre otras tablas se ha

generado una clave primaria numrica nica (porque dicha tabla incluye algn campo adicional


33 de 112

adems de las PKs de las tablas que relaciona), se recomienda crear una constraint Alternate

Key que comprenda las columnas que hacen referencia a las tablas que se relacionan.

NO

RM

A

TABNombrePK

La nomenclatura de la Primary Key debe ser PK[NOMBRE_TABLA].

Ejemplo: PKAGCC_ARTICULOS_CLIENTE

2.4.4 FOREIGN KEYS En los modelos de datos, se debern definir Foreign Keys para garantizar la integridad referencial por base

de datos. A continuacin se enumeran una serie de reglas aplicables a las Foreign Keys:

NO

RM

A

TABNombreFK

La nomenclatura de la Foreign Key debe ser FK[NOMBRE_TABLA]_[NN], donde NN es un

nmero consecutivo que se asigna a cada Foreign Key existente. Deben numerarse las FKs

aunque slo haya una por tabla.

Ejemplo: FKAGCC_ARTICULOS_CLIENTE_01

NO

RM

A

TABGenerateFK

Si en nuestro modelo de datos tenemos includas tablas de otros esquemas, que NO tienen

definida la Primary Key, deberemos deschequear la opcin Generate en las Foreign Keys a esas

tablas, para evitar que se generen.

Si en nuestro modelo de datos tenemos includas tablas de otros esquemas, que SI tienen

definida la Primary Key, deberemos asegurarnos que ambos esquemas conviviran en Produccin

en la misma instancia de base de datos, de lo contrario tambin deber desactivarse la casilla

Generate.

A continuacin se muestra la pantalla en la que puede desactivarse la casilla Generate:


34 de 112

2.4.5 ALTERNATE KEYS Se pueden definir constraints de integridad referencial que indiquen que una serie de campos deben ser

nicos. Para ello, puede hacerse desde la pantalla de edicin de ndices, activando el check Generate as

constraint:


35 de 112

NO

RM

A

TABNombreConstraintAK

La nomenclatura de las Constraint Unique debe ser: AKn[NOMBRE_TABLA].

Ejemplo: AK1AGCC_ARTICULOS_CLIENTE, AK24AGCC_ARTICULOS_CLIENTE

2.4.6 INDICES

Para crear ndices en una tabla, se selecciona esta, y se abre la opcin de ndices asociados. La ventana

permite el mantenimiento de los ndices, y la definicin de las columnas que lo integran.

En la siguiente norma se indica la nomenclatura de los ndices segn su tipo:


36 de 112

NO

RM

A

TABNombreIndices

La nomenclatura de ndices, dependiendo de su tipo, debe ser:

PK[NOMBRE_TABLA] Para los ndices de clave primaria.

AKn[NOMBRE_TABLA] Para los ndices de clave alternativa (nicos).

IEn[NOMBRE_TABLA] Para los ndices no nicos (con duplicados).

IFn[NOMBRE_TABLA] Para los ndices de clave fornea.

GRn[NOMBRE_TABLA] Para los ndices Geogrficos (Oracle Spatial).

DTS[NOMBRE_TABLA] ndices multicolumnas de Intermedia Text

BMn[NOMBRE_TABLA] Indices bitmap (Datawarehouse)

Donde n es un nmero consecutivo.

PRn[NOMBRE_TABLA] Para los ndices Locales de tablas Particionadas

PGn[NOMBRE_TABLA] Para los ndices Globales de tablas Particionadas

Nota: Es importante destacar que en los modelos de datos antiguos en los que no exista integridad

referencial basada en PKs y FKs, la nomenclatura era diferente, ya que se aada una letra X antes del

nombre del ndice.

Al crear los ndices en el modelo, hay que indicar el tablespace fsico en el que se crearn. Para ello, en el

cuadro de dilogo Storage Properties de la pestaa Physical se asignar el tablespace

TBSIND_XXX_100, segn se muestra en la siguiente figura:


37 de 112

NO

RM

A

TABTablespaceIndices

Todos los ndices del modelo (includos los de las PKs, etc.) debern obligatoriamente tener

asignado el tablespace de ndices (TBSIND_XXXX_100).

BU

EN

A

PR

AC

TIC

A TABIndRedundantes

Se recomienda no generar ndices redundantes (desmarcar la casilla Generate) que no sirven

si ya existe uno similar.

Ejemplo: Si tenemos un ndice en una tabla por dos campos CAMPO1 y CAMPO2, no sirve de

nada crear un ndice por el campo CAMPO1.


38 de 112

2.4.7 COLUMNAS LOB (BLOB y CLOB)

Los contenidos de las columnas de tipo LOB (BLOB y CLOB) se almacenan en Tablespaces especficos

para estas columnas, separados del resto de los datos de la tabla. Para cada tabla del modelo que incluya

columnas de tipo LOB, se debe modificar la pestaa LOB Storage segn se muestra en la siguiente

figura:

Deberemos pulsar sobre la opcin Parmeters de la columna de tipo LOB, y ah seleccionar el tablespace

especfico para campos LOB (TBSBLOB_XXXX_100), y marcando las opciones que se muestran a

continuacin:


39 de 112

A continuacin se listan las normas que definen el uso de campos LOB:

NO

RM

A

TABLobStorage

Toda tabla que contenga columnas de tipo BLOB CLOB (excepto las tablas temporales

GLOBAL TEMPORARY) deber tener asignados parmetros en la pestaa LOB Storage para

todas las columnas de este tipo. En los parmetros se asignar el tablespace

TBSBLOB_XXXX_100 y se activarn obligatoriamente los siguientes parmetros (y slo estos):

- CHUNK: 4096

- Retain old versin type -> PCTVERSION -> 10

- Cache -> NO-CACHE -> Logging -> LOGGING

2.4.8 CHECKS Y VALORES POR DEFECTO A NIVEL DE COLUMNA

A nivel de columna, pueden definirse checks (reglas de validacin o validation rules) y valores por defecto

(default values). Para definir checks y/o valores por defecto sobre columnas seguiremos los siguientes

pasos:

1) Definir a nivel de modelo los chequeos o reglas de validacin genricas y valores por

defecto genricos, en la zona Validation Rules o Default Values. Los nombres

debern definirse segn la nomenclatura [XXXX]_CHECK_[NOMBRECHECK], donde

[XXXX] es el nombre del proyecto, y [NOMBRECHECK] el nombre del check (lo ms


40 de 112

descriptivo posible). En la siguiente figura se muestra un ejemplo de definicin de

reglas de validacin y valores por defecto:

Seleccionando la Validation Rule y pulsando el botn derecho la opcin Properties en la pestaa General

rellenaremos el contenido del check (Validation Rule) , en ningn caso se utilizar la variable %ColName,

siempre debe aparecer el nombre de la columna.

Se crear un check para cada columna. Est prohibido asignar el mismo check para 2 o ms columnas


41 de 112

2) Asignar a las columnas deseadas las validaciones y valores por defecto que se

precisen. Esto se realiza la pestaa Constraint, seleccionando una validacin o valor

por defecto de los disponibles en las listas desplegables:


42 de 112

NO

RM

A TABNombreCheck

Los checks (Validation rules) deben cumplir la siguiente nomenclatura:

[XXXX]_CHECK_[NOMBRECHECK], donde [XXXX] es el nombre del proyecto, y

[NOMBRECHECK] el nombre del check (lo ms descriptivo posible).

NO

RM

A

TABMaxCheck

Se crear un check (Validation Rule) para cada columna. Est prohibido asignar el mismo check

(Validation Rule) para 2 o ms columnas

NO

RM

A

TABColNameCheck

El contenido del check (Validation Rule) pestaas general y oracle, en ningn caso se utilizar la

variable %ColName, siempre debe aparecer el nombre de la columna.

2.4.9 TRIGGERS


43 de 112

Para crear un trigger en ERWIN se pulsa sobre la tabla y se indica que se quieren visualizar sus triggers.

Desde esta pantalla pueden crearse nuevos triggers o visualizar los existentes, segn se muestra en la

siguiente figura:

Para garantizar la concordancia del cdigo SQL y las opciones de generacin del objeto, en la pestaa

Code no se deben modificar las variables que aparecen en su definicin, marcadas en la siguiente

pantalla con % (como por ejemplo %TriggerName, %Fire, etc.):


44 de 112

A continuacin se muestran las normas asociadas a la creacin de triggers.

NO

RM

A

TRINombreTrigger

La nomenclatura de los triggers ser [XXXX]_[NOMBRE_TABLA]_TRIG_[TIEMPO]_[ACCION],

donde:


NOMBRE_TABLA: Nombre de la tabla a la que se asocia el trigger

TIEMPO: Deber ser B (para before) o A (para after) en funcin del tiempo del trigger

ACCION: Deber ser D (delete), I (insert) U (Update). En caso de contemplar varias

acciones, se seguir el siguiente orden de letras: DIU. (Ej: D, DU, IU, DIU, etc.)

Un ejemplo nombre de trigger correcto sera: AGCC_ARTICULOS_TRIG_B_DU


45 de 112

NO

RM

A TRIUnicoTrigger

No se permite ms de un trigger en una tabla con el mismo evento.

Por ejemplo, no se pueden crear dos triggers sobre una tabla que se ejecuten (ambos) con las

opciones AFTER UPDATE, INSERT.

NO

RM

A

TRIVariablesTrigger

En la pestaa Code de la definicin de un trigger, no pueden sustituirse los nombres de las

variables que aparecen con porcentaje (Ej: %TriggerName, %Fire, %Actions, etc.). Las variables

se dejarn como tal, y slo en la pestaa Expanded ser podr comprobar el cdigo del trigger

con las variables sustituidas.

2.4.9.1 TRIGGERS ESPECIALES PARA TRAZABILIDAD DE ACCESO

Si deseamos guardar una traza de las modificaciones de una tabla (por ejemplo, para cumplir la LOPD), se

pueden crear triggers especficos a tal efecto. Para ms informacin sobre la trazabilidad de datos,

consultar la documentacin especfica a tal efecto.

2.4.10 PARTICIONES Y SUBPARTICIONES DE TABLA En ocasiones, por motivos de volumen o velocidad de acceso es necesario dividir una tabla en varias

particiones. En este caso, el uso de particiones deber ser autorizado expresamente por ICM,

justificndose el motivo por el cual se requiere esta funcionalidad. Desde ICM, en base a criterios tcnicos,

se decidir si se autoriza su uso.

Tipos de Particionamiento:

Rango . Permite particionar para rangos de fechas

Lista .- Permite particionar asignando a cada particion un valor o lista de valores

Hash .- Permite particionar indicando el nmero de particiones

Tips de SuParticionamiento

Rango - Hash

Rango - Lista

Lista - Hash (No disponible en Erwin 7)

Lista Rango (No disponible en Erwin 7)

A continuacin se incluyen las normas sobre el particionamiento de tablas:

NO

RM

A TABNoParticiones

Salvo autorizacin expresa, no se permite el uso de tablas particionadas en base de datos.

En el momento de su autorizacin, se decidir entre ICM y el proveedor el tipo de particionamiento

a utilizar as como la forma en la que se implementar el particionamiento en el modelo ERWIN.


46 de 112

NO

RM

A

TABNombreParticion

La nomenclatura de las particiones debe ser: [NOMBRE_TABLA]_PAR_[CRITERIO].

La nomenclatura de las subparticiones debe ser: [NOMBRE_TABLA]_SPAR_[CRITERIO].

[NOMBRE_TABLA] es el nombre de la tabla a particionar, y [CRITERIO] define el criterio por el

que se rige la particin en concreto. [CRITERIO] debe contener tanto del criterio como el valor (si

por motivos de longitud del nombre no es posible, se indicar slo el valor).

NO

RM

A

TABPartPasoProduccion

Cuando se realicen cambios en tablas particionadas u objetos asociados a las tablas

particionadas (particiones, ndices,) En el paso a Produccin debe indicarse el nombre de cada

objeto cambiado (campos ,si son campos particionados, ndices locales, ndices globales,

particiones,..) y la actualizacin que se solicita.

NO

RM

A

TABRawMovement

Las tablas particionadas al crearlas por defecto la propiedad RAW MOVEMENT est DISABLE, es

decir no se puede realizar un update de los campos de particionamiento que implique un cambio

de particin del registro.

Salvo autorizacin por ICM est prohibido poner la propiedad de las tablas particionadas

RAW MOVEMENT a ENABLE

NO

RM

A TABNoPartSQL

Salvo autorizacin expresa por parte de ICM, no se puede utilizar el nombre de las particiones en

las sentencias SQL (el criterio de las particiones se encargar de decidir en cul de ellas se

encuentra almacenada la fila).

A continuacin se muestra un ejemplo de definicin de particiones:


47 de 112

2.4.10.1 ASIGNACION DE TABLESPACES A PARTICIONES DE TABLAS Y A INDICES LOCALES PARTICIONADOS Y GLOBALES PARTICIONADOS

En la opcin de men Tables de la tabla seleccionada, en la pestaa Partitions , para cada cada

particin que hayamos definido en Partition Name se debe asignarse un tablespace de datos,

pulsando el botn Edit Properties en al campo Tablespace debemos realizar la asignacin del

tablespace de datos.


48 de 112

NO

RM

A

TABParticionTablespace

Cada Particin y Subparticin, debe tener asignado un tablespace de datos,

2.4.10.1.1 INDICES LOCALES PARTICIONADOS la asignacin del tablespace de ndices se realizar igual que un ndice normal es decir

En la opcin de men Indexes de la tabla seleccionada, en la pestaa Physical, en el botn

Storage Properties en el campo tablespace debemos asignar el tablespace de ndices. No

deben utilizarse particiones de ndice.


49 de 112

NO

RM

A

TABIndicesPartLocalTablespace

Indices Locales Particionados deben tener asignado un tablespace de Indices, al igual que

cualquier ndice normal, (no deben utilizarse particiones de ndice).

BU

EN

A

PR

AC

TIC

A TABIndicesPartLocalPrefix

Se recomienda utilizar los ndices locales particionados Prefijados (aparecen los campos de

particionamiento de la tabla primero en el ndice, despus el campo local por el que se quiere

indexar) sobre los ndices locales particionados no prefijados (no aparece en el ndice los

campos de particionamiento de la tabla )

2.4.10.1.2 INDICES GLOBALES Los ndices Globales en una tabla particionada equivalen a a un ndice normal, por lo tanto

la asignacin de Tablespace debe hacerse igual que en el apartado de ndices.


50 de 112

BU

EN

A

PR

AC

TIC

A

TABUsoIndicesGlobales

En una tabla particionada cuando se desee seleccionar registros sin acceder por clave de

particionamiento se recomienda utilizar ndices globales (un ndice normal de una tabla)

cuando el resultado a obtener sean pocos registros.

2.4.10.1.3 INDICES GLOBALES PARTICIONADOS

Estn desaconsejado su uso salvo casos excepcionales, de hecho est prohibido

por normativa su uso salvo autorizacin por ICM

se debe indicar nombres de particiones del ndice por rango o por hash (Erwin 7 solo

permite por rango) y realizar la asignacin del tablespace de ndices.

En la opcin de men Indexes de la tabla seleccionada, en la pestaa Partitions:

o en el campo Partition Name: debe indicar el nombre de la particin de ndice global

particionado por rango

o en el campo atributo del ndice: para cada particin de ndice global particionado valor

correspondiente a LESS THAN o MAXVALUE

o pulsando el botn Edit Properties se debe seleccionar el tablespace de ndices en el

campo tablespace


51 de 112

NO

RM

A

TABIndicesPartGlobalAutorizacion

Salvo autorizacin expresa por parte de ICM Est prohibido el uso de ndices globales

particionados.

En caso de autorizarse, los Indices Globales Particionados deben tener asignado un tablespace

de Indices, para cada particin existente del ndice global particionado

En caso de autorizarse, los Indices Globales Particionados la nomenclatura de las particiones del

ndice global particionado debe ser:

[NOMBRE_INDICE_GLOBAL_PARTICIONADO]_PAR_[CRITERIO].


52 de 112

BU

EN

A

PR

AC

TIC

A

TABUsoIndicesPartGlobales

Indices Globales Particionados se particionan por hash o rango.(Erwin 7 solo permite por

rango)

Indices Globales Particionados deben ser prefijados (aparecen los campos de

particionamiento del ndice global particionado primero en el ndice, despus el campo por el

que se quiere indexar)

2.5 VISTAS

En este apartado se incluye toda la normativa referente a las vista de base de datos.

2.5.1 VISTAS Existen dos formas de definir una vista:

1) Componiendo la sentencia SQL automticamente: Arrastrando los campos a la

vista, la propia herramienta genera la sentencia SQL de la vista (utilizando las

pestaas Select, From y Where de la vista.

2) Definiendo la sentencia SQL manualmente: En la pestaa User Defined SQL de la

vista podemos establecer manualmente la sentencia SQL.

En cualquiera de los casos, es necesario rellenar tambin las pestaas Synonym y Comment. Adems,

el check CREATE OR REPLACE de la definicin de la vista deber estar obligatoriamente activado,

segn se muestra en la siguiente pantalla:


53 de 112

En las vistas definidas como User Defined SQL, no se debe incluir el ; al final de la definicin de la vista.


54 de 112

Adems, en estas vistas User Defined SQL no se deben incluir columnas en la zona Select, de forma

que en la visualizacin de la vista dentro del tapiz no se mostarn columnas:

Para garantizar que el script de generacin del modelo es correcto (las vistas aparecen creadas en el

orden correcto), si en la clusula FROM de las vistas User Defined SQL aparecen otras vistas, stas

deben indicarse tambin en la pestaa FROM.

Si no se informa en la pestaa FROM, las vistas que tenga en la clusula FROM , las vistas se generarn

en orden alfabtico por lo que podemos tener errores de compilacin por orden incorrecto.


55 de 112

A continuacin se muestran las reglas de la normativa aplicables a las vistas:

NO

RM

A

VISNombreVista

La nomenclatura de las vistas debe ser [XXXX]_V_[NOMBRE_VISTA], donde:


NOMBRE_VISTA: Nombre de la vista, en maysculas. Si contiene varias palabras pueden

separarse por guiones bajos (Ejemplo: ARTICULOS_CLIENTE).

Un ejemplo de nombre de vista correcto sera: AGCC_V_ARTICULOS_CLIENTE.


56 de 112

NO

RM

A VISCreateOrReplace

Todas las vistas del modelo debern tener activada la opcin CREATE OR REPLACE.

Adems, en caso de vistas con User Defined SQL, el cdigo de creacin de la vista deber

incluir CREATE OR REPLACE en su definicin.

NO

RM

A

VISUserDefinedPuntoYComa

En las vistas definidas como User Defined SQL, no se debe incluir el ; al final de la definicin

de la vista, ya que ERWIN lo aade automticamente al generar el script.

NO

RM

A

VISUserDefinedNoColumnas

Al visualizar una vista en el papel del tapiz definida como User Defined SQL, no se mostrar

ninguna columna.

NO

RM

A VISUserDefinedFrom

Para garantizar que el script de generacin del modelo es correcto (las vistas aparecen creadas

en el orden correcto), si en la clusula FROM de las vistas User Defined SQL aparecen otras

vistas, stas deben indicarse tambin en la pestaa FROM.

2.5.2 VISTAS MATERIALIZADAS

Las vistas materializadas son un tipo especial de vista que permite acelerar el acceso a la informacin,

creando copias fsicas del contenido de la vista (un tabla) en lugar de acceder al origen real de la

informacin. En este apartado se detallan las normas bsicas a tener en cuenta a la hora de crear vistas

materializadas en bases de datos de ICM. Estas normas estn orientadas a conseguir que la

implementacin impacte menos al rendimiento de las bases de datos y a facilitar la administracin y el

mantenimiento de las mismas.

Para el correcto mantenimiento de las vistas, hay que tener en cuenta que cualquier cambio en la

estructura de la tabla origen (aadir o cambiar de tipo de una columna) puede hacer que el refresco de

las vistas materializadas creadas sobre ella dejen de funcionar con lo que debera comunicarse a los

departamentos encargados del mantenimiento de las mismas.

A continuacin se muestran una serie de normas y buenas prcticas relativas a las vistas materializadas:

BU

EN

A

PR

AC

TI

CA

VISMatDefinicion

Buenas prcticas sobre el uso de vistas materializadas:

Para evitar trfico de red y duplicidad innecesaria de datos, se recomienda incluir el


57 de 112

mnimo nmero de columnas posibles en las vistas materializadas.

Se crearn los ndices necesarios para que las consultas sobre las vistas

materializadas sean rpidas.

NO

RM

A

VISMatProhibido

Se prohbe el uso de vistas materializadas en modelos de datos de ICM, salvo autorizacin

expresa.

NO

RM

A

VISMatNombre

La nomenclatura de las vistas materializadas debe ser [XXXX]_MV_[NOMBRE_VISTA], donde:


NOMBRE_VISTA: Nombre de la vista materializada, en maysculas. Si contiene varias

palabras pueden separarse por guiones bajos (Ejemplo: ARTICULOS_CLIENTE).

Un ejemplo de nombre de vista materializada correcto sera: AGCC_MV_ARTICULOS_CLIENTE.

NO

RM

A

VISMatLectura

Todas las vistas materializadas sern de slo lectura.

Siempre que creemos una vista materializada en el modelo, debemos activar la opcin Physical

Properties de la pestaa General, y en el cuadro de dilogo Storage Properties asignar el tablespace

de datos (TBSDAT_XXXX_100), segn se muestra en la siguiente figura:


58 de 112

En la siguiente norma se fuerza a que todas las vistas materializadas tengan asignado este tablespace:

NO

RM

A

VISMatTablespace

Todas las vistas materializadas del modelo debern obligatoriamente tener activada la opcin

Physical Properties, y tener asignado el tablespace de datos (TBSDAT_XXXX_100).

2.5.2.1 REFRESCO DE VISTAS MATERIALIZADAS


59 de 112

Las sentencias que definen el refresco de las vistas materializadas no se incluirn en la definicin del

modelo ERWIN, ya que son creadas manualmente por el personal de ICM (utilizando un Job). En lugar de

esto, en la solapa de comentarios de la vista materializada se incluir la siguiente informacin de refresco:

Volumetra estimada de la vista materializada y, en su caso, del log de vista materializada.

Tipo (completo/incremental)

Frecuencia (diario, semanal )

Si debe actualizarse junto con otras vistas materializadas o puede hacerse de manera individual.

El refresco se programar a lo largo de la noche teniendo en cuenta el tiempo que lleva y los horarios de

backup de las bases de datos implicadas. Salvo autorizacin expresa, la frecuencia del refresco de las

vistas materializadas ser diaria o superior (semanal, mensual, etc.).

No se permite el refresco incremental de vistas materializadas. En casos excepcionales, debidamente

justificados, puede permitirse la utilizacin de refresco incremental teniendo en cuenta las siguientes

consideraciones:


60 de 112

En ningn caso se permitir el refresco incremental por ROWID. Por tanto, si la tabla sobre la que

se crea la vista debe tener primary key. En caso contrario, el refresco ser forzosamente completo.

nicamente se estudiar la posibilidad de refresco incremental en caso de que los tiempos del

refresco completo sean inviables para el funcionamiento de la aplicacin. Esto puede ocurrir por

varias razones, entre otras:

o Las tablas originales muy grandes1

o Lnea de comunicacin lentas entre las dos bases de datos

o Se requieren actualizaciones frecuentes

Dado que el refresco incremental supone la creacin y mantenimiento en la base de datos donde

reside la tabla origen de un log de vista materializada, la autorizacin de este tipo de refresco

estar siempre condicionada a que el impacto en el rendimiento de la base de datos origen sea

asumible por las aplicaciones que se ejecutan en ella. Esto puede presentar problemas

especialmente en tablas con muchas actualizaciones.

NO

RM

A

VISMatNoRefresco

Las sentencias que definen el refresco de las vistas materializadas no se incluirn en la definicin

del modelo ERWIN.

NO

RM

A

VISMatComentario

En la solapa de comentarios de la vista materializada se incluir la siguiente informacin de

refresco:

Volumetra estimada de la vista materializada y, en su caso, del log de vista materializada.

Tipo (completo/incremental)

Frecuencia (diario, semanal )

Si debe actualizarse junto con otras vistas materializadas o puede hacerse de manera

individual.

NO

RM

A

VISMatTipoRefr

Las vistas materializadas por defecto tendrn el tipo de refresco bajo demanda (DEMAND). Los

refrescos peridicos se planificarn de manera externa a la base de datos.

NO

RM

A

VISMatFrecuenciaRefr

Salvo autorizacin expresa, la frecuencia del refresco de las vistas materializadas ser diaria o

superior (semanal, mensual, etc.).


61 de 112

NO

RM

A

VISMatMetodoRefr

Las vistas materializadas por defecto se refrescarn con el mtodo de refresco completo. Salvo

autorizacin expresa, no se permite el refresco incremental de vistas materializadas.

2.6 SECUENCIADORES

Los Secuenciadores se crean como un objeto de tipo Sequence, segn se muestra en el siguiente ejemplo:

NO

RM

A

SECNombreSecu

La nomenclatura de los secuenciadotes debe ser [XXXX]_S_[NOMBRE_SECUENCIADOR],

donde:


NOMBRE_SECUENCIADOR: Nombre del secuenciador, en maysculas. El nombre del

secuenciador debe ser representativo del nombre de la tabla/campo para el que se utiliza.

Si contiene varias palabras pueden separarse por guiones bajos.

Un ejemplo de nombre de secuenciador correcto sera: AGCC_S_ARTICULOS_CLIENTE.


62 de 112

N

OR

MA

SECNombreSecuPK

Los secuenciadores utilizados para generar los valores de las primary keys tendrn la siguiente

nomenclatura: [XXXX]_S_[NOMBRE_TABLA_SIN_PREFIJO], donde:


NOMBRE_TABLA_SIN_PREFIJO: Nombre de la tabla que contiene la PK para la que se

usa el secuenciador, sin el prefijo del cdigo del proyecto.

Ej: AGCC_S_ARTICULOS_CLIENTE para la tabla AGCC_ARTICULOS_CLIENTE

2.7 PROCEDIMIENTOS, FUNCIONES Y PACKAGES

Los procedimientos y funciones deben crearse a nivel de modelo (Model-level), y no a nivel de tabla.

Es importante ordenar los procedimientos, funciones y paquetes con Objetct Creation Order, de manera

que el orden de creacin haga que las dependencias compilen correctamente.

En este tipo de objetos debe estar marcado el check Create or Replace, segn se muestra en esta figura:


63 de 112

A continuacin se muestran las normas relativas a procedimientos funciones y packages:

NO

RM

A

PFPAgruparEnPaquetes

Todos los procedimientos y funciones estarn agrupados en paquetes de base de datos. No

existirn procedimientos y/o funciones aislados fuera de paquetes, salvo autorizacin excepcional.

NO

RM

A PFPLocalizacion

Los Paquetes, Procedimientos y Funciones debern situarse dentro del modelo ERWIN cada uno

dentro de la carpeta correspondiente a su tipo (no se pueden colocar paquetes o funciones en la

carpeta de procedimientos, etc.).

NO

RM

A

PFPNombreProc

No existe nomenclatura para los procedimientos creados dentro de un paquete, el nombre de

estos objetos es libre.

En el caso de existir Autorizacin Excepcional para crear Procedimientos fuera de un Paquete la

nomenclatura de los procedimientos ser [XXXX]_PROC_[NOMBRE_PROC], donde:


NOMBRE_PROC: Nombre del procedimiento almacenado. Si contiene varias palabras

pueden separarse por guiones bajos.

Un ejemplo nombre de procedimiento correcto sera: AGCC_PROC_ACTUALIZA_VALORES

NO

RM

A

PFPNombreFunc

No existe nomenclatura para las funciones creadas dentro de un paquete, el nombre de estos

objetos es libre.

En el caso de existir Autorizacin Excepcional para crear Funciones fuera de un Paquete la

nomenclatura de las funciones ser [XXXX]_FUNC_[NOMBRE_FUNC], donde:


NOMBRE_FUNC: Nombre de la funcin. Si contiene varias palabras pueden separarse

por guiones bajos.

Un ejemplo nombre de funcin correcto sera: AGCC_FUNC_ACTUALIZA_VALORES


64 de 112

NO

RM

A

PFPNombrePaq

La nomenclatura de los paquetes ser [XXXX]_PACK_[NOMBRE_PACK], donde:


NOMBRE_PACK: Nombre del paquete. Si contiene varias palabras pueden separarse por

guiones bajos.

Un ejemplo nombre de paquete correcto sera: AGCC_PACK_GENERAL

NO

RM

A

PFPCreateOrReplace

Se deber activar la casilla Create or Replace en los objetos de tipo procedimiento, funcin y

paquete, as como en todos los objetos que lo admitan.

NO

RM

A PFPOrden

Se deber realizar una correcta ordenacin de los objetos de tipo procedimiento, funcin y

paquete (utilizando la pestaa Object Creation Order), de manera que se permita su ejecucin

secuencial sin errores de compilacin.

NO

RM

A

PFPOtrosEsquemas

No se permite incluir en un modelo paquetes, procedimientos o funciones de esquemas externos

(que no sean del esquema propio).

NO

RM

A

PFPCommitRollback

No se permite incluir en ningn paquete, procedimiento o funcin instrucciones del tipo COMMIT o

ROLLBACK.

Es muy importante hacer una correcta gestin de errores en los paquetes, procedimientos y funciones,

asegurando que existe control sobre las posibles excepciones que puedan ocurrir durante su ejecucin. A

continuacin se muestran varios ejemplos de gestin de excepciones, los primeros de forma general, y el

segundo controlando las excepciones por separado:

Ejemplo: gestin de excepciones agrupadas

---------------------------------------------------------------------------

--- Ejemplo 1 -----

---------------------------------------------------------------------------

EXCEPTION

WHEN OTHERS THEN

RAISE_APPLICATION_ERROR ( -20070,

'ERROR '|| '(Cdigo: ' || to_char(SQLCODE) || ')' ||


65 de 112

' - Error general al realizar el proceso.' );

END ;

---------------------------------------------------------------------------

--- Ejemplo 2 -----

---------------------------------------------------------------------------

EXCEPTION

WHEN OTHERS THEN

>

END ;

---------------------------------------------------------------------------

--- Ejemplo 3 -----

---------------------------------------------------------------------------

EXCEPTION

WHEN OTHERS THEN

bResultado_OK := FALSE ;




END ;

Ejemplo: gestin de excepciones detallada

---------------------------------------------------------------------------

--- Control de Errores del Proceso de Actualizacin. -----

---------------------------------------------------------------------------

DECLARE

ERROR_PREDEFINIDO_USUARIO EXCEPTION;

BEGIN

>

RAISE ERROR_PREDEFINIDO_USUARIO; --> Ejecucin de

exception predefinida.

>

EXCEPTION

WHEN ERROR_PREDEFINIDO_USUARIO THEN

>

WHEN TOO_MANY_ROWS THEN

>

WHEN DUP_VAL_ON_INDEX THEN

>

WHEN INVALID_NUMBER THEN

>

WHEN NO_DATA_FOUND THEN

WHEN VALUE_ERROR THEN



' - No fue posible la conversin de valores.' );

WHEN OTHERS THEN



66 de 112



END ;

En la gestin de excepciones, como mnimo se exigir el tratamiento de OTHERS, no pudindose en

ningn caso ignorar la excepcin ocurrida, utilizando NULL, segn el siguiente ejemplo:

Ejemplo: gestin de excepciones detallada

----------------------

bbdd_normativa

Documents