Ficheros (I)
Cuando adquirimos
un compilador de Cobol, sin darnos cuenta a la vez estamos
obteniendo un completo administrador de ficheros, algo
que con otros lenguajes tienes que implementar con bases
de datos u otras herramientas externas.
No voy a entrar en la polémica de que es mejor,
si ficheros Cobol o Bases de datos, pero la experiencia
me permite decir que la fiabilidad, seguridad y potencia
de los ficheros es perfecta para nuestras aplicaciones
de gestión.
La
gran potencia sin duda, viene dada por los archivos
indexados y será sobre ellos sobre los que gire prácticamente
todo el tema, además con longitud fija. Los secuenciales se utilizan para la impresión
y para determinados procesos de exportación de datos,
pero cada uno es libre de utilizar el tipo de fichero
que desee.
En
la sección de Instrucciones relativas a ficheros tengo
una pequeña explicación sobre lo que es un fichero y
una clave y la voy a repetir aquí, porque nos viene
muy bien para comprender perfectamente como se comportan.
¿Que es un fichero? Podríamos
definir un fichero como un conjunto de registros, pero estaríamos mas o menos igual. Si
comparásemos un fichero de cobol con nuestra vieja agenda de teléfonos, para cada amigo
tendríamos los mismos datos, es decir, nombre, teléfono, dirección, etc ... cada uno de
esos datos es lo que llamamos campo y el conjunto de todos esos campos para cada amigo
sería un registro. Ahora podemos comprender mejor que un fichero o archivo es un conjunto
de registros, como una agenda es un conjunto de datos de amigos.
¿Que es una clave? Una clave, es
un campo de nuestra agenda que nos sirve para identificar a cada amigo, en la agenda
normal la clave podría ser la lengüeta con la letra del abecedario correspondiente a los
apellidos del amigo. Informáticamente es mas completa y con ella podremos identificar a
cada uno de ellos, por ejemplo con su nombre o su teléfono o un código que le asignemos
nosotros personalmente.
Algunos tipos de ficheros indexados, dividen el fichero en dos
archivos físicos, uno para las claves y otro para los
datos, otros en cambio lo guardan todo en uno mismo,
pero eso no significa que no lo haga igual, sino que
al usuario solo le muestra un fichero físico, que puede
resultar mas cómodo.
Cuando
se graba un nuevo registro, éste se ordena automáticamente
en orden ascendente por la clave principal. Luego podremos modificar
tantas veces como deseemos los datos, pero la clave
nunca se podrá alterar. Si queremos cambiar la clave,
tendremos que borrar el registro y grabar otro con la
clave deseada. De esa manera Cobol se asegura el perfecto
funcionamiento de su sistema de índices.
La
parte de índices es como una tabla con las posiciones
de memoria de los datos que le corresponden. Si el fichero
está abierto en modo I-O y se produce una salida brusca
del programa o un corte de luz, puede ocurrir que esa
información sobre los datos que corresponden a cada
índice se alteren y de ahí el famoso y terrible error
98. Por eso yo siempre aconsejo tener nuestro fichero
abierto solo como Input y abrirlo como I-O solo en el
preciso momento de grabar o borrar su contenido.
Lo
realmente importante para Cobol cuando crea un fichero,
es el tamaño del registro y el de la clave en bytes. El
resto le da igual, incluso la estructura se puede
definir de maneras totalmente diferentes.
Para Cobol,
si generamos un fichero con un registro de 128 posiciones, eso es lo que guarda,
si nosotros le indicamos que el nombre ocupa 40 y comienza
en la posición 18 perfecto, pero si la próxima vez le
indicamos otra estructura el también la aceptará.
Un
ejemplo, antes de entrar mas en materia:
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT
FICHERO ASSIGN TO RANDOM "FICHERO.DAT"
ORGANIZATION
INDEXED ACCESS DYNAMIC
RECORD
KEY KEYAGE.
DATA DIVISION.
FILE
SECTION.
FD FICHERO
LABEL RECORD STANDARD.
01 REGAGE.
02
KEYAGE.
03
CAMPOCODIGO PIC 9(4).
02
CAMPONOMBRE PIC
X(30).
02
CAMPOPOBLACION PIC
X(20).
|
Suponemos
que CAMPONOMBRE = 'UN NOMBRE CUALQUIERA'
CAMPOCODIGO
= 1001
CAMPOPOBLACION
= 'UNA LOCALIDAD'
Ahora en otro programa cambiamos la estrutura a por ejemplo:
|
FD FICHERO
LABEL RECORD STANDARD.
01 REGAGE.
02
KEYAGE.
03
CAMPOCLAVE1 PIC 999.
03
CAMPOCLAVE2 PIC
9.
02
CAMPODATO1 PIC
X(10).
02
CAMPODATO2 PIC
X(15).
02
CAMPODATO3 PIC
X(25).
| Como
veis, los tamaños son igual la clave sigue
teniendo 4 y el registro 54 pero la estructura
ha cambiado. Si ahora le decimos que nos
displaye el mismo registro obtendríamos
lo siguiente:
CAMPOCLAVE1
= 100
CAMPOCLAVE2
= 1
CAMPODATO1
= 'UN NOMBRE '.
CAMPODATO2
= 'CUALQUIERA '.
CAMPODATO3
= ' UNA LOCALIDAD'.
He
puesto este ejemplo, porque muchas veces aprendemos las cosas tan literalmente que
pensamos que cambiar algo puede provocar errores.
|
CLAVES ALTERNATIVAS
Las claves alternativas, nos dan la posibilidad de acceder
al fichero indexado por mas de un índice, con lo que la rapidez de acceso se incrementa muchísimo.
¿Por que son necesarias ?
Imaginemos un fichero de ventas, cuya clave es el número de factura, pero en su registro también guardamos
la fecha, el cliente, el artículo, etc ..... Si ahora quisieramos listar todos los registros de ventas
relativos a un solo clientes y no existieran las claves alternativas, tendríamos que leer todo el fichero
para saber de que cliente es cada factura e imprimir solo esos registros.
Pues
bien, con este tipo de claves lo que hacemos es posicionarnos directamente en el cliente en concreto y leer secuencialmente
por esa clave, con lo cual tendremos una relación
de todas sus facturas directamente hasta que el cliente
cambie. En los ejemplos que pondré en esta sección
intentaré que se vea todo esto.
En
la actualidad, las claves alternativas se definen de
manera diferente y no hacen la información redundante,
es decir, antes, si creábamos una clave alternativa,
había que implementar en el registro dicha clave,
con lo que repetiamos los datos y hacíamos el
registro de mayor longitud. Hoy en día eso no
es necesario y las claves se pueden definir en la propia
SELECT con lo cual evitamos la repetición de
campos, espacio y además ganamos en comodidad,
sencillez y comprensión.
Veamos que es lo que he dicho:
ANTES:
SELECT FICHERO ASSIGN TO RANDOM 'FICHERO.DAT
ORGANIZATION
INDEXED ACCESS DYNAMIC
RECORD KEY
CLAVE
ALTERNATE RECORD KEY CLAVE1
WITH DUPLICATES
FILE STATUS STA-FICHERO.
FD
FICHERO LABEL RECORD STANDARD.
01
REG-FICHERO.
02
CLAVE.
03
CODIGO PIC 9(5).
02
NOMBRE PIC
X(30).
02
DOMICILIO PIC X(30).
02
POBLACION PIC X(20).
02
CLAVE1.
03
NOMBRE1 PIC X(30).
| Fijaros
como tenemos que repetir dos campos, ocupando
mas espacio y teniendo siempre cuidado de
que ambos estén actualizados a la vez.
|
AHORA:
SELECT
FICHERO ASSIGN TO RANDOM 'FICHERO.DAT
ORGANIZATION
INDEXED ACCESS DYNAMIC
RECORD KEY
CODIGO
ALTERNATE RECORD KEY NOMBRE
WITH DUPLICATES
FILE STATUS STA-FICHERO.
FD
FICHERO LABEL RECORD STANDARD.
01
REG-FICHERO.
02
CODIGO PIC 9(5).
02
NOMBRE PIC
X(30).
02
DOMICILIO PIC X(30).
02
POBLACION PIC X(20).
|
Todo es mucho mas claro, la definición
de los ficheros se asemeja mas a los relativos
y en la SELECT es donde se describen las
claves. Si la clave fuera compuesta, es
decir con mas de un campo, haríamos
lo siguiente:
RECORD
KEY CLAVE = CODIGO, NOMBRE
Si
tuvieramos que hacer un START nos dirigiriamos
por la palabra CLAVE, como ese conjunto
de campos.
|
Aquí
termina la primera parte del tema. Antes de continuar,
es necesario tener claro todo lo aquí expuesto
e igualmente si alguien tiene alguna queja o comentario
al respecto que me lo haga llegar.
Siempre
me gusta recordaros que yo soy un programador mas, al
igual que vosotros y por lo tanto, con las mismas dudas,
inquietudes y meteduras de pata.
Continuará...
|
|