Administración de Bases de Datos (página 2)

Usuarios

Existen tres grandes clases de usuarios:

• Programadores de aplicaciones, que son los responsables de escribir los programas de aplicación de base de datos en algún lenguaje de programación. Estos programas acceden a la base de datos emitiendo la solicitud apropiada al DBMS. Los programas en sí pueden ser aplicaciones convencionales por lotes o pueden ser aplicaciones en línea, cuyo propósito es permitir al usuario final el acceso a la base de datos desde una estación de trabajo o terminal en línea.
• Los usuarios finales, quienes interactúan con el sistema desde estaciones de trabajo o terminales en línea. Un usuario final puede acceder a la base de datos a través de las aplicaciones en línea, o bien puede usar una interfaz proporcionada como parte integral del software del sistema de base de datos. Las interfaces proporcionadas por el fabricante están apoyadas también por aplicaciones en línea, aunque esas aplicaciones están integradas, es decir, no son escritas por el usuario. La mayoría de los sistemas de base de datos incluyen por lo menos una de estas aplicaciones integradas.
• La mayoría de los sistemas proporcionan además interfaces integradas adicionales en las que los usuarios no emiten en absoluto solicitudes explícitas a la base de datos, sino que en vez de ello operan mediante la selección de elementos en un menú o llenando casillas de un formulario. Estas interfaces controladas por menús o por formularios tienden a facilitar el uso a personas que no cuentan con una capacitación formal en tecnología de la información (IT). En contraste, las interfaces controladas por comandos tienden a requerir cierta experiencia profesional en IT, aunque tal vez no demasiada. Por otra parte, es probable que una interfaz controlada por comandos sea más flexible que una controlada por menús o por formularios, dado que los lenguajes de consulta por lo regular incluyen ciertas características que no manejan esas otras interfaces.
• El administrador de base de datos o DBA.

¿Qué es una Base de Datos?

Datos Persistentes

Es una costumbre referirse a los datos de la base de datos como persistentes, esto se refiere de manera intuitiva, que el tipo de datos de la base de datos difiere de otros datos más efímeros. En forma más precisa, se dice que los datos de la base de datos persisten debido a que una vez aceptados por el DBMS para entrar en la base de datos, en lo sucesivo sólo pueden ser removidos de la base de datos por alguna solicitud explícita al DBMS, no como un mero efecto lateral de algún programa que termina su ejecución. Por lo tanto, esta noción de persistencia permite dar una definición más precisa del término base de datos:

Una base de datos es un conjunto de datos persistentes que es utilizado por los sistemas de aplicación de alguna empresa dada.

Hoy en día las bases de datos se utilizan cada vez más también para otro tipo de aplicaciones. De hecho, las empresas mantienen generalmente dos bases de datos independientes; una que contiene los datos operacionales y otra, a la que con frecuencia se le llama almacén de datos, que contiene datos de apoyo para la toma de decisiones. A menudo el almacén de datos incluye información de resumen, la que a su vez se extrae periódicamente de la base de datos operacional.

Entidades y Vínculos

El término entidad es empleado comúnmente en los círculos de bases de datos para referirse a cualquier objeto distinguible que va a ser representado en la base de datos.

Además de las propias entidades básicas habrá también vínculos que asocian dichas entidades básicas. El punto importante con respecto a los vínculos es que son parte de los datos tanto como lo son las entidades básicas. Por lo tanto, deben estar representados en la base de datos al igual que las entidades básicas.

Ambos son utilizados en la elaboración de los diagramas entidad/vínculo o entidad/relación (E/R), que son usados frecuentemente por los diseñadores para ayudar a modelar la base de datos.

Dentro de un diagrama E/R cada vínculo puede relacionarse con una o más de una entidad. Los vínculos que comprenden dos tipos de entidad son vínculos binarios, mientras los que se involucran con tres tipos de entidad se conocen como vínculos ternarios. Los vínculos que se relacionan con una sola entidad siguen siendo binarios, solo que los dos tipos de entidad que están vinculados vienen a ser la misma entidad.

En ocasiones surgen falsas inferencias que pueden causar mal interpretación y vínculos incorrectos entre las entidades, a lo que se le denomina trampa de conexión.

En general, un conjunto determinado de tipos de entidad podría vincularse entre sí en cualquier cantidad de vínculos distintos.

Si una entidad es cualquier objeto acerca del cual se quiere registrar información, entonces un vínculo se ajusta perfectamente a la definición. Por lo que un vínculo puede considerarse como una entidad por derecho propio.

Propiedades

Las entidades, incluyendo los vínculos, poseen propiedades que corresponden a la información que se desea registrar sobre ellas. Por lo tanto dichas propiedades deben estar representadas en la base de datos.

En general, las propiedades pueden ser tan simples o complejas como sea necesario. Cuando las propiedades son simples, se pueden ser representadas mediante tipos de datos simples, incluyendo números, cadenas de caracteres, fechas, horas, etcétera. En contraste, existen propiedades complejas como el dibujo arquitectónico y el texto descriptivo asociado.

Datos y Modelos de Datos

Los datos en realidad son hechos dados, a partir de los cuales es posible inferir hechos adicionales. Esto es exactamente lo que hace el DBMS cuando responde a una consulta de un usuario. Un hecho dado corresponde a su vez a lo que en lógica se denomina proposición verdadera. En base a esto, una base de datos es en realidad una colección de tales proposiciones verdaderas.

Una razón por la que los sistemas de bases de datos relacionales se han vuelto tan dominantes, es que manejan en forma muy directa la interpretación precedente de los datos. Los sistemas relacionales están basados en una teoría formal denominada el modelo de datos relacional, de acuerdo con el cual:

• En tablas, los datos son representados por medio de filas, las que pueden interpretarse directamente como proposiciones verdaderas.
• Se proporcionan operadores para operar sobre las columnas de las tablas, y estos operadores soportan directamente el proceso de inferir proposiciones verdaderas adicionales a partir de las ya dadas.

Sin embargo, el modelo relacional no es el único modelo de datos. Existen otros aunque la mayoría de ellos difieren del modelo relacional en que son hasta cierto grado específicos, en vez de estar basados firmemente en la lógica formal.

Un modelo de datos es una definición lógica, independiente y abstracta de los objetos, operadores y demás que en conjunto constituyen la máquina abstracta con la que interactúan los usuarios. Los objetos permiten modelar la estructura de los datos. Los operadores permiten modelar su comportamiento.

La implementación de determinado modelo de datos es una realización física, en una máquina real, de los componentes de la máquina abstracta que en conjunto constituyen ese modelo.

Entonces, se puede decir que el modelo es aquello que los usuarios tienen que conocer, y la implementación es lo que los usuarios no tienen que conocer. La distinción entre ambos es en realidad sólo un caso de la conocida distinción entre lógico y físico.

Aunque el término modelo de datos es utilizado con dos significados muy distintos, la diferencia entre ambos puede ser caracterizada de esta manera:

• En el primer sentido, un modelo de datos es como un lenguaje de programación cuyos elementos pueden ser usados para resolver una amplia variedad de problemas específicos, pero que en sí y por sí mismos no tienen una conexión directa con ninguno de estos problemas específicos.
• En el segundo sentido, un modelo de datos es como un programa específico escrito en ese lenguaje. En decir, un modelo de datos que toma las características que ofrece algún modelo como el primero y las aplica a cierto problema específico. Puede ser visto como una aplicación específica de algún modelo con el primer significado.

¿Por qué una Base de Datos?

Algunas ventajas que proporciona el uso de un sistema de base de datos sobre los métodos tradicionales son:

• Compactación: Reduce la necesidad de archivos voluminosos en papel.
• Velocidad: La máquina puede recuperar y actualizar datos más rápidamente que un humano. En particular, las consultas específicas sin mucha elaboración pueden ser respondidas con rapidez, sin necesidad de búsquedas manuales o visuales que llevan tiempo.
• Menos trabajo laborioso: Se puede eliminar gran parte del trabajo de llevar a los archivos a mano.
• Actualidad: En el momento que se necesite, se tiene a disposición información precisa y actualizada.

Desde luego, estos beneficios se aplican aún con más fuerza en un entorno multiusuario, donde es probable que la base de datos sea mucho más grande y compleja que en el caso de un solo usuario. No obstante, en el entorno multiusuario hay una ventaja adicional: El sistema de base de datos ofrece a la empresa un control centralizado de sus datos.

Administración de datos y administración de bases de datos

El administrador de datos (DA) es la persona identificable que tendrá la responsabilidad central sobre los datos dentro de la empresa. Ya que los datos son uno de los activos más valiosos de la empresa, es imperativo que exista una persona que los entienda junto con las necesidades de la empresa con respecto a esos datos, a un nivel de administración superior. Por lo tanto, es labor del administrador decidir en primer lugar qué datos deben ser almacenados en la base de datos y establecer políticas para mantener y manejar esos datos una vez almacenados.

El administrador de base de datos (DBA) es el técnico responsable de implementar las decisiones del administrador de datos. Por lo tanto, debe ser un profesional en IT. El trabajo del DBA consiste en crear la base de datos real e implementar los controles técnicos necesarios para hacer cumplir las diversas decisiones de las políticas hechas por el DA. El DBA también es responsable de asegurar que el sistema opere con el rendimiento adecuado y de proporcionar una variedad de otros servicios técnicos.

Beneficios del enfoque de base de datos

• Los datos pueden compartirse

Compartir no solo significa que las aplicaciones existentes puedan compartir la información de la base de datos, sino también que sea posible desarrollar nuevas aplicaciones para operar sobre los mismos datos. Es decir, que sea posible satisfacer los requerimientos de datos de aplicaciones nuevas sin tener que agregar información a la base de datos.

• Es posible reducir la redundancia

En sistemas que no son de bases de datos, cada aplicación tiene sus propios archivos exclusivos. A menudo este hecho puede conducir a una redundancia considerable de los datos almacenados, con el consecuente desperdicio de espacio de almacenamiento. Esto no significa que toda la redundancia puede o debe necesariamente ser eliminada. Sin embargo, sí debe ser controlada cuidadosamente.

• Es posible evitar la inconsistencia

En ocasiones en las que las entidades no coincidan; cuando unas de ellas han sido actualizadas y otras no se dice que la base de datos es inconsistente. Si se elimina la redundancia, entonces no puede ocurrir tal inconsistencia. Como alternativa, si no se elimina la redundancia pero se controla entonces se puede garantizar que la base de datos nunca será inconsistente, asegurando que todo cambio realizado a cualquiera de las entidades será aplicado también a las otras en forma automática. A este proceso se le conoce como propagación de actualizaciones.

• Es posible brindar un manejo de transacciones

Una transacción es una unidad de trabajo lógica, que por lo regular comprende varias operaciones de la base de datos, en particular varias operaciones de actualización. Si se necesitan dos actualizaciones y se declara que ambas son parte de la misma transacción, entonces el sistema puede en efecto garantizar que se hagan ya sea ambas o ninguna de ellas, aun cuando el sistema fallará a la mitad del proceso.

• Es posible mantener la integridad

La integridad se refiere a asegurar que los datos de la base de datos estén correctos. La inconsistencia entre dos entradas que pretenden representar el mismo hecho es un ejemplo de la falta de integridad. Desde luego, este problema en particular puede surgir sólo si existe redundancia en los datos almacenados. No obstante, aun cuando no exista redundancia, la base de datos podría seguir conteniendo información incorrecta. El control centralizado de la base de datos puede ayudar a evitar estos problemas permitiendo que el administrador de datos defina y el DBA implemente las restricciones de seguridad que serán verificadas siempre que se realice una operación de actualización.

• Es posible hacer cumplir la seguridad

Al tener la completa jurisdicción sobre la base de datos, el DBA puede, bajo la dirección apropiada del DBA, asegurar que el único medio de acceso a la base de datos sea a través de los canales adecuados y por lo tanto puede definir las reglas o restricciones de seguridad que serán verificadas siempre que se intente acceder a los datos sensibles. Es posible establecer diferentes restricciones para cada tipo de acceso para cada parte de la información de la base de datos. Sin dichas restricciones la seguridad de los datos podría de hecho estar en mayor riesgo que en un sistema de archivos tradicionales. La naturaleza centralizada de un sistema de base de datos requiere, en cierto sentido, que también sea establecido un buen sistema de seguridad.

• Es posible equilibrar los requerimientos en conflicto

Al conocer los requerimientos generales de la empresa, el DBA puede estructurar los sistemas de manera que ofrezcan un servicio general que sea el mejor para la empresa.

• Es posible hacer cumplir los estándares

Con el control central de la base de datos, el DBA puede asegurar que todos los estándares aplicables en la representación de datos sean observados. Es conveniente estandarizar la representación de datos, en particular como un auxiliar para el intercambio de datos o para el movimiento de datos entre sistemas. En forma similar, los estándares en la asignación de nombres y en la documentación de los datos también son muy convenientes como una ayuda para compartir y entender los datos.

La Independencia de los Datos

Existen dos clases de independencia de los datos, física y lógica.

Los sistemas anteriores a los de base de datos tienden a ser dependientes de los datos. Es decir, la forma en que físicamente son representados los datos en el almacenamiento secundario y la técnica empleada para su acceso, son dictadas por los requerimientos de la aplicación en consideración, significa que el conocimiento de esa representación física y esa técnica empleada para su acceso están integrados dentro del código de la aplicación.

En un sistema de base de datos sería inconveniente permitir que las aplicaciones fuesen dependientes de los datos por las razones siguientes:

• Las distintas aplicaciones requerirán visiones diferentes de los mismos datos.
• El DBA debe tener la libertad de cambiar las representaciones físicas o la técnica de acceso en respuesta a los requerimientos cambiantes, sin tener que modificar las aplicaciones existentes.

La independencia de los datos se puede definir como la inmunidad de las aplicaciones a cambios en la representación física y en la técnica de acceso, lo que implica desde luego que las aplicaciones involucradas no dependen de ninguna representación física o técnica de acceso en particular.

Un campo general es la unidad más pequeña de datos almacenados. La base de datos contendrá muchas ocurrencias o ejemplares de los diversos tipos de campos almacenados.

Un registro almacenado es un conjunto de campos almacenados relacionados. Una ocurrencia de registro almacenado consta de un grupo de ocurrencias de campos almacenados relacionados.

Un archivo almacenado es la colección de todas las ocurrencias existentes actualmente para un tipo de registro almacenado.

En los sistemas que no son de bases de datos, el caso normal es que cualquier registro lógico dado es idéntico a un registro almacenado correspondiente. Sin embargo, éste no es necesariamente el caso en un sistema de base de datos, ya que tal vez el DBA necesita hacer cambios a la representación almacenada de datos aunque los datos, tal y como las aplicaciones los ven, no cambien.

Entre algunos de los aspectos de la representación almacenada que podrían estar sujetos a cambio se encuentran:

• Representación de datos numéricos

Un campo numérico podría estar almacenado en la forma aritmética interna o como una cadena de caracteres. En ambas formas, el DBA debe elegir una base apropiada (binaria o decimal), una escala (flotante o de punto fijo), un modo (real o complejo) y una precisión (el número de dígitos). Podría ser necesario modificar cualquiera de estos aspectos para mejorar el rendimiento, para apegarse a un nuevo estándar o por muchas otras razones.

• Representación de datos de caracteres

Un campo de cadena de caracteres podría ser almacenado mediante cualquiera de los distintos conjuntos de caracteres codificados (ASCII, Unicode).

• Unidades para datos numéricos

Las unidades en un campo numérico podrían cambiar (pulgadas a centímetros).

• Codificación de los datos

En ciertas situaciones podría ser conveniente representar los datos almacenados por medio de valores codificados. Por ejemplo, los colores podrían ser almacenados como un solo digito decimal de acuerdo a un esquema de codificación; 1 = azul, 2 = verde, etc…

• Materialización de los datos

El campo lógico corresponde por lo regular a cierto campo almacenado específico; aunque podría haber diferencias en el tipo de datos, la codificación, etc. En tal caso el proceso de materialización, es decir, la construcción de una ocurrencia del campo lógico a partir de la ocurrencia correspondiente del campo almacenado y presentarla a la aplicación, podría ser considerado como directo. Sin embargo en ocasiones un campo lógico no tendrá una sola contraparte almacenada; en su lugar, sus valores se materializarán por medio de algún cálculo, tal vez sobre varias ocurrencias almacenadas, en este caso el campo sería un campo virtual. Para estos campos el proceso de materialización es indirecto. Sin embargo el usuario podría ver una diferencia entre los campos real y virtual, en tanto que podría no ser posible actualizar una ocurrencia de un campo virtual, al menos no directamente.

• Estructura de los registros almacenados

Dos registros almacenados existentes podrían combinarse en uno. Un cambio así podría ocurrir cuando las aplicaciones existentes están integradas dentro del sistema de base de datos. Lo que implica que el registro lógico de una aplicación podría consistir en un subconjunto propio del registro almacenado correspondiente, es decir, ciertos campos de ese registro almacenado serían invisibles para la aplicación en cuestión.

Como alternativa, un solo tipo de registro almacenado podría ser dividido en dos. Esta separación permitiría que las porciones del registro original utilizadas con menos frecuencia sean almacenadas en un dispositivo más lento. Esto implica que un registro lógico de una aplicación podría contener campos de varios registros almacenados distintos; es decir, podría ser un súper conjunto propio de cualquiera de esos registros almacenados.

• Estructura de los archivos almacenados

Un determinado archivo puede ser implementado físicamente en el almacenamiento en una amplia variedad de formas. Pero ninguna de estas consideraciones deberá afectar de alguna manera a las aplicaciones salvo el rendimiento. Permitir que la base de datos crezca sin dañar de manera lógica las aplicaciones existentes es una de las razones más importantes para requerir, en primer lugar, la independencia de los datos.

Los Sistemas Relacionales y Otros Sistemas

Un sistema relacional es aquel en el que:

• Los datos son percibidos por el usuario como tablas.
• Los operadores disponibles para el usuario son operadores que generan nuevas tablas a partir de las anteriores.

El usuario de un sistema relacional ve tablas y nada más que tablas. En contraste el usuario de un sistema no relacional ve otras estructuras de datos, ya sea en lugar de las tablas de un sistema relacional o además de ellas. A su vez, esas otras estructuras requieren de otros operadores para manipularlas. En un sistema jerárquico, los datos son representados ante el usuario como un conjunto de estructuras de árbol y los operadores que se proporcionan para manipular dichas estructuras incluyen operadores para apuntadores de recorrido; es decir, los apuntadores que representan las rutas jerárquicas hacia arriba y hacia abajo en los árboles.

Los sistemas de bases de datos pueden de hecho ser divididos convenientemente en categorías de acuerdo con los operadores y estructuras de datos que presentan al usuario. De acuerdo con este esquema, los sistemas más antiguos o prerrelacionales se ubican dentro de tres categorías: los sistemas de listas invertidas, jerárquicos y de red.

Bibliografía

• Introducción a los Sistemas de Bases de Datos – C.J. Date. 7ma edición, Pearson Educación(2001).
• Análisis y Diseño de Sistemas – Kendall & Kendall. 3ra edición, Pearson Educación.
• Ingeniería de Software – Ian Sommerville. 6ta edición, Addison Wesley.

Zienia Gabbe

Técnico en Computación, Estudiante de Ingeniería en Ciencias de la Computación; Universidad Católica de Honduras.