Normativa de Modelado de Bases de
Datos y Uso de la Herramienta ERWIN
Versión 1.17
2 de 124 Hoja de Control
Título Normativa de Modelado de Bases de Datos y Uso de la herramienta ERWIN Documento de
Referencia
Responsable Área de Integración y Arquitectura de Aplicaciones
Versión 1.17 Fecha Versión 24/06/2015
Registro de Cambios
Versión Causa del Cambio Responsable del
Cambio Fecha
1.0 Versión inicial del documento, se parte de la normativa para una versión anterior de la herramienta ERWIN
Área de Integración 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 Integración y Arquitectura de
Aplicaciones
16/09/2011
1.2
- PLANTILLAS XML: Cambio de plantillas de
generación de scripts para valores default de columnas - PLANTILLAS FET: Cambio de plantillas ".fet", no generaba saltos de línea en los paquetes.
- TABObligaPK: Las tablas que representan
relaciones muchos a muchos no tienen que llevar PK única, independientemente de que tengan más campos.
- GENObjetosMayuscula: Los objetos no pueden contener la letra eñe.
- 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 específica.
- CARScriptTemplates: No se permite ningún 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 Integración y Arquitectura de
Aplicaciones
13/10/2011
1.3
- PLANTILLAS XML: Cambio de plantillas de generación de scripts
- PLANTILLAS FET: Cambio de plantillas ".fet", incorporada una barra al final de los “Packages”. - PLANTILLA DE PARTIDA: Modificado “custom
Área de Integración y Arquitectura de
Aplicaciones
3 de 124
Versión Causa del Cambio Responsable del
Cambio Fecha
trigger template ICM” para no incluir la barra al final de los triggers.
- Apartado 5: Incluído 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 número de versión.
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 versión del modelo del nombre del fichero.
- GENUDPs: Nueva UDP a nivel del modelo para indicar la versión.
- GENVersion: Nueva norma, cada vez que se hace una entrega hay que incrementar la versión 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 módulo de base de datos. - Templates: Unificados los dos templates anteriores en uno sólo: 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 Integración 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: Excluídos los tablespaces de modelos de Business Objects de esta norma.
- BOBDefTablespaces: Nueva norma.
Área de Integración y Arquitectura de
Aplicaciones
4 de 124
Versión Causa del Cambio Responsable del
Cambio Fecha
1.6
- Apartado 5: Antes de entregar, si el modelo ya se encuentra instalado en producción, comparar con la base de datos de preproducción.
- VISUserDefinedFrom: En las vistas definidas como “User Defined SQL”, si en la claúsula FROM aparecen otras vistas del Modelo de datos, éstas vistas deben indicarse en la pestaña FROM para que en la ejecución del script se generen en el orden correcto
Área de Integración y Arquitectura de
Aplicaciones
16/01/2013
1.7
- Apartado 2.1.3: En Buena Práctica 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 comparación, se utilizará el script proporcionado : ICM_TYPE_SELECTION_VX_Y.xml - Apartado 5: borrado: “(Si se
está comparando contra la base de datos de preproducción de ICM, se utilizará
ICM_TYPE_SELECTION_PPRO_VX_Y.xml)” Área de Integración y Arquitectura de Aplicaciones 29/07/2013 1.8
- Incluído nuevo Apartado 3.4 para Modelos muy grandes que se dividen envarios ficheros ERWIN y varios DBAs. Área de Integración 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 prohíbe 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 práctica TABReutilizarCheck desaparece
- Se añaden las normas: TABMaxCheck y TABColNameCheck Área de Integración y Arquitectura de Aplicaciones 29/07/204 1.10
- En el apartado 2.7 Se incorpora una nueva norma PFPOutput Área de Integración 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 Integración y Arquitectura de
Aplicaciones
02/10/2014
1.12 - En el apartado 3.3 se adapta la normativa documentum a erwin 7
Área de Integración 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 Integración y
5 de 124
Versión Causa del Cambio Responsable del
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 añadido la norma TABPartPasoProduccion 17/10/2014
1.15
- En el apartado 2.4.1 se añade excepción 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
Autorización Excepcional) Área de Integración y Arquitectura de Aplicaciones 26/11/2014 1.16
Se añaden y actualizan los siguientes apartados, normas:
2.1.2 PROYECTO Y MÓDULOS
2.1.2.1 VARIOS MODULOS DE BASES DE DATOS EN UN MISMO PROYECTO
GENVariosModulosBBDD
2.1.2.2 DEFINICION DE MODELOS DE DATOS INSTITUCIONAL Y DEPARTAMENTAL
GENMod_Ins_Dep
2.1.2.3 DEFINICION DE MODELOS DE DATOS MUY GRANDES
GENMod_Gran
3.4 VARIOS MODELOS DE DATOS PARA UN MISMO PROYECTO MULVariosModulosBBDD MULGENNombreFich MULTABNombreTabla MULSECNombreSecu MULSECNombreSecuPK MULVISNombreVista MULTBSDefTablespaces MULOtrosObjetos MULRepetidos Área de Integración y Arquitectura de Aplicaciones 24/06/2015 1.17
Se modifica la Norma TBSDefTablespaces y MULTBSDefTablespaces para que el tablespace de lob solamente aparezca en el modelo de datos si existen campos lob
Se modifica en la norma TABNombreCheck
(lo mas descriptivo posible) por : (breve descripción).
Se añade la norma: TABNameConstrValidCheck Se añade la norma: TABUsoCheck
Se añade la buena práctica TABNameConstrActBD
Se añade el punto 2.4.8.2 Default Values
Área de Integración y Arquitectura de
Aplicaciones
6 de 124
Versión Causa del Cambio Responsable del
Cambio Fecha
En el apartado de Sinónimos Remotos Se añade la norma:
7 de 124 Índice 1 INTRODUCCION ... 9 1.1 AUDIENCIAOBJETIVO ... 9 1.2 CONOCIMIENTOSPREVIOS ... 9 2 NORMATIVA ... 10 2.1 NORMATIVAGENERAL ... 10 2.1.1 HERRAMIENTA ... 10 2.1.2 PROYECTO Y MÓDULOS ... 10
2.1.2.1 VARIOS MODULOS DE BASES DE DATOS EN UN MISMO PROYECTO ... 10
2.1.2.2 DEFINICION DE MODELOS DE DATOS INSTITUCIONAL Y DEPARTAMENTAL ... 11
2.1.2.3 DEFINICION DE MODELOS DE DATOS MUY GRANDES ... 12
2.1.3 PLANTILLA DE PARTIDA... 14
2.1.4 PROTECCIÓN DE DATOS ... 16
2.1.5 USER DEFINED PROPERTIES ... 17
2.1.6 DOCUMENTACIÓN DEL MODELO ... 19
2.1.7 INTEGRIDAD REFERENCIAL ... 21
2.1.8 SEGURIDAD DE OBJETOS (PERMISOS Y SINONIMOS) ... 22
2.1.9 SCRIPT TEMPLATES ... 24
2.1.10 PROPIETARIO DE LOS OBJETOS ... 24
2.1.11 OBJETOS DUPLICADOS ... 25
2.1.12 NOMENCLATURA GENERAL DE OBJETOS... 26
2.2 ESTRUCTURADELMODELOYÁREASDEDISEÑO ... 26
2.3 TABLESPACES ... 29
2.4 TABLAS ... 30
2.4.1 TABLAS ... 30
2.4.2 TABLAS GLOBAL TEMPORARY ... 34
2.4.3 PRIMARY KEYS ... 35
2.4.4 FOREIGN KEYS ... 37
2.4.5 ALTERNATE KEYS ... 39
2.4.6 INDICES ... 40
2.4.7 COLUMNAS LOB (BLOB y CLOB) ... 43
2.4.8 CHECKS Y VALORES POR DEFECTO A NIVEL DE COLUMNA ... 44
2.4.8.1 CHECKS ... 44
2.4.8.2 DEFAULT VALUES ... 50
2.4.9 TRIGGERS ... 51
2.4.9.1 TRIGGERS ESPECIALES PARA TRAZABILIDAD DE ACCESO ... 54
2.4.10 PARTICIONES Y SUBPARTICIONES DE TABLA ... 54
2.4.10.1 ASIGNACION DE TABLESPACES A PARTICIONES DE TABLAS Y A INDICES LOCALES PARTICIONADOS Y GLOBALES PARTICIONADOS ... 56
2.4.10.1.1 INDICES LOCALES PARTICIONADOS ... 57
2.4.10.1.2 INDICES GLOBALES ... 58
2.4.10.1.3 INDICES GLOBALES PARTICIONADOS ... 59
2.5 VISTAS ... 61
2.5.1 VISTAS ... 61
2.5.2 VISTAS MATERIALIZADAS ... 65
2.5.2.1 REFRESCO DE VISTAS MATERIALIZADAS ... 67
2.6 SECUENCIADORES ... 70
2.7 PROCEDIMIENTOS,FUNCIONESYPACKAGES ... 71
2.7.1 PAQUETES ESPECIALES (TRAZAS Y SERVICIOS WEB) ... 75
2.8 OTROSOBJETOS ... 76
2.8.1 SINONIMOS REMOTOS ... 76
2.8.2 ROLES ... 79
2.8.3 JOBS ... 80
2.9 CARGASDEDATOS ... 81
2.9.1 CARGAS DE DATOS INICIALES ... 81
2.9.2 CARGAS DE DATOS DE ENTORNO ... 82
2.9.3 CARGA DE FICHEROS LOB (CLOB y BLOB) ... 84
3 NORMATIVA ADICIONAL PARA ENTORNOS ESPECIFICOS ... 84
3.1 APLICACIONESGIS ... 85
3.2 APLICACIONESBUSINESSOBJECTS ... 85
8 de 124 3.2.2 SUBÁREAS ... 85 3.2.3 NOMENCLATURA DE OBJETOS ... 85 3.2.4 ROLES ... 86 3.3 APLICACIONESDOCUMENTUM ... 88 3.3.1 SUBÁREAS ... 88
3.3.2 SINÓNIMOS REMOTOS PRIVADOS ... 88
3.3.3 SECUENCIAS ... 89
3.3.4 TRIGGERS ... 91
3.4 VARIOSMODELOSDEDATOSPARAUNMISMOPROYECTO ... 93
4 OTRAS CONSIDERACIONES ... 100
4.1 USODECATÁLOGOSCOMUNESYACCESOAOTROSESQUEMAS ... 100
4.2 GENERACIÓNDESCRIPTS ... 100
4.3 DESBORDAMIENTOENNOMBRESDEÍNDICES,PK,FKYTRIGGERS ... 102
4.4 SENTENCIASSQLPERMITIDAS,YBUENASPRÁCTICAS... 103
4.5 BÚSQUEDASTEXTUALES(INTERMEDIATEXT) ... 104
4.5.1 DEFINICIÓN DE INDICES DE INTERMEDIA TEXT ... 104
4.5.2 THESAURUS DE INTERMEDIA TEXT ... 105
5 ANTES DE ENTREGAR: COMPARACIÓN DEL MODELO CONTRA BASE DE DATOS ... 107
6 FORMATO DE ENTREGA ... 119
A1.1 NORMAS ... 120
9 de 124 1 INTRODUCCION
La presente guía presenta la normativa de modelado de Bases de Datos y uso de la herramienta ERWIN para las aplicaciones desarrolladas para Informática 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 definición 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
RMA
NombreDeNorma Contenido de la norma.
o Buenas prácticas: 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:
BUE
NA
PR
A
C
T
IC
A
NombreDeBuenaPractica Contenido de la Buena Práctica.
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, diseño de modelos de datos relacionales y la herramienta de diseño y modelado ERWIN.
10 de 124 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 Versión 7. Esto asegura homogeneidad en todos los proyectos, y documentación del modelo de datos centralizada.
NO
RMA
GENHerramienta
Todo modelo de datos debe estar realizado con la herramienta ERWIN 7.3.8.2235 (Service Pack 2).
2.1.2 PROYECTO Y MÓDULOS
Un proyecto en ICM puede contener varios módulos, entre ellos el que contiene la definición del modelo de datos. El módulo de base de datos se incluye dentro de la entrega según la nomenclatura y estructura de ficheros definidas en el apartado “”FORMATO DE ENTREGA”.
2.1.2.1 VARIOS MODULOS DE BASES DE DATOS EN UN MISMO PROYECTO
Excepcionalmente puede ocurrir que un proyecto tenga 2 o más módulos de definición de Modelo de datos, por ejemplo:
· Modelo de datos INSTITUCIONAL y Modelo de datos de DEPARTAMENTAL · Modelo de datos en BO y modelo de datos en Oracle.
· Modelos de datos MUY GRANDES que para su mantenimiento, es aconsejable que se dividan en varios módulos técnicos de tipo modelo de datos.
· Otros casos según necesidades del proyecto
NO
RMA
GENVariosModulosBBDD
Todo proyecto que necesite tener 2 o más módulos de base de datos asociados a un mismo código POAP´s ó proyecto (XXXX) debe solicitar autorización expresa a ICM antes de la construcción de dichos modelos.
11 de 124
2.1.2.2 DEFINICION DE MODELOS DE DATOS INSTITUCIONAL Y DEPARTAMENTAL
NO
RM
A
GENMod_Ins_Dep
Aquellos Modelos de datos en cuya definición se contemplen grupos de objetos diferentes que se deban
generar en diferentes bases de datos (por ejemplo: base de datos Institucional y bases de datos
Departamentales) y asociados al mismo proyecto, deberán :
1. Solicitar autorización a ICM para la construcción de un Modelo de datos por cada grupo diferenciado de objetos que se deban generar en diferentes bases de datos antes de la construcción de los Modelos de datos.
2. Al código de aplicación (POAPs) : XXXX se le añadirá un sufijo (INS o DEP) seguido de la
tecnología: MODD para diferenciar los distintos módulos técnicos de tipo modelo de datos de ese proyecto:
Modelo de datos Institucional: XXXX_INS_MODD
Modelo de datos Departamental: XXXX_DEP_MODD
El sufijo (INS o DEP) debe aplicarse a la nomenclatura de carpetas (en subversión) y ficheros (.erwin) así como a todos los objetos de base de datos: nombres de tablas, vistas, secuencias, dba´s, tablespaces, packages, procedures, sinónimos… El sufijo (INS o DEP) debe figurar siempre a continuación del código POAP´s.
Carpeta/Nombre de ficheros erwin: xxxx_ins_modd/XXXX_INS-ERW.erwin xxxx_dep_modd/XXXX_DEP-ERW.erwin Esquemas Propietarios de base de datos: DBA_XXXX_INS
DBA_XXXX_DEP
Objetos: Tablas,Indices, Vistas, Secuencias, Tablespaces, Packages, Procedures, Sinónimos,…..: XXXX_INS_TABLA1 XXXX_INS_V_EXPEDIENTE XXXX_DEP_S_INTERESADO TBSDAT_XXXX_INS_100 TBSDAT_XXXX_DEP_100 …
3. En un modelo de datos institucional XXXX_INS-ERW.erwin y un modelo de datos departamental XXXX_DEP-ERW.erwin los objetos que generen ambos modelos (objetos con el check de Generate activado) deben ser diferentes, es decir no pueden tener objetos repetidos en los dos Modelos (Institucional y Departamental).
4. Estos modelos de datos van a generarse en diferentes bases de datos por lo tanto no pueden existir RelationShips entre objetos del Modelo de datos Institucional y Departamental
12 de 124 2.1.2.3 DEFINICION DE MODELOS DE DATOS MUY GRANDES
13 de 124
NO
RM
A
GENMod_Gran
Aquellos Modelos de datos MUY GRANDES que para ser manejables pueden desglosarse en varios
modelos de datos agrupando lógicamente los objetos , deberán :
5. Solicitar autorización a ICM para la construcción de un Modelo de datos por cada agrupación lógica de objetos antes de la construcción de los Modelos de datos.
6. Al código de aplicación (POAPs) : XXXX se le añadirá un sufijo (YYY) seguido de la tecnología:
MODD para diferenciar los distintos módulos técnicos de tipo modelo de datos de ese proyecto:
XXXX_YYY_MODD
(XXXX es el código de proyecto)
(YYY es el código de agrupación lógica de objetos pertenecientes al proyecto, puede contener como Mínimo 1 carácter y como Máximo 3 carácteres)
(MODD es la tecnología del módulo técnico: modelo de datos)
El sufijo (YYY) debe aplicarse a la nomenclatura de carpetas (en subversión) y ficheros (.erwin) así como a odos los objetos de base de datos: nombres de tablas, vistas, secuencias, dba´s,
tablespaces, packages, procedures, sinónimos…. El sufijo (YYY) debe figurar siempre a continuación del código POAP´s.
Carpeta/Nombre de ficheros erwin: xxxx_sc1_modd/XXXX_SC1-ERW.erwin xxxx_sc1_modd/XXXX_SC2-ERW.erwin xxxx_tl1_modd/XXXX_TL1-ERW.erwin Esquemas Propietarios de base de datos: DBA_XXXX_SC1
DBA_XXXX_SC2 DBA_XXXX_TL1
Objetos: Tablas,Indices, Vistas, Secuencias, Tablespaces, Packages, Procedures, Sinónimos…..: XXXX_SC1_TABLA1 XXXX_SC1_V_EXPEDIENTE XXXX_SC2_S_INTERESADO TBSDAT_XXXX_SC1_100 TBSDAT_XXXX_SC2_100 …
7. Los objetos de cada Modelo de datos XXXX_YYY-ERW.erwin que se generen (objetos con el check de
Generate activado) deben ser diferentes, es decir no puede haber objetos repetidos . (En todos los modelos podrán aparecer objetos iguales , pero estos no tendrán el check de generate) es decir la genereación sql de cada proyecto deberá ser diferente, no habrá objetos repetidos generados en sql
14 de 124 2.1.3 PLANTILLA DE PARTIDA
ICM establece una serie de estándares para la realización de modelos de datos, además de una plantilla de partida que debe utilizarse como base para su realización (Fichero “XXXX-ERW.erwin”).
NO
RMA
GENPlantillaFich El Modelo de datos Erwin se debe construir a partir de la plantilla XXXX-ERW.erwin.NO
RMA
GENNombreFich
La Nomenclatura del fichero erwin debe ser: XXXX-ERW.erwin donde: · XXXX: Nombre del proyecto (Ejemplo: AGCC)
BUE
NA
PR
A
C
T
IC
A
GENEjemploPara ver un ejemplo de fichero de ERWIN bien formado, se recomienda consultar el archivo publicado en la web de SOJA denominado AGCC-ERW.erwin
En la plantilla de partida viene configurado el tipo de base de datos por defecto (Oracle V9.X), según se muestra en la siguiente figura:
No se puede modificar esta configuración, debiendo siempre estar configurada esta base de datos, según se muestra en la siguiente norma:
15 de 124
NO
RM
A
GENVersionOracleTodo modelo de datos estará configurado para la base de datos Oracle Versión 9.x
En la plantilla de partida también viene configurada la notación que utiliza el modelo. Dicha notación no se podrá modificar, según se muestra en la siguiente figura:
NO
RMA
GENNotacionIDEF1X
Todo modelo de datos estará configurado con la notación 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 opción de menú “Tools -> Names -> Model Naming Options…”:
16 de 124
BUE
NA
PR
A
C
T
IC
A
GENNamingOptionsSe 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 PROTECCIÓN DE DATOS
Si el modelo incluye tablas que contengan datos personales susceptibles de ser tratados de forma especial según la LOPD, se tendrá en cuenta el tratamiento especial de estas tablas según la ley aplicable
(consultar documento específico sobre protección de datos).
NO
RMA
GENTratarLOPD
Si los datos contenidos en el modelo son de nivel de protección alto (nivel 3), se tendrá que implementar la auditoría de acceso a los datos con los mecanismos disponibles.
Asimismo se creará un área de diseño específica que contenga los objetos afectados, y en la descripción del modelo se incluirá un listado de las tablas que contengan datos personales de nivel alto.
17 de 124
NO
RMA
GENAltaFicheroLOPD
Si el modelo incluye tablas que contengan datos personales, se tendrá que gestionar el alta del fichero en la Agencia de Protección 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 producción del modelo de datos.
2.1.5 USER DEFINED PROPERTIES
En la plantilla de partida se encuentran definidas a nivel de modelo varias UDP’s (User Defined Properties), que incluyen información sobre la versión de la plantilla, la versión de la normativa de Base de Datos a la que afecta, y la versión del modelo que estamos tratando:
18 de 124
NO
RM
A
GENUDPs
Todo modelo debe contener al menos las siguientes UDPs (User Defined Properties), vienen incluídas en la plantilla de partida:
- VERSION PLANTILLA: Indica la versión de la plantilla que se ha utilizado como punto de partida para el modelo.
- VERSION NORMATIVA: Indica la versión de la normativa de base de datos que debe cumplir el modelo.
- VERSION MODELO: Indica la versión actual del modelo ERWIN.
- DESTINO GRANT: Indica el usuario al que se hará GRANT cada vez que se cree un sinónimo público. Su valor deberá ser “PUBLIC” excepto en modelos de datos de Business Objects.
NO
RM
A
GENVersion
Cada vez que se introduzca una modificación al modelo ERWIN y se pretenda instalar esta nueva versión en alguno de los entornos de ICM, deberá modificarse el valor de la UDP cuyo nombre es VERSION MODELO, para incrementar la versión.
Las Unidades de Recepción de Aplicación y de Paso a Producción no instalarán un modelo si no se ha modificado dicha versión.
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 modificación de la UDP de la siguiente manera:
1. Pulsar opción de menú: Model -> Model Properties .
2. Pulsar la pestaña UDP .
En esta pestaña tenemos que modificar el valor, pero no es suficiente con ello, también tenemos que hacerlo en el diccionario de UDPs, siguiendo el paso 3.
19 de 124
Es necesario también modificar el valor en esta nueva pantalla:
2.1.6 DOCUMENTACIÓN DEL MODELO
En todo modelo de datos, cada uno de los objetos generados debe tener rellena la pestaña “Comentario”, indicando una descripción del objeto al que hace referencia.
NO
RMA
GENComentarios
Todos los objetos del modelo deben tener rellena la pestaña “Comentario” con una descripción del objeto en cuestión, y la documentación necesaria asociada al objeto.
20 de 124
Además, el modelo a nivel general debe tener también comentarios indicando la información sobre el modelo, según se muestra en la siguiente pantalla:
NO
RMA
GENComentariosModelo
Se debe rellenar la pestaña “Definition” de las propiedades del modelo, con la descripción general del modelo, así como un listado de las tablas que contengan datos personales sensibles para la Ley de Protección de Datos de nivel alto.
Asimismo, cada área de diseño del modelo también debe tener una descripción general, rellena en la pestaña “Definition” según se muestra en la siguiente pantalla:
21 de 124
NO
RMA
GENComentariosAreas
Se debe rellenar la pestaña “Definition” de las propiedades de cada una de las áreas del modelo, con la descripción 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 definición dentro de la herramienta ERWIN.
En los modelos de datos desarrollados para ICM, salvo autorización expresa, se debe utilizar integridad referencial basada en Primary Keys y Foreign Keys. Además se debe seguir una nomenclatura específica para estas claves (la plantilla de partida ya está configurada para seguir esta nomenclatura). Para consultar la nomenclatura de las PK’s y FK’s pueden consultarse los apartados concretos que hablan de este tipo de objetos.
22 de 124
NO
RMA
GENIntReferencial
En los modelos de datos desarrollados para ICM, salvo autorización expresa por parte del Área de Integración 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 relación. 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 sinónimo público asociado, así como un GRANT que concede permisos sobre ese sinónimo a todos los usuarios (PUBLIC). Mientras que el sinónimo se asigna con un check en la definición del objeto, para realizar el GRANT se hace automáticamente durante la generación del script asociado (para eso se utilizan plantillas de generación propias de ICM – los “.fet”).
A continuación se muestra un ejemplo de tabla con un sinónimo creado (el nombre debe ser igual al nombre de la tabla), y con el check de creación del sinónimo público y “create or replace” activados:
23 de 124
Además del sinónimo público que todo objeto lleva asociado, desde esta pantalla se pueden crear otros sinónimos para el objeto si son necesarios.
A continuación se listan una serie de normas que garantizan que la creación de sinónimos sea correcta:
NO
RMA
GENAsignarSinonimo
Para modelos de datos, todos los objetos de base de datos creados de tipo tabla, secuencia, vista, procedimiento, función y paquete deben llevar asociado un sinónimo público que se llamará igual que el objeto.
El sinónimo siempre se creará en las propiedades del objeto en la pestaña Sinónimo como público, y tendrá activados los checks de “Generate” y “Create or Replace”.
* Para modelos de datos de Documentum consultar la documentación específica de esta tecnología.
24 de 124
NO
RMA
GENSinonimoAdicional
En ocasiones excepcionales, además del sinónimo público que todo objeto debe llevar asociado, se pueden crear otros sinónimos adicionales (que por tanto no se llaman igual que el nombre del objeto que representan).
En ese caso, el nombre de estos sinónimos debe ser identificativo del uso que se quiera dar al sinónimo.
En todos los modelos de datos físicos, a los objetos de base de datos con sinónimo público no remoto se les asigna automáticamente un “GRANT ON NombreObjeto TO PUBLIC WITH GRANT OPTION”.
Esto se realiza automáticamente al utilizar la plantilla ICM_TEMPLATE_COMUN_VX_Y.fet durante la generación del script SQL, por lo que no es necesario realizar nada adicional en el modelo ERWIN.
NO
RM
A
GENNoGrants
No se deberán asignar GRANTS manualmente a los sinónimos públicos de los objetos, ya que esto se hace automáticamente al generar los scripts.
* Excepcionalmente, para los modelos de aplicaciones Documentum, GIS ó Business Objects consultar las normas específicas para estas tecnologías.
2.1.9 SCRIPT TEMPLATES
NO
RMA
GENScriptTemplates
No se permite la inclusión de Script Templates a nivel de modelo (“Model Level”), salvo autorización excepcional por parte de ICM.
2.1.10 PROPIETARIO DE LOS OBJETOS
En todo modelo de datos, todos los objetos que permitan la opción de definir el “Owner” deben tenerlo definido correctamente, según se muestra en la siguiente figura:
25 de 124
NO
RMA
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 situación suele producirse por un desconocimiento de la herramienta ERwin por parte del diseñador, que en lugar 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 la base de datos.
26 de 124
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 creación se intenta crear dos veces el objeto y falla su ejecución.
2.1.12 NOMENCLATURA GENERAL DE OBJETOS
Adicionalmente a la nomenclatura específica de cada tipo de objeto, a continuación 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 MAYÚSCULA, y sólo pueden contener caracteres alfanuméricos no acentuados y guiones bajos. No pueden contener la letra eñe (Ñ)2.2 ESTRUCTURA DEL MODELO Y ÁREAS DE DISEÑO
En este apartado se incluye toda la normativa referente a las distintas áreas de diseño que pueden definirse dentro del fichero ERWIN. Existen otras normas específicas para áreas de diseño en tecnologías Documentum, BO y GIS, que deberán consultarse en el apartado específico de estas tecnologías.
A continuación se enumeran las normas que han de seguirse con respecto a las áreas de diseño:
NO
RM
A
AREMainSub No se permite utilizar el área de diseño de ERWIN “Main Subarea” como área de diseño principal del modelo. Esta área no se modificará manualmente, se utilizarán el resto de áreas de diseño para crear los objetos oportunos.NO
RM
A
AREGeneral
El área de diseño de ERWIN Principal o General del Esquema es obligatoria y debe denominarse según 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 (incluídos sinónimos remotos). No se incluirán objetos que por su naturaleza no tienen representación visual, como las secuencias, procedimientos, etc.
27 de 124
NO
RM
A
AREPropietario
El área de diseño de ERWIN del esquema propio del proyecto es obligatoria y debe denominarse “90 – Área de Creación 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á ningún objeto propiedad de otro usuario). No se incluirán objetos que por su naturaleza no tienen representación 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 subárea específica para cada tipo, que incluirá los objetos específicos de ese tipo de instancia.
La nomenclatura de los áreas será: “9n – Área de Creación del Esquema DBA_XXXX
INSTANCIA”, donde n es un número consecutivo, XXXX es el nombre del proyecto, e INSTANCIA es un identificador de la instancia de base de datos. Ejemplo:
“91 – Área de Creación del Esquema DBA_AGCC CENTRALIZADA” “92 – Área de Creación del Esquema DBA_AGCC DEPARTAMENTAL”
NO
RM
A
AREVaciaEn la entrega del fichero ERWIN no se incluirá ningún área de trabajo vacía que no esté contemplado en la normativa.
NO
RMA
ARELOPD
Si el modelo incluye tablas que contengan datos personales susceptibles de ser tratados de forma especial según la LOPD, se incluirá un área específica que contenga todos los objetos afectados. El nombre de esta área será: “80 – Área de Datos Personales Protegidos”.
BUE
NA
PR
A
C
T
IC
A
AREParcialSe 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 serán tenidas en cuenta para la generación 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 físicas que contengan todos los objetos del mismo tipo (Ej: Subárea que contiene todas las vistas del modelo).
28 de 124
Cuando estamos diseñando un modelo de datos, se puede elegir el “Display Level” pulsando sobre el tapiz con el botón derecho. Para asegurarnos que el orden de visualización coincide con el orden físico de creación de las columnas de las tablas, se recomienda utilizar el Display Level “Physical Order” durante el diseño del modelo:
BUE
NA
PR
A
C
T
IC
A
AREDisplayLevelSe recomienda utilizar el Display Level “Physical Order” durante el diseño del modelo, para asegurarnos que el orden de visualización coincide con el orden físico de creación de las columnas de las tablas.
A la hora de crear un nuevo modelo ERWIN, deberá tenerse en cuenta la colocación de los objetos para que estén dispuestos de una forma que resulte legible, pudiéndose apreciar de forma visual los objetos del modelo así como sus relaciones.
NO
RM
A
GENModeloLegible Los objetos de un modelo deberán estar dispuestos sobre el tapiz de diseño 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 deberán estar definidos en mayúscula, y sólo podrán estar compuestos por caracteres alfanuméricos (sin acentos) y guión bajo “_”. No pueden contener la letra eñe (Ñ).29 de 124
Si en un subárea del proyecto queremos incluir objetos, que no pertenezcan al esquema principal del proyecto, deberemos mostrar el objeto en color amarillo. Para ello, en la opción “Object Font Color - Fill Color” indicaremos el color amarillo, según se muestra en la siguiente figura:
NO
RMA
AREObjExternos
En cualquier subárea del modelo, los objetos externos al esquema propio del proyecto si los hubiese se mostrarán 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:
30 de 124
Cada vez que se cree un nuevo objeto de base de datos, se debe asignar al tablespace correcto, según el tipo de objeto.
En las siguientes normas se incluye la normativa relativa a definición y asignación 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):
- TBSDAT_XXXX_100: Tablespace para las tablas - TBSIND_XXXX_100: Tablespace para los índices
- TBSBLOB_XXXX_100: Tablespace que se asignará a las columnas de tipo BLOB o CLOB .Si no existen campos Lob NO debe definirse este tablespace (se debe eliminar)
Los tablespaces del modelo de datos 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
RMA
TABNombreTabla
La nomenclatura de las tablas debe ser [XXXX]_[NOMBRE_TABLA], donde: · XXXX: Nombre del proyecto (Ejemplo: AGCC)
· NOMBRE_TABLA: Nombre de la tabla, en mayúsculas. Si contiene varias palabras pueden separarse por guiones bajos (Ejemplo: ARTICULOS_CLIENTE).
Ejemplos de nombres de tablas correctos serían: AGCC_ARTICULOS_CLIENTE, AGCC_ART_PROVEEDOR_PRINCIP
31 de 124
NO
RMA
TABTiposColumna
En las tablas, sólo 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 precisión.
El resto de tipos de datos (CHAR, VARCHAR, INTEGER, DECIMAL , LONG, RAW, LONG RAW, BINARY LARGER, etc.) no están 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 pestaña “Oracle”, ninguna opción en el desplegable “Character”, según se muestra en la siguiente figura:
NO
RMA
TABVarchar2
Las columnas del tipo VARCHAR2 de cualquier tabla, nunca tendrán ninguna opción seleccionada en el desplegable “Type” de la pestaña “Oracle”.
32 de 124
BUE
NA
PR
A
C
T
IC
A
TABNombreColumnasA la hora de crear columnas en las tablas del modelo, se recomienda utilizar la siguiente nomenclatura según el tipo de dato que representa la columna:
· ID_: Para identificador numérico de elemento (normalmente la PK, Ej: ID_USUARIO). · CD_ : Para códigos alfanuméricos (Ej: CD_DNI, CD_EXPEDIENTE, etc.)
· DS_: Para descripciones alfanuméricas (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 numérico 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 años
· 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 añadir columnas a una tabla. Además de estos domains, se incluyen otros de uso común para los campos típicos de auditoría de alta, modificación y eliminación de filas (cuyo nombre empieza por ICM_AUDI_).
BUE
NA
PR
A
C
T
IC
A
TABUsoDomainsA 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 están utilizando los tipos de columna de Oracle validados por la normativa.
Asimismo, se pueden utilizar domains específicos incluídos en la plantilla para campos comúnmente utilizados en auditoría de alta, modificación y eliminación de filas.
33 de 124
Siempre que creemos una tabla en el modelo, debemos activar la opción “Physical Properties” de la pestaña “General”, y en el cuadro de diálogo “Storage Properties” asignar el tablespace de datos (TBSDAT_XXXX_100), según se muestra en la siguiente figura:
34 de 124
NO
RM
A
TABAsignarTablespace Todas las tablas del modelo (excepto las tablas temporales – GLOBAL TEMPORARY) deberán obligatoriamente tener activada la opción “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 pestaña “General” se debe chequear la opción “Global Temporary” con las opciones que corresponda, según se muestra en la siguiente figura:
35 de 124
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: · XXXX: Nombre del proyecto (Ejemplo: AGCC)
· NOMBRETABLA: Nombre de la tabla, en mayúsculas. Si contiene varias palabras pueden separarse por guiones bajos (Ejemplo: ARTICULOS_CLIENTE).
Un ejemplo de nombre de tabla correcto sería: AGCC_GTT_ARTICULOS_CLIENTE.
36 de 124
En los modelos de datos, cada tabla deberá tener obligatoriamente una (y sólo una) Primary Key que cumpla con la nomenclatura. Esta primary key estará formado por un solo campo de tipo numérico, y su valor deberá sacarse obligatoriamente de una secuencia.
Existe una excepción a esta regla, en la cuál una primary key deberá estar compuesta por más de un campo, y es en aquellas tablas que sólo sirven para representar relaciones muchos a muchos entre otras tablas y no tengan otros campos adicionales que no sean los de auditoría.
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 relación muchos-a-muchos entre EXPEDIENTE e INTERESADO) tendría como primary key los campos ID_EXPEDIENTE e ID_INTERESADO:
Si AGCC_EXPE_INTERESADO se le añadieran otros campos de Negocio (No de Auditoria) entonces si que debería crearse un campo ID como clave primaria
Ejemplo: Supongamos que tenemos una tabla ARCHIVO y una tabla EXPEDIENTE, y que un expediente puede tener varios archvos, y un archivo puede tener varios expedientes. La tabla EXPEDIENTE_ARCHIVO que relaciona las dos (y que representa la relación muchos-a-muchos entre EXPEDIENTE e INTERESADO) tendría como primary key el campo ID_EXPE_ARCHIVO ya que además de los campos ID_EXPEDIENTE e ID_ARCHIVO, tiene otros campos adicionales de negocio como DS_EXPE_ARCHIVO(descripción) y NM_TRAMITES (Numero de tramites). Además formare con los campos ID_EXPEDIENTE, ID_ARCHIVO una constraint UNIQUE (Alternate KeyI) AK1AGCC_EXPE_ARCHIVO :
37 de 124 A continuación se muestran las normas relativas a Primary Keys:
NO
RM
A
TABObligaPK
Toda tabla del modelo de datos debe tener obligatoriamente una y sólo una Primary Key. Esta Primary Key deberá ser numérica, obtenerse de un secuenciador, y estar formada por un sólo campo de la tabla.
Sólo existe una excepción en la cuál una primary key deberá estar compuesta por más de un campo, y es en aquellas tablas que sirven para representar relaciones muchos a muchos entre otras tablas y no tengan otros campos adicionales que no sean los de auditoría. Se considerará otorgar autorizaciones excepcionales a esta norma para proyectos antiguos en tecnología Forms o modelos de datos heredados con otro sistema de integridad referencial.
BUE
NA
PR
A
C
T
IC
A
TABAKRelacionesSi en una tabla que sirve para representar relaciones muchos a muchos entre otras tablas se ha generado una clave primaria numérica única (porque dicha tabla incluye algún campo adicional además 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
RMA
TABNombrePK
La nomenclatura de la Primary Key debe ser PK[NOMBRE_TABLA]. Ejemplo: PKAGCC_ARTICULOS_CLIENTE
38 de 124
En los modelos de datos, se deberán definir Foreign Keys para garantizar la integridad referencial por base de datos. A continuación 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 número consecutivo que se asigna a cada Foreign Key existente. Deben numerarse las FK’s aunque sólo haya una por tabla.
Ejemplo: FKAGCC_ARTICULOS_CLIENTE_01
NO
RMA
TABGenerateFK
Si en nuestro modelo de datos tenemos incluídas tablas de otros esquemas, que NO tienen definida la Primary Key, deberemos deschequear la opción “Generate” en las Foreign Keys a esas tablas, para evitar que se generen.
Si en nuestro modelo de datos tenemos incluídas tablas de otros esquemas, que SI tienen definida la Primary Key, deberemos asegurarnos que ambos esquemas conviviran en Producción en la misma instancia de base de datos, de lo contrario también deberá desactivarse la casilla “Generate”.
39 de 124 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 edición de índices, activando el check “Generate as constraint”:
40 de 124
NO
RMA
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 opción de índices asociados. La ventana permite el mantenimiento de los índices, y la definición de las columnas que lo integran.
41 de 124
NO
RMA
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 foránea.
GRn[NOMBRE_TABLA] Para los índices Geográficos (Oracle Spatial). DTS[NOMBRE_TABLA] Índices multicolumnas de Intermedia Text BMn[NOMBRE_TABLA] Indices bitmap (Datawarehouse)
Donde n es un número 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 existía integridad referencial basada en PK’s y FK’s, la nomenclatura era diferente, ya que se añadía una letra “X” antes del nombre del índice.
Al crear los índices en el modelo, hay que indicar el tablespace físico en el que se crearán. Para ello, en el cuadro de diálogo “Storage Properties” de la pestaña “Physical” se asignará el tablespace
42 de 124
NO
RMA
TABTablespaceIndices
Todos los índices del modelo (incluídos los de las PK’s, etc.) deberán obligatoriamente tener asignado el tablespace de índices (TBSIND_XXXX_100).
BUE
NA
PR
A
C
T
IC
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.
43 de 124 2.4.7 COLUMNAS LOB (BLOB y CLOB)
Los contenidos de las columnas de tipo LOB (BLOB y CLOB) se almacenan en ‘Tablespaces’ específicos para estas columnas, separados del resto de los datos de la tabla. Para cada tabla del modelo que incluya columnas de tipo LOB, se debe modificar la pestaña “LOB Storage” según se muestra en la siguiente figura:
Deberemos pulsar sobre la opción “Parámeters” de la columna de tipo LOB, y ahí seleccionar el tablespace específico para campos LOB (TBSBLOB_XXXX_100), y marcando las opciones que se muestran a continuación:
44 de 124
A continuación 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 parámetros en la pestaña “LOB Storage” para todas las columnas de este tipo. En los parámetros se asignará el tablespace
TBSBLOB_XXXX_100 y se activarán obligatoriamente los siguientes parámetros (y sólo estos): - CHUNK: 4096
- “Retain old versión 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 (validation rules) y valores por defecto (default values). 2.4.8.1 CHECKS
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 validación genéricas y valores por defecto genéricos, en la zona “Validation Rules” o “Default Values”. Los nombres deberán definirse según la nomenclatura “[XXXX]_CHECK_[NOMBRECHECK]”, donde [XXXX] es el nombre del proyecto, y [NOMBRECHECK] el nombre del check (lo más
45 de 124
descriptivo posible). En la siguiente figura se muestra un ejemplo de definición de reglas de validación y valores por defecto:
Seleccionando la Validation Rule y pulsando el botón derecho la opción Properties en la pestaña General rellenaremos el contenido del check (Validation Rule) , en ningún caso se utilizará la variable %ColName, siempre debe aparecer el nombre de la columna.
46 de 124
2) Asignar a las columnas deseadas las validaciones y valores por defecto que se precisen. Esto se realiza la pestaña “Constraint”, seleccionando una validación o valor por defecto de los disponibles en las listas desplegables:
47 de 124
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 (breve descripción).
NO
RM
A
TABMaxCheckSe creará un check (Validation Rule) para cada columna. Está prohibido asignar el mismo check (Validation Rule) para 2 o más columnas
NO
RMA
TABColNameCheck
El contenido del check (Validation Rule) pestañas general y oracle, en ningún caso se utilizará la variable %ColName, siempre debe aparecer el nombre de la columna.
48 de 124
NO
RM
A
TABUsoCheck
Todos los Checks (Validation Rules) que aparezcan en el Modelo de Datos Erwin deben estar asignados a algún campo de las tablas del Modelo de datos.
Aquellos Checks que no se utilicen en los campos de las tablas del modelo de datos deben ser eliminados
Al asignar una validación a un campo de una tabla(opción “Columns”, pestaña “Constraint”
) Erwin por defecto da un nombre de Constraint (Valor de “Name”) que lo compone con: “Nombre de la constraint seleccionada” + Numero Aleatorio. Si este numero es cambiado por cualquier circunstancia estamos cambiando el nombre de la Constraint y por tanto ya no coincidirá con la constraint que hemos creado previamente en base de datos y por tanto al realizar el Complate Compare saldrá esta diferencia. Se debe poner al valor del campo “Name” el valor del campo “Valid” (check seleccionado).
Ejemplo:
Asigno en una tabla en el campo “IT_IMAGEN” el check AGCC_CHECK_IT_IMAGEN_S_N
seleccionándolo de la lista de valores de “Valid”. Erwin por defecto como valor de “Name” (nombre de la constraint en base de datos) ha dado el siguiente nombre: AGCC_CHECK_IT_IMAGE_1080180105
49 de 124
A continuación modifico el valor de “Name” con el nombre de la constraint seleccionada, es decir, AGCC_CHECK_IT_IMAGEN_S_N
50 de 124
NO
RMA
TABNameConstrValidCheck
En una Validation Rule asignada a un campo de una tabla .
En la pestaña Constraint, en el marco de Validation Constraint, El valor del campo Name debe ser el mismo que el valor del campo “Valid”
Name . – corresponde a nombre de la Constraint del check que se va crear en la base de datos. Valid . – Check seleccionado de la lista de Valores.
BUE
NA
PR
A
C
T
IC
A
TABNameConstrActBDSi se ha renombrado en algún check (Validation Rule) la constraint name según lo indicado en la norma TABNmaeConstrValidCheck, para trasladar este cambio a la base de datos podemos realizarlo , recreando la tabla o bien si ya disponemos de registros eliminar las constraint que hemos actualizado de la siguiente forma:
alter table XXXX_TABLA1 drop constraint ANTIGUA_CHECK_CONSTRAINT
alter table XXXX_TABLA1 add constraint NUEVA_CHECK_CONSTRAINT check (CAMPO sentencia_de_validacion)
ejemplo:
-- en el script generado desde mi modelo de datos erwin 7 de la tabla AGCC_ARCHIVO el campo IT_DATOS_SENSIBLES aparece como:
-- IT_DATOS_SENSIBLES VARCHAR2(1) DEFAULT 'N' NULL CONSTRAINT
AGCC_CHECK_IT_DATOS_1629854590 CHECK (IT_DATOS_SENSIBLES IN ('S','N','J')), -- por tanto utilizaré las sentencias del siguiente modo:
alter table AGCC_ARCHIVO drop constraint CheckNameAntiguo_122854631;
alter table AGCC_ARCHIVO add constraint AGCC_CHECK_IT_DATOS_SENS_S_N CHECK (IT_DATOS_SENSIBLES IN ('S','N','J'));
2.4.8.2 DEFAULT VALUES
51 de 124
NO
RM
A
TABNombreDefaultValue Los Default Value deben cumplir la siguiente nomenclatura:“[XXXX]_DF_[NOMBRE_DEFAULT_VALUE]” , donde [XXXX] es el nombre del proyecto, y [NOMBRE_DEFAULT_VALUE] el nombre del default value , (breve descripción)
NO
RMA
TABUsoDefaultValue
Todos los Default Values que aparezcan en el Modelo de Datos Erwin deben estar utilizados por uno o varios campos de las tablas del modelo de datos
Aquellos que no se utilicen en los campos de las tablas del modelo de datos deben ser eliminados
Ejemplo:
2.4.9 TRIGGERS
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, según se muestra en la siguiente figura:
52 de 124
Para garantizar la concordancia del código SQL y las opciones de generación del objeto, en la pestaña “Code” no se deben modificar las variables que aparecen en su definición, marcadas en la siguiente pantalla con % (como por ejemplo %TriggerName, %Fire, etc.):
53 de 124
A continuación se muestran las normas asociadas a la creación de triggers.
NO
RM
A
TRINombreTrigger
La nomenclatura de los triggers será [XXXX]_[NOMBRE_TABLA]_TRIG_[TIEMPO]_[ACCION], donde:
· XXXX: Nombre del proyecto (Ejemplo: AGCC)
· NOMBRE_TABLA: Nombre de la tabla a la que se asocia el trigger
· TIEMPO: Deberá ser B (para before) o A (para after) en función 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 sería: AGCC_ARTICULOS_TRIG_B_DU
54 de 124
NO
RM
A
TRIUnicoTrigger No se permite más 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
RMA
TRIVariablesTrigger
En la pestaña “Code” de la definición de un trigger, no pueden sustituirse los nombres de las variables que aparecen con porcentaje (Ej: %TriggerName, %Fire, %Actions, etc.). Las variables se dejarán como tal, y sólo en la pestaña “Expanded” ser podrá comprobar el código 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 específicos a tal efecto. Para más información sobre la trazabilidad de datos, consultar la documentación específica 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, justificándose el motivo por el cual se requiere esta funcionalidad. Desde ICM, en base a criterios técnicos, 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 número de particiones
Tips de SuParticionamiento Rango - Hash Rango - Lista
Lista - Hash (No disponible en Erwin 7) Lista – Rango (No disponible en Erwin 7)
A continuación se incluyen las normas sobre el particionamiento de tablas:
NO
RMA
TABNoParticiones
Salvo autorización expresa, no se permite el uso de tablas particionadas en base de datos. En el momento de su autorización, 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.
55 de 124
NO
RMA
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 partición en concreto. [CRITERIO] debe contener tanto del criterio como el valor (si por motivos de longitud del nombre no es posible, se indicará sólo el valor).
NO
RMA
TABPartPasoProduccion
Cuando se realicen cambios en tablas particionadas u objetos asociados a las tablas
particionadas (particiones, índices,…) En el paso a Producción debe indicarse el nombre de cada objeto cambiado (campos ,si son campos particionados, índices locales, índices globales,
particiones,..) y la actualización 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 partición del registro.
Salvo autorización por ICM está prohibido poner la propiedad de las tablas particionadas RAW MOVEMENT a ENABLE
NO
RM
A
TABNoPartSQL Salvo autorización 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 cuál de ellas se encuentra almacenada la fila).56 de 124
2.4.10.1 ASIGNACION DE TABLESPACES A PARTICIONES DE TABLAS Y A INDICES LOCALES PARTICIONADOS Y GLOBALES PARTICIONADOS
En la opción de menú Tables de la tabla seleccionada, en la pestaña Partitions , para cada cada partición que hayamos definido en Partition Name se debe asignarse un tablespace de datos, pulsando el botón Edit Properties en al campo Tablespace debemos realizar la asignación del tablespace de datos.
57 de 124
NO
RMA
TABParticionTablespace Cada Partición y Subpartición, debe tener asignado un tablespace de datos,2.4.10.1.1 INDICES LOCALES PARTICIONADOS
la asignación del tablespace de índices se realizará igual que un índice normal es decir En la opción de menú Indexes de la tabla seleccionada, en la pestaña Physical, en el botón Storage Properties en el campo tablespace debemos asignar el tablespace de índices. No deben utilizarse particiones de índice.
