Convenciones de nombres de Base de Datos

Convenciones de nombres de Base de
Datos
General



Se emplearán siempre caracteres en minúscula 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 símbolo “_”, no se utilizarán otras preposiciones.
También 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/módulo que primero las precisa
Para el nombre de la misma se adopta la convención de emplear: xxx_tabla donde
xxx identifica al sistema/módulo que la creó.
En relaciones m x n entre tabla1 y tabla2, el nombre adoptado para la tabla que
representa a la relación 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.
Codificación en la descripción:
Salida (S) : Son las tablas utilizadas para
emitir información 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.)
Codificación (C) : Son las tablas que se
proveen en función 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.)

Creación de tablas de Tipologías: Para el caso de Tablas que solamente contengan
Descripciones (por ejemplo Tabla de Motivos) se deberá agregar un campo
Autonumérico para identificar el registro. Normalmente las descripciones son
también únicas.Para el actualizador de estas Tablas no se deberá actualizar ni
mostrar el campo identificador.Para la exportación a texto de esta Tabla se deberá
exportar el campo identificador para tener la referencia a las Tablas que usen estos
datos de descripción.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 autonumérico, creado
expresamente para ser clave; este será denominado id_tabla (tabla es sin el prefijo
que identifica al sistema).
Toda clave primaria no autonumérica, con semántica 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 deberían incorporar el nombre de la tabla en su definición.
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 módulo, obviamos el prefijo). En la creación se debe incluir la cláusula
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 ingeniería 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 método: Escribir las
restricciones a nivel tabla en la parte destinada a TextObjects, sección After.
De esta manera al generar el script copia literalmente todo lo que se haya
incluído en esa sección.
o checks a nivel base de datos
Índices: Postgres crea automáticamente para cada clave primaria un índice
denominado igual que dicha primary key. Postgres crea automáticamente 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
generación 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 cláusula
UNIQUE para poder controlar el nombre del índice generado. Y en cuanto a la convención
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 automáticamente un
índice que denomina IX_nombre_de_la_foreign_key (El nombre de la foreign key lo
habíamos establecido como fk_nombre_de_la_relación)
Autonuméricos

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 continuación:
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 ingeniería reversa, levanta la secuencia como objeto de texto.
Postgres permite modificar una secuencia como a continuación:
ALTER SEQUENCE name
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ]
[ MAXVALUE maxvalue | NO MAXVALUE
]
[ RESTART [ WITH ] start ]
[ CACHE cache ]
[ [ NO ] CYCLE ]
Dominios


Los dominios deberán 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 operación división, así que se decide no utilizar dominios.
Tipos de Datos


Los tipos de datos definidos por el usuario (CREATE TYPE) en Postgres no se
adecúan 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 solución sería 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 debería ser el nombre del sistema.
No se emplearán grupos (también conocidos como roles) en este momento porque
no está definida la política de seguridad.
Triggers


La convención 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 código para los dos.
Postgres permite múltiples triggers con el mismo evento-condición y los ejectuta en orden
alfabético.

Si tenemos varios podemos agregarle “_nombreSignificativo” (teniendo en cuenta
que se ejecutarán en orden alfabético) 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
módulo, 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 definición la cláusula WITH CHECK OPTION
que controla que la fila insertada o actualizada permanezca en la vista.
En CaseStudio se registran como TextObjects.