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.