2.2 Funciones De un DBMS:

Analicemos ahora las funciones del DBMS con un poco más de detalle..

Dichas funciones comprenderán por lo menos el manejo de todas las siguientes Definición de datosEl DBMS debe ser capaz de aceptar definiciones de datos (esquemas externos, el esquema conceptual, el esquema interno y todas las transformaciones respectivas) en la forma fuente y convertirlas a la forma objeto correspondiente. En otras palabras, el DBMS debe incluir entre sus componentes un procesador DDL, o compilador DDL, para cada uno de los diversos DDLs (lenguajes de definición de datos). El DBMS también debe "entender"


Definiciones DDL, en el sentido que, por ejemplo, "entienda" que los registros externos EMPLEADO incluyen un campo SALARIO; entonces, debe poder utilizar este conocimiento para analizar y responder a las peticiones de manipulación de datos (por ejemplo. "Obtener todos los empleados con salario < $50,000").

• Manipulación de datos

El DBMS debe ser capaz de manejar peticiones para recuperar, actualizar o eliminar datosexistentes en la base de datos o agregar nuevos datos a ésta. En otras palabras, el DBMS debe incluir un componente procesador DML o compilador DML para tratar con el DML (lenguaje de manipulación de datos).

1. En general, las peticiones DML pueden ser "planeadas" o "no planeadas":

a. Una petición planeada es aquella cuya necesidad fue prevista antes del momento de eje cutar la petición. Probablemente el DBA habrá afinado el diseño físico de la base de datos de tal forma que garantice un buen desempeño para las peticiones planeadas.
b. En contraste, una petición no planeada es una consulta ad hoc; es decir, una petición para la que no se previó por adelantado su necesidad, sino que en vez de ello, surgió sin pensarlo. El diseño físico de la base de datos podría o no ser el adecuado para la peti
ción específica en consideración.

las peticiones planeadas son características de las aplicaciones "operacionales" o de "producción", mientra que las peticiones no planeadas son características de las aplicaciones de "apoyo a la toma de decisiones". Además, peticiones planeadas serán emitidas generalmente desde programas de aplicación preescritos, mientras que las no planeadas, por definición, serán emitidas

en forma interactiva mediante algún procesador del lenguaje de consulta. Nota: Como vimos en el capítulo 1, el procesador del lenguaje de consulta es en realidad una aplicación integrada en línea, no una parte del DBMS como tal;

Optimización y ejecución
Las peticiones DML, planeadas o no planeadas, deben ser procesadas por el componente optimizador, cuya finalidad es determinar una forma eficiente de implementar la petición. En
el capítulo 17 explicamos la optimización en detalle. Las peticiones optimizadas se ejecutan entonces bajo el control del administrador en tiempo de ejecución. Nota: En la práctica, el administrador en tiempo de ejecución recurrirá probablemente a algún tipo de administrador de archivos para acceder a los datos almacenados. Al final de esta sección explicamos brevemente los administradores de archivos.

• Seguridad e integridad de los datos El DBMS debe vigilar las peticiones del usuario y rechazar todo intento de violar las restricciones de seguridad y de integridad definidas por el DBA. Estas tareas pueden realizarse durante el tiempo de compilación, de ejecución o entre ambos.


• Recuperación de datos y concurrencia El DBMS —o más probablemente, algún otro componente de software relacionado, denominado comúnmente administrador de transacciones o monitor de procesamiento de transacciones (monitor PT)— debe imponer ciertos controles de recuperación y concurrencia. Nota: El administrador de transacciones no se muestra debido a que, por lo regular, no forma parte del DBMS como tal.


• Diccionario de datos El DBMS debe proporcionar una función de diccionario de datos. Este diccionario puede ser visto como una base de datos por derecho propio (aunque una base de datos del sistema mí que como una base de datos del usuario). El diccionario contiene "datos acerca de los datos" (en ocasiones llamados metadatos o descriptores); es decir, definiciones de otros objetos del sistema, en lugar de simples "datos en bruto". En particular, todos los diversos esquemas y transformaciones (externos, conceptuales, etcétera) y todas las diversas restricciones de seguridad y de integridad, serán almacenadas en el diccionario, tanto en forma fuente como objeto. Un diccionario extenso incluirá además mucha información adicional; mostrará por ejemplo qué programas utilizan qué partes de la base de datos, qué usuarios necesitan qué informes, etcétera. El diccionario podría incluso —y de hecho, debería— estar integrado dentro de la base de datos que define, e incluir por lo tanto su propia definición. En realidad, debe ser posible consultar el diccionario del mismo modo que cualquier otra base de datos, de manera que, por ejemplo, sea posible saber qué programas o usuarios se podrían ver afectados por un cambio propuesto al sistema. Para una explicación más amplia,Nota: Aquí estamos tocando un área en la que hay mucha confusión de terminología. Algunas personas podrían referirse a lo que nosotros llamamos diccionario como directorio o catálogo —con la implicación de que los directorios y catálogos son, en cierta forma. inferiores a un verdadero diccionario— y podrían reservar el término diccionario para hacer referencia a una clase específica (importante) de herramienta de desarrollo de aplicaciones. Otros términos que también son utilizados, a veces, para hacer referencia a este último tipo de objeto son depósito de datos y enciclopedia de datos.


• Rendimiento Sobra decir que el DBMS debe realizar todas las tareas antes identificadas de la manera más eficiente posible.

Podemos resumir todo lo anterior diciendo que la finalidad general del DBMS consiste en proporcionar una interfaz de usuario para el sistema de base de datos.
Podemos definir la interfaz de usuario como un límite en el sistema debajo del cual todo es invisible para el usuario. Por lo tanto, por definición la interfaz de usuario se encuentra en el nivel externo. Concluimos esta sección con una breve comparación entre los sistemas de administración de bases de datos y los sistemas de administración de archivos (administradores de archivos, o servidores de archivos, para abreviar). En esencia, el administrador de archivos es el componente del sistema operativo subyacente que administra los archivos almacenados; por lo tanto, hablando en términos generales, está "más cerca del disco" de lo que lo está el DBMS. (De hecho, el DBMS es generalmente construido sobre algún tipo de administrador de archivos.) Por lo tanto, el usuario de un sistema de administración de archivos podrá crear y destruir archivos almacenados y realizar operaciones sencillas de recuperación y actualización sobre registros almacenados en dichos archivos. Sin embargo, en contraste con el DBMS:

• Los administradores de archivos no están al tanto de la estructura interna de los registros almacenados, de ahí que no puedan manejar peticiones que se basen en el conocimiento de esa estructura.


• Por lo regular ofrecen poco o ningún soporte zara las restricciones de seguridad y de integridad.


• Por lo regular ofrecen poco o ningún soporte para los controles de recuperación y con currencia.


• No hay un concepto real de diccionario de datos en el nivel del administrador de archivos.Proporcionan mucho menos independencia de datos que el DBMS.


• Por lo regular los archivos no están "integrados" o "compartidos" en el mismo sentido que en una base de datos (normalmente son exclusivos de cierto usuario o aplicación en particular).

Blibliografia: Introducción A Los Sistemas Computacionales, C.j Date, Pearson Education.