Convenciones de nombres de Base de

Datos
General

Se emplearn siempre caracteres en minscula para cualquier identificador.

Los nombres se escriben normalmente en singular inclusive las tablas. Puede haber
excepciones para columnas multivaluadas. (Ej. Telefonos)
Como separador se emplear el smbolo _, no se utilizarn otras preposiciones.
Tambin se emplear como separador de palabras de nombres compuestos.
Ejemplos:
o Tiponormativa: tipo_normativa
o Tipodenormativa: tipo_normativa

Tablas

Las tablas las crea el sistema/mdulo que primero las precisa

Para el nombre de la misma se adopta la convencin de emplear: xxx_tabla donde
xxx identifica al sistema/mdulo que la cre.
En relaciones m x n entre tabla1 y tabla2, el nombre adoptado para la tabla que
representa a la relacin es yyy_tabla1_x_[zzz_]tabla2. Donde zzz es el prefijo de un
sistema si es distinto a yyy, en caso de ser iguales se omite. Siempre, tabla1 es la del
sistema sobre el cual se est trabajando, para que los prefijos coincidan.
Codificacin en la descripcin:
Salida (S) : Son las tablas utilizadas para
emitir informacin fuera del sistema en
diversos formatos (DBF , TXT , etc.)
Temporal (T) : Son las tablas utilizadas para
calculos intermedios y que se crean y borran a
tal efecto (DM11 , etc.)
Codificacin (C) : Son las tablas que se
proveen en funcin de necesidades del sistema
y que no son actualizables por el usuario
(pampacfg , etc.)
Datos (D) : Son las tablas que pueden ser
actualizadas por los usuarios del sistema
(DH01 , DH30 , etc.)

Creacin de tablas de Tipologas: Para el caso de Tablas que solamente contengan

Descripciones (por ejemplo Tabla de Motivos) se deber agregar un campo
Autonumrico para identificar el registro. Normalmente las descripciones son
tambin nicas.Para el actualizador de estas Tablas no se deber actualizar ni
mostrar el campo identificador.Para la exportacin a texto de esta Tabla se deber
exportar el campo identificador para tener la referencia a las Tablas que usen estos
datos de descripcin.Las excepciones implementadas en el Pampa son: Tabla Tipos
de Norma (DL09) y Tabla de Quien Emite Norma (DL10) NO tienen campo
identificador.

Campos

Los tipos no se incluyen en los nombres de los campos

En el caso de que la clave sea un nico campo y es autonumrico, creado
expresamente para ser clave; este ser denominado id_tabla (tabla es sin el prefijo
que identifica al sistema).
Toda clave primaria no autonumrica, con semntica dentro del dominio (por
ejemplo no CUIT), ser denominada cod_tabla.
Los siguientes campos tienen nombres predefinidos:
o id_tabla
o cod_tabla
o nom_tabla o desc_tabla
o obs_tabla
Los campos restantes no deberan incorporar el nombre de la tabla en su definicin.
Cada vez que se quiera crear un tipo fecha, cantidad, importe o porcentaje se
emplear el siguiente prefijo:
o fec_
o cant_
o imp_
o porc_
Los nombres de los campos de las claves extranjeras se propagan.

Nombres de constraints

Claves Primarias: pk_nombre_tabla (el nombre de la tabla con prefijo)

Claves Extranjeras: fk_origen_destino (origen con prefijo, si destino pertenece al
mismo mdulo, obviamos el prefijo). En la creacin se debe incluir la clusula
MATCH FULL para comprobar que todas las columnas tengan valor distinto de
nulo o ninguna de ellas.
Check: En el Standard SQL99 existe la sentencia CREATE ASSERTIONS que sirve
para crear restricciones a nivel base de datos pero Postgres no lo implementa. En
Postgres se pueden especificar estas restricciones usando RULES o TRIGGERS.
o checks a nivel columna: chk_nombre_tabla_nombre_de_check
o Checks a nivel tabla: En Postgres se pueden definir chequeos a nivel tabla
cuando se crea la tabla o con ALTER TABLE. En CaseStudio no se pueden

definir visualmente chequeos a nivel tabla. Al hacer ingeniera reversa,

levanta las restricciones pero las agrega en c/u de las columnas a las que se
refiere. Esto impide generar un script correcto porque el nombre no es nico.
Entonces decidimos utilizar en CaseStudio el siguiente mtodo: Escribir las
restricciones a nivel tabla en la parte destinada a TextObjects, seccin After.
De esta manera al generar el script copia literalmente todo lo que se haya
includo en esa seccin.
o checks a nivel base de datos
ndices: Postgres crea automticamente para cada clave primaria un ndice
denominado igual que dicha primary key. Postgres crea automticamente para cada
columna declarada como UNIQUE, un ndice nico llamado
nombre_tabla_nombre_columna_key

Si se crea manualmente el ndice nico (en CaseStudio) respeta ese nombre en la

generacin de errores. Detectamos dos casos: ndices que se usan para controlar unicidad e
ndices que se usan por motivos de performance. Decidimos NO utilizar la clusula
UNIQUE para poder controlar el nombre del ndice generado. Y en cuanto a la convencin
de nombres de ndices decidimos que el mismo contenga las columnas constituyentes con
el agregado del prefijo ix. En el caso de ser claves alternativas se agrega al prefijo la
palabra key. En el caso de las claves extranjeras, CaseStudio genera automticamente un
ndice que denomina IX_nombre_de_la_foreign_key (El nombre de la foreign key lo
habamos establecido como fk_nombre_de_la_relacin)

Autonumricos

Si en el CASE Studio definimos que el campo del id es de tipo Serial, cuando se

crea la tabla en Postgres al campo lo define como integer y genera solo una
secuencia como a continuacin:
CREATE SEQUENCE emb_juzgado_id_juzgado_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;

El nombre es nombre de tabla _ nombre del campo de tipo serial _ seq.

Por defecto incrementa de a uno, empieza en uno, tiene cache de uno.
Cuando hacemos ingeniera reversa, levanta la secuencia como objeto de texto.
Postgres permite modificar una secuencia como a continuacin:
ALTER SEQUENCE name
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ]

[ MAXVALUE maxvalue | NO
MAXVALUE ]
[ RESTART [ WITH ] start ]
[ CACHE cache ]
[ [ NO ] CYCLE ]

Dominios

Los dominios debern tener un nombre representativo del tipo de dato para el cual
son creados.
Se prob usar un dominio para definir un importe pero no es un conjunto cerrado
con respecto a la operacin divisin, as que se decide no utilizar dominios.

Tipos de Datos

Los tipos de datos definidos por el usuario (CREATE TYPE) en Postgres no se

adecan al Standard SQL99.
El tipo de dato MONEY est desaprobado y no se debe usar en siguientes versiones.

Usuarios de la Base y Grupos

Tendremos un esquema por sistema (create schema). La base de datos ser nica,
por ejemplo uncpba o siu.
Es necesario un usuario para conectarse a la base y que sea propietario de los
objetos de la misma que necesita el sistema. La solucin sera tener un usuario por
cada sistema (materializado como un usuario por cada esquema) con los
correspondientes permisos sobre sus objetos y sobre los objetos de otros sistemas a
los que deba acceder (ej. Grant references al crear foreign keys) El nombre de dicho
usuario debera ser el nombre del sistema.
No se emplearn grupos (tambin conocidos como roles) en este momento porque
no est definida la poltica de seguridad.

Triggers

La convencin que usa CaseStudio es t (de trigger) y u (update), d (delete) o i

(insert) con lo que queda: tu, td o ti seguido de _nombreTabla.
CaseStudio si tiene dos hijos hace un solo trigger con el cdigo para los dos.

Postgres permite mltiples triggers con el mismo evento-condicin y los ejectuta en orden
alfabtico.

Si tenemos varios podemos agregarle _nombreSignificativo (teniendo en cuenta

que se ejecutarn en orden alfabtico) o _numero_de_orden.

StoredProcedures

Para definir stored procedures en Postgres hay que definirlos como funciones.
Nombre sugerido: modulo_nombre_del_storedprocedure

Nombres de Vistas

El nombre de una vista debe comenzar con los tres caracteres correspondientes al
mdulo, seguido de _vista_, seguido del nombre de la vista propiamente dicho.
Si se van a utilizar vistas para realizar inserciones y/o actualizaciones sobre tablas
base, debe tenerse en cuenta en su definicin la clusula WITH CHECK OPTION
que controla que la fila insertada o actualizada permanezca en la vista.
En CaseStudio se registran como TextObjects.