“LINEAMIENTOS PARA LA ESTANDARIZACIÓN DEL DESARROLLO DE …

Lineamientos para la Estandarización del Desarrollo de Software Web y Base de Datos en la Unidad Ejecutora 001 de DEVIDA

Página 1 de 39

“LINEAMIENTOS PARA LA ESTANDARIZACIÓN DEL DESARROLLO DE SOFTWARE WEB Y BASE DE DATOS EN LA UNIDAD EJECUTORA 001 DE

DEVIDA”

I. FINALIDAD

Establecer lineamientos para la estandarización del desarrollo de software web y base de datos, orientados a uniformizar criterios para el desarrollo y/o construcción de software web, creación de objetos en las bases de datos, correcto uso en el desarrollo de sistemas de información y la administración de los Modelos de Datos.

II. BASE LEGAL

2.1 Decreto Legislativo N° 1412, que aprueba la Ley de Gobierno Digital y modificatoria.

2.2 Decreto Supremo N° 029-2021-PCM, que aprueba el Reglamento del Decreto Legislativo Nº 1412, Decreto Legislativo que aprueba la Ley de Gobierno Digital, y establece disposiciones sobre las condiciones, requisitos y uso de las tecnologías y medios electrónicos en el procedimiento administrativo.

2.3 Decreto Supremo N° 047-2014-PCM, que aprueba el Reglamento de Organización y Funciones (ROF) de la Comisión Nacional para el Desarrollo y Vida Sin Drogas – DEVIDA.

2.4 Resolución Ministerial N° 041-2017-PCM, que aprueba el uso obligatorio de la Norma Técnica Peruana “NTP-ISO/IEC 12207:2016 Ingeniería de Software y Sistemas. Procesos del ciclo de vida del software, 3ª Edición”, en las entidades integrantes del Sistema Nacional de Informática.

2.5 Resolución de Gerencia General N° 044-2021-DV-GG, que aprueba la Directiva N° 006-2021-DV-GG-OPP "Disposiciones para la formulación, modificación y aprobación de Documentos Normativos en la Comisión Nacional para el Desarrollo y Vida sin Drogas - DEVIDA".

III. ALCANCE

Las disposiciones contenidas en los presentes Lineamientos, son de aplicación de la Unidad de Tecnologías de Información y Comunicación de la Oficina General de Administración.

IV. PAUTAS E INSTRUCCIONES

4.1 De las actividades de la Unidad de Tecnologías de la Información y Comunicación de la Oficina General de Administración

4.1.1. El personal de la Unidad de Tecnologías de Información y Comunicación realiza el análisis y diseño en las fases de modelamiento de datos y desarrollo de software en proyectos de Tecnología Digital, conforme a los estándares establecidos en el presente documento.

4.1.2. La Unidad de Tecnologías de Información y Comunicación verifica que la fase de modelamiento de datos y desarrollo de software y el soporte al desarrollo de los sistemas de información, sea conforme a los estándares establecidos en el presente documento.

4.1.3. El Administrador de Base de Datos o quien haga sus veces recibe los pases a producción correspondientes a las bases de datos y verifica que cumpla con los estándares establecidos en el presente documento.


Página 2 de 39

4.1.4. El Especialista en Análisis y Desarrollo de Sistemas de Información o quien haga sus veces recibe los pases a producción de los sistemas de información o aplicativos web desarrollados por el personal de la Unidad de Tecnologías de Información y Comunicación, y verifica que cumpla con los estándares establecidos en el presente documento.

4.1.5. La Unidad de Tecnologías de Información y Comunicación se encarga de mantener actualizado el presente documento.

4.2 Del desarrollo de software

4.2.1. La aplicación de principios y las buenas prácticas en todas las etapas del desarrollo de software minimizan los errores y costos de mantenimiento, y maximiza la legibilidad.

4.2.2. El código fuente generado, además de cumplir con los requerimientos funcionales, debe ser fácil de comprender, reutilizar, extender, mantener y escalar.

4.2.3. El producto de software resultante debe ser un recurso eficiente, confiable, estable, fácil de usar y seguro para los usuarios finales.

4.2.4. Utilizar y adoptar la terminología técnica adecuada evitando realizar la traducción literal de los términos técnicos que se utilizan en la industria del desarrollo de software.

4.3 De las Bases de Datos

4.3.1. El análisis y diseño de los Modelos de Datos durante las fases de Modelamiento de Requerimientos y Modelamiento de Tecnología de la MDSI (Metodología de Desarrollo de Sistemas de Información) se realizan conforme a las reglas y estándares establecidos en el presente documento.

4.3.2. El Modelamiento de Datos comprende el modelamiento Conceptual y Físico de Datos.

4.3.3. El Modelamiento Conceptual de Datos hace referencia al documento de estándares internacionales: IEEE STD 1320.2-1998 Standard for Conceptual Modeling Language - Syntax and Semantics for IDEF1X97.

4.3.4. El Modelamiento Físico de Datos contempla la creación de los objetos esquema y no- esquema de las bases de datos (para manejadores de base de datos: Oracle).

4.4 Principios para el desarrollo de software

El software se desarrolla bajo los principios SOLID [S: Principio de responsabilidad única (SRP Single responsibility principle), O: Principio de abierto/cerrado (OCP Open/closed principle), L: Principio de substitución de Liskov (LSP Liskov substitution principle), I: Principio de segregación de la interfaz (ISP Interface segregation principle), D: Principio de inversión de la dependencia (DIP Dependency inversion principle)] de la programación orientada a objetos:

4.4.1 Principio de responsabilidad única

Cada clase o módulo debe tener solo una responsabilidad dentro de la aplicación (alta cohesión). Si se identifica más de un propósito en una de las clases, se debe considerar separar dicha funcionalidad en otra clase. Nótese que el principio no propone tener un solo método en cada clase, sino que todos sus métodos sirvan a un solo propósito.

4.4.2 Principio de abierto/cerrado

Principio que permite heredar el comportamiento de una entidad de software sin modificarlo. Es decir, los módulos deben estar abiertos para su extensión, pero cerrados para su modificación. Este principio es muy importante al definir las clases, paquetes o módulos.


Página 3 de 39

4.4.3 Principio de substitución de Liskov

Los objetos deben poder ser remplazados con instancias de sus subtipos sin alterar la definición del sistema. En otras palabras, los objetos derivados de una clase deben poder ser remplazados por un objeto de la clase base, sin modificar el comportamiento de la misma. La solución es diseñar por contrato (o interfaz).

4.4.4 Principio de segregación de la interfaz

Las interfaces se diseñan con propósitos específicos o con un solo rol en lugar de diseñar pocas interfaces generales que obligue a implementar métodos que no se necesita. De este modo favorecemos a la creación de software con alta cohesión y bajo acoplamiento.

4.4.5 Principio de inversión de dependencia

El código debe depender de abstracciones. Los módulos de alto nivel no deben depender de los módulos de bajo nivel; ambos deben depender de abstracciones. Las abstracciones no deben depender de “detalles” o de clases particulares.

4.5 Buenas prácticas para el desarrollo de software

4.5.1 Elegir cuidadosamente el nombre de las clases

▪ El nombre de las clases debe ser escrita en singular, tiene que ser significativo y tener relación con el propósito de la clase. ▪ Evitar los nombres excesivamente largos.

4.5.2 Elegir cuidadosamente el nombre de los métodos

▪ El nombre debe contener un verbo de forma no personal al inicio de la oración, seguido de la finalidad del método, ej. “Calcular Interés por Inversión”. ▪ Se debe utilizar nombres que tengan sentido, sean comprensibles y sean auto-explicativos. ▪ Evitar los nombres excesivamente largos.

4.5.3 Codificar clases pequeñas

▪ Una clase representa una entidad conceptual en la aplicación y el tamaño de la clase debe reflejar solo la funcionalidad para la cual fue creada. ▪ Se debe asegurar que las clases se enfoquen en hacer un pequeño número de cosas de manera

efectiva.

4.5.4 Codificar métodos pequeños

▪ Limitar cada método a una única tarea o actividad. ▪ Un método largo puede contener subgrupos de funcionalidades. ▪ Refactorizar para mejorar la responsabilidad y el alcance de los métodos.

4.5.5 Usar librerías estándar

Es recomendable usar librerías estándar que ya han sido probadas, depuradas y usadas por otros, esto no sólo mejora la eficiencia del desarrollador, sino que reduce las posibilidades de tener errores en el código.

4.5.6 Documentar el código

Utilizar las herramientas estándar de documentación de Java para documentar los métodos y sus clases; y mantener actualizada la documentación, según cambie el código.


Página 4 de 39

4.5.7 Comentar el código

Mantener el código limpio, comentando lo estrictamente necesario y evitando los comentarios que no aporten valor. Si se respetan los principios mencionados en el punto 5.1 y lo mencionado en los numerales 5.2.1 y 5.2.2 de esta sección, solamente será necesario “Documentar el código”, según lo mencionado en el numeral 5.2.6.

4.5.8 Utilizar un sistema de codificación

Todos los archivos del proyecto deben utilizar la codificación UTF-8.

4.5.9 Utilizar convenciones

El código debe adoptar las convenciones de codificación de la plataforma Java.

4.5.10 DRY/DIE

Evitar la duplicidad en el código fuente, cada fragmento de código debe tener una representación única e inequívoca en el sistema. Refactorizar el código para extraer los fragmentos comunes para no duplicar funcionalidad.

4.5.11 KISS

El diseño de un sistema debe ser sencillo. Cuánto más sencillo sea, mejor. Hay que evitar la complejidad como norma general, pero sobre todo la complejidad innecesaria.

4.5.12 YAGNI

Implementar exclusivamente lo que indique el requerimiento y no intentar desarrollar funcionalidades cuya necesidad no estén aseguradas o construir mega soluciones que resuelvan posibles requerimientos futuros que cambian con frecuencia en entornos ágiles.

4.6 Arquitectura

La estructura de los proyectos de desarrollo de software sigue el patrón de arquitectura n-layer (multicapa) que se refiere a la distribución lógica de las capas y la forma en como está organizado y estructurado el código.

Figura 1. Arquitectura n-layer básica para los proyectos de desarrollo de software.

Como se aprecia en la Figura 1, en esta arquitectura las capas interactúan solamente con sus capas adyacentes manteniendo las responsabilidades y permitiendo abstraer funcionalidades de las capas contiguas.

4.6.1 Cliente

El cliente es el usuario final (persona que utiliza el software) quien interactúa con la aplicación mediante un browser o navegador de Internet con capacidad de interpretar el código generado por la capa de presentación.

4.6.2 Capa de Presentación

En esta capa se incluyen los componentes de los motores de plantillas (template engines) para las vistas html, el código Javascript y el código de estilos css.


Página 5 de 39

4.6.3 Capa de Integración

En esta capa se incluyen los paquetes para los controllers web, los controllers-rest y los paquetes de los facades.

4.6.4 Capa de Servicios

En esta capa se incluyen la lógica del negocio con responsabilidades especificas agrupadas en los paquetes de servicios.

4.6.5 Capa de Acceso a Datos

En esta capa se incluyen los paquetes de los beans y los paquetes de los mappers, así como la implementación e invocación a los procedimientos almacenados.

4.6.6 Base de Datos

El código SQL/PLSQL generado por la capa de Acceso a Datos, así como los procedimientos, funciones, entre otras características que ofrece el motor de base de datos son ejecutados en este nivel (tier).

4.7 Estructura de un proyecto

Las Figuras 2 y 3 muestran ejemplos de la estructura de directorio para el desarrollo de proyectos Java:

Figura 2. Ejemplo de estructura general de un proyecto de software.


Página 6 de 39

Figura 3. Ejemplo de directorios de un componente/módulo en un proyecto de software.

La Figura 2 muestra la estructura de directorios del proyecto con todos los módulos/componentes.

La Figura 3 muestra la estructura de paquetes por módulo/componente.

Aplicando el principio de responsabilidad única, el código de todo proyecto de software debe estar organizado como se muestra en la Figura 2. Cada módulo o componente tiene un paquete principal ubicado en la raíz del proyecto.

Los módulos o componentes mostrados en la imagen referencial de la Figura 4 son implementados respetando el principio SOLID descrito en el numeral 5 de este documento, según la arquitectura n-layer mostrada en el numeral 7 y con una estructura de directorios similar a la mostrada en la Figura 3 (Imagen Referencial).

Figura 4. Ejemplo de diagrama de componentes.


Página 7 de 39

4.8 TECNOLOGÍAS PARA EL DESARROLLO DE SOFTWARE

Los proyectos de desarrollo de software que se implementen en la Comisión Nacional para el Desarrollo y Vida sin Drogas – DEVIDA, deben contar con la siguiente tecnología:

4.8.1 Gestor de dependencias y construcción de proyectos

Tecnología Provider Versión

Maven Apache 3.x

4.8.2 Lenguajes de programación

Lenguaje Provider Versión

Java Oracle 8.x (1.8.x)

Kotlin JetBrains 1.x ó superior

4.8.3 Frameworks Java Spring

Capa Framework/Artifact Provider Versión

Container Spring Pivotal 5.x o superior

Servicios Spring Boot Pivotal 2.x o superior

Integración spring-boot-starter-web Pivotal 2.x o superior

Acceso a Datos mybatis-spring-boot-starter Apache 2.x o superior

Presentación spring-boot-starter-thymeleaf Pivotal 2.x o superior

Transversal spring-boot-startter-security Pivotal 2.x o superior

Transversal spring-boot-starter-log4j2 Pivotal 2.x o superior

4.8.4 Frameworks y Biblioteca Web

Tipo Versión

Bootstrap Framework 4.x

Jquery Library 3.x

Angular Framework 8.x

4.8.5 Bibliotecas para reportes

Tipo Library Versión

PDF jasperreports 6.x

PDF iText 2.x

xcel poi-ooxml 3.x


Página 8 de 39

4.8.6 Biblioteca para logging

Library Versión

spring-boot-starter-log4j2 2.x o superior

4.9 Plataforma de despliegue

Las aplicaciones y los servicios web se deben desplegar en un servidor de aplicaciones Java EE:

Infraestructura Provider Versión

JDK 8 Oracle 8.x (1.8.x)

JBoss EAP Red Hat 7.1.0

4.10 Estándares de desarrollo

La estructura del arquetipo que se debe contemplar en los proyectos de desarrollo de software que se implementen en la Comisión Nacional para el Desarrollo y Vida sin Drogas – DEVIDA, es el siguiente:

Group Id: pe.gob.devida Artifact Id: nombre del proyecto. Version: 0.0.1-SNAPSHOT Packaging: war, jar, ear,ejb,pom (Dependiendo del requerimiento del proyecto).

4.10.1 De la definición de variables

a) Las variables se definen con la primera letra en minúsculas (de acuerdo al estándar “CamelCase”).

Las variables de tipo constantes se definen completamente en mayúsculas, separando cada palabra por un guion bajo y utilizando el tipo “static final” para su definición.

private int level; private static final String ESPACIO_KEYS = "Keys.WS.Param"; public static final int TREE = 1;

b) Una declaración por línea es recomendada para mejor entendimiento.

Se debe documentar cada variable local con un comentario al final de la línea con una breve explicación del uso que se le dará:

int level; // Nivel de Identificación int size; // Tamaño de la tabla

c) Para definir un objeto de tipo “Collection” o elementos que hereden de esta clase, se debe definir con una palabra en plural representando los tipos de objetos almacenados en el “Collection”.

Para definir cualquier otro objeto que no sea “Collection”, escribirlo en singular.

List codigos; String[] dnis;


Página 9 de 39

String[] personas;

d) Evitar escribir diferentes tipos sobre la misma línea:

int foo, fooarray[]; **Código Erróneo (mala implementación)**

e) Inicializar las variables locales donde son declaradas. La única razón para no hacerlo es cuando dependen de algún cálculo. Utilizar variables locales para una sola cosa, las variables multipropósito causan confusión. Realizar las declaraciones al comienzo de los bloques (los que están entre llaves "{}"). El crear variables en cualquier lugar causa confusión y además puede estar generando un uso innecesario del “Garbage Collector”.

void myMethod() { int int1 = 0; // inicio del bloque del método if (condition) { int int2 = 0; // inicio del bloque del "if"... } }

f) La única excepción sobre la inicialización de variables es para los índices de los bucles que

normalmente deben ser declarados en la misma sentencia.

for (int i = 0; i < maxLoops; i++) { ... }

g) Para la definición de variables de bucles se puede utilizar las letras i, j, k, etc., este es un estándar

ampliamente utilizado.

Evitar las declaraciones que escondan niveles superiores, por ejemplo:

int count; ... myMethod() { if (condition) { int count; **Evitar! (Mala implementación)**

h) Seguir las siguientes reglas cuando se codifiquen las clases e interfaces:

• Evitar hacer espacios entre el nombre del método y el paréntesis que inicia la lista de parámetros.

• La llave inicial debe colocarse al final de la misma línea de la declaración.

• La llave final debe colocarse en una línea al final.

• Los métodos deben ser separados por una línea en blanco.


Página 10 de 39

class Sample extends Object { int ivar1; int ivar2; public Sample(int i, int j) { ivar1 = i; ivar2 = j; } int emptyMethod() { } ... }

i) Para la definición de la captura de "Exceptions", es un estándar ampliamente utilizado, el uso de

la letra "e”, para definir el objeto donde se almacenan los datos del "Exception".

try { ... } catch (NamingException e) { } catch (RemoteException e) { } catch (Exception e){ } finally { }

j) Cada línea de código debe contener una sola sentencia:

argv++; // Correcto argc++; // Correcto argv++; argc--; **Evitar!**

k) La sentencia “return” con un valor no debe utilizar paréntesis a menos que sea para una mejor

comprensión.

return; return myDisk.size(); return (size ? size : defaultSize);

l) Las sentencias “if-else”, “if”, “else-if” deben de seguir la siguiente forma:

If (condition) { statements; } if (condition) { statements;


Página 11 de 39

}else{ statements; } if (condition) { statements; }else if ( condition) { statements; }else { statements; }

m) La sentencia “for” debe de seguir la siguiente forma:

for (initialization; condition; update) { statements; }

n) La sentencia “for” también puede utilizar la siguiente forma simplificada:

for (Object e : lista){ statements; }

o) En caso de que todo el trabajo esté hecho en la “inicialización”, la “condición” y la “actualización”,

la sentencia “for” debe ser implementadas de la siguiente forma:

for ( initialization; condition; update);

p) La sentencia “while” debe de seguir la siguiente forma:

while ( condition ) { statements; }

q) La sentencia “do-while” debe implementarse de la siguiente forma:

do { statements; } while ( condition );

r) La sentencia “switch” debe implementarse de la siguiente forma:


Página 12 de 39

switch ( condition ) { case ABC: statements; break; case DEF: statements; break; case XYZ: statements; break; default: statements; break; }

Cada sentencia “switch” debe de incluir una implementación “default”.

s) La sentencia “try-catch” debe de seguir la siguiente forma:

try { statements; } catch (ExceptionClass e) { statements; }

t) La sentencia “try-catch” debe tener siempre una implementación “finally”, ejecute o no algo

dentro de ella.

try { statements; } catch (ExceptionClass e) { statements; } finally { statements; }

4.10.2 De la definición de paquetes

a) Los nombres de los paquetes tienen que ser definidos en singular y en letras minúsculas.

b) La estructura raíz de paquetes es la siguiente: pe.gob.devida.

4.10.3 De la definición de clases

a) Los nombres de clases deben ser sustantivos, con la primera letra en mayúsculas (obligatorio) y para cada palabra que componga el nombre siguiendo el estándar de la nomenclatura “CamelCase”.


Página 13 de 39

b) Se puede utilizar mayúscula en palabras que correspondan a siglas o las letras iniciales de las

palabras. c) No se debe incluir guiones o guiones bajos entre las palabras. d) Tratar de mantener los nombres simples y descriptivos.

e) Evitar las abreviaciones o acrónimos.

f) En caso de utilizar abreviaciones utilice estándares que sean de fácil entendimiento y de conocimiento general.

4.10.4 De la definición de propiedades

a) A continuación de la definición de la clase, defina las propiedades de la clase, en el siguiente orden.

✓ Públicos (public) ✓ Protegidos (protected) ✓ Privados (private)

4.10.5 De la definición de los métodos

a) Siga el siguiente orden para definir los métodos:

✓ Constructores ✓ Métodos públicos ✓ Métodos protegidos ✓ Métodos privados

b) Los métodos deben empezar con minúsculas, no contar con guiones entre las palabras e indicar la operación o proceso a realizar.

c) Todo método debe estar documentado según el estándar “Javadoc”.

/** * Busca el <strong>valor</strong> directamente en la tabla de parámetros * que le corresponda. 1 * * @param codigos String[] Listado de códigos de parámetros 2 * @param dbPool String nombre del pool que utiliza para buscar los datos * @param tipo int tipo de tabla * @param valor String en caso se desee buscar un parámetro en especial, se enviará el valor del parámetro. * @return Object, contiene un objeto ParamBean 3 */ public Object buscar(String[] codigos, String dbPool, int tipo, String valor ){ ... }

d) Se debe detallar la operación que debe realizar el método.

e) Se puede utilizar código HTML para enfatizar palabras o párrafos.


Página 14 de 39

f) Se deben indicar los nombres de los parámetros que se reciben, tipo de dato y una breve descripción del parámetro.

g) En caso del uso de la clase “Maps”, se deben indicar las claves que pueden venir en el mismo. h) Se debe explicar el resultado que devuelve el método.

i) En este ejemplo, el texto que sigue al tipo de dato por cada parámetro se agrega al detalle del “javadoc”, lo que permite un mejor entendimiento sobre el uso de las mismas.

/** * * Busca la cadena valor dentro del parámetro que se encuentra en el * cache. * * @param nombre String nombre del parámetro * @param tipo int tipo de tabla * @param valor String equivale al código del parámetro * @return Object objeto de tipo ParamBean */ public Object buscar(String nombre, int tipo, String valor) { ... }

4.10.6 De la utilización de Stored Procedures

a) Es altamente recomendable el uso de Stored Procedures para permitir una programación modular, una ejecución más rápida, una reducción del tráfico de red, el uso de mecanismos de seguridad, aprovechar el rendimiento de la Base de Datos y algunas veces hacer mantenimientos por base de datos sin necesidad de desplegar nuevamente las aplicaciones web.

b) Para emplear los Stored Procedures dentro de la codificación Java se debe considerar el Framework de persistencia MyBatis con integración a Spring Framework.

Ejemplo 1 - usando clave primaria: ✓ Mapper (XML)


Página 15 de 39

✓ Mapper (Java)

✓ DAO (Java)

Ejemplo 2 - usando filtros de búsqueda: ✓ Mapper (XML)

✓ Mapper (Java)

✓ DAO (Java)

4.11 ESTÁNDARES DE CONSTRUCCIÓN

4.11.1 Definición de la estructura del FILESYSTEM para la subida de archivos

La estructura a utilizar debe ser la siguiente:


Página 16 de 39

Carpetas Descripción

RUTA_BASE Es la ruta base que es definido por la UTIC, por ejemplo:

/JBOSSDATA/

ALIAS_SISTEMA

Nombre del sistema, por ejemplo: SISCONV

ALIAS_MODULO

Por ejemplo: CONVENIO_RENIEC

ALIAS_OBJETO_NEGOCIO

Por ejemplo: EXPEDIENTE

NOMBRE_ARCHIVO

Debe tener concatenado el alias del objeto del negocio, más nombre del archivo a subir, más la fecha y hora del registro: EXPE_001_19062017130205.pdf

La ruta seria la siguiente: /JBOSSDATA/SISCONV/CONVENIO_RENIEC/EXPEDIENTE/EXPE_001_19062017130205.pdf [Alias del Objeto de negocio]_[ nombre del archivo a subir]_[ Fecha y hora del registro] NOTA: Cualquier cambio o sugerencia a la estructura debe ser coordinado con la Coordinación de Sistemas de Información de la Unidad de Tecnologías de Información y Comunicación.

4.11.2 Servicios REST

a) Estilo de URL y métodos HTTP

✓ URL BASE - Propuesta

http://sistemas.devida.gob.pe/[version del API]/ {dominio}/ [nombre del recurso]

Por ejemplo: http:// sistemas.devida.gob.pe /v1/pirdais/encuestas

✓ Nombre de los Recursos

Para mantener consistente los nombres de los recursos, deben ser definidos en minúscula por sustantivos y en plural.

http:// sistemas.devida.gob.pe /v1/pirdais/encuestas http:// sistemas.devida.gob.pe /v1/seguridad/validacionesusuarios

✓ Mapeo de Recursos con los métodos HTTP

Nota: Existen algunas excepciones a esta regla. Por ejemplo, si hubiera la necesidad de crear un servicio de "búsqueda" que devuelva diferentes tipos de recurso no se debería usar sustantivo en el URL, en este caso sería conveniente usar el verbo "buscar" para definir la URL, podría diseñarse así:

http://sistemas.devida.gob.pe /v1/{dominio}/buscar


Página 17 de 39

De acuerdo con el modelo de madurez de Richardson y los principios de los servicios REST, es necesario mapear los métodos HTTP con los recursos que se tienen según la acción que se desea realizar. Ejemplo para un servicio "encuesta":

Método URL Descripción

GET http://sistemas.devida.gob.pe/v1/{dominio}/encuestas Listar todas las encuestas

POST http://sistemas.devida.gob.pe/v1/{dominio}/encuestas Registra una nueva encuesta

GET http://sistemas.devida.gob.pe/v1/{dominio}/encuestas/2 Obtener la encuesta 2

PUT http://sistemas.devida.gob.pe/v1/{dominio}/encuestas/2 Actualizar la encuesta 2

DELETE http://sistemas.devida.gob.pe/v1/{dominio}/encuestas/2 Borrar la encuesta 2

b) Limitar campos devueltos

Se debe hacer uso de f (fields) para seleccionar los campos:

Limitar campos

http://sistemas.devida.gob.pe/v1/{dominio}/[Recurso]?f=[campo 1], [campo 2],... [Campo N]

http://sistemas.devida.gob.pe/v1/{dominio}/encuestas?f=id,descripcion,fechaCreacion

c) Filtros, paginado y ordenamiento

Filtros

http://sistemas.devida.gob.pe/v1/{dominio}/encuestas?estado=nuevo&dependencia=120

Paginado

http://sistemas.devida.gob.pe/v1/{dominio}/encuestas?page=2&per_page=10

Considera que s (sort) define los atributos y su ordenamiento ya sea ascendente (sAsc) o descendente (sDes):

Ordenamiento

http://sistemas.devida.gob.pe/v1/{dominio}/encuestas?estado=nuevo&codDependencia=120&sAsc=fechaCreacion,codDependencia&sDesc=codEmpleado

d) URL no deben tener Formato

Para indicar el formato del recurso que se consulta, se debe usar en el Header, el Internet Media Type que corresponda. Algunos ejemplos:

MEDIA TYPE

application/json application/gzip application/zip

application/pdf text/plain text/csv

application/xml image/jpeg audio/mpeg

http://sistemas.devida.gob.pe/v1/%7bdominio%7d/encuestas?f=id,descripcion,fechaCreacion

http://sistemas.devida.gob.pe/v1/%7bdominio%7d/encuestas?f=id,descripcion,fechaCreacion

http://sistemas.devida.gob.pe/v1/%7bdominio%7d/encuestas?estado=nuevo&dependencia=120

http://sistemas.devida.gob.pe/v1/%7bdominio%7d/encuestas?estado=nuevo&dependencia=120

http://sistemas.devida.gob.pe/v1/%7bdominio%7d/encuestas?page=2&per_page=10

http://sistemas.devida.gob.pe/v1/%7bdominio%7d/encuestas?estado=nuevo&codDependencia=120&sAsc=fechaCreacion,codDependencia&sDesc=codEmpleado

http://sistemas.devida.gob.pe/v1/%7bdominio%7d/encuestas?estado=nuevo&codDependencia=120&sAsc=fechaCreacion,codDependencia&sDesc=codEmpleado


Página 18 de 39

image/gif image/png

video/mp4 video/mpeg

e) Códigos de Respuesta (HTTP status) y Estructura del Response

Para el parámetro de respuesta "HTTP status" se deben usar los siguientes códigos: ✓ 200: Código para respuesta exitosa de una petición. ✓ 4XX: Código de Error (debido a petición errónea por parte del cliente). ✓ 5XX: Código de Error (debido a error por parte del servidor).

Ejemplos: ✓ RESPUESTA EXITOSA DE UNA PETICIÓN:

Response

http status : 200 { // body del response }

✓ RESPUESTA CON CÓDIGO ERROR: Http status: Códigos de error del 400 al 417.

Response

http status : 400 { "code": <código de error>, "message": <descripción del error>, "descripcion" : "detalle del error aquí..." }

Http status: Códigos de error del 500 al 505.

Response

http status : 500 { "code": <código de error>, "message": <descripción del error>, "descripcion" : "detalle del error aquí..." }

4.12 MODELAMIENTO CONCEPTUAL DE DATOS

El Modelo conceptual de datos representa la estructura lógica de la base de datos, la que es independiente del software y de la estructura de almacenamiento de datos.


Página 19 de 39

4.12.1 De la Entidad

a) Nombre de la Entidad

✓ El nombre de la Entidad es un sustantivo que describe lo que la entidad representa. ✓ El nombre debe ser definido en singular. ✓ Se permiten las abreviaturas y siglas. ✓ El nombre de la Entidad debe ser consistente y debe reflejar el significado de lo que representa. ✓ Gráficamente una entidad es representada por un rectángulo.

b) Reglas de la Entidad

✓ Una Entidad debe tener un nombre único. ✓ La Entidad no debe tener el mismo nombre que los atributos. ✓ No debe tenerse dos entidades, cuyos nombres sean sinónimos. Dos nombres son sinónimos si

cada uno de ellos es directa o indirectamente un alias de otro o si existe un tercer nombre que es un alias de los dos nombres.

✓ Cada entidad debe tener múltiples ocurrencias.

c) Atributos de la Entidad

✓ Una Entidad puede tener uno o más atributos, cuyos valores únicos identifican cada instancia de la Entidad.

✓ Una Entidad debe tener uno o más atributos que son propios de la Entidad o derivados de otra entidad a través de las relaciones.

d) Relaciones y Claves Foráneas de la Entidad

✓ Una Entidad puede tener una o muchas relaciones con otras Entidades en un modelo de datos. ✓ Si una clave foránea es contenida completamente en la clave primaria de una Entidad, la entidad

debe ser dependiente. ✓ Si algunos atributos de la clave foránea o que no sean parte de la clave foránea son usados como

parte de la clave primaria de una entidad, entonces la entidad será independiente.

4.13 De los Atributos

4.13.1 Nombre de los Atributos

a) Cada atributo es identificado y tiene un nombre único. b) El nombre es expresado como un sustantivo que describe las características del atributo. c) Son permitidas las abreviaturas y las siglas. d) El nombre del atributo debe ser significativo, consistente y debe estar representado en el modelo. e) Un atributo opcional tiene al menos un valor para una instancia de la Entidad. f) Un atributo no designado como opcional es por defecto mandatorio. g) Un atributo mandatorio tiene exactamente un valor para cada instancia o registro de la Entidad. h) Un atributo de una entidad que no es clave foránea se dice que es propia de la entidad.

4.13.2 Clave Primaria – Atributos

a) Una Entidad debe tener un atributo o grupo de atributos que han sido elegidos como identificador único de una entidad.

b) Este atributo o atributos forma la clave primaria de la Entidad.

4.13.3 Sintaxis

a) Los atributos deben ser mostrados como listados de nombres en la entidad. b) Los atributos que especifican la clave primaria deben estar posicionados en la parte superior de

la lista de atributos y estar marcadas y/o separadas de los demás atributos.

4.13.4 Reglas de los Atributos


Página 20 de 39

a) Cada atributo debe tener un nombre único. b) Un atributo debe ser nombrado por su nombre de atributo o uno de su alias. c) En un modelo de datos, si un atributo es un atributo propio en una entidad y es un atributo

derivado en otra entidad, entonces debe tener el mismo nombre en ambos. d) Ningún modelo puede contener dos nombres de atributos en los que los nombres son alias o

sinónimos. Dos nombres son sinónimos si cada uno es directa o indirectamente un alias del otro, o si hay un tercer nombre para que ambos denominen su alias.

4.13.5 Nomenclatura del Código del Atributo

El primer caracter representado por una letra que corresponde al tipo de dato asignado al campo, luego al nombre conceptual de acuerdo a lo siguiente:

C: Para los datos que representen caracteres, por ejemplo: VARCHAR, CHAR, VARCHAR2, NCHAR2,

CLOB, etc. N: Para los datos que representen datos numéricos, por ejemplo: NUMERIC, FLOAT, INT, BINARY. D: Para los datos que representen datos de fecha, por ejemplo: DATETIME, TIMESTAMP, etc.

Nombre Descripción Prefijo

Año Se almacena el año en cuatro dígitos. c_ann_

Cantidad Cantidad de elementos de un conjunto. n_cnt_

Clave Claves artificiales creadas para estructuras de datos específicas; búsqueda de cadenas, etc.

c_clv_

Código Cadena de caracteres alfanuméricos. También se considera los códigos que indican el tipo de dato, ejemplo: cod_tipacceso, cod_tipdoc, etc.

c_cod_

Descripción Descripción de códigos asociados. Por ejemplo: Descripción de ubigeo

c_des_

Observación Observación c_obs_

Nombre Nombre de persona, razón social, nombre de archivo c_nom_

Fecha Fecha d_fec_

Indicador Cadena de caracteres alfanuméricos que indica un Conjunto discreto y finito de valores con significado propio.

c_ind_

Monto Expresa una cantidad de unidades monetarias. n_mto_

Mes Almacena los datos de tipo mes (MM) c_mes_

Número Cadena de caracteres numéricos. n_num_

Periodo Almacena datos de tipo periodo (AAAAMM) c_per_

Porcentaje Porcentaje n_por_

Semana Semana. n_sem_

Expresión Expresión (fórmulas y concatenación de códigos) c_exp_

Hora Indica la Hora (Formato : HHMISS) d_hor_

Dirección Dirección de calles, ip, url, postal. c_dir_

Imagen Imágenes almacenadas en los campos tipo byte y blob c_img_

Archivo Se almacena Archivos de información en los tipos de datos text y blob.

c_arc_

Mensaje Se almacena los mensajes de texto. c_msj_

Audio Audio. c_aud_

Valor Valor del campo n_val_

Video Video c_vid_


Página 21 de 39

4.13.6 De las Relaciones

Al usar el término relación, denota relaciones específicas a menos que se indique lo contrario.

a) Cardinalidad

El número de instancias esperado en cada extremo de la relación es llamado Cardinalidad.

Una relación debe especificar su cardinalidad. Desde la perspectiva de la Entidad padre se pueden ver las siguientes cardinalidades:

a.1 Cada instancia de la Entidad padre debe tener asociada al menos una instancia de la entidad hijo.

a.2 Cada instancia de la entidad padre puede tener asociada cero o una instancia asociada de la entidad hijo.

a.3 Cada instancia de la entidad padre está asociada con un número exacto de instancias de la entidad hijo.

a.4 Cada instancia de la entidad padre está asociada con cero o más instancias de la entidad hijo (si no se especifica la cardinalidad desde la perspectiva de la entidad padre, esta se da por defecto)

Una relación no específica debe indicar la misma cardinalidad en ambas direcciones de la relación (muchos a muchos).

b) Clasificación de las Relaciones

Una relación es designada como identificadora si los atributos de la clave foránea están contenidos en la clave primaria de la entidad “hijo”. Caso contrario, la relación es designada como “no-identificadora”.

La cardinalidad desde el punto de vista de la entidad hijo puede ser:

b.1 Relación Identificadora

La instancia de la entidad hijo está identificada por la asociación con la entidad padre. Cada instancia de la entidad hijo debe estar asociada con exactamente una y solo una instancia de la entidad padre. La existencia del hijo en este tipo de entidad depende del padre: el hijo solo existe si existe el padre.

El hijo en una relación Identificadora es siempre dependiente del padre, por ejemplo, una instancia de la entidad hijo debe existir solo si está relacionada a una instancia de la entidad padre. Una relación identificadora es siempre mandatoria desde la perspectiva de la instancia hijo.

b.2 Relación No-Identificadora

Cada instancia de la entidad hijo puede ser unívocamente identificada sin conocer la instancia asociada de la entidad padre. Por ejemplo, una relación dependiente entre las entidades Comprador y Orden de Compra, las órdenes de compra pueden ser únicamente identificadas por un número de orden de compra sin identificar la compra asociada.

✓ Ambos, padre y entidades hijos, deben identificar entidades independientes en una relación “No-Identificadora” a menos que una o ambas sean entidades hijos en alguna otra relación que sea una relación “Identificadora”.

✓ Una relación “No-Identificadora” debe ser designada como obligatoria u opcional desde la perspectiva de la instancia de la entidad hijo.

b.3 Relación Mandatoria No-Identificadora

En una relación No-Identificadora obligatoria, cada instancia de la entidad hijo está relacionada exactamente con una instancia de la entidad padre.


Página 22 de 39

b.4 Relación Opcional No-Identificadora

✓ En una relación opcional No-Identificadora, cada instancia de la entidad hijo está relacionada a cero o a una instancia de la entidad padre.

✓ Una relación opcional No-Identificadora debe representar una dependencia condicional. Una instancia de la entidad hijo en la cual cada atributo de la clave foránea para la relación tiene un valor, debe tener una instancia padre asociada en la cual los atributos de la clave primaria del padre son equivalentes en valor a los atributos de la clave foránea del hijo.

b.5 Relación Recursivas

✓ Una entidad puede participar en una relación en la cual es tanto padre como hijo; tales relaciones son llamadas recursivas.

✓ Las recursivas son permitidas. Sin embargo, la recursividad debe incluir al menos una relación No-Identificadora.

c) Nombre de la Relación

c.1 Una relación debe tener un nombre, el cual debe expresarse como un verbo o una frase verbal. Por ejemplo: tiene, pertenece a, es asignado, etc.

c.2 El nombre de cada relación entre dos entidades no requiere ser único en el modelo. c.3 La relación debe ser nombrada de tal manera que las sentencias puedan ser formadas por la

combinación de los nombres de las entidades con las frases.

Por ejemplo, las sentencias “un proyecto tiene cero, uno o más empleados” y “Un empleado tiene asignado cero, uno o muchos proyectos” pueden ser derivados desde una relación no específica nombrada de la siguiente manera: “tiene” y “es asignado” entre las entidades proyecto y empleado. (La secuencia asume la entidad proyecto que aparece sobre o a la izquierda de la entidad empleado).

d) Reglas de las Relaciones

d.1 Composición

✓ Una relación siempre se establece entre dos entidades. ✓ Una entidad debe ser asociada con una o muchas entidades, como hijo o como padre. ✓ Una instancia de una entidad padre debe ser asociada con cero, una o más instancias de la

entidad hijo dependiendo de la cardinalidad especificada en el modelo.

d.2 Relación Identificadora/relación No Identificadora

✓ Una relación debe ser clasificada como una de las siguientes:

• Una relación Identificadora, o

• Una relación mandatoria No-Identificadora (total) o

• Una relación opcional No-Identificadora (parcial) ✓ Una relación Identificadora no debe ser recursiva.

d.3 Relación Total/Relación Parcial

✓ En una relación Identificadora, una instancia de la entidad hijo debe ser asociada con exactamente una instancia de la entidad padre.

✓ En una relación Mandatoria no Identificadora (total), una instancia de la entidad hijo debe ser asociada con exactamente una instancia de la entidad padre.

✓ Solo una relación No-Identificadora puede ser parcial; es decir, opcional desde la perspectiva del hijo.

✓ En una relación parcial, una instancia de la entidad hijo debe ser asociada con cero o una instancia de la entidad padre.


Página 23 de 39

d.4 Entidad Independiente/Entidad dependiente

✓ Si una clave foránea es usada totalmente en la clave primaria de una entidad, la entidad debe ser clasificada como dependiente.

✓ Si solo una porción de una clave foránea o atributo de una no clave foránea es usada para una clave primaria de una entidad, luego, la entidad debe ser clasificada como independiente.

✓ La entidad hijo en una relación Identificadora debe ser siempre una entidad dependiente. ✓ La entidad hijo en una relación no Identificadora debe ser una entidad independiente a menos

que sea una entidad hijo en alguna relación Identificadora. ✓ La entidad padre en una relación Identificadora debe ser una entidad independiente a menos

que esta sea también la entidad hijo en alguna otra relación Identificadora. ✓ Una entidad de categoría no debe ser una entidad hijo en una relación Identificadora a menos

que la clave primaria, que es parte de la relación sea completamente contenida en la clave primaria de la entidad de categoría.

4.14 MODELAMIENTO FÍSICO DE DATOS

El Modelo Físico de Datos se realiza a partir del modelo conceptual y/o lógico de datos normalizados o del modelo de clases en el caso de diseño orientado a objetos.

La implementación del modelo se realiza a través de un motor de base de datos específico.

4.14.1 Criterios Generales del Modelamiento Físico de Datos

a) En el Modelamiento Físico de Datos encontramos los objetos esquema de la base de datos y los objetos no esquema de la base de Datos.

b) El nombre de los objetos esquema y no esquema de la base de datos se rigen por los estándares indicados en su correspondiente clasificación.

c) Los nombres de los objetos no deben contener caracteres especiales como: “,’,/,#,),(,%,&,$,=,?,¿,¡,|,.,;.

d) Los nombres de los objetos son creados en mayúsculas para el caso del manejador de base de datos Oracle.

e) No se pueden utilizar como nombres palabras reservadas de los manejadores de base de datos (comandos de los manejadores de base de datos).

f) En base al modelo de datos, se genera el script de creación y/o modificación de los objetos de la base de datos a ser ejecutados en los ambientes de desarrollo, pruebas y de producción.

g) Cada aplicación o sistema dispone de un(os) tablespace(s) para los objetos que ella contemple, a fin de lograr una mayor performance del motor de la base de datos.

h) Considerar la creación de índices en un tablespace, creado para el almacenamiento de estos objetos de base de datos.

i) El nombre de los objetos esquema y no esquema de la base de datos se rigen por los estándares indicados en su correspondiente clasificación.

j) No deben existir dos tablas con el mismo nombre en el Modelo de Datos Institucional. k) Las tablas deben tener clave primaria obligatoria, a excepción de las tablas LOG o de auditoria u

otros casos que según evaluación se consideren como excepción. l) En casos en que el manejador de base de datos tenga como objeto de base de datos una clave

primaria, ésta se presenta de dos formas:

✓ Que la clave primaria este conformada por el constraint y el índice único en un solo objeto de base de datos. Se aplica cuando el manejador de base de datos es Oracle; por ejemplo, el único objeto es CPK_TBL_ADM_ENTIDAD01 clave primaria de la tabla ENTIDAD01.

✓ Que la clave primaria solo este conformada por el constraint. En estos casos el analista programador debe indicar el constraint de la clave primaria y el índice único en el modelo de datos como dos objetos diferentes; por ejemplo, se crea primero el unique index indicando el tablespace de índices: IDX_ENTIDAD01 y luego se crea el constraint CPK_TBL_ADM_ENTIDAD01 objetos de la tabla ENTIDAD01.


Página 24 de 39

m) Las tablas deben tener como máximo 4 índices por cada tabla para mantener mejores tiempos de consulta de los aplicativos.

n) Mantener actualizado el diccionario de datos de los modelos de datos. Indicando las descripciones de cada atributo o columna y al indicar el nombre de la tabla.

o) Indicar en el diccionario de datos el rango de valores que pueda contener la columna o el código de parámetro referenciado.

p) Evitar tener campos nulos, se indica en los modelos el valor por defecto. (Existen excepciones como las tablas de carga del “datawarehouse”).

q) Los defaults de una columna que sirve de vínculo es la misma en las diferentes tablas del Modelo de Datos.

r) Modelos normalizados hasta la tercera forma normal para los Modelos de los Sistemas Transaccionales, y la desnormalización en el caso de los Modelos de Datawarehouse (OLAP).

s) Los índices deben ser optimizados antes de pasar a producción. t) Para la lógica de las aplicaciones se recomienda el borrado lógico para evitar realizar “delete”

sobre las tablas, por ello se recomienda utilizar campos de eliminación lógica, y un número correlativo de la tabla.

u) Al ser eliminado un objeto su numeración es asignada a un nuevo objeto.

4.14.2 Criterios Específicos a) El nombre de la tabla y de las columnas se recomienda no usar caracteres especiales:

“,’,/,#,),(,%,&,$,=,?,¿,¡,|,.,;, se utiliza uno o varios “underline” dentro del nombre de la tabla pero que estén separados cada 3 caracteres como mínimo.

b) El nombre de las columnas utiliza un “underline” obligatorio ( _ ) para dividir el prefijo de la columna, según estándar con el resto del nombre del atributo.

c) Se utiliza uno o varios “underline” dentro del nombre de la columna, pero que estén separados cada 3 caracteres como mínimo.

d) El valor de las columnas de la clave primaria no debe ser modificado en el tiempo. e) Las columnas que tengan el mismo significado deben tener el mismo nombre en los diferentes

modelos de datos que utilicen dichos campos. f) La longitud de las columnas que tengan el mismo nombre debe tener la misma longitud en los

modelos de datos. g) Las claves foráneas o “foreign keys” deben ser creadas en la base de datos para mantener la

integridad referencial, a excepción de aquellos no considerados por el Analista de Sistemas; previo análisis ni los modelos de “datawarehouse” en los cuales se aplica la desnormalización.

h) En los procedimientos no considerar variables que no se utiliza en el programa. i) Se indican nombres de columnas que se utiliza en los diferentes modelos de datos y que tengan

el mismo significado:

c_cod_personal d_fec_modif c_cod_usumodif d_fec_inivig d_Fec_finvig d_Fec_inicio d_Fec_fin c_cod_prov c_cod_depen c_ind_del

: : : : : : : : : :

código de personal o número de registro. fecha de modificación. código de usuario de modificación. fecha de inicio de vigencia. fecha Final de vigencia. fecha de inicio. fecha final. código de Proveedor. código de Dependencia. flag de eliminación lógica.

j) No se crea claves primarias que agrupan casi todas las columnas de la tabla. Estos casos son

evaluados.


Página 25 de 39

k) Si se crea una tabla que tiene integridad referencial con otra tabla de estructura antigua, la creación de los campos de la nueva tabla tiene que ser de acuerdo al estándar definido en el presente documento. La integridad de la información se realiza a través de otros “constraints” o a través de las validaciones de los programas.

l) Las tablas a crearse deben tener obligatoriamente los campos “cod_usumodif” (código de usuario de modificación) y “fec_modif” (fecha de modificación), los cuales no deben contener valores nulos o en blanco. Las excepciones son sustentadas y evaluadas.

4.14.3 Bases de Datos

Cada sistema debe contar con su base de datos de tal manera que se independiza el uso de recursos; solo en el caso de tener limitaciones de infraestructura, se debe considerar la posibilidad de agregar los objetos del sistema en alguna base ya existente.

4.14.4 Nomenclatura de Base de Datos

Formato: BXXXXXXX<nombre de la base de datos>

Longitud máxima: 8 posiciones. No deben tener caracteres especiales.

Descripción: El nombre asignado debe explicar la información que se almacena.

Ejemplo: BSISCONV: Base de datos con la información del sistema de convenios.

4.14.5 Objetos de la Base de Datos

a) Objetos Esquema de la Base de Datos

Un esquema es una colección de estructuras lógicas de la data u objetos esquema. Sistemas con pocos objetos pueden ser almacenados en un solo esquema. De tratarse de sistemas complejos, la modularidad de las aplicaciones se representa separando cada módulo en un esquema codificado de la siguiente manera: <Nombre del Módulo>

Donde:

Nombre Descripción

Nombre del módulo Se utiliza el nombre corto del módulo

Ejemplo:

ADM → Se guarda información referida a administración. CNF → Se guarda información de la configuración. INT → Se guarda información referida a Interfaces y servicios de comunicación. PRO → Se guarda información de los procesos de negocio.

De requerir incluir esquemas de otro sistema dentro de una base de datos ya creada para un sistema específico, se debe anteponer las siglas que permitan identificar ese nuevo sistema; de requerir más de un esquema se antepone el prefijo del nuevo sistema separado por "_" para dividir la abreviatura del módulo correspondiente a este nuevo sistema.

Ejemplo:

SISCONV_CNF.-Indica que pertenece al sistema de Registro de Convenios y al módulo de Configuración.


Página 26 de 39

SISCOD_DAT.- Indica que pertenece al sistema de Control Interoperacional y al módulo de Datos. SIMDEV_INT.- Indica que pertenece al sistema información de monitoreo y al módulo de Interfaces. SIGPA_ADM.- Indica que pertenece al sistema de Registro de Proyectos y actividad de inversión y al módulo de Administración.

Este conjunto de objetos pertenece a un usuario propietario. Los objetos esquema son creados y manipulados por el SQL e incluye los siguientes tipos de objetos:

✓ Tablespace – Nomenclatura

Por cada esquema existente se crea los siguientes TableSpace: temporales, datos e índices. Los nombres de los TableSpace se codifican de la siguiente manera:

TBS_DATA_<abreviatura de módulo>: TableSpace de datos. TBS_INDEX_<abreviatura de módulo>: TableSpace de índices. TBS_TEMP_<abreviatura de módulo>: TableSpace temporal. TBS_LOB_<abreviatura de módulo>: TableSpace para tipos de dato LOB.

De necesitar agregar en una base de datos ya existente, un sistema con un único módulo para los Tablespace del nuevo sistema agregado, se debe usar las siglas o abreviatura del sistema.

TBS_DATA_<abreviatura de sistema>: TableSpace de datos. TBS_INDEX_<abreviatura de sistema>: TableSpace de índices. TBS_TEMP_<abreviatura de sistema>: TableSpace temporal. TBS_LOB_<abreviatura de sistema>: TableSpace para tipos de dato LOB.

De tener en una base de datos más de un sistema con varios módulos para los tablespace de los sistemas agregados, se debe anteponer en el nombre de módulo las siglas o abreviatura del nuevo sistema. TBS_DATA_<abreviatura de sistema>_<abreviatura de módulo> TBS_INDEX_<abreviatura de sistema>_< abreviatura de módulo> TBS_TEMP_<abreviatura de sistema>_< abreviatura de módulo> TBS_LOB_<abreviatura de sistema>_< abreviatura de módulo>

Ejemplos:

TBS_DATA_SISCONV.- Indica que corresponde al Tablespace de datos sistema Convenios, en este ejemplo solo se requiere el nombre del sistema, ya que el sistema tiene un módulo único. TBS_DATA_SIGPA_CNF.- Indica que corresponde al Tablespace de datos del sistema registro de proyectos y módulo de configuración. En este ejemplo el sistema tiene más de un módulo y debe agregarse la abreviatura que permita identificar el módulo.

✓ Datafile – Nomenclatura

Por cada TableSpace existente se crea al menos un Datafile, el cual es la representación física de un tablespace y es codificado de la siguiente manera, tener en cuenta que esto ya no se realiza, si para el sistema se usa ASM. DF_<Nombre del módulo>_<NN> Dónde:


Página 27 de 39

Esquema Nombre completo del esquema.

Nombre Módulo Se utiliza el nombre corto del módulo o abreviatura de su Proceso.

NN (01, 02, 03, 04 …) Se utiliza un número secuencial de dos dígitos para enumerar a los datafiles.

✓ Tabla – Nomenclatura

Los nombres de las tablas son conformados de acuerdo a la siguiente nomenclatura: <Tipo de tabla>_<Nombre del módulo, Submódulo>_<Nombre de la tabla> Donde:

Nombre Descripción

Tipo de tabla Se utiliza para identificar el tipo de tabla: Maestra, Detalle, auditoría y temporal. Los valores para tipo de

tabla son: - TBL: Tabla maestra - DET: Tabla detalle - AUD: Tabla de auditoria - TMP: Tabla temporal

Nombre del módulo Se utiliza el nombre corto del módulo o la abreviatura del Submódulo

Nombre de la tabla Representa una descripción general de la funcionalidad de la tabla. Los espacios entre palabras son representados con el carácter “_”. Además, el nombre de la tabla debe de ser un sustantivo y no debe de contener más de 22 caracteres.

Ejemplo: TBL_ADM_ENTIDAD: Tabla que almacena las entidades del módulo de administración. DET_ADM_ROL_PERF: Tabla que almacena el detalle de los roles asignados al perfil del módulo de administración. AUD_ADM_ENTIDAD: Tabla que almacena los datos de auditoría que se realiza a la tabla entidad del módulo de administración. TMP_ADM_SOLI_BORRADOR: Tabla que almacena los datos temporales de una solicitud borrador del módulo de administración. En caso de una tabla maestra, considerar el nombre completo de la tabla, pero en el caso de las tablas relacionales, sólo contemplar 3 o 4 caracteres del nombre de la tabla maestra a la que hace referencia. Ejemplo:

• DET_ADM_ROL_PERF

• TMP_ADM_SOLI_BORRADOR

• DET_ACT_BASES


Página 28 de 39

• DET_SEL_PROCESO

• DET_CNF_FLUJO

• DET_INT_BITACORA ✓ Tabla Temporal – Nomenclatura

Formato: tmp<nombre de tabla>

Longitud Máxima: 18 posiciones como máximo.

Descripción: Tmp: No se asigna numeración, son tablas temporales que son creadas y eliminadas por el programa. Se asigna al tablespace temporal de la base de datos.

✓ Columnas – Nomenclatura

Los nombres de los campos, se codifica de la siguiente manera:

Indicador de Tipo de Columna (Prefijo)

Tipo de Datos Manejador de b.d.

SQL

Tipo de Datos Manejador de

b.d. Oracle

n_ann_ : año Smallint Number

n_cnt_ : cantidad Smallint, Decimal,Integer

Number

c_cod_ : código Char Char

c_des_ : descripción Varchar, Text Varchar2, Long

c_obs_ : observación Varchar, Text Varchar2, Long

c_nom_: nombre de persona, razón social, nombre de archivo

Varchar

Varchar2

d_fec_ : fecha Date, Datetime Date

d_hor_ : hora Datetime (formato hora) Date (formato hora)

c_ind_ : indicador Char(1) Char(1)

n_mto_ : monto Decimal, money Char(2) Number

c_mes_ : mes Smallint, Integer, Char Char(2)

_num_:número Decimal Number

c_per_ : periodo ( año, mes) Char(6) Char(6)

n_por_ : porcentaje Decimal Number

c_sem_ : semana Char Char

c_exp_ : expresión (fórmulas y concatenación de códigos)

Varchar Varchar2

c_dir_ : dirección de calles, ip, url, postal

Varchar Varchar2

c_img_ : Imagen Image - Byte Blob

c_arc_ : Archivo Image - ntext Long, Blob

c_msj_ : mensaje Varchar Varchar2

c_aud_ : audio Varbinary Blob

c_val_ : valor varchar o integer varchar2 ó number

c_vid_ : video Byte Blob

c_id_ : Id Char Char

Ejemplo : n_cnt_bultos Number(15,3)


Página 29 de 39

Indicador de Tipo de Columna (Prefijo)

Tipo de Datos Manejador de b.d.

SQL

Tipo de Datos Manejador de

b.d. Oracle

c_nom_decide Varchar2(50) d_fec_inivig Datetime o Date

Excepciones:

• Las columnas de tipo código que tienen datos variables deben ser definidos como varchar o varchar2 (en Oracle).

• El prefijo exp es utilizado para la concatenación de códigos y en el caso que se fundamente su almacenamiento, también es utilizado para entidades externas.

• Se utiliza el prefijo ape_: apellido para casos específicos. Por ejemplo, cuando en una misma tabla indicamos diferentes nombres para diferentes agentes del modelo.

• Las columnas con prefijo indicador tienen constraints como son los checks de validación.

• Los tipos de estados son considerados como códigos; por ejemplo, se tiene tipo de documento como cod_tipdoc.

• En el caso de tablas de auditoría o tablas log, se contempla campos que registran valores y por el cual se considera el prefijo “val” para estos casos.

✓ Índices – Nomenclatura Índice Único de la Clave Primaria Los nombres de las claves primarias serán conformados de la siguiente manera: CPK_<Nombre de la

tabla><NN> Donde:

Nombre Descripción

Nombre de la tabla Representa el nombre completo asignado a la tabla.

NN(00, 01, 02, 03 …) Número secuencial del constraint de tipo llave primaria.

Índice de la Clave Foráneas Los nombres de las claves foráneas son conformados de acuerdo a la siguiente nomenclatura: -CFK_<Nombre de la tabla origen o abreviatura>_<Nombre de la Tabla destino o abreviatura> -CFK_<Nombre de la tabla origen o abreviatura><NN> Donde:

Nombre Descripción

Nombre de la tabla origen

Representa una descripción general de la funcionalidad de la tabla de origen.

Nombre de la tabla destino

Representa una descripción general de la funcionalidad de la tabla de destino.

NN (00, 01, 02, 03 …) Número secuencial del constraint de tipo foránea.

El nombre del constraint de clave foránea tiene un máximo de 30 caracteres. Ejemplo:


Página 30 de 39

CFK_ENTI_UBIG: Constraint que vincula la tabla Entidad con la tabla Ubigeo. CFK_ROL_MODU: Constraint que vincula la tabla Rol con la tabla Modulo.

✓ Secuencias Los nombres de las secuencias son conformados de acuerdo a la siguiente nomenclatura: SQ_<Nombre del campo> Donde:

Nombre Descripción

Nombre del campo Corresponde al nombre del campo que se esté utilizado para la secuencia. Al nombre del campo se le quita la primera letra, que identifica al tipo del campo (N, D, C)

✓ Reglas Composición:

• Toda tabla debe tener una clave primaria. No se crean claves primarias que agrupan casi todas las columnas de la tabla. Estos casos son evaluados.

• Además de una clave primaria, una tabla puede tener una o más claves alternas específicas.

• Una clave (primaria o alterna) consiste de una columna o de una combinación de columnas.

• Cada registro de la tabla debe tener un valor para cada columna de la clave primaria.

• Una clave (primaria o alterna) debe contener solo las columnas que contribuyen al identificador único de la entidad.

• Si la clave primaria se compone de uno o más columnas, el valor de cada columna no clave es dependiente de la clave primaria.

• Las columnas que conforman la clave primaria y las claves alternas de una tabla deben ser propietarias de la entidad o derivarse a través de la relación.

• Cada columna que no es parte de la clave (primaria o alterna) debe ser funcionalmente dependiente de la clave primaria y la clave alterna.

• Se debe evaluar el uso de campos varchar como parte de una clave primaria o de una clave alterna en base de datos.

Clave Alterna: Una columna especificada como parte de una clave alterna no necesariamente puede tener un

valor. Relaciones: Una columna de clave foránea puede ser parcialmente o completamente la clave primaria, o una

clave alterna, o como una columna no clave de una tabla. Si todas las columnas de la clave primaria de una tabla padre son migradas como parte de la clave primaria de la tabla hijo, entonces la relación con las columnas migrados es una relación Identificadora. Si alguna de las columnas no migradas no son parte de la clave primaria de la entidad hijo, luego la relación es una relación no Identificadora.

Por ejemplo, si las tareas son únicamente numeradas en un proyecto, luego la columna migrada

id_proyecto es combinado con un atributo propio id_tarea, para especificar la clave primaria de tarea. La tabla proyecto tiene una relación Identificadora con la tabla tarea. Por otro lado, la columna id_tarea es siempre única, aún a través de los proyectos, luego la columna migrada


Página 31 de 39

id_proyecto debe ser una columna no clave de la tabla tarea. En este caso, la tabla proyecto tiene una relación no Identificadora con la tabla tarea.

Relaciones Múltiples: En algunos casos, una tabla hijo puede tener múltiples relaciones con la tabla padre. La clave

primaria de la tabla padre aparece como una columna de la clave foránea en la tabla hijo para cada relación. Para un registro de la tabla hijo, los valores de las columnas migradas debe ser diferente para cada relación, dos diferentes registros de la tabla padre deben ser referenciadas.

Sintaxis

• Una clave foránea debe ser representado por la posición de los nombres de cada columna de la clave foránea en el rectángulo como se encuentra representada la tabla.

• Cada nombre de la columna de la clave foránea debe consistir del nombre de la columna seguido con las letras FK en paréntesis.

• Si cualquier columna de la clave foránea no pertenece a la clave primaria de la tabla hijo, la columna debe estar posicionado debajo de las columnas de la clave primaria, y la tabla debe ser clasificado como un identificador independiente con respecto a la relación.

Reglas

• Cada columna de la clave primaria de una tabla padre en una relación debe ser una columna de la clave foránea (migrada) en la relación con la tabla hijo.

• Cada columna de la clave primaria de una entidad genérica en una estructura de generalización debe ser un atributo de la clave foránea (heredado) en la relación con la entidad de categoría.

• Cada columna de la clave primaria de una entidad genérica en una generalización debe ser parte de la clave primaria de la entidad de categoría.

✓ Vista – Nomenclatura

Formato: VW_<prefijo de tabla o nombre de vista>

Longitud Máxima: 18 posiciones

Descripción: VW_ : Prefijo de Vistas

Ejemplo: VW_LIS_SIMDEV

✓ Sinónimo – Nomenclatura Los sinónimos son a menudo utilizados por seguridad y conveniencia, puesto que pueden hacer lo

siguiente:

• Enmascarar el nombre y propietario de un objeto.

• Proveer un nombre y total transparencia de los objetos remotos utilizados en base de datos “distribuidas”.

• Simplifica el uso de las sentencias sql a los usuarios de base de datos. Los sinónimos son muy útiles en bases de datos distribuidas y no distribuidas, porque permite

esconder la identidad de los objetos, incluyendo su locación en el sistema. Esto es ventajoso, porque si el objeto es renombrado o movido, únicamente el sinónimo necesita ser redefinido.


Página 32 de 39

Por ello, las aplicaciones basadas en sinónimos continúan funcionando sin modificarse, puesto que son únicamente los sinónimos los que varían.

El sinónimo puede ser igual al nombre de la tabla o corresponder a la parte nemotécnica de la tabla

(no se considera números) o ser igual al nombre de la vista, en este último caso se elimina el prefijo VW.

Excepción: En el caso que algunas tablas sean cambiadas de propietarios o sistemas, se mantiene el

sinónimo creado originalmente o inicialmente. ✓ Trigger – Nomenclatura

Formato: TR_XXXXX


Descripción: TR: Prefijo del objeto Trigger Xxxx: Tipo de tabla o descripción.

Ejemplo: TR_ADM_USUARIO : trigger de insert sobre la tabla adm_usuarios

✓ Procedimiento Almacenado – Nomenclatura (Stored Procedure) Para las variables está prohibido usar el mismo nombre de algunos de los campos de las tablas.

Formato: SP_<Nombre procedimiento> No se aceptan caracteres especiales, indicados en numeral 5.10.1.3

Longitud Máxima: 18 posiciones Descripción: SP_: Prefijo de Stored Procedures Ejemplo: SP_CALCULODIARIO: Stored Procedure que

realiza el Cálculo diario. ✓ Función – Nomenclatura Para las variables está prohibido usar el mismo nombre de algunos de los campos de las tablas.

Formato: FN_<nombre de la función> No se aceptan

caracteres especiales, indicados en el numeral 5.10.1.3.

Longitud Máxima 18 posiciones Descripción FN_: Función Ejemplo FN_DIASUTILES: Función de cálculo de día útil


Página 33 de 39

✓ Package – Nomenclatura Para las variables está prohibido usar el mismo nombre de algunos de los campos de las tablas.

Formato PKG_<nombre del paquete> No se aceptan caracteres especiales, Indicados en el numeral 5.10.1.3.

Longitud Máxima 18 posiciones

Descripción: PKG: Paquete

Ejemplo PG_devalida

✓ Secuencia – Nomenclatura Si la aplicación requiere el uso de secuencias, ésta debe avanzar de 1 en 1 respetando el orden tanto

en el avance en tabla como en la secuencia, la aplicación no debe modificar este incremento.

Formato: SQ_<nombre de la secuencia No se aceptan caracteres especiales, indicados en el numeral 5.10.1.3.

Longitud Máxima 18 posiciones

Descripción: SQ :Secuencia

Ejemplo: SQ_CONTADOR01

✓ Cursor – Nomenclatura Un Programador puede recuperar varias filas de una tabla de base de datos con un puntero a cada

fila, y realizar modificaciones de trabajo en las filas de uno en uno. En estos casos, puede declarar los cursores explícitamente.


Página 34 de 39

✓ Resumen de Prefijos de Objetos Esquema

Tipo de Objeto Prefijo

Tabla t : Tabla Fija y Temporal fija f: Fact. o Tabla de Hechos d : Dimensión l : Log p :Tabla de procesamiento

Tabla Temporal tmp

Clave Primaria (Primay Key) cpk

Clave Foránea (Foreign Key) cfk

Check ck

Vista vw

Trigger tr

Procedimiento Almacenado (Stored Procedure)

sp

Función fn

Package pa

Secuencia sq

Usuario Propietario us

Rol rl

✓ PIVOT – Nomenclatura Presente información en un informe con referencias cruzadas con formato de planilla de cálculo a

partir de cualquier tabla relacional usando código SQL, y almacene datos de una tabla con referencias cruzadas en una tabla relacional. El uso de este objeto debe ser aprobado por el Administrador de la Base de Datos y está sujeto a modificación en base al costo de la consulta.

select * from ( select times_purchased, state_code from customers t ) pivot ( count(state_code) for state_code in ('NY','CT','NJ','FL','MO')


Página 35 de 39

) order by times_purchased

b) Objetos no Esquema de la Base de Datos Son tipos de Objetos almacenados en la base de datos, pero no están contenidos en el esquema. ✓ Roles – Nomenclatura Los Roles se aplican al desarrollo de los sistemas en el manejador de base de datos Oracle:

Formato: Rlss

Longitud Máxima: 18 posiciones como máximo

Descripción: rl : Prefijo de Rol ss : Subsistema

Ejemplo: rldi Rol de Importaciones

✓ Profile – Nomenclatura

Formato: pr<nombre del profile> No se aceptan caracteres especiales, indicados en el numeral 6.1 punto 3.


Descripción: pr : Profile

Ejemplo: prlogistica : Profile del área de logística

V. ANEXO Anexo N° 1: “Glosario de Términos”


Página 36 de 39

Anexo N° 1 Glosario de Términos

Para la correcta aplicación de los presentes lineamientos, se tiene en cuenta las siguientes definiciones:

a. Atributo.- Representa las características o propiedades que sirven para calificar, identificar,

clasificar, cuantificar o expresar el estado de una entidad. b. Atributo Propio.- Son atributos que nacen con la entidad y que no son derivados o heredados de

otra entidad. c. Atributo Derivado.- En adición a un atributo propio de la entidad, un atributo debe ser presentado

en una entidad para su derivación a través de una relación o a través de una generalización. Por ejemplo, si cada empleado es asignado a un departamento, el atributo cod_dpto debe ser un atributo de la tabla empleado, el cual ha migrado de la entidad departamento a la entidad empleado a través de la relación entre ellas.

La entidad departamento debe ser la propietaria del atributo cod_dpto. Y solo los atributos de la clave primaria deben ser derivados a través de la relación. El atributo nombre_dpto, por ejemplo, no es un atributo derivado de empleado, en tanto no es parte de la clave primaria de la entidad departamento.

d. Atributos – Herencia.- En un modelo entidad relación (ER), cada atributo es propio de una

entidad, pero un atributo puede ser heredado a otra entidad por herencia. Por ejemplo: el atributo código del empleado de la tabla empleado (entidad genérica) es heredado por la entidad salario empleado (entidad que hereda).

e. Base de Datos.- Es una colección de información contenida en tablas relacionadas entre sí. f. Clave Alterna.- Cuando exista más de una clave candidata, una es designada como la clave

primaria y otra clave candidata es designada como una clave alterna. Si existe solo una clave candidata, entonces esta es la clave primaria.

g. Clave Candidata.- Una clave candidata de una entidad es un atributo o grupo de atributos que

podrían ser elegidos como clave primaria. Una clave candidata para ser aceptada como clave primaria debe identificar unívocamente cada instancia de la entidad, no puede ser nula o tener alguna parte nula y todos los atributos no-clave deben depender completamente de ella. Una clave candidata no debe ser escogida como parte de la clave primaria.

h. Clave Foránea o Foreign Key.- Es la columna o grupo de columnas en una tabla llamada hija que

contiene valores que concuerdan con la clave primaria de otra tabla llamada padre.

i. Claves foráneas en la Generalización.- La clave primaria para cada entidad de categoría hereda de la clave primaria de la entidad genérica. Por ejemplo, si salario-empleado es una entidad de categoría de la entidad genérica empleado y el atributo id_empleado es la clave primaria de la entidad empleado, el atributo id_empleado puede ser la clave primaria de salario-empleado.

j. Clave Primaria o Primary Key.- Es una columna o grupo de columnas que han sido elegidos como

un identificador único de una tabla. Los valores de estas columnas son diferentes en cada fila. Es decir, cada fila es única. Representa una restricción única de los valores de las propiedades de la entidad.


Página 37 de 39

k. Check.- Es un constraint de integridad de una columna o set de columnas que requieren que una condición específica sea verdadera o falsa para cada fila de la tabla.

l. Chunks.- Una colección contigua de espacio en disco asignada a un dbspace de una instancia. m. Datafiles.- Los datafiles son los ficheros físicos en los que se almacenan los objetos que forman

parte de un tablespace. Un datafile pertenece solamente a un tablespace y a una instancia de base de datos. Un tablespace puede estar formado por uno o varios datafiles. Cuando se crea un datafile, se debe indicar su nombre, su ubicación o directorio, el tamaño que va a tener y el tablespace al que va a pertenecer.

n. Dbspace.- Una colección lógica de chunks que forman un pool de espacio en disco, la cual es usada

para almacenar objetos de las bases de datos. o. Entidad.- Es la representación de un conjunto de cosas reales y abstractas como personas,

objetos, lugares, eventos, ideas, combinación de cosas, etc., que son reconocidas como del mismo tipo y que tienen información relevante en el modelo de datos. Tienen atributos y características comunes y pueden relacionarse entre ellas.

p. Entidad de Categoría.- Pertenece a una colección de entidades caracterizadas por satisfacer un

cierto predicado común. q. Entidad Independiente.- Una entidad es independiente si cada instancia de la entidad puede ser

únicamente identificada sin determinar su relación con otra entidad. r. Entidad Dependiente.- Una entidad es dependiente si la única identificación de una instancia de

la entidad depende de su relación con otra entidad. Expresada en términos de la clave foránea, una entidad es dependiente si cada clave foránea es completamente contenida en la clave primaria de otra entidad. De otro lado sería independiente. Las entidades categorías son siempre dependientes-identificadas.

s. Función.- Son sentencias o comandos en SQL que pueden complementar el manejo de los datos

en las consultas. Se utilizan dentro de las expresiones y actúan con los valores de las columnas, variables o constantes.

t. Identificador Único.- Una entidad debe tener un atributo (o combinación de atributos) cuyos

valores únicos identifican cada instancia de la entidad. u. Índices.- Datos estructurados que están asociadas a una o más columnas en una tabla, en que los

valores de la columna se ordenan para mejorar el rendimiento de algunas consultas. v. Instancia.- Una instancia de una entidad con sus correspondientes valores de atributos representa

un objeto concreto del mundo real. Por lo tanto, podemos decir que una entidad describe un conjunto de objetos del mundo real llamados instancias. No pueden existir dos entidades con los mismos atributos.

w. Online, instancia o Data Server.- Es el programa que administra el contenido de la base de datos

y su almacenamiento en los discos; es decir, como las tablas, filas y columnas están almacenadas físicamente en el computador. Asimismo, el online también interpreta y ejecuta comandos SQL.

Un online está conformado por los Server proceses, la shared memory y el espacio en disco.


Página 38 de 39

x. Package.- Este objeto se usa en Oracle para almacenar código PL/SQL en la Base de Datos, el cual agrupa procedimientos almacenados y funciones.

y. Procedimiento Almacenado (Stored Procedure).- Es una rutina definida por el usuario que es

escrita en SPL (Storage Procedure Lenguaje). Es una extensión del SQL y son almacenados en el system, catálogo en formato ejecutable. Una SPL puede ejecutar rutinas escritas en C u otros lenguajes externos.

z. Cursor.- Como un programador puede que desee recuperar varias filas de una tabla de base de

datos con un puntero a cada fila y realizar modificaciones de trabajo en las filas de uno en uno. En estos casos, puede declarar los cursores explícitamente.

aa. Profiles.- Se refiere a las limitaciones de recursos de la base de datos asignadas a los usuarios a

través de estos profiles, los cuales previenen el consumo excesivo de recursos del sistema de base de datos.

bb.Relaciones.- Las relaciones son usadas para representar asociaciones entre entidades. bb. cc. Relación específica.- Es una asociación entre dos entidades en la cual cada instancia de una

entidad (referida a la entidad padre) es asociada con cero, uno o más instancias de la segunda entidad (referida a la entidad hijo). Por lo tanto, cada instancia de la entidad hijo es asociado con cero o una instancia de la entidad padre.

Las relaciones padre-hijo deben ser consideradas como Relaciones especificas porque ellas especifican precisamente como las instancias de una entidad se relaciona con las instancias de una segunda entidad.

dd. Relación no específica.- Debe ser usada para representar una asociación de muchos a

muchos entre dos entidades. Una relación no específica (relaciones de muchos a muchos) es una asociación entre dos entidades en la cual cada instancia de la primera entidad es asociada con cero, uno o muchas instancias de la segunda entidad, y cada instancia de la segunda entidad está asociada con cero, una o más instancias de la primera entidad.

En el desarrollo inicial de un modelo es a menudo útil identificar relaciones no específicas entre

entidades. Esta relación no específica debe ser después reemplazada con relaciones específicas en el desarrollo del modelo al introducir una tercera entidad tal como se generan en los Modelos Físicos. Una entidad introducida para resolver una relación no específica es algunas veces llamada una entidad asociada.

ee. Roles.- Son grupos de privilegios que se otorga a los usuarios o a otros roles. Los roles facilitan la administración de los usuarios de la base de datos y también de los privilegios

de los objetos esquema. ff. Secuencia.- Objeto de datos del manejador de base de datos Oracle que genera automáticamente

números únicos. Normalmente se utiliza para crear un valor de clave primaria, sustituye al código de aplicación y acelera la eficacia del acceso a los valores de secuencia al almacenarse en memoria caché.

gg. Sinónimo.- Es un alias de una tabla, vista, secuencia, procedimiento, función o package. La

utilidad de los sinónimos es la posibilidad de independizar las aplicaciones de los nombres físicos de las tablas que se manejan.


Página 39 de 39

hh. Tabla. Unidad básica de almacenamiento; esta formada por filas (registros) y columnas (campos), identificadas por una o más columnas.

ii. Tablespace.- Es una colección lógica de "extents" que contiene una tabla específica, un índice o

un fragmento. jj. Trigger.- Es un objeto que reside en la base de datos y se encarga de especificar cuando una

particular acción (INSERT, DELETE, UPDATE, EXECUTE PROCEDURE o EXECUTE FUNCTION) ocurre sobre una tabla particular. También se les denomina reglas activas, porque básicamente un trigger consiste en un evento trigger (conjunto de condiciones) y la resultante es una acción de trigger.

kk. Usuarios Propietarios.- Son los dueños de los objetos que se crean en una determinada instancia.

Estos usuarios otorgan los privilegios de los objetos creados por él. ll. Vista.- Es la representación de los datos de una o más tablas utilizando el lenguaje estructurado

de consulta (SQL).

“LINEAMIENTOS PARA LA ESTANDARIZACIÓN DEL DESARROLLO DE …

Documents

Transcript of “LINEAMIENTOS PARA LA ESTANDARIZACIÓN DEL DESARROLLO DE …