You are on page 1of 12

ESTANDARES DE LA BASE DE DATOS

Aplicacin de calidad a modelos conceptuales de base de datos


El modelo conceptual es el enlace entre los requisitos funcionales de un sistema de
informacin y el diseo de la base de datos, lo que implica una serie de actividades
que permitan definir qu se va a representar y cmo se va a representar,
independientemente del gestor de bases de datos que se vaya a utilizar; hay que
tener en cuenta que existen restricciones del mundo real que no pueden ser
representadas en un modelo conceptual, por lo que es necesario adicionar
representaciones textuales al diagrama.
La primera tarea es especificar los requisitos de la aplicacin en un lenguaje natural;
para esto es necesario realizar encuestas y entrevistas a las personas que estn
involucradas en la organizacin o empresa, revisar la documentacin usada y, si
existe algn software, detallar las interfaces y formularios que son manejados por l;
esto puede consignarse en un documento de especificacin de requisitos, que
representa un esquema percibido de lo que se va a representar.
La segunda tarea consiste en obtener el diagrama conceptual a partir de los
requisitos; para esto, algunos autores nos presentan unas claves para identificar
entidades, atributos y relaciones:

Entidades: sern identificadas de los requisitos como objetos reales o


abstractos de los cuales se desea almacenar informacin; suelen estar
en forma de sustantivos. Las entidades se caracterizan por poder ser
descritas o descompuestas en elementos ms pequeos; adems,
existen dos tipos de entidades: las fuertes, que pueden existir por s
mismas, es decir, sin dependencia de otra entidad, y las dbiles, cuya
existencia depende de la ocurrencia de otra entidad y, por consiguiente,
si se elimina la ocurrencia de la entidad fuerte se elimina su existencia.

Atributos: pueden ser obtenidos de los requisitos como propiedades o


caractersticas que tiene una entidad. Los atributos suelen estar en
singular y son indivisibles, si un atributo puede ser descompuesto es
indicio de que es una entidad o puede acabar como una relacin,
porque se haya determinado que el atributo es una referencia a otro
tipo de entidad.

Relaciones: pueden obtenerse a partir de los verbos que interactan


con dos o ms sustantivos (libro alquilado por un estudiante), las
relaciones son asociaciones o correspondencias entre entidades,
adems, las relaciones presentan cierto grado de cardinalidad con las
que cada tipo de entidad interviene en el tipo de interrelacin.

Una vez que se han identificado los anteriores elementos y se diagraman


acorde con una notacin particular, se debe buscar que el modelo conceptual
se caracterice por su:

Claridad, esto es, que la significacin no sea ambigua

Coherencia, es decir, no existan contradicciones o confusiones

Plenitud, en cuanto a que el esquema representa lo esencial del


fenmeno

Fidelidad, en el sentido de que la representacin del universo del


discurso ha de hacerse sin desviaciones ni deformaciones

Simplicidad, pues se ha de buscar la mxima sencillez

Tambin puede aplicar una serie de Reglas de consistencia e integridad, como


se muestran en la Tabla 6, que le permiten verificar si el modelo conceptual
fue correctamente elaborado, y si no lo fue, proceder a hacer las respetivas
correcciones.

Mediciones al Diagrama Entidad-Relacin


Para ejemplificar la medicin al modelo, se usar el modelo conceptual
presentado en la Fig. 1, basado en la lgica de negocio de una compraventa
de vehculos. Una vez que se revisa el cumplimiento de las reglas de
consistencia e integridad de la Tabla 7, se procede a seguir el marco de
trabajo para la elaboracin de las mtricas de calidad basado en el estndar
ISO/ IEC 9126-3.

1. Identificacin de requisitos de calidad: Los requisitos de


calidad corresponden a las su caractersticas que se van a evaluar; cabe
destacar que el modelo conceptual es un producto de software no
ejecutable, por lo que se aplicarn mtricas internas segn ISO 9126.
Adems de lo anterior, hay una serie de criterios que no sern
evaluados, como, por ejemplo, la portabilidad, debido a que es un
criterio que requiere de una implementacin fsica del modelo de datos;
por lo que solo se evaluarn caractersticas que son susceptibles de ser
aplicadas al modelo conceptual. En la Tabla 7 se resumen las
caractersticas por evaluar y el peso que tendr cada una; cabe aclarar
que el peso est especificado de manera cualitativa, sin embargo, para
efectos prcticos se utilizar una escala de 0 a 1, siendo repartidos los
pesos de la siguiente manera:

o Bajo (B): 0,00-0,33


o Medio (M): 0,34-0,75

o Alto (A): 0,76-1,00

2. Diseo de la evaluacin: En esta etapa se asocian a cada


subcaracterstica los objetos por evaluar; para el caso particular ser
exclusivamente el modelo conceptual, sin embargo, las fuentes de
medicin de algunas mtricas incluyen el documento de especificacin
de requisitos. Adicionalmente, se codific cada mtrica interna con un
cdigo nico para elaborar la Tabla 8, donde fue necesario especificar
las mtricas por evaluar; en este caso se aplican exclusivamente
mtricas internas cuyos propsitos y mtodos de aplicacin fueron
descritos anteriormente.

Ciertas caractersticas del ISO 25012 se evalan con varias mtricas


diseadas con base en el marco de trabajo de ISO 9126-3, pero
modificadas a los criterios de calidad del modelo de calidad de datos;
por otro lado, se tienen otras caractersticas, como la exactitud, que
sern evaluadas por una sola mtrica, debido a que para el caso
particular se mide exclusivamente la exactitud de los atributos de
dominio.

3. Especificacin de la evaluacin: Para cada caracterstica de calidad


definida en la Tabla 8 es necesario definir las mtricas que van a ser
aplicadas, as como los niveles de satisfaccin que se consideran deben
cumplir las ponderaciones para ser consideradas de calidad. En la Tabla
9 se presentan las frmulas dadas para cada mtrica a criterio del
autor, con base en una serie de procedimientos diseados acorde al
marco de trabajo del ISO 9126-3.

4. Evaluacin y verificacin de los criterios de calidad: En la Tabla


10 se detalla la especificacin de la evaluacin obtenida; cabe aclarar
que la evaluacin se efectu con base en los requerimientos bajo los
cuales se dise el modelo, los cuales no se presentan por la extensin
del documento.

Una vez aplicada la evaluacin de las mtricas se procede a contrastar


las columnas Nivel Mnimo Requerido de la Tabla 9 y Puntaje de
la Tabla 10; las mtricas cuyos valores estn por debajo del nivel
requerido corresponden a los elementos del modelo que necesitan ser
modificados para posteriormente volver a realizar un anlisis sobre
ellos. En el caso de la caracterstica de Mantenibilidad se asign cero
(0) al puntaje, debido a que el modelo no sufri modificaciones en los
requisitos, por consiguiente, no se puede realizar la proyeccin de
facilidad de cambio del modelo; sin embargo, esto no quiere decir que
el modelo no tenga calidad, sino que simplemente esta caracterstica
queda pendiente para una evaluacin futura.

5. Transformaciones del modelo conceptual: Las transformaciones


por realizar deben hacerse con base en los aspectos dados por las
mtricas cuyo puntaje no satisface los niveles requeridos; el caso de
estudio se caracteriza por no estar an completo, lo que ocasiona que
no se tenga una adecuacin funcional completa; esto indica que es
necesario verificar los requisitos funcionales que an no han sido
modelados, y plasmarlos en el modelo. La existencia de requisitos

inexistentes puede deberse al uso de atributos y entidades que no


estn estipuladas en los requisitos funcionales; as, pues, las
transformaciones se pueden realizar con base en las siguientes
actividades:

Consistencia: reglas para nombrar atributos, entidades y


relaciones, adems de verificar el correcto uso de entidades
dbiles.

Completitud: verificacin de requisitos funcionales y de los


objetos que los satisfacen en el modelo conceptual.

Precisin: especificacin de tipos de datos en los atributos y


creacin de dominios basados en la lgica del negocio.

Exactitud: verificar que los dominios que fueron creados


correspondan con los atributos del modelo conceptual
consignados para tal fin.

Entendibilidad: tener en cuenta las reglas de notacin,


ortografa y la disposicin de los elementos del modelo
conceptual.

Manejabilidad: verificar la correspondencia de los atributos con


los tipos de datos que les son asignados (no incluye atributos de
dominio).

Facilidad de cambio: si los requisitos funcionales han cambiado


durante la elaboracin del modelo es posible realizar una
proyeccin para determinar si el diagrama conceptual se
adaptar; sin embargo, esta caracterstica es la ms difcil de
medir, debido a que se refiere a necesidades futuras cuyo
impacto en el modelo conceptual es incierto.

Estructura de tablas:
Orden de aparicin de los campos:
Llave artificial (auto numrico).
Llave natural (ndice nico).
Todos los dems campos en orden natural.

Nombre de objetos:

Los nombres de objetos deben ser lo ms corto posible,


fciles de leer, y lo ms descriptivo posible, evitando
trminos

ambiguos

que

se

presten

distintas

interpretaciones.
Ej: tipoMunicipio=>CategoriaMunicipio
Adems de lo anterior tambin deben de ser significativos, es decir,
que representen bien el propsito de ser del objeto en cuestin.

Pueden emplearse abreviaturas o acrnimos pero stos deben ser


regulados para evitar su proliferacin indiscriminada. Los nombres
deben incluir slo caracteres del alfabeto espaol excepto vocales con
acento, ees, y dirisis, y no deben utilizarse caracteres especiales ('#',
'/', ';', '%', '+', '-', etc.) ni espacios, el nico carcter espacial que se
permitir y exclusivamente en los casos que se especificaran
posteriormente ser el underscore _; el uso de nmeros debe evitarse
de ser posible. Los caracteres deben ser en minscula excepto la
primera letra de cada parte constitutiva del nombre (notacin
CamelCase); esta regla no aplica para abreviaturas de tipos de datos
y de tipo de objetos los cuales siempre sern en minscula

Nombre de la BD:

Deben representar el propsito de la misma y no a los usuarios,


departamentos o gerencias. No deben ser necesariamente iguales a los
nombres de las aplicaciones informticas.
vlidos:

InsumosAgricolas,

Inventarios,

Ejemplos de nombres
FinancieroContable,

RecursosHumanos, MedicamentosVeterinarios.

Nombre del campo:


Todos los campos deben iniciar con un acrnimo para el
tipo de dato al que pertenecen segn la siguiente tabla:

Los tipos nchar, nvarchar y ntext no deben utilizarse.


En los nombres de todos los campos, el acrnimo de tipo debe ir seguido
por un underscore _, esto con el fin de permitir la correcta lectura del tipo
de dato de este.
En los campos tipo fecha (datatime) es innecesario incluir la palabra Fecha
ya que est implcita en el tipo de dato, por lo tanto, en lugar de usar
dt_FechaIngreso basta con indicar dt_Ingreso.
Los campos deben especificar muy claramente que datos representan.
Implementacin:
vc_NombreEmpleado, b_Cancelado, d_Concentracion, dt_Inscripcion,
vc_Nota.

Nombre de tabla:
Los nombres siempre sern sustantivos en singular.
Deben empezar con un acrnimo que permita agrupar
de alguna manera lgica o funcional las tablas que estn
asociadas, seguidos del underscore _. El acrnimo Cat
se usar siempre para representar catlogos, y Sys

para tablas de uso interno de los sistemas.


Cat_Cliente,

Emp_Empleado,

Emp_Agenda,

Ejemplo:

Emp_Proyecto,

Prd_Producto,

Prd_Detalle,

Sys_Diccionario, Sys_Parametro, Cat_ClaseProducto.

Siempre son sustantivo en singular.


Iniciar con un acrnimo que permita agrupar de alguna manera
lgica seguido del -, (Cat, Emp, etc.).

Nomenclatura de secuencias
Seguirn al patrn APL_XXX_SEQ.
Donde XXX es un nombre representativo de la tabla o
campo para la cual se crea la secuencia.
Ejemplo:
APL_CLIENT_SEQ: para la secuencia del cdigo de la tabla
APL_CLIENT.

Nombres de Procedimiento Almacenado:


Todos los nombres de procedimientos almacenados deben
iniciar con el acrnimo usp ('User Stored Procedure') y siempre
debe ir seguido por un underscore _. El nombre debe ser un
verbo seguido de uno o ms sustantivos.

Ejemplo:

usp_CalcularSalarioBase, usp_ReservarAuto,
usp_CancelarCuenta.

Nombres de Vista:
Las vistas iniciarn con el acrnimo vw ('view'), siempre debe ir
seguido por un underscore _ y seguirn las mismas
convenciones generales para el uso de nombres.

Nombres de Triggers:

Los triggers iniciarn con el acrnimo trg, siempre


debe ir seguido por un underscore _, el nombre
de la tabla a la que pertenecen, en caso de ser
de una sola operacin (Insert, Update, Delete)
esta debe indicarse en el nombre, seguido del
nombre

bajo

las

mismas

convenciones

generales para el uso de nombres.

Estndar para respaldos


Dispositivos de copia de seguridad
Al

crearse

los

dispositivos

en

el

proceso

de

respaldos de las bases de datos, los nombres de


estos debern ser conformados por la abreviatura
disp,

el nombre de la base de datos, ms el

acrnimo respectivo para bases de datos (Bd) o si


es un archivo de transacciones (Lg), cada uno
separado del otro por un underscore _.

Implementacin:
disp_Seguridad_Db, disp_Sugerencias_Lg

Archivos de respaldos
Los

archivos

para

respaldos

debern

estar

conformados por el nombre de la Base de Datos,


fecha en que se realiza el respaldo (en formato aomes-da) y el acrnimo respectivo para bases de
datos (Bd) o si es un archivo de transacciones (Lg),
cada una de las partes constitutivas ira separada

por un underscore _.

La extensin de estos

archivos siempre ser bak.


Implementacin:

Inventarios_2009-2-24_Db.bak, Fiscalizacion_2009-224_Lg.bak

Restricciones adicionales y recomendaciones

El nombre de los objetos de base de datos ser como


mximo de 30 caracteres, y slo pueden incluir los
caracteres A-Z, a-z , 0-9 y guin bajo (_).

La creacin de los objetos no puede incluir comillas en la


definicin del nombre del objeto.
No se permitir la utilizacin de campos de tipo LONG.

El juego de caracteres de las bases de datos es UTF8


(NLS_CHARACTERSET = UTF8).
En el caso de crear campos de tipo VARCHAR2 o CHAR, al
indicar el nmero de caracteres se prestar atencin a que
no ponga "BYTE".
Para evitar los abrazos mortales (deadlocks) que se producen
al borrar registros de una tabla que tiene tablas
relacionadas (tablas hijas), se recomienda crear un ndice
para las claves extranjeras de la tabla hija.