Estandares de Desarrollo Base de Datos v1.2

ESTANDARES DE DESARROLLO EN BASE DE DATOS
Versin 1.2
Jefatura de Arquitectura
Gerencia de Desarrollo de Servicios
Direccin de Tecnologas de Informacin
Estndares de Desarrollo y Programacin sobre Base de Datos

Direccin: Tecnologa de la Informacin
Versin: 1.2
Noviembre 2014
REVISIONES
Fecha
Versin
01/Agosto/10
1.0
15/06/2012
1.1
11/11/2014
1.2
AMERICA MOVIL PERU SAC
Descripcin
Versin original
Modificacin de estandares alineados a la
Arquitectura de Referencia
Modificacin de estndares
Autor
Anny Aldoradin
Javier Rosado
Javier Rosado
Pagina: 2 / 20

Versin: 1.2
Noviembre 2014
TABLA DE CONTENIDOS
1.
OBJETIVO
2.
ITEMS CONSIDERADOS PARA ESTANDARIZACION
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
Nomenclaturas de Base de Datos

Nomenclatura de Esquemas
Nomenclatura de Tablespaces:
Nomenclatura de DataFile
Nomenclatura de tablas
Nomenclatura de Columnas
Nomenclatura de Constraints
Nomenclatura de ndices
Nomenclatura de Vistas
Nomenclatura de Tipos De Datos
Nomenclatura de Reglas
Nomenclatura de Defaults
Nomenclatura de Package
Nomenclatura de Stored Procedures
Nomenclatura de Functions
Nomenclatura de Triggers
Nomenclatura de Secuencias
Nomenclatura de Sinnimos
Consideraciones y Convenciones de Programacin
2.19.1 Consideraciones para pases a Produccin
2.19.2 Codificacin para mejorar la performance
2.19.3 Convenciones generales de codificacin
2.19.4 Convenciones para nombres de variables
2.19.5 Manejo de Performance ndices
2.19.6 Gestin de transacciones en Functions / StoreProcedures
2.19.7 Particionamiento de tablas
2.20 Buenas Prcticas para OLTP
2.21 Buenas Prcticas para DWH
4
4
5
5
5
6
6
7
7
7
7
7
8
8
9
9
10
10
11
11
12
12
15
16
16
16
17
19
Pagina: 3 / 20

Versin: 1.2
Noviembre 2014
BASE DE DATOS ORACLE

1. OBJETIVO
Implementar el uso de estndares con las mejores prcticas establecidas por los desarrolladores y
administradores de base de datos de la organizacin.
2. ITEMS CONSIDERADOS PARA ESTANDARIZACION
2.1 Nomenclaturas de Base de Datos
Prefijo
Ejemplo
Comentarios
DB_<Sistema>
DB_AUDITORIA
Debe ser un nombre representativo escrito con mayscula
2.2 Nomenclatura de Esquemas

Prefijo
Ejemplo
Comentarios
USR_<MODULO>
USR_ADMINISTRACION, USR_VENTAS
Debe ser un nombre representativo escrito con mayscula.
En el ejemplo son los esquemas de VENTAS
ADMINISTRACION.
Pagina: 4 / 20

Versin: 1.2
Noviembre 2014
2.3 Nomenclatura de Tablespaces:

Prefijo
TBS_<TIPO>_USR<MODULO>
Tipo Tablespace:
DATA: Tablespace de datos.
INDEX: Tablespace de ndices.
TEMP: Tablespace temporal.
Ejemplo
Comentarios
TBS_DATA_USRADMINISTRACION, TBS_INDEX_USRVENTAS
En el ejemplo son los Tablespace de los esquemas de VENTAS y
ADMINISTRACION.
2.4 Nomenclatura de DataFile

Prefijo
Ejemplo
Comentarios
DF_USR<MODULO>_ <CORRELATIVO POR DATAFILE>

DF_USRADMINISTRACION_001, DF_USRADMINISTRACION_002,
DF_USRVENTAS_001
Por cada Tablespace existente se creara un Datafile el cual ser
codificado de la siguiente manera, esto ya no se realizara si se
usa ASM, el cual es un filesystem y un volume manager
integrado.
2.5 Nomenclatura de tablas

Prefijo
<Prefijo Sistema>T_<NombreTabla>
T : Tabla
Ejemplo
Comentarios
AUDIT_USUARIO : Tabla de Usuario

Para tablas temporales locales el lmite mximo es 20 caracteres
incluyendo al #, escrito con mayscula.
El prefijo Sistema debe ser de 4 caracteres
El nombre de tabla debe de ser como mximo 20 caracteres
Todo debe ser escrito con mayscula
Pagina: 5 / 20

Versin: 1.2
Noviembre 2014
2.6 Nomenclatura de Columnas

Prefijo
<Prefijo Tabla><Tipo Dato>_<Nombre Campo>

Prefijo : Debe ser de 4 caracteres
Tipo Dato: debe ser como mximo 2 caracteres
C : Char
V : Varchar
D : Datetime
N : Numeric
I : Integer
SD: SmallDatetime
Ejemplo
USUAV_NOMBRE varchar(50) : Nombre de Usuario

USUAV_APEPAT varchar(50) : Apellido Paterno Usuario
USUAC_FLAG
char(1) : Flag de Usaurio
USUAD_FEC_ALTA datetime : Fecha de Alta
Comentarios
La longitud mxima del Nombre de Campo, en algn caso extremo,

ser de 20 caracteres.
2.7 Nomenclatura de Constraints

Prefijo
Ejemplo
Comentarios
Primary Key PK_<TABLA>

Altern Key
AK_<TABLA>_<CORREL.TABLA>
Foreign Key FK_<TAB. ORIGEN>_<TAB. REFER.>
Default
DF_<TABLA>_<CAMPO>
Check
:
De Campo
CKC_<TABLA>_<CAMPO>
De Tabla
CKT_<TABLA>_<NOMBRE>
PK_USUAT_USUAC_COD Clave Primaria USUAC_COD.
AK_ USUAC_COD_001 Clave Alterna USUAC_COD.
FK_ USUAT_USUAC_COD
CKC_USUAT_USUAC_COD
Todo constraint debe tener un nombre de acuerdo al estndar
especificado.
La Tabla Referencia es aquella cuyos campos deben existir en la
tabla origen (existe una relacin 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 el
mismo nombre
Pagina: 6 / 20

Versin: 1.2
Noviembre 2014
2.8 Nomenclatura de ndices

Prefijo
Ejemplo
Comentarios
IX_<Nombre TABLA>_<CORRELATIVO POR TABLA>

IX_AUDIT_USUARIO_001
Usar esta nomenclatura para ndices que no dependen de un
constraint
El Correlativo a usar es de 3 dgitos( nmeros).
2.9 Nomenclatura de Vistas

Prefijo
Ejemplo
Comentarios
<PrefijoSistema>V__<NombreVista>
V : VISTA
AUDIV_CONSULTA_USUARIO
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 para
nombrar tablas.
2.10 Nomenclatura de Tipos De Datos

Prefijo
Ejemplo
Comentarios
T_<NombreTipoDato>
T_IMPORTE
Usar TIPOS DE DATOS cuando se hayan definidos Dominios
2.11 Nomenclatura de Reglas

Prefijo
Ejemplo
Comentarios
R_<NombreRegla>
R_IMPORTE
Usar RULES solo para user defined data types, en caso de
columnas usar CHECKS.
2.12 Nomenclatura de Defaults

Prefijo
Ejemplo
Comentarios
D_<Nombre_Default>
D_IMPORTE
Usar DEFAULT (Procedural) solo para user definied data types, en
caso de columnas usar DEFAULT (Declarativo).
Pagina: 7 / 20

Versin: 1.2
Noviembre 2014
2.13 Nomenclatura de Package

Prefijo
PKG_<Nombre_Package>
Ejemplo
PKG_CONSULTA_USUARIOS:
Package
con
los
procedimientos para consultor usuarios de sistema.
PKG_NUMEROS_rpc: Package con los procedimientos para
consultor nmeros de la rpc.
La longitud mxima del Nombre de los paquetes, en algn caso
extremo, ser de 25 caracteres.
Comentarios
Todo PAquete deber ser documentado con la siguiente estructura.

'****************************************************************
'* Nombre Package
: <Nombre del Paquete>
'* Propsito
: Explicar en forma detallada
'* Input
: <Parametro> - Descripcin de los parametros
'* Output
: <Descripcin de la Salida>
'* Creado por
: <Responsable>
'* Fec Creacin
: <Fecha Creacin>
'* Fec Actualizacin
: <Fecha de Actualizacin>
'****************************************************************
2.14 Nomenclatura de Stored Procedures
Prefijo
Ejemplo
Comentarios
<PrefijoSistema>SX_<NombreSP>
X puede ser:
S
= SP Select
I
= SP Insert
U
= SP Update
D
= SP Delete
AUDISS_USUARIO : SP Select Usuarios
AUDISI_USUARIO : SP Insert de Usuarios
AUDISU_USUARIO : SP Update de Usuarios
La longitud mxima del Nombre SP, en algn caso extremo, ser de
15 caracteres.
Pagina: 8 / 20

Versin: 1.2
Noviembre 2014
Todo Procedimiento Almacenado deber ser documentado con la siguiente estructura.

'****************************************************************
'* Nombre SP
: <Nombre del SP
'* Propsito
'* Input
: <Parametro> - Descripcin de los parametros
'* Output
'* Creado por
: <Responsable>
'* Fec Creacin
: <Fecha Creacin>
'* Fec Actualizacin
'****************************************************************
2.15 Nomenclatura de Functions
Prefijo
Ejemplo
<PrefijoSistema>FUN_<NombreTabla>
AUDIFUN_USUARIO
AUDIFUN_USUARIO
Comentarios
La longitud mxima del Nombre de la funcion, en algn caso

Toda Funcin deber ser documentado con la siguiente estructura.

'****************************************************************
'* Nombre FUN
: <Nombre de la Funcin>
'* Propsito
: <Explicar en forma detallada>
'* Output
'* Creado por
: <Responsable>
'* Fec Creacin
: <Fecha Creacin>
'* Fec Actualizacin
'****************************************************************
2.16 Nomenclatura de Triggers
Prefijo
<PrefijoSistema>TRX_<NombreTabla>
X puede ser:
I : Insert
U: Update
D: Delete
Ejemplo
Comentarios
La longitud mxima del Nombre del trigger, en algn caso extremo,

ser de 15 caracteres.
AUDITRI_USUARIO
AUDITRU_USUARIO
Pagina: 9 / 20

Versin: 1.2
Noviembre 2014
2.17 Nomenclatura de Secuencias

Prefijo
<PrefijoSistema>SEQ_<NombreTabla>
Ejemplo
Comentarios
La longitud mxima del Nombre de una secuencia, en algn caso

AUDISEQ_USUARIO
AUDISEQ_USUARIO
Toda Secuencia deber ser documentada con la siguiente estructura.

'****************************************************************
'* Nombre Secuencia : <Nombre de la Secuencia>
'* Propsito
'* Output
'* Creado por
: <Responsable>
'* Fec Creacin
: <Fecha Creacin>
'* Fec Actualizacin
'****************************************************************
2.18 Nomenclatura de Sinnimos
Prefijo
<PrefijoSistema>SYXX_<NombreTabla>
XX puede ser:
Ejemplo
Comentarios
PU
= Publico
PR
= Privado
AUDISYPU_USUARIO
AUDISYPR_USUARIO
La longitud mxima del Nombre del sinonimo, en algn caso
Pagina: 10 / 20

Versin: 1.2
Noviembre 2014
Todo Sinnimo deber ser documentado con la siguiente estructura.

'****************************************************************
'* Nombre Sinnimo
: <Nombre de la Sinonimo>
'* Propsito
'* Output
'* Creado por
: <Responsable>
'* Fec Creacin
: <Fecha Creacin>
'* Fec Actualizacin
'****************************************************************
2.19 Consideraciones y Convenciones de Programacin
2.19.1 Consideraciones para pases a Produccin
Todo pase a produccin debe cumplir con los estndares fijados en el presente
documento.
Es obligatorio el uso de un modelador de datos.
Todos los aplicativos deben estar documentados (contar con un diccionario de datos y
diagramas de procesos).
El uso de tipos de datos o dominios es obligatorio para estandarizar el tamao de los

campos, en el caso de uso de estados se deben especificar checks para esas
columnas, estando dichos estados claramente identificados y definidos en su
diccionario de datos y en el diagrama de modelo de datos claramente identificados.
Debern enviar los modelos de datos conteniendo los usuarios a los cuales se tiene
que dar permisos.
La creacin de tablas, ndices, y constraints de tipo primary key deben referenciar al

Tablespace en el cual se crearan estos objetos.
La creacin de cualquier objeto (procedures, packages, functions, tablas, ndices, etc)

debe contener el OWNER (esquema).
La creacin de cualquier objeto (procedures, packages, functions, tablas, ndices, etc)

debe contener al final un /.
Los privilegios de accesos (GRANTS) tambin deben ser considerados.
Los sinnimos deben ser privados.
Pagina: 11 / 20

Versin: 1.2
Noviembre 2014
Es MUY importante que cada pase contenga su procedimiento y script de ROLLBACK,

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 los
registros insertados.
Script de rollback para los objetos nuevos (tablas, ndices, procedures, etc).
Esto queda a consideracin de Desarrollo y QA por tratarse de objetos nuevos.
2.19.2 Codificacin para mejorar la performance
Se usarn Stored Procedures para codificar todas las sentencias SQL, el uso de
sentencias SQL en el lado del cliente debe ser totalmente evitado.
Todos los stored procedures que realicen actualizaciones debe ejecutarse mediante
transacciones, el uso de transacciones es necesario y de uso obligatorio en todos los
procesos de actualizacin.
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 codificacin
Todas las rutinas (STORED PROCEDURE, TRIGGER, VIEW, FUNCTIONS,.) deben

empezar con un comentario corto describiendo las caractersticas funcionales de la
rutina (Qu es lo que hace). Este comentario no debe describir los detalles de la
implementacin de la rutina (Cmo lo hace) porque la implementacin puede cambiar
con el tiempo, resultando que tenemos un trabajo innecesario de mantenimiento del
comentario o peor an que tenemos comentarios errneos. El cdigo por s mismo o
cualquier comentario en lnea o comentario local describir la implementacin de la
rutina. Debe contener tambin el nombre del autor.
Pagina: 12 / 20

Versin: 1.2
Noviembre 2014
Ejemplo de comentario:
CREATE PROCEDURE AUDISS_USUARIO
/*
******************************************************
Procedimiento : AUDISS_USUARIO
Propsito
: Este procedimiento es responsable de
...
Inputs : N/A
Ouputs
: N/A
Se asume
: N/A
Efectos
: N/A
Retorno
: N/A
Notas
: N/A
Modificaciones : N/A
Encargado
:XXXXXXXX
Fecha y hora
: 12/04/2002 - 11:13 pm.
******************************************************
*/
El uso de los DBLINKS y DIRECTORIES no son recomendables, estos sern

permitidos siempre y cuando se vea la necesidad y se tenga la aprobacin del
Administrador de Base de Datos como el personal de Seguridad.
Los parmetros pasados a los STORED PROCEDURE deben ser descritos cuando sus
funciones no sean obvias y cuando la rutina espera que el parmetro est en un rango
especifico de valores. El valor de retorno del STORED PROCEDURE, las variables
globales que son cambiadas por la rutina y especialmente parmetros pasados por
referencia (OUTPUT), deben tambin ser descritos al inicio de cada STORED
PROCEDURE.
Todos los comentarios de mas de una lnea deben hacerse con los caracteres /* */de
la 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
*/
ON AUDIT_USUARIO
defined
as
triggers.
FOR INSERT
AS
...
Pagina: 13 / 20

Versin: 1.2
Noviembre 2014
Todos los comentarios de una lnea, comentarios en lnea (In-line) o comentarios

anidados 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.
declaration
@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 ,
-@C_NOMBRE = USUAV_NOMBRE
-FROM
AUDIT_ACCESO
WHERE
A.USUAC:COD
AND B.ACCI_ACTIVO=1
Set
Codigo
Set
nombre
de
AUDIT_USUARIO
=
usuario
usuario
A,
B
B.USUAC_COD
El bloque de comentario al inicio de cada rutina debe considerar lo siguiente:

Seccin
Nombre
Propsito
Inputs
Se asume
Retorno
Modificaciones
Efectos
Fecha
Descripcin del comentario

Nombre de la rutina y nombre de la persona que lo creo
QUE es lo que la rutina hace (NO COMO).
Cada parmetro no obvio en lneas separadas con comentarios en lnea.
Lista de cada variable externa no obvia, archivo, y cualquier otra
dependencia.
Explicacin del valor retornado por la variable (outputs).
Ver apartado de Modificaciones
Variables externas, archivo, etc afectadas (Slo sino es obvia)
Fecha de creacin y Modificacin
Los nombres deben ser lo suficientemente largos para auto-documentar su funcin,

especialmente en el caso de STORED PROCEDURES.
En caso de nombres con varias palabras, stas deben separase con un carcter _, de
la siguiente manera: palabras_del_nombre.
Para reflejar la estructura lgica del cdigo, debe usarse el carcter TAB. NO usar
espacios ASCII(32). El TAB debe configurarse como ocho caracteres.
Pagina: 14 / 20

Versin: 1.2
Noviembre 2014
Las sentencias SQL deben escribirse de una manera que reflejen la estructura lgica
de la sentencia, evitar totalmente construir sentencias como:
SELECT CH_C1, CH_C2, CH_C3
FROM SGT_TA_TABLA1 TABLA1, SGT_TA_TABLA2 TABLA2
WHERE 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 TABLA2
WHERE TABLA1. USUAC_C1 = TABLA2.USUAC_C2 AND
TABLA2.USUAD_C4 = GETDATE()
2.19.4 Convenciones para nombres de variables
Todos los nombres de variables debe escribirse en letras maysculas separando las
palabras con un underscore _, adems deben seguir el siguiente formato:
Tipo_de_variable_nombre_de_la_variable
Donde el tipo de variable es se define a continuacin:
Parmetro
:
K
Variable local o global:
V
Variable 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, pues

dificultan la lectura del cdigo, en casos donde sea conveniente el uso de
abreviaciones (Nombres muy largos o nombres usados intensamente), sas
abreviaciones deben estar incluidas el repositorio de estndares del proyecto.
Pagina: 15 / 20

Versin: 1.2
Noviembre 2014
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 Gestin de transacciones en Functions / StoreProcedures
Evitar que los nuevos StoreProcedure y Functions contengan COMMIT como parte de
la programacin, la gestin de las transacciones la debe gestionar la aplicacin que
hace uso de dichos objetos para asegurar la integridad de una transaccin que
involucre a varios objetos.
2.19.7 Particionamiento de tablas

Se sugiere la implementacin en mdulos con gran volumen de informacin de
particionamiento de tablas e ndices particionados implementando el tipo RANGE-LIST
compuesto, que asigna los registros de la tabla a diferentes particiones definidas segn el
rango de valores en una columna determinada o con una lista de valores. Con esto se
busca que el acceso a la informacin desde los distintos sistemas en tablas con gran
cantidad de registros, tenga una segmentacin lgica de la informacin permitiendo
optimizar el rendimiento de acceso a la informacin en los sistemas operacionales.
Entre los criterios para particionar una tabla e ndices se recomienda:
Tabla con un volumen de registros sobre 1 milln anual y de al menos 5 campos

incluyendo fechas
Particionamiento utilizando rangos de fechas acotados a un ao especifico, ej.

Nombretabla_particion2010 para los datos ingresados que contengan en la columna
que condiciona la particin con el valor del ao 2010, ya que los rangos que ocupan
sern solamente campos tipo date.
Si se desea dar obsolescencia a datos (pasar a histrico) se puede implementar una

columna de control donde se indica que el dato es obsoleto y pasa a ser parte de las
particiones con menos prioridad en las bsquedas. Esta es una caracterstica que
puede ser explotada en conjunto a rangos en motores Oracle 11g.
Pagina: 16 / 20

Versin: 1.2
Noviembre 2014
2.20 Buenas Prcticas 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 ms privilegios de lo que se
requieren.
Usar GLOBAL TEMPORARY TABLE para tablas temporales, no usar tablas fsicas.
Usar Tablas Temporales y/o la clusula 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 clusula WHERE.
Evitar innecesarios FULL TABLE SCAN en tablas grandes.
Evitar hacer algn calculo en una COLUMNA que tiene INDICE en el WHERE a menos
que exista una INDICE basado en Funcin para esta columna.
Crear tablas e ndices en diferentes Tablespaces.
Evitar usar excesivos INDICES, en lo posible reusar los que se tengan, muchos ndices
degradan la Insercin y actualizacin de informacin.
Usar Result Cache en PLSQL.
Usar NOCOPY Compiler Hint en PLSQL.
Crear los ndices apropiados y estrictamente necesarios.
Analizar Siempre los planes de ejecucin de las sentencias SQL/PLSQL.
Usar BULK COLLECT para las sentencias SELECT en consultas recursivas y masivas
(Bulk SQL.)
Usar FORALL para las sentencias DML en la actualizacin recursiva y masiva de Datos
(Bulk SQL).
Pagina: 17 / 20

Versin: 1.2
Noviembre 2014
Anidar una consulta para mejorar el rendimiento.
Evitar la conversin de tipos de Datos, seleccionar los tipos de datos con cuidado para
minimizar las conversiones implcitas. Como por ejemplo usar datos tipo carcter para
expresiones de cadena o Datos tipo decimales en expresiones numricas o de
clculos.
Dimensionar correctamente el tamao de los varchar2, es decir lo que realmente se

necesita 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 o

NUMBER.
Use COMPOUND TRIGGERS para insercin o actualizacin masiva.
Evitar la generacin de Producto Cartesiano.
Usar mayor (>) o menor (<) en vez de BETWEEN.
Evitar Comparar un Campo a Null en la clausula WHERE.
Usar Secuencias para la Generacin de nmeros correlativos o contadores, NO usar

tablas.
Para OLTP evitar el uso de Paralelismo, este es una caracterstica que se usa para
procesos BATCH y DWH.
Cerrar los Cursores usados siempre.
Evitar el uso de ROWNUM.
No conectarse directamente al ESQUEMA sino a travs de un usuario con privilegios

de acceso a los objetos del ESQUEMA.
Usar RefCursor Class para la recuperacin de los datos va cursores.
Usar Particionamiento para tablas Grandes (mayor a 1 Milln de Registros) y/o

Histricas para mejorar el tiempo de respuesta y facilitar la depuracin peridica.
Usar la sentencia Count con un Valor no con (*),

Ejemplo: Select Count(1)
Pagina: 18 / 20

Versin: 1.2
Noviembre 2014
2.21 Buenas Prcticas para DWH
Usar la funcionalidad de Paralelismo en forma adecuada.
Usar parallel para operaciones UNICAS y Pesadas (como agregaciones o batch) en

ningn caso para operaciones MASIVAS o concurrentes (Ej. detalle de llamadas).
Evitar ejecutar operaciones DML con Parallel mas de 8, si requieren de mas

paralelismo, validarlo con un DBA.
Evitar crear Tablas e ndices con Parallel, siempre Validar la creacin de objetos con el
DBA.
Usar el paralelismo a nivel de sesin no a nivel de objeto (tablas o ndices) como:

ALTER SESSION FORCE PARALLEL QUERY PARALLEL 8;
Para la Creacin 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 anlisis en lugar de Sentencias transaccionales para

procesamiento de grandes volmenes de informacin, como: MERGE, MODULE,
CUBE, RANK, etc.
Usar MERGE en vez de Cursores para procesos que demandan gran volumen de
Datos, evitando el uso de INDICES.
En lo posible Evitar la creacin de INDICES, Los INDICES en general son para

procesos OLTP (Recuperacin de pocos registros) no de Datawarehouse que requiere
procesar gran volumen de registros.
Para la creacin y carga de tablas con informacin reciente o vigente usar el tipo de
compresin FOR QUERY HIGH.
Para la creacin y Carga de tablas con informacin Histrica usar el tipo de compresin
FOR ARCHIVE HIGH.
Antes de ejecutar un DML evaluar su plan de ejecucin y optimizar al mximo dicho

plan, es decir que use eficientemente los recursos de la BD.
Evite el uso de PLSQL cuando el cdigo SQL puede ser mejor y mas rpido.
No USAR UTL_FILE para leer archivos planos en lugar de ello usar TABLAS
EXTERNAS.
Pagina: 19 / 20

Versin: 1.2
Noviembre 2014
Usar SQL MERGE en vez de PLSQL para comparar y procesar gran volumen de
registros.
Usar DBMS_ERRLOG para la gestin de errores de DML en vez de Cdigo PLSQL

(Excepciones).
Activar Calidad de Servicio (QoS) para asegurar los tiempos de respuesta adecuados y
el uso eficiente de los recursos de la Base de Datos.
Usar Particionamiento para mejorar el acceso a la Informacin.
Evitar el uso de UPDATE o DELETE para corregir informacin; es mejor eliminar las
particiones respectivas y volver a cargar la informacin.
Pagina: 20 / 20

Estandares de Desarrollo Base de Datos v1.2

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Estandares de Desarrollo Base de Datos v1.2

Încărcat de

Drepturi de autor:

Formate disponibile

ESTANDARES DE DESARROLLO EN BASE DE DATOS

Estndares de Desarrollo y Programacin sobre Base de Datos

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

ITEMS CONSIDERADOS PARA ESTANDARIZACION

Nomenclaturas de Base de Datos

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

BASE DE DATOS ORACLE

2.2 Nomenclatura de Esquemas

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

2.3 Nomenclatura de Tablespaces:

2.4 Nomenclatura de DataFile

DF_USR<MODULO>_ <CORRELATIVO POR DATAFILE>

2.5 Nomenclatura de tablas

AUDIT_USUARIO : Tabla de Usuario

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

2.6 Nomenclatura de Columnas

<Prefijo Tabla><Tipo Dato>_<Nombre Campo>

USUAV_NOMBRE varchar(50) : Nombre de Usuario

La longitud mxima del Nombre de Campo, en algn caso extremo,

2.7 Nomenclatura de Constraints

Primary Key PK_<TABLA>

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

2.8 Nomenclatura de ndices

IX_<Nombre TABLA>_<CORRELATIVO POR TABLA>

2.9 Nomenclatura de Vistas

2.10 Nomenclatura de Tipos De Datos

2.11 Nomenclatura de Reglas

2.12 Nomenclatura de Defaults

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

2.13 Nomenclatura de Package

Todo PAquete deber ser documentado con la siguiente estructura.

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

Todo Procedimiento Almacenado deber ser documentado con la siguiente estructura.

La longitud mxima del Nombre de la funcion, en algn caso

Toda Funcin deber ser documentado con la siguiente estructura.

La longitud mxima del Nombre del trigger, en algn caso extremo,

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

2.17 Nomenclatura de Secuencias

La longitud mxima del Nombre de una secuencia, en algn caso

Toda Secuencia deber ser documentada con la siguiente estructura.

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

Todo Sinnimo deber ser documentado con la siguiente estructura.

Es obligatorio el uso de un modelador de datos.

El uso de tipos de datos o dominios es obligatorio para estandarizar el tamao de los

La creacin de tablas, ndices, y constraints de tipo primary key deben referenciar al

La creacin de cualquier objeto (procedures, packages, functions, tablas, ndices, etc)

La creacin de cualquier objeto (procedures, packages, functions, tablas, ndices, etc)

Los privilegios de accesos (GRANTS) tambin deben ser considerados.

Los sinnimos deben ser privados.

AMERICA MOVIL PERU SAC

Estndares de Desarrollo y Programacin sobre Base de Datos

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

2.19.2 Codificacin para mejorar la performance

Cuando se codifiquen transacciones grandes se debe usar savepoints (SAVE TRAN)

2.19.3 Convenciones generales de codificacin