Estandares PDF

Tabla de Contenido
Page 1 of 18
Tabla de Contenido
"BANCO CENTRAL DE HONDURAS"
"Departamento de Informatica y Tecnologa"
"Divisin de Operaciones y Servicios , rea de Administracin de Operaciones, Administracin de Base de Datos"
1 Nomenclatura
1.1 Bases de Datos Ver Detalles
1.1.A Tablas Ver Detalles
1.1.B ndices Ver Detalles
1.1.C Campos de Tablas Ver Detalles
1.1.D Procedimientos Almacenados Ver Detalles
1.1.E Vistas Ver Detalles
1.1.F Vistas Materializadas en Oracle Ver Detalles
1.1.G Triggers Desencadenadores Ver Detalles
1.1.H Paquetes Ver Detalles
1.1.I Funciones Ver Detalles
1.1.J Trabajos Automatizados (JOBS) Ver Detalles
1.1.K Polticas de Auditora en Oracle Ver Detalles
1.1.K.1 Creacin y Configuracin de Poltica Ver Detalles
1.1.K.2 Deshabilitar Poltica Ver Detalles
1.1.K.3 Habilitar Poltica Ver Detalles
1.1.K.4 Eliminar Poltica Ver Detalles
2 Polticas
2.I Respecto a la redundancia de Informacin Ver Detalles
2.2 Respecto a los Respaldos de las Bases de Datos Ver Detalles
2.3 Respecto al manejo del Log de Transacciones en una Base de Datos Ver Detalles
2.4 Respecto a la resolucin de Relaciones 1: N entre Tablas Ver Detalles
2.5 Respecto a las reglas de Normalizacin Ver Detalles
2.6 Respecto a la Integridad y Consistencia de la Informacin Ver Detalles
2.7 Respecto a los permisos de usuario Ver Detalles
2.8 Respecto al Diccionario de Datos Ver Detalles
3 Registro de Movimientos Histricos Ver Detalles
3.1 Tabla del Encabezado del Histrico (HstEnc...) Ver Detalles
3.2 Tabla del Detalle del Histrico (HstDet...) Ver Detalles
4 Convenciones Ver Detalles
5 Glosario Ver Detalles
Bibliografa Ver Detalles
A cerca de ... Ver Detalles
1.1 Bases de Datos

Volver a Tabla de Contenido
El nombre de toda Base de Datos estar conformado primeramente por el prefijo de dos letras BD (Correspondiente a las Iniciales de Base de Datos), posteriormente se
colocar un nombre formado por una o mas palabras de tal manera que dicho nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera
comprensible el nombre del Sistema de Informacin que har uso de la Base de Datos.
Ejemplo:
La Base de Datos de Balanza debe ser nombrada como: BDBalanza, Otro ejemplo, la Base de Datos del Sistema de Gestin Administrativa puede ser nombrada como:
BDGestionAdmin, debe observarse que en este caso se est utilizando un nombre de base de datos compuesta por dos palabras que identifican de manera especfica el
nombre de la aplicacin a la que pertenece dicha base de datos.
Adems se debe cumplir con lo siguiente:
El prefijo BD siempre estar escrito en letra mayscula.
Nunca se utilizarn espacios en blanco en el nombre que se le dara a la base de datos ni entre el prefijo y este nombre.
El nombre de la base de datos preferiblemente debe estar compuesto slo de letras, en caso de ser necesario se podran utilizar nmeros al final del nombre.
El nmero mximo de caracteres utilizado para crear el nombre de una base de datos incluyendo el prefijo ser de 20.
La o las palabras que sirven para formar el nombre de la base de datos y que van a continuacin del prefijo BD deben empezar siempre con la primera letra de cada
palabra en mayscula. (Ver Nombre de base de datos en los Ejemplos citados en esta seccin).
1.1.A Tablas
El nombre de toda Tabla estar conformado primeramente por el prefijo de tres letras Tbl (Convencin de Nomenclatura Leszynski (Leszynski Naming Conventions
(LNC))) para indicar que se trata de una tabla dentro de la Base de Datos, posteriormente se colocar un nombre formado por una o mas palabras de tal manera que dicho
nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera comprensible el nombre nico de la entidad o tabla dentro de la Base de Datos.
Ejemplo: Para la tabla entidad de Empleados se utilizar la nomenclatura siguiente: TblEmpleados, que significa Tabla de Empleados.
Otro ejemplo: En el caso de emplear una entidad catlogo con nombres compuestos como describir la tabla de centro de costos, se utilizar la nomenclatura
siguiente:TblCentroCosto que significa Tabla de Centro de Costo.
Para nombrar las tablas que sean producto de la relacin entre dos entidades de la base de datos se colocarn adems del prefijo Tbl los nombres de las tablas que la
forman, es decir cada uno indicar el nombre de las entidades relacionadas; por ejemplo si se tiene una relacin entre las entidades Empleados y Salario en una base de
datos la tabla correspondiente deber ser nombrada: TblEmpleadosSalarios.
file:///C:/Users/le107059/AppData/Local/Temp/~hhA16E.htm
22/08/2016
Tabla de Contenido
Page 2 of 18
Nunca se utilizarn espacios en blanco en el nombre que se le dara a la tabla ni entre el prefijo y este nombre.
Siempre la primera letra del prefijo Tbl estar escrita en letra mayscula.
El nombre de las tablas deben estar compuesto slo de letras, en caso de ser necesario se podran utilizar nmeros al final del nombre.
El nmero mximo de caracteres utilizado para crear el nombre de una tabla incluyendo el prefijo ser de 30.
La o las palabras que sirven para formar el nombre de la tabla y que van a continuacin del prefijo Tbl deben empezar siempre con la primera letra de cada palabra en
mayscula. (Ver Nombre de tablas en los Ejemplos citados en esta seccin)
1.1.B ndices
El nombre de todo ndice creado por el usuario estar conformado primeramente por el prefijo de dos letras y un nmero Inj para todo j =1,2,...m segn los m ndices que
se creen en una tabla en particular.Posteriormente se colocar el nombre de la tabla a la cual pertenece o en la que fue creado, omitiendo el prefijo Tbl del nombre de
dicha tabla.
Ejemplo: Para nombrar un primer ndice creado en la tabla TblEmpleados se utilizar la nomenclatura siguiente: In1Empleados, que significa que es el primer ndice
creado por el usuario en la Tabla de Empleados.
Otro Ejemplo: Si la tabla es una relacin entre dos entidades se colocar siempre el nombre de la tabla que representa las entidades relacionadas, para nombrar un
ndice de la tabla TblEmpleadosSueldos se utilizar la nomenclatura siguiente: In1EmpleadosSueldos.
Para el caso en que se tenga ms de un ndice, el prefijo ser In1, In2, y as sucesivamente segn el nmero de ndices que se creen, por ejemplo si se tienen dos ndices
en la tabla TblEmpleados.uno para las columna correspondientes a el nmero de empleado y fecha de ingreso al Banco y otro para la columna correspondiente a el
departamento al cual pertenece los dos ndices sern nombrados con la nomenclatura siguiente:: In1Empleados y el otro como In2Empleados.
Nunca se utilizarn espacios en blanco en el nombre que se le dara al indice ni entre el prefijo y este nombre.
Siempre la primera letra del prefijo Inj estar escrita en letra mayscula.
El prefijo del nombre de todo ndice siempre estar compuesto de dos primeras letras y por ltimo un nmero correlativo correspondiente al nmero de ndices que se
creen en cada tabla.
El nmero mximo de caracteres utilizado para crear el nombre del indice esta sujeto al numero utilizado en el nombre de la tabla al que pertenece.
La o las palabras que sirven para formar el nombre del ndice y que van a continuacin del prefijo Inj deben empezar siempre con la primera letra de cada palabra en
mayscula. (Ver Nombre de ndices en los Ejemplos citados en esta seccin)
1.1.C Campos de Tablas

El nombre de todo Campo que est representando una clave, sea sta clave primaria o fornea en una tabla en particular; debe estar conformado primeramente por el
prefijo de tres letras Cve, posteriormente este tipo de campos especiales y tambin el resto de campos que constituyen dicha tabla se les colocar un nombre aplicando el
Estndar de Nomenclatura de Atributos GIK (GeneXus Incremental Knowledge Base) que consiste en lo siguiente:
Nombre de Atributo = Objeto + Categora + Calificador + Complemento
Objeto: Es el nombre de la tabla a la que pertenece el atributo, y si es campo clave llevar el prefijo Cve. (1 a 7Caracteres)
Categora: Es la categora semntica del atributo. (1 a 6Caracteres)
Calificador: Puede existir uno o dos calificadores (1 a 6Caracteres)
Complemento: Texto libre (1 a 6Caracteres)
La utilizacin del Estndar de Nomenclatura de Atributos GIK nos facilita l poder compartir y reutilizar el conocimiento, uno de los problemas con los que nos
encontramos a la hora de compartir conocimiento es que cada programador sigue sus propios criterios para nombrar atributos.
Por otro lado utilizar el cdigo GeneXus siguiendo la nomenclatura estndar de atributos GIK enfatiza la comunicacin a travs del cdigo, tambin favorece el
entendimiento por otro programador y facilita el mantenimiento del mismo.
Ejemplo Bsico de Nomenclatura GIK,
Nombre Tabla: TblEmpleados
Objetos CategorasCalificadorComplemento
CveEmp
Cod
Emp
Nom
Emp
Fch
Ini
Emp
Fch
Fin
Emp
Fch
Ing
Banco
Otro Ejemplo:
22/08/2016
Tabla de Contenido
Page 3 of 18
Basndonos en esta nomenclatura vamos a definir un ejemplo de la Tabla de Clientes ms ampliamente y de manera prctica.
Nombre Tabla: TblCliente
Nombre de Campos
CveClienteCodigo
ClienteNombre
ClienteApellidos
ClienteFechaNac
ClienteTelefono
ClienteTelOficina
Ejemplos:
Descripcin de los Campos

Cdigo de Cliente
Nombre de Cliente
Apellidos de Cliente
Fecha Nacimiento de Cliente
Telfono de Cliente
Telfono de Cliente en la Oficina
CveAlumnoCodigo (Campo clave de la tabla alumno), CveAlumnosMateriaCod (Campo clave de la tabla de la relacin Alumno-Materia) o CveAlumMatCod (Campo
clave de la tabla de la relacin Alumno-Materia).
Si existe una llave compuesta por tres campos de la tabla entidad alumno debern ser nombrados de la siguiente manera: CveAlumnoCodigo, CveAlumnoIdentidad,
CveAlumnoCarrrera.
Para nombrar el campo clave en la tabla del centro de costos, se utilizar la nomenclatura siguiente: CveCentroCostoCodigo o CveCenCosCodigo para esta.
En el caso de nombrar el nombre del centro de costos dentro de esta tabla, se utilizar la nomenclatura siguiente: CentroCostoNombre o CenCosNom para este.
En ocasiones es necesario dividir la direccin en calle y nmero, colonia, cdigo postal y localidad de un empleado; de manera que la nomenclatura para estos campos
ser respectivamente en la tabla de empleados (TblEmpleados) ser: EmpleadosCallle, EmpleadosColonia, EmpleadosCodPostal y EmpleadosLocalidad.
Nunca se utilizarn espacios en blanco en el nombre que se le dara al Campo ni entre el prefijo si se utiliza y este nombre.
Siempre la primera letra del prefijo Cve cuando se utilice en campos claves estar escrita en letra mayscula.
El nombre de los Campos deben estar compuesto slo de letras, en caso de ser necesario se podran utilizar nmeros al final del nombre.
El nmero mximo de caracteres utilizado para crear el nombre de un campo incluyendo el prefijo ser de 30.
En caso de que la llave primaria este compuesta por diversos campos dentro de la tabla, cada uno de estos debern ser nombrados con el prefijo Cve inicialmente.
La o las palabras que sirven para formar el nombre del campo y que van a continuacin del prefijo Cve deben empezar siempre con la primera letra de cada palabra en
mayscula. (Ver Nombre de campos en los Ejemplos citados en esta seccin)
Volver al Inicio de Pgina
1.1.D Procedimientos Almacenados

El nombre de todo Procedimiento Almacenado creado por el usuario estar conformado primeramente por el prefijo de dos letras PA (Correspondiente a las Iniciales de
Procedimiento Almacenado); posteriormente se colocar un nombre formado por una o mas palabras de tal manera que dicho nombre sea lo suficientemente descriptivo y
lgico, permitiendo describir de manera comprensible el nombre del proceso o procedimiento automatizado que realizar a travs de dicho procedimiento almacenado en el
sistema de informacin sobre el cual se est trabajando.
Ejemplo:
Para nombrar un procedimiento que realiza la carga inicial de datos de un modulo de seguridad de determinada aplicacin se utilizar la nomenclatura siguiente:
PACargaDatosSeguridad.
Otro Ejemplo:
Para nombrar un procedimiento que realiza el proceso de fin de dia de la compensacin electrnica en un banco comercial se utilizar la nomenclatura siguiente:
PAFinDia.
El prefijo PA siempre estar escrito en letra mayscula.
Nunca se utilizarn espacios en blanco en el nombre que se le dara al procedimiento almacenado ni entre el prefijo y este nombre.
El nombre de los procedimientos almacenados deben estar compuesto slo de letras, en caso de ser necesario se podran utilizar nmeros al final del nombre.
El nmero mximo de caracteres utilizado para crear el nombre de un procedimiento almacenado incluyendo el prefijo ser de 30.
La o las palabras que sirven para formar el nombre del procedimiento almacenado y que van a continuacin del prefijo PA deben empezar siempre con la primera letra
de cada palabra en mayscula. (Ver Nombre de procedimiento almacenado en los Ejemplos citados en esta seccin).
1.1.E Vistas
El nombre de toda Vista creada por el usuario estar conformada primeramente por el prefijo de tres letras Vis; posteriormente se colocar un nombre formado por una o
mas palabras de tal manera que dicho nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera comprensible la consulta almacenada que se
22/08/2016
Tabla de Contenido
Page 4 of 18
estar representado con dicha vista.
Ejemplo: Para nombrar una vista para la consulta de la informacin de un libro en particular tomando como partida de consulta el ttulo del Libro en una Base de Datos de
una Biblioteca, se utilizar la nomenclatura siguiente: VisTtuloLibro.
Nunca se utilizarn espacios en blanco en el nombre que se le dara a la vista ni entre el prefijo y este nombre.
El nombre de las vistas deben estar compuestos slo de letras, en caso de ser necesario se podran utilizar nmeros al final del nombre.
El nmero mximo de caracteres utilizado para crear el nombre de una vista incluyendo el prefijo ser de 30.
La o las palabras que sirven para formar el nombre de la vista y que van a continuacin del prefijo Vis deben empezar siempre con la primera letra de cada palabra en
mayscula. (Ver Nombre de vista en el Ejemplo citado en esta seccin).
1.1.F Vistas Materializadas en Oracle

El nombre de toda Vista Materializada creada por el usuario estar conformada primeramente por el prefijo de dos (2) letras VM; posteriormente se colocar un nombre
formado por una o mas palabras de tal manera que dicho nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera comprensible la consulta
almacenada que se estar representado con dicha vista materializada.
Ejemplo: Para nombrar una vista materializada para la consulta de la informacin de solicitudes en el SASI tomando como partida de consulta el rea de Soporte al
Cliente en la Base de Datos de dicho Sistema, se utilizar la nomenclatura siguiente: VMSolicitudesSoporte.
Detalle de Configuracin de las Vistas Materializadas:
General:
Consulta de Vista Materializada; es aqui donde se deber definir el conjunto de Comandos SQL que formarn la Vista Materializada., en caso de utilizar JOIN, estos
deberan ser diseados con el formato genrico de Oracle (Manejo de Alias) Ejemplo:
Ejemplo de Sintaxis:
create materialized view "usrsasi"."VMSolicitudesSoporte" using index refresh force on commit as

select
s.cvesolicitudcodigo,s.cvesolicitudanexocodigo,s.cveserviciocodigo,s.cveprioridadcodigo,s.cveestadosolicitudcodigo,s.solicitudporcentajeavance,
s.solicitudautorizada, s.solicitudfecharecepcion,s.cveareadeserviciocodigo, s.solicitudempresponsable,
e.servicionombre,e.cvetiposerviciocodigo, v.areadeserviciodescripcion, d.estadosolicituddescripcion, (p.empleadonombre || ' ' ||
p.empleadoapellido) as Empleadoresponsable
from tblsolicitud s, tblservicio e, tblempleado p, tblestadosolicitud d, tblareadeservicio v
where
e.cveserviciocodigo = s.cveserviciocodigo and p.cveempleadocodigo = s.solicitudempresponsable andd.cveestadosolicitudcodigo =
s.cveestadosolicitudcodigo and v.cveareadeserviciocodigo = s.cveareadeserviciocodigo and substr(s.cveareadeserviciocodigo, 9,2)= 14 begin
dbms_stats.gather_table_stats(ownname =>'usrsasi', tabname => 'vmsolicitudessoporte2'); end
Refrescamiento de Datos:
1. Rellenar automaticamente cuando estas se crean, opcin que debe ser configurada.
2. Tipo de Refrescamiento
De las tres opciones posibles (Force, Fast, Complete) se deber configurar la opcin: "Force" (Refrescamiento incremental si es posible o completo si el
incremental no es posible).
3. Mtodo de Refrescamiento
De las dos opciones (Clave Primaria, Identificador de Fila) se deber configurar la opcin: "Clave Primaria".
4. Intervalo de Refrescamiento
De las cuatro opciones posibles (A Peticin (Manualmente), En cada confirmacin (Commit), Automticamente endespus refrescar(Establecimiento de Fecha y
Repeticin por dia, hora, minuto, segundo), Nunca) se deber configurar la opcin: "En cada confirmacin (Commit)".
5. Segmento de Rollback
Configurarlo por Defecto
1.1.G Triggers Desencadenadores

El nombre de todo Trigger's o Desencadenador creado por el usuario estar conformado primeramente por el prefijo de tres letras Tri; posteriormente se colocar un
nombre formado por una o mas palabras de tal manera que dicho nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera comprensible la
accin que se ejecutar en los sistemas de informacin con el que se trabaja en respuesta a las instrucciones SQL (INSERT, UPDATE y DELETE) que se ejecutarn a
travs de la activacin de dicho Trigger ya que este es prcticamente un procedimiento almacenado solo que su ejecucin est en funcin de ciertas condiciones que
deben cumplirse a traves de intrucciones SQL.
22/08/2016
Tabla de Contenido
Page 5 of 18
Ejemplo:
Para nombrar un trigger que se utilizara como disparador en un sistema de control de acceso, el cual se activa al existir una inserccin de datos del cdigo del carnet de un
empleado en un campo en particular y que realiza un proceso o procedimiento de actualizacin de datos en una tabla en particular de dicho sistema, se utilizar la
nomenclatura siguiente: TriControl AccesoEmpleado.
Nunca se utilizarn espacios en blanco en el nombre que se le dara al trigger ni entre el prefijo y este nombre.
El nombre del trigger debe estar compuesto slo de letras, en caso de ser necesario se podran utilizar nmeros al final del nombre.
El nmero mximo de caracteres utilizado para crear el nombre de un trigger incluyendo el prefijo ser de 30.
La o las palabras que sirven para formar el nombre del Trigger y que van a continuacin del prefijo deben empezar siempre con la primera letra de cada palabra en
mayscula. (Ver Nombre de Trigger en el Ejemplo citado en esta seccin).
1.1.H Paquetes
Pre
viou

El nombre de todo Paquete (Package) creado por el usuario estar conformada primeramente por el prefijo de tres(3) letras Paq; posteriormente se colocar un nombre
formado por una o mas palabras de tal manera que dicho nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera comprensible el objeto de
creacin y uso del mismo.
Ejemplo: Para nombrar un paquete que permite realizar las operaciones DML para el monitoro de las solicitudes de servicios en el SASI, se utilizar la nomenclatura
siguiente: PaqMonitoreo.
Notas sobre los paquetes: se recomienda que las primeras tres caracteres deben ser PAQ en maysculas, seguido el nombre completo del sistema si no excede de 24
caracteres incluidas las primeras tres letras.
Ejemplo: PAQNombreSistemaCompleto (cantidad de caracteres 24).
1.1.I Funciones

El nombre de toda Funcin creada por el usuario estar conformada primeramente por el prefijo de tres(3) letras Fun; posteriormente se colocar un nombre formado por
una o mas palabras de tal manera que dicho nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera comprensible el objeto de la creacin y
uso de la misma.( los ejemplos aplican en Oracle como en SqlServer)
Ejemplo: Para nombrar una funcin que se utiliza para saber si una solicitud junto con sus anexos se puede dar por terminada en el SASI, se utilizar la nomenclatura
siguiente: FunSolicitudAtendida.
Notas sobre Funciones: Se recomienda que los primeros tres caracteres puedan ser FU_ en maysculas, seguido el nombre completo de la tabla con la que tendr
interaccin la funcin y por ultimo las letras GET.
Ejemplo:
Tabla: tblEstado
Funcin: FU_EstadoGET
Nota sobre los Procedimientos: Se recomienda que los primeros tres caracteres deben ser PA_ en maysculas, seguido el nombre completo de la tabla con la que tendr
interaccin el procedimiento y por ultimo las letras:
INS (cuando el objetivo principal es agregar informacin).

DEL (cuando el objetivo principal es borrar datos).
UPD (cuando el objetivo principal es actualizar datos).
Ejemplo:
Tabla: tblEstado
Procedimiento: PA_EstadoINS , PA_EstadoDEL , PA_EstadoUPD.
1.1.J Trabajos Automatizados (JOBS)

El nombre de todo Trabajo Automatizado (JOBS) creado por el usuario estar conformada primeramente por el prefijo de dos(2) letras TA (Correspondiente a las
Iniciales de Trabajos Automatizados); posteriormente se colocar un nombre formado por una o mas palabras de tal manera que dicho nombre sea lo suficientemente
descriptivo y lgico, permitiendo describir de manera comprensible el objeto de la creacin y uso del mismo.
22/08/2016
Tabla de Contenido
Page 6 of 18
Ejemplo: Para nombrar un Trabajo Automatizado que se utiliza para monitorear automticamente solicitudes prioritarias en el SASI, se utilizar la nomenclatura siguiente:
TAMonitorearPrioritarias.
1.1.K Polticas de Auditora en Oracle

El nombre de toda Poltica de Auditora para el ambiente Oracle creada por el usuario estar conformada primeramente por el prefijo de cuatro(4) letras audi;
posteriormente se colocar un nombre formado por una o mas palabras (preferiblemente relacionado al nombre del objeto a auditar (tabla o vista) de tal manera que dicho
nombre sea lo suficientemente descriptivo y lgico, permitiendo describir de manera comprensible el objeto de la creacin y uso de la misma.
Ejemplo: Para nombrar una poltica de auditora para el ambiente de Oracle que se utiliza para auditar por comandos INSERT,UPDATE,DELETE en la tabla tbltiposervicio
en el SASI, se utilizar la nomenclatura siguiente: auditiposervicio.
#1
begin
dbms_fga.add_policy (
object_schema => 'usrsasi'
,object_name => 'tbltiposervicio'
,policy_name => 'auditiposervicio'
,audit_condition => NULL
,audit_column => 'CVETIPOSERVICIOCODIGO,TIPOSERVICIODESCRIPCION'
,handler_schema => NULL
,handler_module => NULL
,enable => TRUE
,statement_types =>'INSERT,UPDATE,DELETE'
);
end;
1.1.K.1 Creacin y Configuracin de Poltica

A travs de la siguiente ejemplificacin, se muestra la estructura de creacin y configuracin de una poltica de auditoria en Oracle, mediante la utilizacin del paquete
DBMS_FGA
Cuando se crea una poltica en su sintaxis se utiliza el comando "add_policy" posteriormente despus de la definicin del paquete "dbms_fga"
Tabla a Auditar: tbltiposervicio
Sintaxis
begin
object_schema =>'usrsasi'
,object_name =>'tbltiposervicio'
,policy_name =>'auditbltiposervicio' -- (Nombre de la Poltica)
,enable => TRUE
);
end;
Explicacin:
En esta ejemplificacin se auditan todos los campos (debido a que el parmetro "audit_column =>" no esta definido) de la tabla tbltiposervicio cuando sean ejecutados
los comandos DML (Insert, Update, Delete); en otros ejemplos se indicaran campos en particular a auditar. Adems en este caso en particular no importa el usuario que
ejecute dichos comandos, lgicamente solo podrn realizar dicha ejecucin aquellos usuarios que tienen privilegios sobre el esquema usrsasi dueo del objeto.
Otros ejemplos:
#1
begin
object_schema => 'usrsasi'
,object_name => 'tbltiposervicio'
,policy_name => 'auditiposervicio'
,audit_column => 'CVETIPOSERVICIOCODIGO,TIPOSERVICIODESCRIPCION'
,enable => TRUE
);
end;
En este caso se especifican, campos en particular que se desean auditar.
22/08/2016
Tabla de Contenido
Page 7 of 18
#2
begin
object_schema => 'usrsasi',
object_name => 'tblparametros',
policy_name => 'audiparametros'
);
end;
En este caso si no se especifica el parmetro "statement_types =>" Audita nicamente la Sentencia DML Select, en todas las columnas de la tabla tblparametros, adems
sin condiciones.
#3
begin
object_schema=>'BANK',
object_name=>'ACCOUNTS',
policy_name=>'ACCOUNTS_ACCESS',
audit_column => 'BALANCE',
audit_condition => 'BALANCE >= 11000' );
end;
En este caso en particular, la poltica se crea con condiciones especificas que deben cumplirse en un campo en particular, para auditar la sentencia DML Select
nicamente.
#4
begin
dbms_fga.add_policy(
object_schema=>'UWCLASS',
object_name=> 'FGA_DEMO',
policy_name=> 'UW Audit',
audit_condition=> 'status = ''A''',
audit_column=> 'last_name, salary',
handler_schema => 'UWCLASS',
handler_module=> 'FGA_HANDLER',
enable => TRUE,
statement_types => 'INSERT, UPDATE');
end;
En este caso en particular, solo se desean auditar ciertas columnas, y especficamente solo cuando se ejecuten comandos DML Insert y Update, siempre y cuando se
cumpla la condicin definida en el parmetro "audit_condition=>"
Tambin se pueden colocar varias condiciones a la vez.
Ejemplo:
audit_condition=>'CLAIM_AMOUNT>500 OR PAID_AMOUNT>500'
#5
begin
policy_name => 'audiparametros',
audit_column => 'cveparametrofechaparametroprioridadmaxima,parametroprioridadminima,
parametrohorariohorainicio,parametrohorariohorafinal,parametrotamanomaximoarchivo,
cvedependenciacodigo,parametrocorreo,parametroadministrador',
handler_schema => 'secure',
handler_module => 'log_parametros',
enable => TRUE,
statement_types => 'insert,update,delete');
end;
Poltica auditando diversos Campos en particular, adems audita nicamente los comandos DML (INSERT, UPDATE, DELETE)
#6
begin
enable => TRUE,
statement_types => 'insert,update,delete');
end;
Poltica auditando todos los campos de una tabla (omitiendo el audit_column), adems audita nicamente los comandos DML (INSERT, UPDATE, DELETE)
#7
begin
22/08/2016
Tabla de Contenido
end;
Page 8 of 18
audit_column => 'cveparametrofecha',

enable => TRUE,
statement_types => 'select,insert,update,delete');
Poltica auditando un solo campo en particular, adems audita cualquier comando DML (SELECT, INSERT, UPDATE, DELETE)
1.1.K.2 Deshabilitar Poltica
Volver al Incio de Pgina

Para deshabilitar una poltica ya existente, solo basta conocer el esquema, el objeto y el nombre de la poltica, he ah la importancia de que los nombres de estas estn
estandarizados.
Cuando se deshabilita una poltica en su sintaxis se utiliza el comando "enable_policy" posteriormente despus de la definicin del paquete "dbms_fga"
Y por ltimo el parmetro que se debe modificar es: "enable =>" este debe quedar definido como: "FALSE", restando nicamente la ejecucin de las instrucciones
respectivas segn la sintaxis descrita en el ejemplo mostrado en esta seccin.
Sintaxis
begin
dbms_fga.enable_policy (
object_name => 'tbltiposervicio',
policy_name => 'auditiposervicio',
enable => FALSE
);
end;
Porque Deshabilitar una poltica?:
Por instrucciones por escrito de los usuarios dueos del sistema, con visto bueno del Departamento de Auditoria Interna.
Cuando sea requerido realizar una carga masiva de datos de manera controlada, siempre con visto bueno del Departamento de Auditoria Interna.
Cuando sea necesario para darle mantenimiento a la Base de Datos, con notificacin al Departamento de Auditoria Interna.
1.1.K.3 Habilitar Poltica

Para Habilitar una poltica ya existente, solo basta conocer el esquema, el objeto y el nombre de la poltica, he ah la importancia de que los nombres de estas estn
estandarizados.
Cuando se Habilita una poltica en su sintaxis se utiliza el comando "enable_policy" posteriormente despus de la definicin del paquete "dbms_fga"
Y por ltimo el parmetro que se debe modificar es: "enable =>" este debe quedar definido como: "TRUE", restando nicamente la ejecucin de las instrucciones
respectivas segn la sintaxis descrita en el ejemplo mostrado en esta seccin.
Sintaxis
begin
dbms_fga.enable_policy (
policy_name => 'auditiposervicio',
enable => TRUE
);
end;
1.1.K.4 Eliminar Poltica

De igual manera para Eliminar una poltica ya existente, solo basta conocer el esquema, el objeto y el nombre de la poltica, he ah la importancia de que los nombres de
estas estn estandarizados.
22/08/2016
Tabla de Contenido
Page 9 of 18
Cuando se desea eliminar una poltica en su sintaxis se utiliza el comando "drop_policy" posteriormente despus de la definicin del paquete "dbms_fga"
Restando nicamente la ejecucin de las instrucciones respectivas segn la sintaxis descrita en el ejemplo mostrado en esta seccin.
Sintaxis
begin
dbms_fga.drop_policy (
policy_name => 'auditiposervicio'
);
end;
1.1 Bases de Datos
Pre
viou

Los nombres de las Bases de Datos de aplicaciones que derivan un producto final no desarrollado por BCH o aplicaciones de terceros , no deben cumplir con el estandar
de Base de Datos sealado en el numeral 1.1 Bases de Datos ya que estos ya manejan su propia metodologia y standard de bases de datos producto de su instalacion
generica y para su correcto funcionamiento , cabe mencionar que si en la implementacion/instalacion de dichos productos es posible modificar el nombre de la base de
datos esto debe ser realizado cumpliendo con lo sealado en el numeral 1.1 Bases de Datos.
2.2 Bases de Datos
Pre
viou

Las conexiones desde un aplicativo no desarrollado en BCH hacia otra bases de datos diseada e implementada en BCH , debe cumplir los siguientes requisitos para conexin segn el
tipo de manejador de Bases de Datos :
1.
2.
Oracle : Generacin de cadena de conexin para conectarse a Oracle de la siguiente manera :

SID : Ejemplo de conexin a un esquema ( Usrpuentesigef)
Service Name : Ejemplo de conexin a un esquema (usrpuentesigef) , para estos casos se debe configurar el archivo tnsnames.ora
Otros : Odbc , jdbc ,gateways , DataBase links
SQLSERVER : Generacin de Cadena de conexin hacia la base para conectarse a MS Sqlserver de la siguiente manera.
Conexin via active directory service ( grupo de ads)
ODBC
Otros : Database links
** No se esta permitido la activacion del usuario de administracion sql sa , lo ideal es que las conexiones deben hacer via Directorio Activo o en su defecto con usuarios
propietarios de SQLSERVER si el caso lo amerita.
1.1 Bases de Datos
Pre
viou

El procedimiento de llamado de objetos hacia una base de datos desde una aplicacion no desarrollada por BCH y dependiendo del manejador de Bases de Datos debe
realizarse de la sigueinte forma:
1.
Oracle :
Llamado de un procedimiento almacenado desde un Paquete PL/SQL (Procedure)
BEGIN
USRPUENTESIGEF.PAQPROCESOS.PATRASLADAHISTVENTANILLA(Parametros);
END;
Llamado de una funcin desde un paquete PL/SQL (Function)
BEGIN
EXEC USRPUENTESIGEF.PATRASLADAHISTVENTANILLA(Parametros);
END;
2. MS-SQLSERVER:
Llamado de un procedimiento almacenado de bases de datos (Procedure)
EXECUTE bdDatosPublicos.dbo.PA_INSTABLA(parametros);
Llamado de una funcin de base de datos (Function)
EXECUTE bdDatosPublicos.dbo.FU_GETTABLA(parametros);
22/08/2016
Tabla de Contenido
Page 10 of 18
3.I Respecto a la redundancia de Informacin
Pre
viou

Es de suma importancia aclarar que el manejo de la redundancia es una operacin delicada y debe evitarse al mximo para asegurar la integridad y consistencia de los
datos y su uso slo ser aplicable en aquellos sistemas de informacin que as lo exijan.
Existen casos donde cierta informacin debe almacenarse en una tabla de la Base de Datos en forma repetitiva por cuestiones de los requerimientos del sistema o bien
con el propsito de agilizar las transacciones en las Bases de Datos.
Por ejemplo
En un Sistema de Gestin para una Empresa Mercantil Pequea se manejan datos concernientes a las ventas y compras de insumos, lo cual representa realizar una
facturacin de dichos insumos, esta informacin referente a los detalles de venta o de compra es de inters para la empresa, ya que con ella se efecta un control eficiente
de las operaciones de compra-venta realizadas.
La informacin de cada detalle de venta o de compra es almacenada en dos tablas una donde se tiene el historial de todas las ventas realizadas y en la otra el historial de
compras.
En cada una de estas tablas se tienen registros casi idnticos cuyo nico distintivo puede ser una clave o nmero de folio, representando as una clase de redundancia en
la informacin que es la nica manera de registrar cambios en los datos de esta tabla.
3.2 Respecto a los Respaldos de las Bases de Datos
Pre
viou

Todas las bases de datos debern ser respaldadas al final del da operativo de los sistemas de informacin todos los das de las semanas con el fin de evitar prdidas no
deseadas de la informacin contenida en ellas (Responsabiliad del DBA).
Se recomienda consultar la documentacin concerniente a "Proceso Respaldo y Recuperacin de Base de Datos Servidores Principales, Servidores Satlites y
Microcomputadoras" para llevar a cabo esta tarea.
3.3 Respecto al manejo del Log de Transacciones en una Base de Datos
Pre
viou

Se manejarn archivos Log y Redo Log en aquellas Bases de Datos administradas por MS-SQL Server y ORACLE con el propsito de llevar un registro estadstico de
todas las operaciones efectuadas en cada una de las tablas de esa Base (transacciones).
Debido a que MS-SQL Server asigna un cierto espacio en disco para los archivos Log que manejan las transacciones, se recomienda realizar un proceso de depuracin
del espacio asignado a estos archivos diariamente, tal trabajo debe realizarse inmediatamente despus de realizado el proceso de Respaldo de las Bases de Datos
incluidos los log's, de esta manera se mantendr almacenados los Log diariamente pero no log's acumulativos, esta estrategia se aplica con la finalidad de evitar fallas por
falta de recurso de almacenamiento en el servidor, ya que los archivos fsicos de los Log's tienden a crecer en tamao, de forma muy acelerada dependiendo del
movimiento de transacciones en las Bases de Datos.
En el caso de ORACLE que utiliza los Redo Log Files son archivos fsicos que almacenan el registro de todos los cambios hechos a la base de datos, son utilizados
principalmente para procesos de recuperacin y almacena la informacin proveniente de los Redo Log Buffers. Los Redo Log Buffers registran secuencialmente todos los
cambios hechos a los datos (sentencias DML, commits, rollbacks), se deber considerar de igual manera a las observaciones estipuladas en el prrafo anterior.
2.4 Respecto a la resolucin de Relaciones 1: N entre Tablas

Cuando se realiza el diseo de una Base de Datos siempre se presentan relaciones N: N (muchos a muchos) entre dos tablas, las cuales se resuelven descomponindolas
en dos relaciones 1: N (uno a muchos) al colocar una tabla entidad de interseccin entre ellas; sin embargo la aparicin de relaciones 1: N exige establecer ciertas
polticas respecto a la forma de implementarlas, siendo las siguientes:
1. Llamaremos tabla maestra a aquella tabla que "est del lado 1" en la relacin 1: N, es decir aquella que apunta a ms de un registro en la tabla del lado N de la relacin
y por lo tanto debe ser nico.
2. Llamaremos tabla detalle a la tabla del lado N en la relacin 1: N, donde cada uno de sus registros corresponde a uno y slo un registro en la tabla maestra.
3. Se colocar un campo comn tanto en la tabla maestro como en la tabla detalle que por lo general ser una clave, la cual nos permita ligar los registros entre una tabla y
otra en la relacin 1:N.
4. Se sugiere establecer un ndice para la columna clave en la tabla maestro, con la finalidad de no permitir valores nulos o repetidos en dicho campo adems de optimizar
las operaciones de bsqueda sobre una tabla.
5. Se sugiere tambin colocar ndices que acepten valores duplicados y nulos en la tabla detalle con el fin de hacer ms eficientes las bsquedas y otras operaciones sobre
los registros de esa tabla.
3.5 Respecto a las reglas de Normalizacin
22/08/2016
Tabla de Contenido
Page 11 of 18
Pre
viou

Todo diseo de una Base de Datos deber estar al menos en su tercera forma normal 3FN.
Normalizacin es un proceso que clasifica relaciones, objetos, formas de relacin y dems elementos en grupos, en base a las caractersticas que cada uno posee.
Si se identifican ciertas reglas, se aplica una categora; si se definen otras reglas, se aplicar otra categora.
Cuando las reglas de clasificacin sean ms y ms restrictivas, diremos que la relacin est en una forma normal ms elevada. La relacin que est en la forma
normal ms elevada posible es que mejor se adapta a nuestras necesidades debido a que optimiza las condiciones que son de importancia para nosotros:
- La cantidad de espacio requerido para almacenar los datos es la menor posible;
- La facilidad para actualizar la relacin es la mayor posible;
- La explicacin de la base de datos es la ms sencilla posible.
Al modelar una base de datos, desearemos evitar puntos que crean confusin, duplicacin de la informacin y por ende, un mal funcionamiento y exploracin de la
informacin. Entre las propiedades indeseables en un diseo de bases de datos tenemos:
- Redundancia en la informacin.
- Incapacidad de representar cierta informacin.
- Registrar informacin que no sea identificable.
Ejemplo:
Tomando como ejemplo crear una tabla con la informacin de usuarios, y los datos a guardar de este son el nombre, la empresa, la direccin de la empresa y algn
e-mail, o bien URL si las tienen. En principio se comenzar definiendo la estructura de una tabla como esta:
Formalizacin CERO
Diramos que la anterior tabla esta en nivel de Formalizacion Cero porque ninguna de las reglas de normalizacin ha sido aplicada. Obsrvese los campos url1 y url2
-- Qu se har cuando en la aplicacin se necesite una tercera url ? Se tendr que aadir otro campo/columna a la tabla y tener que reprogramar toda la entrada
de datos del cdigo de programacin? Obviamente no, lo que se quiere es crear un sistema funcional que pueda crecer y adaptarse fcilmente a los nuevos
requisitos. Hechemos un vistazo a las reglas del Primer Nivel de Formalizacin-Normalizacin, y las aplicaremos a nuestra tabla.
Primer nivel de Formalizacin/Normalizacin. (1F/N)
Objetivos:
1. Eliminar los grupos repetitivos de la tablas individuales.
2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.
Se puede notar que se est rompiendo la primera regla cuando se repiten los campos url1 y url2 ? Y que pasa con la tercera regla, la clave primaria ? La regla
tres bsicamente significa que se tiene que poner una campo tipo contador autoincrementable para cada registro. De otra forma, Qu pasaria si tuvieramos dos
usuarios llamados Joe y que si se quisieran diferenciar. Una vez que se aplique el primer nivel de F/N resultara con la siguiente tabla:
Ahora diremos que nuestra tabla est en el primer nivel de F/N. Hemos solucionado el problema de la limitacin del campo url. Pero sin embargo se ven otros
problemas....Cada vez que se introduce un nuevo registro en la tabla usuarios, se tendr que duplicar el nombre de la empresa y del usuario. No slo dicha BD
crecer muchsimo, sino que ser muy facil que la BD se corrompa si se escribe mal alguno de los datos redundantes.
Por lo tanto se debe aplicar pues el segundo nivel de F/N:
Segundo nivel (2F/N)
Objetivos:
1. Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros.
2. Relacionar estas tablas mediante una clave externa.
3. Cada atributo que no est en la clave primaria es completamente dependiente de la clave primaria.
22/08/2016
Tabla de Contenido
Page 12 of 18
Hemos separado el campo url en otra tabla, de forma que podemos aadir ms en el futuro si tener que duplicar los dems datos. Tambien vamos a usar nuestra
clave primaria para relacionar estos campos:
Hemos creado tablas separadas y la clave primaria en la tabla usuarios, userId, esta relacionada ahora con la clave externa en la tabla urls, relUserId. Esto esta
mejor. Pero que ocurre cuando queremos aadir otro empleado a la empresa ABC ? o 200 empleados ? Ahora tenemos el nombre de la empresa y su direccin
duplicandose, otra situacin que puede inducirnos a introducir errores en nuestros datos. As que tendrmos que aplicar el tercer nivel de F/N:
Tercer nivel (3F/N).
Objetivos:
1. Eliminar aquellos campos que no dependan de la clave.
El nombre de empresa y su direccin no tienen nada que ver con el campo userId, asi que tienen que tener su propio empresaId:
Ahora tenemos la clave primaria emprId en la tabla empresas relacionada con la clave externa recEmpresaId en la tabla usuarios, y podemos aadir 200 usuarios
mientras que slo tenemos que insertar el nombre 'ABC' una vez. Nuestras tablas de usuarios y urls pueden crecer todo lo que quieran sin duplicacin ni corrupcin
de datos. La mayoria de los desarrolladores dicen que el tercer nivel de F/N es suficiente, que nuestro esquema de datos puede manejar facilmente los datos
obtenidos de una cualquier empresa en su totalidad, y en la mayoria de los casos esto ser cierto.
Pero hechemos un vistazo a nuestro campo urls - Ves duplicacin de datos ? Esto es perfectamente aceptable si la entrada de datos de este campo es solicitada al
usuario en nuestra apliacin para que teclee libremente su url, y por lo tanto es slo una coincidencia que Joe y Jill teclearon la misma url. Pero que pasa si en lugar
de entrada libre de texto usramos un men desplegable con 20 o incluso ms urls predefinidas ? Entonces tendramos que llevar nuestro diseo de BD al siguiente
nivel de F/N, el cuarto, muchos desarrolladores lo pasan por alto porque depende mucho de un tipo muy especfico de relacin, la relacin 'varios-con-varios', la cual
an no hemos encontrado en nuestra aplicacin.
22/08/2016
Tabla de Contenido
Page 13 of 18
Relaciones entre los Datos
Antes de definir el cuarto nivel de F/N, veremos tres tipos de relaciones entre los datos: uno-a-uno, uno-con-varios y varios-con-varios. Mira la tabla usuarios en el
Primer Nivel de F/N del ejemplo de arriba. Por un momento imaginmos que ponemos el campo url en una tabla separada, y cada vez que introducimos un registro en
la tabla usuarios tambien introducimos una sola fila en la tabla urls. Entonces tendramos una relacion uno-a-uno: cada fila en la tabla usuarios tendra exactamente
una fila correspondiente en la tabla urls. Para los propsitos de nuestra aplicacin no sera til la normalizacin.
Ahora mira las tablas en el ejemplo del Segundo Nivel de F/N. Nuestras tablas permiten a un slo usuario tener asociadas varias urls. Esta es una relacin uno-convarios, el tipo de relacin ms comn, y hasta que se nos present el dilema del Tercer Nivel de F/N. la nica clase de relacin que necesitamos.
La relacin varios-con-varios, sin embargo, es ligeramente ms compleja. Observa en nuestro ejemplo del Tercer Nivel de F/N que tenemos a un usuario relacionado
con varias urls. Como dijmos, vamos a cambiar la estructura para permitir que varios usuarios esten relacionados con varias urls y as tendremos una relacin varioscon-varios. Veamos como quedaran nuestras tablas antes de seguir con este planteamiento:
Para disminuir la duplicacin de los datos ( este proceso nos llevar al Cuarto Nivel de F/N), hemos creado una tabla que slo tiene claves externas y primarias
url_relations. Hemos sido capaces de remover la entradas duplicadas en la tabla urls creando la tabla url_relations. Ahora podemos expresar fielmente la relacin
que ambos Joe and Jill tienen entre cada uno de ellos, y entre ambos, las urls. As que veamos exctamente que es lo que el Cuarto Nivel de F/N. supone:
Cuarto Nivel de F/N
Objetivos:
1. En las relaciones varios-con-varios, entidades independientes no pueden ser almacenadas en la misma tabla.
Ya que slo se aplica a las relaciones varios-con-varios, la mayoria de los desarrolladores pueden ignorar esta regla de forma correcta. Pero es muy til en ciertas
situaciones, tal como esta. Hemos optimizado nuestra tabla urls eliminado duplicados y hemos puesto las relaciones en su propia tabla.
Mediante un ejemplo prctico, podemos seleccionar todas las urls de Joe realizando la siguiente instruccin SQL:
SELECT nombre, url FROM usuarios, urls, url_relations WHERE url_relations.relatedUserId = 1 AND usuarios.userId = 1 AND urls.urlId =
url_relations.relatedUrlId
Y si queremos recorrer todas las urls de cada uno de los usuarios, hariamos algo as:
SELECT nombre, url FROM usuarios, urls, url_relations WHERE usuarios.userId = url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId.
Quinto Nivel de F/N
Existe otro nivel de normalizacin que se aplica a veces, pero es de hecho algo esotrico y en la mayoria de los casos no es necesario para obtener la mejor
funcionalidad de nuestra estructura de datos o aplicacin.
Su principio sugiere:
22/08/2016
Tabla de Contenido
Page 14 of 18
Objetivos:
1. La tabla original debe ser reconstruida desde las tablas resultantes en las cuales a sido troceada.
Los beneficios de aplicar esta regla aseguran que no has creado ninguna columna extraa en tus tablas y que la estructura de las tablas que has creado sea del
tamao justo que tiene que ser. Es una buena prctica aplicar este regla, pero a no ser que estes tratando con una extensa estructura de datos probablemente no
se necesitar.
3.6 Respecto a la Integridad y Consistencia de la Informacin
Pre
viou

Cuando en nuestra Base de Datos se tengan columnas o campos comunes entre dos o ms tablas para indicar una relacin, se deben considerar las polticas siguientes:
Todo cambio efectuado en aquel o aquellos registros en una tabla que esta relacionada con otra debe ser efectuados en el los registros referenciados por los campos
comunes en las dos tablas.
Por ejemplo:
Si se tienen dos tablas TblVentas y TblDetalleVentas que expresan una relacin 1: N en una factura y adems existe en ambas tablas un campo llamado
CveVentasFacturaCodigo que conecta las dos tablas. Si se efecta una operacin de eliminacin de un registro en la tabla TblVentas, se restringe su eliminacin slo si en
la tabla TblDetalleVentas no existan registros cuya CveVentasFacturaCodigo coincida con la de el registro a borrar en TblVentas, ya que si coinciden las claves significa que
al realizar esa venta se vendieron muchos artculos o bien se deben borrar adems del registro en la tabla maestro TblVentas todos los registros cuya clave sea la misma
que la de el registro en la tabla TblVentas, as ser eliminada una venta y el detalle de la misma.
El mismo criterio ser empleado en el caso de altas o modificaciones en cualquiera de las tablas de una relacin.
La finalidad de las polticas anteriores es asegurar la consistencia y coherencia de la informacin almacenada en la Base de Datos.
3.7 Respecto a los permisos de usuario
Pre
viou

Se otorgarn permisos de seleccin, modificacin o eliminacin de datos para cada tabla de una Base de Datos a aquellos grupos de usuarios cuyo contacto con el
sistema sea nicamente para realizar consultas, altas, eliminaciones modificaciones de Informacin, basado en el procedimiento oficial para ejecutar tal requerimiento.
Se darn permisos adicionales a los anteriores para aquellos grupos de usuarios que administrarn el sistema, estos permisos incluirn la posibilidad de crear vistas y
alterar ndices aunque la posibilidad de alterar una estructura de una tabla si las necesidades actuales as lo exigen tendra que hacerse a parte del requerimiento oficial un
anlisis mas detallado por parte del Administrador de Base de Datos con el propsito de certificar o no tal requerimiento, todo ello en consonancia con el los
procedimientos de seguridad de usuarios establecidos por el Administrador de seguridad del Banco.
La seguridad de control de acceso a los datos en los Motores de Base de Datos, estar basada en el uso de Directorio Activo.
3.8 Respecto al Diccionario de Datos
Pre
viou

Todas las Bases de Datos debern constar con su propio diccionario de datos, el cual contiene las caractersticas lgicas de los sitios donde se almacenan los datos
del sistema, incluyendo nombre, descripcin, alias, contenido y organizacin.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de
datos y auxilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo.
Razones para su utilizacin:

1) Para manejar los detalles en sistemas muy "grandes", ya que tienen "enormes" cantidades de datos, aun en los sistemas ms "pequeos" hay gran cantidad de
datos.
Los sistemas al sufrir cambios continuos, es muy difcil manejar todos los detalles. Por eso se registra la informacin, ya sea sobre hoja de papel o usando
procesadores de texto. Los analistas mas organizados usan el diccionario de datos automatizados diseados especficamente para el anlisis y diseo de software.
2) Para asignarle un solo significado a cada uno de los elementos y actividades del sistema.
Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema y registrando detalles
adicionales relacionados con el flujo de datos en el sistema, de tal manera que todo pueda localizarse con rapidez.
3) Para documentar las caractersticas del sistema, incluyendo partes o componentes as como los aspectos que los distinguen. Tambin es necesario saber bajo que
circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren. Produciendo una comprensin ms completa. Una vez que las caractersticas estn
articuladas y registradas, todos los participantes en el proyecto tendrn una fuente comn de informacin con respecto al sistema.
4) Para facilitar el anlisis de los detalles con la finalidad de evaluar las caractersticas y determinar donde efectuar cambios en el sistema.
Determina si son necesarias nuevas caractersticas o si estn en orden los cambios de cualquier tipo.
Se abordan las caractersticas:
Naturaleza de las transacciones: las actividades de la empresa que se llevan a cabo mientras se emplea el sistema.
22/08/2016
Tabla de Contenido
Page 15 of 18
Preguntas: solicitudes para la recuperacin o procesamiento de informacin para generar una respuesta especfica.
Archivos y bases de datos: detalles de las transacciones y registros maestros que son de inters para la organizacin.
Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar transacciones y datos
5) Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un informe. Aun en los manuales, se revelan errores.
Descripcin de los Datos en el Diccionario
Cada entrada en el diccionario de dato consiste en un conjunto de detalles que describen los datos utilizados o producidos en el sistema. Cada artculo se identifica por un
nombre de dato, descripcin, sinnimo y longitud de campo y tiene valores especficos que se permiten para ste en el sistema estudiado.
Nombre de los Datos
Para distinguir un dato de otro, los analista les debe asignar nombre significativos que se utilizan para tener una referencia de cada elemento a travs del proceso total de
desarrollo de sistemas. Por lo tanto, debe tenerse cuidado para seleccionar, en forma significativa y entendible, los nombres de los datos.
Por Ejemplo: la fecha de factura es ms significativa si se llama FacturaFecha que si se le conoce como ABCXXX.
Descripcin de los Datos
Establece brevemente lo que representa el dato en el sistema;
Por Ejemplo, la descripcin para Fecha de Factura indica que es la fecha en la cual se est preparando la misma (para distinguirla de la fecha si fuera el caso en la que
se envi por correo o se recibi).
Las descripciones de datos se deben escribir suponiendo que las personas que los lean no conoce nada en relacin del sistema.
Deben evitarse termino especiales o argot, todas las palabras deben ser entendibles para el lector
Alias
Con frecuencia el mismo dato puede conocerse con diferentes nombres, dependiendo de quien lo utilice.
El uso de los alias deben evitar confusin. Un diccionario de dato significativo incluir todos los alias.
Longitud de campo
Cuando las caractersticas del diseo del sistema se ejecuten ms tarde en el proceso de desarrollo de los sistemas, ser importante conocer la cantidad de espacio que
necesita para cada dato.
Valores de los datos
En algunos procesos solo se permiten valores de datos especficos.
Por ejemplo: en muchas compaas con frecuencia los nmeros de orden de compra se proporcionan con un prefijo de una letra para indicar el departamento del origen.
Registro de las descripciones de datos

Dadas que las descripciones se utilizarn en forma repetitiva a travs de una informacin y despus, durante el diseo, se sugiere un formato fcil para utilizar que
simplifique el registro y los detalles de consulta cuando se necesiten.
Otra manera de descripcin de los datos es mediante el uso de simbologas tales como se muestran en la tabla siguiente:
Simbologa bsica utilizada en la descripcin de un diccionario de datos a nivel de diseo
Smbolo
Significado
=
Composicin: Esta compuesto de es equivalente a
+
Inclusin: y
[]
Seleccin: Selecciona una de las opciones encerradas entre corchetes y separadas por el smbolo "|"
{}
Iteracin: Iteraciones del componente encerrado entre llaves
()
Opcin: Significa que el componente encerrado es opcional (puede estar presente ausente)
*texto*
Comentario: El texto entre asteriscos es un comentario aclarativo de una entrada del DD
@
Identificador: Se utiliza para sealar un campo conjunto de campos que identifican cada ocurrencia de un almacn
Ejemplo: En el presente diseo de diccionario de datos se ejemplifica los atributos de la tabla de clientes as como tambin una descripcin clara de los datos que deberan
almacenados en dichos campos.
22/08/2016
Tabla de Contenido
Page 16 of 18
Modelo de Diccionario de Datos que debe ser entregado al momento de revisin de estructuras de Base de Datos.
4 Registro de Movimientos Histricos
Pre
viou

El registro de los movimientos histricos se elabora, al igual que las tablas de los documentos normales, en dos tablas una que contiene al encabezado y otra que contiene
al detalle.
El nombre de las tablas se compone por el estndar "Hst", seguido del nombre identificador de la tabla.
4.1 Tabla del Encabezado del Histrico (HstEnc...)
Pre
viou

La estructura de la tabla del encabezado del histrico, se compone los siguientes campos:
Los campos de la tabla del encabezado del documento.
Clave o llave primaria ( CveHst ): es la clave que liga al encabezado del histrico con el detalle del histrico, es un entero serial , puede ser generado por un Trigger.
Fecha de la modificacin (FechaUltimaModificacion ): contiene a la fecha del da en que se realiz la modificacin.
Usuario que realizo la modificacin ( CveUsuarioModifica ): aqu se guarda el nombre de usuario de la persona que realizo la modificacin.
4.2 Tabla del Detalle del Histrico (HstDet...)
Pre
viou

22/08/2016
Tabla de Contenido
Page 17 of 18
La estructura de la tabla del detalle del histrico, se compone por los siguientes campos:
Los campos de la tabla del detalle del documento.

La clave del histrico que liga los detalles a la tabla del encabezado del histrico (CveHst).
5 Convenciones
Pre
viou

Respecto a los nombres que se asignarn a objetos de base de datos (tablas, ndices, procedimientos almacenados, vistas, vistas materializadas, desencadenadores,
paquetes, funciones y campos de las tablas en las bases de datos se establecen las siguientes convenciones:
1. Toda la documentacin que sobre Bases de Datos se realice tal como la nomenclatura de dichos objetos deber cumplir con las especificaciones establecidas en este
documento en la seccin correspondiente a cada objeto.
2. El nombre de los directorios de respaldo, ser de acuerdo a lo establecido en la documentacin misma del documento de respaldo y recuperacin de las Bases de Datos
y deber nombrarse estas con el mismo nombre de la Base de Datos que respalda, para mas informacin consultar la documentacin concerniente a el respaldo y
recuperacin de las Bases de Datos.
3. El esquema de la estructura de una Base de Datos cualquiera, deber incluir informacin tal como : nombre de la Base de Datos, propsito u objetivo de la Base de
Datos, nombre de el los sistemas que utilizan esa Base de Datos, espacio en disco ocupado por la Base de Datos, ruta y nombre de los directorios de respaldo de esa
Base de Datos, el nombre, propsito, campos, ndices, tipo de datos almacenados, nmero de registros, bytes utilizados y permisos de cada tabla de la Base de Datos.
Este esquema de la base de datos es un documento que deber cumplir las convenciones establecidas en el punto 1 de esta seccin.
4. Al disear un Sistema de Informacin adems de contar con el diagrama de flujo de datos, se deber elaborar el diagrama Entidad-Relacin de la Base de Datos
manejada por el sistema.
5. Se deber respaldar la informacin contenida en cada Base de Datos en el directorio y servidor correspondiente al final de cada da operativo antes en caso de fallas
mantenimiento de las mismas.
6. Slo se utilizarn ndices en aquellas tablas cuyo volumen de informacin o el uso de claves primarias y/o forneas lo requiera para evitar problemas en bsquedas o
modificaciones optimizando el tiempo para realizar tales operaciones.
6 Glosario
Pre
viou

1- Leszynski Naming Conventions (LNC)
2- Nomenclatura GIK
3- Sinnimos de Tablas
4- Auditoria de Grano Fino "Oracle Fine Grained Auditing (FGA)"
1- Leszynski Naming Conventions (LNC)
Stan Leszynski, un tipo con grandes conocimientos en desarrollo de bases de datos, fundador en 1982 de Leszynski Company Inc. creadores de entre otros del OLE
calendar y de ActiveX para Access 97.
Creo las Convenciones nominales Leszynski Naming Conventions (LNC), un estndar de vocabulario para asignar a los objetos de Access, con la finalidad de una rpida
compresin de la estructura de la aplicacin y el cdigo.
Esta LNC llega a los siguientes objetos:
Tablas, Campos de tablas, Consultas, Formularios, Controles de formulario, Informes, Controles de informe, Macros, Mdulos, Procedimientos, Variables, Constantes y
Tipos definidos por el usuario.
Ejemplo:
Objeto
Tabla
Formulario
Consulta
informe
Prefijo
Tbl
frm
qry
rpt
La convencin de Leszynski abarca los nombres de campos, las imgenes y todos los objetos utilizados en Access, pero en este libro slo se utilizan los prefijos citados
anteriormente. De acuerdo con la convencin de nomenclatura de Leszynski:
El nombre que va a continuacin del prefijo del objeto debe empezar por una letra mayscula.
Nunca se utilizarn espacios en blanco en los nombres de tablas.
Los nombres de las tablas deben contener slo letras y nmeros si es necesario.
2- Nomenclatura GIK
La utilizacin de GeneXus nos facilita l poder compartir y reutilizar el conocimiento, uno de los problemas con los que nos encontramos a la hora de compartir
conocimiento es que cada programador sigue sus propios criterios para nombrar atributos.
Para poder solucionar este problema ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base).
Esta nomenclatura puede tener crticas pero es la que nos propone ARTech para que sea utilizada por la comunidad GeneXus.
La importancia de utilizar esta nomenclatura esta en que viabiliza a la reutilizacin de conocimiento entre KBs.
Por otro lado escribir el cdigo GeneXus siguiendo la nomenclatura estndar enfatiza la comunicacin a travs del cdigo, tambin favorece el entendimiento por otro
22/08/2016
Tabla de Contenido
Page 18 of 18
programador y facilita el mantenimiento del mismo.
Nombre de atributo => Objeto + Categora + Calificador + Complemento

Objeto: Es el nombre de la tabla a la que pertenece el atributo. (1 a 7)
Categora: Es la categora semntica del atributo. (1 a 6)
Calificador: Puede existir uno o dos calificadores (1 a 6)
Complemento: Texto libre
Ejemplo de Nomenclatura GIK
ObjetosCategorasCalificadorComplemento
Cli
Cod
Cli
Nom
Cli
Fch
Ini
Cli
Fch
Fin
Cli
Fch
Ing
Banco
Fac
Vta
Nro
Fac
Cmp
Nro
Basndonos en esta nomenclatura vamos a definir un ejemplo de la Tabla Cliente

Nombre Tabla: TblCliente
Atributos
CliCod*
Cdigo de Cliente
CliNom
Nombre de Cliente
CliApe
Apellido de Cliente
CliFchNac
Fecha Nacimiento de Cliente
CliTel
Telfono de Cliente
CliTelOficina Telfono de Cliente en la Oficina
Nuevo GIK
A pesar de lo bueno que me parece el GIK se tiene que aceptar que en la actualidad se tiende a no abreviar ya que no tenemos las limitaciones que tenamos en el
pasado.
Si se va a comenzar un proyecto nuevo se recomienda que adapten el GIK a las nuevas posibilidades que nos brinda GeneXus.
Ej:
Tabla: TblCliente
Atributos
ClienteCodigo
ClienteNombre
ClienteApellido
3- Sinnimos de Tablas
Catlogo: Es una definicin a nivel gerencial de negocio de una agrupacin de elementos.
Entidad: Representacin lgica de un objeto, cosa o cualquier elemento de un sistema de informacin.

Tabla: Descripcin fsica que representa la entidad en una Base de Datos.
4- Auditoria de Grano Fino "Oracle Fine Grained Auditing (FGA)"
Oracle hace uso del paquete DBMS_FGA para administra todas las polticas de auditoria de grano fino. La auditoria de grano fino (FGA) fue introducida con Oracle 9i; y
solo contemplaba el comando SELECT. En Oracle 10g, FGA contempla tambin INSERT, UPDATE, y DELETE.
La auditoria de Grano Fino (FGA) extiende la capacidad de permitir la captura el actual SQL que manipula los datos.
22/08/2016

Estandares PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estandares PDF

Uploaded by

Copyright:

Available Formats

Tabla de Contenido

1.1 Bases de Datos

"BANCO CENTRAL DE HONDURAS"

El prefijo BD siempre estar escrito en letra mayscula.

Adems se debe cumplir con lo siguiente:

1.1.C Campos de Tablas

Descripcin de los Campos

1.1.D Procedimientos Almacenados

El prefijo PA siempre estar escrito en letra mayscula.

estar representado con dicha vista.

1.1.F Vistas Materializadas en Oracle

create materialized view "usrsasi"."VMSolicitudesSoporte" using index refresh force on commit as

Volver al Inicio de Pgina

1.1.G Triggers Desencadenadores

"BANCO CENTRAL DE HONDURAS"

"BANCO CENTRAL DE HONDURAS"

INS (cuando el objetivo principal es agregar informacin).

Procedimiento: PA_EstadoINS , PA_EstadoDEL , PA_EstadoUPD.

1.1.J Trabajos Automatizados (JOBS)

1.1.K Polticas de Auditora en Oracle

"BANCO CENTRAL DE HONDURAS"

1.1.K.1 Creacin y Configuracin de Poltica

"BANCO CENTRAL DE HONDURAS"

audit_column => 'cveparametrofecha',

1.1.K.2 Deshabilitar Poltica

Volver al Incio de Pgina

"BANCO CENTRAL DE HONDURAS"

1.1.K.3 Habilitar Poltica

"BANCO CENTRAL DE HONDURAS"

1.1.K.4 Eliminar Poltica

1.1 Bases de Datos

"BANCO CENTRAL DE HONDURAS"

2.2 Bases de Datos

"BANCO CENTRAL DE HONDURAS"

Oracle : Generacin de cadena de conexin para conectarse a Oracle de la siguiente manera :

Otros : Odbc , jdbc ,gateways , DataBase links

1.1 Bases de Datos

"BANCO CENTRAL DE HONDURAS"

3.I Respecto a la redundancia de Informacin

"BANCO CENTRAL DE HONDURAS"

3.2 Respecto a los Respaldos de las Bases de Datos

"BANCO CENTRAL DE HONDURAS"

3.3 Respecto al manejo del Log de Transacciones en una Base de Datos

"BANCO CENTRAL DE HONDURAS"

2.4 Respecto a la resolucin de Relaciones 1: N entre Tablas

3.5 Respecto a las reglas de Normalizacin

"BANCO CENTRAL DE HONDURAS"

Primer nivel de Formalizacin/Normalizacin. (1F/N)

Relaciones entre los Datos

3.6 Respecto a la Integridad y Consistencia de la Informacin

"BANCO CENTRAL DE HONDURAS"

3.7 Respecto a los permisos de usuario

"BANCO CENTRAL DE HONDURAS"

3.8 Respecto al Diccionario de Datos

"BANCO CENTRAL DE HONDURAS"

Razones para su utilizacin:

Descripcin de los Datos en el Diccionario

Registro de las descripciones de datos

Volver al Inicio de Pgina

4 Registro de Movimientos Histricos

"BANCO CENTRAL DE HONDURAS"

4.1 Tabla del Encabezado del Histrico (HstEnc...)

"BANCO CENTRAL DE HONDURAS"