Características del enfoque de bases de datos

Hay varias características que distinguen el enfoque de base de datos del enfoque tradicional de programación con archivos.

En el procesamiento de archivos tradicional, cada usuario define e implementa los archivos requeridos para una aplicación específica. Por ejemplo, un usuario, la oficina de contabilidad, podría mantener un archivo de clientes; se escribirían programas para trabajar con estos clientes y un segundo usuario, la oficina de ventas, mantendría otro archivo de clientes con sus programas específicos. Aunque ambos usuario están interesados en datos relativos a los clientes, cada uno mantiene archivos separados –y programas para manipular dichos archivos porque requieren datos que no pueden obtener de los archivos del otro. Esta redundancia al definir y almacenar los datos implica espacio desperdiciado y esfuerzos redundantes para mantener actualizados los datos comunes.

En el enfoque de bases de datos se mantiene un único almacén de datos que se define una sola vez y al cual tienen acceso muchos usuarios.

Las principales características del enfoque de base de datos, es comparación con el procesamiento de archivos, son las siguientes:

• Naturaleza auto descriptiva de los sistemas de base de datos.

Una característica fundamental del enfoque de bases de datos es que el sistema no sólo contiene la base de datos propiamente dicha, sino también una definición o descripción completa de la misma. Esta definición se almacena en el catalogo del sistema, que contiene información y diversas restricciones que se aplican a los datos. A la información almacenada en el catálogo se le denomina METADATOS, y estos describen la estructura de la base de datos.

El catalogo es utilizado por el software del DBMS y, ocasionalmente por los usuarios de la base de datos que necesitan información sobre la estructura de esta ultima. El software del DBMS no esta escrito para una aplicación de base de datos especifica, así que tiene que consultar el catalogo para conocer la estructura de los archivos de una base de datos en particular, como el tipo y formato de los datos los tendrá acceso.

En nuestro ejemplo, el DBMS almacena en el catalogo las definiciones de los cuatro archivos mencionados. Siempre que se recibe una solicitud para tener acceso, por ejemplo, al Nombre de un registro CLIENTE, el software del DBMS consultará el catalogo para determinar la estructura del archivo CLIENTES y la posición y el tamaño del elemento Nombre dentro de un registro de CLIENTES. En cambio, en una aplicación de procesamiento de archivos tradicional, la estructura del archivo y, en algunos casos, la ubicación exacta de Nombre dentro de un registro CLIENTES ya está codificadas en todos los programas que tienen acceso a este elemento de la información.

• Separación entre los programas y los datos. Abstracción de los datos.

En el procesamiento de archivos tradicional, la estructura de los archivos de datos viene integrada en los programas de acceso, así que cualquier modificación de la estructura de un archivo puede requerir la modificación de todos los programas que tienen acceso a dicho archivo.

En cambio, los programas de acceso del DBMS se escriben en modo que sean independientes de los archivos específicos. La estructura de los archivos de datos se almacena en el catalogo del DBMS separada de los programas de acceso. Llamamos a esta propiedad independencia con respecto a los programas y datos.

La característica que hace posible esta independencia se denomina abstracción de los datos.

Un DBMS ofrece a los usuarios una representación conceptual de los datos que no incluye muchos de los detalles de cómo se almacenan. En términos informales, un modelo de datos es un tipo de abstracción de los datos con que se obtiene esta representación conceptual. En el modelo de datos intervienen conceptos lógicos, como serian los objetos, sus propiedades y sus interrelaciones, que la mayoría de los usuarios pueden entender más fácilmente que los conceptos de almacenamiento en la computadora. Por tanto, el modelo de datos oculta los detalles de almacenamiento que no interesan a la mayoría de los usuarios de base de datos. En el enfoque de base de datos, la estructura y organización detalladas de todos los archivos se guardan en el catalogo. Los usuarios de la base de datos hacen referencia a la representación conceptual de los archivos, y el DBMS extrae del catalogo los detalles de almacenamiento de estos cuando los necesita. Hay muchos modelos de datos que sirven para ofrecer a los usuarios esta abstracción de los datos.

 

• Compartimiento de datos y procesamiento de transacciones multiusuario.

Todo DBMS multiusuario debe permitir a varios usuarios tener acceso simultaneo a la base de datos. Esto es indispensable para que los datos de múltiples aplicaciones se integren y mantengan en una sola base de datos. El DBMS debe incluir un software de control de concurrencia para asegurar que, cuando varios usuarios intenten actualizar los mismos datos, lo hagan de manera controlada para que el resultado de las actualizaciones sea correcto. Un ejemplo seria el caso de varios encargados de reservaciones que trataran de asignar un asiento en un vuelo comercial; el DBMS debe garantizar que solo un empleado tenga acceso a un asiento determinado en un momento dado para asignarlo al pasajero. En general, se dice que estas son aplicaciones del DBMS multiusuario es asegurar que las transacciones se realicen de manera correcta sin interferencias.

• Control de redundancias.

En la creación tradicional de programas con procesamiento de archivos, cada grupo de usuarios mantiene sus propios archivos para manejar sus aplicaciones de procesamiento de datos. Por ejemplo, la oficina de contabilidad y la de ventas que mencionábamos antes. Una buena parte de los datos se almacenaría dos veces, una vez en los archivos de cada grupo de usuarios.

Esta redundancia en el almacenamiento de los mismos datos provoca varios problemas.

1. Es necesario realizar una misma actualización lógica como introducir datos de un nuevo cliente varias veces: una vez en cada archivo en el que se registren los datos de los clientes. Esto implica una duplicación del trabajo.
2. Se desperdicia espacio de almacenamiento al guardar los mismos datos en varios lugares, y este problema puede ser grave si las bases de datos son grandes.
3. Es posible que los archivos que representan los mismos datos se vuelvan inconsistentes, quizá porque una actualización se haya aplicado a ciertos archivos pero no a otros. Incluso si la actualización digamos, inserción de un nuevo cliente se aplica a todos los archivos apropiados, persiste la posibilidad de que los datos relacionados con el cliente sean inconsistentes porque cada grupo de usuarios aplica las actualizaciones de manera independiente. Por ejemplo, un grupo de usuarios podría introducir como dirección de un cliente el valor erróneo “Charrúa 1510”, mientras que los demás grupos de usuarios introducirían el valor correcto “Charrúa 1511”. Con el enfoque de base de datos, las visiones de los diferentes grupos de usuarios se integran durante el diseño de la base de datos. Para conservar la consistencia, debe crearse un diseño que almacene cada dato lógico como el nombre o la dirección de un cliente en un solo lugar de la base de datos. Esto evita la inconsistencia y ahorra espacio almacenamiento. En algunos casos, puede convenir la redundancia controlada: allí el DBMS deberá ser capaz de controlar la que en todos los lugares aparezca la misma información.

Representación de vínculos complejos entre los datos.

Una base de datos puede contener numerosos conjuntos de datos estén relacionados entre si de muchas maneras. Es nuestro ejemplo, el registro de “Adriana Martínez” en el archivo CLIENTES se relaciona con 2 registros del archivo FACTURAS. De manera similar, cada registro del archivo LINEAS_FACT se relaciona con un registro del archivo FACTURAS, y con un registro del archivo PRODUCTOS. Por otro lado, cada registro del archivo PRODUCTOS se relaciona con muchos del archivo LINEAS_FACT.

Es preciso que el DBMS pueda representar diversos vínculos de los datos, y también obtener y actualizar con rapidez y eficiencia datos que estén mutuamente relacionados.

Cumplimiento de las restricciones La mayor parte de las aplicaciones de base de datos tienen ciertas restricciones que deben cumplir los datos. El DBMS debe ofrecer recursos para definir tales restricciones y hacer que se cumplan. La forma más simple de restricción sobre los datos consiste en especificar un tipo de datos para cada elemento Nombre dentro de CLIENTES debe ser una cadena de no más de 30 caracteres alfabéticos. Otro tipo de restricción que encontramos a menudo, mas complejo, implica especificar que un registro de un archivo debe relacionarse con registros de otros archivos. Por ejemplo, podemos especificar que “todo registro de LINEAS_FACT debe estar relacionado con un registro de FACTURAS”. A este tipo de restricción le llamamos restricción de integridad referencial. Otro tipo de restricción especifica que los valores de los elementos de información sean únicos, por ejemplo “cada registro de CLIENTES debe tener un valor único de “CodCliente” y le llamaremos restricción de unidad (de clave). Estas restricciones se derivan de la semántica (o significado) de los datos y el minimundo que representa. Es responsabilidad de los diseñadores de la base de datos identificar las restricciones durante el diseño. Algunas restricciones se pueden especificar en el DBMS, el cual hará automáticamente o en el momento en que se introducen los datos.