RESUMEN BASE DE DATOS AVANZADA

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 A LAS BASE DE DATOS ORIENTADAS A OBJETOSLos 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 objetosEl 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 , 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 complejoO1 = (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, )

O9 = (i9, tuple, )

O10 = (i10, set, {i12, i13, i14})O11 = (i11, set {i15, i16, i17})

O12 = (i12, tuple, 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, cuyos objetos seran conjuntos de objetos ESTUDIANTE. El programador puede utilizar entonces las operaciones para set a fin de manipular un objeto de tipo set. 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: OQL1. OQLEl 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 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:

D IN DEPARTAMENTOS

DEPARTAMENTOS D

DEPARTAMENTOS AS DLos 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.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. Problemas de ambigedad:

C3': CC _DEPARTAMENTO.Tiene_ docentes. Rango;No est claro si el objeto devuelto sera de tipo set o de tipo bag. 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 (en el resultado aparecen valores de rango duplicados), mientras que C3B devuelve set (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 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 OBJETOS1. 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 , 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 seto llst>. 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-a-relacional, 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-hefesto1. 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.MOLAPEsta 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.ROLAPImplementacin 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 hechosEs 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.

ConstelacinEl 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 Base de Datos Transaccional Almacn de Datos

Propsito Operaciones diarias. Soporte a las aplicaciones. Recuperacin de informacin, informes, anlisis y minera de datos.

Tipo de datos Datos de funcionamiento de la organizacin. Datos tiles para el anlisis, la sumarizacin, etc.

Caractersticas de los datos Datos de funcionamiento, cambiantes, internos, incompletos. 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.

Acceso SQL. Lectura y escritura. SQL y herramientas propias (slice &

dice, drill, roll, pivot). Lectura.

UNIDAD VI: APLICACIONES DEL DATA WAREHOUSING1. 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. OperacionesLas 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 Drill-down) 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: