1 #LyX 1.3 created this file. For more info see http://www.lyx.org/
11 \paperpackage widemarginsa4
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language english
25 \paperpagestyle default
29 Archivo sin bloques y registros de longitud variable
32 Este tipo de archivo nos traerá a la mesa la particularidad de grabar registros
33 de longitud variablesin realizar su agrupación en bloques, y como veremos
34 en la siguiente sección, tambien permitirá la administración de gaps que
35 queden en el archivo luego de operaciones de baja de registros.
41 Este tipo de archivo realizará el almacenamiento de registros de longitud
42 variable en disco, su borrado y modificación sin la utilización de bloques
44 Su implementación se encuentra en los archivos fuente (
57 Los archivos del tipo 2, presentarán al comienzo del mismo un header compuesto
58 simplemente por un dato del tipo EMUFS_Tipo (int) el cual indicará el tipo
59 de archivo en cuestión.
64 Para poder entender mejor la organización fisica de este tipo de archivo,
65 tomemos el caso hipotético en el que se encuentran grabados
69 (comenzando desde registro 0) de
78 Supongamos también que entre el registro 0 y 1 se encontraba un
95 Si miramos al archivo de datos (.DAT) en el disco nos encontraremos con
101 \begin_inset Graphics
102 filename graphics/Example1.png
111 Como se puede observar, a nivel físico cada registro grabado esta compuesto
112 por un Header cuyo tamaño total es de 8 bytes (
120 ), y posteriormente el registro (bloque de datos) en sí.
121 Luego se encuentra el espacio libre de 18 bytes dejado por el registro
122 de 10 bytes eliminado (10 bytes de datos + header de 8 bytes) y finalmente
123 el segundo registro mencionado.dsds
126 Comportamiento (funciones de la interfáz)
141 se encuentran las cabeceras y la implementación de las funciones principales
142 respectivamente, las cuales dan funcionalidad a esta organización.
146 A continuación se comentará el funcionamiento algunas de las mas importantes.
152 Como se vió al comienzo, los registros en este tipo de archivo no se encuentran
153 agrupados en bloques de ninguna índole y estan dispersos a lo largo del
154 archivo, con la particularidad de que pueden existir gaps o espacio libre,
155 entre dos registros dados.
160 Por ende la lectura de registros en este tipo de organización es muy simple
161 y dada la inexistencia de bloques, el procedimiento será el siguiente:
164 Se determina el offset en bytes, donde comienza el registro deseado, a través
165 de su ID, buscando la misma en el archivo índice (
172 Ya determinada la posición física del registro dentro del archivo de datos
177 ), nos posicionamos en la misma, y leemos el header del registro (
186 Contando así con el tamaño del registro, procedemos a leer el mismo (los
187 datos), dando por finalizada la lectura.
193 En el proceso de alta de registros entrarán en juego dos archivos descriptos
196 sección de archivos auxiliares
198 , siendo estos el archivo índice (
202 ), y el archivo de gaps / espacios libres (
212 Así pues, a la hora de realizar una inserción de un registro en el archivo
213 de datos, el procedimiento será el siguiente:
216 Calculamos el espacio que necesitaremos para el registro: sizeof(
224 ) + sizeof(registro).
227 Determinamos donde debemos insertar el registro, ya sea un gap donde entre,
228 o bien al final del archivo.
231 Insertamos el registro e información de control (
239 ), en la posición indicada en el paso 2.
242 En caso de haber utilizado un GAP, actualizamos el espacio libre restante
243 en el mismo y en caso de que se haya utilizado al totalidad del GAP, se
244 lo elimina del archivo (
251 Actualizamos la entrada correspondiente al registro ingresado (determinada
252 por su RegID), en el archivo índice (
256 ), indicando su offset donde podrá ser accedido luego.
262 En el proceso de baja de registros entrarán en juego los tres archivos descripto
265 sección de archivos auxiliares
267 , siendo estos el archivo índice (
271 ), el archivo de gaps / espacios libres (
275 ) y el archivo de ID's liberados (
284 Dado que en la implementación de este tipo de organización física contamos
285 con los gaps o espacios libres entre registros, no se eliminará fisicamente
286 el registro del archivo de datos (
290 ), pues entonces carecería de sentido el archivo anteriormente mencionado
296 En cambio, se agrega el gap dejado por la eliminación a dicho archivo,
297 y se marca fisicamente en el archivo de datos la eliminación mediante un
298 fill de los bytes correspondientes con un caracter nulo.
299 (hexa 00 y con el propósito de probar fehacientemente que el sistema funciona).
304 El proceso de baja o eliminación de un registro constará luego de los siguientes
308 Se obtiene el offset o posición relativa en donde se encuentra grabado el
309 registro dentro del archivo de datos.
312 Se obtiene el tamaño del registro y se realiza un dummyfill del sector del
313 archivo correspondiente al registro que se está dando de baja.
314 (Se rellena la zona correspondiente a su header+data).
317 Se agrega el GAP generado al archivo de gaps o espacios libres, y en caso
318 de haberse generado un GAP lindante con otro GAP, se realizará un merge
319 de los mismos y se los registrará bajo una única entrada en el archivo
320 de espacios libres (.fsc).
323 Se agrega el ID que fue liberado, al archivo de ID's liberados (
327 ), al final del mismo (
334 Se marca en el archivo índice (
338 ) la eliminación, mediante el valor ¨-1¨ en el registro correspondiente
339 al registro recién eliminado (se le cambia el valor al n-esimo registro,
340 donde N = IDReg del reg eliminado).
343 Modificación de registros
346 Dada la naturaleza del archivo de ID's liberados, y el manejo de espacio
347 libre del que consta esta organización de archivo, el proceso de modificación
348 de un registro se limita a los siguientes pasos:
351 Se realiza la lectura del registro, mediante el respectivo procedimiento
352 ya desarollado anteriormente.
355 Una vez que se cuenta con los nuevos datos modificados, se procede a dar
356 de baja el registro que ha sido modificado, e inmediatamente después se
357 realiza una inserción con los nuevos datos.
366 Como fue indicado, dada la naturaleza de PILA del subsistema de administración
367 de ID liberados, es asegurado que la nueva inserción del registro modificado
368 se realizará con el mismo RegID.
371 Obtención de estadísticas
374 Compactación del archivo de datos
377 Asi como los otros dos tipos de datos, el que nos compete también cuenta
378 con la posibilidad de realizar la compactación de datos cuando el usuario
379 lo desee, justificando todos los registros a izquierda, eliminando así
380 los gaps existentes y decrementando el tamaño del archivo en disco (truncandolo
384 Para poder comprender como hemos implementado el proceso de recompactación
385 en nuestro tipo de archivo 2, nos ayudaremos de esquemas a través de los
386 cuales iremos describiendo el proceso.
387 Notemos antes, que el proceso de compactación esta directamente ligado
388 con el archivo de gaps o espacios libres (
397 Comenzemos con el siguiente cuadro situacional:
402 \begin_inset Graphics
403 filename graphics/Compact1.png
414 Partiendo de esta base, el algoritmo de compactación tomará en su inicio
415 al primer gap existente dentro del archivo de datos, en este caso llamado
421 Luego, establecerá que el
425 a partir de donde se quieren mover datos, sera:
449 Lo cual no es nada más y nada menos que lo obvio, la fuente a partir de
450 donde se mueven los datos, sera el fin del primer gap, donde comienzan
456 ) del movimiento, se establece inicialmente, el inicio del gap, o sea
458 StartGap0 = Destination
463 Luego, el algoritmo entrara en un bucle while (mientras haya bucles por
464 levantar), el cual trabajara hasta el final de la compactación de la siguiente
477 Se levanta el proximo gap al levantado en una instancia previa.
478 En este ejemplo, durante el primer loop del while, se levantará
483 Luego, se calcula cuantos bytes hay que mover hacia el Destination de la
507 Lo cual nuevamente es lógico pues querremos mover lo que se encuentra entre
508 el final del primer gap levantado y el inicio del siguiente).
511 Se realiza el movimiento de los datos, utilizando las direcciones
519 , así como la variable
523 que nos indica cuantos bytes transferir.
532 La transferencia se hace de a chunks de 25 bytes + un resto segun el valor
536 Se establece como gap de referencia, al ultimo gap leido (En este caso se
549 ) y termina el código de repetición del bucle, dando lugar a la carga del
550 siguiente gap en el inicio del mismo.
560 Luego del primer bucle, el archivo se vera de la siguiente forma:
565 \begin_inset Graphics
566 filename graphics/Compact2.png
576 Notemos que al final de la porción de datos de los bytes movidos (donde
581 ), hay basura que será pisada por el próximo movimiento.
586 En el próximo loop, el bucle levantará un nuevo gap, y utilizando el gap
587 anterior (En esta caso el Gap anterior será
591 ) como referencia, realizará los mismos cálculos, desde donde transferir
592 y cuantos bytes mover.
593 (El destino es solo establecido inicialmente por código, y para el resto
594 del algoritmo es el lugar donde quedo el puntero destination luego de la
598 Una vez que se salga del bucle while, se realizará un último movimiento
599 preprogramado, donde la fuente (
603 ) será el final del ultimo gap, y la cantidad de bytes a mover será lo que
604 se encuentre luego del mismo hasta el fin de archivo.
611 Source = StartLastGap + SizeLastGap = EndLastGap
616 Mustmove_bytes = Datsize - Source
623 Damos por terminada así, la explicación del algoritmo de compresión el cual
624 para el caso del tipo 2, es realmente bastante sencillo.
627 Detalles de implementación (funciones internas, ver si lo ponemos o no)