Cómo construir formatos para validación de registros
En el menú principal de catalogación, bajo Modificar la definición de una base de datos se encuentra la opción Validación de registros la cual permite construir estrategias de validación utilizando el lenguaje de formatos del CISIS.
Si la estructura de la base de datos contempla diferentes tipos de registro, puede construir un formato que se aplicará a un tipo de registro en particular. El formato que se construya como General aplicará cuando no existen tipos de registro o para aquellos tipos de registro para los cuales no se haya definido formato de validación.
Seleccione la opción Validación de registros y a continuación seleccione el vínculo correspondiente al tipo de formato que desea crear.
Se presenta una ventana que contiene tres columnas:
- La primera columna contiene la lista de los campos de la base de datos
- La segunda columna presenta una caja de texto para crear/editar el formato de validación. Este formato de validación debe construirse de forma tal que produzca un literal explicativo del error cuando la condición del error se cumpla
Ejemplo: if a(v20) then 'Falta campo 20' fi
Cuando el formato aplicado sobre el registro produce un literal de salida entonces se
asume que se produjo un error
- La tercera columna indica si la condición que establece el formato es una advertencia o un error fatal
Una advertencia presenta al operador el mensaje de error acompañado de tres vínculos que permitirán
*Editar el registro
*Salvar el registro
*Anular la edición del registro
Un error fatal presenta al operador el mensaje de error con un vínculo para editar de nuevo el registro
El formato de validación puede incluir tantos campos como se desee y utilizar cualquiera de los comandos del lenguaje de formatos de CISIS (ver Manual del lenguaje de formatos del CISIS
Formato para detectar campos obligatorios
Formato de validación de duplicados Para explicar el proceso de validación de duplicados usaremos como ejemplo el campo del ISBN (tag 20 en las estructuras MARC). La validación de duplicados consiste en ubicar si ya existe en la base de datos otro registro con igual valor que el campo en proceso de validación. La forma más directa de realizar este proceso es a través de una búsqueda en la lista invertida. Si ya existe un término igual, entonces podemos asumir que el campo está duplicado.
Sin embargo, ésto no es totalmente cierto, ya que en el proceso de edición de registros ya los campos han sido indizados en la base de datos por lo cual, al ya existir la clave, podríamos tener una condición de falso duplicado. Por ello hay que tomar ciertas previsiones para que nuestro formato cubra todas las posibilidades.
Por otra parte, cuando se crea un nuevo registro, la validación se realiza sobre un registro virtual, por cuanto no existe un registro real. Por definición, el MFN de los registros virtuales tiene el valor 1, por lo que también hay que tomar ciertas previsiones para distinguir entre el MFN 1 del registro real y el MFN 1 del registro virtual.
El proceso de validación de registros siempre se realiza sobre un registro virtual por lo que nos toca tomar previsiones para diferenciar si estamos aplicando la validación sobre un registro nuevo o sobre un registro ya existente. El lenguaje de formateo provee el comando MFN para determinar el número mfn del registro que se está procesando. Como ya dijimos, no podemos utilizar esta facilidad ya que siempre nos devolvería 1, valor del MFN en el registro virtual.
Tomando en cuenta estos factores procederemos a desarrollar un formato para validación de duplicados.
Con la función L del lenguaje de formateo podemos determinar si ya existe en la lista invertida otro registros con la clave de búsqueda suministrada. Esta función devuelve el MFN del primer registro que contenga la clave solicitada. Si el ISBN está indizado con el prefijo IS_, tendríamos:
If L('IS_'v20)<>0 then 'ISBN duplicado' fi
Como la validación se realiza sobre un registro virtual, es necesario suministrar en la función L el nombre de la lista invertida sobre la cual se va a aplicar la búsqueda
If L(['marc'] 'IS_'v20)<>0 then 'ISBN duplicado' fi
Este formato funciona en creación de registros, pero no en la modificación, ya que el ISBN ya existe en la lista invertida. Por lo tanto la función L retornaría el MFN del registro que se está modificando.
Esto nos dice que necesitamos comparar el MFN que nos devuelve la función L contra el MFN del registro que estamos procesando para determinar si ambos coinciden, lo cual anularía la condición de error.
if l(['marc']|IS_|v20^a) <> 0 then
if l(['marc']|IS_|v20^a)<>MFN then 'ISBN duplicado', fi
fi
Como ya dijimos que la validación opera sobre un registro virtual, y el MFN de un registro virtual es siempre uno (1), la fórmula antes mencionada no produce ningún resultado confiable ya que la función L siempre retornaría 1.
Para manejar esta circunstancia, cuando ABCD activa el proceso de validación, coloca en el campo 3333 el valor 0 si se trata de un registro nuevo, o el MFN del registro si se trata de un registro en proceso de edición. Por lo tanto, podemos expresar nuestro formato de validación de la siguiente manera:
if l(['marc']|IS_|v20^a) <> 0 then
if l(['marc']|IS_|v20^a)<>val(v3333) then 'ISBN duplicado', fi
fi
De esta forma estamos verificando que no exista ningún registro con la clave solicitada y además que, en caso de existir, que el MFN del registro recuperado no sea igual al MFN del registro que se está procesando.
Si deseamos restringir la validación de duplicados solo en el caso de creación de registros, el formato para validación de duplicados quedaría:
if val(v3333)=0 then if l([‘marc’]|IS_|v20^a) <> 0 then ‘ISBN duplicado’ fi fi
Ejemplo de validación del número de control duplicado:
if val(v3333)=0 then if l([‘marc’]|CN_|v2) <> 0 then ‘Control, duplicado ‘,v2 fi fi
Formato de validación de duplicados (FDT) Esta opción de validación de duplicados la realiza internamente ABCD y es más eficiente para el caso de campos repetibles, por ejemplo, el número de inventario cuando las existencias se ingresan directamente en el registro catalográfico (no se usa la base de datos de copias).
Se verifica que el valor no esté repetido en otra ocurrencia del mismo campo repetible, así como que no esté ingresado en otro registro.
Para activar esta opción siga los siguientes pasos:
Edite la FDT o el formato de entrada respectivo y en la línea correspondiente al campo, o subcampo, en caso de que se desee validar un subcampo en particular, seleccione en la columna “Validación” la opción “Clave única” Coloque en la columna correspondiente a “Prefijo” el prefijo de la fst a ser utilizado para acceder a la indizacion del campo Con esta información ABCD ejecutará un proceso utilizando como referencia el tag del campo, y el subcampo, en caso de que la validación se realize a ese nivel, y verificará si el valor del campo no está en otra ocurrencia del campo (si fuera repetible), y que la clave de búsqueda formada con el prefijo y el valor del campo, o subcampo, no se encuentre en otro registro de la base de datos.
Se emitirá el mensaje de error correspondiente y el registro no podrá ser almacenado hasta tanto no se corrija la inconsistencia.
Formato para condicionar la eliminación de registros
Las condiciones para la eliminación de registros se establecen en un formato especial que permite determinar si un registro puede, o no, ser eliminado de la base de datos.
Se almacena en la carpeta pft/xx de la base de datos activa, bajo el nombre recdel_val.pft
Si el formato existe, se aplica sobre el registro antes de eliminarlo y si devuelve algún mensaje entonces se cancela la eliminación del registro. Si el formato no existe, no procede la validación de la eliminación
En el esquema de manejo de la base de datos Marc en ABCD, la validación de la eliminación de registros puede utilizarse para asegurar la consistencia entre las bases de datos de registro bibliográfico, copias, objetos de préstamo, usuarios y transacciones de préstamo
A No se debe eliminar un registro bibliográfico si tiene copias
B No se deben eliminar copias si están habilitadas para préstamo
C No se deben eliminar las copias habilitadas para préstamo si tienen transacciones pendientes
D No se deben eliminar usuarios si tienen transacciones pendientes
No eliminar el registro bibliográfico si tiene copias
La base de datos bibliográfica tiene definido un campo Número de control el cual se transfiere a la base de datos de copies, conjuntamente con el nombre de la base de datos activa, cada vez que se agrega una nueva copia al registro bibliográfico. En la FST de la base de datos copias existe una clave de indización que contempla el número de control y el nombre de la base de datos. Esta clave relaciona las copias con los registros biblográficos con los cuales están vinculados.
Para validar la eliminación del registro bibliográfico puede construirse el siguiente formato:
if npost(['copies'],'CN_biblo_'v2)>0 or
npost(['loanobjects'],'CN_'v10'_'v1)>0 then 'Error'
fi/
En el cual se verifica si hay registros vinculados en la base de datos copies o en la base de datos loanobjects. Tanto copies como loanobjects deben estar incluídas en el archivo .par de la base de datos activa.
El formato recdel_val.pft se almacena en la carpeta pfts de la base de datos bibliográfica activa. El archivo .par de la base de datos activa debe incluir los caminos de acceso hacia las bases de datos copies y loanobjects, de la siguiente manera:
copies.*=%path_database%copies/data/copies.*
loanobjects.*=%path_database%loanobjects/data/loanobjects.*
No eliminar las copias si están habilitadas para préstamo
La base de datos loanobjects contiene, para cada registro bibliográfico, un registro contentivo de las copias que están habilitadas para préstamo. En esta base de datos las copias habilitadas se expresan en la forma de un campo repetible con subcampos. Si existe en loanobjects un registro con igual número de inventario que la copia que se desea eliminar, entonces no debe proceder la eliminación de la copia. Note que no nos sirve hacer la validación por el número de control ya que un registro de loanobjects referencia todas las copias habilitadas para préstamo y tenemos que determinar la información para una copia en específico.
Para validar la eliminación de las copias puede construirse el siguiente formato de validación:
if npost(['loanobjects'],'IN_'v30)>0 then 'Error' fi/
El formato recdel_val.pft debe estar localizado en la carpeta pfts de la base de datos copies. El archivo .par de la base de datos copies debe contener el camino de acceso a la base de datos loanobjects, de la siguiente manera:
loanobjects.*=%path_database%loanobjects/data/loanobjects.*
No eliminar las copias habilitadas para préstamo si tienen transacciones pendientes
Si una copia habilitada para préstamos (loanobjects) está prestada a algún usuario (trans), no puede proceder su eliminación hasta que se produzca la devolución del préstamo
En la base de datos de transacciones el campo 1 indica la situación del préstamo:
P=prestado
X=devuelto.
Entonces, para que la eliminación de un registro de loanobjects pueda realizarse, no puede haber ningún registro prestado con el número de control del registro que se quiere eliminar. Por ello el formato de validación:
if npost(['trans'],"ON_P_"v1)>0 then 'Error' fi
Nos determina si existen registros prestados en la base de datos de transacciones con el número de control del registro de loanobjects que deseamos eliminar. Este formato se almacena en la carpeta def de la base de datos loanobjects, bajo el nombre recdel_val.pft. Se debe incluir en el archivo loanobjects.par el camino de acceso hacia la base de datos trans, en la forma:
trans.*=%path_database%trans/data/trans.*
No eliminar usuarios si tienen transacciones pendientes
Para eliminar un usuario debe verificar primero si tiene préstamos pendientes
Para estos efectos se puede acceder el archivo de transacciones, utilizando como clave aquella que refleja los préstamos pendientes por código de usuario. Bajo estas condiciones, el formato de validación sería:
If npost(['trans'],'TRU_P_'if p(v20) then v20 else v35 fi)>0 then 'Error' fi/
Este formato de validación debe estar incluido en la carpeta pfts de la base de datos users bajo el nombre recdel_val.pft. Además, en users.par debe incluirse el camino de acceso hacia la base de datos de transacciones, en la forma: trans.=%path_database%trans/data/trans.
Validacion javascript
La definición de la Tabla de Definición de campos o de las hojas de ingreso contiene las siguientes columnas que usará ABCD para construir funciones JavaScript para validar el ingreso desde el cliente. Estas columnas son:
Req? | Si se marca esta columna el campo se considera obligatorio (requerido) y su ausencia causa la emisión de un mensaje que persiste hasta tanto se suministre la información solicitada |
---|---|
Tipo de validación | Alfabético el campo solo admite caracteres alfabéticos. El espacio, signos de puntuación y otros caracteres no son considerados alfabéticos Alfanumérico el campo admite cualquier tipo de caracter: letras, números, espacios, signos de puntuación y caracteres especiales Fecha <=Fecha mayor o igual a la fecha del día Fecha Cualquier fecha Decimal-coma Decimal separado con coma. No se debe incluir separador de cientos o miles Decimal-punto Decimal separado con punto. No se debe incluir separador de cientos o miles Entero Los números del 0-9 Patrón Se suministra un patrón de ingreso contra el cual se validará cada posición del campo ingresado |
Patrón | Si el tipo de validación corresponde a Patrón. Para construir el patrón tome las siguientes consideraciones:A ó a significa que en esa posición va un caracter alfabético 9 significa que en esa posicion va un caracter numérico Cualquier otro caracter significa que en esa posición va el caracter especificado.Ejemplo: 9999-999A significa que las 4 primerós caracteres son numéricos, seguidos por un guion, luego 3 caracteres numéricos y 1 caracter alfabético |