Está en la página 1de 153

INSTITUTO TECNOLGICO SUPERIOR DE ACATLN DE OSORIO

TPICOS AVANZADOS DE BD LICENCIATURA EN INFORMTICA


8 A SEMESTRE ENERO JUNIO 2012

OBJETIVO(S) GENERAL(ES) DEL CURSO


El estudiante conocer y utilizar tecnologas emergentes de bases de datos para el desarrollo de aplicaciones orientadas a objetos relacionadas con el tratamiento de informacin y soporte para la toma de decisiones.

APRENDIZAJES REQUERIDOS Dominio de diseo de bases de datos relacionales. Dominio del lenguaje SQL. Habilidad de programacin en un lenguaje orientado a objetos. Conocimiento de la arquitectura cliente-servidor. Habilidades para utilizar software de sistemas.

Unidad I. Modelos emergentes de bases de datos.


1.1 Bases de datos orientadas a objetos. 1.2 Definicin y conceptos de las BDOO. 1.3 El modelo de datos orientado a objetos. 1.4 El estndar ODMG. 1.4.1 Encapsulamiento, herencia y polimorfismo en BDOO. 1.4.2 Persistencia, concurrencia y recuperacin en BDOO. 1.5 Bases de datos multidimensionales (BDM). 1.5.1 Definicin y conceptos de las BDM.

INTRODUCCIN A LOS SISTEMAS DE BASES DE DATOS OO (SBDOO)

INTRODUCCIN Hace algunos aos, la creacin de nuevas aplicaciones requeran de una difcil seleccin de informacin para muchas fuentes. Los programas eran dependientes de las estructuras de los datos almacenados, haciendo estas estructuras difciles al cambio. Sin embargo, los Sistemas de BD (SBD) han mejorado los procesos de desarrollo de aplicacin en grandes ambientes de datos intensivos, proporcionando una sencilla y uniforme vista de datos expresada en trminos de estructuras independientes.

INTRODUCCIN Su alto nivel de caractersticas lingsticas y sus facilidades para compartir informacin de una manera controlada, hace posible que se puedan crear aplicaciones integradas ms fcilmente. La integridad de los datos est controlada por el SBD. Es decir, el SBD debe ser responsable de cada programa de aplicacin, dentro de la BD. Existe un conjunto de rutinas que facilitan el formateo de datos y accesos a los mismos.

INTRODUCCIN En la dcada pasada se gener mucho inters sobre los SBDOO. Estos sistemas tienen su origen en los lenguajes de POO. Donde los usuario no tienen que luchar contra las construcciones orientadas a la mquina (p. e. campos, atributos, etc). Sino que en su lugar deben tener la posibilidad de manejar objetos y operaciones sobre esos objetos, que se asemejan mucho ms a sus contrapartes en la realidad.

INTRODUCCIN En otras palabras, la idea fundamental es elevar el nivel de abstraccin. Elevar el nivel de abstraccin es incuestionablemente un objetivo valioso y el paradigma de objetos ha tenido mucho xito para satisfacer ese objetivo. La pregunta sera: Si el paradigma de la POO tambin puede ser aplicado satisfactoriamente en las BD.

INTRODUCCIN La idea de manejar una BD que est compuesta de objetos complejos, en lugar de tener que manejar atributos, insercin de tuplas y claves externas, etc., es obviamente ms atractiva desde el punto de vista del usuario. Aunque las disciplinas de los lenguajes de Programacin y la Administracin de BD tienen mucho en comn, tambin difieren en determinados aspectos:
Un programa de aplicacin est hecho, por definicin, para resolver algn problema especfico.

INTRODUCCIN
Por el contrario, una BD est hecha para resolver una variedad de problemas diferentes, y algunos de ellos ni siquiera son conocidos el momento de establecer las BD.

Mucha gente cree que los Sistemas de Objetos representan un gran salto hacia delante en la tecnologa de BD. Creen que las tcnicas de objetos son el enfoque a escoger para las reas de aplicaciones complejas.

Actualmente, los sistemas de software han puesto un ambiente tpico, incluyen herramientas, editores de esquema, verificadores de diseo y programas de circuito disponibles, y todo integrado. La disponibilidad de alta ejecucin en las estaciones de trabajo grfica, se han incrementado tanto en la expansin como en la complejidad de las aplicaciones de los datos intensivos. Algunos ejemplos son:
Diseo y Manufactura (CAD/CAM) Asistido por Computadora

Ingeniera de Software Asistida por Computadora (CASE).

Sistemas de Informacin de Oficinas (OIS). Manufactura Interada por Computadora (CIM). Sistema de Informacin Geogrfica (GIS). Ciencia y Medicina.

Todas stas son reas en las que los productos SQL clsicos tienden a incurrir en problemas. Sin embargo, a lo largo de los aos han sido publicados muchos artculos tcnicos sobre estos temas y ms recientemente, han entrado al mercado varios productos comerciales.

Pero el problema contina, sobre todo en nuevas herramientas, que utilizan subsistemas que requieren de muchos nmeros de datos persistentes. Donde el nivel de complejidad de estos programas y de los datos, han llegado ms all de la capacidad de los SBD tradicionales. Actualmente los programas de aplicacin, en ambientes de diseo, almacenan sus datos en estructuras de archivos de aplicacin especfica.

Aqu el estado del arte es difcil, como en la misma etapa que existi despus de introducir la tecnologa de BD. El desarrollo de las Bases de Datos Orientadas a Objetos (BDOO), con una gran cobertura, han surgido por esta necesidad. Adems combina las mejores cualidades de los archivos planos, las bases jerrquicas y relacionales. Las BDOO representan el siguiente paso (?) en la evolucin de las BD para soportar el anlisis, diseo y Programacin Orientada a Objetos (POO).

Ests permiten el desarrollo y mantenimiento de aplicaciones complejas, ya que se puede utilizar un mismo modelo conceptual y as aplicarlo al anlisis, diseo y programacin. Reduciendo el problema entre los diferentes modelos a travs de todo el ciclo de vida, con un costo significativamente menor. Como cualquier BD programable, una BDOO da un ambiente para el desarrollo de aplicaciones con un depsito persistente listo para su explotacin.

Permiten que el mismo modelo conceptual se aplique al anlisis, diseo, programacin, definicin y acceso a la BD. Esto reduce el problema del operador de traduccin entre los diferentes modelos a travs de todo el ciclo de vida. El modelo conceptual debe ser la base de las herramientas CASE OO totalmente integradas, las cuales ayudan a generar la estructura de datos y los mtodos.

Adems las BDOO ofrecen un mejor rendimiento en las mquinas que las BD por relacin, para aplicaciones o clases con estructuras complejas de datos. Sin embargo, las BDOO coexistirn con las BD Relacionales, como una forma de estructura de datos dentro de una BDOO.

ANTECEDENTES

El propsito de los Sistemas de Bases de Datos (SBD) es la gestin de grandes cantidades de informacin.

Las primeras BD surgieron del desarrollo de los sistemas de gestin de archivos.


Estos sistemas primero evolucionaron en BD de Red o en BD Jerrquicas y, ms tarde, en BD Relacionales. Las aplicaciones de BD tradicionales consisten en tareas de procesamiento de datos, tales como servicios bancarios y la gestin de nmina.

Tales aplicaciones presentan conceptualmente tipos de datos simples.

Los elementos de datos bsicos son registros bastante pequeos y cuyos campos son atmicos.
Es decir, estos campos no contienen estructuras adicionales y en los que se cumple la primera forma normal.

Las BD Relacionales (BDR) almacenan los datos en forma de tablas, renglones y columnas. De tal manera, la BDR no son adecuadas para almacenar objetos, ya que pueden contener estructuras complejas de elementos de datos y tambin apuntadores a otros objetos. Adems, los objetos incluyen instrucciones ejecutables, o mtodos, y para hacer persistentes a los objetos tambin deben proporcionar ciertos medios para almacenarlos. Los SMBDOO, se desarrollaron a principios de la dcada de los 90s para proporcionar un almacenamiento de objetos persistentes.

Sin embargo estos productos no se han comercializado con xito debido a que necesitan convertir los datos al formato MDOO. Las organizaciones no realizan esta conversin porque es muy costosa y las ganancias no compensan la inversin. En respuesta a esto, los proveedores de los DBMS tradicionales estn aumentando las capacidades de sus productos para permitir el almacenamiento de objetos. As como tambin, el almacenamiento tradicional de datos relacionales.

A tales productos se les llama SMBD de Objeto/ Relacionales, y probablemente su uso aumentar en los prximos aos. En particular Oracle, ha desarrollado diversos recursos para la modelacin y almacenamiento de objetos. Existen dos estndares importantes de objetos: El SQL3 y el ODMG-93

Las aplicaciones de las BD en reas como el Diseo Asistido por Computadora, la Ingeniera de Software y el Procesamiento de Documentos no se ajustan al conjunto de suposiciones que se hacen para aplicaciones del estilo de procesamiento de datos. El Modelo de Datos Orientado a Objetos (MDOO) se ha propuesto para tratar algunos de estos nuevos tipos de aplicaciones. El MDOO es una adaptacin a los SBD tradicionales.

El enfoque OO para la programacin fue introducida por primera vez con el lenguaje Simula 67. Que se dise para la programacin de simulacin. Smalltalk fue uno de los primeros lenguajes de Programacin OO (POO) para aplicaciones generales. Actualmente, los lenguajes Java y C++ son los lenguajes de POO ms usados.

La POO se basa en el concepto de encapsulamiento de datos y cdigo que opera sobre stos en un objeto.
La ventaja de la encapsulacin es que permite que la representacin interna de los objetos, sea cambiada sin necesidad de que las aplicaciones que los usan tengan que ser reescritas. La encapsulacin implica la Independencia Fsica de los Datos. Los objetos encapsulados son descritos por:

Una Memoria Privada (Miembros o Atributos).


Interfaz Pblica (Mtodos).

Los objetos estructurados se agrupan en clases.

El conjunto de clases est estructurado en sub y superclases, basado en una extensin del concepto ISA del modelo Entidad - Relacin. Puesto que el valor de un dato en un objeto, tambin puede ser un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto.

PRINCIPIOS DE OO

PRINCIPIOS DE ORIENTACIN A OBJETOS Es conveniente aclarar que muchos conceptos de objetos (o definiciones de stos) son bastante imprecisos y hay muy poco consenso verdadero y mucho desacuerdo, incluso en el nivel ms bsico. En particular, no hay un Modelo de datos de objetos abstracto ni formalmente definido.

PRINCIPIOS DE ORIENTACIN A OBJETOS En una BDOO, cualquier cosa es un objeto y se manipula como tal. Un Objeto es una instancia que responde a mensajes activando un mtodo.
La estructura interna no es visible para los usuarios de ese objeto.

Los sistemas OO proporcionan el concepto de Identificador del Objeto (OID) para identificar a los objetos.

PRINCIPIOS DE ORIENTACIN A OBJETOS Los identificadores de los objetos son nicos. Cada objeto tiene un solo identificador y no hay dos objetos que tengan el mismo identificador. Generalmente el identificador lo genera el sistema de manera automtica. A diferencia de las BD relacionales donde un valor de dato nico, se genera de manera externa al sistema.

PRINCIPIOS DE ORIENTACIN A OBJETOS Hay muchas situaciones en las que hacer que el sistema genere identificadores de manera automtica resulta una ventaja. Dado que libera a los seres humanos de llevar a cabo esa tarea. Sin embargo, esta caracterstica debe manejarse con precaucin. Los identificadores generados por el sistema suelen ser especficos el mismo.

PRINCIPIOS DE ORIENTACIN A OBJETOS Si se desplazan los datos a un sistema de BD diferente, hay que traducirlos. Adems, los identificadores generados por el sistema pueden resultar redundantes, si las entidades que se modelan ya disponen de identificadores unvocos externos al sistema.
Por lo general, los SMBDR se apoyan en claves definidas y controladas por el usuario (claves de usuario), para efectos de identificacin y referencia de entidades. En realidad los apuntadores estilo OID estn expresamente prohibidos en las BDR.

PRINCIPIOS DE ORIENTACIN A OBJETOS

Los objetos soportan una serie de caractersticas:


Se agrupan en tipos denominados clases. Contienen datos internos que definen su estado actual. Soportan ocultacin de datos. Pueden heredar propiedades de otros objetos.

Pueden comunicarse con otros objetos enviando o pasando mensajes.


Tienen mtodos que definen su comportamiento.

Las clases son una coleccin de objetos con propiedades similares, compartimiento comn, relaciones comunes a otras clases. La instancia es un objeto con propiedades definidas en su descripcin de la clase. El mensaje es una clase que debe tener un mtodo correspondiente. Un mensaje puede ser enviado a un objeto a ejecutar una accin. El mtodo es una lista de instrucciones detalladas que definen cmo responde un objeto a un mensaje en particular.

La superclase es la clase que deriva a otra clase. La subclase es la clase derivada de una superclase. La liga expresa compatibilidad de relaciones entre las clases. Los objetos heredan las caractersticas de su clase y de todas las clases de nivel superior a la que pertenecen. Estos principios y tcnicas hacen que las BDOO estn adecuadas a aplicaciones que implican tipos de datos complejos.

Tipos de datos complejos, tales como documentos compuestos o de diseo asistidos por computadora que combinan texto, grficos y hojas de clculo. La BD proporciona un modo natural de representar las jerarquas que aparecen en los datos complejos. La jerarqua de clases permite a la BD seguir la pista del tipo de cada objeto en el documento. Finalmente, el mecanismo de mensajes ofrece soporte natural para una interfaz de usuario grfica.

BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) El campo de las BDOO se ha introducido como una nueva rea de investigacin. Los campos de Lenguajes de Programacin, Inteligencia Artificial e Ingeniera de Software han contribuido con el uso de la tecnologa OO en el rea de las BD. El desafo del rea de BD es integrarlos en un diseo de sistema simple que mantenga el equipo deseado para cada campo.

El resultado es conservar las caractersticas centrales de las BD modernas, incluyendo: Persistencia Control de Concurrencia Recuperacin Consistencia Lenguaje de Consulta.

BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) Desde el punto de vista del desarrollador las ventajas estn dadas en ganancias de productividad, dado su modelado ms simple que facilita el desarrollo de aplicaciones. El modelado de aplicaciones es mucho ms sencillo gracias al concepto de objetos complejos y el modelo obtenido es fcilmente comprensible para el usuario. Este modelo puede ser validado directamente por el cliente de la aplicacin.

BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) El enfoque OO favorece la reutilizacin. Porque gracias al encapsulamiento y a la herencia, es fcil especializar un componente existente para responder a las necesidades particulares de la aplicacin. Desde el punto de vista del usuario final, los SMBDOO, proporcionan mayor aporte en la calidad en trminos de ergonoma, fiabilidad, evolucin y desempeo.

ESTRUCTURA DE OBJETOS El Modelo Orientado a Objetos (MOO) se basa en encapsular cdigo y datos en una nica unidad, llamada objeto.

La interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes.
El trmino mensaje en un contexto orientado a objetos, no implica el uso de un mensaje fsico en una red de computadoras. Si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles especficos de implementacin.

La capacidad de modificar la definicin de un objeto sin afectar al resto del sistema, est considerada como una de las mayores ventajas del modelo de POO.

JERARQUA DE CLASES.

En una BD existen objetos que responden a los mismos mensajes, utilizan los mismos mtodos y tienen variables del mismo nombre y tipo. Sera intil definir cada uno de estos objetos por separado por lo tanto se agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su clase.

Todos los objetos de su clase comparten una definicin comn, aunque difieran en los valores asignados a las variables. As que bsicamente las BDOO tienen la finalidad de agrupar aquellos elementos que sean semejantes en las entidades para formar una clase, dejando por separado aquellas que no lo son.

Por ejemplo: Tomemos como referencia la entidad Alumno y la entidad Maestro. Donde los atributos considerados para cada uno, son en Alumno: Nombre Direccin Telfono Especialidad Semestre Grupo

Maestro: Nombre Direccin Telfono Nmero econmico Plaza RFC Los atributos de Nombre, Direccin y Telfono se repiten en la entidad Alumno y Maestro, as que podemos agrupar estos elementos para formar la clase Persona, con dichos campos.

Quedando por separado en Alumno:


Especialidad Semestre Grupo.

Y en Maestro:
Nmero Econmico Plaza RFC.

CLASE PERSONA Nombre Direccin Telfono

HERENCIA SUPERCLASE SUBCLASES

Especialidad Semestre Grupo

Nmero Econmico Plaza RFC

CLASE ALUMNO

CLASE MAESTRO

PROBLEMAS A RESOLVER POR LOS SMBDOO

Un programa de datos intensivo es aquel que produce y/o requiere de un gran nmero de datos (muchos de ellos no podran introducirse al mismo tiempo dentro de la memoria virtual de un programa). Programar a lo grande se refiere a que los procesos de Ingeniera de Software requieran de mltiples programadores para producir programas grandes y complejos. La complejidad de estos sistemas no slo se muestra en los programas que manipulan datos sino en los datos mismos.

Por ejemplo: Los datos que son usados en la aplicacin de diseos elctricos contienen muchas interconexiones complejas, con muchas limitaciones complejas en la forma de que stas son usadas. Un circuito usa muchos componentes de diferentes tipos, y stos tienen que hacer referencia a otros componentes a los que estn conectados. Un problema en el desarrollo de aplicaciones en las BD es la incompatibilidad entre el Lenguaje de Manipulacin de Datos (DML) de las BD, y el Lenguaje de Programacin de Propsito General, en el cual el resto de las aplicaciones son escritas.

En los sistema OO, se utiliza un Lenguaje Integrado para las operaciones de BD y para las que no lo son. El lenguaje anfitrin y el lenguaje de BD estn fuertemente acoplados en estos sistemas, de hecho son los mismos. A diferencia del SQL. Una ventaja importante es que permite una mejor verificacin de tipo. Se dice que en este lenguaje unificado no hay desacoplo de impedancia entre un lenguaje de programacin procedural y el lenguaje de manipulacin de datos.

Donde desacoplo de impedancia se refiere a la diferencia entre el nivel de registro (manejado por un lenguaje de programacin) y el nivel de conjunto (como la hace SQL). De hecho los lenguajes de objetos estn en el nivel de registros (o procedimientos). Son lenguajes 3GL, no manejan conjuntos slo procedimientos. El rendimiento queda en gran parte en manos de los usuarios (programadores o el ASBD).

Los Lenguajes de Programacin de BD resuelven el problema de incompatibilidad, documentando los tipos de datos de un Lenguaje de Propsito General persistente, o agregando tipos de sistemas de un lenguaje. Sin embargo, cuando se accesan a los datos de otros lenguajes, el problema de la incompatibilidad realmente existe. Las BDOO tratan de mejorar el problema de la incompatibilidad, extendiendo el DML.

Sin embargo, pocas BDOO pueden expresar las aplicaciones complejas por s mismas. El DML carece de una manipulacin de datos de la Aplicacin. El lenguaje de propsito general tiene persistencia de datos slo en la forma de los archivos. Careciendo de un modo sofisticado de memoria persistente que incluye tipos de alto nivel, limitaciones y consultas.

Para preservar la exactitud de las BD en la ejecucin de procesos concurrentes, los sistemas de BD definen el concepto de Transacciones Atmicas. Las transacciones son unidades de trabajo que se permiten procesar de manera concurrente, garantizando resultados que son equivalentes a los resultados producidos por algunas ejecuciones seriales. Definimos esta propiedad de equivalencia como Seriabilidad.

Existen muchas implementaciones que garantizan las ejecuciones seriabilizables, en las transacciones de Read-Write. Si existen transacciones de Read y Write al mismo tiempo sobre el dato x, entonces surgir un conflicto al escribir el dato x, por lo que el manejador de datos tomar la decisin correspondiente. Las BDOO presentan una oportunidad para dar ms concurrencia que otros enfoques tradicionales.

En el enfoque OO, los sistemas de BD conocen acerca de las operaciones que van a ser ejecutadas. Para aplicaciones cooperativas, como en el diseo de ambientes, la nocin de seriabilidad es muy exacto. El diseo cooperativo est basado en la nocin de unidades de trabajo, que puedan interactuar como resultados inesperados. Esta observacin ha creado una nueva rea de inters de investigacin, basada en la Tecnologa OO en el control de concurrencia.

Por ejemplo, es muy comn ver las BDOO implementadas como un interprete de un manejador de almacenamiento. Este es el responsable de los movimientos de los objetos desde el disco hacia la memoria principal, para el manejador del Buffer y algunas transacciones de bajo nivel y tareas de recuperacin. El interprete es el responsable de proveer las facilidades requeridas en las vistas de objetos, tipos y mtodos. Esta arquitectura aparece en los sistemas de BD Relacionales.

Existen varias BD comerciales OO actualmente bajo desarrollo, pero slo un grupo de ellas estn disponibles hoy en da como productos comerciales. Sin embargo, las BDOO ya han provocado una tormenta de controversias en la comunidad de las BD. Los lenguajes de consultas para BDOO son an difciles de implementar. Existe una tensin entre encapsulacin y la vista estructural de datos caractersticos de lenguajes de consulta tales como: SQL y QUEL.

Una BDOO debe tener por lo mismo los siguientes requerimientos:


Debe proporcionar funcionalidad en la BD. Incluir todas las caractersticas esenciales. Debe soportar la Identificacin de Objetos (OID). Debe proporcionar Encapsulamiento. Esta encapsulacin puede ser la base por la cual todos los objetos abstractos son definidos. Debe soportar objetos con estado complejo. El estado de un objeto puede referirse a otros objetos.

HERENCIA. Las clases en un Sistema OO se representan en forma jerrquica. As que las propiedades o caractersticas de un elemento, las contendrn (o heredarn) los elementos que de sta se deriven. Decimos por lo tanto que las entidades derivadas son subclases de la clase padre o Superclase. Se pueden crear muchas agrupaciones (clases) para simplificar un modelo.

CONSULTAS ORIENTADAS A OBJETOS. Los lenguajes de POO, requieren que toda la interaccin con objetos se realice mediante el envo de mensajes.
El trmino mensaje en un entorno OO no implica el uso de mensajes fsicos en la red. Por el contrario hace referencia al intercambio de solicitudes entre los objetos. Se utiliza a veces la expresin invocar a un mtodo para denotar el hecho de enviar un mensaje a un objeto y la ejecucin del mtodo correspondiente.

CONSULTAS ORIENTADAS A OBJETOS.


Dado que la nica interfaz externa presentada por cada objeto es el conjunto de mensajes a los que responde, resulta posible modificar las definiciones de los mtodos y de las variables sin afectar al resto del sistema.
La posibilidad de modificar la definicin de un objeto sin afectar al resto del sistema se considera una de las mayores ventajas del paradigma de la POO.

Consideremos un ejemplo con una entidad Alumno, y deseamos que la consulta realice la bsqueda de todos los alumnos que cursan la materia de Base de Datos II. Para realizar esta consulta, se tendra que enviar un mensaje a cada instancia Alumno dentro del sistema.

Generalmente en una BD hay muchos objetos similares. Por similar se entiende que responden a los mismos mensajes, utilizan los mismos mtodos y tienen variables del mismo nombre y del mismo tipo. As un lenguaje de consultas para un sistema de BDOO, debe incluir tanto el modelo de pasar el mensaje de objeto a objeto, como el modelo de pasar el mensaje de conjunto en conjunto.

Ejemplo del lenguaje para Manipulacin de objetos C++ de ODMG int crear_titular_cuenta(String nombre, String direccion{ d_Database bd_banco_obj; d_Database * bd_banco = &bd_banco_obj; bd_banco->open(BD-Banco); d_Transacction Trans; Trans.begin(); d_Ref<Cuenta> cuenta = new(bd_banco, Cuenta)Cuenta; d_Ref<Cliente> clien = new(bd_banco, Cliente)Cliente; clien->nombre = nombre; clien->direccin = direccin; clien->cuentas.insert_element(cuenta); cuenta->titulares.insert_element(clien); .. Trans.commit(); Bd_banco->close();

COMPLEJIDAD DE MODIFICACIN. En las BDOO pueden existir los siguientes cambios:


Adicin de una nueva clase: Para realizar este proceso, la nueva clase debe colocarse en la jerarqua de clase o subclase, cuidando las variables o mtodos de herencia correspondientes. Eliminacin de una clase: Se requiere la realizacin de varias operaciones, se debe de cuidar los elementos que se han heredado de esa clase a otras y reestructurar la jerarqua.

En s la estructuracin de modelos OO simplifica la estructura, evitando elementos o variables repetidas en diversas entidades.

COMPLEJIDAD DE MODIFICACIN. Sin embargo el precio de esto es dedicarle un minucioso cuidado a las relaciones entre las clases cuando el modelo es complejo. La dificultad del manejo de objetos radica en la complejidad de las modificaciones y eliminaciones de clases. Ya que de tener variables que heredan de otros objetos, se tiene que realizar una reestructuracin que involucra una serie de pasos complejos.

PROGRAMACIN ORIENTADA A OBJETOS. POO (Object-Oriented Programming). Muchas organizaciones que actualmente usan tecnologa orientada a objetos tambin desean los beneficios de los SMBDOO. En otras palabras, se desea la migracin de BD y aplicaciones de BD Relacionales a OO.

PROGRAMACIN ORIENTADA A OBJETOS. La migracin a la tecnologa de objetos consiste de la ingeniera reversa de los programas de aplicacin y la migracin de la BD. El objetivo de la migracin de la BD es tener un esquema equivalente y la BD disponibles bajo los nuevos SMBDOO. Esto desde luego puede ser logrado por medio de la transformacin manual del cdigo de los programas lo cual resulta demasiado complicado.

PROGRAMACIN ORIENTADA A OBJETOS. Para esto existen tres enfoque que hacen uso de la tecnologa de objetos para BD Relacionales (BDR). Construir una interface OO sobre el Sistema de BDR. La migracin a un SBD Objetos/Relacional. Conversin del esquema de BDR a uno OO.

PROGRAMACIN ORIENTADA A OBJETOS. Construir una interface OO sobre el Sistema de BDR. El primer enfoque retiene la BDR y crea una interface OO encima de sta. Este enfoque es el ms fcil. No existe interrupcin del sistema para la migracin de datos y no existe prdida semntica de la informacin. Por otro lado el rendimiento disminuye debido que no existe un buen acoplamiento entre los dos paradigmas en el tiempo de ejecucin.

PROGRAMACIN ORIENTADA A OBJETOS. La migracin a un SBD Objetos/Relacional. En el segundo enfoque, los datos deben ser migrados de acuerdo con el SMBD (por ejemplo Oracle 7 a 8). Y las caractersticas Orientadas a Objetos slo pueden ser explotadas con la modificacin o extensin del esquema.

PROGRAMACIN ORIENTADA A OBJETOS. Conversin del esquema de BDR a uno OO. El tercer enfoque es la migracin de la base de datos en donde un nuevo esquema bajo el SMBDOO es creado. Y los datos son migrados de la Base de Datos Relacional a la Orientada a Objetos. Cada uno de los tres enfoques anteriores tiene sus ventajas y desventajas.

Especialmente el tercero, una metodologa y herramientas de soporte son crticas para una migracin exitosa.

DISEO DE DISTRIBUCIN DE OBJETOS

DISTRIBUCIN DE OBJETOS. Dos aspectos importantes del diseo de distribucin son: La Fragmentacin y la Colocacin. El diseo de la distribucin en el mundo de objetos trae nuevas complejidades, debido al encapsulamiento de mtodos junto con los estados de los objetos. Un problema es que los mtodos estn implementados y compartidos por todas las instancias de objetos de ese tipo.

DISTRIBUCIN DE OBJETOS. Se tiene que decidir si la fragmentacin se realiza solamente sobre los atributos, duplicando los mtodos en cada fragmento. O si los mtodos se puedan fragmentar.

Hay que recordar que algunos dominios de algunos atributos pueden ser clases.
Por lo que la fragmentacin de clases con respecto a tales atributos puede afectar en otras clases.

DISTRIBUCIN DE OBJETOS. Y si la fragmentacin se lleva a cabo con respecto a los mtodos, es necesario distinguir entre mtodos simples y mtodos compuestos.
Mtodos Simples son aquellos que no invocan a otros mtodos. Mientras que los Complejos invocan mtodos de otras clases.

PARTICIONAMIENTO DE CLASE HORIZONTAL

Comencemos con una fragmentacin de una clase con mtodos y atributos simples.

DISTRIBUCIN DE OBJETOS. PARTICIONAMIENTO DE CLASE HORIZONTAL

Para este caso, el particionamiento horizontal primario se puede lograr de acuerdo a un predicado definido en un atributo de la clase. Donde cada clase (o subclase) derivada satisface el predicado de particionamiento particular de la clase original. Si estos predicados son mutuamente exclusivos, entonces las instancias de la clases son disjuntos.

DISTRIBUCIN DE OBJETOS. PARTICIONAMIENTO DE CLASE VERTICAL

La fragmentacin vertical es considerablemente ms compleja.


Por ejemplo al fragmentar una clase verticalmente produce un nmero de clases (o subclases), cada una conteniendo algunos atributos y mtodos. Por lo que cada uno de los fragmentos tiene menos definiciones que la clase original.

DISTRIBUCIN DE OBJETOS. PARTICIONAMIENTO DE CLASE VERTICAL

Si los mtodos son simples, entonces los mtodos pueden particionarse fcilmente.
Y cuando no son simples, la ubicacin de estos mtodos llega a ser un verdadero problema.

COLOCACIN DE OBJETOS. El problema de la colocacin de datos, para las BDOO, involucra la ubicacin de mtodos y clases. Y como las aplicaciones de las BDOO invocan mtodos, la ubicacin de stos afecta el rendimiento de las aplicaciones. La colocacin de mtodos los cuales necesitan accesar mltiples clases en diferentes sitios, es un problema el cual an no ha sido abordado. Existen cuatro alternativas para la colocacin de objetos.

COLOCACIN DE OBJETOS. 1. Comportamiento Local Objeto Local. Tanto el comportamiento (mtodo) del objeto, como los argumentos se encuentran de manera local. 2. Comportamiento Local Objeto Remoto. En este caso el comportamiento y el objeto al cual se le aplica, estn localizados en diferentes sitios.
Una alternativa consiste en mover el objeto remoto al sitio donde el comportamiento se localiza. Otra es enviar la implementacin del comportamiento al sitio donde reside el objeto.

COLOCACIN DE OBJETOS. 3. Comportamiento Remoto Objeto Local. Es el caso inverso del punto 2. 4. Funcin Remota Argumento Remoto. Caso inverso del punto 1.

REPLICACIN
La replicacin agrega una nueva dimensin al problema del diseo. Objetos, Clases de Objetos, o Colecciones de Objetos ( o todo) pueden ser replicados.

ARQUITECTURA DE UNA BDOO

ARQUITECTURA. Una manera de desarrollar un sistema distribuido es la de Cliente/Servidor. La mayora de los actuales SMBDOO son sistemas cliente/servidor.

Donde el cliente solicita objetos del servidor.


Y el servidor los obtiene de la BD y los regresa al cliente solicitante. Estos sistemas son llamados Servidor de Objetos.

ARQUITECTURA DE UNA BDOO. En la siguiente se muestran algunos de los principales productos de BDOO y sus vendedores.
PRODUCTO Gemstone Itasca PROVEEDOR Servio Corporation, Alameda,CA Itasca Systems,Inc.,Minneapolis,MN

Objectivity
Object Store Ontos Versant

Objectivity,Menlo Park,Ca
Object Design,Inc.,Burlington,MA Ontos Inc.,Bellerica,MA Versant Object Technology,Menlo Park,CA

Seis Productos de BDOO y sus Proveedores.

Arquitectura de una BDOO Los primeros se disearon como una extensin de los lenguajes de programacin como Smalltalk C++.
Por ejemplo el sistema GemStone y su lenguaje OPAL, estn basados en Smalltalk, uno de los lenguajes de objetos ms puros.

Aunque recientemente los lenguajes de objetos ms importantes son Java y C++ en ese orden, que han desplazado a otros.

A pesar del hecho de que estos dos son menos puros que smalltalk.

Arquitectura de una BDOO El DML (Lenguaje para La Manipulacin de Datos) y el DDL (Lenguaje para la Definicin de los Datos) constituyen un lenguaje OO comn.

El diseo de las BDOO actuales deben aprovechar al mximo las caractersticas del CASE, e incorporar mtodos creados con cualquier tcnica poderosa.

Desarrollo con Bases de Datos OO Las BDOO se desarrollan al describir, en primer lugar, los tipos de objetos importantes del dominio. Estos tipos de objetos determinan las clases que conformarn la definicin de la BDOO. Por ejemplo: Una BD diseada para almacenar la geometra de ciertas partes mecnicas incluira clases como CILINDRO, ESFERA y CUBO.

Desarrollo con Bases de Datos OO El comportamiento de CILINDRO podra incluir informacin relativa a sus dimensiones, volumen, rea, etc.:
Clase de CILINDRO{ ALTURA RADIO VOLUMEN AREA };

FLOTANTE (); FLOTANTE (); FLOTANTE (); FLOTANTE ();

Se puede llegar a definiciones similares para el cubo y la esfera.

Desarrollo con Bases de Datos OO En la definicin anterior, ALTURA, RADIO y REA representan los mensajes que se pueden enviar a un objeto CILINDRO. La Implantacin se lleva a cabo en el mismo lenguaje, escribiendo funciones correspondientes a las solicitudes OO:

CILINDRO::ALTURA ( ) {RETORNA CILINDRO_ALTURA;} CILINDRO::VOLUMEN ( ) {RETORNA PI * RADIO ( ) * ALTURA ( ) ;}

Desarrollo con Bases de Datos OO En este caso, la Altura se almacena como un elemento de los datos, mientras que Volumen se calcula mediante la frmula apropiada. Observe que la implantacin interna de Volumen utiliza solicitudes para obtener Altura y Radio. Sin embargo, el aspecto ms importante es la sencillez y uniformidad que experimentan los usuarios de CILINDRO.

Desarrollo con Bases de Datos OO Slo necesitan conocer la forma de enviar una solicitud y las solicitudes disponibles.

TRES ENFOQUES DE CONSTRUCCIN DE BDOO. Las BDOO se pueden construir mediante alguno de los tres enfoques siguientes: El Primero.- se puede utilizar el cdigo actual altamente complejo de los sistemas de administracin de las BD, de modo que una BDOO se implante ms rpido sin tener que iniciar de cero.

TRES ENFOQUES DE CONSTRUCCIN DE BDOO. El Primero Las Tcnicas OO se pueden utilizar como medios para el diseo sencillo de sistemas complejos.

Los sistemas se construyen a partir de componentes ya probados con un formato definido para las solicitudes de las operaciones del componente.

TRES ENFOQUES DE CONSTRUCCIN DE BDOO. El Segundo: Considera a la BDOO como una extensin de la tecnologa de las BD por Relacin.

De este modo, las herramientas, tcnicas, y vasta experiencia de la tecnologa por relacin se utilizan para construir un nuevo SMBD.
Se pueden aadir apuntadores a las tablas de relacin para ligarlas con objetos binarios de gran tamao. La BD tambin debe proporcionar a las aplicaciones clientes, un acceso aleatorio y por partes a grandes objetos, con el fin de que slo sea necesario recuperar a travs de la red la parte solicitada de los datos.

TRES ENFOQUES DE CONSTRUCCIN DE BDOO. El Tercero: reflexiona sobre la arquitectura de los SBD y produce una nueva arquitectura optimizada, que cumple las necesidades de la tecnologa OO. Las compaas como Versant, Objectivity, Itasca, etc., utilizan este enfoque y afirman que la tecnologa de relacin es un subconjunto de una capacidad ms general. Adems mencionan que las BDOO son aproximadamente dos veces ms rpidas que las bases de datos por relacin, para almacenar y recuperar la informacin compleja.

TRES ENFOQUES DE CONSTRUCCIN DE BDOO. El Tercero Por lo tanto, son esenciales en aplicaciones como CAD y permitiran que un depsito CASE fuera una facilidad de tiempo real en vez de una facilidad por lotes. La Arquitectura de Versant est orientada al soporte Cliente/Servidor con acercamiento a la computacin distribuida. Cualquier peticin del Cliente, el Servidor la procesa. Los servidores pueden cooperar en una BD distribuida de Versant. Las BD pueden estar levantadas como un sistema mCliente/n-Servidor.

IMPACTO DE LA ORIENTACIN A OBJETOS EN LA INGENIERA DEL SOFTWARE. En las BDOO, la organizacin "Grupo de Administracin de Datos Objeto (ODMG)" representa el 100% de las BDOO industriales. Y ha establecido un estndar de BD equivalente a SQL:
ODL.- Lenguaje de Definicin de Datos Objetos, y OQL.- Lenguaje de Consulta a Objetos.

Respecto a las relacionales, todas (Oracle, Informix, etc.) estn aadiendo en mayor o menor grado algunos aspectos de la OO.

IMPACTO DE LA ORIENTACIN A OBJETOS EN LA INGENIERA DEL SOFTWARE. ANSI (Instituto Nacional Americano de Estndar), por su parte, est definiendo un SQL-3 que incorpora muchos aspectos de la OO.

El futuro del SQL-3 es sin embargo incierto, ya que ODMG ha ofrecido a ANSI su estndar para que sirva de base para un nuevo SQL.

Con lo que slo habra un nico estndar de BD.

IMPACTO DE LA ORIENTACIN A OBJETOS EN LA INGENIERA DEL SOFTWARE. El grupo ODMG (Grupo Manejador de Datos Objeto) naci de un grupo ms grande, llamado "Grupo Manejador de Objetos (OMG). Este grupo est definiendo un estndar universal por objetos. Este estndar permitir que un objeto sea programado en cualquier lenguaje y sistema operativo. Facilitando enormemente el desarrollo de sistemas abiertos cliente-servidor.

VENTAJAS EN BDOO. Est su flexibilidad, y soporte para el manejo de tipos de datos complejos.

Por ejemplo, en una BD convencional:


Si una empresa adquiere varios clientes por referencia de clientes- servicio. Pero la BD existente, que mantiene la informacin de clientes y sus compras, no tiene un campo para registrar quin proporcion la referencia. O de qu manera fue dicho contacto. O si debe compensarse con una comisin, sera necesario reestructurar la BD para aadir este tipo de modificaciones o de datos.

VENTAJAS EN BDOO. Por el contrario, en una BDOO, el usuario puede aadir una "subclase" de la clase de clientes para manejar las modificaciones que representan los clientes por referencia. La subclase heredar todos los atributos, caractersticas de la definicin original, adems se especializar en especificar los nuevos campos que se requieren as como los mtodos para manipular solamente esos campos.

Naturalmente se generan los espacios para almacenar la informacin adicional de los nuevos campos.

VENTAJAS EN BDOO. Esto presenta la ventaja adicional que una BDOO puede ajustarse a usar siempre el espacio de los campos que son necesarios, eliminando espacio desperdiciado en registros con campos que nunca usan.

La segunda ventaja de una BDOO, es que manipula datos complejos en forma rpida y gilmente.

La estructura de la base de datos est dada por referencias (o apuntadores lgicos) entre objetos, los famosos IDOs.

POSIBLES DESVENTAJAS. Al considerar la adopcin de la tecnologa orientada a objetos, la inmadurez del mercado de BDOO constituye una posible fuente de problemas.

Por lo que debe analizarse con detalle la presencia en el mercado del proveedor para adoptar su producto en una lnea de produccin sustantiva.

El segundo problema es la falta de estndares en la industria OO.

POSIBLES DESVENTAJAS. Sin embargo, el "Grupo Manejador de Objetos" (OMG), es una organizacin Internacional de proveedores de sistemas de informacin y usuarios dedicada a promover estndares para el desarrollo de aplicaciones y sistemas OO en ambientes de cmputo en red.

La implantacin de una nueva tecnologa requiere que los usuarios iniciales acepten cierto riesgo.

Aquellos que esperan resultados a corto plazo y con un costo reducido quedarn desilusionados.

POSIBLES DESVENTAJAS. Sin embargo, para aquellos usuarios que planean:


A un futuro intermedio con una visin tecnolgica avanzada. El uso de tecnologa avanzada o de punta. Y el uso de Tecnologa OO.

Paulatinamente compensarn todos los riesgos.

RENDIMIENTO. Las BDOO permiten que los objetos hagan referencia directamente a otros mediante apuntadores suaves. Esto hace que las BDOO pasen ms rpido del objeto A al objeto B que las BDR. Las cuales deben utilizar comandos JOIN para lograr sto. Incluso el JOIN optimizado es ms lento que un recorrido de los objetos.

RENDIMIENTO. As, incluso sin alguna afinacin especial, una BDOO es en general ms rpida en esta mecnica de cazaapuntadores. Las BDOO hacen que el agrupamiento sea ms eficiente.

La mayora de los SBD permiten que el operador coloque cerca las estructuras relacionadas entre s, en el espacio de almacenamiento en disco. Esto reduce en forma radical el tiempo de recuperacin de los datos relacionados, puesto que todos los datos se leen con una lectura de disco, en vez de varias.

RENDIMIENTO. Sin embargo, en una BDR, los objetos de la implantacin se traducen en representaciones tabulares que generalmente se dispersan en varias tablas. As, en una BDR, estos renglones relacionados deben quedar agrupados, de modo que todo el objeto se pueda recuperar mediante una nica lectura del disco. Esto es automtico en una BDOO. Adems, el agrupamiento de los datos relacionados, como todas las subpartes de un ensamble, puede afectar radicalmente el rendimiento general de una aplicacin.

RENDIMIENTO. Esto es relativamente directo en una BDOO, puesto que representa el primer nivel de agrupamiento. Por el contrario, el agrupamiento fsico es imposible en una BDR, puesto que esto requiere un segundo nivel de agrupamiento:
Un nivel para agrupar las hileras que representan a los objetos individuales

Y un segundo para los grupos de hileras que representan a los objetos relacionados.

RENDIMIENTO. Un SMBDOO debe satisfacer dos criterios:


Ser un Sistema OO.

Y ser un Sistema de Administracin de BD.

El primer criterio se traduce en ocho caractersticas generales: Abstraccin, encapsulacin, modularidad, jerarqua, control de tipos, concurrencia, persistencia y genericidad. El segundo criterio se traduce en cinco caractersticas principales: Persistencia, concurrencia, recuperacin ante fallos del sistema, gestin del almacenamiento secundario y facilidad de consultas.

Caractersticas de SGBDOO .

Segundo Criterio. Con 5 caractersticas.

Primer Criterio. Con 8 caractersticas.

RENDIMIENTO. Como se puede observar la Persistencia, al igual que la Concurrencia, son caractersticas del SMBDOO heredadas tanto del SMBD como del Modelo de Objetos. La Persistencia en el caso del SMBD hace referencia a la conservacin de los datos despus de la finalizacin del proceso que los cre. En el caso del Modelo de Objetos, se refiere no slo a la conservacin del estado de un objeto, si no tambin a la conservacin de la clase, que debe trascender a cualquier programa individual.

RENDIMIENTO. De forma que todos los programas interpreten de la misma manera el estado almacenado.

La Concurrencia heredada del SMBD se refiere a la capacidad del sistema para gestionar a mltiples usuarios interactuando concurrentemente sobre el sistema.

Mientras que la concurrencia heredada del Modelo de Objetos, hace referencia a la capacidad de distinguir a un objeto activo de otro que no lo est.

RENDIMIENTO. Persistencia.- 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.

Concurrencia.- Se relaciona con la existencia de muchos usuarios interactuando concurrentemente en el sistema. ste debe controlar la interaccin entre las transacciones concurrentes, para evitar que se destruya la consistencia de la BD.

RENDIMIENTO. 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. Gestin del almacenamiento secundario.- Es soportada por un conjunto de mecanismos que no son visibles al usuario. Tales como gestin de ndices, agrupacin de datos, seleccin del camino de acceso, optimizacin de consultas, etc.

RENDIMIENTO.

Gestin del almacenamiento secundario


Estos mecanismos evitan que los programadores tengan que escribir programas para mantener ndices, asignar el almacenamiento en disco, o trasladar los datos entre el disco y la memoria principal. Crendose de esta forma una independencia entre los Niveles Lgicos y Fsicos del sistema.

Facilidad de Consultas.Permitir al usuario hacer cuestiones sencillas a la BD. Este tipo de consultas tienen como misin proporcionar la informacin solicitada por el usuario de una forma correcta y rpida.

INTEGRIDAD. Los sistemas de objetos no soportan generalmente restricciones de integridad declarativas. En vez de ello, requieren que tales restricciones se hagan cumplir por medio de cdigo procedural (por mtodos o programas de aplicacin).

Niveles:
Ningn soporte del sistema. Validacin de referencias.

Mantenimiento del sistema


Semntica personalizada

CONTROVERSIA. Las BD de Objetos surgieron por la necesidad que tenan los programadores de aplicaciones OO, de conservar sus objetos en una memoria persistente. Esa memoria persistente podra considerarse una BD, pero el punto importante es que en realidad fue especificada por la aplicacin. No era una BD compartida, de propsito general que pretendiera ser adecuada para aplicaciones que no hubieran sido previstas al momento de definir la BD.

CONTROVERSIA. Muchas caractersticas que son esenciales en los SBD, sencillamente no fueron requerimiento en el mundo de los objetos, al menos no originalmente. Se podra decir que un SBDOO no es un SMBD, por:
Un SMBDR ya viene listo para ser usado. Tan pronto como el sistema est instalado, los usuarios pueden comenzar a construir y manipular las BDs. Un SMBDOO, por el contrario, puede ser visto como un Kit de Construccin de SMBD. Cuando es instalado por primero vez, NO est disponible para su uso inmediato. Primero debe ser adaptado por tcnicos capaces y experimentados.

CONTROVERSIA.

Estos tcnicos son quienes tambin definen las clases y mtodos necesarios para la BD. Y slo cuando esta actividad de adaptacin haya terminado, el sistema estar disponible para que los programadores de aplicaciones y los usuarios finales lo utilicen. Se puede observar, que el SMBD adaptado resultante ser especfico de una aplicacin en particular. Podra por ejemplo, ser adaptado para aplicaciones CAD/CAM, pero esencialmente intil para otro tipo de aplicaciones (mdicas, documentos, etc). En otras palabras, todava no sera un SMBD de propsito general, como lo son los SMBDRs.

CONTROVERSIA. En esencia el modelo de objetos dice que podemos almacenar cualquier cosa que queramos, cualquier estructura de datos que podamos definir.

El modelo relaciona dice lo mismo, pero adems insiste en que cualquier cosa que almacenemos debe ser presentada ante el usuario en forma relacional pura.

El modelo relacional no dice nada acerca de lo que puede ser almacenado fsicamente.

CONTROVERSIA. Por lo tanto no impone lmites sobre cules estructuras de datos son permitidas en el nivel fsico.

El nico requerimiento es que cualquier estructura que de hecho est guardada fsicamente, debe ser transformada a relaciones en el nivel lgico y por lo tanto, debe ser oculta ante el usuario.

Los sistemas relacionales hacen una distincin clara entre lo lgico y lo fsico (el modelo de datos contra la implementacin).

CONTROVERSIA. Mientras que los sistemas basados en objetos no lo hacen.

SMBD DE OBJETOS/RELACIONALES

SMBD O/R. Recientemente varios fabricantes han lanzado productos SMBD de Objetos/Relacionales. Tambin conocidos en el mercado, como Servidores Universales. Ejemplos de stos:
Universal Database de DB2.

Universal Data Option para Informix Dynamic Server.


Oracle 8i Universal Server, Database Server o Enterprise Server.

SMBD O/R. La idea general es que los productos deben soportar posibilidades de objetos y relacionales. Los productos en cuestin son intentos acercamiento entre las dos tecnologas. de un

En los SBDR, se complica el manejar estructuras complejas, pero el soporte ya est ah en forma de Dominios. No se necesita hacer nada, para lograr la funcionalidad de objetos en los sistemas relacionales.

SMBD O/R. Es decir, slo se necesita implementarlo, completa y adecuadamente.

Por lo tanto, se cree que un sistema relacional que soporte adecuadamente los dominios, sera capaz de manejar todos estos tipos de datos problemticos, que segn se dice, slo pueden manejar los sistemas de objetos. Tambin se cree que un sistema de objetos/relacional verdadero, sera un sistema relacional verdadero.

SMBD O/R. Los fabricantes de SMBD deberan ser motivados para que hicieran lo que, de hecho, estn tratando de hacer. Extender sus sistemas para que incluyan el soporte apropiado de tipos o dominios.

Una implicacin importante del soporte apropiado para los tipos de datos, es que se permite que los fabricantes de otras compaas construyan y vendan paquetes de tipos de datos separados, que pueden ser incorporados al SMBD.

SMBD O/R. Estos paquetes incluyen soporte para el manejo de Texto Sofisticado, el procesamiento de Series de Tiempo Financieras, el Anlisis de Datos Geoespaciales (cartogrficos), etc.

A dichos paquetes se les conoce de diversas formas:


Navajas de Datos (Informix). Cartuchos de Datos (Oracle) Extensores Relacionales (IBM)

SMBD O/R. Sin embargo, la incorporacin de un nuevo paquete de tipos al sistema es una labor no trivial.

Y la capacidad de hacerlo tiene implicaciones importantes para el diseo y la estructura del propio SMBD.

Por ejemplo, considere lo que pasara si alguna consulta incluyera referencia hacia datos de algn tipo definido por el usuario, o invocaciones a algn operador definido por el usuario.

SMBD O/R. Consideraciones para el sistema:


El compilador del lenguaje de consultas debe ser capaz de analizar sintcticamente y verificar el tipo que se solicita. Por lo que tiene que saber acerca de esos tipos y operadores definidos.

El optimizador tiene que ser capaz de decidir un plan de consulta adecuado para esa solicitud y por lo tanto, estar consciente de las propiedades de los tipos y operadores definidos.

El componente que administra el almacenamiento fsico tiene que soportar las estructuras de almacenamiento nuevas.

SMBD O/R. El efecto de lo anterior es que el sistema necesita ser extensible, y en varios niveles: Anlisis sintctico y verificacin de tipos.
En un sistema en el cual los usuarios pueden definir sus propios tipos y operadores, no se puede manejar de manera integrada el anlisis y verificacin de tipos por el compilador del lenguaje de consultas. Se debe redisear el catlogo del sistema (o al menos extendido). El compilador mismo necesita ser reescrito para acceder al catlogo a fin de obtener la informacin necesaria.

SMBD O/R. Optimizacin.


Transformacin de expresiones (reescritua de consultas). Debe ser dinmico, y no preestablecido. Selectividad. Porcentaje de tuplas que la hacen verdadera. Esta selectividad debe ser integrado en el optimizador. Frmulas de Costo. El optimizador necesita saber cunto cuesta ejecutar un operador definido por el usuario. Estructuras de Almacenamiento y Mtodos de Acceso. El optimizador debe conocer esta informacin.

SMBD O/R. En resumen, Stonebraker est argumentado que los sistemas de Objetos/Relacionales estn en el futuro de todos.

ESTNDARES

PRIMER INTENTO DE ESTANDARIZACIN: ODMG93. La mayor limitacin de las BDOO es la carencia de un estndar.

ODMG-93 (Object-Oriented Database Management Group) es un punto de partida muy importante para ello.

Adopta una arquitectura que consta de un sistema de gestin que soporta un lenguaje de BDOO, con una sintaxis similar a un lenguaje de programacin, tambin OO como puede ser C++ o Smalltalk.

PRIMER INTENTO DE ESTANDARIZACIN: ODMG93. El Lenguaje de BD se especifica mediante:


Un Lenguaje de Definicin de Datos (ODL). Un Lenguaje de Manipulacin de Datos (OML).

Y un Lenguaje de Consulta (OQL).

Siendo todos ellos portables a otros sistemas, con el fin de conseguir la portabilidad de la aplicacin completa.

PRIMER INTENTO DE ESTANDARIZACIN: ODMG93. En definitiva, ODMG-93 intenta definir un SMBDOO que integre las capacidades de las BD con las capacidades de los lenguajes de programacin.

De forma que los objetos de la BD aparezcan como objetos del lenguaje de programacin.

Intentando de esta manera eliminar la falta de correspondencia existente entre los sistemas de tipos de ambos lenguajes.

PRIMER INTENTO DE ESTANDARIZACIN: ODMG93. El SMBDOO extiende el lenguaje con persistencia, concurrencia, recuperacin de datos, consultas asociativas, etc.

Lenguaje ODL

El Lenguaje de Definicin de Datos (ODL) en un SMBDOO es empleado para facilitar la portabilidad de los esquemas de las BD.

LENGUAJE ODL Este ODL no es un lenguaje de programacin completo, define las propiedades y los prototipos de las operaciones de los tipos, pero no los mtodos que implementan esas operaciones.

El ODL intenta definir tipos que puedan implementarse en diversos lenguajes de programacin.

No est por tanto ligado a la sintaxis concreta de un lenguaje de programacin particular.

LENGUAJE ODL De esta forma un esquema especificado en ODL, puede ser soportado por cualquier SMBDOO que sea compatible con ODMG-93.

La sintaxis de ODL es una extensin de la IDL (Interface Definition Language) desarrollado por OMG como parte de CORBA (Common Object Request Broker Architecture).

LENGUAJE OML. El Lenguaje de Manipulacin es empleado para la elaboracin de programas que permitan crear, modificar y borrar datos que constituyen la BD.

ODMG-93 sugiere que este lenguaje sea la extensin de un lenguaje de programacin, de forma que se pueden realizar entre otras las siguientes operaciones sobre la base de datos: Creacin, Borrado, Modificacin e Identificacin de un Objeto.

LENGUAJE OQL. 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 pueden incluir consultas. Tiene una sintaxis abstracta. Su semntica formal puede definirse fcilmente. Proporciona un acceso declarativo a los objetos.

LENGUAJE OQL.
Se 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.

LENGUAJE OQL. Existen dos posibilidades para asociar un sublenguaje de consulta a un lenguaje de programacin: fuerte y dbilmente. El primer caso, Lenguaje de Programacin Fuerte, consiste en una extensin de la gramtica del lenguaje asociado. En el segundo caso, Lenguaje de Programacin Dbil, las funciones query tienen unos argumentos String que contienen las preguntas.

LENGUAJE OQL.
Ejemplo de una consulta con OQL, presentando el aspecto de SQL:

d_Set< d_Ref<Cuenta> > resultado; d_OQL_Query q1(select a from Cliente c, c.cuentas a where c.nombre = Juan and c.obtener_saldo() > 100); d_oql_execute(q1, resultado);

LENGUAJE OO. Para poder utilizar a los Lenguajes OO en un sistema de BD, existen dos alternativas:
Se pueden utilizar como herramientas de diseo y codificacin. Por ej. Una interfaz en una BDR.

Extender el lenguaje de tratamiento de datos como SQL, aadiendo tipos complejos y la POO. Los sistemas que proporcionan extensiones de este tipo a sistemas relacionales, se denominan Relaciones Orientadas a Objetos (ROO).
Otra opcin es tomar un lenguaje de POO y extenderlo para que trabaje con las BD. Estos lenguajes se denomiann Lenguajes de Programacin Persistente.

CONCLUSIONES. En conclusin sabemos que las BDOO representan el siguiente paso en la evolucin de las BD, para soportar el Anlisis, Diseo y Programacin OO. Las BDOO permiten el desarrollo y mantenimiento de aplicaciones complejas con un costo significativamente menor. Permiten que el mismo modelo conceptual se aplique al anlisis, diseo, programacin, definicin y acceso a la BD.

CONCLUSIONES. Esto reduce el problema del operador de traduccin entre los diferentes modelos a travs de todo el ciclo de vida del sistema. El modelo conceptual debe ser la base de las herramientas CASE OO totalmente integradas, las cuales ayudan a generar la estructura de datos y los mtodos. Las BDOO ofrecen un mucho mejor rendimiento de la mquina que las BDR, para aplicaciones o clases con estructuras complejas de datos.

CONCLUSIONES. Sin embargo, las BDOO coexistirn con las BDR durante los prximos aos. Puesto que a menudo se utilizar un modelo por relacin como una forma de estructura de datos, dentro de una BDOO. Podemos decir que en conclusin, con el caso de Oracle, que ha aumentado la demanda de una representacin de objetos complejos en las actuales aplicaciones convencionales.

Principles Of Distributed Database Systems 2. Ed. M. Tamer Ozsu y Patrick Valduriez

Prentice Hall
Procesamiento de Bases de Datos 8a. Ed. David M. Kroenke Pearson. Introduccin a los Sistemas de Bases de Datos 7a. Ed. C. J. Date Prentice Hall.