Sistemas manejadores de bases de datos orientadas a objetos smbdoo
Download
1 / 152

SISTEMAS MANEJADORES DE BASES DE DATOS ORIENTADAS A OBJETOS (SMBDOO) - PowerPoint PPT Presentation


  • 104 Views
  • Uploaded on

SISTEMAS MANEJADORES DE BASES DE DATOS ORIENTADAS A OBJETOS (SMBDOO). INTRODUCCIÓN A LOS SISTEMAS DE BASES DE DATOS OO (SBDOO). INTRODUCCIÓN Hace algunos años, la creación de nuevas aplicaciones requerían de una difícil selección de información para muchas fuentes.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' SISTEMAS MANEJADORES DE BASES DE DATOS ORIENTADAS A OBJETOS (SMBDOO)' - jara


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


  • INTRODUCCIÓN (SMBDOO)

  • Hace algunos años, la creación de nuevas aplicaciones requerían de una difícil selección de información para muchas fuentes.

  • Los programas eran dependientes de las estructuras de los datos almacenados, haciendo estas estructuras difíciles al cambio.

  • Sin embargo, los Sistemas de BD (SBD) han mejorado los procesos de desarrollo de aplicación en grandes ambientes de datos intensivos, proporcionando una sencilla y uniforme vista de datos expresada en términos de estructuras independientes.


  • INTRODUCCIÓN (SMBDOO)

  • Su alto nivel de características lingüísticas y sus facilidades para compartir información de una manera controlada, hace posible que se puedan crear aplicaciones integradas más fácilmente.

  • La integridad de los datos está controlada por el SBD.

  • Es decir, el SBD debe ser responsable de cada programa de aplicación, dentro de la BD.

  • Existe un conjunto de rutinas que facilitan el formateo de datos y accesos a los mismos.


  • INTRODUCCIÓN (SMBDOO)

  • En la década pasada se generó mucho interés 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 máquina (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 más a sus contrapartes en la realidad.


  • INTRODUCCIÓN (SMBDOO)

  • En otras palabras, la idea fundamental es elevar el nivel de abstracción.

  • Elevar el nivel de abstracción es incuestionablemente un objetivo valioso y el paradigma de objetos ha tenido mucho éxito para satisfacer ese objetivo.

  • La pregunta sería: Si el paradigma de la POO también puede ser aplicado satisfactoriamente en las BD.


  • INTRODUCCIÓN (SMBDOO)

  • La idea de manejar una BD que está compuesta de “objetos complejos”, en lugar de tener que manejar atributos, inserción de tuplas y claves externas, etc., es obviamente más atractiva desde el punto de vista del usuario.

  • Aunque las disciplinas de los lenguajes de Programación y la Administración de BD tienen mucho en común, también difieren en determinados aspectos:

    • Un programa de aplicación está hecho, por definición, para resolver algún problema específico.


  • INTRODUCCIÓN (SMBDOO)

    • 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 tecnología de BD.

  • Creen que las técnicas de objetos son el enfoque a escoger para las áreas de aplicaciones “complejas”.


  • Actualmente, los sistemas de software han puesto un ambiente típico, incluyen herramientas, editores de esquema, verificadores de diseño y programas de circuito disponibles, y todo integrado.

  • La disponibilidad de alta ejecución en las estaciones de trabajo gráfica, se han incrementado tanto en la expansión como en la complejidad de las aplicaciones de los datos intensivos.

  • Algunos ejemplos son:

    • Diseño y Manufactura Asistido por Computadora (CAD/CAM)

    • Ingeniería de Software Asistida por Computadora (CASE).


  • Sistemas de Información de Oficinas (OIS). típico, incluyen herramientas, editores de esquema, verificadores de diseño y programas de circuito disponibles, y todo integrado.

  • Manufactura Interada por Computadora (CIM).

  • Sistema de Información Geográfica (GIS).

  • Ciencia y Medicina.

  • Todas éstas son áreas en las que los productos SQL clásicos tienden a incurrir en problemas.

  • Sin embargo, a lo largo de los años han sido publicados muchos artículos técnicos sobre estos temas y más recientemente, han entrado al mercado varios productos comerciales.


    • Pero el problema continúa, sobre todo en nuevas típico, incluyen herramientas, editores de esquema, verificadores de diseño y programas de circuito disponibles, y todo integrado. herramientas, que utilizan subsistemas que requieren de muchos números de datos persistentes.

    • Donde el nivel de complejidad de estos programas y de los datos, han llegado más allá de la capacidad de los SBD tradicionales.

    • Actualmente los programas de aplicación, en ambientes de diseño, almacenan sus datos en estructuras de archivos de aplicación específica.


    • Aquí el estado del arte es difícil, como en la misma etapa que existió después de introducir la tecnología de BD.

    • El desarrollo de las Bases de Datos Orientadas a Objetos (BDOO), con una gran cobertura, han surgido por esta necesidad.

    • Además combina las mejores cualidades de los archivos planos, las bases jerárquicas y relacionales.

    • Las BDOO representan el siguiente paso (?) en la evolución de las BD para soportar el análisis, diseño y Programación Orientada a Objetos (POO).


    • Estás permiten el desarrollo y mantenimiento de aplicaciones complejas, ya que se puede utilizar un mismo modelo conceptual y así aplicarlo al análisis, diseño y programación.

    • Reduciendo el problema entre los diferentes modelos a través 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 depósito persistente listo para su explotación.


    • Permiten que el mismo modelo conceptual se aplique al análisis, diseño, programación, definición y acceso a la BD.

    • Esto reduce el problema del operador de traducción entre los diferentes modelos a través 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 métodos.


    • Además las BDOO ofrecen un mejor rendimiento en las máquinas que las BD por relación, para aplicaciones o clases con estructuras complejas de datos.

    • Sin embargo, las BDOO coexistirán con las BD Relacionales, como una forma de estructura de datos dentro de una BDOO.


    Antecedentes

    ANTECEDENTES máquinas que las BD por relación, para aplicaciones o clases con estructuras complejas de datos.


    • El propósito de los Sistemas de Bases de Datos (SBD) es la gestión de grandes cantidades de información.

    • Las primeras BD surgieron del desarrollo de los sistemas de gestión de archivos.

    • Estos sistemas primero evolucionaron en BD de Red o en BD Jerárquicas y, más tarde, en BD Relacionales.

    • Las aplicaciones de BD tradicionales consisten en tareas de procesamiento de datos, tales como servicios bancarios y la gestión de nómina.


    • Tales aplicaciones presentan conceptualmente tipos de datos gestión de grandes cantidades de información.simples.

    • Los elementos de datos básicos son registros bastante pequeños y cuyos campos son atómicos.

    • 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 también apuntadores a otros objetos.

    • Además, los objetos incluyen instrucciones ejecutables, o métodos, y para hacer persistentes a los objetos también deben proporcionar ciertos medios para almacenarlos.

    • Los SMBDOO, se desarrollaron a principios de la década 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 conversión porque es muy costosa y las ganancias no compensan la inversión.

    • En respuesta a esto, los proveedores de los DBMS tradicionales están aumentando las capacidades de sus productos para permitir el almacenamiento de objetos.

    • Así como también, el almacenamiento tradicional de datos relacionales.



    • Las aplicaciones de las BD en áreas como el Diseño Asistido por Computadora, la Ingeniería 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 adaptación a los SBD tradicionales.


    • El enfoque OO para la programación fue introducida por primera vez con el lenguaje Simula 67.

    • Que se diseñó para la programación de simulación.

    • Smalltalk fue uno de los primeros lenguajes de Programación OO (POO) para aplicaciones generales.

    • Actualmente, los lenguajes Java y C++ son los lenguajes de POO más usados.


    • La POO s primera vez con el lenguaje Simula 67e basa en el concepto de encapsulamiento de datos y código que opera sobre éstos en un objeto.

      • La ventaja de la encapsulación es que permite que la representación interna de los objetos, sea cambiada sin necesidad de que las aplicaciones que los usan tengan que ser reescritas.

      • La encapsulación implica la Independencia Física de los Datos.

      • Los objetos encapsulados son descritos por:

        • Una Memoria Privada (Miembros o Atributos).

        • Interfaz Pública (Métodos).


    • Los objetos estructurados se agrupan en primera vez con el lenguaje Simula 67clases.

    • El conjunto de clases está estructurado en sub y superclases, basado en una extensión del concepto ISA del modelo Entidad - Relación.

    • Puesto que el valor de un dato en un objeto, también puede ser un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto.


    Principios de oo

    PRINCIPIOS DE OO primera vez con el lenguaje Simula 67


    • PRINCIPIOS DE ORIENTACIÓN A OBJETOS primera vez con el lenguaje Simula 67

      • 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 más básico.

      • En particular, no hay un “Modelo de datos de objetos” abstracto ni formalmente definido.


    • PRINCIPIOS DE ORIENTACIÓN A OBJETOS primera vez con el lenguaje Simula 67

      • En una BDOO, cualquier cosa es un objeto y se manipula como tal.

      • Un Objeto es una instancia que responde a mensajes activando un método.

        • 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 ORIENTACIÓN A OBJETOS primera vez con el lenguaje Simula 67

      • 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 automática.

      • A diferencia de las BD relacionales donde un valor de dato único, se genera de manera externa al sistema.


    • PRINCIPIOS DE ORIENTACIÓN A OBJETOS primera vez con el lenguaje Simula 67

      • Hay muchas situaciones en las que hacer que el sistema genere identificadores de manera automática resulta una ventaja.

      • Dado que libera a los seres humanos de llevar a cabo esa tarea.

      • Sin embargo, esta característica debe manejarse con precaución.

      • Los identificadores generados por el sistema suelen ser específicos el mismo.


    • PRINCIPIOS DE ORIENTACIÓN A OBJETOS primera vez con el lenguaje Simula 67

      • Si se desplazan los datos a un sistema de BD diferente, hay que traducirlos.

      • Además, los identificadores generados por el sistema pueden resultar redundantes, si las entidades que se modelan ya disponen de identificadores unívocos externos al sistema.

        • Por lo general, los SMBDR se apoyan en claves definidas y controladas por el usuario (claves de usuario), para efectos de identificación y referencia de entidades.

        • En realidad los apuntadores estilo OID están expresamente prohibidos en las BDR.


    • PRINCIPIOS DE ORIENTACIÓN A OBJETOS primera vez con el lenguaje Simula 67

      • Los objetos soportan una serie de características:

      • Se agrupan en tipos denominados clases.

      • Contienen datos internos que definen su estado actual.

      • Soportan ocultación de datos.

      • Pueden heredar propiedades de otros objetos.

      • Pueden comunicarse con otros objetos enviando o pasando mensajes.

      • Tienen métodos que definen su comportamiento.


    • Las primera vez con el lenguaje Simula 67clases son una colección de objetos con propiedades similares, compartimiento común, relaciones comunes a otras clases.

    • La instancia es un objeto con propiedades definidas en su descripción de la clase.

    • El mensaje es una clase que debe tener un método correspondiente.  Un mensaje puede ser enviado a un objeto a ejecutar una acción.

    • El método es una lista de instrucciones detalladas que definen cómo responde un objeto a un mensaje en particular.


    • La primera vez con el lenguaje Simula 67superclasees la clase que deriva a otra clase.

    • La subclase es la clase derivada de una superclase.

    • La ligaexpresa compatibilidad de relaciones entre las clases.

    • Los objetosheredan las características de su clase y de todas las clases de nivel superior a la que pertenecen.

    • Estos principios  y técnicas hacen que las BDOO estén adecuadas a aplicaciones que implican tipos de datos complejos.


    • Tipos de datos complejos, tales como documentos compuestos o de diseño asistidos por computadora que combinan texto, gráficos y hojas de cálculo.

    • La BD proporciona un modo natural de representar las jerarquías que aparecen en los datos complejos.

    • La jerarquía 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 gráfica.


    • BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) de diseño asistidos por computadora que combinan texto, gráficos y hojas de cálculo.

      • El campo de las BDOO se ha introducido como una nueva área de investigación.

      • Los campos de Lenguajes de Programación, Inteligencia Artificial e Ingeniería de Software han contribuido con el uso de la tecnología OO en el área de las BD.

      • El desafío del área de BD es integrarlos en un diseño de sistema simple que mantenga el equipo deseado para cada campo.



    • BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) las BD  modernas, incluyendo:

      • Desde el punto de vista del desarrollador las ventajas están dadas en ganancias de productividad, dado su modelado más simple que facilita el desarrollo de aplicaciones.

      • El modelado de aplicaciones es mucho más sencillo gracias al concepto de objetos complejos y el modelo obtenido es fácilmente comprensible para el usuario.

      • Este modelo puede ser validado directamente por el cliente de la aplicación.


    • BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) las BD  modernas, incluyendo:

      • El enfoque OO favorece la reutilización.

      • Porque gracias al encapsulamiento y a la herencia, es fácil especializar un componente existente para responder a las necesidades particulares de la aplicación.

      • Desde el punto de vista del usuario final, los SMBDOO, proporcionan mayor aporte en la calidad en términos de ergonomía, fiabilidad, evolución y desempeño.


    • ESTRUCTURA DE OBJETOS las BD  modernas, incluyendo:

      • El Modelo Orientado a Objetos (MOO) se basa en encapsular código 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 término mensaje en un contexto orientado a objetos, no implica el uso de un mensaje físico en una red de computadoras.

      • Si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación.


  • JERARQUÍA DE CLASES.

    • En una BD existen objetos que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo.

    • Sería inútil 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 definición común, aunque difieran en los valores asignados a las variables.

    • Así que básicamente 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 común, aunque difieran en los valores asignados a las variables.Alumno y la entidad Maestro.

    • Donde los atributos considerados para cada uno, son en Alumno:

    • Nombre

    • Dirección

    • Teléfono

    • Especialidad

    • Semestre

    • Grupo


    • Maestro común, aunque difieran en los valores asignados a las variables.:

    • Nombre

    • Dirección

    • Teléfono

    • Número económico

    • Plaza

    • RFC

    • Los atributos de Nombre, Dirección y Teléfono 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 común, aunque difieran en los valores asignados a las variables.Alumno:

      • Especialidad

      • Semestre

      • Grupo.

    • Y en Maestro:

      • Número Económico

      • Plaza

      • RFC.


    CLASE PERSONA común, aunque difieran en los valores asignados a las variables.

    Nombre

    Dirección

    Teléfono

    • HERENCIA

      • SUPERCLASE

      • SUBCLASES

    • Número

    • Económico

    • Plaza

    • RFC

    • Especialidad

    • Semestre

    • Grupo

    CLASE ALUMNO

    CLASE MAESTRO


    Problemas a resolver por los smbdoo

    PROBLEMAS A RESOLVER POR LOS SMBDOO común, aunque difieran en los valores asignados a las variables.


    • Un programa de datos intensivo es aquel que produce y/o requiere de un gran número de datos (muchos de ellos no podrían introducirse al mismo tiempo dentro de la memoria virtual de un programa).

    • Programar a lo grande se refiere a que los procesos de Ingeniería de Software requieran de múltiples programadores para producir programas grandes y complejos.

    • La complejidad de estos sistemas no sólo se muestra en los programas que manipulan datos sino en los datos mismos.


    • Por ejemplo: Los datos que son usados en la aplicación de diseños eléctricos 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 están conectados.

    • Un problema en el desarrollo de aplicaciones en las BD es la incompatibilidad entre el Lenguaje de Manipulación de Datos (DML) de las BD, y el Lenguaje de Programación de Propósito General, en el cual el resto de las aplicaciones son escritas.


    • En los sistema OO, se utiliza un diseños eléctricos contienen muchas interconexiones complejas, con muchas limitaciones complejas en la forma de que éstas son usadas.Lenguaje Integrado para las operaciones de BD y para las que no lo son.

    • El lenguaje anfitrión y el lenguaje de BD están fuertemente acoplados en estos sistemas, de hecho son los mismos. A diferencia del SQL.

    • Una ventaja importante es que permite una mejor verificación de tipo.

    • Se dice que en este lenguaje unificado no hay desacoplo de impedancia entre un lenguaje de programación procedural y el lenguaje de manipulación de datos.


    • Donde diseños eléctricos contienen muchas interconexiones complejas, con muchas limitaciones complejas en la forma de que éstas son usadas.desacoplo de impedancia se refiere a la diferencia entre el nivel de registro (manejado por un lenguaje de programación) y el nivel de conjunto (como la hace SQL).

    • De hecho los lenguajes de objetos están en el nivel de registros (o procedimientos).

    • Son lenguajes “3GL”, no manejan conjuntos sólo procedimientos.

    • El rendimiento queda en gran parte en manos de los usuarios (programadores o el ASBD).


    • Los Lenguajes de Programación de BD resuelven el problema de incompatibilidad, documentando los tipos de datos de un Lenguaje de Propósito 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 manipulación de datos de la Aplicación.

    • El lenguaje de propósito general tiene persistencia de datos sólo 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 ejecución de procesos concurrentes, los sistemas de BD definen el concepto de Transacciones Atómicas.

    • 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 decisión correspondiente.

    • Las BDOO presentan una  oportunidad para dar más 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 diseño de ambientes, la noción de seriabilidad es muy exacto.

    • El diseño cooperativo está basado en la noción de unidades de trabajo, que puedan interactuar como resultados inesperados.

    • Esta observación ha creado una nueva área de interés de investigación, basada en la Tecnología OO en el control de concurrencia.


    • Por ejemplo, es muy común 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 recuperación.

    • El interprete es el responsable de proveer las facilidades requeridas en las vistas de objetos, tipos y métodos.

    • Esta arquitectura aparece en los sistemas de BD Relacionales.


    • Existen varias BD comerciales OO actualmente bajo desarrollo, pero sólo un grupo de ellas están disponibles hoy en día 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 aún difíciles de implementar.

    • Existe una tensión entre encapsulación y la vista estructural de datos característicos 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 características esenciales.

    • Debe soportar la Identificación de Objetos (OID).

    • Debe proporcionar Encapsulamiento. Esta encapsulación 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. requerimientos:

      • Las clases en un Sistema OO se representan en forma jerárquica.

      • Así que las propiedades o características de un elemento, las contendrán (o heredarán) 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. requerimientos:

      • Los lenguajes de POO, requieren que toda la interacción con objetos se realice mediante el envío de mensajes.

        • El término mensaje en un entorno OO no implica el uso de mensajes físicos en la red.

        • Por el contrario hace referencia al intercambio de solicitudes entre los objetos.

        • Se utiliza a veces la expresión invocar a un método para denotar el hecho de enviar un mensaje a un objeto y la ejecución del método correspondiente.


    • CONSULTAS ORIENTADAS A OBJETOS. requerimientos:

      • 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 métodos y de las variables sin afectar al resto del sistema.

      • La posibilidad de modificar la definición 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 búsqueda de todos los alumnos que cursan la materia de Base de Datos II.

    • Para realizar esta consulta, se tendría que enviar un mensaje a cada instancia Alumno dentro del sistema.


    • Generalmente en una BD hay muchos objetos similares. requerimientos:

    • Por similar se entiende que responden a los mismos mensajes, utilizan los mismos métodos 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 Manipulación 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->dirección = dirección;

      • clien->cuentas.insert_element(cuenta);

      • cuenta->titulares.insert_element(clien);

      • …..

      • Trans.commit();

      • Bd_banco->close();

      • }


    • COMPLEJIDAD DE MODIFICACIÓN. ODMG

    • En las BDOO pueden existir los siguientes cambios:

      • Adición de una nueva clase: Para realizar este proceso, la nueva clase debe colocarse en la jerarquía de clase o subclase, cuidando las variables o métodos de herencia correspondientes.

      • Eliminación de una clase: Se requiere la realización de varias operaciones, se debe de cuidar los elementos que se han heredado de esa clase a otras y reestructurar la jerarquía.

      • En sí la estructuración de modelos OO simplifica la estructura, evitando elementos o variables repetidas en diversas entidades.


    • COMPLEJIDAD DE MODIFICACIÓN. ODMG

      • 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 reestructuración que involucra una serie de pasos complejos.


    • PROGRAMACIÓN ORIENTADA A OBJETOS. ODMG

    • POO (Object-Oriented Programming).

    • Muchas organizaciones que actualmente usan tecnología orientada a objetos también desean los beneficios de los SMBDOO.

    • En otras palabras, se desea la migración de BD y aplicaciones de BD Relacionales a OO.


    • PROGRAMACIÓN ORIENTADA A OBJETOS. ODMG

    • La migración a la tecnología de objetos consiste de la ingeniería reversa de los programas de aplicación y la migración de la BD.

    • El objetivo de la migración 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 transformación manual del código de los programas lo cual resulta demasiado complicado.


    • PROGRAMACIÓN ORIENTADA A OBJETOS. ODMG

    • Para esto existen tres enfoque que hacen uso de la tecnología de objetos para BD Relacionales (BDR).

      • Construir una interface OO sobre el Sistema de BDR.

      • La migración a un SBD Objetos/Relacional.

      • Conversión del esquema de BDR a uno OO.


    • PROGRAMACIÓN ORIENTADA A OBJETOS. ODMG

    • 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 más fácil.

    • No existe interrupción del sistema para la migración de datos y no existe pérdida semántica de la información.

    • Por otro lado el rendimiento disminuye debido que no existe un buen acoplamiento entre los dos paradigmas en el tiempo de ejecución.


    • PROGRAMACIÓN ORIENTADA A OBJETOS. ODMG

      La migración 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 características Orientadas a Objetos sólo pueden ser explotadas con la modificación o extensión del esquema.


    • PROGRAMACIÓN ORIENTADA A OBJETOS. ODMG

      Conversión del esquema de BDR a uno OO.

    • El tercer enfoque es la migración 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 metodología y herramientas de soporte son críticas para una migración exitosa.



    • DISTRIBUCIÓN DE OBJETOS. ODMG

    • Dos aspectos importantes del diseño de distribución son: La Fragmentación y la Colocación.

    • El diseño de la distribución en el mundo de objetos trae nuevas complejidades, debido al encapsulamiento de métodos junto con los estados de los objetos.

    • Un problema es que los métodos están implementados y compartidos por todas las instancias de objetos de ese tipo.


    • DISTRIBUCIÓN DE OBJETOS. ODMG

    • Se tiene que decidir si la fragmentación se realiza solamente sobre los atributos, duplicando los métodos en cada fragmento.

    • O si los métodos se puedan fragmentar.

    • Hay que recordar que algunos dominios de algunos atributos pueden ser clases.

    • Por lo que la fragmentación de clases con respecto a tales atributos puede afectar en otras clases.


    • DISTRIBUCIÓN DE OBJETOS. ODMG

    • Y si la fragmentación se lleva a cabo con respecto a los métodos, es necesario distinguir entre métodos simples y métodos compuestos.

      • Métodos Simples son aquellos que no invocan a otros métodos.

      • Mientras que los Complejos invocan métodos de otras clases.

    • PARTICIONAMIENTO DE CLASE HORIZONTAL

    • Comencemos con una fragmentación de una clase con métodos y atributos simples.


    • DISTRIBUCIÓN DE OBJETOS. ODMG

    • 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.


    • DISTRIBUCIÓN DE OBJETOS. ODMG

    • PARTICIONAMIENTO DE CLASE VERTICAL

    • La fragmentación vertical es considerablemente más compleja.

    • Por ejemplo al fragmentar una clase verticalmente produce un número de clases (o subclases), cada una conteniendo algunos atributos y métodos.

    • Por lo que cada uno de los fragmentos tiene menos definiciones que la clase original.


    • DISTRIBUCIÓN DE OBJETOS. ODMG

    • PARTICIONAMIENTO DE CLASE VERTICAL

    • Si los métodos son simples, entonces los métodos pueden particionarse fácilmente.

    • Y cuando no son simples, la ubicación de estos métodos llega a ser un verdadero problema.


    • COLOCACIÓN DE OBJETOS. ODMG

    • El problema de la colocación de datos, para las BDOO, involucra la ubicación de métodos y clases.

    • Y como las aplicaciones de las BDOO invocan métodos, la ubicación de éstos afecta el rendimiento de las aplicaciones.

    • La colocación de métodos los cuales necesitan accesar múltiples clases en diferentes sitios, es un problema el cual aún no ha sido abordado.

    • Existen cuatro alternativas para la colocación de objetos.


    • COLOCACIÓN DE OBJETOS. ODMG

    • Comportamiento Local – Objeto Local. Tanto el comportamiento (método) del objeto, como los argumentos se encuentran de manera local.

    • Comportamiento Local – Objeto Remoto. En este caso el comportamiento y el objeto al cual se le aplica, están localizados en diferentes sitios.

      • Una alternativa consiste en mover el objeto remoto al sitio donde el comportamiento se localiza.

      • Otra es enviar la implementación del comportamiento al sitio donde reside el objeto.


    • COLOCACIÓN DE OBJETOS. ODMG

    • Comportamiento Remoto – Objeto Local. Es el caso inverso del punto 2.

    • Función Remota – Argumento Remoto. Caso inverso del punto 1.

    • REPLICACIÓN

    • La replicación agrega una nueva dimensión al problema del diseño.

    • Objetos, Clases de Objetos, o Colecciones de Objetos ( o todo) pueden ser replicados.



    • ARQUITECTURA. ODMG

    • Una manera de desarrollar un sistema distribuido es la de Cliente/Servidor.

    • La mayoría 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 ODMG.

    En la siguiente se muestran algunos de los principales productos de BDOO y sus vendedores.

    Seis Productos de BDOO y sus Proveedores.


    • Arquitectura de ODMGuna BDOO

    • Los primeros se diseñaron como una extensión de los lenguajes de programación como Smalltalk ó C++.

      • Por ejemplo el sistema GemStone y su lenguaje OPAL, están basados en Smalltalk, uno de los lenguajes de objetos más puros.

      • Aunque recientemente los lenguajes de objetos más 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 ODMGuna BDOO

    • El DML (Lenguaje para La Manipulación de Datos) y el DDL (Lenguaje para la Definición de los Datos) constituyen un lenguaje OO común.

    • El diseño de las BDOO actuales deben aprovechar al máximo las características del CASE, e incorporar métodos creados con cualquier técnica poderosa.


    • Desarrollo con Bases de Datos OO ODMG

    • Las BDOO se desarrollan al describir, en primer lugar, los tipos de objetos importantes del dominio.

    • Estos tipos de objetos determinan las clases que conformarán la definición de la BDOO.

    • Por ejemplo: Una BD diseñada para almacenar la geometría de ciertas partes mecánicas incluiría clases como CILINDRO, ESFERA y CUBO.


    • Desarrollo con Bases de Datos OO ODMG

    • El comportamiento de CILINDRO podría incluir información relativa a sus dimensiones, volumen, área, etc.:

      • Clase de CILINDRO{ ALTURA FLOTANTE (); RADIO FLOTANTE (); VOLUMEN FLOTANTE (); AREA FLOTANTE ();};

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


    • Desarrollo con Bases de Datos OO ODMG

    • En la definición anterior, ALTURA, RADIO y ÁREA representan los mensajes que se pueden enviar a un objeto CILINDRO.

    • La Implantación 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 ODMG

    • En este caso, la Altura se almacena como un elemento de los datos, mientras que Volumen se calcula mediante la fórmula apropiada.

    • Observe que la implantación interna de Volumen utiliza solicitudes para obtener Altura y Radio.

    • Sin embargo, el aspecto más importante es la sencillez y uniformidad que experimentan los usuarios de CILINDRO.


    • Desarrollo con Bases de Datos OO ODMG

    • Sólo necesitan conocer la forma de enviar una solicitud y las solicitudes disponibles.

    • TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO.

    • Las BDOO se pueden construir mediante alguno de los tres enfoques siguientes:

    • El Primero.- se puede utilizar el código actual altamente complejo de los sistemas de administración de las BD, de modo que una BDOO se implante más rápido sin tener que iniciar de cero.


    • TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO. ODMG

    • El Primero…

    • Las Técnicas OO se pueden utilizar como medios para el diseño 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 CONSTRUCCIÓN DE BDOO. ODMG

    • El Segundo: Considera a la BDOO como una extensión de la tecnología de las BD por Relación.

    • De este modo, las herramientas, técnicas, y vasta experiencia de la tecnología por relación se utilizan para construir un nuevo SMBD.

    • Se pueden añadir apuntadores a las tablas de relación para ligarlas con objetos binarios de gran tamaño.

    • La BD también debe proporcionar a las aplicaciones clientes, un acceso aleatorio y por partes a grandes objetos, con el fin de que sólo sea necesario recuperar a través de la red la parte solicitada de los datos.


    • TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO. ODMG

    • El Tercero: reflexiona sobre la arquitectura de los SBD y produce una nueva arquitectura optimizada, que cumple las necesidades de la tecnología OO.

    • Las compañías como Versant, Objectivity, Itasca, etc., utilizan este enfoque y afirman que la tecnología de relación es un subconjunto de una capacidad más general.

    • Además mencionan que las BDOO son aproximadamente dos veces más rápidas que las bases de datos por relación, para almacenar y recuperar la información compleja.


    • TRES ENFOQUES DE CONSTRUCCIÓN DE BDOO. ODMG

    • El Tercero…

    • Por lo tanto, son esenciales en aplicaciones como CAD y permitirían que un depósito 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 computación distribuida.

    • Cualquier petición del Cliente, el Servidor la procesa. Los servidores pueden cooperar en una BD distribuida de Versant.

    • Las BD pueden estar levantadas como un sistema m-Cliente/n-Servidor.


    • IMPACTO DE LA ORIENTACIÓN A OBJETOS EN LA INGENIERÍA DEL SOFTWARE.

    • En las BDOO, la organización "Grupo de Administración de Datos Objeto (ODMG)" representa el 100% de las BDOO industriales.

    • Y ha establecido un estándar de BD equivalente a SQL:

      • ODL.- Lenguaje de Definición de Datos Objetos, y

      • OQL.- Lenguaje de Consulta a Objetos.

    • Respecto a las relacionales, todas (Oracle, Informix, etc.) están añadiendo en mayor o menor grado algunos aspectos de la OO.


    • IMPACTO DE LA ORIENTACIÓN A OBJETOS EN LA INGENIERÍA DEL SOFTWARE.

    • ANSI (Instituto Nacional Americano de Estándar), 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 estándar para que sirva de base para un nuevo SQL.

    • Con lo que sólo habría un único estándar de BD.


    • IMPACTO DE LA ORIENTACIÓN A OBJETOS EN LA INGENIERÍA DEL SOFTWARE.

    • El grupo ODMG (Grupo Manejador de Datos Objeto) nació de un grupo más grande, llamado "Grupo Manejador de Objetos (OMG)“.

    • Este grupo está definiendo un estándar universal por objetos.

    • Este estándar permitirá que un objeto sea programado en cualquier lenguaje y sistema operativo.

    • Facilitando enormemente el desarrollo de sistemas abiertos cliente-servidor.


    • VENTAJAS EN BDOO SOFTWARE.

    • 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 información de clientes y sus compras, no tiene un campo para registrar quién proporcionó la referencia.

      • O de qué manera fue dicho contacto.

      • O si debe compensarse con una comisión, sería necesario reestructurar la BD para añadir este tipo de modificaciones o de datos.


    • VENTAJAS EN BDOO SOFTWARE.

    • Por el contrario, en una BDOO, el usuario puede añadir una "subclase" de la clase de clientes para manejar las modificaciones que representan los clientes por referencia.

    • La subclase heredará todos los atributos, características de la definición original, además se especializará en especificar los nuevos campos que se requieren así como los métodos para manipular solamente esos campos.

    • Naturalmente se generan los espacios para almacenar la información adicional de los nuevos campos.


    • VENTAJAS EN BDOO SOFTWARE.

    • 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 rápida y ágilmente.

    • La estructura de la base de datos está dada por referencias (o apuntadores lógicos) entre objetos, los famosos IDOs.


    • POSIBLES DESVENTAJAS SOFTWARE.

    • Al considerar la adopción de la tecnología 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 línea de producción sustantiva.

    • El segundo problema es la falta de estándares en la industria OO.


    • POSIBLES DESVENTAJAS SOFTWARE.

    • Sin embargo, el "Grupo Manejador de Objetos" (OMG), es una organización Internacional de proveedores de sistemas de información y usuarios dedicada a promover estándares para el desarrollo de aplicaciones y sistemas OO en ambientes de cómputo en red.

    • La implantación de una nueva tecnología requiere que los usuarios iniciales acepten cierto riesgo.

    • Aquellos que esperan resultados a corto plazo y con un costo reducido quedarán desilusionados.


    • POSIBLES DESVENTAJAS SOFTWARE.

    • Sin embargo, para aquellos usuarios que planean:

      • A un futuro intermedio con una visión tecnológica avanzada.

      • El uso de tecnología avanzada o de punta.

      • Y el uso de Tecnología OO.

    • Paulatinamente compensarán todos los riesgos.


    • RENDIMIENTO SOFTWARE.

    • Las BDOO permiten que los objetos hagan referencia directamente a otros mediante apuntadores suaves.

    • Esto hace que las BDOO pasen más rápido del objeto A al objeto B que las BDR.

    • Las cuales deben utilizar comandos JOIN para lograr ésto.

    • Incluso el JOIN optimizado es más lento que un recorrido de los objetos.


    • RENDIMIENTO SOFTWARE.

    • Así, incluso sin alguna afinación especial, una BDOO es en general más rápida en esta mecánica de caza-apuntadores.

    • Las BDOO hacen que el agrupamiento sea más eficiente.

    • La mayoría 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 recuperación de los datos relacionados, puesto que todos los datos se leen con una lectura de disco, en vez de varias.


    • RENDIMIENTO SOFTWARE.

    • Sin embargo, en una BDR, los objetos de la implantación 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 automático en una BDOO.

    • Además, el agrupamiento de los datos relacionados, como todas las subpartes de un ensamble, puede afectar radicalmente el rendimiento general de una aplicación.


    • RENDIMIENTO SOFTWARE.

    • Esto es relativamente directo en una BDOO, puesto que representa el primer nivel de agrupamiento.

    • Por el contrario, el agrupamiento físico 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 SOFTWARE.

    • Un SMBDOO debe satisfacer dos criterios:

      • Ser un Sistema OO.

      • Y ser un Sistema de Administración de BD.

    • El primer criterio se traduce en ocho características generales: Abstracción, encapsulación, modularidad, jerarquía, control de tipos, concurrencia, persistencia y genericidad.

    • El segundo criterio se traduce en cinco características principales: Persistencia, concurrencia, recuperación ante fallos del sistema, gestión del almacenamiento secundario y facilidad de consultas.


    Características de SGBDOO SOFTWARE.

    Primer Criterio. Con 8 características.

    Segundo Criterio. Con 5 características.


    • RENDIMIENTO SOFTWARE.

    • Como se puede observar la Persistencia, al igual que la Concurrencia, son características del SMBDOO heredadas tanto del SMBD como del Modelo de Objetos.

    • La Persistencia en el caso del SMBD hace referencia a la conservación de los datos después de la finalización del proceso que los creó.

    • En el caso del Modelo de Objetos, se refiere no sólo a la conservación del estado de un objeto, si no también a la conservación de la clase, que debe trascender a cualquier programa individual.


    • RENDIMIENTO SOFTWARE.

    • 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 múltiples 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 SOFTWARE.

    • Persistencia.- Es la capacidad que tiene el programador para que sus datos se conserven al finalizar la ejecución 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 interacción entre las transacciones concurrentes, para evitar que se destruya la consistencia de la BD.


    • RENDIMIENTO SOFTWARE.

    • Recuperación.- Proporcionar como mínimo el mismo nivel de recuperación 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.

    • Gestión del almacenamiento secundario.- Es soportada por un conjunto de mecanismos que no son visibles al usuario.

    • Tales como gestión de índices, agrupación de datos, selección del camino de acceso, optimización de consultas, etc.


    • RENDIMIENTO SOFTWARE.

    • Gestión 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.

    • Creándose de esta forma una independencia entre los Niveles Lógicos y Físicos del sistema.

    • Facilidad de Consultas.-

    • Permitir al usuario hacer cuestiones sencillas a la BD. Este tipo de consultas tienen como misión proporcionar la información solicitada por el usuario de una forma correcta y rápida.


    • INTEGRIDAD SOFTWARE.

    • 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 código procedural (por métodos o programas de aplicación).

    • Niveles:

      • Ningún soporte del sistema.

      • Validación de referencias.

      • Mantenimiento del sistema

      • “Semántica personalizada”


    • CONTROVERSIA SOFTWARE.

    • Las BD de Objetos surgieron por la necesidad que tenían los programadores de aplicaciones OO, de conservar sus objetos en una memoria persistente.

    • Esa memoria persistente podría considerarse una BD, pero el punto importante es que en realidad fue especificada por la aplicación.

    • No era una BD compartida, de propósito general que pretendiera ser adecuada para aplicaciones que no hubieran sido previstas al momento de definir la BD.


    • CONTROVERSIA SOFTWARE.

    • Muchas características que son esenciales en los SBD, sencillamente no fueron requerimiento en el mundo de los objetos, al menos no originalmente.

    • Se podría 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 Construcción de SMBD. Cuando es instalado por primero vez, NO está disponible para su uso inmediato. Primero debe ser adaptado por técnicos capaces y experimentados.


    • CONTROVERSIA SOFTWARE.

      • Estos técnicos son quienes también definen las clases y métodos necesarios para la BD. Y sólo cuando esta actividad de adaptación 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á específico de una aplicación en particular.

      • Podría por ejemplo, ser adaptado para aplicaciones CAD/CAM, pero esencialmente inútil para otro tipo de aplicaciones (médicas, documentos, etc).

      • En otras palabras, todavía no sería un SMBD de propósito general, como lo son los SMBDRs.


    • CONTROVERSIA SOFTWARE.

    • 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 además 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 físicamente.


    • CONTROVERSIA SOFTWARE.

    • Por lo tanto no impone límites sobre cuáles estructuras de datos son permitidas en el nivel físico.

    • El único requerimiento es que cualquier estructura que de hecho esté guardada físicamente, debe ser transformada a relaciones en el nivel lógico y por lo tanto, debe ser oculta ante el usuario.

    • Los sistemas relacionales hacen una distinción clara entre lo lógico y lo físico (el modelo de datos contra la implementación).


    • CONTROVERSIA SOFTWARE.

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



    • SMBD O/R SOFTWARE.

    • Recientemente varios fabricantes han lanzado productos SMBD “de Objetos/Relacionales”.

    • También 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 SOFTWARE.

    • La idea general es que los productos deben soportar posibilidades de objetos y relacionales.

    • Los productos en cuestión son intentos de un “acercamiento” entre las dos tecnologías.

    • 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 SOFTWARE.

    • Es decir, sólo se necesita implementarlo, completa y adecuadamente.

    • Por lo tanto, se cree que un sistema relacional que soporte adecuadamente los dominios, sería capaz de manejar todos estos tipos de datos “problemáticos”, que según se dice, sólo pueden manejar los sistemas de objetos.

    • También se cree que un sistema de “objetos/relacional” verdadero, sería un sistema relacional verdadero.


    • SMBD O/R SOFTWARE.

    • Los fabricantes de SMBD deberían ser motivados para que hicieran lo que, de hecho, están tratando de hacer.

    • Extender sus sistemas para que incluyan el soporte apropiado de tipos o dominios.

    • Una implicación importante del soporte apropiado para los tipos de datos, es que se permite que los fabricantes de otras compañías construyan y vendan paquetes de “tipos de datos” separados, que pueden ser incorporados al SMBD.


    • SMBD O/R SOFTWARE.

    • Estos paquetes incluyen soporte para el manejo de Texto Sofisticado, el procesamiento de Series de Tiempo Financieras, el Análisis de Datos Geoespaciales (cartográficos), etc.

    • A dichos paquetes se les conoce de diversas formas:

      • Navajas de Datos (Informix).

      • Cartuchos de Datos (Oracle)

      • Extensores Relacionales (IBM)


    • SMBD O/R SOFTWARE.

    • Sin embargo, la incorporación de un nuevo paquete de tipos al sistema es una labor no trivial.

    • Y la capacidad de hacerlo tiene implicaciones importantes para el diseño y la estructura del propio SMBD.

    • Por ejemplo, considere lo que pasaría si alguna consulta incluyera referencia hacia datos de algún tipo definido por el usuario, o invocaciones a algún operador definido por el usuario.


    • SMBD O/R SOFTWARE.

    • Consideraciones para el sistema:

      • El compilador del lenguaje de consultas debe ser capaz de analizar sintácticamente 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 físico tiene que soportar las estructuras de almacenamiento nuevas.


    • SMBD O/R SOFTWARE.

    • El efecto de lo anterior es que el sistema necesita ser extensible, y en varios niveles:

    • Análisis sintáctico y verificación 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 análisis y verificación de tipos por el compilador del lenguaje de consultas.

      • Se debe rediseñar el catálogo del sistema (o al menos extendido).

      • El compilador mismo necesita ser reescrito para acceder al catálogo a fin de obtener la información necesaria.


    • SMBD O/R SOFTWARE.

    • Optimización.

      • Transformación de expresiones (reescritua de consultas). Debe ser dinámico, y no preestablecido.

      • Selectividad. Porcentaje de tuplas que la hacen verdadera. Esta selectividad debe ser “integrado” en el optimizador.

      • Fórmulas de Costo. El optimizador necesita saber cuánto cuesta ejecutar un operador definido por el usuario.

      • Estructuras de Almacenamiento y Métodos de Acceso. El optimizador debe conocer esta información.


    • SMBD O/R SOFTWARE.

    • En resumen, Stonebraker está argumentado que los “sistemas de Objetos/Relacionales están en el futuro de todos”.


    Est ndares

    ESTÁNDARES SOFTWARE


    • PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-93 SOFTWARE.

    • La mayor limitación de las BDOO es la carencia de un estándar.

    • 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 gestión que soporta un lenguaje de BDOO, con una sintaxis similar a un lenguaje de programación, también OO como puede ser C++ o Smalltalk.


    • PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-93 SOFTWARE.

    • El Lenguaje de BD se especifica mediante:

      • Un Lenguaje de Definición de Datos (ODL).

      • Un Lenguaje de Manipulación 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 aplicación completa.


    • PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-93 SOFTWARE.

    • En definitiva, ODMG-93 intenta definir un SMBDOO que integre las capacidades de las BD con las capacidades de los lenguajes de programación.

    • De forma que los objetos de la BD aparezcan como objetos del lenguaje de programación.

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


    • PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-93 SOFTWARE.

    • El SMBDOO extiende el lenguaje con persistencia, concurrencia, recuperación de datos, consultas asociativas, etc.

    • Lenguaje ODL

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


    • LENGUAJE ODL SOFTWARE

    • Este ODL no es un lenguaje de programación completo, define las propiedades y los prototipos de las operaciones de los tipos, pero no los métodos que implementan esas operaciones.

    • El ODL intenta definir tipos que puedan implementarse en diversos lenguajes de programación.

    • No está por tanto ligado a la sintaxis concreta de un lenguaje de programación particular.


    • LENGUAJE ODL SOFTWARE

    • 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 extensión de la IDL (Interface Definition Language) desarrollado por OMG como parte de CORBA (Common Object Request Broker Architecture).


    • LENGUAJE OML. SOFTWARE

    • El Lenguaje de Manipulación es empleado para la elaboración de programas que permitan crear, modificar y borrar datos que constituyen la BD.

    • ODMG-93 sugiere que este lenguaje sea la extensión de un lenguaje de programación, de forma que se pueden realizar entre otras las siguientes operaciones sobre la base de datos: Creación, Borrado, Modificación e Identificación de un Objeto.


    • LENGUAJE OQL. SOFTWARE

    • El Lenguaje de Consulta propuesto por ODMG-93, presenta las siguientes características:

      • No es computacionalmente completo. Sin embargo, las consultas pueden invocar métodos, e inversamente los métodos escritos en cualquier lenguaje de programación pueden incluir consultas.

      • Tiene una sintaxis abstracta.

      • Su semántica formal puede definirse fácilmente.

      • Proporciona un acceso declarativo a los objetos.


    • LENGUAJE OQL. SOFTWARE

      • Se basa en el modelo de objetos de ODMG-93.

      • Tiene una sintaxis concreta al estilo SQL, pero puede cambiarse con facilidad.

      • Puede optimizarse fácilmente.

      • No proporciona operadores explícitos para la modificación, 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 utilización con otros constructores de colecciones.


    • LENGUAJE OQL. SOFTWARE

    • Existen dos posibilidades para asociar un sublenguaje de consulta a un lenguaje de programación: fuerte y débilmente.

    • El primer caso, Lenguaje de Programación Fuerte, consiste en una extensión de la gramática del lenguaje asociado.

    • En el segundo caso, Lenguaje de Programación Débil, las funciones query tienen unos argumentos String que contienen las preguntas.


    LENGUAJE OQL. SOFTWARE

    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 O SOFTWAREO.

    • Para poder utilizar a los Lenguajes OO en un sistema de BD, existen dos alternativas:

      • Se pueden utilizar como herramientas de diseño y codificación. Por ej. Una interfaz en una BDR.

      • Extender el lenguaje de tratamiento de datos como SQL, añadiendo tipos complejos y la POO. Los sistemas que proporcionan extensiones de este tipo a sistemas relacionales, se denominan Relaciones Orientadas a Objetos (ROO).

      • Otra opción es tomar un lenguaje de POO y extenderlo para que trabaje con las BD. Estos lenguajes se denomiann Lenguajes de Programación Persistente.


    • CONCLUSIONES. SOFTWARE

    • En conclusión sabemos que las BDOO representan el siguiente paso en la evolución de las BD, para soportar el Análisis, Diseño y Programación 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 análisis, diseño, programación, definición y acceso a la BD.


    • CONCLUSIONES. SOFTWARE

    • Esto reduce el problema del operador de traducción entre los diferentes modelos a través 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 métodos.

    • Las BDOO ofrecen un mucho mejor rendimiento de la máquina que las BDR, para aplicaciones o clases con estructuras complejas de datos.


    • CONCLUSIONES. SOFTWARE

    • Sin embargo, las BDOO coexistirán con las BDR durante los próximos años.

    • Puesto que a menudo se utilizará un modelo por relación como una forma de estructura de datos, dentro de una BDOO.

    • Podemos decir que en conclusión, con el caso de Oracle, que ha aumentado la demanda de una representación de objetos complejos en las actuales aplicaciones convencionales.


    • Principles Of Distributed Database Systems 2ª. Ed. SOFTWARE

      M. Tamer Ozsu y Patrick Valduriez

      Prentice Hall

    • Procesamiento de Bases de Datos 8a. Ed.

      David M. Kroenke

      Pearson.

    • Introducción a los Sistemas de Bases de Datos 7a. Ed.

      C. J. Date

      Prentice Hall.

    • http://www.cs.cinvestav.mx/BDChapa/Beto/Blanco.htm

    • http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema7.htm



    ad