BDOO2

TERMINO OO
El trmino orientacin a objetos (abreviado como 00 u O-O) tiene sus orgenes

en los lenguajes de programacin 00, u OOPLs.

Actualmente, los conceptos 00 se aplican en las reas de las bases de datos,
la ingeniera del software, las bases de conocimiento, la inteligencia artificial
y los sistemas de computacin en general

Los OOPLs tienen sus races en el lenguaje SIMULA y SAMLLTALK

Sistemas gestores de bases de datos OO
Prototipos experimentales:
ORION, creado en MCC OpenOODB, de Texas Instrumensts,
IRIS, creado en los laboratorios Hewlett-Packard,
ODE, de ATT Bell Labs,
Proyecto ENCORE/ObServer de Brown University

Sistemas de bases de datos comerciales OO:
GEMSTONE/OPAL de ServioLogic,
ONTOS de Ontology,
Objectivity de Objectivity INC.
Versant de Versant Technologies,
ObjectStore de Object Desing
O2 de O2 Technology.

CONCEPTOS
clase agrupa la estructura de datos interna de un objeto.
tipos de datos abstractos oculta las estructuras de datos internas y
especifica todas las operaciones posibles que pueden aplicarse a un objeto, lo
que deriv en el concepto de encapsulamiento.
Envi de mensajes y Herencia.

Un objeto normalmente tiene dos componentes:
un estado (valor) y
un comportamiento (operaciones).

Objetos transitorios y persistentes
El Objeto, (cierto parecido con una variable de prog de LP), slo que
tendr normalmente una estructura de datos compleja y unas operaciones
especificas definidas por el programador.

Los objetos en un OOPL:
slo existen durante la ejecucin del programa, se denominan:
objetos transitorios.
Una BD00 puede extender la existencia de los objetos guardndolos
permanentemente, de modo que los objetos persisten ms all de la
terminacin del programa y pueden recuperarse y compartirse con
posterioridad con otros programas. La BD almacena:
objetos persistentes permanentemente en almacenamiento secundario,

BASE DE DATOS OO

Un objetivo de las bases de datos 00 es mantener una correspondencia directa
entre los objetos del mundo real y de la base de datos, para que los objetos
no pierdan su integridad e identidad, puedan identificarse fcilmente y pueda
trabajarse con ellos. Por tanto, las bases de datos 00 proporcionan un
identificador de objeto:
(OID, object identifier) generado por el sistema para cada objeto.
Objeto de complejidad arbitraria

Otra caracterstica de las bases de datos 00 es que los objetos pueden tener
una estructura de objeto de complejidad arbitraria a fin de contener toda
la informacin necesaria que describe el objeto.
La estructura interna de un objeto en los OOPLs incluye la especificacin de
variables de instancia, que almacenan los valores que definen el estado
interno del objeto.
Las variables de instancia tambin pueden ser de tipos de datos
arbitrariamente complejos.
Encapsulamiento

Los sistemas orientados a objetos permiten la definicin de las operaciones
(predefinidas) o funciones (comportamiento) que pueden aplicarse a los
objetos de un tipo concreto. Esto obliga a un encapsulamiento completo de
los objetos.

Para el encapsulamiento, una operacin se define en dos partes:
La primera parte, denominada firma (signatura) o interfaz de la operacin,
especifica el nombre de la operacin y los argumentos (o parmetros).
La segunda parte, denominada mtodo o cuerpo, especifica la implementacin
de la operacin.
Independencia de datos

Las operaciones se pueden invocar pasando un mensaje a un objeto, que
incluye el nombre de la operacin y los parmetros.
El objeto ejecuta despus el mtodo para esa operacin. Este
encapsulamiento permite modificar la estructura interna de un objeto, as
como la implementacin de sus operaciones, sin la necesidad de trastocar los
programas externos que invocan esas operaciones.
Por tanto, el encapsulamiento proporciona una forma de independencia de
datos y operacin
Herencia y Jerarquias de tipos y clases

Otros conceptos importantes en los sistemas 00 son la herencia y las
jerarquas de tipos y clases. Esto permite especificar nuevos tipos o clases
que heredan gran parte de su estructura y/u operaciones de los tipos o clases
anteriormente definidos. Esto facilita el desarrollo incremental de tipos de
datos de un sistema, y la reutilizacin de definiciones de tipo existentes a la
hora de crear nuevos tipos de objetos.

El estndar ODMG (object data management group) ha reconocido esta
necesidad y representa explcitamente las relaciones binarias a travs de un
par de referencias inversas (es decir, colocando los OIDs de los objetos
relacionados dentro de los propios objetos, y manteniendo la integridad
referencial
Polimorfismo

Otro concepto 00 es la sobrecarga del operador, que se refiere a la
posibilidad de que una operacin pueda aplicarse a diferentes tipos de
objetos.
En una situacin semejante, un nombre de operacin puede referirse a varias
implementaciones distintas, en funcin del tipo de objetos a los que se
aplique. Esta caracterstica tambin se conoce como polimorfismo del
operador.

Objeto, partes: estado (valor) y comportamiento (operaciones)
Un SBDOO proporciona una identidad nica a cada objeto independiente
almacenado en la base de datos, suele implementarse mediante un
identificador de objeto nico, generado por el sistema, un OID.
El valor de un OID no es visible para el usuario externo, sino que el sistema lo
utiliza a nivel interno para identificar cada objeto de manera nica, y para
crear y administrar las referencias entre objetos.
La principal propiedad de OID: ser inmutable, es decir, el valor de ste para
un objeto particular no cambia. Esto preserva la identidad del objeto del
mundo real que se est representando. Por tanto, un SBD00 debe disponer de
algn mecanismo de generacin de OIDs y conservacin de la propiedad de
inmutabilidad. Tambin es preferible que cada OID se utilice slo una vez;
esto es, aunque un objeto se elimine de la base de datos, su OID no se deber
asignar a otro objeto.
En algunos sistemas tambin es posible crear valores con estructura compleja
sin que se necesite el OID correspondiente

Estado del Objeto:constructores de tipo
En las bases de datos 00, el estado (valor actual) de un objeto complejo
puede construirse a partir de otros objetos (u otros valores) utilizando ciertos
constructores de tipos.
Una forma de representar dichos objetos es ver cada objeto como un tro
(i, c, v), donde i es el identificador de objeto (OID) nico, c es un constructor
de tipo (es decir, una identificacin de cmo se construye el estado del
objeto) y v es el estado del objeto
Tipos de constructores:
Bsicos: atom, tuple y set.
Coleccin: set, list, bag y array.

Si c = atom, el estado (valor) v es un valor atmico del dominio de valores bsicos soportado
por el sistema.
Si c = set, el estado v es un conjunto de identificadores de objetos {il, i2, ... , in}, que son
los OIDs de un conjunto de objetos.
Si c = tuple, el estado v es una tupla de la fonna <al :il, a2:i2, ... , an:in>, donde cada aj es
un nombre de atributo y cada j es un OID.
Si c = list, el valor v es una lista ordenada [il, i2, ... , in] de OIDs de objetos del mismo tipo.
Una lista se parece a un conjunto, excepto que los OIDs de una lista estn ordenados y, por
tanto, podemos referimos al primer, segundo o j-simo objeto de una lista.
Para c = array, el estado del objeto es un array unidimensional de identificadores de objetos.
La principal diferencia entre un array y una lista es que esta ltima puede tener una cantidad
arbitraria de elementos, mientras que un array normalmente tiene un tamao mximo.
La diferencia entre set y bagl4 es que todos los elementos de un conjunto deben ser nicos,
mientras que una bolsa puede tener elementos duplicados.
Un objeto complejo
Para representar objetos de la base de datos relacional utilizamos Constructores de Tipo, mediante un
tro (OID, constructor de tipo, estado) y los constructores de tipo disponibles son atom, set y tuple, (tambin
esta list, bag y array)
Para representar los identificadores de objeto nicos generados por el sistema. Vamos a considerar estos
objetos:
O1 = (i1, atom, Gdl')
O2 = (i2, atom, Tepic')
O3 = (i3, atom, Colima')
O4 = (i4, atom, 5)
O5 = Us, atom, 'Investigacin')
O6 = U6, atom, '22-05-1988')
O7 = (i7, set, {i1, i2, i3 })
O8 = (i8, tuple, <NombreDpto:i5, NmeroDpto:i4, Jefe:i9, Ubicaciones:i7, Empleados:il0,
Proyectos:i11>)
O9 = (i9' tuple, <Jefe:i12, FechalngresoDirector:i6>)
O10 = (i10, set, {i 12, i13, i14 })
0 11 = (il!, set {iIS ' i16, il7 })
012 = (i12, tuple, <Nombre:i18, Apellido1 :i19, Apellido2:i2o, Dni:i21 , """ Sueldo:i26,
Supervisor:i27, Dept:i28>)
*Tambin denominado nombre de variable de instancia en la terminologa OO *Tambin denominado
multiconjunto.
Objetos idnticos e iguales
Ejemplo, Supongamos que tenemos los objetos O1, O2, O3, O4, O5 Y O6:
O1 = (il, tuple, <a1:i4, a2 :i6>)
O2 = (i2, tuple, <a1 :i5, a2:i6>)
O3 = (i3, tuple, <a1:i4' a2: i6
O4 = (i4, atom, 10)
O5 = (i5, atom, 10)
O6 = (i6, atom, 20)
Los objetos 01 y 02 tienen estados de igualdad, puesto que sus estados a
nivel atmico son iguales, pero los valores se alcanzan a travs de los objetos
04 y Os distintos.
los estados de los objetos 01 y 0 3 son idnticos, aunque los propios objetos
no lo son porque tienen OIDs distintos.
Los estados de 04 y Os son idnticos, los objetos reales 04 y Os son iguales
pero no idnticos, porque tienen OIDs distintos.
Especificacin de los tipos de objeto EMPLEADO, FECHA Y DEPARTAMENTO
utilizando los constructores de tipo.

define type EMPLEADO
tuple (Nombre: string;
Apellid01: string;
Apellid02: string;
Dni: string;
FechaNac: DATE;
Direccin: string;
Sexo: char;
Sueldo: float;
Supervisor: EMPLEADO;
Dept: DEPARTAMENTO);

612
define type FECHA
tuple (Ao: integer; Mes: integer; Da:
integer; );

define type DEPARTAMENTO
tuple (NombreDpto: string;
NmeroDpto: integer;
Dire: tuple ( Director: EMPLEADO;
Fechalngreso: FECHA; );
Ubicaciones: set(string);
Empleados: set(EMPLEADO);
Proyectos: set(PROYECTO); );

Comportamiento de los objetos
a travs de operaciones de clase
Los conceptos de ocultacin de informacin y encapsulamiento pueden
aplicarse a los objetos de bases de datos.
El comportamiento de un tipo de objeto se basa en las operaciones que
pueden aplicarse externamente a los objetos de ese tipo.
La estructura interna del objeto est oculta, y el objeto slo es accesible
a travs de determinadas operaciones predefinidas.
Operaciones a utilizar:
Crear (insertar)
Destruir (eliminar) objetos
Actualizar el estado del objeto
Recuperar partes del estado del objeto
Aplicar algunos clculos
Operaciones de clase
En general, la implementacin de una operacin puede especificarse en
un lenguaje de programacin de propsito general que proporciona
flexibilidad y potencia en la definicin de operaciones.
En terminologa 00, En la Operacin:
la parte de interfaz de cada operacin se denomina firma, (que define el
nombre y los argumentos (parmetros) de cada operacin)
y la implementacin de la operacin se denomina mtodo. (se especifica
en PL de propsito general que proporciona flexibilidad y potencia en
la definicin)
Normalmente, un mtodo es invocado enviando un mensaje al objeto
para ejecutar el mtodo correspondiente.

Estructura del objeto

Para las aplicaciones de bases de datos, el requisito de que todos los objetos deben
estar completamente encapsulados es demasiado exigente.
Una forma de relajar este requisito es dividir la estructura de un objeto en atributos
visible y hidden (oculto) (variables de instancia).
Es posible acceder directamente a los atributos visibles para lectura mediante
operadores externos o con un lenguaje de consulta de alto nivel. Los atributos
ocultos de un objeto estn completamente encapsulados y slo se puede acceder a
ellos mediante operaciones predefinidas.
La mayora de los OODBMSs emplean lenguajes de consulta de alto nivel para
acceder a los atributos visibles.
Clase

El trmino clase se utiliza a menudo para referirse a la definicin de un tipo de
objeto, junto con las definiciones de las operaciones para ese objeto.
Para cada clase se declaran varias operaciones, y en la definicin de clase se
incluye la firma (interfaz) de cada operacin. Por otra parte, con un lenguaje de
programacin hay que definir un mtodo (implementacin) para cada operacin.
Las operaciones tpicas incluyen la operacin constructor de objeto, que se
utiliza para crear un objeto nuevo, y la operacin destructor, que se utiliza para
destruir un objeto. Tambin podemos declarar varias operaciones modificador de
objeto para modificar los estados (valores) de varios atributos de un objeto.
Operaciones adicionales pueden recuperar informacin sobre el objeto.
Adicin de operaciones a las definiciones de
EMPLEADO

define class EMPLEADO
type tuple ( Nombre: string; Apellido1:string; Apellido2: string;
Dni: string;
FechaNac:FECHA;
Direccin: string; Sexo: char; Sueldo: float;
Supervisor: EMPLEADO;
Dept: DEPARTAMENTO; );
operations edad: integer;
crear_emp: EMPLEADO;
destruir_emp: boolean;

pag608
Adicin de operaciones a las definiciones de
Departamento
define class DEPARTAMENTO
type tuple (NombreDpto: string;
NmeroDpto: integer;
Dire: tuple (Director: EMPLEADO; Fechalngreso: DATE; );
Ubicaciones: set(string);
Empleados: set(EMPLEADO);
Proyectos set(PROYECTO); );
operations num_empleados: integer;
crear_dept: DEPARTAMENTO;
destruir_dept: boolean;
asignar_emp(e: EMPLEADO): boolean;
(* aade un empleado al departamento *)
eliminar_emp(e: EMPLEADO): boolean;
(* elimina un empleado del departamento *)
end DEPARTAMENTO;
Declaraciones de vnculos inversos en ObjectStore

Declaraciones de clases en O2 para una parte de la
base de datos Universidad
Persistencia de objeto a travs de la
denominacin y la nocin de alcance

Un OODBMS se acopla con un OOPL, este se emplea para especificar las
implementaciones de mtodo, as como otro cdigo de aplicacin.

Un objeto se crea normalmente ejecutando un programa de aplicacin,
invocando la operacin del constructor de objeto. (objetos transitorios y
objetos persistentes)
pag614
Persistencia de objeto a travs de la
denominacin y la nocin de alcance
Mecanismo de denominacin:
Implica asignar a un objeto un nombre persistente nico con el que el
programa actual y otros programas pueden recuperarlo. Este nombre de
objeto persistente puede suministrarse mediante una sentencia u
operacin especfica del programa.
Mecanismo, nocin de alcance.
Este otro mecanismo funciona haciendo que el objeto sea alcanzable
desde algn objeto persistente. Se dice que un objeto B es alcanzable
desde un objeto A si una secuencia de referencias en el grfico del objeto
conduce desde el objeto A al objeto B. Por tanto, si el objeto B se hace
persistente, el objeto A tambin se hacen persistente.
Creacin de objetos persistentes mediante la denominacin y la nocin de alcance.
define class CONJUNTO_OPTO:
type set (DEPARTAMENTO);
operations agregar_dept(d: DEPARTAMENTO): boolean;
(* aade un departamento al objeto CONJUNTO_OPTO *)
eliminar_dept(d: DEPARTAMENTO): boolean;
(* elimina un departamento del objeto CONJUNTO_OPTO *)
crear_conjunto_dept: CONJUNTO_OPTO;
destruir_conjunto_dept: boolean;
end ConjuntoDept;

persistent name TODOS_DEPARTAMENTOS: CONJUNTO_OPTO;
(* TODOS_DEPARTAMENTOS es un objeto con nombre persistente de tipo CONJUNTO_OPTO *)

d:= crear_dept;
(* crea un objeto DEPARTAMENTO nuevo en la variable d *)

b:= TODOS_DEPARTAMENTOS.agregar_dept(d);
(* convierte a d en persistente aadindolo al conjunto persistente TODOS_DEPARTAMENTOS *) 616
Jerarquas de tipos y herencia

En las bases de datos 00, el sistema permite la definicin de nuevos tipos
basndose en otros tipos predefinidos, cargndolos en una jerarqua de tipos
(o clases).
Normalmente, un tipo se define asignndole un nombre de tipo y despus
definiendo varios atributos (variables de instancia) y operaciones (mtodos)
para ese tipo. En algunos casos, los atributos y las operaciones se denominan
en conjunto funciones, ya que los atributos se parecen a funciones sin
argumentos:
NOMBRE_TIPO: funcin, funcn, ... , funcin
Jerarquas de tipos y herencia

Por ejemplo, un tipo que describe las caractersticas de una PERSONA puede
definirse de este modo:

PERSONA: Nombre, Direcc, FechaNac, Edad, Dni
las funciones Nombre, Direcc, Dni y FechaNac pueden implementarse como
atributos almacenados, mientras que la funcin Edad puede implementarse como
un mtodo que calcula la Edad a partir del valor del atributo FechaNac y la fecha
actual.

Subtipos
El concepto de subtipo resulta de utilidad cuando el diseador o el usuario debe crear
un tipo nuevo parecido pero no idntico a un tipo definido ya existente.
El subtipo hereda entonces todas las funciones del tipo predefinido, al que
denominaremos supertipo. Por ejemplo, supongamos que queremos definir dos tipos
nuevos,
EMPLEADO Y ESTUDIANTE, de este modo:
EMPLEADO: Nombre, Direcc, FechaNac, Edad, Dni, Sueldo, FechaContrato,
TiempoEnLaEmpresa
ESTUDIANTE: Nombre, Direcc, FechaNac, Edad, Dni, Especialidad, NotaMedia
Como ESTUDIANTE y EMPLEADO incluyen todas las funciones definidas para
PERSONA, ms algunas funciones adicionales propias, podemos declararlas como
subtipos de PERSONA:
EMPLEADO subtipo-de PERSONA: Sueldo, FechaContrato, TiempoEnLaEmpresa
ESTUDIANTE subtipo-de PERSONA: Especialidad, NotaMedia
Subtipos
OBJETO_GEOMTRICO: Forma, rea, PuntoReferencia
RECTNGULO subtipo-de OBJETO_GEOMTRICO: Anchura, Altura
TRINGULO subtipo-de OBJETO_GEOMTRICO: Lado1, Lado2, ngulo
CRCULO subtipo-de OBJETO_GEOMTRICO: Radio

La operacin rea puede implementarse con un mtodo diferente para cada
subtipo, puesto que el procedimiento para calcular el rea es diferente para los
rectngulos, los tringulos y los crculos. De forma parecida, el atributo Punto
Referencia puede tener un significado diferente para cada subtipo; puede ser el
punto central de los objetos RECTNGULO y CRCULO, Y el vrtice entre dos
lados dados de un objeto TRINGULO. Algunos sistemas de bases de datos 00
permiten renombrar las funciones heredadas en subtipos diferentes para reflejar
el significado de un modo ms exacto.
Restricciones en las extensiones correspondientes
a una jerarqua de tipos

En la mayora de las bases de datos 00, la coleccin de datos de una extensin
(extent) tiene el mismo tipo o clase. Sin embargo, no es una condicin necesaria.
Por ejemplo, Smalltalk, un lenguaje denominado lenguaje 00 typeless (sin tipo),
permite una coleccin de objetos que contiene objetos de diferentes tipos.
Es comn en las aplicaciones de bases de datos que cada tipo o subtipo tenga una
extensin asociada, que alberga la coleccin de todos los objetos persistentes de
ese tipo o subtipo. la restriccin es que cada objeto de una extensin que
corresponde a un subtipo tambin debe ser miembro de la extensin que
corresponde a su subtipo. Algunos sistemas de bases de datos 00 tienen un tipo
de sistema predefinido (denominado clase ROOT [raz] o clase OBJECT [objeto])
cuya extensin contiene todos los objetos del sistema.

Restricciones en las extensiones correspondientes
a una jerarqua de tipos
La clasificacin procede entonces asignando objetos en los subtipos adicionales
que son significativos para la aplicacin, creando una jerarqua de tipos o de
clases para el sistema. Todas las extensiones para el sistema y las clases definidas
por el usuario son subconjuntos de la extensin que corresponde a la clase
OBJECT, directa o indirectamente.
En el modelo ODMG el usuario puede o no especificar una extensin para cada
clase (tipo), dependiendo de la aplicacin y distingue entre herencia de tipo
(denominada herencia de interfaz e indicada mediante dos puntos [:]) y la
restriccin de herencia de extensin (indicada por la palabra clave EXTEND).
Objetos complejos

Objetos complejos: estructurados y no estructurados.
Un objeto complejo estructurado est formado por componentes y se define
aplicando los constructores de tipo disponibles recursivamente a varios
niveles.
Un objeto complejo no estructurado normalmente es un tipo de datos que
requiere una gran cantidad de almacenamiento, como el tipo de datos que
representa una imagen o un objeto de texto grande.
Objetos complejos no estructurados
La caracterstica de objeto complejo no estructurado proporcionada por un
DBMS permite almacenar y recuperar los objetos grandes que la aplicacin de
bases de datos necesita.

Ejemplos tpicos de estos objetos:
Las imgenes de mapas de bits (bitmaps) tambin se conocen como objetos
binarios grandes (BLOBs, binary large objects).
Las cadenas de texto largas (documentos); las cadenas de caracteres tambin
se denominan objetos grandes de caracteres (CLOBs, character large
objects).
DBMS

El DBMS no conoce su estructura (slo la aplicacin que los utiliza puede
interpretar su significado). Por ejemplo, la aplicacin puede tener funciones
para visualizar una imagen o para buscar por determinadas palabras clave o
detectar frases o prrafos en una cadena de texto larga.
El DBMS tambin utiliza las tcnicas de almacenamiento en bfer y en cach
para recopilar las porciones del objeto antes de que el programa de
aplicacin tenga necesidad de acceder a l.

OODBMS

El software DBMS no tiene la capacidad de procesar directamente las
condiciones de seleccin y otras operaciones basadas en los valores de esos
objetos, a menos que la aplicacin proporcione el cdigo para efectuar las
operaciones de comparacin de la seleccin.
En un OODBMS, esto puede realizarse definiendo un nuevo tipo de datos
abstractos y proporcionando los mtodos para seleccionar, comparar y
visualizar dichos objetos.

Objetos complejos estructurados
Un objeto complejo estructurado difiere de uno no estructurado en que su
estructura est definida por la aplicacin repetida de los constructores de tipos
suministrados por el OODBMS.
Entre un objeto complejo y sus componentes en cada nivel, existen dos
tipos de semntica de referencia:
Semntica de propiedad, se aplica cuando los subobjetos de un
objeto complejo se encapsulan dentro del objeto complejo y se
consideran, por tanto, parte de ese objeto complejo. El nombre de
relacin es-parte-de o es-componente-de;
Semntica de referencia, se aplica cuando los componentes del
objeto complejo son objetos independientes pero es posible hacer
referencia a ellos desde el objeto complejo. El nombre de la relacin
est-asociada-con,
La relacin es-parte-de (semntica de propiedad) para la construccin de objetos
complejos tiene la propiedad de que los objetos constituyentes se encapsulan dentro
del objeto complejo y se consideran como parte del estado del objeto interno. No
necesitan tener identificadores de objeto y slo los mtodos de ese objeto pueden
acceder a ellos. Desaparecen si el propio objeto se elimina.

Por el contrario, los componentes referenciados son considerados como objetos
independientes que pueden tener su propia identidad y mtodos. Cuando un objeto
complejo tiene que acceder a sus componentes referenciados, lo hace invocando los
mtodos apropiados de los componentes, ya que no estn encapsulados dentro del
objeto complejo. Por tanto, la semntica de referencia representa las relaciones
entre objetos independientes.

Adems, un objeto componente referenciado puede ser referenciado por ms de un
objeto complejo y, por consiguiente, no se elimina automticamente cuando se
elimina el objeto complejo.


Un OODBMS debe proporcionar opciones de almacenamiento para agrupar
juntos los objetos constituyentes de un objeto complejo en el
almacenamiento secundario, a fin de aumentar la eficacia de las operaciones
que acceden al objeto complejo.
En muchos casos, la estructura del objeto se almacena en pginas de disco
de una forma no interpretada. Cuando una pgina de disco que incluye un
objeto se recupera en la memoria, el OODBMS puede construir el objeto
complejo estructurado a partir de la informacin de las pginas de disco, que
puede referirse a pginas de disco adicionales que tambin deben
recuperarse, Es lo que se conoce como ensamblaje de objeto complejo
Polimorfismo
(sobrecarga del operador)
Otra caracterstica de los sistemas 00 es que proporcionan el polimorfismo de
operaciones, que tambin se conoce como sobrecarga del operador. Este
concepto permite que se vincule el mismo nombre de operador o smbolo a
dos o ms implementaciones diferentes del operador, dependiendo del tipo de
objetos a los que se aplique ese operador. Un ejemplo:
El operador "+puede significar cosas diferentes cuando se aplica a operandos
(objetos) de distintos tipos:
Si los operandos de "+" son de tipo entero, la operacin invocada es una suma
de enteros.
Si los operandos de "+" son de tipo conjunto, la operacin invocada es una unin
de conjuntos.

621
Polimorfismo
En las bases de datos 00 puede darse una situacin parecida. Para ilustrar el
polimorfismo de peracin en las bases de datos OO. Supongamos que
declaramos OBJETO_GEOMTRICO y sus subtipos de este modo:
OBJETO_GEOMTRICO: Forma, rea, PuntoReferencia
RECTNGULO subtipo-de OBJETO_GEOMTRICO (Forma='rectngulo'):
Anchura, Altura
TRINGULO subtipo-de OBJETO_GEOMTRICO (Forma='tringulo'): lado1,
lado2, ngulo
CRCULO subtipo-de OBJETO_GEOMTRICO (Forma='crculo'): Radio

Aqu, la funcin rea est declarada para todos los objetos de tipo
OBJETO_GEOMTRICO. No obstante, la implementacin del mtodo para rea
puede ser distinto para cada subtipo de OBJETO_GEOMTRICO.
Herencia mltiple y herencia selectiva
La herencia mltiple en una jerarqua de tipos se da cuando un determinado
subtipo T es un subtipo de dos (o ms) tipos y, por tanto, hereda las funciones
(atributos y mtodos) de los tipos
Un problema que puede surgir con la herencia mltiple es que los supertipos
de los que el subtipo hereda pueden tener funciones distintas con el mismo
nombre, crendose ambigedad en dos supertipos.
tcnicas para tratar la ambigedad:
Una solucin es que el sistema compruebe si hay ambigedad en el momento de
crear el subtipo, y dejar que el usuario seleccione explcitamente en ese
momento la funcin que se heredar.
Una segunda solucin es utilizar alguna seleccin predeterminada del sistema.
La tercera solucin es prohibir completamente la herencia mltiple si se
produce una ambigedad de nombre, en lugar de obligar al usuario a cambiar el
nombre de una de las funciones en uno de los supertipos.
Herencia mltiple y herencia selectiva
La herencia selectiva se produce cuando un subtipo slo hereda alguna de las
funciones de un supertipo. Otras funciones no se heredan. En este caso,
podemos utilizar una clusula EXCEPT para listar las funciones en un supertipo
que no sern heredadas por el subtipo.

Normalmente no se suministra el mecanismo de herencia selectiva en los
sistemas de bases de datos 00, pero se utiliza con frecuencia en las
aplicaciones de inteligencia artificial
Modelo de objeto del ODMG
Un consorcio de fabricantes de ODBMS, denominado ODMG (Object Data Management Group),
propuso un estndar que se conoce como ODMG-93 o estndar ODMG 1.0. El modelo de objeto
ODMG es el modelo de datos en el que estn basados el lenguaje de definicin de objetos
(ODL) y el lenguaje de consulta de objetos (OQL).
Este modelo de objeto proporciona los tipos de datos, constructores de tipos y otros
conceptos que pueden utilizarse en el ODL para especificar los esquemas de la base de datos
de objetos.
ODL est diseado para dar soporte a las construcciones semnticas del modelo de objeto
ODMG y es independiente de cualquier otro lenguaje de programacin. Se utiliza
principalmente para crear especificaciones de objetos (es decir, clases e interfaces), Por
tanto, ODL no es un lenguaje de programacin completo.
Un usuario puede especificar en ODL un esquema de base de datos
independientemente de cualquier lenguaje de programacin, y despus utilizar las
vinculaciones con lenguajes concretos para especificar cmo pueden asignarse las
construcciones de ODL a las construcciones de esos lenguajes de programacin
concretos, como C++, Smalltalk y Java.
El modelo ODMG utiliza un posible conjunto de definiciones de clases ODL, en el
ejemplo para la base de datos UNIVERSIDAD, los tipos de entidad son mapeados en
clases ODL, y la herencia se realiza con EXTENDS. Sin embargo, no hay una forma
directa de mapear categoras (tipos de unin) o de conseguir la herencia mltiple.
Ejemplo de un esquema de base de datos. (Universidad pag 121 y 124)
(a) Notacin grfica para representar los esquemas ODL.
(a)
Interfaz
Clase
Relaciones 1:1 1:N M:N
Herencia .. (Pag 639)

(b) Esquema grfico de base de datos de objetos para parte de la base de datos
UNIVERSIDAD
(no se muestran las clases NOTA y TTULO).

(b) diagrama ODL. (pag 639) pag 117 db aeropuerto
Si-Persona
Estudiante
Posible esquema ODL para la base de datos UNIVERSIDAD de la Figura anterior (b).
class PERSONA
( extent PERSONAS
key Dni)
{ attribute struct NomPers { string NombreP,
string Apellido1,
string Apellido2 } Nombre;
attribute string Dni;
attribute date FechaNac;
attribute enum Gnero{H, M} Sexo;
attribute struct Direccin { short No,
string Calle,
short NApt,
string Ciudad,
string Prov,
short CP} Direccin;
short EdadO; }; (ejem pag 640)
El lenguaje de consulta de objetos OQL:
El lenguaje de consulta de objetos (OQL) es el lenguaje de consulta propuesto
por el modelo de objeto ODMG. Est diseado para trabajar estrechamente
con los lenguajes de programacin para los que se ha definido una vinculacin
ODMG, como C++, Smalltalk y Java.

Las implementaciones de las operaciones de clase en un esquema ODMG
pueden tener su propio cdigo escrito en dichos lenguajes de programacin.
La sintaxis de OQL para las consultas es parecida a la sintaxis del lenguaje de
consulta estndar (SQL) relacional, con algunas caractersticas aadidas para
los conceptos ODMG, como la identidad de objeto, los objetos complejos, las
operaciones, la herencia, el polimorfismo y las relaciones.
Consultas OQL
La sintaxis bsica de OQL es una estructura select ... from ... where ... ,
como en SQL.
Por ejemplo, la consulta para recuperar los nombres de todos los departamentos
de la universidad de ingeniera se puede escribir de este modo:
co: select O.NombreDpto
from O in DEPARTAMENTOS
where O.Facultad = 'Ingeniera';

Tarea pasos para Mapeado de un esquema EER a un esquema ODB pag (648)
653

El modelo de datos de red y
el sistema IDMS
Modelo de datos de Red
Las estructuras y construcciones del lenguaje para el modelo de red fueron
definidas por el comit C O D A S Y L (Conference on Data Systems Languages:
Conferencia sobre lenguajes para sistemas de datos), por lo que suele
denominrsele modelo de red C O D A S Y L .

El modelo y el lenguaje de red originales se dieron a conocer en el informe de
1971 del Data Base Task Group (Grupo de trabajo sobre bases de datos) de
C O D A S Y L [DBTG1971]; esto es lo que se conoce como modelo D B T G .
Estructuras de datos bsicas:
Registros: consiste en un grupo de valores de datos relacionados entre s.
Se clasifican en tipos de registros:
Un tipo de registros propietario.
Un tipo de registros miembro.
Conjuntos: es una descripcin de un vnculo 1:N entre dos tipos de registros.
Cada definicin de tipo de conjuntos consta de tres elementos bsicos:
Un nombre para el tipo de conjuntos.
Un tipo de registros propietario.
Un tipo de registros miembro.

Representaciones de conjuntos

Representacin de lista circular con doble enlace:
Representacin de apuntador al propietario: (lista enlazada o lista doblemente
enlazada). Para cada tipo de conjuntos, se incluye un apuntador PROPIETARIO adicional en el tipo de
registros miembro que apunta directamente al registro propietario del conjunto.
Registros miembro contiguos: los registros miembro se colocan en posiciones
fsicamente contiguas, casi siempre en seguida del registro propietario.
Arreglos de apuntadores: Un arreglo de apuntadores se almacena junto con el registro propietario.
Esto suele implementarse junto con el apuntador al propietario.
Representacin indizada:
Vnculos M:N
El mtodo correcto para representar un vnculo M : N en el modelo de red es
utilizar dos tipos de conjuntos y un tipo de registros adicionales. Este tipo de
registros adicional TRABAJA_EN, en nuestro ejemplo se llama tipo de
registros de enlace (o ficticio).

Cada registro del tipo de registros TRABAJA_EN debe ser propiedad de un
registro EMPLEADO a travs del conjunto E_T y de un registro PROYECTO a
travs del conjunto P_T, y sirve para relacionar estos dos registros propietario
Cuatro ejemlares Tipo de Conjunto Depto-Carrera

EL MODELO DE DATOS DE RED Y EL
SISTEMA IDMS

Representacin de algunas ocurrencias de un vnculo M : N con "ocurrencias enlazadas

Algunas ocurrencias de los tipos de conjuntos E_T y P_T y del tipo de registros de enlace TRABAJA_EN
correspondientes a los ejemplares del vnculo M : N
Opciones de insercin y retencin en conjuntos
En la terminologa CODASYL, las restricciones u opciones de insercin sobre la
pertenencia a conjuntos especifican lo que sucede cuando se insertan en la
base de datos un registro nuevo que es de tipo de registros miembro.
Los registros se insertan con la orden STORE, hay dos opciones de insercin:
AUTOMATIC y MANUAL

En la terminologa CODASYL, las restricciones u opciones de retencin
especifican si un registro de un tipo de registros miembro puede existir en la
base de datos por si solo o si siempre debe estar relacionado con un
propietario como miembro de algn ejemplar de conjunto.
Hay tres opciones de retencin:
OPTIONAL, MANDATORY y FIXED
Opciones (restricciones) de insercin en conjuntos :
AUTOMATIC: El nuevo registro miembro se conecta automticamente a una ocurrencia
de conjunto apropiada cuando se inserta el registro.
MANUAL: El nuevo registro no se conecta a ninguna ocurrencia de conjunto. Si el
programador lo desea, puede conectar despus explcitamente (manualmente) el
registro a una ocurrencia de conjunto, mediante la orden CONNECT
Opciones (restricciones) de retencin en conjuntos :
OPTIONAL (opcional): Un registro miembro puede existir por s solo sin ser miembro de
ninguna ocurrencia del conjunto. Se le puede conectar y desconectar de las ocurrencias
de conjunto a voluntad con las rdenes CONNECT y DISCONNECT del DML de red (vase la
Sec. 10.5.4).
MANDATORY (obligatoria): Ningn registro miembro puede existir por s solo; siempre
debe ser miembro de una ocurrencia de conjunto del tipo de conjuntos. Se le puede
reconectar en una sola operacin de una ocurrencia de conjunto a otra mediante la
orden RECONNECT del DML de red (vase la Sec. 10.5.4).
FIXED (fija): A l igual que en MANDATORY, ningn registro miembro puede existir por s
solo. Por aadidura, una vez insertado en una ocurrencia de conjunto, queda fijo; no se
le puede reconectar a otra ocurrencia de conjunto.

Ejemplos de insercion y retencin en conjuntos
AUTOMATIC FIXED: Tipo de conjunto DEPENDIENTES_EMP
AUTOMATIC MANDATORY: Tipo de conjunto DEPTO_EMP
MANUAL OPTIONAL:
Opciones de ordenamiento de conjuntos

Los registros miembro de un ejemplar de conjunto pueden estar ordenados de
diversas maneras. Las opciones de ordenamiento disponibles se pueden resumir
como sigue:
Ordenadas segn un campo de ordenamiento: Los valores de uno o ms campos del
registro miembro sirven para ordenar dichos registros dentro de cada ocurrencia de
conjunto en orden ascendente o descendente. El sistema mantiene el orden cuando se
conecta un nuevo registro miembro al ejemplar de conjunto insertando
automticamente el registro en su posicin correcta.
Orden por omisin del sistema: Un nuevo registro miembro se inserta en una posicin
arbitraria determinada por el sistema.
Primero o ltimo: Un nuevo registro miembro se convierte en el primero o en el ltimo
miembro de la ocurrencia de conjunto en el momento en que se inserta. Por tanto, esto
equivale a tener los registros miembro de un ejemplar de conjunto almacenados en
orden cronolgico (o cronolgico invertido).
Siguiente o previo: El nuevo registro miembro se inserta despus o antes del registro
actual de la ocurrencia de conjunto.
Las opciones deseadas en cuanto a insercin, retencin u ordenamiento se especifican
cuando se declara el tipo de conjuntos en el lenguaje de definicin de datos DDL de red
Lenguajes DDL y y DML de red
Despus de disear un esquema de base de datos de red, debemos declarar al
SGBD todos los tipos de registros, tipos de conjuntos, definiciones de
elementos de informacin y restricciones del esquema. Para ello, usamos el
DDL de red.
Cada SGBD de red tiene una sintaxis un tanto distinta y opciones con
pequeas diferencias en su DDL.

El DML de red permite acceder a los registros de la BD de red.
__________________________________________
Empleado

proyecto
NombP NumP localiz
Esquema de red para la base de datos COMPAA.
Declaraciones de tipos de registros y de
elementos de informacin:
SCHEMA NAME IS COMPAA
RECORD NAME IS EMPLEADO
DUPLICATES ARE NOT ALLOWED FOR NSS
DUPLICATES ARE NOT ALLOWED FOR NOMBREP, INIC, APELLIDO
N O M B R E P TYPE IS CHARACTER 15
INIC TYPE IS CHARACTER 1
APELLIDO TYPE IS CHARACTER 15
NSS TYPE IS CHARACTER 9
FECHANAC TYPE IS CHARACTER 9
DIRECCIN TYPE IS CHARACTER 30
SEXO TYPE IS CHARACTER 1
SALARIO TYPE IS CHARACTER 10
NOMBREDEPTO TYPE IS CHARACTER 15

RECORD NAME I S DEPARTAMENTO
DUPLICATES ARE NOT ALLOWED FOR NOMBRE
DUPLICATES ARE NOT ALLOWE D FOR NMERO
NOMBRE TYPE IS CHARACTER 15
NMERO TYPE IS NUMERIC INTEGER
LUGARES TYPE IS CHARACTER 1 5 VECTOR
INICGTE TYPE IS CHARACTER 9

RECORD NAME IS PROYECTO
DUPLICATES ARE NOT ALLOWED FOR NOMBRE
DUPLICATES ARE NOT ALLOWED FOR NUMERO
NUMERO TYPE IS NUMERIC INTEGER
LUGAR TYPE IS CHARACTER 15

RECORD NAME IS TRABAJA_EN
DUPLICATES ARE NOT ALLOWED FOR NSSE, NUMEROP
NSSE TYPE IS CHARACTER 9
NUMEROP TYPE IS NUMERIC INTEGER
HORAS TYPE IS NUMERIC (4,1)

RECORD NAME IS SUPERVISOR
DUPLICATES ARE NOT ALLOWED FOR NSS_SUPERVISOR
NSS.SUPERVISOR TYPE IS CHARACTER 9

RECORD NAME IS DEPENDIENTE
DUPLICATES ARE NOT ALLOWED FOR NSSEMP, NOMBRE
NSSEMP TYPE IS CHARACTER 9
SEXO TYPE IS CHARACTER 1
FECHANAC TYPE IS CHARACTER 9
PARENTESCO TYPE IS CHARACTER 10

Declaraciones de tipos de conjuntos
para el esquema
SET NAME IS TODOS_DEPTOS
OWNER IS SYSTEM
ORDER IS SORTED BY DEFINED KEYS
MEMBER IS DEPARTAMENTO
KEY IS ASCENDING NOMBRE

SET NAME IS PERTENECE_A
OWNER IS DEPARTAMENTO
MEMBER IS EMPLEADO
INSERTION IS MANUAL
RETENTION IS OPTIONAL
KEY IS ASCENDING APELLIDO, NOMBREP, INIC
CHECK IS NOMBREDEPTO IN EMPLEADO = NOMBRE IN
DEPARTAMENTO

SET NAME IS CONTROLA
OWNER IS DEPARTAMENTO
MEMBER IS PROYECTO
INSERTION IS AUTOMATIC
RETENTION IS MANDATORY
SET SELECTION IS BY APPLICATION

SET NAME IS DIRIGE
OWNER IS EMPLEADO
ORDER IS SYSTEM DEFAULT
MEMBER IS DEPARTAMENTO
SET SELECTION IS BY APPLICATION

SET NAME IS P_TRABAJAEN
OWNER IS PROYECTO
DUPLICATES ARE NOT ALLOWED
MEMBER IS TRABAJA_EN
I NSERTION IS AUTOMATIC
RETENTION IS FIXED
KEY IS NSSE
SET SELECTION IS STRUCTURAL NMERO IN
PROYECTO = NUMEROP IN TRABAJA_EN

SET NAME IS E_TRABAJAEN
OWNER IS EMPLEADO
MEMBER IS TRABAJA_EN
RETENTION IS FIXED
KEY IS NUMEROP
SET SELECTION IS STRUCTURAL NSS IN EMPLEADO = NSSE IN
TRABAJA.EN

Declaraciones de tipos de conjuntos
para el esquema
SET NAME IS SUPERVISADOS
OWNER IS SUPERVISOR
ORDER IS BY DEFINED KEY
MEMBER IS EMPLEADO
INSERTION IS MANUAL
RETENTION IS OPTIONAL
KEY IS APELLIDO, INIC, NOMBREP

SET NAME IS ES_SUPERVISOR
OWNER IS EMPLEADO
MEMBER IS SUPERVISOR
KEY IS NSS_SUPERVISOR
SET SELECTION IS BY VALUE OF NSS IN EMPLEADO
CHECK IS NSS_SUPERVISOR IN SUPERVISOR = NSS IN EMPLEADO

Pag 167
Actividad de clase: definicin de cada mtodo de seleccin de conjunto.
SET NAME IS DEPENDIENTESJDE
OWNER IS EMPLEADO
ORDER IS BY DEFINED KEY
MEMBER IS DEPENDIENTE
RETENTION IS FIXED
SET SELECTION IS STRUCTURAL NSS IN EMPLEADO = NSSEMP
IN DEPENDIENTE

PAG 167
TAREA PASOS PARA TRANSFORMAR DER A BD DE RED
Declaraciones de tipos de conjuntos y opciones de
seleccin de conjuntos:
Las declaraciones en DDL de red para los tipos de conjuntos del esquema COMPAA
(anteriores), son complejas que las declaraciones de tipo de registros, porque hay ms
opciones disponibles.
Cada tipo de conjunto se nombra con la clusula SET NAME IS (el nombre del conjunto
es). Las opciones (restricciones) de insercin y retencin se especifican para cada tipo
de conjunto mediante la clusula INSERTION IS (la insercin es) y RETENTION IS
(la retencin es).
Si la opcin de insercin es AUTOMATIC, tambin debemos especificar la forma en que
el sistema seleccionar automticamente una ocurrencia de conjunto a la cual
conectar un nuevo registro miembro cuando ste se inserte en la base de datos. La
clusula SET SELECTION (seleccin de conjunto) sirve para este fin. Tres mtodos
comunes de especificar la seleccin de conjunto son:
SET SELECTION IS STRUCTURAL
SET SELECTION IS BY APLICATION
SET SELECTION IS BY VALUE OF <nombre de campo> IN <nombre de tipo de registros>
Ordenes DML de Red:

Ordenes de DML para localizar registros de un tipo de registros:
FIND ANY <nombre tipo reg> [USING <lista campos>]
FIND DUPLICATE <nombre tipo reg> [USING <lista campos>]
Ejemplo: deseamos leer el reg EMPLEADO correspondiente adl emp llamado Jose
Silva e imprimir su salario:
EMPLEADO.NOMBRE := Jose; EMPLEADO.APELLIDO:=Silva';
$FIND ANY EMPLEADO USING NOMBREP,APELLIDO;
If DB_STATUS = 0
the begin
$GET EMPLEADO;
writeln(EMPLEADO.SALARIO)
end
else writeln(no se hallo el registro); PAG 73
El modelo de datos jerrquico y el
sistema IMS
sistema IMS

El modelo jerrquico de los datos se creo con el fin de modelar la gran
cantidad de tipos de organizaciones jerrquicas que existen en el mundo real-

Las BD Jerrquicas, empleaban estructuras de almacenamiento jerrquicas,
ejemplos de sistemas:
El Multi-Access Retrieval System ( MARS VI) de Control Data Corporation,
El Information Management System (IMS) de I BM y el System-2000 de MRI (ahora
comercializado por SAS Institute).

El modelo de datos jerrquico y el sistema
IMS
Estructuras de Datos Bsicas:
Registro. Un Registro es una coleccin de valores de campos que proporcionan informacin sobre
una entidad o un ejemplar de vnculo.
Tipos de Registros: R Padre y R Hijo
Vnculos padre-hijo, Un tipo de vnculos padre^hijo (tipo de VPH) es un vnculo 1:N entre dos
tipos de registros. El tipo de registros del lado 1 se denomina tipo de registros padre, y el del lado
N se llama tipo de registros hijo del tipo de VPH.
sistema IMS
Una ocurrencia (o ejemplar) del tipo de VPH consiste en un registro del tipo
de registros padre y varios registros (cero o ms) del tipo de registros hijo.

Un esquema jerrquico, se visualizan como diagramas jerrquicos, los
nombres de los tipos de registros aparecen en cuadros rectangulares y los
tipos de VPH se dibujan como lneas que conectan el tipo de reg padre y el
tipo de regs hijo.
En esquemas jerrquicos haremos referencia a un tipo de VPH con el par
(tipo reg padre, tipo regs hijo) entre parntesis: (DEPARTAMENTO, EMPLEADO)
y (DEPARTAMENTO, PROYECTO)
El modelo de datos jerrquico y el sistema
IMS
Departamento
NumD NombD Jefe FechingJ
Proyecto
NombreP NumP lugarP
Empleado
NSS Nombre FechN Dir
Dependiente
Nombr Sexo FechN
Supervisadodo
Nombre NSS
Trabajador
Nombre NSS Hrs
D
N
P
E
S
T
Esquema jerrquico de una parte de la base de datos COMPAA
Nivel 1
Nivel 2
Nivel 3
Propiedades de los esquemas jerrquicos

Un esquema jerrquico de tipos de registros y tipos de VPH debe tener las
siguientes propiedades:

1. Un tipo de registros, la raz del esquema jerrquico, no participa como tipo
de registros hijo en ningn tipo de VPH.
2. Todo tipo de registros, con excepcin de la raz, participa como tipo de
registros hijo en uno y slo un tipo de VPH.
3. Un tipo de registros puede participar como tipo de registros padre en
cualquier cantidad (cero o ms) de tipos de VPH.
4. Un tipo de registros que no participa como tipo de registros padre en
ningn tipo de VPH se denomina hoja del esquema jerrquico.
5. Si un tipo de registros participa como padre en ms de un tipo de VPH,
entonces sus tipos de registros hijo estn ordenados E l orden se visualiza, por
convencin, de izquierda a derecha en los diagramas jerrquicos.
Ocurrencias de tipos de VPH

Ocurrencias de tipos de VPH:
(a) Dos ocurrencias del tipo de VPH (DEPARTAMENTO, EMPLEADO),
(b) Dos ocurrencias del tipo de VPH (DEPARTAMENTO, PROYECTO).

(a) DEPARTAMENTO: Investigacin Administracin

EMPLEADO: S'lva Vizcarra Nieto Esparza Zapata Valds Jabbar

(b) DEPARTAMENTO: Investigacin Administracin

PROYECTO: ProductoX ProductoY ProductoZ Automatizacin Nuevasprestaciones

La definicin de esquema jerrquico define una estructura de datos
de rbol. En la terminologa de estas estructuras, un tipo de registros
corresponde a un nodo del rbol, y un tipo de VPH corresponde a una
arista (o arco) del rbol.

Las propiedades antes identificadas tambin limitan los tipos de vnculos que
se pueden representar en un esquema jerrquico. E n particular, los vnculos
M : N no pueden representarse directamente porque los vnculos padre-hijo
son 1 : N , y u n tipo de registros no puede participar como hijo en dos o ms
vnculos padre-hijo distintos.


EJEMPLO 1: Consideremos los siguientes ejemplares del vnculo EMPLEADO:PROYECTO:
Proyecto Empleados que trabajan en el proyecto
A El, E3, E5
B E2, E4, E6
C El, E4
D E2, E3, E4, E5

Representacin de rbol del esquema jerrquico.
Arboles de ocurrencia
Ocurrencia jerrquica (rbol de ocurrrencia) del esquema jerrquico:
nivel 0: D Administracin
nivel 2: N Abdiel S Zapata S Jabbar T Vizcarra T Zapata T Jabbar T Zapata T Valds T Jabbar
Forma linealizada de una ocurrencia
jerrquica
Una de las estructuras de almacenamiento ms simples que podemos usar es el registro jerrquico: u n
ordenamiento lineal de los registros en u n rbol de ocurrencia en el recorrido en preorden del rbol. Este
orden produce una secuencia de ocurrencias de registros denominada secuencia jerrquica (o secuencia
jerrquica de registros) del rbol de ocurrencia:
D Administracin
E Zapata
E Valds
[~N Abdiel
S Zapata
S Jabbar
E Jabbar
P Automatizacin
T Vizcarra
T Zapata
T Jabbar
P Nuevasprestaciones
[~~ T Zapata
T Valds
T Jabbar
Figura 11,7 Secuencia jerrquica del rbol de ocurrencia
Vnculos Padre-Hijo virtuales

En la siguiente figura muestra esquema DB jerrquica para la base de datos
COMPAA usando algunos VPHV y sin redundancia en sus ocurrencias de
registros. El esquema de base de datos se compone de dos esquemas
jerrquicos: uno con DEPARTAMENTO como raz y el otro con EMPLEADO como
raz. Se incluyen cuatro VPHV, todos con EMPLEADO como padre virtual, para
representar los vnculos sin redundancia.

Vnculo M : N
con VPHV (Vinculos Padre-Hijo virtuales)
Esquema jerrquico para la base de datos COMPAA, usando tipos de VPHV entre dos jerarquas para eliminar los
ejemplares de registros redundantes
Empleado
Nomb In Ape NSS FechN Dir Sexo Salario
Dependiente
NomP Sexo FecN Parentesco
Proyecto
NombP
NumP
LugD
TrabajadorP
Hrs ApuntT
Departamento
NombD NumD
GerenteD
FechG ApuntG
SupervisadosE
ApuntS
EmpleadosD
ApuntE
LugaresD
E D
L
Y
P
S
N
G
T
Jerarquia 1 Jerarquia 2
}
Restricciones de integridad en el modelo
jerrquico
1. Ninguna ocurrencia de registro, con excepcin de los registros raz, puede existir
si no est relacionada con una ocurrencia de registro padre. Esto tiene las siguientes
implicaciones:
a. Ningn registro hijo puede insertarse si no est enlazado a un registro padre.
b. Un registro hijo se puede eliminar independientemente de su padre; pero la eliminacin
de un padre causa automticamente la eliminacin de todos sus registros hijos y
descendientes.
c. Las reglas anteriores no se aplican a los registros hijo y padre virtuales. La regla en este
caso es que un apuntador en un registro hijo virtual debe apuntar a una ocurrencia real de
un registro padre virtual. No debe permitirse la eliminacin de un registro en tanto existan
apuntadores a l en registros hijo virtuales, lo que lo convierte en un registro padre virtual.
2. Si un registro hijo tiene dos o ms registros padre del mismo tipo de registros, el
registro hijo debe duplicarse una vez bajo cada registro padre.
3. Un registro hijo que tenga dos o ms registros padre de diferentes tipos de
registros slo puede tener un padre real; todos los dems deben representarse como
padres virtuales.
Otra regla en IMS es que un tipo de registros raz no puede ser un tipo de registros
hijo virtual en un tipo de VPHV.
Definicin de datos en el modelo jerrquico
(HDDL)
(HDDL: hierarchical data definition language). Debemos definir los campos de cada tipo de registros,
el tipo de datos de cada campo y cualesquier restricciones de clave sobre los campos. Adems,
debemos especificar un tipo de registros raz como tal; y para cada tipo de registros no raz, ser
preciso especificar su padre (real) en un tipo de VPH. Tambin tendremos que especificar todos los
VPHV.
SCHEMA NAME = COMPAA
HIERARCHIES = JERARQUA1, JERARQUA2

RECORD
NAME = EMPLEADO
TYPE = ROOT OF JERARQUA2
DATA ITEMS =
NOMBREP CHARACTER 15
INIC CHARACTER 1
APELLIDO CHARACTER 15
NSS CHARACTER 9
FECHAN CHARACTER 9
DIRECCIN CHARACTER 30
SEXO CHARACTER 1
SALARIO CHARACTER 10
KEY = NSS
ORDER BY APELLIDO, NOMBREP
RECORD
NAME = DEPARTAMENTO
TYPE = ROOT OF JERARQUA1
DATA ITEMS =
NOMBRED CHARACTER 15
NMEROD INTEGER
KEY = NOMBRED
KEY = NMEROD
ORDER BY NOMBRED

RECORD
NAME = LUGARESD
PARENT = DEPARTAMENTO
CHILD NUMBER = 1
DATA ITEMS =
LUGAR CHARACTER 15
Definicin de datos en el modelo jerrquico
(HDDL)
Declaraciones para el esquema jerrquico:

RECORD
NAME = GERENTED
CHILD NUMBER = 3
DATA ITEMS =
FECHAINICGTE CHARACTER 9
APUNTG POINTER WITH VIRTUAL PARENT = EMPLEADO

RECORD
NAME = PROYECTO
CHILD NUMBER = 4
DATA ITEMS =
NOMBREPR CHARACTER 15
NMEROP INTEGER
LUGARP CHARACTER 15
KEY = NOMBREPR
KEY = NMEROP
ORDER BY NOMBREPR

RECORD
NAME = TRABAJADORP
PARENT = PROYECTO
CHILD NUMBER = 1
DATA ITEMS =
HORAS CHARACTER 4
APUNTT POINTER WITH VIRTUAL PARENT = EMPLEADO

RECORD
NAME = EMPLEADOSD
CHILD NUMBER = 2
DATA ITEMS =
APUNTE POINTER WITH VIRTUAL PARENT = EMPLEADO

RECORD
NAME = SUPERVISADOSE
PARENT = EMPLEADO
CHILD NUMBER = 2
DATA ITEMS =
APUNTS POINTER WITH VIRTUAL PARENT = EMPLEADO
Lenguaje de manipulacin de datos
para el modelo jerrquico (HDML)
HDML (Hierarchical Data Manipulation Language: lenguaje de manipulacin de datos
jerrquicos), que es un lenguaje de registro por registro para manipular bases de datos
jerrquicas. Las rdenes del lenguaje deben estar incorporadas en un lenguaje de
programacin de aplicacin general, el denominado lenguaje anfitrin. Aunque lo ms comn
es que COBOL o PL/1 sean los lenguajes anfitriones, usaremos PASCAL en nuestros ejemplos
para mantener la congruencia.
Resumen de rdenes de HDML:
OBTENCIN DE DATOS
GET OBTENER U N REGISTRO, COLOCARLO EN LA VARIABLE DE PROGRAMA CORRESPONDIENTE Y
CONVERTIRLO EN EL REGISTRO ACTUAL . LAS VARIACIONES INCLUYEN GET FIRST, GET NEXT;
GET NEXT WITH IN PARENT Y GET PATH.
ACTUALIZACIN DE REGISTROS
INSERT ALMACENAR UN NUEVO REGISTRO EN LA BASE DE DATOS Y CONVERTIRLO EN EL REGISTRO
ACTUAL
DELETE ELIMINAR D E LA BASE DE DATOS E L REGISTRO ACTUAL (Y SU SUBRBOL)
REPLACE MODIFICAR ALGUNOS CAMPOS DEL REGISTRO ACTUAL
RETENCIN DE ACTUALIDAD GET HOLD OBTENER UN REGISTRO Y M A NTENERLO COMO
REGISTRO ACTUAL PARA PODERLO ELIMINAR O REEMPLAZAR POSTERIORMENTE. Pag 190
La orden G E T
(HDML)

GET FIRST <nombre de tipo de registros> [ WHERE <condicin> ]
GET NEXT <nombre de tipo de registros> [ WHERE <condicin> ]

Por ejemplo, para obtener todos los registros EMPLEADO de la base de datos,
podemos usar Ej3:

EJ3: $GET FIRST EMPLEADO;
while DB_STATUS = 0 do
begin
writeln (P_EMPLEADO.NOMBREP, P_EMPLEADO.APELLIDO);
$GET NEXT EMPLEADO
end;

buscar todos los registros de un tipo dado que tengan el mismo registro padre:
GET NEXT <nombre de tipo de registros hijo
WITHIN [ VIRTUAL ] PARENT [ <nombre de tipo de registros padre> ]+
[ WHERE <condicin> ]

Por ejemplo, si queremos obtener los nombres de
todos los proyectos controlados por el
departamento de investigacin, podemos escribir el
segmento de programa,:

EJ5: $GET FIRST PATH DEPARTAMENTO, PROYECTO
WHERE NOMBRED='lnvestigacin';
(* esto establece el registro DEPARTAMENTO de
'Investigacin' como padre actual del tipo DEPTO y
obtiene el primer registro PROY hijo bajo ese registro
DEPARTAMENTO *)
while DB.STATUS = 0 do
begin
writeln (P_PROYECTO.NOMBREPR);
$GET NEXT PROYECTO WITHIN PARENT
end;

La orden de HDML para obtener un registro es GET.
Esta orden tiene muchas variaciones; la estructura de dos de ellas es la siguiente, donde las partes opcionales
entre corchetes [...]:

Bases de Datos deductivas
Bases de Datos deductivas

En un sistema de bases de datos deductivas se suelen especificar las reglas
mediante un lenguaje declarativo (un lenguaje en el que se indica qu se
quiere conseguir en lugar de cmo hacerlo). Un motor de inferencia (o
mecanismo de deduccin) dentro del sistema puede deducir nuevos hechos
interpretando esas reglas.
El modelo que usa esta relacionado con el modelo de datos relacional y el
formalismo de calculo de dominios, con la lgica de la programacin y el
lenguaje Prolog y Datalog.

Pag 376 732
Hechos y Reglas
Base de datos deductiva utiliza: HECHOS y REGLAS .

Hechos, especificado igual a un relacin (pero sin incluir atributos) describe
algn hecho del mundo real significado determinado por los nombres de
atributo.

Reglas, algo parecido a las vistas .Especifican relaciones virtuales que no
estn almacenadas pero que pueden formarse a partir de los hechos aplicando
mecanismos de inferencia basados en las especificaciones de reglas.

Evaluacin en Prolog/Datalog

La evaluacin de los programas Prolog est basada en una tcnica llamada
encadenamiento hacia atrs (backward chaining), la cual implica una
evaluacin de objetivos de arriba hacia abajo.

En las bases de datos deductivas que usan Datalog, la atencin ha sido
consagrada a manipular grandes volmenes de datos almacenados en una
base de datos relacional. Por tanto, se han diseado tcnicas que las asemeja
a una evaluacin de abajo hacia arriba.

Tarea investigar encadenamiento hacia atrs y evaluacin de abajo hacia arriba
Notacin Prolog/Datalog
Notacin basada en proporcionar predicados con nombres nicos. Un predicado
tiene un significado implcito, el cual est sugerido por su nombre, y un nmero
fijo de argumentos, ste puede considerarse como una consulta o como parte de
una regla o una restriccin.
Valores constantes de un predicado representadas por identificadores (o nombres)
que empiezan con letras minsculas, mientras que los nombres de variables
siempre empiezan con una letra mayscula.

La principal contribucin de las bases de datos deductivas es la capacidad para
especificar reglas recursivas y para proporcionar un entorno de trabajo para la
deduccin de nueva informacin basada en las reglas especificadas.

Una regla tiene la forma cabecera :- cuerpo, donde los caracteres :- indican si y
slo si. Una regla tiene, por lo general, un nico predicado a la izquierda del
smbolo :- (llamado cabecera, LHS [lado izquierdo, Left-Hand Side] o conclusin
de la regla) y uno o ms predicados a su derecha (el cuerpo, RHS [lado derecho,
Right-Hand Side] o premisa(s) de la regla). Un predicado con constantes se dice
que es ground o de predicado instanciado
Operadores logicos
Una regla especifica que si una asignacin particular, o binding, de valores
constantes a las variables del cuerpo (predicados RHS) hace que todos estos
predicados RHS sean verdaderos, tambin hace verdadera la cabecera
(predicado LHS) usando la misma asignacin de valores constantes a las
variables.
Por consiguiente, una regla nos ofrece una forma de generar nuevos hechos
que son instanciaciones de la cabecera de dicha regla. Estos nuevos hechos
estn basados en otros que ya existen y que se corresponden con las
instanciaciones (o bindings) de predicados en el cuerpo de la regla.
El listado de mltiples predicados en el cuerpo de una regla supone aplicar
operadores logicos: OR (;) o AND (,)
Ejemplos, Hechos y Reglas
Los hechos se corresponden con los datos actuales almacenados en la base de
datos, y pueden ser considerados como constituyentes de un conjunto de
tuplas en una relacin SUPERVISAR con dos atributos cuyo esquema es:
supervisar(supervisor, supervisado)
Por tanto, supervisar(X, Y) indica el hecho de que X supervisa a Y.
Predicado superior, cuyo primer argumento es el nombre de un empleado,
mientras que el segundo es un empleado que puede ser un subordinado
directo o indirecto del primero. Por subordinado indirecto entendemos aquel
que depende de otro a cualquier nivel inferior. De esta manera, superor(X, Y)
especifica el hecho de que X es un superior de Y ya sea por supervisin
directa o indirecta.
Ejemplos, Hechos y Reglas
Podemos escribir dos reglas.
La primera de las reglas:
superior(X, Y) :- supervisar(X, Y).
Si el cuerpo es verdadero entonces la cabecera tambin lo es. Esta regla
puede emplearse para generar todas las relaciones superior/subordinado
directas a partir de los hechos que definen el predicado supervisar.
La segunda regla recursiva :
superior(X, Y) :- supervisar(X Z), superior(Z, Y).
Especifica que, si supervisar(X Z) y superior(Z, Y) son ambas verdaderas,
entonces superior(X, Y) tambin lo es. Ejemplo de regla recursiva, donde uno
de los predicados del cuerpo de la regla en el RHS es el mismo que el de la
cabecera en el LHS.
Reglas
En general, el cuerpo de la regla define un nmero de premisas como que, si
todas son verdaderas, podemos deducir que la conclusin en la cabecera de la
misma tambin lo es.

Tambin, cuando el cuerpo de la regla define un nmero de premisas como
que, si cualquiera de los cuerpos lo es, entonces la cabecera tambin lo es;
por tanto, es equivalente a una operacin lgica OR. Por ejemplo, si tenemos
estas dos reglas
(X:- Y, X:- Z), podemos deducir que son equivalentes a X :- Y OR Z.
Ejemplo
(a) Notacin Prolog.
(a) Hechos
SUPERVISAR(alberto, jos).
SUPERVISAR(alberto, fernando).
SUPERVISAR(alberto, aurora).
SUPERVISAR(Juana, alicia).
SUPERVISAR(Juana, luis).
SUPERVISAR(eduardo, alberto).
SUPERVISAR(eduardo, juana).

Reglas
SUPERIOR(X, Y) :- SUPERVISAR(X, Y).
SUPERIOR(X, Y) :- SUPERVISAR(X, Z), SUPERIOR(Z, Y).
SUBORDINADO(X, Y) :- SUPERIOR(Y, X)
(b) El rbol de supervisin.

(b) eduardo

alberto juana

Jos fernando aurora alicia luis
Consultas
SUPERIOR(eduardo, Y)?
SUPERIOR(eduardo, aurora)?
Consultas
Prolog contiene una serie de predicados incorporados que el sistema puede
interpretar directamente.Entre ellos se incluyen el operador de comparacin
de igualdad =(X, Y), que devuelve verdadero si X e y son idnticos y que
puede escribirse tambin como X = Y usando la notacin estndar.
Otros operadores de comparacin de nmeros, como <, <=, > y >=, pueden
considerarse como predicados binarios. En Prolog pueden usarse las funciones
aritmticas +, -, * y / como argumentos en los predicados. Por el contrario,
Datalog (en su forma bsica) no lo permite;

Una consulta suele involucrar un smbolo de predicado con un cierto nmero
de argumentos variables, y su significado (o respuesta) es deducir todas las
combinaciones constantes diferentes que, al ser asignadas a las variables,
hacen que el predicado sea verdadero.
Notacin Datalog
Un programa est constituido por objetos bsicos llamados frmulas atmicas
En Datalog, estas frmulas son literales que tienen la forma p(a1,a2,... , an ),
donde p es el nombre del predicado y n es su nmero de argumentos.
Diferentes predicados pueden contar con distinto nmero de argumentos, por
tanto n de p suele recibir a veces el nombre de grado de p. Los argumentos
pueden ser constantes o nombres de variables.
Datalog cuenta con una serie de predicados incorporados, los cuales pueden
usarse tambin para construir frmulas atmicas. Estos predicados son de dos
tipos principalmente:
los de comparacin binaria [< (menor), <= (menor_o_igual), > (mayor) y
>= (mayor_o_igual)] sobre dominios ordenados
y los de comparacin [= (igual) y /= (distinto)] en dominios ordenados o
desordenados.
Ambos pueden emplearse como predicados binarios con la misma sintaxis
funcional que otros predicados (por ejemplo, escribiendo less(X, 3)) o usando
la notacin simplificadaX<3.
Tarea clausulas de Horn Datalog pag 734
Interpretaciones de reglas en Datalog 736 hasta 739

Bases de Datos distribuidas
Introduccion:

DDBS (Disstributed DataBase System)

DDBMS (Distributed DataBase Management
Systems)

Sistema de bases de datos Distribuidas
(DDBS) Disstributed DataBase System
La tecnologa DDB emergi gracias a la unin de otras dos tecnologas:
La de base de datos y la de comunicacin de datos y de redes.
(desde las comunicaciones por satlite y celulares hasta las MAN, la estandarizacin
de protocolos como Ethernet, TCP/IP y ATM [Modo de transferencia asncrono,
Asynchronous Transfer Mode], as como la explosin de Internet).

Mientras en los 70 y principios de los 80 las bases de datos se movan hacia la
centralizacin produciendo unas monolticas y gigantescas estructuras, la
tendencia a finales de esa dcada era la contraria: ms descentralizacin y
autonoma de procesamiento.
DDBMS
(Distributed DataBase Management Systems)

Los DDBMS (Sistemas de administracin de bases de datos distribuidas,
(Distributed DataBase Management Systems)
sistemas basados en cliente-servidor, o a travs de tecnologas para el acceso a
fuentes de datos distribuidos de manera heterognea. Sistema para resolver los
problemas derivados de la distribucin de datos, las consultas distribuidas y el
procesamiento de las transacciones, la administracin de los metadatos de las
bases de datos distribuidas y otros temas
Conceptos de bases de datos
distribuidas
Un sistema de computacin distribuido consiste en un nmero de elementos de
procesamiento, no necesariamente homogneos, que estn interconectados
mediante una red de computadores, y que cooperan para la realizacin de
ciertas tareas asignadas.

Como objetivo general, estos sistemas dividen un gran e inmanejable problema
en piezas ms pequeas para resolverlo de una manera coordinada, y cada
elemento de procesamiento autnomo pueda ser administrado de manera
independiente y desarrollar sus propias aplicaciones.
distribuidas
DDB (Base de datos distribuida, Distributed DataBase) como una coleccin de
mltiples bases de datos distribuidas interrelacionadas de forma lgica sobre
una red de computadores, y un DDBMS (Sistema de administracin de bases de
datos distribuidas, Distributed DataBase Management System) como el
software encargado de administrar la base de datos distribuida mientras hace
la distribucin transparente para el usuario.
Una coleccin de ficheros almacenados en nodos diferentes de una red y el
mantenimiento de las interrelaciones entre ellos a travs de hiperenlaces se
ha convertido en una organizacin comn en Internet, todo ello mediante
pginas web.
distribuidas
Tecnologa paralela frente a distribuida:
Tomando nuestra atencin hacia las arquitecturas de sistema paralelo, existen dos
tipos fundamentales de arquitecturas de sistema multiprocesador:

Arquitectura de memoria compartida (estrechamente acoplada o tightly coupled).
Varios procesadores comparten el almacenamiento secundario (disco) y la memoria
primaria .
Arquitectura de disco compartido (dbilmente acoplada o loosely coupled). Varios
procesadores comparten el almacenamiento secundario (disco), pero cada uno de ellos
tiene su propia memoria primaria.

Estas arquitecturas permiten a los procesadores comunicarse entre s sin los gastos
derivados del intercambio de mensajes sobre una red.
distribuidas
Los sistemas de bases de datos desarrollados sobre las arquitecturas anteriores se
llaman sistemas de administracin paralelos de bases de datos en lugar de DDBMS,
ya que emplean tecnologa de procesador paralelo.
La arquitectura "nada compartido" es otro tipo de sistema multiprocesador. En
ella, cada procesador tiene su propia memoria (disco) primaria y secundaria, no
existe memoria comn, y esos procesadores se comunican mediante una red de
interconexin de alta velocidad (bus o switch). Aunque esta arquitectura se
asemeja a un entorno de procesamiento de base de datos distribuida, existen unas
grandes diferencias en el modo de operar.

En sistemas multiprocesador de nada compartido, existe simetra y homogeneidad
de nodos; esto no se cumple en un entorno de base de datos distribuida, donde es
muy comn la heterogeneidad del hardware y el sistema operativo de cada nodo.
Algunos tipos de arquitecturas de base de datos. (a) Arquitectura "nada
compartido". (b)Arquitectura en red con una base de datos centralizada en una
de sus ubicaciones. (c)Arquitectura de base de datos distribuida autntica.

CPU
Memoria
Computador 1
DB
Computador 2
Memoria
DB 1
CPU
a)
Switch
CPU
Memoria
DB
Computador n
b)
Sitio
central
(DF)
DB
DB 2
Red de
comunicaciones
Sitio
(Qro)
Sitio
(Gdl)
Sitio
(Col)
Sitio
(Mty)
(c)Arquitectura de base de datos distribuida
autntica.

DB
Sitio 5
(DF)
DB
Red de
comunicaciones
Sitio 3
(Qro)
Sitio 4
(Gdl)
Sitio 2
(Col)
Sitio 1
(Mty)
c)
BD
BD
BD
Ventajas de las bases de datos distribuidas
1. Administracin de datos distribuidos con distintos niveles de transparencia:
tipos de transparencias:
Transparencia de red o de distribucin. Se divide:
La transparencia de localizacin.
La transparencia de denominacin
Transparencia de replicacin. (Fig 1)
Transparencia de fragmentacin.
La transparencia de diseo y de ejecucin

2. Incremento de la fiabilidad y la disponibilidad.
3. Rendimiento mejorado.
4. Expansin ms sencilla.
1. Administracin de datos distribuidos con distintos niveles de
transparencia.
Un DBMS debe ser una distribucin transparente en el sentido de ocultar los
detalles de dnde est fsicamente ubicado cada fichero (tabla, relacin)
dentro del sistema.
tipos de transparencias:
Transparencia de red o de distribucin. Hace referencia a la autonoma
del usuario de los detalles operacionales de la red. Puede dividirse en
transparencia de localizacin y de denominacin.
La transparencia de localizacin hace mencin al hecho de que el comando usado
para llevar a cabo una tarea es independiente de la ubicacin de los datos y del
sistema desde el que se ejecut dicho comando.
La transparencia de denominacin implica que, una vez especificado un nombre,
puede accederse a los objetos nombrados sin ambigedad y sin necesidad de
ninguna especificacin adicional.
Transparencia de replicacin. pueden almacenarse copias de los datos en
distintos lugares para disponer de una mayor disponibilidad, rendimiento y
fiabilidad. La transparencia de replicacin permite que el usuario no se
entere de la existencia de copias.
Transparencia de fragmentacin. Existen dos posibles tipos de
fragmentacin: la horizontal distribuye una relacin en conjuntos de tuplas
(filas), mientras que la vertical lo hace en subrelaciones, de modo que cada
subrelacin est definida por un subconjunto de las columnas de la relacin
original. Una consulta global del usuario debe ser transformada en varias
consultas fragmentadas. La transparencia de fragmentacin permite que el
usuario no se entere de la existencia de fragmentos.
La transparencia de diseo y de ejecucin hace referencia a la libertad
de saber cmo est diseada la base de datos distribuida y dnde ejecuta
una transaccin.
2. Incremento de la fiabilidad y la disponibilidad. Importantes en las BDD.
La fiabilidad est definida ampliamente como la probabilidad de que un
sistema est funcionando (no cado) en un momento de tiempo.
la disponibilidad es la probabilidad de que el sistema est
continuamente disponible durante un intervalo de tiempo.
Cuando los datos y el software DBMS estn distribuidos a lo largo de distintas
localizaciones, uno de ellos puede fallar, mientras el resto contina
operativo. Slo los datos y el software almacenados en la localizacin que
falla sern los que no estn disponibles. Esto mejora tanto la fiabilidad como
la disponibilidad.
Se logra una apreciable mejora al replicar tanto los datos como el software
en ms de una ubicacin. En un sistema centralizado, el fallo de una
ubicacin provoca la cada del sistema para todos los usuarios. En una base
de datos distribuida, parte de la informacin puede estar inaccesible, pero s
se podr acceder a otras partes de la base de datos.
3. Rendimiento mejorado. Un DBMS distribuido fragmenta la base de datos
manteniendo la informacin lo ms cerca posible del punto donde es ms necesaria.
La localizacin de datos reduce el enfrentamiento por la CPU y los servicios de E/S, a
la vez que atena los retardos en el acceso implcito a las redes de rea extendida.
Cuando se distribuye una base de datos a lo largo de varias localizaciones, lo que
obtenemos son bases de datos ms pequeas.
Como resultado, las consultas locales y las transacciones de acceso a los datos de uno de estos
sitios tienen un mayor rendimiento debido al menor tamao de esas bases de datos. Adems,
cada sitio tiene que ejecutar un menor nmero de transacciones que si todas ellas fueran
llevadas a cabo por una base de datos centralizada. Por otra parte, el paralelismo
interconsultas e intraconsultas puede conseguirse ejecutando mltiples consultas de diferentes
sitios, o dividiendo esa consulta en otras ms pequeas que se ejecutan en paralelo. Todo esto
contribuye a mejorar el rendimiento.
4. Expansin ms sencilla. En un entorno distribuido, la expansin del sistema en
trminos de incorporacin de ms datos, incremento del tamao de las bases de datos
o la adicin de ms procesadores es mucho ms sencilla.
La transparencia se ofrece como un complemento a la autonoma, que ofrece a los
usuarios un control severo sobre las bases de datos locales.

Ejemplo de distribucin de datos y replicacin entre
bases de datos distribuidas.
Fig 1.
Sitio
central
(DF)
Red de
comunicaciones
Sitio
(Qro)
Sitio
(Gdl)
Sitio
(Col)
Sitio
(Mty)
EMPLEADOS Todos
PROYECTOS Todos
TRABAJA EN Todos
EMPLEADOS Qro
PROYECTOS Qro y Gdl
TRABAJA_EN empleados
Qro
EMPLEADOS Col
PROYECTOS Col
Col
EMPLEADOS Mty
PROYECTOS Todos
Mty
EMPLEADOS Gdl y Qro
PROYECTOS Gdl
Gdl
Funciones adicionales de las bases de datos
distribuidas
La distribucin conlleva un incremento en la complejidad del diseo del sistema y de su
implementacin. Para obtener todas esas ventajas de las que hemos hablado anteriormente,
el software DDBMS debe ser capaz de ofrecer las siguientes funciones adems de todas las de
un DBMS centralizado:
Seguimiento de los datos. Control de distribucin, fragmentacin y replicacin.
Procesamiento de consultas distribuidas. Acceder a sitios remotos y transmitir consultas
y datos.
Administracin de transacciones distribuidas. Diseo estrategias de consultas y
transacciones.
Administracin de datos replicados. Decidir a qu copia de un dato acceder y
consistencia de copias.
Recuperacin de una base de datos distribuida. Recuperar cadas de un sitio individual y
fallos de enlace.
Seguridad. En transacciones distribuidas y privilegios de autorizacin/acceso de usuarios.
Administracin del directorio (catlogo) distribuido. Contiene inf. (metadatos), global o
local (cada sitio)
Funciones adicionales de las bases de datos
distribuidas
Seguimiento de los datos. La capacidad de controlar la distribucin de los datos, la
fragmentacin y la replicacin expandiendo el catlogo DDBMS.
Procesamiento de consultas distribuidas. La posibilidad de acceder a sitios remotos y de
transmitir consultas y datos a lo largo de todos esos sitios mediante una red de comunicacin.
Administracin de transacciones distribuidas. La facultad de disear estrategias de
ejecucin de consultas y transacciones que accedan a los datos desde ms de una ubicacin y
de sincronizar el acceso a los datos distribuidos y de mantener la integridad de toda la base
de datos.
Administracin de datos replicados. La capacidad de decidir a qu copia de un dato acceder
y de mantener la consistencia de las copias de un elemento de datos replicado.
Recuperacin de una base de datos distribuida. La facultad de recuperarse de las cadas de
una localizacin individual u otro tipo de fallos, como los fallos en los enlaces de
comunicacin.
Seguridad. Las transacciones distribuidas deben ejecutarse con una adecuada administracin
de la seguridad de los datos y contando con los privilegios de autorizacin/acceso de los
usuarios.
Administracin del directorio (catlogo) distribuido. Un directorio contiene informacin
(metadatos) sobre los datos de la base de datos. Puede ser global a toda la DDB, o local para
cada sitio. La colocacin y distribucin del directorio son temas relacionados con el diseo y
las polticas

A nivel de hardware, factores principales que
distinguen un DDBMS de un sistema centralizado:

Existen mltiples computadores llamados sitios o nodos.
Estos sitios deben estar conectados por algn tipo de red de comunicacin
para transmitir los datos y los comandos entre ellos.

Estos sitios pueden estar cercanos entre s (digamos, dentro del mismo edificio o
grupo de edificios adyacentes) y conectados mediante una red de rea local, o
estar geogrficamente distribuidos a larga distancia y enlazados a travs de una
red de rea expandida o long-haul. Las redes de rea local suelen emplear cables
mientras que las long-haul utilizan lneas telefnicas o satlites. Tambin es
posible usar una combinacin de redes.

Tcnicas de fragmentacin,
replicacin y asignacin de datos para
el diseo de bases de datos
distribuidas
Fragmentacin de datos

Unidades lgicas en una base de datos, llamadas fragmentos, los cuales
pueden almacenarse en varios sitios.
En una DDB, cada relacin (o porcin de una relacin) se almacena slo en un
sitio. Partimos de un esquema de base de datos relacional y debemos decidir
cmo distribuir las relaciones entre los diferentes sitios.
Antes de decidir cmo distribuir los datos, debemos determinar las unidades
lgicas de la base de datos que deben distribuirse. Las unidades lgicas ms
simples son las propias relaciones; es decir, cada relacin completa
almacenada en un sitio particular.
Sin embargo, en muchos casos, una relacin puede dividirse en unidades
lgicas ms pequeas con vistas a su distribucin.
TIPOS:

Fragmentacin horizontal..
Fragmentacin horizontal derivada
Fragmentacin vertical
Fragmentacin mixta (hbrida).
Fragmentacin horizontal. . Divide una relacin horizontalmente agrupando
filas para crear subconjuntos de tuplas, cada uno de ellos con un cierto
significado lgico. Las tuplas pertenecientes al fragmento horizontal se
especifican mediante una condicin sobre uno o ms atributos de la relacin.
Estos fragmentos pueden asignarse entonces a diferentes sitios del sistema
distribuido.
La fragmentacin horizontal derivada aplica el particionamiento de una
relacin primaria (DEPARTAMENTO en nuestro ejemplo) a otras relaciones
secundarias (EMPLEADO y PROYECTO) que estn relacionadas con aqulla a
travs de una clave externa (joreign key). De esta forma, los datos
relacionados entre las relaciones primaria y secundaria permanecen
fragmentados de la misma forma.
Fragmentacin vertical. divide una relacin "verticalmente por columnas.
Es necesario incluir la clave primaria, o alguna otra clave candidata, en cada
fragmento vertical de modo que nos permita reconstruir la relacin completa
a partir de ellos
Fragmentacin Horizontal
Cada fragmento horizontal de una relacin R puede especificarse con una
operacin ci(R) en el lgebra relacional.

Un conjunto de fragmentos horizontales cuyas condiciones C1, C2, ... , Cn
incluyan todas las tuplas de R [esto es, cada tupla de R satisface (C1 OR C2 OR
... OR Cn)], recibe el nombre de fragmentacin horizontal completa de R. En
muchos casos, una de estas fragmentaciones es tambin disjunta; es decir,
ninguna tupla de R satisface (Ci AND Cj) para cualquier i =1= j.

Para reconstruir la relacin R a partir de una fragmentacin horizontal
completa necesitamos aplicar la operacin UNION a los fragmentos.
Fragmentacin Vertical
Un fragmento vertical de una relacin R puede especificarse mediante una operacin
Li (R) en el lgebra relacional.
Un conjunto de fragmentos verticales cuyas listas de proyeccin L, L2, ... , Ln
incluyen todos los atributos de R pero que slo comparten el atributo de clave primaria
recibe el nombre de fragmentacin vertical completa de R. En este caso, las listas de
proyeccin satisfacen las dos siguientes condiciones:
L U L2 U ... U Ln = ATTRS(R).
L n Lj = PK(R) para cualquier i =1= j, donde ATTRS(R) es el conjunto de los atributos de
R y pk(R) es la clave primaria de R.

Para reconstruir la relacin R a partir de una fragmentacin vertical completa
aplicamos la operacin OUTER UNION (asumimos que no se ha usado fragmentacin
horizontal). O aplicar FULL OUTER JOIN aun cuando haya podido aplicarse tambin
alguna fragmentacin horizontal.
Fragmentacin mixta (hbrida)
Podemos entremezclar los dos tipos de fragmentacin para obtener una
fragmentacin mixta. En este caso, la relacin original puede reconstruirse
aplicando operaciones UNION y OUTER UNION (u OUTER JOIN) en el orden
apropiado.
Un fragmento de una relacin R puede especificarse mediante una
combinacin de operaciones SELECT-PROYECTO Li (ci(R))
Si C = TRUE (es decir, se seleccionan todas las tuplas) y L ATTRS(R),
obtenemos un fragmento vertical,
y si C TRUE Y L = ATTRS(R), se consigue un fragmento horizontal.
Por ltimo, si C TRUE y L ATTRS(R), se genera un fragmento mixto.
Una relacin puede considerarse en s misma como un fragmento si
C = TRUE y L = ATTRS(R).
Un esquema de fragmentacin de una base de datos es un conjunto de
fragmentos que incluyen todos los atributos y tuplas de esa base de datos y
que satisface la condicin de que es posible reconstruirla en su totalidad
aplicando alguna secuencia de operaciones OUTER UN ION (u OUTER JOIN) Y
UNION.

Un esquema de ubicacin describe la colocacin de los fragmentos en los
sitios del DDBS; por tanto, es un mapa que indica, por cada fragmento, el
(los) sitio(s) en el que est almacenado. Si un fragmento se encuentra en ms
de un sitio se dice que est replicado.

El esquema de replicacin es una descripcin de los fragmentos de la
replicacin.
Replicacin y ubicacin de los datos
La replicacin es til para mejorar la disponibilidad de los datos.
Tipos:

Una base de datos distribuida totalmente replicada. es la replicacin de toda
la base de datos en cada sitio del sistema distribuido.
La no replicacin en una base de datos distribuida, cada fragmento est
almacenado en un sitio.
Una base de datos con replicaciones parciales, esto es, algunos fragmentos de
la base de datos pueden replicarse mientras que otros no.

La eleccin del sitio y el grado de replicacin dependen de los objetivos de
rendimiento y la disponibilidad del sistema, as como de los tipos y
frecuencias de las transacciones efectuadas en cada sitio. 757
Tipos de replicacin
Una base de datos distribuida totalmente replicada. es la replicacin de toda la
base de datos en cada sitio del sistema distribuido, mejorar disponibilidad,
sistema funcionando con uno de los sitios activo, mejora rendimiento en la
recuperacin de consultas globales porque los resultados de este tipo de consultas
pueden obtenerse localmente, desventaja ralentiza drsticamente las operaciones
de actualizacin, ya que es preciso ejecutar dicha operacin en cada copia de la
base de datos para mantener la consistencia de las mismas.
La no replicacin en una base de datos distribuida. es decir, cada fragmento est
almacenado en un sitio. En este caso, todos los fragmentos deben ser disjuntos,
excepto en la repeticin de claves primarias a lo largo de los fragmentos verticales
(o mixtos). Esto suele conocerse tambin como ubicacin no redundante.
Una base de datos con replicaciones parciales, esto es, algunos fragmentos de la
base de datos pueden replicarse mientras que otros no. El nmero de copias de
cada fragmento puede oscilar desde una hasta el nmero total de sitios del
sistema distribuido.

Un posible estado de base de datos para el esquema relacional EMPRESA.
EMPLEADO
Nombre Apellido1 Apellido2 Dni FechaNac Direccin Sexo Sueldo SuperDni Dno
Jos Prez Prez 123456789 01-09-1965 Eloy 198 H 30000 333445555 5
Alberto Campos Sastre 333445555 08-12-1955 Avda. Ros, 9 H 40000 888665555 5
Alicia Jimnez Celaya 999887777 12-05-1968 Gran Va, 38 M 25000 987654321 4
Juana Sainz Oreja 987654321 20-06-1941 Cerquillas, 67 M 43000 888665555 4
Fernando Ojeda Ordez 666884444 15-09-1962 Portillo, sin H 38000 333445555 5
Aurora Oliva Avezuela 453453453 31-07-1972 Antn, 6 M 25000 333445555 5
Luis Pajares Morera 987987987 29-03-1969 Enebros, 90 H 25000 987654321 4
Eduardo Ochoa Paredes 888665555 10-11-1937 Las Peas, 1 H 55000 NULL 1

DEPARTAMENTO LOCALIZACIONES_OPTO

NombreDpto NumeroDRto DniDirect FechalngresoDirector NumeroDRto UbicacionDRto
Investigacin 5 333445555 22-05-1988 1 Madrid
Administracin 4 987654321 01-01-1995 4 Gijon
Sede Centra l 1 888665555 19-06-1981 5 Valencia
5 Sevilla
5 Madrid
Continuacin.
TRABAJA EN

DniEmleado NumProy Horas
123456789 1 32,5
123456789 2 7,5
666884444 3 40,0
453453453 1 20,0
453453453 2 20,0
333445555 2 10,0
333445555 3 10,0
333445555 10 10,0
333445555 20 10,0
999887777 30 30,0
999887777 10 10,0
987987987 10 35,0
987987987 30 5,0
987654321 30 20,0
987654321 20 15,0
888665555 20 NULL

PROYECTO

NombreProyecto NumProyecto UbicacionProyecto NumDptoProyecto
Producto X 1 Valencia 5
Producto Y 2 sevilla 5
Producto Z 3 Madrid 5
Computacin 10 Gijon 4
Reorganizacin 20 Madrid 1
Comunicaciones 30 Gijon 4

SUBORDINADO

DniEmpleado NombSubordinado Sexo FechaNac Relacin
333445555 Alicia M 05-04-1986 Hija
333445555 Teodoro H 25-10-1983 Hijo
333445555 Luisa M 03-05-1958 Esposa
987654321 Alfonso H 28-02-1942 Esposo
123456789 Miguel H 04-01-1988 Hijo
123456789 Alicia M 30-12-1988 Hija
123456789 Elisa M 05-05-1967 Esposa

Ejemplo de fragmentacin, ubicacin y
replicacin
Ejemplo de Fragmentacion Vertical Completa de EMPLEADO.
L = {Dni, Nombre, FechaNac, Direccin, Sexo} y
L2 = {Dni, Sueldo, SuperDni, Dno}

Ejemplo de fragmentacin y distribucin de BD Empresa. Supongamos que la
empresa cuenta con tres sitios operativos (uno por cada departamento).
Sitio 2 ->Depto 5 y Sitio 3 ->Depto 4
(hay acceso frecuente a inf EMPLEADO y PROYECTO para aquellos asalariados que
trabajan en ese departamento y los proyectos controlados por ese departamento).
Estos sitios accedern fundamentalmente a los atributos Nombre, Dni, Sueldo y
SuperDni de EMPLEADO.
El sitio 1 lo utiliza la oficina central y accede regularmente a toda la informacin
de empleados y proyectos, adems de controlar los datos de SUBORDINADO con
miras a los seguros.

Para determinar los fragmentos a replicar en los sitios 2 y 3, primero podemos
fragmentar horizontalmente DEPARTAMENTO por su clave NmeroDpto, A
continuacin, aplicamos la fragmentacin derivada a las relaciones EMPLEADO,
PROYECTO Y LOCALlZACIONES_DPTO.
Se parte la relacin EMPLEADO para incluir slo los atributos {Nombre, Dni, Sueldo,
SuperDni, Dno} en fragmentos mixtos EMPD _5 Y EMPD _4, que incluyen las tuplas
EMPLEADO que satisfacen las condiciones Dno = 5 Y Dno = 4, respectivamente.
Los fragmentos horizontales de PROYECTO, DEPARTAMENTO Y LOCALlZACIONES_DPTO
(almacenados en los sitios 2 y 3) estn replicados porque tambin se encuentran en
las oficinas centrales (sitio 1).

Ubicacin de fragmentos en los sitios. (a) Relacin de fragmentos del sitio 2 correspondiente al departamento 5.
(b) Relacin de fragmentos del sitio 3 correspondiente al departamento 4.

(a)
EMPD_5
Nombre Apellido1 Apellido2 Dni Sueldo SuperDni Dno
Jos Prez Prez 123456789 30000 333445555 5
Alberto Campos Sastre 333445555 40000 888665555 5
Fernando Ojeda Ordez 666884444 38000 333445555 5
Aurora Oliva Avezuela 453453453 25000 333445555 5

DEP_5
NombreDepto Numdepto DniDirector FechaIngrresodirector
Investigacin 5 333445555 1988-05-22

DEP_5_LOCS
NmeroDQto Ubicacin
5 Valencia
5 Sevilla
5 Madrid

(b)

EMPD_4
Nombre Apellido1 Apellido2 Dni Sueldo SuperDni Dno
Alicia Jimnez Celaya 999887777 25000 987654321 4
Juana Sainz Oreja 987654321 43000 888665555 4
Luis Pajares Morera 987987987 25000 987654321 4

DEP_4
NombreDepto Numdepto DniDirector FechaIngrresodirector
Administracin 4 987654321 1995-01-01

DEP_4_LOCS
NmeroDQto Ubicacin
4 Gijn
01

TRABAJA_EN_5
DniEmpleado NumProy Horas
123456789 1 32,5
123456789 2 7,5
666884444 3 40,0
453453453 1 20,0
453453453 2 20,0
333445555 2 10,0
333445555 3 10,0
333445555 10 10,0
333445555 20 10,0

PROYS_5
NombreProyecto NumProyecto UbicacinProyecto NumDptoProyecto
Producto X 1 Valencia 5
Producto Y 2 Sevilla 5
Producto Z 3 Madrid 5

Datos del sitio 2

TRABAJA_EN _4
333445555 10 10,0
999887777 30 30,0
999887777 10 10,0
987987987 10 35,0
987987987 30 5,0
987654321 30 20,0
987654321 20 15,0

PROYS_4
NombreProyecto NumProyecto UbicacinProyecto NumDptoProyecto
Computacin 10 Gijn 4
Comunicaciones 30 Gijn 4

Datos del sitio 3
Ejemplo de fragmentacin:
Para partir la relacin TRABAJA_EN y decidir cules de sus fragmentos se
almacenan en los sitios 2 y 3, nos enfrentamos al problema de que ningn
atributo de TRABAJA_EN indica directamente el departamento al que
pertenece cada tupla, de hecho, cada una de ellas relaciona a un empleado e
con un proyecto p,
Por ejemplo, la tupla TRABAJA_EN <333445555, 10, 10,0> relaciona un
empleado que trabaja para el departamento 5 con un proyecto controlado por
el 4.
En este caso, podramos fragmentar TRABAJA_EN basndonos en el
departamento en el que trabaja el empleado (lo cual est expresado por la
condicin C) para despus volver a dividir en funcin al departamento que
controla los proyectos en los que est trabajando el empleado, tal y como se
ve en la siguiente figura:

Fragmentos completos y disjuntos de la relacin TRABAJA_EN

a) Empleados del Departamento 5

G1 G2
DniEmpleado NumProy Horas DniEmpleado NumProy Horas
123456789 1 32.5 333445555 10 10.0
123456789 2 7.5
666884444 3 40.0 C2 = C and (NumProy n (SELECT
453453453 1 20.0 NumProyecto FROM PROJECT
453453453 2 20.0 WHERE NumDptoProyecto = 4))
333445555 2 10.0
333445555 3 10.0

C1 = C and (NumProy in (SELECT NumProyecto
FROM PROJECT WHERE NumDptoProyecto = 5))

G3
333445555 20 10.0


(b) Empleados del Departamento 4

G4


G5
999887777 30 30.0
999887777 10 10.0 G6
987987987 10 35.0 DniEmpleado NumProy Horas
987987987 30 5.0 987654321 150 20.0
987654321 30 20.0

C5 = C and (NumProy in (SELECT C6 = C and (NumProy in
NumProyecto FROM PROJECT (SELECT NumProyecto
WHERE NumDptoProyecto = 4)) FROM PROJECT WHERE
NumDptoProyecto = 1))
la unin de los fragmentos G1, G2 Y G3 brinda todas las tuplas
TRABAJA_EN para los empleados que trabajan para el
departamento 5,
la unin de los fragmentos G4, Gs Y G6 contiene
las tuplas de los que trabajan para el departamento 4.

En el otro extremo, la unin de los fragmentos G1, G4
y G7 ofrece las tuplas TRABAJA_EN de los proyectos controlados
por el departamento 5.

hemos elegido incluir todos los fragmentos que pueden unirse
mediante una tupla EMPLEADO o una tupla PROYECTO de los
sitios 2 y 3, Por tanto, colocamos la unin de los fragmentos G1,
G2, G3, G4 Y G7 en el sitio 2 y la de los fragmentos G4, Gs, G6,
G2 Y G8 en el 3.
Esta estrategia de ubicacin permite que la concatenacin entre
los fragmentos EMPLEADO o PROYECTO locales del sitio 2 o 3 y el
de TRABAJA_EN pueda llevarse a cabo de una manera
completamente local
Esto demuestra muy a las claras lo complejo que es el problema
de la fragmentacin y ubicacin de una base de datos grande.
(a) Fragmentos de TRABAJA_EN de los empleados que trabajan para el
departamento 5 (C=[DniEmpleado in (SELECT Dni FROM EMPLEADO
WHERE Dno=5)]).
(b) Fragmentos de TRABAJA_EN de los empleados que trabajan para el
departamento 4 (C=[DniEmpleado in (SELECT Dni FROM EMPLEADO
WHERE Dno=4)]).
(c) Fragmentos de TRABAJA_EN de los empleados que trabajan para el departamento 1
(C=[DniEmpleado in (SELECT Dni FROM EMPLEADO WHERE Dno= 1)]).

(c) Empleados del Departamento 1

G7


C7 = C and (NumProy in
(SELECT NumProyecto FROM
PROJECT WHERE

G8


(SELECT NumProyecto
FROM PROJECT WHERE

G9


888665555 20 NULL

(SELECT NumProyecto
FROM PROJECT WHERE

(C=[DniEmpleado in (SELECT Dni FROM EMPLEADO WHERE Dno=5)]).
C1 = C and (NumProy in (SELECT NumProyecto FROM PROJECT WHERE NumDptoProyecto = 5))
C2 = C and (NumProy n (SELECT NumProyecto FROM PROJECT WHERE NumDptoProyecto = 4))

4 (C=[DniEmpleado in (SELECT Dni FROM EMPLEADO WHERE Dno=4)]).

(C=[DniEmpleado in (SELECT Dni FROM EMPLEADO WHERE Dno= 1)]).

La diapositiva anterior muestra las tablas resultantes de alguna fragmentacion.

Tarea Tipos de Sistemas de bases de datos distribuidas y Problemas de los sistemas de administracin de
una base de datos federada. Pag 759-762 antes de consultas.
Procesamiento de consultas en bases de
datos distribuidas
Veremos el modo en que un DDBMS procesa y optimiza una consulta.

Primero trataremos los costes de comunicacin del procesamiento de una
consulta distribuida, para despus pasar a un tipo de operacin especial,
llamada semijoin (semiconcatenacin), que se utiliza para optimizar ciertas
consultas en un DDBMS.
Costes de transferencia de datos del
procesamiento de una consulta distribuida
Factores adicionales que complican el tratamiento de la consulta en un
sistema distribuido:
El primero es el coste de la transferencia de los datos a travs de una red.
Entre estos datos se incluyen los ficheros intermedios que son transferidos a
otros sitios para un mejor procesamiento, as como el resultado final que
debe devolverse al sitio que solicit la informacin
. Aunque estos costes pueden no ser muy grandes si los sitios estn
conectados mediante una red de rea local de alto rendimiento, la situacin
cambia ostensiblemente cuando se habla de otro tipo de redes. Por
consiguiente, los algoritmos de optimizacin de consultas DDBMS tienen como
objetivo fundamental reducir la cantidad de la transferencia de datos a la
hora de elegir una estrategia de ejecucin de una consulta distribuida.
Procesamiento de una consulta distribuida
Las relaciones EMPLEADO Y DEPARTAMENTO estn distribuidas tal y como aparece
en la siguiente figura, ninguna de las dos relaciones est fragmentada.

El tamao de la relacin EMPLEADO es de 100 * 10.000 = 10
6
bytes,
mientras que la de DEPARTAMENTO es de 35 * 100 = 3.500 bytes.

Consideremos la consulta C: por cada empleado, recuperar su nombre y el del
departamento para el cual trabaja.

Esto puede formularse del siguiente modo en el lgebra relacional:
C: Nombre,APellidoP,NombreDPto(EMPLEADO >< Dno=NmeroDpto DEPARTAMENTO)

La consulta es enviada a un sitio 3 distinto, llamado sitio resultado porque es el lugar en el
que se precisan los resultados. Cada registro de la consulta tiene 40 bytes de longitud.

Ejemplo para ilustrar el volumen de datos
transferidos
Nombre ApellidoP ApellidoM Dni FechNac Direccin Sexo Sueldo SuperDni Dno
NombreDpto NmeroDepto Dnidirector FechaIngresodirector

10,000 registros
Longitud de registro: 100 bytes
Longitud del campo Dni: 9 bytes
Longitud del campo Dno: 4 bytes
Longitud del campo Nombre: 15 bytes
Longitud del campo ApellidoP: 15 bytes

100 registros
Longitud de registro: 35 bytes
Longitud del campo NmeroreDpto: 4 bytes
Longitud del campo DniDirector: 9 bytes
Longitud del campo NombreDpto: 10 bytes
Sitio 2.
DEPARTAMENTO
Sitio 1.
EMPLEADO
C: Nombre,APellidoP,NombreDPto(EMPLEADO ><Dno=NmeroDptoDEPARTAMENTO)
Para ejecutar esta consulta distribuida existen tres tipos de estrategias simples:
1. Transferir las relaciones EMPLEADO y DEPARTAMENTO al sitio resultado, y ejecutar
la concatenacin en el sitio 3. En este caso deben trasferirse l.000.000 + 3500 =
l.003.500 bytes.
2. Transferir la relacin EMPLEADO al sitio 2, ejecutar la concatenacin en l y
transferir el resultado al 3. El tamao del resultado de la consulta es de 40 * 10.000 =
400,000 bytes, por lo que se tendrn que transferir 400.000 + 1.000.000 = 14OO.OOO
bytes.
3. Transferir la relacin DEPARTAMENTO al sitio 1, ejecutar la concatenacin en l y
enviar el resultado al 3. En este caso, lo que se transfieren son 400.000 + 3.500 =
403.500 bytes.

Consideremos la siguiente consulta:
C': por cada departamento, recuperar su nombre y el de su director.
Esto quedara del siguiente modo en el lgebra relacional:
C': Nombre,ApellidoP,NombreDPto(DEPARTAMENTO DniDirector=Dni EMPLEADO)
Utilizando las mismas estrategias anteriores cual es la mejor opcin?
Supongamos que el sitio resultado es el 2; en este caso tenemos dos estrategias,
cul seria el costo de transferencia tanto para C como C' ? Y cul es la mejor
opcin?
Realiza la siguiente consulta, utilizando mismas estrategias: C : por cada
departamento, recuperar el nombre y salario de todos los empleados que
trabajan en l .
Realizar una consulta de la base de datos (complejo deportivo o biblioteca)
usando una semijoin
La idea que se esconde tras el procesamiento de una consulta distribuida mediante
una operacin de semijoin es reducir el nmero de tuplas de una relacin antes de
transferirla a otro sitio.
Consideremos la siguiente estrategia para ejecutar C o C':
1. Proyectar los atributos de concatenacin de DEPARTAMENTO al sitio 2 y transferirlos
al sitio 1. Para C enviamos F = NmeroDpto(DEPARTAMENTO), cuyo tamao es de 4
* 100 = 400 bytes, mientras que para C' trasmitimos F' =
DniDirector(DEPARTAMENTO), que tiene un tamao de 9 * 100 = 900 bytes.
2. Concatenamos el fichero transferido con la relacin EMPLEADO en el sitio 1, y
devolvemos al sitio 2 los atributos requeridos. Para C, enviamos R =
Dno, Nombre, Apellido1(F
[
><
]
NmeroDpto=Dno EMPLEADO), cuyo tamao es de 34 *
10.000 = 340.000 bytes, mientras que para C' transferimos R' =
DniDirector,Nombre,Apellido1 (F '
[
><
]
DniDirector=Dni EMPLEADO), que tiene un
tamao de 39 * 100 = 3.900 bytes.
3. Ejecutar la consulta concatenando el fichero transferido R o R' con DEPARTAMENTO,
y presentamos el resultado al usuario del sitio 2. (hacer concatenacin)
usando una semijoin

Usando este planteamiento, enviamos 340.400 bytes para C y 4.800 para C'. En el
paso 2, limitamos los atributos y tuplas EMPLEADO trasmitidas al sitio 2 a slo
aqullas que sern concatenadas con la tupla DEPARTAMENTO en el paso 3.

Para la consulta C, esta reunin incluye todas las tuplas EMPLEADO, con lo que
se obtiene una pequea mejora. Sin embargo, para C' slo sern necesarias 100
de las 10.000 tuplas EMPLEADO.
usando una semijoin

La semiconcatenacin fue ideada para formalizar esta estrategia. Una operacin
semijoin R
[
><

A= B
S, en la que A y B son atributos de dominio compatible de R y S
respectivamente, produce el mismo resultado que la expresin de lgebra
relacional
R
(R
[
><
]

A=B
S). En un entorno distribuido donde R y S residen en sitios
diferentes, esta operacin suele estar implementada de forma que primero se
transfiere F =
B
(S) al sitio en el que reside R para despus concatenar F con R,
lo que nos conduce a la estrategia mostrada aqu.
Observe que la operacin semiconcatenacin no es conmutativa; esto es,
R

[
><

S S

[
><

R
C: Nombre,APellidoP,NombreDPto(EMPLEADO ><Dno=NmeroDptoDEPARTAMENTO)
C': Nombre,ApellidoP,NombreDPto(DEPARTAMENTO DniDirector=Dni EMPLEADO) C':
C': Nombre,ApellidoP,Salario(DEPARTAMENTO DniDirector=Dni EMPLEADO)

Como se representan las consultas anteriores en SQL?

Pag 765
765

BDOO2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BDOO2

Uploaded by

Copyright:

Available Formats

TERMINO OO

El trmino orientacin a objetos (abreviado como 00 u O-O) tiene sus orgenes

You might also like