Bases de Datos

INSTITUTO TECNOLGICO SUPERIOR
JOSE OCHOA LEN BASES DE DATOS

Profesor: Tecnlogo en Sistemas. Silvio Quezada. Segundo ciclo
1
UNIDAD 1: INTRODUCCIN

1. BASES DE DATOS

1.1 Introduccin
Un archivo es un elemento de informacin conformado por un conjunto de registros. Estos
registros a su vez estn compuestos por una serie de caracteres o bytes. Los archivos, alojados en
dispositivos de almacenamiento conocidos como memoria secundaria, pueden almacenarse de
dos formas diferentes: archivos convencionales o bases de datos.

1.2 Los archivos convencionales
Los archivos convencionales pueden organizarse como archivos secuenciales o archivos directos.
Sin embargo, el almacenamiento de informacin a travs de archivos convencionales presenta
una serie de limitaciones que restringen de manera importante la versatilidad de los programas de
aplicacin que se desarrollan.

1.3 Definicin de Base de Datos
Se define una base de datos como una serie de datos organizados y relacionados entre s, los
cuales son recolectados y explotados por los sistemas de informacin de una empresa o negocio
en particular.
Las bases de datos proporcionan la infraestructura requerida para los sistemas de apoyo a la toma
de decisiones y para los sistemas de informacin estratgicos, ya que estos sistemas explotan la
informacin contenida en las bases de datos de la organizacin para apoyar el proceso de toma
de decisiones o para lograr ventajas competitivas. Por este motivo es importante conocer la
forma en que estn estructuradas las bases de datos y su manejo.
Una base de datos es un sistema para archivar informacin en computadora cuyo propsito
general es mantener informacin y hacer que est disponible cuando se solicite.
Las bases de Datos son un rea de la computacin que ha recibido mucha atencin debido a sus
mltiples aplicaciones: bibliotecas, automatizacin de oficinas, ingeniera de software,
diccionarios automatizados y en general cualquier programa orientado a mantener y recuperar
informacin textual. Su recuperacin, actualizacin y manejo es relativamente simple con el uso
de cualquier manejador de bases de datos. Cuando hablamos de documentos con estructura nos
estamos refiriendo a documentos cuya estructura es declarada explcitamente de algn modo,
asociando etiquetas a elementos de la estructura o mediante la sintaxis con la que se escribe el
documento, como se hace en los lenguajes de programacin.

1.4 Componentes principales
Datos. Los datos son la Base de Datos propiamente dicha.
Hardware. El hardware se refiere a los dispositivos de almacenamiento en donde reside la base
de datos, as como a los dispositivos perifricos (unidad de control, canales de comunicacin,
etc.) necesarios para su uso.
Software. Est constituido por un conjunto de programas que se conoce como Sistema
Manejador de Base de Datos (DMBS: Data Base Management System). Este sistema maneja
todas las solicitudes formuladas por los usuarios a la base de datos.

2
Usuarios. Existen tres clases de usuarios relacionados con una Base de Datos:
El programador de aplicaciones, quien crea programas de aplicacin que utiliza la base de datos.
El usuario final, quien accesa la Base de Datos por medio de un lenguaje de consulta o de
programas de aplicacin.
El administrador de la Base de Datos (DBA: Data Base Administrator), quien se encarga del
control general del Sistema de Base de Datos.

1.5 Ventajas en el uso de Bases de Datos.
Globalizacin de la informacin. Permite a los diferentes usuarios considerar la informacin
como un recurso corporativo que carece de dueos especficos.
Eliminacin de informacin redundante. Duplicada
Eliminacin de informacin inconsistente. Si el sistema esta desarrollado a travs de archivos
convencionales, dicha cancelacin deber operarse tanto en el archivo de facturas del Sistema de
Control de Cobranza como en el archivo de facturas del Sistema de Comisiones.
Permite compartir informacin. Varios sistemas o usuarios pueden utilizar una misma entidad.
Permite mantener la integridad en la informacin. Solo se almacena la informacin correcta.
Independencia de datos. La independencia de datos implica un divorcio entre programas y datos;
es decir, se pueden hacer cambios a la informacin que contiene la base de datos o tener acceso a
la base de datos de diferente manera, sin hace cambios en las aplicaciones o en los programas.

1.6 Elementos de una base de datos
Los principales elementos de una base de datos son los siguientes:
Tablas Es el elemento principal de la base de datos, ya que all se registra la informacin que se
quiere gestionar. Est compuesta, como si se tratase de una planilla de clculo, por filas y
columnas. Cada archivo de una base de datos puede contener tantas tablas como se requiera.
Formularios La informacin dentro de la base de datos puede introducirse directamente en las
tablas, pero tambin a travs de un formulario lo que resulta ms cmodo y prctico . Loa
formularios hacen que sea ms fcil arrastrar los datos.
Consultas es el elemento que se emplea para seleccionar una determinada informacin del
interior de la base de datos. La consulta, de esta manera, permite establecer criterios de
bsquedas dentro de las tablas, aquellos datos que se quieren conocer.
Informes Se utilizan para que la informacin aparezca ordenada y bien presentada en el
momento de la impresin del documento. Gracias a los informes, el usuario puede seleccionar
que informacin, de la que se registr en las tablas de una base de datos, desea imprimir y con
qu formato.

1.7 Tablas, Campos y Registros.
Tablas.- Anteriormente ya definimos lo que era una tabla, tambin podemos decir que tabla es un
conjunto de capos que se utiliza para guardar datos.

Podemos tener ms de una tabla en la base de datos para guardar informacin relacionada. Por
ejemplo, en una tabla podemos tener la informacin de clientes, en la otra la informacin del
producto y en la tercera podemos enlazar los datos de dos tablas anteriores, por ejemplo los
pedidos que hicieron clientes de cada producto.


3
Campos.- Cada tabla se compone de campos y registros. A pesar de que a primera vista casi la
podramos confundir con una hoja de Excel, existen unas diferencias fundamentales:

por ejemplo en Access, cada columna en una tabla es un campo y cada fila de una tabla
representa un nico registro que rene la informacin de un elemento de la tabla. Cada campo
de Access slo puede tener un tipo de datos: o slo texto, o slo nmeros, etc.

Los tipos de datos ms utilizados son los nmeros, el texto, la fecha y la moneda pero el Access
no se limita a esto: podemos insertar tambin hipervnculos y adems los objetos OLE, por
ejemplo, imgenes, sonidos e incluso el video clips.
Entonces podemos definir que es un Campo, campo es un Conjunto de datos o un segmento de la
informacin que cuando se agrupa con otros segmentos relacionados, proporciona un registro
detallado de un objeto especfico. Dividir la informacin en incrementos ms pequeos hace que
sea ms fcil trabajar con los datos. Por ejemplo, es ms fcil de crear letras y sus
correspondientes etiquetas de correo si tienes tres campos para nombre, como "Seor" "John",
"Smith" en lugar de agrupados como "Sr. John Smith".

Trabajo Investigativo: Investigar Sobre los Sistemas de Gestin de Bases de Datos.

4

1.2 SISTEMAS DE BASES DE DATOS

1.2.1 Concepto y origen de las BD y de los SGBD
Las aplicaciones informticas de los aos sesenta acostumbraban a darse totalmente por lotes
(batch) y estaban pensadas para una tarea muy especfica relacionada con muy pocas entidades
tipo.
Cada aplicacin (una o varias cadenas de programas) utilizaba ficheros de movimientos para
actualizar (creando una copia nueva) y/o para consultar uno o dos ficheros maestros o,
excepcionalmente, ms de dos. Cada programa trataba como mximo un fichero maestro, que
sola estar sobre cinta magntica y, en consecuencia, se trabajaba con acceso secuencial. Cada
vez que se le quera aadir una aplicacin que requera el uso de algunos de los datos que ya
existan y de otros nuevos, se diseaba un fichero nuevo con todos los datos necesarios (algo que
provocaba redundancia) para evitar que los programas tuviesen que leer muchos ficheros.
A medida que se fueron introduciendo las lneas de comunicacin, los terminales y los discos, se
fueron escribiendo programas que permitan a varios usuarios consultar los mismos ficheros on-
line y de forma simultnea. Ms adelante fue surgiendo la necesidad de hacer las actualizaciones
tambin on-line.
A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus ficheros y fue
necesario eliminar la redundancia. El nuevo conjunto de ficheros se deba disear de modo que
estuviesen interrelacionados; al mismo tiempo, las informaciones redundantes (como por
ejemplo, el nombre y la direccin de los clientes o el nombre y el precio de los productos), que
figuraban en los ficheros de ms de una de las aplicaciones, deban estar ahora en un solo lugar.
El acceso on-line y la utilizacin eficiente de las interrelaciones exigan estructuras fsicas que
diesen un acceso rpido, como por ejemplo los ndices, las multilistas, las tcnicas de hashing,
etc.
Estos conjuntos de ficheros interrelacionados, con estructuras complejas y compartidos por
varios procesos de forma simultnea (unos on-line y otros por lotes), recibieron al principio el
nombre de Data Banks, y despus, a inicios de los aos setenta, el de Data Bases. Aqu los
denominamos bases de datos (BD).
El software de gestin de ficheros era demasiado elemental para dar satisfaccin a todas estas
necesidades. Por ejemplo, el tratamiento de las interrelaciones no estaba previsto, no era posible
que varios usuarios actualizaran datos simultneamente, etc. La utilizacin de estos conjuntos de
ficheros por parte de los programas de aplicacin era excesivamente compleja, de modo que,
especialmente durante la segunda mitad de los aos setenta, fue saliendo al mercado software
ms sofisticado: los Data Base Management Systems, que aqu denominamos sistemas de gestin
de BD (SGBD).

1.2.2 Los ficheros tradicionales y las BD
Aunque de forma muy simplificada, podramos enumerar las principales diferencias entre los
ficheros tradicionales y las BD tal y como se indica a continuacin:

1) Entidades tipos:
Ficheros: tienen registros de una sola entidad tipo.
BD: tienen datos de varias entidades tipo.
2) Interrelaciones:

5
Ficheros: el sistema no interrelaciona ficheros.
BD: el sistema tiene previstas herramientas para interrelacionar entidades.
3) Redundancia:
Ficheros: se crean ficheros a la medida de cada aplicacin, con todos los datos necesarios
aunque algunos sean redundantes respecto de otros ficheros.
BD: todas las aplicaciones trabajan con la misma BD y la integracin de los datos es bsica, de
modo que se evita la redundancia.
4) Usuarios
Ficheros: sirven para un solo usuario o una sola aplicacin. Dan una sola visin del mundo real.
BD: es compartida por muchos usuarios de distintos tipos. Ofrece varias visiones del mundo
real.

1.2.3 Evolucin de los SGBD
Para entender mejor qu son los SGBD, haremos un repaso de su evolucin desde los aos
sesenta hasta nuestros das.

Los aos sesenta y setenta: sistemas centralizados

Los primeros SGBD en los aos sesenta todava no se les denominaba as, estaban orientados a
facilitar la utilizacin de grandes conjuntos de datos en los que las interrelaciones eran
complejas. El arquetipo de aplicacin era el Bill of materials o Parts explosion, tpica en las
industrias del automvil, en la construccin de naves espaciales y en campos similares. Estos
sistemas trabajaban exclusivamente por lotes (batch).
Al aparecer los terminales de teclado, conectados al ordenador central mediante una lnea
telefnica, se empiezan a construir grandes aplicaciones on-line transaccionales (OLTP). Los
SGBD estaban ntimamente ligados al software de comunicaciones y de gestin de
transacciones.
Aunque para escribir los programas de aplicacin se utilizaban lenguajes de alto nivel como
Cobol o PL/I, se dispona tambin de instrucciones y de subrutinas especializadas para tratar las
BD que requeran que el programador conociese muchos detalles del diseo fsico, y que hacan
que la programacin fuese muy compleja.
Puesto que los programas estaban relacionados con el nivel fsico, se deban modificar
continuamente cuando se hacan cambios en el diseo y la organizacin de la BD. La
preocupacin bsica era maximizar el rendimiento: el tiempo de respuesta y las transacciones por
segundo.

Los aos ochenta: SGBD relacionales
Los ordenadores minis, en primer lugar, y despus los ordenadores micros, extendieron la
informtica a prcticamente todas las empresas e instituciones.
Esto exiga que el desarrollo de aplicaciones fuese ms sencillo. Los SGBD de los aos setenta
eran demasiado complejos e inflexibles, y slo los poda utilizar un personal muy cualificado.
Todos estos factores hacen que se extienda el uso de los SGBD. La estandarizacin, en el ao
1986, del lenguaje SQL produjo una autntica explosin de los SGBD relacionales.
Los ordenadores personales
Durante los aos ochenta aparecen y se extienden muy rpidamente los ordenadores personales.

6
Tambin surge software para estos equipos monousuario (por ejemplo, dBase y sus derivados,
Access), con los cuales es muy fcil crear y utilizar conjuntos de datos, y que se denominan
personal data bases. Notad que el hecho de denominar SGBD estos primeros sistemas para PC
es un poco forzado, ya que no aceptaban estructuras complejas ni interrelaciones, ni podan ser
utilizados en una red que sirviese simultneamente a muchos usuarios de diferentes tipos. Sin
embargo, algunos, con el tiempo, se han ido convirtiendo en autnticos SGBD.

Los aos noventa: distribucin, C/S y 4GL
Al acabar la dcada de los ochenta, los SGBD relacionales ya se utilizaban prcticamente en
todas las empresas. A pesar de todo, hasta la mitad de los noventa, cuando se ha necesitado un
rendimiento elevado se han seguido utilizando los SGBD prerrelacionales.
A finales de los ochenta y principios de los noventa, las empresas se han encontrado con el hecho
de que sus departamentos han ido comprando ordenadores departamentales y personales, y han
ido haciendo aplicaciones con BD. El resultado ha sido que en el seno de la empresa hay
numerosas BD y varios SGBD de diferentes tipos o proveedores. Este fenmeno de
multiplicacin de las BD y de los SGBD se ha visto incrementado por la fiebre de las fusiones de
empresas.
Esta distribucin ideal se consigue cuando las diferentes BD son soportadas por una misma
marca de SGBD, es decir, cuando hay homogeneidad. Sin embargo, esto no es tan sencillo si los
SGBD son heterogneos. En la actualidad, gracias principalmente a la estandarizacin del
lenguaje SQL, los SGBD de marcas diferentes pueden darse servicio unos a otros y colaborar
para dar servicio a un programa de aplicacin. No obstante, en general, en los casos de
heterogeneidad no se llega a poder dar en el programa que los utiliza la apariencia de que se trata
de una nica BD.


7

Adems de esta distribucin impuesta, al querer tratar de forma integrada distintas BD
preexistentes, tambin se puede hacer una distribucin deseada, diseando una BD distribuida
fsicamente, y con ciertas partes replicadas en diferentes sistemas. Las razones bsicas por las
que interesa esta distribucin son las siguientes:
1) Disponibilidad. La disponibilidad de un sistema con una BD distribuida puede ser ms alta,
porque si queda fuera de servicio uno de los sistemas, los de ms seguirn funcionando. Si los
datos residentes en el sistema no disponible estn replicados en otro sistema, continuarn estando
disponibles. En caso contrario, slo estarn disponibles los datos de los dems sistemas.
2) Coste. Una BD distribuida puede reducir el coste. En el caso de un sistema centralizado, todos
los equipos usuarios, que pueden estar distribuidos por distintas y lejanas reas geogrficas, estn
conectados al sistema central por medio de lneas de comunicacin. El coste total de las
comunicaciones se puede reducir haciendo que un usuario tenga ms cerca los datos que utiliza
con mayor frecuencia; por ejemplo, en un ordenador de su propia oficina o, incluso, en su
ordenador personal.
Por ejemplo, un programa de aplicacin que un usuario ejecuta en su PC (que est conectado a
una red) pide ciertos datos de una BD que reside en un equipo UNIX donde, a su vez, se ejecuta
el SGBD relacional que la gestiona. El programa de aplicacin es el cliente y el SGBD es el
servidor.
Un proceso cliente puede pedir servicios a varios servidores. Un servidor puede recibir
peticiones de muchos clientes. En general, un proceso A que hace de cliente, pidiendo un servicio
a otro proceso B puede hacer tambin de servidor de un servicio que le pida otro proceso C (o
incluso el B, que en esta peticin sera el cliente). Incluso el cliente y el servidor pueden residir
en un mismo sistema.

8

La facilidad para disponer de distribucin de datos no es la nica razn, ni siquiera la bsica, del
gran xito de los entornos C/S en los aos noventa. Tal vez el motivo fundamental ha sido la
flexibilidad para construir y hacer crecer la configuracin informtica global de la empresa, as
como de hacer modificaciones en ella, mediante hardware y software muy estndar y barato.
El xito de las BD, incluso en sistemas personales, ha llevado a la aparicin de los Fourth
Generation Languages (4GL), lenguajes muy fciles y potentes, especializados en el desarrollo
de aplicaciones fundamentadas en BD. Proporcionan muchas facilidades en el momento de
definir, generalmente de forma visual, dilogos para introducir, modificar y consultar datos en
entornos C/S.

Tendencias actuales
Los tipos de datos que se pueden definir en los SGBD relacionales de los aos ochenta y noventa
son muy limitados. La incorporacin de tecnologas multimedia imagen y sonido en los SI
hace necesario que los SGBD relacionales acepten atributos de estos tipos.
Sin embargo, algunas aplicaciones no tienen suficiente con la incorporacin de tipos
especializados en multimedia. Necesitan tipos complejos que el desarrollador pueda definir a
medida de la aplicacin. En definitiva, se necesitan tipos abstractos de datos: TAD. Los SGBD
ms recientes ya incorporaban esta posibilidad, y abren un amplio mercado de TAD predefinidos
o libreras de clases.
Esto nos lleva a la orientacin a objetos (OO). El xito de la OO al final de los aos ochenta, en
el desarrollo de software bsico, en las aplicaciones de ingeniera industrial y en la construccin
de interfaces grficas con los usuarios, ha hecho que durante la dcada de los noventa se
extendiese en prcticamente todos los campos de la informtica.
En los SI se inicia tambin la adopcin, tmida de momento, de la OO. La utilizacin de
lenguajes como C++ o Java requiere que los SGBD relacionales se adapten a ellos con interfaces
adecuadas.
La rpida adopcin de la web a los SI hace que los SGBD incorporen recursos para ser
servidores de pginas web, como por ejemplo la inclusin de SQL en guiones HTML, SQL
incorporado en Java, etc. Notad que en el mundo de la web son habituales los datos multimedia y
la OO.

9
Durante estos ltimos aos se ha empezado a extender un tipo de aplicacin de las BD
denominado Data Warehouse, o almacn de datos, que tambin produce algunos cambios en los
SGBD relacionales del mercado.
A lo largo de los aos que han trabajado con BD de distintas aplicaciones, las empresas han ido
acumulando gran cantidad de datos de todo tipo. Si estos datos se analizan convenientemente
pueden dar informacin valiosa*.
Por lo tanto, se trata de mantener una gran BD con informacin proveniente de toda clase de
aplicaciones de la empresa (e, incluso, de fuera). Los datos de este gran almacn, el Data
Warehouse, se obtienen por una replicacin ms o menos elaborada de las que hay en las BD que
se utilizan en el trabajo cotidiano de la empresa. Estos almacenes de datos se utilizan
exclusivamente para hacer consultas, de forma especial para que lleven a cabo estudios* los
analistas financieros, los analistas de mercado, etc.
Actualmente, los SGBD se adaptan a este tipo de aplicacin, incorporando, por ejemplo,
herramientas como las siguientes:
a) La creacin y el mantenimiento de rplicas, con una cierta elaboracin de los datos.
b) La consolidacin de datos de orgenes diferentes.
c) La creacin de estructuras fsicas que soporten eficientemente el anlisis multidimensional.

1.2.4 Objetivos y servicios de los SGBD
Los SGBD que actualmente estn en el mercado pretenden satisfacer un conjunto de objetivos
directamente deducibles de lo que hemos explicado hasta ahora. A continuacin los
comentaremos, pero sin entrar en detalles que ya se vern ms adelante en otras asignaturas.

Consultas no predefinidas y complejas

El objetivo fundamental de los SGBD es permitir que se hagan consultas no predefinidas (ad
hoc) y complejas.

Consultas que afectan a ms de una entidad tipo
Se quiere conocer el nmero de alumnos de ms de veinticinco aos y con nota media superior
a siete que estn matriculados actualmente en la asignatura Bases de datos I.
De cada alumno matriculado en menos de tres asignaturas, se quiere obtener el nombre, el
nmero de matrcula, el nombre de las asignaturas y el nombre de profesores de estas
asignaturas.
El usuario debe formular la consulta con un lenguaje sencillo (que se quede, obviamente, en el
nivel lgico), que el sistema debe interpretar directamente.
Sin embargo, esto no significa que no se puedan escribir programas con consultas incorporadas
(por ejemplo, para procesos repetitivos).
La solucin estndar para alcanzar este doble objetivo (consultas no predefinidas y complejas) es
el lenguaje SQL, que explicaremos en otra unidad didctica.

Flexibilidad e independencia

La complejidad de las BD y la necesidad de irlas adaptando a la evolucin del SI hacen que un
objetivo bsico de los SGBD sea dar flexibilidad a los cambios.

10
Interesa obtener la mxima independencia posible entre los datos y los procesos usuarios para
que se pueda llevar a cabo todo tipo de cambios tecnolgicos y variaciones en la descripcin de
la BD, sin que se deban modificar los programas de aplicacin ya escritos ni cambiar la forma de
escribir las consultas (o actualizaciones) directas.
En el mundo de los ficheros ya haba independencia fsica en un cierto grado, pero en el mundo
de las BD acostumbra a ser mucho mayor.

Ejemplos de independencia lgica

1) El personal administrativo de secretara podra tener una visin de la entidad alumno sin que
fuese necesario que existiese el atributo nota. Sin embargo, los usuarios profesores (o los
programas dirigidos a ellos) podran tener una visin en la que existiese el atributo nota pero no
el atributo fecha de pago.
2) Decidimos ampliar la longitud del atributo nombre y lo aumentamos de treinta a cincuenta
caracteres, pero no sera necesario modificar los programas que ya tenemos escritos si no nos
importa que los valores obtenidos tengan slo los primeros treinta caracteres del nombre.

Problemas de la redundancia
En el mundo de los ficheros tradicionales, cada aplicacin utilizaba su fichero.
Sin embargo, puesto que se daba mucha coincidencia de datos entre aplicaciones, se produca
tambin mucha redundancia entre los ficheros. Ya hemos dicho que uno de los objetivos de los
SGBD es facilitar la eliminacin de la redundancia.
Seguramente pensis que el problema de la redundancia es el espacio perdido.
Antiguamente, cuando el precio del byte de disco era muy elevado, esto era un problema grave,
pero actualmente prcticamente nunca lo es. Qu problema hay, entonces? Simplemente, lo que
todos hemos sufrido ms de una vez; si tenemos algo apuntado en dos lugares diferentes no
pasar demasiado tiempo hasta que las dos anotaciones dejen de ser coherentes, porque
habremos modificado la anotacin en uno de los lugares y nos habremos olvidado de hacerlo en
el otro.
As pues, el verdadero problema es el grave riesgo de inconsistencia o incoherencia de los datos;
es decir, la prdida de integridad que las actualizaciones pueden provocar cuando existe
redundancia.
Por lo tanto, convendra evitar la redundancia. En principio, nos conviene hacer que un dato slo
figure una vez en la BD. Sin embargo, esto no siempre ser cierto.
Por ejemplo, para representar una interrelacin entre dos entidades, se suele repetir un mismo
atributo en las dos, para que una haga referencia a la otra.
Otro ejemplo podra ser el disponer de rplicas de los datos por razones de fiabilidad,
disponibilidad o costes de comunicaciones.
La duplicacin de datos es el tipo de redundancia ms habitual, pero tambin tenemos
redundancia cuando guardamos en la BD datos derivados (o calculados) a partir de otros datos de
la misma BD. De este modo podemos responder rpidamente a consultas globales, ya que nos
ahorramos la lectura de gran cantidad de registros.
En los casos de datos derivados, para que el resultado del clculo se mantenga consistente con
los datos elementales, es necesario rehacer el clculo cada vez que stos se modifican. El usuario
(ya sea programador o no) puede olvidarse de hacer el nuevo clculo; por ello convendr que el
mismo SGBD lo haga automticamente.

11

Integridad de los datos
Nos interesar que los SGBD aseguren el mantenimiento de la calidad de los datos en cualquier
circunstancia. Acabamos de ver que la redundancia puede provocar prdida de integridad de los
datos, pero no es la nica causa posible.
Se podra perder la correccin o la consistencia de los datos por muchas otras razones: errores de
programas, errores de operacin humana, avera de disco, transacciones incompletas por corte de
alimentacin elctrica, etc.
En el subapartado anterior hemos visto que podremos decir al SGBD que nos lleve el control de
las actualizaciones en el caso de las redundancias, para garantizar la integridad. Del mismo
modo, podremos darle otras reglas de integridad o restricciones para que asegure que los
programas las cumplen cuando efectan las actualizaciones.
Aparte de las reglas de integridad que el diseador de la BD puede definir y que el SGBD
entender y har cumplir, el mismo SGBD tiene reglas de integridad inherentes al modelo de
datos que utiliza y que siempre se cumplirn. Son las denominadas reglas de integridad del
modelo. Las reglas definibles por parte del usuario son las reglas de integridad del usuario. El
concepto de integridad de los datos va ms all de prevenir que los programas usuarios
almacenen datos incorrectos. En casos de errores o desastres, tambin podramos perder la
integridad de los datos. El SGBD nos debe dar las herramientas para reconstruir o restaurar los
datos estropeados.

Concurrencia de usuarios
Cuando los accesos concurrentes son todos de lectura (es decir, cuando la BD slo se consulta),
el problema que se produce es simplemente de rendimiento, causado por las limitaciones de los
soportes de que se dispone: pocos mecanismos de acceso independientes, movimiento del brazo
y del giro disco demasiado lento, buffers locales demasiado pequeos, etc.
Cuando un usuario o ms de uno estn actualizando los datos, se pueden producir problemas de
interferencia que tengan como consecuencia la obtencin de datos errneos y la prdida de
integridad de la BD.
Para tratar los accesos concurrentes, los SGBD utilizan el concepto de transaccin de BD,
concepto de especial utilidad para todo aquello que hace referencia a la integridad de los datos,
como veremos a continuacin.

Ejemplos de transacciones
1) Imaginemos un programa pensado para llevar a cabo la operacin de transferencia de dinero
de una cuenta X a otra Y. Supongamos que la transferencia efecta dos operaciones: en primer
lugar, el cargo a X y despus, el abono a Y. Este programa se debe ejecutar de forma que se
hagan las dos operaciones o ninguna, ya que si por cualquier razn (por ejemplo, por
interrupcin del flujo elctrico) el programa ejecutase slo el cargo de dinero a X sin abonarlos a
Y, la BD quedara en un estado incorrecto. Queremos que la ejecucin de este programa sea
tratada por el SGBD como una transaccin de BD.
2) Otro ejemplo de programa que querramos que tuviera un comportamiento de transaccin
podra ser el que aumentara el 30% de la nota de todos los alumnos. Si slo aumentara la nota a
unos cuantos alumnos, la BD quedara incorrecta.
Para indicar al SGBD que damos por acabada la ejecucin de la transaccin, el programa
utilizar la operacin de COMMIT. Si el programa no puede acabar normalmente (es decir, si el

12
conjunto de operaciones se ha hecho slo de forma parcial), el SGBD tendr que deshacer todo
lo que la transaccin ya haya hecho. Esta operacin se denomina ROLLBACK.
Acabamos de observar la utilidad del concepto de transaccin para el mantenimiento de la
integridad de los datos en caso de interrupcin de un conjunto de operaciones lgicamente
unitario. Sin embargo, entre transacciones que se ejecutan concurrentemente se pueden producir
problemas de interferencia que hagan obtener resultados errneos o que comporten la prdida de
la integridad de los datos.

Acabamos de observar la utilidad del concepto de transaccin para el mantenimiento de la
integridad de los datos en caso de interrupcin de un conjunto de operaciones lgicamente
unitario. Sin embargo, entre transacciones que se ejecutan concurrentemente se pueden producir
problemas de interferencia que hagan obtener resultados errneos o que comporten la prdida de
la integridad de los datos.

Consecuencias de la interferencia entre transacciones
1) Imaginemos que una transaccin que transfiere dinero de X a Y se ejecuta concurrentemente
con una transaccin que observa el saldo de las cuentas Y y X, en este orden, y nos muestra su
suma. Si la ejecucin de forma concurrente de las dos transacciones casualmente es tal que la
transferencia se ejecuta entre la ejecucin de las dos lecturas de la transaccin de suma, puede
producir resultados incorrectos. Adems, si los decide escribir en la BD, sta quedar
inconsistente (consultad la figura 3).
2) Si simultneamente con el generoso programa que aumenta la nota de los alumnos en un 30%,
se ejecuta un programa que determina la nota media de todos los alumnos de una determinada
asignatura, se podr encontrar a alumnos ya gratificados y a otros no gratificados, algo que
producir resultados errneos.
Estos son slo dos ejemplos de las diferentes consecuencias negativas que puede tener la
interferencia entre transacciones en la integridad de la BD y en la correccin del resultado de las
consultas.


13

Cuando se provocan bloqueos, se producen esperas, retenciones y, en consecuencia, el sistema es
ms lento. Los SGBD se esfuerzan en minimizar estos efectos negativos.

Bases de Datos

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Bases de Datos

Hochgeladen von

Copyright:

Verfügbare Formate

INSTITUTO TECNOLGICO SUPERIOR

JOSE OCHOA LEN BASES DE DATOS

Das könnte Ihnen auch gefallen