Ya se ha visto lo importante que es para el diseñador de sistemas de archivos considerar la forma en que se accede a ellos cuando se organiza el archivo. En este trabajo se verá que el diseñador también debe considerar los tipos de cambios que probablemente tendrán lugar en la vida de un archivo. Si un archivo es muy volátil (sometido a inserciones o eliminaciones frecuentes) y se usa en un ambiente de tiempo real, la organización del archivo debe facilitar cambios rápidos en registros individuales en tiempo real, sin interferir el acceso del usuario al archivo, un ejemplo, de un archivo volátil usado en tiempo real es un archivo de reservaciones en un sistema de reservaciones en línea.

En el otro extremo está un archivo fuera de línea, el cual se somete a relativamente pocos cambios y no necesita mantenerse absolutamente actualizado; puede actualizarse en procesamiento por lotes y no precisa que se incluyan estructuras adicionales para facilitar cambios rápidos, un ejemplo, de este tipo de archivos puede ser un archivo de lista de correos. El mantenimiento de archivos es importante, pues el desempeño se deteriora conforme se hacen cambios al archivo, por ejemplo, supongamos que se modifica un registro en un archivo de registros de longitud variable, de tal forma, que el nuevo registro resulta ser más grande que el original, ¿Qué se hace con los datos adicionales?

En la introducción a este punto observamos que los tipos de modificación que pueden hacerse en un esquema de base de datos relacional son bastantes simples:

• Crear o quitar una relación.
• Añadir o eliminar atributos de un esquema de relaciones.

Esta simplicidad no se cumple en los esquemas de bases de datos orientadas a objetos.

1. Cambios Complejos: los tipos de modificación que pueden hacerse en un esquema orientado a objetos son más complejos que los que pueden hacerse en un esquema de base de datos relacional.
2. Cambios Frecuentes: las aplicaciones que motivan el uso del modelo orientado a objetos requieren cambios de esquema frecuentes, las aplicaciones de diseño a menudo implican: la alteración de la estructura del elemento que se está diseñando, mientras en el ejemplo bancario, los datos descriptivos que se requieren para préstamos, cuentas, etc., cambian relativamente poco.

1. Adición de una Nueva Clase: esta adición en una base de datos orientada a objetos implica más de lo que implicaba la adición de un esquema de relaciones en una base de datos relacional, la nueva clase debe colocarse en la jerarquía de Clase / Subclase o D. A. G., y deben resolverse los problemas de herencia. Si la nueva clase no es un nodo hoja en la jerarquía o el D. A. G., puede que las subclases de la nueva clase necesita heredar variables o métodos de la nueva clase, lo mismo se aplica a las subclases y así sucesivamente.
2. Eliminación de una Clase: la eliminación en una base de datos orientada a objetos requiere varias operaciones, las variables y los métodos que heredan las subclases se deben volver a eliminar. Cualquier cambio en una subclase puede que necesite propagarse a las subclases, y así sucesivamente; las instancias de las clases eliminadas deben hacerse instancias de otra clase, generalmente un padre de la clase eliminada.
3. Modificación de una Definición de Clase: puede definirse una nueva o variable o método o puede eliminarse una definición de una variable o un método, como en los casos anteriores, la definición de las subclases puede verse afectada.
4. Reposición de Clases de la Jerarquía o el D. A. G.: toda reestructuración tiene consecuencias en la herencia de las antiguas y nuevas subclases de la clase reposicionada.

Una modificación de esquema orientado a objetos que se complica más es el hecho de que las instancias de las clases modificadas deben modificarse para ajustarse a la nueva definición, para una base de datos grande, la cantidad de procesamiento que se requiere para efectuar este cambio es considerable.