LIBRO
LIBRO
LIBRO
Este paquete tiene programas que establecen las estructuras de almacenamiento originales--cargan
los datos--aceptan peticiones de datos de programas y usuarios--dan formato a los datos
recuperados de modo que aparezcan en la forma que el programa o el usuario esperan--ocultan
datos a los que un usuario particular no debe tener acceso--aceptan y realizan actualizaciones--
permiten el uso concurrente de los datos sin hacer que los usuarios interfieran unos con otros--y
realizan respaldos y procedimientos de recuperación automáticamente.
Usuarios finales La base de datos se diseña, crea y mantiene para satisfacer las necesidades
de información de los usuarios finales, las personas que usan los datos para realizar sus
labores. Sin importar la elegancia del diseño de la base de datos, o la sofisticación del
hardware y el software utilizados, si la base de datos no proporciona información adecuada
a los usuarios, es un fracaso.
Los usuarios se pueden categorizar de acuerdo con la forma en que acceden a los datos. Los
usuarios sofisticados (también llamados usuarios casuales) están capacitados en el uso del lenguaje
de consulta interactivo, y acceden a los datos mediante el ingreso de consultas en estaciones de
trabajo.
Los usuarios aficionados no usan el lenguaje de consulta inter activo, sino que acceden a los datos
mediante programas de aplicación que se escribieron para ellos. Invocan los programas al ingresar
comandos simples o elegir opciones de un menú. No necesitan conocer detalle alguno de la
estructura o lenguaje del sistema de base de datos. Interactúan con el sistema en una forma menos
sofisticada y restringen su acceso a operaciones realizadas por los programas. Los programas mismos
pueden realizar operaciones de actualización o recuperación.
El usuario secundario puede usar la información en la base de datos sin interactuar directamente
con ella, al recibir salida que usan en sus labores
1.Compartición de datos
La base de datos pertenece a toda la organización. El ABD gestiona los datos, pero
éstos no pertenecen a algún individuo o departamento. Por ende, la organización
tiene el control sobre los datos que necesita para dirigir su negocio. Muchos usuarios
pueden tener autorización para acceder al mismo trozo de información. La autorización para acceder
a los datos la otorga el ABD, no otro departamento.
2. Control de redundancia
Cuando se almacena en una base de datos, la información se integra de modo que
múltiples copias de los mismos datos no se almacenan a menos que sea necesario. Se
permite alguna redundancia limitada para mantener las conexiones lógicas entre los
ítems de datos o para mejorar el rendimiento. Para poner un caso, en el ejemplo de
universidad que se discutió en la sección 1.2, la ID del estudiante aparecía tanto en la
tabla Student como en la tabla Enroll. El sistema de gestión de la base de datos “sabe
acerca” de dicha repetición. Una base de datos de ordinario no tiene múltiples copias
de registros enteros, a diferencia de un sistema de archivos, donde distintos departamentos podían
tener duplicados de archivos enteros.
3. Consistencia de datos
Un efecto de eliminar o controlar la redundancia es que los datos son consistentes. Si
un ítem de datos aparece sólo una vez, cualquier actualización a su valor necesita
realizarse sólo una vez, y todos los usuarios tendrán acceso al mismo nuevo valor. Si
el sistema tiene cierta redundancia controlada, cuando recibe una actualización a un
ítem que aparezca más de una vez con frecuencia puede realizar actualizaciones en
cascada. Esto significa que automáticamente actualizará cada ocurrencia de dicho
ítem, lo que mantiene consistente a la base de datos. Por ejemplo, si se cambia la ID
de un estudiante en la tabla Student, los registros Enroll para dicho estudiante se
actualizarán para mostrar la nueva ID en forma automática.
4. Estándares de datos mejorados
El ABD, que es responsable del diseño y mantenimiento de la base de datos para
satisfacer las necesidades de todos los usuarios, define y refuerza los estándares de
toda la organización para la representación de datos en la base de datos. En esta categoría se
incluyen reglas como el formato de todos los ítems de datos, convenciones
acerca de nombres de datos, estándares de documentación, frecuencia de actualizaciones,
procedimientos de actualización, frecuencia de respaldos, procedimientos de
respaldos y uso permitido de la base de datos. Por ejemplo, el ABD puede elaborar
una regla para que las direcciones se almacenen en un formato particular. En Estados
Unidos, una convención puede ser que, para los nombres de los estados, se usen
abreviaturas con dos letras. La base de datos se puede configurar de modo que cualquier otra
representación se rechace. En otros países, las zonas postales pueden definirse con base en cierto
número de caracteres.
5. Mejor seguridad de datos
Los datos en la base de datos de una organización son un valioso recurso corporativo
que se debe proteger de mal uso intencional o accidental. La seguridad de datos es la
protección de la base de datos de acceso no autorizado por personas o programas
que puedan hacer mal uso o dañar los datos. Un sistema de base de datos permite la
definición y fortalecimiento de restricciones de seguridad en varios niveles. Todo
acceso autorizado a la base de datos es a través del DBMS, que puede requerir que los
usuarios pasen a través de procedimientos de seguridad o usar contraseñas para
obtener acceso a la base de datos. Para eliminar la posibilidad de que un usuario pase
por un lado del DBMS y obtenga acceso a los datos en forma ilegal, el DBMS puede
encriptar los datos antes de almacenarlos. Entonces, cuando un usuario autorizado
6. Integridad de datos mejorada
Algunos sistemas de gestión de base de datos permiten al ABD definir restricciones
de integridad: reglas de consistencia que la base de datos debe obedecer. Estas restricciones se
aplican a ítems dentro de un registro (restricciones intrarregistro) o a
registros que se relacionan mutuamente (restricciones interregistro), o pueden ser
restricciones generales del negocio. Por ejemplo, en los registros de clase, puede
haber una regla de que el número de estudiantes inscritos en una clase nunca supere
algún máximo de inscripción permitido. Otra regla puede ser que la ID del personal
docente en un registro de clase deba corresponder a una ID de personal docente real
en un registro de personal docente. El DBMS es responsable de nunca permitir la
inserción, el borrado o la actualización de un registro que viole una restricción de
integridad.
7. Equilibrio de los requisitos en conflicto
Cada departamento o usuario individual tiene necesidades de datos que pueden estar
en conflicto con los de otros usuarios. El ABD está al tanto de las necesidades de
todos los usuarios y puede tomar decisiones acerca del diseño, uso y mantenimiento
de la base de datos que proporcionen las mejores soluciones para la organización
como un todo. Estas decisiones por lo general favorecen las aplicaciones más importantes,
posiblemente a costa de las menos vitales.
8. Desarrollo más rápido de nuevas aplicaciones
Una base de datos bien diseñada proporciona un modelo preciso de las operaciones
de la organización. Cuando se propone una nueva aplicación, es probable que los
datos requeridos ya estén almacenados en la base de datos. Si es así, el DBMS puede
proporcionar datos en la forma requerida por el programa. El tiempo de desarrollo
se reduce porque no se necesita una fase de creación de archivos para la nueva aplicación, como
ocurría cuando se usaban los sistemas de procesamiento de archivos.
9. Mejor accesibilidad de datos
Además de proporcionar datos para los programas, la mayoría de los sistemas de gestión de base de
datos permiten acceso interactivo a los usuarios. Proporcionan lenguajes de consulta que permiten a
los usuarios plantear preguntas ad hoc y obtener la
información deseada.
10. Economía de escala
Cuando todos los requisitos de datos de la organización se satisfacen mediante una
base de datos en lugar de muchos archivos separados, el tamaño de la operación
combinada proporciona muchas ventajas. La porción del presupuesto que de ordinario se asignaría a
varios departamentos para sus costos de diseño, almacenamiento y
costos de datos, se puede combinar, lo que posiblemente resulte en un costo total
más bajo. Los recursos combinados se pueden usar para desarrollar un sistema más
sofisticado y poderoso que cualquier departamento podría costear en forma individual, lo que
proporciona características no disponibles en un entorno de procesamiento de archivos. El tiempo
de programador que ordinariamente se dedicaría al diseño de archivos y la escritura de programas
para acceder a ellos se puede emplear
en la mejora de la base de datos. Cualquier mejora a la base de datos beneficia a
muchos usuarios.
11. Más control sobre la concurrencia
Si a dos usuarios se les permite ingresar a datos simultáneamente, y al menos uno de
ellos actualiza datos, es posible que interfieran uno con el otro. Por ejemplo, si ambos
intentan realizar actualizaciones, una actualización se puede perder, porque el segundo puede
sobrescribir el valor grabado por el primero. Si las actualizaciones tienen la
intención de ser acumulativas, éste es un serio problema. La mayoría de los sistemas de gestión de
bases de datos integradas tienen subsistemas para controlar concurrencia, de modo que las
transacciones no se pierdan o desempeñen de manera inco rrecta.
12. Mejores procedimientos de respaldo y recuperación
En un entorno de base de datos, los registros de la base de datos por lo general se respaldan
(copian) de manera regular, acaso por la noche. Para mantener seguro el respaldo, se usa una cinta u
otro medio. Conforme se realizan transacciones, cualquier actualización se registra en una bitácora
(log) de cambios. Si el sistema fracasa, cinta y log se usan para llevar la base de datos al estado en
que estaba justo antes de la falla. Por tanto, el sistema se autorrecupera.
1.6 Desventajas del enfoque de base de datos integrada
También existen algunas desventajas en un entorno de base de datos integrada, en comparación con un
sistema de archivos:
1. Alto costo de DBMS
Puesto que un sistema de gestión de base de datos completo es una pieza de software
muy grande y sofisticada, su compra o arrendamiento es costoso.
2. Costos de hardware más altos
Para correr el DBMS se requieren memoria adicional y potencia de procesamiento,
lo que resulta en la necesidad de actualizar el hardware.
3. Costos de programación más altos
Puesto que un DBMS es una herramienta compleja con muchas características, los
programadores de la organización necesitan un conocimiento extenso del sistema
con la finalidad de usarlo con mayor ventaja. Si la organización contrata programadores de base de datos
experimentados o capacita a su propio personal de programación, paga por la experiencia.
4. Altos costos de conversión
Cuando una organización convierte a un nuevo sistema de base de datos, se tienen
que remover datos de los archivos existentes y cargarlos en la base de datos. Debido a
los diferentes formatos usados en los archivos, éste puede ser un proceso difícil y que
consume tiempo. Además, los programas de aplicaciones, que contienen detalles
acerca del almacenamiento y la estructura de los archivos antiguos, se deben modificar para trabajar con
el DBMS.
5. Procesamiento más lento de algunas aplicaciones
Aunque una base de datos integrada se diseña para proporcionar mejor información
más rápidamente que un sistema tradicional que use archivos separados, algunas
aplicaciones son más lentas. Por ejemplo, un archivo de nómina típico se configura
en una secuencia que coincide con el programa de nómina, y contiene sólo los datos
necesarios para esta aplicación. Está diseñado específicamente para hacer a dicha
aplicación tan eficiente como sea posible. En la base de datos, los registros de los
empleados pueden no almacenarse de manera consecutiva y la recuperación normal
puede no ser en la secuencia necesaria por el programa de nómina. Por tanto, este
programa tardará más tiempo en ejecutarse.
6. Vulnerabilidad aumentada
Siempre que los recursos están centralizados, existe un aumento en el riesgo de seguridad. Dado que
todas las aplicaciones dependen del sistema de base de datos, la falla
de cualquier componente del sistema puede llevar las operaciones a un estancamiento. La falla de un
solo programa de aplicaciones puede tener un efecto sobre otros
programas que es posible usen datos incorrectos creados por el programa dañado.
7. Recuperación más difícil
El proceso de recuperación después de una falla de la base de datos es complicado
porque muchas transacciones podrían estar en progreso cuando falle el sistema.
Como parte de su recuperación, el sistema debe determinar cuáles transacciones se
completaron y cuáles todavía estaban en progreso al momento de la falla. Si la base
de datos está dañada, se puede recuperar con el uso de la cinta de recuperación y el
log. El hecho de que una base de datos permita a los usuarios realizar actualizaciones
concurrentes complica aún más el proceso de recuperación.
CAPITULO 2
pero un abordaje de diseño escalonado de base de datos ofrece una mejor solución.
periodo durante el cual el sistema se diseña, crea, usa y luego se sustituye por un nuevo sistema. Un
ciclo de vida típico se extiende durante muchos años y consiste en las etapas que
se muestran en la figura 2.2. Al usar el abordaje del ciclo de vida tradicional, el sistema a la
larga fallará para satisfacer las necesidades del usuario, se identificarán problemas y el ciclo
comenzará de nuevo.
Una suposición básica detrás del abordaje del ciclo de vida del análisis de sistemas es que
base de datos hay razón para cuestionar esta suposición. La base de datos se puede diseñar
en tal forma que pueda evolucionar y cambiar para satisfacer futuras necesidades de información de la
organización. Esta evolución es posible cuando el diseñador crea un verdadero
■ El modelo refleja
fehacientemente las operaciones de la organización.
información.