UNIVERSIDAD LATINA

1. UNIVERSIDAD LATINA BASES DE DATOS MODELO ORIENTADO A OBJETOS

2. Retos actuales de los sistemas manejadores de bases de datos MODELOS ORIENTADOS A OBJETOS • Surgió en los años 90s. • Unificación de técnicas = UML. • “el MOO es la construcción de modelos de un sistema por medio de la identificación y especificación de un conjunto de objetos relacionados, que se comportan y colaboran entre sí de acuerdo a los requerimientos establecidos para el sistema de objetos.”

3. Tendencias actuales en la tecnología de bases de datos Mundo real Análisis y diseño Modelo Código Programa De BD

4. Orientación a objetos • Se emplean clases para definir las entidades • Clase -> Define estructura y compotamiento de objetos • Esquema OO -> Conjunto de clases. • Modelo -> Aspecto de la realidad y se construye de modo que nos ayude a comprender a esta.

5. DIMENCIONES ORIENTADAS A OBJETOS • Dimensión estructural de los objetos -> Propiedades estáticas • Dimensión dinámica del comportamiento -> Propiedades activas, comportamiento individual y colaboración entre objetos. • Dimensión funcional de los requerimientos -> Propiedades de transformación del sistema Dimensiones que describen un sistema de objetos

6. ACTIVIDADES MODELOS ORIENTADOS A OBJETOS • Las actividades que se deben seguir para llevar un MOO son: • Identificar clases, objetos y atributos • Asociar estáticamente los objetos • Describir el comportamiento de los objetos • Definir la colaboración del comportamiento de los objetos • Organizar las clases en jerarquías de herencia • Agregar y/o particionar las clases por niveles de abstracción

7. PERSISTENCIA • Se entiende por persistencia (en programación orientada a objetos) como el mecanismo o la acción de preservar la información de un objeto de forma permanente (guardar), pero a su vez también se refiere a poder recuperar la información del mismo (leer) para que pueda ser nuevamente utilizada. • En el caso de persistencia de objetos la información que persiste en la mayoría de los casos son los valores que contienen los atributos en ese momento, no necesariamente la funcionalidad que proveen sus métodos.

8. ANTECEDENTES • - Primera generacion.- B-Base (1986), GemStone(1987). Son considerados como lenguajes orientados a objetos con persistencia. • - Segunda generación.- Ontos(1989), Object Design, Objetivity, etc. La caracteristica principal es que utilizan una arquitectura cliente-servidor. • - Tercera generación. Itasca(1990), etc. Son verdaderos SMBDOO, con motores que gestionan objetos y lenguajes como ODL, OML, OQL.

9. DEFINICIONES • - Bases de datos orientadas a objetos: Es una colección de objetos en los que sus estados, comportamientos y relaciones son definidas de acuerdo con un modelo de datos orientado a objetos. • - Sistema Manejador de Bases de Datos Orientado a Objetos: Es un sistema de Base de Datos que permite la definición y manipulación de una Base de Datos Orientada a Objetos.

10. CARACTERISTICAS • Del SMBDOO.- Persistencia, Concurrencia, Recuperación, Almacenamiento Secundario, Consultas. • De la orientación a objetos.- Manejo de complejos objetos, Indentidad, Encapsulación, Herencia, Tipos o Clases, Sobrecarga, Extensibilidad, Completitud Computacional..

11. Estándar ODMG • - ODMG (Object Data Management Group) • - Lenguajes de Especificacion de Objetos (ODL) • - Lenguajes de Manipulación de Objetos (OML) • - Lenguajes de Consulta (OQL) • Bindings para lenguajes de programación OO como C++, Smalltalk o Java • un binding es una adaptación de una biblioteca para ser usada en un lenguaje de programación distinto de aquél en el que ha sido escrita

12. LENGUAJES OO • 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.

13. La POO se 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).

14. Los objetos estructurados se agrupan en clases. • 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.

15. PRINCIPIOS DE ORIENTACIÓN 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 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.

16. PRINCIPIOS DE ORIENTACIÓN 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 automática. • A diferencia de las BD relacionales donde un valor de dato único, se genera de manera externa al sistema.

17. PRINCIPIOS DE ORIENTACIÓN A OBJETOS • 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.

18. Las clasesson una colección de objetos con propiedades similares, compartimiento común, relaciones comunes a otras clases. • La instanciaes 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.

19. La superclasees 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.

20. BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) • 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.

21. BASES DE DATOS ORIENTADAS A OBJETOS (BDOO) • 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.

22. ESTRUCTURA DE OBJETOS • 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.

23. La capacidad de modificar la definición de un objeto sin afectar al resto del sistema, está considerada como una de las mayores ventajas del modelo de POO. • 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.

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

25. Por ejemplo: Tomemos como referencia la entidad Alumno y la entidad Maestro. • Donde los atributos considerados para cada uno, son en Alumno: • Nombre • Dirección • Teléfono • Especialidad • Semestre • Grupo

26. Maestro: • 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.

27. Quedando por separado en Alumno: • Especialidad • Semestre • Grupo. • Y en Maestro: • Número Económico • Plaza • RFC.

28. CLASE PERSONA Nombre Dirección Teléfono • HERENCIA • SUPERCLASE • SUBCLASES • Número • Económico • Plaza • RFC • Especialidad • Semestre • Grupo CLASE ALUMNO CLASE MAESTRO

29. ESTÁNDARES

30. PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-93. • La mayor limitación de las BDOO es la carencia de un estándar. • ODMG-93 (Object-OrientedDatabase 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.

31. PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-93. • 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.

32. PRIMER INTENTO DE ESTANDARIZACIÓN: ODMG-93. • 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.

33. LENGUAJE ODL • 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.

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

35. LENGUAJE OML. • 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.

36. LENGUAJE OQL. • 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.

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

38. LENGUAJE OQL. • 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.

39. 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);

40. LENGUAJE OO. • 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.

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

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

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