Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SIU Mapuche ConvencionesBD
SIU Mapuche ConvencionesBD
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:
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
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:
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 1
CACHE 1;
[ 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
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.