Apuntes

UNIVERSIDAD DE ALMERIA
Escuela Polit ecnica Superior Ingenier a T ecnica en Inform atica de Gesti on
Organizaci on y Gesti on de Archivos

Area : Ciencias de la Computaci on e Inteligencia Articial Departamento: Lenguajes y Computaci on
Antonio Aliaga Munoz

web: http://www.ual.es/personal/analiaga e-mail: analiaga@ual.es 14 de febrero de 2006
Indice general
I Almacenando informaci on: discos y archivos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3 3 4 6 6 6 7 7 8 9 9 10 10 13 13 13 14 14 15 15 17 17 18 18 19 19 19 20
1. Almacenamiento de datos 1.1. Jerarqu a de memoria . . . . . . . . . . . . . . . . . . . . 1.2. Introducci on hist orica . . . . . . . . . . . . . . . . . . . . 1.3. Discos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1. Tipos de discos . . . . . . . . . . . . . . . . . . . 1.3.2. Organizaci on de los discos . . . . . . . . . . . . . 1.3.3. Capacidad del disco . . . . . . . . . . . . . . . . 1.3.4. Organizaci on de pistas por sectores . . . . . . . . 1.3.5. Organizaci on de las pistas por bloques . . . . . . . 1.3.6. Espacio reservado o de control (nondata overhead) 1.3.7. El coste del acceso a disco . . . . . . . . . . . . . 1.3.8. El disco como cuello de botella . . . . . . . . . . 1.4. Cintas magn eticas . . . . . . . . . . . . . . . . . . . . . . 2. Archivos 2.1. Archivos f sicos y archivos l ogicos . . . . . 2.2. Operaciones principales sobre archivos . . . 2.2.1. Abrir archivos . . . . . . . . . . . 2.2.2. Cerrar archivos . . . . . . . . . . . 2.2.3. Leer y escribir en archivos . . . . . 2.2.4. Posicionamiento (seek) en archivos
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
3. Elementos b asicos de las estructuras de archivos 3.1. Estructuras de campos . . . . . . . . . . . . . . . . . . . . 3.1.1. Campos de longitud ja . . . . . . . . . . . . . . . 3.1.2. Comenzar cada campo con un indicador de longitud 3.1.3. Utilizar un delimitador al nal de cada campo . . . . 3.1.4. Utilizar una expresi on . . . . . . . . . . . . . . . . 3.2. Estructuras de registros . . . . . . . . . . . . . . . . . . . . 3.2.1. Registros de longitud ja en n umero de bytes . . . .
I
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
2o I.T.I.G./UAL
Indice general 20 21 21 21 21 21 23 25 25 28 28 29 29 30 31 33 33 34 34 36 37 38 39 39 42 42 43 44 46 47 48 49
3.2.2. Registros de longitud ja en n umero de campos . . . . . . . . . . 3.2.3. Comenzar cada registro con un indicador del n umero de bytes de longitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4. Utilizar un archivo auxiliar donde se indica la posici on de inicio de cada registro . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5. Utilizar un delimitador al nal de cada registro . . . . . . . . . . 3.3. Buffers y bloques de registros . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Operaciones sobre registros. Fragmentaci on del almacenamiento . . . . . 3.4.1. La inserci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. El borrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3. La actualizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Acceso a registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1. Llaves de b usqueda . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2. B usqueda iterativa de un registro en un archivo (b usqueda secuencial) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3. Acceso directo e ndices . . . . . . . . . . . . . . . . . . . . . . 4. Organizaciones b asicas de registros en archivos 4.1. Archivos de registros no ordenados: Organizaci on apilada . . 4.1.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . 4.1.2. No estructurados . . . . . . . . . . . . . . . . . . . 4.1.3. Estructurados . . . . . . . . . . . . . . . . . . . . . 4.1.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . 4.2. Archivos de registros ordenados: Organizaci on secuencial . . 4.2.1. Estructura de la organizaci on secuencial . . . . . . . 4.2.2. Manipulaci on de los archivos secuenciales . . . . . 4.2.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . 4.3. Archivos con registros enlazados: Organizaci on encadenada 4.3.1. Estructura de las cadenas . . . . . . . . . . . . . . . 4.3.2. Manipulaci on de los archivos encadenados . . . . . 4.4. Archivos relativos (hashing): Organizaci on directa . . . . . 4.4.1. Hashing est atico cerrado . . . . . . . . . . . . . . . 4.4.2. Manipulaci on de los archivos hash . . . . . . . . . . 4.4.3. Hashing abierto . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
II
Indexaci on
51
53
II
5. Conceptos b asicos sobre ndices Organizaci on y gesti on de archivos
2o I.T.I.G./UAL
Indice general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 53 53 54 54 55 55 56 56 57 57 57 57 58 58 59 59 59 60 60 60 61 61 61 62 62 63 64 66 67 67 68 68 69 70 73 73 74
5.1. Archivos con ndices . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Denici on . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2. Estructura de los ndices . . . . . . . . . . . . . . . . . . 5.2. Propiedades de los ndices . . . . . . . . . . . . . . . . . . . . . 5.2.1. Indices agrupados y no-agrupados (clustered/unclustered) 5.2.2. Indices densos y dispersos (dense/sparse) . . . . . . . . . 5.2.3. Indices primarios y secundarios . . . . . . . . . . . . . . 5.2.4. Indices sobre claves m ultiples . . . . . . . . . . . . . . . 5.2.5. Indices multinivel . . . . . . . . . . . . . . . . . . . . . .
6. Organizaciones indexadas 6.1. Organizaci on secuencial indexada . . . . . . . . . . . . . . . . . . . . . 6.2. Organizaci on indexada simple . . . . . . . . . . . . . . . . . . . . . . . 6.3. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4. El acceso a los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5. Operaciones b asicas en un ndice . . . . . . . . . . . . . . . . . . . . . . 6.5.1. Creando los archivos . . . . . . . . . . . . . . . . . . . . . . . . 6.5.2. Leer el ndice en memoria . . . . . . . . . . . . . . . . . . . . . 6.5.3. Guardando el ndice en disco . . . . . . . . . . . . . . . . . . . . 6.5.4. Inserci on de registros . . . . . . . . . . . . . . . . . . . . . . . . 6.5.5. Borrado de registros . . . . . . . . . . . . . . . . . . . . . . . . 6.5.6. Actualizaci on de registros . . . . . . . . . . . . . . . . . . . . . 6.5.7. Indices que no caben en memoria . . . . . . . . . . . . . . . . . 6.6. Indices secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1. Denici on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.2. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.3. Operaciones b asicas . . . . . . . . . . . . . . . . . . . . . . . . 6.6.4. La recuperaci on de registros utilizando una combinaci on de claves secundarias . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.5. Mejorando la estructura del ndice secundario. Listas invertidas . 6.7. Binding: Enlazando o vinculando . . . . . . . . . . . . . . . . . . . . . . rboles B y B+ 7. Reorganizaci on multinivel con a 7.1. Introducci on . . . . . . . . . . . . . . . . . 7.2. Planteamiento del problema . . . . . . . . 7.3. Arboles binarios de b usqueda . . . . . . . . 7.4. Arboles AVL (Adelson-Velskii-Landis) . . . 7.5. Arboles binarios paginados . . . . . . . . . 7.6. Arboles-B . . . . . . . . . . . . . . . . . . 7.6.1. Denici on . . . . . . . . . . . . . . 7.6.2. Operaciones . . . . . . . . . . . . . Organizaci on y gesti on de archivos
III
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
2o I.T.I.G./UAL rbol-B . . . . . . . . . . 7.6.3. Organizaci on del ndice en a rboles-B: a rboles-B* . . . . . . . . . . . 7.6.4. Variantes de a 7.7. Arboles-B+ . . . . . . . . . . . . . . . . . . . . . . . . . . . rboles-B+: a rboles-B+ de prejo simple 7.7.1. Variantes de a rboles-B+ . . . . . . . . . . . . . . . . . 7.8. Arboles-B frente a a 8. Organizaci on directa. Hashing 8.1. Caracter sticas de la organizaci on hashing . . . . . . . . . 8.2. Elementos que intervienen en la organizaci on hashing . . . 8.2.1. Los cubos o unidades de direccionamiento . . . . 8.2.2. La densidad de empaquetamiento . . . . . . . . 8.2.3. La funci on hash . . . . . . . . . . . . . . . . . . . 8.2.4. Tratamiento de las colisiones . . . . . . . . . . . . 8.3. Hashing est atico . . . . . . . . . . . . . . . . . . . . . . . 8.3.1. Algoritmos hashing . . . . . . . . . . . . . . . . . 8.3.2. T enicas para evitar colisiones . . . . . . . . . . . 8.3.3. T ecnicas de resoluci on de colisiones. Operaciones 8.4. Hashing din amico . . . . . . . . . . . . . . . . . . . . . . 8.4.1. Caracter sticas . . . . . . . . . . . . . . . . . . . 8.4.2. Hashing extensible . . . . . . . . . . . . . . . . .
Indice general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 79 80 81 82 85 85 86 86 87 87 88 88 88 89 90 92 92 93
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Organizaci on y gesti on de archivos
IV
Indice de guras
1.1. Esquema interno de un disco magn etico. . . . . . . . . . . . . . . . . . . 1.2. Interleaving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. Formas de estructurar un archivo en campos. . . . . . . . . . . . . . . . . Formas de estructurar un archivo en registros. . . . . . . . . . . . . . . . Algoritmo de lectura de un archivo con buffer. . . . . . . . . . . . . . . . Algoritmo de escritura de un archivo con buffer. . . . . . . . . . . . . . . Inserci on de un registro en un bloque no-ordenado. . . . . . . . . . . . . Inserci on de un registro en un bloque ordenado con espacio. . . . . . . . Inserci on de un registro en un bloque ordenado sin espacio. Bloque de overow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8. Inserci on de un registro en un bloque ordenado sin espacio. B usqueda en el bloque vecino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9. Borrado de un registro con lista de espacio libre. . . . . . . . . . . . . . . 3.10. B usqueda secuencial en archivos no-bloqueados. . . . . . . . . . . . . . 3.11. B usqueda secuencial en archivos bloqueados. . . . . . . . . . . . . . . . Organizaci on apilada no-estructurada . . . . . . . . . . . . . . . . . . . Organizaci on apilada estructurada con registros de longitud variable. . . . Organizaci on secuencial con registros de longitud variable. . . . . . . . . Organizaci on secuencial. Inserci on de un nuevo registro. . . . . . . . . . Organizaci on secuencial. Inserci on de un nuevo registro en un archivo de derrama. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Organizaci on encadenada. . . . . . . . . . . . . . . . . . . . . . . . . . 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. Arboles binarios de b usqueda . . . . . . . . Arboles AVL . . . . . . . . . . . . . . . . Arboles binarios paginados . . . . . . . . . Arboles binarios paginados (desbalanceo) . Arboles-B . . . . . . . . . . . . . . . . . . Arboles-B (eliminaci on simple en una hoja)
V
7 8 18 20 22 23 26 26 27 27 28 30 31 35 36 38 39 40 45 69 70 71 72 75 77
4.1. 4.2. 4.3. 4.4. 4.5.
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
2o I.T.I.G./UAL 7.7. 7.8. 7.9.
Indice de guras 78 78 79
Arboles-B (eliminaci on simple en un nodo intermedio) . . . . . . . . . . Arboles-B (eliminaci on: redistribuci on) . . . . . . . . . . . . . . . . . . Arboles-B (eliminaci on: concatenaci on) . . . . . . . . . . . . . . . . . .
VI
Parte I Almacenando informaci on: discos y archivos
Cap tulo 1 Almacenamiento de datos

El problema clave del dise no de estructuras de archivos es la gran cantidad de tiempo que se necesita para obtener la informaci on desde el disco. Todos los dise nos de estructuras de archivos se centran en minimizar los accesos a disco y en maximizar la probabilidad de que la informaci on que el usuario necesita est e ya en la RAM. Por lo tanto, el problema principal consiste en encontrar f ormulas que minimicen los accesos a disco para los archivos que cambien de contenido y tama no.
1.1.
Jerarqu a de memoria
La memoria y el almacenamiento se puede clasicar en los siguientes tipos (entre par entesis se indica el orden del tiempo medio de acceso t pico): Almacenamiento primario (ns). Registros de la CPU. Memoria cach e: de primer nivel, segundo nivel y tercer nivel. RAM. Discos RAM. Cach e de disco. Almacenamiento secundario. Discos magn eticos (ms). Cintas (s). Almacenamiento ofine. 3
2o I.T.I.G./UAL Discos magn eticos removibles (ms). pticos (CD-ROM, DVD-ROM) (ms). Discos o Cintas (s).
Almacenamiento de datos
A la vista de la clasicaci on anterior es f acil deducir que el almacenamiento secundario y ofine, en cualquiera de sus modalidades, es muy lento en comparaci on con el 1 almacenamiento primario (RAM, cach es y registros de la CPU) . Adem as, los discos proporcionan una capacidad de almacenamiento ilimitada (hoy d a) a un coste muy bajo en comparaci on con la RAM 2 . Otra ventaja de los discos frente a la RAM es que la infor stos permanece intacta una vez desconectado el sistema, mientras maci on almacenada en e que la RAM es vol atil, si el sistema se para, la informaci on contenida en ella se pierde. En un mundo ideal, nuestros sistemas dispondr an de una RAM ilimitada y no vol atil, pero dadas las limitaciones expuestas nos vemos obligados a disponer de almacenamiento secundario. Un buen dise no de la estructura de archivos nos dar a acceso a toda la capacidad del disco sin hacer que nuestras aplicaciones tengan que esperar mucho tiempo.
1.2.
Introducci on hist orica
Las caracter sticas generales de la investigaci on y el desarrollo de estructuras de archivos se pueden deducir f acilmente del ejemplo anteriormente citado: De una forma ideal, nos gustar a obtener la informaci on que necesitamos accediendo una sola vez al disco. Es decir, no queremos esperar m as de seis d as a tener nuestra lista ordenada. Si esto anterior no es posible, (tener la informaci on en un solo acceso a disco), queremos tener estructuras que permitan obtener la informaci on que buscamos con el m nimo de accesos posibles. Por ejemplo, una b usqueda binaria sobre un mill on registros permite encontrar el dato con menos de veinte comparaciones. Sin embargo, veinte accesos a disco pueden consumir mucho tiempo, m as del deseado. Se nece tres sitan, por tanto, estructuras que permitan obener el dato deseado en s olo dos o accesos como m aximo.
El tiempo medio de acceso de una RAM actual es de unos 7,5 ns (7, 5 109 sg) mientras que los discos SCSI m as r apidos superan los 5 ms (5 103 sg). Existe una diferencia de acceso de orden 1:500.000 (como m nimo). Esto signica, que un proceso para ordenar una lista que cabe entera en memoria RAM y que tarda 1 sg, si se utilizara el disco para la ordenaci on tardar a 500.000 sg, es decir, 139 horas (casi seis d as). 2 Por ejemplo, actualmente un disco SCSI U-320 de 73 GB a 10.000 rpm puede costar unos 300 euros, mientras que 1 GB de RAM para servidores costar a aproximadamente lo mismo. El coste por MByte ser a de 0,4 c entimos de Euro en los discos, frente a 29,30 c entimos de euro en la RAM; la proporci on en este caso es de 1:73.
1
2o I.T.I.G./UAL
Adem as, queremos que nuestras estructuras de archivos permitan recuperar informaci on agrupada. Por ejemplo, si accedemos a disco para capturar los datos de un sto se haga con un solo cliente (nombre, direcci on, tel efono etc.) esperamos que e acceso a disco y no con varios accesos, uno para cada dato. Estas tres caracter sticas son relativamente f aciles de implementar en una estructura de archivos cuando tenemos archivos con datos que nunca cambian. Sin embargo, esto se complica cuando los datos cambian y los archivos crecen o decrecen al a nadir o eliminar informaci on. Al principio se trabajaba con cheros almacenados en cintas. El acceso era secuencial, y el coste de acceso directamente proporcional al tama no de chero. Posteriormente aparecieron los discos y en ellos se empezaron a utilizar los ndices. El acceso ya era aleatorio. La ventaja de usar ndices es que permiten realizar b usquedas muy r apidas. Estos guardan en peque nos cheros estructuras de claves y punteros que apuntan al archivo original o primario. Encontrando la clave en el chero de ndices, el acceso al dato es inmediato. Sin embargo, los ndices simples son m as de lo mismo, cheros de acceso secuencial en s mismos; y cuando crecen, se convierten en dif ciles de gestionar, sobre todo en cheros din amicos en los que las claves pueden cambiar. rboA principios de los a nos sesenta se comenzaron a utilizar estructuras basadas en a les binarios, convirti endose en una potencial soluci on al problema. Sin embargo, cuan rboles crec do se a nad an o eliminaban registros, los a an muy desordenadamente (no de balanceada) ocasionando que en grandes b forma uniforme o usquedas se accediera de el a rbol AVL, consistente en una estructura masiado a disco. A ra z de esto se dise no rbol binario, empleado satisfactoriamente para gestionar daautoajustable basada en un a tos en la RAM. Este mismo algoritmo se intent o aplicar para archivos en disco, pero los accesos eran m as de los esperados para grandes archivos. Se tardaron m as de diez a nos en rboles-B. En gran encontrar una soluci on al problema, hasta que se implementaron los a medida, esta tardanza fue debida al modo en que se contru an estas estructuras, ya que los rboles-B son del tipo de abajo-arriba, al rev rboles AVL que se a es de como trabajan los a empleaban para la geti on de la RAM. rboles-B proveen un excelente acceso a los datos, pero e stos tambi Los a en ten an un coste: ya no se podr a acceder secuencialmete a los cheros de forma eciente. Esto rboles-B+, que a se solucion o r apidamente con los a naden estructuras secuenciales a las rbol. El n hojas del a umero de accesos crece en proporci on a logk N (k = no de entradas indexadas en un bloque y N = tama no del chero). Esta estructura permite acceder a un chero de varios millones de registros con tres o cuatro accesos y garantiza la inserci on y borrado sin p erdida de rendimiento. Posteriormente apareci o una nueva estructura, el hashing, que viene a dar una aproximaci on a nuestra pretensi on de obtener la informaci on deseada con s olo un acceso. Esta es una buena soluci on cuando los archivos no cambian Organizaci on y gesti on de archivos 5 Antonio Aliaga Munoz
2o I.T.I.G./UAL
el hashing demasiado de tama no en el tiempo. Para este tipo de situaciones se dise no extensible y din amico, que permiten b usquedas con no m as de dos accesos a disco.
1.3.
Discos
Como ya se ha dicho antes, el lugar ideal para trabajar con los datos es la RAM, en donde pueden estar asociados a estructuras de archivos de forma autom atica. Sin embargo el uso del almacenamiento secundario es imprescindible. Las principales desventajas de ste los discos y otros dispositivos frente a la RAM son su mayor tiempo de acceso y que e no es igual en todas las partes del dispositivo.
1.3.1.
Tipos de discos
Los discos o unidades de disco (nos referimos a discos magn eticos), son dispositivos de almacenamiento de acceso directo, ya que se puede acceder directamente a cualquier dato en el disco y no secuencialmente como ocurre en una cinta (serial access o acceso secuencial). Los discos magn eticos se clasican en discos duros (hard disks - HD) y discos exibles (oppy disks - FD). Los HD ofrecen alta capacidad a un coste por bit bajo, y son los m as usados. Los FD son baratos pero tambi en son muy lentos y tienen poca capacidad. ltimos son adecuados para transportar peque Estos u nas cantidades de datos o hacer copias de seguridad. Hay un tipo de discos duros, llamados removibles, que permiten ser monta til para transportar grandes cantidades dos y desmontados varias veces, lo cual puede ser u de datos y hacer copias de seguridad que requieren un acceso directo. pticos como Otro tipo de discos son los no-magn eticos, entre los cuales est an los o los m as importantes (CD-ROM, DVD-ROM, etc.). Tambi en existen otro tipo de discos h bridos llamados magneto- opticos.
1.3.2.
Organizaci on de los discos
Un disco est a compuesto a su vez por varios discos o platos, en los que se almacena la se organiza en pistas conc informaci on sobre su supercie. Esta entricas que a su vez est an divididas en sectores. Las pistas se organizan en cilindros. Un cilindro estar a compuesto por todas las pistas que ocupan la misma posici on en los diferentes platos o discos. Todas las pistas de un cilindro se pueden leer sin mover el cabezal, que es lo que consume m as tiempo (Ver la gura 1.1). La unidad de lectura/escritura en un disco es el sector, que se lee entero y se guarda en un buffer, desde el cual se accede al bit que se desea leer. Organizaci on y gesti on de archivos 6 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 1.1: Esquema interno de un disco magn etico.
1.3.3.
Capacidad del disco
Capacidad de la pista = no sectores por pista x bytes por sector. Capacidad del cilindro = no pistas por cilindro x capacidad de pista. Capacidad del disco = no de cilindros x capacidad de cilindro.
1.3.4.
Organizaci on de pistas por sectores
A la hora de organizar los sectores en las pistas, hay que tener en cuenta el tiempo que ste le va suministrando. la controladora del disco tarda en procesar la informaci on que e Existe pues un retardo entre la lectura de cada sector y el siguiente. Si estamos accediendo a datos que est an almacenados en sectores de forma contigua o adyacente y la controladora no es lo sucientemente r apida, s olo podr amos leer un sector en cada revoluci on del disco, lo cual no es deseable. Para mejorar esto, se sit uan los sectores de forma no adyacente dejando el suciente espacio entre ellos para que las controladoras puedan procesar la informaci on que el disco le va suministrando. A esta t ecnica se conoce como interleao ving, donde al factor de interleaving es el n de sectores que separan cada dos sectores l ogicos adyacentes. Actualmente las controladoras de disco han superado este problema y todos los discos son accedidos por la controladora con interleave 1:1, lo cual permite leer todos los sectores de una pista en una sola revoluci on (Ver la gura 1.2). Organizaci on y gesti on de archivos 7 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 1.2: Interleaving. ste agrupa los sectores en clusters para Desde el punto de vista del sistema operativo, e obtener un mayor rendimiento en las operaciones de E/S. En la FAT (le allocation table) se almacena para cada archivo ordenadamente los clusters en los que se ubica. De esta manera, cuando se accede a un chero no se hace sector a sector sino cluster a cluster. Si el sistema operativo es capaz de ubicar un chero completo en clusters contiguos del disco, se dice que ocupa una sola extensi on. Si esto no es posible, se utilizar a m as de una extensi on y el archivo estar a fragmentado (desde el punto de vista del sistema operativo). Otro tipo de fragmentaci on ocurre cuando se quiere almacenar un registro en disco con tama no inferior a un cluster. Existen dos opciones: utilizar un sector para cada registro o un cluster para cada archivo, o almacenarlos de forma contigua. La primera opci on supone desperdiciar grandes cantidades de espacio en disco, y la segunda requiere leer dos sectores o dos clusters para recuperar el registro o archivo. Este par ametro es importante en sistema operativos que permiten predeterminar el tama no del cluster, ya que si en l se van a almacenar grandes cheros de acceso secuencial, el tama e no de cluster debe ser grande, mientras que el almacenamiento de datos de reducidas dimensiones requiere tama nos de cluster menores.
1.3.5.
Organizaci on de las pistas por bloques
Se trata de una organizaci on diferente a la de los sectores, caracter stica de los sistemas UNIX. Los discos que lo permitan, pueden almacenar los archivos de forma continua, Organizaci on y gesti on de archivos 8 Antonio Aliaga Munoz
2o I.T.I.G./UAL
en bloques de distinto tama no llamado factor de bloqueo, que indica el n umero de registros que se almacenan en cada bloque. Esto elimina los problemas anteriormente citados en la organizaci on de pistas por sectores, pero necesita almacenar informaci on adicional para su correcta gesti on. Por tanto pasamos de tener un sistema de direccionamiento por sectores a un sistema de direccionamiento por bloques. Este es en t erminos generales de mayor eciencia que el anterior. La informaci on necesaria para gestionar el bloque de informaci on se almacena en subbloques (count subblock - no bytes del bloque, key sub ltimo registro del bloque, data subblock - datos, etc). As block - clave del u por ejemplo, se podr an realizar b usquedas directamente sobre disco sin necesidad de cargar las claves previamente en memoria.
1.3.6.
Espacio reservado o de control (nondata overhead)
Tanto la organizaci on por bloques como por sectores requiere reservar un espacio adicional para la gesti on del disco. Esta se suele reservar durante el pre-formateo y guardar a informaci on sobre atributos de los sectores o bloques que el disco va a contener como: direcci on f sica del sector y de la pista, sector defectuoso o no, etc. Este proceso se realiza de forma transparente al usuario o programador.
1.3.7.
El coste del acceso a disco
El tiempo total de acceso a disco est a determinado por la contribuci on de tres operaciones f sicas: el tiempo de posicionamiento (seek time), el retardo de rotaci on (rotational delay) y el tiempo de transferencia (fransfer time). El tiempo de posicionamiento es el que tarda el brazo del cabezal en posicionarse en el cilindro correspondiente. Si estamos accediendo a un archivo que est a en cilindros adyacentes, el tiempo de posicionamiento tras haber le do todas las pistas de un cilindro ser a peque no pues ir a al cilindro inmediatamente contiguo. Si por el contrario estamos accediendo a dos cheros, uno en el cilindro m as exterior y otro en el m as interno, el tiempo de posicionamiento ser a bastante elevado. En sistemas multiusuario, el tiempo de posicionamiento suele ser mayor que en un sistema mono-usuario, por la cantidad de diferentes procesos que acceden a distintos archivos simult aneamente. Generalmente, suele ser muy dif cil o imposible conocer exactamente el tiempo de posicionamiento, y entonces se da una estimaci on del tiempo medio de acceso. El retardo de rotaci on hace referencia al tiempo que tarda el disco en situarse sobre el sector buscado, y se calcula en promedio como (la mitad del tiempo que tarda en dar una vuelta) 3 .
Un disco SCSI de 15000 rpm tiene un retardo medio de 2 ms mientras que uno de 10000 rpm tiene un retardo medio de 3 ms y un UATA de 7200 rpm 4,2 ms y una disketera de 360 rpm 83,33 ms.
3
2o I.T.I.G./UAL
El tiempo de transferencia depende de la cantidad de informaci on que se desea transferir y viene dado por la siguiente f ormula: T iempo de transf erencia = tiempo de rotacion
num bytes transf eridos num bytes por pista
1.3.8.
El disco como cuello de botella
stos est La tecnolog a actual permite transmitir datos a mayor velocidad de la que e an disponibles 4 . Para aprovechar al m aximo las capacidades de las redes de comunicaciones se han dise nado sistemas que permitan este aprovechamiento. El striping consiste en tener sistemas de almacenamiento con m ultiples discos en los que la informaci on se almacena a trozos entre todos, sumando as el ancho de banda generado por cada uno de ellos y por tanto reduciendo proporcionalmente el tiempo de transferencia. Es un ejemplo t pico de paralelismo. Otra opci on es utilizar parte de la RAM como unidad disco (RAM disk) debido al sta. Lo que se hace es simular un disco en memoria, con lo abaratamiento de costes de e que eliminamos el retardo de rotaci on y el de posicionamiento se reduce enormemente. El mayor problema es su volatilidad. Otra posibilidad es la utilizaci on de RAM como cach e de disco, la cual contendr a p aginas de datos del disco. Cuando se solicite un dato ubicado en almacenamiento secundario, el sistema buscar a antes si est a ya en la cach e, en cuyo caso evitar a el tener que acceder a disco. El impacto en rendimiento es enorme, sobre todo cuando se accede a datos localmente residentes (ubicados contiguamente). ltimos tipos, (RAM disk y cach Estos dos u e de disco) son ejemplos de buffering, que es una de las t ecnicas m as utilizadas por los sistemas de E/S.
1.4.
Cintas magn eticas
A modo de resumen, las cintas son dispositivos magn eticos de almacenamiento secundario de acceso secuencial (no directo). Entre sus principales ventajas podemos decir que son muy baratas, compactas, f aciles de trasportar, se pueden almacenar en lugares con diferentes condiciones ambientales y proveen un acceso secuencial muy r apido a cheros. Los datos se organizan en la cinta uno tras otro, por lo que no es necesario ning un tipo de direccionamiento. La supercie de la cinta se divide en pistas paralelas, cada una de
Los discos actuales m as r apidos pueden transferir datos al sistema a raz on de unos 100 MBytes/sg de forma sostenida. Por otra parte, las redes de comunicaciones permiten anchos de banda por cable de cobre ptica. de 1 Gbit/sg que equivale a 128 MBytes/sg y a un superiores con bra o
4
10
2o I.T.I.G./UAL
las cuales es una secuencia de bits. Suelen incorporar una pista para control de paridad. Los bytes se suelen agrupar en bloques de tama no que puede variar (de Bytes a KBytes 5 dependiendo de las necesidades del usuario) . Los par ametros f sicos caracter sticos de las cintas son la densidad medida en bits/pulgada (800, 1600, 6250, etc.), la velocidad (pulgadas/segundo) y el tama no entre bloques (pulgadas). En la actualidad, las cintas se utilizan para backups y almacenamiento de archivos hist oricos de acceso poco frecuente.
En el Catastro del Ministerio de Hacienda espa nol, las cintas se formatean en bloques de 10 registros de 720 bytes cada uno, que equivale a 7200 bytes x bloque.
11
2o I.T.I.G./UAL
12
Cap tulo 2 Archivos

Este cap tulo es una introducci on a las operaciones fundamentales de los sistemas de archivos: crear, abrir, cerrar, leer, escribir y posicionar (en lenguaje C: create, open, close, read, write, seek).
2.1.
Archivos f sicos y archivos l ogicos
Un archivo es una colecci on de bytes existentes en alg un dispositivo de almacenamiento (por ejemplo, en un disco o en una cinta). Por lo tanto, el archivo existe f sicamente. Un disco puede contener cientos o miles de archivos f sicos. En sistemas operativos como LINUX se dice que cualquier dispositivo del sistema se puede considerar como si fuera un archivo. As pues, el teclado, una impresora, un disco o una partici on, ser an tambi en tratados como archivos. Sin embargo, desde el punto de vista de un programa de usuario, un archivo es algo l, muy distinto. Apenas sabe nada del archivo, s olo que puede enviar y/o recibir datos de e adem as de cu ando llega a su nal (es como una l nea de tel efono). Adem as, los programas de usuario suelen usar un n umero limitado de archivos, y conf an la tarea de la comunicaci on al sistema operativo. A esta idea de archivo como l nea de tel efono la llamaremos archico l ogico. Por lo tanto, el programa indicar a al sistema operativo que asocie un archivo f sico a un archivo l ogico, y a partir de entonces s olo se comunicar a con el archivo l ogico.
2.2.
Operaciones principales sobre archivos
Antes de entrar a describir las funciones que permiten el manejo de cheros, hay que tener en cuenta que el lenguaje C distingue entre dos grupos distintos, las de bajo nivel y 13
2o I.T.I.G./UAL alto nivel.
Archivos
La diferencia principal entre ellas es que en las de bajo nivel (tipo UNIX) deben declararse y mantenerse todas las zonas intermedias de memoria (buffers); todos los accesos al chero deben programarse manualmente, as como controlar los punteros y contadores. Las funciones de bajo nivel, asocian al chero un valor num erico llamado descriptor. En las funciones de alto nivel (tipo ANSI), todas las lecturas y escrituras se realizan buffers) que no precisan mantenimiento sobre zonas intermedias de memoria (canales o por parte del programador, proporcionando as un nivel de abstracci on entre la aplicaci on buffer como dispositivo l y el dispositivo f sico utilizado, empleando el canal o ogico archivo l o ogico. Este sistema est a pensado para trabajar con pantallas, discos, disquetes, teclados, etc. Aunque son dispositivos diferentes, el sistema de alto nivel asocia a cada uno un canal distinto permitiendo utilizar las mismas funciones de E/S con todos ellos. Las funciones de alto nivel asocian al chero un registro (de tipo FILE). Existen dos tipos de canales de alto nivel, los binarios y los de texto. Desde un punto de vista pr actico, las funciones de bajo nivel acceden a disco en cada operaci on de lectura/escritura que se produce, mientras que las funciones de alto nivel s olo acceden a disco si en la operaci on de lectura/escritura solicitada los datos requeridos no se encuentran en ese preciso instante en el buffer del archivo. De este modo, en un alto porcentaje de ocasiones los datos estar an en el buffer y nos ahorraremos muchos accesos a disco, haciendo que nuestras aplicaciones sean m as r apidas.
2.2.1.
Abrir archivos
canal a un archivo f Una vez asociado un archivo l ogico o sico, debemos decirle al sistema operativo qu e queremos hacer con el archivo. Existen dos opciones: abrir un crear un archivo nuevo (esto implica borrar cualquier informaci archivo existente o on que contuviera en caso de existir previamente). Una vez realizada alguna de estas dos operaciones, el archivo queda a disposici on del programa para leer o escribir, posicionado al principio del mismo. crear (bajo nivel): int creat(char *nombreArchivo, int modo) abrir (bajo nivel): int open(char *nombreArchivo, int modo) crear y abrir (alto nivel): FILE *fopen(char *nombreArchivo, char *modo)
2.2.2.
Cerrar archivos
Un archivo debe cerrarse siempre. S olo as nos aseguraremos que todos los cambios producidos en el mismo quedan escritos en el archivo. Cuando termina un programa se Organizaci on y gesti on de archivos 14 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Archivos
cierran todos los cheros autom aticamente, pero esto no ocurre si el programa aborta antes de su n. Como se vio en el cap tulo anterior, es m as eciente trabajar con bloques de datos que byte a byte. Por ello, el sistema operativo no realiza los cambios de manera inmediata en el disco, sino que utiliza un buffer intermedio. Al cerrar el archivo, se descarga todo el contenido del buffer en el disco. cerrar (bajo nivel): int close(int descriptorFichero) cerrar (alto nivel): int fclose(FILE *descriptorFichero)
2.2.3.
Leer y escribir en archivos
Las funciones de lectura y escritura en archivos son las operaciones fundamentales de los procesos de E/S de cualquier sistema. leer (bn): int read(int descriptorFichero, void *buffer, unsigned numeroBytes) escribir (bn): int write(int descriptorFichero, void *buffer, unsigned numeroBytes) leer (an): int fread(void *buffer, int numeroBytes, int contador, FILE *descriptorFichero) escribir (an): int fwrite(void *buffer, int numBytes, int contador, FILE *descrFichero)
2.2.4.
Posicionamiento (seek) en archivos
Cada vez que se lee o escribe con las funciones anteriores, el puntero que controla la posici on sobre el archivo se mueve al nal de la cadena le da o escrita. En ocasiones nos puede interesar saltar directamente a otra posici on distinta de la actual sin tener que leer los caracteres intermedios, o ir al nal del chero para a nadir nueva informaci on. Posicionar (bn): long lseek(int descriptorFichero, long desplazamiento, int origen) Posici on (bn): long tell(int descriptorFichero) Posicionar (an): long fseek(FILE *descriptorFichero, long desplazamiento, int origen) Posici on (an): long ftell(FILE *descriptorFichero)
15
2o I.T.I.G./UAL
Archivos
16
Cap tulo 3 Elementos b asicos de las estructuras de archivos

Cuando creamos estructuras de archivos, estamos imponiendo un orden a los datos. Existen varias formas de implantar este orden. La m as b asica consiste en un chero de tipo stream (traducido como corriente). Supongamos que introducimos datos desde el teclado (nombre, direcci on). Estos se guardar an en el archivo en el mismo orden que los stream de caracteres, sin a vamos tecleando como si fuera una corriente o nadir ninguna informaci on adicional. Este procedimiento es simple, pero nos ocasiona varios problemas, ya que perdemos la integridad de las unidades organizativas fundamentales de nuestros datos; es decir, no sabemos distinguir nombres de direcciones, ni cuando empiezan o terminan. A estas unidades las llamaremos campos. Por tanto, un campo ser a la menor unidad l ogica de informaci on con signicado en un chero. El campo es un concepto l ogico importante para la estructura del chero, pero no tiene que existir f sicamente.
3.1.
Estructuras de campos
Campos de longitud ja. Comenzar cada campo con un indicador de longitud. Utilizar un delimitador al nal de cada campo. Utilizar una expresi on del tipo clave=valor para identicar cada campo y su valor. 17
Existen varias formas de estructurar los archivos en campos (Ver la gura 3.1):
2o I.T.I.G./UAL
Elementos b asicos de las estructuras de archivos
Figura 3.1: Formas de estructurar un archivo en campos.
3.1.1.
Campos de longitud ja
Lo normal es que los datos que cada campo puede contener no tengan la misma longitud. Sin embargo, si a la hora de almacenarlos en el archivo utilizamos el mismo tama no para todos los datos de un campo conseguiremos delimitar exactamente la posici on que ste en el archivo. La principal ventaja es que basta con un contador para localizar ocupa e el principio y nal de cada campo, y la mayor desventaja es que el archivo necesita espacio adicional (generalmente espacios en blanco) para cubrir el hueco no ocupado por los datos. Tambi en podemos tener problemas si tenemos que almacenar distintos campos en donde alguno de ellos pudiera ser excesivamente largo, o cuando los datos de un campo pueden variar de longitud considerablemente.
3.1.2.
Comenzar cada campo con un indicador de longitud
Otra forma de organizar los datos en un archivo es incluir al principio de cada campo til si el tama un entero que indique la longitud del mismo. Esto es especialmente u no Organizaci on y gesti on de archivos 18 Antonio Aliaga Munoz
2o I.T.I.G./UAL
de campo no supera los 256 caracteres, ya que as s olo tendr amos que utilizar un byte adicional por campo.
3.1.3.
Utilizar un delimitador al nal de cada campo
En este caso es necesario elegir un car acter delimitador adecuado, que no est e presente en ning un dato. Suelen utilizarse, seg un convenga, caracteres de espaciado (blanco, tabulador, salto de l nea), u otros caracteres especiales de uso poco frecuente en el texto corriente ($, &).
3.1.4.
Utilizar una expresi on
Esta opci on tiene una ventaja que las otras no tienen, y es que cada campo provee informaci on a cerca de su propia estructura (metainformaci on). As s olo se incluir an en el archivo aquellos campos que existieran realmente, ignorando los que no tienen valor. Suele utilizarse en combinaci on con otros m etodos, fundamentalmente con delimitadores. m La gran desventaja es la cantidad de espacio adicional que requiere (50 % o as del espacio est a ocupado por informaci on de control).
3.2.
Estructuras de registros
Un registro se dene como un conjunto de campos que permanecen unidos desde un punto de vista de alto nivel organizativo. Al igual que ocurre con el campo, el registro es un concepto l ogico de un nivel conceptual superior al campo y con signicado propio. Los registros no tienen que existir en el archivo en sentido f sico. Existen varias formas de estructurar los archivos en registros (Ver la gura 3.2): Registros de longitud ja en numero de bytes. Registros de longitud ja en numero de campos. Comenzar cada registro con un indicador del numero de bytes de longitud. Utilizar un archivo auxiliar donde se indica la posici on de inicio de cada registro. Utilizar un delimitador al nal de cada registro.
19
2o I.T.I.G./UAL
Figura 3.2: Formas de estructurar un archivo en registros.
3.2.1.
Registros de longitud ja en numero de bytes
Al igual que ocurre con los campos, con este m etodo se fuerza a que todos los registros tengan la misma longitud. Suele ser el m etodo m as utilizado en la organizaci on de archivos. No es necesario que los campos del registro tambi en sean de longitud ja (pueden ser de longitud variable), lo cual implicar a la utilizaci on de espacios de relleno (ller).
3.2.2.
Registros de longitud ja en numero de campos
En lugar de jar el tama no del registro, una mejor soluci on consiste en jar el n umero de campos que contiene. Podremos reconocer el comienzo de cada registro simplemente contando el numero de campos le dos. Organizaci on y gesti on de archivos 20 Antonio Aliaga Munoz
2o I.T.I.G./UAL
3.2.3.
Comenzar cada registro con un indicador del numero de bytes de longitud
En este caso se a nadir a un entero al comienzo de cada registro indicando el numero de bytes del registro. Este es el m etodo m as usado para manejar registros de longitud variable.
3.2.4.
Utilizar un archivo auxiliar donde se indica la posici on de inicio de cada registro
Es lo que se conoce como un ndice de registros. Nos permite conocer la posici on exacta de inicio de cada registro as como su longitud por la diferencia con la posici on del registro siguiente.
3.2.5.
Utilizar un delimitador al nal de cada registro
Esta soluci on es equivalente a utilizar delimitadores para campos. El car acter delimitador, por tanto, no debe estar incluido en los datos almacenados. Normalmente suele ser el par retorno de carro m el car acter n de l nea (LF) o as n de l nea (CR+LF).
3.3.
Buffers y bloques de registros
Como ya se ha citado en el primer cap tulo, se han desarrollado diferentes t ecnicas para obtener mejores resultados en cuanto a la minimizaci on de los accesos a disco. El uso de zonas de memoria a modo de buffers y la agrupaci on de sectores en bloques son dos muestras de los m etodos m as empleados por el sistema operativo para este n. Ambas suelen emplearse simult aneamente ya que se complementan al aplicarse en fases distintas del proceso de lectura/escritura de la informaci on en disco.
3.3.1.
Buffers
Un buffer no es m as que una porci on de memoria que se utiliza a modo de cach e para la transferencia de datos desde el disco al procesador o viceversa. Cuando hablemos de stos de los diferentes buffers nos referiremos precisamente a la RAM, diferenciando a e niveles de memoria cach e que suelen integrar las propias unidades de disco y sus tarjetas controladoras. Organizaci on y gesti on de archivos 21 Antonio Aliaga Munoz
2o I.T.I.G./UAL
ste quien lo mantiene, dotando El buffer se gestiona desde el sistema operativo, y es e apertura al menos uno para cada chero abierto durante el proceso de creaci on (creat) o (open) del archivo. Cuando un programa de usuario solicita una petici on de lectura el proceso realizado se puede esquematizar como se muestra en el siguiente gr aco (Ver la gura 3.3).
Figura 3.3: Algoritmo de lectura de un archivo con buffer.

S olo se produce un acceso a disco si el registro no se encuentra en el buffer.
De manera similar, el proceso de escritura ser a el representado seg un el siguiente gr aco (Ver la gura 3.4). Con esta t ecnica, al trabajar con grandes cantidades de datos en la RAM, se reduce dr asticamente el n umero de accesos a disco. La cuesti on que se nos plantea a continuaci on es si es suciente con un solo buffer por chero, o podemos mejorar el sistema de E/S con la utilizaci on de varios buffers por chero. Veamos el siguiente ejemplo: Un programa realiza entradas y salidas de un car acter cada vez en un chero. Cuando lee el primer car acter, el buffer se carga con el sector que contiene el car acter solicita ste se transmite al programa. Si el programa decide escribir un car do, y e acter, entonces el buffer es modicado. Si el programa solicita otro dato, antes de nada se debe volcar el buffer al disco y posteriormente recuperar el sector conteniendo dicho car acter . . . y as sucesivamente. Esta situaci on se puede optimizar utilizando dos buffers por archivo, uno de entrada y otro de salida. Adem as, se puede mejorar el rendimiento utilizando t ecnicas de Organizaci on y gesti on de archivos 22 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 3.4: Algoritmo de escritura de un archivo con buffer.

S olo se produce un acceso a disco si la siguiente operaci on de lectura/escritura necesita datos que no est an en el buffer.
doble buffer. Esto consiste en disponer dos buffers de escritura por archivo, de tal manera que cuando se escribe uno en disco, se lee el otro y as alternativamente intercambiando los papeles de ambos. Por lo tanto, el sistema operativo puede realizar operaciones en un nicamente a dos buffers, buffer mientras escribe el otro en disco. Esta t ecnica no se limita u buffer pooling. pudiendo tratarse de un conjunto de buffers o
3.3.2.
Bloques
Como es l ogico pensar, el sistema operativo necesita tener control sobre el estado de todos los sectores (unidad m nima de transferencia de informaci on entre el disco y el 1 subsistema de E/S) en un disco . Debido al enorme tama no de los discos actuales y en consecuencia, al gran n umero stos contienen, el sistema operativo utiliza un m de sectores que e ultiplo del sector como bloque depenunidad m nima de transferencia de informaci on de E/S, llamada cluster o diendo del gestor de cheros. Por consiguiente, un bloque ser a el espacio m nimo que
Supongamos que tenemos un disco de 128 GBytes distribuidos en sectores de 512 bytes y que s olo utilizamos 1 byte por sector para control; har an falta 256 MBytes para gestionar esta tarea. Esto supondr a que se deber a destinar una porci on demasiado grande del disco para su propia gesti on, adem as del tiempo adicional que deber a invertirse para manejar estas enormes tablas
1
23
2o I.T.I.G./UAL
puede ocupar un chero en disco. Un chero no tiene por qu e tener el mismo tama no desde el punto de vista f sico en distintos sistemas de cheros, ya que en cada uno de ellos se puede denir el tama no de cluster de manera distinta 2 . Esta forma de gestionar el espacio en disco por el sistema operativo, repercute directamente sobre c omo se deber an manipular nuestros registros de datos. Debemos conocer cu al es el tama no de cluster para aprovechar mejor las posibilidades que el sistema operativo nos ofrece. Para ello, se deber a tender a tener bloques del tama no de un cluster 3 m ste . Es f o ultiplos de e acil calcular cu antos registros habr a en un bloque realizando el cociente entre el tama no de bloque por el tama no de registro (suponiendo que un registro sea de longitud ja e inferior a la del bloque). A esto se conoce como factor de bloqueo o de blocaje. Dependiendo del tipo de registros que pertenecen a un chero se pueden distinguir dos tipos de emblocamiento, el jo y el variable. F actor de Bloqueo =
Longitud de bloque Longitud de regsitro
Emblocamiento jo Considera que todos los registros del chero son del mismo tama no, normalmente con campos de tama no jo y predenido. Adem as se exige que el tama no del registro sea inferior al del bloque, y no se permite colocar registros en dos bloques distintos. Este tipo de emblocamiento ocasiona generalmente un desperdicio de espacio al no poder ubicar algunos registros completos en un bloque, en el caso de que el tama no de bloque no sea m ultiplo del tama no de registro. Requiere, pues, que se dise nen los registros con un tama no adecuado. Emblocamiento variable Se aplica a registros de longitud variable. Puede haber dos variantes, el emblocamiento variable no espaciado o no extendido que no permite que un registro se ubique en dos bloques distintos; y el emblocamiento variable espaciado o extendido, en caso contrario. En el segundo caso, cuando un registro no cabe entero en un bloque se debe almacenar stos no tienen que ser adyacentes. En el caso de un puntero al siguiente bloque, ya que e tener registros de tama no superior al del bloque es necesario utilizar el emblocamiento variable espaciado.
Por ejemplo, si un chero contiene s olo 5 bytes, y el tama no de cluster es de 1 KByte (2 sectores), en disco ocupar a 1024 bytes, desperdici andose el 99.51 % del espacio disponible; en otro sistema con bloques de 2 KBytes (4 sectores) ocupar a 2048 bytes, desaprovechando el 99.76 %. 3 Bases de datos como Oracle utilizan esta caracter stica del sistema operativo, empleando (por defecto) bloques de 8 Kbytes en sistemas de 4 Kbytes por cluster. No obstante, el tama no de bloque es congurable.
2
24
2o I.T.I.G./UAL
En ambos casos, el c alculo del factor de blocaje es complejo y menos preciso que en el emblocamiento jo, ya que se estima en base a la media del tama no de registro. Adem as hay que considerar las marcas que se almacenan para delimitar los registros y los campos entre s . Si el tama no medio de los registros es grande, tambi en es aconsejable utilizar el emblocamiento variable espaciado.
3.4.
Operaciones sobre registros. Fragmentaci on del almacenamiento
Las inserciones, borrados y actualizaciones de registros generan varios problemas, especialmente graves si los registros son de longitud variable. Incluso cuando los campos y registros son de longitud ja hay que dedicarle especial atenci on.
3.4.1.
La inserci on
Si el chero no mantiene ning un orden particular (Ver la gura 3.5), debemos buscar un bloque con suciente espacio vac o para colocar el nuevo registro, y en caso de no encontrar ninguno, obtendremos un bloque nuevo donde lo introduciremos. El problema es mayor si existe un orden establecido en el archivo, por ejemplo de clave primaria (Ver la gura 3.6). En este caso, hay que localizar primero el bloque que corresponda (seg un el orden). Si en el bloque hay espacio vac o, tendremos que desplazar los registros para colocar el nuevo registro en su lugar adecuado. Si en el bloque no hay espacio vac o para colocar el nuevo registro , tendremos que buscarlo en otro bloque. Hay dos posibilidades: overow) (Ver la gura 3.7), que 1. A nadir un bloque nuevo B2 (de desbordamiento o ser a direccionado a partir de un puntero de overow que existe en la cabecera del bloque B1. En este nuevo bloque B2 podremos colocar los registros ordenadamente. A su vez, el bloque de overow puede apuntar a un segundo bloque de overow B3, y as sucesivamente. pr 2. Encontrar espacio en un bloque vecino o oximo B2 (Ver la gura 3.8). Si el bloque candidato B1 a albergar el registro no contiene suciente espacio, lo buscamos en el bloque siguiente. Si en este segundo bloque B2 hay espacio suciente, llevaremos el registro superior del bloque B1 al bloque B2 ordenadamente, desplazando a su vez los registros del bloque B2. Entonces insertamos el nuevo registro en el bloque B1 en la posici on adecuada. Organizaci on y gesti on de archivos 25 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 3.5: Inserci on de un registro en un bloque no-ordenado.

Los registros se insertan desde fuera hacia dentro para que el espacio libre quede siempre a continuaci on de la cabecera permitiendo la incorporaci on de nuevos punteros.
Figura 3.6: Inserci on de un registro en un bloque ordenado con espacio.
26
2o I.T.I.G./UAL
Figura 3.7: Inserci on de un registro en un bloque ordenado sin espacio. Bloque de overow.
Figura 3.8: Inserci on de un registro en un bloque ordenado sin espacio. B usqueda en el bloque vecino.
27
2o I.T.I.G./UAL
3.4.2.
El borrado
En caso de tener una tabla de offsets, podemos eliminar el registro simplemente desplazando los otros para dejar el espacio libre en el centro del bloque. De esta manera queda el espacio compactado, sin fragmentar. Si no tenemos una tabla de offsets o no podemos desplazar los registros (Ver la espacio libre en el gura 3.9), tendremos que mantener una lista de registros borrados o bloque que nos permita conocer qu e espacio libre hay y su tama no. Para ello ser a suciente con gestionar los fragmentos libres a modo de pila, colocando el tope de la pila en el registro de cabecera del bloque, y en cada registro borrado un puntero al siguiente registro eliminado.
Figura 3.9: Borrado de un registro con lista de espacio libre. Otra t ecnica es colocar una marca de borrado en cada registro eliminado, sin m as. Este mecanismo requiere tener una tabla de registros borrados. El espacio libre que queda al eliminar los registros puede ser recuperado realizando un proceso de compactaci on general del archivo.
3.4.3.
La actualizaci on
stos no afectan al almaceSi los registros son de longitud ja, las modicaciones de e namiento ya que el tama no del registro no var a, s olo cambia su contenido. Si los registros son de longitud variable, tenemos todos los problemas de la inserci on y del borrado juntos, exceptuando la necesidad de crear marcas de borrado (en su caso). Se pueden dar dos casos: Si la nueva versi on del registro es de un tama no mayor que la antigua, es necesario tomar espacio adicional del bloque. Esto puede suponer el desplazamiento de otros registros dentro del bloque, e incluso la creaci on de un bloque de desplazamiento (overow). Organizaci on y gesti on de archivos 28 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Si el nuevo registro es de menor tama no, podemos utilizar t ecnicas de recuperaci on de espacio, como se ha explicado en el apartado anterior.
3.5.
Acceso a registros
Una vez que hemos tomado conciencia de que en nuestras estructuras de archivos el registro es la m nima unidad de informaci on que ser a le da o escrita a la vez, necesitamos t ecnicas para movernos ecientemente con esta losof a de organizaci on de la informaci on.
3.5.1.
Llaves de busqueda
Es conveniente tener identicados cada uno de los registros del archivo con una clave (llave o usquedas key) basada en su contenido. De esta manera conseguiremos realizar b m as ecientes. La clave es otra herramienta conceptual (como lo son el campo, registro, sta que archivo, etc). La forma can onica de una clave consiste en una representaci on de e 4 nos permite estandarizar los valores que la clave puede tomar . Podemos tener claves que identiquen de forma unica a un registro. A estas claves las primary keys. Otras claves que pueden denirse y que no tienen llamaremos primarias o nicas son las claves secundarias 5 . porqu e ser u nica, debemos proveer Si una clave secundaria no identica al registro de forma u mecanismos que resuelvan la incertidumbre ocasionada al realizar una b usqueda. Lo m as normal suele ser que se devuelva el subconjunto de registros que coinciden con dicha scroll entre ellos. clave, permitiendo realizar desplazamiento o Algunos criterios importantes para escoger buenas claves primarias son: Las primary keys suelen no estar basadas en datos reales, debido a la incertidumbre stos, ya que en cualquier momento pueden repetirse valores y adem intr nseca de e as no podr an contener datos nulos. no deben estar denidas sobre valores cambiantes. Las primary keys no pueden o
Por ejemplo, si tenemos un registro cuya clave fuese el nombre ANTONIO, el registro deber a po antonio. En este caso, la forma can der encontrarse independientemente de escribir Antonio o onica consistir a en formar claves que s olo contengan may usculas y no contengan blancos al nal de la cadena. 5 Un ejemplo de clave primaria puede ser el NIF, y una clave segundaria el nombre+apellidos.
4
29
2o I.T.I.G./UAL
3.5.2.
Busqueda iterativa de un registro en un archivo (busqueda se cuencial)
En registros no bloqueados (Ver la gura 3.10), la eciencia de una b usqueda secuenN cial es en promedio 2 , siendo N el n umero de registros del archivo, y por tanto, el orden de eciencia es O(N ).
Figura 3.10: B usqueda secuencial en archivos no-bloqueados. En registros bloqueados las b usquedas son m as ecentes (Ver la gura 3.11). Como se ha visto en el primer cap tulo, el coste de recuperar un registro de disco es b asicamente seek-time). Si recuperamos dos registros conel tiempo de posicionamiento (b usqueda o secutivos en un archivo no bloqueado, necesitaremos dos accesos a disco, tardando m as tiempo que en recuperar esos dos registros en un solo acceso transriendo los datos de un sola vez. En este caso, s olo habr a que posicionarse en el primero de ellos y transferir en bloque la informaci on de ambos. Por tanto, podemos mejorar el rendimiento de la b usqueda transriendo bloques de registros en lugar de registros individuales. Aunque aumentar a el tiempo de transferencia (que es proporcional a la cantidad de informaci on), el tiempo de b usqueda se reducir a dr asticamente, y en conjunto, el coste de la b usqueda ser a mucho menor. Sin embargo, aunque obtendremos tiempos de b usqueda muy inferiores a la b usqueda en archivos no bloqueados, el orden de eciencia contin ua siendo O(N ). En promedio, , donde FB es el factor sin embargo, el n umero de accesos se puede calcular como 2N FB de bloqueo (n umero de registos por bloque). Organizaci on y gesti on de archivos 30 Antonio Aliaga Munoz
2o I.T.I.G./UAL
El bloqueo de registros no var a el n umero de comparaciones que deben realizarse en la RAM para encontrar el registro buscado.
Figura 3.11: B usqueda secuencial en archivos bloqueados. La b usqueda secuencial puede ser recomendable en las siguientes situaciones: B usqueda de patrones en cheros ASCII. Ficheros con pocos registros. B usqueda en cheros almacenados en cintas. B usqueda por claves secundarias con un gran n umero de resultados por clave.
3.5.3.
Acceso directo e ndices
El acceso directo es la alternativa m as radical al acceso secuencial. Diremos que tenemos acceso directo a un registro cuando podemos posicionarnos directamente al comienzo del mismo y leerlo. Organizaci on y gesti on de archivos 31 Antonio Aliaga Munoz
2o I.T.I.G./UAL
El orden de eciencia ser a, por tanto, constante O(1), independientemente del n umero de registros del chero. En ocasiones, la posici on de cada registro se almacena en un stos, podemos conocer su posici chero secundario o ndice, o bien, si prescindimos de e on a partir del numero de registro relativo (RRN) con respecto al inicio del chero (0, 1, 2, l seg 3, . . . ). Este RRN suele asignarse a cada registro y se almacena con e un el orden de introducci on en el chero. Para trabajar con el RRN de forma eciente necesitamos que los registros sean de longitud ja. En caso contrario, si los registros son de longitud variable, la eciencia de la b usqueda seguir a siendo O(N ) ya que no sabr amos el tama no de cada registro y por tanto no podemos obtener la posici on del registro de forma directa (para calcularla habr a que realizar una b usqueda secuencial). Por tanto, necesitamos registros de longitud ja conocida: P osicion del registro en el f ichero = RRN longitud del registro
32
Cap tulo 4 Organizaciones b asicas de registros en archivos

Los archivos pueden organizar los registros que contienen de diferentes formas, adoptando una u otra en funci on de la utilidad para la que est en dise nados o del tipo de registro que almacenan. B asicamente, existen cinco tipos de organizaciones: 1. Organizaci on apilada. 2. Organizaci on secuencial. 3. Organizaci on encadenada. 4. Organizaci on directa. 5. Organizaci on indexada. En este tema s olo trataremos las tres primeras y la cuarta a modo de introducci on, dejando la organizaci on indexada y la directa para m as adelante por abordarse en cap tulos espec cos para cada una.
4.1.
Archivos de registros no ordenados: Organizaci on apilada
Este tipo de organizaci on recibe su nombre de la forma en que se incorporan nuevos registros al archivo, ya que se hace del mismo modo que en las pilas. Es decir, los nuevos 33
2o I.T.I.G./UAL
Organizaciones b asicas de registros en archivos
ltimo registro existente. No existe, por registros siempre se incorporan al nal, tras el u tanto, ning un orden establecido, ni existen referencias que indiquen la posici on de un registro en el archivo. El acceso a la informaci on s olo puede ser secuencial, de tal manera que para acceder a un registro siempre ser a necesario pasar por todos los anteriores al mismo comenzando desde el principio del archivo.
4.1.1.
Estructura
En funci on de la estructura de los registros que contienen estos archivos se pueden clasicar en estructurados y no-estructurados. Los no-estructurados pueden contener registros sin estructura denida, con diferente n umero de campos, y cada campo con diferente tipo de datos. Los estructurados, que pueden ser de longitud ja o variable, tienen stos una estructura perfectamente denida; todos tienen el mismo n umero de campos, y e son del mismo tipo y mantienen el mismo orden en el registro.
4.1.2.
No estructurados
El hecho de que no tengan una estructura denida, obliga a que con cada dato se deba almacenar informaci on a cerca de su contenido. Los registros tienen la forma que muestra la gura 4.1. Cada registro est a compuesto por el par identicador/valor con separadores entre ambos y a su vez con separadores entre diferentes parejas. Por su propia naturaleza auto til es descriptiva el espacio que ocupan con respecto a la informaci on verdaderamente u excesivamente elevado. A continuaci on vamos a describir en qu e modo afecta la estructura de este tipo de 1 organizaci on a las operaciones elementales que pueden realizarse con archivos. La inserci on tiene un coste computacional bajo ya que siempre se insertar an los ltimo bloque en disco. Por tanto, el orden de eciencia nuevos registos al nal del u es O(1).
Inserci on: incluir un nuevo registro en el archivo de datos. Lectura: localizar un registro a partir de secundaria. Lectura consecutiva: tras haber realizado una lectura, consiste alg un valor de clave primaria o en leer el siguiente registro seg un el criterio de b usqueda establecido, de forma ordenada. Lectura exhaustiva: Listar todos los registros desde el principio hasta el nal, sin ordenar. Lectura ordenada: Listar todos los registros desde el principio hasta el nal, ordenados por clave. Borrado: Eliminar el registro del archivo. Actualizaci on: Modicar los valores de un registro. Reorganizaci on: Compactar el archivo eliminando los huecos dejados por los registros borrados o actualizados.
1
34
2o I.T.I.G./UAL
Figura 4.1: Organizaci on apilada no-estructurada La lectura es totalmente secuencial desde el comienzo y puede suponer la lectura del archivo completo. Para cada registro accedido, antes de comparar con su valor hay que localizar el identicador deseado seg un el criterio de b usqueda establecido. Es por tanto, una operaci on costosa de eciencia O(N ). La lectura consecutiva del registro siguiente (en orden) dado su anterior es costosa ya que el archivo no mantiene orden alguno. Supondr a la lectura de todo el archivo desde su inicio, y el orden de eciencia es O(N ). La lectura exhaustiva es una operaci on poco costosa de eciencia O(N ). La lectura ordenada, por el contrario, es una operaci on muy costosa de eciencia 2 O(N ). Para cada dato hay que leer de nuevo el archivo completo. El borrado consiste en marcar el registro con un car acter especial. No requiere ninguna otra acci on especial. Su eciencia es O(1). La actualizaci on. Si el registro no cambia de tama no, se actualiza directamente. En cambio, si la longitud var a habr a que marcar el registro como borrado y realizar la posterior inserci on como si de uno nuevo se tratara. En cualquier caso, la eciencia es O(1). compactaci La reorganizaci on, o on requerir a de un archivo auxiliar donde ir copiando los registros v alidos, comenzando por el primero hasta el nal del archivo. Organizaci on y gesti on de archivos 35 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Es una operaci on bastante costosa de eciencia O(N ).
4.1.3.
Estructurados
En este tipo de archivos todos los registros tienen el mismo n umero de campos y en el mismo orden, y si los registros son de longitud ja, adem as en la misma posici on. No es necesario almacenar m as informaci on que los datos en s mismos. la denici on de cada campo puede estar en el propio programa que gestiona el archivo (impl citamente denida) o bien se puede incorporar como el primer registro del archivo. (Ver la gura 4.2).
Figura 4.2: Organizaci on apilada estructurada con registros de longitud variable. La manipulaci on de este tipo de archivos tiene las mismas caracter sticas que los no estructurados, siendo todas las operaciones de car acter secuencial. S olo tiene la ventaja del ahorro que se obtiene al no tener que procesar los identicadores y que los campos est an ordenados en el registro, lo cual es importante para encontrar el registro que satisfaga la condici on de b usqueda con un menor coste computacional. La inserci on: se realiza siempre al nal del archivo, O(1). La lectura: secuencial desde el principio, O(N ). La lectura consecutiva: una vez encontrado el primer registro es necesario comenzar de nuevo desde el principio del archivo para recuperar el siguiente, O(N ). Organizaci on y gesti on de archivos 36 Antonio Aliaga Munoz
2o I.T.I.G./UAL
La lectura exhaustiva: al igual que en los no-estructurados ,se listan todos los ltimo por orden de introducci registros desde el primero hasta el u on, O(N ). La lectura ordenada: para cada registro se debe recorrer de nuevo el archivo completo, O(N 2 ). El borrado: se marca el registro con un car acter especial, O(1). La actualizaci on: si el registro no cambia de longitud, simplemente se reemplaza. En caso contrario, se marca como borrado y se inserta al nal, O(1). La reorganizaci on: se procede como en los no-estructurados, utilizando un archivo auxiliar, O(N ).
4.1.4.
Resumen
De forma resumida podemos decir que las organizaciones apiladas tienen las siguientes caracter sticas: Son la forma menos estructurada existente de organizaci on archivos. Su uso data de los comienzos de los sistemas autom aticos de procesamiento de informaci on. Se justica su uso en la actualidad cuando se necesita una adquisici on muy r apida de la informaci on, siendo en estos casos desaconsejable su procesamiento en tiempo real. Tambi en se aconseja cuando se desconoce el dominio de la informaci on adquirida. Los principales inconvenientes de este tipo de archivos son: Costes de tratamiento muy elevados. Costes de almacenamiento muy altos. Requieren reorganizaciones peri odicas, sobre todo si la volatilidad de la informaci on es alta. El control de la informaci on es dif cil de realizar, ya que permiten distintas ocurrencias del mismo dato en diferentes posiciones del archivo (informaci on redundante). Organizaci on y gesti on de archivos 37 Antonio Aliaga Munoz
2o I.T.I.G./UAL
4.2.
Archivos de registros ordenados: Organizaci on secuencial
Con este nuevo tipo de organizaci on se intentar a resolver algunos de los problemas que presentan las organizaciones apiladas. En las organizaciones secuenciales todos los registros est an ordenados en funci on de una clave. Una clave es un t ermino que puede estar compuesto por uno o varios atributos (campos) y que permite la identicaci on stos en el archivo. inequ voca de un registro, o que permite la ordenaci on de e Los registros tendr an una estructura perfectamente denida, con el mismo n umero de campos, en el mismo orden y referidos al mismo dominio de la informaci on, representando la misma propiedad del mundo real (Ver la gura 4.3).
Figura 4.3: Organizaci on secuencial con registros de longitud variable.

Los registros se encuentran ordenados por la clave ISBN.
Los registros pueden ser de longitud variable o ja. En los archivos con registros de longitud variable, el acceso es secuencial ya que no es posible determinar directamente la posici on de un registro en el archivo. Cuando los registros son de longitud ja, el acceso nica y de un algoritmo se puede realizar de forma directa si disponemos de una clave u que calcule la posici on relativa en el archivo a partir de esta clave. nica Por tanto, parece imprescindible disponer de una clave que identique de forma u a cada registro del archivo. En caso de no ser posible, ser a necesario utilizar un atributo externo que haga la funci on de clave primaria. Organizaci on y gesti on de archivos 38 Antonio Aliaga Munoz
2o I.T.I.G./UAL
4.2.1.
Estructura de la organizaci on secuencial
Como ya hemos adelantado, los archivos estar an compuestos por registros de estructura perfectamente denida, con el mismo n umero de campos (atributos) ocupando el mismo lugar en el registro, y adem as, en los registros de longitud ja, en la misma posici on. Este tipo de organizaci on secuencial no requiere el almacenamiento de identicadores junto a los valores.
4.2.2.
Manipulaci on de los archivos secuenciales
Las inserciones de los nuevos registros no se realizar an al nal, sino en la posici on indicada por el valor de la clave. Por tanto, las inserciones y actualizaciones son m as costosas que en las organizaciones apiladas. La inserci on es una operaci on compleja debido al orden establecido en el archivo, y mucho m as costosa que en las organizaciones de apilo. En primer lugar debemos localizar la posici on de inserci on del nuevo registro. Si no hay un hueco libre habr a que desplazar todos los registros inferiores y nalmente se inserta el registro. Est a claro que esta operaci on es muy costosa porque supone el desplazamiento de gran cantidad de informaci on, O(N ) (Ver la gura 4.4).
Figura 4.4: Organizaci on secuencial. Inserci on de un nuevo registro. Si las inserciones son muy frecuentes, para evitar este problema se puede emplear una zona de derrama, bien en el propio archivo, bien en un archivo auxiliar. En Organizaci on y gesti on de archivos 39 Antonio Aliaga Munoz
2o I.T.I.G./UAL
esta zona de derrama se insertar an directamente los nuevos registros desordenadamente como si de una organizaci on de apilo estructurada se tratara. En este caso la eciencia de la inserci on ser a O(1); (Ver la gura 4.5).
Figura 4.5: Organizaci on secuencial. Inserci on de un nuevo registro en un archivo de derrama. En alg un momento ser a necesario reorganizar el conjunto del archivo, ya sea porque sta se encuentra en el mismo chero), o porque se se llene la zona de derrama (si e llegue a un n umero considerable de registros en el archivo de derrama secundario. Las inserciones son mucho m as r apidas, pero a costa de tener parte del archivo desordenado, lo cual nos genera ciertos problemas: Las b usquedas, y en general cualquier acceso a la informaci on, deber an explorar dos zonas de datos diferentes, con procedimientos de acceso distintos. En la zona ordenada el acceso ser a directo, y en la zona de derrama, el acceso ser a secuencial. Cuanto m as crece la zona de derrama, el acceso a la informaci on ser a m as lento, por lo cual se har a m as necesaria la reorganizaci on. La lectura depender a de dos factores: el criterio de b usqueda y el tipo de registro (longitud ja o variable). Si el criterio de b usqueda no se realiza por la clave, el proceso ser a secuencial y el costo computacional tan elevado como en las organizaciones apiladas, O(N ). Si la Organizaci on y gesti on de archivos 40 Antonio Aliaga Munoz
2o I.T.I.G./UAL
b usqueda es por clave, el costo es muy bajo, ya que pueden utilizarse algoritmos r apidos, como por ejemplo la b usqueda binaria que tiene un orden de eciencia xito y O(log2 N ). Si la b usqueda en la zona ordenada del archivo no ha tenido e sta de forma secuencial la clave existe una zona de derrama, habr a que buscar en e deseada, increment andose considerablemente el tiempo de acceso. Si los registros son de longitud variable, el algoritmo de b usqueda puede aplicarse a bloques en lugar de a los registros, ya que se desconoce la posici on absoluta de stos en el archivo. Por el contrario, si los registros son de longitud ja y la clave e determina su posici on en el archivo, la lectura puede ser directa O(1). La lectura consecutiva depende de la condici on de b usqueda. Si no se busca por clave, una vez recuperado el primer registro obtener el siguiente es tan costoso como en las organizaciones apiladas ya que ser a necesario recorrer todo el archivo desde el principio, O(N ). Si la b usqueda es por clave primaria, el siguiente registro estar a con una probabilidad alta en el mismo bloque o en el siguiente, O(1), o por el contrario, en la zona de derrama. La lectura exhaustiva consiste simplemente en leer el archivo comenzando por la zona maestra de forma ordenada y siguiendo por la zona de derrama sin ordenar, O(N ). La lectura ordenada es r apida siempre que el predicado de ordenaci on incluya la clave, O(N ). Si existe zona de derrama se realizar a una reorganizaci on del archivo antes de proceder a la lectura y despu es se realiza la lectura exhaustiva. Si el predicado no incluye la clave, para cada registro recuperado hay que recorrer de nuevo el archivo completo para recuperar el siguiente, O(N 2 ). El borrado consistir a simplemente el marcar el registro con un car acter especial, O(1). La actualizaci on, si se modica la clave del registro o var a su longitud, se marca el registro como borrado y se procede a su posterior inserci on. Si no se modica la clave y la longitud del registro no cambia se modica directamente el registro con los nuevos valores. La reorganizaci on consiste en generar un nuevo archivo ordenado por la clave en el que se han eliminado los registros borrados y se han intercalado los registros de la zona de derrama. Organizaci on y gesti on de archivos 41 Antonio Aliaga Munoz
2o I.T.I.G./UAL
4.2.3.
Resumen
El empleo de archivos con organizaci on secuencial resuelve algunos de los problemas que planteaban las organizaciones apiladas y mejora el coste computacional de otras operaciones. No obstante siguen siendo poco ecientes cuando existen zonas de derrama. Por ello suelen desaconsejarse cuando el tama no del archivo es grande o cuando la informaci on es muy vol atil por las continuas reorganizaciones que requieren.
4.3.
Archivos con registros enlazados: Organizaci on encadenada
Cuando es necesario manejar medios y grandes vol umenes de informaci on es reco sta en varios archivos relacionados entre s mendable almacenar e , con el n de reducir la redundancia y controlar la consistencia de los datos almacenados. Las clases de obje entidades se pueden representar por uno o varios archivos, y una tos del mundo real o relaci on entre dos o varias clases de objetos por un nuevo archivo. Es necesario, por tanto, que nuestro sistema pueda operar con m ultiples archivos a la vez. Los archivos secuenciales no son adecuados para trabajar con varios archivos simult aneamente. As pues, si los registros de un archivo est an relacionados a su vez con otros objetos de otros archivos, ser a necesario poder almacenar informaci on de esta relaci on en el propio archivo. Esto lo conseguiremos deniendo unos atributos especiales llamados punteros, que ser an un atributo de un registro cuya funci on es la de se nalar a otro registro del mismo o distinto archivo con el cual se encuentra relacionado. No se debe confundir el signicado de estos punteros con los punteros de los lenguajes de programaci on que son otra cosa bien distinta. Un puntero permitir a mantener una relaci on f sica o l ogica entre registros de archivos, no entre direcciones de memoria. En consecuencia, un puntero podr a contener: La direcci on de m aquina de un registro (cilindro, pista, cabeza y sector). Estos punteros son los m as directos y ecientes, pero tienen inconvenientes, ya que dependen del sistema f sico de almacenamiento y de su localizaci on en el mismo; adem as requieren mucho espacio de almacenamiento. comienLa direcci on relativa de un registro con respecto al BOF (begin of le o zo del archivo). Con estos punteros se consigue la independencia del dispositivo, ya que el registro siempre ocupar a la misma direcci on relativa (byte de origen con respecto al BOF) en cualquier sistema de archivos. Adem as requieren menos espacio que los anteriores. Sin embargo, tienen el inconveniente de que dependen de la Organizaci on y gesti on de archivos 42 Antonio Aliaga Munoz
2o I.T.I.G./UAL
posici on del registro en el archivo, de tal manera que si el archivo se reorganiza, cambiar an muchas de las direcciones relativas de los registros. La identicaci on de un registro ( o valor simb olico) a partir de la cual puede obtenerse alguna de las dos direcciones anteriores. Estos punteros simb olicos son independientes del dispositivo as como de la posici on del registro en el archivo. Por contra, son dif ciles de gestionar ya que requieren de complejos algoritmos para transformar su valor en la correspondiente direcci on del registro. Resumiendo, diremos que los archivos est an basados en una organizaci on encadenada si alguno de sus atributos es un puntero (de cualquiera de las clases vistas) a otro registro del mismo archivo o de otro diferente. Desde un punto de vista l ogico, los registros pueden verse como eslabones de una cadena. Los punteros podr an representar: Relaciones entre registros. Relaciones entre archivos. Relaciones entre tipos de entidades. Un orden o secuencia entre los registros de un archivo, permitiendo tener un archivo ordenado por varias claves a la vez.
4.3.1.
Estructura de las cadenas
Los archivos que intervienen en las cadenas de registros pueden estar compuestos de registros de longitud ja o variable, siendo alguno de sus atributos un puntero. Por simplicidad, en adelante supondremos que los registros son de longitud ja. Una cadena ser a una colecci on de registros referenciados, cada uno ocupando una posici on relativa con respecto al primero (llamado cabeza de la cadena) en base a un predicado de ordenaci on (compuesto por uno o varios atributos). Una cadena puede considerarse como una lista de registros, debiendo conocerse en cada momento la cabeza y la cola de la misma. El uso de organizaciones encadenadas permite representar f acilmente las relaciones l ogicas existentes entre el dominio de un problema. Los punteros permiten aumentar el conocimiento del dominio que aporta un registro; es como si los registros de los archivos apuntados estuvieran incluidos en el registro apuntador, pero con las siguientes ventajas: Organizaci on y gesti on de archivos 43 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Los datos de los registros apuntados s olo son almacenados una vez, evitando redundancias superuas. La penalizaci on (en n umero de accesos a disco) del sistema es baja ya que s olo ser a necesario un acceso adicional para localizar el registro apuntado. Al no haber redundancia se evitan los problemas de las inconsistencias. No obstante, tienen el inconveniente de que requieren un dise no cuidadoso de los procesos que actualizan los valores de las claves, ya que si se pierde alg un puntero de la cadena, la informaci on del archivo situada a continuaci on nunca ser a accesible. Normalmente, las organizaciones encadenadas se basan en la existencia de archivos stos se realiza por la clasecuenciales (ordenados por una sola clave). Cuando el acceso a e ste ser ve, e a muy eciente, pero cuando se requiere acceder con un predicado de b usqueda basado en otro atributo, los tiempos de acceso aumentar an proporcionalmente al tama no de la cadena, como si fuese una organizaci on de apilo. Para solucionar este problema es frecuente denir varios punteros en el archivo que lo mantengan ordenado por diferentes claves de b usqueda. Por tanto, los elementos de una cadena pueden formar parte del mismo archivo o de archivos diferentes. Si los elementos de la cadena pertenecen a diferentes archivos, las organizaciones encadenadas representan relaciones entre entidades; y cuando todos los elementos de una cadena pertenecen al mismo archivo, las organizaciones encadenadas representan secuencias l ogicas, al igual que las organizaciones secuenciales pero con varias diferencias: El orden no viene determinado por la posici on f sica de los registros, sino por los punteros. Los registros se incorporan al nal del archivo evitando el uso de zonas de derrama. Se pueden mantener tantas secuencias como se quiera incorporando nuevos punteros al registro. Se necesita conocer cual es el primer registro de la cadena.
4.3.2.
Manipulaci on de los archivos encadenados
Este tipo de organizaciones encadenadas se aconseja para el uso de registros estructurados (con estructura ja denida) y de longitud ja. En el caso de registros de longitud variable, el tiempo de procesamiento aumenta al no conocer la longitud de los registros adem as de por la propia gesti on de los punteros. En los registros de longitud ja conocemos siempre la posici on exacta de cada puntero en la estructura del registro, (Ver la gura 4.6). Organizaci on y gesti on de archivos 44 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 4.6: Organizaci on encadenada.

La cadena muestra un orden de clave primaria dentro del propio archivo.
La inserci on. El nuevo registro se puede incorporar en cualquier posici on del archivo (al principio, al nal o en huecos dejados por registros eliminados). Una vez insertado se deben reasignar los punteros para mantener la secuencia de la cadena ordenada (o de las cadenas, si hay m as de una), por lo que habr a que recorrer la cadena para localizar los registros afectados, siendo en este caso la eciencia O(N ). La lectura s olo podr a realizarse de forma secuencial comenzando por la cabeza de la cadena, necesitando en promedio N accesos, siendo el orden de eciencia 2 O(N ). Si la b usqueda no es por ninguna de las claves, se realiza como si fuera una organizaci on de apilo. La lectura consecutiva de un registro a partir del anterior (basada en alguna clave) es inmediata ya que los registros est an ordenados, O(1). En la mayor parte de los en el siguiente. casos el registro siguiente estar a en el mismo bloque de registros o Si no es por clave hay que leer el archivo desde el inicio, O(N ). La lectura exhaustiva consistir a en posicionarse en el primer registro y a partir de l recorrer todo el archivo hasta el nal, O(N ). e La lectura ordenada deber a localizar la cabeza y a partir de ella recorrer toda la cadena de forma ordenada, O(N ). Si el orden no es por ninguna de las claves de la cadena, entonces su eciencia es O(N 2 ). Organizaci on y gesti on de archivos 45 Antonio Aliaga Munoz
2o I.T.I.G./UAL
La actualizaci on es un proceso sencillo si no se modica ning un atributo perteneciente a alguna clave, simplemente actualizando su valor, O(1). Pero si interviene en alguna cadena ordenada habr a que reestructurar cuidadosamente los punteros, O(N ). En ocasiones, puede ser interesante borrar e insertar en lugar de actualizar. El borrado se realizar a marcando el registro con un car acter especial y reasignando los punteros de la cadena en la que interviene, O(1). Si el registro est a implicado en m as de una cadena, no podr a ser marcado como eliminado mientras sea signicante en las otras cadenas. Esto se controla mediante el uso de unas marcas en el propio registro que indican la signicancia del mismo con respecto a cada cadena. La reorganizaci on deber a realizarse peri odicamente debido a la existencia de registros no-signicantes para ninguna de las cadenas existentes en el archivo. Tambi en puede ser necesaria si se ha producido alg un fallo en el sistema (software o en el proceso de mantenimiento del archivo y se ha perdido el puntero hardware) o de alguna de las cadenas declaradas, quedando informaci on no enlazada que hay que eliminar. nica cadena, se lee el archivo como si de una organizaci En caso de existir una u on de apilo se tratara guardando en un archivo temporal los registros v alidos a modo de organizaci on secuencial (ordenadamente), para posteriormente asignar la direcci on de cada puntero a su registro siguiente. Si hay m as de una cadena, el proceso se complica pues ser a necesario tener en cuenta los punteros que referencian a todos aquellos registros que cambian de posici on tras la reorganizaci on. En cualquier caso, la eciencia de l areorganizaci on es O(N ).
4.4.
Archivos relativos (hashing): Organizaci on directa
Existe otro tipo de organizaci on primaria basada en el direccionamiento calculado hashing, que proporciona un acceso muy r o apido a los registros con cierta condici on de b usqueda. Esta organizaci on suele llamarse organizaci on directa. atributo llamado La condici on de b usqueda suele estar basada en un solo campo o campo de direccionamiento calculado, y si este campo es la clave del archivo se denomina clave de direccionamiento calculado. Tambi en necesitaremos una funci on h funci funci llamada funci on de direccionamiento calculado o on hash o on de aleatorizaci on, la cual devuelve para cada registro la posici on del mismo en funci on de la clave. Tambi en puede devolver la direcci on del bloque al que pertenece el registro, realizando posteriormente la b usqueda del registro dentro del bloque en la RAM. Organizaci on y gesti on de archivos 46 Antonio Aliaga Munoz
2o I.T.I.G./UAL
4.4.1.
Hashing est atico cerrado
El hashing est atico se denomina as porque requiere conocer a priori el n umero de 2 registros que se van a almacenar . Si la funci on hash direcciona registros, se llamar a hashing cerrado, y si devuelve la direcci on de bloques de registros, le llamaremos hashing abierto. array de registros. Suponiendo El hashing cerrado 3 se implementa como una tabla o clave k en un que tenemos M registros, la funci on hash h deber a transformar el campo o valor ente [0..M-1]. Normalmente, las funciones hash tienen la forma: h(k ) = k mod M . Los valores de k no-enteros pueden convertirse utilizando la conversi on ASCII. El siguiente ejemplo muestra un algoritmo t pico de conversi on para cadenas de caracteres: temp = 1; for (i = 0; i < M; i++) temp = (temp * k[i]) % M; direcci on = temp % M; Las funciones hash tienen el problema de que no garantizan que para cada dos claves distintas exista siempre dos valores de direccionamiento diferentes. No son funciones perfectas. Generalmente, el espacio de direccionamiento calculado (los valores que puede devolver la funci on hash) suele ser mayor que el espacion de direcciones ( o numero de direcciones disponibles para los registros). La funci on hash lo que hace es establecer una correspondencia entre ambos. En los casos en que la funci on hash devuelve una misma direcci on para distintos valores de la clave k diremos que se ha producido una colisi on. En estos casos tendremos sta ya que almacenar el registro en otra posici on diferente a la calculada por h ya que e est a ocupada por otro registro insertado anteriormente. Por tanto, debemos dise nar un proceso de resoluci on de colisiones. Existen varios m etodos: Direccionamiento abierto: se examina el archivo hasta encontrar la primera posici on libre. reas de desbordamiento (derrama) Encadenamiento: consiste en mantener unas a extendiendo el array mediante el uso de punteros. La colisi on se resuelve colocando rea y encaden el registro en este a andolo al registro anterior con un puntero. As se tendr a una lista enlazada de registros para cada valor de la funci on hash.
Por contraposici on llamaremos hashing din amico a aqu el que no precisa conocer a priori el n umero de registros. 3 Algunos autores tambi en lo denominan hashing interno.
2
47
2o I.T.I.G./UAL
Hashing multiple : consiste en aplicar una segunda funci on hash. Si se siguen produciendo colisiones puede aplicarse una tercera funci on y tambi en aplicar directamente direccionamiento abierto. El objetivo de la funci on hash es distribuir los registros uniformente en el espacio de direcciones de manera que minimice el n umero de colisiones y se ocupen el mayor n umero de posiciones del array. Estudios demuestran que es recomendable tener tablas que no superen el 70 % . . . 90 % de espacio ocupado para evitar las colisiones y para que no se desperdicie demasiado espacio. Por tanto, para almacenar r registros en una tabla r 0,9, siendo M un n umero primo, ya que se habr a que escoger un M tal que 0,7 M ha demostrado que los n umeros primos realizan una mejor distribuci on de los registros al utilizarse conjuntamente con la funci on mod. Tambi en es usual tomar M como potencia de 2.
4.4.2.
Manipulaci on de los archivos hash
En este tipo de organizaciones cualquier operaci on es eciente siempre que se realice bas andose en el campo clave por el que se calcula la funci on hash. En caso contrario, la eciencia en la misma que la de los archivos de apilo. La inserci on se realiza siempre en la posici on devuelta por la funci on hash, O(1). Si se produce una colisi on debemos aplicar alg un m etodo de resoluci on de colisiones que permita insertar el registro. La lectura Se compara el registro con el indicado por la funci on hash, O(1). Si no coincide es porque hubo una colisi on y debemos buscar en otro lugar en funci on del m etodo de resoluci on de colisiones implementado. La lectura consecutiva de un registro a partir del anterior debe realizarse de forma secuencial desde el inicio del archivo ya que no est a ordenado por ninguna clave, O(N ). La lectura exhaustiva consiste en leer el archivo desde el inicio hasta el nal sin ordenar. La lectura ordenada se realiza recorriendo para cada registro de nuevo el archivo completo, O(N 2 ). La actualizaci on es simple si no se modica la clave. Basta con localizar el registro y cambiar su valor, O(1). Si se modica la clave, tambi en cambiar a la direcci on asociada por la funci on hash, por lo que habr a que eliminarlo y volverlo a insertar en su lugar adecuado, O(1). Organizaci on y gesti on de archivos 48 Antonio Aliaga Munoz
2o I.T.I.G./UAL
El borrado consiste en marcarlo como eliminado, O(1). La reorganizaci on no parece ser necesaria salvo que se disponga de zonas de desbordamiento con registros marcados como eliminados y sea necesario recuperar el espacio.
4.4.3.
Hashing abierto
Para adecuar el hashing a las caracter sticas del almacenamiento en disco los que se stas bloques de hace es dividir el espacio de direcciones de destino en cubetas 4 , siendo e disco o bien un grupo de bloques contiguos. La funci on hash establecer a una correspondencia entre la clave del registro y un n umero de cubeta relativo, en lugar de asignar una direcci on absoluta. En la cabecera del chero debemos tener una tabla que convierta el n umero de la cubeta en la direcci on f sica del bloque de disco correspondiente. Con este m etodo, el problema de las colisiones no es demasiado grave porque se asignan a una cubeta tantos registros como caben en la misma. Sin embargo, si una cubeta se llena debemos tener un mecanismo que permita la inserci on en otro lugar manteniendo enlazada la lista de registros. Esto se hace con punteros a registros que guarden la ste. direcci on del bloque y la posici on relativa del registro en e El hashing que asigna un n umero jo de cubetas se denomina hashing est atico abierto. Este tiene varios problemas ya que puede ocurrir que se desperdicie mucho espacio o por el contrario, que nos falte. Para solucionar estas cuestiones se ha dise nado el hashing din amico.
Tambi en llamadas cubos.
49
2o I.T.I.G./UAL
50
Parte II Indexaci on
51
Cap tulo 5 Conceptos b asicos sobre ndices

5.1.
5.1.1.
Archivos con ndices

Denici on
Al nal de muchos libros aparecen unas cuantas p aginas conteniendo un ndice. Un ndice es una tabla que contiene una lista de claves y la referencia a los n umeros de las p aginas donde aparecen. Todos los ndices est an basados en los mismos conceptos: claves y campos referenciados. La funci on de un ndice es proporcionar un camino para acceder a un registro r apidamente evitando tener que escanear el contenido completo del libro o del archivo en busca de la clave deseada. Los ndices son, por tanto, estructuras auxiliares dise nadas para acelerar operaciones que no son ecientes en nuestras organizaciones b asicas de archivos. Un ndice es otra herramienta conceptual y permite imponer un orden en un archivo sin necesidad de reorganizarlo. Tienen la ventaja de que puede haber varios ndices denidos sobre un archivo, bas andose en distintas claves, lo cual nos permite tener m ultiples caminos de aceso al archivo. Desde un punto de vista formal, un ndice es una colecci on de entradas de datos que proporcionan un camino eciente para localizar todas las entradas de datos con un valor de la clave de b usqueda k. Cada entrada de datos k* contiene toda la informaci on necesaria para recuperar todos los registros con el valor de la clave de b usqueda k (por ejemplo, un puntero al registro referenciado).
5.1.2.
Estructura de los ndices
Debemos tener en cuenta dos cuestiones importantes: 53
2o I.T.I.G./UAL
Conceptos b asicos sobre ndices
Exactamente qu e se debe almacenar en una entrada de datos? C omo se organizan las entradas de datos para soportar de forma eciente recuperaciones a partir de un valor dado? Una entrada de datos k* nos permitir a recuperar uno o m as registros con el valor de la clave k. Existen varias alternativas sobre qu e se debe almacenar en las entradas de datos de un ndice: 1. Una entrada de datos k* es un registro de datos con valor de la clave de b usqueda k. 2. Una entrada de datos k* es un par < k, Rid > donde Rid es el identicador del registro cuyo valor de clave es k (puntero). 3. Una entrada de datos k* es un par < k 1, ListaDeRid > donde ListaDeRid es una lista de identicadores de registros cuya clave de b usqueda es k. En el caso 1, el ndice no necesita almacenar registros de datos de forma separada a los propios datos. El ndice est a contenido impl citamente en la propia organizaci on del archivo (secuencial, encadenado o hash). Las alternativas 2 y 3, que contienen entradas que apuntan a registros de datos, son independientes de la organizaci on usada para el archivo de datos. La soluci on 3 suele gestionar mejor el espacio, pero las entradas de datos suelen ser de longitud variable. Si deseamos utilizar varios ndices, uno de ellos estar a basado en la opci on 1 para ahorrarnos tener que almacenar el contenido de archivo varias veces. Una forma de organizar las entradas de datos es realizando hashing sobre la clave de b usqueda. En este caso, las entradas de datos se tratan como un archivo con organizaci on directa (hash). Otra soluci on ser a organizar las entradas de datos construyendo una rboles y hash. estructura de datos para las b usquedas: a
5.2.
Propiedades de los ndices
Veremos algunas propiedades de los ndices que afectan a la eciencia de las b usquedas utilizando el ndice.
5.2.1.
Indices agrupados y no-agrupados (clustered/unclustered)
Un ndice es agrupado si el orden de los datos en el ndice es el mismo que el de la organizaci on del archivo de datos. Por denici on, todos los ndices de tipo 1 son agrupados. Los ndices de tipo 2 y 3 ser an agrupados si los registros de datos est an ordenados Organizaci on y gesti on de archivos 54 Antonio Aliaga Munoz
2o I.T.I.G./UAL
por la misma clave del ndice. Los ndices basados en hashing no almacenan las entradas de datos de forma ordenada, por lo tanto, s olo ser an agrupados si utilizan la alternativa 1. Los ndices que mantienen entradas de datos ordenadas por la clave de b usqueda utilizan rboles. organizaciones basadas en a En la pr actica es raro mantener archivos de datos totalmente ordenados debido al coste que supone tener que reorganizar la informaci on constantemente (inserciones y borrados). Normalmente, los registros son ordenados inicialmente en p aginas o bloques que dejan un cierto espacio sin ocupar para absorber nuevas inserciones en orden. Si el espacio de la p agina est a agotado, se obtiene m as espacio usando p aginas de desbordamiento (overow). Posteriormente, el chero deber a ser reorganizado para asegurar un buen rendimiento. Por tanto, los ndices agrupados son relativamente caros de mantener cuando el archivo es modicado; tambi en cuando las entradas de datos pueden ser movidas entre p aginas estando los registros identicados por la combinaci on (p agina, slot). Mientras que s olo podemos tener un ndice agrupado en el archivo, podemos tener varios ndices no-agrupados. El coste de utilizar un ndice para recuperar un rango de registros en funci on de la clave de b usqueda puede variar mucho. Si el ndice es agrupado s olo tenemos que recuperar p unos pocos bloques o aginas, si es no-agrupado tendremos que recuperar muchas p aginas de registros.
5.2.2.
Indices densos y dispersos (dense/sparse)
Un ndice es denso si contiene al menos una entrada para cada valor de la clave de b usqueda. Un ndice disperso contiene una entrada para cada p agina de registros del archivo de datos. Los ndices dispersos deben ser agrupados, por tanto, podemos tener como mucho un ndice disperso. T picamente, los ndices dispersos suelen ser mucho menores que los densos.
5.2.3.
Indices primarios y secundarios
Si un ndice est a basado en los campos de la clave primaria diremos que es un ndice primario. En otro caso, es un ndice secundario. Los ndices de la alternativa 1 son primarios y el resto secundarios. Un ndice primario garantiza que no hay valores de clave duplicados. Los ndices secundarios pueden contener duplicados. En caso de que sepamos que en un ndice secundario no hay duplicados, lo llamaremos ndice unico (unique index). Organizaci on y gesti on de archivos 55 Antonio Aliaga Munoz
2o I.T.I.G./UAL
5.2.4.
Indices sobre claves multiples
La clave de b usqueda de un ndice puede contener varios campos, llam andose clave compuesta. En estos ndices, diremos que una consulta de igualdad es aquella en la que cada campo de la clave de b usqueda se compara con una constante con el operador = (ej: edad = 20 and salario = 10). Los archivos hash s olo permiten este tipo de consultas. Por otra parte, una consulta de rango es aquella en la que alguno de los campos de la clave de b usqueda no se compara con una constante con el operador = (ej: edad < 30 and salario > 40), o bien (ej: edad = 30 - omitiendo salario). El orden de los campos en la clave de b usque ste (ej: edad+salario no es igual que da del ndice inuye bastante a la hora de denir e salario+edad).
5.2.5.
Indices multinivel
til cuando teConsisten en tener una especie de ndice de un ndice. Esto puede ser u nemos un ndice que est a compuesto de muchas entradas ( ndices de gran tama no). Igualmente podemos pensar en a nadir un tercer nivel, etc., pero esto tiene l mites en t erminos de eciencia y en tal caso deber amos considerar la implantaci on de un ndice basado en rboles-B. a
56
Cap tulo 6 Organizaciones indexadas

6.1. Organizaci on secuencial indexada
Ver el tema 5 del libro Ficheros: organizaciones cl asicas para el almacenamiento de la informaci on de Irene Luque Ruiz.
6.2.
Organizaci on indexada simple
Un ndice simple es aqu el que puede ser representado utilizando arrays simples de estructuras que contienen las claves y los campos referenciados. Es importante recordar que un ndice es una herramienta conceptual que impone un orden en un archivo sin necesidad de reorganizarlo.
6.3.
Estructura
Las entradas del ndice consistir an en registros de longitud ja con un campo para el valor de la clave y otro campo para el puntero a la posici on real del registro referenciado en el archivo de datos. En el ndice habr a una entrada para cada registro del archivo de datos (es un ndice denso). El ndice est a ordenado, mientras que el archivo de datos no tiene por qu e estarlo ( ndice no-agrupado). Normalmente el archivo de datos suele tener una organizaci on apilada para realizar m as ecientemente las inserciones y borrados, pudiendo tener registros de longitud variable. 57
2o I.T.I.G./UAL
Organizaciones indexadas
6.4.
El acceso a los datos
La operaci on de localizar y acceder a un registro del archivo de datos utilizando el ndice es simple: Las caracter sticas del nuevo procedimiento de b usqueda son: Se trabaja con dos archivos: el archivo de datos y el archivo de ndice. El archivo de ndice es considerablemente m as f acil de gestionar por dos motivos: Los registros son de longitud ja, lo cual facilita el uso del algor tmo de b usqueda binaria. Los registros son de menor tama no, lo que permite tener todo el contenido en memoria. Al tener registros de longitud ja en el ndice, estamos imponiendo un tama no m aximo de clave. Si las claves son el archivo de datos son de mayor tama no y se produce truncamiento, puede haber problemas al violar la restricci on de clave primaria. El archivo de ndice no almacena nada m as que el valor de la clave y el puntero en la mayor a de los casos. Sin embargo, puede ser necesario guardar otros atributos, como por ejemplo, el tama no de registro.
6.5.
Operaciones b asicas en un ndice
Hemos visto que mantener archivos de datos ordenados para poder ejecutar sobre ellos b usquedas binarias puede resultar demasiado costoso. Una de las grandes ventajas de utilizar ndices simples es que la adici on de registros puede realizarse mucho m as rapidamente que en un archivo ordenado, siempre que podamos tener todo el ndice en memoria. Suponiendo que la longitud del registro de ndice es peque na, podremos cargar en memoria varios miles de entradas en una estructura del tipo array. Entonces, todas las operaciones de b usqueda se realizar an en la RAM utilizando b usquedas binarias, siendo mucho m as r apidas, teniendo que acceder al archivo de datos una sola vez para hacer seek() y recuperar la informaci on. En caso de no tener un ndice y estar el archivo de datos ordenado, cada operaci on de b usqueda (aunque sea binaria) acceder a a disco, siendo mucho menos eciente. Sin embargo, el mantenimiento de las estructuras de ndices requiren la realizaci on de tareas adicionales, como por ejemplo: Crear el archivo de ndice originalmente vac o y el archivo de datos. Organizaci on y gesti on de archivos 58 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Leer el contenido del ndice en memoria antes de usarlo. Escribir el ndice de memoria a disco despu es de su uso. A nadir registros al archivo de datos y al ndice. Eliminar registros del archivo de datos y del ndice. Modicar registros en el archivo de datos y en el ndice.
6.5.1.
Creando los archivos
Los dos archivos (datos e ndice) se crean vac os con los registros de cabecera nada m as.
6.5.2.
Leer el ndice en memoria
Se asume que el ndice es lo sucientemente peque no como para poder albergarlo en una estructura de tipo array. Cada elemento de la estructura es un registro del ndice. La lectura se realiza de forma secuencial desde el archivo de ndice en disco a la estructura en memoria, recuperando en cada acceso un gran n umero de registros (para ahorrarnos accesos a disco).
6.5.3.
Guardando el ndice en disco
Cuando no se necesita utilizar m as el ndice, se guarda su contenido en disco. En los sistemas inform aticos pueden generarse corrupciones de datos debido a fallos del sistema (software o ectrico. Debido a que el ndice se mantiene hardware) o cortes de suministro el ntegramente en memoria y s olo se actualiza en disco cuando se deja de utilizar, si antes de realizar esta operaci on se produce un fallo, entonces tendremos un serio problema. Para evitar desastres (o m as bien para poder recuperar el sistema ante un fallo) se deber an implementar al menos un par de mecanismos de seguridad: El programa debe saber cuando el ndice est a fuera de fecha (out of date). Esto puede realizarse gestionando una marca de modicado tanto en memoria como en la cabecera del archivo de ndice en el preciso instante que se produzca la primera modicaci on. Esta marca se eliminar a cuando se guarde el ndice completo en disco. antes de De esta manera, si se produce un fallo durante la ejecuci on del programa o nalizar el procedimiento de escritura, el archivo en disco quedar a marcado como fuera de fecha. Organizaci on y gesti on de archivos 59 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Cualquier programa, antes de utilizar el ndice deber a consultar su estado, y si est a marcado, deber a regenerar el ndice antes de su uso.
6.5.4.
Inserci on de registros
El procedimiento de inserci on debe realizarse siempre sobre el archivo de datos y sobre el ndice. A nadir en el archivo de datos es f acil, s olo deberemos recordar la posici on de inserci on para asign arsela al puntero de la nueva entrada de datos en el ndice. Como el array del ndice est a ordenado, la inserci on de un nuevo registro requerir a probablemente la reorganizaci on del ndice. El procedimiento supondr a el desplazamiento de todos los ste. La gran ventaja de los registros posteriores al nuevo para dejarle espacio a e ndices es que este proceso se hace ntegramente en memoria sin acceder ni una sola vez a disco.
6.5.5.
Borrado de registros
Al igual que la inserci on, el borrado debe actuar sobre el archivo de datos (por los mecanismos estudiados en cap tulos anteriores: marca de borrado, recuperaci on de espacio, etc.) y sobre el ndice en memoria. Existen dos posibilidades: Marcar simplemente el registro del ndice como borrado. Desplazar el contenido de todos los registros posteriores liberando el espacio de la entrada borrada.
6.5.6.
Actualizaci on de registros
Podemos distinguir dos casos, dependiendo de que el cambio afecte a la clave de indexaci on o no: La actualizaci on modica el valor de la clave. Esta operaci on puede signicar la reoganizaci on del ndice y del archivo de datos, para lo cual, el camino m as sencillo consiste en realizar una operaci on de borrado seguida de una inserci on. La actualizaci on no afecta a la clave. Normalmente no afecta al ndice, pero puede suponer reorganizar el archivo de datos. Si el tama no del registro de datos no var a o disminuye, entonces solo hay que actualizar el archivo de datos nada m as. En caso de que var e su tama no, increment andose, puede ser necesario recolocarlo en otra posici on del archivo de datos, teniendo por tanto que actualizar el puntero del registro del ndice. Organizaci on y gesti on de archivos 60 Antonio Aliaga Munoz
2o I.T.I.G./UAL
6.5.7.
Indices que no caben en memoria
Los m etodos vistos hasta ahora presuponen que el contenido completo del ndice est a en memoria. Desgraciadamente, esto no es posible con todos los ndices existentes, teniendo que realizar las operaciones de mantenimiento del ndice sobre almacenamiento secundario. Las desventajas de los ndices simples que no pueden gestionarse integramente en memoria son las siguientes: La b usqueda binaria, al requerir varios accesos a disco, no es signicantivamente m as r apida que realizarla directamente sobre el archivo de datos. La reorganizaci on del ndice (debida a inserciones, borrados y actualizaciones) se realizar a sobre disco siendo millones de veces m as costosa que haci endola sobre RAM. En este punto habr a que reconsiderar seriamente la utilizaci on de organizaciones basadas en hash si la velocidad de acceso es la prioridad o de estructuras rboles-B+ si se necesita la exibilidad del acceso por clave y del acceso basadas en a secuencial ordenado. En cualquier caso, los ndices simples proseen una importante serie de ventajas sobre los archivos de datos ordenados por clave, a un cuando no puedan ser gestionados en memoria: Un ndice simple hace posible el uso de la b usqueda binaria sobre archivos de datos con longitud variable, ya que el ndice establece una asociaci on entre la longitud ja del ndice y la longitud variable del registro de datos. Los registros del ndice son mucho m as peque nos, por lo que las operaciones de reorganizaci on, ordenaci on, etc., ser an mucho menos costosas sobre el ndice que sobre el archivo de datos (debido a que habr a que mover menor cantidad de informaci on). El uso del ndice permite reorganizar las claves sin mover los registros del archivo de datos. Podemos tener diferentes ndices por distintas claves de b usqueda, mientras que en el archivo de datos ordenado por una s ola clave s olo se permite un orden.
6.6.
6.6.1.
Indices secundarios
Denici on
Un ndice secundario es aqu el que permitir a establecer un orden adicional al de la clave primaria en nuestro archivo de datos. Los campos o atributos en los que est an baOrganizaci on y gesti on de archivos 61 Antonio Aliaga Munoz
2o I.T.I.G./UAL
stos pueden contener valores sados estos nuevos ndices se llaman claves secundarias y e duplicados.
6.6.2.
Estructura
Las entradas de datos de los ndices secundarios suelen estar compuestas de un par de claves: una clave secundaria y la correspondiente clave primaria del registro de datos con el que est a relacionado. Las claves se almacenan en forma can onica (may usculas) con registros de longitud ja. Aunque ser a posible construir un ndice secundario de igual manera que un ndice primario, incluyendo un puntero al byte de inicio del registro de datos asociado, existen poderosas razones para no hacerlo as (borrados y actualizaciones).
6.6.3.
Operaciones b asicas
Inserci on de registros Cuando tenemos presente un ndice secundario, la inserci on de un nuevo registro de datos supone tambi en la inserci on de una nueva entrada en el ndice secundario. Previamente deber a haberse incluido esta clave en el ndice primario, siendo el coste de la inserci on el mismo en ambos casos (desplazamiento de entradas desde la posici on de la clave hasta el nal en RAM). Borrado de registros Borrar un registro de datos implica borrarlo del archivo de datos y tambi en todas las l existentes en el referencias a e ndice primario as como en los secundarios. Por lo tanto, habr a que reorganizar los registros restantes del ndice para recuperar el espacio liberado por la entrada eliminada. Sin embargo podemos optar por no borrar las entradas de ndice secundario, especialmente si no podemos cargarlo en memoria y lo estamos manteniendo en almacenamiento secundario. Esto no afectar a al funcionamiento de nuestra aplicaci on ya que al buscar una clave en el ndice secundario, su valor de puntero en el ndice primario devolver a un valor no-existe, lo cual nos indicar a que dicha clave no es v alida aunque est e a un en el ndice secundario. Con este m etodo, podemos ganar enormemente en eciencia de borrado ya que s olo ser a necesario mantener el ndice primario en las operaciones de borrado. Sin en lugar de la referencia a la clave primaria en el ndice secundario, hubi eramos almacenado el puntero al registro de datos, entonces no podr amos ignorar la operaci on de borrado en estos ndices, debido a que estar amos apuntando a registros err oneos que no se corresponden con la entrada indicada por la clave secundaria. Sin embargo, tenemos un espacio adicional ocupado por entradas de datos inv alidas en Organizaci on y gesti on de archivos 62 Antonio Aliaga Munoz
2o I.T.I.G./UAL
los ndices secundarios. Si el sistema de archivos realiza pocas operaciones de borrado, esto no supone ning un problema adicional. No obstante, ser a necesario realizar reorganizaciones peri odicas de los ndices secundarios eliminando aquellas entradas que no tienen asignado un valor de clave primaria v alido. Si el sistema de archivos es muy vol atil, en rboles-B, tonces deber amos considerar el uso de otras estructuras de ndices como los a que permiten el borrado de registros sin reorganizar todas las entradas del ndice. Actualizaci on de registros En la operaci on de borrado hemos visto c omo el ndice primario act ua como un buffer protector aislando al ndice secundario de los cambios del archivo de datos. Este aislamiento puede extenderse a la actualizaci on de registros. Si nuestros ndices secundarios contienen punteros al byte del archivo de datos no queda m as remedio que actualizar el ndice secundario ya que los registros de datos podr an cambiar de posici on. Pero si el ndice secundario hace referencia al ndice primario s olo habr a que cambiarlo si se modica el valor de la clave primaria o de la clave secundaria, en otros casos, el ndice queda intacto. Existen tres posibles situaciones: La actualizaci on cambia el valor de clave secundaria. Ser a necesario reorganizar el ndice para mantenerlo ordenado. Puede ser una operaci on bastante costosa. La actualizaci on cambia el valor de la clave primaria. Esta operaci on supone un gran impacto para el ndice primario, pero en el ndice secundario s olo habr a que modicar el valor de la clave en aquellos registros afectados. Como el cambio no afecta a la clave secundaria, no habr a que reorganizar el ndice a menos que haya m as de una entrada para la m sma clave secundaria, lo cual puede signicar que haya que reorganizar localmente s olo aquellos registros que coinciden en esta clave para mantener el ndice totalmente ordenado en aquellos casos de coincidencia de la clave secundaria. La actualizaci on afecta a otros campos. Todos los cambios que no afecten a las claves primaria o secundaria no suponen cambios en los ndices secundarios.
6.6.4.
La recuperaci on de registros utilizando una combinaci on de claves secundarias
Hasta ahora hemos encontrado un camino eciente para recuperar informaci on del archivo de datos bas andonos s olo en la clave primaria ( ndice primario) o en alguna de las claves secundarias ( ndices secundarios). Organizaci on y gesti on de archivos 63 Antonio Aliaga Munoz
2o I.T.I.G./UAL
A modo de ejemplo, supongamos que tenemos un archivo de datos que guarda una colecci on de grabaciones de m usica. El archivo est a indexado por la combinaci on del o a discogr c odigo de compan aca y n de grabaci on como clave primaria. Tambi en tiene dos ndices secundarios basados en el compositor y otro en el t tulo de la obra. Si deseamos consultar aquellos registros que pertenezcan al autor A y a la obra O y no tuvieramos estos ndices secundarios, deberiamos realizar una b usqueda secuencial sobre la totalidad del archivo de datos. Sin embargo podemos realizar b usqueda muy eciente de la siguiente manera: 1. Recuperamos todos aquellas entradas del ndice secundario cuyo autor es A. 2. Recuperamos todas aquellas entradas del ndice secundario cuya obra es O. 3. Realizamos la intersecci on de ambos conjuntos obteniendo aquellos valores de clave primaria que est an en ambos. 4. Obtenemos los datos de los registros del archivo de datos. Por tanto, utilizando los ndices secundarios, podemos obtener r apidamente respuesta a consultas basadas en combinaciones de claves secundarias relacionadas con los operadores OR/AND mediante uniones o intersecciones de conjuntos.
6.6.5.
Mejorando la estructura del ndice secundario. Listas invertidas
Las estructuras de los ndices secundarios que hemos visto plantean dicultades en dos aspectos: Tenemos que reorganizar el ndice cada vez que se a nade un registro. stas estar Si hay entradas de clave secundaria duplicadas, e an repetidas haciendo que el tama no de los archivos de ndices sea mayor de lo necesario. Una posible soluci on ser a cambiar la estructura del ndice secundario asociando a cada clave secundaria un array de referencias de clave primaria con un n umero jo de entradas para cada clave secundaria. Este m etodo soluciona (en parte) la segunda dicultad de la inserci on de nuevos registros cuando existen valores duplicados de clave ya que en este caso no habr a que reorganizar el ndice. Sin embargo nos ocasiona otros problemas a nadidos: Al proveer espacio para un n umero jo de registros por entrada de clave secundaria, cinco necesitamos mecanismos que resuelvan el problema de tener m as de cuatro o entradas para una misma clave. Organizaci on y gesti on de archivos 64 Antonio Aliaga Munoz
2o I.T.I.G./UAL
El espacio desperdiciado por las claves no usadas es bastante grande. Por tanto, necesitamos una estructura que no requiera la reorganizaci on del ndice cada vez que insertamos una nueva entrada y que no utilice m as espacio del necesario, permitiendo un n umero ilimitado de entradas para cada clave duplicada. Una mejor soluci on consistir a en enlazar una lista de referencias a cada valor de la clave secundaria. A este tipo de estructura le llamaremos listas invertidas ya que accedemos a la clave primaria a partir de la clave secundaria. El t ermino lista indica de hecho que tenemos una lista de claves primarias. Esta soluci on permitir a tener un n umero indeterminado de entradas para cada clave, de tal modo que la clave secundaria s olo aparece una vez ahorrando espacio de almacenamiento. Por el contrario, necesitamos reorganizar el archivo de ndice s olo si una nueva clave es insertada. Por lo tanto, necesitamos redenir la estructura de nuestros ndices secundarios, constando as de una entrada con la clave secundaria m as un puntero a la referencia de la primera clave primaria asociada en la lista invertida. La lista invertida de claves primarias se almacenar a en un archivo aparte. El hecho de asociar el ndice del archivo secundario a un nuevo archivo que contiene las listas enlazadas de referencias provee nuevas ventajas a la estructuras vistas hasta ahora: S olo necesitaremos reorganizar el archivo del ndice secundario si una nueva clave secundaria es insertada, o actualizada. Si borramos o a nadimos registros de una clave existente s olo requiere actualizar la lista invertida. La reorganizaci on del ndice secundario (inserciones o actualizaciones) es m as r api stas son m da al haber menos registros o entradas y e as peque nas. Permiten ser gestionados en almacenamiento masivo dejando m as espacio en RAM a otras estructuras de datos. La lista enlazada no necesita ser ordenada. La lista enlazada contiene entradas de tama no jo lo cual permite ser compactada f acilmente para elimiar el espacio ocupado por entradas correspondientes a registros de datos eliminados. El principal inconveniente del uso de las listas de claves primarias es la imposibilidad de tener juntas las entradas correspondientes a una misma clave secundaria. Esto ocasiona tener que reposicionarse en el archivo de la lista enlazada demasiadas veces para acceder a los registros de una misma clave secundaria. Una soluci on a este problema podr a ser leer la lista completa en RAM, lo cual puede ser muy costoso e incluso impracticable si trabajamos con varios ndices a la vez (se podr a hacer paginaci on leyendo s olo una parte de la lista en funci on de nuestras necesidades, en cualquier caso no resuelve el problema). Organizaci on y gesti on de archivos 65 Antonio Aliaga Munoz
2o I.T.I.G./UAL
6.7.
Binding: Enlazando o vinculando
A continuaci on nos planteamos una cuesti on importante que est a asociada a los sistemas que utilizan ndices: En qu e momento se vinculan a la direcci on f sica sus registros asociados? En el desarrollo de este cap tulo hemos visto que la vinculaci on de las claves primarias a una direcci on se realiza cuando el archivo de datos es construido, mientras que en los ndices secundarios, las claves secundarias se vinculan a una direcci on cuando son usadas. L ogicamente, si un ndice se relaciona directamente con el byte de inicio de cada registo del archivo de datos, conseguimos mayor rapidez en el acceso (es lo que sucede en los ndices primarios). Por tanto, si pensamos en realizar lo mismo con los ndices secundarios, ganar amos bastante en tiempo de acceso, sobre todo si el ndice est a gestionado en disco y no en memoria principal. Sin embargo, la desventaja de enlazar o vincular directamente es que las reorganizaciones del archivo de datos afectar an a todos los archivos de ndices, pudiendo llegar a ser demasiado costosas. Al retrasar el v nculo o enlace hasta el momento del acceso (en tiempo de ejecuci on), podremos dise nar ndices secundarios que requieran un m nimo de reorganizaciones cuando se a naden o borran nuevos registros. Otra ventaja de referenciar los ndices secundarios a las claves primarias en lugar de hacerlo directamente a la posicion f sica del registro es que podemos permitir la existencia de claves secundarias falsas, ya que quien determinar a realmente la existencia de una clave o no ser a la correspondiente clave primaria. De otra forma, cualquier valor de clave asociado a un puntero deber a ser correcto (v alido) o de lo contrario tendr amos un ndice corrupto. Con este m etodo de referenciar los ndices secundarios a partir de los primarios obtenemos un nivel de seguridad importante ya que s olo tendremos que realizar cambios importantes en el ndice primario, mejor que hacerlo en varios lugares (adem as los secundarios). Existen casos en los que puede ser deseable vincular los ndices secundarios directamente al puntero del registro de datos: Cuando se requiere un alto rendimiento en la recuperaci on de datos. Cuando el archivo de datos es est atico (no requiere adici on, borrado o actualizaci on de registros o pocas modicaciones). ptico) son arPor ejemplo, los archivos contenidos en CD-ROM (almacenamiento o chivos de solo lectura.
66
Cap tulo 7 rboles Reorganizaci on multinivel con a B y B+

7.1. Introducci on
rboles-B comenzaron a gestionarse a principios de los setenta pero no tomaLos a ron forma hasta 1979 (Douglas Corner), dando una soluci on eciente al mantenimiento y la organizaci on de grandes sistemas de archivos con un m nimo coste adicional, convirti endose as en la organizaci on est andar para los ndices en los sistemas de bases de datos. En un art culo de R. Bayer y E. McCreight publicado en 1972 se dan los primeros pasos hacia la soluci on denitiva, realizando el planteamiento del problema desde la imposibilidad de mantener el ndice completamente en memoria principal. Se expone la arquitectura de la nueva estructura del ndice, concluyendo que los tiempos de inserci on, borrado y recuperaci on de la informaci on tienen un orden de eciencia de logk N donde k es el tama no de p agina y N el tama no del ndice (n umero de claves). Por lo tanto, se ha introducido un nuevo concepto, que ser a necesario optimizar en cada sistema de archivos, de p que es el tamano agina. A modo de ejemplo, un ndice con un mill on de entradas y un tama no de p agina de 20 as de 4 accesos a disco para recuperar la informaci on 64 necesitar a (log64 2 4) no m solicitada. Por el contrario, una b usqueda binaria requerir a 20 accesos para la misma operaci on. Adem as, la sobrecarga del sistema es m nima cuando se realiza una inserci on o borrado de datos. rbol-B (B-trees) puede provenir de tres diferentes or El nombre a genes, ninguno de ellos conrmado: B de Boeing donde trabajaban R. Bayer y E. McCreight en 1972. 67
2o I.T.I.G./UAL B de Bayer.
rboles B y B+ Reorganizaci on multinivel con a
B de balanced, broad, bushy (balanceado, externo, poblado).
7.2.
Planteamiento del problema
El problema fundamental de gestionar un ndice directamente sobre el almacenamiento secundario es la lentitud inherente al almacenamiento secundario. Este problema puede dividirse en dos cuestiones m as espec cas: La b usqueda binaria requiere demasiados posicionamientos en disco, invirtiendo m as tiempo del deseable. Puede ser demasiado costoso mantener el ndice ordenado para poder realizar b usquedas binarias debido a la necesidad de desplazar grandes cantidades de datos cuando se insertan o borran datos.
7.3.
Arboles binarios de busqueda
rboles binarios de b Una posible soluci on podr an ser los a usqueda. Los nodos de esta estructura de datos contienen los punteros (derecha e izquierda) a sus hijos. Si cada nodo es un registro de longitud ja y los punteros son el n umero de registro relativo (RRN) podremos mantener esta estructura en disco. Esta estructura no aparece ordenada en disco, sino de forma aleatoria, ni existe rela rbol. Toda la informaci ci on entre la secuencia de registros y la estructura del a on sobre la estructura de los datos est a basada en los punteros. Con este punto de vista, la adici on de un nuevo registro se realiza en cualquier posici on, generalmente al nal del archivo, realizando adem as el enlace de esta nueva clave con los nodos apropiados. El rendimien rbol binario es bueno siempre y cuando e ste est to de una b usqueda en un a e balanceado equilibrado. Diremos que un a rbol est o a balanceado cuando la altura del camino m as corto a una hoja no diera en m as de un nivel al camino m as largo. Se dice que est a completamente balanceado si todos los caminos son de la misma altura o longitud. Si un rbol no est rbol, a a balanceado debido a que se realizan inserciones sin reorganizar el a los tiempos de respuesta de las b usquedas no ser an los deseados en algunos de los casos, rbol est especialmente si en a a siendo gestionado en almacenamiento secundario. Organizaci on y gesti on de archivos 68 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 7.1: Arboles binarios de b usqueda
7.4.
Arboles AVL (Adelson-Velskii-Landis)
rbol AVL es un a rbol balanceado en altura. La m Un a axima diferencia de altura entre dos nodos con la ra z es 1. Dos caracter sticas importantes son: rbol no exAl exigir que la diferencia m axima permitida entre las dos ramas del a ceda de 1, garantizamos un cierto nivel m nimo de eciencia en las operaciones de b usqueda. rbol en la forma AVL, la inserci Al mantener el a on de nuevos nodos implican el uso de alguna de las cuatro posibles rotaciones que se realizan sobre una zona local rbol que no necesita de m del a as de cinco reasignaciones de punteros. Es decir, las nuevas inserciones son ecientes. rboles AVL representan una soluci rboles Los a on a la degeneraci on producida en los a rboles binarios de b usqueda debido a las inserciones de nuevos nodos. El problema de los a AVL es que no son directamente aplicables a la mayoria de las estructuras de archivos debido a la gran cantidad de nivieles que presentan, suponiendo cada nivel un acceso a disco, resultando ineciente el acceso a la informaci on. Sin embargo son interesantes rbol de forma equilibrada con pocas desde el punto de vista de que permiten mantener un a operaciones (bajo coste). Organizaci on y gesti on de archivos 69 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 7.2: Arboles AVL
7.5.
Arboles binarios paginados
La idea de la paginaci on viene del hecho ya comentado en esta asignatura de que lo m as costoso en el acceso a disco es el tiempo de posicionamineto de la cabeza del ste. Una vez all disco en alg un lugar de e , la lectura de unan gran cantidad de datos secuencialmente es muy r apida. Por tanto, en un sistema paginado, despu es de posicionar la cabeza, se lee el tama no de bytes correspondiente a una p agina completa del archivo. Una p agina contendr a una gran cantidad de registros individuales, ahorr andonos el coste rbol binario en del acceso a disco para cada uno de ellos. Por tanto, deberemos dividir al a p aginas, almacen andolas en bloques contiguos de disco. En este ejemplo (Ver la gura 7.3) accederemos a cualquier registro con no m as de dos accesos a disco (de un total de 63 nodos). Cada p agina almacena siete nodos y puede ramicarse en ocho nuevas p aginas (64 7 = 448 + 63 = 511) y as sucesivamente (4095 rbol en p nodos con cuatro accesos como m aximo). Claramente, troceando el a aginas obtenemos una b usqueda m as r apida sobre almacenamiento secundario, mejor que cualquiera de la estudiadas hasta ahora. rboles binarios paginados es (con El n umero m aximo de accesos en este tipo de a respecto a los arboles binarios): rboles binarios: log2 (N + 1) - En a rboles binarios paginados: logk+1 (N + 1) En a Organizaci on y gesti on de archivos 70 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 7.3: Arboles binarios paginados rbol completamente balanceado de 511 nodos por p Ejemplo: Sea un a agina, en 3 niveles de paginaci on (k=511, tama no en disco 8 kbytes por p agina). Cu antos registros pueden gestionarse con este a rbol?: logk+1 (N + 1) = 3 = log511+1 (N + 1) = 3 = N + 1 = 5123 = N = 5123 1 = N = 134217721 Cu antos accesos son necesarios para localizar un registro con el N calculado arriba en un a rbol binario? log2 134217721 + 1 = 27 Con este ejemplo se demuestra la gran ventaja, desde el punto de vista del n umero de rboles binarios. accesos al almacenamiento secundario, de utilizar la paginaci on en a Sin embargo, el uso de grandes p aginas no es gratuito. Cada acceso a una p agina requiere la trasmisi on de una gran cantidad de datos, peor a un si el espacio ocupado por ste la p agina no est a siendo utilizado completamente. Pero el principal problema no es e (ya que lo que invertimos en la transmisi on nos lo ahorramos en mayor medida en el rbol para que la b tiempo de posicionamiento), sino c omo se organiza el a usqueda sea realmente eciente. rbol antes de que e ste sea construido, Si tenemos el conjunto completo de claves del a la soluci on al problema es relativamente f acil: podemos ordenar la lista de claves y cons rbol desde e sta, partiendo de la clave situada en el punto medio de la lista como truir el a Organizaci on y gesti on de archivos 71 Antonio Aliaga Munoz
2o I.T.I.G./UAL
rbol (procediendo de igual forma con cada una de las dos clave ra z de la p agina ra z del a partes de la lista, hasta el nal). Desafortunadamente, no solemos disponer de la lista completa de claves al comienzo, sino m as bien de una lista desordenada de claves que llegan aleatoriamente. Despu es de rbol hasta encontrar aquella posici recibir una nueva clave, debemos ir rotando el a on que lo deje de foma balanceada. Despu es de insertar todas las claves, generalmente solemos rbol desbalanceado (Ver la gura 7.4). Este problema deriva directamente del obtener un a rbol lo construimos desde la ra hecho de que el a z hacia abajo. Si las claves que entran rbol, o una mala en primer lugar no son las adecuadas, posiblemente tengamos un mal a rbol (si est rbol paginado, no podemos rotar rama del a a en un nivel inferior). A estar el a rboles sin paginar, ya que p aginas completas de la misma forma que hac amos en los a esto supondr a tener que romper p aginas, lo cual abre un amplio mundo de posibilidades y dicultades. Romper las p aginas signicar a reorganizar parte del ndice en disco ya que el cambio afectar a a varias p aginas. Esta operaci on puede llegar a ser muy costosa si las p aginas son de gran tama no.
Figura 7.4: Arboles binarios paginados (desbalanceo) En cualquier caso, nos quedaremos con la idea de que agrupar claves en p aginas es una mejor soluci on al problema ya que reduce dr asticamente los accesos a disco. Sin embargo tenemos tres cuestiones pendientes de resolver: C omo nos aseguramos de que las claves de la p agina ra z son buenos separadores, dividiendo al resto de las claves de una forma m as o menos equilibrada? Organizaci on y gesti on de archivos 72 Antonio Aliaga Munoz
2o I.T.I.G./UAL
C omo agrupamos claves que no deben compartir la misma p agina? (en el ejemplo (c,d y s). C omo garantizamos que cada p agina contiene un m nimo de claves? Si tenemos un tama no de p agina grande, podemos tener p aginas muy sobrecargadas y otras poco ocupadas desperdiciando espacio. A TODOS ESTOS PROBLEMAS. LOS ARBOLES-B SON LA SOLUCION
7.6.
Arboles-B
rboles binarios paginados son: Los dos principales problemas que presentan los a No existe una buena pol tica de situaci on de las claves en los nodos lo cual provoca rbol desbalanceado. la evoluci on hacia un a rbol est Mientras algunas p aginas del a an completas, otras est an casi vac as provo rbol incrementando excesivamente la altura de algunos cando desequilibrio en el a sub arboles.
7.6.1.
Denici on
Est a claro que el hecho de agrupar un n umero determinado de nodos en un mismo bloque de informaci on reduce considerablemente el n umero de accesos a disco. Esta ope rbol binario raci on, desde un punto de vista l ogico, puede considerarse como cambiar el a pasando a ser n-ario, siendo n el n umero de nodos en cada bloque. Por tanto, cada bloque tendr a ahora n v as o bifurcaciones. Cada bloque de registros se considerar a como un no rbol (un nodo tendr do del a a varias claves y varios apuntadores a otros sub arboles). Estos rboles, por su naturaleza, tambi a en se llaman a a o rboles multiv multinivel o a rboles de accesos m ultiples. rbol multiv En un a a (de orden n), cada nodo tiene n o menos punteros y contiene una clave menos que el n umero de punteros. Si un nodo est a lleno, tendr a n-1 claves y n punteros. Si el nodo no est a lleno, contendr a i n 1 claves y i + 1 punteros. Al tener m ultiples claves, cuando se insertan registros se vuelven a presentar los mis rboles binarios debido a la inadecuada selecci mos problemas que ocurr an en los a on del nodo ra z y a la mala pol tica de distribuci on de las claves, provocando el desbalanceo. Todo est a ocasionado por la selecci on en cada momento de una ra z inadecuada, lo cual rbol o de partes del mismo que tienen requiere realizar reorganizaciones peri odicas del a un coste computacional muy elevado. Hemos visto que si tuvi eramos m as informaci on a Organizaci on y gesti on de archivos 73 Antonio Aliaga Munoz
2o I.T.I.G./UAL
rbol mejor, lo cual hace prepriori, antes de seleccionar la ra z, podr amos construir un a ver que retrasando la elecci on de la misma podemos solucionar este problema. Esta idea rbol de abajo hacia arriba, al rev es de c omo se ha da lugar a la t ecnica de construir el a rboles-B convenido haciendo hasta ahora. La pol tica a seguir en la construcci on de los a sistir a en seleccionar una nueva ra z para dos nodos conocidos, permitiendo as escoger la mejor para ambos. rboles-B utilizaremos la terminolog Para denir los a a expuesta por Knuth (m as clara y menos confusa que la expuesta por Bayer y McCreight). Propiedades: rbol-B, una hoja es un nodo sin descendientes. 1. En un a 2. Cada nodo tiene como m aximo n descendientes. 3. Cada nodo tiene al menos n/2 descendientes, excepto la ra z y las hojas. 4. La ra z tiene al menos 2 descendientes, salvo que sea una hoja. 5. Todas las hojas se encuentran al mismo nivel. 6. Un nodo (no hoja) con k descendientes tiene k-1 claves. 7. Un nodo hoja tiene al menos n/2 1 claves y no m as de n-1. Por tanto, un nodo estar a compuesto por una secuencia de claves ordenadas y por un conjunto de punteros (que siempre es mayor que el n umero de claves en una unidad). Las claves ki cumplen que k1 < k2 < k3 < . . . < kn1 y pi apunta a un sub arbol con valores mayores que ki1 y menores que ki .
7.6.2.
Operaciones
La busqueda rbol-B es inmediata: La localizaci on de una clave concreta en un a 1. Partiendo de la ra z se realiza una b usqueda de la clave en el nodo (si es grande el n umero de elementos se realiza una b usqueda binaria). 2. Si la clave k est a en el nodo la b usqueda ha terminado. 3. En caso contrario, suponiendo que la clave ki < k < ki+1 se repite el proceso de b usqueda descencidendo por el sub arbol apuntado por pi . Organizaci on y gesti on de archivos 74 Antonio Aliaga Munoz
2o I.T.I.G./UAL La inserci on
rbol est El mecanismo en que se basa la inserci on para conseguir que el a e siempre completamente balanceado consiste en promocionar la clave central de un nodo que se divide al no poder albergar m as claves (Ver la gura 7.5).
Figura 7.5: Arboles-B Cuando un nodo est a lleno se ordenan todas las claves, incluida la nueva, y se elige la central para situarla en el nodo padre, dividiendo el nodo original en dos nodos cada uno apuntado por un puntero del nodo padre, con la mitad de claves cada uno. Algoritmo de inserci on: rbol donde debe insertarse la nueva clave. 1. Se busca la hoja del a 2. Si el nodo no est a lleno se inserta de forma ordenada en ese nodo. 3. Si el nodo est a lleno: a) Si el n umero de claves es par, se ordena el conjunto de claves m as la nueva y la central se promociona al nodo padre, dividiendo el nodo en dos mitades con el mismo n umero de claves a la izquierda y derecha de la clave promocionada. b) Si el nodo es impar, se promociona una de las dos claves centrales, produci endose una polarizaci on derecha/izquierda al quedar uno de los nodos divididos con una clave m as que el otro. Organizaci on y gesti on de archivos 75 Antonio Aliaga Munoz
2o I.T.I.G./UAL
El algoritmo de inserci on resuelve el problema del desbalanceo porque siempre se promociona la clave que nos conviene (la central). La eliminaci on Se trata de un proceso m as complejo que el de la inserci on. Siempre podemos recurrir a la posibilidad de marcar la clave como borrada manteni endola en la estructrura del rbol, ya que as a se coserva la consistencia para posteriores accesos. L ogicamente tiene el incoveniente de ocupar un espacio innecesario en memoria lo cual requerir a de posteriores reorganizaciones. Si decidimos eliminar la clave debemos recordar las restricciones impuestas a los rboles-b, concretamente que el n a umero de descendientes es al menos n/2 . Algoritmo de borrado: 1. Si se elimina una clave de un nodo hoja que tiene m as de n/2 1 claves, no hay que hacer nada m as (Ver la gura 7.6). 2. Si se borra una clave de un nodo intermedio (no hoja) se sustituye dicha clave por rbol: intercambio (Ver la gura 7.7). su sucesor en el a 3. Si alg un nodo queda con menos claves de las permitidas (insuciencia): a) Se toma una clave prestada de un nodo adyacente (redistribuci on). En realidad, se sustituye la clave eliminada por la del padre y la del padre se sustituye por la del hermano del nodo en el que se elimin o la primera clave (un nodo siempre tiene un hermano adyacente excepto la ra z) (Ver la gura 7.8). Otra forma de plantear la redistribuci on es creando un nodo auxiliar donde insertamos todas las claves de los dos nodos adyacentes (el que ha quedado insuciente y su hermano) adem as de la clave separadora entre ambos que est a en el padre. Una vez realizado este proceso, se elige como clave separadora la clave central, que es la que se coloca en el padre (reemplazando a la anterior), y se se distribuyen el resto de claves entre los dos nodos. b) Si el nodo en el que se va a borrar la clave no tiene nig un hermano adyacente con m as de n/2 1 claves, entonces el pr estamo lo toma del padre realiz andose una consolidaci on o concatenaci on de nodos teniendo como resutado un nodo lleno (Ver la gura 7.9). c) Si el nodo padre no puede prestar ninguna clave a sus hijos, deber a pedir una clave a alg un hermano. Organizaci on y gesti on de archivos 76 Antonio Aliaga Munoz
2o I.T.I.G./UAL
sta s d) Si el nodo que presta la clave es la ra z y e olo tiene una clave, se produce rbol. un descenso en la altura del a Debemos tener en cuenta que las operaciones de inserci on y borrado est an dise nadas rbol. de tal manera que se preserva en todo momento la estructura balanceada del a
Figura 7.6: Arboles-B (eliminaci on simple en una hoja)
7.6.3.
rbol-B Organizaci on del ndice en a
rbol-B es un a rbol equilibrado en el que cualquier camino La estructura del ndice en a desde la ra z hasta una hoja tiene siempre la misma longitud. El n umero de claves que almacena cada nodo (factor de bloqueo) es una unidad menor que el n umero de punteros rbol. Adem a otros nodos del a as existir an otros punteros a los datos (zona maestra). rboles-B en lenguaje C puede ser la siguienUna propuesta de implementaci on de los a te: typedef struct { long posicionRegistro; char clave[80]; long punteroBloqueNivelAnterior; } elementoB;
77
2o I.T.I.G./UAL
Figura 7.7: Arboles-B (eliminaci on simple en un nodo intermedio)
Figura 7.8: Arboles-B (eliminaci on: redistribuci on) typedef struct { long punteroBloqueNivelAnterior; elementoB bloque[FactorDeBloqueo]; Organizaci on y gesti on de archivos 78 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Figura 7.9: Arboles-B (eliminaci on: concatenaci on) } NodoB;
7.6.4.
rboles-B: a rboles-B* Variantes de a
rboles-B es que ser Uno de los inconvenientes que se pueden encontrar en los a a deseable un mayor nivel de aprovechamiento del espacio que se reserva con respecto al que realmente est a ocupado por las claves. Es evidente que en el peor de los casos podr amos tener un arbol-B con m as del 50 % del espacio sin utilizar debido a la propiedad que dice que un nodo tiene al menos n/2 1 claves. rbol-B* es un a rbol-B con alguna de sus propiedades modicadas B asicamente un a para que el nivel de aprovechamiento sea al menos del 66 % (2/3). Propiedades: 1. Cada nodo tiene como m aximo n descendientes. 2. Cada nodo tiene al menos (2n 1)/3 descendientes, excepto la ra z y las hojas. 3. La ra z tiene al menos 2 descendientes, salvo que sea una hoja. 4. Todas las hojas se encuentran al mismo nivel. Organizaci on y gesti on de archivos 79 Antonio Aliaga Munoz
2o I.T.I.G./UAL
5. Un nodo (no hoja) con k descendientes tiene k-1 claves. 6. Un nodo hoja tiene al menos (2n 1)/3 claves y no m as de n-1. rboles-B* trae apareSin embargo, este tipo de denici on de las propiedades de los a jado el problema de la divisi on del nodo ra z, ya que siempre se toman dos nodos para obtener a partir de ellos tres nodos nuevos con las claves redistribuidas, y resulta que la ra z no tiene ning un hermano para poder realizar esta operaci on. Existen varias alternativas para solucionar este inconveniente: Hacer que el nodo ra z sea m as grande que el resto de nodos con respecto al n umero de claves que almacena. De esta forma, podr a dividirse en nodos que tendr an sus rboles-B*. Tiene el 2/3 partes llenas, cumpliendo todas las propiedades de los a inconveniente de tener que manejar nodos de diferente tama no, lo cual diculta el desarrollo de los algoritmos. Otra soluci on consiste en realizar una divisi on sencilla del nodo ra z en dos partes rbol-B se tratase) y tener en cuenta en los procedimientos iguales (como si de un a de inserci on y borrado las caracter sticas especiales de estos nodos que descienden directamente de la ra z.
7.7.
Arboles-B+
rboles-B son una estructra que da un excelente acceso para recuperar un registro Los a individual a partir de una clave. Pero si deseamos recuperar una secuencia ordenada de registros y el archivo de datos no est a ordenado, este proceso deberemos hacerlo a partir del ndice lo cual es muy costoso, sobre todo si el ndice est a gestionado en disco. Por otra parte, no conviene tener el archivo de datos ordenado por la baja eciencia que presenta en las operaciones de inserci on y borrado. rboles-B+ resuelven este inconveniente incorporando un puntero en cada hoja a Los a la siguiente. typedef struct { char clave[80]; long punteroBloqueNivelAnterior; } elementoNodoB+; typedef struct { long punteroBloqueNivelAnterior; Organizaci on y gesti on de archivos 80 Antonio Aliaga Munoz
2o I.T.I.G./UAL
elementoNodoB+ bloque[FactorDeBloqueo]; } NodoB+; typedef struct { long posicionRegistro; char clave[80]; } elementoHojaB+; typedef struct { ElementoHojaB+ bloque[FactorDeBloqueo]; long punteroSiguienteHoja; } NodoHojaB+; Como puede observarse, en el primer nivel (hojas) existir an tantos nodos como sean necesarios para almacenar las claves de todos los registros del archivo de datos. Cada hoja contendr a adem as de un puntero a cada registro de datos un puntero adicional a la siguiente hoja, lo cual permitir a acceder secuencialmente de forma r apida a todos los registros del archivo de datos ordenadamente. Los nodos intermedios ya no contienen punteros al stos presentes s archivo de datos, estando e olo en las hojas del primer nivel. En esta es tructura del ndice existe redundancia de informaci on ya que en los nodos intermedios se almacenan entradas del ndice que ya se encuentran en las hojas. Al primer nivel del ndice (hojas) se le llama conjunto secuencial ya que permite realizar un recorrido secuencial r apido y ordenado por la clave.
7.7.1.
rboles-B+: a rboles-B+ de prejo simple Variantes de a
rboles-B+ tal como se han descrito en este cap Uno de los inconvenientes de los a tulo es el alto nivel de redundancia existente debido a la necesidad de tener que duplicar todas las claves de los nodos intermedios en el nivel de las hojas. rboles-B+ de prejo simple eliminan esta redundancia e incluso reducen el Los a prejos de las claves en n umero total de nodos del conjunto del ndice empleando trozos o lugar de la clave completa, y direccionando bloques de registros en lugar de direccionar registros individuales. Por tanto, el archivo de datos (zona maestra) estar a gestionado por bloques de registros manteniendo una secuencia ordenada a trav es de apuntadores de cada bloque al siguiente, todos ellos en el dispositivo de almacenamiento secundario. Se tratar a, por tanto, de una organizaci on encadenada de bloques de registros que constituir a en s misma el conjunto secuencial del ndice. Organizaci on y gesti on de archivos 81 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Por otra parte, el conjunto del ndice (es decir, los nodos intermedios) estar a basdo rbol-B donde las claves son sustituidas por el prejo de entrada al bloque y el en un a rea maestra. correspondiente apuntador al bloque de datos en el a Mantenimiento del ndice Mientras realicemos inserciones o borrados de registros en el conjunto secuencial que no impliquen una reorganizaci on de los bloques de datos, entonces el conjunto del ndice permanece invariable. Si por el contrario los cambios requieren reorganizar m ultiples bloques en el conjunto secuencial, entonces el conjunto del ndice debe reorganizarse conforme a las reglas de rboles-B. los a de bloque El tamano El conjunto secuencial debe tener un tama no de bloque adecuado con respecto al dispositivo de almacenamiento secundario empleado (tama no de sector, de cluster, etc.) y tambi en respecto de la RAM disponible y de las caracter sticas intr nsecas de los registros que gestionemos. El conjunto del ndice debe regirse por los mismos par ametros descritos para el conjunto secuencial. Normalmente, ambos suelen tener el mismo tama no de bloque.
7.8.
rboles-B+ Arboles-B frente a a
rboles-B y B+ son las m Las estructuras basadas en a as utilizadas en la organizaci on de los ndices en la mayoria de sistemas actuales. Caracter sticas comunes: rboles equilibrados lo que permite acceder r Producen a apidamente a cualquier nodo y por tanto al registro de datos. Las operaciones de inserci on y borrado son bastante simples suponiendo un gran ahorro computacional. Diferencias: rboles-B no contienen ning Los a un tipo de redundancia y no precisan alcanzar el primer nivel del ndice para acceder a los registros de datos; son m as r apidos. Organizaci on y gesti on de archivos 82 Antonio Aliaga Munoz
2o I.T.I.G./UAL
rboles-B necesitan m Los a as espacio para almacenar los niveles intermedios, ocupan m as, no obstante al no tener redundancias el tama no total del ndice es menor (aunque no demasiado). rbol-B es m rbol-B+. El conUn recorrido secuencial en un a as costoso que en un a rboles-B+ permite un recorrido secuencial de todo el archijunto secuencial de los a vo de datos muy eciente.
83
2o I.T.I.G./UAL
84
Cap tulo 8 Organizaci on directa. Hashing

8.1. Caracter sticas de la organizaci on hashing
Cuando se exige un alto rendimiento en la lectura directa de registros, los ndices rboles no son todo lo buenos que desear basados en a amos, ya que poseen un orden de eciencia O(log(FB +1) r). Tienen por tanto las siguientes deciencias: Las inserciones y borrados requieren m as de una operaci on. Las lecturas requieren al menos dos operaciones, en el ndice y en los datos. La organizaci on hashing mejora el rendimiento consiguiendo extraer la informaci on nica operaci con una u on de acceso O(1), de tal forma que s olo se realizar a un acceso a disco realizando toda la carga computacional en la RAM. algoritmo (funci La organizaci on hash se basa en la aplicaci on de una funci on o on sta el valor de la direcci hash) a la clave de los registros, proporcionando e on de almacenamiento del registro en un bloque de datos llamado cubo. De una manera ideal no deber a haber dos registros que fueran direccionados por la funci on hash al mismo cubo, o bien, que en cada cubo hubiera espacio suciente para almacenar todos los registros que son direccionados al mismo cubo. Dependiendo del n umero de cubos disponibles para almacenar los registros, y de la funci on hash existen varios tipos de hashing: Est atico. Se necesita conocer a priori el n umero de cubos disponibles. Cerrado. S olo existe un cubo. La funci on hash determina la posici on del registro en el cubo. 85
2o I.T.I.G./UAL
Organizaci on directa. Hashing
Abierto. Existe m as de un cubo, cada uno de ellos almacenando m as de un registro. ste va variando en tiempo Din amico. No se requiere conocer el n umero de cubos, y e de ejecuci on, adapt andose a las necesidades del problema.
8.2.
Elementos que intervienen en la organizaci on hashing

El tama no de los cubos. La densidad de empaquetamiento de los cubos ( ). La funci on hash. La existencia de colisiones.
8.2.1.
Los cubos o unidades de direccionamiento
unidades de Todos los registros se encontrar an almacenados en unos cuantos cubos o del cubo C determina la bondad del m almacenamiento. El tamano etodo hashing, de tal manera que aumentando el tama no, tambi en aumenta la probabilidad de que un registro se pueda alojar en ese cubo, pudiendo llegar a ser igual a 1 (la probabilidad) si existe un nico cubo de tama u no mayor o igual al n umero de registros. Una colisi on se produce cuando un registro es direccionado a un cubo que est a coma necesario disponer de pleto, ocasionando un desbordamiento (overow), para lo cual ser derrama. Cuando existan colisiones ser una zona de desbordamiento o a necesario m as de un acceso para recuperar la informaci on solicitada, perdiendo el m etodo en eciencia. Un tama no de cubo demasiado grande ralentizar a las operaciones de recuperaci on y almacenamiento, siendo necesario analizar todos los registros del cubo antes de realizar dicha operaci on; adem as requerir a mucha RAM para su procesamiento. Se necesita, por tanto, un compromiso entre el valor de este par ametro y el n umero de colisiones que se cluster del producen. El tama no de cubo suele ser un m ultiplo del tama no de bloque o 4096 bytes. sistema operativo: t picamente 512, 1024, 2048 o Dependiendo del tama no de los cubos que hayamos denido en nuestro sistema, el n umero de cubos de que disponemos puede calcularse como: Fc = Organizaci on y gesti on de archivos r C yc= Donde: R Fc 86 Antonio Aliaga Munoz
2o I.T.I.G./UAL
factor de cubo; C Tama Fc Factor de blocaje o no de cubo R Tama no de registro; c N umero de cubos; r N umero de registros.
8.2.2.
La densidad de empaquetamiento
La densidad de empaquetamiento es la raz on entre el n umero de registros y el tama no del espacio de direccionamiento. = r c Fc
Puede observarse claramente que cuando disminuye, tambi en disminuye la probabilidad de que se produzcan colisiones, pero aumenta el desperdicio de espacio de almacenamiento, y viceversa. Podemos rednir el n umero de cubos en funci on de la densidad de empaquetamiento de la siguiente forma: c= r 1 Fc
8.2.3.
La funci on hash
La funci on hash determina la homogeneidad de la distribuci on de los registros en el espacio de almacenamiento. Esta funci on devuelve la direcci on del cubo donde debe ubicarse un registro dado. Un algoritmo que realice una distribuci on uniforme de los registros en los cubos producir a menos colisiones que otro que no realice dicha distribuci on uniforme. Esto tambi en depender a de que las claves de los registros correspondan, a su vez, con una distribuci on uniforme. Las operaciones b asicas que realiza la funci on hash son: 1. Si la clave no es num erica, debe transformarla sin p erdida de informaci on, debiendo ser un proceso reversible. 2. A partir del valor num erico de la clave, se obtendr a un valor dentro del orden de magnitud del n umero de cubos disponibles. Por ejemplo, si se dispone de 2970 cubos, el orden de magnitud es 10000; para 75690 cubos, ser a 100000. 3. Mediante un proceso de translaci on se convierte el valor anteriormente calculado en un n umero de cubo entre 0 y c-1. Organizaci on y gesti on de archivos 87 Antonio Aliaga Munoz
2o I.T.I.G./UAL
8.2.4.
Tratamiento de las colisiones
Una colisi on o desbordamiento se produce cuando la funci on hash direcciona un cubo que est a totalmente ocupado, por lo que ser a necesario almacenar el registro en otra zona distinta llamada zona de derrama o de desbordamiento. Las posibles soluciones a este problema son: Tomar como zona de derrama una zona independiente de la zona maestra, abierta, sin l mites de direccionamiento. rea de derrama se encuentra dentro de la zona maestra, utilizando unos cuEl a bien almacenando los desbordes en los mismos cubos de la zona bos especiales, o maestra.
8.3.
Hashing est atico
Se caracteriza fundamentalmente porque se necesita conocer a priori el n umero de ste jo para el desarrollo del problema. cubos disponibles, siendo e
8.3.1.
Algoritmos hashing
Algoritmo de la divisi on Este algoritmo garantiza una distribucion uniforme de los registros en los cubos siempre y cuando exista una distribuci on uniforme de los valores de las claves. 1. Se elige un divisor d, primo y aproximadamente igual a c, (d c). 2. Ci = modulo(Vi , d); donde Vi = valor de la clave Ki . Caracter sticas: Puede haber espacio desperdiciado debido a cubos que no llegan a utilizarse ya que d c. Los registros con claves consecutivas se almacenan en cubos consecutivos. Ejemplo: Sea: r = 100000 registros; R = 60 bytes/registro; C = 1024 bytes/cubo Por tanto: Fc = 17 registros/cubo y c = 5883 cubos. En consecuencia, tomaremos d = 5881. Organizaci on y gesti on de archivos 88 Antonio Aliaga Munoz
2o I.T.I.G./UAL Algoritmo del centro de los cuadrados
1. Dado un registro Ri , su clave es Ki y su valor num erico es Vi entonces calculamos 2 Vi . Se toman los digitos centrales de igual orden de magnitud que c. En el ejemplo anterior, como c = 5883, su orden de magnitud es < c >= 10000, tomamos los 2 cuatro digitos centrales de Vi obteniendo Vi . 2. Se ajusta el n umero obtenido anteriormente al intervalo [0, c 1] multiplicando por c . Entonces: Ci = Vi ha . la fracci on de ajuste: ha = <c > En el ejemplo anterior, ha = 5883 = 0,5883 10000
Con este algoritmo, claves peque nas van al mismo cubo y claves consecutivas no van a cubos consecutivos.
8.3.2.
T enicas para evitar colisiones
En los algoritmos descritos anteriormente se pretende distribuir las claves en los cubos de forma uniforme de modo que se eviten los desbordes o colisiones. Si se conocen stos es relativamente peque las claves de los registros a priori y el n umero de e no (unos cientos), es relativamente sencillo encontrar un algoritmo que sea capaz de evitar las colisiones. A estos algoritmos se les conoce como hashing perfecto ya que los registros pueden localizarse con s olo una operaci on de lectura. Sin embargo, en la mayor parte de problemas aparecen colisiones de manera inevitable. Podemos dar como aceptable un algoritmo que garantice un m aximo del 10 % de registros con colisiones, para el cual el n umero medio de accesos ser a relativamente bajo. El an alisis de claves El analisis de claves puede realizarse si las conocemos a priori, o bien conocemos el stas pueden variar. El algoritmo tratar intervalo de valores en que e a de encontrar grupos o patrones repetitivos de d gitos elimin andolos, dando lugar as a una distribuci on m as uniforme. Tambi en es posible que se produzcan menos colisiones incorporando un mayor conjunto de atributos a la clave (por ejemplo, el nombre + apellidos + dni). Doble hashing En lugar de evitar las colisiones, lo que se persigue con este m etodo es resolverlo lo m as r apidamente posible aplicando una segunda funci on hash sobre la clave del registro colisionado. Organizaci on y gesti on de archivos 89 Antonio Aliaga Munoz
2o I.T.I.G./UAL Aumento del desperdicio
Bien aumentando la capacidad de los cubos o disminuyendo la densidad de empaquetamiento se consigue un descenso en el n umero de colisiones. Por el contrario, tenemos un aumento del espacio necesario para almacenar la informaci on y un aumento del tiempo de transferencia de los cubos a memoria al tener mayor tama no.
8.3.3.
T ecnicas de resoluci on de colisiones. Operaciones
ste Cuando el algoritmo hashing direcciona un registro a un cubo que est a lleno, e se desborda y se produce una colisi on. Entonces deber a ser almacenado en una nueva zona con sucientes garantias de que pueda ser recuperado en un tiempo razonablemente peque no. El tratamiento de los desbordamientos puede realizarse almacen andolos en el rea maestra, o bien en un a rea espec propio a ca llamada zona de derrama. La elecci on depender a de los factores utilizados en la organizaci on hashing y de las caracter sticas el dispositivo de almacenamiento. rea maestra Tratamiento de los desbordes en el a Todos los desbordes de registros colisionados se almacenan en la propia zona maestra sta. o en alg un espacio reservado dentro de e Almacenamiento de los desbordes en los cubos maestros. Cuando un registro provoca una colisi on, se almacena en otro cubo de la zona maestra que tenga espacio libre. Se elige un cubo pr oximo al elegido en primer lugar (el que provoc o el desborde). 1. Se elige el cubo siguiente. Sencillo de implementar. Presenta problemas de aglomeraci on cuando no existe una distribuci on homog enea de claves. Para encontrar un registro, primero se busca en el cubo elegido y si no est a all se sigue buscando en el siguiente hasta encontrarlo, o bien, hasta encontrar un cubo incompleto (en este caso el registro no existir a). 2. Se elige un cubo distante. La distancia se ja de antemano. Se evita el problema de los amontonamientos, pero funciona mal cuando el nivel de ocupaci on es alto. Estos dos ejemplos presentan varios problemas: Organizaci on y gesti on de archivos 90 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Presenta problemas en la recuperaci on, ya que si el registro no est a en el cubo direccionado hay que seguir leyendo cubos hasta encontrarlo o bien dar con un cubo incompleto. Problemas en la inserci on, ya que para poder insertar hay que leer y analizar el cubo completo para saber si tiene espacio disponible y en caso de estar lleno, deber a procederse de igual manera con el cubo siguiente hasta encontrar un cubo que tuviera espacio disponible. El coste computacional que representa esta operaci on puede paliarse si en cada cubo se reserva un espacio para almacenar un indicador de ocupaci on o una lista de espacio libre. Problemas con los borrados ya que despu es de localizar el cubo con el re ste puede eliminarse (teniendo que reestructurar todo el gistro a borrar, e contenido del cubo) o bien debe marcarse como borrado con un car acter especial. Esto ocasiona graves problemas a la funci on de recuperaci on ya que si antes de borrar el registro el cubo estaba lleno, ahora no lo estar ay el algoritmo de recuperaci on puede devolver un falso NO ENCONTRADOdebido a que ha encontrado un cubo incompleto, o de lo contrario, habr a que analizar todos los cubos hasta el nal. Si se decide no liberar el espacio de los registros borrados se resuelven estos problemas pero se desperdiciar a mucho espacio y se eleva el n umero de colisiones al haber menos espacio libre. 3. Se establece un ndice de cubos de ocupaci on. La localizaci on de un cubo disponible cuando se produce una colisi on se realiza en el cat alogo. El cat alogo se gestiona en memoria. De esta manera se pretende que como m aximo sean necesarios dos accesos para recuperar un registro. Cubos de desborde distribuidos en la zona maestra. Consiste en intercalar uniformemente una serie de cubos entre los cubos de la zona maestra con la condici on de que no pueden ser direccionados por la funci on hash. Por ejemplo, si se inser ste almacenar ta un cubo de desborde cada tres cubos de la zona maestra, e a las colisiones de estos tres cubos. rea independiente Tratamiento de los desbordes en un a rea independiente a la zona maestra, que puede tener cualquier estrucSe trata de un a tura y puede estar organizada de cualquier forma, debiendo ser abierta. Generalmente se trata de una organizaci on encadenada de registros. Bastar a con reservar un espacio en Organizaci on y gesti on de archivos 91 Antonio Aliaga Munoz
2o I.T.I.G./UAL
cada cubo para albergar un puntero al primer registro desbordado del primer cubo en la zona de derrama. Por tanto, en la zona de derrama existen tantas cadenas como cubos. Esta t ecnica es viable y f acil de implementar, pero tiene el inconveniente de los retrasos en las recuperaciones, ya que los registros en la zona de derrama pueden estar muy distantes entre s . Las inserciones con colisiones tambi en son costosas computacionalmente. Esta t ecnica puede mejorarse utilizando una estructura encadenada de cubos en lugar de cadenas de registros. Mejora a la anterior ya que en la mayor parte de los casos solo se necesitar an dos accesos. Por el contrario, desperdicia mucho espacio ya que aunque s olo haya una colisi on se reservar a espacio para un cubo completo.
8.4.
Hashing din amico
La organizaci on hashing ha sido concebida para recuperar la informaci on con un s olo acceso a los dispositivos de almacenamiento secundario, sin embargo, la existencia de una zona de derrama trunca todas las espectativas al respecto. Las colisiones suponen un coste computacional a nadido a las operaciones de lectura, inserci on y borrado, complicando adem as los algoritmos correspondientes, provocando que esta organizaci on no satisfaga los requerimientos para los que fue concebida. El principal problema deriva de la necesidad de la existencia de la zona de derrama debido a que el n umero de cubos es constante y se ja a a priori, sin conocer exactamente qu e claves se van a gestionar dsde un principio, o bien a que la funci on hashno es perfecta. El hashing est atico estudiado hasta ahora permite construir una funci on hash que dis stos no se tribuya uniformemente los registros en el espacio de direccionamiento aunque e conozcan a priori, siempre y cuando su n umero no var e en el tiempo. Sin embargo, el hashig est atico, desde hace d ecadas s olo se emplea para gestionarse en memoria principal y no para el almacenamiento en disco. stos es variaCuando no conocemos el n umero de registros a priori o la cantidad de e ble, el hashing est atico no garantiza la restricci on del n umero de accesos. El hashing din amico surgi o a principios de los a nos ochenta como un conjunto de m etodos y organizaciones que garantizan el acceso a la informaci on con una sola operaci on de transferencia.
8.4.1.
Caracter sticas
Las caracter sticas comunes a todos los m etodos de hashing din amico son: El n umero de cubos no se ja a priori en funci on del n umero de registros actual o esperado, sino que los cubos se crean o destruyen seg un van siendo necesarios. Organizaci on y gesti on de archivos 92 Antonio Aliaga Munoz
2o I.T.I.G./UAL
Suele existir en casi todos los m etodos un cat alogo o directorio que mantiene informaci on del n umero de cubos existentes y su ubicaci on en el dispositivo de almacenamiento. En el cat alogo se guardan los resultados de las salidas de la funci on hash sobre las posibles claves de los registros. Una vez aplicada la funci on hash sobre un registro, se localiza en el cat alogo el cubo elegido obteniendo su direcci on f sica. Los cubos tienen un tama no jo c, pudiendo almacenar un n umero determinado de registros Fc . No existe una zona de derrama, aunque algunos m etodos pueden mantener espacios temporales de registros desbordados. Fundamentalmente, la diferencia principal entre el hashing est atico y el din amico es ste u ltimo el n que en e umero de cubos que puede direccionar la funci on hash puede variar con el tiempo.
8.4.2.
Hashing extensible
Este tipo de organizaci on utiliza una funci on hash que aplicada a una clave de un registro obtiene un valor binario del tama no de la palabra de la computadora (generalmente 32 bits), lo que signica que puede direccionar 232 cubos. Estos cubos se van generando a medida que van siendo necesarios. Por tanto, en cada momento s olo ser an necesarios c del total de c cubos posibles, tomando s olo los i bits menos signicativos (0 i b = 32) de la cadena binaria devuelta por la funci on hash. Todos los valores binarios para un determinado i se almacenan en el cat alogo junto a la direcci on f sica del cubo en el dispositivo de almacenamiento. Al n umero i se llama pt profundidad total del cat alogo pt , siendo 2 el n umero de entradas existentes en cada momento en el cat alogo. Las caracter sticas del hashing extensible que lo diferencian de otros m etodos son: Dado un i en el cat alogo exixten 2i entradas, de las cuales s olo hay presentes c cubos, siendo c 2i . M as de una entrada del cat alogo puede estar asociada a una salida, a un mismo cubo. El n umero de entradas que apuntan a un mismo cubo es 2pt pj . Organizaci on y gesti on de archivos 93 Antonio Aliaga Munoz
2o I.T.I.G./UAL La inserci on
1. Inicialmente, la zona de direccionamiento est a vac a y el cat alogo no existe, debiendo reservarse espacio en el dispositivo de almacenamiento para ambos. 2. Inserciones en profundidad 0. a) No es neceario aplicar la funci on hash al registro. b) Se generan en el cat alogo, que inicialmente est a vac o, 20 entradas (o sea, una entrada). c) Se localiza espacio para un cubo y se almacena all el registro. d) Al cubo se le asigna el valor de profundidad pj = 0, ya que no es necesario ning un bit para direccionar el cubo correspondiente (ya que s olo hay uno). e) Se asigna a la entrada del cat alogo el 0, y como salida, la direcci on del cubo seleccionado. f ) Se van realizando nuevas inserciones hasta que el cubo est e lleno. 3. Inserciones en profundidad 1. a) Se reserva espacio para un nuevo cubo. b) Se inserta una nueva entrada en el cat alogo y se actualiza con la direccci on de salida de cada cubo. c) A los cubos se les asigna el valor de profundidad pj = 1, ya que ahora es necesario un bit para direccionar el cubo correspondiente (ahora hay dos). d) Los registros almacenados en el primer cubo se redistribuyen entre los dos cubos en funci on del bit menos signicativo del valor devuelto por la funci on hash aplicada a cada clave. e) Se van realizando nuevas inserciones hasta que el cubo est e lleno. 4. Inserciones en profundidad 2. a) Cuando alguno de los cubos se llene, se reservar a espacio para un nuevo cubo y aumentar a la profundidad del cat alogo, siendo pt = 2, teniendo cuatro entradas (00, 01, 10, 11). b) Se reserva espacio para un nuevo cubo. c) El cubo en el que se ha experimentado la colisi on se divide en dos, (los registros se redistribuyen en funci on de los dos bits menos signicativos). d) A los dos cubos nuevos, se asigna el valor de profundidad pj = 2, mientras que el cubo que no produjo ning un colisi on mantiene pj = 1, y en el cat alogo l. hay dos entradas que apuntan a e Organizaci on y gesti on de archivos 94 Antonio Aliaga Munoz
2o I.T.I.G./UAL Observaciones:
Las inserciones en profundidad superior a 2 se realizan de igual forma, desdoblando aquellos cubos que se desbordan por colisiones, y redistribuyendo los registros entre ambos. Cuando la colisi on se produce en un cubo ci cuyo nivel de profundidad pci sea igual al nivel de profundidad total del cat alogo pt , ser a necesario aumentar la profundidad del cat alogo en una unidad, originando nuevas entradas, y por tanto, haciendo que varias de ellas apunten a un mismo cubo. La reorganizaci on de los cubos implica aplicar de nuevo la funci on hash a cada registro para saber a cual de los nuevos cubos ir a destinado, lo cual no es demasiado costoso por realizarse en memoria. Sin embargo, la reorganizaci on f sica de los regoistros en dichos cubos s puede se costosa, tanto m as cuanto mayor sea el tama no de los cubos c. Suponiendo que el cat alogo no es demasiado grande, pordr a gestionarse ntegramente en memoria. La recuperaci on La recuperaci on de un registro consistir a simplemente en: 1. Aplicar la funci on hash a la clave del registro. 2. Tomar s olo los bits menos signicativos correspondientes a la profundidad del cat alogo pt . 3. Acceder a la entrada del cat alogo correspondiente y obtener la direcci on del cubo donde se debe encontrar. 4. Cargar el cubo en memoria y analizar la existencia all del registro. Si no se encuentra en el cubo es que no est a almacenado (ventajas de no tener zona de derrama). El borrado Para borrar un registro, primero ha de localizarse el cubo correspondiente, y despu es de transferirlo a memoria y reorganizarlo se vuelve a grabar. Si el proceso de borrado da ste y se reorganiza el cat lugar a que un cubo queda vac o, se libera el espacio de e alogo. Se proceder a de igual forma si es posible reunir los registros de dos cubos en uno s olo. Organizaci on y gesti on de archivos 95 Antonio Aliaga Munoz
2o I.T.I.G./UAL
En caso de que el cubo quede vac o, se libera su espacio y en el cat alogo se actualiza su entrada para que apunte al cubo gemelo, que es aqu el en el que s olo var a el bit de signicancia pt . Si no existe ning un cubo gemelo, el nivel de profundidad del cat alogo puede disminuir en una unidad. Tambi en puede disminuir el n umero de cubos sin que ninguno quede vac o, siempre que el n umero de registros total en los cubos gemelos sea menor que Fc ; en tal caso, se reunicar an ambos cubos.
96

Apuntes

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Apuntes

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD DE ALMERIA

Escuela Polit ecnica Superior Ingenier a T ecnica en Inform atica de Gesti on

Organizaci on y Gesti on de Archivos

Antonio Aliaga Munoz

5. Conceptos b asicos sobre ndices Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Antonio Aliaga Munoz

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

4.1. 4.2. 4.3. 4.4. 4.5.

2o I.T.I.G./UAL 7.7. 7.8. 7.9.

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Parte I Almacenando informaci on: discos y archivos

Cap tulo 1 Almacenamiento de datos

Introducci on hist orica

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Organizaci on de los discos

Figura 1.1: Esquema interno de un disco magn etico.

Capacidad del disco

Organizaci on de pistas por sectores

Organizaci on de las pistas por bloques

Espacio reservado o de control (nondata overhead)

El coste del acceso a disco

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

El disco como cuello de botella

Cintas magn eticas

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Cap tulo 2 Archivos

Archivos f sicos y archivos l ogicos

Operaciones principales sobre archivos

2o I.T.I.G./UAL alto nivel.

Leer y escribir en archivos

Posicionamiento (seek) en archivos

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Cap tulo 3 Elementos b asicos de las estructuras de archivos

Elementos b asicos de las estructuras de archivos

Figura 3.1: Formas de estructurar un archivo en campos.

Comenzar cada campo con un indicador de longitud

Elementos b asicos de las estructuras de archivos

Utilizar un delimitador al nal de cada campo

Utilizar una expresi on

Organizaci on y gesti on de archivos

Antonio Aliaga Munoz

Elementos b asicos de las estructuras de archivos

Figura 3.2: Formas de estructurar un archivo en registros.

Registros de longitud ja en numero de bytes

Registros de longitud ja en numero de campos

Elementos b asicos de las estructuras de archivos

Comenzar cada registro con un indicador del numero de bytes de longitud

Utilizar un archivo auxiliar donde se indica la posici on de inicio de cada registro

Utilizar un delimitador al nal de cada registro

Buffers y bloques de registros