Universidad de las Ciencias Informáticas
“Facultad 4”
Título: “Lenguaje de Consulta para Bases de Datos Orientada a Objetos”.
Trabajo de Diploma para optar por el título de Ingeniero Informático
Autor(es): Anabel Betancourt de los Santos.
Mairienis Morales Limonte.
Tutor(es): Lic. Adrián Maranje Agramonte.
Co-tutor: Lic. Karel Osório Ramirez.
“Mayo del 2008”
Declaramos ser autores de la presente tesis y reconocemos a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
__________________________ ____________________________
Anabel Betancourt de los Santos. Mairienis Morales Limonte.
Firma Firma
____________________________
Lic. Adrián Maranje Agramonte Firma
Licenciando en Ciencia de la Computación, avalado por la Universidad de la Habana y la Universidad de Oriente. Categorizado en la Universidad de las Ciencias Informáticas con el grado docente de Instructor Con 5 años de experiencia en software de gestión y 4 años de experiencia laboral en áreas de informática. Ha presentado trabajos en eventos científicos sobre todo en la Universidad de las Ciencias Informáticas.
Correo electrónico: [email protected]
Ubicación: Facultad 2, UCI, Cuba.
II
ÂVâtÇwÉ áx xá }ÉäxÇ? áx vÜxtA VâtÇwÉ áx xá
|ÇàxÄ|zxÇàx? áx ÑÜÉwâvxA aÉ áx twtÑàt? áx |ÇäÉvtM Ät Åxw|tÇ•t vÉÑ|tN Ät ÉÜ|z|ÇtÄ|wtw áx tàÜxäxAÊ
]Éá° `tÜà•A
III
T Å| ÅtwÜx? Å| ÑtwÜx?
Å|á tuâxÄÉá ç Å|á {xÜÅtÇÉáA
TÇtuxÄ UxàtÇvÉâÜà wx ÄÉá ftÇàÉáA
IV
T Å| ÅtwÜx? Å| ÑtwÜx?
Å|á tuâxÄÉá ç Å| {xÜÅtÇÉA
`t|Ü|xÇ|á `ÉÜtÄxá _|ÅÉÇàxA
V como profesionales.
A Fidel Castro por ser el actor intelectual de este gran sueño que es la Universidad de las Ciencias Informáticas y hacernos participe de su realidad.
A nuestro tutor Adrián Maranje Agramonte, por ser tan especial, por su apoyo incondicional, por poner a nuestra disposición sus conocimientos, tiempo y entrega, por ser para nosotros un excelente guía, un amigo y un ejemplo a seguir en todo momento.
A todos aquellos amigos que siempre nos apoyaron de una forma u otra y que supieron darnos aliento en los momentos que más lo necesitábamos.
En fin a todos aquellos que hicieron posible la realización de este gran sueño.
VI A mis hermanos Ana Liz, Yuliet y Abdel por el respaldo y la confianza.
A Yuri Antonio por demostrar ser un muy buen amigo.
A mis otros dos padres Lourdes y Adalberto por todo lo que han luchado junto a mí y por todo su cariño.
A Margot, que hoy puede ver a mi lado como se hacen realidad los sueños.
A mi tutor y amigo incondicional Adrian por tomarme de la mano y no dejarme caer.
A mis tíos, abuelos, primos y cuñados.
A mis sobrinos Samuel David, Jorgito, Yorlli y Joan Mario.
A mi abuelita Julia por haber formado en mí la mujer que soy hoy.
A los profesores en general por cada granito de arena depositado en mí.
A los amigos y demás familiares por preocuparse y por acompañarme en esta travesía que es la vida.
Anabel.
VII preocupación constante por mis estudios y deberes, por sus consejos que me han guiado en la vida, por haber sabido educarme bajo buenos principios y modales que me han sido muy útiles, por ser ejemplos, quererme y cuidarme tanto.
A mi hermano por apoyarme en todo, por ser tan especial conmigo y por saber alegrarme en los momentos que lo he necesitado.
A mis abuelitos por su preocupación constante, por su cariño, sus cuidados y sus ejemplos que han sabido guiarme en momentos de mi vida.
A mi novio Yosbel Ernesto, por apoyarme en todas las circunstancias, por estar siempre a mi lado, por tenerme la paciencia que he necesitado durante todo este tiempo y saber darme el aliento que he necesitado
A mi tutor y más que eso amigo Adrián por su tiempo y dedicación, por estar presente y dispuesto a ayudarme y orientarme cada vez que lo necesito, por ser una persona tan especial y ser un ejemplo a seguir.
A mis suegros Juanicel Alonso y Porfirio González y a mis cuñadas Lien y Lisy por su preocupación.
A mi prima Marilay por estar siempre dispuesta a ayudarme.
A mis tíos Arturo, David, Alberto, mis tías y mis primos por estar siempre al pendiente de mí.
A mis amistades: Velmour, Yily, Danay y mi compañera de tesis Anabel.
A todos aquellos profesores, a los cuales les debo mi formación.
Y a todos los que hoy han podido disfrutar conmigo este sueño que se ha hecho realidad.
Mairienis.
VIII que modelan la solución de problemas en un sistema gestor de datos capaz de almacenar la información en forma de objetos y no de tablas como en los sistemas relacionales y cuya finalidad sea la de brindar abstracción en cuanto al modo de acceso a la información.
Para el desarrollo del mismo se realizó un estudio acerca de los principales estándares de lenguajes para Sistemas Gestores de Bases de Datos Orientadas a Objetos (SGBDOO), analizando además diferentes lenguajes para SGBDOO con el objetivo de determinar las potencialidades y deficiencias que poseían cada uno de ellos y determinándose en cada caso las posibilidades que brindan para materializar los conceptos de la programación orientada a objetos.
En el trabajo se realiza una propuesta de lenguaje de consulta orientado a objeto para un SGBDOO y se describe su estructura así como cada una de las características principales que posee. También se detalla la forma en que este lenguaje materializa cada uno de los conceptos de la programación orientada a objetos como son la herencia, el polimorfismo, el encapsulamiento, entre otros.
El lenguaje propuesto es capaz de proveer representación de objetos complejos. Soporta la encapsulación o abstracción de información. Proporciona la capacidad para ocultar cómo los datos se representan dentro del objeto y cómo se implementa cada método de otros objetos y otras entidades fuera de sí mismo. Permite expresar herencia entre objetos. Es un lenguaje de alto nivel, de modo que se pueden formular fácilmente operaciones complejas.Es declarativo, esto es que el foco de atención está dirigido hacia QUE se quiere y no hacia COMO se obtiene. Es eficiente, puesto que las construcciones permiten optimizaciones.
PALABRAS CLAVE
Lenguaje, Consultas, Objetos, Bases de Datos.
IX DEDICATORIA ... IV AGRADECIMIENTOS ...V RESUMEN...VIII
INTRODUCCIÓN... 1
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 5
Introducción... 5
1.1 Estándares de lenguajes para SGDBOO ... 5
1.1.1 Estándar JDO ... 5
1.1.3 Estándar SQL 1999 ... 6
1.1.4 Estándar ODMG-93 ... 6
1.1.4.1 Lenguaje de Control ... 9
1.1.4.2 Lenguaje ODL ... 10
1.1.4.2.1 Tipos en el lenguaje ODL... 11
1.1.4.3 Lenguaje OML ... 12
1.1.4.4 Lenguaje OQL ... 13
1.2 Panorama de algunos sistemas para el almacenamiento de Objetos... 14
1.2.1 SGBDOO Starburst... 14
1.2.1.1 Lenguaje de consulta Hydrogen... 15
1.2.2 SGBDOO POSTGRES... 15
1.2.2.1 Características del modelo ... 15
1.2.3 SGBDOO ObjectFile ... 15
1.2.3.1 Deficiencias como sistema ... 16
1.2.4 SGBDOO DarmStadt... 16
1.2.5 SGBDOO StreamStore ... 18
1.2.5.1 Deficiencias como sistema ... 18
1.2.6 SGBDOO Jeevan ... 18
1.2.6.1 Deficiencias como sistema ... 19
1.2.7 SGBDOO Jasmine ... 20
1.2.7.1 Lenguaje de programación Jasmine/C... 21
1.2.8 SGBDOO GemStone... 21
1.2.10 SGBDOO O2 ... 22
1.2.10.1 Lenguaje O2 ... 22
1.3 Conclusiones ... 23
CAPÍTULO 2: PROPUESTA DE UN LENGUAJE ESTÁNDAR DE CONSULTA PARA UN SGBDOO. ... 24
Introducción... 24
X
2.2 Lenguajes de consulta orientados a objetos... 28
2.2.1 Atributos del Lenguaje de Consulta ... 29
2.3 Valores ... 30
2.3.1 Valores Nulos... 30
2.3.2 Tipos de datos ... 31
2.3.4 Literales ... 34
2.3.5 Herencia y polimorfismo... 35
2.3.5.1 Subtipos y Herencias de Comportamientos ... 35
2.3.5.1.1 Herencia de Estados... 36
2.3.6 Encapsulamiento ... 36
2.3.7 Relaciones... 36
2.3.9 Expresiones... 39
2.4 Conclusiones ... 40
CAPÍTULO 3: MANIPULACIÓN DE ESQUEMAS Y DATOS ... 41
Introducción... 41
3.1 Especificación formal de la sintaxis ... 41
3.2 Lenguaje de consulta de objetos ... 41
3.2.1 Sintaxis de definición de esquemas... 42
3.2.2 Sintaxis para consulta. ... 43
3.2.2.1 La instrucción INSERT, UPDATE, DELETE... 43
3.2.2.2 La instrucción SELECT ... 44
3.3 Predicados ... 46
3.4 Literales para tipos primitivos. ... 47
3.5 Creación de Objetos ... 48
3.6 Expresiones de camino ... 49
3.7 Unión ... 50
3.8 Trabajando con valores nulos. Ejemplos... 50
3.9 Invocando métodos. ... 51
3.10 Polimorfismo... 52
3.10.1 Enlace tardío... 52
3.10.2 Indicador de clases (casting). ... 53
3.11 Consultas con nombres... 53
3.12 Composición de operadores... 54
3.4.1 Expresiones elementales... 57
3.4.2 Construcción de expresiones ... 58
3.4.2.1 Construcción de objetos. ... 58
3.4.2.2 Construcción de estructuras. ... 58
3.4.2.3 Construcción de conjuntos. ... 59
3.4.2.4 Construcción de listas. ... 59
3.4.2.5 Construcción de bolsas... 59
3.4.2.6 Construcción de arreglos... 60
XI
3.4.3.5 Acceder a los elementos de un diccionario a través de una llave. ... 62
3.4.4 Conjunto binario de expresiones ... 62
3.4.4.1 Unión, intersección, diferencia... 62
3.4.4.2 Inclusión. ... 63
3.4.5 Conversión de expresiones ... 63
3.4.5.1 Extraer elementos de una selección... 63
3.4.5.2 Transformando una lista en conjunto. ... 63
3.4.5.3 Eliminando duplicados. ... 63
3.4.5.4 Aplanar una colección de colecciones. ... 64
CONCLUSIONES... 65
RECOMENDACIONES ... 66
BILIOGRAFÍA ... 67
ANEXOS ... 70
1 INTRODUCCIÓN
Desde que se empezaron a introducir los ordenadores para automatizar la gestión de las empresas en la década de los sesenta, la evolución de los sistemas de información ha tenido una considerable repercusión en la gestión de los datos, desplazándose el centro de gravedad de la informática, que estaba situado en el proceso, hacia la estructuración de los datos.
Surge así, a finales de los sesenta y principios de los setenta, la primera generación de productos de bases de datos en red. En los últimos años hemos venido asistiendo a un avance significativo en la tecnología de bases de datos.
En las décadas anteriores la tecnología para soportar el desarrollo de aplicaciones intensivas de datos tuvo una evolución de cuatro generaciones, entre ellas, sistemas de archivos, sistemas de bases de datos jerárquicos, sistemas de bases de datos en red y sistemas de bases de datos relacionales. En todos los casos, la transición de una generación a otra, ha sido motivada por la imperiosa necesidad de minimizar los costos de desarrollo de aplicaciones, así como los de mantenimiento y mejora de programas de aplicación.
Los sistemas convencionales (relacionales y prerrelacionales) han servido para satisfacer las necesidades de aplicaciones del ambiente para el cual fueron diseñadas, es decir, de procesamiento de datos en negocios, tales como control de inventario, nóminas, cuentas por cobrar etc. Pero aun así existen sistemas que requieren muchas veces:
• Facilidades para modelar y manejar entidades anidadas complejas (tales como diseño de objetos y documentos compuestos).
• Un conjunto sofisticado de tipos de datos, por ejemplo, tipos de datos definidos por el usuario y tipos grandes pero sin estructura (tales como imágenes, audio y documentos textuales).
• Representación de conceptos semánticos (tales como relaciones de generalización y agregación).
• El concepto de evolución temporal de datos (por ejemplo, dimensión temporal de datos y mantener versiones de datos).
2 Además la implementación de las aplicaciones debe realizarse sobre un lenguaje que es una combinación de un lenguaje de programación y un lenguaje de consulta por lo que las aplicaciones quedan totalmente dependientes del gestor de datos.
La estrategia que se decidió optar en la tecnología de base de datos orientada a objetos implica fundamentalmente una transición, más que un incremento de extensiones a sistemas administradores de datos actuales. El núcleo de esta transición está en un nuevo paradigma desarrollado en los lenguajes de programación orientados a objetos que surgen después de la introducción de Simula-67 y Smalltalk-80.
Existen dos razones principales por las que la metodología orientada a objetos es un sólido fundamento para la nueva generación de tecnología de base de datos.
Por una parte, esta metodología ofrece un modelo de datos que incluye los modelos de datos de un sistema de base de datos convencional. Un modelo de datos orientado a objetos puede representar no solamente los datos, las relaciones y la interacción de datos de modelos de datos convencionales, sino también permite encapsular los datos y programas que operan datos con un protocolo definido y proporcionan una estructura uniforme para el trato de tipos de datos arbitrarios definidos por el usuario. Algunas relaciones en el modelo de datos, que son difíciles en sistemas de bases de datos convencionales, son inherentes a un modelo de datos basado en objetos.
Una segunda razón, es que a través de la noción de encapsulamiento y herencia, esta metodología está fundamentalmente diseñada para reducir la dificultad de desarrollo y evolución de sistemas complejos de "software". Esta última fue, precisamente, la meta que motivó a la tecnología de administración de datos, a transformar sistemas de archivos hacia sistemas de bases de datos relacionales.
Existen algunos desafíos que deben considerarse antes de adoptar la tecnología de bases de datos orientada a objetos:
Primero, la tecnología es reciente y se necesita más madurez. Muchos de los productos comerciales comunes poseen distintos grados de calidad en cuanto a desempeño y funcionalidad. Con frecuencia, los proveedores ofrecen solamente motores (máquinas) de
3 Bases de Datos con interfaces propietarias para desarrollo de aplicaciones por los programadores; la inclusión de herramientas de desarrollo está comenzando a surgir.
Segundo, la fuerza de un modelo de datos orientado a objetos es también su debilidad. La riqueza de este modelo hace posible la generación de unos más complejos y sus relaciones con las aplicaciones de procesamiento de datos, introducen aspectos complejos que el usuario debe manejar.
Tercero, no obstante el alto grado de desarrollo y experimentación en lenguajes de programación orientados a objetos y aplicaciones, todavía no hay un consenso en la industria sobre la semántica de su paradigma que vaya más allá de un conjunto de conceptos de alto nivel sobre la programación orientada a objetos, por lo que aún no existen estándares en esta tecnología.
Por todo lo que hasta aquí se ha expuesto se propone realizar la investigación a partir del siguiente problema: ¿Cómo utilizar la transparencia que brindan los paradigmas de programación orientado a objeto en cuanto al cómputo de información para obtener las especificaciones básicas de un lenguaje estándar de consulta para un sistema gestor de datos en forma de objeto?
Partiendo del problema anterior el Objeto de Estudio lo constituye: La Metodología Orientada a Objetos en el modelo de almacenamiento de información.
Delimitando como el Campo de acción: Los lenguajes de programación en sistemas gestores de bases de datos orientada a objetos. Se propone como Objetivo general del presente trabajo: Proponer las especificaciones básicas para diseñar un lenguaje de consulta para un sistema gestor de datos orientado a objetos y cuya finalidad sea la de brindar abstracción en cuanto al modo de acceso a la información.
Dada la problemática que se ha planteado se definieron como Objetivos específicos:
• Definir los tipos primitivos del lenguaje
• Definir las principales instrucciones del lenguaje.
• Definir el lenguaje de consulta.
Para cumplir el objetivo propuesto se proponen las siguientes Tareas de investigación:
4
• Estudio de los sistemas gestores de base de datos relacionales y prerrelacionales y los paradigmas de programación orientados a objetos.
• Evaluar el estado del arte y definir la posición teórica del investigador.
• Proponer una metodología para almacenar la información contenida en los objetos que modelan la solución de problemas.
• Proponer un lenguaje de consulta para el almacenamiento, la recuperación y la actualización de la información contenida en los objetos que modelan la solución de problemas.
Este trabajo ha sido estructurado de la siguiente manera:
Capítulo 1: Describe los principales estándares de lenguajes para Sistemas Gestores de Bases de Datos Orientadas a Objetos (SGBDOO). Se analizan además diferentes lenguajes para SGBDOO con el objetivo de determinar las características comunes y las potencialidades de los mismos.
Capítulo 2: Describe las principales características del lenguaje estándar de consulta propuesto para un SGBDOO. Analizando además cada uno de los aspectos más significativos que se deben tener en cuenta a la hora de diseñar un lenguaje de consulta orientado a objetos.
Capítulo 3: Se desarrolla la propuesta de solución del lenguaje de consulta para bases de datos orientada a objetos.
5 CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA
Introducción
En este capítulo se describen los principales estándares de lenguajes para Sistemas Gestores de Bases de Datos Orientadas a Objetos (SGBDOO). Se analizan además diferentes lenguajes para SGBDOO con el objetivo de determinar las características comunes y las potencialidades de los mismos.
1.1 Estándares de lenguajes para SGDBOO 1.1.1 Estándar JDO
El estándar JDO (Java Data Objects) es un lenguaje de programación, que permite a los desarrolladores escribir código Java para acceder de forma transparente a los datos almacenados sin utilizar el código específico de la base de datos. JDO fue desarrollado como un JSR en la Java Community Process (JCP) programa: JDO 1,0, en existencia desde 2002, es JSR 12, y JDO 2,0, aprobado a principios de 2005 y en desarrollo, es JSR 243.
Los beneficios de la utilización de JDO son los siguientes:
• Portabilidad.
• Acceso a bases de datos de forma transparente.
• Facilidad de uso.
• Alto rendimiento.
• Integración con EJB (Enterprise JavaBeans Technology).1
El API JDO, consta de unos pocos interfaces, es sencillo de aprender y usar, pero lo más importante es que define un estándar para la persistencia de objetos.
1Qusay H. Mahmoud.Guetting Started with Java Data Objects. [En línea] [Citado el: 26 de Marzo de 2008. ] http://java.sun.com/developer/technicalArticles/J2SE/jdo/.
6 1.1.3 Estándar SQL 1999
SQL 1999 es un lenguaje fuertemente tipado, cuyos tipos poseen comportamiento. Añade Tipos Definido por el usuario (UDTs) de SQL. Hay dos tipos de UDTs: distintos y estructurados.
El Tipo Distinto posee las siguientes operaciones:
• Operadores de comparación.
• Operadores de CAST.
• Métodos y funciones.
• No hay mecanismos de herencia entre tipos distintos.
El tipo estructurado posee las siguientes características:
• Está fuertemente tipado.
• Posee Abstracción Encapsulación, y Polimorfismo.
• Ligadura dinámica.
• Verificación de tipos estática.2
En el SQL 99 cada fila es una instancia de la clase y cada atributo de la clase se transforma en una columna de la tabla.
El tipo definido por el usuario (UDT) se puede utilizar como:
• Atributo de otro tipo estructurado.
• Parámetro de función(es), método(s) y procedimiento(s).
• Variable SQL.
• Dominio o columna.
• También se pueden usar para definir tablas y vistas.
1.1.4 Estándar ODMG-93
ODMG-93 (Object-Oriented Database Management Group) es un punto de partida muy importante para el establecimiento de un estándar para Bases de datos Orientadas a Objetos.
2INCITS Technical Committee H2 on Database.SQL:1999[En línea] [Citado el:7 de Febrero de 2008.] http://www.service- architecture.com/database/articles/sql1999.html.
7 Adopta una arquitectura que consta de un sistema de gestión que soporta un lenguaje de bases de datos orientado a objetos, con una sintaxis similar a un lenguaje de programación también orientado a objetos como puede ser C++ o Smalltalk. El lenguaje de bases de datos es especificado 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.
En definitiva, ODMG-93 intenta definir un SGBDOO que integre las capacidades de las bases de datos con las capacidades de los lenguajes de programación, de forma que los objetos de la base de datos 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. El SGBDOO extiende el lenguaje con persistencia, concurrencia, recuperación de datos, consultas asociativas, etc.
La especificación del ODMG reconoce dos tipos de objetos: transitorios y persistentes. Los objetos transitorios son gestionados por el sistema en tiempo de ejecución, ya sea Smalltalk, Java, o C + +.
La especificación ODMG relacional describe las conexiones entre los objetos. Al igual que sus homólogos en el modelo relacional, en ODMG-93 las relaciones pueden ser de uno a uno, uno-a-muchos, o muchos-a-muchos. ODMG-93 especifica un carácter vinculante entre los lenguajes de programación y bases de datos.
• El modelo de objetos ODMG permite que tanto los diseños, como las implementaciones, sean portables entre los sistemas que lo soportan. Dispone de las siguientes primitivas de modelado:
• Los componentes básicos de una base de datos orientada a objetos son los objetos y los literales.
• Un objeto es una instancia autocontenida de una entidad de interés del mundo real. Los objetos tienen algún tipo de identificador único.
8
• Un literal es un valor específico. Los literales no tienen identificadores. Un literal no tiene que ser necesariamente un solo valor, puede ser una estructura o un conjunto de valores relacionados que se guardan bajo un solo nombre.3
• Los objetos se dividen en tipos. Los objetos de un mismo tipo tienen un mismo comportamiento y muestran un rango de estados común:
o El comportamiento se define por un conjunto de operaciones que pueden ser ejecutadas por un objeto.
o El estado de los objetos se define por los valores que tienen para un conjunto de propiedades.
Las propiedades pueden ser:
• Atributos del objeto: Los atributos toman literales por valores y son accedidos por operaciones del tipo get_value y set_value.
• Relaciones entre el objeto y uno o más objetos: Son propiedades que se definen entre tipos de objetos, no entre instancias. Las relaciones pueden ser 1-a-1, 1-a-muchos o muchos-a-muchos.
• Un tipo tiene una interfaz y una o más implementaciones.
• La interfaz define las propiedades visibles externamente y las operaciones soportadas por todas las instancias del tipo.
• La implementación define la representación física de las instancias del tipo y los métodos que implementan las operaciones definidas en la interfaz.
Los tipos pueden tener las siguientes propiedades:
• Supertipos: los tipos se pueden jerarquizar. Todos los atributos, relaciones y operaciones definidas sobre un supertipo son heredados por los subtipos. Los subtipos pueden añadir propiedades y operaciones adicionales para proporcionar un comportamiento especializado a sus instancias.
3Brian Jepson .The Object Database Management Group[En línea] [Citado el: 10 de Marzo de 2008.]
http://www.dbmsmag.com/9707d131.html.
9
• Además de la herencia simple, se admite la herencia múltiple, y en el caso de que dos propiedades heredadas coincidan en el subtipo, se redefinirá el nombre de una de ellas.
o Extensión: es el conjunto de todas las instancias de un tipo dado. El sistema puede mantener automáticamente un índice a los miembros de este conjunto incluyendo una declaración de extensión en la definición de tipos. El mantenimiento de la extensión es opcional y no necesita ser realizada para todos los tipos.
o Claves: propiedad o conjunto de propiedades que identifican de forma única las instancias de un tipo. Las claves simples están constituidas por una única propiedad. Las claves compuestas están constituidas por un conjunto de propiedades. Las claves pueden estar constituidas no sólo por atributos, sino también por relaciones.
Un tipo puede tener una o más implementaciones. A cada una de estas implementaciones se le da un nombre, que además debe ser único dentro del ámbito definido por un tipo. Las implementaciones asociadas a un tipo son separadas léxicamente en el Lenguaje de Definición de Objetos (ODL). Una clase, en este modelo, es la combinación de la interfaz del tipo y una de las implementaciones definidas.
El hecho de permitir varias implementaciones provee ventajas. La primera de ellas es que soporta fácilmente Bases de datos que están sobre redes, donde puede haber máquinas con arquitecturas diferentes (soportando mezcla de lenguajes y compiladores). La segunda es que facilita al programador su tarea al poder comparar fácilmente cuál de las implementaciones se comporta mejor. La implementación que emplee un objeto se especifica en tiempo de creación.
1.1.4.1 Lenguaje de Control
El lenguaje de control es el que permite gestionar las transacciones, controlar el acceso a bases de datos desde múltiples usuarios, gestionar los recursos como los índices, reforzar la integridad de la base de datos basándose en condiciones especificadas por el usuario, etc.
10 Además, en la autorización hay que tener en cuenta el modelo de orientación a objetos, contemplando la autorización por ejemplo para ejecutar métodos, para acceder no sólo a un tipo sino a una jerarquía de tipos, etc. En ODMG el lenguaje de control forma parte del lenguaje de manipulación, pero no incluye la mayoría de las funcionalidades anteriores.
En ODMG se considera un modelo de transacciones anidado para la gestión de transacciones, pero no se consideran detalles como la autorización para ejecutar métodos.
También se indica explícitamente que en un mundo ideal no sería necesario especificar si una colección debe ser indexada o no, con lo que no se considera la indicación explícita de la indexación en el modelo del usuario.
Este estándar tampoco se pronuncia sobre los disparadores que, aunque la gran mayoría de la comunidad de las bases de datos orientadas a objetos no los considera entre otras cosas porque suponen una violación de la encapsulación, también tienen sus defensores.
1.1.4.2 Lenguaje ODL
El lenguaje ODL está diseñado para apoyar las estructuras semánticas del modelo de datos ODMG. Es independiente de cualquier idioma de programación. Crea las especificaciones de los objetos: las clases e interfaces. Además de que especifica un esquema de la base de datos.
Es un Lenguaje de Definición de Objetos para sistemas compatibles con ODMG. Es el equivalente del DDL (Lenguaje de Definición de Datos) de los sistemas Gestores de bases de Datos (SGBD) tradicionales. Define los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones.
Dicho lenguaje se utiliza para expresar la estructura y condiciones de integridad sobre el esquema de la BD. En una BD relacional define las tablas, los atributos en la tabla, el dominio de los atributos y las restricciones sobre un atributo o una tabla. El ODL además debe poder definir también métodos, jerarquías, herencia, etc.
11 1.1.4.2.1 Tipos en el lenguaje ODL
El lenguaje ODL ofrece al diseñador de BD un sistema de tipos semejantes a los de otros lenguajes de programación comunes. Se pueden crear tipos complejos a partir de otros más simples. Los tipos permitidos son:
1. Tipos básicos que a su vez pueden ser:
• Tipos atómicos: enteros, de punto flotante, caracteres, cadenas de caracteres y booleanos.
• Enumeraciones: los valores de una enumeración se declaran en ODL.
2. Tipos de interfaz o estructurados: son tipos complejos obtenidos al combinar tipos básicos por medio de los siguientes constructores de tipos:
• Conjunto (set<tipo>) denota el tipo cuyos valores son todos los conjuntos finitos de elementos del tipo “tipo”.
• Bolsa (bag<tipo>) denota el tipo cuyos valores son bolsas o multiconjuntos de elementos del tipo “tipo”. Una bolsa permite a un elemento aparecer más de una vez.
• Lista (list<tipo>) denota el tipo cuyos valores son listas ordenadas finitas conteniendo ninguno o más elementos del tipo “tipo”. Un caso especial lo constituye el tipo string que es una abreviatura del tipo List<char>.
Hay reglas sobre qué tipos pueden asociarse a atributos y cuáles a relaciones.
• El tipo de un atributo se construye partiendo de un tipo básico o de una estructura cuyos campos sean básicos.
• El tipo de una relación es un tipo de interfaz o un tipo de colección que se aplica a un tipo de interfaz. 4
Por lo tanto, los tipos de interfaz no pueden aparecer en el tipo de un atributo y los tipos básicos no aparecen en el tipo de una relación.
4Prieto, Ana Belen Martinez. Un Sistema de Gestion de Base de Datos Orientadas a Objetos sobre una Maquina Abstracta Persistente.
2001.
12 Deficiencias como Lenguaje
El lenguaje de definición ODL no proporciona soporte para vistas, que en el modelo relacional suponen una unidad de autorización de acceso. En las bases de datos orientadas a objetos las vistas implican mucho más que en el modelo relacional ya que pueden formar parte de una jerarquía de herencia, pueden emplearse como el dominio de un atributo, pueden tener métodos al igual que atributos, e incluso suponen una forma de integrar bases de datos heterogéneas y dar soporte para la evolución de esquemas.
El ODL tampoco proporciona facilidades para llevar a cabo cambios dinámicos en el esquema de la base de datos que impliquen algo más que añadir un nuevo subtipo a un tipo ya existente. No proporciona facilidades para añadir o borrar un método o un atributo de un tipo, añadir un nuevo supertipo a un tipo existente o bien eliminarlo, etc.
1.1.4.3 Lenguaje OML
El Lenguaje de Manipulación de Objetos (OML) es empleado para la elaboración de programas que permitan crear, modificar y borrar datos que constituyen la BD. El ODMG no propone un OML estándar, simplemente sugiere que este lenguaje sea la extensión de un lenguaje de programación, de forma que se puedan realizar, entre otras, las siguientes operaciones sobre la BD:
• Creación de un objeto.
• Borrado de un objeto.
• Modificación de un objeto.
• Identificación de un objeto.
Deficiencias como Lenguaje
El lenguaje de manipulación OML no permite insertar, actualizar o borrar basándose en unas condiciones de búsqueda, es decir, no ofrece la posibilidad de insertar más de un objeto basándose en el cumplimiento de unas condiciones de búsqueda. Desde el punto de vista del estándar, estas operaciones explícitas no son incluidas para mantener la semántica del
13 modelo de objetos, obligando así a acudir a los métodos definidos en los objetos para realizar dichas operaciones.
1.1.4.4 Lenguaje OQL
OQL (Object Query Language) es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y estructuras. Está basado en SQL-92, proporcionando un superconjunto de la sintaxis de la sentencia SELECT.
Este lenguaje no posee primitivas para modificar el estado de los objetos ya que las modificaciones se pueden realizar mediante los métodos que estos poseen. La sintaxis básica de OQL es una estructura SELECT... FROM... WHERE..., como en SQL.
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.
• 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.
• Existen dos posibilidades para asociar un sublenguaje de consulta a un lenguaje de programación: fuerte y débilmente. El primer caso consiste en una extensión de la
14 gramática del lenguaje asociado. En el segundo caso, las funciones query tienen unos argumentos String que contienen las preguntas.5
Requerimientos del lenguaje de Consulta Descripción en OQL
Bases de datos Cuantificación existencial All, any….
Criterio de búsquedas compuestos Si
Funciones agregadas Avg, Max, Min
Funciones, agrupamiento y ordenación Order by, Group by
Consultas anidadas Si
Modelo de Objetos
Jerarquía de Agregación Si
Jerarquía de Herencia Si. Por defecto se incluyen todas las instancias de la subclase de la clase consultada
Métodos Si Polimorfismo Si
1.2 Panorama de algunos sistemas para el almacenamiento de Objetos.
1.2.1 SGBDOO Starburst
Starburst es un sistema de gestión de bases de datos relacional extendido. El objetivo del proyecto Starburst desarrollado en el centro de investigación de Almaden de IBM (1984-1992), y que además constituye la causa de su inclusión en esta revisión, era la construcción de un prototipo completo de un SGBD extensible. La extensibilidad tenía como objetivo permitir una
5Prieto, Ana Belen Martinez. Un Sistema de Gestion de Base de Datos Orientadas a Objetos sobre una Maquina Abstracta Persistente.
2001.
15 adaptación más fácil del sistema a las necesidades de los usuarios sin que el rendimiento del sistema se redujera.
1.2.1.1 Lenguaje de consulta Hydrogen
En Starburst las operaciones sobre tipos definidos por el usuario deben realizarse en el lenguaje de consulta, sin embargo, la aplicación es escrita en un lenguaje que es una combinación del lenguaje de programación y del lenguaje de consulta. Un preprocesador separa ambos. El lenguaje de consulta de Starburst, Hydrogen, expande SQL en dos aspectos importantes: generaliza la gramática de SQL para hacer el lenguaje más ortogonal, y permite añadir nueva funcionalidad al lenguaje (definiendo nuevas funciones sobre columnas, nuevas operaciones sobre tablas y nuevos tipos de datos para columnas).
1.2.2 SGBDOO POSTGRES
Es un SGBD objeto-relacional desarrollado bajo la dirección de M. Stonebraker en la Universidad de California (Berkeley), y que proporciona extensibilidad para tipos de datos, operadores y métodos de acceso. En 1996 cambia su nombre por el de PostgresSQL2 tras haber sustituido el lenguaje de consulta inicial (POSTQUEL) por SQL. Es el sucesor del SGBD relacional INGRES (POST inGRES) y el predecesor del sistema Illustra.
1.2.2.1 Características del modelo
El modelo de datos de POSTGRES está basado en el modelo relacional, pero proporciona objetos (una clase es una tabla, una fila es una instancia y una columna es un atributo), identificadores de objetos (único para cada instancia), objetos compuestos, herencia múltiple, sobrecarga de funciones o métodos, y versiones. Incluye triggers y un potente sistema de reglas.
1.2.3 SGBDOO ObjectFile
Es un motor comercial, suministrado en forma de código fuente, que es empleado para proporcionar persistencia de objetos a cualquier aplicación C++, mediante el almacenamiento
16 de los mismos en ficheros tradicionales. La entrada y la salida se realizan empleando funciones estándar de C o funciones del sistema operativo nativo. Está escrito en C++
estándar y emplea la Standard Template Library, por lo que se exige la existencia de un compilador que soporte estas características.
1.2.3.1 Deficiencias como sistema Carencia de funcionalidades básicas
Este motor está más cercano a un mecanismo para proporcionar persistencia a un lenguaje de programación, como es C++, que a un gestor de objetos, ya que carece del resto de funcionalidades básicas de un gestor: gestión de concurrencia, posibilidad de consultas, etc.
Ligado al lenguaje de programación C++
ObjectFile está pensado única y exclusivamente para objetos creados con el lenguaje de programación C++, no facilitando la interoperabilidad con objetos creados desde otros lenguajes orientados a objetos como, por ejemplo, Java.
Persistencia no transparente
Desde el punto de vista de la persistencia, la forma en la que ObjectFile la proporciona no es en absoluto transparente, al ser el propio usuario el que tiene que implementar los métodos que permitan el almacenamiento y la recuperación de los objetos.6
1.2.4 SGBDOO DarmStadt
El proyecto DarmStadt, desarrollado en la Universidad de Darmstadt (Alemania), representa un gestor de objetos también conocido como DASDBS (DarmStadt Data Base System) que se basa en un núcleo común sobre el que se superponen capas de soporte para aplicaciones específicas, de forma que un SGBD específico para una aplicación se obtiene enlazando el núcleo con el front-end correspondiente.
6Prieto, Ana Belén Martínez. Un Sistema de Gestion de Base de Datos Orientadas a Objetos sobre una Maquina Abstracta Persistente.
2001.
17 1.2.4.1 Deficiencias como sistema
No facilita la portabilidad
A diferencia de la tendencia actual a la realización de sistemas portables, en este sistema entre sus objetivos no se plantea el facilitar la portabilidad del sistema a diferentes entornos. Y esto queda patente al ser el lenguaje inicial de implementación el Pascal y con posterioridad el lenguaje C.
Desadaptación de impedancias entre los diferentes niveles de la arquitectura
Una de las principales ventajas atribuibles a esta arquitectura es la construcción de un núcleo que ofrece operaciones orientadas a conjuntos. Sin embargo, se observa que al no emplear ni el sistema operativo ni los lenguajes de programación ese mismo paradigma se producen problemas de desadaptación de impedancias entre ellos, lo que obliga a construir artefactos software como el object buffer para solucionarlos.
Modelo relacional anidado
El modelo empleado para representar objetos complejos es el modelo relacional anidado NF2 que además de suponer una descomposición artificial de los datos dificulta entre otras cosas las relaciones de cardinalidad n-m (de muchos a muchos).
Descarga demasiada funcionalidad en el front-end
El hecho de que el núcleo no reconozca tipos definidos por el usuario y ni siquiera tipos básicos estándar, hace que las operaciones sobre estos tipos tengan que ser implementadas a nivel de front-end, al igual que los mecanismos de indexación que no son en absoluto considerados en el núcleo. Esto ocasiona una transformación para adaptar las cadenas almacenadas en el núcleo a los tipos de datos correspondientes, lo que se traduce obviamente en una disminución del rendimiento del sistema.7
7Prieto, Ana Belén Martínez. Un Sistema de Gestion de Base de Datos Orientadas a Objetos sobre una Maquina Abstracta Persistente.
2001.
18 1.2.5 SGBDOO StreamStore
StreamStore es un gestor de almacenamiento de bajo nivel escrito en Java que proporciona clases Java para almacenar, recuperar e indexar cualquier clase de objetos. Consta de dos subsistemas que pueden emplearse independientemente: subsistema de almacenamiento y subsistema B-Tree (para la indexación).
1.2.5.1 Deficiencias como sistema
Falta de transparencia para conseguir la persistencia
Para conseguir la persistencia es necesario añadir a cada clase dos métodos que realizan el almacenamiento y posterior carga de los objetos, no siendo en absoluto un proceso transparente para el usuario. Se necesita en primer lugar crear un StreamStore, después una StreamTable y posteriormente, hay que crear un StreamRecord para cada objeto que desea hacerse persistente, y por supuesto, invocar el método correspondiente para guardar el objeto.
Mantenimiento manual de los índices
El mantenimiento de los índices es totalmente responsabilidad del programador, es decir, es el programador el encargado de insertar, borrar y actualizar en la estructura índice.
No soporta consultas declarativas
No proporciona soporte para interrogaciones declarativas a la base de datos mediante un lenguaje estilo OQL.
Filosofía relacional
StreamStore no es un adaptador objeto-relacional propiamente, ya que finalmente los objetos no se almacenan en tablas, sin embargo si se adecua muy bien al modelo relacional.
1.2.6 SGBDOO Jeevan
Es un sencillo gestor de almacenamiento persistente para un único usuario sobre la plataforma Java, desarrollado por W3APPS. Este gestor es un API, que permite al usuario
19 desarrollar aplicaciones empleando únicamente el Java Development Kit, sin que sean por tanto necesarios ni precompiladores.8
1.2.6.1 Deficiencias como sistema
Diferentes métodos para la recuperación de información
Este gestor para la recuperación de los datos no dispone de un lenguaje de consulta potente estilo OQL, si no que acude a una serie de métodos (de la interfaz Database mayoritariamente) que proporcionan las siguientes posibilidades:
• Obtener un objeto por su identificador (método getObject).
• Obtener un conjunto de objetos: bien todos los objetos de una clase, o bien todos los que cumplen una determinada condición (método selectObjects).
• Obtener todos los objetos de una jerarquía de clases. También se puede especificar un criterio de selección (método selectObjectOfType).
• Obtener determinados atributos del objeto (método selectFields).
• Para emplear criterios de selección dinámicos se debe emplear la clase OQLQuery.
Carencia de flexibilidad/extensibilidad
Este gestor proporciona un conjunto mínimo de servicios rígidamente establecidos, no permitiendo la incorporación de nuevas técnicas para ninguno de esos servicios, ni por supuesto la incorporación de los servicios de los que carece.
Indexación mínima no extensible
La indexación soportada por este gestor es básica, ya que únicamente permite indexar por campos de tipo primitivo. Tampoco proporciona ningún mecanismo para incorporar nuevas técnicas de indexación.
8Prieto, Ana Belén Martínez. Un Sistema de Gestion de Base de Datos Orientadas a Objetos sobre una Maquina Abstracta Persistente.
2001.
20 No es compatible con el estándar ODMG
Como se puede observar no es en ningún grado compatible con el API propuesto por el estándar ODMG para Java, lo que dificulta la portabilidad de la aplicación hacia otros gestores diferentes de Jeevan.
No uniformidad en el tratamiento de los objetos
Jeevan no realiza un tratamiento uniforme de los objetos, ya que distingue claramente dos tipos de objetos: los contenedores (extienden Storable) y los incrustados (implementan java.io.Serializable). Además, no comprueba que ambos tipos se empleen del modo adecuado, con lo que puede ocurrir que una clase que extiende la clase Storable tenga un atributo que además es de tipo Storable, lo que puede ocasionar que tengamos dos copias del objeto, una en su propia área de almacenamiento y otra incrustada en el objeto contenedor, con las posibles inconsistencias que esto puede acarrear.
Persistencia mediante serialización Java
El hecho de emplear la serialización como método para conseguir la persistencia impone lentitud si el volumen de datos es grande y además, no proporciona un medio confiable de almacenamiento, ya que si se produce un fallo en el sistema mientras se está escribiendo el objeto a disco se pierde el contenido del fichero.
No soporta concurrencia ni recuperación
Este gestor (al menos la versión revisada) no soporta el concepto de transacción, ni la posibilidad de recuperación ante cualquier fallo del sistema.9
1.2.7 SGBDOO Jasmine
Jasmine es un gestor de base de datos que soporta estructuras de datos complejas, herencia múltiple, propiedades y métodos a nivel de instancia y a nivel de clase, colecciones y métodos a nivel de colección, especificación de integridad referencial, y a diferencia de otros gestores la clase contiene su propia extensión.
9Prieto, Ana Belén Martínez. Un Sistema de Gestion de Base de Datos Orientadas a Objetos sobre una Maquina Abstracta Persistente.
2001.
21 Además de C y C++, Jasmine proporciona un binding para Java creando una clase Java para cada clase Jasmine. Proporciona también una interfaz para cualquier entorno que soporte ActiveX, y mediante un conjunto de herramientas (WebLink), proporciona una forma de acceso a la base de datos mediante Internet empleando páginas HTML.
1.2.7.1 Lenguaje de programación Jasmine/C
Jasmine incorpora, como lenguaje de programación para la construcción de aplicaciones avanzadas, un lenguaje (Jasmine/C) que integra un lenguaje de propósito general C, y un lenguaje de base de datos en un contexto orientado a objetos. El compilador de Jasmine, está implementado para que utilice un compilador de C. Los programas de aplicación, escritos en Jasmine/C, son precompilados a programas de C, los cuales son compilados y enlazados con la runtime support library. El preprocesamiento, se utiliza para obtener el máximo rendimiento de la portabilidad y la optimización de código del compilador de C.
1.2.8 SGBDOO GemStone
GemStone es un SGBDOO que combina los conceptos del lenguaje orientado a objetos SmallTalk. GemStone es particularmente preferible para ser usado en aplicaciones cliente/servidor multiusuario y multiplataforma, soporta acceso concurrente de múltiples lenguajes, incluyendo Smalltalk-80, Smalltalk/V, C++ y C. GemStone también provee un dialecto de Smalltalk (Smalltalk DB, formalmente conocido como OPAL) como DDL y DML internos, los cuales pueden ejecutar métodos o aplicaciones enteras en la base de datos.
El lenguaje de definición y manipulación de datos se denomina Opal y es derivado del SmallTalk. En GemStone los métodos y las estructuras comunes a todas las instancias de una clase están contenidos en un objeto referido como CDO (Objeto de Definición de Clases) por tanto incluso la definición de una clase es un objeto. Todas las instancias de una clase contienen una referencia a su CDO como parte de su identificador de objeto, adicionalmente cada objeto es una instancia de una clase. En GemStone solo se pueden acceder a los atributos de los objetos a través de lo métodos que estos poseen.
22 1.2.9 Lenguaje de Consulta IRIS
El lenguaje de consulta de IRIS, conocido como OSQL es el más similar a SQL en términos de funcionalidad. Más específicamente OSQL, también tiene mecanismos de control para tener acceso secuencial a los resultados de una consulta. Se puede llamar en una consulta a funciones definidas por el usuario. Obviamente el sistema verifica que se el pasen a la función, argumentos con el tipo correcto para asegurar que la consulta es correcta. Con el lenguaje de IRIS también se pueden realizar proyecciones y utilizar al cláusula distinct al igual que en SQL para eliminar los duplicados.
1.2.10 SGBDOO O2
En O2, el esquema define los tipos y las clases de objetos del sistema. Un tipo de objetos se define usando los tipos atómicos provistos por O2 y aplicando los constructores de tipo de O2.
Los tipos atómicos son booleano, de caracter, entero, real, de cadena y de bit. Los constructores de tipos son la tupla, lista, conjunto y conjunto único. Cuando se especifica solo, el constructor de conjunto (set) permite elementos duplicados (lo que llamamos bolsa), no así el constructor conjunto único (unique set) parecido a lo que llamamos conjunto.
En O2 los métodos no se incluyen como parte de una definición de tipos. Más bien, una definición de clase consta de dos partes: el tipo de los objetos que pueden ser miembros de la clase y los métodos que se pueden aplicar a dichos objetos.
1.2.10.1 Lenguaje O2
El sistema O2 tiene un lenguaje O2C, que sirve para definir clases, métodos y tipos, y para crear objetos y valores. El lenguaje de consulta de O2 puede utilizarse solamente como lenguaje dependiente. No puede ser utilizado dentro de métodos, ni dentro del lenguaje de aplicación O2C. Esto limita el alcance de aplicación del lenguaje de consulta. Este lenguaje no tiene previsto mecanismos de cursores. El lenguaje de consulta se utiliza principalmente desde interfaces gráficas interactivas, las cuales ofrecen un pequeño entorno específicamente para la consultas. Este entorno permite por lo general formular las consultas, salvarlas
23 asignándoles un nombre y visualizar el resultado. En O2 se pueden ejecutar proyecciones, reuniones y subconsultas.
1.3 Conclusiones
El beneficio principal de un lenguaje para manipular bases de datos orientadas a objetos no es un tiempo de desarrollo más reducido, el desarrollo orientado a objetos puede requerir más tiempo que el desarrollo convencional porque se pretende que promueva la reutilización futura y la reducción de los posteriores errores y el futuro mantenimiento.
No hay duda que las ideas orientadas a objetos llegaron para quedarse y han influenciado los modelos relacionales tradicionales. Existen dos razones principales por las que la metodología orientada a objetos es un sólido fundamento para la nueva generación de tecnología de base de datos.
Por una parte, esta metodología ofrece un modelo de datos que incluye los modelos de datos de un sistema de base de datos convencional. Un modelo de datos orientado a objetos puede representar no solamente los datos, las relaciones y la interacción de datos de modelos de datos convencionales, sino también permite encapsular los datos y programas que operan datos con un protocolo definido y proporcionan una estructura uniforme para el trato de tipos de datos arbitrarios definidos por el usuario.
Una segunda razón, es que a través de la noción de encapsulamiento y herencia, esta metodología está fundamentalmente diseñada para reducir la dificultad de desarrollo y evolución de sistemas complejos de "software".
Luego de analizar los distintos GBDOO, y los lenguajes de los mismos llegamos a la conclusión de que existen diferencias entre las posibilidades que brindan estos lenguajes para materializar los conceptos de la programación orientada a objetos, además que existen deficiencias en cada uno de estos gestores y a su vez en los lenguajes como son: muchos de ellos soportan la herencia múltiple, que su uso se ha demostrado que no es muy recomendado, encontramos algunos que están muy ligados a un solo lenguaje de programación, que no soportan consultas declarativas, algunos poseen además falta de transparencia para conseguir la persistencia.
24 CAPÍTULO 2: PROPUESTA DE UN LENGUAJE ESTÁNDAR DE CONSULTA PARA UN SGBDOO.
Introducción
En este capítulo se describen las principales características que van a describir la propuesta de lenguaje estándar de consulta para un SGBDOO. Se examinará además cada uno de los aspectos más importantes a tener en cuenta a la hora de realizar el diseño del lenguaje, en todas sus variantes.
2.1 Lenguaje de Programación
Un lenguaje de programación es un conjunto limitado de palabras y de símbolos que representan procedimientos, cálculos, decisiones y otras operaciones que pueden ejecutar una computadora. A pesar de que en este trabajo hemos partido de la división de lenguajes en imperativos y declarativos (los cuales a su vez se dividen en numerosos subgrupos), la clasificación más común y básica que suele hacerse de los lenguajes de programación es la que los divide en lenguajes de bajo y de alto nivel.
2.1.1 Paradigmas de los Lenguajes de Programación
Los paradigmas son marcos de referencia que imponen reglas sobre cómo se deben hacer las cosas, indican qué es válido dentro del paradigma y qué está fuera de sus límites. Un paradigma distinto implica nuevas reglas, elementos, límites y maneras de pensar, o sea implica un cambio.10 Los paradigmas pueden ser considerados como patrones de pensamiento para la resolución de problemas. Desde luego siempre teniendo en cuenta los lenguajes de programación, según nuestro interés de estudio.
Dentro de los paradigmas de los lenguajes de programación se encuentran:
• Paradigmas Imperativo: Modelo abstracto que consiste en un gran almacenamiento de memoria donde la computadora almacena una representación codificada de un cálculo
10Paradigmas de Programación. [En línea] [Citado el: 2 de Abril de 2008.] http://www.frt.utn.edu.ar/sistemas/paradigmas/page22.html.
25 y ejecuta una secuencia de comandos que modifican el contenido de ese almacenamiento.
• Algoritmos + Estructura de Datos = Programa.
• Paradigmas Procedimentales - Modelos de Desarrollo: Orientado a Objetos, a Eventos y a Agentes. Secuencia computacional realizada etapa a etapa para resolver el problema. Su mayor dificultad reside en determinar si el valor computado es una solución correcta del problema.
• Paradigmas Declarativos - Modelos de Desarrollo: Funcional, Lógico y de Flujo de Datos. Se construye señalando hechos, reglas, restricciones, ecuaciones, transformaciones y otras propiedades derivadas del conjunto de valores que configuran la solución.
• Paradigmas Demostrativos - Modelos de Desarrollo: Genético. Cuando se programa bajo un paradigma demostrativo (también llamada programación por ejemplos), el programador no especifica procedimentalmente cómo construir una solución sino que presentan soluciones de problemas similares.
• Paradigmas Funcional - Modelo matemático de composición funcional donde el resultado de un cálculo es la entrada del siguiente, y así sucesivamente hasta que una composición produce el valor deseado.
2.1.2 Paradigmas de programación orientada a objetos.
La orientación a objetos es un paradigma de programación que facilita la creación de software de calidad por sus factores que facilitan el mantenimiento, la extensión y la reutilización del software generado bajo este paradigma. La programación orientada a objetos trata de amoldarse al modo de pensar del hombre y no al de la máquina o sea pensar en términos de objetos es muy parecido a cómo lo haríamos en la vida real.
El elemento básico de este paradigma no es la función (elemento básico de la programación estructurada), sino los objetos. Un objeto es la representación de un concepto para un programa, y contiene toda la información necesaria para abstraer dicho concepto: los datos
26 que describen su estado y las operaciones que pueden modificar dicho estado y determinan las capacidades del objeto.
Existen una serie de principios fundamentales para comprender cómo se modela la realidad al crear un programa bajo el paradigma de la orientación a objetos. Estos principios son: la abstracción, el encapsulamiento, la modularidad, la jerarquía, el paso de mensajes y el polimorfismo.11
Principio de Abstracción.
Mediante la abstracción la mente humana modela la realidad en forma de objetos. Para ello, busca parecidos entre la realidad y la posible implementación de objetos del programa que simulen el funcionamiento de los objetos reales.
Principio de Encapsulamiento.
El encapsulamiento permite a los objetos elegir qué información es publicada y qué información es ocultada al resto de los objetos. Para ello los objetos suelen presentar sus métodos como interfaces públicas y sus atributos como datos privados e inaccesibles desde otros objetos.
Con el encapsulado de los datos se consigue que los usuarios de un objeto sólo tengan que comprender su interfaz, olvidándose de cómo está implementada, y en definitiva, reduciendo la complejidad de utilización.
Principio de Modularidad.
Mediante la modularidad, se propone al programador dividir su aplicación en varios módulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos con un sentido propio.
Esta fragmentación disminuye el grado de dificultad del problema al que da respuesta el programa, pues se afronta el problema como un conjunto de problemas de menor dificultad, además de facilitar la comprensión del programa.
11Campo, Miguel Angel Manzanedo del. Guía de Iniciación al Lenguaje Java. [En línea] [Citado el: 20 de octubre de 2007.]
http://pisuerga.inf.ubu.es/lsi/Invest/Java/Tuto/I_1.htm.
27 Principio de Jerarquía.
La mayoría de nosotros ve de manera natural nuestro mundo como objetos que se relacionan entre sí de una manera jerárquica.
Las distintas clases de un programa se organizan mediante la jerarquía.
Mediante la herencia una clase hija puede tomar determinadas propiedades de una clase padre. Así se simplifican los diseños y se evita la duplicación de código al no tener que volver a codificar métodos ya implementados. Al acto de tomar propiedades de una clase padre se denomina heredar.
Principio del Paso de Mensajes.
Mediante el denominado paso de mensajes, un objeto puede solicitar de otro objeto que realice una acción determinada o que modifique su estado. El paso de mensajes se suele implementar como llamadas a los métodos de otros objetos.
Desde el punto de vista de la programación estructurada, esto correspondería con la llamada a funciones.
Principio de Polimorfismo.
Polimorfismo quiere decir "un objeto y muchas formas". Esta propiedad permite que un objeto presente diferentes comportamientos en función del contexto en que se encuentre. Por ejemplo un método puede presentar diferentes implementaciones en función de los argumentos que recibe, recibir diferentes números de parámetros para realizar una misma operación y realizar diferentes acciones dependiendo del nivel de abstracción en que sea llamado.
2.1.3 Atributos de un buen lenguaje.
• Claridad, sencillez y unidad (legibilidad): La sintaxis del lenguaje afecta la facilidad con la que un programa se puede escribir y más tarde entender y modificar.
• Ortogonalidad: Capacidad para combinar varias características de un lenguaje en todas las combinaciones posibles, de manera que todas ellas tengan significado.
• Naturalidad para la aplicación: La sintaxis del programa debe permitir que la estructura del programa refleje la estructura lógica subyacente.
28
• Apoyo para la abstracción: Una parte importante de la tarea del programador es proyectar las abstracciones adecuadas para la solución del problema y luego implementar esas abstracciones empleando las capacidades más primitivas que provee el lenguaje de programación mismo.
• Facilidad para verificar programas: La sencillez de la estructura semántica y sintáctica ayuda a simplificar la verificación de programas.
• Entorno de programación: Facilita el trabajo con un lenguaje técnicamente débil en comparación con un lenguaje más fuerte con poco apoyo externo.
• Portabilidad de programas
• Costo de uso:
• Costo de ejecución del programa.
• Costo de traducción de programas.
• Costo de creación, prueba y uso de programas.
• Costo de mantenimiento de los programas: costo total del ciclo de vida.
2.2 Lenguajes de consulta orientados a objetos.
Los lenguajes de consulta constituyen una funcionalidad importante de los SGBDOO. El usuario puede recuperar los datos especificando simplemente las condiciones que estos datos deben cumplir. Si se analizan los lenguajes de consulta orientados a objetos, conviene resaltar tres características que vienen directamente impuestas por el modelo de objetos (y que marcarán claramente las diferencias con los lenguajes de consulta relacionales):
• El mecanismo de la herencia (Jerarquías de Herencia).
La herencia provoca que una instancia de una clase sea también una instancia de su superclase. Esto implica que, el ámbito de acceso de una consulta sobre una clase en general incluye a todas sus subclases, a menos que se especifique lo contrario.
• Predicados con atributos complejos anidados (Jerarquías de Agregación).
Mientras que en el modelo relacional los valores de los atributos se restringen a tipos primitivos simples, en el modelo orientado a objetos el valor del atributo de un objeto puede ser un objeto o conjunto de objetos. Esto provoca que las condiciones de búsqueda en una
29 consulta sobre una clase se puedan seguir expresando de la forma <atributo operador valor>, al igual que en el modelo relacional, pero con la diferencia básica de que el atributo puede ser un atributo anidado de la clase.
• Predicados con invocación de métodos.
En el modelo de objetos los métodos definen el comportamiento de los objetos y, al igual que en el predicado de una consulta puede aparecer un atributo, también puede aparecer la invocación de un método.
2.2.1 Atributos del Lenguaje de Consulta
De manera general el lenguaje que se propone posee entre otras características las que a continuación se especifican:
• Es un lenguaje de alto nivel, de modo que se pueden formular fácilmente operaciones complejas.
• Es declarativo, esto es que el foco de atención está dirigido hacia QUE se quiere y no hacia COMO se obtiene.
• Es eficiente, las construcciones permiten optimizaciones.
• Es capaz de proveer representación de objetos complejos.
• Es extensible, o sea, provee soporte para definir nuevos tipos de datos y métodos que son capaces de operar con ese objeto.
• Soporta la encapsulación o abstracción de información. Proporciona la capacidad para ocultar cómo los datos se representan dentro del objeto y cómo se implementa cada método de otros objetos y otras entidades fuera de sí mismo.
• Permite expresar herencia entre objetos. Los objetos existirán en una relación de jerarquía. Una relación de jerarquía es una relación donde un objeto es o proviene desde un objeto raíz. Los objetos en una Base de Datos Orientada a Objetos provendrán desde un objeto de base de datos raíz, o un sub-objeto del objeto de base de datos raíz. Esto brinda la habilidad de adquirir los atributos (datos) y operaciones de otros objetos sobre él en la jerarquía.
30 2.3 Valores
Un valor es una entidad que existe durante un proceso de cálculo y que no altera su significado12. Se puede:
• inspeccionar.
• almacenar.
• incorporar en una estructura de datos.
• pasar como argumento a un procedimiento o función.
• devolver como resultado de una función.
• Siempre conserva su significado: Invarianza semántica.
No todos los valores que un programador pueda pensar, expresar, o usar con un cierto lenguaje, reciben el mismo tratamiento por parte de dicho lenguaje. El Lenguaje propuesto manipula distintas clases de valores las cuales se presentan a continuación:
• Los valores de Primera Clase son: los enteros, los reales, los registros, los conjuntos, además de clases de referencia a variables.
• Los valores de Segunda Clase son: procedimientos y funciones abstractas y algunas otras clases de referencias a variables.
Los valores que no sean ni de primera ni de segunda clase habrán de ser agregados por el programador montando sus propios artificios. Para los de primera, todo lenguaje facilita al programador unos mecanismos para su representación, gestión y manipulación, que omite facilitar para los de segunda. Sólo serán valores de primera clase aquellos para los que el lenguaje facilite un tipo, alguna forma para definir ese tipo, u otro concepto que, a estos efectos, sea similar al de tipo.
2.3.1 Valores Nulos
El resultado de acceder a una propiedad de un objeto nulo está indefinido. Las reglas para manejar ésta indefiniciones en la Propuesta de Lenguaje serán:
12Atributos de un buen lenguaje de programación. [En línea] [Citado el: 28 de Noviembre de 2007.]
http://209.85.215.104/search?q=cache:76GxM7veW1kJ:usuarios.lycos.es/kikorb/dlp.doc+atributos+de+un+buen+lenguaje+de+programaci%C 3%B3n&hl=es&ct=clnk&cd=1&gl=cu.
31
• Los operadores punto (.) para acceso a propiedades, aplicado a operandos a la izquierda indefinidos produce una indefinición como resultado.
• Las operaciones de comparación (=, !=, <, >, <=, >=) con uno de los operandos indefinidos produce un resultado falso.
• is_undefined (indefinido) retorna verdadero; is_defined (indefinido) produce falso.
• Cualquier otra operación con un valor indefinido produce un error en tiempo de ejecución.
2.3.2 Tipos de datos
Los datos se clasifican en diversas categorías según el tipo de máquina o el lenguaje que se use. En la propuesta de lenguaje podemos encontrar las siguientes categorías:
• Numéricos.
• Lógicos.
• Cadena.
Datos Numéricos
Son aquéllos que representan una cantidad o valor determinado. Su representación se lleva a cabo en los formatos ya conocidos (enteros, punto y fracciones decimales si estas existen).
Estos se representarán de dos formas distintas:
• Tipo Numérico Entero (integer)
Es un conjunto finito de los números enteros. Los enteros son números completos, no tienen componentes fraccionarios o decimales y pueden ser negativos y positivos.
• Tipo Numérico Real (real)
Consiste en un subconjunto de los números reales. Estos números siempre tienen un punto decimal y pueden ser positivos o negativos. Un número real consiste de un número entero y una parte decimal.
32 Lógicos
Este tipo de dato también conocido como Booleano, es aquél que solo puede tomar uno de dos valores: Falso o Verdadero. Con él se representarán las alternativas (si/no) a determinadas condiciones. Por ejemplo, cuando se pide si un valor entero sea primo, la respuesta será verdadera o falsa, según sea.
Las categorías y tipos que se mencionaron anteriormente se conocen como Tipos Simples, puesto que no poseen una estructura compleja. En forma adicional, cada lenguaje puede proporcionar la utilización de Tipos Compuestos, siendo estos, datos que tienen una estructura predeterminada.
Cadenas
Son los datos que representan información textual (palabras, frases, símbolos, etc.). No representan valor alguno para efectos numéricos. Pueden distinguirse porque son delimitados por apóstrofes o comillas.13 Se clasifica en dos categorías:
• Datos tipo carácter (char)
Es un conjunto finito y ordenado de caracteres que la computadora reconoce. Un dato de este tipo contiene solo un carácter.
• Datos tipo Cadena (string)
Es una sucesión de caracteres que se encuentran delimitados por una comilla (apóstrofe). La longitud de una cadena de caracteres es el número de ellos comprendidos entre los separadores o delimitadores
13Medrano, Lourdes Arlín Campoy. Tutorial de Base de Datos 1. [En línea] [Citado el: 3 de octubre de 2007.]
