BASE DE DATOS ORIENTADAS A OBJETOS
8.1 Necesidades de los tipos complejos.
En los últimos años, la demanda ha incrementado las formas de abordar los tipos de datos más complejos. Considérense, por ejemplo, un conjunto de direcciones. Mientras una dirección completa puede ser vista como un elemento de datos atómico de tipo cadena de caracteres, esta forma de verlo escondería detalles como la calle, la población, la provincia, y el código postal que podrían ser interesantes para las consultas. Por otra parte, si una dirección se representa dividiéndola en comonentes (calle, población, provincia y código postal) las consultas escritas serían más complicadas, pues tendrían que mencionar cada campo. Una alternativa mejor
es permitir tipos de datos estructurados, que admiten un tipo dirección con subpartes calle, población, provincia y código postal.
8.2 El modelo de datos orientada a objetos.
8.2.1 Estructura de los objetos
Los objetos se corresponden con las entidades del modelo E-R. El paradigma orientado a objetos está basado en el encapsulamiento de los datos
y del código relacionados con cada objeto en una sola unidad cuyo contenido no es visible desde el exterior.
Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por tanto, la interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos.
En general, cada objeto está asociado con:
• Un conjunto de variables que contiene los datos del objeto; las variables se corresponden con los atributos del modelo E-R.
• Un conjunto de mensajes a los que responde; cada mensaje puede no tener parámetros, tener uno o varios.
• Un conjunto de métodos, cada uno de los cuales es código que implementa un mensaje; el método devuelve un valor como respuesta al mensaje.
El término mensaje en un entorno orientado a objetos no implica el uso de mensajes físicos en redes informáticas. Por el contrario hace referencia al intercambio de solicitudes entre los objetos independientemente de los detalles concretos de su implementación. 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 eje-
cución del método correspondiente.
8.2.2 Clases de objetos
Generalmente, en una base de datos hay muchos objetos similares. 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.
Sería un derroche definir por separado cada uno de estos objetos. Por tanto, los objetos parecidos se agrupan para formar una clase. Cada uno de estos objetos se denomina ejemplar de su clase. Todos los objetos de una clase comparten una definición común, pese a que se diferencien en los valores asignados a las variables.
El concepto de clase del modelo orientado a objetos se corresponde con el concepto de entidad del modelo E-R. Algunos ejemplos de clases en la base de datos bancaria son los empleados, los clientes, las cuentas y los préstamos.
8.2.3 Herencia
El concepto de jerarquía de clases es parecido al de especialización del modelo entidad-relación. Los empleados y los clientes pueden representarse mediante clases que son especializaciones de la clase persona.
Las variables y los métodos específicos de los empleados se asocian con la clase empleado. Las variables y los métodos específicos de los clientes se asocian con
la clase cliente. Las variables y los métodos que se aplican tanto a empleados como a clientes se asocian con la clase persona.
8.2.4 Herencia mùltiple
En la mayor parte de los casos una organización de clases con estructura de árbol resulta adecuada para describir las aplicaciones; en la organización con estructura de árbol, cada clase puede tener a lo sumo una superclase. Sin embargo, hay situaciones que no pueden representarse bien en una jerarquía de clases con estructura de árbol.
La herencia múltiple permite a las clases heredar variables y métodos de múltiples superclases. La relación entre clases y subclases se representa mediante un grafo acíclico dirigido (GAD) en el que las clases pueden tener más de una superclase.
8.2.5 Identidad de los objetos
Los objetos de las bases de datos orientadas a objetos suelen corresponder a entidades del sistema modelado por la base de datos. Las entidades conservan su identidad aunque algunas de sus propiedades cambien con el tiempo. De manera parecida, los objetos conservan su identidad aunque los valores de las variables o las definiciones de los métodos cambien total o parcialmente con el tiempo. Este concepto de identidad no se aplica a las tuplas de las bases de datos relacionales. En los sistemas relacionales las tuplas de una relación sólo se distinguen por los valores que contienen.
8.2.6 Continentes de objetos
Se pueden utilizar las referencias entre objetos para modelar diferentes conceptos del mundo real. Uno de estos objetos es el de continentes de objetos. Para ilustrar los continentes de objetos considérese la base de datos simplificada para diseño de bicicletas de la Figura 8.6. Cada diseño de bicicletas contiene las ruedas, el cuadro, los frenos y los cambios. Las ruedas, a su vez, contienen la llanta, un conjunto de radios y el neumático.
8.3 LENGUAJE ORIENTADOS A OBJETOS
Hasta el momento se han abordado los conceptos básicos de la programación orientada a objetos en un nivel abstracto. Para poder utilizarlos en la práctica en un sistema de bases de datos hay que expresarlos en algún lenguaje. Esta expresión puede realizarse de dos maneras:
1. Los conceptos de la programación orientada a objetos se utilizan simplemente como herramientas de diseño y se codifican, por ejemplo, en una
base de datos relacional. Se sigue este enfoque cuando se utilizan los diagramas entidad-relación para modelar los datos y luego se convierten de manera manual en un conjunto de relaciones.
2. Los conceptos de la programación orientada a objetos se incorporan en un lenguaje que se utiliza para trabajar con la base de datos. Con este enfoque hay varios lenguajes posibles en los que se pueden integrar los conceptos:
En los últimos años, la demanda ha incrementado las formas de abordar los tipos de datos más complejos. Considérense, por ejemplo, un conjunto de direcciones. Mientras una dirección completa puede ser vista como un elemento de datos atómico de tipo cadena de caracteres, esta forma de verlo escondería detalles como la calle, la población, la provincia, y el código postal que podrían ser interesantes para las consultas. Por otra parte, si una dirección se representa dividiéndola en comonentes (calle, población, provincia y código postal) las consultas escritas serían más complicadas, pues tendrían que mencionar cada campo. Una alternativa mejor
es permitir tipos de datos estructurados, que admiten un tipo dirección con subpartes calle, población, provincia y código postal.
8.2 El modelo de datos orientada a objetos.
8.2.1 Estructura de los objetos
Los objetos se corresponden con las entidades del modelo E-R. El paradigma orientado a objetos está basado en el encapsulamiento de los datos
y del código relacionados con cada objeto en una sola unidad cuyo contenido no es visible desde el exterior.
Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por tanto, la interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos.
En general, cada objeto está asociado con:
• Un conjunto de variables que contiene los datos del objeto; las variables se corresponden con los atributos del modelo E-R.
• Un conjunto de mensajes a los que responde; cada mensaje puede no tener parámetros, tener uno o varios.
• Un conjunto de métodos, cada uno de los cuales es código que implementa un mensaje; el método devuelve un valor como respuesta al mensaje.
El término mensaje en un entorno orientado a objetos no implica el uso de mensajes físicos en redes informáticas. Por el contrario hace referencia al intercambio de solicitudes entre los objetos independientemente de los detalles concretos de su implementación. 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 eje-
cución del método correspondiente.
8.2.2 Clases de objetos
Generalmente, en una base de datos hay muchos objetos similares. 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.
Sería un derroche definir por separado cada uno de estos objetos. Por tanto, los objetos parecidos se agrupan para formar una clase. Cada uno de estos objetos se denomina ejemplar de su clase. Todos los objetos de una clase comparten una definición común, pese a que se diferencien en los valores asignados a las variables.
El concepto de clase del modelo orientado a objetos se corresponde con el concepto de entidad del modelo E-R. Algunos ejemplos de clases en la base de datos bancaria son los empleados, los clientes, las cuentas y los préstamos.
8.2.3 Herencia
El concepto de jerarquía de clases es parecido al de especialización del modelo entidad-relación. Los empleados y los clientes pueden representarse mediante clases que son especializaciones de la clase persona.
Las variables y los métodos específicos de los empleados se asocian con la clase empleado. Las variables y los métodos específicos de los clientes se asocian con
la clase cliente. Las variables y los métodos que se aplican tanto a empleados como a clientes se asocian con la clase persona.
8.2.4 Herencia mùltiple
En la mayor parte de los casos una organización de clases con estructura de árbol resulta adecuada para describir las aplicaciones; en la organización con estructura de árbol, cada clase puede tener a lo sumo una superclase. Sin embargo, hay situaciones que no pueden representarse bien en una jerarquía de clases con estructura de árbol.
La herencia múltiple permite a las clases heredar variables y métodos de múltiples superclases. La relación entre clases y subclases se representa mediante un grafo acíclico dirigido (GAD) en el que las clases pueden tener más de una superclase.
8.2.5 Identidad de los objetos
Los objetos de las bases de datos orientadas a objetos suelen corresponder a entidades del sistema modelado por la base de datos. Las entidades conservan su identidad aunque algunas de sus propiedades cambien con el tiempo. De manera parecida, los objetos conservan su identidad aunque los valores de las variables o las definiciones de los métodos cambien total o parcialmente con el tiempo. Este concepto de identidad no se aplica a las tuplas de las bases de datos relacionales. En los sistemas relacionales las tuplas de una relación sólo se distinguen por los valores que contienen.
8.2.6 Continentes de objetos
Se pueden utilizar las referencias entre objetos para modelar diferentes conceptos del mundo real. Uno de estos objetos es el de continentes de objetos. Para ilustrar los continentes de objetos considérese la base de datos simplificada para diseño de bicicletas de la Figura 8.6. Cada diseño de bicicletas contiene las ruedas, el cuadro, los frenos y los cambios. Las ruedas, a su vez, contienen la llanta, un conjunto de radios y el neumático.
8.3 LENGUAJE ORIENTADOS A OBJETOS
Hasta el momento se han abordado los conceptos básicos de la programación orientada a objetos en un nivel abstracto. Para poder utilizarlos en la práctica en un sistema de bases de datos hay que expresarlos en algún lenguaje. Esta expresión puede realizarse de dos maneras:
1. Los conceptos de la programación orientada a objetos se utilizan simplemente como herramientas de diseño y se codifican, por ejemplo, en una
base de datos relacional. Se sigue este enfoque cuando se utilizan los diagramas entidad-relación para modelar los datos y luego se convierten de manera manual en un conjunto de relaciones.
2. Los conceptos de la programación orientada a objetos se incorporan en un lenguaje que se utiliza para trabajar con la base de datos. Con este enfoque hay varios lenguajes posibles en los que se pueden integrar los conceptos:
Comentarios
Publicar un comentario