RESUMEN BASE DE DATOS AVANZADA

BIBLIOGRAFA

ELMASRI, Ramez A. y NAVATHE, Shamkant B. 2002 Fundamentos

de Sistemas de Bases de Datos. Espaa. Addison Wesley.
KIMBALL, Ralph. 2002 The Data Warehouse Toolkit. United States.
Wiley Computer Publishing.

UNIDAD I: INTRODUCCIN
ORIENTADAS A OBJETOS

LAS

BASE

DE

DATOS

Los modelos de datos y los sistemas tradicionales, como los relacionales.

han tenido mucho xito en el desarrollo de la tecnologa de bases de datos,
necesaria en muchas aplicaciones de bases de datos comerciales populares.
Sin embargo, tienen sus inconvenientes cuando deben disearse e
implementarse aplicaciones de bases de datos ms complejas; por ejemplo,
bases de datos para experimentos cientficos, telecomunicaciones, sistemas
de informacin geogrfica y multimedia. Estas aplicaciones ms modernas
tienen unos requisitos y unas caractersticas que difieren de los de las
aplicaciones comerciales tradicionales, como estructuras ms complejas
para los objetos, transacciones de mayor duracin, nuevos tipos de datos
para almacenar imgenes o elementos de texto ms grandes, y la
necesidad de definir operaciones especificas de la aplicacin que no son
estndar. Las bases de datos orientadas a objetos se propusieron para
satisfacer las necesidades de estas aplicaciones ms complejas. La
metodologa de orientacin a objetos ofrece la flexibilidad de manipular
algunos de los requisitos sin la limitacin impuesta por los tipos de datos y
los lenguajes de consulta disponibles en los sistemas de bases de datos
tradicionales. Una caracterstica fundamental de las bases de datos
orientadas a objetos es la potencia que otorgan al diseador para
especificar tanto la estructura de los objetos complejos como las
operaciones que pueden aplicarse a esos objetos.
Ora razn para la creacin de bases de datos orientadas a objetos es el
incremento del uso de lenguajes de programacin orientados a objetos en el
desarrollo de aplicaciones de software.
Las bases de datos son componentes fundamentales de muchos sistemas
de software, y las bases de datos tradicionales son difciles de utilizar con
las aplicaciones orientadas a objetos que estn desarrolladas con un
lenguaje de programacin orientado a objetos, como C++ o Java. Las bases
de datos orientadas a objetos estn diseadas para que se integren
directamente y sin problemas con las aplicaciones que estn desarrolladas
en dichos lenguajes.
Aunque se han creado muchos prototipos experimentales y sistemas de
bases de datos orientados a objetos comerciales, no se ha extendido su uso
debido a la popularidad de los sistemas relacionales y relacionales de
objetos.

1. Conceptos de bases de datos orientadas a objetos:

1.1. Panorama general de orientacin a objetos

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

orgenes en los lenguajes de programacin OO, u OOPLs.
Un objeto normalmente tiene dos componentes: un estado (valor) y un
comportamiento (operaciones). Est formado por una estructura de datos
compleja y unas operaciones especficas definidas por el programador.
Los objetos en un OOPL slo existen durante la ejecucin del programa; por
consiguiente, se denominan objetos transitorios. Una base de datos OO
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. En otras palabras, las bases de datos OO
almacenan objetos persistentes permanentemente en almacenamiento
secundario, y permiten que se puedan compartir entre varios programas y
aplicaciones. Un sistema de bases de datos OO interacta con uno o ms
lenguajes de programacin OO a fin de proporcionar la funcionalidad de
objeto persistente y compartido.
Un objetivo de las bases de datos OO 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 OO
proporcionan un identificador de objeto (OID, object identifier) generado
por el sistema para cada objeto. Podemos comparar esto con el modelo
relacional, en el cual cada relacin debe tener un atributo de clave principal
cuyo valor identifique de forma nica a cada tupla.
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. Por lo tanto, una variable de instancia se parece al
concepto de atributo en el modelo relacional, excepto que las variables de
instancia pueden encapsularse dentro del objeto y, por tanto, no son
necesariamente visibles a los usuarios externos. Las variables de instancia
tambin pueden ser de tipos de datos arbitrariamente complejos.
Los sistemas orientados a objetos permiten la definicin de las operaciones
o funciones (comportamiento) que rueden aplicarse a los objetos de un tipo
concreto. De hecho, algunos modelos OO insisten en que todas las
operaciones que un usuario puede aplicar a un objeto deben predefinirse.
Esto obliga a un encapsulamiento completo de los objetos. Esta rgida
metodologa se ha relajado en la mayora de los modelos de datos OO por
varias razones. En primer lugar, el usuario de una base de datos a menudo
necesita conocer los nombres de atributo a fin de poder especificar las
condiciones de seleccin en los atributos para recuperar objetos especficos.
En segundo lugar, un encapsulamiento completo implica que cualquier
recuperacin sencilla requiere una operacin predefinida, lo que dificulta la
especificacin de consultas especficas sobre la marcha.
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. 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.
Otros conceptos importantes en los sistemas OO 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. Por tanto, la especificacin de tipos de
objetos puede proceder sistemticamente. 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.
Otro concepto OO es la sobrecarga del operador, que se refiere a la
posibilidad de que una operacin puede 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.

1.1.1. Identidad de objetos, estructura de objetos y constructores de

tipos.
Identidad del objeto

Un sistema de bases de datos OO proporciona una identidad nica a cada

objeto independiente almacenado en la base de datos. Esta identidad nica
suele implementarse mediante un identificador de objeto nico,
generado por el sistema, u 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 que debe tener un OID es la de ser inmutable, es
decir, el valor de ste para un objeto particular no cambia. Por lo tanto, un
sistema de bases de datos OO debe disponer de algn mecanismo de
generacin de OIDs y conservacin d0e 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. Estas dos propiedades implican que el OID no debe depender de
cualquier valor de atributo del objeto, puesto que el valor de atributo puede
cambiar o corregirse.

Estructura del objeto

En las bases de datos OO, 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 e l 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 (o
valor actual). El modelo de datos normalmente incluir varios constructores
de tipos. Los tres constructores ms bsicos son atom (atmico), tuple
(tupla) y set (conjunto). Otros constructores que tambin se utilizan
mucho son list (lista), bag (mochila) y array. El constructor atom se
utiliza para representar todos los valores atmicos bsicos, como enteros,
nmeros reales, cadenas de caracteres, booleanos y cualquier tipo de datos
bsico que el sistema soporte directamente.

El estado v de un objeto (i, c, v) se interpreta basndose en el constructor c.

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 {i1, i2, ..., in}, que son los OIDs de un conjunto de
objetos que normalmente son de algn tipo. Si c = tupla, el estado v es una
tupla de la forma <a1:i1, a2:i2, ..., an:im>, donde cada aj es un nombre de
atributo y cada ij es un OID. Si c = list, el valor v es una lista ordenada (i1,
i2, ..., ij) 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 referirnos al primer, segundo o j-simo objeto de una lista. Para c
= array, el estado v 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 bag
es que todos los elementos de un conjunto deben ser nicos, mientras que
una bolsa puede tener elementos duplicados.
Este modelo de objetos permite el anidamiento arbitrario de conjuntos,
listas, tuplas y otros constructores. El estado de un objeto que no es de tipo
atmico se referir a otros objetos por sus identificadores de objeto. Por lo
tanto, el nico caso donde aparece el valor real es en el estado de un objeto
de tipo atmico.
Ejemplo Objeto complejo
O1 = (i1, atom, 'Madrid')
O2 = (i2, atom, 'Valencia')
O3 = (i3, atom, 'Sevilla')
O4 = (i4, atom, 5)
O5 = (i5, atom, 'Investigacin')
O6 = (i6, atom, '22-05-1988')
O7 = (i7, set, {i1, i2, i3})
O8 = (i8, tuple, <NombreDpto:i5, NmeroDpto:i4, Dire:i9, Ubicaciones:i7,
Empleados:i10,
Proyectos:i11>)
O9 = (i9, tuple, <Dire:i12, FechalngresoDirector:i6>)
O10 = (i10, set, {i12, i13, i14})
O11 = (i11, set {i15, i16, i17})
O12 = (i12, tuple, <Nombre:i18, Apellido1:i19, Apellido2:i20, Dni:i21, ...,
Sueldo:i26, Supervisor:i27, Dept:i8)
En este modelo, un objeto se puede representar como una estructura de
grafo que puede construirse aplicando recursivamente los constructores de
tipos. El grafo que representa a un objeto Oi puede construirse creando
primero un nodo para el propio objeto Oi. El nodo para Oi se etiqueta con el
OID y el constructor del objeto c. Tambin creamos un nodo en el grafo para
cada valor atmico bsico. Si un objeto Oi tiene un valor atmico, dibujamos
un arco tendente desde el nodo que representa Oi hasta el nodo que
representa su valor bsico. Si construimos el valor del objeto, dibujamos
arcos tendentes desde el nodo del objeto hasta el nodo que representa el
valor construido.

Existen dos tipos de definiciones en una comparacin por igualdad de los

estados de dos objetos. Se dice que dos objetos tienen estados idnticos
(igualdad profunda) si los grficos que representan sus estados son
idnticos en cada respecto, incluyendo los OIDs de cada nivel. Por otro lado,
la definicin dbil de igualdad es cuando dos objetos tienen estados
iguales (igualdad poco profunda o superficial). En este caso, las estructuras
grficas deben ser iguales, y todos los valores atmicos correspondientes de
los grficos tambin deben ser iguales. Sin embargo, algunos nodos internos
correspondientes en los dos grficos pueden tener objetos con OIDs
diferentes.
Ejemplos Objetos idnticos frente a iguales
O1
O2
O3
O4
O5
O6

=
=
=
=
=
=

(i1,
(i2,
(i3,
(i4,
(i5,
(i6,

tuple, <a1:i4, a2:i6>)

tuple, <a1:i5, a2:i6>)
tuple, <a1:i4, a2:i6>)
atom, 10)
atom, 10)
atom, 20)

Los objetos O1 y O2 tienen estados de igualdad, puesto que sus estados a

nivel atmico son iguales, pero los valores se alcanzan a travs de los
objetos O4 y O5 distintos. No obstante, los estados de los objetos O1 y O3

son idnticos, aunque los propios objetos no lo son porque tienen OIDs
distintos. De forma parecida, aunque los estados de O4 y O5 son idnticos,
los objetos reales O4 y O5 son iguales pero no idnticos, porque tienen OIDs
distintos.

Constructores de tipo

Un lenguaje de definicin de objetos (ODL) que incorpora los

constructores de tipos anteriores se puede utilizar para definir los tipos de
objetos para una aplicacin de base de datos particular.
Los constructores de tipo pueden utilizarse para definir las estructuras de
datos para un esquema de base de datos OO.
Palabras claves utilizadas: tupla, set y list para los constructores de tipo, y
los tipos de datos estndar disponibles (integer, string, float, etctera) para
los tipos atmicos.
Ejemplo: Especificacin de los tipos de objeto EMPLEADO, FECHA y
DEPARTAMENTO utilizando los constructores de tipo.

1.2. Encapsulacin de operaciones, mtodos y persistencia.

El concepto de encapsulamiento es una de las principales caractersticas
de los lenguajes y sistemas OO. Tambin est relacionado con los conceptos
de tipos de datos abstractos y ocultacin de informacin en los lenguajes de
programacin. En los modelos y sistemas de bases de datos tradicionales,
este concepto no se aplicaba porque lo habitual era que la estructura de los
objetos de la base de datos fuera visible para los usuarios y programas
externos.

1.2.1. Especificacin del comportamiento del objeto mediante

operaciones de clase.
Los conceptos de ocultacin de informacin y encapsulamiento pueden
aplicarse a los objetos de bases de datos. La idea principal es definir el
comportamiento de un tipo de objeto basndose 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 (insertar, eliminar, actualizar

estado, recuperar estado del objeto para clculos o combinacin de las

anteriores). 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.
Los usuarios externos del objeto slo son conscientes de la interfaz del tipo
objeto, que define el nombre y los argumentos (parmetros) de cada
operacin. La implementacin se oculta a los usuarios externos; esto incluye
la definicin de las estructuras de datos internas del objeto y la
implementacin de las operaciones que acceden a esas estructuras. En la
terminologa OO, la parte de interfaz de cada operacin se denomina firma,
y la implementacin de la operacin se denomina mtodo. Normalmente,
un mtodo es invocado enviando un mensaje al objeto para ejecutar el
mtodo correspondiente.
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. En la mayora de
los casos, las operaciones que actualizan el estado de un objeto se
encapsulan.
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.
Una operacin se aplica normalmente a un objeto utilizando la notacin de
punto, esta tambin se utiliza para referirnos a los atributos de un objeto.
Ejemplo:

1.2.2. Especificacin de la persistencia de objetos a travs del

mecanismo de nombramiento y alcanzabilidad.
No todos los objetos se guardan permanentemente en la base de datos. Los
objetos transitorios existen en el programa que se est ejecutando y
desaparecen una vez que ese programa termina. Los objetos persistentes
se almacenan en la base de datos y persisten despus de la terminacin del
programa. Los mecanismos tpicos para hacer que un objeto sea persistente
son la denominacin y la nocin de alcance (reachability).
El mecanismo de denominacin implica asignar a un objeto un nombre
persistente nico con el que el programa actual y otros programas pueden
recuperarlo. Los nombres que se suministran a los objetos han de ser nicos
dentro de la base de datos particular. Los objetos persistentes denominados
se utilizan como puntos de entrada a la base de datos a travs de los
cuales los usuarios y las aplicaciones pueden iniciar su acceso a la base de
datos. Obviamente, no resulta prctico asignar un nombre a todos los

objetos de una base de datos grande que incluye miles de objetos, por lo
que la mayora de los objetos se hacen persistentes utilizando el segundo
mecanismo, denominado 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.
Ejemplo:

Si primero creamos un objeto persistente denominado N, cuyo estado es un

conjunto o una lista de objetos de alguna clase C, podemos conseguir que
los objetos de C sean persistentes aadindolos al conjunto o la lista, y
hacindolos as alcanzables o accesibles desde N. Por tanto, N refine una
coleccin persistente de objetos de clase C. Por ejemplo, podemos definir
una clase CONJUNTO_DPTO cuyos objetos sean de tipo set(DEPARTAMENT0).
Supongamos que creamos un objeto de tipo CONJUNTO_DPTO y que le
asignamos el nombre
TODOS_DEPARTAMENTOS, convirtindolo as en persistente. Cualquier
objeto DEPARTAMENTO que aadamos al conjunto de
TODOS_DEPARTAMENTOS utilizando la operacin agregar_dept se convertir
en persistente por ser alcanzable desde TODOS_DEPARTAMENTOS. El objeto
TODOS_DEPARTAMENTOS se denomina con frecuencia extensin de la
clase DEPARTAMENTO, pues albergar todos los objetos persistentes de tipo
DEPARTAMENTO.

2. Herencia y jerarquas de tipos y clases

Otra caracterstica importante de los sistemas de bases de datos 00 es que
permiten las jerarquas de tipos y la herencia.

2.1. Jerarqua de tipo y herencia.

En la mayora de las aplicaciones de bases de datos, hay numerosos objetos

del mismo tipo o clase. Por tanto, las bases de datos OO deben proporcionar
la posibilidad de clasificar los objetos por su tipo, como hacen otros
sistemas de bases de datos. Pero en las bases de datos OO, un requisito
aadido es que el sistema permita la definicin de nuevos tipos basndose
en otros tipos predefinidos, cargndolos en una jerarqua de tipos (o
clases).
Normalmente, un tipo o clase, 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
de funciones, ya que los atributos se parecen a funciones sin argumentos.
El nombre de una funcin lo podemos utilizar para referirnos al valor de un
atributo o al valor resultante de una operacin (mtodo). Utilizamos el
trmino funcin para referirnos indistintamente a los atributos y las
operaciones de un tipo objeto, ya que se tratan de una forma parecida en
una introduccin bsica a la herencia.
Un tipo en su forma ms simple puede definirse asignndole un nombre de
tipo y, despus, enumerando los nombres de sus funciones visibles
(pblicas).
NOMBRE_ TIPO: funcin, funcin(), ..., funcin
PERSONA: Nombre, Dlrecc, FechaNac, Edad(FechaActual-FechaNac), Dni
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.
EMPLEADO: Nombre, Dlrecc, FechaNac, Edad, Dni, Sueldo, FechaContrato,
TiempoEnEmpresa
ESTUDIANTE: Nombre, Dlrecc, FechaNac, Edad, Dni, Especialidad, NotaMedla
EMPLEADO subtipo-de PERSONA: Sueldo, FechaContrato,
TlempoEnEmpresa
ESTUDIANTE subtipo-de PERSONA: Especialidad, NotaMedla
Otro ejemplo:
OBJETO_GEOMTRICO: Forma, rea, PuntoReferencla
RECTNGULO subtipo-de OBJETO_GEOMTRICO: Anchura, Altura
TRINGULO subtipo-de OBJETO_ GEOMTRICO: Lado1, Lado2, ngulo
CIRCULO 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. Algunos sistemas de bases de
datos OO permiten renombrar las funciones heredadas en subtipos
diferentes para reflejar el significado de un modo ms exacto. Un modo
alternativo de declarar estos subtipos consiste en especificar el valor del
atributo Forma como una condicin que debe cumplirse para los objetos de
cada subtipo.

RECTNGULO subtipo-de OBJETO_ GEOMTRICO (Forma='rectngulo'):

Anchura, Altura
TRINGULO subtipo-de OBJETO_ GEOMTRICO (Forma='Tringulo'): Lado1,
Lado2, ngulo
CIRCULO subtipo-de OBJETO_GEOMTRICO (Forma='circulo'): Radio
Las definiciones de tipo describen objetos, pero no los generan.
Simplemente son declaraciones de ciertos tipos; y como parte de esa
declaracin, se especfica la implementacin de las funciones de cada tipo.
Al crear un objeto, normalmente pertenece a uno o ms de esos tipos que
se han declarado. Por ejemplo, un objeto crculo es de tipo CIRCULO y
OBJETO_GEOMTRICO (por herencia).
Cada objeto tambin se convierte en miembro de una o ms colecciones de
objetos persistentes (o extensiones), que se utilizan para agrupar
colecciones de objetos que son significativos para la aplicacin de bases de
datos.

2.2. Restricciones sobre extensiones correspondientes a una jerarqua

de tipos.
En la mayora de las bases de datos OO, la coleccin de datos de una
extensin (extent) tiene el mismo tipo o clase. Sin embargo, no es una
condicin necesaria (SmalTalk sin tipo).
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. En este caso, 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.

3. Objetos complejos
Una motivacin importante que llev al desarrollo de sistemas OO fue el
deseo de representar objetos complejos. Hay dos tipos principales de
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.

3.1. Objetos complejos no estructurados y extensibilidad de tipos.

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 son
las imgenes de mapas de bits (bitmaps) y las cadenas de texto largas
(documentos); tambin se conocen como objetos binarios grandes (BLOBs,
binary large objects). Las cadenas de caracteres tambin se denominan
objetos grandes de caracteres (CLOBs, character large objects). Estos
objetos no estn estructurados en el sentido de que el DBMS no conoce su
estructura (slo la aplicacin que los utiliza puede interpretar su
significado).
Debido a que el tamao del objeto es muy grande, un DBMS puede
recuperar una porcin del objeto y suministrrsela a la aplicacin antes de

que se recupere el objeto entero. El DBMS tambin utiliza las tcnicas de

almacenamiento en bfer y en cach.
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.
Como un OODBMS permite a los usuarios crear tipos nuevos, y como un tipo
incluye tanto estructura como operaciones, podemos ver un OODBMS como
que tiene un sistema de tipos extensible. Podemos crear libreras de
tipos nuevos definiendo su estructura y sus operaciones, incluyendo los
tipos complejos.

3.2. 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. Por tanto, la estructura del objeto est
definida y es conocida por el OODBMS.
Entre un objeto complejo y sus componentes en cada nivel, existen dos
tipos de semntica de referencia. El primer tipo, que podemos denominar
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 segundo tipo, que podemos
denominar 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 primer tipo tambin recibe el nombre de relacin es-parte-de o escomponente-de; y el segundo tipo se denomina relacin est-asociado-con,
puesto que describe una asociacin de igualdad entre dos objetos
independientes. 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.
Ejemplo
DEPARTAMENTO: NombreDpto, NmeroDpto, Dlre, Ubicaciones, Empleados y
Proyectos.

Los atributos NombreDpto, NmeroDpto, Dlre y Ubicaciones son propiedad

de un DEPARTAMENTO, mientras que Empleados y Proyectos son referencias
porque hacen referencia a objetos independientes.

4. Otros conceptos de orientacin a objetos.

4.1. Polimorfismo (sobrecarga de operadores).
Otra caracterstica de los sistemas OO 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 (Ejemplo:
operador + en distintos objetos [suma, unin de conjuntos]).
Tomando el ejemplo del OBJETO_GEOMETRICO, 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. Una posibilidad es contar con una
implementacin general que calcule el rea de un OBJETO_ GEOMTRICO
generalizado (por ejemplo, escribiendo un algoritmo general para calcular el
rea de un polgono) y despus reescribir algoritmos ms eficaces para
calcular las reas de objetos geomtricos de tipos especficos, como
crculos, rectngulos, tringulos, etctera. En este caso, la funcin rea se
sobrecarga a causa de las diferentes implementaciones.
El OODBMS debe seleccionar ahora el mtodo apropiado para la funcin
rea en base al tipo de objeto geomtrico al que se aplica.
o
o

Sistemas fuertemente tipados: en tiempo de compilacin, ya que los

tipos de objeto deben conocerse. Es lo que se denomina vinculacin
temprana (o esttica).
Sistemas con tipado dbil o sin tipado (como Smalltalk y LISP): la
funcin debe comprobar en tiempo de ejecucin el tipo de objeto y,
despus, invocar el mtodo adecuado. Es lo que a menudo se
denomina vinculacin posterior (o dinmica).

4.2. Herencia mltiple y herencia selectiva.

La herencia mltiple en una jerarqua de tipos se da cuando un
determinado subtipo es un subtipo de dos (o ms) tipos y, por tanto, hereda
las funciones (atributos y mtodos) de los dos supertipos. Por ejemplo,
podemos s crear el subtipo DIRECTOR_INGENIERIA que es un subtipo de
DIRECTOR e INGENIERO. Esto lleva a la creacin de una red de tipos ms
que de una jerarqua de 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.
Hay varias tcnicas para tratar la ambigedad en la herencia mltiple:
El sistema comprueba si hay ambigedad en el momento de crear el
subtipo, y deja que el usuario seleccione explcitamente en ese
momento la funcin que se heredar.
Utilizar alguna seleccin predeterminada del sistema.
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 los supertipos.
Algunos sistemas OO no permiten en absoluto la herencia mltiple.

4.3. Versiones y configuracin.

Muchas de las aplicaciones que utilizan sistemas OO requieren la existencia
de varias versiones del mismo objeto. Un OODBMS debe poder guardar y
manipular varias versiones del mismo objeto conceptual. Varios sistemas
proporcionan esta capacidad, permitiendo que la aplicacin mantenga
varias versiones de un objeto y se refiera explcitamente a versiones
particulares segn las necesidades. No obstante, el problema de mezclar y
reconciliar los cambios introducidos en dos versiones diferentes
normalmente se deja a los desarrolladores de la aplicacin, que conocen la
semntica de la misma.

UNIDAD II: ESTNDARES, LENGUAJES Y DISEO DE BASES

DE DATOS DE OBJETOS
Es muy importante tener un estndar para un determinado tipo de sistema
de bases de datos, porque proporciona soporte para la portabilidad de
aplicaciones de bases de datos. La portabilidad se define generalmente
como la capacidad de ejecutar un programa de aplicacin en particular en
diferentes sistemas con unas modificaciones mnimas en el propio
programa. En el campo de las bases de datos de objetos, la portabilidad
permitira que un programa escrito para acceder a un sistema gestor de
bases de datos de objetos (ODBMS) pudiera acceder a otro paquete ODBMS
siempre y cuando los dos paquetes soportaran fielmente el estndar.
Una segunda ventaja potencial de tener y obedecer unos estndares es que
ayuda a conseguir la interoperabilidad, que generalmente se refiere a la
posibilidad de que una aplicacin acceda a varios sistemas distintos. En lo
relativo a las bases de datos, esto significa que el mismo programa de
aplicacin puede acceder a algunos datos almacenados bajo un paquete
ODBMS, y a otros datos almacenados bajo otro paquete.
Una de las razones del xito de los DBMSs relacionales comerciales es el
estndar SQL. La ausencia de un estndar para los ODBMSs durante varios
aos puede haber provocado que usuarios potenciales hayan dejado de
convertirse a esta nueva tecnologa. En consecuencia, 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.

1. Visin general del modelo de objetos de ODMG

El modelo de objetos 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. Por tanto, se
pretenda ofrecer un modelo de datos estndar para las bases de datos de
objetos, al igual que SQL describe un modelo de datos estndar para las
bases de datos relacionales.

1.1. Objetos y literales.

Los objetos y los literales son los bloques constructivos bsicos del modelo
de objeto. La principal diferencia entre los dos es que un objeto tiene un
identificador de objeto y un estado (o valor actual), mientras que un literal
tiene un valor pero no un identificador de objeto. En todo caso, el valor
puede tener una estructura compleja. El estado de un objeto puede cambiar
con el transcurso del tiempo modificando el valor del objeto. Un literal es
bsicamente un valor constante, posiblemente con una estructura compleja
que no cambia.
Un objeto queda descrito por cuatro caractersticas: identificador, nombre,
tiempo de vida (ciclo de vida) y estructura.
El identificador de objeto es un identificador nico para todo el
sistema (u Object_ld). Todo objeto debe tener un identificador de
objeto.
Adems del Object_ld, opcionalmente podemos asignar un nombre
nico a algunos objetos dentro de la base de datos particular. Estos
nombres se utilizan como puntos de entrada a la base de datos, es
decir que localizando esos objetos por su nombre nico, el usuario
puede localizar despus otros objetos a los que se hace referencia
desde esos objetos.
El tiempo de vida de un objeto especifica si es un objeto persistente
o un objeto transitorio.
Por ltimo, la estructura de un objeto especifica cmo se construye
el objeto utilizando los constructores de tipos. La estructura
especifica si un objeto es atmico o un conjunto coleccin. El trmino
objeto atmico es diferente a la definicin que dimos para constructor
atmico. En el modelo ODMG, un objeto atmico es cualquier objeto
que no es una coleccin; por consiguiente, esto abarca los objetos
estructurados creados con el constructor struct (constructor de tupla).
En un modelo de objeto, un literal es un valor que no tiene un identificador
de objeto. Sin embargo, el valor puede tener una estructura simple o
compleja. Hay tres tipos de literales: atmico, coleccin y estructurado.
Los literales atmicos corresponden a los valores de los tipos de
datos bsicos y estn predefinidos. Los tipos de datos bsicos del
modelo de objeto son long, short, unsigned long, unsigned short,
float, double, boolean, char, string, enum, adems de otros.
Los literales estructurados se corresponden aproximadamente con
los valores que se construyen utilizando el constructor de tupla.
Incluyen la fecha, el intervalo, la hora y la marca de tiempo como
estructuras integradas, as como cualquier estructura de tipo definida
por el usuario adicional que cada aplicacin necesite. Las estructuras
definidas por el usuario se crean utilizando la palabra clave struct de
ODL, al igual que en los lenguajes de programacin C y C++.

Los literales de coleccin especifican un valor que es una coleccin

de objetos o valores, pero la propia coleccin no tiene un identificador
de objeto. Las colecciones del modelo de objeto son set<T>,
bag<T>, list<T> y array<T>, donde T es el tipo de objetos o valores
de la coleccin.

La notacin de ODMG utiliza la interfaz de palabras clave donde nosotros

habamos utilizado las palabras clave type (tipo) y class (dase). De hecho,

interfaz es un trmino ms apropiado, ya que describe la interfaz de tipos

de objetos (atributos, relaciones y operaciones visibles). Normalmente,
estas interfaces no son instanciables(es decir, no se crean objetos para la
interfaz), pero sirven para definir operaciones que los objetos definidos por
el usuario pueden heredar para una aplicacin en particular. La palabra
clave clase en el modelo de objeto est reservada para las declaraciones de
clase especificadas por el usuario.
En el modelo de objeto, todos los objetos heredan la interfaz bsica de
Object. En general, las operaciones se aplican mediante la notacin de
punto ( P.igual(O) ).Una alternativa a la notacin de punto es la notacin
de flecha ( P->igual(0) ).
La herencia de tipo, que se utiliza para definir las relaciones tipo/subtipo, se
especifica en el modelo de objetos utilizando la notacin de los dos
puntos(:)

1.2. Interfaces predefinidas de coleccin para objetos de coleccin.

Cuando los usuarios diseen el esquema de una base de datos, declararn
sus propias interfaces de objeto y clases relativas a la aplicacin de bases
de datos. Si una interfaz o clase es uno de los objetos coleccin (por
ejemplo, un conjunto), entonces heredar las operaciones de la interfaz set.
Por ejemplo, en una aplicacin de bases de datos UNIVERSIDAD, el usuario
puede especificar una clase para set<ESTUDIANTE>, cuyos objetos seran
conjuntos de objetos ESTUDIANTE. El programador puede utilizar entonces
las operaciones para set<T> a fin de manipular un objeto de tipo
set<ESTUDIANTE>. La creacin de clases de aplicacin normalmente se
hace utilizando el lenguaje de definicin de objetos ODL.
Es importante resear que todos los objetos de una coleccin concreta
deben ser del mismo tipo.

1.3. Objetos atmicos (definidos por el usuario).

Se especifican mediante la palabra clave class en ODL. En el modelo de
objeto, cualquier objeto definido por el usuario y que no es un objeto
coleccin se denomina objeto atmico.
Por ejemplo, en una aplicacin de bases de datos UNIVERSIDAD, el usuario
puede especificar un tipo de objeto (class) para los objetos ESTUDIANTE. La
mayora de esos objetos sern objetos estructurados, por ejemplo un
objeto ESTUDIANTE tendr una estructura compleja, con muchos atributos,
relaciones y operaciones, pero se le seguir considerando atmico porque
no es una coleccin. Este objeto atmico definido por el usuario se define
como una clase especificando sus propiedades y sus operaciones. Las
propiedades definen el estado del objeto y se distinguen adems en
atributos y relaciones.
Un atributo (attribute) es una propiedad que describe algn aspecto de
un objeto. Los atributos tienen valores (normalmente son literales que
tienen una estructura sencilla o compleja) que estn almacenados dentro
del objeto. Sin embargo, los valores de los atributos tambin pueden ser
Object_lds de otros objetos. Los valores de atributo pueden especificarse
incluso a travs de mtodos que se utilizan para calcular el valor del
atributo.

Una relacin (relationship) es una propiedad que especifica que dos

objetos de Ja base de datos estn relacionados. En el modelo de objeto de
ODMG, slo las relaciones binarias se representan explcitamente, y cada
relacin binaria se representa mediante un par de referencias inversas
especificado mediante la relacin de palabra clave. La palabra clave
Inversa (inverse) indica que estas dos propiedades especifican una
relacin conceptual sencilla en direcciones inversas. Al especificar lo
inverso, el sistema de bases de datos puede conservar automticamente la
integridad referencial de la relacin. Si el diseador de la base de datos
desea tener una relacin que slo se represente en una direccin, tiene que
modelarla como W1 atributo (u operacin).
Adems de los atributos y las relaciones, el diseador puede incluir
operaciones en las especificaciones del tipo de objeto (clase). Cada tipo de
objeto puede tener varias firmas de operaciones, que especifican el
nombre de la operacin, sus tipos de argumentos y el valor que devuelve, si
es aplicable. Los nombres de las operaciones son nicos dentro de cada tipo
de objeto, pero pueden sobrecargarse si el mismo nombre de operacin
aparece en distintos tipos de objeto. La firma de operacin tambin puede
especificar los nombres de las excepciones que pueden darse durante la
ejecucin de la operacin.

2. Interfaces, clases y herencia:

2.1. Interfaces predefinidas, clases definidas por el usuario y tipos de
herencia.
En el modelo de objeto ODMG, hay dos conceptos para especificar los tipos
de objetos: interfaces y clases. Adems, existen dos tipos de relaciones de
herencia. Siguiendo con la terminologa ODMG, utilizamos la palabra
comportamiento para referirnos a las operaciones, y estado para
referirnos a las propiedades (atributos y relaciones).
Una interfaz es una especificacin del comportamiento abstracto de un
tipo de objeto, que especifica las firmas de operacin. Aunque una interfaz
puede tener propiedades de estado (atributos y relaciones) como parte de
sus especificaciones, stas no pueden ser heredadas de la interfaz. Una
interfaz es no instanciable, es decir, no podemos crear objetos que
correspondan a una definicin de interfaz.
Una clase es una especificacin del comportamiento abstracto y del estado
abstracto de un tipo de objeto, y es instanciable (es decir, podernos crear
instancias de objetos individuales que es equivalente a la definicin de una
clase).
Como las interfaces no son instanciables, se utilizan principalmente para
especificar operaciones abstractas que las clases y otras interfaces pueden
heredar. Es lo que se denomina herencia de comportamiento y se
especifica con la notacin de los dos puntos (:). Por tanto, en el modelo de
objeto ODMG, la herencia del comportamiento requiere que el supertipo sea
una interfaz, mientras que el subtipo puede ser una clase u otra interfaz.
Otra relacin de herencia, denominada EXTENDS y especificada con la
palabra clave extends, se utiliza para heredar el estado y el
comportamiento estrictamente entre clases. En una herencia de extensin,
tanto el supertipo como el subtipo han de ser clases. La herencia mltiple a

travs de extends no est permitida. Sin embargo, la herencia mltiple s

est permitida para la herencia del comportamiento. Por tanto, una interfaz
puede heredar el comportamiento de otras interfaces. Una clase tambin
puede heredar el comportamiento de varias interfaces, adems de heredar
el comportamiento y el estado de, a lo sumo, una clase va extends.

2.2. Extensiones, claves y objetos factora.

En el modelo de objeto ODMG, el diseador de la base de datos puede
declarar una extensin (utilizando la palabra clave extent) para cualquier
tipo de objeto que se define mediante una declaracin de dale. La extensin
tiene un nombre y contendr todos los objetos persistentes de la clase. Las
extensiones tambin se utilizan para implementar automticamente la
relacin conjunto/subconjunto entre las extensiones de un supertipo y su
subtipo.
Una clase con una extensin puede tener una o ms claves. Una clave
consta de una o ms propiedades (atributos o relaciones) cuyos valores se
restringen para ser nicos de cada objeto de la extensin. En el caso de una
clave compuesta formada por varias propiedades, estas ltimas deben ir
entre parntesis (Clave1, Clave2).
Un objeto factory, es un objeto que puede utilizarse para generar o crear
objetos individuales a travs de sus operaciones. Un objeto factory
proporciona bsicamente las operaciones de constructor para los objetos
nuevos.
Por ultimo el concepto de database. Como un ODBMS puede crear muchas
bases de datos diferentes, cada una con su propio esquema, el modelo de
objeto ODMG tiene interfaces para los objetos databaseFactory y Database.
Cada base de datos tiene un nombre de base de datos propio, y es posible
utilizar la operacin bind para asignar nombres nicos individuales a los
objetos persistentes de una base de datos concreta. La operacin lookup
devuelve el objeto de la base de datos cuyo nombre es el especificado con
object_name, y la operacin unbind elimina el nombre de un objeto
nombrado persistente de la base de datos.

2.3. Lenguaje de definicin de objetos ODL.

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.

UNIDAD III: LENGUAJE DE CONSULTA DE OBJETOS: OQL

1. 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. Por tanto, una
consulta OQL incrustada en uno de estos lenguajes de programacin puede
devolver objetos que coincidan con el sistema de tipos de ese lenguaje.
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.

1.1. Consultas simples en OQL, puntos de entrada a base de datos y

variable iterador.
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:
C0:

select D.NombreDpto
from D In DEPARTAMENTOS
where O.Facultad= 'Ingeniarla';

En general, necesitamos un punto de entrada a la base de datos para

cada consulta, que puede ser cualquier objeto persistente con nombre. Para
muchas consultas, el punto de entrada es el nombre de la extent de una
clase (nombre de un objeto persistente cuyo tipo es una coleccin, en
muchos casos, un conjunto de objetos de la clase).
El uso de un nombre de extensin (DEPARTAMENTOS en C0) como punto de
entrada se refiere a una coleccin persistente de objetos. Siempre que en
una consulta OQL se hace referencia a una coleccin, debemos definir una
variable iteradota (D en C0) que recorra los objetos de la coleccin. En
muchos casos, como en C0, la consulta seleccionar ciertos objetos de la
coleccin, basndose en las condiciones especificadas en la clusula where.
En C0, slo los objetos persistentes D de la coleccin de DEPARTAMENTOS
que satisfacen la condicin D.Facultad = 'Ingeniarla' son seleccionados para
el resultado de la consulta. Para cada objeto seleccionado D, el valor de
D.NombreDpto es recuperado en el resultado de la consulta. Por tanto, el
tipo del resultado para C0 es bag<strlng> porque el tipo de cada valor de
NombreDpto es strlng. En general, el resultado de una consulta sera de
tipo bag para select ... from ... y de tipo set para select dlstinct ... from ...,
como en SQL (al aadir la palabra clave distinct se eliminan los duplicados).
Hay tres opciones sintcticas para especificar las variables iteradoras:
o D IN DEPARTAMENTOS
o DEPARTAMENTOS D
o DEPARTAMENTOS AS D
o
Los objetos con nombre utilizados como puntos de entrada para las
consultas OQL no estn limitados a los nombres de extensiones. Es posible
utilizar cualquier objeto persistente con nombre, tanto si se refiere a un
objeto atmico (sencillo) como a un objeto coleccin, como punto de
entrada a la base de datos.

1.2. Resultados de consultas y expresiones de caminos.

En general, el resultado de una consulta puede ser de cualquier tipo que
pueda expresarse en el modelo de objeto ODMG. Una consulta no tiene que
obedecer la estructura select ... from ... where ..., en el caso ms sencillo,
cualquier nombre persistente ya es una consulta de por s, cuyo resultado es
una referencia a ese objeto persistente. Por ejemplo, la siguiente consulta,
devuelve una referencia a la coleccin de objetos DEPARTAMENTO
persistentes, cuyo tipo es set<DEPARTAMENTO>.
C1: DEPARTAMENTOS;
De forma parecida, supongamos que hubiramos dado un nombre
persistente CC_DEPARTAMENTO a un objeto DEPARTAMENTO sencillo, en
este caso, la siguiente consulta devuelve una referencia a ese objeto
individual de tipo DEPARTAMENTO.

C1A: CC_DEPARTAMENTO;
Una vez especificado un punto de entrada, el concepto de expresin de
ruta puede utilizar para especificar una ruta de acceso a los atributos y los
objetos relacionados. Una expresin de ruta normalmente empieza con el
nombre de un objeto persistente, o con la variable iteradora que recorre los
objetos individuales de una coleccin. Este nombre ir seguido por ninguno
o ms nombres de relacin o nombres de atributo conectados mediante un
punto
C2: CC_DEPARTAMENTO.Director;
C2A: CC_DEPARTAMENTO.Director.Rango;
C28: CC_DEPARTAMENTO.Tlene_docentes;
Las expresiones de ruta C2 y C2A devuelven valores sencillos, porque los
atributos Director (de DEPARTAMENTO) y Rango (de DOCENTE) son de un
solo valor y se aplican a un solo objeto. La tercera expresin C2B, es
diferente, devuelve un objeto de tipo set<DOCENTE>.
Problemas de ambigedad:
C3': CC _DEPARTAMENTO.Tiene_ docentes. Rango;
No est claro si el objeto devuelto sera de tipo set<strlng> o de tipo
bag<strlng>. Debido a este problema de ambigedad, OQL no permite
expresiones como las de C3'. En su lugar, es preciso utilizar una variable
iteradota sobre estas colecciones, como en C3A o C3B:
C3A:

select F.Rango
from F In CC_DEPARTAMENTO.Tlene_ docentes;
C38: select distinct F.Rango
from F In CC_DEPARTAMENTO.Tlene_ docentes;
Aqu, C3A devuelve bag<strlng> (en el resultado aparecen valores de rango
duplicados), mientras que C3B devuelve set<strlng> (los duplicados se
eliminan gracias a la palabra clave distinct).
En general, una consulta OQL puede devolver un resultado con una
estructura compleja especificada en la propia consulta utilizando struct.
Consideremos los siguientes ejemplos:
C4:

CC_DEPARTAMENTO.Dlrector.Tutorlza;

C4A: select struct ( nombre: struct( apellldo1: S.nombre.Apellldo1,

nombre_plla: S.nombre.NombreP).
licenclatura:(select struct (
lic: D.Titulo,
an: D.Ao,
facultad: D.Facultad)
from D In S.Llcenclatura)
from S In CC_DEPARTAMENTO.Dlrector.Tutorlza;
Aqu, C4 es directa, devolviendo un objeto de tipo
set<ESTUDIANTE_DIPLOMADO> como resultado; es la coleccin de

estudiantes graduados tutorizados por el director del departamento de

informtica. Supongamos ahora que necesitamos una consulta para
recuperar los nombres y los apellidos de esos estudiantes graduados y los
ttulos que tiene cada uno. Lo podemos escribir como en C4A, donde la
variable S recorre la coleccin de estudiantes graduados tutorizados por el
director, y la variable D recorre los ttulos de cada estudiante S.
El tipo del resultado de C4A es una coleccin de estructuras (primer nivel)
donde cada una de ellas tiene dos componentes: nombre y licenciatura. El
componente nombre es, a su vez, es una estructura compuesta por apellido
y nombre_plla, que son cadenas sencillas. El componente licenciatura est
definido por una consulta incrustada y es, a su vez, una coleccin de otras
estructuras (segundo nivel), cada una de tres componentes: lic, an y
facultad.
OQL es ortogonal respecto a la especificacin de expresiones de ruta; es
decir, podemos utilizar atributos, relaciones y operaciones (mtodos) en
estas expresiones, siempre que el sistema de tipos de OQL no se vea
comprometido.
La clusula order by es parecida a la equivalente en SQL, y especifica el
orden en el que se visualizar el resultado de la consulta. Por tanto, la
coleccin devuelta por una consulta con una clusula order by es de tipo
lista.

UNIDAD IV: DISEO CONCEPTUAL DE BASE DE DATOS DE

OBJETOS
1. Diseo conceptual de una BDO y de una BDR.
1.1. Diferencias entre el diseo conceptual de una BDO y una BDR.
Una de las principales diferencias entre el diseo BDO y el diseo BDR es la
manipulacin de las relaciones. En BDO, las relaciones normalmente se
manipulan teniendo propiedades de relacin o atributos de referencia que
incluyen OID(s) de los objetos relacionados. Se pueden considerar como
referencias OID a los objetos relacionados. Estn permitidas tanto las
referencias sencillas como las colecciones de referencias. Las referencias
para una relacin binaria slo se pueden declarar en una direccin, o en
ambas direcciones, en funcin de los tipos de acceso esperados. Si la
declaracin es en ambas direcciones, deben especificarse como inversas
entre s, cumplindose as el equivalente BDO de la restriccin de integridad
referencial relacional.
En BDR, las relaciones entre tuplas (registros) se especifican mediante
atributos con valores coincidentes, que pueden considerarse como
referencias de valor y se especifican a travs de foreign keys (claves
externas), que son valores de los atributos clave principales repetidos en
tuplas de la relacin referida. Tienen que ser monovalor en cada registro
porque los atributos multivalor no estn permitidos en el modelo relacional
bsico. Por tanto, las relaciones M:N no deben representarse directamente,
sino corno una relacin separada (tabla).
El mapeo de relaciones binarias que contienen atributos no es directo en los
BDOs, ya que el diseador debe elegir la direccin en la que deben incluirse

los atributos. Si los atributos se incluyen en las dos direcciones, existir

redundancia en almacenamiento, lo que puede llevar a unos datos
inconsistentes. En consecuencia, a veces es preferible utilizar el mtodo
relacional consistente en crear una tabla independiente mediante la
creacin de una clase separada para representar la relacin. Este mtodo
tambin se puede utilizar para las relaciones
n-arias, con un grado n > 2.
Otra rea importante en la que se diferencia el diseo BDO y el diseo BDR
es la manipulacin de la herencia. En BDO, estas estructuras se integran en
el modelo, por lo que el mapeado se consigue utilizando las construcciones
de herencia como derivadas (:) y EXTENDS. En el diseo relacional, hay
varias opciones entre las que elegir, ya que no existen construcciones
integradas para la herencia en el modelo relacional bsico.
La tercera diferencia importante es que en el diseo BDO es necesario
especificar las operaciones en una fase temprana del diseo, porque forman
parte de las especificaciones de clase. Aunque es importante especificar
durante la fase de diseo las operaciones para todos los tipos de bases de
datos, en el diseo BDR es una tarea que se puede demorar hasta la fase de
implementacin.
Hay una diferencia filosfica entre el modelo relacional y el modelo de
objetos de datos en lo que se refiere a la especificacin del comportamiento.
En el modelo relacional no es obligatorio predefinir un conjunto de
comportamientos u operaciones vlidos, mientras que es un requisito tcito
en el modelo de objetos. Una de las ventajas demandadas del modelo
relacional es el soporte de consultas y transacciones especficas
considerando que van contra el principio de encapsulamiento.

1.2. Mapeado de un esquema EER a un esquema ODB.

Es relativamente rpido disear las declaraciones de tipos de las clases de
objetos para un ODBMS a partir de un esquema DER que no contiene
categoras ni relaciones n-arias con n > 2. Sin embargo, en el diagrama DER
no se especifican las operaciones de clases y deben aadirse a las
declaraciones de clase una vez completado el mapeado estructural.
Paso 1: Cree una clase ODL para cada tipo de entidad o subclase DER. El
tipo de la clase ODL debe incluir todos los atributos de la clase DER. Los
atributos multivalor se declaran utilizando los constructores de conjunto,
bolsa o lista. Si los valores del atributo multivalor para un objeto deben
estar ordenados, debe elegir el constructor de lista; si estn permitidos los
duplicados, debe elegir el constructor de bolsa; en caso contrario, debe
elegir el constructor de conjunto. Los atributos compuestos se mapean en
un constructor de tupla (utilizando una declaracin struct en ODL).
Declare una extensin para cada clase y especifique los atributos clave
como claves de la extensin. (Esto slo es posible si el ODBMS cuenta con
un servicio de extensin y declaraciones de restriccin de clave.)
Paso 2: Aada propiedades de relacin o atributos de referencia para cada
relacin binaria en las clases ODL que participen en la relacin. Esto lo

puede crear en una o en las dos direcciones. Si una relacin binaria est
representada por referencias en las dos direcciones, declare las referencias
para que sean propiedades de la relacin inversas entre s, si existe tal
posibilidad. Si una relacin binaria est representada por una referencia en
una sola direccin, declare la referencia para que sea un atributo en la clase
de referencia cuyo tipo es el nombre de la clase referenciada.
En1 funcin de la razn de cardinalidad de la relacin binaria, las
propiedades de relacin o los atributos de referencia pueden ser tipos
monovalor o colecciones. Sern monovalor para las relaciones binarias en
las direcciones 1: 1 o N: 1; sern tipos coleccin (conjunto o lista) para las
relaciones en la direccin 1:N o M:N.
Si existen atributos de relacin, puede utilizar un constructor de tupla
(struct) para crear una estructura de la forma <referencia, atributos
relacin>, que puede incluir en sustitucin del atributo de referencia. Sin
embargo, esto no permite el uso de la restriccin inversa. Adems, si
representa esta opcin en las dos direcciones, los valores de atributo se
representarn dos veces, lo que dar lugar a redundancia.
Paso 3: Incluya las operaciones adecuadas para cada clase. No estn
disponibles a partir del esquema DER y debe aadirlas al diseo de la base
de datos haciendo referencia a los requisitos originales. Un mtodo
constructor debe incluir cdigo de programa que compruebe las
restricciones que deban mantenerse cuando se crea un objeto. Un mtodo
destructor debe comprobar las restricciones que pueden violarse al eliminar
un objeto.
Otros mtodos deben incluir cualquier restriccin posterior que sea
relevante.
Paso 4: Una clase ODL que corresponda a una subclase del esquema EER
hereda (a travs de EXTENDS) el tipo y los mtodos de su superclase en el
esquema ODL. Debe especificar sus atributos (no heredados) especficos,
referencias de relacin y operaciones, como explicamos en los pasos 1, 2 y
3.
Paso 5: Los tipos de entidad dbiles se pueden mapear de la misma forma
que los tipos de entidad normales. Es posible un mapeado alternativo para
los tipos de entidad dbiles que no participan en ninguna relacin, excepto
su relacin de identificacin; puede mapearlos como si fueran atributos
multivalor compuestos del tipo de entidad propietario, utilizando los
constructores set<struct<. .. >>o llst<struct< ... >>. Los atributos de la
entidad dbil se incluyen en la construccin struct< ... >, que corresponde a
un constructor de tupla. Los atributos se mapean como explicamos en los
pasos 1 y 2.
Paso 6: Las categoras (tipos de unin) de un esquema DER son difciles de
mapear a ODL. Es posible crear un mapeado parecido al mapeado DER-arelacional, declarando una clase que represente la categora y definiendo
relaciones 1: 1 entre la categora y cada una de sus superclases. Otra
opcin es utilizar un tipo unin, si lo hay.
Paso 7: Una relacin n-aria con un grado n > 2 se puede mapear en dos
clases separadas, con las referencias apropiadas a cada clase participante.
Esas referencias estn basadas en el mapeado de una relacin 1:N desde
cada clase que representa un tipo de entidad participante a la clase que

representa la relacin n-aria. Una relacin binaria M:N, especialmente si

contiene atributos de relacin, tambin puede utilizar esta opcin de
mapeado, si lo desea.

UNIDAD V: DATA WAREHOUSING

http://www.dataprix.com/data-warehousing-y-metodologia-hefesto
1. Introduccin:
1.1. La Empresa moderna, necesidades de informacin.
En la actualidad, en cualquier organizacin se hace necesario la toma
decisiones, en ocasiones muy estratgicas para lograr un desarrollo
satisfactorio. Generalmente estas decisiones, estn basadas en enormes
volmenes de informacin registrada en bases de datos operacionales o de
otros tipos de fuentes de datos. La recopilacin y anlisis de esta
informacin, dado su carcter heterogneo y su volumen se convierten
usualmente en un problema para las organizaciones y es aqu donde
interviene la Inteligencia de Negocio (Business Intelligence), mediante los
Sistemas de Apoyo a la Toma de Decisiones

1.2. Diferencias entre datos, informacin y conocimiento.

En una conversacin informal, los tres trminos suelen utilizarse
indistintamente y esto puede llevar a una interpretacin libre del concepto
de conocimiento. Quizs la forma ms sencilla de diferenciar los trminos
sea pensar que los datos estn localizados en el mundo y el conocimiento
est localizado en agentes de cualquier tipo (personas, empresas,
mquinas...), mientras que la informacin adopta un papel mediador entre
ambos.
Datos
Los datos son la mnima unidad semntica, y se corresponden con
elementos primarios de informacin que por s solos son irrelevantes como
apoyo a la toma de decisiones. Son tiles segn el contexto. Los datos
pueden ser una coleccin de hechos almacenados en algn lugar fsico
como un papel, un dispositivo electrnico (CD, DVD, disco duro...), o la
mente de una persona. En este sentido las tecnologas de la informacin
han aportado mucho a recopilacin de datos.
Los datos pueden provenir de fuentes externas o internas a la organizacin,
pudiendo ser de carcter objetivo o subjetivo, o de tipo cualitativo o
cuantitativo, etc.
Informacin
La informacin se puede definir como un conjunto de datos procesados y
que tienen un significado (relevancia, propsito y contexto), y que por lo
tanto son de utilidad para quin debe tomar decisiones, al disminuir su
incertidumbre. Los datos se pueden transforman en informacin
aadindoles valor:

Contextualizando: se sabe en qu contexto y para qu propsito se

generaron.
Categorizando: se conocen las unidades de medida que ayudan a
interpretarlos.

Calculando: los datos pueden haber sido procesados matemtica o

estadsticamente.
Corrigiendo: se han eliminado errores e inconsistencias de los datos.
Condensando: los datos se han podido resumir de forma ms concisa
(agregacin).

Por tanto, la informacin es la comunicacin de conocimientos o

inteligencia, y es capaz de cambiar la forma en que el receptor percibe algo,
impactando sobre sus juicios de valor y sus comportamientos.
Conocimiento
El conocimiento es una mezcla de experiencia, valores y informacin que
sirve como marco para la incorporacin de nuevas experiencias e
informacin, y es til para la accin. Se origina y aplica en la mente de los
conocedores. En las organizaciones con frecuencia no slo se encuentra
dentro de documentos o almacenes de datos, sino que tambin esta en
rutinas organizativas, procesos, prcticas, y normas.
El conocimiento se deriva de la informacin, as como la informacin se
deriva de los datos.

2. Data Warehouse:
Un almacn de datos (del ingls data Warehouse) es una coleccin de datos
orientada a un determinado mbito (empresa, organizacin, etc.), integrado,
no voltil y variable en el tiempo, que ayuda a la toma de decisiones en la
entidad en la que se utiliza.

Variante en el tiempo: los cambios producidos en los datos a lo

largo del tiempo quedan registrados para que los informes que se
puedan generar reflejen esas variaciones.
No voltil: la informacin no se modifica ni se elimina, una vez
almacenado un dato, ste se convierte en informacin de slo
lectura, y se mantiene para futuras consultas.
Integrado: la base de datos contiene los datos de todos los sistemas
operacionales de la organizacin, y dichos datos deben ser
consistentes.

Se trata, sobre todo, de un expediente completo de una organizacin, ms

all de la informacin transaccional y operacional, almacenado en una base
de datos diseada para favorecer el anlisis y la divulgacin eficiente de
datos. Los almacenes de datos contienen a menudo grandes cantidades de
informacin que se subdividen a veces en unidades lgicas ms pequeas
dependiendo del subsistema de la entidad del que procedan o para el que
sean necesario (datamarts).
Los data marts son subconjuntos de datos de un data warehouse para
reas especficas. Entre las caractersticas de un data mart destacan:

Usuarios limitados.
rea especfica.
Tiene un propsito especfico.
Tiene una funcin de apoyo.

Segn Kimball, un Data warehouse es la unin de todos los datamarts de las

diferentes reas de una empresa. La informacin se almacena siguiendo
un modelo dimensional.
Otra caracterstica del data warehouse es que contiene metadatos, es
decir, datos sobre los datos. Los metadatos permiten saber la procedencia
de la informacin, su periodicidad de refresco, su fiabilidad, forma de
clculo... etc. Estos sern los que permiten simplificar y automatizar la
obtencin de la informacin desde los sistemas operacionales a los sistemas
informacionales.
Los objetivos que deben cumplir los metadatos, segn el colectivo al que va
dirigido, son:
Dar soporte al usuario final, ayudndole a acceder al data
warehouse con su propio lenguaje de negocio, indicando qu
informacin hay y qu significado tiene. Ayudar a construir consultas,
informes y anlisis, mediante herramientas de Business Intelligence
como DSS, EIS o CMI.
Dar soporte a los responsables tcnicos del data warehouse
en aspectos de auditora, gestin de la informacin histrica,
administracin del data warehouse, elaboracin de programas de
extraccin de la informacin, especificacin de las interfaces para la
realimentacin a los sistemas operacionales de los resultados
obtenidos... etc.
Para comprender ntegramente el concepto de data warehouse, es
importante entender cual es el proceso de construccin del mismo,
denominado ETL (Extraccin, Transformacin y Carga), a partir de los
sistemas operacionales de una compaa:

Extraccin: obtencin de informacin de las distintas fuentes tanto

internas como externas.
Transformacin: filtrado, limpieza, depuracin, homogeneizacin y
agrupacin de la informacin.
Carga: organizacin y actualizacin de los datos y los metadatos en
la base de datos.

3 Modelado:
3.1. Procesamiento analtico (OLAP).
Los data warehouse soportan el procesamiento analtico en lnea, conocido
como OLAP (On-Line Analytical Processing). OLAP rene un gran nmero de
operaciones (solamente de consulta), en las se cruzan gran cantidad de
informacin con el objetivo final de crear informes y resmenes que sean
tiles en la toma de decisiones. Los algoritmos que utiliza estn
implementados para optimizar los tiempos de respuesta a las consultas,
logrando eficiencia y almacenando los datos en estructuras especializadas.
OLAP fue creado bajo las siguientes ideas:
Lograr rapidez de respuesta: entregar la informacin a los usuarios
finales en el menor tiempo posible, de 0 a 5 segundos.
Posibilitar el anlisis: ofrecer anlisis numrico y estadstico de los
datos, con valores agregados. Esto permite analizar tendencias,
causas, detectar variables de inters y descender hasta los niveles

ms bajos de la informacin, lo que se complementa con la ayuda de

los motores de reportes y grficos que se incluyen. Tambin incluye
vistas personalizadas.
Compartir datos: incluye los mecanismos de seguridad necesarios
para compartir la informacin entre los usuarios que se definan.
Basado en una estructura multidimensional: haciendo sencilla la
seleccin y navegacin de los datos.
Recuperacin de informacin: acceso a los datos y recuperacin de
informacin valiosa (solo lectura) para las diferentes aplicaciones
clientes.

3.2. Modos de almacenamiento: ROLAP, MOLAP, HOLAP.

MOLAP
Esta implementacin OLAP almacena los datos en una base de datos
multidimensional. Para optimizar los tiempos de respuesta, el resumen de la
informacin es usualmente calculado por adelantado. Estos valores
precalculados o agregaciones son la base de las ganancias de desempeo
de este sistema. Algunos sistemas utilizan tcnicas de compresin de datos
para disminuir el espacio de almacenamiento en disco debido a los valores
precalculados.
ROLAP
Implementacin OLAP que almacena los datos en un motor relacional.
Tpicamente, los datos son detallados, evitando las agregaciones y las
tablas se encuentran desnormalizadas Los esquemas ms comunes sobre
los que se trabaja son estrella copo de nieve, aunque es posible trabajar
sobre cualquier base de datos relacional. La arquitectura est compuesta
por un servidor de banco de datos relacional y el motor OLAP se encuentra
en un servidor dedicado. La principal ventaja de esta arquitectura es que
permite el anlisis de una enorme cantidad de datos.
HOLAP
Almacena algunos datos en un motor relacional y otros en una base de
datos multidimensional.
Comparacin
Cada sistema OLAP tiene ciertos beneficios (aunque existe desacuerdo
acerca de las caractersticas especficas de los beneficios entre los
proveedores).
Algunas implementaciones MOLAP son propensas a la "explosin" de la base
de datos; este fenmeno provoca la necesidad de grandes cantidades de
espacio de almacenamiento para el uso de una base de datos MOLAP
cuando se dan ciertas condiciones: elevado nmero de dimensiones,
resultados precalculados y escasos datos multidimensionales. Las tcnicas
habituales de atenuacin de la explosin de la base de datos no son todo lo
eficientes que sera deseable.
Por lo general MOLAP ofrece mejor rendimiento debido a la especializada
indexacin y a las optimizaciones de almacenamiento. MOLAP tambin
necesita menos espacio de almacenamiento en comparacin con los
especializados ROLAP porque su almacenamiento especializado
normalmente incluye tcnicas de compresin.
ROLAP es generalmente ms escalable. Sin embargo, el gran volumen de
preprocesamiento es difcil de implementar eficientemente por lo que con

frecuencia se omite; por tanto, el rendimiento de una consulta ROLAP puede

verse afectado.
Desde la aparicin de ROLAP van apareciendo nuevas versiones de bases de
datos preparadas para realizar clculos, las funciones especializadas que se
pueden utilizar tienen ms limitaciones.
HOLAP engloba un conjunto de tcnicas que tratan de combinar MOLAP y
ROLAP de la mejor forma posible. Generalmente puede pre-procesar
rpidamente, escala bien, y proporciona una buena funcin de apoyo.

3.3. Tabla de dimensiones y tabla de hecho: agregadas y

preagregadas.
En un almacn de datos o un sistema OLAP, la construccin de Cubos OLAP
requiere de una tabla de hechos y varias tablas de dimensiones, stas
acompaan a la tabla de hechos y determinan los parmetros (dimensiones)
de los que dependen los hechos registrados en la tabla de hechos.
Tabla de hechos
Es la tabla central de un esquema dimensional y contiene los valores de las
medidas de negocio o dicho de otra forma los indicadores de negocio. Cada
medida se toma mediante la interseccin de las dimensiones que la definen,
dichas dimensiones estarn reflejadas en sus correspondientes tablas de
dimensiones que rodearn la tabla de hechos y estarn relacionadas con
ella.
Las medidas ms tiles para incluir en una tabla de hechos son los aditivos,
es decir, aquellas medidas que pueden ser sumadas como por ejemplo la
cantidad de producto vendido, los costes de produccin o el dinero obtenido
por las ventas; son medidas numricas que pueden calcularse con la suma
de varias cantidades de la tabla. Una caracterstica importante que define a
una tabla de hechos es el nivel de granularidad de los datos que en ella se
almacenan.
La agregacin es un proceso de clculo por el cual se resumen los datos de
los registros de detalle. Esta operacin consiste normalmente en el clculo
de totales dando lugar a medidas de grano grueso. Cuando se resumen los
datos, el detalle ya no est directamente disponible para el analista, ya que
este se elimina de la tabla de hechos. Esta operacin se realiza tpicamente
con los datos ms antiguos de la empresa con la finalidad de seguir
disponiendo de dicha informacin para poder eliminar registros obsoletos de
la tabla de hechos para liberar espacio.
Tablas de dimensin
Las tablas de dimensiones son elementos que contienen atributos (o
campos) que se utilizan para restringir y agrupar los datos almacenados en
una tabla de hechos cuando se realizan consultas sobre dicho datos en un
entorno de almacn de datos o data mart.
Estos datos sobre dimensiones son parmetros de los que dependen otros
datos que sern objeto de estudio y anlisis y que estn contenidos en la
tabla de hechos. Las tablas de dimensiones ayudan a realizar ese
estudio/anlisis aportando informacin sobre los datos de la tabla de
hechos, por lo que puede decirse que en un cubo OLAP, la tabla de hechos
contiene los datos de inters y las tablas de dimensiones contienen
metadatos sobre dichos hechos.

3.4. Esquema estrella, copo de nieve y constelacin.

Estrella
En las bases de datos usadas para data warehousing, un esquema en
estrella es un modelo de datos que tiene una tabla de hechos (o table fact)
que contiene los datos para el anlisis, rodeada de las tablas de
dimensiones. Este aspecto, de tabla de hechos (o central) ms grande
rodeada de radios o tablas ms pequeas es lo que asemeja a una estrella,
dndole nombre a este tipo de construcciones.
Las tablas de dimensiones tendrn siempre una clave primaria simple,
mientras que en la tabla de hechos, la clave principal estar compuesta por
las claves principales de las tablas dimensionales. Este esquema es ideal
por su simplicidad y velocidad para ser usado en anlisis
multidimensionales

Copo de nieve
Un esquema en copo de nieve es una estructura algo ms compleja que
el esquema en estrella. Se da cuando alguna de las dimensiones se
implementa con ms de una tabla de datos. La finalidad es normalizar las
tablas y as reducir el espacio de almacenamiento al eliminar la redundancia
de datos; pero tiene la contrapartida de generar peores rendimientos al
tener que crear ms tablas de dimensiones y ms relaciones entre las tablas
(JOINS) lo que tiene un impacto directo sobre el rendimiento. A favor de los
esquemas en copo de nieve es que al estar normalizadas las tablas de
dimensiones, se evita la redundancia de datos y con ello se ahorra espacio.

Constelacin
El esquema de constelacin est compuesto por una serie de esquemas
en estrella, posee una tabla de hechos principal y una o ms tablas de
hechos auxiliares. Dichas tablas yacen en el centro del modelo y estn
relacionadas con sus respectivas tablas de dimensiones.
No es necesario que las diferentes tablas de hechos compartan las mismas
tablas de dimensiones, ya que, las tablas de hechos auxiliares pueden
vincularse con solo algunas de las tablas de dimensiones asignadas a la
tabla de hechos principal, y tambin pueden hacerlo con nuevas tablas de
dimensiones.
Su diseo y cualidades son muy similares a las del esquema en estrella,
pero posee una serie de diferencias con el mismo, que son precisamente las
que lo destacan y caracterizan. Entre ellas se pueden mencionar:
Permite tener ms de una tabla de hechos, por lo cual se podrn
analizar ms aspectos claves del negocio con un mnimo esfuerzo
adicional de diseo.
Contribuye a la reutilizacin de las tablas de dimensiones, ya que una
misma tabla de dimensin puede utilizarse para varias tablas de
hechos.
No es soportado por todas las herramientas de consulta y anlisis.

3.5. Comparativa: Sistemas operacionales vs. Data warehouse.

Parmetros
Propsito
Tipo de datos
Caracterstica
s de los datos

Base de Datos
Transaccional
Operaciones diarias.
Soporte a las
aplicaciones.
Datos de funcionamiento
de la organizacin.
Datos de
funcionamiento,
cambiantes, internos,
incompletos.

Almacn de Datos
Recuperacin de informacin,
informes, anlisis y minera de
datos.
Datos tiles para el anlisis, la
sumarizacin, etc.
Datos histricos, datos
internos y externos, datos
descriptivos.

Modelo de
datos

Datos normalizados.

Datos en estrella, en copo de

nieve, parcialmente
desnormalizados,
multidimensionales.

Nmero y tipo
de usuarios

Cientos/miles:
aplicaciones, operarios,
administrador de la base
de datos.

Decenas: directores,
ejecutivos, analistas.

SQL. Lectura y escritura.

SQL y herramientas propias

(slice &
dice, drill, roll, pivot). Lectura.

Acceso

UNIDAD VI: APLICACIONES DEL DATA WAREHOUSING

1. Aplicaciones:
1.1. Cubos: indicadores, atributos y jerarquas.
Un cubo multidimensional o hipercubo, representa o convierte los datos
planos que se encuentran en filas y columnas, en una matriz de N
dimensiones.
Los objetos ms importantes que se pueden incluir en un cubo
multidimensional, son los siguientes:

Indicadores: sumarizaciones que se efectan sobre algn hecho o

expresiones basadas en sumarizaciones, pertenecientes a una tabla
de hechos.
Atributos: campos o criterios de anlisis, pertenecientes a tablas de
dimensiones.
Jerarquas: representa una relacin lgica entre dos o ms atributos.

De esta manera en un cubo multidimensional, los atributos existen a lo

largo de varios ejes o dimensiones, y la interseccin de las mismas
representa el valor que tomar el indicador que se est evaluando.

1.2. Granularidad.
La granularidad representa el nivel de detalle al que se desea almacenar
la informacin sobre el negocio que se est analizando. Por ejemplo, los
datos referentes a ventas o compras realizadas por una empresa, pueden
registrarse da a da, en cambio, los datos pertinentes a pagos de sueldos o
cuotas de socios, podrn almacenarse a nivel de mes.
Mientras mayor sea el nivel de detalle de los datos, se tendrn mayores
posibilidades analticas, ya que los mismos podrn ser resumidos o
sumarizados. Es decir, los datos que posean granularidad fina (nivel de
detalle) podrn ser resumidos hasta obtener una granularidad media o
gruesa. No sucede lo mismo en sentido contrario, ya que por ejemplo, los
datos almacenados con granularidad media podrn resumirse, pero no
tendrn la facultad de ser analizados a nivel de detalle. O sea, si la
granularidad con que se guardan los registros es a nivel de da, estos datos
podrn sumarizarse por semana, mes, semestre y ao, en cambio, si estos

registros se almacenan a nivel de mes, podrn sumarizarse por semestre y

ao, pero no lo podrn hacer por da y semana

1.3. Operaciones
Las operaciones que se pueden realizar sobre modelos multidimensionales y
que son las que verdaderamente les permitirn a los usuarios explorar e
investigar los datos en busca de respuestas, son:

Drill-down: Permite apreciar los datos en un mayor detalle, bajando por

una jerarqua definida en un cubo. Esto brinda la posibilidad de introducir
un nuevo nivel o criterio de agregacin en el anlisis, disgregando los
grupos actuales. Drill-down es ir de lo general a lo especfico.

Drill-up: Permite apreciar los datos en menor nivel de detalle, subiendo

por una jerarqua definida en un cubo. Esto brinda la posibilidad de quitar
un nivel o criterio de agregacin en el anlisis, agregando los grupos
actuales. Drill-up es ir de lo especfico a lo general. (Ejemplo inverso Drilldown)
Drill-across: Funciona de forma similar a drill-down, con la diferencia de
que drill-across no se realiza sobre una jerarqua, sino que su forma de ir

de lo general a lo especfico es agregar un atributo a la consulta como

nuevo criterio de anlisis.

Roll-across: Funciona de forma similar a drill-up, con la diferencia de que

roll-across no se hace sobre una jerarqua, sino que su forma de ir de lo
especfico a lo general es quitar un atributo de la consulta, eliminando de
esta manera un criterio de anlisis. (Ejemplo inverso Drill-across)
Pivot: Permite seleccionar el orden de visualizacin de los atributos e
indicadores, con el objetivo de analizar la informacin desde diferentes
perspectivas.
Page: Page es muy til cuando las consultas devuelven muchos registros
y es necesario desplazarse por los datos para poder verlos en su totalidad.
Drill-through: Permite apreciar los datos en su mximo nivel de detalle.
Esto brinda la posibilidad de analizar cules son los datos relacionados al
valor de un Indicador, que se ha sumarizado dentro del cubo
multidimensional.

2. Ciclo de Desarrollo: