BASES DE DATOS ORIENTADAS A OBJETOS

1. BASES DE DATOS ORIENTADAS A OBJETOS Introducción a las BDOO Administración de Bases de Datos Roberto Piris

2. Contenidos • Introducción • Repaso de conceptos de OO • Identidad de objeto • Estructura de objeto • Encapsulación de operaciones, métodos y persistencia. • Jerarquías de tipo y herencia • Objetos complejos • Otros conceptos de OO • Polimorfismo • Herencia múltiple y herencia selectiva • Versiones y configuraciones • Conclusiones

3. Introducción • Los SBD tradicionales muestran carencias (en diseños de ingeniería, investigaciones científicas...) • Se necesitan estructuras más complejas, transacciones de mayor duración, nuevos tipos de datos (imágenes, etc.) • Poder especificar tanto la estructura como las operaciones que se le pueden aplicar

4. Introducción • Cada vez se utilizan más los LPOO • Los fabricantes ya empiezan a incluir características de OO en sus productos → SGBD objeto-relacionales o relacionales extendidos • Sistemas experimentales: ORION, OPENOODB, ODE... • Comerciales: GEMSTONE/OPAL, ONTOS, VERSANT...

5. Introducción • Necesidad de un estándar, cuyo establecimiento lleva años • Un consorcio de vendedores y usuarios (ODMG) propusieron el ODMG-93, revisado dando lugar al ODMG 2.0

6. Repaso de conceptos de OO • El término tiene su origen en los lenguajes de programación OO, cuyas raíces están en el lenguaje SIMULA (1960). • SMALLTALK fue uno de los primeros LP que incorporaron conceptos de OO, como la herencia y el paso de mensajes. • Un LPOO puro, es aquel que ha sido específicamente diseñado para ser OO. Uno híbrido, es un LP tradicional que ha incorporado algunos conceptos (Ejemplo: C++). • Un objeto consta de dos componentes: el estado (el valor) y el comportamiento (las operaciones). • Únicamente existen durante la ejecución del programa (objetos transitorios).

7. Repaso de conceptos de OO • Una BDOO puede alargar la existencia de estos objetos, haciéndolos persistentes. • Las BDOO almacenan objetos persistentes de forma permanente en un almacenamiento secundario, y permite la compartición de los objetos con otros programas y aplicaciones. • Uno de los objetivos de una BDOO es mantener cierta correspondencia entre los objetos de la BD y los del mundo real. • En las BDOO, los objetos pueden tener una cierta complejidad, al contener toda la información necesaria para describir el objeto. En sistemas tradicionales, la información se encuentra dispersa en múltiples tablas. Se definen las estructuras y las operaciones → se favorece la encapsulación.

8. Repaso de conceptos de OO • Una operación se define en dos partes: signatura o interfaz, y método o cuerpo. • Otro concepto clave son la jerarquía de tipos y la herencia. • Un problema inicial de las BDOO era cómo representar las relaciones. Se solucionó introduciendo los identificadores de los objetos referenciados en el propio objeto. • Algunos sistemas proporcionan medios para manejar versiones, y permiten la evolución del esquema (no es obligatorio). • Otra característica es el polimorfismo, que es la capacidad de aplicar diferentes objetos en una operación.

9. Identidad de objeto • Se genera un identificador (OID) único a cada objeto, que no es visible al usuario externo. • El OID debe ser inmutable. También sería deseable que cada OID se usara una sola vez, y que no dependiera de ninguno de sus atributos (algunos utilizan la dirección física del objeto). • Algunos modelos de datos antiguos, exigían que todo fuese un objeto, manejando así muchos OIDs → muchos sistemas permiten la utilización tanto de objetos como de valores.

10. Estructura de objeto • Los objetos pueden construirse a partir de otros más simples. • Un objeto puede representarse como una tupla (i, c, v), con i=identificador, c=constructor de tipo, v=estado del objeto. • Algunos constructores: átomo, tupla, conjunto, lista, bolsa y array. • El estado de un objeto se interpreta a partir de su constructor. • Hay dos tipos de definiciones para una comparación entre objetos: iguales vs idénticos.

11. Encapsulación de operaciones, métodos y persistencia • El concepto de encapsulación está relacionado con los conceptos de tipos de datos abstractos y de ocultación de la información. • Especificación del comportamiento del objeto mediante operaciones de clase • La idea es definir el comportamiento de un objeto basado en las operaciones que se le pueden aplicar externamente. • La estructura interna queda oculta y sólo se puede acceder mediante ciertas operaciones predefinidas. • Los usuarios sólo perciben la interfaz del objeto, donde se definen los nombres y los argumentos de las operaciones. • Se define signatura a la interfaz, y la implementación se conoce como método.

12. Encapsulación de operaciones, métodos y persistencia • En las aplicaciones de BD, el requisito de que todos los objetos deben quedar encapsulados es demasiado estricto. Esto se relaja diferenciando entre atributos visibles y atributos ocultos. • Los operadores externos o un lenguaje de consulta (p.e. SQL) pueden tener acceso directo a los atributos visibles. • Casi todos los SGBD emplean algún lenguaje para tener acceso a los atributos visibles. El OQL se propone como lenguaje de consulta estándar para BDOO. • En la mayoría de los casos, las operaciones que actualizan el estado de un objeto están encapsuladas, lo que define la semántica de actualización de los objetos. • Cada tipo de objeto tiene definidas las restricciones de integridad programadas en los métodos que crean, destruyen y modifican los objetos. Más recientemente, el ODL para el estándar ODMG 2.0 permite la especificación de algunas restricciones como claves y relaciones inversas (integridad referencial)

13. Encapsulación de operaciones, métodos y persistencia • El término clase se utiliza para referirse a una definición de tipo de objetos, junto con las definiciones de las operaciones para ese tipo. • Para cada clase se declaran varias operaciones, y la signatura de cada operación se incluye en la definición de la clase. • Para cada operación se debe definir un método (implementación) en otro lugar. • Las operaciones más habituales incluyen el constructor de objeto, el destructor y varias operaciones para modificar el objeto. Otras operaciones nos permitirán recuperar información acerca del objeto.

14. Encapsulación de operaciones, métodos y persistencia define class Empleado type tuple ( nombre: string; inic: char; apellido: string; fechanacimiento: Fecha; dirección: string; sexo: char; salario: float; supervisor: Empleado; dept: Departamento; ); operations edad: integer; crear_emp: Empleado; borrar_emp: boolean; end Empleado;

15. Encapsulación de operaciones, métodos y persistencia define class Departamento type tuple (nombred: string; númerod: integer; jf: tuple (jefe: Empleado; fechainicio: Fecha; ); localizaciones: set (string); empleados: set (Empleado); proyectos: set (Proyecto); ); operations num_de_emps: integer; crear_dept: Departamento; borrar_dept: boolean; asignar_emp(e: Empleado): boolean; (* añade un empleado al departamento *) quitar_emp(e: Empleado): bolean; (* elimina un empleado del departamento *) end Departamento;

16. Encapsulación de operaciones, métodos y persistencia • Una operación se aplica mediante la notación de punto: Departamento d; d.num_de_emps devolvería el número de empleados del departamento d Empleado e; e.edad nos daría la edad del empleado e

17. Encapsulación de operaciones, métodos y persistencia • Especificación de la persistencia de objetos a través del nombramiento y la alcanzabilidad • Lo normal es que los objetos sean creados por programas en ejecución. • No todos los objetos se almacenan el la BD. • Los objetos que sólo existen durante la ejecución del programa se denominan transitorios. • A los objetos que se almacenan se les llama persistentes. • Los mecanismos habituales para hacer persistente un objeto son el nombramiento y la alcanzabilidad.

18. Encapsulación de operaciones, métodos y persistencia • El nombramiento implica dar un nombre persistente y único al objeto que va a ser almacenado, mediante el cual se puede volver a recuperar. • El nombre se puede asignar por una sentencia o una operación en un programa. • Los objetos persistentes nombrados se pueden utilizar como punto de entrada a la BD. • Problema: ¿qué pasa si tenemos miles de objetos en la BD? → necesitamos nombres únicos para cada uno → buscamos otra solución, la alcanzabilidad.

19. Encapsulación de operaciones, métodos y persistencia • La alcanzabilidad funciona haciendo que un objeto sea alcanzable a través de otro que ya lo es. • Se dice que un objeto B es alcanzable desde un objeto a si una secuencia de referencias del gráfico del objeto conduce del objeto A al objeto B.

20. Encapsulación de operaciones, métodos y persistencia define class ConjuntoDepartamento type set (Departamento); operations añadir_dept (d: Departamento): boolean; (* añade un departamento al objeto ConjuntoDepartamento *) quitar_dept (d: Departamento): bolean; (* elimina un departamento del objeto ConjuntoDepartamento *) crear_conjunto_dept: ConjuntoDepartamento; borrar_conjunto_dept: bolean; end ConjuntoDepartamento; persistent name TodosDepartamentos: ConjuntoDepartamento; (* TodosDepartamentos es un objeto nombrado persistente de tipo ConjuntoDepartamento *) d:= crear_dept; (* crear un nuevo objeto Departamento en la variable d *) b:= TodosDepartamentos.añadir_dept (d); (* hace a de persistente añadiéndolo al conjunto persistente TodosDepartamento *)

21. Encapsulación de operaciones, métodos y persistencia • En un modelo típico de BD, se da por hecho que todos los objetos son persistentes. Así pues, cuando se define un tipo de entidad o una clase como Empleado en el modelo EER, representa tanto la declaración de tipo Empleado como un conjunto persistente de todos los objetos Empleado. En el enfoque OO, una declaración de clase Empleado sólo especifica el tipo y las operaciones de una clase de objetos. El usuario debe definir por separado un objeto persistente de tipo conjunto o lista cuyo valor sea la colección de referencias a todos los objetos Empleado persistentes.

22. Jerarquías de tipo y herencia • En gran parte de las aplicaciones de BD hay muchísimos objetos, por lo que sería deseable poderlos clasificar. • Además, el sistema debería poder permitir la definición de nuevos tipos basados en tipos predefinidos, dando origen a una jerarquía. • Para definir un tipo se le asigna un nombre y una serie de atributos y operaciones para el mismo. En algunos casos, tanto atributos como operaciones se denominan funciones, porque consideran a los atributos como operaciones con cero argumentos. NOMBRE_DE_TIPO: función1, función2, ...

23. Jerarquías de tipo y herencia PERSONA: Nombre, Dirección, FechaNac, Edad, NSS • En el tipo PERSONA, Nombre, Dirección, FechaNac y NSS pueden implementarse como atributos almacenados, mientras que la edad puede obtenerse a partir de FechaNac y la fecha actual.

24. Jerarquías de tipo y herencia • Cuando el diseñador o el usuario desean crear un nuevo tipo, similar a uno ya existente, resulta útil el concepto de subtipo. Éste hereda todas las funciones del tipo predefinido, llamado supertipo. EMPLEADO: Nombre, Dirección, Fechanac, Edad, NSS, Salario, FechaAlta, Antigüedad ESTUDIANTE: Nombre, Dirección, Fechanac, Edad, NSS, Titulación, NM • ESTUDIANTE y EMPLEADO heredarían todas las funciones de Persona, y sólo implementarían aquellas que les sean propias

25. Jerarquías de tipo y herencia • Definir un tipo implica definir todas sus funciones e implementarlas. Cuando definimos un subtipo, se heredan todas las funciones del supertipo, y sólo tenemos que implementar las nuevas, reduciendo así el trabajo. EMPLEADO subtype-of PERSONA: Salario, FechaAlta, Antigüedad ESTUDIANTE subtype-of PERSONA: Titulación, NM • Gracias a este mecanismo, es posible definir una jerarquía supertipo/subtipo

26. Jerarquías de tipo y herencia • Restricciones sobre extensiones correspondientes a una jerarquía de tipos: • En las aplicaciones de BD es habitual que cada tipo o subtipo tenga asociada una extensión, que contenga la colección de todos los objetos persistentes de ese tipo o subtipo. • En ese caso, se da la restricción que todos los objetos que pertenezcan a un subtipo también deben ser miembros de la extensión que corresponda a su supertipo. • En algunos sistemas existe un tipo predefinido (RAIZ o OBJETO) cuya extensión contiene a todos los objetos del sistema. Entonces se lleva a cabo una clasificación, asignando los objetos a subtipos adicionales, creando una jerarquía. En el modelo ODMG el usuario puede especificar una extensión para cada tipo dependiendo de la aplicación. • En la mayor parte de sistemas se hace distinción entre colecciones y objetos persistentes y transitorios.

27. Objetos complejos • Una de las motivaciones para desarrollar sistemas OO, fue la de poder representar objetos complejos. Los hay de dos tipos: estructurados y no estructurados. • Objeto complejo estructurado: constituido por componentes, se define aplicando recurrentemente los constructores de tipos disponibles. • Objeto complejo no estructurado: casi siempre es un tipo de datos que requiere una gran cantidad de almacenamiento, como un tipo de datos que representa a una imagen.

28. Objetos complejos • Objetos complejos no estructurados y extensibilidad de tipos: • Ejemplos representativos: imágenes de mapa de bits y cadenas de texto largas. También se conocen como objetos binarios extensos, o BLOB. • Son no estructurados en el sentido de que el SGBD no sabe qué estructura tienen. Sólo la aplicación que los usa sabe cómo interpretarlos. • Se consideran complejos porque necesitan un área de almacenamiento sustancial, y no forman parte de los tipos estándar que suelen ofrecer los SGBD. • Como el tamaño es grande, el SGBD podría obtener un trozo y pasárselo al programa antes de obtener todo el objeto. Se pueden utilizar técnicas de búferes y almacenamiento en cache para recuperar el siguiente fragmento antes de que el programa lo necesite.

29. Objetos complejos • El SGBD no tiene capacidad para procesar directamente las condiciones de selección ni otras basadas en atributos de estos objetos, a menos que la aplicación proporcione el código necesario para realizar la operación. En un SGBDOO esto se consigue mediante un tipo abstracto de datos para los objetos no interpretados y suministrando los métodos necesarios.

30. Objetos complejos • Objetos complejos estructurados: • La estructura de estos objetos se construye mediante la aplicación repetida de los constructores de tipos que proporciona el SGBD. La estructura está definida, y el SGBD la conoce. • Existen dos tipos de semántica para la referencia entre un objeto complejo y sus componentes de cada nivel: • La semántica de propiedad, se aplica cuando los subobjetos de un objeto complejo están encapsulados dentro de éste, y se los considera parte de él. • La semántica de referencia se aplica cuando los componentes de un objeto complejo son ellos mismos objetos independientes, que son referenciados por el objeto complejo.

31. Objetos complejos • Para la semántica de propiedad, los objetos que están encapsulados dentro del objeto complejo no necesitan tener su identificador de objeto (el OID), y sólo acceden a ellos los métodos del objeto que los contiene. Además, desaparecen cuando se elimina el objeto principal. • Para la semántica de referencia, el objeto se considera que está formado por varios objetos independientes, con identidad y métodos propios. Cuando un objeto complejo necesita acceder a los componentes referenciados, debe hacerlo mediante los métodos pertinentes. Además, los componentes no desaparecen al eliminar el objeto complejo. • Los SGBD deben ofrecer opciones de almacenamiento para agrupar los componentes de un objeto en el almacenamiento secundario. En muchos casos la estructura se almacena sin ser interpretada en páginas de disco. Al recuperar una página que incluye un objeto, el SGBDOO puede recuperar el objeto a partir de la información contenida en las páginas de disco, las cuales pueden hacer referencia a otras páginas de disco. Esto se conoce como ensamblaje de objetos complejos.

32. Otros conceptos de orientación a objetos • Polimorfismo (sobrecarga de operadores) • Herencia múltiple y herencia selectiva • Versiones y configuraciones

33. Polimorfismo (sobrecarga de operadores) • Permite enlazar el mismo nombre o símbolo de operador a dos o más implementaciones diferentes del mismo, dependiendo del tipo de objeto al que se le aplique. OBJETO_GEOMÉTRICO: Forma, Área, PuntoReferencia RECTÁNGULO subtype-of OBJETO_GEOMÉTRICO (Forma=’rectángulo’): Ancuha, Altura TRIÁNGULO subtype-of OBJETO_GEOMÉTRICO (Forma=’triángulo’): Lado1, Lado2, Ángulo CÍRCULO subtype-of OBJETO_GEOMÉTRICO (Forma=’círculo’): Radio • La función Área se ha declarado para todos los objetos del tipo OBJETO_GEOMÉTRICO. Sin embargo, la implementación del mismo puede ser diferente para cada uno de los subtipos. • Una posibilidad es la de tener una implementación general, y luego reescribir algoritmos más eficientes para cada subtipo.

34. Polimorfismo (sobrecarga de operadores) • Al darle diferentes implementaciones a una función, estamos haciendo lo que se denomina sobrecarga de operadores. • El SGBDOO debe seleccionar el método apropiado para la función según el subtipo al que se aplique. En sistemas fuertemente tipeados, se puede hacer en tiempo de compilación (ligadura estática o temprana). En los sistemas débilmente tipeados, (o incluso sin tipos) es posible que el tipo no se conozca hasta el momento de la ejecución (ligadura dinámica o tardía).

35. Herencia múltiple y herencia selectiva • La herencia múltiple es una jerarquía de tipos que se da cuando un cierto subtipo es un subtipo de dos (o más) tipos diferentes y por tanto hereda las funciones de ambos supertipos. • Problema: si los dos supertipos tienen funciones con el mismo nombre y distintas implementaciones, ¿cuál se hereda? • La regla general es que si una función se hereda de un supertipo común, se herede sólo una vez. Para el caso de funciones con el mismo nombre y distinta implementación, se puede dejar al usuario la decisión de cuál heredar, utilizar una opción por defecto, o prohibir la herencia múltiple si hay ambigüedad, obligando a cambiar el nombre de una de las funciones.

36. Herencia múltiple y herencia selectiva • Algunos sistemas OO no permiten la herencia múltiple. • La herencia selectiva se produce cuando un subtipo hereda sólo algunas funciones del supertipo. • Puede usarse una claúsula EXCEPT para enumerar las funciones que no debe heredar. • No es usual que los sistemas cuenten con este mecanismo.

37. Versiones y configuraciones • Muchas aplicaciones de BD que usan sistemas OO requieren la existencia de varias versiones de un mismo objeto. • Si un sistema está en funcionamiento, y se quieren hacer cambios sobre un objeto, el diseñador creará una nueva versión del objeto para efectuar los cambios. Las versiones existentes no se desechan hasta que se han probado exhaustivamente las nuevas.

38. Versiones y configuraciones • Puede haber más de una versión de un mismo objeto, por ejemplo, cuando se trabaja concurrentemente. Pero en algún momento habrá que combinarlas en una nueva (híbrida), lo que precisa la creación de una nueva versión. • Algunos SGBD cuentan con mecanismos para averiguar si algunos cambios son incompatibles, ayudando en el proceso de combinación. • Otros sistemas mantienen un gráfico de versiones que muestra la relación entre distintas versiones.

39. Versiones y configuraciones • Un objeto complejo consta de muchos módulos. Cuando se permite la creación de múltiples versiones, es posible que cada uno de esos módulos tenga varias versiones distintas y un gráfico de versiones. Una configuración del objeto complejo es una colección que consiste en una versión de cada módulo dispuesta de manera tal que las versiones de módulo en la configuración sean compatibles y juntas formen una versión válida del objeto complejo. • Una versión nueva o configuración del objeto complejo no tiene que incluir versiones nuevas para cada módulo. Así pues, ciertas versiones del módulo que no se han cambiado pueden pertenecer a más de una configuración del objeto complejo. • Una configuración es una colección de versiones de diferentes objetos que, juntas, constituyen un objeto complejo, mientras que el gráfico de versiones describe versiones del mismo objeto.

40. Conclusiones • Los sistemas tradicionales tienen carencias, y para solventarlas se recurre a la OO. • La mayoría de los sistemas OO no implementan TODAS las características de OO, sino que relajan algunos requisitos. • Las características de las BDOO están muy relacionadas con las de los LPOO • Se mantiene cierta correspondencia entre los objetos de la BD y los del mundo real.