1.

1 Sistemas de informacin y bases

Aunque la palabra sistema se ha utilizado en forma repetitiva, esta
seccin estudia su significado con mayor detalle. Los sistemas tienen
un significado especial para los analistas y diseadores y es ste el que
gu!a cualquier faceta de su traba"o. #ste significado es la base de lo
que ser$ el desarrollo del libro.
Qu es un sistema?
#n el sentido m$s amplio, un sistema es un con"unto de componentes
que interaccionan entre s! para lograr un ob"etivo com%n. &uestra
sociedad est$ rodeada de sistemas. 'or e"emplo, cualquier persona
e(perimenta sensaciones f!sicas gracias a un comple"o sistema nervioso
formado por el cerebro, la mdula espinal, los nervios y las
clulas sensoriales especializadas que se encuentran deba"o de la piel)
estos elementos funcionan en con"unto para hacer que el su"eto e(perimente
sensaciones de fr!o, calor, comezn, etc. Las personas se
comunican con el lengua"e, que es un sistema muy desarrollado formado
por palabras y s!mbolos que tienen significado para el que habla
y para quienes lo escuchan. Asimismo, las personas viven en un sistema
econmico en el que se intercambian bienes y servicios por otros de valor comparable y
en el que, al menos en teor!a, los participantes obtienen un beneficio en el intercambio.
*na organizacin es un sistema. +us componentes ,mercadotecnia, manufactura,
ventas, investigacin, embarques, contabilidad y personal- traba"an "untos para crear
utilidades que beneficien tanto a los empleados como a los accionistas de la compa!a.
.ada uno de estos componentes es a su vez un sistema. #l departamento de
contabilidad, por e"emplo, quiz$ est formado por cuentas por pagar, cuentas por
cobrar, facturacin y auditoria entre otras.
/odo sistema organizacional depende, en mayor o menor medida, de una entidad
abstracta denominada sistema de informacin. #ste sistema es el medio por el cual los
datos fluyen de una persona o departamento hacia otros y puede ser cualquier cosa,
desde la comunicacin interna entre los diferentes componentes de la organizacin y
l!neas telefnicas hasta sistemas de cmputo que generan reportes peridicos para
varios usuarios. Los sistemas de informacin proporcionan servicio a todos los dem$s
sistemas de una organizacin y enlazan todos sus componentes en forma tal que stos
traba"en con eficiencia para alcanzar el mismo ob"etivo.
FIGURA 1.4
Ejemplo de un sistema abierto: Sistema para el control de inventarios.
La figura 0.1 ilustra una aplicacin de los conceptos de sistemas a una situacin familiar
en una organizacin. &tense las interrelaciones entre los elementos. #sta
caracter!stica es importante para lograr la e(itosa operacin de los sistemas.
FIGURA 1.5
Elementos bsicos de control en un modelo de sistemas.
.aracter!sticas 2mportantes de los sistemas
La finalidad de un sistema es la razn de su e(istencia. #(iste un sistema legislativo,
por e"emplo, para estudiar los problemas que enfrentan los ciudadanos y aprobar la
legislacin que los resuelva. #l sistema de encendido de un automvil tiene el claro
propsito de quemar el combustible para crear la energ!a que emplean los dem$s
sistemas del automvil.
'ara alcanzar sus ob"etivos, los sistemas interaccionan con su medio ambiente, el cual
est$ formado por todos los ob"etos que se encuentran fuera de las fronteras de los
sistemas. Los sistemas que interact%an con su medio ambiente ,reciben entradas y
producen salidas- se denominan sistemas abiertos. #n contraste, aquellos que no
interact%an con su medio ambiente se conocen como sistemas cerrados. /odos los
sistemas actuales son abiertos. #s as! como los sistemas cerrados e(isten slo como
un concepto, aunque muy importante como se ver$ m$s adelante.
#l elemento de control est$ relacionado con la naturaleza de los sistemas, sean
cerrados o abiertos. Los sistemas traba"an me"or ,se encuentran ba"o control- cuando
operan dentro de niveles de desempeo tolerables. 'or e"emplo, las personas traba"an
me"or cuando su temperatura es de 34 grados cent!grados. 5uiz$ una desviacin de 34
a 34.6 grados no afecte en mucho su desempeo aunque, en algunos casos, la
diferencia puede ser notable. *na mayor desviacin, sin embargo, tal como una fiebre
de 37.6 grados, desencadena un cambio dr$stico en las funciones corporales. #l
sistema de"a de funcionar y permanece inactivo hasta que se corri"a su condicin. +i
esta condicin se prolonga demasiado, los resultados pueden ser fatales para el
sistema.
#ste e"emplo muestra adem$s la importancia del control en los sistemas de todo tipo.
/odos los sistemas tienen niveles aceptables de desempeo, denominados estndares
y contra los que se comparan los niveles de desempeo actuales. +iempre deben
anotarse las actividades que se encuentran muy por encima o por deba"o de los
est$ndares para poder efectuar los a"ustes necesarios, La informacin se prolonga
demasiado, los resultados pueden ser fatales para el sistema.
#ste e"emplo muestra adem$s la importancia del control en los sistemas de todo tipo.
/odos los sistemas tienen niveles aceptables de desempeo, denominados estndares
y contra los que se comparan los niveles de desempeo actuales. +iempre deben
anotarse las actividades que se encuentran muy por encima o por deba"o de los
est$ndares para poder efectuar los a"ustes necesarios, La informacin proporcionada al
comparar los resultados con los est$ndares "unto con el proceso de reportar las
diferencias a los elementos de control recibe el nombre de retroalimentacin ,vase 8ig.
1.5).
'ara resumir, los sistemas emplean un modelo de control b$sico consistente en9
0. *n estndar para lograr un desempeo aceptable
:. *n mtodo para medir el desempeo actual
3. *n medio para comparar el desempeo actual contra el est$ndar
1. *n mtodo de retroalimentacin
Los sistemas que pueden a"ustar sus actividades para mantener niveles aceptables
contin%an funcionando. Aquellos que no lo hacen, tarde o temprano de"an de traba"ar.
#l concepto de interaccin con el medio ambiente, que es lo que caracteriza a los
sistemas abiertos, es esencial para el control. ;ecibir y evaluar la retroalimentacin,
permite al sistema determinar qu tan bien est$ operando. +i una empresa, por
e"emplo, produce como salidas productos o servicios con un precio elevado pero de
ba"a calidad, entonces es probable que las personas de"en de adquirirlos. #n este caso,
las figuras o gr$ficas de ventas ba"as son la retroalimentacin que indica a la gerencia
que es necesario efectuar a"ustes, tanto en la calidad de sus productos como la forma
en la que stos se fabrican, para me"orar el desempeo, volver al camino y recobrar las
esperanzas.
#n contraste, los sistemas cerrados sostienen su nivel de operacin siempre y cuando
posean informacin de control adecuada y no necesiten nada de su medio ambiente.
<ado que esta condicin no puede sostenerse por mucho tiempo, la realidad es que no
e(isten sistemas cerrados. #l concepto, sin embargo, es importante porque ilustra un
ob"etivo en el diseo de sistemas9 construir sistemas que necesiten la menor
intervencin del medio e(terno para mantener un desempeo aceptable. 'or
consiguiente, la autorregulacin y el propio a"uste son ob"etivos de diseo en todos los
ambientes de sistemas.
Los componentes que forman un sistema pueden ser a su vez sistemas m$s pequeos)
es decir, los sistemas pueden estar formados por varios niveles de sistemas o
subsistemas. #l cuerpo humano, por e"emplo, contiene subsistemas tales como los
sistemas respiratorio y circulatorio. *n automvil tiene sistemas de combustin,
elctricos y de control de emisiones. #n general, en situaciones de sistemas, es com%n
tener varios niveles de sistemas interactuando entre s!.
+istemas organizacionales
Las organizaciones, presentadas en la seccin anterior, est$n formadas por
muchos sistemas, cada uno con las caracter!sticas propias del
sistema general. 'or e"emplo, todos los sistemas de manufactura tienen similitudes.
+u finalidad es producir bienes o productos que satisfagan
la demanda del mercado. 'ara alcanzar este ob"etivo, los sistemas interact%an
con sus medios ambientes para adquirir los materiales
necesarios, los obreros y el conocimiento para fabricar los bienes. +i el
proceso de fabricacin debe mantenerse, no es posible prescindir de
ninguna de las entradas. Los sistemas de fabricacin tambin generan
salidas tales como productos terminados, desperdicios y tecnolog!a
para la produccin. 'ara mantener su funcionamiento, estos sistemas deben estar ba"o
control. 'or e"emplo, necesitan satisfacer ciertos est$ndares de desempeo.
La cantidad de art!culos fabricados debe cumplir con determinada
cuota, adem$s de alcanzar niveles aceptables de calidad y costo.
Los gerentes y empleados vigilan constantemente los niveles de
desempeo y los comparan contra la productividad planeada. +i e(isten
diferencias o si la eficiencia est$ por deba"o de lo esperado, entonces
se efect%an los cambios necesarios. #n este sentido, los sistemas de
fabricacin son autorregulables y autoa"ustables ya que indican el
personal que necesita ser reemplazado y el momento para hacerlo,
el equipo que debe comprarse o los procedimientos que deben modificarse.
+ilos a"ustes internos no son satisfactorios ,si e(isten muchos
daos, la calidad es muy ba"a o los precios no son razonables- entonces
es probable que hagan su aparicin las fuerzas regulatorias del
medio ambiente. Los sistemas de fabricacin son subsistemas de organizaciones
m$s grandes) stas a su vez forman otros subsistemas para la adquisicin
de materiales, mantenimiento de equipo y capacitacin de obreros.
Las caracter!sticas generales de todos los sistemas son las mismas.
.ualquier sistema puede e(aminarse con este marco de referencia en
mente, aadiendo los detalles que sean necesarios. #sta fle(ibilidad es
la que hace tan %til los conceptos de sistemas en las organizaciones, en
general, y en el diseo de sistemas de informacin en particular.
1.1.1 !oncepto de sistema de in"ormaci#n
Las finalidades de los sistemas de informacin, como las de cualquier
otro sistema dentro de una organizacin, son procesar entradas, mantener
archivos de datos relacionados con la organizacin y producir
informacin, reportes y otras salidas.
Los sistemas de informacin est$n formados por subsistemas que
incluyen hard=are, soft=are, medios de almacenamiento de datos
para archivos y bases de datos. #l con"unto particular de subsistemas
utilizados ,equipo espec!fico, programas, archivos y procedimientos- en lo que se
denomina una aplicacin de sistemas de informacin. <e esta forma, los sistemas de
informacin pueden tener aplicaciones en ventas, contabilidad o compras.
<ado que los sistemas de informacin dan soporte a los dem$s sistemas de la
organizacin, los analistas tienen primero que estudiar el sistema organizacional como
un todo para entonces detallar sus sistemas de informacin. Los organigramas ,vase
8ig. 0.>- se emplean, con frecuencia, para describir la forma en que est$n relacionados
los diferentes componentes de la organizacin, tales como divisiones, departamentos,
oficinas y empleados. Aunque los organigramas indican con precisin las relaciones
formales entre los diferentes componentes no dicen nada con respecto a la forma en
que opera el sistema organizacional) ya que en este tipo de diagramas no es posible
plasmar todos los detalles importantes. A continuacin se dan varios e"emplos de
detalles que son importantes para el analista de sistemas9
Canales informales. ?5u interacciones e(isten entre las personas y los departamentos
que no aparecen en el organigrama o no est$n descritos en los procedimientos de
operacin@
Interdependencias. ?<e qu otros departamentos y componentes de la organizacin
depende un elemento en particular@
Personas y funciones clave. ?.u$les son las personas y elementos m$s importantes en
el sistema para que ste tenga (ito@
Enlaces crticos de comunicacin. ?.mo es el flu"o de informacin e instrucciones
entre los distintos componentes de la organizacin@
?.mo se comunican las $reas entre s!@
La anterior no es una lista e(haustiva de preguntas pero recalca la
importancia de investigar y analizar la manera en que operan las
organizaciones.
#n contraste, durante el diseo los analistas tienen la responsabilidad
de identificar las caracter!sticas importantes y necesarias que
deben tener los nuevos sistemas. #l analista especifica la forma en que
va a operar el sistema y sus subsistemas, las entradas requeridas, las
salidas que se deben producir y los traba"os que se efectuar$n tanto
por las computadoras como en forma manual. 'or otro lado, los
analistas tambin participan en el control de los sistemas b$sicamente
en dos formas9 la primera cuando describen los elementos de control,
tales como est$ndares y mtodos para evaluar el desempeo en relacin
con los dem$s est$ndares para los sistemas de informacin que
disean. Al mismo tiempo, los sistemas que especifican proporcionan
informacin a los directivos y usuarios que permite a stos determinar
si los sistemas que administran operan correctamente. 2ncorporar
mecanismos de retroalimentacin es un paso esencial en el diseo ya
que su inclusin permite sostener las actividades de ambos sistemas.
&inguno de los sistemas perdurar$ si falta un control adecuado.
Los pasos para llevar a cabo el an$lisis y diseo de sistemas que se
emplean a lo largo de todo el libro est$n basados en los conceptos de
sistemas generales contenidos en el presente cap!tulo. Los mtodos
descritos se pueden aplicar a cualquier tipo de sistemas de informacin.
FIGURA 1.$
%r&ani&rama 'ue deja muc(as pre&untas de sistemas sin respuesta.
0.: Sistemas de informacin para la gestin y para la ayuda
en la toma de decisiones
Los sistemas de transacciones est$n orientados hacia operaciones. #n contraste, los
sistemas de informacin administrativa ,A2+- ayudan a los directivos a tomar decisiones
y resolver problemas. Los directivos recurren a los datos almacenados como
consecuencia del procesamiento de las transacciones, pero tambin emplean otra
informacin.
#n cualquier organizacin se deben tomar decisiones sobre muchos asuntos que se
presentan con regularidad ,a la semana, al. mes, al trimestre, etc.- y para hacerlo se
requiere de cierta informacin. <ado que los procesos de decisin est$n claramente
definidos, entonces se puede identificar la informacin necesaria para formular las
decisiones. +e pueden desarrollar sistemas de informacin para que, en forma
peridica, preparen reportes para el soporte de decisiones. .ada vez que se necesita la
informacin, sta se prepara y presenta en una forma y formato diseados con
anterioridad.
.on frecuencia, los especialistas en sistemas de informacin describen las decisiones
apoyadas por estos sistemas como decisiones estructuradas ,vase /abla 0.0-. #l
aspecto estructurado se refiere al hecho de que los administradores conozcan de
antemano los factores que deben tenerse en cuenta para la toma de decisiones as!
como las variables con influencia m$s significativa sobre el resultado de una decisin
,buena o mala-. A su vez, los analistas de sistemas desarrollan reportes bien
estructurados que contienen la informacin necesaria para las decisiones o que indican
el estado de las variables importantes.
#n el e"emplo presentado anteriormente el sistema de informacin
administrativa, o sistema de informes para la administracin, presentar$
reportes basados en las actividades de nivel de transaccin. 'or
e"emplo, los bancos emplean de manera rutinaria reportes sobre depsitos
y retiros, en forma global y por sucursal, con el ob"eto de mantener
al tanto a los funcionarios bancarios sobre el comportamiento de
cada sucursal. /odo esto con el ob"eto de vigilar la relacin entre
estamos otorgados y depsitos recibidos, el nivel de las reservas de
efectivo y los intereses pagados a los cuenta habientes, entre otros
indicadores de uso com%n.
.on frecuencia la informacin proporcionada se combina con
otra de naturaleza e(terna, tal como los detalles relacionados con
tendencias econmicas, demanda y costo de prstamos, y tambin la
tasa de gastos de los consumidores. .on esta informacin los funcionarios
del banco pueden tomar decisiones con respecto a las tasas de
inters de la siguiente semana para los diferentes tipos de prstamo o
si deben aumentar ls tasas de inters que pagan a los clientes con la
finalidad de atraer m$s depsitos. La necesidad de tomar cada una de
estas decisiones se presenta con frecuencia y, por tanto, la informacin
necesaria para ello debe preparase con regularidad.
+istemas para el soporte de decisiones
&o todas las decisiones son de naturaleza recurrente. Algunas se presentan
slo una vez o escasamente. Los sistemas para el soporte de
decisiones ,<++- ayudan a los directivos que deben tomar decisiones
no muy estructuradas, tambin denominadas no estructuradas o decisiones
semiestructuradas ,vase /abla 0.0-. *na decisin se considera
no estructurada si no e(isten procedimientos claros para tomarla y
tampoco es posible identificar, con anticipacin, todos los factores
que deben considerarse en la decisin.
*n factor clave en el uso de estos sistemas es determinar la informacin
necesaria. #n situaciones bien estructuradas es posible identificar
esta informacin con anticipacin, pero en un ambiente no
estructurado resulta dif!cil hacerlo. .onforme se adquiere la informacin,
puede ocurrir que el gerente se d cuenta que se necesita m$s
informacin) es decir, tener informacin puede conducir a otros
requerimientos. .onsidrese el proceso de decisin que debe seguir un
funcionario bancario para decidir entre comenzar a ofrecer cuentas
para mane"o de efectivo o instalar m$quinas de ca"a autom$tica
teniendo en cuenta que los dos servicios son nuevos en el banco. #ntre
las muchas preguntas que debe abordar se encuentran las siguientes9
?.u$l es el costo de cada servicio@ ?.u$ntas ca"as ser$n necesarias@
?.u$l ser$ la respuesta de la competencia@ ?5u l!mites deben ponerse
al monto de cada retiro@ ?+e puede cobrar una cuota por este servicio@
?#l servici redundar$ en mayor cantidad de depsitos y con esto un
aumento en el flu"o de efectivo para el banco@
#n estos casos es imposible disear de antemano tanto el formato como el contenido
de los reportes del sistema. #n consecuencia, los sistemas para el soporte de
decisiones deben tener una fle(ibilidad mayor que la de los dem$s sistemas de
informacin. #l usuario debe ser capaz de solicitar informes definiendo su contenido y
especificando la forma para producir la informacin. <e manera similar, los datos
necesarios para generar la informacin pueden encontrarse en diferentes archivos o
bases de datos m$s que en un solo archivo maestro, que es el caso m$s frecuente en
los sistemas de transacciones y en muchos otros que generan reportes.
#l criterio de los directivos tiene un papel importante en la toma de decisiones donde el
problema no es estructurado. Los sistemas para el soporte de decisiones ayudan pero
no reemplazan el criterio del directivo.
Bisin de los sistemas de informacin
/al como se seala en la seccin anterior, en cualquier organizacin e(isten varios
sistemas de informacin. <esde el punto de vista de la estructura, los sistemas de
informacin en una organizacin se forman a partir de un con"unto de sistemas para
mercadotecnia, fabricacin, personal, compras y otras funciones de la empresa. .ada
una de estas funciones comprende actividades a nivel de transacciones, toma de
decisiones "unto con la ocurrencia de requerimientos %nicos para stas y aplicaciones
para el soporte de oficinas y departamentos.
Lo anterior permite comprender por qu las diferentes funciones comerciales de una
organizacin necesitan el soporte de los sistemas de informacin, de aqu! que se tenga
la nocin de sistemas de informacin para $reas funcionales. #sta es la forma en que
evolucionan los sistemas de informacin en las organizaciones.
Cace alg%n tiempo se especul en torno a los sistemas de informacin totales sistemas
de informacin administrativa %nicos que permitieran satisfacer las necesidades de una
organizacin en todos sus niveles y funciones comerciales. +in embargo, en la
actualidad no prevalece este punto de vista. Los administradores se han dado cuenta
que es imposible y peligroso intentar construir un sistema de informacin monol!tico. <e
esta forma, conforme usted estudie organizaciones, encontrar$ que en realidad e(iste
un grupo de sistemas de informacin por $reas, cada uno con su propia visin y
finalidad. #n con"unto, todos ellos forman el sistema de informacin de una
organizacin.
0.3 Sistemas de bases de datos y sus aplicaciones
'ara repetir lo que mencionamos en la seccin anterior, un sistema de base de datos es
b$sicamente un sistema computarizado para guardar registros) es decir, es un sistema
computarizado cuya finalidad general es almacenar informacin y permitir a los usuarios
recuperar y actualizar esa informacin con base en peticiones. La informacin en
cuestin puede ser cualquier cosa que sea de importancia para el individuo u
organizacin) en otras palabras, todo lo que sea necesario para au(iliarle en el proceso
general de su administracin.
!ota" en este libro los trminos datos e informacin los trato como sinnimos.
Algunos autores prefieren distinguir entre ambos, utilizando datos para referirse a lo
que est$ en realidad almacenado en la base de datos e informacin para referirse al
si#nificado de esos datos como lo entiende alg%n usuario. La diferencia es importante)
tan importante que parece preferible hacerla e(pl!cita donde sea necesario, en vez de
depender de una diferenciacin un tanto arbitraria entre dos trminos que son en
esencia sinnimos.
La figura 0.1 es una imagen simplificada de un sistema de base de datos. 'retende
mostrar que un sistema de base de datos comprende cuatro componentes principales9
datos, hard=are, soft=are y usuarios.
$istema de administracin de base de datos %&'($)
Fi&ura 1.4
Ima&en simpli"icada de un sistema de base de datos.
<atos
Los sistemas de bases de datos est$n disponibles en m$quinas que van desde las
computadoras personales m$s pequeas hasta las mainframes m$s grandes. +obra
decir que las facilidades que proporciona un sistema est$n determinadas hasta cierto
punto por el tamao y potencia de la m$quina subyacente. #n particular, los sistemas
que se encuentran en m$quinas grandes ,sistemas grandes- tienden a ser
multiusuario, mientras que los que se e"ecutan en m$quinas pequeas ,sistemas
pequeos- tienden a ser de un solo usuario. *n sistema de un solo usuario es aquel en
el que slo un usuario puede tener acceso a la base de datos en un momento dado) un
sistema multiusuario es aquel en el cual m%ltiples usuarios pueden tener acceso
simult$neo a la base de datos. .omo sugiere la figura 0.1, en este libro generalmente
tomaremos el %ltimo caso) aunque de hecho la distincin es irrelevante en lo que
respecta a la mayor!a de los usuarios9 #n general, el ob"etivo principal en los sistemas
multiusuario es precisarnente permitir que cada usuario se comporte como si estuviera
traba"ando en un sistema de un solo usuario. Los problemas especiales de los sistemas
multiusuario son en su mayor!a problemas internos del sistema y no aquellos que son
visibles al usuario ,vea la parte 2B de este libro, en especial el cap!tulo 15).
!ota" 'ara efectos de simplicidad, es conveniente suponer que la totalidad de los datos
del sistema est$ almacenada en una sola base de datos, y en este libro haremos
constantemente esta suposicin ,ya que materialmente no afecta ninguna de nuestras
e(plicaciones posteriores-. +in embargo, en la pr$ctica podr!a haber buenas razones
,incluso en un sistema pequeo- para que los datos sean separados en diferentes
bases de datos. Abordaremos algunas de estas razones m$s adelante, en el cap!tulo :
y en otras secciones.

#n general, los datos de la base de datos ,por lo menos en un sistema grande- ser$n
tanto inte#)mdos como compartidos. .omo veremos en la seccin 0.1, los aspectos de
integracin y compartimiento de datos representan una venta"a importante de los
sistemas de bases de datos en el entorno grande) y al menos, tambin la integracin
de datos puede ser importante en los entornos pequeos. 'or supuesto, hay muchas
venta"as adicionales ,que abordaremos despus-, aun en el entorno pequeo. 'ero
antes perm!tanos e(plicar lo que queremos decir con los trminos inte#rado y
compartido.
D 'or integrada, queremos decir que podemos imaginar a la base de datos como una
unificacin de varios archivos que de otro modo ser!an distintos, con una redundancia
entre ellos eliminada al menos parcialmente. 'or e"emplo, una base de datos dada
podr!a contener un archivo #A'L#A<E que proporcionara los nombres de los
empleados, domicilios, departamentos, sueldos, etc. y un archivo 2&+.;2'.2F& que
representara la inscripcin de los empleados a los cursos de capacitacin ,consulte la
figura 0.6-. +uponga ahora que, a fin de llevar a cabo el proceso de administracin de
cursos de capacitacin, es necesario saber el departamento de cada estudiante inscrito.
#ntonces, resulta claro que no es necesario incluir esa informacin de manera
redundante en el archivo 2&+.;2'.2F&, debido a que siempre puede consultarse
haciendo referencia al archivo #A'L#A<E.
D 'or compartida, queremos decir que las piezas individuales de datos en la base
pueden ser compartidas entre diferentes usuarios y que cada uno de ellos puede tener
acceso a la misma pieza de datos, probablemente con fines diferentes. .omo indiqu
anteriormente, distintos usuarios pueden en efecto acceder a la misma pieza de datos
al mismo tiempo ,acceso concurrente-. #ste compartimiento, concurrente o no, es en
parte consecuencia del hecho de
que la base de datos est$ integrada. #n el e"emplo citado arriba, la informacin de
departamento en el archivo #A'L#A<E ser!a t!picamente compartida por los usuarios
del <epartamento de personal y los usuarios del <epartamento de capacitacin) y como
ya suger!, estas dos clases de usuarios podr!an emplear esa informacin para fines
diferentes.
!ota" en ocasiones, si la base de datos no es compartida, se le conoce como personal
o como espec!fica de la aplicacin.
Etra consecuencia de los hechos precedentes Gque la base de datos sea integrada y
,por lo regular- compartidaH es que cualquier usuario ocupar$ normalmente slo una
pequea parte de la base de datos total) lo que es m$s, las partes de los distintos
usuarios se traslapar$n de diversas formas. #n otras palabras, una determinada base
de datos ser$ percibida de muchas formas diferentes por los distintos usuarios. <e
hecho, aun cuando dos usuarios tengan la misma por ci de la base de datos, su visin
de dicha parte podr!a diferir considerablemente a un nivel de tanto tallado.

Fi&ura 1.5
)os arc(ivos E*+)EA,% e I-S!RI+!I%-.
Card=are
Los componentes de hard=are del sistema constan de9

D Los vol%menes de almacenamiento secundario ,principalmente discos magnticos-
que se emplean para contener los datos almacenados, "unto con los dispositivos
asociados de #*$ ,unidades de discos, etc.-, los controladores de dispositivos, los
canales de 'I$, entre otros) y
D Los procesadores de hard=are y la memoria principal asociada usados para apoyar la
e"ecucin del soft=are del sistema de base de datos ,vea la siguiente subseccin-.
#ste libro no hace mucha referencia a los aspectos de hard=are del sistema, por las
siguientes razones ,entre otras-9 'rimero, estos aspectos conforman un tema
importante por s! mismos) segundo, los problemas que se encuentran en esta $rea no
son e(clusivos de los sistemas de base de datos) y tercero, dichos problemas han sido
investigados en forma minuciosa y descritos en otras partes.
+oft=are
#ntre la base de datos f!sica ,es decir, los datos como est$n almacenados f!sicamente-
y los usuarios del sistema, hay una capa de soft=are conocida de manera indistinta
como el administrador de base de datos o el servidor de base de datos) o m$s
com%nmente como el sistema de administracin de base de datos ,<IA+-. /odas las
solicitudes de acceso a la base de datos son mane"adas por el <IA+) las
caracter!sticas que esbozamos en la seccin 0.0 para agregar y eliminar archivos ,o
tablas-, recuperar y almacenar datos desde y en dichos archivos, etctera, son
caracter!sticas que proporciona el <IA+. 'or lo tanto, una funcin general que ofrece
el <IA+ consiste en ocultar a los usuarios de la base de datos los detalles al nivel de
+ard,are ,en forma muy parecida a como los sistemas de lengua"es de programacin
ocultan a los programadores de aplicaciones los detalles a nivel de hard=are-. #n otras
palabras, el <IA+ ofrece a los usuarios una percepcin de la base de datos que est$,
en cierto modo, por encima del nivel del hard=are y que mane"a las operaciones del
usuario ,como las operaciones +5L e(plicadas brevemente en la seccin 0.0-
e(presadas en trminos de ese nivel m$s alto de percepcin. A lo largo de este libro
e(plicaremos con mayor detalle sta y otras funciones del <IA+.
Algunos aspectos adicionales9
#l <IA+ es, por mucho, el componente de soft=are m$s importante del sistema
en general, aunque no es el %nico. Etros comprenden las utiler!as, herramientas de
desarrollo de aplicaciones, ayudas de diseo, generadores de informes y ,el m$s
importante- el administrador de transacciones o monitor P-.
#l trmino &'($ se usa tambin para referirse en forma genrica a un producto
determinado de alg%n fabricante) por e"emplo, el producto <I: *niversal <atabase de
2IA para .$*/0.. #l trmino e1emplar de &'($ se usa entonces para referirse a una
copia de dicho producto que opera en alguna instalacin de computadora determinada.
.omo seguramente notar$, en ocasiones es necesario distinguir cuidadosamente entre
estos dos conceptos.
!ota" <ebemos advertirle que en la industria de las computadoras la gente a menudo
usa el trmino base de datos cuando en realidad se refieren al &'($ ,en cualquiera de
los sentidos anteriores-. Ce aqu! un e"emplo t!pico9 #l fabricante de la base de datos J
super al fabricante de la base de datos Ken proporcin de dos a uno. #ste uso es
engaoso y no es correcto, aunque es mucho muy com%n. ,'or supuesto, el problema
es que si al <IA+ lo llamamos base de datos, entonces ?cmo llamaremos a la base
de datos@- 2dvertencia
para el lector.
*suarios
.onsideramos tres grandes clases de usuarios ,y que en cierto modo se traslapan-9
'rimero, hay programadores de aplicaciones responsables de escribir los
programas de aplicacin de base de datos en alg%n lengua"e de programacin como
.EIEL, P3I1, .LL, Mava o alg%n lengua"e de alto nivel de la cuarta generacin. #stos
programas acceden a la base de datos emitiendo la solicitud apropiada al <IA+ ,por lo
regular una instruccin +5L-. Los programas en s! pueden ser aplicaciones
convencionales por lotes o pueden ser aplicaciones en l!nea, cuyo propsito es permitir
al usuario final el acceso a la base de datos desde una estacin de traba"o o terminal en
l!nea ,vea el p$rrafo siguiente-. Las aplicaciones m$s modernas pertenecen a esta
variedad.
#n consecuencia, la segunda clase de usuarios son los usuarios finales, quienes
interact%an con el sistema desde estaciones de traba"o o terminales en l!nea. *n
usuario final puede acceder a la base de datos a travs de las aplicaciones en l!nea
mencionadas en el p$rrafo anterior, o bien puede usar una interfaz proporcionada como
parte integral del soft=are del sistema de base de datos. 'or supuesto, las interfaces
proporcionadas por el fabricante est$n apoyadas tambin 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, digamos un procesador de lengua"e de consulta, mediante el
cual el usuario puede emitir solicitudes a la base de datos ,tambin conocidas como
instrucciones o comandos), como +#L#./ e 2&+#;/, en forma interactiva con el
<IA+. #l lengua"e +5L mencionado la seccin 0.0 es un e"emplo t!pico de el nivel un
lengua"e de consulta de base de datos.
!ota" #l trmino lengua"e de consulta, a pesar de ser com%n, no es muy preciso, ya
que el verbo consultar en lengua"e normal sugiere slo una recuperacin, mientras
que los lengua"es de consulta por lo regular ,aunque no siempre- ofrecen tambin
actualizacin y otras operaciones.
La mayor!a de los sistemas proporcionan adem$s interfaces integradas adicionales en
las que los usuarios no emiten en absoluto solicitudes e(pl!citas a la base de datos,
como +#L#./, sino que en vez de ello operan mediante ,por e"emplo- la seleccin de
elementos en un men% o llenando casillas de un formulario. #stas interfaces
controladas por men%s o por formularios tienden a facilitar el uso a personas que no
cuentan con una capacitacin formal en 2/ ,/ecnolog!a de la informacin) la abreviatura
2+, de +istemas de informacin, tambin es muy usada con el mismo significado-. #n
contraste, las interfaces controladas por comandos ,por e"emplo, los lengua"es de
consulta- tienden a requerir cierta e(periencia en 2/, aunque tal vez no demasiada
,obviamente no tanta como la que es necesaria para escribir un programa de aplicacin
en un lengua"e como .EIEL-. 'or otra parte, es probable que una interfaz controlada
por comandos sea m$s fle(ible que una controlada por men%s o por formularios, dado
que los lengua"es de consulta por lo regular incluyen ciertas caracter!sticas que no
mane"an esas otras interfaces.
#l tercer tipo de usuario, que no aparece en la figura 0.1, es el administrador de
base de datos o <IA. La funcin del <IA, y la funcin asociada ,muy importante- del
administrador de datos, se abordar$ en la seccin 0.1.
.on esto concluimos nuestra descripcin preliminar de los aspectos m$s importantes
de un sistema de base de datos. Ahora continuaremos con la e(plicacin de estas ideas
con un poco m$s de detalle.
?5*N #+ *&A IA+# <# <A/E+@
<atos persistentes
#s una costumbre referirse a los datos de la base de datos como persistentes ,aunque
en realidad stos podr!an no persistir por mucho tiempoO-. 'or persistentes queremos
decir, de manera intuitiva, que el tipo de datos de la base de datos difiere de otros datos
m$s ef!meros, como los datos de entrada, los datos de salida, las instrucciones de
control, las colas de traba"o, los bloques de control de soft=are, los resultados
intermedios y de manera m$s general, cualquier dato que sea de naturaleza transitoria.
#n forma m$s precisa, decimos que los datos de la base de datos persisten debido en
primer lugar a que una vez aceptados por el <IA+ para entrar en la base de datos, en
lo sucesivo slo pueden ser removidos de la base de datos por al#una solicitud e4plcita
al &'($, no como un mero efecto lateral de ,por e"emplo- alg%n programa que termina
su e"ecucin. 'or lo tanto, esta nocin de persistencia nos permite dar una definicin
m$s precisa del trmino base de datos9
D *na base de datos es un con"unto de datos persistentes que es utilizado por los
sistemas de aplicacin de alguna empresa dada.
Aqu!, el trmino empresa es simplemente un trmino genrico conveniente para
identificar a cualquier organizacin independiente de tipo comercial, tcnico, cient!fico u
otro. *na empresa podr!a ser un solo individuo ,con una pequea base de datos
personal-, toda una corporacin o un gran consorcio similar ,con una gran base de
datos compartida- o todo lo que se ubique entre estas dos opciones. Aqu! tenemos
algunos e"emplos9
0. *na compa!a manufacturera
:. *n banco
3. *n hospital
1. *na universidad
5. *n departamento gubernamental
/oda empresa necesariamente debe mantener una gran cantidad de datos acerca de su
operacin. #stos datos son los datos persistentes a los que nos referimos antes. #n
forma caracter!stica, las empresas que acabamos de mencionar incluir!an entre sus
datos persistentes a los siguientes9
0. <atos de produccin
:. <atos contables
3. <atos de pacientes
1. <atos de estudiantes
5. <atos de planeacin
!ota" Las primeras ediciones de este libro utilizaban el trmino datos operacionales en
lugar de datos persistentes. #l primer trmino refle"aba el nfasis original en los
sistemas de base de datos con aplicaciones operacionales o de produccin) es decir,
aplicaciones rutinarias altamente repetitivas que eran e"ecutadas una y otra vez para
apoyar la operacin cotidiana de la empresa ,por e"emplo, una aplicacin para mane"ar
los depsitos o retiros de efectivo en un sistema bancario-. 'ara describir este tipo de
entorno, se ha llegado a utilizar el trmino procesamiento de transacciones en l!nea. +in
embargo, ahora las bases de datos se utilizan cada vez m$s tambin para otro tipo de
aplicaciones ,por e"emplo, aplicaciones de apoyo a la toma de decisiones- y el trmino
datos operacionales ya no es del todo apropiado. <e hecho, hoy en d!a 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 almac5n de datos %data
,are+ouse), que contiene datos de apoyo para la toma de decisiones. A menudo el
almacn de datos incluye informacin de resumen ,por e"emplo, totales, promedios...- y
dicha informacin a su vez se e(trae peridicamente de la base de datos operacional)
digamos una vez al d!a o una vez por semana. 'ara una e(plicacin m$s amplia de las
bases de datos y las aplicaciones de apoyo a la toma de decisiones.
#ntidades y v!nculos
Ahora consideraremos el e"emplo de una compa!a manufacturera ,Pno=Qare 2nc.-
con un poco m$s de detalle. 'or lo general, una empresa as! desea registrar la
informacin sobre los proyectos que mane"a, las partes que utiliza en dichos proyectos,
los proveedores que suministran esas partes, los almacenes en donde guardan esas
partes, los empleados que traba"an en esos proyectos, etctera. 'or lo tanto los
proyectos, partes, proveedores, etctera, constituyen las entidades b$sicas de
informacin que Pno=Qare 2nc. necesita registrar ,el trmino entidad es empleado
com%nmente en los c!rculos de bases de datos para referirse a cualquier ob"eto
distinguible que va a ser representado en la base de datos-. Bea la figura 0.>. Adem$s
de las propias entidades b$sicas ,como los proveedores, las partes, etctera, en el
e"emplo-, habr$ tambin v!nculos que asocian dichas entidades b$sicas. #stos v!nculos
est$n representados por los rombos y las l!neas de cone(in de la figura 0.>. 'or
e"emplo, e(iste un v!nculo ,B'- entre proveedores y partes9 cada proveedor suministra
ciertas partes y de manera inversa, cada parte es suministrada por ciertos proveedores
,para ser m$s precisos, cada proveedor suministra ciertos tipos de partes y cada tipo de
parte es suministrado por ciertos proveedores-. #n forma similar, las partes son
utilizadas en proyectos y de manera inversa, los proyectos utilizan partes ,v!nculo 'K-)
las partes son guardadas en almacenes y los almacenes guardan partes ,v!nculo A'-) y
as! sucesivamente. Ebserve que todos estos v!nculos son bidireccionales es decir,
pueden ser recorridos en ambas direcciones. 'or e"emplo, el v!nculo B' entre
proveedores y partes puede ser usado para responder las dos siguientes preguntas9
D <ado un proveedor, obtener las partes que ste suministra.
D <ada una parte, obtener los proveedores que la suministran.
Fi&ura 1.$
,ia&rama de entidad . v/nculo 0E.R1 para 2no34are Inc.
#l punto importante con respecto a este v!nculo ,y por supuesto, con respecto a todos
los v!nculos de la figura- es que son parte de los datos tanto como lo son las entidades
bsicas. 'or lo tanto, deben estar representados en la base de datos al igual que las
entidades b$sicas.
La figura 0.> ilustra adem$s otros puntos importantes9
0. Aunque la mayor!a de los v!nculos de la figura comprenden dos tipos de entidad ,es
decir, son v!nculos binarios) no significa que todos los v!nculos deban ser
necesariamente binarios en este aspecto. #n el e"emplo hay un v!nculo ,B'K- que
involucra tres tipos de entidad ,proveedores, partes y proyectos-9 un v!nculo ternario. La
interpretacin que pretendo dar es que ciertos proveedores suministran ciertas partes
para ciertos proyectos. Ebserve con cuidado que este v!nculo ternario ,los proveedores
suministran partes para proyectos- normalmente no equivale a la combinacin de tres
v!nculos binarios los proveedores suministran partes, las partes se usan en
proyectos y los proyectos son abastecidos por los proveedores. 'or e"emplo, la
declaracin de que
,a- +mith suministra llaves inglesas para el proyecto Aanhattan, nos dice ms de lo que
e(presan las tres declaraciones siguientes9
,b- +mith suministra llaves inglesas,
,e- Las llaves inglesas se usan en el proyecto Aanhattan y
,d- #l proyecto Aanhattan es abastecido por +mith
&o podemos ,Rde manera v$lidaO- inferir ,a- conociendo %nicamente ,b-, ,e- y ,d-. 'ara
ser m$s precisos, si conocemos ,b-, ,c- y ,d- entonces podr!amos inferir que +mith
suministra llaves inglesas para al#6n proyecto ,digamos el proyecto Kz-, que cierto
proveedor ,digamos B(- suministra llaves inglesas al proyecto Aanhattan, y que +mith
suministra al#una parte ,digamos la parte 'y- al proyecto Aanhattan, pero no podemos
inferir en forma v$lida que B( sea +mith ni que 'y sean llaves inglesas ni que Kz sea el
proyecto Aanhattan. 8alsas inferencias como stas son e"emplos de lo que a veces se
denomina trampa de cone(in.
:. La figura tambin muestra un v!nculo ,''- que comprende slo un tipo de entidad
,partes-. #l v!nculo aqu! es que ciertas partes incluyen a otras partes como
componentes inmediatos ,el tan mencionado v!nculo de lista de materiales-) por
e"emplo, un tomillo es un componente de una bisagra, que tambin es considerada una
parte y podr!a ser a su vez parte de un componente de un nivel superior como una tapa.
Ebserve que el v!nculo sigue siendo binario) slo que los dos tipos de entidad que
est$n vinculados ,partes y partes- vienen a ser
la misma entidad.
3. #n general, un con"unto determinado de tipos de entidad podr!a vincularse entre s! en
cualquier cantidad de v!nculos distintos. #n el e"emplo de la figura 0.>, hay dos v!nculos
distintos que involucran a proyectos y empleados9 *no ,#K- representa el hecho de que
los empleados est$n asignados a proyectos, el otro %(7) representa el hecho de que
los empleados administran proyectos.
Ahora observamos que un vnculo puede considerarse como una entidad por derec+o
propio. +i tomamos nuestra definicin de entidad como cualquier ob"eto acerca del cual
queremos registrar informacin, entonces un v!nculo se a"usta perfectamente a la
definicin. 'or e"emplo, la parte '1 est$ guardada en el almacn AS es una entidad
acerca de la cual bien querr!amos registrar informacin ,por e"emplo, la cantidad
correspondiente-. A$s a%n, podemos obtener venta"as definitivas ,que e(ceden el
alcance de este cap!tulo- no haciendo distinciones innecesarias entre entidades y
v!nculos. 'or lo tanto, en este libro trataremos en su mayor!a a los v!nculos slo como
una clase especial de entidad.
'ropiedades
.omo acabamos de sealar, una entidad es cualquier ob"eto acerca del cual queremos
registrar informacin. <e donde se desprende que las entidades ,incluidos los v!nculos-
poseen propiedades que corresponden a la informacin que deseamos registrar sobre
ellas. 'or e"emplo, los proveedores tienen localidades las partes tienen pesos los
proyectos tienen prioridades las asignaciones ,de empleados a proyectos- tienen
fec+as de inicio, etctera. 'or lo tanto, dichas propiedades deben estar representadas
en la base de datos. 'or e"emplo, la base de datos podr!a incluir una tabla denominada
y que represente a los proveedores y esa tabla podr!a incluir una columna de nombre
.2*<A< que represente a las localidades de los proveedores. #n general, las
propiedades pueden ser tan simples o tan comple"as como queramos. 'or e"emplo, la
propiedad localidad del proveedor es supuestamente bastante simple, ya que slo
consiste en un nombre de ciudad y puede ser representada en la base de datos por una
simple cadena de caracteres. #n contraste, un almacn podr!a tener una propiedad
plan de piso, que podr!a ser bastante comple"a, consistir tal vez en todo un dibu"o
arquitectnico y en el te(to descriptivo asociado. Al momento de la publicacin de este
libro, la mayor!a de los productos de bases de datos estaban apenas logrando mane"ar
propiedades comple"as como el dibu"o y el te(to. ;egresaremos a este tema m$s
delante ,en especial en el cap!tulo +y en la 'arte B2-) mientras tanto, en la mayor!a de
los casos ,en donde signifique una diferencia- daremos por hecho que las propiedades
son simples y que pueden ser representadas mediante tipos de datos simples. Los
e"emplos de dichos tipos simples incluyen n%meros, cadenas de caracteres, fechas,
horas, etc.
<atos y modelos de datos
#(iste otra importante forma de pensar sobre lo que en realidad son los datos y las
bases de datos. La palabra datos se deriva del vocablo lat!n para dar) por lo tanto, los
datos en realidad son +ec+os dados, a partir de los cuales es posible inferir hechos
adicionales. ,2nferir hechos adicionales a partir de hechos dados es e(actamente lo que
hace el <IA+ cuando responde a una
consulta de un usuario.- *n hecho dado corresponde a su vez a lo que en lgica se
denomina proposicin verdadera8 por e"emplo, el enunciado #l proveedor B0 se ubica
en Londres podr! ser una de estas proposiciones verdaderas. <e aqu! se desprende
que una base de datos es en realidad una coleccin de tales proposiciones verdaderas.
*na razn por la que los sistemas de bases de datos relacionales se han vuelto tan
dominantes, tanto en el mundo industrial como en el acadmico, es que mane"an en
forma muy directa ,de hecho casi trivial- la interpretacin precedente de los datos y las
bases de datos. Los sistemas relacionales est$n basados en una teor!a formal
denominada el modelo de datos relacional, de acuerdo con el la cual9
D #n tablas, los datos son representados por medio de filas y estas filas pueden
interpretarse directamente como proposiciones verdaderas. 'or e"emplo, en la figura
0.0, la fila &2.CET 4: puede interpretarse en forma obvia como la siguiente proposicin
verdadera9
#l &2.CE n%mero 4: contiene dos botellas de Uinfandel ;afanelli 0776, y estar$n listas
para su consumo en el ao :VV3.
D +e 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. .omo e"emplo sencillo, el operador relacional
proyectar ,vea la seccin 0.>- nos permite inferir, a partir de la proposicin verdadera
que acabamos de citar, la siguiente proposicin verdadera, entre otras9
Algunas botellas de Uinfandel estar$n listas para su consumo en el ao :VV3.
,para ser m$s precisos9 Algunas botellas de Uinfandel, en alg%n nicho, producidas por
alg%n productor en alg%n ao, estar$n listas para su consumo en el ao :VV3.-
+in embargo, el modelo relacional no es el %nico modelo de datos. #(isten otros ,vea la
seccin 0.>-, aunque la mayor!a de ellos difieren del modelo relacional en que son
hasta cierto grado especficos, en vez de estar basados firmemente en la lgica formal.
+ea lo que fuere, surge la pregunta9 ?#n general qu es un modelo de datos@ 'odemos
definir el concepto como sigue9
D *n modelo de datos es una definicin lgica, independiente y abstracta de los ob"etos,
operadores y dem$s que en con"unto constituyen la m9uina abstracta con la que
interact%an los usuarios. Los ob"etos nos permiten modelar la estructura de los datos.
Los operadores nos permiten modelar su comportamiento.
#ntonces, de manera %til, podemos distinguir al modelo de su implementacin"
D La implementacin de determinado modelo de datos es una realizacin f!sica, en una
m$quina real, de los componentes de la m$quina abstracta que en con"unto constituyen
ese modelo.
;esumiendo9 #l modelo es aquello que los usuarios tienen que conocer) la
implementacin es lo que los usuarios no tienen que conocer.
!ota" .omo puede ver, la distincin entre modelo e implementacin es en realidad slo
un caso especial ,uno muy importante- de la conocida distincin entre l#ico y fsico.
+in embargo, por desgracia muchos de los sistemas de bases de datos actuales
,incluso aquellos que dicen ser relacionales- no hacen estas distinciones con tanta
claridad como debieran. <e hecho, parece no haber un buen entendimiento de estas
distinciones y de la importancia de hacerlas. .omo consecuencia, a menudo hay una
brecha entre los principios de las bases de datos ,la forma en que los sistemas de
bases de datos deber!an funcionar- y la prctica de las bases de datos ,la forma en que
realmente funcionan-. #n este libro nos enfocamos principalmente en los principios)
aunque es "usto advertirle que cuando comience a utilizar un producto comercial, podr!a
llevarse algunas sorpresas desagradables.
'ara concluir esta seccin, debemos mencionar el hecho de que en realidad el trmino
modelo de datos es utilizado en la literatura con dos significados muy distintos. #l
primero es como se describi anteriormente. #l segundo es como un modelo de los
datos persistentes de alguna empresa en particular ,por e"emplo, la compa!a
manufacturera Pno=Qare 2nc. que mencionamos anteriormente en esta seccin-. La
diferencia entre ambos significados puede ser caracterizada como sigue9
D #n el primer sentido, un modelo de datos es como un len#ua1e de pro#ramacin
,aunque en cierto modo abstracto- 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 cone(in directa con ninguno de estos problemas espec!ficos.
D #n el segundo sentido, un modelo de datos es como un pro#rama especfico escrito
en ese lengua"e. #n otras palabras, 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.
'uede ser visto como una aplicacin especfica de alg%n modelo con el primer
significado.
<e aqu! en adelante, en este libro usaremos el trmino modelo de datos slo en el
primer sentido, e(cepto cuando se indique lo contrario.
8ormatos de archivo incompatibles puesto que la estructura de los archivos est$
incrustada en los programas de aplicacin, dichas estructuras penden del legua"e de
programacin de aplicaciones que se utilice. 'or e"emplo, la estructura de un archivo
generador por un programa .EIEL puede ser diferente de la estructura de un archivo
creada por un programa .. La incompatibilidad directa de dichos archivos hace dif!cil
que se los pueda procesar con"untamente. 'or e"emplo, suponga que el departamento
de contratos quiere averiguar los nombres y direcciones de todos los propietarios cuyos
inmuebles estn actualmente alquilados. <esafortunadamente, el departamento
contratos no dispone de la informacin de detalles sobre los propietarios de los
inmuebles, ya que slo el departamento de ventas tiene esa informacin. +in embargo,
el departamento de contratos s! que dispone del n%mero de inmueble ,property&o-, que
puede utilizarse para localizar el n%mero de inmueble correspondiente en el archivo
'roperty8or;ent del departamento de ventas. #ste archivo contiene el n%mero de
propietario ,ner&o-, que puede utilizarse para localizar los detalles del propietario en el
archivo 'rivateE=ner. Los programas del departamento de contratos han sido
desarrollados en .obol, mientras que los del departamento de ventas han sido
desarrollados en .. 'or tanto, para establecer la correspondencia entre los campos
property&o W los dos archivos 'roperty8or;ent se necesita que un desarrollador de
aplicaciones escriba un programa soft=are que convierta los archivos a un formato
com%n para facilitar el procesamiento. <e nuevo, este proceso puede requerir mucho
tiempo y resultar muy caro.
.onsultas fi"asXproliferacin de programas de aplicacin
<esde el punto de vista del usuario final, los sistemas basados en archivos
representaron una enorme me"ora n respecto a los sistemas manuales. #n
consecuencia, las peticiones de nuevas consultas o de modificaciones de las ya
e(istentes comenzaron a crecer. +in embargo, los sistemas basados en archivos son
muy dependientes del desarrollador de aplicaciones, que es quien tiene que escribir
todas las consultas e informes requeridos. .omo resultado, sucedieron dos cosas, en
algunas organizaciones, el tipo de consulta o de informe que pod!a producirse era fi"o.
&o e(ist!a ninguna posibilidad de solicitar consultas no planificadas ,es decir, consultas
pensadas en el momento o ad +oc) ni acerca de los propios datos ni acerca de los
datos disponibles. #n otras organizaciones, se produ"o una proliferacin de archivos y
de programas de aplicacin. Al final, se alcanz un punto en el que el departamento de
proceso de datos, con sus recursos e(istentes, era incapaz de gestionar todo el traba"o.
#sto normalmente llevaba a que se presionara en e(ceso al personal del departamento
de proceso de datos, lo que daba como resultado programas inadecuados o ineficientes
a la hora de satisfacer las demandas de los usuarios, o bien sistemas de
documentacin e(cesivamente limitados o bien programas cuyo mantenimiento era muy
complicado. A menudo, se tend!a a omitir diversos tipos de funcionalidad9
D &o se inclu!an mecanismos de seguridad o integridad) la recuperacin, para los casos
de fallos de hard=are o soft=are, era limitada o ine(istente)
D #l acceso a los archivos estaba restringido, de modo que slo un usuario pod!a
acceder en cada instante9 no hab!a ning%n tipo de mecanismo para facilitar el acceso
compartido por parte de distintas personas pertenecientes al mismo departamento.
#n cualquier caso, lo que est$ claro es que ese tipo de situacin no era aceptable. +e
necesitaba alg%n otro tipo de solucin.
+istemas de bases de datos
/odas estas limitaciones de los sistemas basados en archivos pueden atribuirse a dos
factores distintos9
,0- La definicin de los datos est$ incluida en los programas de aplicacin, en lugar de
almacenarse de forma separada e independiente)
,:- &o e(iste ning%n control sobre el acceso y manipulacin de los datos, m$s all$ del
que imponen los propios programas de aplicacin.
'ara poder ser m$s efectivos, se necesitaba una nueva tcnica y lo que surgi fue el
concepto de base de datos y los +istemas de Yestin de Iases de <atos ,+YI<-. #n
esta seccin, vamos a proporcionar una definicin m$s formal de estos trminos y a
e(aminar los componentes que podemos esperar encontramos en un entorno +YI<.
La base de datos Iase
*na coleccin compartida de datos lgicamente relacionados, "unto con una descripcin
de estos datos, que est$n diseados para satisfacer las necesidades de informacin de
una organizacin.
#(aminemos ahora la definicin de base de datos para tratar de entender el concepto
adecuadamente. *na base de datos es un repositorio centralizado, posiblemente de
gran tamao, compuesto por datos que pueden ser utilizados simult$neamente por
m%ltiples departamentos y usuarios. #n lugar de disponer de una serie de archivos
desconectados con datos redundantes, todos los elementos de datos est$n integrados,
mantenindose al m!nimo las posibles duplicaciones. La base de datos de"a de ser
propiedad de un departamento y pasa a ser un recurso corporativo compartido. La base
de datos almacena no slo los datos operacionales de la organizacin, sino tambin
una descripcin de dichos datos. 'or esta razn, a veces se suele describir a las bases
de datos como una coleccin autodescriptiva de re#istros inte#rados. La descripcin de
los datos se conoce con el nombre de cat$logo del sistema ,o diccionario de datos o
metadatos, es decir, Zdatos acerca de los datos[-. #s esta naturaleza autodescriptiva de
la bases de datos la que proporciona la independencia entre programas y datos.
#l enfoque adoptado por los sistemas de bases de datos, en el que la definicin de los
datos est$ separada de los programas de aplicacin, es similar a la tcnica utilizada en
el desarrollo moderno de soft=are, donde se proporciona tanto una definicin interna de
un ob"eto como una definicin e(terna independiente de la anterior. Los usuarios de un
ob"eto slo ven la definicin e(terna y no son conscientes del modo en que el ob"eto
est$ definido ni de su manera de funcionar. *na de las venta"as de esta tcnica,
denominada abstraccin de datos, es que podemos modificar la definicin interna de un
ob"eto sin afectar a los usuarios de dicho ob"eto, siempre y cuando la definicin e(terna
contin%e siendo la misma. <e la misma forma, los sistemas de bases de datos separan
la estructura de los datos de los programas de aplicacin y almacenan dicha estructura
en la propia base de datos. +i se aaden nuevas estructuras de datos o se modifican
las e(istentes, los programas de aplicacin no se ver$n afectados, siempre y cuando no
dependan directamente de la informacin que haya sido modificada. 'or e"emplo, si
aadimos un nuevo campo a un registro o creamos un nuevo archivo, las aplicaciones
e(istentes no se ver$n afectadas. +in embargo, si eliminamos de un archivo un campo
utilizado por un programa de aplicacin, entonces dicho programa de aplicacin s! se
ver$ afectado por el cambio y deber$ ser modificado correspondientemente.
#l %ltimo trmino en la definicin de base de datos que debemos e(plicar es el
Zlgicamente relacionado[. Al analizar las necesidades de informacin de una
organizacin, tratamos de identificar entidades, atributos y relaciones. *na entidad es
un ob"eto distintivo ,una persona, lugai cosa, concepto o suceso- dentro de la
organizacin y que hay que representar en la base de datos. *n atributo es una
propiedad que describe alg%n aspecto del ob"eto que queremos almacenar y una
relacin es una asociacin entre entidades. 'or e"emplo, la 8igura 0.> muestra un
diagrama #ntidad\;elacin ,#;- para una parte del caso de estudio de &ream:ome.
#st$ compuesto por9
D seis entidades ,los rect$ngulos-9 Iranch ,sucursal-, +taff ,personal-, 'roperty8or;ent
,inmueble en alquiler- .lient ,cliente- 'rivateE=ner ,propietario- y Lease ,alquiler-)
D siete relaciones ,los nombres adyacentes a las l!neas-9 :as ,tiene-, ;ffers ,ofrece-,
;versees ,gestiona-, <ie,s ,vista-, ;,ns ,posee-, 3eased'y ,alquilado por- y :olds
,alquila-)
D seis atributos, uno para cada entidad9 branch&o ,n%mero de sucursal-, staff&o
,n%mero de empleado-, property&o ,n%mero de inmueble-, client&o ,n%mero de cliente-,
o=ner&o ,n%mero de propietario- y lease&o ,n%mero de contrato de alquiler-.
La base de datos representa las entidades, los atributos y las relaciones lgicas entre
entidades. #n otras palabras, la base de datos almacena un con"unto de datos que
est$n lgicamente relacionados.
Fi&ura 1.$
Ejemplo del dia&rama de entidad5relaci#n.
+istema de gestin de base de datos ,+YI<-
*n sistema soft=are que permite a los usuarios definir, crear, mantener y controlar el
acceso a la base de datos.
#l +YI< es el soft=are que interact%a con los programas de aplicacin del usuario y
con la base de datos. &ormalmente, un +YI< proporciona la siguiente funcionalidad9
D 'ermite a los usuarios definir la base de datos, usualmente mediante un lengua"e de
definicin de datos ,<<L, <ata <efinition Language-. #l <<L permite a los usuarios
especificar las estructuras y tipos de datos y las restricciones aplicables a los datos que
hay que almacenar en la base de datos.
D 'ermite a los usuarios insertar, actualizar, borrar y e(traer datos de la base de datos,
usualmente mediante un lengua"e de manipulacin de datos ,<AL, <ata Aanipulation
Language-. Al disponer de un repositorio centralizado para todos los datos y las
descripciones de los datos, el lengua"e <AL puede proporcionar un mecanismo general
de consulta de esos datos, denominado lengua"e de consulta. La e(istencia de un
lengua"e de consulta resuelve el problema de los sistemas basados en archivos en los
que el usuario ten!a que traba"ar con un con"unto fi"o de consultas, o bien en los que
e(ist!a una proliferacin de programas que provocaban graves problemas de gestin
del soft=are. #l lengua"e de consulta m$s com%n es el lengua"e +5L ,+tructured 5uery
Language, lengua"e estructurado de consulta-, que es ahora tanto el est$ndar formal
como el est$ndar ce facto para los +YI< relacionales. 'ara recalcar la importancia del
+5L, hemos dedicado los .ap!tulos 5 y >, la mayor parte del .ap!tulo :S y el Apndice
# a un estudio en profundidad de este lengua"e.
D 'roporciona un acceso controlado a la base de datos. 'or e"emplo, puede
proporcionar9
D un sistema de seguridad, que evita que los usuarios no autorizados accedan a
la base de datos)
D un sistema de integridad, que mantiene la coherencia de los datos
almacenados)
D un sistema de control de concurrencia que permite el acceso compartido a la
base de datos)
D un sistema de control de recuperacin, que restaura la base de datos a un
estado previo coherente despus de cada fallo hard=are o soft=are)
D un cat$logo accesible por el usuario, que contiene descripciones de los datos
que est$n almacenados en la base de datos.
'rograma de aplicacin
'rograma de Aplicacin *n programa inform$tico que interact%a con la base de datos
emitiendo las apropiadas solicitudes ,normalmente una instruccin +5L- dirigidas al
+YI<.
Los usuarios interact%an con la base de datos mediante una serie de programas de
aplicacin que se utilizan para crear y mantener la base de datos y para generar
informacin. #stos programas pueden ser programas de procesamiento por lotes
convencionales o, lo que resulta m$s habitual hoy en d!a, aplicaciones en l!nea. Los
programas de aplicacin pueden estar escritos en alg%n legua"e de programacin o en
un lengua"e de cuarta generacin de mayor nivel.
La 8igura 0.4 ilustra la tcnica de bases de datos, utilizando los archivos indicados en la
8igura 1.5. La figura muestra cmo los departamentos de ventas y de contratos utilizan
sus programas de aplicacin para acceder a la base de datos a travs del +YI<. .ada
con"unto de programas de aplicacin departamentales gestiona la introduccin de
datos, el mantenimiento de los mismos y la generacin de informes. +in embargo, si lo
comparamos con la tcnica basada en archivos, la estructura fisica y el
almacenamiento de los datos ahora son responsabilidad del +YI<.
Bistas
.on esta funcionalidad, el +YI< es una herramienta e(tremadamente potente y %til.
+in embargo, como a los usuarios finales no les interesa demasiado si una determinada
tarea resulta sencilla o comple"a para el sistema, podr!a argumentarse que los +YI<
han hecho que las cosas se compliquen, ya que ahora los usuarios ven m$s datos de
los que quieren o necesitan. 'or e"emplo, los detalles que el departamento de contratos
quiere ver en lo que respecta a un inmueble en alquiler, como se indica en la 8igura 1.5,
han cambiado en la tcnica que utiliza una base de datos, como se muestra en la
8igura 0.4. Ahora la base de datos tambin almacena el tipo de inmueble, el n%mero de
habitaciones y los detalles referidos al propietario. 'ara hacer frente a este problema,
un +YI< proporciona otra funcionalidad denominada mecanismo de vistas que permite
que cada usuario disponga de su propia vista de la base de datos ,una vista es, en
esencia, un cierto subcon"unto de la base de datos-. 'or e"emplo, podr!amos definir una
lista que permita que el departamento de contratos slo vea los datos que les interesan
referidos a los inmuebles en alquiler.
Fi&ura 1.6
+rocesamiento con bases de datos.
Adem$s de reducir la comple"idad al permitir que los usuarios vean los datos en la
forma que desean verlos, las vistas tienen otras diversas venta"as9
= 3as vistas proporcionan un cierto nivel de se#uridad. 'ueden configurarse las vistas
para e(cluir aquellos datos que algunos usuarios no deban ver. 'or e"emplo, podemos
crear una lista que permita que los gerentes de sucursal y el departamento de nminas
vean todos los datos referidos al personal, incluyendo los detalles salariales, y una
segunda vista que utilizar!a el resto del personal y de la que se e(cluir!an esos detalles
salariales.
= 3as vistas proporcionan un mecanismo para personali>ar la apariencia de la base de
datos. 'or e"emplo, el departamento de contratos podr!a denominar al campo de
alquiler mensual ,rent- utilizando un nombre m$s conveniente, como por e"emplo
Aonthly ;ent.
= ?na vista puede presentar una ima#en co+erente y esttica de la estructura de la
base de datos, a%n cuando se modifique la base de datos subyacente ,por e"emplo,
podr!an aadirse o eliminarse campos, podr!an modificarse relaciones o podr!an
partirse, reestructurarse o renombrarse los archivos-. +i se aaden o eliminan campos
de un archivo y estos campos no son requeridos por la vista, sta no se ver$ afectada
por la modificacin. 'or tanto, las vistas ayudan a conseguir la independencia entre
programas y datos de la que hemos hablado en la seccin precedente.
La e(plicacin anterior es de car$cter general y el nivel real de funcionalidad ofrecido
por un +YI< difiere entre unos productos y otros. 'or e"emplo, un +YI< para una
computadora personal puede no permitir el acceso compartido concurrente y
proporcionar slo mecanismos limitados de seguridad, integridad y control de
recuperacin. +in embargo, los productos +EIE multiusuario modernos y de gran
comple"idad ofrecen todas las funciones anteriores y mucha otras. Los sistemas
modernos son programas soft=are e(tremadamente comple"os compuestos por
millones de l!neas de cdigo y para los que la documentacin est$ formada por
m%ltiples vol%menes. #sto se debe a la necesidad de proporcionar un programa
soft=are que gestione requisitos de naturaleza muy general. Adem$s, la utilizacin de
un +YI< hoy en d!a suele requerir un sistema que proporcione una fiabilidad
pr$cticamente total y una disponibilidad :1X4 ,:1 horas al d!a, @ d!as a la semana-
incluso en el caso de fallos de hard=are o soft=are. Los +YI< est$n continuamente
evolucion$ndose y e(pandindose para adaptarse a las nuevas necesidades de los
usuarios. 'or e"emplo, algunas aplicaciones requieren ahora el almacenamiento de
im$genes gr$ficas, v!deo, sonido y otros tipos de informacin similar. 'ara poder
satisfacer las necesidades de este mercado, es necesario cambiar los +YI<. ;esulta
previsible que cada vez se vayan recibiendo nuevas funcionalidades, por lo que las
funciones de un +YI< nunca ser$n est$ticas. Cablaremos de las funciones b$sicas
proporcionadas por un +EIE en los cap!tulos posteriores.
.omponentes de un entorno +YI<
'odemos identificar cinco componentes principales dentro del entorno +EIE9
hard=are, soft=are, datos, procedimientos y personas, como se ilustra en la 8igura 0.S.
Card=are
#l +YI< y las aplicaciones requieren una plataforma hard=are sobre la que e"ecutarse.
#l hard=are puede ir desde una %nica computadora personal hasta un %nico mainframe
o una red de computadoras. #l hard=are concreto depender$ de las necesidad de la
organizacin y del +YI< utilizado. Algunos +EIE slo se e"ecutan sobre una
plataforma hard=are concreta o sobre un sistema operativo particular, mientras que
otros se e"ecutan sobre un rango m$s amplio de plataformas hard=are y sistemas
operativos. /odo +YI< requiere una cantidad m!nima de memoria principal de espacio
de disco para poder e"ecutarse, pero esta configuracin m!nima puede no
necesariamente proporcionar un rendimiento aceptable. #n la 8igura 0.7 se ilustra una
configuracin hard=are simplificada para &ream:ome. #st$ compuesta de una red de
minicomputadoras, con una computadora central ubicada en Londres y en la que se
e"ecuta el sistema de servicio ,bac]end- del +YI<, es decir, la parte del +YI< que
gestiona y controla el acceso a la base de datos. /ambin se muestran varias
computadoras en distintas ubicaciones en las que se e"ecuta el sistema de interfaz
,frontend- del +YI<, es decir, la parte del +YI< que implementa la interfaz con el
usuario. #ste tipo de arquitectura se denomina cliente\servidor9 el bac]end es el
servidor y el frontend es el cliente. Cablaremos de este tipo de arquitectura en la
+eccin :.>.
Fi&ura 1.7.
Entorno SGS,.
+oft=are
#l componente soft=are comprende el propio soft=are +YI< y los programas de
aplicacin, "unto con el sistema operativo, que incluye el soft=are de red si el +YI< se
est$ utilizando en una red. &ormalmente, los programas de aplicacin se escriben en
un lengua"e de aplicacin de tercera generacin ,3YL-, como ., CAA, Mava, Bisual
Iasic, .EIEL, 8ortran, Ada o 'ascal, o utilizando un lengua"e de cuarta generacin
,1YL- como +5L, incrustado dentro de un lengua"e de tercera generacin. #l +YI<
ob"etivo puede disponer de sus propias herramientas de cuarta generacin que
permitan el desarrollo r$pido de aplicaciones gracias a la e(istencia de lengua"es de
consulta no procedimentales, generadores de informes, generadores de formularios,
generadores gr$ficos y generadores de aplicaciones. La utilizacin de herramientas de
cuarta generacin puede me"orar de forma significativa la productividad y dar como
resultado programas que son m$s f$ciles de mantener.
Clientes
Clientes
Fi&ura 1.8
!on"i&uraci#n (ard3are para ,ream9ome.
<atos
5uiz$ el componente m$s importante de un entorno +YI<, al menos desde el punto de
vista de los usuarios finales sean los datos. #n la 8igura 0.S podemos observar que los
datos act%an como una especie de puente entre los componentes ligados a la m$quina
y los componentes ligados al operador humano. La base de datos contiene tanto los
datos operacionales como los metadatos, es decir, los Zdatos acerca de los datos[. La
estructura de la base de datos se denomina esquema. #n la 8igura 0.4, el esquema
est$ compuesto por cuatro archivos o tablas, que son9 'roperty8or;ent, 'rivateE=ner,
.lient y Lease. La tabla 'roperty8or;ent tiene ocho campos e atributos, a saber9
property&o, street, city, postcode, type ,el tipo de inmueble-, rooms ,el n%mero de
habitaciones-, rent ,el alquiler mensual- y o=ner&o. #l atributo o=ner&o modela la
relacin entre 'roperty8or;ent y 'iivateE=ner9 es decir, el propietario posee %;,ns) un
inmueble para alquiler, como se muestra en el diagrama entidad\relacin de la 8igura
0.>. 'or e"emplo, en la 8igura 0.: podemos observar que el propietario .V1>, Moe
Peogh, posee el inmueble 'A01. Los datos incorporan tambin el cat$logo del sistema,
del que hablaremos en detalle en la +eccin :.1.
'rocedimientos
Los procedimientos son las instrucciones y reglas que gobiernan el diseo y utilizacin
de la base de datos. Los usuarios del sistema y el personal que gestiona la base de
datos requieren una serie de procedimientos documentados que les permitan saber
cmo utilizar o e"ecutar el sistema. #stos procedimientos pueden estar compuestos de
instrucciones que les digan cmo9
D iniciar una sesin en el +YI<)
D utilizar una funcionalidad concreta del +YI< o un programa de aplicacin)
D iniciar y detener el +YI<)
D realizar copias de seguridad de la base de datos)
D gestionar los fallos de hard=are o de soft=are. #sto puede incluir procedimientos para
identificar el componente fallido, para reparar el componente fallido ,por e"emplo,
telefonear al ingeniero de hard=are apropiado- y, despus de la reparacin del fallo,
para recuperar la base de datos)
D cambiar la estructura de una tabla, reorganizar la base de datos entre m%ltiples discos,
me"orar el rendimiento o archivar los datos en un almacenamiento secundario.
'ersonas
#l componente final son las personas que se relacionan con el sistema. Cablaremos de
este componente fundamental en la +eccin 0.1.
<iseo de bases de datos9 un cambio en el paradigma
Casta ahora, hemos dado por supuesto que los datos de la base de datos ten!an una
estructura. 'or e"emplo, en la 8igura 0.4 hemos identificado cuatro tablas9
'roperty8or;ent, 'rivateE=ner, .lient y Lease. 'ero, ?cmo obtenemos esta
estructura@ La respuesta es muy simple9 la estructura de la base de datos se determina
durante el diseo de la base de datos. +in embargo, realizar el diseo de una base de
datos puede ser e(tremadamente comple"o. 'ara producir un sistema que satisfaga las
necesidades de informacin de una organizacin, se necesita un enfoque distinto del
utilizado en los sistemas basados en archivo, donde el traba"o estaba dirigido por las
necesidades de los departamentos individuales en trminos de aplicaciones. 'ara que
el enfoque de base de datos tenga (ito, la organizacin debe ahora pensar primero en
los datos y luego en las aplicaciones. #ste cambio en el enfoque se denomina en
ocasiones cambio de paradi#ma. 'ara que el sistema sea aceptable para los usuarios
finales, resulta crucial la actividad de diseo de la base de datos. *na base de datos
inadecuadamente diseada generar$ errores que pueden conducir a que se tomen
decisiones incorrectas, lo cual podr!a tener repercusiones serias para la organizacin.
'or otro lado, una base de datos bien diseada produce un sistema que proporciona la
informacin correcta para que el proceso de toma de decisiones tenga (ito y funcione
de una manera eficiente. #l ob"etivo de este libro es ayudar a llevar a cabo este cambio
de paradigma. <edicaremos diversos cap!tulos a la presentacin de una metodolog!a
completa de diseos de bases de datos. <icha metodolog!a se presenta como una serie
de pasos f$ciles de seguir, proporcion$ndose directrices a todo lo largo del te(to. 'or
e"emplo, en el diagrama entidad\relacin de la 8igura 0.>, hemos identificado seis
entidades, siete relaciones y seis atributos. 'roporcionaremos directrices para ayudar a
identificar las entidades, los atributos y relaciones que deben ser representados en la
base de datos.
<esafortunadamente, las metodolog!as de diseo de bases de datos no son muy
populares. Auchas organizaciones y diseadores individuales utilizan bastante poco las
metodolog!as para realizar el diseo de bases de datos, lo cual se considera
com%nmente como una de las principales causas de fallo en el desarrollo de sistemas
de bases de datos. <ebido a la falta de enfoques estructurados del diseo de bases de
datos, suelen subestimarse el tiempo y los recursos necesarios para un proyecto de
base de datos y las bases de datos desarrolladas resultan inadecuadas o poco
eficientes a la hora de satisfacer las demandas de las aplicaciones, o bien la
documentacin es limitada o puede que el mantenimiento resulte muy dif!cil.
0.1 Sistemas de bases de datos frente a los sistemas de
archivos
;esulta casi una tradicin que los libros de bases de datos introduzcan los sistemas de
bases de datos mediante una revisin de sus predecesores, los sistemas basados en
archivos. &osotros vamos tambin a a"ustarnos a esta tradicin porque, aunque los
sistemas basados en archivos pueden considerarse obsoletos, siguen e(istiendo
buenas razones para analizarlos9
D +i comprendemos los problemas inherentes a los sistemas basados en archivos,
podemos evitar repetir esos problemas en los sistemas de bases de datos. #n otras
palabras, resulta conveniente que aprendamos de nuestros anteriores errores. #n
realidad, no resulta "usto emplearla palabra Zerrores[, ya que parece que estamos
quitando valor a un traba"o que sirvi a un propsito %til durante muchos aos. #n
realidad, es mucho lo que hemos aprendido de ese traba"o y gracias a l hemos visto
que hay formas me"ores de gestionar los datos.
D +i se desea convertir un sistema basado en archivos en un sistema de bases de
datos, resulta e(tremadamente %til, si no esencial, comprender cmo funcionan los
sistemas basados ?n archivos.
La tcnica basada en archivos
+istema basado en archivos
*na coleccin de programas de aplicacin que realiza diversos servicios para los
usuarios finales, como por e"emplo la produccin de informes. .ada programa define y
gestiona sus propios datos.
Los sistemas basados en archivos fueron uno de los primeros intentos para informatizar
los sistemas de archivo manual con los que todos nosotros estamos familiarizados. 'or
e"emplo, puede crearse un archivo manual en una organizacin para albergar toda la
correspondencia e(terna e interna relativa a un proyecto, a un producto, a una tarea, a
un cliente o a un empleado. &ormalmente, e(isten muchos de dichos archivos, los
cuales es preciso etiquetar y almacenar en una o m$s ca"a o contenedores por
cuestiones de seguridad. Los lugares donde se almacenen esos archivos pueden
disponer de llave, tambin por cuestiones de seguridad, o pueden estar ubicados en
$reas seguras del edificio. #n nuestra propia casa, probablemente dispongamos de
alg%n tipo de sistema de archivo en el que depositamos los recibos, las facturas, la
informacin bancaria, los contratos de seguros, etc. +i necesitamos consultar algo,
vamos a nuestro archivo personal y buscamos en l, de principio a fin, hasta encontrar
la informacin deseada. Alternativamente, puede que dispongamos de un sistema de
inde(acin que nos ayude a localizar m$s r$pidamente lo que queremos. 'or e"emplo,
puede que tengamos subdivisiones en el sistema de archivo o carpetas separadas para
los diferentes elementos que est$n relacionadas de al#una manera l#ica entre s!.
Los sistemas de archivo manual funcionan bien cuando el n%mero de elementos
almacenados es pequeo. /ambin puede funcionar de forma adecuada cuando hay un
gran n%mero de elementos y lo %nico que necesitamos es almacenarlos o e(traerlos.
+in embargo, los sistemas manuales de archivo de"an de ser %tiles cuando tenemos
que establecer referencias cruzadas o procesar la informacin contenida en los
documentos. 'or e"emplo, una agencia inmobiliaria t!pica podr!a disponer de un archivo
separado para cada inmueble que desee vender o alquilar, para cada potencial
comprador o inquilino y para cada miembro de su personal. 'iense en el enorme
esfuerzo que se requerir!a para responder a las siguientes cuestiones9
D ?5u viviendas de tres dormitorios hay disponibles para la venta que tengan "ard!n y
gara"e@
D ?5u apartamentos e(isten para alquilar a menos de 5 ]m del centro de la ciudad@
D ?.u$l es el precio medio de alquiler para un piso de dos dormitorios@
D ?.u$l es el importe total de la nmina anual de todo el personal@
D ?.u$l es la comparacin entre los ingresos del %ltimo mes y los ingresos previstos
para este@
D ?.uales son los ingresos mensuales previstos para el pr(imo ao@
Coy en d!a, los clientes, los gestores de las empresas y el personal de las mismas
quieren cada vez m$s informacin. #n algunas $reas, e(iste la obligacin legal de
generar informes mensuales, trimestrales y anuales detallados. .laramente, los
sistemas manuales no resultan adecuados para este tipo de tarea. Los sistemas
basados en archivos fueron desarrollados para dar respuesta a la necesidad que las
empresas ten!an de acceder de forma m$s eficiente a los datos. +in embargo, en lugar
de establecer un sistema centralizado de gestin de los datos operacionales de las
organizaciones, lo que se hizo fue adoptar un enfoque descentralizado, en el que cada
departamento, con la ayuda de personal especializado en procesamiento de datos,
almacenaba y controlaba sus propios datos. 'ara comprender las implicaciones de
esto, vamos a utilizar el e"emplo de &ream:ome.
#l departamento de ventas ,+ales- es responsable de la venta y alquiler de los
inmuebles. 'or e"emplo, cada vez que un cliente contacta con el departamento de
ventas con la intencin de vender o alquilar un inmueble, se rellena un formulario similar
al que se muestra en la 8igura 0.0,a-. #sto proporciona diversos detalles sobre el
inmueble, como la direccin del n%mero de habitaciones, "unto con la informacin
personal acerca del propietario. #l departamento de ventas tambin gestiona las
consultas de los clientes interesados en comprar o alquilar un inmueble, rellen$ndose
para cada uno un formulario similar al que se muestra en la 8igura 0.0,b-. .on la
asistencia del departamento de procesos de datos, el departamento de ventas crea un
sistema de informacin para gestionar el alquiler de los inmuebles. #l sistema est$
compuesto por tres archivos que contienen los detalles sobre los inmuebles, sobre el
propietario y sobre el cliente, como se ilustra en la 8igura 0.:. 'or simplicidad, vamos a
omitir los detalles relativos al personal, a las sucursales de la empresa y a los
propietarios de la misma.
Fi&ura 1.1
Formularios del departamento de ventas: 0a1 "ormulario de detalles para inmuebles en al'uiles: 0b1
"ormulario de detalles de los clientes.
'roperty8or;ent
property&o street city postcode type rooms rent o=ner&o
'A01
'L71
'Y1
'Y3>
'Y:0
'Y0>
0> Coihead
> Argyll +t
> La=rence +t
: Aanor ;d
0S <ale ;d
6 &ovar <r
Aberdeen
London
Ylasgo=
Ylasgo=
Ylasgo=
Ylasgo=
AI4 6+*
&Q:
Yil 75J
Y3: 15J
Y0:
Yi: 7AJ
Couse
8iat
8iat
8iat
Couse
8iat
>
1
3
3
6
1
>6V
1VV
36V
346
>VV
16V
.V1>
.VS4
.V1V
.V73
.VS4
.V73
'rivateE=ner
o=ner&o f&ame &ame address tei&o
.V1>
.VS4
.V1V
.V73
/oe
.aroi
/ina
/ony
Peogh
8arrei
Aurphy
+ha=
: 8ergus <r, Aberdeen AI: 4+J
> Achray +t, Yiasgo= Y3: 7<J
>3 Qe22 +t, Ylasgo= Y1:
0: 'ar] 'i, Ylasgo= Y1 E5;
V0::1\S>0:0:
V010\364\4107
V010\713\04:S
V010\::6\4V:6
.lient
client&o
f&am
e
&ame address tei&o pref/ype ma(;ent
.;4>
.;6>
.;41
.;>:
Mohn
Aline
Ai]e
Aary
Pay
+te=art
;itchie
/regear
6> Cigh +t, London
+Q0 1#C
>1 8ern <r, Ylasgo=
Y1: EIL
0S /a"o +t, 'A0Y 2K5
6 /arbot ;d, Aberdeen
AI7 3+/
V:V4\441\
6>3:
V 010\S1S\
0S:6
V0146\
37:04S
V0::1\
07>4:V
8iat
82at
Couse
8iat
1:6
36V
46V
>VV
Fi&ura 1.;.
Arc(ivos +ropert<ForRent= +rivate%3ner < !lient utili>ados por el departamento de ventas.
#l departamento de contratos ,.ontracts- es responsable de gestionar los contratos de
alquiler relativos a los distintos inmuebles. .uando un cliente accede a alquilar un
inmueble, un miembro del departamento de ventas rellena un formulario en el que se
indican los detalles relativos al cliente y al inmueble, como se muestra en la 8igura 0.3.
#ste formulario es enviado al departamento de contratos, que le asigna un n%mero de
referencia y termina de rellenar los detalles relativos al pago y al periodo de alquiler. <e
nuevo, con la ayuda del departamento de proceso de datos, el departamento de
contratos crea un sistema de informacin para gestionar estos contratos de alquiler. #l
sistema est$ compuesto por tres archivos donde se almacenan los detalles relativos al
contrato de alquiler, al inmueble y al cliente y donde se introducen datos similares a los
que ya posee el departamento de ventas, como se ilustra en la 8igura 0.1.
La situacin completa se ilustra en la 8igura 1.5. #n ella podemos ver que cada
departamento accede a sus propios archivos utilizando programas de aplicacin
escritos especialmente para ellos. .ada con"unto de programas de aplicacin
departamentales se encarga de gestionar la introduccin de datos, el mantenimiento de
los archivos y la generacin de un con"unto fi"o de informes espec!ficos. Adem$s, lo cual
tiene mayor importancia, la estructura fisica y el almacenamiento de los archivos y
registros de datos est$n definidos por el cdigo de aplicacin.
'odemos encontrar e"emplos similares en otros departamentos. 'or e"emplo, el
departamento de nminas ,'ayroli- almacena informacin relativa al salario de cada
miembro del personal, es decir9
+taff+alary,+taff&o, f&ame, &ame, se(, salary, branch&o-
#l departamento de personal ,'ersonnel- tambin almacena informacin sobre los
miembros del personal, es decir9
+taff,staff&o, f&ame, 2&ame, position, se(, dateEfbirth, salary, branch&o-
Fi&ura 1.?
Formulario de al'uiler utili>ado por el departamento de contratos.
Fi&ura 1.4
Arc(ivos )ease= +ropert<ForRent < !lient utili>ados por el departamento de contratos.
'odemos ver claramente que e(iste una gran cantidad de duplicacin de datos en estos
departamentos, esto siempre suele ser as! en los sistemas basados en archivos. Antes
de analizar las limitaciones de este enfoque, puede resultar %til comprender la
terminolog!a utilizada en los sistemas basados en archivos. *n archivo es simplemente
una coleccin de registros, que contienen datos lgicamente relacionados. 'or e"emplo,
el archivo 'roperty8or;ent de la 8igura 0.: contiene seis registros, uno para cada
inmueble. .ada registro contiene un con"unto lgicamente relacionado de uno o m$s
campos, donde cada campo representa alguna caracter!stica del ob"eto del mundo real
que se quiere modelar. #n la 8igura 0.: los campos del archivo 'roperty8or;ent
representan caracter!sticas de los inmuebles, como su direccin, tipo de inmueble y
n%mero de habitaciones.
Fi&ura 1.5
+rocesamiento basado en arc(ivos.
Limitaciones de la tcnica basada en archivos
#sta breve descripcin de los sistemas tradicionales basados en archivo deber!a ser
suficiente para e(plicar las limitaciones de este enfoque. #n la /abla 0.0 se enumeran
cinco problemas diferentes.
/abla 1.1. Limitaciones de los sistemas basados en archivos.
+eparacin y aislamiento de los datos
<uplicacin de los datos
<ependencias entre los datos
8ormatos de archivos incompatibles
.onsultas fi"asXproliferacin de programas de aplicacin
+eparacin y aislamiento de los datos
.uando se a!slan los datos en archivos separados, resulta m$s dif!cil acceder a los
datos que deben estar disponibles. 'or e"emplo, si queremos generar una lista de todos
los chalets que satisfacen los requisitos de los clientes, necesitamos primero crear un
archivo temporal de aquellos clientes cuyo tipo preferido de inmueble sea Zchalet[. A
continuacin hay que e(plorar el archivo 'roperty8or;ent para localizar aquellos
inmuebles cuyo tipo sea Zchalet[ y cuyo alquiler sea inferior al alquiler m$(imo fi"ado por
el cliente. .on los sistemas de archivos, este tipo de procesamiento resulta dif!cil. #l
desarrollador de aplicaciones debe sincronizar el procesamiento de los dos archivos
para garantizar que se e(traigan los datos correctos. #sta dificultad se hace todav!a
mayor si se necesita e(traer datos de m$s de dos archivos.
<uplicacin de los datos
<ebido al enfoque descentralizado adoptado por los departamentos, la tcnica basada
en archivos, promueve, si es que no requiere, una duplicacin incontrolada de los
datos. 'or e"emplo, en la 8igura 1.5 podemos ver claramente que e(iste una
duplicacin de la informacin tanto de los inmuebles como de los clientes en los
departamentos de ventas y de contratos. La duplicacin descontrolada de los datos
resulta indeseable por varias razones, como por e"emplo9
DLa duplicacin implica un desperdicio de recursos. .uesta tiempo y dinero introducir
los datos m$s de una vez.
D +e consume un espacio de almacenamiento innecesario, lo que tambin tiene su
coste asociado. A menudo, puede evitarse la duplicacin de los datos compartiendo los
archivos de datos.
D Lo m$s importante quiz$ sea que la duplicacin puede conducir a que se pierda la
integridad de los datos. #n otras palabras, los datos podr!an de"ar de ser coherentes.
'or e"emplo, considere el caso de la duplicacin de datos en los departamentos de
personal y de nminas, como hemos descrito anteriormente. +i un empleado cambia de
domicilio y ese cambio de direccin slo se comunica al departamento de personal y no
al de nminas, la nmina de ese empleado podr!a ser enviada a la direccin incorrecta.
Etro problema m$s grave sucede cuando se asciende a un empleado, increment$ndole
a su vez el sueldo. <e nuevo, si el cambio se notifica al departamento de personal pero
no llega al de nminas, el empleado recibir$ una paga incorrecta. .uando este error se
detecte, se necesitar$ tiempo y esfuerzo para resolverlo. #stos dos e"emplos ilustran el
tipo de incoherencia que puede surgir como resultado de la duplicacin de los datos.
'uesto que los miembros del departamento de personal no disponen de ning%n sistema
autom$tico para actualizar los datos contenidos en los archivos del departamento de
nminas, no resulta dif!cil prever que dichas incoherencias terminar$n por surgir.
2ncluso aunque se notifiquen los cambios al departamento de nminas, es posible que
stos se introduzcan de forma incorrecta.
<ependencias entre los datos
.omo ya hemos mencionado, la estructura f!sica y el almacenamiento de los archivos y
registros de datos est$n definidos en el cdigo de la aplicacin. #sto significa que
resulta dif!cil realizar cambios a una estructura e(istente. 'or e"emplo, si se incrementa
el tamao del campo 'roperty8or;ent address de 1V a 10 caracteres, parece que dicho
cambio deber!a poder incrementarse de forma simple, pero se requiere la creacin de
un programa de un solo uso ,es decir, un programa que slo se e"ecute una vez y luego
pueda descartarse- que convierta el archivo 'roperty8or;ent al nuevo formato. #ste
programa tiene que9
D abrir el archivo 'roperty8or;ent original para lectura)
D abrir un archivo temporal con la nueva estructura)
D leer un registro del archivo original, convertir los datos para adecuarlos a la nueva
estructura y escribirlo en el archivo temporal, repitiendo este paso para todos los
registros del archivo original)
D borrar el archivo 'roperty8or;ent original)
D renombrar el archivo temporal, denomin$ndolo 'roperty8or;ent.
Adem$s, todos los programas que accedan al archivo 'roperty8or;ent deber$n ser
modificados para adecuarlos a la nueva estructura del archivo. 'uede que e(istan
muchos de tales programas accediendo al archivo 'roperty8or;ent. 'or tanto, el
programador necesitar$ identificar todos los programas afectados, modificarlos y luego
volverlos a probar. Ebserve que los programas ni siquiera tienen que utilizar el campo
address para verse afectados9 basta con que utilicen el archivo 'roperty8or;ent.
Ebviamente, todo esto puede requerir un tiempo considerable y se trata de un proceso
su"eto a errores. #sta caracter!stica de los sistemas basados en archivos se denomina
dependencia entre los programas y los datos.
8ormatos de archivo incompatibles
'uesto que la estructura de los archivos est$ incrustada en los programas de
aplicacin, dichas estructuras penden del legua"e de programacin de aplicaciones que
se utilice. 'or e"emplo, la estructura de un archivo generador por un programa .EIEL
puede ser diferente de la estructura de un archivo creada por un programa .. La
incompatibilidad directa de dichos archivos hace dif!cil que se los pueda procesar
con"untamente.
'or e"emplo, suponga que el departamento de contratos quiere averiguar los nombres y
direcciones de todos los propietarios cuyos inmuebles estn actualmente alquilados.
<esafortunadamente, el departamento contratos no dispone de la informacin de
detalles sobre los propietarios de los inmuebles, ya que slo el departamento de ventas
tiene esa informacin. +in embargo, el departamento de contratos s! que dispone del
n%mero de inmueble ,property&o-, que puede utilizarse para localizar el n%mero de
inmueble correspondiente en el archivo 'roperty8or;ent del departamento de ventas.
#ste archivo contiene el n%mero de propietario ,ner&o-, que puede utilizarse para
localizar los detalles del propietario en el archivo 'rivateE=ner. Los prozraMnas del
departamento de contratos han sido desarrollados en .obol, mientras que los del
departamento de ventas han sido desarrollados en .. 'or tanto, para establecer la
correspondencia entre los campos property&o W los dos archivos 'roperty8or;ent se
necesita que un desarrollador de aplicaciones escriba un programa soft=are que
convierta los archivos a un formato com%n para facilitar el procesamiento. <e nuevo,
este proceso puede requerir mucho tiempo y resultar muy caro.
.onsultas fi"asXproliferacin de programas de aplicacin
<esde el punto de vista del usuario final, los sistemas basados en archivos
representaron una enorme me"ora n respecto a los sistemas manuales. #n
consecuencia, las peticiones de nuevas consultas o de modificaciones de las ya
e(istentes comenzaron a crecer. +in embargo, los sistemas basados en archivos son
muy dependientes del desarrollador de aplicaciones, que es quien tiene que escribir
todas las consultas e informes requeridos. .omo resultado, sucedieron dos cosas, en
algunas organizaciones, el tipo de consulta o de informe que pod!a producirse era fi"o.
&o e(ist!a ninguna posibilidad de solicitar consultas no planificadas ,es decir, consultas
pensadas en el momento o ad +oc) ni acerca de los propios datos ni acerca de los
datos disponibles.
#n otras organizaciones, se produ"o una proliferacin de archivos y de programas de
aplicacin. Al final, se alcanz un punto en el que el departamento de proceso de datos,
con sus recursos e(istentes, era incapaz de gestionar todo el traba"o. #sto normalmente
llevaba a que se presionara en e(ceso al personal del departamento de proceso de
datos, lo que daba como resultado programas inadecuados o ineficientes a la hora de
satisfacer las demandas de los usuarios, o bien sistemas de documentacin
e(cesivamente limitados o bien programas cuyo mantenimiento era muy complicado. A
menudo, se tend!a a omitir diversos tipos de funcionalidad9
D no se inclu!an mecanismos de seguridad o integridad)
0 la recuperacin, para los casos de fallos de hard=are o soft=are, era limitada o
ine(istente)
D el acceso a los archivos estaba restringido, de modo que slo un usuario pod!a
acceder en cada instante9 no hab!a ning%n tipo de mecanismo para facilitar el acceso
compartido por parte de distintas personas pertenecientes al mismo departamento.
#n cualquier caso, lo que est$ claro es que ese tipo de situacin no era aceptable. +e
necesitaba alg%n otro tipo de solucin.
0.6 Los distintitos niveles de abstraccin de una base de
datos
Ahora estamos en condiciones de presentar la arquitectura para un sistema de base de
datos. &uestro ob"etivo al presentar esta arquitectura es ofrecer una infraestructura en
la que puedan basarse los cap!tulos siguientes. <icha infraestructura resulta %til para
describir los conceptos generales de las bases de datos y para e(plicar la estructura de
sistemas de bases de datos espec!ficos) pero no afirmamos que todo sistema pueda
coincidir enteramente con esta infraestructura en particular, ni queremos sugerir que
esta arquitectura represente la %nica infraestructura posible. #n particular, es probable
que los sistemas pequeos ,vea el cap!tulo 0- no mane"en todos los aspectos de la
arquitectura. +in embargo, la arquitectura parece a"ustarse bastante bien a la mayor!a
de los sistemas) es m$s, es pr$cticamente idntica a la arquitectura propuesta por el
Yrupo de #studio en +istemas de Administracin de Iases de <atos de A&+2X+'A;.
,la tan mencionada arquitectura A&+2X+'A;.. Bea las referencias G:.0\:.:0-. +in
embargo, nosotros decidimos no seguir la terminolog!a A&+2X+'A;. en todos sus
detalles.
!ota" #ste cap!tulo se aseme"a al cap!tulo 0 en el sentido de que tambin es en cierto
modo abstracto y $rido, aunque es fundamental entender el material que contiene para
una apreciacin completa de la estructura y posibilidades de un sistema de base de
datos moderno. 'or lo tanto, al igual que en el cap!tulo 0, tal vez prefiera por ahora slo
darle una le!da ligera y regresar a l m$s tarde, cuando sea directamente relevante
para los temas que est abordando.
LE+ /;#+ &2B#L#+ <# LA A;5*2/#./*;A
La arquitectura A&+2X+'A;. se divide en tres niveles, conocidos como interno,
conceptual y e(terno, respectivamente ,vea la figura :.0-. Cablando en trminos
generales9
D #l nivel interno ,tambin conocido como el nivel fsico) es el que est$ m$s cerca del
almacenamiento f!sico) es decir, es el que tiene que ver con la forma en que los datos
est$n almacenados f!sicamente.
D #l nivel e(terno ,tambin conocido como el nivel l#ico de usuario) es el m$s pr(imo
a los usuarios) es decir, el que tiene que ver con la forma en que los usuarios
individuales ven los datos.
D #l nivel conceptual ,tambin conocido como el nivel l#ico de la comunidad, o en
ocasiones slo como el nivel l#ico, sin calificar- es un nivel de indireccin entre los
otros dos.
Ebserve que el nivel e(terno tiene que ver con las percepciones de usuarios
individuales, mientras que el nivel conceptual tiene que ver con la percepcin de una
comunidad de usuarios.
Fi&ura ;.1
)os tres niveles de la ar'uitectura.
#n otras palabras, habr$ muchas vistas e(ternas distintas, cada una consistente en
una representacin m$s o menos abstracta de alguna parte de la base de datos total, y
habr$ precisamente una vista conceptual que del mismo modo consiste en una
representacin abstracta de la base de datos en su totalidad.^ ,;ecuerde que la
mayor!a de los usuarios no se interesar$n en toda la base de datos, sino slo en una
parte limitada de la misma-. #n forma similar, habr$ precisamente una vista interna
que represente a la base de datos tal como est$ almacenada f!sicamente.
*n e"emplo har$ m$s claras estas ideas. La figura :.: muestra la vista conceptual, la
vista interna correspondiente y dos de las vistas e(ternas ,una para un usuario de 'LM2
y otra para un usuario de .EIEL-, todas ellas para una base de datos de personal
sencilla. 'or supuesto, el e"emplo es completamente hipottico _no pretende refle"ar
ning%n sistema real_ y hemos omitido deliberadamente muchos detalles irrelevantes.
E4plicacin"
D #n el nivel conceptual, la base de datos contiene informacin concerniente a un tipo
de entidad denominada #A'L#A<E. .ada empleado individual tiene un
&*A#;E`#A'L#A<E ,de seis caracteres-, un &*A#;E`<#'A;/AA#&/E ,de
cuatro caracteres- y un +ALA;2E ,de cinco d!gitos decimales-.
D #n el nivel interno, los empleados est$n representados por un tipo de registro
denominado #A'`ALAA.#&A<E, de veinte bytes de longitud. #A'`ALAA.#&A<E
contiene cuatro campos almacenados9 un prefi"o de seis bytes ,que presumiblemente
contiene informacin de control como los indicadores o los apuntadores- y tres campos
de datos correspondientes a las tres propiedades de los empleados. Adem$s, los
registros de #A'`ALAA.#&A<E est$n inde(ados sobre el campo #A'T por medio de
un !ndice de nombre #A'J, cuya definicin no se muestra.
D #l usuario de 'La2 tiene una vista e(terna de la base de datos en la que cada
empleado est$ representado por un registro 'LX2 que contiene dos campos ,los
n%meros de departamento no son de inters para este usuario y por lo tanto fueron
omitidos-. #l tipo del registro est$ definido por una declaracin de estructura 'LX2
ordinaria seg%n las reglas normales de 'L22.
D #n forma similar, el usuario de .EIEL tiene una vista e(terna en la que cada
empleado est$ representado por un registro de .EIEL, que una vez m$s contiene dos
campos ,esta un vez fueron omitidos los salarios-. #l tipo de registro est$ definido por
una descripcin ordinaria de registro .EIEL, de acuerdo con las reglas normales de
.EIEL.
Fi&ura ;.;
Un ejemplo de los tres niveles.
Ebserve que los elementos correspondientes de los datos pueden tener diferentes
nombres en distintos puntos. 'or e"emplo, el n%mero de empleado se denomina #A'T
en la vista e(ti\ terna de 'LX2, #A'&E en la vista e(terna de .EIEL,
&*A#;E`#A'L#A<E en la vista h<E conceptual y nuevamente #A'T en la vista
interna. <esde luego, el sistema debe estar al tanto LA\ de las correspondencias) por
e"emplo, debemos indicar que el campo #A'&E de .EIEL se deriva del campo
conceptual &*A#;E`#A'L#A<E, el cual se deriva a su vez del campo almacenado
#A'T al nivel interno. <ichas correspondencias, o transformaciones, no se muestran de
manera e(pl!cita en la figura :.:) para una e(plicacin m$s amplia, consulte la in
seccin :.>.
Ahora bien, para los fines del presente cap!tulo, no tiene mayor importancia si el
sistema a considerar es relacional o de otro tipo. +in embargo, ser!a %til indicar cmo
son concebidos t!picamente los tres niveles de la arquitectura en un sistema relacional
en particular9
D 'rimero, el nivel conceptual en dicho sistema ser$ definitivamente relacional, en el
sentido est$ de que los ob"etos visibles en ese nivel ser$n tablas relacionales y los
operadores ser$n de tipo relacional ,incluyendo los operadores restrin#ir y proyectar en
particular, que e(pusimos brevemente en el cap!tulo 0-.
D +egundo, una vista e(terna dada tambin ser$ casi siempre relacional. o algo muy
parecido a ello) por e"emplo, las declaraciones de registro de 'LX2 y .EIEL de la figura
:.: podr!an ser consideradas a grandes rasgos como an$logas de las declaraciones de
'LX2 y .EIEL, 0:.0V\ respectivamente, de una tabla relacional en un sistema
relacional.
!ota" <ebemos mencionar de paso que el trmino vista e(terna ,a menudo abreviado
solamente como vista- tiene por desgracia un significado m$s bien espec!fico en con\
te(tos relacionales y que ste no es idntico al significado que se le asigna en este
cap!tulo. 'ara una e(plicacin y e(posicin del significado relacional, consulte los
cap!tulos 3 y 7.
D /ercero, el nivel interno no ser$ relacional, ya que los ob"etos en ese nivel no ser$n
slo tablas relacionales ,almacenadas-) en vez de ello, ser$n los mismos tipos de
ob"etos que se encuentran en el nivel interno de cualquier otro tipo de sistema ,registros
almacenados, apuntadores, !ndices, tablas de dispersin, etctera-. <e hecho, el
modelo relacional como tal no tiene nada en absoluto que decir acerca del nivel interno)
para repetir lo dicho en el cap!tulo 0, tiene que ver con la forma en que la base de datos
se presenta ante el usuario.
Ahora procederemos a e(plicar con m$s detalle los tres niveles de la arquitectura,
comenzando con el nivel e(terno. A lo largo de nuestra e(plicacin haremos constantes
referencias a la figura :.3, la cual muestra los principales componentes de la
arquitectura y sus interrelaciones.
Fi&ura ;.?
Ar'uitectura detallada del sistema.
#L &2B#L #J/#;&E
#l nivel e(terno es el nivel del usuario individual. .omo e(pliqu en el cap!tulo 0, un
usuario dado puede ser un programador de aplicaciones o bien un usuario final con
cualquier grado de sofisticacin. ,#l <IA es un importante caso especial) pero a
diferencia de otros usuarios, el <IA tambin necesitar$ interesarse en los niveles
conceptual e interno. Bea las dos secciones siguientes.-
.ada usuario tiene a su disposicin un lengua"e9
D 'ara el programador de aplicaciones, ste ser$ ya sea un lengua"e de programacin
convencional ,por e"emplo, 'LX2, .LL, Mava- o bien un lengua"e de tipo propietario que
sea espec!fico al sistema en cuestin. A menudo, a estos lengua"es de tipo propietario
se les denomina lengua"es de cuarta generacin ,1YLs-) siguiendo las _confusasO_
bases de que ,a- el cdigo de m$quina, el lengua"e ensamblador y los lengua"es como
'LX2 pueden ser vistos como tres generaciones de lengua"es anteriores, y ,b- los
lengua"es de tipo propietario representan la misma clase de me"ora sobre los lengua"es
de tercera generacin ,3YLs- que la que tuvieron estos lengua"es sobre el lengua"e
ensamblador y la que tuvo el lengua"e ensamblador sobre el cdigo de m$quina.
D 'ara el usuario final, el lengua"e ser$ ya sea un lengua"e de consulta o bien alg%n
lengua"e de finalidad espec!fica, tal vez controlado por formularios o por men%s,
confeccionado para los requerimientos de ese usuario y mane"ado por alg%n programa
de aplicacin en l!nea ,como e(pliqu en el cap!tulo 0-.
#n nuestro caso, lo importante acerca de dichos lengua"es es que incluir$n un
sublengua"e de datos) es decir, un subcon"unto del lengua"e total que se ocupe
espec!ficamente de los ob"etos y operaciones de la base de datos. +e dice que el
sublengua"e de datos ,abreviado como +L< en la figura :.3- est$ incrustado dentro de
su lengua"e anfitrin correspondiente. #l lengua"e anfitrin es el responsable de
proporcionar diversas propiedades que no son espec!ficas de la base de datos, como
las variables locales, las operaciones de c$lculo, la lgica de bifurcacin, etctera. *n
sistema determinado podr!a mane"ar cualquier cantidad de lengua"es anfitrin y
cualquier n%mero de sublengua"es de datos) sin embargo, un sublengua"e de datos
espec!fico soportado por casi todos los sistemas actuales es el lengua"e +5L que
e(plicamos brevemente en el cap!tulo 0. La mayor!a de dichos sistemas permiten que
+5L sea utilizado de manera interactiva, como un lengua"e de consulta independiente,
e incrustado en otros lengua"es como 'LX2 o Mava ,para una e(plicacin m$s amplia,
consulte el cap!tulo 1-.
Ahora bien, aunque para fines de la arquitectura es conveniente distinguir entre el
sublengua"e de datos y el lengua"e anfitrin que lo contiene, ambos podr!an no ser
distintos en lo que al usuario concierne) y de hecho, desde el punto de vista del usuario,
es probablemente me"or que no lo sean. +i no son distintos, o si dif!cilmente pueden
distinguirse, decimos que est$n fuertemente acoplados. +i son clara y f$cilmente
separables, decimos que est$n dbilmente acoplados. Aunque algunos sistemas
comerciales ,en especial los orientados a ob"etos) vea el cap!tulo :1- s! mane"an el
acoplamiento fuerte, la mayor!a no lo hace) en particular, los sistemas +5L
generalmente slo mane"an el acoplamiento dbil. ,#l acoplamiento fuerte ofrece un
con"unto m$s uniforme de propiedades para el usuario, aunque obviamente implica m$s
esfuerzo por parte de los desarrolladores del sistema, un hecho que presumiblemente
cuenta para el statu 9uo.)
#n principio, cualquier sublengua"e de datos determinado es en realidad una
combinacin de por lo menos dos lengua"es subordinados9 un <<L ,lengua"e de
definicin de datos-, que permite la definicin o declaracin de ob"etos de base de
datos, y un <AL ,lengua"e de manipulacin de datos-, que permite la manipulacin o
procesamiento de dichos ob"etos. 'or e"emplo, considere al usuario de 'LX2 de la figura
:.: de la seccin :.:. #l sublengua"e para ese usuario consiste en aquellas
caracter!sticas de 'LX2 que se usan para comunicarse con el <IA+9
La parte del <<L consiste en aquellas construcciones declarativas de 'LX2 necesarias
para declarar ob"etos de base de datos) la propia instruccin <#.LA;# ,<.L-, ciertos
tipos de datos de 'LX2, tal vez e(tensiones especiales de 'LX2 para mane"ar nuevos
ob"etos que no mane"a el 'L22 e(istente.
La parte del <AL consiste en aquellas instrucciones e"ecutables de 'L22 que transfieren
informacin hacia y desde la base de datos) de nuevo, que incluyen tal vez nuevas
instrucciones especiales.
!ota" 'ara ser m$s precisos, debemos decir que al momento de la publicacin de este
libro, 'La2 no inclu!a ninguna caracter!stica espec!fica de base de datos. #n particular,
las instrucciones <AL por lo regular slo son instrucciones .ALL de 'LX2 que invocan
al <IA+ ,aunque esas instrucciones podr!an de alguna forma estar disfrazadas
sint$cticamente para hacerlas un poco m$s sencillas para el usuario) vea la e(plicacin
de +5L incrustado, en el cap!tulo 1-.
Bolviendo a la arquitectura, ya indicamos que un usuario individual se interesar$
generalmente slo por alguna parte de toda la base de datos) es m$s, la vista que el
usuario tiene de esa parte normalmente ser$ un poco abstracta al compararla con la
forma en que los datos est$n almacenados f!sicamente. #l trmino A&+MM+'A;.
utilizado para la vista de un usuario individual es el de vista e(terna. 'or lo tanto, una
vista e(terna es el contenido de una base de datos como lo ve alg%n usuario en
particular ,es decir, para ese usuario, la vista e(tern es la base de datos-. 'or e"emplo,
un usuario del <epartamento de 'ersonal podr!a ver a la base de datos como una
coleccin de ocurrencias de los registros de empleado y departamento, y podr!a
desconocer las ocurrencias de los registros de parte y proveedor que ven los usuarios
del <epartamento de .ompras.
#ntonces, en general, una vista e(terna consiste en muchas ocurrencias de cada uno
de los tipos de registro e(terno ,que no es necesariamente lo mismo que un registro
almacenado-.^ #l sublengua"e de datos del usuario est$ definido en trminos de
registros e(ternos) por e"emplo, una operacin de recuperacin del <AL recuperar$
ocurrencias de registros e(ternos, no ocurrencias de registros almacenados. !ota"
Ahora podemos ver que el trmino registro lgico, empleado ocasionalmente en el
cap!tulo 0, se refer!a en realidad a un registro e(terno. <e hecho, desde este punto de
vista, trataremos de evitar el trmino registro lgico
.ada vista e(terna est$ definida por medio de un esquema e(terno, el cual consiste
b$sicamente en definiciones de cada uno de los diversos tipos de registros e(ternos de
esa vista ,observe una vez m$s en la figura :.:, un par de e"emplos sencillos-. #l
esquema e(terno fue escrito utilizando la parte <<L del sublengua"e de datos del
usuario. ,<e ah! que en ocasiones se haga referencia a ese <<L como &&3 e4ternB1
'or e"enfplo, el tipo de registro e(terno de empleado podr!a defiuiirse como un campo
de n%mero de empleado con seis caracteres, m$s un campo de salario con cinco
d!gitos ,decimales- y as! sucesivamente. Adem$s, debe haber una definicin de la
transformacin entre el esquema e(terno y el esquema conceptual subyacente ,vea la
siguiente seccin-. A$s adelante, en la seccin :.>, consideraremos dicha
transformacin.
#L &2B#L .E&.#'/*AL
La vista conceptual es una representacin de todo el contenido de la informacin de la
base de datos, de nuevo ,al igual que con la vista e(terna- en una forma un poco
abstracta comparada con la forma en la que por lo regular se almacenan los datos
f!sicamente. /ambin ser$ muy diferente de la forma en que cualquier usuario
espec!fico ve los datos. #n trminos generales, la vista conceptual pretende ser una
vista de los datos tal como son, en vez de tal como los usuarios est$n obligados a
verlos debido a las limitaciones ,por e"emplo- del lengua"e o el hard=are en particular
que pudieran utilizar.
La vista conceptual consiste en muchas ocurrencias de varios tipos de registro
conceptual. 'or e"emplo, podr!a consistir en un con"unto de ocurrencias de los registros
de departamento, m$s un con"unto de ocurrencias de los registros de empleado, m$s
un con"unto de ocurrencias de los registros de proveedor, m$s un con"unto de
ocurrencias de los registros de parte ,y as! sucesivamente-. 'or otra parte, un registro
conceptual no es necesariamente lo mismo que un registro e(terno, ni que un registro
almacenado.
La vista conceptual est$ definida por medio del esquema conceptual, el cual comprende
definiciones de cada uno de los diversos tipos de registros conceptuales ,de nuevo,
consulte la figura :.: para ver un e"emplo sencillo-. #l esquema conceptual est$ escrito
con otro lengua"e de definicin de datos, el &&3 conceptual. +i se va a lograr la
independencia f!sica de los datos, entonces las definiciones conceptuales de <<L no
deben comprender en lo absoluto ninguna consideracin de la representacin f!sica ni
de la tcnica de acceso) deben ser 6nicamente definiciones del contenido de la
informacin. 'or lo tanto, en el esquema conceptual no debe haber ninguna referencia
para la representacin de campos almacenados, la secuencia de registros
almacenados, los !ndices, los esquemas de dispersin. los apuntadores o cualquier otro
detalle de almacenamiento y acceso. +i el esquema conceptual se hace
verdaderamente independiente de los datos, entonces los esquemas e(ternos, que
est$n definidos en trminos del esquema conceptual ,vea la seccin :.>-, tambin
ser$n for>osamente independientes de los datos.
#ntonces, la vista conceptual es una vista del contenido total de la base de datos, y el
esquema conceptual es una definicin de esa vista. +in embargo, ser!a engaoso dar
por hecho que el esquema conceptual no es nada m$s que un con"unto de definiciones
muy similar a las definiciones que se encuentran ,por e"emplo- en un programa .EIEL
actual. Las definiciones del esquema conceptual pretenden incluir muchas
caracter!sticas adicionales, como las restricciones de seguridad y de integridad
mencionadas en el cap!tulo 0. Algunas autoridades van m$s le"qs al sugerir que el
ob"etivo final del esquema conceptual es describir toda la empresa) no slo los datos
como tales, sino tambin la forma en que son utilizados, la forma en que fluyen de un
punto a otro dentro de la empresa, su funcin en cada punto, lo controles de auditor!a u
otros que se aplican en cada punto, etctera :.3H. +in embargo, debemos enfatizar que
en la actualidad ning%n sistema soporta realmente un esquema conceptual de cualquier
cosa que se apro(ime a este grado de amplitud) en la mayor!a de los sistemas
e(istentes, el esquema conceptual es en realidad algo m$s que una simple unin de
todos los esquemas e(ternos individuales m$s ciertas restricciones de seguridad y de
integridad. Aunque en verdad es posible que los sistemas futuros sean mucho m$s
sofisticados en cuanto al soporte del nivel conceptual.
#L &2B#L 2&/#;&E
#l tercer nivel de la arquitectura es el nivel interno. La vista interna es una
representacin de ba"o nivel de toda la base de datos y consiste en muchas ocurrencias
de cada uno de los diversos tipos de registros internos. ;egistro interno es el trmino
de A&+MM+'A;. para la construccin que hemos venido llamando registro
almacenado ,y que seguiremos utilizando-. 'or lo tanto, la vista interna est$ todav!a
distante del nivel f!sico, ya que no tiene que ver con trminos como registros ftsicos
,tambin denominados bloques o p$ginas- ni con ninguna consideracin espec!fica de
los dispositivos, como el tamao de los cilindros o de las pistas. #n otras palabras, la
vista interna en efecto da por hecho un espacio de direcciones lineal infinito) los detalles
de cmo el espacio de direcciones se asocia con el almacenamiento f!sico, son en gran
medida espec!ficos del sistema y se omiten deliberadamente de la arquitectura general.
!ota" #l bloque, o p$gina, es la unidad de EI$ es decir, es la cantidad de datos
transferidos entre el almacenamiento secundario y la memoria principal en una sola
operacin de #X+. Los tamaos t!picos de p$gina son 0 PI, : PI o1 PI ,0 PI b 0V:1
bytes-.
La vista interna se describe por medio del esquema interno, el cual no slo define los
diversos tipos de registres almacenados sino que especifica tambin qu !ndices
e(isten, cmo est$n representados los campos almacenados, en qu secuencia est$n
dichos registros, etctera. ,*na vez m$s, observe un e"emplo sencillo en la figura :.:.-
#l esquema interno est$ escrito utilizando otro lengua"e m$s de definicin de datos9 el
&&3 interno. !ota" #n este libro usaremos normalmente los trminos m$s intuitivos
estructura de almacenamiento o base de datos almacenada en lugar de vista
interna, as! como el trmino definicin de la estructura de almacenamiento en lugar
de esquema interno.
'ara terminar, sealamos que, en ciertas situaciones e(cepcionales, a los programas
de aplicacin Gen particular, las aplicaciones de utilera ,vea la seccin :.00-H se les
podr!a permitir operar directamente en el nivel interno en vez del nivel e(terno. +obra
decir que no es recomendable esta pr$ctica, pues representa un riesgo para la
seguridad ,ya que se ignoran las restricciones de seguridad- y un riesgo para la
integridad ,debido a que, de igual manera, se ignoran las restricciones de integridad-.
Adem$s, para iniciar, el programa ser$ dependiente de los datos) aunque, en
ocasiones, sta podr!a ser la %nica forma de obtener la funcionalidad o el rendimiento
requeridos ,tal como le sucede al usuario de un lengua"e de programacin de alto nivel
que ocasionalmente tendr!a que descender al lengua"e ensamblador para satisfacer
ciertos ob"etivos de funcionalidad o rendimiento-.
/;A&+8E;AA.2E&#+
Adem$s de los tres niveles como tales, la arquitectura de la figura :.3 comprende
ciertas transformaciones) en general, una transformacin conceptualXinterna y varias
transformaciones e(ternasXconceptual9
D La transformacin conceptual*interna define la correspondencia entre la vista
conceptual y la base de datos almacenada, y especifica cmo est$n representados los
registros y campos conceptuales en el nivel interno. +i se modifica la estructura de la
base de datos ,es decir, si se hace un cambio a la definicin de la estructura de
almacenamiento-, entonces por consiguiente ser$ necesario modificar la transformacin
conceptualXinterna, de manera que el esquema conceptual pueda permanecer
invariable. ,'or supuesto, es responsabilidad del <IA administrar dichos cambios.- #n
otras palabras, los efectos de dichos cambios deben aislarse por deba"o del nivel
conceptual, a fin de preservar la independencia f!sica de los datos.
D La transformacin e4terna*conceptual define la correspondencia entre una vista
e(terna en particular y la vista conceptual. #n general, las diferencias que puedan
e(istir entre estos dos niveles son an$logas a aquellas que puedan e(istir entre la vista
conceptual y la base de datos almacenada. 'or e"emplo, los campos pueden tener
diferentes tipos de datos) los nombres de los registros y campos pueden ser
cambiados) varios campos conceptuales pueden combinarse en un solo registro
e(terno ,virtual-) etctera. 'uede e(istir cualquier cantidad de vistas e(ternas al mismo
tiempo) cualquier n%mero de usuarios puede compartir una vista e(terna dada) es
posible traslapar diferentes vistas e(ternas.
!ota" <ebe quedar claro que as! como la transformacin conceptualXinterna es la clave
para la independencia f!sica de los datos, tambin las transformaciones
e(ternasXconceptual son la clave para la independencia lgica de los datos. .omo
vimos en el cap!tulo 0, un sistema proporciona la independencia f!sica de los datos G0.3H
si los usuarios y los programas de usuario son inmunes a los cambios en la estructura
f!sica de la base de datos almacenada. <e igual manera, un sistema proporciona la
independencia l#ica de los datos G0.1H silos usuarios y los prograremos mas de usuario
tambin son inmunes a los cambios en la estructura l#ica de la base de datos ,lo que
significa cambios al nivel conceptual o lgico de la comunidad-. #n los cap!tulos 3 y 7,
tendremos m$s que decir respecto de este tema importante.
'or cierto, la mayor!a de los sistemas permiten que la definicin de ciertas vistas
e(ternas se e(prese en trminos de otras ,en efecto, mediante transformaciones
e4ternas*e4ternas), en vez de requerir siempre una definicin e(pl!cita de la
transformacin al nivel conceptual) una caracter!stica %til si varias vistas e(ternas son
parecidas entre s!. #n particular, los sistemas relacionales brindan dicha posibilidad.
0.> suarios y administradores de la base de datos
FIGURA 1.?
!ate&or/as de usuarios administrativos
#n p$rrafos anteriores se ha hecho mencin de los usuarios, gerentes y empleados de
una organizacin que interact%an con los sistemas de informacin. #l grado de
participacin quiz$ cambie y esto depende del tipo de usuario ,8ig. 0.3-.
Los analistas emplean el trmino usuario final para referirse a las personas que no son
especialistas en sistemas de informacin pero que utilizan las computadoras para
desempear su traba"o. Los usuarios finales pueden agruparse en cuatro categor!as.
Los usuarios primarios son los que interact%an con el sistema. #llos lo alimentan con
datos ,entradas- o reciben salidas, quiz$ por medio de una terminal. Los agentes de
reservacin de vuelos, por e"emplo, emplean las terminales para consultar el sistema y
obtener informacin relacionada con pasa"eros, vuelos y boletos.
Los usuarios indirectos son aquellos que se benefician de los resultados o reportes
generados por estos sistemas pero que no interact%an de manera directa con el
hard=are o soft=are. #stos usuarios que utilizan el sistema, pueden ser los gerentes
encargados de las funciones de la empresa ,por e"emplo, los gerentes de
mercadotecnia son los responsables de las aplicaciones de an$lisis de ventas que
generan los reportes mensuales de la compa!a en este ramo-.
&o todos los usuarios finales tienen la misma e(periencia. Algunos nunca han usado
una computadora mientras que otros interact%an cotidianamente con un sistema de
informacin. .ada grupo debe ser capaz de utilizar el sistema con facilidad y de manera
oportuna cuando sea necesario, aunque su empleo no forme parte de la rutina
cotidiana. Al mismo tiempo, las caracter!sticas necesarias del sistema para satisfacer
las necesidades del usuario ocasional ,tales como la capacidad de proporcionar ayuda
adicional- no deben interferir con el traba"o de los dem$s usuarios. #l analista debe
hacer un esfuerzo para equilibrar las caracter!sticas del sistema para que ste se
adecue a las necesidades de todos los usuarios.
#l usuario final tambin puede ser un competidor y no un empleado de la organizacin.
Algunos sistemas de informacin, por e"emplo, son utilizados por agentes de via"es de
l!neas areas o personal del departamento de compras de otras empresas que tienen
terminales enlazadas con las de sus proveedores ,en el cap!tulo : se introduce el
empleo de los sistemas de informacin con el fin de ganar venta"as competitivas) el
tema tambin aparece en diversas partes del libro donde se habla de diseo de
sistemas-. 'ara este tipo de usuario el sistema debe incorporar consideraciones
adicionales tanto para la interaccin con el usuario como para proteger de cualquier
riesgo a la organizacin que proporciona el servicio.
#(iste un tercer tipo de usuarios, los usuarios #erentes, que tienen responsabilidades
administrativas en los sistemas de aplicacin. Al igual que el e"ecutivo de la narracin al
inicio del cap!tulo, estos usuarios son gerentes de la empresa que utilizan en gran
medida los sistemas de informacin. Aientras estas personas no utilicen los sistemas
ya sea directa o indirectamente, no tendr$n la autoridad para aprobar o no la inversin
en el desarrollo de aplicaciones, adem$s no tendr$n la responsabilidad ante la
organizacin de la efectividad de los sistemas ,en el mismo sentido que el
vicepresidente de mercadotecnia es el responsable del (ito de todas las ventas y
programas de mercadotecnia-. <e lo anterior se desprende que esta categor!a de
usuarios es la que debe participar en los esfuerzos de desarrollo de sistemas mayores,
aspecto en el que se hace hincapi en cap!tulos posteriores.
<e particular importancia reviste el hecho de que los usuarios directivos, el cuarto grupo
de usuarios, toman cada vez mayor responsabilidad en el desarrollo de sistemas de
informacin. Las organizaciones bien dirigidas consideran el posible impacto y los
beneficios de los sistemas de informacin cuando elaboran su estrategia competitiva.
#l uso creciente de los sistemas de informacin, sin embargo, es un arma de dos filos
que tiene beneficios y tiene riesgos. <ado que los sistemas de informacin
desarrollados en forma inadecuada pueden entorpecer, e incluso daar, las actividades
de una organizacin, los directivos deben evaluar de manera constante los riesgos a los
que se e(pone la empresa en caso de falla de los sistemas de informacin.
Los cuatro tipos de usuarios son importantes. .ada uno posee informacin esencial
sobre las funciones de la organizacin y hacia dnde se dirige sta. Los analistas de
sistemas, sin embargo, son los que proporcionan las ideas _la imaginacin_ con
respecto a las me"ores formas para usar eficientemente las computadoras. La
informacin que re%nen los analistas sobre el sistema de la empresa, forma b base para
el diseo de nuevos sistemas o para las modificaciones de los que ya e(isten.
0.4 Componentes de los sistemas de bases de datos
8alto.
0.S !r"uitectura de los sistemas de bases de datos
#(isten dos tipos de arquitecturas la de cliente\servidor y la arquitectura distribuida.
A;5*2/#./*;A .L2#&/#\+#;B2<E;
Casta ahora, en este cap!tulo hemos venido e(plicando los sistemas de bases de datos
desde el punto de vista de la as! llamada arquitectura A&+2M+'A;.. #n la figura :.3 en
particular, presentamos una imagen simplificada de esta arquitectura. #n esta seccin
estudiaremos los sistemas de bases de datos desde una perspectiva ligeramente
diferente. <esde luego, la finalidad principal de dichos sistemas es apoyar el desarrollo
y la e"ecucin de las aplicaciones de bases de datos. 'or lo tanto, desde un punto de
vista m$s elevado, un sistema de base de datos puede ser visto como un sistema que
tiene una estructura muy sencilla de dos partes, las cuales consisten en un servidor
,tambin denominado parte dorsal o servicios de fondo) y un con"unto de clientes
,tambin llamados partes frontales, aplicaciones para el usuario o interfaces). .onsulte
la figura :.6. E4plicacin"
D #l servidor es precisamente el propio <IA+. +oporta todas las funciones b$sicas del
<IA+ e(puestas en la seccin :.S9 definicin de datos, manipulacin de datos,
seguridad e integridad de los datos, etctera. #n particular, proporciona todo el soporte
de los niveles e(terno, conceptual e interno e(plicados en las secciones :.3 a :.>. 'or
lo tanto, en este conte(to, servidor es slo el nombre del <IA+.
D Los clientes son las diversas aplicaciones que se e"ecutan sobre el <IA+, tanto
aplicaciones escritas por el usuario como aplicaciones integradas ,es decir, aplicaciones
proporcionadas por el fabricante del <IA+ o por alguna otra compa!a-. 'or supuesto,
en lo que concierne al servidor, no hay diferencia entre las aplicaciones escritas por el
usuario y las integradas) todas usan la misma interfaz con el servidor, como la interfaz
de nivel e(terno e(puesta en la seccin :.3.
Fi&ura ;.5
Ar'uitectura cliente5servidor.
!ota" .iertas aplicaciones especiales de utiler!a podr!an constituir una e(cepcin a lo
anterior, ya que en ocasiones podr!an necesitar operar directamente en el nivel interno
del sistema ,como mencion en la seccin C.5). #stas utiler!as son consideradas m$s
bien como componentes integrales del <IA+, en vez de aplicaciones en el sentido
usual. Las e(plico con m$s detalle en la siguiente seccin.
'rofundizaremos un poco sobre la cuestin de aplicaciones escritas por el usuario en
comparacin con las aplicaciones proporcionadas por el fabricante9
D Las aplicaciones escritas por el usuario son en esencia programas de aplicacin
comunes, escritos por lo regular ya sea en un lengua"e convencional de tercera
generacin ,como . o .EIEL- o en alg%n lengua"e de tipo propietario de cuarta
generacin) aunque en ambos casos es necesario acoplar de alguna manera el
lengua"e con un sublengua"e de datos apropiado, como e(pliqu en la seccin :.3.
D Las aplicaciones proporcionadas por el fabricante ,a menudo llamadas herramientas-
son aplicaciones cuya finalidad b$sica es au(iliar en la creacin y e"ecucin de otras
aplicaciones. Las aplicaciones creadas son aplicaciones confeccionadas para alguna
tarea espec!fica ,podr!an no parecer aplicaciones en el sentido convencional) de hecho,
la idea general de las herramientas es permitir a los usuarios, en especial a los usuarios
finales, la creacin de aplicaciones sin tener que escribir programas en un lengua"e de
programacin convencional-. 'or e"emplo, una herramienta proporcionada por el
fabricante ser!a un #enerador de informes, cuyo propsito es permitir a los usuarios
obtener del sistema informes con cierto formato. /oda peticin de informe puede verse
como un pequeo programa de aplicacin, escrito en un len#ua1e #enerador de
informes de muy alto nivel ,y de finalidad especial-.
Las herramientas proporcionadas por el fabricante pueden dividirse en varias clases
relativamente distintas9
a. 'rocesadores de lengua"e de consulta)
b. Yeneradores de informes)
c. +ubsistemas de gr$ficos comerciales)
d. Co"as de c$lculo)
e. 'rocesadores de lengua"e natural)
f. 'aquetes estad!sticos)
g. Cerramientas de administracin de copias o e(traccin de datos)
h. Yeneradores de aplicaciones ,incluyen procesadores 1YL-)
i. Etras herramientas de desarrollo de aplicaciones, incluyendo productos de
ingenier!a de soft=are asistida por computadora ,.A+#-)
y muchos otros. Los detalles de dichas herramientas e(ceden el alcance de este libro)
sin embargo, sealaremos que ,como di"imos antes- debido a que la idea general de un
sistema de base de datos es apoyar la creacin y e"ecucin de aplicaciones, la calidad
de las herramientas disponibles es, o deber!a ser, un factor primordial en la decisin de
la base de datos ,es decir, en el proceso de seleccionar un nuevo producto de base de
datos-. #n otras palabras. el <IA+ como tal no es el %nico factor a tomar en
consideracin, ni tampoco es necesariamente el factor m$s importante.
.erramos esta seccin con una referencia anticipada. 'uesto que el sistema en su
con"unto puede ser dividido claramente en dos partes ,clientes y servidores-, surge la
posibilidad de operar los dos en m9uinas diferentes. #n otras palabras, e(iste el
potencial para el procesamiento distribuido. 'rocesamiento distribuido significa que es
posible conectar distintas m$quinas en cierto tipo de red de comunicaciones, de tal
manera que una sola tarea de procesamiento de datos pueda dividirse entre varias
m$quinas de la red. <e hecho, esta posibilidad es tan atractiva _por diversas razones,
principalmente econmicas_ que el trmino clienteservidor ha llegado a aplicarse
casi e(clusivamente al caso en el que el cliente y el servidor est$n, en efecto, en
m$quinas distintas. #n la seccin :.0: e(plicar con m$s detalle el procesamiento
distribuido.
*/2L#;aA+
Las utiler!as son programas diseados para ayudar al <IA en sus numerosas tareas
administrativas. .omo mencion en la seccin anterior, algunos programas de utiler!a
operan en el nivel e(terno del sistema y en realidad no son m$s que aplicaciones de
propsito especial) algunas podr!an incluso no ser proporcionadas por el fabricante del
<IA+, sino por alguna otra compa!a. +in embargo, otras utiler!as operan
directamente en el nivel interno ,en otras palabras, son realmente parte del servidor-, de
ah! que deban ser proporcionadas al fabricante del <IA+.
Aqu! hay algunos e"emplos del tipo de utiler!as que com%nmente son requeridas en la
pr$ctica9
D ;utinas de carga, para crear la versin inicial de la base de datos a partir de uno o
m$s archivos del sistema operativo)
D ;utinas de descargaXrecarga, para descargar la base de datos ,o partes de ella-, para
respaldar los datos almacenados y para recargar datos desde dichas copias de
respaldo ,por supuesto la rutina de recarga es b$sicamente idntica a la rutina de
carga recin mencionada-)
D ;utinas de reorganizacin, para reordenar los datos en la base de datos almacenada,
por distintas razones que normalmente tienen que ver con el desempeo) por e"emplo,
agrupar datos en el disco de alguna forma en particular o recuperar espacio ocupado
por datos que se volvieron obsoletos)
D ;utinas estad!sticas, para calcular diversas estad!sticas de desempeo, como el
tamao de los archivos, las distribuciones de valores, los contadores de operaciones de
#X+, etc9
D ;utinas de an$lisis, para analizar las estad!sticas arriba mencionadas)
y as! sucesivamente. 'or supuesto, esta lista representa slo una pequea muestra del
rango de funciones que ofrecen generalmente las utiler!as) e(iste una gran cantidad de
otras posibilidades.
#L ';E.#+AA2#&/E <2+/;2I*2<E
'ara repetir lo dicho en la seccin :.0V, el trmino procesamiento distribuido significa
que distintas m$quinas pueden conectarse en una red de comunicaciones como
2nternet, de tal manera que una sola tarea de procesamiento de datos pueda
e(tenderse a varias m$quinas de la red. ,#n ocasiones, tambin se usa el trmino
procesamiento paralelo b$sicamente con el mismo significado, con e(cepcin de que
las m$quinas distintas tienden a estar f!sicamente muy cerca en un sistema paralelo,
lo que no es necesario en un sistema distribuido) en %ltimo caso, por e"emplo, podr!an
estar geogr$ficamente dispersas-. La comunicacin entre las diversas m$quinas es
mane"ada mediante alg%n tipo de soft=are de administracin de redes) tal vez una
e(tensin del administrador .< que e(plicamos en la seccin :.7 y m$s probablemente
un componente de soft=are independiente.
#l procesamiento distribuido presenta muchos niveles o variedades posibles. 'ara
repetir lo dicho en la seccin :.0V, un caso sencillo comprender!a la operacin de los
servicios dorsales del <IA+ ,el servidor- en una m$quina y las aplicaciones de usuario
,los clientes- en otra. .onsulte la figura :.>.
.omo mencion al final de la seccin :.0V, aunque estrictamente hablando el trmino
cliente\servidor es puramente arquitectnico. +e ha convertido casi en sinnimo de la
organizacin ilustrada en la figura :.>, en la que un cliente y un servidor se e"ecutan en
m$quinas diferentes. <e hecho, hay muchos argumentos a favor de dicho esquema9
#l primero es b$sicamente el simple argumento de procesamiento paralelo
normal9 es decir, ahora se est$n aplicando muchas unidades de procesamiento para las
tareas en con"unto, mientras que el procesamiento del servidor ,base de datos- y del
cliente ,aplicacin- se est$n haciendo en paralelo. <e ah! que el tiempo de respuesta y
la velocidad real de transporte tengan me"or!as.
Adem$s, la m$quina servidor podr!a ser una m$quina construida a la medida y
adaptada a la funcin del <IA+ ,una m$quina de base de datos- y podr!a, por lo
tanto, proporcionar un me"or desempeo del <IA+.
#n forma similar, la m$quina cliente podr!a ser una estacin de traba"o personal
adaptada a las necesidades del usuario final y por lo tanto, capaz de proporcionar
me"ores interfaces. una alta disponibilidad, respuestas m$s r$pidas y en general una
me"or facilidad de uso ara0 el usuario.
Barias m$quinas cliente distintas podr!an ser ,de hecho ser!an- capaces de
acceder a la misn0 m$quina servidor. 'or lo tanto, una sola base de datos podr!a ser
compartida entre varios sistemas cliente distintos ,vea la figura :.4-.
Fi&ura ;.$
!liente < servidor operando en m'uinas di"erentes.
Adem$s de los argumentos anteriores, est$ el punto de que e"ecutar los clientes y el
servidor en m$quinas separadas coincide con la forma en que operan en realidad las
empresas. #s muy com%n que una sola empresa ,por e"emplo, un banco- opere
muchas computadoras, de tal modo que los datos de una parte de la empresa estn
almacenados en una computadora y los datos de otra parte estn almacenados en otra
computadora. /ambin es bastante com%n que los usuarios de una computadora
necesiten acceso por lo menos ocasional a los datos almacenados en otra
computadora. +iguiendo con el e"emplo del banco, es muy probable que los usuarios de
una sucursal necesiten acceder ocasionalmente a los datos almacenados en otra.
Ebserve, por L tanto, que las m$quinas cliente podr!an tener almacenados datos
propios y que la m$quina servidor podr!a tener sus propias aplicaciones. 'or lo tanto, es
com%n que cada m$quina act%e como servidor para ciertos usuarios y como cliente
para otros ,vea la figura :.S-) en otras palabras, cada m$quina soportar$ un sistema de
base de datos completo.
Fi&ura ;.6
Una m'uina servidor= varias m'uinas diente.
Fi&ura ;.7
!ada m'uina opera como clientes < como servidor.
La idea final es que una sola m$quina cliente podr!a ser capaz de acceder a varias
m$quinas servidor diferentes ,lo contrario al caso ilustrado en la figura :.4-. #sta
posibilidad es conveniente ya que, como mencion antes, las empresas operan por lo
regular de tal manera que la totalidad de sus datos no est$n almacenados en una sola
m$quina, sino m$s bien est$n esparcidos a travs de muchas m$quinas distintas, y las
aplicaciones necesitar$n a veces tener la posibilidad de acceder a los datos de m$s de
una m$quina. I$sicamente, este acceso puede ser proporcionado en dos formas9
D *na m$quina cliente dada podr!a ser capaz de acceder a cualquier cantidad de
servidores, pero slo uno a la vez ,es decir, cada peticin individual de base de datos
debe ser dirigida a un solo servidor-. #n un sistema as!, no es posible combinar datos
de dos o m$s servidores con una sola peticin. Adem$s, el usuario de dicho sistema
debe saber qu m$quina en particular contiene qu piezas de datos.
D #l cliente podr!a ser capaz de acceder a varios servidores en forma simult$nea ,es
decir, una sola peticin de base de datos podr!a combinar datos de varios servidores-.
#n este caso, los servidores ven al cliente ,desde un punto de vista lgico- como si en
realidad fuera un solo servidor y el usuario no tiene que saber qu m$quinas contienen
qu piezas de datos.
#ste %ltimo caso constituye lo que por lo regular se denomina un sistema de base de
datos distribuida. La base de datos distribuida es en s! un tema e(tenso. Llevada a su
conclusin lgica, el soporte total a la base de datos distribuida implica que una sola
aplicacin debe ser capaz de operar de manera transparente sobre los datos que
est$n dispersos a travs de una variedad de bases de datos diferentes, las cuales son
administradas por una variedad de <IA+s distintos. operan en varias m$quinas
distintas, son mane"adas por varios sistemas operativos diferentes y est$n conectadas
por una variedad de redes de comunicacin distintas) aqu!, de manera transparente
significa que la aplicacin opera desde un punto de vista lgico como si los datos fueran
mane"ados por un solo <IA+ y en una sola m$quina. R*na posibilidad como sta
podr!a parecer muy dif!cil de lograrO) pero es bastante conveniente desde una
perspectiva pr$ctica, y los fabricantes est$n haciendo un gran esfuerzo para hacer
realidad dichos sistemas.