You are on page 1of 28

Antologa de Tpicos Avanzados de Bases de Datos Unidad I Modelos emergentes de bases de datos. 1.1 Bases de datos orientadas a objetos.

1.1.1 Definicin y conceptos de las BDOO. Introduccin Los modelos de bases de datos tradicionales (relacional, red y jerrquico) han sido capaces de satisfacer con xito las necesidades, en cuanto a bases de datos, de las aplicaciones de gestin tradicionales. Sin embargo, presentan algunas deficiencias cuando se trata de aplicaciones ms complejas o sofisticadas como, por ejemplo, el diseo y fabricacin en ingeniera (CAD/CAM, CIM), los experimentos cientficos, los sistemas de informacin geogrfica o los sistemas multimedia. Los requerimientos y las caractersticas de estas nuevas aplicaciones difieren en gran medida de las tpicas aplicaciones de gestin: la estructura de los objetos es ms compleja, las transacciones son de larga duracin, se necesitan nuevos tipos de datos para almacenar imgenes y textos, y hace falta definir operaciones no estndar, especficas para aplicacin. cada Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de estas nuevas aplicaciones. La orientacin a objetos ofrece flexibilidad para manejar algunos deestos requisitos y no est limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales. Una caracterstica clave de las bases de datos orientadas a objetos es la potencia que proporcionan al diseador al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre objetos. dichos Otro motivo para la creacin de las bases de datos orientadas a objetos es el creciente uso de lenguajes orientados a objetos para desarrollar aplicaciones. Las bases de datos se los han convertido en piezas fundamentales de muchos sistemas de informacin y las bases de datos tradicionales son difciles de utilizar cuando las aplicaciones que acceden a ellas estn escritas en un lenguaje de programacin orientado a objetos como C++, Smalltalk o Java. Las bases de datos orientadas a objetos se han diseado para que se puedan integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos, habiendo adoptado muchos de conceptos de estos lenguajes. los Los Sfabricantes Sde Slos SGBD Srelacionales Stambin Sse Shan Sdado Scuenta Sde Slas Snuevas necesidades en el modelado de datos, por lo que las nuevas versiones de sus sistemas incorporan muchos de los rasgos propuestos para las bases de datos orientadas a objetos, como ha ocurrido con Informix y Oracle. Esto ha dado lugar al modelo relacional extendido y a los sistemas que lo implementan se les denomina sistemas objetorelacionales. La nueva de SQL, SQL:1999, incluye algunas de las caractersticas de la orientacin a ve rsin objetos. Durante los ltimos aos se han creado muchos prototipos experimentales de sistemas de bases de datos orientadas a objetos y tambin muchos sistemas comerciales. Conforme stos fueron apareciendo, surgi la necesidad de establecer un modelo estndar y un lenguaje.

Para ello, los fabricantes de los SGBD orientadas a objetos formaron un grupo denominado ODMG (Object Database Management Group), que propuso el estndar ODMG93 y que ha ido evolucionando hasta el ODMG 3.0, su ultima versin. El uso de estndares proporciona portabilidad, permitiendo que una aplicacin se pueda ejecutar sobre sistemas distintos con mnimas modificaciones. Los estndares tambin proporcionan interoperabilidad, permitiendo que una aplicacin pueda acceder a varios sistemas diferentes. Y una tercera ventaja de los estndares es que permiten que los usuarios puedan comparar entre distintos sistemas comerciales, dependiendo de qu partes del estndar proporcionan. Arquitectura de Una BDOO Los primeros se disearon como una extensin de los lenguajes de programacin como malltalk o C++. El LMD (lenguaje para el manipulacin de datos; tambin conocido como DML) y el LDD (lenguaje para la definicin de los datos; tambin conocido como DDL) construan un lenguaje OO comn. El diseo de las BDOO actuales debe aprovechar al mximo l CASE e incorporar mtodos creados con cualquier tcnica poderosa, incluyendo enunciados declarativos, generadores de cdigos e inferencias con base en reglas. Algunas caractersticas son independientes de la arquitectura fundamental de una BDOO pero son comunes a la mayora de ellas: Versiones.- La mayora de los sistemas de bases de datos slo permiten que exista una representacin de un ente de la base de datos dentro de esta. Las versiones permiten que las representaciones alternas existan en forma simultnea. Transacciones Scompartidas.- SLas Stransacciones Scompartidas Ssoportan Sgrupos Sde usuarios en estaciones de trabajo, los cuales desean coordinar sus esfuerzos en tiempolos usuarios pueden compartir los resultados intermedios de una base de datos. real, La transaccin compartida permite que varias personas intervengan en una sola transaccin. Conceptos de orientacin a objetos El desarrollo del paradigma orientado a objetos aporta un gran cambio en el modo en que mos los datos y los procedimientos que actan sobre ellos. Tradicionalmente, los datos y ve los procedimientos se han almacenado separadamente: los datos y sus relaciones en la base de datos y los procedimientos en los programas de aplicacin. La orientacin a objetos, sin embargo, combina los procedimientos de una entidad con sus datos. Esta combinacin se considera como un paso adelante en la gestin de datos. Las entidades son unidades autocontenidas que se pueden reutilizar con relativa facilidad. En lugar de ligar el comportamiento de una entidad a un programa de aplicacin, el comportamiento es parte de la entidad en si, por lo en cualquier lugar en el que se utilice la entidad, se comporta de un modo predecible y conocido. El modelo orientado a objetos tambin soporta relaciones de muchos a muchos, siendo el primer modelo que lo permite. Aun as se debe ser muy cuidadoso cuando se disean estas relaciones para evitar prdidas de informacin. Por otra parte, las bases de datos orientadas a objetos son navegacionales: el acceso a los datos es a travs de las relaciones, que se almacenan con los mismos datos. Esto se considera atrs. Las bases de datos orientadas a objetos no son apropiadas para un paso realizar ad hoc, al contrario que las bases de datos relacionales, aunque normalmente consultas las

soportan. La naturaleza navegacional de las bases de datos orientadas a objetos implica que consultas deben seguir relaciones predefinidas y que no pueden insertarse nuevas las relaciones al vuelo. No parece que las bases de datos orientadas a objetos vayan a reemplazar a las bases de datos relacionales en todas las aplicaciones del mismo modo en que stas reemplazaron a sus predecesoras. Los objetos han entrado en el mundo de las bases de datos de formas: GBD orientados a objetos puros: son SGBD basados completamente en el modelo orientado a objetos. GBD hbridos u objetorelacionales: son SGBD relacionales que permiten almacenar objetos en sus relaciones (tablas). Los conceptos del paradigma orientado a objetos en programacin, ya que el modelo de datos orientado a objetos es una extensin del mismo. Objeto. Es un elemento autocontenido utilizado por el programa. Los valores que almacena un objeto se denominan atributos, variables o propiedades. Los objetos pueden realizar acciones, que se denominan mtodos, servicios, funciones, procedimientos u operaciones. Los objetos tienen un gran sentido de la privacidad, por lo que slo dan informacin sobre s mismos a travs de los mtodos que poseen para compartir su informacin. Tambin ocultan la implementacin de sus procedimientos, aunque es muy sencillo pedirles que los ejecuten. Los usuarios y los programas de aplicacin no pueden ver qu hay dentro de los mtodos, slo pueden ver los resultados de ejecutarlos. A esto es a lo que se denomina ocultacin de informacin o encapsulamiento de datos. Cada objeto presenta una interface pblica al resto de objetos que pueden utilizarlo. Una de las mayores ventajas del encapsulamiento es que mientras que la interface pblica sea la misma, se puede cambiar la implementacin de los mtodos sin que sea necesario informar al resto de objetos que los utilizan. Para pedir datos a un objeto o que realice una accin se le debe enviar un mensaje. Un programa orientado a objetos es ste un conjunto de objetos que tienen atributos y mtodos. Los objetos interactan envindose mensajes. La clave, por supuesto, es averiguar qu objetos necesita el programa y cules ser sus atributos y sus mtodos. deben Clase. Es un patrn o plantilla en la que se basan objetos que son similares. Cuando un programa crea un objeto de una clase, proporciona datos para sus variables y el objeto puede entonces utilizar los mtodos que se han escrito para la clase. Todos los objetos creados a partir de la misma clase comparten los mismos procedimientos para sus mtodos, tambin tienen los mismos tipos para sus datos, pero los valores pueden diferir. na U clase tambin es un tipo de datos. De hecho una clase es una implementacin de lo que se conoce como un tipo abstracto de datos. El que una clase sea tambin un tipo de datos significa que una clase se puede utilizar como tipo de datos de un atributo.

Tipos de clases. En los programas orientados a objetos hay tres tipos de clases: clases de control, clases y clases interface. entidad Las clases de control gestionan el flujo de operacin de un programa (por ejemplo, el programa que se ejecuta es un objeto de esta clase). Las clases entidad son las que se utilizan para crear objetos que manejan datos (por ejemplo, clases para personas, objetos tangibles o eventos). Las clases interface son las que manejan la entrada y la salida de informacin (por ejemplo, las ventanas grficas y los mens utilizados por un programa). En los programas orientados a objetos, las clases entidad no hacen su propia entrada/salida. El teclado es manejado por objetos interface que recogen los datos y los envan a los objetos entidad para que los almacenen y los procesen. La salida impresa y por pantalla la formatea un objeto interface para obtener los datos a visualizar de los objetos entidad. Cuando los objetos entidad forman parte de la base de datos, es el SGBD el que se encarga de la entrada/salida a ficheros. El resto de la entrada/salida la manejan los programas de aplicacin o las utilidades del SGBD. Muchos programas orientados a objetos tienen un cuarto tipo de clase: la clase contenedor. Estas clases contienen, o manejan, mltiples objetos creados a partir del mismo tipo de clase. Tambin se conocen como agregaciones. Las clases contenedor mantienen los objetos en algn orden, los listan e incluso pueden permitir bsquedas en ellos. Muchos SGBD orientados a objetos llaman a sus clases contenedor extents (extensiones) y su objetivo es permitir el acceso a todos los objetos creados a partir de la misma clase. Tipos de mtodos. Hay varios tipos de mtodos que son comunes a la mayora de las clases: Constructores. Un constructor es un mtodo que tiene el mismo nombre que la clase. Se ejecuta cuando se crea un objeto de una clase. Por lo tanto, un constructor contiene instrucciones para inicializar las variables de un objeto. Destructores. Un destructor es un mtodo que se utiliza para destruir un objeto. No todos los lenguajes orientados a objetos poseen destructores. Accesores. Un accesor es un mtodo que devuelve el valor de un atributo privado de otro objeto. As es cmo los objetos externos pueden acceder a los datos encapsulados. Mutadores. Un mutador es un mtodo que almacena un nuevo valor en un atributo. De este modo es cmo objetos externos pueden modificar los datos encapsulados. Adems, cada clase tendr otros mtodos dependiendo del comportamiento especfico que deba poseer. obrecarga de mtodos. Una de las caractersticas de las clases es que pueden tener mtodos sobrecargados, que son mtodos que tienen el mismo nombre pero que necesitan distintos datos para operar. Ya que los datos son distintos, las interfaces pblicas de los mtodos sern diferentes. Por ejemplo, consideremos una clase contenedor, TodosLosEmpleados, que agrega los objetos creados de la clase Empleado. Para que la clase contenedor sea til, todos debe proporcionar alguna forma de buscar objetos de empleados especficos. Se puede querer buscar por nmero de empleado, por el nombre y los apellidos o por el nmero de telfono. La clase contenedor TodosLosEmpleados tendr tres mtodos llamados encuentra. Uno de los mtodos requiere un entero como parmetro (el nmero de empleado), el segundo requiere

dos cadenas (el nombre y los apellidos) y el tercero requiere una sola cadena (el nmero de telfono). Aunque los tres mtodos tienen el mismo nombre, poseen distintas interfaces pblicas. La ventaja de la sobrecarga de los mtodos es que presentan una interface consistente al programador: siempre que quiera localizar a un empleado, debe utilizar el mtodo encuentra. Nombres de clases, atributos y mtodos. En el mundo de la orientacin a objetos hay cierta uniformidad en el modo de dar nombres a clases, atributos y mtodos. Los nombres de las clases empiezan por una letra mayscula seguida de minsculas. Si el nombre tiene ms de una palabra, se puede usar el caracter subrayado para separar palabras o bien empezar cada una con una letra mayscula (Materia_prima o MateriaPrima). Los nombres de los atributos y de los mtodos empiezan por minscula y si tienen ms de una palabra, utilizan el subrayado o la mayscula (num_empleado o numEmpleado). Los mtodos accesores empiezan por la palabra get seguida del nombre del atributo al que acceden (getNumEmpleado). Los mtodos mutadores empiezan por la palabra set seguida del nombre del atributo cuyo valor modifican (setNumEmpleado).

Herencia de atributos. En ocasiones se necesita trabajar con clases que son similares pero no idnticas. Para ello es muy til una de las caractersticas del paradigma orientado a objetos: la herencia. Una clase tener varias subclases que representan ocurrencias ms especficas de la puede superclase. podemos tener la clase (superclase) Animal con sus atributos (nombre comn, Por ejemplo, nombre cientfico, fecha de nacimiento y gnero) y las subclases Mamfero, Reptil y Pez, cada con unos atributos especficos (Mamfero: peso, altura del hombro, raza y color; una Reptil: actual y longitud mxima; Pez: color). Por el hecho de ser subclases de Animal, longitud heredan sus atributos. La relacin que mantienen las subclases con la superclase es del tipo es un: un mamfero es un animal, un reptil es un animal y un pez es un animal. No todas las clases de una jerarqua se utilizan para crear objetos. or ejemplo, nunca se crean objetos de la clase Animal, sino que se crean objetos de las P clases Mamfero, Reptil o Pez. La clase Animal slo se utiliza para recoger los atributos y mtodos que son comunes a las tres subclases. Se dice que estas clases son abstractas o virtuales. Las clases se utilizan para crear objetos se denominan clases concretas. que Herencia mltiple. Cuando una clase hereda de ms de una superclase se tiene herencia mltiple. Interfaces. Algunos lenguajes orientados a objetos no soportan la herencia mltiple. En lugar de eso permiten que una clase se derive de una sola clase pero permiten que la clase implemente mltiples interfaces. Una interface es una especificacin para una clase sin instrucciones en los mtodos. Cada clase que implemente la interface proporcionar las instrucciones para cada

mtodo de la misma. Una interface puede contener atributos y mtodos, o bien slo atributos, o bien slo mtodos. Polimorfismo. En general, las subclases heredan los mtodos de sus superclases y los utilizan como si fueran suyos. Sin embargo, en algunas ocasiones no es posible escribir un mtodo genrico que pueda ser usado por todas las subclases. La clase ObjetoGeomtrico posee un mtodo rea que deber tener distinta implementacin para sus subclases Crculo, Rectngulo y Tringulo. La superclase contendr un prototipo para el mtodo que calcula el rea, indicando slo su interface pblica. Cada subclase redefine el mtodo, aadiendo las instrucciones necesarias para calcular su rea. Ntese que polimorfismo no es lo mismo que sobrecarga: la sobrecargaa mtodos de la misma clase que tienen el mismo nombre y distintas signaturas, se aplica mientras que el polimorfismo se aplica a varias subclases de la misma superclase que tienen mtodos con la misma signatura y con distintas implementaciones. Ventajas de la orientacin a objetos en programacin: Un programa orientado a objetos consta de mdulos independientes, por lo que se pueden reutilizar en distintos programas, ahorrando tiempo de desarrollo. El interior de una clase se puede modificar como sea necesario siempre que su interface pblica no cambie, de modo que estas modificaciones no afectarn a los programas que utilizan la clase. Los programas orientados a objetos separan la interface de usuario de la gestin de los datos, haciendo posible la modificacin de una independientemente de la otra. La herencia aade una estructura lgica al programa relacionando clases desde lo general a lo ms especfico, haciendo que el programa sea ms fcil de entender y, por tanto, ms fcil de mantener. lo 1.1.2 El modelo de datos orientado a objetos. El modelo de datos orientado a objetos es una extensin del paradigma de programacin orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a objetos son anlogos a las entidades que se utilizan en las bases de datos orientadas a objetos puras, pero con una gran diferencia: los objetos del programa desaparecen cuando el programa termina su ejecucin, mientras que los objetos de la base de datos permanecen. A esto se le denomina persistencia. 1.1.2.1. Relaciones Las bases de datos relacionales representan las relaciones mediante las claves ajenas. No tienen estructuras de datos que formen parte de la base de datos y que representen estos enlaces entre tablas. Las relaciones se utilizan para hacer concatenaciones (join) de tablas. Por el contrario, las bases de datos orientadas a objetos implementan sus relaciones incluyendo en cada objeto los identificadores de los objetos con los que se relaciona. nU Sidentificador Sde Sobjeto Ses Sun Satributo Sinterno Sque Sposee Scada Sobjeto. SNi Slos programadores, ni los usuarios que realizan consultas de forma interactiva, ven o manipulan

estos identificadores directamente. Los identificadores de los objetos los asigna el SGBD y es l el nico que los utiliza. El identificador puede ser un valor arbitrario o puede incluir la informacin necesaria para localizar el objeto en el fichero donde se almacena la base de datos. Por ejemplo, el identificador puede contener el nmero de la pgina del fichero donde se encuentra almacenado el objeto, junto con el desplazamiento desde el principio de la pgina. Hay dos aspectos importantes a destacar sobre este mtodo de representar las relaciones entre datos: Para que el mecanismo funcione, el identificador del objeto no debe cambiar mientras ste forme parte de la base de datos. Las nicas relaciones que se pueden utilizar para consultar la base de datos son aquellas que se han predefinido almacenando en atributos los identificadores de los objetos relacionados. Por lo tanto, una base de datos orientada a objetos pura es navegacional, como los modelos prerrelacionales (el modelo jerrquico y el modelo de red). De este modo se limita la flexibilidad del programador/usuario a aquellas relaciones predefinidas, pero los accesos que siguen estas relaciones presentan mejores prestaciones que en las bases de datos relacionales ms rpido seguir los identificadores de los objetos que hacer operaciones porque es de concatenacin (join). El modelo orientado a objetos permite los atributos multivaluados, agregaciones a las que se denomina conjuntos (sets) o bolsas (bags). Para crear una relacin de uno a muchos, se define un atributo en la parte del uno que ser de la clase del objeto con elSque se relaciona. Este atributo contendr el identificador de objeto del padre. La clase del objeto padre contendr un atributo que almacenar un conjunto de valores: los identificadores de los objetos hijo con los se relaciona. Cuando el SGBD ve que un atributo tiene como tipo de datos una clase, ya que sabe que el atributo contendr un identificador de objeto. Las relaciones de muchos a muchos se pueden representar directamente en las bases de datos orientadas a objetos, sin necesidad de crear entidades intermedias. Para representar la relacin, cada clase que participa en ella define un atributo que contendr un conjunto de val res de la otra clase con la que se relacionar. Aunque el hecho de poder o representar relaciones de muchos a muchos parece aportar muchas ventajas, hay que tener mucho cuidado cuando se utilizan. En primer lugar, si la relacin tiene datos, ser necesario crear una entidad intermedia que contenga estos datos. Por ejemplo, en la relacin de los artculos con proveedores, en donde cada proveedor puede tener un precio distinto para un mismo los artculo. En este caso, la relacin de muchos a muchos se sustituye por dos relaciones de uno a muchos, como se hara en una base de datos relacional. En segundo lugar, se puede disear una base de datos que contiene relaciones de muchos a muchos en donde o bien se pierde informacin, o bien se hace imposible determinar las relaciones con precisin. Tambin en estos casos la solucin es incluir una entidad intermedia que represente la relacin. Ya que el paradigma orientado a objetos soporta la herencia, una base de datos orientada a objetos tambin puede utilizar la relacin es un entre objetos. Por ejemplo, en una base de datos para un departamento de recursos humanos habr una clase genrica Empleado con

diversos atributos: nombre, direccin, nmero de la seguridad social, fecha de contrato y departamento en el que trabaja. Sin embargo, para registrar el modo de pago de cada empleado hay un dilema. No a todos los empleados se les paga del mismo modo: a algunos se les paga por horas, mientras que otros tienen un salario mensual. La clase de los empleados que trabajan por horas necesita unos atributos distintos que la clase de los otros empleados. En una base de datos orientada a objetos se deben crear las dos subclases de empleados. Aunque el SGBD nunca crear objetos de la clase Empleado, su presencia en el diseo clarifica el Sdiseo Slgico Sde Sla Sbase Sde Sdatos Sy Sayuda Sa Slos Sprogramadores Sde Saplicaciones permitindoles escribir slo una vez los mtodos que tienen en comn las dos subclases (sern los mtodos que se sitan en la clase Empleado). En teora, una base de datos orientada a objetos debe soportar dos tipos de herencia: la relacin es un y la relacin extiende. La relacin es un, que tambin se conoce como generalizacinespecializacin, crea una jerarqua donde las subclases son tipos especficos de superclases. Con la relacin extiende, sin embargo, una clase expande su superclase las en lugar de estrecharla en un tipo ms especfico. Por ejemplo, en la jerarqua de la clase Empleado, al igual que son necesarias clases para los empleados que realizan cada trabajo especfico, hace falta guardar informacin adicional sobre los directores, que son empleados pero que tambin tienen unas caractersticas especficas. La base de datos incluir una clase Director con un atributo para los empleados a los que dirige. En este sentido un director no es un empleado ms especfico sino un empleado con informacin adicional. U de las cosas que es difcil de manejar en las bases de datos relacionales es la idea de na las partes de un todo, como en una base de datos de fabricacin, en la que hace falta saber que piezas y que componentes se utilizan para fabricar un determinado producto. Sin embargo, una base de datos orientada a objetos puede aprovechar la relacin denominada todo parte que los objetos de una clase se relacionan con objetos de otras clases que forman en la parte En el caso de la base de datos de fabricacin, la clase Producto se relacionara con de l. las clases Pieza y Componente utilizando una relacin todoparte. Este tipo de relacin es una relacin de muchos a muchos con un significado especial. Un producto puede estar hecho de muchas piezas y muchos componentes. Adems, una misma pieza o un mismo componente se puede utilizar para fabricar distintos productos. El identificar esta relacin como todo parte permite que el diseo sea ms fcil de entender. 1.1.2.2. Integridad de las relaciones Para que las relaciones funcionen en una base de datos orientada a objetos pura, los identificadores de los objetos deben corresponderse en ambos extremos de la relacin. Por ejemplo, si los aparejadores de una empresa de control de calidad se deben relacionar con las obras de construccin que supervisan, debe haber algn modo de garantizar que, cuando un identificador de un objeto Obra se incluye en un objeto Aparejador, el identificador de este mismo objeto Aparejador se debe incluir en el objeto Obra anterior. Este tipo de integridad de relaciones, que es de algn modo anlogo a la integridad referencial en las bases de datos relacionales, se gestiona especificando relaciones inversas. La clase Aparejador tiene un atributo de tipo conjunto llamado supervisa. Del mismo modo, laclase Obra tiene un atributo llamado es supervisada. Para garantizar la integridad de esta relacin, un SGBD orientado a objetos puro deber permitir que el diseador de la base de datos pueda especificar donde debe aparecer el identificador del objeto inverso, como por ejemplo:

relationship set<Obra> supervisa inverse Obra::es supervisada En la clase Aparejador y: relationship Aparejador es supervisada inverse Aparejador::supervisa En la clase Obra. iempre que un usuario o un programa de aplicacin inserta o elimina un identificador de objeto de la relacin supervisa en un objeto Aparejador, el SGBD actualizara automticamente la relacin es supervisada en el objeto Obra relacionado. Cuando se hace una modificacin en objeto Obra, el SGBD lo propagara automticamente al objeto el Aparejador. Del mismo modo que en las bases de datos relacionales es el diseador de la base de datos el que debe especificar las reglas de integridad referencial, en las bases de datos orientadas a objetos es tambin el diseador el que debe especificar las relaciones inversas cuando crea elesquema de la base de datos. 1.1.2.3. UML Existen distintas notaciones o modelos para disear esquemas conceptuales de bases de datos orientadas a objetos: la notacin de Coad/Yourdon, la Shlaer/Mellor, la OMT (Rombaugh) o la de Booch. Cada modelo presenta distintas deficiencias, por lo que algunos de sus autores han desarrollado conjuntamente un lenguaje, denominado UML (Unified Modeling Language), que las evita. La notacin UML (no hay que confundir con las metodologas que utilizan dicha notacin), se ha convertido desde finales de los 90 en un estndar para modelar con tecnologa orientada a objetos todos aquellos elementos que configuran la arquitectura de un sistema de informacin y, por extensin, de los procesos de negocio de una organizacin. De la misma manera que los planos de un arquitecto disponen el esquema director a partir del cual levantamos un edificio, los diagramas UML suministran un modelo de referencia para formalizar los procesos, reglas de negocio, objetos y componentes de una organizacin. La interaccin de todos estos elementos es una representacin de nuestra realidad. El estudio y uso de este lenguaje se realiza en la asignatura obligatoria Ingeniera del Software, del segundo ciclo de Ingeniera Informtica. 1.1.3 El estndar ODMG. El modelo de objetos ODMG permite que tanto los diseos, como las implementaciones, sean portables Sentre Slos Ssistemas que Slo Ssoportan. SDispone Sde Slas Ssiguientes primitivas Sde modelado: Los componentes bsicos de una base de datos orientada a objetos son los objetos y los literales. Un objeto es una instancia autocontenida de una entidad de inters del mundo real. Los objetos tienen algn tipo de identificador nico. Un literal es un valor especfico, como Amparo So S36. SLos Sliterales Sno Stienen Sidentificadores. SUn Sliteral Sno Stiene Sque Sser necesariamente un solo valor, puede ser una estructura o un conjunto de valores relacionados que se guardan bajo un solo nombre.

Los objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio especfico por todos los objetos y literales de ese tipo. Los tipos tambin pueden compartido tener comportamientos. Cuando un tipo tiene comportamientos, todos los objetos de ese tipo comparten los mismos comportamientos. En el sentido prctico, un tipo puede ser una clase de la que se crea un objeto, una interface o un tipo de datos para un literal (por ejemplo, integer). Un objeto se puede pensar como una instancia de un tipo. Lo que un objeto sabe hacer son sus operaciones. Cada operacin puede requerir entrada (parmetros de entrada) y puede devolver algn valor de un tipo datos de conocido. Los objetos tienen propiedades, que incluyen sus atributos y las relaciones que tienen con otros objetos. El estado actual de un objeto viene dado por los valores actuales de propiedades. sus U base de datos es un conjunto de objetos almacenados que se gestionan de modo na que puedan ser accedidos por mltiples usuarios y aplicaciones. La definicin de una base de datos est contenida en un esquema que se ha creado mediante el lenguaje de definicin de objetos ODL (Object Definition Language) que es el lenguaje de manejo de datos que se ha definido como parte del estndar propuesto para las bases de datos orientadas a objetos. 1.1.3.1 Objetos Los tipos de objetos se descomponen en atmicos, colecciones y tipos estructurados. Los tipos coleccin, que se derivan de la interface Collection, son la propuesta del estndarclases contenedor. Los objetos coleccin identificados por el estndar son para las los siguientes: et<tipo>: es un grupo desordenado de objetos del mismo tipo. No se permiten duplicados. Bag<tipo>: es un grupo desordenado de objetos del mismo tipo. Se permiten duplicados. List<tipo>: es un grupo ordenado de objetos del mismo tipo. Se permiten duplicados. Array<tipo>: es un grupo ordenado de objetos del mismo tipo que se pueden acceder por su posicin. Su tamao es dinmico y los elementos se pueden insertar y borrar de cualquier posicin. Dictionary<clave,valor>: es como un ndice. Est formado por claves ordenadas, cada una de ellas emparejada con un solo valor. Los tipos estructurados son los siguientes: Date: es una fecha del calendario (da, mes y ao). Time: es una hora (hora, minutos y segundos). Timestamp: es una hora de una fecha (con precisin de microsegundos).

Interval: es un perodo de tiempo. Estos tipos tienen la misma definicin que los tipos con el mismo nombre del estndar de SLQ. Los objetos se crean utilizando el mtodo new(). Adems, todos heredan la interface que se muestra a continuacin: interface Object { enum Lock Typefread,write,upgradeg; void lock(in Lock Type mode) raises(LockNotGranted); Type boolean try lock(in Lock mode); same as(in Object anObject); boolean Object copy(); void delete(); }; Cada objeto tiene un identificador de objeto nico generado por el SGBD, que no cambia y que no se reutiliza cuando el objeto se borra. Cada SGBD genera los identificadores siguiendo sus propios criterios. Los objetos pueden ser transitorios o persistentes. Los objetos transitorios existen mientras viv el programa de aplicacin que los ha creado. Estos objetos se usan tanto e como almacenamiento temporal como para dar apoyo al programa de aplicacin que se est ejecutando. Los objetos persistentes son aquellos que se almacenan en la base de datos. 1.1.3.2 Literales Los tipos literales se descomponen en atmicos, colecciones, estructurados o nulos. Los literales no tienen identificadores y no pueden aparecer solos como objetos, sino que estn embebidos en objetos y no pueden referenciarse de modo individual. Los literales atmicos son los siguientes: boolean: un valor que es verdadero o falso. short: un entero con signo, normalmente de 8 o 16 bits. long: un entero con signo, normalmente de 32 o 64 bits. unsigned short: un entero sin signo, normalmente de 8 o 16 bits. unsigned long: un entero sin signo, normalmente de 32 o 64 bits. float: un valor real en coma flotante de simple precisin. valor real en coma flotante de doble precisin. double: un octet: un almacn de 8 bits. char: un caracter ASCII o UNICODE. string: una cadena de caracteres. enum: un tipo enumerado donde los valores se especifican explcitamente cuando se declara el tipo. Los literales estructurados contienen un nmero fijo de elementos heterogneos. Cada elemento es un par <nombre, valor> donde valor puede ser cualquier tipo literal. Los tipos estructurados son: date, time, timestamp, interval y struct. Y los tipos coleccin son: set<tipo>, bag<tipo>, list<tipo>, array<tipo> y dictionary<clave,valor>.

1.1.3.3 Tipos U de las caractersticas ms importantes del paradigma orientado a objetos es la na distincin entre la interface pblica de una clase y sus elementos privados (encapsulacin). El estndar propuesto hace esta distincin hablando de la especificacin externa de un tipo yde sus implementaciones. Una interface es una especificacin del comportamiento abstracto de un tipo de objeto y contiene las signaturas de las operaciones. Aunque una interface puede tener propiedades (atributos y relaciones) como parte de su especificacin, stas no pueden ser heredadas desde la interface. Adems, una interface no es instanciable por lo que no se pueden crear objetos a partir de ella (es el equivalente de una clase abstracta en la mayora de los lenguajes de programacin). Una clase es una especificacin del comportamiento abstracto y del estado abstracto de un tipo de objeto. Las clases son instanciables, por lo que a partir de ellas se pueden crear instancias de objetos individuales (es el equivalente a una clase concreta en los lenguajes de programacin). El estndar propuesto soporta la herencia simple y la herencia mltiple mediante las interfaces. Ya que las interfaces no son instanciables, se suelen utilizar para especificar operaciones abstractas que pueden ser heredadas por clases o por otras interfaces. A esto se le denomina herencia de comportamiento y se especifica mediante el smbolo :. La herencia de comportamiento requiere que el supertipo sea una interface, mientras que el subtipo puede ser una clase o una interface. La herencia es una relacin es un: interface ArticuloVenta ...; interface Mueble : ArticuloVenta ...; class Silla : Mueble ...; class Mesa : Mueble ...; class Sof : Mueble ...; La interface o clase ms baja de la jerarqua es el tipo ms especfico. Ya que hereda los comportamientos de todos los tipos que tiene por encima en la jerarqua, es la interface o clase ms completa. En el ejemplo anterior, los tipos mas especficos son Silla, Mesa y Sof. no de los beneficios prcticos de la herencia es que se puede hacer referencia a los U subtipos supertipo. Por ejemplo, un programa de aplicacin puede hacer referencia a como su sillas, y sofs como muebles o incluso como artculos de venta. mesas Esto hace que sea ms sencillo tratar los subtipos como un grupo cuando sea necesario. Los subtipos se pueden especializar como sea necesario aadindoles comportamientos. Los subtipos de un subtipo especializado heredan tambin los comportamientos aadidos. El modelo orientado a objetos utiliza la relacin extiende (extends) para indicar la herencia de estado y de comportamiento. En este tipo de herencia tanto el subtipo como el supertipo deben ser clases. Las clases que extienden a otra clase ganan acceso a todos los estados y

comportamientos del supertipo, incluyendo cualquier cosa que el supertipo haya adquirido a travs de la herencia de otras interfaces. Una clase puede extender, como mximo, a otra clase. Sin embargo, si se construye una jerarqua de extensiones, las clases de ms abajo en la jerarqua heredan todo lo que sus supertipos heredan de las clases que tienen por encima. El modelo permite al diseador que declare una extensin (extent) para cada tipo de objeto como una clase. La extensin de un tipo tiene un nombre e incluye todas las definido instancias de objetos persistentes creadas a partir de dicho tipo. Declarar una extensin denominada empleados para el tipo de objeto Empleado es similar a crear un objeto de tipo et<Empleado> denominado empleados. Una extensin se puede indexar para que el acceso a su contenido sea ms rpido. na clase con una extensin puede tener una o ms claves (key). Una clave es un identificador U nico. Cuando una clave est formada por una sola propiedad, es una clave simple; si est formada por varias propiedades, es una clave compuesta. A diferencia del modelo relacional, nicas no son un requisito. las claves Una implementacin de un tipo consta de dos partes: la representacin y los mtodos. La representacin es una estructura de datos dependiente de un lenguaje de programacin que contiene las propiedades del tipo. Las especificaciones de la implementacin vienen de conexin con un lenguaje (language binding). Esto quiere decir que la representacin una interna de un tipo ser diferente dependiendo del lenguaje de programacin que se utilice y que un mismo tipo puede tener ms de una representacin. Los detalles de las operaciones de un tipo se especifican mediante un conjunto de mtodos. n E especificacin externa de cada operacin debe haber al menos un mtodo. Sin la embargo, un tipo puede incluir mtodos que nunca se ven desde fuera del tipo. Estos mtodos son los que realizan algunas funciones necesarias para otros mtodos del tipo. Los mtodos se escribirn en el mismo lenguaje de programacin utilizado para expresar la representacin del tipo. Si una base de datos soporta aplicaciones programadas en C++, Java y malltalk, entonces ser necesario tener tres implementaciones para cada tipo, una para cada lenguaje, aunque cada programa de aplicacin utilizar solo la implementacin que le corresponda. 1.1.3.4 Propiedades El modelo de objetos ODMG define dos tipos de propiedades: atributos y relaciones. Un atributo se define del tipo de un objeto. Un atributo no es un objeto de primera clase, por lo tanto no tiene identificador, pero toma como valor un literal o el identificador de un objeto. Las relaciones se definen entre tipos. El modelo actual solo soporta relaciones binarias con cardinalidad 1:1, 1:N y N:M. Una relacin no tiene nombre y tampoco es un objeto de primera clase, pero define caminos transversales en la interface de cada direccin. En el lado del muchos de la relacin, los objetos pueden estar desordenados (set o bag) u ordenados (list). La integridad de las relaciones la mantiene automticamente el SGBD y se genera una excepcin se intenta atravesar una relacin en la que uno de los objetos participantes se ha cuando

borrado. El modelo aporta operaciones para formar (form) y eliminar (drop) miembros de una relacin. 1.1.3.5. Transacciones El modelo estndar soporta el concepto de transacciones, que son unidades lgicas de trabajo que llevan a la base de datos de un estado consistente a otro estado consistente. El modelouna secuencia lineal de transacciones que se ejecutan de modo controlado. asume La concurrencia se basa en bloqueos estndar de lectura/escritura con un protocolo pesimista de control de concurrencia. Todos los accesos, creacin, modificacin y borrado de objetos persistentes se deben realizar dentro de una transaccin. El modelo especifica operaciones para iniciar, terminar (commit) y abortar transacciones, as como la operacin de checkpoint. Esta ltima operacin hace permanentes los cambios realizados por la transaccin en curso sinliberar ninguno de los bloqueos adquiridos. 1.1.3.6 Lenguaje de definicin de objetos ODL ODL es un lenguaje de especificacin para definir tipos de objetos para sistemas compatibles ODL es el equivalente del DDL (lenguaje de definicin de datos) de los SGBD con ODMG. tradicionales. Define los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones. La sintaxis de ODL extiende el lenguaje de definicin de interfaces (IDL) de la arquitectura CORBA (Common Object Request Broker Architecture). Lenguaje de consulta de objetos OQL OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y estructuras. Est basado en SQL-92, proporcionando un superconjunto de la sintaxis de la sentencia SELECT. OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones se pueden realizar mediante los mtodos que stos poseen. El lenguaje de consulta propuesto por ODMG-93, presenta las siguientes caractersticas: No es computacionalmente completo. Sin embargo, las consultas pueden invocar mtodos, e inversamente los mtodos escritos en cualquier lenguaje de programacin consultas. pueden incluir Tiene una sintaxis abstracta. u semntica formal puede definirse fcilmente. Proporciona un acceso declarativo a los objetos. e basa en el modelo de objetos de ODMG-93. Tiene una sintaxis concreta al estilo SQL, pero puede cambiarse con facilidad. Puede optimizarse fcilmente. No proporciona operadores explcitos para la modificacin, se basa en las operaciones definidas sobre los objetos para ese fin. Proporciona primitivas de alto nivel para tratar con conjuntos de objetos, pero no restringe su utilizacin con otros constructores de colecciones.posibilidades para asociar un sublenguaje de consulta a un lenguaje de Existen dos programacin: fuerte y dbilmente. El primer caso consiste en una extensin de la gramtica del lenguaje asociado.

En el segundo caso, las funciones query tienen unos argumentos String que contienen las preguntas.

1.1.4 Encapsulamiento, herencia y polimorfismo en BDOO.

Encapsulamiento: El encapsulamiento es una tcnica para empaquetar la informacin, envolviendo los atributos y mtodos de los objetos en clases, de tal forma que se oculte lo que debe ocultarse y haga lo que est pensado para serlo. visible Con esto se trata de lograr que al tener algn cambio en la implementacin de un objeto no se tengan que modificar los programas que utilizan tal objeto. El paradigma orientado a objetos se basa en el encapsulamiento de datos y del cdigo relacionado con cada objeto en una sola unidad. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por lo tanto, la interfaz cada objeto y el resto del sistema se define mediante un conjunto de mensajes entre permitidos. En general, cada objeto est asociado con: Un conjunto de variables que contiene los datos del objeto; las variables corresponden con los atributos del modelo E-R. Un conjunto de mensajes a los que responde; cada mensaje puede o no tener parmetros o tener uno o varios. Un conjunto de mtodos, cada uno de los cuales es el cdigo que implementa un mensaje; el mtodo devuelve un valor como respuesta al mensaje. Mensaje en entorno OO no implica uso de mensajes fsicos en redes informticas. Por el contrario, hace referencia al intercambio de solicitudes entre los objetos, independientemente de los detalles correctos de su implementacin. Se utiliza a veces la expresin invocar un mtodo para detonar al hecho de enviar un mensaje a un objeto y la ejecucin del mtodo correspondiente. Tanto la estructura de los objetos como las operaciones que se pueden aplicar a ellos se incluyen en las definiciones de clases de los objetos. Encapsulamient o JERARQUIA DE TIPOS Y HERENCIA Los esquemas de BDOO suelen necesitar un gran nmero de clases. Sin embargo, varias clases son parecidas entre s. ara permitir la representacin directa de parecidos entre las clases, hay que ubicarlas en P una Sde Sespecializaciones. SEl Sconcepto Sde Sjerarqua Sde Sclases Ses Sparecido Sal jerarqua Sde

especializacin del modelo E-R. Las especializaciones de las clases son denominadas subclases; lo cual especifica atributos y mtodos adicionales para una clase existente. Los objetos creados por medio de una subclase heredan todos los atributos y mtodos de la clase padre. Algunas de estas caractersticas heredadas pueden ellas mismas haber sido heredadas de clases ms en la jerarqua. altas La herencia mltiple y repetida permite que se pueda declarar una clase como heredera de varias, e incluso de ella misma. La herencia simple permite heredar slo de una clase padre. En estos casos, se implementan interfaces que permiten simular la herencia mltiple. las llamadas Otro tipo de interrelacin muy importante en este modelo es la agregacin, que permite objetos complejos o compuestos a partir de otros, correspondiendo a la construir nocin parte-de o tiene un. Por ejemplo un auto tiene un motor. La Sgenericidad Ses Sotra Sforma Sde Sinterrelacin Sque Ses Sla Scapacidad Sde Sdefinir Sclases parametrizadas (genricos), creando una plantilla que permite construir tipos. Por ejemplo, sepuede definir un vector de elementos de tipo X, siendo X el parmetro formal que se sustituye por el parmetro real cuando se requiere construir el tipo concreto, por ejemplo unctor de nmeros enteros, de personas, de vectores, etc. ve POLIMORFISMO El polimorfismo es la capacidad de tener mtodos con el mismo nombre pero con una implementacin diferente o que un mtodo sea aplicable a diferentes tipos de argumento. Una implementacin especfica de un comportamiento para una cierta clase se denomina mtodo. En un sistema polimrfico, un comportamiento puede tener ms de un mtodo que lo implemente. n mtodo puede tener acceso directamente a atributos de un objeto destino por no nombre, U al incluir cualesquiera atributos heredados de clases padres, pero debe tener acceso a atributos de otros objetos con seales secundarias. En sntesis este concepto permite enlazar el mismo nombre o smbolo de operador a dos o ms implementaciones diferentes del operador, dependiendo del tipo de objetos a los que ste se aplique. EJEMPLO: OBJETO_GEOMETRICO: Forma, Area, PuntoCentral RECTANGULO subtype_of OBJETO_GEOMETRICO (Forma=rectngulo): Ancho, Altura TRIANGULO subtype_of OBJETO_GEOMETRICO (Forma=tringulo): Lado1, Lado2, Angulo CIRCULO subtype_of OBJETO_GEOMETRICO(Forma=crculo): Radio Las dos principales formas de polimorfismo son:

Sobrecarga. Se utiliza el mismo nombre para diferentes servicios, que se distinguen por la cantidad y tipos de parmetros, stos no requieren herencia. Sobrescritura. Cuando una subclase redefine un servicio manteniendo el mismo nombre. Un lenguaje de programacin OO se disea para seleccionar automticamente el mtodo correcto para implementar la operacin, a partir de los datos asociados con la operacin como parmetros, y el nombre de la clase de objeto, esto es llamado enlace dinmico (dinamic binding). El enlace dinmico, permite que las entidades del programa puedan referenciar en tiempo de ejecucin a objetos de diferentes clases y est ntimamente relacionado con el concepto de herencia. En el ejemplo del frenado, el objeto seleccionar el mtodo de frenado apropiado, basado en los parmetros que describen el tipo de frenos. 1.1.5 Persistencia, concurrencia y recuperacin en BDOO. Persistencia La ltima propiedad asociada con sistemas OO es la persistencia, que es la capacidad del nombre, estado y comportamiento de un objeto para trascender el espacio o el tiempo. En otras palabras, el nombre, estado y comportamiento de un objeto se pueden conservar an cuando el objeto es transformado o destruido. Es la capacidad que tiene el programador para que sus datos se conserven al finalizar la ejecucin de un proceso, de forma que se puedan reutilizar en otros procesos. Una vez almacenado en memoria secundaria, se puede reconstruir para usarlo durante la ejecucin (materializacin del objeto). or ejemplo, se puede desear guardar informacin del mantenimiento de un auto, para poder P comparar los ajustes y modificaciones que se le han realizado. En este caso, el objeto persiste aun cuando sus atributos se transformen. oportar persistencia significa proporcionar mecanismos eficientes para representar y acceder a pequeos o grandes volmenes de objetos, en medios de almacenamiento no voltiles. Ventajas de almacenar juntas las estructuras de datos y las operaciones en la BO: Mejorar la manipulacin y administracin de los mdulos de cdigo, eliminando la necesidad de vincular (linke) el cdigo con las aplicaciones Aumentar la flexibilidad permitiendo especificar en qu sitio de una red se ejecuta una operacin. En general, en los SGBDOO que soportan C++, las operaciones tienen que ser programadas en C++; se almacenan en ficheros .cxx para ser vinculadas (linked) con la aplicacin. Algunas excepciones son Gemstone y OpenODB que soportan lenguajes para la definicin completa Sde Slos Smtodos S(Opal Sy OSQL). SAmbos Sproductos Salmacenan y Sejecutan Slas operaciones en el motor de la BD en lugar de hacerlo en el espacio de la aplicacin. Concurrencia e relaciona con la existencia de muchos usuarios interactuando concurrentemente en el sistema. ste debe controlar la interaccin entre las transacciones concurrentes, para evitar destruya la consistencia de la BD. que se

Para asegurar que los objetos puedan ser compartidos se utilizan tcnicas de BD: Control de concurrencia: permite que varios usuarios o aplicaciones compartan un modo seguro. objetos de Gestin de transacciones: incluye capacidades de recuperacin ante fallos de la BD. Recuperacin Proporcionar como mnimo el mismo nivel de recuperacin que los SBD actuales. De forma que, tanto en caso de fallo de hardware como de software, el sistema pueda retroceder hasta un estado coherente de los datos.

1.2 Bases de datos multidimensionales (BDM). 1.2.1 Definicin y conceptos de las BDM. Bases de datos multidimensionales on bases de datos ideadas para desarrollar aplicaciones muy concretas, como creacin de Cubos OLAP. Bsicamente no se diferencian demasiado de las bases de datos relacionales (una tabla en una base de datos multidimensional podra serlo tambin en una base de datos multidimensional), la diferencia est ms bien a nivel conceptual; en las bases de datos multidimensionales los campos o atributos de una tabla pueden ser de dos tipos, o bien representan dimensiones de la tabla, o bien representan mtricas que se desean estudiar. 1.2.2 Modelos conceptuales multidimensionales. Aunque los modelos en las fuentes de datos pueden variar, el almacn de datos debe usar un solo modelo consistente que se acomode a las necesidades de los usuarios. Los almacenes pueden almacenarse en BD relacionales, sin embargo, generalmente se usa un modelo multidimensional. e puede pensar en datos almacenados en una matriz multidimensional llamada cubo de datos o hipercubo.

Cada celda del cubo contiene datos agregados que relacionan elementos de las dimensiones. pueden ver los datos por cualquier dimensin que les interese, acercando Los usuarios el contenido de los datos al modelo mental del analista del negocio y facilitando su navegacin.

De hecho, las dimensiones actan como ndices para identificar valores dentro del cubo. El componente de acceso de los almacenes de datos soporta funcionalidad de hoja de clculo extendida, un procesamiento de consultas eficiente, consultas estructuradas, consultas ad hoc, minera de datos y vistas materializadas. As, el usuario puede navegar por los datos de distintas maneras: Drill-down (exploracin descendente), el usuario navega entre los niveles de los datos los ms resumidos a los ms detallados, ofreciendo una visin ms concreta desde y disgregando los datos. Por ejemplo, al hacer drill-down en una dimensin geogrfica con el objetivo de ver las ventas producidas en un periodo, se pueden ver las ventas de un mes particular y despus esas ventas por tipos de productos. ll-up (exploracin ascendente agregacin), desplaza jerarquas hacia Ro arriba, agrupando en unidades mayores a travs de una dimensin y que puede ser simple (los totales por producto se agregan por mes y estos por aos) o expresiones complejas que afectan a la consolidacin de datos de varias dimensiones. Slicing y Dicing (rebanar y cortar), con estos nombres se le conoce a la capacidad de r la BD desde diferentes puntos de vista, haciendo proyecciones sobre alguna ve dimensin. As, por ejemplo una rebanada de la BD de ventas puede corresponder a las Sventas Sde Slos Sproductos Sen Sun Sao. SEl Scorte Sen Srebanadas Ssuele Shacerse frecuentemente a lo largo del eje de tiempo para analizar las tendencias y encontrar patrones. Pivoting y(pivotar, Spivotacin So Srotacin), Sconsiste Sen Sreorientar Sla Svisin multidimensional de los datos rotando el cubo de daos para mostrar una orientacin diferente, por ejemplo, en dos dimensiones se pueden cambiar las filas por columnas, en vez de tener productos, por regin, en cada mes, se puede pivotear a regiones por mes, de cada producto. Nesting (anidamiento o sub-cubo), es una tcnica de visualizacin utilizada para mostrar el resultado de una consulta multidimensional que devuelve un sub-cubo, nuevamente haciendo algn tipo de proyeccin de los datos. ch Rea through (derivacin), es un modelo de extender los datos accesibles al usuario final ms all de lo que se encuentra almacenado en el servidor OLAP, consultando y recuperando de forma automtica datos de un almacn o sistema OLTP, generalmente obteniendo atributos que se calculan mediante operaciones con valores almacenados y derivados. No hay razones para limitar los datos en un cubo de datos a dos o tres dimensiones. Los diseadores Spueden Salmacenar Sfechas Susando Stantas Sdimensiones Scomo Sdeseen S(en hipercubos), si estas dimensiones son de inters para ellos. Sin embargo, ms all de la tercera dimensin, no se puede dibujar una representacin fsica de los cubos de datos. An as, es posible aplicar el proceso de pivoteo, rollup, y drilling down a hipercubos. Los primeros almacenes de datos usaban arreglos multidimensionales, creando sistemas OLAP multidimensionales (MOLAP). Si se usa un modelo relacional, se describe el sistema como un sistema OLAP relacional (ROLAP). Un almacn de datos relacional consiste de mltiples tablas relacionales. n esquema ampliamente usado para almacenes de datos multidimensionales es un esquema U de estrella. Existe una tabla central de renglones de datos, llamado tabla de factual o de hechos, que almacena datos no agregados, observables, est compuesta de tuplas, una por cada hecho registrado. La tabla factual tiene algunos atributos que representan dimensiones y otros atributos dependientes que son de inters. Cada dimensin se representa en su propia tabla, y las tablas dimensionales pueden verse como puntos de una estrella cuyo centro es la

tabla factual. Por ejemplo, en la siguiente figura, la tabla factual ORDEN, se muestra en el centro. Cada tupla de esta tabla proporciona informacin acerca de una orden, la cual involucra la venta de productos a un cliente particular. Para cada orden la tabla almacena noOrden, SidProducto, SidCliente, SidVendedor, Sfecha, SprecioUnitario Sy ScantidadOrdenada. Existen tablas dimensionales para el producto, cliente, vendedor y fecha. Cada una de ellas usarse como una dimensin en un hipercubo, permitiendo hacer consultas sobre las puede ntas de un producto particular, las ventas a un cliente particular, las ventas de un vendedor, ve o las ventas hechas en una fecha especfica. Las tablas dimensionales Producto, Cliente, Vendedor y Fecha se muestran relacionndose con atributos dimensionales correspondientes de la tabla factual. Normalmente estos sus atributos son llaves forneas en la tabla factual. Las tablas dimensionales proporcionan informacin adicional acerca de cada dimensin. P ejemplo, la tabla dimensional vendedor proporciona ms detalles del vendedor que or toma la Sorden. SLos Satributos Srestantes Sde Sla Stabla Sfactual, SnoOrden, SprecioUnitario Sy cantidadOrdenada, son atributos dependientes. Una variacin del esquema de estrella es el esquema copo (snowflake), en el cual las tablas dimensionales tienen dimensiones, porque estn normalizadas. Algunos almacenes de datos normalizan hasta tercera forma normal para acceder a los datos con mayor detalle, por ejemplo, la dimensin Producto puede poder tener tabla dimensional Proveedor, que contiene los datos de los proveedores y se una relaciona el numProveedor, si hay otras tablas no normalizadas se normalizan formando un mediante copo con la tabla factual en el centro. na U constelacin de hechos es un conjunto de tablas factuales que comparten algunas tablasdimensiones, limitando las consultas que pueden hacerse al almacn de datos. As, se de puede tener una tabla de hechos que incluye predicciones econmicas y que comparte la tabla de dimensiones de producto con la tabla de hechos de resultados econmicos. 1.2.3 Cubos e hipercubos de datos. Las primeras soluciones OLAP estuvieron basadas en bases de datos multidimensionalesestructural (dos veces un hipercubo o un arreglo multidimensional) (MDDBS). Un cubo almacenaba los datos para que se puedan manipular intuitivamente y claramente ver las asociaciones a travs de dimensiones mltiples. Los productos pioneros tal como Essbase de Arbor oftware Ssoportan Sdirectamente Slas Sdiferentes Svistas Sy Slas Smanipulaciones dimensionales requeridas por OLAP. Un cubo es una estructura multidimensional que contiene dimensiones y medidas. Las dimensiones definen la estructura del cubo y las medidas proporcionan valores numricos para el usuario final. Como estructura lgica, un cubo permite a una importantes aplicacin cliente recuperar valores como si las celdas del cubo definieran cada posible valor resumido. Las posiciones de las celdas del cubo se definen mediante la interseccin de miembros de la dimensin. Las jerarquas de dimensiones proporcionan rutas de acceso a la agregacin dentro de un cubo. Los valores de medidas se agregan en niveles no hoja para proporcionar valores de miembros de las jerarquas de dimensiones. Los cubos de informacin o cubos OLAP funcionan como los cubos de rompecabezas en los juegos, en el juego se trata de armar los colores y en el data warehouse se trata de organizar los datos por tablas o relaciones; los primeros (el juego) tienen 3 dimensiones, los cubos OLAP un nmero indefinido de dimensiones, razn por la cual tambin reciben el nombre de tienen hipercubos. Un cubo OLAP contendr datos de una determinada variable que se desea

analizar, proporcionando una vista lgica de los datos provistos por el sistema de informacin hacia el data warehouse, esta vista estar dispuesta segn unas dimensiones y podr contener informacin calculada. El anlisis de los datos est basado en las dimensiones del hipercubo, por lo tanto, se trata de un anlisis multidimensional. A la informacin de un cubo puede acceder el ejecutivo mediante tablas dinmicas en una de clculo o a travs de programas personalizados. Las tablas dinmicas le hoja permiten las vistas (cruces, filtrados, organizacin, totales) de la informacin con manipular mucha Las diferentes operaciones que se pueden realizar con cubos de informacin facilidad. se producen con mucha rapidez. Llevando estos conceptos a un data warehouse, ste es una coleccin de datos que est formada por dimensiones y variables, entendiendo como dimensiones a aquellos elementos que participan en el anlisis y variables a los valores que se desean analizar. Dimensiones Las dimensiones de un cubo son atributos relativos a las variables, son las perspectivas de anlisis de las variables (forman parte de la tabla de dimensiones). Son catlogos de informacin complementaria necesaria para la presentacin de los datos a los usuarios, comoejemplo: descripciones, nombres, zonas, rangos de tiempo, etc. Es decir, la por informacin general complementaria a cada uno de los registros de la tabla de hechos. Variables Tambin llamadas indicadores de gestin, son los datos que estn siendo analizados. Forman parte de la tabla de hechos. Ms formalmente, las variables representan algn aspecto cuantificable o medible de los objetos o eventos a analizar. Normalmente, las variables son representadas por valores detallados y numricos para cada instancia del objeto o evento En forma contraria, las dimensiones son atributos relativos a las variables, y medido. son utilizadas para indexar, ordenar, agrupar o abreviar los valores de las mismas. 1.2.4 Estructuras no-jerrquicas y jerrquicas de los datos. La implementacin del modelo Jerrquico en los productos se lleva a cabo en base a punteros; estructura fsica que vara segn los productos, e incluso un mismo producto proporciona distintas organizaciones fsicas a fin de que el usuario pueda conseguir una mayor eficiencia en el diseo fsico de la base de datos. El producto comercial de tipo Jerrquico ms extendido y el nico que ha llegado hasta nuestros das es el IMS de IBM con su lenguaje de datos DL/I2. Otro sistema Jerrquico, el ystem 2000 tambin tuvo una alta aceptacin comercial y fue adquirido posteriormente por el Instituto SAS. El modelo jerrquico fue desarrollado para permitir la representacin de aquellas situaciones de la vida real en las que predominan las relaciones de tipo 1:N. Es un modelo muy rgido en el que las diferentes entidades de las que est compuesta una determinada situacin, se organizan en niveles mltiples de acuerdo a una estricta relacin ADRE/HIJO, de manera que un padre puede tener ms de un hijo, todos ellos localizados en P el mismo nivel, y un hijo nicamente puede tener un padre situado en el nivel inmediatamente superior al suyo.

Esta estricta relacin PADRE/HIJO implica que no puedan establecerse relaciones entre segmentos dentro de un mismo nivel. La representacin grfica de un modelo jerrquico se realiza mediante la estructura de ARBOL INVERTIDO, en la que el nivel superior est ocupado por una nica entidad, bajo la cual se distribuyen el resto de las entidades en niveles que se van ramificando. Los diferentes niveles unidos por medio de las relaciones, las entidades se denominan en el caso particular quedan del modelo jerrquico SEGMENTOS, mientras que los atributos reciben el nombre de CAMPOS. Los segmentos, se organizan en niveles de manera que en un mismo nivel estn todos aquellos segmentos que dependen de un segmento de nivel inmediatamente superior. U OCURRENCIA de un segmento de una base de datos jerrquica es el conjunto de na valores particulares que toman todos los campos que lo componen en un momento determinado. nU REGISTRO de la base de datos es el conjunto formado por una ocurrencia del segmento raztodas las ocurrencias del resto de los segmentos de la base de datos que dependen y jerrquicamente de dicha ocurrencia raz. La relacin PADRE/HIJO en la que se apoyan las bases de datos jerrquicas, determina que el camino de acceso a los datos sea NICO; este camino, denominado CAMINO SECUENCIA comienza siempre en una ocurrencia del segmento raz y recorre la base JERRQUICA, de datos de arriba a abajo, de izquierda a derecha y por ltimo de adelante a atrs. El esquema es una estructura arborescente compuesta de nodos, que representan las entidades, enlazados por arcos, que representan las asociaciones o interrelaciones entre entidades. dichas La estructura del modelo de datos jerrquico es un caso particular de la del modelo en red, con fuertes restricciones adicionales derivadas de que las asociaciones del modelo jerrquico deben formar un rbol ordenado, es decir, un rbol en el que el orden de los nodos es importante. Una estructura jerrquica, tiene las siguientes caractersticas: El rbol se organiza en un conjunto de niveles. El nodo raz, el ms alto de la jerarqua, se corresponde con el nivel 0. arcos representan las asociaciones jerrquicas entre dos entidades y no Los tienen ya que no es necesario porque entre dos conjuntos de datos slo puede nombre, haber una interrelacin. Mientras que un nodo de nivel superior (padre) puede tener un nmero ilimitado de nodos de nivel inferior (hijos), al nodo de nivel inferior slo le puede corresponder un nico nodo de nivel superior. En otras palabras, un progenitor o padre puede tener varios descendientes o hijos, pero un hijo slo tiene un padre. Todo nodo, a excepcin del nodo raz, ha de tener obligatoriamente un padre. e llaman hojas los nodos que no tienen descendientes. e llama altura al nmero de niveles de la estructura jerrquica. momento al nmero de nodos. e denomina El nmero de hojas del rbol se llama peso. lo estn permitidas las interrelaciones 1:1 1:N Cada nodo no terminal y sus descendientes forman un subrbol, de forma que un rbol es una estructura recursiva. El rbol se suele recorrer en preorden; es decir, raz, subrbol izquierdo y subrbol derecho.

Entre las restricciones propias de este modelo se pueden resaltar: Cada rbol debe tener un nico segmento raz. No puede definirse ms de una relacin entre dos segmentos dentro de un rbol. No se permiten las relaciones reflexivas de un segmento consigo mismo. No se permiten las relaciones N:M. No se permite que exista un hijo con ms de un padre. Para cualquier acceso a la informacin almacenada, es obligatorio el acceso por la raz del rbol, excepto en el caso de utilizar un ndice secundario. El rbol debe recorrer siempre de acuerdo a un orden prefijado: el camino jerrquico. La estructura del rbol, una vez creada, no se puede modificar. Las estructuras jerrquicas se clasifican tambin como: Lineales: Ses Sun Scaso Sparticular Sy Ssimple Sen Sel Sque Scada Stipo Sde Sregistro Spadre Sslo puede tener un tipo de registro hijo, donde se muestra la interrelacin entre DEPARTAMENTO y EMPLEADO. Arborescente propiamente dicha: un tipo de registro padre puede tener varios tipos de registro descendientes. 1.2.5 Operadores para datos agregados multidimensionales. unto con el modelo, el Dr. Codd tambin propuso el lgebra relacional, un lenguaje formal J con serie de operadores que trabajan sobre una o varias relaciones para obtener otra una relacin resultado, sin que cambien las relaciones originales. Tanto los operandos como los resultados son relaciones, por lo que la salida de una operacin puede ser la entrada de otra operacin. Esto permite anidar expresiones del lgebra del mismo modo que se pueden anidar las expresiones aritmticas. Codd originalmente propuso ocho operandos pero slo cinco son fundamentales: restriccin, proyeccin, producto cartesiano, unin y diferencia, que permiten realizar Sla Smayora Sde Slas Soperaciones Sde Sobtencin Sde Sdatos. SLos Soperadores Sno fundamentales son la concatenacin (join), la interseccin y la divisin, que se pueden expresar de los cinco operadores fundamentales. La restriccin y la proyeccin son a partir operaciones unarias porque operan sobre una sola relacin. El resto de las operaciones son binarias porque trabajan sobre pares de relaciones. egn el anlisis OLAP, se encuentran otros tipos de operadores para datos agregados multidimensionales. Las tcnicas OLAP, son ampliamente utilizadas para este tipo de tareas, a travs del uso de sus operadores se lleva a cabo la explotacin de la informtica almacenada. Entro los operadores con los que se cuenta para realizar dichos procesos de anlisis se pueden citar: Ro ll-up Agregar valores de medidas a lo largo de jerarquas de Clasificacin. Nos permite agregar datos los Ssus Sdistintos Sniveles Sde Sag4rupacin Sdefinidos Spreviamente Sen Sel Sesquema Sen multidimensional. En otras palabras es subir las consultas de un nivel de agregacin especfico a otro ms amplio. Drill-down Desagregar valores de medidas a lo largo de jerarquas de clasificacin. Este operador OLAP permite bajar a los niveles ms atmicos de nuestro esquema multidimensional.

Drill-accross Consultar medidas de varios hechos en el mismo Cubo. Slice-dice Definir restricciones sobre niveles de jerarquas. Nos permite hacer una seleccin de los res de las dimensiones que uno requiere. val o

Pivoting Reorientar la vista multidimensional de los datos, es decir, cambiar la distribucin de filas/columnas 1.2.6 Consultas multidimensionales de datos. Expresiones multidimensionales (MDX) es el lenguaje de consulta que se utiliza para trabajar con datos multidimensionales y para recuperarlos. MDX est basado en la especificacin XML Analysis (XMLA), con extensiones especficas. MDX utiliza expresiones compuestas for de identificadores, valores, instrucciones, funciones y operadores que se pueden evaluar para recuperar un objeto (por ejemplo, un conjunto o un miembro) o un valor escalar (por ejemplo, una cadena o un nmero).

Las consultas y expresiones MDX se utilizan para lo siguiente: Devolver datos a una aplicacin cliente desde un cubo. Aplicar formato a los resultados de las consultas. Realizar tareas de diseo de cubos, como la definicin de miembros calculados, conjuntos con nombre, asignaciones con mbito e indicadores clave de rendimiento (KPI). Realizar tareas administrativas, incluida la seguridad de dimensin y de celda. MDX es superficialmente similar en muchos aspectos a la sintaxis SQL, que se suele utilizar conbases de datos relacionales. Sin embargo, MDX no es una extensin del lenguaje SQL y es diferente de SQL en muchos aspectos. Para crear expresiones MDX utilizadas para disear o proteger cubos, o para crear consultas MDX que devuelvan y apliquen formato a los datos multidimensionales, Sdebe Scomprender Slos Sconceptos Sbsicos Sde SMDX Sy Sel Smodelado dimensional, los elementos de sintaxis MDX, los operadores MDX, las instrucciones MDX y las funciones MDX.

Unidad II Bases de datos y tecnologas Web. 2.1 Herramientas y tecnologas de desarrollo para la Web. 2.1.1 Intercambio electrnico de datos (EDI). 2.1.2 e-commerce y e-bussiness. 2.1.3 e-Learning. 2.1.4 Sistemas de seguridad para desarrollos Web. 2.2 XML (Extensible Markup Language). 2.2.1 Fundamentos de XML. 2.2.2 Diseo de aplicaciones web usando XML. 2.2.3 Productos XML. 2.2.3.1 Middleware. 2.2.3.2 Bases de datos. 2.2.3.3 Sistemas de administracin de contenidos. 2.2.3.4 Motores de consulta.

Unidad III Bases de datos para el soporte en la toma de decisiones. 3.1 Bodegas de datos (Datawarehouse). 3.1.1 Definicin y objetivo. 3.1.2 Funcionamiento. 3.1.3 Consideraciones de diseo. 3.1.4 Herramientas para extraer, transformar y cargar fuentes de datos. 3.2 Procesamiento y anlisis en lnea (OLAP). 3.2.1 Definiciones y conceptos. 3.2.2 Requerimientos funcionales de los sistemas OLAP. 3.2.3 Operadores para manejo de cubos de datos del estndar SQL3. 3.2.4 Diseo de consultas a bases de datos multidimensionales. 3.2.5 Utilizacin de herramientas paraOLAP. 3.3 Mercados de datos (Data Mart). 3.3.1 Definiciones y conceptos. 3.3.2 Fases de construccin. 3.3.2.1 Anlisis. 3.3.2.2 Construccin. 3.3.2.3 Post-produccin. 3.3.3 Tecnologas. 3.3.3.1 Herramientas frontend. 3.3.3.2 Herramientas de bases de datos. 3.3.4 Proceso de diseo de consultas del mercado de datos. 3.4 Minera de datos (Data mining). 3.4.1 Definiciones y conceptos. 3.4.2 Aplicaciones de la minera de datos. 3.4.3 Diseo de mineros de datos.

You might also like