estandares de desarrollo base de datos v1.2

8/19/2019 Estandares de Desarrollo Base de Datos v1.2

1/20

ESTANDARES DE DESARROLLO EN BASE DE DATOSVersión 1.2

Jefatura de Arquitectura

Gerencia de Desarrollo de Servicios

Dirección de Tecnologías de Información


2/20

Estándares de Desarrollo y Programación sobre Base de Datos

Dirección: Tecnología de la Información

Versión: 1.2 Noviembre 2014

AMERICA MOVIL PERU SAC Pagina: 2 / 20

REVISIONES

Fecha Versión Descripción Autor

01/Agosto/10 1.0 Versión original Anny Aldorad

15/06/2012 1.1Modificación de estandares alineados a la

Arquitectura de ReferenciaJavier Rosado

11/11/2014 1.2 Modificación de estándares Javier Rosad


3/20





TABLA DE CONTENIDOS

1. OBJETIVO 4

2. ITEMS CONSIDERADOS PARA ESTANDARIZACION 4 2.1 Nomenclaturas de Base de Datos 4 2.2 Nomenclatura de Esquemas 4 2.3 Nomenclatura de Tablespaces: 5 2.4 Nomenclatura de DataFile 5 2.5 Nomenclatura de tablas 5 2.6 Nomenclatura de Columnas 6 2.7 Nomenclatura de Constraints 6 2.8 Nomenclatura de Índices 7 2.9 Nomenclatura de Vistas 7 2.10 Nomenclatura de Tipos De Datos 7 2.11 Nomenclatura de Reglas 7 2.12 Nomenclatura de Defaults 7 2.13 Nomenclatura de Package 8 2.14 Nomenclatura de Stored Procedures 8 2.15 Nomenclatura de Functions 9

2.16 Nomenclatura de Triggers 9 2.17 Nomenclatura de Secuencias 10 2.18 Nomenclatura de Sinónimos 10 2.19 Consideraciones y Convenciones de Programación 11

2.19.1 Consideraciones para pases a Producción 11 2.19.2 Codificación para mejorar la performance 12 2.19.3 Convenciones generales de codificación 12 2.19.4 Convenciones para nombres de variables 15 2.19.5 Manejo de Performance Índices 16 2.19.6 Gestión de transacciones en Functions / StoreProcedures 16 2.19.7 Particionamiento de tablas 16

2.20 Buenas Prácticas para OLTP 17 2.21 Buenas Prácticas para DWH 19


4/20





BASE DE DATOS ORACLE

1. OBJETIVO

Implementar el uso de estándares con las mejores prácticas establecidas por los desarrolladoresadministradores de base de datos de la organización.

2. ITEMS CONSIDERADOS PARA ESTANDARIZACION

2.1 Nomenclaturas de Base de Datos

Prefijo DB_Ejemplo DB_AUDITORIAComentarios Debe ser un nombre representativo escrito con mayúscula

2.2 Nomenclatura de Esquemas

Prefijo USR_Ejemplo USR_ADMINISTRACION, USR_VENTAS Comentarios Debe ser un nombre representativo escrito con mayúscula.

En el ejemplo son los esquemas de VENTAS yADMINISTRACION.


5/20





2.3 Nomenclatura de Tablespaces:

Prefijo TBS__USR

Tipo Tablespace:

DATA: Tablespace de datos.

INDEX: Tablespace de índices.

TEMP: Tablespace temporal.

Ejemplo TBS_DATA_USRADMINISTRACION, TBS_INDEX_USRVENTASComentarios Debe ser un nombre representativo escrito con mayúscula.

En el ejemplo son los Tablespace de los esquemas de VENTAS yADMINISTRACION.

2.4 Nomenclatura de DataFile

Prefijo DF_USR_ Ejemplo DF_USRADMINISTRACION_001, DF_USRADMINISTRACION_002,

DF_USRVENTAS_001Comentarios Debe ser un nombre representativo escrito con mayúscula.Por cada Tablespace existente se creara un Datafile el cual serácodificado de la siguiente manera, esto ya no se realizara si seusa ASM, el cual es un filesystem y un volume managerintegrado.

2.5 Nomenclatura de tablas

Prefijo T_

T : Tabla Ejemplo AUDIT_USUARIO : Tabla de UsuarioComentarios Para tablas temporales locales el límite máximo es 20 caracteres

incluyendo al #, escrito con mayúscula.El prefijo Sistema debe ser de 4 caracteresEl nombre de tabla debe de ser como máximo 20 caracteresTodo debe ser escrito con mayúscula


6/20





2.6 Nomenclatura de Columnas

Prefijo _Prefijo : Debe ser de 4 caracteresTipo Dato: debe ser como máximo 2 caracteres

C : Char V : Varchar D : Datetime N : Numeric I : Integer SD: SmallDatetime

Ejemplo USUAV_NOMBRE varchar(50) : Nombre de UsuarioUSUAV_APEPAT varchar(50) : Apellido Paterno UsuarioUSUAC_FLAG char(1) : Flag de UsaurioUSUAD_FEC_ALTA datetime : Fecha de Alta

Comentarios La longitud máxima del Nombre de Campo, en algún caso extremo,será de 20 caracteres.

2.7 Nomenclatura de Constraints

Prefijo Primary KeyPK_Altern Key AK__ Foreign Key FK__ Default DF__ Check :

De Campo CKC__De Tabla CKT__

Ejemplo PK_USUAT_USUAC_COD Clave Primaria USUAC_COD.AK_ USUAC_COD_001 Clave Alterna USUAC_COD.FK_ USUAT_USUAC_CODCKC_USUAT_USUAC_COD

Comentarios Todo constraint debe tener un nombre de acuerdo al estándarespecificado.

La Tabla Referencia es aquella cuyos campos deben existir en latabla origen (existe una relación de referencia)

No puede incluir al #. El Constraint Primary Key Genera un índice clustered, Unique con

el mismo nombre El Constraint Alternate Key Genera un índice nonclustered, Unique

con el mismo nombre

El Constraint Foreign Key Genera un índice nonclustered, con elmismo nombre


7/20





2.8 Nomenclatura de Índices

Prefijo IX__Ejemplo IX_AUDIT_USUARIO _001Comentarios Usar esta nomenclatura para índices que no dependen de un

constraint El Correlativo a usar es de 3 dígitos( números).

2.9 Nomenclatura de Vistas

Prefijo V__V : VISTA

Ejemplo AUDIV_CONSULTA_USUARIO Comentarios En el caso que la vista sea sobre una única tabla, se adopta el

nombre de la tabla, en caso contrario se utiliza los criterios paranombrar tablas.

2.10 Nomenclatura de Tipos De Datos

Prefijo T_Ejemplo T_IMPORTEComentarios Usar TIPOS DE DATOS cuando se hayan definidos Dominios

2.11 Nomenclatura de Reglas

Prefijo R_Ejemplo R_IMPORTE

Comentarios Usar RULES solo para user defined data types, en caso decolumnas usar CHECKS.

2.12 Nomenclatura de Defaults

Prefijo D_Ejemplo D_IMPORTEComentarios Usar DEFAULT (Procedural) solo para user definied data types, en

caso de columnas usar DEFAULT (Declarativo).


8/20





2.13 Nomenclatura de Package

Prefijo PKG_

Ejemplo PKG_CONSULTA_USUARIOS: Package con losprocedimientos para consultor usuarios de sistema.

PKG_NUMEROS_rpc: Package con los procedimientos paraconsultor números de la rpc.

Comentarios La longitud máxima del Nombre de los paquetes, en algún casoextremo, será de 25 caracteres.

Todo PAquete deberá ser documentado con la siguiente estructura.

'****************************************************************'* Nombre Package : '* Propósito : Explicar en forma detallada'* Input : - Descripción de los parametros'* Output : '* Creado por : '* Fec Creación : '* Fec Actualización : '****************************************************************

2.14 Nomenclatura de Stored Procedures

Prefijo SX_X puede ser:S = SP SelectI = SP InsertU = SP UpdateD = SP Delete

Ejemplo AUDISS_USUARIO :SP Select Usuarios AUDISI_USUARIO :SP Insert de Usuarios AUDISU_USUARIO :SP Update de Usuarios

Comentarios La longitud máxima del Nombre SP, en algún caso extremo, será de15 caracteres.


9/20





Todo Procedimiento Almacenado deberá ser documentado con la siguiente estructura.

'****************************************************************'* Nombre SP :


10/20





2.17 Nomenclatura de Secuencias

Prefijo SEQ_

Ejemplo AUDISEQ_USUARIO AUDISEQ_USUARIO

Comentarios La longitud máxima del Nombre de una secuencia, en algún casoextremo, será de 15 caracteres.

Toda Secuencia deberá ser documentada con la siguiente estructura.

'****************************************************************'* Nombre Secuencia : '* Propósito : Explicar en forma detallada'* Output : '* Creado por : '* Fec Creación : '* Fec Actualización : '****************************************************************

2.18 Nomenclatura de Sinónimos

Prefijo SYXX_

XX puede ser:

PU = PublicoPR = Privado

Ejemplo AUDISYPU_USUARIO AUDISYPR_USUARIO

Comentarios La longitud máxima del Nombre del sinonimo, en algún casoextremo, será de 15 caracteres.


11/20





Todo Sinónimo deberá ser documentado con la siguiente estructura.

'****************************************************************'* Nombre Sinónimo : '* Propósito : Explicar en forma detallada'* Output : '* Creado por : '* Fec Creación : '* Fec Actualización : '****************************************************************

2.19

Consideraciones y Convenciones de Programación2.19.1 Consideraciones para pases a Producción

Todo pase a producción debe cumplir con los estándares fijados en el presentedocumento.

Es obligatorio el uso de un modelador de datos.

Todos los aplicativos deben estar documentados (contar con un diccionario de datos ydiagramas de procesos).

El uso de tipos de datos o dominios es obligatorio para estandarizar el tamaño de loscampos, en el caso de uso de estados se deben especificar checks para esascolumnas, estando dichos estados claramente identificados y definidos en sudiccionario de datos y en el diagrama de modelo de datos claramente identificados.

Deberán enviar los modelos de datos conteniendo los usuarios a los cuales se tieneque dar permisos.

La creación de tablas, índices, y constraints de tipo primary key deben referenciar aTablespace en el cual se crearan estos objetos.

La creación de cualquier objeto (procedures, packages, functions, tablas, índices, etcdebe contener el OWNER (esquema).

La creación de cualquier objeto (procedures, packages, functions, tablas, índices, etcdebe contener al final un “/”.

Los privilegios de accesos (GRANTS) también deben ser considerados.

Los sinónimos deben ser privados.


12/20





Es MUY importante que cada pase contenga su procedimiento y script de ROLLBAC

el cual debe considerar: Script de rollback para las operaciones DMLs (Inserts, Updates, Deletes).

Ejemplo: Si el PP implica operaciones de Insert, el rollback será el Delete de losregistros insertados.

Script de rollback para los objetos nuevos (tablas, índices, procedures, etc).Esto queda a consideración de Desarrollo y QA por tratarse de objetos nuevos.

2.19.2 Codificación para mejorar la performance

Se usarán Stored Procedures para codificar todas las sentencias SQL,el uso desentencias SQL en el lado del cliente debe ser totalmente evitado .

Todos los stored procedures que realicen actualizaciones debe ejecutarse mediantetransacciones, el uso de transacciones es necesario y de uso obligatorio en todos losprocesos de actualización.

Cuando se codifiquen transacciones grandes se debe usar savepoints (SAVE TRAN)en los lugares adecuados para evitar rollbacks costosos.

2.19.3 Convenciones generales de codificación

Todas las rutinas (STORED PROCEDURE, TRIGGER, VIEW, FUNCTIONS,….) debenempezar con un comentario corto describiendo las características funcionales de larutina (Qué es lo que hace). Este comentario no debe describir los detalles de laimplementación de la rutina (Cómo lo hace) porque la implementación puede cambicon el tiempo, resultando que tenemos un trabajo innecesario de mantenimiento decomentario o peor aún que tenemos comentarios erróneos. El código por sí mismo ocualquier comentario en línea o comentario local describirá la implementación de lrutina. Debe contener también el nombre del autor.


13/20





Ejemplo de comentario:

CREATE PROCEDURE AUDISS_USUARIO/*

******************************************************Procedimiento : AUDISS_USUARIOPropósito : Este procedimiento es responsable de

...Inputs : N/AOuputs : N/ASe asume : N/AEfectos : N/ARetorno : N/A

Notas : N/AModificaciones : N/AEncargado :XXXXXXXXFecha y hora : 12/04/2002 - 11:13 pm.******************************************************

*/

El uso de los DBLINKS y DIRECTORIES no son recomendables, estos seránpermitidos siempre y cuando se vea la necesidad y se tenga la aprobación delAdministrador de Base de Datos como el personal de Seguridad.

Los parámetros pasados a los STORED PROCEDURE deben ser descritos cuando sufunciones no sean obvias y cuando la rutina espera que el parámetro esté en un rangoespecifico de valores. El valor de retorno del STORED PROCEDURE, las variablglobales que son cambiadas por la rutina y especialmente parámetros pasados porreferencia(OUTPUT), deben también ser descritos al inicio de cada STOREDPROCEDURE.

Todos los comentarios de mas de una línea deben hacerse con los caracteres “/* */”dela siguiente manera:

CREATE TRIGGER AUDITRI_USUARIO

/** Because CHECK constraints can reference the column(s)* on which the column- or table-level constraint has* been defined, any cross-table constraints (in this case,* business rules) need to be defined as triggers.*/ON AUDIT_USUARIO

FOR INSERT

AS...


14/20





Todos los comentarios de una línea, comentarios en línea (In-line) o comentariosanidados deben ser escritos con los caracteres “--”, de la siguiente manera.

-- Get the range of level for this job type from the jobs table.DECLARE @C_MIN_LVL tinyint, -- Minimum level var. declaratio

@C_MAX_LVL tinyint, -- Maximum level var. declaration@C_EMP_LVL tinyint, -- Employee level var. declaration@C_JOB_ID smallint -- Job ID var. Declaration

SELECT @C_USUARIO = USUAC_COD , -- Set Codigo usuario@C_NOMBRE = USUAV_NOMBRE -- Set nombre de usuario

FROM AUDIT_USUARIO A,AUDIT_ACCESO B

WHERE A.USUAC:COD = B.USUAC_CODAND B.ACCI_ACTIVO=1

El bloque de comentario al inicio de cada rutina debe considerar lo siguiente:

Sección Descripción del comentarioNombre Nombre de la rutina y nombre de la persona que lo creoPropósito QUE es lo que la rutina hace (NO COMO).Inputs Cada parámetro no obvio en líneas separadas con comentarios en lín

Se asume Lista de cada variable externa no obvia, archivo, y cualquier dependencia.Retorno Explicación del valor retornado por la variable (outputs).Modificaciones Ver apartado de ModificacionesEfectos Variables externas, archivo, etc afectadas (Sólo sino es obvia)Fecha Fecha de creación y Modificación

Los nombres deben ser lo suficientemente largos para auto-documentar su funciónespecialmente en el caso de STORED PROCEDURES.

En caso de nombres con varias palabras, éstas deben separase con un carácter “_”, dela siguiente manera: palabras_del_nombre.

Para reflejar la estructura lógica del código, debe usarse el carácter TAB. NO usarespacios ASCII(32). El TAB debe configurarse como ocho caracteres.

http://d/EAI/Modificaciones/Modificaciones.dochttp://d/EAI/Modificaciones/Modificaciones.doc


15/20





Las sentencias SQL deben escribirse de una manera que reflejen la estructura lógica

de la sentencia, evitar totalmente construir sentencias como:SELECT CH_C1, CH_C2, CH_C3FROM SGT_TA_TABLA1 TABLA1, SGT_TA_TABLA2 TABLA2WHERE TABLA1. CH_C1 = TABLA2. CH_C2 AND

TABLA.DT_D4 = GETDATE()

en su lugar construir sentencias como:

SELECT USUAC_C1,USUAV_C2,USUAV_C3

FROM AUDIT_TABLA1 TABLA1, AUDIT_TABLA2 TABLA2WHERE TABLA1. USUAC_C1 = TABLA2.USUAC_C2 ANDTABLA2.USUAD_C4 = GETDATE()

2.19.4 Convenciones para nombres de variables

Todos los nombres de variables debe escribirse en letras mayúsculas separando laspalabras con un underscore “_”, además deben seguir el siguiente formato:

Tipo_de_variable_nombre_de_la_variable

Donde el tipo de variable es se define a continuación:Parámetro : KVariable local o global: VVariable de Columna de Tabla: C

Ejemplo:@K_CODIGO_CLIENTE@V_CODIGO_CLIENTE_AUX@C_CODIGO_UNICO

En la medida de lo posible no usar abreviaciones para variables no triviales, puesdificultan la lectura del código, en casos donde sea conveniente el uso deabreviaciones (Nombres muy largos o nombres usados intensamente), ésasabreviaciones deben estar incluidas el repositorio de estándares del proyecto.


16/20





2.19.5 Manejo de Performance Índices

Se deberá indexar las columnas que sean estrictamente necesarias.

No crear índices en los siguientes casos: Columnas que son raramente referenciadas en una consulta. Columnas que tienen pocos valores únicos. Columnas con tipo de dato: Text, Image, bit.

2.19.6 Gestión de transacciones en Functions / StoreProcedures

Evitar que losnuevos StoreProcedure y Functions contengan COMMIT como parte dela programación, la gestión de las transacciones la debe gestionar la aplicación quehace uso de dichos objetos para asegurar la integridad de una transacción queinvolucre a varios objetos.

2.19.7 Particionamiento de tablas

Se sugiere la implementación en módulos con gran volumen de información departicionamiento de tablas e índices particionados implementando el tipo RANGE-LIcompuesto, que asigna los registros de la tabla a diferentes particiones definidas según erango de valores en una columna determinada o con una lista de valores. Con esto sebusca que el acceso a la información desde los distintos sistemas en tablas con grancantidad de registros, tenga una segmentación lógica de la información permitiendooptimizar el rendimiento de acceso a la información en los sistemas operacionales.

Entre los criterios para particionar una tabla e índices se recomienda:

Tabla con un volumen de registros sobre 1 millón anual y de al menos 5 camposincluyendo fechas

Particionamiento utilizando rangos de fechas acotados a un año especifico, ej.Nombretabla_particion2010 para los datos ingresados que contengan en la columnaque condiciona la partición con el valor del año 2010, ya que los rangos que ocupanserán solamente campos tipo date.

Si se desea dar obsolescencia a datos (pasar a histórico) se puede implementar unacolumna de control donde se indica que el dato es obsoleto y pasa a ser parte de lasparticiones con menos prioridad en las búsquedas. Esta es una característica quepuede ser explotada en conjunto a rangos en motores Oracle 11g.


17/20





2.20 Buenas Prácticas para OLTP

Usar UNION ALL en lugar de UNION para evitar ordenamiento innecesario.

Evitar las conversiones de tipos de datos innecesarios.

Evitar usar usuarios y esquemas con roles de DBA o tener más privilegios de lo que srequieren.

Usar GLOBAL TEMPORARY TABLE para tablas temporales, no usar tablas físicas.

Usar Tablas Temporales y/o la cláusula WITH para reescribir Subqueries complejos.

Usar MINUS en los Subqueries en lugar de EXISTS.

Usar EXISTS en Lugar de IN.

Evitar el uso de NOT IN o HAVING.

Evitar el uso de LIKE en el predicado.

No mezclar tipos de datos diferentes en la cláusula WHERE.

Evitar innecesarios FULL TABLE SCAN en tablas grandes.

Evitar hacer algún calculo en una COLUMNA que tiene INDICE en el WHERE a meque exista una INDICE basado en Función para esta columna.

Crear tablas e índices en diferentes Tablespaces.

Evitar usar excesivos INDICES, en lo posible reusar los que se tengan, muchos índicedegradan la Inserción y actualización de información.

Usar Result Cache en PLSQL.

Usar NOCOPY Compiler Hint en PLSQL.

Crear los índices apropiados y estrictamente necesarios.

Analizar Siempre los planes de ejecución de las sentencias SQL/PLSQL.

Usar BULK COLLECT para las sentencias SELECT en consultas recursivas y masiv(Bulk SQL.)

Usar FORALL para las sentencias DML en la actualización recursiva y masiva de Dat(Bulk SQL).


18/20





Anidar una consulta para mejorar el rendimiento.

Evitar la conversión de tipos de Datos, seleccionar los tipos de datos con cuidado paraminimizar las conversiones implícitas. Como por ejemplo usar datos tipo carácter paexpresiones de cadena o Datos tipo decimales en expresiones numéricas o decálculos.

Dimensionar correctamente el tamaño de los varchar2, es decir lo que realmente senecesita para almacenar el dato, un valor alto genera uso innecesario de Memoria.

Usar PLS_INTEGER cuando se trabaja con datos enteros en vez de INTEGER oNUMBER.

Use COMPOUND TRIGGERS para inserción o actualización masiva.

Evitar la generación de Producto Cartesiano.

Usar mayor (>) o menor (


19/20





2.21 Buenas Prácticas para DWH

Usar la funcionalidad de Paralelismo en forma adecuada.

Usar parallel para operaciones UNICAS y Pesadas (como agregaciones o batch) enningún caso para operaciones MASIVAS o concurrentes (Ej. detalle de llamadas).

Evitar ejecutar operaciones DML con Parallel mas de 8, si requieren de masparalelismo, validarlo con un DBA.

Evitar crear Tablas e índices con Parallel, siempre Validar la creación de objetos con eDBA.

Usar el paralelismo a nivel de sesión no a nivel de objeto (tablas o índices) como:“ALTER SESSION FORCE PARALLEL QUERY PARALLEL 8;”

Para la Creación de tablas de trabajo USAR los tablespaces asignados para tal fin(WORK_DATA, WORK_INDX).

Depurar o Borrar las tablas de trabajo y/o temporales frecuentemente.

Usar Sentencias y funciones de análisis en lugar de Sentencias transaccionales paraprocesamiento de grandes volúmenes de información, como: MERGE, MODULECUBE, RANK, etc.

Usar MERGE en vez de Cursores para procesos que demandan gran volumen deDatos, evitando el uso de INDICES.

En lo posible Evitar la creación de INDICES, Los INDICES en general son parprocesos OLTP (Recuperación de pocos registros) no de Datawarehouse que requiereprocesar gran volumen de registros.

Para la creación y carga de tablas con información reciente o vigente usar el tipo decompresión FOR QUERY HIGH.

Para la creación y Carga de tablas con información Histórica usar el tipo de compresióFOR ARCHIVE HIGH.

Antes de ejecutar un DML evaluar su plan de ejecución y optimizar al máximo dicplan, es decir que use eficientemente los recursos de la BD.

Evite el uso de PLSQL cuando el código SQL puede ser mejor y mas rápido.

No USAR UTL_FILE para leer archivos planos en lugar de ello usar TABLAEXTERNAS.


20/20




Usar SQL MERGE en vez de PLSQL para comparar y procesar gran volumen de

registros. Usar DBMS_ERRLOG para la gestión de errores de DML en vez de Código PLSQ

(Excepciones).

Activar Calidad de Servicio (QoS) para asegurar los tiempos de respuesta adecuados yel uso eficiente de los recursos de la Base de Datos.

Usar Particionamiento para mejorar el acceso a la Información.

Evitar el uso de UPDATE o DELETE para corregir información; es mejor eliminar particiones respectivas y volver a cargar la información.

estandares de desarrollo base de datos v1.2

Documents