Aseguramiento de la calidad

EPEDBD

12/10/2015

ESTNDARES PARA EL DISEO DE BASE DE DATOS

[EPEDBD]

Aseguramiento de la calidad

EPEDBD

12/10/2015

NDICE
Descripcin .................................................................................................................................. 3
Reglas Generales ........................................................................................................................ 4
Reglas generales en las tablas....4

Reglas generales para nombres.......4

Reglas generales para relaciones entre tablas. ..5
Reglas generales para tablas de relacin.....5
Reglas generales para los campos claves ............................................................................ 5
Reglas generales para otros campos..6
Reglas generales de acuerdo a su presentacin conceptual6
Reglas generales para datos booleanos.6
Reglas generales para campos de relacin..6

Aseguramiento de la calidad

EPEDBD

12/10/2015

1. DESCRIPCIN
La direccin general del gobierno digital participa activamente a lo largo del
ciclo de vida del desarrollo de un software para asegurar la calidad del mismo.
Uno de los instrumentos que facilitan esta tarea es la adopcin de estndares
de diseo de base de datos.
El uso de estos estndares tiene innumerables ventajas, entre ellas:

Asegurar la legibilidad del modelo de datos, inclusive para personas que

no estn relacionadas con el ambiente informtico, en etapas de anlisis
y diseo.

Facilitar la portabilidad entre motores de base de datos, plataformas y

aplicaciones.

Facilitar la tarea de los programadores en el desarrollo de los sistemas.

Es por esto que la codificacin de las tablas de las bases de datos a

desarrollar debe cumplir ciertos requisitos, detallados en el presente
documento.
Estos requisitos pueden aplicarse en cualquier motor de base de datos.

Aseguramiento de la calidad

EPEDBD

12/10/2015

2. REGLAS GENERALES
Los nombres de tablas y campos deben especificarse bajo el estndar
camelCase. Este estndar especifica escribir las palabras compuestas
eliminando los espacios y poniendo en mayscula la primera letra de cada
palabra. En este mbito se utilizar la variante lowerCamelCase (la
primera letra del nombre, en minscula).
nicamente se utilizarn caracteres alfabticos, salvo que por la
naturaleza del nombre se necesiten dgitos numricos. Se prohbe el uso
de caracteres de puntuacin o smbolos.
Ejemplo: localidadesCenso2003.

Las letras acentuadas se reemplazarn con las equivalentes no

acentuadas, y en lugar de la letra ee () se utilizar (ni).
Ejemplo: anioExpediente, montoSenia.

El nombre elegido debe ser lo ms descriptivo posible, evitando trminos

ambiguos o que se presten a distintas interpretaciones.
Ejemplo: tiposMunicipios => categoriasMunicipios.

El nombre no debe abreviarse, salvo que por necesidad especfica deban

especificarse ms de una palabra en el mismo.
Ejemplo: ido => idOrganismo, freg => fechaRegistro

Agregar comentarios a las bases de datos y los campos, sobre todo a los
booleanos.

2.1. Reglas generales en las Tablas

2.1.1. Para nombres

Los nombres deben especificarse en plural, y de acuerdo a las reglas

generales.
Ejemplo: departamentos, facturas, monedas.

Aseguramiento de la calidad

EPEDBD

12/10/2015

2.1.2. Para relaciones entre tablas

En el caso de tablas que se relacionan especficamente con otra tabla

(ej. tablas tipo, nomencladores, entidades dbiles), esta relacin debe
quedar expresada en el nombre.
Ejemplo: domiciliosPersonas, categoriasMunicipios.
2.1.3. Para tablas de relacin

Las tablas de relacin (objetos asociativos, representan relaciones de

N a M) deben nombrarse utilizando los nombres de las tablas
intervinientes, siguiendo un orden lgico de frase.
Ejemplo: localidadesMunicipios, facturasNotas

2.2. Reglas generales para los campos claves

a. Toda tabla debe poseer uno o ms campos clave.

b. Toda relacin entre tablas debe implementarse mediante constraints
(claves forneas) con integridad referencial, de acuerdo al motor de base
de datos utilizado.
c. La integridad referencial deber actualizar en cascada en todos los casos,
y restringir el borrado salvo para las entidades dbiles.
Ejemplo: no se podr eliminar un registro de la tabla localidades que
tenga ocurrencias en otras tablas; para este caso deber implementarse
el borrado lgico. Por el contrario, s podr habilitarse el borrado en
cascada si la relacin fuera entre las tablas facturas y renglonesFactura.
d. Los campos clave deben ubicarse al inicio de la definicin de la tabla
(deben ser los primeros).
e. El nombre del campo clave debe estar compuesto por id + nombre de la
tabla en singular (para claves no compuestas). Dependiendo de la
naturaleza de la entidad, el nombre de la tabla a usar es el de la misma
tabla, o el de la relacionada.
Ejemplo: tabla localidades => idLocalidad.
f. Las claves compuestas slo deben utilizarse en casos especficos, por
ejemplo, tablas de relacin o entidades dbiles. Si una tabla X con clave
compuesta necesita ser referenciada desde otra tabla Y, deber
generarse un campo clave en X al inicio de la misma como idX, y generar
un ndice nico en los campos que la identificaban.
5

Aseguramiento de la calidad

EPEDBD

12/10/2015

2.3. Reglas generales para otros campos

Todo campo que represente un nombre o descripcin, se colocar

inmediatamente despus de los campos clave, y se nombrar como a la tabla
a la que pertenece, en singular.
Ejemplo: tabla localidades => idLocalidad, localidad. Tabla
sucursalesEmpresas => idEmpresa, idSucursal, sucursal
2.3.1. De acuerdo a su presentacin conceptual

Algunos campos que representan datos, de acuerdo a su representacin

conceptual en el mbito del negocio, debern prefijarse de la siguiente
manera:
Nmeros: num (ejemplo: Nmero de factura => numFactura)
Fechas: fecha (ejemplo: Fecha de inscripcin => fechaInscripcion)
Cdigos: cdigo (ejemplo: Cdigo de producto: codigoProducto)

2.3.2. Para datos booleanos

Los campos booleanos debern nombrarse de acuerdo al estado

correspondiente al valor 1/Verdadero/True de los mismos.
Ejemplos: autorizado, oculto, vigente.
2.3.3. Para campos de relacin

Los campos de relacin (foreign keys, claves forneas) deben nombrarse

de la misma manera que los campos clave (usando el nombre de la tabla
a la que hacen referencia).
Ejemplo: tabla personas => idTipoDocumento, idEstadoCivil
Si el framework de desarrollo utilizado genera o requiere nombres de
campos con nomenclatura especfica, deber consultarse a la Direccin
General de Gobierno Digital la conveniencia de su uso.