guías técnicas de interoperabilidad anexo g05-a02 ... · las fuentes de información estándares...

Guías Técnicas de Interoperabilidad

Anexo G05-A02

Lineamientos para el manejo e implementación de Datos

Fecha: 03 de febrero de 2016

HOJA 1 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016

Anexo G05-A02 Lineamientos para el manejo e implementación de Datos Guía de Interoperabilidad

Contenido

1. Objetivo del documento .............................................................................................. 2

1.1. Entregables para el Manejo de Datos ............................................................... 2

1.1.1. Modelo de Domino ......................................................................................... 2

1.1.2. Modelo del Ciclo de Vida de la Información .............................................. 2

1.1.3. Modelo de Entidad Relación ........................................................................ 2

2. Modelo Arquitectónico de Datos de trámites sobre plataformas de Gob.Mx ..... 3

2.1. Recomendaciones Generales al Diseñar el Modelo de Manejo de Datos del Trámite. ....................................................................................................................... 3

2.2. Fuentes de información ........................................................................................ 4

2.2.1. De los archivos digitales ............................................................................... 5

2.2.2. De las bases de datos relacionales ............................................................ 6

2.2.3. Big Data - Volumen alto de Información .................................................... 8

2.3. Políticas de Manejo de Datos ............................................................................. 9

2.3.1. Detectar la información sensible del trámite ............................................. 9

2.3.2. Políticas de Seguridad de la Información .................................................. 9

2.3.3. Políticas técnicas de Retención de la Información ................................. 11

2.3.4. Políticas Jurídicas de Retención de la Información ............................... 12

3. Lineamientos de Modelado de datos ...................................................................... 13

3.1. Estándares de Modelado de Datos .................................................................. 13

4. Referencias ................................................................................................................. 18

HOJA 2 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


1. Objetivo del documento

En el presente anexo busca establecer la arquitectura de datos que la Institución deberá observar, definiendo responsable la Institución del manejo de la información referente al trámite, es decir, que el procesamiento, almacenamiento y utilización de la información referente a los datos de negocio del trámite serán resguardados y utilizados por componentes o aplicativos desarrollados por la Institución , y enunciar que la responsabilidad de la APF es de la trazabilidad del trámite integrado a la plataforma de Gob.Mx. Así como definir los lineamientos, entregables y directrices necesarios para el diseño del manejo de datos requerido por el trámite, los cuales permiten a la institución estandarizar el manejo de los datos aumentando la comprensión y mantenimiento de los mismos en un entorno de interoperabilidad.

1.1. Entregables para el Manejo de Datos

1.1.1. Modelo de Domino

La Institución presentará el diagrama de dominio, el cual integrará en el Documento de Modelado de Datos, en el especificara la representación conceptual de las entidades significativas de negocio relacionados al Trámite, así como su interrelación entre ellas. Con la finalidad de aumentar la comprensión de los datos del trámite.

1.1.2. Modelo del Ciclo de Vida de la Información

La Institución presentará el diagrama de ciclo de vida de la Información durante el proceso del trámite el cual integrará en el Documento de Modelado de Datos, donde presentará de forma gráfica las fuentes de datos de información así como sus transformaciones en el paso del tiempo o del proceso requerido por el trámite.

1.1.3. Modelo de Entidad Relación

La Institución en caso de contar con un gestor de base de datos relacional presenta el diagrama de Entidad Relación y su respectivo diccionario de datos, donde especificara la representación detallada de las entidades necesarias para cubrir la persistencia del negocio del trámite, así como su interrelación entre dichas entidades. Con la finalidad precisar tablas, atributos, tipos, relaciones,

HOJA 3 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


índices y demás particularidades de un Modelo Formal de Datos y Diccionario de datos, apegándose a los estándares de modelado los cuales pueden ser encontrados en el siguiente apartado. Identificando en el modelo claramente las entidades estáticas (Catálogos requeridos por el trámite) y transaccionales (Persistencia durante el ciclo de vida del trámite).

2. Modelo Arquitectónico de Datos de trámites sobre plataformas de Gob.Mx

El modelo de arquitectura de datos implementado en la plataforma Gob.Mx, permite centralizar información de control y monitoreo del trámite sin registrar información de negocio del trámite. Por tanto, en apego a los artículos del EIDA, establece el Modelo Integral del Esquema de Interoperabilidad en el cual, la institución deberá ser responsable de acuerdo a sus atribuciones de la información en todo momento del trámite, por medio de sistemas y aplicativos que almacenen, procesen o utilicen los datos requeridos por el trámite de la institución o Cadena de interoperabilidad.

2.1. Recomendaciones Generales al Diseñar el Modelo de Manejo de Datos del Trámite.

■ Para el almacenamiento de la información al diseñar considerar la disponibilidad y aseguramiento de la integridad por medio de discos con redundancia física, lógica y con conectividad recomendable en Fibra o cuando menos en Cobre.

■ El diseño de la arquitectura se recomienda sea capaz de generar un mínimo de 3 réplicas

para garantizar el correcto funcionamiento de la infraestructura en alta disponibilidad. Altamente recomendable que las réplicas permitan mantener la información en un estado consistente a prueba de errores temporales como cortes en la red o fallas de infraestructura física en alguna unidad del clúster.

■ El diseño de la arquitectura de almacenamiento deberá estar compuesto por zonas, las

cuales, son áreas aisladas dentro del clúster que son definidas para evitar un solo punto de falla, siendo diseñadas para distribuir las réplicas en todo el clúster. Altamente recomendable utilizar software basado en Openstack Swift o equivalente para proporcionar el almacenamiento basado en objetos.

HOJA 4 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


■ Considerar en apego al Plan de Capacidad del Trámite, proporcionar una solución

redundante y escalable para almacenamiento en caso de requerir almacenar un alto volumen de información (Pentabyte o superior), y manejar a través de un API como BigData, que integre una orquestación robusta de procesamiento de la información. Se recomienda que el diseño de la infraestructura para manejar alto volumen de información debe ser capaz de trabajar con el protocolo de redundancia de ruteo VRRP o equivalente para balanceo de cargas.

■ Se recomienda a la Institución utilizar la infraestructura de la plataforma de Gob.Mx, para

procesos específicos donde podrá diseñar, reutilizar y contar con una solución de almacenamiento segura, con gestión remota a través del portal de auto aprovisionamiento, mediante el cual, se podrá asignar el espacio requerido a cada una de las máquinas virtuales gestionadas, para mayor información consultar la Guía de Aprovisionamiento de ambientes en un entorno de interoperabilidad.

La solución de almacenamiento de objetos implementada en la plataforma Gob.Mx ha sido diseñada para cumplir con los siguientes requerimientos:

○ Servidores físicos de almacenamiento tipo objeto ○ Red del almacenamiento de objetos

● Replicación: ○ Maneja copias lógicas y copias virtuales o clones ○ Capacidad para crear, modificar y borrar las copias

2.2. Fuentes de información Las fuentes de información estándares para manipular información deberán de estar encriptados y garantizar la integridad, disponibilidad y seguridad por medio de mecanismos estándares que considere la Institución. Se establece como fuente de información aceptados por APF, las siguientes:

● Archivos digitales

● Bases de datos relacionales

● Big Data Manejo de volumen alto de información (no, semi y estructurados) ● Correos electrónicos integrados a la solución tecnológica.

El criterio de selección de cada tipo de fuente se describe en los puntos siguientes, considerando como premisa que la fuente de datos sea perfectamente capaz de integrar el trámite con un alto desempeño, seguridad e interoperabilidad con la plataforma de Gob.Mx.

HOJA 5 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


2.2.1. De los archivos digitales

2.2.1.1. Definición

Un archivo digital en su tipo planos es una fuente de información en la que su almacenamiento es provisto por el sistema operativo y no tiene una estructura definida. Para los archivos planos no existe un formato estándar y su manipulación es de acuerdo a un formato predefinido por la aplicación o usuario que lo utiliza; y que varía según las necesidades de información.

2.2.1.2. Características

Para que un archivo plano sea utilizado como fuente de datos, debe cumplir con las siguientes características:

- La unidad fundamental del archivo es un registro. - Cada registro se compone de campos. - Cada campo tiene un tipo definido de dato. - Un separador o delimitador de registros. - En el archivo pueden existir cero o más registros de datos, pero todos los registros deben tener

una estructura uniforme. No combinar registros de distintas estructuras en el mismo archivo. - Contar con un registro que defina la estructura de datos utilizada. Este registro se conoce

como encabezado y el objetivo es que sea utilizado por las aplicaciones que manipulen al archivo.

- Los archivos por la importancia de información deberán ser resguardados por la institución en una Zona Segura.

2.2.1.3. Criterios de uso

Un archivo plano se debe utilizar cuando:

- Se necesite como un mecanismo temporal para almacenar datos. No está permitido su utilización como el medio de almacenamiento definitivo para soportar a sistemas de producción del Instituto.

- Se realice la migración de una fuente de información a otra. (Por ejemplo, de una base de datos de escritorio MS Access a MySQL).

HOJA 6 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


- La decisión que debe tomar para utilizar cualquiera de las dos ya sea archivos planos o base de datos relacional debe definirse dependiendo de factores como el tipo y la cantidad de datos a procesar.

- Es necesario aclarar que los archivos planos no ofrecen un mecanismo de integridad, independencia del sistema operativo, redundancia, consistencia, transacciones, seguridad por registro y campo; y no existen estándares definidos.

2.2.1.4. Tipos de archivos planos

Los tipos de archivos planos que pueden ser utilizados son:

a) Archivo binario. Los datos son representados en formato binario. ● De registro variable ● De registro fijo

b) Archivos de texto. Los datos son representados en formato de texto (ASCII, EBCDIC,

Unicode) ● De registro variable ● De registro fijo

2.2.2. De las bases de datos relacionales


Una base de datos relacional es una fuente de información en la que su almacenamiento es provisto por un Sistema de Gestión de Base de Datos Relacional (Relational DataBase Management System o referida en este documento como RDBMS); y que organiza los datos siguiendo el modelo relacional y cuya estructura fundamental son las tablas.


Para que una base de datos sea utilizada como fuente de datos, debe cumplir con las siguientes características:

HOJA 7 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


- Estructura. Los datos se conceptualizan únicamente como tablas - Integridad. Implementa mecanismos para asegurar la consistencia de los datos. - Manipulación. Ofrece un mecanismo para manipular las tablas, tanto para el usuario,

aplicaciones y administrador de la base de datos. - Para un mayor detalle de la especificación que debe cumplir una base de datos referirse

apartado de Lineamientos de Modelado de Datos presente documento.

2.2.2.3. Criterios de uso.

Una base de datos relacional se debe utilizar cuando:

- Se necesite disminuir la redundancia, evitando que se tengan archivos planos por cada tipo de dato necesitado. Con esto se reduce el uso del espacio de almacenamiento.

- Evitar la inconsistencia. Existe un mecanismo único para operar sobre los datos; y por tanto, el mecanismo de gestión de los mismos es estándar y definido.

- Compartir los datos a múltiples usuarios y aplicaciones. - Aplicar restricciones de seguridad, ya que el administrador de la base de datos puede asegurar

que el acceso a la base de datos sea sólo a través de los mecanismos apropiados y puede definir las verificaciones de seguridad a realizar cuando se intente acceder a información sensible.

- Asegurar que la información de la base de datos sea correcta o integra. - Soportar mecanismos de manejo de transacciones.

2.2.2.4. Tipos de bases de datos relacionales.

Actualmente, en la industria existen los siguientes manejadores de bases de datos con mayor soporte técnico, por tanto, la Institución podrá elegir bajo sus atribuciones el gestor de base de datos que considere. Por ello la APF, solicita aplicar la política de cambiar los manejadores de datos por una plataforma estándar de base de datos, tomando las siguientes consideraciones:

- Para todo nuevo sistema se debe utilizar las últimas versiones del manejador de base de datos relacional elegido.

- Para los sistemas que aún están en producción con las bases de datos distintas, se debe realizar una evaluación de la viabilidad del cambio, que deberá estar medido en el impacto que da a los procesos del trámite y a sus usuarios finales.

- Si la estandarización al manejador elegido por la Institución asegura que el costo de inversión se preserva, debe de realizarse un plan de migración.

HOJA 8 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


2.2.3. Big Data - Volumen alto de Información


En términos generales podríamos referirnos como a la tendencia en el avance de la tecnología que ha abierto las puertas hacia un nuevo enfoque de entendimiento y toma de decisiones, la cual es utilizada para describir enormes cantidades de datos (estructurados, no estructurados y semi estructurados) que tomaría demasiado tiempo y sería muy costoso cargarlos a un base de datos relacional para su análisis. De tal manera que, el concepto de Big Data aplica para toda aquella información que no puede ser procesada o analizada utilizando procesos o herramientas tradicionales. Sin embargo, Big Data no se refiere a alguna cantidad en específico, ya que es usualmente utilizado cuando se habla en términos de petabytes y exabytes de datos.


Para que Big Data sea utilizada como fuente de datos, debe cumplir con las siguientes características:

- Volumen de Datos: cuando se habla en términos de petabytes y exabytes de datos - Integridad. Implanta mecanismos para asegurar la consistencia de los datos. - Manipulación. Dividir en dos tareas (mapper – reducer) para manipular los datos distribuidos a

nodos de un clúster logrando un alto paralelismo en el procesamientoos - Para un mayor detalle de la especificación que debe cumplir una base de datos referirse

apartado de Lineamientos de Modelado de Datos presente documento.

2.2.3.3. Criterios de uso.

Big Data se debe utilizar cuando:

- Se necesita procesar grandes cantidades de información. - Ser representados de diversas maneras en todo el mundo, por ejemplo de dispositivos móviles,

audio, video, sistemas GPS, incontables sensores digitales en equipos industriales, automóviles, medidores eléctricos, veletas, anemómetros, etc.

HOJA 9 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


- Aplicar restricciones de seguridad, ya que el administrador de la base de datos puede asegurar que el acceso a la información sea sólo a través de los mecanismos apropiados y puede definir las verificaciones de seguridad a realizar cuando se intente acceder a información sensible.

2.3. Políticas de Manejo de Datos

La Institución podrá elegir bajo sus propias atribuciones, la tecnología que permita resguardar la información del trámite, sin embargo, se establecen políticas de seguridad y resguardo de información generales que deben observar al elegir la tecnología sin perjuicio de las políticas de seguridad o retención que dicté el marco jurídico y normativo vigente aplicable a la Institución.

2.3.1. Detectar la información sensible del trámite

La Institución deberá hacer un estudio interno del trámite que permita implementar una correcta estrategia de seguridad de datos:

1. Realizar un inventario de los archivos o datos del trámite sensibles y/o confidenciales.

2. Saber dónde están ubicados. 3. Conocer quién tiene acceso a ellos en todo momento. 4. Criterios de retención de información productiva e histórica.

2.3.2. Políticas de Seguridad de la Información

Uno de los primeros riesgos para la seguridad de la información emana de las personas de adentro de la organización. Considerando este punto el personal Interno es el principal depredador de la información, ya que el 90% de los datos que se modifican o borran sin las autorizaciones ni permisos pertinentes proviene de gente del interior de las organizaciones, por ello, se establecen políticas de seguridad para los diferentes rubros:

HOJA 10 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


2.3.2.1. Implementar Notificaciones de Información Sensible

Considerando la importancia de la integridad y disponibilidad de la información en propiedad y resguardo por la Institución, se recomienda fuertemente habilitar mecanismos de notificación de seguimiento interno a la Institución sobre puntos o áreas de la información sensibles para la Institución. Por medio de herramienta de monitoreo o en su caso de base de datos relacionales controlar los eventos por medio de triggers no invasivos.

2.3.2.2. Establecer Niveles de Seguridad

2.3.2.2.1. Seguridad de Archivos Digitales y Base de datos no relacionales

Los archivos planos así como la información gestionada con base de datos no relacionales como Big Data, deberán observar los siguientes puntos de seguridad:

● Firmar electrónicamente los archivos fuentes de información. ● Crear una estructura de carpetas subcarpetas que permita la clasificación por importancia

y sensibilidad de la información. ● Evitar su descarga directa de documentos sin el aplicativo gestor con autoridad suficiente. ● Ubicar la información en servidores protegidos en zona segura de la Infraestructura. ● Restringir acceso físico y lógico a los servidores de gestión documental o repositorios. ● Crear perfiles de usuario con sus respectivos privilegios de alcance sobre la estructura de

carpetas y elementos en ellas. ● Generar copias de seguridad y respaldos de las fuentes de información periódicas y en

ubicaciones seguras.

2.3.2.3. Seguridad de la Base de datos

Los accesos a base de datos, se estableces perfiles definidos con permisos precisos, como se lista en la siguiente tabla. La institución deberá establecer los permisos que tendrá cada usuario de la base de datos como mínimo se deben considerar los siguientes Roles:

HOJA 11 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


USUARIO DESCRIPCIÓN PERMISOS ROL_OWNER Propietarios de la BD Total sobre la BD ROL_APP Usuario de aplicativo con

privilegios de CRUD a BD CRUD a BD alcance del aplicativo.

ROL_WRITER Usuario de escritura a BD Con alternativas para personalizar escritura de tablas

ROL_READER Usuario de Escritura a BD Con alternativas para personalizar lectura de tablas

2.3.2.3.1. Seguridad en el Manejo de la Información entre Servicios

Las políticas de seguridad serán aplicables cuando se intercambie información entre Instituciones lo cual permita interoperar de manera segura y correcta. Como se define en el Anexo G10-A01 Lineamientos de Construcción para Servicios de Intercambio de Información, por importancia se cita los siguientes lineamientos:

● La publicación de los servicios será por medio de un canal web seguro como lo es el protocolo HTTPS (SSL/TLS).

● Los mensajes deberán ser firmados digitalmente, esto es cifrados a nivel mensaje, Certificar digitalmente el intercambio de información considerando la vigencia del certificado. La vigencia es controlada por cada Institución.

● Apegarse a la definición de encabezados del servicio digital con la finalidad de estandarizar el intercambio de información con un bloque común de metadatos.

2.3.3. Políticas técnicas de Retención de la Información

La Institución podrá elegir bajo sus propias atribuciones las políticas de resguardo y retención de datos considerando aspectos técnicos. La política de retención de datos adoptados por la Institución debe observar mínimo las siguientes características:

a) La Institución debe garantizar el resguardo e integridad de la información del trámite dentro de su infraestructura, dicha información puede ser propia de la Institución o información

HOJA 12 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


que ha sido compartida desde otras Instituciones en el caso de trámites que pertenecen a una Cadena de Interoperabilidad.

b) Debe reflejar la actual práctica de la Institución, es decir, conservar dentro de la fuente de datos la información del trámite vigente.

c) Debe contener el responsable de la definición del periodo de retención para la información y en su caso para cada tipo de documento: legal, técnico, contractual, etc.

d) Debe definir el cómo recuperar la información, cómo acceder a ella. La información se retiene y se puede archivar, estando accesible de modo diferente a como lo está on-line.

e) Debe referir también al ciclo de vida del documento: creación, retención, archivado, destrucción, etc.

2.3.4. Políticas Jurídicas de Retención de la Información

La Institución podrá elegir bajo sus propias atribuciones las políticas de resguardo y retención de datos considerando aspectos jurídicos que le apliquen. La política de retención de datos adoptados por la Institución debe observar las leyes especificadas en el Anexo G01-A01 Marco Legal de las guías de interoperabilidad, con especial atención en las siguientes recomendaciones legales:

a) Debe incluir el proceso para recuperar información desde fuentes de información

productivas o históricas de la Institución, en apego a la normativa y ley aplicable, dichas normas se indican en el Anexo G01A01, para esta política cabe aclarar tomar especial atención en la ley ARCO.

b) Se recomienda mantener la información productiva en las fuentes de información elegidas

por la Institución, como mínimo bajo el lineamiento del APF, que es por 5 años. Una vez concluido el tiempo la Institución a su consideración podrá enviar la información a un repositorio histórico o en medios alternos como citas u otros con la finalidad de liberar la fuente de información productiva (La información histórica No estará disponible para ambientes del alcance del aplicativo de trámite) mejorando el desempeño y rendimiento del aplicativo.

HOJA 13 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


3. Lineamientos de Modelado de datos

3.1. Estándares de Modelado de Datos

Propietario del esquema de la base de datos El propietario de la base de datos debe ser de 8 caracteres debiendo ser el primer carácter alfabético según el siguiente formato: Sintaxis: SS WN Donde SS = Clave del sistema y subsistema al que pertenece el propietario de la base de datos WN = Variable que identifica el propietario del objeto

Nombre de la base de datos

El nombre de la base de datos debe de ser 8 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SS BD AA NN Donde SS = Clave del sistema y subsistema aplicativo al que pertenece la base de datos ‘BD’ = Constante AA = Es un prefijo relacionado al ambiente: PR = Producción DS = Desarrollo TT = Pruebas. NN Consecutivo 0 a 9 y letras de A....Z

Contenedores El nombre del contenedor debe de ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SS_TS_T _DDII_999_DDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece al contenedor

HOJA 14 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


‘TS’ = Constante DDII = Constante: DATA o INDX. DDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico descriptivo del contenedor, que en caso de tablespaces particionadas describe a la tabla o al índice que contiene. T = Constante: P si contiene una partición, N si no contiene una partición. 999 = Consecutivo 0 a 9.

Nombre de tablas

El nombre de las tablas puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSST_DDDDDDDDDDDDDDDDDDDDDDDDDD Donde SSS = Clave del sistema y subsistema aplicativo al que pertenece la tabla T = Constante: T para tablas; C para Catálogos. _ = Constante DDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico descriptivo de la tabla.

Nombre de tablas de dimensión

El nombre de las tablas puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSD_DDDDDDDDDDDDDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece la tabla D = Constante _ = Constante DDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico descriptivo de la tabla de dimensión

Nombre de tablas de hechos El nombre de las tablas puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSH_DDDDDDDDDDDDDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece la tabla H = Constante _ = Constante

HOJA 15 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


DDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico descriptivo de la tabla de hechos

Nombres de columnas de tablas El nombre de la columna puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: PPP_DDDDDDDDDDDDDDDDDDDDDDDDD Donde PPP = Prefijo del nombre de la columna en función a su contenido. _ = Constante DDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico de la columna en la tabla El prefijo de la columna estará determinado por la naturaleza de la información contenida en el campo, a continuación mostramos la siguiente tabla para este fin.

PREFIJO DESCRIPCIONES CVE Columnas con contenido de claves o códigos DES Columnas con descripciones alfanuméricas DOM Columnas con direcciones alfanuméricas FEC Columnas con contenido de fechas IND Indicador binario 0 o 1 IMP Columnas con contenido de Importes NUM Columnas con contenido de números CAN Columnas con contenido de cantidades MON Columnas con contenido de valores de moneda NOM Columnas con contenido de nombres POR Columnas con contenido de porcentajes o factores REF Columna con contenido alfanumérico STP Columnas con contenido fecha y hora conjuntamente TIP Columnas con conjunto de tipos de valores TIM Columnas con contenido de tiempos en horas

Vistas

El nombre de la vista puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSV_DDDDDDDDDDDDDDDDDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece la vista. V = Constante _ = Constante

HOJA 16 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


DDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico de la vista en la base de datos

Sinónimos El nombre del sinónimo puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSC_DDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece el sinónimo. C = Constante representativa del objeto al que hace referencia: T = Tabla V = Vista X = Índice SP = Store Procedure CNS = Constraint G = Trigger S = Secuencia

_ = Constante DDDDDDDDDDDDDDD = Mnemónico del sinónimo

Nombre de índices El nombre de los índices puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSX_AA_ TTTT_T_DDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece el índice. X = Constante _ = Constante AA = Tipo de índice: BT = BTree BM = Bitmap _ = Constante TTTT = Primeros 4 caracteres de la tabla/mnemónico de la tabla. _ = Constante T = P para partición; N no partición. DDDDDDDDDDDDDDD = Mnemónico del índice asociado a la tabla Esto aplicará siempre y cuando el RDBMS no genere un índice con nombre que siga esta norma, ya que en ese caso, prevalecerá el generado por el RDBMS. Store procedure

HOJA 17 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


El nombre del store procedure puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSSP MDDDDDDDDDDDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece el plan. SP = Constante M = ‘B’ batch, ‘C’ línea DDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico descriptivo del store procedure.

Constraints El nombre del constraint puede ser menor o igual a 30 caracteres, el primer carácter, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSCNS_AA_PPPP[_HHHH]_DDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece el constraint. CNS = Constante _ = Constante AA = Tipo de constraint: PK Primary key FK Foreign key CH Check UN Unique _ = Constante PPPP = Primeros 4 caracteres de la tabla padre/mnemónico de la tabla HHHH = Sólo en caso de FK, primeros 4 caracteres de la tabla hijo/mnemónico de la tabla hijo. _ = Constante DDDDDDDDDDD = Mnemónico en caso de UN, CH o cualquier otro.

Trigger

El nombre del trigger puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSG_DDDDDDDDDDDDDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece el trigger. G = Constante _ = Constante DDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico del trigger.

HOJA 18 DE 19

PROCESO-MAAGTIC ADS

VERSIÓN 1.0

FECHA FEB-2016


Secuencias

El nombre de la secuencia puede ser menor o igual a 30 caracteres, el primer carácter deberá ser alfabético, a continuación se describe el formato: Sintaxis: SSS_DDDDDDDDDDDDDDDDDDDDDDDDDD Donde SS = Clave del sistema y subsistema aplicativo al que pertenece el trigger. S = Constante _ = Constante DDDDDDDDDDDDDDDDDDDDDDDDDDD = Mnemónico de la secuencia.

4. Referencias Con la finalidad de homologar, estandarizar y aumentar la comprensión al diseñar, implementar y mantener el manejo de la información en los trámites se genera un documento para citar los estándares de la industria recomendados con el fin de referenciar la documentación oficial publicada por sus creadores. Para ello consultar el documento de Estándares tecnológicos utilizados en gob.mx, Anexo N° 6

guías técnicas de interoperabilidad anexo g05-a02 ... · las fuentes de información estándares...

Documents