UNIVERSIDAD TECNOLÓGICA CENTROAMERICANA UNITEC

ESTRUCTURA DE DATOS II

SECCION 1248

RESUMEN DE CAPITULO 5, FILE STRUCTURES

REALIZADO POR:

Rene Andres Dubon Pascua 22051092

CATEDRATICO:
Ing. Carlos Arias

FECHA:
13/05/2023

LUGAR:
Campus San Pedro Sula, UNITEC
1. FILE ACCESS AND FILE ORGANIZATION

Estudiar las relaciones entre la arquitectura de los archivos y el acceso a ellos, resulta ser de
provecho; ya que nos puede dar una idea de como armar un programa eficiente para recorrer el
archivo. Por ejemplo, cuando se sabe el tamaño de los campos y de los récords, es posible
realizar búsquedas directas ya que se puede calcular el offset de bytes; sin embargo, cuando no se
sabe el tamaño de campos o de récords en general se realiza una búsqueda secuencial. Es posible
realizar búsquedas secuenciales en archivos de campos fijos, y búsquedas (relativamente)
directas con archivos de longitud variable.
Es importante remarcar que no hay un tipo de arquitectura de archivo perfecto, elegir una
arquitectura fija cuando la variación es necesaria y elegir una arquitectura variable cuando la
variación es despreciable resulta en manejos ineficientes de memoria. Hay que tomar en
consideración también las limitaciones del programa, ya que en algunos casos los archivos tienen
que ser guardados con un formato especial.

2. BEYOND RECORD STRUCTURES

En décadas anteriores, manejar archivos resultaba una tarea mas complicada debido a las
limitaciones de la era como el nivel del programa, y las herramientas disponibles para visualizar
datos. Hoy en día, el concepto de un objeto de datos para manejar archivos especiales como, por
ejemplo, documentos, videos, imágenes, etc. es común y resulta bastante útil a la hora de
imaginarse los métodos y propiedades que podrían tener esta agrupación de datos específicas.
Estos objetos son asociados con modelos abstractos de datos que se enfocan mas en la forma que
una cierta aplicación observa los datos como archivos de sonido, texto, etc; en vez de la forma en
la cual los datos están guardados; esto nos permite tener un punto de vista mas enfocado en las
aplicaciones de los archivos, en vez del medio de estos.
Los archivos pueden ser escritos con headers que indican información o metadata acerca de los
objetos contenidos en el archivo. Por ejemplo, se pudiera incluir el nombre de los campos, su
longitud, y cuantos campos por récord, entre más información incluya nuestro header, menos
tienen que saber el software de nuestros objetos. Existen clases que nos permiten implementar
esto como por ejemplo el método write header de la fixed field class, que describe la cantidad de
campos, sus tamaños, y el read header que nos verifica la integridad de los objetos guardados. Es
posible también instanciar un objeto de tipo fixed field buffer a través de un header.
La metadata provee información de los datos primarios en un archivo, es comúnmente
posicionada en los headers de los archivos y resulta bastante útil a la hora de interpretar los datos
de un archivo, cuando suficientes usuarios les interesa un tipo de dato en particular. Es común
que se llegue a un formato estándar para permitir el fácil envio y comprensión de los datos en los
archivos, como por ejemplo el formato FITS que indica la forma en la cual se interpretan fotos
espaciales.
Otro ejemplo de objeto de datos, pueden ser las color raster image, que son matrices de pixeles
que corresponden a valores numéricos que pueden ser convertidos a color en la pantalla. Dentro
de estos archivos, podemos incluir metadata útil, como la dimensión de esta matriz (filas de
pixeles y columnas de pixeles), la cantidad de bytes asociados a los pixeles, y una leyenda que
indica que color se debería utilizar si se elige x valor de pixel. Visto desde el punto de vista
funcional de este objeto de dato, es una imagen y nos podría interesar poder ver esta imagen en
una pantalla, poder guardarla, poner una imagen sobre otra, o demostrar varias imágenes para
animación.
Otro concepto importante en los headers son las keywords, que se usan para identificar los
campos que se leerán mas adelante en el programa. Se puede expandir el tema un poco e incluir
también tags que definen que tipo de objeto guardaremos en un programa. Por ejemplo, en un
mismo archivo se puede tener un header para cada objeto, y en este header se puede tagear que
tipo de objeto será, una imagen, un documento, un audio, etc. Estos tags, pueden también estar
contenidas en un índice al principio del archivo, para saber que tipo de objeto vendrá, antes de
leer el header. De hecho, hoy en día los tags son un concepto bastante utilizado en formatos
estándares de archivos.
El concepto de archivos con varios objetos es interesante, sin embargo el nivel de complejidad
aumenta en el archivo; es necesario saber cómo leer y escribir los distintos objetos, además de su
posición en bytes. Las respuestas están relacionadas con las tablas de índices y apuntadores a los
objetos. Dado que trabajamos ahora con modelos de datos abstractos, por ejemplo una imagen,
nuestros programas tienen que ser capaces de poder acceder a un archivo en un cierto formato y
procesar la imagen de acuerdo; ósea su representación en archivos no importa y decimos que el
programa es independiente a la representación.

3. Portability and standardization

Es común que se quiera compartir archivos entre usuarios, lo que abre paso a la portabilidad de
los programas que posible gracias a la estandarización. Es importante considerar que los sistemas
operativos manejan los datos de manera distinta, de igual manera el lenguaje afecta la forma en
la que se trabajan los archivos (con pascal, todos los campos deben tener el mismo tamaño). La
arquitectura de hardware puede afectar también debido a preferencias de administración de
memoria, un mismo programa puede ser corrido en 3 distintas máquinas y producir 3 distintos
resultados.
Para alcanzar la portabilidad de tienen que llegar a estándares y a acuerdos sobre cómo lidiar con
las diferencias entre sistemas. Por ejemplo, se puede acordar a trabajar bajo un formato físico
especifico, es decir un archivo que se guarda en un formato especial igual siempre,
independientemente del sistema que se use. Es común que se desee cambiar el formato una vez
establecido para “mejorarlo” y es posible, pero le quita un poco de valor al significado de
formato estándar.
Es posible también acordar a un estándar de encriptación de datos binarios. Con la tabla ASCII
cubrimos la mayoría de los caracteres relevantes, sin embargo con los datos binarios es muy
probable que se tengan distintos métodos de leer datos. Para mitigar este efecto, se han formado
estándares para la lectura y escritura de binarios, como el de IEEE, y el de XDR.
Es común que los formatos de archivos sean distintos, lo que requiere métodos especiales para
traducir de un formato hacia otro. En vez de hacer un x – y traductor, es común un x – XDR y
XDR -y traductores, ya que cuando son varios distintos formatos esto resulta mas directo.
Alternativamente, en algunos casos los software developers prefieren simplemente programar
para un solo formato y dejar la responsabilidad en los usuarios de respetarlos.