Antología para Bases de Datos Corporativas PDF

DEPARTAMENTO DE INGENIERA EN
SISTEMAS COMPUTACIONALES
3443

M.IT18.362
Bases de
Datos
Distribuidas
Ing. Luis Armando Garca
Eliseo
Agosto
2012
En ste curso se pretende desarrollar un esquema completo de
flujo de informacin, en donde se pueda conocer y dominar el
manejo de los registros en ambientes distribuidos. Tomando en
cuenta los principios bsicos de bloqueo de archivos y registros,
la filosofa de programacin orientada a objetos, la seguridad
de la informacin y algunos mecanismos existentes para
desarrollar sistemas de informacin complejos.

3443

El siguiente material es solamente de apoyo para la asignatura de Bases de Datos
Distribuidas, que se imparte en la Facultad de Ingeniera Arturo Narro Siller, en la
Universidad Autnoma de Tamaulipas.

Es importante mencionar, que la informacin aqu utilizada es totalmente extrada
del libro de Fundamentos de Bases de Datos, creado por Henry Korth y Abraham
Silberchatz.

Academia de Tratamiento de Informacin
Tampico, Tamps, Agosto del 2012

3443
Contenido

BASE DE DATOS ORIENTADAS A OBJETOS.............................................................................. 5
1.1 Nuevas Aplicaciones de las Bases de Datos ....................................................................... 5
1.2 Estructuras de Objetos. ....................................................................................................... 9
1.3 Jerarqua de Clases ........................................................................................................... 10
1.4 Herencia Mltiple ............................................................................................................. 15
1.5 Identidad de objetos .......................................................................................................... 18
1.6 Contenido de Objetos ........................................................................................................ 21
1.7 Organizacin Fsica .......................................................................................................... 22
1.8 Consultas orientadas a objetos ......................................................................................... 24
BASE DE DATOS DISTRIBUIDAS ............................................................................................... 25
2.1 Introduccin a las Bases de Datos Distribuidas .................................................................... 25
2.2 Estructura de Bases de Datos Distribuidas ............................................................................ 26
2.3 Consideraciones al distribuir la base de datos ....................................................................... 28
2.5 Diseo de la Bases de datos Distribuidas ............................................................................... 35
2.6 Procesamiento distribuido de consultas.................................................................................. 46
SEGURIDAD EN LAS BASES DE DATOS ................................................................................... 48
3.1 Introduccin ............................................................................................................................ 48
3.2 Riesgos .................................................................................................................................... 52
3.3 Proteccin de activos y vitales ................................................................................................ 55
3.5 Seguridad Informtica............................................................................................................. 65
HERRAMIENTAS CASE ................................................................................................................ 69
4.1 Introduccin ............................................................................................................................ 69
4.2. Herramientas Case ................................................................................................................. 70
4.3 Tecnologa Case ...................................................................................................................... 72

3443
4.4 Componentes de una herramienta case .................................................................................. 73
4.5 Estructura general de una herramienta CASE........................................................................ 74
4.6 Estado Actual .......................................................................................................................... 75
4.7 Integracin de las herramientas case en el futuro .................................................................. 76
4.8 Clasificacin de las herramientas CASE ................................................................................ 76

3443
BASE DE DATOS ORIENTADAS A OBJETOS

Introduccin

El modelo de datos orientado a objetos est basado en el paradigma de la
programacin orientada a objetos. El lenguaje Simula 67 introdujo por primera vez este
enfoque a la programacin, este lenguaje se dise para la programacin de simulaciones.

Ms recientemente, los lenguajes C++ y Smalltalk han llegado a ser los lenguajes de
programacin orientados a objetos ms ampliamente conocidos.

1.1 Nuevas Aplicaciones de las Bases de Datos

El propsito de los sistemas de bases de datos es la gestin de grandes cantidades de
informacin. Las primeras bases de datos surgieron del desarrollo de los sistemas de
gestin de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en
bases de datos jerrquicas y, ms tarde, en bases de datos relacionales. Entre las
caractersticas comunes de estas viejas aplicaciones estn:
Uniformidad. Existe un gran nmero de datos estructurados de manera similar, todos
del mismo tamao (en bytes).
Orientada en registros. Los datos bsicos constan de registros de longitud fija.
Datos pequeos. Todos los registros son cortos. A menudo los registros tienen 80 bytes
o menos, reflejando el tamao de las tarjetas perforadas, como era lo normal en la
dcada de los aos de los sesenta. A lo sumo, los registros tienen unos pocos cientos de
bytes.

3443
Campos atmicos. Los campos de un registro son cortos y de longitud fija. No hay una
estructura en los campos. Entre otras palabras se cumple la primera forma normal.
Transacciones cortas. Las transacciones son programas con un tiempo de ejecucin
medido en fracciones de segundo. No hay interaccin humana con la transaccin
durante su ejecucin, la somete a ejecucin y espera la respuesta.
Esquemas de concepto esttico. El esquema de la base de datos solo se cambia con
muy poca frecuencia. Cuando se cambia, los tipos de cambio permitidos son sencillos.
En un sistema relacional, las nicas modificaciones de esquema permitidas
normalmente son crear relaciones, eliminar relaciones, aadir atributos en un esquema
de relaciones y eliminar atributos en un esquema de relaciones.

Sin embargo, en aos recientes, la tecnologa de bases de datos se ha adaptado a
aplicaciones fuera del mbito del procesamiento de datos que, en general, les falta al menos
una de las caractersticas anteriores. Estas nuevas aplicaciones incluyen:
Diseo Asistido por Computador (Computer Aided Design (CAD)). Una base de datos
CAD almacena datos pertenecientes a un diseo de ingeniera, incluyendo los
componentes del dato que se est diseando, la relacin de los componentes y las
versiones antiguas de los diseos.
Ingeniera de Software Asistida por Computador. (Computer Aided Software
Engineering (CASE)) Una base de datos CASE almacena los datos requeridos para
asistir a los que desarrollan el software. Estos datos incluyen cdigo fuente,
dependencias entre mdulos, software, definiciones y usos de variables, as como la
historia del desarrollo del sistema software.

3443
Base de datos Multimedios. Una base de datos de multimedios contiene datos
salpicados, datos de audio, datos de video, y similares. Las bases de datos de este tipo
derivan de datos geofsicos, sistema de correo por voz y aplicaciones graficas.
Sistemas de Informacin de Oficina. (Office Information System (OIS)). La informtica
incluye herramientas basadas en estaciones de trabajo para creacin y recuperacin de
documentos, herramientas para mantener calendarios con citas, etctera. Una base de
datos OIS debe permitir consultas que pertenezcan a planificaciones, documentos y
contenidos de documentos.
Sistemas Expertos de Bases de Datos. Un sistema experto de base de datos, adems de
datos, incluye reglas explicitas que representan las restricciones de integridad,
disparadores y otros conocimientos acerca de la empresa que est modelando la base de
datos.

Estas nuevas aplicaciones de las bases de datos no se consideraron en la dcada de
los setenta, que fue cuando se disearon la mayor parte de los sistemas de bases de datos
actuales. En la actualidad son prcticas, debido al aumento en el tamao de la memoria
principal disponible, la velocidad de las unidades centrales de procesamiento, la reduccin
del coste del hardware y la mejora en el entendimiento del manejo de las base de datos que
se ha logrado en los ltimos aos.

Estas nuevas aplicaciones requieren nuevos modelos de datos, nuevos lenguajes de
consulta y nuevos modelos de transacciones. Entre los requisitos de estas nuevas
aplicaciones estn:

3443
Objetos complejos. Un objeto es un dato que es visto como un simple objeto en el
mundo real, pero que contiene otros objetos. Estos objetos pueden tener una estructura
interna compleja arbitraria. A menudo los objetos estn estructurados jerrquicamente,
representando la relacin entre ellos. El modelo de objetos complejos ha llevado al
desarrollo de las bases de datos orientada a objetos, las cuales estn basadas en los
conceptos de los lenguajes de programacin orientada a objetos y a las bases de datos
relacionales anidadas. En las que las relaciones pueden almacenarse dentro de otras
relaciones.
Datos de comportamiento. Puede que distintos objetos necesiten responder de
diferentes formas a la misma orden. Por ejemplo, la eliminacin de ciertas tuplas
pueden requerir la eliminacin de otras tuplas, como en el caso de las entidades dbiles.
En las aplicaciones CAD y CASE el comportamiento de distintos objetos en respuesta a
una orden dada puede ser muy diferente. Esta informacin sobre el comportamiento
puede capturarse almacenando cdigo ejecutable con objetos en la base de datos. Los
mtodos de los sistemas de bases de datos orientado a objetos y la regla base de los
sistemas basados en comportamientos proporcionan esta capacidad.
Meta Conocimiento. A menudo los datos ms importantes sobre aplicaciones son reglas
generales acerca de la aplicacin ms que de las tuplas especficas. Ejemplo de este
tipo, sera: Todas las cuentas de cheques pagan el 5% de inters si el saldo es mayor de
1000; en caso contrario, no pagan inters. Hechos de este tipo no pueden representarse
fcilmente mediante reglas en base de datos lgicas. Las reglas forman una parte
importante de los sistemas expertos de bases de datos.
Transacciones de larga duracin. Las aplicaciones CAD y CASE implican interaccin
humana con los datos. Algunas de estas interacciones pueden ser modificaciones que
si el usuario desea puede deshacer. Los esfuerzos del diseo concurrente que implican

3443
varios diseadores pueden conducir a conflictos entre transacciones. Debido a que estas
transacciones implican interaccin humana con el sistema, las consecuencias de abortos
de transacciones, esperas por bloqueos, etc., son mucho ms serias que en las
transacciones no interactivas cortas comnmente usadas en las aplicaciones tipo
negocios.

1.2 Estructuras de Objetos.

El modelo orientado a objetos se basa en encapsular cdigo y datos en una nica
entidad, llamada objeto. La interfaz entre un objeto y el resto del sistema se define
mediante un conjunto de mensajes.

El motivo de este enfoque puede ilustrarse considerando una base de datos de
documentos en la que los documentos se preparan usando uno entre varios paquetes de
software con formateador de texto. Para imprimir un documento debe ejecutarse el
formateador correcto en el documento. Bajo un enfoque orientado a objetos, cada
documento es un objeto que contiene el texto de un documento y el cdigo que opera sobre
el objeto. Todos los objetos del documento responden al mensaje de imprimir pero lo hacen
en formas diferentes. Cada documento responde ejecutando el cdigo de formatear
adecuado. Encapsulando dentro del objeto del documento la informacin acerca de cmo
imprimir el documento, podemos tener todos los documentos con el mismo interfaz externo
al usuario.

En general, un objeto tiene asociado:

3443
Un conjunto de variables que contienen los datos del objeto. El valor de cada variable
es un objeto.
Un conjunto de mensajes a los que el objeto responde.
Un mtodo, que es un trozo de cdigo para implementar cada mensaje. Un mtodo
devuelve un valor como respuesta al mensaje.

El termino de mensaje en un contexto orientado a objetos no implica el uso de un
mensaje fsico en una red de computadoras, sino que se refiere al paso de solicitudes entre
objetos sin tener en cuenta detalles especficos de implementacin.

Puesto que el nico interfaz externo que presenta un objeto es el conjunto de
mensajes al que responde, es posible modificar la definicin de mtodos y variables sin
afectar otros objetos. Tambin es posible sustituir una variable por un mtodo que calcule
un valor. Por ejemplo, un objeto de documento puede contener una variable de tamao que
contenga el numero de bytes de texto en el documento o bien un mtodo de tamao que
calcule el tamao del documento leyendo el documento y contando el numero de bytes.

La capacidad de modificar la definicin de un objeto sin afectar al resto del sistema
est considerada como una de las mayores ventajas del modelo de programacin orientado
a objetos.

1.3 Jerarqua de Clases

Normalmente en una base de dato existen muchos objetos similares. Por similar
queremos decir que responden a los mismos mensajes, utilizan los mismos mtodos y

3443
tienen variables del mismo nombre y tipo. Sera un trabajo intil definir cada uno de estos
objetos por separado. Por tanto, agrupamos los objetos similares para que formen una clase.
A cada uno de estos objetos se les llama instancias de su clase. Todos los objetos de una
clase comparten una definicin comn. Aunque difieran en los valores asignados a las
variables. Ejemplo de clases en las bases de datos del banco son los clientes, las cuentas y
los prstamos.

El concepto de clases es similar al concepto de tipos abstractos de datos. Sin
embargo, en el concepto de clase existen varios aspectos adicionales ms all de los de los
tipos abstractos de datos. Para representar estas propiedades adicionales, tratamos cada
clase como si fuera un objeto. Un objeto clase incluye:
Una variable con valores es un conjunto cuyo valor es el conjunto de todos los objetos
que son instancias de la clase.
Implementacin de un mtodo para el nuevo mensaje, el cual crea una nueva instancia
de la clase.

Un esquema de base de datos orientada a objetos normalmente requiere un gran
nmero de clases. Sin embargo, a menudo se da el caso de que varias clases son similares.
Por ejemplo, supngase que tenemos una base orientada a objetos para la aplicacin
bancaria. Sera de esperar que la clase de cliente del banco fuera similar a la clase de
empleados del banco en la definicin de variables de nombre, direccin, nmero de
telfono, etc. Sin embargo existen variables especificas para los empleados (por ejemplo
tasa-crdito). Sera deseable definir una representacin para las variables comunes en un
sitio. Esto puede hacerse slo si los empleados y los clientes estn combinados en una
clase.

3443

Para permitir la representacin directa de similaridades entre clases necesitamos
colocar clases en una jerarqua de especializacin como la que se defini en el modelo de
datos Entidad - Relacin. Los empleados y los clientes pueden representarse por clases que
son especializaciones de una clase Persona. Las variables y los mtodos especficos de los
empleados se asocian a la clase Empleado. Las variables y los mtodos especficos de los
clientes se asocian a la clase Cliente. Las variables y los mtodos que se aplican tanto a los
empleados como a los clientes se asocian a la clase Persona. La siguiente figura muestra
una jerarqua de clases que representan personas implicadas en la operacin del ejemplo
bancario. Las variables asociadas a cada clase del ejemplo son:

Persona: numero-seguridad-social, nombre, direccin, numero-telfono-particular,
fecha-de-nacimiento.
Cliente: tasa-de-crdito, estado-retencin-impuestos, numero-de-telfono-trabajo.
Empleado: fecha-de-contrato, salario, numero-de-dependientes.
Director: titulo, numero-despacho, numero-cuenta-de-gastos

Persona
Empleado
Cliente
Director Cajero Secretaria

3443

Por brevedad no presentamos los mtodos asociados a estas clases, aunque estaran
incluidos en la definicin completa de la base de datos bancaria.

Un objeto que representa a un director contiene todas las variables de la clase
Director, Empleado y Persona. Esto se refiere a la herencia de las propiedades de una clase
ms general. Los mtodos se heredan de manera idntica a la herencia de las variables. Las
especializaciones de una clase se denominan subclases. As, por ejemplo, Empleado es una
subclase de Persona; Cajero es una subclase de Empleado. A la inversa, Empleado es una
superclase de Cajero y Persona es una superclase de Empleado.

Anteriormente observamos que cada clase es ella misma un objeto y que ese objeto
incluye una variable que contiene el conjunto de todas las instancias de la clase. Es fcil
determinar qu objetos estn asociados a clases en las hojas de jerarqua. Por ejemplo,
asociamos a la clase Cliente, el conjunto de todos los clientes del banco. Sin embargo, para
las clases que no son hojas, la cuestin es ms complicada. En la figura anterior hay dos
posibles formas de asociar objetos a clases.

Podramos asociar a la clase Empleado todos los objetos de empleado,
incluyendo aquellos que sean instancias de Director, Cajero y Secretaria.
Podramos asociar a la clase Empleado solamente aquellos objetos de empleado
que no sean instancias de Director, ni de Cajero, ni de Secretaria.

3443
Normalmente, en sistemas orientados a objetos se elige la ltima forma. Es posible
determinar el conjunto de todos los objetos de empleado en este caso tomando la unin de
aquellos objetos asociados a todas las clases en el subrbol con raz en Empleado.

Como observamos anteriormente, la jerarqua de clase/subclase es similar al
concepto de especializacin en el modelo entidad relacin. Decimos que Cajero es una
especializacin de Empleado porque el conjunto de todos los cajeros es un subconjunto de
todos los empleados. Es decir, cada cajero es un empleado.

La especializacin permite la posibilidad de que un empleado no sea un cajero, una
secretaria, ni un director. Una forma alternativa de la relacin es el concepto de
generalizacin. En el modelo entidad - relacin, la generalizacin es el resultado de tomar
la unin de dos o ms conjunto de entidades (de nivel bajo) para producir un conjunto de
entidades de nivel alto. Si aplicamos el concepto de generalizacin al modelo orientado a
objetos, cada objeto debe ser una instancia de una clase hoja en la jerarqua. Esto requerira
la definicin de una subclase de Empleado llamada Otro-Empleado para representar
empleados que no fueran cajeros, secretarias ni directores.

En la mayora de los sistemas orientados a objetos suelen tener implcita la
especializacin en vez de la generalizacin. As, en lo que sigue, supondremos que la
jerarqua de clase/subclase est basada en la especializacin.

3443
1.4 Herencia Mltiple

En la mayora de los casos, una organizacin jerrquica de clases es la adecuada
para describir aplicaciones. En tales casos, todas las superclases de una clase son
antepasados de otra en la jerarqua. Sin embargo, existen situaciones que no pueden
representarse bien en una jerarqua de clases.

Supngase que queremos distinguir entre cajeros y secretarias a tiempo completo y
a tiempos partidos en el ejemplo de la figura ya mencionada. Adems supngase que
necesitamos variables y mtodos diferentes para representar estos dos tipos de empleados.
Podemos crear las subclases: Cajero-tiempo-partido, Cajero-tiempo-completo, Secretaria-
tiempo-partido, Secretaria-tiempo-completo. La jerarqua resultante que se muestra a
continuacin no proporciona un buen modelo de la empresa bancaria por varias razones:

Persona
Empleado
Cliente
Cajero a tiempo
completo
Cajero a tiempo
Partido
Secretaria a
Tiempo
Completo
Secretaria a
Tiempo
Partido

3443

Como observamos anteriormente, existen ciertas variables y mtodos especficos de los
empleados a tiempo completos y otros especficos de los de tiempo partido. En la figura
anterior las variables y los mtodos para los empleados a tiempo completo deben estar
definidas dos veces, una para Secretaria-tiempo-completo y otra para Cajero-tiempo-
completo. Para los empleados a tiempo partidos existe una redundancia parecida. Esta
redundancia no es deseable, ya que cada cambio de las propiedades de los empleados a
tiempo completo o partido debe hacerse en dos sitios, lo que puede conducir a
inconsistencias.
La jerarqua no tiene forma de representar empleados que no sean cajeros ni secretarias,
a menos que la ampliemos de manera que incluya las clases Empleado-tiempo-completo
y empleados-tiempo-partido.

Si tuviramos varias clasificaciones de trabajo en vez de las dos de este ejemplo
sencillo, las limitaciones del modelo llegaran a ser ms aparentes.

El concepto de Herencia Mltiple trata los problemas que acabamos de observar en
el modelo orientado a objetos; este concepto de refiere a la capacidad de las clases para
heredar variables y mtodos de mltiples superclases. La relacin clase/subclase se
representa por un grafo con raz aciclica dirigido (DAG) en el que una clase puede tener
ms de una superclase. Volvamos al ejemplo bancario. Utilizando un DAG podemos definir
propiedades de empleo a tiempo completo y a tiempo partido en un sitio. Como se muestra
en la siguiente figura. Definimos una clase Tiempo-partido que define aquellas variables y
mtodos especficos del empleo a tiempo partido y una clase Tiempo-completo que define
aquellas variables y mtodos especficos del empleo a tiempo completo.

3443

Utilizando DAG en la figura mencionada, podemos representar los empleados a
tiempo completo y a tiempo partido que no son cajeros ni secretarias como instancias de las
clases Tiempo-completo y Tiempo-partido, respectivamente.

Cuando se emplea la herencia mltiple es posible que se d ambigedad en el caso
en que pueda heredarse la misma variable o mtodo de ms de una superclase. En el
ejemplo bancario, supngase que en vez de definir salario para la clase Empleado,
definimos una variable pago para cada una de las clases Tiempo-completo, Tiempo-
partido, Cajero y Secretaria como sigue:

Tiempo-completo: pago es un entero de 0 a 100 000 que contiene el salario anual.
Persona
Empleado
Cliente
Cajero a tiempo
completo
Cajero a tiempo
Partido
Secretaria a
Tiempo
Completo
Secretaria a
Tiempo
Partido

3443
Tiempo-partido: pago es un entero de 0 a 20 que contiene una fraccin de pago por
hora.
Cajero: pago es un entero de 0 a 20 000 que contiene el salario anual.
Secretaria: pago es un entero entre 0 a 25 000 que contiene el salario anual.

Considrese la clase Secretaria-tiempo-partido. Podra heredar la definicin de
pago de Tiempo-partido o de Secretaria. El resultado es diferente, dependiendo de la
eleccin que se haga. Entre las opciones que pueden elegir las diversas implementaciones
del modelo orientado a objetos estn las siguientes:
Incluir las dos variables, renombrarlas como Tiempo-partido. pago y Secretaria. pago.
Elegir una u otra basndose en el orden en el que se crearon las clases Tiempo-partido
y Secretaria.
Obligar al usuario a que haga la eleccin en el momento en que se define la clase
secretaria-tiempo-partido.

No se ha aceptado ninguna solucin simple como la mejor. Cabe mencionar que no
todos los casos de herencia mltiple conducen a ambigedad. Si en vez de definir pago,
conservamos la definicin de la variable salario en la clase empleado, y no la definicin de
la variable salario en la clase Empleado, y no la definicin en ningn otro sitio, entonces
las clases Tiempo-partido, Tiempo-completo, Secretaria Tiempo-partido, Tiempo-completo,
Secretaria y Cajero heredan todas salario de Empleado. Puesto que las cuatro clases
comparten la misma definicin de salario, no resulta ninguna ambigedad cuando la
Secretaria-tiempo-partido, Secretaria-tiempo-completo, etc., heredan salario.

1.5 Identidad de objetos

3443

Los objetos en una base de datos orientada a objetos, normalmente corresponden a
una entidad de la empresa que est modelando la base de datos. Una entidad conserva su
identidad aun cuando algunas de sus propiedades cambien con el tiempo. Igualmente, un
objeto conserva su identidad aun cuando algunos o todos los valores de las variables o las
definiciones de los mtodos cambien con el tiempo. Este concepto de identidad no se aplica
a las tuplas de una base de datos relacional. En los sistemas relacionales, las tuplas de una
relacin se distinguen nicamente por los valores que contienen.

La identidad del objeto es una nocin mas fuerte que la que se encuentra
normalmente en los lenguajes de programacin o en los modelos de datos que no estn
basados en la orientacin a objetos. A continuacin ilustramos varias formas de identidad.
Valor Se utiliza un valor de dato por identidad. Esta es la forma de identidad que se usa
en los sistemas relacionales.
Nombre Se utiliza un nombre facilitado por el usuario por identidad. Esta es la forma de
identidad que normalmente se usa para las variables en los procedimientos. A cada
variable se le da un nombre que identifica de manera nica a la variable sin importar el
valor que contenga.
Incorporacin Una nocin de identidad es incorporar en el modelo de datos el lenguaje
de programacin, y no se requiere que el usuario proporcione ningn identificador. Esta
es la forma de identidad que se usa en los sistemas orientados a objetos.

Un tema relacionado con el tipo de identidad es la permanencia de identidad. Una
forma sencilla de lograr incorporar la identidad es por medio de punteros a localizaciones
en memoria. Sin embargo, la asociacin de un objeto a una localizacin fsica en memoria

3443
puede cambiar con el tiempo. A continuacin listamos varios grados de permanencia de
identidad.
Intraprograma. La identidad permanece solamente durante la ejecucin de un nico
programa o consulta. Ejemplo de identidad de interprograma son los nombres de la
variable en los lenguajes de programacin y los identificadores de tuplas en SQL.
Interprograma. La identidad permanece de una ejecucin del programa a otra.
Ejemplos de identidad de interprograma son los nombres de relaciones en un lenguaje
de consulta relacional del tipo del SQL.
Persistente. La identidad permanente no slo entre las operaciones del programa sino
tambin entre las reorganizaciones estructurales de los datos. Las relaciones en SQL no
tienen identidad persistente, ya que una reorganizacin de la base de datos puede
resultar en un nuevo esquema de bases de datos con relaciones con nuevos nombres. La
forma persistente de identidad es la que se requiere en los sistemas orientados a objetos.

Estas formas de identidad sirven para distinguir entre identidad en sistemas
orientados a objetos y punteros en organizacin fsica de datos. Los punteros de la memoria
principal o de la memoria virtual solamente ofrecen identidad de Intraprograma. Los
punteros a datos de un sistema de archivos en disco solamente ofrecen identidad de
interprograma. As, la identidad de objetos es decir, la identidad persistente es una nocin
ms fuerte que la que proporcionan los punteros.

3443
1.6 Contenido de Objetos

Anteriormente observamos que el valor de una variable de un objeto es ella misma
un objeto. Esto crea una jerarqua de contenido entre los objetos. Un objeto O
2
es el hijo de
un objeto O
1
y si O
1
contiene O
2
; es decir, O
2
es el valor de una variable de O
1
. Los objetos
que contienen otros objetos se denominan objetos complejos o compuestos.

Para ilustrar el contenido considrese la base de datos simplificada de diseo de
sistemas de computadoras de la siguiente figura. La base de datos contiene informacin en
varios sistemas de computadoras. Cada sistema de computadoras contiene un conjunto de
tarjetas, un conjunto de buses, un conjunto de dispositivos y un conjunto de chips y los
buses proporcionan un conjunto de interfaces.

La jerarqua de la figura muestra la relacin de contenido entre los objetos de una
forma esquemtica listando los nombres de las clases en vez de los objetos individuales.
Considrese la clase Sistema-computadores. Puede incluir las variables nombre-
computador, id-proyecto, gestor, fecha-terminacin, las cuales contienen datos descriptivos
Sistema de computadoras
Tarjeta Bus Dispositivo
Conjunto
Instrucciones
Chips Interfaces

3443
acerca de una instancia de la clase. Aunque los valores de estas variables se consideran
objetos, son instancias de tipos de datos estndar (como cadenas de caracteres) que se han
implementado directamente a un nivel bajo por razones de rendimiento. La clase Sistema-
computadores tambin incluyen las variables tarjeta, bus, dispositivo y conjunto-
instrucciones. Estas variables toman como valores conjuntos de objetos de las clases
Tarjeta, Bus, Dispositivo y Conjunto-instrucciones, respectivamente.

En determinadas aplicaciones, un objeto puede estar contenido en varios objetos. En
tales casos, la relacin de contenido se representa por un DAG en vez de mediante una
jerarqua.

El contenido es un concepto importante en los sistemas orientados a objetos porque
permite que distintos usuarios vean los datos en diferentes granularidades.

1.7 Organizacin Fsica

La estructura de las bases de datos orientadas a objetos no presenta la uniformidad
de las bases de datos relacionales. Para construir una estructura fcil de mantener,
comnmente los objetos se representan as:
Determinadas clases se tratan como clases bsicas de bloques que se construyen, que el
sistema de computadoras implementa directamente. Comnmente, las clases bsicas
corresponden a tipos de datos de lenguajes de programacin estndar, tales como
entero, flotante, carcter y cadena.
Las instancias de clases que no son bsicas se representan as:

3443
Las variables se representan por campos de un tipo de registro. Cada campo
contiene el valor del objeto para instancias de las clases bsicas, o bien el
identificador del objeto por instancias de las clases que no sean bsicas.
Las variables con un conjunto de valores se representan por una lista enlazada de los
objetos que son miembros del conjunto.

La estructura fsica hace que sea posible utilizar registros de longitud fija para
implementar una base de datos orientada a objetos, aunque la modificacin del esquema
puede complicar esto.

No todas las variables encajan convenientemente en la estructura que hemos
descrito arriba. Algunas de las aplicaciones que se citaron al inicio de este tema incluyen
tipos de datos altamente especializados que son grandes fsicamente y que, por razones
prcticas, normalmente se manipulan mediante programas de aplicaciones que no son parte
del conjunto de mtodos con las clases:

Datos de texto. El texto, normalmente se trata como una cadena de bytes que manipulan
los editores y los formateadores.
Datos de Audio. Comnmente, los datos de audio son una representacin comprimida
digitalizada del habla que manejan aplicaciones software separada.
Datos de vdeo y grficas. Los datos de vdeo pueden representarse como un mapa de
bytes o como un conjunto de lneas, cajas y otros objetos geomtricos. Aunque algunos
datos grficos a menudo se gestionan dentro del sistema de base de datos, en muchos
casos se utilizan aplicaciones software especial. Un ejemplo de los ltimos es un diseo
VLSI.

3443

1.8 Consultas orientadas a objetos

Los lenguajes de programacin orientados a objetos requieren que toda la interaccin con
objetos mediante envi de mensajes. Esto presenta serias limitaciones en las aplicaciones
de bases de datos. Por tal motivo, debe incluir tanto el modelo de pasar el mensaje de
objeto en objeto (un objeto cada vez) como el modelo de pasar el mensaje de conjunto en
conjunto (un conjunto cada vez). La mezcla del proceso con los dos modelos conocido
como impedancia desajustada. Existen varios lenguajes propuestos. Como actualmente
no est surgiendo estndares claros, no presentamos aqu lenguajes especficos, pero en las
notas bibliogrficas se proporcionan algunos.

3443

BASE DE DATOS DISTRIBUIDAS

2.1 Introduccin a las Bases de Datos Distribuidas

En un sistema de bases de datos distribuidas, los datos se almacenan en varios
computadores. Los computadores de un sistema distribuido se comunican entre s a travs
de diversos medios de comunicacin, tales como cables de alta velocidad o lneas
telefnicas. No comparten la memoria principal ni el reloj.

Los procesadores de un sistema distribuido pueden variar en cuanto su tamao y
funcin. Pueden incluir microcomputadores pequeos, estaciones de trabajo,
minicomputadores y sistema de computadores grandes de aplicacin general. Estos
procesadores reciben diferentes nombres, tales como localidades, nodos, computadores,
dependiendo en el contexto donde se mencionen. Nosotros utilizaremos normalmente el
trmino localidad para hacer hincapi en la distribucin fsica de estos sistemas.

Un sistema distribuido de bases de datos consiste en un conjunto de localidades,
cada una de las cuales puede participar en la ejecucin de transacciones que accedan a
datos de una o varias localidades. La diferencia principal entre los sistemas de bases de
datos centralizados y distribuidos es, que en los primeros, los datos residen en una sola
localidad, mientras que en los ltimos, se encuentran en varias localidades. Esta
distribucin de los datos es la causa de muchos problemas que se trataran ms adelante.

3443

2.2 Estructura de Bases de Datos Distribuidas

Un sistema de base de datos consiste en un conjunto de localidades, cada una de las
cuales mantiene un sistema de base de datos local. Cada localidad puede procesar
transacciones locales, es decir, aquellas que slo acceden a datos que residen en esa
localidad. Adems, una localidad puede participar en la ejecucin de transacciones
globales, es decir, aquellas que acceden a datos de varias localidades. La ejecucin de
transacciones globales requiere comunicacin entre las localidades.

Las localidades en el sistema pueden conectarse fsicamente de diversas formas. Las
distintas configuraciones se representan por medio de grafos cuyos nodos corresponden a
las localidades. Una arista del nodo A al nodo B corresponde a una conexin directa entre
las dos localidades. En la siguiente figura se ilustran algunas de las configuraciones ms
comunes. Las diferencias principales entre estas configuraciones son:

Costes de instalacin. El coste de conectar fsicamente las localidades del sistema.
Coste de comunicacin. El coste en tiempo y dinero que implica enviar un mensaje
desde la localidad A hacia la B.
Fiabilidad. La frecuencia con que falla una lnea de comunicacin o una localidad.
Disponibilidad La posibilidad de acceder a informacin a pesar de fallos en algunas
localidades o lneas de comunicacin.

3443

A B
C
D E
F
Red totalmente conectada
A
C B
D E F
Red parcialmente conectada
A
E B
F
C D
Red con estructura de rbol
C
A
B
F
E
D
Red de estrella
A B
C
D E
F
Red de Anillo

3443

Las localidades pueden estar dispersas, ya sea por un rea geogrfica extensa (a lo
largo de un pas), llamadas redes de larga distancia; o en un rea reducida (en un mismo
edificio), llamadas redes de rea local. Para las primeras se utilizan en la comunicacin
lneas telefnicas, conexiones de microondas y canales de satlites; mientras que para las
segundas se utiliza cables coaxiales de banda base o banda ancha y fibra ptica.

2.3 Consideraciones al distribuir la base de datos

Existen varias razones para construir sistemas distribuidos de bases de datos que
incluyen compartir la informacin, fiabilidad y disponibilidad y agilizar el procesamiento
de las consultas. Pero tambin tiene sus desventajas, como desarrollo de software ms
costoso, mayor posibilidad de errores y costos extras de procesamiento.

Ventajas de la distribucin de datos

La principal ventaja de los sistemas distribuidos es la capacidad de compartir y
acceder a la informacin de una forma fiable y eficaz.

Utilizacin compartida de los datos y distribucin del control

La ventaja principal de compartir los datos por medio de la distribucin es que cada
localidad pueda controlar hasta cierto punto los datos almacenados localmente. En un
sistema centralizado, el administrador de base de datos de la localidad central controla la
base de datos. En un sistema distribuido existe un administrador global de la base de dato s

3443
que se encarga de todo el sistema. Parte de esta responsabilidad se delega al administrador
de base de datos de cada localidad. Dependiendo del diseo del sistema distribuido, cada
administrador local podr tener un grado de autonoma diferente, que se conoce como
autonoma local. La posibilidad de contar con autonoma local es en muchos casos una
ventaja importante de las bases de datos distribuidas.

Fiabilidad y disponibilidad

Si se produce un fallo en una localidad de un sistema distribuido, es posible que las
dems localidades puedan seguir trabajando. En particular, si los datos se repiten en varias
localidades, una transaccin que requiere un dato especfico puede encontrarlo en ms de
una localidad. As, el fallo de una localidad no implica necesariamente la desactivacin del
sistema.

El sistema debe detectar cuando falla una localidad y tomar las medidas necesarias
para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que fall. Por
ltimo, cuando se recupere o repare esta localidad, debe contarse con mecanismos para
reintegrarla al sistema con el mnimo de complicaciones.
La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en
aplicaciones de tiempo real. Por ejemplo, si una lnea area no puede tener acceso a la
informacin, es posible que pierda clientes a favor de la competencia.

3443

Agilizacin del procesamiento de consultas

Si una consulta comprende datos de varias localidades, puede ser posible dividir la
consulta en varias subconsultas que se ejecuten en paralelo en distintas localidades. Sin
embargo, en un sistema distribuido no se comparte la memoria principal, as que no todas
las estrategias de interseccin se pueden aplicar en estos sistemas. En los casos en que hay
repeticin de los datos, el sistema puede pasar la consulta a las localidades ms ligeras de
carga.

Desventajas de la distribucin de los datos

La desventaja principal de los sistemas distribuidos es la mayor complejidad que se
requiere para garantizar una coordinacin adecuada entre localidades.
El aumento de la complejidad se refleja en:

Coste del desarrollo de software: es ms difcil estructura un sistema de
bases de datos distribuidos y por tanto su coste es mayor.

Mayor posibilidad de errores: puesto que las localidades del sistema
distribuido operan en paralelo, es ms difcil garantizar que los algoritmos
sean correctos.

3443
Mayor tiempo extra de procesamiento: el intercambio de mensajes y los
clculos adicionales son una forma de tiempo extra que no existe en los
sistemas centralizados.

Transparencia y Autonoma

En la seccin anterior se vio que una relacin r puede almacenarse de varias formas
en un sistema de base de datos distribuida. Es esencial que el sistema reduzca al mnimo la
necesidad de que el usuario se d cuenta de cmo est almacenada una relacin. Como
veremos. Un sistema puede ocultar los detalles de la distribucin de la informacin en la
red. Esto se denomina transparencia de la red. La transparencia de la red se relaciona, en
algn modo, a la autonoma local. La transparencia de la red es el grado hasta el cual los
usuarios del sistema pueden ignorar los detalles del diseo distribuido. La autonoma local
es el grado hasta el cual el diseador o administrador de una localidad pueden ser
independientes del resto del sistema distribuido. Los temas de transparencia y autonoma
sern considerados desde los siguientes puntos de vista:
Nombre de los datos.
Repeticin de los datos.
Fragmentacin de los datos.
Localizacin de los fragmentos y copias.

3443
Asignacin de nombres y autonoma local

Todo elemento de informacin de una base de datos debe tener un nombre nico.
Esta propiedad se asegura fcilmente en una base de datos que no est distribuida. Sin
embargo, en una base de dalos distribuida, las distintas localidades deben asegurarse de no
utilizar el mismo nombre para dos datos diferentes.

Una solucin para este problema es requerir que se registren todos los nombres en
un asignador central de nombres. Sin embargo, este enfoque tiene varias desventajas:
Es posible que el asignador de nombres se convierta en un cuello de botella;
Si el asignador de nombres se cae, es posible que ninguna de las localidades del
sistema distribuido pueda seguir trabajando;
Se reduce la autonoma local, ya que la asignacin de nombres se controla de forma
centralizada.

Un enfoque diferente que origina una mayor autonoma local es exigir que cada
localidad ponga como prefijo un identificador de localidad a cualquier nombre que genere.
Esto garantiza que dos localidades nunca generarn el mismo nombre (ya que cada
localidad tiene un identificador nico). Adems, no se requiere un control central.

Esta solucin al problema de asignacin de nombres, logra autonoma local, pero no
transparencia de la red, ya que se agregan identificadores de localidad a los nombres. As,
la relacin depsito podra llamarse localidad17.depsito en vez de depsito simplemente.

3443
Cada copia y fragmento de un elemento de informacin deben tener un nombre
nico. Es importante que el sistema pueda determinar qu copias son copias del mismo
elemento de informacin y qu fragmentos son fragmentos del mismo elemento de
informacin.

Transparencia de la repeticin y la fragmentacin

No es conveniente requerir que los usuarios hagan referencia a una copia especfica
de un elemento de informacin. El sistema debe ser el que determine a qu copia debe
acceder cuando se le solicite su lectura, y debe modificar todas las copias cuando se
produzca una peticin de escritura.

Cuando se solicita un dato, no es necesario especificar la copia. El sistema utiliza
una tabla-catlogo para determinar cules son todas las copias de ese dato.

De manera similar, no debe exigirse a los usuarios que sepan cmo est
fragmentado un elemento de informacin. Es posible que los fragmentos verticales
contengan id-tuplas, que representan direcciones de tuplas. Los fragmentos horizontales
pueden haberse obtenido por predicados de seleccin complejos. Por tanto, un sistema de
bases de datos distribuido debe permitir las consultas que se hagan en trminos de
elementos de informacin sin fragmentar. Esto no presenta problemas graves, ya que
siempre es posible reconstruir el elemento de informacin original a partir de sus
fragmentos. Sin embargo, este proceso puede ser ineficiente.

3443

Transparencia de localizacin

Si el sistema es transparente en cuanto a repeticin y fragmentacin, se ocultar al
usuario gran parte del esquema de la base de datos distribuida. Sin embargo, el componente
de los nombres que identifican a la localidad obliga al usuario a darse cuenta del hecho de
que el sistema est distribuido.

La transparencia de localizacin se logra creando un conjunto de seudnimos o alias
para cada usuario. As, el usuario puede referirse a los datos usando nombres sencillos que
el sistema traduce a nombres completos.

Con el uso de seudnimos, no ser necesario que el usuario conozca la localizacin
fsica de un dato. Adems, el administrador de la base de datos puede cambiar un dato de
una localidad a otra sin afectar a los usuarios.

Esquema completo de asignacin de nombres

Ya vimos que un nombre proporcionado por el usuario debe pasar por varios pasos
de traduccin antes de que pueda servir como referencia a una copia especfica de un
fragmento determinado en una localidad especfica.

3443
Transparencia y actualizaciones

De alguna forma es ms difcil hacer transparente la base de datos para usuarios que
la actualizan que para aquellos que slo leen datos. El problema principal es asegurarse de
que se actualizan todas las copias de un dato y tambin los fragmentos afectados.

En el caso ms general, el problema de actualizacin de informacin repetida y
fragmentada est relacionado con el problema de actualizacin de vistas.

2.5 Diseo de la Bases de datos Distribuidas

El diseo de un sistema de base de datos distribuido implica la toma de decisiones
sobre la ubicacin de los programas que accedern a la base de datos y sobre los propios
datos que constituyen esta ltima, a lo largo de los diferentes puestos que configuren una
red de ordenadores. La ubicacin de los programas, a priori, no debera suponer un
excesivo problema dado que se puede tener una copia de ellos en cada mquina de la red
(de hecho, en este documento se asumir que as es). Sin embargo, cul es la mejor opcin
para colocar los datos: en una gran mquina que albergue a todos ellos, encargada de
responder a todas las peticiones del resto de las estaciones - sistema de base de datos
centralizado -, o podramos pensar en repartir las relaciones, las tablas, por toda la red. En
el supuesto que nos decantsemos por esta segunda opcin, qu criterios se deberan
seguir para llevar a cabo tal distribucin? Realmente este enfoque ofrecer un mayor
rendimiento que el caso centralizado? Podra optarse por alguna otra alternativa? En los
prrafos sucesivos se tratar de responder a estas cuestiones.

3443
Tradicionalmente se ha clasificado la organizacin de los sistemas de bases de datos
distribuidos sobre tres dimensiones: el nivel de comparticin, las caractersticas de acceso a
los datos y el nivel de conocimiento de esas caractersticas de acceso (vea la figura 1). El
nivel de comparticin presenta tres alternativas: inexistencia, es decir, cada aplicacin y sus
datos se ejecutan en un ordenador con ausencia total de comunicacin con otros programas
u otros datos; se comparten slo los datos y no los programas, en tal caso existe una rplica
de las aplicaciones en cada mquina y los datos viajan por la red; y, se reparten datos y
programas, dado un programa ubicado en un determinado sitio, ste puede solicitar un
servicio a otro programa localizado en un segundo lugar, el cual podr acceder a los datos
situados en un tercer emplazamiento. Como se coment lneas atrs, en este caso se optar
por el punto intermedio de comparticin.

Respecto a las caractersticas de acceso a los datos existen dos alternativas
principalmente: el modo de acceso a los datos que solicitan los usuarios puede ser esttico,
es decir, no cambiar a lo largo del tiempo, o bien, dinmico. El lector podr comprender
fcilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse
como estticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo
como base, cmo de dinmico es, cuntas variaciones sufre a lo largo del tiempo. Esta
dimensin establece la relacin entre el diseo de bases de datos distribuidas y el
procesamiento de consultas.

La tercera clasificacin es el nivel de conocimiento de las caractersticas de acceso.
Una posibilidad es, evidentemente, que los diseadores carezcan de informacin alguna
sobre cmo los usuarios acceden a la base de datos. Es una posibilidad terica, pero sera
muy laborioso abordar el diseo de la base de datos con tal ausencia de informacin. Lo

3443
ms prctico sera conocer con detenimiento la forma de acceso de los usuarios o, en el
caso de su imposibilidad, conformarnos con una informacin parcial de sta.

El problema del diseo de bases de datos distribuidas podra enfocarse a travs de
esta trama de opciones. En todos los casos, excepto aquel en el que no existe comparticin,
aparecern una serie de nuevos problemas que son irrelevantes en el caso centralizado.

A la hora de abordar el diseo de una base de datos distribuida podremos optar
principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia
descendente. Ambos tipos no son excluyentes, y no resultara extrao a la hora de abordar
un trabajo real de diseo de una base de datos que se pudiesen emplear en diferentes etapas
del proyecto una u otra estrategia. La estrategia ascendente podra aplicarse en aquel caso
donde haya que proceder a un diseo a partir de un nmero de pequeas bases de datos
existentes, con el fin de integrarlas en una sola. En este caso se partira de los esquemas
conceptuales locales y se trabajara para llegar a conseguir el esquema conceptual global.

Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere pensar
en el caso donde se parte de cero y se avanza en el desarrollo del trabajo siguiendo la
estrategia descendente. La estrategia descendente debera resultar familiar a la persona que
posea conocimientos sobre el diseo de bases de datos, exceptuando la fase del diseo de la
distribucin. Pese a todo, se resumirn brevemente las etapas por las que se transcurre.

Todo comienza con un anlisis de los requisitos que definirn el entorno del sistema
en aras a obtener tanto los datos como las necesidades de procesamiento de todos los
posibles usuarios del banco de datos. Igualmente, se debern fijar los requisitos del sistema,

3443
los objetivos que debe cumplir respecto a unos grados de rendimiento, seguridad,
disponibilidad y flexibilidad, sin olvidar el importante aspecto econmico. Como puede
observarse, los resultados de este ltimo paso sirven de entrada para dos actividades que se
realizan de forma paralela. El diseo de las vistas trata de definir las interfaces para el
usuario final y, por otro lado, el diseo conceptual se encarga de examinar la empresa para
determinar los tipos de entidades y establecer la relacin entre ellas. Existe un vnculo entre
el diseo de las vistas y el diseo conceptual.

El diseo conceptual puede interpretarse como la integracin de las vistas del
usuario, este aspecto es de vital importancia ya que el modelo conceptual debera soportar
no slo las aplicaciones existentes, sino que debera estar preparado para futuras
aplicaciones. En el diseo conceptual y de las vistas del usuario se especificarn las
entidades de datos y se determinarn las aplicaciones que funcionarn sobre la base de
datos, as mismo, se recopilarn datos estadsticos o estimaciones sobre la actividad de
estas aplicaciones. Dichas estimaciones deberan girar en torno a la frecuencia de acceso,
por parte de una aplicacin, a las distintas relaciones de las que hace uso, podra afinarse
ms anotando los atributos de la relacin a la que accede. Desarrollado el trabajo hasta
aqu, se puede abordar la confeccin del esquema conceptual global.

Este esquema y la informacin relativa al acceso a los datos sirven de entrada al
paso distintivo: el diseo de la distribucin. El objetivo de esta etapa consiste en disear los
esquemas conceptuales locales que se distribuirn a lo largo de todos los puestos del
sistema distribuido. Sera posible tratar cada entidad como una unidad de distribucin; en el
caso del modelo relacional, cada entidad se corresponde con una relacin. Resulta bastante

3443
frecuente dividir cada relacin en subrelaciones menores denominadas fragmentos que
luego se ubican en uno u otro sitio.

De ah, que el proceso del diseo de la distribucin conste de dos actividades
fundamentales: la fragmentacin y la asignacin. El ltimo paso del diseo de la
distribucin es el diseo fsico, el cual proyecta los esquemas conceptuales locales sobre los
dispositivos de almacenamiento fsico disponibles en los distintos sitios. Las entradas para
este paso son los esquemas conceptuales locales y la informacin de acceso a los
fragmentos.

Por ltimo, se sabe que la actividad de desarrollo y diseo es un tipo de proceso que
necesita de una monitorizacin y un ajuste peridicos, para que si se llegan a producir
desviaciones, se pueda retornar a alguna de las fases anteriores.

Diseo

Antes de exponer las alternativas existentes de fragmentacin, se desean presentar
las ventajas e inconvenientes de esta tcnica. Se ha comentado en la introduccin la
conveniencia de descomponer las relaciones de la base de datos en pequeos fragmentos,
pero no se ha justificado el hecho ni se han aportado razones para efectuarlo. Por ello,
desde este punto se va a intentar aportar las razones necesarias para llevar a cabo esa
descomposicin, esa fragmentacin.

El principal problema de la fragmentacin radica en encontrar la unidad apropiada
de distribucin. Una relacin no es una buena unidad por muchas razones. Primero, las

3443
vistas de la aplicacin normalmente son subconjuntos de relaciones. Adems, la localidad
de los accesos de las aplicaciones no est definida sobre relaciones enteras pero s sobre
subconjuntos de las mismas. Por ello, sera normal considerar como unidad de distribucin
a estos subconjuntos de relaciones.

Segundo, si las aplicaciones tienen vistas definidas sobre una determinada relacin
(considerndola ahora una unidad de distribucin) que reside en varios sitios de la red, se
puede optar por dos alternativas. Por un lado, la relacin no estar replicada y se almacena
en un nico sitio, o existe rplica en todos o algunos de los sitios en los cuales reside la
aplicacin. Las consecuencias de esta estrategia son la generacin de un volumen de
accesos remotos innecesario. Adems, se pueden realizar rplicas innecesarias que causen
problemas en la ejecucin de las actualizaciones y puede no ser deseable si el espacio de
almacenamiento est limitado.

Tercero, la descomposicin de una relacin en fragmentos, tratados cada uno de
ellos como una unidad de distribucin, permite el proceso concurrente de las transacciones.
Tambin la relacin de estas relaciones, normalmente, provocar la ejecucin
paralela de una consulta al dividirla en una serie de subconsultas que operar sobre los
fragmentos.

Pero la fragmentacin tambin acarrea inconvenientes. Si las aplicaciones tienen
requisitos tales que prevengan la descomposicin de la relacin en fragmentos mutuamente
exclusivos, estas aplicaciones cuyas vistas estn definidas sobre ms de un fragmento
pueden sufrir una degradacin en el rendimiento. Por tanto, puede ser necesario recuperar

3443
los datos de dos fragmentos y llevar a cabo sobre ellos operacin de unin y punto , lo cual
es costoso.

Un segundo problema se refiere al control semntico. Como resultado de la
fragmentacin los atributos implicados en una dependencia se descomponen en diferentes
fragmentos los cuales pueden destinarse a sitios diferentes. En este caso, la sencilla tarea de
verificar las dependencias puede resultar una tarea de bsqueda de los datos implicados en
un gran nmero de sitios.

Tipos de fragmentacin

Dado que una relacin se corresponde esencialmente con una tabla y la cuestin
consiste en dividirla en fragmentos menores, inmediatamente surgen dos alternativas
lgicas para llevar a cabo el proceso: la divisin horizontal y la divisin vertical.

La divisin o fragmentacin horizontal trabaja sobre las tuplas, dividiendo la
relacin en subrelaciones que contienen un subconjunto de las tuplas que alberga la
primera.
La fragmentacin vertical, en cambio, se basa en los atributos de la relacin para
efectuar la divisin. Estos dos tipos de particin podran considerarse los fundamentales y
bsicos. Sin embargo, existen otras alternativas.

Fundamentalmente, se habla de fragmentacin mixta o hbrida cuando el proceso de
particin hace uso de los dos tipos anteriores. La fragmentacin mixta puede llevarse a
cabo de tres formas diferentes: desarrollando primero la fragmentacin vertical y,

3443
posteriormente, aplicando la particin horizontal sobre los fragmentos verticales
(denominada particin VH), o aplicando primero una divisin horizontal para luego, sobre
los fragmentos generados, desarrollar una fragmentacin vertical (llamada particin HV), o
bien, de forma directa considerando la semntica de las transacciones.

Otro enfoque distinto y relativamente nuevo, consiste en aplicar sobre una relacin,
de forma simultnea y no secuencial, la fragmentacin horizontal y la fragmentacin
vertical; en este caso, se generara una rejilla y los fragmentos formaran las celdas de esa
rejilla, cada celda ser exactamente un fragmento vertical y un fragmento horizontal (ntese
que en este caso el grado de fragmentacin alcanzado es mximo, y no por ello la
descomposicin resultar ms eficiente).

Grado de fragmentacin.

Cuando se va a fragmentar una base de datos deberamos sopesar qu grado de
fragmentacin va a alcanzar, ya que ste ser un factor que influir notablemente en el
desarrollo de la ejecucin de las consultas. El grado de fragmentacin puede variar desde
una ausencia de la divisin, considerando a las relaciones unidades de fragmentacin; o
bien, fragmentar a un grado en el cada tupla o atributo forme un fragmento. Ante estos dos
casos extremos, evidentemente se ha de buscar un compromiso intermedio, el cual debera
establecerse sobre las caractersticas de las aplicaciones que hacen uso de la base de datos.
Dichas caractersticas se podrn formalizar en una serie de parmetros. De acuerdo con sus
valores, se podr establecer el grado de fragmentacin del banco de datos.

3443

Reglas de correccin de la fragmentacin

A continuacin se enuncian las tres reglas que se han de cumplir durante el proceso
de fragmentacin, las cuales asegurarn la ausencia de cambios semnticos en la base de
datos durante el proceso.

Complecin.- Si una relacin R se descompone en una serie de fragmentos
R1, R2, ..., Rn, cada elemento de datos que pueda encontrarse en R deber
poder encontrarse en uno o varios fragmentos Ri. Esta propiedad
extremadamente importante asegura que los datos de la relacin global se
proyectan sobre los fragmentos sin prdida alguna. Tenga en cuenta que en
el caso horizontal el elemento de datos, normalmente, es una tupla, mientras
que en el caso vertical es un atributo.

Reconstruccin.- Si una relacin R se descompone en una serie de
fragmentos R1, R2, ..., Rn, puede definirse una operador relacional tal que el
operador ser diferente dependiendo de las diferentes formas de
fragmentacin. La reconstruccin de la relacin a partir de sus fragmentos
asegura la preservacin de las restricciones definidas sobre los datos en
forma de dependencias.

Disyuncin.- Si una relacin R se descompone horizontalmente en una serie
de fragmentos R1, R2, ..., Rn, y un elemento de datos di se encuentra en
algn fragmento Rj, entonces no se encuentra en otro fragmento Rk (k j).

3443
Esta regla asegura que los fragmentos horizontales sean disjuntos. Si una
relacin R se descompone verticalmente, sus atributos primarios clave
normalmente se repiten en todos sus fragmentos.

Alternativas de asignacin

Partiendo del supuesto que el banco de datos se haya fragmentado correctamente,
habr que decidir sobre la manera de asignar los fragmentos a los distintos sitios de la red.
Cuando una serie de datos se asignan, stos pueden replicarse para mantener una copia.

Las razones para la rplica giran en torno a la seguridad y a la eficiencia de las
consultas de lectura. Si existen muchas reproducciones de un elemento de datos, en caso de
fallo en el sistema se podra acceder a esos datos ubicados en sitios distintos. Adems, las
consultas que acceden a los mismos datos pueden ejecutarse en paralelo, ya que habr
copias en diferentes sitios. Por otra parte, la ejecucin de consultas de actualizacin, de
escritura, implicara la actualizacin de todas las copias que existan en la red, cuyo proceso
puede resultar problemtico y complicado. Por tanto, un buen parmetro para afrontar el
grado de rplica consistira en sopesar la cantidad de consultas de lectura que se efectuarn,
as como el nmero de consultas de escritura que se llevarn a cabo.

En una red donde las consultas que se procesen sean mayoritariamente de lectura, se
podra alcanzar un alto grado de rplica, no as en el caso contrario. Una base de datos
fragmentada es aquella donde no existe rplica alguna.

3443
Los fragmentos se alojan en sitios donde nicamente existe una copia de cada uno
de ellos a lo largo de toda la red. En caso de rplica, podemos considerar una base de datos
totalmente replicada, donde existe una copia de todo el banco de datos en cada sitio, o
considerar una base de datos parcialmente replicada donde existan copias de los fragmentos
ubicados en diferentes sitios. El nmero de copias de un fragmento ser una de las posibles
entradas a los algoritmos de asignacin, o una variable de decisin cuyo valor lo determine
el algoritmo.

La figura compara las tres alternativas de rplica con respecto a distintas funciones
de un sistema de base de datos distribuido.

Rplica total Rplica parcial Particin
Procesamiento de consultas fcil dificultad Similar
Gestin del directorio fcil o inexistente dificultad Similar
Control de concurrencia moderado difcil Fcil
Seguridad muy alta alta Baja
Realidad posible aplicacin realista posible aplicacin

Informacin necesaria

Un aspecto importante en el diseo de la distribucin es la cantidad de factores que
contribuyen a un diseo ptimo. La organizacin lgica de la base de datos, la localizacin
de las aplicaciones, las caractersticas de acceso de las aplicaciones a la base de datos y las
caractersticas del sistema en cada sitio, tienen una decisiva influencia sobre la distribucin.
La informacin necesaria para el diseo de la distribucin puede dividirse en cuatro

3443
categoras: la informacin del banco de datos, la informacin de la aplicacin, la
informacin sobre la red de ordenadores y la informacin sobre los ordenadores en s. Las
dos ltimas son de carcter cuantitativo y servirn, principalmente, para desarrollar el
proceso de asignacin. Se entrar en detalle sobre la informacin empleada cuando se
aborden los distintos algoritmos de fragmentacin y asignacin.

2.6 Procesamiento distribuido de consultas

Existen varios medios para calcular la respuesta a una consulta. En el caso de
sistemas centralizado, el criterio principal para determinar el costo de una estrategia
especfica es el nmero de accesos al disco. En un sistema distribuido es preciso tener en
cuenta otros factores, como son:

El costo de transmisin de datos en la red.

El beneficio potencial que supondra en la ejecucin el que varias localidades
procesaran en paralelo partes de la consulta.

El costo relativo de la transferencia de datos en la red y la transferencia de datos
entre la memoria y el disco vara en forma considerable, dependiendo del tipo de red y de la
velocidad de los discos. Por tanto, en un caso general, no podemos tener en cuenta solo los
costos del disco o los de la red. Es necesario llegar a un equilibrio adecuado entre los dos.

3443
Repeticin y fragmentacin

Considere una consulta muy sencilla: encontrar todas las tuplas de la relacin
depsito. Aunque la consulta es muy simple, de hecho es trivial; su procesamiento no es
trivial, ya que es posible que la relacin depsito est fragmentada, repetido o las dos cosas,
como ya se vio. Si la relacin deposito est repetida, es preciso decidir qu copia se va a
utilizar. Si ninguna de las copias est fragmentada, se elige la copia que implique costos de
transmisin ms reducidos. Pero si una copia est fragmentada, la eleccin no es tan
sencilla, ya que es preciso calcular varios productos o uniones para reconstruir la relacin
depsito. En tal caso, el nmero de estrategias para este ejemplo sencillo puede ser grande.

De hecho, la eleccin de una estrategia puede ser una tarea tan compleja como hacer
una consulta arbitraria.
Procesamiento de interseccin simple
No puede garantizarse que una estrategia sea la mejor en todos los casos. Entre los
factores que deben tomarse en cuenta estn la cantidad de datos que debe transmitirse, el
costo de transmitir un bloque de datos entre dos localidades determinadas y la velocidad
de procesamiento relativa en cada localidad.

3443

SEGURIDAD EN LAS BASES DE DATOS

3.1 Introduccin

La informacin es uno de los activos ms importantes de las entidades, y de uso
especial en algunos sectores de actividad.

Es indudable que cada da las entidades dependen de mayor medida de la
informacin y de la tecnologa, y que los sistemas de informacin estn ms soportados por
la tecnologa, frente a la realidad de hace pocas dcadas.

Por otra parte, hace unos aos la proteccin era ms fcil, con arquitecturas
centralizadas y terminales no inteligentes, pero hoy en da los entornos son realmente
complejos, con diversidad de plataformas y proliferacin de redes, no slo internos sino
tambin externos, incluso con enlaces internacionales.

Entre las plataformas fsicas (hardware) pueden estar: ordenadores grandes y
medianos, ordenadores departamentales y personales, solos o formando parte de red, e
incluso ordenadores porttiles. Esta diversidad acerca la informacin a los usuarios, si bien
hace mucho ms difcil proteger los datos, especialmente porque los equipos tienen
filosofas y sistemas operativos diferentes, incluso a veces siendo del mismo fabricante.

3443
Al hablar de seguridad hemos preferido centrarnos en la informacin misma,
aunque a menudo se hable de seguridad informtica, de seguridad de los sistemas de
informacin o de seguridad de las tecnologas de la informacin.

En cualquier caso hay tres aspectos principales, como distintas vertientes de la
seguridad.

La confidencialidad: se cumple cuando solo las personas autorizadas (en su sentido
amplio podramos referirnos tambin a sistemas) pueden conocer los datos o la informacin
correspondiente.

Podemos preguntarnos qu ocurrira si un soporte magntico con los datos de
nuestros empleados o clientes fuera cedido a terceros? Cul podra ser su uso final?Habr
una cadena de cesiones o ventas incontroladas de esos datos, que podra incluir datos como
domicilios o perfil econmico, o incluso datos mdicos? Y si alguien se hiciera con un
disquete con lo que perciben los directivos de nuestra entidad?.

La integridad: consiste en que slo las personas autorizadas puedan variar
(modificar o borrar) los datos. Adems deben quedar pistas para control posterior y para
auditoria.

Pensemos que alguien modificara datos de forma que perdiramos la informacin de
determinadas deudas a cobrar (o que sin perderla tuviramos que recurrir a la informacin
en papel), o que modificara la ltima parte de los domicilios de algunos clientes.

3443

Algunas de estas acciones se podran tardar en detectar, y tal vez las diferentes
copias de seguridad hechas a lo largo del tiempo estaran viciadas (corruptas decimos a
veces), lo que hara difcil la reconstruccin.

La disponibilidad: se cumple si las personas autorizadas pueden acceder a tiempo a
la informacin.

El disponer de la informacin despus del momento necesario puede equivaler a la
no disponibilidad. Otro tema es disponer de la informacin a tiempo pero que esta no sea
correcta, e incluso que no se sepa, lo que puede originar la toma de decisiones errneas.

Otro caso grave, es la no disponibilidad absoluta. Por haberse producido algn
desastre. En este caso, a medida que pasa el tiempo el impacto ser mayor, hasta llegar a
suponer la no continuidad de la entidad, como ha pasado en muchos de los casos
producidos (ms de un 80% segn estadsticas), ya que las incidencias son frecuentes.

En relacin con ello deben existir soluciones alternativas, basadas en medios
propios o contratados, copias actualizadas de la informacin crtica y de programas en un
lugar diferente, y un verdadero plan de continuidad que permita restablecer las operaciones
en un tiempo inferior o igual al prefijo.

Para ello los usuarios habrn determinado previamente la criticidad de las
aplicaciones y el impacto en sus reas por parte de un comit, se habrn determinado las
prioridades.

3443

En la preparacin y actualizacin del plan debemos pensar en situaciones posibles y
en el impacto que tendran en nuestra entidad (en su caso en las de nuestros clientes),
especialmente si no disponemos de la informacin necesaria almacenada en lugares
alternativos.

La seguridad tiene varios estratos:

El marco jurdico adecuado

Medidas tcnico-administrativas, como la existencia de polticas y procedimientos,
o la creacin de funciones, como administracin de la seguridad o auditoria de sistemas de
informacin interna.

Ambas funciones han de ser independientes y nunca una misma persona podr
realizar las dos ni existir dependencia jerrquica de una funcin respecto a otra.

En cuanto a la administracin de seguridad pueden existir, adems, coordinadores
en las diferentes reas funcionales y geogrficas de cada entidad, especialmente si la
dispersin a la complejidad organizativa o el volumen de la entidad as lo demandan.

En el caso de multinacionales o grupos de empresas nacionales no esta de ms que
exista coordinacin a niveles superiores.

3443
En todo caso, debe existir una definicin de funciones y separacin de tareas; no
tiene sentido que una misma persona autorice una transaccin, la introduzca, y revise
despus los resultados (un diario de operaciones, por ejemplo), porque podra planificar
un fraude o encubrir cualquier anomala, por ello deben intervenir funciones personales
diferentes y existir controles suficientes.

La seguridad fsica, como la ubicacin de los centros de procesos, las protecciones
fsicas, el control fsico de accesos, los vigilantes, las medidas contra el fuego y el agua, y
otras similares.

La llamada seguridad lgica, como el control de accesos a la informacin exigiendo
la identificacin y autenticacin del usuario, o el cifrado de soportes magnticos
intercambiados transmitidos por lnea. (Puede haber cifrado de la informacin por
dispositivos fsicos o a travs de programas.

La autenticacin suele ser mediante contrasea, si bien sera ms lgico, aunque los
costos resultan aun altos para la mayora de sistemas, que pudieran con caractersticas
biomtricas del usuario, para impedir la suplantacin. Entre estas, puede estar la realizacin
de la firma con reconocimiento automtico por ordenador, el anlisis del fondo de ojo, la
huella u otras.

3.2 Riesgos
Al margen de la seguridad, nos parece que el mayor riesgo, aun teniendo un entorno
muy seguro, es que la informtica, y la tecnologa de la informacin en general, no cubran
las necesidades de la entidad: no estn alineadas con el plan de negocio.

3443

Limitndonos a la seguridad propiamente dicha, los riesgos pueden ser mltiples: el
primer paso es conocerlos, y el segundo es tomar decisiones al respecto; el conocerlos y no
tomar decisiones no tiene sentido y debiera crearnos una situacin de desasosiego.

Como las medidas tienen un coste, a veces los directivos se preguntan a los
consultores, cul es el riesgo mximo que podra soportar su entidad, si bien la respuesta
no es fcil, porque dependen de la criticidad del sector y de la entidad misma, de su
dependencia respecto a la informacin, y del impacto que su disponibilidad pudiera tener
en la entidad.

Si nos basamos en el impacto nunca debera aceptarse un riesgo que pudiera llegar a
poner en peligro la propia continuidad de la entidad, pero este precio es demasiado alto.

Por debajo de ello, hay daos de menores consecuencias, siendo los errores y
omisiones la causa ms frecuente, normalmente de poco impacto pero frecuencia muy alta,
y otras el acceso indebido a los datos (a veces a travs de redes), la cesin no autorizada de
soportes magnticos con la informacin critica, algunos dicen sensible), los daos por
fuego, por agua (del exterior como puede ser una inundacin, o una tubera interior), la
variacin no autorizada de programas, persiguiendo el propio beneficio o el causar un dao,
a veces por venganza.

Otra figura es la del hacker, que intenta acceder a los sistemas ms para demostrar
(a veces sobre todo para demostrarse a s mismo) de que es capaz, as como que pueda
superar las barreras de proteccin que hayan establecido.

3443

Alguien podra preguntarse por qu no se citan tambin los virus, cuando han tenido
tanta incidencia; afortunadamente esta es menor ahora que hace unos aos, si bien existe un
riesgo constante porque de forma continua aparecen nuevas modalidades, que no son
detectadas por los programas antivirus hasta que las nuevas versiones los contemplan. Y un
riesgo adicional es que los virus puedan llegar a afectar a los grandes sistemas, sobre todo a
travs de las redes, pero esto es realmente difcil, no nos atrevemos a decir que imposible
por las caractersticas y complejidad de los grandes equipos y las caractersticas de diseo
de sus sistemas operativos.

En definitiva, las amenazas hechas realidad pueden llegar a impactar en los datos,
en las personas, en los programas, en los equipos, en la red y alguna incidencia en varios de
ellos, como puede ser un incendio.

Podramos hacernos una pregunta qu es lo ms crtico a proteger?

La respuesta de la mayora probablemente sera que las personas somos lo ms
crtico, y el valor de una vida humana no se puede comparar con los ordenadores, las
aplicaciones o los datos de cualquier entidad.

Ahora bien, por otra parte, podemos determinar que los datos son an ms crticos si
nos centramos en la continuidad de la entidad.

Como consecuencia de cualquier incidencia se puede producir unas prdidas, que
pueden ser no solo directas (y stas es ms fcil que puedan cubrirlas los seguros), sino

3443
tambin indirectas, como la no recuperacin de deudas al perder los datos, o no
poder tomar las decisiones adecuadas en el momento oportuno por carecer de informacin.

Sabemos que se producen casos en gran parte de entidades, pero en general no
conocemos a cual han afectado (o lo sabemos pero no podemos difundirlo), porque por
imagen no se hacen pblicos los casos, y el hecho de que conozcan muchos ms referidos a
Estados Unidos y otros puntos lejanos que respecto a nuestros pases no significa que
estemos a salvo, sino que nuestro pudor es mayor y los ocultamos siempre que podemos.

3.3 Proteccin de activos y vitales

Son activos vitales todos aquellos relacionados con la continuidad de la entidad,
como pueden ser: planes estratgicos, frmulas magistrales, diseo de prototipos,
resguardos, contratos, plizas, y datos estratgicos, que son los que ms nos interesan bajo
la perspectiva de la seguridad de la informacin.

Y debemos protegerlos pensando en los intereses de los accionistas, de los clientes y
tambin pensando en los empleados y en los proveedores.

Cabe preguntarse el coste de la seguridad frente al coste de la no seguridad, si bien
con antelacin no es fcil saber qu alternativas es mejor, pero no se trata de buscar la
mayor rentabilidad econmica, porque hay razones de otra ndole.

Y debemos pensar que se trata de INVERSIONES en seguridad, aunque en algunos
casos se nos dira que no es fcil reflejar como activos contables y que cual es su

3443
rentabilidad, necesariamente hemos de estar de acuerdo, pero cul es la rentabilidad de
blindar la puerta de acceso a nuestro domicilio, o nuestro coche? Esa rentabilidad la
podemos determinar si los dispositivos o controles han servido para evitar la agresin, pero
a veces habr constituido una medida disuasoria y no llegaremos a enterarnos de su efecto
positivo.

En todo caso la seguridad puede tener aun impacto favorable en el imagen de las
entidades, aunque ello slo no suela justificar sus costes, y tanto para clientes y posibles
clientes como para los empleados. Unos y otros pueden sentirse ms protegidos, as como
considerar ms protegidos sus activos.

Y la proteccin no ha de basarse slo en dispositivos y medios fsicos, sino en
formacin e informacin adecuada al personal, empezando por los directivos para que, en
cascada, afecte a todos los niveles de la pirmide organizativa.

Adems, la existencia de funciones especficas cuando el entorno lo justifica,
contribuye a incrementar la seguridad. Entre ellas las citadas de administracin de la
seguridad y auditoria de sistemas de informacin interna.

Porque deben existir los tres niveles de proteccin:

El CONTROL INTERNO, basado en los objetivos de control y llevado a cabo por
los supervisores a distintos niveles.

3443
La AUDITORIA DE SISTEMAS DE INFORMACIN INTERNA, objetiva e
independiente y con una preparacin adecuada, como herramienta de control.

La AUDITORIA DE SISTEMAS DE INFORMACIN EXTERNA, contratada cuando
se considera necesaria, y como un nivel de proteccin ms. Igualmente objetiva e
independiente.

Los informes de auditores, internos o externos, han de sealar las posibilidades
deficiencias e indicar, en su caso, las recomendaciones correspondientes.

Cabe preguntarse qu hacer, qu pasos dar. No hay soluciones nicas, sino que
dependen de la entidad y del momento, por lo que se indica pasos generales.

Debe partirse de una poltica corporativa sobre la seguridad. El paso
siguiente puede ser la designacin de personas conciertes para funciones determinadas.

Y si no existe una idea calara de cules son los riesgos debe hacerse una evaluacin
de dichos riesgos, por personas objetivas e independientes y tcnicamente preparadas, que
pueden ser internas, externas, o formando un equipo mixto.

Una vez conocidos los riesgos han de tomarse decisiones, tendentes a eliminarlos,
que siempre es posible, a reducirlos, a transferirlos (a una compaa de seguros por
ejemplo), o bien aceptarlos, a un nivel suficiente alto y corporativo.

3443
La contratacin de seguros es necesaria si bien es evidente que, respecto a la
informacin, pueden resarcirnos de la prdida econmica en el caso de incidencias pero si
no disponemos de los datos no podremos procesar y, como se ha indicado, se puede poner
en peligro incluso la continuidad de la entidad.

Despus la entidad ha de crear un modelo de seguridad (o adoptar uno existente) as
como definir una estrategia a seguir, establecer un plan y aportar los medios necesarios, que
adems de presupuestad son el reconocimiento de la importancia de la seguridad, y que no
quede como tareas de rellano para cubrir tiempos de ocio de los tcnicos.

Uno de los primeros productos ha de ser un conjunto de objetivos de control interno,
que nos gusta definir como declaraciones sobre el resultado final deseado o del propsito a
ser alcanzados mediante la implantacin de procedimientos de control.

Para ello la entidad puede basarse en publicaciones como los control objetives, de la
informacin System Audit and Control Association, que cuenta con varios captulos en
Mxico, as como en otros pases iberoamericanos y en Espaa.

Podemos decir que un sistema de control interno puede constar de procesos,
funciones, actividades, subsistemas y dispositivos, cuya finalidad (total o parcial) sea
garantizar que se alcanzan los mencionados objetivos de control.

Finalmente se han de definir proyectos concretos, con actividades, responsables,
resultados y costes.

3443

3.4 Programacin sobre la Seguridad de Access

Les ofrezco una visin global del mecanismo de seguridad de Access y la forma de
administrar la misma con cdigo VB. Aclaro que VB no proporciona ningn mtodo para
crear una BD del sistema de seguridad, pero si cuenta con la capacidad de administrar la
seguridad que esta provee.

Seguridad de Access

Las versiones recientes de Microsoft Access ofrecen dos mtodos para proteger una
base de datos: contrasea para abrir un archivo de base de datos o mediante seguridad a
nivel de usuario o de cuentas. Adems de estos mtodos, puede eliminar cdigo
modificable de VB de la base de datos y as proteger el diseo de formularios, informes y
mdulos de la base de datos de posibles modificaciones guardndolo como un archivo
MDE. Estos ltimos tpicos no sern tratados en este documento.

Contrasea de archivo MDB

Brevemente me refiero a esta opcin para centrarnos en el Sistema de Cuentas que
es el propsito de este artculo. El mtodo Contrasea de Archivo MDB es simple y
consiste en habilitar una contrasea para abrir un archivo MDB especifico. El mtodo es el
adecuado para una base de datos que est compartida entre un pequeo grupo de usuarios o
sobre un slo equipo. No es aplicable si quiere replicar la BD o pretende implantar un

3443
sistema de seguridad en red. Si desea abrir una BD con contrasea de archivo siga este
cdigo:

Dim wrkJet As Workspace
Dim dbsM97 As Database
Set wrkJet = CreateWorkspace("", "admin", "", dbUseJet)
Set dbsM97 = wrkJet.OpenDatabase("miBD.mdb", True, False, "; pwd=miClave")

Tenga en cuenta este cdigo porque en ninguna parte de la ayuda en lnea lo
encuentra tan claro.

En caso de usar el DataControl, hacerlo de esta forma, (dato de Jose Ramon):

Data1.Connect = "; pwd=MiClave"

Para compactar una BD con contrasea pueden seguir este ejemplo particular (dato
de Jose Ramon Laperal):

DBEngine.CompactDatabase "MiBase", "MiBaseCompacta", dbLangGeneral, _
dbVersion30, "; pwd=MiClave"

El xito de la instruccin depende de los parmetros suministrados.

3443

Sistema de Cuentas

Los usuarios son obligados a identificarse y escribir una contrasea cuando inician
Microsoft Access o una Aplicacin Access. La seguridad se basa en permisos, los cuales
son atributos para un grupo o usuario. Por ejemplo, a un grupo bautizado Usuarios_Alpha
se les permita visualizar, introducir o modificar datos en una tabla Clientes, pero no se les
permita cambiar el diseo de esa tabla, ni acceder otras tablas. As un usuario que
pertenezca a este grupo slo tendr estos atributos y, en particular, los que le quiera dar un
Administrador.

Las tres razones principales para utilizar la seguridad al nivel de usuario son las
siguientes:

Proteger la propiedad intelectual del cdigo

Impedir que los usuarios cambien o inutilicen inadvertidamente una aplicacin
cambiando cdigo de objetos de los que depende la aplicacin.

Proteger los datos sensibles de la base de datos.

Si quieren entender plenamente el sistema de seguridad, es necesario estudiar los
conceptos del mismo, como son varios, y la teora es amplia, les tengo que sugerir el
capitulo

3443
Proteccin de la aplicacin, en el manual Creacin de aplicaciones que viene con
Microsoft Access (2.0/95/97). Pero para los que estn de afn, le sugiero esta receta para
crear un sistema de seguridad:

1. Crear a o unirse a grupo de trabajo
Textualmente, Un grupo de trabajo de Microsoft Access es un grupo de usuarios en
un entorno multiusuario que comparten datos. Un Grupo de Trabajo se sirve de un archivo
donde se almacenan las cuentas. Puede usar una predeterminado, uno existente o crear uno
nuevo. Para esto emplea el Administrador para grupos de trabajo. Busque el archivo
Wrkgadm.exe (Access 2.0 o superior).

2. Cree una Cuenta de Propietario y Una de Administrador.
Con el Grupo de Trabajo activo, inicie MS Access, abra una BD, men Usuarios,
Usuario, del cuadro de dialogo escoja Nuevo, del cuadro de dialogo escriba el Nombre y un
ID personal (esta combinacin identificara al usuario de aqu en adelante) y Aceptar. Para
crear la cuenta de propietario siga las mismas instrucciones. El Administrador administrara
el Grupo de Trabajo, el propietario como su nombre lo indica, ser el dueo de la BD y sus
objetos.

3. Activar el procedimiento de inicio de sesin
Una BD ser protegida cuando el administrador tenga contrasea y tenga
Titularidad. Con el Grupo de Trabajo activo, inicie MS Access, abra una BD, men
Cambiar Contrasea, Cambiar Contrasea. Siga el cuadro de dialogo. La prxima vez que
inicie Access, el cuadro de dialogo Conexin solicitara el nombre de un usuario y su
contrasea.

3443

4. Cambie la Titularidad

Inicie la sesin con la cuenta del nuevo Administrador creado anteriormente, Cree
una nueva BD: men Archivo, Complementos, Importar BD. Seleccione el archivo MDB
cuya titularidad desea cambiar, y de Aceptar. Tambin puede cambiar la titularidad de un
objeto individual, desde los dilogos Cambiar Propietario, pero no desviemos la atencin.
Valga aclara que las bases de datos creadas desde una sesin de grupo, no necesitan
cambiar su titularidad porque la traen de nacimiento.

5. Cree las cuentas de los Usuarios.

Cree grupos y usuarios de la siguiente manera. Abra la BD, men seguridad, Grupos
o Usuarios, siga los dilogos. Los PID son importantes para el administrador, no para los
usuarios, antelos. Despus de creados los usuarios y grupos, puede hacer que un usuario,
digamos John, pertenezca a un grupo y as limite sus permisos. Para generalizar, recuerde,
la administracin de las cuentas se lleva a cabo desde el men Seguridad, creo que no
necesitas memorizar ms recetas.

6. Asignar Autorizaciones

Una vez creadas las cuentas, puede asignar autorizaciones a esas cuentas. Men
seguridad, autorizaciones. Importante: su BD no estar segura hasta no eliminar las
autorizaciones del usuario Administrador y del grupo Usuarios (cuentas predeterminadas de
Access). En realidad la administracin de autorizaciones es el proceso donde invertir la

3443
mayor parte del tiempo (la lgica de autorizaciones se aprende ensayando). Tenga presente
en autorizaciones no solo a las tablas, tambin a las consultas, mdulos y formularios.

7. Asignar Contraseas

Al fin llegamos al paso fcil. Asgnele una contrasea a cada uno de sus usuarios.
Es ms rpido con cdigo VB. Con Access, tiene que iniciar Access con cada cuenta, ir al
men Seguridad, Cambiar Contrasea y asignar el password. Si un usuario no tiene
contrasea, cualquiera puede entrar con el nombre de ese usuario, en ese momento la
contrasea es una cadena vaca. Un usuario puede cambiar su contrasea en el momento
que lo desee.

Otro nivel es la codificacin de la BD, pero aun no he llegado a este extremo. Es til
para protegerse de hackers o, no? No es difcil, pero s riesgoso (opinin personal). Desde
el men Archivo, seleccione Codificar/Decodificar BD.

Si llego hasta aqu, y no est an frustrado, me alegra. Vea lo que le espera para
implantar una aplicacin que acceda una BD protegida.

Cdigo Visual Basic

VB proporciona una interfaz poderosa de cdigo para administrar un sistema de
cuentas. Pero antes que se anime, lo ms crtico es decirle a VB cual BD del sistema usar.
Tengan presente esta cita:

3443

Cuando se instala el controlador de bases de datos motor Microsoft Jet, el
programa de instalacin escribe un juego de valores predeterminados en el Registro de
Windows en las subclaves Engines y ISAM, para Jet 3.0. Para Jet 2.5, los valores de
inicializacin se encuentran en el archivo VB.INI o en el archivo <NOMBREAPL>.INI,
dependiendo del valor de la propiedad InitPath del objeto DBEngine.

Es decir, muy posiblemente tendr que vrselas con el espantoso Regedit.Exe o con
los INI si usa aplicaciones de 16 bits. Al respecto, le recomiendo buscar en la ayuda en
lnea estos temas:

Ayuda, Tab [Index], busque inicio del motor de base de datos, y seleccione el titulo
Cambio de la configuracin ISAM del motor Microsoft Jet.

Ejemplos Visual Basic

Puede lanzarse a programar con VB. Los siguientes bloques de cdigo los obtuve de
la ayuda en lnea, los refine y organice. Son para DAO 3.5, para otras versiones el cdigos
es similar, solo que ms sencillos. Ha sido fuente de informacin ma. El mdulo es muy
completo y didctico.

3.5 Seguridad Informtica

Seguridad informtica, tcnicas desarrolladas para proteger los equipos informticos
individuales y conectados en una red frente a daos accidentales o intencionados. Estos

3443
daos incluyen el mal funcionamiento del hardware, la prdida fsica de datos y el acceso a
bases de datos por personas no autorizadas. Diversas tcnicas sencillas pueden dificultar la
delincuencia informtica. Por ejemplo, el acceso a informacin confidencial puede evitarse
destruyendo la informacin impresa, impidiendo que otras personas puedan observar la
pantalla del ordenador, manteniendo la informacin y los ordenadores bajo llave o retirando
de las mesas los documentos sensibles. Sin embargo, impedir los delitos informticos exige
tambin mtodos ms complejos.

En un sistema de los denominados "tolerante a fallos" dos o ms ordenadores
funcionan a la vez de manera redundante, por lo que si una parte del sistema falla el resto
asume el control.

Los virus informticos son programas, generalmente destructivos, que se introducen
en el ordenador (al leer un disco o acceder a una red informtica) y pueden provocar
prdida de la informacin (programas y datos) almacenada en el disco duro. Existen
programas antivirus que los reconocen y son capaces de "inmunizar" o eliminar el virus del
ordenador. Para evitar problemas en caso de apagn elctrico existen las denominadas UPS
(acrnimo de Uninterrupted Power Supply), bateras que permiten mantener el sistema
informtico en funcionamiento, por lo menos el tiempo necesario para apagarlo sin prdida
de datos. Sin embargo, la nica forma de garantizar la integridad fsica de los datos es
mediante copias de seguridad.

3443
El mayor problema que tienen que resolver las tcnicas de seguridad informtica es
el acceso no autorizado a datos. En un sistema seguro el usuario, antes de realizar cualquier
operacin, se tiene que identificar mediante una clave de acceso. Las claves de acceso son
secuencias confidenciales de caracteres que permiten que los usuarios autorizados puedan
acceder a un ordenador. Para ser eficaces, las claves de acceso deben resultar difciles de
adivinar. Las claves eficaces suelen contener una mezcla de caracteres y smbolos que no
corresponden a una palabra real. Adems, para aumentar la seguridad, los sistemas
informticos suelen limitar el nmero de intentos de introducir la clave.

Las tarjetas de contrasea son tarjetas de plstico que no pueden ser manipuladas,
dotadas de un microprocesador que almacena una clave de acceso que cambia
frecuentemente de forma automtica. Cuando se entra en un ordenador mediante una tarjeta
de acceso, el ordenador lee la clave de la tarjeta y otra clave introducida por el usuario, y
las compara respectivamente con una clave idntica a la de la tarjeta (que el ordenador
genera automticamente) y con la clave de acceso del usuario, que est almacenada en una
lista confidencial. En el futuro, es posible que las claves y las tarjetas de acceso se vean
reforzadas por mecanismos biomtricos basados en caractersticas personales nicas como
las huellas dactilares, los capilares de la retina, las secreciones de la piel, el cido
desoxirribonucleico (ADN), las variaciones de la voz o los ritmos de tecleado. Sistemas
operativos como Mac OS, UNIX y Windows-NT permiten restringir el acceso a recursos
del sistema (ficheros, perifricos) de acuerdo con esa identificacin.

Los hackers son usuarios muy avanzados que por su elevado nivel de conocimientos
tcnicos son capaces de superar determinadas medidas de proteccin. Internet, con sus
grandes facilidades de conectividad, permite a un usuario experto intentar el acceso remoto

3443
a cualquier mquina conectada, de forma annima. Las redes corporativas u ordenadores
con datos confidenciales no suelen estar conectadas a Internet; en el caso de que sea
imprescindible esta conexin se utilizan los llamados cortafuegos, un ordenador situado
entre las computadoras de una red corporativa e Internet. El cortafuegos impide a los
usuarios no autorizados acceder a los ordenadores de una red, y garantiza que la
informacin recibida de una fuente externa no contenga virus.
Unos ordenadores especiales denominados servidores de seguridad proporcionan
conexiones seguras entre las computadoras conectadas en red y los sistemas externos como
instalaciones de almacenamiento de datos o de impresin. Estos ordenadores de seguridad
emplean el cifrado en el proceso de dilogo inicial, el comienzo del intercambio
electrnico, lo que evita una conexin entre dos ordenadores a no ser que cada uno de ellos
reciba confirmacin de la identidad del otro.

Una tcnica para proteger la confidencialidad es el cifrado. La informacin puede
cifrarse y descifrarse empleando ecuaciones matemticas y un cdigo secreto denominado
clave. Generalmente se emplean dos claves, una para codificar la informacin y otra para
descodificarla. La clave que codifica la informacin, llamada clave privada, slo es
conocida por el emisor. La clave que descodifica los datos, llamada clave pblica, puede
ser conocida por varios receptores. Ambas claves se modifican peridicamente, lo que
complica todava ms el acceso no autorizado y hace muy difcil descodificar o falsificar la
informacin cifrada. Estas tcnicas son imprescindibles si se pretende transmitir
informacin confidencial a travs de un medio no seguro como puede ser Internet. Las
tcnicas de firma electrnica permiten autentificar los datos enviados de forma que se
pueda garantizar la procedencia de los mismos (imprescindible, por ejemplo, a la hora de
enviar una orden de pago).

3443

HERRAMIENTAS CASE
Ing. Luis Armando Garca Eliseo

4.1 Introduccin

Hoy en da, muchas empresas se han extendido a la adquisicin de herramientas
CASE (Ingeniera Asistida por Computadora), con el fin de automatizar los aspectos clave
de todo el proceso de desarrollo de un sistema, desde el principio hasta el final e
incrementar su posicin en el mercado competitivo, pero obteniendo algunas veces
elevados costos en la adquisicin de la herramienta y costos de entrenamiento de personal
as como la falta de adaptacin de la herramienta a la arquitectura de la informacin y a las
metodologas de desarrollo utilizadas por la organizacin. Por otra parte, algunas
herramientas CASE no ofrecen o evalan soluciones potenciales para los problemas
relacionados con sistemas o virtualmente no llevan a cabo ningn anlisis de los
requerimientos de la aplicacin.

Sin embargo, CASE proporciona un conjunto de herramientas semiautomatizadas y
automatizadas que estn desarrollando una cultura de ingeniera nueva para muchas
empresas. Uno de los objetivos ms importante del CASE (a largo plazo) es conseguir la
generacin automtica de programas desde una especificacin a nivel de diseo.

Ahora bien, con la aparicin de las redes de ordenadores en empresas y
universidades ha surgido en el mundo de la informtica la tecnologa cliente / servidor. Son
muchas de las organizaciones que ya cuentan con un nmero considerable de aplicaciones

3443
cliente / servidor en operacin: Servidores de Bases de Datos y Manejadores de Objetos
Distribuidos. Cliente / servidor es una tecnologa de bajo costo que proporciona recursos
compartidos, escalabilidad, integridad, encapsulamiento de servicios, etc. Pero al igual que
toda tecnologa, el desarrollo de aplicaciones cliente / servidor requiere que la persona
tenga conocimientos, experiencia y habilidades en procesamiento de transacciones, diseo
de base de datos, redes de ordenadores y diseo grfica de interface.

El objeto de estudio est centrado en determinar cules son las influencias de las
herramientas CASE en las empresas desarrolladoras de sistemas de informacin cliente /
servidor? Y cules son las tendencias actuales de las empresas fabricantes de sistemas
cliente / servidor?

A continuacin, en el siguiente artculo ahondaremos ms en el propsito general de
las Herramientas CASE y el impacto que puede ocasionar el uso de las mismas en una
empresa.

4.2. Herramientas Case

De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador
es la aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas
propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseadas, en
el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo
de sistemas.

3443
Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de
vida de las aplicaciones de bases de datos, tambin se puede escoger una herramienta
CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas
del modo ms eficiente y efectivo posible. Una herramienta CASE suele incluir:

Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin
de bases de datos.

Herramientas de diseo para dar apoyo al anlisis de datos.

Herramientas que permitan desarrollar el modelo de datos corporativo, as como los
esquemas conceptual y lgico.

Herramientas para desarrollar los prototipos de las aplicaciones.

El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de
una aplicacin de bases de datos.

Historia

En la dcada de los setenta el proyecto ISDOS desarroll un lenguaje llamado
"Problem Statement Language" (PSL) para la descripcin de los problemas de usuarios y
las necesidades de solucin de un sistema de informacin en un diccionario computarizado.
Problem Statement Analyzer (PSA) era un producto asociado que analizaba la relacin de
problemas y necesidades.

3443
Pero la primera herramienta CASE como hoy la conocemos fue "Excelerator" en
1984, era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos
por ejemplo el EASYCASE o WINPROJECT.

4.3 Tecnologa Case

La tecnologa CASE supone la automatizacin del desarrollo del software,
contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de
informacin y se plantean los siguientes objetivos:

Permitir la aplicacin prctica de metodologas estructuradas, las cuales al
ser realizadas con una herramienta se consigue agilizar el trabajo.
Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento de los programas.
Mejorar y estandarizar la documentacin.
Aumentar la portabilidad de las aplicaciones.
Facilitar la reutilizacin de componentes software.
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante
la utilizacin de grficos.
Automatizar:
El desarrollo del software
La documentacin
La generacin del cdigo
El chequeo de errores
La gestin del proyecto

3443

Permitir:
La reutilizacin del software
La portabilidad del software
La estandarizacin de la documentacin

4.4 Componentes de una herramienta case

De una forma esquemtica podemos decir que una herramienta CASE se compone
de los siguientes elementos:

Repositorio (diccionario) donde se almacenan los elementos definidos o creados por
la herramienta, y cuya gestin se realiza mediante el apoyo de un Sistema de Gestin de
Base de Datos (SGBD) o de un sistema de gestin de ficheros.

Meta modelo (no siempre visible), que constituye el marco para la definicin de las
tcnicas y metodologas soportadas por la herramienta.

Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la
herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la
propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez,
alimentar otros sistemas. Este elemento proporciona as un medio de comunicacin con
otras herramientas.

3443
Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de la
exactitud, integridad y consistencia de los esquemas generados por la herramienta.

Interfaz de usuario, que constar de editores de texto y herramientas de diseo
grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos y mens,
con la ayuda del ratn, definir los diagramas, matrices, etc. que incluyen las distintas
metodologas.

4.5 Estructura general de una herramienta CASE

La estructura CASE se basa en la siguiente terminologa:

CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases
finales o superiores del ciclo de vida del desarrollo de sistemas como la planificacin de
sistemas, el anlisis de sistemas y el diseo de sistemas.

CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases
finales o inferiores del ciclo de vida como el diseo detallado de sistemas, la implantacin
de sistemas y el soporte de sistemas.

CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan
actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades
como la gestin de proyectos y la estimacin.

3443

4.6 Estado Actual

En las ltimas dcadas se ha trabajado en el rea de desarrollo de sistemas para
encontrar tcnicas que permitan incrementar la productividad y el control de calidad en
cualquier proceso de elaboracin de software, y hoy en da la tecnologa CASE (Computer
Aided Software Engineering) reemplaza al papel y al lpiz por el ordenador para
transformar la actividad de desarrollar software en un proceso automatizado.

La tecnologa CASE supone la informatizacin de la informticaes decir la
automatizacin del desarrollo del software--, contribuyendo as a elevar la productividad y
la calidad de en el desarrollo de los sistemas de informacin de forma anloga a lo que
suponen las tcnicas CAD/CAM en el rea de fabricacin.

En este nuevo enfoque que persigue mejorar la calidad del software e incrementar la
productividad en el proceso de desarrollo del mismo, se plantean los siguientes objetivos:
Permitir la aplicacin prctica de metodologas, lo que resulta muy difcil sin
emplear herramientas.
Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento del software.
Mejorar y estandarizar la documentacin.
Aumentar la portabilidad de las aplicaciones.
Facilitar la reutilizacin de componentes de software
Permitir un desarrollo y un refinamiento (visual) de las aplicaciones,
mediante la utilizacin de controles grficos (piezas de cdigo reutilizables).

3443

4.7 Integracin de las herramientas case en el futuro

Las herramientas CASE evolucionan hacia tres tipos de integracin:

La integracin de datos permite disponer de herramientas CASE con diferentes
estructuras de diccionarios locales para el intercambio de datos.

La integracin de presentacin confiere a todas las herramientas CASE el mismo
aspecto.

La integracin de herramientas permite disponer de herramientas CASE capaces de
invocar a otras CASE de forma automtica.

4.8 Clasificacin de las herramientas CASE

No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil
incluirlas en una clase determinada. Podran clasificarse atendiendo a:

Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.

3443

CASE es una combinacin de herramientas software (aplicaciones) y de
metodologas de desarrollo:
1. Las herramientas permiten automatizar el proceso de desarrollo del software.
2. Las metodologas definen los procesos automatizar.

Una primera clasificacin del CASE es considerando su amplitud:

TOOLKIT: es una coleccin de herramientas integradas que permiten automatizar
un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informtico:
Planificacin estratgica, Anlisis, Diseo, Generacin de programas.

WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la
automatizacin del proceso completo de desarrollo del sistema informtico. Permiten cubrir
el ciclo de vida completo. El producto final aportado por ellas es un sistema en cdigo
ejecutable y su documentacin.

Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del ciclo de
vida que automatizan:
UPPER CASE: Planificacin estratgica, Requerimientos de desarrollo
Funcional de Planes Corporativos.
MIDDLE CASE: Anlisis y Diseo.
LOWER CASE: Generacin de cdigo, test e implantacin

Antología para Bases de Datos Corporativas PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Antología para Bases de Datos Corporativas PDF

Enviado por

Direitos autorais:

Formatos disponíveis

DEPARTAMENTO DE INGENIERA EN

Você também pode gostar